Entwurf und Implementierung eines graphischen Modelleditors und einer Benutzerschnittstelle für das Werkzeug CASPA

Transkript

1 Entwurf und Implementierung eines graphischen Modelleditors und einer Benutzerschnittstelle für das Werkzeug CASPA Diplomarbeit von Jens Bachmann UniBwM ID 05/2007 Aufgabenstellung: Univ.-Prof. Dr.-Ing. Markus Siegle Betreuung: Dipl.-Inf. Martin Riedl Univ.-Prof. Dr.-Ing. Markus Siegle Abgabedatum: Universität der Bundeswehr München Fakultät für Informatik

2 ii

3 iii Ich versichere, diese Arbeit ohne fremde Unterstützung und ohne Verwendung anderer als den angegebenen Quellen angefertigt zu haben. Des Weiteren wurde diese Arbeit weder in gleicher noch in ähnlicher Form einer anderen Prüfungsbehörde als Teil einer Prüfungsleistung vorlegt. Alle Angaben, die sinngemäß aus anderen Quellen übernommen wurden, sind entsprechend gekennzeichnet. Jens Bachmann Neubiberg,

4 iv

5 Abstract This diploma thesis deals with the conception and development of a graphical editor for the performance evaluation tool Caspa. This software-tool was developed at the Department of Computer Science at the University of Erlangen-Nuremberg and at the Institute of Computer Engineering at the University of German Armed Forces in Munich. Caspa is able to model and evaluate (distributed) computer systems in a very efficient way with the help of a symbolic (BDD-based) data format and different algorithms. The modelling of systems is based on stochastic process algebras. Caspa works with this formalism and enables the user to define complex systems via a text file interface. Motivated by the tedious interaction with the tool by text files and command line output, as result this thesis should increase the usability. This will be reached by the development of a graphical user interface with modelling capabilities. So the efficient kernel of the tool Caspa can be opened for new users from other institutes. Different, relevant frameworks of the open source development environment Eclipse are used to construct such an editor. These frameworks support the development in a shorter time and in a less buggy manner than production from scratch. The basis of this way of development and the frameworks is the model driven software development. The graphical editor itself is based on a model which realizes the elements of the Caspa-syntax. At the end of this thesis the editor is able to implement the complete interaction with Caspa. The user can build new models, which can be stored, exported and used for input of Caspa. Existing input files of former projects can be imported by the editor and re-edited by the user. There will be also a way to execute the tool Caspa within the editor. So the usage of command line is obsolete. This thesis also shows the interrelation between the different frameworks and enables future developers to continue the implementation of this graphical editor. The thesis also contains a user manual, which will help new users to work with the editor. v

6 vi

7 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung und Ziele dieser Arbeit Gliederung Grundlagen Das Tool Caspa Modellgetriebene Softwareentwicklung Eclipse Modeling Framework Graphical Editing Framework Graphical Modeling Framework Java Emitter Templates Java Compiler Compiler Plug-In-Development unter Eclipse Losgelöst vom Eclipse IDE - Die Rich Client Platform Konzeption und Implementierung Möglichkeiten der Umsetzung Das Modell des Editors Die Erstellung des Editors Definition der graphischen Elemente Definition der Werkzeuge Definition des Mappings vii

8 viii INHALTSVERZEICHNIS Erzeugung und Anpassung des Generatormodells Die erzeugten Pakete und ihre Klassen Anpassungen im generierten Code Eclipse Plug-In vs. Rich Client Platform Verwendete Software Implementierung der Funktionalitäten Der Export von Diagrammmodellen zu Caspa-Dateien Das Importieren von Caspa-Dateien Das Ausführen von Caspa innerhalb des Editors Testen des geschaffenen Produktes Benutzerhandbuch Einstieg Arbeit mit dem Editor Die Erstellung eines graphischen Modells Validierung von Modellen Export von Modellen Import von Eingabedateien Ausführen von Caspa Zusammenfassung Ergebnisse der Arbeit Ausblick Abkürzungsverzeichnis 89 Abbildungsverzeichnis 91 Verzeichnis der Listings 93 Literaturverzeichnis 95

9 Kapitel 1 Einleitung Diese Diplomarbeit beschäftigt sich mit der Konzeption und Entwicklung eines graphischen Editors für das Tool Caspa. Dieses Software-Tool wurde am Institut für Informatik der Universität Erlangen-Nürnberg und am Institut für Technische Informatik der Universität der Bundeswehr München entwickelt. Es entstand in einer Diplomarbeit aus dem Jahre 2003 von Edith Werner. Mittels spezieller Algorithmen und Datenstrukturen ist es in der Lage, sehr effizient Rechen- und Kommunikationssysteme zu modellieren und zu bewerten. Als Modellierungs- Formalismus dienen stochastische Prozessalgebren. Caspa bietet die Möglichkeit, komplexe Systeme textuell nach diesem Formalismus zu spezifizieren. Da die Interaktion mit dem Werkzeug bisher nur über textuelle Dateieingabe und Kommandozeilenausgabe möglich ist, wird im Rahmen dieser Arbeit die Benutzerfreundlichkeit gesteigert werden. Dies geschieht durch die Schaffung einer graphischen Bedienoberfläche, in der eine Spezifikation des zu analysierenden Modells erfolgt. Somit kann dieses leistungsfähige Werkzeug eine höhere Akzeptanz auch außerhalb des genannten Institutes durch neue Anwender erfahren. Um dies zu erreichen, werden verschiedene, sehr aktuelle Frameworks der Open- Source-Entwicklungsumgebung Eclipse verwendet, die die Entwicklung eines graphischen Editors in kürzerer Zeit und auch weniger fehlerbehaftet als durch vollständige Neuentwicklung ermöglichen. Als Grundlage für diese Art der Entwicklung gilt die modellgetriebene Softwareentwicklung, die in diesen Frameworks ihre Anwendung findet. Der Editor selbst basiert auf einem Modell, in dem die Elemente der Caspa-Syntax realisiert sind. Mit dem Abschluss der Arbeit ist es möglich, das Tool Caspa komplett über diesen Editor zu nutzen. Man ist in der Lage, neue Modelle anzulegen, welche für die spätere Bearbeitung gespeichert und weiterhin auch exportiert und zur Eingabe in Caspa verwendet werden können. Der Editor unterstützt auch die Verarbeitung bereits existierender Eingabedateien, um vorhandene Projekte fortzuführen, graphisch weiter zu bearbeiten und zu verändern. Innerhalb des Editors wird eine Möglichkeit zur Ausführung des Tools geschaffen, die die Benutzung der Kommandozeile unnötig macht. Diese Arbeit wird den Zusammenhang der verschiedenen Frameworks aufzeigen und es so einem nachfolgenden Entwickler ermöglichen, die Implementierung des Editors fortzuführen. Außerdem beihaltet sie ein Benutzerhandbuch, welches den Umgang mit dem graphischen Edi- 1

10 2 KAPITEL 1. EINLEITUNG tor für neue Nutzer erleichtern soll. Die folgende Aufgabenstellung bildete die Grundlage dieser Diplomarbeit. 1.1 Aufgabenstellung und Ziele dieser Arbeit Caspa ist ein Software-Werkzeug für die Modellierung und Bewertung von Rechen- und Kommunikationssystemen, das von der Arbeitsgruppe um Prof. Dr. Markus Siegle am Institut für Technische Informatik an der Universität der Bundeswehr München entwickelt wurde. Die in Caspa implementierten Datenstrukturen und Algorithmen sind enorm leistungsfähig. Das Werkzeug verfügt jedoch im Moment lediglich über sehr einfache Möglichkeiten der Interaktion mit dem Benutzer, realisiert durch eine kombinierte Datei- und Kommandozeilen-Schnittstelle. Die von Caspa zu analysierenden Modelle werden dabei textuell spezifiziert. Zukünftig soll eine graphische Spezifizierung der Modelle möglich sein, um das Werkzeug auch ungeübten Benutzern besser zugänglich zu machen. Neben der Realisierung dieser graphischen Modelleingabe soll in dieser Arbeit die Bedienoberfläche des Werkzeugs auf einen aktuellen Stand gebracht werden. 1.2 Gliederung Nach der Abhandlung der Bedeutung von Caspa und der zu Grunde liegenden stochastischen Prozessalgebren folgen in Kapitel 2 einige Grundlagen zur modellgetriebenen Entwicklung von Software und der Vorstellung der verwendeten Frameworks. Im Anschluss erläutert diese Arbeit die Herangehensweise und Umsetzung der Entwicklung eines graphischen Modelleditors in Kapitel 3. Dabei wird speziell auf die Verwendung des von der Eclipse-Community zur Verfügung gestellten Modeling Frameworks eingegangen. Schritt für Schritt kann man hierbei nachvollziehen, wie ein graphischer Editor entsteht und welche Überlegungen im Vorfeld angestellt werden müssen. Da die Generierung des Editor-Quellcodes durch die Frameworks nur den groben äußeren Rahmen erzeugt, müssen viele Details durch eigene Implementierungen und Ergänzungen geschaffen werden. Bei der Erzeugung entsteht standardmäßig eine Eclipse-Erweiterung (Plug-In), die nur innerhalb einer installierten Eclipse-Umgebung lauffähig ist. Da aber eine eigenständige Editorumgebung für den gewünschten Einsatz besser geeignet ist, folgt die Erläuterung zur Gewinnung einer unabhängigen, sogenannten Rich-Client-Platform. Im weiteren Verlauf werden die wichtigen Funktionalitäten, die die Schnittstelle zwischen graphischem Editor und dem Werkzeug Caspa repräsentieren, genauer beleuchtet. Das Benutzerhandbuch befindet sich in Kapitel 4, welches dem neuen Anwender den schnellen und sicheren Umgang mit dem geschaffenen Editor ermöglichen soll. Hierbei werden alle Funktionalitäten genau beschrieben, ohne dabei auf jegliche Implementation einzugehen. Da der Editor auch dem Einsatz in Forschung und Lehre dienen soll, bietet sich dieses Kapitel zur Einarbeitung des jeweiligen Benutzers an. Das Kapitel 5 stellt eine Zusammenfassung der vorliegenden Arbeit dar. Dabei werden die Ergebnisse der Arbeit betrachtet sowie ein Ausblick auf weitere Ansätze und Verwendungsmöglichkeiten der hier verwendeten Frameworks gegeben.

11 Kapitel 2 Grundlagen Dieses Kapitel beginnt in Abschnitt 2.1 mit einer kurzen Vorstellung des Werkzeugs Caspa. Danach werden die Grundlagen der modellgetriebenen Software-Entwicklung in Abschnitt 2.2 erläutert. Für diesen Einsatz stehen verschiedene Frameworks bereits zur Verfügung, auf welche in den Abschnitten 2.3 bis 2.4 genauer eingegangen wird. Zur Umsetzung wurden weitere Werkzeuge benötigt, deren grundlegender Einsatz nachfolgend in den Abschnitten 2.6 und 2.7 beschrieben wird. Eine Einführung in die Entwicklung von Erweiterungen der Entwicklungsumgebung Eclipse sowie der Rich-Client-Platform runden dieses Kapitel ab. Ein Hinweis vorweg: Der Editor wurde komplett, das heißt sämtliche Ausgaben des Editors und der zugrunde liegende Quellcode (Kommentare und Bezeichner), in englischer Sprache entwickelt. Das ermöglicht vor allem den Einsatz des Editors durch internationale Studenten und Wissenschaftler. Die genutzten Frameworks verwenden englische Fachbegriffe, welche im Laufe der Arbeit erläutert und übersetzt werden, die aber beibehalten werden, um die Arbeit mit den Werkzeugen zu erleichtern. In dieser Arbeit werden eingeführte Fachbegriffe der Frameworks, Klassen- und Paketnamen kursiv hervorgehoben. Die Namen von Methoden sowie Bezeichner aus verwendeten Beispielen werden in Schreibmaschinenschrift dargestellt. 2.1 Das Tool Caspa Dieser Abschnitt erläutert die Bedeutung des zugrunde liegenden Werkzeugs Caspa, welches sich als besonders leistungsfähig für Modellierungs- und Analysezwecke auszeichnet. Caspa ist ein Werkzeug zur Realisierung sogenannter stochastischer Prozessalgebren (SPA). Diese werden laut [1] zur Verhaltensmodellierung verteilter 1, nebenläufiger Systeme verwen- 1 Ein verteiltes System stellt nach [2] einen Zusammenschluss unabhängiger, heterogener Rechner dar, die nach außen wie ein einzelner Rechner wirken. Sie verfügen über keinen gemeinsamen Speicher und können ausschließlich über Nachrichten miteinander kommunizieren. Als Beispiele sind Client-Server-Systeme und Mobilfunknetze zu erwähnen. 3

12 4 KAPITEL 2. GRUNDLAGEN det. Mit ihnen ist es möglich, neben funktionalen Eigenschaften auch quantitative Eigenschaften wie Leistungs- und Zuverlässigkeitsmaße solcher Systeme zu bestimmen. Sie erweitern die klassischen Prozessalgebren so, dass es möglich ist, das zeitliche Verhalten eines Systems zu analysieren. Im Modell wird das Verhalten von Prozessen, ihre Kommunikation und Synchronisation miteinander beschrieben. Die Prozesse können Aktionen unabhängig oder in Zusammenarbeit mit anderen Prozessen ausführen. Das Verhalten eines Prozesses kann durch sequentielles Ausführen von Aktionen, Verzweigungen und Rekursion charakterisiert werden. Durch einen Paralleloperator können mehrere Prozesse parallel geschaltet und bei Bedarf über bestimmte Aktionen synchronisiert werden. Dieses SPA-Modell wird zur Analyse in ein beschriftetes Transitionssystem überführt. Dadurch entsteht eine Darstellung, die Zustandsautomaten ähnlich ist und funktionale Analysen (Erreichbarkeitsanalyse) zulässt. Weiterhin ist damit die zeitliche Analyse ermöglicht. Mittels numerischer Untersuchung ist man in der Lage, Zustandswahrscheinlichkeiten und Leistungsmaße zu ermitteln. Gemäß [3] können mit Caspa verteilte, modulare Systeme nachgebildet werden. Modulare Systeme sind diejenigen, welche wiederum aus kleineren Systemen (Module, Bausteine) bestehen. Bevor ein großes System zum Einsatz kommen kann, sollte man es spezifizieren und seine Systemeigenschaften testen. Dies geschieht durch formale Methoden, wie die erwähnten stochastische Prozessalgebren und stochastische Petrinetze. Große Systeme können somit sehr effizient in einem Modell abgebildet werden. Allerdings kann es bei der Berechnung der Zustände im System, insbesondere durch parallelgeschaltete Prozesse, zur Zustandsraumexplosion kommen. Man benötigt daher eine effiziente Art der Speicherung und Verarbeitung der Transitionssysteme. In Caspa wurden hierzu binäre Entscheidungsdiagramme mit mehreren Blattknoten verwendet. Diese werden als Multi-Terminal Binary Decision Diagrams (MTBDDs) bezeichnet. Nicht zuletzt ermöglicht dies eine effiziente, numerische Analyse der durch die kompakte Eingabesprache definierten Systeme. Caspa ist weiterhin in der Lage, spezifizierte Leistungsmaße des Systems zu berechnen, was für die Interpretation des Analyseergebnisses von Vorteil ist. Im Folgenden werden die einzelnen Elemente, welche in Caspa Verwendung finden, genauer beleuchtet. Elemente des Werkzeugs In der Eingabesprache von Caspa gibt es einen Definitionsteil, in dem Konstanten für das gesamte System und Raten für die Transitionen definiert werden können. int max=5; rate lambda=20; Im Beispiel wird eine Konstante mit dem Namen max und dem Wert 5 und eine Rate lambda mit dem Wert 20 deklariert. Diese können im weiteren Verlauf der Deklarationen von System und Prozessen verwendet werden. Ein Konstante kann aber auch durch einen arithmetischen Ausdruck spezifiziert werden. Ein Rate hingegen kann nur als Gleitkomma- oder ganze Zahl definiert werden.

13 2.1. DAS TOOL CASPA 5 Ein Systemteil dient zur Spezifizierung des Gesamtsystem durch Komposition der einzelnen beteiligten Prozesse innerhalb des Systems. Diese können zum Beispiel durch Synchronisation über bestimmte Aktionen parallel verknüpft werden. Das bedeutet, dass die Aktionen von den Prozessen synchron ausgeführt werden. Man ist in der Lage, durch Anwendung von hide bestimmte Aktionen eines Prozesses zu verdecken. Diese Aktionen werden demzufolge nach außen durch τ repräsentiert. S := P(1) [send] hide b in Q(2) Das System, hier mit S bezeichnet, besteht aus den beiden Prozessen P und Q. Der Prozess P wird mit dem Wert 1 und der Prozess Q, für den die Aktion b nach außen verdeckt wird, mit dem Parameterwert 2 initialisiert. Beide Prozesse synchronisieren sich über die Aktion send. Ein weiterer Teil der Eingabesprache ist der Prozessdefinitionsteil. In diesem werden für den jeweiligen Prozess die Zustände mit den Transitionen definiert. Hiermit wird das interne Verhalten eines Prozesses beschrieben. Die Transitionen werden durch eine Aktion und eine Rate spezifiziert. Sie können weiterhin Wächter für Prozessvariablen enthalten. Zustände eines Prozesses unterscheiden sich durch verschiedene Werte der Prozessparameter. P(a[max]) := [a>1] -> (send,lambda); P(a+1) [a=3] -> (reset,gamma); P(0) + (b, 2);(c, 0.5); stop Der Prozess P besitzt einen Parameter a, der im Bereich von 0 bis max definiert ist. Für die erste Transition im Beispiel wurde ein Wächter für die Prozessvariable a mit a>1 definiert. Dies bedeutet, dass dieser Zustandsübergang nur unter dieser Bedingung stattfinden kann. Mit der Aktion send und der Rate lambda wechselt der Prozess P in den Zustand P(a+1). Falls a den Wert 3 besitzt, kann der Prozess entweder mit reset und der Rate gamma nach P(0) übergehen oder (spezifiziert durch + ) mit der Aktion b gefolgt von c beendet werden ( stop ). Der letzte Teil der Eingabesprache ist die Spezifizierung der Leistungsmaße. Von diesen gibt es drei Arten: Zustandsmaß, Mittelwertmaß, Durchsatz. statemeasure pstate P (a=1) meanvalue mean P (a) throughputmeasure tm send Die erste Anweisung definiert ein Zustandsmaß mit dem Bezeichner pstate, welches die Wahrscheinlichkeit angibt, mit der die Prozessvariable a im Prozess P den Wert 1 besitzt. Die zweite Anweisung bezeichnet ein Mittelwertmaß, welches den Erwartungswert der Prozessvariable a in P angibt. Der Durchsatz mit dem Bezeichner tm gibt die Summe der Wahrscheinlichkeiten für die Zustände, aus denen die Aktion send ausgeführt werden kann, multipliziert mit der jeweiligen Rate, an. Zur genaueren Erläuterung der einzelnen Elemente wird auf die Arbeit [3] verwiesen.

14 6 KAPITEL 2. GRUNDLAGEN 2.2 Modellgetriebene Softwareentwicklung Bei modellgetriebener Entwicklung werden nach [4], [5] Modelle für das Design, die Konstruktion, die Entwicklung, das Verständnis, den Einsatz, die Wartung und die Veränderung eines Systems genutzt. Ein Modell ist eine Beschreibung oder Spezifikation eines Systems und seiner Umgebung für einen bestimmten Zweck. Es ist oft eine Kombination aus graphischer und textueller Darstellung, wobei die textuelle Darstellung in natürlicher als auch einer Modellierungssprache formuliert werden kann. Der modellgetriebenen Softwareentwicklung, aus dem Englischen Model Driven Software Development (MDSD), liegt die Model Driven Architecture (MDA) zu Grunde. Dieser Standard wurde von der Object Management Group (kurz: OMG) ins Leben gerufen. Die Architektur eines Systems ist dessen Spezifikation der Komponenten und deren Verknüpfung sowie die Regeln für das Zusammenwirken der einzelnen Komponenten unter Nutzung der Verknüpfungen. Die MDA gibt bestimmte Arten von nutzbaren Modellen, wie sie vorbereitet werden können, und die Beziehungen zwischen den verschiedenen Modellen, vor. Sie definiert drei verschiedene Betrachtungsweisen auf ein System: eine berechnungsunabhängige eine plattformunabhängige und eine plattformspezifische Sicht. Bei der berechnungsunabhängigen Sicht werden nur die Ausstattung sowie die Anforderung an das System betrachtet, die Struktur und die Umsetzung des System aber vernachlässigt. Die plattformunabhängige Sicht fokusiert den Einsatz des Systems ohne Betrachtung der Details einer bestimmten Plattform. Eine Plattform ist eine Menge von Teilsystemen und Technologien, die eine zusammenhängende Menge von Funktionalitäten mit Hilfe von Schnittstellen und Gebrauchsmustern zur Verfügung stellt. Jede Anwendung, die durch die Plattform unterstützt wird, kann die verfügbaren Funktionalitäten nutzen, ohne sich um deren interne Umsetzung zu kümmern. Die plattformspezifische Betrachtungsweise kombiniert die plattformunabhängige Sicht mit den Details bei der Nutzung des Systems auf einer spezifischen Plattform. Jede dieser drei Sichten wird durch ein Modell repräsentiert 2. Die Umwandlung eines Modells in ein anderes Modell des Systems wird als Modelltransformation bezeichnet. Dazu werden Abbildungen (engl. Mappings) verwendet. Das Metamodell Mapping stellt hierbei einen Spezialfall dar, bei dem nach [6] je ein Metamodell 3 für Quellund Zielmodell zur Transformation genutzt wird. Quell- und Zielmodell sind dabei jeweils eine Instanz des dazugehörigen Metamodells. Das Mapping definiert die Relation zwischen den beiden Metamodellen. Dadurch ergeben sich Regeln für die Abbildung einer Modellinstanz a des Metamodells A in eine Modellinstanz b konform zum Metamodell B. Ein Mapping kann 2 im engl. computation independent model (CIM), platform independent model (PIM), platform specific model (PSM) 3 Ein Metamodell ist ein Modell, welches eine abstrakte, strukturelle Form für seine Modellinstanzen definiert. Es definiert die enthaltenen Modellelemente, deren Ordnung, Beziehungen und Beschränkungen.

15 2.3. ECLIPSE MODELING FRAMEWORK 7 auch Templates 4 enthalten, die parametrisierte Modelle sind und bestimmte Teile der Umwandlung spezifizieren. Sie können genutzt werden, um bestimmte Muster von Modellelementen in andere Muster umzuwandeln. Zur Erkennung der Parameter des Templates oder für Werte, die erhalten oder umgewandelt werden sollen, nutzt man sogenannte Marken. Bei der Umwandlung eines Modells kann durch Generatoren auch direkt fehlerfreier Quellcode erzeugt werden, was zu einer extremen Steigerung der Entwicklungsgeschwindigkeit führt. Die Qualität des erzeugten Codes ist gleichbleibend, sodass eine Wiederverwendung ermöglicht wird. OMG hat aus dem Ansatz von MDA mehrere Technologien hervorgebracht, wie zum Beispiel UML 5 und MOF 6. Ein weiteres Ziel der modellgetriebenen Entwicklung ist die durch die Abstraktion gewonnene bessere Handhabbarkeit von komplexen Sachverhalten. Durch die verschiedenen Sichten von MDA kommt es zu einer klaren Trennung von fachlichen und technischen Anteilen und somit einer besseren Wartbarkeit der verschiedenen Komponenten. Die Modelle stellen neben der abstrakten auch eine technologie- oder auch plattformunabhängige Beschreibung der Software dar. Durch Standardisierung wird eine verbesserte Interoperabilität erreicht. MDA fordert vom Entwickler eine sorgfältige Konzeption des Gesamtsystems mit teilweise recht hohem Abstraktionsgrad bereits in der Entwurfsphase, um daraus später ein komplexes Programm zu gewinnen. Ein weiterer Vorteil ist, dass Änderungen am Modell durch die Generierung direkt in den Quellcode eingehen. Damit bleiben Quellcode und Modell konsistent. Diese Vorgehensweise wird als iterativ-inkrementelles Vorgehensmodell bezeichnet, da das Modell in jeder Phase des Entwicklungsprozesses stets verfeinert wird. Der vorgestellte Ansatz modellgetriebener Softwareentwicklung wird in den im Folgenden vorgestellten Frameworks angewendet. Hierbei handelt es sich um Werkzeuge, die durch Modelltransformation und graphische Diagrammeditoren die modellbasierte Entwicklung ermöglichen. 2.3 Eclipse Modeling Framework Dieser Abschnitt erläutert die Grundlagen des Eclipse Modeling Frameworks (kurz: EMF), die zu großen Teilen aus [7], [8] entnommen wurden. EMF ist ein Teil aus dem Eclipse Modeling Project und wurde erschaffen, um das Design und die Implementierung eines strukturierten Modells zu erleichtern. Dieses Framework basiert auf der Programmiersprache Java und bietet die Möglichkeit zur Codegenerierung, um den Schwerpunkt auf das Modell zu legen und nicht auf dessen programmiertechnische Details. Das Framework stützt sich auf die Grundkonzepte der Metadaten, Code-Generierung und Serialisierung 7. EMF wurde als eine Umsetzung von 4 dt. Vorlagen, Schablonen 5 Unified Modeling Language ist eine standardisierte Modellierungssprache um Softwaresysteme zu visualisieren, spezifizieren und dokumentieren. Mit UML2 ist es möglich, das komplette Verhalten eines Objekts zu spezifizieren. 6 Meta Object Facility ist gemäßt [5] eine Modellierungssprache, deren Anwendung in der Definition von Metamodellen besteht. Zur weitergehenden Erläuterung wird auf [5, Kapitel 5] verwiesen. Darin werden die Grundkonzepte objektorientierter Modellierungssprachen wie Klassen, Attribute, Vererbung, Assoziation und Pakete recht gut vermittelt. 7 Serialisierung bedeutet das Umwandeln eines Objekts in einen sequentiellen Datenstrom zur Speicherung.

16 8 KAPITEL 2. GRUNDLAGEN MOF begonnen, welches im vorherigen Abschnitt bereits erwähnt wurde, und stellt nun eine Erweiterung von MOF 2.0 dar. Es ist ein Open-Source-Projekt, welches das Ecore-Modell (siehe Abschnitt 2.3) von MOF 2.0 erweitert und umstrukturiert hat, sodass es für den Benutzer leichter zu handhaben ist. Als ein Teil der MDA ist es in der Eclipse-Familie in seiner Umsetzung ein Werkzeug der MDA Werkzeuge. Das Modell selbst wird in einem Metamodell beschrieben und mit Hilfe von Mappings dazu genutzt, um Softwareobjekte zu generieren, welche das reale System bilden. Es gibt zwei Arten von Mappings: das Metadata Interchange, bei dem Dokumente wie XML 8, DTD 9 und XSD 10 erzeugt werden und die Metadata Interfaces, die Java-Code oder auch andere Sprachen und IDL Code 11 generieren. EMF kann demnach genutzt werden, um ein Modell zu beschreiben und zu erschaffen. Auf Grundlage dieser Definition kann Java Code erzeugt und durch Beifügung von eigenem Code erweitert werden. Das implementierte Modell kann als eine Basis für die Entwicklung jeglicher Java-Anwendungen genutzt werden. Es gibt drei Arten ein Modell in EMF zu erstellen: 1. Direktes Schreiben als XMI 12 -Dokument 2. Laden eines exportierten XMI-Dokumentes aus Tools, wie Rational Rose und Omondos EclipseUML Plug-In 3. Annotierte Java Interfaces 13 mit Modelleigenschaften Gemäß [7] vereinigt EMF somit die drei Technologien Java, XML und UML und ist in der Lage, sie jeweils in die anderen Repräsentationen zu transformieren. Daher ist es gleich, mit welcher Technologie der Benutzer das Modell definiert. Das Ecore Metamodell Im vorherigen Abschnitt wurde der Begriff eines Metamodells bereits erläutert. Das Metamodell, welches die EMF Modelle beschreibt, heißt Ecore (Kern). Darin gibt es vier Modellele- 8 Extensible Markup Language ist eine Metasprache und dient zur hierarchisch strukturierten Darstellung von Daten in Form von Textdokumenten. Mit XML ist es möglich, beliebige Dokumententypen zu definieren. [5, Kapitel 6] 9 Document Type Definition dient in XML zur Trennung von Struktur und Inhalt eines bestimmten Dokumententyps. [5, Kapitel 6] 10 XML Scheme Definition dient zur Strukturbeschreibung von XML-Dokumenten und kann zur strukturellen Validierung von Daten herangezogen werden. [9] 11 Interface Definition Language (dt. Schnittstellendefinierungssprache) dient zur Spezifikation einer Schnittstelle zwischen verschiedenen Programmiersprachen. [9] 12 XML Metadata Interchange ist ein OMG-Standard zum Austausch von Metadaten eines Metamodells mit XML. Es schafft eine Möglichkeit Modellobjekte in XML-Dokumenten zu spezifizieren und wird laut [7] als Format zur Serialisierung von EMF Modellen verwendet. Weiterführende Erläuterungen zu XMI sind in [5, Kapitel 7] zu finden. 13 Ein Interface (Schnittstelle) nach [9] enthält im Gegensatz zu einer Klasse nur abstrakte Methoden, Konstanten und keine Variablen. Eine Klasse kann mit Hilfe des Schlüsselwortes implements die Methoden der Schnittstelle implementieren. Durch das Schnittstellen-Konzept in Java ist Mehrfachvererbung möglich.

17 2.3. ECLIPSE MODELING FRAMEWORK 9 mente (Klassen), welche benutzt werden können, um ein Modell zu beschreiben: EClass bezeichnet eine modellierte Klasse (Objekt), besitzt einen Namen, kein oder mehrere Attribute und kein oder mehrere Referenzen auf andere Klassen EAttribute repräsentiert ein modelliertes Attribut (Eigenschaft) und besitzt einen Namen und einen Datentyp EReference steht für ein Ende einer Assoziation (Beziehung) zwischen Klassen, besitzt einen Namen, ein boolesches Flag für Containment 14 und ein Zieldatentyp, der die Klasse am anderen Ende bezeichnet EDataType stellt den Datentyp eines Attributes dar, der sowohl Primitiv- 15 als auch Objektdatentyp sein kann Die vier genannten Modellelemente besitzen die selbe Bedeutung wie in der UML, da Ecore ein kleiner und vereinfachter Teil von ihr ist. Die UML ist um einiges mächtiger, da sie beispielsweise in der Lage ist, das Verhalten von Anwendungen zu spezifizieren. Man kann nun Instanzen dieser definierten Ecore-Klassen benutzen, um die Klassenstruktur des Modells der Anwendung zu beschreiben. Das entstandene Modell wird als Core Model (Kernmodell) bezeichnet. Die erste Möglichkeit Ecore zu bearbeiten, wird als Direct Ecore Editing bezeichnet. Dabei ist man in der Lage mit EMF s Ecore Editor graphisch, baumartig die Klassen und ihre Abhängigkeiten zu definieren. Mit Omondo s EclipseUML Graphical Editor kann in gewohnter Weise ein UML-Klassendiagramm graphisch definiert werden, welches das Modell repräsentiert. Das entstandene Modell wird als XMI-Dokument gespeichert. Man kann aber auch durch die Java Interfaces mit Annotationen (Kommentare, Anmerkungen) sein Modell definieren. Dabei werden Java Interfaces mit im Kommentar der Javadoc definiert. Ein Beispiel für ein annotiertes Java-Interface zeigt das Listing 2.1 aus [7]. Hier wird eine Bestellung (PurchaseOrder) modelliert. Sie besitzt das Attribut der Versandadresse shipto, welche mit getshipto() gelesen werden kann. Der Datentyp des Attributs ist durch den Rückgabetyp von getshipto() als String definiert. Es werden daher keine weiteren Modellinformationen für das Attribut benötigt. Des Weiteren besitzt Bestellung eine einfache Referenz (mit Containment) auf die einzelnen Bestellpositionen, das heißt, die Items können nur durch diese Bestellung, die Container der Items ist, existieren. Die Multiplizität von Items wird durch den Rückgabetyp List automatisch als 0 bis * (many) definiert. Somit ist es notwendig, den Datentyp Item für die Elemente der Liste anzugeben. Es ist nicht nötig, die Methode setshipto() zu definieren. Da durch die get-methode shipto 14 Containment (dt. Enthaltensein) ist die Bezeichnung für den Beziehungstyp der Komposition ( besteht aus ). Klasse A bildet den Container für das Objekt der Klasse B, welches ohne Klasse A nicht existieren kann. Beispiel: Ein Buch besteht aus mehreren Seiten. Eine Seite gehört immer zu einem Buch. Die Beziehung Buch - Seite hätte somit das containment-flag true. 15 Primitiv- oder auch Grunddatentypen werden einfache Datentypen bezeichnet, welche in allen gängigen Programmiersprachen vorkommen. Dazu gehören Integer, Boolean, Char, String, Float uvm.

18 10 KAPITEL 2. GRUNDLAGEN 1 /** 2 3 */ 4 public interface PurchaseOrder 5 { 6 /* 7 8 */ 9 String getshipto(); /* 12 type="item" containment="true" 13 */ 14 List getitems(); 15 } Listing 2.1: Annotiertes Java Interface für Bestellung als Attribut identifiziert wurde, wird sie automatisch erzeugt. Anhand dieses Interfaces kann EMF ein Modell für Bestellung generieren. Man müsste nun noch das Objekt Item definieren, um das vollständige Kernmodell der Bestellung zu erhalten. Die generierten Modellklassen Nachdem ein Modell angelegt wurde, kann man daraus Java Code erzeugen lassen. Doch wie sieht dies in der Umsetzung genau aus? Es werden immer zwei korrespondierende Dinge in Java pro Objekt erzeugt: ein Interface und eine Klasse. Das Interface definiert Methoden für den Zugriff auf die jeweiligen Modellelemente und die Klasse implementiert diese Schnittstelle. Um ein Beispiel dafür zu zeigen, greifen wir jenes von oben noch einmal auf. Wie man in Listing 2.2 sieht, werden die beiden Methoden 1 public interface PurchaseOrder extends EObject{ 2 3 String getshipto(); 4 5 void setshipto(string newshipto); 6 7 } Listing 2.2: generiertes Interface für Bestellung für die Versandadresse erzeugt. Jedes erzeugte Interface erweitert direkt oder indirekt das Interface EObject. Dieses stellt die Basis aller erzeugten Modellobjekte dar 16. Damit werden jedem Objekt verschiedene Funktionalitäten gegeben, die ererbt werden: eclass liefert das Metaobjekt des Objekts als EClass zurück 16 EObject ist vergleichbar mit java.lang.object, was die Basisklasse aller erzeugbaren Objekte in Java darstellt.

19 2.3. ECLIPSE MODELING FRAMEWORK 11 1 public class PurchaseOrderImpl extends EObjectImpl implements PurchaseOrder{ 2 3 private String shipto; 4 5 public String getshipto() { 6 return shipto; 7 } 8 9 public void setshipto(string newshipto){ 10 String oldshipto = shipto; 11 shipto = newshipto; 12 if (enotificationrequired()) 13 enotify(new ENotificationImpl(this,Notification.SET, 14 POPackage.PURCHASE_ORDER SHIP_TO, 15 oldshipto,shipto)); 16 } 17 } Listing 2.3: generierte Implementationsklasse für Bestellung econtainer() gibt den Container 17 und eresource() die Ressource 18 des Objekts zurück eget(), eset(), eisset() und eunset() stellen den Zugriff auf die Instanzvariablen des Objekts zur Verfügung Das Interface EObject erbt selbst von Notifier und führt somit weitere Funktionalitäten für jedes Modellobjekt ein. Auf jegliche Änderungen am Modell erfolgt eine Benachrichtung, die sogenannte model change notification. Damit läßt sich die Methode setshipto() aus Listing 2.3 erklären. Sobald die Variable shipto geändert wird und eine Benachrichtigung erforderlich ist (enotificationrequired()), wird eine Benachrichtigung mit dem alten Wert oldshipto und dem neuen Wert shipto an das Package gesendet. Doch was ist das Package? Es werden für jedes Modell zwei weitere wichtige Klassen erzeugt: die sogenannte Factory 19 und das eben erwähnte Package (Paket). Factory enthält sämtliche Methoden zur Erzeugung (create) der Klassen des Modells. Ein Beispiel zur Anwendung dieser Factory zeigt das Listing 2.4, in dem eine neue Bestellung durch Factory erzeugt wird. Das ge- 1 PurchaseOrder order = POFactory.eINSTANCE.createPurchaseOrder(); Listing 2.4: Verwendung der generierten Factory nerierte Package bietet einen brauchbaren Zugriff auf alle Ecore Metadaten des Modells. Siehe dazu im Listing 2.3 Zeile 14 den Zugriff auf die Variable shipto mit Hilfe des POPackage. Das Package ermöglicht den Zugriff auf alle Modellklassen, Attribute und Referenzen. Zusätzlich zu den eben erwähnten Interfaces und Klassen wird optional noch das Folgende erzeugt: 17 Ein Container bezeichnet ein Objekt, welches ein anderes Objekt (Bestandteil) enthält. 18 Als Ressource wird hier die Datei bezeichnet, in welcher das Objekt physikalisch abgelegt ist. 19 Die Generierung einer Factory entspringt dem Entwurfsmuster der Fabrikmethode. Sie wird in der Softwareentwicklung als Erzeugungsmuster verwendet. [10]

20 12 KAPITEL 2. GRUNDLAGEN Ein Grundgerüst der Adapter Factory Klasse für das Modell. Diese Basisklasse kann genutzt werden, um objektspezifische Adapter zu erzeugen. Als Adapter werden in EMF die Listener (Empfänger) für die Benachrichtigungen bei Veränderung der Modellobjekte genannt. Beispielsweise dient der ItemAdapter als Listener von Benachrichtigungen der Bestellpositionen einer Bestellung. Eine Plug-In-Manifest-Datei, die benötigt wird, um das Modell als Eclipse Erweiterung zu nutzen. Ein XML-Schema für das Modell. Der erzeugte Quellcode wird durch EMF einfach und effizient gehalten, da nur notwendiger und modularisierter (auf Pakete und Klassen verteilter) Code generiert wird. Dieser ist korrekt und unterscheidet sich nicht von Code, der per Hand erzeugt worden ist. Wie bereits erwähnt, kann generierter Code erweitert werden. Der EMF Code-Generator kann Dateien, die eine Kombination aus generiertem und handgeschriebenem Code sind, erzeugen. Wenn man Methoden und Instanzvariablen zum Code hinzugefügt hat, kann jederzeit aus dem Modell der Code erneuert werden, ohne dass die eigenen Änderungen verloren gehen. Dazu nutzt der Generator wiederum den Javadoc Kommentar und setzt dort die um generierte Interfaces, Klassen und Methoden als generierte Teile zu identifizieren. Jede Methode, die diese Markierung nicht besitzt, zum Beispiel eine eigen implementierte Methode, wird durch den Generator nicht verändert. Folgendes Beispiel zeigt die Verwendung der Markierung durch den Generator. Möchte man eine generierte Methode ab- 1 /** 2 3 */ 4 public String getshipto(){ 5 return shipto; 6 } Listing 2.5: Eine generierte Methode ändern, aber deren Funktionalität weiterhin mit dem Modell konsistent halten, so muss Gen an den Methodenname angefügt werden. Weiterhin implementiert man seine eigene Methode mit dem originalen Name im Kommentar) und sorgt für den Aufruf der neuen Methode mit dem Suffix Gen. Der Generator sucht nun die alte Methode und findet stattdessen die mit dem Suffix und ändert diese entsprechend dem Modell. Das Generatormodell Die meisten Daten, die der EMF Generator benötigt, sind im Core Model abgelegt. Das sind alle Klassen mit ihren Namen, Attributen und Referenzen, welche generiert werden müssen. Aber es gibt durchaus noch mehr Informationen, die vom Generator benötigt aber nicht darin gespeichert werden (z.b. wo der generierte Code abgelegt werden soll oder welches Präfix die

21 2.3. ECLIPSE MODELING FRAMEWORK 13 erzeugten Klassen besitzen sollen). Diese benutzerdefinierten Daten müssen für zukünftige Erzeugungen gespeichert werden. Der Generator nutzt hierzu ein sogenanntes Generatormodell, welches genau wie Ecore auch ein EMF Modell ist. Das Generatormodell stellt all diese Daten inklusive einem verpackten Kernmodell zur Verfügung. Es besitzt Generatormodellklassen, die als decorators für die Ecore-Klassen bezeichnet werden. Beispielsweise steht GenClass für EClass und GenFeature für EAttribute und EReference. Der Generator nutzt das Generatormodell, welches indirekten Zugriff auf das Kernmodell besitzt, für die Erzeugung. Daraus resultieren zwei Modellressourcen in einem Projekt: die ecore Datei, die eine XMI Serialisierung des Kernmodells ist und eine genmodel Datei, die ein serialisiertes Generatormodell mit Verweisen auf.ecore darstellt. Damit bleibt das Kernmodell frei von Informationen, die nur zur Generierung benötigt werden. Dadurch kann es aber passieren, dass das Generatormodell nicht synchron mit dem Kernmodell ist. Durch interne Methoden des Generators wird dies verhindert, da bei Bedarf beide Modelle synchronisiert werden können, was das Framework auch automatisch erledigt. Bearbeiten des Modells mit EMF.Edit Zum EMF Framework zählt auch EMF.Edit. Dies ermöglicht die Erstellung eines Editors für das zugrunde liegende Modell. Mit diesem baumartigen Editor können Instanzen des Modells angezeigt und bearbeitet werden. Diese Baumansicht zeigt hierarchisch alle Modellelemente mit deren Name (Methode gettext()) und einem zugewiesenen Bild (getimage()) an. Beginnend vom Wurzelelement werden mit getchildren() die jeweiligen Kindelemente abgerufen. Außer dieser Baumansicht gibt es noch die Tabellen- und Listenansicht, die in gleicher Weise arbeiten. Der Editor verfügt über ein sogenanntes Property Sheet, mit dem die Attribute der einzelnen Modellelemente bearbeitet werden können. Für jedes Element gibt es die Methode getpropertysource(), die vom jeweiligen IPropertySourceProvider bereitgestellt wird. Durch getpropertydescriptors() erhält das Property Sheet eine Liste mit den Attributen des ausgewählten Objekts. Über diese PropertyDescriptors ist das Anzeigen und Bearbeiten der Eigenschaften möglich. Die genannten Methoden werden durch Item Provider der Modellelemente bereitgestellt. Deren Implementation leistet unter den genannten Aufgaben noch die Behandlung von Änderungen am Modell (model change notification), welche an die graphische Oberfläche des Editors weitergeleitet werden. Diese Funktionalitäten wurden in der Basisklasse ItemProviderAdapter von EMF.Edit bereits implementiert und können dementsprechend auch einfach abgeleitet werden. Neben der Generierung von Quellcode der Programmiersprache Java kann man auch einen einfachen Editor aus dem Generatormodell erzeugen. Dieser Editor ist eine lauffähige Erweiterung der Eclipse Laufzeitumgebung und kann von dort aus gestartet und betrieben werden. Zusammenfassend stellt das Framework Möglichkeiten zur Benachrichtigung, Serialisierung und den Zugriff auf Metadaten des Modells zur Verfügung. Damit ist die Grundlage geschaffen mit anderen EMF-basierten Werkzeugen zusammen zu arbeiten (Interoperabilität).

22 14 KAPITEL 2. GRUNDLAGEN 2.4 Graphical Editing Framework Ein Framework, welches auf EMF basiert, ist das Graphical Editing Framework (kurz: GEF). Grundlagen dieses Frameworks werden in diesem Abschnitt erläutert und stammen zu großen Teilen aus [8]. GEF stammt aus dem Tools Project von Eclipse. Mit ihm ist es möglich, für ein existierendes Modell einen graphischen Editor zu entwerfen. Hierzu nutzt es das vorhandene Draw2D Framework, welches einen Werkzeugsatz für das Layout und die Darstellung von graphischen Objekten (Figures) zur Verfügung stellt. Eine kurze Einführung in dieses bietet der folgende Abschnitt. GEF verfährt hierbei nach der Model-View-Controller Architektur (MVC) 20, die es möglich macht, Veränderung am Modell in die graphische Repräsentation zu übertragen. Die genaue Umsetzung dieser Architektur erfolgt nach Einführung der Grundkonzepte von GEF später in diesem Kapitel. Diese Veränderungen können in einem graphischen Editor auf übliche Art und Weise per Drag&Drop, Copy&Paste und Menü- sowie Werkzeugleistenaktionen durchgeführt werden. GEF ist anwendungsneutral und bietet ein Fundament, um fast jede Art von Anwendung zu erschaffen, beispielsweise für Aktivitätsdiagramme, Klassendiagrammeditoren und Zustandsautomaten. Einführung in Draw2D Draw2D ist ein leichtgewichtiges Grafiksystem, welches von GEF für die Darstellung benötigt wird. Es ist eingebettet in SWT 21, welches das Zeichnen und auftretende Mausereignisse kontrolliert und an die jeweiligen Figures (Abbildungen) von Draw2D delegiert. Diese Figures sind analog zu Fenstern in bekannten graphischen Benutzeroberflächen. Sie können aus willkürlichen, nichtrechteckigen Formen bestehen, ineinander verschachtelt und zusammengesetzt werden. Weiterhin kann man ihre Transparenzwerte und Einordnung in verschiedene Ebenen, was das Verstecken oder Ausschließen von bestimmten Operationen in einem Diagramm ermöglicht, festlegen. Draw2D ist eine eigenständige Bibliothek (kann unabhängig von GEF oder Eclipse genutzt werden), welche den Benutzer befähigt, graphische Sichten in Eclipse zu erschaffen. Im Folgenden werden einige Schlüsselkonzepte von Draw2D aufgezeigt. Graphische Elemente von Draw2D Jedes Element in einem Draw2D Fenster ist eine Figur, deren Klasse (Figure) eine Vielzahl von Methoden bereitstellt, um die folgenden Funktionalitäten zu realisieren. An- und Abmelden eines Listeners, der benachrichtigt wird, falls ein Ereignis (event) innerhalb einer Figure auftritt 20 MVC ist ein dreischichtiges Modell mit einer strikten Trennung dieser Schichten, die verschiedene Aufgaben haben. So befinden sich die Daten in der Modell- und deren Visualisierung in der Viewschicht. Die Controllerschicht übernimmt die Kommunikation zwischen beiden Schichten. 21 Standard Widget Toolkit ist eine Bibliothek zur Erstellung graphischer Benutzeroberflächen mit Java unter Nutzung der graphischen Elemente des Betriebssystems.

23 2.4. GRAPHICAL EDITING FRAMEWORK 15 Strukturelle Ereignisse für das Verschieben oder Verändern der Größe Operationen zum Hinzufügen und Entfernen von Kindobjekten sowie Zugriff auf diese und ihre Elternobjekte Zugriff auf Position, Größe und Layout einer Figure Setzen und Holen des Fokusses Festlegung von Transparenz und Sichtbarkeit Zeichnen, Validierung und weitere Es werden eine Vielzahl von Unterklassen von Figure durch Draw2D zur Verfügung gestellt, die nützliche Funktionen besitzen. Dazu gehört die Klasse Shape (Form), deren Unterklassen nichtrechteckige Objekte enthalten, die sich selbst füllen und einen Rahmen mit konfigurierbarer Breite und Linienart bieten. Als Vertreter sind Ellipsen, Hilfskonturen, Polygone, Rechtecke, abgerundete Rechtecke und Dreiecke zu nennen. Eine weitere Klasse stellen die Widgets (Grafikobjekte) dar, die für Eingaben des Benutzers innerhalb der Draw2D Anwendung verwendbar sind. Dazu zählen verschiedene Buttons (Schaltflächen), Checkboxes (Kontrollkästchen) und Labels (Textfelder). Die Layers (Ebenen) und Panes (Fenster) bieten Klassen mit denen es ermöglicht wird, dass graphische Elemente Kindobjekte aufnehmen können. Sie können skaliert, ihr Inhalt gescrollt werden und besitzen die Fähigkeit, ihre Elemente in verschiedenen Ebenen zu platzieren. Jedes graphische Element besitzt eine Methode paint(), die vom Grafiksystem aufgerufen wird, falls das Element neu gezeichnet werden muss. Die Methode bekommt als Parameter einen graphischen Kontext übergeben. Dieser ist eine Instanz der Grafikklasse und unterstützt die graphischen Operationen, wie das Zeichnen und Füllen der Formen und das Darstellen von Texten. Er hält aber auch den graphischen Zustand des Systems aufrecht, der diese Operationen beeinflusst, wie die aktuelle Schrift, Vorder-, Hintergrundfarbe und vieles mehr. Die Architektur von Draw2D Die Architektur, die hinter Draw2D steckt, wird als leichtgewichtiges System bezeichnet. Sie beinhaltet eine Root Figure (Hauptelement), das das oberste Element in der graphischen Anwendung repräsentiert. Es erbt die graphische Umgebung des SWT, wie Schriftart, Vorderund Hintergrundfarbe. Der sogenannte Event Dispatcher (Abfertiger von Ereignissen) übersetzt die SWT Ereignisse in korrespondierende Draw2D Ereignisse der Root Figure. Er übermittelt, welches graphische Element den Fokus besitzt oder von der Maus angeklickt wurde. Der Update Manager ist für das Zeichnen und Aktualisieren der graphischen Objekte zuständig. Das System nutzt dessen Methode update() und diese erstellt eine Liste mit den neu zu zeichnenden Objekten. Das Aktualisieren geschieht asynchron durch die Verwendung eines eigenen Threads 22. Es stehen zum Neuzeichnen des Objekts verschiedene Methoden zur 22 Ein Thread ist ein leichtgewichtiger Prozess, der den selben Speicherbereich besitzt, wie sein Vaterprozess, aber parallel zu diesem ausgeführt werden kann.

24 16 KAPITEL 2. GRUNDLAGEN Verfügung. So sorgt paintfigure() für das Neuzeichnen des gesamten Objekts, hingegen paintclientarea() nur für den Bereich der Kindobjekte und paintborder() für den Rahmen. Validierung wird genutzt, falls die Größe oder die Position neu berechnet werden muss. So werden durch validate() die Kindobjekte gemäß den Vorgaben des Layoutmanager neu ausgerichtet. Weitere Funktionen von Draw2D Draw2D stellt außerdem verschiedene Typen von Borders (Ränder), Layouts und Layers für seine Objekte bereit. Durch die Verwendung von Locators (Fixierungen) ist es möglich, Objekte an bestimmte Positionen anderer Objekte zu heften. Dies wird beispielsweise für Pfeilspitzen von Connections (Verbindungen) genutzt. So bleibt auch nach Verschiebung des eines Objekts das andere daran fixiert. Die Verwendung von Connection Anchors (Verbindungsanker) erlaubt es, Connections an Objekten zu verankern. Dabei gibt es verschiedene Arten dieser Aufhängpunkte für die unterschiedlichen Objekte wie Rechtecke, Ellipsen oder Labels. Ein Connection Router (Verbindungsrouter) wird genutzt, um den Weg der Connection zwischen zwei Aufhängpunkten auf verschiedene Arten zu bestimmen. Beispiele für verschiedene Connection Router sind in Abbildung 2.1 zu sehen. Ein NullConnectionRouter nutzt die direkte Verbindung zwischen Abbildung 2.1: NullConnectionRouter, Bendpoint - und Manhattan Router (nach [8]) zwei Punkten. Beim BendpointConnectionRouter kann der Benutzer Zwischenpunkte in die Connection einfügen. Der ManhattanConnectionRouter verwendet ausschließlich horizontale und vertikale Liniensegmente, um die Connection zwischen zwei gegebenen Aufhängpunkten zu erzeugen. In Draw2D werden diese Connections als PolylineConnections bezeichnet, die über Decorations der Start- und Endpunkte (z.b. Pfeilspitzen) aber auch Router für den Verbindungsweg verfügen. Einführung in GEF Nach der Beschreibung von Draw2D folgt die Einführung des Graphical Editing Frameworks. Dazu werden als erstes die EditParts und im weiteren Verlauf die EditPolicies von GEF erläutert. Die Betrachtung von GEF wird durch die Umsetzung der MVC-Architektur abgeschlossen.

25 2.4. GRAPHICAL EDITING FRAMEWORK 17 Die EditParts in GEF Die zentralen Elemente in GEF sind die sogenannten EditParts. Sie sind dafür zuständig, dass die Elemente des Modells als visuelle Objekte dargestellt werden und regeln deren Verhalten in verschiedenen Situationen. Demnach muss für jedes Element eine EditPart-Klasse erzeugt werden, sodass dieselbe Klassenstruktur für die EditParts, wie bereits für das Modell, vorliegt. Die zu erzeugenden EditParts werden von der abstrakten Basisklasse AbstractEditPart abgeleitet, welche das Interface org.eclipse.gef.editpart implementiert 23. Man unterscheidet die EditParts in GraphicalEditParts und ConnectionEditParts. GraphicalEditParts repräsentieren die Modellelemente als graphische Objekte und ConnectionEditParts die Verbindungen zwischen ihnen. Ein weiterer Typ sind die TreeEditParts, mit denen sich Bäume des Modells darstellen lassen, die hier aber nicht weiter betrachtet werden sollen. Das Interface EditPart stellt eine Vielzahl Methoden zur Verfügung, die alle von GEF genutzt werden, um die EditParts zu behandeln. Die beiden Methoden activate() und deactivate() werden vom Framework genutzt, um die jeweiligen EditParts zu aktivieren bzw. deaktivieren. Bei der Deaktivierung werden die belegten Ressourcen (wie Bilder oder Schriften) freigegeben. Zur Überprüfung des jeweiligen Zustands dient isactive(). Da die EditParts als EMF-Adapter dienen, besitzen sie eine Methode notifychanged, mit der sie über Änderungen am Modell informiert werden und diese weitergeben können. Jeder GraphicalEditPart besitzt eine Figure (vgl. Draw2D), der den visuellen Teil des Modells widerspiegelt. Er erzeugt (durch createfigure()), aktualisiert bei Modelländerungen (refreshvisuals()) und entfernt die Figure bei seiner Deaktivierung (dispose()). Der Zugriff auf die logischen Kindelemente des zum EditPart gehörigen Modellelements wird durch getmodelchildren() erreicht, die eine Liste der Kinder liefert. Ein ConnectionEditPart ist nichts anderes als ein GraphicalEditPart, der zusätzlich über einen Quell- und Ziel-EditPart verfügt. Da Connections über Aufhängpunkte mit den Objekten verbunden werden, müssen der Quell- bzw. Ziel-EditPart diese anbieten. Dies wird durch die Implementierung des NodeEditPart-Interfaces erreicht, welches einen Knoten repräsentiert. Anfragen an die EditParts Die Objekte, welche von GEF zur Kommunikation genutzt werden, bezeichnet man als Requests (Anfragen). Sie enthalten Information für die spätere Ausführung des Requests. Ein Request wird durch eine Aktion oder ein Werkzeug des Editors ausgelöst. Dieser wird an den zugehörigen EditPart weitergeleitet, der ihn aber nicht bearbeitet, sondern an eine EditPolicy (Richtlinien, siehe unten) weitergibt. Diese übersetzt den Request in ein Command (Befehl), welches dann ausgeführt werden kann. Es gibt drei Typen von Requests, die in GEF Anwendungen zum Einsatz kommen: 23 Durch die Ableitung der abstrakten Klasse und nicht die eigene Implementation des Interfaces schützt man sich vor unerwarteten Änderungen am Framework und schafft somit die Voraussetzung, mit zukünftigen Versionen kompatibel zu bleiben.

26 18 KAPITEL 2. GRUNDLAGEN CreateRequests, die die Erzeugung neuer Modellelemente auslösen. Für Connections gibt es einen CreateConnectionRequest. Ein CreateRequest besitzt eine CreationFactory, die für die Erzeugung der neuen Elemente zuständig ist. GroupRequests sind zum gleichzeitigen Ansprechen mehrerer EditParts vorgesehen. Typischer Anwendungsfall ist der ChangeBoundsRequest, der das Bewegen und Verändern der Größe von EditParts ermöglicht. LocationRequests zeichnen Positionen auf, um ein bestimmtes Verhalten anzuordnen. Mit dem SelectionRequest, der die Auswahl eines EditParts veranlasst, ist es beispielsweise möglich, die genaue Position zu bestimmen, die ausgewählt wurde. Die Richtlinien der EditParts Eine EditPolicy ist der Teil des Frameworks, der es ermöglicht, EditParts zu bearbeiten. In ihr wird definiert, was mit einem EditPart gemacht werden darf. Fehlt sie, kann dementsprechend nichts getan werden. Sie legt fest, was angezeigt werden soll, wenn der EditPart eine Änderung erfährt und delegiert diese notfalls auch an andere EditParts, beispielsweise Kindobjekte. Edit- Policies sind in verschiedene Roles (Zeichenkettenkonstanten als Bezeichner) eingeteilt, mit deren Hilfe sie für die EditParts installiert werden. Falls eine EditPolicy mit der selben Role bereits installiert ist, wird diese überschrieben, da es jeweils nur eine EditPolicy pro EditPart geben kann. Die Component Role ist definiert als Konstante EditPolicy.COMPONENT_ROLE und ihre Basisklasse heißt ComponentEditPolicy. Sie umfasst jegliche Operationen, die sich mit dem Modell und nicht mit der visuellen Repräsentation beschäftigen, beispielsweise dem Löschen des Modellelements. Die Connection Role mit der Basisklasse ConnectionEditPolicy ist zuständig für die ConnectionEditParts. Eine Container Role wird benötigt, wenn das Modellelement als Container für Kindobjekte dient, und stellt das Erzeugen von diesen im jeweiligen EditPart zur Verfügung (ContainerEditPolicy als Basisklasse). Ist einem EditPart ein bestimmtes Layout zugeordnet, so kommt die Layout Role zum Einsatz. Sie berechnet die Ausrichtung und Positionen des EditParts und seiner Kindobjekte. Die Graphical Node Role dient zum Errichten und Verwalten von Connections zwischen EditParts. Eine letzte hier erwähnte und wichtige Role ist die Direct Edit Role, mit deren Hilfe das direkte Bearbeiten von Eigenschaften eines EditParts durch den Benutzer mittels Doppelklick möglich gemacht wird (z.b. Veränderung des Namens eines Modellobjekts durch das Label). Die jeweiligen Commands können in den abgeleiteten EditPolicies behandelt werden, um beispielsweise deren Ausführung zu verhindern. Der GraphicalViewer und RootEditPart Um die EditParts anzuzeigen, wird ein sogenannter GraphicalViewer eingesetzt, der die verschiedenen EditParts verwaltet. Ihm wird zur Initialisierung ein RootEditPart und eine Edit- PartFactory übergeben. Danach kann der Inhalt mit setcontents gesetzt werden. Da GEF

27 2.4. GRAPHICAL EDITING FRAMEWORK 19 eine Standardimplementierung dafür vorsieht, wird auf ihn nicht weiter eingegangen. Der RootEditPart ist ein besonderer Typ von EditPart und hat keinen Bezug zum Modell. Er bietet eine Umgebung für die EditParts des Modells an und kann somit als Schnittstelle zwischen GraphicalViewer und Modell gesehen werden. Es gibt zwei erwähnenswerte Arten von RootEditParts: ScalableRootEditPart, der (wie der Name verrät) eine Möglichkeit für Skalierung (Zoom) des GraphicalViewers bietet. ScalableFreeformRootEditPart, der eine Erweiterung des eben Genannten darstellt. In ihm ist es möglich, das Diagramm in alle Richtungen auszuweiten (auch mit negativen Koordinaten). RootEditParts besitzen außerdem mehrere Layers, die verwendet werden, um Objekte von Edit- Parts zu gruppieren oder separieren. Standardmäßig sind alle Objekte dem Primary Layer zugeordnet. Connections gehören dem Connection Layer an, der immer über dem Primary Layer gezeichnet wird. Weitere Layers werden hier nicht betrachtet. Nachdem nun die Basisklassen und -konzepte von GEF vorgestellt worden sind, kann die Umsetzung der MVC-Architektur erläutert werden. Die EditParts stellen die Controller dar, da sie die Interaktion zwischen dem Modell (den generierten Klassen von EMF) und dem Graphical- Viewer regeln. Der GraphicalViewer repräsentiert die View Schicht der Architektur, da durch ihn die Modellelemente visualisiert werden. Abbildung 2.2: Die Umsetzung der MVC Architektur in GEF (übernommen aus [11]) Die Abbildung 2.2 zeigt noch einmal deutlich diese Umsetzung der MVC-Architektur in GEF. In [11] wird diese mit dem Beispiel des Löschens eines Modellelements verdeutlicht. Durch das Kommando delete wird als erstes das Element aus dem Modell entfernt, was eine Nachricht an den jeweiligen EditPart auslöst. Dieser fordert daraufhin ein Update in der graphischen Darstellung des Elements im Editor an. Man kann nun mit der Erstellung eines Editorgrundgerüstes beginnen. Damit beschäftigt sich das Kapitel 3 dieser Arbeit.

28 20 KAPITEL 2. GRUNDLAGEN 2.5 Graphical Modeling Framework Dieser Abschnitt beschreibt die Grundlagen des Graphical Modeling Framework (kurz: GMF), mit dessen Hilfe der Caspa Graphical Editor implementiert wurde. Es stammt genau wie EMF aus dem Eclipse Modeling Project und vereint in sich die beiden vorgestellten Frameworks EMF und GEF. Es besteht laut [12] im Wesentlichen aus zwei Basiskomponenten, der Runtime (Laufzeitumgebung) und der Generation (Codeerzeugung). Runtime Komponente Runtime verknüpft EMF und GEF, stellt die Ausführungsebene und bestimmte Möglichkeiten zur Diagrammdarstellung zur Verfügung und wurde geschaffen, um Erweiterungen zu ermöglichen. Es besitzt wiederverwendbare Komponenten für graphische Editoren. Dazu zählen Action Bars 24, Connection Handles 25, Compartments (Schubladen) 26 und die Shapes (graphische Objekte), wie sie in Abbildung 2.3 zu sehen sind. Außerhalb der Zeichenfläche werden Actions (Aktionen der Menüleiste), eine Toolbar (Werk- Abbildung 2.3: Beispiel Action Bar, Connection Handles und Compartment (aus [12]) zeugleiste) und ein Properties View (Eigenschaften-Ansicht) angeboten, die standardmäßig vom Framework befüllt aber auch nach Belieben vom Benutzer geändert werden können. Schließlich werden verschiedene Standarddialoge zur Seiteneinstellung, Druckvorschau, Export des Diagramms als Bilddatei und für Einstellungen der Zwischenablage angeboten. Runtime nutzt verschiedene andere Technologien wie Transaction 27, Validation 28 und OCL 29, die ebenfalls zum Eclipse Modeling Framework gehören. 24 Sie dienen dazu, im Editor bequem Unterelemente eines Objekts anzulegen, indem eine Leiste erscheint und man eine Auswahl trifft. 25 Objekte, die mit Connections verbunden werden können, erhalten eine Auswahl, um diese bequem anzulegen. 26 Stellt eine Art Schublade für ein Objekt dar, dessen Unterelemente in dieser abgelegt werden. 27 Transaktionen werden genutzt, um eine Menge von Aktionen zu kapseln und damit sicher zu stellen, dass alle Aktionen erfolgreich ausgeführt werden. 28 Validierung dient zur Überprüfung der Korrektheit eines Diagramms nach festgelegten Regeln. 29 Object Constraint Language ist ein weiterer Standard der OMG und dient zur textuellen Definition von Randbedingungen und Einschränkungen für Objekte (hier eines Modells). OCL basiert auf Prädikatenlogik erster Stufe und Mengentheorie.

29 2.5. GRAPHICAL MODELING FRAMEWORK 21 Generation Komponente Generation (auch als Tooling bezeichnet) hingegen nutzt verschiedene Modelle, um die graphischen, werkzeug- und abbildungsbezogenen Anteile des Editors zu definieren. Durch die Erzeugung von Code aus diesen miteinander kombinierten Modellen wird die Runtime Komponente gewonnen. Der modellgetriebene Ansatz, um graphische Editoren zu erzeugen, wird durch Trennung der Definition des Domänenmodells und der graphischen Definition erreicht. Einen Überblick über den Ablauf der Entwicklung eines graphischen Editors in GMF zeigt die Abbildung 2.4. Aus dem Domänenmodell, dem Ecore Modell (vgl. Abschnitt 2.3), wird ein Abbildung 2.4: Überblick zur Erzeugung eines Editors in GMF (übernommen aus [12]) neues Projekt erzeugt. Dieses durch EMF erzeugte Modell bildet die semantische Grundlage für den Editor. Es folgt die graphische Definition (.gmfgraph) des Editors. Mit diesem plattformunabhängigen Modell werden Figures, Nodes (Knoten) und deren Child Nodes (Kindknoten), Links und Compartments definiert. Es können die vordefinierten, graphischen Objekte aus Draw2D (vgl. 2.4) wie Rechtecke, Kreise, Labels und Connections aber auch eigene Objekte verwendet werden. Das Erscheinungsbild dieser Objekte kann durch die Linienart, -dicke, Vorder- und Hintergrundfarbe und vieles mehr verändert und angepasst werden. Die graphische Definition wird durch einen sogenannten Wizard 30 unterstützt. Somit kann aus dem Domänenmodell ein Grundstock an graphischen Informationen, z.b. über die Nodes, Child Nodes und Links, gewonnen und bereits umgesetzt werden. In der Tooling Definition (.gmftool) können alle Werkzeuge des Editors definiert werden. Dazu gehört das Anlegen einer Palette mit ihren Tools, durch die der Benutzer später die Elemente des Editors auswählen kann. Weiterhin können die Menüleiste, die Werkzeugleiste und deren Aktionen definiert werden. Auch hier unterstützt ein Wizard die Erzeugung von.gmftool auf Grundlage des Domänenmodells. 30 Ein Wizard (Assistent) dient zur Unterstützung, indem er alle benötigten Informationen durch Dialoge nacheinander abfragt und diese danach selbstständig verarbeitet.

30 22 KAPITEL 2. GRUNDLAGEN Die Mapping Definition (.gmfmap) dient der Verknüpfung des graphischen Modells, der Werkzeug-Definition und dem Domänenmodell. Die graphischen Modellelemente werden mit den Elementen der definierten Palette verbunden und den Instanzen der Elemente des Domänenmodells zugeordnet. Im Mapping kann auch die Validierung des Modells durch Constraints und die Vorbelegung von Instanzvariablen definiert werden. Ein Wizard unterstützt den Benutzer auf Grundlage des Domänen-, graphischen und werkzeugdefinierenden Modells. Anhand dieses Mappings kann nun das Diagramm-Generatormodell (.gmfgen) erzeugt werden, aus welchem wiederum der Editor als eine Eclipse Erweiterung oder RCP gewonnen werden kann. Die Code-Generierung erfolgt unter der Nutzung der Java Emitter Templates. Dieser erzeugte Code kann vom Benutzer abgewandelt und ergänzt werden. Im Diagramm- Generatormodell können viele Eigenschaften der Ausführung verändert werden, wie die Druck- Unterstützung, Speicherung und Validierung des Modells. Alle Komponenten aus EMF und GEF, wie die EditParts mit ihren EditPolicies und die ViewProvider, werden generiert. Neben dem semantischen Modell speichert GMF laut [13] in einem unabhängigen Notation Model (Modell für Darstellungsarten) die visuellen Informationen, die für das Zeichnen des Diagramms notwendig sind. Hier werden beispielsweise die Position und Größe der Knoten, Verankerungspunkte der Verbindungen, Farben und vieles mehr abgelegt. Es benutzt die Unterklassen Diagram, Node und Edge (Verbindungen) der abstrakten Klasse View, die deren spezifische Eigenschaften für die visuelle Repräsentation speichern. Das Modell kann mit benutzerdefinierten Daten durch bestimmte Styles die existierende Instanz des Views erweitern. Jeder Diagrammeditor besitzt eine eigene Instanz dieses Notation Models, welche von der Runtime für diagrammspezifischen Informationsaustausch genutzt wird. Um die Daten zu speichern wird der Speichermechanismus von EMF genutzt. Demnach wird es wiederum als XMI abgelegt. 2.6 Java Emitter Templates Die Java Emitter Templates (kurz: JET) sind ein Framework aus dem Model-to-Text Transformation (M2T) Projekt, welches zum Eclipse Modeling Framework gehört. Es bietet gemäß [14] die Möglichkeit zur Codegenerierung, wie sie auch von EMF genutzt wird. Der JET-Syntax ist eine Teilmenge von den Java Server Pages (kurz: JSP), welche genutzt werden, um dynamisch HTML- oder XML-Ausgaben durch einen Web-Server zu erzeugen. Die Templates dienen als Schablonen und können bearbeitet und danach auf einfache Weise jegliche Art von Code wie Java, HTML oder XML erzeugen. JET wird typischer Weise als Implementierung eines Codegenerators genutzt. Ein Codegenerator ist eine wichtige Komponente der modellgetriebenen Softwareentwicklung, da hierbei die Umwandlung von Modellen in Code als Ziel definiert ist. Obwohl die manuelle Umwandlung von abstrakten Modellen in Code möglich ist, wird die Automatisierung dieses Prozesses als die wahre Stärke von MDSD bezeichnet. Die Umwandlung basiert auf Templates, in denen genau festgelegt wird, welche Teile wie umgewandelt werden sollen. Dies wird durch die Anpassung des Benutzers erreicht. Nach [15] kann in Eclipse das Projekt in ein JET Projekt konvertiert werden 31. Dabei wird auto- 31 Dies geschieht unter Java Emitter Templates, die mittels File / New / Other erreicht werden können.

31 2.7. JAVA COMPILER COMPILER 23 matisch im Projektverzeichnis ein Ordner mit dem Namen templates angelegt. Alle Templates (.jet), die sich in diesem Ordner befinden, werden durch die JET-Engine automatisch übersetzt. In den Eigenschaften des Projektes muss nun noch der Ordner für die Java Quelldateien (JET Settings -> Source Container) eingestellt werden, in welchem die übersetzten Dateien abgelegt werden sollen. Diese Dateien aus dem Übersetzungsprozess sind sogenannte Implementierungsklassen, deren Instanzen den Code erzeugen. Durch Aufruf der Methode generate (Erzeugungsprozess) mit einem Argument der Klasse Object wird eine Zeichenkette (java.lang.string) erzeugt, die die Ausgabe gemäß dem Template enthält. Zur Erläuterung des Aufbaus eines Templates wird hier ein Beispiel aus [15] diskutiert. Die er- 1 <%@ jet package="hello" imports= "java.util.*" class="helloworldtemplate" %> 2 <%Date date = new java.util.date(); %> 3 Hello <%=argument%>! The current time is <%=date%>. Listing 2.6: Ein Template Beispiel ste Zeile des Listings 2.6 dient zur Initialisierung der Umgebungsparameter der JET-Engine und wird als JET-Direktive bezeichnet. Sie legt das Paket (package) fest, in welchem die übersetzte Klasse gespeichert wird. Mit imports werden die zu importierenden Pakete und Klassen (durch Leerzeichen getrennt) definiert, welche folgend im Quellcode als import-anweisung erscheinen. Mit class wird der Klassenname der zu generierenden Klasse festgelegt. Eine weitere Direktive stellt include dar, mit dessen Hilfe andere Dateien eingebunden werden können. Alle Anweisungen in <% und %> werden direkt in Implementierungsklasse übernommen. Sie heißen Scriptlets und können beliebige, gültige Java Code Fragmente enthalten. Ausdrücke (Expressions), die mit <%= beginnen, werden beim Aufruf der Klasseninstanz ausgewertet und als String umgewandelt. Alle nicht eingebetteten Zeichen werden an die Ausgabe angehangen. Der Code wird von der JET-Engine, wie im Listing 2.7 dargestellt, erzeugt. Eine Instanziierung dieser Implementierunsklasse zeigt Listing 2.8. Die Zeichenkette output würde nun die Ausgabe mit der Begrüßung und der aktuellen Zeit enthalten. Sie kann weiter verarbeitet und zum Beispiel in eine Datei geschrieben werden. JET kann benutzt werden, um beispielsweise Modellobjekte in einer bestimmten Form auszugeben. Die Verwendung von JET im Caspa Graphical Editor wird im Abschnitt genau erläutert. 2.7 Java Compiler Compiler Der Java Compiler Compiler (kurz: JavaCC) ist der bekannteste Parser Generator für Java Anwendungen. Er ist ein Werkzeug, welcher eine Spezifikation einer Grammatik einliest und in lauffähigen Java-Quellcode umwandelt. Er kann letztendlich genutzt werden, um beispielsweise Dokumente auf Korrektheit nach der Grammatik zu testen. Laut [16] besteht der Prozess der Analyse aus zwei Schritten: der lexikalischen und der syntaktischen Analyse.

32 24 KAPITEL 2. GRUNDLAGEN 1 package hello; 2 import java.util.*; 3 public class HelloWorldTemplate 4 { 5 protected final String NL = System.getProperties().getProperty("line.separator"); 6 protected final String TEXT_1 = "Hello "; 7 protected final String TEXT_2 = "! The current time is "; 8 protected final String TEXT_3 = "."; 9 10 public String generate(object argument) 11 { 12 final StringBuffer stringbuffer = new StringBuffer(); 13 Date date = new java.util.date(); 14 stringbuffer.append(text_1); 15 stringbuffer.append(argument); 16 stringbuffer.append(text_2); 17 stringbuffer.append(date); 18 stringbuffer.append(text_3); 19 return stringbuffer.tostring(); 20 } 21 } Listing 2.7: Die übersetzte Klasse HelloWorldTemplate.java aus dem Template 1 HelloWorldTemplate test = new HelloWorldTemplate(); 2 String output = test.generate("user"); Listing 2.8: Die Instanziierung der übersetzten Klasse HelloWorldTemplate.java Bei der lexikalischen Analyse wird das gegebene Dokument durch einen Scanner Stück für Stück betrachtet und dabei in die sogenannte Tokens unterteilt. Ein Token ist ein signifikanter Teil des Dokumentes und steht für Schlüsselworte, Satzzeichen und Symbole, wie Zahlen oder Zeichenketten. Die Erkennung der Tokens basiert auf regulären Ausdrücken. Als Separators werden Leerräume, wie Leerzeichen, Tabulatoren und andere Steuerzeichen, bezeichnet, die oft zur Trennung der Tokens genutzt werden. Bei der syntaktischen Analyse werden die gelieferten Tokens des Scanners durch den Parser zu einem Syntaxbaum aufgebaut und damit die Korrektheit gemäß der Grammatik festgestellt. Nach [9] ist die Syntax einer Sprache die Menge der erlaubten Zeichenketten und ist durch die Grammatik (mit den Regeln zur korrekten Bildung der Sprache) definiert. Nur wenn das Dokument nach diesen Regeln strukturiert ist, ist es syntaktisch korrekt. Stellt der Parser beim Untersuchen des Dokumentes fest, dass eine Regel verletzt wurde, so gibt er eine Fehlermeldung aus und beendet die Untersuchung. Eine Form die Regeln einer Grammatik zu definieren, ist die Erweiterte Backus-Naur-Form (EBNF). Man spricht von den Ableitungsregeln, die die Ersetzung der Elemente der Grammatik definieren. Die linken Seiten der Regeln werden durch die rechten Seiten definiert. In der EBNF werden verschiedene Metazeichen verwendet. Ein Ausdruck in spitzen Klammern definiert einen Sprachkonstrukt (z.b. <Term>). Eine alternative Definition wird durch eine senkrechten Strich gekennzeichnet. Ein Ausdruck in Mengenklammern drückt sein 0 bis mehrfaches Vorkommen aus. In eckigen Klammern werden Ausdrücke definiert, die 0 oder genau einmal vorkommen. JavaCC ist in der Lage, definierte Grammatiken mit einer Syntax ähnlich der EBNF, zu parsen.

33 2.7. JAVA COMPILER COMPILER 25 Mit dieser Ähnlichkeit sind die von JavaCC verwendeten Metazeichen gemeint. So definiert * die beliebige, + die mindestens einmalige und? die maximal einmalige Wiederholung des Ausdrucks. Es arbeitet laut [17] dabei nach dem Top-Down-Verfahren (Recursive Descent), wodurch linksrekursive Grammatiken nicht erlaubt sind. Hierzu ein kurzes Beispiel einer linksrekursiven Grammatik: A ::= Ax y. Nach dieser Grammatik sind alle Zeichenketten, die mit y beginnen und einer beliebiger Anzahl x enden, erlaubt. Diese kann in JavaCC wie folgt dargestellt werden: A ::= y(x), womit die Linksrekursivität dieser Grammatik umgangen worden ist. Die lexikalische und syntaktische Spezifikation wird in einer Quelldatei angegeben. Verschiedene Optionen erlauben dem Benutzer, das Verhalten des erzeugten Parsers zu verändern. So wird standardmäßig ein LL(1)-Parser von JavaCC erzeugt, der einen Lookahead von 1 besitzt. Als Lookahead wird die Anzahl der Tokens bezeichnet, die der Parser bei der Analyse vorausschaut. Da bestimmte Grammatiken nicht LL(1) sind, ist es dem Benutzer möglich, den Lookahead zu erhöhen. Die Definition von Special Tokens (z.b. für Kommentare) in der lexikalischen Spezifikation führt zu deren Nichtbeachtung während des Parsens. Damit ist gemeint, dass sie an beliebigen Stellen im Dokument auftauchen dürfen, ohne in der Grammatik dort definiert zu sein. Ein gekürztes Beispiel aus [18] soll den Aufbau einer JavaCC-Quelldatei im Listing 2.9 verdeutlichen. Wie bereits erwähnt, kann der Lookahead (hier 2) umdefiniert werden. Zwischen den 1 options 2 { 3 LOOKAHEAD=2; 4 } 5 PARSER_BEGIN(Arithmetic) 6 public class Arithmetic 7 { 8 } 9 PARSER_END(Arithmetic) 10 SKIP : 11 { 12 " " 13 "\r" 14 "\t" 15 } 16 TOKEN: 17 { 18 < NUMBER: (<DIGIT>)+ ( "." (<DIGIT>)+ )? > 19 < DIGIT: ["0"-"9"] > 20 } 21 double expr(): 22 {} 23 { 24 element() ( "+" expr() "-" expr() )* 25 } 26 double element(): 27 {} 28 { 29 <NUMBER> "(" expr() ")" 30 } Listing 2.9: Beispiel einer Spezifikation für JavaCC Anweisungen PARSER_BEGIN und PARSER_END wird die Klasse definiert, in der zusätzliche Methoden implementiert und durch die Parser-Methoden aufgerufen werden können. In SKIP

34 26 KAPITEL 2. GRUNDLAGEN werden die Separatoren definiert, welche vom Parser übersprungen werden. In der TOKEN- Umgebung spezifiziert man die Tokens, auf die man später zurückgreifen möchte. Hier im Beispiel definiert man DIGIT als Ziffer und NUMBER, welche aus mehreren DIGITs bestehen kann, die eventuell durch einen Dezimalpunkt getrennt sind. Die Parser-Methode element() deklariert ein Element entweder als NUMBER oder als geklammerten Ausdruck. Ein Ausdruck (expr()) besteht aus einem Element, was gar nicht oder mehrmals mit einem Ausdruck entweder mit + oder - verknüpft werden kann. Diese Grammatik stellt eine sehr einfache Arithmetik mit den Operatoren + und - dar. Die Entwicklung und der Einsatz eines Parsers, welcher in JavaCC entwickelt wurde und Eingabedateien des Werkzeugs Caspa lexikalisch und syntaktisch analysiert, wird im Abschnitt genau erläutert. 2.8 Plug-In-Development unter Eclipse In den vorangegangen Abschnitten wurde bereits erwähnt, dass man in der Lage ist, mit den verschiedenen Frameworks Erweiterungen für die Entwicklungsumgebung Eclipse zu erschaffen. Diese Erweiterungen werden als Plug-Ins bezeichnet. Bevor auf die Plug-Ins genauer eingegangen wird, sollen die Grundlagen von Eclipse verdeutlicht werden, die zu großen Teilen aus [19] stammen. Die Entwicklungsumgebung Eclipse Als Entwicklungsumgebung wird eine Anwendung bezeichnet, mit der es möglich ist, Software in einer oder mehreren Programmiersprachen zu entwickeln. Sie enthält nach [9] typischerweise einen Editor für die Quelldateien, eine Anbindung an Compiler 32, Linker 33 und Debugger und besitzt die Möglichkeit zur Quelltextformatierung. Eclipse ist eine solche Entwicklungsumgebung (engl. Integrated Development Environment, kurz: IDE), die über diese Dinge hinaus eine Menge mehr nützliche Funktionen enthält. Es wurde von IBM und acht weiteren Firmen im November 2001 erschaffen, läuft auf verschiedensten Betriebssystemen und ist sprachenneutral. Dem zufolge ist es nicht an Java gebunden, obwohl es selbst auf Java basiert. Eclipse ist ein Open-Source-Projekt und es gibt über 100 weitere auf Eclipse basierende Open-Source- Projekte. Die Java Entwicklungsumgebung wird durch Werkzeuge unterstützt, die die Entwicklung von Software in der Programmiersprache Java sehr produktiv machen, da viele Operationen automatisiert wurden. Dazu gehören Syntaxhervorhebung, Codevervollständigung, Codeassistenz und weitere ergänzende Ansichten, die die Struktur des Codes und zu erledigende Aufgaben zeigen. Ein integrierter Debugger macht es möglich, die Ausführung des Codes an 32 Der Compiler wandelt den Quellcode eines Programms einer höheren Programmiersprache in ein äquivalentes Programm einer Zielsprache, wie z.b. Maschinen- oder Bytecode, um. Er meldet dem Benutzer Fehler im Code des Quellprogramms. 33 Der Linker besteht aus Lader und Binder. Während der Lader die Adressen im Maschinencode zu absoluten Adressen umwandelt und das Programm in den Speicher lädt, fasst der Binder die verschiedenen Programmteile (wie Bibliotheken) zu einem Programm zusammen.

35 2.8. PLUG-IN-DEVELOPMENT UNTER ECLIPSE 27 bestimmten Punkten anzuhalten und dann Stück für Stück fortzusetzen, um das Verhalten des Programms zu analysieren und Fehler zu finden. Neben dieser Umgebung bietet Eclipse die Möglichkeit zur Werkzeug-Integration, das heißt, es läßt sich beliebig mit anderen Komponenten verknüpfen. Dies ist durch den Plug-In-Mechanismus nach dem Grundkonzept von OSGi (siehe 2.9) gegeben. Es vereint Werkzeuge zum Entwurf, zur Programmierung, zum Testen und Zeichnen und erhöht somit die Produktivität. Hinter Eclipse steht eine Entwickler-Community, die aus Experten, Selbstständigen, Akademikern, Leuten aus der Industrie und auch freien Entwicklern besteht. Durch diese ist es möglich, Eclipse stets zu verbessern und zu erweitern. Die Eclipse-Organisation besteht aus mehreren Projekten (Beispiele sind die erwähnten Frameworks), welche über die Website [20] erreichbar sind. Das Eclipse-Fenster ist in mehrere Bereiche unterteilt, die nun genauer beleuchtet werden. So gibt es Editoren, mit denen die verschiedenen Ressourcentypen erzeugt und bearbeitet werden können. Ein weiterer Bereich wird durch die verschiedenen Ansichten (Views) geschaffen. Die Outline-Ansicht zeigt zum Beispiel die Inhaltsstruktur der geöffneten Datei an. Die Properties- View (Eigenschaften-Ansicht) zeigt Eigenschaften der Datei an, wie Größe und letztes Aktualisierungsdatum. Diese Views können verschieden genutzt werden, wie im graphischen Editor von GMF später zu sehen sein wird. Eine Perspektive spezifiziert das Layout von Editoren und Ansichten, die für eine bestimmte Aufgabe definiert worden sind. Zum Beispiel gibt es eine Debug-Perspektive, die für das Debuggen eines Programms ausgelegt ist und alle notwendigen Funktionen zur Verfügung stellt. Es gibt eine Vielzahl weiterer Perspektiven, die bequem während des Betriebes gewechselt werden können. Auf die Plug-In Development Perspektive geht der Abschnitt 3.3 genauer ein. Gemäß [21] besteht Eclipse aus drei Ebenen. Die erste Ebene ist die Plattform, welche die Infrastruktur von Eclipse darstellt und programmiersprachenunabhängig ist. Die Java Development Tools (JDT) sind die Java-Entwicklungswerkzeuge und binden ein komplettes Java-IDE als zweite Ebene in Eclipse ein. Das Plug-In Development Environment (PDE) stellt die Erweiterung der JDT, sodass die Entwicklung von Plug-Ins unterstützt wird. Die Plattform besteht aus den zwei Komponenten: Kern und Benutzeroberfläche (engl. User Interface, kurz: UI). Der Kern wiederum trennt sich in Laufzeitkomponente (Runtime), die die Plug-In-Infrastruktur spezifiziert und während dem Start von Eclipse die verfügbaren Plug-Ins lädt und verwaltet, und Arbeitsbereich, der die Projekte verwaltet, welche aus Ordnern und Dateien des Dateisystems bestehen. Die Benutzeroberfläche teilt sich in SWT (siehe 2.4), JFace und Workbench. JFace setzt auf SWT auf und besteht aus UI-Frameworks, welche die Aufgaben der Benutzeroberfläche wahrnehmen. Die Workbench repräsentiert die Eclipse-Oberfläche und stellt damit die Editoren, Ansichten und Perspektiven bereit. Die Plug-Ins Eclipse besteht bis auf seinen Kern nur aus Erweiterungen, den Plug-Ins. Diese sind Anwendungen, die in die Benutzeroberfläche von Eclipse eingeklinkt werden. Sie bieten verschiedenste Funktionalitäten an und können somit die Entwicklungsumgebung von Eclipse erweitern. Allein die Eclipse-Basis zusammen mit der Java-Umgebung besteht schon aus mehr als 60 Plug- Ins. Da eine Vielzahl von Plug-Ins beim Start von Eclipse geladen werden und trotzdem eine

36 28 KAPITEL 2. GRUNDLAGEN kurze Startphase erwartet wird, verfährt Eclipse nach der sogenannte Lazy Loading Rule (Faules Laden). Dies bedeutet, dass nur benötigte Erweiterungen geladen werden. Die neuen Funktionalitäten eines Plug-Ins werden über die Erweiterungspunkte eingebracht. Diese stellen einen Architekturmechanismus dar, über den die Erweiterbarkeit des Plug-Ins öffentlich gemacht wird. Sie können damit von anderen Plug-Ins erweitert werden. Als Beispiel: Die Benutzeroberfläche von Eclipse bietet Erweiterungspunkte an, um neue Editoren und Ansichten für bestimmte Dateitypen zu schaffen. So kann aber auch die Menüzeile und die Werkzeugleiste beliebig verändert und erweitert werden. Ein Plug-In ist standardmäßig wie folgt aufgebaut: Es ist ein Verzeichnis, das eine plugin.xml- Datei enthält, welche als Plug-In-Manifest-Datei bezeichnet wird. Weiterhin kann es wahlweise Ressourcen, wie Symbole, und Java-Code gepackt als Java Archive Datei (JAR) enthalten. In der plugin.xml wird festgelegt, wo im Plug-In Erweiterungspunkte sind (Erweiterungen von anderen akzeptiert werden) und welche anderen Plug-Ins durch dieses erweitert werden. Durch das PDE bietet Eclipse eine ganze Reihe von Tools an, die die Entwicklung von Plug-Ins unterstützen. So gibt es Assistenten zum Erstellen von Plug-In-Projekten, spezielle Editoren für die plugin.xml und die Möglichkeit, die Plug-Ins in einer eigenen Instanz einer Workbench zu testen. Die Entwicklung des GMF-Editors als Erweiterung von Eclipse wird in Abschnitt erläutert. 2.9 Losgelöst vom Eclipse IDE - Die Rich Client Platform Seit Eclipse 3.0 gibt es die Möglichkeit, Anwendungen zu schreiben, die auf Eclipse basieren aber nicht mehr das komplette IDE benötigen. Eine solche Anwendung wird als Rich Client Platform bezeichnet. Rich Client leitet sich nach [22] von Fat-Client ab, welcher die komplette Verarbeitung der Daten beim Client vollzieht. Ein Thin-Client bezieht den Großteil seiner Daten vom Server und enthält nur Benutzeroberfläche und Funktionen, die der Kommunikation mit dem Server dienen (vgl. Online-Banking). Im Gegensatz zum Fat-Client löst der Rich-Client meist nicht nur ein Problem und besteht aus einem Framework, welches durch Plug-Ins erweiterbar ist. So können Lösungen verschiedener Anbieter (Erweiterungen) zusammengebracht und als ein Programm verfügbar gemacht werden. Weitere Eigenschaften eines Rich-Clients sind: Fähigkeit zur Anpassung an Endbenutzer und verschiedene Plattformen Problemlose Verteilung an Endbenutzer und Aktualisierbarkeit des Clients Aufwendige Benutzeroberfläche möglich Somit werden Vorteile von Fat- und Thin-Client kombiniert, ohne dabei Nachteile zu erlangen. Ein Rich-Client muss nicht in einer Client-Server Struktur gebunden sein, wie sich aus der obiger Beschreibung vermuten ließe. Er läuft losgelöst von dem schwerwiegenden IDE von Eclipse, was hier mit einem Server vergleichbar wäre.

37 2.9. LOSGELÖST VOM ECLIPSE IDE - DIE RICH CLIENT PLATFORM 29 Laut [23] ist eine RCP-Anwendung eine Ansammlung von Plug-Ins und einer Laufzeitkomponente, auf welcher sie ausgeführt werden. Dazu fasst der Entwickler seine eigenen Plug-Ins mit denen der Eclipse-Basis zusammen. Die eigenen Plug-Ins müssen nun eine Application (Anwendung) und eine Product Definition enthalten. Die RCP ist leichtgewichtiger als das komplette Eclipse IDE, da nur noch ein Teil der Plug-Ins benötigt wird, welche auf dem Java Runtime Environment (JRE) laufen. Das Eclipse IDE basiert seit der Version 3.0 selbst auf RCP. Die Möglichkeiten von RCP werden durch eine kleine Anzahl unabhängiger Plug-Ins bereitgestellt, der RCP-Basis. Dazu gehören UI, Runtime und OSGi (Open Services Gateway Initiative). Das UI nutzt JFace und wird für die Editoren, Ansichten, Perspektiven und die Workbench benötigt. SWT stellt auch hier die graphische Basis dar. Runtime ermöglicht den Einsatz von Erweiterungen, Anwendungen und Produkten. Außerdem löst es die Abhängigkeiten der verschiedenen Plug-Ins auf und verknüpft sie miteinander. OSGi stellt die Dienste zum Einbinden der Plug-Ins zur Verfügung. Im weiteren Verlauf werden Runtime und OSGi näher erläutert. Seit Eclipse 3.1 hat sich der Aufbau der Plug-Ins geändert: Ein Plug-In ist von nun an in einer JAR Datei gepackt, in der Ressourcen, die kompilierten Klassen und die Spezifikation des Plug-Ins enthalten sind. Die Spezifikation besteht aus einer Manifest.MF-Datei, welche Ausführungseigenschaften und die Beschreibung enthält, und der plugin.xml, die Eigenschaften zur Erweiterung und Erweiterungspunkten beinhaltet. Trotz dieser Änderung des Aufbaus der Plug-Ins sind Eclipse 3.1 und seine Nachfolger kompatibel mit Plug-Ins, die der Form aus Abschnitt 2.8 entsprechen. Eine fertige RCP-Anwendung besteht aus mehreren Komponenten im Dateisystem. Im Installationsverzeichnis befinden sich verschiedene Verzeichnisse, wie Configuration und Plugins, und Dateien, wie dem Launcher (Programmstarter) und einer Eclipse-Produktdatei. Im Configuration-Verzeichnis ist eine config.ini zu finden, welche den Produktnamen und OSGi- Startparameter beinhaltet. Außerdem legen dort die Plug-Ins ihre spezifischen Einstellungen ab. Im Verzeichnis Plugins befinden sich die Erweiterungen, sowohl in Form von Verzeichnissen als auch als JAR-Dateien. Das Plug-In Komponenten-Modell von Eclipse stammt von der OSGi Framework Spezifikation R4.0 ab 34. Sie definiert ein Framework, um die Definition, Zusammenfügung und Ausführung von Komponenten (darin als Bundles bezeichnet) zu realisieren. In Eclipse sind diese Komponenten die Plug-Ins, die sich funktional nicht von den Bundles unterscheiden. Das OSGi- Framework verwaltet die Bundles und ihren beinhalteten Code, indem es deren Aufruf kontrolliert und segmentiert. Jedes Bundle besitzt einen eigenen Classloader (Activator), der zum Laden einer Instanz des Plug-Ins benötigt wird. Der jeweilige Klassenpfad wird dynamisch anhand der Abhängigkeiten, die im Manifest definiert werden, konstruiert. Abbildung 2.5 zeigt als Beispiel das Manifest des org.eclipse.ui Plug-Ins. Neben Name und Version des Bundles ist der Classloader (als Plug-In class bezeichnet) sowie die benötigten Bundles und das zur Verfügung gestellte Paket (Erweiterung) zu erkennen. Durch die Umsetzung von OSGi als eigenständige Implementierung ist Eclipse in der Lage, zur Laufzeit Erweiterungen zu installieren und zu entfernen, ohne dafür neu starten zu müssen. Runtime ist für das Ausführen einer Application zuständig, die eine Art main()-methode 35 für 34 Weitere Informationen zu dieser Technologie sind auf [24] zu finden. 35 In normalen Java-Programmen wird diese Methode beim Start als erstes ausgeführt.

38 30 KAPITEL 2. GRUNDLAGEN Abbildung 2.5: Manifest des Plug-Ins org.eclipse.ui (aus [23]) Eclipse darstellt. Nachdem Runtime durch den Launcher gestartet wurde, versucht es die Application zu finden und auszuführen. Diese wird in der plugin.xml des jeweiligen Plug-Ins definiert. Products sind eine Stufe höher als Applications anzusehen, da bestimmte Brandings (Merkmale), wie Splash-Screen (Startbildschirm), Fenstersymbole und spezifische (für das jeweilige Betriebssystem) Ausführungsparameter für die jeweilige Application gesetzt werden können. Plug-Ins bieten Erweiterungspunkte an, an denen andere anknüpfen können. Um diese Verbindung zwischen den verschiedenen Plug-Ins zu ermöglichen, verwendet Runtime die sogenannte Extension Registry. Dies soll das Beispiel, welches aus [23] übernommen wurde, verdeutlichen. Das UI von Eclipse stellt actionsets zur Verfügung, die Menü- und Werkzeugleistenaktionen repräsentieren. In der plugin.xml des UI steht Folgendes: 1 <extension-point id="actionsets" name="action Sets"/> Listing 2.10: Erweiterungspunkt der UI Möchte ein Plug-In eine eigene Aktion einbringen, so muss es diesen Punkt erweitern. Dies geschieht wie folgt in der plugin.xml: 1 <extension point="org.eclipse.ui.actionsets"> 2 <actionset id="org.eclipsercp.hyperbola.debugactionset"> 3 <action 4 id="org.eclipsercp.hyperbola.debug" class="org.eclipsercp.hyperbola.debugaction" 5 icon="icons/debug.gif" label="debug Chats"/> 6 </actionset> 7 </extension> Listing 2.11: Erweiterung durch Hyperbola Plug-In Nun wird eine neue Aktion in der Menüleiste mit dem Namen Debug Chats und dem Symbol debug.gif durch das UI angelegt. Betätigt der Benutzer diese Aktion, wird die Klasse DebugAction instanziiert und ihre Methode run() aufgerufen. Diese Klasse implementiert das Interface IActionDelegate, welches von dem UI vorgegeben wird. Die Klasse DebugAction wird auch nur dann aufgerufen, wenn der Benutzer die Aktion auslöst, ansonsten nicht. Nach der Erläuterung der Grundlagen folgt im nächsten Kapitel die Umsetzung der Aufgabenstellung auf Basis der hier vorgestellten Frameworks und Werkzeuge.

39 Kapitel 3 Konzeption und Implementierung Nach Abwägung der verwendbaren Möglichkeiten in Abschnitt 3.1 zur Lösung der gestellten Aufgabe wird der Weg von der Konzeption des Modells in Abschnitt 3.2 bis hin zur Entwicklung des graphischen Modelleditors in Abschnitt 3.3 beschrieben. Dabei wird der Schwerpunkt auf die Verwendung des Graphical Modeling Frameworks gelegt. Nach der Beschreibung der eigenen Erweiterungen und Anpassungen im entstandenen Quellcode folgt eine Darstellung zur Gewinnung eines Eclipse-Plug-Ins sowie der Generierung einer Rich-Client-Platform. Der Abschnitt 3.4 zeigt die Umsetzung der wichtigsten Funktionalitäten, die die Schnittstelle zum Werkzeug Caspa herstellen. Dazu zählen der Export der Diagrammmodelle zu Eingabedateien für Caspa und die Importierung vorhandener Eingabedateien zu einem Diagrammmodell. Schließlich beschäftigt sich dessen letzter Unterabschnitt mit der Möglichkeit des direkten Aufrufens des Werkzeugs in der Umgebung des Editors. Der letzte Abschnitt 3.5 beschäftigt sich mit dem Testen des implementierten Editors. In diesem Kapitel werden die Schritte zur Entwicklung des Editors recht genau beschrieben, da der Aufgabensteller diese Art der Ausarbeitung für diese Arbeit gewünscht hat. Dadurch wird dem zukünftigen Entwickler ermöglicht, diese Schritte nachzuvollziehen und besser in die Entwicklung des Editors einzusteigen. Eigene Methoden und Klassen wurden entsprechend kommentiert, sodass es ihm möglich sein wird, das Projekt fortzuführen. Natürlich wird nicht jedes kleine Detail beschrieben. Die grundlegende Umsetzung wird jedoch an Beispielen und Grafiken aus der Entwicklung dieses Werkzeugs untermauert. 3.1 Möglichkeiten der Umsetzung Die Aufgabe dieser Arbeit besteht in der Erstellung eines graphischen Editors für das Werkzeug Caspa. Es bestehen mehrere Möglichkeiten, ein solches Projekt zu realisieren. In jedem Fall soll eine Anwendung mit graphischer Benutzeroberfläche entstehen, um der textuellen Eingabe des Werkzeugs den Rücken zu kehren. Die Wahl der Programmiersprache liegt sicher in den Fähigkeiten des jeweiligen Programmierers. Auf jeden Fall sollte eine objektorientierte Sprache, 31

40 32 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG wie Java oder C++, angewendet werden. Nun hat man die Wahl zwischen zwei Möglichkeiten. Nachdem man sich eine gute Wissensgrundlage in Form eines Klassendiagramms und mehrerer Anwendungsfall- und Sequenzdiagramme erstellt hat, kann man entweder alles von Hand programmieren oder man nutzt vorhandene Code-Generatoren, die ein Modell als Grundlage besitzen. Da ein graphischer Editor mit all seinen Aktionen, Fenstern und vor allem der graphischen Verwaltung recht zeitintensiv zu entwickeln ist, nutzt man sicherlich Entwicklungswerkzeuge, die diese Arbeit extrem verkürzen. So stellt man schnell fest, dass die modellgetriebene Softwareentwicklung für eine Aufgabe dieser Art sehr gute Werkzeuge bietet. Wenn man bereits Erfahrung mit der Entwicklungsumgebung Eclipse und Java besitzt, so stößt man rasch auf das Eclipse Modeling Framework. Die Code-Generierung auf Grundlage eines definierten Modells in Form eines Klassendiagramms überzeugt den ambitionierten Java-Programmierer. Um dieses definierte Modell graphisch zu verändern, liegt es nahe, sich genauer mit dem Graphical Editing Framework zu beschäftigen. Diesen Vorschlag brachten die Betreuer dieser Arbeit zur Umsetzung des Editors hervor. Da das Graphical Modeling Framework diese beiden genannten Frameworks zusammenbringt und in Form von Validierung und mehr Funktionalitäten noch erweitert, entscheidet man sich für diesen Weg. Bei der Erstellung des graphischen Editors für Caspa wurde der Ansatz von Rapid Prototyping angewendet. Nach [25] werden dabei durch Generatoren Prototypen des Systems geschaffen. Anschließend werden diese dem Aufgabensteller präsentiert und ungeeignete Prototypen verworfen. Der beste Ansatz wird nach den Wünschen des Aufgabenstellers weiterentwickelt und verbessert. Da diese Aufgabe ein relativ kleines und auch nicht sicherheitsrelevantes Ein-Mann- Projekt darstellt, wurde auf die Erstellung eines Pflichtenheftes verzichtet. Der Aufgabensteller ist durch die ständige Präsentation des fortgeschrittenen Programms am Entwicklungsprozess stark beteiligt und unterstützt durch unabhängiges Testen der Oberfläche des Editors. Es handelt sich bei der Umsetzung um ein leichtgewichtiges Vorgehensmodell, bei dem von strikter Phasentrennung und Phasendokumenten abgesehen wird. Die Dokumentation des Produktes wird durch diese Arbeit, vor allem durch ein Benutzerhandbuch in Kapitel 4, repräsentiert. 3.2 Das Modell des Editors Durch die Analyse der Aufgabe und Rücksprache mit dem Aufgabensteller wurde ein Modell erstellt, welches stets im ganzen Entwicklungsprozess korrigiert und verfeinert wurde. Es repräsentiert die Objekte, welche in Caspa zur Modellierung zur Verfügung stehen. Dabei wurden die einzelnen Elemente untersucht und geeignete Objekte zu deren Repräsentation ermittelt. Aus diesem Modell wurde ein Klassendiagramm erzeugt, welches zur besseren, visuellen Darstellung des Modells dient. Im Folgenden wird das EMF-Modell anhand des Klassendiagramms erläutert. Die Erstellung dieses Modells mit Hilfe der Werkzeuge des Eclipse Modeling Frameworks erfolgt später in diesem Abschnitt.

41 3.2. DAS MODELL DES EDITORS 33 Abbildung 3.1: Klassendiagramm des graphischen Editors

42 34 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Zur Erklärung des Klassendiagramms wird auf die Abbildung 3.1 und den Abschnitt 2.1, der die Grundlagen von Caspa erläutert, verwiesen. In der folgenden Erläuterung werden alle Bezeichner in Klammern hervorgehoben dargestellt. Dies erleichtert dem Leser das jeweilige Element im Klassendiagramm zu finden. Die verwendeten Beziehungen zwischen den Klassen, die auch in der Legende angegeben wurden, sind Kompositionen 1, Assoziationen mit Navigierrichtung 2 und Spezialisierungen 3 Das Hauptobjekt des entstehenden Modells, welches alle Objekte beinhaltet, wurde als Caspa- System bezeichnet. Jedes CaspaSystem besitzt eine Instanz von Definition (definitions). Dies dient zur Speicherung aller Konstanten (constants), Raten (rates) und Gewichte (weights) des Systems. Diese Objekte besitzen jeweils einen Namen (name) und einen Wert (value). Weiterhin enthält die Definition genau ein Objekt Measure (measures), das zur Sammlung aller Leistungsmaße des Systems genutzt wird. Measure kann beliebig viele Objekte von Statemeasures (Zustandsmaß), Meanvalues (Mittelwertmaß) und Throughputmeasures (Durchsatz) enthalten. Alle Leistungsmaße besitzen einen Bezeichner (identifier). Ein Statemeasure besitzt zusätzlich eine Zustandsbeschreibung (state), für die die Wahrscheinlichkeit später berechnet werden soll. Meanvalue hat als Attribute den Prozess (process) und den Prozessparameter (parameter), dessen Mittelwert berechnet werden soll, sowie die Instanz (instance), falls es mehrere Instanzen des Prozesses gibt. Ein Troughputmeasure verfügt über eine Aktion (action), für die der Durchsatz berechnet werden soll. Das CaspaSystem besitzt genau eine Wurzel (Root), welche den Namen des Systems (system) und eine Verbindung zu einem anderen Objekt im System speichert. Dieses Objekt kann entweder ein Prozess (Process), ein Knoten (Hidenode), welcher Aktionen eines Prozesses verdecken kann, oder ein Knoten (Synchnode), der zum Synchronisieren von Prozessen genutzt wird, sein. Die Verbindung zum Prozess wird über einen RootProcessLink hergestellt. Ein Hidenode kann als Nachfolger entweder einen Prozess über einen HidenodeProcessLink, einen weiteren Hidenode (hidenode) oder einen Synchnode (synchnode) besitzen. Jeder Hidenode besitzt eine eindeutige Nummer (ID) und eine Menge von Aktionen (actions). Bei einem Synchnode verhält es sich ähnlich. Er kann über zwei bis endlich viele Nachfolger verfügen. Dazu zählen Prozesse, welche über SynchnodeProcessLinks verbunden werden, Hidenodes (hidenode) und weitere Synchnodes (synchnode). Ein Synchnode hat ebenso eine ID und Aktionen (actions). Auf das Attribut actionsoutput wird im Abschnitt eingegangen. Die genannten ProcessLinks, welche immer mit einem Prozess verbunden sind, werden benötigt, um die Prozessparameter der jeweiligen Verbindungen zu speichern. Sie besitzen jeweils ein Referenzattribut, um auf ihre Quell- und Zielknoten zugreifen zu können. So hat ein HidenodeProcessLink Zugriff auf seinen Quellknoten über das Attribut hidenode und zum Zielknoten mit process. Der Hidenode erreicht den Link durch sein Attribut processlink. 1 Eine Aggregation beschreibt die Beziehung zwischen zwei Objekten, wobei das eine ein Teil des anderen Objektes darstellt. Die Komposition ist ein Spezialfall der Aggregation, bei der das Objekt höchstens ein Elternobjekt haben darf. [25] (vgl. Containment in Abschnitt 2.3) 2 Eine Assoziation mit Navigierrichtung beschreibt gemäß [25] eine unidirektionale Beziehung zwischen zwei Objekten. Dabei wird die Beziehung in Pfeilrichtung aufgelöst. Ein Beispiel: Ein Zustand kennt seinen Prozess über die Assoziation mit dem Namen fatherprocess. 3 Die Spezialisierung ist eine Art der Vererbung. Das neue Objekt stellt einen Spezialfall des Elternobjektes dar. Hier wurden die Spezialisierung genutzt, um verschiedene graphische Repräsentationen im Editor zu erreichen.

43 3.2. DAS MODELL DES EDITORS 35 Das CaspaSystem hat Zugriff auf alle Prozesse (processes), Hidenodes (hidenodes), Synchnodes (synchnodes) und die Wurzel (root) im System. Jeder Prozess besitzt eine endliche Anzahl von Zuständen (states), Transitionen (transitions), die die Zustände miteinander verbinden, und Zugriff auf das CaspaSystem (system). Jeder Zustand (State) hat einen Namen (name), eine Menge von Parametern (parameters) und wiederum Zugriff auf den Prozess (fatherprocess). Die Parameter sind die jeweiligen geerbten Parameter vom Prozess, die entweder durch eine natürliche Zahl belegt oder durch den Bezeichner bestimmt sind. Ein Zustand kann entweder ein normaler Zustand (NormalState), ein leerer Zustand (EmptyState) oder ein Zustand für das Prozessende (StopState) sein. Ein leerer Zustand repräsentiert den Übergang von einem Zustand zu einem Weiteren, was in Caspa durch zwei aufeinanderfolgende Transitionen ohne Zwischenzustand ausgedrückt wird. Ein StopState kann nur eingehende Kanten besitzen, da der Prozess in diesem Zustand beendet wird. Dies wird in Caspa durch stop verwirklicht. Alle anderen Zustände werden hier als normal bezeichnet, die in der Regel auch den selben Namen haben, wie ihr Vaterprozess. Es können durchaus Unterzustände mit anderem Namen definiert werden, die in Caspa dann als eigene Prozesse auftauchen. Sie werden im Quellcode als Understates bezeichnet, unterscheiden sich aber nicht von den normalen Zuständen. Daher tauchen sie im Modell nicht auf. Sie müssen im späteren Verlauf nur gesondert betrachtet werden. Eine Transition, die zwei Zustände verbindet, hat Zugriff auf Quell- (sourcestate) und Zielzustand (targetstate). Sie besitzt des Weiteren eine Aktion (action), eine Menge von Wächtern (guards) und eine Menge von Zuweisungen (assigns). Die Zuweisungen dienen zum Belegen der Prozessparameter, falls diese im Zielzustand nicht durch eine natürliche Zahl bereits belegt sind. Es gibt zwei Typen von Transitionen: Transition mit einer Rate (RateTransition) oder mit einem Gewicht (WeightTransition). Sie besitzen abhängig von ihrem Typ entweder das Attribut Rate (rate) oder Gewicht (weight). Die WeightTransition wurde eingeführt, da im Moment eine zweite Arbeit zu Caspa durchgeführt wird, in der neben zeitbehafteten auch zeitlose Transitionen neu hinzukommen sollen. Die Klassen State und Transition selbst sind abstrakt, daher kann keine Instanz von ihnen erzeugt werden. Nur deren genannte Spezialisierungen sind instanziierbar. Viele Bezeichner, wie parameter und parameters, tauchen anscheinend doppelt auf. Das liegt daran, dass eines dieser Attribute mehrere Werte aufnehmen kann, die durch Komma getrennt werden. So ist beispielsweise parameter eine Zeichenkette, die die Werte mit Kommas enthält, und parameters eine Liste, in der jeder Wert als einzelnes Element repräsentiert wird. Das dient zur bequemen Eingabe einer Liste mit Werten im graphischen Editor durch eine Zeichenkette, in der die Werte mit Komma getrennt werden. Nach dem Parsen wird diese Zeichenkette (parameter) an den Kommas getrennt und die Liste (parameters) erzeugt. Ebenso verhält es sich bei assigns und guards der Transitionen. Die Umsetzung des Modells Nachdem das zugrunde liegende Modell anhand des Klassendiagramms erläutert wurde, folgt nun die Umsetzung in EMF. Das Erstellen wird dabei an ausgewählten Beispielen von Modellelementen beschrieben. In Eclipse wurde dazu ein neues GMF-Projekt mit dem Namen studium.da.caspaedit erzeugt. Als erstes erscheint ein sogenanntes GMF-Dashboard, welches eine

44 36 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG graphische Repräsentation der Zusammenhänge der einzelnen Modelle in GMF darstellt (siehe Abbildung 3.2). Mit diesem kann das Domänenmodell über Create erzeugt werden. Dabei Abbildung 3.2: Das Dashboard von GMF 2.0 (Bildschirmkopie) wird der Ecore Model Wizard genutzt und ein neues Ecore-Modell caspaedit.ecore erstellt. Diese Möglichkeit des direkten Erstellens eines Ecore-Modells wurde in der neuen Version von EMF verwirklicht 4 und von GMF genutzt. Der erste Eintrag, der in dem erzeugten Ecore zu finden ist, stellt das Paket dar und trägt noch keinen Namen (ist null). Über Properties im unteren View gibt man diesem Paket (dem Modell) einen Namen. In diesem Fall lautet er caspaedit. Durch Rechtsklick auf den Knoten caspaedit können nun Kindobjekte erzeugt werden. Dazu wählt man als erstes eine EClass aus, um eine Objektklasse zu erzeugen. Dieser gibt man einen Namen, hier CaspaSystem. CaspaSystem besitzt eine Referenz auf Definitions. Dazu erzeugt man eine neue EClass Definitions. In der Klasse CaspaSystem kann man danach eine EReference mit dem Name definitions und dem EType Defintions anlegen. Da es genau eine Instanz von Definitions geben soll, wird Lower und Upper Bound auf 1 gesetzt. Es liegt eine Komposition für die Referenz vor, deshalb muss Containment auf true gesetzt werden. Im Folgenden wird die Klasse Root mit einem EAttribute system erstellt. Dieses Attribut hat den EType EString und stellt demnach eine Zeichenkette dar. Die Klasse CaspaSystem kann die Referenz auf Root mit dem Namen root erhalten. Ein Hidenode besitzt einen eindeutigen Wert (ID), der durch das Anlegen eines EAttribute vom EType EInt entsteht. Um diese Eindeutigkeit zu spezifizieren, wird der Parameter ID in den Properties auf true gesetzt. Außerdem besitzt ein Hidenode eine Referenz auf sich selbst. Es wird eine EReference mit dem EType Hidenode angelegt und Containment auf false gesetzt, da keine Komposition vorliegt. Listen von Objekten werden erzeugt, in dem man Lower Bound mit 0 und Upper Bound mit -1 belegt. Es können endlich viele Konstanten in Definitions auftreten. Demnach besitzt das Objekt Definitions eine Referenz auf Objekte der Modellklasse Constant mit dem Namen 4 als Zusatz zu den im Grundlagen-Kapitel genannten Möglichkeiten mittels annotierten Java-Klassen, direktes Schreiben eines XMI-Dokuments und Importieren aus UML-Tools

45 3.3. DIE ERSTELLUNG DES EDITORS 37 constants und der Eigenschaft eines Containments. Wählt man für Upper Bound den Wert - 1 aus, so wird automatisch eine EList von Constant in Definitions aufgebaut. Um Vererbung zu modellieren, wird beim Anlegen einer neuen Klasse als ESuper Types die Oberklasse definiert. So wird für die Klasse EmptyState als Oberklasse State gewählt. Die Listen von Parametern, Zuweisungen und Wächtern (parameters, assigns und guards) werden als transiente Attribute (Transient auf true setzen) deklariert, da sie redundant zu den entsprechenden Zeichenfolgen sind. Somit werden diese bei der Serialisierung des Modells nicht ausgelagert. Gemäß obigem Klassendiagramm kann nach der vollständigen Definition des Ecore-Modells mit der Erstellung des Editors begonnen werden. 3.3 Die Erstellung des Editors Dieser Abschnitt behandelt die Erstellung des graphischen Caspa-Editors mit Hilfe des Graphical Modeling Frameworks. Für dessen Nutzung wird ein vorhandenes Ecore-Modell vorausgesetzt, dessen Erstellung im vorigen Abschnitt behandelt wurde. Im Grundlagen-Kapitel wurde GMF sowie die einzelnen Schritte, die notwendig sind, um aus einem Ecore-Modell einen graphischen Editor zu gewinnen, vorgestellt. Im Dashboard wird das Generatormodell (Domain Gen Model) mittels Derive vom erstellten Domänenmodell abgeleitet. Dieses wird benötigt, um den EMF-Editor zu generieren. Die meisten Einstellungen setzt GMF automatisch, sodass man sich darum nicht bemühen braucht. Im abgeleiteten Generatormodell befindet sich ein Abbild des Domänenmodells. In diesem können unter anderem die Repräsentationen der einzelnen Klassen, Attribute und Referenzen im Editor angepasst werden. Im Paket Caspaedit muss die Eigenschaft Base Package auf studium.da angepasst werden, damit der generierte Code später im Projekt richtig eingebunden wird. EMF.Edit verfügt über ein Property Sheet, in welchem die Attribute von Modellklassen bearbeitet werden können. Man kann durch den Property Type unter Edit in den Eigenschaften des Attributes festlegen, ob das Attribut bearbeitet, nur gelesen oder überhaupt nicht angezeigt werden soll. In diesem Editor werden sämtliche Attribute, wie parameters, assigns und guards, mit Property Type None belegt, da der Benutzer diese nicht sehen soll. Sie dienen lediglich zur internen Darstellung von Listen. Für die Modellklassen kann festgelegt werden, ob sie im Property Sheet ein Symbol und einen Text, welcher durch ein Attribut (wie z.b. der Name) gegeben wird, anzeigen sollen. So wird für die Modellklasse Root die Eigenschaft Image auf true und als Label Feature das Attribut system gewählt. Nach abgeschlossener Bearbeitung der Edit-Eigenschaften kann aus dem Generatormodell der Modellcode und der Edit-Code erzeugt werden. Dies geschieht durch Rechtsklick auf die Wurzel des Generatormodells. Der Generator erzeugt den Modellcode im Paket studium.da.caspaedit/src mit den Interfaces der Modellklassen und den Implementationsklassen unter studium.da.caspaedit.impl. Der generierte Edit-Code wird in studium.da.caspaedit.edit abgelegt, der die erzeugten ItemProvider-Klassen für die jeweiligen Modellklassen und die ItemProviderAdapterFactory beinhaltet. Auf dieser Grundlagen kann ein sehr einfacher, baumartiger Modelleditor erzeugt werden, der aber hier nicht weiter betrachtet wird. Der Editor für das Werkzeug Caspa soll graphische Elemente enthalten, die im nächsten Abschnitt definiert werden.

46 38 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Definition der graphischen Elemente Zur Erstellung des graphischen Modells wird auf das Dashboard zurückgegriffen, da dieses die Möglichkeit bietet, das Modell aus dem Domänenmodell abzuleiten. Als Diagrammelement wird die Modellklasse CaspaSystem gewählt, die die Wurzel des Modells darstellt. Im nächsten Schritt werden alle Modellelemente und deren Attribute aufgelistet. Für alle Objekte, die als graphische Figur im Diagramm auftauchen sollen, muss jeweils das Auswahlkästchen links markiert werden. Diese werden später als Knoten (Node) definiert. Objekte, die Beziehungen zwischen Objekten darstellen sollen, müssen die Auswahl in der Mitte erhalten und werden zu Connections. Die rechte Auswahl legt die Diagram Labels für die jeweiligen Attribute des Objekts an. Das bedeutet, dass diese Attribute in Form eines Textfeldes innerhalb der graphischen Figur angezeigt werden. In diesem Editor werden folgende Modellobjekte als Nodes definiert: Root, Definitions, Measure, Process, Synchnode, Hidenode, EmptyState, NormalState und StopState. Als Connections werden RateTransition, WeightTransition, RootProcessLink, SynchnodeProcessLink und HidenodeProcessLink angegeben. Als letzte Definition folgen die Diagram Labels für das Attribut actions bei Hide- und Synchnode, name bei Process und den States, system bei Root und parameter bei den ProcessLinks. Da im Editor je Objekt nur ein Label vorhanden sein soll, werden die anderen Attribute später im Mapping ergänzt. Nach diesen Definitionen erstellt der Assistent eine gmfgraph-datei mit den gegebenen Nodes, Connections und Labels. Diese stellt das graphische Modell des Editors dar und muss nun noch angepasst werden. Im Canvas befinden sind neben den Nodes, Connections und Labels (vgl. Abbildung 3.3 links) noch die Figure Gallery, welche die graphischen Figuren der jeweiligen Modellobjekte verwaltet. Für jeden Knoten kann man einstellen, ob und wie sein graphisches Objekt in der Größe verändert werden kann, indem man bei Resize Constraint die jeweiligen Himmelsrichtungen oder None wählt. Bei den Labels kann ein Symbol (links neben ihm) zur Ausgabe aktiviert werden. Typische Kindobjekte von Labels sind Alignment und Label Offset, die die Ausrichtung und den Startpunkt definieren. Als Beispiel ist das Label von RootProcess- Link zu nennen, bei dem Alignment auf CENTER und das Offset auf 0,0 gesetzt wurde. Damit wird der Parameter des RootProcessLinks mittig auf der Polyline Connection angezeigt. Es werden Compartments benötigt, mit denen es möglich ist, graphische Kindobjekte in den Vaterobjekten abzulegen. Wir benötigen für Definitions ein Compartment, damit das Objekt Measure in Definitions eingebunden wird. Dazu wird dem Canvas per Rechtsklick ein Compartment- Objekt hinzugefügt. Ihm wird als Name DefinitionsCompartment und als Figure der Descriptor der DefinitionsFigure zugewiesen. Das Selbe wird für Measure gemacht, da dort die verschiedene Leistungsmaße abgelegt werden sollen. Die Anbindung dieser Compartments erfolgt später im Mapping. In der Figure Gallery (vgl. Abbildung 3.3 rechts) kann man den jeweiligen Figure Descriptors ihr genaues Aussehen zuweisen. Mit Rechtsklick können ihm Kindobjekte zugewiesen werden, wie zum Beispiel für Root ein Rechteck. Dieses Rechteck erhält ein Stack Layout (Standardlayout, was keine weiteren Einstellungen benötigt) und ein Label SystemNameFigure, was später das Attribut system anzeigt. Der Child Access stellt die Verbindung zwischen Diagram Label des Canvas und dem Label des Objekts her. Das Rechteck kann in seiner Gestalt

47 3.3. DIE ERSTELLUNG DES EDITORS 39 über die Eigenschaften und Kindobjekte (per Rechtsklick) in Layout, Farbe und zusätzlichen Objekten verändert werden. Die Connections werden im jeweiligen Figure Descriptor als Poly- Abbildung 3.3: Ausschnitte aus der graphischen Definition des Modells (Bildschirmkopie) line Connections angelegt. Diese können in Linienart, -stärke und Farbe angepasst werden. Standardmäßig legt GMF für die Polyline Connections sogenannte Target Decorations an. Damit kann das Ende einer Verbindung in seiner Gestalt angepasst werden, wenn beispielsweise ein Kreis das Ende dekorieren soll. Alle Figures können Labels zugewiesen bekommen. Diese besitzen als Descriptor den der übergeordneten Figure, einen Namen und einen Standardtext. Durch die erwähnten Diagram Labels des Canvas können diese später im Mapping angesprochen werden. Nach Definition aller graphischen Elemente des Editors folgt nun die Definition der Werkzeuge Definition der Werkzeuge Zu der Definition der Werkzeuge (Tooling Definition) gehört vor allem die Palette, mit welcher der Benutzer im Editor die gewünschten Modellelemente zum Erzeugen auswählen kann. Es stehen weitere Werkzeuge in der Definition zur Verfügung, wie Menü-, Werkzeugleistenaktionen und Kontextmenüerweiterungen. Da diese in der verwendeten GMF-Version noch nicht funktionstüchtig waren, werden sie hier vernachlässigt.

48 40 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Wie bei der graphischen Definition unterstützt auch hier ein Assistent beim Anlegen der Werkzeugdefinition. Durch das Dashboard geschieht dies mittels Ableitung vom Domänenmodell. Wiederum wird CaspaSystem als Diagrammelement gewählt. Im nächsten Fenster kann die Auswahl der Knoten und Verbindungen, welche in der Toolbar erscheinen sollen, ausgewählt werden. Die linke Auswahl dient den Knoten und die rechte dementsprechend den Connections. Es wird Hidenode, Synchnode, Process, Rate, Weight, Constant, Statemeasure, Meanvalue und Throughputmeasure als Knoten bestimmt. Als Connections werden keine gewählt, diese werden manuell erzeugt. Nach dem Beenden des Assistenten wird die Palette erzeugt (vgl. Abbildung 3.4 links), die jetzt angepasst wird. Dazu wird ein Name für die Palette CaspaEditToolbar vergeben. Dieser werden per Rechtsklick drei Tool Groups (Gruppen von Werkzeugen) zugeteilt. Die Gruppen werden mit Definitions, Items und Links bezeichnet. Im Folgenden können die verschiedenen Creation Tools, die zum Erzeugen der Modellelemente genutzt werden, in die jeweiligen Gruppen per Drag&Drop gezogen werden. In der Gruppe Links werden per Rechtsklick die Kindobjekte RootLink, HidenodeLink und SynchnodeLink als Creation Tools erzeugt. Diesen werden die Kinder Small und Large Icon Bundle Image zugewiesen, die die Symbole für die entstehende Palette enthalten. Innerhalb der Tool Groups können des Weiteren Separatoren (Trennlinien) eingebracht werden, wie es in Definitions zur Separierung von den Werten und Leistungsmaßen geschehen soll. Das Ergebnis stellt Abbildung 3.4 rechts dar. Abbildung 3.4: Ausschnitte aus der Tool-Definition des Modells (Bildschirmkopie) Dem Leser sollte bereits aufgefallen sein, dass nicht alle Objekte des Modells in der Palette auftauchen. Das ist durchaus gewollt, da es später zu einer Trennung zwischen Prozess- und

49 3.3. DIE ERSTELLUNG DES EDITORS 41 Systemebene kommen soll. Sie wird durch zwei verschiedene Diagramme repräsentiert. Diese beiden Diagramme nutzen das selbe graphische Modell, benötigen aber unterschiedliche Werkzeugmodelle. Deshalb muss ein weiteres Werkzeugmodell für Prozess (process.gmftool) aus dem Domänenmodell erzeugt werden. Hier werden NormalState, EmptyState und StopState als Knoten und Weight- bzw. RateTransition als Connections gewählt. Für die Transitionen wird eine Gruppe erzeugt, deren Eigenschaft Stack auf wahr gesetzt wird. Damit wird eine aufklappbare Gruppe, aus der man später eins der beiden Elemente auswählen kann, erzeugt. Nach der Definition der Palette kann das Mapping definiert werden Definition des Mappings Das Mapping verbindet das Domänen-, Werkzeug- und graphische Modell miteinander. Das Dashboard unterstützt wiederum bei der Erzeugung durch Combine. Wie bereits bei der Werkzeugdefinition müssen auch hier zwei Mappings angelegt werden. Das Mapping für die Systemebene nutzt caspaedit.gmfgraph, caspaedit.ecore und caspaedit.gmftool. In der letzten Auswahl des Assistenten werden Nodes und Links definiert. Als Knoten sind bereits Synchnode, Hidenode, Root, Definitions und Process erkannt worden. Die Links werden auf die ProcessLinks sowie die hidenodes und synchnodes reduziert. Nach diesem Schritt wird ein Mapping angelegt, wie Abbilung 3.5 zeigt. Dieses erstellte Mapping wird nun im Folgenden Abbildung 3.5: Erstellte Mapping-Definition des Modells (Bildschirmkopie) angepasst. Als erstes werden die definierten Compartments aus dem graphischen Modell in das Mapping eingebunden. Dazu erzeugt man für das Node Mapping von Definitions das Kindobjekt Compartment Mapping. Als dessen visuelle Repräsentation wird DefinitionsCompartment genutzt. Im Folgenden werden Child References für Konstanten, Raten und Gewichte angelegt, die die Kindobjekte von Definition darstellen. Diesen werden die jeweiligen Node Mappings zugewiesen. Bei den Node Mappings werden als Elemente der Domänen-Meta-Information die Modellklassen verwendet. In der visuellen Repräsentation wird beim Diagrammknoten das

50 42 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG anzulegende Element angegeben. Bei Konstanten wird als Diagram Label ConstantName verwendet. Als Tool wird der Verweis auf den Paletteneintrag gemacht, der dieses Objekt erzeugen soll. Nach Anlegen der Child References können diese dem Compartment als Children zugewiesen werden. Damit beinhaltet das Objekt Definitions nun Raten, Konstanten und Gewichte, die auch nur innerhalb dieses Objekts erzeugt werden können. Als weiteres Kindobjekt wird Definitions noch das Modellobjekt Measure zugewiesen, welches wiederum ein Compartment (MeasuresCompartment) enthält. Diesem werden die Leistungsmaße als Kindobjekte unterstellt. Abbildung 3.6 zeigt das entstandene Mapping-Modell. Jeder Knoten besitzt ein Label Abbildung 3.6: Erstellung von Compartments und Kindknoten im Mapping (Bildschirmkopie) Mapping, welches das definierte Diagram Label aus dem graphischen Modell mit dem Knoten verknüpft. Mit dem Feature Label Mapping kann das Verhalten des Labels definiert werden. Dabei werden die Features (Modellattribute) gewählt, welche im Label dargestellt werden sollen. Über die verschiedenen Patterns wird die Darstellung und deren Bearbeitung festgelegt. Bei Konstanten dient als Edit-Pattern {0}={1} und als View-Pattern int {0}={1};. In den geschwungenen Klammern steht der Index des Attributes der Features-Liste. So muss beim Bearbeiten des Labels der Name gefolgt von = und dem Wert im Label eingegeben werden. Im Diagramm hingegen wird int name=value; angezeigt werden. Es stehen verschiedene Parser zur Verfügung, nachdem die Zeichenketten ausgewertet werden können. In diesem Fall wurde der MessageFormatParser verwendet, der auch in Java Anwendung findet. Dieser fordert die Syntax der oben genannten Muster zum Parsen der Zeichenketten. Weitere Parser, wie Native, Printf und Regexp, werden hier nicht betrachtet. Durch die Feature Seq Initializer ist man in der Lage, die Attribute eines Objekts bei der Erstellung zu belegen. Das erreicht man entweder durch OCL-Ausdrücke oder durch Java-Methoden, welche später implementiert werden müssen. Nachdem die Knoten im Mapping definiert wurden, folgt die Definition der Links. Durch das

51 3.3. DIE ERSTELLUNG DES EDITORS 43 Link Mapping werden die Connections aus dem graphischen Modell mit den Paletteneinträgen des Tool-Modells verbunden sowie die Modellattribute, welche die Links speichern, gewählt. Die Links der ProcessLinks erhalten ein Feature Label Mapping, um später die Parameter für diese Verbindung zwischen Knoten und Prozess anzeigen zu können. Mit dem Feature Seq Initializer wird eine Java-Methode aufgerufen, die den Parameter der Verbindung belegt. Wie Abbildung 3.7 zeigt, gibt es jeweils drei Links für Synchnodes, Hidenodes und Root. Die Begründung liegt auf der Hand, da die genannten Knoten jeweils mit Synchnodes, Hidenodes und Prozessen verbunden werden können. Es wird dadurch die Belegung der Attribute (synchnode und hidenode) anhand des gewählten Start- und Zielknotens gesteuert. Diese werden im Target Feature festgelegt. Als Besonderheit gilt zu nennen, dass alle Links beispielsweise von Synchnode mit dem selben Paletteneintrag Creation Tool SynchnodeLink erzeugt werden können. Bei den ProcessLinks wird als Element die jeweilige Modellklasse ausgewählt, welche diesen Link repräsentiert. Als Containment Feature wählt man das Attribut processlink des jeweiligen Objekts, damit dieses auf den Link zugreifen kann. Source und Target Feature dienen zum Besetzen der Quell- und Zielattribute des jeweiligen ProcessLinks. Als Connection in der visuellen Repräsentation muss auch die richtige Verbindung des graphischen Modells gewählt werden, beispielsweise Connection SynchnodeProcessLink. Die Link Mappings können durch Link Constraints erweitert werden, die deren Anlegen beschränken. Diese Constraints werden in OCL oder Java definiert. Um zu verhindern, dass ein Objekt mit sich selbst verbunden werden kann, würde man den OCL-Ausdruck: self<>oppositeend definieren. Abbildung 3.7: Definition der Link Mappings (Bildschirmkopie) Nach der Erstellung des Mapping-Modells durch den Assistenten muss überprüft werden, ob alle Tools und Diagram Links richtig angelegt worden sind, da hierbei teilweise das automatische Mapping in der verwendeten GMF-Version nicht fehlerfrei gearbeitet hat. Das Mapping der Prozessebene wird in gleicher Weise mit caspaedit.ecore, caspaedit.gmfgraph und process.gmftool 5 angelegt. Als Wurzelklasse beim Domänenmodell muss aber Process gewählt werden. Hierbei dienen NormalState, EmptyState und StopState als Nodes und Rate- 5 Mittels Select auf dem Dashboard als Tooling Def Model auswählen.

52 44 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Transition bzw. WeightTransition als Links. Bei den Transitionen müssen die Source- und Target Features jeweils auf die Attribute sourcestate und targetstate gesetzt werden. Des Weiteren wird als Diagram Link jeweils die richtige Connection aus der graphischen Definition gewählt. Bei einem NormalState wird der Name in erster Linie vom Vaterprozess mit Hilfe einer Java- Methode abgeleitet und durch Feature Seq Initializer belegt. Die Transitionen besitzen als Constraints Java-Methoden, die im Abschnitt näher betrachtet werden. Außerdem besitzen die Transitionen vier Parameter (action, assign, guard, rate oder weight), die im Label dargestellt werden. Im entsprechenden Initializer wird das Attribut isweight belegt, je nachdem welche Transition gesetzt wurde. Validierung der Modellkomponenten Im Mapping werden Constraints festgelegt, die unter anderem zur Validierung des Modells dienen. Damit wird das erstellte Modell des Benutzers im Diagrammeditor geprüft und verhindert, dass fehlerbehaftete Spezifikationen später mit dem Werkzeug Caspa ausgewertet werden. Dazu werden OCL-Ausdrücke und Java-Methoden genutzt, welche bereits im vorigen Abschnitt erwähnt wurden. Um sie festzulegen, fügt man dem Mapping den Knoten Audit Container hinzu. Diesem vergibt man einen Namen caspaedit und eine selbst gewählte ID (hier caspaeditauditcontainer ). Im Anschluß werden dem Audit Container die Audit Rules (Regeln) hinzugefügt. Jede dieser Regeln besitzt wiederum einen Namen und eine ID. Darüber hinaus kann man wählen, um welchen Schweregrad des Regelverstoßes (ERROR, WARNING, INFORMATION) es sich handelt, und eine dementsprechende Meldung erzeugen. Einer jeden Regel wird hier ein Domain Target Element (Zielelement des Modells) und ein Constraint als Kindknoten zugewiesen. Beim Target Element wählt man die entsprechende Modellklasse aus, für welche die Regel, definiert im Constraint, angewendet werden soll. Weitere Möglichkeiten zur Auswahl des Zielelements bestehen in Domain Attribute Target, bei dem direkt das Attribut gewählt werden kann, und Diagram Element Target, welches für Diagrammelemente geschaffen wurde. Einige Constraints im Diagrammeditor wurden in OCL formuliert. Dazu gehört unter anderem die Regel Processnamecheck, welche prüft, ob ein Prozessname systemweit eindeutig vergeben wurde. In OCL erfolgt die Umsetzung durch den Ausdruck aus Listing 3.1. Als Domain 1 self.processes->forall(p1, p2 p1<>p2 implies p1.name<>p2.name) Listing 3.1: Beispiel des OCL Ausdruckes Processnamecheck Target Element dieser Regel wurde CaspaSystem ausgewählt, da dieses alle Prozesse verwaltet. Mit dem Ausdruck self.processes wird auf diese Liste zugegriffen. Nun definiert man mit dem All-Quantors über dieser Liste: Wenn zwei Elemente nicht gleich sind (Objektvergleich mit Hilfe interner Objekt-ID), folgt daraus, dass sich deren Namen unterscheiden müssen. Sobald zwei verschiedene Prozesse den selben Namen besitzen, wird diese Regel bei der Validierung verletzt.

53 3.3. DIE ERSTELLUNG DES EDITORS 45 Obwohl die Sprache OCL zur Spezifikation von Constraints sehr gut geeignet ist, besteht zusätzlich die Möglichkeit, Java-Methoden und reguläre Ausdrücke dafür zu nutzen. Der Methodenname wird im Constraint der Regel definiert und durch das Erzeugen des Codes in der Klasse CaspaeditValidationProvider erstellt. Die Methode bekommt die gewählte Modellklasse (hier CaspaSystem) als Parameter übergeben und liefert einen booleschen Wert zurück. Die Implementierung dieser Funktionen obliegt dem Entwickler und wird im Abschnitt dieser Arbeit genauer betrachtet. Spezifische Regeln für die Prozessebene wurden in der process.gmfmap angelegt. Insgesamt wurden zur Validierung des Modells 40 Regeln definiert (sieben davon in OCL, die übrigen durch Java-Methoden). Auf der Systemebene wird somit sichergestellt, dass: Prozessnamen syntaktisch korrekt und nicht doppelt vergeben sind Prozessparameter syntaktisch korrekt und deren Maximalwerte definiert sind Korrektheit der Namen des Systems, der Konstanten, Raten und Gewichte sowie der Bezeichner der Leistungsmaße Anzahl und Korrektheit der Parameter der verschiedenen ProcessLinks Anzahl der Verbindungen für Synchnodes (mind. zwei) und Hidenodes (genau eine) Zyklenfreiheitstest aller verbundenen Knoten beginnend bei der Wurzel kein Name oder Bezeichner eine reservierte Zeichenkette von der Caspa-Syntax ist Auf der Prozessebene wird das Modell validiert, das heißt überprüft, ob: Zustandsnamen syntaktisch korrekt sind und bei gleichem Namen unterschiedliche Parameter besitzen die Anzahl der Parameter von Zuständen gleich der Anzahl der Parameter des Prozesses ist es mindestens einen Zustand gibt, der den Namen des Vaterprozesses trägt EmptyStates einen Folgezustand besitzen und es nur einen StopState gibt neu definierte Unterprozesse nicht doppelt vorhanden sind Raten und Gewichte der Transition definiert sind Der Zyklenfreiheitstest ist für den Editor von enormer Bedeutung, da bei einer Auswertung der Knoten ein Zyklus zwangsläufig zu einer Endlosschleife führen würde. Zyklen, die nicht direkt mit der Wurzel (Root) verbunden sind, werden ebenfalls erkannt und als Warnung ausgegeben. Da EmptyStates Übergänge mit zwei aufeinander folgenden Transitionen zwischen

54 46 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG zwei Zuständen sind, muss gewährleistet sein, dass ein EmptyState immer einen Folgezustand aufweist. Nachdem die beiden Mapping-Modelle erstellt wurden, kann im nächsten Schritt das Generatormodell erzeugt werden. Zuvor müssen die beiden Mapping-Modelle von System und Prozess verbunden werden, um später mit Doppelklick auf einen Prozessknoten die Prozessebene zu öffnen. Dazu wird im Mapping-Modell vom System (caspaedit.gmfmap) per Rechtsklick auf Load Resource... das Mapping-Modell von Prozess (process.gmfmap) hinzugefügt. Weiterhin wird im Modell des Systems im Node Mapping von Process unter Related Diagrams das zweite Canvas Mapping ausgewählt. Damit wird das Mapping-Modell von Prozess genutzt, wenn dessen Kindobjekte bearbeitet werden sollen Erzeugung und Anpassung des Generatormodells Aus dem Mapping-Modell caspaedit.gmfmap wird über das Dashboard mittels Transform das GMF-Generatormodell caspaedit.gmfgen angelegt. Wie Abbildung 3.8 zeigt, beinhaltet dieses Abbildung 3.8: Das erzeugte Generatormodell von GMF (Bildschirmkopie) neben Verknüpfungen zum Ecore-Modell und dem EMF-Generatormodell den Gen Editor Generator. In diesem Knoten können Eigenschaften des Editors angepasst werden. Beispielsweise der Paketpräfix (studium.da.caspaedit.diagram) für den generierten Code, die Diagrammdateiendung (ced) und die Serialisierung von Modell- (Domänenmodell) und Diagrammdaten (Notation Model) in einer gemeinsamen Datei. Im Gen Audit Root befinden sich die definierten Validierungsregeln. Unter dem Knoten Gen Diagram CaspaSystemEditPart befinden sich alle zu generierenden EditParts, welche aus der graphischen Definition (Nodes, Links, Compartments und Labels) gewonnen wurden. In dessen Eigenschaften muss die Validierung durch das Setzen von Validation Decorators und Validation Enabled auf true aktiviert werden. Mit Gen Plugin Caspaedit Plugin wird das zu generierende Plug-In spezifiziert. Dazu gehört der Name, die Activator Class und die Plug-In-ID, die auch den Paketpräfix erhalten muss. Der Knoten Gen Editor View spezifiziert die Editoransicht, welche in Eclipse durch den Diagrammeditor erzeugt wird. Die weiteren Knoten werden hier nur kurz genannt, aber nicht weiter betrachtet, da sie in der erzeugten Form den Anforderungen genügen. Der Navigator erzeugt einen

55 3.3. DIE ERSTELLUNG DES EDITORS 47 zusätzlichen Baumeditor, um die Objekte des Diagramms hierarchisch darzustellen. Updater wird zum Aktualisieren des Diagramms verwendet. Property Sheet definiert die einzelnen Seiten des Properties View des Diagramms. Im Gen Expression Provider Container werden die OCL-Ausdrücke und die Verweise auf Java-Methoden der Validierung abgelegt. Für die Prozessebene wird aus der process.gmfmap ebenfalls ein GMF-Generatormodell (process.gmfgen) erzeugt. Es bedarf nun einiger zusätzlicher Anpassungen in diesem Generatormodell, um die Trennung von System- und Prozessschicht zu gewährleisten. Unter dem Editor Generator wird der Paketpräfix auf studium.da.caspaedit.process.diagram und die Model ID auf Process abgeändert. Im Gen Plugin wird für die ID der Paketpräfix gesetzt. Das führt dazu, dass die Klassen der Prozessebene in ein eigenes Paket generiert werden. Nachdem diese Einstellungen getroffen worden sind, wird im Generatormodell des Systems unter Gen Diagram der Knoten ProcessEditPart gewählt. Als Kindknoten besitzt dieser ein Open Diagram Behaviour. Dieses Verhalten zum Öffnen zusätzlicher Diagramme wird später in der Klasse OpenDiagramEditPolicy erzeugt. Prozess ist der einzige Knoten, der diesen Unterknoten enthält, was durch die Anpassung im Mapping Related Diagrams von Prozess erreicht wurde. In den Eigenschaften dieses Knotens muss Diagram Kind mit Process (Model ID vom Prozess-Generatormodell) und Editor ID mit studium.da.caspaedit.process.diagram.part.- CaspaeditDiagramEditorID befüllt werden. Diese ID stammt aus dem Gen Editor View des Prozess-Generatormodells. Mit Hilfe dieser Anpassungen wird ein Editor erzeugt, der auf der Systemebene einen Prozess als Knoten anlegt. Wenn der Benutzer diesen doppelt anklickt, öffnet sich ein weiteres Diagramm, in dem die Kindelemente des Prozesses angelegt werden können. Die Abbildung 3.9 (links) zeigt alle Modelldateien, die für den Editor erstellt wurden und benötigt werden. Die Trace-Dateien werden beim Erzeugen des Generatormodells angelegt und enthalten die IDs der einzelnen Modellobjekte für das jeweilige Diagramm. Aus beiden Generatormodellen wird der Diagrammeditor mit Hilfe des Dashboardes erzeugt. Es werden zwei Pakete angelegt und mit den jeweiligen Klassen des Editors befüllt. Dabei enthält studium.da.caspaedit.diagram die Klassen der Systemebene und studium.da.caspaedit.process.- diagram die Klassen der Prozessebene. In Abbildung 3.9 (rechts) ist das entstandene Plug-In der Systemebene dargestellt. Sie zeigt die verschiedenen Pakete, die für den Editor angelegt worden sind. Im Weiteren werden die erzeugten Klassen innerhalb der Pakete genauer beleuchtet, bevor die Anpassungen im generierten Code beschrieben werden Die erzeugten Pakete und ihre Klassen Um den entstandenen Code zu strukturieren wird ein von Java unterstützter Paketmechanismus verwendet und verschiedene Pakete angelegt. Das Paket edit.commands enthält Klassen, die zur Erzeugung der Knoten und Links benötigt werden. Sie werden von der Klasse CreateElement- Command abgeleitet. Des Weiteren geben sie den Container im Diagramm sowie die Klasse im Modell zurück, in welchem das Objekt erzeugt werden soll. Sie definieren Constraints, die die Erzeugung eines Elements beschränken (canexecute). Die Klassen aus edit.helpers stel-

56 48 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Abbildung 3.9: Verzeichnisse des Editors [links:modelldateien, rechts: Plug-In] len Commands zum Bearbeiten zur Verfügung. Dazu zählen beispielsweise das Löschen, Duplizieren und Bewegen für jedes Element. Die Commands werden von der abstrakten Klasse AbstractEditHelper geerbt und können somit beliebig verändert werden. Das Paket edit.parts repräsentiert durch seine Klassen die eigentlichen EditParts. Zu ihnen zählt die EditPartFactory, welche auf die EditParts der einzelnen Objekte verweist. In den EditPart- Klassen der Elemente werden die EditPolicies mit createdefaulteditpolicies() installiert. Für alle definierten Objekte aus dem Mapping-Modell wird eine eigene EditPart-Klasse angelegt. Die Klassen der Labels erzeugen diese als graphische Objekte (Views - siehe unten), deren Text und Symbole sowie den Parser, der eingegebene Zeichenketten einliest und auswertet. Sie verwalten die direkte Bearbeitungsmöglichkeit und sorgen für das Neuzeichnen bei Änderung der Labelattribute. Die Listener 6 der Modellelemente werden angemeldet. Die EditParts der Compartments erzeugen diese als graphische Objekte und liefern deren Titel zurück. Für die Knoten werden Methoden zum Hinzufügen und Entfernen von Kindobjekten und Labels bereitgestellt. Weitere Methoden dienen dem Erstellen und Verändern der graphischen Repräsentation der Knotenobjekte. Für Links werden die Polyline Connections mit deren Target Decorations erstellt. Optionale Labels werden als Kindobjekte mit den Links verbunden. Im Paket edit.policies werden die Richtlinien für das Editieren der EditParts geregelt (siehe Abschnitt 2.4). Für alle registrierten EditPolicies in den EditParts wird eine Klasse angelegt, die dann die jeweilige Klasse aus dem Paket commands aufruft. GMF verwendet im Vergleich zu 6 Die Listener reagieren auf Änderungen am graphischen oder semantischen Modell und werden genutzt, um diese weiterzuleiten.

57 3.3. DIE ERSTELLUNG DES EDITORS 49 GEF zusätzliche EditPolicies 7. Die SemanticEditPolicy ermöglicht die Erstellung und das Aktualisieren semantischer Modellelemente. Sie wird standardmäßig überschrieben und für die benötigten EditParts angepasst. Die sogenannte CanonicalEditPolicy verwaltet die semantischen Kindobjekte eines Modellobjekts und die Connections zwischen ihnen. Sie wird benötigt, um diese zu synchronisieren und zu aktualisieren, falls Änderungen am Modell auftreten. Die oben erwähnte OpenDiagramEditPolicy wurde erzeugt, um das Öffnen der Prozessebene zu ermöglichen. Weitere EditPolicies werden in diesem Editor nicht verändert und besitzen damit das Standardverhalten, was durch GMF vorgegeben ist. Das Paket diagram.part definiert den Diagrammeditor, das Plug-In (DiagramEditorPlugin), welches diesen zur Verfügung stellt, und eine Klasse mit benötigten Editorfunktionalitäten (DiagramEditorUtil), in der z.b. das Anfangsmodell (createinitialmodel()) und das Öffnen von Diagrammen festgelegt wird. In der DocumentProvider-Klasse wird das gesamte Modell auf ein Dokument abgebildet und konsistent gehalten. Weitere Klassen dienen der Erstellung der Palette, stellen Assistenten zur Erstellung neuer Modelle bereit und implementieren verschiedene Aktionen des Menüs. Die VisualIDRegistry verwaltet anhand der ID (Identifier - Bezeichner), welches graphische Objekt zu welchem Modellelement gehört. Ein weiteres Paket stellt diagram.providers dar. In ihm werden unter anderem Funktionalitäten aus dem Mapping realisiert. Dazu gehören zum Beispiel: Initialisieren der Elemente (vgl. Feature Seq Initializer) - Klasse ElementInitializers Validierung (Audit Container) - Klasse ValidationProvider Parsen (Feature Label Mapping) - Klasse ParserProvider Action Bars und Connection Handles (vgl. Grundlagen GMF) - Klasse ModelingAssistentProvider Verbindung zwischen EditParts und Views anhand der ID - Klasse ViewProvider Das Paket diagram.view.factories stellt für alle Modellelemente abhängig vom Typ (Knoten, Kante oder Diagramm) die graphische Repräsentation (View-Schicht) zur Verfügung. Die Edit- Parts erstellen diese mit ihren Eigenschaften (Stil und Layout), in dem sie auf deren ViewFactory zurückgreifen. Das Paket diagram.expressions dient zum Auswerten von OCL- und regulären Ausdrücken, die in den Constraints verwendet werden. Die verschiedenen Parser für die Labels werden in diagram.parsers umgesetzt. Einstellungen, die in der Eclipse-IDE unter Preferences speziell für diesen Editor getroffen werden können, sind im Paket diagram.preferences implementiert. Dabei werden verschiedene Seiten erstellt, die Einstellungen zu Farben, Connections, Lineal, Hintergrundgitter und mehr ermöglichen. Der Properties-View von Eclipse wird durch das Paket diagram.sheet für den Editor angepasst und erweitert. So werden mehrere Seiten dafür geschaffen, welche sich durch Tabs wechseln lassen. 7 Die EditPolicies von GEF werden in den Superklassen der EditParts standardmäßig definiert und können bei Bedarf geändert werden. Jeder EditPart nutzt die Methode super.createdefaulteditpolicies().

58 50 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Außer den Paketen wurden für das Plug-In, wie in Abschnitt 2.8 erläutert, die Manifest.mf, plugin.xml und plugin.properties erzeugt, die das Plug-In und dessen Erweiterungspunkte definieren. In der Datei messages.properties wurden sämtliche Zeichenketten, wie Titel, Beschreibungen und Fehlermeldungen ausgelagert, um sie dort bearbeiten zu können und die Internationalisierung des Editors an einem Punkt zu ermöglichen Anpassungen im generierten Code Im Grundlagen-Kapitel wurde erwähnt, dass GMF ein Grundgerüst für einen Diagrammeditor schafft, welches sich am semantischen Modell orientiert. Durch die Definition des graphischen, Werkzeug- und Mapping-Modells wird dem Entwickler eine Menge Arbeit abgenommen. Dieser Abschnitt soll dem Leser verdeutlichen, wie man den generierten Editorquellcode nach seinen eigenen Vorstellungen anpassen kann, um die Arbeit mit dem Editor zu verbessern. Dabei werden Verweise auf die jeweiligen Klassen in den Paketen gegeben und die Methoden erläutert, teilweise geschieht dies durch Quellcodeauszüge. So müssen Constraints zur Validierung des Modells, welche durch Java-Methoden realisiert werden sollen, nun implementiert werden. GMF bereitet diese Arbeit vor, indem es die Methodenköpfe und deren Aufruf aus dem Framework bereits generiert. Die Methoden zur Validierung befinden sich in der Klasse CaspaeditValidationProvider aus oben genanntem Paket. Sie enthält eine statische Klasse JavaAudits mit den generierten Methoden. Ein Beispiel zeigt das Listing 3.2. Diese Methode soll die Gültigkeit des Prozessnamens prüfen. Dazu wird das 1 /** 2 3 */ 4 private static Boolean namecheck(process self) { 5 // TODO: implement this method 6 // Ensure that you or mark NOT 7 throw new CaspaeditAbstractExpression.NoImplException( 8 "No user java implementation provided in namecheck operation"); //$NON-NLS-1$ 9 } Listing 3.2: Die generierte Methode namecheck für das Objekt Tag, die Kommentare und die Exception in der Methode entfernt. Als Parameter bekommt die Methode, wie im Mapping definiert, ein Objekt Process, welches getestet werden soll. Das Listing 3.3 zeigt die Anpassung der Methode. Es wird der Prozessname mit Hilfe der 1 private static Boolean namecheck(process self) { 2 return self.getname().matches("[a-za-z][a-za-z_0-9]*")&isnamenotreserved(self.getname()); 3 } Listing 3.3: Die angepasste Methode namecheck für das Objekt Process Funktion getname() geholt und mit der Java-Funktion matches mit dem regulären Ausdruck geprüft. Dieser Ausdruck sieht vor, dass ein Prozessname mit Klein- oder Großbuchstabe

59 3.3. DIE ERSTELLUNG DES EDITORS 51 beginnt und dann mit Buchstaben, Zahlen und _ fortgesetzt werden kann. Weiterhin wird geprüft, ob der Name keine reservierte Zeichenkette der Caspa-Syntax ( int, rate, weight und weitere) darstellt. Als nächstes wird die Umsetzung des Zyklenfreiheitstestes für die verbundenen Knoten der Systemebene vorgestellt. Die Methode cycliccheck bekommt als Argument die Wurzel des Systems. Nachdem bestimmt wurde, ob ein Synch- oder Hidenode mit ihr verbunden ist, wird die Tiefensuche 8 ab diesem Knoten begonnen. Dabei werden besuchte und bereits abgearbeitete Knoten in einer Liste abgelegt. Abgearbeitet ist ein Knoten dann, wenn er keine Nachfolger mehr besitzt. Diese Funktion wird rekursiv auf jeden gefundenen Nachfolger eines Knotens aufgerufen. Dies erfolgt, bis alle Knoten abgearbeitet sind oder ein Knoten zweimal besucht wurde. Zur Unterscheidung der verschiedenen Typen von Knoten wurde der systemweit eindeutige Hashcode dieser Objekte verwendet. Um auch nicht mit der Wurzel verbundene Zyklen zu finden, wurde diese Methode auch für Synch- und Hidenodes zur Validierung genutzt. Damit kann dem Benutzer frühzeitig eine Warnung gegeben werden. Diese beiden Beispiele sollen zur Validierung genügen. Es wurden alle weiteren Validierungsmethoden der Systemebene innerhalb dieser Klasse implementiert. Die Prozessebene verfügt ebenfalls über eine solche Klasse, die die Validierungsregeln aus dem Prozessmapping enthält. In der Klasse BaseItemSemanticEditPolicy werden die oben erwähnten Constraints für die Transitionen definiert. Sie enthält eine statische Klasse Java- Constraints, in der die Methodenköpfe wiederum vorbereitet worden sind. In der Methode transitionconstraint werden die Beschränkungen für das Anlegen einer Transition festgelegt. So kann eine Transition keinen StopState als Quelle und keinen EmptyState besitzen, der bereits selbst Quellzustand einer vorhandenen Transition ist. Somit wird verhindert, dass ein EmptyState mehrere ausgehende Kanten erhalten kann. Mit Java-Methoden ist es leichter, komplizierte Validierungsregeln zu implementieren, weil man bequemer innerhalb der modellierten Klassenstruktur navigieren kann und vorhandene Java-Methoden nutzbar sind. Als Beispiel hierfür gilt die Prüfung, ob verwendete Raten einer Transition auch in den Definitionen definiert sind. Im Mapping wurden die Parameter der ProcessLinks mit Hilfe der Feature Seq Initializer vorbelegt. Diese Belegung soll durch die Java-Methode getprocessparameter realisiert werden. Während der Codegenerierung wurde diese Methode in der Klasse ElementInitializers als Gerüst angelegt. Listing 3.4 zeigt deren Implementation. Jeder ProcessLink besitzt eine Referenz auf den verbundenen Prozess. Dessen Anzahl der Parameter wird in der Variable size abgelegt. Schließlich wird über die gesamte Menge der Parameter des Prozesses iteriert und deren Maximalwerte an die Ergebniszeichenkette getrennt durch Komma angehängt. Damit wird erreicht, dass der ProcessLink, der die Parameter für den Prozess, der synchronisiert werden soll, speichert, bereits vorinitialisiert ist und somit dem Benutzer eine Hilfe bietet. Da jedes CaspaSystem genau ein Objekt Definitions und ein Objekt Root enthält und auch benötigt, werden diese bei der Initialisierung des Modells angelegt. Dazu wird die Methode 8 Die Tiefensuche ist ein Algorithmus aus der Graphentheorie, der einen gerichteten Graphen vom Startknoten aus immer den ersten Nachfolgeknoten folgend bis in die Blätter durchsucht. Eine modifizierte Variante kann genutzt werden, um einen Zyklus zu finden. Ein Zyklus liegt vor, wenn es einen Kantenzug gibt, dessen Start- und Zielknoten gleich ist. Die Implementierung erfolgte gemäß [22, Zyklus_%28Graphentheorie%29].

60 52 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG 1 private static String getprocessparameter(synchnodeprocesslink self) { 2 int size = self.getprocess().getparameters().size(); 3 String erg = ""; 4 for (int i = 0; i < size; i++) { 5 if (i!= 0) erg = erg.concat(", "); 6 erg = erg.concat(integer.tostring(self.getprocess().getparammax(i))); 7 } 8 return erg; 9 } Listing 3.4: Die Methode getprocessparameter für das Objekt SynchnodeProcessLink createinitialmodel() angepasst. In der generierten Methode wird lediglich das Caspa- System angelegt und zurückgegeben (vgl. Listing 3.5). Das Listing 3.6 zeigt die angepasste Me- 1 /** 2 3 */ 4 private static CaspaSystem createinitialmodel() { 5 return CaspaeditFactory.eINSTANCE.createCaspaSystem(); 6 } Listing 3.5: Die generierte Methode createinitialmodel() aus der Klasse DiagramEditorUtil thode. Das CaspaSystem wird ebenfalls erzeugt, aber in der Variable sys zwischengespeichert. Im Anschluß wird eine neue Instanz von Definitions erzeugt und als def abgelegt. Die erzeugte Instanz von Root bekommt den Name Systemname und wird dann dem CaspaSystem per sys.setroot(root) zugewiesen. Die Instanz von Definitions, der ein neu erstelltes Objekt 1 private static CaspaSystem createinitialmodel() { 2 CaspaSystem sys = CaspaeditFactory.eINSTANCE.createCaspaSystem(); 3 Definitions def = CaspaeditFactory.eINSTANCE.createDefinitions(); 4 Root root = CaspaeditFactory.eINSTANCE.createRoot(); 5 root.setsystem("systemname"); 6 sys.setroot(root); 7 def.setmeasures(caspaeditfactory.einstance.createmeasure()); 8 sys.setdefinitions(def); 9 return sys; 10 } Listing 3.6: Die erweiterte Methode createinitialmodel() Measure zugeordnet wurde, wird dem CaspaSystem hinzugefügt. Nun kann dieses erweiterte System zurückgegeben werden. Bei der Erstellung eines neuen Diagramms werden ab diesem Moment immer oben genannte Instanzen hinzugefügt, deshalb wurde auf diese Elemente in der Palette des Editors verzichtet. Da diese Elemente nicht erneut vom Benutzer erzeugt werden können, muss deren Entfernen aus dem Diagramm verhindert werden. Wie bereits erwähnt, kontrollieren die EditParts die Interaktion zwischen dem Modell und visueller Repräsentation mittels EditPolicies. Dementprechend muss die Methode createdefaulteditpolicies() im jeweiligen EditPart angepasst werden. Als Beispiel wird der EditPart von Root gewählt. In dieser Methode wird

61 3.3. DIE ERSTELLUNG DES EDITORS 53 1 installeditpolicy(editpolicyroles.creation_role, 2 new CreationEditPolicy() { 3 public Command getcommand(request request) { 4 if ((request instanceof GroupRequest) && (request.gettype().equals("delete"))) 5 return UnexecutableCommand.INSTANCE; 6 if (understandsrequest(request)) return super.getcommand(request); 7 return null; 8 } 9 }); Listing 3.7: Die Erweiterung der Methode createdefaulteditpolicies() eine CreationEditPolicy, wie Listing 3.7 zeigt, angelegt und die vorhandene aus der Oberklasse damit überschrieben. Will der Benutzer dieses Objekt entfernen, wird über diese EditPolicy der Befehl zum Entfernen (getcommand) aufgelöst. Falls der Typ des Requests der Zeichenkette delete entspricht, handelt es sich um den Request das Objekt zu entfernen, der immer als GroupRequest ausgelöst wird. In diesem Fall wird ein UnexecutableCommand (nichtausführbarer Befehl) zurückgegeben. Andere Requests bleiben unbehandelt und werden an die Oberklasse übergeben. Der Menüpunkt Delete from Model wird damit im Kontextmenü 9 grau hinterlegt und somit deaktiviert. Dieser Menüpunkt kann über die plugin.xml entfernt werden, was im nächsten Unterabschnitt gezeigt wird. In den erzeugten Modellklassen wurden ebenfalls Änderungen unternommen, um bestimmte Funktionalitäten zu erreichen. Wie bereits erwähnt, verfügt beispielsweise der Prozess über die beiden Instanzvariablen parameter (Zeichenkette) und parameters (Liste). Der Benutzer gibt die Parameter des Prozesses im Editor, getrennt durch ein Komma, ein. Die Methode setparameter in der Klasse ProcessImpl wurde so geändert, dass bei jeder Änderung die Liste parameters neu gesetzt wird. Dazu wird die Java-Funktion split(",") auf parameter angewendet und gibt eine Liste der einzelnen Werte zurück. Diese wird nach Löschen von Leerzeichen in der Variable parameters abgelegt. Diese Liste von Parametern ermöglicht später in der Implementierung einen einfacheren Zugriff auf einen bestimmten Index (als in einer unformatierten Zeichenkette). Jedes Objekt, welches über die beiden Variablen verfügt, wurde dementsprechend angepasst. Für Prozesse wurden weitere Methoden implementiert, die: 1. den Parameter oder auch den Maximalwert an einem bestimmten Index zurückgeben, 2. den StopState finden, 3. Unterprozesse mit anderem Namen sowie deren Definitionszustand der Parameter finden. Zusätzliche Methoden für Zustände (in StateImpl) liefern: 1. den Bezeichner eines Parameters (vom Prozess), 2. Auskunft, ob ein Parameter gesetzt ist (mit Zahlwert belegt) oder nicht, 3. den Maximalwert des Parameters (laut Prozess), 4. die Möglichkeit verbundene Transitionen zu informieren, dass sich die Parameter des Zustands geändert haben. Diese Methoden werden von verschiedenen Funktionalitäten des Editors, wie Validierung, Import und Export (siehe Abschnitt 3.4.1, 3.4.2) benötigt. Eine besondere Änderung wurde bei den Transitionen eingeführt. Die Assigns (Zuweisungen) und Guards (Wächter) sind nur unter bestimmten Parametern der verbundenen Zustände nötig. Assigns weisen dem Parameter des Zielzustands einen Wert zu, falls dieser noch nicht gesetzt wurde. Sie werden im Label der Transition durch Komma getrennt angegeben: a:=1, b:=2. 9 Kontextmenü ist ein Menü, welches erscheint, wenn man ein Objekt rechts anklickt.

62 54 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Es werden alle Parameter des Zielzustands betrachtet und eine Liste mit den benötigten Zuweisungen erstellt. Falls eine Zuweisung vom Benutzer nicht spezifiziert wurde, setzt das System automatisch a:=a für den Parameter a ein. Wenn er unbenötigte Zuweisungen eingibt, werden diese verworfen. Dies wurde in der Methode setassign der Klasse TransitionImpl umgesetzt. Auch hier wurde mit jeweils einer Variablen für Zeichenkette und Liste gearbeitet. Ähnlich verhält es sich bei den Wächtern. Diese werden nach den Parametern des Quellzustands benötigt. Sobald ein Parameter davon gesetzt ist, wird kein zusätzlicher Wächter mehr benötigt, da dieser Wert ihn bezeichnet. Es können aber durchaus zusätzliche Wächter für vorhandene Parameter angegeben werden. Ist kein Parameter gesetzt und der Benutzer hat keinen Wächter spezifiziert, so wählt das System automatisch den *. Somit kann die Transition immer feuern. Die geänderte Methode heißt setguard. Wie erwähnt, informiert ein Zustand die Menge seiner verbundenen Transitionen bei einer Änderung. Somit bleiben die Transitionen immer konsistent. Die Umsetzung dieser Wächter und Zuweisungen in Caspa-Eingabedateien erfolgt im Abschnitt 3.4.1, der sich mit dem Exportieren von Diagrammen nach Caspa beschäftigt. In der Klasse ModelingAssistantProvider wurden die zu erzeugenden Typen für die Actions- Bars (auch PopupBars) angepasst. Die Methode gettypesforpopupbar liefert die Typen für den jeweiligen EditPart. In den Definitionen wird keine Aktion zum Anlegen des Objekts Measure mehr benötigt, demzufolge wurde diese Zeile einfach auskommentiert. Das Gleiche wird für den CaspaSystemEditPart im Bezug auf Definitions und Root unternommen. Diese Elemente werden bei der Initialisierung des Diagramms erstellt und können nicht gelöscht werden. Daraus ergibt sich, dass deren Erstellung nicht mehr benötigt wird. Ein Synchnode hat zwei verschiedene Attribute für seine Aktionen. Das Attribut actions beinhaltet die Zeichenkette der Aktionen getrennt durch Komma. Bei actionsoutput wurde immer ein Zeilenumbruch bei einem Komma nach mindestens 50 Zeichen eingebaut, damit der Knoten in seiner graphischen Ausdehnung die Übersichtlichkeit des Diagramms wahrt. Um dies zu erreichen, musste die Methode setactions() aus der Klasse SynchnodeImpl geändert werden, sodass bei jeder Änderung von actions dieser Zeilenumbruch erfolgt und in actionsoutput abgelegt wird. GMF verfügt zwar über Labels mit automatischen Zeilenumbrüchen, diese werden jedoch nach der Breite und nicht nach bestimmten Zeichen durchgeführt. Normalerweise wird ein Parser verwendet, um eine Liste von Attributen nach einem Pattern zu parsen. Da aber nur das eine Attribut (actions) bearbeitet und das andere (actionsoutput) nach Formatierung angezeigt werden soll, musste die Methode createsynchnodeactions_5001parser() verändert werden (siehe Listing 3.8). Nach Erstellung der Listen mit den jeweiligen Attributen wurden zwei MessageFormatParser mit den jeweiligen Patterns erzeugt und über einen CompositeParser miteinander verknüpft. Diese Umsetzung musste erfolgen, da sonst die direkte Editierfunktion des Labels nicht mehr unterstützt worden wäre. Das ist auf die interne Verwendung der Parser durch GMF zurückzuführen. Das gleiche Problem tauchte bei den Zuständen auf, bei denen sowohl Name und Parameter angezeigt, aber nur die Parameter über das Label änderbar sein sollen. Auch hier wurde das Problem durch die Verknüpfung zweier MessageFormatParser gelöst. Eine weitere Implementierung war nötig, um den baumartigen Outline-View 10 funktionstüchtig 10 Der Outline-View steht im Editor zur Verfügung und bietet neben einer graphischen auch eine baumartige Übersicht alle Elemente des Modells an.

63 3.3. DIE ERSTELLUNG DES EDITORS 55 1 EAttribute[] features = new EAttribute[] {CaspaeditPackage.eINSTANCE.getSynchnode_Actions(), 2 CaspaeditPackage.eINSTANCE.getSynchnode_ActionsOutput(), }; 3 EAttribute[] features1 = new EAttribute[] { CaspaeditPackage.eINSTANCE.getSynchnode_Actions() }; 4 MessageFormatParser reader = new MessageFormatParser(features); 5 reader.setviewpattern(" synchronize with \n {1}"); 6 reader.seteditorpattern("{0}"); 7 MessageFormatParser writer = new MessageFormatParser(features1); 8 writer.seteditpattern("{0}"); 9 return new CompositeParser(reader, writer); Listing 3.8: Die Anpassung des Parsers für SynchnodeActions() zu bekommen. Standardmäßig wird für diese Ansicht von allen Objekten das Attribut name verlangt und dann angezeigt. Da das Attribut im Modell bereits verwendet wurde und nicht aussagekräftig genug war, wurde auch diese Ausgabe angepasst. Dazu wurde die Methode getoutlinevieweditpartfactory() in der Klasse CaspaeditDiagramEditor neu implementiert, da sie normalerweise nur von der Oberklasse zur Verfügung gestellt wird. Der Outline-View benutzt einen Tree- und einen TreeDiagramEditPart zum Erzeugen des Baumes. Diese beiden Klassen wurden neu im Paket edit.parts mit dem Präfix Own angelegt und von den originalen Klassen abgeleitet. Überschrieben wurden die beiden Methoden gettext() und getimage(), die jeweils Text und Symbol für die einzelnen Elementen holen. Es wurde innerhalb von gettext nach den EditParts unterschieden und dementsprechend der Text gesetzt. Die Methode getimage bekommt das Symbol aus der gleichnamigen Methode der Klasse CaspaeditElementTypes, die die Symbole für die Elemente bereitstellt. Weitere Anpassungen sind von geringerer Bedeutung und werden hier nicht angesprochen. Sie sind jedoch im Quelltext zu finden und zeilenweise kommentiert, um weiteren Entwicklern die Einarbeitung in dieses Projekt zu ermöglichen. Anpassung der Plug-In-Dateien des Editors Wie in den Grundlagen im Abschnitt 2.8 genannt, werden mit der plugin.xml Erweiterungspunkte und Erweiterungen vorhandener Plug-Ins definiert. Durch diese Spezifizierung ist man in der Lage, die Oberfläche von Eclipse anzupassen. Eclipse verfügt über einen Plug-In-Manifest- Editor, der die Definition vereinfacht. Dieser öffnet sich automatisch durch das Öffnen der plugin.xml. Unter dem Reiter Extensions werden die Erweiterungen des Plug-Ins angezeigt und können dort bearbeitet werden. Dort sind beispielsweise der Editor, die Assistenten, die Constraints der Validierung sowie die Commands und deren Verknüpfung mit Tastenkombinationen abgelegt. Bestimmte Erweiterungspunkte wurden angepasst, um das Verhalten des erzeugten Editors zu verändern. Von GMF wurde eine Menüaktion zur Validierung in der Menüleiste unter Diagram angelegt. Da der Editor im Kontextmenü des Diagramms ebenfalls einen Eintrag zur Validierung erhalten soll, wurde unter common.ui.services.action.contributionitemproviders der GMF Runtime Erweiterung ein weiterer Unterknoten contributionitemprovider eingefügt. Dieser erhält die Klasse CaspaeditValidationProvider als Eigenschaft. Um auf das Kontextmenü des Diagramms

64 56 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG zu verweisen, wird ein Unterknoten popupcontribution mit der Klasse org.eclipse.gmf.runtime.diagram.ui.providers.diagramcontextmenuprovider erzeugt. Dem Knoten popupcontribution weist man eine popupaction mit der ID validateaction und dem Pfad /additions- Group zu und so bekommt der Editor diesen Eintrag mit gewünschter Aktion in seinem Kontextmenü. Dieser Erweiterung des Kontextmenüs können weitere Aktionen hinzugefügt werden. Dies wird beispielsweise benötigt, um einer Verbindung zwischen zwei Knoten im System, die keinen ProcessLink darstellt, die Aktion Delete zuzuweisen, die standardmäßig da nicht vorgesehen ist. Dazu wird ein neuer contributionitemprovider angelegt, der als Klasse diesmal DiagramContributionItemProvider (selber Präfix wie ContextMenuProvider) zugewiesen bekommt. Auch ihm wird ein Unterknoten popupcontribution mit der selben Klasse wie oben zugefügt. Nach Hinzufügen einer popupaction mit ID delete und Pfad /editgroup muss diese Aktion noch für einen bestimmten EditPart beschränkt werden. Das geschieht durch den Unterknoten popupstructuredcontributioncriteria, der als Objektklasse HidenodeHidenode- EditPart (mit vollständigem Paketnamen als Präfix) erhält. Somit kann die Verbindung zweier Hide-Knoten über das Kontextmenü entfernt werden. Durch Erstellung weiterer popupcontributions mit der selben Klasse wurde die Aktion deletefrommodelaction als popuppredefineditem für bestimmte EditParts (Root-, Definitions-, MeasureEditPart und weitere) entfernt. Weitere vordefinierte Aktionen des Kontextmenüs, die nicht benötigt werden (View-, Add-, NavigateGroup, deletefromdiagramaction und andere), wurden ebenfalls auf diese Art deaktiviert. In der plugin.xml der Prozessebene legt GMF automatisch Erweiterungspunkte an, die für Prozesse in diesem Editor nicht zusätzlich gebraucht werden. Dazu zählen die ui.actionsets mit den Aktionen Initialize process diagram file aber auch Open..., Open URI..., Process Diagram und Process Diagram About. Sie werden entfernt, da der Prozesseditor einen Untereditor darstellt. Für die zusätzlichen Funktionalitäten aus Abschnitt 3.4 werden Aktionen in die Menüleiste ebenfalls mit Hilfe der plugin.xml eingebracht. Diese Schritte werden dort genauer erläutert. Nachdem die Erweiterungspunkte definiert worden sind, kann der angepasste Editor genutzt werden Eclipse Plug-In vs. Rich Client Platform Alle beschriebenen Schritte führen zu einem Editor, der als Erweiterung für die Entwicklungsumgebung Eclipse gedacht ist. Mittels einer neuen Ausführungskonfiguration, die unter Open Run Dialog... gewählt wird, kann das Plug-In ausgeführt werden. Dazu erzeugt man eine neue Konfiguration einer Eclipse Application, bei der org.eclipse.sdk.ide als Produkt ausgeführt werden soll. Weitere Einstellungen müssen in diesem Moment nicht getroffen werden. Damit wird die komplette IDE von Eclipse ausgeführt. Im Package Explorer wird ein neues Java-Projekt mit beliebigem Name angelegt. Es wird zur Speicherung der Modell- und Diagrammdateien benötigt. Durch einen Rechtsklick auf den Projektordner kann man über New / Examples... mittels eines Assistenten ein neues Caspaedit Diagramm erstellen. Alle Funktionalitäten sind in diesem Editor vorhanden. Anfänglich wurde diese Art des Editors verwendet,

65 3.3. DIE ERSTELLUNG DES EDITORS 57 da die RCP Unterstützung von GMF noch nicht vollständig funktionierte (vgl. Abschnitt 3.3.8). Sie hat den schwerwiegenden Nachteil, dass jeder Benutzer des Editors die komplette IDE von Eclipse zur Verfügung haben muss. Außerdem werden Funktionen durch die IDE angeboten, die für den Editor ungeeignet sind. Dazu gehört die Möglichkeit, Projekte zu kompilieren und auszuführen, was aus den JDT stammt. Wie im Kapitel Grundlagen beschrieben, wird dies durch die Entwicklung der Rich-Client-Platform verhindert, in die nur noch relevante Erweiterungen eingebunden werden. Da die Vorteile dieser Plattform überwiegen, wurde ab dem Zeitpunkt der überzeugenden Unterstützung von RCP durch GMF der Entwicklungsprozess des Editors vollkommen auf diese Art umgestellt. Um dies zu erreichen, waren verschiedene Anpassungen nötig, die im Folgenden aufgezeigt werden. Bei der Umwandlung des Mapping-Modells wird auf dem Dashboard das Kontrollkästchen für RCP aktiviert. Damit werden bei der Erzeugung des Generatormodells zusätzliche Anteile generiert. Am besten kopiert man das vorhandene Generatormodell (z.b. nach caspaedit_rcp.gmfgen), in welchem dann das RCP-Generatormodell angelegt wird. Damit werden die Änderungen, die man bereits getätigt hat, nicht verworfen. Sonst müssen alle Schritte aus Abschnitt mit dem neuen Generatormodell wiederholt werden. Im erzeugten Generatormodell wurde der Paketpräfix auf studium.da.caspaedit.diagram.rcp geändert, um den entstehenden Code in einem getrennten Paket zu erhalten. Der Grund besteht darin, dass sich der Code des Editor-Plug-Ins unterscheidet und nicht ohne Weiteres zu einer RCP Anwendung angepasst werden kann. Im erzeugten Generatormodell ist der Knoten Gen Navigator entfernt worden, da dieser in RCP noch nicht zur Verfügung steht, und ein neuer Knoten Gen Application entstanden. In diesem Knoten können die Klassen und die ID der zu erstellenden Application spezifiziert und die Menü- und Werkzeugleistenstruktur beliebig geändert werden. Nachdem die Generatormodelle für System- und Prozessebene angelegt worden sind, kann aus beiden jeweils ein Diagrammeditor erzeugt werden. Die angepassten Java-Methoden aus Abschnitt können einfach aus dem Quellcode des Plug-Ins kopiert und in den neu erzeugten Code eingepflegt werden. Bei der Erzeugung des Editors wurde ein neues Paket diagram.application erstellt. Es enthält die Klassen, die aus den Informationen aus dem entsprechenden Knoten des Generatormodells gewonnen wurden. Die Klasse CaspaeditApplication ist für die Ausführung der gesamten Anwendung zuständig. Sie wurde in die plugin.xml unter org.eclipse.core.runtime.applications als Application vermerkt, steht damit in Eclipse als solche zur Verfügung und kann in der Ausführungskonfiguration ausgewählt werden. In der Klasse DiagramEditorActionBarAdvisor werden die Menü- und Werkzeugleiste sowie zusätzliche Aktionen definiert. Diese Spezifizierung von Aktionen wird später im Abschnitt 3.4 noch einmal aufgegriffen. Zum Erstellen einer eigenen Perspektive (vgl. Abschnitt 2.8) dient die Klasse DiagramEditorPerspective, in der das Layout so angepasst wurde, dass Outline- und Properties-View sich im unteren Bereich des Editors befinden. Die Perspektive wird durch die Klasse DiagramEditorWorkbenchAdvisor initialisiert. Sie dient ebenso zum Speichern der Eigenschaften der Workbench, damit der Benutzer den Editor nach einem Neustart wieder so vorfindet, wie er ihn verlassen hat. Die Workbench besteht aus verschiedenen Fenstern, welche unterschiedliche Menü- und Werkzeugleisten besitzen. Durch die Klasse DiagramEditorWorkbenchWindowAdvisor werden die definierten Leisten aus oben genannter Klasse dem Fenster zugewiesen.

66 58 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Zum Starten dieser Anwendung muss die Ausführungskonfiguration angepasst werden. Nach Auswahl der CaspaeditApplication in Program to Run werden die benötigten Plug-Ins unter dem Reiter Plug-Ins spezifiziert. Zu Beginn wählt man Deselect All, um alle aktivierten Plug-Ins zu deaktivieren. Im Workspace werden folgende Pakete ausgewählt: studium.da.caspaedit (Die Modellschnittstellen und ihre Implementationsklassen) studium.da.caspaedit.edit (EMF Editor) studium.da.caspaedit.diagram.rcp (Der Editor der Systemebene) studium.da.caspaedit.process.diagram.rcp (Der Editor der Prozessebene) Durch die Auswahl von Add Required Plug-Ins fügt Eclipse automatisch die benötigten Erweiterungen hinzu. Es fehlen lediglich die beiden Erweiterungen org.eclipse.emf.ocl und org.eclipse.emf.validation.ocl, die manuell aktiviert werden müssen, da sie zur Validierung mittels OCL im Editor benötigt werden. Weitere Plug-Ins können entfernt werden, da sie nicht benötigt werden: ui.ide, update.ui und alle mit update.core (jeweils mit Präfix org.eclipse). Nun kann die Anwendung gestartet werden und ist unabhängig von der Eclipse-IDE. Es werden trotz allem über einhundert Plug-Ins benötigt, was durch die verschiedenen Frameworks EMF, GEF, GMF und ihre Abhängigkeiten verursacht wird. Um die erzeugte, eigenständige Anwendung weitergeben zu können, wird ein Eclipse-Produkt benötigt. Durch Rechtsklick auf das RCP-Editor Paket und der Wahl von New / Other... / Plug- In Development kann eine neue Produktkonfiguration mit beliebigem Namen erzeugt werden. Um alle Einstellungen aus der Ausführungskonfiguration zu übernehmen, wird diese im unteren Bereich des Assistenten gewählt. Die entstandene Produktkonfiguration erhält eine Produkt-ID, welche neu erzeugt wird. Der Name Caspa Graphical Editor, die Product-ID product und die Auswahl der Application CaspaeditApplication müssen nun erfolgen. Im Reiter Configuration tauchen alle verwendeten Plug-Ins auf, die hier auch nochmals angepasst werden können. Unter Launching kann der Name des Programmstarters und Ausführungsparameter für die virtuelle Maschine (VM) von Java angegeben werden. Im Gegensatz zur Application kann ein Product in Eclipse Brandings enthalten. Unter Splash kann ein Startbild, welches als splash.bmp im jeweilig gewählten Plug-In vorhanden sein muss, definiert werden. Im Reiter Branding können Fenstersymbole, der About-Dialog und eine Willkommensseite spezifiziert werden. Nun hat man ein vollwertiges Eclipse-Produkt entworfen, welches mit Rechtsklick auf das Editor-Paket mittels Export... / Plug-in Development / Eclipse product exportiert werden kann. Nach Wahl des Wurzel- und Zielverzeichnisses des Editors wird die lauffähige Anwendung dahin abgelegt. Durch die Installation des sogenannten Eclipse-RCP-Delta-Packs wird dem Entwickler die Möglichkeit eröffnet, das Produkt für verschiedene Plattformen (Windows, Linux, Linux64, MacOS und Solaris) exportieren zu lassen. Teilweise bedarf es einiger manueller Anpassungen durch Hinzufügen bestimmter Plug-Ins zur Konfiguration, um die Lauffähigkeit auf diesen wirklich zu gewährleisten. Trotz allem ist diese Möglichkeit sehr gut, um plattformübergreifende Produkte zu generieren.

67 3.3. DIE ERSTELLUNG DES EDITORS Verwendete Software In diesem Abschnitt werden die verschiedenen Versionen der verwendeten Frameworks angegeben. Dies wurde zur Wahrung der Übersichtlichkeit in Form einer Tabelle dargestellt. Komponente Version Eclipse IDE 3.3 Eclipse Modeling Project Eclipse Modeling Framework EMF Query 1.1 EMF Transaction 1.1 EMF Validation 1.1 Graphical Modeling Framework 2.0 Java Emitter Templates (M2T) OCL für EMF (MDT) 1.1 Tools Project Graphical Editing Framework 3.3 Tabelle 3.1: Versionsübersicht der einzelnen Komponenten Die angegebenen Versionen können unter der URL: heruntergeladen werden. Die IDE befindet sich direkt unter Downloads. Alle anderen Komponenten sind unter dem jeweiligen Projektnamen unter Projects zu finden. Während der Konzeption und Implementierung des Editors wurde GMF und die weiteren Komponenten stets verändert. Der Einstieg begann mit der Version und nach Auftauchen der ersten Vorversionen von GMF 2.0 wurde damit weiterentwickelt. Dabei kam es häufig zu Änderungen in der Definition der graphischen und Mapping-Modelle, sodass viele Anpassungen getroffen werden bzw. Fehler erkannt und den Entwicklern gemeldet werden mussten. Teilweise wurden durch diese vorliegende Arbeit gewisse Fehler behoben und damit die Entwickler unterstützt. Die Vorgehensweise zur Umsetzung des Diagrammeditors wurde in dieser Arbeit trotz allem an der aktuellen und stabilen Version 2.0 von GMF beschrieben, obwohl einige Möglichkeiten in den Vorversionen gar nicht zur Verfügung standen und demnach nicht genutzt worden sind. Beispiele hierfür sind die verschiedenen Parser für die Labels, von denen es bei der Entwicklung nur den MessageFormatParser gab. Auch das graphische Modell wurde in einer späten Version verändert und so kamen die neuen Figure Descriptors hinzu, die anfangs viele Probleme mit den Labels bereiteten. In den Assistenten zur Modelltransformation wurden einige Dinge verbessert, die vorher nicht möglich waren. Die vollständige Unterstützung von RCP wurde nach und nach durch das Framework erweitert. So kam die Validation Decoration erst mit der Version 2.0M7, die Fehler der Validierung als rote Kreise an den jeweiligen Objekten (im gewohnten Eclipse-Stil) kennzeichnet und als sehr sinnvoll eingeschätzt wird. Die Gesamtimplementierung des Editors war bereits mit der Version 2.0M4 beendet. Daher bestand stets Anpassungsbedarf des Editors an die neue Versionen bis schließlich Ende Juni 2007 die fertige Version 2.0 bereitgestellt wurde. Wie erwähnt, wurden dabei grundlegende Konzepte durch die

68 60 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Entwickler verändert. Das Ziel bestand von Anfang an, den Editor nur mit einer stabilen und endgültigen Version des zu Grunde liegenden Graphical Modeling Frameworks frei zu geben. 3.4 Implementierung der Funktionalitäten Nachdem die Entwicklung der Editoroberfläche beschrieben wurde, erläutert dieser Abschnitt die wichtigen Funktionalitäten, welche die Schnittstelle zwischen graphischem Editor und dem Werkzeug Caspa herstellen. Diese sind bis auf wenige Stellen losgelöst von der Definition des Editors. Als erstes wird der Export von erzeugten Modellen im Editor zu Caspa-Eingabedateien beschrieben. Der darauf folgende Abschnitt beschreibt die Importierung vorhandener Caspa- Eingabedateien, die im Editor graphisch repräsentiert werden sollen. Der letzte Abschnitt beschäftigt sich mit der Ausführung des Werkzeugs Caspa innerhalb des Editors mit der Möglichkeit, verschiedene Ausführungsparameter zu definieren. All diese Funktionalitäten runden den Editor als vollwertiges eigenständiges Werkzeug für Caspa ab Der Export von Diagrammmodellen zu Caspa-Dateien Bevor der Export von Diagrammmodellen erläutert werden kann, wird hier ein kurzes Beispiel einer kompletten Caspa-Eingabedatei gegeben (siehe Listing 3.9). Sie beschreibt die komplette 1 int max = 7; 2 rate mu = 3; 3 4 P := Queue (0) 5 6 Queue (n [max]) := 7 [n > 0] -> (serve, mu); Queue (n-1) 8 [n < max] -> (arrival, 2); Queue (n+1) 9 10 statemeasure Queue_full Queue (n = max) Listing 3.9: Caspa-Eingabedatei Queue7.t Spezifikation eines Warteschlangenprozesses. Das System P besteht nur aus dem einen Prozess Queue (Warteschlange) mit dem Zahlwert 0 als Startparameter. Die Queue besitzt einen Parameter, der die Anzahl der wartenden Jobs oder Aufträge beschreibt. Diese Anzahl ist durch die Konstante max=7 nach oben beschränkt. Falls innerhalb des Prozesses die Anzahl der Jobs größer als 0 ist, kann ein Job mit der Rate µ = 3 abgearbeitet werden und demnach wird die Anzahl der Jobs um einen reduziert. Falls die Anzahl der Aufträge noch nicht maximal ist, kann ein weiterer mit der Rate 2 ankommen. Dabei erhöht sich die Zahl der Jobs (n). Am Ende folgt die Definition eines Zustandsmaßes, welches die Wahrscheinlichkeit bestimmt, dass die Queue die maximale Anzahl an Jobs besitzt. In dieser hier vorgestellten Art werden die Eingabedateien von Caspa spezifiziert. Genau so wurde die Ausgabe des Modells umgesetzt, obwohl die genaue Reihenfolge für Caspa nicht so relevant ist (z.b. Konstanten und Ratendefinition),

69 3.4. IMPLEMENTIERUNG DER FUNKTIONALITÄTEN 61 da es die komplette Datei einliest und dann erst die Berechnung startet. Die Datei wird durch die Einhaltung dieser Reihenfolge sehr übersichtlich gehalten und kann vom Betrachter besser verstanden werden. Es folgt nach dem Export der Konstanten, Raten und Gewichte die Definition des Systems, welches aus Hide-, Synchknoten und Instanzen von Prozessen bestehen kann. Danach werden die einzelnen Prozesse mit ihren Guards, Transitionen und Zuständen definiert. Am Ende erfolgt die Ausgabe der Leistungsmaße. Bei der Erstellung des zu Grunde liegenden Modells für den Editor wurde darauf geachtet, dass all diese Informationen im Editor spezifiziert und danach problemlos ausgegeben werden können. Der Export erfolgt mit Hilfe von JET (vgl. Abschnitt 2.6). Es wurden vier verschiedene Templates erstellt, aus denen die JET-Engine vier Klassen im Paket der Modellklasseninterfaces erzeugt. Das erste Template mit dem Namen root.txtjet erzeugt den Rahmen des Systems. Die erzeugte Klasse heißt TranslationCaspaTemplate. Sie beinhaltet als erstes die Ausgabe definierter Konstanten, Raten und Gewichte. Ein Auszug aus dem Template für die Konstanten zeigt Listing Das Template bekommt als Argument das CaspaSystem des aktuellen Dia- 1 <%CaspaSystem system = (CaspaSystem) argument; 2 EList<Constant> constants = system.getdefinitions().getconstants(); 3 Constant constant; 4 for (int i=0;i<constants.size(); i++) { 5 constant=constants.get(i); 6 stringbuffer.append("int "+constant.getconstantname()+" = "+constant.getvalue()+ ; +NL); 7 }%> Listing 3.10: Template für Konstanten (Auszug aus root.javajet) grammmodells. Aus ihm wird die Liste der Konstanten geholt. Danach erfolgt die Iteration über die Konstanten und deren einzelne Ausgabe durch ihren Namen und Wert. Die erhaltene Zeichenkette wird dem Ergebnispuffer hinzugefügt. Genauso wird bei den Raten und Gewichten verfahren, welche auch in Definitions abgelegt sind. Im nächsten Schritt des Templates wird der Wurzelknoten mit dem Systemname und seinen Nachfolgern ausgewertet. Da das System aus einer Kombination von verschiedenen Hide- und Synchknoten bestehen kann, wurden dafür eigene Templates erstellt. Hat die Wurzel beispielsweise einen Synchknoten als Nachfolger, so wird eine Instanz der erzeugten Synchknotentemplateklasse TranslationSynchnodeTemplate aufgerufen. Das Synchknotentemplate trägt den Namen synchnode.txtjet und wertet für den jeweiligen Synchknoten im Modell wiederum seine Nachfolger aus. Diese können Synch-, Hideknoten und Prozesse sein. Prozesse sind durch SynchnodeProcessLinks mit dem Knoten verbunden, der die Parameter für die jeweilige Prozessinstanz hält. Über diese verbundenen ProcessLinks wird iteriert und die Prozesse mit Parameter jeweils durch Trennung der Aktionen des Synchknotens verbunden (vgl. Beispiel aus Abschnitt 2.1). Danach werden als Nachfolger die Hideknoten betrachtet, deren Auswertung wieder in einer eigenen Templateklasse TranslationHidenodeTemplate erfolgt. Sollten weitere Synchknoten als Nachfolger vorhanden sein, werden diese durch eine neue Instanz der Klasse Synchknotentemplate ausgewertet. Jede dieser Instanzen erzeugt für den Synchknoten automatisch einen in Klammern geschlossenen Ausdruck. Die Umsetzung im Template für Hideknoten funktioniert sehr ähnlich, nur dass hierbei genau ein Nachfolger betrachtet werden muss.

70 62 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG Nach dem Export des Systems folgt die der Prozesse. Hierzu werden alle mit der Wurzel verbundenen Prozesse betrachtet, welche die Methode getlinkedprocesses() aus der Klasse RootImpl liefert. Diese Methode verfährt, wie beim Zyklenfreiheitstest nach der Tiefensuche in Graphen, nur dass dabei keine Zyklen gesucht werden. Über alle gefundenen Prozesse, welche in einem Datentyp TreeSet 11 abgelegt sind, wird iteriert und jeweils eine Instanz der Klasse TranslationProcessTemplate mit dem Prozess als Argument erzeugt. Im Template process.txtjet werden der Prozessname und die Parameter als erstes dem Ergebnispuffer hinzugefügt. Danach wird über alle vorhandenen Transitionen iteriert. Zur Ausgabe werden die Guards in eckigen Klammern gefolgt von einem Pfeil, der Aktion und einer Rate in runden Klammern und dem Folgezustand mit den Parametern, die gegebenfalls durch die Assigns angepasst werden, erzeugt. Hierbei müssen verschiedene Spezialfälle betrachtet werden. So werden bei den Emptystates sofort die Folgetransitionen ausgewertet und deren Aktion und Rate an das Ergebnis angehängt. Falls durch die aktuelle Transition ein Folgezustand erreicht wird, der vom Namen nicht dem Prozess entspricht, handelt es sich um einen sogenannten Understate. Er wird in Caspa als neuer Prozess definiert. Diese Zustände werden getrennt, aber gleich behandelt wie der Prozess. Ihre Ausgabe erfolgt erst nach der vollständigen Ausgabe des eigentlichen Prozesses, der in dieser Instanz der Übersetzungsklasse betrachtet wird. Einen weiteren Spezialfall stellen Prozesse dar, die keine Parameter besitzen. Ihre Ausgabe unterscheidet sich von parameterbehafteten Prozessen auch dadurch, dass es keine Guards gibt. Nachdem alle Prozesse an den Ergebnispuffer des Systems angefügt wurden, folgt die Ausgabe der Leistungsmaße. Deren Ausgabe ist ähnlich der der Konstanten und Raten. Im Objekt Definitions ist das Objekt Measure abgelegt, welches alle Leistungsmaße in Form von Listen verwaltet. Die verschiedenen Leistungsmaße werden nach der gewünschten Form entsprechend ihrer Attribute ausgegeben. Als Rückgabewert der Instanz von TranslationCaspaTemplate erhält man eine Zeichenkette, die die Eingabedatei für Caspa repräsentiert. Sie wird in eine Datei geschrieben und kann dann vom Werkzeug Caspa eingelesen und verwendet werden. Zur Einbindung dieser Möglichkeit des Exportierens in den graphischen Editor muss eine neue Menüaktion definiert werden. Ähnlich wie die Klasse ValidationProvider wurde eine Klasse CaspaeditExportProvider angelegt, welche die Klasse AbstractContributionItemProvider erweitert. In dieser wird die Aktion definiert, die als Transaktion ausgeführt wird. Dadurch wird sichergestellt, dass die Aktion nur vollständig ausgeführt werden kann. Die statische Methode export wird erst nach erfolgreicher Validierung des Modells gestartet. Nach Abfrage des Zieldateinamen durch einen FileDialog wird eine neue Datei als Instanz der Klasse FileWriter angelegt. Der Export bekommt als Argument das CaspaSystem, welches vom DiagramEditPart durch resolvesemanticelement() geholt wird. Das Ergebnis der Ausgabe wird in die Datei geschrieben und durch eine Meldung bestätigt. Um diese Aktion vom Menü aus aufrufen zu können, muss sie in der plugin.xml aufgenommen werden. Dazu wird unter den im Abschnitt erwähnten contributionitemproviders ein 11 Der Datentyp TreeSet ist eine Implementierung des Interfaces Set, welches in Java eine Menge darstellt. Der Vorteil einer Menge im Vergleich zu einer Liste ist, dass keine doppelten Elemente vorkommen. Um Tree- Set verwenden zu können, musste eine Klasse ProcessComparator angelegt werden, um den Vergleich von zwei Prozessobjekten zu ermöglichen.

71 3.4. IMPLEMENTIERUNG DER FUNKTIONALITÄTEN 63 solcher neu angelegt. Diesem wird als Klasse der ExportProvider zugewiesen. Der Unterknoten partcontribution beschränkt die Anzeige dieser Aktion im Menü auf den Editor durch die Vergabe der ID diagram.rcp.part.caspaeditdiagrameditorid. In einer partmenugroup wird die exportgroup als ID im /diagrammenu/ (menubarpath) erzeugt. In der partaction mit ID exportaction wird die Aktion der exportgroup hinzugefügt. Damit wird im Editor diese Menüaktion angezeigt und bei dessen Auswahl der Export des Modells angestoßen. Ebenso wurde die Speicherung des Diagrammmodells als Bilddatei erreicht. Die Implementationsklasse lautet CaspaeditExportImageProvider, in der die Klasse CopyToImageAction mit der Editorseite als Argument instanziiert wird. Durch den Aufruf der Methoden init(), setup() und run() der erzeugten Klasseninstanz öffnet sich automatisch ein Dialog, der die Eigenschaften der Bilddatei abfragt und dann selbstständig das Diagramm als Grafikdatei exportiert. Diese Funktionalität wird von GMF unterstützt, ihre Umsetzung ist daher relativ einfach gewesen Das Importieren von Caspa-Dateien Als weitere Funktionalität soll der Import vorhandener Caspa-Eingabedateien in den Editor möglich sein. Dabei werden nach dem Parsen dieser Datei die einzelnen Modellelemente graphisch im Modelleditor dargestellt. In den Quelldateien des Werkzeugs Caspa ist bereits ein Parser für die Grammatik der Eingabedateien vorhanden. Diese Grammatik wurde in YACC 12 definiert, da Caspa in der Programmiersprache C implementiert wurde. Diese Definition kann nicht ohne Weiteres im JavaCC Quellcode verwendet werden, da bestimmte Regeln linksrekursiv sind und daher eine Anpassung benötigen. Dieser Abschnitt behandelt nicht die komplette Grammatik 13, welche zum Parsen von Caspa-Eingabedateien genutzt wird. Zur lexikalischen Analyse wurde für Caspa die Datei lexer.l, die die Tokens definiert und mit dem Werkzeug Flex übersetzt wird, verwendet. In der Datei grammar.y wird die syntaktische Analyse der Eingabedateien festgelegt. Sie wird mit Hilfe des Werkzeugs Bison 14 in C-Quellcode umgesetzt. Zur Erstellung der Definition in JavaCC wurden diese beiden Dateien als Grundlage verwendet. Die vorgegebenen Tokens der lexikalischen Spezifikation konnten einfach übernommen werden. Kommentare wurden als Special Tokens definiert und werden demnach in der Analyse geparst, aber nicht weiter verwendet. Die erste Produktionsregel process_list der definierten Grammatik in grammar.y ist linksrekursiv. Sie wurde gemäß Listing 3.11 für den Parser von Caspa festgelegt. In JavaCC musste die Regel, wie in Listing 3.12 dargestellt, angepasst werden. Die Liste der Prozesse besteht aus mindestens einer Anweisung (stmt). Eine Anweisung kann aus der Definition einer Konstanten, einer Rate, eines Leistungsmaßes oder eines Prozesses bestehen. Werden Konstanten, Raten oder Leistungsmaße vom Parser erkannt, werden sie in Caspa angelegt. Auch in der 12 Der Yet Another Compiler-Compiler ist ein Parsergenerator, der für LALR(1) Grammatiken einen Parser in der Programmiersprache C definiert. Eine solche Grammatik kann im Gegensatz zu JavaCC durchaus linksrekursive Regeln enthalten. 13 Die Grammatik in EBNF, die die Eingabesyntax von Caspa repräsentiert, ist unter [3, Anhang B] zu finden. 14 Bison ist ein Werkzeug, welches wie YACC nach gegebener Spezifikation einen Parser in der Programmiersprache C erstellt.

72 64 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG 1 process_list: 2 process_list stmt stmt 3 ; Listing 3.11: Produktionsregel process_list aus grammar.y 1 void process_list(): 2 {} 3 { 4 stmt() (stmt())* {} 5 } Listing 3.12: Veränderte Produktionsregel process_list in caspa.jj JavaCC Spezifikation wurden die geparsten Elemente mittels eigens implementierten Methoden in der Parserklasse angelegt. Ein Beispiel soll das Anlegen einer Konstante aus den Elementen zeigen (siehe Listing 3.13). Der Parser liefert den Namen v und einen arithmetischen Ausdruck a, der den Wert der 1 void def(): 2 {String v,a;} 3 { 4 <INTDEF> v=variable() "=" a=arith_expr() ";" {createconst(v,a);} 5 } Listing 3.13: Produktionsregel def() zum Anlegen einer neuen Konstante Konstanten darstellt, die zum Anlegen der Konstanten im CaspaSystem des Editors mit der Methode createconst erfolgt. In dieser Methode wird nach Prüfung der vorhandenen Konstanten im System eine neue Konstante angelegt, der Name und Ausdruck zugewiesen wird. Im Anschluss muss diese noch der Liste der Konstanten aus dem Objekt Definitions hinzugefügt werden. Weitere Hilfsmethoden zur Erstellung der Modellelemente sind beispielsweise dividetransitionstring, dividesynchstring, createrootlink und createstatemeasure. Die Methode dividetransitionstring trennt eine geparste und angepasste Zeichenkette nach Transitionen für einen bestimmten Prozess. Es werden action, guards und assigns erkannt und entsprechend angelegt. Nicht vorhandene Zustände der Transition werden ebenfalls dem jeweiligen Prozess zugefügt. Dabei wurden viele Speziallfälle betrachtet, wie zum Beispiel, dass ein Folgezustand der Transition ein neuer Understate 15 ist, aber zu diesem Zeitpunkt noch nicht definiert wurde, da der entsprechende Teil der Eingabedatei noch nicht gelesen wurde. Dies wurde realisiert, in dem er in eine Warteschlange gepackt wird, welche zu einem späteren Zeitpunkt geprüft wird. Jedesmal wenn ein neuer Prozess definiert wird, erfolgt zuerst die Prüfung dieser Warteschlange, das heißt es wird nachgeschaut, ob es sich um den gesuchten Understate handelt. Für eine Transition, die zwei Transitionen ohne expliziten Zwischenzustand enthält, wird automatisch ein EmptyState erzeugt. Die Methode dividesynchstring 15 Als Erinnerung: Ein Understate wird in Caspa als eigener Prozess definiert.

73 3.4. IMPLEMENTIERUNG DER FUNKTIONALITÄTEN 65 zerlegt eine Zeichenkette von Synchknoten entsprechend nach Tiefe der Klammerung der Ausdrücke. Untergeordnete Synchknoten werden durch rekursiven Aufruf dieser Methode ausgewertet und im System angelegt. Um zu prüfen, ob ein Synchknoten mit all seinen Nachfolgern im System bereits vorhanden ist, wird die Methode output der Klasse SynchnodeImpl genutzt, welche eine besondere Zeichenkette zurückliefert. Die JavaCC-Spezifikation wurde in der Datei caspa.jj umgesetzt, in der der Leser alle implementierten Methoden, die gut kommentiert wurden, nachlesen kann. Auf eine genauere Betrachtung dieser Methoden soll hier nicht weiter eingegangen werden. Der Compiler Compiler erzeugt daraus die entsprechenden Klasse CaspaImport mit ihren benötigten Hilfsklassen. Eine Instanz dieser Klasse wird mit der Methode parse mit der einzulesenden Datei und dem CaspaSystem, in dem die erkannten Objekte abgelegt werden sollen, als Argumente aufgerufen. Im Folgenden muss die Einbindung in den graphischen Editor geschaffen werden. Dazu wird eine neue statische Klasse ImportCaspaFileAction in der Klasse DiagramEditorActionBarAdvisor implementiert. Die Menüaktion wird in der plugin.xml unter dem Erweiterungspunkt org.eclipse.ui.actionsets eingebunden. Unter dem vorhandenen ActionSet Caspaedit Actions wird eine neue Aktion eingebracht. Als ID bekommt sie den Verweis auf die oben definierte Aktion studium.da.caspaedit.diagram.rcp.importcaspafileaction. Der Menütext kann in der Datei plugin.properties als importactionlabel definiert und als Label mit % als Präfix angegeben werden. Um die Menüaktion im File-Menü zu erzeugen, muss file/additions als Pfad angegeben werden. Als Klasse wird eben genannte ImportCaspaFileAction mittels Browse gesucht und übernommen. Nun ist die Menüaktion mit der definierten Aktion der statischen Klasse verbunden. Die Methode run der statischen Klasse ruft einen erstellten Assistenten CaspaeditImportWizard auf, der die Caspa-Eingabedatei und die Diagrammmodelldatei abfragt. Nach Eingabe dieser Daten ruft der Assistent die Methode creatediagramfromimport aus der Klasse DiagramEditorUtil auf. Sie wurde ähnlich wie die generierte Methode create- Diagram implementiert, ruft aber die Methode createinitialmodelfromimport auf, die den Parser mit dem jeweiligen CaspaSystem und der spezifizierten Eingabedatei instanziiert. Nachdem der Parser die Datei analysiert hat und das CaspaSystem mit den Modellelementen befüllt hat, wird dieses genau wie bei der Methode createinitialmodel zurückgegeben. Zusammenfassend kann man sagen, dass genau wie bei der Erstellung eines neuen Diagrammmodells, bei dem Definitions und Root automatisch erzeugt werden, hier nun alle Elemente der Eingabedatei einfach hinzugefügt werden Das Ausführen von Caspa innerhalb des Editors Die letzte Funktionalität, die die Schnittstelle zum vorhandenen Werkzeug Caspa repräsentiert, ist die Möglichkeit Caspa direkt aus dem Editor zu starten. Genau wie bei der Aktion für Import wird eine Aktion für das Ausführen in der Klasse DiagramEditorActionBarAdvisor implementiert und dem Menü des Editors hinzugefügt. Diese ruft einen Assistenten auf, der in der Klasse CaspaeditExecuteWizard umgesetzt ist. Im ersten Fenster des Assistenten (ExecuteWizardPage) wird der Dateiname der Eingabedatei und die ausführbare Caspa-Datei für das jeweilige Betriebssystem augewählt. Auf der zweiten Seite werden alle verfügbaren Parameter zur Ausführung von Caspa dargestellt und können mit Hilfe von Auswahlkästchen aktiviert

74 66 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG werden. Stehen mehrere Möglichkeiten für einen Parameter zur Auswahl, so werden diese in einer sogenannten ComboBox (aufklappbare Auswahlliste) aufgelistet. Dies wurde beispielsweise bei der Auswahl der numerischen Verfahren zur Analyse angewendet. Zusätzliche Spezifikationsdateien oder Ausgabedateien können durch einen FileDialog vom Benutzer gewählt werden. Die angegebenen Parameter werden durch die Methode getparameter der Klasse WizardExecuteCreationPage1, die zum Erstellen der Assistentenseite dient, in eine Zeichenkette umgewandelt. Die graphischen Elemente der Assistentenseiten stammen aus den Klassen von SWT und werden jeweils mit der Methode createcontrol für die jeweilige Seite erzeugt. Für jedes Elemente wurden Listener eingeführt, die den jeweiligen booleschen Wert gemäß der Aktivierung verändern. Die letzte Seite des Assistenten verfügt über ein großes Textfeld, welches zur Ausgabe von Caspa genutzt wird. Eine ComboBox empfängt die ausgegebenen Fehlermeldungen. Der Button Run ruft die Methode generateresult auf, die die erforderlichen Dateinamen und Parameter aus den vorhergehenden Seiten des Assistenten holt und daraus ein auführbares Befehlskommando erzeugt. Die Ausführung von Caspa für Modelle mit großem Zustandsraum kann sehr lang dauern. Da somit das gesamte Programm auf die komplette Ausführung warten müsste, wurde dafür die Möglichkeit von Threads in Java genutzt. Damit wird ein paralleler Aufruf ermöglicht, der den Editor nicht blockiert. Um dies zu erreichen, wurde die gesamte Klasse WizardExecuteCreationPage2 als Implementierung des Interfaces Runnable umgesetzt. Dadurch kann diese Klasse als Thread ausgeführt werden. Sie benötigt eine Methode run(), die bei Ausführung des Threads durch start aufgerufen wird. In dieser Methode wird das vorbereitete Kommando als Instanz der Java-Klasse Process mittels Runtime.getRuntime().exec ausgeführt. Die Ausgabe dieses Prozesses erfolgt durch Datenströme, den sogenannten Streams. Für den Fehler- und den Ausgabedatenstrom wurden wiederum Threads implementiert, die Instanzen der erstellten Klasse StreamThread darstellen. Diese überwachen die jeweiligen Datenströme, bis keine Daten mehr kommen, weil der Prozess beendet ist, oder der Benutzer den Thread zur Ausführung abgebrochen hat. Innerhalb der Klasse StreamThread in der Methode run werden InputStreamReader zum Lesen der Datenströme und BufferedReader zum zeilenweisen Lesen dieser InputStreamReader verwendet. Nach der Beendigung des Ausführungsprozesses werden die Ausgaben dem Textfeld und der ComboBox zugewiesen. Über Finish kann der Assistent beendet werden. Alle Dateinamen der Assistenten werden in einer Konfigurationsdatei des Editors gespeichert, um zu verhindern, dass der Benutzer die Daten stets neu eingeben muss. Dazu wurde eine Klasse ConfigFileReadWrite im Paket caspaedit.impl geschaffen. Eine Instanz der Klasse sucht die Datei caspa.config im aktuellen Verzeichnis und liest bei Angabe von true des booleschen Parameters diese ein. Für jeden Dateinamen verfügt diese Klasse über Methoden zum Setzen und Holen der Werte. Als Beispiele sind die beiden Methoden getexecutecaspafile und setexecutecaspafile, die für den Dateinamen der Eingabedatei im Ausführungsassistenten zur Verfügung stehen, zu nennen. Mit der Methode writeconfig werden die gesetzten Werte in die Konfigurationsdatei geschrieben. Jeder Assistent wurde mit dieser Funktionalität erweitert und speichert selbstständig die eingegebenen Dateinamen nach seinem Beenden ab. Das Listing 3.14 zeigt die Umsetzung der Speicherung in der Methode performfinish des Ausführungsassistenten. Das Objekt cfrw ist eine Instanz der Klasse ConfigFileReadWrite

75 3.4. IMPLEMENTIERUNG DER FUNKTIONALITÄTEN 67 1 public boolean performfinish() { 2 // set filename of executable 3 cfrw.setexecutecaspaexec(getcaspaexecfilename()); 4 // set filename of caspa-file 5 cfrw.setexecutecaspafile(getcaspafilename()); 6 // set filename of add-file 7 cfrw.setaddexecutefile(getaddfilename()); 8 // set filename of tra-file 9 cfrw.settraexecutefile(gettrafilename()); 10 // set filename of dot-file 11 cfrw.setdotexecutefile(getdotfilename()); 12 // save config 13 cfrw.writeconfig(); 14 return true; 15 } Listing 3.14: Speichern der Dateinamen durch die Klasse ConfigFileReadWrite und bekommt die Dateinamen durch ihre Methoden zum Setzen zugewiesen. Caspa als ausführbare Datei für Windows erzeugen Da Caspa am Institut für Technische Informatik nur als kompilierte Linuxversion zur Verfügung stand, wurde im Rahmen dieser Arbeit durch Veränderung der Erstellungsdateien (Makefiles) eine ausführbare Version für das Betriebssystem Windows geschaffen. Der graphische Editor ist für beide Betriebssysteme erzeugt worden, daher musste die Ausführung von Caspa auch unter beiden möglich sein. Dieser Abschnitt zeigt diese Veränderungen auf, um nachfolgenden Entwicklern die Arbeit zu ersparen, sich darin einarbeiten zu müssen. Um die Quellen von Caspa kompilieren zu können, wird eine Version von PRISM [26] benötigt. Dieses Werkzeug wurde von der Universität von Birmingham entwickelt und wird zur Verifikation probabilistischer Systeme verwendet. Dieses nutzt wiederum ein Paket namens CUDD in der Version mit dem binäre Entscheidungsdiagramme aufgebaut und manipuliert werden können. Das Paket wird für das Kompilieren von Caspa benötigt, da es damit seine MTBDDs aufbaut. Zunächst wurde die aktuelle Version von PRISM heruntergeladen. Die Quelldateien von Caspa wurden vom Aufgabensteller zur Verfügung gestellt. Zur Erstellung der ausführbaren Caspa-Datei für Windows wird das Programm Cygwin [27] (Version ) benötigt. Dieses emuliert eine Linux-Oberfläche unter dem Betriebssystem Windows. Während der Installation muss man das Entwicklungspaket mit den Tools bison, flex und gcc auswählen, welche später benötigt werden. Nachdem die Caspa-Quellen und das aktuelle PRISM im dafür vorgesehenen Unterverzeichnis von Caspa in das Home-Verzeichnis von Cygwin kopiert worden sind, können die jeweiligen Teile nach Bearbeitung der Makefiles erstellt werden. Zuerst muss das Makefile der Prism-Quelldateien im Hauptverzeichnis angepasst werden. Dazu werden die Variablen OSTYPE auf cygwin, JAVADIR auf das Java-Hauptverzeichnis und JA- VAC sowie JAVAH auf das Bin-Verzeichnis innerhalb von Java gesetzt. Das Listing 3.15 zeigt einen Auszug aus dem Makefile, welches verwendet wurde, mit den gesetzten Variablen. Im Hauptverzeichnis der Prism-Quelldateien muss ein Verzeichnis namens obj mit den Unterverzeichnissen dd, dv, jdd, mtbdd, odd, prism, sparse, hybrid und simulator

76 68 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG 1 OSTYPE = cygwin 2 JAVA_DIR = /cygdrive/c/java/jdk1.6.0_01 3 JAVAC = $(JAVA_DIR)/bin/javac 4 JAVAH = $(JAVA_DIR)/bin/javah Listing 3.15: Anpassungen im Makefile von PRISM angelegt werden. In diesen werden die kompilierten Objektdateien von Prism abgelegt. Unter Cygwin wechselt man in das Hauptverzeichnis von Prism und startet das Makefile durch den Befehl make. Nachdem die Kompilierung von Prism erfolgreich beendet wurde, kann Caspa nach Anpassung von dessen Makefile übersetzt werden. Die vorhandene Version der Quelldateien von Caspa beinhaltet ein Makefile, welches für Cygwin voreingestellt ist. Lediglich das Verzeichnis von CUDD muss gesetzt werden. Das Listing 3.16 zeigt diese Einstellung für die aktuelle Version von PRISM. Danach kann Caspa über den Befehl make in seinem Quel- 1 CUDD_ROOT =../prism/prism src/cudd Listing 3.16: Anpassungen im Makefile von Caspa lenverzeichnis erstellt werden. Nachdem dieser Vorgang beendet ist, hat man eine ausführbare Datei für Windows erhalten. 3.5 Testen des geschaffenen Produktes Um ein zuverlässiges Softwareprodukt 16 schaffen zu können, sind Tests der verschiedenen, angebotenen Funktionalitäten unumgänglich. Nach der Erstellung des Grundgerüstes des Editors durch GMF wurde mit den ersten Tests der geschaffenen Benutzeroberfläche begonnen. Diese wurden durch den Entwickler selbstständig durchgeführt. Dabei wurde besonderes Augenmerk auf die Anlegbarkeit von bestimmten Objekten in deren zugehörigen Oberobjekten gelegt. Des Weiteren können ausgewählte Verbindungen nur zwischen dafür vorgesehenen Objekten geschaffen werden, was wiederum getestet werden musste. Einige genannte Modellobjekte unterliegen Beschränkungen, wie deren Anzahl, Erstellbarkeit und Entfernen, welches durch Constraints in den Modellen des Editors definiert wurde. Diese Beschänkungen wurden ebenfalls in die Tests einbezogen. Erst nach den erfolgreichen Oberflächentests wurden die Schnittstellenfunktionalitäten implementiert. Dazu gehört der Export der Modelle, welcher innerhalb der Oberfläche anhand der erstellten Dateiausgaben geprüft wurde. Da die Syntax der Caspa-Eingabedateien recht gut lesbar ist, konnten die vom Editor erzeugten Dateien sehr gut verifiziert werden. Mängel in der Formatierung und der syntaktisch richtigen Ausgabe wurden dadurch erkannt und behoben. Die Funktionalität des Importierens konnte durch bereitgestellte Fallbeispiele von Caspa, die 16 Nach [25] handelt es sich dabei um ein Software-System, welches erwartungsgemäß in einem bestimmten Zeitraum funktioniert oder eine geforderte Leistung erbringt.

77 3.5. TESTEN DES GESCHAFFENEN PRODUKTES 69 das volle Einsatzspektrum des Werkzeugs ausnutzen, überprüft werden. Somit wurde die Korrektheit des erstellten Parsers untersucht. Die erkannten Objekte des Parsers werden im Editor als graphische Elemente dargestellt. Diese Repräsentation konnte leicht mit den Eingabedateien übergeprüft werden. Neu eingeführte Methoden zur Unterstützung der genannten Funktionalitäten wurden stets in Form von Integrationstests (Gesamttests) mit Hilfe der Oberfläche des Editors verifiziert. Die Ergebnisse innerhalb des Editors zeigten sehr schnell deren Korrektheit auf. Das Testen durch den Entwickler wurde durch die Betreuer dieser Arbeit in unabhängiger Weise in Form von Integrations- und Akzeptanztests unterstützt. Da diese selbstständig die Funktionalitäten überprüften, wurden weitere Fehler gefunden, die im späteren Verlauf abgestellt werden konnten. Explizite Tests durch JUnit 17 wurden dabei nicht erstellt. Obwohl GMF selbst Testpakete für JUnit erstellen kann, wurden diese nicht verwendet, da es sich hierbei um ein überschaubares, kleines Produkt handelt bei dem nur wenige verschiedene Objekte vorkommen. Mit Abschluss der Implementierung des graphischen Editors wurde ein Zeitraum von ungefähr einem Monat dazu verwendet, um die Funktionalität des Editors an die Veränderungen an das zu Grunde liegende GMF anzupassen. In dieser Phase wurden Tests mit eigenen Eingabedateien und Modellen durchgeführt und die Wartung des Produktes betrieben. Dies beendet das Kapitel der Konzeption und Umsetzung. Das folgende Kapitel stellt das Benutzerhandbuch dar, in dem viele hier genannte Dinge nochmals auftauchen. Das liegt daran, dass dieses eigenständige Kapitel einem neuen Benutzer des Editors als Tutorial zugänglich gemacht werden soll. Er muss demnach nicht die komplette Arbeit vorliegen haben, um die Arbeit mit dem Editor zu verstehen. Das Benutzerhandbuch ist ohne Implementierungshintergründe auf einem einfachen Niveau verfasst worden. Es zeigt die Fähigkeiten des Editors sowie den Umgang mit den einzelnen Funktionalitäten. 17 JUnit stellt ein Framework dar, welches zum Testen von Java-Programmen genutzt werden kann.

78 70 KAPITEL 3. KONZEPTION UND IMPLEMENTIERUNG

79 Kapitel 4 Benutzerhandbuch Dieses Kapitel bildet das Benutzerhandbuch für den graphischen Modelleditor für das Werkzeug Caspa. Nach einer Vorstellung der Benutzeroberfläche des Editors folgen Beschreibungen für die Arbeit mit dem Editor zur Erstellung eines eigenen graphischen Modells. Die Oberfläche verteilt sich auf verschiedene Ebenen, wie im weiteren Verlauf deutlich werden wird. Im Anschluß werden die wichtigen Funktionalitäten der Schnittstelle zwischen Editor und Caspa erläutert. Um neuen Benutzern die Einarbeitung zu erleichtern, wird diese Erläuterung durch Bildschirmkopien (Screenshots) untermauert. 4.1 Einstieg Bevor der Editor gestartet werden kann, müssen bestimmte Voraussetzungen in der Konfiguration des Rechners erfüllt sein. Der graphische Editor wurde mit der Entwicklungsumgebung Eclipse für das Betriebssystem Windows XP und Linux 32- und 64-Bit entwickelt. Die Anforderungen ergeben sich demnach genau wie für Eclipse in der Version 3.3. Zusätzlich wird für den Editor die im Moment aktuelle Version des Java Runtime Environment Version 6 benötigt. Alle weiteren Komponenten sind in der vollständigen Version des Editors enthalten. Gestartet wird der Editor mittels einem für Eclipse typischen Launcher (entweder caspaedit.exe oder caspaedit). Nach dem Startbildschirm öffnet sich die Oberfläche des Editors. Die Oberfläche Die leere Oberfläche ist in Abbildung 4.1 zu sehen. Im oberen Bereich befindet sich die Menüleiste mit den verschiedenen Menüs, welche im Folgenden genauer erläutert werden. Im Menü File kann über New / Caspaedit Diagram ein neues Diagrammmodell erstellt werden. Mit Open... werden vorhandene Diagrammmodelle mit der Endung ced geladen. Die Einträge Import und Execute werden in den Abschnitten und genauer betrachtet. Durch 71

80 72 KAPITEL 4. BENUTZERHANDBUCH Close / Close All werden geöffnete Diagramme geschlossen sowie mit Save / Save As / Save All abgespeichert. Im Menü Edit können durch Undo / Redo Aktionen innerhalb des Diagramms zurückgesetzt bzw. wiederhergestellt werden. Die Aktionen Cut / Copy / Paste / Delete dienen zum Ausschneiden, Kopieren, Einfügen und Entfernen von Diagrammelementen. Mit Select All können alle Diagrammelemente im aktiven Diagramm ausgewählt werden. Der Menüpunkt Preferences dient zum Festlegen verschiedener Einstellungen. Über den Menüpunkt Window wird mit Hilfe von Open New Window eine neue Instanz eines Editors parallel zum vorhandenen geöffnet. Im Menü Help kann man einen Dialog öffnen, der Informationen zur aktuellen Programmversion ausgibt. Im unteren Bereich des Editors sind zwei Abbildung 4.1: Die Oberfläche des Editors Sichten zu sehen. Die erste anfangs aktive Sicht ist die Outline-Sicht, die eine Übersicht über das aktuelle Diagramm darstellt. Die zweite Sicht ist die Properties-Sicht und wird im Folgenden benötigt, um die Eigenschaften der Modellelemente im Editor bearbeiten zu können. Beide Sichten sind ohne geöffnetes Diagramm leer, so wie auch bestimmte Menüaktionen deaktiviert sind. 4.2 Arbeit mit dem Editor Die Arbeit mit dem Editor beginnt mit der Erstellung eines graphischen Modells, welches die Spezifikation des gewünschten Systems für das Werkzeug Caspa repräsentieren soll. Die verschiedenen Elemente zur Definition eines solchen Systems werden in den folgenden Abschnitten erläutert. Der Editor ist in der Lage, alle möglichen Spezifikationen, welche von Caspa

81 4.2. ARBEIT MIT DEM EDITOR 73 akzeptiert werden können, zu modellieren und für Caspa zur Verfügung zu stellen. Die Arbeit funktioniert wie mit bekannten Zeichenprogrammen, in denen bestimmte Objekte auf einer Zeichenfläche abgelegt werden Die Erstellung eines graphischen Modells Um ein neues Modell anzulegen, wählt man den Menüpunkt Caspaedit Diagram unter File / New aus. In Folge dessen öffnet sich ein Assistent, der den Dateinamen benannt haben möchte, unter dem das Diagrammmodell abgelegt werden soll. In dieser Datei werden die Instanz des zu Grunde liegenden Modells und die graphischen Eigenschaften aller Modellobjekte gespeichert. Durch Bestätigen von Finish wird ein neues Diagramm angelegt. Dieses Diagramm enthält Modellelemente, die auf jeden Fall benötigt werden. Dazu gehören die Definitionen, in denen später die Konstanten, Raten und Gewichte angelegt werden können. Innerhalb der Definitionen befindet sich ein weiteres Objekt für die Leistungsmaße (Measures). In diesem können die verschiedenen Leistungsmaße für das zu modellierende System definiert werden. Dazu gehören Zustandsmaße (Statemeasures), Mittelwerte (Meanvalues) und Durchsätze (Throughputmeasures). Neben den Definitionen wurde auch die Wurzel des Systems bereits angelegt, in der später der Name des Systems definiert werden kann. Diese genannten Objekte können nicht aus dem Abbildung 4.2: Der Editor mit einem neu erstellten Diagramm. Diagramm gelöscht werden. Darum besteht auch keine Möglichkeit, sie neu anzulegen. Durch das Anlegen des Diagramms haben sich weitere Dinge in der Oberfläche des Editors verändert. So zeigt die Outline-Sicht jetzt eine Übersicht über das vorhandene Diagramm an. Sie ist

82 74 KAPITEL 4. BENUTZERHANDBUCH außerdem in der Lage, die Elemente des Modells in einer Baumansicht zu präsentieren. Im oberen, rechten Bereich dieser Sicht muss dazu der linke Knopf betätigt werden. Auf der rechten Seite ist eine Palette erschienen, mit der der Benutzer die Modellelemente im Diagramm anlegen kann. Die Auswahl erfolgt durch einen einfachen Mausklick auf das gewünschte Objekt und danach auf die Zeichenfläche, um es da anzulegen. Durch die Auswahl von Zoom kann die Ansicht des Diagramms vergrößert und durch zusätzliches Drücken auf die Shift -Taste verkleinert werden. Mit Note können im Diagramm Notizen auf der Zeichenfläche angebracht werden. Zusätzlich ist in der Menüleiste ein neues Menü Diagram entstanden. In diesem können die Linienarten, -farben, Farben und Schriftarten der Objekte geändert werden. Mit Arrange können die Objekte im Diagramm automatisch angeordnet werden. Um Objekte zueinander in bestimmter Art anzuorden, wird Align verwendet. Die Objekte können durch Order in verschiedene Ebenen auf der Zeichenfläche platziert werden. Um die Größe eines Objekts automatisch bestimmen und setzen zu lassen, kann Autosize gewählt werden. Mit Make Same Size werden verschiedene Objekte in ihrer Größe aufeinander angepasst. Unter View können Lineal, Gitter und Seitenumbrüche angezeigt sowie die Ausrichtung am Gitter festgelegt werden. Die Menüpunkte Export und Save As Image werden im Abschnitt beschrieben. Die Validierung des Modells mit Validate wird im nächsten Abschnitt erklärt. In bestimmten Regionen der Zeichenfläche tauchen nach Navigation mit dem Mauszeiger Auswahlfelder auf, mit denen die jeweiligen Unterobjekte angelegt werden können. So erscheint beispielsweise beim Navigieren über dem Objekt der Definitionen die Auswahl, Konstanten, Raten oder Gewichte anzulegen. Diese Auswahlfelder können gleichermaßen wie die Palette auf der rechten Seite genutzt werden. Die Systemebene Die erste Ebene, welche im Editor zu sehen ist, stellt die Systemebene dar. In ihr werden die Synchronisations-, Hide-Knoten und Prozesse des Systems definiert. Sie sind in der Palette unter Nodes zusammengefasst und auf der Zeichenfläche in einem Auswahlfeld dargestellt. Ein Prozess kann über die Palette auf der Zeichenfläche angelegt werden. Es erscheint eine gelbe Box, in der ein Textfeld für den Prozessnamen und die Prozessparameter erscheint. Die Eingabe erfolgt durch den Namen gefolgt von Parametern in runden Klammern. Diese werden durch ihren Namen und den Maximalwert in eckigen Klammern getrennt durch Kommas angegeben. Soll der Prozess keine Parameter besitzen, so müssen die runden Klammern dennoch angegeben werden. Ein Beispiel für einen Prozess mit dem Namen P und den Parametern a mit Maximalwert 5 und b mit Wert max würde folgendermaßen aussehen: P(a[5],b[max]). Der Wert max muss in den Definitionen als Konstante definiert werden, damit Caspa diesen später finden kann. Diese Prozessdefinition kann jederzeit durch Klicken auf das Textfeld geändert werden. Ein Hide-Knoten besitzt eine Menge von Aktionen, die für den jeweiligen Prozess verdeckt werden sollen. Diese werden durch Kommas getrennt angegeben. Ebenso verhält es sich bei dem Synch-Knoten, der mehrere Prozesse über die angegebenen Aktionen synchronisiert. Um die angelegten Objekte miteinander zu verbinden, gibt es mehrere Links, die ihre Namen

83 4.2. ARBEIT MIT DEM EDITOR 75 vom jeweiligen Quellobjekt erhalten haben. Will man einen Synch-Knoten mit einem Hide- Knoten verbinden, so wählt man einen SynchnodeLink aus der Palette aus. Man verbindet die beiden Objekte erst durch Anklicken des Synch-Knoten, dann Ziehen der Verbindung und schließlich dem Ablegen auf dem Hide-Knoten. Synch- und Hide-Knoten können jeweils mit Prozessen, Synch- und Hide-Knoten verbunden werden. Wobei Synch-Knoten mehrere (mindestens zwei) und Hide-Knoten genau einen Nachfolger (aber nicht sich selbst) besitzen können. Die Wurzel des Systems enthält dessen Name, der durch Anklicken des Textfeldes oder in den Eigenschaften in der Properties-Sicht geändert werden kann. Sie muss entweder mit einem Prozess, einem Synch- oder Hide-Knoten über einen RootLink verbunden werden. Ist das Ziel eines der genannten Links ein Prozess, so erscheint auf der Verbindung ein Textfeld, in welchem die Parameter des verbundenen Prozesses definiert werden müssen. Diese Parameter beschreiben die Initialisierung der Prozessparameter für diese angelegte Verbindung. Auch sie werden wieder durch Kommas getrennt angegeben. Der Editor erstellt beim Anlegen dieser Verbindung automatisch ein Folge von Parametern mit den jeweils erkannten Maximalwerten der Prozessparameter. Diese Verbindungen erscheinen aber auch am Rand der Objekte in Form von Pfeilen für ausund eingehende Verbindungen. Durch Drag&Drop auf diese Felder kann die Verbindung zwischen den beiden gewünschten Objekten genau wie mit der Palette angelegt werden. Der Editor erkennt automatisch, ob die gewählte Verbindung zulässig ist. Nicht erlaubte Verbindungsversuche werden durch einen durchgestrichenen Kreis signalisiert. Eine gewählte Verbindung kann ebenso vom Quellobjekt aus auf der Zeichenfläche fallen gelassen werden. Dann schlägt der Editor automatisch die erlaubten Objekte vor, die von dieser Verbindung als Zielobjekt in Frage kommen. Man kann vorhandene Objekte wählen oder neue anlegen lassen, zu denen die Verbindung hergestellt werden soll. Die Abbildung 4.3 zeigt ein Beispiel für die Verbindung von zwei Prozessen mit einem Synch-Knoten, welcher über einen Hide-Knoten mit dem System verbunden ist. Abbildung 4.3: Die Systemebene mit zwei Prozessen und einem Hide- und Synch-Knoten.

84 76 KAPITEL 4. BENUTZERHANDBUCH Die angelegten Raten und Gewichte in den Definitionen können später für die Transitionen innerhalb der Prozesse genutzt werden. Sie werden genau wie die Konstanten mit name=wert im Editor eingegeben. Der Wert darf hierbei eine Gleitkomma- oder ganze Zahl sein. Konstanten dürfen durch ganze Zahlen oder arithmetische Ausdrücke definiert werden. Die Leistungsmaße besitzen jeweils einen Bezeichner, der frei gewählt werden kann. Ein Zustandsmaß besitzt ein Argument state, in dem das Zustandsmaß definiert wird. Dieses kann eine Verknüpfung mit Hilfe von booleschen Operationen von Prozessen, in denen Bedingungen für die Parameter in Klammern definiert werden, sein. Ein einfaches Beispiel für ein Zustandsmaß mit dem Bezeichner stm, welches die Wahrscheinlichkeit bestimmt, dass der Parameter a des Prozesses P gleich 1 ist, würde so definiert werden: stm P (a=1). Beim Mittelwertmaß wird neben dem Bezeichner noch ein Prozess und der Parameter, dessen Erwartungswert berechnet werden soll, in Klammern spezifiziert. Falls mehrere Instanzen des Prozesses vorliegen, kann die Instanz als weiteres Argument in Mengenklammern definiert werden. Ein Beispiel eines Mittelwertmaßes mit dem Bezeicher mv für den Prozess P und seiner ersten Instanz, bei dem für den Parameter a der Wert gesucht ist, würde lauten: mv P (a) {1}. Beim Durchsatz wird die Aktion angegeben, für welche der Durchsatz berechnet werden soll. Die resultierende Anzeige nach der Eingabe der definierten Konstanten, Raten, Gewichte und Leistungsmaße in den Definitionen des Editors folgt der originalen Caspa-Syntax. Zusammenfassend kann man sagen, dass in der Systemebene das Zusammenspiel der einzelnen sequentiellen Prozesse definiert wird. Die Prozessebene Um das Innere eines Prozesses zu definieren, wird der Prozessknoten doppelt angeklickt. Es öffnet sich ein neues Unterdiagramm, in welchem die Zustände und Transitionen definiert werden. Es können normale Zustände (States), Zustände für die Verbindung von mehreren Transitionen (EmptyStates) und ein Zustand zum Beenden des Prozesses (StopState) genutzt werden. Sie werden durch die Palette oder durch das Auswahlfeld erzeugt. Wird ein neuer normaler Zustand angelegt, müssen die Werte der Prozessparameter spezifiziert werden, um den Zustand des Prozesses anzugeben. Dabei sind mehrere Möglichkeiten geschaffen worden: Die Parameter durch Zahlwerte zu belegen. Die Parameternamen des Prozesses zu erhalten und durch Zuweisungen aus den Transitionen zu belegen (siehe unten). Arithmetische Ausdrücke mit den Parameternamen des Prozesses zu bilden. Ein EmptyState dient zur Verbindung zweier aufeinanderfolgender Transitionen ohne expliziten Zwischenzustand. Es muss demnach immer gewährleistet sein, dass ein EmptyState mittels einer Transition mit einem anderen Zustand verbunden wird. Ein StopState signalisiert das Ende eines Prozesses und kann somit keine ausgehenden Transitionen besitzen. Transitionen, die in diesem Zustand münden, veranlassen die Beendigung des Prozesses.

85 4.2. ARBEIT MIT DEM EDITOR 77 Transitionen werden unterschieden in Transition mit Raten oder Gewichten. Im Editor ist dies durch ein aufklappbares Menü innerhalb der Palette verdeutlicht. Durch Anklicken öffnet sich dieses Menü, in dem man den gewünschten Transitionstyp durch wiederholtes Anklicken auswählen kann. Um zwei Zustände zu verbinden, zieht man die Transition vom Quell- zum Zielzustand 1. Dabei erscheint ein Textfeld, in dem verschiedene Angaben zur Transition gemacht werden müssen. Sie werden, wie die Vorschau des Editors zeigt, durch Semikolon getrennt spezifiziert. Die Aktion definiert die nach außen sichtbare Aktion, die beim Zustandswechsel des Prozesses über diese Transition ausgeführt wird. Die Rate oder das Gewicht wird als zweiter Parameter angegeben. Hierbei dürfen Gleitkommazahlen, definierte Raten oder arithmetische Ausdrücke mit diesen verwendet werden. Danach erfolgt die Eingabe der Wächter (Guards), die die Zustandsparameter des Quellzustands für die Transition einschränken. Dabei können durchaus mehrere Wächter durch Kommas getrennt definiert werden. Die Eingabe erfolgt immer durch Eingabe des Parameternamen gefolgt von einem Relationszeichen und einem Wert oder Ausdruck, der den Parameter beschränken soll. Ist mindestens ein Parameter des Quellzustands mit einem Zahlwert belegt, so werden keine Wächter benötigt. Man hat trotzdem die Möglichkeit, unbelegte Parameter zu überwachen. Wird ein Wächter benötigt und der Benutzer gibt keinen ein, so setzt der Editor automatisch den * als Wächter. Dieser beschränkt die Transition in keiner Weise. Die Zuweisungen (assigns) erlauben dem Benutzer die Parameter des Zielzustands zu belegen, falls diese nicht schon belegt oder durch einen arithmetischen Ausdruck definiert sind. Sie werden jeweils durch Kommas getrennt in folgender Form spezifiziert: a:=a+1 oder b:=2. Hierbei drückt := (unbedingt erforderlich) die Zuweisung aus. Der Editor setzt automatisch Zuweisungen für nicht spezifizierte Parameter in der Form: a:=a. Weiterhin werden durch ihn auch unbenötigte Wächter und Zuweisungen verworfen. Wird ein Zustand mit anliegenden Transitionen verändert, so werden automatisch deren Werte nach diesem Schema angepasst. Ein EmptyState kann mehrere eingehende, aber nur eine ausgehende Transition besitzen 2. Für jeden Prozess ist nur ein StopState zugelassen, der über endlich viele eingehende Transitionen verfügen kann. Möchte man einen neuen Unterprozess definieren, der sich vom Namen des Prozesses unterscheidet, so kann der Name in den Eigenschaften in der unteren Sicht angepasst werden. Damit nicht aus Versehen der eigentliche Prozessname verändert werden kann, wurden der Name und die Parameter des Vaterprozesses in den Eigenschaften als schreibgeschützt festgelegt. Legt man einen neuen Unterprozess an, so kann dieser neue Parameter, in der Anzahl zum Vaterprozess verschieden, enthalten. Lediglich der erste definierte Unterzustand muss seine Parameter neu definieren, wie es bei Prozess schon notwendig war. Danach können beliebige Zustände mit dem Namen des Unterprozesses erzeugt werden, die nach endlicher Anzahl von Transitionen in einem Zustand des eigentlichen Prozesses enden müssen. Abbildung 4.4 zeigt ein Beispiel für einen Prozess mit den Parametern a und b. In diesem wurde ein neuer Unterprozess repair angelegt. Er besitzt selbst keine Parameter, aber setzt die des Zustands P(a,b) beim Verlassen jeweils auf 0. Die Zuweisungen sind aber auch direkt im 1 Die Verbindungsunterstützung aus der Systemebene ist hier nicht vorhanden. 2 Die Beschränkung auf eine ausgehende Kante hat implementierungstechnische Hintergründe. Dadurch entsteht aber in keiner Weise eine Einschränkung der Modellierung. Man kann dies ebenso durch die Verwendung von mehreren EmptyStates spezifizieren.

86 78 KAPITEL 4. BENUTZERHANDBUCH Abbildung 4.4: Die Prozessebene mit einem Unterprozess, EmptyState und StopState. Zustand bei den Parametern (siehe P(a,b+1)) möglich. Mit der Rate lambda wird der Prozess P über beide Transitionen (mit Aktion stoprequest und stopit ) beendet. Da der EmptyState (grüner Kreis) keine Parameter besitzt, sind keine Zuweisungen in seiner eingehenden und keine Wächter in seiner ausgehenden Kante möglich. Der StopState ist durch einen roten Kreis dargestellt und hat in diesem Beispiel nur eine eingehende Kante ohne Zuweisungen. Deutlich wird auch, dass der Editor die Zuweisung b:=b für die Transition mit der Aktion receive selbst vergeben hat. So können alle Prozesse mit ihren Zuständen und deren Übergängen definiert und so das Modell vervollständigt werden. Da auf der Prozessebene ein Bestandteil des Gesamtmodells geändert wird, muss das Modell nach dem Speichern und bei Rückkehr zur Systemebene synchronisiert werden. Um dabei Änderungen auf der Systemebene nicht zu verlieren, muss diese vor Betreten der Prozessebene gesichert werden. Es wurde unter Edit / Preferences eine Möglichkeit geschaffen, dies automatisch vom Editor übernehmen zu lassen. Die erste Option ermöglicht die automatische Synchronisation, falls dies nötig ist. Mit der zweiten Option wird die Systemebene bei Betreten der Prozessebene automatisch gesichert. Diese Optionen werden gespeichert und sind auch nach dem Neustart des Editors weiterhin so wirksam Validierung von Modellen Der Editor ist mit einer Funktion zur Validierung des eingegebenen Modells ausgestattet. Diese kann entweder über das Menü Diagram oder im Kontextmenü (per Rechtsklick auf der Zeichenfläche) der jeweiligen Ebene mittels Validate angestoßen werden. Dabei werden Fehler erkannt, welche für die spätere Auswertung mit dem Werkzeug Caspa vermieden werden sollen. Wurde ein Fehler erkannt, so erscheint ein roter Kreis in der oberen rechten Ecke des jeweiligen Modellelements. Wenn man mit dem Mauszeiger über diesen Kreis navigiert, erscheint ein

87 4.2. ARBEIT MIT DEM EDITOR 79 Fehlertext, der den erkannten Fehler darstellt. Die Abbildung 4.5 zeigt einen Fehler beim Validieren des oben genannten Modells der Systemebene. Die Meldung verdeutlicht, dass ein jeder Abbildung 4.5: Ein Validierungsfehler im Modell. Prozess mindestens einen Zustand benötigt, der den selben Namen trägt wie der Prozess selbst. Dieser ist der Startzustand des Prozesses und muss somit vorhanden sein. Weiterhin werden folgende Einschränkungen des Modells validiert: Vergabe korrekter Namen für Prozesse, Parameter, Konstanten, Raten, Gewichte und Bezeichner der Leistungsmaße (aus Buchstaben, Zahlen und Unterstrich) Kein Name oder Bezeichner ist eine reservierte Zeichenkette der Caspa-Syntax Keine mehrfache Vergabe von Prozessnamen und Unterzuständen Definition der Maximalwerte für Prozessparameter Korrekte Anzahl der Parameter für Links und Zustände Geforderte Anzahl der Verbindungen für Hide- und Synch-Knoten Zyklenfreiheitstest für alle mit der Wurzel verbundenen Knoten Raten und Gewichte der Transitionen sind definiert Falls ein Bezeichner oder Name keine gültige Zeichenkette oder eine reservierte Zeichenkette der Caspa-Syntax ist, erscheint die Fehlermeldung Check the name of.... Dann muss eine andere Zeichenkette gewählt werden. Gültige Zeichenketten beginnen in diesem Editor immer mit einem Buchstaben, da auch Caspa dies so fordert. Alle weiteren möglicherweise auftretenden Fehlermeldungen sind so formuliert worden, dass sie das Problem klar schildern. Der Benutzer ist somit jederzeit in der Lage, sein Modell nach diesen Regeln zu prüfen. Auf der Systemebene werden die Validierungsregeln der Prozessebene ebenfalls geprüft und am jeweiligen Prozess wie in Abbilung 4.5 kenntlich gemacht. Demnach muss der Benutzer nicht alle Prozesse auf deren Prozessebene selbstständig prüfen. Zyklen werden auch in nicht mit der Wurzel verbundenen Knoten gefunden, aber nur als Warnung eingestuft. Falls ein Unterzustand (mit anderem Namen) in einem Prozess nicht zu einem Zustand von ihm zurückkehrt, wird ebenfalls eine Warnung ausgegeben. Eine Warnung wird durch ein gelbes Dreieck dargestellt.

88 80 KAPITEL 4. BENUTZERHANDBUCH Export von Modellen Die nächste Funktionalität stellt den Export (Ausgabe) erstellter Modelle als Eingabedateien für Caspa zur Verfügung. Sie ist im Menü Diagram unter Export zu finden. Wählt der Benutzer diese Aktion aus, so wird automatisch das Modell validiert. Sollten dabei Fehler auftreten, wird der Export mit entsprechender Meldung abgebrochen. Erst nachdem das Modell korrekt ist oder nur Warnungen enthält, öffnet sich ein Dialog, der es dem Benutzer ermöglicht, den Dateinamen für die Eingabedatei zu spezifizieren. Nach dieser Auswahl erzeugt der Editor die Datei, welche später mit dem Werkzeug Caspa verwendet werden kann. Dabei werden alle Konstanten, Raten, Gewichte und Leistungsmaße aus den Definitionen ausgelagert. Nur mit der Wurzel verbundene Prozesse, Hide- und Synch-Knoten befinden sich im Caspa-Syntax in der exportierten Ausgabedatei. Neu erstellte Unterprozesse werden als Prozesse in Caspa-Syntax umgesetzt und durch die vorhandenen Transitionen mit den Zuständen des Prozesses verknüpft. Die Ausgabe wird nur für die Verwendung von Caspa benötigt. Ansonsten kann das Modell immer im Dateiformat mit der Endung ced gespeichert und später wieder geladen werden. Dadurch werden alle graphischen Eigenschaften beibehalten, was durch den Export in die Eingabedatei nicht erfolgt. Das Modell kann auf eine zweite Art ausgelagert werden. Durch die Menüaktion Save As Image ist der Benutzer in der Lage, die System-, Prozessebene oder markierte Bereiche der Zeichenfläche als Bilddatei zu speichern. In Abbildung 4.6 ist der Assistent zum Speichern des Diagramms als Bilddatei dargestellt. Neben der Auswahl des Zielverzeichnisses und des Dateinamens besteht die Möglichkeit, ein gewünschtes (der gebräuchlichen) Bildformate zu wählen. Diese Bilddateien können beliebig jedoch nicht mehr mit dem Editor, da strukturelle Informationen über das Modell nicht mehr extrahierbar sind, verwendet werden. Abbildung 4.6: Assistenten zum Speichern als Bilddatei Import von Eingabedateien Der Editor ist in der Lage, vorhandene Eingabedateien von Caspa einzulesen und als graphisches Modell zu repräsentieren. Diese Modelle können dann weiter bearbeitet und verändert werden. Unter dem Menüpunkt Import des Editors wurde diese Funktionalität abgelegt. Es erscheint ein Assistent, der zuerst die Eingabedatei und im nächsten Schritt die Diagrammdatei abfragt, unter der das Modell abgespeichert werden soll. Nach diesen Angaben öffnet sich das

89 4.2. ARBEIT MIT DEM EDITOR 81 neue Diagramm, welches alle definierten Bestandteile der Eingabedatei beinhaltet. Treten während des Einlesens Fehler in der Eingabedatei auf, so wird ein Fehler des Parsers ausgegeben. Dieser enthält die Zeile und Spalte sowie die erwartete Zeichenkette statt der vorhandenen. In bereits beschriebener Form kann der Benutzer nun auf der System- und den jeweiligen Prozessebenen das Modell editieren. Sollte die Systemebene keine expliziten Prozesse miteinander verknüpfen oder instanziieren, so erzeugt der Editor automatisch einen neuen Prozess Generated, in dem die spezifizierte Transition modelliert wird. Der Editor erzeugt durch eigenständige Ausrichtung der Modellobjekte eine übersichtliche Repräsentation der definierten Bestandteile. Parallelschaltungen von auch mehr als zwei Prozessen werden unter Beachtung der Klammerung mittels Synch-Knoten dargestellt. Prozesse, ihre Zustände und deren Übergänge sind in den jeweiligen Prozessebenen abgelegt. Der Editor führt den Import völlig selbstständig durch, so bedarf es dazu keiner weiteren Erklärung Ausführen von Caspa Der graphische Editor bietet als weitere Schnittstelle zu Caspa die Möglichkeit, es direkt aus dem Editor zu starten. Durch die Menüaktion Execute wird ein Assistent geöffnet, welcher die Eingabedatei und die ausführbare Datei von Caspa verlangt. Nachdem dieser Schritt abgehandelt wurde, folgt eine Seite (siehe Abbildung 4.7), auf der alle Ausführungseinstellungen zu Caspa spezifiziert werden können. Abbildung 4.7: Einstellung der Parameter des Assistenten zum Ausführen. Für jede Einstellung ist jeweils auf der rechten Seite in Klammern die Bedeutung angegeben.

90 82 KAPITEL 4. BENUTZERHANDBUCH So können zum Beispiel die Detailgrade der Information über die generierten Strukturen in Caspa, Erreichbarkeitsanalyse, Ausgabe eines Parsebaumes und die Methode der numerischen Analyse ausgewählt werden. Die Auswahl der Einstellung erfolgt durch Markieren der Kontrollkästchen. Bei Einstellungen mit mehreren Möglichkeiten sind diese in einem Auswahlfeld zu wählen. Die textuellen Eingaben werden vom Editor nach Korrektheit überprüft. Nur wenn man ein bestimmtes numerisches Verfahren angewählt hat, können für dieses weitere Parameter im unteren Bereich eingestellt werden. Dazu gehören beispielsweise die maximale Anzahl der Iterationen oder die maximale Speicherbelegung für Matrizen. Zur genaueren Erläuterung dieser Parameter wird auf [3, Anhang A] verwiesen. Die Standardparameter für die Ausführung sind vom Editor bereits aktiviert. Sollten aktivierte Dateien nicht spezifiziert sein, kann die nächste Seite nicht erreicht werden. Der Assistent zeigt dies durch eine Fehlermeldung im oberen, weißen Bereich. Die Auswahl erfolgt entweder durch direkte Eingabe im Textfeld oder durch bequeme Auswahl in einem Dialogfenster, welches mit der Schaltfläche rechts neben dem Textfeld erreicht werden kann. Die letzte Seite des Assistenten, dargestellt in Abbildung 4.8, stößt die Ausführung von Caspa mit den spezifizierten Parametern und Dateiangaben an. Dazu muss der Benutzer die Schalt- Abbildung 4.8: Die Ausgabeseite des Assistenten zum Ausführen. fläche Run betätigen. Im Hintergrund wird Caspa gestartet und dessen Ausgaben im großen Textfeld angezeigt. Sollte Caspa Fehlermeldungen generieren, werden diese in der erscheinenden, aufklappbaren Box im unteren Bereich in roter Textfarbe ausgegeben. Für den Benutzer wird in der untersten Textzeile die verwendete Kommandozeile des Aufrufes dargestellt. Die Ausführung kann bei komplexen Spezifikationen recht lang dauern. Daher besteht jederzeit die Möglichkeit, diese durch eine Betätigung der Schaltfläche Break zu stoppen. Dieser ist nur