Modellgetriebene Softwareentwicklung

Softwaretechnik Projekt Referat Modellgetriebene Softwareentwicklung Marcus Mews

Marcus Mews 18. Januar 2008 Technische Universität Berlin Fachbereich Informatik Softwaretechnik Projekt

INHALTSVERZEICHNIS 1 Einführung...4 1.1 Rückblick...4 1.2 Ausblick...4 2 Modelle... 6 2.1 Das Modell... 6 2.2 Das Metamodell...7 2.3 Unterscheidungen...8 2.3.1 Das ontologische Metamodell... 8 2.3.2 Das linguistische Metamodell...8 2.4 Meta-Ebenen und Abstraktion...9 3 Verfeinerung in UML... 11 3.1 UML-Profile...11 3.2 Verfeinerung des Metamodells...13 3.3 Verfeinerung des Modells... 13 4 Transformationen... 14 4.1 Modell zu Modell... 14 4.2 Modell zum Modell eines anderen Metamodells... 15 4.3 Modell zu Quelltext...16 4.3.1 Quelltextgenerierung... 16 4.3.1.1 Templates...16 4.3.1.2 API-basierte Generatoren...17 4.3.2 Generierter Code / nicht generierter Code...17 4.3.3 Integration von generiertem und nicht generiertem Code... 18 4.4 Richtlinien... 19 4.4.1 Alles in einem Rutsch...19 4.4.2 Generiere gut aussehenden Quelltext... 19 5 MDSD Konzept...21 5.1 Terminologie... 21 5.1.1 Domäne...21 5.1.2 Metamodell...21 5.1.3 Formale Modelle...22 5.1.4 Transformation... 22 5.2 Ziele und Potentiale...22 5.3 Genereller Ansatz... 23 6 Fazit...25 7 Quellen... 26 3

1 Einführung 1 Einführung Dieses Referat soll einen Überblick über wichtige Aspekte der modellgetriebenen Softwareentwicklung (MDSD; engl. Modell Driven Software Developement) geben und einige Gesichtspunkte näher erläutern. Als Hauptreferenz wurde Modellgetriebene Softwareentwicklung von Thomas Stahl und Markus Völter herangezogen. Falls nicht explizit hervorgehoben, so beziehen sich die Ausführungen auf MDSD und nicht auf die Modellgetriebene Architektur (MDA; engl. Model Driven Architecture), wie sie durch die Object Management Group (OMG) propagiert wird. In vielen Fällen ist eine solche Unterscheidung jedoch überflüssig, da die MDA als Spezialisierung der MDSD verstanden werden kann. 1.1 Rückblick In den 90er Jahren entwickelten sich mehrere Paradigmen der Softwareentwicklung, aus denen drei ganz besonders hervortraten: Beherrschten zu Beginn jenen Jahrzehnts noch Computer Aided Softwareengineering (CASE) und Sprachen der vierten Generation (4GLs) die Bildfläche, so kamen gegen Ende der 90er Jahre objektorientierte Paradigmen hinzu. CASE-Methoden und die notwendigen Werkzeuge waren meist proprietär und standen daher im Widerspruch zu offenen Standards. Schlechte Erfahrungen der Unternehmen mit den oftmals teuren Werkzeugen waren die Folge und wurden durch mangelnde Interoperabilität verschärft. Zwar konnten objektorientierte Sprachen nicht alle Wünsche erfüllen, sie lösten jedoch die vorangegangenen Programmiersprachen ab und legten den Grundstein für die Komponententechnologie. In Verbindung mit UML-Werkzeugen ist es zwar möglich, zwischen Modellen und korrespondierendem Quelltext zu wechseln, jedoch blieben UML-Modelle immer nur (grafische) Dokumentation. 1.2 Ausblick Obwohl sich viele UML-Werkzeuge signifikant verbessert haben und intelligente Wizards zur Erstellung von Benutzeroberflächen, Anwendung von Entwicklungsmustern und über Codeskelettgenerierung verfügen, sind sie weiterhin nicht in der Lage, Änderungen am Designmuster automatisch und iterativ auf den Quelltext der gesamten Anwendung zu übertragen. Bei MDA und MDSD werden wesentliche Teile des Quelltextes und nicht nur Codeskelette aus den Modellen generiert. Die hier genutzten Modelle müssen dementsprechend exakt und ausdrucksstark sein um Applikationen mitsamt ihrer Funktionalität so gut wie möglich beschreiben zu können. Aus diesem Grund kann keine allgemeine und für alle Bereiche passende Modellierungssprache verwendet werden, da sie entweder einen übermäßigen Umfang hätte oder zu ungenau und abstrakt wäre. Folglich setzt MDA / MDSD immer eine zu entwickelnde Domänensprache voraus, die auf das zu lösende Problem angepasst ist. Wird die Applikation in all ihren Funktionen mithilfe der Domänensprache genau beschrieben, ist durch entsprechende (zu implementierende) Generatoren eine Transformation in ausführbaren Code möglich. Je nachdem, wie detailliert die Domänensprache ist, kann zwischen 50-80 Prozent des Quelltextes automatisch generiert werden. In stark spezialisierter Software und bei Unikaten kann ein Entwicklungsansatz nach MDA/MDSD auch nicht sinnvoll sein. Sind hingegen Softwarefamilien bzw. -produktlinien 4

1.2 Ausblick das Entwicklungsziel, so kann durch modellgetriebene Softwareentwicklung eine signifikante Einsparung an Ressourcen erreicht werden. Die Vorteile von MDA sind also größere Entwicklungseffizienz bessere Integration von Fachexperten bessere Änderbarkeit der Software leichtere Umsetzung der Softwarearchitektur Möglichkeit der Portierung auf andere Plattformen Natürlich ist das Übersetzen von abstrakten Spezifikationen in weniger abstrakten, ausführbaren Code nichts neues. Bei modellgetriebener Softwareentwicklung wird hingegen nicht nur übersetzbarer Quelltext erzeugt, sondern auch zugehörige Modelle und Infrastrukturen, mit deren Hilfe der Quelltext erst übersetzt bzw. transformiert werden kann. 5

2 Modelle 2 Modelle 2.1 Das Modell Abbildung 1: Haus 1 Dies ist ganz klar ein Haus. Im Zusammenhang der modellgetriebenen Softwareentwicklung soll die Abbildung jedoch zuallererst als Modell eines Hauses verstanden werden. Hier steht als die Idee Haus im Vordergrund; der pure Gedanke: Haus. Abbildung 2: Haus 2 Das neue Bild zeigt auch ein Haus. Dieses ist präziser modelliert. Präziser modelliert heißt nicht, dass es sich in seiner Art vom Haus 1 unterscheidet, sondern nur, dass all seine Attribute, die Haus 1 nicht vorgegeben hat, nun festgelegt werden. Attribute eines Hauses könnten die Anzahl der Fenster und Türen sein. Die Anschrift ist ein weiteres Attribut. Abbildung 3: Haus 3 Die Pläne wurden in die Tat umgesetzt und das Haus tatsächlich gebaut. Haus 3 ist die Analogie zur Instanz einer Klasse. Die zugehörige Klasse soll das zweite Haus darstellen. Das erste Haus hingegen ist das Modell vom zweiten Haus und demnach das Metamodell zum letzten Haus. 6

2.1 Das Modell Modelle repräsentieren Strukturen, Funktionen oder Verhaltensweisen auf abstrakte Weise. In der Regel werden MDA-Modelle in UML definiert. Abbildung 4: Die vier Metaschichten der OMG Da der Begriff meta immer relativ zu einem Modell zu betrachten ist und sich daher eine absolute Definition von Metamodell erübrigt, hat die OMG vier Metaschichten definiert. Insbesondere die zwei unteren Schichten M0 und M1 sind für Softwareentwickler gewohntes Terrain: In M1, dem Modell, wird eine Klasse mitsamt Attributen und Methoden definiert, die dann üblicherweise zur Laufzeit in M0 instanziiert und mit speziellen Werten versehen wird. Selbstverständlich können mehrere Instanzen erzeugt werden, deren Attribute sich auch unterscheiden können. 2.2 Das Metamodell Ebene M2 das Metamodell definiert die Konstrukte, die in M1 Verwendung finden. Somit sind die in M1 verwendeten Klassen Instanzen aus der M2-Metamodell Ebene. Die oberste Ebene M3 das Meta-Metamodell definiert einerseits die M2-Metamodell-Ebene und andererseits auch sich selbst. Daher existieren oberhalb von M3 keine weiteren Ebenen. Laut OMG werden die Instanzen in M2 auf Basis der Meta Object Facility (MOF) definiert. Diese MOF ist prinzipiell unabhängig von UML und ermöglicht so Metamodellierungen die nicht auf UML basieren. Selbst nicht OO-Modellierungssprachen sollen durch MOF unterstützt werden. Dennoch basiert MOF auf dem Klassenkern der UML und verwendet sowohl gleiche Konzepte als auch gleiche Syntax wie die UML. 7

2.2 Das Metamodell Das Metamodell ist ein Modell des Modells. Dementsprechend ist das erste Haus das Metamodell zum dritten Haus. Werden nur die Modellierungsebenen M1 und M2 betrachtet, so kann das Modellhaus (Haus 2) natürlich auch lediglich als Instanz und das Metamodellhaus (Haus 1) als Modell betrachtet werden. Wichtig ist, dass nicht nur die einzelnen Komponenten, die auf der nächsten, darunter liegenden Ebene betrachtet werden, modelliert werden, sondern alle Verknüpfungsarten. Das heißt, dass insbesondere Konstrukte wie Vererbung und Referenzierung auf einer Modellebene definiert werden müssen, damit sie von den Instanzen genutzt werden können. 2.3 Unterscheidungen 2.3.1 Das ontologische Metamodell Ontologische Modelle entstehen durch mehrstufige Klassifizierung. Allerdings sind Klasse- Modell-Beziehungen nicht immer nur über mehrere Abstraktionsebenen hinweg gültig. Abbildung 5: Ontologisches Metamodell Am folgenden Beispiel (Abbildung 5) soll illustriert werden, dass zwar Stadt eine Instanz der Klasse Knoten und Zürich eine Instanz der Klasse Stadt ist, aber Zürich keine Instanz der Klasse Knoten ist. 2.3.2 Das linguistische Metamodell Ein Modell einer Modellierungstechnik oder -sprache heißt linguistisches Metamodell der betreffenden Technik oder Sprache. Jedoch wird die Präzisierung linguistisch oft weggelassen. Daher bedeutet Metamodell ohne Zusätze in der Regel linguistisches Metamodell. 8 Abbildung 6: Linguistisches Metamodell

2.3 Unterscheidungen Linguistische Metamodelle modellieren die verwendeten Modellierungskonstrukte. Daher können im Modellbereich einerseits nur durch das Metamodell zur Verfügung gestellte Konstrukte genutzt und diese andererseits aber auch nur durch modellierte Verknüpfungstechniken miteinander in Verbindung gebracht werden. So müssen im Metamodell nicht nur Metaklassen erstellt werden, sondern auch Techniken wie Vererbung und Referenzierung. 2.4 Meta-Ebenen und Abstraktion PIM' PIM Mapping Refactoring PSM-1 PSM-1' bezieht sich auf Plattform -1 Abbildung 7: Zusammenhang von PIM, PSM und Plattform Im Sinne der MDA ist die Trennung von plattformabhängigen (PSM) und plattformunabhängigen (PIM) Modellen ein Schlüsselkonzept der OMG. Ausgehend von der Tatsache, dass Konzepte stabiler als Technologien sind, kann ein PIM unabhängig von der aktuellen Technologie und Plattform entwickelt werden. Mithilfe von speziellen Transformationen für eine Zielplattform kann aus dem PIM ein PSM erstellt werden. Die Rücktransformation aus nicht generiertem Quelltext ist allerdings nur schwer automatisierbar, da an dieser Stelle intellektuelle Arbeit in Form eines Refaktorings notwendig ist. In Verbindung mit verschiedenen Zielplattformen und entsprechenden Transformationen können mehrere PSM parallel existieren. Modelle können trotz verschiedener Abstraktionsgrade auf ein und derselben Metaebene liegen. Hier liefern Transformationen zwar ein spezielleres Modell, dieses befindet sich aber immer noch auf der gleichen Abstraktionsebene. 9

2.4 Meta-Ebenen und Abstraktion M3 MOF <<instanceof>> PIM- Metam odell PSM- Metam odell M2 PIM <<instanceof>> Transformation PSM <<instanceof>> M1 Abbildung 8: Abstrakt vs. Meta Im Rahmen des Beispiels könnten verschiedene Plattformen beispielsweise verschiedene Architekturstile bedeuten; so ließe sich ein und dasselbe Einfamilienhaus sowohl auf der Bauhaus- Plattform als auch auf der Jugendstil-Plattform realisieren. Die speziellen Ausprägungen weichen voneinander ab, aber das Modell wird dennoch seiner Spezifikation entsprechend umgesetzt. Ob und inwieweit eine plattformspezifische Modellierung bereits auf höherer Ebene notwendig oder angebracht ist, muss von Projekt zu Projekt entschieden werden. Um von technischen Gegebenheiten möglichst unabhängig zu sein, empfiehlt sich jedoch weitestgehend mit plattformunabhängigen Modellen zu arbeiten. Im Rahmen des Beispiels sollte demzufolge erst bei der Quelltextgenerierung entschieden werden, in welchem Stil das Haus erzeugt wird, und nicht indem bspw. auf der Modellebene ein plattformspezifisches Modell eines Stils genutzt wird. 10

3 Verfeinerung in UML 3 Verfeinerung in UML Das bisher betrachtete Modell ist noch sehr einfach und wird nun weiter verfeinert, um daran die Möglichkeiten der Modellierung aufzuzeigen. Zunächst soll das Metamodell weiter ausgearbeitet werden. Ein Haus besteht üblicherweise aus einem Dach, mehreren Räumen sowie Fenstern. Diese Verfeinerungen sollen gleich in UML dargestellt werden. Um das Beispiel übersichtlich zu halten, wird das Haus lediglich in drei weitere Bestandteile zerlegt. Abbildung 9: Metahaus Da das Modell auf dem Metamodell aufbaut, muss zuerst das Metamodell betrachtet und modelliert werden. Um eine passende M2 Sprache für die Modellierung des Metamodells zu definieren und dann später im Softwareentwicklungsprozess nutzen zu können, ist es wenig sinnvoll, die M2 Sprache komplett neu zu entwerfen. Vielmehr werden ausgehend vom UML-Metamodell passende Erweiterungen erstellt. Es gibt drei Möglichkeiten, diese Erweiterungen umzusetzen: Erweiterungen auf Basis des existierenden Metamodells der UML Erweiterungen mittels Stereotypen (mithilfe von UML 1.x) Erweiterungen mittels Profilen (mithilfe von UML2) Im Folgenden wird die Modellierung mittels Profilen genauer betrachtet und das Metamodell modelliert. 3.1 UML-Profile UML-Diagramme sind nur in Kombination mit einer Modellierungssprache MDA-Modelle. Die Modellierungssprache ist typischer Weise durch ein UML-Profil und daran angeknüpfte 11

3.1 UML-Profile Transformationsvorschriften gegeben. Hierdurch ist die Bedeutung der UML-Modelle formalisiert und ihre Abbildung auf eine gegebene Plattform eindeutig definiert. Das so entstandene Metamodell ist eine Instanz des ursprünglichen UML-Metamodells. UML-Profile können den Sprachumfang der UML durch leichtgewichte Konstrukte erweitern. Diese Konstrukte ermöglichen nicht nur eine Erweiterung sondern auch eine Einschränkung des Metamodells der UML. So können individuelle Anforderungen und Besonderheiten des Problems berücksichtigt werden. Darüber hinaus existieren bereits Standardprofile, auf die auch gegebenenfalls zurückgegriffen werden kann: UML Profil für Corba / Corba Component Modell (CCM) UML Profil für Enterprise Application Integration (EAI) UML Profil für Enterprise Distributed Object Computing (EDOC) UML Testing Profile UML Profile for Schedulability, Performance, and Time spezielle Typen von Systemen (eingebettete oder Hardwaresysteme) spezielle Techniken und Implementierungssprachen (C++, Java) spezielle Methoden und Vorgehensmodelle (RUP, V-Modell). Jedes UML-Profil verwendet immer ein Referenzmodell, das typischer Weise das UML- Metamodell ist. Andernfalls kann auch ein bereits bestehendes UML-Profil durch ein weiteres erweitert werden. Jedoch können auf diese Weise keine bestehenden Definitionen verändert oder entfernt werden. Allerdings ist durch Constraints eine Reduzierung der sprachlichen Möglichkeiten möglich. UML Profile bestehen prinzipiell aus drei Kategorien: Stereotypen (Spezialisierung von UML::Class) Tagged Values (Eigenschaften von Stereotypen) Constraints (Modellierungsregeln) Durch Contraints formulierte Bedingungen gelten sowohl für den Stereotypen als auch für die aus Stereotypen abgeleiteten Klassen des Modells. Zur Definition von Contraints wird die Object Contraint Language (OCL) verwendet. Contraints lassen sich sowohl auf Metamodellebene (M1) als auch auf Modellebene (M2) verwenden. Abbildung 10 stellt eine Erweiterung der UML grafisch dar. UML::Class <<instanceof>> MOF::Classifier generalizes MyMetaClass <<instanceof>> Abbildung 10: Metamodell Erweiterung in Bezug zur MOF 12

3.2 Verfeinerung des Metamodells 3.2 Verfeinerung des Metamodells Wie zu Beginn dieses Kapitels erwähnt, kann ein Haus in weitere Komponenten untergliedert werden. Da jedes Haus auf diese Art strukturiert werden kann, ist es sinnvoll, dass Metamodell dementsprechend auszuformulieren, sodass es dem Entwickler weitere Sprachkonstrukte auf Modellebene zur Verfügung stellt. Abbildung 11 zeigt wie sich das Haus aus Dach und Räumen zusammensetzt. Jeder Raum, so das Modell, kann auch über Fenster verfügen. 3.3 Verfeinerung des Modells Abbildung 11: Metamodell des Hauses Das Modell kann wie gewohnt mithilfe der UML dargestellt werden. An dieser Stelle kann auf die im Metamodell definierten Konstrukte zurückgegriffen werden. Dort formulierte Einschränkungen würden im Modell automatisch übernommen. Zudem kann die Konformität und Wohlgeformtheit des Modells durch automatische Modellvalidierung sichergestellt werden. Abbildung 12: Modell in Bezug zum Metamodell 13

4 Transformationen 4 Transformationen Ziel der MDA ist es, über Modelltransformationen also generativ den Prozess der Softwareentwicklung über alle Abstraktionsschichten abzubilden. Auf diese Art müssen lediglich alle benötigten Transformationen geschrieben werden um eine Vielzahl von Softwareprodukten herstellen zu können. Neben der Codegenerierung, auf die im Folgenden genauer eingegangen wird, sind Modelltransformationen eine der wichtigsten Technologien der MDA. 4.1 Modell zu Modell Auf Grundlage ein und desselben Metamodells können verschiedene Modelle definiert werden, die das gleiche Ziel verfolgen. In solchen Fällen ist es möglich, ein Modell in ein anderes zu transformieren. Dies geschieht mithilfe von Queries/Views/Transformations (QVT) Sprache. Erweitern wir unser Beispiel um ein weiteres Modell, das auf dem gleichen Metamodell beruht. Im neuen Modell ist das gleiche Haus wie im alten dargestellt. Jedoch unterscheidet sich die innere Struktur der Modelle voneinander: Während im neuen Modell alle Räume und das Dach direkt vom Haus referenziert werden, gibt die Referenzierungsstruktur beim alten Haus Auskunft über den Aufbau des Hauses. Nichtsdestotrotz können die Modelle mit einer definierten Transformationsvorschrift ineinander überführt werden. 14

4.2 Modell zum Modell eines anderen Metamodells 4.2 Modell zum Modell eines anderen Metamodells Wenn sich die Metamodelle unterscheiden, kann unter Umständen eine Transformation zwischen zwei Modellen durchgeführt werden; dies hängt insbesondere davon ab, inwieweit sich gleiche Prinzipien von einem Metamodell in ein anderes überführen lassen. Abbildung 13: Metahausmodell nach Baukastenprinzip Hier wird ein neues Metamodell genutzt, dass auf der Idee eines Baukastensystems beruht. Einzelne Blöcke lassen sich beliebig aneinander stecken und können so ein größeres Haus bilden. Jeder Block besteht hierbei aus sechs Seiten, wobei jede Seite eine Wand, eine Tür oder ein Fenster sein kann. 15

4.3 Modell zu Quelltext 4.3 Modell zu Quelltext 4.3.1 Quelltextgenerierung Im Folgenden wird auf einige Quelltextgenerierungstechniken genauer eingegangen. All diese Techniken besitzen immer ein Metamodell bzw. eine abstrakte Syntax. Ferner existieren immer Transformationen, die auf diesem Metamodell aufbauen. 4.3.1.1 Templates Diese Generierungstechnik ist einer der einfachsten Wege zur automatischen Quelltexterzeugung. Im folgenden Beispiel soll aus einer Spezifikation eine komplette Javaklasse generiert werden. Dies wird mithilfe eines XSLT-stylesheet. <class name= Person package= com.mycompany > <attribute name= name type= String /> <attribute name= age type= int /> </class> Text 1: Spezifikation der Klasse <xsl:template match= class > package <xsl:value-of select= @package />; public class <xsl:value-of select= @name />; <xsl:apply-templates select= attribute /> } </xsl:template> <xsl:template match= attribute > private <xsl:value-of select= @type /> <xsl:value-of select= @name />; public <xsl:value-of select= @type /> get_<xsl:value-of select= @name />() { return <xsl:value-of select= @name />; } public void set_<xsl:value-of select= @name /> ( <xsl:value-of select= @type /> <xsl:value-of select= @name /> ) { } this.<xsl:value-of select= @name /> = <xsl:value-of select= @name />; </xsl:template> Text 2: XSLT-stylesheet 16

4.3 Modell zu Quelltext package com.mycompany; public class Person { private String name; private int age; public String get_name() { return name; } public void set_name(string name) { this.name = name; } } public int get_age() { return age; } public void set_age(int age) { this.age = age; } Solange keine größeren Systeme mit diesem recht einfachen Ansatz generiert werden müssen, steht der Quelltextgenerierung durch Templates nichts im Weg. Werden die Systeme allerdings komplexer, so werden die XSLT-stylesheets schnell unübersichtlich. 4.3.1.2 API-basierte Generatoren Text 3: Generierte Javaklasse Eine sehr bekannte Art der Quelltextgenerierung sind API-basierte Generatoren. Durch die zur Verfügung gestellte API können Elemente der Zielplattform erzeugt werden. Da sie auf der abstrakten Syntax der Zielsprache arbeiten, sind sie an sie gebunden. Das folgende, sehr kurze Beispiel soll einen ersten Einstieg ermöglichen. public class Vehicle : Object { } Text 4: Generierte Quelltext in C# CodeNamespace n =... CodeTypeDeclaration c = new CodeTypeDeclaration ( Vehicle ); c.isclass = true; c.basetypes.add (typeof (System.Object) ); c.typeattributes = TypeAttributes.Public; n.types.add( c ); Text 5: Generatorquelltext in C# Würden mehrere Sprachen derselben abstrakten Syntax existieren, könnten solche Generatoren für all diese Sprachen genutzt werden. Im Rahmen des.net-frameworks ist eine Auswahl der konkreten Syntax (C#, VB, C++) möglich. So kann ein abstrakt definierter API-basierter Quelltextgenerator für mehrere Zielsprachen verwendet werden. 4.3.2 Generierter Code / nicht generierter Code Da in den meisten Fällen nur Teile der Anwendung generiert werden, müssen die Lücken manuell mit Quelltext ausgefüllt werden. Jedoch ziehen manuelle Änderungen am Quelltext viele Probleme hinsichtlich Konsistenz, Build-Management, Versionierung nach sich. Können generierte Dateien, wenn sie zu 100% generiert wurden, einfach noch gelöscht werden um beim nächsten 17

4.3 Modell zu Quelltext build erneut erstellt zu werden, so muss mit generierten und nachträglich manipulierten Quelltexten anders verfahren werden: Manuelle Veränderungen müssen immer in dafür gekennzeichneten Bereichen stehen, damit sie beim Neugenerieren nicht überschrieben aber in das neue Generat übernommen werden können. Es ist ratsam, generierten und nicht-generierten Quelltext in verschiedenen Dateien zu halten und eine Architektur zu verwenden, die nicht nur klar hervorhebt, welche Artefakte generiert und welche manuell erstellt werden, sondern auch definiert, wie diese Quelltexte kombiniert werden. 4.3.3 Integration von generiertem und nicht generiertem Code Ausgehend von unverändertem, generiertem Quelltext soll manuell neuer Quelltext in das Generat eingefügt werden. Eine einfache Methode der Integration besteht in der Verwendung von reservierten Bereichen, die vom Generator lesbar sind. Hier kann der Entwickler eigenen Quelltext einfügen, ohne dass dieser bei nachfolgenden Generatorläufen überschrieben wird. Auto geschw indigkeit: int bescheunige(dv: int) stop() public class Auto { int geschwindigkeit = 0; public void beschleunige(int dv) { // protected area begin 0001 // insert your code here // protected area end - 0001 } } public void stop() { // protected area begin 0002 // insert your code here // protected area end - 0002 } Abbildung 14: Generierter Code mit Protected Areas Allerdings hat diese Methode einige Nachteile: Der Generator ist komplexer, da er die Erkennung, Erhaltung und Verwaltung der geschützten Bereiche bewältigen muss. Nicht immer ist eine Erhaltung geschützter Bereiche möglich; in der Praxis sind Quelltextverluste keine Seltenheit. Die Trennung von generiertem und manuell erstelltem Quelltext wird durchbrochen, da beide in einer Datei/Klasse stehen. Da besonders der letzte Punkt problematisch ist, sollten andere Mechanismen der Integration in Betracht gezogen werden. Eine viel genutzte Lösung ist die 3-schichtige Implementierung. 18

4.3 Modell zu Quelltext Nicht-generierte, abstrakte Basisklasse (Teil der Plattform ) Plattform schicht Generierte, abstrakte Mittelklasse Modellschicht Manuell im plem entiert, nicht-abstrakte Klasse Applikationslogik- Schicht Abbildung 15: Die drei Schichten der dreischichtigen Implementierung Als Teil einer Plattform wird zunächst eine abstrakte Basisklasse implementiert. Für jede Komponente generiert der Generator eine von der Basisklasse erbende Zwischenklasse. Diese realisiert alle aus dem Modell abgeleiteten Aspekte. Die letztlich durch den Entwickler erstellte, nicht abstrakte Implementierungsklasse erbt von der generierten Zwischenklasse und kann dann im System verwendet werden. Auf diese Weise können Lücken in der Zwischenklasse aufgefüllt werden. 4.4 Richtlinien 4.4.1 Alles in einem Rutsch Der Build-Prozess der endgültigen Anwendung sollte die Neugenerierung aller transformierten / generierten Artefakte umfassen. Werden auch nur wenige manuelle nachträgliche Schritte notwendig um das System innerhalb des Build-Prozesses zu erstellen, so wird eine Umgehung des MDA/MDSD-Schemas riskiert, die dann auf die traditionelle Softwareentwicklung zurückführt. Aus diesem Grund sollten alle manuellen Anpassungen in Zusammenhang mit dem Build-Prozess vermieden werden. Dies bedeutet keineswegs, dass 100% einer Anwendung generiert werden müssten. In den meisten Fällen ist es sogar unumgänglich, einige Teile in einer 3GL zu implementieren. Lediglich der Build-Vorgang soll in einem Rutsch durchgeführt werden können. 4.4.2 Generiere gut aussehenden Quelltext Anzunehmen, dass der Entwickler den generierten Quelltext nie zu Gesicht bekommt, ist unrealistisch. Obwohl Entwickler generierten Quelltext nicht ändern müssen, können sie mit herkömmlichen Entwicklungswerkzeugen bspw. beim debugging mit generiertem Quelltext in Berührung kommen. Folgende Möglichkeiten helfen, generierten Quelltext übersichtlich und verständlich zu halten: Sinnvolle Kommentare können unter Zuhilfenahme der im Modell verwendeten Terminologie und Informationen generiert werden. 19

4.4 Richtlinien Um die Lesbarkeit der generierten Quelltexte zu verbessern, können Pretty Printer oder Beautifier verwendet werden. Diese Werkzeuge existieren für jede gängige Programmiersprache und können generierten Quelltext umstrukturieren und mit sinnvollen Einrückungen versehen. So genannte Location Strings helfen, den generierten Quelltexten zugrunde liegende Modellelemente zu identifizieren. Ferner sind Generierungsdaten wie Datum und Versionsnummer sinnvoll. [2003-10-04 17:05:42] GENERATED FROM TEMPLATE SomeTemplate MODEL ELEMENT apackage::aclass::someoperation(). Text 6: Location Strings und Generierungsdaten Falls keine performancekritischen Anwendungsteile generiert werden, ist gute Lesbarkeit nicht nur bei generiertem Quelltext notwendig für die Akzeptanz bei Anwendungsentwicklern; sie ist bei manuell erzeugtem mindestens ebenso wichtig. Längst wird Quelltext nicht mehr nur für Maschinen geschrieben, sondern zum Lesen durch andere Benutzer. 20

5 MDSD Konzept 5 MDSD Konzept Modell Driven Architecture (MDA) ist einer der jüngeren Standards der Object Management Group (OMG); er wurde 2001 veröffentlicht. Die OMG - ein Konsortium aus ca. 800 Firmen - wurde 1989 gegründet und erstellt herstellerneutrale Spezifikationen zur Verbesserung der Portabilität und Interoperabilität von Software. Obwohl MDA und MDSD sich in vielen Aspekten ähneln, zielt MDSD im Gegensatz zu MDA auf die praktische Einsetzbarkeit für den Softwareentwicklungsprozess ab und legt die Priorität nicht wie MDA auf die langfristige Interoperabilität. Hierdurch werden aktuelle Entwicklungen modellgetriebener Softwareentwicklung für den Alltag einsetzbar; unabhängig vom Reifegrad des OMG-MDA-Standards. 5.1 Terminologie 5.1.1 Domäne Jede Modellierung bezieht sich immer auf eine Domäne. Sie bildet den Rahmen des gesamten Softwareprodukts und kann sowohl fachlich als auch technisch motiviert sein. Eine fachliche Domäne ist beispielsweise Versicherungen mit Konzepten wie Versicherungsprodukt, Tarif, Schaden, Vertrag, etc. Weitere Beispiele sind Astronomie oder Autohändler. Wenn sich Domänen aus kleineren Subdomänen zusammensetzen, lassen sich zwei Arten unterscheiden: Technische Subdomänen beschreiben einzelne Teile bzw. Aspekte des Gesamtsystems. Typische Beispiele sind GUI-Layout oder Persistenz. Große Systeme lassen sich oft in inhaltliche Teilgebiete untergliedern. Im obigen Versicherungsbeispiel könnten für einzelne Sparten Untergliederungen definiert werden: Leben, PKW, Haftpflicht, etc. 5.1.2 Metamodell Das Metamodell ist eine Schlüsselkomponente im Konzept des MDA/MDSD. Es ist Voraussetzung für das formale Modell einerseits und Modell-zu-Modell Transformationen andererseits. Das Metamodell formalisiert die Strukturen der betrachteten Domäne und ist Grundlage für jedwede Automation. Obwohl Metamodelle gut mit der UML beschrieben werden können, sind sie nicht notwendigerweise UML basiert. Das Metamodell umfasst die abstrakte Syntax und die statische Semantik. Erstgenannte spezifiziert lediglich die Struktur der Sprache und abstrahiert von Schreibweisen oder Schlüsselwörtern. Die statische Semantik einer Sprache legt Wohlgeformtheitskriterien fest; so müssen in (den meisten) Programmiersprachen Variablen vor ihrer Benutzung deklariert werden. Im Kontext von MDSD kommt der statischen Semantik eine besondere Bedeutung zu, da sie der Detektierung von Modellierungsfehlern dient. 21

5.1 Terminologie 5.1.3 Formale Modelle Formale Modelle bilden den Ausgangspunkt für automatisierte Transformationen. Selbst interpretative Ansätze erfordern ein formalisiertes Modell. Jedes formale Modell steht in direkter Verbindung zu einer Domäne und ist daher ein in der DSL formulierter Satz. Durch die Semantik der DSL erhält das Modell erst seine Bedeutung. Konzeptionell ist jedes Modell eine Instanz seines Metamodells. 5.1.4 Transformation Da jedes Quellmodell eine Instanz des zugehörigen Metamodells ist, basiert jede MDSD Transformation auf einem Quellmetamodell. Transformationsvorschriften resultieren daher ausschließlich aus den Konstrukten des Metamodells. Transformationen werden zwischen Modell-zu-Modell- und Modell-zu-Plattform- Transformationen unterschieden. Letztere werden häufig auch als Modell-zu-Code- Transformationen bezeichnet. Modell-zu-Modell-Transformationen erzeugen ihrerseits wieder Modelle. Diese können jedoch auf einem anderen Metamodell basieren als das Quellmetamodell. Solche Transformationen beschreiben prinzipiell wie Konstrukte vom Quellmetamodell in das Zielmetamodell überführt werden. Modell-zu-Plattform-Transformationen generieren mit Kenntnis einer speziellen Plattform Artefakte, die auf genau eine Plattform angepasst sind. 5.2 Ziele und Potentiale Mit MDA/MDSD soll mithilfe von formal eindeutigen Modellen eine signifikante Steigerung der Entwicklungsgeschwindigkeit erreicht werden. Hierzu wird durch Generatoren automatisch Quellcode erzeugt, der andernfalls mühsam per Hand geschrieben werden müsste. Durch die Codegenerierung werden einerseits Zeit und Kosten gespart und es wird andererseits auch die Softwarequalität gesteigert. Abbildung 16: Aufwand bei traditioneller bzw. modellgetriebener Softwareentwicklung 22

5.2 Ziele und Potentiale Ein weiteres Ziel ist die Reduzierung der Komplexität und damit eine wesentlich verbesserte Handhabbarkeit komplexer Modelle und Strukturen. Durch abstrakte Modellelierungssprachen soll eine klare Trennung von fachlichen und technischen Aspekten gewährleistet werden, um Verantwortlichkeiten zu trennen und die Wartbarkeit zu verbessern. Abstrakte und technologieunabhängige Beschreibungen der Strukturen und Modelle mithilfe einer eindeutigen Modellierungssprache ermöglichen einen einfacheren Umgang mit und einen schnelleren Umstieg auf neue Technologien. Wurden Modellierungssprachen, Architekturen oder Transformationen einmal definiert, so können sie im Sinne einer Softwareproduktionsstrasse wiederverwendet werden. Diese Art der Wiederverwendung kann zur Herstellung vieler verschiedener Softwaresysteme einer Domäne genutzt werden. 5.3 Genereller Ansatz Jedes Programm und jede Software unterliegt einer ihr eigenen Struktur und einem Modell. Diese Konstruktionsparadigmen sind je nach Programm offensichtlicher oder versteckter, ausgeprägter oder unpräziser, konsequenter oder uneinheitlicher im Quelltext wiederzufinden. Diese Variationen entstehen vor allem durch unterschiedliche Programmiergewohnheiten, fehlende fachliche oder domänenspezifische Kompetenz sowie wirtschaftliche Einflussfaktoren wie Zeitdruck und Resourcenmangel. Jedoch sind genau jene Konstruktionsparadigmen ausschlaggebende Einflussfaktoren auf Entwicklungsgeschwindigkeit, Qualität, Wartbarkeit, Performance, Interoperabilität und Portabilität. Abbildung 17: Grundidee modellgetriebener Softwareentwicklung 23

5.3 Genereller Ansatz Da Konstruktionsparadigmen sehr schwer auf Quelltextebene zu erkennen sind, da sie verteilt, verschleiert und oft stark individualisiert vorliegen, werden gewöhnlicherweise Dokumentationen erstellt. Diese leiden jedoch immer unter einem Konsistenzproblem und werden, wenn sie nicht ständig mit dem aktuellen Quelltext synchron gehalten werden, nutzlos. Hier kommt der Ansatz der modellgetriebenen Softwareentwicklung zum Tragen: Modelle sind abstrakt und formal zugleich. Abstrakte Modelle, die sich auf das Wesentliche reduzieren, haben den gleichen Stellenwert wie bisheriger Quelltext. So sind Modelle zwar immer noch Teil der Dokumentation und in der Lage, Strukturen, Architektur und Zusammenhänge grafisch und leicht verständlich darzustellen; sie sind darüber hinaus auch direkter Bestandteil der Software, da aus ihnen ein Großteil der Implementierung generiert werden kann. Die verwendeten Modelle fußen jeweils auf einer dem Problemraum angepassten, spezifischen Sprache, der Domain Spezific Language (DSL). Die Nutzung einer DSL ist allen modellgetriebenen Ansätzen gleich, da nur eine reduzierte und kompakte Modellsprache eine abstrakte Modelllösung überhaupt ermöglicht. Sei nun eine existierende Referenzimplentierung mit individueller Struktur gegeben. Durch etwaige Umstrukturierung des Quelltextes kann die Anwendung in drei wesentliche Teile gegliedert werden: Generischer Code: Quelltext, der für alle ähnlichen Programme gleich ist, Schematischer Code: Sich wiederholender Quelltext, der bspw. auf gleichen Entwurfsmustern basiert und Individueller Code: Anwendungsspezifischer Quelltext. Die modellgetriebene Softwareentwicklung hat nun das Ziel, den schematischen Anteil aus dem Modell abzuleiten. Die hierfür notwendigen Transformationen können zwar Zwischenstufen besitzen, müssen für die jeweilige Domäne jedoch nur einmal erstellt werden. Des weiteren ist auch die Zielplattform ein wesentliches Schlüsselelement, da die erstellten und genutzten Transformationen auf sie optimiert wurden bzw. nur mit ihr funktionieren. 24

6 Fazit 6 Fazit Wird der OMG Standard geeignet interpretiert, so ist MDA schon heute einsetzbar und die aufgeführten Potentiale teilweise umsetzbar. Erstmals wird eine echte Kontrolle der Architektur möglich, da zu jedem Zeitpunkt im Verlauf des Projekts sämtliche Details der Architektur bekannt sind. Alle modellierten Eigenschaften der Architektur fließen direkt und in voller Gänze in das Projekt ein und gewährleisten, dass Quelltext und Architektur in Einklang sind. Darüber hinaus wird durch die explizite Auseinandersetzung mit architekturbezogenen Themen das Bewusstsein um die Architektur gestärkt. Außerdem sind technische und fachliche Aspekte eindeutig identifizierbar und voneinander getrennt. Durch die Quelltextgenerierung kann je nach Projektart ein erheblicher Anteil automatisch erstellt werden und lästige Copy, Paste & Modify Arbeiten entfallen weitestgehend. Fehlerbehebung im technischen Quelltext lässt sich einfacher und effizienter durchführen. Liegt der Fehler im Infrastrukturquelltext, so muss er nur an einer Stelle im Generator behoben werden. Jedoch fehlt es zur Zeit immer noch an einigen Standards der OMG, bspw. für Modell-zu- Modell-Transformationen. Eine bessere Unterstützung durch Werkzeughersteller, die bspw. eine automatische Generierung von Tests oder Basisbausteine zur Verwendung bekannter Architekturmuster bereitstellen, kann den Entwicklungsprozess entscheidend fördern. 25

7 Quellen 7 Quellen Stahl, Völter: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management. Heidelberg: dpunkt.verlag, 2005 Javamagazin. Titelthema MDA-Einführung. Frankfurt: Software & Support Verlag 09.2003 Völter, Markus: Metamodellierung Heidenheim: völter - ingeneurbüro für softwaretechnologie Völter, Markus: Modellgetriebene Softwareentwicklung Heidenheim: völter - ingeneurbüro für softwaretechnologie Bausch, Daniel: Modellgetriebene Softwareentwicklung. Am Beispiel von openarchitectureware TU-Darmstadt Geiger, R.: Evaluierung von Produktivitätspotentialen im Softwareentwicklungsprozess für Webanwendungen FH Darmstadt Neuhaus, W., Holzer, B.: Modellgetriebene Softwareentwicklung. Alles UML, oder? Troisdorf: SIGS-DATACOM Glinz, Martin: Metamodelle Universität Zürich Software-Engineering: Einführung in die MDA http://www.software-kompetenz.de/?5348 [02.01.2008] Wikipedia: Modell Driven Architektur http://de.wikipedia.org/wiki/model_driven_architecture [02.01.2008] Wikipedia: Profil (UML) http://de.wikipedia.org/wiki/profil_%28uml%29 [13.01.2008] Computerwoche.de: Profile http://www.computerwoche.de/produkte_technik/software/572838/index4.html [13.01.2008] 26