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.
Datum změny | Verze dokumentu | Autor | Popis změny |
---|---|---|---|
1.7.2004 | 1.0 | René Stein | Počáteční verze |
30.7.2004 | 1.1 | René Stein | Zanesen požadavek na notifikace |
2.8.2004 | 1.2 | René Stein | Dokument schválen zákazníkem |
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í
- <<Include>> UC002 –Zobrazení seznamu karet zásilek.
- Uživatel vybere kartu zásilky.
- Uživatel dá příkaz k zobrazení karty zásilky.
- Systém zobrazí požadovanou kartu zásilky.
- Uživatel vybere nového řešitele.
- Uživatel potvrdí přiřazení řešitele.
- Systém uloží informaci o novém řešiteli.
- 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
- 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
Systémová role | Přístupová práva |
---|---|
Recepční Řešitel |
Právo na zobrazení karty zásilky Právo na přidělení/změnu řešitele |
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.
Mohlo by vás také zajímat
-
Moderní trendy ve webdesignu: Top trendy pro rok 2024
12. ledna 2024 -
inPage AI: Revoluční nástroj pro tvorbu webů
3. července 2024 -
9 nejzajímavějších doménových koncovek
19. srpna 2024 -
AI na dosah ruky: Jak je to s AI v osobních zařízeních?
22. ledna 2024
Nejnovější
-
Jak chránit webové stránky před Web/AI Scrapingem
27. listopadu 2024 -
Jaký monitor je nejlepší k novému Macu Mini?
25. listopadu 2024 -
Výkonný a kompaktní: ASOME Max Studio s výjimečným poměrem cena/výkon
11. listopadu 2024 -
Šokující data od Microsoftu: Kyberútoky rostou o stovky procent!
8. listopadu 2024