Lean ist in

MDSD und innewohnende Qualität

Zweifellos kann MDSD dazu benutzt werden, um den Qualitätsstandard einer Anwendung zu erhöhen [5]. Allerdings hat es wenig Sinn zu versuchen, die Qualität des Endprodukts zu verbessern, wenn der MDSD-Prozess nicht selbst höchsten Qualitätsansprüchen genügt. Tabelle 2 enthält eine kleine Auswahl von Maßnahmen zur Qualitätssicherung für Metamodelle und DSLs sowie den auf ihnen operierenden Transformationen. Diese Maßnahmen sollten so früh wie möglich umgesetzt und, wenn möglich, sogar automatisiert werden. Qualität muss von Anfang an „eingebaut“ werden. Neben Metamodellen und Transformationen muss auch jedes Inputmodell einer Validierung unterzogen werden, und zwar vom ersten Tag an. Denn wer das Validieren der Inputmodelle ignoriert oder nachlässig betreibt, spielt mit dem Feuer. Welche Probleme auftauchen können, wenn man Modelle nicht oder nur unzureichend validiert, beschreibt die kleine Liste des Schreckens in Tabelle 3.

Tabelle 2: Qualitätssicherungsmaßnahmen für den MDSD-Prozess

Maßnahmen zur Qualitätssicherung
Metamodell/DSL Komplexität vermeiden: Komplexe Metamodelle oder DSLs sind oftmals schwer zu verstehen und daher nur mühsam verwendbar.

Verständlichkeit prüfen: Versteht die Zielgruppe das Metamodel oder die DSL? Spricht es/sie ihre Sprache?

Semantik präzisieren: Missverständliche Semantik führt zu irritierten Benutzern und Fehlern in der Modellierung.

Effizienz überprüfen: Typische Anwendungsfälle müssen mit wenig Aufwand ausgedrückt werden können.

Nützlichkeit evaluieren: Existierende Sprachfeatures müssen abgeschlossen und aus sich heraus nützlich sein.

Erweiterbarkeit sicherstellen: Es sollte sich am Bestehenden nichts ändern, wenn etwas neues hinzukommt.

Semantische Validierung: Semantisch fehlerhafte Modelle müssen erkannt und zurückgewiesen werden.

Referenzmodelle: Metamodelle sollten immer anhand von essenziellen Anwendungsfällen aus der Domäne geprüft werden.

Validierungstestmodelle: Auch die Validierung muss mit Modellen getestet werden, die typische oder kritische Fehler enthalten.

Transformationen Deklarativ vor Imperativ: Wenn irgend möglich, spezifiziere man, was getan werden muss, statt selbst das Wie zu implementieren.

Validieren vor Transformieren: Nur korrekte Modelle dürfen transformiert werden.

Auf bewährten Lösungen aufbauen: Transformationen beruhen auf einer bewährten Referenzimplementierung aus der Zieldomäne.

Scheitere früh und sicher: Unvollständige oder fehlerhafte Transformationsprodukte dürfen nicht den nächsten Schritt der Produktionskette erreichen.

Referenzartefakte: Die Korrektheit der Transformationen wird durch Vergleich mit Referenzartefakten gesichert.

Integration sicherstellen: Die Interaktion generierter Artefakte mit der Umgebung muss getestet werden.

Tabelle 3: Fehlverhalten und Effekte

Fehlverhalten Effekt
Keine Validierung Modelle, die nur teilweise oder gar nicht verarbeitet werden können

Fehler im laufenden System

Ein laufendes System, das falsche Ergebnisse produziert

Nachträglich eingeführte
Validierung
Fehlschlagende Unit und Integration Tests

Umfangreiche Korrekturen an bestehenden Modellen

Redesign von Transformationen oder manuell erstelltem Code

Nicht getestete
Validierung
Risiko eines späten Eintretens der Effekte fehlender oder nachträglich eingeführter Validierung

Automatisierte Modellvalidierung und Tests aller Bausteine gehören zum Sicherheitsnetz eines MDSD-Prozesses. Sie sollten daher dieselbe Wertschätzung genießen wie Unit Tests für Quellcode.

MDSD und die Gewinnung von Wissen

Das Auslagern von Domänenwissen in Modelle wird oft als Grund für den Einsatz von MDSD angeführt, sind Modelle doch vielfältig wiederverwendbar. Dabei wird oft übersehen, dass sich in einem MDSD-Prozess ganz unterschiedliche Arten von Domänenwissen niederschlagen (Abb. 1). Da die Repräsentation von Wissen aus der Quelldomäne durch Modelle eine Prämisse von MDSD ist, wird dieser zwangsläufig viel Aufmerksamkeit geschenkt. Die Repräsentation von Metawissen über die Domäne wird jedoch oft stiefmütterlich oder einseitig behandelt (viel Referenzdokumentation, keine Hintergrundinformationen, warum etwas so und nicht anders modelliert wird; kaum eine Darstellung von Zusammenhängen). Das Wissen, das sich in Transformationen oder Workflows niederschlägt, bleibt oftmals verborgen hinter technischen Details. Daher enden MDSD-Projekte nicht selten als Blackboxlösung. Da sich bald niemand mehr findet, der Projekte neuen Anforderungen anpassen kann, schwindet ihr Wert mit der Zeit. Für einen nachhaltigen Erfolg modellgetriebener Entwicklungsprozesse ist es daher wichtig, alle Formen von Wissen angemessen zu repräsentieren und nutzbar zu machen.

Abb. 1: Arten von Domänenwissen

Doch zuerst sollte man versuchen, so viel Wissen über Quell- und Zieldomäne wie irgend möglich zu erlangen. Derartiges Wissen ist eine notwendige Voraussetzung, um eine erfolgreiche MDSD-Lösung zu erschaffen.

Sind DSLs, Metamodelle oder Erweiterungen von etablierten Sprachen (z. B. UML-Profile) neu zu entwickeln, ist das Ausloten verschiedener Alternativen essenziell. Nur wenn man sich zugesteht, auch erst einmal Fehler zu machen, lernt man, welche Aspekte über das Wohl und Weh einer Sprache entscheiden und in welcher Form die Domäne von den eigenen Erwartungen abweicht. Wer nur auf ausgetretenen Pfaden wandelt, schafft kein neues Wissen. Das praktische Erproben von Entwürfen für neue Metamodelle und darauf aufbauenden Transformationen ist ebenfalls sehr zu empfehlen, erfährt man doch so einiges über die Praktikabilität dieser Bausteine. DSLs, die zwar in der deklarativen Darstellung des Domänenwissens brillieren, deren Instanzdokumente jedoch schwer zu verarbeiten oder zu pflegen sind, können sich letztendlich als unbrauchbar herausstellen. Schließlich sollte man Sprach- beziehungsweise Metamodelldesign als Teamaufgabe betrachten. Metamodelle und DSLs sind nicht zuletzt Mittel der Verständigung. Eine Gruppe kann viel besser beurteilen, wie gut sie diesen Zweck erfüllt, als das es ein „einsamer Designer“ je tun könnte. Wie andernorts liegt auch hier die zentrale Herausforderung darin, das gewonnene Wissen fassbar und wiederverwendbar zu machen. Die folgenden Maßnahmen helfen dabei:

  • Die Dokumentation muss als integraler Bestandteil von Metamodell, DSL und Transformationen begriffen werden (ähnlich wie bei JavaDoc). Sie muss daher auch zeitgleich erstellt werden, schließlich ist die Halbwertszeit von Wissen oft kurz.
  • Das Festhalten von Wissen ist eine Gemeinschaftsaufgabe, an der sich jeder beteiligen sollte.
  • Für den Benutzer einer MDSD-Lösung ist es oftmals die größte Herausforderung, zu verstehen, mit welchen Mitteln man welche Resultate erzielt. Daher sollte es eine Art von Kochbuch geben, das typische Problemstellungen aus der Anwendungsdomäne behandelt.
  • Man vermeide es, lange Epen zu produzieren. Die Erfahrung lehrt, dass die Nützlichkeit einer Anleitung umgekehrt proportional zu ihrer Länge ist.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.