Diplomamunka. Petri hálók szimulációja és alkalmazásuk objektum-orientált környezetben. készítette: Bedők Dávid v0.4

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 deklaratí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 fejleszté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örnyezet 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 tokenjá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 dokumentum, 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 DLLké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 hozzá, 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ó architekturá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]) verifiká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étrehozott 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 bemutatásra kerülnek az implementálás során alkalmazott tervezési minták és program technikai megoldások. Az eszköz újrafelhasználhatóságának, és - nem titkoltan - oktatásban való alkalmazá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 úgynevezetett 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 órafrekvencia 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 „Kommunikation 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 kutatá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 Computing

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 1988ban 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 első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 4

Academy of Transdisciplinary Learning and Advanced Studies Institute of Electrical and Electronics Engineers


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


5

Minden egyes pozíció tartalmazhat tetszőleges természetes számú tokent. A tokeneket 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 tartozó ö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 helyekre 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 egymá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ásolni 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.


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átható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 negatí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értelmű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ással 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 mutathat, 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 prioritá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.


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] fejlesztett 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


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égpedig 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 adattípusoknak lehet megfeleltetni (Algebraic Abstract Data Types, AADT). Ebben a tulajdonsá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ő bizonyí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 enniü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]


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: folyamatos (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égbő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 megfeleltethető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.


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 fejezetekben 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ásnak (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 menté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


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, forgalom 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ághoz (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égtelent” (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.


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 tartalmazza az mp értékeket: M = [mp1 , mp2 ..mpk ]T 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} halmaz 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 2 = {T 3} •P 3 = {T 2} •P 4 = {T 3}

P 1• = {T 2} P 2• = {T 2} P 3• = {T 1, T 3} P 4• = {T 1}

míg a tranzíciókra nézve: •T 1 = {P 3, P 4} •T 2 = {P 1, P 2} •T 3 = {P 3}

T 1• = {P 1} T 2• = {P 3} T 3• = {P 2, P 4}


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. 

W−



0 0 1 1  = 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.    

W− = 

P1 P2 P3 P4 T1 0 0 1 1 T2 2 1 0 0 T3 0 0 1 0

    

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

W+



1 0 0 0   = 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  0  W T =  −2 −1 3  0 1 −1 1 A kezdeti állapotban (2.12. ábra) összesen három token található, melyeknek eloszlása a következő M0 = [1, 0, 2, 0]T á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 a P3 veszít. Az eloszlás így a következő lesz: M1 = [1, 1, 1, 1]T . 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ó


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 helye, a P1 egy tokent szerez. A kialakult token eloszlás a következő lesz: M2 = [2, 1, 0, 0]T (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övetkeztében a P3 pozícióra, ahol így most 3 játékos lesz. A token eloszlás ennek megfelelően a következő: M3 = [0, 0, 3, 0]T (2.15. ábra).

2.15. ábra. M3 állapot Ha folytatjuk az eddigi olykor determinisztikus, olyan nem-determinisztikus lépéseket, akkor ezeket egy M állapot átmenet mátrixban tudjuk felírni.    

M =

1 0 2 0

1 1 1 1

2 1 0 0

0 0 3 0

0 1 2 1

0 2 1 2

0 3 0 3

    

Az utolsó lépésben kialakuló M6 állapot után nincs további lépésre lehetőség, a szimuláció leáll, végállapot következik be (2.16. ábra). Hogy ez az automata elméletből ismeretes 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 .


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ú dokumentumná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ölté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)


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) szerkesztő 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 limitá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/menté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 lehető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]


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 magá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 jelenleg elérhető kereskedelmi, illetve ingyenes Petri háló szerkesztő alkalmazások. Ezen programokat 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ámogatjá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égeredmé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 elhelyezé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 formátumban is lementhetjük (*.gif, *.jpeg, *.png és *.ppm). 7

http://www.informatik.uni−hamburg.de/TGI/PetriNets/tools/quick.html


18

2.7.2. CPN Tools Színezett Petri hálók szerkesztésére alkalmas ingyenes desktop alkalmazás[24], legfrissebb 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 elemei 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.


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ó szerkesztő. Nevének megfelelően a diszkrét pozíciók és tranzíciók mellett lehetőség van folyamatos 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 kiemelhető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 annotá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 egyesével léptetni a tokenjátékot, illetve folyamatos lejátszásra állítani. A tüzelésre kész tranzí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,


20

úgynevezett MDI alkalmazás, nagyítási és nyomtatási funkciókkal ellátva. Grafikus szerkesztő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élysé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 helyeknek 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 tulajdonsá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átumot 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, átfutá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.


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 tokencsoportonké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é kompatibilis 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 olvashatunk.

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.


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éldá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áltoztathatunk. Fontos kiemelni, hogy bármilyen műveletvégzést is hajtunk végre az objektumokkal, 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 Petri 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 eredmé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étrehozhatunk ő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üzelhete, 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.


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 pluginja 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 megadandó 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 segí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 lehet.


24

Netlab[38] (kereskedelmi): 2004-es korához képest nem kifejezetten elegáns kinézetű alkalmazá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 Petri 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 (csomagkü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ősorban 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 szimulá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 operá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 szimulá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 összehasonlításra kerülnek. A táblázatban az alkalmazások rövidített nevei olvashatóak. Funkció Reset él Súlyozott élek Többszörös élsúlyok Kapacitás korlát Tiltó él Tranzíció prioritás Időzített tranzíciók

JARP

CPN

PNK

HPNS

HP

PIPE

x

x

x

x

x

x x

x x

x

x

x x x x x x

x x x x

x

QPME

RN x x x

TVT

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 Funkció Tokenjáték léptetéssel

JARP

CPN

manuális

Automata tokenjáték szimuláció Tokenjáték egér kattintással Állapot visszaállítás Tüzelésre kész tranzíciók jelölése

PNK x

x

25 HPNS x

HP

x

x

PIPE x

QPME

x

x

x

RN Speciális manuális tranzícióval

TVT

x

x

Kezdeti állapot x

x

Kezdeti állapot

x x

2.2. táblázat. Szimuláció lehetőségei szerint Csak azon szempontok kerültek felsorolásra, melyeket legalább egy vizsgált alkalmazá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ó Vizuális tokenek száma Megtörhető él rajzolás

JARP 3

CPN 1

PNK 0

Egyenesek, több szinten

Van, de nem aránytartó

Megfelelő

Méretezhetőség Tranzíciók forgatása Feliratok kikapcsolhatósága Annotációk, jegyzetek Hálózat nagyítása, kicsinyítése Grafikus annotációk

Korlátlan

x

x

HPNS 5 (kis méretben 0) Egyenesek és görbék, két szinten

HP 4

PIPE 5

Egyenesek, több szinten

Egyenesek, illetve görbék, tetszőleges törésponttal

3 méret 45 fok

5 méret

x

x

x

x

x

x

x

x

QPME 0

RN 0

TVT 0

Egyenesek mentén, tetszőleges törésponttal

45 fok

45 fok x

x

x x

Geometriai alakzatok

x

Geometriai 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égpontok á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 kriptográfiai eljárás, de tervezett felhasználása miatt egy fejezetben bemutatásra kerül. Az aszimetrikus, 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 Funkció Tulajdonság módosítás

JARP Helyi ikonok

Grafikus csoportosítás Modulok

CPN Helyi menü

HPNS Helyi menü

x

Statisztika Rácsháló

Rácshálóhoz igazítás Tranzíció történet Mentési formátum Exportálási lehetőség

PNK Helyi menü

Van, és három fix szinten sűríthető

26 HP Tulajdonság lap, helyi menü x

PIPE

QPME Tulajdonság lap

Riportot generáló modulok

Eclipse-re épül, a lehetősége adott x

x

modulként x

x

x

RN

TVT Helyi menü

x

x

x ARP, PNML GIF, JPEG, PNG, PPM

XML

XML

HPS

PNML

PNG, PS

BMP, TXT, HPX (INI)

PNG, PS, eDSPN

PNML PNG, PS, TikZ

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 gyakorlati 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égtelensége (Diffie Hellman (DH), Rivest Shamir Adleman (RSA))8 . Ezzel szemben a legismertebb 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 elvekben 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, 2007ben 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 kulcsokat 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 aszimmetrikus é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).


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 kulcsú 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)) matematikailag 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 = message) 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 elnevezett 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 rendelkezik 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. mA = E −1 (cA , sB ) Bob a válasz üzenetét Alice nyilvános kulcsával kódolja be, melyet egyedül Alice fog tudni visszafejteni.


28

cB = E(mB , kA ) mB = E −1 (cB , sA ) Az RSA algoritmus egyik nagy előnye, hogy a nyilvános és a titkos kulcsok megcseré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 („postá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 ) mdA = E −1 (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örté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élniü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 tulajdonosró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.


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 szolgá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 lehallgatá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 legtö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).


1

30

k e y t o o l ␣−g e n k e y p a i r ␣−k e y a l g ␣RSA␣−k e y s i z e ␣ 1024 ␣− s i g a l g ␣SHA1withRSA␣− a l i a s ␣ c u s t o m a l i a s ␣−k e y s t o r e ␣demo . j k s ␣−dname␣ "CN=U n i v e r s i t a s ␣ Budensis , ␣OU=NIK , ␣O=UNI−OBUDA, ␣L=Budapest , ␣S=Hungary , ␣C=HU, ␣ EmailAddress=i n f o @ n i k . uni−obuda . hu " ␣−s t o r e p a s s ␣ c h a n g e i t ␣−k e y p a s s ␣ 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 megnevezé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 certificateje (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 felderí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 foglalkozik. 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.


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 tartalmazó 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

k e y t o o l ␣−c e r t r e q ␣− a l i a s ␣ c u s t o m a l i a s ␣−k e y s t o r e ␣demo . j k s ␣− f i l e ␣demo . c s r ␣−s t o r e p a s s ␣ c h a n g e i t ␣−k e y p a s s ␣ c h a n g e i t

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) implementá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 scriptelhető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ülmé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.


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 elnevezé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

o p e n s s l ␣ ca ␣−p o l i c y ␣ c u s t o m p o l i c y ␣−c o n f i g ␣ c u s t o m o p e n s s l . c o n f ␣−c e r t ␣ c a _ c e r t i f i c a t e . pem␣−i n ␣demo . c s r ␣− k e y f i l e ␣ ca . key ␣−days ␣ 720 ␣−md␣ sha384 ␣−p a s s i n ␣ p a s s : 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 certificate” 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ítványokat akár egy XML-ben is utaztathatjuk a hálózaton.


1

33

k e y t o o l ␣−i m p o r t c e r t ␣− a l i a s ␣ c u s t o m a l i a s ␣− f i l e ␣demo . pem␣−k e y s t o r e ␣demo . j k s ␣−s t o r e p a s s ␣ c h a n g e i t ␣−k e y p a s s ␣ c h a n g e i t

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 matematikai 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 esemé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 esetben 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 kezelhetetlenek 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 objektumorientá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 informá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).


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 mindenké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 (első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 gondolni, 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 elemekhez, 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 megvizsgá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 Studiobó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. Ugyanezen 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ánvaló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 maradt, mert talán ez az az alkalmazás, mely a dolgozat céljaihoz hasonló indítatásból született. 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 algoritmust 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ű nyelveknek 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 volna 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 felhaszná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.


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ó „distinguished” 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értetlensége ellenőrzésre kerül, ezért a megnyitási folyamatban erre fel kell készülni. Amennyiben 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álható, é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 21

X.509.V3 certificate-ek támogatása a cél a megfelelő szintű biztonság elérése érdekében. A SOAP WebService-ek esetén elterjed módszer az aláíró tanúsítvány SOAP-Header-be csomagolá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 üzenet 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.


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 certificate 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 kiadottat).

3. fejezet Rendszerterv 3.1. Modellezés A Petri hálózat szimulátor és szerkesztő alkalmazás tervezése UML (Unified Modeling 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 modellezésre illetve fejlesztésre globálisan érvényes szabályokat, a nem funkcionális követelmé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 olvasható. 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 állapot közti átmenet) nem lehet 100 ezredmásodpercnél több egy 50 tranzíciót tartalmazó hálózat esetében. • NFR4 A belépéshez szükséges titkos kulcsoknak, illetve a TrustStore-ok tanúsítvá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örnyezetben 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 megoldá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 modulok elhelyezkedése az operációs rendszer felhasználójához legyen rendelve (felhaszná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 kompatibilis a PNML formátummal, így más e formátumot támogató Petri háló szerkesztő 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.


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ároló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 egyré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.


40

• JKS Java Key Store rövidítése. A Java nyelv szabványa szimmetrikus és aszimmetrikus 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ú tanúsítványok állományának kiterjesztése. • Petri háló Matematikai modellező nyelv, elsősorban eloszott, párhuzamos rendszerek 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 gyakran 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 Standardization 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 miké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észletgazdag 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ődleges, illetve az összes tervezett modul használati eset diagramja (Use case diagram), vala-


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) alkalmazá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.


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 ellá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.1. ábra. Main use case Elsődleges használati eset űrlapja Elsődleges használati eset 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 have, Could have és Won’t have kifejezésekkel szokták definiá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 fenntartott 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ő Use Case Leírás

43

3. FEJEZET. RENDSZERTERV Esemény folyam

Alternatív ágak

Utófeltételek Üzleti szabályok NFR-ek Megjegyzés

44

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 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 eseményfolyamot ez az alternatíva nem befolyásolja) Nincsenek [BR1][BR2][BR3][BR4][BR5][BR6][BR7][BR8][BR9] [NFR1][NFR2][NFR4][NFR5][NFR6][NFR7] [NFR8][NFR9][NFR12] 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], 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 alkalmazá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.


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 modulok 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 mindezek 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. fejezetben 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 alkalmazá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 optimalizá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 érvé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 annotációhoz pontosan egy elem összerendelése rajzolható általa)


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 állapot 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. Értelemszerű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 alkalmas 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 szimulá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ármely 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 folyamat, 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.


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 dobá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.


48

szituációban jósolhatóan előforduló állapotok memóriába kerülnek, és ismételt előfordulá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íthatjuk (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.4. ábra. State Hierarchy module use case

3.5. ábra. Minimap module use case

3.6. ábra. Neighborhood Matrix module use case

49


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 elemek, 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ő kiterjeszté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 activate) • 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)


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 aktuá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 megvaló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.


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 teljesü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.


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ó azonosí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 tartalmazó á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 kihagyni. 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 rendelkezik 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 felhaszná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ásolni (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, mikö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).


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 minden 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


55

között, azonban 50 ezredmásodpercnél nem lehet kisebb. A másik várakoztatás nem minden 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 (Interaction Diagram). Ezen diagramokra az jellemző, hogy a kommunikációban résztvevő objektumokra, 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 Diagram (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égrehajtá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.


56

egyes osztály elemzésére nincs értelme kitérni, azonban az alkalmazás magját jelentő típusok bemutatásra kerülnek. Az osztályok teljes qualified névvel azonosítottak a dolgozatban, 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. Cryptography. X509Certificates. X509Certificate2 osztálynak, X.509.V3-as tanúsítványok tárolására használható. Az Utils.CryptoHelper osztály már konkrét üzleti funkcióval rendelkezik. 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 (getCertificateFromTrustStore) • 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 validációhoz szükséges kibocsátó subject-jét ([email protected], CN=Petri Universitas 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 lokalizá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ő nyelvesí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) esemé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 opcionalitá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 implementálják az interface-t). 5

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


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 egysé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 leszá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 hideCancelButton 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, StateMatrixSetting, 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.


58

célra használhatóak bárhol az alkalmazáson belül (TextExportForm, ChangeTextValueForm).

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ípusok 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 ellá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 elvé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,


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 kapcsolatot 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érhető, 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 gyermek ablak kontextusától függő dinamikus tulajdonság, tokenjátékos és esemény lap generá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 enné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érlő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. 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).


60

Az MDI szülő ablak feladatai közé tartozik a fentieken kívül még egy konzol ablak kezelése is. A konzol ablakra az alkalmazás bármely osztálya küldhet üzeneteket (eseményeken 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. PetriNetwork 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. DrawReversibleLine é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 kiindulá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 állapotá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/visszajelö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 ejteni. 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 áthelyezé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 enné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


61

(feliratát) módosítani tudja a felhasználó. Itt is van egy speciális viselkedés: amennyiben 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 szerkeszté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áltásban lehetnek. Felsorolásképpen a 3.1. script részlet bemutatja a definiált képviselőket. 1 namespace P e t r i N e t w o r k S i m u l a t o r . Forms . Main { 2 p u b l i c d e l e g a t e v o i d N e t w o r k I t e m H a n d l e r ( L i s t i t e m s , b o o l f o r c e R e f r e s h ) ; 3 p u b l i c d e l e g a t e v o i d ChildFormHandler ( s t r i n g name ) ; 4 } 5 namespace P e t r i N e t w o r k S i m u l a t o r . Forms . T o o l s { 6 public delegate void StateVectorHandler ( StateVector stateVector ) ; 7 public delegate void StateMatrixSettingsHandler ( FireRule fireRule , i n t millisecondsTimeoutForSimulation ) ; 8 p u b l i c d e l e g a t e void S t a t e A c t i o n H a n d l e r ( S t a t e M a t r i x A c t i o n a c t i o n , PetriNetwork network ) ; 9 p u b l i c d e l e g a t e void NetworkActionHandler ( NetworkToolboxAction s e l e c t e d A c t i o n ) ; 10 p u b l i c d e l e g a t e v o i d N e t w o r k I t e m H a n d l e r ( NetworkToolboxItem s e l e c t e d I t e m ) ; 11 } 12 namespace P e t r i N e t w o r k S i m u l a t o r . E n t i t i e s . Network { 13 p u b l i c d e l e g a t e v o i d D i m e n s i o n H a n d l e r ( i n t width , i n t h e i g h t ) ; 14 } 15 namespace P e t r i N e t w o r k S i m u l a t o r . E n t i t i e s . Common . Network 16 { 17 p u b l i c d e l e g a t e void PetriNetworkEventHandler ( s t r i n g message ) ; 18 public delegate void PetriNetworkNotifier ( NetworkNotifierAction action ) ; 19 } 20 namespace P e t r i N e t w o r k S i m u l a t o r . U t i l s 21 { 22 p u b l i c d e l e g a t e void CryptoHandler ( s t r i n g message ) ; 23 public delegate void CultureHandler ( ) ; 24 } 25 namespace P e t r i N e t w o r k S i m u l a t o r . C o n t r o l s 26 { 27 p u b l i c d e l e g a t e v o i d PropertyGroupMoveHandler ( A b s t r a c t N e t w o r k network , N e t w o r k P r o p e r t y networkProperty , f l o a t 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 tulajdonság és esemény táblázatot fel tudja építeni. Amennyiben egyetlen elem van csak kijelölve, 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ó felhaszná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 indulá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. AbstractNetwork és az Entities. Network. PetriNetwork osztályok jelentik. Az absztrakció itt elsősorban a „Segregation of Duties” és a „Separation of concerns” elveit követi,


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 <StateVector> é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 grafikai 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. IdentityProvider 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ó, annotá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ó kezeléséért.

3.6.8. Petri tételek osztályai Minden olyan grafikai elem, mely a Petri hálózaton megjelenhet, az Entities. Common. Base. AbstractItem osztály példánya. Ez csupán a nevét (name), egyedi azonosítóját (unid) és kapcsolódó adatainak megjelenítésének kapcsolóját definiálja (showAnnotation), 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 alkalmazá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áltozik. Ilyenkor elképzelhető, hogy színezett token példányok eltűnnek, illetve újak létrejö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ó szempont 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


63

absztrakt osztály felelős a grafikai megjelenítésért, beleértve ebbe az egy ponton görbíthető 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őleges é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. Position 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 absztrakt, é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églalapké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áltoztatunk, 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 entitá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 tokeneloszlása (Dictionary >, ahol a kulcs a pozíció unid-ja).


64

3.16. ábra. Petri tételek osztályai Üzletileg lényeges pontja az osztálynak az Equals és GetHashCode metódusok overrideolá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 entitá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 tartalmaz. 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 rendelhető, 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.


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. GeneralToolWindow ő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. GeneralPictureToolWindow formmal. Az ős meghatározza a kép fizikai méreteit és nagyítási arányait. Metódusokat 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


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 Tool 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 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Timed c l o c k . \ n e t w o r k s \ Timed_clock . pn . xml E=bedok . david@nik . uni−obuda . hu , CN=David Bedok , OU=NIK , O=UNI−OBUDA, L=Budapest , S=Hungary , C=HU ( 2 0 1 1 . 1 0 . 0 2 . 18 : 2 4 : 4 8 ) N y o l c a s s z a m l a l o D i n i n g p h i l o s o p h e r s . \ n e t w o r k s \\ D i n i n g _ p h i l o s o p h e r s . pn . xml E=bedok . david@nik . uni−obuda . hu , CN=David Bedok , OU=NIK , O=UNI−OBUDA, L=Budapest , S=Hungary , C=HU ( 2 0 1 1 . 1 0 . 0 2 . 18 : 2 4 : 5 6 )

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%\M i c r o s o f t SDKs\Windows\ v7 . 0A\ Bin \NETFX 4 . 0 T o o l s \ xsd . e x e " r e c e n t f i l e s . 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 recentfiles.xsd (lásd. 3.4.kód) és egy recentfiles_rf.xsd file (lásd. 3.5. kód). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<x s : s c h e m a i d=" P e t r i N e t w o r k F i l e s " t a r g e t N a m e s p a c e=" h t t p : // f i l e s . p e t r i n e t w o r k . hu " x m l n s : m s t n s=" h t t p : // f i l e s . p e t r i n e t w o r k . hu " xmlns=" h t t p : // f i l e s . p e t r i n e t w o r k . hu " x m l n s : x s=" h t t p : //www. w3 . o r g /2001/XMLSchema" xmlns:msdata=" u r n : s c h e m a s −m i c r o s o f t −com:xml −msdata " a t t r i b u t e F o r m D e f a u l t=" q u a l i f i e d " e l e m e n t F o r m D e f a u l t=" q u a l i f i e d " x m l n s : r f=" h t t p : // r e c e n t f i l e . p e t r i n e t w o r k . hu "> <x s : i m p o r t namespace=" h t t p : // r e c e n t f i l e . p e t r i n e t w o r k . hu " s c h e m a L o c a t i o n=" r e c e n t f i l e s _ r f . xsd " /> <x s : e l e m e n t name=" P e t r i N e t w o r k F i l e s " m s d a t a : I s D a t a S e t=" t r u e " m s d a t a : L o c a l e=" en−US" m s d a t a : P r e f i x=" f p n "> <xs:complexType> < x s : c h o i c e minOccurs=" 0 " maxOccurs=" unbounded "> <x s : e l e m e n t r e f=" r f : R e c e n t F i l e " />

3.4. kód. A recentfiles.xml állomány schema-ja


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

67

<x s : s c h e m a t a r g e t N a m e s p a c e=" h t t p : // r e c e n t f i l e . p e t r i n e t w o r k . hu " x m l n s : m s t n s=" h t t p : // f i l e s . p e t r i n e t w o r k . hu " xmlns=" h t t p : // r e c e n t f i l e . p e t r i n e t w o r k . hu " x m l n s : x s=" h t t p : //www. w3 . o r g /2001/XMLSchema" xmlns:msdata=" u r n : s c h e m a s −m i c r o s o f t −com:xml−msdata " a t t r i b u t e F o r m D e f a u l t=" q u a l i f i e d " e l e m e n t F o r m D e f a u l t=" q u a l i f i e d " > <x s : e l e m e n t name=" R e c e n t F i l e " m s d a t a : P r e f i x=" r f "> <xs:complexType> <x s : s e q u e n c e> <x s : e l e m e n t name=" NetworkName " m s d a t a : P r e f i x=" r f " t y p e=" x s : s t r i n g " minOccurs=" 0 " /> <x s : e l e m e n t name=" FileName " m s d a t a : P r e f i x=" r f " t y p e=" x s : s t r i n g " minOccurs=" 0 " /> <x s : e l e m e n t name=" D e s c r i p t i o n " m s d a t a : P r e f i x=" r f " t y p e=" x s : s t r i n g " minOccurs=" 0 " />

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. Futtassuk a 3.6. kódban leírt parancsot, és a kimenetként előálló RecentFiles. PetriNetworkFiles és RecentFiles. RecentFile osztályt importáljuk be a Petri szimulációs alkalmazásba! 1

"%INSTALLDIR%\M i c r o s o f t ␣SDKs\Windows\ v7 . 0A\ Bin \NETFX␣ 4 . 0 ␣ T o o l s \ xsd . exe " ␣ / o u t p u t d i r : s o u r c e ␣/ c l a s s e s ␣ / l a n g u a g e : CS␣ / namespace : P e t r i N e t w o r k S i m u l a t o r . R e c e n t F i l e s ␣ . \ manual \ r e c e n t f i l e s . xsd ␣ . \ manual \ r e c e n t f i l e s _ r f . 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. RecentFilesHelper 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 alkalmazá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űparanccsal (CTRL + num) és tooltip szöveggel együtt.

3.19. ábra. Utoljára megnyitott állományok osztály diagramjai


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 foglalkozunk. 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 irodalomkutatá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ózatokró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 feldolgozá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

[..]
[..]
[..] < p n : V i s i b l e S e t t i n g s> [..] [..] [..]

69

4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

70

[..]
<s h : S t a t e s x m l n s : s h=" h t t p : // s t a t e h i e r a r c h y . p e t r i n e t w o r k . hu "> [..] <s h : E d g e s x m l n s : s h=" h t t p : // s t a t e h i e r a r c h y . p e t r i n e t w o r k . hu "> [..] <S i g n a t u r e xmlns=" h t t p : //www. w3 . o r g /2000/09/ x m l d s i g#"> [..]

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 felsorolá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

<ns:Name n s : v a l u e=" Sample " x m l n s : n s=" h t t p : // s e t t i n g s . p e t r i n e t w o r k . hu " /> < n s : C e r t i f i c a t e S u b j e c t n s : v a l u e="E=bedok . david@nik . uni−obuda . hu , CN=David Bedok , OU=NIK , O=UNI−OBUDA, L=Budapest , S=Hungary , C=HU" x m l n s : n s=" h t t p : // s e t t i n g s . p e t r i n e t w o r k . hu " /> <ns:Width n s : v a l u e=" 400 " x m l n s : n s=" h t t p : // s e t t i n g s . p e t r i n e t w o r k . hu " /> <ns:TokenGenNumber n s : v a l u e=" 20 " x m l n s : n s=" h t t p : // s e t t i n g s . p e t r i n e t w o r k . hu " /> [..] [..]

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, tartalma 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) hatá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 kereszthivatkozni í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 inicializá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 gyakorlatias, 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 „sebessé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ástechnikai 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 speciá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 LastModificationDate). 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


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 5 6 7 8 9 10 11 12

[..] A r i a l 10
[..]

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 vastagsá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 (DefaultPen), alapértelmezett él ecset (DefaultEdgePen), megjelölt elem ecsete (MarkPen),


73

kijelölt él ecsete (SelectedEdgePen), kijelölt topológia elem ecsete (SelectedItemPen), vizuá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 megnevezéseik törlése), mely nyilván egy nagyon kényelmetlen lehetőség volna. 1 2 3 4

< p n : V i s i b l e S e t t i n g s> [..]

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 megjelenítése szabályozható globálisan: élek súlyai (EdgeWeight) és feliratai (EdgeLabel), annotá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 (TransitionLabel), tüzelésre kész tranzíciók jelölése/nem jelölése (ReadyToFireTransitions) illetve 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 megjegyzé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 memó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

< i : P o s i t i o n . . . x m l n s : i=" h t t p : // item . p e t r i n e t w o r k . hu "> [..] < i : T r a n s i t i o n . . . x m l n s : i=" h t t p : // item . p e t r i n e t w o r k . hu "> [..] [..]

4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 12 13 14 15 16 17 18 19 20 21 22 23

74

<e dg :E dge . . . x m l n s : e d g=" h t t p : // edge . p e t r i n e t w o r k . hu "> [..] [..] [..] [..]

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évté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 tartozó 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évté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. Minden Token példány (tok:Token tag) az AbstractItemből származik, innen eredeztethető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

< i : P o s i t i o n b i : n a m e=" P1 " b i : u n i d=" 1 " b i : s h o w a n n o t a t i o n=" True " i : r a d i u s=" 20 " p o s : c a p a c i t y l i m i t=" 0 " x m l n s : p o s=" h t t p : // p o s i t i o n . p e t r i n e t w o r k . hu " x m l n s : b i=" h t t p : // b a s e i t e m . p e t r i n e t w o r k . hu " x m l n s : i=" h t t p : // item . p e t r i n e t w o r k . hu ">

< s f : S i z e s f : w i d t h=" 40 " s f : h e i g h t=" 40 " x m l n s : s f=" h t t p : // s i z e f . p e t r i n e t w o r k . hu " />
[..]
[..]

4.7. kód. Pozíciók XML modellje


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á tartoznak. 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

< i : T r a n s i t i o n b i : n a m e=" T1 " b i : u n i d=" 2 " b i : s h o w a n n o t a t i o n=" True " i : r a d i u s=" 1 0 , 3 0 7 7 6 " t r a : a n g l e=" 23 " t r a : p r i o r i t y=" 0 " t r a : t y p e="NORMAL" t r a : d e l a y=" 0 " t r a : c l o c k R a d i u s=" 5 " x m l n s : t r a=" h t t p : // t r a n s i t i o n . p e t r i n e t w o r k . hu " x m l n s : b i=" h t t p : // b a s e i t e m . p e t r i n e t w o r k . hu " x m l n s : i=" h t t p : // item . p e t r i n e t w o r k . hu ">

< s f : S i z e s f : w i d t h=" 5 " s f : h e i g h t=" 20 " x m l n s : s f=" h t t p : // s i z e f . p e t r i n e t w o r k . hu " />

[..]

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 azonosí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 egyenes 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 4 5 6 7 8 9

<e dg :E dge b i : n a m e=" " b i : u n i d=" 14 " b i : s h o w a n n o t a t i o n=" True " e d g : w e i g h t=" 1 " e d g : t y p e=" NORMAL" x m l n s : b i=" h t t p : // b a s e i t e m . p e t r i n e t w o r k . hu " x m l n s : e d g=" h t t p : // edge . p e t r i n e t w o r k . hu "> <e d g : S t a r t e d g : r e f t y p e="TRANSITION">2 <edg:End e d g : r e f t y p e="POSITION">1
[..]

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 valamely 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.


1 2

3 4 5 6 7 8 9 10

76

< s f : S i z e s f : w i d t h=" 100 " s f : h e i g h t=" 40 " x m l n s : s f=" h t t p : // s i z e f . p e t r i n e t w o r k . hu " /> new n o t e [..]

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, melynek topológiája a Petri hálóhoz hasonlatosan tárolható XML-ben. Először a gráf sarokpontjai, 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 esemé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 21 22 23 24 25

<s h : S t a t e s x m l n s : s h=" h t t p : // s t a t e h i e r a r c h y . p e t r i n e t w o r k . hu "> <s v : S t a t e V e c t o r sv:name="m0" s v : u n i d=" 31 " s v : r a d i u s=" 20 " x m l n s : s v=" h t t p : // s t a t e v e c t o r . p e t r i n e t w o r k . hu ">
<s v : T o k e n D i s t r i b u t i o n s> <s v : P o s i t i o n s v : u n i d=" 0 "> <s v : T o k e n s v : u n i d=" 26 " /> [..] [..] <s v : E v e n t s>
[..] <s h : E d g e s x m l n s : s h=" h t t p : // s t a t e h i e r a r c h y . p e t r i n e t w o r k . hu "> <s e : S t a t e E d g e x m l n s : s e=" h t t p : // s t a t e e d g e . p e t r i n e t w o r k . hu "> < s e : S t a r t S t a t e>31 <s e : E n d S t a t e>28 [..]

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 felhaszná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), csupá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 programozottan 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üksé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 2 3 4 5

s e t ␣ROOTCA_FILE_PREFIX=p e t r i r o o t c a s e t ␣KEYS_DIR=.\ k e y s \ s e t ␣ROOTCA_KEY_FILENAME=%ROOTCA_FILE_PREFIX%. key s e t ␣ROOTCA_KEY_FILE=%KEYS_DIR%%ROOTCA_KEY_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ g e n r s a ␣−d e s 3 ␣−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 genrsa 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 2 3 4 5 6

s e t ␣ROOTCA_KEY_PASSWORD=c h a n g e i t r o o t s e t ␣OSSL_CONFIG=o p e n s s l . c o n f s e t ␣ROOT_CERTS_DIR= . \ . . \ r o o t c a \ c e r t s \ s e t ␣ROOTCA_CERT_PEM_FILENAME=%ROOTCA_FILE_PREFIX%.pem . c e r s e t ␣ROOTCA_CERT_PEM_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_PEM_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ r e q ␣−c o n f i g ␣%OSSL_CONFIG%␣−new␣−x509 ␣− sha384 ␣−days ␣ 1826 ␣−key ␣%ROOTCA_KEY_FILE%␣−p a s s i n ␣ p a s s :% ROOTCA_KEY_PASSWORD%␣−e x t e n s i o n s ␣ x 5 0 9 v 3 _ e x t e n s i o n s ␣−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 csomagolá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).


1 2 3 4 5

79

[ ␣ x509v3_extensions ␣ ] b a s i c C o n s t r a i n t s=c r i t i c a l ,CA: t r u e , p a t h l e n : 3 keyUsage=keyCertSign , ␣ cRLSign s u b j e c t K e y I d e n t i f i e r=hash a u t h o r i t y K e y I d e n t i f i e r=keyid , i s s u e r

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 2 3

s e t ␣ROOTCA_CERT_DER_FILENAME=%ROOTCA_FILE_PREFIX%. d e r s e t ␣ROOTCA_CERT_DER_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_DER_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ x509 ␣−i n ␣%ROOTCA_CERT_PEM_FILE%␣−i n f o r m ␣ 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 érdeké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 parancssori 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 2 3 4 5 6

s e t ␣ROOTCA_CERTSTORE_PASSWORD=c h a n g e i t s e t ␣ROOTCA_ALIAS=r o o t c a s e t ␣STORE_DIR=.\ s t o r e \ s e t ␣ROOTCA_CERTSTORE_FILENAME=%ROOTCA_FILE_PREFIX%. j k s s e t ␣ROOTCA_CERTSTORE=%STORE_DIR%%ROOTCA_CERTSTORE_FILENAME% %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣−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 ␣− t r u s t c a c e r t s

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.


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 tanú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 2 3 4

s e t ␣SUBCA_FILE_PREFIX=p e t r i s u b c a s e t ␣SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%. key s e t ␣SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ g e n r s a ␣−d e s 3 ␣−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 felhaszná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 2 3 4 5 6 7

s e t ␣ROOT_CSR_DIR= . \ . . \ r o o t c a \ c s r \ s e t ␣SUBCA_CSR_FILENAME=%SUBCA_FILE_PREFIX%. c s r s e t ␣SUBCA_CSR_FILE=%ROOT_CSR_DIR%%SUBCA_CSR_FILENAME% s e t ␣SUBCA_KEY_PASSWORD=c h a n g e i t s u b s e t ␣SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%. key s e t ␣SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ r e q ␣−c o n f i g ␣%OSSL_CONFIG%␣−new␣−days ␣ 1096 ␣ −sha384 ␣−key ␣%SUBCA_KEY_FILE%␣−p a s s i n ␣ p a s s :%SUBCA_KEY_PASSWORD%␣− e x t e n s i o n s ␣ x 5 0 9 v 3 _ e x t e n s i o n s ␣−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. Ennek 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


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 2 3

s e t ␣SUBCA_CERT_PEM_FILENAME=%SUBCA_FILE_PREFIX%.pem . c e r s e t ␣SUBCA_CERT_PEM_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_PEM_FILENAME% %OPENSSL_HOME%\b i n \ 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 ␣ p a s s :%ROOTCA_KEY_PASSWORD%␣−c e r t ␣% ROOTCA_CERT_PEM_FILE%␣−i n ␣%SUBCA_CSR_FILE%␣ ␣−e x t e n s i o n s ␣ x 5 0 9 v 3 _ e x t e n s i o n s ␣−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 2 3

s e t ␣SUBCA_CERT_DER_FILENAME=%SUBCA_FILE_PREFIX%. d e r s e t ␣SUBCA_CERT_DER_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_DER_FILENAME% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ x509 ␣−i n ␣%SUBCA_CERT_PEM_FILE%␣−i n f o r m ␣PEM ␣−out ␣%SUBCA_CERT_DER_FILE%␣−outform ␣DER

4 5 6 7 8 9

s e t ␣SUBCA_ALIAS=subca s e t ␣SUBCA_CERTSTORE_PASSWORD=c h a n g e i t s e t ␣SUBCA_CERTSTORE_FILENAME=%SUBCA_FILE_PREFIX%. j k s s e t ␣SUBCA_CERTSTORE=%STORE_DIR%%SUBCA_CERTSTORE_FILENAME% %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣−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 ␣− t r u s t c a c e r t s

10 11 12 13

14

s e t ␣SUBCA_CERTPATHSTORE_FILENAME=%SUBCA_FILE_PREFIX%. path . j k s s e t ␣SUBCA_CERTPATHSTORE=%STORE_DIR%%SUBCA_CERTPATHSTORE_FILENAME% %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣−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 ␣− t r u s t c a c e r t s %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣−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 ␣− t r u s t c a c e r t s

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ábban 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 Universitas 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


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 segí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 2 3 4 5 6 7 8 9 10 11 12 13 14 15

s e t ␣KEYALG=RSA s e t ␣KEYSIZE=1024 s e t ␣SIGALG=SHA1withRSA s e t ␣END_ALIAS=p e t r i s e t ␣END_FILE_PREFIX=uniobuda s e t ␣END_KEYSTORE_FILENAME=%END_FILE_PREFIX%_ p r i v a t e . j k s s e t ␣END_KEYSTORE=%OUTPUTDIR%%END_KEYSTORE_FILENAME% s e t ␣CERT_CN=U n i v e r s i t a s ␣ B u d e n s i s s e t ␣CERT_OU=NIK s e t ␣CERT_O=UNI−OBUDA s e t ␣CERT_L=Budapest s e t ␣CERT_S=Hungary s e t ␣CERT_C=HU s e t ␣END_KEYSTORE_PASSWORD=c h a n g e i t s t o r e s e t ␣END_PRIVATEKEY_PASSWORD=p e t r i p a s s

16 17

%KEYTOOL_HOME%\b i n \ k e y t o o l ␣−g e n k e y p a i r ␣−k e y a l g ␣%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%␣−k e y p a s s ␣%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 2 3

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

4 5

%KEYTOOL_HOME%\b i n \ k e y t o o l ␣−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%␣−s t o r e p a s s ␣% END_KEYSTORE_PASSWORD%␣−k e y p a s s ␣%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 állománya el lett juttatva a Sub CA felé, a certificate aláírása megtörténhet. Ehhez hasonlóan


83

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

5

[ ␣ x509v3_extensions_nonca ␣ ] b a s i c C o n s t r a i n t s=c r i t i c a l ,CA: f a l s e keyUsage=d i g i t a l S i g n a t u r e , ␣ nonRepudiation , ␣ keyEncipherment extendedKeyUsage=serverAuth , ␣ c l i e n t A u t h , ␣ c o d e S i g n i n g , ␣ e m a i l P r o t e c t i o n , ␣ timeStamping s u b j e c t K e y I d e n t i f i e r=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 dokumentumok digitális aláírása és a kulcs csere (pl. SSL/TLS kapcsolat felépítése) szerepelni fog (keyUsage=digitalSignature, nonRepudiation, keyEncipherment). 1 2

s e t ␣END_LONG_CERT_PEM_FILENAME=%END_FILE_PREFIX%. l o n g . pem . c e r s e t ␣END_LONG_CERT_PEM_FILE=%END_OUTPUT_DIR%% END_LONG_CERT_PEM_FILENAME%

3 4

%OPENSSL_HOME%\b i n \ 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%␣−i n ␣%END_CSR_FILE%␣− k e y f i l e ␣%SUBCA_KEY_FILE%␣−days ␣ 720 ␣−md␣ sha384 ␣−p a s s i n ␣ p a s s :% 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 Java 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 2

s e t ␣END_TMP_CERT_PEM_FILENAME=%END_FILE_PREFIX%.tmp . pem . c e r s e t ␣END_TMP_CERT_PEM_FILE=%OUTPUTDIR%%END_TMP_CERT_PEM_FILENAME%

3 4

5

6

7

%OPENSSL_HOME%\b i n \ o p e n s s l ␣ x509 ␣−i n ␣%END_LONG_CERT_PEM_FILE%␣−out ␣% END_TMP_CERT_PEM_FILE% %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣− 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%␣−s t o r e p a s s ␣% END_KEYSTORE_PASSWORD%␣−noprompt %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣− 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%␣−s t o r e p a s s ␣% END_KEYSTORE_PASSWORD%␣−noprompt %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣− 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%␣−s t o r e p a s s ␣% END_KEYSTORE_PASSWORD%␣−k e y p a s s ␣%END_PRIVATEKEY_PASSWORD%

5.14. kód. Végfelhasználói tanúsítvány konvertálása és csomagolása


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 2 3 4 5 6

s e t ␣END_CERT_DER_FILENAME=%END_FILE_PREFIX%. d e r s e t ␣END_CERT_DER_FILE=%OUTPUTDIR%%END_CERT_DER_FILENAME% s e t ␣END_CERT_PEM_FILENAME=%END_FILE_PREFIX%.pem . c e r s e t ␣END_CERT_PEM_FILE=%OUTPUTDIR%%END_CERT_PEM_FILENAME% s e t ␣END_PKCS12_PASSWORD=c h a n g e i t s t o r e s e t ␣END_CERTSTORE_PASSWORD=c h a n g e i t

7 8

9

10

11

%KEYTOOL_HOME%\b i n \ k e y t o o l ␣−e x p o r t c e r t ␣−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% %OPENSSL_HOME%\b i n \ o p e n s s l ␣ x509 ␣−i n ␣%END_CERT_DER_FILE%␣−i n f o r m ␣DER␣− out ␣%END_CERT_PEM_FILE%␣−outform ␣PEM %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t k e y s t o r e ␣−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%␣−s r c s t o r e t y p e ␣JKS␣−d e s t s t o r e t y p e ␣ PKCS12␣−s r c s t o r e p a s s ␣%END_KEYSTORE_PASSWORD%␣−d e s t s t o r e p a s s ␣% END_PKCS12_PASSWORD%␣−s r c k e y p a s 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 %KEYTOOL_HOME%\b i n \ k e y t o o l ␣−i m p o r t c e r t ␣−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 ␣− t r u s t c a c e r t s

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 adatbázisok (OpenSSL file alapú adatbázist készít), valamint néhány végfelhasználói certificate, 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 elmentett 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


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ánja 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ő érté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 indulá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 alkalmazá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, melyben 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 kimentett 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álható 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 fejezet 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 haszná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 szimulá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ályok , 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áltozá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, utalva 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. 3

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 (kevé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 AbstractTransition osztály.


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 feleslegessé 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: Edges, 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).


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 (StatesName), 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-


90

mények neveit, majd azokhoz objektum-orientált értelemben vett eseménykezelőket rendelü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 osztá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átszó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, RESETFIRE 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énylegesen 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 regisztrá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<String, PetriHandler> 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


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 d e l e g a t e v o i d P e t r i H a n d l e r ( A b s t r a c t E v e n t D r i v e n I t e m item , EventType eventType ) ;

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

p u b l i c c l a s s P e t r i N e t w o r k : System . O b j e c t { [..] p r i v a t e D i c t i o n a r y <S t r i n g , P e t r i H a n d l e r > h a n d l e r s ; [..] p u b l i c L i s t <S t r i n g > EventsName { [..] } [..] p u b l i c v o i d b i n d P e t r i E v e n t ( s t r i n g eventName , P e t r i H a n d l e r h a n d l e r ) { [ . . ] } p u b l i c v o i d u n b i n d P e t r i E v e n t ( s t r i n g eventName , P e t r i H a n d l e r h a n d l e r ) { [ . . ] } [..] p r i v a t e P e t r i H a n d l e r getPetriEventByName ( s t r i n g eventName ) { [ . . ] } p r i v a t e P e t r i H a n d l e r getPetriEventByTrunk ( L i s t
e v e n t s ) { [ . . ] } [..] p r i v a t e v o i d c h e c k H a n d l e r ( A b s t r a c t E v e n t D r i v e n I t e m item , EventType eventType ) { L i s t
e v e n t s = item . EventTrunk . getEventsByType ( eventType ) ; P e t r i H a n d l e r h a n d l e r = getPetriEventByTrunk ( e v e n t s ) ; i f ( h a n d l e r != n u l l ) { h a n d l e r ( item , eventType ) ; } } [..] }

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énykezelő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 pontosan 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 2 3 4

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] Random rand = new Random ( ) ; P e t r i N e t w o r k network = P e t r i N e t w o r k . openFromXml ( rand , @" n e t w o r k s \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


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 esemé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ú paraméterrel tudjuk azonosítani hogy épp melyik hajtódott végre (pl. PREACTIVATE vagy POSTACTIVATE). 1 2 3 4 5 6 7 8 9 10 11 12 13

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] p r i v a t e s t a t i c v o i d e v e n t H a n d l e r ( A b s t r a c t E v e n t D r i v e n I t e m item , EventType eventType ) { S t r i n g B u i l d e r sb = new S t r i n g B u i l d e r ( 1 0 0 ) ; sb . Append ( " e v e n t H a n d l e r ( item : " + item . Name + " , eventType : "+eventType+" ) " ) ; i f ( item i s P o s i t i o n ) { P o s i t i o n p o s i t i o n = ( P o s i t i o n ) item ; sb . Append ( " t o k e n count : " + p o s i t i o n . TokenCount ) ; } System . C o n s o l e . W r i t e L i n e ( sb . T o S t r i n g ( ) ) ; }

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 objektumorientált kapcsolat létrehozására. A hálózat példányának bindPetriEvent() metódusa segí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 2 3 4 5 6 7 8 9 10

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] try { network . b i n d P e t r i E v e n t ( "dummy" , new P e t r i H a n d l e r ( e v e n t H a n d l e r ) ) ; } c a t c h ( ArgumentException e ) { System . C o n s o l e . W r i t e L i n e ( e . Message ) ; }

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ülső, 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 vizsgá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ő.


93

így visszakapott listát feldolgozhatjuk és a Petri eseményeket egy a célnak megfelelő általá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 2 3 4 5 6 7 8

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] L i s t <S t r i n g > l i s t O f E v e n t s = network . EventsName ; f o r e a c h ( S t r i n g item i n l i s t O f E v e n t s ) { network . b i n d P e t r i E v e n t ( item , new P e t r i H a n d l e r ( e v e n t H a n d l e r ) ) ; network . b i n d P e t r i E v e n t ( item , new P e t r i H a n d l e r ( e v e n t H a n d l e r 2 ) ) ; }

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 2 3 4 5 6 7 8 9 10

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] F i r e E v e n t f i r e E v e n t = F i r e E v e n t . INITFIRE ; FireReturn f i r e R e t u r n = n u l l ; w h i l e ( ! F i r e E v e n t .DEADLOCK. E q u a l s ( f i r e E v e n t ) ) { f i r e R e t u r n = network . f i r e ( ) ; System . C o n s o l e . W r i t e L i n e ( f i r e R e t u r n ) ; f i r e E v e n t = f i r e R e t u r n . FireEvent ; }

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ásra 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 monitorozá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. ábra), melyen lehetőségünk van kiválasztani valamely háttértárról a titkos kulcsunkat tartalmazó 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 validá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 elmenteni.

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 megnyitni, 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ózatot. 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őbbiekben, azonban érdemes a megjelent adatokat inicializálni. A hálózat grafikus kiterjedé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 szerint 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. Titkos 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.


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íthatjuk. 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 jelení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 felhaszná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 integritá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 úgyne1

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.


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-


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 rendelkezik az összes olyan elemmel, melyre a hálózat szerkesztéséhez szükségünk lesz. Számos


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 kezdjük. Válasszuk ki valamelyik eszközt, látni fogjuk hogy a Paletta adott funkciógombja benyomódik. Ez jelzi az aktuálisan kiválasztott eszközt, azonban nem csupán ez: ha a szerkesztő 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. Helyezzü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 triggerelni. 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.


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 elemek á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 elemek, 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áltoztatja, 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 sikeresen 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 egyedi 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 tulajdonsá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 pozí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 megjelenik, é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.


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 jelení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 állapotban 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ökkenő). 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érhető Á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 állapothierarchia 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 termé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 automatikusan 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 mindaddig memóriában maradnak (illetve a PN.XML kimenet részeit fogják képezni), amíg a


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 aktuá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,


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ő tranzí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


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 haszná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 állapotok 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-spaceeik „_”-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 alkalmazá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


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 esemé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 esemé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 alaposabban. 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ó


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ásodikké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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

u s i n g P e t r i N e t w o r k L i b r a r y . Model . NetworkItem ; [..] p r i v a t e P e t r i N e t w o r k network ; p r i v a t e L i s t r e s u l t ; [..] t h i s . network = P e t r i N e t w o r k . openFromXml ( t h i s . rand , @" network \ H o r s e r a c e . pn . xml " ) ; t h i s . network . b i n d P e t r i E v e n t ( " g o a l " , new P e t r i H a n d l e r ( e v e n t H a n d l e r ) ) ; [..] p r i v a t e v o i d e v e n t H a n d l e r ( A b s t r a c t E v e n t D r i v e n I t e m item , EventType eventType ) { i f ( item i s P o s i t i o n ) { P o s i t i o n p o s i t i o n = ( P o s i t i o n ) item ; L i s t t o k e n s = p o s i t i o n . Tokens ; i f ( ( t o k e n s != n u l l ) && ( t o k e n s . Count == 1 ) ) { t h i s . r e s u l t . Add( t o k e n s [ 0 ] ) ; } } } [..] 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 19 20 21 22 23 24 25 26 27 28 29 30

107

pri vate void s t a r t ( ) { t h i s . r e s u l t . Clear () ; t h i s . network . s e t S t a r t S t a t e ( " s t a r t " ) ; F i r e E v e n t f i r e E v e n t = F i r e E v e n t . INITFIRE ; FireReturn f i r e R e t u r n = n u l l ; w h i l e ( ! F i r e E v e n t .DEADLOCK. E q u a l s ( f i r e E v e n t ) ) { f i r e R e t u r n = t h i s . network . f i r e ( ) ; f i r e E v e n t = f i r e R e t u r n . FireEvent ; } }

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 kihaszná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óverseny eredményének első három helyezettjére voltam kíváncsi. Nyilvánvalóan a véletlenszerű 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űszerezni 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 logikai 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 imperatí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. 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). 2

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 esemény a hálózat több különböző pontján is előállhat, ezért szerepelhet ugyanaz az elnevezé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ótartalommal 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 irodalomkutatá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 Environment, 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árható 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 lehetett volna olyan egyetemi projekt kapcsán készülő szimulátort találni, melybe a Petri esemé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 szerkesztő é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 Universitas 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ábbfejleszté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/konferencia 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 felmerü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 declarative 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 BadenWuerttemberg). 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 Berlin). 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] Jo˜ ao 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-Universit¨ at 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.

Diplomamunka. Petri hálók szimulációja és alkalmazásuk objektum-orientált környezetben. készítette: Bedők Dávid v0.4

Recommend Documents