Implementierung einer Visualisierung von Petrinetzen

Algorithmen zur Analyse selbst. Zus¨atzlich wird den Analysemethoden die M¨oglichkeiten einer kleinen grafischen Oberfl¨ache gegeben.

Einige Analysemethoden verf¨ugen ¨uber Parameter, zum Beispiel das zu verwendende Distanzmaß zur Berechnung der T-Cluster. Das InterfaceConfiguration dient dazu, solche Parameter zu definieren und f¨ur das Durchf¨uhren der Analyse zur Verf¨ugung zu stellen.

Da nicht vorhergesagt werden kann, welche Parameter eine Analysemethode ben¨otigt, ist dieses Interface sehr schlicht gehalten. Es gibt unter anderem vor, dass dieequals-Funktion implementiert werden muss sowie die dazugeh¨orige FunktionhashCode, um verschiedene Parameterkombinationen eindeutig unterscheiden zu k¨onnen. Welche Parameter gespei-chert werden und wie der Zugriff auf diese erfolgt, ist der Implementierung dieses Interfaces v¨ollig frei gelassen.

Die Resultate einer Analysemethode werden in Klassen gespeichert, die das Interface Result implementieren. Das Speichern der Resultate an sich ist dabei jeder Implemen-tierung frei ¨uberlassen, da auch hier nicht vorhergesagt werden kann, welche Form diese haben werden. Lediglich zwei Funktion zum Export der Resultate in eine Datei werden vom Interface definiert.

Durch die in diesem Abschnitt beschriebenen und in MonaLisa implementierten Strukturen k¨onnen schnell und einfach neue Analysemethoden zuMonaLisa hinzugef¨ugt werden. Sollte, wie beschrieben,MonaLisa um neue Varianten vonPNerweitert werden, muss das Interface Tool ebenfalls angepasst werden. F¨ur eine Analysemethode m¨usste hier zus¨atzlich vermerkt sein, f¨ur welche PN-Implementation diese ausgelegt ist. Auch hier w¨urde das Schaffen einer komplett neuen Klassenstruktur entfallen.

nutztRenderer-Klassen, um die verschiedenen Aspekte der Visualisierung, wie zum Bei-spiel Farbe oder Form eines Knotens, festzulegen. Durch ¨Uberschreiben dieser Klassen ist es dem Programmierer sehr leicht m¨oglich, diese Eigenschaften zu beeinflussen. Diese k¨onnen global f¨ur alle Knoten oder aber f¨ur jeden Knoten einzeln ge¨andert werden. Die Klassen unterliegen hierbei dem Prinzip der generischen Programmierung. Ein bekanntest Beispiel f¨ur dieses Konzept ist die Java KlasseList, in welcher nur Elemente eines Daten-typs gespeichert werden. Da aber nicht f¨ur jeden Datentyp eine eigene Implementierung der KlasseList vorliegen kann, wird der Datentyp der Liste erst beim Initialisieren dieser gesetzt, zum Beispiel List<Integer>. Genauso verh¨alt es sich bei der Klasse Graph der JUNG-Bibliothek. Der Datentyp der Klasse f¨ur die Knoten und Kanten ist erst einmal nicht bekannt, denn der Entwickler kann diese frei w¨ahlen. Im Falle des NetViewer wer-den hierzu jedoch nicht die vorhanwer-denen Klassen derPN-Repr¨asentation verwendet. Zum Einen liegen hier zwei Klassen f¨ur die Knoten des PN vor, Place und Transition, von JUNG wird aber nur ein Klasse f¨ur Knoten unterst¨utzt. Zum Zweiten werden f¨ur die Vi-sualisierung andere Anforderungen gestellt, da viel mehr Informationen in den Knoten gespeichert werden m¨ussen, wie zum Beispiel dessen Farbe oder Form. Und zum Dritten sollte das Anlegen logischer Pl¨atze m¨oglich sein, also eine Kopie eines Platzes, welcher nur mit bestimmten Knoten verbunden ist. Ein solcher Platz existiert in der Visualisierung mehrmals, im darunterliegenden PN aber nur einmal. Diese drei Aspekte f¨uhrten dazu, dass von einer Erweiterung der vorhandenen Klassen abgesehen wurde, zumal es sich so vermeiden ließ, die vorhandenen Klassen, welche auf dasPN zugreifen, anzupassen. Statt-dessen wurden die beiden Klassen NetViewerNode und NetViewerEdge implementiert, deren UML Diagramm in Ausz¨ugen in Abbildung 3.3 zu sehen sind.

Zur Unterscheidung zwischen Transitionen und Pl¨atzen besitzt die Klasse NetView-erNode das Attribut nodeType, welches diese Zuordnung zul¨asst. Weiter werden in dieser Klasse alle Informationen zur Visualisierung des Knotens gespeichert. Dazu z¨ahlen unter anderem die F¨ullfarbe, die Farbe der Umrandung und die Form. Ein weiteres Attribut gibt Auskunft, ob es sich um einen logischen Platz handelt. Ist dies der Fall, existiert ein Mas-ter Node, welcher den urspr¨unglichen Platz repr¨asentiert. Dieser kennt alle seine logischen Pl¨atze sowie jeder logischen Pl¨atze seinenMaster Node kennt. Denn wird zum Beispiel die Farbe eines logischen Platzes ge¨andert, wird diese f¨ur alle anderen Pl¨atze gleichen Namens ebenfalls ¨ubernommen.

Die Klasse NetViewerEdge speichert neben dem Kantengewicht ebenfalls Informatio-nen zur Farbe einer Kante. Wird ein Knick in eine Kante eingebaut, so geschieht dies durch das Platzieren eines unsichtbaren Knotens an dieser Stelle und das Aufteilen der Kante in zwei neue Kanten. Die urspr¨ungliche, direkte Kante, wird jedoch nicht gel¨oscht, sondern lediglich unsichtbar gemacht. Das L¨oschen dieser Kante w¨urde dazu f¨uhren, dass

¨uber dieGraph-Klasse nicht mehr die Nachbarschaft zweier echter Knoten abgefragt wer-den k¨onnte. Wie bei den logischen Pl¨atzen, kennt jede so erzeugte Zwischenkante seine Master Edge. AlsGraph-Klasse wird inMonaLisa die KlasseSparseGraph verwendet.

Abbildung 3.3: Die Abbildung zeigt in Ausz¨ugen die UML-Klassendiagramme der beiden Klas-senNetviewerNode und NetViewerEdge. Diese beiden Klassen werden im NetViewer verwendet, um die grafische Repr¨asentation einesPN zu realisieren. In der KlasseNetViewerNode dienen die meisten Attribute dazu, die grafischen Eigenschaften eines Platzes oder einer Transition zu spei-chern, so unter anderem die F¨ullfarbe, die Farbe der Umrandung, die Form oder die Position der Beschriftung. Daneben gibt es weitere Attribute und Funktionen, die dem Verwalten der logischen Pl¨atze dienen. In der KlasseNetViewerEdge wird die Farbe und das Gewicht einer Kante gespei-chert sowie Informationen zu eingebauten Knicken in dieser. Beide Klassen implementieren das InterfaceSerializable.

umfangreiche M¨oglichkeiten zum Anpassen dieser. Die Darstellung der einzelnen Elemen-te kann ebenso beeinflusst werden wie das Layout durch Hinzuf¨ugen logischer Pl¨atze und Knicke in Kanten. Logische Pl¨atze erm¨oglichen eine Verbesserung des Layouts, da durch diese die Anzahl kreuzender Kanten reduziert werden kann. Ein weiteres Element, welches bei der besseren Organisation des Layouts helfen kann, sind hierarchische Transitionen.

Eine solche stellt in der Visualisierung desPN eine Transition dar, hinter der jedoch eine gr¨oßere Struktur an Pl¨atzen und Transitionen verborgen ist, die auf diese Weise versteckt wird. Sie agiert also als Blackbox. So k¨onnen gr¨oßere oder kleine Substrukturen eines Modells zwar modelliert werden, ihre grafische Darstellung jedoch reduziert werden, um ein ¨ubersichtlicheres Layout zu erhalten. Das Erweitern vonMonaLisa um hierarchische Transitionen w¨are ein n¨achster Schritt f¨ur die Weiterentwicklung der Software. Hierzu ist jedoch ein gr¨oßerer Eingriff in die Funktionalit¨aten der Klassen f¨ur die Visualisierung des PN n¨otig. So muss zum Beispiel die Zuordnung einzelner Elemente des PN zu der Sub-struktur einer hierarchischen Transition erm¨oglicht werden. Weiter muss eine M¨oglichkeit geschaffen werden, wie die Elemente dieser Substrukturen modelliert und editiert werden oder bedacht werden k¨onnen.

Sollte, wie beschrieben, MonaLisa um weitere PN-Varianten erweitert werden, so wird ebenfalls eine Anpassung der Visualisierung derPN n¨otig. Wie bei den Klassen zur

Repr¨asentation eines PN w¨urde auch hier keine komplett neue Klassenstruktur notwen-dig, und die vorhandenen Klassen k¨onnen als Ausgangspunkt der neuen Klassen verwendet werden. Dank der generischen Klassen von JUNG w¨are die Implementation neuer Klas-sen f¨ur Transitionen, Pl¨atze und Kanten, um zum Beispiel inhibitorische Kanten oder zeitabh¨angige Transitionen zu repr¨asentieren, sehr einfach. F¨ur die Visualisierung dieser neuen Elemente m¨ussten neueRenderer Klassen implementiert werden.

3.1.4 Implementierung einer Synchronisation zwischen demPN und der