UML - Diagramas de interacción

[ Home > Apuntes Tácticos > UML ]


Mapa General

UML

Resumen

Los diagramas de interacción son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento.

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


Arriba

Índice de Contenidos


Introducción

Los diagramas de interacción son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento.

Habitualmente, un diagrama de interacción capta el comportamiento de un solo caso de uso (Enlace Cap 03). El diagrama muestra cierto número de ejemplos de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso.

Ilustraré este enfoque mediante un caso de uso simple que exhibe el comportamiento siguiente:

Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.


Arriba

Diagramas de secuencia

En un diagrama de secuencia, un objeto se muestra como caja en la parte superior de una línea vertical punteada (véase la Figura 6-1.

Figura 06-01(11K)

Figura 6-1: Diagrama de secuencia

Esta línea vertical se llama línea de vida del objeto. La línea de vida representa la vida del objeto durante la interacción. Esta forma fue popularizada inicialmente por Jacobson.

Cada mensaje se representa mediante una flecha entre las líneas de vida de dos objetos. El orden en el que se dan estos mensajes transcurre de arriba hacia abajo. Cada mensaje es etiquetado por lo menos con el nombre del mensaje; pueden incluirse también los argumentos y alguna información de control, y se puede mostrar la autodelegación, que es un mensaje que un objeto se envía a sí mismo, regresando la flecha de mensaje de vuelta a la misma línea de vida.

Dos partes de la información de control son valiosas. Primero, hay una condición, que indica cuándo se envía un mensaje (por ejemplo, [necesitaReorden])(Se necesita reponer el almacen con articulos). El mensaje se envía sólo si la condición es verdadera. El segundo marcador de control útil es el marcador de iteración, que muestra que un mensaje se envía muchas veces a varios objetos receptores, como sucedería cuando se itera sobre una colección. La base de la iteración se puede mostrar entre corchetes (como en *[para cada línea de pedido]).

Como se puede apreciar, Figura 6-1 es muy simple y tiene un atractivo visual inmediato; en ello radica su gran fuerza.

Una de las cuestiones más difíciles de comprender en un programa orientado a objetos es el flujo de control general. Un buen diseño tiene muchísimos pequeños métodos en diferentes clases, y a veces resulta muy complicado determinar la secuencia global de comportamiento. Podrá acabar leyendo el código, tratando de encontrar dónde está el programa. Esto ocurre así, en especial, para todos aquellos que comienzan a trabajar con objetos. Los diagramas de secuencia le ayudan a ver la secuencia.

Este diagrama incluye un regreso, el cual indica el regreso de un mensaje, no un nuevo mensaje. Los regresos difieren de los mensajes normales en que la línea es punteada.

Los diagramas POSA (Buschmann et al., 1996), en los que se basa una gran parte de las anotaciones de la notación de gráficas de secuencia de UML, emplean ampliamente los regresos. Yo no lo hago así. He observado que los regresos saturan el diagrama y tienden a oscurecer el flujo. Todos los regresos se hallan implícitos por el modo como se secuencian los mensajes. Sólo utilizo regresos cuando aumentan la claridad del diagrama.

Mi consejo es mostrar los regresos cuando ayudan a aumentar la claridad. La única razón por la que usé un regreso en la Figura 6-1 fue para demostrar la notación; si se elimina el regreso, a mi juicio el diagrama continúa tan claro como antes.

En el UML 1.0 los regresos se indicaban mediante puntas de flecha tipo pluma, en lugar de líneas punteadas. Las he encontrado tan difíciles de implementar que de todas maneras he utilizado las líneas punteadas, de modo que me alegra ver el cambio.

Esto lo menciono, debido a que quisiera ofrecer aquí un pequeño consejo: evite ir en contra de la notación del UML. Esta notación se volverá cabalmente comprendida, y hacer algo fuera de la norma dañará la comunicación del diseñador con otros diseñadores. Sin embargo, si hay algo que esté causando una gran confusión, yo haría algo fuera de la norma. Después de todo, el propósito principal del diagrama es la comunicación. Si es que llega a romper las reglas del UML, hágalo muy de vez en cuando y defina con claridad lo que ha hecho.


Arriba

Procesos concurrentes y activaciones

Los diagramas de secuencia son valiosos también para los procesos concurrentes.

En la Figura 6-2 vemos algunos objetos que revisan una transacción bancaria.

Figura 06-02(11K)

Figura 6-2: Diagrama de Secuencia: Procesos y activaciones concurrentes

Cuando se crea una Transacción, ésta crea un Coordinador de transacción que coordina el trámite de la Transacción. Este coordinador crea una cantidad (en el presente caso, dos) de objetos Revisor de transacción, cada uno de los cuales es responsable de una revisión en particular. Este proceso permitirá añadir con facilidad otros procesos de revisión, porque cada registro es llamado asincrónicamente y opera en paralelo.

Cuando termina un Revisor de transacción, se lo notifica al Coordinador de transacción. El coordinador comprueba si todos los revisores respondieron; de no ser así, no hace nada. Si todos han respondido indicando terminaciones exitosas, como en el presente caso, entonces el coordinador notifica a la Transacción que todo está bien.

La Figura 6-2 introduce varios elementos nuevos en los diagramas de secuencia. En primer lugar, se ven las activaciones, que aparecen explícitamente cuando está activo un método, ya sea porque está efectuando operaciones o porque se encuentra esperando la devolución de una subrutina. Muchos diseñadores utilizan las activaciones todo el tiempo. A mi juicio, éstas no aportan mucho a la ejecución de procedimientos. Por tanto, sólo las uso en situaciones concurrentes.

Las medias cabezas de flecha indican mensajes asíncronos. Un mensaje asíncrono no bloquea al invocador, por lo cual puede continuar con su proceso. Un mensaje asíncrono puede hacer alguna de estas tres cosas:

  1. Crear un nuevo proceso, en cuyo caso se vincula con el principio de una activación.
  2. Crear un nuevo objeto.
  3. Comunicarse con un proceso que ya está operando.

El borrado (deletion) de un objeto se muestra con una X grande. Los objetos pueden auto destruirse (como se muestra en la Figura 6-2), o pueden ser destruidos mediante otro mensaje (véase la Figura 6-3).

Figura 06-03(13K)

Figura 6-3:Diagrama de secuencia: revisión de fallas

Texto de la imagen

Se pueden mostrar con más claridad las consecuencias de la autodelegación cuando se tienen activaciones. Sin ellas, o sin la notación de apilamiento que se usa aquí, es difícil decir dónde ocurrirán más llamadas tras una autodelegación: en el método invocador o en el invocado. Las activaciones de apilamientos dejan en claro este aspecto. Descubro que, en algunas ocasiones, ésta es una razón para utilizar activaciones en una interacción de procedimiento, aun cuando por lo común no uso las activaciones en estos casos.

Las Figuras 6-2 y 6-3 muestran dos de las situaciones del caso de uso de "revisión de transacciones". He dibujado cada situación por separado. Hay técnicas para combinar la lógica condicional en un solo diagrama, pero prefiero no usadas, ya que complican demasiado el diagrama.

En la Figura 6-3 me he servido de una técnica muy útil: he insertado descripciones textuales de lo que sucede en el lado izquierdo del diagrama de secuencia. Ello implica la alineación de cada bloque de texto con el mensaje apropiado dentro del diagrama. Esto ayuda a comprender el diagrama (a cambio de un poco de trabajo extra), y lo hago con aquellos documentos que conservaré, pero no con bosquejos desde cero.


Arriba

Diagramas de colaboración

La segunda forma del diagrama de interacción es el diagrama de colaboración.

En los diagramas de colaboración, los objetos ejemplo se muestran como iconos. Las flechas indican, como en los diagramas de secuencia, los mensajes enviados dentro del caso de uso dado. Sin embargo, en esta ocasión la secuencia se indica numerando los mensajes.

El numerar los mensajes dificulta más ver la secuencia que poner las líneas verticales en la página. Por otra parte, la disposición espacial del diagrama permite mostrar otras cosas mejor. Se puede mostrar cómo se vinculan entre ellos los objetos y emplear la disposición para sobre poner paquetes u otra información.

Se puede usar alguno de los diversos esquemas de numeración para los diagramas de colaboración. El más simple se ilustra en la Figura 6-4. Otro enfoque comprende un esquema de numeración decimal, el cual aparece en la Figura 6-5.

En el pasado, el esquema más utilizado era el de la numeración simple. El UML utiliza el esquema decimal, pues hace evidente qué operación llama a otra y cuál es esa otra, aunque pueda ser más difícil apreciar la secuencia general.

Figura 06-04(10K)

Figura 6-4:Diagrama de colaboración con numeración simple

Sin importar el tipo de esquema de enumeración que se utilice, se puede añadir el mismo tipo de control de información que se mostraría en un diagrama de secuencia.

En las Figuras 6-4 y 6-5 se pueden apreciar las distintas formas del esquema de nombrado de objetos en UML. Tal esquema adopta la forma de nombreObjeto : NombreClase, donde se puede omitir el nombre del objeto o el de la clase. Obsérvese que, si se omite el nombre del objeto, hay que conservar los dos puntos (:), para que quede claro que es el nombre de la clase y no el del objeto. Así, el nombre "Línea Macallan : Línea de pedidos" indica una instancia de Línea de pedidos llamada Línea Macallan (debo decir que éste es un pedido que yo apreciaría de modo particular). Acostumbro a nombrar objetos con el estilo de Smalltalk que empleé en los diagramas de secuencia (este esquema es válido en UML, pues "unObjeto" es un nombre perfectamente correcto para un objeto).

Figura 06-05(9K)

Figura 6-5: Diagrama de colaboración con numeración decimal


Arriba

Comparación de los diagramas de secuencia y de colaboración

Los diferentes desarrolladores tienen distintas preferencias cuando se trata de seleccionar la forma de diagrama de interacción que emplearán. Por lo general, yo prefiero el diagrama de secuencia, debido a que me gusta el énfasis que pone en la secuencia; es fácil apreciar el orden en el que ocurren las cosas. Otros, en cambio, prefieren el diagrama de colaboración, porque pueden usar la distribución para indicar cómo se conectan estáticamente los objetos.

Una de las características principales de ambos tipos de diagrama de interacción es su simplicidad. Se pueden ver con facilidad los mensajes mirando tan sólo el diagrama. Sin embargo, si trata de representar algo más que un simple proceso secuencial, sin mucho comportamiento condicional o de ciclos, la técnica comienza a fallar.


Arriba

El comportamiento condicional

¿Cuál es el mejor modo de mostrar el comportamiento condicional?

Existen dos escuelas de pensamiento. Una consiste en usar diagramas separados para cada situación. La otra consiste en emplear condiciones en los mensajes, a fin de indicar el comportamiento.

Yo prefiero la primera. Los diagramas de interacción están en su mejor forma cuando su comportamiento es simple. Rápidamente pierden su claridad con un comportamiento más complejo. Si quiero captar una conducta complicada en un diagrama simple, prefiero utilizar un diagrama de actividades.

El UML ofrece mucha sintaxis adicional para los diagramas de secuencia, la cual se basa en los patrones del equipo de Siemens (Buschmann et aL, 1996). No entraré aquí en los detalles, ante todo debido a que no me satisface la complejidad que provoca. Para mí, la belleza de los diagramas de interacción reside en su simplicidad y muchas de las notaciones adicionales la echan a perder en su intento por ser completos desde el punto de vista computacional. Le aconsejo que no se precipite utilizando las formas más complejas de los diagramas de interacción, pues quizá encuentre que los más simples tienen un valor superior.


Arriba

Cuándo utilizar los diagramas de interacción

Se deberán usar los diagramas de interacción cuando se desee ver el comportamiento de varios objetos en un caso de uso. Son buenos para mostrar la colaboración entre los objetos; sin embargo, no sirven tan bien para la definición precisa del comportamiento.

Si desea ver el comportamiento de un solo objeto a través de muchos casos de uso, use un diagrama de estado de transición. Si quiere ver el comportamiento a través de muchos casos de uso o muchos procesos, considere un diagrama de actividad.


Arriba

Para mayor información



Arriba

Índice


Arriba

Referencia Bibliográfica

Fowler, Martín
UML, gota a gota
Addison Wesley Longman de México,SA de CV
México 1.999
ISBN: 968-44-364-1
Formato 17x23
Paginas 224


Atrás arriba Adelante

© 2.003 - La Güeb de Joaquín - Apuntes Tácticos - UML
[Arriba] [Home] [Apuntes] [UML] [Correo]
La documentación es como el sexo: cuando es bueno, es muy,
muy bueno; y cuando es malo, es mejor que nada.
Fecha de la última actualización.:  18 / Septiembre / 2003
Esta página es española