Článek 61

VYHLEDÁVÁNÍ PRVKŮ ACTOR A
PROCESNÍ MODELOVÁNÍ
Část 1
RNDr. Ilja Kraval, duben 2009
http://www.objects.cz
ÚVOD
Shodou okolností jsem nedávno obdržel dva maily s dotazy a postřehy, které se týkaly
problematiky popsané v článku číslo 12 „Actor versus BPM“ . Vzhledem k velikosti obou
mailů stručně shrnu základní body obou dvou mailů:
1. Otázka vyhledávání případů užití pomocí prvků Actor a pomocí podnikových procesů
2. V čem spočívá důvod vyhledávání prvků typu Actor
3. Otázka rolí (funkcí) v podniku a jejich vztah k prvku Actor
Pokusím se v tomto článku odpovědět na tyto otázky.
PRVEK TYPU ACTOR
Nejprve upřesněme pojem Actor z pohledu UML:
Jedná se o prvek z okolí, který interaguje se systémem. Není to tedy libovolný objekt z okolí,
ale ten, který je spojen v interakci se systémem.
Implicitním obrázkem prvku Actor je „panáček s názvem“, například takto:
http://www.objects.cz
strana 2
Obsluha
Doporučuje se, aby se pro neživé okolní prvky (externí systémy) zavedl jiný obrázek než
panáček (například obrázek PC) mechanismem „zavést stereotype + výměna prezentačního
prvku“
Pozn.: Konkrétně pro výměnu obrázku pro stereotypy v EA viz zde - nejprve vytvořte
požadovaný obrázek v nějakém editoru obrázků a uložte jej ve formátu EMF nebo WMF a
poté přiřaďte tento obrázek k danému stereotypu. Například externí systém s názvem Server
kina by byl zobrazen jako PC takto (obrázek PC je získán z aplikace VISIO uložením do WMF a
následně převzat do EA):
Serv er kina
Dalším prvkem USE CASE DIAGRAMU je spojnice mezi prvkem typu Actor a prvkem typu Use
Case, nazývá se „Use“. Při použití prvku Actor se do jednoho diagramu umísťuje několik
prvků typu Use Case, se kterým daný prvek typu Actor komunikuje, například takto:
strana 2
http://www.objects.cz
strana 3
Obsluha
Obrázek 1 Actor a několik prvků Use Case
Doporučuje se použít i prvek Boundary, který vymezuje vnitřek a okolí systému takto:
Obsluha
Obrázek 2 Použití prvku Boundary
V některých firmách malují obrázek obráceně s prvkem Actor uprostřed takto:
strana 3
http://www.objects.cz
strana 4
Obsluha
Obrázek 3 Chybné rozložení diagramu
Tomuto způsobu se raději vyhněte, protože nezdůrazňuje opticky, co je venku a co uvnitř a
nepůsobí proto příliš technicky.
VÝHODA PROCESNÍ ŠKOLY: NEPOTŘEBUJE PRVKY TYPU ACTOR
Rád bych zde uvedl některé doporučené postupy týkající se BPM ve vztahu k případům užití.
Pokud se věnujeme procesnímu modelování pro vyhledání případů užití, tak vlastně tvoříme
zvláštní případ Activity diagramu. Je vhodné „vnitřky“ nalezených business procesů popsat
pomocí slovního scénáře. V těchto slovních scénářích se vyskytují „podstatná jména“ jako
objekty z okolí, které se nějak chovají, například takto:
„Klient přichází do pobočky banky a chce si založit účet na přepážce banky. Předává
požadavek obsluze na přepážce a ta jej zanese do systému, spustí se UC Založení běžného
účtu na přepážce.“
Jak bylo řečeno, ne každý objekt z okolí je prvkem typu Actor a také zde při tomto popisu
nespecifikujeme prvek typu Actor ve smyslu jako ten prvek, který stojí „proti systému“ a
interaguje s ním, ale prostě popisujeme prvky (objekty) z okolí a pak se „spustí případ užití“.
To je velká výhoda procesního modelování: Není třeba při vyhledání použít prvek Actor, tj.
hledat toho, kdo vlastně komunikuje s případem užití, stačí popsat proces a dát jej do vztahu
strana 4
http://www.objects.cz
strana 5
s odpovídajícím prvkem UC v tomto vztahu, viz následující obrázek (pozn.: na obrázku je pro
proces použita syntaxe BMPN):
Klient žádá založení BÚ na
přepážce
Založení běžného účtu na
přepážce
Obrázek 4 Proces vlevo spouští případ užití vpravo
Protože se soustřeďujeme na proces, tak nás nyní nezajímá, kdo je vlastně prvkem typu
Actor vůči případu užití.
Zatímco otázkou „aktorové“ školy vyhledávání případů užití je „kdo používá systém“,
otázkou procesní školy je „co se děje okolo systému, že je třeba použít systém“. V druhé
otázce vůbec nemusíte pojmenovat toho, kdo používá systém, tj. kdo je Actorem.
Procesní škola vyhledávání případů má oproti „actorové“ jednu velkou výhodu: Nemusíme
při vyhledávání pojmenovávat prvky typu Actor, tj. kdo komunikuje se systémem, stačí
najít a pojmenovat proces, který spouští daný případ užití. V popisu procesu popisujeme
chování objektů z okolí bez ohledu na to, zda jej považujeme za prvek Actor nebo nikoliv.
Teoreticky vzato bychom se tedy bez prvků Actor v procesní škole obešli, ale přesto tyto
prvky vyhledáváme. Existují dva základní okruhy důvodů pro vyhledávání prvků typu Actor:
1. Vyhledání prvků typu Actor pro samotný vývoj systému (hledisko vývojáře)
2. Vyhledávání prvků typu Actor pro obchodní účely (nikoliv hledisko vývojáře)
strana 5
http://www.objects.cz
strana 6
VYHLEDÁNÍ PRVKŮ TYPU ACTOR Z POHLEDU VÝVOJÁŘE
Jedná se o primární důvod vyhledání prvků typu Actor a souvisí s problematikou rozhraní
systému:
Prvky typu Actor spolu se spojnicí Use vůči prvku Use Case odhalují rozhraní systému a
vzniká tak již v brzké fázi analýzy dotaz na jejich následné technologické řešení.
Pokud se podíváme na USE CASE DIAGRAM i s prvky typu Actor spolu se spojnicemi Use a s
prvkem Boundary, tak nás z hlediska návrhu IS zajímají právě průsečíky mezi spojnicemi Use
a prvkem Boundary. Tyto průsečíky reprezentují rozhraní neboli interface systému, viz
obrázek:
Interface systému
Interface systému
Export přev odních příkazů do
Clearingov ého Centra
Clearingov é
Centrum
Obsluha v bance
Obrázek 5 Interakce prvku typu Actor s případem užití reprezentuje interface systému
strana 6
http://www.objects.cz
strana 7
Jak již bylo řečeno pro další návrh systému tak vzniká velmi příznivá situace, kdy již ve velmi
raných fázích analýzy vznikají otázky technologické povahy o komunikaci systému vůči okolí a
co tuto komunikaci bude následně konkrétně v technologii reprezentovat. Například na
předešlém obrázku jsou patrné dva interfacy a je otázkou, co je reprezentuje technologicky.
Z jedné strany je vidět dotaz na povahu „obrazovek“ (bude to ASP, JSP, lokální aplikace
s okny apod.?), na straně druhé je otázkou, jak se odešlou převodní příkazy do Clearingového
centra (dávka přes internet, datová linka?).
Odhalení interfaců je důležité i pro analytika a to zejména pokud se řeší komunikace
s externími systémy: Systém nemůže od okolního prvku požadovat něco, co okolní prvek
neumí a analytik musí tedy při návrhu funkcionalit samotného systému počítat pouze s tím,
co daný prvek z okolí umí. Musí proto provést analýzu možností komunikace externího
systému s naším systémem.
Existují však i další, vedlejší důvody pro vyhledávání prvků typu Actor, než je specifikace
interfaců, a o těch bude pojednáno v další části článku.
ZÁVĚRY 1 ČÁSTI ČLÁNKU
1. Procesní škola vyhledávání případů užití nemusí specifikovat prvky typu Actor, což je
výhodou.
2. Prvky typu Actor ale musíme jako vývojáři i tak dohledat, protože reprezentují interfacy
systému a ty se musí při návrhu IS řešit.
Konec 1. části článku
3 - denní kurz Návrh IS pomocí UML se koná v Praze ve dnech 19.5.-21.5.09
5 denní Pobytový kurz ve dnech 11.5-15.5.09 má opět výrazné slevy
strana 7