|
|
[Seminarthemen WS08/09] [ < ] [ > ] [Übersicht]
Die modellgetriebene Softwareentwicklung ist eine Technik der Softwareentwicklung, bei der Teile des zu entwickelnden Softwaresystems mit Hilfe von Modellen auf einem höheren Abstraktionsniveau beschrieben werden (vgl. [SVEH07, S. 4 u. S. 11]). Unter einem Modell soll hierbei eine Menge von Aussagen über ein betrachtetes System verstanden werden (vgl. [Met05, S. 19]). Bei Modellen wird in der Regel von Systemanteilen abstrahiert, die für die jeweilige Betrachtung nicht relevant sind, um die Komplexität zu verringern und eine Fokussierung auf die relevanten Aspekten zu erlauben.
Die Verwendung von Modellen zur Softwareentwicklung an sich ist nicht neu und hat seit der De&64257;nition der Uni&64257;ed Modeling Language (UML) noch zugenommen. Diese Modelle dienen jedoch oftmals lediglich zum Design bzw. zur Dokumentation der Software, was nach Stahl et al. [SVEH07] als modellbasierte Softwareentwicklung bezeichnet werden soll (vgl. [SVEH07, S. 3]). Hierbei besteht zwischen dem Modell und der Implementierung lediglich eine gedankliche Verbindung. Dies kann zum einen dazu führen, dass im Entwicklungsprozess gewonnene Erkenntnisse sowie daraus resultierende Änderungen im Modell nachgetragen werden müssen. Dieser Prozess ist jedoch aufwändig und wird daher in der Praxis oftmals vernachlässigt, sodass Inkonsistenzen zwischen dem Modell und der Implementierung entstehen. Zum anderen liegt die Aufgabe der Transformation des Modells in die Implementierung vollständig beim Entwickler, sodass das Design zum Teil „nachimplementiert“ wird. Ein solcher Prozess ist nicht nur fehleranfällig, sondern birgt darüber hinaus die Gefahr unterschiedlicher Interpretationen seitens der Entwickler und damit auch die Gefahr unterschiedlicher (und damit inkonsistenter) Umsetzungen.
Im Unterschied dazu stehen bei der modellgetriebenen Softwareentwicklung die Modelle gleichberechtigt neben dem Quellcode und &64258;ießen direkt in die Implementierung der Software mit ein. Das Adjektiv „getrieben“ soll dabei die zentrale Rolle der Modelle im Entwicklungsprozess hervorheben. Durch die direkte Integration der Modelle in die Software ergibt sich zudem die Möglichkeit der Automatisierung dieses Prozesses.
Die modellgetriebene Softwareentwicklung wird in der Literatur nicht einheitlich de&64257;niert (vgl. [ZW06, S. 22]; [Met05, S. 2]; [SVEH07, S. 11]). Die in der oben genannten Literatur aufgeführten De&64257;nitionen der MDSD haben jedoch einen gemeinsamen Kerngedanken: Die Modelle stellen einen wesentlichen Aspekt der MDSD dar und &64258;ießen in die Software als Endprodukt ein. Für die weiteren Ausführungen soll die umfassendere De&64257;nition von Stahl et al. [SVEH07] verwendet werden, die auch die Art der Integration der Modelle in die Software umfasst:
Modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD) ist ein Oberbegri&64256; für Techniken, die aus formalen Modellen automatisiert lau&64256;ähige Software erzeugen. [SVEH07, S. 11]
Diese De&64257;nition beinhaltet die folgenden drei Aspekte (vgl. [SVEH07, S. 11&64256;.]):
Die Einordnung, ob ein Vorgehen modellgetrieben ist oder nicht, kann dabei nicht immer ganz trennscharf getro&64256;en werden. Hervorzuheben ist, dass MDSD nicht auf einzelne Sprachen oder Werkzeuge eingeschränkt ist, sondern einen allgemeinen Ansatz darstellt.
Die übergeordneten Ziele der MDSD sind die Verbesserung der Softwarequalität und der Wiederverwendbarkeit sowie die Erhöhung der Entwicklungse&64259;zienz. Diese Ziele sollen durch den Einsatz der MDSD wie folgt erreicht werden (vgl. [SVEH07, S. 13&64256;.]):
Einheitliche Architektur Durch die automatisierte Erzeugung der modellierten Softwareteile wird gewährleistet, dass diese Teile einheitlich und nach einem festgelegten Schema erzeugt werden und so zwingend dieselbe Architektur und Implementierung besitzen. Dieses Vorgehen erhöht die Konsistenz des Systems und führt zu einer klareren Struktur. Dies bedeutet dabei nicht, dass die Architektur bereits zu einem frühen Zeitpunkt endgültig festgelegt sein muss. Vielmehr werden nachträgliche Architekturänderungen erleichtert und können konsistent durchgeführt werden. Die Änderungen müssen lediglich an einer zentralen Stelle (der Festlegung, wie die Software ausgehend von den Modellen zu erzeugen ist) vorgenommen werden.
Entwicklungse&64259;zienz Auf den ersten Blick ließe sich eine E&64259;zienzsteigerung darauf zurückführen, dass bei der MDSD, im Vergleich zu einem herkömmlichen Vorgehen, der Anteil an zu schreibendem Quellcode durch die automatische Erzeugung von Codeteilen wesentlich geringer ist. Gerade in größeren Projekten entfällt auf das eigentliche Schreiben des Quelltextes jedoch nur ein sehr geringer Teil der Zeit, sodass hier lediglich ein kleiner Vorteil zu erwarten ist.
Ein wesentlich größerer Vorteil ergibt sich mittelfristig bei der Weiterentwicklung bzw. in der Wartungsphase, wenn bereits mehrere Änderungen am System durchgeführt wurden. Durch die Automatisierung ist das System auch nach mehreren Änderungen konform zu der ursprünglichen Architektur, wodurch auch nachträgliche Erweiterungen einfach integriert und so potentielle Fehler reduziert werden können. Zudem kann das Expertenwissen, das während der Entwicklung der Automation in diese einge&64258;ossen ist, auch zukünftig weiterverwendet werden.
Wiederverwendbarkeit Die Architekturen, Modellierungsmechanismen sowie Automationsschritte können zur Herstellung mehrerer verschiedener Softwaresysteme verwendet werden. Insbesondere wenn eine Reihe von sehr ähnlichen Systemen entwickelt werden soll, ergibt sich ein großes Wiederverwendungspotential: Durch die Abstraktion von den Unterschieden der Systeme und die Auslagerung dieser Unterschiede in Modelle sind nur geringe Anpassungen notwendig, um mit einer Implementierung verschiedene, gleichartige Systeme zu erstellen.
Softwaresysteme bilden unterschiedliche fachliche oder technische Geltungsbereiche ab. Kerngedanke der MDSD ist es, eine für den jeweiligen Bereich spezi&64257;sche Abstraktion zu &64257;nden, um diesen auf Basis der Abstraktion formal beschreiben zu können. Mit Hilfe dieser formalen Beschreibung wird es möglich, die Aspekte des Geltungsbereichs automatisiert in den Entwicklungsprozess zu integrieren. Für diese abstrakte Beschreibung sowie für die automatisierte Integration existieren in der MDSD zwei grundlegende Konzepte (vgl. [BCT05, S. 2]):
Die Modellierung im Kontext der MDSD sowie die in diesem Zusammenhang verwendete Terminologie sollen im Folgenden erläutert werden (vgl. [SVEH07, S. 28&64256;.]). Abbildung 1 zeigt eine Einordnung der einzelnen Begri&64256;e sowie deren Zusammenhänge untereinander.
|
|
Domäne Eine Domäne bezeichnet einen abgegrenzten Interessens- oder Wissensbereich, der durch ein Modell beschrieben werden soll. Unterschiedliche Domänen können dabei jeweils durch eigene Modelle beschrieben werden, sollten jedoch klar voneinander abgegrenzt werden. Zur Verringerung der Komplexität großer Domänen können diese zusätzlich in Subdomänen aufgeteilt werden. Domänen können dabei sowohl fachlich als auch technisch orientiert sein: Die Speicherung von Objekten in Datenbanken stellt eine technische Domäne dar, während die Regeln eines Kreditrankings einer Bank eine fachliche Domäne darstellen.
Metamodell Um eine Domäne formal beschreiben zu können, muss ihre Struktur formalisiert werden. Die formale Beschreibung dieser Domänenstruktur wird als Metamodell bezeichnet. Da Domänen durch Modelle beschrieben werden, beschreibt ein Metamodell zugleich auch die Struktur der Modelle der entsprechenden Domäne. Ein Metamodell legt zudem die abstrakte Syntax sowie die Kontextbedingungen einer Sprache fest, mit der die Domäne beschrieben werden kann.
Abstrakte und konkrete Syntax Die Syntax einer Sprache legt die Regeln für die korrekte Konstruktion von Ausdrücken einer Sprache fest. In Bezug auf das Metamodell beschreibt die abstrakte Syntax die Regeln zur korrekten Konstruktion von Modellen auf Basis der Elemente des Metamodells.
Die konkrete Syntax beschreibt die Regeln für eine konkrete Repräsentation der abstrakten Syntax, beispielsweise in einer textuellen oder gra&64257;schen Notation, mit denen die Modelle letztendlich geschrieben werden können. Eine abstrakte Syntax kann dabei durch eine oder auch mehrere konkrete Syntaxen repräsentiert werden. Die De&64257;nition einer Syntax kann beispielsweise durch eine kontextfreie Grammatik oder mit Hilfe der Backus-Naur-Form erfolgen.
So de&64257;niert die abstrakte Syntax der Sprache Java das Konstrukt der Klassen, die durch einen Namen identi&64257;ziert werden. Klassen können zudem von einer anderen Klasse abgeleitet werden sowie Interfaces implementieren. Die konkrete Syntax hingegen legt fest, dass eine Klassende&64257;nition mit dem Schlüsselwort class beginnt und die Oberklasse mit extends sowie die implementierten Interfaces mit implements angegeben werden.
Kontextbedingungen Die Kontextbedingungen2 einer Sprache beschränken deren Syntax und beschreiben die Menge der wohlgeformten (gültigen) Sprachausdrücke (vgl. [HR00, S. 14]). Die Bedingungen werden dabei mit Bezug auf die abstrakte Syntax de&64257;niert und sind somit von ihr abhängig. Ein Beispiel für Kontextbedingungen von Programmiersprachen ist die Bedingung, dass Variablen vor der ersten Benutzung de&64257;niert werden müssen.
Semantik Im Gegensatz zur Syntax, die Regeln über den korrekten Aufbau von Ausdrücken einer Sprache festlegt, legt die Semantik die Bedeutung der Sprachelemente auf Basis der abstrakten Syntax fest. Die Semantik kann dabei formal spezi&64257;ziert sein oder intuitiv abgeleitet werden. Eine gängige Semantik des binären Operators „+“ beispielsweise ist die mathematische Operation der Addition.
Domänenspezi&64257;sche Sprache Eine domänenspezi&64257;sche Sprache (domain speci&64257;c language, DSL) entspricht einer Programmiersprache der jeweiligen Domäne, mit der Modelle geschrieben werden können. Eine domänenspezi&64257;sche Sprache basiert auf einem Metamodell der Domäne mit dazugehöriger abstrakter Syntax und Kontextbedingungen. Die konkrete Syntax legt die Notation der domänenspezi&64257;schen Sprache fest, während die Bedeutung der Ausdrücke durch die Semantik bestimmt wird.
Formales Modell Ein formales Modell ist eine Beschreibung einer Domäne und wird in seiner Struktur wiederum durch ein Metamodell beschrieben. Ein formales Modell kann als ein in einer domänenspezi&64257;schen Sprache geschriebenes Programm angesehen werden, das automatisiert in die ausführbare Software überführt werden kann (vgl. [SVEH07, S. 31]).
Metametamodell Jedes Modell kann in seiner Struktur ebenfalls wieder durch ein Modell beschrieben werden, das Metamodell des Modells. Das Modell bildet dabei eine Instanz des Metamodells. Prinzipiell sind beliebig viele Metaebenen möglich, in der MDSD wird üblicherweise eine dreistu&64257;ge Modellhierarchie verwendet: Modell, Metamodell und Metametamodell (vgl. [SVEH07, S. 31]).
Das Metametamodell beschreibt dabei die Struktur des zu einer Domäne gehörigen Metamodells. Durch die Verwendung einheitlicher Metametamodelle wird es möglich, unterschiedliche Metamodelle mit denselben Softwarewerkzeugen zu erstellen sowie zu verarbeiten. Die Beschreibung von Metametamodellen kann durch weitere, unabhängige Metamodelle oder rekursiv erfolgen. In dem letzteren Fall beschreibt sich das Metametamodell somit selbst.
Domänen Modelle dienen dazu, Domänen der Software abstrakt zu beschreiben. Somit kommt der Auswahl der zu beschreibenden Domänen eine zentrale Bedeutung zu (vgl. [HSS05, S. 113]). Prinzipiell kann jede beliebige Domäne modelliert werden, für die dies sinnvoll ist. Schließlich ist die Allgemeingültigkeit des Modellierungsansatzes ein zentraler Aspekt der MDSD. Es existieren jedoch einige typische Anwendungsbereiche, die an dieser Stelle vorgestellt werden sollen (vgl. [Gen08a]). Diese Bereiche lassen sich zudem oftmals sinnvoll miteinander kombinieren.
Abstraktionsniveau Eine wichtige Entscheidung beim Entwurf eines Metamodells ist die Wahl des Abstraktionsniveaus. Ist das Modell zu konkret, so ergibt sich kein zusätzlicher Nutzen durch das Modell, die Zielsprache wird nachmodelliert. Zudem führt die damit einhergehende Vielzahl an Aspekten zu Unübersichtlichkeit. Ist das Modell jedoch zu abstrakt, so werden wesentliche Fragestellungen nicht im Modell abgebildet, was wiederum die Generierung erschwert. Insofern ist die Wahl des Abstraktionsniveau keine triviale Entscheidung, sondern kontextabhängig zu tre&64256;en. Dafür können die folgenden Empfehlungen gegeben werden:
Insgesamt sollte eine Tendenz zu schlanken Modellen vorliegen, die eventuell durch weitere Modelle erweitert werden.
Modell-zu-Modell-Transformationen stellen einen wesentlichen Bestandteil der MDSD dar, da sie die Lücke zwischen verschiedenen Abstraktionsniveaus überbrücken (vgl. [SVEH07, S. 195]). In einer MDSD ohne Modelltransformationen existieren lediglich zwei Abstraktionsebenen – die Ebene des Modells und die Ebene des Quellcodes. Diese Einschränkung führt jedoch zu zwei Problemen (vgl. [SVEH07, S. 195]):
Modell-Transformationen hingegen erlauben es, mehrere Abstraktionsebenen miteinander zu verbinden. Dadurch wird es beispielsweise möglich, fachliche Datenmodelle schrittweise in technische Persistenzmodelle zu überführen, aus denen dann OR-Mappings generiert werden können. Modell-Transformationen können in zwei Kategorien eingeteilt werden (vgl. [SVEH07, S. 199f.]):
Für die Modell-zu-Code-Transformation existieren zwei funktional äquivalente Ansätze: Die Generierung von Quellcode ausgehend vom Modell sowie die Interpretierung des Modells zur Laufzeit.
Die Generierung erfolgt dabei anhand festgelegter Transformationsregeln. Diese können beispielsweise in einer imperativen Sprache (z. B. Java) ausprogrammiert oder mit Hilfe einer Templatesprache angegeben werden. Ausprogrammierte Generatoren bieten vielfältige Möglichkeiten der Codeerzeugung, in der Regel jedoch nur eine eingeschränkte Unterstützung von Zeichenketten, die statische Anteile des zu erzeugenden Codes abbilden. Sollen große statische Anteile erzeugt werden, so sind Templatesprachen besser geeignet. Ein Beispiel für eine Templatesprache zur Transformation von XML-Modellen ist XSLT [2].
Die oben genannten Methoden weisen dabei unterschiedliche Vor- und Nachteile auf:
Integration von geniertem und manuellem Code In der Regel steht der erzeugte Code (oder das zu interpretierende Modell) nicht alleine, sondern muss in weiteren, manuell geschriebenen Code integriert werden. Da generierter Code in der Regel mehrfach erzeugt und auch wieder gelöscht wird, ist eine manuelle Erweiterung nicht zielführend. Somit stellt die Integration von generiertem und manuellem Code eine zentrale Herausforderung der MDSD dar. An dieser Stelle sollen drei mögliche Vorgehensweisen kurz vorgestellt werden; für eine detailliertere Diskussion sei auf Stahl et al. [SVEH07, S. 159&64256;.] verwiesen.
dargestellte Hierarchie umgesetzt: Eine abstrakte Basisklasse implementiert von der eigentlichen Anwendung unabhängige Funktionalität. Eine generierte, aber ebenfalls abstrakte Mittelklasse implementiert alle Aspekte, die aus dem Modell abgeleitet werden können, während eine manuell implementierte Klasse schließlich zusätzliche fachliche Methoden bereitstellt. Dieser Ansatz wird beispielsweise im Web-Framework „symfony“ für die Persistenz verwendet.
Cartridges stellen zwar keine konzeptuell neue Transformation dar, sind jedoch eine logische Weiterentwicklung der vorgestellten Transformationen und sollen daher an dieser Stelle erwähnt werden. Cartridges (Steckmodule) sind fertige Generatorkomponenten für einzelne Domänen (vgl. [SVEH07, S. 197]) und umfassen neben einem Metamodell fertige Modell-zu-Code-Transformationen. Cartridges erlauben es beispielsweise, technische Details für verwendete Frameworks wie Spring oder Hibernate zu kapseln. Für die Nutzung einer solchen Cartridge muss ein dem Metamodell der Cartridge entsprechendes Modell erzeugt werden – typischerweise mit Hilfe einer Modelltransformation. Die Erzeugung des Generierungsergebnisses geschieht dann innerhalb der Cartridge. Diese Vorgehensweise erlaubt es, oft verwendete Generatoren durch eine einheitliche Schnittstelle wiederzuverwenden. Eine Austauschmöglichkeit für Cartridges bietet beispielsweise die Fornax-Plattform [3].
[Seminarthemen WS08/09] [ < ] [ > ] [Übersicht]
