In diesem Beitrag werde ich zunächst die Anforderungen herausarbeiten, die sich aus der MDD-Methodik für die Praxis ergeben. Diese werden sodann als Kriterien für die Evaluation von Modelling- und Software-Tools in weiteren Beiträgen verwendet. Diese wurden auf der Grundlage diverser Quellen [1, 2] und den Informationen der vorherigen Beiträge zu diesem Thema erstellt.

Softwaremodelle als zentraler Aspekt

DDD und MDD erfordern, dass das Modell als zentrales Element im Softwareentwicklungsprozess steht, und zwar von Beginn an. Sofern nicht bereits Code eines Systems existiert, wird das Modell im ersten Schritt neu erstellt. Für das Requirements Engineering bietet UML Anwendungsfalldiagramme an. Diese können wiederum für die Modellierung einer groben Systemkomponentenstruktur (Komponentendiagramm) und deren Feinstruktur (Klassendiagramm) verwendet werden. Die vorgenannten Aspekte spiegeln vorwiegend strukturelle und statische Elemente des Softwaresystems wieder. Fachlogik und das dynamische Anwendungsverhalten werden dagegen mittels Sequenz-, Interaktions- und Aktivitätsdiagrammen modelliert; auch hier können Anwendungsfalldiagramme als Vorlage dienen. Jeder der drei vorgenannten Diagrammtypen stellt die Systemdynamik mit dem Fokus auf unterschiedliche Aspekte dar. Bei DDD spielt zudem der Objektzustand eine große Rolle, dieser kann mit Hilfe von Zustandsdiagrammen modelliert werden. Die Grundlagen der UML-Modellierung sind in [3] umfassend erläutert und werden hier deshalb nicht näher betrachtet.

Integration vorhandener Artefakte

Für bereits existierende Systeme kann in der Regel zumindest die existierende statische Struktur (Packages und Klassen) mittels Reverse Engineering in ein UML-Modell überführt werden. Es ist typischerweise relativ einfach möglich, Klassendiagramme auf der Basis von existierendem Quellcode in einer objektorientierten Programmiersprache zu erstellen. Verhaltensaspekte dagegen sind auf diesem Weg häufig schwieriger in das Modell zu integrieren.
DDD verlangt darüber hinaus, dass das Modell zu jedem Zeitpunkt den aktuellen Stand der Architektur und des Designs des Softwaresystems widerspiegelt. Dies erfordert, dass Modell- und Codeartefakte jederzeit miteinander synchronisiert werden können.

Plattformunabhängigkeit

Systeme bestehen außerdem in vielen Fällen aus inhomogenen Komponenten, die teilweise auf der Grundlage unterschiedlicher Technologien und/oder Plattformen entwickelt wurden. Ist dies der Fall, so muss auch das Modell diesem Umstand Rechnung tragen. In Model-Driven Architecture (MDA) [4] wird daher zwischen PIMs (Platform-Independent Models) und PSMs (Platform-Specific Models) unterschieden. Erstere verwenden nur Elemente, die in nahezu allen objektorientierten Programmiersprachen gleichermaßen vorkommen, während letztere spezielle Aspekte einer gewählten Sprache unterstützen. Beispielsweise kennt C# Properties, während Java für den gleichen Zweck Getter- und Setter-Methoden verwendet. Sofern ein Softwareprojekt, das aus inhomogenen Komponenten besteht, entwickelt wird, sollte ein Modellierungstool die Transformation von PIM in PSM unterstützen, so dass Aspekte zunächst allgemein und dann pro zu unterstützender Technologieplattform im Detail modelliert werden können. Mit anderen Worten: die Fachlichkeit wird zuerst ohne Bezug zu einer Programmiersprache und/oder Technologieplattform abstrakt modelliert.

Anpassung an verwendete Technologien

Schließlich spielen auch projektspezifische Besonderheiten eine Rolle. UML erlaubt die Verwendung von Stereotypen und Tagged Values, um Eigenschaften bestimmter Modellelemente semantisch zu beschreiben. Ein Modellierungstool sollte Funktionen bereitstellen, die dem Entwicklerteam die Anpassung des Modelltransformations- und Codegenerierungsprozesses erlauben.

Zusammengefasst können daher die folgenden Kriterien aufgestellt werden:

1. UML-Modellierung: Das Tool muss die Erstellung der gängigen UML-Diagrammtypen erlauben. Idealerweise können Diagramme miteinander verknüpft werden, um die Navigation durch das Modell zu erleichtern.
2. Codegenerierung: Die Generierung von Quellcode in einer vorgegebenen Programmiersprache muss unterstützt werden.
3. Reverse Engineering: Existierender Code muss über Reverse Engineering in ein Modell überführt werden können, und zwar wenigstens für die statischen Strukturelemente des Softwaresystems, idealerweise auch für dynamische Elemente.
4. Synchronisierung: Die Synchronisation von Quellcode und Modell muss möglich sein, d. h. geänderte Modellelemente müssen bei der Generierung auch im Quellcode geändert bzw. neu eingefügt und Codeänderungen in das Modell übernommen werden können.
5. MDA: Sofern dies im Projekt benötigt wird, müssen sowohl PIMs als auch PSMs unterstützt werden. Erstere müssen dann in letztere transformierbar sein.
6. Anpassbarkeit: Die vorgenannten Generierungs-, Transformations- und Synchronisationsprozesse müssen über Templates anpassbar sein, so dass projekt- oder technologiespezifische Besonderheiten berücksichtigt werden können.

Fazit

Ein gutes MDD-Tool unterstützt Fachseite, Softwarearchitekten und Entwickler gleichermaßen bei der Modellierung von Fachlichkeit im sogenannten Domain Model mit Hilfe der UML. Dies geschieht zunächst abstrakt und ohne Bezug zu einer konkreten Technologieplattform. Strukturelle Elemente des Modells können im nächsten Schritt, d. h. nach Wahl einer Technologieplattform, weitgehend automatisiert in einer beliebigen objektorientierten Programmiersprache abgebildet werden. Hierbei können spezielle Aspekte der Zielprogrammiersprache im plattformspezifischen Modell abgebildet und der Codegenerierungsprozess entsprechend angepasst werden. Sofern bereits Code aus existierenden Systemen vorhanden ist, so muss dieser in das Modell integriert werden können. Code und Modell werden während des gesamten Entwicklungsprozesses synchron gehalten, hierfür ist ebenfalls eine Toolunterstützung erforderlich.

Referenzen

[1] Evans, Eric: Domain-Driven Design – Tackling Complexity in the Heart of Software, Addison-Wesley 2004
[2] Fowler, Martin: Patterns of Enterprise Application Architecture, Addison-Wesley 2003
[3] Fowler, Martin: UML Distilled – A Brief Guide to the Standard Object Modeling Language, 3. Auflage, Addison-Wesley, 2004
[4] Wikipedia: Model-Driven Architecture, Online-Publikation, http://en.wikipedia.org/wiki/Model-driven_architecture, Stand: 7. Februar 2013