UML diagramy případů užití

Diagram případů užití je mapa rozsahu. Pojmenovává lidi a systémy, které komunikují s tím, co stavíte, cíle, se kterými k tomu přicházejí, a čáru mezi vnitřkem a vnějškem. To je všechno, co dělá, a právě jeho zdrženlivost je smyslem.

Neříká nic o pořadí. Nic o obrazovkách, polích či algoritmech. Nic o tom, jak cokoli funguje. Každé z toho je jiný diagram a pokušení propašovat je na tenhle je to, co vyrábí rozbujelé a nepoužitelné diagramy případů užití, které této notaci udělaly špatné jméno.

Seznam vám nikdo nedá. Diagram výše vypadá po nakreslení samozřejmě a předtím samozřejmý vůbec nebyl; mezeru mezi prázdným papírem a tím obrázkem vyplní čtyři otázky, které se v místnosti dají položit za dvacet minut.

1. Kdo tu něco začíná? Každý z nich je kandidát na primárního aktéra. Ptejte se na roli, ne na jméno - člověk, který řekl „to dělám já“, je jedním nositelem role, která ho přežije.
2. Kdo nebo co něco dostává, aniž by o to žádal? Reporty, soubory, notifikace, zúčtovací běhy. Tohle jsou podpůrní aktéři na pravé straně hranice a je to ta polovina diagramu, která většině prvních návrhů chybí.
3. Co tam musí být, aby to fungovalo? Platební poskytovatelé, identitní služby, mainframe, protipodvodný engine. Cokoli, kvůli čemu byste zakládali ticket jinému týmu, je mimo hranici a patří na diagram - jeho nakreslení bývá okamžikem, kdy si někdo uvědomí, že ta závislost nikdy nebyla dohodnuta.
4. Co se děje proto, že uběhl čas? Noční rekonciliace, čtrnáctidenní expirace, měsíční fakturace. Čas je aktér, kreslí se jako panáček s popisem Clock nebo Scheduler, a procesy, které ho vynechají, končí s případy užití, které zdánlivě nikdo nezačíná.

Pak pojmenujte každý cíl z aktérovy strany pultu, slovesem napřed, jeho slovníkem: Submit payment, ne Payment submission handling a už vůbec ne PaymentController. Pokud název dává smysl jen někomu, kdo viděl kód, je to krok v případu užití, ne případ užití.

Tyhle dva jsou důvodem, proč se diagramy případů užití kreslí špatně. Oba jsou přerušované šipky s klíčovým slovem a ukazují opačnými směry.

«include» ukazuje od základního případu k tomu, co vždy dělá. Čtěte to jako „volá“. V diagramu výše Submit payment zahrnuje Authorize payment: nejde odeslat bez autorizace. Existuje proto, aby vyňal chování sdílené několika případy - a přesně proto ho zahrnuje i Refund payment.

«extend» ukazuje od nepovinného doplňku zpět k základnímu případu. Čtěte to jako „může přerušit“. Log audit trail rozšiřuje Refund payment: refundace fungují i bez něj a děje se za jisté podmínky. Základní případ o svých rozšířeních neví.

Diagram je obsah knihy. To, z čeho se opravdu staví, je popis případu užití za každou elipsou - a projekt, který nakreslí diagram a popisy nikdy nenapíše, vyrobil obrázek práce místo její specifikace. Právě o téhle části notace neříká nic, a proto tolik týmů zůstane u obrázku.

Existují tři užitečné hloubky a výběr je rozhodnutí projektu, ne modelování. Stručný popis jsou dvě věty v backlogu. Volný je odstavec na scénář. Plně rozvinutý má pole níže a vyplatí se u té hrstky případů, které nesou skutečné peníze nebo skutečné riziko.

• Název. Popis elipsy, sloveso napřed: Authorize payment.
• Primární aktér. Ten, kdo chce výsledek. Merchant.
• Zainteresovaní a jejich zájmy. Komu dalšímu na tom záleží a co z toho potřebuje. Akviziční banka chce platný autorizační kód; protipodvodný tým chce mít pokus zaznamenaný bez ohledu na to, zda uspěl. V tomhle poli se objeví většina chybějících požadavků.
• Předpoklady. Co už platí, když případ začíná - obchodník je přihlášen, objednávka existuje. Ne seznam kroků, ale seznam záruk.
• Hlavní úspěšný scénář. Očíslovaná šťastná cesta, krok aktéra a pak krok systému, v jazyce byznysu. Někde mezi pěti a dvanácti kroky; víc znamená, že případ užití jsou ve skutečnosti dva.
• Rozšíření. Očíslovaná podle kroku, ze kterého se větví - 4a, 4b, 7a - každé s podmínkou a s tím, co se stane. Tohle je pole, kvůli kterému se formát vyplatí, protože je systematickou pobídkou pro každý způsob, jakým šťastná cesta selže.
• Následné podmínky. Co platí potom, při úspěchu i při každém selhání. „Autorizace je zaznamenána a prostředky jsou blokovány“ jde otestovat způsobem, jakým „platba je zpracována“ ne.

Rozpracováno v malém pro Authorize payment: hlavní úspěšný scénář je (1) obchodník odešle platbu, (2) systém ověří částku objednávky, (3) systém požádá akviziční banku o autorizaci, (4) banka vrátí schválení, (5) systém zaznamená blokaci a potvrdí. Práce je v rozšířeních - 3a bance vyprší čas, 4a banka zamítne, 4b banka si vyžádá dodatečné ověření - a každé z nich je rozhovor, který by jinak někdo vedl o šest týdnů později při triáži chyb.

Užitečný diagram případů užití se vejde na jednu stránku a má někde mezi třemi a deseti elipsami. Je to obsah, ne kniha. Detail patří do popisů případů užití - očíslovaného hlavního toku a jeho alternativ - nebo, pokud je tok dost větvený na to, aby se vyplatilo ho nakreslit, do diagramu aktivit na každý případ.

1. Funkční rozklad. Dvacet elips pojmenovaných podle tlačítek. Případy užití jsou cíle; pokud to není něco, co aktér chce, nepatří to sem.
2. Aktéři pojmenovaní podle lidí nebo pozic z organigramu. Modelujte roli. Jeden člověk může být několika aktéry a jeden aktér může být dávková úloha.
3. Prohozené šipky «include» a «extend». Ukazují opačně. Použijte test odstranění z výše uvedeného.
4. Aktéři uvnitř hranice. Hranice je to, co stavíte. Aktér je z definice mimo ni.
5. Pořadí naznačené svislou pozicí. Diagram případů užití nemá časovou osu. Nic na rozvržení neříká, co se děje dřív.