Metodología Orientada a ObjetosClave 43100007Maestría en Sistemas Computacionales

Modulo 05UML: Vista de Interacción

1

UML: Vista de interacción

5.1 Descripción5.2 Diagramas de secuencia5.3 Diagramas de colaboración5.4 Realización de los casos de uso5.5. Modelo de diseño

2

5.1 Descripción

En esta vista los objetos obran recíprocamente para implementar comportamiento. Proporciona una vista integral del comportamiento de un sistema de objetos. Esta vista se modela por colaboraciones.

Las colaboraciones es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes unidos para realizar un cierto propósito.

El comportamiento es el conjunto de mensajes intercambiados por los objetos ligados, tal conjunto de mensajes es una colaboración se llama interacción. Una interacción modela la ejecución de una operación, caso de uso u otra entidad de comportamiento.

Un mensaje es una comunicación unidireccional entre objetos, un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores entre objetos.

El orden de los mensajes se pude mostrar en dos tipos de diagramas: Secuencia (se centra en las secuencias de tiempo de los mensajes) y colaboración (se centra en las relaciones entre objetos que intercambian mensajes).

Habitualmente un diagrama de colaboración capta el comportamiento de un solo caso de uso. EL diagrama muestra un cierto número de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso.

3

La creación de los casos de uso, modelos del dominio y otros artefactos, es más sencilla que la asignación de responsabilidades y la creación de diagramas de interacción bien diseñados; ya que en esta etapa se requiere la aplicación de las técnicas de diseño, en término de patrones, estilos y principios.

La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase.

Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes.

Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos de diagramas de interacción: el Diagrama de Colaboración (Conocido como Diagrama de Comunicación en la UML 2.0) y el Diagrama de Secuencia.

El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos.

El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos, muestra las relaciones entre

4

objetos y son mejores para comprender todos los efectos que tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede obtenerse automáticamente a partir del correspondiente diagrama de Secuencia (o viceversa).

5.2 Diagrama de Secuencia

Diagrama que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En particular muestra los objetos participantes en la interacción y la secuencia de mensajes intercambiados.

Representa una interacción, un conjunto de comunicaciones entre objetos organizadas visualmente por orden temporal. A diferencia de los diagramas de colaboración, los diagramas de secuencia incluyen secuencias temporales pero no incluyen las relaciones entre objetos. Pueden existir de forma de descriptor (describiendo todos los posibles escenarios) y en forma de instancia (describiendo un escenario real).

Dentro del conjunto de mensajes representados dispuestos en una secuencia temporal, cada rol en la secuencia se muestra como una línea de vida, es decir, una línea vertical que representa el rol durante cierto plazo de tiempo, con la interacción completa. Los mensajes se muestran como flechas entre líneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de transacción. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso.

5

Figura. Ejemplo de un diagrama de Secuencia

Un diálogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interacción. En general, el tiempo avanza hacia abajo dentro de la página (se pueden invertir los ejes si se desea). Con frecuencia sólo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una métrica. La ordenación horizontal de los objetos no tiene ningún significado.

Cada objeto representa una columna distinta, se pone un símbolo de objeto al final de la flecha que representa el mensaje que ha creado el objeto; está situada en el punto vertical que denota el instante en que

6

se crea el objeto. Esta se conoce como línea de vida del objeto. Se pone una X grande en el punto en que deja de existir el objeto o en el punto en que el objeto se destruye a sí mismo. Para el periodo durante el cual esté activo el objeto, la línea de vida se amplía para ser una línea doble continua. Si el objeto se llama a sí mismo, entonces se superpone otra copia de la doble línea para mostrar la doble activación. El orden relativo de los objetos no tiene significado aún cuando resulta útil organizarlos de modo que se minimice la distancia de las flechas.

Activación

Una activación es la ejecución de un procedimiento, incluyendo el tiempo de espera a los procedimientos anidados para ejecutarse. Se representa con una línea doble que sustituye la línea de vida de un diagrama de secuencia. Una llamada se representa con una flecha que apunta a la parte superior de la activación iniciada por la llamada.

En estos diagramas puede mostrarse también la auto delegación, que es un mensaje que un objeto se envía a sí mismo; regresando la flecha del mensaje de vuelta a la misma activación.

Dos partes de la información de control para estos diagramas son valiosos, la primera la condición que indica cuándo se envía un mensaje, por ejemplo: [necesitaReorden] este mensaje se envía solo sí la condición es verdadera. El segundo marcador de control útil es la iteración, que muestra que un mensaje se envía varias veces a varios objetos receptores. La base de la iteración se muestra entre corchetes, como *[para cada línea de pedido]

Los diagramas incluyen un regreso, para cada mensaje enviado al objeto receptor, los regresos difieren de los mensajes normales en que

7

la línea es punteada y con puntas de flecha tipo pluma. Considere que algunas veces los regresos saturan el diagrama y tienden a oscurecer el flujo, a veces los regresos son obvios en el diagrama y no hay necesidad de ponerlos, úselos solo cuando ayuden a mejorar la comunicación en el diagrama.

Foo Bar

1 : calcular()[color = rojo]

Figura. Diagrama de Secuencia parcial con mensaje condicional

A B C

: Cajero1 : mensaje1() 2 : calcular()[ x < 10 ]

[ x > 15 ] 3 : Calcular()

Figura. Diagrama de Secuencia parcial con mensajes condicionales Mutuamente excluyentes

8

Simulador Aleatorio

: Cajero1 : ejecutarSimulacion()

2 : calcular()[i:=1..N]

Figura. Diagrama de Secuencia parcial con iteración paraUn objeto

Cada mensaje se representa mediante una flecha horizontal que va desde la línea de vida del objeto que envió el mensaje hasta la línea de vida del objeto que ha recibido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo.

Para un flujo de objeto asíncrono entre objetos activos, los objetos se representan mediante líneas dobles continuas y los mensajes se representan como flechas. Se pueden enviar simultáneamente dos mensajes pero no se pueden recibir simultáneamente porque no se puede garantizar una recepción simultánea.

Las bifurcaciones se muestran partiendo la línea de vida del objeto. Cada bifurcación puede enviar y recibir mensajes. Eventualmente las líneas de vida del objeto tienen que fusionarse de nuevo.

9

Iteracionsd

Simulador Aleatorio Programador

: Cajero

1 : ejecutarSimulacion()2 : calcular()

3 : estimar()

4 : procesar()

*[i:=1..N]

Figura. Diagrama de Secuencia parcial con iteración paraUn grupo de objetos

10

Figura. Ejemplo de un diagrama de Secuencia

Un diagrama de secuencia también se puede mostrar en forma de descriptor, en el cual los constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola ejecución del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados porque los símbolos denotan roles y no objetos individuales.

- Ver Guía Diagrama de Secuencia(Se envía por buzón de transferencia)

11

5.3 Diagrama de Colaboración

La segunda forma del diagrama de iteración es el diagrama de colaboración; en estos diagramas los objetos ejemplo se muestran como iconos, las flechas indican los mensajes enviados dentro del caso de uso dado, en este diagrama las secuencias se indican numerando los mensajes. Este diagrama muestra mejor como se vinculan los objetos en un comportamiento específico.

Figura. Diagrama de Colaboración: realizarPago Notación

Enlaces

Un enlace es el camino de conexión entre dos objetos; indica que es posible alguna forma de navegación y visibilidad entre los objetos. De manera forma un enlace es una instancia de una asociación. (En el diagrama anterior los enlaces son las líneas que unen a los objetos)

Mensajes

Cada mensaje entre objetos se representa con una expresión de mensaje y una pequeña flecha que indica la dirección el mensaje;

12

podrían fluir muchos mensajes a lo largo de ese enlace. Se añade un número de secuencia para mostrar el orden secuencial de los mensajes en el hilo de control actual.

Mensaje a “self” o “this”

Son mensaje que se envía un objeto a sí mismo, esto se representa mediante un enlace a sí mismo, con mensajes que fluyen a lo largo del enlace.

Creación de instancias

Cualquier mensaje se pude utilizar para crear una instancia, pero en UML existe la convención de utilizar para este fin el mensaje denominado create. Si se utiliza otro nombre para este fin se puede añadir el estereotipo <<create>> al mensaje.

Secuencias de números

El orden de los mensajes se presenta mediante números de secuencia. El esquema de numeración es:

• No se enumera el primer mensaje• El orden y anidamiento de los mensajes se muestran con el esquema de numeración válido, en el que los mensajes anidados tiene un número adjunto. El anidamiento se denota anteponiendo el número de mensaje entrante al número de mensaje saliente.

13

Figura. Diagrama de Colaboración conNumeración compleja

Mensajes condicionales

Un mensaje condicional se muestra con una cláusula condicional, similar a una cláusula de iteración, el mensaje sólo se envía si la evaluación de la cláusula es verdad. Cuando se trata de mensajes condicionales mutuamente exclusivos, se modifican las expresiones de secuencias con una letra de camino condicional. La primera letra que se utiliza es la letra “a”.

14

Figura. Diagrama de Colaboración conMensaje Condicional

Figura. Diagrama de Colaboración conMensaje Condicionales mutuamente exclusivos

Iteración o bucle

La notación de las iteraciones se muestra en el diagrama siguiente. Si los detalles de la cláusula de iteración no son

15

importantes para el modelador, se pude utilizar simplemente un “*”.

Figura. Diagrama de Colaboración conIteración

Hay notación adicional en estos diagramas, sin embargo, no olvide que su belleza reside la simplicidad y muchas de las notaciones adicionales lo echan a perder en su intento por ser completos desde el punto de vista computacional. Un consejo útil, es que no se precipite queriendo usar formas complejas del los diagramas de interacción, encontrara que lo más simple tiene un valor superior.

Un problema típico en los proyectos de tecnología OO es que no se aprecia el valor de llevar a cabo el diseño de los objetos mediante el uso de diagramas de interacción; usualmente se hacen de manera vaga, como mostrando mensajes hacia objetos que realmente necesitan mucha elaboración adicional.

Lo que es importante es saber cómo pensar y diseñar en objetos, que es muy diferente y una capacidad más importante, que conocer la notación de los diagramas UML. Los diagramas de interacción desde el punto de vista del diseño, son los más importantes, y requieren

16

el mayor grado de esfuerzo creativo; la creación de estos diagramas requiere la aplicación de los principios de responsabilidades y el uso de los principios de patrones de diseño.

Ver. Guía Diagrama de Comunicación (Se envía por buzón de transferencia)

5.4 Realización de los Casos de Uso

Una realización de casos de uso, describe cómo se realiza un caso de uso particular en el modelo de diseño, en función de los objetos que colaboran. De manera más precisa. Un diseñador puede describir el diseño de uno o más escenarios de un caso de uso; cada uno de estos se denomina una realización del caso de uso. La realización del caso de uso es un término o concepto del UP que se utiliza para recordarnos la conexión de los requisitos expresados como casos de uso y el diseño de objetos que satisface los requisitos.

Los diagramas de interacción de UML son un lenguaje común para ilustrar las realizaciones de los casos de uso. No olvide que existen patrones de diseño que se pueden aplicar durante este trabajo de diseño.

17

Los casos de uso sugieren eventos del sistema que se muestran explícitamente en los diagramas de secuencia.

Opcionalmente, podrían describirse los efectos de los eventos del sistema en términos de los cambio de los objetos del dominio en los contratos de las operaciones del sistema.

Los eventos del sistema representan los mensajes que inician los diagramas de interacción, los cuales presentan el modo de los objetos del dominio en los contratos de las operaciones del sistema.

Los diagramas de interacción comprenden la interacción de los mensajes entre los objetos cuyos nombres se inspiran algunas veces en los nombres de las clases conceptuales del modelo del dominio; además de otras clases de objetos.

Ver. Guía Realización de casos de uso (Se envía por buzón de transferencia)

5.5 Modelo de diseño

El Modelo del diseño es un modelo de objetos que describe la realización de los casos de uso y sirve como una abstracción del modelo de implementación y el código fuente. El modelo de diseño se utiliza como insumo esencial a las actividades de implementación y pruebas.

Ver. Guía Modelo de diseño (Se envía por buzón de transferencia)

18

Bibliografía

1. Shari Lawrence Pfleeger, Joanne M. Atlee “Software Engineering ,Theory and Practice”, Thrid Edition, Pearson, Prentice Hall

2. Craig Larman, “UML y Patrones, Una introducción al análisis y diseño orientado a objetos y al proceso unificado”, Segunda Edición, Pearson, Prentice Hall.

3. Eric j. Fraude, “Ingeniería de Software, Una perspectiva orientada a objetos”, Alfaomega.

4. James Rumbaugh, Ivar Jacobson y Grady Booch, “El lenguaje Unificado de Modelado, Manual de Referencia“, Addison Wesley

5. Martin Flower con Kendall Scout, “UML gota a gota”, Pearson Addison Wesley6. Ian Sommerville, “Ingeniería de Software”, Sexta Edición, Addison Wesley, 2002,

ISBN:970-26-0206-8. 7. Joseph Schmuller, “Apendiendo UML en 24 horas”, Prentice Hall

Referencias Adicionales1. Hans van Vliet, “Software Engineering: Principles and Practice”, segunda edición,

John Wiley & Sons, 2001.2. Pankaj Jalote, “An Integrated Approach to Software Engineering”, segunda edición,

Springer, 1997.3. Alan Shalloway, James R. Trott, “Design Patterns Explained: A New Perspective

on Object-Oriented Design”, Addison-Wesley, 2002.4. Erich Gamma et al, “Design Patterns, Elements of Reusable Object-Oriented

Software”, Addison-Wesley, 1994.5. John Vlissides, “Patterns Hatching: Design Patterns Applied”, Addison-Wesley,

1998.6. Frank Armour, Granville Miller, “Advanced Use Case Modeling”, Addison Wesley,

2000.

19