Use case diagram - diagram případů užití

Základy

Use case diagram (UC diagram) zobrazuje chování systému (nebo jeho části) z hlediska uživatele.

Příklad UC diagramu

jednoduchý use case diagram : videopůjčovna, 16 kB

Na obrázku je use case diagram jednoduchého systému půjčovny videokazet :

  • každý případ užití, typová činnost (use case) charakterizuje určité použití systému účastníkem; případ užití má jméno, může mít textovou specifikaci
  • účastník (actor) reprezentuje kohokoliv (či cokoliv) mimo systém, kdo se systémem komunikuje a interaguje (člověk, HW, čidlo, jiný systém, ...); jediné, co actor může, je přijímat nebo předávat do systému informace
  • PS.: spíše než konkrétního uživatele reprezentuje actor roli : jeden konkrétní účastník (člověk, technické zařízení, jiný informační systém, ....) může být vyjádřen i více actory (vystupují ve stejné roli), a více různých konkrétních účastníků může být vyjádřeno jedním actorem (vystupují ve společné roli)
  • ohraničení (boundary) udává hranice systému/susbsystému (zde videopůjčovna); obecně je to vlastně klasifikátor (systém/subsystém/třída), jehož funkconalitu pomocí use case popisujeme
  • vztahy, relace (relationships) :
    • asociace mezi prodavač a půjčit kazetu : jde o komunikační asociaci, vyjadřuje tok informace mezi vnějším prvkem a případem užití
    • závislost mezi půjčit kazetu a najít zákazníka má stereotyp <<include>> : UC půjčit kazetu zahrnuje do sebe UC najít zákazníka (zahrnovaný use case); toto nám umožňuje re-use : najít zákazníka v systému musíme jak tehdy, když si chce zákazník půjčit videokazetu, tak tehdy, když videokazetu vrací - <<include>> nám umožní nadefinovat hledání zákazníka jen jednou a opakovaně ho zahrnout do více případů užití (vrátit kazetu, půjčit kazetu)

V diagramu je naznačeno, jak actor používá systém, ale jsou uvedeny jen názvy činností - my však potřebujeme specifikovat další podrobnosti: zde není jiná možnost, než naplnit do jednotlivých UC textové specifikace (jiná možnost ovšem je - podrobnosti lze namodelovat dalším navázaným diagramem, např. sekvečním).

V těchto specifikacích by mělo být zejména popsáno :

  • co systém dělá (ale ne jak to dělá)
  • měly by být používány jen pojmy problémové domény
  • jak a kdy činnost začíná a končí
  • kdy má systém interakce s actorem
  • které údaje jsou měněny
  • jaké kontroly vstupních údajů jsou prováděny
  • základní, alternativní a chybové průběhy
  • způsoby popisu nejsou v UML formalizovány: může to být strukturovaný/formátovaný text (pre- a post-conditions), pseudokód, ...

Příklad popisu případu užití vrátit kazetu :
vysvětlující komentáře budou psány takto
případ užití : vrátit kazetu
název případu užití
ID: UC_02
jednoznačný identifikátor
Účastníci : prodavač
seznam účastníků, kteří se podílejí na komunikaci
Vstupní podmínky
  1. zákazník chce vrátit (dříve vypůjčenou) videokazetu
  2. prodavač je zalogován do systému
  3. zde jsou obsaženy všechny podmínky, které musí být splněny, aby mohl být use case spuštěn; neboli : všechny uvedené podmínky musí být vyhodnoceny jako pravda;
    může jít jak o podmínky, jejichž pravdivost je "ověřitelná" přímo systémem (podmínka 2), tak o stav okolního světa (podmínka 1)
    PS.: tak jednoduché a obecné podmínky jako zalogování do systému se zde však obvykle neuvádějí ....
Tok událostí
  1. Systém spustí případ užití (UC_05 najít zákazníka)
  2. zde je spuštěn zahrnutý případ užití pro nalezení konkrétního zákazníka (UC05) - ten vyzve uživatele k zadání čísla průkazky zákazníka, podle čísla průkazky ho vyhledá a vrátí jeho identifikaci zpět do klientského případu užití (tj. nic nezobrazí) : vlastní zobrazení zákazníka si zajišťuje každý klientský případ užití "po svém" (každý by mohl chtít zobrazit jinou sadu údajů zákazníka a jiným způsobem)
  3. Systém zobrazí údaje vyhledaného zákazníka jako jméno, příjmení, adresu, telefon a vypůjčené kazety jako seznam záznamů : číslo kazety + název filmu + datum výpůjčky + vrátit (jako předpokládané datum vrácení)
  4. Uživatel vybere kazety, které zákazník vrací, a výběr potvrdí
  5. Systém od zákazníka odstraní všechny kazety, které předtím uživatel označil, a případ užití skončí
následné podmínky

seznam vypůjčených kazet byl u zákazníka aktualizován

zde jsou uvedeny podmínky, které po úspěšném dokončení případu užití musí být pravdivé
alternativní tok
  1. k bodu 2. hlavního toku : pokud v seznamu vypůjčených kazet není žádná kazeta, systém tuto skutečnost oznámí a případ užití skončí
  2. zde jsou uvedeny alternativy k hlavnímu toku, tj. průběhy nastávající jen zcela výjimečně a nestandardně
chybový tok
  1. k bodu 1. hlavního toku : pokud zákazník není nalezen, systém tuto chybu vypíše, upozorní obsluhu na to, že průkazka by měla být zničena a případ užití skončí
  2. zde jsou uvedeny chybové větvě k hlavnímu toku, tj. průběhy, které by neměly vůbec nastat - pokud nastanou, je to považováno za chybu (např. nekonzistence dat v systému, nesoulad mezi reálným světem a evidovanými informacemi apod.) a tato situace musí být nějak vyřešena

Další podrobnosti

Složitější diagram případů použití

složitější use case diagram : videopůjčovna, 35 kB

V tomto diagramu máme oproti předchozímu (jednoduchému) :

  • vztahy, relace (relationships) :
    • mezi actory manager a skladník je zavedena relace zobecnění účastníka (actor generalization) (vysvětlení vztahu generalizace - specializace viz v sekci OO):
      • actor skladník podědí od managera všechny relace k případům užití, tj. i když to není explicitně znázorněno, tak skladník může spouštět i use case UC_04
      • jinak řečeno : všude, kde je použit actor manager, může být použit kterýkoliv z jeho potomků, tj. UC_04 může být spouštěno jak managerem, tak skladníkem i prodavačem
      • UC_03 může spouštět jen skladník, nemůže ho spouštět ani manager (manager není potomkem skladníka, ale jeho předkem) ani prodavač (není potomkem skladníka, ale je s ním ve stromu generalizací na stejné úrovni)
      • actor manager je konkrétní actor (je to tedy konkrétní role, která opravdu komunikuje se systémem - spouští use cases), ale mohl by být abstraktní (bylo by vyjádřeno kurzívou : manager) : pak by takováto role ve skutečnosti nikdy se systémem neinteragovala - sloužila by nám jen pro zavedení stromu dědičnosti
    • mezi UC_02 vrátit vidokazetu a UC_07 naúčtovat pokutu je závislost se stereotypem <<extend>> : bázový případ užití UC_02 je za určitých podmínek (byla překročena smluvní výpůjční doba) rozšířen o nové chování, tj. o rozšiřující případ užití UC_07 (systém pak zákazníkovi předepíše pokutu). K relaci <<extend>> je (nepovině) v poznámce uveden zápis podmínka: {vrátit < aktuální datum} extension point: EP_01_pokuta, což znamená, že v bodu zozšíření EP_01_pokuta je spuštěno UC_07, ale jen tehdy, je-li splněna podmínka {vrátit < aktuální datum} (tj. pokud je vracena kazeta, pro kterou je datum kdy měla být vrácena starší než dnešní den - vrácení už mělo proběhnout v minulosti). Bod rozšíření EP_01_pokuta odkazuje na jeden z bodů rozšíření v UC.
  • UC_02 najít kazetu má navíc přidaný compartment extension points se seznamem bodů rozšíření. Syntaxe popisující body rozšíření a jejich umístění (v toku událostí) není přesně definovaná. Upřesnění umístění bodu rozšíření tedy může být přidáno přímo do corpamtmentu ke každému bodu rozšíření (za dvojtečku), nebo se může bod rozšíření objevit přímo ve specifikaci UC popisující tok událostí.
Tok událostí s extension pointem :
  1. Systém spustí ....
  2. Systém zobrazí údaje vyhledaného zákazníka ....
  3. Uživatel vybere kazety, které zákazník vrací, a výběr potvrdí

  4. (EP1_01_pokuta)
    zde je spuštěn rozšiřující případ užití tehdy, když je splněna podmínka {vrátit < aktuální datum}, tj. když kazeta měla být vrácena už v minulosti : v tom případě se spustí EC_07 naúčtovat pokutu, které naúčtuje zákazníkovi pokutu - k danému zákazníkovi zapíše do systému datum vystavení pokuty a její výši a vytiskne doklad o zaplacení. UC_07 má popis svého chování popsán ve své specifikaci
  5. Systém od zákazníka odstraní všechny kazety, které předtím uživatel vybral, a případ užití skončí

Kam dál

Náměty na další samostudium

  • generalizace-specializace pro případy užití
  • násobnost u asociace use case - actor
  • není v UML 2.0 : komunikační asociace mezi actory
  • k čemu všemu může být diagram případů užití vlastně použit ?