Lekce 2 - UML - Use Case Diagram

V minulé lekci, Úvod do UML, jsme si uvedli jazyk UML a pochopili, že usnadňuje jak analýzu, tak i návrh informačních systémů.

V dnešním UML tutoriálu začneme s Use Case diagramy.

Use Case Diagram (česky diagram případů užití) zobrazuje chování systému tak, jak ho vidí uživatel. Účelem diagramu je popsat funkcionalitu systému, tedy co od něj klient nebo my očekáváme. Diagram vypovídá o tom, co má systém umět, ale neříká, jak to bude dělat. Proto je to většinou první diagram, který při návrhu informačního systému vytváříme. Je důležité se nejprve shodnout na tom, co má náš systém (nebo aplikace, hra, cokoli) umět. Až potom má smysl se ptát, jak to vlastně uděláme.

Use Case diagram se skládá z případů užití (use case), dále aktérů (actors) a vztahů mezi nimi.

Use Case (Případ užití)

Případ užití (nebo zkráceně UC) je sada několika akcí, které vedou k dosažení určitého cíle. Use Case může být přidání komentáře k článku, registrování nového uživatele nebo např. vytisknutí dokumentu. Definuje tedy jednu funkcionalitu, kterou by měl navrhovaný systém umět. Ta v sobě obsahuje další akce, např. přidání komentáře bude obsahovat ověření uživatele, validaci zadaných dat, zápis do databáze apod. To v diagramu zachyceno již nebude. UML často hovoří o tzv. blackboxu (černé skříňce), kde skryjeme vnitřní logiku a pracujeme pouze s komponentami. Tento princip přesně využívá UC diagram.

Use Case je nejčastěji zakreslován jako elipsa s jeho názvem uvnitř.

Případy užití vychází ze zadání systému od našeho zákazníka (pokud děláme systém pro sebe, tak z našich poznámek, co by měl umět). Hovoříme o tzv. mapování uživatelských požadavků na jednotlivé Use Case.

Actor (Aktér)

Aktér je role, která komunikuje s jednotlivými případy užití. V této roli může být obsazen uživatel nebo externí systém. Aktérem tedy může být např. Uživatel, Administrátor, SMS server nebo dokonce Čas. Aktér inicializuje nějaký případ užití (např. Uživatel vloží příspěvek do fóra). Zde bychom hovořili o tom, že je aktér aktivní. Aktér sám však může být případem užití iniciován (např. externí SMS server je iniciován případem užití Poslat SMS). V tomto případě hovoříme o pasivním aktérovi a zakresluje ho v diagramu napravo.

Aktéry znázorňujeme jako postavu z čar s názvem napsaným pod ní.

Pojďme si nyní zkusit vytvořit ukázkový UC diagram, jelikož všichni znáte ITnetwork, budeme navrhovat jemu podobný systém, jen značně zjednodušený. Tento ukázkový systém nás bude provázet celým UML kurzem, vlastně si celý ITnetwork navrhneme pomocí několika UML diagramů. Popis jeho funkčnosti by vypadal pomocí Use Case diagramu takto:

Vidíme, že diagram není složité nakreslit. Navrhnout však případy užití tak, aby jich byl rozumný počet a rovnoměrně pokrývaly funkcionalitu systému již chce trochu praxe. Určitě je však lepší nějaký než žádný, takže se ho nebojte používat

• Neregistrovaný uživatel může psát komentáře nebo se zaregistrovat. Komunikace probíhá zleva doprava (pokud není šipkou naznačen jiný směr). Aktéři jsou tedy propojeni s těmi případy užití, které se jich týkají. Vazbě znázorněné jednoduchou čarou říkáme asociace. Může mít specifikovanou násobnost i směr, ale tím se zde nebudeme ještě zabývat.
• Člen může to samé, jako neregistrovaný uživatel, protože z něj dědí. Tento vztah je znázorněn prázdnou uzavřenou šipkou směrem k předkovi. Tuto vazbu nazýváme generalizace. Člen může navíc ještě spravovat svůj profil a hodnotit články.
• Redaktor též umí to samé jako člen, ale navíc může články i psát.
• Administrátor může oproti redaktorům opět spouštět několik funkčností navíc. Zajímavá je vazba <<include>>. Ta se používá v případě, že je nějaká funkcionalita důležitá natolik, že ji chceme mít v diagramu místo toho, abychom ji jen prohlásili součástí nějakého Use Case. Případ užití napojený pomocí vazby <<include>> se spustí vždy, když je spuštěn případ, na který je napojen. Zde je tedy autor článku upomenut při schválení a zamítnutí článku. Samotné upomenutí v sobě bude mít další logiku, např. jestli emailem, SMS apod. My ho máme zabalený v jednom případu užití. Kromě <<include>> existuje ještě vazba <<extend>>, ale ta je velmi zavádějící a příliš se nepoužívá, nebudeme se jí tedy zabývat.
• Posledním aktérem je Timer (čas), ten se v určitou dobu spustí a provede odeslání aktualizací emailem. Aktéra čas zakreslujeme na pravou stranu, ačkoli je v podstatě aktivní.

V následujícím cvičení, Řešené úlohy k 1.-2. lekci UML, si procvičíme nabyté zkušenosti z předchozích lekcí.