Ejemplos de diagramas de actividad
Tres diagramas de actividad de procesos que ya conoce - una tubería de integración continua, un triaje de tickets y un fragmento que termina dos tokens de forma distinta - cada uno con el razonamiento de cada nodo.
8 min de lecturaUML 2.5.114 de 35
01Example 1: parallel work behind a fork
A build pipeline is the clearest first example because the concurrency is real rather than notional. Unit tests, linting and a dependency scan genuinely run at once, nothing downstream can start until all three have finished, and everybody has watched it happen.
The two solid bars are doing the work. The upper one is a fork: one token arrives and three leave, so all three branches run. The lower one is a join: it waits until a token has arrived on every incoming edge before letting one continue. Swap either for a diamond and the diagram now claims something false - a diamond fires on the first token through and never waits.
Note the two separate final nodes. A failed build and a deployed build are different endings, and drawing them as two ringed discs is both legal and clearer than routing both back into one. UML puts no limit on how many activity final nodes an activity has.
02Example 2: a three-way branch with exhaustive guards
Most business processes are not concurrent. They are a decision with several outcomes that later come back together, which is the shape below.
Three things in this diagram are deliberate. The guards are exhaustive: [sev 1], [sev 2 or 3] and [else] between them cover every ticket, so no token can arrive at the diamond and find nowhere to go. A token with no enabled outgoing edge is a stalled process, and it is a defect worth catching on paper.
The lower diamond is a merge, not a join, and the difference matters: only one of the three paths ever carries a token, so waiting for all three would deadlock immediately. The rule is easy to hold - a diamond opens what a diamond closes, and a bar closes what a bar opened.
Finally, every action is a verb phrase in the imperative: “Page on-call”, not “On-call paging”. Nouns creep in when somebody is describing a system rather than a process, and a diagram of nouns is a class diagram that has taken the wrong shape.
03Example 3: the two ways a flow can end
The pair of ending nodes is the detail most first diagrams get wrong, and the mistake is invisible: the diagram still looks right.
After the fork, two tokens are in flight. The audit branch reaches a flow final - the circle with a cross - which consumes that token and nothing else. The customer branch reaches an activity final, the ringed disc, which ends the whole activity and abandons every other token in it.
Put the ringed disc on the audit branch instead, and the diagram now says the order is abandoned as soon as the log line is written. Nothing about it looks wrong, which is exactly why the distinction is worth learning once: use a flow final for a side branch that simply finishes, and an activity final only where you mean “we are done”.
04Turning these into your own
These three cover the shapes almost every activity diagram is made of. What changes between them and yours is the labels; what should not change is the discipline about scope.
Reach for it when
- One process per diagram, with a name you could put in an email subject line.
- Verb-phrase actions, so each box is something somebody or something does.
- Swimlanes when the handoffs between roles are the point - lane crossings are where processes fail.
- A guard of [else] on the last edge out of every decision, so the set is exhaustive.
Reach for something else when
- More than about fifteen actions. Extract a subtree as its own activity instead.
- A bar where alternatives rejoin, or a diamond where concurrent work does.
- Error handling for every step. Draw the happy path, then one diagram for the failure that matters.
- Modelling a single object's lifecycle - that is a state machine, not an activity.
If the audience is business analysts rather than engineers, the same process is usually better drawn in BPMN, which has richer event semantics and is what a process engine will execute. The two notations answer the same question for different rooms.
05What to remember
In one line each
- 01A bar forks and joins; a diamond branches and merges. A diamond never waits, and a bar always does.
- 02Guards belong on edges out of a decision and never on edges out of a fork.
- 03Make the guard set exhaustive - [else] on the last edge - or the process can stall.
- 04A flow final ends one token; an activity final ends everything. The wrong one looks identical.
- 05Actions are verb phrases. If the boxes are nouns, you are drawing the wrong diagram.
06Preguntas frecuentes
¿Cuál es un buen ejemplo de diagrama de actividad?
Una tubería de integración continua es el más claro: construir el artefacto, lanzar en paralelo tras una bifurcación las pruebas, los linters y el escaneo de dependencias, esperar a los tres en la unión y ramificar según el resultado. Usa todos los nodos que importan en unas diez cajas.
¿Cómo se dibujan pasos paralelos en un diagrama de actividad?
Ponga una barra sólida - la bifurcación - cruzando el flujo y saque una arista hacia cada acción concurrente. Cierre el grupo con una segunda barra, la unión, que espera un token en cada arista entrante. Las aristas que salen de una bifurcación nunca llevan guarda, porque se toman todas.
¿Qué diferencia hay entre un final de flujo y un final de actividad?
El final de flujo, un círculo con una cruz, termina el token que llega a él y deja el resto de la actividad en marcha. El final de actividad, un disco con anillo, termina toda la actividad y descarta los demás tokens. Poner el disco con anillo en una rama secundaria mata en silencio el flujo principal.
¿Las guardas que salen de una decisión deben cubrir todos los casos?
Sí. Si no se cumple ninguna guarda, el token no tiene adónde ir y la actividad se detiene, lo cual es un defecto real y no un detalle de estilo. La costumbre segura es dar a la última arista la guarda [else], con lo que el conjunto queda exhaustivo por construcción.
¿Cuántas acciones debe tener un diagrama de actividad?
Unas quince antes de dejar de ser legible. Por encima de eso, extraiga un subárbol como actividad propia y referéncielo con una única acción de llamada. Un diagrama que hay que ampliar es un diagrama que nadie contrasta con la realidad.
Lecturas relacionadas