VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ Část 3 Tento článek je pokračováním předešlých článků RNDr. Ilja Kraval, duben 2009 http://www.objects.cz ÚVOD V předešlých článcích jsme se seznámili s použitím prvku typu Actor a s jeho významem. Připomeňme, že se jedná o prvek z okolí, který interaguje se systémem. Není to tedy libovolný objekt z okolí, ale ten, který je v interakci se systémem. Z hlediska vývojáře odhaluje interfacy systému, takže díky prvku Actor vznikají již v brzké fázi analýzy dotazy na následná technologická řešení všech interfaců informačního systému, což je žádoucí. V předešlých kapitolách jsme dospěli k těmto závěrům: 1. Procesní škola vyhledávání případů užití nemusí specifikovat prvky typu Actor, což je její výhodou. 2. Prvky typu Actor musíme jako vývojáři dohledat i v procesní škole, protože reprezentují interfacy systému a ty se musí při návrhu IS řešit. 3. Hádky nad kontextem prvku Actor mohou být zbytečné, pokud je odhalena podstata interfacu. 4. Prvek Actor se nesmí zaměnit s instancí Role uvnitř systému, jsou to totiž dva odlišné pojmy.
strana 2 PRVEK ACTOR A JINÉ CHOVÁNÍ PŘÍPADŮ UŽITÍ Na konci předešlého jsme řešili model popisujícího část evidence klasické knihovny: Byl nalezen případ užití Prohlížení titulů knihovny. Jednalo se o prohlížečku, která zobrazuje všechny možné informace o knihách včetně fyzické pozice titulu (kde se nachází fyzicky). Byly nalezeny tyto prvky v okolí jako prvky typu Actor: Knihovník, Administrátor a Čtenář. Autor modelu namaloval následující obrázek: Položili jsme si tyto otázky: Obrázek 1 Opět příliš mnoho prvků Actor? První otázka zněla, co myslíte, je toto řešení správné nebo ne? Odpověď je nasnadě: Není, protože nesouhlasí počet interfaců. Kolik sedí človíčků, když se prohlíží titul knihovny? Jeden. Jako druhá zazněla v příkladu tato otázka: Co když knihovník vidí jiné tituly než čtenář, například navíc tituly vyřazené? Je to jiný případ užití nebo není? Pro správnou odpověď si představme, jak bude tento program logicky fungovat. Systém ve svém programu nemůže podle toho, kdo sedí venku, volit jinou větev algoritmu anebo nasadit jiný filtr. Jedná se o jeden případ užití, kdy se uvnitř programu vyhodnotí přístupová práva podle přihlášené role (viz předešlá kapitola) a podle této role se nasadí odpovídající filtr na prohlížečku. Tato věta také zazní ve scénáři hned na začátku. strana 2
strana 3 Dalším problémem týkajícím se prvků Actor je otázka požadavku zákazníka, který chce vidět role k danému případu užití. Tuto otázku řeší následující kapitola. JAK ŘEŠIT POŽADAVEK ZÁKAZNÍKA, POKUD CHCE VIDĚT TZV. ROLE PODNIKU Vrátíme se k řešení problému, kdy zákazník chce mít v obchodních materiálech projektu znázorněno, která funkce v podniku používá který případ užití a navíc například i s četností (např. frekvence použití za den). V žádném případě bych nedoporučoval udělat ústupek v tom smyslu, že vytvoříme chybně více prvků typu Actor, než kolik napočítáme interfaců. To je opravdu hrubou chybou návrhu. Vhodnější je diagramy pro účely zákazníka tvořit jakoby bokem, tj. jako obchodní materiály pro specifický účel, tyto se nakonec ani nemusí dostat do vývoje. Jedná se tedy o dokumenty navíc jen pro zákazníka. Můžeme postupovat například takto: Zavedeme nový stereotyp pro typ prvku Actor. Tento stereotyp chápeme jako role v podniku. Název může být zvolen například jako business role nebo podobně. Není to prvek Actor v tom významu, jak jej známe, ale je to role neboli funkce v podniku. Proto bychom mu měli dát i jiný obrázek, například jiného panáčka takto: Obrázek 2 Možnost jiného obrázku pro funkci neboli roli v podniku Poté vytvoříme diagram vyjadřující, která role v podniku může používat který případ užití. K tomu můžeme s úspěchem použít obecný vztah Dependency, například takto: strana 3
strana 4 Ředitel Manažer Účetní Prohlížení statistik Obrázek 3 Znázornění vztahu rolí v podniku k případu užití pomocí Dependency pouze pro čistě obchodní dokument Velmi důležité je to, že máme takto zachovánu čistou podobu vývojářského dokumentu (který je samozřejmě jinde) se správným počtem interfaců, přitom jsme zákazníkovi vyhověli a nedopustili se žádné hrubé chyby v návrhu. Funkce podniku v dokumentech se přitom stávají pěkným okrasným prvkem, zákazník je spokojen a vývojáři se v jiném dokumentu dopočítají správného počtu interfaců. Navíc lze jednoduše ocenit každé dané Dependency číselnou hodnotou udávající například odhadovanou frekvenci použití tohoto případu užití touto funkcí za den. K tomu velmi dobře poslouží mechanismus tagových hodnot přiřazených ke každému Dependecy. PŘÍPADY UŽITÍ S NĚKOLIKA PRVKY ACTOR Je pravdou, že vždy při větším počtu prvků Actor zbystříme pozornost, zda je model správně, ale nemusí se vždy jednat o chybu rozmnožení actorů. Uveďme si příklad se čtyřmi prvky Actor a přitom každý z nich má nárok na život: Nechť chceme jako externí dodavatel dodat do banky k již existujícímu bankovnímu sytému (není naše řešení) novou agendu. Náš systém (mimo jiné) poskytuje službu klientovi s mobilem tak, že klient pošle mobilem zašifrovanou zprávu (šifruje sám mobil). Zpráva se dešifruje a rozparsuje (programujeme my). Poté se převezme pole nazvané podpis a strana 4
strana 5 odešle se na autentizační server, který nám dodala externí SW firma, tj. subdodavatel zakázky. Následně po verifikaci podpisu z externího serveru putuje dotaz do externího bankovního systému, od něj dostaneme odpověď. Pokud byla ve zprávě od klienta uvedena návratová adresa jako mail, odpověď klientovi putuje na tento uvedený mail a to tak, že se použije standardní prostředek pro odesílání mailů (například EXCHANGE SERVER apod.). Je třeba navrhnout případ užití i s prvky typu Actor a určit interfacy. Výsledný obrázek může vypadat například takto: Klient s m obilem Aute ntiza č ní s e rv e r Zpra c ov á ní zprá v y od k lie nta s m obile m M a il s e rv e r BIS Obrázek 4 Případ se čtyřmi prvky Actor a každý má nárok na život Všimněme si, že vyhledání interfaců (zde máme celkem 4) ihned implikuje na začátku projektu otázku co je reprezentuje a není to jen problém technologický, ale i obchodní! Otázky ohledně interfaců: 1. Actor Klient s mobilem: Od klienta dostaneme zprávu, ptáme se jakým způsobem a jakou technologií? Bude to pevná linka, šifrovaná datová linka přes internet apod.? Není to problém pouze technologický, ale i obchodní (např. nutná smlouva s providerem u datové linky a její zdlouhavé řešení apod.). strana 5
strana 6 2. Actor Autentizační server: Subdodavatel musí dodat specifikaci interfacu a způsob komunikace s autentizačním serverem, který nám dodal jako externí systém. 3. Actor BIS: Musí se vyřešit připojení na BIS, což se při vývoji může jevit jako problém: V době vývoje sama banka jako klient ještě nemusí být známa (nabízíme jako produkt na trh) a navíc nás stejně informatici k jejich systému tak jak tak nepustí. Zde se problém připojení na BIS může vyřešit jednoduše pomocí vzoru ADAPTER. Každý, kdo v našem systému komunikuje s bankovním systémem, musí přistupovat k definovanému interfacu resp. skupině interfaců nabízenému dovnitř našeho systému a nijak jinak. Pro vývojářskou verzi se může vyvinout ADAPTER s názvem BIS - Simulant, který pouze simuluje přístup k bance. Po příchodu do banky je třeba implementaci daného adaptéru vyměnit při zachování interfacu (tj. vyměnit implementaci metod daného interfacu). Sama implementace adaptéru v bance je již problém spolupráce s informatiky dané banky. 4. Actor Mail server: Interface na Mail server je dán dokumentací použitého prostředku pro odesílání mailů. Tento příklad je ilustrativní nejenom v tom, že vidíme zřetelně 4 prvky Actor a přitom každý má nárok na život, ale i v tom, jaké poslání mají prvky Actor z hlediska návrhu a jak jsou pro návrh IS tyto prvky důležité! Hned v raných fázích analýzy vedou k nutnosti podrobit analýze interfacy systému a poté je navrhnout i technologicky. Díky analýze prvků Actor se tak vyhneme fatální a velmi nepříjemné situaci, kdy se uprostřed programování zjišťuje, jak by se vlastně měla daná funkcionalita navrhnout jinak a celá přeprogramovat, protože daný nezanalyzovaný Actor ji není schopen předpokládaným způsobem podporovat. To jsou potom překopávky v projektu opravdu hodně drsné. Konec článku Využijte některou z našich dočasných slev, zúčastněte se našich kurzů! 3 - denní kurz Návrh IS pomocí UML se koná v Praze ve dnech 19.5.-21.5.09 Poslední termín 5- denního Pobytového kurzu, další až na podzim, nepropásněte jarní slevy! Tyto kurzy mají stále ještě volná místa! strana 6