Das Potenzial von Model-driven Software Development (MDSD) ausschöpfen

Modellgetriebene Entwicklung beschleunigt agile Software-Projekte

| Autor / Redakteur: Bernd Linowski * / Florian Karlstetter

Vermeidung von Abfall

Eine der besten Methoden, um die Effizienz von Entwicklungsprozessen zu erhöhen, ist die Vermeidung von "Abfall". Das gilt auch für MDSD. Denn dieses Verfahren bringt zusätzliche Artefakte und Aktivitäten mit sich, die sich mit "Müll" füllen oder selbst als Abfall enden können (siehe Tabelle 1 in der Bildergalerie). Abfall ist alles, was Aufwand oder Kosten verursacht, aber nicht zur Wertschöpfung des Endprodukts beiträgt.

MDSD und schnelle Entwicklung

"Schnelle Entwicklung" heißt bei MDSD, die Zeit zwischen Planung eines Features und dessen Auslieferung zu minimieren. Leider wird bei der Einführung von MDSD oft eine falsche Strategie gewählt die gekennzeichnet ist durch eine Unterscheidung von zwei aufeinanderfolgenden Phasen:

  • 1. MDSD-Prozessentwicklung: Die Entwicklung des Metamodels, DSL und Transformationen und die Integration in den übergeordneten Entwicklungsprozess,
  • 2. MDSD in der Produktion: schnelle und billige Produktion von aus Modellen abgeleiteten Artefakten.

Eine Entwicklungsmethode mit dem vagen Versprechen einzuführen, dass diese später hoch produktiv sein wird, lässt sie jedoch langsam und unflexibel erscheinen. Stattdessen ist folgendes Vorgehen zu empfehlen:

  • Bereits in den ersten Iterationen sollte ein gewisses Maß an Anwendungsfunktionalität produziert werden.
  • Kein "Big Design Upfront", stattdessen die für das gewünschte Feature nötigen Erweiterungen an DSL (Domain-specific Language), Transformationen und Workflows inkrementell zum Bestehenden hinzufügen.
  • Verhindern, dass lange Warteschlangen von Features entstehen, die MDSD unterstützen muss. Wird diese Liste nach dem First-in-First-out-Prinzip abgearbeitet, erhöht sich die Zeitspanne zwischen Anforderung und Auslieferung eines Features.
  • Nur ausnahmsweise einem spät angefordertem Feature Vorrang gewähren. Denn dadurch erhöht sich die Wartezeit der zurückgestellten Features. Das lässt den Produktionsprozess als unberechenbar erscheinen.

Hilfreich ist, die Zahl der sich in Entwicklung befindlichen Features zu begrenzen (Work-in-Progress-Limit). Außerdem sollte die Balance zwischen den Features zur MDSD-Prozessentwicklung und denen zur Anwendungsentwicklung gewahrt bleiben.

Rolle von MDSD und inhärenter Qualität

Mit MDSD die Qualität des Endprodukts verbessern zu wollen, macht wenig Sinn, wenn der MDSD-Prozess nicht selbst höchsten Ansprüchen genügt.

Tabelle 2 zeigt einige Maßnahmen zur Qualitätssicherung für Metamodelle und DSLs sowie den entsprechenden Transformationen, die frühestmöglich umgesetzt werden sollten.

Natürlich gehören automatisierte Tests aller Bausteine eines MDSD-Prozesses (Metamodelle, Transformationen, etc.) zum Sicherheitsnetz. Sie sind ebenso wichtig wie Unit-Tests für Quellcode. Um Risiken zu weiter zu begrenzen, müssen alle Input-Modelle validiert werden, und zwar vom ersten Tage an (siehe Tabelle 3).

MDSD und Generieren von Wissen

Oft wird das Auslagern von Domänenwissen in Modelle als Grund für den Einsatz von MDSD angeführt. Denn Modelle lassen sich auf vielfältige Weise wiederverwenden. Dabei wird oft übersehen, dass sich in einem MDSD-Prozess unterschiedliche Arten von Domänenwissen niederschlagen. Da die Repräsentation von Wissen aus der Quelldomäne durch Modelle eine Prämisse von MDSD ist, wird dieser viel Aufmerksamkeit geschenkt.

Dagegen wird die Repräsentation von Meta-Wissen über die Domäne oft stiefmütterlich behandelt. Es fehlen beispielsweise häufig Informationen, warum etwas auf eine bestimmte Weise modelliert wurde. Das Wissen, das sich in Transformationen oder Workflows niederschlägt, bleibt so hinter technischen Details verborgen. Daher enden MDSD-Projekte nicht selten als "Black-Box": Nach kurzer Zeit findet sich niemand mehr, der sie an geänderte Anforderungen anpassen kann.

Know-how nutzbar machen

Daher sollte zunächst alles verfügbare Wissen über Quell- und Ziel-Domäne zusammengetragen werden. Sind DSLs, Metamodelle oder Erweiterungen von etablierten Sprachen wie UML-Profile neu zu entwickeln, ist das Ausloten von Alternativen essenziell. Zudem ist es empfehlenswert, die Entwürfe neuer Metamodelle und die darauf aufbauenden Transformationen in der Praxis zu erproben. Dies liefert Hinweise auf die Praktikabilität. Denn DSLs, die zwar mit der deklarativen Darstellung des Domänenwissens brillieren, deren Instanz-Dokumente jedoch schwer zu verarbeiten oder zu pflegen sind, können sich als unbrauchbar erweisen.

Schließlich sollte das Sprach- beziehungsweise Metamodelldesign als Teamaufgabe betrachtet werden. Metamodelle und DSLs sind nicht zuletzt Mittel der Verständigung. Eine Gruppe von Designern kann viel besser als ein einzelner Fachmann beurteilen, wie gut diese ihren Zweck erfüllen.

weiter mit: Effizienter Know-how-Transfer

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 31342380 / Entwicklung)