Wenn wir uns die Entwicklung der Diskussion in der IT-Gemeinde über Modellierung und Modelle in den vergangenen Jahren – sogar Jahrzehnten – betrachten, dann wird ganz deutlich, dass unsere doch anscheinend so rationale Szene auch hochgradig von Mode und Zeitgeist geprägt wird. Immer neue Modellierungstrends sind entstanden und teilweise auch wieder verschwunden.

Mit den Datenbanken haben vor langer Zeit Datenmodelle in die IT Einzug gehalten und diese waren aus der real existierenden Anwendungsentwicklung der 80er Jahre kaum wegzudenken. Sogar Unternehmensdatenmodelle wurden propagiert und die IT damit im Gesamtunternehmen strategisch geadelt. Daneben entstand eine erste Software-Guru-Szene mit Persönlichkeiten wie Tom DeMarco und Ed Yourdon, die Datenflussmodelle der Strukturierten Analyse predigten. Zumindest die Modelle der Strukturierten Analyse sind inzwischen aber IT-Geschichte…

Die neunziger Jahre waren von objektorientierten Modellen und ihren neuen Päpsten wie Grady Booch,  Ivar Jacobson und James Rumbaugh, geprägt. Die Unified Modeling Language war das kristallisierte Ergebnis dieser Epoche und wirkt bis heute nachhaltig auf unsere Arbeit. Die Verwendung von UML ist heute offensichtlich geübte Praxis. Umso wertvoller empfinde ich den Artikel von Gabriele Taentzer und Thorsten Arendt, in dem sie praktische Tipps für die QS von UML-Modellen geben.

Einen Höhepunkt der objektorientierten Modellierung haben wir dann seit Anfang dieses Jahrtausends mit den Ansätzen der Model Driven Architecture erlebt, die die alte Vision wiederbelebt haben, dass man aus Modellen Software generieren kann. Und dieser Ansatz für Softwareentwicklung ist auch heute noch weit verbreitet, auch wenn nicht ganz so lautstark darüber berichtet wird, wie über aktuelle Hype-Themen. Benedikt von Treskow hat in diesem Heft einen wirklich guten Erfahrungsbericht geschrieben und Daniela Schilling geht sogar noch einen Schritt weiter, wenn sie ihren Generator-Generator mit dem Ziel der Entmystifizierung des modellgetriebenen Designs vorstellt.

Parallel zu diesen Modellen hat die Modellierung von Geschäftsprozessen immer mehr Fahrt aufgenommen. Einen ersten Schub bekam das Thema dadurch, dass Prof. Scheer vor den erfolgreichen Einsatz von SAP-Standardsoftware die Modellierung von Prozessketten gesetzt hat. Es gibt immer noch Erweiterungen von Prozessmodellierungsansätzen, im Sinne der Standardisierung spielt aber gewiss BPMN eine immer größere Rolle.

Der aktuelle Zeitgeist, der ja wesentlich durch agile Softwareentwicklung beeinflusst ist, schiebt Modelle nun immer häufiger in die Ecke der zu schwergewichtigen Entwicklung. Ist das der Anfang vom Ende der Modellierung in der Anwendungsentwicklung? Kann man einen roten Faden in dieser Modell-Geschichte erkennen? Oder sind es wirklich nur sich mehr oder weniger wiederholende Moden?

Fangen wir mal mit der Frage an, wozu Modellierung eigentlich dienen soll. Modelle dienen ja definitionsgemäß der Abstraktion, sei es der Abstraktion und Formalisierung von fachlichen Anforderungen und damit zur besseren Kommunikation zwischen Anwendern bzw. Auftraggebern und den Entwicklern, oder der Abstraktion im Sinne einer architekturellen Strukturierung oder sogar der Generierung von Anwendungssystemen.  Aber für all diese Ziele sind Modelle nicht unumstritten oder ohne Alternative.

Sowohl die objektorientierte Modellierung als auch die Geschäftsprozessmodellierung haben sich das Ziel der besseren Kommunikation mit dem Auftraggeber auf ihre Fahnen geschrieben. Die objektorientierten Modelle haben diesen Anspruch nicht immer erfüllt. Genau in diesem Punkt wird die UML-Verwendung in agilen Projektkontexten oft als Verschwendung empfunden, wenn die Modelle keinen direkten Nutzen für die Anwender darstellen, sondern nur als Übergabe-Artefakt  zwischen zwei Entwicklungsphasen dient. Hier wird in agilen Projekten die direkte und persönliche Kommunikation zwischen Fachleuten und Entwicklern in kurzen Iterationen bevorzugt.

Zur Kommunikation zwischen Fachbereich und Entwicklung scheinen Prozessmodelle besser geeignet zu sein. Sie können auch einen fachlichen Rahmen um agile Anforderungen bilden, die in User Stories formuliert werden und damit nicht nur das System aus Anwendersicht dokumentieren, sondern auch wesentliche Orientierungs- und Strukturierungshilfe geben. Und in manchen Werkzeug-getriebenen Ansätzen wird auch hier Software für automatisierte Workflows aus Prozessmodellen generiert.

Für die Strukturierung (und damit auch zur Dokumentation) komplexer Softwaresysteme hat sich UML in ihrer Tradition der Daten- und Funktionsabstraktion wirklich bewährt und es gibt meiner Meinung nach auch keine wirkliche Alternative dazu, auch wenn Martin Fowler öffentlich wirksam forderte, dass zur Dokumentation eigentlich guter Code ausreichen sollte. Die zwischenzeitlich fast religiöse Diskussion darum hat er selbst entschärft, indem er den Nutzen von Modellen gerade zur Strukturierung komplexer Systeme einräumt.

Ich habe die Hoffnung, dass die IT sich trotz der Hype-Wellen, die regelmäßig über sie hinweg rollen, immer mehr von modischen Trends emanzipiert. Wir können lernen, dass es keine „Weltformel“ für alle Probleme in der Anwendungsentwicklung gibt, sondern dass wir für die jeweiligen Aufgaben adäquate Verfahren, Artefakte und Werkzeuge wählen. Es ist auf jeden Fall erkennbar, dass wir die Tool-Gläubigkeit in der Softwareentwicklung mehr und mehr durch handwerklich saubere Arbeit sowohl in der Spezifikation und Modellierung als auch in der Programmierung ersetzen. Gutes Handwerk braucht gute Ausbildung und Nutzen von Erfahrungen. Wir müssen auch nicht mit schwergewichtigen Kanonen auf leichtgewichtige Spatzen schießen, aber gerade in großen und komplexen Systemen werden wir auf die guten Erfahrungen, die wir in den letzten Jahrzehnten mit Architekturen und Modellen gemacht haben, nicht verzichten können.

Autor: Dr. Thorsten Janning