CLASE 7

MODELO DE DESARROLLO DE PROGRAMAS Y PROGRAMACION

CONCURRENTE – 2.023-
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
Modelo de ANALISIS Modelo de DISEÑO
Es un modelo conceptual y genérico, Es un modelo físico y concreto, es un
es una abstracción del sistema plano de la implementación

Es menos formal Es más formal

Es un bosquejo del diseño del sistema Es una realización del diseño del sistema

Puede no mantenerse durante todo el Debe ser mantenido durante todo el

ciclo de vida del SW ciclo de vida del SW

Define 1 estructura p/modelar el sist Da forma al sistema

3 Diseño DISEÑO (UML) - ETAPAS
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 interactuan 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.1 DISEÑAR LA ARQUITECTURA
3.1.1 IDENTIFICAR NODOS Y CONFIGURAC: MODELO DE DESPLIEGUE
Característ.de los Diagr.de Despliegue

Ej.de1modelo
de
Despliegue
p/un Sist.de
Compras
Interbancario

Ej.de1modelo
de
Despliegue
de teorías
anteriores

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).
3.1.2 IDENTIFICAR CLASES RELEVANTES
De las clases de análisis encontradas se identifican los siguientes tipos de clases:

• Clases Activas: 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.2 DISEÑAR CU 3.2.1 IDENTIFICAR CLASES DE DISEÑO: DIAGR.DE CLASES DE DISEÑO
Establece las clases de diseño q implementan las clases de análisis teniendo en cuenta el modelo de despliegue.
Estudia requis.especiales (rendim, mem, diseño) d las clases d 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 requerim.especiales del CU realizados con los mecanismos genéricos d 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.

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”)
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

Ej.de Diagrama
de Clases de
Diseño
3.2.2 INTERACCIONES ENTRE OBJETOS: DIAGR. DE SECUENCIA
Muestra la interacción d 1conj.de objetos a través del tiempo y se modela p/c/CU. Contiene detalles d implement.del
escenario, incluyendo los obj.y clases q se usan p/implementar el escenario y los msjes intercambiados entre los obj.
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 en la parte superior de izquierda a derecha y s acomodan de manera q simplifiquen el Diagr.
La extensión q está debajo (y en forma descendente) d c/obj.será 1línea discontinua conocida como línea d vida d
1obj. Junto con la línea de vida d 1obj.se encuentra un pequeño rectáng.conocido como activac, el cual representa
la ejecución de 1operación q realiza el objeto. La long.del rectáng.s interpreta como la duración d la activac.
Los envíos de msjes s representan con flechas horizontales q unen la línea de vida del obj.emisor con la línea d vida
del obj.destinatario. En c/flecha se pone el nombre del acontecimiento q provoca el envío del msje, y s puede
acompañar de datos entre paréntesis

Existen diferentes tipos de envíos de mensajes:

o Simple: es la transferencia del control de 1objeto a otro.
o 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.
o Asíncrono: el emisor no espera al destinatario p/poder realizar otras acciones (sist.multi-thread).
El diagr.representa al tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte
inferior. Un msje q esté + cerca d la parte superior ocurrirá antes q 1 q esté cerca la parte inferior. Con ello el diagr.de
sec.tiene 2dimensiones. La dimens.horizontal es la disposición de los objetos, y la dimens.vertical 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
Consiste en detallar las operaciones q realizan las clases de diseño, las mismas pueden surgir de:
• Identificar los mensajes q deben responderse 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
Las operac.d la clase de diseño
necesitan soportar todos los roles q la
clase desempeña en las diferentes
Ej.d mét.p/las clases de 1CU “Dispensar Películas”. realizaciones del CU.
 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

Ej.d atrib.p/las clases Ficha Cliente y Tarj.Crédito del CU “Dispensar Pelíc”

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 necesarias

• 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

Ej.d relac.p/el CU “Dispensar Películas”

 3.3.4 IDENTIFICAR ESTADOS
Algunos obj.del diseño son estados controlados, lo q determinan su comportamiento cuando reciben 1msje.
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
BIBLIOGRAFÍA RECOMENDADA

• 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.