TEMA 4. PROCESO UNIFICADO

Transcripción

1 TEMA 4. PROCESO UNIFICADO Diseño El objetivo final del diseño es producir un Modelo Lógico del sistema a implementar. Diferencia entre Análisis y Diseño del Proceso Unificado Modelo de Análisis Modelo de Diseño Es un modelo conceptual y genérico, es una abstracción del sistema Es menos formal Es un bosquejo del diseño del sistema Puede no mantenerse durante todo el ciclo de vida del software Define una estructura para modelar el sistema Es un modelo físico y concreto, es un plano de la implementación Es más formal Es una realización del diseño del sistema Debe ser mantenido durante todo el ciclo de vida del software Da forma al sistema 1

2 Etapas: 3 Diseño 3.1 Diseñar la Arquitectura Identificar nodos y configuraciones: modelo de despliegue Identificar clases relevantes 3.2 Diseñar CU Identificar clases de diseño: diagrama de clases de diseño Interacciones entre objetos: diagrama de secuencia 3.3 Diseñar Clases de Diseño Identificar operaciones Identificar atributos Identificar relaciones Identificar estados 3.4 Diagrama de Clases de Diseño completo 3 Diseño 3.1 Diseñar la Arquitectura Identificar nodos y configuraciones: modelo de despliegue Se describe la distribución física del sistema en términos de nodos (ordenadores). Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Es por ello que se deben tener en cuenta los siguientes puntos para el desarrollo del modelo de despliegue: Todos los actores del CU interactuarán con el sistema en el mismo sitio físico? Qué requerimientos de computación necesito en cada nodo? Qué tipo de conexiones o red existe entre los nodos? Qué protocolos manejan? Cuáles son sus características? Tengo requisitos del tipo Copias Redundantes para caso de fallos? Copia de seguridad de BBDD? 2

3 Entre los nodos intervinientes y los actores se debe indicar la cardinalidad correspondiente. Características de los Diagramas de Despliegue Un Nodo es un elemento de hardware o software y un componente describe un elemento físico del sistema (muestra las opciones de realización incluyendo código fuente, binario y ejecutable). A continuación se muestra un ejemplo de un modelo de Despliegue para un Sistema de Compras Interbancario. 3

4 3.1.2 Identificar clases relevantes De las clases de análisis encontradas se identifican los siguientes tipos de clases: Clases Activas, que necesiten estar ejecutándose concurrentemente. Se suelen identificar observando la distribución del sistema en nodos. Debe existir al menos un objeto activo por cada nodo. Tienen uno o más procesos por lo que pueden dar lugar a actividades de control. Clases relacionadas con las comunicaciones entre nodos 3.2 Diseñar CU Identificar clases de diseño: diagrama de clases de diseño Establece las clases de diseño que permiten implementar las clases de análisis teniendo en cuenta el modelo de despliegue. Estudiar los requisitos especiales (de rendimiento, de memoria, de diseño) de las clases de análisis, e identificar clases de diseño necesarias. Es decir consiste en derivar las clases de diseño de las correspondientes clases de análisis que participan en el CU. Estudia los requerimientos especiales del CU realizados con los mecanismos genéricos de diseño o con clases de diseño. Asigna responsabilidades a las clases identificadas, realizando un diagrama de clases que muestre las clases de diseño que intervienen en la realización del CU y las relaciones entre ellas. Para desarrollar esta identificación se escribe un cuadro de tres columnas para cada CU en donde, en la primera columna se indican las clases de análisis que se encontraron en dicha etapa, en la segunda columna se indican las clases de diseño resultante teniendo en cuenta que pueden presentarse las siguientes alternativas: 1) Que la clase de diseño se mantenga de la clase de análisis original 2) Que la clase de diseño desaparezca debido a que es absorbida por otra clase de diseño 3) Que aparezca una nueva clase de diseño ( inclusión ) debido a que es necesaria para poder realizar correctamente el diseño del CU En la tercera columna Requisito de Diseño cuando corresponde se coloca la justificación del porqué de la elección de las clases de diseño de la segunda columna. Por último con esta tabla se procede a realizar el Diagrama de las Clases de Diseño en base al Diagrama de Colaboración del Análisis, trabajando obviamente con las Clases de Diseño del cuadro comparativo colocando la cardinalidad correspondiente. 4

5 A continuación se muestra un ejemplo para un CU Dispensar Películas analizando las clases de diseño y obteniendo a partir de ellas el Diagrama de Clases de Diseño Interacciones entre objetos: diagrama de secuencia Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y los mensajes intercambiados entre los objetos. El diagrama de Secuencia consta de objetos, representados del modo usual: rectángulos con nombres subrayados, mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiempo representado por una progresión vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama. La extensión que está debajo 5

6 (y en forma descendente) de cada objeto será una línea discontinua conocida como la línea de vida de un objeto. Junto con la línea de vida de un objeto se encuentra un pequeño rectángulo conocido como activación, el cual representa la ejecución de una operación que realiza el objeto. La longitud del rectángulo se interpreta como la duración de la activación. Los envíos de mensajes se representan mediante flechas horizontales que unen la línea de vida del objeto emisor con la línea de vida del objeto destinatario. En cada flecha se pone el nombre del acontecimiento que provoca el envío del mensaje, y se puede acompañar de datos entre paréntesis. Existen diferentes tipos de envíos de mensajes: Simple: es la transferencia del control de un objeto a otro. Síncronos: son los más utilizados. El emisor del mensaje debe esperar a que el destinatario finalice el método mencionado antes de continuar su actividad. Asíncrono: el emisor no espera al destinatario para poder realizar otras acciones (sistemas multi-thread). El diagrama representa al tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que esté más cerca de la parte superior ocurrirá antes que uno que esté cerca la parte inferior. Con ello el diagrama de secuencias tiene dos dimensiones. La dimensión horizontal es la disposición de los objetos, y la dimensión vertical muestra el paso del tiempo. A continuación se muestra un ejemplo de un diagrama de Secuencia de un CU Realizar Encuesta. 6

7 3.3 Diseñar Clases de Diseño Identificar operaciones o métodos Consiste en detallar cuáles son las operaciones que realizarán las clases de diseño, las mismas pueden surgir de: Identificar los mensajes que se debe responder con el Diagrama de Secuencia Analizar las responsabilidades de la clase de análisis de la que deriva. A menudo implican una o varias operaciones Contemplar los requisitos especiales de la clase de análisis de la que deriva, por ejemplo el acceso a un gestor de BBDD Añadir la visibilidad de cada operación Usar la sintaxis del lenguaje de implementación a utilizar Se debe tener en cuenta que las operaciones de la clase de diseño necesitan soportar todos los roles que la clase desempeña en las diferentes realizaciones del CU. Películas. A continuación se muestra un ejemplo de métodos las clases de un CU Dispensar Identificar atributos Se distinguen los atributos que tendrán las clases, para ello se tiene en cuenta que: Los atributos deben ser los requeridos para realizar sus operaciones Hay que tener en cuenta los atributos obtenidos en la fase de Análisis Los tipos de atributos se restringen a los tipos disponibles en el lenguaje de programación a usar Hay que reutilizar los tipos de atributos Si una clase de diseño resulta compleja por culpa de sus atributos, se pueden agrupar atributos en clases independientes 7

8 A continuación se muestra un ejemplo de atributos para las clases Ficha Cliente y Tarjeta Crédito del CU Dispensar Películas Identificar relaciones Se distinguen las Asociaciones, Agregaciones y Generalizaciones, teniendo en cuenta para el mismo: Estudiar el diagrama de secuencias y ver qué asociaciones o agregaciones son necesarios Agrupar objetos en agregaciones para mandarles mensajes a todos ellos Estudiar asociaciones creadas en la fase de análisis Si el lenguaje de programación no soporta el mecanismo de generalización o herencia se deben emplear los mecanismos de asociación y agregación Películas. A continuación se muestra un ejemplo de relaciones para el CU Dispensar Identificar estados Algunos objetos del diseño son estados controlados, lo que determinan su comportamiento cuando reciben un mensaje, utilizándose un Diagrama de Estado para describir las diferentes transiciones de estado de un objeto del diseño. En consecuencia cada Diagrama de Estado es una entrada de valor para la implementación de la correspondiente clase de Diseño. Factura. A continuación se muestra un ejemplo de un Diagrama de Estado para una clase 8

9 3.4 Diagrama de Clases de Diseño Completo Simplemente se completa el Diagrama de Clases obtenido anteriormente en el punto agregándole los métodos, atributos y relaciones. A continuación se muestra un ejemplo de una clase Factura con sus atributos y métodos; relacionados con una clase Cuenta. Bibliografía Recomendada: El Proceso Unificado de Desarrollo de Software. De Gustavo Torossi. Pág:40:53 El Proceso Unificado de Desarrollo de Software De Ivar Jacobson, Grady Booch y James Rumbaugh. Capítulo 9, 10 y 11. Pág.: 165:199 Métrica 3. Técnicas y Prácticas. Ministerio de Administraciones Públicas. De Alarcos. 9