Diagramas de actividades: el flujo de trabajo representado gráficamente

En UML 2 una actividad (activity en inglés) es un comportamiento que supedita las unidades subordinadas (acciones y objetos) a una secuencia cronológica. Para ello, utiliza modelos de flujo de datos y de control. El diagrama de actividades se puede visualizar como parte de un sistema más grande junto con otros tipos de diagrama. Un rectángulo grande y redondeado marca la actividad como un sistema cerrado (aunque puede omitirse). En la imagen de ejemplo, más abajo, se puede ver la actividad “Cocinar espárragos”. En el encabezado del rectángulo grande se escribe el título. El cuerpo contiene flechas (bordes, edges en inglés) y rectángulos que simbolizan las acciones, los objetos y los flujos de datos o de control de la operación.

Solo cuando se cumplen las condiciones especificadas en los pines, los datos introducen una acción (pin de entrada) o la acción produce un resultado (pin de salida). Incluso si una acción tiene varios flujos de control de entrada, cada una debe ofrecer un token antes de que se inicie la acción.

Para las acciones dentro de un diagrama de actividad, la sintaxis presenta la forma simple del rectángulo redondeado. Sin embargo, los modeladores también pueden recurrir a acciones específicas para obtener descripciones más detalladas. UML emplea su propia notación para expresar algunas de ellas:

1. Opaque actions son “acciones opacas”. Actúan como marcadores de posición o se especifican mediante una sintaxis de texto concreta (no definida por UML).
2. Invocation actions son acciones que causan un cierto comportamiento, tanto directa como indirectamente. Esto incluye:

• Call actions: Una call behavior action es una llamada directa a un comportamiento. Una call operation action, en cambio, envía una petición a un objeto que llama a un comportamiento asociado. La start object behavior action hace que un objeto ejecute directamente su comportamiento de instancia. Si no se determina ninguna, puede desencadenar el comportamiento de clase de nivel superior (classifier behavior).

La notación de una acción que origina un comportamiento es un rectángulo redondeado y en él deberás introducir el nombre del comportamiento. Las call behavior actions también están marcadas con un símbolo de tridente (como se muestra en la imagen de abajo). Esto representa la ramificación jerárquica adicional creada por la acción.

• Send actions: en el diagrama de actividades, las acciones de envío siempre envían datos asincrónicamente (los diagramas de secuencia también conocen los mensajes sincrónicos). Esto significa que no esperan una respuesta del objeto de destino y, por lo tanto, no bloquean el flujo del objeto. La acción concluye tan pronto como se haya enviado el mensaje. Por lo tanto, puede tener una entrada de argumentos como, por ejemplo, parámetros, pero no produce una salida de resultados. Además, los mensajes pueden ir a varios destinatarios al mismo tiempo. La acción de la señal de envío, la acción de la señal de difusión y la acción del objeto de envío se engloban dentro de este tipo.

Las acciones de envío de señales se desvían en su notación de la forma habitual (el rectángulo redondeado) y en su lugar un pentágono indica la dirección de la señal transmitida como una gran flecha. Si el contenido de una acción de objeto de envío también consiste en una señal, puede utilizar la misma notación.

3. Las object actions modifican el estado de los objetos (y también las instancias de una clase). Puedes crearlos o destruirlos, compararlos con otras instancias, leerlos y luego asignarlos a una clase o modificar la clasificación. Las instancias de acciones de objetos existen bajo UML 2 son las siguientes:

• Las create object actions generan instancias de una clase, es decir, objetos.
• Las destroy object actions destruyen el objeto en su pin de entrada.
• Las test identity actions examinan si dos valores en su pin de entrada representan el mismo objeto.
• Read self actions, determinan su propio objeto de contexto.
• Value specification actions, examinan las especificaciones de valor. La notación lleva la etiqueta value specification.
• Read extent actions, encuentran todos los objetos de una clase, así como los objetos de sus especificaciones. Por razones prácticas, los modeladores suelen limitar el radio de alcance.
• Reclassify object actions, cambian la clase del objeto en el pin de entrada.
• Read is classified object actions, determinan si un objeto en el pin de entrada pertenece a una clase.
• Start classifier behavior actions desencadenan un comportamiento para un objeto que está determinado por su clase. El comportamiento es entonces asincrónico.

4. Las link actions cambian el comportamiento de las asociaciones (las relaciones entre clasificadores, por lo general de dos clases) y sus instancias, los enlaces. Aquí se incluyen:

• Read link actions: recuperan valores (datos de fin de enlace) en una página de una asociación.
• Create link actions: crean enlaces (no tienen pins de salida porque los enlaces no son datos en sí mismos) y enlazan objetos.
• Destroy link actions: eliminan los enlaces y los objetos de enlace si corresponden a un valor de datos del extremo del enlace especificado.

5. Las link object actions influyen en el comportamiento de los objetos enlazados de forma similar a las link actions, pero consideran los objetos desde otros puntos de vista. Estas son las instancias de acciones de objetos de enlace:

• Read link object end actions, que recuperan objetos finales de objetos enlazados.
• Read link object end qualifier actions, que recuperan los valores finales del clasificador de los objetos de enlace.
• Create link object actions, que son acciones Create link especiales que se pueden utilizar para crear objetos de enlace.

6. Las structural feature actions determinan el comportamiento de las características estructurales en los diagramas de actividades. Para ello necesitan un pin de entrada, ya que normalmente se les asigna un objeto y una característica estructural de un clasificador especificada estáticamente. La acción de las características estructurales afecta a ambos elementos. Existen los siguientes tipos:

• Read structural feature action: leen los valores de las características estructurales y los transmiten como salida.
• Add structural feature value actions: requieren un pin de entrada de valores. Especifican el valor que la acción asigna a una característica estructural.
• Remove structural feature value actions: restan un valor de una característica estructural. Un pin de entrada de valores con multiplicidad 1..1 especifica este valor.
• Clear structural feature actions: eliminan todos los valores de un elemento de estructura.

7. Las variable actions influyen en las variables especificadas estáticamente que están definidas por una actividad o un nodo de actividad estructurado. Hay tres tipos:

• Add variable value actions, también requieren un pin de entrada de valores. Debe ser del mismo tipo que la variable y añadirle exactamente un valor.
• Remove variable value actions, eliminan un valor especificado por el pin.
• Clear variable actions, eliminan todos los valores de una variable.

8. Accept event actions: pertenecen a los llamados puntos de espera (wait points). Esto significa que la acción espera que tenga lugar un evento (event) del pool de eventos del objeto context. La acción cuenta con desencadenantes que provocan la acción cuando se producen uno o más estados prescritos. UML describe tres especializaciones:

• Accept call actions: tienen un disparador que acepta eventos de llamada. Dos pins de salida de resultados y un pin de salida de información de retorno completan el acuerdo. Si se debe ejecutar una acción de respuesta, la información necesaria para ello se almacena en el pin de salida de información de retorno.

9. Las structured actions están declaradas en el diagrama de actividades con UML 2 como una acción y como un grupo de actividades (ver arriba). Esto significa, por un lado, que su comportamiento está determinado por los nodos de actividad y las flechas y, por el otro, que ciertos subtipos de estas acciones prescriben un determinado comportamiento para los nodos ejecutables debido a su semántica, en particular con respecto a su secuencia.

Estos son los subtipos de acciones estructuradas:

• Conditional nodes, consisten en una o más cláusulas que representan las diferentes ramas de las posibles acciones ejecutables. Una cláusula contiene un segmento de prueba y un segmento de cuerpo, que a su vez incluyen nodos ejecutables sin cortes. En primer lugar, la cláusula ejecuta la acción en el área de prueba. Si su valor de salida es verdadero, la cláusula ejecuta la acción en el área del cuerpo.
• Loop nodes, describe un grupo de acciones que se repiten dentro de un bucle. Las acciones se dividen en tres secciones: configuración, prueba y cuerpo. El bucle siempre ejecuta la configuración primero, seguido por una prueba o cuerpo que luego se repetirá alternativamente.
• Sequence nodes, imponen una secuencia a los nodos ejecutables dentro de sus límites. Estos se representan con flujos de datos como flechas, que pueden apuntar hacia dentro o hacia fuera de la estructura.

10. Las expansion regions son otro tipo de nodos de actividad estructurados. Aceptan como entrada a una o más colecciones de valores. En el camino a la región de expansión, el pin de entrada copia cada token entrante en el número de artículos de la colección. Todos los nodos de la colección se ocupan de cada uno de los valores de la colección. Un turno se considera una ejecución de expansión (expansion execution). Un nodo de desglose (una especie de nodo de objeto) indica la interface de la región de desglose. Hacia el exterior, muestra sus valores como una colección y, hacia el interior, cada uno de los elementos del conjunto se considera un valor. Para la notación, se dibuja un rectángulo redondeado con una línea de puntos. Los nodos de expansión aparecen como rectángulos con segmentos y, como se muestra a continuación, se dibujan directamente en la línea. La segmentación debe representar la lista de colecciones de valor.

Los nodos de objetos son subtipos de los nodos de actividad. En UML, un objeto suele ser la instancia con valor más pequeña. Los objetos representan datos en el diagrama de actividades. Mientras se ejecuta una acción, los nodos de objeto retienen estos datos. Porque solo los tokens de control pueden recorrer una acción. Los tokens de objeto, en cambio, entran como valores por un pin de entrada y son enviados desde el pin de salida al flujo de objetos.

Los nodos de objetos se introdujeron por primera vez en el diagrama de actividades del UML-2. Son elementos tipificados. Si un nodo de objeto corresponde a un determinado tipo, los tokens de objeto que se mueven sobre él deben tener valores correspondientes. Una excepción son los tokens nulos que no tienen valor, ajustándose a cada nodo de objeto.

Los nodos de objeto prescriben el orden en el que los tokens los dejan. Hay cuatro maneras de hacerlo:

• Desordenado (no especificado)
• Ordenado (comportamiento definido por el modelador)
• FIFO (first in first out): el orden de entrada y salida sigue siendo el mismo.
• LIFO (last in first out): el orden es exactamente el opuesto.

Si deseas crear un diagrama de actividades, puedes decidirte por uno de los cuatro tipos de nodos de objetos:

1. Pin: ya hemos hablado de los pins. En el primer gráfico se podía ver la notación básica de los pins. Debido a su función de enlace entre las acciones y los flujos de objetos, los modeladores suelen dibujarlos como pequeños rectángulos directamente sobre el símbolo de la acción. Los pins de entrada (input pins) están marcados con un borde (un flujo de objeto) en la dirección de la acción. Para los pins de salida (output pins) la flecha se aleja de la acción. El siguiente gráfico muestra cómo se pueden acortar la representación de pins del mismo tipo (izquierda) o cómo se pueden dibujar pins de entrada y salida si se omiten los bordes (derecha).

Dentro de un diagrama de actividades UML, los tokens vagan por varias acciones hasta que la actividad concluye cuando el primer token llega al nodo final. Dado que este proceso puede incluir varios tokens al mismo tiempo, se requiere un determinado orden. Los nodos de control sirven para asegurar un flujo de proceso claro, gestionando exclusivamente los flujos de control en su trayecto desde el principio del diagrama de actividades hasta las acciones y el final de la actividad. Los nodos de control no pueden almacenar tokens en caché, a diferencia de nodos de objeto como el nodo de búfer.

Una diferencia significativa entre los flujos de objeto y de control es que solo los tokens de control se mueven en los flujos de control. A diferencia de los tokens de objeto, estos tokens no llevan ningún dato con ellos. Son meros marcadores. Por lo tanto, las acciones no requieren que los nodos de objeto (especialmente los pines) tomen y pasen las fichas de control. Un testigo de control inicia una acción, se mueve al siguiente y luego lo pone en movimiento. Por lo tanto, controla la ejecución cronológica de la actividad.

Entre los símbolos del diagrama de actividades UML, los nodos de control son probablemente los más diversos. Pertenecen a los nodos de actividad. UML 2 distingue seis tipos:

1. Los nodos de inicio (nodos iniciales) inician una actividad. Puede haber más de un nodo de inicio por operación. Si se inicia una operación, el nodo de inicio pone en movimiento inmediatamente el flujo de control. Si existen varios nodos de inicio, los respectivos flujos de control se inician simultáneamente. Los nodos de operación estructurados también pueden tener nodos de inicio. Estos también se inician inmediatamente al iniciar la actividad estructurada, siempre y cuando no se hayan establecido condiciones para su inicio. Puesto que los nodos iniciales están al principio, todos los indicadores son flechas de actividad salientes. Estos son siempre flujos de control. Otra característica especial de los nodos de inicio: las fichas de control colocadas en el nodo de inicio al comienzo de una actividad pueden permanecer allí si el flujo de control no acepta o bloquea la ficha ofrecida.
2. Los nodos finales detienen el flujo de una actividad. Hay dos tipos de nodos finales: el nodo final de la actividad termina toda la actividad destruyendo todos los tokens dentro de la actividad cuando recibe el primer token. Solo se conservan los testigos de objeto en la salida de los nodos de parámetros de actividad.

Todas las acciones sincrónicas también se detienen con él. Las acciones asíncronas se ejecutan hasta que se completan. Los nodos finales aceptan todos los tokens entrantes. A diferencia del nodo de inicio, un nodo final solo tiene flechas de actividad entrantes. Es posible más de un nodo final.

Si dibujas un diagrama de actividad con más de un nodo final, las acciones pueden detenerse antes de que hayan servido a su propósito, porque una ficha ya ha alcanzado el primer punto final. El nodo final de flujo detiene un flujo de control y destruye todos los tokens entrantes. Esto no afecta a otros movimientos de control. Por lo tanto, este nodo final es una alternativa práctica si se modelan varios puntos finales en el diagrama de actividades.

3. Nodos de paralelización y nodos de sincronización (nodos de horquilla y nodos de unión), también llamados horquillas, son nodos de control con una notación casi idéntica que refleja sus tareas.

Un nodo de paralelización divide una flecha de actividad entrante en varios flujos de salida simultáneos. Solo puede entrar una flecha en el nodo de paralelización. Si se trata de un flujo de control, todas las flechas de salida son también flujos de control; el mismo principio se aplica a los flujos de objetos. El nodo crea copias del token de entrada para todos los movimientos de salida. Si se acepta un token en el destino del flujo de salida, se borra del nodo fuente. Si otro objetivo no acepta su token, el nodo de paralelización puede excepcionalmente retener el token hasta que sea aceptado.

Los nodos de sincronización funcionan exactamente al revés. Varios bordes entran, pero sólo uno de ellos puede salir. Si la totalidad de los bordes de entrada consiste en flujos de control, también sale un flujo de control, y si entre ellos hay solo un flujo de objeto, UML especifica el borde de salida como flujo del objeto. Si también se reciben tokens de control, en este caso, caducarán y sólo saldrán los tokens de objeto. Si dos objetos tienen la misma identidad, el nodo los fusiona en un token. En general, los tokens solo pueden salir si todos los bordes entrantes ofrecen uno (operación and). Esto sucede bajo el principio first in first out (el que entra primero, sale el primero). Si se asigna una especificación de valor al nodo de sincronización con joinSpec, el nodo espera a los tokens que cumplen explícitamente estos requisitos antes de emitir tokens.

4. Los nodos de ramificación y los nodos de conexión (nodos de decisión y nodos de fusión) también comparten el mismo símbolo en el diagrama de actividad. La dirección del flujo es de nuevo la característica distintiva de estas anotaciones de nudos.

Un nodo de rama requiere al menos uno, pero no más de dos bordes entrantes. UML llama a uno primary incoming edge (borde primario entrante). A un segundo lo denomina flujo de entrada de decisiones (decision input flow). El que los flujos salientes representen a flujos de objeto o de control, depende del tipo de borde primario. La tarea del nodo es entonces decidir entre los bordes salientes, que le ofrecen sus nodos entrantes sin copiarlos. El token solo podrá tomar entonces un camino.