Třetí část odpovědi na mail ohledně zpracování případů užití, aneb jak je to s číslováním pořadí případů užití

Transkript

1 Třetí část odpovědi na mail ohledně zpracování případů užití, aneb jak je to s číslováním pořadí případů užití autor RNDr. Ilja Kraval leden Úvod Tento článek navazuje jako pokračování na článek předešlý. Minule jsme si zde dali jednu hádanku a s potěšením musím konstatovat, že odpovědělo opravdu překvapivě hodně čtenářů. S potěšením jsem si pročítal v haldě mailů odpovědi na otázku kde je chyba v předešlém článku. Mimochodem, napadla mne zajímavá myšlenka zavést na našem serveru kvízové otázky z modelování a návrhu IS podobného charakteru a zapojit tak čtenáře do živé diskuse. Dnes si důkladně rozebereme první odpovědi. Jenom připomenu, že minule jsme se ptali, kde je chyba v této větě:...například ihned po ukončení UseCase Založit žádost následuje vždy UseCase Vytisknout žádost, jehož obsah ale nemůže být součástí UseCase Založit žádost, protože tisk žádosti se provádí nejen po jejím založení ale i v jiných dalších případech a tak je existence samostatného UseCase pro popis tisku žádosti zcela oprávněná... Strana 1

2 Jak je to s číslováním pořadí případů užití Některé z odpovědí se sice snažily popsat chybu, ale nebyly úplně přesné anebo se soustředily až na důsledky této chyby. Vybral jsem jednu z nich, která plně vystihuje problém. Zkusme se zamyslet nad touto sice nikoliv chybnou, ale ne úplně přesnou odpovědí: Zdravím Vás, myslím, že v USE CASE nevyjadřujeme časovou posloupnost. Proto je špatně část... ihned po ukončení UseCase Založit žádost následuje vždy UseCase Vytisknout žádost... S pozdravem a díky za vaši práci S.M. Poznámka: Nejprve musím odpovědět na poděkování na konci mailu, které mne potěšilo. Jako odpověď použiji jeden typicky americký výrok: OK, it s my job. A jen dodám, že výuka modelování IS pomocí UML a OOP je prací, která mne baví. Je třeba zdůraznit, že ono to s posloupností případů užití není až tak jednoduché a úvaha o posloupnosti může vést i k omylům! Kolega v předešlém mailu má pravdu v tom, že přímo v syntaxi modelu případů užití není uvedena povinnost uvádět posloupnost případů užití tak, jak jsou vyvolány (instanciovány, použity) po sobě. Dokonce pokud se jedná o případy užití nabízené ven ze systému, tak pořadí případů užití z hlediska principu anonymity klienta systému ani nemá smysl! Posloupnost jak by se případy užití nabízené ven měly vyvolat po sobě (výrazně zdůrazňuji kondicionál v této větě!) je dána pouze posloupností procesů v podniku, tj. posloupností v chodu podniku! Je třeba zdůraznit, že každý samotný případ užití nabízený ven může být vyvolán a použit kdykoliv a proto musí být každý případ užití navržen slangově řečeno blbovzdorně. Například každému je jasné, že před tím, než se odsouhlasí úvěr, musí být daný úvěr založen, musí být vyplněn a také překlopen do stavu připraven k odsouhlasení. Z hlediska procesů podniku je zřejmé, že úvěr v podniku se nejprve zakládá, poté se vyplňuje potřebnými údaji, tak se připravuje k odsouhlasení a poté se zavolá případ užití pro odsouhlasení. Ale v případech užití uvnitř algoritmů se nesmíme spolehnout, že proces podniku venku musí běžet a poběží zrovna takto. Případ užití Odsouhlasení úvěru může být totiž spuštěn kdykoliv! Jak tedy ošetřit tuto libovůli Strana 2

3 spuštění zvenku? Samotný případ užití odsouhlasení musí být uvnitř navržen tak, že nelze obsloužit jiné úvěry, než úvěry připravené k odsouhlasení. Například případ užití začíná výběrem úvěrů v tomto stavu, tj. ve stavu připraven k odsouhlasení : část scénáře:...obsluze se zobrazí seznam úvěrů ve stavu úvěr připraven k odsouhlasení, obsluha vybere jeden úvěr atd. Poznámka na okraj, opravdu technická: S výhodou lze použít pro odkazy nástroj EA Object Editor (viz ), který se zavádí ve firmách ve stále větším počtu licencí. Tzv. živé odkazy na prvky v modelu EA jsou zde zdůrazněny pomocí žluté barvy. Zde ve scénářích UC jsou jimi modelovací prvky tzv. user concepts, které budou mapovány na objekty programu a poté na model tříd programu. Nyní již vidíme první kandidáty na toto mapování žlutě: 1. seznam úvěrů, tj. budoucí objekt správce seznamu úvarů 2. samotný úvěr, tj. budoucí objekt samotného úvěru 3. číselník stavů úvěrů, jehož jedním itemem je úvěr stav připraven k odsouhlasení Tyto prvky se dále mapují na nalezené třídy a tím vzniká vztah mezi pojmy uživatele a modelem tříd, tedy vzniká to, co nazýváme interpretací evidované informace v programu uživatelem. Pokud v systému není ani jeden úvěr v tomto stavu, není co odsouhlasit a případ užití odsouhlasení končí hned na svém začátku. Je vidět, že vnitřní dobře navržená konzistentní stavovost výskytů informace je právě onou skutečností, která zaručuje požadovanou blbovzdornost v případech užití! Je třeba si uvědomit, že v předešlém odstavci byla řeč o případech užití nabízených ven spustitelných vnějším klientem systému kdykoliv. Pokud však popisujeme vnitřní implementaci případu užití, tj. popisujeme co se děje uvnitř případu při jeho použití (tj. v rámci vyvolání), tak v této implementaci, tj. popisu vnitřku, je již posloupnost toho, co se děje, dána přesně v časovém sledu a tedy takříkajíc po sobě. Jinak řečeno v popisu scénáře programu se doslova píše: udělá se toto, potom toto...atd.. Tímto vlastně popisujeme požadovaný algoritmus programu. Znamená to, že ve vnitřním scénáři případu užití vyjadřujeme velmi přesně (a pokud možno detailně) posloupnost toho, co se po čem děje. Z toho plyne, že pokud se v rámci scénáře odvoláme na případ užití pomocí <<include>>, tak toto volání má přesně definovanou pozici v posloupnosti scénáře a má proto smysl hovořit o pořadí tohoto zavolání v rámci tohoto scénáře. Uveďme si příklad pomocí jednoho klasického vzoru z modelování pomocí případů užití. Velmi často se vyskytuje situace, kdy obsluze se zobrazí seznam nějakých prvků, obsluha vybere jeden prvek ze seznamu a provede jeho editaci. Tento Strana 3

4 analytický scénář lze realizovat v designu pomocí jedné obrazovky, kde v jedné části (například vlevo) se zobrazuje seznam prvků a jinde (například vpravo) se zobrazuje detail vybraného prvku s možností editace. Protože se části scénáře výběr prvku a editace vybraného prvku volají i odjinud, zavedeme tyto části jako případy užití a provedeme na ně <<include>> (tj. vytkneme). Aplikace vzoru by pak mohl vypadat v příkladu třebas takto: Textový tvar: Případ užití Editace fyzické osoby s výběrem Scénář: Provede se výběr fyzické osoby obsluhou, viz UC Výběr fyzické osoby. Provede se editace aktuálně vybrané fyzické osoby, viz UC Editace aktuálně vybrané fyzické osoby. Poznámka: Jak vidět, opět je zřejmou výhodou, pokud i pro volání mezi případy užití pomocí <<include>> používáme nástroj EA Object Editor Graficky v diagramu potom toto řešení vypadá takto: «include» Editace fyzické osoby s výběrem Výběr fyzické osoby Editace aktuálně vybrané fyzické osoby «include» obrázek 1 Aplikace USE CASE PATTERNu Editace prvku s výběrem (tento diagram musí být v plném souladu s textem scénáře). Strana 4

5 Je logické a zřejmé (z uvedeného scénáře to vyplývá), že nejprve se v posloupnosti zavolá případ užití Výběr fyzické osoby a poté případ užití Editace aktuálně vybrané fyzické osoby. Syntaxe UML to nevyžaduje, ale tuto skutečnost bychom mohli znázornit také přímo v diagramu jako vlastnost samotného vztahu <<include>> pomocí prvku CONSTRAINT s udáním hodnoty v pořadí: «include» {order = 1} Editace fyzické osoby s výběrem Výběr fyzické osoby «include» {order = 2} Editace aktuálně vybrané fyzické osoby obrázek 2 Možnost využití prvku CONSTRAINT pro pořadí Poznámka: Jak se můžete seznámit se vzory modelování? Všechny užitečné a potřebné vzory návrhu IS (nejenom tento jeden) jsou podrobně probrány například na pobytovém školení (viz ), proto doporučuji účast na tomto školení. Všimněte si, že v předešlém obrázku má smysl očíslovat si vztahy typu <<include>> (nikoliv samotné případy užití,ale vztahy <<include>>!). Má tedy v tomto případě smysl udat třeba i graficky, jako jsou které případy užití volány v jakém pořadí. Pořadí vyplývá přímo ze scénáře volajícího případu užití. Poznámka: Osobně do diagramu toto pořadí neznázorňuji a ponechávám je čitelné pouze v textu scénáře. Strana 5

6 Závěr první: Ve svém důsledku závěrečná věta znamená, že odpověď kolegy není dostatečně úplně přesná, protože lze popsat situace, kdy má smysl očíslovat si pořadí volání případů užití! Ale přes tuto ne úplnou přesnost v odpovědi, kolega ve svém mailu vystihuje jako důsledek chybu v původním mailu! O opravdu přesné odpovědi pojednáme podrobně příště, nyní následuje pouze nápověda : Porovnejme si dvě situace. Na straně jedné máme situaci jako dotaz z mailu v úvodu tohoto článku, tj. předmět hádanky. Na straně druhé si prohlédněme číslování volání případů užití, tedy vztahů <<include>> v našem příkladu, viz obrázek 2 Možnost využití prvku CONSTRAINT pro pořadí! Tyto dvě situace se podstatně liší! V prvém případě, tj. v dotazu mailu, opravdu (jak píše odpověď) nemá smysl číslovat nějaké pořadí, v druhém však smysl má! Odpověď na hádanku následuje v dalším pokračování článku!...článek bude pokračovat! Strana 6