Tema 5 - Diseño Detallado

Ingeniería del Software II 2011
Tema 5. Diseño detallado.
Diseño del Software.
Los requisitos y el análisis orientado a objetos se centran en aprender a hacer lo correcto:

Entender los objetos de nuestro sistema.

Reglas y restricciones relacionadas.
Las primeras iteraciones de las fases del inicio y elaboración centran su trabajo en esta labor.
Las siguientes iteraciones centran su trabajo en el diseño de una solución en función de
objetos software que colaboran.
En cada iteración tendrá lugar una transición desde los requisitos hacia el diseño y la
implementación, con retroalimentación constante.
Lo esencial de esta actividad es la creación de diagramas de interacción que representan el
modo en el que los objetos colaboran.
Después de esto, o al mismo tiempo, se desarrollan los diagramas de clases (del diseño),
resumen de la definición de las clases software que se van a implementar.
Estos artefactos forman parte en el PU del Modelo de Diseño.
Requieren mayor esfuerzo creativo y la aplicación de principios de asignación de
responsabilidades (patrones de diseño).
Diagramas de interacción.
Los diagramas de interacción

Expresan gráficamente cómo interactúan los objetos a través de mensajes.

Modelan aspectos dinámicos.
Dos tipos, diagrama de secuencia y diagrama de colaboración:

Ordenación temporal.

Organización estructural.
Ambos son semánticamente equivalentes e implican modelar instancias concretas junto con
los mensajes dentro de un escenario que ilustra el comportamiento.
1
Elementos de los diagramas de interacción.

Objetos. Rectángulo etiquetado: nombreobjeto : nombreclase

Objetos anónimos. Etiquetados con: nombreclase (No es necesario un objeto por cada
clase del sistema y puede haber más de dos objetos de la misma clase).

Enlaces. Es una instancia de una asociación, debe tener su correspondencia en el
modelo de clases. Sólo son relevantes (navegabilidad, nombres)

Actores. Como en los casos de uso, correspondencia.

Mensajes. Es la especificación de una comunicación entre objetos que transmite
información, con la expectativa de que desencadenará una actividad. A lo largo de un
mismo enlace pueden fluir múltiples mensajes y en ambas direcciones.
Funcionamiento de los objetos:

Normalmente hay un objeto en tratamiento.

Un objeto empieza a ejecutar sentencias cuando recibe un mensaje: tiene una
activación existente.

Puede responder a ese mensaje o enviar otros.

Si envía un mensaje no puede continuar con el cálculo hasta que se le responda
(mensaje síncrono).

En cualquier momento hay una pila de activaciones existentes.

El objeto de la cima puede enviar un mensaje o responder, si responde desaparece de
la pila, el siguiente objeto asociado a la nueva cima recupera el control.
Sintaxis de la expresión de mensaje básica:
Resultado := nombre(parámetro:tipoParámetro):tipoRetorno

Resultado. Está constituido por el valor o los valores devueltos por el mensaje, puede
omitirse.

Nombre. Es el nombre del mensaje que generalmente corresponde a una operación
definida en la clase del objeto destinatario.

Parámetro. Valor que se le pasa a la operación por algún motivo, normalmente
definido por el programador.
2
Otros componentes:

Fecha.

Número de secuencia (diagramas de colaboración)

Condiciones, caminos mutuamente exclusivos, iteración.
Diagramas de Colaboración y Secuencia.
Los diagramas de colaboración enfatizan la organización estructural de los objetos que envían
y reciben mensajes.

Representan las interacciones entre las instancias del modelo en forma de grafo o red.

Economizan espacio al poder añadir objetos en las dos dimensiones.

Mejoran la visibilidad de las iteraciones, bifurcaciones y concurrencias.
Los diagramas de secuencia muestran las interacciones entre objetos desde un punto de vista
temporal.

Formato con aspecto de valla.

Notación más simple.
Diagramas de Colaboración.
 El primer mensaje es uno de los mensajes externos del DSS:
 Para expresar la devolución de valores:
 Mensaje a sí mismo:
3
 Número de secuencia y trayectorias mutuamente excluyentes (condición):
 Crear instancia y agregación a un multiobjeto:
 Iteraciones:
 Enviar mensaje a una clase: poner nombre de clase sin subrayar.
4
Diagramas de Secuencia.
Diagramas de Interacción y PU.
Son la forma de ilustrar las realizaciones de los casos de uso, es decir, describen como se
realiza un caso particular en función de los objetos que colaboran.
En el Proceso Unificado del Desarrollo del Software (PU):

Inicio. Normalmente no hay diagramas de interacción en esta fase.

Elaboración. Para los escenarios más significativos o de más riesgo.

Construcción. Para el resto de problemas de
diseño.
Diagramas de Clases.
Algunos de los objetos software que interactúan
mediante el paso de mensajes se inspiran en el Modelo
de Dominio, las clases conceptuales inspiran las clases de
diseño y se reduce el salto en la representación.
Las clases software incorporan métodos, aquellos que
indican los mensajes intercambiados en los diagramas de
interacción.
También incorporan la visibilidad, la capacidad de un
objeto de ver o tener una referencia a otro objeto, poder
5
enviarle un mensaje.
Ejemplo: A tiene visibilidad de B de:
1.
2.
3.
4.
Atributo. B es atributo de A.
Parámetro. B es un parámetro de un método de A.
Local. B es un objeto local de un método de A.
Global. B es de algún modo visible globalmente para A.
Elementos de los diagramas de Clases.
Algunas consideraciones sobre los métodos:

El método create se utiliza en UML para indicar instanciación e inicialización. Es
habitual omitir en los Diagramas de Clases de Diseño (DCD) los métodos de creación y
constructores.

Los métodos de acceso que recuperan o establecen los valores de los atributos (get y
set) se excluyen.

Los métodos a multiobjetos no forman parte de la clase de los objetos, son de la
colección y por lo tanto tampoco se muestan.
Opcionalmente se pueden mostrar todos los tipos de los atributos, parámetros de los métodos
y los valores de retorno si se está creando en una herramienta CASE con generación
automática de código pero para desarrolladores de software humanos puede ser negativo por
el “nivel de ruido introducido”.
6
Se puede añadir la flecha de navegabilidad que implica visibilidad aunque normalmente se
transforma en un atributo en la clase origen que referencia a una instancia de la clase
destino.
Se muestran las asociaciones necesarias para satisfacer la visibilidad.
El diagrama de clases resultante no muestra las mismas asociaciones que el Modelo de
Dominio.
También se pueden mostrar relaciones de dependencia para otros tipos de visibilidad.
Diagramas de clases y PU.
Las herramientas CASE pueden hacer ingeniería inversa y los Diagramas de Clases de Diseño
(DCD) se pueden generar a partir del código fuente.
En el Proceso Unificado del Desarrollo del Software (PU):

Inicio. Los Diagramas de Clases de Diseño (DCD) no se realizan, son prematuros.

Elaboración. Los DCD acompañan a los de interacción de las realizaciones de los casos
de uso.

Construcción. Los DCD se siguen generando a partir del código fuente como apoyo a la
visualización estática del sistema.
7