Návrh aplikací v jazyce UML – textová specifikace případů užití

V předchozích článcích popisované diagramy případů užití jsou pomůcky pro rychlou orientaci ve funkčních požadavcích na systém, jejichž významovým podložím musí být podrobný textový popis případů užití. Tento článek vybočuje ze zaměření série na návrh aplikací v UML, protože UML žádnou normalizovanou osnovu pro textové případy užití nenabízí, a proto budu vše vysvětlovat na šabloně, jejíž současnou strukturu můžete považovat za jednu z inkarnací mých zkušeností z projektů, na kterých jsem se podílel.

I když mně šablona zcela vyhovuje, vy se jí nemusíte dogmaticky držet a berte ji raději jen jako prověřený prefabrikát připravený pro zakomponování do vašich vlastních analytických postupů.

Představme si, že vytváříme systém pro zpracování a oběh korespondence ve firmě a že máme nyní za úkol napsat případ užití, kdy je zásilka předána ke zpracování řešiteli, který je informován o nově přiděleném úkolu automaticky generovaným emailem.

Úvodní informace

Každý případ užití je identifikován svým názvem a pořadovým číslem a je umístěn v samostatném dokumentu. Název i pořadové číslo případu užití se samozřejmě shoduje s údaji v diagramu případů užití. Z důvodu přehlednosti a snadného vytváření rychlých odkazů mezi dokumenty doporučuji, aby i název souboru obsahoval název a pořadové číslo případu užití. Sám v názvech dokumentů nepoužívám diakritiku a mezery mezi slovy nahrazuji podtržítky.

Název případu užití:
UC001 Předání zásilky ke zpracování řešiteli
Název souboru s textovým popisem případu užití
UC001_ Predani_zasilky_ke_zpracovani_ resiteli

Ihned za názvem by měla být informace o stavu dokumentu. Pro případy užití jsou většinou důležité jen 2 stavy – stav “Na dokumentu se pracuje“ a stav “Schválen zákazníkem“.

Stav dokumentu:
Schválen zákazníkem

Každý dokument by měl obsahovat stručnou historii provedených úprav. Eviduje se datum změny, nová verze dokumentu, autor změny a stručný popis změny.

Případ užití je uvozen stručným popisem za účelem rychlého zorientování čtenáře v řešené problematice.

Stručný popis:
Po přijetí zásilky a vytvoření její elektronické podoby (karty) je vybrán řešitel zásilky. Vybrat nového řešitele může také již přiřazený řešitel v případě, že o řešení zásilky sám nemá zájem.

Abychom se při designu a vývoji systému soustředili na nejčastěji využívané funkce systému a zbytečně nealokovali finanční a lidské zdroje na technologicky precizní řešení funkcí, jež jsou ale pak využívány jen v přestupném roce, zjišťujeme a evidujeme, jak často by měl být dle zadavatele scénář případu užití realizován.

Frekvence užití
30x denně

Následuje seznam aktorů i s popisem jejich role v případu užití.

• Zakladatel karty – osoba, která mj. poprvé přiděluje kartu zásilky řešiteli.
• Řešitel – osoba, které bylo přiděleno řešení zásilky a která řešení deleguje na jinou osobu.

Tok událostí

Nejdůležitější je v případech užití tok událostí neboli podrobný postup, jakým je dosaženo hlavního funkčního záměru případu užití. V šabloně rozlišuji tři typy toku událostí.

• Základní tok událostí – v základním toku událostí je umístěn maximálně stručný a přitom kompletní postup při realizaci případu užití. V základním toku se nesmí objevit žádné větvení toku ani žádné podrobné informace, jak je daného postupu dosaženo. Separací alternativního a rozšiřujícího chování nepřetížíme hlavní tok událostí pozornost odvádějícími podrobnostmi ani rozptylujícími variacemi chování. Tok případů užití, s nimiž je spojen popisovaný případ užití relací <<Include>> nebo <<Extend>>, může být do hlavního toku vložen zapsáním slova <<Include>> nebo <<Extend>> následovaném plným názvem inkriminovaného případu užití.
• Alternativní tok událostí – v alternativním toku jsou zapsány všechny odchylky od lineárního toku událostí (podmíněné kroky postupu, opakování kroků – cykly)
• Rozšiřující tok událostí – rozšiřující tok obsahuje všechny relevantní podrobnosti k bodům postupu v hlavním toku.

Základní tok událostí

1. <<Include>> UC002 –Zobrazení seznamu karet zásilek.
2. Uživatel vybere kartu zásilky.
3. Uživatel dá příkaz k zobrazení karty zásilky.
4. Systém zobrazí požadovanou kartu zásilky.
5. Uživatel vybere nového řešitele.
6. Uživatel potvrdí přiřazení řešitele.
7. Systém uloží informaci o novém řešiteli.
8. Systém odešle novému řešiteli email s notifikací o přiřazení úkolu.

Alternativní tok událostí

Body 3,4

• Uživatel může přerušit proces změny řešitele. Žádná změna nebude uložena Konec případu užití.

Rozšiřující tok událostí

Bod 7

1. V emailu musí být zahrnuty všechny evidované informace o odesílateli zásilky.

Doplňující informace

Již v případech užití můžeme začít navrhovat aplikační práva pro jednotlivé aktory v systému.

Přístupová práva

Zákazník při analytických pohovorech také často vznáší předběžné požadavky na očekávané odezvy systému K evidenci zadavatelem preferované doby odezvy slouží sekce Doba odezvy.

Doba odezvy
Otevření karty zásilky – 5 sekund

Důležité operace v systému by měly být ukládány do protokolu o činnosti systému, aby bylo snadné v případě nutnosti dohledat, kdy jaká změna nastala a kdo je původcem změny.

Požadavky na logování
Systém zaeviduje do logu datum a čas změny, číslo zásilky, identifikátor uživatele, který změnu provedl a identifikátor nového i původního řešitele.

Jestliže zadavatel vznese ještě další speciální požadavky na průběh případu užití, tak je zapíšeme do sekce s názvem Ostatní požadavky.

Kritické podmínky, které musejí být splněny, aby mohl být případ užití spuštěn, jsou v sekci Podmínky před spuštěním.

Podmínky před spuštěním
Karta zásilky není označena příznakem „Nevyžaduje řešení“.

Dokončení instance scénáře případu užití znamená, že v systému proběhly všechny změny, jejichž seznam je v sekci Stav po ukončení.

Stav po ukončení

• U zásilky změněn řešitel.
• Odeslán email novému řešiteli.

Čerpá-li náš případ užití informace z jiného dokumentu, například z rámcového zadání vytvořeného zákazníkem, uvedeme v dokumentu seznam použitých zdrojů.

Požadavky uživatelů relevantní pro funkcionalitu
Návrh systému Evidence korespondence – kapitola Řešení zásilek na straně 25

Všechny nejasnosti a sporné body vyžadující konzultaci se zadavatelem, dalším analytikem nebo projektovým vedoucím si poznamenáme v poslední sekci Poznámky a problémy.

Poznámky a problémy
Bude se držet historie řešitelů?

Po schválení finálního znění textových specifikací všech případů užití zákazníkem přistoupíme většinou k vytváření diagramu tříd. Diagram tříd bude hlavním tématem následujících částí seriálu.

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

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