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.
Diagramas de secuencia: ventajas y singularidades
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.
Los diagramas de secuencia apoyan en el análisis lógico de partes de sistemas. Si la secuencia de tiempo de los procesos desempeña un papel importante, este tipo de diagrama es ideal. Sin embargo, no tiene sentido representar todo un sistema con él. En su lugar, es mejor utilizar un diagrama de comportamiento adecuado, como el diagrama de caso de uso, el diagrama de estado o el diagrama de actividad. Estos ilustran contextos incluso más amplios de una manera clara y fácilmente comprensible.
Diagramas de secuencia: ejemplos con notación
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.
Líneas de vida
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.
En ingeniería informática, un operando es un objeto influenciado por un operador. Los operandos pueden ser constantes o variables. Un operando simple, por ejemplo, es la variable X. Los operadores pueden ser simples operadores aritméticos como “+” y “-”. En la programación, estos componentes se utilizan desde en funciones simples como “x = t * 4” hasta en sofisticados algoritmos.
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.
Mensajes
El mensaje es un elemento básico del diagrama de secuencia. En la programación orientada a objetos, un sistema se compone de objetos. UML presenta estos objetos como nodos unidos entre sí por los elementos de conexión, que en UML pueden realizar varias tareas. Concretamente, en el diagrama de secuencia UML se encargan de modelar los mensajes de metaclase. Como forma básica del elemento de conexión la notación establece una línea. Las flechas son una forma especial de elemento de conexión que representan una relación direccional o flujo de información. En el diagrama de secuencia simbolizan a los mensajes. En función del tipo de mensaje del que se trate, su visualización cambia, como bien muestra la siguiente imagen.
Para dotar al mensaje de contenido se agrega una etiqueta, que en el caso de mensajes simples sigue el siguiente formato:
[nombre del mensaje] : [atributo “=”] nombre de la señal o nombre de la operación [argumentos] [“:” valor de retorno]
Los argumentos válidos para los mensajes son:
- Constantes
- Valores wildcard o comodín (valores simbólicos que representan un valor legal X en el diagrama)
- Atributos del remitente
- Parámetros de la interacción envolvente
- Atributos de clase superior
Los mensajes tienen una firma con la que se especifica el contenido del mensaje. La firma se refiere a una señal o a una operación y debe llevar su nombre. Esto implica que el contenido del mensaje desencadena una operación (es decir, una actividad) en el destinatario o le envía una señal (es decir, solo intercambia información). Además, los mensajes difieren dependiendo de si son sincrónicos o asincrónicos: con los mensajes asincrónicos, el remitente no espera una respuesta, sino que reanuda su comportamiento inmediatamente; con los síncronos, el remitente espera una respuesta y bloquea el canal de envío durante un tiempo.
Estos son los tipos de mensajes estandarizados en el diagrama de secuencia UML:
- Los mensajes asíncronos del tipo (MessageSort) asynchronchCall invocan una operación y desencadenan su ejecución. Con los mensajes asíncronos, el sistema no espera una respuesta del destinatario, sino que prosigue con sus procesos sin interrupción. Los parámetros de operación y los atributos de los mensajes deben coincidir.
- El tipo asynchSignal se utiliza para las instancias de señal. Representa el envío y la recepción de mensajes asíncronos. Este mensaje es el resultado de una acción de envío asíncrona de la señal. Aquí los atributos de la señal determinan los argumentos del mensaje.
- Notación: los mensajes asíncronos se modelan con forma de flechas con línea continua y punta abierta.
- Los mensajes síncronos invocan solo a las operaciones, no a las señales. El tipo de mensaje se llama synchCall. Los mensajes síncronos esperan una respuesta de la operación antes de reanudar su comportamiento y se representan con una flecha cuya punta está coloreada en negro.
- El destinatario de un mensaje devuelve las respuestas al remitente después de que la operación haya producido un resultado, en cuyo caso el símbolo tiene una punta de flecha abierta o coloreada. La línea de la flecha correspondiente es discontinua.
- createMessage es un tipo de mensaje que señala una nueva instancia de una línea de vida. Con él, el sistema crea un nuevo objeto en el diagrama de secuencia. Este tipo de mensaje es el único que remite directamente a la cabeza de la línea de vida. Otros mensajes deben apuntar a la línea de vida discontinua. createMessage es representado, al igual que en el caso de las respuestas, por una flecha de punta abierta y línea discontinua, solo que en este caso apunta en la dirección opuesta.
- deleteMessage señala el punto en el que se destruye una instancia de línea de vida. Este mensaje de eliminación se dibuja de forma libre como una flecha, a la que opcionalmente se le añade el título “destroy”. Siempre debe señalar a un evento de destrucción. También llamado destruction occurrence specification, esta especificación de evento marca la destrucción de un objeto en la línea de tiempo de ejecución con una X.
Al remitente o el receptor pueden faltarles los mensajes –o les son desconocidos. El estándar UML asume entonces que la instancia se encuentra fuera del diagrama. Si se conoce al destinatario pero no al remitente, se trata de un mensaje encontrado. En el lugar del remitente se escribe un círculo pequeño y coloreado, simbolizando su ausencia. El caso contrario es el del mensaje perdido: cuando el receptor es desconocido, en la punta de la flecha se añade un cículo coloreado.
Un tipo especial de mensaje lo constituye el que se envía en su propia línea de vida. La línea de vida envía una función recursiva desde el cuadro de activación. Mientras la primera operación, representada por el cuadro de activación, está teniendo lugar, en la misma línea de vida se inicia una segunda operación que parte del mensaje enviado. Este tipo de mensaje se utiliza, por ejemplo, si se realiza una operación varias veces y, por lo tanto, el objeto debe referirse a sí mismo. Los mensajes entre dos líneas de vida también pueden causar activaciones superpuestas.
Otra parte importante del mensaje son los parámetros, que son especificaciones de valor. El sistema evalúa esta dimensión cuando envía un mensaje con una firma. Esto ocurre en las especificaciones de salida, es decir, en el punto en el que se envía el mensaje. El resultado prescribe los valores para los atributos de señal o los parámetros de salida de operación, dependiendo de quién sea el receptor. A continuación, la operación procesa el valor y genera un parámetro de salida.
Una particularidad que se puede resaltar es el parámetro comodín. Si en un mensaje faltan todos los parámetros, la sintaxis precisa una cadena vacía que indica que no se ha fijado el valor del parámetro. Sin embargo, dicho valor es considerado válido para los parámetros o atributos del receptor, es decir, como su propio nombre indica, funciona como un comodín. Los caracteres comodín son marcadores de posición para letras individuales o cadenas completas. En muchos casos se recurre al asterisco (*) como marcador de posición. En el caso de UML, este papel lo cumple el guión (“-”).
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”.
Los parámetros IN, OUT e INOUT especifican si una instancia acepta o devuelve valores. El parámetro IN indica que una instancia recibe y procesa valores, pero no los envía. El parámetro OUT especifica que no asume ningún valor, sino que solo los emite. El parámetro INOUT permite valores de entrada y salida. Si no se define ninguno de estos valores, el sistema asume IN por defecto.
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.
Condición de guarda
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.
Fragmentos de interacción en diagramas de secuencia
Cuando se crea un diagrama de secuencia, las líneas de vida y los mensajes conforman los componentes principales. UML2 presenta un marco para este tipo de diagrama, si bien no es obligatorio. El marco limita un subproceso, el llamado fragmento de interacción, e incluye todas las líneas de vida y mensajes necesarios. Como se ejemplifica en la imagen inferior, dicho marco está representado por un rectángulo con una etiqueta en la esquina superior izquierda, en la que se incluye la abreviatura sd, propia de un diagrama de secuencia, y normalmente resaltada en negrita, y el nombre de la interacción.
Además de la limitación visual, el marco también responde a aspectos funcionales. Por ejemplo, si se crean varios diagramas de secuencia (u otras interacciones), el marco sirve para delimitar las diferentes presentaciones. Para mostrar que los diferentes fragmentos de interacción se comunican entre sí, modela un mensaje cuya flecha se dirija a la línea lateral del marco. El punto en el que la flecha topa con el marco se denomina puerta, elemento con una función dentro del diagrama, pero que carece de notación propia. Un ejemplo de lo aquí expuesto se puede observar en la imagen superior, donde el sistema envía el mensaje 5 al exterior.
En UML, los fragmentos de interacción forman parte de los nodos. UML especifica las propiedades y las tareas de cada uno de ellos, dependiendo del tipo de diagrama en el que se encuentren. En general, puede afirmarse que los nodos son elementos modelo dentro de un sistema o proceso en el que se puede instalar un artefacto. UML conecta a los diferentes nodos con elementos de conexión, encargados de representar el intercambio de información de forma gráfica mediante flechas o líneas simples.
En UML se pueden crear diagramas de secuencia que contengan subsegmentos entrelazados. Los marcos ayudan a mostrar los fragmentos individuales de una manera ordenada.
Los diagramas de secuencia pueden contener los fragmentos de interacción: ocurrencia de interacción, invariantes de estado, cuadros de activación y fragmentos combinados.
Ocurrencia de interacción
Las ocurrencias de interacciones forman una subclase que define la notación, estructura y comportamiento de dos metaclases, estas son, ocurrencias de interacciones y descomposición en parte.
La ocurrencia de interacción como metaclase es un fragmento de interacción que convoca a otra interacción o la utiliza. Si un diagrama de secuencia se vuelve demasiado complejo, se puede usar esta referencia para que resulte más claro. En el diagrama de secuencia de la imagen siguiente, la ocurrencia de interacción descrita está representada con un cuadro negro. Para identificar de forma inequívoca la ocurrencia de interacción llamada, hay que especificar la siguiente sintaxis en el cuerpo (campo en el que se realizan las operaciones):
- nombre del atributo (atributo de una línea de vida en la interacción que recibe el valor de retorno),
- nombre de la colaboración (ocurrencia de colaboración identificada, que vincula interacciones y colaboraciones),
- nombre de interacción del elemento al que se llama,
- argumento -io (In/Out): argumentos de la interacción de entrada y salida y
- valor de retorno (respuesta de la interacción llamada).
La ocurrencia de interacción se modela como un rectángulo con una etiqueta pentagonal en la esquina superior izquierda. En ella se introduce la abreviatura “ref” (del inglés: “referral”).
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.
Cuadro de activación/especificación de ejecución
El cuadro de activación (Execution Specification) representa el tiempo en una línea de vida en la que un objeto ejecuta un comportamiento o durante el que tiene lugar una acción. Además, permite modelar el tiempo en el que un objeto implicado envía un mensaje o espera una respuesta, pues el cuadro de activación representa un período de tiempo abstracto durante el tiempo de ejecución. Como ocurre en el resto del diagrama de secuencia, el tiempo no es una dimensión absoluta, sino relativa. El comportamiento pasivo, como puede ser esperar una respuesta, también debe introducirse como activación en el diagrama de secuencia.
UML presenta la semántica basada en trazas de un cuadro de activación a través de la estructura simple <start,end>. Su notación permite dos formas: por un lado, es posible modelar un rectángulo gris alargado y estrecho en la línea de vida. En tales casos, la activación no suele incluir una etiqueta en el cuerpo. Por otro, también es posible modelar un rectángulo ligeramente más ancho en la línea de vida, donde se dispone de espacio para etiquetar el cuadro de activación. Si un objeto realiza una activación durante el tiempo de ejecución, puedes indicar el nombre de dicha acción.
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.
Una acción de duración atómica se muestra como una caja negra. Se trata de una secuencia indivisible de varias operaciones simples que no pueden ser observadas porque se realizan con extrema rapidez. Por lo tanto, una acción de duración atómica aparece completa inmediatamente.
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.
Invariantes de estado
La invariante de estado es una restricción de tiempo de ejecución. La línea de vida representa un objeto. Durante el tiempo de ejecución, este objeto cambia de estado como resultado del cuadro de activación. La invariante de estado examina el objeto con respecto a su cambio de estado en el cuadro de activación antes de ejecutar la siguiente especificación de entrada. Todas las acciones implícitas previas dentro del cuadro de activación se consideran ejecutadas.
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.
Fragmentos combinados
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.
Operadores de interacción
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.
El no determinismo es un concepto de ciencia de la computación para simplificar el modelado. De este modo un sistema tiene más de una forma de lograr un resultado, siempre que el valor de entrada sea el mismo. En la práctica se utilizan los algoritmos deterministas con un solo método de cálculo. Por el contrario, un algoritmo no determinista sigue una trayectoria impredecible en el cálculo, incluso cuando el sistema se inicia con los mismos valores de entrada. Dado que el algoritmo suele producir resultados más diferentes que un algoritmo determinista, la tarea debería ser menos compleja. Los modelos abstractos simplifican los sistemas complejos. Por lo tanto, son adecuados para realizar diferentes cálculos con el algoritmo no determinista.
Loop:
Un fragmento combinado con el operador de interacción “loop” repite su operando. La condición de guarda determina el número exacto de ejecuciones. Esta protección puede incluir límites de repetición y variables booleanas. Los límites de repetición se indican en la etiqueta del marco siguiendo el esquema: loop (X,Y). Las variables X e Y representan números enteros. X es el número mínimo de repeticiones (“min-int”) y nunca es negativo. Y representa al número máximo de repeticiones (“max-int”) y ha de ser igual o mayor que el mínimo (es decir, > 0).
De manera opcional es posible anotar la variable booleana en el cuerpo del marco junto a la etiqueta, restringiendo aún más la repetición. Si la condición de la variable booleana ya no se cumple y se alcanza el número mínimo de repeticiones, el loop se detiene. Puedes anotar la restricción entre corchetes, la cual se refiere a factores externos, como la aportación de un actor.
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.
Si no se establece ninguna limitación de repetición, el mínimo es 0 y el máximo es infinito. Si se especifica una limitación, el mínimo y el máximo tienen el mismo valor.
Parallel:
Normalmente, la posición de una flecha en la línea de vida en el diagrama de secuencia establece un orden cronológico. En un fragmento combinado con el operador de interacción parallel, sus operandos pueden ejecutar los procesos simultáneamente. Los operandos entrelazan su orden de procedimiento, si bien el orden dado dentro de los operandos siempre se mantiene. En el diagrama de secuencia UML se modela este fragmento combinado con un marco continuo. Los diferentes operandos se separan visualmente con líneas discontinuas, de forma similar al operador “alternativa”. En la etiqueta se introduce la abreviatura “par” . Además, si los operandos han de trabajar en paralelo en una sola línea de vida, UML permite una forma abreviada: la Co-Region cumple exactamente con esta tarea. Para ello, simplemente combina los eventos con un corchete.
Sección crítica:
Utilizando una sección crítica, el sistema evita los errores que pueden ocurrir cuando varios procesos comparten recursos. Dentro de esta área de sistema, solo un proceso utiliza el recurso hasta un punto concreto en el tiempo. Además, el sistema prioriza el proceso respectivo. Con la etiqueta “critical” se define una región crítica con el objetivo de evitar que otros operadores de interacción influyan en un fragmento principal. Por ejemplo, bloquea las trazas entrelazadas de un fragmento paralelo combinado.
Como muestra el gráfico superior, una línea directa del proveedor de gas acepta varias llamadas en paralelo y las reenvía simultáneamente a los empleados de la línea directa. Sin embargo, si se trata de una emergencia por posible olor a gas, el sistema prioriza el mensaje y reenvía la llamada a través de la sección crítica al servicio de emergencias. La sección crítica evita que los flujos de información del fragmento principal se procesen en paralelo con el mensaje de la sección crítica. Solo las líneas de vida en la sección crítica se comportan de esta manera.
Assertion:
El operador de interacción “assertion” define el estado de las secuencias. Las secuencias dentro de un operando con la etiqueta assert se consideran secuencias válidas. El operador establece que todas las secuencias fuera del fragmento finalizan en trazas no válidas.
Ignore/consider:
Un diagrama de secuencia UML representa de forma detallada una parte del sistema. No obstante, para una visualización determinada, algunos mensajes no son necesarios, mientras otros han de ser incluidos. Con el operador de interacción “ignore” se excluyen ciertos mensajes. Esta información aparece en el sistema en una traza, pero no en el fragmento ignore. La notación determina el uso de una etiqueta con la siguiente estructura: ignore {mensaje1,mensaje2}.
Los fragmentos combinados con el operador de interacción “consider”, por otro lado, incluyen ciertos mensajes en un fragmento. El sistema ignora todos los demás mensajes que pasan por el fragmento. Los mensajes que hay que considerar se incluyen según la siguiente estructura: consider {mensaje3,mensaje4}.
Estos dos operadores tienen tareas contrapuestas. Sin embargo, los dos suelen aparecer con frecuencia en fragmentos entrelazados. Por ejemplo, los modeladores a menudo combinan assert con ignore (assert ignore {Msg1, Msg2}) o assert y consider (assert y consider {Msg3, Msg4})
Negative:
Para indicar un error del sistema, se utiliza el operador de interacción “negative”. El fragmento combinado contiene, por tanto, trazas no válidas. El operador se utiliza, por ejemplo, cuando se visualiza un procedimiento de registro al sistema utilizando un diagrama de secuencia. Al modelar la línea de vida de un actor en el camino hacia tiempo muerto, puedes enmarcar este mensaje de error con el fragmento negativo (denotado neg). Debido al modelado explícito de trazas no válidas en el fragmento combinado negativo, el resto de fragmentos se consideran positivos y sus trazas, válidas.
Strict:
Dentro de un fragmento combinado, puede ser importante mantener un orden estricto. La etiqueta “strict” impone una secuenciación rigurosa en sus operandos. Esto se aplica al primer nivel del fragmento. Los operandos en otros fragmentos están sujetos a su propio orden.
Secuenciación weak:
Los fragmentos combinados con el operador de interacción “seq” representan un orden débil. El comportamiento entre los operandos del fragmento influye en las propiedades de las trazas en lugar de en los operadores de interacción. Por lo tanto, una secuenciación débil puede actuar como un fragmento paralelo. Esto sucede cuando los operandos participan en diferentes líneas de vida. A cambio, la secuenciación débil se transforma en un orden estricto cuando sus operandos aparecen en la misma línea de vida. La etiqueta es “seq”.
Las trazas con las siguientes propiedades definen la secuenciación weak:
- Las especificaciones de eventos dentro de un operando conservan su orden.
- Las especificaciones de eventos que actúan en diferentes líneas de vida y que no ocurren dentro del mismo operando ocurren en cualquier orden.
- Si las especificaciones del evento actúan en la misma línea de vida, pero en operandos diferentes, su posición en la línea de vida prescribe su orden. De este modo, el primer operando viene antes que el segundo operando.
Continuation:
La continuación no se puede considerar un fragmento independiente. De hecho, solo recibe su propia semántica en los fragmentos combinados alternativa y secuenciación weak. La forma para la continuación es la misma que para la invariante de estado: un rectángulo con esquinas redondeadas. Se diferencia, sin embargo, de la variante de estado en que puede cubrir de forma opcional varias líneas de vida.
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.
Si deseas mostrar ejemplos de aplicación en detalle o comprobar la lógica de un sistema, crea un diagrama de secuencia con UML. La notación permite modelar el flujo de mensajes durante toda la vida útil de un objeto. Incluso las operaciones complejas pueden mostrarse claramente utilizando fragmentos de interacción entrelazados. El diagrama de secuencia no es sin razón uno de los diagramas de comportamiento de UML más utilizados.