Klassendiagramm

Klasse

Eine Klasse (Class) beschreibt eine Menge von Instanzen, die dieselben Merkmale, Zusicherungen und Semantik haben.

Klassen werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse tragen oder zusätzlich auch Attribute und Operationen. Dabei werden diese drei Rubriken (Compartments) – Klassenname, Attribute, Operationen – jeweils durch eine horizontale Linie getrennt. Klassennamen beginnen gewöhnlich mit einem Großbuchstaben und sind meist Substantive im Singular (Sammlungsklassen u. Ä. ggf. im Plural).

Die Attribute einer Klasse werden mindestens mit ihrem Namen aufgeführt und können zusätzlich Angaben zu ihrem Typ, einen Initialwert, Eigenschaftswerte und Zusicherungen enthalten. Methoden werden ebenfalls mindestens mit ihrem Namen, zusätzlich mit möglichen Parametern, deren Typ und den Initialwerten, sowie eventueller Eigenschaftswerte und Zusicherungen notiert.

Abb. 30: Beispiel Klasse

Sichtbarkeitsbereich

Der Sichtbarkeitsbereich (Scope) der Klassenelemente wird mit einem Zeichen vor dem Namen gekennzeichnet. Ist ein Element öffentlich sichtbar, steht vor dem Namen das Zeichen +. Private Elemente erhalten das Zeichen – vorangestellt. Das Zeichen # vor dem Namen bedeutet, dass das Klassenelement mit dem Zugriffsattribut protected gekennzeichnet ist. Protected bedeutet eine Erweiterung von private – Tochterklassen erben Attribute, die als protected gekennzeichnet sind.

~ vor dem Namen bedeutet Package – eine Einschränkung von public; nicht unbegrenzte öffentliche Sichtbarkeit, sondern begrenzt auf das Package.

Abstrakte Klasse

Von einer abstrakten Klasse werden niemals Instanzen erzeugt. Sie ist bewusst unvollständig und bildet somit die Basis für weitere Unterklassen, die Instanzen haben können. Eine abstrakte Klasse wird wie eine normale Klasse dargestellt, jedoch wird der Klassenname kursiv gesetzt.

Stereotype

Durch Stereotype können z. B. abstrakte Klassen gekennzeichnet werden. Die Angabe des Stereotyps erscheint ober dem Klassennamen in französischen Anführungsstrichen « ». Stereotype können auch durch unterschiedliche Farben oder durch die Kursivschreibweise des Namens der Klasse sichtbar gemacht werden.

Objekt

Objekte sind die konkreten, agierenden Einheiten einer objektorientierten Anwendung. Sie werden nach einem Bauplan, der Klassendefinition, im Speicher erzeugt. Jedes Objekt hat eine eigene Identität. Ein Objekt besitzt ein bestimmtes Verhalten, das durch seine Methoden bestimmt ist. Zwei Objekte der gleichen Klasse haben das gleiche Verhalten. Objekte besitzen weiters Attribute, die bei Objekten derselben Klasse gleich sind. Der Zustand eines Objekts wird durch die Werte bestimmt, die in den Attributen gespeichert sind. Deshalb sind zwei Objekte einer Klasse gleich, wenn die Werte in den Attributen übereinstimmen.

Im Diagramm werden Objekte analog zu den Klassen mit einem Rechteck gezeichnet. Der Name wird unterstrichen, um sie von den Klassen unterscheiden zu können. Dem Namen des Objekts wird nach einem Doppelpunkt der Klassenname angefügt. Hat für den zu modellierenden Fall der konkrete Objektname keine Bedeutung, kann dieser auch entfallen. Es werden dann nur ein Doppelpunkt und der Klassenname dargestellt. Da die Methoden in der Objektdarstellung uninteressant sind, werden diese nicht angegeben.

Eigenschaften (Attribute)

Ein Attribut ist ein (Daten-)Element, das in jedem Objekt einer Klasse gleichermaßen enthalten ist und von jedem Objekt mit einem individuellen Wert repräsentiert wird.

Anders als in der UML 1.x wird in der UML 2.0 und danach nicht mehr strikt zwischen Attributen und Assoziationsenden unterschieden. Das heißt, die Darstellung als Attribut in einer Klasse oder als navigierbare Assoziation ist gleichbedeutend.

Jedes Attribut wird mindestens durch seinen Namen beschrieben. Zusätzlich können ein Typ, die Sichtbarkeit, ein Initialwert u. Ä. definiert werden. Die vollständige Syntax lautet, wie folgt

[Sichtbarkeit][/]Name[:Typ][Multiplizität][=Initialwert]

Methoden (Operationen)

Eine Klasse muss für jede Nachricht, die sie empfängt, eine zuständige Methode besitzen. Über eine Methode stellt eine Klasse anderen Klassen Funktionalität zur Verfügung. Über Nachrichten, sprich Methodenaufrufe, kommunizieren die aus den Klassen installierten Objekte untereinander und erreichen so eine Koordinierung ihres Verhaltens. Objekte und ihre Kommunikation über Methodenaufrufe werden in der Gruppe der Interaktionsdiagramme dargestellt.

Beziehungen

Es gibt vier verschiedene Arten von Beziehungen zwischen Klassen, wobei die Generalisierung eine Sonderform ist, die anderen drei – Assoziation, Aggregation und Komposition – sind einander sehr ähnlich sind.

Assoziation

Die Assoziation stellt die Kommunikation zwischen zwei Klassen im Diagramm dar. Die Klassen werden mit einer einfachen Linie verbunden. Mithilfe eines Pfeils kann man eine gerichtete Assoziation modellieren.

Jede Assoziation kann mit einem Namen versehen werden, der die Beziehung näher beschreibt. Der Name kann zusätzlich mit einer Leserichtung – einem kleinen ausgefüllten Dreieck – versehen werden. Diese Richtung bezieht sich nur auf den Namen und hat keinen Bezug zur Navigierbar- keit der Assoziation.

Auf jeder Seite der Assoziation können Rollennamen dazu verwendet werden, genauer zu beschreiben, welche Rolle die jeweiligen Objekte in der Beziehung einnehmen. Die Rollen sind die Namen der Eigenschaften (Attribute), die der Assoziation oder einer der beteiligten Klassen gehören.

Assoziationen werden in Programmiersprachen in der Regel dadurch realisiert, dass die beteiligten Klassen entsprechende Attribute erhalten.

Eine Rolle repräsentiert also eine Eigenschaft. Außer Rollennamen können auch Sichtbarkeitsangaben auf jeder Seite der Assoziation angebracht werden. Ist beispielsweise ein Assoziationsende als privat (-) deklariert, so kann das Objekt selbst, d. h. die Operationen des Objekts, die Assoziation benutzen, benachbarte Klassen erhalten jedoch keinen Zugriff.

Eine gerichtete Assoziation wird wie eine gewöhnliche Assoziation notiert, jedoch hat sie auf der Seite der Klasse, zu der navigiert werden kann, also in Navigationsrichtung, eine geöffnete Pfeilspitze.

Multiplizität und Rollenname können theoretisch jedoch auch auf der Seite notiert werden, zu der nicht navigiert werden kann. Sie bezeichnen dann eine Eigenschaft (Property), die zu keiner Klasse gehört, sondern zur Assoziation.

In dem Beispiel würde die Klasse „Kunde“ ein Attribut „konto“ als Referenz auf ein Objekt der Klasse Kundenkonto erhalten und die Klasse Kundenkonto ein privates Attribut „bpos“ mit einem Sammlungsobjekt (Collection bzw. Unterklasse davon), welches die Buchungsposition- Objekte referenziert.

Gelesen werden diese Beziehungen in folgender Weise:

• Eine Veranstaltung hat einen
• Ein Saalplan ist einer Spielstätte

Der Pfeil sagt aus, dass die Kommunikation überwiegend vom Saalplan ausgeht (bei der Implementierung erhält deshalb die Klasse eine Referenz auf die Spielstätte).

Dabei werden die Kardinalitäten vor der Zielklasse gelesen.

Multiplizität

In der UML gibt es den Begriff Multiplizität, um die Menge möglicher Ausprägungen zu beschreiben. Die Multiplizität wird durch einen minimalen Wert und einen maximalen Wert beschrieben, z. B. 3..7. Ist der minimale Wert gleich dem maximalen Wert kann die Unter- oder Obergrenze entfallen. Es wird dann anstelle von 3..3 lediglich 3 geschrieben. Ist die untere Grenze 0, so bedeutet dies, dass die Beziehung optional ist.

In der UML wird auch der Begriff Kardinalität verwendet, um die Anzahl konkreter Ausprägungen zu beschreiben.

Der Begriff Kardinalität hat seinen Ursprung in der Datenmodellierung und dort die gleiche Bedeutung wie die Multiplizität in der UML. In der UML werden beide Begriffe verwendet und somit feiner zwischen möglichen Ausprägungen und tatsächlichen Ausprägungen unterschieden. Die Kardinalität beschreibt z. B. beim Objektmodell die konkrete Anzahl assoziierter Objekte.

Assoziationsklasse

Klassen können aber auch kombinatorisch untereinander in Beziehung stehen. Betrachtet man die Beziehungen zwischen Kunde, Konto und Bankomatkarte, dann stellt sich heraus, dass eine Bankomatkarte für eine Kombination aus einem Kunden und einem Konto existiert und das ist etwas gänzlich anderes, als die Karte mit Kunde und Konto direkt zu assoziieren. Die UML stellt dafür die Schreibweise Assoziationsklasse zur Verfügung:

Eine Besonderheit der Assoziationsklasse ist, dass es nur genau eine Instanz der assoziierten Klasse pro Referenz geben darf. Im Beispiel darf es also nur eine Instanz von Bankomatkarte für eine Kombination aus Kunde und Konto geben.

Sind mehrere Klassen beteiligt, dann wird der Assoziationsknoten (n-äre Assoziation) verwendet.

Die n-äre Assoziation hat ihren Ursprung in der Datenmodellierung (Entity Relationship Modelle) und wird in der UML mit identischer Semantik verwendet. Alle an der Assoziation beteiligten Klassen bilden eine Einheit. Im Beispiel bedeutet dies, dass (Flugticket, Datum, Flug, Passagier) eine Einheit bilden und als Gesamtes eine Bedeutung haben, die Teilnahme an einem konkreten Flug. Die Bedeutung wird meist im Namen der Assoziation (Raute) ausgedrückt.

Wichtig bei der n-ären Assoziation ist das setzen der Multiplizitäten, d. h. welche Kombinationen von Objektausprägungen sind gültig. Um die Multiplizitäten richtig setzen zu können, denken Sie für n-1 Elemente eine Multiplizität von 1 und setzen die Multiplizität des n-ten.

Zum Beispiel: Ein Passagier hat für einen Flug an einem Datum genau ein Flugticket. Falls es möglich sein sollte, dass der Passagier mehrere Tickets für denselben Flug am gleichen Datum besitzen darf, muss die Multiplizität bei Flugticket größer als 1 sein (z. B. *).

Aggregation

Eine Aggregation ist eine Assoziation, erweitert um den semantisch unverbindlichen Kommentar, dass die beteiligten Klassen keine gleichwertige Beziehung führen, sondern eine „Teil von“- Beziehung darstellen. Eine Aggregation soll beschreiben, wie sich etwas Ganzes aus seinen Teilen logisch zusammensetzt.

Eine Aggregation wird wie eine Assoziation als Linie zwischen zwei Klassen dargestellt und zusätzlich mit einer kleinen Raute versehen. Die Raute steht auf der Seite des Aggregats, also des Ganzen. Sie symbolisiert gewissermaßen das Behälterobjekt, in dem die Einzelteile gesammelt sind. Im Übrigen gelten alle Notationskonventionen der Assoziation.

Komposition

Eine Komposition ist eine strenge Form der Aggregation, bei der die Teile vom Ganzen existenz-abhängig sind. Sie beschreibt, wie sich etwas Ganzes aus Einzelteilen zusammensetzt. Die Komposition wird wie die Aggregation als Linie zwischen zwei Klassen gezeichnet und mit einer kleinen Raute auf der Seite des Ganzen versehen. Im Gegensatz zur Aggregation wird die Raute jedoch ausgefüllt.

Falls die Multiplizität für Teile (Motor) von null beginnt (0..*), dann kann das Ganze auch ohne Teile existieren, bzw. beliebig viele Teile beinhalten. Falls die Multiplizität des Ganzen (PKW/Boot) null bis eins (0..1) beträgt, dann kann das Teil auch ohne Ganzem existieren, sobald jedoch das Teil zum Ganzen gehört, wird es nicht mehr getrennt und es entsteht eine existenz- abhängige Beziehung.

Existenzabhängig bedeutet, dass das Teil ohne seinem Ganzen nicht existieren kann und wenn das Ganze zerstört wird, müssen, auch alle seine Teile zerstört werden.

• Ein Saalplan hat beliebig viele Plätze, aber mindestens einen.
• Ein Platz gehört genau zu einem Saalplan
• Jeder Saalplan gehört zu einer Veranstaltung
• Eine Veranstaltung kann beliebig viele Saalpläne
• Der Saalplan könnte auch zu einer anderen Veranstaltung zugeordnet werden (Aggregation), muss allerdings immer eine Veranstaltung haben.
• Der Platz gehört zu einem Saalplan, diese Beziehung kann nicht geändert werden (Komposition)

Generalisierung/ Spezialisierung

Eine Generalisierung ist eine Beziehung zwischen einer allgemeinen und einer speziellen Klasse, wobei die speziellere weitere Merkmale hinzufügen kann und sich kompatibel zur allgemeinen Klasse verhält.

Bei der Generalisierung bzw. Spezialisierung werden Merkmale hierarchisch gegliedert, d. h., Merkmale allgemeinerer Bedeutung werden allgemeineren Elementen zugeordnet und speziellere Merkmale werden Elementen zugeordnet, die den allgemeineren untergeordnet sind. Die Merkmale der Ober-Elemente werden an die entsprechenden Unter-Elemente weitergegeben, d.h. vererbt. Ein Unter-Element verfügt demnach über die in ihm spezifizierten Merkmale sowie über die Merkmale seiner Ober-Elemente. Unter-Elemente erben alle Merkmale ihrer Ober- Elemente und können diese um weitere erweitern oder überschreiben

Mit dieser Form werden hierarchische Vererbungsbäume modelliert. Vererbungsbäume sind ein wichtiges Gestaltungselement bei der Modellierung von Softwarearchitekturen. In der Abbildung wird beispielsweise modelliert, dass Veranstaltungen Inhouse- oder Gastveranstaltungen sein können.

Abhängigkeiten (Dependencies)

Eine Abhängigkeit (Dependency) ist eine Beziehung von einem (oder mehreren) Quellelement(en) zu einem (oder mehreren) Zielelement(en).

Die Zielelemente sind für die Spezifikation oder Implementierung der Quellelemente erforderlich. Dargestellt wird eine Abhängigkeit durch einen gestrichelten Pfeil, wobei der Pfeil vom abhängigen auf das unabhängige Element zeigt. Zusätzlich kann die Art der Abhängigkeit durch ein Schlüsselwort oder Stereotyp näher spezifiziert werden.

Da das Quellelement bei einer Abhängigkeitsbeziehung das Zielelement für seine Spezifikation oder Implementierung benötigt, ist es ohne das Element unvollständig.

Abhängigkeiten können unterschiedliche Ursachen haben. Einige Beispiele hierfür sind:

• Ein Paket ist von einem anderen abhängig. Die Ursache kann hierbei beispielsweise darin bestehen, dass eine Klasse in dem einen Paket von einer Klasse in dem anderen Paket abhängig
• Eine Klasse benutzt eine bestimmte Schnittstelle einer anderen Wenn die angebotene Schnittstelle verändert wird, sind in der schnittstellennutzenden Klasse ebenfalls Änderungen erforderlich.
• Eine Operation ist abhängig von einer Klasse, beispielsweise wird die Klasse in einem Operationsparameter Eine Änderung in der Klasse des Parameters macht möglicherweise eine Änderung der Operation erforderlich.

Die Abstraktionsbeziehung (Abstraction) ist eine spezielle Abhängigkeitsbeziehung zwischen Modellelementen auf verschiedenen Abstraktionsebenen. Die Beziehung wird wie eine Abhängigkeitsbeziehung notiert. Sie können aber nicht verwechselt werden, da die Abstraktion immer zusammen mit einem Stereotyp verwendet wird. Die UML definiert die Standard-Stereotype «de- rive», «trace» und «refine».

Zu einer Abstraktionsbeziehung gehört auch immer eine Abbildungsvorschrift, wie die beteiligten Elemente zueinanderstehen (Mapping). Die Angabe kann formal oder informal sein. Eine Abstraktionsbeziehung kann trotz der Pfeilrichtung je nach Stereotyp und Abbildungsvorschrift auch bidirektional sein, z. B. häufig die «trace»-Beziehung.

Eine spezielle Abstraktionsbeziehung ist die Realisierungsbeziehung (Realization). Es ist eine Beziehung zwischen einer Implementierung und ihrem Spezifikationselement.

Die Substitutionsbeziehung (Substitution) ist eine spezielle Realisierungsbeziehung. Sie gibt an, dass Exemplare des unabhängigen Elementes zur Laufzeit durch Exemplare des abhängigen Elementes substituiert werden können, z. B. da die Elemente dieselben Schnittstellen implementieren.

Die Verwendungsbeziehung (Usage) ist eine spezielle Abhängigkeitsbeziehung. Der Unterschied zur Abhängigkeitsbeziehung ist, dass die Abhängigkeit sich nur auf die Implementierung beschränkt und nicht für die Spezifikation gilt. Das heißt, das abhängige Element benötigt das unabhängige Element für seine Implementierung. Es kann also keine Verwendungsbeziehungen zwischen Schnittstellen geben, aber dafür die Abhängigkeitsbeziehung.

Die Berechtigungsbeziehung (Permission) ist eine spezielle Abhängigkeitsbeziehung, die dem abhängigen Element Zugriffsrechte auf das unabhängige Element erteilt.

Schnittstellen

Schnittstellen (Interfaces) sind spezielle Klassen, die mit einer Menge von Merkmalen (Features) einen ausgewählten Teil des extern sichtbaren Verhaltens von Modellelementen (hauptsächlich von Klassen und Komponenten) spezifizieren.

Die Implementierungsbeziehung (Implementation) ist eine spezielle Realisierungsbeziehung zwischen einer Klasse und einer Schnittstelle. Die Klasse implementiert die in der Schnittstelle spezifizierten Merkmale.

Schnittstellen werden wie Klassen notiert, sie tragen jedoch das Schlüsselwort «interface».

Es werden bereitgestellte und benötigte Schnittstellen unterschieden. Eine bereitgestellte Schnittstelle wird von einem Modellelement angeboten und kann von anderen verwendet werden. Eine benötigte Schnittstelle ist eine Schnittstelle, die von einem anderen Modellelement eingefordert wird.

Schnittstellen spezifizieren nicht nur Operationen, sondern auch Attribute. Entsprechend dürfen Schnittstellen auch Assoziationen zu anderen Schnittstellen oder Klassen haben.

Klassen, die eine Schnittstelle implementieren wollen, müssen alle in der zugehörigen Schnittstelle definierten Operationen implementieren. Bezüglich der in der Schnittstelle definierten Attribute muss sich die implementierende Klasse so verhalten, als ob sie die Attribute besitzt. Im einfachsten Fall implementiert sie die Attribute wirklich. Es genügt aber auch, z. B. nur die entsprechenden get() und set() Methoden anzubieten.

Eine Klasse kann mehrere Schnittstellen implementieren und darüber hinaus weitere Eigenschaften enthalten oder anders ausgedrückt: Eine Schnittstelle beschreibt in der Regel eine Untermenge der Operationen und Attribute einer Klasse.

Aus der aktuellen Spezifikation geht nicht klar hervor, ob für die Implementierungsbeziehung der gestrichelte Pfeil mit Schlüsselwort «realize» oder wie in der UML 1.x die gestrichelte Generalisierungsbeziehung verwendet wird. Wir nehmen hier Letzteres an, da diese Variante auch für die praktische Arbeit wesentlich besser geeignet ist.

Die Implementierungsbeziehung wird mit einem speziellen Pfeil notiert. Die andere Möglichkeit, die Implementierung einer Schnittstelle darzustellen, ist ein kleiner, nicht ausgefüllter Kreis, der durch eine Linie mit der Klasse verbunden ist, der die Schnittstelle anbietet. Dies soll einen Stecker symbolisieren. Daneben wird der Name der Schnittstelle genannt; er entspricht dem Namen der zugehörigen Schnittstelle.

Bei der Pfeilschreibweise besteht die Möglichkeit, die durch die Schnittstelle geforderten Operationen und Attribute abzulesen. Bei der Kurznotation sieht man die von der Schnittstelle geforderten Operationen und Attribute nicht, sondern nur den Namen der Schnittstelle.

Bereitstellung und Anforderung einer Schnittstelle können ebenso durch die Kombination der beiden Kurznotationen dargestellt werden, indem man den Stecker in die Buchse steckt.

Vor der letzten Darstellung sei allerdings gewarnt: Die „Assembly“ gehört im Gegensatz zu den Symbolen für bereitgestellte Schnittstelle und benutzte Schnittstelle in die Kategorie Konnektor. Ein durchgängiges Modellieren mit einem Instance-Classifier-Verweis auf die Schnittstellen-Beschreibung wird nicht möglich sein. Vermeiden Sie daher diese Schreibweise.

Die Abbildung zeigt, dass die Klasse „Opel Astra“ die Schnittstelle „Auto“ implementiert. Die Schnittstelle Auto fordert vier Operationen lenken(), schalten(), bremsen() und beschleunigen() sowie zwei Attribute „geschwindigkeit“ und „fahrtrichtung“. Die Klasse „Opel Astra“ erfüllt die Anforderungen für diese Schnittstelle, da sie unter anderem über die vier geforderten Operationen und zwei Attribute verfügt.

Beispiel

Bei einem Ticketsystem für ein Schauspielhaus werden über einen Veranstaltungsplan alle Stücke des Theaters verwaltet. Die Klasse Veranstaltungsplan ist mit der Klasse Saalplan über eine Komposition verbunden. Somit kann die Klasse Veranstaltungsplan Objekte der Klasse Saalplan verwalten. Jeder Saalplan enthält die Plätze des Theaters, und diese werden über den Saalplan verkauft.