Ich erinnere mich an ein Projekt bei einem mittelständischen Logistikunternehmen in Hamburg. Das Team saß seit drei Wochen in einem schicken Konferenzraum und zeichnete bunte Kreise und Strichmännchen auf Whiteboards. Sie dachten, sie hätten alles im Griff. Am Ende hatten sie ein riesiges Use Case Diagram UML Diagrams erstellt, das so komplex war, dass kein Entwickler es mehr verstand. Das Ergebnis? Drei Monate Entwicklungszeit für ein Feature, das am Ende niemand brauchte, und ein Verlust von knapp 80.000 Euro an Personalkosten. Der Fehler war klassisch: Sie haben die Zeichnung mit der Architektur verwechselt.
In meiner Laufbahn habe ich das immer wieder erlebt. Leute glauben, dass ein hübsches Bild die harte Arbeit des Nachdenkens ersetzt. Das Gegenteil ist der Fall. Ein Diagramm ist nur so gut wie die Klarheit, die es im Kopf der Beteiligten schafft. Wenn du nur malst, um zu malen, kannst du es gleich lassen. Es geht hier nicht um Kunst, sondern um die harte Definition von Systemgrenzen und Benutzerinteraktionen. Wenn die nicht sitzen, brennt die Hütte später beim Codieren lichterloh.
Die Falle der funktionalen Zersplitterung im Use Case Diagram UML Diagrams
Der häufigste Fehler, den ich sehe, ist der Versuch, jede einzelne Funktion des Systems in das Bild zu pressen. Ich nenne das „Funktions-Salami“. Ein Anwendungsfall ist keine Funktion. „Button klicken“ ist kein Anwendungsfall. „Datenbank aktualisieren“ ist kein Anwendungsfall. Wer das so macht, endet mit einem Spinnennetz aus Linien, das nichts aussagt. Ein echter Anwendungsfall beschreibt ein Ziel, das ein Akteur erreichen will. Das Ziel ist „Paket versenden“ oder „Rechnung reklamieren“.
Wenn du anfängst, technische Details wie Login-Prozesse oder Validierungsschritte als eigene Blasen zu zeichnen, hast du schon verloren. Ein Login ist meistens nur eine Voraussetzung, kein eigenständiger Geschäftswert für den Nutzer. In einem großen Versicherungsprojekt, das ich retten musste, hatten sie 150 Anwendungsfälle für ein einfaches Kundenportal. Nach zwei Tagen Aufräumarbeit blieben 12 übrig. Die restlichen 138 waren technischer Kleinkram, der in die Spezifikation der einzelnen Schritte gehört, aber nicht auf die oberste Ebene der Modellierung.
Warum Granularität dein größter Feind ist
Viele Anfänger denken, mehr Details bedeuten mehr Präzision. Das ist falsch. Auf dieser Ebene der Abstraktion bedeutet mehr Detail meistens mehr Verwirrung. Du willst sehen, wer mit dem System interagiert und was das System im Kern leisten soll. Sobald du anfängst, über If-Then-Else-Bedingungen in deiner Grafik nachzudenken, bist du eine Ebene zu tief gerutscht. Das gehört in ein Aktivitätsdiagramm oder direkt in den Code. Bleib oben, bleib beim Geschäftswert. Wenn du das nicht schaffst, wird dein Team die Übersicht verlieren und am Ende Funktionen bauen, die technisch funktionieren, aber am Kundenwunsch vorbeigehen.
Der Akteur ist kein Jobtitel sondern eine Rolle
Ein Fehler, der regelmäßig zu massiven Missverständnissen zwischen Fachabteilung und IT führt, ist die falsche Definition der Akteure. Ich habe Projekte gesehen, da stand „Herr Müller aus der Buchhaltung“ als Akteur im Diagramm. Das ist Wahnsinn. Was passiert, wenn Herr Müller in Rente geht oder die Abteilung wechselt?
Ein Akteur im Use Case Diagram UML Diagrams repräsentiert eine Rolle, die jemand gegenüber dem System einnimmt. Das kann ein Mensch sein, aber auch ein anderes technisches System. Wenn du hier nicht sauber trennst, baust du Software, die so starr ist wie eine Behörde aus den 80ern. Du musst abstrahieren. „Buchhalter“ ist eine Rolle. „Administrator“ ist eine Rolle. „Externes Bezahlsystem“ ist ein Akteur.
Ich habe mal erlebt, wie ein Team ein System für ein Krankenhaus entwarf. Sie hatten „Chirurg“, „Internist“ und „Radiologe“ als separate Akteure. Das Problem? In der Nachtschicht mussten alle drei Rollen teilweise von einer Person übernommen werden. Das System war aber so programmiert, dass man sich ständig ummelden musste. Ein einziger Akteur namens „Behandelnder Arzt“ mit entsprechenden Berechtigungen hätte das Problem gelöst und Wochen an Umprogrammierung gespart.
Die Inclusion und Extension Hölle vermeiden
Es gibt diese beiden Pfeiltypen: `<
