Diplomamunka

Petri hálók szimulációja és alkalmazásuk objektum-orientált környezetben

készítette: Bedők Dávid született 1983. december 12. Ajka

2011-2012 2012.04.28. v0.4.4

Konzulensek: Dr. Takács Márta Dr. Vámossy Zoltán

Óbudai Egyetem Mérnök Informatikus MSC Integrált Intelligens Rendszerek szakirány Tartalomjegyzék

Absztrakt v

1. Bevezetés 1

2. Irodalomkutatás 2 2.1. Prof. Dr. Carl Adam Petri ...... 2 2.2. Petri hálók ...... 3 2.2.1. Alap- és általános hálózat teória ...... 5 2.2.2. Előnyök/Hátrányok ...... 5 2.2.3. Kiterjesztések ...... 6 Reset él bevezetése (Reset arc) ...... 6 Kapacitás korlát bevezetése (Capacity limit) ...... 6 Tiltó él bevezetése (Inhibitor arc) ...... 6 Priorizált Petri hálók (Prioritised Petri nets) ...... 6 Színezett Petri hálók (Coloured Petri nets) ...... 7 Időzített Petri hálók (Timed Petri nets) ...... 7 Algebrai Petri hálók (Algebraic Petri nets) ...... 8 Hierarchikus Petri hálók (Hierarchical Petri nets) ...... 9 Objektum-orientált Petri hálók (Concurrent OO Petri Nets) . . . .9 Hibrid Petri hálók (Hybrid Petri nets) ...... 9 Folyamat hálózatok (Workflow nets) ...... 9 2.3. Petri Nets 2008 konferencia ...... 10 2.4. Matematikai modell ...... 11 2.4.1. Példa modell ...... 12 2.5. Petri Net Markup Language (PNML) ...... 15 2.5.1. Általános PNML szerkesztő - ePNK ...... 16 2.6. GDToolkit - Automata gráf rajzoló könyvtár ...... 16 2.7. Perti háló szerkesztők ...... 17 2.7.1. JARP Petri Nets Analyzer ...... 17

i TARTALOMJEGYZÉK ii

2.7.2. CPN Tools ...... 18 2.7.3. Petri Net Kernel ...... 18 2.7.4. Hybrid Petri Nets Simulator ...... 19 2.7.5. HPSim ...... 19 2.7.6. Platform Independent Petri net Editor ...... 20 2.7.7. Queueing Petri net Modeling Environment ...... 21 2.7.8. Renew ...... 22 2.7.9. Tool for Verification of Timed-Arc Petri Nets ...... 23 2.7.10. További eszközök ...... 23 2.8. Alkalmazások összehasonlítása ...... 24 2.9. XML állomány hitelességének biztosítása ...... 25 2.9.1. Gyakorlati és feltétel nélküli titkosság ...... 26 2.9.2. Kulcscsere ...... 27 2.9.3. Szimmetrikus titkosítás ...... 27 2.9.4. Aszimmetrikus titkosítás ...... 27 2.9.5. Az RSA algoritmus ...... 27 2.9.6. Certificate authority ...... 28 2.9.7. Eszközök és szabványok ...... 29 Java Keytool ...... 29 Portecle ...... 31 Open SSL ...... 32 2.10. Irodalomkutatás tanulsága ...... 33

3. Rendszerterv 37 3.1. Modellezés ...... 37 3.2. Kiegészítő specifikációk ...... 37 3.2.1. Nem funkcionális követelmények ...... 37 3.2.2. Kockázatok ...... 38 3.2.3. Üzleti szabályok ...... 38 3.2.4. Kifejezések ...... 39 3.3. Használati esetek, űrlapok és forgatókönyvek ...... 40 3.3.1. Actorok ...... 41 3.3.2. Elsődleges használati eset ...... 41 Sikertelen forgatókönyv ...... 44 3.3.3. Modulok ...... 45 Petri paletta modul ...... 45 TARTALOMJEGYZÉK iii

Állapot mátrix modul ...... 46 Állapot-hierarchia modul ...... 47 Térkép modul ...... 48 Szomszédossági mátrix modul ...... 48 Statisztika modul ...... 50 Események modul ...... 50 Tranzíció történet modul ...... 52 3.4. Aktivitás diagramok ...... 52 3.4.1. Elsődleges aktivitás ...... 53 3.4.2. Szimuláció aktivitás diagramja ...... 53 3.5. Együttműködési diagramok ...... 55 3.6. Osztály diagramok ...... 55 3.6.1. Kriptográfiai osztályok ...... 56 3.6.2. Lokalizáció ...... 56 3.6.3. Dialógusok ...... 57 3.6.4. Felsorolás típusok ...... 58 3.6.5. Űrlapok ...... 58 3.6.6. Képviselők ...... 61 3.6.7. Petri hálózatok ...... 61 3.6.8. Petri tételek osztályai ...... 62 3.6.9. Állapotvektorok osztályai ...... 63 3.6.10. Petri események ...... 64 3.6.11. Modul ablakok osztályai ...... 65 3.6.12. Utoljára megnyitott állományok ...... 66 3.6.13. További osztályok ...... 68

4. Petri hálózatok tárolása 69 4.1. Globális tulajdonságok ...... 70 4.2. Globális események ...... 71 4.3. Vizuális beállítások ...... 72 4.4. Láthatósági/megjelenítési beállítások ...... 73 4.5. Topológia ...... 73 4.6. Állapot-hierarchia ...... 76 TARTALOMJEGYZÉK iv

5. Integritás védelem 77 5.1. Root CA létrehozása ...... 77 5.2. Sub CA létrehozása ...... 80 5.3. Sub CA tanúsítványának aláírása ...... 81 5.4. Végfelhasználói kulcs generálása ...... 82 5.5. Végfelhasználói kulcs tanúsítványának aláírása ...... 82 5.6. Integráció a Petri szimulátorral ...... 84 5.6.1. Bejelentkezési folyamat ...... 84 5.6.2. Megnyitási folyamat ...... 85

6. Modell alkalmazása OO környezetben 86 6.1. Petri hálózat API bemutatása ...... 86 6.1.1. Topológia és egyéb építőkövek osztályai ...... 87 6.1.2. Petri hálózat osztálya ...... 88 6.1.3. Eseményvezérlés osztályai ...... 90 6.2. Petri hálózat API felhasználása ...... 91

7. Eredmények bemutatása 94 7.1. Bejelentkezés ...... 94 7.2. Új hálózat létrehozása ...... 95 7.3. Létező hálózat megnyitása ...... 96 7.4. Modulok ...... 97 7.4.1. Petri paletta ...... 98 7.4.2. Állapot mátrix ...... 101 7.4.3. Állapot-hierarchia ...... 101 7.4.4. Szomszédossági mátrix ...... 102 7.4.5. Statisztika és Tranzíció történet ...... 102 7.4.6. Petri események ...... 104 7.5. Lóverseny ...... 104

8. Összefoglalás 108

Résumé 110

Ábrák jegyzéke 112

Kódjegyzék 115

Irodalomjegyzék 117 Absztrakt

Ahogy a mai programozási technikák fejlődnek, a fejlesztők számára egy egyre ké- nyelmesebb környezet kezd felépülni. Azonban ennek számos jelen dokumentumban nem részletezett előnye mellett előfordulnak hátrányai is. Utóbbiak közé tartozik az, hogy a magasszintű imperativ/procedurális formális programozási nyelvek elnyomják a deklara- tív jellegű gondolkodásmódot. Ennek egyik iparban tapasztalható hatása pl. az, hogy egy pusztán Java fejlesztő egy relációs adatbázist csak és kizárólag adattárolásra szeretne használni, és ördögtől valónak tartja az SQL szintakszist. Szerencsére vannak azért olyan trendek, melyek nem engedik kihalni az alternatív gondolkodásmódot a mindennapi fej- lesztésben, gondolhatunk itt most pl. a Microsoft LINQ1 megoldására. Jelen dolgozat célja szintén egy, az automataelmélet általánosításának is tekinthető modell, a Petri háló bemutatása, és megoldáskeresés arra, hogy a Petri hálókat miként lehetne felhasználni imperatív nyelvekben is konkrét algoritmikus problémák megoldására. Annak érdekében, hogy az objektum-orientált világba beépített Petri háló a környe- zet lehetőségeit kihasználva tudjon működni, szükséges az e célra létrehozott hálózatok szabványos módon történő modellezése. Egy általános Petri háló modellje nem elégsé- ges, ugyanis ebben nincs helye pl. egy kiválasztott tranzíció tüzelésekor defininált, illetve egy pozíció tokenszámának változásakor meghatározott eseménynek, melyre a tervezett OO Petri hálóban fontos szerep hárul. A dolgozat az új leírásmód tervezése mellett a modell grafikus szerkesztője elkészítését is bemutatja, mely nem csupán egy céleszköz a feladat bemutatásához, hanem számos általános modullal is rendelkezik, mint pl. a token- játék lejátszását segítő eszközök, avagy az állapotok múltbeli/jövőbeli viszonyát bemutató állapot-hierarchia gráf. A modell részletes XSD sémával és egyedi névterekkel rendelkező XML 1.0 doku- mentum, a szerkesztő alkalmazás pedig Microsoft .NET 4.0 környezetben, C# nyelven készült el, lokalizált MDI alkalmazásként, az OOP elveit magas szinten képviselve. A felület tervezésekor kiemelt szerepet kapott a Petri hálók prezentálásának lehetősége. A Petri hálózatok beágyazását megvalósító API szintén C# nyelven, szabványos .NET DLL- ként publikált.

1 Language-Integrated Query, vagyis „nyelvbe ágyazott lekérdezés”. Térnyerése 2007-re, a .NET 3.5 keretrendszer megjelenésére tehető. A LINQ providerek segítségével adatokhoz úgy férhetünk hoz- zá, hogy deklaratív módon megírt SQL utasításokat adunk ki[1].

v 1. fejezet

Bevezetés

A Petri hálózat 1962-es publikálása óta nem csupán az automata elméletben számára kijelölt helyet foglalta el, hanem teret nyert a konkurens viselkedést bemutató architek- turális tervezés eszközeként is, meghódította az UML-t[64] valamint az oktatás is kezdi felfedezni. Utóbbi sok esetben az LTSA (Labelled Transition System Analyser[65]) verifi- kációs eszköz segítségével FSP (Finite State Processes) nyelven szimulálja a deadlock és kiéheztetés problémáját, azonban nem elhanyagolható tényező, hogy a Petri hálózatok a szálak közötti függőségeket (szinkronizáció) intuitívabb módon képesek prezentálni[63]. A dolgozat bemutatja a Petri hálózatok történetét, megemlékezik 2010-ben elhunyt megalkotójáról, Prof. Dr. Carl Adam Petriről, és röviden kitér matematikai modelljére. Az irodalomkutatás kapcsán nagyító alá kerül számos Petri hálózatok szimulálására lét- rehozott alkalmazás, és megfogalmazásra kerül egy új kiterjesztésre való igény. A rendszerterv a dolgozat kapcsán elkészülő Petri háló szimulációs alkalmazás UML modellezésének lépéseivel kezdődik, majd az osztálydiagramok részletezése mellett bemu- tatásra kerülnek az implementálás során alkalmazott tervezési minták és program techni- kai megoldások. Az eszköz újrafelhasználhatóságának, és - nem titkoltan - oktatásban való alkalma- zásának lehetőségét támogatandó fejezetek is helyet kaptak. Részletes leírás olvasható a Petri hálózatok XML formátumú állományának szerkezetéről és integritás-védelméről, illetve a szimulációs alkalmazás felhasználói leírásáról. A programozói könyvtár, az úgy- nevezetett API is bemutatásra kerül, és egyszerű felhasználására is található példa. A dolgozat utolsó fejezetében visszatekintünk az elért eredményekre, valamint érté- kelésre kerül az alkalmazás felhasználhatósága és továbbfejleszthetősége.

1 2. fejezet

Irodalomkutatás

2.1. Prof. Dr. Carl Adam Petri

Mindenek előtt ismerjük meg annak a személynek az életútját, aki nélkül Petri há- lókról nem beszélhetnénk. Legendák szerint[3] 13 éves volt, mikor 1939 augusztusában Carl Adam Petri[2] (Leipzig 1926. július 12 - Siegburg 2010. július 2) feltalálta a Petri hálókat, eredetileg kémiai folyamatok leírására (2.1. ábra).

2.1. ábra. Kémiai folyamatok leírása Petri hálókkal[7]

15 éves korában édesapja mesélt neki Konrad Zuse[4] (Berlin 1910. június 22 - Hünfeld 1995. december 18) német mérnök munkájáról, aki Z3 elnevezésű a világ első Turing-teljes gépét 1941 májusában mutatta be Berlinben[5]. Ez volt az első olyan teljesen automatikus gép, mely programozható volt, 2000 relé, 22 bit hosszúságú szavak és 5-10 Hz-es órafrek- vencia jellemezte1. A fiatal Petrire mindez nagy hatással volt, és saját számítógép építését tervezgette. Matematikai tanulmányait 1950-ben kezdte meg a hannoveri egyetemen (Technical University Hannover), öt évvel később már az IBM-nél gyakornok. 1956-ban diplomázik, majd két évig még az egyetemnél marad. 1959-től 1962-ig a bonni egyetemre (University of Bonn) kerül, a Petri hálókat egy disszertációja részeként 1962-ben itt publikálta „Kom- munikation mit Automaten” címmel (Kommunikáció automatával, lásd. 2.4 ábra), majd e kapcsán szerezte meg PhD címét Darmstadt-ban (Darmstadt University of Technology). 1963 és 1968 között a bonni egyetemen dolgozik, majd ezt követően a GMD2 kuta- tásokkal foglalkozó igazgatója. Számos előadásra hívták élete során a világ minden táján, az Amerikai Egyesült Államoktól Kínáig. A hamburgi egyetem (University of Hamburg)

1 Az eredeti Z3 az 1943-as berlini bombázások során elpusztult, de 1960-ban készítettek róla egy replikát (Deutsches Museum). 2 Gesellschaft für Mathematik und Datenverarbeitung, National Center for Mathematics and Com- puting

2 2. FEJEZET. IRODALOMKUTATÁS 3

2.2. ábra. Prof. Dr. Carl Adam Petri, 2007. augusztus 21.[3] tiszteletbeli professzora lett 1988-ban, hivatalosan 1991-ben vonult nyugdíjba. Az 1988- ban alapított Academia Europaea tagja, 1997-ban a tekintélyes „Werner von Siemens Ring” német kitüntetést kap, és még ebben az évben tagja lesz a „New York Academy of Sciences”-nek. 2007-ben az ATLAS-tól3 (Academy Gold Medal of Honor), 2009-ben pedig az IEEE-től4 kapott kitüntetést (Computer Pioneer Award)[6].

2.3. ábra. Konrad Zuse és Carl Adam Petri 1975-ben

2.2. Petri hálók

Ma a Petri hálózatokat a matematikai modellezési nyelvek közé soroljuk, mely el- sősorban az elosztott és párhuzamos rendszerek leírására használható. Egyidejűleg nyújt grafikus és matematikai leírást, és ez lehetővé teszi összetett rendszerek gyors áttekintését, és a részleteiben való elmerülést is. A mai modern számítástechnikában és -tudományban a munkafolyamat-vezérelt modellezésben van kiemelt szerepe (workflow management). A Petri hálózatok jelentősége az úgynevezett nem-determinisztikus rendszerek esetén talán még nagyobb. Az ilyen rendszerekre az jellemző, hogy egy-egy adott állapotukból nem egyértelműen következik a következő állapotuk.

3 Academy of Transdisciplinary Learning and Advanced Studies 4 Institute of Electrical and Electronics Engineers 2. FEJEZET. IRODALOMKUTATÁS 4

2.4. ábra. Az 1962-es disszertáció címlapja[6]

A Petri hálózat (Petri net, Place/Transition net) lényegében egy irányított és sú- lyozott páros gráf, melyben kétféle csomópont fordul elő, pozíció és tranzíció (2.5 ábra). Súlyozott irányított élek pozíciók és tranzíciók között, illetve tranzíciók és pozíciók között lehetnek csupán. Azokat a pozíciókat, melyekből irányított él megy egy tranzíció irányá- ba, bemeneti (input) helyeknek nevezzük, ahol pedig egy irányított él a tranzíciótól a pozícióig megy, kimenetinek (output).

2.5. ábra. Egy Petri háló szerkezetének mintája 2. FEJEZET. IRODALOMKUTATÁS 5

Minden egyes pozíció tartalmazhat tetszőleges természetes számú tokent. A tokene- ket szokás játékosoknak is nevezni, ezek eloszlása határozza meg a Petri háló aktuális állapotát (mint a szerializálható mezők az objektum-orientált környezetben). Definíció szerint egy tranzíció tüzeléséséről akkor beszélhetünk, ha az összes bemeneti helyén a hozzá tartozó él súlyának megfelelő token elérhető. Tüzelést követően a tranzícióhoz tar- tozó összes kimeneti helyen megjelenik annyi token/játékos, amennyi a hozzá vezető él súlya. A tüzelési folyamat ezen két része (input helyekről a tokenek elvétele, output he- lyekre a tokenek elhelyezése) teljesen atomic, szét nem választható, és közé más folyamat nem ékelhető. Érdemes megemlíteni, hogy a tokenek száma nem kell hogy állandó legyen minden egyes állapotában a Petri hálónak. Amennyiben az input helyekből vezető élek összsúlya X, az output helyekbe vezető élek össz-súlya pedig Y, akkor a tüzelés előtti és azt követő tokenek száma (Y-X)-el megváltozik, mely lehet pozitív és negatív szám is. A tüzelési sorrend, vagyis hogy az atomi tüzelések milyen sorrendben követik egy- mást, teljes mértékben nem-determinisztikus. Ha egy állapotból két különböző tranzíció is tüzelésre kész, akkor a tüzelő tranzíció kiválasztása általános esetben véletlenszerű. A rendszer nem zárja ki azt, hogy lehessen speciális kiegészítő szabályokkal úgy befolyásol- ni ez esetben a folyamatot, hogy a kiválasztás valaminek függvényében valósuljon meg (lásd. a 2.2.3 fejezetet a 6. oldalon). Az elosztott rendszerek konkurens viselkedésének szimulálása így egy általános és egy prioritásos esetben is elvégezhető. Létezik két speciális tranzíció is, a forrás- illetve a nyelő tranzíció. A forrástranzí- ciónak nincsen bemenete, és minden állapotban képes tüzelni, míg a nyelőtranzíciónak nincsen kimenete, így a tüzelés során hozzá került tokeneket „elnyeli”.

2.2.1. Alap- és általános hálózat teória

A Petri hálózat az automata uralkodó elmélete helyett egy újat mutatott, melynek a modern fizika (speciális relativitás elmélete, bizonytalanság elve, stb.) különösen örült[7]. Az úgynevezett „Basic Net Theory” (BNT) egy olyan elosztott rendszerek teóriájára épülő modell, mely nem ellentétes a fizika törvényeivel. Számos különböző mérnök bevonásá- val (közgazdaságtan, mechanika, számítástechnika, logika, biológia, távközlési protokollok szakértői) később ebből készült el a „General Net Theory” (GNT), melynek a következők a legfontosabb tulajdonságai:

• az üres halmaz nem tekinthető hálózatnak • a pozíciók/állapotok (states) és tranzíciók (transitions) különálló halmazok • nincs izolált elem a hálóban • nincsenek rövid körök (két elem közötti oda-vissza irányított élek)

2.2.2. Előnyök/Hátrányok

A Petri hálók előnyei már szóba kerültek a 2.2 fejezetben (3. oldal): egyidejűleg nyújtanak grafikus és matematikai reprezentációt, segítik a probléma gyors megértését, és bemutatják a nem-determinisztikus folyamatok lehetséges állapotait. 2. FEJEZET. IRODALOMKUTATÁS 6

Minden éremnek azonban két oldala van. Már egy egyszerűbb valós problémának a modellezéséhez is nagy Petri háló szükséges, és egy idő után a modell mérete az átlátha- tóságot rontja. Ezen utóbbira egy lehetséges megoldást nyújtanak a Színezett Petri hálók (lásd. a 2.2.3 fejezetet a 7. oldalon).

2.2.3. Kiterjesztések

A Petri hálóknak számos kiterjesztése létezik, melyek megpróbálnak a Petri hálók ne- gatív, illetve néhol korlátot jelentő tulajdonságain (időtől független, nem-determinisztikus működés, végtelen körök, átláthatatlanul nagy hálózatok) javítani. Néhány ezek közül visszafelé kompatibilis (ezeket vannak akik nem tekintik kiterjesztésnek), vagyis egyér- telműen visszaalakíthatóak általános Petri hálóvá (ilyenek pl. a Színezett Petri hálók), és van amelyik csupán plusz tulajdonságokkal ruházza fel a hálózatot, melyek leírására korábban nem volt lehetőség (pl. Időzített Petri hálók). Bizonyos kiterjesztések egymás- sal kombinálhatóak. A komplexebb kiterjesztéseket szokták Magas-szintű Petri hálóknak (High-level Petri nets) is nevezni.

Reset él bevezetése (Reset arc)

A reset él nem feltétele a tüzelésnek, hanem a tranzíció tüzelésekor kiüríti a pozíciót, vagyis tüzelést követően ott token nem lehet. Irányultsága csak pozíciótól tranzícióig mu- tathat, súlyozása nincsen. A reset élt bármely összetettebb kiterjesztés implementálhatja.

Kapacitás korlát bevezetése (Capacity limit)

A Petri hálók pozíciójának egy részéhez kapacitás korlátot állíthatunk be. Ez azt határozza meg, hogy legfeljebb mennyi token szerepelhet az adott pozícióban. Ezáltal ha egy adott helyen egy tranzíció tüzelése után a kapacitás korlátot a tokenek száma átlépné, akkor a tüzelés nem történhet meg. A kapacitás korlátot bármely összetettebb kiterjesztés implementálhatja.

Tiltó él bevezetése (Inhibitor arc)

A kapacitáskorlát helyett használhatunk tiltó éleket is. A tiltó él pozíció és tranzíció között azt jelöli, hogy amíg a pozíción token helyezkedik el, a tranzíció nem tüzelhet. A tiltó él is súlyozható, mely súly azt jelöli, hogy mennyi az a tokenszám a pozíción, mely hatására már a tiltás életbe lép (ha a pozíción a súlynak megfelelő, vagy annál több token van, a tiltás aktív, különben pedig ez nem jelent megszorítást). A tiltó él hasonlóan a reset élhez, csak pozíciótól tranzícióig mutathat. A kiterjesztést bármely összetettebb kiterjesztés implementálhatja.

Priorizált Petri hálók (Prioritised Petri nets)

Minden egyes tranzícióhoz egy-egy prioritás rendelhető. A tokenjáték folyamata ez által annyiban változik, hogy egy tranzíció csak akkor tüzelhet, ha nincs nála magasabb prioritású tüzelésre kész tranzíció. Tranzíciók prioritása lehet azonos, így valójában pri- oritás csoportok léteznek. Ha olyan állapot áll elő, ahol azonos prioritás csoportban lévő tranzíciók készek csak a tüzelésre, akkor a működés továbbra is nem-determinisztikus. A priorizált tranzíciókat bármely összetettebb kiterjesztés implementálhatja. 2. FEJEZET. IRODALOMKUTATÁS 7

Színezett Petri hálók (Coloured Petri nets)

A High-level Petri nets csoportba tartoznak a Színezett Petri hálók. Az eredeti Petri hálóban a tokenek megkülönböztethetetlenek, míg a CPN-ekben minden tokennek van egy értéke, ráadásul ez sokszor típusos, mely lehetővé teszi a műveletvégzést a modellben. Utóbbi támogatására megjelennek az élkifejezések és az őrfeltételek (guard expressions). Utóbbiak adott bemeneti élhez köthetőek, és meghatározzák azon feltételeket, melyek igaz volta esetén a csatolt tranzíció tüzelhet, míg az élkifejezések azt határozzák meg, hogy tüzelést követően a kimeneti helyeken mennyi és milyen típusú tokenjátékos jelenik meg (az élkifejezések paraméterei a bemeneti helyek tokenjei). Azt szokták mondani, hogy a Színezett Petri hálók egyben programozási nyelvek is. Elsősorban ott használják, ahol a szinkronizáció, a kommunikáció és az erőforrás-megosztás fontos. Ennek a kiterjesztésnek a bemutatását párhuzamba szokták állítani az assembly kód és a magas szintű programozási nyelvek kapcsolatával[12]. Elméletben mindkét szint kifejezőereje azonos, a gyakorlatban viszont a magas szintű nyelvek (és így a Színezett Petri hálók is) sokkal nagyobb modellező erővel rendelkeznek. A tokenek típusai, az élkifejezések és őrfeltételek Standard ML-ben adhatóak meg, mely egy erősen típusos funkcionális programozási nyelv, melyet Robin Milner[14] fejlesz- tett ki.

2.6. ábra. Elosztott adatbázis kezelő rendszer CPN modellje[13]

Minden Színezett Petri háló visszalakítható/széthajtogatható eredeti Petri hálóvá, ahogy ez a(z) 2.6 és 2.7 ábrákon is látható. A Színezett Petri hálók egyik legnagyobb egyetemi kutatása Dániában, az Aarhus Egyetemen[11] zajlik Kurt Jensen vezetésével.

Időzített Petri hálók (Timed Petri nets)

Az Időzített Petri hálók alapkoncepciója az, hogy nem elég a modell struktúráját defininálni, hanem az időzítést is szükséges, ugyanis a tokenjáték szabályai szerint egy tü- zelésre kész tranzíció a nem-determinisztikus döntést követően atomi lépésben, az „időtől idegen kifejezéssel” élve azonnal lejátszódik. Az eredeti Petri hálók kapcsán csupán logikai időről beszélhetünk, melyben egy adott tokenjátékban meg tudjuk határozni, hogy időben melyik tranzíció tüzelt korábban egy másikhoz viszonyítva. Fizikai időt (mely általában szabályosan periodikus) azonban nem tudunk rendelni ehhez a műveletsorhoz. Az Időzí- tett Petri hálókban léteznek olyan tranzíciók, melyek csupán egy külső időhöz kötötten 2. FEJEZET. IRODALOMKUTATÁS 8

2.7. ábra. Elosztott adatbázis kezelő rendszer PN modellje[13]

(pl. órajel) tüzelhetnek, illetve létezhetnek olyanok is, melyek hagyományos módon nem időzítettek. Tipikusan pl. egy forrástranzíció időzítésével tudjuk időtől függővé tenni a hálózatunk működését. Az időzítés bevezetésével a tokenjáték „lejátszhatóvá” válik, nem csupán léptethetővé, ezért a tranzícióknak egy további új tulajdonsága is megjelenik, még- pedig a késleltetés. Ezáltal „lejátszási” módban az időzítéshez nem kötött tranzíciók nem azonnal, hanem a beállított várakoztatást követően tüzelnek csupán.

Algebrai Petri hálók (Algebraic Petri nets)

Az Algebrai Petri hálókban[15] az üres, úgynevezett „black” tokeneket algebrai adat- típusoknak lehet megfeleltetni (Algebraic Abstract Data Types, AADT). Ebben a tu- lajdonságában ez a kiterjesztés hasonlóságot mutat a Színezett Petri hálókkal, azonban az APN hálózatokban az adattípusok magukkal hordoznak alaptételeknek tekinthető bi- zonyításokat/számításokat is. Jacques Vautherin készítette az első Algebrai Petri hálót 1985-ben, majd később Wolfang Reisig fejlesztette tovább. Filozófusok étkezési problémájának (Dining Philosophers problem5) Algebrai Petri hálóját mutatja be a 2.8 ábra.

5 A számítástudományban a „Dining Philisopher” probléma (Edsger Dijkstra, 1965) a párhuzamos algoritmusok, és azok szinkronizációjának a problémája, illetve módszer a szinkron hibák kizárá- sára. A szituáció: öt csendes filozófus ül egy végtelen mennyiségű spagetti tálat tartalmazó kerek asztalnál, mindegyik szomszédos ember között egy-egy villával. A filozófusoknak felváltva kell en- niük és gondolkodniuk, az evéshez azonban két villa szükséges (vagyis két szomszédos filozófus gondolkodása esetén lehet csak enni). Fontos, hogy a bal illetve a jobb villa felvétele különálló műveletek. A probléma arra keresi a megoldást, hogy egyik filozófus se éhezzen, vagyis a feladat nem más, mint a „deadlock” elkerülése.[16] 2. FEJEZET. IRODALOMKUTATÁS 9

2.8. ábra. Étkező filozófusok problémája Algebrai Petri hálóban[15]

Hierarchikus Petri hálók (Hierarchical Petri nets)

A hierarchikus kiterjesztés lehetővé teszi, hogy különböző absztrakciókban vizsgáljuk meg a hálózatot. Ebből eredeztethetőek az Objektum Petri hálók (Object Petri nets), ahol a Petri hálók beágyazott Petri hálókat tartalmazhatnak, amikkel szinkronizálás során kommunikálhatnak.

Objektum-orientált Petri hálók (Concurrent OO Petri Nets)

A CO-OPN-ek[17] az Algebrai Petri hálókon alapszanak, lényegében objektumok gyűjteményének párhuzamos kölcsönhatásáról szólnak.

Hibrid Petri hálók (Hybrid Petri nets)

A Hibrid Petri háló kiterjesztésben kétféle tranzíció és pozíció található meg: folya- matos (continuous) és diszkrét (discrete). Ennek megfelelően a hálózat is kettéválik egy folyamatos és egy diszkrét részre. Előbbi alkalmas futó folyamatok szimulálására, míg utóbbi elsősorban a logikai funkciókat modellezi. A Hibrid Petri háló nevét ezen kettőség- ből kapta, egy modellben egyesíti e két nézőpontot.

Folyamat hálózatok (Workflow nets)

Folyamat hálózatok[18] az eredeti hálózatok visszafelé nem kompatibilis módosításá- val kaphatóak meg. Pontosan egy olyan pozíciót kell a hálózatnak tartalmaznia, melynek nincsen bemeneti (input place), és pontosan egyet, melynek nincs kimeneti éle (output place). Fontos az is, hogy a hálózat erősen kötött, vagyis minden node között léteznie kell útnak. Négy speciális tranzíció is megjelenik a hálózatban: AND-join, AND-split, XOR-split és XOR-join, de ezek csupán „szintaktikai cukorkák”, ugyanis megfeleltethe- tőek megfelelő Petri háló szerkezeteknek (lásd. 2.9. ábra). A Folyamat hálózatokban négyféle trigger közül (erőforrás, üzenet, idő és „nincs” trigger) pontosan egyet minden tranzícióhoz hozzá kell rendelnünk. Tranzíciók mentén a hálózat szétvágható, és alfolyamatokat defininálhatunk ez által. 2. FEJEZET. IRODALOMKUTATÁS 10

2.9. ábra. Speciális tranzíciók a Folyamat hálózatokban[18]

2.3. Petri Nets 2008 konferencia

2008-ban Xi’an-ban (Kína) megrendezett Petri konferencián Carl Adam Petrit kérték fel egy előadásra. A prezentálásban Rüdiger Valk segített neki. A fejezetben ezen előadás rövid kivonata kerül ismertetésre. A konferencián kiemelték, hogy a Petri hálók két fontos területen játszanak szerepet: az információ feldolgozás terén, és az alapvető fizikai törvények kapcsán. Utóbbit úgy lehet érteni, hogy a Petri hálók segítségével a modern fizika fő tanai kerültek lefordításra, kombinatórikus formában. A Petri hálók világában két pólus létezik csupán (mint ahogy az már korábbi fejeze- tekben bemutatásra került): az állapotok (states) avagy más neveken helyek (places), kö- rülmények (conditions) és a tranzíciók (transitions). Ha veszünk egy konkrét modellezendő feladatot, pl. egy fizikai folyamatot, akkor az állapotok anyagok lesznek (substances), a tranzíciók pedig reakciók (reactions). A Petri világ pontjai között csupán kétféle kapcsolat lehet. A konferencia ezt adás- nak (give) és elvevésnek (take) mutatta be. A fizikai példánál maradva az adás lehet pl. létrehozás (creation), az elvetés pedig megsemmisítés (annihilation). A konferencián ezt követően a háló topológia került részletezésre. A tranzíciók men- tén zárt halmazokat lehet készíteni, és ez alapján összetettebb Petri hálókat tömörebb formában leírni. Két szituáció került kiemelésre, az egyik az Információ gyűjtés (2.10), míg a másik a Döntési helyzet (2.11) volt.

2.10. ábra. Információ gyűjtés 2. FEJEZET. IRODALOMKUTATÁS 11

Az Információ gyűjtés során a tranzíció tüzelésre kész, és a bementén lévő pozíciók tokenjei átkerülnek a kimenetére. Ezt a helyzetet nyílt alhálózatnak nevezhetjük (open subnet).

2.11. ábra. Döntés

A Döntési helyzetben egy pozíció tokenje nem-determinisztikus helyzetbe kerül. Két irányban is tüzelésre kész tranzíciók várakoznak a tokenjátékosra, de csak az egyik tüzelhet a következő atomi lépésben. Ezt a helyzetet zárt alhálózatnak nevezzük. Az előadás során fizikai és mérési példák kerültek bemutatásra (oszcillátor, forga- lom statisztika, azaz hány autó halad át egy adott X ablakon egy óra leforgása alatt). A végkövetkeztetése mindezeknek az lett, hogy ha a modellünket jeláramlás kombinatórikai koncepciójára alapozzuk, ahogy az informatika javasolja, és ragaszkodunk a folytonosság- hoz (ahogy Konrad Zuse tette), akkor a végén elkerülhetetlenül egy véges univerzumot kapunk. E véges halmazok kapcsán Albert Einstein megérzését, majd Stephen Hawking munkásságát idézték, ugyanis manapság egyre több szerző vitatkozik az univerzum véges modellezésének irányával. Vajon egy véges világot tudunk használni elemzésre tiszta lelkiismerettel? - dobják fel a kérdést. Természetesen igen, ha nem feledjük el hogy ez egy kivetítése csupán annak, amit tapasztalni lehet. Nem szabad elhinni, hogy „vezethetjük és irányíthatjuk a Végte- lent” (Command and Control of the Infinite). El kell utasítani a végtelen eredményeket, és meg kell vizsgálni a valóság elég jó közelítéséből eredő analízis eredményeit.

2.4. Matematikai modell

A Petri hálózatok matematikai modellje Tadao Murata 1989. április cikke (Invited Paper) alapján kerül bemutatásra[66]. Petri háló6 (network Graph): G = (P, T , W) ahol

Pozíciók (Places): p ∈ P Tranzíciók (Transitions): t ∈ T Irányított és súlyozott élek (Weighted edge/arc): w ∈ W ahol

W :(P × T ) ∪ (T × P) → N+ Irányított élek (Arcs): a ∈ A ahol bármely a ∈ A élhez w(a) ∈ N+ súly tartozik.

Továbbá P és T diszjunkt halmazok, vagyis egyik pozíció sem lehet tranzíció, és fordítva.

6 Jelölés: N+ a (pozitív) természetes számok halmaza. 2. FEJEZET. IRODALOMKUTATÁS 12

Definiálhatjuk •t jelölést, mely egy t ∈ T tranzíció kapcsán a bemeneti pozíciókat jelöli az adott tranzícióra nézve: •t = {p ∈ P|W (p, t) > 0} (vesszük azokat a pozíciókat, melyekből bármely t ∈ T tranzíció irányába él vezet). Definiálhatjuk a t• jelölést, mely egy t ∈ T tranzíció kapcsán a kimeneti pozíciókat jelöli az adott tranzícióra nézve: t• = {p ∈ P|W (t, p) > 0} (vesszük azokat a pozíciókat, melyekhez bármely t ∈ T tranzíció irányából él vezet). Definiálhatjuk a •p jelölést, mely egy p ∈ P pozíció kapcsán azokat a tranzíciókat jelöli, melyből ő tokeneket kaphat: •p = {t ∈ T |W (t, p) > 0}. Definiálhatjuk a p• jelölést, mely egy p ∈ P pozíció kapcsán azokat a tranzíciókat jelöli, melyekbe ő tokeneket adhat: p• = {t ∈ T |W (p, t) > 0}.

mpi jelölje egy hely pi ∈ P állapotát, melyet a benne szereplő tokenek száma definiál. M jelölje azt a vektort (Marking), mely a G Petri háló összes p ∈ P pozíciójára nézve T tartalmazza az mp értékeket: M = [mp1 , mp2 ..mpk ] ahol G hálónak k darab pozíciója van. M-et a G hálózat állapotának tekinthetjük. M0 jelölje (initial marking) azt a token eloszlás vektort, mely a kezdő token eloszlást reprezentálja.

A G = (P, T , W) hálót szokás bővebb alakban G = (P, T , W, M0) is megadni.

2.4.1. Példa modell

Vizsgáljunk meg a 2.12. ábrán látott G = (P, T , W, M0) hálózatot és írjuk fel a matematikai modellnek megfelelő halmazokat, vektorokat és mátrixokat.

2.12. ábra. Kiindulási M0 állapot

A pozíciókat a P = {P 1,P 2,P 3,P 4}, míg a tranzíciókat a T = {T 1,T 2,T 3} hal- maz defininálja a G hálózatban. Definíció szerint a pozíciók topológiájára a következőket írhatjuk fel: •P 1 = {T 1} P 1• = {T 2} •P 2 = {T 3} P 2• = {T 2} •P 3 = {T 2} P 3• = {T 1,T 3} •P 4 = {T 3} P 4• = {T 1} míg a tranzíciókra nézve: •T 1 = {P 3,P 4} T 1• = {P 1} •T 2 = {P 1,P 2} T 2• = {P 3} •T 3 = {P 3} T 3• = {P 2,P 4} 2. FEJEZET. IRODALOMKUTATÁS 13

A most bemutatott topológiában az élek súlya nem kap szerepet. Ezt orvosolva elké- szíthetjük a modell szomszédossági mátrixát is. Ehhez először fel kell írnunk a pozíciókból elinduló élek súlyát a következő W − mátrixban.

 0 0 1 1  −   W =  2 1 0 0  0 0 1 0

A W − mátrix értelmezése kapcsán segítséget jelent, ha feljegyezzük a sorokhoz a tranzí- ciókat, az oszlopokhoz pedig a pozíciókat valamilyen szabály szerinti sorrendben.

 P 1 P 2 P 3 P 4   T 1 0 0 1 1  −   W =    T 2 2 1 0 0  T 3 0 0 1 0

Ezt követően a W + mátrixot is megfogalmazzuk, a pozíciókba bemenő élek súlyával.

 1 0 0 0  +   W =  0 0 3 0  0 1 0 1

A szomszédossági mátrix a két mátrix elemenkénti kivonásával keletkezik: W T = W + − − W −.

 1 0 −1 −1  T   W =  −2 −1 3 0  0 1 −1 1

A kezdeti állapotban (2.12. ábra) összesen három token található, melyeknek elosz- T lása a következő M0 = [1, 0, 2, 0] állapot vektorral jellemezhető. Tüzelésre a T3 tranzíció képes csupán, így a következő lépés determinisztikusan adódik (2.13. ábra).

2.13. ábra. M1 állapot

A T3 tranzíció atomi tüzelését követően a P2 és P4 pozíciók tokent szereznek, míg T a P3 veszít. Az eloszlás így a következő lesz: M1 = [1, 1, 1, 1] . A tokenjátékosok száma növekedett. Az így kialakult állapot nem-determinisztikus helyzetet hozott létre. A T3 és a T1 tranzíció esetén is minden feltétel adott a tüzelésre. Tegyük fel, hogy a T1 tranzíció 2. FEJEZET. IRODALOMKUTATÁS 14

2.14. ábra. M2 állapot fog érvényesülni. A P4 és P3 pozíciók egy-egy tokent veszítenek, míg a T1 tranzíció output T helye, a P1 egy tokent szerez. A kialakult token eloszlás a következő lesz: M2 = [2, 1, 0, 0] (2.14. ábra). Az utolsó bemutatott lépésben egyedül a T2 tranzíció képes a tüzelésre, ez meg is történik. A P1 helyről kettő, míg a P2 helyről 1 token „átvándorol” a tüzelés következ- tében a P3 pozícióra, ahol így most 3 játékos lesz. A token eloszlás ennek megfelelően a T következő: M3 = [0, 0, 3, 0] (2.15. ábra).

2.15. ábra. M3 állapot

Ha folytatjuk az eddigi olykor determinisztikus, olyan nem-determinisztikus lépése- ket, akkor ezeket egy M állapot átmenet mátrixban tudjuk felírni.

 1 1 2 0 0 0 0   0 1 1 0 1 2 3    M =    2 1 0 3 2 1 0  0 1 0 0 1 2 3

Az utolsó lépésben kialakuló M6 állapot után nincs további lépésre lehetőség, a szi- muláció leáll, végállapot következik be (2.16. ábra). Hogy ez az automata elméletből is- meretes fogalom szerinti elfogadott állapotnak számít-e, az a modell mögötti problémától függ (mely a jelenlegi matematikai modell elemzése szempontjából lényegtelen).

Az M6 azonban nem az egyetlen végállapot a modellben. A szimuláció során több ponton voltak nem-determinisztikus lépések (M1,M4 és M5 állapotok esetén), melyek alternatív futási ágakat eredményezhetnek. A 2.17. ábráról leolvasható az állapotok hierarchia eloszlása és a három lehetséges végállapot is: M2B,M5B és M6. 2. FEJEZET. IRODALOMKUTATÁS 15

2.16. ábra. M3 állapot

2.17. ábra. Állapot-hierarchia

2.5. Petri Net Markup Language (PNML)

A hálózatok egységes leírásának céljából készült el a Petri Net Markup Language[19]. Eredetileg a Petri Net Kernel alkalmazás[20] kimeneti formátuma volt, de felmerült az igény különböző alkalmazások közti átjárhatóságra. E célra az XML alapú dokumentum- nál jobb leírást találni sem lehetett. Háromféle Petri hálózat írható le a PNML segítségével:

• Eredeti Petri hálók (Place/Transition nets) • Magas-szintű Petri hálózatok (High-Level Petri nets), ide tartoznak elsősorban a Színezett Petri hálók • Szimmetrikus hálók (Symmetric nets)

A PNML-t úgy alkották meg, hogy nyitott legyen a változásra. Helyet biztosít a háló- zatok általános leírására, és a specifikus, kiegészítő tulajdonságok tárolását is támogatja. Utóbbiak leírását egy különálló „Petri Net Type Definition” (PNTD) állomány tárolja. Minden hálózat típusnak szükséges a saját névterével ellátott PNTD-t definiálnia. A szabvány weboldalán a részletes leírás mellett példa PNML dokumentumok letöl- tésére is lehetőségünk van (elérhető pl. az eredeti Petri hálók között a „philosophers”, a „swimming pool” avagy a „token ring” modellje). A teljesség igénye nélkül jelenleg a következő eszközök támogatják a PNML formá- tumot:

• ePNK • OWLS2PNML • PNML Framework (Eclipse plugin) • Coloane (Université Pierre et Marie Curie) 2. FEJEZET. IRODALOMKUTATÁS 16

• Tina (LAAS/CNRS) • Petri Web (Technische Universiteit Eindhoven) • WoPeD (Workflow Petri Net Designer, Berufsakademie Karlsruhe) • ProM (TU/e) • Pneditor • Yasper (Yet Another Smart Process Editor)

2.5.1. Általános PNML szerkesztő - ePNK

Az ePNK project[21] célja egy általános GMF (Graphical Modeling Framework) szer- kesztő készítése, mely teljes mértékben a PNML szabványt követi. A megtervezett és elké- szített szerkesztő első körben Eclipse plugin-ként, 2011. augusztus 5. óta azonban önálló Windows desktop alkalmazásként is elérhető (ePNK product néven, bár ehhez csupán li- mitált támogatást adnak). A 2011. június 17-i verzió bár a PNML szabványt teljeskörűen támogatja, verziószáma v0.9.2, mert nem képes egyelőre minden elem exportálására/men- tésére. A fejlesztő Ekkart Kindler ezt a verziószámozást saját maga számára ösztönzésnek tekinti[21].

2.6. GDToolkit - Automata gráf rajzoló könyvtár

A GDToolkit[22] egy C++ „Graph Drawing Toolkit” (GDT) library, mely a gráf típusának és adatainak megadását követően automatikus legenerálja/megrajzolja azt, és ami miatt a dolgozat nagyítója alá kerül, az a Petri hálók támogatása (lásd. 2.18. ábra). Bár a projekt alapkoncepciója nagyon ígéretes, a végeredmény nem éri el a hozzá fűzött reményeket. Egy e célfeladatra kialakított könyvtártól szebb ábrákat és rugalmasabb lehe- tőségeket lehetne elvárni, illetve a háló további bővítése is problémákba ütközhet (egyedi feliratok, tokenek elhelyezése).

2.18. ábra. GDToolkit generált Petri hálója[22] 2. FEJEZET. IRODALOMKUTATÁS 17 2.7. Perti háló szerkesztők

Mivel a dolgozat egy saját Petri háló modell megtervezését tűzte ki célul (mely ma- gában foglal olyan többletinformációkat, melyek az objektum-orientált környezetbe való beágyazhatóságot segítik), ezért kézenfekvő hogy megvizsgálásra kerülnek a piacon jelen- leg elérhető kereskedelmi, illetve ingyenes Petri háló szerkesztő alkalmazások. Ezen prog- ramokat a hamburgi egyetem által karbantartott Petri hálók világa (Petri Nets World[10]) weboldalon be lehet regisztrálni, így ez remek kiindulás az ilyen alkalmazások keresésé- hez7. Elsősorban az újabb Windows operációs rendszereken (Vista, Windows 7) működő ingyenes alkalmazások kerülnek kipróbálásra, illetve előnyt élveznek a válogatás során azok, melyek elsősorban Petri háló szerkesztők, nem pedig csupán kiegészítésként támo- gatják azokat.

2.7.1. JARP Petri Nets Analyzer

A JARP[23] egy nagyon alapfunkciókkal rendelkező, Java nyelven Ricardo Sangoi Padilha által készített ingyenes Petri háló szerkesztő, mely semmilyen kiterjesztést nem támogat. Tokenjáték léptetésére is alkalmas, azonban csak manuális módon. A tüzelésre kész tranzíciók zölddel, míg a többi pirossal jelenik meg, és egér kattintással a felhaszná- lónak kell a zöldek közül választania.

2.19. ábra. JARP[23]

Vizuálisan három tokent jelenít meg, ezt követően csak a tokenek darabszáma látszó- dik. A tokenjátékosok pozíciókra helyezése és elvétele a pozíciót kijelölve két dinamikusan megjelenő nyomógombbal lehetséges. Ugyanígy működik az élek súlyozása is, és ez vég- eredményben kényelmes megoldás. Az élek egyenes vonalakból állnak, azonban minden vonal a középső pontján megtörhető. A pozíciók és tranzíciók tetszőlges mértékben mé- retezhetőek, bár a méretezés művelete néhol „elszámolja” magát. Mentés során az ARP formátumot támogatja, melyben a komponensek vizuális el- helyezésére nincs hely. Ennek megoldására belekerült az alkalmazásba a PNML formá- tumban való exportálási lehetőség, bár meg kell jegyezni, hogy a PNML hivatalos oldalán megtalálható példák megnyitásakor kivételt dob. Az elkészült hálót többféle grafikai for- mátumban is lementhetjük (*.gif, *.jpeg, *.png és *.ppm).

7 http://www.informatik.uni−hamburg.de/TGI/PetriNets/tools/quick.html 2. FEJEZET. IRODALOMKUTATÁS 18

2.7.2. CPN Tools

Színezett Petri hálók szerkesztésére alkalmas ingyenes desktop alkalmazás[24], leg- frissebb verziója 2011. júliusi (lásd. 2.20. ábra). A grafikus szerkesztője nem mondható szokásosnak, minden funkció, legyen az egy mentési menü elérése, avagy egy új pozíció elhelyezése, egyedi kör alakú helyi menüből érhető el. Az irányított élek/ívek megrajzolá- sában a felhasználónak talán túl sok a szerepe. Az alkalmazás az éleket bár simítja, ha a felhasználó megtörte azokat, az elemek áthelyezésével átláthatatlan ábra fog keletkezni.

2.20. ábra. CPN Tools[24]

Menteni részletes XML dokumentumba lehet, melyhez verziónként DTD állomány is elérhető (legfrissebb http://cpntools.org/DTD/6/cpn.dtd), így akár külső eszközzel is egyértelműen feldolgozható. Érdekes grafikai megoldás a szerkesztő felületén csoportok definiálásának lehetősége. Egy időben csak egy lehet az aktív, és csak ezen csoport ele- mei látszódnak „élesen”. Ilyenkor egyébként minden más elem is szerkeszthető korlátozás nélkül, csupán nem hangsúlyos. Egy elem több csoportba is tartozhat, így a felhaszná- ló szabadságfoka elég magas. Mindez nyilván összetett hálók esetén jelent átláthatósági segítséget.

2.7.3. Petri Net Kernel

Python és Java nyelven érhető el a szintén ingyenes PNK legfrissebb verziója, mely már nem mondható frissnek (2001.05.13). Az alkalmazás jelentősége abban áll, hogy ezen alkalmazás kapcsán készült el a Petri Net Markup Language, vagyis a szabványos leírás a Petri hálók számára. A Petri Net Kernel[20] sokféle hálózatot támogat, a felhasználói felülete azonban nagyon sok szempontból kényelmetlen, mely minden tekintetben nem okolható a program korával, inkább tervezési kérdés. Előnye azonban a felületnek, hogy minden egyes elemét drag-and-drop módszerrel lehet áthelyezni, és mindez igaz az ívek görbületére is. 2. FEJEZET. IRODALOMKUTATÁS 19

2.7.4. Hybrid Petri Nets Simulator

A spanyol Alberto Amengual által 2004-ben Java nyelven készített Hybrid Petri Nets Simulator[25] egy igényes kivitelű alapfunkciókat ellátó ingyenes Hibrid Petri háló szer- kesztő. Nevének megfelelően a diszkrét pozíciók és tranzíciók mellett lehetőség van folya- matos helyek és tranzíciók elhelyezésére is. A grafikus szerkesztője teljesen megfelelőnek mondható. A grafikailag kritikus élrajzolás kétféle módon is történhet: tetszőleges ponton törhető vonalak halmazából, avagy két pont által széthúzott görbéből lehet építkezni. A tokenek kirajzolása a pozíciókhoz öt tokenig grafikailag is megjelenik, ezt követően csak számként látszódik.

2.21. ábra. Hybrid Petri Nets Simulator[25]

A pozíciókat három méretben lehet megjeleníteni, ezzel a fontosabb részek kiemel- hetőek, illetve a kevésbé fontosak a háttérbe szoríthatóak. Támogatja a kapacitás korlát kiterjesztést a helyekre nézve. A tranzíciók szintén három méretben léteznek, illetve 45 fokban forgathatóak, késleltetés állítható be számukra. Az éleknek súlyuk lehet (de ehhez grafikai támogatás és megjelenítésbeli különbség nincsen), pozícióknak és tranzícióknak pedig feliratuk, melyek egyedileg ki- és bekapcsolhatóak. Az ábrán tetszőleges helyen an- notációk (megjegyzések) helyezhetőek el. Szimulációs módba lépve a szerkesztő eszközök inaktívak lesznek. Lehetőség van egye- sével léptetni a tokenjátékot, illetve folyamatos lejátszásra állítani. A tüzelésre kész tran- zíciók minden lépésben kiemelődnek pirossal. A tokenjáték az ábrán megjelenik, de több információt minderről nem kapunk. A kezdeti állapot egy gombnyomással viszaállítható. Az elkészült Petri hálót PNG illetve PostScript formátumba exportálni lehet, illetve van lehetőség közvetlen nyomtatásra is.

2.7.5. HPSim

A HPSim[26] alkalmazást Henryk Anschuetz készítette tanulmányai során 1999 és 2001 között, C++ nyelven. Természetesen ez az alkalmazás is ingyenes. Többablakos, 2. FEJEZET. IRODALOMKUTATÁS 20

úgynevezett MDI alkalmazás, nagyítási és nyomtatási funkciókkal ellátva. Grafikus szer- kesztője vizuálisan egyszerű, kissé szögletes, azonban minden fontosabb dolgot gyorsan el lehet érni benne. Él szerkesztője egyenes vonalakon alapszik, azonban tetszőleges mély- ségben minden ponton törhető. Támogatja a tiltó éleket (inhibitor arc) és az élsúlyokat, bár utóbbi grafikusan nem jelenik meg. Négy token kirajzolása még vizuális, ezt követően szám formájú. A pozíciók és tranzíciók öt méretben érhetőek el (kiemelési szerep). A he- lyeknek kapacitás korlát, míg a tranzícióknak késleltetés állítható be. Szöveges és grafikus annotációk is elhelyezhetőek az ábrán, hogy támogassák az ábra értelmezését.

2.22. ábra. HPSim[26]

Minden kijelölt elemnek tulajdonság lapja van, számos beállítási lehetőség csak itt érhető el (pl. a tokenek számának megadása, melyhez nincs rajzoló eszköz). A tulajdon- ság lap kényelmesebb és gyorsabb szerkesztést tesz lehetővé, mint az eddig bemutatott alkalmazások helyi menüs megoldása (részben utóbbi is megtalálható a HPSim-ben). Az elemek csoportosíthatóak, előtérbe illetve háttérbe helyezhetőek. A tokenjáték rendkívül látványos, grafikusan látszódnak a tokenek mozgásai az él irányultságának megfelelően. Mentési formátuma (*.hps) teljesen egyedi bináris állomány. Van lehetőség exportálni bitmap (*.bmp), text (*.txt) és windows ini (*.hpx) formátumba, utóbbit importnálni is tudja. Szabványokat egyik kimenet sem követ, újrafelhasználási lehetősége gyakorlatilag nincs.

2.7.6. Platform Independent Petri net Editor

A PIPE[27] alkalmazás pár kiterjesztést támogat (tiltó élek, időzített tranzíciók), bár alapvetően az eredeti Petri hálók szerkesztésére készítették. Grafikus szerkesztője kielégítő, bár tud kényelmetlenséget okozni. XSLT transzformáció segítségével a PNML formátu- mot közvetve támogatja, lévén XML kimenetet készít. Több mint valószínű, hogy a már bemutatott Hybrid Petri Nets Simulator (2.7.4. fejezet) alapjaira épül, teljesen hasonló a menüszerkezetük alapja, az XML kimenetük, illetve az ikonkészletük. A 2.23. ábrán épp a filozófusok spaggeti evésének problémáját követhetjük nyomon. Az alkalmazás erőssége a kép bal oldalán megtalálható modulok sokasága. Az aktuális hálózatra nézve különféle elérhetőségi méréseket és gráfokat, deadlock kalkulációkat, át- futási időket lehet számoltatni, illetve az állapotmátrix megjelenítésére is lehetőségünk van. A projekt célja a fejlesztési üteméből szinte adódik: egy egyetemi projektről van szó, melyet évről évre a hallgatók fejlesztenek tovább, modularizálnak. A legutolsó 4.0-ás változata 2011. szeptemberi forrásról árulkodik. 2. FEJEZET. IRODALOMKUTATÁS 21

2.23. ábra. Platform Independent Petri net Editor képernyője[27]

A PIPE legújabb változata a tokeneket több dimenzióba helyezi: a játékosok adott színnel és névvel jelzett csoportokra oszthatók. Minden pozíción és minden élen token- csoportonként lehet tokenszámot illetve élsúlyt definiálni. Ezzel a kiterjesztéssel néhány egyedi problémakör egyszerűbb formában modellezhető (a kiterjesztés visszafelé kompa- tibilis a place/transition hálókkal). Szintén egy remek megoldása az alkalmazásnak az „animáció történet” adatlap (animation history), mely szimuláció során készül. Az aktuá- lisan tüzelő tranzíció neve egy rendezett listában megjelenik. Ha a Petri hálózat tranzíció neveit jól választjuk meg, akkor a naplóban értelmes mondatokat, kifejezéseket olvasha- tunk.

2.7.7. Queueing Petri net Modeling Environment

A QPME[28] elnevezésű alkalmazás modern Eclipse környezetben készült több éves egyetemi projekt, mely 2003 óta a mai napig aktív, és leírása szerint jelenleg több mint 120 egyetemen használják, ingyenes termék. Kiemelt funkciói között szerepel a riportolás (token átvitel (throughput), min/max/átlagos token szám, stb.) lehetősége, a különböző diagramok, táblázatok generálása.

2.24. ábra. Queueing Petri net Modeling Environment[28]

A projekt fejlesztése jelenleg is folyik a modell analizálás területén. 2. FEJEZET. IRODALOMKUTATÁS 22

2.7.8. Renew

A Renew[29] Petri háló szimulátor megpróbál egy picit kiemelkedni a tömegből. Azon kívül, hogy az eredeti és a Színezett Petri hálókat szerkeszti és szimulálja (valamint számos kisebb kiterjesztést is megvalósít (pl.: tiltó és reset él), egy egyedi koncepcióval is előáll: a hálózatokat típusoknak, objektum-orientált szóval élve osztályoknak tekinti, és a tokenjá- ték szimulálása kezdetén hálózatokat példányosít (és a szimuláció ezen háló példányokon megy végbe). Ezen hálózatokat Referencia hálónak (Reference net) nevezte el a Renew koncepciója. A Színezett Petri hálók működési elvével rokonságban számos pontján a há- lónak kifejezéseket helyezhetünk el. A kifejezéseket a Renew-ban - apróbb módosításokkal és egyszerűsítésekkel - Java szintaktikával határozhatjuk meg. Utóbbinak fontos szerepe van, ugyanis a hálózatok Java programba betölthetőek (mint a de.renew.net.NetInstance osztály példányai), és szimulációjuk lejátszható. Gyakorlatilag az a nem-determinisztikus eredmény, mely a hálózat szimulálásával a külső szerkesztőben is előáll, előállítható egy Java alkalmazásba ágyazva is. A fenti koncepció során a szimulált hálózat példányok - hasonlóan az objektum pél- dányokhoz - mind egyediek, létrehozásukkor lehetőség van inicializálásra, és a tokenjáték során elérhetünk Java objektumokat, melyeken metódusokat hívhatunk, állapotokat vál- toztathatunk. Fontos kiemelni, hogy bármilyen műveletvégzést is hajtunk végre az objek- tumokkal, azt mind előre, a Referencia hálóban kell „lekódolnunk”. A Referencia hálókban nem csupán a tokeneknek van típusuk (mint a Színezett Pet- ri hálókban), hanem opcionálisan a pozícióknak is (a típus Java primitív illetve bármely Java referencia lehet). Ez meghatározza, hogy milyen típusú tokeneket tartalmazhat. A pozíciókhoz ennek megfelelően definiálhatunk inicializálási kifejezéseket, melyeknek ered- ménye a kiindulási tokeneloszlást fogja meghatározni, illetve globális inicializációs blokkok is léteznek, melyek a hálózat példányosításakor hajtódnak végre. Szintén egy párhuzam a Színezett Petri hálókkal az élkifejezések megadásának lehetősége. Egy tranzíció tüzelé- sekor az él súlyát, vagyis a „mozgó” tokenek számát ez a kifejezés határozza meg. Létre- hozhatunk őrkifejezéseket is: egy tranzíció csak akkor tüzelhet, ha a hozzá tartozó összes őrkifejezés igaz értékkel tér vissza. Az egyes kifejezésekben használhatunk metódus hívásokat, melyek pl. a token tí- pusából adódhatnak, és szintaktikailag helyesek. A metódusok sokszor lefuthatnak, ezt tervezéskor figyelembe kell venni, hiszen pl. annak eldöntése, hogy egy tranzíció tüzelhet- e, avagy sem, adódhat egy kifejezés értékétől, azonban az ebben definiált metódus akkor is lefut, ha végeredményben a tranzíció nem tüzelt. Pontosan e miatt a tranzíciókhoz tetszőlges számú akciót (action) is defininálhatunk, melyek pontosan egyszer, csupán a tranzíció tüzelésekor hajtódnak végre. Minden eddigi specialitás még nem lenne túl meggyőző arra nézve, hogy miért is nyújt mindez többet, mint pl. egy jól megtervezett Színezett Petri háló. Lényegében utóbbi is egy komplett magas szintű programozási nyelvnek fogható fel, mindehhez a Renew még nem tesz hozzá a Java szintaktika használatával (sőt). Van azonban a Renew Referencia hálóinak egy lehetősége, melyre a Színezett Petri háló leírása nem alkalmas, és mindez a háló példányokból adódik. Felmerült ugyanis az igény a koncepció során arra, hogy két egymástól független Referencia háló példány egymással kommunikálni tudjon, vagyis közöttük szinkronizáció lépjen fel. Ennek kidolgozására a tranzíciókhoz definiálni lehet egy downlink (küldő oldalon) és egy uplink tulajdonságot, mely segítségével szinkron kommunikáció tud felépülni (szinkron esetben a két példánynak egy időben jelen kell lennie a memóriában). A szinkronizáció egyébként a Színezett Petri hálóknál is felmerült már, ugyanis néhol előnyös volna, ha két tranzíció egy időben automatikusan tudna tüzelni. 2. FEJEZET. IRODALOMKUTATÁS 23

A Renew szerkesztőjében megtalálható egy úgynevezett manuális tranzíció (manual transition). Ha a szimuláció során az adott tranzíció tüzelhetne, akkor a folyamat megáll, és egérrel a felhasználónak kell a szimulációt továbbvinnie.

2.7.9. Tool for Verification of Timed-Arc Petri Nets

A TAPAAL[30] egy friss Időzített Petri hálók szimulációját támogató projekt, mely fejlesztése a dolgozat írásának idejében is folyik (2011. augusztusi az utolsó verziója). Alapja a Platform Independent Petri net Editorhoz (lásd. 2.7.6. fejezet) hasonlóan a Hybrid Petri Nets Simulatorra (lásd. 2.7.4. fejezet) épül, így szerkesztője nagy meglepetést nem tartogat. Szállító (transport arc) és tiltó éleket támogat.

2.25. ábra. Tool for Verification of Timed-Arc Petri Nets[30]

A 2.25. ábra egy termelő-fogyasztó probléma modelljét mutatja be az alkalmazás keretrendszerében.

2.7.10. További eszközök

AlPiNA[31] (ingyenes): Algebrai Petri hálók szerkesztésére alkalmas Eclipse plugin. ARP[32] (ingyenes): Prof. Carlos A. Maziero alkalmazása, mely Turbo Pascal 6 nyelven készült (MS-DOS). CoopnBuilder[33] (ingyenes): Objektum-orientált Petri hálók (CO-OPN) szerkesztő programja. CPN-AMI[34] (ingyenes): A párizsi Sorbonne egyetem alatt működő intézet Eclipse plu- ginja Petri hálókhoz. ExSpect[35] (ingyenes): Számos Petri hálót támogató, dokumentációja alapján ígéretes eszköz, mely ma már ingyenes (a hivatalos weboldalán elérhető a telepítéskor megadan- dó serial), azonban Windows Vista és 7 operációs rendszereken indulást követően kilép. Erről a weboldal is tájékoztat, és felhívja a figyelmet az alkalmazás támogatásának teljes hiányára. Integrated Net Analyzer[36] (ingyenes): Egy karakteres Petri háló szerkesztő, elvben akár Színezett Petri hálókat is támogat. A szöveges kimenetét egy konvertáló script se- gítségével a Petri Net Kernel meg tudja jeleníteni. JPetriNet[37] (ingyenes): Rendkívül egyszerű Java nyelven készített szerkesztő. Mind grafikailag, mind szimuláció szempontjából keveset tud, a hálózatokat elmenteni sem le- het. 2. FEJEZET. IRODALOMKUTATÁS 24

Netlab[38] (kereskedelmi): 2004-es korához képest nem kifejezetten elegáns kinézetű al- kalmazás, mely pár apróbb kiterjesztést támogat, mint pl. a kapacitás korlát, avagy a tranzíciók késleltetése. A program csak német nyelven érhető el. P3[39] (ingyenes): Ígéretesnek tűnő 2008-as alkalmazás, mely bár elsősorban eredeti Pet- ri hálókat támogat, számos elemzést elvégez leírása szerint (elérhetőségi fa (reachability tree), tüzelési fa (firing tree), tüzelési gráf (firing graph)), valamint PNML formátumban képes menteni. Sajnos Windows Vista és Windows 7 rendszereken nem indul el. Pace[40] (kereskedelmi): Érdekességként kerül megemlítésre a Pace nevű alkalmazás, mely nem a Petri háló részletes analízisét tűzte ki célul, hanem üzleti folyamatok (csomag- küldés, értesítés, riportkészítés stb.) vizuális szimulálását, elsősorban a probléma gyorsabb átlátásának céljából. Petri-LLD[41] (ingyenes): Az alkalmazás egy olyan korlátozást támogat, miszerint egy pozíció csak egy tokent tartalmazhat. Ezen tulajdonsága azt a célt szolgálja, hogy könnyen lehessen az elkészült modellt PLC-re (Programmable Logic Controllers) tölteni. Elsősor- ban oktatási célból készítette James Brusey 2005-ben a cambridge-i egyetemen. Petri Net Toolbox[42] (kereskedelmi): A romániai alkalmazás Matlab v6.1-hez készült (de a legújabb változata Matlab R2010a-t is támogat) kiegészítő, mely a Petri hálók szi- mulálást és analízisét tűzte ki célul. Petrisim[43] (ingyenes): Turbo Pascalban készített MS-DOS-os alkalmazás, mely az ope- rációs rendszere ellenére fejlettnek mondható. Nyilvánvaló korlátaival azonban számolni kell. Petruchio[44] (ingyenes): Egy teljes Eclipse fejlesztői környezetre épülő Petri net szimu- látor, mely még talán gyerekcipőben jár, a jövőben érdemes lehet odafigyelni rá. SimHPN[46] (kereskedelmi): Petri hálók szimulálására szakosodott Matlab kiegészítő. VisualPetri[47] (ingyenes): Egyszerű kiterjesztést nem támogató Petri háló szimulátor. A rajzolást a GDI+ könyvtárra építette. Workflow Petri Net Designer[48] (ingyenes): Petri és Folyamat hálózatokat (Workflow nets) támogat a WoPeD. A PNML mentési formátumot támgatja, legújabb változata 2011. július 5.-ei. Yasper[49] (ingyenes): Egy felhasználóbarát felületet kínáló Időzített Petri hálókat tá- mogató alkalmazás, PNML mentési formátum támogatással.

2.8. Alkalmazások összehasonlítása

A részletesebben elemzett alkalmazások egymáshoz képest táblázatos formában össze- hasonlításra kerülnek. A táblázatban az alkalmazások rövidített nevei olvashatóak.

Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Reset él x Súlyozott élek x x x x x x x x Többszörös élsúlyok x x Kapacitás korlát x x x x Tiltó él x x x x x x Tranzíció prioritás x x Időzített tranzíciók x x x x x x

2.1. táblázat. Alapvető kiterjesztések szerint

Az alkalmazások általában egy meghatározott Petri háló kiterjesztés köré készültek, illetőleg egy egyedi kiterjesztés referencia implementációi. Ezért összehasonlításuk során csupán az alapvető kiterjesztések kerülnek be a táblázatba (2.1. táblázat). 2. FEJEZET. IRODALOMKUTATÁS 25

Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Tokenjáték manuális x x x Speciális léptetéssel manuális tranzícióval Automata tokenjáték x x x x x szimuláció Tokenjáték egér kattin- x x tással Állapot visszaállítás x Kezdeti Kezdeti x állapot állapot Tüzelésre kész tranzíci- x x x ók jelölése

2.2. táblázat. Szimuláció lehetőségei szerint

Csak azon szempontok kerültek felsorolásra, melyeket legalább egy vizsgált alkalma- zás támogat, ez azonban nem azt jelenti, hogy ne lennének olyan tulajdonságok, melyek ne érdemelnének meg egy-egy új sort (pl. él súlyozásának grafikai támogatása, jegyzetek és objektumok összekapcsolása, állapot-hierarchia megjelenítése).

Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Vizuális toke- 3 1 0 5 (kis mé- 4 5 0 0 0 nek száma retben 0) Megtörhető él Egyenesek, Van, Megfelelő Egyenesek Egyenesek, Egyenesek, Egyenesek rajzolás több szin- de nem és görbék, több szin- illetve gör- mentén, ten aránytartó két szinten ten bék, tet- tetsző- szőleges leges töréspont- töréspont- tal tal Méretezhetőség Korlátlan 3 méret 5 méret Tranzíciók 45 fok 45 fok 45 fok forgatása Feliratok x x x x x kikapcsolha- tósága Annotációk, x x x x x x jegyzetek Hálózat x x x x nagyítása, kicsinyítése Grafikus Geometriai Geometriai annotációk alakzatok alakzatok, képek 2.3. táblázat. Grafikai beállítások szerinti összehasonlítás

A nagyító alá került alkalmazásokat sokszor nehéz egymáshoz képest pár szóban összehasonlítani, hiába hasonló pl. az élrajzolás menete, ha pl. a CPN Tools esetén a vég- pontok áthelyezésére a megtört élek teljesen érzéketlenek, és hiába tűnik „forradalminak” a Petri Net Kernel egyedi GUI megoldása, ha szokatlansága miatt közel használhatatlan. Azt sem tudja a táblázat érzékeltetni, hogy a HPSim esetén a nagyítás bár lehetséges, gyakorlatban ezt biztosan nem tesztelték, illetőleg hogy hiába a Renew számos remek ötlete, a programmal Petri hálót rajzolni napokba telik. A Queueing Petri net Modeling Environment elnevezésű alkalmazás szinte sehol sem szerepel a táblázatokban, azonban ez elsősorban félkész jellege miatt van, várhatóan sokkal több lesz ebben az Eclipse-re épülő szimulátorban, ha elkészül.

2.9. XML állomány hitelességének biztosítása

A dolgozat témájának nem fő csapásiránya az aszimmetrikus titkosítás, mint kriptog- ráfiai eljárás, de tervezett felhasználása miatt egy fejezetben bemutatásra kerül. Az aszi- metrikus, avagy nyilvános kulcsú titkosítás nem csupán előzetes kulcscsere nélküli adatok titkosítására használható, hanem egyértelmű hitelesítésre is. A dolgozat szempontjából főleg e miatt került képbe. Az algoritmusok matematikai háttere nem kerül bemutatásra. 2. FEJEZET. IRODALOMKUTATÁS 26

Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Tulajdonság Helyi iko- Helyi Helyi Helyi me- Tulajdonság Tulajdonság Helyi me- módosítás nok menü menü nü lap, helyi lap nü menü Grafikus cso- x x portosítás Modulok Riportot Eclipse-re generáló épül, a modulok lehetősége adott Statisztika modulként x Rácsháló Van, és x x x három fix szinten sűríthető Rácshálóhoz x x x igazítás Tranzíció x történet Mentési for- ARP, XML XML HPS PNML PNML mátum PNML Exportálási GIF, PNG, PS BMP, PNG, PS, PNG, PS, lehetőség JPEG, TXT, eDSPN TikZ PNG, HPX PPM (INI) 2.4. táblázat. Egyéb szempontok szerinti összehasonlítás

2.9.1. Gyakorlati és feltétel nélküli titkosság

Claude Shannon a 20. században bevezette a gyakorlati titkosság, illetve a feltétel nélküli titkosság fogalmát. Előbbi megfelelő védelmet nyújt, amennyiben feltöréséhez az aktuális kornak megfelelő léptékkel mérve irreálisan nagy számítási kapacitás szükséges, utóbbi kapcsán viszont az mondható el, hogy a megszerezhető összes információ birtoká- ban sem tudjuk megfejteni, legyen bármekkora számítási kapacitásunk[51]. Bár könnyen mondhatnánk, hogy a feltétel nélküli titkosság elnyomja a gyakorlati titkosságot biztosító módszereket, valójában mindkettőnek megvan a maga felhasználási területe. A gyakorla- ti titkosságot alkalmazó módszerek előnye lehet a gyorsaság (Data Encryption Standard (DES), Advanced Encryption Standard (AES)) avagy az előzetes kulcscsere szükségtelen- sége (Diffie Hellman (DH), Rivest Shamir Adleman (RSA))8. Ezzel szemben a legismer- tebb feltétel nélküli titkosságot felmutató algoritmus a véletlen átkulcsolás (One Time Pad (OTP)), mely a gyakorlatban a rendkívül nagy kulcsmérete miatt (a kulcs mérete meg kell hogy egyezzen a titkosítandó üzenet hosszával) csak speciális körülmények között használható, ugyanis egy kulcsot nem szabad kétszer felhasználni, mivel ekkor az OTP-vel kódolt üzenetek azonnal törhetővé válnak9. Így bár a gyakorlati titkosság módszereit el- vekben a jövő számítógépei fel tudják majd törni10, mivel a kulcsok újrafelhasználhatósága az informatika világában szükségszerű, a feltétel nélküli titkosságot biztosító módszerek ritkábbak. 8 A gyorsaságot és a kulcscsere szükségtelenségét egyesíti a Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protokollok mögötti úgynevezett „handshake” (kézfogás). 9 Az OTP módszer egyszerűségében nagyszerű. Ha pl. két személy közötti üzenetváltás kulcsa az aktuális amerikai Playboy magazin hivatalos honlapjáról a címlap (mint bináris adat), akkor az üzenetváltásuk matematikailag törhetetlen, és fenntartható az is, hogy egy kulcs csupán egyszer legyen használva. 10 Az 1976-77-ben szabványosított Data Encryption Standard (DES) algoritmus 56 bites kulcsait 1998-ban pár nap alatt, egy évvel később már napon belül tudták törni szuperszámítógépek, 2007- ben pedig egy 10000 dolláros összeköltségű COPACOBANA párhuzamos rendszer 7 napon belül megfejtette. Ez gyakorlatilag a DES végét jelentette (bár még ma is széles körben használják egyes változatait, pl. TripleDES), a 2001. november 26.-án bejelentett Advanced Encryption Standard (AES) váltotta. A korrektség kedvéért azért meg kell említeni, hogy amennyiben a DES kulcso- kat rövid időközönként cseréljünk (pl. a kulcscserét publikus csatornán megoldható Diffie Hellman (DH) algoritmus segítségével), akkor a DES a mai napig tartja a gyakorlati titkosságát (az aszim- metrikus és szimmetrikus kulcsokat is felhasználó SSL algoritmusa pontosan így jár el, bár ma már ott is az AES a javasolt szimmetrikus kulcs). 2. FEJEZET. IRODALOMKUTATÁS 27

2.9.2. Kulcscsere

Maradva most már csak a gyakorlati titkosságot felmutató algoritmusoknál, további csoportosítást lehet bevezetni. Az egyik csoportba olyan algoritmusok tartoznak, melyek esetén a felek között előzetes és titkos kulcscsere szükséges. Ezeket hívjuk titkos kul- csú módszereknek (private/secret/shared key cryptography, symmetric-key algorithm). A másik csoport ennek megfelelően a nyilvános kulcsú titkosítók (public-key cryptography, asymmetric key algorithm), ahol erre nincs szükség, mert vagy a titok megosztása (Diffie Hellman (DH)), vagy az algoritmus maga (Rivest Shamir Adleman (RSA)) matematika- ilag garantálja azt, hogy teljes „lehallgatás” esetén sem lehet a kommunikációt feltörni, illetve megsérteni, ezért a (nyilvános) kulcs akár a Facebook-on keresztül is megosztható.

2.9.3. Szimmetrikus titkosítás

A szimmetrikus titkosítók[52] egy titkos kulcsot használnak, mely mind az adó, mind a vevő oldalán megtalálható. A titkosítás (E = Encryption) során az üzenet (m = mes- sage) ezen kulcs (k = key) függvényében alakul át rejtjellé (c = cipher text). c = E(m, k) A dekódolás (D = Decryption) folyamata ezzel teljesen analóg (számos módszer esetén az E és D algoritmusa megegyezik). A dekódoló függvényének a rejtjel és a titkos kulcs a paramétere (k = k∗, ezért nevezik a módszert szimmetrikusnak). m = D(c, k∗)

2.9.4. Aszimmetrikus titkosítás

Az aszimmetrikus eset modellje[53] csak abban tér el ettől, hogy k nem egyezik meg k∗-al. A titkosítás a k nyilvános kulccsal történik, míg a fejtés (E−1) a titkos k∗ kulccsal. E−1(E(m, k), k∗) = m

2.9.5. Az RSA algoritmus

Az aszimmetrikus titkosítók közül a dolgozat csak Rivest, Shamir és Adleman-ról el- nevezett RSA algoritmussal foglalkozik[54]. Amennyiben Alice és Bob egymásnak üzenni akar (mA és mB üzenetet szeretnének kicserélni), és feltesszük hogy mindkettőjük rendel- kezik egy-egy kulcspárral (Alice nyilvános kulcsa legyen kA, titkos kulcsa pedig sA, Bob-é pedig ennek megfelelően kB és sB) akkor az üzenetváltásuk a következőképpen zajlik.

Alice mA üzenetét eltitkosítja Bob nyilvános kulcsával. A rejtjelet ezt követően már Alice sem tudja értelmezni, bármely lehallgatható csatornán biztonságosan elküldheti Bob számára.

cA = E(mA, kB)

Bob az egyetlen, aki a cA rejtjelet vissza tudja fejteni, saját titkos kulcsával. −1 mA = E (cA, sB) Bob a válasz üzenetét Alice nyilvános kulcsával kódolja be, melyet egyedül Alice fog tudni visszafejteni. 2. FEJEZET. IRODALOMKUTATÁS 28

cB = E(mB, kA) −1 mB = E (cB, sA) Az RSA algoritmus egyik nagy előnye, hogy a nyilvános és a titkos kulcsok meg- cserélhetőek a felhasználás helyén (természetesen a titkos kulcs a tulajdonosnál marad). Ebben az esetben hitelesítésről beszélhetünk, ugyanis ha Alice a Bob számára küldendő mA üzenetet nem Bob nyilvános kulcsával, hanem a saját titkos kulcsával írja alá (az alá- írás (signA) valójában az üzenet lenyomatának (digest, mdA) titkosítását jelenti), akkor ezen üzenetet bár bárki elolvashatja a csatornán, módosítást nem tud rajta végezni („pos- tás támadás” esete), mivel ekkor Bob az aláírás ellenőrzésekor (melyhez Alice nyilvános kulcsát használja fel) hibát fog tapasztalni (az aláírás ellenőrzése akkor is megbukik, ha az aláírást, és akkor is ha az üzenetet módosították).

signA = E(mdA, sA) −1 mdA = E (signA, kA) A dolgozat további részletekre nem tér ki, de megemlítést érdemel, hogy a titkosítás és a hitelesítés együttesen is használható, így rejtett és hiteles üzenet is előállítható. A Petri háló szimulációs alkalmazás kimeneti XML állományának hitelesítésére lesz csak szükség a dolgozat keretein belül.

2.9.6. Certificate authority

Ha két fél között kiválasztásra kerül egy megfelelő titkosítási módszer, legyen az szimmetrikus avagy aszimmetrikus, a kulcscserét meg kell oldani (titkos kulcs esetén ez általában személyesen, nyilvános kulcsok cseréje esetén akár Interneten keresztül is tör- ténhet). Ha azonban a kommunikáció nem két személy között zajlik, hanem három, akkor már rögtön hat cserét kell lebonyolítani, négy esetén 12-őt, N esetén pedig N 2 − N- et (mindenkinek el kell küldeni a nyilvános kulcsát az összes többi résztvevő számára). Ez egy orvosolandó szűk keresztmetszetet jelent. A probléma megoldását a Certificate Authority-k[55], avagy röviden CA-k bevonása jelenti. Amennyiben a CA intézménye garantálja, hogy minden résztvevő valódiságát ellen- őrzi, valamint feltesszük, hogy a CA-ban minden résztvevő feltétel nélkül megbízik, akkor a kommunikációban részvevőknek nem kell egymás nyilvános kulcsát előzetesen kicserél- niük. Minden résztvevő rendelkezik a saját titkával11, melyet generálásakor becsomagol egy úgynevezett „self-signed certificate”-be. A példa kedvéért Alice-nek legyen egy ilyen tanúsítványa (certificate). A tanúsítvány valójában a titok nyilvános kulcsát, valamint néhány olvasható (de a titkos kulccsal aláírt, így hiteles) adatot tartalmaz a tulajdonos- ról. A „self-signed” jellege miatt ez csupán annyira hiteles, amennyire az aláírója, vagyis Alice (ez a gyakorlatban hiteltelen, hiszen bárki készíthet olyan tanúsítványt, miszerint ő a Microsoft első embere, és ezt nem más, mint saját maga igazolja..). A generált „self-signed certificate”-ből egy úgynevezett Certificate Signing Request (CSR) exportálható ki, mely átadható megfelelő azonosítás (és díjfizetés) ellenében egy Certificate Authority részére. Az intézmény ezt a CSR-t (mely tartalmazza a nyilvános kulcsot) aláírja a saját, vagyis a mindenki által feltétel nélkül elfogadott, hiteles titkos kulcsával, majd visszaküldi Alice-nek, hogy kicserélje a régi „self-signed certificate”-jét erre. 11 A gyakorlatban a titok olyan kártyák belsejében generálódik, melyből a tulajdonos sem tudja a kulcsot kimásolni. A titkosítandó adat kerül a kártyán átvezetésre, és a rejtjelet, aláírást adja vissza kimenetként. 2. FEJEZET. IRODALOMKUTATÁS 29

Ezt követően vizsgáljuk meg mi történik akkor, ha Alice hiteles üzenetet szeretne küldeni egy számára ismeretlen Bob számára (és természetesen Bob sem ismeri Alice-t). Alice az üzenetének lenyomatát aláírja saját titkos kulcsával. Bob az üzenetet megkapja, de mielőtt a benne foglaltakat elhinné, meg akar bizonyosodni arról, hogy azt tényleg Alice írta-e. Ezért Alice CA-jához fordul (Alice Certificate-jének „Issuer” rekordja tartalmazza a kibocsátó/aláíró CA-t). A benne lévő nyilvános kulcs segítégével meg tud győződni arról, hogy az üzenetet tényleg Alice írta, és a csatornán sehol sem sérült meg („men in the middle”, avagy postás támadás nem érte), magából a CA által aláírt certificate-ből pedig abban lehet biztos, hogy a CA ellenőrizte Alice kilétét, így mögötte tényleg az áll, akinek mondja magát (a CA titkos kulcsa csak a CA-nál van meg, így más nem tud általa aláírt certificate-eket kiállítani). Egy CA Alice kilétét ellenben nem fogja az idők végezetéig garantálni. Ezt mint szol- gáltatás nyújtja, és általában adott időre szól (valamennyi évre általában). Az érvényességi idő kezdete és vége bekerül a certificate olvasható adatai közé (mely nem módosítható és hiteles, mivel a CA aláírja). Ha valaki kap Alice-től egy üzenetet, mely bár hitelesen Alice-től származik, a CA nem fogja kiadni a lejárt certificate-et Bob számára, hogy ezt ellenőrizni tudja, illetve ha már Bob-nak ez előzőleg megvolt, Bob is látja a tanúsítvány adatai között a lejárt dátumot. Természetesen előfordulhat, hogy egy titkos kulcsot ellopnak, vagy bizonytalanság merül fel annak kapcsán, hogy már nem csak egy személy birtokolja. Ilyenkor a lehető leggyorsabban új kulcsot kell generálni, és a régit érvényteleníteni kell. Ennek lejelentése a CA felé azt fogja eredményezni, hogy a hitelesítő intézmény a régi tanúsítványt egy „Certificate Revocation List”-re (CRL) helyezi. Azok a kliensek, melyek korábban Alice ellopott kulcsának nyilvános párját használták, valamilyen időközönként ezen CRL listát lekérik, és összevetik saját adatbázisukkal.

2.9.7. Eszközök és szabványok

Számos eszköz létezik „self-signed certificate”-ek létrehozására. A legbiztonságosabb, ha ezt egy fizikai hardware végzi el, mely védve van a generálás során mindenféle lehallga- tástól12. Hardware hiányában kulcsokat egyszerű programokkal is lehet generálni, ilyenkor arra érdemes figyelni, hogy úgynevezett „secure random” generátort használjanak. A leg- több operációs rendszer alapeszközei között megtalálhatóak az ilyen programok, de ma már a különféle programozási nyelvek SDK-i illetve API-jai (Application Programming Interface) is használhatóak erre.

Java Keytool

A dolgozat szempontjából az úgynevezett „end-entity” kulcsgenerálásra a Java 1.6 JDK keytool elnevezésű eszközt fogjuk használni[56]. Az „end-entity” jelöli, hogy ez egy olyan kulcs, mely nem alkalmas más kulcsok tanúsítványainak aláírására, vagyis CA-ként nem használható. A keytool csak „end-entity”-kkel kapcsolatos tevékenységekre alkalmas, Certificate Authority-t nem lehet vele szimulálni. A 2.1. kódrészletben bemutatott parancs előállít egy „demo.jks” elnevezésű Java Key Store állományt, mely tartalmazza a titkos és nyilvános aszimmetrikus RSA kulcsokat.

12 Bár hihetetlennek hangzik, de a kulcs generálásakor a CPU által felvett áramerősségből a kulcsra elég jó közelítést lehet adni (és ezt követően „brute-force” módszerrel támadni). 2. FEJEZET. IRODALOMKUTATÁS 30

1 keyt ool ␣−genkeypair␣−keyalg ␣RSA␣−keysize␣1024␣−sigalg ␣SHA1withRSA␣− a l i a s␣customalias␣ −keystore␣demo. jks␣−dname␣"CN=Universitas␣ Budensis,␣OU=NIK,␣O=UNI−OBUDA,␣L=Budapest,␣S=Hungary,␣C=HU,␣ [email protected] −obuda.hu"␣ −storepass␣changeit␣−keypass ␣ changeit 2.1. kód. Aszimmetrikus kulcsgenerálás Java 1.6 keytool-lal

A kulcs generálásakor meg kell adni a választott algoritmust (aszimmetrikus kulcs esetén ez RSA vagy DSA lehet13), a kulcsméretet (pl. 1024 bit14), az aláírás lenyomatának elkészítéséhez szükséges algoritmust (ez manapság legtöbbször SHA-1 szokott lenni15) valamint az úgynevezett Distinguished Name-et (DN, egyedi megnevezés). A DN több rekordból áll össze, ezek a következőek:

• Common Name, CN: A természetes személy neve, avagy az intézmény megneve- zése. • Organizational Unit, OU: Szervezeti egység megnevezése. • Organization, O: Szervezet, leányvállalat megnevezése. • Locality, L: Helység megnevezése. • State or Province, S: Ország vagy megye megnevezése. • Country, C: Az ország két betűs nemzetközi rövidítése. • Email address, EmailAddress: A tulajdonos elérhetősége.

A kulcs generálásakor megadott adatok mind nyilvánosak lesznek, és a tanúsítvány rekordjai közé kerülnek. A Java keytool a kulcsot egy úgynevezett JKS formátumban tárolja (Java Key Store). A JKS nem csak egy kulcs, hanem tetszőleges számú kulcs tárolására alkalmas. A titkos kulcsokat önmagukban, a nyilvánosakat tanúsítványukba csomagolva tartalmazza. A titkos kulcs rekordja mellett mindig megtalálható a certificate- je (sőt annak teljes „certificate path”-a is16), utóbbiak azonban létezhetnek titkos kulcs nélkül is. Ez esetben a nyilvános kulcsok halmazát „trusted list”-nek nevezzhetjük, ugyanis ezek azok a címzettek, akiknek a titkosított adatát visszafejthetjük, illetve hitelességüket ellenőrizni tudjuk. A JKS kontextusában két különböző jelszóról beszélhetünk:

13 A Digital Signature Algorithm (DSA) és az RSA között algoritmikusan kicsi a különbség, inkább jogi okai vannak a DSA létezésének. Ma már az RSA jogdíjai is lejártak, és elterjedtebb is, mint a DSA, így a dolgozat is csak RSA kulcsokkal foglalkozik. 14 Ahhoz, hogy a Java megbízható védelmet nyújtó kulcsméretet tudjon használni, a JDK-hoz külön le kell tölteni a „Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6” kiegészítést a http://www.oracle.com oldaláról. Ez az egyetlen olyan csomag, mely a teljes JDK-nak része, de külön kell telepíteni. Ennek oka elsősorban politkai. Vannak országok, ahol nem lehet 128 bites titkosításnál erősebbet használni, ugyanis ekkor az állam szuperszámítógépei a kódolt üzeneteket nem tudják visszafejteni. Hogy ennek a mai globalizált világban van-e bármi jelentősége, ez a dolgozat nem foglalkozik. A használt kulcsmérethez viszont a csomag telepítése szükséges. 15 Az SHA-1 a „Secure Hash Algorithm” rövidítése, és főleg az 128 bites MD5-ben talált hibák fel- derítése után terjedt el. 160 bites hash-t állít elő, javított változatai az SHA-2 családba tartozó SHA-256/224 illetve SHA-512/384[57]. A hash algoritmusok részleteivel jelen dolgozat nem foglal- kozik. 16 Jelen dolgozat nem tér ki a tanúsítványok és a keytool használatának minden részletére, így néhol a leírásban egyszerűsítés jelenik meg. A megemlített „certificate path”-ok helyes kezelésére jelen forgatókönyv szerint is szükség lesz, de ez nem kerül bemutatásra. 2. FEJEZET. IRODALOMKUTATÁS 31

• Store password: magát a JKS elemeit védi (így a „trusted list”-hez való hozzáfé- réshez is szükséges). • Key password: a JKS-en belül tárolt titkos kulcsot védi.

Minden egyes elemet, legyen az titkos kulcs, avagy certificate, egy úgynevezett „alias”- on keresztül tudunk megcímezni. Az alias teljesen szabadon választható, átnevezhető, nem része a tanúsítványnak. A kulcspár (titkos és nyilvános) elkészítését követően a nyilvános kulcsot tartalma- zó tanúsítvány a saját titkos kulcsával van aláírva, így ennek megbízhatósága alacsony. Annak érdekében, hogy a megbízhatóságot növeljük, egy Certificate Signing Request[61] (CSR) állományt kell generálnunk, melyet majd el kell juttatni egy Certificate Authority számára. Mivel ez is egy „end-entity” funkcionalitás, a Java keytool ennek előállítására is alkalmas. A 2.2. kódrészlet prezentálja a „demo.csr” állomány előállítását a korábban létrehozott „demo.jks” állományból. A megfelelő kulcs megcímzéséhez a jelszavak és az alias („customalias”) megadása szükséges.

1 keyt ool ␣−c e r t r e q ␣−a l i a s␣customalias␣ −keystore␣demo. jks␣− file␣demo. csr ␣−storepass␣changeit␣−keypass␣changeit 2.2. kód. Certificate Signing Request generálása

Portecle

A JKS állományok kezelését a Java API szinten támogatja. A nyilvános titkosító algoritmusok17 implementációja úgynevezett „provider”-eken keresztül érhető el. Ilyen szolgáltatója van a Sun/Oracle-nek is, azonban egy külső csapat által készített Bouncy Castle[59] használata javasolt. Mielőtt az API alapvető funkcióinak (JKS-ek megnyitása, böngészése, tanúsítványok hozzáadása, törlése, tárolási szabványok konverziója) imple- mentálását elkezdjük, érdemes körülnézni az Interneten. Egy aprócska kis segédprogram, a Portecle 1.7 egy ilyen alapfunkciókkal rendelkező Bouncy Castle providert használó grafikus alkalmazás[58]. Bár az eszköz a Java keytool minden funkcióját „kiváltja” (ugyanazon parancsokat hívja a keytool is, mindegyik mögött a Java API-ja működik), a dolgozat csupán a JKS csomagok PKCS12-re való konverziójára fogja használni. Ennek oka a keytool scriptel- hetősége, mely hosszú távon kényelmesebb (a teljesség kedvéért megjegyzendő, hogy a PKCS12 konverzió is scriptelhető). A PKCS12, vagyis Public-Key Cryptography Standards 12 egy csomagolási szabvány titkos kulcsok és certificate-ek tárolására[60]. Mivel a kulcsgenerálás során Java Key Store formátumban állnak elő az „end-entity” kulcsai, ezt Microsoft C# alkalmazásban körül- ményes volna feldolgozni. A PKCS12-re való konverziót követően azonban olyan PFX állomány18 jön létre, melyet standard .net könyvtárak is tudnak értelmezni. A PKCS12 formátumban a titkos kulcsokat nem védi egy különálló jelszó, így a konverzió során csak a JKS „store password”-je marad meg.

17 A titkosító algoritmusok forrásai egy-két apró kivételtől eltekintve (DES, AES) nyilvánosak. Széles körű használat esetén mindig biztonságosabb egy matematikai háttérrel rendelkező, nyílt forrású algoritmust használni, mint egy algoritmikus titkot őrizni, és félni az ipari kémkedéstől. 18 A *.pfx kiterjesztésnek történelmi okai vannak, helyette szokás *.p12-őt használni. 2. FEJEZET. IRODALOMKUTATÁS 32

2.26. ábra. Portecle 1.7

Open SSL

Az aszimmetrikus titkosításhoz használt kulcspárok előállítását követően szükségünk lehet arra, hogy a nyilvános kulcsot tartalmazó tanúsítványt aláírassuk egy Certificate Authority-val, hogy így olyan személyek is meg tudjanak bízni a titkos kulcsunkkal védett, avagy hitelesített adatban, akik minket nem ismernek, de a választott CA-ban megbíznak. Ezen hitelesítésnek díja van, ezért jelen dolgozat létrehoz egy Certificate Authority szimulációt, mely a fontosabb üzemeltetési feladatokat ellátja. E célra az OpenSSL elne- vezésű multiplatform alkalmazás teljesen megfelel[62]. Az OpenSSL segítségével elő tudunk állítani olyan tanúsítványt, mely alkalmas más tanúsítványok aláírására, vagyis CA-ként tud viselkedni. Jelen dolgozat témáján túlmutat ezen OpenSSL-es kulcsgenerálásnak és certificate létrehozásnak a részletei, ezért ezek csak a dolgozat mellékleteként kapnak helyet. Legyen adott egy OpenSSL-lel generált kulcspár titkos része „ca.key” néven, PKCS8 szabány szerint tárolva („cakeypassword” jelszóval szimmetrikus módon védve), PEM formátumban19, továbbá ezen kulcs nyilvános része (tanúsítványa) szintén PEM formátumban „ca_certificate.pem” néven elérhető. Ekkor az „end-entity” certificate-jét tartalmazó „demo.csr” Certificate Signing Request állományból egy új, CA által aláírt „demo.pem” formátumot készít a 2.3. kódrészletben olvasható parancs (az érvényességi ideje 720 nap lesz).

1 openssl␣ca␣−policy␣custompolicy␣−config␣customopenssl.conf␣−c e r t ␣ ca_certificate .pem␣−in␣demo. csr␣−keyfile␣ca.key␣−days ␣720␣−md␣ sha384 ␣−passin␣pass:cakeypassword␣−out␣demo.pem 2.3. kód. Certificate aláírása OpenSSL-lel

Az elkészült „demo.pem” tanúsítvány kibocsátó rekordjában (Issuer) immáron a CA „distinguished” neve lesz olvasható bárki számára, és ezáltal már nem „self-signed certifi- cate” többé. Utolsó lépésben az „end-entity” oldalán a régi „self-signed” tanúsítványt ki kell cserélni az újjal. Erre a Java keytool importcert parancsát használhatjuk (lásd. 2.4. kód).

19 Az OpenSSL alapértelmezetten a PEM (Privacy Enhanced Mail) formátumot használja kulcsok és tanúsítványok tárolására. A PEM egy szöveges fejléccel ellátott Base64 kódoláson átesett DER formátumú adat. Az ASN1 DER (Distinguished Encoding Rules) egy bináris formátum, a legtöbb böngésző ezt használja. A PEM használata azonban sokkal kényelmesebb, mert a tárolt tanúsít- ványokat akár egy XML-ben is utaztathatjuk a hálózaton. 2. FEJEZET. IRODALOMKUTATÁS 33

1 keyt ool ␣−importcert␣−a l i a s␣customalias␣ − file ␣demo.pem␣−keystore␣demo. j k s ␣−storepass␣changeit␣−keypass␣changeit 2.4. kód. CA által aláírt tanúsítvány JKS-be importálása keytool-lal

2.10. Irodalomkutatás tanulsága

Az irodalomkutatás során nagyító alá kerültek a Petri hálózatok topológiai és ma- tematikai leírásai, a különféle kiterjesztései és az ezekhez elérhető szerkesztő alkalmazá- sok. A dolgozat célja a Petri hálózatok egy újabb kiterjesztését elkészíteni, mely egyrészt már meglévő kiterjesztéseket átemel, másrészt viszont új elemeket, úgynevezett petri ese- ményeket visz be a modellbe annak érdekében, hogy a tokenjátékot át lehessen emelni objektum-orientált környezetbe. Objektum-orientált környezetben az állapotok közti lehetséges átmeneteket (állapot alatt itt most egy objektumpéldány aktuális szerializálható adatait értve) legtöbb eset- ben jól definiált, zárt halmaznak tekintjük. Törekedni szükséges az egyszerűségre és az átláthatóságra. Pontosan azért, mert a sok állapot és bonyolult állapot-átmenetek kezel- hetetlenek lesznek az implementálás során. Ha a Petri hálózatok tokenjátéka bekerülne az imperatív objektum-orientált nyelvek eszközkészletébe (mely célkitűzés jelen dolgozat egyik feladata), akkor pontosan ezt a nem-determinisztikus állapotváltozást lehetne úgy kezelni, hogy mindez ne sértse az objektumok jól definiált határait, állapotait. Természetesen mindenféle kiterjesztést nem lehet figyelembe venni, egyrészt mert ezek céljai között lehetnek kizárások (össze nem egyeztethető célra hozták őket létre), másrészt mert a dolgozat határaiba sem férhet bele minden. A következő kiterjesztések azonban megvalósításra kerülnek a Petri hálózatok új modelljében:

• reset él bevezetése • kapacitás korlát bevezetése • tiltó él bevezetése • priorizált Petri hálók megvalósítása • időzített Petri hálók megvalósítása

A fentieken kívül a modellben helyet fognak kapni azok a hozzáadott tulajdonságok, melyek a szerkesztést és megjelenítést részletes módon specifikálni tudják, illetve lehető- ség lesz a tokenjáték több pontján is eseményeket definiálni (melyek eseménykezelői az oop szabályai szerint elkészíthetőek lesznek) annak érdekében hogy egy valós objektum- orientált környezetbe való beágyazás lehetővé váljon. A Színezett Petri hálók nem kerülnek megvalósításra első körben, mert a kitűzött célt túlbonyolítanák, azonban mivel a CPN-ek visszafelé kompatibilisek az általános Petri há- lókkal, ennek lehetősége a jövőben nyitott maradhat. Egy apróság azonban a CPN-ekhez hasonlóan (bár nem azonos módon) implementálásra kerül, mégpedig a tokenjátékosok egymástól való megkülönböztetése. Minden tokenjátékos felruházható lesz valamely in- formáció hordozására, és amennyiben egy tranzíció tüzelése során ez a játékos egy másik pozícióra kerülhet, akkor a hordozott információ áramlása is megfigyelhető lesz (vannak azonban olyan helyzetek, mikor a tokenszám változik az általános Petri hálózatban, és így új tokenek jelenhetnek meg, illetve létezőek tünhetnek el). 2. FEJEZET. IRODALOMKUTATÁS 34

A Petri Net Markup Language (lásd. a 2.5. fejezet) támogatása, vagyis az elkészült Petri hálózatok exportálási lehetősége egy rendkívül elegáns megoldás volna, így minden- képpen érdemes megvizsgálni. A terveztett új kiterjesztés számára saját PNTD-t (Petri Net Type Definition) is kellene készíteni, ezért figyelembe kell venni, hogy jelent-e ez korlátozást, avagy sem. A részletesen megvizsgált Petri háló szerkesztő alkalmazások (lásd. a 2.7. fejezet) tanulságai szerint a grafikai szerkesztő felhasználóbarát elkészítése hiánypótló volna (el- sősorban az ingyenes termékek között), illetve van pár olyan terület, melynél pár apró ötlettel is lehetne sikereket elérni (tokenek vizuális megjelenése legalább öt tokenig, él sú- lyának megfelelő vastagságú vonal rajzolása, tranzíciók és pozíciók méretezési szabadsága, tranzíciók teljes tartományú forgatási lehetősége). Olyan apróságokra is érdemes gondol- ni, mint az elemek árnyékolása avagy az anti-aliasing vonalak rajzolása. Szinte sehol sem lehetett találkozni olyan beállításokkal, melyek során a grafikai felület elemeit globálisan lehetett volna vezérelni (pl. feliratok, annotációk ki- és bekapcsolása). Szinte mindegyik eszközben voltak annotációk (megjegyzések), azonban ezek nem voltak köthetőek elemek- hez, csupán az ábra egy részén megjelenni tudtak. Az UML annotációihoz hasonlatosan érdemes volna lehetőséget adni arra, hogy a megjegyzéseket tranzíciókhoz, pozíciókhoz illetve élekhez köthesse a felhasználó. Az élek megrajzolása és a szerkesztési szabadságfokának kérdése kulcsfontosságú a vizuális megjelenés szempontjából, ezért is lett több alkalmazás kapcsán részletesen meg- vizsgálva. A Platform Independent Petri net Editor (lásd. a 2.7.6. fejezet) megoldásának implementálása elégséges volna. A HPSim alkalmazásban (lásd. a 2.7.5. fejezet) látható, de a Microsoft Visual Studio- ból is jól ismert „property editor” szintén egy felhasználóbarát és gyors megoldás a háló elemeinek szerkesztésére, így ennek megvalósítása is a kitűzött célok között van. Ugyan- ezen HPSim alkalmazásban volt látható egyedül a tokenjáték szimulációja során a tokenek vizuális mozgása az élek mentén. Ez a funkció prezentációs célra is alkalmas, bár nyilván- valóan erőforrás pazarló, így csak kikapcsolási lehetőséggel együtt érdemes implementálni. Utoljára a Renew elnevezésű alkalmazás (lásd. a 2.7.8. fejezet) visszatekintése ma- radt, mert talán ez az az alkalmazás, mely a dolgozat céljaihoz hasonló indítatásból szüle- tett. A Renew-ban megszerkesztett Reference hálókat Java alkalmazásba lehet beágyazni, és azokat pl. üzleti célra felhasználni. Bár ez hasonlóságot mutat a dolgozat céljával, való- jában másról van szó. A Reference hálók, hasonlóan a Színezett Petri hálókhoz egy algorit- must képesek modellezni (magas szintű programozási nyelvek), előbbiek annyival előbbre mennek ebben, hogy ezt az algoritmust Java környezetbe további implementálás nélkül fel is tudják használni. A dolgozat célja nem ez. Elsősorban „csupán” az alacsony szintű nyel- veknek megfelelő eredeti Petri hálók modellezését tűzi ki célul (számos fentebb említett kiterjesztéssel), melyben nem kap szerepet konkrét algoritmus, mely implementálása vol- na a modell szimulációjának a feladata. A modell tokenjátéka a szerkesztő alkalmazásban teljesen függetlenül valós üzleti problémáktól lejátszható, elemezhető, analízisre felhasz- nálható. Azonban ha megnyitjuk egy megfelelő C# és/vagy Java nyelven e célra készült frameworkben, akkor eseményeihez eseménykezelőket, tokenjeihez pedig objektum példá- nyokat rendelhetünk. A szimuláció itt is ugyanúgy lejátszható (tipikusan háttér szálban), de interakció itt már csupán az eseménykezelőkben valósul meg, melynek nincs „köze” a modellhez. A Renew-val hasonlatosan a dolgozat által implementált framework is egy konkrét osztály példányaként tekint a Petri hálókra, azonban ezen példányt a modell nem specializálja oly részleteiben, mert nem feladata egy algoritmus megoldása a szimuláció futása során, csupán képes „kiszólni” a környezetének állapotváltozásairól. 2. FEJEZET. IRODALOMKUTATÁS 35

Az irodalomkutatásban megvizsgálásra kerültek az aszimmetrikus titkosítás szabvá- nyos eszközei annak érdekében, hogy a Petri szerkesztő alkalmazás kimeneti XML állomá- nyát digitális aláírással lehessen ellátni. Erre azért lehet szükség, mivel az XML állományt bárki a szerkesztőtől függetlenül módosíthatja, és így pl. Internetre olyan állományok is kikerülhetnek, melyeket a szimulátorba betöltve nem lehet működésre bírni, vagy hibás szimulációt mutatnak be (vagy akár meg se jelennek, a program hiba ágra fut). A hibás szimuláció a legveszélyesebb oktatási szempontból, hiszen ha valaki nem ismeri az elvárt eredményt, nem biztos hogy feltűnik a nem várt viselkedés. A szimulátor indulását követően a felhasználótól egy PKCS12 formátumban letárolt RSA titkos kulcsot fog bekérni. A kulcsot védő szimmetrikus jelszó megadását követően a program ellenőrizni fogja a kulcs tanúsítványának néhány adatát (kibocsátóját, verzió- számát20 és a kulcs „alias” nevét). A fentieknek megfelelő kulcsot a gyakorlatban bárki elő tud állítani (mivel fizetett Certificate Authority nem lesz mögötte, bár az alkalmazott technológia ezt a jövőt tekintve nem zárja ki), de lehetőség lesz kulcs igénylésére is (ez egyfajta license-nek is felfogható). A Petri hálózatokat csak és kizárólag az a felhasználó tudja elmenteni, aki előzőleg autentikálta magát egy megfelelő RSA kulccsal. A mentés során a hálózat XML állománya digitális aláírással védett lesz, és az aláíró „distinguis- hed” nevét is tartalmazni fogja. Ez egy járulékos előnye az alkalmazott módszernek. Egy hálózat működésének megbízhatósága nyilvánvalóan függ attól, hogy egy ismert szakértő, avagy egy hallgató készítette. Természetesen a szimulátort nem csak az tudja majd használni, aki rendelkezik titkos RSA kulccsal (mivel bárki rendelkezhet ilyennel, ez nem lehetőségbeli, hanem igénybeli korlát). Az autentikációs lépés kihagyását követően is el fog indulni az alkalmazás, sőt lehetőség lesz a program teljes fukcionalitását használni (új hálózat létrehozása, meglévő átszerkesztése és a szimuláció módosított lejátszása, stb.). Egyetlen dolgot nem lehet majd véghezvinni: menteni az elkészült illetve módosított hálózatot. A digitális aláírás nyilvánvalóan csak akkor ér valamit, ha annak valódisága, sértet- lensége ellenőrzésre kerül, ezért a megnyitási folyamatban erre fel kell készülni. Amennyi- ben egy megnyitandó hálózat digitális aláírása nem megfelelő (verifikációs lépés), avagy hiányzik, nem fog betöltésre kerülni. Az aláíró nyilvános kulcsának az XML-hez csatolása nem tervezett funkció21, ezért az ellenőrzéshez szükség lesz az aláíró tanúsítványára. A tanúsítványokat szintén PKCS12 formátumban egy meghatározott könyvtárba kell majd másolni, ahonnan a program indulását követően automatikusan felolvassa. Csak olyan hálózatok megnyitása lesz lehetséges, melyek tanúsítványa a „truststore”-ban megtalál- ható, és integritásuk sem sérült (a „truststore” tanúsítványainak nem lesz jelszóvédelme (a PKCS12 formátum ezt lehetővé teszi), de elemei teljesen hasonló ellenőrzésen átesnek majd, mint a belépéshez használt titkos kulcsok). Megjegyzendő, hogy az állomány mentése nem lesz korlátozva a létrehozójára, ennek nem volna sok értelme (az XML adatait megnyitva bárki lemásolhatja). Aki rendelkezik titkos kulccsal, és ezt belépés során megadja, valamint rendelkezik egy másik személy által készített hálózattal, és annak tanúsítványával, akkor a megnyitást és esetleges szerkesztést követően a hálózatra rámenthet. Ekkor természetesen a saját titkos kulcsa segítségével új digitális aláírás keletkezik, és az aláíró adatai is megváltoznak.

20 X.509.V3 certificate-ek támogatása a cél a megfelelő szintű biztonság elérése érdekében. 21 A SOAP WebService-ek esetén elterjed módszer az aláíró tanúsítvány SOAP-Header-be csomago- lása. Ez egy úgynevezett „Binary Security Token”-ként kerül az üzenetbe, Base64 kódolással. A fogadó oldal így még komolyabb autentikációs lépés nélkül meg tud győződni arról, hogy az üze- net nem sérült-e. Csak azt követően foglalkozik azzal, hogy a csatolt tanúsítványban, vagy annak kibocsátójában megbízik-e, ha az üzenet integritása sértetlen. 2. FEJEZET. IRODALOMKUTATÁS 36

Mind az autentikációs, mind a verifikációs lépés során a tanúsítványok lejárati (és kibocsátási) ideje ellenőrizve lesz. Ha a tanúsítvány már lejárt, nem lesz engedélyezett menteni/megnyitni. Ez a funkció használatható lesz pl. egy szemeszterre érvényes certi- ficate kiadására, így egy hallgató az oktató által már régebben készített (és azóta már többször átdolgozott) hálózatot nem fogja tudni megnyitni (csupán az aktuálisan kiadot- tat). 3. fejezet

Rendszerterv

3.1. Modellezés

A Petri hálózat szimulátor és szerkesztő alkalmazás tervezése UML (Unified Mo- deling Language) segítségével kerül bemutatásra. A dolgozat nem tér ki az UML tervezés lépéseire és nem foglalkozik az egyes UML diagramok hasznosságával sem. Elsősorban nem a teljességre törekvés vezette a modellezést, így van ahol csak kiemelt diagramok kerülnek bemutatásra, és az egyértelmű, avagy a dolgozatot érdemben nem befolyásoló ábrák kimaradnak.

3.2. Kiegészítő specifikációk

A Kiegészítő specifikációk (Supplementary specifications) célja összegyűjteni a mo- dellezésre illetve fejlesztésre globálisan érvényes szabályokat, a nem funkcionális követel- ményeket illetve a kifejezéseket. Itt kerülnek megemlítésre a projekt kockázatai, illetve a teljesítendő feladat korlátai, határai.

3.2.1. Nem funkcionális követelmények

A Nem funkcionális követelmények (Non-Functional Requirements) listája alább ol- vasható. A dolgozat később ezek sorszámára fog hivatkozni.

• NFR1 A rendszernek egy felhasználó egyidejű beléptetését kell tudnia kezelni. • NFR2 A szimulációs alkalmazás összetettebb műveletei, mint pl. a megnyitási, mentési, beléptetési folyamat nem tarthat tovább egy középkategóriás személyi szá- mítógépen egy másodpercnél. • NFR3 A hálózatok szimulációjának késleltetés nélküli lejátszási sebessége (két ál- lapot közti átmenet) nem lehet 100 ezredmásodpercnél több egy 50 tranzíciót tar- talmazó hálózat esetében. • NFR4 A belépéshez szükséges titkos kulcsoknak, illetve a TrustStore-ok tanúsít- ványainak a Public-Key Cryptography Standards 12 (PKCS12) szabvány által leírt állományba kell hogy csomagolva legyenek.

37 3. FEJEZET. RENDSZERTERV 38

• NFR5 A titkos és nyilvános kulcsnak RSA eljárással kell készülnie, a DSA (Digital Signature Algorithm) kulcsok nem támogatottak. • NFR6 A szimulációs alkalmazásnak MDI (Multiple Document Interface) környe- zetben kell elkészülnie. Legalább öt hálózat egyidejű szerkesztése és egyidejű futó szimulációja gördülékenyen kell hogy működjön. • NFR7 A szimulációs alkalmazás tartalmazzon szabványos nyelvi lokalizációs meg- oldásokat, de nem cél az alkalmazás minden feliratához ezt összerendelni. Minimális cél az ablakok fejlécei. Az alkalmazáson belül legyen lehetőség a nyelv váltására. • NFR8 Az alkalmazás fő ablakának mérete és elhelyezkedése, illetve az egyes modu- lok elhelyezkedése az operációs rendszer felhasználójához legyen rendelve (felhasz- náló szintű tulajdonságok legyenek). • NFR9 Az alkalmazás a korábban megnyitott illetve sikeresen mentett új hálózatok gyors megnyitását tegye lehetővé. • NFR10 A hálózatok file formátuma szabványos, XSD-vel és részletes névterekkel rendelkező XML 1.0 dokumentum legyen. • NFR11 A hálózatok XML-jének schema állománya (XSD) Microsoft XSD tool eszközzel XML-ből generálható legyen. • NFR12 A tanúsítványoknak X.509 v3 tanúsítványoknak kell lenniük. • NFR13 A hálózat szerkesztése közben az egér kurzorja a kijelölt rajzoló eszközzel szinkron képet mutasson, bár ez a grafikai hatás kikapcsolható legyen.

3.2.2. Kockázatok

A projekt kockázatai (Project Risks) alább kerülnek felsorolásra.

• A tervezett alkalmazás kimeneti XML állománya valószínűsíthetően nem lesz kom- patibilis a PNML formátummal, így más e formátumot támogató Petri háló szer- kesztő alkalmazásokban nem lesz megnyitható. • A Petri hálózatok integritás védelme ellenszenvet válthat ki azon felhasználói kö- rök esetén, akik az egyébként ingyenesre tervezett regisztrációt nem szándékoznak végrehajtani. • A projekt számára nehéz lesz olyan domain nevet lefoglalni, mely egyértelműen utal a használatára, és széles körben elterjeszthető. Amennyiben a szimulátornak fantázia név lesz kitalálva, azt nehéz lesz megismertetni a felhasználók táborával.

3.2.3. Üzleti szabályok

• BR1 Az X.509 tanúsítványoknak érvényesnek kell lenniük a használat idejében (a rendszer idő a kulcs létrehozása és lejárati ideje között kell hogy legyen). • BR2 A titkos kulcs kibácsátója a következő kell hogy legyen: „[email protected], CN=Petri Universitas Budensis Sub CA, OU=NIK, O=UNI-OBUDA, S=Hungary, C=HU”. • BR3 A titkos kulcs alias-a „petri” kell hogy legyen. • BR4 A TrustStore könyvtára a telepítése könyvtáron belüli „truststore” könyvtár. 3. FEJEZET. RENDSZERTERV 39

• BR5 A TrustStore-ok megnyitásához szükséges tárolási jelszó (store password) üres karakterlánc kell hogy legyen. • BR6 A titkos kulcsot tároló PKCS12 tárolónak rendelkeznie kell megnyitási jelszó- val, melyet a felhasználó minden egyes alkalommal meg kell hogy adjon (a jelszó nem menthető el még kényelmi okokból sem). • BR7 Nem szabad engedni olyan hálózat megnyitását, melyen nincsen integritás védelem (digitális aláírás). • BR8 Nem szabad engedni megnyitni olyan hálózatot, melyhez kötődő tanúsítvány nincs az alkalmazás TrustStore-jában. • BR9 Az alkalmazás szabad szavas beviteli mezővel csak olyan helyen rendelkezhet, ahol a bevitt érték nem kerül validálásra. Az összes többi adat típushelyes bekérése és ellenőrzése szükséges. • BR10 Nem lehet egy digitális aláírásnál több egy petri hálózaton (pontosan egy digitális aláírás kell hogy biztosítsa az integritás védelmet). • BR11 A szimuláció során statisztikai adatok készüljenek minden egyes pozíció, tranzíció és állapot vektor kapcsán.

3.2.4. Kifejezések

A Kifejezések listája (Glossary of Terms) alább olvasható.

• Alias A nyilvános kulcsú titkosításhoz haszált kulcsokat és tanúsítványokat táro- lókban tárol(hat)juk. A tárolóban az alias határozza meg a tárolás helyét (egyedi szöveges azonosító). • Aszimmetrikus titkosítás Nyílvános kulcsú titkosítás, mely lehetővé teszi egy- részt a kommunikációban résztvevő felek matematikailag védett eljárással biztosí- tott titkosságát, illetve hitelességét (digitális aláírás). • Állapot átmenet diagram A Petri hálók kapcsán értelmezett állapotok közti kapcsolatokat leíró irányított gráf. • Állapot vektor A Petri háló kapcsán értelmezett adott pozícióra jellemző token eloszlás vektor. • CA Certificate Authority rövidítése. Olyan valós vagy szimulált intézmény, mely rendelkezik olyan self-signed Root certificate-tel, mely alkalmas más tanúsítványok aláírására (kibocsátására). • CER Windows operációs rendszer által kedvelt kiterjesztés, valójában legtöbbször DER állomány. • DER Distinguished Encoding Rules rövidítése, bináris formátum, melyben sokszor a tanúsítványokat is tárolják. • DSA Digital Signature Algorithm rövidítése, FIPS szabánya, 1991-ben publikálták, lényegét tekintve hasonló az RSA algoritmushoz. • FIPS Federal Information Processing Standard rövidítése, az Amerikai Egyesült Államok kormányának számítástechnikai szabványai. 3. FEJEZET. RENDSZERTERV 40

• JKS Java Key Store rövidítése. A Java nyelv szabványa szimmetrikus és aszimmet- rikus kulcsok és utóbbiak tanúsítványainak tárolására. Megnyitásához egy tárolási jelszó (store password) megadása szükséges, azonban a titkos kulcsok megnyitása egy újabb jelszóhoz kötött (key password). • KeyStore A titkos kulcs és a hozzá tartozó tanúsítványok tárolója. Erre nézve birtokjoggal csak a tulajdonos felhasználó rendelkezhet. • MDI alkalmazás Multiple Document Interface rövidítése, vagyis olyan alkalmazás, mely több dokumentum párhuzamos megnyitását és szerkesztését támogatja, egy közös kezelőfelülettel (A keretet MDI framenek vagy MDI parentnek, míg a gyermekablakokat MDI childnak/MDI childrennek hívjuk). • P12 PKCS12 tároló állomány kiterjesztése. • PEM Privacy Enhanced Mail rövidítése, Base64 enkódolású DER formátumú ta- núsítványok állományának kiterjesztése. • Petri háló Matematikai modellező nyelv, elsősorban eloszott, párhuzamos rendsze- rek nem-determinisztikus működésének szimulálására használják. • PFX Personal Information Exchange rövidítése, a PKCS12 elődje, manapság gyak- ran a P12 formátumhoz hasonlóan PKCS12 formátumú tároló kiterjesztése. • PKCS12 Public-Key Cryptography Standards 12 rövidítése, az RSA Laboratories cég szabványa elsősorban X.509 kulcsok és tanúsítványok tárolására. Megnyitásához egy tárolási jelszó (store password) megadása szükséges. • PKI Public Key Infrastructure rövidítése. A kriptográfia nyilvános kulcsú titkosí- tásához kötődő hardware, software, szabvány, szabály és eljárás gyűjtemény. • RSA Az 1976-ban Ron Rivest, Adi Shamir és Len Adleman által publikált nyilvános kulcsú titkosítás algoritmusa. • Szomszédossági mátrix A Petri hálók kapcsán értelmezett |P|*|T| elemű mátrix, melyet a Petri háló gráfjából lehet képezni (|P| a pozíciók, |T| a tranzíciók száma). • TrustStore Azon tanúsítványok halmazául szolgáló X.509 tároló, melyekben a rendszer felhasználói megbíznak. • X.509 Certificate International Telecommunication Union Telecommunication Stan- dardization Sector (ITU-T) szabványa, mely meghatározza, hogy egy nyilvános kulcs tanúsítványának milyen formátumúnak kell lennie, milyen adatokat, és azokat mi- ként kell tárolnia. Elsősorban bizonyos azonosításra szolgáló rekordok és a nyilvános kulcsú titkosításhoz használt nyilvános kulcsot tartalmazza, a kibocsátó (CA) által aláírva. • XML Extensible Markup Language rövidítése, kiterjeszthető leíró nyelv. Unicode kódolású szöveges állomány, melyet ember és gép is egyértelműen fel tud dolgozni. • XSD XML Schema Definition rövidítése. Az XML dokumentum elemeinek rész- letgazdag leírása, elsősorban típusok és sorrendiség segítségével. Az XSD állomány XML formátumú.

3.3. Használati esetek, űrlapok és forgatókönyvek

Ebben a fejezetben bemutatásra kerül a szimulátor és szerkesztő alkalmazás elsődle- ges, illetve az összes tervezett modul használati eset diagramja (Use case diagram), vala- 3. FEJEZET. RENDSZERTERV 41 mint ezek űrlapjai (Use case form). Ahol indokolt, ott sikeres (Primary Happy scenario) és sikertelen forgatókönyvek (Secondary Sad scenario) is leírásra kerülnek.

3.3.1. Actorok

Mivel a Petri háló szimulációs alkalmazás egy egyfelhasználós asztali (desktop) al- kalmazás, az actorok halmaza nem komplikált.

• Alkalmazás (Application) • Általános felhasználó (General User)

· Felhasználó (User) · Azonosított felhasználó (Identified User)

Az Alkalmazás hajt végre minden olyan háttér illetve automata tevékenységet, mely a program hatékony és gördülékeny működéséhez feltétlenül szükséges. Az Általá- nos felhasználók képesek arra, hogy a program által megvalósított folyamatok indítását kezdeményezzék. Ezen a ponton két szerepkör van definiálva. Bejelenetkezés nélkül csak korlátozott lehetősége van a Felhasználóknak, míg bejelentkezést követően az összes funkció elérhetővé válik az Azonosított felhasználók számára.

3.3.2. Elsődleges használati eset

A Petri háló szimulációs alkalmazás elsődleges feladata létrehozni egy az előzetes specifikációnak (lásd. a 2.10. fejezet) szintaktikailag és szemantikailag is megfelelő Petri hálózatot. Szintaktikailag helyes hálózatnak tekinthető az az XML adatszerkezet, mely defininálni képes a hálózat és kiterjesztéseinek adatait, valamint a topológiát egyértelműen meghatározza. A tárolandó adatokat a következő felsorolás tartalmazza:

• hálózat tulajdonságai • hálózat eseményei • hálózat vizuális beállításai • pozíciók tulajdonságai, tokenjátékosai és eseményei • tranzíciók tulajdonságai és eseményei • hálózat topológia (Petri háló éleinek halmaza) és ehhez csatolt tulajdonságok • csatolt annotációk és kapcsolódó tulajdonságok • modul specifikus adatok • integritás védelem adatai

Az adatszerkezetnek meg kell felelnie az általános Petri hálózatok szabályainak1 (lásd. a 2.4. fejezet), valamint az élek, pozíciók és tranzíciók tulajdonságai között szerepelnie kell a következőkben definiált kiterjesztésekhez kapcsolódó adatoknak:

1 Ilyen szabálynak tekintendő pl. hogy az irányított és súlyozott élek halmazára (w ∈ W) teljesülnie kell a következő összefüggésnek: W :(P × T ) ∪ (T × P) → N+, ahol p ∈ P a pozíciók, t ∈ T pedig a tranzíciók halmaza. 3. FEJEZET. RENDSZERTERV 42

• reset él (élekhez kapcsolódó adat) • kapacitás korlát (pozíciókhoz kapcsolódó adat) • tiltó él (élekhez kapcsolódó adat) • priorizált Petri hálók (tranzíciókhoz kapcsolódó adat) • időzített Petri hálók (tranzíciókhoz kapcsolódó adat)

Szemantikai szempontból akkor tekintünk helyesnek egy hálózatot, ha szimulálá- sa során az őt felépítő elemek a rendeltetési céljuknak megfelelően tudnak viselkedni. Ennek érdekében a szimulációs alkalmazás elsődleges feladata ezen viselkedés ellenőrzé- se (szimuláció), és olyan inkonzisztens szerkesztési állapotok mellőzése, melyek a Petri hálók nem-determinisztikus viselkedési kontextusában is lehetetlen/elérhetetlen állapotot tükröznek. Az elsődleges használati eset az eddigiek fényében ezen alapfeladatokat hivatott el- látni. Felsorolásszerűen ezek a következőek:

1. alkalmazás elindítása és ehhez kapcsolódó folyamatok

• TrustStore megnyitása és ellenőrzése • külső erőforrások (pl. kurzorok) betöltése és kezelése • a gyors lista (recent files) elemeinek ellenőrzése

2. alkalmazás felhasználói felülete és kapcsolódó folyamatok

• alkalmazás beállításainak kezelése (szerkesztés, érvényesítés) • az MDI kerethez kapcsolódó funkciók (gyermek ablakok listája, elrendezése) • modulok betöltése, bezárása

3. új Petri hálózat elkészítése 4. már létező hálózat megnyitása

• digitális aláírás ellenőrzése

5. hálózat szerkesztése és mentése 6. hálózat képként való exportálása 7. hálózatok integritás védelmének biztosításához kapcsolódó folyamatok

• bejelentkezés, vagyis a titkos kulcs megnyitása és ellenőrzése • mentés során a digitális aláírás elkészítése és csatolása a kimenethez

8. alkalmazás bezárása, és ehhez kapcsolódó folyamatok

• sikeresen mentett hálózatok mentése a gyors listába (recent files)

Mindezen funkciókat a 3.1. ábra use case diagramján lehet szemléltetni. 3. FEJEZET. RENDSZERTERV 43

3.1. ábra. Main use case

Elsődleges használati eset űrlapja Use Case Elsődleges használati eset Leírás A használati eset leírja mindazon funkciókat, melyek az alkalmazás elsődleges céljaihoz szükségesek. Actorok Felhasználó, Azonosított felhasználó, Alkalmazás Prioritás Kötelező (A prioritást az angol Must have, Should ha- ve, Could have és Won’t have kifejezésekkel szokták de- finiálni. Ezek magyarra fordítását jelen dokumentum a következőkben alkalmazza: Kötelező, Szükséges, Lehetsé- ges, Szükségtelen.) Kockázat Magas Előfeltétel, feltevés A funkciók egy jelentős részéhez érvényes TrustStore szükséges, mely fizikai állományként az e célra fenntar- tott könyvtárban a program elindítását megelőzően már rendelkezésre kell hogy álljon. Kiterjesztési pont Nincs Kiterjeszt Az egyes modulok innen indíthatóak el. Trigger Nem értelmezhető 3. FEJEZET. RENDSZERTERV 44

Esemény folyam 1: Privát kulcs megnyitása [A1][A2] 1.1: A rendszer ellenőrzi a kulcs érvényességét 2: Új Petri hálózat létrehozása 2.1: Petri háló alapvető tulajdonságainak megadása 3: Petri hálózat szerkesztése 4: Szimuláció, elemzés, modulok betöltése 5: Hálózat exportálása (kép formátumban) 6: Hálózat mentése (titkos kulcs szükséges) 6.1: Digitális aláírás generálása 7: Kilépés 7.1: Legutoljára mentett hálózatok listájának frissítése Alternatív ágak A1: Titkos kulcs hiányában lehetőség van meglévő há- lózat megnyitására A1.1: A TrustStore alapján a megnyitandó hálózat alá- írásának ellenőrzése A1.2: A folyamat a [3] pontban folytatható, de az [5]-ös pont titkos kulcs hiányában nem hajtható végre A2: Az alkalmazás globális beállításainak módosítása. A folyamat a [1]-es ponttól folytatható (az eredeti ese- ményfolyamot ez az alternatíva nem befolyásolja) Utófeltételek Nincsenek Üzleti szabályok [BR1][BR2][BR3][BR4][BR5][BR6][BR7][BR8][BR9] NFR-ek [NFR1][NFR2][NFR4][NFR5][NFR6][NFR7] [NFR8][NFR9][NFR12] Megjegyzés Nincs

Sikertelen forgatókönyv

1. Az alkalmzás induláskor betölti a TrustStore-ok listáját. 2. A Felhasználó nem rendelkezik titkos kulccsal, bezárja a bejelentkezési ablakot. 3. Megpróbál megnyitni egy ismeretlen forrásból származó hálózatot, mely integritás védett. Az állományban olvasható CertificateSubject mező értéke „[email protected] obuda.hu, CN=Teszt Elek, OU=NIK, O=UNI-OBUDA, L=Budapest, S=Hungary, C=HU”. 4. A felhasználó ellenőrzi hogy rendelkezik-e Teszt Elek tanúsítványával. Ezt az alkal- mazáson belül az erre szolgáló menüpontban meg tudja tenni. Amely tanúsítvány itt látható, az biztosan megfelelő X.509 v3 tanúsítvány [NFR12], RSA algoritmussal készült [NFR5], a rendszer idő szerint érvényes [BR1], kibocsátója „Petri Universitas Budensis Sub CA” [BR2] és megnyitási jelszava üres [BR5]. Teszt Elek tanúsítványát megtalálja a listában. 5. A megnyitás folyamata megszakad, az alkalmazás naplójában olvasható, hogy az aláírás nem megfelelő, a petri hálózat XML állományát valószínűleg alkalmazáson kívül módosították, avagy megsérült. 6. A felhasználó kilép az alkalmazásból. 3. FEJEZET. RENDSZERTERV 45

3.3.3. Modulok

A Petri háló szimulációs alkalmazás felhasználói felülete úgy lett kialakítva, hogy tetszőleges számú modul kezelése nem csak most, hanem a jövőben is lehetséges legyen. Ennek egyik sarkpontja a menürendszeren belül egy dinamikus viselkedés az egyes mo- dulok betöltése (megjelenítése) és bezárása kapcsán, másik sarkpontja pedig a modulok lebegő ablakának közös őse. A „lebegő ablak” azért fontos, mert így egyrészt egyidőben akár az összes modul aktív lehet (ha elég nagy felbontás rendelkezésre áll), másrészt mind- ezek semmilyen teret nem vesznek el az MDI keret funkcióitól. A modul ablakok őse olyan felhasználói élményt javító elemekkel rendelkezik, mint pl. az áttetszőség (opacity), illetve bizonyos esetekben a nagyítás/kicsinyítés lehetősége (zoom). A Petri hálózatok szimulálásának lehetősége nem került integrálásra a 3.3.2. fejezet- ben bemutatott elsődleges használati esetben, így az ezen hiányt pótló Állapot mátrix modul speciálisnak tekinthető abban az értelemben, hogy e nélkül csomagolni az alkal- mazást nincs sok értelme. Hasonlóan modulként van megvalósítva (elsősorban a „lebegő ablak” kényelme miatt) a szerkesztéshez használt eszköztár, a Petri paletta modul is.

Petri paletta modul

Az eszköztár (3.2. ábra) lehetőséget biztosít a „rajzoló” illetve „kijelölő” eszközök kiválasztására, illetve tartalmaz néhány kényelmi funkciót. Ha egy eszközt kiválasztottunk, akkor a szerkesztő felületen az egér kurzor megjelenése ezzel szinkronban megváltozik (ez a grafikai hatás kikapcsolható, az NFR13-nek megfelelően). Az eszköz kiválasztása minden egyes gyermek ablakra hatással lesz, a kijelölést támogató kényelmi funkciók azonban csak az aktuálisra (ha van). A paletta a következő elemeket tartalmazza:

• Az összes elem törlése az aktuális hálózatról • Kijelölő eszköz (több tétel kijelölését is támogatja, csoportos szerkesztéshez optima- lizálva) • Kijelölő eszköz (egy időben csak egy kijelölt elem lehet, a hálózat specializálásakor előnyös) • Speciális él kijelölő eszköz (ha a hálózat összetettsége miatt egy él kijelölése két dimenzióban korlátos) • Mozgató eszköz (bármely elem vagy elemek (csoportos kijelölés esetén) áthelyezésé- re, illetve élek „görbítésére”) • Törlő eszköz • Tokenjátékos törlő eszköz (egyesével lehet játékosokat törölni pozíciókon) • Összes elem kijelölését támogató gyors funkció (csak az aktuális hálózatra lesz ér- vényes) • A kijelölés megfordítása (csak az aktuális hálózatra lesz érvényes) • A kijelölés törlése (csak az aktuális hálózatra lesz érvényes) • Pozíciót rajzoló eszköz • Tranzíciót rajzoló eszköz • Él rajzoló eszköz (csak a hálózat topológiának megfelelő élek, illetve bármely anno- tációhoz pontosan egy elem összerendelése rajzolható általa) 3. FEJEZET. RENDSZERTERV 46

• Tokenjátékos rajzoló eszköz (egyesével lehet játékosokat elhelyezni pozíciókon) • Annotáció rajzoló eszköz (megjegyzések doboza)

3.2. ábra. Petri paletta module use case

Állapot mátrix modul

Az állapot mátrix modul (3.3. ábra) nem csupán a 2.4.1. fejezetben bemutatott M ál- lapot mátrix felírására és exportálására (képi, szöveges és LATEX formátumban) alkalmas, hanem itt van lehetőség az egyes állapotok léptetésére is, vagyis a szimulációra. A szimuláció történhet felhasználói kezdeményezésre, avagy lehet automatikus. Ér- telemszerűen időzített Petri hálózatok csak ezen utóbbi esetben tudnak az időzítésnek megfelelően viselkedni. A modul tartalmazza az automata szimuláció leállítására alkal- mas vezérlőt is, mely csak abban az esetben aktív, ha van a háttérben futó szimuláció. Az eszköztár gyermek ablakonként külön-külön értelmezett. Ha az egyik gyermek ablakban egy szimulációt elindítottunk, az nem fog szimulációt eredményezni egy másikban (a szi- mulációt támogató funkció gombok aktívsága is dinamikusan változik a gyermek ablakok váltogatásával). A szimuláció egyes lépései automatikusan megjelennek grafikusan a Petri hálózaton (Redraw Petri network), illetve van lehetőség a modul keretein belül arra is, hogy bár- mely az állapot mátrixban megtalálható állapotra visszatérjünk (Goto selected State). Megtehetjük azt is hogy töröljük az összes állapotot, hogy az aktuális állapotból legyen a kiindulási helyzet (Clear State matrix). Ha egy nem-determinisztikus ponthoz ér a folya- mat, akkor a futás eredményét ál-véletlen (pseudo-random) szám dobása fogja eldönteni2. Definiált azonban a Petri hálóra globálisan jellemző tüzelési szabály, melyet a felhasználó tetszés szerint beállíthat. A tüzelési szabály a következők egyike lehet:

• véletlenszerű (alapértelmezés) • a tranzíciók egyedi azonosítója (unid) szerinti növekvő sorrend alapján (a kisebb unid-val rendelkező tranzíció fog tüzelni nem-determinisztikus lépés esetén) • a tranzíciók egyedi azonosítója (unid) szerinti csökkenő sorrend alapján • prioritás szerint (priorizált Petri háló esetén)

Amennyiben prioritás szerinti tüzelési szabály van beállítva, de az N (N > 0) tü- zelésre kész tranzíció közül a legnagyobb prioritással rendelkező tranzíciók halmazának

2 A mai kor számítógépei által generált ál-véletlen számok a gyakorlati szimulációban véletlennek tekinthetőek. 3. FEJEZET. RENDSZERTERV 47 számossága nagyobb mint 1, vagyis |F | > 1 (ahol F ⊆ N), akkor az azonos prioritással rendelkező tranzíciók közül a választás nem-determinisztikus marad (ál-véletlen szám do- bása fog dönteni). A tüzelési szabályt, illetve az automatikus szimuláció során lényeges „timeout” értékét3 a modul ablakán elérhető beállítások panelben lehet konfigurálni. Az alkalmazás a háttérben az összes előforduló állapotot elemzi és memóriában tá- rolja. Ez azt jelenti, hogy ha az aktuális állapot mátrixban nem látható egy korábban már előforduló tokenjátékos eloszlás, de az ismételten előforul, akkor az a memóriából kerül betöltésre. Ez nem csupán azt eredményezi, hogy a korábban elnevezett állapot (az állapotokat el lehet nevezni egy másik modulban) neve visszaköszön, hanem azt is, hogy az állapotból kiinduló jövőbeli futás eredménye is láthatóvá válik.

3.3. ábra. State Matrix module use case

Állapot-hierarchia modul

Az állapot-hierarchia modul (3.4. ábra) az állapot mátrix modul kiegészítésének is tekinthető. A 3.3.3. fejezetben már említésre került, hogy a már előforduló, illetve adott

3 A szimuációs „timeout” egy minimum 50 ezredmásodperces érték, mely mindenképpen eltelik két tüzelés között akkor is, ha egyébként a hálózat nincs időzítve. Ennek oka elsősorban a szimuláció emberi szemmel való követhetősége, illetve a program stabilitása szempontjából is lényeges lehet. 3. FEJEZET. RENDSZERTERV 48 szituációban jósolhatóan előforduló állapotok memóriába kerülnek, és ismételt előfordu- lásukkor innen kerülnek elővételre. Az állapot-hierarchia modul ezen memória tartalmát jeleníti meg grafikusan. A megjelenítés valójában egy súly nélküli irányított gráf, ahol a szögpontok halmazában az állapotok vannak, az élek halmazában pedig az állapotok közti átmenetek. Ha két állapot között oda-vissza átmenet létezik, akkor értelemszerűen ez két külön irányított élnek jelenik meg. A modulban az egyes állapotokat „drag&drop” segítségével lehet elrendezni (ha egy új állapot kerül memóriába, akkor annak elrendezése véletlenszerű lesz), illetve kontextus menüből lehet elérni az állapotok további tulajdonságait:

• elnevezés (szabad szöveges mező) • sugár • események

Egy állapot átnevezése hatással van a 3.3.3. fejezetben bemutatott állapot mátrixra is. További hasonlóság a két modul között, hogy itt is bármely memóriában lévő állapot azonnali beállítása lehetséges (Goto selected State). A modul rendelkezik funkcióval az összes memóriában lévő állapot végleges törlésére nézve (Clear all states). Ez a törlés eltér az állapot mátrix esetén bemutatott állapot törléssel, ugyanis ott csupán az aktuális szimulációs lépések állapotátmenetei törlődnek, itt viszont a memória tartalmát törölhetjük. Az állapot-hierarchiát képként (PNG formátumban) kiexportálhatjuk, illetve ezen kép méreteit (szélesség, magasság) egy a modulból elérhető tulajdonság panelen beállít- hatjuk (Change SH settings). Ha olyan szerkesztési lépés következik be, melynek eredménye a memóriában lévő állapotok inkonzisztenciáját okozhatja, automatikusan törlődik az összes állapot, és ez hatással lesz nem csak az állapot-hierarchia, hanem az állapot mátrix modulra is.

Térkép modul

A térkép modul nem más, mint egy előnézeti kép a készülő Petri hálózatra nézve (3.5. ábra). A szerkesztéshez szükséges segédvonalak és jelzések kivételével tartalmaz minden grafikai hatást, és a hálózat szimulációját is megjeleníti. Tetszőleges méretben nagyítható, illetve kicsinyíthető, és bár ez jellemzője a szerkesztő felületnek is, prezentációra ennek a modulnak a nagyítása kényelmesebb.

Szomszédossági mátrix modul

A szomszédossági mátrix automatikusan elkészül minden olyan pillanatban, mikor a hálózat topológiája (pozíciók, tranzíciók, élek száma) megváltozik. A modul lehetőséget biztosít nem csupán a 2.4.1. fejezetben bemutatott W T szomszédossági mátrix előállítá- sára, hanem a W − és W + mátrixok is elemezhetőek. A mátrixokat lehetőség van képi (PNG), szöveges és LATEX formátumban exportálni (3.6. ábra). 3. FEJEZET. RENDSZERTERV 49

3.4. ábra. State Hierarchy module use case

3.5. ábra. Minimap module use case

3.6. ábra. Neighborhood Matrix module use case 3. FEJEZET. RENDSZERTERV 50

Statisztika modul

Az alkalmazás a [BR11]-es (3.2.3. fejezet) üzleti szabály értelmében minden egyes pozícióról, tranzícióról és állapot vektorról statisztikát vezet a szimuláció során (3.7. ábra). A pozíciók kapcsán értelmezett az utolsó inicializálás óta eltelt aktiválódások száma, az ez alatt összesen, minimálisan és maximálisan jelen lévő tokenjátékosok száma, illetve ezek számolt átlaga. A tranzíciók és az állapot vektorok kapcsán csupán a tüzelések, illetve az aktiválódások száma kerül összegzésre. A modul lehetőség biztosít az összes statisztikai adat monitorozására, az egyes ele- mek, illetve az összes statisztikai adat inicializálására.

3.7. ábra. Statistics module use case

Események modul

A Petri háló szimulációs alkalmazás jelen dolgozatban bemutatásra kerülő kiter- jesztése az egyes pozíciókhoz, tranzíciókhoz, állapotokhoz, illetve magához a hálózathoz események csatolását írja elő. Az eseményeknek típusuk és nevük van, az egyes elemekhez csak bizonyos típusú események csatolhatóak, és ezek meghatározott körülmények között aktiválódhatnak majd:

1. Pozíciókhoz köthető események

• Aktiválás előtt, vagyis mielőtt tokenjátékosokat veszít, vagy szerez (pre acti- vate) • Aktiválás után, vagyis miután tokenjátékosokat veszített, vagy szerzett (post activate)

2. Tranzíciókhoz köthető események

• Aktiválás előtt, vagyis közvetlenül a tüzelés előtt (pre activate) • Aktiválás után, vagyis közvetlenül a tüzelés után (post activate)

3. Állapot vektorokhoz köthető események

• Aktiválás előtt, vagyis az állapot bekövetkezése előtt (pre activate) • Aktiválás után, vagyis az állapot bekövetkezése után (post activate) 3. FEJEZET. RENDSZERTERV 51

4. Hálózathoz köthető események

• Halott állapot bekövetkezése, vagyis mikor egyetlen további tranzíció sem tud tüzelni, a szimuláció ilyenkor automatikusan leáll (deadlock) • Ciklus indulásakor, vagyis mikor egy olyan állapot aktiválódik, amelyik az ak- tuális szimuláció állapot mátrixában már szerepelt egyszer (cycle) • Időzített hálózatok esetén órajel hatására (tick)

Egy összetett eseménylánc során fontos az események bekövetkezésének sorrendjét is tudni, vagyis a folyamat életciklusát. Tegyük fel, hogy egy adott tranzíció tüzelését a lehető legrészletesebb módon körülvesszük eseményekkel. Ekkor az események a következő sorrendben aktiválódnak:

1. Az aktuális állapot „post activate” eseménye 2. Az input helyek „pre activate” eseménye 3. Az input helyek „post activate” eseménye 4. A tranzíció „pre activate” eseménye 5. Ha előáll, akkor „cycle” esemény 6. Ha előáll, akkor „tick” esemény 7. A tranzíció „post activate” eseménye 8. Az output helyek „pre activate” eseménye 9. Az output helyek „post activate” eseménye 10. Az új állapot „pre activate” eseménye 11. Ha előáll, akkor „deadlock” esemény

Egy eseménynek a regisztrálása csupán nevének a megadását jelenti (a név átesik egy transzformáción, mely során elveszíti white space karaktereit). A hálózat OO környezetbe ágyazását követően ezen név alapján lehet majd konkrét implementáló eseménykezelőt rendelni hozzá. Bár elsőre hiba lehetőséget sugallhat, hogy két esemény felveheti ugyanazt a nevet, azonban mindez szándékos tervezési lépés. Minden egyes esemény, típustól és kontextustól függetlenül ugyanahhoz a képviselőhöz tartozik. Kontextusát természetesen megkapja paraméterben, azonban ezen egyszerűsítés lehetővé teszi azt, hogy ugyanahhoz a logikai névhez egy lépésben egy megfelelően általános eseménykezelőt rendelhessünk. Ezen logikát követi az események modul is, mely név alapján csoportosítja az elemeket. A szimuláció során tetszőleges helyen beregisztrált egyedi események egy listába kerülnek. A lista egy elemét kiválasztva megjelennek azok az objektumok (pozíció, tranzíció, állapot vektor avagy maga a hálózat), melyekhez az adott névvel esemény lett regisztrálva. A szimulációs alkalmazás csupán az események regisztrálását, és jelen modulban meg- valósított listázását támogatja (3.8. ábra). Nem célja és nem is feladata az eseményekhez eseménykezelők rendelése, minthogy konkrét probléma, algoritmus sem kerül defininálásra sehol a szimulátorban. 3. FEJEZET. RENDSZERTERV 52

3.8. ábra. Petri Event List module use case

Tranzíció történet modul

A tranzíció történet avagy napló modul alkalmas lehet egy meghatározott szimulá- ció állapotait áttekinthető, szöveges formában megjeleníteni. Mindez akkor teljesülhet, ha a tranzíciók neveinek értelmes kifejezéseket ad meg a felhasználó. Állapotváltás során a tüzelő tranzíció neve kerül be a listába (a tüzeléskori neve, tüzelés utáni átnevezésekor a tranzíció napló nem fogja az új nevet átvezetni a korábbi eseményekre). Amennyiben a tranzíció tüzelésekor voltak bemeneti pozíciók (ez forrástranzíció kivételével mindig tel- jesül), a bemenetként kapott tokenjátékosok nevei felsorolásra kerülnek a tranzíció nevét követően.

3.9. ábra. Tranzíció történet modul use case

A modul ezen kívül alkalmas a naplóban megjelenő tranzíciók gyors kijelölésére is. Egy napló tételre kattintva (amennyiben a tranzíció még létezik) az aktuális MDI gyermek ablakon a tranzíció kijelölődik (a korábbi kijelölések megszűnnek).

3.4. Aktivitás diagramok

A tervezés következő fázisában néhány összetettebb folyamat aktivitás diagramja kerül bemutatásra (Activity Diagram). Az aktivitás diagramok alkalmasak a használati esetek viselkedésének pontosabb bemutatására, miközben a Use Case diagramok validálása is megtörténik. 3. FEJEZET. RENDSZERTERV 53

Két olyan pontja van az alkalmazásnak, ahol a részletesebb modellezés elvárható. Az egyik az alkalmazás elsődleges használati esete, míg a másik az állapot mátrix használati esetben leírt szimuláció (ez az adott használati esetnek csak egy része).

3.4.1. Elsődleges aktivitás

Az alkalmazás elsődleges használati esetéhez tartozik az inicializálás (kurzorok és egyéb erőforrások megnyitása, legutóbb használt hálózatok betöltése), a felhasználó azo- nosítása (bejelentkeztetés, privát kulcs verifikációja) és a hálózatok teljeskörű kezelése (megnyitás, szerkesztés, mentés). Az alkalmazás indítást követően egy PKCS12 formátumban tárolt privát kulcsot tar- talmazó állomány tallózását, illetve az ehhez szükséges tárolási jelszó megadását kéri a felhasználótól. Amennyiben ilyennel nem rendelkezik, lehetősége van a bejelentkezést ki- hagyni. Ennek egyetlen következménye lesz: mivel integritás védelemmel így nem tudja ellátni a Petri hálózatokat, és a [BR7], [BR10] szabályok szerint nem létezhet hálózat e nélkül, az elkészített hálózatot nem fogja tudni elmenteni (létrehozni, szerkeszteni és szimulálni memóriában viszont tudja). Ugyanerre az ágra fut a felhasználó, ha rendel- kezik megfelelő formátumú privát kulccsal, azonban az [NFR5], [BR1], [BR2] és [BR3] szabályok közül bármelyiket nem teljesíti a validáció során. A bejelentkezési képernyőn megadott jelszót az alkalmazás semmilyen körülmények között nem mentheti el (még ha ez kényelmes is volna a felhasználónak), megfelelve ezzel a [BR6] szabálynak. Bejelentkezést követően a felhasználó által elért aktivitások egyértelműek a haszná- lati eset diagramjából is. A beállítások módosítása, modulok betöltése (megjelenítés és elrejtés), a TrustStore böngészése, meglévő illetve új Petri hálók megnyitása/létrehozása bármilyen sorrendben és kombinációban megtörténhet, hiszen az alkalmazás az [NFR6] követelmény szerint MDI alkalmazás. Hálózat megnyitásakor ellenőrzésre kerül, hogy az állományban lévő felhasználó token (usertoken) nyilvános kulcsa (vagyis aki a hálózatot elmentette) megtalálható-e a TrustStore-ban. Amennyiben nem, a megnyitás sikertelen lesz. Mentés során a felhasználó tokenje, illetve időbélyeg (timestamp) is mentésre kerül a hálózat XML-jébe, közvetlenül a digitális aláírás generálása előtt (integritás védelem).

3.4.2. Szimuláció aktivitás diagramja

A Petri hálózatok szimulációját az Állapot mátrix modulban van lehetősége a fel- használónak elindítani. Alapvetően kétféle szimulációs mód van: a lépésenkénti (Manual step simulation) illetve az automatikus (Run simulation). Mindegyik ágra igaz azonban, hogy a következő tüzelésre kész tranzíció meghatározása (Fire transition (calculate next step)) programozott, vagyis nincs lehetősége a felhasználónak direkt módon befolyásol- ni (pl. egér kattintással). A választás alapértelmezetten nem-determinisztikus, azonban árnyalhatja mindezt a hálózatra jellemző tüzelési szabály (fire rule). Minden egyes lépés során vagy egy új állapot beállítása (Set state), avagy egy már az állapot mátrixban lévő állapot visszaállítása (Goto selected state) történik meg, mi- közben a Petri hálózat újrarajzolását jelző esemény keletkezik (Redraw Petri network). Amennyiben futó szimuláció van a háttérben, megvizsgálásra kerül, hogy a felhasználó kérte-e a szimuláció leállítását (cancel event occured), illetve deadlock állt-e be az utolsó lépés után. Ha egyik sem, akkor folytatódik a szimuláció, ezt jelzi az aktivitás diagramon egy kör, avagy ciklus (Run simulation). 3. FEJEZET. RENDSZERTERV 54

3.10. ábra. Elsődleges activity diagram

Két ponton történik várakoztatás a futó szimuláció során. Az egyik várakoztatás min- den egyes ciklus legvégén végrehajtódik (Waiting), ezzel a szimuláció általános sebessége definiálható. Ezredmásodpercben meghatározott értéke beállítható a tüzelési szabályok 3. FEJEZET. RENDSZERTERV 55 között, azonban 50 ezredmásodpercnél nem lehet kisebb. A másik várakoztatás nem min- den egyes ciklusban érvényesül: amennyiben időzített tranzíció kerül tüzelésési helyzetbe, az időzítésének megfelelő várakozást követően tud csak aktivizálódni 4.

3.11. ábra. Szimuláció activity diagram

3.5. Együttműködési diagramok

A tervezés következő fázisa együttműködési diagramok létrehozása volna (Interac- tion Diagram). Ezen diagramokra az jellemző, hogy a kommunikációban résztvevő ob- jektumokra, a köztük lévő üzenetváltásra és ezek sorrendiségére összpontosít (Sequence Digram, Communication Diagram vagy Collaboration Diagram, Iteraction Overview Di- agram (Activity Diagram és Sequence Diagram kombinációja)). A Petri háló szimulációs alkalmazás folyamatai a használati eset illetve aktivitás diagramok segítségével azonban egyértelmű képet mutatnak, nincs szükség a felsorolt diagramok elkészítésére.

3.6. Osztály diagramok

A Petri hálózat szimulátor alkalmazás számos helyen alkalmaz objektum-orientált tervezési mintákat, illetve több ponton alkalmazza az iparban megszokott absztrakciót, mint ahány helyen egy ekkora méretű alkalmazástól egyébként elvárható volna. Minden

4 Ezen a ponton a szimulációs alkalmazás egy egyszerűsítéssel él. A szimuláció egy háttérszálban történik, így a futás nem akadályozza a felhasználót bármely más felhasználói akciójának végre- hajtásában. Azonban elegáns megoldás volna minden egyes időzített tranzíció számára is egy-egy háttérszálat definiálni, hiszen amíg egy-egy időzített pl. forrás tranzíció tüzelésére várunk, lehet hogy más nem időzített tranzíció tüzelhetne. 3. FEJEZET. RENDSZERTERV 56 egyes osztály elemzésére nincs értelme kitérni, azonban az alkalmazás magját jelentő típu- sok bemutatásra kerülnek. Az osztályok teljes qualified névvel azonosítottak a dolgozat- ban, azonban rövidítésképpen a legelső névtér nem kerül megnevezésre. Ez minden egyes osztály esetén PetriNetworkSimulator.

3.6.1. Kriptográfiai osztályok

Az Utils.CertificateWrapper osztály csupán csomagolása a System. Security. Cryp- tography. X509Certificates. X509Certificate2 osztálynak, X.509.V3-as tanúsítványok táro- lására használható. Az Utils.CryptoHelper osztály már konkrét üzleti funkcióval ren- delkezik. Singleton pattern szerint lett elkészítve annak érdekében, hogy a TrustStore elemei, illetve bejelentkezést követően a privát kulcs az alkalmazás bármely pontján el- érhető legyen. Az egyetlen példányán (illetve a statikus metódosok esetén az osztályon) keresztül történik minden kriptográfiai művelet:

• tanúsítványok validációja (isValidCertificate) • privát kulcsok validációja (isValidPrivateStore) • TrustStore inicializálása és tárolása (initTrustStore) • felhasználó token alapján a TrustStore-ból egy tanúsítvány kikeresése (getCertifica- teFromTrustStore) • digitális aláírás elkészítése egy XmlDocument példányra (createSignature) • digitális aláírás ellenőrzése (checkSignature)

Az osztály static readonly változók formájában a forráskód részeként tartalmazza a vali- dációhoz szükséges kibocsátó subject-jét ([email protected], CN=Petri Univer- sitas Budensis Sub CA, OU=NIK, O=UNI-OBUDA, S=Hungary, C=HU), a privát kulcs alias-át (petri), a TrustStore-ok könyvtárát (truststore) illetve utóbbiak megnyitásához szükséges jelszót (<üres>).

3.6.2. Lokalizáció

A lokalizáció nem teljeskörű az alkalmazásban5, azonban a teljeskörű szabványos lo- kalizációhoz szükséges építőkövek elkészültek. Az Utils.CultureHelper osztály singleton pattern szerint készült, hogy a szükséges erőforrás kezelő (ResourceManager) bárhonnan elérhető legyen, azonban csak akkor kelljen inicializálni, mikor az szükséges (első nyelve- sített felirat megjelenítésekor, illetve az alkalmazáson belüli dinamikus nyelvváltáskor). Nyelvváltás kezdeményezésére changeCulture (event CultureHandler changeCulture) ese- mény történik. Azok az UI (User Interface) felületek, melyek tartalmaznak nyelvesített elemeket, eseménykezelőt készítenek ehhez az eseményhez. Hogy mindez ne csak opcio- nalitás legyen, készült egy Forms.Common.IUpdateCulture interface, melyet minden űrlapnak implementálnia kell (az egyes eszköz és dialógus ablakok közös ősei implemen- tálják az interface-t).

5 Messze nincs minden felirat dinamikussá téve, mindössze az egyes ablakok fejlécei vannak nyelve- sítve. Azok a feliratok, melyek nem nyelvesítettek, mindig angolul jelennek meg. 3. FEJEZET. RENDSZERTERV 57

3.12. ábra. Kriptográfiai osztályok

3.13. ábra. Lokalizációhoz kapcsolódó osztályok

3.6.3. Dialógusok

Az alkalmazás számos ponton használ modális dialógus ablakokat. Az általában kö- telező adatbekérés és ennek megerősítésére/elutasítására alkalmas gombok kezelése egy- séges képet mutat, mert ezen Formoknak egy közös ős lett definiálva Forms.Common. GeneralDialogForm néven. Az űrlap rendelkezik egy információs sávval, melyet a le- származott ablakok az information virtuális metódus override-olásával definiálhatnak. Amennyiben az űrlapon a „mégse” gomb megjelenítése nem engedélyezett6, a védett hi- deCancelButton metódust kell a leszármazott űrlap inicializálása során meghívni. Az elérhető dialógus ablakokat a 3.14. ábra mutatja be. Legtöbb célspecifikusan, a nevéből következő rendeltetésre használható csupán (StateHierarchySetting, StateMatrix- Setting, CreateNewPetriNetwork, stb.) vannak azonban olyan űrlapok is, melyek általános

6 Léteznek olyan dialógus ablakok, mely csak tájékoztatnak, nem kérnek be adatot, így nincs mit a felhasználónak elutasítani a „mégse” gombbal. 3. FEJEZET. RENDSZERTERV 58 célra használhatóak bárhol az alkalmazáson belül (TextExportForm, ChangeTextValue- Form).

3.14. ábra. Dialógus ablakok osztály diagramja

3.6.4. Felsorolás típusok

Az entitások sehol sem tartalmaznak kulcs-érték párokat literálként a forráskódba ágyazva. Minden olyan helyzetben, ahol a literál többlet információt tárol, felsorolás típu- sok vannak defininálva. Az alkalmazás C# nyelven való implementálása végett az enum nem más mint egy szintaktikai cukor (syntactic sugar) egy integrál érték típus körül. Ott, ahol a típus biztonság (type safety) és az objektum-orientáltság kiemelten fontos, a C# enum típusa nem a legjobb választás. Bár lehetőség van az enumot tulajdonságokkal el- látni annotációk segítségével, és statikus extension metódusokat is készíthetünk, ezek egy része teljesítmény problémákat okozhat, illetve legtöbbször ellentétes az encapsulation el- vével. Mindezek miatt jelen dolgozat részeként készült egy tervezési minta[67], mely több ponton a Java nyelv felsorolás típusának megfelelő lehetőségekkel rendelkezik. Az így elké- szült osztály példányai természetesen már referencia típusúak lesznek (ezáltal type safe), ahogyan a Java-ban.

3.6.5. Űrlapok

Az alkalmazás összesen négy általános űrlapot (Formot) tartalmaz:

• Forms.Dialogs.AboutForm: a program adatait tartalmazó dialógus • Forms.Dialogs.LoginForm: bejelentkezési képernyő • Forms.Main.MDIParent: MDI keret ablak • Forms.Main.PetriNetworkForm: MDI gyermek ablak

Az MDI szülő ablak értelemszerűen a teljes alkalmazást összefogja. Inicializálja az ál-véletlen generátort és tárolja a korábban megnyitott állományok kezelésére létrehozott RecentFiles. RecentFilesHelper osztály példányát illetve a modulok dinamikus listá- ját (List). Beolvassa és frissíti az operációs rendszer felhasználójá- tól függő beállításokat (ide az egyes ablakok, modulok megjelenítési helye és láthatósága, 3. FEJEZET. RENDSZERTERV 59

3.15. ábra. Felsorolás típusok osztályai az MDI parent mérete és az alkalmazás globális tulajdonságai tartoznak7), illetve kap- csolatot biztosít az egyes modulok és a gyermek ablakok között. Rendelkezik két állapotú menüvel, melyből az összes alkalmazásszintű és az MDI keretekre jellemző opció elérhe- tő, a modulok ki és bekapcsolhatóak. A menü második állapotát az első gyermekablak megnyitása, illetve az utolsó gyermekablak bezárása triggereli. A gyermekablakok külön menüvel nem rendelkeznek. A keret ablak felelős az alkalmazás leginkább erőforrásigényes műveletéért: a gyer- mek ablak kontextusától függő dinamikus tulajdonság, tokenjátékos és esemény lap gene- rálásáért. Amennyiben egyetlen grafikai elem van kijelölve az aktuális gyermekablakon, a tulajdonság és eseménylapok a mögöttes osztálypéldány legapróbb részletekig kiterjedő adattábláját fogják megmutatni. Ha azonban több tétel van kijelölve (csoportos kijelö- lés), akkor az osztály-hierarchia futás időben történő elemzése segítségével olyan csoportos szerkesztésre alkalmas elemek jelennek meg, melyek a lehető legbővebb halmazt képezik a kijelölt elemek tulajdonságaira nézve. A tulajdonságlap dinamikus viselkedése még en- nél is többet mutat: figyelembe veszi a kijelölt elemmel végezhető műveletek halmazát is (pl. egy él típusa (normál, tiltó avagy reset) csak akkor defininálható, ha az él irá- nyítása pozíciótól tranzícióig mutat), illetve rendelkezik néhány speciális művelettel (él irányultságának megfordítása, él kiegyenesítése). Minden szerkeszthető adat a számára legoptimálisabb formában, teljes validációval rendelkező dinamikusan létrehozott vezér- lőben jelenik meg (lenyíló listák, checkboxok, szín és betűtípus dialógus ablakok, stb.). A csoportos szerkesztést támogató egyedi vezérlő is készült az alkalmazáshoz Controls. PropertyGroupMoveTool néven. A vezérlő paramétertől függően egy kis és egy nagy léptékkel tudja kétirányban módosítani egy meghatározott tulajdonság értékét. Az MDI szülő ablak feladatai közé tartozik a fentieken kívül még egy konzol ablak ke-

7 Az alkalmazás globális tulajdonságai a következők: a rácsháló mérete (GridSize) és megjeleníté- se (ShowGrid), a grafikai elemek rácshálóhoz igazítása (AlignToGrid) illetve az egyedi kurzorok be/kikapcsolása (ShowCustomCursor). 3. FEJEZET. RENDSZERTERV 60 zelése is. A konzol ablakra az alkalmazás bármely osztálya küldhet üzeneteket (eseménye- ken keresztül). A konzol ablak tartalma helyi menüből szöveges állományként lementhető (pl. tranzakció napló, hibakeresés és egyéb okokból), illetve inicializálható (törölhető). A konzol ablakra írni is lehet, a konzol alatti utasítás sorba való gépelés segítségével. Jövőbeli tervezett funkciók között szerepel az alkalmazás belső CLI-ból (Command Line Interface) való működésének megvalósítása (MathLab szerű felhasználói élmény eléréséhez). Az MDI gyermek ablak legfontosabb feladata az Entities. Network. PetriNet- work entitás példányának tárolása, grafikai megjelenítése és támogatása. A modulokkal az MDI szülőjén keresztül, illetve események segítségével képes kétirányú kommunikáci- óra. A szerkesztő ablak közel tetszőleges mértékben nagyítható, illetve kicsinyíthető az egér görgőjének segítségével (MouseWheel eseménykezelő). Az összes egérrel végrehajtott művelet transzformálja a képernyő pixeleit a Petri hálózat logikai pixeleire, figyelembe véve a nagyítás mértékét. Csoportos kijelöléskor, illetve élek rajzolásakor segédvonalak jelennek meg, melyek segítik a felhasználó tájékozódását (ControlPaint. DrawReversib- leLine és DrawReversibleFrame statikus metódusok felhasználásával). A rajzolás a Petri hálózatok topológiájának megfelelő szabályokra érzékeny. Ez azt jelenti, hogy pl. mikor él kirajzolásakor az egyik végpontot már definináltuk, a lehetséges végpontok (ha a kiin- dulási pont tranzíció volt, akkor a pozíciók, ellenkező esetben a tranzíciók) más színnel jelennek meg (és mindez forrás és nyelő tranzíciók figyelembe vételével történik). A gyermek ablakon végezhető műveletek halmaza a Petri paletta modul aktuális ál- lapotának függvényében változik. A pozíció, tranzíció és annotáció (jegyzet) eszköz műkö- dése mondhatni egyértelmű. Az alkalmazás beállítása szerint ikon jelzi a gyermek ablakon a kiválasztott eszközt, kattintás hatására egy új elem hozzáadásra kerül a hálózathoz. Ha olyan helyre szeretne a felhasználó elemet helyezni, ahol a „közelben” egy másik elem avagy él található, akkor az elem hozzáadása helyett a „közeli” tétel kijelölődik/vissza- jelölődik. Az élek rajzolása még ennél is több helyzetfüggő intelligenciával rendelkezik: egyrészt felismeri a hálózat topológiát, másrészt alkalmas egy annotáció és bármely más nem annotációs elem összerendelésére (valamint kezeli utóbbi él átdefiniálását is). További gyors szerkesztést támogató tulajdonsága az él rajzoló eszköznek, hogy ha egy pozíciótól egy üres területig élt rajzol a felhasználó, az üres helyen egy új tranzíció jelenik meg, majd ha innen is élt húz egy üres területre, ott egy új pozíció jelenik meg. Ezzel a módszerrel rendkívül gyors, a topológiának megfelelő hálózat építés valósulhat meg. Az elemek átmozgatására, átméretezésére alkalmas eszközről érdemes még szót ej- teni. Kiválasztásakor a hálózaton számos átméretezést segítő segéd pont jelenik meg (ez a vizuális hatás a hálózat szinten kikapcsolható). Pozíció, tranzíció és annotáció esetén egyszerűen áthúzhatjuk az elemet a kívánt új pozíciójába, illetve négy sarkát megfogva át tudjuk méretezni. Az áthelyezés működik a pozíciók és tranzíciók nevére is, mely áthelye- zés a tulajdonosa origójához viszonyított. Pozíció esetén a méretezés csak „négyzetesen” történhet (nem lehet ellipszis alakú a pozíció), tranzíció illetve jegyzet esetén ellenben en- nél egyel több szabadsági fokunk van. Ha egy a topológiában résztvevő egyenes élt bármely pontján megfogunk, akkor ezen a ponton keresztüli görbületet hozunk létre. A görbület arányos lesz az egyenes él közepéhez, így a végpontjait áthelyezve sem okoz mindez később grafikai hibát. Ha valamely kis tétel (pl. tranzíció) sarkát nem tudjuk az egérrel megfogni, nagyítsuk a hálózatot az egér görgőjével. A kijelölést segíti a gyermek ablak státusz sora is, ahol megjelenik hogy az egér aktuális pozíciója éppen melyik tételt, és annak melyik részét azonosította (pl. bal-felső sarok, illetve felirat). A Petri paletta állapotától függetlenül ha egy névvel rendelkező tételen (pozíció, tranzíció, él) az egér bal gombjával duplán kattintunk, akkor modális ablakban a nevét 3. FEJEZET. RENDSZERTERV 61

(feliratát) módosítani tudja a felhasználó. Itt is van egy speciális viselkedés: amennyi- ben annotáción történik a kattintás, akkor a név helyett a tartalmazó szöveg módosítása lehetséges. Az MDI gyermek ablakon három tabfül található. Az elsőn láthatjuk a grafikus szer- kesztési felületet, a másodikon az XML forrást (a memóriában lévő állapot szerint), a harmadikon pedig a hálózathoz tartozó leírást (szabadon szerkeszthető). Az XML forrás bár nem szerkeszthető, a jobb áttekinthetőség kapcsán színezéssel dekorálható. A gyermek ablak kezeli az automatikus szimuláció során elinduló háttérszálat is, és annak felülettel való szinkronizációját.

3.6.6. Képviselők

A képviselők segítségével az alkalmazás osztálypéldányai egymással aktív üzenetvál- tásban lehetnek. Felsorolásképpen a 3.1. script részlet bemutatja a definiált képviselőket.

1 namespace PetriNetworkSimulator.Forms.Main { 2 public delegate void NetworkItemHandler(List items , bool forceRefresh); 3 public delegate void ChildFormHandler(string name); 4} 5 namespace PetriNetworkSimulator.Forms.Tools { 6 public delegate void StateVectorHandler(StateVector stateVector); 7 public delegate void StateMatrixSettingsHandler(FireRule fireRule , int millisecondsTimeoutForSimulation) ; 8 public delegate void StateActionHandler(StateMatrixAction action , PetriNetwork network); 9 public delegate void NetworkActionHandler(NetworkToolboxAction selectedAction); 10 public delegate void NetworkItemHandler(NetworkToolboxItem selectedItem) ; 11} 12 namespace PetriNetworkSimulator. Entities .Network { 13 public delegate void DimensionHandler(int width, int height); 14} 15 namespace PetriNetworkSimulator . Entities .Common.Network 16{ 17 public delegate void PetriNetworkEventHandler(string message); 18 public delegate void PetriNetworkNotifier(NetworkNotifierAction action); 19} 20 namespace PetriNetworkSimulator. Utils 21{ 22 public delegate void CryptoHandler(string message); 23 public delegate void CultureHandler(); 24} 25 namespace PetriNetworkSimulator.Controls 26{ 27 public delegate void PropertyGroupMoveHandler(AbstractNetwork network , NetworkProperty networkProperty , float value); 28} 3.1. kód. Képviselők

A NetworkItemHandler segítségével az MDI gyermek ablakokon kijelölt vizuális elemekről kap üzenetet az MDI parent, hogy ennek megfelelően a dinamikus tulajdon- ság és esemény táblázatot fel tudja építeni. Amennyiben egyetlen elem van csak kijelöl- ve, akkor a konkrét elem teljeskörű tulajdonságlapja lesz látható, ha több elem, akkor a lehető legbővebb közös tulajdonságok csoportos szerkesztése előtt nyílik meg az út. Külön képviselők támogatják az állapot mátrix és az állapot-hierarchia közötti üzenet cserét (StateVectorHandler és StateActionHandler), illete a Petri palettán való fel- használói jelzések MDI parenten keresztül történő ejuttatását az aktális gyermek ablak számára (NetworkActionHandler és NetworkItemHandler). Ha az alkalmazás in- dulásakor a TrustStore inicializálása érvénytelen tanúsítványt talál, esemény keletkezik (CryptoHandler), melyről az MDI keret konzoljában értesülhet a felhasználó.

3.6.7. Petri hálózatok

A hálózatok alkalmazáson belüli modelljét az Entities. Common. Network. Ab- stractNetwork és az Entities. Network. PetriNetwork osztályok jelentik. Az abszt- rakció itt elsősorban a „Segregation of Duties” és a „Separation of concerns” elveit követi, 3. FEJEZET. RENDSZERTERV 62 vagyis bizonyos művelet csoportok egymással való keveredését küszöböli ki, és kevésbé az objektum-orientáltág miatt került szétválasztásra a modell. Az absztrakt osztály felel a hálózat vizuális (NetworkVisualSettings) és láthatósági (NetworkVisibleSettings) beállításaiért, valamint tárolja a tranzíciók, pozíciók és annotá- ciók (List), valamint az élek halmazát (List). Felel a kijelölt elemekért (List), és karbantartja az állapotokat (List és StateHierarchy) és a hálózathoz csatolt eseményeket is (EventTrunk). Hatékonysági és szerializálási szempontból vannak az élek elkülönítve tárolva a többi gra- fikai elemtől, azonban a kijelölt tételek kezelése együttesen történik (a selectedItems lista generikus típusa AbstractItem, mely az összes grafikai elem közös őse). Az absztraktból leszármazott PetriNetwork osztály tárolja a hálózat fizikai adatait (állomány név, felhasználó token, utolsó módosítás dátuma, szélesség, magasság, leírás, tüzelési szabály és a szimulációs timeout érték), valamint az Entities. Utils. Identity- Provider osztály példányát. Utóbbi felelős a hálózat szinten értelmezett egyedi UNID értékek kiosztásáért. Egyedi UNID-val rendelkezik minden token, pozíció, tranzíció, an- notáció (jegyzet) és állapotvektor. Szerializálás során van ennek jelentősége, ugyanis az XML állományban számos helyen hivatkozni kell meghatározott tételekre (pl. egy él egy- értelműen hivatkozik a kezdő illetve a végpontjára). Műveletek oldaláról az osztály felelős a grafikai megjelenítésért, a statisztikai adatok inicializálásáért és a teljes szimuláció ke- zeléséért.

3.6.8. Petri tételek osztályai

Minden olyan grafikai elem, mely a Petri hálózaton megjelenhet, az Entities. Com- mon. Base. AbstractItem osztály példánya. Ez csupán a nevét (name), egyedi azo- nosítóját (unid) és kapcsolódó adatainak megjelenítésének kapcsolóját definiálja (sho- wAnnotation), valamint rendelkezik egy statikus UNID alapú keresővel (findItemByUnid metódus). Három absztrakt osztály származik belőle:

• Entities.Common.TokenPlayer.AbstractToken a tokenjátékosok közös őse • Entities.Common.Edge.AbstractEdge az élek közös őse • Entities.Common.Item.Base.AbstractNetworkItem a pozíciók, tranzíciók és annotációk (jegyzetek) közös őse

A tokenjátékosok egyetlen egyedi adattagja a kitöltési színük (TokenColor). Az al- kalmazás az értelmezhető helyeken kezeli a tokenjátékosok példányainak valós mozgását, és ennek vizualizációjára alkalmas a példány színezése. Azonban vannak olyan szituációk, mikor egy tranzíció tüzelése során a hálózat előző állapotára jellemző tokenszám megvál- tozik. Ilyenkor elképzelhető, hogy színezett token példányok eltűnnek, illetve újak létre- jönnek (az új tokenjátékos mindig fekete színű lesz). E viselkedést nem lehet befolyásolni az alkalmazás jelen állapotában, a színezés alkalmas viszont arra, hogy kiderüljön melyek azok a rész hálózatok, melyekben adott tokenek nem vesznek el sosem. Nem utolsó szem- pont az sem, hogy számos Petri hálózat, mely fix tokenszámmal működik, eredményesen vizualizálható. Az élek közös absztrakt őse valójában mindent meghatároz, ami az élekhez kapcsoló- dik. Két leszármazott osztálya (Entities. Edge. EdgePositionTransition és Entities. Edge. EdgeTransitionPosition) csupán a topológiai irányultságban különbözik. Az 3. FEJEZET. RENDSZERTERV 63 absztrakt osztály felelős a grafikai megjelenítésért, beleértve ebbe az egy ponton görbít- hető köztes pontot is. Ameddig egy él egyenes, kijelölése az él bármely közeli pontjára való kattintással megoldható. Görbítést követően egy segédkör jelenik meg a köztes görbítési pont körül, mely jelzi a kijelöléshez, illetve mozgatáshoz használható területet. Az élek fontos adattagja a típusa (EdgeType), mely értéke szerint nem csupán vizuálisan jelenik meg máshogyan a kapcsolat, hanem természetesen a hálózat tüzelésére is mindez komoly hatással lesz. Az Entities.Common.Item.Base.AbstractNetworkItem absztrakt osztály tá- rolja a grafikai elemek origóját, méretét, bal-felső koordinátáját, sugarát és feliratának offsetjét. A felsorolt adattagok között van redundancia, azonban leszármazott függő, hogy melyik mező írható, és melyiket számolja ki az alkalmazás automatikusan. A kiszámolás azért szükséges, mert a grafikai megjelenítés során nem érdemes felesleges számításokkal terhelni a számítógép erőforrásait. Egy pozíció vizuális meghatározása a felhasználó szá- mára logikusabb az origója és a sugara által, megjelenítéséhez azonban a számítógépnek a bal-felső koordinátájára és a méreteire van szüksége. Az osztály gondoskodik a elemek statisztikájának kezeléséért, valamint a kereshetőségükért mind vizuálisan (koordináták), mind adattagok (név és unid) alapján. Egy jegyzetet az Entities.Common.Item.Note.AbstractNote absztrakt osztállyal modellezünk. Tároljuk a csatolt példányt (AbstractItem) illetve a jegyzet szövegét. Csatolt osztály tokenjátékos és annotáció kivételével bármely AbstractItem lehet, vagyis tetszőle- ges élhez, pozícióhoz és tranzícióhoz köthetünk jegyzetet. A jegyzet grafikai megjelenítését az Entities.Item.NetNote.Note leszármazott osztály definiálja. A pozíciókhoz kapcsolódó egyedi adattagokat az Entities. Item. NetPosition. Po- sition osztály határozza meg. Legfontosabb adattagjai a tokenjátékosok listája (List ) illetve a pozíció kapacitás korlátja. A tokenjátékosok kezeléséért is ez az osztály felel, tokeneket egyesével lehet elvenni, hozzáaadni, illetve tüzeléskor tömegesen mozgatni. A játékosok öt elemig vizuálisan elkülönítve jellennek meg (a saját színükkel), ezt követően azonban egy számmal lesznek jelezve a pozíción. A tranzíciókat az Entities.Common.Item.Transition.AbstractTransition abszt- rakt, és leszármazott Entities.Item.NetTransition.Transition osztály határozza meg. Minden tranzícióhoz tartozik egy prioritás, egy típus (TransitionType) és egy esetleges időzítés. Vizuálisan külön meghatározható a forgatás szöge (oldalakkal párhuzamos tég- lalapként tároljuk adatait, utólag értelmezett egy ezen végzett forgatás), illetve időzítés esetén az azt jelölő óra ikon mérete és helyzete a tranzícióhoz képest. Máshogy jeleníti meg a leszármazott osztály a forrás illetve a nyelő tranzíciókat, illetve az időzítést jelölő óra csak akkor jelenik meg, ha a késleltetés pozitív. Ha egy tranzíció típusa megváltozik, akkor ez kihatással van a hálózat többi elemére is (a beállítás csak a hálózaton keresztül történhet meg, és ez egyben validálja is a lépést). Ha például egy tranzíciót forrássá vál- toztatunk, akkor automatikusan minden bemeneti éle törlődik, ha pedig nyelővé, akkor minden kimeneti.

3.6.9. Állapotvektorok osztályai

Az állapotvektorok központi osztálya az Entities.State.Vector.StateVector en- titás. Minden állapotnak egyedi neve, azonosítója (unid), origója, sugara, statisztikája (GeneralStatistics) és eseménytörzse (EventTrunk) van, valamint nem utolsó sorban to- keneloszlása (Dictionary >, ahol a kulcs a pozíció unid-ja). 3. FEJEZET. RENDSZERTERV 64

3.16. ábra. Petri tételek osztályai

Üzletileg lényeges pontja az osztálynak az Equals és GetHashCode metódusok override- olása, ugyanis akkor lesz két állapot azonos, ha azonos pozíciókhoz azonos számú token tartozik. A tokeneloszlás tárolása azonban ennél többet mutat az osztályban, hiszen a tokenek listájának elemei eltérhetnek annak ellenére, hogy a lista elemszáma azonos. Az osztály ezen kívül gondoskodik az állapotok grafikai megjelenítéséről és kereshetőségéről (grafikai koordináták és unid alapján is). Az Entities.State.Hierarchy.StateHierarchy osztály tárolja az állapotokat és a közöttük lévő átmeneteket. Utóbbiakhoz az Entities.State.Edge.EdgeStateState en- titást használja. Az állapot-hierarchia adattagja az állapotok és az élek listáján kívül az ábrázoláshoz használt felület szélessége és magassága is.

3.6.10. Petri események

A Petri hálózatok dolgozatban definiált kiterjesztésének építőköve az Entities. Event. PetriEvent osztály. Az osztály üzletileg olyan karakterlánc (esemény neve) tárolására alkalmas, mely mindkét oldalról trim-elt, belső szóközök helyett pedig „_” karaktert tar- talmaz. Ha üres string kerül értékadásra, automatikusan null-ozza (Adjusted property ez esetben hamissal tér vissza). Azokhoz az entitásokhoz, melyekhez Petri esemény rendelhe- tő, egy-egy Entities.Event.EventTrunk példányt kell rendelni. Ezt az érintett entitások által kötelezően implementált Entities.Common.Base.IPetriEvent interface elő is írja számukra. A következő osztályok érintettek:

• Entities.Common.Item.Base.AbstractNetworkItem a Pozíciók és Tranzíciók közös abstract őse • Entities.Common.Network.AbstractNetwork a Petri hálózatok abstract őse • Entities.State.Vector.StateVector az állapotvektorok osztálya

A 3.17. ábrán látható Entities.Event.PetriEventTransfer osztály még nem került szó- ba. Ez csupán egy technikai osztály, mely összeköti az esemény példányt (PetriEvent) a szülőjével (IPetriEvent), mivel ez az információ tartalmazási oldalról szedhető csupán össze. Az eseményeket kezelő modulban van erre szükség, ahol név alapján kell az összes érintett szülőt listába gyűjteni. 3. FEJEZET. RENDSZERTERV 65

3.17. ábra. Petri eseményekhez kötődő osztályok

3.6.11. Modul ablakok osztályai

Minden egyes modul egy-egy lebegő ablakként jelenik meg az alkalmazásban, mely ablakok közös jellemzője a nyelvesített címsor, az előtérbe és háttérbe küldés lehetősége és az állapotsávban állítható áttetszőség. E közös jellemzők a Forms. Common. Ge- neralToolWindow ősosztályon keresztül valósulnak meg. Azok a modulok, melyek központi eleme egy (vagy több) nagyítható kép, egy köztes ősosztállyal is rendelkeznek, mégpedig a Forms. Common. GeneralPictureToolWin- dow formmal. Az ős meghatározza a kép fizikai méreteit és nagyítási arányait. Metódu- sokat tartalmaz a pixelek és a valós koordináták konverziójára és a kép exportálására.

3.18. ábra. Eszköz ablakok osztályai 3. FEJEZET. RENDSZERTERV 66

3.6.12. Utoljára megnyitott állományok

Az utoljára megnyitott állományok az alkalmazás gyökerében lévő recentfiles.xml állományban kerülnek szerializálásra, és minden program indítás során ebből kerülnek deszerializálásra. A folyamat teljesen automatizált módon, a .NET 4.0 SDK XSD To- ol elnevezésű eszközével készült. A 3.2. kódban egy példa XML állomány olvasható az utoljára megnyitott állományok kapcsán.

1 2 5 6 Timed clock 7 .\ networks\Timed_clock .pn.xml 8 9 E=bedok. david@nik . uni−obuda.hu, CN=David Bedok, 10 OU=NIK , O=UNI−OBUDA, L=Budapest , S=Hungary , C=HU (2011.10.02. 11 18:24:48) Nyolcas szamlalo 12 13 14 15 Dining philosophers 16 .\ networks\\Dining_philosophers .pn.xml 17 18 E=bedok. david@nik . uni−obuda.hu, CN=David Bedok, 19 OU=NIK , O=UNI−OBUDA, L=Budapest , S=Hungary , C=HU (2011.10.02. 20 18 : 2 4 : 5 6 ) 21 22 23 3.2. kód. Utoljára megnyitott állományok példa XML forrása

Minden állományról elmentjük a nevét, elérési útját és leírását, kombinálva az utolsó mentés dátumával, és a felhasználó tokenjével. Annak érdekében, hogy automatizáltan lehessen a fenti XML állományt deszerializálni, szükségünk van a fenti XML-t meghatá- rozó XSD állományra. Ezt az XSD Tool 3.3. kódrészletben bemutatott parancsával lehet generáltatni.

1 "%INSTALLDIR%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\xsd.exe" recentfiles.xml / outputdir:output 3.3. kód. XSD tool segítésével XML-ből XSD generálás

A kimenet névterenként külön állományban jelenik meg, így keletkezni fog egy re- centfiles.xsd (lásd. 3.4.kód) és egy recentfiles_rf.xsd file (lásd. 3.5. kód).

1 2 7 8 9 10 11 12 13 14 15 3.4. kód. A recentfiles.xml állomány schema-ja 3. FEJEZET. RENDSZERTERV 67

1 2 9 10 11 12 13 14 15 16 17 18 3.5. kód. A recentfiles_rf.xml állomány schema-ja

A fenti állományokból az XSD Tool segítségével lehet C# osztályt generáltatni. Fut- tassuk a 3.6. kódban leírt parancsot, és a kimenetként előálló RecentFiles. PetriNet- workFiles és RecentFiles. RecentFile osztályt importáljuk be a Petri szimulációs al- kalmazásba!

1 "%INSTALLDIR%\Microsoft␣SDKs\Windows\v7.0A\Bin\NETFX␣4.0␣Tools\xsd. exe"␣/outputdir:source␣/classes␣/language:CS␣/namespace: PetriNetworkSimulator.RecentFiles␣.\manual\recentfiles .xsd␣.\ manual\recentfiles_rf .xsd 3.6. kód. XSD tool segítségével XSD-ből Java kód generálás

A szerializálás és deszerializálás csomagolására készült el a RecentFiles. Recent- FilesHelper osztály. Példánya karbantartja az utoljára megnyitott állományok listáját, és lekezeli az időközben áthelyezett állományok problémáját. Ha voltak ilyenek, az alkalma- zás bezárásakor ezen állományok már nem fognak bekerülni a recentfiles.xml állományba. A létező elemek az MDI keret menürendszerébe dinamikusan bekerülnek, billentyűpa- ranccsal (CTRL + num) és tooltip szöveggel együtt.

3.19. ábra. Utoljára megnyitott állományok osztály diagramjai 3. FEJEZET. RENDSZERTERV 68

3.6.13. További osztályok

Az eddig nem csoportosított osztályok összefoglalva ebben a fejezetben kerülnek megemlítésre. A statikus Program osztály, a Properties.Resources és a sealed (final) Properties.Settings osztály minden formos alkalmazást jellemez, ezekkel külön nem fog- lalkozunk. A Controls.PropertyGroupMoveTool UserControl-ról már volt szó a 3.6.5. fejezetben, ugyanehhez a funkció csoporthoz tartozik az Utils. ControlHelper statikus 8 és az Utils. PropertyTag osztály is, utóbbi egyszerűen a paraméterátadást könnyí- ti meg. A még nem említett Utils.CursorHelper osztály singleton pattern szerint lett elkészítve, segítségével állományból belolvasott egyedi kurzorok kerülnek betöltésre.

3.20. ábra. További osztályok diagramjai

8 A statikus osztály C#-ban olyan osztályt jelent, melynek csak statikus member-jei vannak. Nem összekeverendő a Java nyelv statikus osztály módosítójával, amely top level nested class-oknál használatos. 4. fejezet

Petri hálózatok tárolása

A Petri hálózatok mentés során XML formátumban perzisztálódnak merevlemezre. Az XML formátum lehetővé teszi az egyértelmű és gyors feldolgozást nem csupán számító- gép, hanem ember számára is. Az alkalmazott névterek és tag elnevezések pedig lehetővé teszik a *.pn.xml állományok integrációját más alkalmazások számára. A dolgozat iroda- lomkutatásában említett PNML formátum teljesen hasonló célokból jött létre (lásd. a 2.5. fejezet). Ha megvizsgáljuk a *.pn.xml állományok keretét (4.1. kód), akkor feltűnhet egy má- sik lényeges pont a tervezés során: a szekvenciális feldolgozás lehetősége. A Petri hálóza- tokról tárolható adatok számos ponton redundanciát tartalmazhatnak perzisztálás során (pl. él mentésekor az él adatait a kapcsolódó pozícióhoz és a tranzícióhoz is köthetjük), ezért ennek elkerülése érdekében minden egyes elemnek egyedi azonosítója van, melyre hivatkozni lehet. Ez a kereszthivatkozott XML dokumentumokban egy bevett szokás (pl. SOAP üzenetekben). Az egyedi formátum definíció mellett ezen azonosítás és hivatkozás is saját implementációt követ, mely megvalósítja azt a követelményt, melyet a szabvány egyébként nem ír elő: egy elemre csak akkor kerül hivatkozás, ha szekvenciális feldolgo- zás mellett az elem definíciója a dokumentumban már korábban megtörtént. A tervezés során arra külön figyelem fordult, hogy ne legyenek kör hivatkozások, így a „kiterítés” teljes egészében meg tud valósulni. E megvalósítás az XML dokumentum átláthatóságát nagyban megkönnyíti (elsősorban emberek számára), illetőleg manuális feldolgozás során is elegendő a dokumentumon egyszer végigmenni (ez azért ma már elhanyagolható előnyt jelent).

1 2 3 4 [..] 5 6 7 [..] 8 9 10 [..] 11 12 13 [..] 14 15 16 17 [..] 18 19 20 [..] 21 22

69 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 70

23 [..] 24 25 26 27 28 [..] 29 30 31 [..] 32 33 34 35 [..] 36 37 4.1. kód. A kimeneti *.pn.xml állomány kerete

Az XML gyökér eleme (root element) a pn:PetriNetwork. Ennek gyerekei azonos névtér deklaráció mellett a hálózat globális tulajdonságai (pn:NetworkSettings), globá- lis eseményei (pn:Events), vizuális (pn:VisualSettings) és láthatósági (pn:VisibleSettings) beállításai, topológiája (pn:Network) valamint állapot-hierarchiája (pn:StateHierarchy). Utóbbi lényegében egy különálló modul perzisztálását jelenti. A gyökér elem (és annak minden gyermeke) integritás védett. A védelmet leíró dekorációs elemeket az XML digitá- lis aláírás W3C szabványa határozza meg. A szabvány kitér arra is, hogy ezen elemeknek a gyökér elem alatt kell elhelyezkedniük[68]. Ezen Signature tag szabványos módon a http://www.w3.org/2000/09/xmldsig# névtér alá tartozik.

4.1. Globális tulajdonságok

Azon tulajdonságok, melyek nem köthetőek közvetlenül egyetlen topológiai elemhez sem, illetőleg a hálózat egészét jellemzik, a globális tulajdonságok között kerülnek felsoro- lásra (4.2. kód). A pn:NetworkSettings összes gyereke a http://settings.petrinetwork.hu névtér alá tartozik.

1 2 3 4 5 6 7 8 9 10 11 [..] 12 13 [..] 14 15 16 17 4.2. kód. A kimeneti *.pn.xml állomány kerete

A név (ns:Name) és leírás (ns:Description) mezők egyszerű szöveges reprezentá- ciói a hálózatnak. A leírás az alkalmazásban egy külön tabpage-en jelenik meg, tar- talma egyszerű unicode szöveges tartalom lehet. Az integritás védelemhez feltétlenül szükséges a tanúsítvány tárgya (ns:CertificateSubject) illetve az utolsó mentés dátuma 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 71

(ns:LastModificationDate). A hálózat fizikai méretét a szélesség (ns:Width), a magasság (ns:Height) és az állapot-hierarchia dimenziói (ns:StateHierarchyWidth és ∼Height) ha- tározzák meg. Grafikus megjelenítés illetve képként való exportálás során ezen méretek lesznek a megjelenítési határok. Az egyes topológia elemek, illetve állapotok létrehozásakor (állapotok a szimuláció során automatikusan jönnek létre) egy-egy alapértelmezett, ámbár egyedi névvel lesznek ellátva az entitások. Ezen azonosítás csupán vizuális, vagyis az egyediséget utólag meg lehet változtatni (bár legtöbbször érdemes egyedinek hagyni). Az entitásokra kereszthi- vatkozni így nem nevükkel, hanem úgynevezett unid értékükkel lehet. Ez a háttérben automatikusan és garantáltan egyedi módon kerül kiosztásra (egy a hálózat szintjén ini- cializált unid generátor biztosítja a kiosztását az új azonosítóknak). Az entitások kezdeti neveit nem csupán generálás után, hanem előtte is részben meg tudjuk határozni. Ezt a célt szolgálják az ns:XXXGenNumber és ns:XXXPrefix tulajdonságok. Ha adott típusú entitásból létrejön egy új, neve a meghatározott prefix-ből, és az automatikusan iterált egész számból fog állni. A következő entitásokra értelmezett ezen név generálás: tokenjáté- kos (token), pozíció (position), tranzíció (transition), annotáció/jegyzet (note) és állapot (state). Az előbb említett csoportba tartozik az ns:DefaultEdgeWeight tulajdonság is, mely szintén egy új entitás létrehozásakor kap szerepet. Az éleknek bár ugyanúgy lehet nevük, létrehozásukkor ez - alapértelmezett beállítások szerint - automatikusan üres karakterlánc lesz (egyedi unid értéket az élek is kapnak). Bár nevük elődefiniálása nem lenne túl gya- korlatias, a létrehozáskori élvastagság néhány esetben hasznos lehet (pl. ha tudjuk előre hogy a legtöbb él a hálózatban minimum dupla széles). Az utolsó két tulajdonság a tüzelési szabály (ns:FireRule) illetve a szimulációs „se- besség” (ns:SimulationTimeout). Előbbi értékei a következők lehetnek:

• Véletlen (RANDOM) • Egyedi azonosító (unid) szerint növekvő (ASC_UNID) • Egyedi azonosító (unid) szerint csökkenő (DESC_UNID) • Prioritás alapján működő (PRIORITY)

Értéke értelemszerűen a nem-determinisztikus tüzelések során lesz lényeges, számítástech- nikai modellek esetén a leggyakoribb a prioritásos működés, míg pl. háború szimulátorok során a véletlenszerű sem ritka. Az egyedi azonosító alapján történő tüzelés csak spe- ciálisan felépített hálózat kapcsán értelmezhető. A szimuláció sebessége valójában egy ezredmásodpercben megadott érték, mely futtatott szimuláció során két állapotváltás kö- zött mindenképpen eltelik. Nem minden globális tulajdonság szerkeszthető felhasználó által. A legfontosabb nem szerkeszthető elemek az integritás védelem mezői (CertificateSubject és LastModification- Date). Ezen kívül értelemszerűen az XXXGenNumber értékek is írásvédettek.

4.2. Globális események

A Petri háló dolgozatban definiált kiterjesztése szerint lehetőség van a hálózathoz globálisan eseményeket rendelni (4.3. kód). Az események kivétel nélkül mind azonos névtérhez tartoznak (http://event.petrinetwork.hu), de a tagek nevei eltérnek. Globális 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 72

esemény esetén az XML elem neve pe:Event, azonban majd későbbiekben látni fogjuk, hogy pl. topológia elemhez az XSD egyértelműsége miatt más nevet fog az XML-ben kapni ugyanezen szabályoknak megfelelő elem (pl. 4.7. kód). Hálózat esetén az esemény típusa a következők egyike lehet:

• Holtpont (DEADLOCK) • Ciklus (CYCLE) • Óraütés (TICK)

1 2 3 [..] 4 4.3. kód. Globális események XML modellje

Az eseményeket csak és kizárólag a nevük azonosítja (pe:name), mely szándékosan nem egyedi a korábban leírt indokok szerint (lásd. a 3.3.3. fejezetet).

4.3. Vizuális beállítások

A grafikai szerkesztő egyik erőssége a vizuális megjelenés sokszínűsége és definiálható- sága (4.4. kód). A legtöbb hálózaton megjelenő szín RGB értéke perzisztálásra kerül egy e célra definiált http://color.petrinetwork.hu névtér alatt (a beállítható színek a következők: alapértelmezett ecset színe (DefaultColor), megjelölt entitás színe (MarkColor), kijelölt entitás színe (SelectedColor), vizuális segítség során aktivált szín (HelpColor), állapot színe (StateColor), tüzelésre kész tranzíció színe (MarkAsReadyToFireColor) valamint az időzített tranzíció óra ikonjának színe (ClockColor).

1 2 3 [..] 4 7 Arial 8 10 9 10 11 [..] 12 4.4. kód. Vizuális beállítások XML modellje

Jelen állapot szerint minden egyes felirat egy meghatározott betűtípussal és mérettel jelenik meg. Ez az úgynevezett alapértelmezett betűtípus (DefaultFont) melyet az e célra létrehozott http://font.petrinetwork.hu névtér definiál. A betűtípus dekorációját (stílusát) is lehet árnyalni, erre ismét egy külön névtér létezik (http://fontstyle.petrinetwork.hu). Grafikai szerkesztés során két szituációban nyernek teret a korábban bemutott szín tulajdonságok: az ecsetek illetve a kitöltések színei kapcsán. A kitöltés tulajdonságai nem perzisztálhatóak (ilyen tulajdonság lehetne pl. a kitöltés stílusa), azonban az ecsetek vas- tagsága igen! Ennek megfelelően létezik egy http://pen.petrinetwork.hu névtér alá tartozó tag halmaz. A következő ecsetek vastagsága szerkeszthető: alapértelmezett ecset (Defa- ultPen), alapértelmezett él ecset (DefaultEdgePen), megjelölt elem ecsete (MarkPen), 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 73

kijelölt él ecsete (SelectedEdgePen), kijelölt topológia elem ecsete (SelectedItemPen), vi- zuális segítség ecsete (HelpPen), állapot ecsete (StatePen), állapotok közötti élek ecsete (StateEdgePen), tüzelésre kész tranzíciók ecsete (MarkAsReadyToFirePen) valamint az időzített tranzíciók óra ikonjának ecsete (ClockPen).

4.4. Láthatósági/megjelenítési beállítások

A grafikai sokszínűség szerves része az is, hogy a felhasználó tudja meghatározni, hogy milyen részletességgel szeretné a hálózaton az adatokat megjeleníteni. Ennek is két dimenziója van: lehetőség van globálisan, illetve elemenként definiálni a kiegészítő adatok megjelenését. Utóbbi hiányában ha csak bizonyos csoportba tartozó elemek információinak megjelenítésére lenne szükségünk, törölnünk kéne adatokat a hálózatból (pl. a megneve- zéseik törlése), mely nyilván egy nagyon kényelmetlen lehetőség volna.

1 2 3 [..] 4 4.5. kód. Láthatósági/megjelenítési beállítások XML modellje

A http://settings.petrinetwork.hu névtér alatti tagek határozza meg a grafikai elemek globális ki- illetve bekapcsolási lehetőségét (4.5. kód). Rendre a következő elemek megje- lenítése szabályozható globálisan: élek súlyai (EdgeWeight) és feliratai (EdgeLabel), an- notációk (Notes), méretező és mozgató segédkörök (EdgeHelpLine), pozíciók kapacitásai (Capacity) és feliratai (PositionLabel), tranzíciók prioritásai (Priority) és feliratai (Tran- sitionLabel), tüzelésre kész tranzíciók jelölése/nem jelölése (ReadyToFireTransitions) il- letve időzített tranzíciók óráinak megjelenítése (Clock). Megjegyzendő, hogy az élek súlya vizuálisan a jelölő vonal vastagsága segítségével mindenképpen látható.

4.5. Topológia

A pn:Network tag gyermekei (4.6. kód) definiálják a Petri hálózat topológiájának alapvető építőköveit, illetve annotációit (megjegyzéseit). Az ismertetett osztályhierarchi- ából (lásd. a 3.6.8. fejezet) az olvasható ki, hogy a pozíciók, tranzíciók és annotációk közös őssel rendelkeznek (AbstractNetworkItem osztály), ezzel szemben a perzisztált XML-ben bár a pozíciók és tranzíciók rendelkeznek közös szülő taggel (neit:NetworkItems), a meg- jegyzések nem ez alá, hanem közvetlenül a pn:Network alá tartoznak. Ennek oka, hogy minden egyes megjegyzés (i:Note) hivatkozik pontosan egy pozícióra, tranzícióra avagy élre, és a már említett szekvenciális feldolgozás végett a hivatkozott elemeknek már me- móriában kell lenniük (az osztály-hierarchia átalakítása ezen tudna segíteni, mely a Petri hálózatok API elkészültekor részben meg is valósult, lásd. 6.1. fejezet).

1 2 3 4 [..] 5 6 7 [..] 8 9 [..] 10 11 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 74

12 13 [..] 14 15 [..] 16 17 18 19 [..] 20 21 [..] 22 23 4.6. kód. Topológia XML modellje

A i:Position tagek (4.7. kód) attribútumai illetve gyermekei több különböző név- tér alá tartoznak. Ez javarészt utal a mögöttes osztályhierarchiára. A bi:name, bi:unid és bi:showannotation mind az AbstractItem osztályban deklarálódnak (az ezekhez tarto- zó XML névtér a http://baseitem.petrinetwork.hu), az i:radius attribútum és az i:Events gyermek elem pedig az AbstractNetworkItem osztályban (http://item.petrinetwork.hu név- tér). Ezekkel szemben a pos:capacitylimit attribútum és pos:Tokens gyermek elem mögött olyan tulajdonságok vannak (http://position.petrinetwork.hu névtér), melyekkel egyedül csak egy pozíció rendelkezhet. A pf (http://pointf.petrinetwork.hu névtér) illetve sf (http://sizef.petrinetwork.hu névtér) prefix-szel bevezetett gyermek elemek egy-egy kiemelt vektorgrafikai sarokpontot reprezentálnak. Pozíciók illetve tranzíciók esetén más-más elemek szerkeszthetőek, ezért a perzisztált modellben előfordul redundancia (pl. a sugár (i:radius) szinkronban van mind a szélességgel, mind a magassággal (sf:Size)). A pozíciók a rajtuk található tokenjátékosokat gyermek elemként tartalmazzák. Min- den Token példány (tok:Token tag) az AbstractItemből származik, innen eredeztethe- tőek az XML elem attribútumai. A játékos gyermeke a vizuális színét definiálja egy c:TokenColor tag segítségével (http://color.petrinetwork.hu névtér). Ehhez hasonlóan a pozíciók a rajtuk definiált eseményeket is gyermek elemként tartalmazzák (i:Events). A már bemutatott pe:Eventtel azonos pe:ItemEvent tag írja le a csatolt eseményeket, melyek a következők lehetnek:

• Aktiválás előtt (PREACTIVATE) • Aktiválás után (POSTACTIVATE)

1 2 3 4 5 6 7 8 9 10 [..] 11 12 13 14 [..] 15 16 4.7. kód. Pozíciók XML modellje 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 75

A pozíciók tárolási modelljének részletes leírása után az i:Transition tag (4.8. kód) kapcsán csupán a különbségeket érdemes kiemelni. Csak tranzíciókra jellemző tulajdonság a forgásszög (tra:angle) fokban megadva, a prioritás (tra:priority), a típus (tra:type), a késleltetés (tra:delay) és az utóbbi kapcsán opcionálisan megjeleníthető óra ikon mérete (tra:clockRadius). Mindezen elemek a http://transition.petrinetwork.hu névtér alá tartoz- nak. A definiálható események azonosak a pozíciónál látotthoz (tüzelés előtt illetve tüzelés után), a tranzíció típusa pedig a következők egyike lehet:

• Normál tranzíció (NORMAL) • Forrás tranzíció (SOURCE) • Nyelő tranzíció (SINK)

1 2 3 4 5 6 7 8 9 [..] 10 11 4.8. kód. Tranzíciók XML modellje

Miután a pozíciók és tranzíciók bevezetésre kerültek, definiálhatjuk a közöttük lévő éleket is (4.9. kód). Minden él egyben AbstractItem is, ezért névvel (bi:name), egyedi azo- nosítóval (bi:unid) és az adatai megjelenítéséhez kötődő kapcsolóval (bi:showannotation) rendelkezik. Csak az élekre jellemző tulajdonság a súly (edg:weight), az él típusa (edg:type), valamint a kezdő- (edg:Start) illetve végpontja (edg:End). Utóbbiak két gyermek elemként vannak definiálva. Az él egyértelműségét a hivatkozott entitások unid mezői garantálják. Az edg:reftype attribútum XML szinten redundáns adat. Amennyiben az él nem egye- nes vonal, hanem görbe, a köztes pont offset-jét a pf:CurveMiddlePointOffset gyermek határozza meg a vektorgrafikus ábrázolás során. Az offset a két végpont középpontjához képest értendő.

1 2 3 2 4 1 5 7 8 [..] 9 4.9. kód. Élek XML modellje

A megjegyzéseket leíró i:Note tagek (4.10. kód) egy egyedi attribútumot illetve egy egyedi gyermek elemet tartalmaznak (not:Text). Az not:attachedItem attribútum vala- mely pozíció, tranzíció avagy él unid mezőjére hivatkozik, ennek létezése a szekvenciális feldolgozás támogatása végett már garantált. 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 76

1 2 3 4 5 6 7 new note 8 9 [..] 10 4.10. kód. Annotációk XML modellje

4.6. Állapot-hierarchia

Az állapothierarchia modul nem csupán adatszinten, hanem vizuálisan is tárolja az állapotok közötti kapcsolatot (4.11. kód). Ezen hálózat egy másik gráfot definiál, mely- nek topológiája a Petri hálóhoz hasonlatosan tárolható XML-ben. Először a gráf sarok- pontjai, vagyis az állapotok vannak leírva (sh:States), majd ezeket követi az állapot- átmenetek halmaza (sh:Edges). Minden egyes állapotvektor (sv:StateVector) rendelkezik névvel (sv:name), egyedi azonosítóval (sv:unid), sugárral (sv:radius) és origóval (pf:StateOrigo). A token eloszlást egy erre szolgáló gyermek elem, az sv:TokenDistributions fogja össze. Minden egyes ilyen elem tartalmazza az összes pozíció hivatkozását (sv:Position), és ahol az adott állapotban token található, ott a játékosokét is (sv:Token). Az állapotokhoz ese- mények is csatolhatóak (sv:Events), a pe:StateEvent tag típusa a topplógiai elemekhez hasonlatosan PREACTIVATE illetve POSTACTIVATE lehet. Az se:StateEdge elemek mindegyikének két gyermek eleme van (se:StartState illetve se:EndState), melyek mindegyike egy-egy állapotra hivatkozik unid mezője segítségével.

1 2 3 4 5 6 7 8 [..] 9 10 [..] 11 12 13 14 [..] 15 16 17 18 19 20 31 21 28 22 23 [..] 24 25 4.11. kód. Állapot-hierarchia XML modellje 5. fejezet

Integritás védelem

Az irodalomkutatás részleteiben foglalkozott a titkosítás és hitelesítés tárgykörének alapvető elméleti hátterével (lásd. a 2.9. fejezetet a 25. oldalon), mely a Petri szimulációs alkalmazás XML kimeneti állományának hitelesítése végett lényeges a dolgozat számá- ra. Az aszimmetrikus titkosítás (lásd. 2.9.4. fejezet), azon belül is az RSA algoritmus (lásd. 2.9.5. fejezet) felhasználása a szabványos viselkedést, a kulcsgeneráláshoz felhasz- nált alkalmazások (Java Keytool és OpenSSL, lásd. 2.9.7. fejezet) pedig a kódbiztonságot garantálják. Ahhoz, hogy az alkalmazás felhasználói saját kulccsal rendelkezzenek, melyek mindegyike ezen szimulációs alkalmazáshoz használható legyen, szükséges egy Certificate authority „létrehozása” is (lásd. a 2.9.6. fejezet). A dolgozat szempontjából a technikai háttér megvalósítása érdekes csupán, ezért valós Certificate authority nem kerül regisztrálásra (ennek jelentős költsége is volna), csu- pán egy a dolgozat jelen fejezetében leírt CA szimulálása fog megvalósulni, szoftveres eszközökkel. A leírtak birtokában bárki képes lehet arra, hogy az alkalmazás által prog- ramozottan vizsgált CA tulajdonságoknak megfelelő hasonló CA-t létrehozzon, és ezáltal valós kulcsokat tudjon generálni a Petri szimulációs alkalmazás számára. Az így generált kulcsok ugyanúgy alkalmasak a PN.XML állományok hitelességének biztosítására, mint az „eredeti” CA-val létrehozottak. A fejezetben lépésről lépésre bemutatásra kerül az integritás védelemhez szükséges kulcsok és tanúsítványok létrehozása. Paraméterezhető BATCH állományok készültek a dolgozathoz, melyek elvégzik a Certificate authority szimulációját, új kulcsok generálását, tanúsítványok aláírását és szükségszerű cseréjüket a tárolási állományukban. Kezdő lépésként egy megfelelő Certificate authority létrehozása lesz szükséges. A CA valójában ugyanolyan kulcspár, mint a végfelhasználói kulcs(pár), azonban olyan speciális tanúsítvánnyal rendelkezik, melynek publikus adatai között szerepel egy kapcsoló, mely megengedi, hogy a CA ne csak pl. XML dokumentumok aláírására legyen képes, hanem más tanúsítványokat is aláírhasson. Hogy a kettő közötti különbség még szignifikánsabb legyen, általában a CA kulcsát úgy hozzák létre, hogy általános dokumentumokat ne, csak és kizárólag más tanúsítványokat tudjon aláírni! A dolgozat is ugyanezt a mintát fogja követni.

5.1. Root CA létrehozása

Bármely eszközzel is dolgozunk, ha létrehozunk/generálunk egy új aszimmetrikus titkosításra és hitelesítésre alkalmas kulcspárt, akkor egy úgynevezett self-signed kulccsal

77 5. FEJEZET. INTEGRITÁS VÉDELEM 78

fogunk rendelkezni. Ez - ahogy neve is utal erre - olyan tanúsítvánnyal rendelkezik, melyet „önmaga” írt alá. Tanúsítvány nem létezhet aláírás, vagyis integritás védelem nélkül, hiszen ki hinné el pár egymás után írt karakterről, hogy az tényleg a nevezett személy tulajdona, és nem pedig pár perce gépelte be valaki, aki vissza szeretne élni más nevével. Mivel a kulcsgenerálás pillanatában egyetlen kulcs van csak „kéznél”, mégpedig a most létrehozott, a tanúsítvány aláírása az éppen generált kulccsal fog megtörténni. Hogy egy kulcs megfelelő forrásból származik-e, a tanúsítványát aláíró másik kulcs hitelességétől függ, vagyis ez egyfajta bizalmi lánc, mely algoritmikusan védett. Ahhoz, hogy egy felhasználó megbízzon egy kulcs aláírásában, két dologra van szüksége: első lépésben a titkosítás nyilvános algoritmusa segítségével megbizonyosodik arról, hogy a kapott üzenet nem sérült (ez az autentikációs lépés (authentication)), második lépésben pedig megvizsgálja, hogy az aláíró személyében, avagy az ő tanúsítványának valamely aláírójában megbízik-e (ez az úgynevezett authorization). Utóbbi bizalmi láncnak szük- ségszerűen lesz egy forrás pontja, egy olyan kulcs, melynek tanúsítványát önmaga írta alá, vagyis self-signed. Ezt nevezik Root CA-nak, a fejezet is e kulcs létrehozásával indul.

1 s e t ␣ROOTCA_FILE_PREFIX=p e t r i r o o t c a 2 s e t ␣KEYS_DIR=.\ keys \ 3 s e t ␣ROOTCA_KEY_FILENAME=%ROOTCA_FILE_PREFIX%.key 4 s e t ␣ROOTCA_KEY_FILE=%KEYS_DIR%%ROOTCA_KEY_FILENAME% 5 %OPENSSL_HOME%\bin \ o p e n s s l ␣ genrsa ␣−des3 ␣−out ␣%ROOTCA_KEY_FILE%␣4096 5.1. kód. Root CA privát kulcs létrehozása

A Root CA létrehozása OpenSSL alkalmazással valósul meg (lásd. 5.1. kód). A genr- sa utasítással egy 4096 bit hosszú privát kulcsot hozhatunk létre. A futtatás során az OpenSSL bekéri a kulcsot védő jelszót (ez egy szimmetrikus kulcs, mellyel a bitsorozat állományát védi).

1 s e t ␣ROOTCA_KEY_PASSWORD=c h a n g e i t r o o t 2 s e t ␣OSSL_CONFIG=o p e n s s l . conf 3 s e t ␣ROOT_CERTS_DIR= . \ . . \ rootca \ c e r t s \ 4 s e t ␣ROOTCA_CERT_PEM_FILENAME=%ROOTCA_FILE_PREFIX%.pem . c e r 5 s e t ␣ROOTCA_CERT_PEM_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_PEM_FILENAME% 6 %OPENSSL_HOME%\bin \ o p e n s s l ␣ req ␣−c o n f i g ␣%OSSL_CONFIG%␣−new␣−x509␣− sha384 ␣−days ␣ 1826 ␣−key␣%ROOTCA_KEY_FILE%␣−passin␣pass:% ROOTCA_KEY_PASSWORD%␣−extensions␣x509v3_extensions␣−out ␣% ROOTCA_CERT_PEM_FILE% 5.2. kód. Root CA tanúsítványának létrehozása

A privát kulcs birtokában készíthetünk tanúsítványt a kulcshoz, mely a tanúsítvány publikus rekordjainak megadását és aláírását, valamint a kulcspár publikus felének cso- magolását jelenti. Mindehhez az OpenSSL req utasítását használhatjuk (lásd. 5.2. kód). Az utasítás paraméterben megkapja a tanúsítvány típusát (x509), az érvényesség idejét (5 év, vagyis 1826 nap), a privát kulcsot és a hozzá tartozó szimmetrikus kulcs jelszavát valamint a tanúsítvány kiterjesztéseit leíró tag nevét. Utóbbi egy openssl.conf állományra hivatkozik (lásd. 5.3. kód). A létrehozott kulcs tanúsítványára jellemző lesz, hogy ő egy CA (CA:true), mely 3 mélységig biztosítja azt, hogy az általa aláírt certificate-ek hitelesek (pathlen:3 ). A kulcs csak és kizárólag más tanúsítványok aláírására lesz használható, dokumentumokat nem tud titkosítani, avagy hitelesíteni (keyUsage=keyCertSign, cRLSign). 5. FEJEZET. INTEGRITÁS VÉDELEM 79

1 [␣x509v3_extensions␣] 2 basicConstraints=critical ,CA:true ,pathlen:3 3 keyUsage=keyCertSign ,␣cRLSign 4 subjectKeyIdentifier=hash 5 authorityKeyIdentifier=keyid , issuer 5.3. kód. X509v3 kiterjesztések (openssl.conf állomány)

A tanúsítvány létrehozásakor az OpenSSL be fogja kérni a nyilvános rekordok érté- keit. Ezek legyenek az alábbiak:

• E, E-mail address = [email protected] • CN, CountryName = Petri Universitas Budensis Root CA • OU, OrganizationalUnitName = NIK • O, OrganizationName = UNI-OBUDA • L, LocalityName = Budapest • S, StateOrProvinceName = Hungary • C, CountryName = HU

1 s e t ␣ROOTCA_CERT_DER_FILENAME=%ROOTCA_FILE_PREFIX%. der 2 s e t ␣ROOTCA_CERT_DER_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_DER_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l ␣x509␣−in ␣%ROOTCA_CERT_PEM_FILE%␣−inform ␣ PEM␣−out ␣%ROOTCA_CERT_DER_FILE%␣−outform␣DER 5.4. kód. Root CA tanúsítványának konvertálása

A létrejött tanúsítvány PEM formátumban lesz. A szélesebb körű felhasználás érde- kében az OpenSSL x509 utasításával DER formátumra konvertálhatjuk (lásd. 5.4. kód). Ezt felhasználva létre tudunk hozni TrustStore-t JKS formátumban, a Java keytool pa- rancssori alkalmazása segítségével (lásd. 5.5. kód). A TrustStore szabadon terjeszthető nyilvános csatornákon. Birtokában a hitelességet vizsgáló fél az authorization lépéseit végre tudja hajtani, amennyiben természetesen a TrustStore-ban szereplő tanúsítványban feltétel nélkül megbízik.

1 s e t ␣ROOTCA_CERTSTORE_PASSWORD=changeit 2 s e t ␣ROOTCA_ALIAS=rootca 3 s e t ␣STORE_DIR=.\ s t o r e \ 4 s e t ␣ROOTCA_CERTSTORE_FILENAME=%ROOTCA_FILE_PREFIX%. j k s 5 s e t ␣ROOTCA_CERTSTORE=%STORE_DIR%%ROOTCA_CERTSTORE_FILENAME% 6 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−k e y s t o r e ␣%ROOTCA_CERTSTORE%␣− s t o r e p a s s ␣%ROOTCA_CERTSTORE_PASSWORD%␣−a l i a s ␣%ROOTCA_ALIAS%␣− f i l e ␣ %ROOTCA_CERT_PEM_FILE%␣−noprompt␣−trustcacerts 5.5. kód. Root CA TrustStore-jának előállítása

A most bemutatott lépések során sikeresen létrehoztunk egy self-signed Root CA-t, mely elsősorban tanúsítványok aláírására lesz használható. A tanúsítvány Subject, illetve Issuer (kibocsátó) mezeje is „Petri Universitas Budensis Root CA” lett, kellően hosszú, 5 éves élettartamra érvényesítettük, Root CA lévén önmagával. 5. FEJEZET. INTEGRITÁS VÉDELEM 80 5.2. Sub CA létrehozása

A Root CA birtokában immáron alá tudnánk írni végfelhasználó tanúsítványokat, azonban mindez nem volna túl elegáns lépés. A CA szimulációja során az életszerűségre törekvés jegyében egy úgynevezett Sub CA létrehozásával folytatjuk. A Sub CA nagyon hasonló tulajdonságokkal fog rendelkezni, mint a Root CA. Elsősorban ő is csupán ta- núsítványok aláírására lesz alkalmas, dokumentumokéra nem, és publikus adatai között jelezve lesz a CA szerepkör. Érvényességi ideje kicsit kevesebb lesz, és ami a legfontosabb, tanúsítványát az 5.1. fejezetben létrehozott Root CA fogja aláírni, vagyis nem self-signed lesz.

1 s e t ␣SUBCA_FILE_PREFIX=p e t r i s u b c a 2 s e t ␣SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%.key 3 s e t ␣SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% 4 %OPENSSL_HOME%\bin \ o p e n s s l ␣ genrsa ␣−des3 ␣−out ␣%SUBCA_KEY_FILE%␣4096 5.6. kód. Sub CA létrehozása

A Sub CA létrehozására szintén az OpenSSL parancssori utasításai lesznek felhasz- nálva. Generálás után első körben self-signed kulcs fog keletkezni (lásd. 5.6. kód). A privát kulcs generálását követően a Sub CA-nak is szüksége van egy ideiglenes self-signed tanúsítványra. A tanúsítvány tartalmazza a javasolt publikus adatokat, érvé- nyességi időt és x509v3 kiterjesztéseket. Mikoron a Root CA a tanúsítványt aláírja, ezen adatok egy részét megváltoztathatja (pl. az érvényességi időt, illetve kiterjesztéseket).

1 s e t ␣ROOT_CSR_DIR= . \ . . \ rootca \ c s r \ 2 s e t ␣SUBCA_CSR_FILENAME=%SUBCA_FILE_PREFIX%. c s r 3 s e t ␣SUBCA_CSR_FILE=%ROOT_CSR_DIR%%SUBCA_CSR_FILENAME% 4 s e t ␣SUBCA_KEY_PASSWORD=changeitsub 5 s e t ␣SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%.key 6 s e t ␣SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% 7 %OPENSSL_HOME%\bin \ o p e n s s l ␣ req ␣−c o n f i g ␣%OSSL_CONFIG%␣−new␣−days ␣ 1096 ␣ −sha384 ␣−key␣%SUBCA_KEY_FILE%␣−p a s s i n ␣ pass :%SUBCA_KEY_PASSWORD%␣− extensions␣x509v3_extensions␣−out ␣%SUBCA_CSR_FILE% 5.7. kód. Certificate Signing Request állomány létrehozása

A Sub CA tanúsítványa hason módon a Root CA-hoz, az OpenSSL req utasításával fog elkészülni (lásd. 5.7. kód). Fontos különbség a -x509 kapcsoló hiánya a parancsban. En- nek hiányában nem valós tanúsítvány, hanem csupán egy úgynevezett Certificate Signing Request (CSR) állomány készül. E CSR állományt el kell juttatni az aláíró Root CA-hoz, hogy elkészülhessen a valós, aláírt tanúsítvány. Az OpenSSL a tanúsítvány publikus adatait be fogja kérni. Használjuk a következő- ket: • E, E-mail address = [email protected] • CN, CountryName = Petri Universitas Budensis Sub CA • OU, OrganizationalUnitName = NIK • O, OrganizationName = UNI-OBUDA • L, LocalityName = Budapest • S, StateOrProvinceName = Hungary • C, CountryName = HU 5. FEJEZET. INTEGRITÁS VÉDELEM 81 5.3. Sub CA tanúsítványának aláírása

A Sub CA CSR állományát - akár publikus csatornán - el kell juttatni a Root CA-hoz. A Root CA ennek birtokában el tudja készíteni a Sub CA aláírt tanúsítványát. Mindehhez az OpenSSL ca utasítását használhatjuk (lásd. 5.8. kód).

1 s e t ␣SUBCA_CERT_PEM_FILENAME=%SUBCA_FILE_PREFIX%.pem . c e r 2 s e t ␣SUBCA_CERT_PEM_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_PEM_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l ␣ ca ␣−c o n f i g ␣%OSSL_CONFIG%␣−k e y f i l e ␣% ROOTCA_KEY_FILE%␣−p a s s i n ␣ pass :%ROOTCA_KEY_PASSWORD%␣−c e r t ␣% ROOTCA_CERT_PEM_FILE%␣−in ␣%SUBCA_CSR_FILE%␣␣−extensions␣ x509v3_extensions␣−md␣ sha384 ␣−out ␣%SUBCA_CERT_PEM_FILE% 5.8. kód. Sub CA tanúsítványának aláírása

A RootCA openssl.conf állományában meghatározott tulajdonságok szerint az aláírt tanúsítvány érvényességi ideje egy év lesz (default_days=365), a kulcs pedig elsősorban tanúsítványok aláírására lesz használható (Key usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06)). A tanúsítvány PEM formátumban készül el.

1 s e t ␣SUBCA_CERT_DER_FILENAME=%SUBCA_FILE_PREFIX%. der 2 s e t ␣SUBCA_CERT_DER_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_DER_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l ␣x509␣−in ␣%SUBCA_CERT_PEM_FILE%␣−inform ␣PEM ␣−out ␣%SUBCA_CERT_DER_FILE%␣−outform␣DER

4

5 s e t ␣SUBCA_ALIAS=subca 6 s e t ␣SUBCA_CERTSTORE_PASSWORD=changeit 7 s e t ␣SUBCA_CERTSTORE_FILENAME=%SUBCA_FILE_PREFIX%. j k s 8 s e t ␣SUBCA_CERTSTORE=%STORE_DIR%%SUBCA_CERTSTORE_FILENAME% 9 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−k e y s t o r e ␣%SUBCA_CERTSTORE%␣− s t o r e p a s s ␣%SUBCA_CERTSTORE_PASSWORD%␣−a l i a s ␣%SUBCA_ALIAS%␣− f i l e ␣% SUBCA_CERT_DER_FILE%␣−noprompt␣−trustcacerts

10

11 s e t ␣SUBCA_CERTPATHSTORE_FILENAME=%SUBCA_FILE_PREFIX%.path . j k s 12 s e t ␣SUBCA_CERTPATHSTORE=%STORE_DIR%%SUBCA_CERTPATHSTORE_FILENAME% 13 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−k e y s t o r e ␣%SUBCA_CERTPATHSTORE %␣−s t o r e p a s s ␣%SUBCA_CERTSTORE_PASSWORD%␣−a l i a s ␣%ROOTCA_ALIAS%␣− f i l e ␣%ROOTCA_CERT_PEM_FILE%␣−noprompt␣−trustcacerts 14 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−k e y s t o r e ␣%SUBCA_CERTPATHSTORE %␣−s t o r e p a s s ␣%SUBCA_CERTSTORE_PASSWORD%␣−a l i a s ␣%SUBCA_ALIAS%␣− f i l e ␣%SUBCA_CERT_DER_FILE%␣−noprompt␣−trustcacerts 5.9. kód. Sub CA tanúsítványának aláírása

A certificate-et az aláíró visszajuttatja a Sub CA-hoz. A továbbiakban a publikus tanúsítvány terjesztését mind a Sub CA, mind a Root CA (kérésre) megteheti. A koráb- ban a Root CA kapcsán bemutatott konverziós és TrustStore létrehozási lépések a Sub CA esetében is elkészíthetőek (lásd. 5.9. kód). TrustStore-ból lehet egy olyat készíteni, melyben csupán a Sub CA tanúsítványa van, illetve egyet, melyben az őt aláíró Root CA certificate-je is szerepel. A Sub CA létrehozása ezzel befejeződött. A tanúsítvány Subject mezője „Petri Uni- versitas Budensis Sub CA” lett, azonban az Issuer az aláírás során automatikusan felvette az aláíró CN-jét: „ Petri Universitas Budensis Root CA”. Az immáron nem self-signed Sub 5. FEJEZET. INTEGRITÁS VÉDELEM 82

CA továbbra sem használható a PN.XML állományok hitelesítésére, azonban alkalmas lesz arra, hogy aláírjon e célra létrehozott tanúsítványokat.

5.4. Végfelhasználói kulcs generálása

A végfelhasználói kulcs létrehozásának lépései sok hasonlóságot fognak mutatni a Sub CA során bemutatottakkal. A self-signed kulcs generálása ezúttal Java Keytool se- gítségével készül el (ezzel is mutatva, hogy az eszköz lényegtelen, a mögöttes nyilvános algoritmusok számítanak). Ezt mutatja be az 5.10. kód.

1 s e t ␣KEYALG=RSA 2 s e t ␣KEYSIZE=1024 3 s e t ␣SIGALG=SHA1withRSA 4 s e t ␣END_ALIAS=p e t r i 5 s e t ␣END_FILE_PREFIX=uniobuda 6 s e t ␣END_KEYSTORE_FILENAME=%END_FILE_PREFIX%_private . j k s 7 s e t ␣END_KEYSTORE=%OUTPUTDIR%%END_KEYSTORE_FILENAME% 8 s e t␣CERT_CN=Universitas␣Budensis 9 s e t ␣CERT_OU=NIK 10 s e t ␣CERT_O=UNI−OBUDA 11 s e t ␣CERT_L=Budapest 12 s e t ␣CERT_S=Hungary 13 s e t ␣CERT_C=HU 14 s e t ␣END_KEYSTORE_PASSWORD=c h a n g e i t s t o r e 15 s e t ␣END_PRIVATEKEY_PASSWORD=p e t r i p a s s

16

17 %KEYTOOL_HOME%\bin \ k eytool ␣−genkeypair␣−keyalg ␣%KEYALG%␣−k e y s i z e ␣% KEYSIZE%␣−s i g a l g ␣%SIGALG%␣−a l i a s ␣%END_ALIAS%␣−k e y s t o r e ␣% END_KEYSTORE%␣−dname␣"CN=%CERT_CN%,␣OU=%CERT_OU%,␣O=%CERT_O%,␣L=% CERT_L%,␣S=%CERT_S%,␣C=%CERT_C%,␣EmailAddress=%CERT_E%−"␣s t o r e p a s s ␣%END_KEYSTORE_PASSWORD%␣−keypass ␣%END_PRIVATEKEY_PASSWORD% 5.10. kód. Végfelhasználói kulcs generálása

Az elkészült kulcspár tanúsítványát alá kell iratni a Sub CA-val. Ehhez szükséges a már részletezett Certificate Signing Request (CSR) állomány elkészítése. Ugyancsak Java Keytool segítségével ennek előállítását mutatja be az 5.11. kód.

1 s e t ␣END_FILE_PREFIX=uniobuda 2 s e t ␣END_CSR_FILENAME=%END_FILE_PREFIX%. c s r 3 s e t ␣END_CSR_FILE=%SUB_CRL_DIR%%END_CSR_FILENAME%

4

5 %KEYTOOL_HOME%\bin \ k eytool ␣−c e r t r e q ␣−a l i a s ␣%END_ALIAS%␣−k e y s t o r e ␣% END_KEYSTORE%␣− f i l e ␣%END_CSR_FILE%␣−storepass␣% END_KEYSTORE_PASSWORD%␣−keypass ␣%END_PRIVATEKEY_PASSWORD% 5.11. kód. Végfelhasználói tanúsítvány CSR állományának létrehozása

5.5. Végfelhasználói kulcs tanúsítványának aláírása

Miután valamely, akár publikus csatornán, a végfelhasználói tanúsítvány CSR állo- mánya el lett juttatva a Sub CA felé, a certificate aláírása megtörténhet. Ehhez hasonlóan 5. FEJEZET. INTEGRITÁS VÉDELEM 83

a Sub CA tanúsítványának Root CA általi aláírasakor már bemutaott Open SSL ca uta- sítását használhatjuk (lásd. 5.13. kód).

1 [␣x509v3_extensions_nonca␣] 2 basicConstraints=critical ,CA:false 3 keyUsage=digitalSignature ,␣nonRepudiation ,␣keyEncipherment 4 extendedKeyUsage=serverAuth ,␣clientAuth ,␣codeSigning ,␣emailProtection ,␣timeStamping 5 subjectKeyIdentifier=hash 5.12. kód. Sub CA által aláírt végfelhasználó tanúsítványok kiterjesztései (openssl.conf)

Az aláírás során a tanúsítvány kiterjesztései azonban mások lesznek, ezeket a Sub CA openssl.conf állománya írja le (lásd. 5.12. kód). Kritikus, vagyis minden körülmények között figyelembe veendő kiterjesztése a végfelhasználói tanúsítványnak, hogy nem CA (CA:false), vagyis nem használható authorization-re. A keyUsage kiterjesztésében ennek megfelelően nem lesz felsorolva más tanúsítványok aláírásának lehetősége, azonban doku- mentumok digitális aláírása és a kulcs csere (pl. SSL/TLS kapcsolat felépítése) szerepelni fog (keyUsage=digitalSignature, nonRepudiation, keyEncipherment).

1 s e t ␣END_LONG_CERT_PEM_FILENAME=%END_FILE_PREFIX%. long . pem . c e r 2 s e t ␣END_LONG_CERT_PEM_FILE=%END_OUTPUT_DIR%% END_LONG_CERT_PEM_FILENAME%

3

4 %OPENSSL_HOME%\bin \ o p e n s s l ␣ ca ␣−p o l i c y ␣%SUBCA_POLICY%␣−c o n f i g ␣% OSSL_CONFIG%␣−c e r t ␣%SUBCA_CERT_PEM_FILE%␣−in ␣%END_CSR_FILE%␣− k e y f i l e ␣%SUBCA_KEY_FILE%␣−days ␣720␣−md␣ sha384 ␣−passin␣pass:% SUBCA_KEY_PASSWORD%␣−out ␣%END_LONG_CERT_PEM_FILE% 5.13. kód. Végfelhasználói tanúsítvány aláírása Sub CA által

Befejező lépésként a Sub CA által létrehozott tanúsítványt be kell importálni a Ja- va keystore-ba. Ezzel a lépéssel a már benne lévő self-signed certificate ki lesz cserélve. Azonban az importálást nem lehet addig végrehajtani, amíg a keystore-ban a bizalmi lánc nem ellenőrizhető (ez a JKS egyik előnyös tulajdonsága). Mindehhez szükség van a Sub CA tanúsítványának importálására, melynek pedig a Root CA tanúsítványára. Ebből kö- vetkezik a sorrendiség: először a Root CA, majd a Sub CA, végül pedig a Sub CA által aláírt végfelhasználói tanúsítvány importálása a feladat (lásd. 5.14. kód).

1 s e t ␣END_TMP_CERT_PEM_FILENAME=%END_FILE_PREFIX%.tmp . pem . ce r 2 s e t ␣END_TMP_CERT_PEM_FILE=%OUTPUTDIR%%END_TMP_CERT_PEM_FILENAME%

3

4 %OPENSSL_HOME%\bin \ o p e n s s l ␣x509␣−in ␣%END_LONG_CERT_PEM_FILE%␣−out ␣% END_TMP_CERT_PEM_FILE% 5 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−a l i a s ␣%ROOTCA_ALIAS%␣− f i l e ␣% ROOTCA_CERT_PEM_FILE%␣−k e y s t o r e ␣%END_KEYSTORE%␣−storepass␣% END_KEYSTORE_PASSWORD%␣−noprompt 6 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−a l i a s ␣%SUBCA_ALIAS%␣− f i l e ␣% SUBCA_CERT_DER_FILE%␣−k e y s t o r e ␣%END_KEYSTORE%␣−storepass␣% END_KEYSTORE_PASSWORD%␣−noprompt 7 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−a l i a s ␣%END_ALIAS%␣− f i l e ␣% END_TMP_CERT_PEM_FILE%␣−k e y s t o r e ␣%END_KEYSTORE%␣−storepass␣% END_KEYSTORE_PASSWORD%␣−keypass ␣%END_PRIVATEKEY_PASSWORD% 5.14. kód. Végfelhasználói tanúsítvány konvertálása és csomagolása 5. FEJEZET. INTEGRITÁS VÉDELEM 84

Miután a keystore elkészült, a Java keytool és az Open SSL segítségével néhány további műveletet még elvégezhetünk: DER formátumú tanúsítvány exportálása, PEM formátumú konverziója, PKCS12 keystore előállítása, illetve truststore létrehozása (lásd. 5.15. kód).

1 s e t ␣END_CERT_DER_FILENAME=%END_FILE_PREFIX%. der 2 s e t ␣END_CERT_DER_FILE=%OUTPUTDIR%%END_CERT_DER_FILENAME% 3 s e t ␣END_CERT_PEM_FILENAME=%END_FILE_PREFIX%.pem . c e r 4 s e t ␣END_CERT_PEM_FILE=%OUTPUTDIR%%END_CERT_PEM_FILENAME% 5 s e t ␣END_PKCS12_PASSWORD=c h a n g e i t s t o r e 6 s e t ␣END_CERTSTORE_PASSWORD=changeit

7

8 %KEYTOOL_HOME%\bin \ k eytool ␣−exportcert␣−k e y s t o r e ␣%END_KEYSTORE%␣− s t o r e p a s s ␣%END_KEYSTORE_PASSWORD%␣−a l i a s ␣%END_ALIAS%␣− f i l e ␣% END_CERT_DER_FILE% 9 %OPENSSL_HOME%\bin \ o p e n s s l ␣x509␣−in ␣%END_CERT_DER_FILE%␣−inform ␣DER␣− out ␣%END_CERT_PEM_FILE%␣−outform␣PEM 10 %KEYTOOL_HOME%\bin \ k eytool ␣−importkeystore␣−s r c k e y s t o r e ␣%END_KEYSTORE %␣−d e s t k e y s t o r e ␣%END_PKCS12%␣−srcstoretype␣JKS␣−deststoretype␣ PKCS12␣−s r c s t o r e p a s s ␣%END_KEYSTORE_PASSWORD%␣−deststorepass␣% END_PKCS12_PASSWORD%␣−s rc ke yp as s ␣%END_PRIVATEKEY_PASSWORD%␣− s r c a l i a s ␣%END_ALIAS%␣−d e s t a l i a s ␣%END_ALIAS%␣−noprompt 11 %KEYTOOL_HOME%\bin \ k eytool ␣−importcert␣−k e y s t o r e ␣%END_CERTSTORE%␣− s t o r e p a s s ␣%END_CERTSTORE_PASSWORD%␣−a l i a s ␣%END_ALIAS%␣− f i l e ␣% END_CERT_DER_FILE%␣−noprompt␣−trustcacerts 5.15. kód. Végfelhasználói tanúsítvány konvertálása és csomagolása

5.6. Integráció a Petri szimulátorral

Miután elkészültek a Certificate authority szimulálására alkalmas kulcspárok és adat- bázisok (OpenSSL file alapú adatbázist készít), valamint néhány végfelhasználói certifica- te, készen állunk ezek felhasználására a Petri szimulációs alkalmazásban. Két különálló tevékenységre bontható a kulcsok és a tanúsítványok beépítése. Az egyik feladat a program indulásakori, illetve menüből aktiválható bejelentkezési folyamat, a másik pedig a hálózatok megnyitásakor a jogosultság ellenőrzése.

5.6.1. Bejelentkezési folyamat

Bejelentkezés során a felhasználónak ki kell tallóznia egy PKCS12 formátumban el- mentett keystore állományt, valamint meg kell adnia az állományt védő szimmetrikus kulcs jelszavát. Sikeres bejelentkezés csak akkor következik be, ha:

• A keystore PKCS12 formátumban van • A keystore tartalmaz private kulcsot • A kulcs tanúsítványa érvényes, vagyis kibocsátási ideje múltbeli, lejárati ideje pedig jövőbeli • A tanúsítvány X509v3-mas tanúsítvány 5. FEJEZET. INTEGRITÁS VÉDELEM 85

• A tanúsítvány kibocsátója a korábban létrehozott Sub CA ([email protected], CN=Petri Universitas Budensis Sub CA, OU=NIK, O=UNI-OBUDA, S=Hungary, C=HU ) • A tanúsítvány alias-a (FriendlyName) ”petri”.

A bejelentkezés során beírt jelszót az alkalmazás nem tárolja el sehol, nem aján- ja fel következő belépésékor. Sikeres belépést követően az MDI keret ablak fejlécében a tanúsítvány subject mezője lesz látható, valamint a létrehozott illetve megnyitott háló- zatok menthetőek lesznek. Mentés során a PN.XML állomány automatikusan integritás védelmet kap, valamint CertificateSubject és LastModificationDate mezői a megfelelő ér- téket felveszik (ezen mezők is alá lesznek írva). Érvényes kulccsal alá lehet írni más által létrehozott hálózatot is, amennyiben azt sikeresen meg tudtuk nyitni.

5.6.2. Megnyitási folyamat

A Petri szimulációs alkalmazásban csak olyan hálózatokat nyithatunk meg, melyek integritás védelmét ellenőrizni tudjuk. Az ellenőrzés automatikus, csupán a program in- dulását megelőzően az általunk ismert hálózat készítők PKCS12 formátumú truststore állományát a telepítési könyvtár ”truststore” mappjába kell elhelyeznünk. A program indulásakor ezen könyvtár tartalmát beolvassa, és minden benne lévő tanúsítványon a következő ellenőrzéseket végzi el:

• A truststore PKCS12 formátumban van • A truststore nincs szimmetrikus kulccsal védve (avagy jelszava üres) • A truststore tartalmaz pontosan egy tanúsítványt • A tanúsítvány érvényes, vagyis kibocsátási ideje múltbeli, lejárati ideje pedig jövőbeli • A tanúsítvány X509v3-mas tanúsítvány • A tanúsítvány alias-a (FriendlyName) ”petri”.

Amennyiben valamely tanúsítvány nem megy át a fenti ellenőrzésen, erről az alkal- mazás konzolja tájékoztatást ad. A konzol adatai állományba menthetőek (helyi menü- ből), és esetleg elküldhető a tanúsítvány tulajdonosának (pl. tájékoztathatja arról, hogy a tanúsítványa lejárt). Amennyiben megnyitunk egy korábban készített hálózatot, az alkalmazás ellenőrzi, hogy a hálózat aláírójában megbízunk-e, vagyis felépíti a bizalmi láncot. Ha a folyamat sikeres, a hálózat megnyílik, lehetőségünk van módosítani, illetve lefuttatni a szimulációt. A Petri szimulációs alkalmazás egy grafikus truststore böngészőt is tartalmaz, mely- ben a program indulásakor elérhető érvényes certificate-ek részletes adatai olvashatóak. 6. fejezet

Modell alkalmazása OO környezetben

A szimulációs alkalmazás támogatásával létrehozott és PN.XML formátumban ki- mentett Petri háló bár önállóan is használható (szimulációra, oktatásra, prezentációra), jelen dolgozat elsődlegesen nem egy ilyen célkitűzés köré épül. A modellben regisztrálha- tó események halmaza egy önálló Petri háló kiterjesztés építőköveit jelentik. Események a hálózat különböző pontjain keletkezhetnek (a keletkezés helye és ideje gyakorlatilag meghatározza a típusát), azonosításuk pedig egy egyszerű karakterlánccal valósul meg. Mindezekről korábban már részletesen szó volt (lásd. 2.10. Irodalomkutatás tanulsága fe- jezet a 33. oldalon, 3.3.3. Események modul fejezet az 50. oldalon, 3.6.10. Petri események fejezet a 64. oldalon illetve 4.2. Globális események fejezet a 71. oldalon). Annak érdekében, hogy a modellt módosítás/transzformáció nélkül fel lehessen hasz- nálni egy tetszőleges objektum-orientált alkalmazásban, a következő lépések szükségesek:

• A hálózat topológia adatait be kell tudni olvasni memóriába (PN.XML állomány megnyitása) • Azon vizuális adatokat, megjelenítési beállításokat, melyek csak és kizárólag a szi- mulációs alkalmazás számára fontosak, figyelmen kívül lehet hagyni • A memóriában leképzett topológiát a megnyitó alkalmazás kizárólag olvasásra tudja használni. Nincs lehetőség a modell memóriában történő bővítésére, módosítására1. • A megnyitott hálózat tüzelését programozottan kell tudni léptetni.

Mindezen lépések arra vezettek, hogy egy programozói API (Application Programming Interface) készüljön a szimulációs alkalmazás forrását felhasználva.

6.1. Petri hálózat API bemutatása

Az API egy különálló library (.NET DLL) formájában készül el. Forrásának jelentős része a Petri szimulációs alkalmazásból származik, azonban attól több ponton eltér. Az osztály-hierarchia áttervezése egy szükségszerű iterációs lépés volt a fejlesztés során. Az API mellőz mindenféle vizuális funkcionalitást, a szimulációs alkalmazásban alkalmazott

1 Ez alól kivételt képez a Petri események utólagos regisztrálási lehetősége. Ezzel a módosítással azonban a hálózat topológiája, viselkedése semmilyen formában nem fog változni.

86 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 87 osztály-hierarchia azonban több ponton éppen a vizualitás kapcsán szeparálja a felelősségi köröket. Másik lényeges különbség a .NET specifikus internal láthatóság alkalmazása, mely a DLL szintjén nyilvános, a felhasználó alkalmazás számára azonban elérhetetlen műveleteket jelent2.

6.1.1. Topológia és egyéb építőkövek osztályai

Az áttervezett osztályhierarchiából (lásd. 6.1. ábra) kikerültek azon abstract osztá- lyok3, melyeknek egyetlen leszármazottja volt csupán. Mivel az API-ban szereplő osztályok felelősségi köre kisebb, mint a szimulátorban használt változatuké, ezért az absztrakció már nem indokolt. Lényeges különbség az AbstractNetworkItem felelősségi körének vál- tozása. A szimulátorban ez az osztály fogta össze azon grafikai elemeket, melyek élekkel voltak összekötve, gyakorlatilag melyek topológiát alkottak: Note, Position és Transition osztályok. Az új hierarchiában az osztály az AbstractEventDrivenItem nevet kapta, utal- va a felelősségi körére: azon osztályok őse, melyek Petri eseményeket tartalmazhatnak. Az osztály ezen kívül statisztikát is vezet. Három leszármazott osztálya van: Position, Transition és StateVector.

6.1. ábra. Petri hálózat API áttervezett osztályhierarchiája

A Petri hálózat API kívülről leginkább a nyilvános tulajdonságain keresztül érhető el, szinte kivétel nélkül csak olvasásra. Ahogy azt a 6.2. és a 6.3. ábrán megfigyelhetjük, minden lényeges információ kinyerhető az osztályok példányaiból:

• Egy Token vissza tudja adni színét • Egy Él vissza tudja adni súlyát, típusát és végpontjait • Egy Megjegyzés/Annotáció vissza tudja adni szövegét illetve hogy milyen elemhez tartozik • Egy Pozíció vissza tudja adni kapacitását, tokenjei listáját és darabszámát • Egy Tranzíció vissza tudja adni késleltetését, prioritását és típusát • Egy Állapotvektor vissza tudja adni teljes tokeneloszlását

2 Ennek segítségével nincs szükség interface-ek definiálására. Amennyiben az API Java nyelven is elkészülne, hasonló viselkedést elegáns módon interface-ek segítségével tudnánk megvalósítani (ke- vésbé elegáns, de működő megoldás volna a package hierarchia trükkös felépítése is). 3 Név szerint kikerült a hierarchiából az AbstractToken, AbstractNote, AbstractPosition és az Abst- ractTransition osztály. 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 88

6.2. ábra. Élek, tokenek és jegyzetek osztálydiagramjai

Minden AbstractEventDrivenItem képes visszaadni eseménytörzsét (EventTrunk), melyen keresztül új események regisztrálása is lehetséges, valamint a leszármazottjáról tá- rolt statisztikai adatokat. Az AbstractEventDrivenItem osztály őse az AbstractItem, mely csupán az egyedi azonosítóját és a szabad szöveges elnevezését tárolja egy példánynak.

6.1.2. Petri hálózat osztálya

Az új osztály-hierarchia és a felelősségi körök lehetővé teszik a Petri hálózatok osztá- lyának az újratervezését is (lásd. 6.4. ábra). Egyrészről az AbstractNetwork osztály felesle- gessé válik, másrészről a teljesítmény okokból szeparáltan kezelt topológiai elemek és élek külön listája az új hierarchiában egyesülni tud! A háttérben List-ként egységesen tárolt elemek külön szeparált tulajdonságok segítségével kérhetőek vissza: Ed- ges, Positions és Transitions. Ugyancsak nevesített tulajdonság létezik a tokenjátékosok visszaadására is (Tokens), mely a pozíciók miatt gyakorlatilag ugyanezt a listát dolgozza fel. Magának a hálózatnak is van eseménytörzse, és természetesen vissza tudja adni a nem grafikához köthető attribútumait (CertificateSubject, Description, FileName, FireRule, LastModificationData, Name). 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 89

6.3. ábra. Pozíciók, Tranzíciók és Állapotvektorok osztálydiagramjai

6.4. ábra. Petri hálózatok új osztálya

Kettő, csak az API-ben létező új tulajdonság is helyet kapott az új PetriNetwork osztályban. Az egyik képes visszaadni a hálózatban előforduló összes állapot nevét (Sta- tesName), a másik pedig az összes egyedi (!) esemény nevét. Utóbbi metódus használata kézenfekvő: az API segítségével programozottan megnyitott hálózatból kikérjük az ese- 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 90 mények neveit, majd azokhoz objektum-orientált értelemben vett eseménykezelőket ren- delünk! Annak elemzésére, hogy az esemény neve mögött milyen szituáció feleltethető meg, a szimulátor alkalmazás alkalmasabb, bár az eseményvezérelt elemek bejárásával az API-en keresztül is felderíthető. A tranzíció tüzelést, vagyis a tokenjátékot a hálózat osz- tálya a szimulátorban használt változatból átemelte, azt módosítás nélkül tartalmazza. A hálózat példányának fire() elnevezésű metódusát meghívva egy tranzíció tüzelése ját- szódik le. A metódus egy FireReturn elnevezésű osztály példányával tér vissza, melyből kinyerhető egy FireEvent enum értéke. Ennek segítségével kideríthető a következő tüzelés meghívásának szükségessége. Lehetséges értékei: INITFIRE, NORMALFIRE, RESET- FIRE illetve DEADLOCK. Utóbbi esetben egyértelműen nincs értelme a fire() metódust ismét meghívni, a RESETFIRE visszatérési érték pedig egy ciklusra utal, vagyis egy olyan állapotvektor állt elő az utolsó tüzelés hatására, mely már korábban előfordult (ez nem jelenti azt, hogy innentől bizonyosan ciklikusság fog következni, hiszen a hálózat műkö- dése nem-determinisztikus). A visszatérési értékből a hálózat állapotára nézve semmilyen lényeges információval nem rendelkezünk, a FireReturn példányából a FireEventen kívül a tüzelő tranzíció referenciáját kapjuk még meg. Ez az API szándékos viselkedése.

6.1.3. Eseményvezérlés osztályai

6.5. ábra. Eseményvezérlés osztályai

Annak érdekében, hogy a Petri események objektum-orientált környezetbe tényle- gesen beépüljenek, programozott kapcsolatot kell kialakítani a már meglévő EventTrunk által összefogott PetriEvent osztály példányai, és majdan az API segítségével regiszt- rált (csatolt) eseménykezelők között. A kapcsolatot a PetriHandler képviselő, illetve a PetriNetwork osztályában tárolt privát Dictionary típusú mező fogja biztosítani! Utóbbi kulcs-érték párokat tartalmazó Dictionary példány kulcsként az egyedi Petri események nevét, értékként pedig magát a PetriHandlert fogja tárolni. Az értékekhez nem biztos hogy tartozik eseménykezelő, de ha igen, akkor azok meghívását a tokenjáték tüzelés közben fogja meghívni (checkHandler() metódus). A hálózat példányá- nak szintjéről a bindPetriEvent() és az unbindPetriEvent() metódusok segítségével tudja 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 91

az API-t felhasználó programozó a kapcsolatot regisztrálni/megszüntetni (részletesebben lásd. 6.1. kód).

1 p u b l i c delegate void PetriHandler(AbstractEventDrivenItem item , EventType eventType); 2 3 p u b l i c class PetriNetwork : System.Object 4 { 5 [..] 6 p r i v a t e Dictionary handlers; 7 [..] 8 p u b l i c List EventsName 9 { 10 [..] 11 } 12 [..] 13 p u b l i c void bindPetriEvent(string eventName, PetriHandler handler) {[..]} 14 p u b l i c void unbindPetriEvent(string eventName, PetriHandler handler) {[..]} 15 [..] 16 p r i v a t e PetriHandler getPetriEventByName(string eventName) {[..]} 17 p r i v a t e PetriHandler getPetriEventByTrunk(List events) {[..]} 18 [..] 19 p r i v a t e void checkHandler(AbstractEventDrivenItem item , EventType eventType) 20 { 21 List events = item.EventTrunk.getEventsByType(eventType); 22 PetriHandler handler = getPetriEventByTrunk(events); 23 i f (handler != null) 24 { 25 handler(item , eventType); 26 } 27 } 28 [..] 29 } 6.1. kód. Eseményvezérlés háttere

A képviselő által meghatározott esemény aláírása lehetőséget ad a felhasználónak arra, hogy az eseményt kiváltó AbstractEventDrivenItem példányát elemezze az esemény- kezelőben (a pontosabb azonosítás végett az aláírás tartalmazza az esemény típusát is).

6.2. Petri hálózat API felhasználása

Egy API-t akkor tekintünk megfelelőnek, ha felhasználása egyszerű és egyértelmű. Ha valamit rosszul használ a programozó, akkor arról értelmes értesítést kapjon, és termé- szetesen ne lehessen inkonzisztens állapotot előidézni (ez utóbbi követelmény egy helyesen tervezett objektum-orientált alkalmazásban nem jöhet szóba). A Petri hálózat API is pon- tosan erre törekszik. Néhány egyszerű utasítás segítségével memóriába fogjuk tudni tölteni a hálózatot, össze fogjuk tudni rendelni a Petri eseményeket saját eseménykezelőinkkel, és le fogjuk tudni játszani a szimulációt programozottan.

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 Random rand = new Random ( ) ; 4 PetriNetwork network = PetriNetwork.openFromXml(rand , @"networks\Demo.pn.xml"); 6.2. kód. Hálózat megnyitása

A legelső lépés a Petri hálózat megnyitása (lásd. 6.2. kód). Ehhez a PetriNetwork osztály statikus openFromXml() metódusát tudjuk felhasználni. A file elérési útvonala mellett egy véletlenszám generátort is át kell adnunk. Utóbbit tovább adjuk a létrehozandó Petri példánynak (nem volna szerencsés ha a generátor inicializálását az API végezné el). A statikus metódus visszatér egy PetriNetwork példánnyal. Nem létező állomány esetén a metódus null-t fog visszaadni, illetőleg ha a PN.XML állományt szabálytalanul (az 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 92

XSD-nek nem megfelelő módon) módosították, akkor XML validációs kivételek fognak keletkezni. Az API nem vizsgálja a hálózat integritás védelmét! Ennek oka, hogy a már elkészült hálózat beépítésével a felhasználó alkalmazás érvényességi idejét is korlátoznánk a TrustStore-ban lévő tanúsítvánnyal. Ahhoz, hogy bármilyen eseményvezérelt interakciót létrehozzunk, szükségünk lesz eseménykezelőkre. Az eseménykezelő aláírását a PetriHandler delegate definiálja, erre láthatunk egy példát a 6.3. kódban. A paraméterben kapott AbstractEventDrivenItem runtime típusát lekérdezve biztonságos castolást tudunk végrehajtani, majd így az ese- ményt kiváltó entitás bármely aktuális tulajdonságát/statisztikáját lekérdezhetjük. Ha az adott entitásra több különböző eseményt is hozzárendeltünk, az EventType típusú para- méterrel tudjuk azonosítani hogy épp melyik hajtódott végre (pl. PREACTIVATE vagy POSTACTIVATE).

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 p r i v a t e static void eventHandler(AbstractEventDrivenItem item , EventType eventType) 4 { 5 StringBuilder sb = new StringBuilder(100); 6 sb . Append ("eventHandler(item:" + item.Name +", eventType:"+eventType+")"); 7 i f (item is Position) 8 { 9 Position position = (Position)item; 10 sb . Append (" token count:" + position.TokenCount); 11 } 12 System.Console.WriteLine(sb.ToString()); 13 } 6.3. kód. Eseménykezelő

Miután elkészítettük a szükséges eseménykezelőt, és ismerjük a modellben névvel azonosított Petri eseményt, melyhez ezt hozzá kívánjuk kötni, áttérhetünk az objektum- orientált kapcsolat létrehozására. A hálózat példányának bindPetriEvent() metódusa se- gítségével megadjuk a Petri esemény nevét, majd létrehozunk egy PetriHandler típusú eseménykezelőt a korábban (6.3. kód) bemutatott eseménykezelőt felhasználva (lásd. 6.4. kód). Amennyiben adott névvel nem létezik Petri esemény, ArgumentExceptiont fog dobni a metódus4.

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 t r y 4 { 5 network. bindPetriEvent("dummy", new PetriHandler(eventHandler)); 6 } 7 catch (ArgumentException e) 8 { 9 System.Console.WriteLine(e.Message); 10 } 6.4. kód. Névvel adott esemény regisztrálása

Az API az események regisztrálását dinamikus formában is el tudja végezni, ezzel lehetőség nyílik arra hogy olyan alkalmazások készüljenek, ahol a PN.XML állomány kül- ső, ismeretlen forrásból származik (így a forráskód nem tud a Petri esemény nevéről). Ehhez mindössze a hálózat példányának EventsName tulajdonságát kell használni, mely visszadja azon egyedi események neveit, melyek a hálózatban léteznek (lásd. 6.5. kód). Az

4 A Petri események neveit alapvetően a modellező eszközben tudjuk felhasználóbarát módon vizs- gálni, amennyiben persze a modellt meg tudjuk nyitni a megfelelő certificate birtokában. Utóbbi hiányában sem nehéz API-tól független módon kideríteni, hiszen a PN.XML állomány ember szá- mára is könnyen értelmezhető. 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 93

így visszakapott listát feldolgozhatjuk és a Petri eseményeket egy a célnak megfelelő álta- lános eseménykezelőhöz rendelhetjük. A 6.5. kód példát mutat arra is, hogy ugyanahhoz a Petri eseményhez több eseménykezelő is feliratkozhat.

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 List listOfEvents = network.EventsName; 4 foreach (String item in listOfEvents) 5 { 6 network. bindPetriEvent(item , new PetriHandler(eventHandler)); 7 network. bindPetriEvent(item , new PetriHandler(eventHandler2)); 8 } 6.5. kód. Összes esemény regisztrálása

Miután a megnyitás és az események összerendelése megtörtént, készen állunk a tokenjáték lejátszására. Ezt megtehetjük külön szálban, akár futva hagyni a szálat egy végtelen ciklusban, avagy az aktuális szálban a tüzeléseket egymás után meghívva (lásd. 6.6. kód). A fire() metódus visszatérési értékét felhasználhatjuk egy esetleges DEADLOCK vagy ciklikusság detektálására. DEADLOCK esetén a szimulációt nincs értelme tovább futtatni, ilyen esetben érdemes a külön szálban indított szimulációt is befejezni.

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 FireEvent fireEvent = FireEvent.INITFIRE; 4 FireReturn fireReturn = null; 5 while (! FireEvent .DEADLOCK. Equals(fireEvent)) 6 { 7 fireReturn = network. fire(); 8 System.Console.WriteLine(fireReturn); 9 fireEvent = fireReturn.FireEvent; 10 } 6.6. kód. Tokenjáték lejátszása 7. fejezet

Eredmények bemutatása

A Petri háló szimulátor alkalmazás alapvető használati esetei kerülnek bemutatás- ra a fejezetben, azonban a teljes funkcionalitást lefedő felhasználói kézikönyv ismertetése nem célja a dolgozatnak. Kezdeti lépésként a bejelentkezés és a TrustStore bemutatá- sán keresztül elindítjuk a szimulátort, ezt követően létrehozunk egy hálózatot, mely során megvizsgáljuk milyen kényelmi funkciók állnak rendelkezésünkre szerkesztés közben. Végül elindítunk egy szimulációt és elemezzük a futás eredményét. Kitérünk az egyes modulok használataira, és kiemelten foglalkozunk a Petri események regisztrálásának és monitoro- zásának lehetőségeire.

7.1. Bejelentkezés

Az alkalmazás indulást követően egy bejelentkezési képernyővel fogad (lásd. 7.1. áb- ra), melyen lehetőségünk van kiválasztani valamely háttértárról a titkos kulcsunkat tar- talmazó PKCS12 formátumú állományt. Az ilyen állományok egy szimmetrikus kulccsal (jelszóval) védettek, melynek megadása szintén kötelező. Enter billentyű avagy a hason nevű nyomógomb segítségével a bejelentkezési folyamat elindul, mely során a kulcs vali- dálásra kerül. Amennyiben nincs birtokunkban titkos kulcs, a bejelentkezési ablakot ESC billentyűvel, avagy a „Nincs kulcsom” nyomógombbal zárjuk be. Az alkalmazás utóbbi esetben is elindul azzal a korlátozással, hogy nem tudjuk a létrehozott hálózatot elmen- teni.

7.1. ábra. Bejelentkezés a szimulátor alkalmazásba

94 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 95

Idegen forrásból származó Petri hálózatokat csak abban az esetben tudunk megnyit- ni, ha a hálózat aláírójának tanúsítványával rendelkezünk az alkalmazás telepítési helyén megtalálható „truststore” könyvtárban. Az indulást követően a szimulátor megvizsgálja a könyvtárban lévő összes PKCS12 formátumú állományt, és validálja azokat, keresve a megfelelő tanúsítványokat. Ha hibát észlel bármely állomány kapcsán, akkor az alkalmazás naplójában erről a felhasználó tájékoztatást kap. Futás közben az [Eszközök | TrustStore] menüpontjából előhozhatjuk a sikeresen beolvasott tanúsítványok listáját. Bármely soron duplán kattintva a certificate részletes adatait is megtekinthetjük (lásd. 7.2. ábra).

7.2. ábra. TrustStore böngészése

7.2. Új hálózat létrehozása

A [Fájl | Új | Petri hálózat (Ctrl+N)] menüre kattintva létrehozhatunk egy új hálóza- tot. Akkor is megtehetjük ezt, ha nem rendelkezünk megfelelő titkos kulccsal a mentéshez. Az ablakon (lásd. 7.3. ábra) megjelenő valamennyi adatot módosíthatjuk még a későb- biekben, azonban érdemes a megjelent adatokat inicializálni. A hálózat grafikus kiterje- dése mellett többek között megadhatjuk az automatikusan generált elnevezések prefixeit, avagy a szimuláció sebességét (simulation timeout). A hálózat neve alapértelmezés sze- rint a „pn__” mintára épül, ahol a a tanúsítvány úgynevezett DN nevének (Distinguished Name) CN részét (Common Name) tartalmazza white-space mentes formában, a pedig egy egyszerű sorszám. Tit- kos kulcs hiányában a CN helyett „anonymous” jelenik meg. A hálózat sikeres létrehozását követően egy üres munkalapot fogunk kapni (lásd. 7.4. ábra). A hálózat összes beállítási lehetőségét a főképernyő bal oldalán a Tulajdonságok lapon találjuk. Az alkalmazás ezen része helyzetfüggően mindig az éppen kijelölt elem, avagy ennek hiányában a hálózat tulajdonságait és eseményeit tartalmazza. Ahhoz, hogy a szerkesztést érdemben elkezdjük, szükségünk van a Petri paletta modul megjelenítésére. 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 96

7.3. ábra. Új hálózat létrehozása

Ehhez navigáljunk a [Nézet | Eszköztárak | Petri paletta (Alt+Shift+P)] menüpontra, és kapcsoljuk be. Az eszköztárak állandóan elérhetőek, csupán a láthatóságukat állítjuk a menük segítségével. Az összes egyidejű megjelenítéséhez nagy felbontás javasolt, azonban egy közös kényelmi szolgáltatás révén mindegyik ablak áttetszőségét szabadon állíthat- juk. Az alkalmazást bezárva az a munkafelület, melyet a felhasználó otthagy, következő látogatásakor visszatöltődik1. Utóbbi hatás az operációs rendszer felhasználójához kötött, és nem a program indulásakor megadott tanúsítványhoz. A hálózat szerkesztő ablakában opcionálisan rácsháló, úgynevezett vezető grid jele- níthető meg. Az [Eszközök | Beállítások] menüpontban definiálható a rácsháló sűrűsége, a megjelenítését pedig a [Nézet | Rácsháló megjelenítése] menüpontban tudjuk aktiválni. Ide kapcsolódó funkcionalitás a [Nézet | Rácshoz igazítás] is, mely bekapcsolás esetén minden elhelyezett/átmozgatott topológia elemet a legközelebbi rácsháló metszésponthoz fog letenni.

7.3. Létező hálózat megnyitása

Egy korábban szerkesztett avagy idegen forrásból kapott hálózat megnyitását a fel- használó a [Fájl | Megnyitás (Ctrl+O)] menüpontjában kezdeményezheti. A megfelelő PN.XML állomány kiválasztását követően az alkalmazás azonnal megvizsgálja az integri- tás védelmét. Ismeretlen kulcssal aláírt, avagy alá nem írt hálózat megnyitása sikertelen lesz, a sikertelenségről a konzol ablakban a felhasználó tájékoztatást kap. A konzol ablak helyi menüből szöveges állományba menthető (illetve ugyanitt törölhető is), és szükség esetén elküldhető hibakeresés céljából pl. a hálózat készítőjének (a felhasználó számára egy hibaüzenet, mely szerint a TrustStore-ban lévő tanúsítvány már lejárt nem biztos hogy értelmezhető, azonban a hálózat készítője ebből láthatja, hogy új certificate-et kell kiállítania, és elküldenie a felhasználói számára). A megnyitott hálózattal egy időben minden látható eszköztár is frissülni fog (lásd. 7.5. ábra), betöltve illetve megjelenítve a kapcsolódó információkat. Az alkalmazás úgyne-

1 A munkafelület jellemzői a következők: főablak és az eszköztárak mérete és pozíciója, az alkalmazás beállításai, illetve a nyitva hagyott eszköztárak listája. 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 97

7.4. ábra. Új hálózat szerkesztés közben vezettt MDI keret jellegzetessége miatt egyidőben több hálózat is megnyitható, azonban az eszköztárak egyszerre csak egy (az aktuális) adatait tudják megjeleníteni. A hálózat szerkesztési ablakának aktuális állapotát a [Fájl | Exportálás | Képként (*.png)] menü- pontban bármikor kimenthetjük. Ez a funkcionalitás annak is adott, aki nem rendelkezik titkos kulccsal. Minden Petri hálózat gyermek ablaka rendelkezik három tab füllel (lásd. 7.6. ábra). Az elsőn látható maga a hálózat szerkesztési módban, a másodikon az aktuális állapotnak a PN.XML forrása (nem a már korábban mentett állomány forrása ez, hanem az aktuális szerkesztett állapoté), míg az utolsón a hálózat leírását olvashatjuk illetve szerkeszthetjük. Utóbbi valójában egy egyszerű karakteres szerkesztő felület. A PN.XML forrás közvetlenül nem írható, a hálózatot szerkeszteni csak a grafikus interface segítségével tudjuk. Az alkalmazás bezáráskor a sikeresen megnyitott hálózatok elérési adatait elmenti egy XML állományba, mely a telepítési könyvtárban található (recentfiles.xml). A program következő indulásakor ezt az állományt előveszi, és amennyiben a hálózat még mindig ugyanazon az elérési úton található, beépíti a [Fájl | Utoljára megnyitott állományok] közé. Az itt látható almenük buborék súgó formájában megmutatják a hálózat utolsó módosítójának nevét, idejét és leírását is, valamint CTRL + segítségével akár azonnal is elérhetőek (prezentáció során így gyakorlatilag egy előre beállított környezet pillanatok alatt előállítható).

7.4. Modulok

A Petri szimulációs alkalmazás üzleti értékének jelentős részét a modulokban tárolja. Itt van lehetőség az elkészült hálózat szimulálási eredményeinek vizsgálatára, a statiszti- 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 98

7.5. ábra. Létező hálózat megnyitása

7.6. ábra. Szerkesztő ablak három állapota kák elemzésére és a különféle exportálások elvégzésére.

7.4.1. Petri paletta

A hálózat alapvető topológiájának kialakításához nélkülözhetetlen az úgynevezett Petri paletta eszköztár (lásd. 7.7. ábra), mely a [Nézet | Eszköztárak | Petri paletta (Alt+Shift+P)] menüpontban avagy a gyorsikonok közül érhető el. Ez az eszköztár rendel- kezik az összes olyan elemmel, melyre a hálózat szerkesztéséhez szükségünk lesz. Számos 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 99 kényelmi funkció került beépítésre a paletta eszközei mögé, mely első ránézésre nem biztos hogy feltűnik a felhasználónak. A Paletta modul tetszőlegesen átméretezhető, az ikonok az átméretezett ablakhoz igazítva több sorban is meg tudnak jelenni.

7.7. ábra. Petri paletta modul

A hálózat szerkesztését általában egy pozíció avagy egy tranzíció elhelyezésével kezd- jük. Válasszuk ki valamelyik eszközt, látni fogjuk hogy a Paletta adott funkciógombja be- nyomódik. Ez jelzi az aktuálisan kiválasztott eszközt, azonban nem csupán ez: ha a szer- kesztő felületre visszük az egeret, akkor észrevehetjük hogy az egér mutatója a kiválasztott eszköznek megfelelően megváltozik. Ez a hatás majd az összes eszközre igaz a palettán, nem csupán a topológiai elemeknél, hanem a kijelölési/törlési/mozgatási eszközöknél is utal az egér mutatója az aktuális eszközre. Elképzelhető, hogy van olyan felhasználó, akit ez a hatás idegesít, ezért az [Eszközök | Beállítások] menüpontban kikapcsolható. A topológia kialakítását rendkívüli mértékben gyorsítja az él rajzolási (!) eszköz. He- lyezzünk el a szerkesztő felületen egyetlen pozíciót avagy tranzíciót, majd válasszuk ki az él rajzolás eszközét. Kezdjük el kijelölni az él kiindulási pontját, annak tudatában, hogy még nincs a hálózatban végpont, melyhez köthetnénk. Ahol az él végpontját elképzeljük, engedjük el az egér bal gombját. Ha ezt egy üres területen hajtottuk végre, automatikusan elhelyez az alkalmazás egy új elemet (pozíciót avagy tranzíciót), pontosan az ellentettjét az él kiindulási pontjának. Természetesen ha egy már létező elemhez irányítjuk az élt, akkor nem fog létrejönni új elem, hanem a kapcsolat felépül a két korábban létrehozott elem között. Érvénytelen topológiát nem tudunk kialakítani, az alkalmazás nem enged két egyforma elemet összekötni, sőt figyel a forrás illetve nyelő tranzíciók helyes viselkedésére is. Mikor az él kiindulási pontját kijelöljük, az összes lehetséges végpont alapértelmezés szerint zöld színnel (hálózat szintjén definiálható) megjelölődik, ezzel segítve a tájékozó- dást. Bár apróság, hasznos lehet, hogy ha egy élt olyan két pont között definiálunk, ahol már létezik kapcsolat, akkor új él kirajzolása helyett automatikusan a már létező él súlyát növeli meg egyel az alkalmazás! Ha a két topológiai elem között bár van él, de ellentétes irányú, akkor pedig az új él automatikusan görbülettel jön létre, segítve a tájékozódást a későbbiekben. Pozíciók, tranzíciók és megjegyzés elemek elhelyezésekor az alkalmazás figyel arra, hogy ne lehessen két elemet véletlenül egymáshoz túl közel elhelyezni. Ha észleli a közeli elemet, akkor nem fedi el azt egy új elemmel, hanem kijelöli a már létezőt, felhívva a figyelmét a felhasználónak. A kijelölés nem fogja a kijelölés eszköz kiválasztását is trigge- relni. Pozíción, tranzíción, megjegyzésen avagy élen az egérrel duplán klikkelve egy felugró auto fókuszos ablakban a tétel feliratát tudjuk begépelni, illetve módosítani. A pozíciók és tranzíciók feliratának offsetje tetszés szerint beállítható, az élek esetén pedig az élre felfeküdve jelenik meg a felirat, külön ügyelve arra hogy véletlenül se legyen fejtetőn, illetve jobbról balra kiírva. A megjegyzést az él eszközzel tudjuk pontosan egy pozícióhoz, tranzícióhoz avagy élhez kötni. A kötést szaggatott vonal fogja jelezni. 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 100

A mozgató/átméretező eszköz kapcsán érdemes pár apróságot észrevenni. Az eszköz egyrészt alkalmas bármely nem él elem drag&drop típusú mozgatására, valamint az ele- mek átméretezésére. Az átméretezést az elemek sarkát „megfogva” tudjuk elvégezni. A speciális pontok alapértelmezés szerint kis szürke körök formájában láthatóak az eszköz használata során (más eszköznél ezen segéd jelzések nem láthatóak). Nem csupán az ele- mek, hanem azok felirata is átmozgatható ugyanezen eszközzel. A szürke kör itt is látható a felirat közepe körül. Fontos tudni, hogy a felirat mozgatása csupán az offsetjét változ- tatja, a kapcsolódó elem átmozgatásával a felirat követni fogja. Az élek esetén a felirat mozgatása nem lehetséges, azonban minden élt egy ponton meg tudunk görbíteni. Ehhez egy egyenes élt bárhol megfogva „húzzuk” meg a méretező eszköz segítségével. Miután si- keresen elgörbítettük az élt, a görbítést már csak a görbületben lévő segédponttal tudjuk módosítani, illetve az ilyen élt csak így tudjuk kijelölni is (egyenes élt az egyenes mentén bárhol). Kétféle kijelölési eszköz létezik: az egyszerű nyíllal több elem egyidejű kijelölése és együttes szerkesztése lehetséges, míg a „kézfejjel” jelzett eszköz az egyes elemek egye- di specifikációjakor hasznos, ugyanis itt egyidejűleg csupán egyetlen elem lehet kijelölve. Többszörös kijelölés esetén tudunk - az egérrel egy adott téglalapot leírva - több elemet egyidőben kijelölni. A kijelölt elemek típusa a háttérben megvizsgálásra kerül, és a tulaj- donságlapon olyan szerkesztési lehetőségek jelennek meg, melyek minden kijelölt elemre érvényesek lehetnek. Ennek megfelelően más-más tulajdonság lapot kapunk ha csak po- zíciókat, avagy ha pozíciókat és tranzíciókat is kijelöltünk. Ha több elem van kijelölve, és valamely kijelölt elemet mozgatjuk át a mozgatási eszközzel, akkor minden kijelölt elem el fog mozdulni pontosan az átmozgatott elem mozgatási offsetjének megfelelően. Ha arra van szükségünk, hogy több elem azonos X avagy Y koordinátán helyezkezdjen el, akkor egyszerűen jelöljük ki őket, és meg fog jelenni a tulajdonság lapon a célnak megfelelő igazítási eszköz! Ha csak egy elem van kijelölve, akkor természetesen annak minden adata megjele- nik, és az összes szerkeszthető tulajdonságot módosítani tudjuk. A teljesség igénye nélkül pl. minden elem esetén egyesével meghatározhatjuk, hogy megjelenjen-e a felirata avagy sem (sőt, ezt globálisan is állíthatjuk a hálózat tulajdonságai között). Állíthatjuk egy pozíció sugarát közel tetszőleges mértékben (egy ésszerű minimum és maximum érték között), valamint meghatározhatjuk kapacitás korlátját. Utóbbi tulajdonság zárójelben megjelenik a pozíció felirata mögött. Egyedül a pozícióknál nyer értelmet a tulajdonság lap Tokenjátékosok tab füle, melyen látható és szerkeszthető a pozíció összes játékosa. Egy Token kapcsán a neve illetve színe határozható meg, illetve a tulajdonságlapról egy konkrét példány törölhető is (a token törlő eszköz nem meghatározható módon egyesével törli a játékosokat). Tranzíciók kapcsán az általános dolgok mellett beállítható a tranzí- ció forgási szöge, a prioritása, típusa (normál, nyelő avagy forrás) és időzítése. Prioritása megjelenik a feliratában, időzítése esetén pedig egy kis óra ikon jelenik meg egy szintén meghatározható helyen (ennek is külön offsetje van, mint a feliratnak). Ha élt jelölünk ki, akkor a tulajdonság lapon lehetőségünk van egy gombnyomásra irányát megfordítani2, avagy kiegyenesíteni, ha görbített. Természetesen alaptulajdonságai között beállítható az él vastagsága is.

2 Természetesen itt is figyelembe van véve az a speciális eset, mikor a kapcsolatban forrás avagy nyelő tranzíció vesz részt. 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 101

7.4.2. Állapot mátrix

A [Nézet | Eszköztárak | Állapot mátrix (Alt+Shift+S)] menüpont segítségével je- leníthető meg az Állapot mátrix modul (lásd. 7.8. ábra). Ezen modul irányítja a hálózat tüzeléseit és a szimulációt is! A tüzelés ikonjára kattintva léptethetjük a hálózatot. A tokenjáték folyamata részletesen naplózásra kerül az alkalmazás konzoljára. Minden ál- lapotban alapértelmezés szerint vörös színnel kiemelve láthatóak azon tranzíciók, melyek tüzelésre képesek. Ha több ilyen tranzíció is van, akkor a tüzelés a tüzelési szabálynak megfelelően fog végrehajtódni (véletlenszerű, prioritásos, unid szerint növekvő avagy csök- kenő). A tüzelési szabály a modul ablakából elérhető beállítási ablakon módosítható (lásd. 7.8. ábra). Ugyanitt tudjuk beállítani a szimuláció sebességét is, mely akkor nyer szerepet, ha az automata szimulációt elindítjuk a „lejátszás” ikon segítségével. A szimuláció ennek hatására egy külön szálon elindul, minden lépésben visszaszinkronizálva az eredményt a szerkesztő felületre. A térkép modul kivételével a többi modul ez esetben nem frissül automatikusan (teljesítmény okokból).

7.8. ábra. Állapot mátrix modul

Az Állapot mátrix modul által előállított állapot mátrix képként, szöveges illetve LATEX formátumban is kimenthető. A modul ablakában bármely állapotra kattintva az adott állapotra lehet ugrani, gyakorlatilag betöltve/visszaállítva az adott szituációt. Ha a tüzelés során ciklus keletkezik, akkor a visszatérő állapot automatikusan kijelölődik. Az ezt követő állapotok ekkor még láthatóak lesznek, azonban ha még egy tüzelést végrehajtunk, akkor a nem-determinisztikus működés miatt az állapot mátrix jövője törlődik.

7.4.3. Állapot-hierarchia

A [Nézet | Eszköztárak | Állapot-hierarchia (Alt+Shift+H)] menüpontból elérhe- tő Állapot-hierarchia modul (lásd. 7.9. ábra) szoros együttműködésben van az Állapot mátrix-szal. Az állapotok egy külön irányított gráfba szerveződve jelennek meg az állapot- hierarchia modulban. Ha egy olyan állapot vektor alakul ki, mely korábban még nem létezett, akkor egy véletlen helyen fog itt megjelenni az új állapot, generált névvel. Az állapotok drag&drop módszerrel helyezhetőek tetszőleges pozícióba, irányítottságuk ter- mészetesen nem módosítható, azonban helyi menüből kiválasztható mindegyik állapot tulajdonság lapja, ahol nevük, méretük, pozíciójuk és eseményeik is szerkeszthetőek! Az Állapot-hierarchiára is jellemző az, hogy bármely állapotot kijelölve a hálózat automati- kusan a kiválasztott állapotra ugrik, visszatöltve gyakorlatilag az akkori tokeneloszlást. Az Állapot-hierarchia képként kimenthető, illetve grafikai szélessége és magassága beállítható a modul ikonsorában elérhető tulajdonság lapon keresztül. Az állapotok mind- addig memóriában maradnak (illetve a PN.XML kimenet részeit fogják képezni), amíg a 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 102

7.9. ábra. Állapot-hierarchia modul hálózat topológiája nem változik meg! Abban a pillanatban, hogy egy új kapcsolat, avagy új topológiai elem kerül fel a hálózatra, a teljes állapot halmaz törlődik, minden korábban beállított információval együtt.

7.4.4. Szomszédossági mátrix

A Szomszédossági mátrix (lásd. 7.10. ábra) a [Nézet | Eszköztárak | Szomszédossá- gi mátrix (Alt+Shift+N)] menüpont segítségével hozható elő. Kimenete automatikusan íródik, szerkesztési lehetőségünk itt nincsen. A tab fülek segítségével külön vizsgálhatjuk a kimenő, illetve a bemenő élek szerepét a szimulációra, illetve a mátrixokat ki tudjuk menteni képként, szöveges illetve LATEX formátumban.

7.10. ábra. Szomszédossági mátrix modul

7.4.5. Statisztika és Tranzíció történet

A [Nézet | Eszköztárak | Statisztika (Alt+Shift+T)] illetve [Nézet | Eszköztárak | Tranzíció történet (Alt+Shift+R)] menüpontban érhetjük el a Statisztika és a Tranzíció történet modulokat. A Statisztika modulban (lásd. 7.11. ábra) listában láthatjuk az ak- tuális hálózat összes pozícióját, tranzícióját és állapotát (ezen elemekre vezet statisztikát a szimulátor). Valamely tételt kijelölve elemezhetjük az elem aktivitását. Pozíciók esetén azt is láthatjuk, hogy mi volt a legtöbb illetve legkevesebb tokenszám vele kapcsolatban, 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 103 illetve ezek átlagát is kiszámolja a program. Lehetőségünk van a kiválasztott, avagy az összes elem statisztikáját nullázni a megfelelő vezérlő gombok segítségével.

7.11. ábra. Statisztika modul

A Tranzíció történet modulban (lásd. 7.12. ábra) időrendben láthatjuk a tüzelő tran- zíciókat, illetve zárójelben a tüzelés során a tranzíción keresztülhaladó tokenjátékosok neveit! A modulba bekerülő adatokat a vezérlő ikon segítségével lehet törölni, azonban már bekövetkezett bejegyzések nem fognak változni, és ez egy szándékos viselkedés! Ha a tranzíciókat avagy a tokenjátékosokat átnevezzünk, töröljük, akkor is megmaradnak eredeti nevükön és tulajdonságaikkal a Tranzíció történet modulban. A listában bármely elemre kattintva, amennyiban az még létezik, kijelölődik a hálózatban egyedüli elemként. Fontos tudni, hogy a tranzíció történet nem kerül perzisztálásra!

7.12. ábra. Tranzíció történet modul 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 104

7.4.6. Petri események

A Petri események modul a [Nézet | Eszköztárak | Petri események (Alt+Shift+E)] menüpontból érhető el, és csupán arra alkalmas, hogy áttekintést adjon a hálózatban regisztrált összes Petri eseményről (lásd. 7.13. ábra). Két listát láthatunk az eszköz hasz- nálata során. A bal oldaliban az összes egyedi elnevezésű Petri esemény látható, míg a jobb oldaliban a bal oldalon kijelölt esemény előfordulási helyei listázódnak.

7.13. ábra. Petri események modul

A Petri eseményeket két helyen tudjuk szerkeszteni: a főablak bal oldali Tulajdonság szerkesztőjének utolsó „Események” fülén a kijelölési szituáció függvényében a hálózat, a pozíciók illetve a tranzíciók eseményeit, míg az Állapot-hierarchia modulban az egyes álla- potok helyi menüből elérhető tulajdonság lapján az állapotok eseményeit regisztrálhatjuk. A regisztrálás során megadott nevek automatikusan „trim”-elődnek, illetve white-space- eik „_”-ra lesznek cserélve. A Petri események a szimulációs alkalmazásban semmilyen hatást nem váltanak ki, szerepük a Petri hálózatok API-ét felhasználó programok kapcsán értelmezett csupán (részletesebben lásd. a 6. fejezetben).

7.5. Lóverseny

Dolgozatom végén egy gyakorlati példával támasztanám alá az elkészült szimulá- tor és Petri hálózat API felhasználásának lehetőségeit. Üzleti igényünk legyen az, hogy egy lóverseny első három helyezettjét szeretnénk sorrendben visszakapni. Legegyszerűbb megoldás imperatív nyelvekben megvalósítva valamilyen ál-véletlen szám generátor alkal- mazása volna, azonban ez semennyire sem modellezné a valóságot. Esetleg lehetne színezni a versenyben résztvevő lovak korábbi eredményeinek tudatában a véletlen szerepét, de ez még mindig független volna a valós versenypályán előforduló szituációktól, nem beszélve arról, hogy a számítás menete nagyrészt áttekinthetetlen volna. Milyen alternatív ötletek jöhetnek szóba? Először is próbáljuk meg megfogalmazni azt, hogy milyen hatások (akár véletlenek) érhetik a lovakat illetve versenyzőket a pályán:

• az aréna első kanyara után általában kialakul egy véletlen futási sorrend (first curve) • egy ló bármikor megakadhat, ütemet veszthet a pályán (get stuck) • természetesen előzések is előfordulhatnak (outran)

Mindennek leegyszerűsített modelljét mutatja be a 7.14. ábra. A versenyben összesen há- rom ló vesz részt, melyek különböző futási utakat bejárva jutnak el a célig. Minden út 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 105

7.14. ábra. Lóverseny modellje különféle véletlen eseményeket tartalmazhat, és előzés során egymással az utak interakci- óba is kerülhetnek. A 7.14. ábrán az „end” feliratú tranzíció három bemeneti pozíciójának (goal1, goal2 és goal3 elnevezésűek) mindegyike rendelkezik egy POSTACTIVATE „goal” Petri ese- ménnyel. Ezt mutatja be a Petri események modul képernyőképe a 7.15. ábrán.

7.15. ábra. Lóverseny kapcsán regisztált Petri események

A véletlen célbaérkezési sorrendet a tokenjátékosok által kiváltott „goal” események bekövetkezési sorrendje fogja meghatározni. Maguk a pozíciók érdektelenek, a tokenek vannak egymástól névben és színben megkülönböztetve: Kincsem, Botond és Overdose névre hallgatnak, időben és térben összehozva e három paripát. Mikoron valamely „goal” esemény bekövetkezik, az API segítségével hozzá rendelt eseménykezelő lefut. Az ese- ménykezelőben az eseményt kiváltó pozíció tokenjei lekérhetőek, melyekből a célba ért ló azonosítható. De mielőtt ennyire előre rohanunk, vizsgáljuk meg a hálózatot kicsit alapo- sabban. Az első kanyart (first curve) követően a lovak más-más pozícióban/pályán lesznek. Mindegyik lovas csak egyik utat veheti fel (path1, path2 és path3 közül). Ezt a hatást az egyes utak további pozíciójaiból kiinduló tiltó élek hozzák létre (pl. a path1 tranzíció 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 106

nem tüzelhet abban az esetben, ha az azt követő három pozíció bármelyikén tokenjáté- kos található). A legfelső szinten ábrázolt futási pálya során a ló már az első akadályban megakadhat (get stuck), de nincs ez másként a további két ábrázolt pálya esetén sem (a középső pozíciók esetén). A verseny során két előzési lehetőség is modellezésre került. Az úgynevezett outran tranzíciók csak egymáshoz közeli pályák/pozíciók során jöhetnek létre3. Tüzelésükkor egyik véletlenszerűen kiválasztott lovas leelőzi ellenfelét, miközben akár pályát is cserélhetnek. A leelőzött lovasnak mindez egy meghátrálást is jelent (nem jut előbbre).

7.16. ábra. Egy lehetséges lóverseny futási eredménye

Egy lehetséges lóverseny futási eredményét láthatjuk a 7.16. ábrán. A tranzíció törté- netben a tranzíciók és a rajtuk keresztülhaladó tokenjátékosok neveit olvashatjuk. Fej-fej mellett indulva Botond az egyes pályát, Kincsem a kettest míg Overdose a hármast vá- lasztotta. Botond rögtön az élre tör, miközben Overdose leelőzi Kincsemet a kettes és hármas pálya elején. Ezt kihasználva Botond megnyeri a futamot. Kicsem utolsó erejével még előrébb jut, de mindhiába, mert Overdose végérvényesen maga mögé utasítva máso- dikként célba ér. Kincsem elkeseredésében folyamatosan megbotlik, míg végül utolsóként bevágtat. A 7.16. ábrán a futás állapotmátrixát is láthatjuk, bár ez sokkal inkább egy gépi feldolgozás során olvasmányos.

1 using PetriNetworkLibrary .Model.NetworkItem; 2 [..] 3 p r i v a t e PetriNetwork network; 4 p r i v a t e List result; 5 [..] 6 t h i s .network = PetriNetwork.openFromXml(this.rand, @"network\Horserace.pn.xml"); 7 t h i s .network.bindPetriEvent("goal", new PetriHandler(eventHandler)); 8 [..] 9 p r i v a t e void eventHandler(AbstractEventDrivenItem item , EventType eventType) { 10 i f (item is Position) { 11 Position position = (Position)item; 12 List tokens = position .Tokens; 13 i f ( (tokens != null) && ( tokens.Count == 1 ) ) { 14 t h i s. result .Add(tokens[0]) ; 15 } 16 } 17 } 18 [..]

3 A pályák demonstrációja nem törekszik élethű modellt adni. A pályák lehetnek egymás melletti utak, egymás mögötti pozíciók is. 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 107

19 p r i v a t e void start() 20 { 21 t h i s.result.Clear(); 22 t h i s .network. setStartState("start"); 23 FireEvent fireEvent = FireEvent.INITFIRE; 24 FireReturn fireReturn = null; 25 while (! FireEvent .DEADLOCK. Equals(fireEvent)) 26 { 27 fireReturn = this.network. fire(); 28 fireEvent = fireReturn.FireEvent; 29 } 30 } 7.1. kód. Lóverseny felhasználása API-en keresztül

Miután a lóverseny modelljét kialakítottuk, és néhány automata szimuláció alapján a futási eredményeket elfogadhatónak tekintjük, készen állunk a modell API-en keresztüli felhasználására. Ennek eredményét mutatja a 7.1. kódrészlet. A hálózat megnyitása és a goal Petri esemény valós eseménykezelőhöz kötése után egy start() metódus meghívá- sa segítségével a futási eredményeket egy generikus sorrendtartó listába gyűjthetjük. A folyamatot főszálon, vagy akár háttérszálon is elvégezhetjük. Az eseménykezelőben kihasz- nál(hat)juk a modell jellegzetességeit (nevezetesen azt, hogy a célnak megfelelő pozíciókon egynél több token sosem lehet). Mi is volt a demonstráció eredeti célkitűzése? Egy lóver- seny eredményének első három helyezettjére voltam kíváncsi. Nyilvánvalóan a véletlen- szerű eredmény előállt, azonban e véletlenszerűség mögötti üzleti kód vajon áttekinthető formában adott? Remélhetőleg a válasz erre is igen. 8. fejezet

Összefoglalás

A dolgozat egy egyszerűnek tűnő, ámbár annál merészebb célkitűzéssel indult el: a magas szintű imperatív objektum-orientált nyelvek világát miként lehetne megfűsze- rezni egy olyan deklaratív jellegű leírási móddal, mint a Petri hálók. A törekvés nem példa nélküli, a bevezetőben már említett Microsoft LINQ megoldás egy deklaratív lo- gikai nyelvet, az SQL-t használta sikeresen fel erre a célra. Felmerülhet a kérdés, hogy vajon miért is lehet ez a terület érdekes? Az imperatív nyelvekre1 jellemző utasítások és parancsok felszólító módban fogalmazzák meg az elvégzendő feladatot, ezzel szemben a deklaratív nyelvek2 előszeretettel használják a kijelentő módot állításaik leírására. Előbbi arra alkalmas, hogy a gép számára definiáljuk, hogy hogyan oldja meg a feladatot, míg utóbbi sokkal inkább a mit kérdésre ad választ[69]. Az imperatív nyelvek szükségszerű- en elvesznek a részletekben, apró elemi műveleteik legtöbbször nem függnek egymástól, egy „tökéletesen” mozgó gépezet apró fogaskerekei csupán. A deklaratív nyelvek esetén ezzel szemben az „elemi művelet” sokkal inkább egy ember számára elemi, és nem a gép számára. A megoldandó feladatra sokszor madártávlatból tekint, a konkrét implementá- ciót részletkérdésnek tartja. Talán az utolsó gondolat az, mely kapcsán úgy vélem egyre inkább előtérbe kerülhetnek a deklaratív nyelvek az iparban is. A kor számítástechnikai eszközeinek teljesítménye már jó ideje lehetővé teszi azt, hogy egy alkalmazás-fejlesztő ne csupán algoritmusok készítésével, hanem már sokéves munkát magában hordozó modulok integrálásával foglalkozzon. Azt is mondhatjuk, hogy hamarosan megszületik egy olyan generáció, mely nem biztos hogy a munkája szépségét egy jól megírt rendezésben fogja látni, hanem egy új API felhasználásában. Vajon sikeres lehet egy ilyen fejlesztői csoport? Őszintén én erre csak nemmel válaszolhatok, azonban az is tény, hogy már számomra is léteznek olyan problémák, melyekre munkám során nem kívánok fekete doboznál többre gondolni3. A választott deklaratív leírási mód - a Petri hálók - integrálása természetesen impe- ratív nyelven készült el, mint ahogy a gépek jelentős része csupán ezt képes értelmezni (ugyanebből kifolyólag a Prolog avagy az SQL fordítója is imperatív nyelven íródott). Nem volt célom olyan professzionális integrálást létrehozni, mint a Microsoft LINQ, lévén ehhez a meglévő imperatív nyelv fordítójához kellett volna nyúlni. Megelégedtem egy API létrehozásával, melyet bármely magas szintű nyelvekben járatos fejlesztő percek alatt fel

1 Imperatív nyelvekre néhány példa: assembly, Algol, Pascal, PHP, Python, C, C++, C#, Java. 2 Funkcionális deklaratív nyelvekre (függvényfogalomra épülő közelítésmód) példa a LISP, és az Erlang (ERicsson LANGuage), logikai funkcionális nyelv (reláció-fogalomra épülő közelítésmód) pedig pl. az SQL avagy a Prolog. 3 A teljesség igénye nélkül ilyen probléma az elemi naplózás (commons logging, log4j), egy riport elkészítése (jasper reports) avagy egy e-mail elküldése egy PHP kódból (swift mailer).

108 8. FEJEZET. ÖSSZEFOGLALÁS 109 tud használni. Az integráció egyetlen eleme az objektum-orientált világ kontextusában értelmezett események összekötése a Petri hálózatok tokenjátéka során keletkezettekkel. A kapcsolat létrehozása a legnagyobb szándékosság mellett lett végletekig egyszerű: egy névvel elláthatjuk a Petri hálózat bármely eseményét, majd ezen névhez az elkészült API segítségével egy eseménykezelőt rendelhetünk. Nincsenek korlátozások: ugyanazon ese- mény a hálózat több különböző pontján is előállhat, ezért szerepelhet ugyanaz az elneve- zés több szituációban is. Az imperatív nyelvek esetén mindez redundanciának számítana, ugyanazon feladatot szinte tilos két különböző helyen definiálni. Pontosan ezért a több különböző ponton regisztrált azonos nevű eseményeket egyetlen egyszer kell ugyanahhoz az eseménykezelőhöz rendelnünk az API megfelelő metódusa segítségével. A Petri háló API elkészítése nyilvánvalóan nem sokat ér megfelelő információtarta- lommal rendelkező Petri hálózatok nélkül. Ennek érdekében került nagyító alá számos - elsősorban ingyenes - Petri háló szerkesztésére alkalmas szimulációs eszköz. Az irodalom- kutatás kapcsán tapasztaltak egy érdekes ellentmondásra világítottak rá: sok egyetemen foglalkoznak komolyabban Petri hálókkal (lásd. 2.7.7. Queueing Petri net Modeling En- vironment, 2.7.6. Platform Independent Petri net Editor avagy CPN-AMI[34]), mégis a fellelhető szerkesztő programok sokszor nincsenek köszönőviszonyban a mai kor elvárha- tó követelményeinek. Példának okáért a sorból minőségben kiemelkedő CPN Tools (lásd. 2.7.2. fejezet) innovatív felületét egy hétköznapi felhasználó nehezen értelmezi, sok remek alkalmazás felett pedig már lassan eljár az idő (pl. 2.7.5. HPSim). Minden bizonnyal lehe- tett volna olyan egyetemi projekt kapcsán készülő szimulátort találni, melybe a Petri ese- mények kiterjesztés integrálható lett volna, azonban egyik alkalmazás sem nyerte el olyan mértékben a tetszésem, hogy ezt az utat válasszam. Nem másodlagosan ha már a szer- kesztő és a szimulátor alkalmazás fejlesztése előtérbe került, egy felhasználóbarát oktatási segédeszköz gondolata is célként lebegett előttem. Mindebből született meg a Universi- tas Budensis Petri Network Simulator (UBPNS) fantázia névre hallgató program, mely az általános Place/Transition hálózatok közel teljeskörű szerkesztését és elemzését teszi lehetővé. A rendszertervben bemutatott Petri háló kiterjesztések mellett természetesen a legfontosabb pluginje a saját ötleten alapuló Petri események regisztrációja. A szimulátor alkalmazás implementálása során az úgynevezett clean-code elveinek jelentős része szem előtt lett tartva, mely nyitva hagyja a kaput az alkalmazás továbbfej- lesztése előtt. Az elegancia jegyében készült lokalizáció nem az összes felületre készült el, azonban a háttérben működő általános motor sehol sem zárja ki ennek befejezését. Apró- ság, de a sok kódtechnikai megoldás közül kiemelném a felsorolás típusok alternatívájaként készített referencia típusú osztályokat, melyeket a C# világába a Java világából kölcsö- nöztem, illetve megemlíthető még a kimeneti PN.XML állományok integritás védelmének szabványos megoldása, mely lehetőséget ad az oktatásban egy adott kurzus/konferen- cia idejére létrehozható hálózatok szabad publikálására, valamint a megbízható forrásból származó tételek elkülönítésére. A fejlesztés közben számos továbbfejlesztési lehetőség fel- merült: a legkézenfekvőbb a színezett petri hálók támogatása volna, de a tokenjátékosok megkülönböztetése kapcsán is volna még mit implementálni. Résumé

In our present the imperative programming techniques starting to suppress the decla- rative ones, like Prolog, LISP or Erlang. For instance, in industry environment this effect is responsible for opinions of many Java developers, that the only purpose of a relational database is to store data exclusively. Fortunately there are some high-level innovations in the industrial development, which don’t let to die out the alternative way of thinking: e.q. Microsoft LINQ solution (Language-Integrated Query). Target of this study is also to embed a declarative modeling technique - the Petri nets - into the world of the imperative high-level programming. Why is it an interesting area? It is essential to answer this question. When we develop with an imperative language (like C# or Java), we always write instructions and commands in imperative mood to define for the computer how to solve the problem. On the other hand, at the world of the declarative thinking we try to describe what we want to solve, and don’t care about the „How-To’s”. Therefore the imperative languages often lost in the details, and if we want to modify the whole background logic, we have to dig deep inside the code. Perhaps a developer generation have been already born, who only integrate pre-prepared API (Application Programming Interface) in duty time, instead of implementing a nice algorithm for the eight queen problem. For that generation a declarative modification is more manageable, and it will be a big plus if this modification immediately takes effect on the running code. So if we don’t want to lost in details, and want to change the behavior of our code from a bird’s-eye view, we would better get used to the declarative way of thinking. The Petri-nets is an effective modeling tool, especially in the area of the concurrent behavior, and it has a very intuitive characteristic: the non-deterministic simulation. This behavior is hard to be implemented in an imperative language, and its parameters even more difficult to be changed. This was the reason why this dissertation was selected the aim: embed Petri-nets into an imperative high-level language. To reach the goal, first of all we need a well-formed description about Petri-nets, and its extensions, and also need a new extension to model the object-oriented events inside the simulation. We have to identify the moments of the transitions’ activation (transition fire), the token player movement and the change of the token distribution. The dissertation also implements a graphical user-friendly editor and simulator beside the model. To create a modern editor for projection, education and propagation of the Petri-nets is an intentional secondary goal. After we created a new Petri-net in the implemented Universitas Budensis Petri Network Simulator (UBPNS), we may load it with a high-level imperative language with the help of the Petri Network API. The usage of the API will be very simple intentionally. Open the well-formed PN.XML document, fetch the stored pre-registered names of the Petri events, than associate them to any object-oriented event-handlers. In the last step we start the simulation, even in a background thread, and when a Petri event occurs, our

110 8. FEJEZET. ÖSSZEFOGLALÁS 111 bounded event-handlers will be perform. The rules of the simulation are predefined and also non-deterministic, and if we want to analyze or modify its behavior, we have to open it in the Universitas Budensis Petri Network Simulator. Ábrák jegyzéke

2.1. Kémiai folyamatok leírása Petri hálókkal[7] ...... 2 2.2. Prof. Dr. Carl Adam Petri, 2007. augusztus 21.[3] ...... 3 2.3. Konrad Zuse és Carl Adam Petri 1975-ben ...... 3 2.4. Az 1962-es disszertáció címlapja[6] ...... 4 2.5. Egy Petri háló szerkezetének mintája ...... 4 2.6. Elosztott adatbázis kezelő rendszer CPN modellje[13] ...... 7 2.7. Elosztott adatbázis kezelő rendszer PN modellje[13] ...... 8 2.8. Étkező filozófusok problémája Algebrai Petri hálóban[15] ...... 9 2.9. Speciális tranzíciók a Folyamat hálózatokban[18] ...... 10 2.10. Információ gyűjtés ...... 10 2.11. Döntés ...... 11

2.12. Kiindulási M0 állapot ...... 12

2.13. M1 állapot ...... 13

2.14. M2 állapot ...... 14

2.15. M3 állapot ...... 14

2.16. M3 állapot ...... 15 2.17. Állapot-hierarchia ...... 15 2.18. GDToolkit generált Petri hálója[22] ...... 16 2.19. JARP[23] ...... 17 2.20. CPN Tools[24] ...... 18 2.21. Hybrid Petri Nets Simulator[25] ...... 19 2.22. HPSim[26] ...... 20 2.23. Platform Independent Petri net Editor képernyője[27] ...... 21 2.24. Queueing Petri net Modeling Environment[28] ...... 21 2.25. Tool for Verification of Timed-Arc Petri Nets[30] ...... 23 2.26. Portecle 1.7 ...... 32

3.1. Main use case ...... 43 3.2. Petri paletta module use case ...... 46

112 ÁBRÁK JEGYZÉKE 113

3.3. State Matrix module use case ...... 47 3.4. State Hierarchy module use case ...... 49 3.5. Minimap module use case ...... 49 3.6. Neighborhood Matrix module use case ...... 49 3.7. Statistics module use case ...... 50 3.8. Petri Event List module use case ...... 52 3.9. Tranzíció történet modul use case ...... 52 3.10. Elsődleges activity diagram ...... 54 3.11. Szimuláció activity diagram ...... 55 3.12. Kriptográfiai osztályok ...... 57 3.13. Lokalizációhoz kapcsolódó osztályok ...... 57 3.14. Dialógus ablakok osztály diagramja ...... 58 3.15. Felsorolás típusok osztályai ...... 59 3.16. Petri tételek osztályai ...... 64 3.17. Petri eseményekhez kötődő osztályok ...... 65 3.18. Eszköz ablakok osztályai ...... 65 3.19. Utoljára megnyitott állományok osztály diagramjai ...... 67 3.20. További osztályok diagramjai ...... 68

6.1. Petri hálózat API áttervezett osztályhierarchiája ...... 87 6.2. Élek, tokenek és jegyzetek osztálydiagramjai ...... 88 6.3. Pozíciók, Tranzíciók és Állapotvektorok osztálydiagramjai ...... 89 6.4. Petri hálózatok új osztálya ...... 89 6.5. Eseményvezérlés osztályai ...... 90

7.1. Bejelentkezés a szimulátor alkalmazásba ...... 94 7.2. TrustStore böngészése ...... 95 7.3. Új hálózat létrehozása ...... 96 7.4. Új hálózat szerkesztés közben ...... 97 7.5. Létező hálózat megnyitása ...... 98 7.6. Szerkesztő ablak három állapota ...... 98 7.7. Petri paletta modul ...... 99 7.8. Állapot mátrix modul ...... 101 7.9. Állapot-hierarchia modul ...... 102 7.10. Szomszédossági mátrix modul ...... 102 7.11. Statisztika modul ...... 103 7.12. Tranzíció történet modul ...... 103 ÁBRÁK JEGYZÉKE 114

7.13. Petri események modul ...... 104 7.14. Lóverseny modellje ...... 105 7.15. Lóverseny kapcsán regisztált Petri események ...... 105 7.16. Egy lehetséges lóverseny futási eredménye ...... 106 Kódjegyzék

2.1. Aszimmetrikus kulcsgenerálás Java 1.6 keytool-lal ...... 30 2.2. Certificate Signing Request generálása ...... 31 2.3. Certificate aláírása OpenSSL-lel ...... 32 2.4. CA által aláírt tanúsítvány JKS-be importálása keytool-lal ...... 33 3.1. Képviselők ...... 61 3.2. Utoljára megnyitott állományok példa XML forrása ...... 66 3.3. XSD tool segítésével XML-ből XSD generálás ...... 66 3.4. A recentfiles.xml állomány schema-ja ...... 66 3.5. A recentfiles_rf.xml állomány schema-ja ...... 67 3.6. XSD tool segítségével XSD-ből Java kód generálás ...... 67 4.1. A kimeneti *.pn.xml állomány kerete ...... 69 4.2. A kimeneti *.pn.xml állomány kerete ...... 70 4.3. Globális események XML modellje ...... 72 4.4. Vizuális beállítások XML modellje ...... 72 4.5. Láthatósági/megjelenítési beállítások XML modellje ...... 73 4.6. Topológia XML modellje ...... 73 4.7. Pozíciók XML modellje ...... 74 4.8. Tranzíciók XML modellje ...... 75 4.9. Élek XML modellje ...... 75 4.10. Annotációk XML modellje ...... 76 4.11. Állapot-hierarchia XML modellje ...... 76 5.1. Root CA privát kulcs létrehozása ...... 78 5.2. Root CA tanúsítványának létrehozása ...... 78 5.3. X509v3 kiterjesztések (openssl.conf állomány) ...... 79 5.4. Root CA tanúsítványának konvertálása ...... 79 5.5. Root CA TrustStore-jának előállítása ...... 79 5.6. Sub CA létrehozása ...... 80 5.7. Certificate Signing Request állomány létrehozása ...... 80 5.8. Sub CA tanúsítványának aláírása ...... 81

115 KÓDJEGYZÉK 116

5.9. Sub CA tanúsítványának aláírása ...... 81 5.10. Végfelhasználói kulcs generálása ...... 82 5.11. Végfelhasználói tanúsítvány CSR állományának létrehozása ...... 82 5.12. Sub CA által aláírt végfelhasználó tanúsítványok kiterjesztései (openssl.conf) 83 5.13. Végfelhasználói tanúsítvány aláírása Sub CA által ...... 83 5.14. Végfelhasználói tanúsítvány konvertálása és csomagolása ...... 83 5.15. Végfelhasználói tanúsítvány konvertálása és csomagolása ...... 84 6.1. Eseményvezérlés háttere ...... 91 6.2. Hálózat megnyitása ...... 91 6.3. Eseménykezelő ...... 92 6.4. Névvel adott esemény regisztrálása ...... 92 6.5. Összes esemény regisztrálása ...... 93 6.6. Tokenjáték lejátszása ...... 93 7.1. Lóverseny felhasználása API-en keresztül ...... 106 Irodalomjegyzék

[1] Don Box, Anders Hejlsberg (Microsoft): Language-Integrated Query. http://msdn.microsoft.com/library/bb308959.aspx (2007.02.01.)

[2] Carl Adam Petri önéletrajza (Universität Hamburg). http://www.informatik.uni−hamburg.de/TGI/mitarbeiter/profs/petricv_ eng.html (2011.03.30.)

[3] Prof. Dr. Carl Adam Petri (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Carl_Adam_Petri (2011.07.09.)

[4] Dr. J.A.N. Lee: Konrad Zuse önéletrajza. http://ei.cs.vt.edu/~history/Zuse.html (2011.09.25.)

[5] Konrad Zuse Z3 gépe (History of Computing). http://www.computermuseum.li/Testpage/Z3−Computer−1939.htm (2011.10.01.)

[6] Carl Adam Petri hivatalos oldala (Universität Hamburg). http://www.informatik.uni−hamburg.de/TGI/mitarbeiter/profs/petri_eng. html (2011.05.19.)

[7] Petri net (Scholarpedia Enciklopédia). http://www.scholarpedia.org/article/Petri_net (2008.04.17.)

[8] Petri net (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Petri_net (2011.08.05.)

[9] Introductions to Petri Nets. http://www.informatik.uni−hamburg.de/TGI/PetriNets/introductions (2011.11.11.)

[10] Petri Nets World (Universität Hamburg). http://www.informatik.uni−hamburg.de/TGI/PetriNets (2011.08.05.)

[11] Coloured Petri nets (Aarhus University Department of Computer Science). http://cs.au.dk/CPnets (2011.11.09.)

[12] Kurt Jensen, Erdélyi Árpád: Színezett Petri hálók (Aarhus Egyetem, Budapesti Műszaki és Gazdaságtudományi Egyetem). http://www.inf.mit.bme.hu/sites/default/files/materials/category/kateg% C3%B3ria/oktat%C3%A1s/msc−t%C3%A1rgyak/form%C3%A1lis−m%C3% B3dszerek/11/Szinezett_Petri_halok−1.pdf (2011.10.20.)

117 IRODALOMJEGYZÉK 118

[13] dr. Bartha Tamás: Színezett Petri hálók (BME Méréstechnika és Információs Rendszerek Tanszék). https://sauron.inf.mit.bme.hu/Edu/FormModsz/2010/form10tavasz. nsf/a141f6e0f01d3349c1256e4c005bc395/9b5e3f4bfaa6334cc12577110075a6a3/\ protect\T1\textdollarFILE/PN_szinezett−2p.pdf (2011.10.21.)

[14] Arthur John Robin Gorell Milner (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Robin_Milner (2007.12.10.)

[15] Algebraic Petri nets (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Algebraic_Petri_nets (2010.03.05.)

[16] Dining philosophers problem (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Dining_philosophers_problem (2011.07.28.)

[17] Concurrent Object-Oriented Petri Nets (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/CO−OPN (2010.11.10.)

[18] Thomas Freytag: Workflow Petri Net Designer. http://woped.org/woped (2012.02.05.)

[19] Petri Net Markup Language. http://www.pnml.org (2012.01.20.)

[20] Erik Fischer: Petri Net Kernel. http://www2.informatik.hu−berlin.de/top/pnk/index.html (2011.09.15.)

[21] Ekkart Kindler: ePNK - A generic PNML tool (Denmark’s Technical University, DTU Informatics DK-2800 Kgs. Lyngby Denmark). http://www2.imm.dtu.dk/~eki/projects/ePNK/ (2011.02.17.)

[22] GDToolkit - Graph Drawing Toolkit. http://www.dia.uniroma3.it/~gdt/gdt4/index.php (2008.08.01.)

[23] JARP Petri Nets Analyzer. http://jarp.sourceforge.net/us/index.html (2001.12.06.)

[24] CPN Tools. http://cpntools.org (2011.10.04.)

[25] Hybrid Petri Net ICSI Simulator. http://sourceforge.net/projects/hisim (2011.08.27.)

[26] Henryk Anschuetz: HPSim. http://www.winpesim.de/3.html (2011.09.12.)

[27] Platform Independent Petri net Editor. http://pipe2.sourceforge.net/index.html (2011.11.24.)

[28] Queueing Petri net Modeling Environment (University of the State of Baden- Wuerttemberg). http://descartes.ipd.kit.edu/projects/qpme/features (2011.10.02.)

[29] Renew (University of Hamburg). http://www.renew.de (2011.12.04.) IRODALOMJEGYZÉK 119

[30] Tool for Verification of Timed-Arc Petri Nets (University in Denmark). http://www.tapaal.net (2011.09.27.)

[31] Algebraic Petri Net Analyzer. http://alpina.unige.ch (2011.10.01.)

[32] Analisador de Redes de Petri. http://dainf.ct.utfpr.edu.br/~maziero/doku.php/software:arp_tool (2009.09.14.)

[33] CO-OPN and COOPNBuilder (University of Geneva). http://smv.unige.ch/research−projects/co−opn (2011.10.06.)

[34] CPN-AMI (Laboratoire d’Informatique de Paris). http://move.lip6.fr/software/CPNAMI (2011.10.03.)

[35] ExSpect. http://www.exspect.com (2011.10.05.)

[36] Prof. Dr. Peter. H. Starke: Integrated Net Analyzer (Humboldt-Universität zu Ber- lin). http://www2.informatik.hu−berlin.de/~starke/ina.html (2003.07.31.)

[37] JPetriNet. http://jpetrinet.sourceforge.net (2011.11.07.)

[38] Petri net tool Netlab (Aachen University). http://www.irt.rwth−aachen.de/en/fuer−studierende/downloads/petri− −net−tool−netlab/ (2011.10.23.)

[39] Dragan Gasevic: P3 - Petri net tool. http://www.sfu.ca/~dgasevic/projects/P3net/index.htm (2008.12.19.)

[40] Pace (IBE Simulation Engineering GmbH). http://www.ibepace.com (2011.09.22.)

[41] PetriLLD. http://sourceforge.net/apps/mediawiki/petrilld/index.php?title= =Main_Page (2011.08.25.)

[42] Petri Net Toolbox for Matlab (Technical University „Gh. Asachi” of Iasi). http://www.ac.tuiasi.ro/pntool (2010.12.09.)

[43] Petrisim 5 - Discrete Simulation Environment. http://staff.um.edu.mt/jskl1/petrisim (2004.05.17.)

[44] Petruchio. http://petruchio.informatik.uni−oldenburg.de (2012.04.28.)

[45] pneditor: Petri net editor. http://code.google.com/p/pneditor (2011.09.03.)

[46] SimHPN (Group of Discrete Event Systems Engineering). http://webdiis.unizar.es/GISED/?q=tool/simhpn (2011.09.28.) IRODALOMJEGYZÉK 120

[47] VisualPetri. http://sourceforge.net/projects/visual−petri/files/visual−petri (2011.09.02.)

[48] WoPeD: Workflow Petri Net Designer. http://www.woped.org (2011.10.06.)

[49] Yasper: Yet Another Smart Process Editor. http://www.yasper.org (2011.10.07.)

[50] Bruno Pages: BOUML. http://www.bouml.fr (2012.04.28.)

[51] Prof. Dr. Galántai Aurél: Információ- és kódelmélet (Óbudai Egyetem). http://www.uni−obuda.hu/users/galantai (2011.02.04.)

[52] Symmetric-key algorithm (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Symmetric−key_algorithm (2011.08.30.)

[53] Asymmetric-key algorithm (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Asymmetric−key_algorithm (2011.09.25.)

[54] RSA (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/RSA (2011.09.28.)

[55] Certificate authority (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Certificate_authority (2011.09.19.)

[56] Java Key and Certificate Management Tool. http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool. html (2012.04.25.)

[57] Secure hash algorithm (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/SHA−1 (2011.09.27.)

[58] Wayne Grant, Mark Majczyk, Ville Skyttä: Portecle. http://portecle.sourceforge.net/ (2011.06.10.)

[59] Bouncy Castle Crypto API. http://www.bouncycastle.org/ (2011.04.01.)

[60] PKCS12 (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/PKCS12 (2011.03.08.)

[61] Certificate Signing Request (Wikipedia Enciklopédia). http://en.wikipedia.org/wiki/Certificate_signing_request (2011.09.27.)

[62] OpenSSL. http://www.openssl.org/ (2012.04.25.)

[63] Joa˜o Paulo Barros: Specific Proposals for the Use of Petri Nets in a Concurrent Programming Course. http://www.dca.ufrn.br/~affonso/DCA0409/pdf/artigo_petrinet1.pdf (2012.04.25.) IRODALOMJEGYZÉK 121

[64] Harald Störrle: Models of software architecture, Design and Analysis with UML and Petri-nets, Ludwig-Maximilians-Universita¨t München, 2000

[65] Labelled Transition System Analyser. http://www.doc.ic.ac.uk/ltsa/ (2006.06.01.)

[66] Tadao Murata: Petri Nets Properties, Analysis and Applications. http://embedded.eecs.berkeley.edu/Respep/Research/hsc/class. F03/ee249/discussionpapers/PetriNets.pdf (1989.05.01.)

[67] Bedők Dávid: Java és C# enum összehasonlítása, Java enum tervezési minta megvalósítása C#-ban. http://bedok.hu/oe/index.php?q=1&NEWS_GRID=130&order=1&q_action= =gotonews (2012.01.20.)

[68] W3C XML Signature Syntax and Processing (Second Edition). http://www.w3.org/TR/xmldsig−core/ (2008.06.10.)

[69] Szeredi Péter, Benkő Tamás: Bevezetés a logikai programozásba, Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar, Budapest, 2004.02.01.