Desarrollo de software orientado a objetos

Desarrollo de software orientado a objetos

1. Modelo de requisitos

   • objetivo
     • Delimitar el sistemas
     • Capturar la funcionalidad desde la perspecitiva del usuario
   • contrato entre el desarrollador y el cliente
     • proyectar lo que desea el cliente
   • Primero en desarrollarse
   • base para formar demás modelos
   • cualquier cambio que se haga
     • menores consecuencias en este nivel
   • se basa en la metodología Objectory
     • modelo de casos de uso
   • Conceptos
     • Requisitos
       • Expresar el modelo de requisitos
     • Análisis
       • Modelo de análisis
         • estable respecto a cambios
     • Diseño
       • Modelo de diseño
         • Adaptándose al ambiente de implementación real
     • Implementación
       • código fuente
     • Pruebas
       • casos de uso
         • pruebas de componentes y de integración
     • Documentación
       • se debe registrar a lo largo de las diversas actividades
         • manuales de usuarios, administracioó, etc.
   • Propósito comprender en su totalidad el problema y sus implicaciones
   • el analista debe interactuar con el cliente
     • completar la información faltante, y así resolver ambigüedades e inconsistencias.
   • separar los requisitos verdaderos
   • metodología de Objectory
     • El modelo de comportamiento
       • especifica la funcionalidad que ofrece el sistema
         • punto de vista del usuario
     • modelo de presentación
       • especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso
     • El modelo de información
       • aspectos estructurales de la aplicación en términos de objetos
   • descripción del problema
     • es un resumen preliminar de necesidades
     • punto de partida para comprender los requisitos del sistema.
   • modelo de casos de uso
     • describe un sistema en términos de sus distintas formas de utilización
       • , cada una de las cuales se conoce como un caso de uso
         • . Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario
           • los cambios en los requisitos significarán cambios en los casos de uso.
     • actores
       • entidades distintas a los usuarios
         • , en el sentido de que éstos son las personas reales que utilizarán el sistema.
         • los actores representan cierta función que una persona real realiza
   • casos de usos
     • , se establece la funcionalidad propia del sistema por medio de los casos de uso
     • cada caso de uso define una clase o forma particular de usar el sistema
     • cada ejecución del caso de uso se puede ver como una instancia del mismo
   • documentación
     • es fundamental la descripción textual detallada de cada uno de los actores y casos de uso identificados
     • . Estos documentos son sumamente críticos ya que a partir de ellos se desarrollará el sistema completo.
   • modelo de interfaces
     • describe la presentación de información entre los actores y el sistema
     • . Se especifica en detalle cómo se verán las interfaces de usuario al ejecutar cada uno de los casos de uso.
   • Modelo del Dominio del Problema
     • define un modelo de clases común para todos los involucrados en el modelo de requisitos, tanto analistas como clientes.
     • consiste en los objetos del dominio del problema,
     • identificación de clases del dominio del problema
       • , se obtiene principalmente de algún documento textual que describa el sistema.
     • identificación de atributos
       • determinar los atributos del dominio del problema.
         • Este proceso tiene una complejidad similar al de identificación de las asociaciones.
       • Sin embargo, identificar atributos puede resultar más difícil si se hace a través de un proceso de búsqueda a partir de la descripción del problema

2. Modelo de análisis

   • objetivo
     • comprender y generar una arquitectura de objetos para el sistema con base en lo especificado en el modelo de requisitos.
   • representación conceptual
   • cualidad
     • rastreabilidad (traceability) de los modelos, que permite evaluar el impacto de cambios durante el desarrollo.
   • Arquitectura de clases
     • objetivoñgenerar una arquitectura de objetos que sirva como base para el diseño del sistema
     • se distinguen según la organización de los objetos de acuerdo a su funcionalidad.
     • incluir cualquier número de dimensiones
     • Clases con estereotipos
       • Entidad
         • objetos que guardan información sobre el estado interno del sistema a corto y largo plazo
         • objetos corresponden al dominio del problema
       • Borde
         • objetos que implementan las interfaces del sistema con el mundo externo
       • Control
         • objetos que implementan el comportamiento o control de la lógica de los casos de uso,
           • especificando cuándo y cómo el sistema cambia de estado
         • . Los objetos control modelan la funcionalidad que no se asocia naturalmente con un solo objeto.
   • identificación de clases según sus estereotipos
     • identificar
       • clases borde
         • Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema
         • describen la comunicación bidireccional entre el sistema y los actores.
         • cuenta con al menos tres estrategias para identificarlas
           • base en los actores
             • Cada actor necesita su propia clase borde para comunicarse con el sistema
               • dos tipos de clase borde dependiendo del tipo de actor
                 • bordes a otros sistemas
                   • comunicación se describa mediante protocolos de comunicación
                   • traducir las salidas del sistema a un protocolo de comunicación estandarizado
                   • enviar eventos producidos internamente sin conversiones complejas
                 • bordes a usuarios humanos.
                   • utilizan diversas técnicas para el modelado de la interacción
           • base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos
           • descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes
       • clases entidad
         • modelar la información que el sistema debe manejar a corto y largo plazos
           • la información a corto plazo existe durante la ejecución de un caso de uso
           • la información a largo plazo trasciende los casos de uso
         • se identifican principalmente a partir del dominio del problema del modelo de requisitos
         • no es fácil decidir cuándo cierta información debe ser modelada como un objeto entidad o un atributo
       • clases control
         • en la mayoría de casos
           • existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos
             • clase borde
             • clase entidad
             • posibilidad es repartir el comportamiento entre los dos tipos de objetos
               • no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación
                 • para evitar estos problemas, tal comportamiento se asigna a objetos control.
         • normalmente proveen la administración de los demás tipos de objetos, dependiendo de la existencia del propio caso de uso
         • proveen la administración de los demás tipos de objetos, dependiendo de la existencia del propio caso de uso
         • se especifica directamente de los casos de uso
     • lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y controles difícil
   • diagramas de secuencias
     • describen los diferentes casos de uso según la interacción o eventos enviados entre los objetos de la arquitectura del modelo de análisis
     • describe aspectos dinámicos de un sistema
     • utilizan objetos
   • Diccionario de clase según módulos
     • organiza según módulos
     • no es obligatorio
     • aprovechamos para separar estas clases en diferentes módulos
       • lograr una mejor organización y correspondencia entre clases y casos de uso

3. Modelo de diseño

   • refinamiento y formalización adicional del modelo de análisis
   • especificaciones muy detalladas de todos los objetos
   • formalización del espacio de análisis
   • transición de análisis a diseño
     • separado para cada aplicación particular
   • el diseño tiene la responsabilidad de mantener esta separación mediante métodos
     • sirven para tomar decisiones (control) y aquellos que no (borde y entidad).
   • aspectos principales
     • Diseño de objetos
       • formaliza el modelo para generar especificaciones muy detalladas de todos los objetos, incluyendo sus operaciones y atributos.
         • describe cómo interactúan los objetos en cada caso de uso específico
     • Diseño de sistema
       • identificar e investigar las consecuencias del ambiente de implementación sobre el diseño
         • decisiones de implementación estratégicas
           • cómo se incorporará una base de datos en el sistema
           • qué y cómo se usarán las bibliotecas de componentes
           • qué lenguajes de programación se utilizarán
           • cómo se manejarán los procesos
           • cómo se diseñará el manejo de excepciones y recolección de basura
   • si el ambiente de implementación tiene pocas consecuencias en el sistema, el diseño se basará casi exclusivamente en el diseño de objetos
     • Por el contrario
       • si el ambiente de imple-mentación afecta de manera importante al sistema, el diseño se basará en una combinación de diseño de objetos y diseño de sistema
   • Estrategias de Diseño
     • arquitectura
       • organización de las clases dentro del sistema
       • Durante el diseño debe detallarse esta arquitectura
     • robustez
       • uno de los objetivos principales del diseño
       • El sistema debe estar protegido contra errores y ofrecer diagnósticos que permitan identificar fallas,
       • a veces es bueno insertar instrucciones internas en el código para descubrir fallas
         • luego se eliminen durante la producción
       • se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepciones
     • reuso
       • Cuanto más se pueda reutilizar el código será mejor la robustez del sistema
     • extensibilidad
   • Diseño de objetos
     • proceso para añadir detalles al análisis y tomar decisiones junto con el diseño del sistema
     • determinar cómo las clases, atributos y asociaciones del modelo de análisis deben implementarse en estructuras de datos específicas
     • determinar si se requiere introducir nuevas clases en el modelo de diseño
       • funcionalidad ofrecida por las clases servidores se define en términos de sus responsabilidades
     • diseñar un objeto se seguirá el diseño por responsabilidades (RDD - Responsibility-Driven Design)
       • basa en un modelo cliente-servidor
     • Las tarjetas de clases permiten al diseñador visualizar las diferentes clases de manera independiente y detallada.
     • responsabilidades
       • se identifican a partir de los casos de uso generados durante el modelo de análisis
     • jerarquía
       • no de los aspectos de programación más importantes de la orientación a objetos
       • se identifica a partir de las responsabilidades y colaboraciones obtenidas antes
     • contrato
       • mecanismo de diseño para agrupar las distintas responsabilidades de una clase
         • relacionadas lógicamente entre sí
       • sirven como indicadores de los diversos servicios provistos por cada clase
     • Protocolos
       • pertenece al conjunto de firmas correspondientes a las distintas responsabilidades de una clase
       • El objetivo
         • es precisar las responsabilidades hasta obtener métodos que den especial énfasis a las responsabilidades agrupadas en los contratos ofrecidos por las clases.
     • atributos
       • aspectos estructurales de las clases
   • Diseño de sistema
     • aspectos
       • lenguaje de programación a utilizarse
       • Incorporación de bibliotecas
       • Incorporación de una base de datos de tipo relacionales
       • Incorporacion de archivos
       • Consideraciones de procesamiento
     • Lenguajes de programación
       • no todos implementan de la misma forma los diferentes conceptos de la orientación a objetos
     • interfaces de gráficas
       • objetivo esencial administrar la interacción con el usuario mediante elementos gráficos
     • Base de datos
       • consideran tres los modelos de bases de datos principales
         • Modelo relacional
           • colección de tablas donde cada una tiene un número específico de columnas y un número arbitrario de filas
             • guarda un valor de tipo primitivo
               • enteros
               • cadenas
         • Modelo relacional extendido
           • se extiende mediante procedimientos, objetos, versiones y otras nuevas capacidades
         • Modelo orientado a objetos
           • Se define un modelo orientado a objetos donde varía el tipo de encapsulamiento de los datos y los procedimientos en el objeto
       • son depósitos de datos guardados en uno o más archivos
   • revisión de diseño
     • realización de una ultima revisión
   • Diagramas de secuencias del diseño
     • describir los casos de uso del análisis con base en los protocolos de clases definidos
     • pueden referir directamente a las clases
     • a partir de la interacción entre subsistemas

4. Modelo de implementación

   • Genera el código final del programa
   • se adapta al lenguaje de programación y/o la base de datos
   • Diagrama de clases
     • apoyo visual al proceso de programación

5. Modelo de pruebas

   • debe ser planificado con anticipación y de manera integral junto con el desarrollo del sistema
   • deben hacerse simultáneamente con el desarrollo del sistema
   • objetivo la certificación final de la calidad del producto y no la búsqueda de errores
   • definición de conceptos
     • falla (failure)
       • ocurre cuando un programa no se comporta de manera adecuada
       • La falla es una propiedad (estadística) de un sistema en ejecución
     • Una falta (fault)
       • tiene lugar en el código del programa.
       • puede ocasionar una falla (failure) en el sistema
       • no puede haber una falta si el programa no puede fallar (fail)
     • error
       • acción humana que provoca que un software contenga una falta
       • . Un error puede significar la existencia de una falta en el programa
   • Tipos de pruebas
     • dividen de manera general
       • validación
         • e revisa si el resultado corresponde a la especificación del sistema
       • validación
         • se revisa si el resultado es realmente lo que el cliente quería
     • técnicas
       • Prueba de regresión
         • Tiene como propósito verificar el sistema luego, de haberle introducido cambios
       • Prueba de operación
         • Su objetivo es verificar el sistema en operación por un largo periodo bajo condiciones normales de uso
       • Prueba de escala completa
         • Trata de verificar el sistema en su carga máxima
       • Prueba de rendimiento
         • Tiene como propósito medir la capacidad de procesamiento del sistema bajo diferentes cargas
       • Prueba de sobrecarga
         • Pretende observar cómo se comporta el sistema cuando se le aplica una sobrecarga, más allá de las pruebas de escala completa y rendimiento
       • Prueba negativa
         • Tiene como propósito medir el estrés del sistema en situaciones inesperadas
       • Prueba basada en requisitos
         • Intenta llevar a cabo pruebas basadas directamente en la especificación de requisitos
       • Pruebas ergonómicas
         • Tienen como propósito probar los aspectos ergo-nómicos del sistema
       • Prueba de documentación de usuario
         • Tiene como propósito probar la documentación de usuario
       • Prueba de aceptación o de validación
         • Pretende lograr una revisión final por parte de la organización que solicitó el sistema
     • niveles de prueba
       • Prueba de unidad
         • Mediante esta prueba sólo una unidad es probada como tal
         • es la de más bajo nivel
         • pruebas
           • especificación
             • verificar las relaciones de entrada y salida de una unidad
           • basada en estado
             • verifica las interacciones entre operaciones de una clase según cambios en los atributos de un objeto
           • estructural
             • que tiene como propósito verificar que la estructura interna de la unidad sea correcta
       • Prueba de integración
         • En ella se verifica que las unidades trabajen juntas correctamente
       • Prueba de sistema
         • Verifica el sistema completo o su aplicación como tal
   • Proceso de pruebas
     • abarcan
       • planeación
       • construcción
       • ejecución
     • Estrategia de prueba
       • Orden de pruebas
         • Tiene como propósito definir en qué momento y en qué orden se aplicarán las pruebas
       • Alcance de pruebas
         • Tiene como propósito identificar el tipo, número y casos de pruebas que se aplicarán para revisar los diferentes aspectos del sistema
       • Automatización de pruebas
         • Tiene como propósito reducir el esfuerzo y costo de las pruebas mediante la automatización del proceso o aspectos de él