2. díl - UML - Use Case Diagram

Návrhové vzory UML UML - Use Case Diagram

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, založení 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řídá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 hovoříme 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 devbook, budeme navrhovat jemu podobný systém, jen značně zjednodušený. Tento ukázkový příklad nás bude provázet celým UML seriálem, vlastně si celý devbook 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 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 zapisujeme na pravou stranu, ačkoli je v podstatě aktivní.

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


 

  Aktivity (1)

Článek pro vás napsal David Čápka
Avatar
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 se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (14 hlasů) :
4.714284.714284.714284.714284.71428


 


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

 

 

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

Avatar
Mediel
Redaktor
Avatar
Mediel:

Sorry, máš pravdu, jsem se soustředil na to UML. Chápu, že jsi podrážděný, ale zas tyhle komentáře jsou myšlené v dobrém ;) Ale pravda, raději držet jazyk za zuby, aby byl klid :D Jdu pokračovat.

Odpovědět 23.9.2013 14:03
Nechci vám ukazovat, jak dobrý jsem já ... Chci vám ukázat, jak dobrý můžete být vy ... Když uvěříte ... V sami sebe...
Avatar
Martin
Neregistrovaný
Avatar
Martin:

Proč všichni dědí možnost registrovat se od Neregistrovaného uživatele?
Není to trochu blbost aby se např. administrátor mohl znova registrovat?

 
Odpovědět 16.12.2013 15:26
Avatar
Mirakin
Člen
Avatar
Odpovídá na Martin
Mirakin:

A není to spíš tak, že se nedědí možnost registrovat, ale samotný uživatel. Například, že neregistrovaný uživatel má jméno, příjmení, rok narození atd.
Stejně tak i člen, redaktor, administrátor.

 
Odpovědět 26.1.2014 11:37
Avatar
Odpovídá na Mirakin
Jakub Vaněk (Bubavanek):

Ono jde asi spis o to ze potomek dedi jen z primeho predka, nikoli z ,,prapredka,, nebo jak to nazvat. Tudiz redaktor dedi pouze ze clena, clen pouze z neregistrovaneho atp.

Opravte me nekdo jestli se pletu.

 
Odpovědět  -2 9.2.2014 20:03
Avatar
MrPabloz
Člen
Avatar
Odpovídá na Jakub Vaněk (Bubavanek)
MrPabloz:

Tu je dědičnost dána tak, že co umí rodič, umí i potomek, a jestli člen umí vše co neregistrovaný, tak potom redaktor, který dědí z člena, umí vše co člen, tedy i to co neregistrovaný :)

Odpovědět 9.2.2014 20:37
Harmonie těla a duše, to je to, oč se snažím! :)
Avatar
Odpovídá na MrPabloz
Jakub Vaněk (Bubavanek):

Aha, takze by se dalo rict vicenasobna dedicnost?

 
Odpovědět 9.2.2014 20:41
Avatar
MrPabloz
Člen
Avatar
Odpovědět 9.2.2014 21:19
Harmonie těla a duše, to je to, oč se snažím! :)
Avatar
Tunco
Člen
Avatar
Tunco:

Prosím, prečo je UC3 a UC 4 vynechané?

 
Odpovědět 18.10.2014 15:31
Avatar
holanekk
Člen
Avatar
holanekk:

Dají se use case diagramy používat i pro návrh desktopových aplikací ? Které typy ULM diagramů by se daly pro vývoj desktopových aplikací použít ? děkuji za odpověď.

 
Odpovědět 23.10.2014 18:10
Avatar
Tereza Pospíšilová:

Ahoj, možná trochu hloupá otázka, ale mějte se mnou slitování, učím se a mám za sebou 11 hodin koukání do monitoru :D Prosím Vás u Timera resp. uc, píše se asi také scénář, že? Zkouším v EA udělat zabezpečovací systém budovy a zasekla jsem se u scénáře...dlouhé hodiny mě zabralo to, jestli mám vůbec správně diagram a teď toto :D

 
Odpovědět 15. ledna 16:54
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 19. Zobrazit vše