"use case" Diagramme sind gar keine Use Case Diagramme

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Beim Schmökern in der UML-Spezifikation (ich gestehe, das tue ich manchmal zur Entspannung) bin ich gerade auf ein überraschendes Detail gestoßen:

Diagramme mit use case im Titel sind keine Anwendungsfalldiagramme.

Also nicht nur "können manchmal was anderes sein" - das hätte ich ja auch so ausgedrückt, sondern "sind in aller Regel keine". Hm, wie das? Lassen wir die Spezifikation zu Wort kommen:

[...], the primary graphical symbols define the type of the diagram.

Mit anderen Worten, wenn hauptsächlich Anwendungsfälle zu sehen sind muss es wohl ein Anwendungsfalldiagramm sein. Gut, das spräche nicht dagegen, es im Titel auch so zu nennen.

Ein paar Zeilen weiter lesen wir aber:

The heading of a diagram represents the kind, name, and parameters of the namespace enclosing or the model element owning elements that are represented by symbols in the contents area.

Das heißt die Bezeichnung im Diagrammtitel bezieht sich nicht auf die Art des Diagramms, sondern vielmehr auf die Art des Elements dessen Unterelemente im Diagramm gezeigt werden. Wer hätte das gedacht?

Ja, gut, bei Verhaltensdiagrammen ist es natürlich so. Ein Aktivitätsdiagramm zeigt eine Aktivität und die Elemente des Diagramms gehören dieser Aktivität. Aber bei Strukturdiagrammen wie dem Klassen- oder dem Anwendungsfalldiagramm?

Glücklicherweise enthält die Spezifikation hier ein seltenes Beispiel, das auch noch in anderer Hinsicht interessant ist:

Dieses "use case" Diagramm zeigt also einfach die untergeordneten Elemente des Anwendungsfalles. Das sind meist Aktivitäten oder wie hier Zustandsmaschinen, die zur Beschreibung des Anwendungsfalls dienen. Theoretisch könnte man auch Anwendungsfälle zeigen und hätte dann auch ein Anwendungsfalldiagramm, das mit "use case" beschriftet wäre. Ein Anwendungsfall der andere Anwendungsfälle besitzt ist mir aber noch nicht unter gekommen und wäre auch seltsam.

Was also steht über einem richtigen Anwendungsfalldiagramm? Ganz einfach: "package", denn in den meisten Fällen gehören die Anwendungsfälle einem Paket.

Und beim Klassendiagramm? Sie ahnen schon: Ein "class" Diagramm ist kein Klassendiagramm. Ein Diagramm das die Elemente im Namensraum einer Klasse zeigt ist vielmehr ein Kompositionsstrukturdiagramm.

Damit ist auch das Rätsel gelöst, warum die UML bei 14 Diagrammarten nur 8 Rahmenarten kennt. Hier nochmal eine Übersicht:

• activity: Knoten und Kanten gehören der Aktivität (ownedNode, ownedEdge)
• class: Eigenschaften und Konnektoren gehören der Klasse (ownedAttribute, ownedConnector)
• component: paketierbare Elemente gehören der Komponente (ownedMember)
• deployment: paketierbare Elemente gehören dem Knoten (ownedMember)
• interaction: Lebenslinien und Fragmente gehören der Interaktion (lifeline, fragment)
• package: paketierbare Elemente gehören dem Paket (ownedMember)
• state machine: Zustände und Transitionen gehören zur Zustandsmaschine (region.subvertex, region.transition)
• use case: Verhalten gehört zum Anwendungsfall (ownedMember)

Muss jetzt die Geschichte der UML neu geschrieben werden? Ich glaube nicht. Diagramme darf man beliebig benennen und wenn ich ein Anwendungsfalldiagramm so betiteln will, darf ich das auch tun. Wir empfehlen ja sowieso einen methodikspezifischen Namen zu verwenden, wie zum Beispiel "Systemkontext" oder "Fachklassendiagramm".

PS: Der andere interessante Punkt ist übrigens, dass ein Diagramm in ein anderes eingebettet sein kann. Ob das aber wirklich so sein soll ist fraglich, da das Diagramm in der aktuellen Arbeitsversion der UML 2.5 ausgetauscht worden ist.