Model-driven Software Development

MDSD beschleunigt agile Software-Projekte

| Autor / Redakteur: Bernd Linowski * / Florian Karlstetter

Bernd Linowski, Architekturberater bei Tata Consultancy Services (TCS).
Bernd Linowski, Architekturberater bei Tata Consultancy Services (TCS). (Bild: Tata Consultancy Services)

„Model-driven Software Development“ gilt oft als schwerfällig. Dabei kann auch die agile Entwicklung von MDSD profitieren, sofern man die Prinzipien der „Lean Production“ aus der Fertigungsindustrie auf ein Software-Projekt überträgt.

Schlanke Produktionsprozesse („Lean Production“) haben ihren Ursprung im Toyota Production System. Statt große Mengen von Fahrzeugen auf Halde zu produzieren, stellt Toyota nur so viele Autos her, wie nachgefragt werden („Just-in-Time“). Um die Kosten niedrig zu halten, reduziert der Hersteller zudem Abfall jeder Art, und eine durchgängig hohe Qualität verringert den Ausschuss. Außerdem hält Toyota seine Mitarbeiter dazu an, ständig zur Verbesserung des Produktionsprozesses beizutragen.

Lean Production lässt sich durchaus auf die Software-Entwicklung übertragen, auch auf Model-driven Software Development (MDSD). Allerdings gibt es Unterschiede zwischen industrieller Produktion und Software-Entwicklung: Letztere ist ein Designprozess, der Informationen produziert, die nahezu ohne weitere Kosten repliziert werden können. Dies verschiebt den Fokus vom Produktionsprozess hin zu einem Produktdesignprozess. Allerdings hat MDSD eine Sonderstellung: Es legt höheres Gewicht auf Produktionsprozesse und das damit verbundene Prozessdesign.

So sind Sprach- oder Metamodell-Design und das Entwickeln von Transformationen, welche die Artefakte aus den entsprechenden Modellen generieren, ein wichtiger Bestandteil von MDSD. Gleiches gilt für das Erstellen von Workflows, mit denen sich Artefakte erzeugen und in einen Build-Prozess einbinden lassen. MDSD ähnelt somit industriellen Produktionsprozessen. Dadurch können auch die negativen Eigenschaften solcher Prozesse auftreten, etwa hohe Anfangsinvestitionen und die Tatsache, dass sich Prozesse im Nachhinein schwer ändern lassen.

Model-driven Software Development agil betreiben

Prinzipien der „Lean Production“ werden bereits in der Software-Entwicklung angewendet, etwa bei agilen Entwicklungsmethoden wie Scrum oder XP. MDSD gilt im Vergleich dazu als schwerfällig. Um der wachsenden Nachfrage nach agiler Entwicklung gerecht zu werden, muss MDSD daher selbst agil betrieben werden.

Im Folgenden werden folgende Prinzipen von Lean Production auf ihre Tauglichkeit für MDSD untersucht:

  • Vermeidung von Abfall
  • schnelle Entwicklung
  • inhärente Qualität
  • Gewinnen von Wissen
  • Optimierung

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.

Effizienter Know-how-Transfer

Die Herausforderung besteht darin, das gewonnene Wissen wiederverwendbar zu machen. Folgende Maßnahmen helfen dabei:

  • Dokumentation als integralen Bestandteil von Metamodell, DSL und Transformationen betrachten: Ähnlich wie bei JavaDoc sollte die Dokumentation parallel zu den genannten Komponenten erstellt werden. Denn die Halbwertszeit von Wissen ist oft extrem kurz.
  • Wissen gemeinsam dokumentieren.
  • "Kochbuch“ erstellen: Die größte Herausforderung bei MDSD besteht darin, herauszufinden, mit welchen Mitteln man welche Resultate erzielt. Hilfreich ist ein Rezeptbuch das typische Problemstellungen aus der Anwendungsdomäne behandelt.
  • Anleitungen kurz halten: Erfahrungsgemäß schwindet der Nutzen eines Dokuments, je voluminöser es ist.

Optimierung des Ganzen

Mary und Tom Popendieck stellen in ihrem Werk „Implementing Lean Software Development“ fest: „Brillante Produkte entstehen durch die Kombination von günstiger Gelegenheit und Technik“. Das gilt auch für die modellorientierte Entwicklung. Zwar ist Technik ein wichtiger Aspekt; oftmals führt jedoch die Fehleinschätzung von potenziellen Anwendungsfeldern dazu, dass MDSD nur unzureichend zur Optimierung des Ganzen beiträgt.

Kennzeichen einer „günstigen Gelegenheit“ sind:

Inhärente Komplexität: Eine Tätigkeit leistet dann einen wichtigen Beitrag zur Schaffung eines Endprodukts, wenn sie ein erhebliches Maß an mentaler Anstrengung erfordert. In diesem Sinne sollte sich auch MDSD der zentralen Probleme annehmen. Das vermeintliche Musterbeispiel für MDSD, das Generieren großer Mengen von „Boilerplate Code", adressiert dagegen eher eine unbeabsichtigte Komplexität und trägt nur bedingt zur Wertschöpfung bei.

Relevanz: Könnte man die Ergebnisse, die ein MDSD-Prozess liefert, auch weglassen, besteht die Gefahr, dass MDSD als zu komplex oder zu teuer eingestuft wird.

Häufigkeit: Sind während der Entwicklung eines Produktreleases nur wenige Male Artefakte aus Modellen abzuleiten, sollte man den Einsatzvon MDSD hinterfragen.

Ausmaß: Oft sind es die Menge der zu verarbeitenden Informationenoder die große Zahl der zu generierenden Artefakte, die den Einsatz von MDSD rechtfertigen. Bis zu einem gewissen Grad kann das Ausmaß einer Aufgabe mangelnde inhärente Komplexität kompensieren. Das gilt jedoch nicht für fehlende Relevanz oder Häufigkeit.

Da Software-Produktionsprozesse heute meist unter wirtschaftlichen Aspekten bewertet werden, sollte das volle Optimierungspotenzial von MDSD ausgeschöpft werden:

  • MDSD kann den Koordinationsaufwand verringern, etwa durch systemübergreifendes Bereitstellen von kompatiblen Artfakten. Insellösungen sind von zweifelhaftem Wert.
  • MDSD kann helfen, ein Endprodukt breit und flexibel einsetzbar zu machen. Das gelingt jedoch nur, wenn die Belange der Anwendungsfunktionen und der technischen Infrastruktur auch in den Bausteinen der MDSD-Lösung entkoppelt sind.
  • MDSD sollte stets so umgesetzt werden, dass alle Teilbereiche des Entwicklungsprozesses davon profitieren, inklusive Testen oder Installation. Denn kaum etwas ist der Optimierung so abträglich wie ein MDSD-Prozess, der neben vielen Artefakten auch viel Arbeit mit sich bringt, die manuell zu erledigen ist.

Modellgetriebe Entwicklung kann somit nicht nur agil und schlank betrieben werden, sie sollte es sogar unbedingt – denn nur so lässt sich ihr volles Potenzial ausschöpfen.

* Der Dimplom-Informatiker Bernd Linowski ist als Architekturberater bei Tata Consultancy Services (TCS) tätig.

Kommentare werden geladen....

Kommentar zu diesem Artikel

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: 44365195 / Agile Entwicklung)