Diagram případů užití

Základní charakteristika

Diagram případů užití (Use Case Diagram) se používá k popisu chování systému z hlediska uživatele a zachycuje, které typy uživatelů se systémem pracují a jaké činnosti v rámci systému vykonávají. [Buch2007] Umožňuje znázornit funkční požadavky na systém tím, že popisuje interakci mezi ním a uživateli [Fow2003].

Prvním krokem procesu tvorby softwaru je specifikace softwarových požadavků. Dle [Kan2004] existují dvě skupiny požadavků – funkční požadavky a nefunkční požadavky. Případy užití jsou schopny postihnout pouze funkční požadavky, tedy požadavky určující, jaké chování by měl navrhovaný systém nabízet (co by měl systém dělat). Nefunkční požadavky, které představují omezení či vlastnosti systému, zachytit nedokážou. Proto je nutné doplňovat model případů užití i například modelem požadavků, který ale není součástí UML. [Arl2008]

V rámci analýzy se vytváří model případů užití, který je tvořen nejen diagramy případů užití, ale měl by obsahovat i specifikaci případů užití a definici aktérů. [Use2006]

Dle [Arl2008] spočívá modelování případů užití v následujících krocích:

  • Nalezení hranic systému
  • Vyhledání aktérů
  • Nalezení případů užití
  • Specifikace případů užití
  • Určení alternativních scénářů
  • Opakování předchozích bodů, dokud nedojde k ustálení případů užití, aktérů a hranic systému

Prvky diagramu

Aktér popisuje uživatele vně systému, který je se s ním v interakci. Tímto uživatelem nemusí být pouze fyzická osoba, ale například i jiný systém či hardwarové zařízení. Jeho název pak vyjadřuje jeho roli v systému. Aktéry můžeme rozlišovat na primární a pomocné. [Buch2007]

V jazyce UML 2.0 jsou aktéři znázorňovány nejčastěji jako na obrázku 10. Pro vyjádření rolí, které jsou určeny osobám, se obvykle používá figurka, zatímco obdélník zobrazuje roli, kterou hrají jiné systémy. [Arl2008] Pokud je figurka použita pro roli systému, je doplněna o stereotyp <<system>> (viz obrázek 11). Některé CASE nástroje (Computer-Aided Software Engineering) umožňují jednotlivým aktérům přiřadit vlastní ikony (viz obrázek 12).

Aktéři 

Obrázek 10. Hierarchie aktérů znázorněná nejčastěji používanou notací 

Aktéři 

Obrázek 11. Hierarchie aktérů znázorněna pouze pomocí ikon figurek

Aktéři

Obrázek 12. Hierarchie aktérů znázorněna pomocí vlastních ikon

Případ užití „specifikuje část funkcionality systému, kterou využívá aktér a která plní určitý cíl.“ [Buch2007] Je charakterizován množinou scénářů případů užití prováděných za stejným cílem, tedy sekvencí kroků popisující interakci uživatele se systémem (viz tabulka3.2). [Fow2003]

Vztahy mezi aktéry a případy užití jsou nazývány komunikační asociace či relace (stereotyp <<communication>>) a znázorňují mezi nimi plynoucí tok informací. [Buch2007][Arl2008]

Mezi případy užití mohou být použity tři typy vztahů: include (při opakování stejného případu užití na více místech), extend (nadstandardní případ užití při splnění dané podmínky) a generalizace/specializace. Tento poslední typ vztahu je používán také mezi aktéry, kdy umožňuje znázornit předky či potomky aktéra (viz obrázek 10).

Hranice systému (v UML 2.0 označovány jako subjekt) jsou v modelu znázorněny rámečkem kolem případů užití a názvem modelovaného systému.

Doporučení

Dle [Arl2008] a [Use2006] platí pro diagramy případů užití následující doporučení:

  • Případy užití by měly být co nejjednodušší, aby byly srozumitelné jak analytikům a návrhářům, tak uživatelům a jiným zainteresovaným osobám. Z tohoto důvodu není používání relací <<extend>> a <<include>> příliš vhodné.
  • Případy užití by měly vyjadřovat, co od navrhovaného systému očekávají aktéři, nikoli to, jak systém tyto požadavky uspokojí.
  • Při modelování případů užití by neměla být často použita tzv. funkční dekompozice, tedy rozkládání obecných případů užití na více konkrétních.
  • Každý aktér by měl být krátce popsán, aby byla specifikována jeho role z obchodního hlediska.
  • Pro specifikaci ani pro název případů užití neexistuje v UML žádný standard. Jim Arlow však ve své knize [Arl2008] doporučuje při pojmenovávání používat tzv. VelbloudíNotaci, dle níž by mělo každé slovo začínat velkým písmenem.
  • Názvy případů užití by měly korespondovat s termíny používanými v dané byznys oblasti (domain terminology).
  • Při modelování by se také měla zohlednit časová posloupnost jednotlivých případů užití. Dřívější případy užití by měly být zobrazeny nad pozdějšími.
  • Pokud je to možné, primární aktéři by měli být umístěni na levé straně diagramu.
  • Aktéři by měli být kresleni na okrajích diagramu.
  • Aktéři by měli být pojmenováni podstatným jménem v jednotném čísle.
  • Každý aktér by měl být komunikační relací propojen alespoň s jedním případem užití.
  • Aktéři by neměli být navzájem propojeni komunikačními relacemi.
  • V diagramu je také možné použít aktéra „Čas“, pokud je potřeba namodelovat, že v systému nastane něco v určitý okamžik.
  • Vložený případ užití by měl být umístěn vpravo od základního případu užití
  • Rozšiřující případ užití by měl být umístěn pod základním případem užití.
  • Při modelování generalizace/specializace by měli být nadřazení aktéři (popř. případy užití) nad podřazenými aktéry (popř. případy užití).

Příkladový model případů užití

Diagram případů užití

Obrázek 13. Diagram případů užití

Název případu užití

Ocenit vozidlo

Identifikace případu užití

UC001

Cíl případu užití

Získat cenu pro daný typ vozidla na základě zadaných parametrů vozidla a výbavy

Primární aktér(ři)

Prodavač autobazaru

Pomocný aktér(ři)

-

Vstupní podmínky

Prodavač autobazaru je přihlášen v aplikaci a zadá volbu pro ocenění vozidla.

Výstupní podmínky

Je vytvořeno ocenění vozidla.

Základní scénář

Krok

Role

Akce

1

Systém

zobrazí formulář pro ocenění vozidla.

2

Aktér

zadá povinné údaje o vozidle, a to: značka, model, rok výroby a najeto km.

3

Systém

automaticky doplní další parametry vozidla dle předchozích zadaných údajů (hmotnost, převodovka, základní výbava apod.) a provede ocenění vozidla.

4

Aktér

zvolí, že chce ocenění uložit.

5

Systém

provede kontrolu zadaných údajů.

6

Systém

pokud není chyba, a uloží ocenění.

Pokud je chyba UC002 - alternativní scénář - chyba vstupních údajů.

Alternativní scénář

Krok

Role

Akce

6a1

Systém

zobrazí chybové hlášení, že vozidlo nelze ocenit.

6a2

Systém

nabídne volbu pro zrušení ocenění a pro opravu údajů ocenění. (Pokud aktér zvolí opravu údajů, pokračuje se krokem 2 hlavního scénáře)

Tabulka 1. Specifikace (scénář) případu užití dle [Buch2007]

Název aktéra

Popis aktéra

Prodavač autobazaru

Prodavač autobazaru je zaměstnancem autobazaru nebo smluvního partnera finanční organizace, který prodává vozidlo a nabízí klientovi úvěr či leasing na jeho financování.

Tabulka 2. Definice aktéra