Unified Modeling Language (UML) je modelovací jazyk v oblasti softvérového inžinierstva, ktorého cieľom je nastaviť štandardné spôsoby vizualizácie návrhu systému. UML vedie vytváranie viacerých typov diagramov, ako sú diagramy interakcie, štruktúry a správania. A sekvenčný diagram je najčastejšie používaný interakcia diagram.

Interakčný diagram

Interakčný diagram sa používa na zobrazenie interaktívne správanie systému. Keďže vizualizácia interakcií v systéme môže byť náročná, používame rôzne typy interakčných diagramov na zachytenie rôznych funkcií a aspektov interakcie v systéme.

• Sekvenčný diagram jednoducho zobrazuje interakciu medzi objektmi v sekvenčnom poradí, t. j. v poradí, v ktorom sa tieto interakcie vyskytujú.
• Na označenie sekvenčného diagramu môžeme použiť aj termíny diagramy udalostí alebo scenáre udalostí.
• Sekvenčné diagramy popisujú, ako a v akom poradí fungujú objekty v systéme.
• Tieto diagramy sú široko používané obchodníkmi a vývojármi softvéru na dokumentáciu a pochopenie požiadaviek na nové a existujúce systémy.

Dôležité témy pre sekvenčné diagramy

• Zápis sekvenčného diagramu
• Herci
  • Záchranné laná
  • Správy
  • Vytvoriť správu
  • Odstrániť správu
  • Vlastná správa
  • Odpovedať na správu
  • Nájdená správa
  • Stratená správa
  • Stráže
• Ako vytvoriť sekvenčné diagramy?
• Prípady použitia sekvenčných diagramov
• Výzvy používania sekvenčných diagramov

1. Zápis sekvenčného diagramu

1.1. Herci

Aktér v UML diagrame predstavuje typ roly, kde interaguje so systémom a jeho objektmi. Tu je dôležité poznamenať, že aktér je vždy mimo rámca systému, ktorý sa snažíme modelovať pomocou diagramu UML.

Používame hercov na zobrazenie rôznych rolí vrátane ľudských používateľov a iných externých subjektov. Predstavujeme aktéra v UML diagrame pomocou zápisu paličkovej osoby. V sekvenčnom diagrame môžeme mať viacerých aktérov.

Napríklad:

Tu je používateľ v systéme rezervácie miest zobrazený ako aktér, ak existuje mimo systému a nie je súčasťou systému.

1.2. Záchranné laná

Záchranné lano je pomenovaný prvok, ktorý zobrazuje jednotlivého účastníka v sekvenčnom diagrame. Takže v podstate každá inštancia v sekvenčnom diagrame je reprezentovaná záchranným lanom. Prvky záchranného lana sú v sekvenčnom diagrame umiestnené v hornej časti. Štandard v UML pre pomenovanie záchranného lana má nasledujúci formát:

Názov inštancie: Názov triedy

jquery po kliknutí

Záchranné lano zobrazíme v obdĺžniku tzv hlavu s jeho názvom a typom. Hlava je umiestnená na vrchole zvislej prerušovanej čiary (označovanej ako driek), ako je znázornené vyššie.

• Ak chceme modelovať nepomenovanú inštanciu, postupujeme podľa rovnakého vzoru s výnimkou toho, že časť názvu záchranného lana zostane prázdna.
• Rozdiel medzi záchranným lanom a hercom
  • Záchranné lano vždy zobrazuje objekt vo vnútri systému, zatiaľ čo herci sa používajú na zobrazenie objektov mimo systému.

Nasleduje príklad sekvenčného diagramu:

1.3. Správy

Komunikácia medzi objektmi je znázornená pomocou správ. Správy sa zobrazia v postupnom poradí na záchrannom lane.

• Správy reprezentujeme pomocou šípok.
• Životné línie a správy tvoria jadro sekvenčného diagramu.

Správy možno vo všeobecnosti rozdeliť do nasledujúcich kategórií:

Synchrónne správy

Synchrónna správa čaká na odpoveď predtým, ako sa interakcia môže posunúť ďalej. Odosielateľ čaká, kým príjemca nedokončí spracovanie správy. Volajúci pokračuje len vtedy, keď vie, že príjemca spracoval predchádzajúcu správu, t. j. dostane odpoveď.

• Veľký počet volaní v objektovo orientovanom programovaní je synchrónnych.
• Používame a pevná hlavica šípu reprezentovať synchrónnu správu.

java bubble sort

Asynchrónne správy

Asynchrónna správa nečaká na odpoveď od príjemcu. Interakcia sa posúva vpred bez ohľadu na to, či príjemca spracuje predchádzajúcu správu alebo nie. Používame a lemovaná hlavica šípu reprezentovať asynchrónnu správu.

1.4. Vytvoriť správu

Na vytvorenie inštancie nového objektu v sekvenčnom diagrame používame správu Create. Sú situácie, keď si konkrétny hovor vyžaduje vytvorenie objektu. Je znázornený bodkovanou šípkou a na ňom označené slovo vytvorte, aby ste určili, že ide o symbol vytvorenia správy.

Napríklad:

Vytvorenie novej objednávky na webovej stránke elektronického obchodu by si vyžadovalo vytvorenie nového objektu triedy Objednávka.

1.5. Odstrániť správu

Na vymazanie objektu používame Delete Message. Keď je objektu uvoľnená pamäť alebo je zničený v rámci systému, používame symbol Delete Message. Ničí výskyt objektu v systéme. Je znázornený šípkou ukončenou x.

Napríklad:

V nižšie uvedenom scenári, keď používateľ dostane objednávku, môže byť objekt triedy objednávky zničený.

1.6. Vlastná správa

Môžu nastať určité scenáre, keď objekt potrebuje poslať správu sám sebe. Takéto správy sa nazývajú vlastné správy a sú reprezentované a Šípka v tvare U .

Ďalší príklad:

Zvážte scenár, v ktorom chce zariadenie získať prístup k svojej webovej kamere. Takýto scenár je znázornený pomocou vlastnej správy.

1.7. Odpovedať na správu

Správy s odpoveďou sa používajú na zobrazenie správy odosielanej od príjemcu odosielateľovi. Správu s vrátením/odpoveď reprezentujeme pomocou an otvorená hlava šípu s bodkovanou čiarou . Interakcia sa posunie vpred iba vtedy, keď príjemca odošle odpoveď.

Napríklad:

Zvážte situáciu, keď zariadenie požaduje fotografiu od používateľa. Tu je správa, ktorá zobrazuje odosielanú fotografiu, odpoveďou.

1.8. Nájdená správa

Found message sa používa na reprezentáciu scenára, v ktorom neznámy zdroj posiela správu. Je reprezentovaný pomocou an šípka smerujúca k záchrannému lanu z koncového bodu.

Napríklad:

Zvážte scenár zlyhania hardvéru.

Môže to byť spôsobené viacerými dôvodmi a nie sme si istí, čo spôsobilo zlyhanie hardvéru.

1.9. Stratená správa

Stratená správa sa používa na reprezentáciu scenára, kde príjemca nie je systému známy. Je znázornený pomocou šípky nasmerovanej ku koncovému bodu záchranného lana.

Napríklad:

Zvážte scenár, v ktorom sa vygeneruje varovanie.

Varovanie môže byť vygenerované pre používateľa alebo iný softvér/objekt, s ktorým záchranné lano interaguje. Keďže destinácia nie je vopred známa, používame symbol stratenej správy.

concat java reťazec

1.10. Stráže

Na modelovanie podmienok používame stráže v UML. Používajú sa, keď potrebujeme obmedziť tok správ pod zámienkou splnenia podmienky. Ochrany zohrávajú dôležitú úlohu pri informovaní vývojárov softvéru o obmedzeniach spojených so systémom alebo konkrétnym procesom.

Napríklad:

Aby ste mohli vyberať hotovosť, musíte mať zostatok vyšší ako nula podmienku, ktorá musí byť splnená, ako je uvedené nižšie.

Vyššie uvedený sekvenčný diagram znázorňuje sekvenčný diagram pre hudobný prehrávač založený na emóciách:

1. Najprv používateľ otvorí aplikáciu.
2. Zariadenie potom získa prístup k webovej kamere.
3. Webová kamera zachytáva obraz používateľa.
4. Zariadenie používa algoritmy na detekciu tváre a predpovedanie nálady.
5. Následne si vyžiada databázu pre slovník možných nálad.
6. Nálada sa získa z databázy.
7. Používateľovi sa zobrazí nálada.
8. Hudba je vyžiadaná z databázy.
9. Vygeneruje sa zoznam skladieb a nakoniec sa zobrazí používateľovi.

2. Ako vytvoriť sekvenčné diagramy?

Vytvorenie sekvenčného diagramu zahŕňa niekoľko krokov a zvyčajne sa vykonáva počas fázy návrhu vývoja softvéru, aby sa ilustrovalo, ako rôzne komponenty alebo objekty interagujú v priebehu času. Tu je podrobný návod, ako vytvoriť sekvenčné diagramy:

1. Identifikujte scenár:
   • Pochopte konkrétny scenár alebo prípad použitia, ktorý chcete znázorniť v sekvenčnom diagrame. Môže to byť špecifická interakcia medzi objektmi alebo tok správ v konkrétnom procese.
2. Zoznam účastníkov:
   • Identifikujte účastníkov (objekty alebo aktérov) zapojených do scenára. Účastníkmi môžu byť používatelia, systémy alebo externé entity.
3. Definujte záchranné linky:
   • Nakreslite pre každého účastníka zvislú prerušovanú čiaru, ktorá predstavuje životnú čiaru každého objektu v priebehu času. Záchranné lano predstavuje existenciu objektu počas interakcie.
4. Usporiadať záchranné laná:
   • Umiestnite záchranné laná vodorovne v poradí ich zapojenia do interakcie. To pomáha pri vizualizácii toku správ medzi účastníkmi.
5. Pridať aktivačné lišty:
   • Pre každú správu nakreslite aktivačný pruh na záchranné lano odosielajúceho účastníka. Aktivačná lišta predstavuje dobu, počas ktorej účastník aktívne spracováva správu.
6. Kresliť správy:
   • Použite šípky na znázornenie správ medzi účastníkmi. Správy prúdia horizontálne medzi životnými čiarami, čo naznačuje komunikáciu medzi objektmi. Rôzne typy správ zahŕňajú synchrónne (plná šípka), asynchrónne (prerušovaná šípka) a vlastné správy.
7. Zahrnúť spätné správy:
   • Ak účastník odošle správu s odpoveďou, nakreslite prerušovanú šípku vracajúcu sa k pôvodnému odosielateľovi, ktorá bude predstavovať spätnú správu.
8. Uveďte čas a objednávku:
   • Na označenie poradia správ v poradí použite čísla. Na znázornenie výskytov udalostí alebo plynutia času môžete použiť aj zvislé prerušované čiary.
9. Zahrňte podmienky a slučky:
   • Použite kombinované fragmenty na reprezentáciu podmienok (napríklad príkazov if) a slučiek v interakcii. To pridáva na zložitosti sekvenčného diagramu a pomáha pri podrobnom postupe riadenia.
10. Zvážte paralelné vykonávanie:
    • Ak sa dejú paralelné aktivity, znázornite ich nakreslením paralelných zvislých prerušovaných čiar a zodpovedajúcim umiestnením správ.
11. Skontrolujte a spresnite:
    • Skontrolujte sekvenčný diagram kvôli prehľadnosti a správnosti. Uistite sa, že presne predstavuje zamýšľanú interakciu. Podľa potreby dolaďte.
12. Pridať anotácie a komentáre:
    • Zahrňte akékoľvek ďalšie informácie, anotácie alebo komentáre, ktoré poskytujú kontext alebo objasnenie prvkov v diagrame.
13. Predpoklady a obmedzenia dokumentu:
    • Ak existujú nejaké predpoklady alebo obmedzenia súvisiace s interakciou, zdokumentujte ich spolu s diagramom.
14. Nástroje:
    • Použite modelovací nástroj UML alebo softvér na vytváranie diagramov na vytvorenie prehľadného a profesionálne vyzerajúceho sekvenčného diagramu. Tieto nástroje často poskytujú funkcie na jednoduché úpravy, spoluprácu a dokumentáciu.

3. Prípady použitia sekvenčných diagramov

• Vizualizácia správania systému:
  • Sekvenčné diagramy sa používajú na ilustráciu dynamického správania systému zobrazením interakcií medzi rôznymi komponentmi, objektmi alebo aktérmi v priebehu času.
  • Poskytujú jasnú a vizuálnu reprezentáciu toku správ a udalostí v konkrétnom scenári.
• Softvérový dizajn a architektúra:
  • Počas fázy návrhu vývoja softvéru pomáhajú sekvenčné diagramy vývojárom a architektom plánovať a pochopiť, ako budú rôzne komponenty a objekty vzájomne pôsobiť, aby dosiahli špecifické funkcie.
  • Poskytujú plán pre správanie systému.
• Komunikácia a spolupráca:
  • Sekvenčné diagramy slúžia ako komunikačný nástroj medzi zainteresovanými stranami, vrátane vývojárov, dizajnérov, projektových manažérov a klientov.
  • Pomáhajú pri sprostredkovaní zložitých interakcií v ľahko zrozumiteľnom vizuálnom formáte, podporujú spoluprácu a zdieľané porozumenie.
• Objasnenie požiadaviek:
  • Pri spresňovaní systémových požiadaviek možno použiť sekvenčné diagramy na objasnenie a špecifikáciu očakávaných interakcií medzi systémovými komponentmi alebo medzi systémom a externými entitami.
  • Pomáhajú zabezpečiť spoločné pochopenie správania systému medzi všetkými zainteresovanými stranami.
• Ladenie a odstraňovanie problémov:
  • Vývojári používajú sekvenčné diagramy ako nástroj na ladenie na identifikáciu a analýzu problémov súvisiacich s poradím a načasovaním správ počas interakcií so systémom.
  • Poskytuje vizuálnu reprezentáciu toku kontroly a pomáha pri lokalizácii a riešení problémov.

4. Problémy používania sekvenčných diagramov

• Zložitosť a veľkosť:
  • Ako systémy rastú v komplexnosti, sekvenčné diagramy môžu byť veľké a zložité. Správa veľkosti diagramu a zároveň presné znázornenie interakcií môže byť náročné a príliš zložité diagramy sa môžu stať ťažko zrozumiteľnými.
• Úroveň abstrakcie:
  • Nájdenie správnej rovnováhy z hľadiska abstrakcie môže byť náročné. Sekvenčné diagramy musia byť dostatočne podrobné, aby poskytli potrebné informácie, ale príliš veľa podrobností môže zahltiť čitateľov. Je dôležité zamerať sa na najkritickejšie interakcie bez toho, aby ste uviazli v detailoch.
• Dynamická povaha:
  • Sekvenčné diagramy predstavujú dynamické aspekty systému a v dôsledku toho sa môžu počas procesu vývoja často meniť. Udržiavanie sekvenčných diagramov v aktuálnom stave s vyvíjajúcim sa systémom môže byť výzvou, najmä v rýchlo sa meniacich alebo agilných vývojových prostrediach.
• Nejednoznačnosť v správach:
  • Niekedy môže byť náročné definovať presnú povahu správ medzi objektmi. Nejednoznačnosť v obsahu alebo význame správy môže viesť k nedorozumeniam medzi zainteresovanými stranami a ovplyvniť presnosť sekvenčného diagramu.
• Súbežnosť a paralelnosť:
  • Zastupovanie súbežných a paralelných procesov môže byť zložité. Zatiaľ čo sekvenčné diagramy majú mechanizmy na označenie paralelného vykonávania, vizualizácia viacerých interakcií prebiehajúcich súčasne môže byť náročná a môže vyžadovať ďalšie diagramové prvky.
• Obmedzenia v reálnom čase:
  • Reprezentovať obmedzenia v reálnom čase a presné načasovanie môže byť náročné. Zatiaľ čo sekvenčné diagramy poskytujú sekvenčnú reprezentáciu, presné zachytenie a komunikácia aspektov v reálnom čase si môže vyžadovať ďalšiu dokumentáciu alebo doplnkové diagramy.