Tema 8 Clase 8 Proceso Unificado - Diseno

Vista previa del material en texto

CLASE 8
MODELO DE DESARROLLO DE PROGRAMAS Y PROGRAMACION 
CONCURRENTE – 2.019
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.
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 1 estructura p/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 
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: diagr.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
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 1tipo 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 requis.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.
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
3.1.2 IDENTIFICAR CLASES RELEVANTES
De las clases de análisis encontradas se identifican los siguientes tipos de clases:
• Clases Activas: q necesitan 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 1 o más procesos x lo q pueden dar lugar a actividades de control.
• Clases relacionadas con las comunicaciones entre nodos
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 1diagr.de clases q muestre 
las clases de diseño que intervienen en la realización del CU y las relaciones entre ellas.
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Se escribe 1cuadro de 3 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) Q la clase de diseño se “mantenga” de la clase de análisis original
2) Q la clase de diseño “desaparezca” debido a q 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.
3.2DISEÑAR CU
3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Ej.de 1CU “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
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 obj., representados x: rectángulos con nombres subrayados, msjes.entre obj. 
represent.x líneas continuas con 1punta de flecha y el tiempo represent. 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 msjes 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 msje, y se puede acompañar de datos entre paréntesis
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.
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 realizan 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 operac.
• Contemplar requis.especiales de clase de análisis de la q deriva, x ej.acceso a1gestor 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 IDENTIFICARATRIBUTOS
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 considerar:
• 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 program.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