Entwicklung eines domänenspezifischen UML Diagramms zur Benutzeroberflächenmodellierung
©2008
Diplomarbeit
128 Seiten
Zusammenfassung
Inhaltsangabe: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 […]
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 […]
Leseprobe
Inhaltsverzeichnis
Stefan Kuhn
Entwicklung eines domänenspezifischen UML Diagramms zur
Benutzeroberflächenmodellierung
ISBN: 978-3-8366-1458-0
Druck Diplomica® Verlag GmbH, Hamburg, 2008
Zugl. Hochschule Furtwangen, Furtwangen, Deutschland, Diplomarbeit, 2008
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplom.de, Hamburg 2008
Printed in Germany
ii
Inhaltsverzeichnis
INHALTSVERZEICHNIS
II
ABBILDUNGSVERZEICHNIS
VI
1 EINLEITUNG
1
2 GRUNDLAGEN
3
2.1 B
EGRIFFLICHKEITEN
3
2.2 M
ODEL
D
RIVEN
S
OFTWARE
D
EVELOPMENT
(MDSD)
3
2.3 U
NIFIED
M
ODELING
L
ANGUAGE
(UML)
4
2.4 E
CLIPSE
M
ODELING
F
RAMEWORK
(EMF)
5
2.4.1
E
INLEITUNG
5
2.4.2
H
INFÜHRUNG
5
2.4.3
E
CORE
(M
ETA
)
M
ODEL
6
2.4.4
V
ERHÄLTNIS VON
E
CORE UND
MOF
7
2.4.5
G
ENERATOR
M
ODELL
8
2.4.6
G
ENERAT
8
2.4.7
P
ERSISTENZ
9
2.4.8
D
YNAMISCHES
EMF
9
2.4.9
EMF.E
DIT
9
2.5 D
RAW
2D
10
2.6 G
RAPHICAL
E
DITING
F
RAMEWORK
(GEF)
11
2.6.1
E
INLEITUNG
11
2.6.2
H
INFÜHRUNG
12
2.6.3
Ü
BERBLICK
12
2.6.4
B
ASISKOMPONENTEN
13
2.7 G
RAPHICAL
M
ODELING
F
RAMEWORK
(GMF)
17
2.7.1
E
INLEITUNG
17
2.7.2
L
AUFZEITINFRASTRUKTUR
(R
UNTIME
)
17
2.7.3
G
ENERATIVE
A
RCHITEKTUR
19
2.8 X
PAND
T
EMPLATE
S
PRACHE
23
3 ANFORDERUNGEN
25
3.1 F
UNKTIONAL
25
3.1.1
K
ONFORMITÄT ZUR ABSTRAKTEN
UML
S
YNTAX
25
3.1.2
U
SER
I
NTERFACE
(UI)
25
3.2 A
NFORDERUNGEN ZUR
UMLA
BBILDUNG
27
3.3 A
NFORDERUNGEN DES
G
RAPHISCHEN
E
DITORS
27
3.4 N
ICHT FUNKTIONAL
28
3.5 W
EITERES
V
ORGEHEN
28
4 SPRACHDEFINITION
30
4.1.1
E
INLEITUNG
30
4.2 V
ORSTELLUNG VERGLEICHBARER
K
ONZEPTE VON
[M
ÜL
07]
:
30
4.3 K
ONZEPTIONELLE
L
ÖSUNG
31
4.3.1
I
DENTIFIKATION UND
E
INTEILUNG STATISCHER
UI
E
LEMENTE
31
4.3.2
A
BWEICHUNGEN
33
4.3.3
D
ATEN UND
E
LEMENTE ZUR
D
ATENBINDUNG
33
4.3.4
K
LASSIFIZIERUNG
34
4.4 UML
P
ROFILABBILDUNG
35
4.4.1
K
LASSEN UND
A
UFZÄHLUNGEN
35
4.4.2
A
SSOZIATIONEN UND
C
ONTAINMENTS
38
5 NOTATIONSELEMENTE
44
5.1.1
E
LEMENTE DES
UI
44
5.1.2
P
RIMITIVE
E
LEMENTE
44
5.1.3
K
OMPLEXE
E
LEMENTE
44
5.1.4
C
ONTAINER
E
LEMENTE
44
5.1.5
D
ATENHALTENDE
E
LEMENTE
45
5.1.6
V
ERBINDUNGEN
46
6 WERKZEUGWAHL
47
6.1 UML2
47
6.2 F
RAMEWORK DES
G
RAPHISCHEN
E
DITORS
47
7 GENERATIVER ENTWICKLUNGSPROZESS VON GMF
49
7.1 E
INLEITUNG
49
7.2 A
NPASSUNGSMÖGLICHKEITEN
49
7.2.1
A
NPASSUNGEN AM
Q
UELLCODE
49
7.2.2
A
NPASSUNG DURCH
E
XTENSIONS
49
7.2.3
T
EMPLATEANPASSUNGEN ANHAND EINES ERBENDEN
G
ENERATORMODELLS
50
7.2.4
T
EMPLATEANPASSUNGEN ANHAND EINES ERWEITERNDEN
G
ENERATORMODELLS
50
iv
7.3 E
MPFOHLENER
E
NTWICKLUNGSPROZESS
50
8 DESIGN DES GRAPHISCHEN EDITORS
55
8.1 D
ESIGNENTSCHEIDUNG
M
ETAMODELL
55
8.2 T
OOLING
M
ODEL
GMFTOOL
58
8.3 G
RAPHICAL
M
ODEL
GMFGRAPH
60
8.4 M
APPING
M
ODEL
GMFMAP
61
8.4.1
E
INLEITUNG
61
8.4.2
Ü
BERSICHT
61
8.4.3
P
RIMITIVES
E
LEMENT
62
8.4.4
UIC
ONTAINER
63
8.4.5
UID
ATA
P
ROVIDER
64
8.4.6
UID
ATA
R
ELATION
65
8.4.7
Z
USAMMENFASSUNG
66
8.5 E
RWEITERUNGSMETAMODELLE
66
8.5.1
GUI
G
EN
M
ODEL
67
8.5.2
GUI
UMLG
EN
M
ODEL
70
9 IMPLEMENTIERUNG
74
9.1 E
INLEITUNG
74
9.1.1
P
LATTFORM
74
9.1.2
S
TRUKTUR DER
Q
UELLEN
74
9.1.3
P
ROFIL
I
MPLEMENTIERUNG
75
9.1.4
I
MPLEMENTIERUNG DER
N
OTATIONSELEMENTE
75
9.1.5
K
ONFIGURATION MITTELS
V
ARIABLEN
76
9.1.6
K
ONFIGURATION MITTELS EINES
B
ILDES
76
9.1.7
F
IGUREN MITTELS
,,G
RAPHICS
"
76
9.1.8
Z
USTANDSABHÄNGIGE
F
IGUREN
77
9.2 G
RAPHISCHER
E
DITOR
77
9.2.1
A
NPASSUNGEN AM ERWEITERUNGSMODELLFREIEN
G
ENERATORMODELL
78
9.3 T
EMPLATES
79
9.3.1
E
INLEITUNG
79
9.3.2
F
EHLERMELDUNGEN
79
9.3.3
P
ROFILANWENDUNG BEIM
L
ADEN
80
9.3.4
P
ROPERTY
T
AB
80
9.3.5
S
TEREOTYPABHÄNGIGE
B
ESCHRIFTUNGEN
81
9.3.6
K
OMFORTWERKZEUGE
83
9.3.7
S
TEREOTYPISIERTE
K
NOTEN
84
9.3.8
A
TTRIBUTSABHÄNGIGES
F
IGURE
85
9.3.9
K
ANTEN
86
9.3.10 S
PEZIELLE
UID
ATA
R
ELATION
K
ANTE
87
9.3.11 UIC
ONTAINMENT
A
SSOCIATION
88
9.3.12 B
EKANNTE
F
EHLER
90
10 FAZIT
92
10.1 K
RITIK AN DEN VERWENDETEN
W
ERKZEUGEN
92
10.1.1 EMF
92
10.1.2 E
CLIPSE
UML2
92
10.1.3 GMFR
UNTIME
93
10.1.4 GMFT
OOLING
93
10.2 K
RITISCHE
W
ERTUNG
94
10.2.1 A
BSTRAKTE
S
YNTAX
94
10.2.2 G
RAPHISCHER
E
DITOR
95
10.2.3 A
NSATZ
95
10.3 A
USBLICKE
96
10.3.1 A
BSTRAKTE
S
YNTAX
96
10.3.2 G
RAPHISCHER
E
DITOR
96
LITERATURVERZEICHNIS
98
EIDESSTATTLICHE ERKLÄRUNG
103
ANHANG A BEISPIELE
I
ANHANG B ANPASSUNGSMÖGLICHKEITEN
V
A
NPASSUNGEN IM
Q
UELLCODE
VI
A
NPASSUNGEN DURCH
E
XTENSIONS
VII
A
NPASSUNGEN AM
GMF
G
ENERATORMODELL
VIII
S
TATISCHE
A
NPASSUNG DER
T
EMPLATES
X
T
EMPLATE
A
NPASSUNGEN ANHAND EINES EINDEUTIGEN
A
TTRIBUTS
:
XI
T
EMPLATE
A
NPASSUNGEN ANHAND EINES ERBENDEN
G
ENERATORMODELL
XII
T
EMPLATE
A
NPASSUNGEN ANHAND ERWEITERNDER
G
ENERATORMODELLE
XIII
A
NPASSUNG DER
M2M
T
RANSFORMATION IN DER
,,G
ENERATOR
"
K
LASSE
XV
E
IGENSTÄNDIGES
G
ENERATOR
P
ROJEKT
XVI
ANHANG C WEITERE TEMPLATEANPASSUNGEN
XVII
vi
Abbildungsverzeichnis
A
BBILDUNG
1
D
RAW
2D
B
EISPIEL
... 11
A
BBILDUNG
2
G
ENERATIVE
A
RCHITEKTUR
... 20
A
BBILDUNG
3
G
RAPHICAL
D
EFINITION
M
ODEL
... 21
A
BBILDUNG
4
T
OOLING
D
EFINITION
M
ODEL
... 21
A
BBILDUNG
5
M
APPING
M
ODEL
... 22
A
BBILDUNG
6
X
PAND
B
EISPIEL
... 24
A
BBILDUNG
7
C
LASS ERWEITERNDE
S
TEREOTYPEN
... 36
A
BBILDUNG
8
A
SSOZIATIONSERWEITERNDE
UML
E
LEMENTE
... 39
A
BBILDUNG
9
B
EISPIEL
1
IN
M
AGIC
D
RAW
... 40
A
BBILDUNG
10
B
EISPIEL
1
ALS
E
CLIPSE
UML2
E
XPORT
... 41
A
BBILDUNG
11
M
ÖGLICHE
UML
D
ARSTELLUNG
... 42
A
BBILDUNG
12
L
ÖSUNG DURCH
K
ONVENTION
... 43
A
BBILDUNG
13
N
OTATIONSELEMENTE DER PRIMITIVEN
E
LEMENTE
... 44
A
BBILDUNG
14
N
OTATIONSELEMENTE DER KOMPLEXEN
E
LEMENTE
... 44
A
BBILDUNG
15
N
OTATIONSELEMENTE DER
C
ONTAINER
E
LEMENTE
... 44
A
BBILDUNG
16
E
DITIERBARE
G
RUPPE
... 45
A
BBILDUNG
17
D
ATENHALTENDE
N
OTATIONSELEMENTE
... 45
A
BBILDUNG
18
N
OTATIONSELEMENTE FÜR
V
ERBINDUNGEN
... 46
A
BBILDUNG
19
T
OOLING
M
ODEL DES
GE ... 59
A
BBILDUNG
20
N
OTATIONSELEMENT
M
ASTER
D
ETAIL
V
ERBINDUNG
... 60
A
BBILDUNG
21
GMFMAP
M
ODELL
... 61
A
BBILDUNG
22
T
OP
N
ODE
R
EFERENCE EINER
K
LASSE
... 62
A
BBILDUNG
23
M
APPING
D
EFINITION DES PRIMITIVEN
E
LEMENTS
... 63
A
BBILDUNG
24
M
APPING
D
EFINITION DES
UIC
ONTAINERS
... 63
A
BBILDUNG
25
M
APPING
D
EFINITION DES
UID
ATA
P
ROVIDERS
... 64
A
BBILDUNG
27
P
ROPERTY
V
IEW DER
UID
ATA
R
ELATION
... 65
A
BBILDUNG
26
M
APPING
D
EFINITION DER
UID
ATA
R
ELATION
... 65
A
BBILDUNG
28
GUI
G
EN
M
ODEL
... 68
A
BBILDUNG
29
M
ETAMODELL DES GUI
UMLG
EN
M
ODELS
... 71
A
BBILDUNG
30
GE
B
EISPIEL
1/DSL ... I
A
BBILDUNG
31
GE
B
EISPIEL
1/UML ... II
A
BBILDUNG
32
GE
B
EISPIEL
2/DSL ... III
A
BBILDUNG
33
GE
B
EISPIEL
2/UML ... IV
1 Einleitung
Bisher wurde bei Orientation in Objects GmbH (OiO) PowerPoint Folien
zur Graphical User Interface (GUI) Beschreibung eingesetzt, oder Kun-
den 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 zukunftsorien-
tiert 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 Mo-
deling Language (UML) ermöglicht zwar die Verwendung domänenspezi-
fischer Terminologie mittels Stereotypen, ihre dreizehn Diagramme sind
jedoch ein Notationsstandard [Jec04] und nicht auf die Domäne an-
passbar. Die UML ist ,,zunächst nicht einfach genug, um effektiv mit ei-
ner graphischen Syntax arbeiten zu können" [Sta07] Es gilt einen do-
mänenspezifischen graphischen Editor zur GUI Modellierung zu entwi-
ckeln, 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 Ar-
goi, welches das Metamodell von UML erweitert, um UMLi [UMLi08] Mo-
delle zu erstellen. Jedoch kann aufgrund des verwendeten Erweite-
rungsmechanismus 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 Mo-
dellgetriebene 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 festge-
halten. In Notationselemente wird die entwickelte Notation der Sprach-
elemente vorgestellt. Nachdem die Werkzeugwahl begründet wird fol-
2
gen die technischen Kapitel. Das Kapitel Generativer Entwicklungspro-
zess von GMF stellt einen übertragbaren, werkzeugspezifischen Entwick-
lungsprozess 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 aufgabenspezifi-
schen Anpassung der Transformationsdefinition. Die Arbeit schließt mit
einer Kritik der verwendeten Werkzeuge und der eigenen Entwicklung
ab.
2 Grundlagen
2.1 Begrifflichkeiten
Domäne
Eine Domäne ist ein ,,begrenztes Interessen- oder Wissensgebiet"
[Sta07] .
Meta-Modell
Eine ,,formalisierte Beschreibung einer Domäne nennt man Metamodell"
[Sta07] , welches die abstrakte Syntax und die statische Semantik um-
fasst.
Abstrakte Syntax
Meta-Modellelemente und ihre Beziehungen bezeichnet man als ab-
strakte Syntax.
Konkrete Syntax
,,Der Begriff (abstrakte Syntax) dient zur Unterscheidung von der konk-
reten Syntax, die beschreibt, wie die tatsächlichen Quelltexte bzw.
Diagramme aussehen" [Sta07] .
Statische Semantik
Die statische Semantik legt Wohlgeformtheits-Bedingungen fest.
Domänenspezifische Sprache
Eine Domänenspezifische Sprache (Domain Specific Language, DSL) ist
nach [Sta07] eine Programmiersprache für eine Domäne. Sie besteht
aus konkreter und abstrakter Syntax sowie statischer Semantik und ei-
ner klar definierten Semantik der Sprachelemente (dynamische Seman-
tik) [Sta07] .
2.2 Model Driven Software Development (MDSD)
,,Modellgetriebene Softwareentwicklung (...) ist ein Oberbegriff für
Techniken, die aus formalen Modellen automatisiert lauffähige Software
erzeugt" [Sta07] . Der zu erstellende Graphische Editor (GE) wird in ei-
4
ner MDSD Werkzeugkette genutzt, um diese Modelle zu erstellen. Er
wird auch selbst mittels Modellen erzeugt.
,,Das Ziel von MDSD ist (...) domänenspezifische Abstraktionen zu fin-
den und diese in einer formalen Modellierung zugänglich zu machen"
[Sta07] .Hierdurch ist es möglich ,,auf einer höheren Abstraktionsebene
zu programmieren" [Sta07] , auch ohne die Details der Implementie-
rung zu kennen. Dadurch entsteht ein hohes Automatisierungspotential,
welches in der Mehrzahl der Fälle in eine Produktivitätssteigerung mün-
det.
In der MDSD werden mittels eines Generators Modelle in Modelle (Model
to Model, M2M) oder Modelle in Text (Model to Text, M2T) überführt.
Eine Transformation wird mittels einer Transformationsdefinition be-
schrieben, welche konkrete Modelle bei einer Transformation als Argu-
mente berücksichtigt. Bei M2T Transformationen ähneln die Transfor-
mationsdefinitionen Schablonen, weshalb sie ,,Templates" genannt wer-
den.
2.3 Unified Modeling Language (UML)
,,Die Unified Modeling Language (UML) dient zur Modellierung, Doku-
mentation, Spezifizierung und Visualisierung komplexer Softwaresyste-
me unabhängig von deren Fach- und Realisierungsgebiet. Sie liefert die
Notationselemente (...)" [Jec04] , sowie die formale Meta-Modell-
Beschreibung. Die UML wird von der Object Management Group (OMG)
standardisiert und gilt als herstellerneutral. Seit der UML Version 2.0
basiert sie vollständig auf der Meta Object Facility (MOF). Die UML wird
mittels der Infrastructure [OMG08a] , welche grundlegende Sprachele-
mente hält, sowie der Superstructure [OMG08b] , welche Diagrammno-
tation und Semantik enthält, spezifiziert.
Im weiteren Verlauf dieser Arbeit ist insbesondere der Stereotyp von
Bedeutung. ,,Ein Stereotyp eröffnet die Möglichkeit zur Definition von
Erweiterungen von existierenden Klassen des Metamodells. Sie ermögli-
chen somit die Verwendung von (...) domänenspezifischer Terminologie
(...) durch ,,Anpassung" der UML" [Jec04] . Mittels Stereotypen können,
in der UML einzigartig, auf Benutzer-Modellebene Metaklassen model-
liert werden. Von der erweiterten Klasse wird nicht geerbt, sondern sie
wird referenziert. Dieses Muster ist in der MDSD auch als Modellmarkie-
rungen [Sta07] bekannt. Stereotypen werden in einem Profil definiert,
welche die einzige standardisierte UML Erweiterungsmöglichkeit ist.
2.4 Eclipse Modeling Framework (EMF)
2.4.1 Einleitung
EMF stellt die technologische Kernkomponente der zur Realisierung die-
ser Diplomarbeit verwendeten Technologien dar.
Die wichtigsten Konzepte von EMF werden beschrieben:
·
Ecore als Kernmodell bzw. Meta-Meta-Modell mit welchem Domä-
nenmodelle (Meta Modelle bzw. eigene Sprachen) definierbar
sind, sowie sein Verhältnis zu MOF.
·
EMF zur Datenintegration, mit unterschiedlichen Datenrepräsenta-
tionen in Java und XML. Das Persistieren der Daten in Resources
und die Verwendung mehrere Resources in einem ResourceSet.
·
Die wesentlichen Charakteristika der Java Repräsentationsklassen
wie das Observer Pattern und Reflection sowie die Fähigkeit EMFs
diese zur Laufzeit dynamisch zu erzeugen.
·
EMF.Edit mit
ItemProvidern
die die nötigen Informationen der
Modellelemente für Editoren liefern.
Command
s und der
Command-
Stack
als Grundlage für undo und redo Operationen. Die Kapse-
lung eines
CommandStack
und eines
ResourceSet
in eine
Edi-
tingDomain
.
2.4.2 Hinführung
Das Eclipse Modeling Framework (EMF) ist ein Framework zur Daten In-
tegration und Modellierung. Freigegeben wurde EMF 2002 von IBM
6
[Mer07a] und wurde für Eclipse entwickelt, ist jedoch auch außerhalb
einsetzbar. Benutzt wird es bereits von einer Vielzahl an Produkten z.B.
von IBM und Eclipse-PlugIns wie UML2, Object Constraint Language
(OCL) [OCL08] und GMF [Mer07a] . EMF verbindet XML, Java und UML
[Bud03] . Vorausgreifend auf die Erklärung des Kernmodells wird bei
der UML Unterstützung die von ,,essential MOF" (eMOF) verwendeten
Notationselemente des Klassendiagramms interpretiert, also einen Teil
des Klassendiagramms [Bud03] . Anzusiedeln ist EMF zwischen Prog-
rammierern und Modellieren [Bud03]
EMF verarbeitet die Struktur eines Datenmodells einer unterstützten
Technologie als Struktur-Ausprägung und kann sie in eine andere Aus-
prägung überführen. XML-Schemata und Java-Klassen sind mögliche
Ausprägungen eines Datenmodells. EMF überführt die Ausprägungen
mit Hilfe eines eigenen Kernmodells ineinander. Eclipse Projekte wie
Connected Data Objects (CDO) [CDO08] oder Teneo [Ten08] ermögli-
chen es Datenbanken als weitere Ausprägung eines Datenmodells anzu-
sehen, indem sie das EMF Kernmodell unterstützen.
2.4.3 Ecore (Meta) Model
Das EMF Kern (engl. core) Modell, auch Ecore genannt, ermöglicht die
gemeinsame, abstrakte Repräsentation des Datenmodells der unterstüt-
zen Technologien. Diese werden über ein Ecore Instanzmodell mitei-
nander verbunden [Bud03] . Ecore Modelle sind Meta-Modelle, be-
schreiben also andere Modelle. Das Ecore Modell ist selbst ein EMF Mo-
dell, definiert sich selbst und ist dadurch sein eigenes Meta-Modell.
Folglich ist Ecore ein Meta-Meta Modell und lässt sich durch die Selbst-
definition beliebig rekursiv fortführen, z.B. Meta-Meta-Meta-Modell. Das
Ecore Modell selbst besteht aus einer Teilmenge des UML Klassendiag-
ramms, die verwendeten Elemente liegen jedoch eine Abstraktionsebe-
ne über UML. Das von der OMG für UML2 verwendete Meta-Meta-Modell
ist MOF, dessen Verhältnis zu Ecore später Beachtung findet. Ecore be-
sitzt die gleiche Elementnotation, jedoch eine deutlich geringere Ele-
mentmenge wie UML. Als Beispiel dient die Aggregation, die in Ecore
nicht vorhanden ist. Die Definition der UML Klassen als Metaklassen bie-
tet jedoch den praktischen Vorteil, bestehende UML Werkzeuge zur Ers-
tellung von Ecore Modellen zu nutzen [Bud03] . Standardmäßig werden
Ecore Modelle in XML Metadata Interchange (XMI) serialisiert. XMI ist
der Standard zur Serialisierung von Metadaten, welche Ecore Modelle
sind [Bud03] .
Zusammenfassend lässt sich über Ecore folgendes sagen:
·
Ecore und seine XMI Serialisierung sind das Zentrum von EMF
·
Ein Ecore Modell kann aus einer der drei Quellen erzeugt werden:
einem UML Modell, einem XML-Schema oder aus annotierten Java
Interfaces.
·
Die Java Implementierung, und optional andere Ausprägungen
des Modells, können aus seinem Ecore Modell generiert werden.
2.4.4 Verhältnis von Ecore und MOF
Meta Object Facility (MOF) definiert eine Teilmenge aus UML für das
Konzept der Klassen Modellierung in einem Objekt Speicher (Reposito-
ry). Als solches ist MOF mit Ecore vergleichbar. Der Fokus von Ecore
liegt auf der Werkzeug Integration statt auf dem Verwalten von Metada-
ten Repositories. Hierdurch vermeidet Ecore einige Komplexität von
MOF [Bud03] . In der sich noch in der Entwicklung befindenden Spezifi-
kation [MOF08] von MOF 2.0 ist eine ähnliche Teilmenge, ,,essential
MOF" (eMOF) [Mer07b] seit 2003 vorgesehen. Es gibt wenige, haupt-
sächlich Namensunterschiede zwischen Ecore und eMOF sowie Ecores
Unterstützung von Generics [Mer07b] .EMF kann eMOF Serialisierungen
lesen und schreiben [EMF05] .
8
2.4.5 Generator Modell
Das EMF Generator Modell (
.genmodel
) stellt technisch das Zentrum
von EMF da. Es dekoriert ein Ecore Modell und in ihm werden Informa-
tionen gespeichert die das Ecore (auch Domänen Modell genannt) mit
implementierungsspezifischen Details ,,verschmutzen" würden [Mer07a]
. Das Ziel der Code Generierung, das Präfix der generierten Klassen, der
Name der erzeugten Fabrik sowie die verwendeten Entwurfsmuster ein-
zelner Elemente werden im EMF-Generatormodell spezifiziert. Zusätzlich
gibt die Möglichkeit das Generatormodell mit dem Domänenmodell zu
synchronisieren. Aus dem Generator Modell wird der Quellcode erzeugt
[Bud03] . Die Generierung lässt sich mit Hilfe von Java Emitter Templa-
tes (JET) [JET08] anpassen. JET ist eine Java Server Pages (JSP) ähnli-
che Template Sprache [Pop04] . Hervorzuheben ist, dass Anpassungen
durch Methodenspezifische ,,Protected Regions" [Sta07] erfolgen und
angepasste Methoden mittels
@generated NOT
ausgezeichnet [Bud03]
werden. EMF trennt also Generat und Implementierten Code nicht.
2.4.6 Generat
EMF erzeugt ein
EPackage
, Fabriken sowie Java Interfaces und Imple-
mentierungsklassen. Dies gilt als gutes Design und wird benötigt um
Mehrfachvererbung zu realisieren. Es werden getter und setter gene-
riert. Die Interfaces erweitern alle, direkt oder indirekt,
EObject
. Die
wichtigsten Methoden hiervon sind:
eClass()
- gibt das Meta-Objekt des Objects zurück
eContainer()
und
eResource()
- gibt den das Objekt
beinhaltenden Container bzw. die beinhaltende Resource zurück.
eSet()
und
eGet()
- geben Zugriff auf die performante Reflection
API.
EObject
selbst erweitert
Notifier
. Ein
Notifier
ist das beobachtbare
Objekt des Observer Patterns [Gam95] und ein
Adapter
ist der Beo-
bachter [Bud03]
2.4.7 Persistenz
Die Fähigkeit Modelle zu persistieren sowie andere persistierte Modelle
zu referenzieren sind Schlüsselfähigkeiten von EMF [Bud03] . Es besteht
die Möglichkeit selbst einen ,,Serialisierer" zu schreiben und dennoch
unabhängig von der Art der Serialisierung andere Modelle zu Referen-
zieren und selbst referenziert zu werden. Typischerweise wird das Wur-
zelelement des Modells einer
Resource
übergeben wodurch alle direkt
oder indirekt vom Wurzelelement beinhaltenden Elemente in ihr gespei-
chert werden. Ein
ResourceSet
kapselt eine Menge an Resourcen auf
die zusammen zugegriffen wird und ermöglicht Resourcen übergreifen-
de Referenzen. Die passende Serialisierungskomponente für eine Re-
source wird aus einem Register (Registry) erfragt.
2.4.8 Dynamisches EMF
EMF kann die oben beschriebene Generierung der Java-Klassen aus ei-
nem Domänenmodell dynamisch zur Laufzeit im Speicher vollziehen
[Bud03] . Dies ist für UML Stereotype unerlässlich. Hierfür werden im-
plizit die Standardeinstellungen des Generator Modells verwendet und
Verhalten (Methoden) kann nicht implementiert werden. Dynamisches
EMF resultiert in einer geringeren Performance sowie in einer kompli-
ziertere Verwendung der Meta-Elemente und Elemente.
2.4.9 EMF.Edit
EMF.Edit ist ein Framework um Editoren für EMF Modelle zu erstellen
[Bud03] . Editoren benötigen im Wesentlichen die Beschriftung (Label),
die Eigenschaften (Properties), die Kinder und das Symbol (Icon) eines
Elements. EMF.Edit trifft bereits Annahmen hierfür, z.B. liegen Kind-
Knoten eines Elements in seinen Containment Referenzen. Diese An-
nahmen sind, außer bei dynamisch zur Laufzeit erzeugten Editoren, an-
passbar. Des Weiteren ist für Editoren das Editieren der Modelle, im Ge-
gensatz zum reinen Schreiben der Modelle wichtig [EMF04] . Konkret ist
10
hiermit das Rücksetzten (undo) und Wiederherstellen (redo) von Ände-
rungen gemeint. Änderungen am Modell werden mittels
Command
s
durchgeführt, die in
CompoundCommand
s geschachtelt werden können.
Die für Editoren benötigten Informationen werden von
ItemProvider
n
bereitgestellt, welche zudem generische
Command
s liefern. Für Instanzen
eines Meta-Elements existiert mindestens ein
ItemProvider
.
Command
s
werden auf dem
CommandStack
gespeichert, der die undo/redo Funktio-
nalität ermöglicht. Der
CommandStack
sowie ein
ResourceSet
werden
durch eine
EditingDomain
gekapselt.
Die bisher beschriebene Funktionalität von EMF.Edit ist nicht an Eclipse
gebunden. EMF.Edit bietet zudem die Möglichkeit auf Basis der oben
genannten Funktionalität einen Eclipse JFace basierten Editor zu gene-
rieren. Für EMF.Edit bietet die Transaktionskompontente EMF Transacti-
on eine
TransactionalEditingDomain
mit welcher mehrere Threads
bzw. Editoren auf einer
EditingDomain
arbeiten können [EMF08] .
2.5 Draw2D
Draw2D ist das in dieser Arbeit verwendete Framework für graphische
Komponenten. Es wurde für GEF entwickelt, basiert auf SWT und ist oh-
ne Eclipse oder GEF einsetzbar. Es ist auf Graphische Editoren mit be-
wegbaren Elementen ausgelegt [Sca05] und beseitigt Unzulänglichkei-
ten von SWT/JFace indem beliebige Figuren definierbar sind. Draw2D
wird als Leichtgewicht System bezeichnet, da es in einem SWT-Canvas
beheimatet ist um die Flexibilität zu erhöhen und weniger Systemre-
sourcen zu verbrauchen [Moo04] . Das Lightweight System besteht aus
einer speziellen Wurzelfigur, einem
EventDispatcher
, welcher SWT
Events übersetzt, und einem
UpdateManager
, der die Figuren zeichnet
[Moo04] .
Figuren (
IFigure
) in Draw2D besitzen ähnlich Eigenschaften wie native
Fenster: ihre Größe ist anpassbar, sie sind verschiebbar, erhalten Fokus
und besitzen ein eigenes Koordinatensystem. Sie sind die zentralen
Elemente und folgen dem Composite Entwurfsmuster [Gam95] . Jede
Figur kann einen eigenen Layout Manager für die Anordnung der in ihr
liegender Figuren definieren und ihnen Layout Constraints zuweisen.
Draw2D bietet Bildausschnitte [Sca05] , die z.B. für Bildschirm-
überschreitende Figuren notwendig sind.
Abbildung 1 Draw2D Beispiel
2.6 Graphical Editing Framework (GEF)
2.6.1 Einleitung
Zusammen mit der später beschriebenen GMF-Runtime liefert GEF die
Laufzeitinfrastruktur für den erstellten Editors. Die GMF-Runtime ist als
12
Erweiterung und nicht als Abstraktion von GEF zu verstehen. Die in der
Implementierung beschriebenen Anpassungen sind partiell und nicht
zusammenhängend. Sie werden soweit erklärt, dass sie sich mittels der
Beschreibungen von GEF und GMF-Runtime einordnen lassen. Dieser
Abschnitt beschreibt unter anderem die zentralen Elemente
EditPart
und
EditPolicy
von GEF sowie ihre Kommunikation mittels
Request
s
und
Command
s.
2.6.2 Hinführung
Das Modell-View-Controller [Gam95] Prinzip ist ein bekanntes Ent-
wurfsmuster zur Rollenverteilung für Benutzerinteraktion. Das Graphical
Editing Framework (GEF) wurde entwickelt, um die Controller Rolle bei
Graphische Editoren zu übernehmen. Es leitet also die Interaktion zwi-
schen dem Modell, welches die Bedeutung des Diagramms trägt, und
dessen Darstellung. GEFs Aufgaben sind, die Element-Darstellung zu
wählen und zu aktualisieren, dem Benutzer die Interaktion mit dem Mo-
dell zu erlauben und sich in die Arbeitsumgebung zu integrieren
[Hud05] .GEF ist abhängig von Draw2D und der Eclipse Rich-Client-
Platform (RCP). Als Modell in GEF kann jedes beobachtbare Java-Objekt
verwendet werden, jedoch bietet sich eine Aufteilung in Geschäfts- und
Ansichtsmodell an [Ani05] .
2.6.3 Überblick
Die Interaktion der GEF Elemente untereinander ist komplex. Dieser
vereinfachte, typische Ablauf hilft einen ersten Überblick zu gewinnen:
1.
Der Benutzer löst eine Aktion (
Action
) mittels eines Ereignisses
(
Event
) aus.
2.
Die Aktion schickt eine Anfrage (
Request
) an einen Controller
(
EditPart
).
3.
Der
EditPart
wertet die Anfrage mit Hilfe der zu ihm gehörenden
EditPolicy
s aus und antwortet mit einem
Command
.
4.
Der
Command
, welcher die Änderungen am Modell vornimmt, wird
ausgeführt.
5.
Die das Modell beobachtenden
EditPart
s erkennen die
Veränderung und aktualisieren die Ansicht.
Der Controller bzw.
EditPart
ist das zentrale Element in GEF. Bevor auf
ihn eingegangen wird, werden die Komponenten betrachtet, welche sei-
nen Einsatz erst ermöglichen.
2.6.4 Basiskomponenten
2.6.4.1 EditorPart
Eclipse Editoren sind dafür verantwortlich Eingaben entgegen zu neh-
men, Viewer zu erzeugen und zu konfigurieren sowie die Eingabe zu
verarbeiten und zu speichern [Moo04] . Eine Subklasse von
EditPart
stellt die Verbindung zwischen GEF und Eclipse her. Typischerweise hält
der Editor eine
EditDomain
, eine
ActionRegistry
und einen
Selec-
tionSynchronizer
[Sca05] .Die konfigurierten Viewer werden der Edit-
Domain hinzugefügt.
2.6.4.2 EditDomain
Die Aufgaben der
EditDomain
und EMFs
EditingDomain
überschneiden
sich, sie sind jedoch nicht zu verwechseln. Die
EditDomain
bündelt den
Editor
, mehrere Viewer wie z.B. die Toolbar und den
CommandStack
[Moo04] . Der
CommandStack
besitzt die gleichen Aufgaben wie der
gleichnamige EMF
CommandStack
, sie sind jedoch ebenfalls nicht iden-
tisch.
2.6.4.3 GraphicalViewer
Der
GraphicalViewer
bietet eine nahtlose Integration in die Eclipse
Workbench und ist überall verwendbar, wo ein SWT-
Control
bereits-
teht. Er ist vom Editor unabhängig, und erzeugt ein
LightweightSystem
14
auf dem
Control
. Folglich ist er für Ereignisbehandlung (Event Hand-
ling), unter anderem auch für ,,Drag & Drop" verantwortlich, und leitet
Event
s an die
EditDomain
weiter [Sca05] . Der
GraphicalViewer
bildet
die Basis für
EditParts
[Sca05] und benötigt einen speziellen
RootE-
ditPart
, eine EditPart Fabrik [Gam95] und Inhalt um zu funktionieren
[Moo04] . Er besitzt ein
EditPart
-Register, um Modellelemente zu exis-
tierenden
EditPart
s zuzuweisen, kennt die selektierten sowie fokus-
sierten
EditPart
und das ausgewählte Werkzeug. Der
GraphicalVie-
wer
besitzt eine spezielle
IFigure
, beispielsweise eine Viewport Figur.
2.6.4.4 Benutzerinteraktion
Grundsätzlich wird als Folge einer Benutzeraktion ein
Request
an einen
EditPart
geschickt, der, je nach Art der Interaktion, ihn mit einem
Command
beantwortet. Um einen
Request
zu erzeugen, kann man eine
Taste drücken, eine Aktion (
Action
) auslösen oder mit der Werkzeug-
leiste (
Palette
) arbeiten. Das Modell wird nicht direkt von den
Edit-
Part
s manipuliert, sie liefern die
Command
s hierfür, die meist von den
Werkzeugen ausgeführt werden.
2.6.4.5 Tools
Die
Palette
beinhaltet neben den komplexen Standard Werkzeugen
[Sca05] unterschiedliche
CreationTool
s [Moo04] , welche entweder
Elemente (Knoten) oder Connections (Kanten) erzeugen. Beide werden
mit einer Fabrik konfiguriert. Eine Besonderheit der
CreationTool
s ist,
dass sie für Feedback schon beim Gleiten über die Zeichenfläche fort-
laufend
Request
s verschicken.
2.6.4.6 Requests
Request
s sind die Kommunikationsobjekte in GEF [Moo04] . Sie werden
verwendet, um
Command
s zu erhalten, und können für die
Request
-
Ausführung relevante Informationen tragen. Beispielsweise hält ein
Re-
quest
zum Erstellen einer Verbindung zwischen zwei
EditPart
s, der an
die Senke gerichtet ist, den fertig konfigurierten
Command
zur Verbin-
dungserstellung hinsichtlich der Quelle.
Die wichtigsten
Request
s sind:
CreateRequest
zum Erstellen von neuen Modellobjekten
GroupRequest
, um mehrere
EditPart
s mit einem
Request
überspannen zu können. Beispielsweise löst das Löschen eines
Elementes ein
GroupRequest
vom Typ
delete
aus.
LocationRequest
zum Aufspüren einer Position
2.6.4.7 EditParts
EditPart
s sind als Controller des MVC-Musters die zentralen Elemente
in GEF und folgen zudem dem Composite Muster [Gam95] . Sie be-
stimmen wie Modellelemente auf visuelle Figuren abgebildet werden
und wie sich Figuren in unterschiedlichen Situationen verhalten [Moo04]
. Jeder Darstellung mit Verhalten ist ein
EditPart
zugeordnet und typi-
scherweise gibt es für jedes Modellelement einen
EditPart
. Zusätzlich
existieren z.B. für editierbare Labels und für nicht auf Assoziationsklas-
sen beruhende Verbindungen (ansonsten trifft der Fall eines eigenen
Modellelements zu) weitere
EditPart
s. Die Aufgaben von
EditPart
s
sind nach [GEF08] :
Erzeugen und erhalten einer Ansicht
Erzeugen und erhalten von Kind
EditPart
s und ggf.
ConnectionEditParts
Unterstützung der Modellbearbeitung
Vereinfacht lassen sich
EditPart
s in drei Kategorien aufteilen:
Connec-
tionEditParts
für Kanten,
GraphicalEditParts
für Knoten und
Tree-
EditParts
für Bäume, z.B. für den Outline View.
16
Die
EditPart
-Erzeugung erfolgt durch Fabriken, welchen das Modell-
element, für welches sie einen
EditPart
erzeugen soll, sowie ein Kon-
text bzw. der zukünftige Container
EditPart
, übergeben wird. Die
EditPart
-Erzeugung wird durch eine Modelländerungsbenachrichtigung
angestoßen. Der folgende Ablauf betrachtet die Erzeugung eines
Gra-
phicalEditPart
. Der zukünftige Container
EditPart
ruft
refresh-
Children()
, welche sich über
getModelChildren()
eine Liste aller
Kind-Elemente besorgt. Es wird geprüft, ob den Listenelementen
Edit-
Part
s zugewiesen sind. Ist das nicht der Fall, wird das unter Verwen-
dung der Fabrik nachgeholt und der Kind-
EditPart
dem Container
EditPart
hinzugefügt.
2.6.4.8 EditPolicy
EditPart
s antworten auf
Request
s mittels
EditPolicy
s, welche erst
die Editierfunktionalität in die
EditPart
s bringen [Moo04] . Sie erlauben
die selektive Wiederbenutzung von Editierverhalten über mehrere
Edit-
Part
s [GEF08] . Erhält ein
EditPart
ein
Request
iteriert er über seine
EditPolicy
s, welche den
Request
mit zusätzlichen Informationen an-
reichern oder einen
Command
zurückgeben. Im Normalfall fasst er die
zurück gelieferten
Command
s zu einem
CompoundCommand
zusammen.
Eine
EditPolicy
unterstützt einen
Request
, wenn sie einen
Command
zurückliefert, ignoriert ihn, wenn sie
null
zurückliefert oder unterbindet
ihn, indem sie einen
UnexecutableCommand
zurückgibt. Beim Installie-
ren in einen
EditPart
wird ihr eine in ihm einzigartige Rolle zugewie-
sen. Diese Rollen sind
String
s und sind beim Löschen oder Austau-
schen von
EditPolicy
s von Bedeutung [GEF08] .
Zusätzlich zu dem Zurückgeben von
Command
s übernehmen die
EditPo-
licy
s auch das Benutzerfeedback. Beispielsweise erstellt eine
Graphi-
calNodeEditPolicy
beim Erstellen einer Verbindung eine ,,dummy"
Connection, die solange angezeigt wird, wie keine reale Verbindung
existiert [Moo04] .
2.6.4.9 Command
Command
s modifizieren das Modell und vereinfachten durch folgende
Merkmale seine Bearbeitung [Moo04] :
Undo und Redo
Ausführungseinschränkungen (
canExecute()
)
Schachtelbarkeit
Sie gehören zwar nicht zum Modell, sind aber eng mit ihm verknüpft
[GEF08] . Die bereits beschriebenen EMF-
Command
s übernehmen o.g.
Aufgaben, jedoch ist die technische Basis unterschiedlich.
2.7 Graphical Modeling Framework (GMF)
2.7.1 Einleitung
Das Graphical Modeling Framework (GMF) entstand aus Frustration über
die technischen Schwierigkeiten EMF mit GEF zu benutzen und dem
Wunsch Graphische Editoren auf ähnliche Weise wie EMF-Baumeditoren
zu erzeugen [Ani06] . Das aus einer Laufzeitinfrastruktur, welche GEF
und EMF integriert, und einem generativen Teil bestehende GMF, wurde
2005 angekündigt und 2006 freigegeben [Sha06] . Die Laufzeit stellt
zusätzliche Dienste wie Transaktionen, ein Notations-Meta-Modell, Va-
riationspunkte für die Laufzeiterweiterung, usw. bereit. Der generative
Teil umfasst eine Sprache, um Editoren zu beschreiben und passt damit
in das Konzept der Software Factories [Sha06] . Zunächst wird die Lauf-
zeitumgebung betrachtet, welche als Fortsetzung der GEF Grundlagen
zu sehen ist, danach die generative Architektur.
2.7.2 Laufzeitinfrastruktur (Runtime)
Die Laufzeitinfrastruktur wurde von IBM entwickelt, welche diese für
IBM Rational Produkte einsetzt [Ani06] . Ihre Eigenschaften sind:
18
·
eine Service orientierte Struktur die den Editor erweiterbar für
Drittanbieter macht
·
Integration einiger EMF basierte Komponenten wie z.B. OCL und
Transaction
·
Definition eines erweiterbaren Notations-Meta-Modells
·
GMFs Command Framework welches EMFs und GEFs
Command
(-
stack
) integriert
·
die Extensible Type Registry
2.7.2.1 Notations-Meta-Modell
Das Notations-Meta-Modell speichert visuelle, nicht semantische, Infor-
mationen domänenunabhängig und ist somit unabhängig vom darunter
liegendem Domänenmodell) [Ani06] . Mit seiner Hilfe werden die Posi-
tionen und Größen von Knoten, Verbindungen, etc. gespeichert. Es ist
für eigene Bedürfnisse erweiterbar und das stabilste Meta-Modell in
GMF. Die zentrale Klasse von ihm ist der
View
, er hält die
element
-
Referenzen auf das Domänenelement und ist damit die einzige Verbin-
dung zu dem semantischen Modell. Der
View
ist Teil des Modells und
sollte nicht mit dem MVC Muster in Verbindung gebracht werden.
2.7.2.2 Dienste (Services)
Die GMF-Runtime wurde als Plattform für verschiedene Domänenedito-
ren entwickelt und benötigte deshalb robuste Erweiterungsmöglichkei-
ten, welche durch Eclipse Extension Point basierte GMF Service-Provider
Infrastruktur [GMF08a] realisiert wurden. Diese Struktur wird über be-
kannte GEF Konzepte wie abstrakte ,,Basis"-
EditPart
s und
EditPoli-
cy
s, welche an die Dienste delegieren, integriert [GMF08a] . Die unter-
schiedlichen Abläufe stellt [GMF08a] gegenüber. Die Services erlauben
beliebige Arten der Überschreibung ohne domänenspezifische Abhän-
gigkeiten von ihnen [GMF08a] .
Die wichtigsten Dienste sind:
·
ViewService
·
EditPartService
·
EditPolicyService
·
PaletteService
2.7.2.3 Extensible Type Registry nach [GMF08b]
Mittels der Extensible Type Registry wird ein applikationsspezifisches
Klassifizierungssystem definiert. Dieses basiert auf und bietet eine Al-
ternative zu den Meta-Klassen des Domänenmodells. Die Extensible Ty-
pe Registry wird ausgiebig von GMF Services genutzt, beispielsweise
beim Erfragen eines Delete Command für eine Klassifizierung oder des
Icons für eine. Eine Klassifizierung ist ein Element Type (bzw.
IEle-
mentType
) und ihre konkrete Ausprägung entweder ein Meta-Modell Ty-
pe oder ein Specialization Type. Der Meta-Modell Type aller Modellele-
mente mit gleicher
EClass
und gleichem Client-Context ist gleich. Das
Editierverhalten des Meta-Modell- Type wird in seinem
EditHelper
be-
stimmt, welcher eine Command-Fabrik ist. Specialization Types erwei-
tern einen Meta-Modell Type oder mehrere Specialization Types, jedoch
auch indirekt nie mehr als einen Meta-Modell Type.
EditHelperAdvi-
ce
s, welche die vom
EditHelper
zurückgegebenen
Command
s vor oder
nach ihm dekorieren, können mehreren Element Types zugewiesen
werden. Die
ElementTypeRegistry
wird von GMF verwaltet und ermög-
licht das Auffinden von
ElementType
s und
EditHelperAdvice
s anhand
verschiedener Kriterien. Die Angabe eines Client Context ermöglicht die
Aufteilung der
ElementTypeRegistry
um Editoren auf Basis des glei-
chen Metamodells, wie z.B. des UML2 Metamodells, seiteneffektfrei ein-
zusetzen.
2.7.3 Generative Architektur
Der generative Teil wird von Borland entwickelt. Er beseitigt bestehende
Defizite der repetitiven Arbeit mit GEF (,,slow and painful" [Ani06] ) und
20
ermöglicht die schnelle Entwicklung von graphischen Editoren [Pla06] .
Abbildung 2 zeigt dessen Aufbau, die Notation wurde in Anlehnung an
das GMF Dashboard gewählt:
Abbildung 2 Generative Architektur
Der Ablauf der Entwicklung eines Graphischen Editors lässt sich hieraus
bereits erkennen. Ein EMF basiertes Domänenmodell z.B. UML2 wird
erstellt und eingebunden. Danach wird die Notation im Graphical Defini-
tion Model sowie die Benutzerinteraktion im Tooling Definition Model
festgelegt. Die drei oben genannten Modelle werden im Mapping- Modell
vereint, welches per M2M Transformation in das plattformnahe Genera-
tor Modell überführt wird. Mittels der Xpand Template Sprache wird aus
ihm Quellcode, welcher die GMF-Runtime nutzt, generiert.
2.7.3.1 Graphical Definition Model (gmfgraph)
Das Graphical Definition Model beschreibt die visuellen Aspekte eines
Graphischen Editors anhand der Verknüpfung von Draw2D Figuren
[Ani06] [Sha06] . Zudem ermöglicht es Quellcode unabhängig von an-
deren Modellen zu erzeugen und handgeschriebene Figuren über die
Modellierung ihrer Interfaces einzubinden und ist wiederverwendbar
[GMF08] .
Abbildung 3 Graphical Definition Model
2.7.3.2 Tooling Definition Model (gmftool)
Das Tooling Definition Model (Abbildung 4) wird benutzt um die Palette,
Menüs, Toolbars, Popups usw. zu beschreiben [GMF08] .
Abbildung 4 Tooling Definition Model
2.7.3.3 Mapping Model (gmfmap)
Das Mapping Model verbindet die o.g. Modelle [Sha06] , indem es sie
dekoriert. Zudem definiert es die Struktur des Editors, indem in ihm die
Parts, die Kombination von Modell, EditPart und Figur, angeordnet und
in Relation zueinander gesetzt werden. Beispielsweise wird ein Label mit
einem Attribut des Domänenmodells verbunden und die möglichen
Kind-Parts eines Parts definiert. In ihm ist es möglich Einschränkungen
(Constraints) auf Parts zu definieren, Attribute initial zu belegen (Featu-
re Initializers) und Validierungsregeln festzulegen.
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2008
- ISBN (eBook)
- 9783836614580
- DOI
- 10.3239/9783836614580
- Dateigröße
- 1.7 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Hochschule Furtwangen – Allgemeine Informatik
- Erscheinungsdatum
- 2008 (Juni)
- Note
- 1,3
- Schlagworte
- mdsd
