FIT, Brno University of Technology, Czech Rep.,

´ 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ávrh vyv´ıjej´ıc´ıch se systém˚ u Vladim´ır Janouˇsek Brno 2008

c Vladim´ır Janouˇsek, 2008

Pˇ redmluva Aplikac´ı simulace a form´ aln´ıch model˚ u, zvláˇstˇe pak model˚ u na bázi DEVS (Discrete Event Systems Specification) v návrhu systém˚ 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éto 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ého inˇzen´ yrstv´ı s vyuˇzit´ım modelov´ an´ı a simulace v návrhu systém˚ u. Tento pˇr´ıstup je s u ´spˇechem pouˇz´ıv´ an v pr˚ umyslu, zvláˇstˇe pak ve v´ yvoji vojensk´ ych a kosmick´ ych technologi´ı (v´ yzkum v této oblasti podporuje zejména NASA a Ministerstvo obrany USA). Skupina modelován´ı a simulace na FIT VUT v Brnˇe nen´ı ani zdaleka tak silná, ale také se snaˇz´ı aplikovat form´ aln´ı modely a simulaci ve v´ yvoji systém˚ u. Vycház´ı vˇsak z ponˇekud jin´ ych koˇren˚ u, které nejsou tak tˇesnˇe svázány s pr˚ umyslem a jsou vhodné sp´ıˇse pro jin´ y typ projekt˚ u a s t´ım souvisej´ıc´ı jin´ y pˇr´ıstup k v´ yvoji systém˚ u. Klade d˚ uraz pˇredevˇs´ım na rychlé prototypován´ı, experimentáln´ı programov´ an´ı, dynamické jazyky a objektovou orientaci zaloˇzenou na prototypov´ ych objektech. Tento pˇr´ıstup je obecnˇe vhodn´ y pro návrh a v´ yvoj systém˚ u s nejasnou specifikac´ı, kterou je tˇreba dopracovat aˇz v rámci v´ yvoje a c´ılového nasazen´ı. Kromˇe moˇznosti zkoumat a interaktivnˇe vyv´ıjet systém za bˇehu je téˇz pˇredmˇetem zkoumán´ı moˇznost automatického v´ yvoje model˚ u. Oba zm´ınˇené 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áln´ı programován´ı a objektovou orientaci se ˇclenové skupiny snaˇz´ı aplikovat pˇribliˇznˇe od r. 2000. V té dobˇe existovala experimentáln´ı implementace interpretu Objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN), které jsem navrhl a form´ alnˇe definoval v rámci své disertaˇcn´ı práce. Pro OOPN jsem v té dobˇe navrhl koncept otevˇrené architektury, umoˇznuj´ıc´ı reflektivn´ı zásahy do modelu a simul´ atoru v dobˇe bˇehu. Toto téma posléze podrobnˇe zpracoval ve své disertaˇcn´ı práci Radek Koˇc´ı. Implementována byla tenkrát ale jen ˇcást potˇrebn´ ych reflektivn´ıch vlastnost´ı, které byly nezbytné pro jednoducé experimenty napˇr. s vnoˇrenou simulac´ı. V rámci zkoumán´ı moˇznost´ı multiparadigmatického pˇr´ıstupu k tvorbˇe model˚ u s jednoduch´ ym jednot´ıc´ım formalismem bylo posléze rozhodnuto paralelnˇe aplikovat tytéˇz principy pro podstatnˇe jednoduˇsˇs´ı formalismus, a sice DEVS (Discrete EVent Systems Specification). D´ıky konceptuáln´ı jednoduchosti a hierarchické struktuˇre s volnˇe vázan´ ymi komponentami je DEVS pouˇziteln´ y jako spoleˇcn´ y základ pro aplikaci r˚ uzn´ ych formalism˚ u v r´ amci jednoho simulaˇcn´ıho modelu. Experimentáln´ı implementace, kterou jsem vytvoˇril, splˇ novala vˇsechny kl´ıˇcové poˇzadavky – byl to systém s plnou reflektivitou, umoˇzn ˇuj´ıc´ı neomezené zásahy do simulace v dobˇe bˇehu. Experimentálnˇe byly téˇz implementovány vizu´ aln´ı nástroje pro inspekci a editaci model˚ u (implementaci tˇechto nástroj˚ u provedl v rámci své diplomové práce Elod Kironsk´ y). Vytvoˇrené prostˇred´ı nyn´ı poskytuje rámec, do kterého je moˇzné potenciálnˇe zaˇclenit interprety jin´ ych formalism˚ u. V souˇcasné 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ém˚ u, které jako souˇcást své disertaˇcn´ı práce navrhl a implementoval Zdenˇek Mazal. V uvedeném kontextu se nyn´ı jev´ı jako vhodné popsat kl´ıˇcové aspekty souˇcasného stavu poznán´ı v oblasti aplikace reflektivity pro potˇreby modelován´ı a simulace vyv´ıjej´ıc´ıch se systém˚ u. A o tom je tato práce. Autor

Abstrakt Tato práce se zab´ yv´ a problematikou modelován´ı, simulace a návrhu systém˚ u s diskrétn´ımi událostmi s d˚ urazem na nepˇretrˇzitˇe bˇeˇz´ıc´ı a vyv´ıjej´ıc´ı se systémy. Konkrétnˇe se zab´ yv´ a tˇemito tématy: • Vymezen´ı tˇr´ıdy vyv´ıjej´ıc´ıch se systém˚ u, zahrnuj´ıc´ı jak interaktivn´ı, tak automatick´ y v´ yvoj. • Systémy s diskrétn´ımi událostmi, formalismus DEVS, jeho varianty, vˇcetnˇe existuj´ıc´ıch modifikac´ı, zavádˇej´ıc´ıch strukturn´ı dynamiku. • Reflektivn´ı DEVS a otevˇren´ a abstrakn´ı architektura pro modelán´ı, simulaci a návrh systém˚ u. • Prostˇredky pro interaktivn´ı evoluˇcn´ı návrh systém˚ u. • Pˇr´ıpadové studie, demonstruj´ıc´ı reflektivitu a dynamick´ y v´ yvoj struktury systému. Hlavn´ım pˇr´ınosem práce je (1) zmapován´ı problematiky vyv´ıjej´ıc´ıch se systém˚ u, zahrnuj´ıc´ı pˇredevˇs´ım dynamickou manipulaci s modely a simulacemi v kontextu návrhu systém˚ u s vyuˇzit´ım simulace, (2) koncept abstraktn´ı architektury pro simlaci vyv´ıjej´ıc´ıch se systém˚ u a (3) a ovˇeˇren´ı navrˇzeného konceptu abstraktn´ı achitektury pro vyv´ıjej´ıc´ı se systémy pˇr´ıkladem praktické realizace, aplikované v nˇekolika pˇr´ıpadov´ ych studi´ıch. To vˇse v návaznosti na teorii modelován´ı a simulace systém˚ u s diskrétn´ımi událostmi.

vi

Obsah ´ 1 Uvod – vyv´ıjej´ıc´ı se syst´ emy

1

2 Syst´ emy s diskr´ etn´ımi ud´ alostmi 2.1 Systémy, znalosti, problémy . . . . . . . . . . . . . . 2.2 Simulaˇcn´ı modelován´ı . . . . . . . . . . . . . . . . . ˇ 2.3 Cas, trajektorie a segmenty . . . . . . . . . . . . . . 2.4 Systém . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Formalismus DEVS . . . . . . . . . . . . . . . . . . . 2.5.1 Systém s diskrétn´ımi událostmi . . . . . . . . 2.5.2 Základn´ı model . . . . . . . . . . . . . . . . . 2.5.3 Sloˇzen´ y model . . . . . . . . . . . . . . . . . 2.5.4 Pouˇzit´ı port˚ u . . . . . . . . . . . . . . . . . . 2.5.5 Varianty a rozˇs´ıˇren´ı základn´ı definice DEVS . 2.6 Hierarchická simulace DEVS (abstraktn´ı simul´ ator) . 2.7 Praktické pouˇzit´ı formalismu DEVS . . . . . . . . . 2.7.1 DEVS a objektová 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álném ˇcase, propojen´ı s reáln´ ym okol´ım 4.3 Klonován´ı a migrace systém˚ u a simulac´ı . . . . . . . ˇ ı a modifikace modelu . . . . . . . . . . . . . . . 4.4 Cten´ 4.5 Systémy 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áln´ı programován´ı a Smalltalk . . . . 5.3 Objektová orientace zaloˇzen´ a na prototypech . . 5.4 Modelován´ı systém˚ u prototypov´ ymi objekty . . . 5.5 Sd´ılené chován´ı, 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ém . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Smalltalk a SmallDEVS . . . . . . . . . . . . . . . . . . 5.7.2 Perzistence . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.3 Vizu´ aln´ı nástroje pro manipulaci s modely a simulacemi Aplikaˇcn´ı rozhran´ı jádra SmallDEVS . . . . . . . . . . . . . . . Poznámka k implementaci . . . . . . . . . . . . . . . . . . . . .

6 Specifikace syst´ em˚ u formalismem OOPN 6.1 Petriho s´ıtˇe a objekty . . . . . . . . . . . . . . 6.1.1 Princip vysoko´ urovˇ nové Petriho s´ıtˇe . . 6.1.2 Paraleln´ı objektovˇe orientovan´ y systém 6.1.3 Modelován´ı objekt˚ u Petriho s´ıtˇemi . . . 6.1.4 Interakce objekt˚ u – zas´ılán´ı zpr´ av . . . 6.1.5 Invokace metod objekt˚ u zas´ılán´ım zpr´ av 6.1.6 Atomická 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é 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é simulace: Systém hromadné obsluhy, lizována 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ávˇer . . . . . . . . . . . . . . . . . . . . . . . . . .

71

jehoˇz ˇcást . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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émy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 9.2 Aplikace v OOPN a DEVS v multiagentn´ıch systémech . . . . . . . . . . . 86 9.3 Shrnut´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 10 Dynamick´ e modely v ˇ r´ızen´ı projekt˚ u 93 10.1 Základn´ı pojmy z oblasti ˇr´ızen´ı projekt˚ u . . . . . . . . . . . . . . . . . . . . 93 10.2 Modelován´ı projektového 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áce se zab´ yv´ a vyuˇzit´ım simulace v návrhu a v´ yvoji poˇc´ıtaˇcov´ ych (i kdyˇz nikoliv nutnˇe jen poˇc´ıtaˇcov´ ych) systém˚ u, které jsou pouˇz´ıv´ any v reálném prostˇred´ı, maj´ı tedy definované vstupy a v´ ystupy a pracuj´ı v reálném ˇcase. Zvláˇstn´ı pozornost je pˇritom vˇenována v´ yvoji struktury systém˚ u nejen v pr˚ ubˇehu návrhu a testován´ı, ale i bˇehem reálného pouˇz´ıv´ an´ı a u ´drˇzby. K v´ yvoji struktury systému m˚ uˇze docházet jednak inkremet´ aln´ımi zásahy zvenˇc´ı, jednak automatickou adaptac´ı systému na mˇen´ıc´ı se vnˇejˇs´ı podm´ınky. Modelovac´ı formalismy Problematika vyv´ıjej´ıc´ıch se systém˚ u bude pops´ ana obecnˇe, na u ´rovni abstraktn´ıch model˚ u s rigoróznˇe definovan´ ymi pojmy ˇcas, stav, vstup a v´ ystup. Konkrétn´ı formalismus pro nás nen´ı nijak zavazuj´ıc´ı, d˚ uraz bude kladen na v pˇr´ımou návaznost na pojmy obecné teorie systém˚ u. Jako spoleˇcn´ y základ pro u ´vahy o pouˇzit´ı r˚ uzn´ ych formalism˚ u bude pouˇzit formalismus pro specifikaci systému s diskrétn´ımi událostmi – DEVS (Discrete EVent systems Specification). Tento formalismus je v´ yznamn´ y svou bezprostˇredn´ı vazbou na obecnou teorii systém˚ u a právˇe takovou u ´rovn´ı abstrakce, kter´ a je ideáln´ı pro simulaci a návrh systém˚ u, které jsou pˇredmˇetem naˇseho zájmu (t.j. pˇredevˇs´ım poˇc´ıtaˇcov´ ych systém˚ u libovolného druhu). Ostatn´ı v u ´vahu pˇripadaj´ıc´ı formalismy, jako jsou napˇr. koneˇcné automaty, stavové diagramy (statecharts) a Petriho s´ıtˇe, jsou do DEVS relativnˇe snadno mapovatelné. I systémy jin´ ych typ˚ u, jako jsou spojité systémy a systémy s diskrétn´ım ˇcasem, lze také do DEVS snadno transformovat. DEVS jako spoleˇcn´ y form´ aln´ı základ pro r˚ uzné pˇr´ıstupy k modelován´ı a simulaci usnadˇ nuje transformaci model˚ u, portabilitu, migraci a klonován´ı model˚ u, obecn´ y v´ yvoj nov´ ych simulaˇcn´ıch architektur bez ohledu na konkrétn´ı formalismus nebo specifikaˇcn´ı jazyk. Vyuˇzit´ı formalismu, jako je DEVS, umoˇzn´ı bezprostˇredn´ı provázán´ı teorie modelován´ı a simulace s prax´ı – modely a simul´ atory postavené na form´ aln´ım základˇe a v souladu s teori´ı lze analyzovat jako matematické objekty s vyuˇzit´ım form´ aln´ıch metod a souˇcasnˇe jsou k dispozici k pˇr´ımému praktickému pouˇzit´ı, t.j. jak k simulaˇcn´ım experiment˚ um, tak k bˇehu v c´ılovém prostˇred´ı. V´ yvoj syst´ em˚ u v simulovan´ em a v re´ aln´ em prostˇ red´ı Zvyˇsuj´ıc´ı se nároky na kvalitu a schopnosti vyv´ıjen´ ych systém˚ u, které se v d˚ usledku nar˚ ustaj´ıc´ıch poˇzadavk˚ u stávaj´ı stále sloˇzitˇejˇs´ımi, vede k v´ yvoji nov´ ych metod návrhu, v´ yvoje, implementace a u ´drˇzby systém˚ u. V´ yvoj systém˚ u v simulaci (Simulation-Based Development) je metoda tvorby poˇc´ıtaˇcov´ ych systém˚ u, vyuˇz´ıvaj´ıc´ı d˚ ukladné testován´ı a verifikaci navrhovaného systému ve vˇsech fáz´ıch v´ yvoje, aniˇz by bylo nutné se vázat na reálné okol´ı systému, pˇr´ıpadnˇe na reáln´ y ˇcas. Mimo to je simulace ve fázi návrhu uˇziteˇcn´ a tehdy, kdyˇz pro navrhované systémy

2

´ ´ KAPITOLA 1. UVOD – VYVÍJEJÍCÍ SE SYSTEMY

neexistuje pˇredem jasn´ a specifikace. Zde je nezbytné pouˇz´ıt evoluˇcn´ı návrh, kter´ y spoˇc´ıv´ a v rychlém a bezprostˇredn´ım vytváˇrn´ı, modifikaci, testován´ı, vyhodnocován´ı a porovnáván´ı mnoha kandid´ atn´ıch ˇreˇsen´ı. Podle charakteru hodnot´ıc´ı funkce pak m˚ uˇze evoluce systém˚ u prob´ıhat interaktivnˇe, automaticky, nebo kombinovanˇe. V pˇr´ıpadˇe interaktivn´ıho testován´ı simulovaného produktu jde o tzv. virtuáln´ı prototypován´ı. Podp˚ urná architektura mus´ı pˇr´ısluˇsnou variantu evoluˇcného návrhu systém˚ 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ém v kontaktu s mˇen´ıc´ım se prostˇred´ım a m´ a-li i v pˇredem neznám´ ych podm´ınkách plnit definované c´ıle, je tˇreba jiˇz pˇri návrhu systému zohlednit moˇznost adaptace, v´ yvoje, resp. uˇcen´ı. Adaptace systému na mˇen´ıc´ı se prostˇred´ı m˚ uˇze b´ yt provádˇena bud’ inkrementáln´ımi vnˇejˇs´ımi zásahy z prostˇred´ı, tedy p˚ usoben´ım jiného systému (typicky ˇclovˇeka-v´ yvojáˇre), nebo samostatnˇe, na základˇe autonom´ıho zkoumán´ı prostˇred´ı a uˇcen´ı se. Pˇripust´ıme-li autonomn´ı chován´ı a adaptaci systému v neznámém prostˇred´ı, m´ a smysl o systémech, které jsou pˇredmˇetem naˇseho zkoumán´ı, uvaˇzovat jako o agentn´ıch systémech, resp. jako o inteligentn´ıch agentech. Pak je vhodné zab´ yvat se moˇzn´ ymi agentn´ımi architekturami – systém m˚ uˇze b´ yt realizován jako jednoduch´ y reaktivn´ı agent, kter´ y na základˇe vstupu a aktuáln´ıho stavu jednoduˇse definovanou funkc´ı generuje v´ ystup, nebo m˚ uˇze b´ yt cháp´ an jako agent deliberativn´ı (uvaˇzuj´ıc´ı), jehoˇz stav je jiˇz komplikovanˇeji strukturován a funkce, modifikuj´ıc´ı stav na základˇe aktuáln´ıho stavu a vstupu, pˇr´ıpadnˇe generuj´ıc´ı v´ ystup na základˇe stavu, jsou pomˇernˇe komplikované funkce, specifikované 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é se t´ ykaj´ı návrhu a udrˇzován´ı vyv´ıjej´ıch se systém˚ u. Pˇritom je kladen d˚ uraz na pouˇzit´ı simulace, form´ aln´ıch model˚ u a jejich zachován´ı v pr˚ ubˇehu a v´ yvoje i c´ılového nasazen´ı. Jako motivaˇcn´ı pˇr´ıklady a pˇr´ıpadové studie uvedeme nˇekolik r˚ uznorod´ ych systém˚ u, které spojuje právˇe kontakt s okoln´ı realitou a d˚ uraz na dynamickou manipulaci s modely a simulacemi: (1) Simuluj´ıc´ı systém. V obecném pojet´ı jde o systém, jehoˇz souˇcást´ı je simulace. Simuluje-li systém s´ am sebe a pouˇz´ıv´ a-li v´ ysledky vlastn´ı simulace pro modifikaci svého vlastn´ıho chován´ı v budoucnu, mluv´ıme o reflektivn´ı simulaci. Jde o pˇr´ıpad anticipuj´ıc´ıcho systému, optimalizuj´ıc´ıho své pˇredpokl´ adané budouc´ı chován´ı podle zvolen´ ych kriteri´ı na základˇe násobn´ 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ávislosti 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ém, proto je nutné pouˇz´ıt simulaci. Simulace simuluj´ıc´ıch systém˚ u klade specifické nároky na simulaˇcn´ı systém – 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ému (jednotlivé simulace spouˇstˇet jako procesy OS), nebo v r´ amci simulaˇcn´ıho systému samotného. Prvn´ı moˇznost je snadno dostupná, ale z program´ atorského hlediska tˇeˇzkop´ adn´ a, druhá moˇznost je pohodlnˇejˇs´ı, ale simulaˇcn´ı prostˇred´ı ji mus´ı samo o sobˇe umoˇznit. (2) Inkrementáln´ı v´ yvoj ˇr´ıdic´ıho systému autonom´ıho mobiln´ıho robota v simulovaném prostˇred´ı. Jde o v´ yvoj systému, jehoˇz specifikace nen´ı na poˇcátku v´ yvoje zcela jasn´ a a je ji tˇreba dodateˇcnˇe upˇresˇ novat na základˇe v´ ysledk˚ u test˚ u, provádˇen´ ych na pokusn´ ych ˇ ıdic´ı systém autonomn´ıho mobiln´ıho robota je vhodné realizac´ıch v r˚ uzn´ ych prostˇred´ıch. R´ vyv´ıjet a testovat v simulovaném prostˇred´ı dˇr´ıve, neˇz pˇristoup´ıme k testován´ı v prostˇred´ı

3 reálném. Simulovat pˇritom lze i tvrdˇs´ı podm´ınky, neˇz jaké oˇcekáváme v reálném prostˇred´ı, pˇr´ıpadnˇe podm´ınky, které sice oˇcekáváme, ale jsou reálnˇe tˇeˇzko vytvoˇritelné. V pˇr´ıpadˇe, ˇze nen´ı jasn´ y ani okamˇzik, kdy je c´ılov´ y produkt prohláˇsen za hotov´ y, mus´ıme pˇripustit i dodateˇcn´ y v´ yvoj pˇri bˇeˇzném provozu v c´ılovém prostˇred´ı. Aby bylo moˇzné ˇr´ıdic´ı systém inkrementálnˇe vyv´ıjet jak v simulovaném, tak v reálném prostˇred´ı, je nezbytné zachovat model ˇr´ızen´ı v pr˚ ubˇehu celého v´ yvoje, vˇcetnˇe c´ılového nasazen´ı. Souˇcást´ı c´ılové realizace pak mus´ı b´ yt interpret formalismu, v kterém byl model vytvoˇren. Souˇcasnˇe mus´ı b´ yt tento interpret zpˇr´ıstupnˇen pro monitorován´ı stavu a pro inkrementáln´ı zásahy v´ yvojáˇre – typicky vzd´ alenˇe, napˇr. s vyuˇzit´ım webov´ ych sluˇzeb. ˇ ızen´ı projektového portfolia, jeho optimalizace a monitorován´ı. Projektové port(3) R´ folio je mnoˇzina aktuálnˇe bˇeˇz´ıc´ıch a pl´ anovan´ ych projekt˚ u. Modely (rámcové pl´ any) projekt˚ u, specifikované napˇr. s´ıt’ov´ ymi grafy nebo ˇcasovan´ ymi Petriho s´ıtˇemi, se pouˇz´ıvaj´ı k optimalizaci mechanismu pˇridˇelován´ı zdroj˚ u (rozvrhován´ı) a k pr˚ ubˇeˇznému monitorován´ı pr˚ ubˇehu projektu. Jak v rámci optimalizace, tak v pr˚ ubˇehu monitorován´ı se vyuˇz´ıv´ a simulace. V rámci optimalizace je tˇreba simulovat mnoho kandidatn´ıch model˚ u a na základˇe vyhodnocen´ı v´ ysledk˚ u vybrat model, kter´ y nejlépe vyhovuje zadan´ ym kriteri´ım. V rámci monitorován´ı se pak porovnává simulace pl´ anovaného pr˚ ubˇehu projektu s realitou. Postupem ˇcasu se mˇen´ı jak projektové portfolio (tj. mnoˇzina aktuáln´ıch projekt˚ u), tak struktura dostupn´ ych zdroj˚ u. Model celého systému se proto mus´ı adekvátn´ım zp˚ usobem pr˚ ubeˇznˇe pˇrizp˚ usobovat takto se mˇen´ıc´ım vnˇejˇs´ım podm´ınk´ am. Obdobné (v mnohém tytéˇz) problémy se ˇreˇs´ı v souvislosti se systémy pl´ anován´ı a ˇr´ızen´ı v´ yroby. Reflektivn´ı a meta´ urovˇ nov´ e architektury Uvedené pˇr´ıklady demonstruj´ı v´ yznamn´ y aspekt celé tˇr´ıdy podobn´ ych systém˚ u, kter´ ym je nutnost zab´ yvat se kromˇe základn´ı (aplikaˇcn´ı) u ´rovnˇe také meta´ urovn´ı, tedy systémem popisuj´ıc´ım v´ yvoj tˇechto systém˚ u. Na této u ´rovni sledujeme pˇrechody mezi doˇcasnˇe existuj´ıc´ımi d´ılˇc´ımi systémy. Z praktického hlediska je tˇreba v se v uvedeném kontextu zab´ yvat kromˇe vz´ ajenného provázán´ı reality a simulace (reality-in-the-loop simulation) také meta´ urovˇ novou architekturou a reflektivn´ım rozhran´ım smul´ atoru, aby bylo moˇzné s modely a simulacemi dynamicky (to jest za bˇehu) manipulovat v souladu s teori´ı a bez ohledu na to, zda aktorem této manipulace je vnˇejˇs´ı systém nebo manipulovan´ y systém s´ am. Souvislosti Meta´ urovˇ nové a reflektivn´ı architektury patˇr´ı k základ˚ um poˇc´ıtaˇcové vˇedy a jsou neodmyslitelnou souˇcást´ı informaˇcn´ıch technologi´ı. V oblasti teoretick´ ych základ˚ u stoj´ı za zm´ınku pˇredevˇs´ım Goedel˚ uv d˚ ukaz ne´ uplnosti form´ aln´ıho systému a Turing˚ uv univerz´ aln´ı stroj, pouˇzit´ y v d˚ ukazu nerozhodnutelnosti problému zastaven´ı. V oblasti vˇedy o systémech se napˇr. Klir zab´ yv´ a existenc´ı metasystém˚ u, popisuj´ıc´ıch v´ yvoj systém˚ u. Z informaˇcn´ıch technologi´ı stoj´ı za zm´ınku obecné operaˇcn´ı systémy coˇz jsou jsou vesmˇes systémy s meta´ urovˇ novou a reflektivn´ı architekturou – umoˇzn ˇuj´ı vytváˇren´ı a manipulaci s programy a procesy, pˇriˇcemˇz aktory takové manipulace jsou bˇeˇz´ıc´ı procesy ˇr´ızené existuj´ıc´ımi programy. Co do ideové ˇcistoty jsou zaj´ımavé systémy, zaloˇzené na dynamick´ ych jazyc´ıch, jako jsou LISP a Smalltalk, pˇr´ıpadnˇe na jazyc´ıch, které jsou LISPem a Smalltalkem inspirovány. Zm´ınˇené systémy jsou schopné 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ákladˇe interakce s uˇzivatelem. V´ yvoj systému za bˇehu na základˇe interakce s v´ yvojáˇrem je kl´ıˇcov´ ym pˇredpokladem pro

´ ´ KAPITOLA 1. UVOD – VYVÍJEJÍCÍ SE SYSTEMY

4

techniku v´ yvoje, zvanou experimentáln´ı programován´ı (exploratory programming).1 V oblasti umˇelé inteligence je sebemodifikace základn´ım pˇredpokladem schopnosti systému uˇcit se. Hlavn´ım c´ılem tohoto textu je popsat fenomén vyv´ıjej´ıch se systém˚ u v kontextu simulaˇcn´ıho modelován´ı 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áˇren´ı i v rámci u ´drˇzby a adaptace poˇc´ıtaˇcov´ ych systém˚ u na mˇen´ıc´ı se podm´ınky bˇehem jejich ˇzivota. Takové zpr˚ uhlednˇen´ı vyv´ıjen´ ych systém˚ u i metod jejich v´ yvoje by mˇelo b´ yt u ´ˇcinn´ ym prostˇredkem ke zv´ yˇsen´ı jejich uˇzitné hodnoty. Obsah N´ asleduj´ıc´ı text je organizován takto: Po obecném u ´vodu do modelován´ı a simulace systém˚ u s d˚ urazem na systémy s diskrétn´ımi událostmi je pops´ ana problematika systém˚ u s dynamicky se mˇen´ıc´ı strukturou. Poté je definována abstraktn´ı architektura pro simulaci vyv´ıjej´ıc´ıch se systém˚ u. N´ asleduje diskuse praktick´ ych aspekt˚ u definované architektury, spolu s metodick´ ymi poznámkami. Nakonec jsou uvedeny jednoduché pˇr´ıpadové studie, demonstruj´ıc´ı aplikaci simulace v návrhu a realizaci vyv´ıjej´ıch se systém˚ u.

1ˇ

Cesk´ y pˇreklad nen´ı pˇresn´ y, ale v daném kontextu je pouˇziteln´ y.

Kapitola 2

Syst´ emy s diskr´ etn´ımi ud´ alostmi Kapitola prezentuje systémy s diskrétn´ımi událostmi, které jsou vhodnou abstrakc´ı pro modelován´ı poˇc´ıtaˇcov´ ych (ale nejen poˇc´ıtaˇcov´ ych) systém˚ u v rámci jejich návrhu a v´ yvoje. Adekv´ atnost tohoto zp˚ usobu modelován´ı je opodstatnˇena t´ım, ˇze jako systémy s diskrétn´ımi událostmi lze modelovat vˇsechny typy dynamick´ ych systém˚ u (t.j. systém˚ u, u nichˇz m´ a smysl zkoumat chován´ı) a tedy vˇsechny zp˚ usoby aplikac´ı vyv´ıjen´ ych systém˚ u. V návaznosti na základn´ı pojmy teorie systém˚ u a teorie modelován´ı a simulace je v následuj´ıc´ıch podkapitol´ ach pˇredstaven formalismus DEVS a jeho abstraktn´ı simul´ ator. Pro ilustraci pˇr´ımé vazby teorie a praxe modelován´ı a simulace je prezentována i ukázka praktického pouˇzit´ı formalismu DEVS v konkrétn´ım programovac´ım jazyce.

2.1

Syst´ emy, znalosti, probl´ emy

Klir [Kli85] definuje r´ amec pro studium systém˚ u, ve kterém rozliˇsuje 4 epistemologické u ´rovnˇe, reflektuj´ıc´ı dostupné znalosti o systému. Kaˇzd´ au ´roveˇ n zahrnuje znalosti dostupné 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é nás 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émy jsou schopny generovat ˇcasové ˇrady (time series), proto se také naz´ yvaj´ı generativn´ı systémy. ´ 3. Uroveˇ n struktury (structure level, staructural system) zahrnuj´ı znalost o subsystémech systému a o struktuˇre jej´ıch vz´ ajemn´ıch vztah˚ u (propojen´ı). Tuto hierarchii zavrˇsuje pát´ a u ´roveˇ n - u ´roveˇ n metasystém˚ u, které obsahuj´ı informaci o tom, jak se datové, generativn´ı a strukturn´ı systémy vyv´ıjej´ı v ˇcase. Na této u ´rovni nás zaj´ımá dynamika samotného popisu systému. Ve v´ yˇse uvedeném kontextu existuj´ı 3 typy problém˚ u k ˇreˇsen´ı [Kli85]: 1. Analýza systému. Systém bud’ existuje, nebo je pl´ anována jeho existence a pokouˇs´ıme se pochopit jeho chován´ı. Za pouˇzit´ı generativn´ıho popisu ziskáváme a zkoumáme data.

´ ´ ÍMI UDALOSTMI ´ KAPITOLA 2. SYSTEMY S DISKRETN

6

2. Inference systému. Systém 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ému. Systém neexistuje a snaˇz´ıme se ho navrhnout. Pˇrecház´ıme na vyˇsˇs´ı u ´roveˇ n znalost´ı, od existuj´ıc´ıch generativn´ıch komponent ke sloˇzenému systému s vhodnou strukturou. Zat´ımco Klir [Kli85] uvedenou hierarchii znalost´ı definuje pˇredevˇs´ım jako rámec pro zkoum´ an´ı moˇznosti induktivn´ı identifikace systém˚ u (odvozován´ı 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ém˚ u, které se daj´ı uplatnit v modelovac´ıch a simulaˇcn´ıch jazyc´ıch. Zab´ yvaj´ı se pˇredevˇs´ım u ´rovn´ı struktury a chován´ı s c´ılem generovat data. Diskutovanou ot´ azkou i v této oblasti je u ´roveˇ n metasystém˚ u, tedy moˇznost specifikovat a simulovat vyv´ıjej´ıc´ı se generativn´ı systémy. ´ cinn´ Uˇ ym prostˇredkem pro anal´ yzu chován´ı systém˚ u je simulace. Modelován´ı a simulaci systém˚ u, zvláˇstˇe pak systém˚ u s diskrétn´ımi událostmi, se vˇenuj´ı následuj´ıc´ı ˇcásti kapitoly.

2.2

Simulaˇ cn´ı modelov´ an´ı

Základn´ı rámec pro modelován´ı a simulaci je podle [ZKP00] definován ˇctyˇrmi entitami (viz obr. 2.1): 1. Zdrojový systém (source system) pˇredstavuje zdroj dat (chován´ı). 2. Model pˇredstavuje instrukce pro generován´ı dat srovnateln´ ych s reáln´ ym systémem. 3. Simul´ ator provád´ı instrukce modelu a skuteˇcnˇe generuje chován´ı. 4. Experiment´ aln´ı r´ amec (experimental frame) specifikuje podm´ınky, za kter´ ych systém pozorujeme a exeperimentujeme se s n´ım. Experimental Frame

Simulator Source System Simulation Relation Modeling Relation

Model

Obrázek 2.1: Základn´ı entity a jejich vztahy Základn´ı vztahy mezi tˇemito entitami jsou modelov´ an´ı a simulace. Relace modelován´ı pˇritom specifikuje, jak model reprezentuje odpov´ıdaj´ıc´ı reáln´ y systém. Mezi systémem a modelem mus´ı b´ yt homomorfn´ı vztah, tj. je pˇr´ıpustné 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ého systému k modelu m˚ uˇze b´ yt proveden na základˇe pozorován´ı dat z´ıskan´ ych z experiment˚ u se systémem. Model je pak pouˇzit k vytvoˇren´ı simul´ atoru, kter´ y slouˇz´ı ke generován´ı dat. Chován´ı, generované simul´ atorem, mus´ı b´ yt validn´ı, tj. simul´ ator mus´ı generovat stejn´ a nebo podobná data jako zdrojov´ y systém za stejn´ ych podm´ınek.

2.3

ˇ Cas, trajektorie a segmenty

ˇ je Základn´ım pojmem dynamického systému je ˇcas, kter´ y je nez´ avislou veliˇcinou. Cas definovován strukturou time = (T, <), kde

T je mnoˇzina, < je tranzitivn´ı, irreflexivn´ı a antisymetrická relace (uspoˇrád´ 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é) uspoˇra ´d´ an´ı. Relaci < definujeme typicky jako line´ arn´ı uspoˇrád´ an´ı, ale v nˇekter´ ych pˇr´ıpadech je vhodné pracovat i s ˇcásteˇcn´ ym uspoˇrád´ an´ım, které m˚ uˇze modelovat ˇ neurˇcitost v popisu systému a násobnost 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étn´ı ˇcasovou z´ akladnu). Nad T definujeme intervaly: (t1 , t2 ) = {τ |t1 < τ < t2 , τ ∈ T }, [t1 , t2 ] = {τ |t1 ≤ τ ≤ t2 , τ ∈ T }, (t1 , t2 ] = {τ |t1 < τ ≤ t2 , τ ∈ T }. Zápis < t1 , t2 > oznaˇcuje libovoln´ y z interval˚ u. Intervaly nad T nˇekdy znaˇc´ıme T . Je-li T ˇcasová základna a A libovolná 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ény na sebe navazuj´ı. Spojitý segment nad spojitou ˇcasovou základnou je spojit´ y ve vˇsech bodech. Po ˇca ´stech spojitý segment je spojit´ y ve vˇsech bodech kromˇe koneˇcného poˇctu bod˚ u. Po ˇca ´stech konstantn´ı segment je speciáln´ı pˇr´ıpad po ˇcástech spojitého segmentu. Ud´ alostn´ı segment ω :< t0 , tn >−→ A∪{∅} je segment nad spojitou ˇcasovou základnou a mnoˇzinou událost´ı A ∪ {∅}, kde ∅ znaˇc´ı ne-ud´ alost. ∅ je hodnotou ω mezi jednotliv´ ymi událostmi z mnoˇziny A, které se vyskytly v ˇcasech t1 , t2 , ..., tn−1 . Segment nad diskrétn´ı ˇcasovou základnou se naz´ yv´ a sekvence.

2.4

Syst´ em

Systém je abstraktn´ı koncept, popisuj´ıc´ı chován´ı entit v ˇcase.1 Popisuje v´ ystupn´ı chován´ı na základˇe vstupu a stavové informace. Formálnˇe je systém pops´ an strukturou [ZKP00] S = (T, X, Ω, Q, q0 , Y, δ, λ), 1

Uvaˇzujeme dynamick´ y systém na u ´rovni 2 Klirovy hierarchie.


8 kde

T je ˇcasová základna, 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áteˇcn´ı stav, δ : Q × Ω −→ Q je pˇrechodová funkce, λ : Q × X −→ Y je v´ ystupn´ı funkce.

Systém pˇritom splˇ nuje následuj´ıc´ı omezen´ı: (1) Ω je uzavˇren´ a vzhledem ke kompozici; (2) pro kaˇzd´ y pár soused´ıc´ıch segment˚ u ω, ω ′ ∈ Ω a pro vˇsechny stavy q ∈ Q plat´ı: ′ δ(q, ωω ) = δ(δ(q, ω), ω). Omezen´ı (2) zaruˇcuje, ˇze systém m˚ uˇze b´ yt pˇreruˇsen v libovolném ˇcase a jeho stav je registrován. Pokraˇcován´ı z tohoto stavu s pokraˇcován´ım vstupn´ıho segmentu povede do stejného koncového stavu, jako kdyby k pˇreruˇsen´ı nedoˇslo. Typy syst´ em˚ u Zeigler [ZKP00] definuje 3 základn´ı modelovac´ı formalismy, resp. typy systém˚ u: Systém popsaný diferenci´ aln´ımi rovnicemi, systém s diskrétn´ım ˇcasem a systém s diskrétn´ımi ud´ alostmi. Poslednˇe jmenovan´ y formalismus (DEVS, kter´ y bude pops´ an v následuj´ıc´ım textu) m˚ uˇze b´ yt modifikován nebo pˇr´ımo pouˇzit pro modelován´ı ostatn´ıch typ˚ u systém˚ u. Systém popsan´ y diferenci´ aln´ımi rovnicemi m˚ uˇze b´ yt s vyuˇzit´ım vhodného vzorkován´ı a metod numerické integrace pˇreveden na systém s diskrétn´ım ˇcasem. Systém s diskrétn´ım ˇcasem m˚ uˇze b´ yt cháp´ an jako zvláˇstn´ı pˇr´ıpad systému s diskrétn´ımi událostmi. DEVS je tedy univerz´ aln´ı, a proto tento formalismus povaˇzujeme za ideáln´ı n´ızko´ urovˇ novou abstrakci, vhodnou pro vˇsechny typy systém˚ u. Jiné (speciálnˇejˇs´ı, pˇr´ıpadnˇe vysoko´ urovˇ novˇejˇs´ı) formalismy je moˇzné do DEVS relativnˇe snadno transformovat.

2.5

Formalismus DEVS

DEVS je zkratka pro Discrete EVent System Specification, tedy specifikaci systému s diskrétn´ımi událostmi [ZKP00]. Pro tento formalismus je definován abstraktn´ım simul´ ator, kter´ y lze kromˇe specifikace sémantiky chápat také jako vzor pro reálnou implementaci.

2.5.1

Syst´ em s diskr´ etn´ımi ud´ alostmi

Neform´ alnˇe lze systém s diskrétn´ımi událostmi popsat následuj´ıc´ım zp˚ usobem. Systém m´ a vstupy a v´ ystupy pozorovatelné jako události. Na nˇekteré vstupy systém reaguje v´ ystupem (okamˇzitˇe nebo se zpoˇzdˇen´ım), na nˇekteré viditelnˇe nereaguje (jen pˇrecház´ı mezi vnitˇrn´ımi stavy). Nˇekdy generuje v´ ystup bez pˇr´ımé vnˇejˇs´ı pˇr´ıˇciny. Uvnitˇr systém pˇrecház´ı mezi vnitˇrn´ımi stavy, a to bud’ samovolnˇe (poté, co v daném stavu strávil jist´ y ˇcas), nebo na základˇe vnˇejˇs´ı události (události na vstupu). V´ ystup vˇzdy závis´ı jen na aktuáln´ım stavu a je pozorovatlen´ y jako událost pˇri samovolném pˇrechodu systému do stavu následuj´ıc´ıho. Na obr. 2.2 je zobrazen vstupn´ı událostn´ı segment (x), stavová trajektorie (s), trajektorie uplynulého ˇcasu (e) pro aktuáln´ı stav a v´ ystupn´ı událostn´ı segment (y).

2.5. FORMALISMUS DEVS

9 x1

x2

x

t s

t e

t y

y1

t0

t1

t2

t3

t

ˇ Obrázek 2.2: Casov´ e segmenty systému s diskrétn´ımi událostmi ˇ Souvislost s obecnou definic´ı syst´ emu Casov´ a základna systému s diskrétn´ımi událostmi je T = R0+ . Vstupn´ı a v´ ystupn´ı segmenty jsou událostn´ı segmenty. Je-li S je mnoˇzina stav˚ u, stavová trajektorie je po ˇcástech konstantn´ı segment nad S a T . Podle obecné definice systému mus´ı stav registrovat i dobu setrv´ aván´ı 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é stavem a ˇcasem setrv´ aván´ı systému ve stavu s. Tot´ aln´ı stavová trajektorie je po ˇcástech spojit´ y segment nad Q a T .

2.5.2

Z´ akladn´ı model

Z´ akladn´ı model je specifikován 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ýstupn´ı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ých stav˚ u, e je ˇcas uplynulý od posledn´ı ud´ alosti, λ : S −→ Y je výstupn´ı funkce,


10

ta : S −→ R0+ ∪ {∞} je funkce posuvu ˇcasu. Interpretace formalismu Systém je v daném okamˇziku ve stavu s ∈ S. Nevyskytne-li se ˇzádn´ a extern´ı událost, systém setrv´ a ve stavu s p o dobu ta(s) time. Zvláˇstn´ı hodnotou ta(s) je symbol ∞ – v takovém pˇr´ıpadˇe je systém 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ém zmˇen´ı stav na δint (s). Vyskytne-li se extern´ı událost x ∈ X v ˇcase e ≤ ta(s), systém 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ést ve stejném ˇcasovém okamˇziku) se provede pouze extern´ı pˇrechod. Atomick´ y model Uveden´ y formalismus umoˇzn ˇuje specifikovat jak´ ykoli systém s diskrétn´ımi událostmi. Chápeme-li ale systém jako hierarchickou strukturu, v´ yˇse uvedená definice odpov´ıd´ a specifikaci atomickému modelu, základn´ı nedˇelitelné jednotce systému. Pˇr´ıklady mohou b´ yt gener´ ator, procesor, fronta, bin´ arn´ı ˇc´ıtaˇc apod. Systémy sloˇzené ze subsystém˚ u pak specifikujeme jako sloˇzené modely.

2.5.3

Sloˇ zen´ y model

Dalˇs´ım konceptem formalismu DEVS je hierarchie – systém m˚ uˇze b´ yt dekomponován do subsystém˚ u. Subsystémy 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álost´ı. Stav sloˇzeného systému je pak urˇcen stavy vˇsech jeho subsystém˚ u. Sloˇzen´ım a propojen´ım systém˚ u vznikne opˇet systém. Sloˇzený model je definován strukturou Nself = (X, Y, D, {Md }, {Id }, {Zi,d }, select) kde

X je mnoˇzina vstupn´ıch ud´ alost´ı, Y je mnoˇzina výstupn´ı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álosti modelu i na vstupn´ı událost modelu d. self identifikuje sloˇzen´ y model N . Funkce select se pouˇz´ıv´ a k ˇreˇsen´ı konfliktu souˇcasn´ ych událost´ı – vyb´ır´ a jeden submodel z mnoˇziny submodel˚ u, ve kter´ ych je aktuálnˇe provediteln´ y intern´ı pˇrechod.

2.5. FORMALISMUS DEVS

11

Uzavˇ renost vzhledem ke skl´ ad´ an´ı Mnoˇzina systém˚ 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ákladn´ı DEVS. Tato vlastnost byla form´ alnˇe dokázána 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álosti je moˇzné specifikovat jako strukturované mnoˇziny, coˇz nám umoˇzn´ı pouˇz´ıt libovoln´ y poˇcet vstupn´ıch a v´ ystupn´ıch port˚ u a libovoln´ y poˇcet stavových promˇenných. Strukturovan´ a mnoˇzina S = (V, S1 × S2 ×, ... × Sn ) je definována mnoˇzinou promˇenn´ ych V , |V | = n, a kartézsk´ 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ána 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é mnoˇziny, specifikaci propojen´ı lze definovat mezi jednotliv´ ymi porty jednotliv´ ych model˚ u a funkci pˇrekladu událost´ı definovat jako identitu. Toto zjednoduˇsen´ı specifikace sloˇzeného modelu je snadno prakticky pouˇzitelné a je skuteˇcnˇe pouˇzito ve vˇsech reáln´ ych implementac´ıch formalismu DEVS. N´ asleduje form´ aln´ı definice toho typu specifikace sloˇzeného 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ýstupn´ı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 ,


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ýstupn´ıch propojen´ı, select : 2D − {} −→ D je preferenˇcn´ı funkce a jsou splnˇena následuj´ı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é varianty a modifikace DEVS, jako je paraleln´ı DEVS, celulárn´ı DEVS, symbolick´ y DEVS, fuzzy DEVS, nebo DEVS s dynamickou strukturou. Existuje také moˇznost mapován´ı jin´ ych formalism˚ u do DEVS. Takto lze mapovat napˇr. koneˇcné automaty, Petriho s´ıtˇe, stavové diagramy, ale i diferenci´ aln´ı rovnice (prostˇrednictv´ım numerické integrace). DEVS lze tedy chápat jako spoleˇcn´ y základ pro multiparadigmatické modelován´ı a simulaci [ZKP00].

2.6

Hierarchick´ a simulace DEVS (abstraktn´ı simul´ ator)

Simulace DEVS je organizována 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ého modelu, je podˇr´ızen nadˇrazenému simul´ atoru a m˚ uˇze m´ıt podˇr´ızené 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ázek 2.3: Mapován´ı mezi modely a simul´ atory simulaci slouˇz´ı zpr´ avy (viz obr. 2.4): • (i, t) - inicializaˇcn´ı zpr´ avy pos´ılá nadˇrazen´ y simul´ ator podˇr´ızen´ ym pˇri odstartován´ı simulace,

´ SIMULACE DEVS (ABSTRAKTNÍ SIMULATOR) ´ 2.6. HIERARCHICKA

13

• (∗, t) - pokyn nadˇrazeného simul´ atoru podˇr´ızenému k vygenerován´ı v´ ystupu a proveden´ı intern´ıho pˇrechodu pl´ anovaného na ˇcas t, • (y, t) - v´ ystupn´ı zpr´ avy pos´ılá podˇr´ızen´ y simul´ ator nadˇrazenému (nadˇrazen´ y simluátor je zopdpovˇedn´ y za jejich pˇr´ıpadnou distribuci), • (x, t) - vstupn´ı zpr´ avy pos´ılá 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ému dokonˇcen´ı zpracován´ı zpr´ avy (i, t), (∗, t), nebo (x, t) a oznamuje ˇcas proveden´ı následuj´ı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ázek 2.4: Zprávy pouˇz´ıvané pˇri simulaci DEVS Kaˇzd´ y simul´ ator udrˇzuje informaci o ˇcase posledn´ı události tlast a ˇcase následuj´ıc´ı pl´ anované události tnext , je schopen provést pl´ anovanou událost a reagovat na vstupn´ı událost. Simul´ ator sloˇzeného modelu (Coordinator) udrˇzuje tnext pro vˇsechny submodely, deleguje na nˇe provádˇen´ı událost´ı a distribuuje události 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ádˇen´ı jednotliv´ ych krok˚ u simulace. D´ ale uvedené algoritmy vycházej´ı z [ZKP00] a [Van00]. Abstraktn´ı koˇ renov´ y simul´ ator Koˇrenov´ y simul´ ator je zodpovˇedn´ y za postupné provádˇen´ı krok˚ u simulace. Je spuˇstˇen s parametry podˇr´ızen´ y simul´ ator child, ˇcas zaˇcátku a konce simulace tBEGIN , tEN D . Pouˇz´ıv´ a promˇenné t a tnext . Algoritmus: t := tBEGIN poˇsli (i, t) podˇr´ızenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child t := tnext dokud t < tEN D opakuj: poˇsli (∗, t) podˇr´ızenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child t := tnext

14


Abstraktn´ı simul´ ator atomick´ eho modelu M = (X, S, Y, δint , δext , λ, ta) pouˇz´ıv´ a promˇenné tlast , tnext , y, u ´pln´ y stav (s, e) a parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazeného simul´ atoru parent reaguj takto: tlast := t − e tnext := tlast + ta(s) poˇsli (done, tnext ) nadˇrazenému simul´ atoru parent Na zpr´ avu (∗, t) od nadˇrazeného simul´ atoru parent reaguj takto: y := λ(s) poˇsli (y, t) nadˇrazenému simul´ atoru parent s := δint (s) tlast := t tnext := tlast + ta(s) poˇsli (done, tnext ) nadˇrazenému simul´ atoru parent Na zpr´ avu (x, t) od nadˇrazeného 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ému 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é tlast , tnext , y, eventList, imminent, d, receivers, activeChildren a parent. Algoritmus: Na zpr´ avu (i, t) od nadˇrazeného 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ého 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ému simul´ atoru Na zpr´ avu (∗, t) od nadˇrazeného 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 ˇ Í FORMALISMU DEVS 2.7. PRAKTICKE

15

Na zpr´ avu (y, t) od podˇr´ızeného 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ému 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ého 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án 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ásledného pokraˇcován´ı simulace (vˇcetnˇe moˇznosti klonován´ı a migrace) za pˇredpokladu, ze mezit´ım nedojde k manipulaci se strukturou. Pro potˇreby dynamické 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áln´ ym okol´ım. Tato problematika bude diskutována v kapitole 4. Paraleln´ı a distribuovan´ a simulace Simulaci lze paralelizovat a distribuovat. V tomto pˇr´ıpadˇe je vhodné pouˇz´ıt paraleln´ı variantu DEVSu, která se nepatrnˇe liˇs´ı od klasické varianty. Tato varianta poˇc´ıt´ a s moˇznost´ı souˇcasn´ ych událost´ı na vstupech model˚ u a je pops´ ana v [ZKP00]. Pro dalˇs´ı v´ yklad nen´ı podstatné, o kterou variantu jde. Proto bude pro jednoduchost pouˇzita varianta klasická.

2.7

Praktick´ e pouˇ zit´ı formalismu DEVS

DEVS byl v dobˇe svého vzniku urˇcen k tomu, aby bylo moˇzné form´ alnˇe popsat a pracovat modely, které se pak obvykle implementovaly bˇeˇzn´ ym zp˚ usobem, typicky v událostnˇe orientovaném 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é knihovny pro bˇeˇzné programovac´ı jazyky, jako je LISP, C, C++, Java, Smalltalk apod. Existuje ˇrada implementac´ı DEVS, jako pˇr´ıklady lze uvést ADEVS (University of Arizona), CD++ (Carleton University), DEVS/HLA (ACIMS), DEVSJAVA (ACIMS), GALATEA (USB Venezuela), GDEVS (Aix-Marseille III, France), JDEVS (Université de


16

Corse - France), PyDEVS (McGill), PowerDEVS (University of Rosario, Argentina), SimBeans (University of Linz, Austria), VLE (Université du Litoral -France), SmallDEVS (Brno University of Technology, Czech Republic), James (University of Rostock, Germany).2 V souˇcasné 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é dobˇe existuj´ı pro objektovˇe orientované jazyky C++ a Java. Implementace DEVS v objektovˇe orientovaném jazyce zaloˇzeném na tˇr´ıd´ ach vede k typickému zp˚ usobu modelován´ı, kde modely jsou vytváˇreny jako podtˇr´ıdy existuj´ıc´ıch tˇr´ıd (model˚ u). Podtˇr´ıda definuje instanˇcn´ı promˇenné pro reprezentaci stavu a redefinuje metody, odpov´ıdaj´ıc´ı funkc´ım δext , λ, δint , ta atomického 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é 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ého pouˇzit´ı formalismu DEVS pro tvorbu simulaˇcn´ıch model˚ u bude uveden jednoduch´ y pˇr´ıklad, demonstruj´ıc´ı pˇr´ımé mapován´ı matematického 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án´ı totoˇzn´ y, liˇs´ı se jen v pouˇzitém programovac´ım jazyku a v názvech 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é. Pˇ r´ıklad Specifikujme hráˇ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élisation, 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ého pˇr´ıstupu k objektové orientaci, zaloˇzeného na tˇr´ıd´ ach, také 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ého 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é lze tedy jednoduˇse adaptovat pro libovoln´ yz alternativn´ıch n´ astroj˚ u. 4 Specifikaci systému jsme rozˇs´ıˇrili o poˇc´ ateˇcn´ı stav s0 ∈ S.


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é funkce (intern´ı a extern´ı), v´ ystupn´ı funkci a poˇcáteˇ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áˇc by mˇel b´ yt v poˇcáteˇcn´ım stavu pasivn´ı, od prvn´ıho se liˇs´ı jen poˇcáteˇcn´ım stavem: InitiallyP assiveP ingP ongP layer = (X, S, Y, δint , δext , λ, ta, s0 ), kde

X, S, Y, δint , δext , λ, ta jsou definovány stejnˇe jako v modelu P ingP ongP layer, s0 = receive.

V objektovˇe orientované 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á nstavuje poˇcáteˇcn´ı stav.

PingPongPlayer subclass : #InitiallyPassivePingPongPlayer initialize super i n i t i a l i z e . phase ←#receive .

Systém dvou hráˇc˚ u je specifikován jako sloˇzen´ y DEVS P ingP ong = (X, Y, D, {Md }, EIC, IC, EOC, select),

18 kde


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ého 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á koˇrenov´ ym simul´ atorem je vytvoˇrena následuj´ıc´ım kódem – ten souˇcasnˇe odstartuje simulaci.

PingPong new getSimulator simulate : 1.5.

Pr˚ ubˇeh simulace je zaznamen´ an jako sekvence událost´ı a zmˇen stavu. Na obr´ azku 2.5 je orientaˇcn´ı textov´ y záznam, generovan´ y bˇehem simulace, existuje ale moˇznost generovat záznam v XML pro pˇr´ıpadné dalˇs´ı zpracován´ı. Uveden´ y pˇr´ıklad demonstruje pouˇzit´ı formalismu DEVS pro vytvoˇren´ı modelu a následné simulaˇcn´ı ovˇeˇren´ı jeho spr´ avné funkce (anal´ yzou logu lze z´ıskat potˇrebné informace o chován´ı systému). Existuje samozˇrejmˇe moˇznost pouˇzit´ı model˚ u na bázi DEVS k jin´ ym u ´ˇcel˚ um, napˇr. pro stochastickou simulaci. V takovém pˇr´ıpadˇe je tˇreba pr˚ ubˇeˇznˇe sb´ırat data o vyuˇzit´ı zdroj˚ u, délkách front apod. Jinou moˇznost´ı je simulace v reálném ˇcase, propojen´ a s reáln´ ym okol´ım. K tomu je tˇreba zajistit komunikaci modelu s okol´ım a synchronizovat simulaci s reáln´ ym ˇcasem. Model pak chápeme jako program s reáln´ ymi vstupy a v´ ystupy. V´ yhodou tohoto zp˚ usobu programován´ı je konformita programu s pouˇzit´ ym formalismem, coˇz vytváˇr´ı prostor pro aplikaci matematick´ ych metod pro anal´ yzu a verifikaci. Moˇznost simulace systému v simulovaném prostˇred´ı pak umoˇzn ˇuje d˚ ukladné testován´ı vyv´ıjeného systému v pr˚ ubˇehu v´ yvoje. Tomuto zp˚ usobu v´ yvoje systém˚ 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ému vyuˇzit´ı simulaˇcn´ıho modelován´ı bude pops´ an v kapitole 5.


****************** 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ázek 2.5: Záznam pr˚ ubˇehu simulace

19

20


Kapitola 3

Syst´ emy s dynamicky se mˇ en´ıc´ı strukturou Systémy, u kter´ ych se pˇredpokl´ ad´ a adaptace a v´ yvoj, chápeme obecnˇe jako systémy s dynamickou strukturou. Modelován´ı a simulace takov´ ych systém˚ u mus´ı nutnˇe zahrnout fenomény 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án´ı o moˇznost vyjádˇrit reflektivn´ı vlastnosti systému. Princip systémové reflexe tkv´ı v tom, ˇze systém vid´ı svoji vlastn´ı specifikaci a je schopen do n´ı dynamicky zasahovat. Tyto zásahy jsou systémem bezprostˇrednˇe reflektovány, tj. maj´ı okamˇzit´ y vliv na jeho strukturu a chován´ı. Problematikou reflexe v softwarov´ ych systémech se zab´ yv´ a ˇrada autor˚ u, napˇr. [Mae87, MMWY92, Paw98, TUN06, LRS01]. V oblasti form´ aln´ıch model˚ u systém˚ u s diskrétn´ımi událostmi lze uvést vyv´ıjej´ıc´ıc´ı se Petriho s´ıtˇe [ABPD96] a r˚ uzné 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étnˇe implementován napˇr. v ADEVS, Dynamic DEVS (kter´ y bude uveden v následujc´ıc´ım textu) je definován obecnˇeji – dynamika je moˇzn´ a i na u ´rovni atomick´ ych model˚ u. Definice Dynamic DEVS zavád´ı strukturn´ı pˇrechody, které 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é zavádˇej´ı strukturn´ı dynamiku, plat´ı, ˇze systém s mˇen´ıc´ı se strukturou je vˇzdy specifikovaten´ y jako systém statick´ y. To znamená, ˇze je simulovateln´ y ekvivalentn´ım systémem se statickou strukturou, jehoˇz stavov´ y prostor je rozˇs´ıˇren tak, aby zahrnoval vˇsechny varianty a pˇrechodové 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

´ ˇ ÍCÍ STRUKTUROU KAPITOLA 3. SYSTEMY S DYNAMICKY SE MEN

Obrázek 3.1: Strukturn´ı pˇrechody [Uhr01] kde

X je mnoˇzina vstupn´ıch událost´ı, Y je mnoˇzina v´ ystupn´ıch událost´ı, m0 ∈ M (m0 ) je poˇcáteˇ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áteˇcn´ı stav, δint : S −→ S je intern´ı pˇrechodová funkce, δext : Q × X −→ S je extern´ı pˇrechodová 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álost´ı, Y je mnoˇzina v´ ystupn´ıch událost´ı, m0 ∈ M (m0 ) je poˇcáteˇcn´ı model (poˇcáteˇ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álost´ı, 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Í 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é: Podˇr´ızen´ y simul´ ator child, ˇcas zaˇcátku a konce simulace tBEGIN , tEN D , aktuáln´ı ˇcas t a ˇcas následuj´ıc´ı pl´ anované události tnext . Algoritmus: t := tBEGIN poˇsli (i, t) podˇr´ızenému simul´ atoru child poˇckej na (done, s, tnext ) od podˇr´ızeného simul´ atoru child t := tnext dokud t < tEN D opakuj: poˇsli (∗, t) podˇr´ızenému simul´ atoru child poˇckej na (done, s, tnext ) od podˇr´ızeného simul´ atoru child t := tnext Abstraktn´ı simul´ ator atomick´ eho modelu Promnné: Aktuáln´ı model m, ˇcas posledn´ı události tlast , ˇcas následuj´ıc´ı události 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ého simul´ atoru parent reaguj takto: tlast := t − e tnext := tlast + ta(sm ) poˇsli (done, sm , tnext ) nadˇrazenému simul´ atoru parent Na zpr´ avu (∗, t) od nadˇrazeného simul´ atoru parent reaguj takto: m y := λ(s ) poˇsli (y, t) nadˇrazenému simul´ atoru parent m m s := δint (s ) m := ρ(sm ) tlast := t tnext := tlast + ta(sm ) poˇsli (done, sm , tnext ) nadˇrazenému simul´ atoru parent Na zpr´ avu (x, t) od nadˇrazeného 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ému simul´ atoru parent Abstraktn´ı simul´ ator (koordin´ ator) sloˇ zen´ eho modelu Promˇenné: Aktuáln´ı model n, stav sn , ˇcas posledn´ı události tlast , ˇcas následuj´ıc´ı události tnext , v´ ystup y, seznam

24


následuj´ıc´ıch událost´ı v submodelech eventList, mnoˇzina submodel˚ u s událostmi pl´ anova´ ymi na aktuáln´ı ˇ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ého 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ému simul´ atoru Na zpr´ avu (∗, t) od nadˇrazeného 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ému 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ému simul´ atoru Na zpr´ avu (x, t) od nadˇrazeného 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ému 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áklad systému James [Uhr01] pro modelován´ı a simulaci agentn´ıch systém˚ u. Formáln´ı model DynDEVS je koncipován jako uzavˇren´ y, neˇreˇs´ı problematiku klonován´ı a editaci model˚ u asynchronn´ımi zásahy z vnˇejˇsku. Umoˇzn ˇuje vˇsak kromˇe vzniku a zániku model˚ u také jejich migraci rámci systému, coˇz je pro multiagentn´ı systémy typické. Vzhledem k tomu, ˇze migraci provád´ı model, kter´ y se chce pˇresunout, je pˇresun souˇcásti jeho vlastn´ıho intern´ıho nebo extern´ıho pˇrechodu. V okamˇziku migrace je tedy v definovaném stavu, pˇriˇcemˇz e = 0. V definici dynamického 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é události. Ale v pˇr´ıpadˇe, ˇze celou simulaci chápeme jako otevˇren´ y systém se vstupy a v´ ystupy (pˇr´ıpadnˇe také s vlastn´ım, nez´ avisl´ ym ˇcasem),1 mus´ıme se zab´ yvat asynchronn´ımi zásahy 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ému. Pˇritom je tˇreba zajistit korektn´ı chován´ı pˇri klonován´ı model˚ u a editaˇcn´ıch operac´ıch v libovolném okamˇziku. Touto problematikou se zab´ yv´ a kapitola 4.

1

Otevˇrené ch´ ap´ an´ı simulace s moˇznost´ı neomezenˇe klonovat a editovat modely je nezbytné pro interaktivn´ı evoluˇcn´ı v´ yvoj a u ´drˇzbu nepˇretrˇzitˇe bˇeˇz´ıc´ıch systém˚ u.

26


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ému pro simulaci vyv´ıjej´ıc´ıch se systém˚ u. Nejprve jsou vymezeny poˇzadované vlastnosti, poté je na základˇe jejich anal´ yzy vytvoˇren návrh vhodné architektury a diskutovány moˇznosti pouˇzit´ı.

4.1

Vymezen´ı poˇ zadovan´ ych vlastnost´ı

Systémy, kter´ ymi se hodl´ ame nad´ ale zab´ yvat a pro které m´ ame v u ´myslu definovat vhodnou simulaˇcn´ı architekturu, lze charakterizovat jako • optimalizuj´ıc´ı, uˇc´ıc´ı se, adaptivn´ı systémy, • otevˇrené, dynamicky zkoumatelné a dynamicky editovatelné systémy, • reflektivn´ı systémy. Vzhledem k pˇredpokl´ adanému zp˚ usobu pouˇzit´ı simulace v rámci návrhu, v´ yvoje a u ´drˇzby systém˚ u mezi hlavn´ı poˇzadavky na podp˚ urné nástroje patˇr´ı • simulace v reálném ˇcase, propojen´ı simulace s okoln´ı realitou, • klonován´ı a editace model˚ u v pr˚ ubˇehu simulace, • multisimulace – systémy simulac´ı, simulace simulac´ı, V následuj´ıc´ım textu budou jednotlivé poˇzadavky podrobnˇe analyzovány a bude z nich odvozen návrh otevˇrené architektury pro modelován´ı a simulaci vyv´ıjej´ıc´ıch se systém˚ 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álném ˇcase plyne ˇcas modelu stejnˇe rychle jako ˇcas reáln´ y. Otázkou z˚ ustává konkrétn´ı hodnota ˇcasového u ´daje, resp. mapován´ı mezi hodnotou svˇetového ˇcasu a ˇcasu modelu. Lze rozliˇsit dva pˇr´ıpady:

ˇ ´ ABSTRAKTNÍ ARCHITEKTURA KAPITOLA 4. OTEVREN A

28

Lok´ aln´ı re´ aln´ yˇ cas. Tok ˇcasu pˇri simulaci v reálném ˇcase m˚ uˇze b´ yt chápán jako reáln´ y ˇcas bˇehu modelu. V takovém pˇr´ıpadˇe hodnota ˇcasu v daném okamˇziku udává reálnou dobu, po jakou model od svého startu bˇeˇzel. Je-li simulace pˇreruˇsena, reáln´ y ˇcas bˇehu modelu z˚ ustává konstantn´ı, je také pozastaven. Po opˇetovném spuˇstˇen´ı hodnota ˇcasu nar˚ ustá plynule od hodnoty ˇcasu v okamˇziku pˇreruˇsen´ı. Toto cháp´ an´ı reálného ˇcasu modelu je souladu s definic´ı systému – jde o ˇcas, v kterém systém existuje. Zastaven´ı simulace znamená, ˇze systém v dobˇe, kdy je simulace zastavena, neexistuje a jeho existence pokraˇcuje aˇz po opˇetovném spuˇstˇen´ı simulace. Zastavován´ı a spouˇstˇen´ı simulace jsou operace, které model nevn´ımá a pokud mu metasystém (okoln´ı realita) tuto informaci neposkytne, ˇzije model ve svém ˇcase, aniˇz by vidˇel nˇejaké pˇreruˇsen´ı. Glob´ aln´ı re´ aln´ yˇ cas. Tok tohoto ˇcasového u ´daje nelze ˇzádn´ ym zp˚ usobem ovlivnit, natoˇz zastavit. M´ a-li model pracovat s globáln´ım reáln´ ym ˇcasem, pozastaven´ı simulace zp˚ usob´ı problém – simulace se opozd´ı oproti reálnému ˇcasu. Po opˇetovném spuˇstˇen´ı se se zpoˇzdˇen´ım provedou akce, pl´ anované 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á. Nedodrˇzen´ı ˇcasového r´ amce (timeoutu) pro provedne´ı akce je cháp´ ano jako selh´ an´ı a mus´ı b´ yt systémem detekováno. To vyˇzaduje dodat ˇcasová omezen´ı do modelu a tato omezen´ı v pr˚ ubˇehu simulace hl´ıdat. V nˇekter´ ych pˇr´ıpadech je v´ yhodné pouˇz´ıt proporcion´ aln´ı ˇcas. Rychlost toku modelového ˇcasu vzhlem k r´ alnému ˇcasu je pak dána koeficientem, tzv. RT-fakorem. Simulace je tedy na reálném ˇcase závislá, ale bˇeˇz´ı bud’ zrychlenˇe, nebo zpomalenˇe. Simulace v re´ aln´ em ˇ case Simulaci je moˇzné synchronizovat s reáln´ ym ˇcasem a propojit simulované a reálné entity do jednoho celku.1 Základn´ım pˇredpokladem je dostateˇcnˇe rychlé provádˇen´ı jednotliv´ ych krok˚ u simulace. Pak staˇc´ı po kaˇzdém kroku poˇckat na hodnotu reálného ˇcasu rovnou ˇcasu následuj´ıc´ı události v simulaˇcn´ım ˇcase a pak provést dalˇs´ı krok. Problémem, kter´ y je tˇreba ˇreˇsit v pˇr´ıpadˇe distribuované 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ásit 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ána s vyuˇzit´ım prostˇredk˚ u operaˇcn´ıho systému. Z hlediska modelu se interakce s reáln´ ym okol´ım ˇreˇs´ı speciáln´ı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ázej´ıc´ı data z vnˇejˇs´ıho prostˇred´ı (viz napˇr. [Hu04]). V atomickém 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ému,2 realizuj´ıc´ı v´ ystupy a ˇcekaj´ıc´ı na moˇzné vstupy. Z procesu vstupnˇe-v´ ystupn´ı aktivity atomického modelu m˚ uˇze b´ yt kdykoli asynchronnˇe (tj. nez´ avisle na procesu simulace) aktualizován stav atomického modelu. Pˇri kaˇzdé takové zmˇenˇe mus´ı proces vstupnˇe-v´ ystupn´ı aktivity okamˇzitˇe aktualizovat tnext := clock hodnotou aktuáln´ıho reálného ˇ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ém˚ u – po otestov´ an´ı modelu ˇr´ıdic´ıho systému (pˇresnˇeji ˇr´ıdic´ıho systému realizovaného jako model) v simulovaném prostˇred´ı (obsahuj´ıc´ım simulovan´ y ˇr´ızen´ y systém) se simulované prostˇred´ı nahrad´ı rozhran´ım na re´ alné okol´ı (a re´ aln´ y ˇr´ızen´ y systém). 2 Pojem operaˇcn´ı systém zde zahrnuje jakékoliv v´ ypoˇcetn´ı prostˇred´ı, ve kterém simul´ ator bˇeˇz´ı, tj. napˇr´ıklad JVM, Smalltalk, stejnˇe tak, jako napˇr. UNIX apod.

´ EM ´ CASE, ˇ ´ YM ´ OKOLÍM 4.2. SIMULACE V REALN PROPOJENÍ S REALN

29

zasl´ an´ım zpr´ avy (se, tnext ) nadˇrazenému simul´ atoru. Simul´ ator sloˇzeného 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ému nadˇrazenému simul´ atoru. Koˇrenov´ y simul´ ator si v reakci na (se, tnext ) aktualizuje tnext , takˇze v následuj´ıc´ım kroku m˚ uˇze pˇr´ısluˇsn´ y atomick´ y model na stavovou událost zareagovat intern´ım pˇrechodem. Reakce simul´ atoru na zpr´ avy pˇricházej´ıc´ı z r˚ uzn´ ych proces˚ u (z procesu koˇrenového 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ány. 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ém okamˇziku aktuáln´ı hodnotu reálného ˇcasu. Na zaˇcátku simulace je tˇreba synchronizovat ˇcas modelu a hodiny reálného ˇcasu (clock) – lze nastavit bud’ tBEGIN := clock, nebo clock := tBEGIN . V prvn´ım pˇr´ıpadˇe pracujeme s globáln´ım ˇcasem, v druhém pˇr´ıpadˇe pracujeme ˇcasem reálného bˇehu modelu (hodnota clock udává reálnou dobu bˇehu od spuˇstˇen´ı). Algoritmus koˇrenového simul´ atoru pro simulaci v reálném ˇcase vypad´ a takto: synchronizuj clock a tBEGIN t := tBEGIN poˇsli (i, t) podˇr´ızenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného 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ému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child t := tnext Na zpr´ avu (se, tnext ) reaguj synchronizovanˇe takto: t := tnext Simul´ ator atomického 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ému simul´ atoru Na ostatn´ı zpr´ avy reaguj stejnˇe jako v kap. 2, ale synchronizovanˇe. Simul´ ator sloˇzeného modelu z kap. 2 dopln´ıme takto: Na zpr´ avu (se, tnext ) od podˇr´ızeného simul´ atoru d reaguj synchronizovanˇe takto: eventList := (eventList − {(d, )}) ∪ {(d, tdnext )} t := tnext 3 Pseudopromˇenn´ a je promˇenn´ a, do které v doménové u ´rovni nelze pˇriˇradit hodnotu, tj. je pro model k dispozici pouze pro ˇcten´ı. 4 Pod pojmem synchronizované proveden´ı m´ ame na mysli kritickou sekci hl´ıdanou semaforem pro pˇr´ıstup k promˇenn´ ym simul´ atoru.


30

Poˇsli zpr´ avu (se, tnext ) nadˇrazenému 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éna v situaci, kdy dovol´ıme editaci modelu – pro takové zásahy se simulace pˇrechodnˇe zastav´ı a po proveden´ı operace se znovu spust´ı. Kop´ırován´ı, serializace apod. jsou bezpeˇcné jen tehdy, kdyˇz model neobsahuje ˇzádné bˇeˇz´ıc´ı procesy. Toto lze realizovat tak, ˇze ke spuˇstˇen´ı vstupnˇe-v´ ystupn´ıch aktivit atomického 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ásleduj´ıc´ı sekci pro potˇreby klonován´ı model˚ u. Koˇrenov´ y simul´ ator je pak tˇreba upravit tak, aby pˇri kaˇzdém startu a zastaven´ı pos´ılal podˇr´ızenému 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ého modelu, kter´ y je urˇcem pro simulaci v re´ alném ˇcase a umoˇzn´ı dynamické klonován´ı a editaci (jak bude ukázáno dále). Atomický model se stavem a vstupnˇe-výstupn´ı aktivitou je specifikován 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áteˇcn´ı stav, (s, e) ∈ Q je aktuáln´ı totáln´ı stav, α je vstupnˇe v´ ystupn´ı aktivita.

Vstupnˇe-v´ ystupn´ı aktivita α bˇeˇz´ı v reálném ˇcase a nez´ avisle na simulaci ovlivˇ nuje stav s ∈ S. Pˇri kaˇzdé modifikaci stavu s ∈ S oznamuje simul´ ator nadˇrazenému simul´ atoru stavovou událost (se, t) s hodnotou aktuáln´ıho reálného ˇcasu. Aktivita α rozum´ı zpr´ avám (suspendActivity) a (resumeActivity). Rozˇ s´ıˇ ren´ a definice sloˇ zen´ eho modelu Sloˇzený model se stavem je definován 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ány stejnˇe jako v klasické 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ého modelu prepareToStop a prepareToStart. Tyto metody jsou zdˇedˇené jako pr´ azdné a v kaˇzdém modelu, kter´ y implementuje rozhran´ı na realitu mus´ı b´ yt adekv´ atnˇe implementov´ any. 6 Jejich souvislost byla vysvˇetlena v kap. 2.

´ Í A MIGRACE SYSTEM ´ U ˚ A SIMULACÍ 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áz´ı v r´ amci pl´ anovan´ ych událost´ı v pr˚ ubˇehu simulace. Neˇreˇs´ı ani problematiku klonován´ı, ani vazbu na vnˇejˇs´ı prostˇred´ı, a tedy ani asynchronn´ı editaˇcn´ı zásahy do modelu z vnˇejˇs´ıho prostˇred´ı, vˇcetnˇe ovl´ ad´ an´ı simul´ atoru. Právˇe tuto problematiku nyn´ı pop´ıˇseme a rozˇs´ıˇr´ıme abstraktn´ı simul´ ator DEVS tak, aby takové zásahy umoˇznil. Kontinuace a DEVS Kontinuace je objekt, reprezentuj´ıc´ı pokraˇcován´ı v´ ypoˇctu. Je to sn´ımek, vytvoˇren´ y v libovolném okamˇziku z bˇeˇz´ıc´ıho procesu. S kontinuac´ı se pracuje jako s daty – lze ji uloˇzit, pˇrenést jinam, kop´ırovat apod. Kontinuace umoˇzn ˇuj´ı implementovat multitasking, klonován´ı a migraci proces˚ u, návraty v ˇcase, prohledáván´ı stavového prostoru. Definice systému i definice DEVS odpov´ıdaj´ı tomuto konceptu – systém s aktuáln´ım stavem obsahuje veˇskerou potˇrebnou informaci k proveden´ı simulace, tj. ke generován´ı stavové trajektorie, tj. ke zjiˇstˇen´ı budouc´ıho chov´ an´ı. Dynamick´ e klonov´ an´ı a migrace V pˇr´ıpadˇe systému s diskrétn´ımi událostmi je stav modelu v libovolném okamˇziku urˇcen u ´pln´ ym stavem (s, e). D´ıky uzavˇrenosti mnoˇziny systém˚ u vzhledem ke skl´ ad´ an´ı pro kaˇzd´ y sloˇzen´ y systém vˇzdy existuje ekvivalentn´ı základn´ı systém s u ´pln´ ym stavem (s, e). Pˇritom s kaˇzd´ ym podsystémem lze nakl´ adat stejnˇe jako se sloˇzen´ ym systémem. K tomu, aby bylo moˇzné kdykoliv poˇr´ıdit sn´ımek (klon) systému nebo jeho ˇcásti, je tˇreba vhodnˇe doplnit abstraktn´ı simul´ ator. Pˇred kaˇzd´ ym klonován´ı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ál pokraˇcovat. Vzhledem k tomu, ˇze systém je definován nez´ avisle na kontextu7 , je moˇzné bez problém˚ u nechat klon systému dál existovat v jiném kontextu, neˇz v jakém bˇeˇzel origin´ al. Je tak moˇzné realizovat migraci komponent mezi subsystémy v rámci jedné 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án´ı a klonován´ı celé simulace – simul´ atory si potˇrebnou informaci pamatuj´ı a po okop´ırován´ı simulace plynule pokraˇcuje. Problém nast´ avá v pˇr´ıpadˇe strukturn´ı editace model˚ u, t.j. pˇri manipulaci s jednotliv´ ymi komponentami ve smyslu klonován´ı, odstraˇ nován´ı a vklád´ an´ı. Po takov´ ych operac´ıch je tˇreba provést korektn´ı inicializaci vˇsech komponent dˇr´ıve, neˇz necháme simulaci pokraˇcovat. Inicializace se na zaˇcátku pokraˇcován´ı simulace mus´ı vˇzdy provést, aby byla aktualizována hodnota tlast a tnext ve vˇsech komponentách (po pˇr´ıpadné editaci struktury se mohou tyto hodnoty stát neaktu´ aln´ımi) a aby nadˇrazen´ y simul´ ator z´ıskal korektn´ı informaci o ˇcase následuj´ıc´ı události. 7

Systém nev´ı o hierarchicky nadˇrazeném systému ani o systémech, s nimiˇz je propojen. Na druhé stranˇe, sloˇzen´ y systém zn´ a vˇsechny své komponenty i jejich propojen´ı. 8 Toto je v pˇr´ıpadˇe jiného paradigmatu, jako je napˇr. objektov´ a orientace, problém – kontext objektu je d´ an vˇsemi dostupn´ ymi objekty. Vymˇenit kontext v pr˚ ubˇehu v´ ypoˇctu pak nen´ı tak jednoduché, jako je tomu v pˇr´ıpadˇe formalismu DEVS. Obˇe paradigmata vˇsak lze vhodnˇe kombinovat – objekty lze bez problém˚ u pouˇz´ıt uvnitˇr komponent DEVS a migraci omezit na komponenty DEVS.


32

Simul´ ator dynamického DEVS [Uhr01] vˇzdy inicializuje pˇrid´ avané subsystémy. V naˇsem pˇr´ıpadˇe ale poˇc´ıt´ ame se vznikem nov´ ych subsystém˚ u klonován´ım s následnou editac´ı, pˇriˇcemˇz k naklonován´ı systému m˚ uˇze doj´ıt asynchronnˇe, v libovolném okamˇziku. Proto mus´ıme ˇreˇsit korektn´ı vytvoˇren´ı klonu tak, aby jeho následn´ a inicializace v novém kontextu probˇehla spr´ avnˇe a aby klon mohl plynule pokraˇcovat v existenci. Simul´ ator atomického modelu hodnotu e ˇcasu stráveného ve stavu s standardnˇe aktualizuje pˇri zpracován´ı 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ádku, ale chceme-li simulaci pˇreruˇsovat a manipulovat s jej´ımi kontinuacemi (ve smyslu klonován´ı, migrace, zpˇetného 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ého ˇcasu e. Pˇr´ıˇst´ı zpr´ ava (i, t) po opˇetovném odstartován´ı simulace pak spr´ avnˇe synchronizuje pokraˇcován´ı simulace. Vazba simul´ atoru na vnˇ ejˇ s´ı prostˇ red´ı, simul´ ator jako syst´ em Simul´ ator daného modelu chápeme opˇet jako systém se vstupy a v´ ystupy. Vstupy jsou události (start), (stop), (reset), (endT ime, t) a události pˇredstavuj´ıc´ı poˇzadavky na editaˇcn´ı operace. Ty budou pops´ any v sekci 4.4. Sekvence v´ ystupn´ıch událost´ı nese informaci o stavov´ ych trajektori´ıch a událostn´ıch segmentech vˇsech submodel˚ u, vˇcenˇe zmˇen stavu samotného simul´ atoru (spuˇstˇen, zastaven apod.). Jde o události (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ém reaguje informac´ı o struktuˇre a aktuáln´ım stavu modelu, kterého 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ázek 4.1: Simul´ ator jako systém Rozˇ s´ıˇ ren´ı simul´ atoru atomick´ eho modelu Abstraktn´ı simul´ ator atomického modelu dopln´ıme o reakci na zpr´ avu (sync, t). Kv˚ uli pˇr´ımé souvislosti uvedeme i reakci na zpr´ avu (i, t), reakce na ostatn´ı zpr´ avy z˚ ustávaj´ı stejné jako v kap. 2, jsou jen doplnˇeny o generován´ı událost´ı 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ého simul´ atoru parent reaguj takto: s := s0 e := 0 tlast := 0 tnext := ∞ poˇsli (done, tnext ) nadˇrazenému simul´ atoru parent 9

Stejnou zpr´ avu jsme jiˇz pouˇzili v pˇredch. sekci k jinému u ´ˇcelu, a sice k zastaven´ı vstupnˇe-v´ ystupn´ı aktivity. Oba d˚ uvody k jej´ımu zaveden´ı jsou nez´ avislé a m˚ uˇze proto plnit oba u ´ˇcely souˇcasnˇe.

´ Í A MIGRACE SYSTEM ´ U ˚ A SIMULACÍ 4.3. KLONOVAN

33

Na zpr´ avu (i, t) od nadˇrazeného 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ému simul´ atoru parent Na zpr´ avu (sync, t) od nadˇrazeného simul´ atoru parent reaguj takto: poˇsli (suspendActivity) vstupnˇe-v´ ystupn´ı aktivitˇe α e := t − tlast poˇsli (done, tnext ) nadˇrazenému simul´ atoru parent Rozˇ s´ıˇ ren´ı simul´ atoru sloˇ zen´ eho modelu Abstraktn´ı simul´ ator sloˇzeného modelu dopln´ıme o reakci na zpr´ avu (sync, t). Kv˚ uli pˇr´ımé souvislosti uvedeme i reakce na zpr´ avy (i, t) a (done, t), reakce na ostatn´ı zpr´ avy z˚ ustávaj´ı stejné jako v kap. 2. Na zpr´ avu (reset) od nadˇrazeného simul´ atoru parent reaguj takto: ∀d ∈ D : poˇsli (reset) simul´ atoru d activeChildren := D Na zpr´ avu (i, t) od nadˇrazeného 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ého 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ého 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ého simul´ atoru (i, t), d pak tlast := max{tlast |d ∈ D} Je-li posledn´ı zpr´ ava od nadˇrazeného simul´ atoru (∗, t), nebo (x, t), pak tlast := t tnext := min{tdnext |d ∈ D} poˇsli (done, tnext ) nadˇrazenému 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á metaudálosti (simulationStarted, t), (simulationStopped, t). Algoritmus: t := 0 tEN D := ∞ Na zpr´ avu (start) reaguj takto:


34

Jestliˇze p = nil, pak p := nov´ y proces: poˇsli (i, t) podˇr´ızenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child t := tnext te := tEN D generuj metaudálost (simulationStarted, t) dokud t < te opakuj: poˇsli (∗, t) podˇr´ızenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child t := tnext poˇsli (sync, t) podˇrzenému simul´ atoru child poˇckej na (done, tnext ) od podˇr´ızeného simul´ atoru child generuj metaudálost (simulationStopped, t) p := nil Na zpr´ avu (stop) reaguj takto: Jestliˇze t >= te a p = nil, generuj metaudálost (simulationStopped, t) te := t Na zpr´ avu (reset) reaguj takto: poˇsli (reset) podˇr´ızenému simul´ atoru child poˇckej na (done, ) od podˇr´ızeného 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ého simul´ atoru pro bˇeh v reálném ˇcase si na základˇ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é simulaci provádˇet klonován´ı, migraci a editaci model˚ u. Nyn´ı dopln´ıme návrh dynamického aplikaˇcn´ıho rozhran´ı simul´ atoru, které umoˇzn´ı • dynamickou inspekci modelu a stavu simulace, • dynamickou zmˇenu vazeb mezi modely,modelsestavem • dynamické vytváˇren´ı a ruˇsen´ı model˚ u, • dynamickou editaci definice atom˚ u, • dynamické vytváˇren´ı, editace a ruˇsen´ı pomocn´ ych objekt˚ u.

ˇ Í 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ál10 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ány. Na obr. 4.2 je ukázka hierarchie objekt˚ u 11 existuj´ıc´ıch na poˇcátku simulace modelu PingPong z kapitoly 2. Nedocház´ı-li k zásah˚ 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éno a specifikace objektu) a pˇrid´ a ho do mnoˇziny O, • COP Y – zkop´ıruje objekt o do promˇenné P AST EBU F F ER, • P AST E – vloˇz´ı kopii objektu uloˇzeného v promˇenné 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é P AST EBU F F ER, • REN AM E – pˇrejmenuje objekt o (parametrem je nové jméno) v mnoˇzinˇe O, • SAV E – uloˇz´ı objekt o do vstupnˇe v´ ystupn´ı promˇenné IO,13 • LOAD – vloˇz´ı objekt ze vstupnˇe v´ ystupn´ı promˇenné IO do mnoˇziny O,14 • EDIT – modifikuje specifikaci objektu o (parametrem je nová specifikace), • makrooperace sloˇzené z uveden´ ych operac´ı. 10

V objektovˇe orientovaném prostˇred´ı zaloˇzeném 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é 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é konkrétn´ı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éhoˇz efektu. 13 Prakticky je objekt uloˇzen v textové podobˇe. 14 Prakticky probˇehne rekonstrukce objektu z textové reprezentace.


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ázek 4.2: Hierarchie objekt˚ u – sn´ımek stavu simulace PingPong Uvedené operace lze bez omezen´ı aplikovat v libovolném okamˇziku na libovolné objekty. Jako pˇr´ıklad lze uvést 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ány jmény objekt˚ u a modifikuj´ı tyto objekty nebo mnoˇziny tyto objekty obsahuj´ıc´ı. Vzhledem k hierarchické struktuˇre model˚ u lze pro identifikaci objektu pouˇz´ıt pathname, tj. sekvenci jmen vˇsech objekt˚ u, které jsou hierarchicky vnoˇreny a poˇzadovan´ y objekt obsahuj´ı, vˇcetnˇe jména tohoto objektu. Napˇr. v systému na obr. 4.2 m˚ uˇzeme objekt, odpov´ıdaj´ıc´ı v´ ystupn´ı funkci hráˇce B identifikovat jménem "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ázej´ı od vnˇejˇs´ıho systému, napˇr. od uˇzivatele (viz obr. 4.3). Pokud 15

Vzhledem k tomu, ˇze nˇekteré sloˇzky jména lze eliminovat, aniˇz by doˇslo k nejednoznaˇcnosti, m˚ uˇzeme tent´ yˇz objekt jednoduˇseji identifikovat jménem "SIMULATIONS/Ping Pong/Player B/METHODS/outputFnc".

ˇ Í A MODIFIKACE MODELU 4.4. CTEN

37

Simulator Command

X

Model

Y

Output

S

User interface User

Obrázek 4.3: Architektura pro interaktivn´ı evoluˇcn´ı v´ yvoj simulace bˇeˇz´ı, pro kaˇzdou editaˇcn´ı operaci nad modelem je nutné pozastavit simulaci, provést poˇzadovanou operaci a poté simulaci znovu spustit: poˇsli (stop) koˇrenovému simul´ atoru poˇckej na (simulationStopped), proved’ editaˇcn´ı operaci, poˇsli (start) koˇrenovému 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é operace. Po proveden´ı editaˇcn´ı operace simul´ ator generuje v´ ystupn´ı událost (model, M ), kde M je model, kterého 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ámci intern´ıho nebo extern´ıho pˇrechodu. Vzhledem k tomu, ˇze algorimus simulace je synchronn´ı, je proveden´ı jakéhokoli v zásahu do modelu v tomto okamˇziku bezpeˇcné. Model m˚ uˇze ˇc´ıst a editovat s´ am sebe, ale nepˇr´ımo také kontext, v kterém se nacház´ı. Nadˇrazen´ y model m´ a k dispozici stav vˇsech sv´ ych subsystém˚ u a souˇcást´ı tˇechto d´ılˇc´ıch stav˚ u mohou b´ yt poˇzadavky na editaˇcn´ı zásahy v nadˇrazeném modelu. Vzhledem k tomu, ˇze sloˇzen´ y systém je konceptuálnˇe systém paraleln´ı, mus´ı nadˇrazen´ y systém ˇreˇsit konflikty editaˇcn´ıch zásah˚ u, poˇzadovan´ ych v tomtéˇz okamˇziku r˚ uzn´ ymi subsystémy souˇcasnˇe.17 V pˇr´ıpadˇe, ˇze operaci nelze provést, neprovede se. Informaci o kontextu, v kterém se model nacház´ı, m˚ uˇze z´ıskat jedinˇe prostˇrednictv´ım sv´ ych vstup˚ u – to lze zajistit vhodnou strukturou hierarchicky nadˇrazeného nadˇrazeného sloˇzeného modelu. N´ aˇs pˇr´ıstup je zaloˇzen na meta´ urovˇ nové architektuˇre simul´ atoru. Model chápeme jako systém doménové u ´rovnˇe, simul´ ator chápeme jako metasystém,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ém kroku simulace, pˇriˇcemˇz vˇsechny proveditelné 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ém modelu. 18 V obou pˇr´ıpadech jde o systémy specifikovatelné formalismem DEVS. 17

38


modelu jsou zpracovány.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ázek 4.4: Simulace reflektivn´ıho systému

4.5

Syst´ emy simulac´ı (multisimulace)

Pozvednˇeme se nyn´ı mimo ˇcas a prostor jedné simulace. Na této u ´rovni pracujeme s mnoha nez´ avisl´ ymi simulacemi a jejich ˇcasoprostory a zab´ yv´ ame se dynamick´ ym vytváˇren´ım, ruˇsen´ım a propojován´ım simulac´ı. Toto dává 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án´ı 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é jsou kritéria 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ém˚ u – souˇcást´ı modelu M je simul´ ator jiného modelu M ′ . Pokud M ′ je modelem M , jde o reflektivn´ı simulaci – simulujeme systém, kter´ y obsahuje model sebe sama a provád´ı s n´ım simulaˇcn´ı experimenty. Multiparadigmatick´ a simulace je realizována 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ány a propojeny v rámci jedné multisimulace. Kompozice simul´ ator˚ u Uvedené pˇr´ıpady se liˇs´ı pˇredevˇs´ım t´ım, zda simulace bˇeˇz´ı z konceptuáln´ıho pohledu paralelnˇe (na stejné 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ého modelu. V druhém 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ého simul´ atoru, coˇz jsou z pohledu vnoˇreného modelu metaoperace a metainformace (na této u ´rovni m˚ uˇzeme s modelem a jeho simulac´ı zacházet 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ávislém, 19 Z hlediska praktické implementace lze frontu v nˇekter´ ych pˇr´ıpadech vynechat a editaˇcn´ı operace prov´ adˇet pˇr´ımo. Pro jednoduché z´ asahy to nevad´ı, obecnˇe je to ale nutné, kv˚ uli serializaci poˇzadavk˚ u pˇri n´ asobnému pˇr´ıstupu k refl. rozhran´ı simul´ atoru z mnoha submodel˚ u souˇcasnˇe.

´ 4.5. SYSTEMY SIMULACÍ (MULTISIMULACE)

39

ˇcase. Je samozˇrejmˇe moˇzné paraleln´ı simulaci vnoˇrit a vnoˇrené simulace nechat bˇeˇzet paralelnˇe. Vzhledem k tomu, ˇze simul´ ator se jev´ı jako komponenta DEVS, je moˇzné ho pˇrirozenˇe pouˇz´ıt jako submodel sloˇzeného 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ázek 4.5: Paraleln´ı simulace Simulator Model Command

Output Simulator Command

Output Model

Obrázek 4.6: Vnoˇren´ a simulace Multisimulaˇ cn´ı syst´ em Multisimulaˇcn´ı systém je systém, jehoˇz subsystémy 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át mu kompatibiln´ı rozhran´ı) a pouˇz´ıt ho jako subsystém multisimulaˇcn´ıho systému, kter´ y specifikujeme jako DEVS a simulujeme simul´ atorem DEVS (pˇr´ıkladem m˚ uˇze b´ yt simul´ ator pro jiné 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émem, podle toho, o jak´ y typ aplikace jde (pˇr´ıklad vnoˇrené simulace s nezávisl´ 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án´ı procesoru jednotliv´ ym simulac´ım. Procesy jednotliv´ ych simulac´ı jsou obvykle implementovány jako procesy hostitelského operaˇcn´ıho systému. Pak se o pˇridˇelován´ı procesoru star´ a pl´ anovaˇc operaˇcn´ıho systému. V pˇr´ıpadˇe multisimulaˇcn´ıho prostˇred´ı SmallDEVS, které bude 20

Pojem simulace, resp. simul´ ator, pouˇz´ıv´ ame analogicky k pojmu proces, resp. procesor v operaˇcn´ıch systémech. Proces (v terminologii operaˇcn´ıch systém˚ u) je objekt, obsahuj´ıc´ı program a aktu´ aln´ı stav jeho prov´ adˇen´ı. Totéˇz plat´ı obecnˇe pro procesor. Stejnˇe ch´ apeme i simulaci, resp. simul´ ator - zahrnuje model a jeho aktu´ aln´ı stav. Z jiného (nadˇcasového) 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émy, schopné generovat budouc´ı ud´ alosti.


40

pops´ ano v kapitole 5, se o pˇridˇelován´ı 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ávaznosti 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ána abstraktn´ı architektura univerz´ aln´ıho simulaˇcn´ıho systému 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éto architektury patˇr´ı simulace v reálném ˇcase, propojen´ı simulace s okoln´ı realitou, klonován´ı, migrace a editace submodel˚ u za bˇehu, meta´ urovˇ nová multisimulaˇcn´ı architektura (simul´ atory jsou systémy, s kter´ ymi se zacház´ı stejnˇe jako s modely). Konkrétn´ı implementac´ı této abstraktn´ı architektury je systém SmallDEVS, kterému se vˇenuje kapitola 5.

Kapitola 5

V´ yvoj syst´ em˚ u v simulaci, n´ astroj SmallDEVS V této kapitole bude pˇredstaven konkrétn´ı nástroj (SmallDEVS [Jan06]), implementuj´ıc´ı reflektivitu a podporuj´ıc´ı interaktivn´ı inkrementáln´ı v´ yvoj systému za bˇehu. Implementaˇcn´ım prostˇred´ım je Smalltalk. Popsané 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ém˚ u vnoˇriteln´ ym operaˇcn´ım systémem, podporuj´ıc´ım perzistenci, multitasking, interaktivitu a experimentáln´ı programovn´ı (exploratory programming). Smalltalk a jeho principy jsou také jedn´ım z hlavn´ıch zdroj˚ u inspirace pro vybudován´ı systému SmallDEVS.

5.1

Motivace a zvolen´ y pˇ r´ıstup

Jako motivaˇcn´ı pˇr´ıklad lze uvést inkrementáln´ı v´ yvoj ˇr´ıdic´ıho systému autonom´ıho mobiln´ıho robota v simulovaném prostˇred´ı. Jde o v´ yvoj systému, jehoˇz specifikace nen´ı na poˇcátku v´ yvoje zcela jasn´ a a je ji tˇreba dodateˇcnˇe upˇresˇ novat na základˇe v´ ysledk˚ u test˚ u, provádˇen´ ych na pokusn´ ych realizac´ıch v r˚ uzn´ ych prostˇred´ıch, a to jak simulovan´ ych, tak reáln´ ych. Vzhledem k tomu, ˇze je mnohdy nutné dovyv´ıjet realizovan´ y systém pˇri bˇeˇzném provozu v c´ılovém prostˇred´ı, je nezbytné zachovat model ˇr´ızen´ı v pr˚ ubˇehu celého v´ yvoje, vˇcetnˇe c´ılového nasazen´ı, s moˇznost´ı vrátit se kdykoli zpˇet do prostˇred´ı simulovaného. C´ılová realizace ˇr´ıdic´ıho systému pak mus´ı obsahovat simul´ ator modelu ˇr´ızen´ı, bˇeˇz´ıc´ı v reálném ˇcase a propojen´ y s reáln´ ym okol´ım. Pˇritom je vhodné zajistit vzd´ alené monitorován´ı stavu a inkrementáln´ı zásahy v´ yvojáˇre do modelu ˇr´ızen´ı za bˇeˇzného provozu. Uveden´ y styl v´ yvoje systém˚ u klade specifické nároky na podp˚ urné 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án´ı s interaktivn´ı fitness funkc´ı a s interaktivn´ım generován´ım r˚ uzn´ ych mutac´ı modelu. Otevˇ ren´ e a flexibiln´ı podp˚ urn´ e prostˇ redky Experimentáln´ı modelován´ı je tˇreba podpoˇrit odpov´ıdaj´ıc´ım nástrojem. K jeho hlavn´ım rys˚ um mus´ı patˇrit reflektivn´ı aplikaˇcn´ı rozhran´ı a interaktivn´ı vizuáln´ı nástroje pro inspekci a editaci model˚ u a manipulaci se simulacemi. Otevˇrenost a flexibilitu potˇrebnou pro inkrementáln´ı zásahy

42

´ ´ U ˚ V SIMULACI, NASTROJ ´ KAPITOLA 5. VYVOJ SYSTEM SMALLDEVS (programové i interaktivn´ı) v dobˇe bˇehu m˚ uˇze zajisit objektovˇe orientovan´ y pˇr´ıstup smalltalkovského 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é realizaci se pˇredpokl´ ad´ a propojen´ı modelu (kter´ y ve vhodném okamˇziku form´ alnˇe prohlás´ıme za c´ılovou realizaci) s reáln´ ym okol´ım. K tomu je nutné okoln´ı realitu zpˇr´ıstupnit se stejn´ ym rozhran´ım, jaké maj´ı komponenty modelu. Prakticky to znamená prvky reálného okol´ı zpˇr´ıstupnit formou speciáln´ıch atomick´ ych komponent. V´ yvoj v simulaci a zachov´ an´ı modelu (model continuity) V´ yvoj zaloˇzen´ y na simulaci je vhodné kromˇe postupu od simulace k realitˇe umoˇznit i reverznˇe, tj. umoˇznit návraty z reálného 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álném prostˇred´ı. Prakticky to znamená umoˇznit dynamické klonován´ı komponent modelu (resp. c´ılového programu) a pˇrenos tˇechto klon˚ u do simulovaného prostˇred´ı.

5.2

Experiment´ aln´ı programov´ an´ı (exploratory programming) a Smalltalk

Smalltalk je vˇseobecnˇe cháp´ an jako vzorov´ y jazyk pro experimentáln´ı programován´ı (exploratory programming), nebot’ poskytuje u ´ˇcinné prostˇredky pro interaktivn´ı zásahy do bˇeˇz´ıc´ıho systému. V této ˇcásti pop´ıˇseme podrobnˇeji nˇekteré 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é, zkoumaj´ıc´ı, pokusné, ˇci experiment´ aln´ı programov´ an´ı (EP). Posledn´ı z uveden´ ych term´ın˚ u budeme preferovat. Tento styl programován´ı 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ém. 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ákladˇe experiment˚ u s pokusn´ ymi realizacemi. Jde o interaktivn´ı prohlednáván´ı (exploration) prostoru vˇsech moˇzn´ ych program˚ u s c´ılem naj´ıt ten, kter´ y nejlépe vyhovuje obvykle velmi nejasnˇe zadan´ ym poˇzadavk˚ um. Taková situace je typická v oblasti umˇelé inteligence, ale i v ˇradˇe jin´ ych pˇr´ıpad˚ u. LISP, Smalltalk, Prolog a Self jsou typické jazyky umoˇzn ˇuj´ıc´ı právˇe tento styl programován´ı. 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án´ı podporuje i vizuáln´ımi nástroji. Inkrement´ aln´ı kompilace Technicky je pro podporu experimentáln´ıho programován´ı nezbytn´ a moˇznost okamˇzitého pˇrechodu od vytvoˇren´ı programu k jeho bezprostˇredn´ımu interaktivn´ımu (ale i automatickému) otestován´ı. Kompilace tedy mus´ı trvat zlomky, maximalnˇe jednotky vteˇrin, nikoliv minuty, jak je tomu u staticky typovan´ ych mainstreamov´ ych jazyk˚ u. Také mus´ı prob´ıhat z pohledu uˇzivatele skrytˇe, bez nutnosti explicitnˇe spouˇstˇet kompilátor. Toho lze prakticky doc´ılit inkrementáln´ım kompilátorem, kter´ y zpracovává jen d´ılˇc´ı ˇcásti vytváˇreného programového d´ıla právˇe v okamˇziku jejich modifikace a pˇreloˇzen´ y kód inkrementálnˇe zakomponovává do v´ ysledného celku. V pˇr´ıpadˇe Smalltalku je nejvˇetˇs´ı

´ Í PROGRAMOVAN ´ Í A SMALLTALK 5.2. EXPERIMENTALN

43

a jedinou jednotkou pˇrekladu jedna metoda. V´ ysledkem je objekt (konkrétnˇe zkompilovan´ a metoda), kter´ y je zaregistrován ve struktuˇre pˇr´ısluˇsné tˇr´ıdy, coˇz je také objekt, kter´ y je souˇcást´ı objektové pamˇeti (object memory) Smalltalku. Programov´ an´ı za bˇ ehu Podstatou EP je témˇ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áln´ımi zásahy. Stav v´ ypoˇctu je také v libovolném okamˇziku v ˇsiroké m´ıˇre editovateln´ y. Smalltalk poskytuje vizuáln´ı nástroje pro zkoumán´ı a editaci programu (t.j. systému 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ém okamˇziku modifikovat a bezprostˇrednˇe zkoumat d˚ usledky takov´ ych zásah˚ u. Takˇze jak zkoumán´ı bˇehu programu, tak samotné programován´ı prob´ıh´ a souˇcasnˇe. Takov´ ymto spojen´ım programován´ı s okamˇzit´ ym ovˇeˇrován´ım chován´ı lze obecnˇe dos´ ahnout mnohem vyˇsˇs´ı produktivity program´ atorské práce i vyˇsˇs´ı kvality kódu neˇz zdlouhav´ ym opakovan´ ym programován´ım, následnou explicitn´ı kompilac´ı a spouˇstˇen´ım v´ ysledné aplikace s omezen´ ymi moˇznostmi sledovat chován´ı programu, jak je tomu v pˇr´ıpadˇe bˇeˇzn´ ych programovac´ıch jazyk˚ u, pouˇzit´ ych pro prototypován´ı a evoluˇcn´ı v´ yvoj. Bˇeˇzné programovac´ı jazyky totiˇz podporuj´ı klasick´ y pˇr´ıstup softwarového inˇzen´ yrstv´ı, zaloˇzen´ y na d˚ ukladné anal´ yze poˇzadavk˚ u a z n´ı odvozené pˇresné specifikace programového 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ód ztr´ ac´ı p˚ uvodn´ı v´ yznam, protoˇze to, ˇceho se program´ ator snaˇz´ı inkrementáln´ımi zásahy doc´ılit, nen´ı primárnˇe zdrojov´ y text, ale uspokojivˇe bˇeˇz´ıc´ı programové d´ılo. To se totiˇz v´ yvojáˇr snaˇz´ı neust´ ale testovat, analyzovat a upravovat. V pˇr´ıpadˇe Smalltalku tedy jde program´ atorovi primárnˇe o vytvoˇren´ı funguj´ıc´ıcho systému ˇziv´ ych objekt˚ u v perzistentn´ı objektové pamˇeti, nikoliv o vytvoˇren´ı soubor˚ u se zdrojov´ ymi texty, které po zkompilován´ı a spuˇstˇen´ı takov´ y systém objekt˚ u pˇri odstartován´ı vytvoˇr´ı. Program´ ator ve Smalltalku needituje ˇzádné textové soubory, ale inkrementálnˇe modifikuje objekty pˇr´ımo v objektové pamˇeti za pomoci inkrementáln´ıho kompilátoru spojeného s nástroji pro navigaci v systému objekt˚ u. Kompil´ ator je automaticky aktivován jako reakce na zásahy programátora, kter´ y edituje jen jednotlivé textové reprezentace metod, které jsou mu zpˇr´ıstupˇ neny v nástroji 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ád´ a do logu mimo objektovou pamˇet’. V pˇr´ıpadˇe, ˇze by tento log z jakéhokoliv 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án´ı a modifikace jsou v´ yluˇcnˇe jen ˇzivé objekty v objektové 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árn´ı. Pˇrestoˇze tak mohou b´ yt vidˇeny, nejsou to zdrojové texty v pravém smyslu slova. Needituj´ı se, slouˇz´ı typicky jen pro pˇr´ıpadn´ y pˇrenos vytvoˇreného d´ıla do objektové pamˇeti jiného Smalltalku. Takto vygenerované texty nejsou urˇceny k tomu, aby je ˇcetl, analyzoval a editoval ˇclovˇek. Jak prohl´ıˇzen´ı, tak i anal´ yza a editace systému tˇr´ıd se pˇrirozenˇe realizuje v jejich primárn´ı, ˇzivé podobˇe, t.j. v podobˇe objekt˚ u v objektové pamˇeti. Proto také mnohé Smalltalky preferuj´ı export nikoliv v podobˇe, která 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áno za standard pro textovou reprezentaci tˇr´ıd a objekt˚ u, urˇcenou ke strojovému zpracován´ı. Perzistence, obraz pamˇ eti Jelikoˇz nepracujeme se zdrojov´ ymi texty v souborech, ale s objektovou pamˇet´ı, mus´ı systém pro EP podporovat moˇznost jej´ıho kompletn´ıho uloˇzen´ı na extern´ı médium (obvykle do souboru) v podobˇe tzv. obrazu (image). Tento obraz objektové pamˇeti je pˇri startu systému (Smalltalku) naˇcten a objektová pamˇet’ je rekonstruována pˇresnˇe v té podobˇe, v jaké byla pˇredt´ım uloˇzena. Nˇekteré Smalltalky jsou schopny nepˇretrˇzitˇe obraz objektové pamˇeti udrˇzovat na disku a také ˇreˇsit odklád´ an´ı nepouˇz´ıvan´ ych ˇcást´ı na disk v pˇr´ıpadˇe nedostatku volné operaˇcn´ı pamˇeti. Takov´ ym Smalltalkem je napˇr. systém GemStone [?], deklarovan´ y jako objektovˇe orientovan´ y datab´ azov´ y systém pro klient-server aplikace. Reflektivita a dynamiˇ cnost Smalltalk je pomˇernˇe rozsáhl´ y programov´ y systém vytvoˇren´ y ve Smalltalku samotném. Jde o typickou ukázku systému, 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án´ı vˇsech jej´ıch instac´ı. Smalltalk je dynamick´ y jazyk. To znamená, ˇze programové struktury mohou vznikat a zanikat za bˇehu. Smalltalk je systém, vytvoˇren´ y a bˇeˇz´ıc´ı ve Smalltalku. Programován´ı ve Smalltalku znamená postupnou modifikaci Smalltalku smˇerem ke k´ yˇzené aplikaci. Smalltalk, resp. aplikace ve Smalltalku vytváˇren´ a, tedy ve skuteˇcnosti provád´ı sebemodifikaci a t´ım se toto programové d´ılo vyv´ıj´ı. Pouˇ zitelnost EP EP je obecnˇe vhodné v tˇechto situac´ıch: • malé projekty, • malé t´ ymy (v ideáln´ım pˇr´ıpadˇe aplikuj´ıc´ı zásady extremn´ıho programován´ı), • nejasné zadán´ı, • omezené prostˇredky (ˇcas, prostor, pen´ıze). EP je naopak nevhodné pro velké projekty a velké t´ ymy. Tam se poˇc´ıt´ a právˇe se zaveden´ ymi bˇeˇzn´ ymi technikami softwarového inˇzen´ yrstv´ı s d˚ ukladnou pˇredbˇeˇznou anal´ yzou a s existuj´ıc´ımi rozsáhl´ ymi a otestovan´ ymi knihovnami pro bˇeˇzné, obvyle staticky typované jazyky. Také veˇskeré podp˚ urné nástroje, umoˇzn ˇuj´ıc´ı t´ ymov´ y v´ yvoj, jsou zaloˇzeny na správˇe soubor˚ u se zdrojov´ ymi texty, které se povaˇzuj´ı za primárn´ı a jedinou udrˇzovanou podobu programového 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é 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é, tj. nem˚ uˇze za ˇzádn´ ych okolnost´ı doj´ıt k chybˇe, zp˚ usobené aplikac´ı operace nad nesprávn´ ym typem dat.

´ ORIENTACE ZALOZEN ˇ A ´ NA PROTOTYPECH 5.3. OBJEKTOVA

45

Potenciáln´ı problém dynamicky typovan´ ych jazyk˚ u ale tkv´ı v tom, ˇze na pˇr´ıpadné typové nekompatibility se pˇrijde aˇz za bˇehu. Ale vzhledem k tomu, ˇze EP je zaloˇzeno na velmi d˚ ukladném testován´ı, pravdˇepodobnost neodhalen´ı takové chyby je obvykle mnohem pˇrijatelnˇejˇs´ı neˇz cena v´ yvoje s pouˇzit´ım klasického staticky typovaného jazyka (nehledˇe na fakt, ˇze statická typová kontrola neodhal´ı jiné váˇzné chyby, které 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á orientace zaloˇzená na prototypov´ ych objektech [Lie86]. Vzorov´ ym jazykem, zaloˇzen´ ym na prototypov´ ych objektech je Self [US87]. Pˇr´ımé pouˇzit´ı tohoto jazyka by pro naˇse u ´ˇcely bylo problematické z hlediska interoperability a portability, proto v´ yhodnˇe vyuˇzujeme toho, ˇze tento styl programován´ı je k dispozici pˇr´ımo ve Smalltalku d´ıky rozˇs´ıˇren´ı, které je implementováno v bal´ıku Prototypes [MA04]. Jde o jednoduch´ y framework pro Smalltalk, nikoliv o vnoˇren´ y jazyk. Jazykem pro specifikaci metod z˚ ustává Smalltalk. Na rozd´ıl od klasického beztˇr´ıdn´ıho OO jazyka Selfu [US87] jsou zde proto nˇekteré m´ırné odliˇsnosti: • Reprezentace objekt˚ u z˚ ustává zachována, takˇze se rozliˇsuj´ı datové 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é objekty s objekty definovan´ ymi tˇr´ıdami. • Vˇsechny prototypové objekty jsou instancemi tˇr´ıdy PrototypeObject, která je podtˇr´ıdou Behavior, stejnˇe jako metatˇr´ıdy. Základn´ı princip prototypov´ ych objekt˚ u lze charakterizovat takto: • Prototypov´ y objekt m´ a sloty, metody a delegáty (viz dále), um´ı reagovat na zpr´ avy. Reakce na zpr´ avu spoˇc´ıv´ a v proveden´ı odpov´ıdaj´ıc´ı metody nebo vrácen´ı obsahu odpov´ıdaj´ıc´ıcho slotu. • Dˇediˇcnost je realizována delegac´ı. Nerozum´ı-li objekt zpr´ avˇe, hledá se odpov´ıdaj´ıc´ı metoda (nebo slot) v delegátech, 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áty). • Nad libovoln´ ym prototypov´ ym objektem lze v libovolném okamˇziku otevˇr´ıt Inspektor, kter´ y umoˇzn´ı interaktivn´ı zkoumán´ı a editaci objektu. Typické pouˇzit´ı a souˇcasnˇe princip programován´ı bez tˇr´ıd si ukáˇzeme na pˇr´ıkladech. Vytvoˇ ren´ı pr´ azdn´ eho objektu

anObject ← PrototypeObject new.

46


Inspektor

anObject inspect .

V´ ysledkem je otevˇren´ı inspektoru (obr. 5.1).

Obrázek 5.1: Inspektor prototypového objektu Inspektor je kombinac´ı browseru a klasického smalltalkovského inspektoru, protoˇze prototypov´ y objekt je v podstatˇe kombinac´ı tˇr´ıdy a jej´ı instance. Pomoc´ı tohoto nástroje je moˇzné zkoumat a modifikovat stav objektu, ale také jeho metody a delegáty (delegáti jsou objekty, na které objekt deleguje zpr´ avy, které nen´ı s´ am schopen obslouˇzit – takto je v beztˇr´ıdn´ıch systémech realizováno sd´ılené chov´ an´ı mnoˇziny objekt˚ u, tj. dˇediˇcnost). Klonov´ an´ı

anotherObject ← anObject clone .

Klon je mˇelkou kopi´ı origin´ alu. Pro jiné neˇz mˇelké kopie je tˇreba vytvoˇrit vlastn´ı metody. Operace nad sloty

anObject addSlot : ’x ’ . anObject addSlot : ’x ’ withValue : 0. anObject removeSlot : ’x ’ .

Téhoˇz efektu lze doc´ılit pomoc´ı inspektoru. Staˇc´ı vybrat –slots– a sledovat instrukce, pˇr´ıpadnˇe vybrat konkrétn´ı 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éhoˇz efektu lze doc´ılit pomoc´ı inspektoru. Staˇc´ı vybrat –methods– a sledovat instrukce, pˇr´ıpadnˇe vybrat konkrétn´ı metodu a vyvolat kontextovou nab´ıdku.

´ Í SYSTEM ´ U ˚ PROTOTYPOVYMI ´ 5.4. MODELOVAN OBJEKTY

47

Operace nad deleg´ aty

anObject addDelegate : ’parent ’ withValue : (PrototypeObject new) . anObject removeDelegate : ’parent ’ .

Téhoˇz efektu lze doc´ılit pomoc´ı inspektoru – staˇc´ı kliknout na –delegates– a sledovat instrukce, pˇr´ıpadnˇe kliknout na konkrétn´ıho delegáta 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é objekty a ostatn´ı objekty Smalltalku jsou z vnˇejˇs´ıho pohledu zcela zamˇenitelné 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án´ı vyv´ıjej´ıc´ıch se systém˚ u vhodné pouˇz´ıt prototypové objekty. Tˇr´ıdn´ı pˇr´ıstup k modelován´ı 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ého z pˇredem zn´ am´ ych komponent. Druhá moˇznost je zbyteˇcnˇe komplikovan´ a, i kdyˇz ji v principu dynamické jazyky pˇripouˇstˇej´ı. D˚ uvodem je principiáln´ı statiˇcnost systému tˇr´ıd. Jakékoli dynamické modifikace toho v principu statického systému jsou sice moˇzné, ale jejich realizace je komplikovan´ a a ne kaˇzd´ y jazyk ji umoˇzn ˇuje. Je totiˇz tˇreba pˇri jakémkoli dynamickém zásahu zachovat konzistenci systému. 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é se zachován´ı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ákoliv dynamická manipulace s prototypov´ ymi objekty je trivi´ aln´ı, jak jsme vidˇeli v pˇredchoz´ı podkapitole. Omezuje se na klonován´ı a editaci objekt˚ u. Sd´ılené chován´ı, kv˚ uli kterému dávaj´ı tˇr´ıdy smysl, je jednoduˇse realizovatelné prostˇrednictv´ım delegace, kterou lze také 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áce s jak´ ymikoli dokumenty také spoˇc´ıv´ a v kop´ırován´ı a editaci. Chceme-li umoˇznit interaktivn´ı dynamické zásahy do simulace, je tento zp˚ usob manipulace s objekty velmi vhodn´ y d´ıky své jednoduchosti a pˇr´ımoˇcarosti. processor

jobDone

generator jobDone jobOut

jobIn discard discard

Obrázek 5.2: Gener´ ator a procesor.

48


Pˇ r´ıklad Nyn´ı ukáˇzeme pˇr´ıklad modelu, vytoˇreného inkrementálnˇ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é v´ yrazy vyhodnocovány 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 ] .

´ Í 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án vyhodnocen´ım v´ yrazu

system getSimulator simulate : 500.

V´ yˇse uveden´ y kód je skript, kter´ y zas´ılán´ım zpr´ av vhodn´ ym objekt˚ um inkrementálnˇe vytvoˇr´ı model. Kódy 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é z´ıskat komunikac´ı s objekty modelu. Napˇr. kód metody, kterou jsme dˇr´ıve zakompilovali do objektu, lze z´ıkat takto:

anObject methodSourceAt: aMethodName.

50


Pro takto inkrementálnˇe vytvoˇren´ y programov´ y systém nen´ı zp˚ usob jeho vytvoˇren´ı podstatn´ y, takˇze skript, kter´ y ho vytvoˇril, nechápeme jako zdrojov´ y kód v pravém slova smyslu. Takov´ y skript lze kdykoli pro existuj´ıc´ı systém 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ého 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ém modelu m˚ uˇzeme jednoduˇse pˇridat dalˇs´ı procesory naklonován´ım extuj´ıc´ıcho procesoru. Ale pozdˇejˇs´ı modifikace procesoru se pak dotknou jen jednoho exempláˇre. Chceme-li zajistit, aby vˇsechny procesory sd´ılely jednu definici, je tˇreba ji pˇresunout z procesoru do separátn´ı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é skuteˇcnosti a deleguj´ıc´ım zpracován´ı vˇsech ostatn´ıch zpr´ av na pˇr´ısluˇsn´ y trait. Klony takto definovaného procesoru pak sd´ıl´ı jednu definici a jej´ı pˇr´ıpadn´ a modifikace pak ovlivn´ı chován´ı 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ány stejnˇe jako u procesor ve v´ yˇse uvedeném 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án´ım delegace na trait zajist´ıme sd´ılen´ı definice chován´ı vˇsemi klony prototypu procesoru. Nyn´ı m˚ uˇzeme specifikovat systém s nˇekolika procesory stejného 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é delegovat zpracován´ı 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ém pˇr´ıstupu k objektové orientaci. Je moˇzn´ a i násobn´ a delegace i dynamicé zmˇeny této 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é 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ód, jehoˇz vyhodnocen´ım z´ık´ ame pˇr´ısluˇsnou struktutu, která 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ách, jako jsou jména slot˚ u, objekty, které jsou referencovány ze slot˚ u, metody, delegáti, komponenty sloˇzeného


52

modelu apod. Také m˚ uˇzeme klonovat a editovat cel´ y model nebo libovolnou jeho ˇcást, a to i v pr˚ ubˇehu simulace. M˚ uˇzeme pˇrid´ avat a odstraˇ novat komponenty, sloty, delegáty, metody apod. Tyto operace jsou pˇr´ıstupné uˇzivateli, resp. nadˇrazenému systému, ale také (reflektivnˇe) modelu, kterého se tyto operace t´ ykaj´ı.

5.7

Operaˇ cn´ı syst´ em

Pod pojmem operaˇcn´ı systém rozum´ıme veˇskeré programové prostˇredky pro podporu vytv´ aˇren´ı a bˇehu aplikaˇcnˇe specifického softwaru, vˇcetnˇe moˇznosti libovolné manipulace s n´ım. Jde o software, vytváˇ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ém, základn´ı vrstvu operaˇcn´ıho systému SmallDEVS tvoˇr´ı Smalltalk. Ten zahrnuje virtuáln´ı stroj, kompilátor, v´ıceprocesové prostˇred´ı, knihovnu tˇr´ıd, vstupy a v´ ystupy a interaktivn´ı v´ yvojové nástroje, z nichˇz pro SmallDEVS jsou podstatné nástroje Workspace a Inspector.1 Workspace umoˇzn ˇuje editaci text˚ u a interaktivn´ı vyhodnocován´ı fragment˚ u kódu. V´ ysledné objekty mohou b´ yt zkoumány v textové podobˇe nebo prostˇrednictv´ım inspektor˚ u. Inspektor umoˇzn ˇuje zkoumat stav objektu, komunikovat s n´ım a editovat jeho aktuáln´ı stav. Model, kter´ y byl prezentován vpˇredchoz´ıch sekc´ıch, m˚ uˇze byt vytvoˇren vyhodnocen´ım pˇr´ısluˇsného kódu ve Workspace. Stejn´ ym zp˚ usobem lze model zkoumat i editovat, jak jiˇz bylo ukázáno. Lze téˇ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éˇz cel´ y model v libovolném okamˇziku klonovat:

savedSystem ← system copy . 1

Ostatn´ı n´ astroje Smalltalku, jako je Browser, Debugger apod., jsou ovˇsem také k dispozici.

ˇ Í 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ámci Workspace. Systematiˇctˇejˇs´ı pˇr´ıstup je zaloˇzen na vyuˇzit´ı hierarchického 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álnˇe bˇeˇz´ıc´ıch simulac´ı) i libovolnou jeho ˇcást lze v libovolném okamˇziku klonovat, pˇr´ıpadnˇe v textové formˇe uloˇzit na extern´ı médium nebo pˇrenést do jiného 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ástroji, které jsou souˇcást´ı operaˇcn´ıho systému Smalltalku. Prostˇred´ı SmallDEVS ale nav´ıc poskytuje specializované vizuáln´ı nástroje pro sugestivnˇejˇsi a pˇrehlednˇejˇs´ı manipulaci s modely a simulacemi. Tyto nástroje byly inspirovány nástroji pro manipulaci s prototypov´ ymi objekty v systému Self [US87]. Self je jazyk a systém, zaloˇzen´ y na prototypov´ ych objektech. Základn´ım vizuáln´ım nástrojem program´ atora je tak zvan´ y Outliner. Jde o nástroj, umoˇzn ˇuj´ıc´ıc´ı zkoumat a modifikovat strukturu objektu. Srovnáme-li tento nástroj se nástroji Smalltalku, Outliner spojuje funkˇcnost Browseru a Inspectoru, protoˇze v systému Self pojem tˇr´ıda a instance spl´ yvaj´ı v jeden koncept – objekt obsahuje data i metody. V prostˇred´ı systému Self jsou vizualizovatelné vztahy (reference) mezi objekty a je moˇzné s obsahy slot˚ u (referencemi na objekty) manipulovat kop´ırován´ım a vklád´ an´ım (copy-paste), resp. pˇresouv´ an´ım (drag-and-drop). Refaktoring objekt˚ u (pˇremist’ován´ı slot˚ u mezi r˚ uzn´ ymi objekty) je tak moˇzné provádˇet intuitivn´ım, konkrétn´ım a bezprostˇredn´ım zp˚ usobem. Velmi podobnˇe se manipuluje s dokumenty a sloˇzkami pomoc´ı vizuáln´ıch interaktivn´ıch nástroj˚ u soudob´ ych operaˇcn´ıch systém˚ u – ty umoˇzn ˇuj´ı vytváˇret, vyj´ımat, kop´ırovat, vkládat, pˇrejmenovávat 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é struktuˇre M yRepository. Rozd´ıl oproti manipulaci se soubory je ten, ˇze jde o ˇzivé objekty, pˇr´ıpadnˇe bˇeˇz´ıc´ı simulace (nikoliv pojmenované ˇretˇezce zvané soubory) a vˇse se odehr´ avá v operaˇcn´ı pamˇeti, nikoliv na extern´ım médiu (pˇr´ıpadn´ a externalizace objekt˚ u v textové podobˇe je ovˇsem moˇzn´ a, jak bylo uvedeno v´ yˇse). Podstatnou vlastnost´ı vizuáln´ıch nástroj˚ 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ástroji nebo zda vznikly jako v´ ysledek bˇehu program˚ u. Této transparentnosti je dosaˇzeno t´ım, ˇze se nepracuje se zdrojov´ ymi texty objekt˚ u, ale pracuje se s objekty pˇr´ımo (zdrojové texty se neuchovávaj´ı, protoˇze jsou zbyteˇcné, jak jiˇz bylo uvedeno).


54

Kaˇzd´ y objekt je moˇzné zkoumat a editovat. Podle typu objektu se otevˇre odpov´ıdaj´ıc´ı nástroj. Ke zkoumán´ı a editaci obecn´ ych objekt˚ u slouˇz´ı PrototypeObjectInspector (obr. 5.1), ke zkoumán´ı a modifikaci MyRepository slouˇz´ı MyRepositoryBrowser (obr. 5.3 vlevo nahoˇre), ke zkoumán´ı atomick´ ych model˚ u slouˇz´ı AtomicModelExplorer (obr. 5.3 vlevo dole), ke zkoumán´ı 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ástroj se otevˇre automaticky v d˚ usledku vyhodnocen´ı v´ yrazu

anObject open.

Obrázek 5.3: SmallDEVS – vizuáln´ı nástroje pro manipulaci s modely a simulacemi

5.8

Aplikaˇ cn´ı rozhran´ı j´ adra SmallDEVS

Obrázek 5.4 ukazuje kompozici protokol˚ u AtomicDEVSPrototype, CoupledDEVSPrototype, PrototypeObjectForSimulation, AtomicDEVSTrait, MyRepository a DEVSRootSolverRT. Jde o kompletn´ı aplikaˇcn´ı rozhran´ı jádra SmallDEVS, dostupné jak vizuáln´ım v´ yvojov´ ym nástroj˚ um, tak program˚ um a skript˚ um pro tvorbu model˚ u a manipulaci s nimi.

´ 5.9. POZNAMKA K IMPLEMENTACI

55

Obrázek 5.4: Aplikaˇcn´ı rozhran´ı jádra SmallDEVS.

5.9

Pozn´ amka k implementaci

SmallDEVS je implementován ve Smalltalku za pouˇzit´ı rozˇs´ıˇren´ı Prototypes. M˚ uˇze b´ yt cháp´ an jako vzor, podle kterého lze prezentovan´ y koncept realizovat i v jiném 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ého interpretu vhodného dynamického jazyka s inkrementáln´ım kompilátorem.

56


Kapitola 6

Specifikace syst´ em˚ u s diskr´ etn´ımi ud´ alostmi objektovˇ e orientovan´ ymi Petriho s´ıtˇ emi Pˇr´ımé pouˇzit´ıt´ı formalismu DEVS pro specifikaci systému nemus´ı b´ yt vˇzdy v´ yhodné. Problematické jsou zejména pˇr´ıpady, kde se struktura systém˚ u mˇen´ı pˇr´ıliˇs rychle a komplikovanˇe. Rekonfigurovat strukturu sloˇzeného modelu by je pak bylo pˇr´ıliˇs obt´ıˇzné. Lepˇs´ı moˇznost´ı je v takov´ ych pˇr´ıpadech pouˇz´ıt objektové paradigma s adresovateln´ ymi objekty a zas´ılán´ım zpr´ av. Jako optimáln´ı se jev´ı kombinace, ve které je DEVS pouˇzit pro strukturován´ı systému do v´ıceménˇe statick´ ych komponent, zat´ımco dynamicky vznikaj´ıc´ı a zanikaj´ıc´ı objekty jsou pouˇzity uvnitˇr atomick´ ych komponent DEVS. V následuj´ıc´ım textu je pops´ ana moˇznost definovat systém s diskrétn´ımi událostni 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é komponenty DEVS. Pˇritom je zohlednˇena moˇznost dynamick´ ych zásah˚ u do bˇeˇz´ıc´ı simulace v souladu s konceptem otevˇreného systému, definovaného v kapitole 4.

6.1

Petriho s´ıtˇ e a objekty

Základn´ı koncept Petriho s´ıt´ı definoval v ˇsedes´ at´ ych letech C. A. Petri. Jde o matematick´ y stroj se sugestivn´ı vizuáln´ı reprezentac´ı, kter´ y srozumitelnˇe modeluje synchronizaci a komunkaci proces˚ u v paraleln´ıch a distribuovan´ ych systémech. Existuje celá ˇrada variant Petriho s´ıt´ı. Na tomto m´ıstˇe se soustˇred´ıme pˇredevˇs´ım na vysoko´ urovˇ nové Petriho s´ıtˇe, konkrétnˇe pak na Objektovˇe orientované Petriho s´ıtˇe (OOPN) [Jan95, Jan98, MVT97, MVT02, JK07]. Ostatn´ı bˇeˇznˇe pouˇz´ıvané typy Petriho s´ıt´ı jsou subformalismy objektovˇe orientov´ ych Petriho s´ıt´ı.1 Konkrétn´ı implementac´ı OOPN je interpret jazyka PNtalk [PNt06, JK03, JK05a, JK05b, MVR+ 06]. 1 Objektovˇe orentované 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ém 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ána formou bipartitn´ıho orientovaného grafu, obsahuj´ıc´ı dva typy uzl˚ u – m´ısta a pˇrechody – propojené 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ému je modelov´ an rozloˇzen´ım znaˇcek v m´ıstech. Ke zmˇen´ am stavu docház´ı v d˚ usledku provádˇen´ı pˇrechod˚ u. Pˇrechod m´ a definována 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é jsou specifikovánu 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é v´ ystupn´ımi hranami. Ve vysoko´ urovˇ nové Petriho s´ıt´ı mohou znaˇcky reprezentovat libovolná data, která mohou b´ yt provádˇen´ım pˇrechod˚ u libovolnˇe zpracováv´ ana. V´ yrazy na hran´ ach specifikuj´ı multimnoˇziny znaˇcek. Mohou obsahovat promˇenné. Ty mus´ı b´ yt v rámci provedej´ı pˇrechodu navázány na konkrétn´ı hodnoty. Pˇrechod m˚ uˇze nav´ıc obsahovat stráˇzn´ı podm´ınku, jej´ıˇz splnˇen´ı je vyˇzadováno pro proveden´ı pˇrechodu. Kromˇe toho m˚ uˇze obsahovat akci, která 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é Petriho s´ıti (bez stráˇzn´ı podm´ınky a akce). Obsahuje promˇenné x a y. Je provediteln´ y pro dvˇe r˚ uzn´ a navázán´ı promˇenn´ ych {x = 1, y = A} a {x = 1, y = B}. Jeho proveden´ı je realizováno 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ázek 6.1: Proveden´ı pˇrechodu ve vysoko´ urovˇ nové Petriho s´ıti pro navázán´ı 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ém. Takov´ y systém lze popsat jako abstraktn´ı matematick´ y stroj, kter´ y m´ a strukturu a chován´ı. Struktura objektovˇe orientovaného systému je urˇcena mnoˇzinou tˇr´ıd, specifikuj´ıc´ıch reprezentaci instanc´ı (instanˇcn´ı promˇenné) a mnoˇzinu metod, vˇcetnˇe tzv. implicitn´ı metody, popisuj´ıc´ı implicitn´ı aktivitu objektu. Dynamika systému spoˇc´ıv´ a v postupn´ ych zmˇen´ ach stavu (pˇriˇcemˇz jeden stav je definován jako v´ ychoz´ı). Stav objektovˇe orientovaného systému je dán mnoˇzinou momentálnˇe existuj´ıc´ıch objekt˚ u. Kaˇzd´ y z nich se nacház´ı ve stavu, kter´ y je dán hodnotami instanˇcn´ıch promˇenn´ ych a stavy vˇsech momentálnˇe existuj´ıc´ıch (rozpracovan´ ych) metod. Evoluci (postupné zmˇeny stavu) tohoto systému lze pak definovat pravidly,

ˇ A OBJEKTY 6.1. PETRIHO SÍTE

59

specifikuj´ıc´ımi podm´ınky v´ yskytu jist´ ych událost´ı a zmˇeny stavu pˇri v´ yskytu tˇechto událost´ı. V paraleln´ım objektovˇe orientovaném systému existuj´ı ˇctyˇri typy událost´ı: 1. Ud´ alost typu A – zmˇena stavu objektu bez interakce s ostatn´ımi objekty. 2. Ud´ alost typu N – vytvoˇren´ı nového objektu pˇri zasl´ an´ı zpr´ avy new pˇr´ısluˇsné tˇr´ıdˇe. 3. Ud´ alost typu F – vytvoˇren´ı nové 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ást´ı kaˇzdé události je garbage collecting, tedy odstranˇen´ı nedostupn´ ych objekt˚ u. Ud´ alosti mˇen´ı stav systému. Objekty v rámci systému mohou dynamicky vznikat a zanikat, stejnˇe tak i instance metod. Obrázek 6.2 ukazuje dekompozici procesu systému do objekt˚ u, skl´ adaj´ıc´ıch se z proces˚ u metod (v ˇcasovém 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ázek 6.2: Proces systému (a) a jeho dekompozice do objekt˚ u (b). Objekt o0 je hlavn´ı (prvotn´ı) objekt, existuj´ıc´ı po dobu existence systému. Objekt o1 je dále dekomponován 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ém lze podle [Jan98] popsat Petriho s´ıtˇemi takto: 1. Kaˇzd´ a metoda je definována 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á je implicitnˇe vyvolána vznikem objektu) nazveme s´ıt’ objektu. Tˇr´ıda je specifikována 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é 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ány za souˇcást pˇrechod˚ u).


60

5. Metody jsou invokovány zas´ılán´ım zpr´ av. Zasl´ an´ı zpr´ avy m˚ uˇze b´ yt specifikováno anotac´ı pˇrechodu, patˇr´ıc´ıho nˇekteré s´ıti metody nebo s´ıti objektu. 6. Nˇekteré pˇrechody s´ıtˇe objektu jsou prohláˇseny za speciáln´ı metody (tzv. synchronn´ı porty), urˇcené pro pro atomickou synchronn´ı komunikaci, realizovanou zas´ılán´ım zpr´ av ze stráˇ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ázek 6.3: Anotace pˇrechodu – stráˇz a akce. V objektovˇe orientovaném systému se veˇskeré v´ ypoˇcty realizuj´ı zas´ılán´ım zpr´ av. V OOPN je zas´ılán´ı zpr´ av moˇzné specifikovat v rámci akc´ı a stráˇz´ı pˇrechod˚ u (viz obr. 6.3). Adresátem 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át, a tedy odpov´ıdaj´ıc´ı metoda, se zjist´ı v rámci zjiˇst’ován´ı 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é ve stráˇzi pˇrechodu, je interpretováno jako atomick´ a synchronn´ı interakce, která spoˇc´ıv´ a v invokaci synchronn´ıho portu (viz dále). Zasl´ an´ı zpr´ avy, specifikované v akci pˇrechodu, je interpretováno jako invokace s´ıtˇe metody.

6.1.5

Invokace metod objekt˚ u zas´ıl´ an´ım zpr´ av

S´ıtˇe metod, specifikované jako souˇcást tˇr´ıd, jsou urˇceny k dynamické instanciaci v reakci na pˇr´ıchoz´ı zpr´ avy. Pˇrijet´ı zpr´ avy objektem odpov´ıd´ a události typy F (fork, vytvoˇren´ı nového procesu metody). V´ ysledkem je vytvoˇren´ı nové instance (kopie) odpov´ıdaj´ıc´ı s´ıtˇe metody (a pˇr´ıpadné 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álosti 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ásti 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áˇzi pˇrechodu je interpretováno jako atomick´ a synchronn´ı komunikace. Jde o komunikaˇcn´ı koncept, umoˇzn ˇuj´ıc´ı podm´ınit proveditelnost pˇrechodu souˇcasnou proveditelnost´ı jiného (volaného) pˇrechodu, nazvaného synchronn´ı port. Jsou-li oba pˇrechody proveditelné, mohou b´ yt provedeny, a to synchronnˇe, jako jedna atomická operace. Synchronn´ı port lze povaˇzovat za speciáln´ı druh metody, kterou lze volat ze stráˇze jiného 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ázek 6.4: Invokace metody.

modelován´ı synchronizace aktivit objekt˚ u ve v´ıce´ urovˇ nov´ ych modelech [?]. Princip atomické synchronn´ı interakce, respektuj´ıc´ı polymorfismus a navázán´ı 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ázek 6.5: Atomická 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án´ı do OOPN zaveden také 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átu 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éˇz je pops´ ana i jeho konkrétn´ı implementace, jazyk a systém PNtalk. Vzhledem k pomˇerné rozs´ ahlosti origin´ aln´ı definice jsou dále uvedeny jen nejd˚ uleˇzitˇejˇs´ı pojmy a jejich souvislosti, které jsou nutné 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ána jako trojice OOP N = (Σ, c0 , oid0 ), kde Σ je systém tˇr´ıd, c0 je poˇcáteˇcn´ı tˇr´ıda a oid0 je jméno prvotn´ıho objektu, kter´ y je instanc´ı c0 . Systém tˇr´ıd zahrnuje mnoˇzinu tˇr´ıd, hierarchicky uspoˇrádanou podle relace dˇediˇcnosti. Kaˇzdé tˇr´ıdˇe pˇr´ısluˇs´ı mnoˇzina jmen instanc´ı (doména) a je pro ni definována 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ém tˇr´ıd mus´ı splˇ novat jisté


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é byla tato s´ıt’ definována. Anotace Petriho s´ıt´ı jsou specifikovány inskripˇcn´ım jazykem umoˇzn ˇuj´ıc´ım pracovat také 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ále obsahuje synchronn´ı port state: a metody waitFor: a reset. Poznamenejme, ˇze tento pˇr´ıklad nemodeluje nic smysluplného, 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ázek 6.6: Pˇr´ıklad OOPN.

6.2.2

Reprezentace stavu OOPN

Stav OOPN je definován jako systém objekt˚ u. Objekt je definován jako systém instanc´ı s´ıt´ı, obsahuj´ıc´ı v daném stavu právˇe jednu instanci s´ıtˇe objektu a mnoˇzinu instanc´ı s´ıt´ı metod, které jsou v daném stavu rozpracovány. Kaˇzd´ a instance s´ıtˇe je dvojice (id, m), kde id je jméno instance s´ıtˇe a m je znaˇcen´ı této s´ıtˇe (obsahuje znaˇcen´ı m´ıst i pˇrechod˚ u). Znaˇcen´ı m kaˇzdému 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ému pˇrechodu mnoˇzinu invokac´ı (rozpracovan´ ych metod). Systém objekt˚ u je uzavˇrený, tj. zaruˇcuje, ˇze znaˇcen´ı vˇsech instanc´ı s´ıt´ı ve vˇsech objektech referencuj´ı pouze instance s´ıt´ı obsaˇzené v systému objekt˚ u. Také je zaruˇceno, ˇze neobsahuje objekty, které by nebyly tranzitivnˇe dostupné z prvotn´ıho objektu. Poˇca ´teˇcn´ı systém objekt˚ u objektovˇe orientované Petriho s´ıtˇe OOP N = (Σ, c0 , id0 ) obsahuje jedin´ y objekt, identifikovan´ y jménem id0 , kter´ y je instanc´ı poˇcáteˇcn´ı tˇr´ıdy c0 . Znaˇcen´ı jeho s´ıtˇe objektu odpov´ıd´ a poˇcáteˇcn´ımu znaˇcen´ı této s´ıtˇe, specifikované ve tˇr´ıdˇe c0 . Pˇ r´ıklad Uvaˇzujme OOPN specifikovanou tˇr´ıdami na obr´ azku 6.6. Poˇcáteˇcn´ı stav této OOPN je definován 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éˇz jménem jako instance jeho s´ıtˇe objektu, a sice id0 . Poˇcáteˇ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ému objekt˚ u – poˇcáteˇcn´ı stav s0 .

6.2.3

Dynamika OOPN

Dynamika OOPN je definována poˇcáteˇcn´ım systémem objekt˚ u a pravidly specifikuj´ıc´ımi proveditelnost a provádˇen´ı pˇrechod˚ u v instanc´ıch s´ıt´ı. Proveden´ı pˇrechodu je událost, formalizovan´ a jako ˇctveˇrice (e, id, t, b), kde e specifikuje typ události (A, N , F nebo J, viz 6.1.2, str. 59), jméno id identifikuje instanci s´ıtˇe, ve které k události doˇslo, t identifikuje pˇrechod jehoˇz proveden´ı událost zp˚ usobilo a b je navázán´ı promˇenn´ ych pˇrechodu t. V´ yskyt ′ události (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álnˇe b´ yt proveden ˇctyˇrmi zp˚ usoby, které odpov´ıdaj´ı ˇctyˇrem typ˚ um událost´ı z 6.1.2. Pˇrechod m˚ uˇze b´ yt pro jisté navázán´ı 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átem zpr´ avy je objekt, kter´ y m´ a pˇr´ısluˇsnou metodu definovánu 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ávˇ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ásledek vytvoˇren´ı nového objektu, tj, invokaci pˇr´ısluˇsné s´ıtˇe objektu, F-proveden´ı m´ a za následek invokaci pˇr´ısluˇsné s´ıtˇe metody a uplatn´ı se jen vstupn´ı hrany pˇrechodu, J-proveden´ı m´ a za následek odstranˇen´ı pˇr´ısluˇsné 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ému pˇrechodu mnoˇzinu invokac´ı, tj. dvojic (id, b), kde id je identifikace (jméno) vytvoˇrené instance s´ıtˇe a b je navázán´ı promˇenn´ ych pˇrechodu pˇri jeho F-proveden´ı. Ud´ alosti tvaru (e, id, t, b) postupnˇe modifikuj´ı stav systému. V jednom okamˇziku (v daném stavu) m˚ uˇze potenciálnˇe nastat nˇekolik událost´ı (je zde potenciálnˇ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ásteˇ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 .


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ému objekt˚ u – stav s5 . V´ ysledn´ y stav s5 je specifikován tabulkou 6.2. Stav s5 obsahuje dva objekty identifikované jmény 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é jako id1, id2 a id3. Instance s´ıt´ı s jmény id2 a id3 jsou invokacemi metody waitFor:, vytvoˇrené proveden´ım pˇrechodu t2 v objektu id1.

6.3

Simul´ ator OOPN

Simulace OOPN spoˇc´ıv´ a v opakovaném provádˇen´ı kroku simulace. V rámci simulaˇcn´ıho kroku se provede testován´ı proveditelnosti pˇrechod˚ u v jednotliv´ ych instanc´ıch s´ıt´ı, tvoˇr´ıc´ıch systém objekt˚ u. Z provediteln´ ych pˇrechod˚ u je pak vybr´ an jeden a proveden. Pro práci se simulaˇcn´ım ˇcasem je vˇsak tˇreba tento koncept upravit a zavést moˇznost specifikovat ˇcekán´ı. Stejnˇe jako ostatn´ı aktivity, tok ˇcasu se v OOPN specifikuje zas´ılán´ım ˇ an´ı v simulaˇcn´ım ˇcase je specifikováno akc´ı tvaru self zpr´ av v rámci akc´ı pˇrechod˚ u. Cek´ hold: t. Proveden´ı pˇrechodu je v takovém 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ást pˇrechodu. Pl´ anován´ı událost´ı je v simul´ atoru OOPN realizováno kalend´ aˇrem. Pr˚ ubˇeh simulace je následuj´ıc´ı: 1. Dokud existuje provediteln´ y pˇrechod, provede se. Pˇri provádˇen´ı pˇrechod˚ u se do kalendáˇre umist’uj´ı pl´ anované události ve tvaru (ˇcas, událost). Jde o události typu J (dokonˇcen´ı rozpracovaného pˇrechodu), které se pl´ anuj´ı v d˚ usledku ˇcekán´ı, specifikovaného akc´ı self hold: t. 2. Nen´ı-li ˇzádn´ y pˇrechod provediteln´ y, dojde k posuvu ˇcasu podle nejbliˇzˇs´ı pl´ anované události a událost (t.j. dokonˇcen´ı ˇcekaj´ıc´ıcho pˇrechodu) se provede. Pokraˇcuje se bodem 1. Simul´ ator OOPN pˇripouˇst´ı také zasl´ an´ı zpr´ avy self hold: t ve stráˇzi pˇrechodu. V takovém pˇr´ıpadˇe je stráˇz splnˇena (a pˇrechod se m˚ uˇze provést), pokud je pˇrechod nepˇretrˇzitˇe provediteln´ y po specifikovanou dobu.

ˇ Í 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ém s diskrétn´ımi událostmi v souladu s definic´ı DEVS. To nám 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ás´ı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ém˚ u objekt˚ u, dosaˇziteln´ ych z poˇcáteˇcn´ıho systému 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á funkce δint realizuje proveden´ı jedné události v OOPN, pl´ anované na aktuáln´ı ˇcas. V pˇr´ıpadˇe konfliktu se vybere jedna událost pomoc´ı preferenˇcn´ı funkce select, definované podobnˇe, jako v pˇr´ıpadˇe sloˇzen´ ych model˚ u DEVS (vybere jeden z libovolné 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ásleduj´ıc´ı pl´ anované události v OOPN, tj. bud’ 0, existuje-li alespoˇ n jeden provediteln´ y pˇrechod v aktuáln´ım ˇcase, nebo (tc −t), kde tc je ˇcas nejbliˇzˇs´ı pl´ anované události v kalend´ aˇri a t je ˇcas aktuáln´ı, je-li v kalen´ aˇri alespoˇ n jedna poloˇzka. Je-li kalend´ aˇr prázdn´ y, ta vrac´ı hodnotu ∞ (systém je pasivován). • Extern´ı pˇrechodová 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án souladu s principy otevˇrené abstraktn´ı architektury pro simulaci vyv´ıjej´ıc´ıch se systém˚ u, popsané v kapitole 4. Dynamické 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é manipulace konzistentn´ı systém objekt˚ u dle definice [Jan98], simulace po tomto zásahu korektnˇe pokraˇcuje, v opaˇcném pˇr´ıpadˇe je simulace ukonˇcena v d˚ usledku chyby. Tˇr´ıdy OOPN jsou v PNtalku globálnˇe dostupné jménem. Pˇr´ıstup k metodám uvnitˇr tˇr´ıdy je moˇzn´ y prostˇrednitv´ım jména (selektoru odpov´ıdaj´ıc´ı zpr´ avy). S´ıt’ objektu je dostupná pod jménem #object. Uzly Petriho s´ıt´ı jsou také pˇr´ıstupné prostˇrednictv´ım sv´ ych jmen. Tˇr´ıdy, metody, m´ısta a pˇrechody rozumˇen´ı zpr´ avám, které 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é je pˇrechod provediteln´ y.

66


Podobnˇe lze pˇristupovat k reprezentaci aktuáln´ıho stavu. Jde o systém objekt˚ u, zapouzdˇruj´ıc´ıch mnoˇziny proces˚ u. Hlavn´ı objekt je v PNtalku globálnˇe pˇr´ıstupn´ y pod jménem #main. Objekty jsou dostupné prostˇrednictv´ım referenc´ı, které se vyskytuj´ı v podobˇe znaˇcek v m´ıstech Petriho s´ıt´ı. Procesy metod jsou prováz´ any relac´ı invokace do hierarchické struktury, která 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é sloˇzky stavu lze ˇc´ıst i editovat pouˇzit´ım adekvátn´ıch metaoperac´ı. Integrace OOPN do prostˇ red´ı SmallDEVS Interpret OOPN (PNtalk) s dynamick´ ym aplikaˇcn´ım rozhran´ım je intergrován do prostˇred´ı SmallDEVS (popsaného v kapitole 5), kde umoˇzn ˇuje specifikovat atomické 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é 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áln´ımi nástroji. Procesy OOPN jsou v MyRepository pˇr´ıstupné 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é 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ému s diskrétn´ımi událostmi v souladu s definic´ı DEVS d´ıky kompatibiln´ımu zapouzdˇren´ı. V návaznosti na definici otevˇrené abstraktn´ı architektury pro simulaci vyv´ıjej´ıc´ıch se systém˚ u, která byla uvedena za pouˇzit´ı formalismu DEVS, lze definovat dynamické aplikaˇcn´ı rozhran´ı i pro simul´ ator OOPN. Praktickou implementac´ı je systém PNtalk/SmallDEVS, kter´ y umoˇzn ˇuje atomické komponenty DEVS specifikovat formalismem OOPN. Specifikace atomick´ ych komponent sloˇzeného 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án´ı a návrhu systém˚ u je demonstrována následuj´ı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émantiku. 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ázek 7.1: Mapován´ı mezi modely a simul´ atory Pˇripomeˇ nme si nejprve princip hierarchické simulace DEVS. Kaˇzdému 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ého implementaˇcn´ıho formalismu. Origináln´ı abstraktn´ı simul´ ator DEVS podle [ZKP00] je specifikován s ohledem na implementaci v bˇeˇzném prog. jazyce a proto obsahuje referenci na nadˇrazen´ y simul´ ator a komunikuje pˇr´ım´ ym pˇred´ aván´ım zpr´ av adresátovi (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é a propojen´ı je definováno s vyuˇzit´ım jmen komponent a port˚ u). Algoritmy a struktura simul´ atoru a koordinátoru proto mus´ı b´ yt upraveny pro takto volnˇe vázané hierarchicky organizované komponenty komunikuj´ıc´ı asynchronˇe pˇred´ avan´ ymi zpr´ avami. Lze pˇritom vyj´ıt napˇr. z [Van00] (podobnˇe jsou specifikovány 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éna odesilatele, resp. pˇr´ıjemce. Toto

68

´ KAPITOLA 7. REFLEKTIVNÍ SIMULATOR DEVS

adresován´ı umoˇzn´ı pˇripojit v´ıce komponent na jeden port, coˇz zjednoduˇs´ı propojován´ı (pˇrid´ aván´ı dedikovan´ ych port˚ u pro kaˇzdou komponentu kompozitu by model ponˇekud zkomplikovalo). Simul´ ator atomick´ eho modelu Simul´ ator atomického modelu specifikujeme jako systém 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ána do promˇenn´ ych tlast , tnext , y, (s, e). Funkce δint , δext , λ, ta jsou definovány tak, aby systém reagoval na vstupn´ı události podle specifikace uvedené v kap. 2 v závislosti na specifikaci atomického modelu M = (X, S, Y, δint , δext , λ, ta), definovaného taktéˇz v kap. 2. Simul´ ator sloˇ zen´ eho modelu Simul´ ator sloˇzeného modelu (koordinátor) specifikujeme jako systém 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ána do promˇenn´ ych tlast , tnext , y, eventList receivers, activeChildren (viz algoritmus simul´ atoru v kap. 2). Funkce δint , δext , λ, ta jsou definovány tak, aby systém reagoval na vstupn´ı události podle specifikace uvedené v kap. 2. v závislosti na specifikaci sloˇzeného modelu N = (X, Y, D, {Md }, EIC, EOC, IC, select), definovaného taktéˇz v kap. 2. Koˇ renov´ y simul´ ator Koˇrenov´ y simul´ ator specifikujeme jako systém 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ána do promˇenn´ ych, reprezentuj´ıc´ıch stav simulace, aktuáln´ı ˇcas t a ˇcas následuj´ıc´ıc událost´ı tnext . Funkce δint , δext , λ, ta jsou definovány tak, aby systém reagoval na vstupn´ı události prováden´ı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án 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ákladˇe modelu se jednou nar´ az zkonstruuje celá struktura simul´ atoru pomoc´ı kompilátoru DEVS do DEVS. Takto lze pracovat s DEVS podle p˚ uvodn´ı (statické) definice. Jinou moˇznost´ı je v reflektivn´ım simul´ atoru zpˇr´ıstupnit kompletn´ı aplikaˇcn´ı rozhran´ı pro dynamické vytváˇren´ı, inspekci a editaci model˚ u (a jejich simul´ ator˚ u). Pak m´ ame na zaˇcátku k

69

Obrázek 7.2: Model gener´ atoru a procesoru

Obrázek 7.3: Model simul´ atoru modelu gener´ atoru a procesoru dispozici pouze koˇrenov´ y simul´ ator s prázdn´ ym modelem. D´ıky zpˇr´ıstupnˇen´ ym operac´ım lze pak dynamicky vytváˇ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á, ˇze pro doménovou u ´roveˇ n i pro meta´ uroveˇ n je pouˇzit tent´ yˇz formalismus. Potenciálnˇe je moˇzné pro r˚ uzné u ´rovnˇe pouˇz´ıt r˚ uzné formalismy, resp. jazyky. Nyn´ı zv´ aˇz´ıme moˇznost pouˇzit´ı jiného formalismu, konkrétnˇ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án´ı 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é implementaci simul´ atoru DEVS pomoc´ı DEVS), ale pouˇzijeme pˇr´ımé mapován´ı formalismu DEVS do formalismu OOPN. Mapován´ı atomického modelu DEVS do OOPN je ukázáno na obr´ azku 7.4. Mechanismus zpracován´ı vstup˚ u, modifikace stavu a generován´ı v´ ystup˚ u je specifikován vysoko´ urovˇ novou Petriho s´ıt´ı. Kaˇzd´ y konkrétn´ı model, implementovan´ y jako podtˇr´ıda AtomicDEV S, specifikuje (1) funkce DEVS, které jsou realizovány odpov´ıdaj´ı-

´ KAPITOLA 7. REFLEKTIVNÍ 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ázek 7.4: DEVS v OOPN c´ımi metodami v OOPN, a (2) poˇcáteˇcn´ı znaˇcen´ı m´ısta s, které obsahuje poˇcáteˇcn´ı stav modelu. Tento pˇr´ıstup je moˇzné témˇeˇr beze zmˇeny pouˇz´ıt pro mapován´ı DEVS do CPN (Coloured Petri nets), implementovan´ ych nástrojem 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ázi DEVS s vyuˇzit´ım standardn´ıho nástroje pro vysoko´ urovˇ nové Petriho s´ıtˇe.

Kapitola 8

Pˇ r´ıpadov´ a studie: Simulace simuluj´ıc´ıho syst´ emu Simuluj´ıc´ı systém je systém, jehoˇz souˇcást´ı je simulace. Simuluje-li systém s´ am sebe a pouˇz´ıv´ a-li v´ ysledky vlastn´ı simulace pro modifikaci svého vlastn´ıho chován´ı v budoucnu, jde o reflektivn´ı simulaci. Do tˇr´ıdy simuluj´ıc´ıch systém˚ u typicky patˇr´ı systémy, jejichˇz souˇcást´ı je rozhodovac´ı proces, obsahuj´ıc´ı simulaci. Takové systémy 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ého problému v r´ amci sloˇzitého systému. Pˇritom d˚ usledky jednotliv´ ych ˇreˇsen´ı nen´ı moˇzné analyticky zjistit ani jednoduˇse otestovat. Jedin´ ym ˇreˇsen´ım je pro vˇsechny návrhy expert˚ u provést simulaˇcn´ı experimenty, jejich v´ ysledky porovnat a poté provést rozhodnut´ı. Simulace simuluj´ıc´ıch systém˚ u pak dává smysl jako souˇcást procesu rozhodován´ı problém˚ u, t´ ykaj´ıc´ıch se simuluj´ıc´ıch systém˚ u. Jako pˇr´ıklad uvedeme optimalizaci poˇctu otevˇren´ ych pˇrep´ aˇzek v bance v závislosti 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ázek 8.1 ukazuje systém, kter´ y chceme simulovat. Jde velmi zjednoduˇsenou abstrakci hypotetické banky, kde klienti nejprve ˇcekaj´ı ve frontˇe, by byli obslouˇzeni u ´ˇredn´ıkem (teller) zpracovávaj´ıc´ım jejich poˇzadavky. Poté je (po ˇcekán´ı 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é 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ástech dne, které se liˇs´ı ˇcetnost´ı pˇr´ıchodu klient˚ u do banky. Rozliˇsuj´ı se tˇri obdob´ı, která 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ém simulován, jde o vnoˇrenou simulaci): Na zaˇcátku kaˇzdé periody se opakovanˇe provede simulace prvn´ı ˇcásti systému (tj. fronty s mnoˇzinou pˇrep´ aˇzek prvn´ıho typu – teller) pro r˚ uzné poˇcty u ´ˇredn´ık˚ u (tellers) v rozsahu od 1 do celkového poˇctu dostupn´ ych u ´ˇredn´ık˚ u (10). Na základˇe v´ ysledk˚ u jednotliv´ ych simulac´ı veden´ı banky urˇc´ı poˇcty

72

´ KAPITOLA 8. SIMULACE SIMULUJÍCÍHO SYSTEMU

Obrázek 8.1: Systém hromadné obsluhy se dvˇema frontami a obsluˇzn´ ymi linkami (pˇrevzato z [Skl97])

Obrázek 8.2: Základn´ı idea vnoˇrené simulace (pˇrevzato z [Skl97])

ˇ 8.2. MODEL S VNORENOU SIMULACÍ V JAZYCE SIMULA

73

u ´ˇredn´ık˚ u pro pˇrep´ aˇzky prvn´ıho typu (tellers) a druhého typu (cashiers). Pro jednoduchost v naˇsem simulaˇcn´ım modelu ponecháme v´ ybˇer nejlepˇs´ı varianty na interaktivn´ım zásahu 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ériem je pr˚ umˇern´ y ˇcas stráven´ y klientem v bance (resp. v jej´ı prvn´ı ˇcásti, tj. ve frontˇe a u pˇrep´ aˇzky prvn´ıho typu). Pro moˇznost pˇr´ımého porovnán´ı uvedeme dvˇe implementace modelu téhoˇz systému, realizované v r˚ uzn´ ych simulaˇcn´ıch jazyc´ıch. Jedn´ım z nich je klasick´ y jazyk pro simulaˇcn´ı modelován´ı (SIMULA), druh´ y je experimentáln´ı vizuáln´ı jazyk pro paraleln´ı objektovˇe orientované modelován´ı, zaloˇzen´ y na Petriho s´ıt´ıch (PNtalk). Nejprve uvedeme kód 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éto tˇr´ıdy (nebo jej´ı podtˇr´ıdy) tedy definuje samostatn´ y svˇet s vlastn´ım ˇcasem. Metoda Hold() zp˚ usob´ı ˇcekán´ı v simulaˇcn´ım ˇcase pˇr´ısluˇsné 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é tˇr´ıdou Simulation. Pˇr´ısluˇsn´ y anonymn´ı objekt (instance nepojenované tˇr´ıdy, odpov´ıdaj´ıc´ı bloku), se vytvoˇr´ı (inicializuje) v okamˇziku, kdy m´ a doj´ıt k zahájen´ı vyhodnocován´ı bloku. Vnoˇrován´ı simulac´ı v jazyce SIMULA je tedy moˇzné 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áˇr uˇcinil dokonalou pˇredstavu, následuje kompletn´ı kód 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é 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é simulace explicitnˇe pˇr´ısluˇsnou instanci tˇr´ıdy Simulation (nebo jej´ıho ekvivalentu, pokud je v daném prostˇred´ı k dispozici) vytvoˇrit. Princip ovˇsem z˚ ust´ av´ a zachov´ an.

74

´ KAPITOLA 8. SIMULACE SIMULUJÍCÍHO 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Í 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


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Í 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éhoˇz systému, 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án´ı v´ yraznˇe odliˇsn´ y od bˇeˇzného textového, avˇsak princip, pouˇzit´ yv pˇredchoz´ı ˇcásti, z˚ ustává zachován. Odliˇsnosti oproti modelu v jazyce SIMULA jsou dané pouˇzit´ ym jazykem a t´ım, ˇze model pro vnoˇrenou simulaci je smysluplné pouˇz´ıt jako nadtˇr´ıdu vnˇejˇs´ıho modelu. Model je specifikován 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ého systému se dvˇena frontami a dvˇema typy u ´ˇredn´ık˚ u. Model BankModel je zjednoduˇsen´ım modelu Bank, proto je v´ yhodné 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ém hromadné obsluhy. Klienti jsou generováni stochasticky ˇcasovan´ ym pˇrechodem generator. Banka m´ a kapacitu 100 klient˚ u. Zákazn´ıci jsou paralelnˇe obsluhováni u ´ˇredn´ıky, kteˇr´ı jsou modelováni znaˇckami v m´ıstˇe clerks (pˇrechod service m˚ uˇze b´ yt provádˇen násobnˇ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é ˇcásti pracovn´ıho dne. Ten je do pˇr´ısluˇsného m´ısta um´ıstˇen metodou makeExperimentForPeriod:clerks: (viz obr. 8.4). Tato metoda inicializuje model na základˇe parametr˚ u (period a clerks). Pak nechá bˇeˇzet simulaci po dobu 600 ˇcasov´ ych jednotek, coˇz je doba trv´ an´ı experimentu v ˇcase modelu (self hold: 600 ). Poté z m´ısta stat vyzvedne, zpracuje a odevzdá (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án, 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é instance tˇr´ıdy BankModel. S takto vytvoˇren´ ym modelem, kter´ y bude dále 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ámci systému Smalltalk (s knihovnou PNtalk). V´ ysledkem vyhodnocen´ı tohoto v´ yrazu je pr˚ umˇern´ y ˇcas stráven´ y klientem v bance (pro zadané parametry).


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ázek 8.3: Tˇr´ıda BankModel


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ázek 8.4: Metoda tˇr´ıdy BankModel, urˇcen´ a k proveden´ı simulaˇcn´ıho experimentu.


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ázek 8.5: Tˇr´ıda Bank – prvn´ı ˇcást s´ıtˇe objektu


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ázek 8.6: Tˇr´ıda Bank – druhá ˇcást s´ıtˇe objektu, na prvn´ı ˇcást 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áklad pro dalˇs´ı specializaci v rámci sofistikovanˇejˇs´ıho modelu banky. Nav´ıc ukáˇzeme, jak instance BankModel m˚ uˇze b´ yt simulována uvnitˇr jiné simulace. Sofistikovanˇejˇs´ı model banky se specifikován tˇr´ıdou Bank, dˇed´ıc´ı od tˇr´ıdy BankModel. Tˇr´ıda Bank pˇrdává druhou obsluˇznou linku (druhou sadu pˇrep´ aˇzek) a model ˇr´ızen´ı banky, kter´ y provád´ı rozhodován´ı o pˇriˇrazován˚ uu ´ˇredn´ık˚ u k jednotliv´ ym typ˚ um pˇrep´ aˇzek na základˇe v´ ysledk˚ u simulace modelu BankModel. S´ıt’ objektu, definovan´ a tˇr´ıdou Bank je zobrazena na dvou obr´ azc´ıch. Obrázek 8.5 zobrazuje pr˚ uchod klient˚ u bankou. Zdˇedˇené ˇcásti s´ıtˇe objektu, které z˚ ustávaj´ı beze zmˇeny, jsou zobrazeny ˇsedˇe. Obrázek 8.6 zobrazuje mechanismus rozhodován´ı a pˇremist’ován´ı u ´ˇredn´ık˚ u mezi pˇrep´ aˇzkami prvn´ıho a druhého typu na základˇe v´ ysledk˚ u simulace banky pro tˇri fáze dne (m´ısto period). Vnoˇren´ y model je simulován pˇrechodem inner pro aktuálná fázi. Tato ˇcinnost je provádˇena opakovanˇe (pro fázi 1, 2 a 3), pak simulace konˇc´ı – viz cyklus .


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ázek 8.7: Metoda tˇr´ıdy Bank, urˇcen´ a k proveden´ı vnoˇrené simulace Po kaˇzdé vnoˇrené simulaci probˇehne rozhodován´ı. 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áno metodou consultManager. Doporuˇcen´ a relokace u ´ˇredn´ık˚ u je specifikována 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ána se dvˇema parametry, prvn´ım je fáze dne (period p), druh´ ym je poˇcet dostupn´ ych u ´ˇredn´ık˚ u (clerks c). Obrázek 8.7 ukazuje metodu tˇr´ıdy Bank, která provád´ı vnoˇrené simulace simulaci a sb´ır´ a data. Vnoˇren´ a simulace je provádˇena pro vˇsechny moˇzné poˇcty u ´ˇredn´ık˚ u, zaˇc´ın´ a se poˇctem c a v kaˇzdém 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é simulace, v druhém pˇr´ıpadˇe jde o reáln´ y ˇcas, ve kterém probˇehne dialog. Z hlediska ˇcasu hlavn´ıho modelu trvaj´ı obˇe operace nulovou dobu. Sku-


83

teˇcné trv´ an´ı vnoˇrené simulace v modelovém ˇcase hlavn´ıho modelu je realizováno zpoˇzdˇen´ım v cyklu, provádˇen´ıc´ım jednotlivé simulace (viz obr. 8.6, pˇrechod simulate). Vzhledem k tomu, ˇze OOPN/PNtalk je paraleln´ı jazyk, spuˇstˇen´ı vnoˇrené simulace i dialog s uˇzivatelem jsou realizovány jako procesy, které 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álost ukonˇcen´ı naplánovat. 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é simulace nebo dialogu s uˇzivatelem. Pro tyto u ´ˇcely existuj´ı operace suspendTime a activateTime. Je li ˇcas pozastaven, pl´ anovaˇc dovol´ı provádˇet pouze události pl´ anované na aktuáln´ı ˇcas modelu. Po opˇetovné aktivaci se mohou uplatnit i dalˇs´ı pl´ anované události a ˇcas modelu se m˚ uˇze posunout, nen´ı-li na aktuáln´ı ˇcas jiˇz nic naplánováno. Tyto operace jsou pouˇzity v metodách 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ázek 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ém 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án 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áze, pˇriˇcemˇz v kaˇzdé z nich jsou provedeny vnoˇrené simulace pro r˚ uzné 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áze busy, idle a very busy a pro poˇcty u ´ˇredn´ık˚ u od 1 do 10. Tuˇcnˇe jsou vyznaˇceny vybrané varianty. Celkové v´ ysledky jsou v tabulce 8.2.


84

Obrázek 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é formˇe naznaˇcil probematiku simulace simuluj´ıc´ıch systém˚ u. V reáln´ ych situac´ıch je tˇreba oproti uvedenému pˇr´ıkladu ˇreˇsit komplikovanˇejˇs´ı parametrizaci, pˇr´ıpadnˇe vytvoˇren´ı nového modelu pro (vnoˇrenou) simulaci na základˇe aktuálnˇ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ákladˇ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éto kapitole bude pˇredstaveno prostˇred´ı pro tvorbu multiagentn´ıch systém˚ u na bázi objektovˇe orientovan´ ych Petriho s´ıt´ı. Jde o demonstraci moˇznosti programovat agenty form´ aln´ımi modely s moˇznost´ı jejich dynamické adaptace za ˇzivota systému. Tento pˇr´ıstup je podrobnˇeji pops´ an v publikac´ıch [?] a v disertaˇcn´ı práci [Maz08].

9.1

Multiagentn´ı syst´ emy

Multiagentn´ım systém je systém, ve kterém vz´ ajemnˇe interaguj´ı agenti. Agenti [Woo02] jsou autonomn´ı entity, schopné dlouhodobˇe plnit c´ıle zadané uˇzivatelem bez jeho dohledu v daném prostˇred´ı. Interakce agent˚ u pˇredstavuje komplexn´ı soci´ aln´ı aktivity, jako kooperace, soupeˇren´ı, vyjedn´ aván´ı, apod. Jako pˇr´ıklady aplikac´ı multiagent´ıch systém˚ u lze uvést komplexn´ı softwarové systémy, kde jednotlivé komponenty jsou natolik nez´ avislé a sloˇzité, ˇze z hlediska návrhu je efektivn´ı povaˇzovat je za zcela samostatné jednotky, které spolu komunikuj´ı ve velmi malé m´ıˇre pomoc´ı vysoko´ urovˇ nového jazyka, napˇr´ıklad jen v pˇr´ıpadˇe nestandardn´ıch situac´ı [SBD+ 00]. Dalˇs´ımi oblastmi jsou t´ ymová spolupráce 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é a adaptivn´ı softwarové systémy, zahrnuj´ıc´ı zak´ azkovou v´ yrobu [Kou01], ˇr´ıd´ıc´ı systémy letiˇstˇe [GR96]), distribuované aplikace pro z´ısk´ avav´ı znalost´ı [KHS97], senzorové s´ıtˇe [LTO03], sémantick´ y web a vyhled´ aván´ı informac´ı [E. 03], simulace socioekonomick´ ych proces˚ u [Mos01] apod. Velká pozornost je vˇenována nasazován´ı 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ále pokraˇcuje v´ yzkum vhodn´ ych vnitˇrn´ıch model˚ u agenta – a to jak v teoretické, tak v praktické (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ém˚ u: • Bˇehem návrhu a v´ yvoje inteligentn´ıho systému je tˇreba se systémem nebo jeho prototypem pr˚ ubˇeˇznˇe experimentovat a dovyv´ıjet ho za bˇehu. Struktura modelu (napˇr.

ˇ Í PRO VYVOJ ´ ´ U ˚ KAPITOLA 9. PROSTRED MULTIAGENTNÍCH SYSTEM

86

fragmenty pl´ an˚ u deliberativn´ıho agenta) jsou interaktivnˇe a inkrementálnˇe vyv´ıjeny bˇehem existence systému. • Systém se vyv´ıj´ı vlastn´ımi prostˇredky s´ am. Na základˇe mˇen´ıc´ıch se vnˇejˇs´ıch podm´ınek provád´ı pr˚ ubˇeˇznˇe optimalizaci vlastn´ı struktury s ohledem na aktuáln´ı c´ıle. • V pˇr´ıpadˇe multiagentn´ıch systém˚ u je tˇreba poˇc´ıtat s dynamick´ ym vytváˇren´ım, migrac´ı a ruˇsen´ım agent˚ u. Iniciátorem manipulace m˚ uˇze b´ yt jak agent, tak uˇzivatel nebo v´ yvojáˇr. Agentn´ı platforma (operaˇcn´ı systém) mus´ı takovouto manipulaci s agenty umoˇznit. V následuj´ıc´ım textu bude struˇcnˇe naznaˇcena realizace agentn´ıho systému 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ájmu 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ámˇery (intentions). Zámˇery jsou vytváˇreny v podobˇe pl´ an˚ u, které doˇcasnˇe ˇr´ıd´ı ˇcinnost agenta a jsou dynamicky vytváˇreny v souladu s aktuáln´ımi c´ıli na základˇe nˇekter´ ych vstupn´ıch událost´ı. Koncept multiagent´ıho syst´ emu v prostˇ red´ı PNtalk/SmallDEVS Vzhledem k tomu, ˇze agentn´ı systémy jsou ve své podstatˇe systémy paraleln´ı a distribuované, jev´ı se smyslupln´ ym pouˇz´ıt pro jejich specifikaci Petriho s´ıtˇe. Aplikac´ı Petriho s´ıt´ı v návrhu agentn´ıch systém˚ 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án´ım, ale bez dynamické instanciace. V rámci námi zvolené 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áln´ı 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é specifikovat i agentn´ı platformu (agentn´ı operaˇcn´ı systém), vytváˇrej´ıc´ı potˇrebnou abstrakci okoln´ı reality a poskytuj´ıc´ı prostˇred´ı pro existenci agent˚ u. Takto navrˇzen´ y agentn´ı systém vyuˇz´ıv´ a infrastrukturu, poskytovanou prostˇred´ım SmallDEVS [JK06]. Jde zejména 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é mobiln´ı robotiky. Vazba na reálné okol´ı agent˚ u je v tomto pˇr´ıpadˇe implementována jednotn´ ym rozhran´ım, zpˇr´ıstupˇ nuj´ıc´ım jak reálné, tak simulované robotické platformy. Pro simulaci robot˚ u v simulovaném prostˇred´ı je pouˇzit extern´ı robotick´ y simul´ ator. Agentn´ı architektura Architektura systému vycház´ı z existuj´ıc´ıch architektur BDI agent˚ u, jako je PRS [GL87] a jeho následn´ıci dMars [dLG+ 04], 3APL [DdBDM03], Jadex [PBL03], AgentSpeak [Rao96] and [BWH07]. Nejv´ıce je inspirována systémy dMars [dLG+ 04] a Jason [BWH07]. Origináln´ım pˇr´ınosem je (1) form´ aln´ı specifikace celého agentn´ıho systému (jeho obecn´ ych i aplikaˇcnˇe-specifick´ ych souˇcást´ı) objektovˇe orientovan´ ymi

´ 9.2. APLIKACE V OOPN A DEVS V MULTIAGENTNÍCH 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é agentn´ı architektury. Na obr. 9.1 jsou zn´ azornˇeny nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy, kter´ ymi je implementováno prostˇred´ı PNagent. Z diagramu tˇr´ıd je patrné, ˇze multiagentn´ı systém systém (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é zmˇeny stavu systému jsou d˚ usledkem událost´ı (Event). Ud´ alosti pro agenta generuje platforma. Kaˇzd´ y pl´ an m´ a pˇriˇrazeny vzory spouˇstˇec´ıch událost´ı, pˇr´ıpadnˇe vzory událost´ı, které pl´ an suspenduj´ı, obnov´ı prov´ adˇen´ı, zp˚ usob´ı selh´ an´ı, nebo u ´spˇeˇsné dokonˇcen´ı. Zvláˇstn´ım typem události je c´ıl (Goal). C´ıle jsou, na rozd´ıl od bˇeˇzn´ ych událost´ı, perzistentn´ı (z˚ ustavaj´ı v platnosti, dokud nejsou splnˇeny, nebo dokud se nestanou neaktu´ aln´ımi). Instance pl´ an˚ u (PlanInstance) jsou souˇcást´ı zámˇer˚ u (Intention). Na základˇe události nebo vzniku c´ıle se instanciuje odpov´ıdaj´ıc´ı pl´ an a vytvoˇr´ı se zámˇer. Zámˇer také obsahuje pˇr´ıpadné instance podpl´ an˚ u. Obrázek 9.2 obsahuje schematické zn´ azornˇen´ı jádra agenta, které interpretuje události. V rámci v´ yˇse uvedeného prostˇred´ı mus´ı aplikaˇcn´ı programátor specifikovat (1) bázi pˇredstav (model svˇeta, beliefs), (2) metody tˇr´ıdy agenta, reprezentuj´ıc´ı agentovy schopnosti, (3) extern´ı události, reprezentuj´ıc´ı zmˇeny v prostˇred´ı, (4) aplikaˇcnˇe specifické pl´ any.

Obrázek 9.1: Zjednoduˇsen´ y diagram tˇr´ıd systému 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án´ı lze demonstrovat na typickém ukázkovém pˇr´ıkladu pro multiagentn´ı systémy, nazvaném Cleaner World. Jde 2D prostˇred´ı maticového typu, obsahuj´ıc´ı odpad, agenty a popelnice. Pozice odpadu, popelnic a agent˚ u, stejnˇe jako aktuáln´ı 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


Obrázek 9.2: Schematické zn´ azornˇen´ı struktury interpretu systému PNagent.

agentPosition(4,5). carryingWaste.

Obrázek 9.3 ukazuje, jak lze tent´ yˇz model vyjádˇrit prostˇredky OOPN. Fakta jsou modelována znaˇckami v m´ıstech. Synchronn´ı port canDropWaste a negativn´ı predik´ at notCarryingWaste slouˇz´ı k testován´ı stavu svˇeta, resp. ke zjiˇstˇen´ı, zda stav svˇeta dovoluje provést nˇejakou operaci.

Obrázek 9.3: Agentn´ı prostˇred´ı Cleaner World a jeho reprezentace v jazyce PNtalk.

Z´ amˇ ery, pl´ any Zámˇ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áˇren´ım pl´ an˚ u od poˇcátˇcn´ıch princip˚ u, jako napˇr. STRIPS, ale aktivuje pˇredem pˇripravené d´ılˇc´ı pl´ any podle aktuáln´ı situace. Pl´ any ale mohou b´ yt specifikovány jen ˇcásteˇcnˇe a k jejich dospecifikován´ı m˚ uˇze doj´ıt aˇz za bˇehu, pˇri instaniaci. Pl´ an je specifikován Petriho s´ıt´ı, která vˇzdy obsahuje m´ısta start, success a failure. Dalˇs´ı m´ısta a pˇrechody specifikuj´ı kauzalitu jednotliv´ ych operac´ı a stav provádˇen´ı pl´ anu. Na obr´ azku 9.4 je pˇr´ıklad instance pl´ anu. Provádˇen´ı pˇrechod˚ u, specifikuj´ıc´ıch jednotlivé kroky provádˇen´ı pl´ anu, je omezeno stráˇ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ádˇ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é se uplatn´ı pˇri ˇreˇsen´ı konflikt˚ u.


89

Obrázek 9.4: Pˇr´ıklad pl´ anu specifikovaného Petriho s´ıt´ı v prostˇred´ı PNagent.

Interpret Interpret je implementován tˇr´ıdou BDIAgent. Jádro interpretu je na obr´ azku 9.5. Tradiˇcn´ı cyklus interpretu BDI agenta – z´ıskej nové události, vytvoˇr odpov´ıdaj´ıc´ı pl´ any, uprav strukturu zámˇer˚ u, vyber jeden zámˇer a proved’ jeden krok jeho aktuáln´ıho ˇ ast zobrazená na obr´ pl´ anu – je zde rozdˇelen do dvou nez´ avisl´ ych ˇcást´ı. C´ azku 9.5 vpravo je zodpovˇedn´ a za zpracován´ı událost´ı – události jsou postupnˇe odeb´ır´ any z fronty událost´ı, maj´ı moˇznost upravit agentovu bázi znalost´ı a poté jsou paralelnˇe pˇred´ any metodám, jeˇz maj´ı za u ´kol vytváˇren´ı nov´ ych instanc´ı pl´ an˚ u, resp. spr´ avu stavu existuj´ıc´ıch instanc´ı (tedy uspáván´ı, probouzen´ı atd.). Druhá ˇcást, zachycen´ a na obr´ azku vlevo, se star´ a o interpretaci struktury zámˇer˚ u. Interpret vykon´ avá jeden zámˇer krok po kroku tak dlouho, dokud je tento zámˇer provediteln´ y. Poté vybere náhodnˇe jin´ y provediteln´ y z´ amˇer. Interpretace zámˇer˚ u pˇredstavuje vlastn´ı funkˇcnost agenta – zde se v jednotliv´ ych kroc´ıch realizuj´ı agentovy pl´ any, tedy provádˇej´ı akce, které ovlivˇ nuj´ı prostˇred´ı. Agentn´ı platforma Tˇr´ıda Platform definuje prostˇred´ı, v kterém agenti existuj´ı. Poskytuje agent˚ um tˇri základn´ı sluˇzby: (1) Správu ˇzivotn´ıho cyklu – zejména prostˇredky pro


90

Obrázek 9.5: Zpracován´ı událost´ı a interpretace zámˇer˚ u agenta.

vytváˇren´ı a odstraˇ nován´ı agent˚ u, pˇridˇelován´ı jednoznaˇcn´ ych identifikátor˚ u (AID) apod., (2) sluˇzbu b´ıl´ ych stránek (vyhledáván´ı 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álné okol´ı, obstar´ avá prostˇred´ı SmallDEVS. Aplikace prostˇ red´ı PNagent v oblasti robotiky V´ yˇse popsané multiagentn´ı prostˇred´ı bylo experimentálnˇe ovˇeˇreno v oblasti malé mobiln´ı robotiky. Agent je pouˇzit pro ˇr´ızen´ı robota. To znamená, ˇze m´ a za u ´kol zpracovávat 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é prostˇrednictv´ım speciáln´ıho rozhran´ı na extern´ı realitu, které je v prostˇred´ı SmallDEVS realizováno 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é rozhran´ı na senzory a aktuátory fyzick´ ych i simulovan´ ych robot˚ u. Z hlediska aplikace jde o server, zpˇr´ıstupˇ nuj´ıc´ı senzory a aktuátory v abstrahované formˇe klientsk´ ym program˚ um, pˇriˇcemˇz klientské programy implementuj´ı ˇr´ızen´ı robot˚ u. Player obsahuje ovladaˇce jak pro simulované, tak pro reálné senzory a aktuátory robot˚ u. K simulaci chován´ı 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ákladn´ıch 1

http://playerstage.sourceforge.net/


91

Obrázek 9.6: Simul´ ator Stage

Obrázek 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álnˇe kolem robota, osmi nárazn´ıky, kompasem a r´ adiem, umoˇzn ˇuj´ıc´ım zas´ıl´ an´ı zpr´ av ostatn´ım robot˚ um. Pˇr´ıkazy, které 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ádia. V takto vytvoˇreném prostˇred´ı lze experimantovat s r˚ uzn´ ymi multirobotick´ ymi u ´lohami. Ovˇeˇren´ı praktické pouˇzitelnosti bylo provedeno na u ´loze formován´ı t´ ymu robot˚ u, jak byla definována napˇr. v [HZ04]. V´ıce podrobnost´ı lze naj´ıt v [Maz08]. Od simulace k realitˇ e Pro realizaci uvedené multirobotické u ´lohy byl pouˇzit extern´ı software, sestávaj´ıc´ı ze serveru Player a simul´ atoru Stage. Pˇrechod od simulovan´ ych robot˚ u v simulovaném prostˇred´ı k reáln´ ym robot˚ um v re´ alném prostˇred´ı m˚ uˇze b´ yt proveden nˇekolika zp˚ usoby, pˇr´ıpadnˇe v nˇekolika fáz´ı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ém palubn´ım poˇc´ıtaˇci kaˇzdého 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ém bˇeˇz´ı ˇr´ızen´ı jednoho


92

robota), Player bˇeˇz´ı na palubn´ım poˇc´ıtaˇci kaˇzdého 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ého 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é 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ázek 9.8: Konfigurace systému 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é volnˇe vázané komponenty, události, snadnou manipulaci (plug’n’play), pˇr´ımou vazbu na teorii modelován´ı a simulace, operaˇcn´ı systém. Formalismus OOPN, resp. jazyk PNtalk, pˇrin´ aˇs´ı paralelismus, synchronizaci, objekty, vizuáln´ı jazyk, pˇrirozenou reprezentaci pl´ an˚ u. Jak aplikaˇcnˇe specifická ˇcást agenta, tj. reprezentace svˇeta, d´ılˇc´ı pl´ any atd., tak i obecná architektura agenta jsou pops´ any pomoc´ı OOPN v jazyce PNtalk a interpretovány v rámci 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áln´ı v´ yvoj jak agentn´ı aplikace, tak i obecné agentn´ı architektury, a to za pouˇzit´ı stejn´ ych prostˇredk˚ u. Moˇznost snadné adaptace agentn´ı architektury podle aktuáln´ıch poˇzadavk˚ u dané aplikace m˚ uˇze urychlit a zkvalitnit v´ yvoj agentn´ıho systému. Kromˇe toho potenciálnˇ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éto kapitole bude pˇredstaven koncept vyuˇzit´ı dynamick´ ych OOPN v ˇr´ızen´ı projekt˚ u, konkrétnˇe v modelován´ı projektového portfolia pro potˇreby rozvrhován´ı a monitorován´ı.

10.1

Z´ akladn´ı pojmy z oblasti ˇ r´ızen´ı projekt˚ u

Projekt Projekt [Anb05] je ˇcasovˇe ohraniˇcené u ´sil´ı smˇeˇruj´ıc´ı k vytvoˇren´ı unikátn´ıho produktu nebo sluˇzby. ˇ ızen´ı projekt˚ ˇ ızen´ı projekt˚ R´ u R´ u [Sch05] je proces pl´ anován´ı, koordinován´ı a ˇr´ızen´ı u ´loh a zdroj˚ u pro dosaˇzen´ı definovaného c´ıle v daném ˇcase, s definovan´ ymi zdroji a s omezenou cenou. Problematika ˇr´ızen´ı projektu zahrnuje (1) pl´ anován´ı 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áln´ıch i pl´ anovan´ ych projekt˚ u, aby se dos´ ahlo konkrétn´ıch c´ıl˚ u. Smyslem ˇr´ızen´ı projektového portfolia je optimalizace ˇcasu, náklad˚ u a zdroj˚ u, pˇresahuj´ıc´ı rámec jednotliv´ ych projekt˚ u [GK03, Lee04]. Mnoˇzina aktuáln´ı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ávanému v´ ysledku. K provádˇen´ı aktivit jsou vyuˇz´ıv´ any zdroje, aktivity transfromuj´ı vstupy na v´ ystupy. Aktivity a zdroje v rámci projektu jsou obvykle cháp´ any jako procesy [Anb05]. S´ıt’ov´ y diagram projektu S´ıt’ov´ y diagram je grafová reprezentace uspoˇrád´ an´ı jednotliv´ ych aktivit, které 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é anaˇ lyzovat ˇcasové charakteristiky projektu (doba trv´ an´ı, kritická cesta). Casto pouˇz´ıvanou alternativou s´ıt’ového siagramu je ˇcasovan´ a Petriho s´ıt’.

94

´ MODELY V R ˇ ÍZENÍ PROJEKTU ˚ KAPITOLA 10. DYNAMICKE

Pl´ anov´ an´ı Pl´ anován´ı je proces v´ ybˇeru a uspoˇrád´ an´ı aktivit, vedouc´ıch k dosaˇzen´ı c´ıle [Spi92]. Rozvrhov´ an´ı Rozvrhován´ı [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á kritéria, napˇr´ıklad minimalizace celkové ceny dan´ ych zdroj˚ u. V´ ystupem procesu rozvrhován´ı 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é (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é situace vz´ acné. V pˇr´ıpadˇe projektového 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ému) se objevuj´ı nové c´ıle a tedy vznikaj´ı nové projekty, jiné 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é s ˇcasem mˇen´ı. Dynamické (on-line) pl´ anov´ an´ı a rozvrhov´ an´ı [Koc02] pˇredstavuje proces tvorby rozvrhu za bˇehu systému. Rozvrh je tedy tvoˇren inkrementálnˇe pˇri zmˇenˇe aktuálnˇe dostupn´ ych informac´ı. D˚ uleˇzit´ ym poˇzadavkem je dostateˇcn´ a rychlost on-line pl´ anován´ı a rozvrhován´ı. Monitorov´ an´ı Monitorován´ı projektu je sledován´ı v´ yznam´ ych událost´ı v pr˚ ubˇehu ˇreˇsen´ı projektu a porovnáván´ı se simulac´ı projektu. Typicky jde o sledován´ı zaˇcátk˚ u a konc˚ u jednotliv´ ych aktivit, pˇr´ıpadnˇe o události, jako jsou neplánované zmˇeny ve struktuˇre a parametrech zdroj˚ u. V pˇr´ıpadˇe jakékoli odchylky reality od simulace je tˇreba upravit model a okamˇzitˇe provést dynamické pl´ anován´ı a rozvrhován´ı, aby model (vˇcetnˇe rozvrhu zdroj˚ u) odpov´ıdal realitˇe a aby byly splnˇeny vˇsechny aktuáln´ı poˇzadavky na systém.

10.2

Aplikace dynamick´ ych OOPN v modelov´ an´ı projektov´ eho portfolia pro potˇ reby rozvrhov´ an´ı a monitorov´ an´ı

V této studii ukáˇzeme, ˇze pro adekvátn´ı modelován´ı projektového portfolia na bázi Petriho s´ıt´ı je tˇreba pouˇz´ıt (at’ uˇz pˇr´ımo, nebo jen na konceptuáln´ı u ´rovni) dynamickou variantu Objektovˇe orientovan´ ych Petriho s´ıt´ı (OOPN), aby bylo moˇzné provádˇet jak klonován´ı a editaci pro potˇreby optimalizace a rozvrhován´ı, tak dynamickou modifikaci v pr˚ ubˇehu monitorován´ı 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án´ı nov´ ych pl´ an˚ u, zmˇeny pl´ an˚ u apod). Pro potˇreby ˇr´ızen´ı projektového portfolia se pouˇz´ıv´ a ˇrada pˇr´ıstup˚ u, metod a modelovac´ıch formalism˚ u, mnohé z nich vyuˇz´ıvaj´ı modely na bázi Petriho s´ıt´ı [GK03, AG04, HY03]. Vesmˇes jde o Petriho s´ıtˇe sice vysoko´ urovˇ nové, ale nestrukturované. Vyuˇzit´ı moˇznosti strukturován´ı, at’ uˇz statického, jako v pˇr´ıpadˇe hierarchick´ ych Petriho s´ıt´ı, tak dynamického, jako v pˇr´ıpadˇe objektovˇe orientovan´ ych Petriho s´ıt´ı, se jev´ı jako moˇzné a pˇr´ınosné. Oˇcekávanou v´ yhodou objektovˇe orientovan´ ych Petriho s´ıt´ı je adekvátn´ı strukturován´ı modelu projektového portfolia. Existuje ˇrada potenciálnˇ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éto studii se ale zamˇeˇr´ıme na Objektovˇe orientované

´ Í PROJEKTOVEHO ´ 10.2. MODELOVAN PORTFOLIA

95

Petriho s´ıtˇe (OOPN) [Jan95, Jan98], vycházej´ıc´ı d˚ uslednˇe z klasického objektového 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á je také pro zam´ yˇslenou aplikaci nepostradateln´ a. Koncept modelov´ an´ı projektov´ eho protfolia Projektové portfolio lze modelovat pomoc´ı OOPN takto: • Projektové portfolio je modelováno jedn´ım objektem OOPN. Zdroje jsou modelovány objekty, dostupn´ ymi jako znaˇcky v m´ıstech – znaˇcky nesou reference na objekty zdroj˚ u. Tyto odkazy na zdroje jsou distribuovány do m´ıst s´ıtˇe objektu podle jejich rol´ı. • S´ıtˇe metod modeluj´ı jednotlivé vzory pl´ an˚ u projekt˚ u. Jejich instance jsou dynamicky vytváˇ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án 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á 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ého portfolia. Obsahuje tˇri r˚ uzné typy projekt˚ u, resp. tˇri typy pl´ an˚ u, modelované metodami OOPN. Tyto pl´ any sd´ıl´ı tˇri typy (resp. role) zdroj˚ u. Typy zdroj˚ u (jejich role) jsou modelovány 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ázán 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án´ı jednotliv´ ych konkrétn´ıch projekt˚ u. Poznamenejme, ˇze jsou pˇr´ıpustné násobné invokace metod OOPN, které 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ádˇen´ı pokraˇcuje um´ıstˇen´ım znaˇcek do v´ ystupn´ıch m´ıst. Zdroje a jejich role Obrázek 10.1 neukazuje vˇsechny detaily – nejsou v nˇem prozat´ım uvaˇzovány jednotlivé zdroje. Pˇredpokl´ ad´ a se, ˇze zdroje jsou modelovány 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ém modelu potenciálnˇe v´ıce neˇz jednu roli. Obrázek 10.3 ukazuje situaci, kde je jeden zdroj (objekt tˇr´ıdy Resource), maj´ıc´ı dvˇe r˚ uzné role, sd´ılen dvˇema projekty. Kaˇzd´ a aktivita poˇzaduje zdroj urˇcitého 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ákladˇe pˇredchoz´ıch zkuˇsenost´ı s podobn´ ymi


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ázek 10.1: Model projektového portfolia Resource is_a PN allocFor: a duration: d

.

d

.

allocated use

.

idle

d

.

self hold: d

return

Obrázek 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ázek 10.3: Konflikt dvou aktivit poˇzaduj´ıc´ıch jeden zdroj se dvˇemi rolemi


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á se na jeho uvolnˇen´ı. To je specifikováno stráˇz´ı kaˇzdého pˇrechodu, modeluj´ıc´ıho aktivitu. Podaˇr´ı-li se zdroj alokovat, je následnˇe pouˇzit. Pouˇzit´ı zdroje je modelováno ˇcasovan´ ym pˇrechodem (viz metoda use v tˇr´ıdˇe Resource – zpoˇzdˇen´ı je realizováno 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ázek 10.4: Zdroj s rozvrhem. Rozvrhy zdroj˚ u Obrázek 10.4 ukazuje zdroj s rozvrhem. Stráˇ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án´ım synchronn´ıho portu). Rozvrh pro kaˇzd´ y zdroj je vytvoˇren vhodn´ ym optimalizaˇcn´ım procesem mimo model a poté um´ıstˇen do m´ısta schedule. Model s doplnˇen´ ymi rozvrhy pro jednotlivé zdroje je pak pouˇziteln´ y pro anal´ yzu, ovˇeˇren´ı spr´ avnosti modelu a pro monitorovnán´ı. Schopnosti zdroj˚ u Pro kaˇzd´ y zdroj lze specifikovat jeho schopnost vykon´ avat urˇcité 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án´ı 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ákladˇe informac´ı z m´ısta skills, které obsahuje dvojice (aktivita, schopnost), provede ˇcekán´ı po dobu (1/s)d. Obrázek 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ázek 10.6 ukazuje model aktivity, poˇzaduj´ıc´ı tˇri zdroje se dvˇemi rolemi. Synchronn´ı pouˇzit´ı zdroj˚ u (srovnán´ı zaˇcátk˚ u a dob trv´ an´ı pouˇzit´ı zdroj˚ u) je modelováno 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é pouˇz´ıt v´ıce zdroj˚ u, lze zohlednit vhodnost dané kombinace zdroj˚ u pro t´ ymovou práci. To lze specifikovat matic´ı, která kaˇzdé dvojici 1

Napˇr´ıklad metodami z´ısk´ av´ an´ı znalost´ı z datab´ az´ı (datamining). Existuj´ı varianty této 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é 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


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ázek 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ázek 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é doby trv´ an´ı aktivit a schopnosti vykon´ avat konkrétn´ı aktivity, schopnost t´ ymové spolupráce zdroj˚ u lze z´ıskat anal´ yzou dat z pˇredchoz´ıch projekt˚ u. Tato schopnost se opˇet projev´ı v délce skuteˇcného trv´ an´ı aktivity. Konkrétn´ı implementace je v metodách typu useWith: r ve tˇr´ıdˇe ScheduledResource. Koncept pouˇ zit´ı modelu pro rozvrhov´ an´ı a monitorov´ an´ı Praktické pouˇzit´ı OOPN v modelován´ı projektového portfolia pro potˇreby rozvrhován´ı a monitorován´ı m˚ uˇzeme nyn´ı podrobnˇeji specifikovat takto: • Simulace se pouˇz´ıv´ a pro ovˇeˇren´ı spr´ avnosti návrhu projektu. Zde se uplatn´ı hlavnˇe interaktivn´ı simulace. Model je téˇz pouˇziteln´ y pro anal´ yzu, vedouc´ı napˇr. ke zjiˇstˇen´ı kritické 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ého portfolia). • Opakovan´ a automatická simulace je pouˇzita také jako souˇcást fitness funkce pˇri optimalizaci zp˚ usobu pˇridˇelován´ı zdroj˚ u aktivit´ am. V´ ysledkem tohto optimalizaˇcn´ıho procesu je rozvrh, kter´ y vz´ ajemnˇe mapuje zdroje, ˇcasové intervaly a aktivity.


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álnˇ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án´ı projektu. Pro monitoring pˇredpokl´ ad´ ame simulaci synchronizovanou reáln´ ym ˇcasem a událostmi z reálného prostˇred´ı. Mapován´ı reálnéhého ˇ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é tyto zdroje modeluj´ı, a provede se nové rozvrhován´ı. Po vytvoˇren´ı nového rozvrhu se aktualizuj´ı objekty zdroj˚ u (protoˇze obsahuj´ı vlastn´ı rozvrh pro jednotlivé ˇcinnosti). • Pro potˇreby rozvrhován´ı se vytvoˇr´ı klon okamˇzitého stavu (jde o stav modelu v pr˚ ubˇehu monitorován´ı) a ten je pouˇzit jako poˇcáteˇcn´ı stav pro zkoumán´ı vˇsech moˇzn´ ych budoucnost´ı portfolia s r˚ uzn´ ymi zp˚ usoby pˇridˇelován´ı zdroj˚ u v rámci zvolené optimalizaˇcn´ı strategie a zvolen´ ych kriteri´ı. • Vytvoˇren´ı nového typu projektu (nového pl´ anu) znamená pˇrid´ an´ı nové 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ána v pr˚ ubˇehu ˇreˇsen´ı, stejnˇe tak i jednotlivé jej´ı instance. Zachov´ an´ı modelu D´ıky pˇredpokl´ adané moˇznosti zasahovat do bˇeˇz´ıc´ı simulace v pr˚ ubˇehu monitorován´ı a d´ıky moˇznosti stav simulace klonovat a dále pouˇz´ıt pro potˇreby anal´ yzy a optimalizace je snadno realizovateln´ y fenomén zachován´ı modelu (model continuity) v projektovém ˇr´ızen´ı. Základn´ı myˇslenkou je povaˇzovat model projektového portfolia specifikovan´ y formalismem OOPN za základn´ı a vˇsechny ostatn´ı pohledy na projektové portfolio automaticky generovat, pˇr´ıpadnˇe z jin´ ych pohled˚ u automaticky generovat a realizovat automatické editaˇcn´ı zásahy do modelu na bázi 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á zpˇr´ıstupnit metaobjektov´ y protokol (MOP) simul´ atoru. MOP (jinak téˇz reflektivn´ı rozhran´ı) simul´ atoru umoˇzn´ı zasahovat do struktury modelu za bˇehu. Takové rozˇs´ıˇren´ı OOPN bylo jiˇz navrˇzeno a experimentálnˇe implementováno v prostˇred´ı jazyka a systému PNtalk, coˇz je implementace OOPN ve Smalltalku [JK04]. OOPN/PNtalk MOP umoˇzn ˇuje vytváˇ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é ˇzivé objekty. Umoˇzn ˇuje také vytvoˇrit klon bˇeˇz´ıc´ıho systému a uloˇzit, resp. naˇc´ıst ho do/z datab´ aze. Alternativou k pˇr´ımému pouˇzit´ı simul´ atoru OOPN je moˇznost OOPN pouˇz´ıt jen na konceptuáln´ı u ´rovni s t´ım, ˇze samotná realizace m˚ uˇze b´ yt jin´ a. OOPN je moˇzné transformovat do jin´ ych formalism˚ u a prostˇred´ı. C´ılovou realizac´ı m˚ uˇze b´ yt napˇr. datab´ azová 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é aktivity v r´ amci jednotliv´ ych projekt˚ u kontroluj´ı kromˇe okamˇzité fyzické dostupnosti zdroje také 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é komplikovanˇejˇs´ı.


100

aplikace. Pro optimalizaci a rozvrhován´ı pak mohou b´ yt pouˇzity existuj´ıc´ı obecné nástroje, napˇr knihovny pro genetické algoritmy apod.

10.3

Shrnut´ı

Studii o modelován´ı projektového 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áln´ı vysoko´ urovˇ novou Petriho s´ıt’ pro celé projektové portfolio a tuto Petriho s´ıt’ postupnˇe v rámci monitorován´ı aktualizovat a po aktualizaci pouˇz´ıt jako v´ ychodisko pro rozvrhován´ı. • Modely na bázi OOPN nab´ızej´ı moˇznost pouˇz´ıt dynamicky instanciovatelné Petriho s´ıtˇe pro modelován´ı jednotliv´ ych pl´ an˚ u projekt˚ u. Pˇredem definované pl´ any lze dynamicky instanciovat, instance pl´ an˚ u mohou b´ yt parametrizovány. Jednotlivé pl´ any jsou ale staticky fixovány – odpov´ıdaj´ıc´ı Petriho s´ıtˇe jsou v pˇr´ıpadˇe klasické varianty OOPN pevnˇe dány v dobˇe startu systému. • Doporuˇcené ˇreˇsen´ı: Instanciovatelné Petriho s´ıtˇe s moˇznost´ı editovat jejich strukturu za bˇehu. Pl´ any projekt˚ u pak mohou b´ yt libovolnˇe modifikovány, zat´ımco strukturován´ı modelu do jednotliv´ ych pl´ an˚ u z˚ ustává 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é instance. V´ yhodou pˇr´ımého pouˇzit´ı OOPN pro modelován´ı projektového portfolia je adekvátn´ı strukturován´ı modelu, takˇze nevzniká jedna nestrukturovan´ a s´ıt’, kde jsou d´ılˇc´ı s´ıtˇe jednotliv´ ych projekt˚ u spojeny do jednoho celku, ale jednotlivé s´ıtˇe existuj´ı a jsou pod kontrolou samostatnˇe (napˇr. zánik, resp. ukonˇcen´ı projektu jsou modelovány adekvátn´ım zp˚ usobem). Pracuje se t´ım pádem na vyˇsˇs´ı u ´rovni neˇz v pˇr´ıpadˇe editace jedné nestrukturované s´ıtˇe – pojmy problémové domény jsou v modelu zachovány, vytvoˇren´ım modelu se neztrác´ı 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éto práci byly pops´ any vybrané aspekty problematiky modelován´ı a simulace vyv´ıjej´ıc´ıch se a nepˇretrˇzitˇe bˇeˇz´ıc´ıch systém˚ u, zahrnuj´ıc´ı jak teoretická v´ ychodiska, tak moˇznosti praktické realizace. Byly uvaˇzovány r˚ uzné aplikaˇcn´ı oblasti, zahrnuj´ıc´ı jak automatickou, tak interaktivn´ı evoluci systém˚ 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é 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é diagramy (statecharts) je moˇzné do DEVS relativnˇe snadno transformovat. S vyuˇzit´ım DEVS je moˇzné srozumitelnˇe a na form´ aln´ım základˇe popsat problematiku distribuované simulace, viz napˇr. [ZKP00]. DEVS také hraje v´ yznamnou u ´lohu v souˇcasn´ ych aktivit´ ach v oblasti v´ yvoje systém˚ u na bázi simulace (Simulation-Based Design and Development), kde koncept zachován´ı modelu (Model Continuity) v´ yznamnˇe pˇrisp´ıv´ a k efektivnosti a bezpeˇcnosti v´ yvoje [HZ04]. Hlavn´ı témata aktuáln´ı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án´ı a návaznost na metodiky softwarového inˇzen´ yrstv´ı, • interoperabilita nástroj˚ u a pˇrenositelnost model˚ u, • standardn´ı knihovny znovupouˇziteln´ ych model˚ u, • webové sluˇzby pro simulaci. Dynamické prostˇred´ı pro modelován´ı a simulaci model˚ u na bázi DEVS, o kterém byla v tomto textu ˇreˇc, je v souladu s obecn´ ym trendem ve stále vˇetˇs´ı m´ıˇre aplikovat dynamické programovac´ı jazyky v realizaci programov´ ych systém˚ u. V´ yhodou je rychlejˇs´ı v´ yvoj systém˚ u a moˇznost sledovat a modifikovat jejich dynamiku, coˇz vede k lepˇs´ımu vhledu do chován´ı systém˚ u a tedy ke kvalitnˇeji navˇzen´ ym systém˚ um. Jednoduch´ y a srozumiteln´ y form´ aln´ı základ model˚ u na bázi DEVS umoˇzn ˇuje kromˇe simulace a testován´ı pˇr´ımo aplikovat i matematické metody pro anal´ yzu systém˚ u, jejich struktury i chován´ı.

´ ER ˇ KAPITOLA 11. ZAV

102

Jin´ e formalismy DEVS modeluje systém jako stavov´ y stroj (i kdyˇz mnoˇzina stav˚ u m˚ uˇze b´ yt i nekoneˇcn´ a) s explicitnˇe vyjádˇren´ ym stavem a s explicitnˇe vyjádˇren´ ymi pˇrechody, modifikuj´ıc´ımi stav. To nemus´ı b´ yt na prvn´ı pohled pro praktické programován´ı pˇr´ıliˇs v´ yhodné. 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ázané komponenty, s kter´ ymi je moˇzné snadno dynamicky manipulovat právˇe d´ıky explicitnˇe vyjádˇrenému stavu a volné vazbˇe na ostatn´ı komponenty. Obvyklé pˇr´ıstupy k programován´ı je v´ yhodné pouˇz´ıt uvnitˇr komponent DEVS. Mapován´ı vybraného formalismu (jazyka) do komponenty DEVS znamená vyjádˇ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áln´ı reprezentovatace modelu. Zapouzdˇren´ım interpretu OOPN bylo dosaˇzeno spojen´ı v´ yhod paraleln´ıho objektovˇe orientovaného 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ázány referencemi a zachovat konzistenci modelu po editaˇcn´ıch zásaz´ıch nen´ı zcela jednoduché.1 CAST CAST je zkratka pro Computer-Aided Systems Theory [Pic89]. DEVS, jako modelovac´ı formalismus, kter´ y bezprostˇrednˇe z teorie systém˚ u vycház´ı, dokonale odpov´ıd´ a konceptu spojen´ı poˇc´ıtaˇcov´ ych nástroj˚ u a teorie systém˚ u. Kaˇzd´ a konkrétn´ı implementace abstraktn´ıho simul´ atoru DEVS je vlastnˇe pˇr´ımoˇcarou poˇc´ıtaˇcovou implementac´ı teorie systém˚ u (s diskrétn´ımi událostmi). Vezmeme-li v u ´vahu koncept zachován´ı modelu v c´ılové realizaci, jde v pˇr´ıpadˇe DEVS a jin´ ych kompatibiln´ıch formalism˚ u (DEVS-like systems) o pˇr´ıklad ideáln´ıho sepˇet´ı teorie a praxe tvorby poˇc´ıtaˇcov´ ych systém˚ u, kde konkrétn´ı, prakticky realizované systémy 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álném prostˇred´ı. Poˇ c´ıtaˇ cov´ e n´ astroje V tomto textu popisované obecné principy simulaˇcn´ıho modelován´ı vyv´ıjej´ıc´ıch se systém˚ u (kapitola 4) jsou ilustrovány konkrétn´ımi implementacemi abtraktn´ı simulaˇcn´ı architektury, navrˇzené právˇe pro tento typ systém˚ u. Implementaˇcn´ım prostˇred´ım je Smalltalk. V nˇem vytvoˇrené nástroje SmallDEVS a PNtalk (kapitoly 5 a 6) jsou pouˇzitelné jako pom˚ ucky pro studium problematiky modelován´ı 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ástroj˚ u. Propojen´ı experimentáln´ıch nástroj˚ u SmallDEVS a PNtalk se soudob´ ymi pr˚ umyslovˇe pouˇziteln´ ymi a pouˇz´ıvan´ ymi nástroji je potenciálnˇe moˇzné, protoˇze jako souˇcást 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án´ı a simulace v souˇcasné dobˇe pracuje [MRMZ07]. Ve speciáln´ıch pˇr´ıpadech, kdy nen´ı tˇreba interoperabilitu s jin´ ymi nástroji ˇreˇsit, lze tyto experimentáln´ı nástroje pouˇz´ıt pˇr´ımo. Situaci usnadˇ nuje fakt, ˇze jde o volnˇe ˇsiˇritelné nástroje, s jejichˇz zdrojov´ ym kódem lze d´ıky liberáln´ı 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éto práce jsou prvn´ı kroky vedouc´ı k formalizaci problematiky vyv´ıjej´ıc´ıch se systém˚ u, zahrnuj´ıc´ı pˇredevˇs´ım dynamickou manipulaci s modely a simulacemi v kontextu návrhu systém˚ u s vyuˇzit´ım simulace. Pˇritom byl kladen d˚ uraz na d˚ usledné provázán´ı teorie modelován´ı a simulace (reprezentované formalismem DEVS) s prax´ı v podobˇe nástroj˚ u SmallDEVS a PNtalk, které byly demonstrovány 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ém˚ 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é 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.

FIT, Brno University of Technology, Czech Rep.,

Recommend Documents