Domänenspezifische Modellierung als Methode der Softwareentwicklung

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Grundlagen der DSM
2.1 Der Problem-Lösungs-Prozess
2.2 Architektur und Entwurf der DSM-Umgebung

3 Domänenspezifische Modellierung mit MetaEdit+
3.1 Theoretische Grundlagen
3.2 Architektur
3.3 Die Entwicklung einer DSM-Umgebung
3.3.1 Definition der Domänenkonzepte
3.3.2 Festlegung der Domänenregeln
3.3.3 Erstellung von Notationen
3.3.4 Codegenerierung und Erstellen von Reports
3.4 Das domänenspezifische Modellierungswerkzeug

4 Domänenspezifische Modellierung mit Microsoft Visual Studio 2005
4.1 Einführung
4.2 Die universelle Modellierungsplattform
4.3 Implementierung einer Domänenspezifischen Sprache

5 Fazit

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1: Der Weg von der Domänen-Idee zum fertigen Produkt

Abb. 2: Experten als Motor für die anderen Entwickler nutzen

Abb. 3: Architektur einer DSM-Umgebung

Abb. 4: Unterschiede zwischen CASE-Tools und MetaCASE-Tools

Abb. 5: Architektur von MetaEdit+

Abb. 6: GOPPRR-Metamodellierung mit MetaEdit+

Abb. 7: Object Tool in MetaEdit+

Abb. 8: Property Tool in MetaEdit+

Abb. 9: Graph Tool in MetaEdit+

Abb. 10: Bindings Tool in MetaEdit+

Abb. 11: Constraints Definer in MetaEdit+

Abb. 12: Symboleditor

Abb. 13: Systemhierarchie bei der Erstellung von Reports

Abb. 14: Generatoren definieren im Report Browser

Abb. 15: Graph Browser

Abb. 16: Diagrammeditor in MetaEdit+

Abb. 17: Matrixeditor in MetaEdit+

Abb. 18: Tabelleneditor in MetaEdit+

Abb. 19: Symbole aus dem Alltag

Abb. 20: Ansicht eines Domänenmodells

1 Einleitung

Die Modellierung ist eine beliebte und bewährte Ingenieurtechnik. Architekten z. B. bauen Modelle von Hochhäusern, um sie für den Kunden zu visualisieren. Wissenschaftler erforschen mithilfe von mathematischen oder physikalischen Modellen die Folgen von Naturkatastrophen. Die Automobilindustrie, um ein weiteres Beispiel zu nennen, testet Modelle im Windkanal. Die moderne Welt ist ohne Modellierung nicht mehr vorstellbar.

In dieser Arbeit soll die Modellierung als Methode der Softwareentwicklung näher betrachtet werden. Um hochwertige Software-Anwendungen zu erstellen, müssen die Prozesse des betreffenden Systems analysiert, modelliert und im Ergebnis optimiert werden. In den letzten Jahren haben Modellierungssprachen wie z.B. Unified Modeling Language (UML) bei der Modellgetriebenen Softwareentwicklung [Model Driven Software-Development - MDSD] an großer Bedeutung gewonnen. UML ist eine domänenneutrale und branchenunabhängige Modellierungssprache, die in den 90er Jahren des 20. Jahrhunderts zum Marktführer avancierte.

Doch ist dieses Werkzeug noch zeitgemäß?

UML sowie andere domänenneutrale Modellierungswerkzeuge sind sehr allgemein gehalten und haben keinen Bezug zu einer Domäne. Eine Domäne, abgeleitet von dem lateinischen Wort dominium, bezeichnet ein wissenschaftliches Fachgebiet oder eine bestimmte Branche. Die Modellierung mit domänenneutralen Werkzeugen ist nur für Experten geeignet und gestaltet sich für den Modellierungs-Laien sehr problematisch. Ein Zitat von Maslow besagt folgendes:

„When you only have a hammer, you tend to see every problem as a nail.”^[1]

Mit anderen Worten, man versucht zu viele verschiedene Aufgabenstellungen bei der Softwareentwicklung mit diesen domänenneutralen Modellierungswerkzeugen zu lösen.

Es entsteht daher ein Bedarf an Werkzeugen, die an eine bestimmte Domäne angepasst sind.

Ein Ansatz ist die Domänenspezifische Modellierung [Domain-Specific Modeling - DSM]. Bei der DSM sind die Modellelemente Objekte der Anwendungsdomäne.

Die Modellierung bezieht sich auf die Abstraktionen und die Semantik der Domäne. Der Modellierer kann direkt mit ihren Konzepten arbeiten. Die zu fokussierenden Regeln können als Grenzen der Domäne verstanden werden und lassen sich als Constraints in die Sprache einbinden, um ungültige und unerwünschte Entwurfsmodelle zu vermeiden.^[2]

Die DSM soll nicht ausschließlich dazu verwendet werden, Modelle einer Domäne zu generieren, sondern auch fertige Applikationen aus diesen zu erzeugen. Dieser hohe Grad der Automatisierung wird dann durch die Anwendung der domänenspezifischen Modellierungssprache [Domain-Specific Modeling Language - DSL] und des Codegenerators erreicht, wenn nur die Anforderungen einer Domäne erfüllt werden müssen.

2 Grundlagen der DSM

2.1 Der Problem-Lösungs-Prozess

In den Anfängen der Softwareentwicklung sind Problemlösungen mithilfe von komplexer Assemblersprache formuliert und durch einen Compiler (Assembler) in Maschinencode übersetzt worden. Der damit verbundene hohe Programmieraufwand wurde durch die Entwicklung von Programmiersprachen der dritten Generation sichtbar reduziert und führte somit zu einer erheblichen Produktivitätssteigerung. Die Bestrebungen nach einer stärkeren Übereinstimmung zwischen Code und Anwendungsdomäne, um das Abstraktionsniveau beim Programmieren weiter zu erhöhen, konnten durch die objektorientierten Sprachen wie z. B. Java oder C++ erreicht werden. Mit diesen Ansätzen, die Lösungen auf Basis der Implementierungsplattform abbilden und realisieren, konnten Softwareprodukte auf einem höheren Abstraktionsniveau erstellt werden.^[3]

Die modellgetriebene Softwareentwicklung (MDSD) führte zu einem Paradigmenwechsel in der Softwareentwicklung. Gemäß dem Leitsatz „Konfigurieren statt Programmieren“ steht bei diesem Ansatz das Modell, somit nicht mehr die Programmierung im Mittelpunkt. Die Visualisierung der Problemlösung mithilfe von Modellen erhöht die Verständlichkeit und wirkt der ansteigenden Komplexität von Projekten entgegen. Weiterhin dienen Modelle als Eingabe für Codegeneratoren, um so eine vollständige Codegenerierung zu ermöglichen.

Viele Modellierungssprachen wie z. B. UML sind codebasiert, d.h. es werden direkte Programmierkonzepte (Klassen, Funktionen) und nicht die Konzepte der Anwendungsdomäne als Modellkonstrukte verwendet. Im Ergebnis erhöht sich das Abstraktionsniveau nicht oder nur gering. Dies führt dazu, dass sich aus den Modellen, die die Implementierung in Code darstellen, nur ein geringer Anteil des fertigen Codes automatisch generieren lässt.

Als Konsequenz daraus muss der Entwickler den erzeugten Code manuell vervollständigen. Setzt man dieses Konstrukt fort, ergibt sich daraus eine redundante Entwicklung. Es entsteht das so genannte Roundtrip-Problem, da das Modell und der daraus generierte Code die gleichen Informationen enthalten müssen.^[4]

Ein weiterer wesentlicher Kritikpunkt besteht darin, dass UML sowie die anderen vorgestellten Ansätze (siehe Abb. 1) keinen direkten Bezug zur Anwendungsdomäne besitzen, so dass das Problem weiterhin zuerst in der Domäne gelöst werden muss. Wird durch den Einsatz von UML-Modellen kein adäquater Code generiert, so besteht die Notwendigkeit, dass Problem an drei Stellen zu lösen: in der Domänen-, in der UML- und der Codelösung.^[5]

Die Ausführungen haben gezeigt, dass UML zu generisch, aber für Dokumentationszwecke gut geeignet erscheint.^[6]

Eine nennenswerte Steigerung der Effizienz in der Softwareentwicklung kann also nur durch stärkere Konzentration auf die Anwendungsdomäne sowie die vollständige automatisierte Codegenerierung erfolgen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Der Weg von der Domänen-Idee zum fertigen Produkt^[7]

Die domänengetriebene Entwicklung [Domain-Driven Development – DDD] orientiert sich im Gegensatz zu den bereits vorgestellten Ansätzen stärker an der Domäne und erreicht eine Erhöhung des Abstraktionsniveau beim Programmieren.

Es sei nochmals festgehalten, Modelle dienen bei der domänenspezifischen Modellierung zur Visualisierung der Anwendungsdomäne und nicht der Programmierwelt.

Zur Spezifikation einer Lösung werden Domänenmodelle direkt aus Konzepten der Problemdomäne entwickelt. Resultierend aus der Tatsache, dass jede Domäne ihre eigenen speziellen Konzepte und Regeln besitzt, orientiert sich die Modellierungssprache an der Semantik und den Abstraktionen der Problemdomäne. Durch die Verwendung der Terminologie der Anwendungsdomäne wird sichergestellt, dass die Spezifikation bzw. das Modell fehlerfrei und vollständig ist.^[8] Da sowohl die Modellierungssprache als auch die Generatoren speziell an eine Domäne angepasst sind, kann das fertige Endprodukt automatisch aus der „High-Level-Spezifikation“ generiert werden.^[9]

Abbildung 2 zeigt die Vorgehensweise der DSM. Im Idealfall ist demzufolge für die Definition einer domänenspezifischen Modellierungssprache und des Codegenerators nur ein Domänenexperte oder ein Experten-Team erforderlich. Der Entwickler erstellt auf der Grundlage der Terminologie der Anwendungsdomäne das Modell, aus dem automatisch der Code generiert wird.^[10]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Experten als Motor für die anderen Entwickler nutzen^[11]

2.2 Architektur und Entwurf der DSM-Umgebung

Mit dem Einsatz von Metamodellierungswerkzeugen, auch genannt MetaCASE- Tools, wird der Entwurf einer DSM-Umgebung ermöglicht. Das schließt die automatische Generierung von unterstützenden Werkzeugen [Computer-Aided Software-Engineering (CASE) –Tools], die auf Grundlage der domänenspezifischen Sprache und Generatoren erstellt werden, mit ein. Die Implementierung von CASE-Tools, die Entwickler bei der Verwendung von domänenspezifischen Modellierungssprachen und Generatoren unterstützt, stellte einen entscheidenden Faktor für den Durchbruch der DSM dar.

Dies führt einerseits zu einer Reduktion der Produkteinführungszeiten und Senkung der Entwicklungskosten und andererseits zu einer Erhöhung der Zuverlässigkeit. Somit wird durch den Einsatz von DSM eine Verbesserung der Produktivität, Qualität und Verständlichkeit erreicht.^[12]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Architektur einer DSM-Umgebung^[13]

Der Aufbau einer solchen DSM-Umgebung wird in der Abbildung 3 nochmals verdeutlicht. Die Bausteine, aus denen die Enwicklungsumgebung generiert wird, sind im linken Teil dargestellt. Demgegenüber sind die Komponenten abgebildet, die der Modellierer für die Produkterstellung verwendet.^[14]

Bei der Definition einer DSM-Umgebung empfiehlt sich eine inkrementelle Vorgehensweise. Die entworfene Modellierungssprache (oder Teile davon) kann sofort in konkreten Modellen, von z.B. potenziellen Benutzern bzw. Modellierern getestet werden. Das hat den Vorteil, dass auf dieser Grundlage frühzeitig Verbesserungsmöglichkeiten umgesetzt und das Verständnis für die Domäne erhöht wird.

Nachdem hier nun ein Überblick über die Architektur einer domänenspezifischen Modellierungsumgebung gegeben wurde, soll nun der Entwurf einer DSL, der Generatoren sowie des Domänen-Framework detaillierter erläutert werden.

Die Definition einer Modellierungssprache scheint auf den ersten Blick komplex und aufwendig zu sein. Doch begrenzt man den Geltungsbereich auf nur eine Domäne in einem Unternehmen, ist die Aufgabe lösbar.^[15] Die Konzeption einer DSL gliedert sich in drei Phasen:^[16]

- die Definition der Domänenkonzepte
- die Festlegung der Domänenregeln
- und die Erstellung von Notationen.

Im Folgenden werden diese zentralen Aspekte näher erläutert.

Definition der Domänenkonzepte

Der Zweck einer DSL ist es, die Terminologie einer Anwendungsdomäne zu formalisieren. Ein besonderer Fokus liegt hierbei auf der Semantik einer DSL. Sie muss für den Anwender bzw. Modellierer klar verständlich oder gut dokumentiert sein.

Ein Ansatz zur Identifikation der Konzepte des Anwendungsbereiches besteht darin auf die Fachkompetenz von einem oder mehreren Domänenexperten zurückzugreifen. Durch ihre langjährigen Erfahrungen in der Produktentwicklung sind diese mit der Semantik und der Architektur (Systembeschreibung, Dienste der Komponenten) der Domäne vertraut. Folglich können sie einfacher die erforderlichen Konzepte definieren und diese als Objekte der Modellierungssprache mit Objekteigenschaften und -verbindungen darstellen. Das Ziel ist es, dass die identifizierten Konzepte der Semantik der Domäne entsprechen.^[17]

Festlegung der Domänenregeln

Regeln werden genau wie die Domänenkonzepte direkt in die DSL eingebunden. Durch die Spezifikation von Regeln wird einerseits die Verwendung der Modellierungssprache eingeschränkt, indem sie die zulässigen Verbindungen zwischen den Konzepten sowie deren Wiederverwendung aber auch die Anordnung von Modellen festlegen. Andererseits wird die Richtigkeit des Modells sichergestellt, da Fehler von Entwicklern frühzeitig verhindert werden.^[18]

Erstellung von Notationen

Im letzten Schritt werden unter Verwendung von DSM-Werkzeugen für die Konzepte eigene Notationen entworfen. Durch die visuelle Repräsentation in Form von Symbolen wird die Wartbarkeit und Erzeugung von Modellen erleichtert sowie deren Verständlichkeit erhöht. Vorrausetzung für die Verwendung von Notationen ist deren Konsistenz, d.h. sie müssen eindeutig abgebildet sein, so dass eine Verwechslung zwischen den erstellten Notationen verhindert wird.^[19]

Nachdem hier auf den theoretischen Entwurf einer DSL eingegangen wurde, erfolgt nun eine detailliertere Vorstellung der letzten zwei Komponenten einer DSM-Umgebung.

Definition des Domänen-Framework

Das Domänen-Framework trägt durch die Bereitstellung von selbst definiertem Framework-Hilfscode oder einzelnen Komponenten (z. B. Templates zur Bereitstellung der Benutzeroberfläche), in Form einer Komponenten-Bibliothek, zur Vereinfachung der Codegenerierung bei. Es stellt die Schnittstelle zwischen dem erzeugten Code und der darunterliegenden Plattform bereit. Die Erstellung eines Domänen-Framework ist zwar nicht zwingend notwendig, z. B. wenn die Dienste der bestehenden Komponente ausreichend sind, aber hilfreich, da Komponenten aus früheren Enwicklungen verwendet werden können.^[20]

Entwicklung des Codegenerators

Durch die Definition eines Codegenerators werden die erstellten Modelle in Code überführt. Die Hauptaufgabe ist es, Regeln zu formulieren, mit denen spezifiziert wird, wie die Informationen aus den Domänenmodellen ausgelesen und in Quellcode transformiert werden. Das zentrale Anliegen besteht dabei immer in der Generierung von vollständig ausführbarem Code.^[21]

Das Domänen-Framework erleichtert diese Aufgabe z. B. bei der Implementierung vordefinierter Komponenten, wodurch der Abstraktionsgrad auf der Codeseite angehoben wird.

Resultierend aus der Tatsache, dass domänenspezifische Modelle unabhängig vom Quellcode sind, kann durch die Verwendung unterschiedliche Generatoren Code für verschiedene Plattformen generiert werden.^[22]

[...]

---

^[1] Maslow /The Unpublished Papers/

^[2] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 30

^[3] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 30

^[4] Vgl. Stahl, Völter /Modellgetriebene Softwareentwicklung/ 12

^[5] Vgl. Kelly /Modellierung mit MetaEdit+/ 1

^[6] Vgl. Vgl. Greenfield, Short /Software Factories/ 118

^[7] Vgl. Kelly /Modellierung mit MetaEdit+/ 1

^[8] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 31

^[9] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung - Praxisbeispiele/ 22

^[10] Vgl. Kelly /Modellierung mit MetaEdit+/ 2

^[11] Vgl. Kelly /Modellierung mit MetaEdit+/ 2

^[12] Vgl. Kelly /Modellierung mit MetaEdit+/ 2

^[13] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 32

^[14] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 32

^[15] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung - Praxisbeispiele/ 22

^[16] Vgl. Kelly /Modellierung mit MetaEdit+/ 4

^[17] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 32

^[18] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 32

^[19] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung - Praxisbeispiele/ 27

^[20] Vgl. Kelly /Modellierung mit MetaEdit+/ 4

^[21] Vgl. Kelly /Modellierung mit MetaEdit+/ 4

^[22] Vgl. Tolvanen, Kelly /Domänenspezifische Modellierung/ 33