Meine Themen: Anforderungen, Anwendungslandschaften und Architekturen.

Wie selbstverständlich setzen Business-Analysten, Requirements Engineers und Softwareentwickler grafische Modelle ein, um zu beschreiben, was ein Softwaresystem für seine Benutzer leisten soll. Doch warum eigentlich? Weil meiner Meinung nach viele eine idealisierte Vorstellung davon haben, was Modelle leisten können:

  • “Modelle bilden doch die Realität ab!”
  • “Mit Modellen kann ich Software vollständig beschreiben.”
  • “Modelle sind eindeutig interpretierbar.”

Für triviale Fälle, bestimmte Anwendungsgebiete und Modellierungssprachen mag dies richtig sein. Nicht aber, wenn Sie modellieren wollen, wie sich Unternehmenssoftware in eine Anwendungslandschaft integriert oder wie Geschäftsprozesse von dieser Software unterstützt werden. Ich modelliere solche Anwendungsfälle für unsere Kunden und habe dabei festgestellt, dass Modellierung häufig missverstanden wird. In diesem und folgenden Beiträgen habe ich einige Missverständnisse für Sie gesammelt:

Ein Bild sagt mehr als tausend Worte?

Bilder und grafische Modelle sind ausdrucksmächtiger als Text. Sie stellen dar, was sich textuell nur schwer beschreiben lässt. Trotzdem sagt ein Bild nicht mehr als tausend Worte. Ich denke, „ein Bild abstrahiert tausend Worte“ kommt der Wahrheit schon näher. Denn in der Abstraktion eines Künstlers und der Interpretation durch einen Betrachter liegt der künstlerische Reiz von Bildern. Darin liegt aber auch das Problem mit grafischen Modellen: Der Betrachter des Modells muss nämlich entscheiden, welche tausend Worte er hineininterpretiert.

Standards garantieren Verständlichkeit?

Wie verringert man als Modellierer den Interpretationsspielraum von Modellen? Indem man sich an eine standardisierte Notation hält: Ein Modellierer, der verstanden werden will, sollte eine Notation wählen, die verstanden wird. Das ist jedoch zu kurz gedacht.
Zwar ist es meist besser, eine bestehende Notation zu verwenden, als sich ad-hoc eine auszudenken. Aber auch standardisierte Notationen bieten viel Spielraum, um Informationen missverständlich darzustellen. Lassen Sie einen realen Geschäftsprozess von mehreren Personen in derselben, standardisierten Notation modellieren. Die Modelle werden sich nicht nur optisch, sondern auch inhaltlich unterscheiden.

Wer die Notation beherrscht, kann modellieren?

Eine Notation allein kann keine verständlichen Modelle garantieren. Trotzdem sieht man es in Schulungen und Handbüchern immer wieder: Es wird eine Notation vermitteln, aber nicht ihre Anwendung. Viele Notationen haben gar keine begleitende Methodik. Bekannte Beispiele sind UML und BPMN. Aber wo kommen die Informationen für die Modelle her? Was kommt ins Modell, was lasse ich weg? Wie validiere ich das Modell? Nach welcher Methodik man modelliert, bleibt einem in der Regel selbst überlassen.

In den weiteren Teilen dieser kleinen Serie gehe ich unter anderem auf häufige Missverständnisse bei der Auswahl von Modellierungswerkzeugen ein; und ich zeige Ihnen, was es mit der Abbildung der Realität in Modelle “wirklich” auf sich hat…