Types Of Diagram In Uml

Also, dieses UML, ne? Einheitliche Modellierungssprache. Klingt wie 'ne Geheimsprache für Nerds. Und was machen die damit? Diagramme! Aber nicht so bunte Bildchen wie im Kindergarten. Nein, viel komplizierter!

Die üblichen Verdächtigen: Klassendiagramme

Klassendiagramme. Der Klassiker. Hier werden Klassen mit ihren Attributen und Methoden dargestellt. Super, wenn man wissen will, welche Daten wo rumliegen und was damit passiert. Persönliche Meinung: Sehen oft aus wie überfüllte Tabellen. Aber hey, Ordnung muss sein!

Ich sag's ja nur: Diese Linien und Pfeile, die da rumschwirren, sind manchmal verwirrender als das eigentliche Problem. Und dann die ganzen Kardinalitäten… 0..1? 1..? 0..*? Hilfe! Ich brauche einen Kaffee.

Verhaltensdiagramme: Wenn's mal nicht so läuft, wie geplant

Dann haben wir die Verhaltensdiagramme. Hier geht's um das, was die Software so treibt. Anwendungsfalldiagramme zum Beispiel. Wer macht was mit dem System? Klingt simpel, wird aber schnell komplex.

Anwendungsfalldiagramme: Das Drama in drei Akten

Anwendungsfalldiagramme sind wie kleine Theaterstücke. Ein Akteur (der User) interagiert mit dem System (die Bühne). Und dann passiert irgendwas (der Anwendungsfall). Ob es ein Happy End gibt? Hängt davon ab, ob die Software funktioniert!

Mal ehrlich: Wer hat sich noch nie gefragt, warum man für 'ne simple Login-Funktion ein ganzes Diagramm braucht? Ich schon! Aber gut, visualisieren wir halt, dass der User seinen Benutzernamen und sein Passwort eingibt. Spannend!

Zustandsdiagramme: Das ewige Hin und Her

Zustandsdiagramme zeigen, wie sich ein Objekt im Laufe der Zeit verändert. Vom 'neuen' zum 'alten' Zustand, und so weiter. Klingt philosophisch, ist aber nur Software. Oder doch nicht?

Ich finde ja, Zustandsdiagramme sind perfekt, um zu zeigen, warum die Software manchmal so komisch reagiert. "Oh, das Objekt befindet sich gerade im Zustand 'Verwirrt'. Kein Wunder, dass es nicht das tut, was es soll!"

Aktivitätsdiagramme: Der Workflow-Wahnsinn

Aktivitätsdiagramme sind wie Flussdiagramme für Programmierer. Hier werden die einzelnen Schritte eines Prozesses dargestellt. Entscheidungen, Verzweigungen, Parallelitäten… Alles drin!

Sind wir ehrlich, manchmal sieht ein Aktivitätsdiagramm aus wie ein Labyrinth. Und die Frage ist: Findet man am Ende den Ausgang oder nur einen weiteren toten Winkel?

Interaktionsdiagramme: Wer flüstert wem was ins Ohr?

Interaktionsdiagramme zeigen, wie Objekte miteinander kommunizieren. Sequenzdiagramme sind hier der Star. Wer schickt wem welche Nachricht in welcher Reihenfolge?

Sequenzdiagramme sind wie Tratsch am Gartenzaun. Nur dass hier Objekte tratschen. Und die Nachrichten sind Code. Und der Gartenzaun ist das Netzwerk.

Ich behaupte ja, Sequenzdiagramme sind der beste Beweis dafür, dass Software auch nur menschlich ist. Voller Missverständnisse und unnötiger Kommunikation.

Kommunikationsdiagramme: Das Spinnennetz der Beziehungen

Kommunikationsdiagramme (oder Kollaborationsdiagramme) sind wie Sequenzdiagramme, nur anders. Hier steht nicht die Reihenfolge der Nachrichten im Vordergrund, sondern die Beziehungen zwischen den Objekten.

Ich persönlich finde Kommunikationsdiagramme immer etwas unübersichtlich. Sie sehen aus wie ein Spinnennetz, in dem sich die Objekte verfangen haben. Aber hey, vielleicht ist das ja auch die Realität in der Software!

Komponentendiagramme & Deploymentdiagramme: Das große Ganze

Komponentendiagramme zeigen die einzelnen Softwarekomponenten und ihre Beziehungen. Deploymentdiagramme zeigen, wo die Software läuft. Server, Clients, Datenbanken… Die ganze Infrastruktur.

Mal ehrlich, wer versteht schon wirklich, was da vor sich geht? Hauptsache, die Software läuft. Und wenn nicht, dann ist es halt "ein Deployment-Problem".

Also, UML-Diagramme sind schon 'ne feine Sache. Aber manchmal denke ich, dass sie eher dazu dienen, die Komplexität der Software zu verschleiern, als sie zu vereinfachen. Aber hey, das ist nur meine unpopuläre Meinung. Vielleicht lieg ich ja auch völlig falsch.

Und jetzt erstmal 'nen Kaffee. Und vielleicht noch ein Diagramm zeichnen. Oder auch nicht.