Transcription
FernUniversität in HagenSeminar in Informatik (01917, WS2009/10)Eclipse – Projekte und EntwicklungModel Development Tools (MDT)Jochen [email protected] Projekt Model Development Tools“ (MDT) ist Teil des Eclipse Modeling“””Projekts (EMP) und stellt mit seinen Schwesterprojekten Werkzeuge zur Verfügung,damit modellgetrieben Software entwickelt werden kann. MDT baut hier auf demEclipse Modeling Framework“ (EMF) und dem Graphical Editing Framework“””(GEF) auf, nutzt also bereits bestehende Projekte - grafische Editoren können aufdiese Weise erstellt werden. Mehr noch, aus diesen Modellen kann Programmcodein der Zielsprache gegossen werden.MDT samt seiner Unterprojekte fokussiert sich dabei auf die Umsetzung existierender Spezifikationen der Object Management Group“ (OMG), genauer Busi””ness Process Modeling Notation“ (BPMN), Object Constraint Language“ (OCL),”Unified Modeling Language“ (UML) und Extensible Markup Language Schema””Definition“ (XSD). Neben der Implementierung dieser Spezifikationen gibt es auchweitere Unterprojekte, die die nötigen Anwendungstools stellen, damit mit den Spezifikationen gearbeitet werden kann.1 EinleitungDie Softwareentwicklung strebt danach, die Komplexität der Softwaresysteme besser beherrschbar zu halten und so die relative Anzahl erfolgreicher Projektabschlüsse zu steigern [SW02, S. 2 ff.]. Die modellgetriebene Entwicklung derartiger Systeme ist hier einer der Kandidaten für einen Lösungsansatz. Bei dieser modellgetriebenen Strategie solldem Eclipse-Projekt eine Schlüsselrolle zukommen, genauer dem EMP. Der Untertitel desEMPs A Domain-Specific Language (DSL) Toolkit“ lässt schon erahnen, dass dort vor”allem Hilfen zur Entwicklung von domänenspezifischen Sprachen angeboten werden.Das EMP fasst als Container-Projekt einige Unterprojekte, die aufeinander aufbauen oderin Wechselwirkung stehen. EMF, GEF und das Graphic Modeling Framework“ (GMF)1”leisten beispielsweise alles Notwendige, dass grafische Editoren erstell- und nutzbar sind.Mehr noch, sie ermöglichen, dass aus den fertigen Modellen dann Programmcode in derZielsprache wird.MDT baut auf diese Projekte auf und regelt, dass die bestehenden Spezifikationen umsetzbar sind. Darüber hinaus werden notwendige Tools geliefert, die einen Gebrauch der1Das GMF soll die beiden Projekte EMF und GEF geschickt verzahnen.
Model Development Tools (MDT)Spezifikationen erst ermöglichen. Beispielsweise gibt es die beiden MDT-UnterprojekteUML2“ und UML2 Tools“ , die so das Zusammenspiel aus Spezifikations- und Werk””zeugprojekt widerspiegeln. MDT spezialisiert sich dabei auf das Umsetzen existierenderStandards der OMG, wie UML, OCL, XSD, BPMN.Ziel der Arbeit ist es einen Überblick zu geben, inwieweit MDT samt seiner Unterprojekte in der Lage ist, die Lösungen für die anfallenden Probleme der modellgetriebenenEntwicklung zu liefern.2 Modellgetriebene Entwicklung2.1 Definition und WegModellgetriebene Softwareentwicklung (MDSD) will automatisch Quellcode aus domänenspezifischen Modellen generieren. Model Driven Architecture (MDA) ist dabei der Ansatzder OMG für die modellgetriebene Softwareentwicklung. MDA ist von der OMG patentiert und folglich wird als Alternativbegriff zu MDA auch Model Driven Development(MDD) für modellgetriebene Entwicklung genutzt. Bezogen auf MDT ist die genaue Abgrenzung zwischen MDSD und MDA unerheblich, beide haben das Ziel aus ModellenProgrammcode automatisch zu erstellen2 .MDD ist möglich, wenn es eine passende Modellierungssprache und passende Werkzeugefür die betreffende Domäne gibt. Dazu müssen die Modelle in Quellcode oder in andere Modelle transformierbar sein und der Quellcode muss für eine ausgereifte Plattformerzeugt werden können. Als Austauschformat für Modelle wird häufig XML MetadataInterchange (XMI) eingesetzt. Die OMG strebt dabei noch eine Standardisierung derTransformations- und Modellierungssprachen an, die Interoperabilität der Werkzeuge sollso erst einmal möglich bzw. verbessert werden [RHQ 05, S. 59].Eine Sprache im Sinne der MDA muss zum einen die Domäne erfassen und zum anderen rigide definiert sein, damit die Modelle validier- und zu Quellcode transformierbarsind. Die UML als Universalsprache kann und will dies so natürlich nicht leisten. Allerdings kann mit Hilfe des in der UML-Version 2.0 eingeführten Elements Profil“ der”UML-Sprachschatz auf eine bestimmte Domäne zugeschnitten werden. Um am Ende beieiner domänenspezifischen Sprache zu landen, gibt es also die Option eine Universalsprache einzuschränken oder eine eigene domänenspezifische Sprache formal von Null an zubeschreiben.2Vergleich von MDA und MDSD, siehe [Etz06, S. 13]
Model Development Tools (MDT)2.2 Metamodelle und deren Bedeutung für die MDDEin Metamodell ist ein Modell, das die darunter liegende Schicht beschreibt und die untereSchicht ist eine Instanz der darüber liegenden Schicht [RHQ 05, S. 54]. Meta kommtaus dem Griechischen und bedeutet Über“ , Metamodell steht also für ein Übermodell,”Metaschicht für Überschicht. Über bezieht sich dabei auf Schichten, also eine Metaschichtliegt eine Schicht über der aktuellen Schicht, eine Metametaschicht eine weitere Schichtüber der Metaschicht. Eine einzelne Metaschicht kann man als Metamodell bezeichnen,allerdings werden alle Metaschichten gemeinsam auch als Metamodell bezeichnet. Manmuss also aufpassen, von welchen Schichten nun genau gesprochen wird, wenn von einemMetamodell die Rede ist.Am Beispiel der UML soll dieser Schichtaufbau klar gemacht werden, siehe Abbildung S.4. Die Schicht M0 fasst die Instanzen, also das Objektgeflecht, dass der Anwender beimBenutzen der Software erzeugt und dessen Instanzen miteinander interagieren. Auf derSchicht M1 steht das vom Programmierer modellierte Anwendungssystem. Die Schicht M0ist eine Instanz der Schicht M1. Hier wird also geklärt, welche Attribute eine Buch-Instanzder Schicht M0 hat. Für jede Schicht muss geklärt werden, wie das Modell notiert werdensoll und meist wird im objektorientierten Umfeld die UML zur Beschreibung einer jedenSchicht genutzt. Auf der Schicht M2 steht die UML-Sprachbeschreibung selbst, also dieRegeln, die der Systemmodellierer einzuhalten hat. Wie schon bei den darunter liegendenSchichten wird zur Beschreibung die UML genutzt. Folglich wird M2, also die UML mit derUML-Syntax beschrieben. M2 beschreibt hier etwa, dass eine ’Class’ wie ’Buch’ beliebigviele ’Property’-Instanzen haben darf. Auf der Schicht M3 wird die Metaschicht zur UMLbeschrieben, also welcher Satz an Elementen in der UML vorkommen darf, hier etwa’Class’, ’Association’ und ’Generalization’. Auf der Schicht M3 ist beim OMG-Standarddie Meta-Object-Facility (MOF), was mit Metaobjektmöglichkeiten eingedeutscht werdenkann.MOF und UML sind eine mögliche Basis, wie man modellgetrieben entwickeln kann[SVEH07, S. 64]. Dabei ist MOF das Metametamodell und UML das Metamodell. Durchdie bereits genannten Profile kann man sich die Universalsprache UML auf die Problemdomäne zurechtschustern. Diese Herangehensweise funktioniert, hat aber den Nachteil,dass man die UML nur schlecht um Kernelemente reduzieren kann - will man dies dennoch, muss man einen anderen Weg suchen, etwa eine eigene domänenspezifische Spracheentwerfen.Eclipse arbeitet mit einem anderen Metametamodell als MOF, nämlich Ecore. Ecore istdem Metametamodell Essential-MOF“ (EMOF), eine auf das Wesentliche zusammenge”stauchte Version von MOF, sehr ähnlich. Ecore ist Bestandteil des Eclipse-Projekts EMF.EMF lässt dann aus solchen Ecore-Modellen die Java-Implementierung oder andere Modelle generieren. Die UML konnte mit Ecore anstatt mit MOF als Metamodell beschriebenwerden und so sind UML-Modelle nun auch für EMF nutzbar.
Model Development Tools (MDT)Abbildung 1: Vier Schichten Modell um die UML [RHQ 05, S. 54]
Model Development Tools (MDT)Es gibt also vor allem zwei Optionen im Eclipse-EMF-Umfeld die Struktur seiner Problemdomäne auf der Ebene M2 zu beschreiben, einmal indem man ein bestehendes Modellwie die UML an seine Bedürfnisse anpasst oder indem man sein eigenes Modell auf EcoreBasis erstellt.2.3 Vorgehen bei der MDDHat man sich festgelegt, ob man auf UML setzen will oder die Schicht unterhalb vonEcore selbst formuliert, kann man seine Problemdomäne beschreiben. Die UML kannman durch die Profile und die OCL auf seine Problemwelt anpassen [S. 9 ff.]. Dies wurdefür einige Domänen bereits erfolgreich getan und es entstanden Standards der OMG, etwaBPMN für Geschäftsprozesse [BPMN, Abbildung S. 7; Fachliche Modellierung, AbbildungS. 9]. Man muss das Rad also für vieles nicht neu erfinden. Eine solche problemspezifischeSprache innerhalb einer Universalsprache, wie hier innerhalb der UML wird als interneDSL bezeichnet. Im Gegensatz dazu steht eine externe DSL, die man von Grund auf selbstdefiniert [Fow05].Die Implementation und das Erstellen der notwendigen Tools für einen von der OMGdefinierten Standard ist dann allerdings wieder den kommerziellen oder Open-SourceProjekten vorbehalten [SVEH07, S. 72]. Genau hier soll das MDT helfen und liefert etwamit UML2 ein Projekt, dass den UML-Standard beschreibt und mit den UML2 Toolseine Sammlung von Werkzeugen, um mit dem Standard arbeiten zu können. Die anderenSpezifikationen erweitern oftmals die UML - sie sind also als interne DSLs zur UML zusehen.Für den Gebrauch einer Universalsprache beim Modellieren spricht, dass man direkt starten und auf alle bewährten Werkzeuge seiner IDE zurückgreifen kann. Nachteilig ist, dassalle domänenspezifischen Fehler unentdeckt bleiben, die in der Universalsprache syntaktisch erlaubt sind. Definiert man die Sprache selbst, ist sie genau an der Problemweltangelehnt, aber es fehlen oft die nötigen Werkzeuge zum Einsatz. Für den Bau solchernotwendiger Werkzeuge zum Modellieren, Parsen und Codegenerieren mit externen DSLsgeben die Schwesterprojekte der MDT Hilfestellung. Auf diese Werkzeuge wird in dieserArbeit nicht weiter eingegangen.Am Ende steht dann ein domänenspezifisches Modell aus dem Programmcode für dieAnwendung der Zielplattform oder ein anderes Modell erstellt werden kann.3 MDT innerhalb des Modeling-ProjectsMDT ist ein Container-Projekt. Die Unterprojekte sind operation projects“. MDT selbst”ist in der Inkubationsphase. Die Unterprojekte sind in unterschiedlichen Phasen, aktuellsind BPMN2, Information Management Metamodel (IMM), MST, Papyrus, SBVR, OCL,UML2, UML2Tools und XSD als Projekte unter dem MDT-Dach versammelt.
Model Development Tools (MDT)Das Modeling-Projekt versucht besonders bei der Erstellung eigener DSLs zu helfen, wieman aus dem Untertitel des EMPs A Domain-Specific Language Toolkit“ erkennen kann.”MDT läuft dabei etwas nebenher und sorgt dafür, dass die bestehenden Spezifikationendabei genutzt werden können, allerdings eben auch für sich alleine verfügbar sind, etwa UML2 zum Gebrauch der UML-Spezifikation. Darüber hinaus sollen Werkzeuge zumGebrauch der Spezifikationen geliefert werden, etwa UML2Tools, die die Arbeit mit denStandards ermöglichen. Man wird sehen, dass die Spezifikationen der OMG teilweise alsinterne DSL der Universalsprache UML umgesetzt sind, genauer sie erweitern oftmalsdie UML durch Profile [Kapitel S. 9 ff.]. Mit den eben genannten Grundlagen ist es nunmöglich, die Rolle und Ideen zu verstehen, die hinter den einzelnen MDT-Unter-Projektenstecken [Ver09a].MST hat zum Ziel den passenden Rahmen zu schaffen, um mit dem MOF-Metametamodellarbeiten zu können. Die UML-Spezifikation leitet sich von MOF ab [Abbildung S. 4]. ImEclipse-Umfeld wurde UML aber von Ecore als Metamodell beschrieben. MST hat nunzur Aufgabe, dass das MOF-Metamodell verfügbar ist, falls dies einmal notwendig werdensollte. MST regelt auch die Serialisierung von Modellen im XMI-Format. Zukünftig sollMST eine Hilfe beim Bau von Spezifikationen sein, also insbesondere interessant für dieBeteiligten der OMG [Ver09c].UML2 ist die Implementierung des UML-Standards. UML2 liefert allerdings keine Werkzeuge, sondern nur die Implementierung des UML-Standards, Testfälle, Validierungsfälleund ein XMI-Schema, damit Modelle serialisiert und ausgetauscht werden können [Ver09d].Wie UML2 ist auch das OCL-Projekt die Implementierung des OCL-Standards. Es werden keine Tools zum Umgang angeboten. Wie schon erwähnt, ist die OCL eine Abfragesprache für UML-Diagramme und lässt es so zu, dass man die Anforderungen an einDiagramm deutlich genauer formulieren und auch prüfen kann. Das zugehörige OCLTools-Projekt ist allerdings eingestellt, der Termination Review wurde am 8. Oktober2008 eingereicht[Ver09a].Die Projekte BPMN2, IMM, SBVR sind interne DSLs, dabei ist UML die Hostsprache.BPMN2 implementiert den BPMN-Standard der OMG in der kommenden Version 2. Dabei ist das Ziel der BPMN die grafische Darstellung der Geschäftsprozessmodellierung.Es werden also Symbole angeboten, mit denen dann eine Folge von Tätigkeiten modelliert werden kann. Seit 2005 befindet sich diese Domäne unter dem Dach der OMG alseiner der Standards. Die grafischen Elemente werden eingeteilt in Flow Objects (Knotenim Geschäftsprozessdiagramm), Connection Objects (Kanten im Diagramm), Swimlanes(Bereichsabgrenzung für Bereiche) und Artifacts (weitere Elemente). BPMN [AbbildungS. 7] spielt mit SBVR zusammen: SBVR liefert die Norm für Fachbegriffe, Geschäftsobjekte und Geschäftsregeln für BPMN [BA07, S. 3]. SBVR ist eine Implementierungeines Metamodells für Geschäftsregeln und Geschäftsvokabular, SBVR ist ebenfalls einOMG-Standard. Dabei wird es durch die Spezifikation möglich, dass eine Transformationdes Platform Independent Model (PIM) zum Platform Specific Model (PSM) gelingt. DerWechsel vom PIM zum PSM ist ein spezieller Abschnitt des von der OMG patentiertenMDA-Standards [Etz06, S. 11].
Model Development Tools (MDT)Abbildung 2: Business Process Modeling Notation Standard, aus [Ver09g]IMM ist wie UML2, OCL, BPMN2 und SBVR ein Projekt, dass den Standard der OMGimplementiert. Der OMG-Standard soll dabei den bestehenden Standard Common Ware”house Metamodel“ (CWM) ablösen. CWM soll durch IMM abgelöst werden, damit IMMim MDA-Prozess verwendet werden kann. CWM ist nicht so formuliert, damit eine Codegeneration möglich ist und der Name spiegelt den Aufgabenbereich des Profils nicht angemessen wider, die beschriebene Domäne geht weit über Data Warehouses hinaus[Ver09f].Dabei soll das Projekt auch die Chance nutzen, die Kooperation der OMG und der EclipseWelt zu intensivieren [Ver09b].Papyrus soll ein Editor für UML und Systems Modeling Language“ (SysML) werden.”SysML ist eine Sprache für die Modellierung komplexer Systeme, an denen neben Softwarefachleuten auch Elektrotechniker und Regelungstechniker mitwirken [Wol07]. SysMLerweitert die UML [Ver09j] und ist selbst auch ein OMG-Standard. SysML bietet teilsandere Diagrammarten wie die UML, etwa Systemkontextdiagramme und dazu die profilüblichen eigenen Stereotypen innerhalb der Diagramme. Zusätzlich gibt es Konventionen bei den Kommentaren, um so die Aussagen zu kategorisieren [Abbildung S. 8] undso die Aussagekraft zu erhöhen. Der Praxisnutzen von SysML ist umstritten [PR08, Teil4, Fazit]. Papyrus soll einmal selbst zu einem Containerprojekt werden und dabei viele andere Projekte unter sich bündeln, damit ein MDD-Werkzeug entsteht, welches eineOpen-Source-Alternative zu den kommerziellen Spitzenwerkzeugen darstellt. Entwickeltwird Papyrus von einem Konsortium unter Federführung von LISE, einem Team einerfranzösischen Atombehörde. Papyrus baut dabei auf UML2 auf, arbeitet in Kombinationmit TOPCASE, einer Model-Based-Engineering-Platform und MOSKitt einem Editor,der die UML2 Tools erweitert und eine Kompatibilität mit verschiedenen CASE-Toolssicherstellen soll. Papyrus soll also ein sehr umfassendes Projekt im Rahmen der modellgetriebenen Entwicklung werden [Ken09].UML2 Tools stellt die grafischen Werkzeuge zur Verfügung, dass mit dem UML-Standardim Eclipse-Umfeld gearbeitet werden kann, also UML2-Modelle wirklich erstellt und bearbeitet werden können. Es ist daher eine Konkurrenz zu Papyrus, obwohl Papyrus auchlängerfristig plant, die UML2-Tools irgendwann einmal abzulösen bzw. zu vereinnahmen.UML2 Tools basiert auf GMF. Aktuell ist die Version 0.9 und unterstützt werden Strukturdiagramme (Klassendiagramm, Profildefinition, Kompositionsdiagramm, Komponentendiagramm, Deploymentdiagramm), Verhaltensdiagramme (Aktivitätsdiagramm, Zustandsdiagramm, Anwendungsfalldiagramm), Interaktionsdiagramme (Sequenzdiagramm,
Model Development Tools (MDT)Abbildung 3: Diagramme und -elemente der SysML mit profilbezogenen Stereotypen undKommentarkonventionen, Abbildung nach [Tim08]
Model Development Tools (MDT)Abbildung 4: Zusammenspiel von Standards und Projekten im MDTTimingdiagramm (noch unveröffentlicht)). Das Projekt baut natürlich auf UML2 auf[Ver09e].XSD ist die Implementierung des OMG-Standards XML Schema Definitions (XSD). DieMöglichkeit zur Arbeit mit XSD ist sehr wichtig, da EMF-Modelle mit einer XMLbasierten Sprache beschrieben werden können und XSD gibt hier die Möglichkeit dieStruktur von XML-Dokumenten festzulegen, also die Regeln zu beschreiben und die dannnach den Regeln erstellten Modelle automatisch auf Regeleinhaltung zu überprüfen. XSDspielt somit überall eine Rolle, wenn mit XML-Dokumenten gearbeitet wird.Das Zusammenspiel der MDT-Projekte soll durch die Abbildung auf S. 9 verdeutlichtwerden: die UML-Profile erweitern die UML und passen diese an eine bestimmte Domänefachlich an. MST und die XML-Standards befinden sich eher auf der Seite der technischenModellierung. Die Gestaltungsvorschrift der XMI-Datei zum jeweiligen Modell wird vomImplementierungsprojekt festgelegt, also legt etwa UML2 für UML-Modelle fest, wie dieseals XMI-Datei abzubilden sind. Die Tabelle auf S. 10 zeigt, welches Projekt zu welchemStandard gehört und gibt einen Hinweis auf den Aufgabenbereich oder die Versionsnummer des Projekts.4 Profile und OCL bei internen DSLs auf UML-BasisWill man Software modellgetrieben, aber ohne eigens formulierte Sprache entwickeln,wird man gewöhnlich auf UML setzen, sofern nichts gegen einen solchen Einsatz spricht.Bei Bedarf hält man Ausschau, ob ergänzende Standards für die eigene Domäne bereitsexistieren. Bei diesen internen DSLs spielen die OCL und UML-Profile als Erweiterungsmechanismen von UML eine wichtige Rolle.OCL erweitert die UML und hat dabei keinerlei Seiteneffekte. Das bedeutet, dass dasUML-Modell durch die OCL nicht geändert, sondern lediglich überwacht wird. Durch
Model Development Tools (MDT)ProjektMDTBPMN2IMMMSTOCLPapyrusSBVRUML2UML2 rsion 1.1; ContainerprojektVersion 0.7; GeschäftsprozessmodellierungMetamodell-Standard für InformationsmanagementEMF-Aufsatz für SpezifikationserstellerVersion 3; 5. ReleaseVersion 0.7; Ziel Integrated Modeling EnvironmentMetamodel-Standard für Geschäftsdomäne/ -vokabularVersion 3.1; Metamodel UML-Implementierung für EMFVersion 0.9; Werkzeuge für UML-EinsatzVersion 2.6; XML-Schema-Datei-DefinitionTabelle 1: Übersicht von MDT und seiner Unterprojektediese Überwachung ist es möglich die Anforderungen an das Modell genauer festzulegen.Auch innerhalb der UML-Beschreibung taucht die OCL auf, etwa wird so festgehalten,dass Generalisierungsbeziehungen gerichtet sein müssen und nicht zyklisch sein dürfen[Ver07, S. 81]. Gronback und Merks stellen zur Rolle der OCL innerhalb des EMP fest:It’s Everywherere (time to learn it!)“ [GM08, S. 6]. Die OCL-Ausdrücke im UML-Modell”haben folgende Spezifizierungsabsichten [DM05, S. 56]: Invariante Bedingungen für Klassen und Typen Vor- und Nachbedingungen für Methoden Abfrageausdrücke Ableitungsregeln für berechenbare AttributeFestgehalten werden die OCL-Ausdrücke entweder als Kommentar [Abbildung S. 13] imUML-Modell oder rein textuell an anderer Stelle. OCL-Ausdrücke sind immer an einenKontext gebunden [Liste S. 10]. Durch die OCL wird es also möglich, das Design By”Contract“ 3 im Modell festzuhalten. Durch die Formalisierung der OCL ist es eben auchmöglich, dass die OCL-Anweisungen maschinell in Code umgesetzt bzw. ausgewertet werden können. Diese Automatisation ist für die MDD ausschlaggebend. Die OCL orientiertsich an der Syntax von Smalltalk, das heißt, dass das Gleichheitszeichen für einen Vergleichund nicht für eine Zuweisung steht! Folgende Abbildung auf S. 11 und die zugehörige Listeauf S. 10 zeigen ein UML-Basisdiagramm, eine ans Modell gestellte Anforderung und denzugehörigen OCL-Ausdruck. Bedingung: Das Alter einer Person ist nicht negativ.OCL-Constraint: context Person inv: self.Alter 03Entwurf gemäß Vertrag, festgelegt von Bertrand Meyer: durch die Festlegung von Invarianten, Vorund Nachbedingungen der interagierenden Softwarebausteinen soll ein reibungsloser Programmablaufsichergestellt werden.
Model Development Tools (MDT)Abbildung 5: UML-Basis-Diagramm zur Veranschaulichung von Constraints, nach[Ver09i] Bedingung: Eine Person ist jünger als ihre Eltern.OCL-Constraint: context Person inv: self.Eltern- forAll(e e.Alter self.Alter) Bedingung: Nur eine erwachsene Person darf ein Auto besitzen.OCL-Constraint: context Person inv: self.Alter 18 implies autos- size() 0Die OCL überwacht also, ob ein Modell eingehalten wird, die Constraints wirken dabei als Einschränkung. Jetzt möchte man vielleicht die Universalsprache UML wirklicherweitern. Hier helfen die UML-Profile. Ein Profil ist ein Stereotypisiertes Paket, das”Modellelemente der UML enthält, die für einen bestimmten Einsatzzweck angepasst werden .“ [Bal05, S. 542]. Mit der OCL und den UML-Profilen ist es dann möglich eineinterne DSL zu bilden - dabei muss man auf die Annehmlichkeiten des Arbeitens in derUniversalsprachen-Umgebung sogar nicht einmal verzichten. Neben dem Einsatzzweck einProfil für eine bestimmte Domäne zu definieren, kann man auch eines erstellen, dass dieUML auf eine bestimmte Plattform anpasst. Es ist also denkbar ein Profil Java oder EJBanzulegen [siehe Abbildung S. 13].Stereotype stehen in französischen Anführungszeichen, den Guillements, über dem Bezeichner der Klasse. Für sich genommen, weisen Stereotype erst einmal nur auf eine besondere Charakteristik des Elements hin. Ein Stereotyp muss erst definiert werden, bevor mandiesen einsetzen kann. Dies geschieht, indem man das Wort stereotype“ in Guillements”oberhalb des Element-Bezeichners notiert und als Element-Bezeichner den Namen deszu definierenden Stereotyps schreibt. Darunter folgen die Attribute des Stereotyps. Wirddieser Stereotyp-Bezeichner dann an anderer Stelle in Guillements gesetzt, ist klar, mitwelcher besonderen Charakteristik dieses Element verknüpft ist. So wendet man Stereotype dann an. Bei der ABEweb-Methode zur Entwicklung von Webapplikationen werdendie Aktivitätsdiagramme der UML zu interaktionsorientierten Aktivitätsdiagrammen erweitert. In diesen Diagrammen kommen Aktionen vor, die mit den Stereotypen SA“ oder”AA“ versehen sind. So ist klar, ob es sich um eine Akteuraktion oder eine Systemaktion”handelt und diese Unterscheidung ist später für die Transformation sehr wichtig[LS04,S. 255 ff.]. Die Abbildung auf S. 12 zeigt den eben erwähnten Einsatz der StereotypenSA und AA .Bündelt man nun ein Paket mit Stereotypen und gibt diesem Paket selbst den Stereotyp
Model Development Tools (MDT)Abbildung 6: Stereotypisiertes interaktionsorientiertes Aktivitätsdiagramm zum Anwendungsfall Buchbestellung bei einem Online-Shop“ , Abbildung aus [LS04,”S. 250]
Model Development Tools (MDT)Abbildung 7: Definition eines UML-Profils, hier für EJB, Abbildung aus [Ver07, S. 188]profile“ , dann erhält man ein UML-Profil, wie bereits erwähnt, handelt es sich dabei”um ein stereotypisiertes Paket. Die Abbildung auf S. 13 zeigt die Definition eines UMLProfils. Der Paketname ist durch den Stereotyp profile“ ausgezeichnet, im Profil sind nur”Stereotypen, die ein Element der Metaebene erweitern. Zusätzlich befinden sich in denKommentaren die Randbedingungen in Form von OCL-Ausdrücken.Das Modell seines modellierten Systems kann man ebenfalls in ein Paket stecken unddieses Paket kann dann ein oder mehrere UML-Profile einbinden - so sind die in deneingebundenen Profilen definierten Stereotypen auch im Paket des modellierten Systemssichtbar. Die Abbildung auf S. 14 zeigt diese apply“-Beziehung zur Profileinbindung.”Die UML wurde so durch ein oder mehrere Profile erweitert und ist gegebenenfalls so zueiner internen DSL geworden. Die Modelle des Pakets Webshopping können nun auf alleStereotypen zugreifen, die in den Profilen Java und EJB definiert wurden.Beim Erstellen von Profilen muss einiges bedacht werden, etwa muss gesichert sein, dassdie Profile nicht mit der UML im Widerspruch stehen. Der Austausch von Modellen undProfilen kann mittels des Standards XMI erfolgen. Die OMG hat bereits einige Standardprofile geschaffen, wie man im Kapitel S. 5 ff. nachlesen kann.5 DiskussionTheoretisch gibt es einige Vorteile der MDD. Zu allererst ist ein Domänenexperte bessereinbindbar: er ist ein Fachmann im Problemfeld und findet sich daher im Umfeld einerdomänenspezifischen Sprache besser zurecht als im Umfeld einer 3-GL-Programmiersprache,die er noch nicht kennt. Dazu altert das DSL-System mit der Domäne und nicht mit dereingesetzten Technik. Darüber hinaus kann der Code automatisch erzeugt werden - es
Model Development Tools (MDT)Abbildung 8: Anwendung eines UML-Profils auf ein Modell, Abbildung aus [Ver07, S.191]werden also die Fehler verhindert, die beim Implementieren anfallen und viel Zeit kosten.Die Idee der automatischen Codegeneration gibt es schon länger - die CASE-Werkzeuge inden 90er Jahren wollten dies ebenfalls leisten. Die Abgrenzung zwischen CASE- und MDDWerkzeugen besteht nun darin, dass bei den CASE-Werkzeugen eine Vollautomatisierungdas Ziel ist: aus einer Systembeschreibung soll eine fertige Architektur erzeugt werden.Die MDD-Ansätze wollen nur einen sinnvollen Anteil an Automatisierung bereitstellen,sich dabei aber die nötige Flexibilität erhalten.Eine Trennung von fachlichen und technischen Anteilen führt zu einer höheren Abstraktion des Systems und die Komplexität wird so handhabbarer, einer der grundlegendenWünsche der Softwareentwicklung, wie in der Einleitung auf S. 1 bereits angesprochenwurde. Dazu soll durch Standardisierung eine verbesserte Interoperabilität erreicht werden[Ver09h].Die Grundvoraussetzung für die MDD, also das domänenspezifische Modell, muss voneinem Entwickler allerdings erst einmal erstellt werden können. Der Entwickler hat zuentscheiden, ob er einen Standard einsetzt, oder eine interne DSL bevorzugt, oder eineexterne DSL erzeugt. Ein erfahrener Entwickler wird den anfallenden Aufwand für die dreiVarianten einschätzen können. Fowler, der die Begriffe interne und externe DSL prägte,schätzt die Wahrscheinlichkeit für den Eintritt der theoretischen Vorteile wie folgt ein:Only time will tell if these advantages will actually be realized“ [Fow05, Conclusion].”Die Standardisierung und intensivierte Zusammenarbeit zwischen OMG und der EclipseWelt wird den Aufwand für das Erstellen der Generatoren und Tools für die domänenspezifischen Sprachen weiter minimieren und so dieses Feld für Einsteiger immer zugänglicher
Model Development Tools (MDT)machen. Dazu wird durch die Verfügbarkeit der Projekte unter dem MDT-Dach es ebenauch möglich nur die bereits bestehenden Standards isoliert einzusetzen und die bereitsvorhandenen Werkzeuge zu nutzen. Falls man von externen Anwendungen kommt, kannman über Standards wie XMI trotzdem die Modelle für die Eclipse-Welt verfügbar machen; Tools wie Papyrus sollen diese Möglichkeiten weiter optimieren und vorantreiben.Das MDT hilft also beim Umgang mit Standards und diese helfen im MDD-Prozess mittelsinterner DSLs. Darüber hinaus ist der bloße Gebrauch der Standards und dazugehörigerWerkzeuge für domänenspezifische Modelle vielleicht nicht sehr hilfreich, aber für denEntwicklungsalltag trotzdem eine enorme Erleichterung. Ebenfalls birgt es viel Potential,wenn die OMG und Eclipse-Welt deren Zusammenarbeit intensivieren, da so Standardsund zugehörige Implementierungen vielleicht schneller entstehen und ggf. Firmen sichentschließen die Ressourcen zu bündeln: Die Implementierung ist so zeitnah vorhandenund auch für die Open-Source-Welt verfügbar.
Model Development Tools (MDT)6 AbkürzungsverzeichnisBPMN Business Process Modeling Notation;CASE Computer Aided Software Engineering;CWM Common Warehouse Metamodel;DSL Domain specific language;EMF Eclipse Modeling Framework;EMOF Essential Meta Object Facility;EMP Eclipse Modeling Project;GEF Graphical Editing Framework;GMF Graphical Modeling Framework;IDE Integrated Development Environment;IMM Information Management Metamodel;MDA Model Driven Architecture;MDD Model Driven Development;MDSD Model Driven Software Development;MDT Model Development Tools;MOF Meta Object Facility;MST Metamodel Specification Tools;OCL Object Constraint Language;OMG Object Management Group;PIM Platform Independent Model;PSM Platform Specific Model;SVBR Semantics of Business Vocabulary and Business Rules;SysML Systems Modeling Language;UML Unified Modeling Language;XMI Extensible Markup Language Metadata Interchange;XSD Extensible Markup Language Schema Definition;
Model Development Tools (MDT)Literatur[BA07]Bartonitz, Michael ; Ammon, Rainer von: BPMN Relevante Standards. In:Enterprise Architecture und BPM (2007), S. 1–5. – Onlineausgabe[Bal05]Balzert, Heide: Lehrbuch der Objektmodellierung, Analyse und Entwurf mitder UML2. Muenchen : Elsevier GmbH, 2005. – 2. Auflage[DM05]Demelt, Achim ; Mitrik, Dieter: OCL in der Praxis. In: JavaSpektrum(2005), Nr. 01, S. 56–59. – Onlineausgabe[Etz06]Etzel, Marcel: Modellgetriebene Softwareentwicklung. Website, Seminararbeit, Johann Wolfgang
Die Schicht M0 ist eine Instanz der Schicht M1. Hier wird also gekl art, welche Attribute eine Buch-Instanz der Schicht M0 hat. Fur jede Schicht muss gekl art werden, wie das Modell notiert werden soll und meist wird im objektorientierten Umfeld die UML zur B
