Codegenerierung aus Prozessmodellen mittels des Eclipse-Plug-ins 'JBoss Graphical Process Designer' (Case-Ansatz) bzw. AndroMDA (MDA-Ansatz)
Ein Vergleich
©2006
Bachelorarbeit
116 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
In der Bachelor-Arbeit wird ein Vergleich der Prozessmodellierung mit CASE-Ansatz und der Prozessmodellierung mit MDA-Ansatz durchgeführt.
Die Modellierung mit CASE-Ansatz erfolgt mit einem Plug-in für die Entwicklungsumgebung Eclipse. Dieses Plug-in von der Firma JBoss erzeugt während der grafischen Modellierung eine Prozessbeschreibung. Beim MDA-Ansatz erfolgt die Modellierung auch mit einem CASE-Tool (MagicDraw). Die Prozessbeschreibung wird dann mittels AndroMDA [ANDROMDAH] generiert.
Der Fokus dieser Arbeit liegt auf dem technischen Aspekt der Prozessmodellierung, sowie der Codegenerierung mittels AndroMDA. Um auf die Generierung von Prozessbeschreibungen durch AndroMDA eingehen zu können, ist es notwendig, den Aufbau und die Funktionsweise von AndroMDA, speziell der AndroMDA jBPM-Cartridge, zu beschreiben. Auf andere Codegeneratoren wird nicht eingegangen. Eine Gegenüberstellung einiger Codegeneratoren ist unter [CG] u finden.
Gang der Untersuchung:
Zu Beginn wird das Umfeld der Entstehung der Arbeit dargestellt und danach wird die Aufgabenstellung vorgestellt.
In Kapitel 2 folgt eine kurze Einführung in die generative Softwareentwicklung. Dabei werden die Themen: Computer-Aided Software Engineering, Model Driven Architecture (MDA) und Model Driven Software Development (MDSD) behandelt. Um die Konzepte der Model Driven Architecture verstehen zu können, werden einige Standards der OMG vorgestellt (UML, MOF, XML, XMI ).
In Kapitel 2.2.2 werden die MDA-Konzepte dargestellt. Abgeschlossen wird der theoretische Teil der Arbeit mit einem Vergleich von MDA und MDSD.
Im praktischen Teil wird der Aufbau und die Funktionsweise von AndroMDA, speziell der AndroMDA jBPM-Cartridge, beschrieben.
Zuerst wird in Kapitel 3.3 das Vorgehen mit CASE-Ansatz erläutert. Die Prozessmodellierung erfolgt beim CASE-Ansatz mit einem Plug-in für die Entwicklungsumgebung Eclipse anhand eines einfachen Beispielprozesses (JBay).
Der gleiche Beispielprozess wird in Kapitel 3.4 verwendet, um den MDA-Ansatz darzustellen. Beim MDA-Ansatz erfolgt die Modellierung auch mit einem CASE-Tool (MagicDraw).
Die Prozessbeschreibung wird dann aber mittels AndroMDA generiert. Der Aufbau des Quelltextgenerators AndroMDA wird in Kapitel 3.4.2 beschrieben. Besonders ausführlich wird auf die jBPM-Cartridge eingegangen, da mit ihr aus einem Prozessmodell eine Prozessbeschreibung generiert werden kann.
In Kapitel 3.4.3 wird eine Einführung in die Velocity […]
In der Bachelor-Arbeit wird ein Vergleich der Prozessmodellierung mit CASE-Ansatz und der Prozessmodellierung mit MDA-Ansatz durchgeführt.
Die Modellierung mit CASE-Ansatz erfolgt mit einem Plug-in für die Entwicklungsumgebung Eclipse. Dieses Plug-in von der Firma JBoss erzeugt während der grafischen Modellierung eine Prozessbeschreibung. Beim MDA-Ansatz erfolgt die Modellierung auch mit einem CASE-Tool (MagicDraw). Die Prozessbeschreibung wird dann mittels AndroMDA [ANDROMDAH] generiert.
Der Fokus dieser Arbeit liegt auf dem technischen Aspekt der Prozessmodellierung, sowie der Codegenerierung mittels AndroMDA. Um auf die Generierung von Prozessbeschreibungen durch AndroMDA eingehen zu können, ist es notwendig, den Aufbau und die Funktionsweise von AndroMDA, speziell der AndroMDA jBPM-Cartridge, zu beschreiben. Auf andere Codegeneratoren wird nicht eingegangen. Eine Gegenüberstellung einiger Codegeneratoren ist unter [CG] u finden.
Gang der Untersuchung:
Zu Beginn wird das Umfeld der Entstehung der Arbeit dargestellt und danach wird die Aufgabenstellung vorgestellt.
In Kapitel 2 folgt eine kurze Einführung in die generative Softwareentwicklung. Dabei werden die Themen: Computer-Aided Software Engineering, Model Driven Architecture (MDA) und Model Driven Software Development (MDSD) behandelt. Um die Konzepte der Model Driven Architecture verstehen zu können, werden einige Standards der OMG vorgestellt (UML, MOF, XML, XMI ).
In Kapitel 2.2.2 werden die MDA-Konzepte dargestellt. Abgeschlossen wird der theoretische Teil der Arbeit mit einem Vergleich von MDA und MDSD.
Im praktischen Teil wird der Aufbau und die Funktionsweise von AndroMDA, speziell der AndroMDA jBPM-Cartridge, beschrieben.
Zuerst wird in Kapitel 3.3 das Vorgehen mit CASE-Ansatz erläutert. Die Prozessmodellierung erfolgt beim CASE-Ansatz mit einem Plug-in für die Entwicklungsumgebung Eclipse anhand eines einfachen Beispielprozesses (JBay).
Der gleiche Beispielprozess wird in Kapitel 3.4 verwendet, um den MDA-Ansatz darzustellen. Beim MDA-Ansatz erfolgt die Modellierung auch mit einem CASE-Tool (MagicDraw).
Die Prozessbeschreibung wird dann aber mittels AndroMDA generiert. Der Aufbau des Quelltextgenerators AndroMDA wird in Kapitel 3.4.2 beschrieben. Besonders ausführlich wird auf die jBPM-Cartridge eingegangen, da mit ihr aus einem Prozessmodell eine Prozessbeschreibung generiert werden kann.
In Kapitel 3.4.3 wird eine Einführung in die Velocity […]
Leseprobe
Inhaltsverzeichnis
Björn Kleinert
Codegenerierung aus Prozessmodellen mittels des Eclipse-Plug-ins ,,JBoss Graphical
Process Designer" (Case-Ansatz) bzw. AndroMDA (MDA-Ansatz)
Ein Vergleich
ISBN-10: 3-8324-9925-3
ISBN-13: 978-3-8324-9925-9
Druck Diplomica® GmbH, Hamburg, 2006
Zugl. Fachhochschule Stralsund, Stralsund, Deutschland, Bachelorarbeit, 2006
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 GmbH
http://www.diplom.de, Hamburg 2006
Printed in Germany
Inhaltsverzeichnis
Inhaltsverzeichnis
ii
Abbildungsverzeichnis
v
1. Problemstellung
1
1.1. Kurze Danksagung und Vorstellung des IT Services Center Bonn . . . .
1
1.2. Erläuterung der Aufgabenstellung
. . . . . . . . . . . . . . . . . . . . .
2
2. Einführung in die generative Softwareentwicklung
3
2.1. Computer-Aided Software Engineering (CASE) . . . . . . . . . . . . . .
3
2.2. Model Driven Architecture und Model Driven Software Development . .
4
2.2.1. Anmerkungen zu den Standards UML, MOF, XML, XMI . . . . .
5
2.2.1.1. Unified Modelling Language (UML) . . . . . . . . . . .
5
2.2.1.2. Meta Object Facility (MOF) . . . . . . . . . . . . . . . .
7
2.2.1.3. Extensible Markup Language (XML) . . . . . . . . . . . 10
2.2.1.4. XML Metadata Interchange (XMI) . . . . . . . . . . . . 10
2.2.2. Vorstellung der MDA-Konzepte . . . . . . . . . . . . . . . . . . . 15
2.2.2.1. Modelltransformationen . . . . . . . . . . . . . . . . . . 18
2.2.3. Vergleich von MDA und MDSD . . . . . . . . . . . . . . . . . . . 22
ii
INHALTSVERZEICHNIS
3. Beschreibung des Vorgehens zur Aufgabenlösung
25
3.1. Die JBoss jBPM Workflowengine . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Vergleichskriterien festlegen . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Vorgehen mit CASE-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Anforderungen und Analyse . . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Prozessmodellierung mit dem Graphical Process Designer . . . 27
3.3.3. Einbindung von Services in das Prozessmodell . . . . . . . . . . 30
3.3.4. JUnit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4. Vorgehen mit MDA-Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1. Entwicklungsprozess mit AndroMDA . . . . . . . . . . . . . . . . 32
3.4.2. Aufbau von AndroMDA
. . . . . . . . . . . . . . . . . . . . . . . 38
3.4.2.1. Aufbau der AndroMDA jBPM-Cartridge . . . . . . . . . 41
3.4.3. Einführung in die Velocity Template Language (VTL) . . . . . . . 43
3.4.4. Die Templates der jBPM-Cartrigde . . . . . . . . . . . . . . . . . 45
3.4.5. Funktionsweise von AndroMDA . . . . . . . . . . . . . . . . . . . 47
3.4.6. Ein AndroMDA-Projekt mittels Projektgenerator erzeugen . . . . 49
3.4.7. AndroMDA einstellen
. . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.8. Anforderungen und Analyse
. . . . . . . . . . . . . . . . . . . . 51
3.4.9. Prozessmodellierung mit MagicDraw
. . . . . . . . . . . . . . . 51
3.4.10. Prozessbeschreibung generieren . . . . . . . . . . . . . . . . . . 56
3.4.11. Nach der Codegenerierung . . . . . . . . . . . . . . . . . . . . . 57
3.4.12. JUnit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
INHALTSVERZEICHNIS
4. Analyse der Ergebnisse
60
4.1. Unterschiede der Prozessmodellierungsvariaten . . . . . . . . . . . . . 60
4.2. Vergleich zweier Prozessbeschreibungen . . . . . . . . . . . . . . . . . 61
4.3. Vor und Nachteile von MDA . . . . . . . . . . . . . . . . . . . . . . . . . 63
5. Schlussfolgerungen und Ausblick
64
5.1. Eine neue Cartridge erstellen . . . . . . . . . . . . . . . . . . . . . . . . 65
Index
67
A. Anhang
70
A.1. Typographische Konventionen der Arbeiten . . . . . . . . . . . . . . . . 70
A.2. Installationshinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.3. Literaturverzeichnis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.4. Internetquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.5. Quelltexte und Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . 79
Abbildungsverzeichnis
2.1. 4-Schichtenmodell [WIKI] . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2. MOF-Metamodell [WIKI] . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3. Klassendigramm ,,MeineKlasse"
. . . . . . . . . . . . . . . . . . . . . . 11
2.4. PIM zu PSM Transformation . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Metamodelltransformation [MDAG] . . . . . . . . . . . . . . . . . . . . . 19
2.6. Instanzbasierte Abbildung [MDAG] . . . . . . . . . . . . . . . . . . . . . 20
2.7. Musterbasierte Abbildung [MDAG] . . . . . . . . . . . . . . . . . . . . . 21
2.8. MDA Konzepte [MDSD] . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9. AC-MDSD Konzepte [MDSD] . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1. JBay Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2. Eclipse-Plug-in-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Generative Development Process . . . . . . . . . . . . . . . . . . . . . . 33
3.4. Entwicklungsprozess mit AndroMDA . . . . . . . . . . . . . . . . . . . . 34
3.5. Architektur von Anwendungen [ANDROMDAH] . . . . . . . . . . . . . . 36
3.6. Architektur von Java-Anwendungen [ANDROMDAH] . . . . . . . . . . . 37
3.7. Codegenerierung mit AndroMDA . . . . . . . . . . . . . . . . . . . . . . 39
3.8. JBay Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
v
ABBILDUNGSVERZEICHNIS
3.9. AndroMDA-Profile hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . 53
3.10.Aktivitätsdiagramm zuweisen (Schritt 1) . . . . . . . . . . . . . . . . . . 54
3.11.Aktivitätsdiagramm zuweisen (Schritt 2) . . . . . . . . . . . . . . . . . . 54
3.12.Feld verschiebbare Ereignisse
. . . . . . . . . . . . . . . . . . . . . . . 55
3.13.Call-Event einstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.14.Stereotyp festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.15.JBay Ordnerstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.1. Prozessmodell der Bestellungsbearbeitung . . . . . . . . . . . . . . . . 79
A.2. Aktivitätsdiagramm der Bestellungsbearbeitung . . . . . . . . . . . . . . 80
A.3. Modell der AndroMDA-jBPM-Metafassaden . . . . . . . . . . . . . . . . 81
A.4. Modell der AndroMDA-jBPM-Metafassaden . . . . . . . . . . . . . . . . 82
A.5. UML Metaklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Einleitung
,,Darum versenkt, wer im ungeschlichteten Zwist der Völker nach geisti-
ger Ruhe strebt, gern den Blick in das stille Leben der Pflanzen und in der
heiligen Naturkraft inneres Wirken; oder, hingegeben dem angestammten
Triebe, der seit Jahrtausenden der Menschen Brust durchglüht, blickt er
ahndungsvoll aufwärts zu den hohen Gestirnen, welche in ungestörtem
Einklang die alte, ewige Bahn vollenden." [AH]
AndroMDA (sprich Andromeda) ist kein Sternbild und auch nicht der Name einer Prin-
zessin. AndroMDA ist ein in Java entwickeltes MDA-Framework. In dieser Arbeit wird
das Vorgehen der Prozessmodellierung durch CASE-Ansatz und durch MDA-Ansatz
an einem Beispiel (JBay) verglichen. An einem anderen Beispiel (Bestellungsbearbei-
tung) werden zwei Prozessbeschreibungen verglichen. Eine Prozessbeschreibung ist
durch den CASE-Ansatz entstanden und die andere Prozessbeschreibung ist mit An-
droMDA generiert worden (MDA-Ansatz).
Im theoretischen Teil der Arbeit werden Standards der Object Management Group
(OMG) sowie wichtige MDA-Konzepte vorgestellt.
Im praktischen Teil der Arbeit wird der Aufbau und die Funktionsweise von AndroMDA,
speziell der AndroMDA jBPM-Cartridge, beschrieben.
Am Ende der Arbeit wird ein Ausblick gegeben, wie eine neue Cartridge für
AndroMDA entwickelt werden kann.
1. Problemstellung
1.1. Kurze Danksagung und Vorstellung des IT Services
Center Bonn
Diese Arbeit wurde durch das IT Services Center Bonn ermöglicht. Ich möchte mich
speziell bei der Abteilung SW Development1 in Stralsund bedanken. Sie hat es mir
ermöglicht, einen Einblick in das Thema MDA und AndroMDA zu bekommen. Für
die fachliche Unterstützung bedanke ich mich bei Dipl.-Inf. Stefan Post und bei den
Professoren Axel Buhl und Gero Wedemann.
Zum Umfeld meiner Arbeit. Im Januar 2002 wurde die Deutsche Post Solutions GmbH
[DPITS], als Tochter des Konzerns Deutsche Post World Net, gegründet. Im Okto-
ber 2005 wurde der Name abgeändert in IT Services Center Bonn. In 11 deutschen
Standorten sind ca. 1300 Mitarbeiter beschäftigt. Die Organisationsstrukturen sind
identisch mit den anderen IT Services Centern in Prag, (Tschechische Republik)
Scottsdale (USA) und Cyberjaya (Malaysia). Die Grundelemente der Organisation
in allen Standorten [DPITS-Organigramm]:
-Account Management: Zentraler Ansprechpartner des Kunden, vertritt alle Leistun-
gen der IT Services (Consulting, Anwendungsentwicklung, Produkte, Betrieb)
-Domains: Bündelt die Geschäftstätigkeiten nach Themen
-Product Management: Ist für die Entwicklung und das Life Cycle Management von
Komponenten und Anwendungen zuständig.
-Resource Center: Es bündelt Resourcen zum flexiblen Einsatz in Projekten. In der
Abteilung SW Development 1 ist der Standort Stralsund vertreten. In dieser Abteilung
ist meine Arbeit entstanden.
-Production Services: Bündelt die betriebsnahen Funktionen in der Infrastrukturein-
heit und stellt den Support der produktiven IT-Anwendungen bereit.
1
KAPITEL 1. PROBLEMSTELLUNG
1.2. Erl¨
auterung der Aufgabenstellung
Es soll ein Vergleich der Prozessmodellierung mit CASE-Ansatz und der Prozessmo-
dellierung mit MDA-Ansatz durchgeführt werden. Die Modellierung mit CASE-Ansatz
erfolgt mit einem Plug-in für die Entwicklungsumgebung Eclipse. Dieses Plug-in von
der Firma JBoss erzeugt während der grafischen Modellierung eine Prozessbeschrei-
bung. Beim MDA-Ansatz erfolgt die Modellierung auch mit einem CASE-Tool (Ma-
gicDraw). Die Prozessbeschreibung wird dann mittels AndroMDA [ANDROMDAH]
generiert.
Der Fokus dieser Arbeit liegt auf dem technischen Aspekt der Prozessmodellierung,
sowie der Codegenerierung mittels AndroMDA. Um auf die Generierung von Prozess-
beschreibungen durch AndroMDA eingehen zu können, ist es notwendig, den Aufbau
und die Funktionsweise von AndroMDA, speziell der AndroMDA jBPM-Cartridge, zu
beschreiben. Auf andere Codegeneratoren wird nicht eingegangen. Eine Gegenüber-
stellung einiger Codegeneratoren ist unter [CG] u finden.
2
2. Einf¨
uhrung in die generative
Softwareentwicklung
In diesem Kapitel wird die Theorie nur verkürzt wiedergeben. Auf weiterführende Do-
kumente wird ggf. verwiesen.
2.1. Computer-Aided Software Engineering (CASE)
Wie der Name es schon sagt, können Computer (in Form von CASE-Werkzeugen)
bei der Softwareentwicklung Unterstützung leisten. Diese Werkzeuge können bei der
Planung, beim Entwurf, bei der Implementierung und bei der Dokumentation einge-
setzt werden. Oft werden so genannte UML-Tools verwendet (als ein Vertreter von
CASE-Werzeugen). Unter [UMLTOOLS] findet man einen Vergleich von UML-Tools.
Ein UML-Tool ist MagicDraw. Es ermöglicht dem Entwickler einen Prozess grafisch
mittels UML zu modellieren (in 2.2.1.1 wird einiges zum Thema UML gesagt). In
der Arbeit wird MagicDraw in der Version 9.5 verwendet. Mit neueren Versionen von
MagicDraw kann auch Quelltext generiert werden. Daher ist MagicDraw kein reines
CASE-Tool, was aber für diese Arbeit keine Rolle spielt. Das Eclipse-Plug-in ist ein
CASE-Werkzeug. Damit können ebenfalls Prozesse grafisch modelliert werden. Im
Gegensatz zu MagicDraw, ist das erstellte Modell kein UML-Modell. Außerdem er-
zeugt das Plug-in während der Modellierung eine Prozessbeschreibung. Es findet
also eine Codegenerierung statt. Obwohl eine Prozessbeschreibung generiert wird,
sind CASE-Tools nicht mit der Model Driven Architecture (MDA) oder mit Model Dri-
ven Software Development (MDSD) gleichzusetzen. Im Gegensatz zu CASE-Tools
haben MDA- und MDSD-Werkzeuge keine festen Vorgaben hinsichtlich der Domä-
nenarchitektur (Domänensprache, Transformationen, Zielarchitektur). Beim CASE-
Ansatz findet keine Abstrahierung vom Quellcode statt. So bietet z. B. das Eclipse-
Plug-in nur zwei verschiedene Sichtweisen auf eine Prozessbeschreibung an. Bei
MDA und MDSD findet eine Abstrahierung vom Quellcode statt.
3
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
2.2. Model Driven Architecture und Model Driven
Software Development
Die IT-Branche ist sehr schnelllebig. Technische Änderungen z. B. von Betriebssys-
temen, Datenbanken, Kommunikationswerkzeugen und selbst Änderungen von Pro-
grammiersprachen finden in kurzen Zyklen statt. Fachdomänen hingegen, verändern
sich eher in längeren Zyklen. Es wäre daher sinnvoll, wenn man Fachlichkeiten ge-
trennt von technischen Architekturen entwickeln könnte. Diese und weitere Ideen der
modellgetriebenen, generativen Softwareentwicklung hat die OMG in einem Standar-
disierungsprozess unter dem Namen MDA zusammengetragen. Nun wird näher auf
das Thema MDA eingegangen. Dazu wird hauptsächlich [MDSD] und [SEmUML2]
verwendet.
Die OMG Object Management Group (OMG) wurde 1989 gegründet und ist ein Kon-
sortium aus derzeit ca. 800 Firmen weltweit [OMG]. Sie beschäftigt sich mit der Er-
stellung herstellerneutraler Spezifikationen zur Verbesserung der Interoperabilität und
Portabilität von Softwaresystemen. Bekannte Standards der OMG sind UML, XMI,
MOF, CORBA. Für den MDA-Standard hat die OMG eine MDA-Homepage eingerich-
tet [MDA].
Die OMG ist bemüht, einige Ideen der modellgetriebenen, generativen Softwareent-
wicklung zu standardisieren, verfolgt aber nicht die gleichen Ziele wie das Model Dri-
ven Software Development (MDSD). Ein Vergleich von MDA und MDSD erfolgt spä-
ter. Bei MDA handelt es sich um eine Vorgehensweise zur effizienten Entwicklung von
Softwaresystemen. Dabei zielt MDA auf Interoperabilität (durch Standardisierung soll
Herstellerunabhängigkeit erreicht werden) und auf Portabilität (Plattformunabhängig-
keit) von Softwaresystemen ab. Mit Plattformunabhängigkeit ist dabei nicht nur die
Unabhängigkeit bezüglich eines Betriebssystems gemeint. Plattformen können auf-
einander aufbauen z. B. eine Hardware kann eine Plattform für ein Betriebssystem
sein oder eine J2EE-Anwendung kann eine Plattform für ein eBusiness-System dar-
stellen. Dank MDA soll die Entwicklungs-Performance, Wiederverwendbarkeit, Soft-
warequalität, Wartbarkeit und Interoperabilität gesteigert werden.
Markus Völter (einer der Autoren von [MDSD]) meint dazu:
,,Die Praktikabilität des OMG|MDA-Ansatzes stößt zum Teil auf Skepsis,
die möglicherweise nicht ganz unbegründet ist. Es gibt nicht wenige, die
MDA für eine »Disziplin für Theoretiker« halten." [MDSD]
Richtig ist wohl, dass durch den Einsatz der modellgetriebenen Softwareentwicklung
in Projekten, deren Scheitern nicht verhindert werden kann. Der Einsatz ist aber ein
weiterer Schritt hin zu einer Industrialisierung der Softwareentwicklung.
4
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
2.2.1. Anmerkungen zu den Standards UML, MOF, XML, XMI
2.2.1.1. Unified Modelling Language (UML)
Die Unified Modelling Language ist seit November 1997 standardisiert. Im September
2004 wurde der UML 2.0 Standard verabschiedet (laut [WIKI]). Mit der universellen
Modellierungssprache ist es u. a. möglich, Softwaresysteme visuell zu modellieren. In
der Softwareentwicklung setzt sich immer mehr die Objekorientierung und damit auch
die UML als Modellierungssprache durch. UML baut die objektorientierte Begriffswelt
auf. Mit UML können auch Geschäftsprozesse grafisch modelliert werden.
In UML 2.0 sind 13 Diagrammarten definiert. Sie sind aufgeteilt in Diagramme, die
die Strukturen bzw. das Verhalten einer Anwendung beschreiben. Die 6 Diagramme,
mit denen man die Struktur einer Anwendung modellieren kann, sind: das Klassen-
diagramm, das Objektdiagramm, das Paketdiagramm, das Kompositionsstrukturdia-
gramm, das Komponentendiagramm und das Verteilungsdiagramm.
Die 7 Diagramme, mit denen das Verhalten einer Software modelliert werden kann,
sind: das Geschäftsprozessdiagramm, das Zustandsdiagramm, das Timingdiagramm,
das Sequenzdiagramm, das Kommunikationsdiagramm, das Interaktionsdiagramm
und das für die Prozessmodellierung wichtigste Diagramm, das Aktivitätsdiagramm.
Mit den Aktivitätsdiagrammen können u. a. parallele Abläufe (mit Verantwortlichkeits-
grenzen) modellieret werden. Die Abbildungen 3.8 und A.2 zeigen zwei Aktivitätsdia-
gramme.
Ein weiter Bestandteil der UML ist die Object Contraint Language (OCL). OCL wird
nicht nur für die Überprüfung der Semantik von Modellen verwendet (durch Cons-
traints), sondern auch bei Modell-zu-Modell-Transformationen findet die OCL Verwen-
dung.
AndroMDA verarbeitet derzeit UML 1.4 Modelle. Trotzdem werden einige Änderun-
gen von UML 2.0 im Vergleich zu UML 1.4 kurz aufgelistet. In UML 1.4 sind Akti-
vitätsdiagramme Erweiterungen von Zustandsdiagrammen. Das Aktivitätsdiagramm
in UML 2.0 ist nicht mehr Teil eines Zustandsdiagramms und die Semantik ist jetzt
der der Petri-Netze [PN] ähnlich. Bei UML 2.0 sind mehrere Startknoten erlaubt und
zusätzlich zum Aktivitätsendknoten gibt es in UML 2.0 auch Ablaufendknoten. Mehr
Informationen zu UML 2.0 siehe [SEmUML2] und [UMLH].
Es gibt auch Neuerungen in UML 2.0, die im Zusammenhang mit MDA hinzugekom-
men sind. Durch die UML 2.0 Superstructure ist UML und OCL formal beschrieben.
Das ist für die Modelltransformation und die Codegenerierung wichtig. Es wurde auch
die Möglichkeit, UML mittels UML-Profilen zu erweitern, bei UML 2.0 überarbeitet.
Weiterhin wurden Erweiterungen für die Modellierung von Komponenten vorgenom-
5
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
men. Mehr Informationen sind in [MDSD] zu finden.
Ein wichtiges UML-Konzept für MDA ist das Erstellen von UML-Profilen. Eine Domä-
ne kann mittels Domain Specific Language (DSL) beschrieben werden. In der Praxis
wird dazu häufig UML mittels Profilen erweitert. Durch UML-Profile kann UML erwei-
tert werden und zwar ohne dass man das UML-Metamodell ändern oder erweitern
muss. Bei Verwendung von UML-Profilen findet eine Spezialisierung statt. Die eige-
nen Konstrukte einer Sprache können zu einem UML-Profil zusammengefasst wer-
den. UML-Profile enthalten Basis-UML-Konstrukte wie Klassen, Assoziationen, Ste-
reotypen, Tagged Values und Constraints. Tagged Values legen die Eigenschaften
der UML-Elemente fest. Sie werden in geschweiften Klammern angegeben und be-
stehen aus einem Namen und einem Wert. Mit Constraints lassen sich Modellierungs-
regeln festlegen. Diese besondere Form von Tagged Values ist auf boole'sche Aus-
drücke beschränkt und kann ebenfalls in geschweiften Klammern angegeben werden.
Ein Stereotyp ist eine UML Klasse, die beschreibt, in welcher Form eine andere UML
Klasse für ein spezielles Einsatzgebiet angepasst werden kann. Ein Stereotyp kann
durch Tagged Values und Constraints genauer spezifiziert werden. Der Name eines
Stereotyps steht zwischen ,,« und »". Oft verwendete Namen für Stereotypen sind z.
B. ,,«entity»" oder ,,«service»".
Die OMG schlägt für die Modellierung von Softwaresystemen, wie bereits erwähnt,
den eigenen Standard UML vor, aber Modelle müssen nicht zwingend mit UML be-
schrieben werden. Laut OMG ist ein Modell: die formale Repräsentation von Struktur,
Funktion oder Verhalten eines Systems. Also sind klassische Programmiersprachen
(z. B. C++ oder Java) MDA-Modellierungssprachen und deren Programme sind dem-
nach MDA-Modelle. In der Praxis werden von den MDA-Tools UML-Modelle verarbei-
tet. Ein UML-Tutorial findet man unter [UMLT].
6
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
2.2.1.2. Meta Object Facility (MOF)
MOF ist ein weiterer Standard der OMG.
Dieser Standard definiert ein Meta-Metamodell (Grammatik) zur Definition von Meta-
modellen. Abbildung 2.1 veranschaulicht das 4-Schichtenmodell.
Abbildung 2.1.: 4-Schichtenmodell [WIKI]
7
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Abbildung 2.2.: MOF-Metamodell [WIKI]
8
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Die 4 Meta-Ebenen sind:
-M3 dient als Basis für Metamodelle, ist also die Meta-Metamodell-Ebene. Die OMG
setzt auf dieser Ebende MOF 2.0 ein, folglich sind alle OMG-Sprachtechnologien
Instanzen dieser Ebene. Ein vereinfachtes MOF-Metamodell ist in Abbildung 2.2 ab-
gebildet.
-M2 kann man z. B. als UML 2.0 Ebene bezeichnen, hier wird die Sprache UML 2.0
definiert, also das UML Metamodell.
-In der Ebene M1 sind die, z. B. aus UML enstandenen, ,,Benutzer-Modelle" angesie-
delt, also Instanzen des UML-Metamodells.
-M0 ist die Objekt-Ebene, sie beinhaltet Objekte der Realität.
Ein Beispiel für ein MOF-konformes Metamodell ist das UML1.4-Metamodell, das in
AndroMDA Verwendung findet (siehe [UML14META]). MOF definiert nicht nur eine
Menge von Meta-Metamodellkonzepten, sondern auch Ableitungsregeln für die Er-
zeugung von Interfaces zum Zugriff auf Repositories (Sammlung von Metamodellen)
und Regeln, die es durch eine entsprechende XML-Repräsentation (z. B. XMI) er-
möglichen, MOF-konforme Metamodelle auszutauschen.
9
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
2.2.1.3. Extensible Markup Language (XML)
Die eXtensible Markup Language (XML) ist ein Standard der vom World Wide Web
Consortium (W3C) verabschiedet wurde. Mit XML kann die Struktur eines Dokuments
definiert werden. Weiterhin ist es mit XML möglich, den Inhalt und die Darstellung
voneinander zu trennen. In einem XML-Dokument können sich Inhalte befinden, die
mittels Transformationen (z. B. der XLST) umgewandelt und dargestellt werden kön-
nen. Die Syntax eines XML-Dokuments kann mittels Document Type Definition (DTD)
oder einem XML-Schema definiert werden.
XML-Dokumente müssen Regeln erfüllen:
- Elemente sind ohne Überlappungen zu schachteln.
- Elemente mit Inhalt müssen einen Start-Tag und Ende-Tag besitzen.
- Attributwerte müssen in Hochkomma stehen.
- Ein leeres Element muss einen Ende-Tag besitzen
(z. B. <Test></Test>) oder mit /> enden.
Grundsätzlicher Aufbau eines XML-Dokuments:
- ein Start-Tag mit Namen,
- XML Attribute mit Namen und Wert,
- textuelle Inhalte und
- ein End-Tag mit demselben Namen wie der Start-Tag
Mehr zu XML ist unter [XML] zu finden.
2.2.1.4. XML Metadata Interchange (XMI)
Mit XML Metadata Interchange (XMI) wurde ein Standard von der OMG spezifiziert,
mit dem Metadaten ausgetauscht werden können. Somit sollte der Austausch von z.
B. UML Modellen, die mit verschiedenen Tools grafisch erstellt wurden, theoretisch
möglich sein.
Seit November 2001 gibt es die zwei XMI-Versionen XMI 1.2 und XMI 2.1. In [XMI11]
wird von der OMG die XMI Version 1.1 (DTD) beschrieben und in [XMI21] wird die
Version 2.1 (XSD) spezifiziert.
In der XMI Version 1.1 gibt es Regeln (Tags) zur Transformation von MOF-basierten
Metamodellen in XMI-valide XML-Dokumente. Strukturvorschriften werden durch frei
definierbare Tags, den XML DTDs, erzeugt. MagicDraw verwendet eine DTD als For-
matvorlage, um XMI konforme XML-Dokumente zu generieren. Ein Beispiel einer
DTD (UML1.4-XMI1.1-DTD) findet man unter [UML14DTD].
10
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Im Anhang befinden sich einige Auszüge aus einer DTD, die zum Erstellen des fol-
genden Beispiels verwendet wurden. Ein Beispiel einer XML-Datei (,,MeineKlasse"),
die durch den Export mit MagicDraw unter Verwendung einer DTD als Formatvorlage
entstanden ist, wird ebenfalls im Anhang angegeben. Hier nun Auszüge aus der XML-
Datei ,,MeineKlasse.xml", die eine textuelle Beschreibung der Klasse mit dem Namen
,,MeineKlasse", mit dem Attribut ,,meinAttribut" und der Methode ,,meineOperation()"
ist.
Abbildung 2.3.: Klassendigramm
"
MeineKlasse"
11
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Einige Elemente des XML-Dokuments ,,MeineKlasse.xml":
-XML Bezeichner mit Version und Zeichensatz:
<?xml version = '1.0' encoding = 'UTF-8' ?>
-Das XMI ,,Root" Element mit obligatorischem Attribut ,,xmi.version":
<XMI xmi.version = '1.2' xmlns:UML = 'org.omg.xmi.namespace.UML'
timestamp = 'Mon Jan 23 14:20:42 CET 2006'>
-Im XMI-Header-Tag werden Informationen über das dargestellte Modell hinterlegt.
Hier kommen meist die Child Elemente ,,xmi.metamodel" und ,,xmi.documentation"
vor:
<XMI.header>
<XMI.documentation>
<XMI.exporter>MagicDraw UML</XMI.exporter>
<XMI.exporterVersion>9.5</XMI.exporterVersion>
</XMI.documentation>
<XMI.metamodel xmi.name='UML' xmi.version='1.4'/>
</XMI.header>
-Innerhalb des XMI-Content-Tags wird der Inhalt des Metamodells beschrieben:
<XMI.content>
...
</XMI.content>
-,,UML:Model" legt fest, dass es sich bei den innerhalb des Tags befindlichen Elemen-
ten um die eines UML Modells handelt:
<UML:Model xmi.id='eee_1045467100313_135436_1' name='Data'></UML:Model>
-Hier wird angegeben, dass die innenstehenden Elemente (Attribute und Operatio-
nen) zu der Klasse ,,MeineKlasse" gehören:
<UML:Class xmi.id='_9_5_1_73401ef_1144234037645_791034_88' name='MeineKlasse'>
</UML:Class>
12
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
-UML:Attribute definiert das Attribut ,,meinAttribut":
<UML:Attribute xmi.id='_9_5_1_73401ef_1144234731474_121278_105'
name='meinAttribut'>
<UML:Attribute.initialValue>
<UML:Expression xmi.id='_9_5_1_73401ef_1144234751281_767141_110'/>
</UML:Attribute.initialValue>
</UML:Attribute>
-Die ,,public" Operation ,,meineOperation" wird durch ,,UML:Operation" festgelegt:
<UML:Operation xmi.id='_9_5_1_73401ef_1144234731474_895763_107'
name='meineOperation' visibility='public'>
<UML:BehavioralFeature.parameter>
<UML:Parameter xmi.id='_9_5_1_73401ef_1144234731474_717354_106' kind='return'/>
</UML:BehavioralFeature.parameter>
</UML:Operation>
Jedes Element im Dokument wird mit einer eindeutigen ID gekennzeichnet. Somit ist
der direkte Zugriff auf die Elemente möglich. Weiterhin werden diese IDs von MDA-
Tools, im Zusammenhang mit so genannten geschützten Bereichen, verwendet.
13
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Die XMI Version 2.1 wird mittels XSD definiert. Ein konkretes XML-Schema wird als
XML-Schema-Definition (XSD) bezeichnet und hat üblicherweise die Endung .xsd.
XML-DTDs sind nicht so komplex wie XML-Schemata, werden aber vermutlich bald
durch XML-Schemata abgelöst werden. Einige Vorteile von XML-Schemata gegen-
über DTDs sind: XML-Schemata sind erweiterbar, kennen reguläre Ausdrücke, unter-
stützen umfangreiche Datentypen und sie sind selbst in XML geschrieben. In [XMI21]
werden die Regeln zur Erzeugung von XMI Version 2 Schemata (in EBNF) aufgeführt.
Die Zuweisung eines Schemas an ein XML-Dokument erfolgt mit einem Verweis zu
Beginn des XML-Dokuments. Zum Zuweisen eines Namensraums müssen die At-
tribute ,,xmlns:xsi" und ,,xsi:schemaLocation" verwendet werden. Der Beginn eines
XML-Dokuments könnte so aussehen:
<beispiel xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/xhtml
beispiel.xsd">
Durch ein XML-Schema kann man u. a. festlegen, welche Elemente, Attribute, Da-
tentypen in einem Dokument vorkommen dürfen. Wie in 4.2 beschrieben, wird XSD
verwendet, um die Struktur einer Prozessbeschreibung für die JBoss jBPM Workflo-
wengine vorzugeben. Man findet das Schema unter [JDPLXSD]. Ein weiteres Beispiel
für ein XML-Schema, welches Struktur eines jBPM-Cartridge-Deskriptors festlegt, fin-
det man unter [CDS]. Da MagicDraw die XMI Version 1.2 (also DTD) verwendet, wird
hier nicht noch weiter auf XML-Schemata eingegangen und auf [XMLS] verwiesen.
In der Praxis ist der Austausch von Metadaten noch problematisch. Viele UML-Design-
Tools exportieren Daten in der XMI Version 1.2, so auch Poseidon und MagicDraw.
Trotzdem sind diese Tools nicht kompatibel zueinander. AndroMDA verwendet zum
Weiterverarbeiten der XMI-Dokumente NetBeans MDR (Metadata Repository). Da-
mit können XMI 1.2 Dokumente importiert werden. Leider ist somit nur eine Unter-
stützung von UML 1.4 gegeben, UML 2.0 Modelle können deshalb derzeit nicht mit
AndroMDA verarbeitet werden.
14
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
2.2.2. Vorstellung der MDA-Konzepte
Eines der Schlüsselkonzepte von MDA, um Plattformunabhängigkeit zu ereichen, ist
die Trennung von PIM (Platform Independent Model) und PSM (Platform Specific
Model). Konzepte finden länger Verwendung als Technologien. Ausserdem besitzen
formale Modelle das Potential automatisiert Transformationen durchzuführen (z. B.
Codegenerierung aus Modellen). Was ist nun aber ein PIM bzw. ein PSM? Zunächst
gibt die MDA so genannte Viewpoints vor. Sie bieten verschiedene Sichten auf ein
bestehendes bzw. auf ein zu entwickelndes System. Um eine Softwarearchitektur
beschreiben zu können, wie es vom Institute of Electrical and Electronics Engineers
durch IEEE 1471 vorgeschlagen wird, gibt es die folgenden MDA-Viewpoints:
-Computation Independent Viewpoint (Umgebung und Anforderungen eines Systems,
aber ohne Struktur und interne Arbeitsweise)
-Platform Independent Viewpoint (Funktionalitäten des Systems, aber Plattformunab-
hängig)
-Platform Specific Viewpoint (Platform Independent Viewpoint inklusive Plattformin-
formationen und Angaben zur Realisierung des Systems auf dieser Plattform)
Aus diesen Viewpoints können MDA Modelle in folgende Gruppen eingeteilt werden:
-Computaion Independent Model (CIM)
-Platform Independent Model (PIM)
-Platform Specific Model (PSM)
-Platform Model (PM)
Das CIM enthält den Grundwortschatz für weitere MDA Modelle wie PIM und PSM.
Es beschreibt die Anforderungen an die Umgebung und die Nutzung eines Systems.
Nicht beschrieben werden die innere Struktur und das innere Verhalten eines Sys-
tems. Das CIM wird mittels UML repräsentiert, wobei dafür meist Anwendungsfalldia-
gramme, Aktivitätsdiagramme, Interaktionsdiagramme und Klassendiagramme ver-
wendet werden. Das Computation Independet Model wird oft auch als Domainmodell
oder Geschäftsmodell bezeichnet.
Das PIM bildet in MDA das Kernstück. Es kann aus dem CIM hervorgehen. Im platt-
formunabhängigen Modell wird die Struktur und das Verhalten eines Systems, unab-
hängig von einer später verwendeten Plattform (Software, Hardware), festgelegt. Zu-
sätzlich zum CIM, wird im PIM die innere Struktur und das Verhalten eines Systems
beschrieben. Durch die plattformunabhängige Erfassung der Business-Logik und des
Domänenwissens in einem PIM können fachliche Zusammenhänge langfristig und
zentral erfasst werden.
15
KAPITEL 2. EINF ¨
UHRUNG IN DIE GENERATIVE SOFTWAREENTWICKLUNG
Durch ein Plattformmodell (PM) werden die Struktur einer Plattform und die von der
Plattform angegebenen Dienste beschrieben. Was alles eine Plattform sein kann,
wurde schon in 2.2 dargelegt. Das PM liefert Konzepte für eine später in den PSMs
einzusetzende Modellierungssprache z. B. in Form von UML-Profilen. Mit der Wei-
terentwicklung von MDA ist es vielleicht möglich, dass es zukünftig standardisierte
Plattformmodelle gibt.
Das Platform Specific Model (PSM) ist das wichtigste Modell für die Codegnerierung.
Für die reine Codegenerierung ist nur das PSM notwendig. Es enthält alle Informatio-
nen die notwendig sind, um ein Softwaresystem oder eine Komponente eines solchen
Softwaresystems generieren zu können. Da das PSM technologiebezogen ist, wird in
der Theorie angestrebt, durch eine oder mehrere Transformationen aus einem oder
mehreren PIMs zu einem PSM zu gelangen. Abbildung 2.4 zeigt, wie aus einem PIM
durch Zugabe weiterer Informationen (PM) und durch eine Transformation ein PSM
entsteht.
16
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2006
- ISBN (eBook)
- 9783832499259
- ISBN (Paperback)
- 9783838699257
- DOI
- 10.3239/9783832499259
- Dateigröße
- 1.7 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Fachhochschule Stralsund – Elektrotechnik, Bachelor Informatik
- Erscheinungsdatum
- 2006 (Oktober)
- Note
- 2,0
- Schlagworte
- software-entwicklung quelltextgenerator
