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.

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "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."

Átírás

1 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 december 12. Ajka 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

2 Tartalomjegyzék Absztrakt v 1. Bevezetés 1 2. Irodalomkutatás Prof. Dr. Carl Adam Petri Petri hálók Alap- és általános hálózat teória Előnyök/Hátrányok Kiterjesztések Reset él bevezetése (Reset arc) Kapacitás korlát bevezetése (Capacity limit) Tiltó él bevezetése (Inhibitor arc) Priorizált Petri hálók (Prioritised Petri nets) Színezett Petri hálók (Coloured Petri nets) Időzített Petri hálók (Timed Petri nets) Algebrai Petri hálók (Algebraic Petri nets) Hierarchikus Petri hálók (Hierarchical Petri nets) Objektum-orientált Petri hálók (Concurrent OO Petri Nets) Hibrid Petri hálók (Hybrid Petri nets) Folyamat hálózatok (Workflow nets) Petri Nets 2008 konferencia Matematikai modell Példa modell Petri Net Markup Language (PNML) Általános PNML szerkesztő - epnk GDToolkit - Automata gráf rajzoló könyvtár Perti háló szerkesztők JARP Petri Nets Analyzer i

3 TARTALOMJEGYZÉK ii CPN Tools Petri Net Kernel Hybrid Petri Nets Simulator HPSim Platform Independent Petri net Editor Queueing Petri net Modeling Environment Renew Tool for Verification of Timed-Arc Petri Nets További eszközök Alkalmazások összehasonlítása XML állomány hitelességének biztosítása Gyakorlati és feltétel nélküli titkosság Kulcscsere Szimmetrikus titkosítás Aszimmetrikus titkosítás Az RSA algoritmus Certificate authority Eszközök és szabványok Java Keytool Portecle Open SSL Irodalomkutatás tanulsága Rendszerterv Modellezés Kiegészítő specifikációk Nem funkcionális követelmények Kockázatok Üzleti szabályok Kifejezések Használati esetek, űrlapok és forgatókönyvek Actorok Elsődleges használati eset Sikertelen forgatókönyv Modulok Petri paletta modul

4 TARTALOMJEGYZÉK iii Állapot mátrix modul Állapot-hierarchia modul Térkép modul Szomszédossági mátrix modul Statisztika modul Események modul Tranzíció történet modul Aktivitás diagramok Elsődleges aktivitás Szimuláció aktivitás diagramja Együttműködési diagramok Osztály diagramok Kriptográfiai osztályok Lokalizáció Dialógusok Felsorolás típusok Űrlapok Képviselők Petri hálózatok Petri tételek osztályai Állapotvektorok osztályai Petri események Modul ablakok osztályai Utoljára megnyitott állományok További osztályok Petri hálózatok tárolása Globális tulajdonságok Globális események Vizuális beállítások Láthatósági/megjelenítési beállítások Topológia Állapot-hierarchia

5 TARTALOMJEGYZÉK iv 5. Integritás védelem Root CA létrehozása Sub CA létrehozása Sub CA tanúsítványának aláírása Végfelhasználói kulcs generálása Végfelhasználói kulcs tanúsítványának aláírása Integráció a Petri szimulátorral Bejelentkezési folyamat Megnyitási folyamat Modell alkalmazása OO környezetben Petri hálózat API bemutatása Topológia és egyéb építőkövek osztályai Petri hálózat osztálya Eseményvezérlés osztályai Petri hálózat API felhasználása Eredmények bemutatása Bejelentkezés Új hálózat létrehozása Létező hálózat megnyitása Modulok Petri paletta Állapot mátrix Állapot-hierarchia Szomszédossági mátrix Statisztika és Tranzíció történet Petri események Lóverseny Összefoglalás 108 Résumé 110 Ábrák jegyzéke 112 Kódjegyzék 115 Irodalomjegyzék 117

6 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 LINQ 1 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

7 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

8 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 július 12 - Siegburg július 2) feltalálta a Petri hálókat, eredetileg kémiai folyamatok leírására (2.1. ábra) ábra. Kémiai folyamatok leírása Petri hálókkal[7] 15 éves korában édesapja mesélt neki Konrad Zuse[4] (Berlin június 22 - Hünfeld 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 jellemezte 1. 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 ban diplomázik, majd két évig még az egyetemnél marad 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) és 1968 között a bonni egyetemen dolgozik, majd ezt követően a GMD 2 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

9 2. FEJEZET. IRODALOMKUTATÁS ábra. Prof. Dr. Carl Adam Petri, augusztus 21.[3] tiszteletbeli professzora lett 1988-ban, hivatalosan 1991-ben vonult nyugdíjba. Az ban alapított Academia Europaea tagja, 1997-ban a tekintélyes Werner von Siemens Ring német kitüntetést kap, és még ebben az évben tagja lesz a New York Academy of Sciences -nek ben az ATLAS-tól 3 (Academy Gold Medal of Honor), 2009-ben pedig az IEEE-től 4 kapott kitüntetést (Computer Pioneer Award)[6] á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 Academy of Transdisciplinary Learning and Advanced Studies 4 Institute of Electrical and Electronics Engineers

10 2. FEJEZET. IRODALOMKUTATÁS á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) ábra. Egy Petri háló szerkezetének mintája

11 2. FEJEZET. IRODALOMKUTATÁS 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 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 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) 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.

12 2. FEJEZET. IRODALOMKUTATÁS 6 Minden éremnek azonban két oldala van. Már egy egyszerűbb valós problémának a modellezéséhez is nagy Petri háló szükséges, és egy idő után a modell mérete az átláthatóságot rontja. Ezen utóbbira egy lehetséges megoldást nyújtanak a Színezett Petri hálók (lásd. a fejezetet a 7. oldalon) 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.

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

14 2. FEJEZET. IRODALOMKUTATÁS á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 problem 5 ) 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]

15 2. FEJEZET. IRODALOMKUTATÁS á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 á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.

16 2. FEJEZET. IRODALOMKUTATÁS á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 ábra. Információ gyűjtés

17 2. FEJEZET. IRODALOMKUTATÁS 11 Az Információ gyűjtés során a tranzíció tüzelésre kész, és a bementén lévő pozíciók tokenjei átkerülnek a kimenetére. Ezt a helyzetet nyílt alhálózatnak nevezhetjük (open subnet) á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 Matematikai modell A Petri hálózatok matematikai modellje Tadao Murata á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.

18 2. FEJEZET. IRODALOMKUTATÁS 12 Definiálhatjuk t jelölést, mely egy t T tranzíció kapcsán a bemeneti pozíciókat jelöli az adott tranzícióra nézve: t = {p P W (p, t) > 0} (vesszük azokat a pozíciókat, melyekből bármely t T tranzíció irányába él vezet). Definiálhatjuk a t jelölést, mely egy t T tranzíció kapcsán a kimeneti pozíciókat jelöli az adott tranzícióra nézve: t = {p P W (t, p) > 0} (vesszük azokat a pozíciókat, melyekhez bármely t T tranzíció irányából él vezet). Definiálhatjuk a p jelölést, mely egy p P pozíció kapcsán azokat a tranzíciókat jelöli, melyből ő tokeneket kaphat: p = {t T W (t, p) > 0}. Definiálhatjuk a p jelölést, mely egy p P pozíció kapcsán azokat a tranzíciókat jelöli, melyekbe ő tokeneket adhat: p = {t T W (p, t) > 0}. m pi jelölje egy hely p i 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 m p értékeket: M = [m p1, m p2..m pk ] T ahol G hálónak k darab pozíciója van. M-et a G hálózat állapotának tekinthetjük. M 0 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, M 0 ) is megadni Példa modell Vizsgáljunk meg a ábrán látott G = (P, T, W, M 0 ) hálózatot és írjuk fel a matematikai modellnek megfelelő halmazokat, vektorokat és mátrixokat ábra. Kiindulási M 0 á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 1 = {T 2} P 2 = {T 3} P 2 = {T 2} P 3 = {T 2} P 3 = {T 1, T 3} P 4 = {T 3} P 4 = {T 1} míg a tranzíciókra nézve: T 1 = {P 3, P 4} T 1 = {P 1} T 2 = {P 1, P 2} T 2 = {P 3} T 3 = {P 3} T 3 = {P 2, P 4}

19 2. FEJEZET. IRODALOMKUTATÁS 13 A most bemutatott topológiában az élek súlya nem kap szerepet. Ezt orvosolva elkészíthetjük a modell szomszédossági mátrixát is. Ehhez először fel kell írnunk a pozíciókból elinduló élek súlyát a következő W mátrixban. W = 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 = P 1 P 2 P 3 P 4 T T T Ezt követően a W + mátrixot is megfogalmazzuk, a pozíciókba bemenő élek súlyával. W + = A szomszédossági mátrix a két mátrix elemenkénti kivonásával keletkezik: W T = W + W. W T = A kezdeti állapotban (2.12. ábra) összesen három token található, melyeknek eloszlása a következő M 0 = [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) ábra. M 1 á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: M 1 = [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ó

20 2. FEJEZET. IRODALOMKUTATÁS ábra. M 2 á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: M 2 = [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ő: M 3 = [0, 0, 3, 0] T (2.15. ábra) ábra. M 3 á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 = Az utolsó lépésben kialakuló M 6 á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 M 6 azonban nem az egyetlen végállapot a modellben. A szimuláció során több ponton voltak nem-determinisztikus lépések (M 1, M 4 és M 5 állapotok esetén), melyek alternatív futási ágakat eredményezhetnek. A ábráról leolvasható az állapotok hierarchia eloszlása és a három lehetséges végállapot is: M 2B, M 5B és M 6.

21 2. FEJEZET. IRODALOMKUTATÁS ábra. M 3 állapot á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)

22 2. FEJEZET. IRODALOMKUTATÁS 16 Tina (LAAS/CNRS) Petri Web (Technische Universiteit Eindhoven) WoPeD (Workflow Petri Net Designer, Berufsakademie Karlsruhe) ProM (TU/e) Pneditor Yasper (Yet Another Smart Process Editor) Á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, 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 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] 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 á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) ábra. GDToolkit generált Petri hálója[22]

23 2. FEJEZET. IRODALOMKUTATÁS 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éhez 7. 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 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 á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 hamburg.de/tgi/petrinets/tools/quick.html

24 2. FEJEZET. IRODALOMKUTATÁS CPN Tools Színezett Petri hálók szerkesztésére alkalmas ingyenes desktop alkalmazás[24], legfrissebb verziója júliusi (lásd á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 ábra. CPN Tools[24] Menteni részletes XML dokumentumba lehet, melyhez verziónként DTD állomány is elérhető (legfrissebb í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 Petri Net Kernel Python és Java nyelven érhető el a szintén ingyenes PNK legfrissebb verziója, mely már nem mondható frissnek ( ). 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.

25 2. FEJEZET. IRODALOMKUTATÁS 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 á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 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,

26 2. FEJEZET. IRODALOMKUTATÁS 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 á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 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 ( fejezet) alapjaira épül, teljesen hasonló a menüszerkezetük alapja, az XML kimenetük, illetve az ikonkészletük. A á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 szeptemberi forrásról árulkodik.

27 2. FEJEZET. IRODALOMKUTATÁS á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 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 ábra. Queueing Petri net Modeling Environment[28] A projekt fejlesztése jelenleg is folyik a modell analizálás területén.

28 2. FEJEZET. IRODALOMKUTATÁS 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.

29 2. FEJEZET. IRODALOMKUTATÁS 23 A Renew szerkesztőjében megtalálható egy úgynevezett manuális tranzíció (manual transition). Ha a szimuláció során az adott tranzíció tüzelhetne, akkor a folyamat megáll, és egérrel a felhasználónak kell a szimulációt továbbvinnie 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 fejezet) hasonlóan a Hybrid Petri Nets Simulatorra (lásd fejezet) épül, így szerkesztője nagy meglepetést nem tartogat. Szállító (transport arc) és tiltó éleket támogat ábra. Tool for Verification of Timed-Arc Petri Nets[30] A ábra egy termelő-fogyasztó probléma modelljét mutatja be az alkalmazás keretrendszerében 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.

30 2. FEJEZET. IRODALOMKUTATÁS 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 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 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ó JARP CPN PNK HPNS HP PIPE QPME RN TVT Reset él x Súlyozott élek x x x x x x x x Többszörös élsúlyok x x Kapacitás korlát x x x x Tiltó él x x x x x x Tranzíció prioritás x x Időzített tranzíciók x x x x x x 2.1. táblázat. Alapvető kiterjesztések szerint Az alkalmazások általában egy meghatározott Petri háló kiterjesztés köré készültek, illetőleg egy egyedi kiterjesztés referencia implementációi. Ezért összehasonlításuk során csupán az alapvető kiterjesztések kerülnek be a táblázatba (2.1. táblázat).

31 2. FEJEZET. IRODALOMKUTATÁS 25 Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Tokenjáték manuális x x x Speciális léptetéssel manuális tranzícióval Automata tokenjáték x x x x x szimuláció Tokenjáték egér kattintással x x Állapot visszaállítás x Kezdeti állapot Kezdeti állapot x Tüzelésre kész tranzíciók jelölése x 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ó JARP CPN PNK HPNS HP PIPE QPME RN TVT Vizuális tokenek (kis mé száma retben 0) Megtörhető él Egyenesek, Van, Megfelelő Egyenesek Egyenesek, Egyenesek, Egyenesek rajzolás több szinten de nem és görbék, több szin- illetve gör- mentén, aránytartó két szinten ten bék, tet- tetsző- szőleges törésponttaleges törésponttal Méretezhetőség Korlátlan 3 méret 5 méret Tranzíciók 45 fok 45 fok 45 fok forgatása Feliratok kikapcsolhatósága x x x x x Annotációk, jegyzetek x x x x x x Hálózat nagyítása, kicsinyítése x x x x Grafikus annotációk Geometriai alakzatok 2.3. táblázat. Grafikai beállítások szerinti összehasonlítás Geometriai alakzatok, képek 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 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.

32 2. FEJEZET. IRODALOMKUTATÁS 26 Exportálási lehetőség GIF, JPEG, PNG, PPM PNG, PS BMP, TXT, HPX (INI) PNG, PS, edspn PNG, TikZ Funkció JARP CPN PNK HPNS HP PIPE QPME RN TVT Tulajdonság Helyi ikonok Helyi Helyi Helyi me- Tulajdonság Tulajdonság Helyi módosítás menü menü nü lap, helyi lap nü menü Grafikus csoportosítás x x Modulok Riportot Eclipse-re generáló épül, a modulok lehetősége adott Statisztika modulként x Rácsháló Van, és x x x három fix szinten sűríthető Rácshálóhoz x x x igazítás Tranzíció x történet Mentési formátum ARP, XML XML HPS PNML PNML PNML me- PS, 2.4. táblázat. Egyéb szempontok szerinti összehasonlítás 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álnak 9. Így bár a gyakorlati titkosság módszereit elvekben a jövő számítógépei fel tudják majd törni 10, 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 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, ben pedig egy 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 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).

33 2. FEJEZET. IRODALOMKUTATÁS 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ó 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 ) 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 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 (m A és m B üzenetet szeretnének kicserélni), és feltesszük hogy mindkettőjük rendelkezik egy-egy kulcspárral (Alice nyilvános kulcsa legyen k A, titkos kulcsa pedig s A, Bob-é pedig ennek megfelelően k B és s B ) akkor az üzenetváltásuk a következőképpen zajlik. Alice m A ü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. c A = E(m A, k B ) Bob az egyetlen, aki a c A rejtjelet vissza tudja fejteni, saját titkos kulcsával. m A = E 1 (c A, s B ) Bob a válasz üzenetét Alice nyilvános kulcsával kódolja be, melyet egyedül Alice fog tudni visszafejteni.

34 2. FEJEZET. IRODALOMKUTATÁS 28 c B = E(m B, k A ) m B = E 1 (c B, s A ) 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ő m A üzenetet nem Bob nyilvános kulcsával, hanem a saját titkos kulcsával írja alá (az aláírás (sign A ) valójában az üzenet lenyomatának (digest, md A ) 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). sign A = E(md A, s A ) md A = E 1 (sign A, k A ) 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 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ával 11, 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.

35 2. FEJEZET. IRODALOMKUTATÁS 29 Ezt követően vizsgáljuk meg mi történik akkor, ha Alice hiteles üzenetet szeretne küldeni egy számára ismeretlen Bob számára (és természetesen Bob sem ismeri Alice-t). Alice az üzenetének lenyomatát aláírja saját titkos kulcsával. Bob az üzenetet megkapja, de mielőtt a benne foglaltakat elhinné, meg akar bizonyosodni arról, hogy azt tényleg Alice írta-e. Ezért Alice CA-jához fordul (Alice Certificate-jének Issuer rekordja tartalmazza a kibocsátó/aláíró CA-t). A benne lévő nyilvános kulcs segítégével meg tud győződni arról, hogy az üzenetet tényleg Alice írta, és a csatornán sehol sem sérült meg ( men in the middle, avagy postás támadás nem érte), magából a CA által aláírt certificate-ből pedig abban lehet biztos, hogy a CA ellenőrizte Alice kilétét, így mögötte tényleg az áll, akinek mondja magát (a CA titkos kulcsa csak a CA-nál van meg, így más nem tud általa aláírt certificate-eket kiállítani). Egy CA Alice kilétét ellenben nem fogja az idők végezetéig garantálni. Ezt mint 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 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ól 12. 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).

36 2. FEJEZET. IRODALOMKUTATÁS 30 1 k e y t o o l genkeypair keyalg 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, Address=info@nik. uni obuda. hu " s t o r e p a s s changeit keypass c h a n g e i t 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 lehet 13 ), a kulcsméretet (pl bit 14 ), az aláírás lenyomatának elkészítéséhez szükséges algoritmust (ez manapság legtöbbször SHA-1 szokott lenni 15 ) 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. address, Address: 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 is 16 ), 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 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.

37 2. FEJEZET. IRODALOMKUTATÁS 31 Store password: magát a JKS elemeit védi (így a trusted list -hez való hozzáféréshez is szükséges). Key password: a JKS-en belül tárolt titkos kulcsot védi. Minden egyes elemet, legyen az titkos kulcs, avagy certificate, egy úgynevezett alias - on keresztül tudunk megcímezni. Az alias teljesen szabadon választható, átnevezhető, nem része a tanúsítványnak. A kulcspár (titkos és nyilvános) elkészítését követően a nyilvános kulcsot 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 keypass c h angeit 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ó algoritmusok 17 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ány 18 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.

38 2. FEJEZET. IRODALOMKUTATÁS á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átumban 19, 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 custompolicy c o n f i g customopenssl. conf c e r t c a _ c e r t i f i c a t e. pem in demo. c s r k e y f i l e ca. key days 720 md sha384 p a s s i n pass : cakeypassword out demo. pem 2.3. kód. Certificate aláírása OpenSSL-lel Az elkészült demo.pem tanúsítvány kibocsátó rekordjában (Issuer) immáron a CA distinguished neve lesz olvasható bárki számára, és ezáltal már nem self-signed 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 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.

39 2. FEJEZET. IRODALOMKUTATÁS 33 1 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 keypass c hangeit 2.4. kód. CA által aláírt tanúsítvány JKS-be importálása keytool-lal 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).

40 2. FEJEZET. IRODALOMKUTATÁS 34 A Petri Net Markup Language (lásd. a 2.5. fejezet) támogatása, vagyis az elkészült Petri hálózatok exportálási lehetősége egy rendkívül elegáns megoldás volna, így 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 fejezet) megoldásának implementálása elégséges volna. A HPSim alkalmazásban (lásd. a 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 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.

41 2. FEJEZET. IRODALOMKUTATÁS 35 Az irodalomkutatásban megvizsgálásra kerültek az aszimmetrikus titkosítás szabványos eszközei annak érdekében, hogy a Petri szerkesztő alkalmazás kimeneti XML állományát digitális aláírással lehessen ellátni. Erre azért lehet szükség, mivel az XML állományt bárki a szerkesztőtől függetlenül módosíthatja, és így pl. Internetre olyan állományok is kikerülhetnek, melyeket a szimulátorba betöltve nem lehet működésre bírni, vagy hibás szimulációt mutatnak be (vagy akár meg se jelennek, a program hiba ágra fut). A hibás szimuláció a legveszélyesebb oktatási szempontból, hiszen ha valaki nem ismeri az elvárt eredményt, nem biztos hogy feltűnik a nem várt viselkedés. A szimulátor indulását követően a felhasználótól egy PKCS12 formátumban letárolt RSA titkos kulcsot fog bekérni. A kulcsot védő szimmetrikus jelszó megadását követően a program ellenőrizni fogja a kulcs tanúsítványának néhány adatát (kibocsátóját, verziószámát 20 é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 X.509.V3 certificate-ek támogatása a cél a megfelelő szintű biztonság elérése érdekében. 21 A SOAP WebService-ek esetén elterjed módszer az aláíró tanúsítvány SOAP-Header-be 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.

42 2. FEJEZET. IRODALOMKUTATÁS 36 Mind az autentikációs, mind a verifikációs lépés során a tanúsítványok lejárati (és kibocsátási) ideje ellenőrizve lesz. Ha a tanúsítvány már lejárt, nem lesz engedélyezett menteni/megnyitni. Ez a funkció használatható lesz pl. egy szemeszterre érvényes 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).

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

44 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 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 Ü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: E=petrisubca@qwaevisz.hu, 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.

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

46 3. FEJEZET. RENDSZERTERV 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ú 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-

47 3. FEJEZET. RENDSZERTERV 41 mint ezek űrlapjai (Use case form). Ahol indokolt, ott sikeres (Primary Happy scenario) és sikertelen forgatókönyvek (Secondary Sad scenario) is leírásra kerülnek 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 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 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ályainak 1 (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.

48 3. FEJEZET. RENDSZERTERV 42 reset él (élekhez kapcsolódó adat) kapacitás korlát (pozíciókhoz kapcsolódó adat) tiltó él (élekhez kapcsolódó adat) priorizált Petri hálók (tranzíciókhoz kapcsolódó adat) időzített Petri hálók (tranzíciókhoz kapcsolódó adat) Szemantikai szempontból akkor tekintünk helyesnek egy hálózatot, ha szimulálása során az őt felépítő elemek a rendeltetési céljuknak megfelelően tudnak viselkedni. Ennek érdekében a szimulációs alkalmazás elsődleges feladata ezen viselkedés ellenőrzése (szimuláció), és olyan inkonzisztens szerkesztési állapotok mellőzése, melyek a Petri hálók nem-determinisztikus viselkedési kontextusában is lehetetlen/elérhetetlen állapotot tükröznek. Az elsődleges használati eset az eddigiek fényében ezen alapfeladatokat hivatott 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.

49 3. FEJEZET. RENDSZERTERV ábra. Main use case Elsődleges használati eset űrlapja Use Case Elsődleges használati eset Leírás A használati eset leírja mindazon funkciókat, melyek az alkalmazás elsődleges céljaihoz szükségesek. Actorok Felhasználó, Azonosított felhasználó, Alkalmazás Prioritás Kötelező (A prioritást az angol Must have, Should 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ő

50 3. FEJEZET. RENDSZERTERV 44 Esemény folyam Alternatív ágak Utófeltételek Üzleti szabályok NFR-ek Megjegyzés 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 E=teszt.elek@nik.uniobuda.hu, CN=Teszt Elek, OU=NIK, O=UNI-OBUDA, L=Budapest, S=Hungary, C=HU. 4. A felhasználó ellenőrzi hogy rendelkezik-e Teszt Elek tanúsítványával. Ezt az 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.

51 3. FEJEZET. RENDSZERTERV 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 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)

52 3. FEJEZET. RENDSZERTERV 46 Tokenjátékos rajzoló eszköz (egyesével lehet játékosokat elhelyezni pozíciókon) Annotáció rajzoló eszköz (megjegyzések doboza) 3.2. ábra. Petri paletta module use case Állapot mátrix modul Az állapot mátrix modul (3.3. ábra) nem csupán a fejezetben bemutatott M állapot mátrix felírására és exportálására (képi, szöveges és L A TEX 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önteni 2. 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.

53 3. FEJEZET. RENDSZERTERV 47 számossága nagyobb mint 1, vagyis F > 1 (ahol F N), akkor az azonos prioritással rendelkező tranzíciók közül a választás nem-determinisztikus marad (ál-véletlen szám dobása fog dönteni). A tüzelési szabályt, illetve az automatikus szimuláció során lényeges timeout értékét 3 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 á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 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.

54 3. FEJEZET. RENDSZERTERV 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 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 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 L A TEX formátumban exportálni (3.6. ábra).

55 3. FEJEZET. RENDSZERTERV ábra. State Hierarchy module use case 3.5. ábra. Minimap module use case 3.6. ábra. Neighborhood Matrix module use case

56 3. FEJEZET. RENDSZERTERV 50 Statisztika modul Az alkalmazás a [BR11]-es ( 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 á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)

57 3. FEJEZET. RENDSZERTERV 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.

58 3. FEJEZET. RENDSZERTERV á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 á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) 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.

59 3. FEJEZET. RENDSZERTERV 53 Két olyan pontja van az alkalmazásnak, ahol a részletesebb modellezés elvárható. Az egyik az alkalmazás elsődleges használati esete, míg a másik az állapot mátrix használati esetben leírt szimuláció (ez az adott használati esetnek csak egy része) 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) 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).

60 3. FEJEZET. RENDSZERTERV á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

61 3. FEJEZET. RENDSZERTERV 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 á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 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.

62 3. FEJEZET. RENDSZERTERV 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 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 (E=petrisubca@qwaevisz.hu, 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>) Lokalizáció A lokalizáció nem teljeskörű az alkalmazásban 5, 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.

63 3. FEJEZET. RENDSZERTERV ábra. Kriptográfiai osztályok ábra. Lokalizációhoz kapcsolódó osztályok 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élyezett 6, 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 ábra mutatja be. Legtöbb célspecifikusan, a nevéből következő rendeltetésre használható csupán (StateHierarchySetting, StateMatrix- Setting, CreateNewPetriNetwork, stb.) vannak azonban olyan űrlapok is, melyek általános 6 Léteznek olyan dialógus ablakok, mely csak tájékoztatnak, nem kérnek be adatot, így nincs mit a felhasználónak elutasítani a mégse gombbal.

64 3. FEJEZET. RENDSZERTERV 58 célra használhatóak bárhol az alkalmazáson belül (TextExportForm, ChangeTextValue- Form) ábra. Dialógus ablakok osztály diagramja 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 Ű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<GeneralToolWindow>). 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,

65 3. FEJEZET. RENDSZERTERV ábra. Felsorolás típusok osztályai az MDI parent mérete és az alkalmazás globális tulajdonságai tartoznak 7 ), 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. Az MDI szülő ablak feladatai közé tartozik a fentieken kívül még egy konzol ablak ke- 7 Az alkalmazás globális tulajdonságai a következők: a rácsháló mérete (GridSize) és megjelenítése (ShowGrid), a grafikai elemek rácshálóhoz igazítása (AlignToGrid) illetve az egyedi kurzorok be/kikapcsolása (ShowCustomCursor).

66 3. FEJEZET. RENDSZERTERV 60 zelé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

67 3. FEJEZET. RENDSZERTERV 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 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 NetworkItemHandler ( L i s t <AbstractItem> items, b o o l f o r c e R e f r e s h ) ; 3 public delegate void 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. Tools { 6 p u b l i c d e l e g a t e void S t a t e V e c t o r H a n d l e r ( S t a t e V e c t o r s t a t e V e c t o r ) ; 7 public delegate void StateMatrixSettingsHandler ( FireRule firerule, i n t m i l l i s e c o n d s T i m e o u t F o r S i m u l a t i o n ) ; 8 public delegate void StateActionHandler ( StateMatrixAction action, PetriNetwork network ) ; 9 p u b l i c d e l e g a t e v o i d NetworkActionHandler ( NetworkToolboxAction s e l e c t e d A c t i o n ) ; 10 public delegate void NetworkItemHandler ( NetworkToolboxItem selecteditem ) ; 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 public delegate void DimensionHandler ( i n t width, i n t height ) ; 14 } 15 namespace PetriNetworkSimulator. E n t i t i e s. Common. Network 16 { 17 public delegate void PetriNetworkEventHandler ( s t r i n g message ) ; 18 p u b l i c d e l e g a t e void P e t r i N e t w o r k N o t i f i e r ( N e t w o r k N o t i f i e r A c t i o n a c t i o n ) ; 19 } 20 namespace PetriNetworkSimulator. U t i l s 21 { 22 public delegate void CryptoHandler ( s t r i n g message ) ; 23 p u b l i c d e l e g a t e void CultureHandler ( ) ; 24 } 25 namespace PetriNetworkSimulator. Controls 26 { 27 public delegate void PropertyGroupMoveHandler ( AbstractNetwork network, NetworkProperty networkproperty, f l o a t v a l u e ) ; 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ó 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,

68 3. FEJEZET. RENDSZERTERV 62 vagyis bizonyos művelet csoportok egymással való keveredését küszöböli ki, és kevésbé az objektum-orientáltág miatt került szétválasztásra a modell. Az absztrakt osztály felel a hálózat vizuális (NetworkVisualSettings) és láthatósági (NetworkVisibleSettings) beállításaiért, valamint tárolja a tranzíciók, pozíciók és annotációk (List<AbstractNetworkItem>), valamint az élek halmazát (List<AbstractEdge>). Felel a kijelölt elemekért (List<AbstractItem>), é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. Identity- Provider osztály példányát. Utóbbi felelős a hálózat szinten értelmezett egyedi UNID értékek kiosztásáért. Egyedi UNID-val rendelkezik minden token, pozíció, tranzíció, 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 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

69 3. FEJEZET. RENDSZERTERV 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 <AbstractToken>) 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 Á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<Int64, List<AbstractToken> >, ahol a kulcs a pozíció unid-ja).

70 3. FEJEZET. RENDSZERTERV á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 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 á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.

71 3. FEJEZET. RENDSZERTERV ábra. Petri eseményekhez kötődő osztályok 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 ábra. Eszköz ablakok osztályai

72 3. FEJEZET. RENDSZERTERV 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 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <P e t r i N e t w o r k F i l e s x m l n s : x s i=" h t t p : //www. w3. org /2001/XMLSchema i n s t a n c e " 3 xmlns:xsd=" h t t p : //www. w3. org /2001/XMLSchema" 4 xmlns=" h t t p : // f i l e s. p e t r i n e t w o r k. hu "> 5 <R e c e n t F i l e 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 "> 6 <NetworkName>Timed c l o c k</networkname> 7 <FileName>. \ networks \ Timed_clock. pn. xml</ FileName> 8 <D e s c r i p t i o n> 9 E=bedok. david@nik. uni obuda. hu, CN=David Bedok, 10 OU=NIK, O=UNI OBUDA, L=Budapest, S=Hungary, C=HU ( : 2 4 : 4 8 ) Nyolcas s z a m l a l o 12 </ D e s c r i p t i o n> 13 </ R e c e n t F i l e> 14 <R e c e n t F i l e 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 "> 15 <NetworkName>Dining p h i l o s o p h e r s</networkname> 16 <FileName>. \ networks \\ Dining_ philosophers. pn. xml</ FileName> 17 <D e s c r i p t i o n> 18 E=bedok. david@nik. uni obuda. hu, CN=David Bedok, 19 OU=NIK, O=UNI OBUDA, L=Budapest, S=Hungary, C=HU ( : 2 4 : 5 6 ) 21 </ D e s c r i p t i o n> 22 </ R e c e n t F i l e> 23 </ P e t r i N e t w o r k F i l e s> 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 Tools \ xsd. exe " r e c e n t f i l e s. xml / o u t p u t d i r : o u t p u t 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 kód). 1 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <xs:schema i d=" P e t r i N e t w o r k F i l e s " targetnamespace=" h t t p : // f i l e s. p e t r i n e t w o r k. hu " 3 xmlns:mstns=" 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 " 4 xmlns:xs=" h t t p : //www. w3. org /2001/XMLSchema" xmlns:msdata=" urn:schemas m i c r o s o f t com:xml msdata " 5 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 " elementformdefault=" q u a l i f i e d " 6 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 "> 7 <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 " schemalocation=" r e c e n t f i l e s _ r f. xsd " /> 8 <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 " msdata:isdataset=" t r u e " msdata:locale=" en US" m s d a t a : P r e f i x=" fpn "> 9 <xs:complextype> 10 <x s : c h o i c e minoccurs=" 0 " maxoccurs=" unbounded "> 11 <x s : e l e m e n t r e f=" r f : R e c e n t F i l e " /> 12 </ x s : c h o i c e> 13 </ xs:complextype> 14 </ x s : e l e m e n t> 15 </ xs: schema> 3.4. kód. A recentfiles.xml állomány schema-ja

73 3. FEJEZET. RENDSZERTERV 67 1 <?xml v e r s i o n=" 1. 0 " s t a n d a l o n e=" yes "?> 2 <xs:schema targetnamespace=" 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 " 3 xmlns:mstns=" h t t p : // f i l e s. p e t r i n e t w o r k. hu " 4 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 " 5 xmlns:xs=" h t t p : //www. w3. org /2001/XMLSchema" 6 xmlns:msdata=" urn:schemas m i c r o s o f t com:xml msdata " 7 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 " 8 elementformdefault=" q u a l i f i e d " > 9 <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 "> 10 <xs:complextype> 11 <x s : s e q u e n c e> 12 <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 " type=" x s : s t r i n g " minoccurs=" 0 " /> 13 <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 " type=" x s : s t r i n g " minoccurs=" 0 " /> 14 <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 " type=" x s : s t r i n g " minoccurs=" 0 " /> 15 </ x s : s e q u e n c e> 16 </ xs:complextype> 17 </ x s : e l e m e n t> 18 </ xs: schema> 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 Tools \ xsd. exe " / outputdir : source / c l a s s e s / language : CS /namespace : PetriNetworkSimulator. 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. Recent- FilesHelper osztály. Példánya karbantartja az utoljára megnyitott állományok listáját, és lekezeli az időközben áthelyezett állományok problémáját. Ha voltak ilyenek, az 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 ábra. Utoljára megnyitott állományok osztály diagramjai

74 3. FEJEZET. RENDSZERTERV 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 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 á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.

75 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 <?xml v e r s i o n=" 1. 0 " encoding=" utf 8"?> 2 <pn:petrinetwork xmlns:pn=" h t t p : // p e t r i n e t w o r k. hu "> 3 <pn: NetworkSettings> 4 [.. ] 5 </ pn: NetworkSettings> 6 <pn: Events> 7 [.. ] 8 </ pn: Events> 9 <p n : V i s u a l S e t t i n g s> 10 [.. ] 11 </ p n : V i s u a l S e t t i n g s> 12 <p n : V i s i b l e S e t t i n g s> 13 [.. ] 14 </ p n : V i s i b l e S e t t i n g s> 15 <pn:network> 16 <neit:networkitems x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 17 [.. ] 18 </ n eit: N e tworkitems> 19 <n e i t : E d g e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 20 [.. ] 21 </ n e i t : E d g e s> 22 <n e i t : N o t e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 69

76 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA [.. ] 24 </ n e i t : N o t e s> 25 </ pn:network> 26 <p n : S t a t e H i e r a r c h y> 27 <s h : S t a t e s xmlns:sh=" 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 "> 28 [.. ] 29 </ s h : S t a t e s> 30 <sh:edges xmlns:sh=" 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 "> 31 [.. ] 32 </ sh: Edges> 33 </ p n : S t a t e H i e r a r c h y> 34 <S i g n a t u r e xmlns=" h t t p : //www. w3. org /2000/09/ xmldsig#"> 35 [.. ] 36 </ S i g n a t u r e> 37 </ pn: PetriNetwork> 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 névtér alá tartozik 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 névtér alá tartozik. 1 <pn: NetworkSettings> 2 <ns:name n s : v a l u e=" Sample " xmlns:ns=" 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 " /> 3 <n s : D e s c r i p t i o n n s : v a l u e=" " xmlns:ns=" 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 <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" xmlns:ns=" 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 " /> 5 <n s : L a s t M o d i f i c a t i o n D a t e n s : v a l u e=" : 1 7 : 5 3 : 5 1 " xmlns:ns=" 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 " /> 6 <ns:width n s : v a l u e=" 400 " xmlns:ns=" 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 " /> 7 <n s : H e i g h t n s : v a l u e=" 250 " xmlns:ns=" 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 " /> 8 <ns:statehierarchywidth n s : v a l u e=" 500 " xmlns:ns=" 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 " /> 9 <n s : S t a t e H i e r a r c h y H e i g h t n s : v a l u e=" 200 " xmlns:ns=" 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 " /> 10 <ns:tokengennumber n s : v a l u e=" 20 " xmlns:ns=" 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 " /> 11 [.. ] 12 <n s : T o k e n P r e f i x n s : v a l u e=" " xmlns:ns=" 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 " /> 13 [.. ] 14 <ns:defaultedgeweight n s : v a l u e=" 1 " xmlns:ns=" 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 " /> 15 <n s : F i r e R u l e n s : v a l u e="random" xmlns:ns=" 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 " /> 16 <ns:simulationtimeout n s : v a l u e=" 100 " xmlns:ns=" 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 " /> 17 </ pn: NetworkSettings> 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

77 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 LastModification- Date). Ezen kívül értelemszerűen az XXXGenNumber értékek is írásvédettek 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 ( de a tagek nevei eltérnek. Globális

78 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 72 esemény esetén az XML elem neve pe:event, azonban majd későbbiekben látni fogjuk, hogy pl. topológia elemhez az XSD egyértelműsége miatt más nevet fog az XML-ben kapni ugyanezen szabályoknak megfelelő elem (pl 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 <pn: Events> 2 <pe:event pe:name=" sampleevent " p e : t y p e="deadlock" xmlns:pe=" h t t p : // event. p e t r i n e t w o r k. hu " /> 3 [.. ] 4 </ pn: Events> 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 fejezetet) 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 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 <p n : V i s u a l S e t t i n g s> 2 <c : D e f a u l t C o l o r c : r e d=" 0 " c : g r e e n=" 0 " c : b l u e=" 0 " c : a l p h a=" 255 " xmlns:c=" h t t p : // c o l o r. p e t r i n e t w o r k. hu " /> 3 [.. ] 4 <f : D e f a u l t F o n t f s : b o l d=" True " f s : i t a l i c =" True " f s : u n d e r l i n e=" F a l s e " 5 f s : s t r i k e o u t=" F a l s e " x m l n s : f s=" h t t p : // f o n t s t y l e. p e t r i n e t w o r k. hu " 6 x m l n s : f=" h t t p : // f o n t. p e t r i n e t w o r k. hu "> 7 <f:fontname>a r i a l</ f:fontname> 8 <f : F o n t S i z e>10</ f : F o n t S i z e> 9 </ f : D e f a u l t F o n t> 10 <p:defaultpen p:width=" 1 " xmlns:p=" h t t p : // pen. p e t r i n e t w o r k. hu " /> 11 [.. ] 12 </ p n : V i s u a l S e t t i n g s> 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 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 ( 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 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),

79 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 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) 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 <p n : V i s i b l e S e t t i n g s> 2 <ns:edgelabel n s : v a l u e=" True " xmlns:ns=" 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 " /> 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 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ó 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 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 fejezet). 1 <pn:network> 2 <neit:networkitems x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 3 <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 "> 4 [.. ] 5 </ i : P o s i t i o n> 6 <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 "> 7 [.. ] 8 </ i : T r a n s i t i o n> 9 [.. ] 10 </ n eit: N e tworkitems> 11 <n e i t : E d g e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu ">

80 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA <edg:edge... xmlns:edg=" h t t p : // edge. p e t r i n e t w o r k. hu "> 13 [.. ] 14 </ edg:edge> 15 [.. ] 16 </ n e i t : E d g e s> 17 <n e i t : N o t e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 18 <i : N o t e... x m l n s : i=" h t t p : // item. p e t r i n e t w o r k. hu "> 19 [.. ] 20 </ i : N o t e> 21 [.. ] 22 </ n e i t : N o t e s> 23 </ pn:network> 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 az i:radius attribútum és az i:events gyermek elem pedig az AbstractNetworkItem osztályban ( névtér). Ezekkel szemben a pos:capacitylimit attribútum és pos:tokens gyermek elem mögött olyan tulajdonságok vannak ( névtér), melyekkel egyedül csak egy pozíció rendelkezhet. A pf ( névtér) illetve sf ( 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 ( 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 <i : P o s i t i o n bi:name="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 " xmlns:pos=" 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 : // baseitem. 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 "> 2 <p f : T o p L e f t P o i n t p f : x=" 92 " p f : y=" 188 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 3 <p f : O r i g o p f : x=" 112 " p f : y=" 208 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 4 <p f : L a b e l O f f s e t p f : x=" 0 " p f : y=" 0 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 5 < 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 " /> 6 <pos: Tokens> 7 <tok:token bi:name=" 1 " b i : u n i d=" 26 " b i : s h o w a n n o t a t i o n=" True " xmlns:tok=" h t t p : // token. p e t r i n e t w o r k. hu "> 8 <c:tokencolor c : r e d=" 0 " c : g r e e n=" 0 " c : b l u e=" 0 " c : a l p h a=" 255 " xmlns:c=" h t t p : // c o l o r. p e t r i n e t w o r k. hu " /> 9 </ tok:token> 10 [.. ] 11 </ pos: Tokens> 12 <i : E v e n t s> 13 <pe:itemevent pe:name=" t e s t " p e : t y p e="preactivate" xmlns:pe=" h t t p : // event. p e t r i n e t w o r k. hu " /> 14 [.. ] 15 </ i : E v e n t s> 16 </ i : P o s i t i o n> 4.7. kód. Pozíciók XML modellje

81 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 75 A pozíciók tárolási modelljének részletes leírása után az i:transition tag (4.8. kód) kapcsán csupán a különbségeket érdemes kiemelni. Csak tranzíciókra jellemző tulajdonság a forgásszög (tra:angle) fokban megadva, a prioritás (tra:priority), a típus (tra:type), a késleltetés (tra:delay) és az utóbbi kapcsán opcionálisan megjeleníthető óra ikon mérete (tra:clockradius). Mindezen elemek a 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 <i : T r a n s i t i o n bi:name="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=" 10,30776 " 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 : // baseitem. 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 "> 2 <p f : T o p L e f t P o i n t p f : x=" 169,5 " p f : y=" 27 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 3 <p f : O r i g o p f : x=" 172 " p f : y=" 37 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 4 <p f : L a b e l O f f s e t p f : x=" 0 " p f : y=" 0 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 5 < 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 " /> 6 <p f : C l o c k O f f s e t p f : x=" 10 " p f : y=" 10 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 7 <i : E v e n t s> 8 <pe:itemevent pe:name="dummy" p e : t y p e="postactivate" xmlns:pe=" h t t p : // event. p e t r i n e t w o r k. hu " /> 9 [.. ] 10 </ i : E v e n t s> 11 </ i : T r a n s i t i o n> 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 <n e i t : E d g e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 2 <edg:edge bi:name=" " 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 : // baseitem. p e t r i n e t w o r k. hu " xmlns:edg=" h t t p : // edge. p e t r i n e t w o r k. hu "> 3 <e d g : S t a r t e d g : r e f t y p e="transition">2</ e d g : S t a r t> 4 <edg:end e d g : r e f t y p e="position">1</ edg:end> 5 <p f : C u r v e M i d d l e P o i n t O f f s e t p f : x=" 0 " p f : y=" 0 " 6 x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 7 </ edg:edge> 8 [.. ] 9 </ n e i t : E d g e s> 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.

82 4. FEJEZET. PETRI HÁLÓZATOK TÁROLÁSA 76 1 <n e i t : N o t e s x m l n s : n e i t=" h t t p : // networkitem. p e t r i n e t w o r k. hu "> 2 <i : N o t e bi:name="n1" b i : u n i d=" 61 " b i : s h o w a n n o t a t i o n=" True " i : r a d i u s=" 53,85165 " n o t : a t t a c h e d I t e m=" 10 " xmlns:not=" h t t p : // note. p e t r i n e t w o r k. hu " x m l n s : b i=" h t t p : // baseitem. 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 "> 3 <p f : T o p L e f t P o i n t p f : x=" 468 " p f : y=" 5 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 4 <p f : O r i g o p f : x=" 518 " p f : y=" 25 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 5 <p f : L a b e l O f f s e t p f : x=" 0 " p f : y=" 0 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 6 < 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 " /> 7 <not: Text>new note</ not: Text> 8 </ i : N o t e> 9 [.. ] 10 </ n e i t : N o t e s> 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 <p n : S t a t e H i e r a r c h y> 2 <s h : S t a t e s xmlns:sh=" 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 "> 3 <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 " xmlns:sv=" 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 "> 4 <p f : S t a t e O r i g o p f : x=" 26 " p f : y=" 27 " x m l n s : p f=" h t t p : // p o i n t f. p e t r i n e t w o r k. hu " /> 5 <s v : T o k e n D i s t r i b u t i o n s> 6 <s v : P o s i t i o n s v : u n i d=" 0 "> 7 <sv:token s v : u n i d=" 26 " /> 8 [.. ] 9 </ s v : P o s i t i o n> 10 [.. ] 11 </ s v : T o k e n D i s t r i b u t i o n s> 12 <s v : E v e n t s> 13 <p e : S t a t e E v e n t pe:name=" s t a t e e v e n t " p e : t y p e="preactivate" xmlns:pe=" h t t p : // event. p e t r i n e t w o r k. hu " /> 14 [.. ] 15 </ s v : E v e n t s> 16 </ s v : S t a t e V e c t o r> 17 </ s h : S t a t e s> 18 <sh:edges xmlns:sh=" 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 "> 19 <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 "> 20 <s e : S t a r t S t a t e>31</ s e : S t a r t S t a t e> 21 <se: End State>28</ se: EndSt ate> 22 </ s e : S t a t e E d g e> 23 [.. ] 24 </ sh: Edges> 25 </ p n : S t a t e H i e r a r c h y> kód. Állapot-hierarchia XML modellje

83 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 fejezet), azon belül is az RSA algoritmus (lásd fejezet) felhasználása a szabványos viselkedést, a kulcsgeneráláshoz felhasznált alkalmazások (Java Keytool és OpenSSL, lásd 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 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 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

84 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 s e t ROOTCA_FILE_PREFIX=p e t r i r o o t c a 2 s e t KEYS_DIR=.\ keys \ 3 s e t ROOTCA_KEY_FILENAME=%ROOTCA_FILE_PREFIX%. key 4 s e t ROOTCA_KEY_FILE=%KEYS_DIR%%ROOTCA_KEY_FILENAME% 5 %OPENSSL_HOME%\bin \ o p e n s s l genrsa des3 out %ROOTCA_KEY_FILE% kód. Root CA privát kulcs létrehozása A Root CA létrehozása OpenSSL alkalmazással valósul meg (lásd 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 s e t ROOTCA_KEY_PASSWORD=c h a n g e i t r o o t 2 s e t OSSL_CONFIG=o p e n s s l. conf 3 s e t ROOT_CERTS_DIR=. \.. \ r o otca \ c e r t s \ 4 s e t ROOTCA_CERT_PEM_FILENAME=%ROOTCA_FILE_PREFIX%.pem. c e r 5 s e t ROOTCA_CERT_PEM_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_PEM_FILENAME% 6 %OPENSSL_HOME%\bin \ o p e n s s l req c o n f i g %OSSL_CONFIG% new x509 sha384 days 1826 key %ROOTCA_KEY_FILE% p a s s i n pass :% ROOTCA_KEY_PASSWORD% e x t e n s i o n s x509v3_extensions out % ROOTCA_CERT_PEM_FILE% 5.2. kód. Root CA tanúsítványának létrehozása A privát kulcs birtokában készíthetünk tanúsítványt a kulcshoz, mely a tanúsítvány publikus rekordjainak megadását és aláírását, valamint a kulcspár publikus felének csomagolását jelenti. Mindehhez az OpenSSL req utasítását használhatjuk (lásd 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 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).

85 5. FEJEZET. INTEGRITÁS VÉDELEM 79 1 [ x509v3_extensions ] 2 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: true, pathlen : 3 3 keyusage=keycertsign, crlsign 4 s u b j e c t K e y I d e n t i f i e r=hash 5 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, address = petrirootca@qwaevisz.hu CN, CountryName = Petri Universitas Budensis Root CA OU, OrganizationalUnitName = NIK O, OrganizationName = UNI-OBUDA L, LocalityName = Budapest S, StateOrProvinceName = Hungary C, CountryName = HU 1 s e t ROOTCA_CERT_DER_FILENAME=%ROOTCA_FILE_PREFIX%. d e r 2 s e t ROOTCA_CERT_DER_FILE=%ROOT_CERTS_DIR%%ROOTCA_CERT_DER_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l x509 in %ROOTCA_CERT_PEM_FILE% inform PEM out %ROOTCA_CERT_DER_FILE% outform DER 5.4. kód. Root CA tanúsítványának konvertálása A létrejött tanúsítvány PEM formátumban lesz. A szélesebb körű felhasználás érdekében az OpenSSL x509 utasításával DER formátumra konvertálhatjuk (lásd 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 kód). A TrustStore szabadon terjeszthető nyilvános csatornákon. Birtokában a hitelességet vizsgáló fél az authorization lépéseit végre tudja hajtani, amennyiben természetesen a TrustStore-ban szereplő tanúsítványban feltétel nélkül megbízik. 1 s e t ROOTCA_CERTSTORE_PASSWORD=c h a n g e i t 2 s e t ROOTCA_ALIAS=r o o t c a 3 s e t STORE_DIR=.\ s t o r e \ 4 s e t ROOTCA_CERTSTORE_FILENAME=%ROOTCA_FILE_PREFIX%. j k s 5 s e t ROOTCA_CERTSTORE=%STORE_DIR%%ROOTCA_CERTSTORE_FILENAME% 6 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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.

86 5. FEJEZET. INTEGRITÁS VÉDELEM 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 s e t SUBCA_FILE_PREFIX=p e t r i s u b c a 2 s e t SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%. key 3 s e t SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% 4 %OPENSSL_HOME%\bin \ o p e n s s l genrsa des3 out %SUBCA_KEY_FILE% 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 kód). A privát kulcs generálását követően a Sub CA-nak is szüksége van egy ideiglenes self-signed tanúsítványra. A tanúsítvány tartalmazza a javasolt publikus adatokat, érvényességi időt és x509v3 kiterjesztéseket. Mikoron a Root CA a tanúsítványt aláírja, ezen adatok egy részét megváltoztathatja (pl. az érvényességi időt, illetve kiterjesztéseket). 1 s e t ROOT_CSR_DIR=. \.. \ r o o t ca \ c s r \ 2 s e t SUBCA_CSR_FILENAME=%SUBCA_FILE_PREFIX%. c s r 3 s e t SUBCA_CSR_FILE=%ROOT_CSR_DIR%%SUBCA_CSR_FILENAME% 4 s e t SUBCA_KEY_PASSWORD=changeitsub 5 s e t SUBCA_KEY_FILENAME=%SUBCA_FILE_PREFIX%. key 6 s e t SUBCA_KEY_FILE=%KEYS_DIR%%SUBCA_KEY_FILENAME% 7 %OPENSSL_HOME%\bin \ o p e n s s l req c o n f i g %OSSL_CONFIG% new days 1096 sha384 key %SUBCA_KEY_FILE% p a s s i n pass :%SUBCA_KEY_PASSWORD% e x t e n s i o n s x509v3_extensions out %SUBCA_CSR_FILE% 5.7. kód. Certificate Signing Request állomány létrehozása A Sub CA tanúsítványa hason módon a Root CA-hoz, az OpenSSL req utasításával fog elkészülni (lásd 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, address = petrisubca@qwaevisz.hu CN, CountryName = Petri Universitas Budensis Sub CA OU, OrganizationalUnitName = NIK O, OrganizationName = UNI-OBUDA L, LocalityName = Budapest S, StateOrProvinceName = Hungary C, CountryName = HU

87 5. FEJEZET. INTEGRITÁS VÉDELEM 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 kód). 1 s e t SUBCA_CERT_PEM_FILENAME=%SUBCA_FILE_PREFIX%.pem. c e r 2 s e t SUBCA_CERT_PEM_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_PEM_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l ca c o n f i g %OSSL_CONFIG% k e y f i l e % ROOTCA_KEY_FILE% p a s s i n pass :%ROOTCA_KEY_PASSWORD% c e r t % ROOTCA_CERT_PEM_FILE% in %SUBCA_CSR_FILE% e x t e n s i o n s x509v3_extensions md sha384 out %SUBCA_CERT_PEM_FILE% 5.8. kód. Sub CA tanúsítványának aláírása A RootCA openssl.conf állományában meghatározott tulajdonságok szerint az aláírt tanúsítvány érvényességi ideje egy év lesz (default_days=365), a kulcs pedig elsősorban tanúsítványok aláírására lesz használható (Key usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06)). A tanúsítvány PEM formátumban készül el. 1 s e t SUBCA_CERT_DER_FILENAME=%SUBCA_FILE_PREFIX%. d e r 2 s e t SUBCA_CERT_DER_FILE=%SUB_CERTS_DIR%%SUBCA_CERT_DER_FILENAME% 3 %OPENSSL_HOME%\bin \ o p e n s s l x509 in %SUBCA_CERT_PEM_FILE% inform PEM out %SUBCA_CERT_DER_FILE% outform DER 4 5 s e t SUBCA_ALIAS=subca 6 s e t SUBCA_CERTSTORE_PASSWORD=c h a n g e i t 7 s e t SUBCA_CERTSTORE_FILENAME=%SUBCA_FILE_PREFIX%. j k s 8 s e t SUBCA_CERTSTORE=%STORE_DIR%%SUBCA_CERTSTORE_FILENAME% 9 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 s e t SUBCA_CERTPATHSTORE_FILENAME=%SUBCA_FILE_PREFIX%. path. j k s 12 s e t SUBCA_CERTPATHSTORE=%STORE_DIR%%SUBCA_CERTPATHSTORE_FILENAME% 13 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 14 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 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

88 5. FEJEZET. INTEGRITÁS VÉDELEM 82 CA továbbra sem használható a PN.XML állományok hitelesítésére, azonban alkalmas lesz arra, hogy aláírjon e célra létrehozott tanúsítványokat 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 kód. 1 s e t KEYALG=RSA 2 s e t KEYSIZE= s e t SIGALG=SHA1withRSA 4 s e t END_ALIAS=p e t r i 5 s e t END_FILE_PREFIX=uniobuda 6 s e t END_KEYSTORE_FILENAME=%END_FILE_PREFIX%_private. j k s 7 s e t END_KEYSTORE=%OUTPUTDIR%%END_KEYSTORE_FILENAME% 8 s e t CERT_CN=U n i v e r s i t a s Budensis 9 s e t CERT_OU=NIK 10 s e t CERT_O=UNI OBUDA 11 s e t CERT_L=Budapest 12 s e t CERT_S=Hungary 13 s e t CERT_C=HU 14 s e t END_KEYSTORE_PASSWORD=c h a n g e i t s t o r e 15 s e t END_PRIVATEKEY_PASSWORD=p e t r i p a s s %KEYTOOL_HOME%\bin \ k e y t o o l genkeypair keyalg %KEYALG% k e y s i z e % KEYSIZE% s i g a l g %SIGALG% a l i a s %END_ALIAS% k e y s t o r e % END_KEYSTORE% dname "CN=%CERT_CN%, OU=%CERT_OU%, O=%CERT_O%, L=% CERT_L%, S=%CERT_S%, C=%CERT_C%, Address=%CERT_E%" s t o r e p a s s %END_KEYSTORE_PASSWORD% k e y p a s s %END_PRIVATEKEY_PASSWORD% 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 kód. 1 s e t END_FILE_PREFIX=uniobuda 2 s e t END_CSR_FILENAME=%END_FILE_PREFIX%. c s r 3 s e t END_CSR_FILE=%SUB_CRL_DIR%%END_CSR_FILENAME% 4 5 %KEYTOOL_HOME%\bin \ k 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% 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

89 5. FEJEZET. INTEGRITÁS VÉDELEM 83 a Sub CA tanúsítványának Root CA általi aláírasakor már bemutaott Open SSL ca utasítását használhatjuk (lásd kód). 1 [ x509v3_extensions_nonca ] 2 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 3 keyusage=d i g i t a l S i g n a t u r e, nonrepudiation, keyencipherment 4 extendedkeyusage=serverauth, clientauth, codesigning, protection, timestamping 5 s u b j e c t K e y I d e n t i f i e r=hash 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 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 s e t END_LONG_CERT_PEM_FILENAME=%END_FILE_PREFIX%. long. pem. c e r 2 s e t END_LONG_CERT_PEM_FILE=%END_OUTPUT_DIR%% END_LONG_CERT_PEM_FILENAME% 3 4 %OPENSSL_HOME%\bin \ o p e n s s l ca p o l i c y %SUBCA_POLICY% c o n f i g % OSSL_CONFIG% c e r t %SUBCA_CERT_PEM_FILE% 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 pass :% SUBCA_KEY_PASSWORD% out %END_LONG_CERT_PEM_FILE% 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 kód). 1 s e t END_TMP_CERT_PEM_FILENAME=%END_FILE_PREFIX%.tmp. pem. c e r 2 s e t END_TMP_CERT_PEM_FILE=%OUTPUTDIR%%END_TMP_CERT_PEM_FILENAME% 3 4 %OPENSSL_HOME%\bin \ o p e n s s l x509 in %END_LONG_CERT_PEM_FILE% out % END_TMP_CERT_PEM_FILE% 5 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 6 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 7 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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% kód. Végfelhasználói tanúsítvány konvertálása és csomagolása

90 5. FEJEZET. INTEGRITÁS VÉDELEM 84 Miután a keystore elkészült, a Java keytool és az Open SSL segítségével néhány további műveletet még elvégezhetünk: DER formátumú tanúsítvány exportálása, PEM formátumú konverziója, PKCS12 keystore előállítása, illetve truststore létrehozása (lásd kód). 1 s e t END_CERT_DER_FILENAME=%END_FILE_PREFIX%. d e r 2 s e t END_CERT_DER_FILE=%OUTPUTDIR%%END_CERT_DER_FILENAME% 3 s e t END_CERT_PEM_FILENAME=%END_FILE_PREFIX%.pem. c e r 4 s e t END_CERT_PEM_FILE=%OUTPUTDIR%%END_CERT_PEM_FILENAME% 5 s e t END_PKCS12_PASSWORD=c h a n g e i t s t o r e 6 s e t END_CERTSTORE_PASSWORD=c h a n g eit 7 8 %KEYTOOL_HOME%\bin \ 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% 9 %OPENSSL_HOME%\bin \ o p e n s s l x509 in %END_CERT_DER_FILE% inform DER out %END_CERT_PEM_FILE% outform PEM 10 %KEYTOOL_HOME%\bin \ k e y t o o l importkeystore s r c k e y s t o r e %END_KEYSTORE % d e s t k e y s t o r e %END_PKCS12% 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 11 %KEYTOOL_HOME%\bin \ k e y t o o l i mportcert 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 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 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

91 5. FEJEZET. INTEGRITÁS VÉDELEM 85 A tanúsítvány kibocsátója a korábban létrehozott Sub CA (E=petrisubca@qwaevisz.hu, 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 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.

92 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 Irodalomkutatás tanulsága fejezet a 33. oldalon, Események modul fejezet az 50. oldalon, 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ára 1. 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 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

93 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 jelent Topológia és egyéb építőkövek osztályai Az áttervezett osztályhierarchiából (lásd ábra) kikerültek azon abstract osztályok 3, 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 á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.

94 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN á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 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 á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<AbstractItem>-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).

95 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN á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-

96 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 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, RESET- FIRE illetve DEADLOCK. Utóbbi esetben egyértelműen nincs értelme a fire() metódust ismét meghívni, a RESETFIRE visszatérési érték pedig egy ciklusra utal, vagyis egy olyan állapotvektor állt elő az utolsó tüzelés hatására, mely már korábban előfordult (ez nem jelenti azt, hogy innentől bizonyosan ciklikusság fog következni, hiszen a hálózat működése nem-determinisztikus). A visszatérési értékből a hálózat állapotára nézve semmilyen lényeges információval nem rendelkezünk, a FireReturn példányából a FireEventen kívül a tüzelő tranzíció referenciáját kapjuk még meg. Ez az API szándékos viselkedése 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

97 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 91 az API-t felhasználó programozó a kapcsolatot regisztrálni/megszüntetni (részletesebben lásd kód). 1 p u b l i c d e l e g a t e void P e t r i H a n d l e r ( AbstractEventDrivenItem item, EventType eventtype ) ; 2 3 p u b l i c c l a s s PetriNetwork : System. Object 4 { 5 [.. ] 6 p r i v a t e Dictionary <String, PetriHandler > h a n d l e r s ; 7 [.. ] 8 p u b l i c L i s t <String > EventsName 9 { 10 [.. ] 11 } 12 [.. ] 13 p u b l i c void bindpetrievent ( s t r i n g eventname, P e t r i H a n d l e r handler ) { [.. ] } 14 p u b l i c void unbindpetrievent ( s t r i n g eventname, P e t r i H a n d l e r handler ) { [.. ] } 15 [.. ] 16 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 ) { [.. ] } 17 p r i v a t e P e t r i H a n d l e r getpetrieventbytrunk ( L i s t <PetriEvent> e v e n t s ) { [.. ] } 18 [.. ] 19 p r i v a t e void checkhandler ( AbstractEventDrivenItem item, EventType eventtype ) 20 { 21 L i s t <PetriEvent> e v e n t s = item. EventTrunk. geteventsbytype ( eventtype ) ; 22 P e t r i H a n d l e r handler = getpetrieventbytrunk ( e v e n t s ) ; 23 i f ( handler!= n u l l ) 24 { 25 handler ( item, eventtype ) ; 26 } 27 } 28 [.. ] 29 } 6.1. kód. Eseményvezérlés háttere A képviselő által meghatározott esemény aláírása lehetőséget ad a felhasználónak arra, hogy az eseményt kiváltó AbstractEventDrivenItem példányát elemezze az eseménykezelőben (a pontosabb azonosítás végett az aláírás tartalmazza az esemény típusát is) 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 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 Random rand = new Random ( ) ; 4 PetriNetwork network = PetriNetwork. openfromxml ( networks \Demo. pn. xml " ) ; 6.2. kód. Hálózat megnyitása A legelső lépés a Petri hálózat megnyitása (lásd 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

98 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 92 XSD-nek nem megfelelő módon) módosították, akkor XML validációs kivételek fognak keletkezni. Az API nem vizsgálja a hálózat integritás védelmét! Ennek oka, hogy a már elkészült hálózat beépítésével a felhasználó alkalmazás érvényességi idejét is korlátoznánk a TrustStore-ban lévő tanúsítvánnyal. Ahhoz, hogy bármilyen eseményvezérelt interakciót létrehozzunk, szükségünk lesz eseménykezelőkre. Az eseménykezelő aláírását a PetriHandler delegate definiálja, erre láthatunk egy példát a 6.3. kódban. A paraméterben kapott AbstractEventDrivenItem runtime típusát lekérdezve biztonságos castolást tudunk végrehajtani, majd így az 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 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 p r i v a t e s t a t i c void eventhandler ( AbstractEventDrivenItem item, EventType eventtype ) 4 { 5 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 ( ) ; 6 sb. Append ( " eventhandler ( item : " + item. Name + ", eventtype : "+eventtype+" ) " ) ; 7 i f ( item i s P o s i t i o n ) 8 { 9 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 ; 10 sb. Append ( " token count : " + p o s i t i o n. TokenCount ) ; 11 } 12 System. Console. WriteLine ( sb. ToString ( ) ) ; 13 } 6.3. kód. Eseménykezelő Miután elkészítettük a szükséges eseménykezelőt, és ismerjük a modellben névvel azonosított Petri eseményt, melyhez ezt hozzá kívánjuk kötni, áttérhetünk az 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 kód). Amennyiben adott névvel nem létezik Petri esemény, ArgumentExceptiont fog dobni a metódus 4. 1 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 t r y 4 { 5 network. bindpetrievent ( "dummy", new P e t r i H a n d l e r ( eventhandler ) ) ; 6 } 7 catch ( ArgumentException e ) 8 { 9 System. Console. WriteLine ( e. Message ) ; 10 } 6.4. kód. Névvel adott esemény regisztrálása Az API az események regisztrálását dinamikus formában is el tudja végezni, ezzel lehetőség nyílik arra hogy olyan alkalmazások készüljenek, ahol a PN.XML állomány kü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 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ő.

99 6. FEJEZET. MODELL ALKALMAZÁSA OO KÖRNYEZETBEN 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 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 L i s t <String > l i s t O f E v e n t s = network. EventsName ; 4 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 ) 5 { 6 network. bindpetrievent ( item, new P e t r i H a n d l e r ( eventhandler ) ) ; 7 network. bindpetrievent ( item, new P e t r i H a n d l e r ( eventhandler2 ) ) ; 8 } 6.5. kód. Összes esemény regisztrálása Miután a megnyitás és az események összerendelése megtörtént, készen állunk a tokenjáték lejátszására. Ezt megtehetjük külön szálban, akár futva hagyni a szálat egy végtelen ciklusban, avagy az aktuális szálban a tüzeléseket egymás után meghívva (lásd 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 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 FireEvent f i r e E v e n t = FireEvent. INITFIRE ; 4 FireReturn f i r e R e t u r n = n u l l ; 5 w h i l e (! FireEvent.DEADLOCK. Equals ( f i r e E v e n t ) ) 6 { 7 f i r e R e t u r n = network. f i r e ( ) ; 8 System. Console. WriteLine ( f i r e R e t u r n ) ; 9 f i r e E v e n t = f i r e R e t u r n. FireEvent ; 10 } 6.6. kód. Tokenjáték lejátszása

100 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 Bejelentkezés Az alkalmazás indulást követően egy bejelentkezési képernyővel fogad (lásd á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 ábra. Bejelentkezés a szimulátor alkalmazásba 94

101 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 ábra) á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 á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_<cert_subject_cn>_<number> mintára épül, ahol a <cert_subject_cn> a tanúsítvány úgynevezett DN nevének (Distinguished Name) CN részét (Common Name) tartalmazza white-space mentes formában, a <number> 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 á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.

102 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA á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ődik 1. 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 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 ábra), betöltve illetve megjelenítve a kapcsolódó információkat. Az alkalmazás úgyne- 1 A munkafelület jellemzői a következők: főablak és az eszköztárak mérete és pozíciója, az alkalmazás beállításai, illetve a nyitva hagyott eszköztárak listája.

103 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA á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 á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 + <number> 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ó) 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-

104 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA á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 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 á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

105 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 99 kényelmi funkció került beépítésre a paletta eszközei mögé, mely első ránézésre nem biztos hogy feltűnik a felhasználónak. A Paletta modul tetszőlegesen átméretezhető, az ikonok az átméretezett ablakhoz igazítva több sorban is meg tudnak jelenni á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.

106 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 100 A mozgató/átméretező eszköz kapcsán érdemes pár apróságot észrevenni. Az eszköz egyrészt alkalmas bármely nem él elem drag&drop típusú mozgatására, valamint az 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ítani 2, 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.

107 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA Á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 á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 á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) ábra. Állapot mátrix modul Az Állapot mátrix modul által előállított állapot mátrix képként, szöveges illetve L A TEX 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 Állapot-hierarchia A [Nézet Eszköztárak Állapot-hierarchia (Alt+Shift+H)] menüpontból elérhető Állapot-hierarchia modul (lásd á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

108 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA á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 Szomszédossági mátrix A Szomszédossági mátrix (lásd á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 L A TEX formátumban ábra. Szomszédossági mátrix modul 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 á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,

109 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 103 illetve ezek átlagát is kiszámolja a program. Lehetőségünk van a kiválasztott, avagy az összes elem statisztikáját nullázni a megfelelő vezérlő gombok segítségével ábra. Statisztika modul A Tranzíció történet modulban (lásd á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! ábra. Tranzíció történet modul

110 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 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 á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 á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) 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 á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

111 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA á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 á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 ábrán á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ó

112 7. FEJEZET. EREDMÉNYEK BEMUTATÁSA 106 nem tüzelhet abban az esetben, ha az azt követő három pozíció bármelyikén tokenjátékos található). A legfelső szinten ábrázolt futási pálya során a ló már az első akadályban megakadhat (get stuck), de nincs ez másként a további két ábrázolt pálya esetén sem (a középső pozíciók esetén). A verseny során két előzési lehetőség is modellezésre került. Az úgynevezett outran tranzíciók csak egymáshoz közeli pályák/pozíciók során jöhetnek létre 3. 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) ábra. Egy lehetséges lóverseny futási eredménye Egy lehetséges lóverseny futási eredményét láthatjuk a á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 á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 u s i n g PetriNetworkLibrary. Model. NetworkItem ; 2 [.. ] 3 p r i v a t e PetriNetwork network ; 4 p r i v a t e L i s t <Token> r e s u l t ; 5 [.. ] 6 t h i s. network = PetriNetwork. openfromxml ( t h i s. network \ Horserace. pn. xml " ) ; 7 t h i s. network. bindpetrievent ( " g o a l ", new P e t r i H a n d l e r ( eventhandler ) ) ; 8 [.. ] 9 p r i v a t e void eventhandler ( AbstractEventDrivenItem item, EventType eventtype ) { 10 i f ( item i s P o s i t i o n ) { 11 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 ; 12 L i s t <Token> tokens = p o s i t i o n. Tokens ; 13 i f ( ( tokens!= n u l l ) && ( tokens. Count == 1 ) ) { 14 t h i s. r e s u l t. Add( tokens [ 0 ] ) ; 15 } 16 } 17 } 18 [.. ] 3 A pályák demonstrációja nem törekszik élethű modellt adni. A pályák lehetnek egymás melletti utak, egymás mögötti pozíciók is.

Diplomamunka. Petri hálók szimulációja és alkalmazásuk objektum-orientált környezetben. készítette: Bedők Dávid. 2011-2012 2012.04.28. 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. 2011-2012 2012.04.28. 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

Részletesebben

Alapszintű formalizmusok

Alapszintű formalizmusok Alapszintű formalizmusok dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék 1 Mit szeretnénk elérni? Informális tervek Informális követelmények Formális modell Formalizált követelmények

Részletesebben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és

Részletesebben

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Autóipari beágyazott rendszerek. Komponens és rendszer integráció Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása

Részletesebben

ContractTray program Leírás

ContractTray program Leírás ContractTray program Leírás Budapest 2015 Bevezetés Egy-egy szerződéshez tartozó határidő elmulasztásának komoly gazdasági következménye lehet. Éppen ezért a Szerződés kezelő program főmenü ablakában a

Részletesebben

DebitTray program Leírás

DebitTray program Leírás DebitTray program Leírás Budapest 2015 Bevezetés Egy-egy kintlévőséghez tartozó határidő elmulasztásának komoly következménye lehet. Éppen ezért a Kintlévőség kezelő program főmenü ablakában a program

Részletesebben

Diszkrét állapotú rendszerek modellezése. Petri-hálók

Diszkrét állapotú rendszerek modellezése. Petri-hálók Diszkrét állapotú rendszerek modellezése Petri-hálók Diszkrét eseményű rendszerek Discret Event (Dynamic) Systems DES, DEDS állapotterük diszkrét halmaz állapotváltozásuk kizárólag az időben aszinkron

Részletesebben

III. Alapfogalmak és tervezési módszertan SystemC-ben

III. Alapfogalmak és tervezési módszertan SystemC-ben III. Alapfogalmak és tervezési módszertan SystemC-ben A SystemC egy lehetséges válasz és egyben egyfajta tökéletesített, tovább fejlesztett tervezési módszertan az elektronikai tervezés területén felmerülő

Részletesebben

GráfRajz fejlesztői dokumentáció

GráfRajz fejlesztői dokumentáció GráfRajz Követelmények: A GráfRajz gráfokat jelenít meg grafikus eszközökkel. A gráfot többféleképpen lehet a programba betölteni. A program a gráfokat egyedi fájl szerkezetben tárolja. A fájlokból betölthetőek

Részletesebben

Petri hálók: Alapelemek és kiterjesztések

Petri hálók: Alapelemek és kiterjesztések Petri hálók: Alapelemek és kiterjesztések dr. Bartha Tamás dr. Pataricza András dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Modellek a formális ellenőrzéshez Mivel nyújt többet

Részletesebben

ServiceTray program Leírás

ServiceTray program Leírás ServiceTray program Leírás Budapest 2015 Bevezetés szerviz munkalapok státuszai a Törölve és Lezárva státuszt leszámítva a munkalap különböző nyitott állapotát jelzik, melyek valamilyen tevékenységet jeleznek.

Részletesebben

Petri hálók: alapfogalmak, kiterjesztések

Petri hálók: alapfogalmak, kiterjesztések Petri hálók: alapfogalmak, kiterjesztések dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Petri hálók felépítése, működése A Petri hálók eredete Petri háló: Mi

Részletesebben

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18.

Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Viczián István IP Systems http://jtechlog.blogspot.hu/ JUM XIX. - 2012. szeptember 18. Két projekt Mindkettőben folyamatirányítás Eltérő követelmények Eltérő megoldások Dokumentum gyártási folyamat Üzemeltetés

Részletesebben

Térképek jelentése és elemzése

Térképek jelentése és elemzése Térképek jelentése és elemzése Ontológiák Az ontológiák termekre, csomópontokra (koncepciókra) és összeköttetésekre (kapcsolatokra) vonatkozó listák, amik importálhatóak és hozzáadhatóak a VUE térképekhez,

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Diszkrét állapotú rendszerek modellezése. Petri-hálók

Diszkrét állapotú rendszerek modellezése. Petri-hálók Diszkrét állapotú rendszerek modellezése Petri-hálók Diszkrét eseményű rendszerek Discret Event (Dynamic) Systems DES, DEDS állapotterük diszkrét halmaz állapotváltozásuk kizárólag az időben aszinkron

Részletesebben

Modellek dokumentálása

Modellek dokumentálása előadás CAD Rendszerek II AGC2 Piros Attila Budapesti Műszaki és Gazdaságtudományi Egyetem, Gép- és Terméktervezés Tanszék 1 / 18 DOKUMENTÁCIÓK FELOSZTÁSA I. Felosztás felhasználás szerint: gyártási dokumentáció

Részletesebben

Podoski Péter és Zabb László

Podoski Péter és Zabb László Podoski Péter és Zabb László Bevezető Algoritmus-vizualizáció témakörében végeztünk kutatásokat és fejlesztéseket Felmértük a manapság ismert eszközök előnyeit és hiányosságait Kidolgoztunk egy saját megjelenítő

Részletesebben

Petri hálók: alapfogalmak, kiterjesztések

Petri hálók: alapfogalmak, kiterjesztések Petri hálók: alapfogalmak, kiterjesztések dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék A Petri hálók eredete Petri háló: Mi az? Carl Adam Petri: német matematikus,

Részletesebben

Újrakonfigurálható eszközök

Újrakonfigurálható eszközök Újrakonfigurálható eszközök 5. A Verilog sűrűjében: véges állapotgépek Hobbielektronika csoport 2017/2018 1 Debreceni Megtestesülés Plébánia Felhasznált irodalom és segédanyagok Icarus Verilog Simulator:

Részletesebben

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell

Részletesebben

Az MTA Cloud a tudományos alkalmazások támogatására. Kacsuk Péter MTA SZTAKI

Az MTA Cloud a tudományos alkalmazások támogatására. Kacsuk Péter MTA SZTAKI Az MTA Cloud a tudományos alkalmazások támogatására Kacsuk Péter MTA SZTAKI Kacsuk.Peter@sztaki.mta.hu Tudományos alkalmazások és skálázhatóság Kétféle skálázhatóság: o Vertikális: dinamikusan változik

Részletesebben

Modell alapú tesztelés mobil környezetben

Modell alapú tesztelés mobil környezetben Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed

Részletesebben

Adat és folyamat modellek

Adat és folyamat modellek Adat és folyamat modellek Előadásvázlat dr. Kovács László Folyamatmodell nyersanyag miből termék mit funkció ki munkaerő eszköz mivel Objektumok Tevékenységek Adatmodell Funkció modell Folyamat modell

Részletesebben

Petri hálók: Alapelemek és kiterjesztések

Petri hálók: Alapelemek és kiterjesztések Petri hálók: Alapelemek és kiterjesztések dr. Bartha Tamás dr. Pataricza András dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Modellek a formális ellenőrzéshez Mivel nyújt többet

Részletesebben

Összeállította Horváth László egyetemi tanár

Összeállította Horváth László egyetemi tanár Óbudai Egyetem Neumann János Informatikai Kar Intelligens Mérnöki Rendszerek Intézet Intelligens Mérnöki Rendszerek Szakirány a Mérnök informatikus alapszakon Összeállította Horváth László Budapest, 2011

Részletesebben

TERC V.I.P. hardverkulcs regisztráció

TERC V.I.P. hardverkulcs regisztráció TERC V.I.P. hardverkulcs regisztráció 2014. második félévétől kezdődően a TERC V.I.P. költségvetés-készítő program hardverkulcsát regisztrálniuk kell a felhasználóknak azon a számítógépen, melyeken futtatni

Részletesebben

Objektumorientált paradigma és a programfejlesztés

Objektumorientált paradigma és a programfejlesztés Objektumorientált paradigma és a programfejlesztés Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján Objektumorientált

Részletesebben

Elérhetőségi analízis Petri hálók dinamikus tulajdonságai

Elérhetőségi analízis Petri hálók dinamikus tulajdonságai Elérhetőségi analízis Petri hálók dinamikus tulajdonságai dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Petri hálók vizsgálata Az elemzés mélysége szerint: Vizsgálati

Részletesebben

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/

Részletesebben

Elektronikusan hitelesített PDF dokumentumok ellenőrzése

Elektronikusan hitelesített PDF dokumentumok ellenőrzése Elektronikusan hitelesített PDF dokumentumok ellenőrzése Adobe Reader beállítása és használata a hitelesített PDF dokumentumok ellenőrzéséhez A dokumentáció szabadon tovább terjeszthető, a legfrissebb

Részletesebben

CAD Rendszerek I. Sajátosság alapú tervezés - Szinkron modellezés

CAD Rendszerek I. Sajátosság alapú tervezés - Szinkron modellezés CAD Rendszerek I. Sajátosság alapú tervezés - Szinkron modellezés Farkas Zsolt Budapesti Műszaki és Gazdaságtudományi Egyetem, Gép- és Terméktervezés Tanszék 1/ 14 Tartalom -Sajátosság alapú tervezés:

Részletesebben

Nagy bonyolultságú rendszerek fejlesztőeszközei

Nagy bonyolultságú rendszerek fejlesztőeszközei Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő

Részletesebben

22. GRÁFOK ÁBRÁZOLÁSA

22. GRÁFOK ÁBRÁZOLÁSA 22. GRÁFOK ÁBRÁZOLÁSA A megoldandó feladatok, problémák modellezése során sokszor gráfokat alkalmazunk. A gráf fogalmát a matematikából ismertnek vehetjük. A modellezés során a gráfok több változata is

Részletesebben

Objektum Vezérelt Szoftverek Analízise

Objektum Vezérelt Szoftverek Analízise Objektum Vezérelt Szoftverek Analízise Ferenc Rudolf és Beszédes Árpád ferenc@inf.u-szeged.hu beszedes@inf.u-szeged.hu Szegedi Tudományegyetem FrontEndART Szoftver Kft. Bevezetés A szoftver rendszerek

Részletesebben

SuliStat felhasználói dokumentáció

SuliStat felhasználói dokumentáció SuliStat felhasználói dokumentáció A jelen dokumentáció által tárgyalt program képes egy iskola tanulmányi adataiból statisztikákat készíteni. Osztály illetve iskola szintű statisztika készítésére van

Részletesebben

Közösség, projektek, IDE

Közösség, projektek, IDE Eclipse Közösség, projektek, IDE Eclipse egy nyílt forráskódú (open source) projekteken dolgozó közösség, céljuk egy kiterjeszthető fejlesztői platform és keretrendszer fejlesztése, amely megoldásokkal

Részletesebben

Technikai információk fejlesztőknek

Technikai információk fejlesztőknek Technikai információk fejlesztőknek Különbségek a Java-s nyomtatványkitöltő program és az Abev2006 között 1. A mezőkód kijelzés bekapcsolása a Szerviz/Beállítások ablakban érhető el. 2. Az xml állományok

Részletesebben

Számítógéppel segített folyamatmodellezés p. 1/20

Számítógéppel segített folyamatmodellezés p. 1/20 Számítógéppel segített folyamatmodellezés Piglerné Lakner Rozália Számítástudomány Alkalmazása Tanszék Pannon Egyetem Számítógéppel segített folyamatmodellezés p. 1/20 Tartalom Modellező rendszerektől

Részletesebben

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2008. 04. 17. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési

Részletesebben

Microsoft SQL Server telepítése

Microsoft SQL Server telepítése Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió

Részletesebben

2 Access 2016 zsebkönyv

2 Access 2016 zsebkönyv 2 Access 2016 zsebkönyv BBS-INFO Kiadó, 2016. 4 Access 2016 zsebkönyv Bártfai Barnabás, 2016. Minden jog fenntartva! A könyv vagy annak oldalainak másolása, sokszorosítása csak a szerző írásbeli hozzájárulásával

Részletesebben

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat.

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. Súgó Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. A lekérdező rendszer a Hírközlési Szolgáltatások és Interfész bejelentések, valamint az

Részletesebben

Magyar Nemzeti Bank - Elektronikus Rendszer Hitelesített Adatok Fogadásához ERA. Elektronikus aláírás - felhasználói dokumentáció

Magyar Nemzeti Bank - Elektronikus Rendszer Hitelesített Adatok Fogadásához ERA. Elektronikus aláírás - felhasználói dokumentáció ERA Elektronikus aláírás - felhasználói dokumentáció Tartalomjegyzék 1. Bevezető... 3 1.1. Általános információk... 3 2. DesktopSign... 3 2.1. Általános információk... 3 2.2. Telepítés... 3 3. MNBSubscriber...

Részletesebben

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben Ráth István rath@mit.bme.hu A grafikus nyelvek... mindenhol ott vannak: Grafikus felületek (Visual Studio) Relációs sémák (dbdesign)

Részletesebben

Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok

Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok Elérhetőségi probléma egyszerűsítése: Állapottér és struktúra redukció Petri-háló alosztályok dr. Bartha Tamás Dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Elérhetőségi probléma

Részletesebben

Algoritmus terv 3. Fejezet: Folyamatok meghatározása

Algoritmus terv 3. Fejezet: Folyamatok meghatározása This image cannot currently be displayed. Algoritmus terv 3. Fejezet: Folyamatok meghatározása 1. Algoritmus általános áttekintése 2. Inputok és outputok definiálása 3. Folyamatok meghatározása 4. ozási

Részletesebben

Dr. Mileff Péter

Dr. Mileff Péter Dr. Mileff Péter 1 2 1 Szekvencia diagram Szekvencia diagram Feladata: objektumok egymás közti üzenetváltásainak ábrázolása egy időtengely mentén elhelyezve. Az objektumok életvonala egy felülről lefelé

Részletesebben

Modellezés Petri hálókkal. dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék

Modellezés Petri hálókkal. dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Modellezés Petri hálókkal dr. Bartha Tamás dr. Majzik István dr. Pataricza András BME Méréstechnika és Információs Rendszerek Tanszék Modellező eszközök: DNAnet, Snoopy, PetriDotNet A DNAnet modellező

Részletesebben

A Java EE 5 plattform

A Java EE 5 plattform A Java EE 5 platform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem Utolsó módosítás: 2007. 11. 13. A Java EE 5 platform A Java EE 5 plattform A J2EE 1.4 után következő verzió. Alapvető továbbfejlesztési

Részletesebben

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan

A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Telepítés internetről A TERC VIP költségvetés-készítő program telepítése, Interneten keresztül, manuálisan Új szolgáltatásunk keretén belül, olyan lehetőséget kínálunk a TERC VIP költségvetéskészítő program

Részletesebben

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

Enterprise extended Output Management. exom - Greendoc Systems Kft. 1

Enterprise extended Output Management. exom - Greendoc Systems Kft. 1 Enterprise extended Output Management exom - Greendoc Systems Kft. 1 exom - Greendoc Systems Kft. 2 Sokféle bementi adatformátum kezelése Adatok fogadása különböző csatornákon Előfeldolgozás: típus meghatározás,

Részletesebben

Területi elemzések. Budapest, 2015. április

Területi elemzések. Budapest, 2015. április TeIR Területi elemzések Felhasználói útmutató Budapest, 2015. április Tartalomjegyzék 1. BEVEZETŐ... 3 2. AZ ELEMZÉSBEN SZEREPLŐ MUTATÓ KIVÁLASZTÁSA... 4 3. AZ ELEMZÉSI FELTÉTELEK DEFINIÁLÁSA... 5 3.1.

Részletesebben

Az ErdaGIS térinformatikai keretrendszer

Az ErdaGIS térinformatikai keretrendszer Az ErdaGIS térinformatikai keretrendszer Két évtized tapasztalatát sűrítettük ErdaGIS térinformatikai keretrendszerünkbe, mely moduláris felépítésével széleskörű felhasználói réteget céloz, és felépítését

Részletesebben

Iman 3.0 szoftverdokumentáció

Iman 3.0 szoftverdokumentáció Melléklet: Az iman3 program előzetes leírása. Iman 3.0 szoftverdokumentáció Tartalomjegyzék 1. Az Iman rendszer...2 1.1. Modulok...2 1.2. Modulok részletes leírása...2 1.2.1. Iman.exe...2 1.2.2. Interpreter.dll...3

Részletesebben

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu Számonkérés 2 Papíros (90 perces) zh az utolsó gyakorlaton. Segédanyag nem használható Tematika 1. félév 3 Óra Dátum Gyakorlat 1. 2010.09.28.

Részletesebben

Czifra Sándor Lőrinczi Konrád. Videó vezérelt kurzusok készítése Moodle keretrendszerben

Czifra Sándor Lőrinczi Konrád. Videó vezérelt kurzusok készítése Moodle keretrendszerben Czifra Sándor Videó vezérelt kurzusok készítése Moodle keretrendszerben A kezdetek... Felsővezetői támogatás. Nemzetközi trendek kutatása. Tanulmány utak, best practice Szakmai iránymutatás, oktatás. Módszertani

Részletesebben

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman Szakterületi modell A fogalmak megjelenítése 9. fejezet Applying UML and Patterns Craig Larman 1 Néhány megjegyzés a diagramokhoz Ez a tárgy a rendszer elemzésről és modellezésről szól. Noha például egy

Részletesebben

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni. Service-Oriented Architecture, SOA Az elosztott rendszerek fejlesztésének módja. Célja:az IT eszközök komplexitásának a kezelésének egyszerűsítése könnyebben újrafelhasználhatóság, egymással integrálhatóság

Részletesebben

Objektum orientált programozás Bevezetés

Objektum orientált programozás Bevezetés Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban

Részletesebben

VBA makrók aláírása Office 2007 esetén

VBA makrók aláírása Office 2007 esetén VBA makrók aláírása Office 2007 esetén Windows tanúsítványtárban és/vagy kriptográfia eszközökön található tanúsítványok esetén Office 2007 alkalmazással 1(10) 1. Tartalomjegyzék 1. Tartalomjegyzék...

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

Webes alkalmazások fejlesztése

Webes alkalmazások fejlesztése Webes alkalmazások fejlesztése 3. gyakorlat Authentikáció, adatok feltöltése Szabó Tamás (sztrabi@inf.elte.hu) - sztrabi.web.elte.hu Authentikáció Manapság már elvárás, hogy a felhasználó regisztrálni

Részletesebben

IP Thermo for Windows

IP Thermo for Windows IP Thermo for Windows (2 db szenzorig ingyenes!) Klímafelügyelő és naplózó szoftver Az IP Thermo klímafelügyelő és naplózó szoftver szobák, épületek, irodák, szállodák teljes körű hőmérsékleti felügyeletére,

Részletesebben

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás: Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban

Részletesebben

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport TANMENET Informatika szakmacsoport Programozási gyakorlatok III. tantárgy 12. évfolyam A osztály 2013/2014 tanév Heti óraszám: Éves óraszám: 3 óra 96 óra Készítette: Szikszai Gusztáv tanár Ellenőrizte:.

Részletesebben

Kriptográfia 0. A biztonság alapja. Számítás-komplexitási kérdések

Kriptográfia 0. A biztonság alapja. Számítás-komplexitási kérdések Kriptográfia 0 Számítás-komplexitási kérdések A biztonság alapja Komplexitás elméleti modellek független, egyenletes eloszlású véletlen változó értéke számítással nem hozható kapcsolatba más információval

Részletesebben

Felhasználói segédlet a Web of Knowledge / Web of Science adatbázis használatához

Felhasználói segédlet a Web of Knowledge / Web of Science adatbázis használatához Felhasználói segédlet a Web of Knowledge / Web of Science adatbázis használatához Az adatbázis elérése, regisztrálás, belépés Az adatbázis az arra jogosult intézmények és felhsználói kör számára a http://eisz.om.hu

Részletesebben

Számítógép architektúra

Számítógép architektúra Budapesti Műszaki Főiskola Regionális Oktatási és Innovációs Központ Székesfehérvár Számítógép architektúra Dr. Seebauer Márta főiskolai tanár seebauer.marta@roik.bmf.hu Irodalmi források Cserny L.: Számítógépek

Részletesebben

Importálás. más típusú (pl:.imp,.xml,.xkr,.xcz) állomány beimportálása a nyomtatványkitöltő programba

Importálás. más típusú (pl:.imp,.xml,.xkr,.xcz) állomány beimportálása a nyomtatványkitöltő programba Importálás Külső programok által generált imp és.xml állományokat be lehet tölteni a program import funkcióival. Az ABEV2006 az xml állományok importálását nem tudta. Ez újdonság a nyomtatványkitöltő programban.

Részletesebben

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja 1 / 15 Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja Vajna Miklós 2012. január 24. Tartalomjegyzék 2 / 15 1 Bevezető 2 Motiváció 3

Részletesebben

Informatika tanterv nyelvi előkészítő osztály heti 2 óra

Informatika tanterv nyelvi előkészítő osztály heti 2 óra Informatika tanterv nyelvi előkészítő osztály heti Számítógép feladata és felépítése Az informatikai eszközök használata Operációs rendszer Bemeneti egységek Kijelző egységek Háttértárak Feldolgozás végző

Részletesebben

Erőforrás gazdálkodás a bevetésirányításban

Erőforrás gazdálkodás a bevetésirányításban Professzionális Mobiltávközlési Nap 2009 Új utakon az EDR Erőforrás gazdálkodás a bevetésirányításban Fornax ZRt. Nagy Zoltán Vezérigazgató helyettes Budapest, 2009. április 9. Tartalom 1. Kézzelfogható

Részletesebben

Kommunikációs rendszerek teljesítőképesség-vizsgálata

Kommunikációs rendszerek teljesítőképesség-vizsgálata Kommunikációs rendszerek teljesítőképesség-vizsgálata (3. előadás) Dr. Lencse Gábor lencse@sze.hu https://www.tilb.sze.hu/cgi-bin/tilb.cgi?0=m&1=targyak&2=krtv 1 Miről lesz szó? Az OMNeT++ diszkrét idejű

Részletesebben

Objektumorientált paradigma és programfejlesztés Bevezető

Objektumorientált paradigma és programfejlesztés Bevezető Objektumorientált paradigma és programfejlesztés Bevezető Vámossy Zoltán vamossy.zoltan@nik.uni-obuda.hu Óbudai Egyetem Neumann János Informatikai Kar Ficsor Lajos (Miskolci Egyetem) prezentációja alapján

Részletesebben

Informatikai alapismeretek Földtudományi BSC számára

Informatikai alapismeretek Földtudományi BSC számára Informatikai alapismeretek Földtudományi BSC számára 2010-2011 Őszi félév Heizlerné Bakonyi Viktória HBV@ludens.elte.hu Titkosítás,hitelesítés Szimmetrikus DES 56 bites kulcs (kb. 1000 év) felcserél, helyettesít

Részletesebben

GIS adatgyűjtés zseb PC-vel

GIS adatgyűjtés zseb PC-vel GIS adatgyűjtés zseb PC-vel Mit jelent a midas GIS kifejezés? Mapping Information Data Acquisition System Térképi Információ- és Adat Gyűjtő Rendszer Terepi adatgyűjtés a felhasználó által definiált adatbázisban.

Részletesebben

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb. SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.hu Mesterséges intelligencia oktatás a DE Informatikai

Részletesebben

1. A VHDL mint rendszertervező eszköz

1. A VHDL mint rendszertervező eszköz 1.1. A gépi tervezés A gépi leíró nyelvek (HDL) célja az egyes termékek egységesítése, logikai szimulációhoz leíró nyelv biztosítása, a terv hierarchikus felépítésének tükrözése és a nagy tervek áttekinthetővé

Részletesebben

Bevezetés a QGIS program használatába Összeálította dr. Siki Zoltán

Bevezetés a QGIS program használatába Összeálította dr. Siki Zoltán Bevezetés Bevezetés a QGIS program használatába Összeálította dr. Siki Zoltán A QGIS program egy nyiltforrású asztali térinformatikai program, mely a http://www.qgis.org oldalról tölthető le. Ebben a kis

Részletesebben

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás

Petőfi Irodalmi Múzeum. megújuló rendszere technológiaváltás Petőfi Irodalmi Múzeum A Digitális Irodalmi Akadémia megújuló rendszere technológiaváltás II. Partnerek, feladatok Petőfi Irodalmi Múzeum Megrendelő, szakmai vezetés, kontroll Konzorcium MTA SZTAKI Internet

Részletesebben

Színezett Petri hálók

Színezett Petri hálók Színezett Petri hálók dr. Bartha Tamás dr. Majzik István BME Méréstechnika és Információs Rendszerek Tanszék Motiváció Étkező filozófusok Petri-háló modellje: C1 P1 C2 P5 C5 P2 C3 P4 C4 P3 2 Motiváció

Részletesebben

Book Template Title. Author Last Name, Author First Name

Book Template Title. Author Last Name, Author First Name Book Template Title Author Last Name, Author First Name Book Template Title Author Last Name, Author First Name I. rész - Szoftver technológia 1. fejezet - Esettanulmány Bevezetés Az alkalmazás fejlesztésére

Részletesebben

MS ACCESS 2010 ADATBÁZIS-KEZELÉS ELMÉLET SZE INFORMATIKAI KÉPZÉS 1

MS ACCESS 2010 ADATBÁZIS-KEZELÉS ELMÉLET SZE INFORMATIKAI KÉPZÉS 1 SZE INFORMATIKAI KÉPZÉS 1 ADATBÁZIS-KEZELÉS MS ACCESS 2010 A feladat megoldása során a Microsoft Office Access 2010 használata a javasolt. Ebben a feladatban a következőket fogjuk gyakorolni: Adatok importálása

Részletesebben

Programozási technikák Pál László. Sapientia EMTE, Csíkszereda, 2009/2010

Programozási technikák Pál László. Sapientia EMTE, Csíkszereda, 2009/2010 Programozási technikák Pál László Sapientia EMTE, Csíkszereda, 2009/2010 12. ELŐADÁS Adatbázis-kezelés Delphiben 2 Adatmegjelenítés lekérdezés segítségével A táblákhoz hasonlóan a lekérdezések is az adatbázis

Részletesebben

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel

Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel Csináljunk az adatból információt! A Lone-Soft listázó keretrendszerrel A piacon lévő ügyviteli szoftverek jó részének legnagyobb hibája, hogy a letárolt adatokat nem képesek a felhasználó által hasznosítható

Részletesebben

A PiFast program használata. Nagy Lajos

A PiFast program használata. Nagy Lajos A PiFast program használata Nagy Lajos Tartalomjegyzék 1. Bevezetés 3 2. Bináris kimenet létrehozása. 3 2.1. Beépített konstans esete.............................. 3 2.2. Felhasználói konstans esete............................

Részletesebben

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató Közoktatási Statisztika Tájékoztató 2012/2013 Tartalomjegyzék 1. Technikai információk... 2 2. Publikus felület... 2 2.1 Bejelentkezés... 2 2.2 Összesítés... 3 2.2.1 Statisztikai tábla megtekintése...

Részletesebben

Adatbázismodellek. 1. ábra Hierarchikus modell

Adatbázismodellek. 1. ábra Hierarchikus modell Eddig az adatbázisokkal általános szempontból foglalkoztunk: mire valók, milyen elemekből épülnek fel. Ennek során tisztáztuk, hogy létezik az adatbázis fogalmi modellje (adatbázisterv), amely az egyedek,

Részletesebben

Adatszerkezetek Tömb, sor, verem. Dr. Iványi Péter

Adatszerkezetek Tömb, sor, verem. Dr. Iványi Péter Adatszerkezetek Tömb, sor, verem Dr. Iványi Péter 1 Adat Adat minden, amit a számítógépünkben tárolunk és a külvilágból jön Az adatnak két fontos tulajdonsága van: Értéke Típusa 2 Adat típusa Az adatot

Részletesebben

Matlab Fuzzy Logic Toolbox

Matlab Fuzzy Logic Toolbox Matlab Fuzzy Logic Toolbox The Future looks Fuzzy Newsweek, May, 28, 1990. A fuzzy irányítási rendszerek vizsgálatára Windows alatt futó Matlab programcsomag szimulációs eszközeit és a Matlab-ra ráépülő

Részletesebben

MIKOVINY SÁMUEL TÉRINFORMATIKAI EMLÉKVERSENY

MIKOVINY SÁMUEL TÉRINFORMATIKAI EMLÉKVERSENY NYUGAT-MAGYARORSZÁGI EGYETEM GEOINFORMATIKAI KAR MIKOVINY SÁMUEL TÉRINFORMATIKAI EMLÉKVERSENY 2012/2013. TANÉV Az I. FORDULÓ FELADATAI NÉV:... Tudnivalók A feladatlap 4 feladatból áll, melyeket tetszőleges

Részletesebben

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása Szabó Zsolt adatbiztonság tároláskor Felhasználók hitelesítése adatbiztonság szállításkor Felhasználóknak szeparálása jogi és szabályozási kérdések incidens kezelés öntitkosító meghajtókat Hardveres Softveres

Részletesebben

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31

Bánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31 IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma

Részletesebben

Kulcsár Attila. A második szint GeoCalc GIS 2. GISopen 2012 konfrencia. www.geocalc.hu

Kulcsár Attila. A második szint GeoCalc GIS 2. GISopen 2012 konfrencia. www.geocalc.hu Kulcsár Attila A második szint GISopen 2012 konfrencia 1 GeoCalc GIS története 2006 Alapverzió (csak adatbázisokkal együtt Temető nyilvántartás) 2008 GeoCalc GIS 1.0 2011 GeoCalc GIS 1.5 (hierarchia, földtömegszámítás,

Részletesebben

Interfészek. PPT 2007/2008 tavasz.

Interfészek. PPT 2007/2008 tavasz. Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése 2 Már megismert fogalmak áttekintése Objektumorientált

Részletesebben

Bevezetés az informatikába

Bevezetés az informatikába Bevezetés az informatikába 6. előadás Dr. Istenes Zoltán Eötvös Loránd Tudományegyetem Informatikai Kar Programozáselmélet és Szoftvertechnológiai Tanszék Matematikus BSc - I. félév / 2008 / Budapest Dr.

Részletesebben

Alapok (a K2D rendszer alapjai)

Alapok (a K2D rendszer alapjai) Alapok (a K2D rendszer alapjai) 1 1. Bevezetés... 3 2. Fastruktúra... 3 2.1. Nyitása, zárása... 3 2.2. Fülek... 5 2.3. Licence kulcs érvényesítése... 9 2.4. Új elem felvitele... 10 2.5. Elem törlése...

Részletesebben

Utolsó módosítás:

Utolsó módosítás: Utolsó módosítás: 2012. 09. 06. 1 A tantárggyal kapcsolatos adminisztratív kérdésekkel Micskei Zoltánt keressétek. 2 3 4 5 6 7 8 9 Forrás: Gartner Hype Cycle for Virtualization, 2010, http://premierit.intel.com/docs/doc-5768

Részletesebben