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

El diagrama de actividades es un tipo de diagrama dentro del lenguaje unificado de modelado (UML). Este lenguaje de modelado gráfico define formas para la representación de la programación orientada a objetos; en concreto, especifica 14 tipos de diagramas. A cada uno de ellos se le asignan determinados formularios y con la ayuda de reglas de notación, los sistemas y procesos pueden ser resumidos y representados claramente. UML no solo modela sistemas de software, sino también procesos empresariales. Los diagramas de actividades son útiles, sobre todo, en estas dos áreas. Pero ¿con qué propósito se crea un diagrama de actividad?

El propósito de los diagramas de actividad

Los diagramas de actividades UML pertenecen al grupo de diagramas de comportamiento en UML. Mientras que un diagrama de estructura registra el estado de un sistema, es decir, los objetos existentes y sus jerarquías, así como las conexiones entre ellos en un momento determinado, los diagramas de comportamiento describen el flujo cronológico de la circulación dedatos. Además del diagrama de actividades, el diagrama de caso de uso y el diagrama de máquina de estados también pertenecen a este grupo. Los diagramas de actividades son similares en su uso y notación a los diagramas de flujo (especialmente a los diagramas de programas), pero se adaptan a la programación orientada a objetos.

Básicamente se puede decir que el diagrama de actividades modela el flujo de actividades. Estos pueden ser procesos dentro de un sistema informático, procesos de casos de uso o procesos comerciales. Por ejemplo, la actividad “preparar una tortilla de queso” puede descomponerse en muchas actividades secundarias más pequeñas: las acciones, que pueden llevarse a cabocronológicamente. Una acción, por ejemplo, sería “cascar los huevos” y vendría seguida de la acción “batir los huevos con especias”. La segunda acción está supeditada a la primera. Están en un estado de evolución, por así decirlo.

También pueden representarse procesos paralelos. Por ejemplo, en el caso de que sean dos personas las que preparan la tortilla, es posible que las acciones de “cascar los huevos” y “picar las especias” sean simultáneas. Por lo tanto, la actividad tiene dos puntos de partida, desde los quelas personas comienzan su actividad, moviéndose de una acción a otra. En el diagrama de actividades, los dos actores de la acción (las dos personas) desempeñan un papel importante, pero no reciben notación propia. Se mueven de un punto de partida a un punto final, atravesando los flujos de prueba u objetos para pasar de una acción a la siguiente. En el camino hay obstáculos ocasionales, los llamados pines, que solo dejan pasar bajo ciertas condiciones, por ejemplo, cuando ambas personas están presentes.

En el diagrama de actividades, estas “personas” se denominan tokens. Hay dos tipos de token en el diagrama de actividades UML: el primero es el objeto token, que transmite información a los nodos de acción, inicia allí una acción y (si se especifica) almacena el resultado como un valor. Si el resultado y el token corresponden a las especificaciones definidas en un pin, este pin de salida envía el objeto token mediante un flujo de objetos a la siguiente acción. Antes de que el token pueda iniciar esta acción, debe cumplir con las especificaciones del pin de entrada. Los tokens de control, por otra parte, solo migran a través de flujos de control y sirven como marcadores. Inician una acción, pero no transmiten ningún dato.

En el ejemplo “preparar una tortilla de queso” de arriba utilizamos el diagrama de actividades para mostrar la secuencia cronológica de un caso de uso. Los diagramas de casos de uso, en cambio, representan los requisitos del sistema que deben cumplirse.

Por supuesto, los diagramas de actividades UML no solo se utilizan para casos de aplicación de la vida diaria. En primera instancia ayudan a presentar los procesos de los sistemas de software de forma estructurada y con ellos, los analistas económicos, por ejemplo, hacen especificaciones a los desarrolladores de software. Utilizando el lenguaje gráfico, los expertos intercambian información de forma clara y comprensible universalmente. Una vez que se han aclarado todos los procesos y se han eliminado los errores, el diagrama de actividades sirve como una plantilla limpia para la programación.

Si integras una herramienta UML en tu entorno de desarrollo integrado, el diagrama puede actuar como un marco de código utilizando la conversión XML como lenguaje de programación.

El Object Management Group (OMG), que especifica el lenguaje unificado de modelado (UML), resume las posibles tareas de los diagramas de actividades UML de la siguiente manera:

  • Programación informática procedimental que asigna jerarquías a las actividades.
  • En los modelos orientados a objetos, las actividades actúan como métodos que describen los procesos con más detalle.
  • Visualización de flujos de trabajo y procesos empresariales.
  • En el caso de los sistemas de aplicación asistidos por ordenador, las actividades especifican los procesos a nivel de sistema.

Las notaciones para los diagramas de actividades UML

Las formas dentro del UML pueden ser equiparadas a los componentes de las oraciones en un idioma. Por lo tanto, el lenguaje de modelado asigna un significado a cada forma. Los modificadores se encargan de describir las formas con más detalle y de relacionarlas entre sí. Además, hay que tener en cuenta que, a veces, las formas necesitan otras formas o etiquetas para crear un diagrama significativo. Del mismo modo que el lenguaje hablado solo tiene sentido si se respetan ciertas reglas gramaticales básicas, UML solo funciona como medio de comunicación si se respetan las especificaciones.

UML 2.5 es la especificación más reciente del lenguaje de modelado y, por lo tanto, constituirá la base de las indicaciones que siguen. UML determina la notación de los tipos de diagrama basándose en sus áreas de aplicación. Dado que el diagrama de actividades UML representa el flujo de los procesos del sistema y los casos de uso, el metamodelado le asigna los formularios apropiados.

¿Cómo se muestran visualmente los componentes individuales y qué funciones cumplen los símbolos en el diagrama de actividades UML?

Actividades

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.

Las actividades se consideran clases en UML (su metaclase es el comportamiento) que pueden definirse más concretamente con propiedades. Esto puede influir en los elementos subordinados. Una actividad se da por finalizada cuando un token se ha movido, a través de las diversas acciones, desde su punto de partida inicial hasta el punto final. El punto finaldestruye el token, así como a todos los demás tokens, de forma que la actividad detiene todas las acciones sincrónicas.

Nota

UML 1 define los diagramas de actividad de forma diferente a UML 2. La versión anterior les asignaba el papel de un diagrama de máquina de estados especializado, lo que limitaba sus áreas de aplicación. Si está utilizando una herramienta UML, debes asegurarte de que esta es compatible con la formulación deseada –lo ideal sería que se tratara de UML 2.5 o superior.

Acciones: nodos de actividad que representan el comportamiento

Una acción (en inglés, action, executable node) es un elemento del modelo que está jerárquicamente subordinado a la actividad: la acción es una instancia de la clase actividad. Las acciones representan a un comportamiento dentro de un sistema: son los bloques de construcción básicos utilizados para expresar el comportamiento en UML. Se utilizan tanto en los diagramas de actividades como en las interacciones.

Al crear un diagrama de actividades, se utiliza la notación “Acción” para representar las partes ejecutables de una actividad. En el ejemplo anterior, la acción de “pelar los espárragos y ponerlos en la olla” es un paso hacia la finalización de la actividad “cocinar los espárragos”. Las acciones reciben información de entrada, la procesan y producen información de salida. Una acción no se detiene hasta que se completa.

Dentro de los diagramas de actividades UML, las acciones pertenecen a los nodos de actividad. Las flechas conectan las acciones entre sí. UML distingue entre flujos de objetos (flujos de datos) y flujos de control (transporta tokens de control). Las acciones solo procesan flujos de control. Cuando los flujos de datos se mueven entre acciones, los pins (nodos de objetos) aceptan los tokens de objetos como entrada, los convierten para procesarlos en la acción y luego generan la salida de objetos que se mueve como tokens de objetos.

Hecho

La categoría Nodo de actividad se introdujo en UML 2. Existen tres subtipos: nodos de control, nodos de objeto y nodos ejecutables (las acciones). No hay jerarquías entre estos tres. Siempre que no estén conectados en cadena o definidos más estrechamente dentro de un grupo de actividades, pueden ejecutarse en cualquier orden (es decir, tan pronto como los tokens entrantes cumplan las condiciones de un nodo) o paralelamente.

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.

  1. 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.
  1. Laslink actionscambian 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.
  1. Laslink 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.
  1. Lasstructural 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.
  1. Lasvariable 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.
  1. 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.
  • Reply actions: tienen una conexión con las acciones de aceptar llamada. Por un lado, los desencadenantes deben coincidir para que la acción de respuesta, en el caso de un evento de llamada, pueda reaccionar a la acción de aceptación de llamada ejecutada previamente. Por otro lado, el comportamiento del cual depende coloca su valor de salida en el pin de entrada de información de retorno de la acción de respuesta.
  • Unmarshall actions: consultan los valores de las características de la estructura de referencia. Para reconocer el objeto, tienen un pin de entrada de objeto. Los valores obtenidos se emiten en un pin de salida.
Hecho

Si los datos estructurados de un objeto o también los datos elementales de un programa deben ser transferidos a otros programas o partes del programa, o si se desea almacenarlos, entonces se han de convertir en un formato adecuado para ello. Este proceso se llama marshalling. El proceso opuesto, unmarshalling (o unmarshaling), convierte estos datos “congelados” en objetos ejecutables. Un ejemplo de esto es la transferencia de diagramas UML de una herramienta a otra utilizando la conversión XML.

  1. Lasstructured 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.
  1. Las expansion regions son otro tipo de nodos de actividad estructurados. Aceptan como entrada a una o más colecciones devalores. 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.
  1. Lasreduce actions provocan un comportamiento hasta que un único valor emerge de una colección de valores. Para este fin, la acción combina los elementos de la colección. Por lo tanto, la acción tiene dos parámetros de entrada, pero sólo un parámetro de salida o retorno.
  2. Lasraise exception actions terminan por sí mismas tan pronto como causan una excepción. Por lo tanto, no terminan como las acciones normales, que se detienen cuando se completa la acción. Se extienden hacia el exterior a través del sistema hasta el siguiente nodo de actividad estructurado superior. Si tienes un controlador que coincide con la excepción, la acción se detiene. De lo contrario, sigue propagándose.

Nodos de objeto: nodos de actividad que dirigen tokens de objetos

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).
  1. Nodos de parámetros de actividad: la actividad pertenece a la metaclase de la descripción del comportamiento. Según UML, todo comportamiento tiene parámetros. Antes de que se ejecute un comportamiento, puedes alimentarlo con valores para su procesamiento. Una vez procesados, el sistema devuelve nuevos valores. En esta estructura, los parámetros son los marcadores de posición que permiten introducir o emitir estos valores. El nodo de parámetro de actividad se encarga de esto en el diagrama de actividades UML. Esto significa que los nodos de parámetros de actividad se encuentran al principio y al final de una actividad.

Como resultado, un nodo de este tipo tiene solo flechas de actividad de entrada o de salida. Los nodos de parámetros de actividad de entrada se dibujan con flechas de salida y los nodos de parámetros de actividad de salida con flechas de entrada. Hay un nodo de parámetro de actividad por parámetro, donde ambos son del mismo tipo.

  1. Nodo central de almacenamiento: al igual que los pins, el nodo tampón (nodo tampón central) se aplica directamente en el diagrama de actividades. Este nodo de objeto almacena los valores en cualquier punto del diagrama. Sin embargo, a diferencia de la clavija o pin, no está vinculada a un nodo de actividad. El nodo de buffer utiliza el flujo de objetos para conectar objetos entrantes y salientes con otros nodos de objetos, por ejemplo, con un pin.

El nodo de buffer se utiliza para grabar en memoria intermedia los flujos de objetos entrantes y salientes. Por lo tanto, acepta todos los tokens de objetos entrantes y los hace disponibles para flujos de objetos salientes. Solo cuando una nota de objeto se libera en el otro extremo del flujo y acepta los parámetros del objeto, reenvía el token. Según la notación UML, este nodo consiste en un simple rectángulo. Su función especial se indica con el estereotipo <<centralBuffer>>.

  1. Nodos de almacenamiento de datos: como los nodos de buffer, los nodos de almacenamiento de datos también se instalan entre flujos de objetos sin ligarlos a una acción. Este subtipo del nodo buffer tiene una característica especial: almacena una copia de cada token enviado hasta que la actividad a la que está supeditada se completa. Cada valor existe solo una vez en el nodo de almacenamiento de datos. Si el nodo ya almacena un objeto token con una identidad fija, no acepta tokens nuevos con exactamente las mismas propiedades. Como con todas las notas de objeto, el nodo de almacenamiento de datos se representa como un rectángulo. Para diferenciarlo, escribe el estereotipo <<datastore>> en la cabecera.

Nodos de control: nodos de actividad que dirigen los tokens de control

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 flujodetiene 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.

  1. 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.

  1. 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.

Un nodo de conexión agrupa varios movimientos entrantes en un único movimiento saliente. A diferencia del nodo de sincronización, el nodo de conexión no fusiona ningún token en uno nuevo ni sincroniza los tipos de bordes entrantes. Por lo tanto, para un flujo de control de salida, todos los bordes de entrada deben ser también flujos de control. Lo mismo se aplica a los flujos de objetos. El nodo de conexión simplemente ofrece todos los tokens recibidos para el borde de salida.

En resumen

Si deseas crear un diagrama de actividades con UML y editarlo en equipo, es importante obedecer a la notación. Esta es la única manera de asegurar la comprensión general de este lenguaje de modelado gráfico. En este artículo te presentamos los nodos y bordes de actividad más importantes con sus funciones. Además, mostramos todas las notaciones básicas y específicas de los diagramas de actividades de acuerdo con la especificación UML-2.5.1. La especificación exhaustiva de todos los símbolos del diagrama de actividades UML se puede encontrar en el sitio web de Object Management Group.


¡No te vayas! ¡Tenemos algo para ti!
Consigue tu dominio .es un año gratis.

Introduce el dominio que deseas en la barra de búsqueda para comprobar su disponibilidad.
12 meses desde 0€/año IVA incl.
después 12,10 €/año IVA incl.