Příklady diagramů aktivit
Tři diagramy aktivit procesů, které znáte - CI pipeline, třídění ticketů a fragment, který ukončuje dva tokeny různě - vždy s odůvodněním každého uzlu.
8 min čteníUML 2.5.114 z 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.
06Časté dotazy
Jaký je dobrý příklad diagramu aktivit?
Nejsrozumitelnější je CI pipeline: sestav artefakt, pak souběžně za vidlicí spusť testy, lintery a sken závislostí, počkej na všechny tři ve spojení a větvi se podle výsledku. Použije každý podstatný druh uzlu v asi deseti boxech.
Jak se v diagramu aktivit kreslí souběžné kroky?
Přes tok položte plný pruh - vidlici - a z něj veďte jednu hranu do každé souběžné akce. Skupinu uzavřete druhým pruhem, spojením, které počká na token na každé vstupní hraně. Na hranách vycházejících z vidlice nikdy nejsou stráže, protože se použijí všechny.
Jaký je rozdíl mezi koncem toku a koncem aktivity?
Konec toku, kruh s křížem, ukončí token, který k němu dorazí, a zbytek aktivity běží dál. Konec aktivity, kroužkovaný kruh, ukončí celou aktivitu a zahodí všechny ostatní tokeny. Použít kroužkovaný kruh na vedlejší větvi tiše zabije hlavní tok.
Musí stráže vycházející z rozhodnutí pokrýt každý případ?
Ano. Pokud neplatí žádná stráž, token nemá kam jít a aktivita uvázne, což je skutečná vada, ne kosmetika. Bezpečný zvyk je dát poslední hraně stráž [else], čímž se množina stane vyčerpávající z konstrukce.
Kolik akcí má mít jeden diagram aktivit?
Zhruba patnáct, pak přestává být čitelný. Nad tento počet vyjměte podstrom jako samostatnou aktivitu a odkazujte na ni jedinou volací akcí. Diagram, který je třeba přiblížit, je diagram, který nikdo neporovnává s realitou.
Související články