Diagramas de secuencia: mostrar interacciones con UML

El diagrama de secuencia es un tipo de diagrama del lenguaje unificado de modelado (UML) que, a su vez, se trata de un lenguaje orientado a objetos y está compuesto por elementos gráficos. UML modela sistemas y procesos de la programación orientada a objetos así como procesos de negocio con el objetivo de presentar asuntos complejos de manera clara. Para ello, UML establece una notación estandarizada y recurre a formas visuales para representar un componente o comportamiento específico. El llamado metamodelado define las unidades lingüísticas y su significado dentro de UML y determina cómo pueden interactuar ciertos elementos entre sí y qué jerarquías existen entre las respectivas unidades lingüísticas.

En UML los elementos y las relaciones se representan en forma de diagramas. UML2 distingue entre 14 tipos de diagramas diferentes, que se ordenan en tres categorías distintas: diagramas de estructura, de comportamiento y de interacción.

• Los diagramas de estructura (structure diagrams) srepresentan un sistema y sus componentes de forma estática. Establecen las relaciones que existen entre elementos individuales o entre elementos y conceptos superiores. Un ejemplo de ello es el diagrama de clase.
• Los diagramas de comportamiento (behavior diagrams) representan los procesos y el comportamiento de un sistema dinámicamente. A diferencia de los diagramas de estructura, la secuencia de procesos y, por lo tanto, el tiempo, desempeñan un papel importante en la visualización. Un ejemplo de este tipo de diagramas es el diagrama de actividad.
• Los diagramas de interacción (interaction diagrams) pertenecen a la categoría de diagramas de comportamiento. Se enumeran por separado porque modelan un comportamiento específico, es decir, las interacciones entre los elementos del sistema. Los elementos básicos de las interacciones son las llamadas líneas de vida. Estas consisten en objetos (los bloques de construcción independientes más pequeños de la programación orientada a objetos) que representan a participantes individuales en una interacción. El diagrama de interacción más utilizado es el diagrama de secuencia.

El diagrama de secuencia UML representa los eventos en orden cronológico, razón por la que a veces se le llama diagrama de eventos o escenario de eventos. El orden (es decir, la secuencia exacta) es más importante que los puntos específicos en el tiempo. Sin embargo, es posible añadir restricciones al modelo con el que se está trabajando. Por ejemplo, una limitación de tiempo para un proceso en particular (introducir el PIN en un cajero automático) puede desencadenar un evento (se expulsa la tarjeta si pasado cierto tiempo no se ha introducido PIN alguno).

El diagrama de secuencia describe básicamente cómo los objetos (e instancias) intercambian mensajes en un orden determinado. Los objetos son los bloques de construcción básicos de los diagramas UML y representan ciertas características de un elemento del sistema, que varían dependiendo del diagrama. En las interacciones, los objetos son las conocidas como líneas de vida.

En un sistema se realizan solicitudes y se envían respuestas constantemente. El destinatario toma las decisiones en función de la solicitud específica y de sus propias reglas predefinidas. El entramado de posibles decisiones e interacciones suele estar representado por un diagrama de actividades. Si se representan todas las decisiones posibles (sí/no) como un diagrama de árbol, probablemente se obtendrá la imagen de una red fuertemente ramificada. No obstante, el diagrama de secuencia muestra solo una ruta específica dentro de esta red.

En concreto, el diagrama de secuencia se diferencia del diagrama de casos de uso de UML en su orden detallado. Si se va a introducir un nuevo proceso empresarial, el caso de uso proporciona una visión de conjunto de las necesidades. No obstante, si, por otra parte, se han de definir casos concretos junto con unos plazos, habrá que optar por el diagrama de secuencia, ya que permite visualizar subáreas individuales con mayor precisión. Con él es posible poner a prueba detenidamente las relaciones lógicas del caso de aplicación en cuestión.

Los diagramas de secuencia UML también son útiles cuando es necesario representar gráficamente operaciones complicadas para su mejor comprensión. Gracias a un modelado claro es posible identificar rápidamente las estaciones por las que debe pasar una única tarea para que se complete con éxito. Así, por ejemplo, es posible planificar y probar distintos métodos antes de implementarlos en el negocio diario o en un sistema informático.

Para representar las estructuras de control de un lenguaje de programación de alto nivel, se combinan varios diagramas de secuencia en un fragmento combinado.

El fin de un diagrama UML es ayudar a todas las partes implicadas a comprender mejor los sistemas complejos. Para ello, el lenguaje de modelado utiliza símbolos visuales. En casos excepcionales y con determinados grupos de aplicaciones, UML se puede modificar, pero recomendable recurrir al lenguaje estandarizado por el OMG (Object Management Group) para evitar que se produzcan problemas de comprensión. Las especificaciones que se indican a continuación corresponden al estándar UML en la versión UML 2.5.

Una línea de vida representa el curso del tiempo de un proceso. A la cabeza se sitúa un rectángulo que contiene normalmente el nombre del objeto y el nombre de la clase. Si falta el nombre del objeto, la línea de vida representa a una instancia de objeto sin nombre. En este caso, se puede suponer que todos los objetos de la misma clase actúan de la misma forma en esta secuencia. La línea de vida siempre representa un solo operando. Si el operando tiene varios valores, se debe seleccionar uno de ellos, es decir, la multiplicidad nunca es >1.

La línea discontinua situada bajo el encabezamiento representa el transcurso del tiempo. El tiempo tiene un desarrollo lineal descendente. A lo largo de la línea temporal se envían los mensajes y las respuestas. Un mensaje que haya de enviarse tras otro se sitúa más abajo en la línea de tiempo. En esta notación no se trata de puntos concretos en el tiempo, sino siempre de una secuencia. Los mensajes siempre están dispuestos uno debajo de otro, a menos que existan en fragmentos combinados de forma paralela.

Las líneas de vida indican cuánto tiempo participa activamente un objeto en un proceso, lo que se puede ver por la longitud de una línea en comparación con otras. Algunos objetos se destruyen antes de que el proceso haya terminado. Cuando ya no se necesita un objeto, se indica con una X el punto en la línea de vida en el que se ha de destruir.

Si quieres comprobar la robustez de tu sistema, el diagrama de secuencia es muy adecuado pues muestra una vista muy detallada. Se pueden utilizar tres estereotipos de clase de la línea de la vida:

• Entidad
• Límite
• Control

En la imagen de arriba se pueden ver estas tres líneas de vida con la notación: la entidad tiene una cabeza circular que se sitúa sobre una línea horizontal. El estereotipo de línea de vida denominado límite consta de una cabeza de la misma forma de la que sale una línea horizontal que conecta con otra vertical: a modo de T rotada noventa grados a la izquierda. La cabeza del estereotipo de control está compuesta por una flecha que gira en círculo. De todos estos estereotipos sale una línea de vida discontinua, que desciende en vertical.

Si ya has elaborado un concepto utilizando un diagrama de casos de uso, el diagrama de secuencia puede ayudarte, por ejemplo, a diseñar los pasos individuales teniendo en cuenta los actores y objetos posibles.

Los límites (boundaries) representan interfaces que interactúan con actores externos. Estos objetos pueden ser, por ejemplo, interfaces de usuario, en cuyo caso el actor correspondería a una persona. Las entidades (entities), por otro lado, son contenedores de datos, o sea, objetos que contienen datos del sistema. Para que los límites y las entidades se comuniquen, se necesita un elemento de control. El control no tiene que ser necesariamente un objeto; también funciona un método que se asigna a uno de los otros dos elementos. Se trata del medidador que conecta entidad y límite, monitoriza las señales de los dos elementos y comprueba su lógica.

Los tres estereotipos se comunican siguiendo estas cuatro reglas:

• Los objetos de límite son, como interfaces, responsables de la comunicación con los actores. De este modo, los actores se comunican exclusivamente con las fronteras.
• Por el contrario, los objetos de control se comunican con otros objetos de control, así como con entidades y límites. Pero no interactúan con los actores.
• Los límites se comunican con los objetos de control y con los actores.
• Las entidades son los soportes de datos más arraigados en el sistema. Solo intercambian datos con objetos de control.

Los mensajes de respuesta solo pueden estar formados por una expresión con un máximo de un operando por parámetro. Si el remitente de una respuesta no emite valores, el mensaje tampoco tiene valores específicos que enviar. En tal caso, el mensaje modela parámetros de salida de un emisor como operando (es decir, los valores resultantes de una operación). Sin parámetros de salida, el operando debe permanecer vacío para lo que basta con modelar un marcador de posición comodín en lugar del valor de retorno. Si hay un operando, el sistema lo evalúa de nuevo según la especificación de salida. El resultado de la evaluación especifica los valores de los parámetros “out”, “input” y “return”.

UML especifica tres símbolos que señalan el destinatario del mensaje como expresión de parámetro. El destinatario es el objetivo de asignación del mensaje. El mensaje de respuesta asigna un valor de retorno al parámetro de salida del emisor. Estos son los símbolos estandarizados:

• Unknown
• Interaction Parameter
• Attribute

Unknown (desconocido) es un parámetro vacío y equivale al comodín. El parámetro de interacción (Interaction Parameter) es un ownedParameter (parámetro propio) de la interacción a la que pertenece. Esto quiere decir que la interaccion es propietaria del parámetro. Este parámetro dispone de un nombre. Los parámetros de operación y los parámetros de interacción tienen el mismo tipo. Los atributos se pueden nombrar sin restricciones y representan el nombre de un comportamiento de contexto, siendo este el que determina la línea de vida a la que regresa el mensaje o la interacción circundante. Si la interacción no define ningún comportamiento, actúa como un contexto.

Las puertas (gates) son simplemente puntos al final de un mensaje. Pertenecen al tipo MessageEnd (final del mensaje) y marcan al remitente y al destinatario de un mensaje. Sirven para ilustrar el flujo de información y muestran cómo se trasladan los mensajes entre dos fragmentos de interacción. Para ser más precisos, representan los puntos de conexión entre las ocurrencias de interacción y las interacciones, así como entre los operandos de interacción dentro y fuera de un fragmento combinado. Se sitúan en el marco del diagrama.

El diagrama de secuencia UML conoce cuatro tipos de puertas. Difieren dependiendo de los fragmentos de interacción con los que están asociados:

• Actual Gate (puerta actual): las ocurrencias de interacción (interaction occurrence) remiten de un diagrama a otro. Esta puerta abre la conexión en el borde exterior de la ocurrencia de interacción para los mensajes desde la interacción a la que se refiere la ocurrencia de interacción. De este modo, la puerta tiene una asociación a la ocurrencia de interacción y acepta mensajes entrantes y salientes.
• Formal Gate (puerta formal): para que una interacción pueda intercambiar mensajes con una ocurrencia de interacción necesita una puerta formal. La puerta está situada en el interior del marco.
• Inner CombinedFragment gate (puerta interior para fragmentos combinados): dentro de un fragmento combinado, se sitúa una puerta en el marco. Intercambia mensajes con extremos de mensaje del fragmento combinado con mensajes con extremos de mensaje fuera del fragmento combinado.
• Outer Combined Fragment gate (puerta exterior para fragmentos combinados): esta puerta se encuentra en el borde exterior de un fragmento combinado. Constituye el polo opuesto a la puerta interior.

Las puertas pueden tener nombres explícitos o implícitos que deben coincidir en parejas: de este modo las puertas Actual Gate y Formal Gate deben coincidir, al igual que han de hacerlo las puertas Inner CombinedFragment Gate y Outer CombinedFragment Gate. Además, los mensajes deben ir en la misma dirección, coincidir en los valores de propiedad y tener el mismo MessageSort.

Los mensajes desempeñan un papel singular en los diagramas de comunicación (una forma simplificada del diagrama de secuencia), que modelan cómo interactúan las líneas de vida. A diferencia de los diagramas de secuencia, los diagramas de comunicación se centran en la arquitectura del sistema y en cómo esta determina el flujo de mensajes. Aunque permite mostrar una arquitectura detallada, los fragmentos de interacción (tales como los fragmentos combinados) no la utilizan. Como consecuencia, carece de un elemento estructural, si bien en su lugar se numeran los mensajes. A veces los mensajes pueden adelantar a otros, por lo que el orden de los mensajes salientes difiere del orden de los mensajes entrantes. A pesar de todo, el estándar UML desaconseja este tipo de mensajes no secuenciales en el diagrama de comunicación.

La notación UML para los diagramas de comunicación prescribe un marco de diagrama de secuencia simple: un rectángulo con una etiqueta pentagonal en el encabezado. En la etiqueta, la designación “sd” define este tipo de diagrama, junto a la que aparece el nombre de la interacción. Los mensajes se representan con una forma diferente: conectan las líneas de vida rectangulares (UML: nodos de objetos) como líneas rectas simples.

Sobre ellos se muesta una expresión de secuencia junto con una flecha que apunta en dirección del receptor. La designación tiene la siguiente estructura: [Número Nombre][Repetir]. El número entero establece la jerarquía de los elementos. Cuando uno de los números difiere (por ejemplo, 1.2.2 y 1.2.3), el sistema los envía uno tras otro. El nombre, por otro lado, representa las transmisiones simultáneas. El sistema envía simultáneamente dos mensajes con la designación de secuencia 1.2.3a y 1.2.3b, pues contienen el mismo número. La repetición incluye una restricción que determina cuándo se enviará el mensaje o un valor que determina con qué frecuencia se repetirá el mensaje.

En UML, las condiciones de guarda custodian el comportamiento de un elemento. El elemento debe:

• cumplir con una cierta condición,
• no exceder un cierto valor o quedar por debajo,
• corroborar una afirmación.

Por lo tanto, se puede concluir que una condición de guarda es una restricción. Solo si se cumple la restricción, el elemento afectado puede ejercer cierto comportamiento. Hay muchos elementos diferentes que pueden tener este tipo de condiciones: acciones, atributos, comportamiento, entre otros. UML no prescribe un lenguaje estricto, pero ofrece OCL (Object Constraint Language) como opción nativa. También se utilizan a menudo las variables booleanas.

Una restricción de interacción consiste en una expresión booleana de este tipo. La restricción sirve de protección para el operando dentro de un fragmento combinado. Solo si el valor de la restricción es verdadero, el fragmento de interacción adjunto inicia su comportamiento. La restricción se anota entre corchetes en la línea de vida por encima de una especificación de ejecución. La estandarización permite combinar fragmentos sin restricciones de interacción, ya que en este caso el sistema asume que los mensajes recibidos son verdaderos.

Dado que la ocurrencia de interacción hace referencia a otros diagramas, estos factores externos determinan su comportamiento. Mientras que la interacción enlazada tiene puertas formales (Formal Gate), la interacción de referencia tiene la puerta real (Actual Gate).

La descomposición en parte (Part-Decomposition) consiste en la separación parcial y secuencial de una línea de vida dentro de una interacción realizada por otra interacción. Con esta descomposición, es posible separar los detalles entre sí y, de este modo, examinar más de cerca cada una de las subfunciones. Si los mensajes llegan o emanan de la línea de vida descompuesta, se consideran puertas reales, que están conectadas con las puertas formales de la acción de descomposición. Las puertas y los parámetros de ambos elementos deben coincidir. La descomposición parcial también recibe la etiqueta “ref” y se define por la interacción asociada.

El comienzo y el final los marcan las especificaciones de ocurrencia de eventos (Event Occurrence Specification). Al inicio de una activación se encuentra el evento de inicio y al final está el evento de fin. Estos fragmentos representan cada uno un solo momento y existen en una propia línea de vida. La especificación de ocurrencia de evento representa el inicio o el final de una acción. La especificación de ocurrencia de mensajes da la señal para enviar y recibir un mensaje. Por lo tanto, su valor siempre depende del mensaje o de la acción.

La activación no tiene notación separada, ya que existe de forma implícita en los elementos de conexión exteriores del rectángulo que representa el cuadro de activación. Si este pasa por una acción de duración atómica, las asociaciones inicial y final se refieren a la misma especificación de entrada, lo que se puede resaltar con una línea de conexión entre la acción y la especificación de entrada.

Mientras que otras especificaciones de entrada no requieren notación, la destrucción de la especificación de entrada de mensaje se marca con una X mayúscula, marcando la disolución de una instancia de un objeto en un punto concreto en la línea de vida (la línea de la vida termina ahí). Las instancias subordinadas o las especificaciones de entrada en puntos posteriores de la línea de tiempo no son válidas, dado que después de que el objeto haya sido destruido, estas tampoco pueden existir.

A veces, los cuadros de activación se superponen. Cuando, por ejemplo, un objeto se envía un mensaje a sí mismo, un cuadro de activación envía un mensaje a otra instancia de esa clase. Ambas especificaciones están parcialmente en la misma línea de vida, al mismo tiempo. En el diagrama de secuencia UML, esta circunstancia se representa con rectángulos superpuestos.

La invariante de estado fija un valor restrictivo. Si este valor es igual al estado del objeto, la ruta se considera válida. Si el objeto no cumple la restricción, su ruta no es válida.

De acuerdo con la notación del diagrama de secuencia UML, la invariante de estado se escribe con llaves { } dentro del cuadro de activación o con un rectángulo redondeado en las esquinas.

Los fragmentos combinados se clasifican dentro de los fragmentos de interacción. Se trata de elementos abstractos del sistema y representan unidades de interacción. Esto significa que, aunque pueden ser considerados parte de una interacción, ellos mismos también son pequeñas interacciones. Los fragmentos combinados en un diagrama de secuencia establecen el comportamiento de varios fragmentos de interacción, si bien ellos mismos solo forman el marco. Los definen los operadores de interacción y los operandos de interacción: los operandos contienen uno o varios mensajes. En la línea de vida, antes de un fragmento combinado, se sitúa una restricción, también llamada condición de guarda, que controla los operandos contenidos.

Como ya se ha descrito, los operandos son magnitudes constantes o variables que pasan por un proceso. Los operadores influyen en el comportamiento de los operandos. Por ejemplo, el operador booleano “OR” puede especificar que se ejecute el operando A o el operando B (o que se ejecuten ambos). Dentro de un fragmento combinado, un operando especifica que se envíe un mensaje determinado bajo ciertas condiciones. El operador determina qué relaciones de ordenación tienen los operandos de un fragmento entre sí y qué relaciones de ordenación tienen con el fragmento superior.

UML define 12 operadores de interacción.

Alternative:

Dentro del fragmento combinado con el operador de interacción “Alternativa”, un fragmento subordinado solo puede enviar un mensaje si se cumple una determinada condición. De lo contrario, un fragmento competidor dentro del marco enviará su mensaje. La imagen superior muestra un ejemplo de un fragmento combinado con el operador “Alternativa”. Utiliza la abreviatura “alt” para la etiqueta. Divide el marco rectangular por una línea discontinua horizontal, correspondiendo la parte superior a una condición.

Guard:

La condición de guarda comprueba si la condición del operando se cumple. En caso afirmativo, el sistema envía un mensaje en el área de condición. Si no, envía un mensaje en el área alternativa. Un operando dentro de este fragmento combinado siempre necesita una condición de guarda que se considera verdadera (“true“) para poder ejecutarse. Si el operando de condición no tiene una condición de guarda explícita, se asume una protección implícita. Así que este fragmento siempre representa una decisión “o … o”.

Option:

Este fragmento combinado se modela en el diagrama de secuencia como la alternativa, porque la opción también representa una decisión. Con todo, solo hay un operando, por lo que la decisión consiste en determinar si el operando se ejecuta o no. El operando con una condición no debe estar vacío, aunque por otro lado su alternativa sí está vacía. Un fragmento con el operador de interacción “ejecución opcional” utiliza la etiqueta “opt”.

Break:

Un fragmento combinado con el operador de interacción “break” interrumpe el fragmento principal. Si una línea de vida cumple la condición del operando, el sistema ejecuta el fragmento combinado, pero ignora el resto del fragmento principal. Para que todas las líneas de vida puedan agotar su vida, debes incluir cada línea de vida en el fragmento combinado. De lo contrario, una línea de vida puede detenerse en medio del proceso sin que sea destruida de la forma adecuada. Si el fragmento break carece de condición de guarda, la decisión es no determinista. Es por eso que se recomienda utilizar una condición de guarda.

En un cajero automático, por ejemplo, es posible introducir el número PIN tres veces. Si el PIN es incorrecto, se pedirá al usuario repetir la entrada. En el diagrama de secuencia UML se anotan el mensaje “Introducir PIN” y su respuesta “PIN incorrecto. Inténtelo de nuevo” con las flechas correspondientes. La etiqueta tiene forma Loop (0,2). La variable booleana es [PIN incorrecto]. Mientras no se introduzca el PIN correcto, el loop se repite dos veces. Si el PIN es correcto, el sistema resuelve el bucle. Si se excede el número máximo de repeticiones, también se libera el loop, pero el proceso se cancela como no válido.

Según cómo se organice la continuación en el diagrama de secuencia, la tarea también cambia. Si la continuación está al principio de un diagrama de interacción, se usa para modelar el comportamiento de la continuación. Si la continuación se encuentra al final de su fragmento de interacción, reenvía el proceso. Si nombra su continuación (como en el ejemplo: notOK), el siguiente fragmento de la línea de vida debe tener una continuación con el mismo nombre (notOK) o no debe modelar una continuación. Si la continuación se encuentra sola en el fragmento, esto corresponde a una continuación al final del fragmento.