Unified Modeling Language (UML) je modelovací jazyk v oblasti softwarového inženýrství, jehož cílem je nastavit standardní způsoby vizualizace návrhu systému. UML vede vytváření různých typů diagramů, jako jsou diagramy interakce, struktury a chování. A sekvenční diagram je nejčastěji používaný interakce diagram.

Interakční diagram

Interakční diagram se používá k zobrazení interaktivní chování systému. Protože vizualizace interakcí v systému může být obtížná, používáme různé typy interakčních diagramů k zachycení různých funkcí a aspektů interakce v systému.

• Sekvenční diagram jednoduše zobrazuje interakci mezi objekty v sekvenčním pořadí, tj. v pořadí, ve kterém k těmto interakcím dochází.
• K označení sekvenčního diagramu můžeme také použít termíny diagramy událostí nebo scénáře událostí.
• Sekvenční diagramy popisují, jak a v jakém pořadí objekty v systému fungují.
• Tyto diagramy jsou široce používány obchodníky a vývojáři softwaru k dokumentaci a pochopení požadavků na nové a stávající systémy.

Důležitá témata pro sekvenční diagramy

• Zápis sekvenčního diagramu
• Herci
  • Záchranná lana
  • Zprávy
  • Vytvořit zprávu
  • Smazat zprávu
  • Vlastní zpráva
  • Odpovědět na zprávu
  • Nalezená zpráva
  • Ztracená zpráva
  • Stráže
• Jak vytvořit sekvenční diagramy?
• Příklady použití sekvenčních diagramů
• Problémy při používání sekvenčních diagramů

1. Zápis sekvenčního diagramu

1.1. Herci

Aktér v diagramu UML představuje typ role, kde interaguje se systémem a jeho objekty. Zde je důležité poznamenat, že aktér je vždy mimo rozsah systému, který se snažíme modelovat pomocí diagramu UML.

Využíváme herce k zobrazení různých rolí včetně lidských uživatelů a dalších externích subjektů. Aktéra reprezentujeme v UML diagramu pomocí notace stick person. V sekvenčním diagramu můžeme mít více aktérů.

Například:

Zde je uživatel v rezervačním systému zobrazen jako aktér tam, kde existuje mimo systém a není součástí systému.

1.2. Záchranná lana

Záchranné lano je pojmenovaný prvek, který zobrazuje jednotlivého účastníka v sekvenčním diagramu. Takže v podstatě každá instance v sekvenčním diagramu je reprezentována záchranným lankem. Prvky záchranné čáry jsou umístěny v sekvenčním diagramu nahoře. Standard v UML pro pojmenování záchranného lana má následující formát:

Název instance: Název třídy

javascriptový víceřádkový řetězec

Zobrazujeme záchranné lano v obdélníku tzv hlava s jeho názvem a typem. Hlava je umístěna na vrcholu svislé přerušované čáry (označované jako představec), jak je znázorněno výše.

• Pokud chceme modelovat nepojmenovanou instanci, postupujeme podle stejného vzoru s tím rozdílem, že část názvu záchranného lana je nyní ponechána prázdná.
• Rozdíl mezi záchranným lanem a hercem
  • Záchranné lano vždy zobrazuje objekt uvnitř systému, zatímco aktéři se používají k zobrazení objektů vně systému.

Následuje příklad sekvenčního diagramu:

1.3. Zprávy

Komunikace mezi objekty je znázorněna pomocí zpráv. Zprávy se na záchranné lince zobrazují v sekvenčním pořadí.

• Zprávy znázorňujeme pomocí šipek.
• Záchranné čáry a zprávy tvoří jádro sekvenčního diagramu.

Zprávy lze obecně rozdělit do následujících kategorií:

Synchronní zprávy

Synchronní zpráva čeká na odpověď, než se interakce může pohnout vpřed. Odesílatel čeká, dokud příjemce nedokončí zpracování zprávy. Volající pokračuje pouze tehdy, když ví, že příjemce zpracoval předchozí zprávu, tj. obdržel odpověď.

• Velké množství volání v objektově orientovaném programování je synchronních.
• Používáme a pevná hlavice šípu reprezentovat synchronní zprávu.

Asynchronní zprávy

Asynchronní zpráva nečeká na odpověď od příjemce. Interakce se posouvá vpřed bez ohledu na to, zda příjemce zpracuje předchozí zprávu nebo ne. Používáme a lemovaná hlavice šípu reprezentovat asynchronní zprávu.

1.4. Vytvořit zprávu

K vytvoření instance nového objektu v sekvenčním diagramu používáme zprávu Create. Existují situace, kdy konkrétní volání zprávy vyžaduje vytvoření objektu. Je znázorněn tečkovanou šipkou a na ní označeným slovem vytvořte, aby bylo uvedeno, že se jedná o symbol vytvoření zprávy.

Například:

Vytvoření nové objednávky na webu elektronického obchodu by vyžadovalo vytvoření nového objektu třídy Objednávka.

1.5. Smazat zprávu

K odstranění objektu používáme Delete Message. Když je objektu uvolněna paměť nebo je zničen v systému, používáme symbol Delete Message. Ničí výskyt objektu v systému. Je reprezentován šipkou končící x.

Například:

Ve scénáři níže, když uživatel obdrží objednávku, může být objekt třídy objednávky zničen.

1.6. Vlastní zpráva

Mohou nastat určité scénáře, kdy objekt potřebuje poslat zprávu sám sobě. Takové zprávy se nazývají Self Messages a jsou reprezentovány a Šipka ve tvaru U .

budkový algoritmus

Další příklad:

Zvažte scénář, kdy chce zařízení získat přístup ke své webové kameře. Takový scénář je reprezentován pomocí vlastní zprávy.

1.7. Odpovědět na zprávu

Zprávy s odpovědí se používají k zobrazení zprávy odesílané od příjemce odesílateli. Reprezentujeme zprávu o návratu/odpovědi pomocí an otevřená hlava šipky s tečkovanou čarou . Interakce se posune vpřed pouze tehdy, když příjemce odešle odpověď.

Například:

Zvažte scénář, kdy zařízení požaduje od uživatele fotografii. Zde je zpráva, která ukazuje odesílanou fotografii, odpovědí.

1.8. Nalezená zpráva

Zpráva Found se používá k reprezentaci scénáře, kdy zprávu odešle neznámý zdroj. Je reprezentován pomocí an šipka směřující k záchrannému lanu z koncového bodu.

Například:

Zvažte scénář selhání hardwaru.

Může to být způsobeno několika důvody a nejsme si jisti, co způsobilo selhání hardwaru.

můj živý kriket

1.9. Ztracená zpráva

Ztracená zpráva se používá k reprezentaci scénáře, kdy příjemce není systému znám. Je znázorněna pomocí šipky směřující ke koncovému bodu od záchranného lana.

Například:

Zvažte scénář, kde je generováno varování.

Varování může být generováno pro uživatele nebo jiný software/objekt, se kterým záchranné lano interaguje. Protože cíl není předem znám, používáme symbol ztracené zprávy.

1.10. Stráže

K modelování podmínek používáme stráže v UML. Používají se, když potřebujeme omezit tok zpráv pod záminkou splnění podmínky. Ochrany hrají důležitou roli při informování vývojářů softwaru o omezeních systému nebo konkrétního procesu.

Například:

Aby bylo možné vybrat hotovost, musí být zůstatek vyšší než nula splněn, jak je uvedeno níže.

Výše uvedený sekvenční diagram znázorňuje sekvenční diagram pro hudební přehrávač založený na emocích:

1. Nejprve uživatel otevře aplikaci.
2. Zařízení poté získá přístup k webové kameře.
3. Webová kamera snímá obraz uživatele.
4. Zařízení používá algoritmy k detekci obličeje a předpovídání nálady.
5. Následně požaduje databázi pro slovník možných nálad.
6. Nálada je načtena z databáze.
7. Nálada se zobrazí uživateli.
8. Hudba je požadována z databáze.
9. Vygeneruje se seznam skladeb a nakonec se zobrazí uživateli.

2. Jak vytvořit sekvenční diagramy?

Vytvoření sekvenčního diagramu zahrnuje několik kroků a obvykle se provádí ve fázi návrhu vývoje softwaru, aby se ilustrovalo, jak různé komponenty nebo objekty interagují v průběhu času. Zde je podrobný návod, jak vytvořit sekvenční diagramy:

1. Identifikujte scénář:
   • Pochopte konkrétní scénář nebo případ použití, který chcete znázornit v sekvenčním diagramu. Může to být specifická interakce mezi objekty nebo tok zpráv v určitém procesu.
2. Seznam účastníků:
   • Identifikujte účastníky (objekty nebo aktéry) zapojené do scénáře. Účastníky mohou být uživatelé, systémy nebo externí entity.
3. Definujte Lifelines:
   • Nakreslete svislou přerušovanou čáru pro každého účastníka, která představuje životní čáru každého objektu v průběhu času. Záchranné lano představuje existenci objektu během interakce.
4. Uspořádat záchranná lana:
   • Umístěte záchranná lana vodorovně v pořadí, v jakém jsou zapojeni do interakce. To pomáhá při vizualizaci toku zpráv mezi účastníky.
5. Přidat aktivační lišty:
   • U každé zprávy nakreslete na záchranné lano odesílajícího účastníka aktivační pruh. Aktivační lišta představuje dobu, po kterou účastník aktivně zpracovává zprávu.
6. Kreslit zprávy:
   • Pomocí šipek znázorněte zprávy mezi účastníky. Zprávy proudí horizontálně mezi záchrannými čarami, což naznačuje komunikaci mezi objekty. Různé typy zpráv zahrnují synchronní (plná šipka), asynchronní (přerušovaná šipka) a vlastní zprávy.
7. Zahrnout zpětné zprávy:
   • Pokud účastník odešle zprávu s odpovědí, nakreslete přerušovanou šipku vracející se k původnímu odesílateli, která bude představovat zprávu s odpovědí.
8. Uveďte čas a pořadí:
   • Použijte čísla k označení pořadí zpráv v pořadí. Můžete také použít svislé přerušované čáry k znázornění výskytu událostí nebo plynutí času.
9. Zahrnout podmínky a smyčky:
   • Použijte kombinované fragmenty k reprezentaci podmínek (jako jsou příkazy if) a smyček v interakci. To zvyšuje složitost sekvenčního diagramu a pomáhá při podrobnějším řízení toku.
10. Zvažte paralelní provedení:
    • Pokud probíhají paralelní aktivity, znázorněte je nakreslením paralelních svislých přerušovaných čar a odpovídajícím umístěním zpráv.
11. Zkontrolujte a upřesněte:
    • Zkontrolujte sekvenční diagram pro jasnost a správnost. Ujistěte se, že přesně reprezentuje zamýšlenou interakci. Podle potřeby dolaďte.
12. Přidat poznámky a komentáře:
    • Zahrňte jakékoli další informace, anotace nebo komentáře, které poskytují kontext nebo objasnění prvků v diagramu.
13. Předpoklady a omezení dokumentu:
    • Pokud existují nějaké předpoklady nebo omezení související s interakcí, zdokumentujte je vedle diagramu.
14. Nástroje:
    • Použijte modelovací nástroj UML nebo software pro tvorbu diagramů k vytvoření úhledného a profesionálně vyhlížejícího sekvenčního diagramu. Tyto nástroje často poskytují funkce pro snadné úpravy, spolupráci a dokumentaci.

3. Případy použití sekvenčních diagramů

• Vizualizace chování systému:
  • Sekvenční diagramy se používají k ilustraci dynamického chování systému zobrazením interakcí mezi různými komponentami, objekty nebo aktéry v průběhu času.
  • Poskytují jasnou a vizuální reprezentaci toku zpráv a událostí v konkrétním scénáři.
• Softwarový design a architektura:
  • Během fáze návrhu vývoje softwaru pomáhají sekvenční diagramy vývojářům a architektům plánovat a porozumět tomu, jak budou různé komponenty a objekty interagovat, aby dosáhly konkrétních funkcí.
  • Poskytují plán pro chování systému.
• Komunikace a spolupráce:
  • Sekvenční diagramy slouží jako komunikační nástroj mezi zúčastněnými stranami, včetně vývojářů, designérů, projektových manažerů a klientů.
  • Pomáhají zprostředkovat složité interakce ve snadno srozumitelném vizuálním formátu, podporují spolupráci a sdílené porozumění.
• Vyjasnění požadavků:
  • Při zpřesňování požadavků na systém lze použít sekvenční diagramy k objasnění a upřesnění očekávaných interakcí mezi komponentami systému nebo mezi systémem a externími entitami.
  • Pomáhají zajistit společné porozumění chování systému mezi všemi zúčastněnými stranami.
• Ladění a odstraňování problémů:
  • Vývojáři používají sekvenční diagramy jako ladicí nástroj k identifikaci a analýze problémů souvisejících s pořadím a načasováním zpráv během interakcí se systémem.
  • Poskytuje vizuální reprezentaci toku kontroly a pomáhá při lokalizaci a řešení problémů.

4. Problémy používání sekvenčních diagramů

• Složitost a velikost:
  • Jak systémy rostou ve složitosti, sekvenční diagramy mohou být velké a složité. Správa velikosti diagramu při stále přesné reprezentaci interakcí může být náročná a příliš složité diagramy může být obtížné pochopit.
• Úroveň abstrakce:
  • Nalézt správnou rovnováhu z hlediska abstrakce může být náročné. Sekvenční diagramy musí být dostatečně podrobné, aby zprostředkovaly potřebné informace, ale příliš mnoho podrobností může čtenáře zahltit. Je důležité zaměřit se na nejkritičtější interakce, aniž byste se zabředli do drobností.
• Dynamická povaha:
  • Sekvenční diagramy představují dynamické aspekty systému a v důsledku toho se mohou během procesu vývoje často měnit. Udržování aktuálních sekvenčních diagramů s vyvíjejícím se systémem může být problém, zejména v rychle se měnících nebo agilních vývojových prostředích.
• Nejednoznačnost ve zprávách:
  • Někdy může být náročné definovat přesnou povahu zpráv mezi objekty. Nejednoznačnost obsahu nebo významu zprávy může vést k nedorozuměním mezi zúčastněnými stranami a ovlivnit přesnost sekvenčního diagramu.
• Souběžnost a paralelismus:
  • Reprezentovat souběžné a paralelní procesy může být složité. Zatímco sekvenční diagramy mají mechanismy pro indikaci paralelního provádění, vizualizace více interakcí probíhajících současně může být náročná a může vyžadovat další diagramové prvky.
• Omezení v reálném čase:
  • Reprezentovat omezení v reálném čase a požadavky na přesné načasování může být náročné. Zatímco sekvenční diagramy poskytují sekvenční reprezentaci, přesné zachycení a sdělování aspektů v reálném čase může vyžadovat další dokumentaci nebo doplňkové diagramy.