Archyno
UMLDiagramy správania

Príklady UML sekvenčných diagramov

Tri toky, každý potrebuje niečo, čo ostatné nie: prihlásenie, ktoré sa vetví, platba, ktorá sa opakuje, a udalosť, na ktorú nikto neodpovie.

6 min čítaniaUML 2.5.19 z 35

Krátka odpoveď

  • Prihlásenie je štandardný príklad, pretože sa vetví - a vetvenie je to, čo sekvenčný diagram dokáže a číslovaný zoznam nie.
  • Neúspešnú odpoveď dajte dovnútra fragmentu loop. Cyklus obsahujúci len požiadavku skrýva dôvod, prečo sa opakovanie deje.
  • Asynchrónna správa je plná čiara s otvoreným hrotom a bez odpovede. Chýbajúca návratová šípka je tvrdenie, nie opomenutie.
  • Takmer každý reálny tok pokryjú tri tvary: vetvenie, opakovací cyklus a správa, na ktorú nikto neodpovie.
UML sekvenčný diagram prihlásenia. Používateľ odošle prihlasovacie údaje na prihlasovaciu stránku, ktorá požiada identitnú službu o ich overenie. Vo vetve úspechu služba vydá token a stránka presmeruje na nástenku; vo vetve zlyhania zaznamená pokus a stránka zobrazí chybu.
Prihlásenie. Fragment alt nesie oba výsledky a vetva zlyhania robí vlastnú prácu.

01Prihlásenie, kde je pointou vetvenie#

Diagram vyššie čítajte ako dva príbehy so spoločným začiatkom. Všetko nad rámom alt sa deje tak či tak; vnútri neho beží práve jeden oddiel a stráže v hranatých zátvorkách hovoria ktorý. To je vec, ktorú sekvenčný diagram robí a číslovaný zoznam krokov nie, a preto je tento tok štandardným prvým príkladom.

Detail, ktorý sa oplatí okopírovať, je vo vetve zlyhania. Nevracia len chybu: najprv vystrelí record(failure)na log pokusov, nakreslené otvorenou hlavou šípky, lebo naň nič nečaká. Diagram, ktorého cesta zlyhania je jedna šípka s popiskou "chyba", je diagram, ktorý o ceste zlyhania nepremýšľal - a požiadavka na obmedzovanie pokusov, ktorú všetci objavia o tri týždne, býva presne v tej vetve.

02Platba, kde sú pointou slučka a volanie sebe#

UML sekvenčný diagram platby s opakovaniami. Pokladničná služba volá platobnú bránu až trikrát, kým je odpoveďou prechodné zlyhanie, medzi pokusmi počíta odstup, a potom zapíše výsledok do úložiska objednávok.
Opakovanie. Zlyhávajúca odpoveď je vnútri slučky, lebo je dôvodom, prečo slučka existuje.

Dve veci sa tu na prvom sekvenčnom diagrame neobjavia. Stráž fragmentu loop pomenúva zároveň hranicu aj podmienku - [3 times, while transient] - lebo slučka bez hranice je diagram sľubujúci výpadok a slučka bez podmienky nepovie, čo ju zastaví skôr.

Tou druhou je backoff(), správa z Checkout sebe samému, nakreslená ako šípka, ktorá opustí čiaru života a vráti sa na ňu. Volania sebe sa oplatí kresliť práve vtedy, keď je oneskorenie alebo rozhodnutie súčasťou príbehu - tu je celým dôvodom, prečo druhý pokus uspeje - a oplatí sa ich vynechať, keď sú obyčajnou vnútornou prácou.

Všimnite si aj to, čo tu nie je: žiadna čiarkovaná odpoveď po markPaid(orderId). Úložisko objednávok samozrejme odpovie, ale tá odpoveď nenesie nič, o čom by tento tok uvažoval, a kresliť každú odpoveď je spôsob, akým sa z diagramu šiestich zaujímavých správ stane diagram dvanástich.

03Udalosť, kde sa neodpovedá na nič#

UML sekvenčný diagram publikovania udalosti. Objednávková služba publikuje udalosť OrderPlaced do brokera, ktorý ju asynchrónne doručí skladovej službe a e-mailovej službe. Na žiadnu správu neprichádza odpoveď.
Publikovanie. Tri otvorené hlavy šípok, žiadne odpovede a žiadne tvrdenie o tom, kto beží prvý.

Toto je príklad, ktorý takmer nikto nekreslí, a ten, ktorý sa najviac oplatí mať. Každá šípka je asynchrónna - plná čiara, otvorená hlava - a nie je tu jediný čiarkovaný návrat. Objednávková služba publikuje a ide ďalej; sklad aj e-mailová služba udalosť dostanú a nič na tomto diagrame nehovorí, ktorá z nich skončí skôr, lebo to nehovorí ani nič v systéme.

Nakresliť tento tok s plnými hlavami šípok a odpoveďami by bol iný systém: taký, kde publikovanie blokuje, kým nedobehnú obaja konzumenti, čo je práve tá vlastnosť, ktorú broker existuje odstrániť. Notácia ich odlišuje a to odlíšenie má hodnotu väčšiu než kdekoľvek inde v UML.

Po jednom riadku na každé

  1. 01Fragment alt nesie každý výsledok; ak má stráž len jedna vetva, mysleli ste opt.
  2. 02Slučke dajte hranicu aj podmienku a zlyhávajúcu odpoveď nechajte vnútri nej.
  3. 03Otvorená hlava šípky plus žiadna odpoveď znamená asynchrónne. Nekreslite návrat, ktorý sa nestal.
  4. 04Volanie sebe kreslite, keď je oneskorenie alebo rozhodnutie súčasťou príbehu, nie pre obyčajnú vnútornú prácu.
  5. 05Vynechajte odpovede, ktoré nenesú nič, o čom by tok uvažoval.

Pre metódu namiesto príkladov si prečítajte ako nakresliť sekvenčný diagram; pre celú notáciu článok o sekvenčnom diagrame.

04Časté otázky#

Aký je dobrý príklad UML sekvenčného diagramu?

Prihlásenie je štandardný príklad, pretože sa vetví, a vetvenie je práve to, čo sekvenčný diagram dokáže a číslovaný zoznam nie. Okrem toho sa oplatí nakresliť opakovanie a asynchrónne publikovanie, pretože spolu pokryjú tri tvary, z ktorých sa skladá takmer každý reálny tok.

Ako zobraziť opakovanie v sekvenčnom diagrame?

Fragmentom loop okolo správ, ktoré sa opakujú, a strážou, ktorá pomenuje počet aj podmienku, napríklad trikrát, kým je chyba prechodná. Neúspešnú odpoveď nakreslite tiež dovnútra cyklu - cyklus obsahujúci len požiadavku skrýva dôvod, prečo sa opakovanie deje.

Ako sa kreslí asynchrónna správa?

Ako plná čiara s otvorenou hrotom šípky namiesto plnej hlavy, ktorú nesie synchrónne volanie, a bez návratovej šípky za ňou. Práve tá neprítomnosť odpovede je podstatná: odosielateľ nečakal, a prerušovaná návratová šípka by tvrdila opak.

V tejto sérii

Súvisiace články

Všetky články