Bei einem früheren Kunden erlaubte sich ein englischsprachiger Mitarbeiter einen kleinen Scherz: er bezeichnete die Kollegen, die sich mit UML-Modellierung beschäftigten, als „The Art Department“ (eine eigene Abteilung für diese „Künstler“ gab es dort allerdings nicht – zum Glück, wie ich finde).

Auch wenn er das wie gesagt nicht ganz ernst meinte, kommen in seinen Worten doch zwei Vorstellungen zum Ausdruck, denen ich seitdem immer wieder begegnet bin.

Die erste Vorstellung ist: wenn von Modellierung die Rede ist, insbesondere mit Standardnotationen wie UML, SysML oder BPMN, dann geht es in erster Linie darum, Sachverhalte graphisch zu illustrieren (zum Beispiel, um ein gemeinsames Verständnis von Anforderungen in einem Team zu erreichen). Ich stimme dem – zumindestens in dieser Verallgemeinerung – nicht zu. Warum, werde ich gleich erklären.

Die zweite Vorstellung, die man mit etwas Phantasie zwischen den Zeilen lesen kann, ist: die Modellierer sind Künstler, aber die „wahre Arbeit“ wird von anderen Leuten mit mehr Bodenhaftung gemacht.

Zu beiden Vorstellungen kann ich das Gleiche sagen: es stimmt zwar, dass es sinnvoll sein kann, graphische Modellierungsnotationen einzusetzen, um ad hoc Sachverhalte zu klären. Oft sind dafür sogar Skizzen auf einem Flipchart geeignet. Damit sind die Möglichkeiten, die der Einsatz von Modellen bietet, aber bei weitem nicht erschöpft.

Benutzt man zum Beispiel ein UML-Modellierungswerkzeug, dann erstellt man in der Regel UML-Diagramme. Anders als bei Werkzeugen wie Visio erstellt man mit den Diagrammen – im Hintergrund – aber ein UML-Modell, das einen wertvollen Informationsspeicher darstellt, der nahezu beliebig ausgewertet werden kann, unter anderem:

  • zur automatischen Prüfung der Spezifikationskonsistenz (zum Beispiel: wurden für alle Ein- und Ausgabedaten einer Funktion auch eine entspreche Datenklasse beschrieben) ?
  • zum Erzeugen von Spezifikationsdokumenten
  • zum Erzeugen von Projektstatusberichten
  • zur Codegenerierung
  • zur Simulation usw.

Betrachtet man ein Modell unter diesem Blickwinkel, kommt man zu weiteren Erkenntnissen:

1. Für den Einsatz von Modellierungssprachen wie UML ist die graphische Repräsentation – das Art Department – nicht zwangsläufig erforderlich. Es sind also durchaus Werkzeuge denkbar (und auch vorhanden), die das Editieren von Modellen mit graphischer Notation möglich machen, ohne dass der Benutzer ein einziges Diagramm erstellen muss.

Ich persönlich finde es sehr bedauerlich, dass die UML-Werkzeuge, die heute den Markt dominieren, nicht im Sinne der Benutzerfreundlichkeit neue Wege beschreiten, und zum Beispiel das automatisierte Erzeugen und Layouten von Diagrammen aus textuellen Spezifikationen oder über domänenspezifische Wizards unterstützen – technisch ist das kein Problem mehr.

2. Eine große Stärke von Modellen, im Vergleich etwa zur textuellen Spezifikation von Anforderungen, besteht in der definierten Verbindung von Sichten, beispielsweise des Systemverhaltens mit dem Datenmodell. Von dieser Stärke wird aber nur derjenige profitieren können, der gezielt die Fähigkeiten von Werkzeugen nutzt, statt beispielsweise nur per Copy und Paste einzelne Diagramme in textuelle Spezifikationsdokumente einzufügen.

Die Bodenhaftung stellt man her, indem man Modelle konkret in Projekten verwendet, statt sie nur in einem Modell-Repository als „Datensarg“ zu speichern. Um den Projektteilnehmern das Verständnis der Modelle zu erleichtern, liegt eine drastische Reduktion der verwendeten Modellelemente auf das absolut Notwendige nahe. Um zu wissen, was notwendig ist, sollte der Einsatzzweck für die Modelle früh festgelegt werden. Folgender Blogbeitrag liefert eine Klassifizierung als Entscheidungshilfe: http://blog.hood-group.com/blog/2012/03/27/wie-viel-formalisierung-benotigt-ein-modell/