Ejemplos de diagramas de actividad

Una tubería de construcción es el primer ejemplo más claro porque la concurrencia es real y no nocional. Las pruebas unitarias, el linting y el escaneo de dependencias corren de verdad a la vez, nada aguas abajo puede empezar hasta que las tres hayan terminado, y todo el mundo lo ha visto pasar.

El trabajo lo hacen las dos barras sólidas. La de arriba es una bifurcación: llega un token y salen tres, así que corren las tres ramas. La de abajo es una unión: espera hasta que haya llegado un token por cada arista entrante antes de dejar continuar a uno. Cambia cualquiera de las dos por un rombo y el diagrama pasa a afirmar algo falso: un rombo se dispara con el primer token y nunca espera.

Fíjate en los dos nodos finales separados. Una construcción fallida y una desplegada son finales distintos, y dibujarlos como dos discos con anillo es legal y más claro que encaminar ambos de vuelta a uno solo. UML no pone límite a cuántos nodos finales de actividad tiene una actividad.

La mayoría de los procesos de negocio no son concurrentes. Son una decisión con varios desenlaces que después se vuelven a juntar, que es la forma de abajo.

Tres cosas de este diagrama son deliberadas. Las guardas son exhaustivas: [sev 1], [sev 2 or 3] y [else] cubren entre todas cualquier ticket, así que ningún token puede llegar al rombo y no tener adónde ir. Un token sin arista de salida habilitada es un proceso detenido, y es un defecto que merece cazarse sobre el papel.

El rombo de abajo es una fusión, no una unión, y la diferencia importa: solo uno de los tres caminos lleva token alguna vez, así que esperar a los tres se bloquearía de inmediato. La regla es fácil de sostener: un rombo cierra lo que un rombo abrió, y una barra cierra lo que una barra abrió.

Por último, cada acción es una frase verbal en imperativo: «Avisar a la guardia», no «Aviso a la guardia». Los sustantivos se cuelan cuando alguien describe un sistema en vez de un proceso, y un diagrama de sustantivos es un diagrama de clases que ha tomado la forma equivocada.

El par de nodos de fin es el detalle que la mayoría de los primeros diagramas se equivoca, y el error es invisible: el diagrama sigue pareciendo correcto.

Tras la bifurcación hay dos tokens en vuelo. La rama de auditoría llega a un fin de flujo - el círculo con una cruz - que consume ese token y nada más. La rama del cliente llega a un fin de actividad, el disco con anillo, que termina toda la actividad y abandona cualquier otro token que haya en ella.

Pon el disco con anillo en la rama de auditoría y el diagrama pasa a decir que el pedido se abandona en cuanto se escribe la línea de registro. Nada en él parece mal, y por eso exactamente merece aprender la distinción una vez: usa un fin de flujo para una rama lateral que simplemente termina, y un fin de actividad solo donde quieras decir «ya está».

Estos tres cubren las formas de las que está hecho casi cualquier diagrama de actividad. Lo que cambia entre ellos y el tuyo son las etiquetas; lo que no debería cambiar es la disciplina sobre el alcance.

Si el público son analistas de negocio y no ingenieros, el mismo proceso suele quedar mejor dibujado en BPMN, que tiene una semántica de eventos más rica y es lo que ejecutará un motor de procesos. Las dos notaciones responden a la misma pregunta para salas distintas.