Back To Top

Klassendiagramme mit der UML


UML KlassenKlassendiagramme sind die Basisdiagramme in der UML und spiegeln die Struktur von Objekten samt deren Beziehungen untereinander wider.

Das Einsatzgebiet der Klassendiagramme beginnt mit dem Projekt, meist nach der Erstellung von Anwendungsfallanalyse und Aktivitätsdiagramm.

Bereits in der Analysephase ist es sinnvoll mit den Klassendiagrammen zu beginnen und eine erste grobe Planung zu erstellen.

Während des Projekts wird noch viel geändert, und das Klassendiagramm bietet eine gute Hilfestellung, um die Komplexität einer Anwendung bzw. eines Teiles davon aufzunehmen und zu beschreiben.

Im ersten Schritt fehlen häufig die Datentypen, Schnittstellen und Methoden.

Die Klasse erfasst namentlich zunächst nur die Aufgabe, für die sie später zuständig ist.

Ein Klassendiagramm enthält alle Informationen über die eigentliche Programmierung, der enthaltenen Eigenschaften und Funktionalitäten der Klassen und der Beziehung der Klassen untereinander.

Das Metamodell der Klassendiagramme

UML KlassenDie Grafik Subpackages der Klassenpakete und deren Abhängigkeiten zeigt die Unterpakete der Klassendiagramme und deren Abhängigkeiten: 
 

In den meisten Programmiersprachen wie C# oder Java gibt es eine allgemeine Oberklasse, die jeweils Object heißt. Von dieser Oberklasse erben alle Klassen, die programmiert werden. Dieses Konzept findet sich auch in der UML 2.0.

Die Klasse

Comelio-Blog UML AktivitätEin benennbares Element (NamedElement) in der UML 2 kann einen Namen haben und ist nach außen mit einer Sichtbarkeit verbunden. Eines dieser benennbaren Elemente in der UML 2.0 ist bspw. eine Klasse. Klassen legen Name, Zustand und Verhalten von Objekten fest und beschreiben beschreiben so deren Struktur.

Eine Klasse soll innerhalb eines Systems die Verantwortung für einen sachlogischen Aspekt des Gesamtsystems übernehmen, d. h., sie beschreibt die Gemeinsamkeiten von Objekten mit identischen Verhaltensweisen. In einer gemeinsamen Klasse sind somit die Attribute und die Operationen der Objekte identisch.

Eine Klasse wird durch ein dreigeteiltes Rechteck dargestellt.

Der Klassenname steht zentriert und fett im oberen Rechteck und beginnt mit einem Großbuchstaben, wie in nebenstehender Abbildung Eine einfache Klasse mit fehlenden Attributen und Operationen.

Es ist wichtig, einen aussagekräftigen Klassennamen zu benutzen, denn über diesen ist die Klasse eindeutig identifizierbar. Es wird niemals zwei Klassen gleichen Namens in einem objektorientierten Modell geben.

In der Analysephase, in der es darum geht, alle notwendigen Klassen ausfindig zu machen, sollte die Klasse wie in der nebenstehenden Abbildung Eine einfache Klasse ganz ohne Attribute und Methoden dargestellt aussehen.

Im nächsten Schritt sollte genauer geklärt werden, welche Eigenschaften (Attribute) die Klasse haben kann, und was die Klasse alles tun und erledigen kann.

Die Klasse wird unterteilt, und die Eigenschaften und Operationen (Spezifikation: attributes, operations) werden in zwei weiteren rechteckförmigen Unterteilungen innerhalb der Klasse untergebracht.

Das zweite Segment enthält die Attribute und beschreibt somit den Zustand, also die Eigenschaften der Objekte in dieser Klasse. Die Operationen, die das dynamische Verhalten der Objekte festlegen finden sich im dritten Segment.

Basisklasse der UML 2

UML KlassenEs gibt in der UML 2 eine Oberklasse mit dem Namen Element, von der alle Elemente erben. Diese Oberklasse ist abstrakt, von ihr kann also keine Instanz gebildet werden. Sie bildet ein allgemeines Konzept, dessen konkrete Ausprägungen in Unterklassen dargestellt werden. Sie darf grundsätzlich weitere Elemente enthalten, wie im Metamodell beschrieben. Die Darstellung von Element sehen Sie in nebenstehender Grafik.

RootDiagramm

UML KlassenIn der UML 2.0 gibt es den Begriff eines benennbaren Elements (NamedElement). Ein benennbares Element kann einen Namen haben und ist nach außen mit einer Sichtbarkeit verbunden. Eines dieser benennbaren Elemente in der UML 2.0 ist bspw. eine Klasse. Eine Klasse soll innerhalb eines Systems genau eine Aufgabe übernehmen. So übernimmt die Klasse eine Verantwortung für einen sachlogischen Aspekt des Gesamtsystems. Der Kontext sieht wie in nebenstehender Abbildung RootDiagramm aus.

Mulitplizitäten

UML KlassenZunächst zu einem typisierbaren Element (Spezifikation TypedElement). Es handelt sich dabei grundsätzlich um ein benanntes Element. Ein typisierbares Element hat grundsätzlich keinen oder einen Typ.

Die Multiplizität, die dieses Diagramm eigentlich beschreibt, stellt definiert ein Intervall dar und deutet die Anzahl der möglichen Kardinalitäten (Spezifikation: Cardinality) an, die die Anzahl der möglichen Ausprägungen darstellt.

Die Multiziplität wird von eckigen Klammern umschlossen und legt jeweils die Unter- und Obergrenze der Ausprägungen eines Attributes fest. Und nicht nur in diesem Zusammenhang gibt es die Multiplizität (Spezifikation: MultiplicityElement). Wenn die Multiziplität die Möglichkeiten der Ausprägungen anzeigt, redet man von Kardinalität (Spezifikation: Cardinality), wenn man die Anzahl der Elemente in einer Menge benennen möchte. Hierbei handelt es sich also um die konkrete Anzahl der Ausprägungen.

Expressions

UML KlassenEine Wertespezifikation (Spezifikation: ValueSpecification) stellt eine Spezifikation der Werte in einem Modell dar. Es handelt sich dabei um einfache formale Ausdrücke. Diese Ausdrücke können aus der Programmiersprache sein, in der man sie beschreib. Der Fachbegriff hierzu heißt: OpaqueExpression.

Wichtig: die Angabe der Sprache kann weggelassen werden, wenn sie aus dem Kontext verständlich ist. Wenn man die Sprache angeben will, so erfolgt dies mit der Sprachangabe in geschweiften Klammern.

Literale stellen Spezialisierungen der Klasse LiteralSpecification dar, wobei diese wiederum von ValueSpecification abgeleitet ist . Dabei gibt es folgende Literale:

  • LiteralBoolean
  • LiteralInteger
  • LiteralString
  • LiteralUnlimitedNatural
  • LiteralNull

Constraint

UML KlassenEine Zusicherung (Spezifikation: Constraint) ist eine Bedingung, die für ein Element erfüllt sein muss. Es kann sich dabei um einen OCL-Ausdruck handeln, zugelassen ist aber auch ein sprachlicher Ausdruck. Die Abbildung zeigt das Metamodell zu den Constraints.

Die Zusicherung definiert mit Hilfe eines booleschen Ausdrucks, welcher Wertebereich zulässig ist. Zusicherungen werden grundsätzlich in geschweifte Klammern gefasst. Erlaubt ist die Zusicherung bei einem Element direkt hinter dem Namen oder innerhalb eines Kommentars, der direkt mit dem Element verbunden wird.

Die Syntax für eine Zusicherung sieht wie folgt aus:

`{` [<name> `:`] <boolean expression> `}`

Classifier

UML KlassenIn der Abbildung Classes sehen Sie die Modelle für den vorherigen Classifier und die dazugehörigen Merkmale.

Der Classifier kann mehrere Eigenschaften (Spezifikation: Properties) enthalten, wobei eine Eigenschaft immer zu 0 oder einem Classifier gehört.

 

Feature

UML KlassenEin Feature beschreibt einige Verhaltensmerk­male oder Strukturmerkmale der Objekte einer Klasse.

Ein StructuralFeature ist bspw. die Eigenschaft, die auch mit einem Attribut isReadOnly versehen werden kann, das angibt, dass das Attribut nicht mehr verändert werden kann.

Ein BehavioralFeature ist bspw. eine Operation. Hierbei geht es grundsätzlich um Verhalten. Es können anhand der Multiziplitäten beliebig viele Parameter übergeben werden. Der Parameter hat dabei eine Richtung und gehört BehavioralFeature, was man an der Kompositions­beziehung erkennt.

Properties

UML KlassenIn der Spezifikation kommt danach die Beschreibung der Properties. Die Eigenschaften können auch per Assoziation beschrieben werden.

Wie schon erwähnt, stellen die Eigenschaften ein StructuralFeature dar.

Abhängigkeiten

UML KlassenBei den Abhängigkeiten handelt es sich um Beziehungen von Elementen.

Dabei geht es um Quellelemente (Spezifikation: +supplier) und um clients, die das Ziel darstellen.

Hier an dieser Stelle zunächst das Metamodell in nebenstehender Abbildung Abhängigkeiten.
 

 

Objekte und Instanzspezifikation

Comelio-Blog UML KlassenWährend eine Klasse eine Schablone darstellt, ist das Objekt eine konkrete Ausprägung dieser Klasse. In der UML 2.0 unterliegt dieser Formalismus der Instanzspezifikation (Spezifikation: InstanceSpecification). Die genauen Werte für ein solches Objekt (Attributwerte), nennen sich Slots.

Ein Objekt kann die Klasse enthalten, von der es konkret abgeleitet wird. Der Aufbau ist dem der Klasse ähnlich, nur wird der Name des Objekts unterstrichen. Zudem haben die Attribute konkrete Werte. Es ist nicht zwingend, für alle Attribute entsprechende Werte anzugeben.

Attribute

Comelio-Blog UML KlassenIn der UML 2.0 gibt es ein typisierbares Element (TypedElement). Es handelt sich dabei um ein benennbares Element (NamedElement), das neben einem Namen auch einen Typ haben kann. Attribute und Parameter sind beispielsweise solche Elemente.

Eine Wertespezifikation (ValueSpecification) drückt einen Wert in einem Modell aus. Es handelt sich dabei letztendlich nur um mathematische Ausdrücke, die sich errechnen lassen.

Ein Attribut muss innerhalb der Klasse eindeutig definiert sein. Die Attribute können mit folgender Syntax noch weiter spezifiziert werden:

[Sichtbarkeit] [/] name [:Typ] [Multiplizität] 
[= Vorgabewert] [{Eigenschaftswert}]

Merkmale der Syntax:

  • Sichtbarkeit (Spezifikation: visibility)
    Die Sichtbarkeit für das nachfolgende Attribut bestimmt, wie von außerhalb der Klasse auf das Attribut oder seinen Wert zugegriffen werden kann. Es gibt in der UML 2.0 vier verschiedene Sichtbarkeitsmodi, die auch für Methoden gelten.
    Schlüsselwort Notation Bedeutung
    public + Die Sichtbarkeit kann von überall her erfolgen.
    private - Sichtbarkeit nur innerhalb der eigenen Klasse.
    protected # Die Sichtbarkeit kann in allen abgeleiteten Klassen und der eigenen Klasse erfolgen. Kein Zugriff von außen.
    package ~ Sichtbarkeit gilt für alle definierten Klassen in demselben Paket der Klasse.
    static Das Element ist unterstrichen. Das Element ist auch ohne Objekt sichtbar und zugreifbar.
  • name
    Der Name des Attributes ist grundsätzlich zwingend anzugeben.
  • /
    Abgeleitetes Attribut. Die Werte werden zur Laufzeit berechnet, daher brauchen die Daten nicht vorab gespeichert zu werden.
  • [:Typ][Multiplizität] (Spezifikation: multiplicity)
    Hier wird der Typ des Attributes festgelegt. Mit der Multiplizität wird die Unter- und Obergrenze der Anzahl der unter einem Attributnamen ablegbaren Ausprägungen festgelegt.
    Multiplizität Bedeutung
    0..1 Das Attribut kann entweder keinen oder einen Wert annehmen.
    1..1 Das Attribut muss zwingend mit genau einem Wert belegt werden. Es gilt auch die vereinfachende Schreibweise »1«.
    0..* Das Attribut kann beliebig viele Werte annehmen.
    1..* Das Attribut muss mindestens einen Wert haben, kann aber beliebig viele Werte annehmen.
    n..m Das Attribut muss mindestens n Werte annehmen, kann aber bis zu m Werte annehmen.
    n..n Das Attribut muss genau n Werte annehmen.
  • Vorgabewert (Spezifikation: default)
    Der Vorgabewert ist der Default-Wert des Attributs, der automatisch gesetzt wird, wenn zur Laufzeit eine Methode diesen Wert nicht verändert. Der Vorgabewert setzt quasi den Wert des Attributs per Default. Zunächst ist also der Wert des Attributes gesetzt, kann später allerdings zur Laufzeit verändert werden.
  • Eigenschaftswert (Spezifikation: property-string)
    Mit den Eigenschaftswerten, die in geschweiften Klammern angegeben werden, können Einschränkungen festgelegt werden.
    Der Eigenschaftswert wird in geschweiften Klammern mitgeführt. Mit dem Eigenschaftswert können Sie die Eigenschaften des Attributs genauer festlegen. In folgender Tabelle sind die laut der Spezifikation möglichen Eigenschaftswerte aufgeführt:
    Eigenschaftswert Bedeutung
    readOnly Nur lesender Zugriff auf den Eigenschaftswert erlaubt.
    union

    Definiert eine gemeinsame Verwendung von Attributen für einen Oberbegriff. Die Zuordnung erfolgt durch die Subsets.

    subsets Die Attribute werden durch subsets zusammengefasst.
    redefines Die derzeitige Definition eines Attributes wird überschrieben.
    ordered Legt fest, dass die Attributinhalte in einer stringenten Reihenfolge angeordnet werden und eindeutig sind.
    bag Legt fest, dass Attribute ungeordnet sein können und nicht zwingend eindeutig sein müssen.
    sequence oder seq Legt fest, dass die Attribute geordnet sein müssen, allerdings müssen sie nicht eindeutig sein.
    composite Legt fest, dass das Attribut selbst die eigenen Werte zerstört.

Methoden (Operationen)

UML KlassenDie Operation (Methode) ist wiederum ein Verhaltensmerkmal und steuert auch das Verhalten.

Die Abbildung zeigt die Operationen und deren formale Verhältnisse und Regelungen.

Es gibt grundsätzlich Vor- und Nach­bedingungen. Zu den Operationen gehören per Kompositionsbeziehung die Parameter, Constraints und Typen. Eine Methode muss innerhalb der Klasse eindeutig sein. Die Syntax sieht wie folgt aus:

[Sichtbarkeit] Name (Parameterliste) : Rückgabetyp [{Eigenschaftswert}]

Die Parameterliste wird entsprechend der folgenden Syntax beschrieben:

[Übergaberichtung] Name : Typ [`[`Multiplizität`]`] [= Vorgabewert] 
  [`{`Eigenschaftswert`}`]

Vieles, was zu den Attributen gesagt wurde, gilt auch für die Methoden.

  • Die Sichtbarkeit regelt, wie bei den Attributen, den Zugriff auf Methoden. Die Notation ist identisch mit der Notation der Methoden.
  • Der Name ist innerhalb einer Klasse eindeutig.

Die Übergaberichtung des Parameters (Spezifikation: ParameterDirectionKind) kann folgende Schlüsselwörter enthalten:

Schlüsselwort Bedeutung
in Der Wert des Parameters wird von der aufrufenden Methode übergeben.
out Der Wert des Parameters wird an die aufrufende Methode zurückgegeben.
inout Der Wert des Parameters wird als Erstes von der aufrufenden Methode übergeben und danach an die aufrufende Methode zurückgegeben.
return Mit return wird der Rückgabewert definiert.

Kommentare

UML KlassenAn eine Klasse und jedes andere Element aus der UML 2.0 können Kommentare (Spezifikation: Comment) angehangen werden. Dieser Kommen­tar gehört zum Element selbst. Diese Kompositions­beziehung stellt den Kommentar als Eigentum des Elementes dar. Ein Element kann beliebig viele Kommentare enthalten, aber auch beliebig vielen Elementen gehören.

Es gibt beim Kommentar noch eine andere Möglichkeit, das Element anzubringen: als angeheftetes Element (Spezifikation: +annotatedElement). Auch hierbei kann ein Kommentar beliebig vielen Elementen angeheftet werden.

Interfaces (Schnittstellen)

UML KlassenBei den Schnittstellen handelt es sich um eine vertragliche Vereinbarung darüber, welche Merkmale die einbindenden Klassen später enthalten sollten. Sie können grundsätzlich jeweils beliebig viele Eigenschaften und Operationen enthalten, wie Sie in nebenstehender Abbildung Interfaces an der Kompositionsbeziehung ersehen können.

Umgekehrt gehören die Eigenschaften und Operationen selbst immer keinem oder einem Interface.

Methoden und set- und get-Methoden werden in der Schnittstelle definiert. Damit verpflichtet sich die Klasse, die Methode (Spezifikation: operation) der Schnittstelle zu definieren. Das gilt hier ebenso für Attribute, auch wenn die meisten Programmiersprachen diese als Eigenschaftsmethoden bezeichnen. Die genaue Ausprogrammierung geschieht in der Klasse. Die Schnittstelle besteht daher nur aus den Methodenrümpfen und den Ein- und Ausgabeparametern.

Ein Classifier kann beliebig viele Schnittstellen implementieren. Die Klasse kann darüber hinaus weitere Methoden und Eigenschaften enthalten. Schnittstellen können untereinander erweitert werden und voneinander erben. Hierbei wird die Generalisierungsbeziehung genutzt.

Es gibt nunmehr zwei Möglichkeiten, eine Schnittstelle anzubringen: eine bereitgestellte Schnitt­stelle und eine benötigte Schnittstelle. Im ersten Fall bietet eine Schnittstelle ein Modellelement an und kann von anderen Modellelementen genutzt werden. Im anderen Fall handelt es sich um eine Schnittstelle, die von einem anderen Modellelement eingefordert wird.

Zur Implementierung von Schnittstellen gibt es die Implementierungsbeziehung (Spezifikation: implementation), eine spezielle Form der Realisierungsbeziehung.

Grundsätzlich wird das Interface genauso notiert wie die Klasse.

Zusätzlich enthält dieser Classifier allerdings das Schlüsselwort <<interface>>.

Das Schlüsselwort steht über dem Namen des Classifiers, ähnlich wie mit einem Stereotyp.

Die Schnittstelle wird in der Klasse realisiert und steht somit in einer Realisierungsbeziehung (Spezifikation: realize). Nebenstehend wird die standardmäßige Notation verwendet.

Oftmals ist in der Literatur und auch in der Spezifikation an dem Pfeil (Spezifikation: Dependency-Pfeil) das Schlüsselwort <<realize>> angezeigt, wie hier auch geschehen.

Es gibt noch eine weitere Möglichkeit, die Realisierung eines Interface zu notieren.

Die Notation aus der Abbildung nennt sich Steckernotation und ist die abgekürzte Notation.

Die Kurznotation zeigt nur die Namen der Schnittstelle, nicht die enthaltenen Operationen und Attribute.

Für geforderte Schnittstellen gibt es auch zwei Möglichkeiten.

Die Standardnotation ist analog zu der Realisierungsbeziehung.

Auch hierfür gibt es eine Kurznotation.

Hierbei werden wiederum die enthaltenen Operationen und Attribute nicht angezeigt. Im Übrigen kann man auch beide Notationen mischen.

Dies stellt dann die Kombination von der Forderung und der Implementierung dar.

 

Generalisierung, Vererbung

Comelio-Blog UML AktivitätDie Generalisierung (Spezifikation: Generalization) drückt eine Beziehung von einem allgemeinen Fall zu einem speziellen Fall der Klasse aus. Sie dient der Strukturierung von Aufgabengebieten einer Klasse. Die einzelnen Merkmale der Oberklasse werden durch die Generalisierung an die Elemente der Unterklasse weitergegeben.

Sie ist ein geeigneter Weg, um Coderedundanzen zu vermeiden. Es ist wichtig, eine Oberklasse zu finden, die grundlegende Eigenschaften hat und diese weiter vererbt. Der Erbling erbt somit diese Eigenschaften und kann selbst zusätzliches definieren.

Ein Objekt, das von einer Unterklasse instanziert wurde kann jederzeit ein Objekt der Oberklasse ersetzen. Dies verbirgt sich in der Objektorientierung hinter dem Begriff des Substitutionsprinzips.

Die Generalisierung ist auch unter dem Begriff »Vererbung« bekannt. Die Generalisierung wird dargestellt durch einen Pfeil mit einer dreieckigen Spitze, der nicht ausgefüllt ist.

In der UML kann man das Überschreiben von Merkmalen (Spezifikation: ReDefinition) über die Metamodellklasse RedefinableElement steuern. In einer Generalisierungsbeziehung dürfen alle Metamodellelemente überschreiben, sofern sie eine Unterklasse von RedefinableElement sind. Die Überschreibung erfolgt z.B. bei einem Attribut über den Eigenschaftswert {redefines}.

Mehrere Klassen können von einer Oberklasse erben. Der Begriff der Generalisierung ist sehr treffend, weil eine Oberklasse grundsätzliche Eigenschaften an eine Unterklasse weitergibt, die spezifischer wird.

Die Abbildung Eine Oberklasse mit mehreren Unterklassen zeigt die Notation einer Oberklasse, von der mehrere Unterklassen erben.

Oftmals möchte man ausdrücken, welchen Grund eine Generalisierung hat.

Die Abbildung Notation für eine Generalisierungsmenge (GeneralizationSet) zeigt eine Generalisierung mit der so genannten Generalisierungsmenge (Spezifikation: GeneralizationSet).

Auf der rechten Seite in der Abbildung wird aufgezeigt, dass vom allgemeinen Fall »Personal« Klassen abgebildet werden, die den Mitarbeiterstatus genauer spezifizieren und zusätzliche Merkmale zu den Klassen hinzufügen. Beispielsweise wird ein Chef bestimmte Dinge tun und erledigen können, wozu ein Angestellter oder Praktikant nicht berechtigt ist. Allen Unterklassen ist aber gemeinsam, dass eine Personalnummer vergeben werden muss, egal ob es sich um einen Praktikanten, einen Angestellten oder einen Chef handelt.

Die Generalisierungsmenge (Spezifikation: GeneralizationSet) benennt die Zusammensetzung der so genannten Generalisierungskanten. Die einzelnen Realisierungen bilden wiederum die so genannten Partitionen (Spezifikation: partitions). Die Generalisierungseigenschaften können darunter in geschweiften Klammern angegeben werden, für die wiederum Schlüsselwörter angegeben werden müssen, die in nachfolgender Tabelle genauer erläutert werden.

Schlüsselwort Bedeutung
complete Besagt, dass in dieser Menge alle im logischen Kontext vorkommenden Spezialisierungen vorhanden sind.
incomplete Die vorhandenen Spezialisierungen sind noch nicht vollständig, es können weitere Klassen abgeleitet werden, die in diesen logischen Zusammenhang passen.
disjoint Immer nur eine kann Ausprägung innerhalb des Kontextes zu sich selbst konform sein.
overlapping Hier sind im Gegensatz zu disjoint Objekte erlaubt, die sowohl von der einen Klasse als auch von der anderen Klasse stammen können.

Assoziationen (Associations)

Comelio-Blog UML AktivitätDie Assoziation (Spezifikation: associations) beschreibt Beziehungen zwischen Klassen. Die Beziehung wird dabei genau beschrieben und benannt. Sie wird durch eine durchgezogene Linie zwischen Klassen dargestellt und kann einen Namen tragen.

Zur Assoziation gehören beliebig viele Eigenschaften. Pakete besitzen grundsätzlich jeweils beliebig viele Elemente und Typen. Zwischen den Linien, die die Assoziationen darstellen, kann eine gestrichelte Linie gezogen werden um weitere Einschränkungen zu notieren.

Verschiedene Ausprägungen:

Im einfachsten Fall besteht die Assoziation aus einer durchgezogenen Linie zwischen zwei Klassen. An der Linie kann die jeweilige Rolle der Klasse notiert werden, die die genaue Verwendung der Klasse bezeichnet.

Bei dem Klassennamen ändert sich in diesem Zusammenhang nichts, die Rolle beschreibt lediglich die Klasse im Kontext der Assoziation, ähnlich wie ein Schauspieler eine Rolle spielt. Mit einer Rolle kann zudem eine Multiplizität angegeben werden. Wenn die Multiziplität nicht angegeben wird, ist 0..* voreingestellt. Die Assoziation enthält zudem einen Namen, dessen Bezeichnung mittig an die Linie angebracht wird.

Wichtig: auch zwei Assoziationslinien in denen andere Rollen eingenommen werden können gezogen werden. Eine Rolle besagt nichts anderes als eine Eigenschaft (Property). Die Rollenangaben können hier ebenfalls eine Sichtbarkeit enthalten. Benachbarte Klassen haben Zugriff auf diese Operation des Objektes.

Vor den Namen kann man einen Schrägstrich (/) setzen. Dies bedeutet, dass diese Assoziation von einer anderen Assoziation abgeleitet ist.

Die Assoziation kann grundsätzlich auch mit einer so genannten Leserichtung versehen werden. Die Leserichtung beschreibt die Beziehung zwischen den beiden Klassen näher.

Eine angegebene Leserichtung besagt in etwa das, was eine Rollenangabe der Klasse innerhalb der Assoziation besagen würde. Die Rollenangabe ist weitaus aussagekräftiger als die Leserichtung. Die Pfeilrichtung besagt, dass es sich um eine gerichtete Assoziation handelt.

Ein möglicher Fall ist, dass eine Klasse die andere Klasse kennen darf, oder sogar kennen muss, umgekehrt aber die gegenüberliegende Klasse die andere Klasse nicht kennen darf.

Man spricht an dieser Stelle auch von unidirektionaler und bidirektionaler Assoziation. Bidirektionale Assoziation bedeutet, dass in beide Richtungen navigiert werden kann, während unidirektional bedeutet, dass nur eine Richtung erlaubt ist.

Die Leserichtung wird lediglich zu einem besseren Verständnis für die Notation und den logischen Zusammenhang genutzt. Die gerichtete Assoziation bestimmt zwingend, ob ein Objekt auf ein anderes zugreifen darf.

n-äre Assoziation

Comelio-Blog UML AktivitätEs gibt auch den Fall, dass mehr als zwei Assoziationsenden verfügbar sein müssen. Dies nennt man in der UML mehrgliedrige Assoziation. Dabei gibt es keine Möglichkeit, die n-äre Assoziation zu benennen, zumal aufgrund der Anordnung des Notationselementes kein Platz dafür vorhanden ist.

Natürlich können hier auch wiederum Multiplizitäten angegeben werden. Allerdings ist im Zusammenhang der n-ären Assoziation weder eine Aggregation noch eine Komposition erlaubt.

Vererbung von Assoziationen

Comelio-Blog UML AktivitätAssoziationen können jederzeit generalisiert werden. Sie sind spezielle Classifier. Es gibt einige formelle Regeln. Die Anzahl der Assoziationsenden mus bspw. gleich bleiben, die beteiligten Klassen müssen gleich sein und ebenfalls in einem Generalisierungs­zusammenhang stehen. Des Weiteren darf die Multiplizität der Assoziation bei dem Erbling nicht erweitert werden. Sie darf allerdings explizit eingeschränkt werden.

Aggregation

Comelio-Blog UML AktivitätBei der Aggregation handelt es sich um eine so genannte Teile-Ganzes-Beziehung. In der UML-2.0-Spezifikation der OMG übersetzt man die Aggregation mit »besteht aus«. Das Ende mit der leeren Raute bezeichnet die Klasse, die das Ganze darstellt. Das gegenüberliegende Assoziationsende ist ein Teil, das zum Ganzen gehört. Die Notation sieht wie in der Abbildung aus.

In diesem Fall besteht ein Flugzeug aus mindestens einem Motor und maximal zwei Motoren, was die Multiziplität an den Aggregationsenden aussagt. Grundsätzlich könnte man auch eine Assoziationsbeziehung benutzen, um das Gleiche auszudrücken. Hier würde Flugzeug eine Rolle »besteht aus« zugewiesen und der Motor eben die Rolle »ist Teil von« zugewiesen bekommen. Am Assoziationsende des Ganzen ist eine Navigierbarkeit nicht möglich. Natürlich kann man die Notation mit einer Leserichtung versehen usw.

Die Lebensdauer des Ganzen überdauert die Lebensdauer der Teile und umgekehrt. Die Teile des Ganzen können sogar grundsätzlich auch für andere Klassen Teile sein. Die Multiziplitäten modellieren bei der Aggregation die Anzahl der Teile in einem Ganzen und in wie vielen Ganzen die einzelnen Teile vorhanden seien dürfen.

Komposition

Comelio-Blog UML AktivitätDie Komposition stellt in diesem Zusammenhang eine weitaus strengere Form der Aggregation dar, bei der die Teile vom Ganzen sogar existenzabhängig sind. Es ist an dieser Stelle eine so genannte Inklusion der Teile zu einem Ganzen. In diesem Fall stellen Teile und das Ganze eine Einheit dar. Somit kann die Zerstörung dieser Einheit oder Teile daraus die Zerstörung des Ganzen zur Folge haben.

Die Abbildung besagt, dass ein Flugzeug keinen oder einen Motor enthalten darf. Erst durch die Motoren wird das Flugzeug zu einem Ganzen. Hier wären Segelflugzeuge auch berücksichtigt.

Bei der Komposition ist die Auswahl der Multiziplitäten, die verwendet werden dürfen, beschränkt. Während ein Ganzes aus diversen Teilen bestehen kann, darf ein Teil nur zu genau einem Ganzen gehören. Es darf nicht zusätzlich noch zu einem anderen Ganzen gehören. Die Notation für die Multiziplität an der Raute kann weggelassen werden, da sie damit 1 ist.

Namensräume

UML KlassenIn der Spezifikation beschrieben ist das Namespace Diagram. Dieses steht in einer Kompositionsbeziehung zu NamedElement. Zusätzlich gibt es noch eine gerichtete Assoziation, wobei der Namespace mehrere Benannte Elemente enthalten darf. Im Namespace können die verschiedenen Enumerationen der VisibilityKinds angebracht werden:

  • Public
  • Private
  • Protected
  • Package

Schaut man einmal auf den Import, so unterscheidet man hier zwischen Elementimport und Packageimport. Es handelt sich hier um eine Kompositionsbeziehung. Die importierten Packages und Elemente gehören fest zum Namespace. Ein Namespace darf immer beliebig viele Importe zulassen, immer aber gehört ein Import zu einem einzigen Namespace.

In einen Namensraum (Namespace) können benennbare Elemente eingefügt werden. Wichtig ist, dass sie innerhalb des Namensraumes, der zum Beispiel eine große Ansammlung von Elementen genauer gliedert, eindeutig sind. Von außen kann man das Element mit dem qualifizierten Namen ansprechen.

Da Namensräume ineinander verschachtelt sein können, können die qualifizierten Namen sehr ausschweifend werden und somit über mehrere Namensräume gehen. Die entsprechende Notation ist folgendermaßen:

Namensraum1::Namensraum2::Klasse1

Pakete

UML KlassenZur besseren Strukturierung werden Klassen in Pakete gegliedert, die mit den Namensräumen zusammenhängen. Elemente, die in Paketen gegliedert werden dürfen sind Paket-Elemente (PackageableElement).

Die UML 2.0 enthält eine Diagrammart, in der Pakete ausgedrückt werden. Damit kann man mehrere Classifier zu einem Paket zusammenfassen und erhält eine abstrakte Übersicht über verschiedene Funktionalitäten.

Die einzelnen Pakete können beliebige Typen enthalten. Jedes Paket enthält einen Namensraum, in dem die Namen der Classifier eindeutig sein müssen. Jedes in einem Paket enthaltene Element kann über einen qualifizierten Namen (Paketname::Klassenname) angesprochen werden, innerhalb eines Paketes auch über einen unqualifizierten Namen.

Dabei besteht der unqualifizierte Name nur aus dem Namen des Classifiers. Innerhalb eines Paketes kommt man an einen anderen Classifier heran, außerhalb des Paketes kommt man ebenfalls unqualifiziert an die einzelnen Classifier heran, es hängt allerdings davon ab, wie die einzelnen Classifier zugreifbar sind.

Hier gilt wiederum für private das Minuszeichen (-). Damit darf von außen nicht auf das Element zugegriffen werden. Für public gilt dementsprechend das Pluszeichen (+), das besagt, dass von jeder Stelle des gesamten Modells auf dieses Element mit dem qualifizierten Namen zugegriffen werden darf.

Die Pakete können selbst Pakete enthalten. Auch bei einer Verschachtelung von Paketen kann die vorherige Notation übernommen werden. Hierbei können statt der Klassen jeweils die Pakete notiert werden.

Ein Paket kann importiert werden, was sich durch einen gestrichelten Pfeil zwischen zwei Paketen darstellen lässt, an dem ein Stereotyp mit dem Schlüsselwort <<import>> angebracht ist.

Es besagt, dass der Import public ist. Im Gegensatz dazu gibt es auch einen Import, der private ist. Dieser ist identisch, nur das Schlüsselwort lautet <<access>>.

Es gibt darüber hinaus eine verkürzte Notation für den Import, das so genannte Paket-Merge.

Hierbei wird der Zugriff mit <<merge>> notiert und beinhaltet eine Verschmelzung des Pakets, das auf diese Weise importiert wird. Vom Prinzip her spricht man an dieser Stelle von einer Generalisierung.

Der <<merge>>-Import besagt, dass die Klasse 2 im Paket 1 genauso angesprochen werden kann, als wäre diese direkt in Paket 1 selbst vorhanden. An dieser Stelle spricht man beim <<merge>>-Import von einer Verschmelzung. Private Elemente werden nicht einbezogen. Formal kann man diese Verschmelzung gemäß der Spezifikation auch durch eine Generalisierung darstellen.

Beim Import eines einzelnen Elements kann dieses Element per unqualifiziertem Namen angesprochen werden. Hierbei kann auch ein Aliasname verwendet werden. Ein Aliasname kann nicht verwendet werden, wenn ein komplettes Paket mit mehreren Elementen importiert wird.

Ein Paket ist immer auch ein Namensraum, (Spezifikation: Namespace), das benennbare Elemente (NamedElement) beinhalten kann. Im Namensraum selbst müssen diese Elemente eindeutig identifizierbar sein. Außerhalb dieses Namensraumes kann ein Element mit gleichem Namen existieren. Mit den qualifizierten Namen können diese Elemente direkt identifiziert werden.