Diagramas de ac­ti­vi­da­des: el flujo de trabajo re­pre­se­n­ta­do grá­fi­ca­me­n­te

En UML 2 una actividad (activity en inglés) es un co­m­po­r­ta­mie­n­to que supedita las unidades su­bo­r­di­na­das (acciones y objetos) a una secuencia cro­no­ló­gi­ca. Para ello, utiliza modelos de flujo de datos y de control. El diagrama de ac­ti­vi­da­des se puede vi­sua­li­zar como parte de un sistema más grande junto con otros tipos de diagrama. Un re­c­tá­n­gu­lo grande y re­do­n­dea­do marca la actividad como un sistema cerrado (aunque puede omitirse). En la imagen de ejemplo, más abajo, se puede ver la actividad “Cocinar es­pá­rra­gos”. En el en­ca­be­za­do del re­c­tá­n­gu­lo grande se escribe el título. El cuerpo contiene flechas (bordes, edges en inglés) y re­c­tá­n­gu­los que si­m­bo­li­zan las acciones, los objetos y los flujos de datos o de control de la operación.

Solo cuando se cumplen las co­n­di­cio­nes es­pe­ci­fi­ca­das en los pines, los datos in­tro­du­cen 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 re­c­tá­n­gu­lo re­do­n­dea­do. Sin embargo, los mo­de­la­do­res también pueden recurrir a acciones es­pe­cí­fi­cas para obtener de­s­cri­p­cio­nes más de­ta­lla­das. UML emplea su propia notación para expresar algunas de ellas:

1. Opaque actions son “acciones opacas”. Actúan como ma­r­ca­do­res de posición o se es­pe­ci­fi­can mediante una sintaxis de texto concreta (no definida por UML).
2. In­vo­ca­tion actions son acciones que causan un cierto co­m­po­r­ta­mie­n­to, tanto directa como in­di­re­c­ta­me­n­te. Esto incluye:

• Call actions: Una call behavior action es una llamada directa a un co­m­po­r­ta­mie­n­to. Una call operation action, en cambio, envía una petición a un objeto que llama a un co­m­po­r­ta­mie­n­to asociado. La start object behavior action hace que un objeto ejecute di­re­c­ta­me­n­te su co­m­po­r­ta­mie­n­to de instancia. Si no se determina ninguna, puede des­en­ca­de­nar el co­m­po­r­ta­mie­n­to de clase de nivel superior (cla­s­si­fier behavior).

La notación de una acción que origina un co­m­po­r­ta­mie­n­to es un re­c­tá­n­gu­lo re­do­n­dea­do y en él deberás in­tro­du­cir el nombre del co­m­po­r­ta­mie­n­to. Las call behavior actions también están marcadas con un símbolo de tridente (como se muestra en la imagen de abajo). Esto re­pre­se­n­ta la ra­mi­fi­ca­ción je­rá­r­qui­ca adicional creada por la acción.

• Send actions: en el diagrama de ac­ti­vi­da­des, las acciones de envío siempre envían datos asi­n­cró­ni­ca­me­n­te (los diagramas de secuencia también conocen los mensajes si­n­cró­ni­cos). 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 ar­gu­me­n­tos como, por ejemplo, pa­rá­me­tros, pero no produce una salida de re­su­l­ta­dos. Además, los mensajes pueden ir a varios de­s­ti­na­ta­rios 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 re­c­tá­n­gu­lo re­do­n­dea­do) y en su lugar un pentágono indica la dirección de la señal tra­n­s­mi­ti­da 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 in­s­ta­n­cias de una clase). Puedes crearlos o de­s­trui­r­los, co­m­pa­rar­los con otras in­s­ta­n­cias, leerlos y luego asi­g­nar­los a una clase o modificar la cla­si­fi­ca­ción. Las in­s­ta­n­cias de acciones de objetos existen bajo UML 2 son las si­guie­n­tes:

• Las create object actions generan in­s­ta­n­cias 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 re­pre­se­n­tan el mismo objeto.
• Read self actions, de­te­r­mi­nan su propio objeto de contexto.
• Value spe­ci­fi­ca­tion actions, examinan las es­pe­ci­fi­ca­cio­nes de valor. La notación lleva la etiqueta value spe­ci­fi­ca­tion.
• Read extent actions, en­cue­n­tran todos los objetos de una clase, así como los objetos de sus es­pe­ci­fi­ca­cio­nes. Por razones prácticas, los mo­de­la­do­res suelen limitar el radio de alcance.
• Re­cla­s­si­fy object actions, cambian la clase del objeto en el pin de entrada.
• Read is cla­s­si­fied object actions, de­te­r­mi­nan si un objeto en el pin de entrada pertenece a una clase.
• Start cla­s­si­fier behavior actions des­en­ca­de­nan un co­m­po­r­ta­mie­n­to para un objeto que está de­te­r­mi­na­do por su clase. El co­m­po­r­ta­mie­n­to es entonces asi­n­cró­ni­co.

4. Las link actions cambian el co­m­po­r­ta­mie­n­to de las aso­cia­cio­nes (las re­la­cio­nes entre cla­si­fi­ca­do­res, por lo general de dos clases) y sus in­s­ta­n­cias, los enlaces. Aquí se incluyen:

• Read link actions: recuperan valores (datos de fin de enlace) en una página de una aso­cia­ció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 co­rre­s­po­n­den a un valor de datos del extremo del enlace es­pe­ci­fi­ca­do.

5. Las link object actions influyen en el co­m­po­r­ta­mie­n­to de los objetos enlazados de forma similar a las link actions, pero co­n­si­de­ran los objetos desde otros puntos de vista. Estas son las in­s­ta­n­cias 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 cla­si­fi­ca­dor de los objetos de enlace.
• Create link object actions, que son acciones Create link es­pe­cia­les que se pueden utilizar para crear objetos de enlace.

6. Las stru­c­tu­ral feature actions de­te­r­mi­nan el co­m­po­r­ta­mie­n­to de las ca­ra­c­te­rí­s­ti­cas es­tru­c­tu­ra­les en los diagramas de ac­ti­vi­da­des. Para ello necesitan un pin de entrada, ya que no­r­ma­l­me­n­te se les asigna un objeto y una ca­ra­c­te­rí­s­ti­ca es­tru­c­tu­ral de un cla­si­fi­ca­dor es­pe­ci­fi­ca­da es­tá­ti­ca­me­n­te. La acción de las ca­ra­c­te­rí­s­ti­cas es­tru­c­tu­ra­les afecta a ambos elementos. Existen los si­guie­n­tes tipos:

• Read stru­c­tu­ral feature action: leen los valores de las ca­ra­c­te­rí­s­ti­cas es­tru­c­tu­ra­les y los tra­n­s­mi­ten como salida.
• Add stru­c­tu­ral feature value actions: requieren un pin de entrada de valores. Es­pe­ci­fi­can el valor que la acción asigna a una ca­ra­c­te­rí­s­ti­ca es­tru­c­tu­ral.
• Remove stru­c­tu­ral feature value actions: restan un valor de una ca­ra­c­te­rí­s­ti­ca es­tru­c­tu­ral. Un pin de entrada de valores con mu­l­ti­pli­ci­dad 1..1 es­pe­ci­fi­ca este valor.
• Clear stru­c­tu­ral feature actions: eliminan todos los valores de un elemento de es­tru­c­tu­ra.

7. Las variable actions influyen en las variables es­pe­ci­fi­ca­das es­tá­ti­ca­me­n­te que están definidas por una actividad o un nodo de actividad es­tru­c­tu­ra­do. 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 exac­ta­me­n­te un valor.
• Remove variable value actions, eliminan un valor es­pe­ci­fi­ca­do por el pin.
• Clear variable actions, eliminan todos los valores de una variable.

8. Accept event actions: pe­r­te­ne­cen 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 des­en­ca­de­na­n­tes que provocan la acción cuando se producen uno o más estados pre­s­cri­tos. UML describe tres es­pe­cia­li­za­cio­nes:

• Accept call actions: tienen un di­s­pa­ra­dor que acepta eventos de llamada. Dos pins de salida de re­su­l­ta­dos y un pin de salida de in­fo­r­ma­ción de retorno completan el acuerdo. Si se debe ejecutar una acción de respuesta, la in­fo­r­ma­ción necesaria para ello se almacena en el pin de salida de in­fo­r­ma­ción de retorno.

9. Las stru­c­tu­red actions están de­cla­ra­das en el diagrama de ac­ti­vi­da­des con UML 2 como una acción y como un grupo de ac­ti­vi­da­des (ver arriba). Esto significa, por un lado, que su co­m­po­r­ta­mie­n­to está de­te­r­mi­na­do por los nodos de actividad y las flechas y, por el otro, que ciertos subtipos de estas acciones pre­s­cri­ben un de­te­r­mi­na­do co­m­po­r­ta­mie­n­to para los nodos eje­cu­ta­bles debido a su semántica, en pa­r­ti­cu­lar con respecto a su secuencia.

Estos son los subtipos de acciones es­tru­c­tu­ra­das:

• Co­n­di­tio­nal nodes, consisten en una o más cláusulas que re­pre­se­n­tan las di­fe­re­n­tes ramas de las posibles acciones eje­cu­ta­bles. Una cláusula contiene un segmento de prueba y un segmento de cuerpo, que a su vez incluyen nodos eje­cu­ta­bles 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: co­n­fi­gu­ra­ción, prueba y cuerpo. El bucle siempre ejecuta la co­n­fi­gu­ra­ción primero, seguido por una prueba o cuerpo que luego se repetirá al­te­r­na­ti­va­me­n­te.
• Sequence nodes, imponen una secuencia a los nodos eje­cu­ta­bles dentro de sus límites. Estos se re­pre­se­n­tan con flujos de datos como flechas, que pueden apuntar hacia dentro o hacia fuera de la es­tru­c­tu­ra.

10. Las expansion regions son otro tipo de nodos de actividad es­tru­c­tu­ra­dos. Aceptan como entrada a una o más co­le­c­cio­nes 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 re­c­tá­n­gu­lo re­do­n­dea­do con una línea de puntos. Los nodos de expansión aparecen como re­c­tá­n­gu­los con segmentos y, como se muestra a co­n­ti­nua­ción, se dibujan di­re­c­ta­me­n­te en la línea. La se­g­me­n­ta­ción debe re­pre­se­n­tar la lista de co­le­c­cio­nes 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 re­pre­se­n­tan datos en el diagrama de ac­ti­vi­da­des. 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 in­tro­du­je­ron por primera vez en el diagrama de ac­ti­vi­da­des del UML-2. Son elementos ti­pi­fi­ca­dos. Si un nodo de objeto co­rre­s­po­n­de a un de­te­r­mi­na­do tipo, los tokens de objeto que se mueven sobre él deben tener valores co­rre­s­po­n­die­n­tes. Una excepción son los tokens nulos que no tienen valor, aju­s­tá­n­do­se a cada nodo de objeto.

Los nodos de objeto pre­s­cri­ben el orden en el que los tokens los dejan. Hay cuatro maneras de hacerlo:

• Des­or­de­na­do (no es­pe­ci­fi­ca­do)
• Ordenado (co­m­po­r­ta­mie­n­to 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 exac­ta­me­n­te el opuesto.

Si deseas crear un diagrama de ac­ti­vi­da­des, 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 mo­de­la­do­res suelen di­bu­jar­los como pequeños re­c­tá­n­gu­los di­re­c­ta­me­n­te 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 re­pre­se­n­ta­ció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 ac­ti­vi­da­des 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 de­te­r­mi­na­do orden. Los nodos de control sirven para asegurar un flujo de proceso claro, ge­s­tio­na­n­do ex­clu­si­va­me­n­te los flujos de control en su trayecto desde el principio del diagrama de ac­ti­vi­da­des hasta las acciones y el final de la actividad. Los nodos de control no pueden almacenar tokens en caché, a di­fe­re­n­cia de nodos de objeto como el nodo de búfer.

Una di­fe­re­n­cia si­g­ni­fi­ca­ti­va entre los flujos de objeto y de control es que solo los tokens de control se mueven en los flujos de control. A di­fe­re­n­cia de los tokens de objeto, estos tokens no llevan ningún dato con ellos. Son meros ma­r­ca­do­res. Por lo tanto, las acciones no requieren que los nodos de objeto (es­pe­cia­l­me­n­te 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 mo­vi­mie­n­to. Por lo tanto, controla la ejecución cro­no­ló­gi­ca de la actividad.

Entre los símbolos del diagrama de ac­ti­vi­da­des UML, los nodos de control son pro­ba­ble­me­n­te los más diversos. Pe­r­te­ne­cen 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 mo­vi­mie­n­to in­me­dia­ta­me­n­te el flujo de control. Si existen varios nodos de inicio, los re­s­pe­c­ti­vos flujos de control se inician si­mu­l­tá­nea­me­n­te. Los nodos de operación es­tru­c­tu­ra­dos también pueden tener nodos de inicio. Estos también se inician in­me­dia­ta­me­n­te al iniciar la actividad es­tru­c­tu­ra­da, siempre y cuando no se hayan es­ta­ble­ci­do co­n­di­cio­nes para su inicio. Puesto que los nodos iniciales están al principio, todos los in­di­ca­do­res son flechas de actividad salientes. Estos son siempre flujos de control. Otra ca­ra­c­te­rí­s­ti­ca especial de los nodos de inicio: las fichas de control colocadas en el nodo de inicio al comienzo de una actividad pueden pe­r­ma­ne­cer 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 de­s­tru­ye­n­do 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 pa­rá­me­tros de actividad.

Todas las acciones si­n­cró­ni­cas también se detienen con él. Las acciones así­n­cro­nas se ejecutan hasta que se completan. Los nodos finales aceptan todos los tokens entrantes. A di­fe­re­n­cia 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 mo­vi­mie­n­tos de control. Por lo tanto, este nodo final es una al­te­r­na­ti­va práctica si se modelan varios puntos finales en el diagrama de ac­ti­vi­da­des.

3. Nodos de pa­ra­le­li­za­ción y nodos de si­n­cro­ni­za­ción (nodos de horquilla y nodos de unión), también llamados ho­r­qui­llas, son nodos de control con una notación casi idéntica que refleja sus tareas.

Un nodo de pa­ra­le­li­za­ción divide una flecha de actividad entrante en varios flujos de salida si­mu­l­tá­neos. Solo puede entrar una flecha en el nodo de pa­ra­le­li­za­ció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 mo­vi­mie­n­tos 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 pa­ra­le­li­za­ción puede ex­ce­p­cio­na­l­me­n­te retener el token hasta que sea aceptado.

Los nodos de si­n­cro­ni­za­ción funcionan exac­ta­me­n­te 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 es­pe­ci­fi­ca 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 es­pe­ci­fi­ca­ción de valor al nodo de si­n­cro­ni­za­ción con joinSpec, el nodo espera a los tokens que cumplen ex­plí­ci­ta­me­n­te estos re­qui­si­tos antes de emitir tokens.

4. Los nodos de ra­mi­fi­ca­ció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 ca­ra­c­te­rí­s­ti­ca di­s­ti­n­ti­va de estas ano­ta­cio­nes 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 de­ci­sio­nes (decision input flow). El que los flujos salientes re­pre­se­n­ten 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.