Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <<include>>

Transkript

1 Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <<include>> autor RNDr. Ilja Kraval leden Úvod Tento článek navazuje jako pokračování na články předešlé. Minule jsme si zde uvedli, že na hádanku z první části článku odpovědělo opravdu překvapivě hodně čtenářů. Také jsme si důkladně rozebrali první odpovědi. Dnes si uvedeme správné řešení. Jenom připomenu, že 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 Správná a výstižná odpověď Některé z odpovědí uvedené minule se sice snažily popsat chybu, ale nebyly úplně přesné anebo se soustředily až na důsledky této chyby. Uvedeme si nyní dobré řešení zaslané čtenářem. Považuji tuto formulací za nejvýstižnější. Poté si vysvětlíme podstatu tohoto problému. Odpověď kolegy zní takto: --- Dobrý den, k hádance: Domnívám se, že UC Vytisknout žádost se nespouští až po skončení UC Založit žádost, ale v jeho rámci. Posledním krokem UC Založit žádost má být include UC Vytisknout žádost, a teprve po provedení tohoto kroku je žádost založena. Je možné, že v UC diagramu bude spousta čar, ale je to tak správně. Osobně dávám přednost specifikaci UC ve formě textového dokumentu, pokud si mohu vybrat. S pozdravem, J. D. --- Tato formulace je velmi přesná a nyní si ji vysvětlíme podrobněji. Jak funguje vztah <<include>> Představme si, že píšeme scénář k nějakému případu užití, nazvěme tento případ užití například jako A. Spokojeně dokončíme práci s tímto prvkem modelu, scénář je hotov a vypadá dobře. O chvíli následuje zpracování dalšího případu užití, nazvěme jej například jako případ užití B. Najednou při tvorbě scénáře nového případu užití B dostaneme velmi silný pocit dejavu: Toto jsme už jednou někde psali! A opravdu zjistíme, že celá jedna část textu se opakuje, jak ve scénáři případu užití A, tak ve scénáři případu užití B. Samozřejmě, tohoto si můžeme všimnout pouze v případě, že dodržujeme pravidla pro psaní scénářů případů užití, jako je například zákaz používání synonym (tj. jeden pojem ve scénářích musí být vždy vyjádřen pouze stejným slovem), používáme ustálená slovní spojení (tj. vzory scénářů). Pokud totiž tato pravidla nedodržujeme, shody si nemusíme všimnout, protože stejná pasáž bude popsána pokaždé jinými slovy. Poznámka: O pravidlech psaní scénářů v USE CASE DIAGRAMECH viz například školení pro jednotlivce anebo školení firemní Strana 2

3 Tuto situaci si můžeme znázornit ilustračním obrázkem takto: A B scénář A scénář B obrázek 1 ve scénáři A a scénáři B se objevuje stejná část textu Jako příklad takovéhoto opakující se části scénáře můžeme uvést následující ukázku textu:... Obsluze se zobrazí seznam fyzických osob (rodné číslo, jméno, příjmení), obsluha vybere fyzickou osobu.... Takovýto výběr fyzické osoby se ve scénářích opravdu často opakuje... Pro ty z vás, kteří znají základní princip objektového přístupu při modelování, je situace na obrázku velmi povědomá! Je to situace stav před vytknutím u principu opětovné použitelnosti resp. objektového paradigmatu. Objektový princip modelování žádá zavést interakci mezi prvky modelu a tím se zamezí opakování částí prvků, tedy laicky řečeno, ono zelené se principem objektového paradigmatu žádá vytknout mimo oba prvky a mělo by se opětovně použít z obou prvků. V tomto našem případě se použije pro toto vytnutí interakce <<include>>. Autor modelu je nyní povinen provést tyto kroky (zdůrazňuji slůvko povinen!): Strana 3

4 1. Zavede třetí prvek případu užití, nazve jej například případ užití C, a do něj umístí text scénáře opakující se v obou případech užití (například přenese text přes schránku clipboard) 2. Zavede v diagramu interakci <<include>> takto: A «include» «include» C B obrázek 2 Vytknutí společného scénáře do třetího prvku případu užití 3. V místech textů, kde se původně opakující text vyskytoval, tento opakující se text smaže. Místo něj umístí formulaci odkazu, například takto:...a dále se provede případ užití C... Ideální je, pokud pro tuto operaci odkazování využije nástroj EA Object Editor (viz podrobněji na straně ). Tento nástroj totiž drží konzistentně odkaz v textu i při změně názvu případu užití C na jiný název. Pro jednoduché vysvětlení předešlého postupu si můžeme uvést paralelu jednoduchého vytknutí opakujícího se kusiska kódu ve volání funkcí (resp. metod objektu). Vytknutí opakujícího se kódu do funkce funguje úplně stejně, jenom namísto interakce <<include>> je použita interakce zavolání funkce. Jinak řečeno, jak vytknutí opakujícího se kódu, tak vytknutí stejných částí textů scénáře jsou konkrétními realizacemi obecnějšího postupu objektového paradigmatu a opětovné použitelnosti. Ještě je třeba podotknout, že v předešlém případě, kdy se části textů opakovaly, je povinností autora modelu zavést tuto interakci vytknutím, protože části scénářů by se neměly v analytickém USE CASE modelu opakovat. Dá se říci, že interakce <<include>> je zavedena primárně za účelem zamezení tohoto zdvojení. Avšak je povoleno použít interakci <<include>> také v případě, kdy se nejedná o situaci žádající zavést opětovnou použitelnost. Autor se prostě rozhodne část scénáře vytknout pouze z kosmetických důvodů. Například scénář je příliš dlouhý a autor zváží, že je lepší některé jeho části zavolat přes <<include>> kvůli přehlednosti Strana 4

5 celkového scénáře. Tento postup je také znám u psaní funkcí: Někdy se příliš dlouhé funkce prostě rozsekají na menší funkce a ty se zavolají z hlavní funkce, i když tyto menší nikdy nebudou volány odnikud jinud, než z toho místa, odkud byly vytknuty. Někdy zase autor modelu chce pouze to, aby se určitá část scénáře identifikovala v diagramu a byla vidět jako prvek diagramu, tedy jako případ užití. Pokud autor vytkne případ užití z takovýchto důvodů, tak můžeme vidět například diagram v této podobě: X «include» Y obrázek 3 Include kosmetické a ať hledáme, jak hledáme, nemůžeme nikde najít, že by ještě jiný prvek nežli X měl také <<include>> na prvek Y. Jinak řečeno, prvek Y byl vytknut ven, ale nikoliv proto, aby si na něj mohl jiný prvek typu USE CASE ukázat, ale buď proto, že scénář X je velmi dlouhý anebo že chceme, aby prvek Y byl vidět na diagramu jako samostatný prvek se svým názvem. Důležité je, že ať už vytkneme prvek případu užití z důvodu opětovné použitelnosti, anebo z kosmetických důvodů, platí základní důsledek objektového paradigmatu, a ten je právě předmětem našeho dotazu. Objektové paradigma v modelování Podívejme se na následující obrázek Strana 5

6 A «include» C obrázek 4 Obrázek k dotazu a zkusme odpovědět na tuto otázku: Pokud budeme chtít zkontrolovat celý scénář případu užití A, tak, jak vyplývá z postupu vytknutí, v určitém místě narazíme na odkaz na volání případu užití C (...a dále se provede případ užití C...). V tomto místě by měl ten, kdo kontroluje opravdu celý scénář, odskočit do scénáře případu užití C a přečíst celý scénář C (úplně stejně, jako když se krokuje funkce step into ), a až skončí se scénářem případu užití C, měl by se vrátit těsně za bod odskoku a dočíst scénář případu užití A. A teď následuje otázka (kterou účastníci našeho školení znají dobře): Ten, kdo kontroluje scénář A, si musí přečíst i scénář C, pokud chce míst jistotu, že vše sedí. Otázka tedy zní takto: Když řeknu případ užití A, mám na mysli případ užití A nebo A plus C? První odpověď, která nás napadne, je že určitě musím mít na mysli A + C, protože přece samotné A bez C nemá smysl! No to je sice pravda, ale představme si, že někdo cizí se zdravým selským rozumem vejde do místnosti a my se zeptáme: Když řeknu A, mám na mysli A nebo A+C? Asi tušíme, co nám odpoví a jak se u toho bude usmívat. Kde je problém? Začínáme si odporovat: Přece samo A je samo A (to zní až pravdivě hloupě!), ale na straně druhé přece scénář celého případu užití A je chápán jako celý scénář A+C, který musíme číst opravdu celý! Odpověď je skryta v obecném principu objektového paradigmatu v modelování a zní: Při modelování je každý pohled na prvek v libovolném diagramu vždy relativní! Relativnost je synonymum pro slovní spojení: Záleží na úhlu pohledu a proto jsou platné obě odpovědi! Neexistuje totiž absolutní pohled na prvek v modelu. Buď se díváme na prvek zvně a vidíme jeho služby. Například v našem příklad někdo zvně vidí případ užití A jako knoflík poskytující jedno užití svým stiskem knoflíku. To je vnější pohled. Když někdo stiskne tento knoflík, dostane službu tohoto prvku a to bez hledu na to, zda je prvek C vytknut anebo nikoliv. Vnější pohled je pohled na službu resp.služby prvku a je to proto pohled sumarizující: Hovoříme o A jako celku Strana 6

7 z pohledu služby, tedy nutně musí proběhnout opravdu vše za touto službou, ať je to uvnitř jakkoliv uspořádané. Existuje však v relativnosti pohledu druhý pohled, a to je vnitřní pohled, tedy jak je tato služba implementována, jak je zavedena vnitřně. A tam vidíme, že A obsahuje v interakci <<include>> prvek C a tedy prvek A použije jeho službu stisknutím jeho knoflíku. Nikdy nemůžeme stát venku i uvnitř současně a proto na otázku, jak vidíme A, zda A nebo A+C, dostaneme opravdu šalamounskou odpověď: Záleží na úhlu pohledu. Bavíme se o knoflíku A viděném zvenku anebo o A za hranicí tohoto knoflíku, tedy jak je vnitřně A strukturováno a jak je složeno? Kolega ve své odpovědi se tomuto jasnému, ale složitému vysvětlení vyhnul velmi elegantně slovy:...domnívám se, že UC Vytisknout žádost se nespouští až po skončení UC Založit žádost, ale v jeho rámci... Tímto vyjádřil onu skutečnost, že případ užití Založit žádost je viděn zvenku jako jeden případ užití (tj. zvenku nejsou dva po sobě jdoucí případy užití... ). Slovíčko v jeho rámci je synonymum pro vnitřní scénář. Je zřejmé, že chyby tohoto druhu vznikají právě nepochopením objektového paradigmatu, tj. jak funguje vnější a vnitřní pohled na prvky. Když se totiž podíváme na předešlý obrázek 4, tak nám může připadat jako podivná otázka: Kolik případů užití je na obrázku vidět? Odpověď: Samozřejmě, že dva! Ale pozor, věc není až tak jednoduchá. Doplňme obrázek ještě o prvek typu ACTOR takto: A Obsluha «include» C Strana 7

8 a zeptejme se trochu jinak: Kolik případů užití systému na tomto obrázku vidí sama Obsluha? Odpověď: Vidí jeden, a to případ užití A. Na tento rozdílný pohled zvně (obsluha vidí jeden) a zevnitř (služba je uvnitř složena pomocí dvou prvků A + C) si musí autor modelu zvyknout, jinak dojde k protimluvům a chybným závěrům... Podobná řešení Zmínil bych se ještě o odpovědích čtenářů, které se sice lišily, ale byly podobné předešlému řešení. Vyberu z nich jednu charakteristickou odpověď:... Oba UC zmíněné v zadání (Založit žádost, Vytisknout žádost) by měly být na sobě nezávislé a být součástí třetího UC např. Přidat žádost. V rámci něho je definovaná posloupnost jejich provádění, tj. napřed Založit žádost, pak Vytisknout žádost. Kromě toho alternativní scénář - jestliže se první UC úspěšně nedokončí, druhý se neprovádí. Oba UC (Založit žádost, Vytisknout žádost) je možné vyvolat i samostatně nebo z jiných UC. UC Vytisknout žádost může být proveden pouze nad žádostí, která je založená. S pozdravem P.L. I když to tak na první pohled nevypadá, toto řešení je v podstatě takřka shodné, jako předešlé řešení, jen s tím rozdílem, že se autor rozhodl nazvat případy užití jinak: Přidat žádost na tomto obrázku je vlastně onen sumární případ užití z předešlého řešení, kde se nazýval Založit žádost. Tady se oproti tomu jako Založit žádost nazývá ta část scénáře, která předchází tisku. Oba scénáře vyjdou nakonec nastejno, jenom názvy případů užití jsou jiné: Strana 8

9 První varianta návrhu vypadá potom schematicky ve scénářích takto: UC Založit žádost Scénář: Udělá se toto, potom toto atd. Pokud OK, dále se provede tisk žádosti viz UC Tisk žádosti Druhá varianta návrhu (jiný model než předešlý!) má následující podobu: UC Přidat žádost Scénář: Provede se založení viz UC Založit žádost Pokud OK, dále se provede tisk viz UC Tisk žádosti UC Založit žádost Scénář: Udělá se toto, potom toto atd. Všimněte si, že pokud pomineme jiné názvy případů užití, tak tyto dva scénáře se liší pouze tím, že je buď vytknuta nebo není vytknuta tato část scénáře: Udělá se toto, potom toto atd. Závěr Díky objektovému paradigmatu můžeme paradoxně při pohledu zvně vidět dva prvky na diagramu jako jeden použitelný zvně (tj. zde případy užití), pokud spolu interagují. Je to velmi podobné, jako při volání funkcí: Funkce F1 volá funkci F2, ale já vidím a volám pouze hlavičku F1, protože F2 je skryta. Vnější pohled tedy implikuje i nutné vyvolání toho, co se děje uvnitř F1, aniž bychom zvně viděli, jak k tomu dojde. Jinak řečeno zvenku vidíme jedno celé F1, ale vnitřní struktura je F1 plus F2. Podobně v předešlém dotazu chyba spočívá v tom, že ve vnějším pohledu je vidět pouze jeden případ užití, ať už ho nazveme Založit žádost podle první varianty Strana 9

10 anebo Přidat žádost podle druhé varianty. Teprve v rámci něj se spustí druhý případ užití Tisk žádosti. Nakonec ještě drobná poznámka k jedné větě odpovědi z první varianty, kde kolega píše:...osobně dávám přednost specifikaci UC ve formě textového dokumentu, pokud si mohu vybrat... Co se týče mne, dávám přednost kombinaci obou dvou, což umožňuje zmíněný produkt EA Object Editor (viz konec článku Strana 10