Příklady diagramů aktivit

Build pipeline je nejjasnějším prvním příkladem, protože souběžnost je tu skutečná, ne pomyslná. Jednotkové testy, linting a sken závislostí opravdu běží naráz, nic dál po proudu nemůže začít, dokud všechny tři neskončí, a každý to už viděl.

Práci dělají ty dva plné pásy. Horní je rozvětvení: přijde jeden token a odejdou tři, takže běží všechny tři větve. Dolní je spojení: čeká, dokud token nepřijde po každé vstupní hraně, a teprve pak nechá jeden pokračovat. Vyměňte kterýkoli za kosočtverec a diagram teď tvrdí něco nepravdivého - kosočtverec se spustí u prvního tokenu a nikdy nečeká.

Všimněte si těch dvou samostatných koncových uzlů. Selhaný build a nasazený build jsou rozdílné konce a nakreslit je jako dva kotouče s prstencem je legální i jasnější než směrovat oba zpět do jednoho. UML neklade žádný limit na to, kolik koncových uzlů aktivity aktivita má.

Většina obchodních procesů není souběžná. Jsou to rozhodnutí s několika výsledky, které se později sejdou, a to je tvar níže.

Tři věci na tomhle diagramu jsou záměrné. Stráže jsou vyčerpávající: [sev 1], [sev 2 or 3] a [else] dohromady pokryjí každý tiket, takže žádný token nemůže dorazit ke kosočtverci a nenajít kam jít. Token bez povolené odchozí hrany je zastavený proces a je to vada, kterou se vyplatí zachytit na papíře.

Dolní kosočtverec je sloučení, ne spojení, a na tom rozdílu záleží: token nese vždy jen jedna z těch tří cest, takže čekat na všechny tři by se okamžitě zablokovalo. Pravidlo se snadno drží - kosočtverec zavírá to, co kosočtverec otevřel, a pás zavírá to, co otevřel pás.

Konečně, každá akce je slovesná fráze v rozkazovacím způsobu: „Přivolat pohotovost“, ne „Přivolávání pohotovosti“. Podstatná jména se vkrádají, když někdo popisuje systém místo procesu, a diagram podstatných jmen je diagram tříd, který nabral špatný tvar.

Dvojice koncových uzlů je detail, který většina prvních diagramů pokazí, a ta chyba je neviditelná: diagram pořád vypadá správně.

Za rozvětvením jsou v letu dva tokeny. Auditní větev dosáhne konce toku - kruhu s křížem - který spotřebuje ten token a nic jiného. Zákaznická větev dosáhne konce aktivity, kotouče s prstencem, který ukončí celou aktivitu a zahodí v ní každý další token.

Dejte kotouč s prstencem na auditní větev místo toho a diagram teď říká, že objednávka je opuštěná, jakmile se zapíše řádek do logu. Nic na něm nevypadá špatně, a právě proto se ten rozdíl vyplatí naučit jednou: konec toku použijte pro vedlejší větev, která prostě doběhne, a konec aktivity jen tam, kde myslíte „jsme hotovi“.

Tyhle tři pokrývají tvary, ze kterých je téměř každý diagram aktivit poskládaný. Mezi nimi a tím vaším se mění popisky; co by se měnit nemělo, je disciplína ohledně rozsahu.

Pokud jsou publikem byznys analytici a ne inženýři, tentýž proces bývá lépe nakreslit v BPMN, které má bohatší sémantiku událostí a je tím, co spustí procesní engine. Ty dvě notace odpovídají na tutéž otázku pro rozdílné místnosti.