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.
Klassendiagramme im Kontext der Unified Modeling Language
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.
UML-Klassendiagramme: Anwendungsgebiete
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.
Klassendiagramme: Notation laut UML
UML-Klassendiagramme bestehen aus Klassen und deren Instanzen (Objekte) sowie Schnittstellen. Sie stellen hierarchische Beziehungen sowie Assoziationen zwischen diesen Elementen her. Die Notation dieses Diagrammtyps ist der Grundbaustein für die meisten anderen Strukturdiagramme. UML 2 definiert Strukturdiagramme als Klassifizierer. Innerhalb der UML-Metamodellierung sind Paketdiagramme, Komponentendiagramme und dergleichen Subklassen des Strukturdiagramms. Dieses wird aber nicht modelliert, da es eine abstrakte Klasse ist. Das Klassendiagramm eignet sich am besten als Beispiel für ein Strukturdiagramm. Andere Diagramme dieser Kategorie nutzen abgewandelte Bausteine des Klassendiagramms für ihre Notation.
Als Klassifizierer (Englisch: Classifier) versteht UML eine abstrakte Metaklasse. Sie dient dazu, Modellelemente innerhalb der Modellierungssprache einem gemeinsamen Konzept zuzuordnen. Das nennt sich Generalisierung. So kann der Standard allgemein formuliert werden. Geht die Spezifikation auf ein bestimmtes Element ein, muss lediglich diese Besonderheit erklärt werden.
Die Klasse
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.
Die Instanz ist eine konkrete Ausprägung eines abstrakten Elements. Sie führt ein vorgeschriebenes Verhalten innerhalb der vorgegebenen Parameter aus. Manche Instanzen benennt UML explizit. So ist das Objekt eine benannte Instanz der Klasse. Eigenschaften von Instanzen modelliert man mit Diagrammen auf Instanz-Level. Statt eines Klassendiagramms zeichnen Sie dann beispielsweise ein Objektdiagramm.
Verkapselte Klassifizierer erweitern sogenannte strukturierte Klassifizierer. Letztere zeichnen sich dadurch aus, dass sie im Inneren eine Struktur vorschreiben und verbundene Elemente aufnehmen können. Diese Elemente (Metaklasse: ConnectableElements) beeinflussen das Verhalten der Klassifizierer. Jedes verbundene Element steht für einen Teilnehmer am Verhalten im Klassifizierer. Man sagt auch, sie übernehmen eine Rolle. Der verkapselte Klassifizierer besitzt zusätzlich eine Andockstelle (Port). Damit isoliert man den Klassifizierer vom System, ohne die Verbindung zu verlieren.
Verhaltensklassifizierer weisen häufig eine Verbindung zu einer Schnittstelle auf, die InterfaceRealization (Schnittstellenausführung). Der Klassifizierer stimmt implizit mit den Bedingungen der Schnittstelle überein, indem er den Funktionsumfang der Schnittstelle unterstützt. Die InterfaceRealization (auch „Lollipop“ genannt) zeichnen Sie als ungefüllten Kreis, der über eine Linie mit der Klasse verbunden ist.
Die genannten Metaklassen klassifizieren Objekte. Die Klasse ist die spezifische Ausprägung dieser Metaklassen. Somit bestimmt sie die Klassifizierung näher und konkretisiert die einzelnen Bestandteile, die die Struktur und das Verhalten der Objekte ausmachen. Klassen besitzen Eigenschaften, die sie (und ihre untergeordneten Objekte) beschreiben. Dazu gehören:
- Merkmale (Properties bzw. Attributes, wenn sie zur Klasse gehören)
- Operationen (Operations, können für ein Objekt aufgerufen werden)
- Signalempfänger (Receptions) seit UML 2.0
- Anschlüsse (Ports) seit UML 2.0
- Konnektoren (Connectors)
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 (Merkmale)
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
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.
Signalempfänger
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
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
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.
Multiplizitäten
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).
| Mengentyp | Einzigartig | Geordnet |
|---|---|---|
| Sequenz | Nein | Ja |
| Multimenge (Bag) | Nein | Nein |
| Geordnete Menge | Ja | Ja |
| Menge | Ja | Nein |
Einschränkung
Auch die Einschränkung (Constraint) soll hier erwähnt werden. In früheren UML-Versionen zählte dieses Element zu den Beziehungen. Inzwischen definiert UML die Einschränkung als packbares Element. Das heißt, dass sie direkt einem Paket gehören kann. Sie geht auch mit anderen Elementen solche Beziehungen ein, z. B. mit Klassen oder Merkmalen. Das beeinflusst die Notation jedoch nicht. Die Einschränkung stellt eine Bedingung oder Zusicherung für ihren Besitzer dar. Sie kann eines oder mehrere Elemente beeinflussen.
Das besitzende Element benötigt Zugriff auf die Einschränkung. Damit prüft es, ob die Einschränkung valide ist und ob sie erfüllt wurde. Es hängt vom Besitzer ab, wann das passiert. Einige Elemente, wie die Operation, verifizieren die Einschränkungen vor ihrer Ausführung, zwischendurch und/oder danach. Sie besitzen Vorbedingungen, Körperbedingungen und Nachbedingungen. Die Spezifikation, wann ein Element seine Einschränkung prüft, bezeichnet UML als Kontext. Man unterscheidet zwischen dem Kontext und der tatsächlichen Spezifikation. Letztere beschreibt, welches Element die Einschränkung absteckt, welchen Aspekt sie bewertet und welches Ergebnis sie erwartet. Die genaue Spezifizierung erhält ein Constraint durch eine boolesche Wertspezifizierung.
Die Notation besteht aus einer Textkette in folgender Form:
<Name des eingeschränkten Elements> ::= { <Name der Einschränkung> : <boolescher Ausdruck> }
UML schreibt keine Sprache vor. Sie haben die Wahl, welche Einschränkung Sie in welcher Sprache vornehmen wollen, wenn Sie Ihr Klassendiagramm erstellen. Nutzen Sie eine Programmiersprache wie Java, eine natürliche Sprache oder eine für Maschinen lesbare Sprache wie XML. Die Object Management Group, die den UML-Standard festlegt, veröffentlicht die Object Constraint Language (OCL). Diese Sprache definiert UML-kompatible Einschränkungen. Ihr Vorteil ist, dass sie sich nahtlos in die Notation einfügt.
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
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.
Seit UML 2.4 legt die Spezifikation fest: Das Label eines Stereotyps schreibt man am Anfang mit einem Großbuchstaben, etwa <<Type>>. Andere Label, etwa für Eigenschaften an Assoziationsenden, schreibt man durchgängig klein.
Man unterscheidet zwei Arten von Beziehungen zwischen (Meta-)Klasse und Stereotyp. Die benötigte Erweiterung (Notation: isRequired = true) definiert, dass ein Stereotyp mit jeder Instanz der Metaklasse im Klassendiagramm eine Verbindung eingeht. Die nicht benötigte Erweiterung (Notation: isRequired = false) erlaubt Ihnen, Instanzen der Metaklasse frei mit einem Stereotyp zu verknüpfen. Sie können den Stereotyp auch löschen. Jedoch darf eine bestimmte Instanz während der Laufzeit nur einmal mit einem bestimmten Stereotyp verknüpft sein.
Wollen Sie einen Stereotyp entfernen, löschen Sie das Profil, das ihn definiert, aus dem Bereich angewandte Profile (appliedprofiles) im übergeordneten Paket. Alternativ tilgen Sie die Instanz, die er erweitert.
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>>)
Fokus
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.
Geschäftslogik, auch Anwendungslogik, beschreibt die Logik eines Systems, die sich mit der Ausführung realer Geschäftsanforderungen befasst. Sie grenzt sich ab von der Logik, die die technische Ausführung vorschreibt. In der objektorientierten Programmierung brachte die Geschäftslogik das Konzept des Geschäftsobjekts hervor. Dieses modelliert konkrete Abläufe und reale Werte in einem Informationssystem.
Helfer
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.
Typ
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.
Anwendungsklasse
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.
Metaklasse
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.
Utility
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.
UML spezifiziert weitere Standard-Stereotypen für andere Diagrammtypen. Deren Anwendungsbereiche und Notation entnehmen Sie der UML-Spezifikation 2.5.1, Kapitel 22: Standard Profile, Tabelle 22.1, Seite 680.
Schnittstellen
Schnittstellen sind Klassifizierer. In ihrer Notation ähneln sie den Klassen. Im Gegensatz zur Klasse sind sie aber Deklarationen, d. h. sie deklarieren eine Menge logisch zusammenhängender, öffentlicher Funktionen und Verpflichtungen. Dafür nutzen sie einen Vertrag. Führt eine Instanz die Schnittstelle aus, muss sie diesen Vertrag erfüllen. Dabei spricht man davon, dass die Instanz einen Service laut Vertrag anbietet. Als Deklaration bildet die Schnittstelle selber keine Instanzen.
An dieser Stelle kommt die Klasse gelegen, denn sie instanziert. Ihre Instanz setzt Schnittstellenspezifikationen ein. Dafür muss sie den Vertrag der Schnittstelle erfüllen. Im Gegenzug nutzt sie das Interface als öffentliche Kulisse. Zudem kann ein Klassifizierer mehrere Schnittstellen einsetzen. Umgekehrt dient eine Schnittstelle auch mehreren Klassifizierern. Im UML-Klassendiagramm ähneln sich die Notationen von Schnittstelle und Klasse: ein Rechteck, optional mit drei durch Linien getrennten Bereichen.
Um zu zeigen, dass eine Klasse eine Schnittstelle einsetzt, nutzt man die Notation InterfaceRealization (bekannt von den Verhaltensklassifizierern). Diese repräsentiert eine bereitgestellte Schnittstelle (Provided Interface) – das ist eine Schnittstelle, die eine Instanz direkt ausführt. Letzteres gilt auch für übergeordnete Klassen wie die Komponente. Hat die Klasse einen öffentlichen Port, stellt dieser die Schnittstelle bereit. Die InterfaceRealization stellen Sie mit einem Kreis dar, der über eine Linie mit dem Klassifizierer verbunden ist.
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.
Datentypen
Datentypen vereinen eine Menge von Objekten mit deren Operationen. Dabei verwenden sie konkrete Wertebereiche und fügen diese mit ihren speziellen Operationen zusammen. Objekte können mehrere Typen haben. Deren Zahlenwerte reichen von primitiven Typen bis zu längeren Aufzählungen.
Datentypen sind Klassifizierer. Ihre Instanzen identifizieren Sie nur anhand ihres Wertes. Mit Datentypen visualisieren Sie Werttypen, primitive Typen und strukturierte Typen im UML-Klassendiagramm. Kopieren Sie eine Datentyp-Instanz oder modellieren zwei Instanzen desselben Datentyps mit demselben Wert, gelten diese als gleiche Instanzen.
Besitzt der Datentyp Attribute, ordnet ihn UML als strukturierten Datentyp ein. Dessen Instanzen gelten nur als gleich, wenn ihre Struktur und die Werte ihrer Attribute gleich sind.
Primitive Typen weisen keine untergeordnete Struktur auf, sondern stehen für atomare Datenwerte. Sie finden im Klassendiagramm auch bei Einschränkungen Anwendung. Meist weisen diese Typen eine komplexe Semantik außerhalb der UML-Spezifikation auf. In UML besitzen sie jedoch keine Identität, weshalb sie bei gleichem Wert nicht unterscheidbar sind. Das sind einige primitive Typen in UML:
- Boolean (boolesche Variablen)
- Integer (ganze Zahl)
- UnlimitedNatural (unbegrenzte, natürliche Zahl)
- Real (reale Zahlen)
- String (Zeichenkette)
Sie notieren primitive Typen mit dem Label <<primitive>> über dem Namen des jeweiligen Datentypen.
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.
Beziehungen
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 Assoziation
Die Assoziation ist eine Beziehung, die Tupel verbindet. In der Informatik sind Tupel geordnete Wertesammlungen. Im Gegensatz zur Menge spielen dabei logische Verbindung und Reihenfolge eine Rolle. Somit ist es nicht falsch, der Assoziation neben der offiziellen Bezeichnung als semantische Beziehung auch eine strukturelle Komponente zuzuweisen. Die Assoziation ist eine Verbindung zwischen Klassifizierern. Die Elemente in dieser Beziehung haben eine logische oder physische Nähe. Je nach Anzahl der Mitglieder nennt man die Assoziation binär (zwei Instanzen), ternär (drei Instanzen) oder n-är (ab vier Instanzen).
Assoziationsenden verbinden im UML-Klassendiagramm Assoziationen mit Instanzen. Das Assoziationsende hat einen Endnamen. Dieser Name drückt die Rolle der Instanz in der jeweiligen Beziehung aus. Nehmen wir an, ein Student dreht mehrere Versionen eines Kurzfilms für ein Filmseminar. Dann wäre die Rolle des Filmstudenten zum Film „Schöpfer“. Die Rolle des Films wäre „Seminararbeit“. Den Namen schreiben Sie unter die Verbindungslinie, jeweils an das Instanzsymbol, das es beschreibt. Das Ende gehört entweder der Assoziation selbst oder dem End-Klassifizierer. Bei mehr als zwei Enden gehört die Rolle zur Assoziation.
Der Pfeil neben dem Assoziationsnamen im oberen Klassendiagramm zeigt die Richtung der Beziehung an. Im unteren Diagramm signalisiert der Punkt an der Instanz „Film“, dass das Assoziationsende „Seminararbeit“ der Instanz „Filmstudent“ gehört. Da das Assoziationsende „Schöpfer“ keine solche Markierung aufweist, gehört Sie der Assoziation selbst. Die Multiplizität „1“ zeigt an, dass genau eine Instanz „Filmstudent“ existiert. Die Instanz „Film“ hat mindestens drei Ausbildungen.
Die Navigierbarkeit ist eine Endeigenschaft (End Property). Sie zeigt an, ob eine Instanz an diesem Ende der Assoziation vom anderen Ende der Assoziation erreichbar ist. Ist Instanz B erreichbar für Instanz A, zeichnen Sie auf die Assoziationskante eine offene Pfeilspitze in Richtung Instanz B direkt an das Instanzsymbol B. Ist Instanz D nicht erreichbar für Instanz C, zeichnen Sie ein X auf die Linie bei Instanz D. Wollen Sie keine Navigierbarkeit angeben, zeichnen Sie keine gesonderte Notation.
Es gibt zwei Varianten der Assoziation: die Verbindung (Link) und die Aggregation.
- Die Verbindung (Link) ist eine Instanz der Assoziation. Sie verfügt über mindestens zwei Enden, die jeweils eine Multiplizität haben. Dieser Wert muss eine Instanz des Datentyps der Enden sein. In unserem Beispielbild oben filmt ein Filmstudent drei Filme während der Studienzeit. Der Wert für die Instanz „Student“ ist „1“. Der Wert für die Instanz „Film“ ist „3“. Die Verbindung modellieren Sie als durchgezogene Linien zwischen Beziehungsteilnehmern. Im Gegensatz zur Assoziation verbindet der Link Instanzen und keine Klassifizierer.
- Die Aggregation ist eine binäre Assoziation. Sie hat also immer zwei Teilnehmer. Im Gegensatz zum Link stellt Sie keine Beziehungen auf gleicher Ebene her. Stattdessen zeigt sie Beziehungen zwischen einem Teil und dem Ganzen. Die Aggregation stellen Sie durch eine Eigenschaft am Assoziationsende dar. Sie modellieren einen Rhombus an der Instanz, die für das Ganze steht.
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 gerichtete Beziehung
Die gerichtete Beziehung ist eine abstrakte Klasse. Sie beschreibt Beziehungen zwischen einer Quelle und einem Ziel. Beide Enden der Beziehung können mehrere Elemente aufweisen. Wie die Assoziation hat die gerichtete Beziehung ebenfalls keine festgelegte Notation. Ihre Unterklassen bilden spezifische Formen aus. Diese basieren auf einer Linie von der Quelle zum Ziel. Folgende Instanzen prägen eine gerichtete Beziehung aus:
- Verallgemeinerung (Generalization)
- Abhängigkeit (Dependency)
- VorlagenBindung (Template Binding)
- Einbeziehen (Include): gehört zur Notation für Anwendungsfalldiagramme
- Erweitern (Extend): gehört zur Notation für Anwendungsfalldiagramme
Die Verallgemeinerung ist eine binäre Beziehung zwischen Klassen. Sie richtet sich von einer Subklasse zu einer Superklasse – also von einer bestimmten zu einer allgemeineren Klasse. Die bestimmte Klasse (z. B. Dahlie) besitzt die Verallgemeinerung. Ein Pfeil mit geschlossener, aber nicht gefüllter Pfeilspitze zeigt von dieser Quelle zum Ziel. Das Ziel ist die allgemeine Klasse (z. B. Korbblütler).
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.
Umgangssprachlich werden Verallgemeinerungen auch als „ist ein …“-Beziehungen bezeichnet. Denn man kann sagen: „Eine Dahlie ist ein Korbblütler.“
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 Standardisierung UML 2.5 gibt wenig Auskunft zur Vererbung. Sie können sich jedoch nach vorherigen Versionen richten. UML 2 erklärt allgemein, dass spezialisierte Klassen die Merkmale und Einschränkungen ihrer Superklassen übernehmen. UML 1.4 spezialisierte, dass deklarierte Attribute in einer Subklasse vererbte Attribute überschreiben.
Die Abhängigkeit (Dependency) ist eine Beziehung zwischen „Anbieter“ und „Klient“ (supplier-client-relationship). Diese gerichtete Beziehung beschreibt, dass ein Element abhängig von einem anderen Element ist. Es kann sich auch um eine Menge an Elementen handeln. Der Klient benötigt ein anderes Element für die nähere Spezifikation oder um seine Aufgabe auszuführen. Ohne den Anbieter fehlt dem Klienten ein struktureller oder semantischer Bestandteil. Deshalb wirken sich Veränderungen am Anbieter möglicherweise auf den Klienten aus. Laut UML 2.5 beeinflusst die Semantik immer das genannte Element, aber nicht dessen Instanzen. Abhängigkeiten spielen nicht nur im UML-Klassendiagramm eine Rolle, sondern auch in anderen Strukturdiagrammen wie dem Komponentendiagramm oder dem Bereitstellungsdiagramm.
Die Abhängigkeit hat drei Unterkategorien:
- Abstraktion (Abstraction)
- Bereitstellung (Deployment)
- Nutzung (Usage)
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.
Mithilfe dieser Abstraktionsstereotypen mappen Sie die Beziehung zwischen Klient und Anbieter. Dieser Prozess kann beidseitig oder einseitig und formal oder informal stattfinden. Klient und Anbieter befinden sich in unterschiedlichen Diagrammen, z. B. in einem Klassendiagramm und in einem Anwendungsfalldiagramm.
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.
Fazit
Das Klassendiagramm ist eines der beliebtesten UML-Diagramme, weil es Systemstrukturen sowohl detailliert als auch übersichtlich darstellt. Als Strukturdiagramm zeigt es das System im statischen Zustand. So erhalten die Betrachter einen Überblick über die notwendigen Elemente in einem System. Zudem stellen Sie damit Beziehungen zwischen den Bausteinen Ihrer Systemarchitektur dar. Von realen Objekten bis zu abstrakten Klassen mit erweiternden Profilen modellieren Sie mit dem UML-Klassendiagramm unabhängig von der Programmiersprache. So fördern Sie das Verständnis zwischen Fachbereichen bei der Umsetzung eines Projekts.