Návrh aplikací v jazyce UML – začínáme s případy užití

Hic Sunt Leones – zde jsou lvi. Touto větou Římané označovali neprobádaná teritoria na mapách. Při návrhu každého systému musíme zpočátku logicky utřídit množství mlhavých a navíc chaoticky vyslovovaných požadavků zákazníka na funkce, které by měl systém obsahovat. Svět se příliš nezměnil, před námi je neznámá oblast a když ji dokonale nezmapujeme, na konci neúspěšného projektu pochopíme, že v ní zůstali i lvi. Hlavní funkční požadavky na systém jsou v UML zachyceny v případech užití (Use Case).

Hledání hranic systému

Případy užití neboli Use Case jsou psány z pohledu zákazníka a podávají první představu o rozsahu projektu. V této fázi analýzy se ještě nezabýváme technologickými aspekty řešení a používáme pouze pojmy přirozeného jazyka a termíny z problémové domény, abychom co nejvěrněji a pro zákazníka co nejsrozumitelněji načrtli funkční skeleton systému.

Neřešíme, jestli systém bude postaven na platformě .Net či J2EE, ani nediskutujeme se zákazníkem nad výhodami objektových či relačních databází, ale zjišťujeme, které procesy má systém podporovat a jací uživatelé jej budou používat. Názvy případů užití musejí být dostatečně obecné, přitom jednoznačné a výstižné. Příklady názvů případů užití:

• přihlášení uživatele do systému
• založení nové pracovní pozice
• přidání zboží do košíku
• úprava údajů o trvalém bydlišti uchazeče

Pokud zákazník naše případy užití nepochopí a nechá jejich zpracování a realizaci jen na nás a naší agilitě, pak jsme vyvíjenému systému právě zakoupili nepřenosnou vstupenku na utěšeně rostoucí popraviště zbytečných a nedotažených projektů. Buďte připraveni na eventualitu, kdy pasivní zachycení starých procesů přeroste v návrh nových racionalizovaných procesních toků optimalizovaných pro automatizaci. Jde o takzvaný „business process reingeneering“, kterým se ale v této sérii článků o UML nebudu zabývat.

Jak jsem již naznačil, ve správně vytvořených případech užití nalezneme odpovědi alespoň na dvě základní otázky. První se týká rozdělení odpovědnosti mezi systémem a okolím. Případy užití napomáhají nalezení hraniční čáry mezi systémem a jeho okolím a informují, jaké jsou vazby systému k okolí. Pod pojmem okolí systému budeme rozumět uživatele, procesy a vztahy, jež sice systém ovlivňují, ale nejsou jeho přímou součástí.

Představme si, že analyzujeme systém bezpečnostní agentury, určený pro evidenci a obsazení pracovních pozic. Na pohovoru s manažerem náboru dostaneme informaci, že některé pozice vyžadují vyhlášení výběrového řízení. Výběrové řízení musí být schváleno třemi členy vedení společnosti. Po skončení pohovoru napíšeme případ užití, který popíše průběh procesu pro vyhlášení výběrového řízení. Na další schůzce při debatě nad obsahem nového případu manažer upřesní, že workflow pro vyhlášení výběrového řízení již podporuje jiný systém, se kterým jsou zcela spokojeni. V našem systému se bude evidovat pouze datum vyhlášení výběrového řízení. Evidence data výběrového řízení se stane novým případem užití v rámci systému, workflow pro vyhlášení výběrového řízení vytěsníme mimo hranice systému. Nejsou-li podchyceny hranice systému, nemůže existovat shoda mezi zadavatelem a realizátorem nad rozsahem systému.

Druhá důležitá otázka, na níž nalezneme odpověď v případech užití, může být formulována jednoduše: Kdo používá systém? Uživatelé systému se nazývají aktoři. Pojem aktor překvapivě mnoho analytiků špatně chápe. Název aktora vystihuje roli uživatele nebo jiného systému při interakci s naším systémem. Aktorem není nikdy konkrétní osoba, ale jde o roli, kterou může vůči našemu systému hrát mnoho osob nebo jiný systém. Jedna konkrétní osoba může v průběhu práce se systémem vystupovat ve více rolích.

Správně pojmenovaní a navržení aktoři:

• administrátor
• obchodní zástupce
• lektor
• systém SAPProcessor pro přenos založených objednávek do SAPu

Špatně identifikovaní a pojmenovaní aktoři:

• Vilém Málek (konkrétní osoba není aktor)
• osoba vyhledávající údaje o objednávkách (příliš všeobecný popis, aktor pouze s jednou odpovědností)

Notace pro případy užití

Případy užití jsou zachyceny ve vizuální a textové podobě. Diagramy případů užití (UseCase diagrams) nám poskytnou rychlou představu o jednotlivých funkcích systému, ale přesné postupy, rozšiřující a alternativní scénáře musejí být zachyceny v textové formě. V jazyce UML je kodifikován pouze diagram případů užití, strukturu dokumentu s textem případů užití si musíme navrhnout sami.

V UML diagramech zachycujeme případy užití, aktory a jejich vztahy. Případ užití je v UML diagramech zobrazen jako ovál s názvem případu. Doporučuji, aby z důvodu přehlednosti a rychlé orientace bylo součástí názvu případu i jeho jednoznačné identifikační číslo (UC001, UC002 a tak dále).

Pro aktora jsou navrženy dva rovnocenné symboly. Prvním z nich je symbol postavy a druhým čtverec. Symbol postavy většina analytiků používá pro aktora zastupujícího osoby, symbol čtverce, na nějž je ještě aplikován stereotyp <<system>>, reprezentuje externí systémy. Oba symboly musejí vždy obsahovat název aktora.

Nejdůležitějším vztahem v diagramu je přiřazení případu užití k aktorovi. Přiřazení je vyjádřeno plnou nepřerušovanou čárou. U tohoto vztahu se předpokládá stereotyp <<communication>>, i když se v diagramu případů užití nezobrazuje. Jednoduchý diagram případů užití:

UML diagram – přiřazení případu užití k aktorovi (plná velikost, cca 10 kB)

Na diagramu systému „Objednávky a Faktury“ nalezneme případy užití „Založení objednávky“ (UC001), „Tisk objednávky“ (UC002), „Prohlížení sestav“ (UC003) a „Import nových faktur“ (UC004). Aktoru s názvem „Obchodní zástupce“ jsou přiřazeny případy „Založení objednávky“ a „Tisk objednávky“ a také případ užití „Prohlížení sestav“, který sdílí s aktorem „Manažer“. Aktor „SAP“ vyžaduje od našeho systému podporu při importu nových faktur. Případy užití jsou umístěny v modrém obdélníku symbolizujícím pomyslné hranice modelovaného systému.

Při analýze reálného systému však běžně identifikujeme desítky i stovky případů užití s množstvím závislostí, jejichž přímé a naivní zobrazení by vypovídací hodnotu diagramu zcela ochromilo. Jak naznačit, že určitá sekvence kroků se v mnoha UC opakuje? Jak rozšířit nějaký případ užití o nepovinné chování? Co s případy užití nebo aktory, sdílejícími mnoho společných rysů a zvyšujícími komplexnost diagramu redundantními vazbami? Jak se vyrovnat s nudnými a monotónními případy užití pro správu číselníků? Jak vidíte, podobných otázek není málo. Příští článek se proto bude věnovat mimo jiné upřesňujícím vztahům include a extend mezi případy užití a zaměří se také na význam generalizace elementů.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.