Model Driven Architecture (MDA) Florian Betreuer: Marco Musconi Software Engeneering Project WS 2006/07 07. Februar 2007 SEPR WS 2006/07 Seite 1
Inhaltsverzeichnis Historie 3 CASE 3 Objektorientierung 3 Unified Modeling Language 4 Ergebnisse dieser historischen Entwicklung 4 Motivation 5 Grundidee 5 Definition 7 Computation Independend Model (CIM) 10 Meta Object Facility (MOF) 10 Platform Independend Model (PIM) 11 Plattform Model (PM) 11 Platform Specific Model (PSM) 11 Platform Specific Implementation (PSI) 11 Entwicklungsprozess 12 Erstellung des CIM 12 Abgrenzung des PIM 12 Tranformation in PSM 12 Deployment und Erweiterung des PSI 12 Vorgehensmodell 13 OOAnalyse 14 Plattfrommodellierung 14 Generatorerstellung 14 OODesign 14 OOProgrammierung 14 Testbetrieb 15 Fazit 15 Vorteile 15 Nachteile 15 Quellenverzeichnis 17 SEPR WS 2006/07 Seite 2
Historie In den 90er Jahre entwickelten sich diverse Zweige und unterschiedliche Ansätze zur generativen Sowftwareentwicklung. Ein herausragender Ansatz stellt die Computer-Aided-Software Engeneering-Methode (CASE) dar, mit der Software in Gänze aus einem Modell heraus generiert wird. Weiterhin hielten die 4th-Generation-Languages (4GL) gemeinsam mit der Objektorientierung Einzug in die Software-Entwicklung. Diese Veränderungen und die neuen Konzepte der Hochsprachen bedingten allerdings, dass der Prozess der Software-Entwicklung sich verlangsamte und vor allem die erhofften Vereinfachung und Automatismen stets schwergewichtiger wurden. CASE CASE-Tools sind umfangreiche Entwicklungsumgebungen, die modellbasiert arbeiten und sehr detailliert die Strukturen des Modells auf die jeweilige Zielplattform abbilden können. Durch eine fehlende Standardisierung entstanden ausschließlich proprietäre Ansätze durch den jeweiligen Hersteller des Tools forciert. Im Umkehrschluss daraus wurden diese Ansätze teuer verkauft und gingen einher mit schlechten Erfahrungen der Entwickler. Nicht nur vor diesem Hintergrund entwickelte sich durch die OpenSource-Community getrieben ein wachsendes Beweustsein für offene Standards. Objektorientierung Der objektorientierte Ansatz und dessen Umsetzung in die Sprachen C++ und Java lösen in weiten Teilen die 3rd Generation Languages (3GL) wie C, Kobol und SEPR WS 2006/07 Seite 3
Pascal ab. Java legt durch seine Struktur den Grundstein für eine umfangreiche Komponententechnologie, welche später in Bibliotheken für C++ oder Softwarearchitekturen wie J2EE mündeten. Durch die zunehmende Unübersichtlichkeit der im Umfang weiter steigenden Projekte stellt sich die Frage nach einer Modellierungssprache. Unified Modeling Language Die Unified Modeling Language (UML) wurde als grafische Notationsform von statischen und dynamischen Abläufen in Systemen oder innerhalb einer Software von der Object Modeling Group (OMG) entwickelt und standardisiert. Das eherne Ziel in Verbindung mit dem CASE-Ansatz war das Round-Trip -Engineering, bei dem Code aus einem Modell generiert wird und alle manuellen Änderungen am Code zurück in das Modell fließen sollen. Bei genauerer Betrachtung der Nutzung von UML blieb im Laufe der Zeit eher eine grafische Dokumentation der Systeme als eine Abstraktion übrig. Ergebnisse dieser historischen Entwicklung Die CASE-Tools setzen sich aufgrund ihrer proprietären Ansätze und Schwergewichtigkeit nicht durch. Hingegen etabliert sich die UML und erfährt durch den Versionswechsel auf 2.0 bzw. 2.1 (aktuell) eine umfangreiche Erweiterung, welche als technische Basis für die folgende Darstellung der Modell getriebenen Software Entwicklung dient. UML-Tools beinhalten Teile des CASE-Gedanken in der Art, dass sie sowohl Code generieren können, als auch teilweise Reverse-Engeneering beherrschen. Sie sind zum Teil von Entwicklungsumgebungen geworden und lassen die Grenzen zwischen diesen Technologien bzw. Code und Modell verschwimmen. SEPR WS 2006/07 Seite 4
Schließlich hat sich die objektorientierte Programmierung durchgesetzt, selbst Scriptsprachen beherrschen heute Objektorientierung; allerdings wird Software nach wie vor manuell programmiert und die Kompetenz der Entwickler ist ein deutlicher Indikator für die Qualität der Software. Übrig bleibt, dass es nach wie vor an Konzepten fehlt, diese historische Entwicklung auszuwerten und einen Nutzen daraus ziehen. Die UML-Tools oder Entwicklungsumgebungen haben deutliche Ähnlichkeit mit den alten CASE-Tools, sind wenig flexibel und vor allem lassen sich Designänderungen schlecht adaptieren. Motivation Jede Software besitzt durch die Nutzung Ihrer Sprachelemente und Bibliotheken eine innere Struktur. Diese Struktur hat Einfluss auf die Qualität und Performance; gleichzeitig lässt das abstrakte Niveau der Sprachen die Konstruktionsparadigmen im Hintergrund verschwimmen. Letztendlich hängt so die Qualität immer vom einzelnen Entwickler ab. Diesem Konsistenzproblem wird mit Reviews entgegengewirkt. Schwergewichtige Modellierungen dienen als Dokumentation und tragen ebenso wie Reviews nicht zur Vereinfachung der Arbeitsweisen bei, sondern verlangsamen im Gegenteil den Arbeitsfluss und minimieren die Flexibilität. Nicht selten sind diese Prozesse sind unter Zeitdruck häufig die ersten Opfer und lassen damit gute Qualität der Software vermissen. Grundidee Modelle sind abstrakt und formal zugleich und enthalten eine exakte Bedeutung der gegebenen Problems und des Programmcodes. Durch das Verschwimmen der SEPR WS 2006/07 Seite 5
Modelle mit der Software werden die Modelle zu einem Bestandteil der Software selbst. Für jeden Problembereich benötigt man eine Vogelperspektive, eine dem Problemraum angepasste Modellierungssprache. Diese wird im allgemeinen als Domain Specific Language (DSL) bezeichnet. Erweitert um vorgefertigte und wiederverwendbare Komponenten stellt diese Kombination eine mächtige Basis im Verhältnis zu normalen Programmiersprachen oder technischen Plattformen dar. Die Modelle nutzen ohne spezielles Hintergrundwissen der Entwickler die effizientesten Frameworks oder Bibliotheken. Code der Applikation Transformation Applikations- Modell DSL analysieren trennen Individueller Code Schematisch sich wiederholender Code Generischer Code Schematisch sich wiederholender Code Individueller Code Plattfrom benutzt erstellt 1. Trennung von Code und Modell In der obigen Grafik wird die Struktur einer klassischen Applikation aufgezeigt. Die Struktur lässt sich bsw. durch Refactoring in drei Teile umstrukturieren. Einen generischen Anteil, der für alle zukünftigen Anwendungen identisch ist und einen schematischen Teil, der nicht für alle Anwendungen gleich ist, jedoch zum Beispiel auf den SEPR WS 2006/07 Seite 6
gleichen Entwurfsmustern basiert. Einen letzten Teil stellt der individuelle Code dar, der für jede Applikation einzigartig ist. Der Analyse folgt eine Trennung des Appliaktionsmodells von dem Code. Das Modell wird durch eine DSL eindeutig beschrieben und ermöglicht so über die Definition eines geeigneten Transformators eine Generierung von großen Teilen des Codes (den schematischen und generischen Teil zusammengefasst zum generierten Code) - allerdings nicht des gesamten Codes, was einen deutlichen Unterschied zur CASE-Methode darstellt. Es soll nur der Code generiert werden, der auch sinnvoll ist. Der individuelle Code vervollständigt die Applikation, bleibt erhalten und muss nicht nach jedem Generierungsprozess neu erstellt oder eingesetzt werden. Schlussendlich wird der Code auf der Plattform deployed, welche bereits durch den Transormationsprozess ihr Anforderungen und Randbedingungen in den generierten Code einfließen lassen konnte. Jedwede Änderung am Modell kann so über einen oder mehrere Transformationsprozesse direkt in Code bzw. in die Software umgesetzt werden. Zudem besteht eine gewisse Plattformunabhängigkeit. Definition Die Modell getriebene Softwareentwicklung - Model Driven Software Development (MDSD) ist ein Vorgehensmodell, welches sich am oben genannten Ansatz orientiert. Die Model Driven Architecture (MDA) ist eine Abwandlung bzw. Standardisierungsinitiative der Object Modeling Group (OMG). Als Modellierungssprache legt die OMG in der MDA UML fest, wohingegen MDSD schlicht auf eine geeignete Modellierungssprache verweist. Weiterhin gibt es Unterschiede in der Motivation zwischen MDA und MDSD, welche hier nicht weiter betrachtet werden sollen. SEPR WS 2006/07 Seite 7
Die OMG ist eine Organisation mit über 800 Mitgliedern, welche bereits die Standards XMI, SysML, CWM, CORBA definiert hat. Seit Ende 2000 kommuniziert OMG den Standard MDA. 2. Darstellung der MDA aus Sicht der OMG Basierend auf den etablierten Standards der OMG, trennt MDA die Business- und die Applikationslogik von der darunter liegenden Plattform. Plattformunabhängige Modelle einer Appliaktion oder die Business-Modelle integrierter Systeme in UML o- der den anderen Modellierungssprachen der OMG können virtuell (transformiert) auf jeder Plattform (bspw. CORBA,.NET oder J2EE) realisiert werden. Die plattformunabhängigen Modelle dokumentieren die Business-Funktionalität und das Verhalten des Systems unabhängig von der Technologie, mit der die Implementierung stattfindet. Beide Bereiche, Technologie (Plattform) und Modell können sich nun entwickeln und sind getrennt voneinander änderbar; sie fließen über die Transformation wieder ineinander. Dies bedeutet zusätzlichen Arbeitsaufwand, je- SEPR WS 2006/07 Seite 8
doch ist dieser Prozess im Laufe eines Projektes automatisiert daher weitestgehend vernachlässigbar. Um den Gedanken der Modellierung zu verfeinern definiert die OMG ein Schichtenmodell. Unten ist dieses Modell schematisch dargestellt und soll einen Einblick in die unterschiedlichen Transformationen-Varianten geben. describes instanceof M3: Meta-Metamodell Typ: Classifier Name: Classifier describes instanceof M2: Metamodell Typ: Classifier Name: Klasse Features: Attributes, Operations, Associations describes describes M1: Model instanceof instanceof Typ: Klasse Name: Person Attribute: FirstName, LastName Operations:... Associations:... M0: Instances Typ: Person FirstName: John LastName: Doe 3. Schichtenmodell Das Schichtenmodell ist ein Grundgedanke hinter der modellgetriebenen Software. DIe einzelnen Schichten beschreiben von oben nach unten gesehen jeweils das Modell der nächsten Schicht. In umgekehrter Sichtweise ist jede Schicht eine Instanz der jeweils darüber liegenden. SEPR WS 2006/07 Seite 9
In dem oben gezeigten Diagramm ist John Doe (M0) eine Instanz der Klasse Person (Code - M1). Die Klasse Person ist wiederum eine Instanz des Classifiers vom Typ Klasse (Metamodell - M2). Der Classifier ist eine Instanz des Classiefiers Classifier (Metametamodell - M3); auf dieser Ebene ergibt sich logisch, dass die Abstraktion weiter fortgesetzt werden kann, daher die jeweiligen Ring-Verweise auf Metaebene M3. Von der anderen Richtung betrachtet, ergibt sich, dass das Metametamodell M3 (MOF) das Metamodel M2 (UML-Klassendiagramm) beschreibt, welches wiederum die Klasse im Code beschreibt. Zuletzt beschreibt die Code-Klasse das Verhalten der Person John Doe. Die Übergänge zwischen den Ebenen oder innerhalb einer Ebene lassen sich durch Transformationen beschrieben. Diese Transformationen finden in Abhängigkeit von der Ebene sowohl von Modell zu Modell, als auch von Modell zu Code statt. Folgende unterschiedlichen Modelle werden in der MDA definiert: Computation Independend Model (CIM) Das CIM stellt das Businessmodell der Anwendung dar. Es ist abstrakt und unabhängig von Hardware und Software. Der Nutzen dieses Modells liegt im Verständnis der Funktionalität. Meta Object Facility (MOF) Als MOF bezeichnet die OMG den Kern der UML. Sie stellt die Modellierungsdefinition der UML dar, beschreibt im weiteren Sinne eine abstrakte Sprache und ein Framework zur Verwaltung von plattformunabhängigen Metamodellen. SEPR WS 2006/07 Seite 10
Platform Independend Model (PIM) Das gleicht in Teilen dem CIM und nutzt es als Grundlage, genügt allerdings formalen Spezifikationen, die eine Transformation zulassen. Hierzu wird eine formale Modellierungssprache wie UML verwendet, die an den Problemraum angepasst ist (bsw. durch UML2-Profile). Plattform Model (PM) Ein Plattformmodell definiert die technischen Konzepte und Elemente einer bestimmten Plattform. Weiter stellt es die Elemente, die für die Modellierung eines plattformspezifischen Systems benötigt werden, zur Verfügung. Platform Specific Model (PSM) Nach Transformation des PIM entsteht unter Einfluss des PM das PSM. Das PSM enthält alle spezifischen Konzepte der Zielplattform. Mit weiteren Transformationen auf der Basis ein oder mehrerer PSM wird dann für die konkrete Plattform die Implementierung erzeugt. Wichtig ist, dass PIM und PSM relative Konzepte sind - relativ zur Plattform. Beispielsweise ist ein PSM in EJB spezifisch für eine EJB-2.0 Plattform, aber unabhängig bezüglich der konkreten, Applikationsserver-spezifischen Umsetzung. Platform Specific Implementation (PSI) Das PSI ist die Implementierung der aus dem Transformationsprozess entstandenen PSM auf der Zielplattform. Die PSM-Modelle kann um den individuellen Code der Applikation erweitert werden. SEPR WS 2006/07 Seite 11
Entwicklungsprozess Erstellung des CIM Das CIM basiert auf einer Anforderungsanalyse. Der Analyse folgt eine Entscheidung für eine Fachdomäne, die Struktur und das Verhalten der Software werden festgelegt. Mit diesen Definitionen entsteht durch Modellierung in UML oder einer anderen Sprache das CIM. Abgrenzung des PIM Das PIM nutzt das unspezifische CIM als Grundlage. Aufbauend auf eine abstrakte Form des Modells werden Teile abgegrenzt und verfeinert (durch Profile bzw. Stereotypen), bis sie den Spezifikationen der Transformation genügen. Diese Teile werden in ein oder mehrere PSM transformiert, wobei die Plattform durch die jeweilige Fachdomäne Einfluss nimmt. (Bspw. durch eine bestimmt Komponententechnologie). Tranformation in PSM Das PSM ist ein durch die Transformation geprägtes Modell. On die Transformation auf einer hohen Abstraktionsebene geschehen ist, oder einer niederen ist dabei nicht entscheidend. Das PSM gilt für die jeweils niedrigere Ebene wieder als PIM und kann so weiter in Richtung PSI transformiert werden. Deployment und Erweiterung des PSI Nach der letzten Transformationsstufe kann das Deployment erfolgen und das System durch individuellen Code vervollständigt werden. Der individuelle Code wird von den Generatoren geschützt, da ein erneuter Generierungsprozess nicht den in- SEPR WS 2006/07 Seite 12
dividuellen Code überschreiben soll. Anschließend folgt ein klassischer Entwicklungsfortgang. Diese Modelle bauen so aufeinander auf, dass jederzeit eine Änderung der Spezifikation oder der Anforderung ohne Verlust über die einzelnen Transformationen in die Ziel-Applikation transformiert werden kann. Vorgehensmodell Angelehnt an den IBM Rational Unified Process (RUP) wird im folgenden ein Vorgehensmodell beschrieben. Der RUP ist kein Wasserfall-Modell, sondern gibt eine klare Vorgabe der Entwicklungsphasen. Diese Phasen sind beliebig oft wiederholbar. OOA Plattform- Modellierung Generator- Erstellung OOD OOP Testbetrieb 5. Entwicklungsprozess nach RUP SEPR WS 2006/07 Seite 13
OOAnalyse Das CIM wird auf Basis der Anforderungsanalyse erstellt. Dies beinhaltet die Systemidee, Fachklassen und Use-Cases. Aus dem CIM lassen sich ein oder mehrere PIM ableiten. Diese verfeinern die Geschäftsprozesse und die Use-Cases. Plattfrommodellierung Bei der Plattformmodellierung wird die Zielarchitektur beschrieben und darauf aufbauend ein UML-Profil erstellt. Ebenso beinhaltet die Modellierung eine klare Definition der jeweilig zu verwendenden Zielplattform. Generatorerstellung Diese Phase definiert den Projekt-Setup. Es werden die Transformationsprozesse konfiguratiert (bsw. in Form von Cartridges für AndroMDA). Außerdem werden das Build und Deployment vorbereitet und festgelegt. OODesign Das zu transformierende PIM wird markiert und unter dem Einfluss des PM in die PSM bzw, PSI transformiert. OOProgrammierung Während dieser Phase wird das PSI durch individuellen Code ergänzt. Es folgt eine Überprüfung des PSI. SEPR WS 2006/07 Seite 14
Testbetrieb Im Testbetrieb werden Build und Deployment überprüft und eine Benutzung der Software durch Tester überwacht. Diese einzelnen Prozesse können sich dem Schema des Diagramms nach beliebig oft wiederholen, wie in der obigen Grafik gezeigt. Die Wiederholungen dienen zur Verfeinerung der Modelle und arbeiten auf eine Fertigstellung der Software hin. Es ist trotz dieser festen Phasen jederzeit eine Änderung im Modell möglich, eine Designänderung oder eine Anforderungsänderung kann so direkt entsprochen werden. Fazit Vorteile Die MDA ermöglicht durch das starke Verschmelzen der Modelle mit der Software eine schnelle Reaktion auf Anforderungsänderungen. Änderungen werden über die einzelnen Transformationen von Modell zum Code transportiert, ohne den individuellen Code zu überschreiben. Weiterhin gewährleistet die automatische Generierung von Code eine Verlässlichkeit innerhalb der Programmierung, die über einer rein individuellen liegt. Die Software ist wesentlich weniger fehleranfällig und wartungsärmer. Nachteile Bislang stecken die Tools noch in den Kinderschuhen. Eine Akzeptanz seitens der Software-Entwickler ist nur bedingt gegeben, da zwar ein Standard existiert, aber ein SEPR WS 2006/07 Seite 15
hoher Initialaufwand und die Herstellerabhängigkeit wesentlich mehr ins Gewicht fallen. Fehlende Vorgaben für Entwicklungsprozesse und ein stetes Neu-Generieren von dem jeweiligen Applikations-Code bzw. das Abarbeiten aller Transformationen erschwert bei Änderungen ein ursprünglich angestrebte Einfachheit der Wartung. Es bleibt, einen weiteren Punkt zu diskutieren: die Entfremdung der Entwickler vom Code. Einerseits ermöglicht die Entfremdung den Unternehmen ein billiges Arbeiten ohne spezielle Fachkräfte, auf der anderen Seite blockiert die Abstraktion die Entwickler vor der individuellen Anpassung des Programmcodes, selbst wenn gute Kenntnisse der Zielplattform vorhanden sind. SEPR WS 2006/07 Seite 16
Quellenverzeichnis Virtuelles Software Engeneering Kompetenzzentrum. Model Driven Architecture, http://www.software-kompetenz.de/?27111 Wikipedia. Model Driven Architecture, http://de.wikipedia.org/wiki/model_driven_architecture Wikipedia. Modellgetriebene Softwareentwicklung, http://de.wikipedia.org/wiki/modellgetriebene_softwareentwicklung Stahl, Völter. Modellgetriebene Softwareentwicklung, Techniken, Engeneering, Management, dpunkt.verlag. 2005 Petrasch, Meimberg. Model Driven Architecture Eine praxisorientierte Einführung in die MDA, dpunkt.verlag. 2006 SEPR WS 2006/07 Seite 17