Príklady diagramov aktivít
Tri diagramy aktivít procesov, ktoré poznáte - CI pipeline, triedenie tiketov a fragment, ktorý ukončuje dva tokeny rôzne - vždy s odôvodnením každého uzla.
8 min čítaniaUML 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é otázky
Aký je dobrý príklad diagramu aktivít?
Najzrozumiteľnejšia je CI pipeline: zostav artefakt, potom súbežne za vidlicou spusti testy, lintery a sken závislostí, počkaj na všetky tri v spojení a rozvetv sa podľa výsledku. Použije každý podstatný druh uzla v asi desiatich boxoch.
Ako sa v diagrame aktivít kreslia súbežné kroky?
Cez tok položte plný pruh - vidlicu - a z neho veďte jednu hranu do každej súbežnej akcie. Skupinu uzavrite druhým pruhom, spojením, ktoré počká na token na každej vstupnej hrane. Na hranách vychádzajúcich z vidlice nikdy nie sú stráže, lebo sa použijú všetky.
Aký je rozdiel medzi koncom toku a koncom aktivity?
Koniec toku, kruh s krížom, ukončí token, ktorý k nemu dorazí, a zvyšok aktivity beží ďalej. Koniec aktivity, krúžkovaný kruh, ukončí celú aktivitu a zahodí všetky ostatné tokeny. Použiť krúžkovaný kruh na vedľajšej vetve ticho zabije hlavný tok.
Musia stráže vychádzajúce z rozhodnutia pokryť každý prípad?
Áno. Ak neplatí žiadna stráž, token nemá kam ísť a aktivita uviazne, čo je skutočná chyba, nie kozmetika. Bezpečný zvyk je dať poslednej hrane stráž [else], čím sa množina stane vyčerpávajúcou z konštrukcie.
Koľko akcií má mať jeden diagram aktivít?
Zhruba pätnásť, potom prestáva byť čitateľný. Nad tento počet vyberte podstrom ako samostatnú aktivitu a odkazujte naň jedinou volacou akciou. Diagram, ktorý treba priblížiť, je diagram, ktorý nikto neporovnáva s realitou.
Súvisiace články