Klassendiagramm

2025-05-08T19:48:22Z

78.42.178.161: /* Komposition und Aggregation */

{{UML Diagrammtypen}}
Ein '''Klassendiagramm''' ist ein Strukturdiagramm der [[Unified Modeling Language]] (UML) zur grafischen Darstellung ([[Modellierung]]) von [[Klasse (objektorientierte Programmierung)|Klassen]], [[Schnittstelle (Objektorientierung)|Schnittstellen]] sowie deren Beziehungen. Eine ''Klasse'' ist in der [[Objektorientierung]] ein abstrakter Oberbegriff für die Beschreibung der gemeinsamen Struktur und des gemeinsamen Verhaltens von [[Objekt (Programmierung)|Objekten]] (''Klassifizierung''). Sie dient dazu, Objekte zu [[Abstraktion|abstrahieren]]. Im Zusammenspiel mit anderen Klassen ermöglicht sie die Modellierung eines abgegrenzten Systems in der [[Objektorientierte Analyse|objektorientierten Analyse]] und im [[Objektorientiertes Design|Entwurf]].

Seit den 1990er Jahren werden Klassendiagramme meistens in der Notation der [[Unified Modeling Language|UML]] dargestellt. Das Klassendiagramm ist eine der 14 Diagrammarten der UML, einer Modellierungssprache für [[Software]] und andere Systeme.

== Notation in der Unified Modeling Language ==

=== Klassen ===
[[Klasse (UML)|Klassen]] werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse (fett gedruckt) tragen oder zusätzlich auch [[Attribut (UML)|Attribute]], [[Operation (UML)|Operationen]] und Eigenschaften spezifiziert haben. Dabei werden diese drei Rubriken (engl. ''compartment'') – Klassenname, Attribute/Eigenschaften, Methoden/Operationen – jeweils durch eine horizontale Linie getrennt. Wenn die Klasse keine Attribute/Eigenschaften oder Methoden/Operationen besitzt, kann die unterste horizontale Linie entfallen. Oberhalb des Klassennamens können Schlüsselwörter (engl. ''keyword'') in [[Guillemets]] und unterhalb des Klassennamens in geschweiften Klammern zusätzliche Eigenschaften (wie <code>{abstrakt}</code>) stehen.

Die Attribute werden wie folgt spezifiziert:
[Sichtbarkeit] [/] name [: Typ] [ [[Multiplizität (UML)|Multiplizität]] ] [= Vorgabewert] [{eigenschaftswert*}]
Daraus folgt, dass in der UML ausschließlich der Name eines Attributs angegeben werden muss, und zwar eindeutig innerhalb einer Klasse. Klassenattribute werden unterstrichen. Darüber hinaus sind bei Attributnamen sämtliche Zeichen erlaubt, auch wenn in einigen Programmiersprachen beispielsweise Umlaute verboten sind.

Operationen werden in ähnlicher Art und Weise spezifiziert:
[Sichtbarkeit] name [''({Parameter})''] [: Rückgabetyp] [{eigenschaftswert*}]
Zudem wird ein Parameter wie folgt aufgebaut:
[Übergaberichtung] name : Typ [ [[Multiplizität (UML)|Multiplizität]] ] [= Vorgabewert] [{eigenschaftswert*}]
Die Namensgebung und der Zeichenraum sind hier genauso wie bei den Attributsspezifikationen. Klassenoperationen werden auch hier unterstrichen. Den „Pseudotyp“ [[Void (Schlüsselwort)|void]] gibt es in der UML nicht, daher muss in einem solchen Fall der Rückgabetyp weggelassen werden. Ansonsten können bei Attributen und Methoden/Operationen sämtliche primitiven Typen sowie selbst definierte Klassen oder Interfaces als Typ bzw. Rückgabetyp verwendet werden.

Die Sichtbarkeit von Attributen und Methoden/Operationen wird wie folgt gekennzeichnet:
* „+“ für ''[[public]]'' – (engl. öffentlich), unbeschränkter Zugriff
* „#“ für ''[[protected]]'' – (engl. geschützt), Zugriff nur von der Klasse sowie von Unterklassen (Klassen, die erben)
* „−“ für ''[[Private (Informationstechnik)|private]]'' – (engl. privat), nur die Klasse selbst kann es sehen
* „~“ für ''[[Package (Sichtbarkeit)|package]]'' – (engl. Paket), innerhalb des Pakets sichtbar (nur in wenigen Programmiersprachen, etwa Java und C#, implementierbar)

Mögliche Eigenschaften sind:
; ordered
: die Daten werden geordnet zurückgegeben
; redefines <Operationsname> (nur bei Operationen)
: diese Operation überschreibt die geerbte Operation <Operationsname>
; read-only
: auf diese Variable kann nur lesend zugegriffen werden

Die Übergaberichtungen:
; in
: Der übergebene Parameter wird nur gelesen (Standard, wenn nichts angegeben wurde).
; out
: Der übergebene Parameter wird beschrieben, ohne ihn vorher zu lesen.
; inout
: Der übergebene Parameter wird gelesen bzw. verarbeitet und beschrieben, beispielsweise um das Ergebnis zurückzugeben.

Die folgenden Abbildungen zeigen zwei Varianten der grafischen Notation für eine Klasse. Abhängig davon, ob eine Klasse in einem Klassendiagramm für ein Design- oder für ein Analysemodell gezeichnet wird, können mehr oder weniger Details dargestellt werden.

<gallery widths="300" heights="145" class="center">
Datei:UmlCd_Klasse-1.svg|Einfachste Form der Darstellung für eine Klasse
Datei:UmlCd_Klasse-2.svg|Zusätzliche Darstellung von Attributen und Operationen
</gallery>
<div style="clear:both;"></div>

[[Datei:UmlCd Klasse-3.svg|gerahmt|rechts|Detaillierte Darstellung einer Klasse ]]
Abstrakte Klassen sind Klassen, von denen keine [[Objekt (Programmierung)#Objektorientierte Programmierung|Instanz]] angelegt werden kann. Abstrakte Klassen sehen in [[UML]] wie normale Klassen aus. Um sie zu unterscheiden, steht unterhalb des Klassennamens das Wort <code>abstract</code> in geschweiften Klammern. Alternativ kann der Klassenname auch kursiv geschrieben werden, wenn dies gut erkennbar ist.
<div style="clear:both;"></div>

[[Datei:UmlCd Klasse-4.svg|mini|300px|links|Beispiel einer ''aktiven Klasse'' mit zwei [[Signalempfänger (UML)|Signalempfängern]]]]
Eine [[Klasse (UML)#Aktive Klassen|aktive Klasse]] wird mit einem doppelten linken und rechten Rand gezeichnet.
<div style="clear:both;"></div>

[[Datei:UmlCd TemplateKlasse-1.svg|gerahmt|rechts|Klassenschablone]]
Einige Programmiersprachen ermöglichen eine Parametrisierung von Klassenschablonen ''(Class Templates)'', um Objekte basierend auf diesen Vorlagenparametern zu erzeugen. Die UML bietet dafür die Notation für ''Template Arguments'' an. Dabei werden die Vorlagenparameter in einem gestrichelten Rechteck überlappend an die rechte obere Ecke der Klasse eingetragen. Im Beispiel ist eine Klasse „Vector“ mit dem Vorlagenparametertyp „int“ und dem Parameternamen „T_VALUE“ eingetragen.
<div style="clear:both;"></div>

=== Schnittstellen ===
Eine [[Schnittstelle (UML)|Schnittstelle]] wird ähnlich wie eine [[Klasse (UML)|Klasse]] mit einem Rechteck dargestellt, zur Unterscheidung aber mit dem Schlüsselwort <code>interface</code> gekennzeichnet. Schnittstellen können seit der UML 2 auch Attribute besitzen.<ref>{{Literatur| Autor=Heide Balzert| Titel=Lehrbuch der Objektmodellierung: Analyse und Entwurf mit der UML 2| Auflage=2.| Verlag=Spektrum Akademischer Verlag|Ort=Heidelberg| Jahr=2005| ISBN=978-3-8274-2903-2| Fundstelle=S. 543}}</ref>

<gallery class="center" widths="400" heights="210">
Datei:UmlCd Interface-1.svg|Eine Schnittstelle wird mit dem Schlüsselwort <nowiki><<interface>></nowiki> markiert
Datei:UmlCd Interface-2.svg|Angebotene Schnittstelle, dargestellt mit einer [[Abhängigkeitsbeziehung (UML)|Schnittstellenrealisierungsbeziehung]]
</gallery>
<div style="clear:both;"></div>

== Wichtige Beziehungen ==

=== Generalisierung ===
[[Datei:Generalization (UML class diagram).svg|mini|Generalisierung]]
Eine [[Generalisierung (UML)|Generalisierung]] in der UML ist eine gerichtete Beziehung zwischen einer ''generelleren'' und einer ''spezielleren'' Klasse. Exemplare der spezielleren Klasse sind damit auch Exemplare der generelleren Klasse. Konkret bedeutet dies, dass die speziellere Klasse implizit über alle [[Merkmal (UML)|Merkmale]] (Struktur- und Verhaltensmerkmale) der generelleren Klasse verfügt – ''implizit'' deshalb, weil diese Merkmale in der spezielleren Klasse nicht explizit deklariert werden. Man sagt, dass die speziellere Klasse sie von der generelleren Klasse „erbt“ oder „ableitet“.<ref>{{Literatur |Autor=Amelie Flatt, Arne Langner, Olof Leps |Titel=Phase I: Mapping Legal Concepts to Technical Objects |Sammelwerk=Model-Driven Development of Akoma Ntoso Application Profiles |Verlag=Springer International Publishing |Ort=Cham |Datum=2022 |ISBN=978-3-031-14131-7 |DOI=10.1007/978-3-031-14132-4_3 |Seiten=13–17 |Online=https://link.springer.com/10.1007/978-3-031-14132-4_3 |Abruf=2023-01-07}}</ref>

Eine Generalisierung wird als durchgezogene Linie zwischen den beiden beteiligten Classifiern dargestellt. Am Ende mit dem generelleren Classifier wird eine geschlossene, nicht ausgefüllte Pfeilspitze gezeichnet.

In gängigen objektorientierten Programmiersprachen entspricht dies dem Konzept der Vererbung, wobei der Pfeil auf die Oberklasse zeigt.

<gallery widths="400" heights="210" align="center">
Datei:UmlCd Generalisierung-1.svg|Generalisierung in einem Beispiel angewandt
</gallery>

=== Assoziation ===
Eine [[Assoziation (UML)|Assoziation]] beschreibt eine [[Relation (Philosophie)|Beziehung]] zwischen zwei oder mehr [[Klasse (UML)|Klassen]]. An den Enden von Assoziationen sind häufig [[Multiplizität (UML)|Multiplizitäten]] vermerkt. Diese drücken aus, wie viele dieser Objekte in Relation zu den anderen Objekten dieser Assoziation stehen.

<gallery widths="400" heights="210" align="center">
Datei:UmlCd Assoziation-1.svg|Beispiel für eine binäre Assoziation
Datei:UmlCd Assoziation-2.svg|Beispiel für eine ''reflexive Assoziation''
</gallery>
<div style="clear:both;"></div>

=== Komposition und Aggregation ===
{{Überarbeiten|[[Diskussion:Klassendiagramm#Abschnitt Komposition und Aggregation|Diskussionsseite zu diesem Artikel]]|Dieser Abschnitt|grund=}}
[[Datei:Komposition Aggregation.svg|mini|links|300px|Beispiele für ''Komposition'' und ''Aggregation'']]
Eine [[Relation (Philosophie)|Beziehung]] zwischen Klassen, die z. B. öfter benötigt wird, ist die Beziehung zwischen einem ''Ganzen'' und seinen ''Teilen''. Die UML sieht dafür zwei spezielle Assoziationen vor: die [[Assoziation (UML)#Aggregation und Komposition|''Aggregation'' und die speziellere ''Komposition'']]. Aggregation und Komposition beschreiben die Beziehung von Teilen zu ihrem Ganzen, wobei Komposition eine stärkere Form der Aggregation darstellt.<ref name=":0">{{Internetquelle |url=https://www.uml-diagrams.org/aggregation.html |titel=UML shared aggregation is relationship between a property and one or more composite objects used to group together a set of instances. |abruf=2024-08-09}}</ref>

In der grafischen Darstellung einer ''Komposition'' dekoriert eine ausgefüllte [[Raute]] das Ende mit der Multiplizität 1 (oder 1..1), das mit dem Ganzen verbunden ist. Im Fall der ''Aggregation'' ist es eine nicht ausgefüllte Raute mit einer Kardinalität von 0..* .

Komposition ist ein Spezialfall der Aggregation, bei dem die Teile existenziell vom Ganzen abhängig sind und nicht ohne das Ganze existieren können. Bei Aggregation können die Teile unabhängig existieren, selbst wenn das Ganze nicht mehr vorhanden ist.

In einer Komposition hat das Ganze eine Kardinalität von 1 (oder 1..1), während die Teile genau zu diesem einen Ganzen gehören. In einer Aggregation können die Teile zu mehreren Ganzen gehören, und die Kardinalität des Ganzen kann unterschiedlich sein.<ref name=":1">{{Internetquelle |url=https://www.uml-diagrams.org/composition.html |titel=UML composite aggregation (composition) is relationship between a property and at most one composite object with responsibility for the existence and storage of that property (part). |abruf=2024-08-09}}</ref> Der Fokus liegt hierbei eher auf den Teilen. Durch eine Komposition wird ausgedrückt, dass die Teile von ihrem Ganzen abhängig sind, während in einer Aggregation die Teile unabhängig von ihrem Ganzen existieren können.<ref name=":0" />

Dabei definiert der Unterschied in der Kardinalität (0..* oder 1..1), ob eine Aggregation oder der Spezialfall Komposition vorliegt. Eine Komposition liegt vor, wenn die Kardinalität am Ganzen 1 (oder 1..1) lautet und die Teile ohne das Ganze nicht existieren können.<ref name=":1" /> Eine Aggregation liegt vor, wenn die Kardinalität 0..* lautet.
<div style="clear:both;"></div>

Für das Beispiel heißt die Existenzabhängigkeit folgendes:
* Komposition: Ein Raum kann nicht ohne Gebäude existieren.
* Aggregation: Ein Student kann ohne Vorlesung existieren.

Dennoch bestehen die linken Entitäten aus den rechten Entitäten:
* Ein Gebäude besteht aus Räumen. (Im Beispiel aus mindestens einem Raum; ist als Kardinalität auch 0 Räume zulässig, so ist die Beziehung dennoch eine Komposition.)
* Eine Vorlesung wird von Studenten besucht. (Die Kardinalität kann variieren, und die Beziehung bleibt eine Aggregation, da die Studenten unabhängig von der Vorlesung existieren können.)<ref name=":0" />
In Hinblick auf eine „besteht aus“-Beziehung unterscheiden sich Komposition und Aggregation nicht. Dies ist genau das, was sie vereint. Sie unterscheiden sich jedoch in der „kann ohne sein Ganzes existieren“-Beziehung.

Liegt eine Komposition vor, spricht man auch von einer [[Referenzielle Integrität|referenziellen Integrität]], die für einen Teil angibt, dass es vom Ganzen abhängig ist.

Das Ganze darf zusätzliche Beziehungen zu anderen Klassen oder weitere eigene Attribute besitzen – es muss nicht ausschließlich aus Teilen einer Klasse bestehen.

== Formale Semantik ==
Rumbaugh, Jacobson und Booch fordern eine eher minimal definierte, mengentheoretische Semantikbeschreibung.<ref>{{Literatur|Autor=James Rumbaugh, Ivar Jacobson, Grady Booch|Titel=The Unified Modeling Language Reference Manual|Verlag=Addison-Wesley|Jahr=1998|ISBN=978-0201309980}}</ref> Demnach ist eine Konfiguration (englisch ''snapshot'') <math>\sigma</math> eines UML-Klassendiagrammes eine Menge von Objekten der in dem Diagramm vorhandenen Klassen. Eine Konfiguration ist konsistent, wenn alle in dem Diagramm angegebenen Einschränkungen eingehalten werden, wie z. B. [[Multiplizität (UML)|Multiplizitäten]] oder [[Object Constraint Language|OCL]] Constraints.

=== Klassen und Attribute ===
In jeder Konfiguration wird eine Klasse als Menge ihrer Objekte beschrieben. Wenn <math>cname</math> der Name einer Klasse ist, dann ist <math>\sigma(cname)</math> eine Menge. Diese Menge darf auch leer sein, wenn es kein Objekt gibt.

Wenn <math>attribn</math> ein Attribut vom Typ <math>typn</math> einer Klasse mit dem Klassennamen <math>cname</math> ist, dann ist <math>\sigma(attribn)</math> eine partielle Funktion von der Menge der Objekte <math>\sigma(cname)</math> in die Menge der Objekte des Attributstyps <math>\sigma(typn)</math>. Die Funktion muss partiell sein, da sie für (noch) nicht initialisierte Attribute undefiniert ist. Klassenattribute werden genauso behandelt, haben aber die zusätzliche Einschränkung, dass alle Objekte einer Klasse auf dasselbe Objekt des Attributtyps abgebildet werden müssen.

Wurde zusätzlich eine Multiplizität eines Attributes definiert mit dem Intervall <math>I</math>, dann ist <math>\sigma(attribn)</math> eine [[Relation (Mathematik)|Relation]] mit <math>\sigma(attribn): \sigma(cname) \times \sigma(typn)</math>, mit der zusätzlichen Einschränkung, dass für jedes <math>a\in \sigma(cname)</math> <math>Card(\{b|\langle a,b \rangle \in \sigma(attribn)\}) \in I</math> gilt.

Falls eine Klasse mit Namen <math>cname1</math> eine Unterklasse von der Klasse mit Namen <math>cname</math> ist, dann gilt: <math>\sigma(cname1) \subseteq \sigma(cname)</math>

=== Assoziationen ===
Eine Assoziation <math>r</math> zwischen Klassen mit den Namen <math>cname1</math> und <math>cname2</math> wird als Relation <math>\sigma(r)</math> zwischen den Mengen der Objekte der Klassen interpretiert, <math>\sigma(r): \sigma(cname1) \times \sigma(cname2)</math>. Die Multiplizitäten müssen in beiden Richtungen wie oben beschrieben behandelt werden. Diese Darstellung erlaubt allerdings keine Behandlung der Rollennamen an den Assoziationsenden. Um dies dennoch zu ermöglichen, könnte eine eindeutige Labelfunktion und deren Inverse eingeführt werden.

Bei dieser Art der Betrachtung der Semantik wird nicht zwischen normalen Assoziationen und deren speziellen Ausprägungen (Aggregation, Komposition) unterschieden.

=== Operationen ===
Im Allgemeinen löst eine [[Operation (UML)|Operation]] einen Übergang von einer Konfiguration zu einer anderen aus. Im Falle nicht-deterministischer Operationen gibt es eine Menge von Nachfolge-Konfigurationen. Einen Sonderfall stellen Query-Operationen dar. Da diese keine Seiteneffekte haben dürfen, erfolgt auch kein Zustandsübergang in eine andere Konfiguration. Operationen entsprechen in vielen Programmiersprachen [[Methode (Programmierung)|Methoden]] bzw. [[Funktion (Programmierung)|Funktionen]].

== Beispieldiagramm ==
[[Datei:UmlCd Klassendiagramm-1.svg|links|Beispiel eines Klassendiagramm mit fünf [[Klasse (UML)|Klassen]], zwei [[Generalisierung (UML)|Generalisierungen]] und drei [[Assoziation (UML)|Assoziationen]]]]
<div style="clear:both;"></div>

== Literatur ==
* {{Literatur| Autor=Heide Balzert| Titel=Lehrbuch der Objektmodellierung – Analyse und Entwurf mit der UML 2| Verlag=Elsevier Spektrum Akademischer Verlag| Jahr=2005| ISBN=3-8274-1162-9}}
* {{Literatur| Autor=Christoph Kecher| Titel=UML 2.0 – Das umfassende Handbuch| Verlag=Galileo Computing| Jahr=2006| ISBN=3-89842-738-2}}
* {{Literatur| Autor=Chris Rupp, Stefan Queins, Barbara Zengler| Titel=UML 2 Glasklar| Verlag=Hanser Verlag| Jahr=2007| ISBN=978-3-446-41118-0}}
* {{Literatur|Autor=[[James Rumbaugh]], [[Ivar Jacobson]], [[Grady Booch]]|Titel=The Unified Modeling Language Reference Manual|Verlag=Addison-Wesley|Jahr=1998|ISBN=978-0201309980}}

== Weblinks ==
{{Commonscat|Class diagrams|Klassendiagramm}}

== Einzelnachweise ==
<references />

{{Normdaten |TYP=s |GND=4825393-5}}

[[Kategorie:Objektorientierte Programmierung]]
[[Kategorie:Unified Modeling Language]]
[[Kategorie:Diagramm]]

Wikipedia (Deutsch) – Lokale Kopie - Benutzerbeiträge [de]

Klassendiagramm