Modellgetriebene Softwareentwicklung

Auszug aus einem Beitrag von Oliver Meimberg: "Möglichkeiten und Potentiale der Formalisierung in der Softwareentwicklung" in "Schriften zum Software-Qualitätsmanagement" von  Roland Petrasch und Stephan Höppner [Hrsg.], Logos Verlag Berlin

Im Bereich der Datenanalyse oder der Analyse von besonders kritischen Abläufen ist der Begriff der Modellierung nicht neu. Die Zielsetzung der modellgetrieben Softwareentwicklung (MDD) ist es nun, möglichst alle Informationen, die im Softwareentwicklungsprozess (vor allem in der Phase der Anforderungs- und Systemanalyse) entstehen, in formalen Modellen abzubilden. Der Vorteil liegt auf der Hand: Höheres Automatisierungspotential durch die Eindeutigkeit der Informationen.

Die OMG (Object Management Group) beschreibt den Begriff des Modells folgendermaßen: "Ein Modell repräsentiert einen Teilaspekt der Funktionalität, Struktur oder Verhaltensweise in einem System" [WebOMG1]

Für ein formal gültiges Modell sollte folgendes gelten:

• Einem Modell liegt eine formal eindeutige Syntax zugrunde, die die Notationselemente genau definiert. Dies können grafische Elemente, wie z.B. in der UML oder anderen Diagrammformen wie auch textuelle Elemente wie Tags in XML-Modellen oder auch Sprachelemente von Programmiersprachen sein.
• Die möglichen Beziehungen zwischen den einzelnen Notationselementen sind formal genau festgelegt (Grammatik).
• Den Notationselementen und ihren Beziehungen zueinander ist für eine klar definierte Abstraktionsebene (Modellierungsebene) eine eindeutige Bedeutung zugeordnet (Semantik).

Eine formal eindeutige und vollständige Definition von Syntax (Notationselemente plus Grammatik) und Semantik (Bedeutung der Notation innerhalb der Modellierungsebene) nennt man Metamodell oder auch Sprache.

Einfacher ausgedrückt: Ein Metamodell ist ein Modell, das beschreibt wie bestimmte Modelle gebaut bzw. interpretiert werden.

Die Aufgabe eines Modells ist es, Informationen eines bestimmten Teilaspektes möglichst formal und eindeutig zu beschreiben. Vor dem Hintergrund der oben beschriebenen Formalisierung von Projektinformationen kann auch ein stark formalisiertes Artefakt als Modell bezeichnet werden. Die auf abstrakter Ebene für einen Artefakttyp festgelegte Informationsstuktur ist dementsprechend das dem Artefakt zugrundeliegende Metamodell.

Die Syntax einer Sprache bzw. eines Metamodells wird bestimmt aus der Notationsform und der darüberliegenden Grammatik. Für die praktische Metamodellierung in Softwareprojekten wird hier üblicherweise auf bereits bestehende Beschreibungssprachen wie UML oder XML zurückgegriffen. Diese Sprachen sind zum einen sehr verbreitet und werden inzwischen durch unzählige Tools unterstützt, zum anderen bieten sie genügend Freiraum zur Anreicherung der Sprache mit eigener spezifischer Semantik.

Ein Modell muss, um es sinnvoll interpretieren zu können, eindeutig mit einer klar definierten semantischen Bedeutung gepaart sein.

Die semantische Ausprägung der Sprachen wird mit Bezeichnungen von betrachteten Objekten und Aspekten aus der Welt, die es zu beschreiben gilt, formal genau festgelegt. Besonders wichtig ist hier die absolute Eindeutigkeit eines jeden Modellelementes. Die gefundenen Begriffe werden miteinander in Beziehung gesetzt und mit Regeln für Schlussfolgerungen und Validierung versehen.

Um die Semantik einer bestimmten Modellform festzulegen, ist vor allem zunächst die Modellierungsdomäne zu betrachten. Modelle aus dem Bereich der Anforderungsanalyse (Use Case Modell, Geschäftsprozessmodell, etc.) haben in erster Linie eine fachliche Semantik, d.h. sie bilden die Welt des Anwenders ab. Jedoch kann die Semantik eines Modells auch technischer Natur sein, wenn es z.B. darum geht, Schnittstellen zu entwickeln oder Frameworks zu implementieren. In diesem Falle ist die Zielwelt (Fachdomäne) des Modells eine technische.

Bei der Definition der Semantik sollten folgende Aspekte berücksichtigt werden:

• Definition der Zielwelt (z.B. Unternehmensebene des Kunden, Benutzersicht, technische Sicht, etc.)
• Hieraus abgeleitet die Definition der realen Bedeutung jedes Modellelementes innerhalb der Zielwelt
• Definition des Abstraktionsgrades

Zwei sehr verbreitete Beschreibungssprachen im Bereich der Softwaremodellierung sind XML und UML, wobei XML eine rein textbasierte, UML hingegen eine grafische Beschreibungssprache ist.

Die Unified Modeling Language, kurz UML, ist eine objektorientierte grafische Beschreibungssprache. UML ist vor allem im Bereich der objektorientierten Analyse und Design sehr verbreitet.

Die UML bietet eine Reihe verschiedener Diagrammformen, die in zwei Kategorien unterteilt werden können:

• Statische Diagramme
• Dynamische Diagramme / Verhaltensdiagramme

Inhalt der UML ist eine feste Syntax und eine erste, relativ abstrakt gehaltene Semantik. So existieren in der UML beispielsweise Modellelemente zur Repräsentierung von

• Klassen, Objekten
• Verschiedene Arten von Beziehungen zwischen Klassen
• Status
• Aktivitäten
• Use Cases

Die Semantik dieser Modellelemente ist zunächst noch relativ abstrakt, so dass sich die UML in ihrer Rohform hauptsächlich zur Klassen- und Ablaufmodellierung im Bereich der objektorientierten Programmierung eignet. Die tatsächliche Stärke der UML liegt jedoch in ihrer Erweiterbarkeit. Mit Hilfe von Stereotypes  und Tagged Values  kann das UML Metamodell um eigene Semantik erweitert werden, sodass es die Struktur der Artefakte in einem individuellen Softwareentwicklungsprozess exakt abbilden kann. Diese Fähigkeit macht die UML zu einem mächtigen Werkzeug im Bereich der modellgetrieben Softwareentwicklung.

Auch XML als textuelle Beschreibungssprache findet eine wichtige Rolle in der modellgetriebenen Softwareentwicklung. XML besitzt, im Gegensatz zur UML, zunächst überhaupt keine Semantik. Die Semantik sowie eine weiterführende Grammatik wird einer XML-Datei erst über eine DTD oder ein XML-Schema gegeben.

Bei der Modellierung von Softwareprodukten können XML und UML gleichzeitig eingesetzt werden. Beim Entwurf der Metamodelle für die formale Verwaltung von Projektinformationen muss jedoch jeweils abgewägt werden, welche Notationsform für welche Modellform die geeignetere ist. Einige grundsätzliche Unterschiede zwischen beiden Notationsformen sind:

• UML ist als grafische Beschreibungssprache besser lesbar und intuitiver.
• Aufgrund der fehlenden Semantik ist XML für spezielle Fälle flexibler als UML.
• XML ist bereits ein definiertes Speicherformat und somit direkt automatisiert weiterverarbeitbar.
• XML ist ein reines Textformat und kann somit über jeden einfachen Texteditor formuliert werden. UML Diagramme hingegen benötigen einen grafischen Editor. Die meisten Editoren speichern UML-Diagramme in propritären Dateiformaten, so dass ein UML-Diagramm für die automatische Weiterverarbeitung zunächst in ein Standardaustauschformat exportiert werden muss (siehe unten: XMI)
• Die UML bietet durch ihr semantisches Metamodell bereits einen (Meta-) Modellierungsrahmen, sodass eigene UML-Metamodelle in der Regel einem allgemein verständlichen Standard folgen.

XMI kann als die textuelle (XML-basierte) Repräsentierung der UML verstanden werden. Die OMG hat mit XMI ein XML-Metamodell geschaffen, welches die Semantik und die erweiterte Grammatik der UML auf die Notationsform von XML abbildet. So lässt sich jedes UML-Diagramm in XMI ausdrücken, was eine der wichtigsten Voraussetzung für die automatisierte Weiterverarbeitung von UML-Modellen ist.

Ein entscheidender Vorteil bei der Modellierung auf der Basis von klar definierten Metamodellen ist die Eindeutigkeit und Übersichtlichkeit der in einem formalen Modell beschriebenen Sachverhalte. Mindestens genauso überzeugend ist aber sicherlich noch ein weiterer Aspekt: Modelle sind grundsätzlich transformierbar.

Transformation in diesem Sinne bedeutet, dass ein oder mehrere Modelle in ein anderes Modell automatisiert überführt werden können. Bei dieser Transformation werden Aspekte der Zieldomäne, also des Fachgebiets des Zielmodells, dem ursprünglichen Modell hinzugefügt und für die Zieldomäne irrelevante Aspekte werden herausgefiltert. Grundsätzlich ist für eine Transformation von Modellen die Definition des Metamodells für das Quellmodell wie auch für das Zielmodell zwingend notwendig.

Im Sinne der modellgetriebenen Softwareentwicklung entspricht die Transformation von Modellen der automatisierten Weiterverarbeitung der Artefakte. Die Transformation von einem Artefakt in ein anderes (z.B. auch Code) läuft üblicherweise in zwei Stufen ab:

• Automatisierte Transformation aller transformierbaren (im Quellartefakt vorhandenen) Informationen in die Struktur des Zielmodells
• Manuelle Ergänzung des Zielmodells um die im Quellmodell nicht vorhandenen Informationen

Die eigentliche Arbeit, also die Aktivität im Sinne des Softwareentwicklungs-prozesses, beschränkt sich somit nur auf den zweiten Schritt. Folglich wird redundante Arbeit durch den Transformer erledigt und die Aktivität wird auf die wesentliche Arbeit des Entwicklers oder Systemanalytikers reduziert.

Hieraus ergeben sich folgende Vorteile:

• Reduzierung der Gesamtarbeit durch Automatisierung (Effizienzsteigerung)
• Reduzierung des Fehlerpotentials durch Automatisierung (Qualitätssteigerung)
• Es ist im Zielmodell exakt definiert, welche vom Entwickler noch zu erarbeitende Information an welcher Stelle und in welcher Form notiert werden muss.

Das so entstandene Zielmodell kann innerhalb einer Transformationskette des Softwareentwicklungsprozesses wiederum ein Quellmodell für eine weitere Transformation sein.

Ein klassisches Beispiel für eine Modelltransformation ist die Transformation eines wohldefinierten XML Formates in ein HTML Dokument. Dies geschieht beispielsweise über einen XSL  Transformer (XSLT). So ist es z.B. möglich, ein Modell für einen Use Case zu definieren und das auf das bereits definierte HTML Modell zu transformieren. Dies könnte die vereinfachte Basis für ein Anforderungsdokumentationssystem sein.

Gleichzeitig könnte das Modell des Use Cases aber auch bereits Code für ein definiertes Applikationsframework generieren. Formal gesehen ist eine Programmiersprache in Kombination mit einem Framework ein exakt definiertes Metamodell. Je feiner das Metamodell des Use Case Artefaktes definiert ist, umso mehr Code kann für die Zielplattform generiert werden.