Tema_8_Clase_7_Proceso_Unificado_-_Dise_o

Vista previa del material en texto

CLASE 6
MODELO DE DESARROLLO DE PROGRAMAS Y PROGRAMACION 
CONCURRENTE
FAC.DE INGENIERIA - UNJu
Proceso Unificado - DISEÑO
DISEÑO (UML)
El objetivo final del diseño es producir un Modelo Lógico del sistema a implementar.
Florencia
Resaltado
DIFERENCIA ENTRE ANALISIS Y DISEÑO DEL PROCESO UNIFICADO
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 SW
Define una estructura para modelar el sist
Modelo de ANALISIS Modelo de DISEÑO
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 SW
Da forma al sistema 
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
ANALISIS (UML) - ETAPAS3 Diseño
3.1 Diseñar la Arquitectura
3.1.1 Identificar nodos y configuraciones: 
modelo de despliegue
3.1.2 Identificar clases relevantes
3.2 Diseñar CU
3.2.1 Identificar clases de diseño: diagr.de clases de diseño
3.2.2 Interacciones entre objetos: diagrama de secuencia
3.3 Diseñar Clases de Diseño
3.3.1 Identificar operaciones
3.3.2 Identificar atributos
3.3.3 Identificar relaciones
3.3.4 Identificar estados
3.4 Diagrama de Clases de Diseño completo
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.1DISEÑAR LA ARQUITECTURA
3.1.1 IDENTIFICAR NODOS Y CONFIGURAC: MODELO DE DESPLIEGUE
Describe la distribución física del sist.en términos de nodos (ordenadores). Es un tipo de diagr.de UML q se 
utiliza p/modelar el HW de las implementaciones de sist. y las relaciones entre sus componentes. P/el 
modelo de Despliegue se debe tener en cta.:
• ¿Todos los actores del CU interactuarán con el sistema en el mismo sitio físico?
• ¿Qué requerimientos de computación necesito en c/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 p/caso de fallos? ¿Copia de seguridad de BBDD?
Entre los nodos intervinientes y los actores se debe indicar la cardinalidad correspondiente.
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.1DISEÑAR LA ARQUITECTURA
3.1.1 IDENTIFICAR NODOS Y CONFIGURAC: MODELO DE DESPLIEGUE
• Un Nodo es 1elemento de HW o SW. Un componente describe un elemento físico del 
Sist.(muestra las opciones de realización incluyendo código fuente, binario y ejecutable).
Características de los Diagramas de Despliegue
Ej.de1modelo de Despliegue p/un Sist.de Compras Interbancario
Florencia
Resaltado
3.1.2 IDENTIFICAR CLASES RELEVANTES
De las clases de análisis encontradas se identifican los siguientes tipos de clases:
• Clases Activas, q necesiten estar ejecutándose concurrentemente. Se suelen identificar 
observando la distribución del sist.en nodos. Debe existir al menos un objeto activo x c/nodo. Tienen 
uno o más procesos x lo q pueden dar lugar a actividades de control.
• Clases relacionadas con las comunicaciones entre nodos
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Establece las clases de diseño q permiten implementar las clases de análisis teniendo en cuenta el 
modelo de despliegue. Estudia los requisitos especiales (de rendimiento, de memoria, de diseño) de 
las clases de análisis, e identifica las 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 diagr.de clases q muestre las clases 
de diseño que intervienen en la realización del CU y las relaciones entre ellas.
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Se escribe un cuadro de tres columnas p/cada CU en donde, en la 1ra.columna se indican las clases 
de análisis q se encontraron en dicha etapa, en la 2da.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) Q aparezca 1nueva clase de diseño (“inclusión”) debido a q es necesaria p/poder realizar 
correctamente el diseño del CU
En la 3ra.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 2da.columna.
Con esta tabla se procede a realizar el Diagr.de las Clases de Diseño en base al Diagr.de Colaborac. 
del Análisis, trabajando con las Clases de Diseño del cuadro comparativo colocando la cardinalidad.
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
A continuación se muestra un ej.p/un CU “Dispensar Películas” analizando las clases de diseño y 
obteniendo a partir de ellas el Diagr.de Clases de Diseño
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Diagrama de 
Clases de 
Diseño
3.2.2 INTERACCIONES ENTRE OBJETOS: DIAGR. DE SECUENCIA
El Diagr.de Secuencia muestra la interacción de 1conj.de objetos en 1aplicación a través del tiempo y se 
modela p/cada CU. Contiene detalles de implementación del escenario, incluyendo los objetos y clases 
q se usan p/implementar el escenario y los mensajes intercambiados entre los objetos. 
Consta de objetos, representados x: rectángulos con nombres subrayados, mensajes entre los objetos 
representados x líneas continuas con 1punta de flecha y el tiempo representado x 1progresión vertical.
Los objetos se colocan cerca de la parte superior de izquierda a derecha y se acomodan de manera q 
simplifiquen el Diagr. La extensión q está debajo (y en forma descendente) de c/objeto será 1línea 
discontinua conocida como la línea de vida de 1objeto. Junto con la línea de vida de 1objeto se 
encuentra un pequeño rectángulo conocido como activación, el cual representa la ejecución de 
1operación q realiza el objeto. La long.del rectángulo se interpreta como la duración de la activación.
Los envíos de mensajes se representan mediante flechas horizontales q unen la línea de vida del objeto 
emisor con la línea de vida del objeto destinatario. En c/flecha se pone el nombre del acontecimiento q 
provoca el envío del mensaje, y se puede acompañar de datos entre paréntesis.
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.2.2 INTERACCIONES ENTRE OBJETOS: DIAGR. DE SECUENCIA
Existen diferentes tipos de envíos de mensajes: 
Simple: es la transferencia del control de 1objeto a otro.
Síncronos: son los + utilizados. El emisor del mensaje debe esperar a q el destinatario finalice el 
método mencionado antes de continuar su actividad.
Asíncrono: el emisor no espera al destinatario p/poder realizar otras acciones (sist.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é + 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.
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
Florencia
Resaltado
3.2.2 INTERACCIONES ENTRE OBJETOS: DIAGR. DE SECUENCIA
Ej.de 1 
Diagr.de
Secuencia de 
1 CU “Realizar 
Encuesta”
3.3 DISEÑAR CLASES DE DISEÑO
3.3.1 IDENTIFICAR OPERACIONES O MÉTODOS
Las operaciones de la clase de 
diseño necesitan soportar todos los 
roles q la clase desempeña en las 
diferentes realizaciones del CU.
Consiste en detallar las operaciones q realizarán las clases de diseño, las mismas pueden surgir de:
• Identificar los mensajes q se debe responder con el Diagr.de Secuencia
• Analizar las responsabilidades de la clase de análisis de la q deriva. Implican 1 o varias operaciones
• Contemplar requisitos especiales de la clase de análisis de la q deriva, x ej.el acceso a un gestor de BBDD
• Añadir la visibilidad de c/operación
• Usar la sintaxis del leng.de implementación a utilizar
Ejemplo de métodos las clases de un 
CU “Dispensar Películas”.
3.3.2 IDENTIFICAR ATRIBUTOS
Se distinguen los atributos q tendrán las clases, p/ello se debe tener en cuenta q:
• Los atributos deben ser los requeridos p/realizar sus operaciones
• Hay q tener en cuenta los atributos obtenidos en la fase de Análisis
• Los tipos de atributos se restringen a los tipos disponibles en el leng.de programación a usar
• Hay q reutilizar los tipos de atributos
• Si 1clase de diseño resulta compleja x culpa de sus atrib., se pueden agrupar atrib.en clases 
independientes
Ejemplo de atributos para las clases 
Ficha Cliente y Tarjeta Crédito del CU 
“Dispensar Películas”
3.3.3 IDENTIFICAR RELACIONES
Se distinguen las Asociaciones, Agregaciones y Generalizaciones, se debe tener en cuenta:
• Estudiar el Diagr.de Secuencia y ver q asociaciones o agregaciones son necesarios
• Agrupar objetos en agregaciones p/mandarles mensajes a todos ellos
• Estudiar asociaciones creadas en la fase de análisis
• Si el leng.de programac.no soporta el mecanismo de generalización o herencia se deben 
emplear los mecanismos de asociación y agregación
Ejemplo de relaciones para 
el CU “Dispensar Películas”
3.3.4 IDENTIFICAR ESTADOS
Algunos objetos del diseño son estados 
controlados, lo q determinan su 
comportamiento cuando reciben 
1mensaje.
Se utiliza 1Diagr.de Estado p/describir las 
diferentes transiciones de estado de 
1objeto del diseño. En consecuencia 
c/Diagr.de Estado es 1entrada de valor 
p/la implementación de la 
correspondiente clase de Diseño.
Ejemplo de 1 
Diagr.de
Estado p/1 
clase Factura
• El Proceso Unificado de Desarrollo de Software. De Gustavo Torossi.
• El Proceso Unificado de Desarrollo de Software. 2000. 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.
BIBLIOGRAFÍA RECOMENDADA