UML diagramy - část 1.
V mnoha firmách není zavedený standard pro návrh a klade se větší důraz na samotnou implementaci. To může vést k rychlejšímu vývoji, pokud součástí analýzy požadavků a zpracování zadání jsou samotní vývojáři. V situaci, kdy jsou týmy oddělené dochází k mnoha nedorozuměním mezi produktovým managementem a vývojářským týmem, což značně zpomaluje vývoj a v nejhorších případech může vést i k situaci vývojář vs produktový manažer.
V tomto článku bych se chtěl zaměřit na jazyk UML (Unified Modeling Language) a jeho nejpoužívanější typy diagramů. Proč zrovna tento jazyk? Jedná se o nejvíce používaný modelovací jazyk, nejen v prostoru softwarového vývoje. Díky jeho formalizaci a popularitě lze odstavec textu zachytit jednou “čarou” mezi entitami diagramu. Dalším z jeho výhod je verifikovatelnost a dostupnost studijních materiálů k samostudiu.
Diagramy jazyka UML jsou rozděleny do 2 hlavních kategorií:
- Diagramy struktury (Structure Diagrams) – popisují strukturu systému
- Diagram chování (Behaviour Diagram) – popisují chování systému
- Diagramy interakce (Interaction Diagrams) – popisují interakci mezi
jednotlivými částmi systému
Class Diagram
Pro bližší pochopení domény, identifikaci entit a jejich vazby mezi sebou se používá diagram tříd. Tímto diagramem lze zachytit mnoho implementačních informací a zároveň je lehce pochopitelný pro členy mimo vývojářský tým. Slouží také jako podklad pro databázový model.
Prvním krokem návrhu diagramu tříd je identifikace jednotlivých entit domény, pro kterou se vyvíjí software. Lze zde definovat jednotlivé atributy třídy a metody spolu s jejich viditelností (+ public, - private, # protected)
Pro zachycení jednotlivých vazeb mezi jednotlivými entitami se nejčastěji používá asociace, dědičnost, agregace a kompozice.
Dědičnost funguje klasicky jako dědění tříd v objektovém programování.
Asociaci lze chápat jako vztah Foreign key (cizí klíč - v databázovém kontextu)
Class A má strukturální vazbu ke Class B. Neboli Class A si drží cizí klíč na Class B.
Agregaci lze chápat jako kolekci. Nebo-li Class A patří do Class B. Class A může mít jinou životnost než Class B (nemusí být vytvořený ve stejnou dobu).
Příklad:
Class A = pneumatika, Class B = auto.
Class A je vytvořena v létě a v zimě nastala situace výměny z letních pneumatik za zimní. Pneumatika a auto byly vytvořeny v jinou chvíli
Kompozici lze chápat jako skládání objektu jinými objekty. Je podobné agregaci, ale liší se v tom, že objekty zanikají společně (smazáním rodičovského objektu se smažou i jednotlivé části).
Příklad:
Class A = Odvětví firmy, Class B = Firma.
Zaniknutím firmy, zanikají i její jednotlivá odvětví.
Multiplicita
U vazeb mezi objekty lze také znázorňovat multiplicitu.
1..* = jedna až nekonečno
0..* nebo * = 0 až nekonečno
m = pouze m
m..n = m až n
Objekt Class A může mít pouze jednu vazbu k objektu Class B. Zatímco objekt Class B může mít 0..* vazeb k objektům Class A.
Na následujícím obrázku je znázorněn jednoduchý příklad zachycení objednávek v UML Class diagramu.
State Machine Diagram
U některých entit se také zaznamenává stav relevantní k dané entitě. State Machine Diagram je UML diagram chování, který by měl sloužit k objasnění stavů entity. V jakých stavech se může entita nacházet, za jaké události a podmínky může entita změnit svůj stav.
Přechod ze Stavu A do Stavu B nastává v určité události za nějaké podmínky a akce, která převede entitu ze stavu A do stavu B.
Podmínka a akce jsou volitelné informace přechodu.
Na následujícím obrázku je znázorněn jednoduchý příklad zachycení stavů objednávky e-shopu bez kamenné prodejny a reklamace v UML State Machine Diagramu.
