Klassendiagramme mit UML erstellen

Klassendiagramme sind Strukturdiagramme innerhalb der Unified Modeling Language, kurz: UML. Die Modellierungssprache UML ist ein ISO-Standard. Sie veranschaulicht Systeme der objektorientierten Programmierung. Auch Geschäftsprozesse lassen sich damit übersichtlich aufzeichnen. Mithilfe visueller Mittel zeigt UML Zustände von Systemen auf und beschreibt Interaktionen zwischen Systemelementen. Dafür legt die Notation Formen und Linien für 14 Diagrammtypen fest.

Die Metamodellierung beschreibt sowohl einzelne Elemente der Modellierungssprache als auch die Sprache selbst. Sie legt Spracheinheiten für unterschiedliche Ebenen fest. Eine Spracheinheit in dieser visuellen Sprache ist beispielsweise das Verhalten. Es beschreibt sowohl eine Metaklasse als auch einen Oberbegriff für alle dynamischen Faktoren innerhalb eines Systems. Eine weitere Spracheinheit ist das Objekt, das Grundelement der objektorientierten Programmierung. UML-Klassendiagramme modellieren Objekte als Instanzen von Klassen. Somit ist das Klassendiagramm einer der wichtigsten und meistgenutzten Diagrammtypen der UML.

Die Diagrammtypen teilen sich nach ihrer Funktion in zwei Hauptkategorien ein: Strukturdiagramme und Verhaltensdiagramme. Letztere weisen eine Unterkategorie auf: Interaktionsdiagramme. Diese modellieren nicht nur das allgemeine Verhalten eines Systems, sondern fokussieren sich auf Informationsflüsse zwischen Objekten im Zeitverlauf eines Prozesses. Dazu gehören beispielsweise die Sequenzdiagramme. Sie modellieren die chronologische Reihenfolge von Nachrichten, die in einem detaillierten Anwendungsfall fließen. Verhaltensdiagramme visualisieren dynamische Prozesse. Ein Beispiel ist das Aktivitätsdiagramm. Dieses zeigt auf, wie einzelne Aktionen in einem Ablauf interagieren. Strukturdiagramme hingegen zeigen statische Zustände; sie illustrieren die Elemente eines Systems und deren Abhängigkeiten untereinander.

Das Klassendiagramm teilt Objektinstanzen aufgrund ihrer Eigenschaften bestimmten Klassen zu – es besteht also eine hierarchische Abhängigkeit. Gleichzeitig existieren Beziehungen zwischen verschiedenen Klassen oder zwischen Objekten.

Klassendiagramme stellen Zustände mit Systemelementen dar. Sie zeigen Strukturen bis zur kleinsten Instanz auf. Demnach eignen sie sich für die Darstellung von detaillierten Software-Architekturen. Daraus lassen sich konkrete Programmierschritte ableiten. Einige softwaregestützte Programmierumgebungen wandeln diese UML-Diagramme direkt in Code-Frames um. Mittels Team-Sharing kommunizieren Entwickler untereinander oder mit anderen Entscheidern innerhalb eines Unternehmens. Für Fachfremde vermittelt ein UML-Diagramm einen Überblick über geplante Systemstrukturen oder Prozessabläufe. Zudem lassen sich damit Systemanforderungen formulieren, die die Entwickler dann umsetzen. Untereinander können IT-Experten Diagramme modellieren und effektiv abändern, ohne bereits in der Planungsphase größere Umgebungen oder Prozesse programmieren zu müssen.

Das sind die Einsatzgebiete von Klassendiagrammen:

• Sie beschreiben Typen innerhalb eines Systems. Die grafische Darstellung lässt sich in verschiedene Programmiersprachen und Umgebungen übertragen. Somit existiert sie unabhängig von der zukünftigen Anwendung.
• Sie modellieren bereits bestehende Software-Architekturen. Sollen zusätzliche Bestandteile eingebunden werden, visualisieren sie geeignete Strukturen, an denen neue Komponenten eingebaut werden können. Für die zukünftigen Systemelemente erstellen Klassendiagramme einen Leitfaden für den Programm-Code. Je nach Bedarf kann dieser Schritt skizzenhaft oder sehr detailliert ausfallen.
• Sie stellen Datenmodelle dar. Dabei eignen sie sich für Systeme unterschiedlicher Komplexität.
• Bei verschachtelten Anwendungen können die Dokumentation und die Wartung sehr komplex werden. Klassendiagramme vermitteln einen Überblick über das Schema.
• Sie stellen Anforderungen an eine Software dar. Als Bilddatei lassen sie sich leicht über interne Geschäftskanäle weiterleiten. So ermöglichen sie Experten aus unterschiedlichen Abteilungen, sich über die Architektur auszutauschen.
• Der UML-Standard nutzt Klassendiagramme, um seine eigene Notation visuell darzustellen.

Die Klasse ist ein Modellelement im Klassendiagramm und eine Spezialisierung des verkapselten Klassifizierers (EncapsulatedClassifier) und des Verhaltensklassifizierers (BehavioredClassifier). Sie fasst eine Menge von Instanzen zusammen. Objektinstanzen innerhalb einer Klasse prägen die gleichen Merkmale (Attributes) und Verhaltensweisen (Methods) aus. Außerdem weisen sie die gleiche Semantik auf, d. h. sie nutzen die gleichen Zeichen mit der gleichen Bedeutung. Somit ist die Klasse eine Art Muster für ihre Objekte. Sie instanziert die Objekte und definiert ihr Verhalten im System.

Diese Eigenschaften fügen Sie in die Notation ein, wenn Sie ein Klassendiagramm erstellen. In UML wird eine Klasse als Rechteck mit durchgezogener Linie dargestellt. Sein Körper besteht aus drei Abteilungen, die übereinander angeordnet sind. Nur der oberste Teil muss zwingend modelliert werden, denn hier legen Sie den Namen der Klasse fest. Die beiden anderen Partitionen beschriften Sie optional mit Attributen (Mitte) und Operationen (unten). Diesen Elementen weisen Sie verschiedene Sichtbarkeiten zu, indem Sie folgende Symbole vor ihren Namen schreiben:

• + = öffentlich
• - = privat
• # = geschützt
• / = abgeleitet
• ~ = Paket
• * = zufällig

Properties sind verbundene Elemente. Klasseneigene Attribute (ownedAttributes) sind immer Rollen. Man verbindet sie über Konnektoren. Besitzen sie die Eigenschaft isComposite= true („ist zusammengesetzt = wahr“), nennt man sie Teile (Parts).

Die UML-Property ist ein Strukturmerkmal, das verschiedene Einsatzgebiete hat. Neben der Funktion als Attribut in einer Klasse kann es auch Assoziationsenden darstellen.

Der Property-Type leitet sich vom Namen des Klassifizierers ab. Optional legen Sie einen Standardwert für ein Merkmal fest. Zusätzlich bestimmen Modifizierer näher, wie sich ein Merkmal verhält:

• geordnet (Notation: isOrdered = true)
• einzigartig (Notation: isUnique = true)
• nicht einzigartig (Notation: isUnique = false)
• schreibgeschützt (das Merkmal kann nur gelesen werden, Notation: isReadOnly = true)
• Sequenz (das Merkmal ist eine geordnete Sammlung, Notation: isUnique = false und isOrdered = true)
• Vereinigung (eine abgeleitete Vereinigung von Teilmengen, Notation: union)
• ID (gehört zur Bezeichnung seines Klassifizierers, Notation: id)
• Merkmalseingrenzung (eine Eingrenzung, die das Merkmal beeinflusst, Notation: property-constraint)
• Neudefinition eines Merkmals (definiert ein vererbtes, benanntes Merkmal um, Notation: redefines [Merkmalsname])
• Teilmenge des Merkmals (symbolisiert ein Merkmal, das eine Teilmenge eines benannten Merkmals ist, Notation: subsets [Merkmalsname])

Operationen sind Verhaltensfunktionen. Sie kommen in Klassen, aber auch in Datentypen oder Schnittstellen vor. Sie rufen die Instanz einer Klasse direkt auf. Die Operation legt folgende Aspekte eines Aufrufs fest:

• Name
• Typ
• Parameter
• Einschränkungen

Die Operation gehört ihrem übergeordneten Klassifizierer an. Dieser ändert sie möglicherweise, indem er Typ oder Parameter neu definiert.

Für Operationen gibt es Vorbedingungen. Diese müssen erfüllt sein, bevor die Operation ausgeführt wird. UML definiert jedoch nicht, wie sich ein Verhaltensaufruf verhält, wenn die Vorbedingungen nicht erfüllt sind. Außerdem legen Sie Nachbedingungen fest, die erfüllt sein müssen, wenn die Operation abschließt. Körperbedingungen beschränken das Ausgabeergebnis auf einen Wert, der aus ihren Spezifikationen errechnet wird. Dieser Wert sollte die Nachbedingungen erfüllen. Die Operation kann aber auch eine Ausnahme hervorrufen, während sie ausgeführt wird. Dann erfüllt sie voraussichtlich nicht die Nachbedingungen.

Die Notation für das Klassendiagramm schreibt vor, dass Operationen in einem Abteil im Körper der Klasse notiert werden. Laut UML-Standard ist die Angabe obligatorisch. Gleichzeitig ermöglicht UML, alle standardmäßigen Angaben innerhalb einer Klasse zu unterdrücken. Nur der Name muss notiert werden.

Ein Signalempfänger zeigt an, dass ein Klassifizierer bereit ist, ein Signal anzunehmen. Er definiert auch, welche Arten von Signalen die Instanzen der Klasse annehmen. Der Signalempfänger heißt so wie sein Signal. Entsprechende Angaben notieren Sie im Körper der Klasse, in einem Abteil unter den Operationen.

Ports sind Anschlüsse für verkapselte Klassifizierer. Sie stellen einen Punkt dar, an dem der Klassifizierer mit seiner Umwelt interagiert. Abgesehen von den Ports ist der verkapselte Klassifizierer ein in sich geschlossenes System. Da seine inneren Struktur- und Verhaltenselemente vom restlichen System unberührt bleiben, können Sie diesen Klassifizierer ebenso unabhängig definieren. Solange ein System die Einschränkungen des Ports erfüllt, können Sie den verkapselten Klassifizierer in unterschiedlichen Umgebungen wiederverwenden.

Zudem erlaubt UML mehrere Andockstellen pro Klassifizierer. Sie können für jeden Port eigene Regeln definieren. Der Port ist eine Eigenschaft des Klassifizierers, Sie legen seine Regeln also im Bereich für Properties fest. Dazu gehören die Dienste, die der Klassifizierer seiner Umwelt anbietet, und die Dienste, die er benötigt. Sie unterscheiden zwischen unterschiedlichen Informationsflüssen, indem Sie den dafür verwendeten Port identifizieren.

Auch Ports selbst haben Eigenschaften. Führt der Port veröffentlichte Funktionen des Klassifizierers aus, zeigt das die Eigenschaft isService an. Wenn isService = true gegeben ist, gilt der Port als unverzichtbarer Bestandteil der nach außen sichtbaren Funktionen des verkapselten Klassifizierers. Bei isService = false gehört der Port nicht zu den essenziellen Features und kann daher, genau wie andere interne Funktionen, geändert oder gelöscht werden.

Ports interagieren mit Schnittstellen. Es gibt bereitgestellte und benötigte Schnittstellen (s. u. „Schnittstellen“). Die Schnittstelle, die mit dem Port verbunden ist, spezifiziert die Interaktionen, die über den Port laufen. Da die Andockstelle eine Eigenschaft ist, hat sie einen Typ. Der Wert von isConjugated vermittelt zwischen dem Typen und der Schnittstelle des Ports. Ist der Wert wahr, kann sich die benötigte Schnittstelle direkt vom Typ des Ports ableiten oder aus der Menge von Schnittstellen, die der Typ des Ports realisiert. Eine bereitgestellte Schnittstelle leitet sich in diesem Fall aus der Menge der Schnittstellen ab. Wenn isConjugated wahr ist, leitet sich die bereitgestellte Schnittstelle vom Typ ab.

Generiert ein verkapselter Klassifizierer eine Instanz, werden für jeden seiner Ports entsprechende Instanzen erstellt. Ein Port hält die jeweilige Instanz in Übereinstimmung mit seinem Typ und seiner Multiplizität (s. u.). Die Instanzen nennt UML Interaktionspunkte. Jede Instanz besitzt einzigartige Verweise, anhand derer sie zwischen den unterschiedlichen Anfragen für Verhaltensfunktionen unterscheidet, die an ihre Ports gerichtet werden.

Ports mit der Eigenschaft isBehavior = true senden eine Anfrage an die Instanz des verkapselten Klassifizierers. Die Anfrage übernimmt das spezifizierte Verhalten der Instanz. Die sogenannten Behavior-Ports leiten Anfragen also nicht ins Innere Ihres Klassifizierers. Ist im Klassendiagramm dafür kein Verhalten festgelegt, gehen Nachrichten an diesen Ports verloren.

Einen Port modellieren Sie als kleines Quadrat auf dem Rahmen des Klassifizierers, zu dem er gehört. An den Port zeichnen Sie die benötigte oder bereitgestellte Schnittstelle. Wenn Sie keine speziellen Merkmale für den Port festlegen, zeichnen Sie die Schnittstelle ohne Port.

Konnektoren definieren Verbindungen zwischen zwei oder mehr Instanzen. Die Spezifikation ermöglicht deren Kommunikation. Im Gegensatz zu Beziehungen wie der Assoziation verbinden Konnektoren keine beliebigen Instanzen, sondern nur Instanzen, die als Verbindungsteile definiert sind. Konnektoren modellieren Sie als Kanten mit mindestens zwei Enden. Sie stehen für die teilnehmenden Instanzen, die den verknüpfbaren Elementen einen Typ zuweisen.

Eine weitere wichtige Größe ist die Multiplizität. Dieser Parameter gibt an, wie viele Instanzen eine strukturierte Klasse ausbilden darf. Zudem begrenzt sie Attribute und Operationen. Sie ist ein Teil der inneren Struktur – das ist ein vorgeschriebenes Element im Körper der Klasse. Sie tragen es hinter den Attributen und Operationen ein. Zu diesem Abschnitt gehört auch die Topologie. Knoten (Objektinstanzen) verbinden sich über Kommunikationswege (CommunicationPaths) zu Topologienetzwerken.

Multiplizitäten notieren Sie wie folgt:

<multiplizität> : <multiplizitätsbereich> [<Ordnungsbezeichnung> , <Einzigartigkeitsbezeichner>]

Der Multiplizitätsbereich gibt einen festen Wert oder einen Von-bis-Bereich an:

• 0 = die Klasse bildet keine Instanzen aus (kommt selten vor)
• 0..1 = entweder keine Instanz oder eine Instanz
• 1 oder 1..1 = genau eine Instanz
• 0..* oder nur * = keine Instanz oder mehr mit offenem Wert
• 1..* = eine Instanz oder mehr mit offenem Wert

Die Ordnung und Einzigartigkeit kann man als Set (Menge) ausdrücken oder durch Einzelbegriffe, die man mit Komma trennt. Je nachdem, ob die Knoten in der Menge einzigartig oder geordnet sind, erhält die Menge eine Typbeschreibung. In der Notation beschreiben Sie die einzelnen Größen als ordered/unordered (geordnet/ungeordnet) oder unique/not unique (einzigartig/nicht einzigartig).

Manche eingeschränkten Elemente notieren Sie in UML als Text, z. B. ein Attribut einer Klasse im Klassendiagramm. Die Einschränkung notieren Sie hinter dem Textelement in geschwungenen Klammern. Handelt es sich bei dem Besitzer um ein Element, das Sie als Symbol darstellen, platzieren Sie die Einschränkung möglichst nah an dem Symbol; so sollte es offensichtlich sein, dass beide Elemente eine semantische Beziehung haben. Noch deutlicher machen Sie die Verbindung, indem Sie die Einschränkung in ein Notizzettel-Symbol schreiben und mit seinem Besitzer über eine gestrichelte Linie verbinden.

Wirkt die Einschränkung auf zwei Elemente, verbinden Sie die Besitzer über eine gestrichelte Linie. Daran schreiben Sie die Einschränkung in geschwungenen Klammern. Setzen Sie eine Pfeilspitze an ein Ende, signalisiert dies die Position der Besitzer innerhalb einer Sammlung von eingeschränkten Elementen (constrainedElements). Der Pfeil zeigt weg von der ersten Position hin zur zweiten. Besitzen mehr als zwei Elemente die Einschränkung, nutzen Sie das Notizzettel-Symbol und verbinden jedes Element mit der Einschränkung.

Auch Kanten zählen zu den beschränkbaren Elementen. Modellieren Sie mehr als zwei Kanten derselben Art, ziehen Sie die gestrichelte Constraint-Linie durch alle Kanten, die die involvierten Elemente darstellen.

Stereotypen definieren Erweiterungen von Metaklassen. Laut UML-Spezifikation gehören sie zu den Profilen. Beschreibt ein Stereotyp zusätzliche Eigenschaften mehrerer Metaklassen, kann er während der Laufzeit zu einem bestimmten Zeitpunkt nur eine Instanz der Metaklasse auf einmal beschreiben. Unter den Metaklassen nimmt der Stereotyp eine bestimmte Rolle ein. Denn er kann niemals alleine stehen. Sie modellieren einen Stereotyp immer in Verbindung mit dem Klassifizierer, den er erweitert. Sie verbinden die Metaklasse mit dem Stereotypen, indem Sie eine Erweiterung (Extension) modellieren.

UML definiert einige Klassen-Stereotypen, die Ihr UML-Klassendiagramm erweitern. Sechs Stereotypen gehören zum Standard. Oft genutzt, aber nicht standardisiert sind drei Stereotypen, mit denen Sie das Muster „Modell-Präsentation-Steuerung“ (Model-View-Controller, kurz: MVC) in UML umsetzen. Die drei nicht standardisierten Stereotypen sind:

• Die Entität (Notation: <<Entity>>): Der Stereotyp Entity definiert eine Klasse oder ein Objekt. Die jeweilige Instanz steht für eine Sammlung von Daten. Häufig sind es Systemdaten, die über längere Zeit gespeichert werden sollen. Die Entität übernimmt die Rolle des Modells aus dem MVC-Muster. UML kennt diesen Stereotypen, aber ordnet ihn standardmäßig den Komponentendiagrammen zu. Die häufig genutzte Notation führt die Spezifikation nicht auf. Sie modellieren die Entität als Kreis, der auf einer kurzen Linie ruht.
• Die Grenze (Notation: <<Boundary>>): Die Grenze ist ein Stereotyp für eine Klasse oder ein Objekt. Sie entspricht in etwa dem Element View im MVC-Muster. Die Grenze modelliert die Grenze Ihres Systems, z. B. eine Benutzeroberfläche. Üblicherweise stellt man sie als Kreis dar, von dem links eine Linie abgeht, die auf eine vertikale Linie trifft.
• Das Kontrollelement (Notation: <<Control>>): Das Kontrollelement repräsentiert dieselben Elemente wie der Controller unter MVC. Klassen oder Objekte mit diesem Stereotyp modellieren Elemente, die das Systemverhalten oder Kontrollflüsse abstimmen. Im UML-Standard übernimmt der Stereotyp <<Focus>> ähnliche Aufgaben. Eine Control-Instanz zeichnen Sie als Kreis mit einer offenen Pfeilspitze auf der Linie.

Diese drei Stereotypen lassen sich auch als einfache Klasse zeichnen. Im Rechteck notieren Sie den Namen des jeweiligen Stereotyps. Hauptsächlich wenden Modellierer diese Formen in Sequenzdiagrammen an. Wenn Sie mehr über Entity-Boundary-Control-Diagramme wissen wollen, lesen Sie unseren Artikel über Sequenzdiagramme mit UML.

Für Klassendiagramme eignen sich diese standardisierten Stereotypen:

• Fokus (<<Focus>>)
• Helfer (<<Auxiliary>>)
• Typ (<<Type>>)
• Anwendungsklasse (<<ImplementationClass>>)
• Metaklasse (<<Metaclass>>)
• Utility (<<Utility>>)

Die Fokusklasse definiert die grundlegende Geschäftslogik oder den Kontrollfluss von Helferklassen. Diese unterstützen die Fokusklasse, die eine oder mehrere Helfer anbindet. Sie definiert unterstützende Klassen implizit, indem Sie mit ihnen eine Abhängigkeitsbeziehung eingeht (s. u. „Die gerichtete Beziehung“). Nutzt sie Helferklassen, definiert sie diese explizit. Der UML-Standard empfiehlt diesen Stereotyp besonders für die Design-Phase, wenn Sie Kontrollflüsse zwischen Komponenten darstellen oder die grundlegende Geschäftslogik festlegen.

Die Helferklasse agiert meist in Kombination mit der Fokusklasse. Sie unterstützt generell Klassen mit entscheidender Bedeutung für das System. Dafür führt sie zweitrangige Kontrollflüsse aus und definiert subsidiäre Logik. Unterstützt die Helferklasse eine Fokusklasse, erfolgt die Definition explizit. Über eine Abhängigkeitsbeziehung definieren Sie die unterstützte Klasse implizit.

Die Typenklasse legt ein Gebiet für Geschäftsobjekte fest. Außerdem spezifiziert sie die Operatoren dieser Objekte. Der Typ-Stereotyp kann Attribute und Assoziationen aufweisen. Jedoch beschreibt er damit nicht die physische Ausführung des Objekts.

Einige Programmiersprachen (z. B. Java oder C++) erlauben lediglich eine Klasse für jede Instanz. Mit UML können Sie eine Instanz jedoch mehreren Klassen zuordnen. Die Anwendungsklasse schlägt eine Brücke zwischen diesen zwei Welten. Dieser Stereotyp beschränkt die UML-Klasse. Er bestimmt, dass eine Instanz unter ihm nur eine Klasse realisieren darf. Dafür kann die Anwendungsklasse mehrere unterschiedliche Typen umsetzen. Um einen ihr zugeordneten Klassifizierer erfolgreich auszuführen, muss sie zwei Bedingungen erfüllen: Sie muss alle Operationen des Klassifizierers bereitstellen und diese müssen das Verhalten aufweisen, das für den Klassifizierer definiert wurde. Physische Attribute und Assoziationen müssen aber nicht übereinstimmen.

Da sich die Formen von Klasse und Metaklasse nicht unterscheiden, gibt das Label Metaclass an, dass es sich um den Stereotyp Metaklasse handelt. Die Instanzen dieser Klasse sind selbst Klassen. Mit diesem Stereotyp arbeiten Sie also auf einem höheren Abstraktionslevel.

Die Utility-Klasse besitzt keine Instanzen. Sie kennzeichnet lediglich eine Sammlung benannter Attribute und Operationen. Diese sind immer statisch. Statische Attribute ändern sich nicht, wenn sie aufgerufen werden. Statische Operationen wendet man bei Entitäten oder Entitätstypen an. Nutzen Sie die Utility-Klasse, müssen Sie von Anfang an die entsprechenden Werte und Operationen angeben, da diese sich nicht mehr ändern. Unterstreichung kennzeichnet diese Elemente.

Es gibt auch benötigte Schnittstellen (Required Interfaces). Sie visualisieren eine Abhängigkeitsbeziehung (s. u. „Beziehungen“). Dabei benötigt ein Element ein anderes Element, um den vollen Umfang seiner eigenen Funktionen auszuführen. In diesem Fall benötigt ein Klassifizierer (oder eine seiner Instanzen) eine Schnittstelle. Die InterfaceUsage (Schnittstellennutzung) spezifiziert die Ansprüche an die Schnittstelle. Dafür verbindet eine durchgezogene Linie den Klassifizierer mit einem offenen Halbkreis. Dieser symbolisiert die Schnittstelle. Notieren Sie den Namen der Schnittstelle bei beiden Repräsentanten unter dem (Halb-)Kreis.

Vererbt eine Klasse eine Schnittstelle an eine untergeordnete Klasse, modellieren Sie die Schnittstellenanbindung an die untergeordnete Klasse oder Instanz. Zeigen Sie die hierarchische Beziehung mit dem Zirkumflex (^), z. B. als ^Schnittstelle 1.

Nutzen Sie die rechteckige Schnittstellen-Notation, zeichnen Sie zwischen den zwei Knoten eine Kante. Im Klassendiagramm modellieren Kanten die Beziehungen zwischen Klassen, Instanzen oder Komponenten. UML schreibt verschiedene Linien und Pfeile für unterschiedliche Funktionen und Beziehungen vor. In diesem Fall verbinden Sie eine Klasse mit der benötigten Schnittstelle über einen gestrichelten Pfeil mit offener Spitze. Geben Sie dem Pfeil das Label <<use>>. Eine bereitgestellte Schnittstelle verbinden Sie mit einer Klasse über einen gestrichelten Pfeil mit geschlossener, nicht ausgefüllter Spitze. Der Pfeil zeigt immer in Richtung der Schnittstelle.

Die Enumeration (Aufzählung) ist ein Datentyp. Sie stellen den Wert der Aufzählung als sogenanntes Aufzählungsbuchstabensymbol dar. Wie im Bild oben zu sehen, handelt es sich dabei einfach um einen Namen, der symbolisch für einen bestimmten Wert steht. Diesen wählen Sie selbst. In der Aufzählung „Rosenarten“ steht beispielswiese der Name „Teerosen“ für die Anzahl Teerosen, die ein Blumenladen im Sortiment hat. Im Klassendiagramm zeichnen Sie diesen Klassifizierer mit dem Symbol für die Klasse, einem Rechteck. Der Name sowie das Label <<enumeration>> steht im Kopf. Sie trennen den Kopfbereich vom Körper durch horizontale Linien in Abteilungen.

Wie bei anderen Klassen reserviert die Aufzählung die oberen Abteilungen für Attribute und Operationen. Blieben diese leer, lassen Sie beide Abteilungen aus dem Diagramm weg. Im untersten Teil geben Sie Ihre Aufzählungsbuchstabensymbole ein. Beispielsweise besteht die Aufzählung von Rosenarten in einem Blumengeschäft aus dem Kopf mit dem Titel „Rosenarten“ und dem Körper mit einer Liste: Teerosen, Noisette-Rosen, Gallica-Rosen, Bourbon-Rosen, Zimtrosen.

Klassendiagramme stellen Beziehungen zwischen Systemelementen dar. So soll der Betrachter sehen, welche Komponenten das System benötigt und wie sie sich gegenseitig beeinflussen. Das UML-Element Beziehung ist eine abstrakte Klasse. Es steht für die Idee einer Beziehung zwischen Systemkomponenten. Somit besitzt dieses Element keine gesonderte Notation. Seine Ausprägungen weisen jedoch spezifische Details auf, die sie unterscheiden.

Beziehungen werden in UML als Kanten zwischen Knoten verstanden. Somit modellieren Sie Beziehungen generell mit einer Linie bzw. mit Abwandlungen davon – wie dem Pfeil.

Die UML-Definition zu Beziehungs-Subklassen und Instanzen hat sich von UML 1 zu UML 2 teilweise drastisch geändert. Ursprünglich gab es beispielsweise semantische, strukturelle und gerichtete Beziehungen. Drei konkrete Beziehungen (Assoziation, Einschränkung und Abhängigkeit) ordnete UML den semantischen Beziehungen zu. Unter UML 2 sind Einschränkungen inzwischen packbare Elemente, Assoziationen definieren einige Quellen als strukturelle und semantische Beziehung. Die Abhängigkeit läuft nun unter gerichteten Beziehungen.

Es bleibt zu abzuwarten, wie sich der Standard in künftigen Versionen ändert. Nachfolgend erläutern wir Klassendiagramme weiterhin nach UML 2.5. Demnach hat die Metaklasse Beziehung zwei Subklassen: die gerichtete Beziehung und die Assoziation.

Die Unterart Komposition (Composite Aggregation) beschreibt die Beziehung zwischen einer Zusammensetzung von Teilen und einem einzelnen Teil davon. Löscht das System das Ganze (die Zusammensetzung), zerstört es auch den einzelnen Teil. Ist z. B. ein Baum das Ganze, dann ist ein Blatt ein Teil davon. Fällt der Baum einem Waldbrand zum Opfer, zerstört der Brand auch die Blätter. Wenn Sie beispielsweise ein Klassendiagramm erstellen und diese Beziehung darstellen, zeichnen Sie eine durchgezogene Linie zwischen den Instanzen. Modellieren Sie einen schwarz gefüllten Rhombus auf die Seite der Zusammensetzung (in diesem Beispiel: die Instanz „Baum“). Diese Seite nennt man auch Aggregationsende.

Die zweite Unterart der Aggregation ist die geteilte Aggregation (abgekürzt auch einfach Aggregation). Diese asymmetrische Beziehung besteht zwischen einer Eigenschaft (Property) und einer Instanz, die für eine Menge von Instanzen steht. Die Verbindung sollte direkt erfolgen. Andernfalls könnte eine Kompositionsinstanz als Teil ihrer selbst interpretiert werden. Das kann passieren, wenn Sie die Abhängigkeitsbeziehung zyklisch modellieren. Die geteilte Eigenschaft kann zu mehreren Kompositionen gehören. Gleichzeitig kann ihre Instanz unabhängig von der Komposition existieren. Löscht das System in diesem Fall eine Komposition (oder alle), kann die Teilinstanz weiter bestehen. Deshalb gilt diese Beziehung als schwach im Vergleich zur Komposition.

Außerdem bietet die Assoziation noch eine Besonderheit: die Assoziationsklasse. Sie ist gleichzeitig Klasse und Beziehung. Somit können Sie der Assoziationsklasse im Klassendiagramm Attribute zuweisen.

Die Subklasse spezifiziert die allgemeine Klasse. Das heißt auch, dass die Subklasse einige Eigenschaften – inhaltlich wie strukturell – mit der Superklasse teilt, meist die grundlegenden Elemente. Dieser Umstand nennt sich Vererbung. So teilt die Klasse Dahlie im Beispiel den körbchenförmigen Blütenstand mit der Superklasse Korbblütler. Ein spezifisches Merkmal des Genus Dahlie sind seine acht Chromosomenpaare – andere Pflanzen haben meist nur zwei Chromosomenpaare. Die unterschiedlichen Dahlien-Arten bilden daher vielfältigere Erscheinungsmerkmale aus.

Implizit erlaubt UML die multiple Vererbung. Damit modellieren Sie mehrere Subklassen, die sowohl gemeinsame als auch unterschiedliche Superklassen aufweisen. Alternativ existieren mehrere Ebenen der Verallgemeinerung. Diese Beziehungen können Sie entweder mit der Pfeil-Notation darstellen oder Sie verschachteln die Subklassen in ihren Superklassen. Dafür modellieren Sie alle zugehörigen Subklassen im Körper der Superklasse.

Das Verallgemeinerungs-Set (Generalization Set) hilft Ihnen, Übersicht im Klassendiagramm zu wahren. Das Set ist ein packbares Element. Pakete in UML sind Behälter für benannte Elemente, die semantische Ähnlichkeiten haben und sich ggf. gemeinsam verändern. Ein Paket ist ein Namensraum und keine Klasse. Das Verallgemeinerungs-Set können Sie aber mit einem Klassifizierer assoziieren. Dieser nennt sich Powertyp.

Sie modellieren den Powertyp als String an der Verallgemeinerungskante in dieser Form: {[isCovering Property] , [isDisjoint Property]} : [Name des Powertyps]. Die Eigenschaft isCovering beschreibt, ob das Set vollständig ist. Die Werte sind entweder complete (vollständig) oder incomplete (unvollständig). Die Eigenschaft isDisjoint sagt aus, ob die Klassifizierer gemeinsame Instanzen teilen. Die Werte sind entweder disjoint (keine Überlappung) oder overlapping (Überlappung besteht).

Die Abstraktion verbindet Elemente auf verschiedenen Ebenen. Alternativ zeigt sie verschiedene Blickwinkel auf. Die benannten Elemente in dieser Abhängigkeitsbeziehung stehen für dasselbe Konzept. Dabei ist das spezifischere Element laut UML-Standard der Klient, der abhängig vom Anbieter, dem abstrakteren Element, ist. Somit müssten das Pfeilende an der Subklasse und die Spitze an der Superklasse liegen. UML erlaubt aber auch eine umgekehrte Notation. Ist es Ihrer Meinung nach sinnvoller, wenn das abstrakte Element abhängig von seiner Subklasse ist, zeichnen Sie die Pfeilspitze an das spezifischere Element.

Die Abstraktion hat zwei Unterklassen: die Realisation (Realization) und die Ausprägung (Manifestation).

Die Realisation haben wir bereits in Bezug auf Schnittstellen erwähnt. Die Schnittstellenrealisation (InterfaceRealization) ist eine Spezifizierung der Realisation. Sie beschreibt eine Beziehung zwischen Klassifizierer und Schnittstelle. Der Klassifizierer nutzt die Schnittstelle, um seinem Klienten einen Service anzubieten. Die Schnittstelle führt diesen Service aus. Dafür muss der Klassifizierer den Vertrag erfüllen, den die Schnittstelle festschreibt. Die Notation für bereitgestellte und benötigte Schnittstellen finden Sie im Abschnitt „Schnittstellen“.

Die Ersetzung (Substitution) ist eine weitere Beziehung, die die Realisation spezifiziert. Sie besteht zwischen einem Ersatz-Klassifizierer und einem Vertrags-Klassifizierer. Der Ersatz-Klassifizierer erfüllt den Vertrag des anderen Klassifizierers. Während der Laufzeit ersetzen Instanzen des Ersatz-Klassifizierers potenziell Instanzen des Vertrags-Klassifizierers. Im Gegensatz zur Spezialisierung besteht keine strukturelle Ähnlichkeit zwischen Elementen der Substitution. Sie notieren die Substitution als Abhängigkeitskante (gestrichelter Pfeil mit offener Spitze) im Klassendiagramm und fügen das Schlüsselwort <<substitute>> an die Kante an.

Die Ausprägung beschreibt eine Beziehung zwischen einem Artefakt und einem oder mehreren Modellelementen. UML definiert Artefakte als Klassifizierer. Sie symbolisieren konkrete, physische Instanzen wie Archivordner. Die Ausprägung steht dafür, dass ein Artefakt ein verbundenes Element direkt ausführt. Umgekehrt kann es symbolisieren, dass Elemente an der Entstehung des Artefakts beteiligt sind. Die Ausprägung ist ein Element des Bereitstellungsdiagramms und wird hier nur der Vollständigkeit halber erwähnt. Sie verlangen dieselbe Notation wie Ersetzungen. Das Schlüsselwort ist <<manifest>>.

Die Abstraktion definiert zudem einige Stereotypen. Stereotypen gehören zu den UML-Profilen. Soll eine bestehende Metaklasse für ein Projekt erweitert werden, definiert man dafür ein Profil. Die Stereotyp-Klasse nutzt man immer zusammen mit der Metaklasse, da ein Profil nur Bestehendes ändert oder eine Terminologie hinzufügt. Seit UML 2.4.1 notiert UML Stereotypen mit Großbuchstaben am Anfang. Die Standard-Stereotypen für eine Abstraktion sind:

• Ableiten (<<Derive>>): Ein Element leitet sich von einem anderen Element ab. Meist sind sie vom gleichen Typ.
• Verfeinern (<<Refine>>): Ein Element gibt detailliertere Informationen für eine Klasse, die auch im anderen Element existiert. Die Elemente befinden sich auf verschiedenen Abstraktionsebenen. Beispielsweise verfeinert ein Modell auf ausführender Ebene seine Klasse „Mitarbeiter“ im Verhältnis zur Klasse „Mitarbeiter“ auf der Design-Ebene.
• Verfolgen (<<Trace>>): Unterschiedliche Modelle drücken verschiedene Aspekte eines Systems aus. Mit Mapping bzw. Tracing verfolgen Sie Elemente, die in verschiedenen Modellen dasselbe Konzept darstellen. Mit dem Trace können Sie Änderungen an den Elementen sowie Vorgaben nachvollziehen.

Die Bereitstellung zeigt die Beziehung zwischen einem Artefakt und seinem Einsatzziel. Im UML-Diagramm deutet die Bereitstellungskante von einem oder mehreren Artefakten auf das Einsatzziel (Deployment Target). Das Schlüsselwort für die Kante ist <<deploy>>. Diese Abhängigkeit können Sie auch auf dem Level von Instanzen anwenden. Alternativ modellieren Sie das Artefakt in den Körper des Einsatzziels. Dafür zeichnen Sie entweder das Artefakt als Symbol oder Sie listen die bereitgestellten Artefakte auf. Diese Abhängigkeit ist ein Teil der Notation für Bereitstellungsdiagramme.

Die Nutzung beschreibt eine Beziehung, in der der Klient den Anbieter benötigt, um seine Aufgaben vollständig zu erfüllen oder um Operationen auszuführen. Die Nutzung setzt also die allgemeine Abhängigkeit als Instanz um. Diese Abhängigkeit prägt einige konkrete Beziehungen aus:

• Nutzen (<<use>>): Ein Element nutzt ein anderes Element, jedoch sind die genauen Beziehungsteilnehmer und der genaue Nutzen nicht detailliert festgelegt.
• Erschaffen (<<create>>): Ein Klient-Klassifizierer oder eines seiner Struktur- bzw. Verhaltenselemente erschafft eine oder mehrere Instanzen des Anbieter-Klassifizierers.
• Aufrufen (<<call>>): Eine Operation ruft eine andere Operation auf. Das Ziel kann jegliche Operation im Umfeld der Quell-Operation sein, auch übergeordnete Klassifizierer.
• Senden (<<send>>): Eine Operation ist die Quelle, also der Klient. Ihr Ziel ist ein Signal. Die Abhängigkeit modelliert also, dass die Operation das Zielsignal sendet.
• Benötigte Schnittstelle (Required Interface ­­­-----C): Die benötigte Schnittstelle existiert, im Gegensatz zur bereitgestellten Schnittstelle, nicht im Klassifizierer. Sie bestimmt die Dienste, die ein Klassifizierer benötigt, um seine Funktionen für seinen Klienten auszuführen. Die Abhängigkeit besteht zwischen Klassifizierer und Schnittstelle. Mehr dazu lesen Sie im Abschnitt „Schnittstellen“.

Vorlagen-Bindung (Template Binding) ist die letzte gerichtete Beziehung, die im Klassendiagramm Anwendung findet. Wenn Sie ein Klassendiagramm erstellen, erweist es sich manchmal als nützlich, Vorlagen für Ihre Klassen anzufertigen. Vorlagen bestehen bei Klassen aus Vorlagen-Parametern. Diese Parameter gehören in die Vorlagen-Signatur. Die Signatur bestimmt die geordnete Menge an Parametern innerhalb der Vorlage. Modellieren Sie Klassen, die keine individuellen Eigenschaften aufweisen müssen, arbeiten Sie effizienter, wenn Sie Vorlagen verwenden. Soll aber eine Klasse feste Parameter erhalten, nutzen Sie die Vorlagen-Bindung. Die Beziehung besteht zwischen einem gebundenen Element und der Vorlagen-Signatur in einer Ziel-Vorlage.

Das gebundene Element ist vorlagenfähig, d. h. es kann zu einer Vorlage werden oder an andere Vorlagen gebunden werden. Das Element ist gebunden, weil es eine Verbindung zu einer Vorlage aufweist. Diese Verbindung beschreibt den Aufbau des Elements, indem es formelle Vorlagen-Parameter aus der Vorlage mit wertigen Parametern ersetzt.