Modellbasiert entwickeln

„Das Modell beschreibt den Kern der Problemlösung ohne den Ballast der spezifischen technischen Domäne“

Modellbasierte Softwareentwicklung ermöglicht den Fokus auf das Lösen des eigentlichen Problems, statt sich um Details einer technischen Domäne kümmern zu müssen. Aussagekräftige Visualisierung schafft auch in einem heterogenen Team eine Basis für eine produktive Kommunikation. Das Modell sichert darüber hinaus seinen Wert – auch wenn sich die technische Domäne ändert.

Durch angepasste SourceCode-Generatoren werden Modelle in SourceCode übersetzt. Der generierte SourceCode kann dann wiederum übersetzt und als ausführbares Programm zur Anwendung gebracht werden. Änderungen in der technischen Domäne können durch Anpassung der SourceCode-Generierung umgesetzt werden – und alle Modell werden automatisch für das neue Umfeld übersetzt.

Modellbasierte Entwicklung gibt es schon länger. Auch wenn im allgemeinen typische Programmiersprachen wie C/C++, Java, Python, etc. nicht als Modell betrachtet werden, so sind selbst sie genau genommen Modelle. Im Allgemeinen verbindet man aber mit Modellen eher die Problemlösung in Form von UML- oder BPMN-Diagrammen, bzw. anderen grafischen Notationen.

Der Kerngedanke hinter der modellbasierten Entwicklung ist jedoch, die Problemlösung vollständig innerhalb eines Modells abzubilden und das Modell in eine oder mehrere technische Domänen abbilden zu können.

UML z.B. lässt sich sowohl in verschiedene Sprachen, als auch auf verschiedene technische Plattformen mittels geeigneter Generatoren transformieren. Im Rahmen der Transformation werden die für die technische Domäne notwendigen Informationen über z.B. das Sprachsyntax ergänzt.

Ein anderes Beispiel ist Mathlab/Simulink, das z.B. in der Automobilentwicklung gerne eingesetzt wird um die Software der Fahrzeugsteuerung zu entwickeln und zu testen.

Was macht modellbasierte Entwicklung für die Softwareentwicklung so interessant …

• das Modell beschränkt sich auf die wesentlichen Informationen. Das Modell eines Dialogsystems muss beschreiben, welche Dialoge mit welchen Elementen wie interagieren sollen, jedoch nicht, wie diese Dialoge dann z.B. in Java mit SWT oder unter Windows mit WPF realisiert werden.
• das Modell ist somit gewissermaßen zeitlos. D.h. die Lösung die das Modell für ein Problem darstellt, ist solange valide bis eine bessere Lösung gefunden ist.
• wenn Modelle eine verständliche Notation verwenden, z.B. Prozessdiagramme mit BPMN, dann können sie auch leicht von Stakeholdern ohne Kenntnisse einer Programmiersprache verstanden werden. D.h. die Partizipation aller Stakeholder wird erhöht und Fehler beim Wissenstransfer werden reduziert.
• Modelle können mittels Generatoren transformiert werden. Z.B. ein Generator um aus einem Modell eine Windows-Anwendung zu generieren und ein anderer, um daraus eine Web-Anwendung zu machen.
• Generatoren sind losgelöst von konkreten Problemlösungen, sondern dienen zum Transformieren von Modellen einer definierten Notation. Damit lassen sich Generatoren zum Einen im Rahmen eines eigenen Projekts realisieren und sind somit von einem konkreten Problem entkoppelt. Zum Anderen können Generatoren natürlich auch dazu genutzt werden um mehr als ein Modell zu transformieren.

Eigentlich überzeugende Argumente die für eine modellbasierte Entwicklung sprechen.

Warum hat man aber das Gefühl, das modellbasierte Entwicklung nicht so verbreitet ist, wie man es erwarten sollte?

Das hat aus meiner Sicht folgende Gründe:

• schaut man sich die IT Welt an, so liegt der Fokus häufig auf dem Bereich der Programmiersprache und weniger in der bewussten Modellierung. D.h. in der Praxis ist es immer noch wahrscheinlicher das ein Entwickler eine Programmiersprache beherrscht als das er fit in Modellierungssprachen ist. In der Konsequenz wird dann also i.A. auf das zurück gegriffen, was man kennt … also die direkte Programmierung. Indirekt sehe ich persönlich auch darin die Ursache für das weit verbreitete „Code first … document later (or never)“ Problem.
• Software im Bereich der modellbasierten Entwicklung ist meistens teuer oder schlecht oder beides. Und es ist ja nicht damit getan nur ein Modellierungswerkzeug zu haben. Das Modell muss ja mittels der SourceCode-Generierung verarbeitet werden und damit in eine oft mittels CI/CD automatisierte Welt integriert werden.
• Wer Generatoren schreibt hat aus die Möglichkeit die Modellierungssprache zu definieren. Der Vorteil über die Modellierungssprache den Fokus auf das zu legen, was als Problemlösung über das Modell ausgedrückt werden soll, beinhaltet auch den Nachteil, das die Verlockung da ist, eben für jedes Problem eine eigene Sprache zur Modellierung zu schaffen.

Sollte man deshalb aus modellbasierte Entwicklung verzichten?

Ganz klar nein!

Ein wesentlicher Vorteil der modellbasierten Entwicklung ist die Möglichkeit zu skalieren. D.h. wenn es das Geschäftsmodell hergibt einen Generator mehr als einmal einzusetzen, wird die Sache wirtschaftlich interessant – sofern sich der wesentliche Arbeitsanteil mit jedem weiteren Projekt primär auf das modellieren beschränkt und der damit verbundene Aufwand kleiner ist als der einer „klassischen Softwareentwicklung“.

Aber man sollte ein paar Punkte beachten:

• Arbeitsteilung ist Trumpf – „Modellierer“ modellieren und „Programmierer“ schreiben die Generatoren. Jede der Tätigkeiten benötigt andere Skills. Das Trennen der Aufgaben erlaubt das vertiefen der Skills und in der Kombination ein besseres Ergebnis.
• Generatoren und Modellsprachen sind mit genau der selben Sorgfalt zu betrachten, wie jedes andere Projekt auch. D.h. wenn die Qualität der Generatoren schlecht ist, wird das aus dem Modell generierte Ergebnis wahrscheinlich auch nicht so toll sein. Wenn die Modellsprache nicht dokumentiert ist, ist es eine tote Sprache.
• Sorgfältig planen welche Modellsprachen und welche Generatoren benötigt werden. Kurzum: die Modellsprachen müssen geeignet sein die Problemlösungen vollständig im Rahmen der Modellierung abzubilden. UML z.B. ist gut geeignet um Kassendiagramme abzubilden, aber haben Sie schon mal versucht damit ein Geschäftsprozess oder ein Dialogsystem zu modellieren? Generatoren auf der anderen Seite müssen das Modell transformieren können ohne das am Ende doch wieder programmiert werden muss. Wenn der Generator nur Code-Fragmente erzeugt, die manuell gefüllt werden müssen und im Zweifelsfall mittels Copy&Paste auch einfach ohne Generator erzeugt werden können, dann lohnt der Aufwand für einen Generator nicht.

Also viel Spaß beim modellbasierten entwickeln.