Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie
Diplomant: Bc. Martin Miloš Vedoucí diplomové práce: prof. Ing. Václav Řepa, CSc. Oponent diplomové práce: Ing. Tomáš Šalamoun, MBA
VYUŢITÍ AGENTŮ PŘI MODELOVÁNÍ BUSINESS PROCESŮ
školní rok 2009/2010
Prohlášení
Prohlašuji, ţe jsem diplomovou práci zpracoval(a) samostatně a ţe jsem uvedl(a) všechny pouţité prameny a literaturu, ze kterých jsem čerpal(a).
V Praze dne 29.6.2010
………………………………. podpis
i
PODĚKOVÁNÍ Chtěl bych zde poděkovat svému vedoucímu diplomové práce prof. Ing. Václavovi Řepovi, CSc. za ochotu, se kterou mi poskytoval odbornou pomoc, cenné rady a připomínky při zpracování této práce. Rovněţ bych chtěl poděkovat všem ostatním za pomoc a podporu při tvorbě této práce.
ii
ABSTRAKT Tato práce se zabývá vyuţitím agentů v modelování business procesů. Cílem je identifikovat jednotlivá vyuţití v problémové oblasti a zhodnotit jejich potenciál. Vyuţití je analyzováno na základě cílů modelování procesů. Detailněji je popsáno vyuţití agentů při samotném modelování, tvorbě spustitelných procesů a dynamickém plánování. Dalším cílem je poskytnout aktuální přehled výzkumu a literatury v dané oblasti. K cíli práce postupuje analýzou dostupných zdrojů a aplikací získaných poznatků v případové studii. Práce se nezabývá implementací multiagentních systémů (MAS). Úvodní kapitoly se stručně zabývají procesy a jejich modelováním, charakteristikou agentů a modelování MAS. Pro modelování procesů byla zvolena notace BPMN v plánované verzi 2.0. Další části se věnují samotnému vyuţití agentů. Poslední součástí práce je případová studie diskutující moţnosti agentů na společnosti provozující veřejné aukce aut. Je zde prezentována a doplněna transformace BPMN do agentového modelu (interakčních diagramů) jako mezičlánek spojující procesní modelování a pouţití multiagentních systémů. Přínosem je aktuální přehled problémové oblasti, ohodnocení vyuţití agentů v modelování business procesů podle účelu modelování a doplnění transformace BPMN do interakčních diagramů. Další rozvoj je doporučen v oblastech kombinace business rules a agentů a hybridní simulace.
KLÍČOVÁ SLOVA Modelování procesů, agent, BPMN, business proces, multiagentní systém
iii
ABSTRACT This diploma thesis deals with the usage of agents in business process modelling. The aim is to identify possible uses in the problem area and to evaluate their potential. Intended usage is analysed on the basis of the objectives of process modelling. Described in detail, it focuses on potential application of agents in a process modelling itself, in deploying executable and flexible processes, process improvements and finally in dynamic planning. A further objective is to provide an overview of current research and literature in problem area. To fulfil the goal available literature is analysed and basis approaches are demonstrated in case study. Paper does not address the implementation of multi-agent systems (MAS). Following introduction reader is guided though basic elements of the processes and their modelling, concept of agents and modelling of MAS. As a process modelling notation BPMN in planned 2.0 release was selected. Next section is devoted to the usage of agents. The last part of the work is a case study discussing the possibilities of agents application in company operating public car auctions. In addition the process model (BPMN) transformation to agent model is presented and further developed as a interconnection between process modelling and agent-based systems. Combination of agent approach with business rules and hybrid simulation are proposed as the most promising usages.
KEY WORDS Process modelling, agent, BPMN, business process, agent-based
iv
OBSAH 1
Úvod ................................................................................................................................... 1 1.1
2
Širší kontext ................................................................................................................. 2
Podnikové procesy.............................................................................................................. 2 2.1
Proces ........................................................................................................................... 3
2.2
BPMN .......................................................................................................................... 5
2.2.1 3
4
Objekty BPMN ..................................................................................................... 7
Agentový přístup .............................................................................................................. 12 3.1
Definice ...................................................................................................................... 13
3.2
Druhy agentů .............................................................................................................. 15
3.2.1
reaktivní agent .................................................................................................... 16
3.2.2
Deliberativní agent ............................................................................................. 16
3.2.3
Hybridní a sociální agent .................................................................................... 18
3.3
Vztahy mezi agenty ................................................................................................... 19
3.4
Modelování MAS ...................................................................................................... 21
3.4.1
AUML ................................................................................................................ 21
3.4.2
UML ................................................................................................................... 26
Vyuţití agentů .................................................................................................................. 28 4.1
Vyuţití agentů v oblasti business procesů ................................................................. 32
4.1.1
Vyuţití agentů při modelování ........................................................................... 33
4.1.2
ABPM(S) ............................................................................................................ 35
4.1.3
Vyuţití agentů pro dynamické plánování ........................................................... 43
4.1.4
Multiagentní simulace ........................................................................................ 47
4.1.5
Transformace BPMN do agentového modelu .................................................... 51
v
5
Případová studie ............................................................................................................... 52 5.1
Moţnosti vyuţití agentů v modelované společnosti .................................................. 58
5.2
Transformace do agentového modelu ........................................................................ 58
6
Závěr ................................................................................................................................. 63
7
Bibliografie ....................................................................................................................... 66
8
Terminologický slovník .................................................................................................... 70
9
Seznam obrázků, tabulek a diagramů ............................................................................... 71
10 Příloha 1 – diagramy v textové notaci AUML ................................................................. 73 11 Příloha 2 – kontrolní list ................................................................................................... 74
vi
1 ÚVOD Tato práce se věnuje vyuţití agentů při modelování business procesů a v souvisejících oblastech. Podnikové procesy jsou intenzivně diskutovanou oblastí posledních let a v situaci, kdy se řízení procesů a jejich modelování věnuje kaţdá větší společnost, se jedná o velmi aktuální téma. Práce propojuje agenty, jejichţ vyuţití je předmětem intenzivního výzkumu a pokusů o praktické implementace, s modelováním business procesů. Cílem práce je identifikovat v jakých oblastech modelování procesů má vyuţití agentů potenciál. Cílem je nalézt vyuţití agentů, které by vedlo k větší flexibilitě business procesů. Zkoumanými oblastmi je modelování procesů za účelem dokumentace, analýzy a optimalizace, tvorby spustitelných procesů a moţnost vyuţití agentů při validaci procesů. Pro danou oblast je velmi málo dostupných pramenů v českém jazyce, proto je dalším cílem je poskytnout aktuální přehled výzkumu a literatury v problémové oblasti. Práce se také snaţí o odpověď na otázku, jak překlenout mezeru mezi multiagentními systémy, ostatními částmi IT a uţivateli. Jako prvek sblíţení je navrţeno vyuţití business rules a transformace procesního modelu do agentového modelu. Vedlejším cílem práce je představení chystaného standardu BPMN 2.0. Úvodní kapitolu následuje přestavení procesního modelování, včetně detailnějšího popisu prvků BPMN. Následující kapitola se věnuje konceptům agentů. Tato kapitola obsahuje i základy modelování multiagentních systémů pomocí Agent UML (AUML) a UML. V kapitole věnující se vyuţití agentů jsou nejdříve nastíněny obecné moţnosti vyuţití agentů. Kapitola poté pokračuje analýzou vyuţití v modelování a ostatních oblastech business procesů. Konkrétně se zabývá vyuţitím agentů v Business process managementu (BPM), dynamickém plánování a multiagentní simulací. Oblast BPM je doplněna diskuzí společného vyuţití business rules a agentů. Cílů bude dosaţeno analýzou dostupných zdrojů a vlastními úvahami autora. Na závěr budou poznatky demonstrovány na případové studii. Práce se nezabývá implementací multiagentních systémů. Zaměřením je spíše určená analytikům a lidem s koncepty agentů ne příliš seznámenými. U čtenáře se předpokládá znalost UML.
1
1.1 Širší kontext Významným trendem v oblasti informačních systémů je dnes stále sílicí nástup sluţeb. Sluţby jsou nezávislé entity, objekty v systému, které poskytují svojí funkcionalitu pomocí jasně popsaného rozhraní. Vnitřní uspořádání sluţby není viditelné, pro uţivatele či jiné volající sluţby fungují na principu černé skřínky. Vzájemná interakce sluţeb je pevně daná vývojářem a sluţby se navzájem volají příkazy. Na druhou stranu agenty také poskytují zapouzdřenou funkcionalitu, ale navíc mají vlastní stavy a cíle. Mohou vzájemně komunikovat a vytvářet nová seskupení i na základě vlastní vůle po splnění cíle. Volání mezi agenty probíhá pomocí ţádostí a ne příkazů, s provedením musí souhlasit i vykonávající agent. Z výše uvedeného vyplývá, ţe zavedení agentů přináší do informačních systémů zcela novou flexibilitu, která je s pomocí běţných objektů nedosaţitelná. Dnešní systémy absencí flexibility často výrazně trpí. Při designu je zvaţována ideální cesta a maximálně jeden či dva výjimečné stavy. Na ostatní situace není systém připraven. Zde by mohly systémy postavené na agentech být velmi prospěšné. Při vzniku nové nenamodelované situace dojde k její analýze a agenty sami automaticky vytvoří nový workflow procesu. Vyuţití agentů je široké. Naleznou uplatnění v analýze, modelování i samotné realizaci, ale i v simulaci systému. Modelování a simulace s vyuţitím agentů byly jiţ vyuţity v několika velkých společnostech a přinesly významné úspory (například: Procter & Gamble, Ford motors company), především díky simulacím s vyuţitím agentů a následném odstranění slabých míst. (Anthes, 2003 ) Systémy postavené na agentech naleznou vyuţití především v dynamických systémech, které se velmi často mění. Na druhou stranu agentová technologie má stále ještě mnoho problémů. Neexistuje jednotný přístup k implementaci. I přes existenci jednotících snah, jako je například Agent UML, se stále nepodařilo sjednotit metodický základ. Problémem jsou vzájemné komunikační protokoly a na ně navazující schopnost vzájemného vyjednávání mezi agenty. Dalším problémem je i malé povědomí o agentech a jejich moţnostech mezi business uţivateli a lidmi zodpovědnými za investice do IT i absence podpory ze strany velkých dodavatelů software.
2 PODNIKOVÉ PROCESY Cílem této kapitoly je objasnit, co je proces a jeho vyuţití v podnikání. Úvod kapitoly se stručně věnuje definici procesu, poté je pozornost věnována BPMN (Business process model and notation) notaci. V další části kapitoly je věnována pozornost nové verzi notace BPMN 2
2.0. Představení novinek vychází z knihy B. Silvera (Silver, 2009), který je členem přípravného výboru OMG tvořícího BPMN 2.0 specifikaci. Různé důvody modelování procesů vedou k odlišným poţadavkům na výsledný model. Procesy je moţné modelovat s následujícími cíli: Procesní model slouţící k dokumentaci fungování organizace, který je vyuţíván pro interní účely, ale i potřeby externího auditu. Procesní modelování slouţící k analýze procesů a jejich optimalizaci. Tato oblast se zaměřuje na identifikaci podnikových procesů, analýzu současných procesů a na návrh změn procesů. Tyto změny mohou být postupného charakteru nebo v podobě reingeneeringu, kdy dochází k podstatným změnám fungování procesu. Procesní modelování za účelem tvorby spustitelných procesů v softwaru na podporu řízení. Validací procesu se rozumí ověření schopnosti procesu reprezentovat reálnou činnost modelovanou procesem.
2.1 Proces Definic procesu je moţné nalézt celou řadu. Většinou se odlišují úhlem pohledu na proces a šíří jeho definice. Podle prof. Řepy je podnikový proces „souhrnem činností, transformujících souhrn vstupů do souhrnu výstupů (zboţí nebo sluţeb) pro jiné lidi nebo procesy, pouţívajíce k tomu lidi a nástroje.“(Řepa, 2007 str. 15). ISO 9000 definuje proces jako „soubor vzájemně souvisejících nebo vzájemně působících činností, který přeměňuje vstupy na výstupy.“
vstupy Dodavatel
výstupy Podnikový proces
Zákazník zpětná vazba
Obrázek 1 Základní schéma podnikového procesu (Řepa, 2007 str. 15)
Okolí procesu tvoří činnosti ovlivňující běh procesu: události, informace, zdroje a výstup procesu. Kaţdý proces má svého zákazníka. Můţe se jednat o externího, ale i o interního zákazníka procesu. Obrázek 1 zdůrazňuje vstupní zdroje a výstupy z procesu. Je zde zdůrazněna důleţitá role zpětné vazby, která je důleţitá pro hodnocení procesu a pro určení moţných zlepšení. Obrázek 2 zobrazuje okolí podnikového procesu a cíl procesu 3
ospravedlňující jeho existenci. Kaţdý proces musí mít jasně definovaný cíl. Pokud proces nemá jasný účel, proč je v podniku vykonáván, tak akorát podniku odčerpává zdroje, které by mohly být vyuţity v jiných procesech, se sporným výsledkem.
Obrázek 2 Obecné schéma podnikového procesu (Kvapilík, 2006)
Ve svém článku na BPM portále rozděluje prof. Řepa procesy na hlavní a vedlejší. „Hlavním procesem se rozumí proces, jímţ přímo vzniká hodnota pro firmu, a který firmu fakticky ţiví. Znamená to, ţe takový proces musí mít přímý kontakt se zákazníkem a ţe pokrývá celý tento kont(r)akt, tedy nejlépe od vzniku potřeby u zákazníka aţ po její uspokojení příslušnou sluţbou (výrobkem).“ (Řepa, 2008). Hlavní procesy vyjadřují podstatu podniku a jeho konkurenční výhodu oproti ostatním podnikům. Takových procesů se ve firmě vyskytuje jen několik. Všechny ostatní činnosti ve firmě patří do podpůrných procesů. (Řepa, 2008). I tyto procesy mají velký význam pro chod společnosti. Jsou určené interním zákazníkům, externím regulátorům a občas mohou být zákazníkem i vlastníci. Avšak tyto procesy nepřináší firmě zisk, spíše tvoří základnu a strukturu pro existenci hlavních procesů. Na rozdíl od hlavních procesů, které jsou jen velmi obtíţně outsourcovatelné, tak je moţné podpůrné procesy moţné outsourcovat. Outsourcingem hlavních procesů by podnik přišel o svoji podstatu podnikání, poskytl by jeho konkurenční výhodu ostatním společnostem. Naopak standardizace a outsourcing podpůrných procesů umoţňuje podnikům se soustředit na své podnikání. Za kaţdý proces by měla být odpovědná konkrétní osoba (role) v podniku. Zodpovědnost za proces lze rozdělit mezi dvě osoby, mezi vlastníka procesu a sponzora. Sponzor procesu má na starost strategické řízení procesu, stanovuje cíle procesu, jeho vazby na ostatní procesy, budoucí vývoj procesu a další faktory z oblasti strategie. Vlastník je osoba zodpovědná za běh
4
procesu a za dosaţené výstupy. Jeho role odpovídá taktickému řízení manaţerských teorií. Vlastník je zodpovídá za průběh aktivit, koordinaci procesu a další oblasti taktického řízení.
Obrázek 3 Business process metamodel (Řepa)
Pro účely modelování procesů je nutné pochopit, z čeho se model podnikového procesu skládá. Obrázek 3 zobrazuje hierarchicky prvky modelu business procesu. Všechny prvky jsou odvozeny od business process model elementu, který se dělí na koncept (vnitřní prvky procesu) a externí aspekty. Koncept se dále dělí na stimuly, stavy a aktivity. Prvky procesního diagramu se liší dle pouţité notace, z tohoto důvodu budou detailně popsány součásti BPMN modelu v následující kapitole.
2.2 BPMN Business process model and notation (BPMN)1 je standardem pro modelování podnikových procesů, vytvořený původně konsorciem BPMI. Dnes se o rozvoj stará organizace Object management group (OMG). BPMN se v posledních letech stala standardem v oblasti modelování podnikových procesů. BPMN je určená pouze k modelování podnikových procesů. Neklade si za cíl modelovat celý podnik, business model. Business model zachycuje 1
S příchodem specifikace BPMN 2.0 dojde ke změně názvu z Business proces modelling notation na Business process model and notation.
5
cíle podniku, organizační strukturu, procesy a další diagramy. Toto úzké zaměření BPMN bývá označováno jako nevýhoda, ale zároveň tvoří jednu z příčin její úspěšnosti, tím ţe poskytuje plnohodnotnou notaci pro modelování procesů bez zatíţení těţkou metodikou. Hlavní cíl BPMI, vytvořit jazyk pro tvorbu spustitelných procesů, se nepodařilo zatím naplnit. Přesto, moţná i právě proto, se BPMN velmi rozšířila. Podle B. Silvera se BPMN díky exaktní definici jednotlivých částí modelů stala grafickým standardem pro jednotné vyjádření grafického modelu v BPM nástrojích. Na BPMN poté navazují proprietární metody a jazyky pro vytvoření spustitelného procesu.(Silver, 2009) BPMN standard poskytuje exaktní definice jednotlivých částí, ale vůbec se nezabývá metodikou modelování procesu. Specifikaci návrhu BPMN 2.0 (OMG, 2009) tvoří přibliţně 500 stránkový dokument, kde jsou jednotlivé části sice přesně definovány, ale jak mají být pouţívány, specifikace jiţ neříká. To zůstává na zváţení analytika či autorech knih o BPMN. Silver přirovnává ve své kníţce snahu naučit se BPMN ze specifikace snaze naučit se psát příběhy ze slovníku. Toto přirovnání pěkně vystihuje postavení specifikace, která je nezbytným základem, ale rozhodně ne postačujícím základem. V procesu schvalování OMG se nyní nachází BPMN 2.0. Ke schválení by mělo dojít dle beta verze specifikace v průběhu června 2010. Nová verze s sebou přináší několik novinek: (Silver, 23) BPMN 2.0 přináší standardizované XML schéma. Všechny vytvořené modely by tak automaticky měly být zachyceny v XML. To přináší velký potenciál pro přenášení modelů, ale i pro transformaci modelů do jiných notací nebo aplikací, kde BPMN slouţí jako úvodní model. Obrázek 4 je příkladem XML schéma aktivity. Nepřerušující události umoţňující modelování událostí, které nepřeruší běh procesu, ale vytvoří další větev procesu. Například pokud klient změní během zpracování objednávky kontaktní adresu ještě před odesláním zboţí, tak nechceme začít objednávku zpracovávat znovu, ale jen upravit adresu. Zde se pouţije nepřerušující událost, která spustí novou větev s aktivitou „změn údaje“. Dále nová specifikace přináší Business rule (BR) task, eskalaci (escalation event) a další změny. Úkolem business rule tasku je umoţnit provázání BPMN modelu s BR. BR task vrací hodnotu pravidla pro danou situaci, neprovádí ţádnou jinou činnost.
6
Obrázek 4 XML schéma aktivity (OMG, 2009)
2.2.1 OBJEKTY BPMN Tato kapitola se věnuje popisu jednotlivých grafických objektů BPMN notace. Na stránkách OMG je k dispozici UML model všech elementů BPMN 1.1 (OMG), který obsahuje všechny moţné prvky diagramu včetně atributů. Z důvodu rozsáhlosti modelu a zachování jeho pochopitelnosti není moţné model vloţit do této práce ani jako přílohu. Objekty jsou rozděleny do pěti hlavních kategorií: (OMG, 2009) Tokové objekty: události, aktivity a brány Spojující objekty: sekvenční toky, toky zpráv, asociace a datová asociace Dráhy: dráhy a bazény Data: datové objekty, vstupy, výstupy, data stores, properties Artefakty: skupiny a textové anotace Ukázky objektů byly vytvořeny v nástroji Aris Express 2.0. 2.2.1.1 Události Tokové objekty tvoří nejdůleţitější skupinu prvků diagramu. Událost je něco, co nastane během běhu procesu. Události se dělí na počáteční, mezikrokové a koncové podle toho, kdy proces ovlivní. Zmíněné události jsou zobrazeny na Diagram 1. Počáteční událost vytváří novou instanci procesu. Proces má většinou jednu počáteční událost. Pokud je událostí více, tak první událost, která nastane, spouští proces. Později příchozí počáteční události vytváří nové instanci procesu. V XML diagramu je moţné nastavit, aby proces po vytvoření čekal na příchod všech událostí. Při přijetí jakékoliv startovací události se vytvoří nová instance procesu ve stavu čekání na příchod všech ostatních startovacích událostí, proces je spuštěn aţ 7
po příchodu všech událostí. Pouţití více startovacích událostí znepřehledňuje model a z diagramu není na první pohled patrné, která událost(i) proces spustila, proto je doporučováno tvořit procesy pouze s jednou startovací událostí.
Diagram 1 Počáteční, vnitřní a koncové události v BPMN
Tabulka 1 zobrazuje moţné počáteční události, které spouští novou instanci procesu. Počáteční událost bez speciálního druhu (none event start), vyţívá se v podprocesech. Podmíněný start (conditional event), se vyuţívá k automatickému spuštění procesu, pokud dojde k poklesu (překročení) určitého ukazatele, např.: míry zásob. Událost (message event) je reakcí na příchozí zprávu z vnějšku bazénu. Zprávy není moţné zasílat uvnitř bazénu. Vícenásobná událost (multiple event) umoţňuje spuštění procesu více událostmi. Další tok procesu je stejný pro všechny události. Paralelní událost (paralel multiple event) čeká na příchod více událostí, aţ poté se pokračuje v běhu procesu, funkcionalitou je podobná AND bráně. Signálová událost (signal event) reaguje na signál vytvořený jiným procesem, případně procesem samotným. Jedná se o alternativu slabé vazby (vzor observer) Časová událost (timer event) umoţňuje pravidelné spouštění proces (týdně, první středu v měsíci, po hodině apod.) Chybová událost (error event) zachycuje chybu vytvořenou jiným procesem.
Tabulka 1 Počáteční události v BPMN 2.0
Nepřerušující události, které nepřerušují běh procesu, ale vytvářejí novou větev, se zakreslují s čárkovaným ohraničením viz Diagram 2.
8
Diagram 2 Přerušující a nepřerušující událost
Obrázek 5 Události v BPMN (OMG, 2009)
Obrázek 5 rekapituluje všechny události v BPMN dle specifikace. Události v prvních dvou sloupcích (catching) slouţí k odchycení událostí, které nastaly jinde během běhu procesu, například čekání na zprávu od zákazníka. Události ve dvou pravých sloupcích slouţí k vyhození zprávy během běhu procesu. Paleta dostupných událostí je bohatší neţ u startovacích událostí, viz. Tabulka 1. Během běhu procesu je moţné vyuţívat událost zrušení (cancel event), která ihned zruší běh daného procesu (pod-procesu), kompenzační událost (compensation event), která vyvolá roll-back prováděného procesu dle definovaných aktivit pro navrácení procesu do původního stavu. Odkazující (Link) událost odkazuje na pokračování diagramu na jiné straně. 2.2.1.2 Aktivity Aktivita je obecný termín pro činnost vykonávanou ve společnosti. Aktivity mohou být atomické nebo sloţené z více aktivit. Aktivity se dělí na pod-procesy a úlohy. Pod-procesy umoţňují tvorbu hierarchických modelů, kde se jeden proces skládá z více vnořených
9
procesů. Úroveň jednotlivých abstrakcí není nijak omezená. Úloha je činnost, kterou není rozumné pro účely modelování procesu jiţ dále dělit.
Diagram 3 Úlohy: běţná, opakující se, násobná – paralelní, násobná - sekvenční a pod-proces
Diagram 3 zobrazuje zachycení úloh a pod-procesů v BPMN. S úlohou i pod-procesem je moţné spojit událost (boundary event), která je aktivní pouze po dobu běhu dané úlohy, viz první úloha v diagramu. V BPMN je moţné vyuţít cyklické úlohy. Druhá úloha představuje opakující se úlohu (loop task), která se opakuje, dokud není splněna podmínka pro ukončení. Dopředu není znám počet opakování, z toho vyplývá, ţe jednotlivé instance jsou spouštěny sekvenčně za sebou. Z programátorského hlediska se opakující se úloha dá přirovnat k „dowhile“ („while-do“) cyklu. Násobná úloha se dá přirovnat k „for each“ cyklu. Dopředu je znám počet opakování a cyklus prochází všechny prvky mnoţiny (například příchozí zboţí). Všechny druhy opakování je moţné vyuţít i pro pod-procesy. V BPMN existuje celkem osm druhů úloh, které jsou odlišeny graficky uvnitř diagramu úlohy. Názvy úloh byly ponechány v angličtině: Abstract, Business rule, manual, receive, skript, send, service, user task. Diagram 3 zobrazuje zleva Business rule task, user task, send message task a service task. Manual a user úlohy jsou určeny k modelování úloh, které jsou vykonávány uţivateli bez větší automatizace. Receive a send úlohy slouţí k přijímání/posílání zpráv. Je moţné je nahradit událostí. Script task přímo spouští kód v procesním enginu. Pokud nejsou úlohy nijak speciálně modelovány, tak jsou spouštěny v synchronním reţimu. Pro dosaţení asynchronní komunikace je nutné vyuţít zaslání a přijmutí zprávy od externího bazénu. Service task invokuje pouţití webové sluţby. Business rule task vrací hodnotu pravidla v dané situaci. 2.2.1.3 Brány Brána označuje v procesu místo, kde dochází ke spojení nebo rozdělení procesu do alternativních či paralelních větví. Základní brána bez označení stejně jako brána s kříţkem uvnitř znamená exklusivní OR (XOR), kde pouze jedna větev je povolená. OR join brána je vhodná ke spojení podmíněně spouštěných větví, kde neznáme předem, která větev bude aktivována. Brána čeká na všechny aktivované toky. Komplexní bránu je moţné vyuţít pro
10
nadefinování vlastní podmínky. Příkladem můţe být diskriminátor, kde je brána v potaz první příchozí větev a poté proces pokračuje v běhu dál bez čekání na ostatní větve.
Diagram 4 Brány v BPMN: základní, paralelní, XOR, událost, OR join (nebo), komplexní brána
2.2.1.4 Spojovací objekty Spojovací objekty spojují ostatní objekty do logických uskupení. Do spojovacích objektů patří: sekvenční tok, toky zpráv, asociace a datová asociace. „Sekvenční tok vyjadřuje pořadí, v jakém budou činnosti v rámci procesu prováděny. Sekvenční tok je symbolizován šipkou, která směřuje od zdrojového objektu k cílovému objektu. Těmito objekty mohou být události, činnosti nebo uzly.“(Řepa, 2007 str. 133)
Diagram 5 Podmíněný a defaultní tok
Podmíněný tok (označený kosočtvercem) se realizuje, pouze pokud je splněna podmínka daného toku. Podmíněný tok nemusí nutně vycházet z brány, z aktivity můţe vycházet více toků.
Podmíněné toky nemusí obsahovat navzájem se vylučující se podmínky. Kaţdá
podmínka se vyhodnocuje zvlášť bez závislosti na ostatních podmínkách. Z toho vyplývá, ţe více podmínek můţe mít hodnotu „true“. Defaultní tok se realizuje, kdyţ není splněna podmínka pro ţádný podmíněný tok. Větve procesu, kde se vykytuje alespoň jeden podmíněný tok, je moţné spojit pouze „nebo“ bránou (OR join). Toky zpráv slouţí ke komunikaci mezi bazény. Příklad vyuţití ukazuje Diagram 6, kde reklamační oddělení nejdříve obdrţí zprávu od zákazníka, poté je provedeno vyhodnocení reklamace a zákazníkovi je odeslána zpráva s vyhodnocením.
11
Diagram 6 Toky zpráv mezi bazény
Datová asociace je novým objektem v BPMN 2.0 a slouţí k připojení vstupních a výstupních datových zdrojů. Vyjadřuje se orientovanou přerušovanou šipkou. Asociace slouţí k připojení ostatních objektů. Asociace můţe vyuţívat orientovanou i neorientovanou přerušovanou čáru.
Diagram 7 Neorientovaná a orientovaná asociace
2.2.1.5 Bazény a dráhy V 1.x verzích BPMN byl bazén definován jako kontejner pro proces. V BPMN 2.0 je bazén definován pouze pro diagram spolupráce, kde zobrazuje toky zpráv mezi procesem a externími subjekty. Bazén můţe obsahovat pouze jeden proces. (Silver, 2009 pp. 25-26) Dle prof. Řepy Bazény a dráhy „umoţňují v popisech procesů zvýrazňovat úlohy pohledu jednotlivých entit – podniků a účastníků procesu“ (Řepa, 2007 str. 133). Pro praktické pouţití je bazén vhodné pouţít jako kontejner pro proces a pojmenovat ho názvem procesu. Dráhy je vhodné pouţít jako rozčlenění procesu dle vykonávání či odpovědnosti. Dráhy je vhodné pojmenovat jménem organizační jednotky nebo role. Externí účastníky je většinou vhodné modelovat pouze jako bazén bez modelu procesu a členění na aktivity. Jak externí účastník vykonává svou činnost, proces většinou nezajímá. Z hlediska procesu je podstatná vzájemná komunikace. Příkladem takového subjektu je zákazník v Diagram 6.
3 AGENTOVÝ PŘÍSTUP
12
Cílem této kapitoly je charakterizovat agenty samotné a základní přístupy k jejich tvorbě. Oblasti vyţití agentů zaznamenaly významný rozvoj během posledních let. Jedním z těţišť rozšíření agentů jsou agentové simulace, které umoţňují simulace komplexních problémů, jeţ jsou jinými prostředky obtíţně proveditelné. Pro dosaţení cíle práce je nejprve nutné charakterizovat agentový přístup, se kterým mnoho lidí z oblasti aplikované informatiky není příliš seznámeno. Kapitola se věnuje základním definicím a klasifikaci a poté rozebírá různé moţnosti vyuţití agentů v oblasti software. Od tohoto pohledu se můţou lišit charakteristiky agentů, pokud by se jednalo o vyuţití v oblasti umělé inteligence.
3.1 Definice Agenta je moţné obecně definovat jako: „část komplexních adaptivních systémů provádějící rozhodování. Kaţdý agent má vlastní sadu pravidel, které mu umoţňují přijímat informovaná rozhodnutí. Agent má schopnost učení se a adaptace“ (North, et al., 2007 p. 24). Jiná definice: „Agent je entita zkonstruovaná za účelem kontinuálně a do jisté míry autonomně plnit své cíle v adekvátním prostřední na základě vnímání prostřednictvím senzorů a prováděním akcí prostřednictvím aktivátorů. Agent přitom ovlivňuje podmínky prostředí tak, aby se přibliţoval plnění cílů.“ (Kubík, 2004 str. 12). Agenty jsou některými autory označovány jako další vývojová fáze objektů, ke kterým jsou přidány vnitřní přesvědčení a cíle. Tabulka 2 srovnává úroveň abstrakce objektů a agentů. Tento přístup je více rozšířen v oblasti softwarových agentů. Objekt
Agent
Zapouzdřuje proměnné a metody
Zapouzdřuje chování
Nutná synchronizace vláken
Agenty jsou vzájemně nezávislé
Uspořádání objektů prostřednictvím dědičnosti
Uspořádání agentů v organizacích
Komunikuje voláním metod (posíláním zpráv)
Komunikuje
prostřednictvím
komunikačních jazyků Prostředí (kromě kompilačního nehraje ţádnou Prostředí sehrává významnou roli roli Tabulka 2: Srovnání abstrakce objektů a agentů (Kubík, 2004 str. 13)
13
vyšších
Vnitřní přesvědčení jsou interní vlastnosti agentů, které ovlivňují jejich chování, můţe se jednat například o sklon k riziku nebo o jiné sociologické vlastnosti. Na rozdíl od objektů je agent iniciativní. Pro naplnění svých cílů je agent, kromě čekání na volání, schopen činnost iniciovat a sám ji aktivně provádět. Na druhou stranu nemusí činnost na poţadavek vykonat, pokud to odporuje jeho cílům a uzavřeným SLA. Agenty tedy charakterizují tři základní vlastnosti (North, et al., 2007 p. 27): Schopnost přijmout vlastní rozhodnutí, Cíl, ke kterému jsou tato rozhodnutí směrována, Schopnost ostatních identifikovat komponentu, agenta. Úplný agent by také měl mít schopnost adaptace. Z pohledu koncového uţivatele můţe být agent definován jako „program pomáhající uţivatelům, který jedná v jejich prospěch. Agenty fungují na základě delegace úkolů od uţivatelů.“ (Lange, et al., 1998). Ze systémového pohledu lze dle Langeho nahlíţet na agenta jako na softwarový objekt, který má následující vlastnosti (Lange, et al., 1998): Je situován ve spustitelném prostředí Povinné vlastnosti o Reaktivita: agent vnímá změny prostředí a reaguje na ně o Autonomie: agent má kontrolu nad svými akcemi o Cílevědomost: snaha dosáhnout cíle o Časová kontinuálnost: schopnost aktivity po dobu ţivota Další nepovinné vlastnosti o Komunikativní: schopnost komunikace s ostatními agenty o Mobilní: schopnost přemístit se z jednoho hostitele na druhého o Schopnost učení se: schopnost brát v potaz minulé události při rozhodování o Důvěryhodnost: důvěryhodnost agenta pro koncového uţivatele Vnitřně je softwarový agent rozdělen na několik částí, které vykonávají jednotlivé činnost (viz Obrázek 6).
14
Obrázek 6 Architektura softwarového agenta (Netrvalová, 2006)
Důleţitou součástí agentových systémů je prostředí, ve kterém agenty operují. Dle Wooldridge je moţné prostředí charakterizovat z několika úhlů pohledu. Prostředí můţe být deterministické nebo stochastické. Deterministické prostředí je plně předvídatelné, nevyskytují se v něm náhodné události (např.: generátor náhodných čísel). Opakování stejného postupu se stejnými vstupními informacemi vede v deterministickém prostředí ke stejným výsledkům. Ve stochastickém prostředí se vykytují náhodné prvky. Výsledky operací se stejnými vstupy jsou vzájemně odlišné díky nahodilosti a nepředvídatelnosti některých prvků. Prostředí můţe být statické nebo dynamické v závislosti na tom, kolik prvků ho můţe najednou měnit. S tímto členění souvisí rozdělení prostředí na diskrétní a neustále trvající. Systémy zaloţené na tazích, kde nedochází k více tahům najednou, jsou příkladem statického diskrétního prostředí. Můţe se jednat o tahovou strategii, kde se nejprve provedou obecné změny systému a pak jednotliví hráči hrají postupně ve stanoveném pořadí. (Wooldridge, 1999)
3.2 Druhy agentů Agenty je moţné rozdělit dle jejich komplexnosti a vnímání okolního světa na: (Ipser, 2008) 1) reaktivní 2) deliberativní 3) sociální
15
4) hybridní.
3.2.1
REAKTIVNÍ AGENT
Charakteristiky druhů agentů byly vytvořeny kombinací několika zdrojů (Wooldridge, 1999), (Lange, et al., 1998), (Kubík, 2004), (Šalamoun, 2009). Reaktivní agent je nejjednodušším typem agenta. Přijímá vnější signály a podle vlastních pravidel na ně odpovídajícím způsobem reaguje. Tyto pravidla bývají jednoduchá, většinou se jedná o strukturu „pokudpak“ pravidel. Reaktivní agent si neuchovává vlastní obraz vnějšího prostředí, často si ani neudrţuje vnitřní stav. To způsobuje, ţe agent nemá schopnost adaptace a učení se. Jednou
z implementací
reaktivních
agentů
je
subsumpční
architektura
vytvořená
R. Brookesem, která klade důraz na budování systému od spodu. Nejdříve jsou vytvořeni agenty se základním chováním a pro dosaţení poţadované komplexnosti jsou postupně přidávány nové moţnosti chování. Zde jsou agenty fyzicky přítomni v prostředí. Veškeré informace získávají interakcí s vnějším prostředím. Svým chování jsou schopni prostředí ovlivňovat. Agenty nemají vlastní inteligenci, ta je vloţená do systému. Inteligence vzniká výše zmíněnou interakcí agentů s prostředím. Jednoduchost reaktivních agentů s sebou přináší několik nevýhod. Je obtíţné vloţit do systému společný cíl. Systém je formován jednotlivými interakcemi, které vznikají na základě reakčních pravidel a ne účelovým chováním agentů směřujících k dosaţení společného cíle. Tohoto chování je moţné vyuţít v simulacích, kde se zkoumají moţnosti budoucího vývoje při známých pravidlech.(Kubík, 2004)
3.2.2 DELIBERATIVNÍ AGENT Deliberativní (intencionální) agent si na rozdíl od reaktivních agentů uchovává své minulé stavy a tvoří si vlastní obraz vnějšího prostředí. Informace o vnějším prostředí získává agent pomocí vlastních senzorů a prostřednictvím komunikace s ostatními agenty.
16
Obrázek 7 Schéma deliberativního agentu (Kubík, 2004 str. 15)
Obrázek 7 ukazuje schéma deliberativního agentu. Ukazuje, jak na jednotlivé reakce agentu působí prostředí. Akce deliberativních agentů jsou ovlivněny nejen současným stavem prostředí, ale předchozími zkušenostmi agentů. Na rozdíl od reaktivních agentů je agent schopen vlastní inteligencí určit pořadí vykonávaných činností. Avšak deliberativní agent postrádá sociální inteligenci, ta je předmětem zájmů sociálních agentů. Implementace inteligence intencionálního agenta je velmi sloţitou záleţitostí. Existující přístupy je moţné rozdělit do dvou hlavních kategorií:(Šalamoun, 2009) 1) rozhodování na základě uţitku 2) rozhodování na základě logických pravidel Agent se rozhoduje primárně podle očekávaného uţitku z činnosti. Nejdříve vykonává funkce přinášející mu nejvyšší uţitek. Toto rozhodování je podobné teorii racionálního rozhodování v ekonomii. Pro vyuţití v oblasti agentů se více, z důvodu menší náročnosti na výpočty a přesnost definic, hodí ordinální teorie, kde jsou činnosti seřazeny podle uţitku, ale nejsou jim přidělené absolutní hodnoty uţitku. Rozhodování na základě uţitku má několik významných nedostatků. Prvním je obtíţnost samotného stanovení uţitku, který je velmi subjektivní hodnotou kaţdého agenta a je velice obtíţné ho obecně stanovit. Stejný problém nastává při stanovení pravděpodobností událostí agentem. Kalkulace všech moţných kombinací moţností je výpočetně náročná a můţe být nedostupná v reálném čase.(Šalamoun, 2009)
17
Druhým způsobem je rozhodování na základě logických úvah. Rozhodování probíhá na základě logických formulí. Velmi rozšířeným deliberativním agentem je BDI agent (beliefs, desires, intentions). Agent vychází z principů modální a časové logiky. Základními mentálními postoji agenta představy o světě (beliefs), tuţby a motivace (desires) a záměry směřující k plnění cílů (intentions). (Wooldridge, 1999 str. 29). Jejich detailnější charakteristiku je moţné najít v odkazovaném pramenu nebo v mnoha jiných pramenech.
3.2.3 HYBRIDNÍ A SOCIÁLNÍ AGENT Sociální agent se vyznačuje komunikací s ostatními agenty pomocí vyšších komunikačních jazyků. Agent si uchovává detailnější historii vzájemných interakcí včetně cen transakcí, ochoty spolupráce ostatních agentů a další informace. Agenty mohou vytvářet i krátkodobé koalice za účelem překonání omezenosti zdrojů. Architektura GRATE (Obrázek 8) umoţňuje spolupráci jednotlivých agentů při řešení problémů. Při potřebě spolupráce se nejdříve identifikují potenciální partneři, kteří jsou zainteresováni na společném řešeni problému. Posléze se vytvoří společný plán, přiřadí se úkoly jednotlivým agentům a tím vzniknout i jejich role.
Obrázek 8 Architektura GRATE(Kubík, 2004 str. 60)
Hybridního agenta lze definovat jako kombinaci ostatních výše uvedených agentů. „Hybridní architekturou agenta rozumíme takovou architekturu, ve které se nacházejí komponenty pro reaktivitu, deliberativnost i sociální model pro komunikaci na vyšší úrovni.“ (Kubík, 2004 str.
18
60). Hybridní agenty se snaţí vyuţít výhod předcházejících přístupů s odstraněním nedostatků jednotlivých modelů. Příkladem hybridního agenta je InteRRaP (z angl. Integration of Reactive Behaviour and Rational Planning) navrţený Janem Bubeníkem. „Hybridní agent se skládá ze dvou hlavních částí. První částí je plánovací jednotka a druhou je reaktivní jednotka. Za svého běhu agent vytvoří plán a začne jej provádět. Kaţdý krok je přitom kontrolován reaktivní jednotkou, která sleduje, zda nedošlo v systému k nějaké změně. Pokud je tato změna v blízkém okolí agenta, bude se výstup reaktivní a plánující jednotky značně lišit. Tento rozdíl je zároveň signálem k přehodnocení plánu v plánující jednotce.“(Bubeník, 2006) Schéma agenta ukazuje Obrázek 9.
Obrázek 9: Schéma hybridního agenta (Bubeník, 2006)
3.3 Vztahy mezi agenty V multiagentních systémech se vyskytuje velké mnoţství agentů. Přirozeně mezi nimi dochází k vzájemným interakcím. Vztahy mezi agenty se dají rozdělit do několika hlavní kategorií podle míry a důvodu vzájemné spolupráce:(Kubík, 2004 str. 79) 1) Koordinace 2) Kooperace 3) Soupeření Koordinací se rozumí proces přidělování limitovaných zdrojů v multiagentním systému. Agenty zde pracují na dosaţení svých vlastních cílů a vyuţívají k tomu společné omezené zdroje (např.: výpočetní čas, volná paměť). Cíle jednotlivých agentů jsou na sobě nezávislé. Omezené prostředky jsou racionálně přidělovány tak, aby nedocházelo k chaotickému
19
chování a k neustálým konfliktům mezi agenty. Zdroje můţou být přiděleny společně uznanou autoritou nebo na základě vzájemné dohody agentů. Předpokladem koordinace je povědomí agenta o ostatních agentech a schopnost komunikace s nimi. Protokol reaktivní komunikace je příkladem koordinace agentů. Protokol reaktivní komunikace definuje tři základní prvky (Kubík, 2004 stránky 80-81): 1) Značky s časovou platností 2) Funkci (schopnost) vytváření značek 3) Funkci (schopnost) interpretace značek „Prostředí si lze představit jako datové struktury, které jsou paralelně běţícími funkcemi zpracovávajícími data z prostředí. Komunikace mezi agentem a prostředím je realizována zasíláním zpráv.“ (Kubík, 2004 str. 81) Vlastní funkcionalita prostředí je pro agenty zapouzdřená komunikačním rozhraním. Výhodou tohoto způsobu komunikace je modularita prostředí. Agenty je moţné plynule přidávat a odebírat beze změn prostředí. Bez větších zásahů je také moţné provést změny prostředí, pokud přitom zůstane zachováno komunikační prostředí. Obrázek 10 ukazuje schéma prostředí, kde je vyuţívána reaktivní komunikace. Data prostředí jsou přístupná pouze přes komunikační rozhraní.
Obrázek 10 Schéma reaktivní komunikace (Kubík, 2004 str. 81)
Další moţností vzájemné koordinace je vyuţití principů aukce. Zde jsou zdroje alokovány agentům s vyuţitím vztahu nabídky a poptávky. Aukcí je několik druhů: anglická aukce, holandská aukce, jednokolová aukce, kde vyhrává nejvyšší nabídka, Vickreyova aukce,
20
oboustranná aukce. V případě zájmu čtenáře lze nalézt definice jednotlivých druhů aukcí v mnoha jiných publikacích. Kooperací se rozumí stav, kdy agenty pracují na dosaţení společného cíle. Kooperace je proces, při kterém kooperující agenty vyjednávají a rokují o společném řešení problémů nebo konfliktů. Rokující agenty mohou být řízeni centrálně nebo decentralizovaně. Kaţdý agent ve skupině má přesně definovanou roli, kterou musí plnit. Kooperace je často doprovázena vznikem koalic. Moţností jak řešit kooperaci agentů je mnoho. Základní kooperaci je moţné realizovat pomocí tabulové architektury či kontraktační sítě. Popis architektur je moţné najít v publikaci (Kubík, 2004) nebo jiných pramenech.
3.4 Modelování MAS Cílem této kapitoly je stručně představit modelování multiagentních systémů pomocí Unified modelling langure (UML) a Agent UML (AUML). AUML je rozšířením původního UML o prvky umoţňující modelování agentových systémů, které bylo později částečně zahrnuto to UML samotného. AUML vyuţívá rozšířené objektové analýzy a designu. UML spravované organizací Object Management Group (OMG) je univerzální notací určenou k modelování. Je standardem především při modelování během vývoje software. Další notací určenou k modelování MAS je Agent-Object-Relationship (AOR), který je také rozšířením UML (Wagner, 2003). Dle Wagnera (Wagner, 2003) „se AOR model skládá ze dvou hlavních částí, externí a interní. Externí AOR model nahlíţí na systém z pohledu vnějšího pozorovatele, který pozoruje jednotlivé agenty a jejich interakce ve zvaţované doménové oblasti problému. Vnitřní model definuje agenta z interního pohledu (firstperson).“ V AOR je entita buďto událost, akce, poţadavek, závazek, agent nebo objekt. Pouze agent je schopen komunikace, vnímání, akce, dávání závazků a naplňovaní poţadavků, volně převzato z (Wagner, 2003).
3.4.1 AUML Základními prvky modelování MAS v AUML vyhází z tradičních diagramů UML. Nejčastěji pouţívanými diagramy jsou sekvenční diagram, model tříd (class diagram), diagram aktivit, use case diagram a statechart diagram. Sekvenční diagram zachycuje vzájemnou interakci agentů. Vnitřní zpracování agentem je znárodněno pomocí statechart diagramu nebo diagramu aktivit. Rozšířením UML 1.X sekvenčního diagramu vznikly komunikační protokoly mezi
21
agenty, které jsou standardizovány organizací FIPA (Foundation for Intelligent Physical Agents). Jedná se o znovupouţitelnou šablonu komunikace mezi agenty, kterou je moţné vţdy přizpůsobit konkrétním podmínkám. Odell navrhuje v (Odell, et al., 2000) vyuţití vrstveného přístupu k modelování. Modelování rozděluje do tří vrstev. V první vrstvě se modelují vzájemné interakce mezi agenty na nejvyšší úrovni abstrakce a agenty přítomné v systému pomocí class diagramu upraveného pro modelování agentů. V druhé vrstvě je detailněji modelována komunikace mezi agenty. Pomocí detailnější sekvenčních diagramů a diagramů spolupráce je rozpracovaná komunikace z první vrstvy. Class diagramy jsou také rozpracovány do většího detailu. V třetí vrstvě jsou modelovány vnitřní reakce agenta na jednotlivé komunikační akty. Modelují se zde vnitřní stavy agenta pomocí statechart diagramu a diagramy aktivit popisující jednotlivé kroky vnitřního zpracování. Jednotlivé vrstvy jsou vzájemně provázány. Obrázek 11 představuje vrstvu 1, která společně s textovým popisem protokolu (Obrázek 12) tvoří nejvyšší abstrakci komunikace agentů.
Obrázek 11 Příklad komunikačního diagramu na základě šablony FIPA (Odell, et al., 2000)
22
Obrázek 11 ukazuje příklad komunikačního protokolu přizpůsobeného konkrétní situaci zobrazeného s vysokou úrovní abstrakce. Diagram je zaloţen na šabloně kontraktační sítě podle specifikace FIPA. Obrázek byl ponechán v angličtině, přeloţenou verzi je moţné nalézt v (Kubík, 2004) na straně 212. Komunikaci zde iniciuje nakupující zasláním poptávky (RFP – request for proposal) agentu v roli prodávajícího. Odpověď agenta v roli prodávajícího je časově omezená konkrétní lhůtou. Agent má tři moţnosti odpovědi: zaslání nabídky, neporozumění a odmítnutí. Kříţek v rozhodovací bráně znamená exklusivní nebo (XOR), tj. právě jedna odpověď můţe být odeslána. Agent v roli nakupujícího můţe buď nabídku přijmout, nebo odmítnout.
V případě přijmutí je iniciující agent informován o zahájení
zpracování nabídky. Iniciátor, agent v roli nakupujícího, můţe kdykoliv zrušit zpracovávanou nabídku. Obrázek 12 zobrazuje popis nově vytvořeného balíčku na základě šablony FIPA. Původní obecné popisy byly přizpůsobeny vyuţití balíčku. Iniciátor a účastník byly nahrazeny nakupujícím (buyer) a prodávajícím (seller). Lhůta je nyní tvořená konkrétním datem a komunikační akty odpovídají aktům v sekvenčním diagramu (Odell, et al., 2000).
Obrázek 12 Nově vytvořený balíček po dosazení hodnot předchozího obrázku (Odell, et al., 2000)
Vrstva dvě je tvořena UML diagramy chování a interakce. Modely zachycují jednotlivé interakce agentů. Nejvíce vyuţívány jsou sekvenční diagramy (sequence diagram), diagram aktivit (actvity diagram), collaboration diagram, stavový diagram (statechart). Kaţdý z těchto diagramů nahlíţí na komunikace z jiného úhlu. Obrázek 13 zobrazuje základní strukturu sekvenčního diagramu komunikace agentů, kde CA (communication act) rozšiřuje UML a nahrazuje původní zasílání zpráv. Diagram tříd (class diagram) popisuje agenty přítomné v systému
23
Obrázek 13 Základní formát sekvenčního diagramu
Diagram spolupráce je svým významem velmi podobný sekvenčnímu diagramu. Oba vyjadřují vzájemné moţnosti komunikace a její posloupnost. Oba modely (Obrázek 14) mají stejný význam.
Obrázek 14 Stejná situace zobrazená v diagramu spolupráce (nahoře) a sekvenčním diagramu (dole) (Odell, et al., 2000)
24
Diagram aktivit vyjadřuje posloupnost jednotlivých událostí, které je spouští. Tím umoţňuje vizualizaci skutečného běhu činností. Ze všech diagramů je nejvíce podobný procesnímu modelu, který v základní verzi vyjadřuje stejnou posloupnost. Statechart na úrovni 2 je spíše pouţíván jako omezující diagram, který vymezuje platné stavy agenta. Třetí úroveň modelování zobrazuje interní zpracování uvnitř agenta. Jedná se o detailní popis vnitřních činností agenta reagujících na jednotlivé komunikační akty, při kterých jiţ nedochází ke komunikaci s ostatními agenty. Obrázek 15 zobrazuje diagram aktivit pro vnitřní zpracování objednávky agentem. Jedná se o interní proces spouštěný na základě reakce na komunikační akt (place order) v komunikačním protokole.
Obrázek 15 Diagram aktivit: zpracování objednávky uvnitř agenta (Odell, et al., 2000)
Diagram aktivit je doprovázen vnitřním statechart diagramem jednotlivých agentů, které mohou být navzájem provázány jednotlivými událostmi a reakcemi na ně. Obrázek 16 popisuje vnitřní diagramy stavů tří agentů z předchozího diagramu aktivit. Diagramy jsou navzájem provázané prostřednictvím komunikačních aktů agentů.
25
Obrázek 16 Vnitřní statechart diagram jednotlivých agentů
3.4.2 UML UML obecně umoţňuje modelovat: objekty, entity, třídy, atributy, operace, funkce a vztahy. K větší podpoře modelování multiagentních systémů v základní verzi UML došlo ve verzi 2.0. Tato kapitola popisuje základy modelování agentních systémům verzi 2.1. Přístupy AUML byly postupně integrovány do UML samotného. Základní principy modelování MAS se od AUML neliší. Wongthongtham ve svém článku (Wongthongtham, a další, 2008) kritzuje malé rozlišování pojmu agent a jeho role v sekvenčních diagramech AUML. Pojem je často zaměňován. Příkladem je Obrázek 14, kde agent můţe mít pouze jednu roli. Pro zobrazení více rolí jednoho agenta je nutné pro kaţdou roli vytvořit zvláštní čáru ţivota. Pro snaţší modelování komunikace mezi agenty navrhují v (Dillon, et al., 2008) a (Wongthongtham, et al., 2008) oddělení agenta a jeho role. To přináší moţnost přiřadit agentu více rolí v rámci jedoho objektu. Role agenta Příklad z oblasti autopůjčovny (Obrázek 17) ilustruje pouţití portů pro rozlišení rolí agenta. Agent smlouvy (agreement) vystupuje v roli určující status vrácení vypůjčeného auta a v roli vykonavající operace.Port je název prvku diagramu vnitřní struktury (composite structure diagram), který popisuje zvnější viditelnou část popisovaného prvku (agenta). 26
Obrázek 17 Sekvenční diagram vyuţívající porty (Dillon, et al., 2008)
Druhou oblastí modelování agentů je zachycení cílů agentů. UML původně uřčený především k modelování objektů se této oblasti dlouhou dobu nevěnoval. Dillon (Dillon, et al., 2008) ve výše zmíněném článku navrhuje modelování cílů pomocí diagramu vnitřní struktury (composite structure diagram), který se stal součástí UML od verze 2.0. Pro modelování agentů jsou podstatné jiţ popsané porty, které vyjadřují různé role agenta, a vnitřní části. Kaţdá část reprezentuje samostatnou oblast zpracování. (Wongthongtham, a další, 2008)
27
Obrázek 18 Diagram vnitřní struktury agenta smlouva z předchozího obrázku (Dillon, et al., 2008)
Statický pohled a vzájemné vazby mezi agenty jsou popsány pomocí diagramu tříd. Tento velmi populární diagram v objektovém modelování má podobné vyuţití i při modelování multiagentních systémů. Zobrazuje agenty přítomné v systému, vazby mezi nimi. Problematika modelování MAS je velmi sloţitá a její komplexnější vysvětlení by vydalo na samotnou diplomovou práci. Zde byly popsány především části modelování a diagramy, které jsou nadále v práci pouţívány. Detailnější přístup modelování multiagentních systémů pomocí UML je popsán v (Bauer, et al., 2005).
4 VYUŢITÍ AGENTŮ Tato kapitola se zabývá moţnostmi vyuţití agentů v praxi. Úvod kapitoly se zabývá celkovými moţnostmi pouţití agentů v průmyslu. Další části kapitoly se věnují hlavnímu tématu práce a to moţnostem vyuţití v oblasti business procesů. Dle studie Pěchoučka a Mařka v časopise International Journal on Autonomous Agents and Multi-Agent Systems (Pěchouček, et al., 2008) je moţné oblasti potenciálního vyuţití agentů rozdělit do následujících kategorií: (Pěchouček, et al., 2008) 1) Agentově orientované softwarové inţenýrství (AOSE; Agent Oriented Software Engineering) poskytující návrhářům a vývojářům prostředí a nástroje, které umoţňují
28
tvorbu aplikací s autonomními a komunikativními elementy, vedoucí k tvorbě software a infrastruktury splňujícího tyto vlastnosti. 2) Multiagentní techniky (Multi-agent Techniques), které poskytují výpočetní techniky a algoritmy umoţňující řešení komplexních výpočetních úloh v otevřeném dynamickém prostředí. 3) Multiagentní simulace (Multi-agent Simulation) poskytuje nástroje a metody pro modelování komplexních a dynamických prostředí skutečného světa. Důraz je kladen na vzájemné interakce prvků a jejich vliv na vlastnosti celého systému. 4) Autonomně orientované techniky (Autonomy-Oriented Techniques) poskytující soubor technik umělé inteligence podporující autonomní rozhodování inteligentního systému a schopnost přizpůsobit rozhodování aktuálním podmínkám a minulým zkušenostem. Tabulka 3 zobrazuje základní přehled moţností vyuţití agentů v devíti doménových oblastech. Pro moţnost pochopení tabulky je nutné detailněji popsat jednotlivé hodnotící kritéria domény: (Pěchouček, et al., 2008) Typy vyuţívaných konceptů agentů Integrace se stávajícími systémy označuje, zda je integrace se stávajícími systémy klíčovým poţadavkem Fáze vyuţití (vyspělost produktů) značí v jaké fázi vývoje a výzkumu se tato oblast nachází. Stav je rozdělen do tří moţností: ukázkový systém, prototyp a reálné vyuţití. Ukázkovým systémem se myslí software vytvořený výzkumnými týmy. Hardwarová integrace specifikuje, zda je agentní technologie postavená celá na softwarové úrovni nebo zda zahrnuje i hardwarové komponenty. Funkcionalita vyjadřuje funkční poţadavky na MAS. Zde je důleţité oddělit koncepty agentů od poţadované funkcionality multiagentního systému. Agentní platforma udává na jaké platformě je aplikace vytvořená. Aplikace můţe být vytvořená na proprietární infrastruktuře nebo vyuţívat jiţ existující platformy. Detailnější pozornost je nutné věnovat vysvětlení konceptů agentů. Některé koncepty jsou detailněji vysvětleny v předchozích kapitolách (kapitola 3). Nyní budou postupně rozebrány jednotlivé koncepty vyskytující se v tabulce. Úkolem koordinace je zajistit spolupráci autonomních agentů. Koordinace většinou zajišťuje řešení konfliktů a kolizí a sdílení zdrojů. Vyjednávání poskytuje vyjednávací a aukční techniky, které souţí k domluvě mezi agenty.
29
Zde je kladen důraz na stanovení plánu akcí a strategií, tak aby agent dosáhl co největšího vlastního uţitku. Simulace poskytuje techniky ke zkoumání kolektivního chování agentů. Zkoumá, jak jednotlivé interakce působí na systém jako celek a emergenci chování celého systému. Zároveň simulace umoţňuje provádění „co-kdyţ“ analýz. Účelem interoperability je dosaţení vysoké míry spolupráce mezi komponentami systému, které nesdílí společný model chování a prostředí. Interoperabilita není zkoumána jen na fyzické úrovni pomocí komunikačních protokolů, ale je zkoumána i sémantika komunikace. Další oblastí je měnitelná autonomie, která vyjadřuje schopnost prostředí dynamicky měnit autonomii rozhodování jednotlivých agentů v systému. Distribuované plánování poskytuje metody spolupráce a sdílení informací za účelem plánování činností autonomních agentů. Plánování je rozděleno na pět částí: Dekompozice úkolu, alokace zdrojů, vyřešení konfliktů, individuální plánování a spojení plánů. Důvěra a reputace umoţňuje agentu vytvořit si model důvěry a sdílet reputaci s ostatními agenty. Důvěra a reputace se pouţívá ve společenství trvale nespolupracujících agentů a slouţí k hodnocení ostatních agentů například při vytváření koalic. Výše zmíněné popisy konceptů jsou převzaty a mírně doplněny z (Pěchouček, et al., 2008).
30
Oblast
Koncept agentů
Koordinace, vyjednávání, Řízení výroby distribuované plánování, simulace, interoperabilita
Integrace Fáze využití Ano
Ukázkové systémy
Hardwarová Funkcionalita integrace Kritická
Agentní platforma
Účastnící se společnosti
Řízení, simulace, diagnostika
Proprietární, JADE
Rockwell Automation, DaimlerChrysler, BHP, Billiton
Logistika
Koordinace, vyjednávání, distribuované plánování, simulace
Ne
Reálné systémy Ano
Plánování, rozvrhování
Proprietární, Magenta, Cougaar
Magenta, Whitestein, Cougaarsoftware
Plánování výroby
Koordinace, distribuované plánování, simulace, interoperabilita
Ne
Reálné systémy Důležitá
Plánování, rozvrhování
Proprietární, JADE
Volkswagen, Liaz, Škoda Auto, CERTICON
Simulace
Koordinace, vyjednávání, simulace, měnitelná autonomie
Ne
Ukázkové systémy
Ano
Simulace, řízení, plánování
Proprietární, JADE, AGlobe
Rockwell Automation, CADENCE, CERTICON, SCA Packaging
Bezpilotní řízení letadel
Koordinace, vyjednávání, měnitelná autonomie, BDI architektura
Ano
Plánování, simulace, řízení, řešení konfliktů
AFRL, DSTO, SRI, Proprietární, A-Globe, Americká armáda, JACK Quinetiq
Objevování vesmíru Výcvik a Vzdělávání
BDI architektura, měnitelná autonomie Simulace, měnitelná autonomie, BDI
Distribuované učení se, Automobilový distibuované učení se (metaprůmysl reasoning), sdílení znalostí
Ne
Prototyp
Ne
Reálné systémy Důležitá
Řízení, plánování, simulace
Proprietární
NASA, JPL
Ne
Ukázkové systémy
Ne
Simulace, trénink
Proprietární, JACK, DEFACTO
AOS, TNO, LFAD, UKMOD
Ne
Prototyp
Důležitá
Diagnostika, simulace, ad-hoc networking
N/A (Restina, A-Globe)
Denso, DaimlerChrysler, Volkswagen, BMW
Ne
Integrace, plánování, koordinace
JADE, webové služby
Virtuell Fabrik, Siemens, LogicaCMG, Liaz, Global Infotek, SAP, IBM, CERTICON
Dodavatelské Sdílení znalostí, aukce, důvěra, Důležitá řetězce interoperabilita
Prototyp
Tabulka 3 Přehled domén vyuţití agentů (Pěchouček, et al., 2008)
31
4.1 Vyuţití agentů v oblasti business procesů Tato kapitola se zabývá moţnostmi vyuţití agentů v oblasti business procesů. Výzkumná činnost, která v oblasti agentů trvá jiţ více neţ dvě desetiletí, společně s jiţ realizovanými projekty ukazují na široké vyuţití agentů v oblasti podnikových procesů. Výzkum a aplikace se zaměřují na několik oblastí. První oblastí je vyuţití agentů při samotném modelování podnikových procesů. Druhou oblastí je BPM, workflow a ostatní software vyuţívající princip agentů. Třetí popisovaná oblast v této kapitole se zaměřuje na simulace s vyuţitím agentů. Poslední popisovanou oblastí je vyuţití agentů pro plánování a rozvrhování činností. Velmi často dochází k prolínání výše zmíněných oblastí. Jejich vymezení je spíše teoretické a slouţí k ilustraci širokých moţností vyuţití agentů nejen v oblasti podnikových procesů. Téma modelování procesů a Business process management (BPM) software spolu velmi úzce souvisí. Model procesu vyuţívající agenty je moţné získat přímým modelováním nebo transformací dnes běţně pouţívaných notací (př. BPMN). Cílem vyuţití agentů při modelování business procesů je zvýšení jejich flexibility. Dnešní přístupy k modelování podnikových procesů málo reflektují přirozenou povahu business procesů. Často se příliš soustředí na identifikaci aktivit a jejich umístění do řetězce činností. Modely procesů jsou málo flexibilní vůči změnám. Řetězec činností je pevně dán a obsahuje většinou jen ideální průběh a případně pár výjimek. Modelování nestandardního průběhu je velmi pracné a znepřehledňuje diagramy. Změn, které mnohou nastat, je velmi mnoho a liší se úrovní dopadu, délkou trvání a závaţností změny. Obrázek 19 přehledně zobrazuje jednotlivé typy změn. Dle Regeva (Regev, et al., 2005) lze změny rozdělit do pěti hlavních kategorií, mohou nastat změny: funkcionality, která určuje, co proces má dělat. Především se jedná o cíl procesu. operační perspektivy popisující aktivity procesu. perspektivy chování určující, kde a za jakých podmínek jsou jednotlivé aktivity vykonávány. informační perspektiva určující vstupní a výstupní informace. v organizační perspektivě definující, kdo a v jakých rolí se procesu účastní. (Regev, et al., 2005)
32
Obrázek 19 Moţné změny v business procesu (Regev, et al., 2005)
Kaţdá změna lze popsat několika vlastnostmi. První vlastností je rozsah změny. Můţe se jednat od inkrementální nebo radikální změnu. Druhou vlastností je doba trvání změny, jeţ můţe mít dočasný nebo trvalý charakter. Třetí vlastností je účinek změny, který se můţe projevit ihned nebo aţ s odloţeným účinkem. Očekávanost změny je další charakteristikou. Očekávané změny jsou většinou iniciované uvnitř podniku. Ad hoc změny bývají způsobeny externími faktory. (Regev, et al., 2005)
4.1.1 VYUŢITÍ AGENTŮ PŘI MODELOVÁNÍ Dnes pouţívané notace modelování procesů vycházejí z flow-charting principu, kde struktura procesu a pořadí vykonávání jednotlivých činností jsou pevně dány. Hlavní důraz je kladen na identifikaci činností a jejich seskupování do sekvencí. Tento předpoklad výrazně komplikuje moţnosti modelování procesů. U mnoha procesů není moţné určit pořadí a návaznost jednotlivých aktivit, pokud je vůbec moţné aktivity dopředu stanovit. Navíc společnosti dnes operují v dynamickém prostředí, které se neustále mění. Pro zachování konkurenceschopnosti musí být společnost flexibilní a schopná adekvátně reagovat na externí události. Zejména v těchto oblastech naleznou multiagentní systémy vyuţití. V oblastech, kde je okolí pevně dáno a běh procesu je předem znám, bez velkého výskytu nahodilostí, je pouţití multiagentního přístupu zbytečné a nepřinese novou kvalitu do systému.
33
Obrázek 20 Business proces s pouţitím agentů (Grundspenkis, et al., 2006)
Základní představu agentů v podnikovém procesu zobrazuje Obrázek 20. Proces a jeho činnosti jsou rozděleny mezi autonomní agenty, které jsou zodpovědné za výkon jim přidělených činností. Pro splnění cíle procesu je nutné vyjednávání mezi agenty. Agenty spolupracují na základě vzájemně uzavřených SLA. Kaţdý proces má svého vlastního agenta, zodpovědného za jeho realizaci. Agent procesu zodpovídá za dosaţení celkového cíle a koordinace agentů jednotlivých aktivit či skupin aktivit. Dále agent procesu reaguje na vnější události a případně iniciuje znovu vyjednání jednotlivých SLA uzavřených mezi agenty v rámci procesu. Diagram procesu je tak nahrazen agenty a jejich interakcemi. Graficky je moţné tyto vztahy vyjádřit pomocí sekvenčního diagramu, který zachycuje moţnosti vzájemné komunikace. (Grundspenkis, et al., 2006) Vyuţití agentů pro samotné modelování procesů bez dalších návazností v podobě vývoje multiagentního systému nebo simulace je velmi problematické a dle názoru autora k tomuto vyuţití nedojde. Hlavním problémem je častá nedůvěra uţivatelů v agenty. Pro většinu lidí je koncept aktivní části programového kódu obtíţně představitelný. Zároveň dochází k odklonu od jednoduchosti procesního diagramu, ve kterém alespoň základní prvky a principy pochopí i neškolený uţivatel během krátkého časového úseku. Na druhou stranu pokud člověku neseznámenému s agenty předloţíte model procesu s vyuţitím agentů, bude pro něj jeho pochopení mnohem sloţitější. Obtíţná uchopitelnost agentů posiluje nedůvěru v MAS. Navíc nasazení multiagentního systému přináší často radikální změnu ve způsobu práce a komunikace. Příkladem je nasazení MAS pro plánování jízd taxisluţby, kde výkon většiny úloh plánování přebírají od operátorů agenty (viz kapitola 4.1.3)(Glaschenko, et al., 2009). To s sebou přináší změny v celkové organizaci firmy a je nutná vysoká důvěra ve schopnosti MAS.
34
V této práci je prezentován přístup, kde základní procesní modely organizace, tvořené v dnes běţně pouţívaných notacích (BPMN, EPC a další), jsou pouţívány jako prvotní prvek v tvorbě MAS. Tyto modely jsou získány, případně vytvořeny jako první krok analýzy MAS a zároveň slouţí ke komunikaci s ostatními členy projektového týmu, především s lidmi nepocházejícími z IT. Samozřejmě procesní modely jsou pouze jedním ze vstupů a při jejich vyuţití při tvorbě MA systémů je nutné je transformovat a výrazně doplnit. Zde je moţné vyuţít níţe navrhovanou transformaci BPMN do agentového modelu. Důvody pro pouţití tohoto přístupu byly naznačeny jiţ výše v tomto odstavci. Snahou je posílit důvěru v agenty mezi uţivateli. Na druhou stranu tento přístup přináší několik negativ. Projektový tým musí být schopen překonat statickou podobu procesního modelu a plně se věnovat moţnostem vyuţití agentů. Procesní model by měl napomoci pochopení toho, jak systém funguje dnes, ne k omezení toho, jak by mohl systém fungovat v budoucnu. Toto je důleţité mít neustále na paměti. I přes toto omezení je pouţití výše zmíněných notací viděno jako vhodnější prostředek komunikace neţ sloţité modely agentového systému. Procesní model je moţné vyuţít i pro prezentaci funkcionality agentového řešení. Příkladem je vyuţití BPMN pro znázornění průběhu agentové simulace v AOR (agent-object relationship). Obrázek 27 ukazuje průběh MA simulace drive-trhu restaurace(Nicolae, et al., 2009). Toto vyjádření simulace je snadno pochopitelné i bez hlubších znalostí principů multiagentní simulace. Agenty jsou znázorněny jako jednotlivé dráhy bazénu. Principy AOR simulace budou detailněji popsány v kapitole ji věnované. Nejedná se o přímé vyuţití agentů při modelování business procesů, ale spíše o obrácený přístup. Vyuţití současných metod modelování procesů v tvorbě a modelování multiagentních systémů. Přesto se jedná o důleţitou část umoţňující lepší komunikaci mezi zainteresovanými stranami.
4.1.2 ABPM(S) Tato kapitola se věnuje moţnostem vyuţití agentů v Agent business process management (ABPM) a ABPM suite (ABPMS), který je softwarovou realizací konceptů BPM. Cílem je zjistit, zda je moţné vyuţít agenty v procesním řízení podniku. Před diskuzí moţností vyuţití agentů je nejprve nutné definovat obsah pojmu BPM. „Business Process Management (BPM), česky procesní řízení je manaţerská disciplína a současně technologie vyuţívající pro procesně orientované řízení podniku jeho architekturu podnikání. BPM je zaměřen na řízení celého ţivotního cyklu podnikání, coţ vyţaduje i zvládnutí změn ve firemní kultuře. Dnešní úspory vytváří zítřejší potenciál pro inovace. Potenciál intuitivního zlepšování se však postupně vyčerpává a vzhledem ke komplexnosti 35
podnikatelských struktur dochází při zvyšování výkonnosti k překročení hranic přípustného rizika. BPM jako manaţerská disciplína zaměřená na řízení ţivotního cyklu podnikání je komplex metodologie a prostředků (nástrojů), která toto intuitivní zlepšování nahrazuje inţenýrským přístupem. Ten je spojený s vědomým a cíleným řízením firemní architektury, tedy všech strukturálních součástí, které tvoří byznys – od cílů přes procesy aţ po zdroje. Většinou je opřen o business model, výkres podnikových struktur, na kterém lze změny navrhovat a ověřovat dříve, neţ jsou zavedeny do praxe. A to ve všech podstatných souvislostech a bez rizik.“ (BPM Portál, 2008) V této práci jsou workflow systémy podporující automatické řízení průběhu procesu součástí BPM. Obrázek 21 zobrazuje architekturu BPMS a jeho hlavní komponenty. Analýza vyuţití se bude soustředit na části modelování, návrh spustitelných procesů a procesní engine.
Obrázek 21 Architektura BPMS (Silver, 2010)
Jennings stanovuje následující poţadavky na BPM: (Jennings, et al., 1998) Umoţňuje lidem vykonávajícím rozhodnutí přístup k relevantním informacím bez ohledu na to, jak a kde jsou v podniku uloţeny. Umoţňuje lidem vykonávajícím rozhodnutí dostat podporu v rozhodování z jiných oddělení či z okolí podniku. Proaktivně vyhledává a doručuje aktuální související informace, i kdyţ o ně nemuselo být ţádáno (např.: z důvodu nevědomosti o jejich existenci).
36
Informuje vykonavatele o změnách nastalých jinde v podniku a jeho okolí, které mohou mít vliv na jeho činnost a rozhodování. Identifikuje zájmové skupiny zajímající se o výsledky rozhodnutí. Větší flexibilitu je třeba také dodat systémům pro řízení workflow. Cílem je dosaţení adaptivního tvoření workflow na základě parametrů procesů, aktuální situace a dalších faktorů. Za účelem reálnosti implementace bez přílišné sloţitosti je vhodné ze začátku moţnosti adaptibility zjednodušit a jednoznačně je vymezit. Poţadovanou funkcionalitou je automatická změna toku workflow, ve zjednodušené verzi nahrazení jedné úlohy (aktivity) druhou, odstranění aktivity, přidání jedné aktivity na základě parametrů procesu a jeho předchozího průběhu. S tím souvisí i problematika přiřazení rolí jednotlivým aktivitám. Výše uvedené poţadavky odpovídají definici agentů a je dobré se minimálně zamyslet nad potenciálem agentů v této oblasti. Vyuţití agentů lze rozdělit do dvou oblastí. První je osobní agent přímo podporující uţivatele. Druhou oblastí je vyuţití agentů pro při změnách workflow procesů. Úkolem osobního agenta je naplňovat poţadavky definované Jenningsem. Agent můţe za člověka vykonávat jednodušší úkoly zcela automaticky nebo po odsouhlasení. Příkladem můţe být organizace meetingu. Agent se spojí s agenty ostatních zúčastněných a pokusí se vyjednat termín. Pro vyhledávání termínu je moţné vyuţít kalendáře jednotlivých uţivatelů, pokud je to vyţádáno, tak agent nabídne organizátorovi vhodné termíny, kdy jsou dostupní všichni účastníci, nebo rovnou vybere termín sám. Společně s tím agent automaticky zarezervuje vhodnou zasedací místnost, potřebné technické vybavení a případně zajistí objednávku občerstvení. O potřebě občerstvení agent rozhodne na základě pracovních pozic účastníků ve společnosti. Agent také informuje účastníky o detailech meetingu. V případě účasti zaměstnanců z jiných lokalit agent odhadne čas jízdy a vyhledá příslušné spojení, případně předobjedná taxi. Agent dále pomáhá při řízení změn, objednání větší (menší) místnosti, přesun na jiný čas atd. Agent informuje ostatní účastníky o relevantních dokumentech a jejich nových verzích. Porovnáním tématu meetingu s organizační strukturou a jednotlivých zodpovědností agent také navrhne další účastníky. Uvedené příklady naznačují vyuţití agentů v jednoduchém procesu. Přiklad byl inspirován podobnou situací popsanou v (Jennings, et al., 1998). Uţivatelům je dána moţnost volby míry autonomie agenta. Ta omezuje pravomoci agenta. Například agent můţe automaticky posunout termín schůzky maximálně o dvě hodiny, pokud jsou splněny ostatní podmínky. Posunutí o více hodin musí
37
být schváleno organizátorem osobně. Všechny výše uvedené činnosti jsou snadno realizovatelné s vyuţitím sluţeb. Druhou uvedenou variantou je výše zmíněné vyuţití agentů k dynamickému sestavení a změnám workflow procesu. Zhao v (Zhao, et al., 2005) navrhuje kompletní přístup k vyuţití agentů v procesech a jejich řízení. Navrhuje koncept pro modelování procesů i pro vytváření instancí a podporu procesů. Proces chápe jako skupinu autonomních spolupracujících agentů. K popisu jednotlivých agentů vyuţívá mnoţinu profilů agentů (Obrázek 22). Profil obsahuje kompletní popis procesu v XML. Popsány jsou obecné vlastnosti procesu, podmínky vytvoření instance procesu, podmínky běhu a dokončení, ale i zařazení procesu do hierarchie ostatních procesů.
Obrázek 22 Profil agenta (Zhao, et al., 2005)
Všechny procesy jsou postavené na stejné architektuře schematicky popsané na Obrázek 23. Agenty při rozhodování o vykonání akce vyuţívají dva přístupy. První přístup, zdola-nahoru, vychází z analýzy současných podmínek a z ní určuje akce, které je moţno vykonat a směřují k naplnění cíle. Druhý přístup, shora-dolů, představuje proaktivní chování agenta. Od cíle a podmínek jeho naplnění jsou postupně odvozovány akce, vytvářející tyto podmínky. Přístup shora-dolů je vhodný pro plánování. Spolupráce agentů probíhá pomocí tvorby sítí. Po přirazení cíle procesu se první agent, který si myslí, ţe je cíl schopen splnit, se stane členem sítě. Agent stanoví plán činností, a pokud zjistí, ţe pro dosaţení cíle je nutná spolupráce s ostatními agenty, tak iniciuje vyjednávání. Takto postupně probíhá dekompozice cíle, aţ do doby neţ je moţné ho kompletně splnit a je vytvářená síť agentů.(Zhao, et al., 2005)
38
Obrázek 23 Architektura agenta procesu (Zhao, et al., 2005)
Jednou z prvních skutečných implementací ABPM byl systém ADEPT implementovaný ve společnosti British Telecom. V průběhu dalších let došlo k implementaci několika systémů, ale celkově je tato oblast stále ve fázi výzkumu a k velkému rozšíření komerčních aplikací zatím nedošlo, i přesto ţe o tvorbu ABPM či workflow systémů se pokouší řada autorů, ale zatím se většinou jedná o koncepty a ukázková řešení. Reálných implementací v podnicích je mnohem méně, i přesto tato oblast poskytuje velký potenciál rozvoje. 4.1.2.1 Kombinace agentů a business rules Tato kapitola se věnuje vyuţití business rules a agentů v BPM. Zaobírá se moţnostmi vyčlenění logiky z procesů do pravidel a následné vyuţívání pravidel agenty při řízení workflow procesů. Dle definice Business Rules Group business rules (BR) „představují obchodní logiku podnikání a je moţné je definovat jako pravidla, která definují nebo omezují aspekty podnikání. Jsou určena k zajištění podnikatelské struktury a k řízení nebo ovlivňování chování businessu.“ (Business Rules Group, 2000) Jedná se o automatizované rozhodnutí v určité situaci, například předání odchozí objednávky ke schválení nadřízenému, pokud přesáhne určitou částku. Jiným příkladem můţe být procento slevy podle odběru zboţí za určité období. Často jsou business rules vyuţívána v oblastech zpracování objednávky, plánování a vyhodnocování marketingových kampaní, schvalování úvěrů apod. Business rules mohou vyjadřovat různé skutečnosti, od definice samotných pojmů, přes různé omezení aţ po seskupení rozhodovacích pravidel. (Miloš, 2009) Kombinace business rules a vyuţití agentů v řízení procesů poskytuje moţnost zvýšení flexibility business procesů a jejich změn. Z pohledu procesů se BR dají rozdělit do dvou oblastí: BR uplatnitelné v celém procesu 39
BR související s konkrétní činností či rozhodováním BR uplatnitelné v celém procesu jsou průběţně vyhodnocovány po dobu běhu instance procesu. Jedná se o pravidla, které nesouvisí s obsahem právě vykonávané části procesu. Spíše sledují celkový stav procesu, jeho výkonnost, plnění termínů a další ukazatele. Patří sem i integritní pravidla, jejichţ nesplnění vede k nespuštění či pozastavení běhu procesu. Reynolds rozděluje BR pravidla do tří oblastí, podle toho jak ovlivňují proces: (Reynolds, 2009) Pravidla stanovující role a vykonavatele pravidla (routing rules) určují, kdo by měl aktivitu vykonat. Pravidla toku určující, které aktivity by měly být vykonány a v jakém pořadí. Pravidla eskalace určující, co dělat pokud aktivita či proces není dokončen včas. Příkladem můţe být pravidlo: pokud je proces nebo jakákoliv aktivita procesu zpoţděna o více neţ tři dny, tak informuj přímého nadřízeného pracovníka zodpovědného za instanci procesu. BR mohou být společné i pro více procesů. Znovupouţitelnost pravidel je jedním z účelů jejich pouţívání. Druhou skupinou jsou pravidla, která přímo souvisí s vykonávanou aktivitou či rozhodováním. Jedná se o pravidla, která je moţné vyhodnotit aţ v čase, kdy daná aktivita nastane. Příkladem jsou pravidla vyhodnocující nárok na úvěr. Ty jsou automaticky vyhodnocována při schvalování ţádosti. Dalším příkladem je výše slevy dle obratu zákazníka. Kombinace vyuţití BR a agentů v BPM přináší moţnost zvýšení flexibility business procesů. Kaţdá instance procesu by měla svého vlastního agenta. Agenty mohou automaticky sledovat plnění BR souvisejících s celým procesem a v případě porušení vykonat specifikovanou činnost. Cílem je přesunout rozhodování z procesů do BR a ty pokud je to účelné, řídit pomocí agentů. Při rozhodování o tom, kde modelovat rozhodování můţe pomoci Obrázek 24. Ten stručně shrnuje doporučení popsané v článku Muehlena a další (Muehlen, et al., 2008) zabývajícího se problémem, kde a jak modelovat rozhodovací činnost. Rozhodovací úlohu hodnotí pomocí pěti kritérií: frekvence změny, osoby zodpovědné za implementaci, porozumění důsledkům změny, zdroje změny a rozsahu změny. Osoba zodpovědná za implementaci je osoba, která provádí změnu nebo je za její podobu zodpovědná. Důsledek změny je velmi důleţitým faktorem. V případě změny BR není zřetelné, kde všude se změna projeví a jaké to bude mít důsledky. Proto rozhodování, ve kterých změna bude mít závaţné důsledky, by měly být modelovány v procesech. (Muehlen, et al., 2008)
40
Z výše uvedeného vyplývá, ţe v procesech by neměly být přímo modelovány (ne jako odkaz na vyuţití BR) rozhodovací problémy, kde často dochází ke změně a změna má velký, ale předvídatelný dopad.
Obrázek 24 Modelování rozhodování (Muehlen, et al., 2008)
Prvním vyuţitím agentů je kontrola dodrţování integritních a compliance pravidel. Integritní pravidla stanovují základní pravidla fungování businessu, definují základní pojmy a strukturu podnikání. Agenty k tomu učené kontrolují splnění integritních pravidel, dodrţování podnikových směrnic a legislativních poţadavků. Bez nutnosti modelovat kontrolu a dohlíţení nad pravidly přímo v procesech. Tím dochází k zpřehlednění procesů. Dalším vyuţitím je pouţití agentů při určování toku procesu a rolí vykonávajících jednotlivé aktivity. Agent procesu má uloţený referenční model procesu představující běh procesu bez neočekávaných událostí. Cílem agenta procesu je dokončení procesu v jeho správě v poţadované době a kvalitě. Cílem nemusí být vţdy úspěšné dokončení procesu. Pozitivní výsledkem je i nalezení nestandardního průběhu a informování zodpovědné osoby. Míra vyuţití agentů v procesu závisí na jeho důleţitosti, očekávatelnosti změn a jejich dopadu. Od toho se odvíjí role agenta, která můţe být velmi rozmanitá, od informativní přes poradenskou aţ po schopnost přijímat vlastní rozhodování o procesu. Za účelem dosaţení cíle se agent snaţí dosáhnout nápravy, pokud se průběh procesu negativně odlišuje od plánu. Pro hodnocení procesu a jeho průběhu si agent vytváří nebo komunikací s ostatními agenty 41
získává hodnocení procesu jako například: interní rating zákazníka, prioritu procesu, termíny dokončení jednotlivých aktivit dle vzorového modelu procesu, rizikovost procesu. Způsob výpočtu jednotlivých hodnocení procesu můţe být určen pomocí business rules nebo je vyvinut přímo pro agenta v případě sloţitějších metod výpočtu a pouţití nestandardních metod (např.: kombinace více BR a sloţitějších matematických výpočtů, nutnost komunikace s ostatními agenty v systému). Příkladem vyuţití je zkrácení doby aktivit procesů s vyšší prioritou a hodnotou pro společnost. Společnost interně stanovila standardní dobu vyřízení reklamace na dvacet pracovních dnů. Pokud se jedná o pro společnost cenného zákazníka, tak agent automaticky zkrátí dobu vyřízení podle jeho hodnoty na patnáct nebo deset dní. Existuje několik způsobů určení lhůty a jejího zaznamenání v IS. Od jednoduchých, kde lhůta je dána BR tabulkou obsahující interval trţeb zákazníka za poslední rok a tomu odpovídající lhůtu reklamace, aţ po sloţitější varianty, kde jsou kromě objemu trţeb uvaţovány náklady spojené se zákazníkem, jeho platební morálka a další faktory. Agent nemusí tento výpočet provádět sám, hodnoty můţe zjistit například z CRM systému. Rozhodovací BR tabulku agenta by pak tvořily hodnota zákazníka a příslušná lhůta. Jiným vyuţitím je automatické přidání nebo odebrání kontrolních a schvalovacích aktivit nebo změna rolí schvalovatelů a kontrolorů v závislosti na rizikovosti instance procesu a jeho průběhu. Například pokud je proces vyhodnocen jako rizikový, tak musí být jeho průběh zkontrolován odpovědnou osobou. Rizikovost procesu je velmi nejasný termín. Můţe se jednat o riziko nesplnění cíle, riziky ztráty, podvodu ze strany zaměstnance, podvodu ze strany zákazníka a další rizika. Po zjištění typu rizika agent přidá do procesu schvalovací aktivitu s příslušnou rolí schvalovatele. Uvedená situace nalezne vyuţití například při schvalování zaloţení účtu či půjčky v bance. Při podání ţádosti agent automaticky vyhodnotí rizikovost zákazníka a při překročení určitého rizika automaticky přidá do procesu schválení pracovníkem oddělení risku, bez kterého není moţné produkt poskytnout. Dnes je často odpovědnost za schválení ponechána na pracovníkovi pobočky a konzultace s oddělením risku je dobrovolná aţ na specifické situace. Vyuţití agentů přinese větší provázanost jiţ dnes pouţívaných metod hodnocení rizik s procesem schvalování a větší flexibilitu tohoto hodnocení zapojení faktorů jako zkušenosti zaměstnance, délka jeho pracovního poměru, rizikovost oblasti a další faktory. Jiným příkladem je důkladnější kontrola výstupního zboţí určeného důleţitým zákazníkům. Opačným příkladem je naopak přeskočení některých kontrol, pokud je proces ve zpoţdění a jeho dokončení včas je pro firmu velmi důleţité a při jeho nesplnění hrozí společnosti sankce. Například automatická volba draţší rychlejší dopravy, pokud je garantována doba doručení. Tato oblast úzce souvisí s dynamickým 42
plánováním popsaným v další kapitole. Pravidla umoţňující změnu procesu budou uloţena v BR a zpřístupněna oprávněným agentům. Toto rozdělení umoţňuje jednodušší správu a základní změny BR. Tyto změny mohou provádět přímo oprávnění uţivatelé bez zásahu do systému. Cílem vyuţití agentů a BR při modelování a řízení business procesů je, tam kde je to účelné, vyčlenění logiky rozhodování do BR a její řízení pomocí ABPM. Příliš velká přítomnost rozhodování a nestandardních situací vede k znepřehlednění modelů procesů. Zároveň je obtíţně přímo v procesech modelovat sloţitější rozhodování a rozhodovací mapy. Agent procesu se řídí BR a vlastní inteligencí při monitoringu a řízení workflow procesu. Logika rozhodování jako výše zmíněná hodnota zákazníka a výše slevy by měla být uloţena v business pravidlech, ke kterým přistupují procesy i ABPM software. Agenty umoţní i vyčlenění rutinních činností, které jsou společné pro mnoho procesů, jako například notifikace zákazníka pří změně stavu procesu a pokus o opětovnou notifikaci, pokud předchozí pokus selhal. Zde lze vyuţít princip vzorů závazků navrhovaný v (Xing, et al., 2001). Skládáním meta závazků lze vygenerovat postup notifikace. Toto zjednodušení business procesů umoţní se soustředit na hlavní podstatu procesu.
4.1.3 VYUŢITÍ AGENTŮ PRO DYNAMICKÉ PLÁNOVÁNÍ Velký potenciál nabízejí multiagentní systémy v oblastech dynamického plánování (planning) a rozvrhování (scheduling) výroby, přepravy a ostatních činností. Agenty naleznou vyuţití při řešení úloh z oblasti logistiky. Na rozdíl od klasických metod optimalizace jsou schopny pracovat s měnícím se prostředím a externími událostmi z něj přicházejícími. Systém průběţně reaguje na tyto změny a vytváří aktuální plány. Druhou oblastí aplikace je plánování výroby. MAS pro plánování výroby se pokouší zavést i společnost Škoda Auto ve spolupráci s ČVUT (Agent technology center, ATG) a dalšími společnostmi. V oblasti logistiky jiţ systémy vyuţívající agenty k plánování dosáhly komerčních úspěchů. Společnost Magenta úspěšně implementovala MAS pro dynamické plánování cest ropných tankerů, taxisluţby, kurýrní sluţby a v dalších oblastech. (Glaschenko, et al., 2009) Zde bude detailněji představen multiagentní systém určený pro plánování taxisluţby v reálném čase vyvinutí společností Magenta. Systém byl vyvinut pro největší londýnskou taxisluţbu, která denně zpracovává přes 13000 objednávek. Základní proces přepravy zákazníka a jeho podporu agenty znázorňuje Obrázek 26. Základem systému je adaptivní plánování přepravy. Systém plánování funguje v cyklech. V mezidobí jsou poţadavky ukládány do fronty a v dalším kole cyklu jsou poţadavky postupně zpracovány. Při výskytu 43
externí události (nová objednávka, změna statusu řidiče) je znovu vytvořena pouze část plánu dotčená touto změnou. (Glaschenko, et al., 2009). Dalším prvkem pozitivně ovlivňující rychlost systému je zavedení zpoţdění mezi vyhodnocením přirazení v té chvíli optimálního zdroje a sdělením této informace danému zdroji. Během této doby se agenty snaţí dosáhnout ještě lepšího plánu činností. Ale jiţ pouze změna, která povede ke zlepšení plánu, můţe být pro daný zdroj realizována. Ostatní změny jiţ nejsou moţné. Moţnost provádění změn plánu je také omezena pouze do chvíle, neţ je vůz přistaven zákazníkovi. Objednávka i zdroj jsou reprezentovány agenty. V systému působí také další agenty. Nejaktivnějšími jsou agenty objednávek, ty mají na starost výběr vhodných vozidel a také iniciují komunikaci s agenty příslušných zdrojů. Kdykoliv přijde nová objednávka, tak systém automaticky vybere nejlepší zdroj a provede jeho předrezervaci. Rozhodování probíhá na základě pravidel, která zahrnují poţadavky zákazníka, zisk, vytíţenost řidičů a další faktory. Plánování je rozděleno do na sebe navazujících aktivit: příchod objednávky, kontrola moţnosti naplánování objednávky, vytvoření agenta objednávky, předvýběr řidičů, kteří mohou objednávku slnit, ohodnocení kombinací řidič-objednávka získáním nákladů na změnu od agentů, vyhodnocení moţnosti změny plánu. Základní schéma systému zachycuje Obrázek 25. Čas určený pro plánování, během něhoţ probíhá snaha dosáhnout alespoň lokálního optima, objednávky je dynamicky určen na základě typu objednávky, po jeho vypršení jsou informace odeslány vybranému řidiči.(Glaschenko, et al., 2009)
Obrázek 25 Svět agentů (čárkovaná čára znázorňuje první zprávu, plná provázání) (Glaschenko, et al., 2009)
Tento systém je ukázkou úspěšné implementace agentů. Přes 90% objednávek je řidiči přiřazeno automaticky pomocí systému bez nutnosti zásahu dispečinku. Vyuţití agentů pro řešení přiřazovacích úloh je tedy velmi reálné a má jiţ dnes komerční úspěchy. 44
Obrázek 26 Základní proces přepravy zákazníka společně s rozdělením na agenty
45
Obrázek 27 BPMN diagram simulace drive-thru restaurace (Nicolae, et al., 2009)
46
4.1.4 MULTIAGENTNÍ SIMULACE Multiagentní simulace (MA) je jednou z oblastí s největším praktickým uplatněním agentů. MA simulace se vyuţívá od modelování biologických systémů, přes sociální systémy aţ po modelování trhů. Kapitola nejdříve stručně představí důvody simulace a popíše MA simulaci. Druhá část je věnována moţnostem vyuţití MA simulace při modelování business procesů. Proč potřebujeme simulaci? Rozsáhlost a počet vazeb uvnitř systému neumoţňuje jeho plné pochopení jedinou osobou. Komplexita systému skrývá důleţité detaily ovlivňující systém. Nikdo není schopen představit si všechny reálné moţnosti, které systém vykazuje. Za účelem tvorby informovaných rozhodnutí je nutné analyzovat otázky, které přesahují kapacitu mentálních schopností rozhodovatele, i přestoţe můţe mít velmi rozsáhlé zkušenosti se systémem. (North, et al., 2007 pp. 61-62). Úkolem simulace je podpořit schopnost přijmout informované rozhodnutí, ale nejen to. Agentová simulace mimo jiné slouţí k pochopení emergence chování v systému, kde je chování systému formováno zdola jednotlivými interakcemi agentů. Tímto způsobem je moţné identifikovat kauzální vztahy, které nejsou v systému viditelné. MA simulace v oblasti business procesů nalezne vyuţití v analýze procesu samotného a jeho dynamiky. Proces je moţné namodelovat jako MA simulaci, která umoţní postihnout vlastnosti v procesních modelech nezachytitelné. Simulaci je moţné vyuţití i pro analýzu budoucí podoby procesu během reingeneeringu procesů. Jednou z moţných metod tvorby simulace je Agent-Object Relationship modelling (AOR). Principy AOR představuje Wagner v (Wagner, 2003). Autor zde „navrhuje rozdělení objektů na pasivní a aktivní. Oba tyto typy jsou modelovány v diagramu agentů. V diagramech, které se zabývají dynamikou systému, však hrají hlavní roli agenty. Klíčovými koncepty jsou závazek a právo, které k sobě agenty mají navzájem. Dalším konceptem pak je událost. Ta můţe buď vzniknout v prostředí, nebo můţe být vyvolána akcí. Akce se pak dělí na komunikační a nekomunikační. Události pak mohou být buď vnímány, nebo v případě událostí způsobených komunikační akcí vysílány a přijímány. Metoda připouští jak existenci lidských a softwarových agentů, tak i roli agentů institucionálních – sloţených. Kromě diagramu agentů (obdoby diagramu tříd) pak zahrnuje diagram interakčního rámce, který staticky zachycuje základní vztahy pomocí výše uvedených konceptů. Dalším diagramem pak je diagram interakční sekvence, který velmi připomíná sekvenční diagram UML. Nicméně komunikace je opět zachycena pomocí konceptů AOR. Doplňkem pak je interní model jednotlivých agentů.“ (Smolík, 2009) 47
Cílem práce není detailněji popisovat tvorbu MA simulace. Pro více informací odkazuji čtenáře na jinou literaturu. Detailní popis multiagentního modelování a simulací (ABMS) například nabízí kniha Managing Business Complexity (North, et al., 2007), kde se autoři detailně věnují popisu konceptů ABMS, vyuţití a tvorbě simulace. 4.1.4.1 Vyuţití MA simulace v procesním modelování Tato kapitola se věnuje vyuţití MA simulace v procesním modelování. Zaobírá se moţnostmi ověření procesních modelů pomocí simulace a opačným přístupem, kdy je procesní model částečně odvozen z vytvořené MA simulace. Byly identifikovány tři moţné oblasti vyuţití: Vyuţití MA simulace k ověření stávajícího (vytvořeného) procesního modelu. Odvození procesního modelu z vytvořené MA simulace. Nahrazení procesního modelu MA simulací. Jednou z moţností jak ověřit zda procesním model odpovídá reálnému systému je vyuţití multiagentní simulace. První variantou je ověření jiţ existujícího modelu. Zde je velmi problematickým faktorem převod procesního modelu do MA simulace, tak aby simulace odpovídala modelu a nepřidávala do něj nic navíc. Jednou z příčin jsou různé teoretické základy modelování procesů a konceptu agentů, ačkoliv tyto rozpory nemusí být na první pohled viditelné. Model procesů dnes představuje pevně seskupenou skupinu činností, na které je nahlíţeno pohledem ze shora. Procesy jsou vnímány v kontextu událostí, potřebných vstupů a výstupů, cílů procesu a dále. Cíle se hodnotí z pohledu celého procesu. Největší úrovní abstrakce jsou celopodnikové cíle a strategie, ze které jsou poté odvozeny hlavní podnikové procesy. Naopak do větší hloubky a rozpadu cílů na úroveň jednotlivých aktivit a jejich vykonavatelů se pouští minimum analýz. Málokdo se zabývá cíli jednotlivých zaměstnanců vykonávajících proces. Na druhou stranu společný cíl procesu se v pojetí agentů rozpadá na cíle jednotlivých agentů reprezentující vykonavatele procesu. Vzájemná interakce mnoha agentů s jednoduššími cíli a chováním poskytuje skupině inteligentní chování. U MA simulace jsou problémem spíše globální cíle podniku a metody jak zajistit konzistenci agentů s těmito cíly. Zde se nachází hlavní problém vyuţití čisté MA simulace bez kombinace ostatními moţnosti simulace. Otázkou je také jak zajistit převod metrik procesů (KPI) do MA simulace a správnou interpretaci MA simulace a jejich zpětný převod do procesního modelu. Výsledky získané ze simulace musí být prokazatelně zpětně převoditelné a uplatnitelné v procesním modelu. Schéma převodu reálné situace do simulace a převod výsledků simulace do reality 48
zobrazuje Obrázek 28Obrázek 2. Vysoké nároky na kvalitu převodů přináší nutnost formální specifikace transformace procesního modelu do MA simulace. Postupy převodu do a z simulace musí být vzájemně konzistentní. Jedním z moţných řešení je přímá transformace procesního modelu do agentového modelu. Základům této transformace se věnuje kapitola 4.1.5.
Obrázek 28 Převod reality do simulace a zpět (Remondino, 2003)
Opačným přístupem je simulace procesů pomocí diskrétní simulace (DE, Discrete event simulation) nebo Systémové dynamiky (SD, System dynamics). Tyto metody simulace procesů pracují se statickým pohledem na procesy, které vnímají jako pevný řetěz událostí. Takto jsou dnes mnohdy popisovány procesy samotné. Ač je zřejmé, ţe business proces pevně seskupující jednotlivé činnosti ne vţdy odpovídá realitě. Navíc k přechodu mezi stavy jsou vyuţívány rovnice, náhodné generátory a statistické metody, kterými je velmi obtíţné vyjádřit sloţitější podmínky. Na druhou stranu výhodou těchto metod je přímočará a snazší implementace. Není nutné vytvářet speciální model, k vytvoření simulace často stačí detailněji specifikovat jiţ existující procesní model, kdy do procesu je nutné doplnit data, ukazatele a určit výpočet výsledků jednotlivých aktivit a přechodů mezi nimi. Jako lepší řešení se jeví kombinace obou výše zmíněných přístupů, společné pouţití multiagentní a procesní simulace. Remedino v (Remondino, 2003) navrhuje rozdělení organizace do sub-systémů, které mohou být popsány pomocí klasických procesních modelů a nedochází v nich ke komplexním interakcím. Interakce sub-systémů je zajištěna pomocí agentů. Příkladem je společnost provozující dvě výrobní linky, kde druhá linka zpracovává výrobky z první linky. Příklad vychází z příkladu popsaného ve výše zmíněném článku Remedina. Linky nejsou automaticky propojené. Rozpracované výrobky putují z linky 1 do 49
skladu nebo rovnou na linku 2. Před samotným transportem probíhá výstupní kontrola linky 1. Situaci ilustruje Obrázek 29. Propojení linek je simulováno pomocí MA simulace. Změny interních a externích podmínek působí skrze prostředí na agenty a tím i na celý proces.
Obrázek 29 MA procesní simulace (Remondino, 2003)
Agenty naleznou vyuţití při simulaci lidských činností, jednotlivců vytvářejících skupinové chování (trhů), sloţitých strojů, komplexních vztahů, které není moţné dostatečně přesně popsat matematickou či statistickou funkcí, a v podobných případech. Systémová dynamika nalezne vyuţití při dlouhodobém sledování proměnných, situacích, kde nás zajímají agregované údaje. Diskrétní simulace, která je často nazývaná procesně orientovaná simulace, nalezne vyuţití při simulování procesů, jejichţ struktura je definovatelná a přechody mezi jednotlivými částmi nejsou příliš komplexní a dají se vyjádřit pomocí rovnic a generátorů náhodných čísel. Správná kombinace zmíněných přístupů přináší optimální kombinaci „jednoduchosti“ tvorby modelů a jejich souladu s realitou. Tím simulace poskytuje nástroje pro optimalizaci podnikových procesů, ověření jejich úplnosti a také umoţňuje provádění „co-kdyţ“ analýz. Důleţitou podmínkou je podpora hybridní simulace softwarovými nástroji. Jedním z produktů nabízející kombinované simulace je Anylogic z dílny společnosti XJ Technologies. Tutoriál popisují tvorbu kombinované MA a SD simulace je k dispozici v (XJ Technologies, 2008) . Alternativou k tvorbě procesního modelu a následné tvorbě simulace procesů je postup, kdy se nejprve vytvoří MA simulace a z modelu simulace je transformací vytvořen procesní model. Případně je tvorba procesního modelu vynechána úplně a podnik pouţívá dále model MA simulace. Tím dojde k úspoře nákladků při vytváření procesního modelu, jeho opětovné 50
tvorbě a ověřování pomocí simulace. Na druhou stranu je nutné vytvořit kvalitní simulaci, která pokrývá celou společnost. Není takto moţné vytvářet obecně popsané procesy, jejichţ struktura je velmi proměnlivá. Problémem je i neexistence metod tvorby procesního modelu z MA simulace. Další nevýhodou je obtíţnost auditu modelu a problémy při získávání certifikací. Tento přístup bych doporučil pouze ve specifických případech, kde je potřeba zachytit komplexní prostředí firmy a zároveň je dostupný kvalitní model MA simulace.
4.1.5 TRANSFORMACE BPMN DO AGENTOVÉHO MODELU Mezi procesy a vývojem multiagentních systémů dnes existuje jen velmi těsné spojení. Absence tohoto spojení je jedním z faktorů, který brání rozšíření MAS. Tato kapitola nabízí transformaci procesního modelu do agentového systému jako hledaný mezikrok a vhodný nástroj ke zpřístupnění konceptů agentů business analytikům. O transformaci procesního modelu do agentového se pokouší několik autorů. Kaţdý má svůj specifický přístup a málokdy je návrh transformace doprovázen praktickým nástrojem, který by danou transformaci podporoval. Endert a spoluautoři se v (Endert, et al., 2007) pokouší o automatickou transformaci BPMN do BDI agentů. Zmíněný přístup podporuje nástroj vyvinutý v prostředí Eclipse GMF prezentovaný v (Kuster, 2007). Nástroj by měl podporovat automatický export BPMN do JIAC (Java-based Intelligent Agent Componentware). S nástrojem a transformací byly provedeny základní experimenty, ale bohuţel se mi transformace nepodařilo zprovoznit. Instalace proběhla bez problémů, v Eclipse je poté moţné modelovat BPMN 1.1 procesy, ale při pokusu o export do JIAC nebo textové podoby vţdy došlo k chybě. Dalším přístupem je převod grafické podoby BPMN do AOR modelu, prezentovaný v (Pascalau, et al., 2009). Autoři se pokouší o validaci procesu aukce převodem do MA simulace. Přístup vyuţitý v následující kapitole navrhl Urciza a kol v (Urzica, et al., 2009). V článku nejdříve představují transformaci grafické podoby BPMN do její textové podoby. Následně je provedeno mapování textové podoby procesu na textovou notaci UML, představenou v (Winikoff, 2005). Nakonec je provedena transformace z textové podoby do diagramů. Jednotlivé čási BPMN diagramu mají své specifické mapování. Základní prvky mapování představuje následující výčet. (Urzica, et al., 2009) Bazén je namapován jako agent.
51
Aktivity jsou spouštěny interně agentem, proto nejsou součástí mapování interakčních diagramů. Událost – zpráva je namapována jako zpráva v AUML (message od komu jméno). Časová událost není mapována, je kontrolována interně. Brána je mapována jako box příslušného druhu. Detailněji bude transformace popsána v následující kapitole společně se samotnou transformací namodelovaných procesů do interakčních diagramů. Oblast automatické transformace procesního modelu do agentového modelu je zatím ve fázi výzkumu. Jedná se o ne moc prozkoumanou oblast, kde je potřeba provést ještě mnoho práce. Tvrzení o aktuálnosti výzkumu je podpořeno i daty vzniku citovaných dokumentů. Velký potenciál v oblasti transformace BPMN přináší plánovaná specifikace 2.0, kde je grafický model reprezentován v XML. To povede k odstranění hledání textové notace pro BPMN a umoţní se plně soustředit na mapování samotné. Transformace nalezne vyuţití v oblastech, kde je třeba vytvořit multiagentní systém na základě procesního modelu. Příkladem vyuţití je pouţití transformace při tvorbě MA simulace procesů. Transformace přispívá k větší konzistenci mezi procesním modelem a simulací. Zajímavou oblastí k rozvoji je problematika transformace pr. model – simulace – pr. model. Částečně se problematikou round-trip transformace zabývá Kuester v (Kuster, 2007).
5 PŘÍPADOVÁ STUDIE Tato kapitola slouţí k ilustraci dříve diskutovaných moţností vyuţití na ukázkovém příkladě. Nejprve je slovně i procesním modelem představená příkladová společnost. Následně jsou diskutovány moţnosti vyuţití agentů v dané společnosti a nakonec je provedena transformace BPMN diagramů do interakčních AUML diagramů. Jedná se o fiktivní společnost provozující veřejné aukce aut v reálném čase určené široké veřejnosti. Tento systém prodeje aut je velmi populární v Japonsku a částečně i v USA, ale tam jsou aukce většinou zaměřeny na zákazníky z řad dealerů. V České republice se autorovi společnost provozující aukce určené veřejnosti nepodařilo vypátrat. Většina prodávaných vozidel je přímo vlastněná aukční společností. Aukce probíhá jedenkrát týdně v sobotu. V průměru je nabízeno 130 vozidel k prodeji. Fyzické prohlídky aut jsou moţné den před aukcí a v den aukce před jejím začátkem. Kaţdé vozidlo je vybaveno technický popisem včetně vyvolávací ceny (ukázka viz Příloha 2 – 52
kontrolní list). Obrázek 30 zobrazuje základní mapu procesů společnosti. Cyklus aukce začíná nákupem vozů, poté je aukce technicky připravována a zároveň jsou připravovány jednotlivé vozy. Přípravy zakončuje plán aukce, ve kterém jsou prodávaná auta zveřejněna na internetu i v prostorách firmy. Proces přípravy a plánování aukce je znázorněn na Obrázek 31. Zájemci o účast v aukci se musí dopředu zaregistrovat. Cena za registraci je 200,- Kč. Aukce je moţné se zúčastnit i online pomocí aukčního software. Software nabízí sluţbu robota, který automaticky přihazuje cenu vybraného vozu do stanovené maximální ceny aukcionářem. Došlé elektronické nabídky jsou monitorovány pracovníkem přítomným přímo v místnosti aukce, který předává nabídky osobě řídící aukci. Aukce probíhá v reálném čase. Postupně jsou za sebou nabízeny jednotlivé vozy. Aukce kaţdého vozu začíná jeho představením, zařazením do příslušné kategorie, poté jiţ začíná samotná aukce. Všechny vozy mají stanovenou minimální prodejní cenu, která není veřejně známá, a počáteční vyvolávací cenu, která je vyšší neţ minimální cena. Cena auta začíná na vyvolávací ceně a postupně v případě nabídky nová cena narůstá o částku stanovenou řídící osobou. V případě, ţe vyvolávací cena není nikým nabídnuta, tak dojde k jejímu sníţení. Tato situace se opakuje, dokud není nabídnuta vyvolávací cena, nebo vyvolávací cena není rovna minimální ceně. V tomto případě je aukce ukončená jako neúspěšná. Pokud je nabídnuta vyvolávací cena, tak je zaznamenán nabízející a po zpracování nabídky je stanovena a vyhlášena nová cena draţeného auta.
Obrázek 30 Základní schéma procesů
53
Pokud se do dvou minut neobjeví nová nabídka, tak dojde k ukončení aukce ukončena a je vyhlášen vítěz. V tu chvíli začíná nová aukce vytvořením nové instance procesu aukce. Proces aukčního dne je zobrazen na Obrázek 32. Stav aukce je sledován v sekvenčně opakujícím se procesu, který probíhá jako „for each“ cyklus naplánovaných aukcí. Po ukončení poslední aukce je vytvořena závěrečná zpráva hodnotící úspěšnost dne a nově vzniklé závazky.
Obrázek 31 Proces přípravy aukce
Proces detailního průběhu aukce je k dispozici na Obrázek 33. Pro lepší čitelnost je diagram rozdělen na dvě části. Pod-proces platba a sluţby je v první části zabalen. Vítěz aukce je povinen ihned sloţit zálohu. V případě vítěze účastnícího se přes internet je záloha automaticky strţena z jeho kreditní karty. V případě ţe nedojde k úhradě, je výsledek aukce anulován a záleţí na provozovateli, zda bude poţadovat náhradu škody. Po přijetí zálohy jsou s vydraţitelem dojednány volitelné dodatečné sluţby a je vypočtena finální cena za aukci včetně všech poplatků (poplatek z výhry, administrativní poplatek). Pokud základní úhrada není uhrazená ve stanoveném termínu, tak dojde ke zrušení aukce a záloha propadá provozovateli. Vozidlo nebude vítězi předáno, pokud má nějaký závazek vůči provozovateli i z titulu dodatečně objednaných sluţeb.
54
Obrázek 32 Proces: průběh aukčního dne
55
56
Obrázek 33 Proces: průběh aukce (z důvodu přehlednosti je rozdělen na dvě části, pokračování na další straně)
57
5.1 Moţnosti vyuţití agentů v modelované společnosti Tato kapitola diskutuje různé moţnosti vyuţití agentů ve zde představené společnosti. První oblastí je řízení aukce agentem a s tím související moţnost vyuţití dynamického výpočtu nové vyvolávací ceny a navýšení v průběhu aukce dle vývoje situace během dne. Agenty je moţné vyuţít v mnoha procesech. V první fázi se jeví vhodné vyuţít agenty při tvorbě plánu aukce a vyvolávacích cen. Agent pomáhá při sestavování plánu aukce. Agent automaticky zjistí cenu podobného vozu v registrech automobilů a v historii aukcí. Pro podporu plánování je navrhnuto rozšířit registrace účastníků o vyjádření preferovaných vozů z nabídky. Kaţdý účastník by měl moţnost zvolit tři poţadované vozy. Za účelem motivace účastníků k vyjádření preferencí bude v případě vydraţení preferovaného vozu zákazníkovi poskytnuta sleva z výsledné ceny. Tímto krokem agent získá základní přehled o poptávce a atraktivnosti jednotlivých vozů. To je společně s minulými zkušenostmi vyuţito pro optimální rozdělení vozidel do jednotlivých částí aukce. S touto oblastí těsně souvisí vyuţití multiagentní simulace. Pro otestování výše uvedeného způsobu plánování je nutné vytvořit simulaci aukce. Simulace je také vhodné prostředí k provádění „co-kdyţ“ analýz a testování, jak zaváděné změny ovlivní chod společnosti. Zvaţovanými změnami mohou být například: zavedení online video prohlídek, vzdálené představení auta bez jeho fyzické přítomnosti v aukci místnosti, změny struktury poplatků a další. Bylo by vhodné analyzovat dopad technologických změn diskutovaný v (National Auto Auction Association, 2006) na zisk firmy. Poslední oblastí vyuţití je personální agent účastníků aukce, který je schopen účasti v aukci a automaticky vyhledává vhodné vozy.
5.2 Transformace do agentového modelu Tato kapitola se věnuje praktické transformaci namodelovaných BPMN diagramů do agentového modelu. Jednotlivé procesy jsou transformovány do interakčních diagramů. Textové notace a jejich grafické reprezentace byly vytvořeny v programu Prometheus Design Tool (PDT) postavený na platformě Eclipse, který slouţí k designu a vývoji multiagentních systémů. Metodologie Prometheus popisuje celý vývojový cyklus MAS od globální analýzy aţ po generování kódu. Detailně je popsána v (Padgham, et al., 2004). Pro transformaci do agentového modelu byla pouţita metodika navrţená Urzicou popsaná v (Urzica, et al., 2009), která je stručně představená v kapitole 4.1.5. Kaţdá dráha bazénu byla 58
přetvořena v agenta, navíc byl do systému přidán agent manaţer, schvalující nabídku aukce. Mapování popsané ve zmíněné kapitole bylo rozšířeno o následující prvky: Cesta zpět v procesu tvořící potenciální smyčku je mapována jako skok v sekvenčním diagramu (label a goto label). Podmínka příliš nízké vyvolávací ceny končící aukci je mapována jako break box, který ukončí běh celého interakčního diagramu. Podmínky bran a ostatní podmínky jsou mapovány jako guard. Nepřerušující událost je mapována pomocí opt boxu (volitelný) obsahujícího reakci na danou událost. Opakující se pod-proces je mapován jako běţný loop box. Nejprve byla vytvořená textová verze interakčních diagramů viz níţe a z nich pomocí softwarového nástroje grafická reprezentace. Textová notace interakčního diagramu AUML aukce: start aukce agent auk agent_aukce agent uc agent_ucastnik agent den agent_aukcniho_dne message den auk start-aukce message auk uc info-auto label vyv-cena box break guard [posl.vyv.cena=min.cena] message auk den konec aukce end break message auk uc vyvolavaci-cena box alt message uc auk nabidka next guard [2-min] goto vyv-cena end alt label navysena cena message auk uc navysena cena box alt message uc auk nabidka goto navysena cena next guard [2-min] message auk uc vyhlaseni viteze end alt message auk den konec aukce finish
Grafická reprezentace kódu je zobrazena na Obrázek 36. Transformace procesu průběh aukce byla provedena do části ukončení aukce. Uplatnění agentů ve zbylé části procesu je velmi obtíţné, a proto je zbytečné převádět zbývající část procesu do interakčních diagramů. Ostatní textové modely jsou přiloţeny v příloze 1. Zde jsou zobrazeny pouze jejich výsledné grafické reprezentace. 59
Obrázek 34 Interakční diagram: příprava aukce
60
Obrázek 35 Interakční diagram: aukční den
61
Obrázek 36 Interakční diagram: aukce
Uvedená transformace by mohla slouţit jako spojující prvek týmu zodpovědného za vývoj MAS a ostatními členy IT týmu a jako základní vstupní prvek při tvorbě MAS. Provedená transformace se soustředí na komunikaci v rámci procesu a s externími subjekty. Nejsou v ní transformovány vnitřní stavy agentů a celkový model agentů vyjádřený class diagramem. O tyto oblasti je nutné transformaci rozšířit. Nejspíše bude nutné do modelu procesu doplnit některé charakteristiky potřebné k transformaci do agentové modelu. Problém 62
například nastává při určení prostředí, které stejně jako agenty můţe být představováno bazénem. V kontextu BPMN je vhodné s těmito kroky počkat na oficiální přijetí verze 2.0, jejíţ součástí je výše zmíněný kompletní XML reprezentace všech diagramů.
6 ZÁVĚR Práce analyzovala moţnosti vyuţití agentů v modelování business procesů a ostatních oblastech. Byl ukázán široký potenciál vyuţití agentů, kde i počet dostupných pramenů svědčí o aktuálnosti tématu. Avšak většina prací se věnuje teoretickým konceptům. Praktické implementace zatím nejsou moc rozšířené, kromě oblasti plánování a multiagentní simulace. I přestoţe věci nazývají jinými jmény, je si mnoho autorů ve svých přístupech podobno. Tento fenomén se nejvíce projevuje v oblasti ABPM. Nyní budou shrnuty výsledky analýzy jednotlivých vyuţití. Vyuţití agentů v oblasti dokumentace procesů se nezdá reálné. Zde postačují dnes pouţívané notace, které kvalitně zachycují statický pohled na proces. Naopak namodelováním procesu s vyuţitím agentů dojde k potlačení ilustrativních statických vlastností a společně s malým rozšířením povědomí o agentech vede vyuţití agentů v modelování za účelem dokumentace spíše ke zhoršení situace. Navíc agentové modely jsou jen velmi těţkou auditovatelné. Vyuţití agentů v oblasti analýzy a optimalizace procesů poskytuje mnohem větší potenciál. Zde nalezne vyuţití především multiagentní simulace. Simulace vyuţívající agenty jsou jiţ dnes velmi rozšířené a nacházejí uplatnění v čím dál více oblastech. V oblasti modelování procesů naleznou agenty vyuţití v identifikaci procesů samotných, ale i v analýze, experimentech s budoucími stavy procesů a při validaci procesů. Simulaci je moţné vyuţít k odhalení dynamiky procesu a emergence chování uvnitř systému, které jsou promocí běţných postupů modelování procesů těţko objevitelné. Omezením vyuţití simulace je náročnost jejího vývoje a neexistence jednotného metodického základu. Multiagentní simulace téměř vţdy přesáhne rozsah jednoho procesu. Pro získání důvěryhodnosti simulace je nutné vytvořit věrohodný model současné reality. Jinak bude velmi obtíţné prosadit závěry ze simulace vyplývající, i kdyţ mohou být pro společnost přínosné. K tvorbě MA simulace je moţné vyuţít několik různých obecných metodologií (př. AOR), ale nástroje slouţící k implementaci simulace jsou většinou svázány s jedním jazykem. Na druhou stranu výběr nástrojů je opravdu široký: NetLogo, Anylogic Repast, Swarm, nástroje vyuţívající platformu JAVA a další. 63
Hybridní simulace pouţívající prvky diskrétní simulace, systémové dynamiky a agentů se jeví jako vhodný kompromis mezi „jednoduchostí“ a přímočarostí tvorby diskrétní simulace a přínosy vyuţití agentů v simulaci. Agenty by měly nahradit diskrétní simulaci v simulaci lidí, skupin lidí, komplexních problémů a sloţitých přechodů mezi aktivitami. Většímu rozšíření MA simulace v oblasti podnikových procesů by pomohla přímá podpora tvorby hybridní simulace v CASE nástrojích podporujících modelování procesů. Jiţ dnes jsou do některých nástrojů zabudovány moţnosti simulace procesu přímo z diagramu, po jeho patřičném doplnění informacemi potřebnými pro spuštění. Pokud by se podařilo naimplementovat i podporu multiagentní simulace, došlo by k růstu vyuţití a reálnosti simulace procesů. Pokud se nepodaří vloţit podporu přímo do CASE nástroje, je vhodné alespoň zabudovat automatické transformace do agentového modelu, který bude dále rozvíjen v jiných nástrojích přímo určených k MA simulaci, například programu Anylogic, který podporuje tvorbu hybridní simulace. Vyuţití agentů v modelování a tvorbě spustitelných procesů skrývá dle autora velký potenciál, ačkoliv je tato oblast zatím spíše ve fázi výzkumu neţ reálného vyuţití. Vyuţití agentů lze rozdělit do dvou oblastí. První je osobní agent uţivatele ABPMS, který uţivateli pomáhá automatizací některých, z počátku snadno implementovatelných, úloh. Příkladem můţe být automatické domluvení termínu schůzky a s tím související úkoly zarezervování potřebné místnosti, techniky, příprava osnovy setkání a další činnosti. Pro vývoj v této oblasti je moţné se inspirovat nástroji určenými k customizaci webových portálů. Druhou oblastí je vyuţití agentů v oblasti dynamického řízení procesů a workflow. Agent mající na starost řízení procesu je schopen v případě potřeby dynamicky změnit pořadí aktivit procesu či aktivitu přidat nebo odebrat. Tento stupeň inteligence agenta je realizovatelný v blízké budoucnosti. Další fází vývoje je kompletní tvorba toku procesu agentem samotným na základě jeho vlastní inteligence a interakcí s ostatními agenty. Kombinované vyuţití business rules a agentů umoţní zvýšení flexibility procesů řízeným pomocí BPMS. Část logiky rozhodování je z procesů vyčleněna do bus. pravidel, které jsou vyuţívány agenty v ABPMS. Business rules jsou mnohem bliţší uţivatelům neţ agenty. Pokročilý uţivatel je schopen sám provádět změny pravidel a tím ovlivňovat chování proceu. ABPM se zabývá mnoho autorů. Závěrem studia jednotlivých pramenů je, ţe v základních principech se většina autorů shoduje a rozdíly nastávají v detailech a přístupech implementaci, pokud je vůbec autorem moţná implementace popisována. Aţ na pár výjimek (např.: British
64
Telecom) je vyuţití agentů v této oblasti modelování podnikových procesů v podnicích minimální. Vyuţití agentů pro validaci business procesů je komplikováno velkou rozdílností dnes běţně pouţívaných metod modelování procesů a konceptem agentů. I přesto, ţe toto vyuţití se mi od počátku jevilo jako velmi slibné, tak na závěr musím konstatovat opak. Komplikaci vyuţití způsobují nové vlastnosti vnášené agenty do modelu procesu. Zachování konzistence mezi modely můţe pomoci přímá transformace procesního modelu do simulace, kterou bude proces validován. Agenty lze a dokonce je nutné je vyuţít k validaci agentově namodelovaných procesů prostřednictvím MA simulace. I ostatní agentové systémy je vhodné ověřit pomocí agentové simulace. Transformace procesního model do agentového je vhodný spojovací prvek oblasti business procesů a vývoje multiagentních systémů. Ukázka transformace BPMN do interakčních diagramů byla provedena v kapitole 5. I přes omezení, které tento přístup vnáší do analýzy MAS (přílišné soustředění se na původní proces), myslím, ţe je to jeden z prvků jak zvýšit zainteresovanost ostatních členů organizace (schvalovatelé projektů, sponzoři projektů, klíčový uţivatelé a další) v oblasti agentů a zároveň vede k posílení důvěry ke konceptu agentů z důvodu lepší představitelnosti moţností agentů, i kdyţ neúplných. Na druhou stranu to můţe vést k nabytí dojmu, ţe agenty jsou jen nadstavba nad současnými procesy. Věřím, ţe se mi podařilo naplnit základní cíl práce, analyzovat moţnosti vyuţití agentů v oblasti business procesů. Identifikoval jsem jednotlivé oblasti moţného vyuţití a potenciál agentů v jednotlivých oblastech. Jako nejvíce slibné vidím kombinaci agentů s business rules a vyuţití hybridní simulace, pokud dojde k její podpoře více softwarovými nástroji. Dále jsem rozšířil mapování BPMN do textové notace AUML představené v (Urzica, et al., 2009) o další prvky a provedl jsem ukázkovou transformaci namodelovaných procesů společnosti provozující veřejné aukce aut do interakčních diagramů. Další oblastí rozvoje je praktický rozvoj navrhovaných vyuţití a pokus o jejich implementaci v softwarovém řešení. Potenciál vyuţití transformace zvyšuje XML pozadí nově chystané specifikace BPMN 2.0.
65
7 BIBLIOGRAFIE Anthes, Gary. 2003 . Agents of Change. Computerworld. [Online] Leden 27, 2003 . [Cited: Květen 8, 2010.] http://www.computerworld.com/s/article/77855/Agents_of_Change. Autoaukce, s.r.o. 2010. Protokol - 31025662. [Online] duben 2010. [Citace: 30. duben 2010.] http://www.autoaukce.cz/Protokol/2010042931025662.pdf. Bauer, Bernhard and Odell, James. 2005. UML 2.0 and Agents: How to Build Agent-based Systems with the new UML standard. Journal of Engineering Applications of Artificial Intelligence. 2005, Vol. 18, 2, pp. 141-157. BPM Portál. 2008. Procesní řízení Business Process Management. [Online] 2008. http://bpm-slovnik.blogspot.com/2008/04/bpm.html. Bubeník, Jan. 2006. NEURAL NETWORK IN AGENT SYSTEM. 2006. Business Rules Group. 2000. Defining Business Rules ~ What Are They Really? 2000. http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf. Dillon, Darshan, Dillon, Tharam S. and Chang, Elizabeth. 2008. Use of UML 2.1 to Model Multi-Agent Systems. s.l. : Lecture Notes In Computer Science; Vol. 5287, 2008. Endert, Holger, et al. 2007. Mapping BPMN to Agents: An Analysis. 2007. Glaschenko, Andrey, et al. 2009. Multi-Agent Real Time Scheduling System for Taxi Companies. AAMAS 2009 - 8th International Conference on Autonomous Agents and Multiagent Systems. 2009. Grundspenkis, Janis and Pozdnyakov, Dmitrij. 2006. An Overview of the Agent Based Systems for the Business Process. International Conference on Computer Systems and Technologies - CompSysTech’06. 2006. Chang, Jin W. and Scott, Colin T. 1996. Agent-based workflow: TRP Support Environment (TSE). Computer Networks and ISDN Systems 28. 1996. Chopra, Amit K. and Singh, Munindar P. 2004. Commitments for Flexible Business Processes. s.l. : Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems - Volume 3, 2004. Ipser, Jaroslav. 2008. BP: Informační portál pro multiagentní technologie. místo neznámé : FI MUNI, 2008. Jennings, Nick and Faratin, Paul. 1998. AGENT-BASED BUSINESS PROCESS MANAGEMENT. 1998. 66
Kubík, Aleš. 2004. Inteligentní agenty: tvorba aplikačního software na bázi multiagentových systémů. Brno : Computer Press, 2004. Kuster, Tobias. 2007. Development of a Visual Service Design Tool. s.l. : Technical University of Berlin, 2007. Kvapilík, Jan. 2006. Bakalářská práce: Modelování podnikových procesů. místo neznámé : MASARYKOVA UNIVERZITA, 2006. Lange, Danny B. and Oshima, Mitsuru. 1998. Programming and Deploying Java Mobile Agents Aglets. s.l. : Addison-Wesley Longman Publishing, 1998. Miloš, Martin. 2009. Seminární práce k předmětu 4IT410. místo neznámé : VŠE, 2009. Muehlen, Michael zur, Indulska, Marta and Kittel, Kai. 2008. Towards Integrated Modeling of Business Processes and Business Rules. s.l. : 19th Australasian Conference on Information Systems, 2008. National Auto Auction Association. 2006. TECHNOLOGY IS CHANGING THE MARKETPLACE. 2006. http://www.naaa.com/files/public/TechnologyChange.pdf. Netrvalová, Arnoštka. 2006. Úvod do problematiky multiagentních systémů. místo neznámé : ZČU v Plzni, 2006. Nicolae, Oana and Wagner, G. 2009. Simulation Model: A drive-through restaurant with a menu board, a kitchen and a pickup. [Online] 2009. http://oxygen.informatik.tucottbus.de/aor/?q=node/20. North, Michael J. and Macal, Charles M. 2007. Managing Business Complexity: Discovering Strategic Solutions with Agent-Based Modeling and Simulation. s.l. : Oxford University Press, 2007. Odell, James J., Bauer, Bernhard and Parunak, H. Van Dyke. 2000. Representing Agent Interaction Protocols in UML. 2000. OMG.
BPMN
Elements
and
attributes.
[Online]
[Cited:
Duben
5,
2010.]
http://www.bpmn.org/Documents/BPMN_Elements_and_Attributes.pdf. —. 2009. Business Process Model and Notation (BPMN):FTF Beta 1. [Online] 2009. Padgham, Lin and Winikoff, Michael. 2004. Developing Intelligent Agent Systems: A Practical Guide. s.l. : John Wiley and Sons, 2004. Pang, Gian. 2000. Implementation of an Agent-Based Business. s.l. : Universität Zürich, 2000.
67
Pascalau, Emilian, Giurca, Adrian and Wagner, Gerd. 2009. Validating Auction Business Processes using Agent-based. 2009. Pěchouček, Michal and Mařík, Vladimír. 2008. Industrial deployment of multi-agent technologies: review and selected case studies. International Journal on Autonomous Agents and Multi-Agent Systems. 2008. Regev, Gil, Soffer, Pnina and Schmidt, Rainer. 2005. Taxonomy of Flexibility in Business Processe. s.l. : Produced as a result of the BPMDS’05 workshop, 2005. Remondino,
Marco.
2003.
AGENT
BASED
PROCESS
SIMULATION
FOR
MANAGEMENT AND. 2003. Reynolds, John. 2009. Process rules why BPMN isn´t enough. [Online] February 3, 2009. [Cited: Červen 18, 2010.] http://thoughtfulprogrammer.blogspot.com/2009/02/process-ruleswhy-bpmn-isn-enough.html. Řepa,
Václav.
Business
process
metamodel.
Opensoul.
[Online]
http://opensoul.panrepa.org/bpm.html. —. 2007. Podnikové procesy: Procesní řízení a modelování. Praha : Grada, 2007. —. 2008. Řízení procesů versus procesní řízení. BPM portál – téma měsíce, 4/2008. [Online] 2008. [Citace: 01. 04 2010.] Shannon, Robert E. 1998. INTRODUCTION TO THE ART AND SCIENCE OF SIMULATION. s.l. : Proceedings of the 1998 Winter Simulation Conference, 1998. Silver, Bruce. 23. 5 Things to Love About BPMN 2.0. BPMS Watch. [Online] 2009. Březen 23. [Citace: 2010. duben 5.] http://www.brsilver.com/wordpress/2009/03/26/5-things-to-loveabout-bpmn-20/. —. 2009. BPMN Method & Style. s.l. : Cody-Cassidy Press, 2009. —. 2010. UNITING PROCESS ARCHITECTURE AND EXECUTION. s.l. : Bruce Silver Associates, 2010. Smolík, Jan. 2009. Možnosti modelování procesů v multiagentních. 2009. Šalamoun, Tomáš. 2009. Studijní materiály k předmětu 4IT495: Simulace societálních jevů. 2009. Urzica, Andreaa and Tanase, Claudiu. 2009. Mapping BPMN to AUML: Towards an automatic process. 2009.
68
Wagner, Gerd. 2003. The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behavior. Information Systems 28. 2003. Wikipedia. 2010. Objektově orientované programování. [Online] 28. březen 2010. [Citace: 3. květen
2010.]
http://cs.wikipedia.org/wiki/Objektov%C4%9B_orientovan%C3%A9_programov%C3%A1n %C3%AD. Winikoff, M. 2005. Towards making Agent UML practical: A textual notation and a tool. s.l. : Proc. of the 1st International Workshop on Integration of Software Engineering and Agent Technology (ISEAT 2005), 2005. Wongthongtham, Pornpit, a další. 2008. Use of UML 2.1 to Model Multi-Agent Systems based on a Goal-driven Software Engineering Ontology. místo neznámé : 2008 Fourth International Conference on Semantics, Knowledge and Grid, 2008. —. 2008. Use of UML 2.1 to Model Multi-Agent Systems based on a Goal-driven Software Engineering Ontology. s.l. : 2008 Fourth International Conference on Semantics, Knowledge and Grid, 2008. Wooldridge, Michael. 1999. Intelligent Agents In G. Weiss, editor: Multiagent Systems. Boston : The MIT Press, 1999. http://www.csc.liv.ac.uk/~mjw/pubs/mas99.pdf. Xing, Jie, et al. 2001. A Commitment-Based Approach for Business Process Interoperation. s.l. : A Commitment-Based Approach for Business Process Interoperation, 2001. XJ Technologies. 2008. How to Build a Combined Agent Based / System Dynamics Model in AnyLogic. Tutorial based on the materials of AnyLogic workshop, System Dynamics Conference 2008. [Online] 2008. http://www.xjtek.com/anylogic/articles/. Zádová, Vladimíra. 2008. Business Rules přístup v návrhu informačních systémů. místo neznámé : Sytémová integrace 2008, 2008. Zhao, Xinpei, Chan, Keith and Li, Mingshu. 2005. Applying Agent Technology to Software Process Modeling and Process-Centered Software Engineering Environment. 2005 ACM Symposium on Applied Computing. 2005.
69
8 TERMINOLOGICKÝ SLOVNÍK Termín
Zkratka
Význam „část komplexních adaptivních systémů provádějící
Agent
rozhodování. Kaţdý agent má vlastní sadu pravidel, které
mu
umoţňují
přijímat
informovaná
rozhodnutí. Agent má schopnost učení se a adaptace“ (North, et al., 2007 p. 24). Agent
Unified
Modelling AUML
Rozšíření jazyka UML slouţící k modelování MAS
Language Business process modelling BPMN
BPMN je standardem pro modelování podnikových
notation
procesů vytvořený původně konsorciem BPMI.
(od
verze
2.0
Business process model and
Dnes
notation)
management group (OMG).
Business process management
BPM
se
o
rozvoj
stará
organizace
Object
Business Process Management (BPM), česky procesní řízení je manaţerská disciplína a současně technologie vyuţívající pro procesně orientované řízení podniku jeho architekturu podnikání.(BPM Portál, 2008)
Business process management BPMS
Softwarová řešení podporující BPM
suite Business rules
BR
Business
rules
představují
obchodní
logiku
podnikání a je moţné je definovat jako pravidla, která definují nebo omezují aspekty podnikání. Jsou určena k zajištění podnikatelské struktury a k řízení nebo ovlivňování chování businessu. (Business Rules Group, 2000) Multiagentní systém
MAS
Informační systém postavených na principech agentů
Proces
ISO 9000 definuje proces jako „soubor vzájemně souvisejících nebo vzájemně působících činností,
70
který přeměňuje vstupy na výstupy.“ Simulace
Simulace je proces tvorby modelu reálného systému a provádění experimentů s tímto modelem za účelem dosaţení lepšího pochopení studovaného systému či za účelem posouzení různých variant činnosti systému(Shannon, 1998)
Validace
Validací se rozumí ověření toho, zda model věrně reprezentuje
původní
systém
nebo
systém
zamýšlený.
9 SEZNAM OBRÁZKŮ, TABULEK A DIAGRAMŮ Tabulka 1 Počáteční události v BPMN 2.0 ........................................................................................................ 8 Tabulka 2: Srovnání abstrakce objektů a agentů (Kubík, 2004 str. 13) ............................................................13 Tabulka 3 Přehled domén využití agentů (Pěchouček, et al., 2008) .................................................................31
Diagram 1 Počáteční, vnitřní a koncové události v BPMN ................................................................................ 8 Diagram 2 Přerušující a nepřerušující událost .................................................................................................. 9 Diagram 3 Úlohy: běžná, opakující se, násobná – paralelní, násobná - sekvenční a pod-proces ......................10 Diagram 4 Brány v BPMN: základní, paralelní, XOR, událost, OR join (nebo), komplexní brána ......................11 Diagram 5 Podmíněný a defaultní tok .............................................................................................................11 Diagram 6 Toky zpráv mezi bazény .................................................................................................................12 Diagram 7 Neorientovaná a orientovaná asociace ..........................................................................................12
Obrázek 1 Základní schéma podnikového procesu (Řepa, 2007 str. 15) ........................................................... 3 Obrázek 2 Obecné schéma podnikového procesu (Kvapilík, 2006) ................................................................... 4 Obrázek 3 Business process metamodel (Řepa) ............................................................................................... 5 Obrázek 4 XML schéma aktivity (OMG, 2009) .................................................................................................. 7 Obrázek 5 Události v BPMN (OMG, 2009) ........................................................................................................ 9 Obrázek 6 Architektura softwarového agenta (Netrvalová, 2006) ..................................................................15 Obrázek 7 Schéma deliberativního agentu (Kubík, 2004 str. 15) .....................................................................17 Obrázek 8 Architektura GRATE(Kubík, 2004 str. 60) ........................................................................................18 Obrázek 9: Schéma hybridního agenta (Bubeník, 2006) ..................................................................................19 Obrázek 10 Schéma reaktivní komunikace (Kubík, 2004 str. 81) .....................................................................20
71
Obrázek 11 Příklad komunikačního diagramu na základě šablony FIPA (Odell, et al., 2000)............................22 Obrázek 12 Nově vytvořený balíček po dosazení hodnot předchozího obrázku (Odell, et al., 2000) ..............23 Obrázek 13 Základní formát sekvenčního diagramu .......................................................................................24 Obrázek 14 Stejná situace zobrazená v diagramu spolupráce (nahoře) a sekvenčním diagramu (dole) (Odell, et al., 2000) ............................................................................................................................................24 Obrázek 15 Diagram aktivit: zpracování objednávky uvnitř agenta (Odell, et al., 2000) ..................................25 Obrázek 16 Vnitřní statechart diagram jednotlivých agentů ...........................................................................26 Obrázek 17 Sekvenční diagram využívající porty (Dillon, et al., 2008) .............................................................27 Obrázek 18 Diagram vnitřní struktury agenta smlouva z předchozího obrázku (Dillon, et al., 2008) ...............28 Obrázek 19 Možné změny v business procesu (Regev, et al., 2005) ................................................................33 Obrázek 20 Business proces s použitím agentů (Grundspenkis, et al., 2006) ...................................................34 Obrázek 21 Architektura BPMS (Silver, 2010) .................................................................................................36 Obrázek 22 Profil agenta (Zhao, et al., 2005) ..................................................................................................38 Obrázek 23 Architektura agenta procesu (Zhao, et al., 2005) ..........................................................................39 Obrázek 24 Modelování rozhodování (Muehlen, et al., 2008) .........................................................................41 Obrázek 25 Svět agentů (čárkovaná čára znázorňuje první zprávu, plná provázání) (Glaschenko, et al., 2009) ..............................................................................................................................................................44 Obrázek 26 Základní proces přepravy zákazníka společně s rozdělením na agenty .........................................45 Obrázek 27 BPMN diagram simulace drive-thru restaurace (Nicolae, et al., 2009) ..........................................46 Obrázek 28 Převod reality do simulace a zpět (Remondino, 2003) ..................................................................49 Obrázek 29 MA procesní simulace (Remondino, 2003) ...................................................................................50 Obrázek 30 Základní schéma procesů .............................................................................................................53 Obrázek 31 Proces přípravy aukce ..................................................................................................................54 Obrázek 32 Proces: průběh aukčního dne .......................................................................................................55 Obrázek 33 Proces: průběh aukce (z důvodu přehlednosti je rozdělen na dvě části, pokračování na další straně) ...................................................................................................................................................57 Obrázek 34 Interakční diagram: příprava aukce ..............................................................................................60 Obrázek 35 Interakční diagram: aukční den ....................................................................................................61 Obrázek 36 Interakční diagram: aukce ............................................................................................................62
72
10 PŘÍLOHA 1 – DIAGRAMY V TEXTOVÉ NOTACI AUML Příprava aukce: start priprava_aukce agent pl planovaci_agent agent man Agent_manazer agent per Tech_personal_agent agent env prostredi message env pl t-4 message pl per plan-hotov box parallel message per pl premisteni-dokonceno next message per pl informace umisteny next label schvaleni message pl man ke-schvaleni box alt message man pl schvaleno next message man pl neschvaleno goto schvaleni end alt end parallel guard [nabidka-zverejnena] message pl env aukce-pripravena finish
Aukční den: start aukcni_den agent den agent_aukcniho_dne agent auk agent_aukce agent per ter_personal_agent agent uc agent_ucastnik agent env prostredi message den env zahajeni-prohlidky label prohlidka box alt message uc den zadost-registrace message den per registrace box parallel message per uc registrace-provedena next goto prohlidka end parallel next guard [cas-zahajeni] message den uc aukce-spustena end alt box loop message den auk start-aukce message auk den aukce-ukoncena end loop message den env konec aukci message den per tvorba-reportu message den env konec-dne finish
Aukce: start aukce agent auk agent_aukce agent uc agent_ucastnik
73
agent den agent_aukcniho_dne message den auk start-aukce message auk uc info-auto label vyv-cena box break guard [posl.vyv.cena=min.cena] message auk den konec aukce end break message auk uc vyvolavaci-cena box alt message uc auk nabidka next guard [2-min] goto vyv-cena end alt label navysena cena message auk uc navysena cena box alt message uc auk nabidka goto navysena cena next guard [2-min] message auk uc vyhlaseni viteze end alt message auk den konec aukce finish
11 PŘÍLOHA 2 – KONTROLNÍ LIST
74
75
Zdroj: (Autoaukce, s.r.o, 2010)
76
