VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ

Transkript

1 VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ Část 2 Tento článek je pokračováním předešlého článku RNDr. Ilja Kraval, duben ÚVOD V předešlém článku 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é kapitole 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. Kromě přesně technického pojetí prvku typu Actor jako budoucího interfacu systému existuje i náhled na prvek Actor víceméně laický a takříkajíc obchodní. I ten je však pro samotný projekt důležitý. Tomu se začneme v této části článku věnovat.

2 strana 2 DŮVODY PRO POUŽITÍ PRVKŮ ACTOR LAICKÉ, OBCHODNÍ NEBOLI NEVÝVOJÁŘSKÉ V praxi jsem se setkal se dvěma laickými důvody (tj. nikoliv s důvodem hledáme interfacy systému ), proč se zákazník, obchodník, apod. zajímá o prvky typu Actor: 1. Prvky typu Actor výrazně zkrášlují a oživují Use Case Diagramy. Tento důvod sice může znít trochu komicky, ale je velmi důležitý zejména tehdy, pokud se dokumenty tvořené v UML jazyce stávají součástí obchodní nabídky resp. jsou zařazeny jako součást dokumentů putujících do výběrového řízení. Pokud popíšeme tutéž situaci dvěma diagramy případy užití a jeden z nich bude bez panáčků, tak ten s panáčky vyhrává, tak to prostě je. 2. Mapování rolí v podniku na frekvence použití jednotlivých případů užití. Může se stát, že zákazník chce graficky znázornit, která role v podniku bude používat ten který případ užití a k tomu ještě také zadat číselně odhadovanou frekvenci použití daného případu užití tou kterou rolí v podniku. Například tuto prohlížečku budou používat ředitel, vedoucí účetní, atd., asi tak 10 krát denně apod. Je třeba podotknout, že oba důvody jsou z obchodního hlediska určitě důležité, ale z pohledu vývojáře navrhující systém jsou pouze sekundární. Primární je vyhledání interfaců a jejich následné technologické řešení. Bohužel však s laickým náhledem na prvky Actor a s uvedenými dvěma důvody bývají spojeny dvě vážné chyb. Musíme se s nimi seznámit, abychom se jich vyvarovali, teprve poté přistoupíme k návodu, jak používat prvky Actor v dokumentech obchodní povahy. PROBLÉM ZBYTEČNÉ HÁDKY NAD KONTEXTEM PRVKU ACTOR Již v článku 12 je uveden první příklad chybného přístupu k prvku Actor, nyní jej blíže rozebereme a poté uvedeme i další příklady. strana 2

3 strana 3 PŘÍKLAD 1 Nalezli jsme v bankovním systému USE CASE s názvem Založení běžného účtu klientovi na přepážce banky. Jeden analytik může namalovat tuto situaci takto: Obrázek 1 Jako Actor zvolen název obsluha A druhý by oponoval takto: Obrázek 2 Jako název Actora zvolen Klient Kdo má pravdu? Ptáme se, kdo je vlastně prvkem typu Actor? Klient nebo Obsluha? Jinak řečeno, který z těchto dvou obrázků je správně? Tento na první pohled banální rozdíl může vést v týmu k prudkým a vášnivým diskusím, jak se stalo v praxi i zde. Tým se rozdělil na dva nesmiřitelné tábory. Jedni argumentovali rozumně: Přece nebudete tvrdit, že klient přeskočí přepážku, odstrčí obsluhu a naťuká si to sám? Já tam vidím jako prvek Actor Obsluhu! Druzí naopak tvrdili také vcelku logicky: Prvkem Actor je Klient a Obsluha je jenom prostředník. Obsluha přece nic do systému nepřináší, ona pouze zprostředkuje přenos informací do systému. To už tam můžete namalovat taky klávesnici a monitor, protože ona ta Obsluha jinou funkci nemá. A navíc, přece nebudete tvrdit, že tento případ užití je tu pro Obsluhu. Případ užití je pro Klienta, jak je již patrné v názvu případu užití. Jemu, tedy Klientovi přináší užitek. strana 3

4 strana 4 Vznikla i třetí skupina, ta zavržena hned na počátku. Tato skupina navrhovala následující řešení: Umístěme prvek Actor Klient, k němu ještě Obsluha a znázorněme, že Klient to předá Oblsuze a ta to dá do systému takto : Založení běžného účtu klientov i na přepážce banky Klient Obsluha Obrázek 3 Špatný návrh otevírající Pandořinu skřínku Proti tomuto řešení jsme vyslovili tento argument: Tak to jste otevřeli Pandořinu skříňku a můžete tam namalovat už cokoliv, třebas, že Manželka řekla Klientovi, aby šel do banky, a taky tam můžete namalovat Přepážku v bance, Monitor, Klávesnici, Síťovou kartu atd... Největší chybou v této rozepři bylo to, že se o tomto problému jak nazvat paňácu diskutovalo asi týden a práce stála. Přitom scénáře byly napsány a vědělo se, co se má naprogramovat! Takže jak se mělo správně postupovat? Položme si nejprve otázku: Je znám interface? Je známo, co jej reprezentuje? Ano, z pohledu vývojáře jsme identifikovali interface ven typu obrazovka pro člověka. Zbývá pouze vyřešit, jaký typ GUI to bude (ASP, JSP, klasická okna apod.) Interface jsme nalezli, následně se specifikoval i technologicky. Nyní je již interface znám a prvek Actor se stává jen okrasným prvkem diagramu. Dáme tam takový název, který se nejvíce líbí zákazníkovi, tipl bych si, že pro dokument jdoucí do banky bude asi nejlepší Obsluha v bance. strana 4

5 strana 5 PŘÍKLAD 2 V jedné internetové diskusi se analytik ptal takto: Navrhuji evidenční systém pro půjčovnu aut. Nalezl jsem případ užití Zaevidování zápůjčky auta. Mám problém, jak nazvat prvek Actor k tomuto případu užití. Rád bych tam dal název Zákazník, ale to nemohu, protože když se nová zápůjčka eviduje, tak v té době je Zákazník už v autě a jede pryč. Mám tam dát název Pracovník půjčovny? Odpověď: Máte zde specifikován interface systému? Ano. Technolog ho vyřešil technologicky v dané technologii? Ano. Dejte takový název, který se nejvíc líbí, tedy je nejméně kolizní. Protože vše ostatní je z hlediska vývoje již vyřešeno a to jak analyticky, tak následně technologicky, název prvku Actor je již vedlejší. PŘÍKLAD 3 Jedna bratislavská firma navrhuje evidenční systém pro evidenci plavby lodí po moři. Při vyhledávání případů užití nalezli tento konečný proces podniku rozkladu (tzv. Action neboli Task, tj. dále nerozkládaný proces podniku): Business Process Vyplutí lodi z přístavu : Loď vyplouvá z přístavu. Kapitán přistupuje k zařízení a odesílá zprávu o vyplutí lodi, my tuto zprávu přijímáme přes satelit, viz případ užití Příjem zprávy z lodi. Všimněme si, že z hlediska procesů podniku je vše jasné, stejně tak z hlediska interfacu systému a je třeba pouze přesně specifikovat technologickou komunikaci přes satelit. Koho ale zvolit jako prvek Actor v modelu případů užití? Kapitána, zařízení, satelit nebo snad něco jiného? strana 5

6 strana 6 Nejlepší název, tedy nejschůdnější a nejméně kolizní, je myslím Loď, ale co je hlavní, hádat se o tom nebudeme, protože je to zbytečné. PRAKTICKÉ DOPORUČENÍ PRO HLEDÁNÍ NÁZVŮ PRVKŮ ACTOR Uzavřeme tyto příklady doporučením: Pokud je identifikována povaha rozhraní, tak diskuse nad názvem prvku Actor je z hlediska samotného návrhu neplodná a zbytečná. Interface jsme nalezli, následně jej specifikujeme i technologicky. Poté pro název prvku Actor platí pravidlo: Je to okrasný prvek diagramu pro potěchu oka zákazníka. Nejlépe vyhovuje ten název, který se líbí zákazníkovi a je nejméně kolizní. DRUHÝ PROBLÉM S PRVKY TYPU ACTOR SNAHA O ROZMNOŽENÍ ACTORŮ PŘÍKLAD 4 Při prvním setkání s tímto problémem množení aktorů jsem zažil tak trochu až komickou situaci. Stalo se to v jedné SW firmě, kde jsem prováděl školení a konzultaci. Tato firma dodávala ekonomické systémy a chtěla přecházet ze zastaralejší technologie na technologii modernější. Při tomto přechodu současně pracovníci chtěli vytvořit také USE CASE MODEL. V té době byla populární actorová škola a tak tím chtěli začít. Když jsem po skončení školení odjížděl z firmy, tak se ptali, za jak dlouho by mohli najít prvky typu Actor. Znal jsem rozsah původního systému (střední systém, cca asi 500 relačních tabulek). Bylo mi řečeno, že na vyhledávání prvků Actor budou pracovat tři analytici. Systém znali dobře, sami jej programovali. Odhadl jsem v tom případě dobu pro nalezení prvků typu Actor na několik dnů, asi tak dva až tři, maximálně na jeden pracovní týden. Ještě na odchodu jsem dodal: Pokud se vyskytne problém, pošlete mail. Asi za tři až čtyři týdny jsem dostal tak trochu zoufalý mail: Pane doktore, máme problém. Stále ještě hledáme Actory... (tak to je opravdu problém, říkám si v duchu, to už měli mít za sebou)...a oni nám furt přibývají. Moje odpověď zněla: Není možné, počet aktorů je statická veličin a nemohou přibývat. strana 6

7 strana 7 Jejich další mail mne překvapil: Nemáte pravdu, za dobu naší komunikace další dva přibyli! Požádal jsem je, aby mi poslali mailem ukázku jejich dokumentů. Poslali mi část modelu a jejich diagramy mne šokovaly. Uprostřed byl umístěn jednoduchý případ užití a ten byl obklopen skupinou prvků typů Actor takto nějak: Manažer senior Manžer junior Účetní Prohlížení statistik Manažer Účetní junior Účetní senior Obrázek 4 Typický problém množení prvků Actor Moc jsem tomu nerozuměl, a protože jsem jel do jejich firmy vyřídit i jiné záležitosti, tak jsem si tento zajímavý bod dal jako jeden z prvních pro řešení v konzultaci. To, co namalovali, má svou logiku, ale předem upozorňuji, že obsahuje dvě hrubě chybné úvahy. Celý jejich problém spočíval v tom, že v systému řešili agendu přístupových práv. V této agendě se vyskytují tzv. Role a již tušíme, jaké Role se tam vyskytují (viz předešlý obrázek): Účetní, Účetní junior... atd. Na druhé straně v systému existují tzv. Akce, jako je Založení faktury, Odsouhlasení faktury, atd., což souhlasí s případy užití, a jedna z nich je (opět viz předešlý obrázek Prohlížení statistik.) Předešlý obrázek tedy podle nich ukazuje, která Role může spustit danou akci tedy případ užití Prohlížení statistik. Tato úvaha je samozřejmě mylná a špatná. Odhalení její chyby není až tak složité: Stačí namalovat prvek Boundary neboli hranici, poté spočítat interfacy jako průsečíky Use a Boundary a zeptat se: Kolik lidí sedí u systému při použití sytému zrovna tímto případem strana 7

8 strana 8 užití? Odpověď zní: Jeden... Ale jej jich je šest, což znamená, že všech šest se tohoto případu užití účastní! Podstata omylu této úvahy spočívá ve dvou nejčastějších chybách analytika: První chybou je záměna vnitřku a vnějšku systému a druhá chyba spočívá v nazývání instancí jejím obsahem. K první chyba: Nejprve se zeptejme, co je to Role? O jaký typ prvku se z pohledu UML jedná? Řečeno jazykem UML, co je to za metaclass, tj. jaký je to typ prvku v UML? Role je součástí řešení v agendě přístupových práv a je to analytická třída. Je to budoucí program, vzniknou z ní mapováním do technologie prvky jako tabulka, třída v OOP, funkce, proměnné atd. Stejně tak Akce je také třídou. Je třeba si okódovat a pojmenovat spustitelné akce, tj. instance akcí, a poté přiřadit právo spuštění dané Akce k dané Roli. Příklad řešení takové agendy může vypadat například takto (návrh části systému v modelu tříd): User Role Akce * * * * Pov olené Role Usera Pov olené Akce dané Role Obrázek 5 Jednoduchá agenda přístupových práv Scénář přihlášení i s výběrem role můžeme napsat takto (pozn.: jsou vynechány všechny Exception Flow), sledujte přitom model tříd: Někdo zadá username a password. V seznamu Userů se najde daný User se zadaným username a ověří se password (hešováno MD5). Zobrazí se seznam Povolených rolí pro daného Usera, obsluha vybere jednu Roli (může žít v daném okamžiku v jedné roli). Prvky User i Role se drží po dobu běhu aplikace. strana 8

9 strana 9 Všimněme si, že věta někdo zadá username a password nespecifikuje, o koho se jedná, je to synonymum pro anonym. Po přihlášení běží aplikace a pak se někde jinde vyhodnocuje právo k dané akci v dané situaci. Vyhodnotí se nejprve, zda existuje instance Povolené akce pro danou dvojkombinaci Role + Akce (pozn.: Role je známa z přihlášení, Akce vyplývá z kontextu bodu programu, například zrovna pracuji nad tímto menu-itemem spouštějícím tuto akci). Poté se buď vysvítí nebo zešedí nabídka pro spuštění dané akce. Pro náš příklad je důležité, že uvedené Role, o kterých je zde řeč, nejsou prvky typu Actor, ale instance ze třídy Role. Stejně tak Akce zde nejsou případy užití, ale instance ze tříd Akce. A tato záměna je kritická. První chyba je tedy záměna vnitřku a vnějšku: Jednotlivé evidované Role jsou instance ze třídy Role a nikoliv vnější prvky typu Actor! K druhé chybě: Spočívá v tom, že bychom správně neměli nazývat instance obsahem, ale pokud možno neutrálně, například odvozením názvů instancí z názvu třídy (pokud třídu známe). Příklad evidence v instancích by mohl vypadat takto: Role1 - název = 'Ředitel' Akce1 - kod = název = 'Prohlížení sta... Pov olené Akce pro Roli Obrázek 6 Část evidence přístupových práv Správně zavedeme instanci například s názvem Role1, která má atribut Název s hodnotou = Ředitel a nikoliv tak, že instanci evidované role nazveme přímo Ředitel. Tato záměna je matoucí a může vést k dalším hrubým chybám. Například ve školeních tuto chybu nazýváme chybou ulice Milady Horákové, protože v jednom příkladu zazní tato otázka: V evidenci se nachází ulice Milady Horákové v Praze i v Brně. Je možné potom vztah mezi evidovaným strana 9

10 strana 10 městem a evidovanou ulicí považovat za kompozici ku N, když se tato ulice vyskytuje jak v Praze, tak v Brně? Diagram na Obrázek 6 Část evidence přístupových práv ukazuje, jak vlastně funguje laicky řečeno povolení prohlížení statistik pro ředitele. Jak bylo řečeno, existuje na jedné straně evidovaná instance Role1, která má název s hodnotou = Ředitel, na straně druhé existuje Akce1 která má kód = 121 a název s hodnotou = Prohlížení statistik. K nim existuje instance práva z asociační třídy, která je provazuje. Pokud tato instance existuje (zde ano), tak anonym, který se přihlásil a vybral roli Role1 podle předešlého scénáře, má právo k této akci (např. konkrétně v datech jako SQL příkaz select count nad touto tabulkou s podmínkou, že cizí klíče id_role a kod_akce jsou rovné vstupním parametrům). V daném bodě programu se pak vyhodnotí právo například pomocí funkcionality: Pravo(long IdRole, integer kodakce): boolean resp. objektově Pravo(CRole Role, CAkce Akce): boolean (pozn.: za voláním této funkcionality je schován zmíněný datový dotaz do tabulky práv) Uvedená chyba množení aktorů je vážná, protože vede ke špatnému určení v počtu rozhraní. Proto by neměla nastat a neměla by být ani tolerována. Naštěstí nalezení této chyby je snadné: Počet interfaců musí souhlasit s počtem prvků Actor. Po správném určení počtu prvků Actor (v našem případě redukce na jednoho) navrhujeme názvy prvků Actor podle doporučeného postupu v předešlé kapitole článku. PŘÍKLAD 5 V jedné klasické knihovně, která půjčuje knihy, byl nasazen evidenční systém. Představme si, že jsme zatím ve stádiu, kdy se hledají případy užití a prvky Actor. Byl nalezen případ užití Prohlížení titulů knihovny. Jedná 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). Nalezly se tyto prvky v okolí jako prvky typu Actor: Knihovník, Administrátor a Čtenář. Autor modelu namaloval následující obrázek: strana 10

11 strana 11 Obrázek 7 Opět příliš mnoho prvků Actor? Co myslíte, je to správně nebo ne? Navíc zazněla 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í? To už je námět pro další pokračování článku. V příštím článku zodpovíme také dotazy, které se objevily na našem Fóru objektových technologií. Konec 2. části, pokračování příště. Modelovat a navrhovat IS rychle a kvalitně se musí umět! Neváhejte, využijte některou z našich dočasných slev, zúčastněte se našich kurzů a naučte se to! 3 - denní kurz Návrh IS pomocí UML se koná v Praze ve dnech denní Pobytový kurz ve dnech má dočasné výrazné slevy Kurzy mají stále ještě volná místa! strana 11