Entwicklung eines domänenspezifischen UML Diagramms zur Benutzeroberflächenmodellierung

Diplomarbeit von Stefan Kuhn

Einleitung:

Bisher wurde bei Orientation in Objects GmbH (OiO) PowerPoint Folien zur Graphical User Interface (GUI) Beschreibung eingesetzt, oder Kunden nutzen einen GUI-Builder, um ihre Anforderungen zu spezifizieren, welche nach programmiert wurden. Hieraus entstand die Motivation auch das GUI mittels Modellen zu beschreiben, welche zukunftsorientiert auf einer Standardsprache basieren sollen, um sie mit möglichst vielen Editoren bearbeiten zu können.

Die fachliche Abstraktion domänenspezifischer Diagramme ermöglicht Domänenexperten oft erst formale Modelle zu erstellen. Die Unified Modeling Language (UML) ermöglicht zwar die Verwendung domänenspezifischer Terminologie mittels Stereotypen, ihre dreizehn Diagramme sind jedoch ein Notationsstandard (Jec04) und nicht auf die Domäne anpassbar. Die UML ist ‘zunächst nicht einfach genug, um effektiv mit einer graphischen Syntax arbeiten zu können’ (Sta07)Es gilt einen domänenspezifischen graphischen Editor zur GUI Modellierung zu entwickeln, welcher UML konforme Modelle erstellt.

Der Editor soll weder ein technologiespezifischer GUI-Builder, noch ein UML Werkzeug sein. Dem Ansatz am nächsten liegt das Werkzeug Argoi, welches das Metamodell von UML erweitert, um UMLi (UMLi08) Modelle zu erstellen. Jedoch kann aufgrund des verwendeten Erweiterungsmechanismus das Modell nicht von anderen UML Werkzeugen geöffnet werden. Dem Autor ist kein vergleichbarer Ansatz bekannt.

Thematisch liegt der Fokus auf Visuellen Sprachen, der UML sowie Modellgetriebene Softwareentwicklung.

Die Arbeit ist in neun weitere Kapitel gegliedert. Zunächst werden die Grundlagen und die Anforderungen beschrieben. In der Sprachdefinition werden die Elemente des Problemraums identifiziert und formal festgehalten. In Notationselemente wird die entwickelte Notation der Sprachelemente vorgestellt. Nachdem die Werkzeugwahl begründet wird folgen die technischen Kapitel. Das Kapitel Generativer Entwicklungsprozess von GMF stellt einen übertragbaren, werkzeugspezifischen Entwicklungsprozess vor. Danach wird das Design des Graphischen Editors (GE) anhand von Modellen und Meta-Modellen beschrieben. Der Schwerpunkt des folgenden Kapitels Implementierung liegt auf der aufgabenspezifischen Anpassung der Transformationsdefinition. Die Arbeit schließt mit einer Kritik der verwendeten Werkzeuge und der eigenen Entwicklung ab.

Inhaltsverzeichnis:

	INHALTSVERZEICHNIS	II
	ABBILDUNGSVERZEICHNIS	VI
1.	EINLEITUNG	1
2.	GRUNDLAGEN	3
2.1	BEGRIFFLICHKEITEN	3
2.2	MODEL DRIVEN SOFTWARE DEVELOPMENT (MDSD)	3
2.3	UNIFIED MODELING LANGUAGE (UML)	4
2.4	ECLIPSE MODELING FRAMEWORK (EMF)	4
2.4.1	EINLEITUNG	4
2.4.2	HINFÜHRUNG	5
2.4.3	ECORE (META) MODEL	6
2.4.4	VERHÄLTNIS VON ECORE UND MOF	6
2.4.5	GENERATOR MODELL	7
2.4.6	GENERAT	7
2.4.7	PERSISTENZ	8
2.4.8	DYNAMISCHES EMF	8
2.4.9	EMF.EDIT	8
2.5	DRAW2D	9
2.6	GRAPHICAL EDITING FRAMEWORK (GEF)	10
2.6.1	EINLEITUNG	10
2.6.2	HINFÜHRUNG	11
2.6.3	ÜBERBLICK	11
2.6.4	BASISKOMPONENTEN	11
2.7	GRAPHICAL MODELING FRAMEWORK (GMF)	15
2.7.1	EINLEITUNG	15
2.7.2	LAUFZEITINFRASTRUKTUR (RUNTIME)	15
2.7.3	GENERATIVE ARCHITEKTUR	17
2.8	XPAND TEMPLATE SPRACHE	20
3.	ANFORDERUNGEN	24
3.1	FUNKTIONAL	24
3.1.1	KONFORMITÄT ZUR ABSTRAKTEN UML SYNTAX	24
3.1.2	USER INTERFACE (UI)	24
3.2	ANFORDERUNGEN ZUR UML-ABBILDUNG	26
3.3	ANFORDERUNGEN DES GRAPHISCHEN EDITORS	26
3.4	NICHT FUNKTIONAL	26
3.5	WEITERES VORGEHEN	27
4.	SPRACHDEFINITION	29
4.1.1	EINLEITUNG	29
4.2	VORSTELLUNG VERGLEICHBARER KONZEPTE VON (MÜL07) :	29
4.3	KONZEPTIONELLE LÖSUNG	30
4.3.1	IDENTIFIKATION UND EINTEILUNG STATISCHER UI ELEMENTE	30
4.3.2	ABWEICHUNGEN	31
4.3.3	DATEN UND ELEMENTE ZUR DATENBINDUNG	32
4.3.4	KLASSIFIZIERUNG	33
4.4	UML PROFILABBILDUNG	33
4.4.1	KLASSEN UND AUFZÄHLUNGEN	33
4.4.2	ASSOZIATIONEN UND CONTAINMENTS	36
5.	NOTATIONSELEMENTE	42
5.1.1	ELEMENTE DES UI	42
5.1.2	PRIMITIVE ELEMENTE	42
5.1.3	KOMPLEXE ELEMENTE	42
5.1.4	CONTAINER ELEMENTE	43
5.1.5	DATENHALTENDE ELEMENTE	43
5.1.6	VERBINDUNGEN	44
6.	WERKZEUGWAHL	45
6.1	UML2	45
6.2	FRAMEWORK DES GRAPHISCHEN EDITORS	45
7.	GENERATIVER ENTWICKLUNGSPROZESS VON GMF	47
7.1	EINLEITUNG	47
7.2	ANPASSUNGSMÖGLICHKEITEN	47
7.2.1	ANPASSUNGEN AM QUELLCODE	47
7.2.2	ANPASSUNG DURCH EXTENSIONS	47
7.2.3	TEMPLATEANPASSUNGEN ANHAND EINES ERBENDEN GENERATORMODELLS	48
7.2.4	TEMPLATEANPASSUNGEN ANHAND EINES ERWEITERNDEN GENERATORMODELLS	48
7.3	EMPFOHLENER ENTWICKLUNGSPROZESS	48
8.	DESIGN DES GRAPHISCHEN EDITORS	52
8.1	DESIGNENTSCHEIDUNG METAMODELL	52
8.2	TOOLING MODEL - GMFTOOL	54
8.3	GRAPHICAL MODEL - GMFGRAPH	56
8.4	MAPPING MODEL - GMFMAP	57
8.4.1	EINLEITUNG	57
8.4.2	ÜBERSICHT	57
8.4.3	PRIMITIVES ELEMENT	58
8.4.4	UICONTAINER	59
8.4.5	UIDATAPROVIDER	60
8.4.6	UIDATARELATION	60
8.4.7	ZUSAMMENFASSUNG	62
8.5	ERWEITERUNGSMETAMODELLE	62
8.5.1	GUIGENMODEL	63
8.5.2	GUIUMLGENMODEL	66
9.	IMPLEMENTIERUNG	72
9.1	EINLEITUNG	72
9.1.1	PLATTFORM	72
9.1.2	STRUKTUR DER QUELLEN	72
9.1.3	PROFIL-IMPLEMENTIERUNG	73
9.1.4	IMPLEMENTIERUNG DER NOTATIONSELEMENTE	73
9.1.5	KONFIGURATION MITTELS VARIABLEN	74
9.1.6	KONFIGURATION MITTELS EINES BILDES	74
9.1.7	FIGUREN MITTELS ‘GRAPHICS’	74
9.1.8	ZUSTANDSABHÄNGIGE FIGUREN	75
9.2	GRAPHISCHER EDITOR	75
9.2.1	ANPASSUNGEN AM ERWEITERUNGSMODELLFREIEN GENERATORMODELL	76
9.3	TEMPLATES	76
9.3.1	EINLEITUNG	76
9.3.2	FEHLERMELDUNGEN	77
9.3.3	PROFILANWENDUNG BEIM LADEN	77
9.3.4	PROPERTY TAB	77
9.3.5	STEREOTYPABHÄNGIGE BESCHRIFTUNGEN	78
9.3.6	KOMFORTWERKZEUGE	80
9.3.7	STEREOTYPISIERTE KNOTEN	81
9.3.8	ATTRIBUTSABHÄNGIGES FIGURE	82
9.3.9	KANTEN	82
9.3.10	SPEZIELLE UIDATARELATION-KANTE	83
9.3.11	UICONTAINMENTASSOCIATION	84
9.3.12	BEKANNTE FEHLER	86
10.	FAZIT	88
10.1	KRITIK AN DEN VERWENDETEN WERKZEUGEN	88
10.1.1	EMF	88
10.1.2	ECLIPSE UML2	88
10.1.3	GMF-RUNTIME	89
10.1.4	GMF-TOOLING	89
10.2	KRITISCHE WERTUNG	90
10.2.1	ABSTRAKTE SYNTAX	90
10.2.2	GRAPHISCHER EDITOR	90
10.2.3	ANSATZ	91
10.3	AUSBLICKE	91
10.3.1	ABSTRAKTE SYNTAX	91
10.3.2	GRAPHISCHER EDITOR	92
	LITERATURVERZEICHNIS	93
	EIDESSTATTLICHE ERKLÄRUNG	97
	ANHANG A - BEISPIELE	98
	ANHANG B - ANPASSUNGSMÖGLICHKEITEN	103
	ANPASSUNGEN IM QUELLCODE	104
	ANPASSUNGEN DURCH EXTENSIONS	105
	ANPASSUNGEN AM GMF GENERATORMODELL	106
	STATISCHE ANPASSUNG DER TEMPLATES	107
	TEMPLATE-ANPASSUNGEN ANHAND EINES EINDEUTIGEN ATTRIBUTS:	108
	TEMPLATE-ANPASSUNGEN ANHAND EINES ERBENDEN GENERATORMODELL	109
	TEMPLATE-ANPASSUNGEN ANHAND ERWEITERNDER GENERATORMODELLE	110
	ANPASSUNG DER M2M TRANSFORMATION IN DER ‘GENERATOR’ KLASSE	118
	EIGENSTÄNDIGES GENERATOR PROJEKT	119
	ANHANG C - WEITERE TEMPLATEANPASSUNGEN	120

Textprobe:

Kapitel 7., Generativer Entwicklungsprozess von GMF Die Architektur von GMF bietet eine Reihe von Anpassungsmöglichkeiten. In diesem Kapitel werden die wesentlichen vorgestellt. Im Anschluss wird eine übertragbare und aufgabenstellungsunabhängige Vorgehensweise vorgestellt. Dies ist erforderlich, da ihr Kernkonzept nicht in den betrachteten Editoren oder Beispielen berücksichtigt wird und auf vier Präsentationsfolien (Tik07)dokumentiert ist. Diese Vorgehensweise wurde für den im Rahmen dieser Arbeit zu erstellenden GE verwendet. Abgewichen wurde von der konsequenten Verwendung von Xpand Aspekten aufgrund eines Fehlers (Web07) in der verwendeten GMF Version. Ist im Folgenden von einem Aspekt die Rede, ist ein Software Aspekt, also ein Aspekt im eigentlichen Sinne gemeint. Ein oAW-Aspekt qualifiziert das technische, aus Aspekt orientierter Programmierung bekannte Hilfsmittel der openArchitectureWare Template-Sprache Xpand.

Anpassungsmöglichkeiten:

Die wesentlichen Anpassungsmöglichkeiten bei GMF werden kurz vorgestellt. Eine ausführliche Betrachtung mit Vorgehensweise, Wertung, Verwendungsempfehlung und verfügbaren Implementierungen ist im Anhang B – Anpassungsmöglichkeiten S. VI zu finden.

Anpassungen am Quellcode:

Das Generat wird angepasst und die veränderten Methoden mittels (at)generated NOT vor Überschreibung geschützt.

Anpassung durch Extensions:

Die Eclipse Service-Plattform und bereitgestellte GMF Extension-Points werden verwendet um Erweiterungen hinzuzufügen. Hervorzuheben ist, dass sich diese Erweiterungsmöglichkeit sehr gut zum Anpassen von fremden Editoren eignet.

Templateanpassungen anhand eines erbenden Generatormodells:

Ein eigenes Meta-Modell wird erstellt, dessen Meta-Klassen von denen der gmfgen-Meta-Klassen erben. Die Templates werden auf die Spezialisierungen angepasst und Instanzen von Meta-Klassen im Generatormodell werden ersetzt.

Templateanpassungen anhand eines erweiternden Generatormodells:

Ein eigenes Meta-Modell wird erstellt, dessen Meta-Klassen Referenzen auf gmfgen-Meta-Klassen besitzen. Dieses Konzept ist in der MDSD unter dem Begriff ‘Model Marking’ (Sta07)bekannt. Instanzen der gmfgen-Meta-Klassen im Generatormodell werden von Instanzen der eigenen Meta-Klassen referenziert. Anpassungen in den Templates greifen, wenn eine gmfgen-Meta-Klassen Instanz markiert ist.

Empfohlener Entwicklungsprozess:

In diesem Abschnitt wird der empfohlene Entwicklungsprozess vorgestellt und näher erläutert. Das zentrale Konzept ist das erweiternde Generatormodell.

Normale initiale Schritte:

Die ersten Schritte sind mit denen der normalen GMF Entwicklung identisch. Domänenmodell, Tooling-Modell, Graph-Modell und Mapping-Modell sind zu erstellen. Um spätere Verschiebungen innerhalb des Generatormodells zu reduzieren, bietet es sich im an, bereits im Mapping Modell möglichst viele Elemente, wenn auch nicht funktional, zu berücksichtigen. Im Anschluss wird ein Generatormodell erzeugt.

Namensgebung im Generatormodell:

Für eine Instanz jedes Typs auf gleicher Hierarchieebene sind die zu erzeugenden Klassennamen anzupassen. Ein erneutes Erzeugen des Generatormodells zeigt welche Änderungen in der verwendeten Version erhalten bleiben, wo sie sich also lohnen. Die standardmäßige Benamung von GMF ist in nicht trivialen Situationen nicht aussagenkräftig. In Hinblick auf zu erwartenden Anpassungen an den generierten Klassen ist der Mehrwert einer aussagekräftigen Namensgebung groß.

Erste Anpassungen:

Der Quellcode wird generiert und muss angepasst werden. Änderungen sind bis zum Funktionieren eines mustergültigen Einzelfalls vorzunehmen, angepasste Methoden sind mit @generated NOT auszuzeichnen. Wurde die Anpassung erfolgreich für den Beispielfall getestet, gilt es sie für eine höhere Abstraktionsebene verfügbar zu machen. Sie gedankliche einer Metaklasse zuzuordnen bietet sich an, um später nicht die technisch einfachste zu wählen.

Initiales erstellen eines Metamodells:

Der folgende Schritt ist nur einmalig für ein Projekt notwendig. Es gilt zuerst ein eigenes Meta-Modell zum Testen zu erstellen und das korrekte Laden in das Generatormodell sicherzustellen. Hierfür wird ein normales Ecore Modell erstellt, ein Wurzel Element angelegt und das gmfgen-Meta-Modell geladen. Dem Wurzelelement wird eine Metaklasse angehängt und ihr eine Referenz auf eine Metaklasse des gmfgen-Metamodells hinzugefügt. Im Zusammenhang mit dem Laden des Erweiterungsmodells existierte ein Fehler in der verwendeten GMF Version. Dieser macht es erforderlich mittels Text- oder XML-Editor im Generatormodell die Option xsi:schemaLocation hinzuzufügen und korrekt zu belegen. Alternativ kann der Fehler auch mit dem Bugfix (Kuh08) behoben werden. Wird keine der beiden Varianten gewählt muss das Meta-Modell generiert und als Eclipse PlugIn eingebunden werden. Dies behindert ein ‘Lebendiges Metamodell’ (Sta07) . Ist das Erweiterungsmodell geladen, sind Instanzen der zu erweiternden gmfgen-Metaklasse nicht von einer Instanz der eigenen Metaklasse referenzierbar. Obwohl die in beiden Modellen verwendeten gmfgen-Meta-Modelle ein Wurzelelement mit identischem Namensraumattribut besitzen, verwenden die beiden Modelle unterschiedliche Pfadangaben zu ihnen. Für den gmfgen-Editor sind die Meta-Modelle folglich nicht identisch und für das Erweiterungsmodell existiert keine gültige, referenzierbare Instanz der zu erweiternden Metaklasse. Die Referenz zum gmfgen-Meta-Modell muss mittels eines Text- oder XML-Editors aus dem Kopf des Generatormodells kopiert, und alle Referenzen zum gmfgen-Meta-Modell in dem Erweiterungsmodell hierdurch ersetzt werden. Wurde dieser Schritt korrekt vorgenommen, lädt der Ecore Editor im weiteren Projektverlauf das gmfgen-Meta-Modell über die ‘richtige’ Referenz. Später erstellte Meta-Klassen werden nun mit der im Generatormodell verwendeten Referenz gespeichert, ein späteres korrigieren dieser entfällt also. Die zum Testen erstellte Metaklasse ist bis zum Erstellen der ersten produktiv einzusetzenden Metaklasse nicht zu löschen.

Erstellen von Meta-Klassen:

Im Normalfall ist eine eigene Metaklasse nach einer Anpassung des Generats zu erstellen. Die Ausnahme stellen Anpassungen da, die einem bereits vorhandenen Aspekt zugeordnet werden können und für die es bereits eine zu diesem Aspekt gehörende, den zu erweiternden Typ referenzierende Metaklasse existiert. Müssen für einen Aspekt mehrere Meta-Klassen referenziert werden, bietet es sich an die referenzierenden Klassen einer Gruppe, bzw. einem Container innerhalb des Erweiterungsmodells zuzuordnen. Da Instanzen im Erweiterungsmodell an sich nur Instanzen im Generatormodell referenzieren müssen, ist ihre Position im Erweiterungsmodell quasi frei wählbar. Sie lassen sich also später noch gut ordnen und Referenzmultiplizitäten sind änderbar. Wurde eine Metaklasse erstellt ist zu klären, ob oder welche Eigenschaften sie besitzen muss. Besitzt sie lediglich eine Referenz auf einen gmfgen-Typ, ist sie mit den aus Java bekannten ‘Marker’-Interfaces wie ‘Serializable’ vergleichbar. Eine besessene Eigenschaft kann beispielsweise mittels eines String Attributs den Namen einer Variablen tragen oder andere Modellelemente referenzieren. Im letzten Fall ist es selbstverständlich möglich Elemente eines dritten Modells, wie z.B. Stereotype eines UML Profils zu referenzieren.

Implementierung der Templates:

Der Fall einer referenzierten gmfgen-Instanz ist nun in den Templates zu berücksichtigen und die Anpassungen im Falle eines referenzierenden, bestimmten Metatyps umzusetzen. Hierbei ist die statische Struktur des GMF Template Verzeichnisses zu berücksichtigen und nicht zu ändern. Zudem sollten eigene Änderungen möglichst außerhalb eines bestehenden DEFINE Blocks vorgenommen werden. Sofern möglich ist dieser mittels eines oAW-Aspekts zu dekorieren oder der zu ändernde Teilbereich in einen eigenen DEFINE Block zu verschieben und dieser zu dekorieren. Um referenzierende Elemente zu erhalten ist eine oAW-Extension in xpt::EMFUtils zu verwenden. Referenzierende Objekte auf das aktuelle erhält man mittels getReferencingObjects(this). Die zurückgelieferte Menge ist mittels .typeSelect(Metaklasse) auf Instanzen einer Metaklassen zu filtern, auf eine nicht leere Menge zu prüfen und z.B. das nullte Element der Menge auf die Metaklasse zu ‘casten’. Wurde das Template angepasst, wird @generated NOT der Methode entfernt, erneut generiert und ggf. Fehler beseitigt. Dieser Vorgang ist zu wiederholen bis alle Änderungen durch die Templates vorgenommen werden. Das Ergebnis ist nun erneut zu testen, hierbei sind insbesondere Zustände die in der exemplarischen Lösung nicht überprüft werden konnten zu berücksichtigen.

Nächste Iteration:

Da die M2M Transformation vom Mapping-Modell zum Generatormodell Erweiterungsmodelle entfernt, ist vor diesem Vorgang das Generatormodell zu kopieren. Nachdem die M2M Transformation durchgeführt wurde sind beide Modelle mit einem Text- oder XML-Editor zu öffnen und der Kopf des alten Generatormodells, sowie das am Ende liegende Erweiterungsmodell in das neue Generatormodell zu kopieren.

Im weiteren Projektverlauf wird auffallen, dass das gmfgraph-Modell vergleichsweise schlecht skaliert. Es sollte seine Möglichkeit genutzt werden, lediglich die Schnittstelle von ‘legacy’ Draw2D Figuren zu beschreiben. Sollen mühevoll erstellte Figuren fein justiert werden, kann aus einem bestehenden gmfgraph-Modell ein Plugin welches Draw2D Figuren sowie ein gmfgraph-Modell mit ausschließlich Schnittstellendefinitionen beinhaltet, generiert werden.

Design des Graphischen Editors:

Dieses Kapitel klärt das Softwaredesign des GE anhand der dafür von GMF entwickelten Sprache, den fachlichen Modell gmftool, gmfgraph und gmfmap sowie den Konzepten der eigens entwickelten Sprachen, den eigenen Metamodellen. Es wird den Empfehlungen gefolgt das Modell als Sprache innerhalb des Projekts zu verwenden (Sta07) . Ist der Leser bereits mit GEF vertraut, würde er an dieser Stelle eine Beschreibung des konzeptionellen Aufbaus von EditParts, EditPolicies sowie Commands und den Argumenten der Requests erwarten. Diese Konzepte sind implizit in den Modellen enthalten. Bevor das Design anhand der Modelle erklärt wird, ist zu entscheiden, ob der GE nativ auf UML Modellen aufsetzt, oder ob von und zu ihnen abgebildet bzw. transformiert wird.

Designentscheidung Metamodell:

Die Entscheidung, ob der GE direkt auf einem UML Modell aufbaut oder sein eigenes Metamodell benutzt, ist fundamental. Setzt der GE nicht direkt auf UML Modellen auf, muss ein eigenes Metamodell für ihn entwickelt werden, welches mindestens die Konzepte des Problemraums beschreibt. Diese Überlegung bietet sich aufgrund folgender fünf Eigenschaften der nicht angepassten, generativen Architektur an.

Sie unterstützt nicht mehrere Metamodelle im gleichen Editor. Wie in den Grundlagen zu Eclipse UML2 beschrieben, erweitert ein UML Profil das UML Metamodell.

Dynamisches EMF wird nicht unterstützt. Wie ebenfalls in den Grundlagen zu Eclipse UML2 beschrieben, werden die Elemente der Profile mittels dynamischem EMFs erzeugt.

Es fehlt das Konzept der ‘Element Type Registry’ oder ein vergleichbares. Das gmfgen-Metamodell setzt es zwar unvollständig um, Anpassungsmöglichkeiten fehlen jedoch. Am direkten Importieren des Domänenmodells ins Mapping-Modell wird das fehlende Konzept ersichtlich. Ihm am nächsten kommen die im Mapping-Modell möglichen ‘Constraints’.

Nicht primitive Abbildungen, wie sie in den Abbildungsvorschriften zu UML Profilen definiert wurden, werden nicht unterstützt.

In Metamodellen definiertes Verhalten der Metaklassen, also ihre Funktionen, können nicht genutzt werden. Deshalb ist es z.B. nicht möglich eine UML Assoziation zu erstellen ohne den Quellcode anzupassen.

Wird in diesem Kapitel von einer M2M Transformation gesprochen, bleibt bewusst offen ob sie direkt im Speicher oder in einem zusätzlichen Schritt durchgeführt wird. Die unterschiedlichen Überführungsmöglichkeiten von einem eigenen Metamodell zu dem von UML mitentwickelten Profil werden vorgestellt und die Wahl begründet.