Upřesňujeme popis funkcí systému pomocí sekvenčního diagramu (pokračování 'Veverky')
V tomto článku si ukážeme, jak lze detailněji popsat automatizovatelnou funkci pomocí UML sekvenčního diagramu.
V tomto příkladu používám prostředí Enterprise Architect od australské společnosti [1].
Úplnou specifikaci UML najdete [2].
Nejprve vysvětlím, co budeme upřesňovat.
V jsme modelovali procesy 'pohádkové' tematické oblasti — pasáže o veverce z 'Pohádky o caru Saltanovi' A.S. Puškina. A začali jsme s diagramem Aktivity. Poté jsme vyvinuli funkční model pomocí use-case diagramu, na Obrázku 1 je zobrazen fragment.

Obrázek 1. Vztah mezi požadavkem a funkcí
Nyní chceme upřesnit informace o provádění této automatizovatelné funkce:
- s jakými komponenty rozhraní bude náš uživatel interagovat;
- jaké řídicí komponenty budeme potřebovat;
- co budeme uchovávat;
- jaké zprávy si uživatel a komponenty systému vymění pro provedení funkce.
Hlavními prvky sekvenčního diagramu jsou interagující objekty s různými stereotypy a vazby mezi nimi — interagující objekty si mezi sebou vyměňují určité informace (Obrázek 2).

Obrázek 2. Hlavní prvky sekvenčního diagramu
Objekty jsou uspořádány v horizontální posloupnosti, mezi nimi jsou předávány zprávy. Osa času je orientována shora dolů.
Prvek Actor může být použit k reprezentaci uživatele, který iniciuje tok událostí.
Každý objekt má tečkovanou čáru nazývanou 'životní čára', kde tento prvek existuje a potenciálně se podílí na interakcích. Ohnisko řízení je vyznačeno obdélníkem na životní čáře objektu.
Zprávy, kterými si objekty vyměňují informace, mohou být různých typů, zprávy mohou být také nastavena tak, aby odrážely operace a vlastnosti počátečního a cílového prvku.
Stereotypní prvky, jako jsou hranice (Boundary), ovládací prvky (Control) a entity (Entity), mohou být použity k modelování uživatelského rozhraní (GUI), ovladačů a databázových prvků, odpovídajícím způsobem.
Opakující se tok zpráv může být označen jako fragment typu "loop".
Plánujeme upřesnit popis funkce "Přidat do evidence informace o novém ořechu".
Souhlasíme s následujícími dodatečnými zjednodušeními a předpoklady.
- Ořech, jádro a skořápky jsou všechny hmotné hodnoty odpovídajících typů (Obrázek 3).

Obrázek 3. Upřesnění diagramu tříd - Do evidence náš uživatel bude zadávat informace o jakýchkoliv hmotných hodnotách.
- Upřesníme název evidence – "Evidence hmotných hodnot".
- Předpokládejme, že náš uživatel, pracující s GUI "Evidence hmotných hodnot", může přidat novou hmotnou hodnotu prostřednictvím GUI "Karta hmotné hodnoty".
- V závislosti na typu hmotné hodnoty se mění datová struktura a GUI.
- Při vyplňování polí karty hmotné hodnoty probíhá kontrola správnosti zadaných dat.
Diagram, sestavený s ohledem na tyto předpoklady, je uveden na Obrázku 4.

Obrázek 4. Upřesnění popisu funkce "Přidat do evidence informace o novém ořechu"
O použití dalších typů diagramů UML si můžete přečíst zde:
Seznam zdrojů
- Webové stránky Sparx Systems. [Elektronický zdroj] Přístupový režim: Internet:
- OMG Unified Modeling Language (OMG UML) specifikace. Verze 2.5.1. [Elektronický zdroj] Přístupový režim: Internet:
Zdroj: habr.com

