Vánoční nadílka Vánoční nadílka
Vánoční akce! Daruj lepší budoucnost blízkým nebo sobě. Až +50 % zdarma na dárkové poukazy. Více informací

Lekce 2 - UML - Use Case Diagram

Návrh UML UML - Use Case Diagram American English version English version

Unicorn College ONEbit hosting Tento obsah je dostupný zdarma v rámci projektu IT lidem. Vydávání, hosting a aktualizace umožňují jeho sponzoři.

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 a podobně. 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ř.

UML Use Case

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í.

UML Aktér

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:

Ukázkový Use Case UML diagram případů užití

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 a podobně. 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í.

Příště, v lekci UML - Use Case Specifikace, si řekneme něco o UC specifikaci a ukážeme si ještě jeden Use Case diagram, tentokrát komplexnějšího systému.


 

 

Článek pro vás napsal David Čápka
Avatar
Jak se ti líbí článek?
27 hlasů
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor sítě se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.
Miniatura
Předchozí článek
Úvod do UML
Miniatura
Všechny články v sekci
UML
Miniatura
Následující článek
UML - Use Case Specifikace
Aktivity (3)

 

 

Komentáře
Zobrazit starší komentáře (23)

Avatar
Jakub Mikšík:21. dubna 18:24

Děkuji za odpověď. Trochu jsem doufal, že nastoupení a vystoupení z výtahu bude špatně. Hlava mi to totiž moc nebere. Počítal jsem, že to bude spíše patřit třeba do diagramu aktivit. Při nastoupení do výtahu to není přece o tom, co by měl systém umět... Respektive musí umět otevření dveří, ale to je sekundární vlastnost přivolání výtahu (i když výtah stojí v daném patře, kde mi a jen otevře dveře)... :-/ Je možné mi to polopaticky vysvětlit? Nebo je to v pořádku jen za předpokladu, že aktor musí ještě něco udělat (kromě přivolání výtahu - třeba ručně ty dveře otevřít). Na normálních systémech to chápu, ale na tomhle případu jsem se kousl. díky :-)

 
Odpovědět 21. dubna 18:24
Avatar
Jindřich Máca
Tým ITnetwork
Avatar
Odpovídá na Jakub Mikšík
Jindřich Máca:22. dubna 0:26

Je to docela jednoduché a zkusím to tedy vysvětlit trochu polopaticky. Tento diagram se snaží o zachycení toho, co by daný systém měl umět. Už z doslovného překladu "diagram případů použití" je jasné, že primárním cílem je popis různých použití systému. Jelikož je to diagram analýzy, ne návrhu, řeší se zde pouze otázka toho, co bude umět, nikoliv jak to bude ve výsledku technicky zpracované. Jedním z jeho hlavních využití je pak např. možnost namapovat schopnosti systému na kladené uživatelské požadavky, tj. zkrátka jestli to bude umět všechno, co uživatel požadoval. :)

Ve Tvém případě tedy nastoupení i vystoupení jsou použití systému výtah, tudíž hurá s nimi do diagramu. To, že ve výsledku tyto akce budou čistě uživatelská interakce bez programové podpory je záležitost technického řešení (návrhu). Ber to tak, že v rámci analýzy ještě ani nevíš přesné technologie, ve kterých to budeš dělat, ale víš, že obecný výtah má umožňovat toto použití na základě toho, že to uživatel chtěl. :D

Doufám, že už je to trochu jasnější, líp to asi vysvětlit neumím...

 
Odpovědět 22. dubna 0:26
Avatar
Jakub Mikšík:22. dubna 17:56

Teď už je mi to naprosto jasné. Já jsem v některých krocích byl myšlenkově trošku napřed, tak mi to nedávalo moc smysl. Děkuji moc :-)

 
Odpovědět 22. dubna 17:56
Avatar
bujna.tomas
Člen
Avatar
bujna.tomas:3. května 7:48

Možno som niečo prehliadol, ale nie je Timer v tomto prípade aktívny aktér a teda by mal byť naľavo?

 
Odpovědět 3. května 7:48
Avatar
bujna.tomas
Člen
Avatar
bujna.tomas:3. května 8:02

Jemineee áno, prehliadol som je to v článku.

 
Odpovědět 3. května 8:02
Avatar
Lukáš Hruška:19. července 11:50

Díky za tutoriál, pro základní přehled skvělý. Mám ale připomínku k větě "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. "

Z tohoto důvodu tam <<include>> opravdu není ;-) Je tam z toho důvodu, že pokud se nějaká část (kroky scénáře) use case opakují u více use case, tak se tato část napíše samostatně, aby se u každého use case nevypisovala znovu. V případě změny se tak změní všude. Jedná se vlastně o odstranění zbytečných duplicit.
Navíc všechny popsané use case jsou stejně důležité, buď je daný systém má umět nebo nemá.

Editováno 19. července 11:52
 
Odpovědět 19. července 11:50
Avatar
Lukáš Hruška:19. července 11:54

To, že zadavatel klade větší důraz na nějakou funkčnost patří do textového popisu, který diagram doplňuje.

 
Odpovědět 19. července 11:54
Avatar
Jakub Hrubčo:14. srpna 11:36

Ahoj, prosim ako sa nazyva vazba medzi Timer a UC12? Dakujem

 
Odpovědět 14. srpna 11:36
Avatar
Odpovídá na Jakub Hrubčo
Josef Horváth:15. srpna 6:55

Ahoj, výše v textu máš uvedeno:

Vazbě znázorněné jednoduchou čarou říkáme asociace. Může mít specifikovanou násobnost i směr.

Šipkou naznačíš, že odkaz na UC12 bude uchován v instanci Timeru. Více o vztazích mezi entitami se dozvíš v lekci 4 – UML – Doménový model.

 
Odpovědět  +1 15. srpna 6:55
Avatar
Zdenek
Člen
Avatar
Zdenek:2. prosince 0:43

Ahoj, mohl by jsi jeste podrobneji popsat vazbu <<extend>>. Vidavam ji v diagramech casteji nez <<include>>.
Diky

 
Odpovědět 2. prosince 0:43
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 10 zpráv z 33. Zobrazit vše