Technische Universität Ilmenau, Fakultät für Informatik und Automatisierung
Fachgebiet Biosignalverarbeitung, Projektarbeit Informatik
WS 2005/2006

Domänenspezifische Modellierung

von: Andreas Ludwig

Inhaltsverzeichnis

1 Einleitung 5

2 Grundlagen der DSM 6

2.1 Der Problem-Lösungs-Prozess  6
2.2 Architektur und Entwurf der DSM-Umgebung 9

3 Domänenspezifische Modellierung mit MetaEdit+  14

3.1 Theoretische Grundlagen 14
3.2 Architektur 16
3.3 Die Entwicklung einer DSM-Umgebung 17

3.3.1 Definition der Domänenkonzepte  17
3.3.2 Festlegung der Domänenregeln  21
3.3.3 Erstellung von Notationen  23
3.3.4 Codegenerierung und Erstellen von Reports 24

3.4 Das domänenspezifische Modellierungswerkzeug  26

4 Domänenspezifische Modellierung mit Microsoft Visual Studio 2005 29

4.1 Einführung 29
4.2 Die universelle Modellierungsplattform  31
4.3 Implementierung einer Domänenspezifischen Sprache 32

5 Fazit 33

Literaturverzeichnis  35

Abkürzungsverzeichnis

CASE = Computer-Aided Software-Engineering
DDD = Domain-Driven Development
DSL = Domain-Specific Modeling Language
DSM = Domain-Specific Modeling
GOPPRR = Graph, Object, Property, Port, Relationship, Role
HTML = Hypertext Markup Language
MDSD = Model Driven Software-Development
UML = Unified Modeling Language
XML = Extensible Markup Language
 

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.”¹ 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.² 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.³

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.⁴ 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.⁵ Die Ausführungen haben gezeigt, dass UML zu generisch, aber für Dokumentationszwecke gut geeignet erscheint.⁶ 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.

[...]

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