Archyno
UMLDiagramy chování

Příklady UML sekvenčních diagramů

Tři toky, každý potřebuje něco, co ostatní ne: přihlášení, které se větví, platba, která se opakuje, a událost, na kterou nikdo neodpoví.

6 min čteníUML 2.5.19 z 35

Krátká odpověď

  • Přihlášení je standardní příklad, protože se větví - a větvení je to, co sekvenční diagram umí a číslovaný seznam ne.
  • Neúspěšnou odpověď dejte dovnitř fragmentu loop. Cyklus obsahující jen požadavek skrývá důvod, proč se opakování děje.
  • Asynchronní zpráva je plná čára s otevřeným hrotem a bez odpovědi. Chybějící návratová šipka je tvrzení, ne opomenutí.
  • Téměř každý reálný tok pokryjí tři tvary: větvení, opakovací cyklus a zpráva, na kterou nikdo neodpoví.
UML sekvenční diagram přihlášení. Uživatel odešle přihlašovací údaje na přihlašovací stránku, která požádá identitní službu o jejich ověření. Ve větvi úspěchu služba vydá token a stránka přesměruje na nástěnku; ve větvi selhání zaznamená pokus a stránka zobrazí chybu.
Přihlášení. Fragment alt nese oba výsledky a větev selhání dělá vlastní práci.

01Přihlášení, kde je pointou větvení#

Diagram výše čtěte jako dva příběhy se společným začátkem. Všechno nad rámem alt se děje tak jako tak; uvnitř něj běží právě jeden oddíl a stráže v hranatých závorkách říkají který. To je věc, kterou sekvenční diagram dělá a číslovaný seznam kroků ne, a proto je tenhle tok standardním prvním příkladem.

Detail, který se vyplatí okopírovat, je ve větvi selhání. Nevrací jen chybu: nejdřív vystřelí record(failure)na log pokusů, nakreslené otevřenou hlavou šipky, protože na něj nic nečeká. Diagram, jehož cesta selhání je jedna šipka s popiskem "chyba", je diagram, který o cestě selhání nepřemýšlel - a požadavek na omezení pokusů, který všichni objeví za tři týdny, bývá přesně v té větvi.

02Platba, kde jsou pointou smyčka a volání sobě#

UML sekvenční diagram platby s opakováními. Pokladní služba volá platební bránu až třikrát, dokud je odpovědí přechodné selhání, mezi pokusy počítá odstup, a pak zapíše výsledek do úložiště objednávek.
Opakování. Selhávající odpověď je uvnitř smyčky, protože je důvodem, proč smyčka existuje.

Dvě věci se tu na prvním sekvenčním diagramu neobjeví. Stráž fragmentu loop pojmenovává zároveň mez i podmínku - [3 times, while transient] - protože smyčka bez meze je diagram slibující výpadek a smyčka bez podmínky neřekne, co ji zastaví dřív.

Tou druhou je backoff(), zpráva z Checkout sobě samému, nakreslená jako šipka, která opustí čáru života a vrátí se na ni. Volání sobě se vyplatí kreslit právě tehdy, když je zpoždění nebo rozhodnutí součástí příběhu - tady je celým důvodem, proč druhý pokus uspěje - a vyplatí se je vynechat, když jsou obyčejnou vnitřní prací.

Všimněte si i toho, co tu není: žádná čárkovaná odpověď po markPaid(orderId). Úložiště objednávek samozřejmě odpoví, ale ta odpověď nenese nic, o čem by tenhle tok uvažoval, a kreslit každou odpověď je způsob, jakým se z diagramu šesti zajímavých zpráv stane diagram dvanácti.

03Událost, kde se neodpovídá na nic#

UML sekvenční diagram publikování události. Objednávková služba publikuje událost OrderPlaced do brokera, který ji asynchronně doručí skladové službě a e-mailové službě. Na žádnou zprávu nepřichází odpověď.
Publikování. Tři otevřené hlavy šipek, žádné odpovědi a žádné tvrzení o tom, kdo běží první.

Tohle je příklad, který téměř nikdo nekreslí, a ten, který se nejvíc vyplatí mít. Každá šipka je asynchronní - plná čára, otevřená hlava - a není tu jediný čárkovaný návrat. Objednávková služba publikuje a jde dál; sklad i e-mailová služba událost dostanou a nic na tomhle diagramu neříká, která z nich skončí dřív, protože to neříká ani nic v systému.

Nakreslit tenhle tok s plnými hlavami šipek a odpověďmi by byl jiný systém: takový, kde publikování blokuje, dokud nedoběhnou oba konzumenti, což je právě ta vlastnost, kterou broker existuje odstranit. Notace je odlišuje a to odlišení má hodnotu větší než kdekoli jinde v UML.

Po jednom řádku na každé

  1. 01Fragment alt nese každý výsledek; pokud má stráž jen jedna větev, mysleli jste opt.
  2. 02Smyčce dejte mez i podmínku a selhávající odpověď nechte uvnitř ní.
  3. 03Otevřená hlava šipky plus žádná odpověď znamená asynchronně. Nekreslete návrat, který se nestal.
  4. 04Volání sobě kreslete, když je zpoždění nebo rozhodnutí součástí příběhu, ne pro obyčejnou vnitřní práci.
  5. 05Vynechte odpovědi, které nenesou nic, o čem by tok uvažoval.

Pro metodu místo příkladů si přečtěte jak nakreslit sekvenční diagram; pro celou notaci článek o sekvenčním diagramu.

04Časté dotazy#

Jaký je dobrý příklad UML sekvenčního diagramu?

Přihlášení je standardní příklad, protože se větví, a větvení je právě to, co sekvenční diagram umí a číslovaný seznam ne. Kromě toho se vyplatí nakreslit opakování a asynchronní publikování, protože společně pokryjí tři tvary, ze kterých se skládá téměř každý reálný tok.

Jak zobrazit opakování v sekvenčním diagramu?

Fragmentem loop kolem zpráv, které se opakují, a stráží, která pojmenuje počet i podmínku, například třikrát, dokud je chyba přechodná. Neúspěšnou odpověď nakreslete také dovnitř cyklu - cyklus obsahující jen požadavek skrývá důvod, proč se opakování děje.

Jak se kreslí asynchronní zpráva?

Jako plná čára s otevřeným hrotem šipky místo plné hlavy, kterou nese synchronní volání, a bez návratové šipky za ní. Právě ta nepřítomnost odpovědi je podstatná: odesílatel nečekal, a přerušovaná návratová šipka by tvrdila opak.

V této sérii

Související články

Všechny články