Klassendiagramm UML

Klassendiagramm (Class Diagram)

Das Klassendiagramm bildet das Herzstück der UML. Es basiert auf den Prinzipien der Objektorientierung (Abstraktion, Kapselung, Vererbung, …) und ist durch seine Vielseitigkeit in allen Phasen eines Projekts einsetzbar. In der Analysephase tritt es als Domainmodell in Erscheinung und versucht ein Abbild der Wirklichkeit darzustellen. In der Designphase wird damit die Software modelliert und in der Implementierungsphase daraus Sourcecode generiert.

In Klassendiagrammen werden Klassen und die Beziehungen von Klassen untereinander modelliert. Bei den Beziehungen kann man grob drei Arten unterscheiden. Die einfachste und allgemeinste Variante ist die Assoziation. Eine zweite modellierbare Beziehung ist die Aufnahme einer Klasse in eine zweite Klasse, die sogenannte Containerklasse. Solche Beziehungen werden Aggregation oder Komposition genannt. Eine dritte Möglichkeit ist die Spezialisierung bzw. Generalisierung.

Da eine Klasse die Struktur und das Verhalten von Objekten, die von dieser Klasse erzeugt werden, modellieren muss, können diese mit Methoden und Attributen versehen werden. Weiterhin ist die Modellierung von Basisklassen und Schnittstellen über Stereotypen möglich. In einigen Programmiersprachen können Templateklassen implementiert werden. Die UML stellt solche Klassen im Klassendiagramm als parametrisierbare Klassen dar.

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 (Samm­lungsklassen 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 eventuel­ler Eigenschaftswerte und Zusicherungen notiert.

Abb. 30: Beispiel Klasse

Sichtbarkeitsbereich

Der Sichtbarkeitsbereich (Scope) der Klas­senelemente wird mit einem Zeichen vor dem Namen gekennzeichnet. Ist ein Elemen­t ö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.

Stereotypen

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

Abb. 31: Beispiel Stereotypen

Parametrisierbare Klassen 

Eine besondere Art von Klassen sind parametrisierbare Klassen. Bei diesen Klassen ist der Typ der enthaltenen Attribute noch nicht festgelegt. Die Festlegung erfolgt erst beim Instanzieren eines Objekts dieser Klassen. Für solche Klassen wird die grafische Darstel­lung abgewandelt. Das Rechteck für die Klasse bekommt im oberen Bereich ein zweites Rechteck mit einer Umrandung, in dem der variierbare Typ steht.

Abb. 32: Parametrisierbare Klasse

Objekt

Objekte sind die konkreten, agierenden Einheiten einer objektorientierten Anwendung. Sie werden nach einem Bauplan, der Klassendefinition, im Speicher er­zeugt. Jedes Objekt hat eine eigene Identität. Ein Objekt besitzt ein bestimmtes Ver­halten, das durch seine Methoden bestimmt ist. Zwei Objekte der gleichen Klasse ha­ben 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 wer­den 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 ent­fallen. Es werden dann nur ein Doppelpunkt und der Klassenname dargestellt. Da die Methoden in der Objektdarstellung uninteressant sind, werden diese nicht ange­geben.

Abb. 33: Beispiel Objekt

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, kommuni­zieren 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 Leserich­tung - einem kleinen ausgefüllten Dreieck - versehen werden. Diese Rich­tung bezieht sich nur auf den Namen und hat keinen Bezug zur Navigierbarkeit der Assoziation.

Auf jeder Seite der Assoziation können Rollennamen dazu verwendet werden, genauer zu beschreiben, welche Rolle die jeweili­gen 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 Rollenna­me 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 folgenden Beispiel würde die Klasse „Kunde“ ein Attribut "konto" als Refe­renz auf ein Objekt der Klasse Kundenkonto erhalten und die Klasse Kun­denkonto ein privates Attribut "bpos" mit einem Sammlungsobjekt (Collection bzw. Unterklasse davon), welches die Buchungsposition-Objekte referenziert.

Abb. 34: Assoziation und Komposition mit allen Angaben

Viele Modellierungswerkzeuge verwenden die Rollennamen der Be­ziehung für die entsprechenden automatisch erzeugten Attribute, Rollenna­men korrespondieren in der UML auch formal mit den entsprechenden Attributen. Assoziation mit Navigierbarkeit ist eine Alternativnotation zur Attributdarstellung in der zugehörigen Klasse.

Abb. 35: Assoziationen

Gelesen werden diese Beziehungen in folgender Weise:

• Eine Veranstaltung hat einen Saalplan.

• Ein Saalplan ist einer Spielstätte zugeordnet.

Der Pfeil sagt aus, dass die Kommunikation über­wiegend vom Saalplan ausgeht (bei der Implemen­tierung 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.

Abb. 36: Multiplizität vs. Kardinalität

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:

Abb. 37: Assoziationsklasse

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:

Abb. 38: Assoziationsknoten (n-äre Assoziation)

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.

Abb. 39: Notation Aggregation

Das Beispiel Unternehmen-Abteilung-Mitarbeiter zeigt, dass ein Teil (Abtei­lung) gleichzeitig auch wieder Aggregat sein kann.

Abb. 40: Beispiel Aggregation

Komposition

Eine Komposition ist eine strenge Form der Aggregation, bei der die Teile vom Ganzen existenzabhä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.

Abb. 41: Aggregation und Komposition

Wenn eine Klasse als Teil mehrerer Kompositionen definiert wird, wie beispielsweise in der folgenden Abbildung, dann bedeutet dies, dass sowohl Pkws als auch Boote einen Motor besitzen, ein konkretes Motor-Objekt aber immer nur entweder zu einem Pkw oder einem Boot gehören kann. Das entscheidende Merkmal einer Komposition ist, dass die aggregierten Teile niemals mit anderen Objekten geteilt werden. Dies kann auch im Diagramm mittels XOR-Constraint beschrieben werden.

Abb. 42: Beispiel Komposition

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 existenzabhängige Beziehung. Existenzabhängig bedeutet, dass das Teil ohne seinemGanzen nicht existieren kann und wenn das Ganze zerstört wird, müssen, auch alle seine Teile zerstört werden.

In der folgenden Abbildung ist zwischen der Klasse Veranstaltungsplan und der Klasse Saalplan eine Aggregation modelliert. Eine Komposition ist zwischen den Klassen Saalplan und Platz definiert. Es gibt somit kein Saalplan-Objekt ohne einen Platz. Gelesen werden die Beziehungen in folgender Weise:

Abb. 43: Beispiel Aggregation und Komposition 

• Ein Saalplan hat beliebig viele Plätze, aber mindes­tens einen.

• Ein Platz gehört genau zu einem Saalplan.

• Jeder Saalplan gehört zu einer Veranstal­tung.

• Eine Veranstaltung kann beliebig viele Saalpläne enthalten.

• 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 hinzu­fügen kann und sich kompatibel zur allgemeinen 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 folgenden Abbildung wird beispielsweise modelliert, dass Veranstaltungen Inhouse- oder Gastveranstaltungen sein können.

Abb. 44: Beispiel Vererbung

Abhängigkeiten (Dependencies)

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

Die Zielelemente sind für die Spezifikation oder Implementierung der Quell­elemente 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 ist.

  Eine Klasse benutzt eine bestimmte Schnittstelle einer anderen Klasse.
  Wenn die angebotene Schnittstelle verändert wird, sind in der schnitt­stellennutzenden Klasse ebenfalls Änderungen erforderlich.

• Eine Operation ist abhängig von einer Klasse, beispielsweise wird die Klasse in einem Operationsparameter genutzt. Eine Änderung in der Klasse des Parameters macht möglicherweise eine Änderung der Opera­tion erforderlich.

Die Abstraktionsbeziehung (Abstraction) ist eine spezielle Abhängigkeitsbe­ziehung 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-Stereotypen «derive», «trace» und «refine».

Zu einer Abstraktionsbeziehung gehört auch immer eine Abbildungsvor­schrift, 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 Realisierungsbe­ziehung. 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ängigkeitsbezie­hung. Der Unterschied zur Abhängigkeitsbeziehung ist, dass die Abhängig­keit sich nur auf die Implementierung beschränkt und nicht für die Spezifika­tion gilt. Das heißt, das abhängige Element benötigt das unabhängige Ele­ment 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ängigkeits­beziehung, 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 Realisie­rungsbeziehung zwischen einer Klasse und einer Schnittstelle. Die Klasse implementiert die in der Schnittstelle spezifizier­ten Merkmale.

Schnittstellen werden wie Klassen notiert, sie tragen jedoch das Schlüssel­wort «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 Schnitt­stellen oder Klassen haben.

Klassen, die eine Schnittstelle implementieren wollen, müssen alle in der zugehörigen Schnittstelle definierten Operationen implementieren. Bezüg­lich der in der Schnittstelle definierten Attribute muss sich die implementie­rende 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.

Zwischen implementierender Klasse und der Schnittstelle besteht eine spezielle Realisierungsbeziehung, die Implementierungsbeziehung (Schlüs­selwort «realize»).

Abb. 45: Beispiel Schnittstelle

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 derKlasse 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 Schnittstel­le 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.

Abb. 46: Notation bereitgestellte Schnittstelle

Für eine angeforderte Schnittstelle besitzt das anfordernde Element eine Verwendungsbeziehung zu der Schnittstelle. Bei der dafür existierenden Kurznotation handelt es sich um einen Halbkreis am Stiel. Dies soll eine Buchse symbolisieren.

Abb. 47: Notation angeforderte 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.

Abb. 48: Notationsmöglichkeiten für Schnittstellen (Nutzung und Bereitstellung)

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 diese Schreibweise!

Da Schnittstellen spezielle Klassen sind, gelten alle entsprechenden Regeln. Beispielsweise ist Generalisierung möglich.

Abb. 49: Erweiterung von Schnittstellen

Die folgende 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.

Abb. 50: Beispiel zur Implementierung von Schnittstellen

Symbole

Die folgende Tabelle enthält die Symbole der Klassendiagramme.

Name/Symbol	Verwendung
Klasse	Eine Klasse wird im Diagramm mit einem Rechteck darge­stellt, in dem der Name der Klasse angezeigt wird. Das Klassensymbol kann mit einem Bereich zur Dar­stellung der Attribute und der Methoden erweitert werden. Für parametrierbare Klassen wird das Klassensymbol mit einem Rechteck erweitert, das den Namen des Parameters enthält.
Objekt	Objekte werden mit einem Rechteck dargestellt, in dem der Name und die Klasse des Objekts unterstrichen angezeigt werden. Beide werden durch einen Doppelpunkt getrennt. Auf den Klassennamen kann verzichtet werden, wenn das Objekt auch ohne Klassennamen eingeordnet werden kann. Ein anonymes Objekt (ohne Namen) wird nur mit einem Doppelpunkt und dem Klassennamen angegeben.
Paket	Pakete beinhalten mehrere Klassen, die für eine bestimmte Aufgabe dort gruppiert wurden. Die Grafik für ein Paket symbolisiert eine Karteikarte, auf der der Paketname steht.
Assoziation	Stehen zwei Klassen in einer Beziehung, wird das durch die Verbindung der beiden Klassen mit einer durchgezogenen Linie dargestellt.       Auf der Linie kann in der Nähe des Klassensymbols die Kardinalität angegeben werden.       Auf der Linie können weiterhin der Name der Beziehung und die Rolle angegeben werden (Rollen: Angeklagter, Anklä­ger; Beziehungsname: klagt an).         Sie können mit einem Pfeil die vorrangige Richtung der Kom­munikation angeben. (Navigation)
Aggregation	Die Aggregation wird mit einer Linie, an deren einem Ende ein Rautensymbol zur Klasse des Containers zeigt, darge­stellt (Klasse B kann Objekte der Klasse A verwalten). Das Rautensymbol ist nicht gefüllt. Rollen, Kardinalität und vorrangige Richtung der Kommunikation werden wie bei der Assoziation angegeben.
Komposition	Die Komposition wird im Unterschied zur Aggregation mit einer gefüllten Raute dargestellt. Die weitere Symbolik ent­spricht der der Aggregation.
Generalisierung	Das Symbol ist ein Pfeil, der auf die Basisklasse zeigt und diese mit der abgeleiteten Klasse verbindet. Der Pfeil wird nicht gefüllt dargestellt (Klasse A erbt von der Klasse B).
Realisierung/Realisierung	Implementiert eine Klasse eine Schnittstelle (Interface), wird die Verbindung mit einem Pfeil und einer unterbrochenen Linie dargestellt.

Beispiel

Bei einem Ticketsystem für ein Schauspielhaus werden über einen Veranstaltungsplan alle Stücke des Thea­ters verwaltet. Die Klasse Veranstaltungsplan ist mit der Klasse Saalplan über eine Komposition verbun­den. 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. Die Klasse Saalplan verwaltet über eine weitere Komposition Objekte der Klasse Platz. Die Navigation ist in Richtung der Klasse Platz gerichtet. Die Klasse Saalplan kommuniziert mit der Klasse Veranstaltung, in die die Daten der Auffüh­rung ausgelagert sind, z. B. Datum und Uhrzeit. Die Angaben zur Spielstätte, z. B. der Name und die Adresse, wurden in die Klasse Spielstätte ausgelagert. Die Navigation erfolgt von der Klasse Saalplan.

Abb. 51: Beispiel Klassendiagramm

Paketdiagramm (Package Diagram)

Ein Paket (Package) ist eine logische Ansammlung von Modellelementen beliebigen Typs, mit denen das Gesamtmodell in kleinere überschaubare Einheiten gegliedert wird.

Ein Paket definiert einen Namensraum, d. h., innerhalb eines Paketes müssen die Namen der enthaltenen Elemente eindeutig sein. Jedes Modellelement kann in anderen Paketen referenziert werden, gehört aber nur zu höchstens einem (Heimat-)Paket. Pakete können verschiedene Modellelemente enthalten, beispielsweise Klassen und Anwendungsfälle. Sie können hierarchisch gegliedert werden, d. h. ihrerseits wieder Pakete enthalten.

Ein Modellelement, beispielsweise eine Klasse, kann in verschiedenen Paketen benutzt werden, jedoch hat jede Klasse ihr Stammpaket. In allen anderen Paketen wird sie lediglich über ihren qualifizierten Namen

Paketname::Klassenname

zitiert. Dadurch entstehen Abhängigkeiten zwischen den Paketen, d. h., ein Paket nutzt Klassen eines anderen Pakets.

Abb. 52: Beispiel Paket Diagramm

Ein Paket wird in Form eines Aktenregisters dargestellt. Innerhalb dieses Symbols steht der Name des Paketes. Werden innerhalb des Symbols Modellelemente angezeigt, steht der Name auf der Registerlasche, andernfalls innerhalb des großen Rechtecks. Oberhalb des Paket­namens können Stereotypen notiert werden.

Möchte man eine Arbeitsteilung auf mehrere Gruppen von Entwicklern vornehmen, kann man die Unterteilung in Pakete nutzen und jeder Gruppe ein solches Paket zur Bearbeitung übergeben. Damit die spätere Zusammenführung der Pakete problemlos möglich ist, wird eine Schnittstelle vereinbart. Dabei ist am Anfang nur der Name für die Schnittstelle nötig. Über die Schnittstelle können die im Paket enthaltenen Funktionen aufgerufen werden. Somit kann das Paket entsprechend getestet und die spätere Zusammenarbeit mit weiteren Paketen garantiert werden. Garantiert bedeutet in diesem Zusammenhang, dass für die in dem Paket implementierten Funktionen beim Aufruf mit möglichen Eingabewerten genau die definierten Ergebniswerte geliefert werden.

Das Zusammenspiel der Pakete des Systems wird in einem Paketdiagramm dargestellt, in dem man auch den internen Aufbau eines Pakets modelliert.

Grafische Elemente

Name/Element	Verwendung
Paket	Das Symbol des Paketes ist einer Karteikarte nachempfunden. Innerhalb dieses Sym­bols wird der Paketname dargestellt. Möchten Sie innerhalb des Paketes die Kommuni­kationen der Unterpakete modellieren, können Sie den Paketnamen in das oben ange­fügte Rechteck verlagern.
Kommunikation	Die Kommunikation der Pakete untereinander wird mit einem Pfeil dargestellt, der auf einer unterbrochenen Linie verläuft. Der Pfeil geht von dem Paket aus, von dem auch die Kommunikation überwiegend ausgeht.
Generalisierung	Erbt ein Paket von einem anderem, wird das Symbol für die Generalisierung verwendet. Mit einem Pfeil werden die beteiligen Pakete verbunden, wobei die Pfeilspitze auf das Paket zeigt, von dem geerbt wird.
Enthält (Nesting)	Mit diesem Symbol können Sie die Paketgliederung vom übergeordneten Paket her mo­dellieren. Dazu wird das Symbol „Enthält“ an das Paketsymbol des übergeordneten Pake­tes gezeichnet. Die untergeordneten Pakete werden durch durchgezogene Linien mit diesem Symbol verbunden.