´ Simulace a navrh vyv´ıjej´ıc´ıch se ´ u˚ system
Vladim´ır Janouˇsek
´ uˇ ´ v Brnˇ Fakulta informaˇ cn´ıch technologi´ı, Vysoke cen´ı technicke e Brno, 2008
Simulace a n´ avrh vyv´ıjej´ıc´ıch se syst´ em˚ u Vladim´ır Janouˇsek1 FIT, Brno University of Technology, Czech Rep., email:
[email protected]
Simulace a n´avrh vyv´ıjej´ıc´ıch se syst´em˚ u Vladim´ır Janouˇsek Brno 2008
c Vladim´ır Janouˇsek, 2008
Pˇ redmluva Aplikac´ı simulace a form´ aln´ıch model˚ u, zvl´aˇstˇe pak model˚ u na b´azi DEVS (Discrete Event Systems Specification) v n´avrhu syst´em˚ u se ve svˇetˇe dlouhodobˇe zab´ yv´ a pˇredevˇs´ım skupina prof. Zeiglera (Univ. of Arizona). Pˇr´ıstup t´eto skupiny v posledn´ı dobˇe stav´ı pˇredevˇs´ım na zaveden´ ych programovac´ıch jazyc´ıch, jako je C++ a Java a na sladˇen´ı zaveden´ ych metod softwarov´eho inˇzen´ yrstv´ı s vyuˇzit´ım modelov´ an´ı a simulace v n´avrhu syst´em˚ u. Tento pˇr´ıstup je s u ´spˇechem pouˇz´ıv´ an v pr˚ umyslu, zvl´aˇstˇe pak ve v´ yvoji vojensk´ ych a kosmick´ ych technologi´ı (v´ yzkum v t´eto oblasti podporuje zejm´ena NASA a Ministerstvo obrany USA). Skupina modelov´an´ı a simulace na FIT VUT v Brnˇe nen´ı ani zdaleka tak siln´a, ale tak´e se snaˇz´ı aplikovat form´ aln´ı modely a simulaci ve v´ yvoji syst´em˚ u. Vych´az´ı vˇsak z ponˇekud jin´ ych koˇren˚ u, kter´e nejsou tak tˇesnˇe sv´az´any s pr˚ umyslem a jsou vhodn´e sp´ıˇse pro jin´ y typ projekt˚ u a s t´ım souvisej´ıc´ı jin´ y pˇr´ıstup k v´ yvoji syst´em˚ u. Klade d˚ uraz pˇredevˇs´ım na rychl´e prototypov´an´ı, experiment´aln´ı programov´ an´ı, dynamick´e jazyky a objektovou orientaci zaloˇzenou na prototypov´ ych objektech. Tento pˇr´ıstup je obecnˇe vhodn´ y pro n´avrh a v´ yvoj syst´em˚ u s nejasnou specifikac´ı, kterou je tˇreba dopracovat aˇz v r´amci v´ yvoje a c´ılov´eho nasazen´ı. Kromˇe moˇznosti zkoumat a interaktivnˇe vyv´ıjet syst´em za bˇehu je t´eˇz pˇredmˇetem zkoum´an´ı moˇznost automatick´eho v´ yvoje model˚ u. Oba zm´ınˇen´e pˇr´ıpady vyˇzaduj´ı zab´ yvat se otevˇrenost´ı a reflektivitou v souvislosti s form´ aln´ımi modely, simulac´ı a objektovou orientac´ı. Otevˇrenost, reflektivitu, experiment´aln´ı programov´an´ı a objektovou orientaci se ˇclenov´e skupiny snaˇz´ı aplikovat pˇribliˇznˇe od r. 2000. V t´e dobˇe existovala experiment´aln´ı implementace interpretu Objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN), kter´e jsem navrhl a form´ alnˇe definoval v r´amci sv´e disertaˇcn´ı pr´ace. Pro OOPN jsem v t´e dobˇe navrhl koncept otevˇren´e architektury, umoˇznuj´ıc´ı reflektivn´ı z´asahy do modelu a simul´ atoru v dobˇe bˇehu. Toto t´ema posl´eze podrobnˇe zpracoval ve sv´e disertaˇcn´ı pr´aci Radek Koˇc´ı. Implementov´ana byla tenkr´at ale jen ˇc´ast potˇrebn´ ych reflektivn´ıch vlastnost´ı, kter´e byly nezbytn´e pro jednoduc´e experimenty napˇr. s vnoˇrenou simulac´ı. V r´amci zkoum´an´ı moˇznost´ı multiparadigmatick´eho pˇr´ıstupu k tvorbˇe model˚ u s jednoduch´ ym jednot´ıc´ım formalismem bylo posl´eze rozhodnuto paralelnˇe aplikovat tyt´eˇz principy pro podstatnˇe jednoduˇsˇs´ı formalismus, a sice DEVS (Discrete EVent Systems Specification). D´ıky konceptu´aln´ı jednoduchosti a hierarchick´e struktuˇre s volnˇe v´azan´ ymi komponentami je DEVS pouˇziteln´ y jako spoleˇcn´ y z´aklad pro aplikaci r˚ uzn´ ych formalism˚ u v r´ amci jednoho simulaˇcn´ıho modelu. Experiment´aln´ı implementace, kterou jsem vytvoˇril, splˇ novala vˇsechny kl´ıˇcov´e poˇzadavky – byl to syst´em s plnou reflektivitou, umoˇzn ˇuj´ıc´ı neomezen´e z´asahy do simulace v dobˇe bˇehu. Experiment´alnˇe byly t´eˇz implementov´any vizu´ aln´ı n´astroje pro inspekci a editaci model˚ u (implementaci tˇechto n´astroj˚ u provedl v r´amci sv´e diplomov´e pr´ace Elod Kironsk´ y). Vytvoˇren´e prostˇred´ı nyn´ı poskytuje r´amec, do kter´eho je moˇzn´e potenci´alnˇe zaˇclenit interprety jin´ ych formalism˚ u. V souˇcasn´e dobˇe je do tohoto prostˇred´ı vnoˇren a v tomto pro-
iv stˇred´ı u ´spˇeˇsnˇe pouˇz´ıv´ an interpret OOPN (d´ıky Radkovi Koˇc´ımu). Jednou z vˇetˇs´ıch aplikac´ı OOPN je prostˇred´ı pro v´ yvoj multiagentn´ıch syst´em˚ u, kter´e jako souˇc´ast sv´e disertaˇcn´ı pr´ace navrhl a implementoval Zdenˇek Mazal. V uveden´em kontextu se nyn´ı jev´ı jako vhodn´e popsat kl´ıˇcov´e aspekty souˇcasn´eho stavu pozn´an´ı v oblasti aplikace reflektivity pro potˇreby modelov´an´ı a simulace vyv´ıjej´ıc´ıch se syst´em˚ u. A o tom je tato pr´ace. Autor
Abstrakt Tato pr´ace se zab´ yv´ a problematikou modelov´an´ı, simulace a n´avrhu syst´em˚ u s diskr´etn´ımi ud´alostmi s d˚ urazem na nepˇretrˇzitˇe bˇeˇz´ıc´ı a vyv´ıjej´ıc´ı se syst´emy. Konkr´etnˇe se zab´ yv´ a tˇemito t´ematy: • Vymezen´ı tˇr´ıdy vyv´ıjej´ıc´ıch se syst´em˚ u, zahrnuj´ıc´ı jak interaktivn´ı, tak automatick´ y v´ yvoj. • Syst´emy s diskr´etn´ımi ud´alostmi, formalismus DEVS, jeho varianty, vˇcetnˇe existuj´ıc´ıch modifikac´ı, zav´adˇej´ıc´ıch strukturn´ı dynamiku. • Reflektivn´ı DEVS a otevˇren´ a abstrakn´ı architektura pro model´an´ı, simulaci a n´avrh syst´em˚ u. • Prostˇredky pro interaktivn´ı evoluˇcn´ı n´avrh syst´em˚ u. • Pˇr´ıpadov´e studie, demonstruj´ıc´ı reflektivitu a dynamick´ y v´ yvoj struktury syst´emu. Hlavn´ım pˇr´ınosem pr´ace je (1) zmapov´an´ı problematiky vyv´ıjej´ıc´ıch se syst´em˚ u, zahrnuj´ıc´ı pˇredevˇs´ım dynamickou manipulaci s modely a simulacemi v kontextu n´avrhu syst´em˚ u s vyuˇzit´ım simulace, (2) koncept abstraktn´ı architektury pro simlaci vyv´ıjej´ıc´ıch se syst´em˚ u a (3) a ovˇeˇren´ı navrˇzen´eho konceptu abstraktn´ı achitektury pro vyv´ıjej´ıc´ı se syst´emy pˇr´ıkladem praktick´e realizace, aplikovan´e v nˇekolika pˇr´ıpadov´ ych studi´ıch. To vˇse v n´avaznosti na teorii modelov´an´ı a simulace syst´em˚ u s diskr´etn´ımi ud´alostmi.
vi
Obsah ´ 1 Uvod – vyv´ıjej´ıc´ı se syst´ emy
1
2 Syst´ emy s diskr´ etn´ımi ud´ alostmi 2.1 Syst´emy, znalosti, probl´emy . . . . . . . . . . . . . . 2.2 Simulaˇcn´ı modelov´an´ı . . . . . . . . . . . . . . . . . ˇ 2.3 Cas, trajektorie a segmenty . . . . . . . . . . . . . . 2.4 Syst´em . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Formalismus DEVS . . . . . . . . . . . . . . . . . . . 2.5.1 Syst´em s diskr´etn´ımi ud´alostmi . . . . . . . . 2.5.2 Z´akladn´ı model . . . . . . . . . . . . . . . . . 2.5.3 Sloˇzen´ y model . . . . . . . . . . . . . . . . . 2.5.4 Pouˇzit´ı port˚ u . . . . . . . . . . . . . . . . . . 2.5.5 Varianty a rozˇs´ıˇren´ı z´akladn´ı definice DEVS . 2.6 Hierarchick´a simulace DEVS (abstraktn´ı simul´ ator) . 2.7 Praktick´e pouˇzit´ı formalismu DEVS . . . . . . . . . 2.7.1 DEVS a objektov´a orientace . . . . . . . . . 2.7.2 Pˇr´ıklady model˚ u a jejich implementace . . . .
. . . . . . . . . . . . . .
5 5 6 7 7 8 8 9 10 11 12 12 15 16 16
3 Syst´ emy s dynamicky se mˇ en´ıc´ı strukturou 3.1 Dynamick´ y DEVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Abstraktn´ı simul´ ator pro dynamick´ y DEVS . . . . . . . . . . . . . . . . . . 3.3 Aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 21 23 25
4 Otevˇ ren´ a abstraktn´ı architektura 4.1 Vymezen´ı poˇzadovan´ ych vlastnost´ı . . . . . . . . . . 4.2 Simulace v re´aln´em ˇcase, propojen´ı s re´aln´ ym okol´ım 4.3 Klonov´an´ı a migrace syst´em˚ u a simulac´ı . . . . . . . ˇ ı a modifikace modelu . . . . . . . . . . . . . . . 4.4 Cten´ 4.5 Syst´emy simulac´ı (multisimulace) . . . . . . . . . . . 4.6 Shrnut´ı . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
27 27 27 31 34 38 40
5 V´ yvoj syst´ em˚ u v simulaci, n´ astroj SmallDEVS 5.1 Motivace a zvolen´ y pˇr´ıstup . . . . . . . . . . . . 5.2 Experiment´aln´ı programov´an´ı a Smalltalk . . . . 5.3 Objektov´a orientace zaloˇzen´ a na prototypech . . 5.4 Modelov´an´ı syst´em˚ u prototypov´ ymi objekty . . . 5.5 Sd´ılen´e chov´an´ı, znovupouˇzitelnost . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
41 41 42 45 47 50
. . . . .
. . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
viii
OBSAH 5.6 5.7
5.8 5.9
In(tro)spekce a reflektivita . . . . . . . . . . . . . . . . . . . . . Operaˇcn´ı syst´em . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Smalltalk a SmallDEVS . . . . . . . . . . . . . . . . . . 5.7.2 Perzistence . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.3 Vizu´ aln´ı n´astroje pro manipulaci s modely a simulacemi Aplikaˇcn´ı rozhran´ı j´adra SmallDEVS . . . . . . . . . . . . . . . Pozn´amka k implementaci . . . . . . . . . . . . . . . . . . . . .
6 Specifikace syst´ em˚ u formalismem OOPN 6.1 Petriho s´ıtˇe a objekty . . . . . . . . . . . . . . 6.1.1 Princip vysoko´ urovˇ nov´e Petriho s´ıtˇe . . 6.1.2 Paraleln´ı objektovˇe orientovan´ y syst´em 6.1.3 Modelov´an´ı objekt˚ u Petriho s´ıtˇemi . . . 6.1.4 Interakce objekt˚ u – zas´ıl´an´ı zpr´ av . . . 6.1.5 Invokace metod objekt˚ u zas´ıl´an´ım zpr´ av 6.1.6 Atomick´a synchronn´ı interakce objekt˚ u 6.2 Formalismus OOPN . . . . . . . . . . . . . . . 6.2.1 Struktura OOPN . . . . . . . . . . . . . 6.2.2 Reprezentace stavu OOPN . . . . . . . 6.2.3 Dynamika OOPN . . . . . . . . . . . . . 6.3 Simul´ ator OOPN . . . . . . . . . . . . . . . . . 6.4 Zapouzdˇren´ı OOPN do DEVS . . . . . . . . . . 6.5 Dynamick´e aplikaˇcn´ı rozhran´ı simul´ atoru . . . . 6.6 Shrnut´ı . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
51 52 52 53 53 54 55
. . . . . . . . . . . . . . .
57 57 58 58 59 60 60 60 61 61 62 63 64 65 65 66
7 Reflektivn´ı simul´ ator DEVS
67
8 Simulace simuluj´ıc´ıho syst´ emu 8.1 Pˇr´ıklad vnoˇren´e simulace: Syst´em hromadn´e obsluhy, lizov´ana opakovanou vnoˇrenou simulac´ı . . . . . . . 8.2 Model s vnoˇrenou simulac´ı v jazyce SIMULA . . . . 8.3 Model s vnoˇrenou simulac´ı v jazyce PNtalk . . . . . 8.3.1 Tˇr´ıda BankModel . . . . . . . . . . . . . . . 8.3.2 Class Bank . . . . . . . . . . . . . . . . . . . 8.3.3 Vnoˇren´ a simulace, interakce ˇcasov´ ych os . . . 8.3.4 Simulace . . . . . . . . . . . . . . . . . . . . . 8.4 Z´avˇer . . . . . . . . . . . . . . . . . . . . . . . . . .
71
jehoˇz ˇc´ast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
je optima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
71 73 77 77 81 82 83 84
9 Prostˇ red´ı pro v´ yvoj multiagentn´ıch syst´ em˚ u 85 9.1 Multiagentn´ı syst´emy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 9.2 Aplikace v OOPN a DEVS v multiagentn´ıch syst´emech . . . . . . . . . . . 86 9.3 Shrnut´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 10 Dynamick´ e modely v ˇ r´ızen´ı projekt˚ u 93 10.1 Z´akladn´ı pojmy z oblasti ˇr´ızen´ı projekt˚ u . . . . . . . . . . . . . . . . . . . . 93 10.2 Modelov´an´ı projektov´eho portfolia . . . . . . . . . . . . . . . . . . . . . . . 94 10.3 Shrnut´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
OBSAH 11 Z´ avˇ er
ix 101
x
OBSAH
Kapitola 1
´ Uvod – vyv´ıjej´ıc´ı se syst´ emy Tato pr´ace se zab´ yv´ a vyuˇzit´ım simulace v n´avrhu a v´ yvoji poˇc´ıtaˇcov´ ych (i kdyˇz nikoliv nutnˇe jen poˇc´ıtaˇcov´ ych) syst´em˚ u, kter´e jsou pouˇz´ıv´ any v re´aln´em prostˇred´ı, maj´ı tedy definovan´e vstupy a v´ ystupy a pracuj´ı v re´aln´em ˇcase. Zvl´aˇstn´ı pozornost je pˇritom vˇenov´ana v´ yvoji struktury syst´em˚ u nejen v pr˚ ubˇehu n´avrhu a testov´an´ı, ale i bˇehem re´aln´eho pouˇz´ıv´ an´ı a u ´drˇzby. K v´ yvoji struktury syst´emu m˚ uˇze doch´azet jednak inkremet´ aln´ımi z´asahy zvenˇc´ı, jednak automatickou adaptac´ı syst´emu na mˇen´ıc´ı se vnˇejˇs´ı podm´ınky. Modelovac´ı formalismy Problematika vyv´ıjej´ıc´ıch se syst´em˚ u bude pops´ ana obecnˇe, na u ´rovni abstraktn´ıch model˚ u s rigor´oznˇe definovan´ ymi pojmy ˇcas, stav, vstup a v´ ystup. Konkr´etn´ı formalismus pro n´as nen´ı nijak zavazuj´ıc´ı, d˚ uraz bude kladen na v pˇr´ımou n´avaznost na pojmy obecn´e teorie syst´em˚ u. Jako spoleˇcn´ y z´aklad pro u ´vahy o pouˇzit´ı r˚ uzn´ ych formalism˚ u bude pouˇzit formalismus pro specifikaci syst´emu s diskr´etn´ımi ud´alostmi – DEVS (Discrete EVent systems Specification). Tento formalismus je v´ yznamn´ y svou bezprostˇredn´ı vazbou na obecnou teorii syst´em˚ u a pr´avˇe takovou u ´rovn´ı abstrakce, kter´ a je ide´aln´ı pro simulaci a n´avrh syst´em˚ u, kter´e jsou pˇredmˇetem naˇseho z´ajmu (t.j. pˇredevˇs´ım poˇc´ıtaˇcov´ ych syst´em˚ u libovoln´eho druhu). Ostatn´ı v u ´vahu pˇripadaj´ıc´ı formalismy, jako jsou napˇr. koneˇcn´e automaty, stavov´e diagramy (statecharts) a Petriho s´ıtˇe, jsou do DEVS relativnˇe snadno mapovateln´e. I syst´emy jin´ ych typ˚ u, jako jsou spojit´e syst´emy a syst´emy s diskr´etn´ım ˇcasem, lze tak´e do DEVS snadno transformovat. DEVS jako spoleˇcn´ y form´ aln´ı z´aklad pro r˚ uzn´e pˇr´ıstupy k modelov´an´ı a simulaci usnadˇ nuje transformaci model˚ u, portabilitu, migraci a klonov´an´ı model˚ u, obecn´ y v´ yvoj nov´ ych simulaˇcn´ıch architektur bez ohledu na konkr´etn´ı formalismus nebo specifikaˇcn´ı jazyk. Vyuˇzit´ı formalismu, jako je DEVS, umoˇzn´ı bezprostˇredn´ı prov´az´an´ı teorie modelov´an´ı a simulace s prax´ı – modely a simul´ atory postaven´e na form´ aln´ım z´akladˇe a v souladu s teori´ı lze analyzovat jako matematick´e objekty s vyuˇzit´ım form´ aln´ıch metod a souˇcasnˇe jsou k dispozici k pˇr´ım´emu praktick´emu pouˇzit´ı, t.j. jak k simulaˇcn´ım experiment˚ um, tak k bˇehu v c´ılov´em prostˇred´ı. V´ yvoj syst´ em˚ u v simulovan´ em a v re´ aln´ em prostˇ red´ı Zvyˇsuj´ıc´ı se n´aroky na kvalitu a schopnosti vyv´ıjen´ ych syst´em˚ u, kter´e se v d˚ usledku nar˚ ustaj´ıc´ıch poˇzadavk˚ u st´avaj´ı st´ale sloˇzitˇejˇs´ımi, vede k v´ yvoji nov´ ych metod n´avrhu, v´ yvoje, implementace a u ´drˇzby syst´em˚ u. V´ yvoj syst´em˚ u v simulaci (Simulation-Based Development) je metoda tvorby poˇc´ıtaˇcov´ ych syst´em˚ u, vyuˇz´ıvaj´ıc´ı d˚ ukladn´e testov´an´ı a verifikaci navrhovan´eho syst´emu ve vˇsech f´az´ıch v´ yvoje, aniˇz by bylo nutn´e se v´azat na re´aln´e okol´ı syst´emu, pˇr´ıpadnˇe na re´aln´ y ˇcas. Mimo to je simulace ve f´azi n´avrhu uˇziteˇcn´ a tehdy, kdyˇz pro navrhovan´e syst´emy
2
´ ´ KAPITOLA 1. UVOD – VYV´IJEJ´IC´I SE SYSTEMY
neexistuje pˇredem jasn´ a specifikace. Zde je nezbytn´e pouˇz´ıt evoluˇcn´ı n´avrh, kter´ y spoˇc´ıv´ a v rychl´em a bezprostˇredn´ım vytv´aˇrn´ı, modifikaci, testov´an´ı, vyhodnocov´an´ı a porovn´av´an´ı mnoha kandid´ atn´ıch ˇreˇsen´ı. Podle charakteru hodnot´ıc´ı funkce pak m˚ uˇze evoluce syst´em˚ u prob´ıhat interaktivnˇe, automaticky, nebo kombinovanˇe. V pˇr´ıpadˇe interaktivn´ıho testov´an´ı simulovan´eho produktu jde o tzv. virtu´aln´ı prototypov´an´ı. Podp˚ urn´a architektura mus´ı pˇr´ısluˇsnou variantu evoluˇcn´eho n´avrhu syst´em˚ u efektivnˇe umoˇznit. Adaptace syst´ emu na mˇ en´ıc´ı se okoln´ı podm´ınky M´ a-li b´ yt vyv´ıjen´ y syst´em v kontaktu s mˇen´ıc´ım se prostˇred´ım a m´ a-li i v pˇredem nezn´am´ ych podm´ınk´ach plnit definovan´e c´ıle, je tˇreba jiˇz pˇri n´avrhu syst´emu zohlednit moˇznost adaptace, v´ yvoje, resp. uˇcen´ı. Adaptace syst´emu na mˇen´ıc´ı se prostˇred´ı m˚ uˇze b´ yt prov´adˇena bud’ inkrement´aln´ımi vnˇejˇs´ımi z´asahy z prostˇred´ı, tedy p˚ usoben´ım jin´eho syst´emu (typicky ˇclovˇeka-v´ yvoj´aˇre), nebo samostatnˇe, na z´akladˇe autonom´ıho zkoum´an´ı prostˇred´ı a uˇcen´ı se. Pˇripust´ıme-li autonomn´ı chov´an´ı a adaptaci syst´emu v nezn´am´em prostˇred´ı, m´ a smysl o syst´emech, kter´e jsou pˇredmˇetem naˇseho zkoum´an´ı, uvaˇzovat jako o agentn´ıch syst´emech, resp. jako o inteligentn´ıch agentech. Pak je vhodn´e zab´ yvat se moˇzn´ ymi agentn´ımi architekturami – syst´em m˚ uˇze b´ yt realizov´an jako jednoduch´ y reaktivn´ı agent, kter´ y na z´akladˇe vstupu a aktu´aln´ıho stavu jednoduˇse definovanou funkc´ı generuje v´ ystup, nebo m˚ uˇze b´ yt ch´ap´ an jako agent deliberativn´ı (uvaˇzuj´ıc´ı), jehoˇz stav je jiˇz komplikovanˇeji strukturov´an a funkce, modifikuj´ıc´ı stav na z´akladˇe aktu´aln´ıho stavu a vstupu, pˇr´ıpadnˇe generuj´ıc´ı v´ ystup na z´akladˇe stavu, jsou pomˇernˇe komplikovan´e funkce, specifikovan´e napˇr. prostˇredky form´ aln´ı logiky, pˇr´ıpadnˇe neuronov´ ymi s´ıtˇemi, s vyuˇzit´ım fuzzy logiky, genetick´ ych algoritm˚ u apod. Motivaˇ cn´ı pˇ r´ıklady Smyslem tohoto textu je zmapovat esenci´ aln´ı skuteˇcnosti, kter´e se t´ ykaj´ı n´avrhu a udrˇzov´an´ı vyv´ıjej´ıch se syst´em˚ u. Pˇritom je kladen d˚ uraz na pouˇzit´ı simulace, form´ aln´ıch model˚ u a jejich zachov´an´ı v pr˚ ubˇehu a v´ yvoje i c´ılov´eho nasazen´ı. Jako motivaˇcn´ı pˇr´ıklady a pˇr´ıpadov´e studie uvedeme nˇekolik r˚ uznorod´ ych syst´em˚ u, kter´e spojuje pr´avˇe kontakt s okoln´ı realitou a d˚ uraz na dynamickou manipulaci s modely a simulacemi: (1) Simuluj´ıc´ı syst´em. V obecn´em pojet´ı jde o syst´em, jehoˇz souˇc´ast´ı je simulace. Simuluje-li syst´em s´ am sebe a pouˇz´ıv´ a-li v´ ysledky vlastn´ı simulace pro modifikaci sv´eho vlastn´ıho chov´an´ı v budoucnu, mluv´ıme o reflektivn´ı simulaci. Jde o pˇr´ıpad anticipuj´ıc´ıcho syst´emu, optimalizuj´ıc´ıho sv´e pˇredpokl´ adan´e budouc´ı chov´an´ı podle zvolen´ ych kriteri´ı na z´akladˇe n´asobn´ ych simulac´ı sebe sama. Pˇr´ıkladem m˚ uˇze b´ yt optimalizace poˇctu otevˇren´ ych pˇrep´ aˇzek v bance v z´avislosti na zmˇen´ ach pravdˇepodobnostn´ıho rozloˇzen´ı pˇr´ıchoz´ıch klient˚ u v pr˚ ubˇehu dne. Jde o analyticky neˇreˇsiteln´ y probl´em, proto je nutn´e pouˇz´ıt simulaci. Simulace simuluj´ıc´ıch syst´em˚ u klade specifick´e n´aroky na simulaˇcn´ı syst´em – je tˇreba pracovat s nez´ avisl´ ymi ˇcasov´ ymi osami a zajistit pˇrenos informac´ı mezi jednotliv´ ymi simulacemi. To lze ˇreˇsit bud’ s podporou operaˇcn´ıho syst´emu (jednotliv´e simulace spouˇstˇet jako procesy OS), nebo v r´ amci simulaˇcn´ıho syst´emu samotn´eho. Prvn´ı moˇznost je snadno dostupn´a, ale z program´ atorsk´eho hlediska tˇeˇzkop´ adn´ a, druh´a moˇznost je pohodlnˇejˇs´ı, ale simulaˇcn´ı prostˇred´ı ji mus´ı samo o sobˇe umoˇznit. (2) Inkrement´aln´ı v´ yvoj ˇr´ıdic´ıho syst´emu autonom´ıho mobiln´ıho robota v simulovan´em prostˇred´ı. Jde o v´ yvoj syst´emu, jehoˇz specifikace nen´ı na poˇc´atku v´ yvoje zcela jasn´ a a je ji tˇreba dodateˇcnˇe upˇresˇ novat na z´akladˇe v´ ysledk˚ u test˚ u, prov´adˇen´ ych na pokusn´ ych ˇ ıdic´ı syst´em autonomn´ıho mobiln´ıho robota je vhodn´e realizac´ıch v r˚ uzn´ ych prostˇred´ıch. R´ vyv´ıjet a testovat v simulovan´em prostˇred´ı dˇr´ıve, neˇz pˇristoup´ıme k testov´an´ı v prostˇred´ı
3 re´aln´em. Simulovat pˇritom lze i tvrdˇs´ı podm´ınky, neˇz jak´e oˇcek´av´ame v re´aln´em prostˇred´ı, pˇr´ıpadnˇe podm´ınky, kter´e sice oˇcek´av´ame, ale jsou re´alnˇe tˇeˇzko vytvoˇriteln´e. V pˇr´ıpadˇe, ˇze nen´ı jasn´ y ani okamˇzik, kdy je c´ılov´ y produkt prohl´aˇsen za hotov´ y, mus´ıme pˇripustit i dodateˇcn´ y v´ yvoj pˇri bˇeˇzn´em provozu v c´ılov´em prostˇred´ı. Aby bylo moˇzn´e ˇr´ıdic´ı syst´em inkrement´alnˇe vyv´ıjet jak v simulovan´em, tak v re´aln´em prostˇred´ı, je nezbytn´e zachovat model ˇr´ızen´ı v pr˚ ubˇehu cel´eho v´ yvoje, vˇcetnˇe c´ılov´eho nasazen´ı. Souˇc´ast´ı c´ılov´e realizace pak mus´ı b´ yt interpret formalismu, v kter´em byl model vytvoˇren. Souˇcasnˇe mus´ı b´ yt tento interpret zpˇr´ıstupnˇen pro monitorov´an´ı stavu a pro inkrement´aln´ı z´asahy v´ yvoj´aˇre – typicky vzd´ alenˇe, napˇr. s vyuˇzit´ım webov´ ych sluˇzeb. ˇ ızen´ı projektov´eho portfolia, jeho optimalizace a monitorov´an´ı. Projektov´e port(3) R´ folio je mnoˇzina aktu´alnˇe bˇeˇz´ıc´ıch a pl´ anovan´ ych projekt˚ u. Modely (r´amcov´e pl´ any) projekt˚ u, specifikovan´e napˇr. s´ıt’ov´ ymi grafy nebo ˇcasovan´ ymi Petriho s´ıtˇemi, se pouˇz´ıvaj´ı k optimalizaci mechanismu pˇridˇelov´an´ı zdroj˚ u (rozvrhov´an´ı) a k pr˚ ubˇeˇzn´emu monitorov´an´ı pr˚ ubˇehu projektu. Jak v r´amci optimalizace, tak v pr˚ ubˇehu monitorov´an´ı se vyuˇz´ıv´ a simulace. V r´amci optimalizace je tˇreba simulovat mnoho kandidatn´ıch model˚ u a na z´akladˇe vyhodnocen´ı v´ ysledk˚ u vybrat model, kter´ y nejl´epe vyhovuje zadan´ ym kriteri´ım. V r´amci monitorov´an´ı se pak porovn´av´a simulace pl´ anovan´eho pr˚ ubˇehu projektu s realitou. Postupem ˇcasu se mˇen´ı jak projektov´e portfolio (tj. mnoˇzina aktu´aln´ıch projekt˚ u), tak struktura dostupn´ ych zdroj˚ u. Model cel´eho syst´emu se proto mus´ı adekv´atn´ım zp˚ usobem pr˚ ubeˇznˇe pˇrizp˚ usobovat takto se mˇen´ıc´ım vnˇejˇs´ım podm´ınk´ am. Obdobn´e (v mnoh´em tyt´eˇz) probl´emy se ˇreˇs´ı v souvislosti se syst´emy pl´ anov´an´ı a ˇr´ızen´ı v´ yroby. Reflektivn´ı a meta´ urovˇ nov´ e architektury Uveden´e pˇr´ıklady demonstruj´ı v´ yznamn´ y aspekt cel´e tˇr´ıdy podobn´ ych syst´em˚ u, kter´ ym je nutnost zab´ yvat se kromˇe z´akladn´ı (aplikaˇcn´ı) u ´rovnˇe tak´e meta´ urovn´ı, tedy syst´emem popisuj´ıc´ım v´ yvoj tˇechto syst´em˚ u. Na t´eto u ´rovni sledujeme pˇrechody mezi doˇcasnˇe existuj´ıc´ımi d´ılˇc´ımi syst´emy. Z praktick´eho hlediska je tˇreba v se v uveden´em kontextu zab´ yvat kromˇe vz´ ajenn´eho prov´az´an´ı reality a simulace (reality-in-the-loop simulation) tak´e meta´ urovˇ novou architekturou a reflektivn´ım rozhran´ım smul´ atoru, aby bylo moˇzn´e s modely a simulacemi dynamicky (to jest za bˇehu) manipulovat v souladu s teori´ı a bez ohledu na to, zda aktorem t´eto manipulace je vnˇejˇs´ı syst´em nebo manipulovan´ y syst´em s´ am. Souvislosti Meta´ urovˇ nov´e a reflektivn´ı architektury patˇr´ı k z´aklad˚ um poˇc´ıtaˇcov´e vˇedy a jsou neodmyslitelnou souˇc´ast´ı informaˇcn´ıch technologi´ı. V oblasti teoretick´ ych z´aklad˚ u stoj´ı za zm´ınku pˇredevˇs´ım Goedel˚ uv d˚ ukaz ne´ uplnosti form´ aln´ıho syst´emu a Turing˚ uv univerz´ aln´ı stroj, pouˇzit´ y v d˚ ukazu nerozhodnutelnosti probl´emu zastaven´ı. V oblasti vˇedy o syst´emech se napˇr. Klir zab´ yv´ a existenc´ı metasyst´em˚ u, popisuj´ıc´ıch v´ yvoj syst´em˚ u. Z informaˇcn´ıch technologi´ı stoj´ı za zm´ınku obecn´e operaˇcn´ı syst´emy coˇz jsou jsou vesmˇes syst´emy s meta´ urovˇ novou a reflektivn´ı architekturou – umoˇzn ˇuj´ı vytv´aˇren´ı a manipulaci s programy a procesy, pˇriˇcemˇz aktory takov´e manipulace jsou bˇeˇz´ıc´ı procesy ˇr´ızen´e existuj´ıc´ımi programy. Co do ideov´e ˇcistoty jsou zaj´ımav´e syst´emy, zaloˇzen´e na dynamick´ ych jazyc´ıch, jako jsou LISP a Smalltalk, pˇr´ıpadnˇe na jazyc´ıch, kter´e jsou LISPem a Smalltalkem inspirov´any. Zm´ınˇen´e syst´emy jsou schopn´e nepˇretrˇzitˇe bˇeˇzet a sv´ ymi vlastn´ımi prostˇredky samy sebe vyv´ıjet, a to jak autonomnˇe, tak na z´akladˇe interakce s uˇzivatelem. V´ yvoj syst´emu za bˇehu na z´akladˇe interakce s v´ yvoj´aˇrem je kl´ıˇcov´ ym pˇredpokladem pro
´ ´ KAPITOLA 1. UVOD – VYV´IJEJ´IC´I SE SYSTEMY
4
techniku v´ yvoje, zvanou experiment´aln´ı programov´an´ı (exploratory programming).1 V oblasti umˇel´e inteligence je sebemodifikace z´akladn´ım pˇredpokladem schopnosti syst´emu uˇcit se. Hlavn´ım c´ılem tohoto textu je popsat fenom´en vyv´ıjej´ıch se syst´em˚ u v kontextu simulaˇcn´ıho modelov´an´ı s vyuˇzit´ım form´ aln´ıch model˚ u. Motivac´ı k tomuto poˇc´ın´ an´ı je snaha aplikovat form´ aln´ı modely pˇri vytv´aˇren´ı i v r´amci u ´drˇzby a adaptace poˇc´ıtaˇcov´ ych syst´em˚ u na mˇen´ıc´ı se podm´ınky bˇehem jejich ˇzivota. Takov´e zpr˚ uhlednˇen´ı vyv´ıjen´ ych syst´em˚ u i metod jejich v´ yvoje by mˇelo b´ yt u ´ˇcinn´ ym prostˇredkem ke zv´ yˇsen´ı jejich uˇzitn´e hodnoty. Obsah N´ asleduj´ıc´ı text je organizov´an takto: Po obecn´em u ´vodu do modelov´an´ı a simulace syst´em˚ u s d˚ urazem na syst´emy s diskr´etn´ımi ud´alostmi je pops´ ana problematika syst´em˚ u s dynamicky se mˇen´ıc´ı strukturou. Pot´e je definov´ana abstraktn´ı architektura pro simulaci vyv´ıjej´ıc´ıch se syst´em˚ u. N´ asleduje diskuse praktick´ ych aspekt˚ u definovan´e architektury, spolu s metodick´ ymi pozn´amkami. Nakonec jsou uvedeny jednoduch´e pˇr´ıpadov´e studie, demonstruj´ıc´ı aplikaci simulace v n´avrhu a realizaci vyv´ıjej´ıch se syst´em˚ u.
1ˇ
Cesk´ y pˇreklad nen´ı pˇresn´ y, ale v dan´em kontextu je pouˇziteln´ y.
Kapitola 2
Syst´ emy s diskr´ etn´ımi ud´ alostmi Kapitola prezentuje syst´emy s diskr´etn´ımi ud´alostmi, kter´e jsou vhodnou abstrakc´ı pro modelov´an´ı poˇc´ıtaˇcov´ ych (ale nejen poˇc´ıtaˇcov´ ych) syst´em˚ u v r´amci jejich n´avrhu a v´ yvoje. Adekv´ atnost tohoto zp˚ usobu modelov´an´ı je opodstatnˇena t´ım, ˇze jako syst´emy s diskr´etn´ımi ud´alostmi lze modelovat vˇsechny typy dynamick´ ych syst´em˚ u (t.j. syst´em˚ u, u nichˇz m´ a smysl zkoumat chov´an´ı) a tedy vˇsechny zp˚ usoby aplikac´ı vyv´ıjen´ ych syst´em˚ u. V n´avaznosti na z´akladn´ı pojmy teorie syst´em˚ u a teorie modelov´an´ı a simulace je v n´asleduj´ıc´ıch podkapitol´ ach pˇredstaven formalismus DEVS a jeho abstraktn´ı simul´ ator. Pro ilustraci pˇr´ım´e vazby teorie a praxe modelov´an´ı a simulace je prezentov´ana i uk´azka praktick´eho pouˇzit´ı formalismu DEVS v konkr´etn´ım programovac´ım jazyce.
2.1
Syst´ emy, znalosti, probl´ emy
Klir [Kli85] definuje r´ amec pro studium syst´em˚ u, ve kter´em rozliˇsuje 4 epistemologick´e u ´rovnˇe, reflektuj´ıc´ı dostupn´e znalosti o syst´emu. Kaˇzd´ au ´roveˇ n zahrnuje znalosti dostupn´e vu ´rovn´ıch niˇzˇs´ıch. 0. Zdrojov´ au ´roveˇ n (source level, source system) je nejniˇzˇs´ı u ´roveˇ n, kde jde jen o mnoˇzinu promˇenn´ ych, kter´e n´as zaj´ımaj´ı. ´ 1. Uroveˇ n dat (data level, data system) zahrnuje tempor´ aln´ı v´ yvoj promˇenn´ ych v podobˇe ˇcasov´ ych ˇrad. ´ 2. Uroveˇ n chov´ an´ı (behavior level, behavior system), obsahuje znalosti o vztaz´ıch mezi historiemi promˇenn´ ych. Behavior´ aln´ı syst´emy jsou schopny generovat ˇcasov´e ˇrady (time series), proto se tak´e naz´ yvaj´ı generativn´ı syst´emy. ´ 3. Uroveˇ n struktury (structure level, staructural system) zahrnuj´ı znalost o subsyst´emech syst´emu a o struktuˇre jej´ıch vz´ ajemn´ıch vztah˚ u (propojen´ı). Tuto hierarchii zavrˇsuje p´at´ a u ´roveˇ n - u ´roveˇ n metasyst´em˚ u, kter´e obsahuj´ı informaci o tom, jak se datov´e, generativn´ı a strukturn´ı syst´emy vyv´ıjej´ı v ˇcase. Na t´eto u ´rovni n´as zaj´ım´a dynamika samotn´eho popisu syst´emu. Ve v´ yˇse uveden´em kontextu existuj´ı 3 typy probl´em˚ u k ˇreˇsen´ı [Kli85]: 1. Anal´yza syst´emu. Syst´em bud’ existuje, nebo je pl´ anov´ana jeho existence a pokouˇs´ıme se pochopit jeho chov´an´ı. Za pouˇzit´ı generativn´ıho popisu zisk´av´ame a zkoum´ame data.
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
6
2. Inference syst´emu. Syst´em existuje a snaˇz´ıme se pˇrej´ıt na vyˇsˇs´ı epistemologickou u ´roveˇ n, typicky od dat ke generativn´ımu popisu. 3. N´ avrh syst´emu. Syst´em neexistuje a snaˇz´ıme se ho navrhnout. Pˇrech´az´ıme na vyˇsˇs´ı u ´roveˇ n znalost´ı, od existuj´ıc´ıch generativn´ıch komponent ke sloˇzen´emu syst´emu s vhodnou strukturou. Zat´ımco Klir [Kli85] uvedenou hierarchii znalost´ı definuje pˇredevˇs´ım jako r´amec pro zkoum´ an´ı moˇznosti induktivn´ı identifikace syst´em˚ u (odvozov´an´ı vyˇsˇs´ıch znalostn´ıch u ´rovn´ı z niˇzˇs´ıch), Zeigler [Zei84, Zei90, ZKP00] a jin´ı se zamˇeˇruj´ı ve vˇetˇs´ı m´ıˇre na metody specifikace syst´em˚ u, kter´e se daj´ı uplatnit v modelovac´ıch a simulaˇcn´ıch jazyc´ıch. Zab´ yvaj´ı se pˇredevˇs´ım u ´rovn´ı struktury a chov´an´ı s c´ılem generovat data. Diskutovanou ot´ azkou i v t´eto oblasti je u ´roveˇ n metasyst´em˚ u, tedy moˇznost specifikovat a simulovat vyv´ıjej´ıc´ı se generativn´ı syst´emy. ´ cinn´ Uˇ ym prostˇredkem pro anal´ yzu chov´an´ı syst´em˚ u je simulace. Modelov´an´ı a simulaci syst´em˚ u, zvl´aˇstˇe pak syst´em˚ u s diskr´etn´ımi ud´alostmi, se vˇenuj´ı n´asleduj´ıc´ı ˇc´asti kapitoly.
2.2
Simulaˇ cn´ı modelov´ an´ı
Z´akladn´ı r´amec pro modelov´an´ı a simulaci je podle [ZKP00] definov´an ˇctyˇrmi entitami (viz obr. 2.1): 1. Zdrojov´y syst´em (source system) pˇredstavuje zdroj dat (chov´an´ı). 2. Model pˇredstavuje instrukce pro generov´an´ı dat srovnateln´ ych s re´aln´ ym syst´emem. 3. Simul´ ator prov´ad´ı instrukce modelu a skuteˇcnˇe generuje chov´an´ı. 4. Experiment´ aln´ı r´ amec (experimental frame) specifikuje podm´ınky, za kter´ ych syst´em pozorujeme a exeperimentujeme se s n´ım. Experimental Frame
Simulator Source System Simulation Relation Modeling Relation
Model
Obr´azek 2.1: Z´akladn´ı entity a jejich vztahy Z´akladn´ı vztahy mezi tˇemito entitami jsou modelov´ an´ı a simulace. Relace modelov´an´ı pˇritom specifikuje, jak model reprezentuje odpov´ıdaj´ıc´ı re´aln´ y syst´em. Mezi syst´emem a modelem mus´ı b´ yt homomorfn´ı vztah, tj. je pˇr´ıpustn´e zjednoduˇsen´ı. Relace simulace specifikuje, jak pˇresnˇe simul´ ator realizuje instrukce modelu.
ˇ 2.3. CAS, TRAJEKTORIE A SEGMENTY
7
Pˇrechod od zdrojov´eho syst´emu k modelu m˚ uˇze b´ yt proveden na z´akladˇe pozorov´an´ı dat z´ıskan´ ych z experiment˚ u se syst´emem. Model je pak pouˇzit k vytvoˇren´ı simul´ atoru, kter´ y slouˇz´ı ke generov´an´ı dat. Chov´an´ı, generovan´e simul´ atorem, mus´ı b´ yt validn´ı, tj. simul´ ator mus´ı generovat stejn´ a nebo podobn´a data jako zdrojov´ y syst´em za stejn´ ych podm´ınek.
2.3
ˇ Cas, trajektorie a segmenty
ˇ je Z´akladn´ım pojmem dynamick´eho syst´emu je ˇcas, kter´ y je nez´ avislou veliˇcinou. Cas definovov´an strukturou time = (T, <), kde
T je mnoˇzina, < je tranzitivn´ı, irreflexivn´ı a antisymetrick´a relace (uspoˇr´ad´ an´ı) nad T .
Jestliˇze pro kaˇzdou dvojici (t, t′ ) plat´ı bud’ t < t′ , nebo t > t′ , nebo t = t′ , pak jde o line´ arn´ı (´ upln´e) uspoˇra ´d´ an´ı. Relaci < definujeme typicky jako line´ arn´ı uspoˇr´ad´ an´ı, ale v nˇekter´ ych pˇr´ıpadech je vhodn´e pracovat i s ˇc´asteˇcn´ ym uspoˇr´ad´ an´ım, kter´e m˚ uˇze modelovat ˇ neurˇcitost v popisu syst´emu a n´asobnost stavov´ ych trajektori´ı. Casovou z´ akladnu T typicky + definujeme tak, ˇze T = R0 (pak jde o spojitou ˇcasovou z´ akladnu), nebo T = N (pak jde o diskr´etn´ı ˇcasovou z´ akladnu). Nad T definujeme intervaly: (t1 , t2 ) = {τ |t1 < τ < t2 , τ ∈ T }, [t1 , t2 ] = {τ |t1 ≤ τ ≤ t2 , τ ∈ T }, (t1 , t2 ] = {τ |t1 < τ ≤ t2 , τ ∈ T }. Z´apis < t1 , t2 > oznaˇcuje libovoln´ y z interval˚ u. Intervaly nad T nˇekdy znaˇc´ıme T
. Je-li T ˇcasov´a z´akladna a A libovoln´a mnoˇzina, funkce f : T −→ A se naz´ yv´ a ˇcasov´ a funkce nebo sign´ al. Restrikce f na intervalu < t1 , t2 > se naz´ yv´ a segment nebo trajektorie ω :< t1 , t2 >−→ A a zapisuje se ω . Dva segmenty nazveme soused´ıc´ı, kdyˇz jejich dom´eny na sebe navazuj´ı. Spojit´y segment nad spojitou ˇcasovou z´akladnou je spojit´ y ve vˇsech bodech. Po ˇca ´stech spojit´y segment je spojit´ y ve vˇsech bodech kromˇe koneˇcn´eho poˇctu bod˚ u. Po ˇca ´stech konstantn´ı segment je speci´aln´ı pˇr´ıpad po ˇc´astech spojit´eho segmentu. Ud´ alostn´ı segment ω :< t0 , tn >−→ A∪{∅} je segment nad spojitou ˇcasovou z´akladnou a mnoˇzinou ud´alost´ı A ∪ {∅}, kde ∅ znaˇc´ı ne-ud´ alost. ∅ je hodnotou ω mezi jednotliv´ ymi ud´alostmi z mnoˇziny A, kter´e se vyskytly v ˇcasech t1 , t2 , ..., tn−1 . Segment nad diskr´etn´ı ˇcasovou z´akladnou se naz´ yv´ a sekvence.
2.4
Syst´ em
Syst´em je abstraktn´ı koncept, popisuj´ıc´ı chov´an´ı entit v ˇcase.1 Popisuje v´ ystupn´ı chov´an´ı na z´akladˇe vstupu a stavov´e informace. Form´alnˇe je syst´em pops´ an strukturou [ZKP00] S = (T, X, Ω, Q, q0 , Y, δ, λ), 1
Uvaˇzujeme dynamick´ y syst´em na u ´rovni 2 Klirovy hierarchie.
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
8 kde
T je ˇcasov´a z´akladna, X je mnoˇzina vstupn´ıch hodnot, Y je mnoˇzina v´ ystupn´ıch hodnot, Ω je mnoˇzina vstupn´ıch segment˚ u, Q je mnoˇzina stav˚ u, q0 je poˇc´ateˇcn´ı stav, δ : Q × Ω −→ Q je pˇrechodov´a funkce, λ : Q × X −→ Y je v´ ystupn´ı funkce.
Syst´em pˇritom splˇ nuje n´asleduj´ıc´ı omezen´ı: (1) Ω je uzavˇren´ a vzhledem ke kompozici; (2) pro kaˇzd´ y p´ar soused´ıc´ıch segment˚ u ω, ω ′ ∈ Ω a pro vˇsechny stavy q ∈ Q plat´ı: ′ δ(q, ωω ) = δ(δ(q, ω), ω). Omezen´ı (2) zaruˇcuje, ˇze syst´em m˚ uˇze b´ yt pˇreruˇsen v libovoln´em ˇcase a jeho stav je registrov´an. Pokraˇcov´an´ı z tohoto stavu s pokraˇcov´an´ım vstupn´ıho segmentu povede do stejn´eho koncov´eho stavu, jako kdyby k pˇreruˇsen´ı nedoˇslo. Typy syst´ em˚ u Zeigler [ZKP00] definuje 3 z´akladn´ı modelovac´ı formalismy, resp. typy syst´em˚ u: Syst´em popsan´y diferenci´ aln´ımi rovnicemi, syst´em s diskr´etn´ım ˇcasem a syst´em s diskr´etn´ımi ud´ alostmi. Poslednˇe jmenovan´ y formalismus (DEVS, kter´ y bude pops´ an v n´asleduj´ıc´ım textu) m˚ uˇze b´ yt modifikov´an nebo pˇr´ımo pouˇzit pro modelov´an´ı ostatn´ıch typ˚ u syst´em˚ u. Syst´em popsan´ y diferenci´ aln´ımi rovnicemi m˚ uˇze b´ yt s vyuˇzit´ım vhodn´eho vzorkov´an´ı a metod numerick´e integrace pˇreveden na syst´em s diskr´etn´ım ˇcasem. Syst´em s diskr´etn´ım ˇcasem m˚ uˇze b´ yt ch´ap´ an jako zvl´aˇstn´ı pˇr´ıpad syst´emu s diskr´etn´ımi ud´alostmi. DEVS je tedy univerz´ aln´ı, a proto tento formalismus povaˇzujeme za ide´aln´ı n´ızko´ urovˇ novou abstrakci, vhodnou pro vˇsechny typy syst´em˚ u. Jin´e (speci´alnˇejˇs´ı, pˇr´ıpadnˇe vysoko´ urovˇ novˇejˇs´ı) formalismy je moˇzn´e do DEVS relativnˇe snadno transformovat.
2.5
Formalismus DEVS
DEVS je zkratka pro Discrete EVent System Specification, tedy specifikaci syst´emu s diskr´etn´ımi ud´alostmi [ZKP00]. Pro tento formalismus je definov´an abstraktn´ım simul´ ator, kter´ y lze kromˇe specifikace s´emantiky ch´apat tak´e jako vzor pro re´alnou implementaci.
2.5.1
Syst´ em s diskr´ etn´ımi ud´ alostmi
Neform´ alnˇe lze syst´em s diskr´etn´ımi ud´alostmi popsat n´asleduj´ıc´ım zp˚ usobem. Syst´em m´ a vstupy a v´ ystupy pozorovateln´e jako ud´alosti. Na nˇekter´e vstupy syst´em reaguje v´ ystupem (okamˇzitˇe nebo se zpoˇzdˇen´ım), na nˇekter´e viditelnˇe nereaguje (jen pˇrech´az´ı mezi vnitˇrn´ımi stavy). Nˇekdy generuje v´ ystup bez pˇr´ım´e vnˇejˇs´ı pˇr´ıˇciny. Uvnitˇr syst´em pˇrech´az´ı mezi vnitˇrn´ımi stavy, a to bud’ samovolnˇe (pot´e, co v dan´em stavu str´avil jist´ y ˇcas), nebo na z´akladˇe vnˇejˇs´ı ud´alosti (ud´alosti na vstupu). V´ ystup vˇzdy z´avis´ı jen na aktu´aln´ım stavu a je pozorovatlen´ y jako ud´alost pˇri samovoln´em pˇrechodu syst´emu do stavu n´asleduj´ıc´ıho. Na obr. 2.2 je zobrazen vstupn´ı ud´alostn´ı segment (x), stavov´a trajektorie (s), trajektorie uplynul´eho ˇcasu (e) pro aktu´aln´ı stav a v´ ystupn´ı ud´alostn´ı segment (y).
2.5. FORMALISMUS DEVS
9 x1
x2
x
t s
t e
t y
y1
t0
t1
t2
t3
t
ˇ Obr´azek 2.2: Casov´ e segmenty syst´emu s diskr´etn´ımi ud´alostmi ˇ Souvislost s obecnou definic´ı syst´ emu Casov´ a z´akladna syst´emu s diskr´etn´ımi ud´alostmi je T = R0+ . Vstupn´ı a v´ ystupn´ı segmenty jsou ud´alostn´ı segmenty. Je-li S je mnoˇzina stav˚ u, stavov´a trajektorie je po ˇc´astech konstantn´ı segment nad S a T . Podle obecn´e definice syst´emu mus´ı stav registrovat i dobu setrv´ av´an´ı ve stavu s ∈ S, proto definujeme Q jako mnoˇzinu u ´pln´ ych stav˚ u Q = {(s, e)|e ∈ S, e ∈ R0+ }. Prvky Q jsou dvojice, tvoˇren´e stavem a ˇcasem setrv´ av´an´ı syst´emu ve stavu s. Tot´ aln´ı stavov´a trajektorie je po ˇc´astech spojit´ y segment nad Q a T .
2.5.2
Z´ akladn´ı model
Z´ akladn´ı model je specifikov´an algebraickou strukturou M = (X, S, Y, δint , δext , λ, ta), kde
X je mnoˇzina vstupn´ıch ud´ alost´ı, S je mnoˇzina stav˚ u, Y je mnoˇzina v´ystupn´ıch ud´ alost´ı, δint : S −→ S je intern´ı pˇrechodov´ a funkce, δext : Q × X −→ S je extern´ı pˇrechodov´ a funkce, kde Q = {(s, e) | s ∈ S, 0 ≤ e ≤ ta(s)} je mnoˇzina u ´pln´ych stav˚ u, e je ˇcas uplynul´y od posledn´ı ud´ alosti, λ : S −→ Y je v´ystupn´ı funkce,
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
10
ta : S −→ R0+ ∪ {∞} je funkce posuvu ˇcasu. Interpretace formalismu Syst´em je v dan´em okamˇziku ve stavu s ∈ S. Nevyskytne-li se ˇz´adn´ a extern´ı ud´alost, syst´em setrv´ a ve stavu s p o dobu ta(s) time. Zvl´aˇstn´ı hodnotou ta(s) je symbol ∞ – v takov´em pˇr´ıpadˇe je syst´em pasivn´ı a pl´ anuje setrvat ve stavu s navˇzdy. Dos´ ahne-li uplynul´ y ˇcas e hodnoty ta(s), v´ ystup λ(s) se objev´ı na v´ ystupu a syst´em zmˇen´ı stav na δint (s). Vyskytne-li se extern´ı ud´alost x ∈ X v ˇcase e ≤ ta(s), syst´em zmˇen´ı stav na δext (s, e, x). V´ ystup se generuje pouze v okamˇziku, kdy e = ta(s). Pˇri konfliktu intern´ıho a extern´ıho pˇrechodu (maj´ı-li se prov´est ve stejn´em ˇcasov´em okamˇziku) se provede pouze extern´ı pˇrechod. Atomick´ y model Uveden´ y formalismus umoˇzn ˇuje specifikovat jak´ ykoli syst´em s diskr´etn´ımi ud´alostmi. Ch´apeme-li ale syst´em jako hierarchickou strukturu, v´ yˇse uveden´a definice odpov´ıd´ a specifikaci atomick´emu modelu, z´akladn´ı nedˇeliteln´e jednotce syst´emu. Pˇr´ıklady mohou b´ yt gener´ ator, procesor, fronta, bin´ arn´ı ˇc´ıtaˇc apod. Syst´emy sloˇzen´e ze subsyst´em˚ u pak specifikujeme jako sloˇzen´e modely.
2.5.3
Sloˇ zen´ y model
Dalˇs´ım konceptem formalismu DEVS je hierarchie – syst´em m˚ uˇze b´ yt dekomponov´an do subsyst´em˚ u. Subsyst´emy jsou propojeny a mohou na sebe vz´ ajemnˇe p˚ usobit prostˇrednictv´ım sv´ ych extern´ıch (vstupn´ıch a v´ ystupn´ıch) ud´alost´ı. Stav sloˇzen´eho syst´emu je pak urˇcen stavy vˇsech jeho subsyst´em˚ u. Sloˇzen´ım a propojen´ım syst´em˚ u vznikne opˇet syst´em. Sloˇzen´y model je definov´an strukturou Nself = (X, Y, D, {Md }, {Id }, {Zi,d }, select) kde
X je mnoˇzina vstupn´ıch ud´ alost´ı, Y je mnoˇzina v´ystupn´ıch ud´ alost´ı, D je mnoˇzina jmen submodel˚ u, {Md |d ∈ D} je mnoˇzina submodel˚ u, {Id |d ∈ D ∪ {self }} je specifikace propojen´ı, ∀d ∈ D ∪ self : Id ⊆ D ∪ {self }, d ∈ / Id , {Zi,d |i ∈ Id , d ∈ D ∪ {self }} je specifikace pˇrekladu ud´ alost´ı, Zi,d : X −→ Xd pro i = self , Zi,d : Yi −→ Y pro d = self , Zi,d : Yi −→ Xd pro i 6= self a d 6= self , select : 2D − {} −→ D je preferenˇcn´ı funkce.
Interpretace formalismu Id pro kaˇzd´ y model d je moˇzina jmen model˚ u, jejichˇz v´ ystupy jsou pˇripojeny na vstup modelu d. Zi,d pro kaˇzd´ y model i, kter´ y je pˇripojen na vstup modelu d, specifikuje pˇreklad v´ ystupn´ı ud´alosti modelu i na vstupn´ı ud´alost modelu d. self identifikuje sloˇzen´ y model N . Funkce select se pouˇz´ıv´ a k ˇreˇsen´ı konfliktu souˇcasn´ ych ud´alost´ı – vyb´ır´ a jeden submodel z mnoˇziny submodel˚ u, ve kter´ ych je aktu´alnˇe provediteln´ y intern´ı pˇrechod.
2.5. FORMALISMUS DEVS
11
Uzavˇ renost vzhledem ke skl´ ad´ an´ı Mnoˇzina syst´em˚ u je uzavˇren´ a vzhledem k operaci skl´ ad´ an´ı. Tomu odpov´ıd´ a skuteˇcnost, ˇze i sloˇzen´ y model je model se stavy, vstupy a v´ ystupy a m˚ uˇze b´ yt pops´ an jako z´akladn´ı DEVS. Tato vlastnost byla form´ alnˇe dok´az´ana a d˚ ukaz lze naj´ıt napˇr. v [ZKP00].
2.5.4
Pouˇ zit´ı port˚ u
Stavov´ e promˇ enn´ e a porty Mnoˇziny intern´ıch stav˚ u a mnoˇziny vstupn´ıch a v´ ystupn´ıch ud´alosti je moˇzn´e specifikovat jako strukturovan´e mnoˇziny, coˇz n´am umoˇzn´ı pouˇz´ıt libovoln´ y poˇcet vstupn´ıch a v´ ystupn´ıch port˚ u a libovoln´ y poˇcet stavov´ych promˇenn´ych. Strukturovan´ a mnoˇzina S = (V, S1 × S2 ×, ... × Sn ) je definov´ana mnoˇzinou promˇenn´ ych V , |V | = n, a kart´ezsk´ ym souˇcinem mnoˇzin hodnot jedotliv´ ych promˇenn´ ych. Takˇze v definici DEVS s n stavov´ ymi promˇenn´ ymi {v1 , v2 , ...vn }, p vstupn´ımi porty {ip1 , ip2 , ..., ipp } a q v´ ystupn´ımi porty {op1 , op2 , ..., opp } m˚ uˇzeme mnoˇziny X, S a Y zapsat takto: X = ({ip1 , ..., ipp }, {(xip1 , ..., xipp )|xip1 ∈ Xip1 , ..., xip1 , ∈ Xipp }), S = ({v1 , ...vn }, {(sv1 , ..., svn )|sv1 ∈ Sv1 , ..., svn , ∈ Svn }), Y = ({op1 , ..., opp }, {(yop1 , ..., yopq )|yop1 ∈ Yop1 , ..., yopq , ∈ Sopq }). Strukturovan´ a mnoˇzina m˚ uˇze b´ yt specifikov´ana i jinak, jako mnoˇzina dvojic (jmeno, hodnota), v naˇsem pˇr´ıpadˇe: X = {(p, v)|p ∈ InP orts, v ∈ Xp }, S = {(v, s)|v ∈ StV ariables, s ∈ Sv }, Y = {(p, v)|p ∈ OutP orts, v ∈ Yp }, pˇriˇcemˇz InP orts = {p|(p, v) ∈ X}, StV ariables = {v|(v, s) ∈ S}, OutP orts = {p|(p, v) ∈ Y }. Alternativn´ı definice sloˇ zen´ eho modelu Jsou-li X a Y strukturovan´e mnoˇziny, specifikaci propojen´ı lze definovat mezi jednotliv´ ymi porty jednotliv´ ych model˚ u a funkci pˇrekladu ud´alost´ı definovat jako identitu. Toto zjednoduˇsen´ı specifikace sloˇzen´eho modelu je snadno prakticky pouˇziteln´e a je skuteˇcnˇe pouˇzito ve vˇsech re´aln´ ych implementac´ıch formalismu DEVS. N´ asleduje form´ aln´ı definice toho typu specifikace sloˇzen´eho modelu. Nself = (Xself , Yself , D, {Md }, EIC, IC, EOC, select), kde
Xself = {(p, v)|p ∈ InP ortsself , v ∈ Xp,self } je mnoˇzina vstupn´ıch ud´ alost´ı, Yself = {(p, v)|p ∈ OutP ortsself , v ∈ Yp,self } je mnoˇzina v´ystupn´ıch ud´ alost´ı, D je mnoˇzina jmen submodel˚ u, {Md |d ∈ D} je mnoˇzina submodel˚ u se vstupy Xd a v´ ystupy Yd ,
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
12
Xd = {(p, v)|p ∈ InP ortsd , v ∈ Xp,d } Yd = {(p, v)|p ∈ OutP ortsd , v ∈ Yp,d }, EIC = {((self, ipself ), (d, ipd ))|ipself ∈ InP ortsself , d ∈ D, ipd ∈ InP ortsd } je mnoˇzina extern´ıch vstupn´ıch propojen´ı, IC = {((a, opa ), (b, ipb ))|a, b ∈ D, opa ∈ OutP ortsa , ipb ∈ InP ortsb } je mnoˇzina intern´ıch propojen´ı, EOC = {((d, opd ), (self, opself ))|opself ∈ OutP ortsself , d ∈ D, opd ∈ OutP ortsd } je mnoˇzina extern´ıch v´ystupn´ıch propojen´ı, select : 2D − {} −→ D je preferenˇcn´ı funkce a jsou splnˇena n´asleduj´ıc´ı omezen´ı: ∀((a, p), (b, q)) ∈ IC =⇒ a 6= b, ∀((a, p), (b, q)) ∈ EIC : Xp,a ⊆ Xq,b , ∀((a, p), (b, q)) ∈ IC : Yp,a ⊆ Xq,b , ∀((a, p), (b, q)) ∈ EOC : Yp,a ⊆ Yq,b .
2.5.5
Varianty a rozˇ s´ıˇ ren´ı z´ akladn´ı definice DEVS
Existuj´ı r˚ uzn´e varianty a modifikace DEVS, jako je paraleln´ı DEVS, celul´arn´ı DEVS, symbolick´ y DEVS, fuzzy DEVS, nebo DEVS s dynamickou strukturou. Existuje tak´e moˇznost mapov´an´ı jin´ ych formalism˚ u do DEVS. Takto lze mapovat napˇr. koneˇcn´e automaty, Petriho s´ıtˇe, stavov´e diagramy, ale i diferenci´ aln´ı rovnice (prostˇrednictv´ım numerick´e integrace). DEVS lze tedy ch´apat jako spoleˇcn´ y z´aklad pro multiparadigmatick´e modelov´an´ı a simulaci [ZKP00].
2.6
Hierarchick´ a simulace DEVS (abstraktn´ı simul´ ator)
Simulace DEVS je organizov´ana hierarchicky (viz obr. 2.3). Hierarchie simul´ ator˚ u odpov´ıd´ a hierarchii model˚ u. Kaˇzd´ y simul´ ator je zodpovˇedn´ y za simulaci sv´eho modelu, je podˇr´ızen nadˇrazen´emu simul´ atoru a m˚ uˇze m´ıt podˇr´ızen´e simul´ atory. Ke komunikaci simul´ ator˚ u pˇri Root Coordinator
Coordinator
Coupled Model
Atomic Model
Coordinator
Atomic Model
Coupled Model
Atomic Model
Simulator
Simulator
Simulator
Obr´azek 2.3: Mapov´an´ı mezi modely a simul´ atory simulaci slouˇz´ı zpr´ avy (viz obr. 2.4): • (i, t) - inicializaˇcn´ı zpr´ avy pos´ıl´a nadˇrazen´ y simul´ ator podˇr´ızen´ ym pˇri odstartov´an´ı simulace,
´ SIMULACE DEVS (ABSTRAKTN´I SIMULATOR) ´ 2.6. HIERARCHICKA
13
• (∗, t) - pokyn nadˇrazen´eho simul´ atoru podˇr´ızen´emu k vygenerov´an´ı v´ ystupu a proveden´ı intern´ıho pˇrechodu pl´ anovan´eho na ˇcas t, • (y, t) - v´ ystupn´ı zpr´ avy pos´ıl´a podˇr´ızen´ y simul´ ator nadˇrazen´emu (nadˇrazen´ y simlu´ator je zopdpovˇedn´ y za jejich pˇr´ıpadnou distribuci), • (x, t) - vstupn´ı zpr´ avy pos´ıl´a nadˇrazen´ y simul´ ator podˇr´ızen´ ym a vynucuje tak pˇr´ıpadnou distribuci a proveden´ı extern´ıho pˇrechodu, • (done, tnext ) - podˇr´ızen´ y signalizuje nadˇrazen´emu dokonˇcen´ı zpracov´an´ı zpr´ avy (i, t), (∗, t), nebo (x, t) a oznamuje ˇcas proveden´ı n´asleduj´ıc´ıho intern´ıho pˇrechodu.
Root Coordinator (i, t) (*, t) (done, t) Coordinator (i, t) (x, t) (*, t)
(i, t) (x, t) (*, t)
(y, t) (done, t)
(y, t) (done, t)
Coordinator (i, t) (x, t) (*, t) (y, t) (done, t) Simulator
Simulator
(i, t) (x, t) (*, t) (y, t) (done, t) Simulator
Obr´azek 2.4: Zpr´avy pouˇz´ıvan´e pˇri simulaci DEVS Kaˇzd´ y simul´ ator udrˇzuje informaci o ˇcase posledn´ı ud´alosti tlast a ˇcase n´asleduj´ıc´ı pl´ anovan´e ud´alosti tnext , je schopen prov´est pl´ anovanou ud´alost a reagovat na vstupn´ı ud´alost. Simul´ ator sloˇzen´eho modelu (Coordinator) udrˇzuje tnext pro vˇsechny submodely, deleguje na nˇe prov´adˇen´ı ud´alost´ı a distribuuje ud´alosti mezi submodely podle jejich propojen´ı. Na nejvyˇsˇs´ı u ´rovni simulaci ˇr´ıd´ı koˇrenov´ y (hlavn´ı) simul´ ator (Root Coordinator), kter´ y iniciuje prov´adˇen´ı jednotliv´ ych krok˚ u simulace. D´ ale uveden´e algoritmy vych´azej´ı z [ZKP00] a [Van00]. Abstraktn´ı koˇ renov´ y simul´ ator Koˇrenov´ y simul´ ator je zodpovˇedn´ y za postupn´e prov´adˇen´ı krok˚ u simulace. Je spuˇstˇen s parametry podˇr´ızen´ y simul´ ator child, ˇcas zaˇc´atku a konce simulace tBEGIN , tEN D . Pouˇz´ıv´ a promˇenn´e t a tnext . Algoritmus: t := tBEGIN poˇsli (i, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext dokud t < tEN D opakuj: poˇsli (∗, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext
14
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
Abstraktn´ı simul´ ator atomick´ eho modelu M = (X, S, Y, δint , δext , λ, ta) pouˇz´ıv´ a promˇenn´e tlast , tnext , y, u ´pln´ y stav (s, e) a parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: tlast := t − e tnext := tlast + ta(s) poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent Na zpr´ avu (∗, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: y := λ(s) poˇsli (y, t) nadˇrazen´emu simul´ atoru parent s := δint (s) tlast := t tnext := tlast + ta(s) poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent Na zpr´ avu (x, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: e := t − tlast s := δext (s, e, x) tlast := t tnext := tlast + ta(s) poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent Abstraktn´ı simul´ ator (koordin´ ator) sloˇ zen´ eho modelu Nself = (X, Y, D, {Md }, {Id }, {Zi,d }, select) pouˇz´ıv´ a promˇenn´e tlast , tnext , y, eventList, imminent, d, receivers, activeChildren a parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: ∀d ∈ D : poˇsli (i, t) simul´ atoru d activeChildren := D Na zpr´ avu (done, tnext ) od podˇr´ızen´eho simul´ atoru d reaguj takto: eventList := (eventList − {(d, )}) ∪ {(d, tdnext )} activeChildren := activeChildren − {d} Je-li activeChildren = ∅, pak: tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru Na zpr´ avu (∗, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: d imminent := {d|(d, tnext ) ∈ eventList, tdnext = t} d := select(imminent) poˇsli (∗, t) simul´ atoru d activeChildren := {d}
´ POUZIT ˇ ´I FORMALISMU DEVS 2.7. PRAKTICKE
15
Na zpr´ avu (y, t) od podˇr´ızen´eho simul´ atoru d reaguj takto: Je-li d ∈ Iself a Zd,self (y) 6= ∅, pak: yself = Zd,self (y) poˇsli (yself , t) nadˇrazen´emu simul´ atoru parent receivers := {d|d ∈ D, self ∈ Id , Zself,d (x) 6= ∅} ∀d ∈ receivers : xd := Zself,d (x) poˇsli (xd , t) simul´ atoru d activeChildren := activeChildren ∪ receivers Na zpr´ avu (x, t) od nadˇrazen´eho simul´ atoru reaguj takto: receivers := {d|d ∈ D, self ∈ Id , Zself,d (x) 6= ∅} ∀d ∈ receivers : xd := Zself,d (x) poˇsli (xd , t) simul´ atoru d activeChildren := receivers Korektn´ı implementace V korektn´ı implementaci pˇri pˇrijet´ı zpr´ avy (∗, t) vˇzdy plat´ı t = tnext a pˇri pˇrijet´ı zpr´ avy (x, t) vˇzdy plat´ı tlast ≦ t ≦ tnext . D˚ ukaz korektn´ı synchronizace abstraktn´ıho simul´ atoru je pod´an v [ZKP00]. Pˇ reruˇ sov´ an´ı a klonov´ an´ı simulac´ı Uveden´ y abstraktn´ı simul´ ator pˇripouˇst´ı moˇznost pˇreruˇsen´ı a n´asledn´eho pokraˇcov´an´ı simulace (vˇcetnˇe moˇznosti klonov´an´ı a migrace) za pˇredpokladu, ze mezit´ım nedojde k manipulaci se strukturou. Pro potˇreby dynamick´e editace modelu je tˇreba simul´ ator upravit. Tato problematika bude podrobnˇe pops´ ana v kapitole 4. RT simulace a HIL Uveden´ y abstraktn´ı simul´ ator nen´ı pˇripraven na moˇznost propojen´ı s re´aln´ ym okol´ım. Tato problematika bude diskutov´ana v kapitole 4. Paraleln´ı a distribuovan´ a simulace Simulaci lze paralelizovat a distribuovat. V tomto pˇr´ıpadˇe je vhodn´e pouˇz´ıt paraleln´ı variantu DEVSu, kter´a se nepatrnˇe liˇs´ı od klasick´e varianty. Tato varianta poˇc´ıt´ a s moˇznost´ı souˇcasn´ ych ud´alost´ı na vstupech model˚ u a je pops´ ana v [ZKP00]. Pro dalˇs´ı v´ yklad nen´ı podstatn´e, o kterou variantu jde. Proto bude pro jednoduchost pouˇzita varianta klasick´a.
2.7
Praktick´ e pouˇ zit´ı formalismu DEVS
DEVS byl v dobˇe sv´eho vzniku urˇcen k tomu, aby bylo moˇzn´e form´ alnˇe popsat a pracovat modely, kter´e se pak obvykle implementovaly bˇeˇzn´ ym zp˚ usobem, typicky v ud´alostnˇe orientovan´em simulaˇcn´ım jazyce Simscript. Lepˇs´ı moˇznost´ı je ale pouˇz´ıt DEVS pˇr´ımo pro implementaci a odstranit tak nutnost explicitn´ıho mapov´ an´ı formalismu do programovac´ıho jazyka. K tomuto u ´ˇcelu byly vytvoˇreny podp˚ urn´e knihovny pro bˇeˇzn´e programovac´ı jazyky, jako je LISP, C, C++, Java, Smalltalk apod. Existuje ˇrada implementac´ı DEVS, jako pˇr´ıklady lze uv´est ADEVS (University of Arizona), CD++ (Carleton University), DEVS/HLA (ACIMS), DEVSJAVA (ACIMS), GALATEA (USB Venezuela), GDEVS (Aix-Marseille III, France), JDEVS (Universit´e de
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
16
Corse - France), PyDEVS (McGill), PowerDEVS (University of Rosario, Argentina), SimBeans (University of Linz, Austria), VLE (Universit´e du Litoral -France), SmallDEVS (Brno University of Technology, Czech Republic), James (University of Rostock, Germany).2 V souˇcasn´e dobˇe v pr˚ umyslu nejpouˇz´ıvanˇejˇs´ı implementac´ı je DEVSJAVA, kterou pouˇz´ıv´ a napˇr. NASA a DoD (USA).
2.7.1
DEVS a objektov´ a orientace
Nejˇcastˇejˇs´ı implementace v souˇcasn´e dobˇe existuj´ı pro objektovˇe orientovan´e jazyky C++ a Java. Implementace DEVS v objektovˇe orientovan´em jazyce zaloˇzen´em na tˇr´ıd´ ach vede k typick´emu zp˚ usobu modelov´an´ı, kde modely jsou vytv´aˇreny jako podtˇr´ıdy existuj´ıc´ıch tˇr´ıd (model˚ u). Podtˇr´ıda definuje instanˇcn´ı promˇenn´e pro reprezentaci stavu a redefinuje metody, odpov´ıdaj´ıc´ı funkc´ım δext , λ, δint , ta atomick´eho modelu, pˇr´ıpadnˇe specifikuje kolekci submodel˚ u (tj. instanc´ı pˇr´ısluˇsn´ ych tˇr´ıd), spolu s relac´ı propojen´ı pro sloˇzen´e modely. V obou pˇr´ıpadech je inicializaˇcn´ı metoda zodpovˇedn´ a za vytvoˇren´ı vstupn´ıch a v´ ystupn´ıch port˚ u. Vyuˇzit´ı dˇediˇcnosti pro specifikaci model˚ u je v´ yznamn´ ym pˇr´ınosem, stejnˇe tak i instanciace model˚ u. D´ıky tomu lze udrˇzovat knihovny znovupouˇziteln´ ych model˚ u.
2.7.2
Pˇ r´ıklady model˚ u a jejich implementace
Pro ilustraci praktick´eho pouˇzit´ı formalismu DEVS pro tvorbu simulaˇcn´ıch model˚ u bude uveden jednoduch´ y pˇr´ıklad, demonstruj´ıc´ı pˇr´ım´e mapov´an´ı matematick´eho modelu do programovac´ıho jazyka. Pro implementaci bude pouˇzit Smalltalk [GR89] s modelovac´ım prostˇred´ım SmallDEVS [Jan06]. V jin´ ych objektovˇe orientovan´ ych jazyc´ıch a prostˇred´ıch, jako je JAVADEVS apod., je princip modelov´an´ı totoˇzn´ y, liˇs´ı se jen v pouˇzit´em programovac´ım jazyku a v n´azvech nˇekter´ ych metod.3 Pro potˇreby v´ ykladu v tomto textu je Smalltalk vhodnˇejˇs´ı jednak kv˚ uli struˇcnosti a pˇrehlednosti, jednak proto, ˇze pro v´ yklad v kapitole 5 bude pouˇzit´ı Smalltalku kv˚ uli jeho specifik´ ym vlastnostem prakticky nezbytn´e. Pˇ r´ıklad Specifikujme hr´aˇce pingpongu:4 P ingP ongP layer = (X, S, Y, δint , δext , λ, ta, s0 ), kde
2
X = {(receive, ball)}, Y = {(send, ball)}, S = {send, receive}, δint (send) = receive, δint (receive) = receive, δext (receive, e, (receive, ball)) = send, δext (send, e, x) = send, λ(send) = (send, ball), λ(receive) = ∅, ta(send) = 0.5, ta(receive) = ∞.
Seznam je pˇrevzat z prezentace B.P. Zeiglera na konferenci Mosim08: Mod´elisation, Optimisation et Simulation des Systmes, March 31-April 2 2008, Paris, France. 3 SmallDEVS umoˇ nuje pro modelov´ an´ı pouˇz´ıt kromˇe kasick´eho pˇr´ıstupu k objektov´e orientaci, zaloˇzen´eho na tˇr´ıd´ ach, tak´e jin´ y, flexibilnˇejˇs´ı pˇr´ıstup, kter´ y bude pops´ an v kapitole 5. Na tomto m´ıstˇe ale z˚ ustaneme u klasick´eho pˇr´ıstupu, kter´ y je zcela konformn´ı s bˇeˇznˇe pouˇz´ıvan´ ymi n´ astroji pro modelov´ an´ı a simulaci na b´ azi formalismu DEVS. Pˇr´ıklady zde uveden´e lze tedy jednoduˇse adaptovat pro libovoln´ yz alternativn´ıch n´ astroj˚ u. 4 Specifikaci syst´emu jsme rozˇs´ıˇrili o poˇc´ ateˇcn´ı stav s0 ∈ S.
´ POUZIT ˇ ´I FORMALISMU DEVS 2.7. PRAKTICKE
17
s0 = send. V praktick´ ych implementac´ıch formalismu DEVS atomick´ y model definuje mnoˇzinu vstupn´ıch a v´ ystupn´ıch port˚ u, mnoˇzinu stavov´ ych promˇenn´ ych, funkci posuvu ˇcasu, pˇrechodov´e funkce (intern´ı a extern´ı), v´ ystupn´ı funkci a poˇc´ateˇcn´ı stav. N´ asleduje implementace modelu P ingP ongP layer v prostˇred´ı SmallDEVS.
AtomicDEVS subclass : #PingPongPlayer instanceVariableNames : ’phase ’
initialize super i n i t i a l i z e . phase ←#send . s e l f addInputPortNamed: #receive . s e l f addOutputPortNamed: #send . extTransition (phase = #receive ) & (( s e l f peekFrom: #receive ) = #ball ) ifTrue : [ phase ←#send ] intTransition phase = #send ifTrue : [ phase ←#receive ] . timeAdvance phase = #send ifTrue : [ ↑ 0.5 ] . phase = #receive ifTrue : [ ↑ Float infinity ] . outputFnc phase = #send ifTrue : [ s e l f poke : #ball to : #send ] .
Druh´ y hr´aˇc by mˇel b´ yt v poˇc´ateˇcn´ım stavu pasivn´ı, od prvn´ıho se liˇs´ı jen poˇc´ateˇcn´ım stavem: InitiallyP assiveP ingP ongP layer = (X, S, Y, δint , δext , λ, ta, s0 ), kde
X, S, Y, δint , δext , λ, ta jsou definov´any stejnˇe jako v modelu P ingP ongP layer, s0 = receive.
V objektovˇe orientovan´e implementaci formalismu DEVS m˚ uˇzeme vyuˇz´ıt dˇediˇcnosti – v modelu InitiallyP assiveP ingP ongP layer, dˇed´ıc´ıho difinici modelu P ingP ongP layer, novˇe definujeme pouze inicializaˇcn´ı metodu, kter´a nstavuje poˇc´ateˇcn´ı stav.
PingPongPlayer subclass : #InitiallyPassivePingPongPlayer initialize super i n i t i a l i z e . phase ←#receive .
Syst´em dvou hr´aˇc˚ u je specifikov´an jako sloˇzen´ y DEVS P ingP ong = (X, Y, D, {Md }, EIC, IC, EOC, select),
18 kde
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
X = Y = {}, D = {P layerA, P layerB}, {Md } = {P ingP ongP layerP layerA , InitiallyP assiveP ingP ongP layerP layerB }, EIC = EOC = {}, IC = {(P layerA.send, P layerB.receive), (P layerB.send, P layerA.receive)}, ∀m ∈ 2D − {} : select(m) = P layerA.
Specifikace sloˇzen´eho modelu v praktick´ ych iplementac´ıch DEVS obsahuje mnoˇzinu submodel˚ u, mnoˇzinu vlastn´ıch vstupn´ıch a v´ ystupn´ıch port˚ u, specifikaci propojen´ı mezi porty jednotliv´ ych model˚ u. N´ asleduje implementace modelu hry Ping-Pong v prostˇred´ı SmallDEVS.
CoupledDEVS subclass : #PingPong
initialize super i n i t i a l i z e . s e l f addComponents: { #’Player A’ −> PingPongPlayer new. #’Player B’ −> InitiallyPassivePingPongPlayer new. }. s e l f addCouplings : { {#’Player A’ . #send} −> {#’Player B’ . #receive }. {#’Player B’ . #send} −> {#’Player A’ . #receive }. }.
Hierarchie simul´ ator˚ u zastˇreˇsen´a koˇrenov´ ym simul´ atorem je vytvoˇrena n´asleduj´ıc´ım k´odem – ten souˇcasnˇe odstartuje simulaci.
PingPong new getSimulator simulate : 1.5.
Pr˚ ubˇeh simulace je zaznamen´ an jako sekvence ud´alost´ı a zmˇen stavu. Na obr´ azku 2.5 je orientaˇcn´ı textov´ y z´aznam, generovan´ y bˇehem simulace, existuje ale moˇznost generovat z´aznam v XML pro pˇr´ıpadn´e dalˇs´ı zpracov´an´ı. Uveden´ y pˇr´ıklad demonstruje pouˇzit´ı formalismu DEVS pro vytvoˇren´ı modelu a n´asledn´e simulaˇcn´ı ovˇeˇren´ı jeho spr´ avn´e funkce (anal´ yzou logu lze z´ıskat potˇrebn´e informace o chov´an´ı syst´emu). Existuje samozˇrejmˇe moˇznost pouˇzit´ı model˚ u na b´azi DEVS k jin´ ym u ´ˇcel˚ um, napˇr. pro stochastickou simulaci. V takov´em pˇr´ıpadˇe je tˇreba pr˚ ubˇeˇznˇe sb´ırat data o vyuˇzit´ı zdroj˚ u, d´elk´ach front apod. Jinou moˇznost´ı je simulace v re´aln´em ˇcase, propojen´ a s re´aln´ ym okol´ım. K tomu je tˇreba zajistit komunikaci modelu s okol´ım a synchronizovat simulaci s re´aln´ ym ˇcasem. Model pak ch´apeme jako program s re´aln´ ymi vstupy a v´ ystupy. V´ yhodou tohoto zp˚ usobu programov´an´ı je konformita programu s pouˇzit´ ym formalismem, coˇz vytv´aˇr´ı prostor pro aplikaci matematick´ ych metod pro anal´ yzu a verifikaci. Moˇznost simulace syst´emu v simulovan´em prostˇred´ı pak umoˇzn ˇuje d˚ ukladn´e testov´an´ı vyv´ıjen´eho syst´emu v pr˚ ubˇehu v´ yvoje. Tomuto zp˚ usobu v´ yvoje syst´em˚ u ˇr´ık´ ame v´ yvoj zaloˇzen´ y na simulaci (simulation-based development). Jeden z moˇzn´ ych pˇr´ıstup˚ u k takov´emu vyuˇzit´ı simulaˇcn´ıho modelov´an´ı bude pops´ an v kapitole 5.
´ POUZIT ˇ ´I FORMALISMU DEVS 2.7. PRAKTICKE
****************** time: 0.5 * Internal Transition: aPingPong/Player A * New State: phase: #receive * Output Port Configuration: send: #event * Next scheduled internal transition at time Infinity * External Transition: aPingPong/Player B * Input Port Configuration: receive: #event * New State: phase: #send * Root DEVS Output Port Configuration: ****************** time: 1.0 * Internal Transition: aPingPong/Player B * New State: phase: #receive * Output Port Configuration: send: #event * Next scheduled internal transition at time Infinity * External Transition: aPingPong/Player A * Input Port Configuration: receive: #event * New State: phase: #send * Root DEVS Output Port Configuration: ****************** time: 1.5 * Internal Transition: aPingPong/Player A * New State: phase: #receive * Output Port Configuration: send: #event * Next scheduled internal transition at time Infinity * External Transition: aPingPong/Player B * Input Port Configuration: receive: #event * New State: phase: #send * Root DEVS Output Port Configuration:
Obr´azek 2.5: Z´aznam pr˚ ubˇehu simulace
19
20
´ ´ ´IMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN
Kapitola 3
Syst´ emy s dynamicky se mˇ en´ıc´ı strukturou Syst´emy, u kter´ ych se pˇredpokl´ ad´ a adaptace a v´ yvoj, ch´apeme obecnˇe jako syst´emy s dynamickou strukturou. Modelov´an´ı a simulace takov´ ych syst´em˚ u mus´ı nutnˇe zahrnout fenom´eny jako: • mˇen´ıc´ı se vazby mezi komponentami, • dynamicky vznikaj´ıc´ı a zanikaj´ıc´ı komponenty, • dynamicky se mˇen´ıc´ı definice atom˚ u. Modifikace struktury modelu lze obecnˇe doc´ılit rozˇs´ıˇren´ım simulaˇcn´ıho modelov´an´ı o moˇznost vyj´adˇrit reflektivn´ı vlastnosti syst´emu. Princip syst´emov´e reflexe tkv´ı v tom, ˇze syst´em vid´ı svoji vlastn´ı specifikaci a je schopen do n´ı dynamicky zasahovat. Tyto z´asahy jsou syst´emem bezprostˇrednˇe reflektov´any, tj. maj´ı okamˇzit´ y vliv na jeho strukturu a chov´an´ı. Problematikou reflexe v softwarov´ ych syst´emech se zab´ yv´ a ˇrada autor˚ u, napˇr. [Mae87, MMWY92, Paw98, TUN06, LRS01]. V oblasti form´ aln´ıch model˚ u syst´em˚ u s diskr´etn´ımi ud´alostmi lze uv´est vyv´ıjej´ıc´ıc´ı se Petriho s´ıtˇe [ABPD96] a r˚ uzn´e varianty zaveden´ı strukturn´ı dynamiky do formalismu DEVS, jako je DSDEVS [Bar97] a Dynamic DEVS [Uhr01]. Zat´ımco DSDEVS umoˇ nuje dynamiku na u ´rovni sloˇzen´ ych model˚ u a je konkr´etnˇe implementov´an napˇr. v ADEVS, Dynamic DEVS (kter´ y bude uveden v n´asledujc´ıc´ım textu) je definov´an obecnˇeji – dynamika je moˇzn´ a i na u ´rovni atomick´ ych model˚ u. Definice Dynamic DEVS zav´ad´ı strukturn´ı pˇrechody, kter´e mˇen´ı nikoliv stav, ale model (princip je na obr. 3.1, strukturn´ı pˇrechody jsou zn´ azornˇeny teˇckovanˇe). Pro vˇsechny pˇr´ıstupy, kter´e zav´adˇej´ı strukturn´ı dynamiku, plat´ı, ˇze syst´em s mˇen´ıc´ı se strukturou je vˇzdy specifikovaten´ y jako syst´em statick´ y. To znamen´a, ˇze je simulovateln´ y ekvivalentn´ım syst´emem se statickou strukturou, jehoˇz stavov´ y prostor je rozˇs´ıˇren tak, aby zahrnoval vˇsechny varianty a pˇrechodov´e funkce zahrnuj´ı specifikaci pˇrechodov´ ych funkc´ı vˇsech variant.
3.1
Dynamick´ y DEVS
Dynamick´ y DEVS Dynamick´ y model je struktura [Uhr01] DynM = (X, Y, m0 , M (m0 )),
22
´ ˇ ´IC´I STRUKTUROU KAPITOLA 3. SYSTEMY S DYNAMICKY SE MEN
Obr´azek 3.1: Strukturn´ı pˇrechody [Uhr01] kde
X je mnoˇzina vstupn´ıch ud´alost´ı, Y je mnoˇzina v´ ystupn´ıch ud´alost´ı, m0 ∈ M (m0 ) je poˇc´ateˇcn´ı model, M (m0 ) je nejmenˇs´ı mnoˇzina se strukturou {(S, s0 , δint , δext , ρ, λ, ta)| S je mnoˇzina stav˚ u, s0 ∈ S je poˇc´ateˇcn´ı stav, δint : S −→ S je intern´ı pˇrechodov´a funkce, δext : Q × X −→ S je extern´ı pˇrechodov´a funkce, kde Q = {(s, e) | s ∈ S, 0 ≤ e ≤ ta(s)} je mnoˇzina u ´pln´ ych stav˚ u, ρ : S −→ M (m0 ) je funkce pˇrechodu mezi modely, λ : S −→ Y je v´ ystupn´ı funkce, + ta : S −→ R0 ∪ {∞} je funkce posuvu ˇcasu}, splˇ nuj´ıc´ı podm´ınku ∀n ∈ M (m0 ) : (∃m ∈ M (m0 ) : n = ρ(sm ), sm ∈ S m ) ∨ n = m0 .
Dynamick´ y sloˇ zen´ y DEVS Dynamick´ y sloˇzen´ y model je struktura [Uhr01] DynN = (X, Y, n0 , N (n0 )), kde
X je mnoˇzina vstupn´ıch ud´alost´ı, Y je mnoˇzina v´ ystupn´ıch ud´alost´ı, m0 ∈ M (m0 ) je poˇc´ateˇcn´ı model (poˇc´ateˇcn´ı konfigurace), N (n0 ) je nejmenˇs´ı mnoˇzina se strukturou {(D, ρN , {DynMd }, {Id }, {Zi,d }, select)| D je mnoˇzina jmen submodel˚ u, ρN : SSS −→ M (m0 ) je funkce pˇrechodu mezi modely, kde SSS = ×d∈D,m∈DynMd S m , {DynMd |d ∈ D} je mnoˇzina submodel˚ u, {Id |d ∈ D ∪ {self }} je specifikace propojen´ı, ∀d ∈ D ∪ self : Id ⊆ D ∪ {self }, d ∈ / Id , {Zi,d |i ∈ Id , d ∈ D ∪ {self }} je specifikace pˇrekladu ud´alost´ı, Zi,d : X −→ Xd pro i = self , Zi,d : Yi −→ Y pro d = self , Zi,d : Yi −→ Xd pro i 6= self a d 6= self ,
´ ´ DEVS 3.2. ABSTRAKTN´I SIMULATOR PRO DYNAMICKY
23
select : 2D − {} −→ D je preferenˇcn´ı funkce}, splˇ nuj´ıc´ı podm´ınku ∀n ∈ N (m0 ) : (∃m ∈ N (m0 ) : n = ρN (sssm ), sssm ∈ SSS m ) ∨ n = n0 .
3.2
Abstraktn´ı simul´ ator pro dynamick´ y DEVS
Abstraktn´ı koˇ renov´ y simul´ ator Promˇenn´e: Podˇr´ızen´ y simul´ ator child, ˇcas zaˇc´atku a konce simulace tBEGIN , tEN D , aktu´aln´ı ˇcas t a ˇcas n´asleduj´ıc´ı pl´ anovan´e ud´alosti tnext . Algoritmus: t := tBEGIN poˇsli (i, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, s, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext dokud t < tEN D opakuj: poˇsli (∗, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, s, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext Abstraktn´ı simul´ ator atomick´ eho modelu Promnn´e: Aktu´aln´ı model m, ˇcas posledn´ı ud´alosti tlast , ˇcas n´asleduj´ıc´ı ud´alosti tnext , v´ ystup y, u ´pln´ y stav (sm , e) a nadˇrazen´ y simul´ ator parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: tlast := t − e tnext := tlast + ta(sm ) poˇsli (done, sm , tnext ) nadˇrazen´emu simul´ atoru parent Na zpr´ avu (∗, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: m y := λ(s ) poˇsli (y, t) nadˇrazen´emu simul´ atoru parent m m s := δint (s ) m := ρ(sm ) tlast := t tnext := tlast + ta(sm ) poˇsli (done, sm , tnext ) nadˇrazen´emu simul´ atoru parent Na zpr´ avu (x, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: e := t − tlast sm := δext (sm , e, x) m := ρ(sm ) tlast := t tnext := tlast + ta(sm ) poˇsli (done, sm , tnext ) nadˇrazen´emu simul´ atoru parent Abstraktn´ı simul´ ator (koordin´ ator) sloˇ zen´ eho modelu Promˇenn´e: Aktu´aln´ı model n, stav sn , ˇcas posledn´ı ud´alosti tlast , ˇcas n´asleduj´ıc´ı ud´alosti tnext , v´ ystup y, seznam
24
´ ˇ ´IC´I STRUKTUROU KAPITOLA 3. SYSTEMY S DYNAMICKY SE MEN
n´asleduj´ıc´ıch ud´alost´ı v submodelech eventList, mnoˇzina submodel˚ u s ud´alostmi pl´ anova´ ymi na aktu´aln´ı ˇcas imminent, vybran´ y submodel d, seznam submodel˚ u pro pˇred´ an´ı vstupu receivers, nadˇrazen´ y simul´ ator parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: ∀d ∈ D : poˇsli (i, t) simul´ atoru d poˇckej na (done, s, tnext ) od vˇsech receivers aktualizuj sn aktualizuj eventList tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, sn , tnext ) nadˇrazen´emu simul´ atoru Na zpr´ avu (∗, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: imminent := {d|(d, tdnext ) ∈ eventList, tdnext = t} d := select(imminent) poˇsli (∗, t) simul´ atoru d poˇckej na (y, t) od simul´ atoru d je-li d ∈ Iself a Zd,self (y) 6= ∅, pak: yself = Zd,self (y) poˇsli (yself , t) nadˇrazen´emu simul´ atoru parent receivers := {d|d ∈ D, self ∈ Id , Zself,d (x) 6= ∅} ∀d ∈ receivers : xd := Zself,d (x) poˇsli (xd , t) simul´ atoru d poˇckej na (done, s, tnext ) od vˇsech receivers aktualizuj sn Dold := D n := ρn (sn ) ∀d ∈ D − Dold : poˇsli (init, t) simul´ atoru d poˇckej na (done, s, tnext ) od vˇsech d ∈ D − Dold aktualizuj sn aktualizuj eventList tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, sn , tnext ) nadˇrazen´emu simul´ atoru Na zpr´ avu (x, t) od nadˇrazen´eho simul´ atoru reaguj takto: receivers := {d|d ∈ D, self ∈ Id , Zself,d (x) 6= ∅} ∀d ∈ receivers : xd := Zself,d (x) poˇsli (xd , t) simul´ atoru d poˇckej na (done, s, tnext ) od vˇsech receivers aktualizuj sn Dold := D n := ρn (sn ) ∀d ∈ D − Dold : poˇsli (init, t) simul´ atoru d poˇckej na (done, s, tnext ) od vˇsech d ∈ D − Dold aktualizuj sn aktualizuj eventList
3.3. APLIKACE
25
tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, sn , tnext ) nadˇrazen´emu simul´ atoru Korektn´ı implementace V korektn´ı implementaci pˇri pˇrijet´ı zpr´ avy (∗, t) vˇzdy plat´ı t = tnext a pˇri pˇrijet´ı zpr´ avy (x, t) vˇzdy plat´ı tlast ≦ t ≦ tnext .
3.3
Aplikace
Dynamick´ y DEVS (DynDEVS) byl pouˇzit jako form´ aln´ı z´aklad syst´emu James [Uhr01] pro modelov´an´ı a simulaci agentn´ıch syst´em˚ u. Form´aln´ı model DynDEVS je koncipov´an jako uzavˇren´ y, neˇreˇs´ı problematiku klonov´an´ı a editaci model˚ u asynchronn´ımi z´asahy z vnˇejˇsku. Umoˇzn ˇuje vˇsak kromˇe vzniku a z´aniku model˚ u tak´e jejich migraci r´amci syst´emu, coˇz je pro multiagentn´ı syst´emy typick´e. Vzhledem k tomu, ˇze migraci prov´ad´ı model, kter´ y se chce pˇresunout, je pˇresun souˇc´asti jeho vlastn´ıho intern´ıho nebo extern´ıho pˇrechodu. V okamˇziku migrace je tedy v definovan´em stavu, pˇriˇcemˇz e = 0. V definici dynamick´eho DEVS tak nen´ı tˇreba pracovat s u ´pln´ ym stavem (s, e) a lze vystaˇcit jen s t´ım, ˇze inicializace novˇe pˇrid´ avan´ ych model˚ u spr´ avnˇe nastav´ı ˇcas posledn´ı a pl´ anovan´e ud´alosti. Ale v pˇr´ıpadˇe, ˇze celou simulaci ch´apeme jako otevˇren´ y syst´em se vstupy a v´ ystupy (pˇr´ıpadnˇe tak´e s vlastn´ım, nez´ avisl´ ym ˇcasem),1 mus´ıme se zab´ yvat asynchronn´ımi z´asahy z vnˇejˇs´ıho svˇeta. Pak jiˇz nevystaˇc´ıme se samotnou reflex´ı, jako v pˇr´ıpadˇe DynDEVS, ale mus´ıme zpˇr´ıstupnit reflektivn´ı rozhran´ı vnˇejˇs´ımu syst´emu. Pˇritom je tˇreba zajistit korektn´ı chov´an´ı pˇri klonov´an´ı model˚ u a editaˇcn´ıch operac´ıch v libovoln´em okamˇziku. Touto problematikou se zab´ yv´ a kapitola 4.
1
Otevˇren´e ch´ ap´ an´ı simulace s moˇznost´ı neomezenˇe klonovat a editovat modely je nezbytn´e pro interaktivn´ı evoluˇcn´ı v´ yvoj a u ´drˇzbu nepˇretrˇzitˇe bˇeˇz´ıc´ıch syst´em˚ u.
26
´ ˇ ´IC´I STRUKTUROU KAPITOLA 3. SYSTEMY S DYNAMICKY SE MEN
Kapitola 4
Otevˇ ren´ a abstraktn´ı architektura pro simulaci vyv´ıjej´ıc´ıch se syst´ em˚ u Kapitola definuje abstraktn´ı architekturu univerz´ aln´ıho syst´emu pro simulaci vyv´ıjej´ıc´ıch se syst´em˚ u. Nejprve jsou vymezeny poˇzadovan´e vlastnosti, pot´e je na z´akladˇe jejich anal´ yzy vytvoˇren n´avrh vhodn´e architektury a diskutov´any moˇznosti pouˇzit´ı.
4.1
Vymezen´ı poˇ zadovan´ ych vlastnost´ı
Syst´emy, kter´ ymi se hodl´ ame nad´ ale zab´ yvat a pro kter´e m´ ame v u ´myslu definovat vhodnou simulaˇcn´ı architekturu, lze charakterizovat jako • optimalizuj´ıc´ı, uˇc´ıc´ı se, adaptivn´ı syst´emy, • otevˇren´e, dynamicky zkoumateln´e a dynamicky editovateln´e syst´emy, • reflektivn´ı syst´emy. Vzhledem k pˇredpokl´ adan´emu zp˚ usobu pouˇzit´ı simulace v r´amci n´avrhu, v´ yvoje a u ´drˇzby syst´em˚ u mezi hlavn´ı poˇzadavky na podp˚ urn´e n´astroje patˇr´ı • simulace v re´aln´em ˇcase, propojen´ı simulace s okoln´ı realitou, • klonov´an´ı a editace model˚ u v pr˚ ubˇehu simulace, • multisimulace – syst´emy simulac´ı, simulace simulac´ı, V n´asleduj´ıc´ım textu budou jednotliv´e poˇzadavky podrobnˇe analyzov´any a bude z nich odvozen n´avrh otevˇren´e architektury pro modelov´an´ı a simulaci vyv´ıjej´ıc´ıch se syst´em˚ u.
4.2
Simulace v re´ aln´ em ˇ case, propojen´ı s re´ aln´ ym okol´ım
Re´ aln´ yˇ cas Pˇri simulaci modelu v re´aln´em ˇcase plyne ˇcas modelu stejnˇe rychle jako ˇcas re´aln´ y. Ot´azkou z˚ ust´av´a konkr´etn´ı hodnota ˇcasov´eho u ´daje, resp. mapov´an´ı mezi hodnotou svˇetov´eho ˇcasu a ˇcasu modelu. Lze rozliˇsit dva pˇr´ıpady:
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
28
Lok´ aln´ı re´ aln´ yˇ cas. Tok ˇcasu pˇri simulaci v re´aln´em ˇcase m˚ uˇze b´ yt ch´ap´an jako re´aln´ y ˇcas bˇehu modelu. V takov´em pˇr´ıpadˇe hodnota ˇcasu v dan´em okamˇziku ud´av´a re´alnou dobu, po jakou model od sv´eho startu bˇeˇzel. Je-li simulace pˇreruˇsena, re´aln´ y ˇcas bˇehu modelu z˚ ust´av´a konstantn´ı, je tak´e pozastaven. Po opˇetovn´em spuˇstˇen´ı hodnota ˇcasu nar˚ ust´a plynule od hodnoty ˇcasu v okamˇziku pˇreruˇsen´ı. Toto ch´ap´ an´ı re´aln´eho ˇcasu modelu je souladu s definic´ı syst´emu – jde o ˇcas, v kter´em syst´em existuje. Zastaven´ı simulace znamen´a, ˇze syst´em v dobˇe, kdy je simulace zastavena, neexistuje a jeho existence pokraˇcuje aˇz po opˇetovn´em spuˇstˇen´ı simulace. Zastavov´an´ı a spouˇstˇen´ı simulace jsou operace, kter´e model nevn´ım´a a pokud mu metasyst´em (okoln´ı realita) tuto informaci neposkytne, ˇzije model ve sv´em ˇcase, aniˇz by vidˇel nˇejak´e pˇreruˇsen´ı. Glob´ aln´ı re´ aln´ yˇ cas. Tok tohoto ˇcasov´eho u ´daje nelze ˇz´adn´ ym zp˚ usobem ovlivnit, natoˇz zastavit. M´ a-li model pracovat s glob´aln´ım re´aln´ ym ˇcasem, pozastaven´ı simulace zp˚ usob´ı probl´em – simulace se opozd´ı oproti re´aln´emu ˇcasu. Po opˇetovn´em spuˇstˇen´ı se se zpoˇzdˇen´ım provedou akce, pl´ anovan´e na dobu, kdy byla simulace pˇreruˇsena. Hodnota zpoˇzdˇen´ı (latence) m˚ uˇze b´ yt v nˇekter´ ych aplikac´ıch kritick´a. Nedodrˇzen´ı ˇcasov´eho r´ amce (timeoutu) pro provedne´ı akce je ch´ap´ ano jako selh´ an´ı a mus´ı b´ yt syst´emem detekov´ano. To vyˇzaduje dodat ˇcasov´a omezen´ı do modelu a tato omezen´ı v pr˚ ubˇehu simulace hl´ıdat. V nˇekter´ ych pˇr´ıpadech je v´ yhodn´e pouˇz´ıt proporcion´ aln´ı ˇcas. Rychlost toku modelov´eho ˇcasu vzhlem k r´ aln´emu ˇcasu je pak d´ana koeficientem, tzv. RT-fakorem. Simulace je tedy na re´aln´em ˇcase z´avisl´a, ale bˇeˇz´ı bud’ zrychlenˇe, nebo zpomalenˇe. Simulace v re´ aln´ em ˇ case Simulaci je moˇzn´e synchronizovat s re´aln´ ym ˇcasem a propojit simulovan´e a re´aln´e entity do jednoho celku.1 Z´akladn´ım pˇredpokladem je dostateˇcnˇe rychl´e prov´adˇen´ı jednotliv´ ych krok˚ u simulace. Pak staˇc´ı po kaˇzd´em kroku poˇckat na hodnotu re´aln´eho ˇcasu rovnou ˇcasu n´asleduj´ıc´ı ud´alosti v simulaˇcn´ım ˇcase a pak prov´est dalˇs´ı krok. Probl´emem, kter´ y je tˇreba ˇreˇsit v pˇr´ıpadˇe distribuovan´e RT simulace, je synchronizace hodin na vˇsech uzlech. Moˇzn´ ym ˇreˇsen´ım je jeden ze simulaˇcn´ıch uzl˚ u je prohl´asit za referenˇcn´ı, ostatn´ı se pak podle nˇeho synchronizuj´ı. Vstupnˇ e-v´ ystupn´ı aktivity Interakce simul´ atoru s vnˇejˇs´ım svˇetem je realizov´ana s vyuˇzit´ım prostˇredk˚ u operaˇcn´ıho syst´emu. Z hlediska modelu se interakce s re´aln´ ym okol´ım ˇreˇs´ı speci´aln´ımi komponentami (modely), doplnˇen´ ymi o moˇznost pos´ılat data do vnˇejˇs´ıho prostˇred´ı a pˇrij´ımat asynchronnˇe pˇrich´azej´ıc´ı data z vnˇejˇs´ıho prostˇred´ı (viz napˇr. [Hu04]). V atomick´em modelu, reprezentuj´ıc´ım rozhran´ı na vnˇejˇs´ı svˇet, bˇeˇz´ı tzv. vstupnˇe-v´ ystupn´ı aktivita. Jde o proces (nebo mnoˇzinu proces˚ u) operaˇcn´ıho syst´emu,2 realizuj´ıc´ı v´ ystupy a ˇcekaj´ıc´ı na moˇzn´e vstupy. Z procesu vstupnˇe-v´ ystupn´ı aktivity atomick´eho modelu m˚ uˇze b´ yt kdykoli asynchronnˇe (tj. nez´ avisle na procesu simulace) aktualizov´an stav atomick´eho modelu. Pˇri kaˇzd´e takov´e zmˇenˇe mus´ı proces vstupnˇe-v´ ystupn´ı aktivity okamˇzitˇe aktualizovat tnext := clock hodnotou aktu´aln´ıho re´aln´eho ˇcasu a signalizovat tzv. stavovou ud´ alost 1
Toto d´ av´ a smysl napˇr. v nˇekter´ ych f´ az´ıch v´ yvoje ˇr´ıdic´ıch syst´em˚ u – po otestov´ an´ı modelu ˇr´ıdic´ıho syst´emu (pˇresnˇeji ˇr´ıdic´ıho syst´emu realizovan´eho jako model) v simulovan´em prostˇred´ı (obsahuj´ıc´ım simulovan´ y ˇr´ızen´ y syst´em) se simulovan´e prostˇred´ı nahrad´ı rozhran´ım na re´ aln´e okol´ı (a re´ aln´ y ˇr´ızen´ y syst´em). 2 Pojem operaˇcn´ı syst´em zde zahrnuje jak´ekoliv v´ ypoˇcetn´ı prostˇred´ı, ve kter´em simul´ ator bˇeˇz´ı, tj. napˇr´ıklad JVM, Smalltalk, stejnˇe tak, jako napˇr. UNIX apod.
´ EM ´ CASE, ˇ ´ YM ´ OKOL´IM 4.2. SIMULACE V REALN PROPOJEN´I S REALN
29
zasl´ an´ım zpr´ avy (se, tnext ) nadˇrazen´emu simul´ atoru. Simul´ ator sloˇzen´eho modelu si v reakci na tuto zpr´ avu aktualizuje tnext pro podˇr´ızenou komponentu v seznamu eventList, aktualizuje si vlastn´ı tnext a poˇsle zpr´ avu (se, tnext ) sv´emu nadˇrazen´emu simul´ atoru. Koˇrenov´ y simul´ ator si v reakci na (se, tnext ) aktualizuje tnext , takˇze v n´asleduj´ıc´ım kroku m˚ uˇze pˇr´ısluˇsn´ y atomick´ y model na stavovou ud´alost zareagovat intern´ım pˇrechodem. Reakce simul´ atoru na zpr´ avy pˇrich´azej´ıc´ı z r˚ uzn´ ych proces˚ u (z procesu koˇrenov´eho simul´ atoru a z proces˚ u aktivit v atomech) mus´ı b´ yt kv˚ uli pˇr´ıstupu ke sd´ alen´ ym promˇenn´ ym simul´ atoru synchronizov´any. Abstraktn´ı simul´ ator pro bˇ eh v re´ aln´ em ˇ case Pˇredpokl´ adejme, ˇze clock je pseu3 dopromˇenn´ a, obsahuj´ıc´ı v kaˇzd´em okamˇziku aktu´aln´ı hodnotu re´aln´eho ˇcasu. Na zaˇc´atku simulace je tˇreba synchronizovat ˇcas modelu a hodiny re´aln´eho ˇcasu (clock) – lze nastavit bud’ tBEGIN := clock, nebo clock := tBEGIN . V prvn´ım pˇr´ıpadˇe pracujeme s glob´aln´ım ˇcasem, v druh´em pˇr´ıpadˇe pracujeme ˇcasem re´aln´eho bˇehu modelu (hodnota clock ud´av´a re´alnou dobu bˇehu od spuˇstˇen´ı). Algoritmus koˇrenov´eho simul´ atoru pro simulaci v re´aln´em ˇcase vypad´ a takto: synchronizuj clock a tBEGIN t := tBEGIN poˇsli (i, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext dokud clock < tEN D opakuj: ˇcekej na clock = t nebo na pˇreruˇsen´ı zpr´ avou (se, tnext ) 4 proved’ synchronizovanˇe: t := min{clock, tnext , t} poˇsli (∗, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext Na zpr´ avu (se, tnext ) reaguj synchronizovanˇe takto: t := tnext Simul´ ator atomick´eho modelu z kap. 2 dopln´ıme takto: Na zpr´ avu (se, tnext ) reaguj synchronizovanˇe takto: t := tnext Poˇsli zpr´ avu (se, tnext ) nadˇrazen´emu simul´ atoru Na ostatn´ı zpr´ avy reaguj stejnˇe jako v kap. 2, ale synchronizovanˇe. Simul´ ator sloˇzen´eho modelu z kap. 2 dopln´ıme takto: Na zpr´ avu (se, tnext ) od podˇr´ızen´eho simul´ atoru d reaguj synchronizovanˇe takto: eventList := (eventList − {(d, )}) ∪ {(d, tdnext )} t := tnext 3 Pseudopromˇenn´ a je promˇenn´ a, do kter´e v dom´enov´e u ´rovni nelze pˇriˇradit hodnotu, tj. je pro model k dispozici pouze pro ˇcten´ı. 4 Pod pojmem synchronizovan´e proveden´ı m´ ame na mysli kritickou sekci hl´ıdanou semaforem pro pˇr´ıstup k promˇenn´ ym simul´ atoru.
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
30
Poˇsli zpr´ avu (se, tnext ) nadˇrazen´emu simul´ atoru Na ostatn´ı zpr´ avy reaguj stejnˇe jako v kap. 2, ale synchronizovanˇe. Aktivace a deaktivace vstupnˇ e-v´ ystupn´ıch aktivit Aktivity atomick´ ych model˚ u se startuj´ı v okamˇziku spuˇstˇen´ı simulace. Pˇri zastaven´ı simulace by mˇely b´ yt ukonˇceny. Toto je v´ yznamn´ y poˇzadavek zejm´ena v situaci, kdy dovol´ıme editaci modelu – pro takov´e z´asahy se simulace pˇrechodnˇe zastav´ı a po proveden´ı operace se znovu spust´ı. Kop´ırov´an´ı, serializace apod. jsou bezpeˇcn´e jen tehdy, kdyˇz model neobsahuje ˇz´adn´e bˇeˇz´ıc´ı procesy. Toto lze realizovat tak, ˇze ke spuˇstˇen´ı vstupnˇe-v´ ystupn´ıch aktivit atomick´eho modelu dojde v reakci na zpr´ avu (i, t) a zastaven´ı aktivit se provede v reakci na zpr´ avu (sync, t),5 kterou zavedeme v n´asleduj´ıc´ı sekci pro potˇreby klonov´an´ı model˚ u. Koˇrenov´ y simul´ ator je pak tˇreba upravit tak, aby pˇri kaˇzd´em startu a zastaven´ı pos´ılal podˇr´ızen´emu simul´ atoru zpr´ avy (i, t) a (sync, t). Rozˇ s´ıˇ ren´ a definice atomick´ eho modelu Pro u ´plnost uvedeme jeˇstˇe rozˇs´ıˇrenou definici atomick´eho modelu, kter´ y je urˇcem pro simulaci v re´ aln´em ˇcase a umoˇzn´ı dynamick´e klonov´an´ı a editaci (jak bude uk´az´ano d´ale). Atomick´y model se stavem a vstupnˇe-v´ystupn´ı aktivitou je specifikov´an algebraickou strukturou M = (X, S, Y, δint , δext , λ, ta, s0 , (s, e), α), kde
(X, S, Y, δint , δext , λ, ta) je DEVS, s0 ∈ S je poˇc´ateˇcn´ı stav, (s, e) ∈ Q je aktu´aln´ı tot´aln´ı stav, α je vstupnˇe v´ ystupn´ı aktivita.
Vstupnˇe-v´ ystupn´ı aktivita α bˇeˇz´ı v re´aln´em ˇcase a nez´ avisle na simulaci ovlivˇ nuje stav s ∈ S. Pˇri kaˇzd´e modifikaci stavu s ∈ S oznamuje simul´ ator nadˇrazen´emu simul´ atoru stavovou ud´alost (se, t) s hodnotou aktu´aln´ıho re´aln´eho ˇcasu. Aktivita α rozum´ı zpr´ av´am (suspendActivity) a (resumeActivity). Rozˇ s´ıˇ ren´ a definice sloˇ zen´ eho modelu Sloˇzen´y model se stavem je definov´an libovol6 nou ze struktur N = (X, Y, D, {Md }, {Id }, {Zi,d }, select), N = (X, Y, D, {Md }, EIC, IC, EOC, select), kde
5
X, Y , D, {Id }, {Zi,d }, select, EIC, EOC, IC jsou definov´any stejnˇe jako v klasick´e definici (viz kap. 2), {Md |d ∈ D} je mnoˇzina submodel˚ u, pˇriˇcemˇz submodelem je bud’ atomick´ y model se stavem a vstupnˇe-v´ ystupn´ı aktivitou, nebo sloˇzen´ y model se stavem.
V simulaˇcn´ım prostˇred´ı SmallDEVS (viz kap. 5) je zastavov´ an´ı a spouˇstn´ı vstupnˇe-v´ ystupn´ıch aktivit implementov´ ano metodami atomick´eho modelu prepareToStop a prepareToStart. Tyto metody jsou zdˇedˇen´e jako pr´ azdn´e a v kaˇzd´em modelu, kter´ y implementuje rozhran´ı na realitu mus´ı b´ yt adekv´ atnˇe implementov´ any. 6 Jejich souvislost byla vysvˇetlena v kap. 2.
´ ´I A MIGRACE SYSTEM ´ U ˚ A SIMULAC´I 4.3. KLONOVAN
4.3
31
Klonov´ an´ı a migrace syst´ em˚ u a simulac´ı
DynDEVS (viz kap. 3, [Uhr01]) ˇreˇs´ı problematiku sebemodifikace modelu, kdy ke zmˇenˇe modelu doch´az´ı v r´ amci pl´ anovan´ ych ud´alost´ı v pr˚ ubˇehu simulace. Neˇreˇs´ı ani problematiku klonov´an´ı, ani vazbu na vnˇejˇs´ı prostˇred´ı, a tedy ani asynchronn´ı editaˇcn´ı z´asahy do modelu z vnˇejˇs´ıho prostˇred´ı, vˇcetnˇe ovl´ ad´ an´ı simul´ atoru. Pr´avˇe tuto problematiku nyn´ı pop´ıˇseme a rozˇs´ıˇr´ıme abstraktn´ı simul´ ator DEVS tak, aby takov´e z´asahy umoˇznil. Kontinuace a DEVS Kontinuace je objekt, reprezentuj´ıc´ı pokraˇcov´an´ı v´ ypoˇctu. Je to sn´ımek, vytvoˇren´ y v libovoln´em okamˇziku z bˇeˇz´ıc´ıho procesu. S kontinuac´ı se pracuje jako s daty – lze ji uloˇzit, pˇren´est jinam, kop´ırovat apod. Kontinuace umoˇzn ˇuj´ı implementovat multitasking, klonov´an´ı a migraci proces˚ u, n´avraty v ˇcase, prohled´av´an´ı stavov´eho prostoru. Definice syst´emu i definice DEVS odpov´ıdaj´ı tomuto konceptu – syst´em s aktu´aln´ım stavem obsahuje veˇskerou potˇrebnou informaci k proveden´ı simulace, tj. ke generov´an´ı stavov´e trajektorie, tj. ke zjiˇstˇen´ı budouc´ıho chov´ an´ı. Dynamick´ e klonov´ an´ı a migrace V pˇr´ıpadˇe syst´emu s diskr´etn´ımi ud´alostmi je stav modelu v libovoln´em okamˇziku urˇcen u ´pln´ ym stavem (s, e). D´ıky uzavˇrenosti mnoˇziny syst´em˚ u vzhledem ke skl´ ad´ an´ı pro kaˇzd´ y sloˇzen´ y syst´em vˇzdy existuje ekvivalentn´ı z´akladn´ı syst´em s u ´pln´ ym stavem (s, e). Pˇritom s kaˇzd´ ym podsyst´emem lze nakl´ adat stejnˇe jako se sloˇzen´ ym syst´emem. K tomu, aby bylo moˇzn´e kdykoliv poˇr´ıdit sn´ımek (klon) syst´emu nebo jeho ˇc´asti, je tˇreba vhodnˇe doplnit abstraktn´ı simul´ ator. Pˇred kaˇzd´ ym klonov´an´ım a jin´ ymi operacemi nad bˇeˇz´ıc´ı simulac´ı je tˇreba form´ alnˇe aktualizovat u ´pln´ y stav modelu a od tohoto stavu pak po proveden´ı operace d´al pokraˇcovat. Vzhledem k tomu, ˇze syst´em je definov´an nez´ avisle na kontextu7 , je moˇzn´e bez probl´em˚ u nechat klon syst´emu d´al existovat v jin´em kontextu, neˇz v jak´em bˇeˇzel origin´ al. Je tak moˇzn´e realizovat migraci komponent mezi subsyst´emy v r´amci jedn´e simulace i mezi r˚ uzn´ ymi simulacemi.8 ´ Uprava abstraktn´ıho simul´ atoru pro potˇ reby dynamick´ e editace modelu – synchronizace simul´ ator˚ u Abstraktn´ı simul´ ator DEVS z kapitoly 2 implicitnˇe pˇripouˇst´ı moˇznost zastavov´an´ı a klonov´an´ı cel´e simulace – simul´ atory si potˇrebnou informaci pamatuj´ı a po okop´ırov´an´ı simulace plynule pokraˇcuje. Probl´em nast´ av´a v pˇr´ıpadˇe strukturn´ı editace model˚ u, t.j. pˇri manipulaci s jednotliv´ ymi komponentami ve smyslu klonov´an´ı, odstraˇ nov´an´ı a vkl´ad´ an´ı. Po takov´ ych operac´ıch je tˇreba prov´est korektn´ı inicializaci vˇsech komponent dˇr´ıve, neˇz nech´ame simulaci pokraˇcovat. Inicializace se na zaˇc´atku pokraˇcov´an´ı simulace mus´ı vˇzdy prov´est, aby byla aktualizov´ana hodnota tlast a tnext ve vˇsech komponent´ach (po pˇr´ıpadn´e editaci struktury se mohou tyto hodnoty st´at neaktu´ aln´ımi) a aby nadˇrazen´ y simul´ ator z´ıskal korektn´ı informaci o ˇcase n´asleduj´ıc´ı ud´alosti. 7
Syst´em nev´ı o hierarchicky nadˇrazen´em syst´emu ani o syst´emech, s nimiˇz je propojen. Na druh´e stranˇe, sloˇzen´ y syst´em zn´ a vˇsechny sv´e komponenty i jejich propojen´ı. 8 Toto je v pˇr´ıpadˇe jin´eho paradigmatu, jako je napˇr. objektov´ a orientace, probl´em – kontext objektu je d´ an vˇsemi dostupn´ ymi objekty. Vymˇenit kontext v pr˚ ubˇehu v´ ypoˇctu pak nen´ı tak jednoduch´e, jako je tomu v pˇr´ıpadˇe formalismu DEVS. Obˇe paradigmata vˇsak lze vhodnˇe kombinovat – objekty lze bez probl´em˚ u pouˇz´ıt uvnitˇr komponent DEVS a migraci omezit na komponenty DEVS.
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
32
Simul´ ator dynamick´eho DEVS [Uhr01] vˇzdy inicializuje pˇrid´ avan´e subsyst´emy. V naˇsem pˇr´ıpadˇe ale poˇc´ıt´ ame se vznikem nov´ ych subsyst´em˚ u klonov´an´ım s n´aslednou editac´ı, pˇriˇcemˇz k naklonov´an´ı syst´emu m˚ uˇze doj´ıt asynchronnˇe, v libovoln´em okamˇziku. Proto mus´ıme ˇreˇsit korektn´ı vytvoˇren´ı klonu tak, aby jeho n´asledn´ a inicializace v nov´em kontextu probˇehla spr´ avnˇe a aby klon mohl plynule pokraˇcovat v existenci. Simul´ ator atomick´eho modelu hodnotu e ˇcasu str´aven´eho ve stavu s standardnˇe aktualizuje pˇri zpracov´an´ı zpr´ avy (x, t) a tato hodnota je pouˇzita pouze pro v´ ypoˇcet δext (s, e, x). Pro nepˇretrˇzit´ y bˇeh simulace je to v poˇr´adku, ale chceme-li simulaci pˇreruˇsovat a manipulovat s jej´ımi kontinuacemi (ve smyslu klonov´an´ı, migrace, zpˇetn´eho navracen´ı apod.), mus´ıme tuto hodnotu aktualizovat v okamˇziku pˇreruˇsen´ı. Zavedeme proto novou zpr´ avu (sync, t).9 Simul´ ator na (sync, t) reaguje aktualizac´ı hodnoty uplynul´eho ˇcasu e. Pˇr´ıˇst´ı zpr´ ava (i, t) po opˇetovn´em odstartov´an´ı simulace pak spr´ avnˇe synchronizuje pokraˇcov´an´ı simulace. Vazba simul´ atoru na vnˇ ejˇ s´ı prostˇ red´ı, simul´ ator jako syst´ em Simul´ ator dan´eho modelu ch´apeme opˇet jako syst´em se vstupy a v´ ystupy. Vstupy jsou ud´alosti (start), (stop), (reset), (endT ime, t) a ud´alosti pˇredstavuj´ıc´ı poˇzadavky na editaˇcn´ı operace. Ty budou pops´ any v sekci 4.4. Sekvence v´ ystupn´ıch ud´alost´ı nese informaci o stavov´ ych trajektori´ıch a ud´alostn´ıch segmentech vˇsech submodel˚ u, vˇcenˇe zmˇen stavu samotn´eho simul´ atoru (spuˇstˇen, zastaven apod.). Jde o ud´alosti (intT r, t, M, y, s, s′ ), (extT r, t, M, x, e, s, s′ ), (simulationStarted, t) a (simulationStopped, t). Na editaˇcn´ı a in(tro)spekˇcn´ı operace syst´em reaguje informac´ı o struktuˇre a aktu´aln´ım stavu modelu, kter´eho se operace t´ yk´ a, tj. (model, M ) kde M je model se stavem (viz sekce 4.2). (start) (stop) (reset) (doSteps, n) (endTime, t) (inject, x) (editOp, object)
Simulator Command
X
Model S
Y
Output
(intTr, t, M, y, s, s’, tn) (extTr, t, M, x, (s, e), s’, tn) (simulationStarted, t) (simulationStopped, t) (model, M)
Obr´azek 4.1: Simul´ ator jako syst´em Rozˇ s´ıˇ ren´ı simul´ atoru atomick´ eho modelu Abstraktn´ı simul´ ator atomick´eho modelu dopln´ıme o reakci na zpr´ avu (sync, t). Kv˚ uli pˇr´ım´e souvislosti uvedeme i reakci na zpr´ avu (i, t), reakce na ostatn´ı zpr´ avy z˚ ust´avaj´ı stejn´e jako v kap. 2, jsou jen doplnˇeny o generov´an´ı ud´alost´ı odpov´ıdaj´ıc´ı zmˇen´ am stavu modelu (intT r, t, M, y, s, s′ ) a (extT r, t, M, x, e, s, s′ ) do vnˇejˇs´ıho prostˇred´ı. Na zpr´ avu (reset) od nadˇrazen´eho simul´ atoru parent reaguj takto: s := s0 e := 0 tlast := 0 tnext := ∞ poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent 9
Stejnou zpr´ avu jsme jiˇz pouˇzili v pˇredch. sekci k jin´emu u ´ˇcelu, a sice k zastaven´ı vstupnˇe-v´ ystupn´ı aktivity. Oba d˚ uvody k jej´ımu zaveden´ı jsou nez´ avisl´e a m˚ uˇze proto plnit oba u ´ˇcely souˇcasnˇe.
´ ´I A MIGRACE SYSTEM ´ U ˚ A SIMULAC´I 4.3. KLONOVAN
33
Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: tlast := t − e tnext := tlast + ta(s) poˇsli (resumeActivity) vstupnˇe-v´ ystupn´ı aktivitˇe α poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent Na zpr´ avu (sync, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: poˇsli (suspendActivity) vstupnˇe-v´ ystupn´ı aktivitˇe α e := t − tlast poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru parent Rozˇ s´ıˇ ren´ı simul´ atoru sloˇ zen´ eho modelu Abstraktn´ı simul´ ator sloˇzen´eho modelu dopln´ıme o reakci na zpr´ avu (sync, t). Kv˚ uli pˇr´ım´e souvislosti uvedeme i reakce na zpr´ avy (i, t) a (done, t), reakce na ostatn´ı zpr´ avy z˚ ust´avaj´ı stejn´e jako v kap. 2. Na zpr´ avu (reset) od nadˇrazen´eho simul´ atoru parent reaguj takto: ∀d ∈ D : poˇsli (reset) simul´ atoru d activeChildren := D Na zpr´ avu (i, t) od nadˇrazen´eho simul´ atoru parent reaguj takto (jako v kap. 2): ∀d ∈ D : poˇsli (i, t) simul´ atoru d activeChildren := D Na zpr´ avu (sync, t) od nadˇrazen´eho simul´ atoru parent reaguj takto: ∀d ∈ D : poˇsli (sync, t) simul´ atoru d activeChildren := D Na zpr´ avu (done, tnext ) od podˇr´ızen´eho simul´ atoru d reaguj takto (jako v kap. 2): eventList := (eventList − {(d, )}) ∪ {(d, tdnext )} activeChildren := activeChildren − {d} Je-li activeChildren = ∅, pak: Je-li posledn´ı zpr´ ava od nadˇrazen´eho simul´ atoru (i, t), d pak tlast := max{tlast |d ∈ D} Je-li posledn´ı zpr´ ava od nadˇrazen´eho simul´ atoru (∗, t), nebo (x, t), pak tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, tnext ) nadˇrazen´emu simul´ atoru Rozˇ s´ıˇ ren´ı koˇ renov´ eho simul´ atoru (ovl´ ad´ an´ı simulace) Koˇrenov´ y simul´ ator reaguje na 4 zpr´ avy z vnˇejˇs´ıho prostˇred´ı, slouˇz´ıc´ı k ovl´ ad´ an´ı simulace: (reset), (start), (stop), (endT ime, te). Do vnˇejˇs´ıho prostˇred´ı pos´ıl´a metaud´alosti (simulationStarted, t), (simulationStopped, t). Algoritmus: t := 0 tEN D := ∞ Na zpr´ avu (start) reaguj takto:
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
34
Jestliˇze p = nil, pak p := nov´ y proces: poˇsli (i, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext te := tEN D generuj metaud´alost (simulationStarted, t) dokud t < te opakuj: poˇsli (∗, t) podˇr´ızen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child t := tnext poˇsli (sync, t) podˇrzen´emu simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızen´eho simul´ atoru child generuj metaud´alost (simulationStopped, t) p := nil Na zpr´ avu (stop) reaguj takto: Jestliˇze t >= te a p = nil, generuj metaud´alost (simulationStopped, t) te := t Na zpr´ avu (reset) reaguj takto: poˇsli (reset) podˇr´ızen´emu simul´ atoru child poˇckej na (done, ) od podˇr´ızen´eho simul´ atoru child t := 0 te := 0 Na zpr´ avu (endT ime, te) reaguj takto: tEN D := te := te ´ Simulace v re´ aln´ em ˇ case Upravu v´ yˇse uveden´eho simul´ atoru pro bˇeh v re´aln´em ˇcase si na z´akladˇe jiˇz uveden´ ych informac´ı laskav´ y ˇcten´ aˇr provede s´ am.
4.4
ˇ Cten´ ı a modifikace modelu, dynamick´ e aplikaˇ cn´ı rozhran´ı simul´ atoru
V pˇredchoz´ı sekci byl pops´ an simul´ ator, reaguj´ıc´ı na operace pro ovl´ ad´ an´ı simulace a pˇripouˇstˇej´ıc´ı pˇri pozastaven´e simulaci prov´adˇet klonov´an´ı, migraci a editaci model˚ u. Nyn´ı dopln´ıme n´avrh dynamick´eho aplikaˇcn´ıho rozhran´ı simul´ atoru, kter´e umoˇzn´ı • dynamickou inspekci modelu a stavu simulace, • dynamickou zmˇenu vazeb mezi modely,modelsestavem • dynamick´e vytv´aˇren´ı a ruˇsen´ı model˚ u, • dynamickou editaci definice atom˚ u, • dynamick´e vytv´aˇren´ı, editace a ruˇsen´ı pomocn´ ych objekt˚ u.
ˇ ´I A MODIFIKACE MODELU 4.4. CTEN
35
Objekty Objekty, nad kter´ ymi jsou dynamicky (za bˇehu) k dispozici editaˇcn´ı operace, jsou prvky mnoˇzin • SIM U LAT ION S – mnoˇzina simulac´ı, • M ODELS – mnoˇzina model˚ u, • IN P ORT S – mnoˇzina vstupn´ıch port˚ u modelu, • OU T P ORT S – mnoˇzina v´ ystupn´ıch port˚ u modelu, • SLOT S – mnoˇzina stavov´ ych promˇenn´ ych modelu s asociovan´ ymi sloˇzkami aktu´al10 n´ıho stavu modelu, • M ET HODS – mnoˇzina funkc´ı, specifikuj´ıc´ıch atomick´ y model, • COU P LIN GS – mnoˇzina propojen´ı, specifikuj´ıc´ıch sloˇzen´ y model. Tyto mnoˇziny jsou hierarchicky organizov´any. Na obr. 4.2 je uk´azka hierarchie objekt˚ u 11 existuj´ıc´ıch na poˇc´atku simulace modelu PingPong z kapitoly 2. Nedoch´az´ı-li k z´asah˚ um do simulace z vnˇejˇsku, v pr˚ ubˇehu simulace se mˇen´ı pouze obsah slot˚ u atomick´ ych model˚ u. Operace Nad objektem o, resp. nad mnoˇzinou objekt˚ u O zavedeme tyto operace:12 • N EW – vytvoˇr´ı nov´ y objekt o (parametrem je jm´eno a specifikace objektu) a pˇrid´ a ho do mnoˇziny O, • COP Y – zkop´ıruje objekt o do promˇenn´e P AST EBU F F ER, • P AST E – vloˇz´ı kopii objektu uloˇzen´eho v promˇenn´e P AST EBU F F ER do mnoˇziny O, • DELET E – odstran´ı objekt o z mnoˇziny O, • CU T – odstran´ı objekt o z mnoˇziny O a um´ıst´ı ho do promˇenn´e P AST EBU F F ER, • REN AM E – pˇrejmenuje objekt o (parametrem je nov´e jm´eno) v mnoˇzinˇe O, • SAV E – uloˇz´ı objekt o do vstupnˇe v´ ystupn´ı promˇenn´e IO,13 • LOAD – vloˇz´ı objekt ze vstupnˇe v´ ystupn´ı promˇenn´e IO do mnoˇziny O,14 • EDIT – modifikuje specifikaci objektu o (parametrem je nov´a specifikace), • makrooperace sloˇzen´e z uveden´ ych operac´ı. 10
V objektovˇe orientovan´em prostˇred´ı zaloˇzen´em na prototypov´ ych objektech (viz kap. 5) pracujeme jeˇstˇe se speci´ aln´ımi sloty DELEGAT ES. 11 P˚ uvodn´ı model v kap. 2 je vytvoˇren z instanc´ı pˇredem pˇripraven´ ych tˇr´ıd, a jeho implementace obshuje i inicializaˇcn´ı metody, kter´e v pˇr´ıpadˇe, ˇze se zamˇeˇr´ıme jen na objekty simulace bez ohledu na zp˚ usob vytvoˇren´ı, nemaj´ı pro specifikaci modelu ˇz´ adn´ y v´ yznam, zn´ ame-li aktu´ aln´ı stav. Tˇr´ıdy a inicializace instanc´ı jsou implementaˇcn´ı detaily vynucen´e konkr´etn´ım prostˇred´ım a nemaj´ı pro simulaci v´ yznam. Ani definice DEVS s niˇc´ım takov´ ym nepoˇc´ıt´ a. 12 Lze potenci´ alnˇe definovat i jinou sadu operac´ı, kterou lze doc´ılit t´ehoˇz efektu. 13 Prakticky je objekt uloˇzen v textov´e podobˇe. 14 Prakticky probˇehne rekonstrukce objektu z textov´e reprezentace.
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
36 SIMULATIONS Ping Pong (Simulation) MODEL
Ping Pong (CoupleDEVS) MODELS
INPORTS
Player A (AtomicDEVS) INPORTS
METHODS
#receive
extTransition (phase = #receive) & ((self peekFrom: #receive) = #ball) ifTrue: [ phase := #send ]
OUTPORTS
OUTPORTS #send SLOTS phase #send
intTransition phase = #send ifTrue: [ phase := #receive ].
COUPLINGS {#’Player A’.#send}->{#’Player B’.#receive}. {#’Player B’.#send}->{#’Player A’.#receive}.
timeAdvance phase = #send ifTrue: [ ^ 0.5 ]. phase = #receive ifTrue: [ ^ Float infinity ]. outputFnc phase = #send ifTrue: [ self poke: #ball to: #send ]
Player B (AtomiDEVS) INPORTS
METHODS
#receive
extTransition (phase = #receive) & ((self peekFrom: #receive) = #ball) ifTrue: [ phase := #send ]
OUTPORTS #send SLOTS phase #send
intTransition phase = #send ifTrue: [ phase := #receive ]. timeAdvance phase = #send ifTrue: [ ^ 0.5 ]. phase = #receive ifTrue: [ ^ Float infinity ]. outputFnc phase = #send ifTrue: [ self poke: #ball to: #send ]
Obr´azek 4.2: Hierarchie objekt˚ u – sn´ımek stavu simulace PingPong Uveden´e operace lze bez omezen´ı aplikovat v libovoln´em okamˇziku na libovoln´e objekty. Jako pˇr´ıklad lze uv´est vˇsechny objekty na obr. 4.2. Pokud v´ ysledkem operace je funkˇcn´ı model, simulace m˚ uˇze pokraˇcovat. Jinak je simulace ukonˇcena kv˚ uli chybˇe. Jm´ ena objekt˚ u Operace jsou parametrizov´any jm´eny objekt˚ u a modifikuj´ı tyto objekty nebo mnoˇziny tyto objekty obsahuj´ıc´ı. Vzhledem k hierarchick´e struktuˇre model˚ u lze pro identifikaci objektu pouˇz´ıt pathname, tj. sekvenci jmen vˇsech objekt˚ u, kter´e jsou hierarchicky vnoˇreny a poˇzadovan´ y objekt obsahuj´ı, vˇcetnˇe jm´ena tohoto objektu. Napˇr. v syst´emu na obr. 4.2 m˚ uˇzeme objekt, odpov´ıdaj´ıc´ı v´ ystupn´ı funkci hr´aˇce B identifikovat jm´enem "SIMULATIONS/Ping Pong/MODEL/Ping Pong/Player B/METHODS/outputFnc".15 Editaˇ cn´ı z´ asahy do simulace z vnˇ ejˇ s´ıho prostˇ red´ı Uvaˇzujme situaci, kdy poˇzadavky na editaˇcn´ı operace pˇrich´azej´ı od vnˇejˇs´ıho syst´emu, napˇr. od uˇzivatele (viz obr. 4.3). Pokud 15
Vzhledem k tomu, ˇze nˇekter´e sloˇzky jm´ena lze eliminovat, aniˇz by doˇslo k nejednoznaˇcnosti, m˚ uˇzeme tent´ yˇz objekt jednoduˇseji identifikovat jm´enem "SIMULATIONS/Ping Pong/Player B/METHODS/outputFnc".
ˇ ´I A MODIFIKACE MODELU 4.4. CTEN
37
Simulator Command
X
Model
Y
Output
S
User interface User
Obr´azek 4.3: Architektura pro interaktivn´ı evoluˇcn´ı v´ yvoj simulace bˇeˇz´ı, pro kaˇzdou editaˇcn´ı operaci nad modelem je nutn´e pozastavit simulaci, prov´est poˇzadovanou operaci a pot´e simulaci znovu spustit: poˇsli (stop) koˇrenov´emu simul´ atoru poˇckej na (simulationStopped), proved’ editaˇcn´ı operaci, poˇsli (start) koˇrenov´emu simul´ atoru poˇckej na (simulationStarted) Pokud simulace nebˇeˇz´ı, provede se pˇr´ımo editaˇcn´ı operace. Na kaˇzd´ y realizovateln´ y poˇzadavek na editaˇcn´ı operaci simul´ ator zareaguje proveden´ım pˇr´ısluˇsn´e operace. Po proveden´ı editaˇcn´ı operace simul´ ator generuje v´ ystupn´ı ud´alost (model, M ), kde M je model, kter´eho 16 se editaˇcn´ı operace t´ ykala. Reflektivn´ı editaˇ cn´ı z´ asahy – sebemodifikace modelu Tento typ modifikace modelu umoˇzn ˇuje definice DynDEVS. Editace modelu je v pˇr´ıpadˇe formalismu DynDEVS podle [Uhr01] dovolena v r´amci intern´ıho nebo extern´ıho pˇrechodu. Vzhledem k tomu, ˇze algorimus simulace je synchronn´ı, je proveden´ı jak´ehokoli v z´asahu do modelu v tomto okamˇziku bezpeˇcn´e. Model m˚ uˇze ˇc´ıst a editovat s´ am sebe, ale nepˇr´ımo tak´e kontext, v kter´em se nach´az´ı. Nadˇrazen´ y model m´ a k dispozici stav vˇsech sv´ ych subsyst´em˚ u a souˇc´ast´ı tˇechto d´ılˇc´ıch stav˚ u mohou b´ yt poˇzadavky na editaˇcn´ı z´asahy v nadˇrazen´em modelu. Vzhledem k tomu, ˇze sloˇzen´ y syst´em je konceptu´alnˇe syst´em paraleln´ı, mus´ı nadˇrazen´ y syst´em ˇreˇsit konflikty editaˇcn´ıch z´asah˚ u, poˇzadovan´ ych v tomt´eˇz okamˇziku r˚ uzn´ ymi subsyst´emy souˇcasnˇe.17 V pˇr´ıpadˇe, ˇze operaci nelze prov´est, neprovede se. Informaci o kontextu, v kter´em se model nach´az´ı, m˚ uˇze z´ıskat jedinˇe prostˇrednictv´ım sv´ ych vstup˚ u – to lze zajistit vhodnou strukturou hierarchicky nadˇrazen´eho nadˇrazen´eho sloˇzen´eho modelu. N´ aˇs pˇr´ıstup je zaloˇzen na meta´ urovˇ nov´e architektuˇre simul´ atoru. Model ch´apeme jako syst´em dom´enov´e u ´rovnˇe, simul´ ator ch´apeme jako metasyst´em,18 kter´ y m´ a na vstupu frontu poˇzadavk˚ u na inspekci a editaci, vˇcetnˇe pˇr´ıpadn´ ych maker (skript˚ u). Fronta se vyprazdˇ nuje po kaˇzd´em kroku simulace, pˇriˇcemˇz vˇsechny provediteln´e poˇzadavky na editaci 16
Vˇcetnˇe aktu´ aln´ıho stavu a vˇcetnˇe pˇr´ıpadn´ ych submodel˚ u, viz definice v sekci4.2. Napˇr´ıklad pˇri proveden´ı intern´ıho pˇrechodu je generov´ an v´ ystup, kter´ y invokuje extern´ı pˇrechody v navazuj´ıc´ıch komponent´ ach. Ve vˇsech tˇechto pˇrechodech mohou b´ yt odpov´ıdaj´ıc´ı zmˇenou stavu poˇzadov´ any zmˇeny v nadˇrazen´em modelu. 18 V obou pˇr´ıpadech jde o syst´emy specifikovateln´e formalismem DEVS. 17
38
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
modelu jsou zpracov´any.19 Reflektivity je dosaˇzeno propojen´ım v´ ystup˚ u simul´ atoru na jeho vstup (viz obr. 4.4). Vzhledem k tomu, ˇze na v´ ystupu simul´ atoru je k dispozici stav modelu, model m˚ uˇze takto komunikovat s vlastn´ım simul´ atorem a doc´ılit tak vykon´ an´ı poˇzadovan´ ych instrospekˇcn´ıch i reflektivn´ıch operac´ı. Simulator Command
X
Model
Y
Output
S
model struct./state operation req.
Obr´azek 4.4: Simulace reflektivn´ıho syst´emu
4.5
Syst´ emy simulac´ı (multisimulace)
Pozvednˇeme se nyn´ı mimo ˇcas a prostor jedn´e simulace. Na t´eto u ´rovni pracujeme s mnoha nez´ avisl´ ymi simulacemi a jejich ˇcasoprostory a zab´ yv´ ame se dynamick´ ym vytv´aˇren´ım, ruˇsen´ım a propojov´an´ım simulac´ı. Toto d´av´a smysl pro optimalizaci, vnoˇrenou a reflektivn´ı simulaci a pro multiparadigmatickou simulaci. Optimalizace zaloˇzen´ a na simulaci spoˇc´ıv´ a v prohled´ av´an´ı prostoru vˇsech simulac´ı (a vˇsech model˚ u) s c´ılem naj´ıt nejlepˇs´ı model podle dan´ ych kriteri´ı, pˇriˇcemˇz m´ıra, do jak´e jsou krit´eria splnˇena, je odvozena od v´ ysledk˚ u simulaˇcn´ıch experiment˚ u. Vnoˇ ren´ a a reflektivn´ı simulace je v podstatˇe simulace simuluj´ıc´ıch syst´em˚ u – souˇc´ast´ı modelu M je simul´ ator jin´eho modelu M ′ . Pokud M ′ je modelem M , jde o reflektivn´ı simulaci – simulujeme syst´em, kter´ y obsahuje model sebe sama a prov´ad´ı s n´ım simulaˇcn´ı experimenty. Multiparadigmatick´ a simulace je realizov´ana r˚ uzn´ ymi simul´ atory pro r˚ uzn´ a modelovac´ı paradigmata. Pˇritom simul´ atory d´ılˇc´ıch model˚ u (specifikovan´ ych r˚ uzn´ ymi formalismy spjat´ ymi s pouˇzit´ ymi paradigmaty) jsou synchronizov´any a propojeny v r´amci jedn´e multisimulace. Kompozice simul´ ator˚ u Uveden´e pˇr´ıpady se liˇs´ı pˇredevˇs´ım t´ım, zda simulace bˇeˇz´ı z konceptu´aln´ıho pohledu paralelnˇe (na stejn´e u ´rovni), nebo zda jsou simulace vnoˇreny. V prvn´ım pˇr´ıpadˇe (paraleln´ı simulace) je simul´ ator zapouzdˇren tak, ˇze bˇeˇz´ı se synchronizovan´ ym ˇcasem a zpˇr´ıstupˇ nuje rozhran´ı vnoˇren´eho modelu. V druh´em pˇr´ıpadˇe (vnoˇren´ a simulace) se simul´ ator jev´ı jako komponenta, jej´ıˇz rozhran´ı (vstupy a v´ ystupy) zpˇr´ıstupn ˇuje operace vnoˇren´eho simul´ atoru, coˇz jsou z pohledu vnoˇren´eho modelu metaoperace a metainformace (na t´eto u ´rovni m˚ uˇzeme s modelem a jeho simulac´ı zach´azet zcela libovolnˇe bez jeho ”vˇedom´ı”). Vnoˇren´ y model pak bˇeˇz´ı ve vlastn´ım, na vnˇejˇs´ım modelu nez´avisl´em, 19 Z hlediska praktick´e implementace lze frontu v nˇekter´ ych pˇr´ıpadech vynechat a editaˇcn´ı operace prov´ adˇet pˇr´ımo. Pro jednoduch´e z´ asahy to nevad´ı, obecnˇe je to ale nutn´e, kv˚ uli serializaci poˇzadavk˚ u pˇri n´ asobn´emu pˇr´ıstupu k refl. rozhran´ı simul´ atoru z mnoha submodel˚ u souˇcasnˇe.
´ 4.5. SYSTEMY SIMULAC´I (MULTISIMULACE)
39
ˇcase. Je samozˇrejmˇe moˇzn´e paraleln´ı simulaci vnoˇrit a vnoˇren´e simulace nechat bˇeˇzet paralelnˇe. Vzhledem k tomu, ˇze simul´ ator se jev´ı jako komponenta DEVS, je moˇzn´e ho pˇrirozenˇe pouˇz´ıt jako submodel sloˇzen´eho modelu a pracovat s n´ım stejnˇe jako s ostatn´ımi komponentami. Simulator Command
Simulator Model Command Simulator Model Command Simulator Model Command Simulator Model Command Simulator Model Command Model
Output Output Output Output Output Output
Obr´azek 4.5: Paraleln´ı simulace Simulator Model Command
Output Simulator Command
Output Model
Obr´azek 4.6: Vnoˇren´ a simulace Multisimulaˇ cn´ı syst´ em Multisimulaˇcn´ı syst´em je syst´em, jehoˇz subsyst´emy jsou simu20 lace, resp. simul´ atory. Simul´ ator m˚ uˇzeme jednak modelovat (implementovat) pˇr´ımo jako DEVS (viz kap. 7), jednak ho m˚ uˇzeme (bez ohledu na realizaci) zapouzdˇrit do komponenty DEVS (tj. d´at mu kompatibiln´ı rozhran´ı) a pouˇz´ıt ho jako subsyst´em multisimulaˇcn´ıho syst´emu, kter´ y specifikujeme jako DEVS a simulujeme simul´ atorem DEVS (pˇr´ıkladem m˚ uˇze b´ yt simul´ ator pro jin´e paradigma, uveden´ y v kapitole 6). Takto zapouzdˇren´ y simul´ ator m˚ uˇze pracovat bud’ s nez´ avisl´ ym ˇcasem, nebo se ˇcasem synchronizovan´ ym s nadˇrazen´ ym syst´emem, podle toho, o jak´ y typ aplikace jde (pˇr´ıklad vnoˇren´e simulace s nez´avisl´ ym ˇcasem je uveden v kapitole 8). Pl´ anov´ an´ı simulac´ı V multisimulaˇcn´ım prostˇred´ı je tˇreba ˇreˇsit ot´ azku pˇridˇelov´an´ı procesoru jednotliv´ ym simulac´ım. Procesy jednotliv´ ych simulac´ı jsou obvykle implementov´any jako procesy hostitelsk´eho operaˇcn´ıho syst´emu. Pak se o pˇridˇelov´an´ı procesoru star´ a pl´ anovaˇc operaˇcn´ıho syst´emu. V pˇr´ıpadˇe multisimulaˇcn´ıho prostˇred´ı SmallDEVS, kter´e bude 20
Pojem simulace, resp. simul´ ator, pouˇz´ıv´ ame analogicky k pojmu proces, resp. procesor v operaˇcn´ıch syst´emech. Proces (v terminologii operaˇcn´ıch syst´em˚ u) je objekt, obsahuj´ıc´ı program a aktu´ aln´ı stav jeho prov´ adˇen´ı. Tot´eˇz plat´ı obecnˇe pro procesor. Stejnˇe ch´ apeme i simulaci, resp. simul´ ator - zahrnuje model a jeho aktu´ aln´ı stav. Z jin´eho (nadˇcasov´eho) u ´hlu pohledu jsou jak procesy, tak simulace sekvence ud´ alost´ı mˇen´ıc´ı stav. V naˇsem pojet´ı jak proces, tak simulace reprezentuj´ı syst´emy, schopn´e generovat budouc´ı ud´ alosti.
ˇ ´ ABSTRAKTN´I ARCHITEKTURA KAPITOLA 4. OTEVREN A
40
pops´ ano v kapitole 5, se o pˇridˇelov´an´ı procesoru star´ a standardn´ı pl´ anovaˇc Smalltalku. Obdobnˇe by se situace ˇreˇsila i v jin´ ych podobn´ ych prostˇred´ıch, jako je napˇr. Java.
4.6
Shrnut´ı
V n´avaznosti na existuj´ıc´ı pˇr´ıstupy, zab´ yvaj´ıc´ımi se modely s vyv´ıjej´ıc´ı se strukturou (zm´ınˇen´ ymi v kapitole 3) byla definov´ana abstraktn´ı architektura univerz´ aln´ıho simulaˇcn´ıho syst´emu s dynamick´ ym aplikaˇcn´ım rozhran´ım, umoˇzn ˇuj´ıc´ı jak interaktivn´ı v´ yvoj modelu, tak reflektivitu. Ke kl´ıˇcov´ ym atribut˚ um t´eto architektury patˇr´ı simulace v re´aln´em ˇcase, propojen´ı simulace s okoln´ı realitou, klonov´an´ı, migrace a editace submodel˚ u za bˇehu, meta´ urovˇ nov´a multisimulaˇcn´ı architektura (simul´ atory jsou syst´emy, s kter´ ymi se zach´az´ı stejnˇe jako s modely). Konkr´etn´ı implementac´ı t´eto abstraktn´ı architektury je syst´em SmallDEVS, kter´emu se vˇenuje kapitola 5.
Kapitola 5
V´ yvoj syst´ em˚ u v simulaci, n´ astroj SmallDEVS V t´eto kapitole bude pˇredstaven konkr´etn´ı n´astroj (SmallDEVS [Jan06]), implementuj´ıc´ı reflektivitu a podporuj´ıc´ı interaktivn´ı inkrement´aln´ı v´ yvoj syst´emu za bˇehu. Implementaˇcn´ım prostˇred´ım je Smalltalk. Popsan´e principy lze uplatnit i v jin´ ych prostˇred´ıch. Existuj´ıc´ı implementace ovˇsem vyuˇz´ıv´ a toho, ˇze Smalltalk s´ am o sobˇe je vysoce portabiln´ım a do jin´ ych syst´em˚ u vnoˇriteln´ ym operaˇcn´ım syst´emem, podporuj´ıc´ım perzistenci, multitasking, interaktivitu a experiment´aln´ı programovn´ı (exploratory programming). Smalltalk a jeho principy jsou tak´e jedn´ım z hlavn´ıch zdroj˚ u inspirace pro vybudov´an´ı syst´emu SmallDEVS.
5.1
Motivace a zvolen´ y pˇ r´ıstup
Jako motivaˇcn´ı pˇr´ıklad lze uv´est inkrement´aln´ı v´ yvoj ˇr´ıdic´ıho syst´emu autonom´ıho mobiln´ıho robota v simulovan´em prostˇred´ı. Jde o v´ yvoj syst´emu, jehoˇz specifikace nen´ı na poˇc´atku v´ yvoje zcela jasn´ a a je ji tˇreba dodateˇcnˇe upˇresˇ novat na z´akladˇe v´ ysledk˚ u test˚ u, prov´adˇen´ ych na pokusn´ ych realizac´ıch v r˚ uzn´ ych prostˇred´ıch, a to jak simulovan´ ych, tak re´aln´ ych. Vzhledem k tomu, ˇze je mnohdy nutn´e dovyv´ıjet realizovan´ y syst´em pˇri bˇeˇzn´em provozu v c´ılov´em prostˇred´ı, je nezbytn´e zachovat model ˇr´ızen´ı v pr˚ ubˇehu cel´eho v´ yvoje, vˇcetnˇe c´ılov´eho nasazen´ı, s moˇznost´ı vr´atit se kdykoli zpˇet do prostˇred´ı simulovan´eho. C´ılov´a realizace ˇr´ıdic´ıho syst´emu pak mus´ı obsahovat simul´ ator modelu ˇr´ızen´ı, bˇeˇz´ıc´ı v re´aln´em ˇcase a propojen´ y s re´aln´ ym okol´ım. Pˇritom je vhodn´e zajistit vzd´ alen´e monitorov´an´ı stavu a inkrement´aln´ı z´asahy v´ yvoj´aˇre do modelu ˇr´ızen´ı za bˇeˇzn´eho provozu. Uveden´ y styl v´ yvoje syst´em˚ u klade specifick´e n´aroky na podp˚ urn´e prostˇredky. Zvolen´ y pˇr´ıstup je zaloˇzen na kombinaci ˇctyˇr paradigmat: Experiment´ aln´ı modelov´ an´ı (exploratory modeling) Jednoduˇse ˇreˇceno, netvoˇr´ıme model, abychom s n´ım experimentovali, ale experimentujeme, abychom naˇsli (vytvoˇrili) spr´ avn´ y model. Jde v podstatˇe o formu evoluˇcn´ıho programov´an´ı s interaktivn´ı fitness funkc´ı a s interaktivn´ım generov´an´ım r˚ uzn´ ych mutac´ı modelu. Otevˇ ren´ e a flexibiln´ı podp˚ urn´ e prostˇ redky Experiment´aln´ı modelov´an´ı je tˇreba podpoˇrit odpov´ıdaj´ıc´ım n´astrojem. K jeho hlavn´ım rys˚ um mus´ı patˇrit reflektivn´ı aplikaˇcn´ı rozhran´ı a interaktivn´ı vizu´aln´ı n´astroje pro inspekci a editaci model˚ u a manipulaci se simulacemi. Otevˇrenost a flexibilitu potˇrebnou pro inkrement´aln´ı z´asahy
42
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS (programov´e i interaktivn´ı) v dobˇe bˇehu m˚ uˇze zajisit objektovˇe orientovan´ y pˇr´ıstup smalltalkovsk´eho typu, ale vyˇsˇs´ı m´ıru flexibility a bezpeˇcnosti (d´ıky jednoduˇsˇs´ı realizaci) m˚ uˇze zajistit pˇr´ıstup zaloˇzen´ y na prototypov´ ych objektech.
Propojen´ı reality se simulac´ı (reality-in-the-loop simulation) V pr˚ ubˇehu v´ yvoje a hlavnˇe v c´ılov´e realizaci se pˇredpokl´ ad´ a propojen´ı modelu (kter´ y ve vhodn´em okamˇziku form´ alnˇe prohl´as´ıme za c´ılovou realizaci) s re´aln´ ym okol´ım. K tomu je nutn´e okoln´ı realitu zpˇr´ıstupnit se stejn´ ym rozhran´ım, jak´e maj´ı komponenty modelu. Prakticky to znamen´a prvky re´aln´eho okol´ı zpˇr´ıstupnit formou speci´aln´ıch atomick´ ych komponent. V´ yvoj v simulaci a zachov´ an´ı modelu (model continuity) V´ yvoj zaloˇzen´ y na simulaci je vhodn´e kromˇe postupu od simulace k realitˇe umoˇznit i reverznˇe, tj. umoˇznit n´avraty z re´aln´eho nasazen´ı zpˇet do simulace. V´ yhodou je pak moˇznost pracovat i v simulaci s daty z´ıskan´ ymi z bˇehu v re´aln´em prostˇred´ı. Prakticky to znamen´a umoˇznit dynamick´e klonov´an´ı komponent modelu (resp. c´ılov´eho programu) a pˇrenos tˇechto klon˚ u do simulovan´eho prostˇred´ı.
5.2
Experiment´ aln´ı programov´ an´ı (exploratory programming) a Smalltalk
Smalltalk je vˇseobecnˇe ch´ap´ an jako vzorov´ y jazyk pro experiment´aln´ı programov´an´ı (exploratory programming), nebot’ poskytuje u ´ˇcinn´e prostˇredky pro interaktivn´ı z´asahy do bˇeˇz´ıc´ıho syst´emu. V t´eto ˇc´asti pop´ıˇseme podrobnˇeji nˇekter´e souvisej´ıc´ı skuteˇcnosti. Experiment´ aln´ı programov´ an´ı (exploratory programming) Pojem Exploratory programming je tˇeˇzko pˇreloˇziteln´ y. Pouˇziteln´ y je term´ın zkoumav´e, zkoumaj´ıc´ı, pokusn´e, ˇci experiment´ aln´ı programov´ an´ı (EP). Posledn´ı z uveden´ ych term´ın˚ u budeme preferovat. Tento styl programov´an´ı umoˇzn ˇuje rychlou tvorbu prototyp˚ u, tedy program˚ u, o kter´ ych pˇredpoklad´ ame, ˇze moˇzn´ a ˇreˇs´ı zadan´ y probl´em. Je vhodn´ y v situac´ıch, kdy nen´ı k dispozici dostateˇcn´ a specifikace budouc´ıho d´ıla a vhodn´ y zp˚ usob realizace je tˇreba teprve objevit na z´akladˇe experiment˚ u s pokusn´ ymi realizacemi. Jde o interaktivn´ı prohledn´av´an´ı (exploration) prostoru vˇsech moˇzn´ ych program˚ u s c´ılem naj´ıt ten, kter´ y nejl´epe vyhovuje obvykle velmi nejasnˇe zadan´ ym poˇzadavk˚ um. Takov´a situace je typick´a v oblasti umˇel´e inteligence, ale i v ˇradˇe jin´ ych pˇr´ıpad˚ u. LISP, Smalltalk, Prolog a Self jsou typick´e jazyky umoˇzn ˇuj´ıc´ı pr´avˇe tento styl programov´an´ı. Smalltalk (spolu s j´ım pˇr´ımo inspirovan´ ymi jazyky, jako je Self) je nav´ıc zaj´ımav´ y t´ım, ˇze tento zp˚ usob programov´an´ı podporuje i vizu´aln´ımi n´astroji. Inkrement´ aln´ı kompilace Technicky je pro podporu experiment´aln´ıho programov´an´ı nezbytn´ a moˇznost okamˇzit´eho pˇrechodu od vytvoˇren´ı programu k jeho bezprostˇredn´ımu interaktivn´ımu (ale i automatick´emu) otestov´an´ı. Kompilace tedy mus´ı trvat zlomky, maximalnˇe jednotky vteˇrin, nikoliv minuty, jak je tomu u staticky typovan´ ych mainstreamov´ ych jazyk˚ u. Tak´e mus´ı prob´ıhat z pohledu uˇzivatele skrytˇe, bez nutnosti explicitnˇe spouˇstˇet kompil´ator. Toho lze prakticky doc´ılit inkrement´aln´ım kompil´atorem, kter´ y zpracov´av´a jen d´ılˇc´ı ˇc´asti vytv´aˇren´eho programov´eho d´ıla pr´avˇe v okamˇziku jejich modifikace a pˇreloˇzen´ y k´od inkrement´alnˇe zakomponov´av´a do v´ ysledn´eho celku. V pˇr´ıpadˇe Smalltalku je nejvˇetˇs´ı
´ ´I PROGRAMOVAN ´ ´I A SMALLTALK 5.2. EXPERIMENTALN
43
a jedinou jednotkou pˇrekladu jedna metoda. V´ ysledkem je objekt (konkr´etnˇe zkompilovan´ a metoda), kter´ y je zaregistrov´an ve struktuˇre pˇr´ısluˇsn´e tˇr´ıdy, coˇz je tak´e objekt, kter´ y je souˇc´ast´ı objektov´e pamˇeti (object memory) Smalltalku. Programov´ an´ı za bˇ ehu Podstatou EP je t´emˇeˇr nepˇretrˇzitˇe vyuˇz´ıvan´ a moˇznost zkoumat stav a pr˚ ubˇeh v´ ypoˇctu, pˇriˇcemˇz program, kter´ y ˇr´ıd´ı v´ ypoˇcet, je okamˇzitˇe modifikovateln´ y inkrement´aln´ımi z´asahy. Stav v´ ypoˇctu je tak´e v libovoln´em okamˇziku v ˇsirok´e m´ıˇre editovateln´ y. Smalltalk poskytuje vizu´aln´ı n´astroje pro zkoum´an´ı a editaci programu (t.j. syst´emu tˇr´ıd a jejich metod) i stavu v´ ypoˇctu (t.j. obsahu instanˇcn´ıch promˇenn´ ych jednotliv´ ych objekt˚ u). Jak obsah instanˇcn´ıch promˇenn´ ych ˇziv´ ych objekt˚ u, tak i jejich tˇr´ıdy a metody lze v libovoln´em okamˇziku modifikovat a bezprostˇrednˇe zkoumat d˚ usledky takov´ ych z´asah˚ u. Takˇze jak zkoum´an´ı bˇehu programu, tak samotn´e programov´an´ı prob´ıh´ a souˇcasnˇe. Takov´ ymto spojen´ım programov´an´ı s okamˇzit´ ym ovˇeˇrov´an´ım chov´an´ı lze obecnˇe dos´ ahnout mnohem vyˇsˇs´ı produktivity program´ atorsk´e pr´ace i vyˇsˇs´ı kvality k´odu neˇz zdlouhav´ ym opakovan´ ym programov´an´ım, n´aslednou explicitn´ı kompilac´ı a spouˇstˇen´ım v´ ysledn´e aplikace s omezen´ ymi moˇznostmi sledovat chov´an´ı programu, jak je tomu v pˇr´ıpadˇe bˇeˇzn´ ych programovac´ıch jazyk˚ u, pouˇzit´ ych pro prototypov´an´ı a evoluˇcn´ı v´ yvoj. Bˇeˇzn´e programovac´ı jazyky totiˇz podporuj´ı klasick´ y pˇr´ıstup softwarov´eho inˇzen´ yrstv´ı, zaloˇzen´ y na d˚ ukladn´e anal´ yze poˇzadavk˚ u a z n´ı odvozen´e pˇresn´e specifikace programov´eho d´ıla. To ovˇsem v pˇr´ıpadˇe nejasn´ ych poˇzadavk˚ u nelze aplikovat. Objektov´ a pamˇ et’ Zaj´ımav´ ym d˚ usledkem pˇr´ıstupu EP je fakt, ˇze tak zvan´ y zdrojov´ y k´od ztr´ ac´ı p˚ uvodn´ı v´ yznam, protoˇze to, ˇceho se program´ ator snaˇz´ı inkrement´aln´ımi z´asahy doc´ılit, nen´ı prim´arnˇe zdrojov´ y text, ale uspokojivˇe bˇeˇz´ıc´ı programov´e d´ılo. To se totiˇz v´ yvoj´aˇr snaˇz´ı neust´ ale testovat, analyzovat a upravovat. V pˇr´ıpadˇe Smalltalku tedy jde program´ atorovi prim´arnˇe o vytvoˇren´ı funguj´ıc´ıcho syst´emu ˇziv´ ych objekt˚ u v perzistentn´ı objektov´e pamˇeti, nikoliv o vytvoˇren´ı soubor˚ u se zdrojov´ ymi texty, kter´e po zkompilov´an´ı a spuˇstˇen´ı takov´ y syst´em objekt˚ u pˇri odstartov´an´ı vytvoˇr´ı. Program´ ator ve Smalltalku needituje ˇz´adn´e textov´e soubory, ale inkrement´alnˇe modifikuje objekty pˇr´ımo v objektov´e pamˇeti za pomoci inkrement´aln´ıho kompil´atoru spojen´eho s n´astroji pro navigaci v syst´emu objekt˚ u. Kompil´ ator je automaticky aktivov´an jako reakce na z´asahy program´atora, kter´ y edituje jen jednotliv´e textov´e reprezentace metod, kter´e jsou mu zpˇr´ıstupˇ neny v n´astroji na prohl´ıˇzen´ı tˇr´ıd. Textovou podobu metod Smalltalk spravuje ve vlastn´ı reˇzii a umoˇzn ˇuje pˇr´ıstup i k historick´ ym verz´ım metod. Tyto informace Smalltalk ukl´ad´ a do logu mimo objektovou pamˇet’. V pˇr´ıpadˇe, ˇze by tento log z jak´ehokoliv d˚ uvodu nebyl k dispozici, nab´ız´ı k prohl´ıˇzen´ı a editaci dekompilovanou podobu metod. Tento pˇr´ıstup jenom podtrhuje nez´ avislost Smalltalku na extern´ıch souborech a textech. Pˇredmˇetem zkoum´an´ı a modifikace jsou v´ yluˇcnˇe jen ˇziv´e objekty v objektov´e pamˇeti Smalltalku. Export a import objekt˚ u Soubory s textovou podobou tˇr´ıd a jejich metod lze v pˇr´ıpadˇe potˇreby kdykoliv ze Smalltalku vygenerovat, ale rozhodnˇe je nelze povaˇzovat za prim´arn´ı. Pˇrestoˇze tak mohou b´ yt vidˇeny, nejsou to zdrojov´e texty v prav´em smyslu slova. Needituj´ı se, slouˇz´ı typicky jen pro pˇr´ıpadn´ y pˇrenos vytvoˇren´eho d´ıla do objektov´e pamˇeti jin´eho Smalltalku. Takto vygenerovan´e texty nejsou urˇceny k tomu, aby je ˇcetl, analyzoval a editoval ˇclovˇek. Jak prohl´ıˇzen´ı, tak i anal´ yza a editace syst´emu tˇr´ıd se pˇrirozenˇe realizuje v jejich prim´arn´ı, ˇziv´e podobˇe, t.j. v podobˇe objekt˚ u v objektov´e pamˇeti. Proto tak´e mnoh´e Smalltalky preferuj´ı export nikoliv v podobˇe, kter´a by zdrojov´ y text pˇripom´ınala,
44
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
ale adˇeji v XML, coˇz je dnes povaˇzov´ano za standard pro textovou reprezentaci tˇr´ıd a objekt˚ u, urˇcenou ke strojov´emu zpracov´an´ı. Perzistence, obraz pamˇ eti Jelikoˇz nepracujeme se zdrojov´ ymi texty v souborech, ale s objektovou pamˇet´ı, mus´ı syst´em pro EP podporovat moˇznost jej´ıho kompletn´ıho uloˇzen´ı na extern´ı m´edium (obvykle do souboru) v podobˇe tzv. obrazu (image). Tento obraz objektov´e pamˇeti je pˇri startu syst´emu (Smalltalku) naˇcten a objektov´a pamˇet’ je rekonstruov´ana pˇresnˇe v t´e podobˇe, v jak´e byla pˇredt´ım uloˇzena. Nˇekter´e Smalltalky jsou schopny nepˇretrˇzitˇe obraz objektov´e pamˇeti udrˇzovat na disku a tak´e ˇreˇsit odkl´ad´ an´ı nepouˇz´ıvan´ ych ˇc´ast´ı na disk v pˇr´ıpadˇe nedostatku voln´e operaˇcn´ı pamˇeti. Takov´ ym Smalltalkem je napˇr. syst´em GemStone [?], deklarovan´ y jako objektovˇe orientovan´ y datab´ azov´ y syst´em pro klient-server aplikace. Reflektivita a dynamiˇ cnost Smalltalk je pomˇernˇe rozs´ahl´ y programov´ y syst´em vytvoˇren´ y ve Smalltalku samotn´em. Jde o typickou uk´azku syst´emu, kter´ y je s´ am sebe schopen za bˇehu vyv´ıjet. K tomu je tˇreba, aby objekty mohly zkoumat a modifikovat objekty (vˇcetnˇe sebe). Objekt m˚ uˇze zkoumat i modifikovat jak tˇr´ıdy (tj. mnoˇzinu metod a specifikaci reprezentace stavu), tak jejich instance (tj. obsah instanˇcn´ıch promˇenn´ ych). Modifikace tˇr´ıdy ve Smalltalku okamˇzitˇe ovlivn´ı strukturu a chov´an´ı vˇsech jej´ıch instac´ı. Smalltalk je dynamick´ y jazyk. To znamen´a, ˇze programov´e struktury mohou vznikat a zanikat za bˇehu. Smalltalk je syst´em, vytvoˇren´ y a bˇeˇz´ıc´ı ve Smalltalku. Programov´an´ı ve Smalltalku znamen´a postupnou modifikaci Smalltalku smˇerem ke k´ yˇzen´e aplikaci. Smalltalk, resp. aplikace ve Smalltalku vytv´aˇren´ a, tedy ve skuteˇcnosti prov´ad´ı sebemodifikaci a t´ım se toto programov´e d´ılo vyv´ıj´ı. Pouˇ zitelnost EP EP je obecnˇe vhodn´e v tˇechto situac´ıch: • mal´e projekty, • mal´e t´ ymy (v ide´aln´ım pˇr´ıpadˇe aplikuj´ıc´ı z´asady extremn´ıho programov´an´ı), • nejasn´e zad´an´ı, • omezen´e prostˇredky (ˇcas, prostor, pen´ıze). EP je naopak nevhodn´e pro velk´e projekty a velk´e t´ ymy. Tam se poˇc´ıt´ a pr´avˇe se zaveden´ ymi bˇeˇzn´ ymi technikami softwarov´eho inˇzen´ yrstv´ı s d˚ ukladnou pˇredbˇeˇznou anal´ yzou a s existuj´ıc´ımi rozs´ahl´ ymi a otestovan´ ymi knihovnami pro bˇeˇzn´e, obvyle staticky typovan´e jazyky. Tak´e veˇsker´e podp˚ urn´e n´astroje, umoˇzn ˇuj´ıc´ı t´ ymov´ y v´ yvoj, jsou zaloˇzeny na spr´avˇe soubor˚ u se zdrojov´ ymi texty, kter´e se povaˇzuj´ı za prim´arn´ı a jedinou udrˇzovanou podobu programov´eho d´ıla. Bezpeˇ cnost Jazyky pro EP jsou vesmˇes jazyky s dynamickou typovou kontrolou. Jazyky s dynamickou typovou kontrolou nevyˇzaduj´ı deklarace typ˚ u promenn´ ych, protoˇze nejsou k pˇrekladu zapotˇreb´ı. Nˇekter´e jazyky (napˇr. Strongtalk [?]) umoˇzn ˇuj´ı nepovinnˇe deklarovat typy promˇenn´ ych tam, kde to m´ a vysvˇetluj´ıc´ı, dokumentaˇcn´ı v´ yznam. Smalltalk, LISP, Self, Prolog ani Python s deklaracemi typ˚ u nepoˇc´ıtaj´ı. Je vˇsak tˇreba zd˚ uraznit, ˇze ve vˇsech tˇechto pˇr´ıpadech jde o jazyky typovˇe bezpeˇcn´e, tj. nem˚ uˇze za ˇz´adn´ ych okolnost´ı doj´ıt k chybˇe, zp˚ usoben´e aplikac´ı operace nad nespr´avn´ ym typem dat.
´ ORIENTACE ZALOZEN ˇ A ´ NA PROTOTYPECH 5.3. OBJEKTOVA
45
Potenci´aln´ı probl´em dynamicky typovan´ ych jazyk˚ u ale tkv´ı v tom, ˇze na pˇr´ıpadn´e typov´e nekompatibility se pˇrijde aˇz za bˇehu. Ale vzhledem k tomu, ˇze EP je zaloˇzeno na velmi d˚ ukladn´em testov´an´ı, pravdˇepodobnost neodhalen´ı takov´e chyby je obvykle mnohem pˇrijatelnˇejˇs´ı neˇz cena v´ yvoje s pouˇzit´ım klasick´eho staticky typovan´eho jazyka (nehledˇe na fakt, ˇze statick´a typov´a kontrola neodhal´ı jin´e v´aˇzn´e chyby, kter´e nejsou zp˚ usobeny typovou nekompatibilitu).
5.3
Objektov´ a orientace zaloˇ zen´ a na prototypov´ ych objektech
Dalˇs´ım zdrojem inspirace pro SmallDEVS je objektov´a orientace zaloˇzen´a na prototypov´ ych objektech [Lie86]. Vzorov´ ym jazykem, zaloˇzen´ ym na prototypov´ ych objektech je Self [US87]. Pˇr´ım´e pouˇzit´ı tohoto jazyka by pro naˇse u ´ˇcely bylo problematick´e z hlediska interoperability a portability, proto v´ yhodnˇe vyuˇzujeme toho, ˇze tento styl programov´an´ı je k dispozici pˇr´ımo ve Smalltalku d´ıky rozˇs´ıˇren´ı, kter´e je implementov´ano v bal´ıku Prototypes [MA04]. Jde o jednoduch´ y framework pro Smalltalk, nikoliv o vnoˇren´ y jazyk. Jazykem pro specifikaci metod z˚ ust´av´a Smalltalk. Na rozd´ıl od klasick´eho beztˇr´ıdn´ıho OO jazyka Selfu [US87] jsou zde proto nˇekter´e m´ırn´e odliˇsnosti: • Reprezentace objekt˚ u z˚ ust´av´a zachov´ana, takˇze se rozliˇsuj´ı datov´e sloty a metody. • Jazyk pro specifikaci metod je Smalltalk, takˇze pro pˇr´ıstup ke slot˚ um je tˇreba zas´ılat zpr´ avy explicitnˇe (pˇres self). • Lze libovolnˇe vyuˇz´ıvat existuj´ıc´ıch objekt˚ u Smalltalku a kombinovat prototypov´e objekty s objekty definovan´ ymi tˇr´ıdami. • Vˇsechny prototypov´e objekty jsou instancemi tˇr´ıdy PrototypeObject, kter´a je podtˇr´ıdou Behavior, stejnˇe jako metatˇr´ıdy. Z´akladn´ı princip prototypov´ ych objekt˚ u lze charakterizovat takto: • Prototypov´ y objekt m´ a sloty, metody a deleg´aty (viz d´ale), um´ı reagovat na zpr´ avy. Reakce na zpr´ avu spoˇc´ıv´ a v proveden´ı odpov´ıdaj´ıc´ı metody nebo vr´acen´ı obsahu odpov´ıdaj´ıc´ıcho slotu. • Dˇediˇcnost je realizov´ana delegac´ı. Nerozum´ı-li objekt zpr´ avˇe, hled´a se odpov´ıdaj´ıc´ı metoda (nebo slot) v deleg´atech, po nalezen´ı se metoda provede v kontextu p˚ uvodn´ıho pˇr´ıjemce zpr´ avy. • Prototypov´ y objekt rozum´ı metaoperac´ım pro editaci objektu (manipulaci se sloty, metodami a deleg´aty). • Nad libovoln´ ym prototypov´ ym objektem lze v libovoln´em okamˇziku otevˇr´ıt Inspektor, kter´ y umoˇzn´ı interaktivn´ı zkoum´an´ı a editaci objektu. Typick´e pouˇzit´ı a souˇcasnˇe princip programov´an´ı bez tˇr´ıd si uk´aˇzeme na pˇr´ıkladech. Vytvoˇ ren´ı pr´ azdn´ eho objektu
anObject ← PrototypeObject new.
46
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
Inspektor
anObject inspect .
V´ ysledkem je otevˇren´ı inspektoru (obr. 5.1).
Obr´azek 5.1: Inspektor prototypov´eho objektu Inspektor je kombinac´ı browseru a klasick´eho smalltalkovsk´eho inspektoru, protoˇze prototypov´ y objekt je v podstatˇe kombinac´ı tˇr´ıdy a jej´ı instance. Pomoc´ı tohoto n´astroje je moˇzn´e zkoumat a modifikovat stav objektu, ale tak´e jeho metody a deleg´aty (deleg´ati jsou objekty, na kter´e objekt deleguje zpr´ avy, kter´e nen´ı s´ am schopen obslouˇzit – takto je v beztˇr´ıdn´ıch syst´emech realizov´ano sd´ılen´e chov´ an´ı mnoˇziny objekt˚ u, tj. dˇediˇcnost). Klonov´ an´ı
anotherObject ← anObject clone .
Klon je mˇelkou kopi´ı origin´ alu. Pro jin´e neˇz mˇelk´e kopie je tˇreba vytvoˇrit vlastn´ı metody. Operace nad sloty
anObject addSlot : ’x ’ . anObject addSlot : ’x ’ withValue : 0. anObject removeSlot : ’x ’ .
T´ehoˇz efektu lze doc´ılit pomoc´ı inspektoru. Staˇc´ı vybrat –slots– a sledovat instrukce, pˇr´ıpadnˇe vybrat konkr´etn´ı slot a vyvolat kontextovou nab´ıdku. Operace nad metodami
anObject addMethod: ’printOnTranscript Transcript show: s e l f x printString ’ . anObject methodSourceAt: #printOnTranscript . anObject removeMethod: #printOnTranscript .
T´ehoˇz efektu lze doc´ılit pomoc´ı inspektoru. Staˇc´ı vybrat –methods– a sledovat instrukce, pˇr´ıpadnˇe vybrat konkr´etn´ı metodu a vyvolat kontextovou nab´ıdku.
´ ´I SYSTEM ´ U ˚ PROTOTYPOVYMI ´ 5.4. MODELOVAN OBJEKTY
47
Operace nad deleg´ aty
anObject addDelegate : ’parent ’ withValue : (PrototypeObject new) . anObject removeDelegate : ’parent ’ .
T´ehoˇz efektu lze doc´ılit pomoc´ı inspektoru – staˇc´ı kliknout na –delegates– a sledovat instrukce, pˇr´ıpadnˇe kliknout na konkr´etn´ıho deleg´ata a vyvolat kontextovou nab´ıdku. Zasl´ an´ı zpr´ avy
anObject printOnTranscript
S prototypov´ ymi objekty lze komunikovat stejnˇe jako s ostatn´ımi objekty Smallalku. Prototypov´e objekty a ostatn´ı objekty Smalltalku jsou z vnˇejˇs´ıho pohledu zcela zamˇeniteln´e a lze je libovolnˇe kombinovat.
5.4
Modelov´ an´ı syst´ em˚ u prototypov´ ymi objekty
Vyjasnˇeme nyn´ı d˚ uvody, proˇc je k modelov´an´ı vyv´ıjej´ıc´ıch se syst´em˚ u vhodn´e pouˇz´ıt prototypov´e objekty. Tˇr´ıdn´ı pˇr´ıstup k modelov´an´ı je omezuj´ıc´ı t´ım, ˇze bud’ vyˇzaduje zn´ at vˇsechny tˇr´ıdy pˇredem, v dobˇe kompilace (v pˇr´ıpadˇe staticky kompilovan´ ych jazyk˚ u), nebo vyˇzaduje tvoˇrit (a odstraˇ novat) tˇr´ıdy za bˇehu (v pˇr´ıpadˇe dynamick´ ych jazyk˚ u). Prvn´ı moˇznost skuteˇcnˇe omezuje modelovac´ı s´ılu jazyka – dynamicky lze mˇenit jen strukturu modelu, sloˇzen´eho z pˇredem zn´ am´ ych komponent. Druh´a moˇznost je zbyteˇcnˇe komplikovan´ a, i kdyˇz ji v principu dynamick´e jazyky pˇripouˇstˇej´ı. D˚ uvodem je principi´aln´ı statiˇcnost syst´emu tˇr´ıd. Jak´ekoli dynamick´e modifikace toho v principu statick´eho syst´emu jsou sice moˇzn´e, ale jejich realizace je komplikovan´ a a ne kaˇzd´ y jazyk ji umoˇzn ˇuje. Je totiˇz tˇreba pˇri jak´emkoli dynamick´em z´asahu zachovat konzistenci syst´emu. Napˇr. Smalltalk umoˇzn ˇuje modifikovat definici tˇr´ıdy i v pˇr´ıpadˇe, ˇze existuj´ı jej´ı instance (instance jsou vymˇenˇeny za nov´e se zachov´an´ım p˚ uvodn´ı identity), neb´ yv´ a to vˇsak bˇeˇzn´ ym zvykem ve vˇetˇsinˇe dynamick´ ych jazyk˚ u. Naproti tomu, jak´akoliv dynamick´a manipulace s prototypov´ ymi objekty je trivi´ aln´ı, jak jsme vidˇeli v pˇredchoz´ı podkapitole. Omezuje se na klonov´an´ı a editaci objekt˚ u. Sd´ılen´e chov´an´ı, kv˚ uli kter´emu d´avaj´ı tˇr´ıdy smysl, je jednoduˇse realizovateln´e prostˇrednictv´ım delegace, kterou lze tak´e dynamicky mˇenit trivi´ aln´ım zp˚ usobem. Kromˇe toho, manipulace s prototypov´ ymi objekty pˇripom´ın´ a manipulaci s libovoln´ ymi objekty, bl´ızk´ ymi ˇclovˇeku. Napˇr. interaktivn´ı (ale i skriptovan´ a) pr´ace s jak´ ymikoli dokumenty tak´e spoˇc´ıv´ a v kop´ırov´an´ı a editaci. Chceme-li umoˇznit interaktivn´ı dynamick´e z´asahy do simulace, je tento zp˚ usob manipulace s objekty velmi vhodn´ y d´ıky sv´e jednoduchosti a pˇr´ımoˇcarosti. processor
jobDone
generator jobDone jobOut
jobIn discard discard
Obr´azek 5.2: Gener´ ator a procesor.
48
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
Pˇ r´ıklad Nyn´ı uk´aˇzeme pˇr´ıklad modelu, vytoˇren´eho inkrement´alnˇe z prototypov´ ych objekt˚ u. N´ asleduj´ıc´ı sekvence v´ yraz˚ u je program (skript), kter´ y postupnˇe vytvoˇr´ı model gener´ atrou a procesoru. Tento skript m˚ uˇze b´ yt proveden nar´ az, nebo mohou b´ yt jednotliv´e v´ yrazy vyhodnocov´any postupnˇe, krok za krokem v interaktivn´ım prostˇred´ı Smalltalku (ve workspace). Nejprve vytvoˇr´ıme gener´ ator u ´loh.
| system generator processor jobPrototype | jobPrototype ← PrototypeObject new. jobPrototype addSlots : { ’n ’ −> 0. ’ size ’ −> 0. ’name’ −> ’aJob ’ . }. jobPrototype addMethod: ’setSizeBetween : s l and: sh s e l f size : ( s l to : sh) atRandom’ . generator ← AtomicDEVSPrototype new. generator addSlots : { ’jobPrototype ’ −> jobPrototype . ’ ia ’ −> 2. ”interval min” ’ ib ’ −> 7. ”interval max” ’ sa ’ −> 5. ”job size min” ’sb ’ −> 10. ”job size max” ’ f i r s t ’ −> true . ’n ’ −> 0. ”number of jobs generated”}. generator intTransition : ’ s e l f f i r s t : false ’ . generator outputFnc: ’ s e l f n: s e l f n +1. self poke : (( s e l f jobPrototype setSizeBetween : s e l f sa and: s e l f sb) clone n: s e l f n; yourself ) to : #out ’ . generator timeAdvance: ’ ↑ self first ifTrue : [ 0 ] ifFalse : [ ( s e l f ia to : s e l f ib ) atRandom ] ’ . generator addOutputPorts: {#out}.
N´ asleduj´ıc´ı sekvence v´ yraz˚ u vytvoˇr´ı model procesoru.
processor ← AtomicDEVSPrototype new. processor addSlots : { ’queue ’ −> OrderedCollection new. ’queueSize ’ −> 5. ’ processorStatus ’ −> #idle . ’currentJob ’ −> nil . ’timeSpent ’ −> 0 }. processor addInputPorts : {#in }. processor addOutputPorts: {#out . #discard }. processor intTransition : ’ s e l f processorStatus caseOf : { [ #busy ] −> [ s e l f queue size > 0 ifTrue : [ s e l f currentJob : ( s e l f queue removeFirst) ] ifFalse : [ s e l f processorStatus : #idle . s e l f currentJob : nil ] . s e l f timeSpent : 0 ] .
´ ´I SYSTEM ´ U ˚ PROTOTYPOVYMI ´ 5.4. MODELOVAN OBJEKTY
49
[ #discard ] −> [ s e l f queue removeFirst . s e l f queue size <= s e l f queueSize ifTrue : [ s e l f processorStatus : #busy ] ] . [ #idle ] −> [ ”nothing” ] } ’ . processor extTransition : ’ s e l f queue add: ( s e l f peekFrom: #in ) . s e l f processorStatus caseOf : { [ #idle ] −> [ s e l f processorStatus : #busy . s e l f currentJob : ( s e l f queue removeFirst) ] . [ #busy ] −> [ s e l f timeSpent : s e l f timeSpent + s e l f elapsed . s e l f queue size > s e l f queueSize ifTrue : [ s e l f processorStatus : #discard ] ] . [ #discard ] −> [ ”nothing” ] } ’ . processor outputFnc: ’ s e l f processorStatus caseOf : { [ #busy ] −> [ s e l f poke : s e l f currentJob to : #out ] . [ #discard ] −> [ s e l f poke : ( s e l f queue last ) to : #discard ] . [ #idle ] −> [ ”nothing” ] } ’ . processor timeAdvance: ’ s e l f processorStatus caseOf : { [ #busy ] −> [ ↑ s e l f currentJob size − s e l f timeSpent ] . [ #discard ] −> [ ↑ 0 ] . [ #idle ] −> [ ↑ Float infinity ] } ’ .
Komponenty propoj´ıme do jednohoho celku vyhodnocen´ım n´ asleduj´ıc´ı sekvence v´ yraz˚ u.
system ← CoupledDEVSPrototype new. system addOutputPorts: { #out . #discard }. system addComponents: { #generator −> generator . #processor −> processor }. system addCouplings : { #(generator out) −> #(processor in ) . #(processor out) −> #(s e l f out ) . #(processor discard ) −> #(s e l f discard ) }.
Takto vytvoˇren´ y model m˚ uˇze b´ yt simulov´an vyhodnocen´ım v´ yrazu
system getSimulator simulate : 500.
V´ yˇse uveden´ y k´od je skript, kter´ y zas´ıl´an´ım zpr´ av vhodn´ ym objekt˚ um inkrement´alnˇe vytvoˇr´ı model. K´ody metod jsou pˇred´ any jako parametry odpov´ıdaj´ıc´ıch zpr´ av a odpov´ıdaj´ıc´ı objekty si je v reakci na tyto zpr´ avy automaticky zakompiluj´ı do sv´ ych struktur. Pro jakoukoliv manipulaci s modelem je podstatn´ y model s´ am, nikoliv skript, kter´ y ho vytvoˇril. Jakoukoliv potˇrebnou informaci je moˇzn´e z´ıskat komunikac´ı s objekty modelu. Napˇr. k´od metody, kterou jsme dˇr´ıve zakompilovali do objektu, lze z´ıkat takto:
anObject methodSourceAt: aMethodName.
50
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
Pro takto inkrement´alnˇe vytvoˇren´ y programov´ y syst´em nen´ı zp˚ usob jeho vytvoˇren´ı podstatn´ y, takˇze skript, kter´ y ho vytvoˇril, nech´apeme jako zdrojov´ y k´od v prav´em slova smyslu. Takov´ y skript lze kdykoli pro existuj´ıc´ı syst´em automaticky vygenerovat. Skript, kter´ y zrekonstruuje objekt (vˇcetnˇe vˇcech z nˇeho odkazovan´ ych objekt˚ u) m˚ uˇze b´ yt z´ısk´ an vyhodnocen´ım v´ yrazu
script ← anObject storeString .
Jinou moˇznost´ı je z´ıskat definici objektu v XML s vyuˇzit´ım knihovny SIXX:
sixxString ← anObject sixxString .
Rekonstrukce objektu se pak provede vyhodnocen´ım nˇekter´eho z v´ yraz˚ u:
anObject ← Object readFrom: StoreString . anObject ← Object readSixxFrom: sixxString .
Takto lze manipulovat se vˇsemi objekty, vˇcetnˇe model˚ u a bˇeˇz´ıc´ıch simulac´ı.
5.5
Sd´ılen´ e chov´ an´ı, znovupouˇ zitelnost
Ve v´ yˇse uvedn´em modelu m˚ uˇzeme jednoduˇse pˇridat dalˇs´ı procesory naklonov´an´ım extuj´ıc´ıcho procesoru. Ale pozdˇejˇs´ı modifikace procesoru se pak dotknou jen jednoho exempl´aˇre. Chceme-li zajistit, aby vˇsechny procesory sd´ılely jednu definici, je tˇreba ji pˇresunout z procesoru do separ´atn´ıho objektu, kter´ y se naz´ yv´ a trait. Samotn´ y procesor je pak pops´ an modelem, definuj´ıc´ım jen instanˇcnˇe specifick´e skuteˇcnosti a deleguj´ıc´ım zpracov´an´ı vˇsech ostatn´ıch zpr´ av na pˇr´ısluˇsn´ y trait. Klony takto definovan´eho procesoru pak sd´ıl´ı jednu definici a jej´ı pˇr´ıpadn´ a modifikace pak ovlivn´ı chov´an´ı vˇsech klon˚ u. Trait procesoru m˚ uˇze b´ yt vytvoˇren takto:
processorTrait ← AtomicDEVSTrait new. processorTrait addMethod: ’ intTransition ........ ’. processorTrait addMethod: ’ extTransition . . . . . . . . ’ . processorTrait addMethod: ’outputFnc . . . . . . . . ’ . processorTrait addMethod: ’timeAdvance . . . . . . . . ’ .
Metody intT ransition, extT ransition, outputF nc, timeAdvance traitu jsou definov´any stejnˇe jako u procesor ve v´ yˇse uveden´em modelu. Spoleˇcnˇe s trait objektem je tˇreba specifikovat prototyp procesoru:
processorPrototype ← AtomicDEVSPrototype new. processorPrototype addSlots : { ’queue ’ −> OrderedCollection new. ’queueSize ’ −> 5. ’ processorStatus ’ −> #idle . ’currentJob ’ −> nil . ’timeSpent ’ −> 0 }. processorPrototype addInputPorts : {#in }. processorPrototype addOutputPorts: {#out . #discard }. processorPrototype addDelegate : ’ defaultTrait ’ withValue : processorTrait .
Specifikov´an´ım delegace na trait zajist´ıme sd´ılen´ı definice chov´an´ı vˇsemi klony prototypu procesoru. Nyn´ı m˚ uˇzeme specifikovat syst´em s nˇekolika procesory stejn´eho typu:
5.6. IN(TRO)SPEKCE A REFLEKTIVITA
51
system ← CoupledDEVSPrototype new. system addOutputPorts: { #out . #discard }. system addComponents: { #generator −> generator }. previousPort ← {#generator . #out}. 1 to : 3 do: [ : i | newProcessor ← processorPrototype copy . newProcessorName ← (#processor , i printString ) asSymbol. system addComponents: { newProcessorName −> newProcessor }. system addCouplings : { previousPort −> {newProcessorName. #in }. {newProcessorName. #out} −> {#s e l f . #out} }. previousPort ← {newProcessorName. #discard} ] . system addCouplings : { {newProcessorName. #discard} −> {#s e l f . #discard} }.
Poznamenejme, ˇze trait objekty mohou tak´e delegovat zpracov´an´ı zpr´ av na dalˇs´ı trait objekty. T´ımto zp˚ usobem trait objekty hraj´ı roli tˇr´ıd a delegace modeluje dˇediˇcnost v klasick´em pˇr´ıstupu k objektov´e orientaci. Je moˇzn´ a i n´asobn´ a delegace i dynamic´e zmˇeny t´eto relace.
5.6
In(tro)spekce a reflektivita
V´ yˇse uveden´ y model, obsahuj´ıc´ı gener´ ator a 3 procesory, byl vytvoˇren skriptem, kter´ y komponenty dynamicky propojil. V´ ysledn´e propojen´ı lze zkontrolovat. Propojen´ı z´ısk´ ame vyhodnocen´ım v´ yrazu
system couplings
nebo
system couplingStoreString .
V´ ysledkem je mnoˇzina asociac´ı dvojic , pˇr´ıpadnˇe k´od, jehoˇz vyhodnocen´ım z´ık´ ame pˇr´ısluˇsnou struktutu, kter´a vypad´ a takto:
{ {#generator . #out} −> {#processor1 . #in }. {#processor1 . #out} −> {#s e l f . #out}. {#processor1 . #discard} −> {#processor2 . #in }. {#processor2 . #out} −> {#s e l f . #out}. {#processor2 . #discard} −> {#processor3 . #in }. {#processor3 . #out} −> {#s e l f . #out}. {#processor3 . #discard} −> {#s e l f . #discard }. }
Tato struktura m˚ uˇze b´ yt (po pˇr´ıpadn´ ych modifikac´ıch) pouˇzita pozdˇeji jako argument zpr´ av
system removeCouplings : couplings . system addCouplings : couplings .
Podobnˇe m˚ uˇzeme z´ıskat dalˇs´ı informace o modelu a jeho komponent´ach, jako jsou jm´ena slot˚ u, objekty, kter´e jsou referencov´any ze slot˚ u, metody, deleg´ati, komponenty sloˇzen´eho
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
52
modelu apod. Tak´e m˚ uˇzeme klonovat a editovat cel´ y model nebo libovolnou jeho ˇc´ast, a to i v pr˚ ubˇehu simulace. M˚ uˇzeme pˇrid´ avat a odstraˇ novat komponenty, sloty, deleg´aty, metody apod. Tyto operace jsou pˇr´ıstupn´e uˇzivateli, resp. nadˇrazen´emu syst´emu, ale tak´e (reflektivnˇe) modelu, kter´eho se tyto operace t´ ykaj´ı.
5.7
Operaˇ cn´ı syst´ em
Pod pojmem operaˇcn´ı syst´em rozum´ıme veˇsker´e programov´e prostˇredky pro podporu vytv´ aˇren´ı a bˇehu aplikaˇcnˇe specifick´eho softwaru, vˇcetnˇe moˇznosti libovoln´e manipulace s n´ım. Jde o software, vytv´aˇrej´ıc´ı potˇrebnou abstrakci nad tzv. hol´ ym poˇc´ıtaˇcem a poskutuj´ıc´ı operace pro manipulaci s programy a bˇeˇz´ıc´ımi procesy jak uˇzivateli, tak tˇemto program˚ um a proces˚ um.
5.7.1
Smalltalk a SmallDEVS
Odmysl´ıme-li hostitelsk´ y operaˇcn´ı syst´em, z´akladn´ı vrstvu operaˇcn´ıho syst´emu SmallDEVS tvoˇr´ı Smalltalk. Ten zahrnuje virtu´aln´ı stroj, kompil´ator, v´ıceprocesov´e prostˇred´ı, knihovnu tˇr´ıd, vstupy a v´ ystupy a interaktivn´ı v´ yvojov´e n´astroje, z nichˇz pro SmallDEVS jsou podstatn´e n´astroje Workspace a Inspector.1 Workspace umoˇzn ˇuje editaci text˚ u a interaktivn´ı vyhodnocov´an´ı fragment˚ u k´odu. V´ ysledn´e objekty mohou b´ yt zkoum´any v textov´e podobˇe nebo prostˇrednictv´ım inspektor˚ u. Inspektor umoˇzn ˇuje zkoumat stav objektu, komunikovat s n´ım a editovat jeho aktu´aln´ı stav. Model, kter´ y byl prezentov´an vpˇredchoz´ıch sekc´ıch, m˚ uˇze byt vytvoˇren vyhodnocen´ım pˇr´ısluˇsn´eho k´odu ve Workspace. Stejn´ ym zp˚ usobem lze model zkoumat i editovat, jak jiˇz bylo uk´az´ano. Lze t´eˇz odstartovat simulaci a sledovat jej´ı pr˚ ubˇeh (log). Simulaci lze spustit jako proces na pozad´ı a asynchronnˇe s n´ı komunikovat.
[ s ← system getSimulatorRT . s simulate : 500. ] forkAt : Processor userBackgroudPriority . s s s s
← system getSimulatorRT . stopTime: Float infinity . RTFactor: 1. start .
s stop .
Komunikac´ı se simul´ atorem s m˚ uˇzeme z´ıskat simulovan´ y model a zkoumat stav jeho komponent. N´ asleduj´ıc´ı pˇr´ıklad otevˇre inspektor na obsahem slotu ’queue’ prvn´ıho procesoru:
( s rootDEVS componentNamed: #processor1) model queue inspect
Model m˚ uˇzeme v pr˚ ubˇehu simulace editovat zp˚ usobem, kter´ y byl uveden v pˇredchoz´ıch sekc´ıch. M˚ uˇzeme t´eˇz cel´ y model v libovoln´em okamˇziku klonovat:
savedSystem ← system copy . 1
Ostatn´ı n´ astroje Smalltalku, jako je Browser, Debugger apod., jsou ovˇsem tak´e k dispozici.
ˇ ´I SYSTEM ´ 5.7. OPERACN
5.7.2
53
Perzistence
V pˇredchoz´ıch sekc´ıch byla perzistence modelu jednoduˇse ˇreˇsena pˇriˇrazen´ım do promˇenn´ ych v r´amci Workspace. Systematiˇctˇejˇs´ı pˇr´ıstup je zaloˇzen na vyuˇzit´ı hierarchick´eho uloˇziˇstˇe M yRepository:
MyRepository at : ’/Simulations/GeneratorAnd3Processors ’ put : system . aComponent ← MyRepository at : ’/Simulations/GeneratorAnd3Processors ’ . aComponent ← (MyRepository componentNamed: ’ Simulations ’ ) componentNamed: ’GeneratorAnd3Processors ’ . aComponent addComponents: { name1 −> object1 . name2 −> object2 }.
Toto uloˇziˇstˇe (vˇcetnˇe vˇsech v nˇem aktu´alnˇe bˇeˇz´ıc´ıch simulac´ı) i libovolnou jeho ˇc´ast lze v libovoln´em okamˇziku klonovat, pˇr´ıpadnˇe v textov´e formˇe uloˇzit na extern´ı m´edium nebo pˇren´est do jin´eho Smalltalku.
5.7.3
Vizu´ aln´ı n´ astroje pro manipulaci s modely a simulacemi
Workspace a Inspector, s kter´ ymi jsme vystaˇcili v pˇredchoz´ıch sekc´ıch, jsou standardn´ımi n´astroji, kter´e jsou souˇc´ast´ı operaˇcn´ıho syst´emu Smalltalku. Prostˇred´ı SmallDEVS ale nav´ıc poskytuje specializovan´e vizu´aln´ı n´astroje pro sugestivnˇejˇsi a pˇrehlednˇejˇs´ı manipulaci s modely a simulacemi. Tyto n´astroje byly inspirov´any n´astroji pro manipulaci s prototypov´ ymi objekty v syst´emu Self [US87]. Self je jazyk a syst´em, zaloˇzen´ y na prototypov´ ych objektech. Z´akladn´ım vizu´aln´ım n´astrojem program´ atora je tak zvan´ y Outliner. Jde o n´astroj, umoˇzn ˇuj´ıc´ıc´ı zkoumat a modifikovat strukturu objektu. Srovn´ame-li tento n´astroj se n´astroji Smalltalku, Outliner spojuje funkˇcnost Browseru a Inspectoru, protoˇze v syst´emu Self pojem tˇr´ıda a instance spl´ yvaj´ı v jeden koncept – objekt obsahuje data i metody. V prostˇred´ı syst´emu Self jsou vizualizovateln´e vztahy (reference) mezi objekty a je moˇzn´e s obsahy slot˚ u (referencemi na objekty) manipulovat kop´ırov´an´ım a vkl´ad´ an´ım (copy-paste), resp. pˇresouv´ an´ım (drag-and-drop). Refaktoring objekt˚ u (pˇremist’ov´an´ı slot˚ u mezi r˚ uzn´ ymi objekty) je tak moˇzn´e prov´adˇet intuitivn´ım, konkr´etn´ım a bezprostˇredn´ım zp˚ usobem. Velmi podobnˇe se manipuluje s dokumenty a sloˇzkami pomoc´ı vizu´aln´ıch interaktivn´ıch n´astroj˚ u soudob´ ych operaˇcn´ıch syst´em˚ u – ty umoˇzn ˇuj´ı vytv´aˇret, vyj´ımat, kop´ırovat, vkl´adat, pˇrejmenov´avat a otv´ırat (new, cut, copy, paste, rename, open) dokumenty a sloˇzky. V naˇsem pˇr´ıpadˇe takto pracujeme s objeky, um´ıstˇen´ ymi v hierarchick´e struktuˇre M yRepository. Rozd´ıl oproti manipulaci se soubory je ten, ˇze jde o ˇziv´e objekty, pˇr´ıpadnˇe bˇeˇz´ıc´ı simulace (nikoliv pojmenovan´e ˇretˇezce zvan´e soubory) a vˇse se odehr´ av´a v operaˇcn´ı pamˇeti, nikoliv na extern´ım m´ediu (pˇr´ıpadn´ a externalizace objekt˚ u v textov´e podobˇe je ovˇsem moˇzn´ a, jak bylo uvedeno v´ yˇse). Podstatnou vlastnost´ı vizu´aln´ıch n´astroj˚ u SmallDEVS je jejich transparentnost – umoˇzn ˇuj´ı zkoumat a manipulovat s objekty bez ohledu na to, zda byly interaktivnˇe vytvoˇreny tˇemito n´astroji nebo zda vznikly jako v´ ysledek bˇehu program˚ u. T´eto transparentnosti je dosaˇzeno t´ım, ˇze se nepracuje se zdrojov´ ymi texty objekt˚ u, ale pracuje se s objekty pˇr´ımo (zdrojov´e texty se neuchov´avaj´ı, protoˇze jsou zbyteˇcn´e, jak jiˇz bylo uvedeno).
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
54
Kaˇzd´ y objekt je moˇzn´e zkoumat a editovat. Podle typu objektu se otevˇre odpov´ıdaj´ıc´ı n´astroj. Ke zkoum´an´ı a editaci obecn´ ych objekt˚ u slouˇz´ı PrototypeObjectInspector (obr. 5.1), ke zkoum´an´ı a modifikaci MyRepository slouˇz´ı MyRepositoryBrowser (obr. 5.3 vlevo nahoˇre), ke zkoum´an´ı atomick´ ych model˚ u slouˇz´ı AtomicModelExplorer (obr. 5.3 vlevo dole), ke zkoum´an´ı a editaci sloˇzen´ ych model˚ u slouˇz´ı CoupledModelExplorer (obr. 5.3 vpravo nahoˇre), k ovl´ ad´ an´ı simulac´ı slouˇz´ı SimulationControlPanel (obr. 5.3 vpravo dole). Odpov´ıdaj´ıc´ı n´astroj se otevˇre automaticky v d˚ usledku vyhodnocen´ı v´ yrazu
anObject open.
Obr´azek 5.3: SmallDEVS – vizu´aln´ı n´astroje pro manipulaci s modely a simulacemi
5.8
Aplikaˇ cn´ı rozhran´ı j´ adra SmallDEVS
Obr´azek 5.4 ukazuje kompozici protokol˚ u AtomicDEVSPrototype, CoupledDEVSPrototype, PrototypeObjectForSimulation, AtomicDEVSTrait, MyRepository a DEVSRootSolverRT. Jde o kompletn´ı aplikaˇcn´ı rozhran´ı j´adra SmallDEVS, dostupn´e jak vizu´aln´ım v´ yvojov´ ym n´astroj˚ um, tak program˚ um a skript˚ um pro tvorbu model˚ u a manipulaci s nimi.
´ 5.9. POZNAMKA K IMPLEMENTACI
55
Obr´azek 5.4: Aplikaˇcn´ı rozhran´ı j´adra SmallDEVS.
5.9
Pozn´ amka k implementaci
SmallDEVS je implementov´an ve Smalltalku za pouˇzit´ı rozˇs´ıˇren´ı Prototypes. M˚ uˇze b´ yt ch´ap´ an jako vzor, podle kter´eho lze prezentovan´ y koncept realizovat i v jin´em prostˇred´ı. V pˇr´ıpadˇe, ˇze by ˇslo o statick´ y jazyk, jako je Java, C/C++ apod., nevyhneme se pouˇzit´ı vnoˇren´eho interpretu vhodn´eho dynamick´eho jazyka s inkrement´aln´ım kompil´atorem.
56
´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS
Kapitola 6
Specifikace syst´ em˚ u s diskr´ etn´ımi ud´ alostmi objektovˇ e orientovan´ ymi Petriho s´ıtˇ emi Pˇr´ım´e pouˇzit´ıt´ı formalismu DEVS pro specifikaci syst´emu nemus´ı b´ yt vˇzdy v´ yhodn´e. Problematick´e jsou zejm´ena pˇr´ıpady, kde se struktura syst´em˚ u mˇen´ı pˇr´ıliˇs rychle a komplikovanˇe. Rekonfigurovat strukturu sloˇzen´eho modelu by je pak bylo pˇr´ıliˇs obt´ıˇzn´e. Lepˇs´ı moˇznost´ı je v takov´ ych pˇr´ıpadech pouˇz´ıt objektov´e paradigma s adresovateln´ ymi objekty a zas´ıl´an´ım zpr´ av. Jako optim´aln´ı se jev´ı kombinace, ve kter´e je DEVS pouˇzit pro strukturov´an´ı syst´emu do v´ıcem´enˇe statick´ ych komponent, zat´ımco dynamicky vznikaj´ıc´ı a zanikaj´ıc´ı objekty jsou pouˇzity uvnitˇr atomick´ ych komponent DEVS. V n´asleduj´ıc´ım textu je pops´ ana moˇznost definovat syst´em s diskr´etn´ımi ud´alostni objektovˇe orientova´ ymi Petriho s´ıtˇemi (OOPN). Je struˇcnˇe pˇredstaven formalismus OOPN a jeho simul´ ator, vˇcetnˇe zapouzdˇren´ı do atomick´e komponenty DEVS. Pˇritom je zohlednˇena moˇznost dynamick´ ych z´asah˚ u do bˇeˇz´ıc´ı simulace v souladu s konceptem otevˇren´eho syst´emu, definovan´eho v kapitole 4.
6.1
Petriho s´ıtˇ e a objekty
Z´akladn´ı koncept Petriho s´ıt´ı definoval v ˇsedes´ at´ ych letech C. A. Petri. Jde o matematick´ y stroj se sugestivn´ı vizu´aln´ı reprezentac´ı, kter´ y srozumitelnˇe modeluje synchronizaci a komunkaci proces˚ u v paraleln´ıch a distribuovan´ ych syst´emech. Existuje cel´a ˇrada variant Petriho s´ıt´ı. Na tomto m´ıstˇe se soustˇred´ıme pˇredevˇs´ım na vysoko´ urovˇ nov´e Petriho s´ıtˇe, konkr´etnˇe pak na Objektovˇe orientovan´e Petriho s´ıtˇe (OOPN) [Jan95, Jan98, MVT97, MVT02, JK07]. Ostatn´ı bˇeˇznˇe pouˇz´ıvan´e typy Petriho s´ıt´ı jsou subformalismy objektovˇe orientov´ ych Petriho s´ıt´ı.1 Konkr´etn´ı implementac´ı OOPN je interpret jazyka PNtalk [PNt06, JK03, JK05a, JK05b, MVR+ 06]. 1 Objektovˇe orentovan´e Petriho s´ıtˇe [Jan98] byly navrˇzeny s c´ılem pokr´ yt schopnosti ostatn´ıch typ˚ u Petriho s´ıt´ı a umoˇznit pouˇz´ıt Petriho s´ıtˇe zp˚ usobem, kter´ y je srovnateln´ y s programov´ an´ım v univerz´ aln´ım objektovˇe orientovan´em jazyce.
´ U ˚ FORMALISMEM OOPN KAPITOLA 6. SPECIFIKACE SYSTEM
58
6.1.1
Princip vysoko´ urovˇ nov´ e Petriho s´ıtˇ e
Petriho s´ıt’ je specifikov´ana formou bipartitn´ıho orientovan´eho grafu, obsahuj´ıc´ı dva typy uzl˚ u – m´ısta a pˇrechody – propojen´e hranami. M´ısta, pˇrechody i hrany mohou b´ yt opatˇreny anotacemi, specifikovan´ ymi vhodn´ ym inskripˇcn´ım jazykem. M´ısta mohou obsahovat multimnoˇziny znaˇcek (tokens). Stav syst´emu je modelov´ an rozloˇzen´ım znaˇcek v m´ıstech. Ke zmˇen´ am stavu doch´az´ı v d˚ usledku prov´adˇen´ı pˇrechod˚ u. Pˇrechod m´ a definov´ana vstupn´ı a v´ ystupn´ı m´ısta (ta jsou s pˇrechodem propojena vstupn´ımi a v´ ystupn´ımi hranami). Pˇrechod je provediteln´ y, jsou-li v jeho vstupn´ıch m´ıstech znaˇcky, kter´e jsou specifikov´anu na vstupn´ıch hran´ ach. Proveden´ım pˇrechodu se tyto znaˇcky ze vstupn´ıch m´ıst odstran´ı a do v´ ystup´ıch m´ıst se vygeneruj´ı znaˇcky pecifikovan´e v´ ystupn´ımi hranami. Ve vysoko´ urovˇ nov´e Petriho s´ıt´ı mohou znaˇcky reprezentovat libovoln´a data, kter´a mohou b´ yt prov´adˇen´ım pˇrechod˚ u libovolnˇe zpracov´av´ ana. V´ yrazy na hran´ ach specifikuj´ı multimnoˇziny znaˇcek. Mohou obsahovat promˇenn´e. Ty mus´ı b´ yt v r´amci provedej´ı pˇrechodu nav´az´any na konkr´etn´ı hodnoty. Pˇrechod m˚ uˇze nav´ıc obsahovat str´aˇzn´ı podm´ınku, jej´ıˇz splnˇen´ı je vyˇzadov´ano pro proveden´ı pˇrechodu. Kromˇe toho m˚ uˇze obsahovat akci, kter´a provede libovoln´ y v´ ypoˇcet nad vstupn´ımi daty. V´ ysledky pak mohou b´ yt uloˇzeny do v´ ystupn´ıch m´ıst. Na obr. 6.1 je pˇr´ıklad pˇrechodu ve vysoko´ urovˇ nov´e Petriho s´ıti (bez str´aˇzn´ı podm´ınky a akce). Obsahuje promˇenn´e x a y. Je provediteln´ y pro dvˇe r˚ uzn´ a nav´az´an´ı promˇenn´ ych {x = 1, y = A} a {x = 1, y = B}. Jeho proveden´ı je realizov´ano pro {x = 1, y = A}. 112
12
x x‘y
AAA BBB
B
2‘y+ 3‘B
x x‘y
A
2‘y+ 3‘B
2‘7
2‘7
2‘x
2‘x 45
112 455
AB
457 7
2 455
(a)
(b)
Obr´azek 6.1: Proveden´ı pˇrechodu ve vysoko´ urovˇ nov´e Petriho s´ıti pro nav´az´an´ı promˇenn´ ych {x = 1, y = A}. (a) – stav pˇred proveden´ım, (b) – stav po proveden´ı pˇrechodu.
6.1.2
Paraleln´ı objektovˇ e orientovan´ y syst´ em
OOPN podle [Jan98] specifikuje paraleln´ı objektovˇe orientovan´ y syst´em. Takov´ y syst´em lze popsat jako abstraktn´ı matematick´ y stroj, kter´ y m´ a strukturu a chov´an´ı. Struktura objektovˇe orientovan´eho syst´emu je urˇcena mnoˇzinou tˇr´ıd, specifikuj´ıc´ıch reprezentaci instanc´ı (instanˇcn´ı promˇenn´e) a mnoˇzinu metod, vˇcetnˇe tzv. implicitn´ı metody, popisuj´ıc´ı implicitn´ı aktivitu objektu. Dynamika syst´emu spoˇc´ıv´ a v postupn´ ych zmˇen´ ach stavu (pˇriˇcemˇz jeden stav je definov´an jako v´ ychoz´ı). Stav objektovˇe orientovan´eho syst´emu je d´an mnoˇzinou moment´alnˇe existuj´ıc´ıch objekt˚ u. Kaˇzd´ y z nich se nach´az´ı ve stavu, kter´ y je d´an hodnotami instanˇcn´ıch promˇenn´ ych a stavy vˇsech moment´alnˇe existuj´ıc´ıch (rozpracovan´ ych) metod. Evoluci (postupn´e zmˇeny stavu) tohoto syst´emu lze pak definovat pravidly,
ˇ A OBJEKTY 6.1. PETRIHO S´ITE
59
specifikuj´ıc´ımi podm´ınky v´ yskytu jist´ ych ud´alost´ı a zmˇeny stavu pˇri v´ yskytu tˇechto ud´alost´ı. V paraleln´ım objektovˇe orientovan´em syst´emu existuj´ı ˇctyˇri typy ud´alost´ı: 1. Ud´ alost typu A – zmˇena stavu objektu bez interakce s ostatn´ımi objekty. 2. Ud´ alost typu N – vytvoˇren´ı nov´eho objektu pˇri zasl´ an´ı zpr´ avy new pˇr´ısluˇsn´e tˇr´ıdˇe. 3. Ud´ alost typu F – vytvoˇren´ı nov´e instance metody pˇri zasl´ an´ı odpov´ıdaj´ıc´ı zpr´ avy. 4. Ud´ alost typu J – ukonˇcen´ı existence instance metody s pˇred´ an´ım v´ ysledku volaj´ıc´ımu objektu. Implicitn´ı souˇc´ast´ı kaˇzd´e ud´alosti je garbage collecting, tedy odstranˇen´ı nedostupn´ ych objekt˚ u. Ud´ alosti mˇen´ı stav syst´emu. Objekty v r´amci syst´emu mohou dynamicky vznikat a zanikat, stejnˇe tak i instance metod. Obr´azek 6.2 ukazuje dekompozici procesu syst´emu do objekt˚ u, skl´ adaj´ıc´ıch se z proces˚ u metod (v ˇcasov´em diagramu jsou mnoˇziny okamˇzik˚ u, kdy proces existuje, vyznaˇceny ˇsed´ ymi oblastmi). s
(a)
o0 s
o1 o2
(b)
o3
p0 o1
p1 p2
(c)
p3
Obr´azek 6.2: Proces syst´emu (a) a jeho dekompozice do objekt˚ u (b). Objekt o0 je hlavn´ı (prvotn´ı) objekt, existuj´ıc´ı po dobu existence syst´emu. Objekt o1 je d´ale dekomponov´an do proces˚ u metod (c), p1 je proces implicitn´ı metody, existuj´ıc´ı po dobu existence objektu.
6.1.3
Modelov´ an´ı objekt˚ u Petriho s´ıtˇ emi
Objektovˇe orientovan´ y paraleln´ı syst´em lze podle [Jan98] popsat Petriho s´ıtˇemi takto: 1. Kaˇzd´ a metoda je definov´ana samostatnou vysoko´ urovˇ novou Petriho s´ıt´ı, kterou nazveme s´ıt’ metody. S´ıt’ definuj´ıc´ı vlastn´ı aktivitu objektu (jde o tzv. implicitn´ı metodu, kter´a je implicitnˇe vyvol´ana vznikem objektu) nazveme s´ıt’ objektu. Tˇr´ıda je specifikov´ana jednou s´ıt´ı objektu a mnoˇzinou s´ıt´ı metod. 2. S´ıtˇe metod sd´ıl´ı m´ısta s´ıtˇe objektu (pˇrechody s´ıtˇe metody maj´ı pˇr´ıstup k m´ıst˚ um s´ıtˇe objektu). Tato m´ısta hraj´ı podobnou u ´lohu, jako instanˇcn´ı promˇenn´e v bˇeˇzn´ ych objektovˇe orientovan´ ych programovac´ıch jazyc´ıch. 3. Znaˇcky (tokens) v s´ıt´ıch reprezentuj´ı objekty (jsou to reference na objekty). 4. Tˇr´ıdy lze definovat jako podtˇr´ıdy existuj´ıc´ıch tˇr´ıd, tedy dˇedˇen´ım. Metody jsou dˇedˇeny klasick´ ym zp˚ usobem [GR89], dˇediˇcnost reprezentace objektu spoˇc´ıv´ a v dˇedˇen´ı uzl˚ u s´ıtˇe objektu (hrany s´ıtˇe jsou povaˇzov´any za souˇc´ast pˇrechod˚ u).
´ U ˚ FORMALISMEM OOPN KAPITOLA 6. SPECIFIKACE SYSTEM
60
5. Metody jsou invokov´any zas´ıl´an´ım zpr´ av. Zasl´ an´ı zpr´ avy m˚ uˇze b´ yt specifikov´ano anotac´ı pˇrechodu, patˇr´ıc´ıho nˇekter´e s´ıti metody nebo s´ıti objektu. 6. Nˇekter´e pˇrechody s´ıtˇe objektu jsou prohl´aˇseny za speci´aln´ı metody (tzv. synchronn´ı porty), urˇcen´e pro pro atomickou synchronn´ı komunikaci, realizovanou zas´ıl´an´ım zpr´ av ze str´aˇz´ı pˇrechod˚ u.
6.1.4
Interakce objekt˚ u – zas´ıl´ an´ı zpr´ av x x>0
guard
x
x
x>0
y := x + 1
y := x + 1 x
y
action
y
Obr´azek 6.3: Anotace pˇrechodu – str´aˇz a akce. V objektovˇe orientovan´em syst´emu se veˇsker´e v´ ypoˇcty realizuj´ı zas´ıl´an´ım zpr´ av. V OOPN je zas´ıl´an´ı zpr´ av moˇzn´e specifikovat v r´amci akc´ı a str´aˇz´ı pˇrechod˚ u (viz obr. 6.3). Adres´atem zpr´ avy m˚ uˇze b´ yt bud’ primitivn´ı objekt (napˇr. ˇc´ıslo, ˇretˇezec apod.), nebo objekt, definovan´ y Petriho s´ıtˇemi. Adres´at, a tedy odpov´ıdaj´ıc´ı metoda, se zjist´ı v r´amci zjiˇst’ov´an´ı proveditelnosti pˇrechodu. M˚ uˇze j´ıt o metodu primitivn´ıho objektu, nebo o metodu, definovanou Petriho s´ıt´ı, nebo o synchronn´ı port. Zasl´ an´ı zpr´ avy, specifikovan´e ve str´aˇzi pˇrechodu, je interpretov´ano jako atomick´ a synchronn´ı interakce, kter´a spoˇc´ıv´ a v invokaci synchronn´ıho portu (viz d´ale). Zasl´ an´ı zpr´ avy, specifikovan´e v akci pˇrechodu, je interpretov´ano jako invokace s´ıtˇe metody.
6.1.5
Invokace metod objekt˚ u zas´ıl´ an´ım zpr´ av
S´ıtˇe metod, specifikovan´e jako souˇc´ast tˇr´ıd, jsou urˇceny k dynamick´e instanciaci v reakci na pˇr´ıchoz´ı zpr´ avy. Pˇrijet´ı zpr´ avy objektem odpov´ıd´ a ud´alosti typy F (fork, vytvoˇren´ı nov´eho procesu metody). V´ ysledkem je vytvoˇren´ı nov´e instance (kopie) odpov´ıdaj´ıc´ı s´ıtˇe metody (a pˇr´ıpadn´e um´ıstˇen´ı parametr˚ u do parametrov´ ych m´ıst). Tato instance s´ıtˇe existuje, dokud nedojde k um´ıstˇen´ı znaˇcky do m´ısta return. Pak m˚ uˇze doj´ıt k ud´alosti typu J (join, ukonˇcen´ı procesu metody). T´ım dojde k ukonˇcen´ı existence instance metody, pˇred´ an´ı v´ ysledku a proveden´ı v´ ystupn´ı ˇc´asti pˇrechodu, kter´ y zaslan´ım zpr´ avy metodu invokoval. Na obr´ azku je zn´ azornˇen princip invokace metody. Poznamenejme, ˇze pˇrechody s´ıtˇe metody mohou pˇristupovat k m´ıst˚ um s´ıtˇe objektu a ovlivˇ novat tak stav objektu.
6.1.6
Atomick´ a synchronn´ı interakce objekt˚ u
Zasl´ an´ı zpr´ avy neprimitivn´ımu objektu ve str´aˇzi pˇrechodu je interpretov´ano jako atomick´ a synchronn´ı komunikace. Jde o komunikaˇcn´ı koncept, umoˇzn ˇuj´ıc´ı podm´ınit proveditelnost pˇrechodu souˇcasnou proveditelnost´ı jin´eho (volan´eho) pˇrechodu, nazvan´eho synchronn´ı port. Jsou-li oba pˇrechody provediteln´e, mohou b´ yt provedeny, a to synchronnˇe, jako jedna atomick´a operace. Synchronn´ı port lze povaˇzovat za speci´aln´ı druh metody, kterou lze volat ze str´aˇze jin´eho pˇrechodu zasl´ an´ım zpr´ avy. Tento druh komunikace je vhodn´ y pro
6.2. FORMALISMUS OOPN
61 arg
arg
x
msg: arg send y := o msg: x
wait
receive return
y
return
Obr´azek 6.4: Invokace metody.
modelov´an´ı synchronizace aktivit objekt˚ u ve v´ıce´ urovˇ nov´ ych modelech [?]. Princip atomick´e synchronn´ı interakce, respektuj´ıc´ı polymorfismus a nav´az´an´ı promˇenn´ ych pˇrechodu a parametr˚ u synchronn´ıho portu je zn´ azornˇen na obr´ azku 6.5.
o msg: x
msg: arg
x = arg
Obr´azek 6.5: Atomick´a synchronn´ı interakce objekt˚ u. Synchronn´ı port, kter´ y jen testuje, ale nemodifikuje obsah m´ıst odpov´ıdaj´ıc´ı s´ıtˇe objektu, naz´ yv´ ame predik´ at. V [Maz08] byl pro potˇreby ˇcitelnˇejˇs´ıho modelov´an´ı do OOPN zaveden tak´e negativn´ı predik´ at. Analogicky k not v Prologu, negativn´ı predik´ at selˇze, pokud stejnˇe specifikovan´ y pozitivn´ı predik´ at uspˇeje a naopak. Pomoc´ı negativn´ıho predik´atu lze testovat nepˇr´ıtomnost znaˇcky v m´ıstˇe. Jde o zobecnˇen´ı konceptu inhibiˇcn´ı hrany v Petriho s´ıt´ıch.
6.2
Formalismus OOPN
Formalismus OOPN je podrobnˇe pops´ an a form´ alnˇe definov´ an v [Jan98]. Tamt´eˇz je pops´ ana i jeho konkr´etn´ı implementace, jazyk a syst´em PNtalk. Vzhledem k pomˇern´e rozs´ ahlosti origin´ aln´ı definice jsou d´ale uvedeny jen nejd˚ uleˇzitˇejˇs´ı pojmy a jejich souvislosti, kter´e jsou nutn´e pro pochopen´ı nˇekter´ ych aplikac´ı v navazuj´ıc´ıch kapitol´ ach. Zamˇeˇr´ıme se pˇritom na strukturu OOPN, na reprezentaci stavu a na dynamiku OOPN.
6.2.1
Struktura OOPN
Objektovˇe orientovan´ a Petriho s´ıt’ [Jan98] je definov´ana jako trojice OOP N = (Σ, c0 , oid0 ), kde Σ je syst´em tˇr´ıd, c0 je poˇc´ateˇcn´ı tˇr´ıda a oid0 je jm´eno prvotn´ıho objektu, kter´ y je instanc´ı c0 . Syst´em tˇr´ıd zahrnuje mnoˇzinu tˇr´ıd, hierarchicky uspoˇr´adanou podle relace dˇediˇcnosti. Kaˇzd´e tˇr´ıdˇe pˇr´ısluˇs´ı mnoˇzina jmen instanc´ı (dom´ena) a je pro ni definov´ana struktura instanc´ı. Specifikace struktury instanc´ı tˇr´ıdy zahrnuje s´ıt’ objektu, mnoˇzinu s´ıt´ı metod, mnoˇzinu synchronn´ıch port˚ u, mnoˇzinu selektor˚ u zpr´ av a bijekci mnoˇziny selektor˚ u zpr´ av na mnoˇzinu, obsahuj´ıc´ı metody a synchronn´ı porty. Syst´em tˇr´ıd mus´ı splˇ novat jist´e
´ U ˚ FORMALISMEM OOPN KAPITOLA 6. SPECIFIKACE SYSTEM
62
podm´ınky umoˇzn ˇuj´ıc´ı dˇediˇcnost a zaruˇcuj´ıc´ı, ˇze pro kaˇzdou instanci s´ıtˇe lze urˇcit odpov´ıdaj´ıc´ı s´ıt’ a tˇr´ıdu, ve kter´e byla tato s´ıt’ definov´ana. Anotace Petriho s´ıt´ı jsou specifikov´any inskripˇcn´ım jazykem umoˇzn ˇuj´ıc´ım pracovat tak´e s primitivn´ımi objekty, jako jsou ˇc´ısla, ˇretˇezce atd. Pˇ r´ıklad Pˇr´ıklad OOPN je na obr´ azku 6.6. Obsahuje tˇr´ıdy C0 a C1. Tˇr´ıda C0 obsahuje jen s´ıt’ objektu. Tˇr´ıda C1 obsahuje s´ıt’ objektu, obsahuj´ıc´ı m´ısto p a pˇrechod t, a d´ale obsahuje synchronn´ı port state: a metody waitFor: a reset. Poznamenejme, ˇze tento pˇr´ıklad nemodeluje nic smyslupln´eho, pouze demonstruje formalismus OOPN. C0 is_a PN
C1 is_a PN t3
o state: x. x >= 3 o reset
2‘#e
state: x
p1 x
#e
o
waitFor: x
o
p2
o := C1 new o
t2 y := o waitFor: x
x
x
x t1
reset x
t1
x
0
x
x
t2
0
y
p3
y (x,y) (x,#fail) p4
#success
#fail
x t4
t
0
p
#e
x
y := x + 1 t
return
return
Obr´azek 6.6: Pˇr´ıklad OOPN.
6.2.2
Reprezentace stavu OOPN
Stav OOPN je definov´an jako syst´em objekt˚ u. Objekt je definov´an jako syst´em instanc´ı s´ıt´ı, obsahuj´ıc´ı v dan´em stavu pr´avˇe jednu instanci s´ıtˇe objektu a mnoˇzinu instanc´ı s´ıt´ı metod, kter´e jsou v dan´em stavu rozpracov´any. Kaˇzd´ a instance s´ıtˇe je dvojice (id, m), kde id je jm´eno instance s´ıtˇe a m je znaˇcen´ı t´eto s´ıtˇe (obsahuje znaˇcen´ı m´ıst i pˇrechod˚ u). Znaˇcen´ı m kaˇzd´emu m´ıstu v instanci s´ıtˇe pˇriˇrazuje multimnoˇzinu znaˇcek, identifikuj´ıc´ıch objekty (primitivn´ı, neprimitivn´ı i tˇr´ıdy) a kaˇzd´emu pˇrechodu mnoˇzinu invokac´ı (rozpracovan´ ych metod). Syst´em objekt˚ u je uzavˇren´y, tj. zaruˇcuje, ˇze znaˇcen´ı vˇsech instanc´ı s´ıt´ı ve vˇsech objektech referencuj´ı pouze instance s´ıt´ı obsaˇzen´e v syst´emu objekt˚ u. Tak´e je zaruˇceno, ˇze neobsahuje objekty, kter´e by nebyly tranzitivnˇe dostupn´e z prvotn´ıho objektu. Poˇca ´teˇcn´ı syst´em objekt˚ u objektovˇe orientovan´e Petriho s´ıtˇe OOP N = (Σ, c0 , id0 ) obsahuje jedin´ y objekt, identifikovan´ y jm´enem id0 , kter´ y je instanc´ı poˇc´ateˇcn´ı tˇr´ıdy c0 . Znaˇcen´ı jeho s´ıtˇe objektu odpov´ıd´ a poˇc´ateˇcn´ımu znaˇcen´ı t´eto s´ıtˇe, specifikovan´e ve tˇr´ıdˇe c0 . Pˇ r´ıklad Uvaˇzujme OOPN specifikovanou tˇr´ıdami na obr´ azku 6.6. Poˇc´ateˇcn´ı stav t´eto OOPN je definov´an stavem prvotn´ıho objektu (instance hlavn´ı tˇr´ıdy). Obsahuej por´ ateˇcn´ı znaˇcen´ı s´ıtˇe objektu tˇr´ıdy C0. Objekt je identifikov´ an t´ımt´eˇz jm´enem jako instance jeho s´ıtˇe objektu, a sice id0 . Poˇc´ateˇcn´ı stav oznaˇc´ıme s0 a m˚ uˇzeme ho specifikovat tabulkou 6.1.
6.2. FORMALISMUS OOPN
63 s0 C0
id0 id0 object net
p1 p2 p3 p4 t1 t2 t3
2‘#e empty
1, 2 empty empty empty empty
Tabulka 6.1: Pˇr´ıklad syst´emu objekt˚ u – poˇc´ateˇcn´ı stav s0 .
6.2.3
Dynamika OOPN
Dynamika OOPN je definov´ana poˇc´ateˇcn´ım syst´emem objekt˚ u a pravidly specifikuj´ıc´ımi proveditelnost a prov´adˇen´ı pˇrechod˚ u v instanc´ıch s´ıt´ı. Proveden´ı pˇrechodu je ud´alost, formalizovan´ a jako ˇctveˇrice (e, id, t, b), kde e specifikuje typ ud´alosti (A, N , F nebo J, viz 6.1.2, str. 59), jm´eno id identifikuje instanci s´ıtˇe, ve kter´e k ud´alosti doˇslo, t identifikuje pˇrechod jehoˇz proveden´ı ud´alost zp˚ usobilo a b je nav´az´an´ı promˇenn´ ych pˇrechodu t. V´ yskyt ′ ud´alosti (e, id, t, b) ve stavu S zp˚ usob´ı zmˇenu tohoto stavu na S , coˇz oznaˇcujeme jako krok a zapisujeme S[e, id, t, biS ′ . Pˇrechod m˚ uˇze potenci´alnˇe b´ yt proveden ˇctyˇrmi zp˚ usoby, kter´e odpov´ıdaj´ı ˇctyˇrem typ˚ um ud´alost´ı z 6.1.2. Pˇrechod m˚ uˇze b´ yt pro jist´e nav´az´an´ı promˇenn´ ych A-proveden, pokud zasl´ an´ı zpr´ avy vede na primitivn´ı v´ ypoˇcet, m˚ uˇze b´ yt N-proveden, pokud jde o zasl´ an´ı zpr´ avy new tˇr´ıdˇe, m˚ uˇze b´ yt F-proveden, pokud adres´atem zpr´ avy je objekt, kter´ y m´ a pˇr´ısluˇsnou metodu definov´anu Petriho s´ıt´ı, a m˚ uˇze b´ yt J-proveden, pokud metoda invokovan´ a pˇredchoz´ım F-proveden´ım tohoto pˇrechodu pr´avˇe skonˇcila. A-proveden´ı pˇrechodu odpov´ıd´ a proveden´ı pˇrechodu ve standardn´ı Petriho s´ıti, N-proveden´ı pˇrechodu m´ a za n´asledek vytvoˇren´ı nov´eho objektu, tj, invokaci pˇr´ısluˇsn´e s´ıtˇe objektu, F-proveden´ı m´ a za n´asledek invokaci pˇr´ısluˇsn´e s´ıtˇe metody a uplatn´ı se jen vstupn´ı hrany pˇrechodu, J-proveden´ı m´ a za n´asledek odstranˇen´ı pˇr´ısluˇsn´e instance s´ıtˇe metody a uplatn´ı se jen v´ ystupn´ı hrany pˇrechodu. Vzhledem k tomu, ˇze mezi F- a J-proveden´ım si pˇrechod mus´ı pamatovat pˇr´ısluˇsnou invokaci, byl zaveden pojem znaˇcen´ı pˇrechod˚ u. Je to funkce, pˇriˇrazuj´ıc´ı kaˇzd´emu pˇrechodu mnoˇzinu invokac´ı, tj. dvojic (id, b), kde id je identifikace (jm´eno) vytvoˇren´e instance s´ıtˇe a b je nav´az´an´ı promˇenn´ ych pˇrechodu pˇri jeho F-proveden´ı. Ud´ alosti tvaru (e, id, t, b) postupnˇe modifikuj´ı stav syst´emu. V jednom okamˇziku (v dan´em stavu) m˚ uˇze potenci´alnˇe nastat nˇekolik ud´alost´ı (je zde potenci´alnˇe nˇekolik r˚ uznˇe provediteln´ ych pˇrechod˚ u), ze kter´ ych se nedetrministicky vybere a uskuteˇcn´ı jen jedna. Pˇ r´ıklad Uvaˇzujme OOPN specifikovanou tˇr´ıdami na obr´ azku 6.6 a poˇc´asteˇcn´ı stav z 6.2.2. Proved’me sekvenci krok˚ u s0 s1 s2 s3 s4
[(N, id0 , C0.t1, ())i [(F, id0 , C0.t2, (x = 1, o = id1 ))i [(F, id0 , C0.t2, (x = 2, o = id1 ))i [(A, id1 , C1.t, (x = 0))i [(A, id2 , C1.waitF or : .t2, (x = 1))i s5 .
´ U ˚ FORMALISMEM OOPN KAPITOLA 6. SPECIFIKACE SYSTEM
64 s5 C0
C1
id0 id0 object net
object net waitFor:
p1 p2 p3 p4 t1 t2 t3 p t x return t1 t2
id1
id1 id2
id3
#e id1 empty empty empty
(id2 , {(x, 1), (o, id1 )}), (id3 , {(x, 2), (o, id1 )}) empty
0 empty empty
2
#success
empty
empty
empty
empty
empty
Tabulka 6.2: Pˇr´ıklad syst´emu objekt˚ u – stav s5 . V´ ysledn´ y stav s5 je specifikov´an tabulkou 6.2. Stav s5 obsahuje dva objekty identifikovan´e jm´eny id0 a id1. Znaˇcen´ı nˇekter´ ych m´ıst a pˇrechod˚ u objektu id0 se zmˇenilo. Nov´ y objekt id1 obsahuje instance s´ıt´ı identifikovan´e jako id1, id2 a id3. Instance s´ıt´ı s jm´eny id2 a id3 jsou invokacemi metody waitFor:, vytvoˇren´e proveden´ım pˇrechodu t2 v objektu id1.
6.3
Simul´ ator OOPN
Simulace OOPN spoˇc´ıv´ a v opakovan´em prov´adˇen´ı kroku simulace. V r´amci simulaˇcn´ıho kroku se provede testov´an´ı proveditelnosti pˇrechod˚ u v jednotliv´ ych instanc´ıch s´ıt´ı, tvoˇr´ıc´ıch syst´em objekt˚ u. Z provediteln´ ych pˇrechod˚ u je pak vybr´ an jeden a proveden. Pro pr´aci se simulaˇcn´ım ˇcasem je vˇsak tˇreba tento koncept upravit a zav´est moˇznost specifikovat ˇcek´an´ı. Stejnˇe jako ostatn´ı aktivity, tok ˇcasu se v OOPN specifikuje zas´ıl´an´ım ˇ an´ı v simulaˇcn´ım ˇcase je specifikov´ano akc´ı tvaru self zpr´ av v r´amci akc´ı pˇrechod˚ u. Cek´ hold: t. Proveden´ı pˇrechodu je v takov´em pˇr´ıpadˇe pozdrˇzeno (v simulaˇcn´ım ˇcase) po definovanou dobu a teprve po jej´ım uplynut´ı je provedena v´ ystupn´ı ˇc´ast pˇrechodu. Pl´ anov´an´ı ud´alost´ı je v simul´ atoru OOPN realizov´ano kalend´ aˇrem. Pr˚ ubˇeh simulace je n´asleduj´ıc´ı: 1. Dokud existuje provediteln´ y pˇrechod, provede se. Pˇri prov´adˇen´ı pˇrechod˚ u se do kalend´aˇre umist’uj´ı pl´ anovan´e ud´alosti ve tvaru (ˇcas, ud´alost). Jde o ud´alosti typu J (dokonˇcen´ı rozpracovan´eho pˇrechodu), kter´e se pl´ anuj´ı v d˚ usledku ˇcek´an´ı, specifikovan´eho akc´ı self hold: t. 2. Nen´ı-li ˇz´adn´ y pˇrechod provediteln´ y, dojde k posuvu ˇcasu podle nejbliˇzˇs´ı pl´ anovan´e ud´alosti a ud´alost (t.j. dokonˇcen´ı ˇcekaj´ıc´ıcho pˇrechodu) se provede. Pokraˇcuje se bodem 1. Simul´ ator OOPN pˇripouˇst´ı tak´e zasl´ an´ı zpr´ avy self hold: t ve str´aˇzi pˇrechodu. V takov´em pˇr´ıpadˇe je str´aˇz splnˇena (a pˇrechod se m˚ uˇze prov´est), pokud je pˇrechod nepˇretrˇzitˇe provediteln´ y po specifikovanou dobu.
ˇ ´I OOPN DO DEVS 6.4. ZAPOUZDREN
6.4
65
Zapouzdˇ ren´ı OOPN do DEVS
Simul´ ator OOPN m˚ uˇzeme popsat, resp. zapouzdˇrit jako syst´em s diskr´etn´ımi ud´alostmi v souladu s definic´ı DEVS. To n´am umoˇzn´ı specifikovat komponenty DEVS formalismem OOPN. Princip zapouzdˇren´ı OOPN do DEVS tkv´ı v tom, ˇze dvˇe disjunktn´ı podmnoˇziny mnoˇziny m´ıst prohl´as´ıme za vstupn´ı, resp. v´ ystupn´ı, asynchronn´ı porty a definujeme reprezentaci stavu zapouzdˇruj´ıc´ıho DEVS a funkce zapouzdˇruj´ıc´ıho DEVS takto: • Mnoˇzina stav˚ u je mnoˇzina syst´em˚ u objekt˚ u, dosaˇziteln´ ych z poˇc´ateˇcn´ıho syst´emu objekt˚ u. • Vstupn´ı porty odpov´ıdaj´ı vstupn´ım asynchronn´ım port˚ um hlavn´ıho objektu. V´ ystupn´ı porty odpov´ıdaj´ı v´ ystupn´ım asynchronn´ım port˚ um hlavn´ıho objektu. Hodnoty vstup˚ u a v´ ystup˚ u patˇr´ı do mnoˇziny primitivn´ıch objekt˚ u OOPN. • Intern´ı pˇrechodov´a funkce δint realizuje proveden´ı jedn´e ud´alosti v OOPN, pl´ anovan´e na aktu´aln´ı ˇcas. V pˇr´ıpadˇe konfliktu se vybere jedna ud´alost pomoc´ı preferenˇcn´ı funkce select, definovan´e podobnˇe, jako v pˇr´ıpadˇe sloˇzen´ ych model˚ u DEVS (vybere jeden z libovoln´e podmnoˇziny mnoˇziny vˇsech m´ od˚ u pˇrechod˚ u2 ). • Funkce posuvu ˇcasu ta vrac´ı dobu, za kterou m´ a doj´ıt k n´asleduj´ıc´ı pl´ anovan´e ud´alosti v OOPN, tj. bud’ 0, existuje-li alespoˇ n jeden provediteln´ y pˇrechod v aktu´aln´ım ˇcase, nebo (tc −t), kde tc je ˇcas nejbliˇzˇs´ı pl´ anovan´e ud´alosti v kalend´ aˇri a t je ˇcas aktu´aln´ı, je-li v kalen´ aˇri alespoˇ n jedna poloˇzka. Je-li kalend´ aˇr pr´azdn´ y, ta vrac´ı hodnotu ∞ (syst´em je pasivov´an). • Extern´ı pˇrechodov´a funkce δext modifikuje stav vstupn´ıch asynchronn´ıch port˚ u hlavn´ıho objektu pˇrid´ an´ım objekt˚ u ze vstupn´ıch port˚ u DEVS. • V´ ystupn´ı funkce λ mapuje (z implementaˇcn´ıho hlediska pˇresune) obsah v´ ystupn´ıch asynchronn´ıch port˚ u hlavn´ıho objektu do v´ ystupn´ıch port˚ u DEVS.
6.5
Dynamick´ e aplikaˇ cn´ı rozhran´ı simul´ atoru
Simul´ ator OOPN m˚ uˇze b´ yt realizov´an souladu s principy otevˇren´e abstraktn´ı architektury pro simulaci vyv´ıjej´ıc´ıch se syst´em˚ u, popsan´e v kapitole 4. Dynamick´e aplikaˇcn´ı rozhran´ı simul´ atoru OOPN pak umoˇzn ˇuje manipulovat se strukturou tˇr´ıd i jejich instanc´ı, s metodami i s jejich invokacemi. Manipulace spoˇc´ıv´ a ve ˇcten´ı struktury a stavu a v modifikaci struktury a stavu jednotliv´ ych Petriho s´ıt´ı. Je-li v´ ysledkem dynamick´e manipulace konzistentn´ı syst´em objekt˚ u dle definice [Jan98], simulace po tomto z´asahu korektnˇe pokraˇcuje, v opaˇcn´em pˇr´ıpadˇe je simulace ukonˇcena v d˚ usledku chyby. Tˇr´ıdy OOPN jsou v PNtalku glob´alnˇe dostupn´e jm´enem. Pˇr´ıstup k metod´am uvnitˇr tˇr´ıdy je moˇzn´ y prostˇrednitv´ım jm´ena (selektoru odpov´ıdaj´ıc´ı zpr´ avy). S´ıt’ objektu je dostupn´a pod jm´enem #object. Uzly Petriho s´ıt´ı jsou tak´e pˇr´ıstupn´e prostˇrednictv´ım sv´ ych jmen. Tˇr´ıdy, metody, m´ısta a pˇrechody rozumˇen´ı zpr´ av´am, kter´e odpov´ıdaj´ı metaoperac´ım pro inspekci a editaci. 2
M´ od pˇrechodu je varianta proveden´ı, zahrnuj´ıc´ı nav´ az´ an´ı promˇenn´ ych, pro kter´e je pˇrechod provediteln´ y.
66
´ U ˚ FORMALISMEM OOPN KAPITOLA 6. SPECIFIKACE SYSTEM
Podobnˇe lze pˇristupovat k reprezentaci aktu´aln´ıho stavu. Jde o syst´em objekt˚ u, zapouzdˇruj´ıc´ıch mnoˇziny proces˚ u. Hlavn´ı objekt je v PNtalku glob´alnˇe pˇr´ıstupn´ y pod jm´enem #main. Objekty jsou dostupn´e prostˇrednictv´ım referenc´ı, kter´e se vyskytuj´ı v podobˇe znaˇcek v m´ıstech Petriho s´ıt´ı. Procesy metod jsou prov´az´ any relac´ı invokace do hierarchick´e struktury, kter´a m´ a koˇren v procesu s´ıtˇe hlavn´ıho objektu. Tato hierarchie proces˚ u je obvykle v´ ychodiskem pro navigaci ve struktuˇre stavu OOPN. Jednotliv´e sloˇzky stavu lze ˇc´ıst i editovat pouˇzit´ım adekv´atn´ıch metaoperac´ı. Integrace OOPN do prostˇ red´ı SmallDEVS Interpret OOPN (PNtalk) s dynamick´ ym aplikaˇcn´ım rozhran´ım je intergrov´an do prostˇred´ı SmallDEVS (popsan´eho v kapitole 5), kde umoˇzn ˇuje specifikovat atomick´e komponenty DEVS pomoc´ı OOPN. Pˇr´ıstup k prvk˚ um OOPN je moˇzn´ y prostˇrednictv´ım prohl´ıˇzeˇce MyRepository (viz kap. 5). Tˇr´ıdy OOPN jsou v MyRepository pˇr´ıstupn´e ve sloˇzce PNtalk. Na dalˇs´ı u ´rovni hierarchie jsou metody. Jak tˇr´ıdy, tak metody lze editovat odpov´ıdaj´ıc´ımi vizu´aln´ımi n´astroji. Procesy OOPN jsou v MyRepository pˇr´ıstupn´e jako hierarchicky niˇzˇs´ı poloˇzky pod komponentou DEVS, specfikovanou formalismem OOPN. Hierarchicky niˇzˇs´ı u ´roveˇ n trvoˇr´ı procesy vytvoˇren´e procesy na u ´rovni vyˇsˇs´ı. Stav procesu je k dispozici jako znaˇcen´ı odpov´ıdaj´ıc´ı Petriho s´ıtˇe.
6.6
Shrnut´ı
OOPN lze pouˇz´ıt pro specifikaci syst´emu s diskr´etn´ımi ud´alostmi v souladu s definic´ı DEVS d´ıky kompatibiln´ımu zapouzdˇren´ı. V n´avaznosti na definici otevˇren´e abstraktn´ı architektury pro simulaci vyv´ıjej´ıc´ıch se syst´em˚ u, kter´a byla uvedena za pouˇzit´ı formalismu DEVS, lze definovat dynamick´e aplikaˇcn´ı rozhran´ı i pro simul´ ator OOPN. Praktickou implementac´ı je syst´em PNtalk/SmallDEVS, kter´ y umoˇzn ˇuje atomick´e komponenty DEVS specifikovat formalismem OOPN. Specifikace atomick´ ych komponent sloˇzen´eho modelu pomoc´ı OOPN pˇrin´ aˇs´ı vyˇsˇs´ı u ´roveˇ n popisu a sugestivn´ı vizualizovatelnost. Aplikovatelnost OOPN a DEVS v simulaˇcn´ım modelov´an´ı a n´avrhu syst´em˚ u je demonstrov´ana n´asleduj´ıc´ımi pˇr´ıpadov´ ymi studiemi.
Kapitola 7
Pˇ r´ıpadov´ a studie: Reflektivn´ı simul´ ator DEVS Uˇziteˇcnou vlastnost´ı modelovac´ıho formalismu je schopnost definovat vlastn´ı s´emantiku. Pˇr´ıkladem m˚ uˇze b´ yt reflektivn´ı simul´ ator DEVS. Je to simul´ ator DEVS specifikovan´ y jako DEVS. Root Coordinator
Coordinator
Coupled Model
Atomic Model
Coordinator
Atomic Model
Coupled Model
Atomic Model
Simulator
Simulator
Simulator
Obr´azek 7.1: Mapov´an´ı mezi modely a simul´ atory Pˇripomeˇ nme si nejprve princip hierarchick´e simulace DEVS. Kaˇzd´emu modelu odpov´ıd´ a pˇr´ısluˇsn´ y simul´ ator a na vrcholu hierarchie je koˇrenov´ y simul´ ator (vz obr. 7.1). Pˇri realizaci reflektivn´ıho simul´ atoru lze vyj´ıt ze specifikace abstraktn´ıho simul´ atoru DEVS. Tu je vˇsak tˇreba pˇrizp˚ usobit charakteru c´ılov´eho implementaˇcn´ıho formalismu. Origin´aln´ı abstraktn´ı simul´ ator DEVS podle [ZKP00] je specifikov´an s ohledem na implementaci v bˇeˇzn´em prog. jazyce a proto obsahuje referenci na nadˇrazen´ y simul´ ator a komunikuje pˇr´ım´ ym pˇred´ av´an´ım zpr´ av adres´atovi (jde o synchronn´ı komunikaci). Formalismus DEVS nepouˇz´ıv´ a reference, komponenty o sobˇe vz´ ajemnˇe nev´ı, jen nadˇrazen´ a komponenta zn´ a jejich propojen´ı (komponenty jsou pojmenovan´e a propojen´ı je definov´ano s vyuˇzit´ım jmen komponent a port˚ u). Algoritmy a struktura simul´ atoru a koordin´atoru proto mus´ı b´ yt upraveny pro takto volnˇe v´azan´e hierarchicky organizovan´e komponenty komunikuj´ıc´ı asynchronˇe pˇred´ avan´ ymi zpr´ avami. Lze pˇritom vyj´ıt napˇr. z [Van00] (podobnˇe jsou specifikov´any algoritmy simul´ ator˚ u v kap. 2). V naˇsem pˇr´ıpadˇe pouˇzijeme zpr´ avy tvaru (msg, f rom/to, t). Obsahuj´ı oproti origin´ alu nav´ıc jm´ena odesilatele, resp. pˇr´ıjemce. Toto
68
´ KAPITOLA 7. REFLEKTIVN´I SIMULATOR DEVS
adresov´an´ı umoˇzn´ı pˇripojit v´ıce komponent na jeden port, coˇz zjednoduˇs´ı propojov´an´ı (pˇrid´ av´an´ı dedikovan´ ych port˚ u pro kaˇzdou komponentu kompozitu by model ponˇekud zkomplikovalo). Simul´ ator atomick´ eho modelu Simul´ ator atomick´eho modelu specifikujeme jako syst´em SM = (X, S, Y, δint , δext , λ, ta, M ). Mnoˇzina X obsahuje vˇsechny zpr´ avy tvaru (i, to, t), (x, to, t), (∗, to, t). Mnoˇzina Y obsahuje vˇsechny zpr´ avy tvaru (y, f rom, tn), (done, f orm, tn), (log, f rom, tn). Mnoˇzina S je strukturov´ana do promˇenn´ ych tlast , tnext , y, (s, e). Funkce δint , δext , λ, ta jsou definov´any tak, aby syst´em reagoval na vstupn´ı ud´alosti podle specifikace uveden´e v kap. 2 v z´avislosti na specifikaci atomick´eho modelu M = (X, S, Y, δint , δext , λ, ta), definovan´eho takt´eˇz v kap. 2. Simul´ ator sloˇ zen´ eho modelu Simul´ ator sloˇzen´eho modelu (koordin´ator) specifikujeme jako syst´em SN = (X, S, Y, δint , δext , λ, ta, N ), Mnoˇzina X obsahuje vˇsechny zpr´ avy tvaru (i, to, t), (x, to, t), (∗, to, t), (y, f rom, tn), (done, f rom, tn). Mnoˇzina Y obsahuje vˇsechny zpr´ avy tvaru (y, f rom, tn), (done, f orm, tn), (i, to, t), (x, to, t), (∗, to, t), (log, f rom, tn). Mnoˇzina S je strukturov´ana do promˇenn´ ych tlast , tnext , y, eventList receivers, activeChildren (viz algoritmus simul´ atoru v kap. 2). Funkce δint , δext , λ, ta jsou definov´any tak, aby syst´em reagoval na vstupn´ı ud´alosti podle specifikace uveden´e v kap. 2. v z´avislosti na specifikaci sloˇzen´eho modelu N = (X, Y, D, {Md }, EIC, EOC, IC, select), definovan´eho takt´eˇz v kap. 2. Koˇ renov´ y simul´ ator Koˇrenov´ y simul´ ator specifikujeme jako syst´em SR = (X, S, Y, δint , δext , λ, ta) Mnoˇzina X obsahuje vˇsechny zpr´ avy tvaru (start), (stop), (reset), (stopT ime, t), (done, f rom, tn). Mnoˇzina Y obsahuje vˇsechny zpr´ avy tvaru (i, to, t), (∗, to, t), (log, f rom, tn). Mnoˇzina S je strukturov´ana do promˇenn´ ych, reprezentuj´ıc´ıch stav simulace, aktu´aln´ı ˇcas t a ˇcas n´asleduj´ıc´ıc ud´alost´ı tnext . Funkce δint , δext , λ, ta jsou definov´any tak, aby syst´em reagoval na vstupn´ı ud´alosti prov´aden´ım jednotliv´ ych krok˚ u simulace, pˇr´ıpadnˇe zmˇenou stavu (zastaven´ı spuˇstˇen´ı) a zmˇenou paramert˚ u simulace. Reflektivn´ı simul´ ator Mˇejme sloˇzen´ y model, obsahuj´ıc´ı gener´ ator a procesor, viz obr. 7.2. Kompletn´ı reflektivn´ı simul´ ator tohoto modelu je pak specifikov´an jako sloˇzen´ y model, zobrazen´ y na obr. 7.3. Simulator simuluje generator, Simulator2 simuluje processor, Coordinator simuluje cel´ y model a RootSolver ˇr´ıd´ı celou simulaci. Realizace Uveden´ y reflektivn´ı simul´ ator lze pro dan´ y model vygenerovat staticky: Na z´akladˇe modelu se jednou nar´ az zkonstruuje cel´a struktura simul´ atoru pomoc´ı kompil´atoru DEVS do DEVS. Takto lze pracovat s DEVS podle p˚ uvodn´ı (statick´e) definice. Jinou moˇznost´ı je v reflektivn´ım simul´ atoru zpˇr´ıstupnit kompletn´ı aplikaˇcn´ı rozhran´ı pro dynamick´e vytv´aˇren´ı, inspekci a editaci model˚ u (a jejich simul´ ator˚ u). Pak m´ ame na zaˇc´atku k
69
Obr´azek 7.2: Model gener´ atoru a procesoru
Obr´azek 7.3: Model simul´ atoru modelu gener´ atoru a procesoru dispozici pouze koˇrenov´ y simul´ ator s pr´azdn´ ym modelem. D´ıky zpˇr´ıstupnˇen´ ym operac´ım lze pak dynamicky vytv´aˇret, editovat a manipulovat s modely a s celou simulac´ı. Praktick´ y v´ yznam reflektivn´ı simulace DEVS Lze ovˇeˇrit funkˇcnost a analyzovat v´ ykonnostn´ı aspekty r˚ uzn´ ych modifikac´ı simul´ atoru DEVS. Pouˇ zit´ı jin´ ych formalism˚ u Uveden´ y reflektivn´ı simul´ ator DEVS pouˇz´ıv´ a tzv. metacirkul´ arn´ı architekturu. To znamen´a, ˇze pro dom´enovou u ´roveˇ n i pro meta´ uroveˇ n je pouˇzit tent´ yˇz formalismus. Potenci´alnˇe je moˇzn´e pro r˚ uzn´e u ´rovnˇe pouˇz´ıt r˚ uzn´e formalismy, resp. jazyky. Nyn´ı zv´ aˇz´ıme moˇznost pouˇzit´ı jin´eho formalismu, konkr´etnˇe OOPN. Vzhledem k tomu, ˇze jde o velmi vysoko´ urovˇ nov´ y formalismus s ˇsirok´ ymi vyjadˇrovac´ımi schopnostmi (jako univerz´ aln´ı programovac´ı jazyk) s moˇznost´ı komponent´ıho modelov´an´ı konformn´ıho s konceptem sloˇzen´ ych model˚ u DEVS, nebudeme implementovat hierarchick´ y simul´ ator DEVS pomoc´ı OOPN (pˇrestoˇze bychom to mohli udˇelat analogicky k uveden´e implementaci simul´ atoru DEVS pomoc´ı DEVS), ale pouˇzijeme pˇr´ım´e mapov´an´ı formalismu DEVS do formalismu OOPN. Mapov´an´ı atomick´eho modelu DEVS do OOPN je uk´az´ano na obr´ azku 7.4. Mechanismus zpracov´an´ı vstup˚ u, modifikace stavu a generov´an´ı v´ ystup˚ u je specifikov´an vysoko´ urovˇ novou Petriho s´ıt´ı. Kaˇzd´ y konkr´etn´ı model, implementovan´ y jako podtˇr´ıda AtomicDEV S, specifikuje (1) funkce DEVS, kter´e jsou realizov´any odpov´ıdaj´ı-
´ KAPITOLA 7. REFLEKTIVN´I SIMULATOR DEVS
70 AtomicDEVS is_a PN
.
x x x x
x
x
.
.
x
self hold: (self taS: s)
. . y := self lambdaS: s . .
. x
.
x
s
x
s
t := self time. newS := self deltaExtS: x E: (self time - lastT) X: x
s
newS
s
s t lastT
.
newS lastT lastT
y y
t := self time. newS := self deltaIntS: s
t
deltaExtS: s E:e: X: x
deltaIntS: s
lambdaS: s
taS: s
Obr´azek 7.4: DEVS v OOPN c´ımi metodami v OOPN, a (2) poˇc´ateˇcn´ı znaˇcen´ı m´ısta s, kter´e obsahuje poˇc´ateˇcn´ı stav modelu. Tento pˇr´ıstup je moˇzn´e t´emˇeˇr beze zmˇeny pouˇz´ıt pro mapov´an´ı DEVS do CPN (Coloured Petri nets), implementovan´ ych n´astrojem CPNTools a vyuˇz´ıt jeho konceptu hierarchick´ ych m´ıst a pˇrechod˚ u pro realizaci sloˇzen´ ych model˚ u. Takto lze simulovat a analyzovat modely na b´azi DEVS s vyuˇzit´ım standardn´ıho n´astroje pro vysoko´ urovˇ nov´e Petriho s´ıtˇe.
Kapitola 8
Pˇ r´ıpadov´ a studie: Simulace simuluj´ıc´ıho syst´ emu Simuluj´ıc´ı syst´em je syst´em, jehoˇz souˇc´ast´ı je simulace. Simuluje-li syst´em s´ am sebe a pouˇz´ıv´ a-li v´ ysledky vlastn´ı simulace pro modifikaci sv´eho vlastn´ıho chov´an´ı v budoucnu, jde o reflektivn´ı simulaci. Do tˇr´ıdy simuluj´ıc´ıch syst´em˚ u typicky patˇr´ı syst´emy, jejichˇz souˇc´ast´ı je rozhodovac´ı proces, obsahuj´ıc´ı simulaci. Takov´e syst´emy se v praxi vyskytuji pomˇernˇe ˇcasto. Staˇc´ı si pˇredstavit situaci [Skl97], kdy skupina expert˚ u navrhne mnoˇzinu moˇzn´ ych ˇreˇsen´ı dan´eho probl´emu v r´ amci sloˇzit´eho syst´emu. Pˇritom d˚ usledky jednotliv´ ych ˇreˇsen´ı nen´ı moˇzn´e analyticky zjistit ani jednoduˇse otestovat. Jedin´ ym ˇreˇsen´ım je pro vˇsechny n´avrhy expert˚ u prov´est simulaˇcn´ı experimenty, jejich v´ ysledky porovnat a pot´e prov´est rozhodnut´ı. Simulace simuluj´ıc´ıch syst´em˚ u pak d´av´a smysl jako souˇc´ast procesu rozhodov´an´ı probl´em˚ u, t´ ykaj´ıc´ıch se simuluj´ıc´ıch syst´em˚ u. Jako pˇr´ıklad uvedeme optimalizaci poˇctu otevˇren´ ych pˇrep´ aˇzek v bance v z´avislosti na zmˇen´ ach pravdˇepodobnostn´ıho rozloˇzen´ı pˇr´ıchoz´ıch klient˚ u v pr˚ ubˇehu dne.
8.1
Pˇ r´ıklad vnoˇ ren´ e simulace: Syst´ em hromadn´ e obsluhy, jehoˇ z ˇ c´ ast je optimalizov´ ana opakovanou vnoˇ renou simulac´ı
Obr´azek 8.1 ukazuje syst´em, kter´ y chceme simulovat. Jde velmi zjednoduˇsenou abstrakci hypotetick´e banky, kde klienti nejprve ˇcekaj´ı ve frontˇe, by byli obslouˇzeni u ´ˇredn´ıkem (teller) zpracov´avaj´ıc´ım jejich poˇzadavky. Pot´e je (po ˇcek´an´ı v dalˇs´ı frontˇe) obslouˇzen u ´ˇredn´ıkem na pokladnˇe (cashier). Pravdˇepodobnostn´ı rozloˇzen´ı doby mezi pˇr´ıchody klient˚ u a doby trv´ an´ı obˇema typy u ´ˇredn´ık˚ u jsou zn´ ama. Pˇredpokl´ adejme, ˇze banka m´ a k dispozici nˇekolk ˇ ızen´ı banky chce optiu ´ˇredn´ık˚ u, kteˇr´ı jsou schopni pracovat na libovoln´e z obou pozic. R´ malizovat pˇridˇelen´ı u ´ˇredn´ık˚ u k obˇema typ˚ um pˇrep´ aˇzek v r˚ uzn´ ych ˇc´astech dne, kter´e se liˇs´ı ˇcetnost´ı pˇr´ıchodu klient˚ u do banky. Rozliˇsuj´ı se tˇri obdob´ı, kter´a nazveme ”busy”, ”idle” a ”very busy”. Pro nalezen´ı nejlepˇs´ı strategie pˇrˇrazen´ı u ´ˇredn´ık˚ u k pˇrep´ aˇzk´ am je pouˇzita simulace (je-li syst´em simulov´an, jde o vnoˇrenou simulaci): Na zaˇc´atku kaˇzd´e periody se opakovanˇe provede simulace prvn´ı ˇc´asti syst´emu (tj. fronty s mnoˇzinou pˇrep´ aˇzek prvn´ıho typu – teller) pro r˚ uzn´e poˇcty u ´ˇredn´ık˚ u (tellers) v rozsahu od 1 do celkov´eho poˇctu dostupn´ ych u ´ˇredn´ık˚ u (10). Na z´akladˇe v´ ysledk˚ u jednotliv´ ych simulac´ı veden´ı banky urˇc´ı poˇcty
72
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
Obr´azek 8.1: Syst´em hromadn´e obsluhy se dvˇema frontami a obsluˇzn´ ymi linkami (pˇrevzato z [Skl97])
Obr´azek 8.2: Z´akladn´ı idea vnoˇren´e simulace (pˇrevzato z [Skl97])
ˇ 8.2. MODEL S VNORENOU SIMULAC´I V JAZYCE SIMULA
73
u ´ˇredn´ık˚ u pro pˇrep´ aˇzky prvn´ıho typu (tellers) a druh´eho typu (cashiers). Pro jednoduchost v naˇsem simulaˇcn´ım modelu ponech´ame v´ ybˇer nejlepˇs´ı varianty na interaktivn´ım z´asahu uˇzivatele – program nab´ıdne moˇznosti pˇrerozdˇelen´ı u ´ˇredn´ık˚ u (spolu s odpov´ıdaj´ıc´ımi simulaˇcn´ımi v´ ysledky), z kter´ ych uˇzivatel jednu vybere. Rozhodovac´ım krit´eriem je pr˚ umˇern´ y ˇcas str´aven´ y klientem v bance (resp. v jej´ı prvn´ı ˇc´asti, tj. ve frontˇe a u pˇrep´ aˇzky prvn´ıho typu). Pro moˇznost pˇr´ım´eho porovn´an´ı uvedeme dvˇe implementace modelu t´ehoˇz syst´emu, realizovan´e v r˚ uzn´ ych simulaˇcn´ıch jazyc´ıch. Jedn´ım z nich je klasick´ y jazyk pro simulaˇcn´ı modelov´an´ı (SIMULA), druh´ y je experiment´aln´ı vizu´aln´ı jazyk pro paraleln´ı objektovˇe orientovan´e modelov´an´ı, zaloˇzen´ y na Petriho s´ıt´ıch (PNtalk). Nejprve uvedeme k´od simuluj´ıc´ıho modelu v jazyce SIMULA, pˇrevzat´ y z [Skl97].
8.2
Model s vnoˇ renou simulac´ı v jazyce SIMULA [Skl97]
Model v jazyce SIMULA vyuˇz´ıv´ a toho, ˇze tˇr´ıda Simulation definuje simulaˇcn´ı ˇcas. Kaˇzd´ a instance t´eto tˇr´ıdy (nebo jej´ı podtˇr´ıdy) tedy definuje samostatn´ y svˇet s vlastn´ım ˇcasem. Metoda Hold() zp˚ usob´ı ˇcek´an´ı v simulaˇcn´ım ˇcase pˇr´ısluˇsn´e instance tˇr´ıdy Simulation. SIMULA umoˇzn ˇuje definovat bloky (Begin...End) dˇed´ıc´ı od existuj´ıc´ıch tˇr´ıd. Napˇr´ıklad konstrukce Simulation Begin...End definuje blok, dˇed´ıc´ı vlastnosti definovan´e tˇr´ıdou Simulation. Pˇr´ısluˇsn´ y anonymn´ı objekt (instance nepojenovan´e tˇr´ıdy, odpov´ıdaj´ıc´ı bloku), se vytvoˇr´ı (inicializuje) v okamˇziku, kdy m´ a doj´ıt k zah´ajen´ı vyhodnocov´an´ı bloku. Vnoˇrov´an´ı simulac´ı v jazyce SIMULA je tedy moˇzn´e velmi pˇr´ımoˇcaˇre definovat vnoˇren´ım blok˚ u dˇed´ıc´ıch od tˇr´ıdy Simulation.1 Aby si ˇcten´aˇr uˇcinil dokonalou pˇredstavu, n´asleduje kompletn´ı k´od simulaˇcn´ıho modelu s vnoˇrenou simulac´ı, pˇredvzat´ y z [Skl97]. ! NESTED Simulation using the Simula ’ s class SIMULATION ; ! ; ! The example i s a model of a bank. Customers are f i r s t ; ! served by tellers , then by cashiers . ; ! The input rate changes in three periods : there i s a busy ; ! period , then an idle period and again a busy one . ; ! For each period the repeated inner simulation experiment ; ! simulates the f i r s t queue for the particular input rate ; ! and for various numbers of servers . Then i t shows the ; ! results (average time spent at the f i r s t server ) and ; ! prompts the user for the number of t e l l e r s and the number; ! of cashiers . Tellers always finish a service that has ; ! already started . The simulation should find the ; ! time customers spend in the bank (average and maximum) ; ! for various numbers of clerks in the three periods . ; ! ; Simulation Begin
! Global variables : ;
1 V ostatn´ıch tˇr´ıdnˇe zaloˇzen´ ych objektovˇe orientovan´ ych jazyc´ıch, kter´e neumoˇzn ˇuj´ı blok˚ um dˇedit (coˇz je drtiv´ a vˇetˇsina programovac´ıch jazyk˚ u), je tˇreba pro vnoˇren´e simulace explicitnˇe pˇr´ısluˇsnou instanci tˇr´ıdy Simulation (nebo jej´ıho ekvivalentu, pokud je v dan´em prostˇred´ı k dispozici) vytvoˇrit. Princip ovˇsem z˚ ust´ av´ a zachov´ an.
74
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU Integer Period , Trial ; ! Real Array MinInt,MaxInt(1:3); ! Real Array Duration(1:3); ! Ref(Head) Queue1,Queue2; ! Integer MaxClerks, Tellers , Cashiers ; Integer BusyTellers , BusyCashiers ; ! Real S1Mean, S1Std, S2Mean, S2Std ; ! Integer SeedG, SeedS1, SeedS2; ! Long Real TotalTime, MaxTime; ! Integer CustomersOut; !
Period , Trial number; Min and Max intervals ; Duration of periods [min ] ; The two queues ; ! Total numbers; Numbers of working clerks ; Random normal servers ; Seeds of the random generators ; Variables for s t a t i s t i c s ; Number of served customers ;
Process Class Generator ; Begin While true do begin ! Interval between arrivals : ; Hold(Uniform(MinInt(Period ) ,MaxInt(Period ) ,SeedG) ) ; Activate New Customer(Time) ; End While; End of Generator ; Process Class Customer( Arrival ) ; Real Arrival ; Begin Ref(Customer) Next; Real Spent ; I f (not Queue1.Empty) or (BusyTellers >= Tellers ) then Wait(Queue1) ; ! Has to wait in Queue1; ! Service can start ; BusyTellers ← BusyTellers + 1; Hold(Normal(S1Mean, S1Std, SeedS1) ) ; ! This i s the t e l l e r service ; BusyTellers ← BusyTellers − 1; I f (not Queue1.Empty) and (BusyTellers < Tellers ) then begin Next :− Queue1. First ; Next.Out; ! First from Queue1 served ; Activate Next after Current ; End I f ; I f (not Queue2.Empty) or (BusyCashiers >= Cashiers) then Wait(Queue2) ; ! Has to wait in Queue2; ! Service can start ; BusyCashiers ← BusyCashiers + 1; Hold(Normal(S2Mean, S2Std, SeedS2) ) ; ! This i s the cashier service ; BusyCashiers ← BusyCashiers − 1; I f (not Queue2.Empty) and (BusyCashiers < Cashiers) then begin Next :− Queue2. First ; Next.Out; ! First from Queue2 served ; Activate Next after Current ; End I f ; CustomersOut ← CustomersOut + 1; Spent ← Time − Arrival ;
ˇ 8.2. MODEL S VNORENOU SIMULAC´I V JAZYCE SIMULA TotalTime ← TotalTime + Spent ; I f Spent > MaxTime then MaxTime ← Spent ; End of Customer; Procedure Report ; ! Experiment evaluation ; Begin OutText(” ∗∗∗ Report on external simulation ∗∗∗”); OutImage; OutInt(CustomersOut, 6 ) ; OutText(” customers ready at time ”) ; OutFix(Time,2 ,10); OutImage; OutText(”Average time in system : ”) ; OutFix(TotalTime/CustomersOut,2 ,10); OutImage; OutText(”Maximum time in system : ”) ; OutFix(MaxTime,2 ,10); OutImage; End of Report ; ! MAIN program body; SeedG ← 11; SeedS1 ← 13; SeedS2 ← 17; MinInt(1) ← 1; MaxInt(1) ← 4; MinInt(2) ← 2; MaxInt(2) ← 9; MinInt(3) ← 1; MaxInt(3) ← 3; Duration(1) ← 120; Duration(2) ← 240; Duration(3) ← 120; MaxClerks ← 6; S1Mean ← 6; S1Std ← 1; S2Mean ← 8; S2Std ← 2; Queue1 :− New Head; Queue2 :− New Head; Period ← 1; Activate New Generator ;
! Seeds of random variables ; ! Min and Max intervals ; ! Duration of periods ;
! Random normal servers ;
For Period←1 step 1 until 3 do begin Real Array TimeSpent(1:MaxClerks) ; OutText(” ∗∗∗ Results of internal simulation ∗∗∗ Period ”) ; OutInt(Period , 1 ) ; OutImage; OutText(” Tellers Average time spent ”) ; OutImage; For Trial←1 step 1 until MaxClerks do ! ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ; Simulation Begin ! Internal Global variables : ; Real TrialDuration ; ! Internal experiment [min ] ; Ref(Head) Queue; ! The queue ; Integer Servers ; ! Total number; Integer BusyServers ; ! Numbers of working clerks ; Integer TrialSeedG , TrialSeedS ; ! Seeds of the random generators ;
75
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
76 Long Real TotTime; Integer CustOut;
! Variables for s t a t i s t i c s ; ! Number of served customers ;
Process Class IGenerator ; Begin While true do begin Hold(Uniform(MinInt(Period ) ,MaxInt(Period ) ,TrialSeedG ) ) ; Activate New ICustomer(Time) ; ! Interval between arrivals : ; End While; End of IGenerator ; Process Class ICustomer( Arrival ) ; Real Arrival ; Begin Ref(ICustomer) Next; I f not Queue.Empty or (BusyServers >= Servers) then Wait(Queue) ; ! Has to wait in Queue; ! Service can start ; BusyServers ← BusyServers + 1; Hold(Normal(S1Mean, S1Std, TrialSeedS ) ) ; ! Teller ’ s service ; BusyServers ← BusyServers − 1; I f not Queue.Empty then begin Next :− Queue. First ; Next.Out; Activate Next after Current ; End I f ;
! First from Queue served ;
CustOut ← CustOut + 1; TotTime ← TotTime + Time − Arrival ; End of ICustomer ; ! Internal MAIN program body; TrialSeedG ← 7; ! Seeds for random variables ; TrialSeedS ← 23; Servers ← Trial ; TrialDuration ← 600; Queue :− New Head; Activate New IGenerator ; Hold(TrialDuration ) ; ! Internal experiment duration ; TimeSpent( Trial ) ← TotTime/CustOut; OutInt( Trial ,13); OutFix(TimeSpent( Trial ) ,3 ,23); OutImage; End of internal simulation ; ! ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ; OutText( ”Enter the number of t e l l e r s : ”) ; OutImage; Tellers ← InInt ; OutText( ”Enter the number of cashiers : ”) ; OutImage; Cashiers ← InInt ; Hold(Duration(Period ) ) ;
ˇ 8.3. MODEL S VNORENOU SIMULAC´I V JAZYCE PNTALK
77
Report ; OutText( ”Press Enter to Continue. ”) ; OutImage; InImage ; End For; End of program;
8.3
Model s vnoˇ renou simulac´ı specifikovan´ y objektovˇ e orientovn´ ymi Petriho s´ıtˇ emi v jazyce PNtalk
Nyn´ı uvedeme model t´ehoˇz syst´emu, specifikovan´ y objektovˇe orientovan´ ymi Petriho s´ıtˇemi (OOPN) v jazyce PNtalk. Vzhledem k pˇrev´ aˇznˇe vizu´ aln´ımu charakteru jazyka PNtalk je styl programov´an´ı v´ yraznˇe odliˇsn´ y od bˇeˇzn´eho textov´eho, avˇsak princip, pouˇzit´ yv pˇredchoz´ı ˇc´asti, z˚ ust´av´a zachov´an. Odliˇsnosti oproti modelu v jazyce SIMULA jsou dan´e pouˇzit´ ym jazykem a t´ım, ˇze model pro vnoˇrenou simulaci je smyslupln´e pouˇz´ıt jako nadtˇr´ıdu vnˇejˇs´ıho modelu. Model je specifikov´an dvˇema tˇr´ıdami, BankModel a Bank, pˇriˇcemˇz BankModel specifikuje zjednoduˇsen´ y model banky pro vnoˇrenou simulaci (tj. frontu a u ´ˇredn´ıky jednoho typu a Bank specifikuje model cel´eho syst´emu se dvˇena frontami a dvˇema typy u ´ˇredn´ık˚ u. Model BankModel je zjednoduˇsen´ım modelu Bank, proto je v´ yhodn´e tˇr´ıdu Bank specifikovat jako podtˇr´ıdu tˇr´ıdy BankModel. Vyuˇzije se zde v´ yhodnˇe moˇznosti dˇedˇen´ı struktury Petriho s´ıt´ı.
8.3.1
Tˇ r´ıda BankModel
Tˇr´ıda BankModel (viz obr. 8.3) modeluje banku jako syst´em hromadn´e obsluhy. Klienti jsou generov´ani stochasticky ˇcasovan´ ym pˇrechodem generator. Banka m´ a kapacitu 100 klient˚ u. Z´akazn´ıci jsou paralelnˇe obsluhov´ani u ´ˇredn´ıky, kteˇr´ı jsou modelov´ani znaˇckami v m´ıstˇe clerks (pˇrechod service m˚ uˇze b´ yt prov´adˇen n´asobnˇe, coˇz modeluje paraleln´ı obsluhu klient˚ u mnoˇzinou u ´ˇredn´ık˚ u). M´ısto stat slouˇz´ı ke sbˇeru statictick´ ych dat. Model je navrˇzen ˇ pro simulaci ve tˇrech reˇzimech: busy, idle a very busy. C´ıslo 1, 2 nebo 3 vm´ıstˇe period reprezentuje pˇr´ısluˇsn´ y reˇzim, kter´ y v praxi odpov´ıd´ a urˇcit´e ˇc´asti pracovn´ıho dne. Ten je do pˇr´ısluˇsn´eho m´ısta um´ıstˇen metodou makeExperimentForPeriod:clerks: (viz obr. 8.4). Tato metoda inicializuje model na z´akladˇe parametr˚ u (period a clerks). Pak nech´a bˇeˇzet simulaci po dobu 600 ˇcasov´ ych jednotek, coˇz je doba trv´ an´ı experimentu v ˇcase modelu (self hold: 600 ). Pot´e z m´ısta stat vyzvedne, zpracuje a odevzd´a (v m´ıstˇe return) v´ ysledky experimentu (pr˚ umˇernou dobu obsluhy jednoho klienta). Pˇredpokl´ ad´ a se, ˇze nad jednou instanc´ı modelu se provede jen jeden experiment (model, tak, jak ke specifikov´an, pro jednoduchost nepoˇc´ıt´ a s moˇznost´ı restart˚ u). Pro kaˇzd´ y experiment se poˇc´ıt´ a s vytvoˇren´ım nov´e instance tˇr´ıdy BankModel. S takto vytvoˇren´ ym modelem, kter´ y bude d´ale pouˇzit soufistikovanˇejˇs´ım zp˚ usobem, m˚ uˇzeme experimentovat interaktivn´ım vyhodnocen´ım v´ yrazu BankModel new makeExperimentForPeriod: 1 clerks: 10 v r´amci syst´emu Smalltalk (s knihovnou PNtalk). V´ ysledkem vyhodnocen´ı tohoto v´ yrazu je pr˚ umˇern´ y ˇcas str´aven´ y klientem v bance (pro zadan´e parametry).
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
78
BankModel is_a PN
p1
generator
#e
period <= 3
#e
self hold: (Uniform min: (#(1 2 1) at: period) max: (#(4 9 3) at: period)). arrival := self time.
#e
period
period
arrival p2 arrival
capacity 100‘#e
#e enter arrival FIFO
makeExperimentForPeriod: p clerks: c
arrival #e
service #e self hold: (Normal mean: 6 deviation: 1).
#e
clerks
arrival
arrival update_stat
(oldCustOut, oldTotalTime) (0, 0)
totalTime := oldTotalTime + self time - arrival. custOut := oldCustOut + 1.
stat (custOut, totalTime)
Obr´azek 8.3: Tˇr´ıda BankModel
ˇ 8.3. MODEL S VNORENOU SIMULAC´I V JAZYCE PNTALK
p
79
c
makeExperimentForPeriod: p clerks: c p
p11
c
p
period
c‘#e
clerks
#e
#e experiment self hold: 600.
#e
#e avgTime := totalTime / custOut.
(custOut, totalTime)
avgTime
return
(0, 0)
stat
Obr´azek 8.4: Metoda tˇr´ıdy BankModel, urˇcen´ a k proveden´ı simulaˇcn´ıho experimentu.
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
80
Bank is_a BankModel
p1
#e
generator period <= 3
#e
self hold: (Uniform min: (#(1 2 1) at: period) max: (#(4 9 3) at: period)). arrival := self time.
#e
arrival
1
period p2
period
arrival
capacity #e
100‘#e
enter arrival FIFO
service
arrival
#e 5‘#e
arrival
self hold: (Normal mean: 6 deviation: 1).
tellers
#e
FIFO2 #e
arrival
5‘#e
self hold: (Normal mean: 8 deviation: 2).
service2
update_stat #e
#e
arrival
arrival
cashiers
(oldCustOut, oldTotalTime, oldMaxTime)
custOut := oldCustOut + 1. spent := self time - arrival. totalTime := oldTotalTime + spent. maxTime := oldMaxTime max: spent.
(0, 0, 0)
stat
(custOut, totalTime, maxTime)
Obr´azek 8.5: Tˇr´ıda Bank – prvn´ı ˇc´ast s´ıtˇe objektu
ˇ 8.3. MODEL S VNORENOU SIMULAC´I V JAZYCE PNTALK
81
Bank is_a BankModel clerks
10
p5
maxClerks
#e
#e
#e
inner period <= 3
period period
result := self innerSimulationForPeriod: period maxClerks: maxClerks. cl1 := self consultManager: result. cl2 := maxClerks - clerks1. move1 := (old1 - cl1) max: 0. move2 := (old2 - cl2) max: 0.
(old1,old2)
period
nextPeriod
1 nextPeriod := period + 1.
nextPeriod
p4
period
period (cl1,cl2)
period
simulate
period
period
(5, 5)
self hold: #(120 240 120) at: period.
move1‘#e
p3
clerks12
move2‘#e endOfSim
#e
#e
5‘#e
period > 3
tellers
move1
move1to2 #e
#e #e
5‘#e
Transcript show: ’Customers: ’, custOut printString; cr; show: ’avg. time: ’, (totalTime/custOut) printString; cr; show: ’max. time: ’, maxTime printString; cr.
#e cashiers
move2to1
move2
(custOut, totalTime, maxTime)
stat (0, 0, 0)
Obr´azek 8.6: Tˇr´ıda Bank – druh´a ˇc´ast s´ıtˇe objektu, na prvn´ı ˇc´ast navazuje m´ısty period tellers, cashiers a stat
8.3.2
Class Bank
Jiˇz vytvoˇren´ a tˇr´ıda BankModel bude nyn´ı pouˇzita jako z´aklad pro dalˇs´ı specializaci v r´amci sofistikovanˇejˇs´ıho modelu banky. Nav´ıc uk´aˇzeme, jak instance BankModel m˚ uˇze b´ yt simulov´ana uvnitˇr jin´e simulace. Sofistikovanˇejˇs´ı model banky se specifikov´an tˇr´ıdou Bank, dˇed´ıc´ı od tˇr´ıdy BankModel. Tˇr´ıda Bank pˇrd´av´a druhou obsluˇznou linku (druhou sadu pˇrep´ aˇzek) a model ˇr´ızen´ı banky, kter´ y prov´ad´ı rozhodov´an´ı o pˇriˇrazov´an˚ uu ´ˇredn´ık˚ u k jednotliv´ ym typ˚ um pˇrep´ aˇzek na z´akladˇe v´ ysledk˚ u simulace modelu BankModel. S´ıt’ objektu, definovan´ a tˇr´ıdou Bank je zobrazena na dvou obr´ azc´ıch. Obr´azek 8.5 zobrazuje pr˚ uchod klient˚ u bankou. Zdˇedˇen´e ˇc´asti s´ıtˇe objektu, kter´e z˚ ust´avaj´ı beze zmˇeny, jsou zobrazeny ˇsedˇe. Obr´azek 8.6 zobrazuje mechanismus rozhodov´an´ı a pˇremist’ov´an´ı u ´ˇredn´ık˚ u mezi pˇrep´ aˇzkami prvn´ıho a druh´eho typu na z´akladˇe v´ ysledk˚ u simulace banky pro tˇri f´aze dne (m´ısto period). Vnoˇren´ y model je simulov´an pˇrechodem inner pro aktu´aln´a f´azi. Tato ˇcinnost je prov´adˇena opakovanˇe (pro f´azi 1, 2 a 3), pak simulace konˇc´ı – viz cyklus .
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
82
p
c
innerSimulationForPeriod: p clerks: c c nestedExperiment
c
suspendTime c
c>0 b := BankModel newIn: Scheduler new. cc := c - 1.
self suspendTime.
cc p
p11
c
(c,b) p12
p15
(c,b)
makeExperiment
c
result := b makeExperimentForPeriod: p clerks: c.
finish results size = c
(c,result)
self activateTime.
p13 (c,result)
finishExperiment
results := oldResults add: (Array with: c with: result).
oldResults
results results results
results
results := OrderedCollection new.
p14 return
Obr´azek 8.7: Metoda tˇr´ıdy Bank, urˇcen´ a k proveden´ı vnoˇren´e simulace Po kaˇzd´e vnoˇren´e simulaci probˇehne rozhodov´an´ı. Rozhodnt´ı o pˇrem´ıstˇen´ı u ´ˇredn´ık˚ u je realizovano dialogem s uˇzivatelem (jsou mu pˇritom pˇredloˇzeny v´ ysledky simulace). To je specifikov´ano metodou consultManager. Doporuˇcen´ a relokace u ´ˇredn´ık˚ u je specifikov´ana obsahem m´ıst move1 a move2. Pˇrechody move2to1 a move1to2 realizuj´ı relokaci.
8.3.3
Vnoˇ ren´ a simulace, interakce ˇ casov´ ych os
Vnoˇren´ a simulace (viz obr. 8.6, pˇrechod inner ) je vˇzdy startov´ana se dvˇema parametry, prvn´ım je f´aze dne (period p), druh´ ym je poˇcet dostupn´ ych u ´ˇredn´ık˚ u (clerks c). Obr´azek 8.7 ukazuje metodu tˇr´ıdy Bank, kter´a prov´ad´ı vnoˇren´e simulace simulaci a sb´ır´ a data. Vnoˇren´ a simulace je prov´adˇena pro vˇsechny moˇzn´e poˇcty u ´ˇredn´ık˚ u, zaˇc´ın´ a se poˇctem c a v kaˇzd´em kroku se c dekrementuje (viz obr. 8.6. Vnoˇren´ a simulace i rozhodnut´ı o poˇctu u ´ˇredn´ık˚ u u obou typ˚ u pˇrep´ aˇzek probˇehne z hlediska ˇcasu modelu okamˇzitˇe. V obou pˇr´ıpadech jde o interakci r˚ uzn´ ych ˇcasov´ ych os. V prvn´ım pˇr´ıpadˇe jde o ˇcas vnoˇren´e simulace, v druh´em pˇr´ıpadˇe jde o re´aln´ y ˇcas, ve kter´em probˇehne dialog. Z hlediska ˇcasu hlavn´ıho modelu trvaj´ı obˇe operace nulovou dobu. Sku-
ˇ 8.3. MODEL S VNORENOU SIMULAC´I V JAZYCE PNTALK
83
teˇcn´e trv´ an´ı vnoˇren´e simulace v modelov´em ˇcase hlavn´ıho modelu je realizov´ano zpoˇzdˇen´ım v cyklu, prov´adˇen´ıc´ım jednotliv´e simulace (viz obr. 8.6, pˇrechod simulate). Vzhledem k tomu, ˇze OOPN/PNtalk je paraleln´ı jazyk, spuˇstˇen´ı vnoˇren´e simulace i dialog s uˇzivatelem jsou realizov´any jako procesy, kter´e bˇeˇz´ı paralelnˇe s ostatn´ımi aktivitami v modelu. V obou pˇr´ıpadech ale nen´ı zn´ ama doba ukonˇcen´ı, takˇze nelze ud´alost ukonˇcen´ı napl´anovat. Jelikoˇz chceme, aby vˇse probˇehlo s nulov´ ym zpoˇzdˇen´ım, ˇreˇsen´ım je pozastaven´ı toku ˇcasu hlavn´ıho modelu do okamˇziku ukonˇcen´ı vnoˇren´e simulace nebo dialogu s uˇzivatelem. Pro tyto u ´ˇcely existuj´ı operace suspendTime a activateTime. Je li ˇcas pozastaven, pl´ anovaˇc dovol´ı prov´adˇet pouze ud´alosti pl´ anovan´e na aktu´aln´ı ˇcas modelu. Po opˇetovn´e aktivaci se mohou uplatnit i dalˇs´ı pl´ anovan´e ud´alosti a ˇcas modelu se m˚ uˇze posunout, nen´ı-li na aktu´aln´ı ˇcas jiˇz nic napl´anov´ano. Tyto operace jsou pouˇzity v metod´ach consultManager (viz obr. 8.8) a innerSimulationForPeriod:clerks: (viz obr. 8.7) result consultManager: result
result consult self suspendTime. tellers := GUI consultResult: result. self activateTime.
tellers
return
Obr´azek 8.8: Metoda tˇr´ıdy Bank, urˇcen´ a k dialogu s uˇzivatelem Pˇrechod nestedExperiment (viz obr. 8.7) vytvoˇr´ı c vnoˇren´ ych simulac´ı modelu BankModel. V´ yraz BankModel newIn: Scheduler new zajist´ı, ˇze kaˇzd´ a vnoˇren´ a simulace je provedena v nov´em pl´ anovaˇci, tj. s nez´ avisl´ ym ˇcasem modelu. Reference na simulaci (viz promˇenn´ a b v obr. 8.7) je pak pouˇzita k proveden´ı simulaˇcn´ıho experimentu pˇrechodem makeExperiment. Pˇrechod finishExperimet posb´ ar´ a v´ ysledky vˇsech simulac´ı. Cel´ y tento proces je odstartov´an pˇrechodem suspendTime a ukonˇcen pˇrechodem finish.
8.3.4
Simulace
Simulace se spust´ı vyhodnocen´ım v´ yrazu Bank new. Postupnˇe probˇehnou tˇri f´aze, pˇriˇcemˇz v kaˇzd´e z nich jsou provedeny vnoˇren´e simulace pro r˚ uzn´e rozdˇelen´ı u ´ˇredn´ık˚ u a jejich v´ ysledky jsou pˇredloˇzeny uˇzivateli i interaktivn´ımu v´ ybˇery nejlepˇs´ı varianty (obr. 8.9). Tabulka 8.1 zobrazuje simulaˇcn´ı v´ ysledky vnoˇren´ ych simulac´ı pro f´aze busy, idle a very busy a pro poˇcty u ´ˇredn´ık˚ u od 1 do 10. Tuˇcnˇe jsou vyznaˇceny vybran´e varianty. Celkov´e v´ ysledky jsou v tabulce 8.2.
´ KAPITOLA 8. SIMULACE SIMULUJ´IC´IHO SYSTEMU
84
Obr´azek 8.9: Simulace. busy idle very busy
1 28.65 15.65 22.59
2 14.81 5.62 15.01
3 6.14 5.85 7.22
4 6.18 5.85 5.89
5 5.74 5.51 6.13
6 5.88 5.85 6.10
7 5.63 6.10 5.90
8 6.18 6.02 5.65
9 6.32 6.32 6.18
10 6.12 5.56 6.12
Tabulka 8.1: V´ ysledky vnoˇren´ ych simulac´ı.
main simulation loop
number of customers 135
avg. time 14.74
max. time 32.43
Tabulka 8.2: V´ ysledky simulace.
8.4
Z´ avˇ er
Prezentovan´ y pˇr´ıklad ve zjednoduˇsen´e formˇe naznaˇcil probematiku simulace simuluj´ıc´ıch syst´em˚ u. V re´aln´ ych situac´ıch je tˇreba oproti uveden´emu pˇr´ıkladu ˇreˇsit komplikovanˇejˇs´ı parametrizaci, pˇr´ıpadnˇe vytvoˇren´ı nov´eho modelu pro (vnoˇrenou) simulaci na z´akladˇe aktu´alnˇe dostupn´ ych dat. Zat´ımco ˇreˇsen´ı v jazyce SIMULA umoˇzuje pouze parametrizaci pˇredem vytvoˇren´ ych model˚ u, PNtalk (pˇr´ıpadnˇe SmallDEVS) umoˇzn ˇuje dynamickou konstrukci vnoˇren´ ych model˚ u na z´akladˇe v´ ysledk˚ u introspekce hlavn´ıho modelu.
Kapitola 9
Pˇ r´ıpadov´ a studie: Prostˇ red´ı pro v´ yvoj multiagentn´ıch syst´ em˚ u V t´eto kapitole bude pˇredstaveno prostˇred´ı pro tvorbu multiagentn´ıch syst´em˚ u na b´azi objektovˇe orientovan´ ych Petriho s´ıt´ı. Jde o demonstraci moˇznosti programovat agenty form´ aln´ımi modely s moˇznost´ı jejich dynamick´e adaptace za ˇzivota syst´emu. Tento pˇr´ıstup je podrobnˇeji pops´ an v publikac´ıch [?] a v disertaˇcn´ı pr´aci [Maz08].
9.1
Multiagentn´ı syst´ emy
Multiagentn´ım syst´em je syst´em, ve kter´em vz´ ajemnˇe interaguj´ı agenti. Agenti [Woo02] jsou autonomn´ı entity, schopn´e dlouhodobˇe plnit c´ıle zadan´e uˇzivatelem bez jeho dohledu v dan´em prostˇred´ı. Interakce agent˚ u pˇredstavuje komplexn´ı soci´ aln´ı aktivity, jako kooperace, soupeˇren´ı, vyjedn´ av´an´ı, apod. Jako pˇr´ıklady aplikac´ı multiagent´ıch syst´em˚ u lze uv´est komplexn´ı softwarov´e syst´emy, kde jednotliv´e komponenty jsou natolik nez´ avisl´e a sloˇzit´e, ˇze z hlediska n´avrhu je efektivn´ı povaˇzovat je za zcela samostatn´e jednotky, kter´e spolu komunikuj´ı ve velmi mal´e m´ıˇre pomoc´ı vysoko´ urovˇ nov´eho jazyka, napˇr´ıklad jen v pˇr´ıpadˇe nestandardn´ıch situac´ı [SBD+ 00]. Dalˇs´ımi oblastmi jsou t´ ymov´a spolupr´ace robot˚ u (napˇr. robotick´ y fotbal [Kit98]), telekomunikaˇcn´ı aplikace (mobiln´ı agenti, migruj´ıc´ı je zdroj˚ um dat, coˇz vede k minimalizaci zat´ıˇzen´ı komunikaˇcn´ı infrastruktury) [AM04], rekonfigurovateln´e a adaptivn´ı softwarov´e syst´emy, zahrnuj´ıc´ı zak´ azkovou v´ yrobu [Kou01], ˇr´ıd´ıc´ı syst´emy letiˇstˇe [GR96]), distribuovan´e aplikace pro z´ısk´ avav´ı znalost´ı [KHS97], senzorov´e s´ıtˇe [LTO03], s´emantick´ y web a vyhled´ av´an´ı informac´ı [E. 03], simulace socioekonomick´ ych proces˚ u [Mos01] apod. Velk´a pozornost je vˇenov´ana nasazov´an´ı multiagentn´ıch aplikac´ı v pr˚ umyslu, s ˇc´ımˇz u ´zce souvis´ı standardizace (o tu se star´ a organizace FIPA [FIP01]). Souˇcasnˇe vˇsak st´ale pokraˇcuje v´ yzkum vhodn´ ych vnitˇrn´ıch model˚ u agenta – a to jak v teoretick´e, tak v praktick´e (implementaˇcn´ı) rovinˇe. Vyuˇ zit´ı dynamick´ ych model˚ u Existuj´ı tˇri hlavn´ı d˚ uvody pro aplikaci dynamick´ ych model˚ u v oblasti inteligentn´ıch (agentn´ıch) syst´em˚ u: • Bˇehem n´avrhu a v´ yvoje inteligentn´ıho syst´emu je tˇreba se syst´emem nebo jeho prototypem pr˚ ubˇeˇznˇe experimentovat a dovyv´ıjet ho za bˇehu. Struktura modelu (napˇr.
ˇ ´I PRO VYVOJ ´ ´ U ˚ KAPITOLA 9. PROSTRED MULTIAGENTN´ICH SYSTEM
86
fragmenty pl´ an˚ u deliberativn´ıho agenta) jsou interaktivnˇe a inkrement´alnˇe vyv´ıjeny bˇehem existence syst´emu. • Syst´em se vyv´ıj´ı vlastn´ımi prostˇredky s´ am. Na z´akladˇe mˇen´ıc´ıch se vnˇejˇs´ıch podm´ınek prov´ad´ı pr˚ ubˇeˇznˇe optimalizaci vlastn´ı struktury s ohledem na aktu´aln´ı c´ıle. • V pˇr´ıpadˇe multiagentn´ıch syst´em˚ u je tˇreba poˇc´ıtat s dynamick´ ym vytv´aˇren´ım, migrac´ı a ruˇsen´ım agent˚ u. Inici´atorem manipulace m˚ uˇze b´ yt jak agent, tak uˇzivatel nebo v´ yvoj´aˇr. Agentn´ı platforma (operaˇcn´ı syst´em) mus´ı takovouto manipulaci s agenty umoˇznit. V n´asleduj´ıc´ım textu bude struˇcnˇe naznaˇcena realizace agentn´ıho syst´emu prostˇredky Objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN). V´ıce detail˚ u lze naj´ıt v [Maz08].
9.2
Aplikace v OOPN a DEVS v multiagentn´ıch syst´ emech
Pˇredmˇetem naˇseho z´ajmu jsou deliberativn´ı agenti, zaloˇzen´ı na Beliefs-Desires-Intentions (BDI) architektuˇre [Bra87]. Takov´ı agenti pracuj´ı s vnitˇrnim modelem svˇeta (beliefs), c´ıli (desires) a z´amˇery (intentions). Z´amˇery jsou vytv´aˇreny v podobˇe pl´ an˚ u, kter´e doˇcasnˇe ˇr´ıd´ı ˇcinnost agenta a jsou dynamicky vytv´aˇreny v souladu s aktu´aln´ımi c´ıli na z´akladˇe nˇekter´ ych vstupn´ıch ud´alost´ı. Koncept multiagent´ıho syst´ emu v prostˇ red´ı PNtalk/SmallDEVS Vzhledem k tomu, ˇze agentn´ı syst´emy jsou ve sv´e podstatˇe syst´emy paraleln´ı a distribuovan´e, jev´ı se smyslupln´ ym pouˇz´ıt pro jejich specifikaci Petriho s´ıtˇe. Aplikac´ı Petriho s´ıt´ı v n´avrhu agentn´ıch syst´em˚ u r˚ uzn´ ych typ˚ u se zab´ yvalo nˇekolik autor˚ u, jako jsou [MW97], [WH02], a [YC06]. Tyto pˇr´ıstupy vesmˇe modeluj´ı agenty barven´ ymi Petriho s´ıtˇemi, resp. s´ıtˇemi s objektov´ ym strukturov´an´ım, ale bez dynamick´e instanciace. V r´amci n´ami zvolen´e architektury agenta (BDI) jsou Petriho s´ıtˇe pouˇzity pˇredevˇs´ım pro reprezentaci pl´ an˚ u. Vzhledem k tomu, ˇze se zde na konceptu´aln´ı u ´rovni pracuje s dynamicky instanciovateln´ ymi Petriho s´ıtˇemi, jev´ı se smyslupln´ ym pouˇz´ıt pro specifikaci agenta formalismus OOPN, resp. jazyk PNtalk [Jan95] [MVT97] [MVR+ 06], kter´ y je na formalismu OOPN zaloˇzen. Kromˇe samotn´ ych agent˚ u je formalismem OOPN (v jazyce PNtalk) moˇzn´e specifikovat i agentn´ı platformu (agentn´ı operaˇcn´ı syst´em), vytv´aˇrej´ıc´ı potˇrebnou abstrakci okoln´ı reality a poskytuj´ıc´ı prostˇred´ı pro existenci agent˚ u. Takto navrˇzen´ y agentn´ı syst´em vyuˇz´ıv´ a infrastrukturu, poskytovanou prostˇred´ım SmallDEVS [JK06]. Jde zejm´ena o mechanismus ˇr´ızen´ı simulac´ı a vazbu na extern´ı realitu. V naˇsem pˇr´ıpadˇe pˇredpokl´ ad´ ame aplikaci v oblasti mal´e mobiln´ı robotiky. Vazba na re´aln´e okol´ı agent˚ u je v tomto pˇr´ıpadˇe implementov´ana jednotn´ ym rozhran´ım, zpˇr´ıstupˇ nuj´ıc´ım jak re´aln´e, tak simulovan´e robotick´e platformy. Pro simulaci robot˚ u v simulovan´em prostˇred´ı je pouˇzit extern´ı robotick´ y simul´ ator. Agentn´ı architektura Architektura syst´emu vych´az´ı z existuj´ıc´ıch architektur BDI agent˚ u, jako je PRS [GL87] a jeho n´asledn´ıci dMars [dLG+ 04], 3APL [DdBDM03], Jadex [PBL03], AgentSpeak [Rao96] and [BWH07]. Nejv´ıce je inspirov´ana syst´emy dMars [dLG+ 04] a Jason [BWH07]. Origin´aln´ım pˇr´ınosem je (1) form´ aln´ı specifikace cel´eho agentn´ıho syst´emu (jeho obecn´ ych i aplikaˇcnˇe-specifick´ ych souˇc´ast´ı) objektovˇe orientovan´ ymi
´ 9.2. APLIKACE V OOPN A DEVS V MULTIAGENTN´ICH SYSTEMECH
87
Petriho s´ıtˇemi a (2) otevˇrenost, umoˇzn ˇuj´ıc´ı experimentovat jak s variantn´ımi implementacemi agent˚ u, tak i s modifikacemi cel´e agentn´ı architektury. Na obr. 9.1 jsou zn´ azornˇeny nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy, kter´ ymi je implementov´ano prostˇred´ı PNagent. Z diagramu tˇr´ıd je patrn´e, ˇze multiagentn´ı syst´em syst´em (MAS) obsahuje komunikuj´ıc´ı agenty (CommunicatingAgent), kteˇr´ı si mohou prostˇrednitv´ım agentn´ı platformy (Platform) pos´ılat zpr´ avy (ACLMessage). Kaˇzd´ y agent obsahuje mnoˇzinu pl´ an˚ u (PlanTemplate). Veˇsker´e zmˇeny stavu syst´emu jsou d˚ usledkem ud´alost´ı (Event). Ud´ alosti pro agenta generuje platforma. Kaˇzd´ y pl´ an m´ a pˇriˇrazeny vzory spouˇstˇec´ıch ud´alost´ı, pˇr´ıpadnˇe vzory ud´alost´ı, kter´e pl´ an suspenduj´ı, obnov´ı prov´ adˇen´ı, zp˚ usob´ı selh´ an´ı, nebo u ´spˇeˇsn´e dokonˇcen´ı. Zvl´aˇstn´ım typem ud´alosti je c´ıl (Goal). C´ıle jsou, na rozd´ıl od bˇeˇzn´ ych ud´alost´ı, perzistentn´ı (z˚ ustavaj´ı v platnosti, dokud nejsou splnˇeny, nebo dokud se nestanou neaktu´ aln´ımi). Instance pl´ an˚ u (PlanInstance) jsou souˇc´ast´ı z´amˇer˚ u (Intention). Na z´akladˇe ud´alosti nebo vzniku c´ıle se instanciuje odpov´ıdaj´ıc´ı pl´ an a vytvoˇr´ı se z´amˇer. Z´amˇer tak´e obsahuje pˇr´ıpadn´e instance podpl´ an˚ u. Obr´azek 9.2 obsahuje schematick´e zn´ azornˇen´ı j´adra agenta, kter´e interpretuje ud´alosti. V r´amci v´ yˇse uveden´eho prostˇred´ı mus´ı aplikaˇcn´ı program´ator specifikovat (1) b´azi pˇredstav (model svˇeta, beliefs), (2) metody tˇr´ıdy agenta, reprezentuj´ıc´ı agentovy schopnosti, (3) extern´ı ud´alosti, reprezentuj´ıc´ı zmˇeny v prostˇred´ı, (4) aplikaˇcnˇe specifick´e pl´ any.
Obr´azek 9.1: Zjednoduˇsen´ y diagram tˇr´ıd syst´emu PNagent, zobrazuj´ıc´ı nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy a jejich vztahy.
Model svˇ eta (beliefs, b´ aze pˇ redstav) Tˇr´ıda agenta mus´ı vˇzdy specifikovat model svˇeta. Zp˚ usob modelov´an´ı lze demonstrovat na typick´em uk´azkov´em pˇr´ıkladu pro multiagentn´ı syst´emy, nazvan´em Cleaner World. Jde 2D prostˇred´ı maticov´eho typu, obsahuj´ıc´ı odpad, agenty a popelnice. Pozice odpadu, popelnic a agent˚ u, stejnˇe jako aktu´aln´ı stav agenta, m˚ uˇze b´ yt vyj´ adˇren napˇr. v Prologu takto: wastePosition(5,6). wastePosition(4,4). binPosition(2,3).
88
ˇ ´I PRO VYVOJ ´ ´ U ˚ KAPITOLA 9. PROSTRED MULTIAGENTN´ICH SYSTEM
Obr´azek 9.2: Schematick´e zn´ azornˇen´ı struktury interpretu syst´emu PNagent.
agentPosition(4,5). carryingWaste.
Obr´azek 9.3 ukazuje, jak lze tent´ yˇz model vyj´adˇrit prostˇredky OOPN. Fakta jsou modelov´ana znaˇckami v m´ıstech. Synchronn´ı port canDropWaste a negativn´ı predik´ at notCarryingWaste slouˇz´ı k testov´an´ı stavu svˇeta, resp. ke zjiˇstˇen´ı, zda stav svˇeta dovoluje prov´est nˇejakou operaci.
Obr´azek 9.3: Agentn´ı prostˇred´ı Cleaner World a jeho reprezentace v jazyce PNtalk.
Z´ amˇ ery, pl´ any Z´amˇery obsahuj´ı instance pl´ an˚ u. Pl´ any jsou pˇredem pˇripraveny aplikaˇcn´ım program´ atorem. Tato agentn´ı architektura nepoˇc´ıt´ a s vytv´aˇren´ım pl´ an˚ u od poˇc´atˇcn´ıch princip˚ u, jako napˇr. STRIPS, ale aktivuje pˇredem pˇripraven´e d´ılˇc´ı pl´ any podle aktu´aln´ı situace. Pl´ any ale mohou b´ yt specifikov´any jen ˇc´asteˇcnˇe a k jejich dospecifikov´an´ı m˚ uˇze doj´ıt aˇz za bˇehu, pˇri instaniaci. Pl´ an je specifikov´an Petriho s´ıt´ı, kter´a vˇzdy obsahuje m´ısta start, success a failure. Dalˇs´ı m´ısta a pˇrechody specifikuj´ı kauzalitu jednotliv´ ych operac´ı a stav prov´adˇen´ı pl´ anu. Na obr´ azku 9.4 je pˇr´ıklad instance pl´ anu. Prov´adˇen´ı pˇrechod˚ u, specifikuj´ıc´ıch jednotliv´e kroky prov´adˇen´ı pl´ anu, je omezeno str´aˇz´ı self step: myAgent. Odpov´ıdaj´ıc´ı synchronn´ı port je provediteln´ y, je-li pl´ an aktivn´ı a interpret pl´ anu je pˇripraven k proveden´ı kroku. Dalˇs´ı stavy prov´adˇen´ı pl´ anu (kromˇe #active) jsou #ready (pˇripraven k aktivaci), #suspended (pozastaven), #succeeded (ukonˇcen u ´spˇeˇsnˇe), #failed (ukonˇcen ne´ uspˇeˇsnˇe). Pl´ any maj´ı pˇridˇeleny priority, kter´e se uplatn´ı pˇri ˇreˇsen´ı konflikt˚ u.
´ 9.2. APLIKACE V OOPN A DEVS V MULTIAGENTN´ICH SYSTEMECH
89
Obr´azek 9.4: Pˇr´ıklad pl´ anu specifikovan´eho Petriho s´ıt´ı v prostˇred´ı PNagent.
Interpret Interpret je implementov´an tˇr´ıdou BDIAgent. J´adro interpretu je na obr´ azku 9.5. Tradiˇcn´ı cyklus interpretu BDI agenta – z´ıskej nov´e ud´alosti, vytvoˇr odpov´ıdaj´ıc´ı pl´ any, uprav strukturu z´amˇer˚ u, vyber jeden z´amˇer a proved’ jeden krok jeho aktu´aln´ıho ˇ ast zobrazen´a na obr´ pl´ anu – je zde rozdˇelen do dvou nez´ avisl´ ych ˇc´ast´ı. C´ azku 9.5 vpravo je zodpovˇedn´ a za zpracov´an´ı ud´alost´ı – ud´alosti jsou postupnˇe odeb´ır´ any z fronty ud´alost´ı, maj´ı moˇznost upravit agentovu b´azi znalost´ı a pot´e jsou paralelnˇe pˇred´ any metod´am, jeˇz maj´ı za u ´kol vytv´aˇren´ı nov´ ych instanc´ı pl´ an˚ u, resp. spr´ avu stavu existuj´ıc´ıch instanc´ı (tedy usp´av´an´ı, probouzen´ı atd.). Druh´a ˇc´ast, zachycen´ a na obr´ azku vlevo, se star´ a o interpretaci struktury z´amˇer˚ u. Interpret vykon´ av´a jeden z´amˇer krok po kroku tak dlouho, dokud je tento z´amˇer provediteln´ y. Pot´e vybere n´ahodnˇe jin´ y provediteln´ y z´ amˇer. Interpretace z´amˇer˚ u pˇredstavuje vlastn´ı funkˇcnost agenta – zde se v jednotliv´ ych kroc´ıch realizuj´ı agentovy pl´ any, tedy prov´adˇej´ı akce, kter´e ovlivˇ nuj´ı prostˇred´ı. Agentn´ı platforma Tˇr´ıda Platform definuje prostˇred´ı, v kter´em agenti existuj´ı. Poskytuje agent˚ um tˇri z´akladn´ı sluˇzby: (1) Spr´avu ˇzivotn´ıho cyklu – zejm´ena prostˇredky pro
ˇ ´I PRO VYVOJ ´ ´ U ˚ KAPITOLA 9. PROSTRED MULTIAGENTN´ICH SYSTEM
90
Obr´azek 9.5: Zpracov´an´ı ud´alost´ı a interpretace z´amˇer˚ u agenta.
vytv´aˇren´ı a odstraˇ nov´an´ı agent˚ u, pˇridˇelov´an´ı jednoznaˇcn´ ych identifik´ator˚ u (AID) apod., (2) sluˇzbu b´ıl´ ych str´anek (vyhled´av´an´ı agent˚ u podle jejich AID), a (3) pˇrenos zpr´ av mezi agenty. Jazyk zpr´ av odpov´ıd´ a podmnoˇzinˇe jazyka FIPA ACL [FIP01]. Niˇzˇs´ı vrstvu platformy, vˇcetnˇe vazby na re´aln´e okol´ı, obstar´ av´a prostˇred´ı SmallDEVS. Aplikace prostˇ red´ı PNagent v oblasti robotiky V´ yˇse popsan´e multiagentn´ı prostˇred´ı bylo experiment´alnˇe ovˇeˇreno v oblasti mal´e mobiln´ı robotiky. Agent je pouˇzit pro ˇr´ızen´ı robota. To znamen´a, ˇze m´ a za u ´kol zpracov´avat informace ze senzor˚ u robota a ovl´ adat jeho akˇcn´ı prvky. V´ yvoj ˇr´ıdic´ıho softwaru (agenta) prob´ıh´ a v prostˇred´ı PNtalk/SmallDEVS. Senzory a akˇcn´ı prvky robota jsou dostupn´e prostˇrednictv´ım speci´aln´ıho rozhran´ı na extern´ı realitu, kter´e je v prostˇred´ı SmallDEVS realizov´ano jako komponenta s DEVS rozhran´ım (viz obr. 9.7). Tato komponenta zpˇr´ıstupˇ nuje rozhran´ı na Player/Stage (viz obr. 9.6). Player [GVH03] je middleware pro robotiku (vyvinut´ y v Univ. Of Southern 1 California), poskytuj´ıc´ı jednotn´e rozhran´ı na senzory a aktu´atory fyzick´ ych i simulovan´ ych robot˚ u. Z hlediska aplikace jde o server, zpˇr´ıstupˇ nuj´ıc´ı senzory a aktu´atory v abstrahovan´e formˇe klientsk´ ym program˚ um, pˇriˇcemˇz klientsk´e programy implementuj´ı ˇr´ızen´ı robot˚ u. Player obsahuje ovladaˇce jak pro simulovan´e, tak pro re´aln´e senzory a aktu´atory robot˚ u. K simulaci chov´an´ı robot˚ u v 2D a 3D prostˇred´ı slouˇz´ı simul´ atory Stage a Gazebo [GVH03], s kter´ ymi Player spolupracuje. Pˇri experimentech byl pouˇzit jeden ze z´akladn´ıch 1
http://playerstage.sourceforge.net/
´ 9.2. APLIKACE V OOPN A DEVS V MULTIAGENTN´ICH SYSTEMECH
91
Obr´azek 9.6: Simul´ ator Stage
Obr´azek 9.7: Rozhran´ı na Player model˚ u robota implementovan´ ych simul´ atorem, ActiveMedia Pioneer P3-DX 3, vybaven´ y osmi sonary o rozsahu 45◦ s dosahem 2,5 m, rozm´ıstˇen´ ymi radi´alnˇe kolem robota, osmi n´arazn´ıky, kompasem a r´ adiem, umoˇzn ˇuj´ıc´ım zas´ıl´ an´ı zpr´ av ostatn´ım robot˚ um. Pˇr´ıkazy, kter´e je schopen robot vykonat (odpov´ıdaj´ı agentov´ ym schopnostem) jsou ˇctyˇri: robot se m˚ uˇze pohybovat vpˇred, zastavit, otoˇcit se o dan´ yu ´hel a zaslat zpr´ avu pomoc´ı r´adia. V takto vytvoˇren´em prostˇred´ı lze experimantovat s r˚ uzn´ ymi multirobotick´ ymi u ´lohami. Ovˇeˇren´ı praktick´e pouˇzitelnosti bylo provedeno na u ´loze formov´an´ı t´ ymu robot˚ u, jak byla definov´ana napˇr. v [HZ04]. V´ıce podrobnost´ı lze naj´ıt v [Maz08]. Od simulace k realitˇ e Pro realizaci uveden´e multirobotick´e u ´lohy byl pouˇzit extern´ı software, sest´avaj´ıc´ı ze serveru Player a simul´ atoru Stage. Pˇrechod od simulovan´ ych robot˚ u v simulovan´em prostˇred´ı k re´aln´ ym robot˚ um v re´ aln´em prostˇred´ı m˚ uˇze b´ yt proveden nˇekolika zp˚ usoby, pˇr´ıpadnˇe v nˇekolika f´az´ıch: 1. PNagent, PNtalk, SmallDEVS a Player bˇeˇz´ı na PC, Player komunikuje se senzory a akˇcn´ımi prvky robot˚ u r´ adiov´ ym spojen´ım. 2. PNagent, PNtalk a SmallDEVS bˇeˇz´ı na PC, Player bˇeˇz´ı na internetovˇe dostupn´em palubn´ım poˇc´ıtaˇci kaˇzd´eho robota a pˇr´ımo pˇristupuje k jeho senzor˚ um a akˇcn´ım prvk˚ um. 3. PNagent, PNtalk a SmallDEVS bˇeˇz´ı na nˇekolika PC (na kaˇzd´em bˇeˇz´ı ˇr´ızen´ı jednoho
ˇ ´I PRO VYVOJ ´ ´ U ˚ KAPITOLA 9. PROSTRED MULTIAGENTN´ICH SYSTEM
92
robota), Player bˇeˇz´ı na palubn´ım poˇc´ıtaˇci kaˇzd´eho robota a pˇr´ımo pˇristupuje k jeho senzor˚ um a akˇcn´ım prvk˚ um. 4. PNagent, PNtalk, SmallDEVS a Player bˇeˇz´ı na palubn´ım poˇc´ıtaˇci kaˇzd´eho robota. Ve vˇsech pˇr´ıpadech lze do prostˇred´ı PNagent/PNtalk/SmallDEVS za bˇehu pˇristupovat podle konfigurace bud’ lok´ alnˇe, nebo vzd´ alenˇe. Je tak moˇzn´e bˇehem experiment˚ u detailnˇe sledovat a pˇr´ıpadnˇe i interaktivnˇe modifikovat stav a strukturu agent˚ u, ˇr´ıd´ıc´ıch roboty.
Obr´azek 9.8: Konfigurace syst´emu pro multirobotickou u ´lohu.
9.3
Shrnut´ı
Kombinace formalism˚ u OOPN a DEVS je pro tuto aplikaci uˇziteˇcn´ a z nˇekolika d˚ uvod˚ u. Formalismus DEVS, resp. prostˇred´ı SmallDEVS, pˇrin´ aˇs´ı hierarchicky organizovan´e volnˇe v´azan´e komponenty, ud´alosti, snadnou manipulaci (plug’n’play), pˇr´ımou vazbu na teorii modelov´an´ı a simulace, operaˇcn´ı syst´em. Formalismus OOPN, resp. jazyk PNtalk, pˇrin´ aˇs´ı paralelismus, synchronizaci, objekty, vizu´aln´ı jazyk, pˇrirozenou reprezentaci pl´ an˚ u. Jak aplikaˇcnˇe specifick´a ˇc´ast agenta, tj. reprezentace svˇeta, d´ılˇc´ı pl´ any atd., tak i obecn´a architektura agenta jsou pops´ any pomoc´ı OOPN v jazyce PNtalk a interpretov´any v r´amci prostˇred´ı SmalDEVS. Tyto prostˇredky umoˇzn ˇuj´ı interaktivn´ı (i automatick´ y) evoluˇcn´ı v´ yvoj model˚ u. Je tedy moˇzn´ y inkrement´aln´ı v´ yvoj jak agentn´ı aplikace, tak i obecn´e agentn´ı architektury, a to za pouˇzit´ı stejn´ ych prostˇredk˚ u. Moˇznost snadn´e adaptace agentn´ı architektury podle aktu´aln´ıch poˇzadavk˚ u dan´e aplikace m˚ uˇze urychlit a zkvalitnit v´ yvoj agentn´ıho syst´emu. Kromˇe toho potenci´alnˇe umoˇzn ˇuje i automatickou evoluci agent˚ u i agentn´ı platformy.
Kapitola 10
Pˇ r´ıpadov´ a studie: Dynamick´ e modely v ˇ r´ızen´ı projekt˚ u V t´eto kapitole bude pˇredstaven koncept vyuˇzit´ı dynamick´ ych OOPN v ˇr´ızen´ı projekt˚ u, konkr´etnˇe v modelov´an´ı projektov´eho portfolia pro potˇreby rozvrhov´an´ı a monitorov´an´ı.
10.1
Z´ akladn´ı pojmy z oblasti ˇ r´ızen´ı projekt˚ u
Projekt Projekt [Anb05] je ˇcasovˇe ohraniˇcen´e u ´sil´ı smˇeˇruj´ıc´ı k vytvoˇren´ı unik´atn´ıho produktu nebo sluˇzby. ˇ ızen´ı projekt˚ ˇ ızen´ı projekt˚ R´ u R´ u [Sch05] je proces pl´ anov´an´ı, koordinov´an´ı a ˇr´ızen´ı u ´loh a zdroj˚ u pro dosaˇzen´ı definovan´eho c´ıle v dan´em ˇcase, s definovan´ ymi zdroji a s omezenou cenou. Problematika ˇr´ızen´ı projektu zahrnuje (1) pl´ anov´an´ı projektu, (2) organizaci projektu, (3) rozpoˇcet projektu, (4) odhad a kontrolu spotˇreby zdroj˚ u a ˇcasu, (5) ˇr´ızen´ı rizik projektu, (6) ˇr´ızen´ı zmˇen, (7) projektovou dokumentaci. ˇ ızen´ı projektov´ R´ eho portfolia Jde o ˇr´ızen´ı nikoliv jednoho projektu, ale skupiny aktu´aln´ıch i pl´ anovan´ ych projekt˚ u, aby se dos´ ahlo konkr´etn´ıch c´ıl˚ u. Smyslem ˇr´ızen´ı projektov´eho portfolia je optimalizace ˇcasu, n´aklad˚ u a zdroj˚ u, pˇresahuj´ıc´ı r´amec jednotliv´ ych projekt˚ u [GK03, Lee04]. Mnoˇzina aktu´aln´ıch a pl´ anovan´ ych projekt˚ u, tvoˇr´ıc´ı portfolio, se v pr˚ ubˇehu ˇcasu vyv´ıj´ı. Proces Proces je sekvence aktivit vedouc´ı k oˇcek´avan´emu v´ ysledku. K prov´adˇen´ı aktivit jsou vyuˇz´ıv´ any zdroje, aktivity transfromuj´ı vstupy na v´ ystupy. Aktivity a zdroje v r´amci projektu jsou obvykle ch´ap´ any jako procesy [Anb05]. S´ıt’ov´ y diagram projektu S´ıt’ov´ y diagram je grafov´a reprezentace uspoˇr´ad´ an´ı jednotliv´ ych aktivit, kter´e vedou k c´ıli projektu. S´ıt’ov´ y diagaram umoˇzn ˇuje specifikovat sekvence akc´ı, paraleln´ı vˇetve i kolize. Aktivity maj´ı pˇriˇrazenu dobu trv´ an´ı a je tedy moˇzn´e anaˇ lyzovat ˇcasov´e charakteristiky projektu (doba trv´ an´ı, kritick´a cesta). Casto pouˇz´ıvanou alternativou s´ıt’ov´eho siagramu je ˇcasovan´ a Petriho s´ıt’.
94
´ MODELY V R ˇ ´IZEN´I PROJEKTU ˚ KAPITOLA 10. DYNAMICKE
Pl´ anov´ an´ı Pl´ anov´an´ı je proces v´ ybˇeru a uspoˇr´ad´ an´ı aktivit, vedouc´ıch k dosaˇzen´ı c´ıle [Spi92]. Rozvrhov´ an´ı Rozvrhov´an´ı [Spi92, Pin02, Pin05] je alokace zdroj˚ u um´ıstˇen´ ych v ˇcasoprostoru za dan´ ych podm´ınek na aktivity tak, aby se splnila zadan´a krit´eria, napˇr´ıklad minimalizace celkov´e ceny dan´ ych zdroj˚ u. V´ ystupem procesu rozvrhov´an´ı je rozvrh. Jedn´ a se o datovou strukturu obsahuj´ıc´ı informace o pˇriˇrazen´ı aktivit zdroj˚ um v ˇcase. Statick´ e a dynamick´ e pl´ anov´ an´ı a rozvrhov´ an´ı Statick´e (off-line) pl´ anov´ an´ı a rozvrhov´ an´ı [Pin05, Koc02] pˇredpokl´ ad´ a, ˇze vˇsechny poˇzadavky (c´ıle) a vˇsechny parametry dostupn´ ych zdroj˚ u jsou dopˇredu zn´ amy a v budoucnu se nemˇen´ı. V praxi jsou takov´e situace vz´ acn´e. V pˇr´ıpadˇe projektov´eho portfolia se poˇc´ıt´ a s v´ yvojem c´ıl˚ u i zdroj˚ u v ˇcase. Bˇehem ˇreˇsen´ı (za bˇehu syst´emu) se objevuj´ı nov´e c´ıle a tedy vznikaj´ı nov´e projekty, jin´e projekty jsou v d˚ usledku zmˇeny c´ıl˚ u ruˇseny nebo jsou jim mˇenˇeny parametry. Struktura a parametry zdroj˚ u se tak´e s ˇcasem mˇen´ı. Dynamick´e (on-line) pl´ anov´ an´ı a rozvrhov´ an´ı [Koc02] pˇredstavuje proces tvorby rozvrhu za bˇehu syst´emu. Rozvrh je tedy tvoˇren inkrement´alnˇe pˇri zmˇenˇe aktu´alnˇe dostupn´ ych informac´ı. D˚ uleˇzit´ ym poˇzadavkem je dostateˇcn´ a rychlost on-line pl´ anov´an´ı a rozvrhov´an´ı. Monitorov´ an´ı Monitorov´an´ı projektu je sledov´an´ı v´ yznam´ ych ud´alost´ı v pr˚ ubˇehu ˇreˇsen´ı projektu a porovn´av´an´ı se simulac´ı projektu. Typicky jde o sledov´an´ı zaˇc´atk˚ u a konc˚ u jednotliv´ ych aktivit, pˇr´ıpadnˇe o ud´alosti, jako jsou nepl´anovan´e zmˇeny ve struktuˇre a parametrech zdroj˚ u. V pˇr´ıpadˇe jak´ekoli odchylky reality od simulace je tˇreba upravit model a okamˇzitˇe prov´est dynamick´e pl´ anov´an´ı a rozvrhov´an´ı, aby model (vˇcetnˇe rozvrhu zdroj˚ u) odpov´ıdal realitˇe a aby byly splnˇeny vˇsechny aktu´aln´ı poˇzadavky na syst´em.
10.2
Aplikace dynamick´ ych OOPN v modelov´ an´ı projektov´ eho portfolia pro potˇ reby rozvrhov´ an´ı a monitorov´ an´ı
V t´eto studii uk´aˇzeme, ˇze pro adekv´atn´ı modelov´an´ı projektov´eho portfolia na b´azi Petriho s´ıt´ı je tˇreba pouˇz´ıt (at’ uˇz pˇr´ımo, nebo jen na konceptu´aln´ı u ´rovni) dynamickou variantu Objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN), aby bylo moˇzn´e prov´adˇet jak klonov´an´ı a editaci pro potˇreby optimalizace a rozvrhov´an´ı, tak dynamickou modifikaci v pr˚ ubˇehu monitorov´an´ı podle mˇen´ıc´ıch se vnˇejˇs´ıch podm´ınek (a reflektovat tak zmˇeny ve struktuˇre zdroj˚ u, pˇrid´ av´an´ı nov´ ych pl´ an˚ u, zmˇeny pl´ an˚ u apod). Pro potˇreby ˇr´ızen´ı projektov´eho portfolia se pouˇz´ıv´ a ˇrada pˇr´ıstup˚ u, metod a modelovac´ıch formalism˚ u, mnoh´e z nich vyuˇz´ıvaj´ı modely na b´azi Petriho s´ıt´ı [GK03, AG04, HY03]. Vesmˇes jde o Petriho s´ıtˇe sice vysoko´ urovˇ nov´e, ale nestrukturovan´e. Vyuˇzit´ı moˇznosti strukturov´an´ı, at’ uˇz statick´eho, jako v pˇr´ıpadˇe hierarchick´ ych Petriho s´ıt´ı, tak dynamick´eho, jako v pˇr´ıpadˇe objektovˇe orientovan´ ych Petriho s´ıt´ı, se jev´ı jako moˇzn´e a pˇr´ınosn´e. Oˇcek´avanou v´ yhodou objektovˇe orientovan´ ych Petriho s´ıt´ı je adekv´atn´ı strukturov´an´ı modelu projektov´eho portfolia. Existuje ˇrada potenci´alnˇe pouˇziteln´ ych pˇr´ıstup˚ u, kombinuj´ıc´ıch Petriho s´ıtˇe a objekty, k nejpropracovanˇejˇs´ım (z hlediska souvisej´ıc´ı teorie a moˇznost´ı anal´ yzy a verifikace) patˇr´ı Reference nets [Val98], [Ren06]. V t´eto studii se ale zamˇeˇr´ıme na Objektovˇe orientovan´e
´ ´I PROJEKTOVEHO ´ 10.2. MODELOVAN PORTFOLIA
95
Petriho s´ıtˇe (OOPN) [Jan95, Jan98], vych´azej´ıc´ı d˚ uslednˇe z klasick´eho objektov´eho paradigmatu [GR89]. Hlavn´ım d˚ uvodem tohoto v´ ybˇeru je koncept dynamicky instanciovateln´ ych s´ıt´ı metod, kter´ y v konkurenˇcn´ıch pˇr´ıstupech chyb´ı a kter´ y je pro zam´ yˇslenou aplikaci kl´ıˇcov´ y. Dalˇs´ım d˚ uvodem je otevˇren´ a implementace simul´ atoru OOPN [JK04], kter´a je tak´e pro zam´ yˇslenou aplikaci nepostradateln´ a. Koncept modelov´ an´ı projektov´ eho protfolia Projektov´e portfolio lze modelovat pomoc´ı OOPN takto: • Projektov´e portfolio je modelov´ano jedn´ım objektem OOPN. Zdroje jsou modelov´any objekty, dostupn´ ymi jako znaˇcky v m´ıstech – znaˇcky nesou reference na objekty zdroj˚ u. Tyto odkazy na zdroje jsou distribuov´any do m´ıst s´ıtˇe objektu podle jejich rol´ı. • S´ıtˇe metod modeluj´ı jednotliv´e vzory pl´ an˚ u projekt˚ u. Jejich instance jsou dynamicky vytv´aˇreny a ruˇseny v okamˇziku startu, resp. ukonˇcen´ı projektu.Tyto pl´ any sd´ıl´ı pˇr´ıstup k m´ıst˚ um s´ıtˇe objektu, kde jsou k dispozici zdroje. Start projektu je technicky realizov´an zasl´ an´ım odpov´ıdaj´ıc´ı zpr´ avy objektu portfolia (s pˇr´ıpadn´ ymi parametry, upˇresˇ nuj´ıc´ımi pl´ an). V tom okamˇziku je vytvoˇrena nov´a instance s´ıtˇe metody (t.j. pl´ anu) a zaˇc´ın´ a bˇeˇzet. Model projektov´ eho portfolia Na obr. 10.1 je pˇr´ıklad modelu projektov´eho portfolia. Obsahuje tˇri r˚ uzn´e typy projekt˚ u, resp. tˇri typy pl´ an˚ u, modelovan´e metodami OOPN. Tyto pl´ any sd´ıl´ı tˇri typy (resp. role) zdroj˚ u. Typy zdroj˚ u (jejich role) jsou modelov´any m´ısty s´ıtˇe objektu portfolia. Pl´ any A a B jsou na obr. 10.1 zn´ azornˇeny bez zobrazen´ı jejich sktruktury, pl´ an C je uk´az´an i s jeho strukturou. Pˇrechody s´ıtˇe objektu portfolia obsahuj´ı v´ yrazy tvaru self projectA: x. Tyto pˇrechody jsou urˇceny k invokaci odpov´ıdaj´ıc´ıch metod zasl´ an´ım pˇr´ısluˇsn´ ych zpr´ av, tedy pro vytvoˇren´ı a nastartov´an´ı jednotliv´ ych konkr´etn´ıch projekt˚ u. Poznamenejme, ˇze jsou pˇr´ıpustn´e n´asobn´e invokace metod OOPN, kter´e se pak mohou pˇrekr´ yvat v ˇcase. Hierarchick´ a kompozice pl´ an˚ u Pl´ any projekt˚ u mohou b´ yt sloˇzeny z podpl´ an˚ u. K tomu lze pouˇz´ıt koncept invokaˇcn´ıho pˇrechodu, kter´ y zasl´ an´ım zpr´ avy self subplan vytvoˇr´ı novou instanci subpl´ anu a v okamˇziku ukonˇcen´ı jej´ıho prov´adˇen´ı pokraˇcuje um´ıstˇen´ım znaˇcek do v´ ystupn´ıch m´ıst. Zdroje a jejich role Obr´azek 10.1 neukazuje vˇsechny detaily – nejsou v nˇem prozat´ım uvaˇzov´any jednotliv´e zdroje. Pˇredpokl´ ad´ a se, ˇze zdroje jsou modelov´any znaˇckami v m´ıstech, kter´ a odpov´ıdaj´ı jejich rol´ım. Zdroje jsou instance tˇr´ıdy Resource (viz obr. 10.2). Vzhledem k tomu, ˇze znaˇcky v OOPN jsou reference na objekty, kaˇzd´ y zdroj m˚ uˇze m´ıt v takto koncipovan´em modelu potenci´alnˇe v´ıce neˇz jednu roli. Obr´azek 10.3 ukazuje situaci, kde je jeden zdroj (objekt tˇr´ıdy Resource), maj´ıc´ı dvˇe r˚ uzn´e role, sd´ılen dvˇema projekty. Kaˇzd´ a aktivita poˇzaduje zdroj urˇcit´eho typu (zdroj schopn´ y plnit urˇcitou roli) na urˇcitou dobu. Aktivita A1 projektu A poˇzaduje zdroj s rol´ı R1 na 10 ˇcasov´ ych jednotek, aktivita A2 projektu B poˇzaduje zdroj s rol´ı R2 na 5 ˇcasov´ ych jednotek. Poˇzadovab´ a doba trv´ an´ı aktivity je obvykle odhadnuta na z´akladˇe pˇredchoz´ıch zkuˇsenost´ı s podobn´ ymi
´ MODELY V R ˇ ´IZEN´I PROJEKTU ˚ KAPITOLA 10. DYNAMICKE
96
ProjectPortfolio is_a PN r1 x projectC: x
projectA: x r2
projectB: x
r3 y
y
x
a
self projectA: x y
x
b
self projectB: x
x
c
y
self projectC: x
Obr´azek 10.1: Model projektov´eho portfolia Resource is_a PN allocFor: a duration: d
.
d
.
allocated use
.
idle
d
.
self hold: d
return
Obr´azek 10.2: Zdroj a Resource allocFor: a duration: d d
projectA
allocated
.
use
d self hold: d
. . .
projectB
idle
return
A1 r allocFor: #A1 duration: 10 r use
A2 r
. R1
. R2
r
r allocFor: #A2 duration: 5 r use
Obr´azek 10.3: Konflikt dvou aktivit poˇzaduj´ıc´ıch jeden zdroj se dvˇemi rolemi
´ ´I PROJEKTOVEHO ´ 10.2. MODELOVAN PORTFOLIA
97
projekty.1 M´ısta R1 a R2 obsahuj´ı znaˇcku odkazuj´ıc´ı na tent´ yˇz objekt, modeluj´ıc´ı sd´ılen´ y zdroj. Kaˇzd´ a aktivita se nejprve snaˇz´ı zdroj alokovat. Nen´ı-li zdroj dostupn´ y, ˇcek´a se na jeho uvolnˇen´ı. To je specifikov´ano str´aˇz´ı kaˇzd´eho pˇrechodu, modeluj´ıc´ıho aktivitu. Podaˇr´ı-li se zdroj alokovat, je n´aslednˇe pouˇzit. Pouˇzit´ı zdroje je modelov´ano ˇcasovan´ ym pˇrechodem (viz metoda use v tˇr´ıdˇe Resource – zpoˇzdˇen´ı je realizov´ano zpr´ avou self hold: d ). SheduledResource is_a Resource allocFor: a duration: d self isScheduledFor: a time: (DateAndTime now) duration: d d allocated use
.
d
isScheduledFor: a time: t duration: d (a = sa) & (t >= st) & (t < (st+sd)) & (d <= sd)
. . idle .
(sa, st, sd) schedule
self hold: d
return
Obr´azek 10.4: Zdroj s rozvrhem. Rozvrhy zdroj˚ u Obr´azek 10.4 ukazuje zdroj s rozvrhem. Str´aˇz synchronn´ıho portu pro alokaci zdroje kontroluje, zda je poˇzadavek v souladu s rozvrhem. Rozvrh je uloˇzen v m´ıstˇe schedule jako mnoˇzina trojic (aktivita, ˇcas, trv´ an´ı) a je k dispozici na dotaz (vol´an´ım synchronn´ıho portu). Rozvrh pro kaˇzd´ y zdroj je vytvoˇren vhodn´ ym optimalizaˇcn´ım procesem mimo model a pot´e um´ıstˇen do m´ısta schedule. Model s doplnˇen´ ymi rozvrhy pro jednotliv´e zdroje je pak pouˇziteln´ y pro anal´ yzu, ovˇeˇren´ı spr´ avnosti modelu a pro monitorovn´an´ı. Schopnosti zdroj˚ u Pro kaˇzd´ y zdroj lze specifikovat jeho schopnost vykon´ avat urˇcit´e aktivity. Jde o m´ıru vhodnosti zdroje pro danou aktivitu. Tento u ´daj lze z´ıskat anal´ yzou dat z pˇredchoz´ıch projekt˚ u. Doba vykon´ av´an´ı aktivity je pak nepˇr´ımo umˇern´ a schopnosti zdroje. V pˇr´ıpadˇe zdroje se schopnost´ı s = 1.0 je skuteˇcn´ a doba trv´ an´ı (tj. doba pouˇzit´ı zdroje) rovna typick´ ym poˇzadavk˚ um aktivity, v jin´ ych pˇr´ıpadech m˚ uˇze b´ yt tato doba delˇs´ı ˇ (i kratˇs´ı). Casovan´ y pˇrechod metody use na z´akladˇe informac´ı z m´ısta skills, kter´e obsahuje dvojice (aktivita, schopnost), provede ˇcek´an´ı po dobu (1/s)d. Obr´azek 10.4 ukazuje doplnˇenou verzi tˇr´ıdy ScheduledResource. Alokace v´ıce zdroj˚ u pro jednu aktivitu Vyˇzaduje-li aktivita v´ıce zdroj˚ u, je to tˇreba odpov´ıdaj´ıc´ım zp˚ usobem specifikovat. Obr´azek 10.6 ukazuje model aktivity, poˇzaduj´ıc´ı tˇri zdroje se dvˇemi rolemi. Synchronn´ı pouˇzit´ı zdroj˚ u (srovn´an´ı zaˇc´atk˚ u a dob trv´ an´ı pouˇzit´ı zdroj˚ u) je modelov´ano zpr´ avou (a odpov´ıdaj´ıc´ı metodou zdroje) r useWith: s with: t.2 V pˇr´ıpadˇe, ˇze je pro danou aktivitu nutn´e pouˇz´ıt v´ıce zdroj˚ u, lze zohlednit vhodnost dan´e kombinace zdroj˚ u pro t´ ymovou pr´aci. To lze specifikovat matic´ı, kter´a kaˇzd´e dvojici 1
Napˇr´ıklad metodami z´ısk´ av´ an´ı znalost´ı z datab´ az´ı (datamining). Existuj´ı varianty t´eto zpr´ avy pro r˚ uzn´ y poˇcet parametr˚ u. Odpov´ıdaj´ıc´ı metoda tˇr´ıdy ScheduledResource zjist´ı maxim´ aln´ı dobu trv´ an´ı, nastav´ı ji vˇsem zdroj˚ um (vol´ an´ım k tomu urˇcen´ ych synchronn´ıch port˚ u), pot´e zaˇsle p˚ uvodn´ı zpr´ avu use paralelnˇe vˇsem z˚ uˇcastnˇen´ ym zdroj˚ um vˇcetnˇe sebe a poˇck´ a na jej´ı dokonˇcen´ı vˇsemi z˚ uˇcastnˇen´ ymi zdroji. 2
´ MODELY V R ˇ ´IZEN´I PROJEKTU ˚ KAPITOLA 10. DYNAMICKE
98
SheduledResource is_a Resource allocFor: a duration: d self isScheduledFor: a time: (DateAndTime now) duration: d (a, d) allocated (a, d)
use
.
isScheduledFor: a time: t duration: d (a = sa) & (t >= st) & (t < (st+sd)) & (d <= sd)
. . idle .
(sa, st, sd) schedule (a, s)
self hold: (1/s)*d
return
skills
Obr´azek 10.5: Zdroj s rozvrhem a schopnostmi. a Resource projectA
A1
R1
r allocFor: #A1 duration: 10. s allocFor: #A1 duration: 10. t allocFor: #A1 duration: 10 r useWith: s with: t
r, s t
.. ..
a Resource
a Resource
R2
a Resource
Obr´azek 10.6: Aktivita vyˇzaduj´ıc´ı v´ıce zdroj˚ u zdroj˚ u pˇriˇrazuje m´ıru schopnosti spolupracovat. Podobnˇe jako v pˇr´ıpadˇe typick´e doby trv´ an´ı aktivit a schopnosti vykon´ avat konkr´etn´ı aktivity, schopnost t´ ymov´e spolupr´ace zdroj˚ u lze z´ıskat anal´ yzou dat z pˇredchoz´ıch projekt˚ u. Tato schopnost se opˇet projev´ı v d´elce skuteˇcn´eho trv´ an´ı aktivity. Konkr´etn´ı implementace je v metod´ach typu useWith: r ve tˇr´ıdˇe ScheduledResource. Koncept pouˇ zit´ı modelu pro rozvrhov´ an´ı a monitorov´ an´ı Praktick´e pouˇzit´ı OOPN v modelov´an´ı projektov´eho portfolia pro potˇreby rozvrhov´an´ı a monitorov´an´ı m˚ uˇzeme nyn´ı podrobnˇeji specifikovat takto: • Simulace se pouˇz´ıv´ a pro ovˇeˇren´ı spr´ avnosti n´avrhu projektu. Zde se uplatn´ı hlavnˇe interaktivn´ı simulace. Model je t´eˇz pouˇziteln´ y pro anal´ yzu, vedouc´ı napˇr. ke zjiˇstˇen´ı kritick´e cesty v projektu. Start projektu se simuluje invokac´ı odpov´ıdaj´ıc´ı Petriho s´ıtˇe (to je technicky ˇreˇseno zasl´ an´ am zpr´ avy s pˇr´ıpadn´ ymi parametry, v´ ysledkem je invokace odpov´ıdaj´ıc´ı metody objektu projektov´eho portfolia). • Opakovan´ a automatick´a simulace je pouˇzita tak´e jako souˇc´ast fitness funkce pˇri optimalizaci zp˚ usobu pˇridˇelov´an´ı zdroj˚ u aktivit´ am. V´ ysledkem tohto optimalizaˇcn´ıho procesu je rozvrh, kter´ y vz´ ajemnˇe mapuje zdroje, ˇcasov´e intervaly a aktivity.
´ ´I PROJEKTOVEHO ´ 10.2. MODELOVAN PORTFOLIA
99
• Simulace s definovan´ ymi rozvrhy zdroj˚ u je m˚ uˇze b´ yt pouˇzita k dalˇs´ı anal´ yze. Model je 3 jiˇz deterministick´ y a simulac´ı lze napˇr. vygenerovat Gantt˚ uv diagram pro potˇreby dokumentace projektu. Lze potenci´alnˇe zohlednit i neurˇcitost a pracovat s fuzzy rozvrhem. • Model s definovan´ ym rozvrhem zdroj˚ u m˚ uˇze b´ yt pouˇzit pro monitorov´an´ı projektu. Pro monitoring pˇredpokl´ ad´ ame simulaci synchronizovanou re´aln´ ym ˇcasem a ud´alostmi z re´aln´eho prostˇred´ı. Mapov´an´ı re´aln´eh´eho ˇcasu a ˇcasu modelu pˇritom respektuje fakt, ˇze ˇcas modelu pokr´ yv´ a pouze pracovn´ı dobu.4 • Pˇri zmˇenˇe ve struktuˇre zdroj˚ u se mus´ı okamˇzitˇe automaticky aktualizovat m´ısta, znaˇcky a objekty, kter´e tyto zdroje modeluj´ı, a provede se nov´e rozvrhov´an´ı. Po vytvoˇren´ı nov´eho rozvrhu se aktualizuj´ı objekty zdroj˚ u (protoˇze obsahuj´ı vlastn´ı rozvrh pro jednotliv´e ˇcinnosti). • Pro potˇreby rozvrhov´an´ı se vytvoˇr´ı klon okamˇzit´eho stavu (jde o stav modelu v pr˚ ubˇehu monitorov´an´ı) a ten je pouˇzit jako poˇc´ateˇcn´ı stav pro zkoum´an´ı vˇsech moˇzn´ ych budoucnost´ı portfolia s r˚ uzn´ ymi zp˚ usoby pˇridˇelov´an´ı zdroj˚ u v r´amci zvolen´e optimalizaˇcn´ı strategie a zvolen´ ych kriteri´ı. • Vytvoˇren´ı nov´eho typu projektu (nov´eho pl´ anu) znamen´a pˇrid´ an´ı nov´e metody objektu portfolia za bˇehu. S´ıt’, modeluj´ıc´ı pl´ an projektu, m˚ uˇze b´ yt podle mˇen´ıc´ıch se vnˇejˇs´ıch poˇzadavk˚ u modifikov´ana v pr˚ ubˇehu ˇreˇsen´ı, stejnˇe tak i jednotliv´e jej´ı instance. Zachov´ an´ı modelu D´ıky pˇredpokl´ adan´e moˇznosti zasahovat do bˇeˇz´ıc´ı simulace v pr˚ ubˇehu monitorov´an´ı a d´ıky moˇznosti stav simulace klonovat a d´ale pouˇz´ıt pro potˇreby anal´ yzy a optimalizace je snadno realizovateln´ y fenom´en zachov´an´ı modelu (model continuity) v projektov´em ˇr´ızen´ı. Z´akladn´ı myˇslenkou je povaˇzovat model projektov´eho portfolia specifikovan´ y formalismem OOPN za z´akladn´ı a vˇsechny ostatn´ı pohledy na projektov´e portfolio automaticky generovat, pˇr´ıpadnˇe z jin´ ych pohled˚ u automaticky generovat a realizovat automatick´e editaˇcn´ı z´asahy do modelu na b´azi OOPN. K praktick´ e realizaci Uveden´ y zp˚ usob pouˇzit´ı OOPN vyˇzaduje realizovat simul´ ator otevˇren´ ym zp˚ usobem. Prakticky to znamen´a zpˇr´ıstupnit metaobjektov´ y protokol (MOP) simul´ atoru. MOP (jinak t´eˇz reflektivn´ı rozhran´ı) simul´ atoru umoˇzn´ı zasahovat do struktury modelu za bˇehu. Takov´e rozˇs´ıˇren´ı OOPN bylo jiˇz navrˇzeno a experiment´alnˇe implementov´ano v prostˇred´ı jazyka a syst´emu PNtalk, coˇz je implementace OOPN ve Smalltalku [JK04]. OOPN/PNtalk MOP umoˇzn ˇuje vytv´aˇren´ı, ruˇsen´ı, inspekci a editaci jednotliv´ ych Petriho s´ıt´ı definuj´ıc´ıch tˇr´ıdy a jednotliv´ ych instanc´ı s´ıt´ı implementuj´ıc´ıch jednotliv´e ˇziv´e objekty. Umoˇzn ˇuje tak´e vytvoˇrit klon bˇeˇz´ıc´ıho syst´emu a uloˇzit, resp. naˇc´ıst ho do/z datab´ aze. Alternativou k pˇr´ım´emu pouˇzit´ı simul´ atoru OOPN je moˇznost OOPN pouˇz´ıt jen na konceptu´aln´ı u ´rovni s t´ım, ˇze samotn´a realizace m˚ uˇze b´ yt jin´ a. OOPN je moˇzn´e transformovat do jin´ ych formalism˚ u a prostˇred´ı. C´ılovou realizac´ı m˚ uˇze b´ yt napˇr. datab´ azov´a 3 Zdroje jsou modelov´ any objekty, dostupn´ ymi jako znaˇcky v m´ıstech s´ıtˇe objektu. Str´ aˇze pˇrechod˚ u modeluj´ıc´ıch jednotliv´e aktivity v r´ amci jednotliv´ ych projekt˚ u kontroluj´ı kromˇe okamˇzit´e fyzick´e dostupnosti zdroje tak´e to, zda rozvrh zdroje dovoluje zdroj aktivitˇe pˇridˇelit (to je implementov´ ano metodami zdroje). 4ˇ Cas modelu by mohl b´ yt zaveden i jinak. Model by pak byl obecnˇejˇs´ı, ale tak´e komplikovanˇejˇs´ı.
´ MODELY V R ˇ ´IZEN´I PROJEKTU ˚ KAPITOLA 10. DYNAMICKE
100
aplikace. Pro optimalizaci a rozvrhov´an´ı pak mohou b´ yt pouˇzity existuj´ıc´ı obecn´e n´astroje, napˇr knihovny pro genetick´e algoritmy apod.
10.3
Shrnut´ı
Studii o modelov´an´ı projektov´eho portfolia Objektovˇe orientovan´ ymi Petriho s´ıtˇemi m˚ uˇzeme shrnout takto: • Obvykl´ ym ˇreˇsen´ım s vyuˇzit´ım Petriho s´ıt´ı je udrˇzovat jednu glob´aln´ı vysoko´ urovˇ novou Petriho s´ıt’ pro cel´e projektov´e portfolio a tuto Petriho s´ıt’ postupnˇe v r´amci monitorov´an´ı aktualizovat a po aktualizaci pouˇz´ıt jako v´ ychodisko pro rozvrhov´an´ı. • Modely na b´azi OOPN nab´ızej´ı moˇznost pouˇz´ıt dynamicky instanciovateln´e Petriho s´ıtˇe pro modelov´an´ı jednotliv´ ych pl´ an˚ u projekt˚ u. Pˇredem definovan´e pl´ any lze dynamicky instanciovat, instance pl´ an˚ u mohou b´ yt parametrizov´any. Jednotliv´e pl´ any jsou ale staticky fixov´any – odpov´ıdaj´ıc´ı Petriho s´ıtˇe jsou v pˇr´ıpadˇe klasick´e varianty OOPN pevnˇe d´any v dobˇe startu syst´emu. • Doporuˇcen´e ˇreˇsen´ı: Instanciovateln´e Petriho s´ıtˇe s moˇznost´ı editovat jejich strukturu za bˇehu. Pl´ any projekt˚ u pak mohou b´ yt libovolnˇe modifikov´any, zat´ımco strukturov´an´ı modelu do jednotliv´ ych pl´ an˚ u z˚ ust´av´a zachov´ ano. Pracuje se s pˇredem definovan´ ymi typy pl´ an˚ u projekt˚ u a s jejich instancemi. Dynamicky lze editovat jak typy pl´ an˚ u, tak jejich jednotliv´e instance. V´ yhodou pˇr´ım´eho pouˇzit´ı OOPN pro modelov´an´ı projektov´eho portfolia je adekv´atn´ı strukturov´an´ı modelu, takˇze nevznik´a jedna nestrukturovan´ a s´ıt’, kde jsou d´ılˇc´ı s´ıtˇe jednotliv´ ych projekt˚ u spojeny do jednoho celku, ale jednotliv´e s´ıtˇe existuj´ı a jsou pod kontrolou samostatnˇe (napˇr. z´anik, resp. ukonˇcen´ı projektu jsou modelov´any adekv´atn´ım zp˚ usobem). Pracuje se t´ım p´adem na vyˇsˇs´ı u ´rovni neˇz v pˇr´ıpadˇe editace jedn´e nestrukturovan´e s´ıtˇe – pojmy probl´emov´e dom´eny jsou v modelu zachov´any, vytvoˇren´ım modelu se neztr´ac´ı informace o jednotliv´ ych projektech portfolia. Dalˇs´ım pˇr´ınosem tohoto ˇreˇsen´ı je zaveden´ı typ˚ u (vzor˚ u) pl´ an˚ u, a to jak pˇredem pˇripraven´ ych, tak i dynamicky vznikaj´ıc´ıch a dynamicky aktualizovateln´ ych v pr˚ ubˇehu ˇreˇsen´ı.
Kapitola 11
Z´ avˇ er V t´eto pr´aci byly pops´ any vybran´e aspekty problematiky modelov´an´ı a simulace vyv´ıjej´ıc´ıch se a nepˇretrˇzitˇe bˇeˇz´ıc´ıch syst´em˚ u, zahrnuj´ıc´ı jak teoretick´a v´ ychodiska, tak moˇznosti praktick´e realizace. Byly uvaˇzov´any r˚ uzn´e aplikaˇcn´ı oblasti, zahrnuj´ıc´ı jak automatickou, tak interaktivn´ı evoluci syst´em˚ u. V´ yznam DEVS pro modelov´ an´ı, simulaci a n´ avrh syst´ em˚ u Hlavn´ım formalismem, pouˇzit´ ym v tomto textu, je DEVS. Formalizace simulaˇcn´ıch model˚ u pomoc´ı DEVS pˇrin´ aˇs´ı platformnˇe nez´ avisl´e simulaˇcn´ı modely a moˇznost transformace model˚ u do r˚ uzn´ ych simulaˇcn´ıch prostˇred´ı. Sofistikovanˇejˇs´ı formalismy, jako jsou napˇr´ıklad Petriho s´ıtˇe a stavov´e diagramy (statecharts) je moˇzn´e do DEVS relativnˇe snadno transformovat. S vyuˇzit´ım DEVS je moˇzn´e srozumitelnˇe a na form´ aln´ım z´akladˇe popsat problematiku distribuovan´e simulace, viz napˇr. [ZKP00]. DEVS tak´e hraje v´ yznamnou u ´lohu v souˇcasn´ ych aktivit´ ach v oblasti v´ yvoje syst´em˚ u na b´azi simulace (Simulation-Based Design and Development), kde koncept zachov´an´ı modelu (Model Continuity) v´ yznamnˇe pˇrisp´ıv´ a k efektivnosti a bezpeˇcnosti v´ yvoje [HZ04]. Hlavn´ı t´emata aktu´aln´ıho v´ yzkumu souvisej´ıc´ıho s formalismem DEVS lze shrnout takto: • standardizace modelova´ıch formalism˚ u, • transformace model˚ u mezi r˚ uzn´ ymi formalismy a implementaˇcn´ımi jazyky, • metodologie modelov´an´ı a n´avaznost na metodiky softwarov´eho inˇzen´ yrstv´ı, • interoperabilita n´astroj˚ u a pˇrenositelnost model˚ u, • standardn´ı knihovny znovupouˇziteln´ ych model˚ u, • webov´e sluˇzby pro simulaci. Dynamick´e prostˇred´ı pro modelov´an´ı a simulaci model˚ u na b´azi DEVS, o kter´em byla v tomto textu ˇreˇc, je v souladu s obecn´ ym trendem ve st´ale vˇetˇs´ı m´ıˇre aplikovat dynamick´e programovac´ı jazyky v realizaci programov´ ych syst´em˚ u. V´ yhodou je rychlejˇs´ı v´ yvoj syst´em˚ u a moˇznost sledovat a modifikovat jejich dynamiku, coˇz vede k lepˇs´ımu vhledu do chov´an´ı syst´em˚ u a tedy ke kvalitnˇeji navˇzen´ ym syst´em˚ um. Jednoduch´ y a srozumiteln´ y form´ aln´ı z´aklad model˚ u na b´azi DEVS umoˇzn ˇuje kromˇe simulace a testov´an´ı pˇr´ımo aplikovat i matematick´e metody pro anal´ yzu syst´em˚ u, jejich struktury i chov´an´ı.
´ ER ˇ KAPITOLA 11. ZAV
102
Jin´ e formalismy DEVS modeluje syst´em jako stavov´ y stroj (i kdyˇz mnoˇzina stav˚ u m˚ uˇze b´ yt i nekoneˇcn´ a) s explicitnˇe vyj´adˇren´ ym stavem a s explicitnˇe vyj´adˇren´ ymi pˇrechody, modifikuj´ıc´ımi stav. To nemus´ı b´ yt na prvn´ı pohled pro praktick´e programov´an´ı pˇr´ıliˇs v´ yhodn´e. DEVS m´ a ovˇsem smysl pouˇz´ıvat jako komponentn´ı prostˇred´ı, kde s v´ yhodou vyuˇzijeme toho, ˇze jde o volnˇe v´azan´e komponenty, s kter´ ymi je moˇzn´e snadno dynamicky manipulovat pr´avˇe d´ıky explicitnˇe vyj´adˇren´emu stavu a voln´e vazbˇe na ostatn´ı komponenty. Obvykl´e pˇr´ıstupy k programov´an´ı je v´ yhodn´e pouˇz´ıt uvnitˇr komponent DEVS. Mapov´an´ı vybran´eho formalismu (jazyka) do komponenty DEVS znamen´a vyj´adˇrit explicitnˇe stavy a pˇrechody. V kapitole 6 byla pops´ ana moˇznost specifikovat komponentu DEVS formalismem OOPN. V´ yhodou tohoto pˇr´ıstupu je ˇcitelnˇejˇs´ı, vysoko´ urovˇ novˇejˇs´ı, vizu´aln´ı reprezentovatace modelu. Zapouzdˇren´ım interpretu OOPN bylo dosaˇzeno spojen´ı v´ yhod paraleln´ıho objektovˇe orientovan´eho jazyka a komponentn´ıho pˇr´ıstupu se snadno dynamicky manipulovateln´ ymi komponentami. Interpret OOPN zpˇr´ıstupˇ nuje reflektivn´ı rozhran´ı, umoˇzn ˇuj´ıc´ı s objekty interpretu manipulovat podobnˇe jako s komponentami DEVS. Vzhledem k charakteru formalismu jsou zde ale jist´ a omezen´ı plynouc´ı z toho, ˇze objekty (na rozd´ıl od komponent) jsou prov´az´any referencemi a zachovat konzistenci modelu po editaˇcn´ıch z´asaz´ıch nen´ı zcela jednoduch´e.1 CAST CAST je zkratka pro Computer-Aided Systems Theory [Pic89]. DEVS, jako modelovac´ı formalismus, kter´ y bezprostˇrednˇe z teorie syst´em˚ u vych´az´ı, dokonale odpov´ıd´ a konceptu spojen´ı poˇc´ıtaˇcov´ ych n´astroj˚ u a teorie syst´em˚ u. Kaˇzd´ a konkr´etn´ı implementace abstraktn´ıho simul´ atoru DEVS je vlastnˇe pˇr´ımoˇcarou poˇc´ıtaˇcovou implementac´ı teorie syst´em˚ u (s diskr´etn´ımi ud´alostmi). Vezmeme-li v u ´vahu koncept zachov´an´ı modelu v c´ılov´e realizaci, jde v pˇr´ıpadˇe DEVS a jin´ ych kompatibiln´ıch formalism˚ u (DEVS-like systems) o pˇr´ıklad ide´aln´ıho sepˇet´ı teorie a praxe tvorby poˇc´ıtaˇcov´ ych syst´em˚ u, kde konkr´etn´ı, prakticky realizovan´e syst´emy a jejich komponenty jsou souˇcasnˇe matematick´ ymi objekty, manipulovaten´ ymi v souladu s teori´ı a souˇcasnˇe pˇr´ımo pouˇziteln´ ymi v re´aln´em prostˇred´ı. Poˇ c´ıtaˇ cov´ e n´ astroje V tomto textu popisovan´e obecn´e principy simulaˇcn´ıho modelov´an´ı vyv´ıjej´ıc´ıch se syst´em˚ u (kapitola 4) jsou ilustrov´any konkr´etn´ımi implementacemi abtraktn´ı simulaˇcn´ı architektury, navrˇzen´e pr´avˇe pro tento typ syst´em˚ u. Implementaˇcn´ım prostˇred´ım je Smalltalk. V nˇem vytvoˇren´e n´astroje SmallDEVS a PNtalk (kapitoly 5 a 6) jsou pouˇziteln´e jako pom˚ ucky pro studium problematiky modelov´an´ı a simulace a jako demonstrace nˇekter´ ych ne zcela bˇeˇzn´ ych pˇr´ıstup˚ u, jej´ımˇz c´ılem je podpoˇrit tvorbu nov´ ych a dalˇs´ı v´ yvoj existuj´ıc´ıch simulaˇcn´ıch n´astroj˚ u. Propojen´ı experiment´aln´ıch n´astroj˚ u SmallDEVS a PNtalk se soudob´ ymi pr˚ umyslovˇe pouˇziteln´ ymi a pouˇz´ıvan´ ymi n´astroji je potenci´alnˇe moˇzn´e, protoˇze jako souˇc´ast dalˇs´ıho v´ yzkumu se poˇc´ıt´ a s moˇznost´ı zajiˇstˇen´ı interoperability za pouˇzit´ı platformnˇe neutr´ aln´ıho jazyka DEVSML, na jehoˇz v´ yvoji se v komunitˇe v´ yzkumn´ık˚ u z oblasti modelov´an´ı a simulace v souˇcasn´e dobˇe pracuje [MRMZ07]. Ve speci´aln´ıch pˇr´ıpadech, kdy nen´ı tˇreba interoperabilitu s jin´ ymi n´astroji ˇreˇsit, lze tyto experiment´aln´ı n´astroje pouˇz´ıt pˇr´ımo. Situaci usnadˇ nuje fakt, ˇze jde o volnˇe ˇsiˇriteln´e n´astroje, s jejichˇz zdrojov´ ym k´odem lze d´ıky liber´aln´ı licenci (MIT) nakl´ adat prakticky bez omezen´ı. 1
Tato problematika je st´ ale pˇredmˇetem v´ yzkumu.
103 Origin´ aln´ı v´ ysledky Hlavn´ım pˇr´ınosem t´eto pr´ace jsou prvn´ı kroky vedouc´ı k formalizaci problematiky vyv´ıjej´ıc´ıch se syst´em˚ u, zahrnuj´ıc´ı pˇredevˇs´ım dynamickou manipulaci s modely a simulacemi v kontextu n´avrhu syst´em˚ u s vyuˇzit´ım simulace. Pˇritom byl kladen d˚ uraz na d˚ usledn´e prov´az´an´ı teorie modelov´an´ı a simulace (reprezentovan´e formalismem DEVS) s prax´ı v podobˇe n´astroj˚ u SmallDEVS a PNtalk, kter´e byly demonstrov´any v nˇekolika pˇr´ıpadov´ ych studi´ıch.
104
´ ER ˇ KAPITOLA 11. ZAV
Literatura [ABPD96]
Andrea Asperti, Nadia Busi, Piazza Porta, and S. Donato. Mobile petri nets. Technical report, 1996.
[AG04]
Norman P. Archer and Fereidoun Ghasemzadeh. Project portfolio selection and management. In J.K. Pinto P.W.G. Morris, editor, TheWiley Guide to Managing Projects. Wiley, New York, 2004.
[AM04]
K. A. Amin and A. R. Mikler. Agent-based Distance Vector Routing: A Resource Efficient and Scalable approach to Routing in Large Communication Networks. Journal of Systems and Software, 71(3):215–227, 2004.
[Anb05]
F. Anbari. Q & As for the PMBOK Guide. ISBN 1930699395. Project Management Institute, 2005.
[Bar97]
F. J. Barros. Modeling formalisms for dynamic structure systems. In ACM Transactions on Modeling and Computer Simulation (TOMACS), 1997.
[Bra87]
M. E. Bratman. Intention, Plans, and Practical Reason. Harvard University Press, Cambridge, MA, 1987.
[BWH07]
R. H. Bordini, M. Wooldridge, and J. F. H¨ ubner. Programming Multi-Agent Systems in AgentSpeak using Jason (Wiley Series in Agent Technology). John Wiley & Sons, 2007.
[DdBDM03] M. Dastani, F. de Boer, F. Dignum, and J. Meyer. Programming Agent Deliberation: an Approach Illustrated Using the 3APL Language. In Proceedings of AAMAS ’03, pages 97–104, New York, NY, USA, 2003. ACM. [dLG+ 04]
M. d’Inverno, M. Luck, M. P. Georgeff, D. Kinny, and M. Wooldridge. The dMARS Architecture: A Specification of the Distributed Multi-Agent Reasoning System. Autonomous Agents and Multi-Agent Systems, 9(1-2):5–53, 2004.
[E. 03]
E. I. Hsu and D. L. Mcguinness. Wine Agent: Semantic Web Testbed Application. In Proceedings of 2003 Description Logics (DL2003), page 5–7. CEUR-WS.org, 2003.
[FIP01]
FIPA. FIPA ACL Message Structure Specification. FIPA, 2001.
[GK03]
S. Rollins G. Kendall. Advanced Project Portfolio Management and the PMO. J. Ross Publishing, Boca Raton, FL, 2003.
106
LITERATURA
[GL87]
M. P. Georgeff and A. L. Lansky. Reactive Reasoning and Planning. In Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-87), pages 677–682, Seattle, WA, USA, July 1987. Morgan Kaufmann.
[GR89]
A. Goldberg and D. Robson. Smalltalk 80: The Language. Addison-Wesley, 1989.
[GR96]
Michael Peter Georgeff and Anand S. Rao. A profile of the australian artificial intelligence institute. IEEE Expert: Intelligent Systems and Their Applications, 11(6):89–92, 1996.
[GVH03]
B. P. Gerkey, R. T. Vaughan, and A. Howard. The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. In Proceedings of the 11th International Conference on Advanced Robotics, pages 317–323, 2003.
[Hu04]
X. Hu. A Simulation-Based Software Development Methodology for Distributed Real-Time Systems. PhD thesis, The University of Arizona, USA, 2004.
[HY03]
X.C. Jiao H.S. Yan, Z. Wang. Modeling, scheduling and simulation of product development process by extended stochastic high-level evaluation Petri nets. Robotics and Computer-Integrated Manufacturing, 19(4):329–342, 2003.
[HZ04]
X. Hu and B. P. Zeigler. Model Continuity to Support Software Development for Distributed Robotic Systems: a Team Formation Example. In Journal of Intelligent & Robotic Systems, Theory & Application, Special Issue: Multiple and Distributed Cooperating Robots, pages 71–87, 2004.
[Jan95]
V. Janouˇsek. PNtalk: Object Orientation in Petri nets. In Proceedings of European Simulation Multiconference ESM’95, pages 196–200. Prague, CZ, 1995.
[Jan98]
V. Janouˇsek. Modelov´ an´ı objekt˚ u Petriho s´ıtˇemi. PhD thesis, FEI VUT, Brno, CZ, 1998.
[Jan06]
V. Janouˇsek. SmallDEVS. http://www.fit.vutbr.cz/˜janousek/smalldevs, 2006.
[JK03]
V. Janouˇsek and R. Koˇc´ı. PNtalk: Concurrent Language with MOP. In Proceedings of the CS&P’2003 Workshop. Warsaw University, Warsawa, PL, 2003.
[JK04]
V. Janouˇsek and R. Koˇc´ı. Towards an Open Implementation of the PNtalk System. In Proceedings of the 5th EUROSIM Congress on Modeling and Simulation. EUROSIM-FRANCOSIM-ARGESIM, Paris, FR, 2004.
[JK05a]
V. Janouˇsek and R. Koˇc´ı. PNtalk Project: Current Research Direction. In Simulation Almanac 2005. Faculty of Electrical Engineering, Praha, CZ, 2005.
[JK05b]
V. Janouˇsek and R. Koˇc´ı. Towards Model-Based Design with PNtalk. In Proceedings of the International Workshop MOSMIC’2005. Faculty of management science and Informatics of Zilina University, SK, 2005.
LITERATURA
107
[JK06]
V. Janouˇsek and E. Kironsk´ y. Exploratory Modeling with SmallDEVS. In Proc. of ESM 2006, pages 122–126. EUROSIS, 2006.
[JK07]
V. Janouˇsek and R. Koˇc´ı. Embedding Object-Oriented Petri Nets into a DEVS-based Simulation Framework. In Proceedings of the 16th International Conference on System Science, volume 1, pages 386–395. Wroclaw University of Technology, 2007.
[KHS97]
H. Kargupta, I. Hamzaoglu, and B. Stafford. Scalable distributed data mining - an agent architecture. In Proceedings the Third International Conference on the Knowledge Discovery and Data Mining, page 211–214, Menlo Park, California, 1997. AAAI Press.
[Kit98]
H. Kitano, editor. Volume 1395 of Lecture Notes in Computer Science. Springer, 1998.
[Kli85]
G. Klir. Architecture of Systems Problem Solving. Plenum Press, New Yourk, NY, 1985.
[Koc02]
Waldemar Kocjan. Dynamic scheduling state of the art report. Technical Report T2002:28, Dynamic scheduling state of the art report, 2002.
[Kou01]
Adamantios Koumpis. 2(36):1, 2001.
[Lee04]
B. Lee. Multi-project management in software engineering using simulation modeling. Software Quality Journal, 12(1):59–82, 2004.
[Lie86]
H. Lieberman. Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems. In OOPSLA ‘86 Conference Proceedings. Also Sigplan Notices, volume 21, issue 11, pages 214–223, 1986.
[LRS01]
R. Laddaga, P. Robertson, and H. Shrobe, editors. Self-Adaptive Software: Applications. Springer, 2001.
[LTO03]
Victor Lesser, Milind Tambe, and Charles L. Ortiz, editors. Distributed Sensor Networks: A Multiagent Perspective. Kluwer Academic Publishers, Norwell, MA, USA, 2003.
[MA04]
H. M. Mosner and R. Allen. Prototypes. http://map.squeak.org, 2004.
[Mae87]
P. Maes. Computational reflection. Technical report, Artifical Inteligence Laboratory, Vrije Universiteit Brusel, 1987.
[Maz08]
Z. Mazal. Modelov´ an´ı uvaˇzuj´ıc´ıch syst´em˚ u Petriho s´ıtˇemi. PhD thesis, FIT VUT, Brno, CZ, 2008.
The european ist explantech project.
Ubiquity,
[MMWY92] H. Masuhara, S. Matsuoka, T. Watanabe, and A. Yonezawa. Object-oriented concurrent reflective languages can be implemented efficiently. In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), SIGPLAN Notices, volume 27, number 10, pages 127–144. ACM Press, New York, NY, 1992.
108
LITERATURA
[Mos01]
Multi-agent based simulation: second international workshop. volume 1979 of Lecture notes in computer science: Lecture notes in artificial intelligence, Berlin, 2001. Springer.
[MRMZ07]
Saurabh Mittal, Jos´e Luis Risco-Mart´ın, and Bernard P. Zeigler. Devsml: automating devs execution over soa towards transparent simulators. In SpringSim ’07: Proceedings of the 2007 spring simulation multiconference, pages 287–295, San Diego, CA, USA, 2007. Society for Computer Simulation International.
[MVR+ 06]
ˇ ska, V. Janouˇsek, R. Koˇc´ı, B. Kˇrena, and T. Vojnar. PNtalk: State of M. Ceˇ the Art. In Proceedings of the Fourth International Workshop on Modelling of Objects, Components, and Agents, pages 301–307. Hamburg, DE, 2006.
[MVT97]
ˇ ska, V. Janouˇsek, and T. Vojnar. PNtalk – A Computerized Tool for M. Ceˇ Object Oriented Petri Nets Modelling. In Proceedings of EUROCAST’97, pages 229–231. Las Palmas de Gran Canaria, ES, 1997.
[MVT02]
ˇ ska, V. Janouˇsek, and T. Vojnar. Modelling, Prototyping, and Verifying M. Ceˇ Concurrent and Distributed Applications Using Object-Oriented Petri Nets. Kybernetes: The International Journal of Systems and Cybernetics, 2002(9), 2002.
[MW97]
D. Moldt and F. Wienberg. Multi-Agent-Systems Based on Coloured Petri Nets. In Lecture Notes in Computer Science: 18th International Conference on Application and Theory of Petri Nets, pages 82–101. Springer-Verlag, 1997.
[Paw98]
R. Pawlak. Metaobject Protocols For Distributed Programming. Technical report, Laboratoire CNAM-CEDRIC, Paris, 1998.
[PBL03]
A. Pokahr, L. Braubach, and W. Lamersdorf. Jadex: Implementing a BDIInfrastructure for JADE Agents. EXP – in search of innovation, 3(3):76–85, 2003.
[Pic89]
Franz Pichler. From systems theory to cast. In Franz Pichler and Roberto Moreno-D´ıaz, editors, EUROCAST, volume 410 of Lecture Notes in Computer Science, pages 2–6. Springer, 1989.
[Pin02]
Michael Pinedo. Scheduling: Theory, Algorithms, and Systems. second edition. Prentice Hall, 2002.
[Pin05]
Michael Pinedo. Planning and Scheduling in Manufacturing and Services. Springer, 2005.
[PNt06]
The PNtalk System. http://www.fit.vutbr.cz/˜janousek/pntalk, 2006.
[Rao96]
A. S. Rao. AgentSpeak(L): BDI agents speak out in a logical computable language. In Rudy van Hoe, editor, Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World, pages 42–55, Secaucus, NJ, USA, 1996. Springer-Verlag New York, Inc.
LITERATURA
109
[Ren06]
Renew – the Reference Net Workshop. http://www.renew.de, 2006.
[SBD+ 00]
S. Subrahmanian, P. Bonatti, J. Dix, T. Eiter, S. Kraus, F. Ozcan, and R. Ross. Heterogeneous Agent Systems. MIT Press/AAAI Press, Cambridge, MA, USA, 2000.
[Sch05]
K. Schwalbe. Information Technology Project Management, Fourth Edition. ISBN 1930699395. Course Technology, 2005.
[Skl97]
J. Sklenar. Intorduction to http://staff.um.edu.mt/jskl1/talk.html, 1997.
[Spi92]
M. Spinner. Elements of Project Management: Plan, Schedule, and Control, 2nd Ed. Englewood Cliff, NJ, Prentice Hall, 1992.
[TUN06]
The TUNES Project http://tunes.org, 2006.
[Uhr01]
A. M. Uhrmacher. Dynamic structures in modeling and simulation: a reflective approach. ACM Transactions on Modeling and Computer Simulation (TOMACS), 11:206–232, 2001.
[US87]
D. Ungar and R. Smith. SELF: The Power of Simplicity. In OOPSLA ‘87 Conference Proceedings, pages 227–241, 1987.
[Val98]
R. Valk. Petri Nets as Token Objects: An Introduction to Elementary Object Nets. In Jorg Desel, Manuel Silva (eds.): Application and Theory of Petri Nets; Lecture Notes in Computer Science, volume 120. Springer-Verlag, 1998.
[Van00]
H. Vangheluwe. Multi-formalism Modelling and Simulation. PhD thesis, Faculty of Science, Ghent University (UGent), December 2000.
[WH02]
D. Weyns and T. Holvoet. A Colored Petri Net for a Multi-Agent Application. In Components, Objects and Agents, MOCA02. Computer Science Department, Aarhus University, 2002.
[Woo02]
M. Wooldridge. Introduction to MultiAgent Systems. John Wiley & Sons, 2002.
[YC06]
Z. Yu and Y. Cai. Object-Oriented Petri nets Based Architecture Description Language for Multi-agent Systems. International Journal of Computer Science and Network Security, 6(1B):123–131, 2006.
[Zei84]
B. P. Zeigler. Multifacetted Modelling and Discrete Event Simulation. Academic Press Prof., Inc., San Diego, CA, 1984.
[Zei90]
B. P. Zeigler. Object-Oriented Simulation with Hierarchical, Modular Models: Intelligent Agents and Endomporphic Systems. Academic Press Prof., Inc., San Diego, CA, 1990.
[ZKP00]
B. Zeigler, T. Kim, and H. Praehofer. Theory of Modeling and Simulation. Academic Press, Inc., London, UK, 2000.
for
a
Free
OOPN
Reflective
in
Computing
SIMULA.
System.