Klassendiagramm (Class Diagramm)

Das Klassendiagramm ist wahrscheinlich eines der Diagramme, welches zum großen Erfolg von UML beigetragen haben.

Mit dem Klassendiagramm lassen sich die für ein Programm entworfenen Klassen mit Atrributen und Methoden sowie den Beziehungen der Klassen zueinander visualisieren.
Ein Klassendiagramm ist daher nur auf die objektorientierte Software-Entwicklung anwendbar.

Ein Klassendiagramm muss nicht den vollständigen Klassenentwurf wiedergeben, sondern kann sich auch nur auf einen Ausschnitt relevanter Klassen beziehen.

Beispiel:

Obiges Klassendiagramm zeigt die Beziehung zweier Klassen. Die linke Klasse Eurofighter steht in Beziehung mit einer anderen Klasse Rakete.

Die Klasse Eurofighter hat Attribute (obere, rote Liste), welche die Eigenschaften der Klasse beschreiben. Außerdem hat die Klasse Operationen (untere, grüne Liste), welche die möglichen Funktionen (Methoden) der Klasse zeigen.

Dass in die Klasse Rakete keine Attribute und Operationen eingetragen wurden ist nicht weiter tragisch. Oft wird der Fokus auf die relevanten Klassen gelegt und nur bedingt relevante Klassen vereinfacht dargestellt; das Abstraktionslevel wird nicht selten bewusst gebrochen.

Ein UML-Klassendiagramm dient primär der Planung und Konzeption, als Hilfestellung für Software-Entwickler.
Es gibt zudem Programme, welche ein, nach den Programmrichtlinien erstelltes, Klassendiagramm in Quellcode umsetzt.

Beziehungen der objektorientierten Programmierung

Assoziation

Die Assoziation ist die einfachste Beziehung zwischen Klassen. Die Assoziation ist i.d.R. mit einem einfachen Strich symbolisiert. Die Objekte der Klassen bleiben trotz der Beziehung voneinander unabhängig und sind gleichberechtigt. Wird ein Objekt einer Klasse zerstört, existiert die andere Klasse unabhängig weiter.

Aggregation und Komposition

Das nachfolgende Schaubild eines Klassendiagramms zeigt drei Klassen Bücherregal, Buch und Seite.

Wie sind die Beziehungen dieser drei Objekte? Eine Seite ist fester Bestandteil eines Buches, sie kann nicht einfach ausgetauscht oder umgeheftet werden; Die Seiten werden mit dem Buch gekauft, verbrennt das Buch, verbrennen die Seiten des Buches unbedingt mit.
Ein Buch hingegen kann in dieses oder jenes Regal gestellt werden. Seiten sind also fest mit Büchern verbunden, Bücher aber nicht mit Regalen.

Die Aggregation ist eine häufig verwendete Beziehungsform in der Objektorientiertheit.
Die beschreibt eine Klassenbeziehung, bei welcher eine Klasse n Klassen übergeordnet ist und einbindet. Die Bindung ist fest, allerdings können die Objekte der untergeordneten Klassen auch ohne die der übergeordneten Klasse existieren.

Die Aggregation wird i.d.R. mit einer weißen oder transparenten Raute symbolisiert (obige Skizze: linke Beziehung).

Die Komposition beschreibt ebenfalls eine feste Bindung einer übergeordneten Klasse zu n untergeordneten Klassen. Allerdings können die Objekte der untergeordneten Klassen bei der Komposition nicht ohne die der übergeordneten Klassen existieren. Wird das Objekt der übergeordneten Klasse zerstört, sind auch die untergeordneten Objekte zerstört.

Eine Komposition wird i.d.R. mit einer schwarzen Raute dargestellt (obige Skizze: rechte Beziehung).

Die Raute liegt immer auf der Seite der übergeordneten Klasse.

Aggregation vs Komposition – Interpretationssache

Ob Aggregation oder Komposition anzuwenden ist, hängt von den Umständen und Zielen ab. Es kann z.B. für ein Software-Projekt notwendig sein, dass z.B. die virtuelle Buchseite doch auch unabhängig vom Buch existieren kann.

Beispiel: Klassengebilde Auto

In diesem Klassendiagramm hat die Klasse Auto auch die Klassen Motor und Getriebe. Die Objekte der untergeordneten Klassen Motor und Getriebe können auch ohne das (Objekt) Auto existieren! Außerdem können Motor und Getriebe von Auto zu Auto getauscht werden.
Daher werden die Beziehungen als Aggregation vereinbart.

Genauso gut kann die Klasse Auto die Klassen Motor und Getriebe aber auch über eine Komposition verwenden. Bedingt durch die Komposition können die beiden Objekte der Klassen Motor und Getriebe nicht ohne das Objekt Auto existieren. Das Getriebe und der Motor kann somit auch nicht von Auto zu Auto getauscht werden.

Vererbung

Die Vererbung ist die wohl interessanteste, obwohl sehr indirekte, Beziehung der Klassen bzw. der Klassenobjekte untereinander.
In der objektorientierten Programmierung können Datentypen Klassen so “Eltern” bzw. “Kinder” haben. Die “Eltern”-Klassen können ihre Eigenschaften (Attribute) und Methoden an ihre Kinder vererben. Da, im Gegensatz zur Schnittstellenvererbung, nicht nur Signaturen von Operationen, sondern die gesamten Operationen vererbt werden, ist hier speziell die Implementierungsvererbung gemeint.

Eine Vererbung wird mit Pfeilen dargestellt, der Pfeil zeigt vom Erben zum Vererber. Man spricht von Mehrfachvererbung, wenn eine Klasse von mehr als einer Klasse erbt.

Beispiel an Hand der Mehrfachvererbung: Mechatronik enthält die Eigenschaften der Elektronik und Mechanik

Ein weiteres, typisches Beispiel zur Erläuterung des Vererbungsprinzips ist das Beispiel der Vererbungsbeziehung zwischen Fahrzeug-Klassen.

Die oberste Klasse ist die abstrakte Klasse Fahrzeug. Eine abstrakte Klasse ist nicht instanziierbar (also praktisch nicht direkt verwendbar). Die Klasse Fahrzeug stellt zwar alle Grundfunktionen und Eigenschaften zur Verfügung, welche ein Fahrzeug bieten muss (jedes Fahrzeug sollte u.a. einen Geschwindigkeitstacho haben, fahren und anhalten können), die allgemeine Definition Fahrzeug als abstrakte Klasse kann jedoch noch nicht verwendet werden.

Fahrzeuge können PKW und LKW sein (oder bei entsprechendem Klassenentwurf auch ein Motorrad oder Motorboot). Ein PKW sowie auch ein LKW haben alle Eigenschaften eines Fahrzeugs, bringen jedoch auch ganz eigene Eigenschaften mit, wie z.B. eine eigene Sitzplatzgestaltung.
In diesem Beispiel sind des weiteren bestimmte Typen eines PKW definiert. Ein PKW kann die Gestaltung eines Vans, einer Limousine oder eines Sportwagens mit entsprechenden Spezifikationen haben.

Interface (Schnittstelle)

Eine Schnittstellenvererbung funktioniert ähnlich wie die Implementierungsvererbung. Anders als bei der Implementierungsvererbung werden jedoch keine vollständigen Operationen, sondern nur die Signaturen (i.d.R.: Rückgabewert, Methodenname, Parameternamen und – datentypen), vererbt.
Das Interface (Vererber), welches von einer anderen Klasse implementiert wird, sichert damit nur zu, dass die implementierende Klasse eine bestimmte Funktionalität bereitstellt.

Erklärungsbeispiel: Ein Interface Fahrstuhl hat die Signaturen der Methoden „hochfahren()“, „herunterfahren()“ und „anhalten()“.
Damit sagt das Interface Fahrstuhl aus: „Wer mich implementiert, der muss die Funktionen hochfahren(), herunterfahren() und anhalten() haben und mit Funktionalität versorgen, ansonsten kann er mich nicht implementieren„.

Häufig werden Interfaces mit einem vorangestellten „I“ namentlich gekennzeichnet, ein Interface „Fahrstuhl“ hieße so „IFahrstuhl“, ein Interface „Verbindung“ mit dieser Kennzeichnung „IVerbindung“.

Im UML-Klassendiagramm werden Schnittstellen zur Verdeutlichung meistens mit dem Zusatz „<<interface>>“ versehen.

Dargestellt wird eine Schnittstellenvererbung bzw. -implementierung mit Hilfe von gestrichelten Pfeilen.

Die Darstellung mit Pfeilen ist die sinngemäße Anlehnung an die Implementierungsvererbung (welche mit durchgezogenen Pfeilen dargestellt wird).

Die Schnittstellenvererbung kann auch mit Hilfer einer anderen Darstellungsweise skizziert werden. Beispielsweise verwendet Microsoft für die Schnittstellenimplementierung keine Pfeile, sondern eine Art „Anker“.

Diese Darstellungsweise hat die Vorteile, dass keine Linien zwischen dem Interface und den implementierenden Klassen gezogen werden müssen (platzsparend) und dass die äußerst indirekte Beziehung der Schnittstellenvererbung betont wird.

Hinweise:
Mit UML-Klassendiagrammen können eine Obermenge an Modellen und Strukturen dargestellt werden, allerdings können nicht alle objektorientierten Programmiersprachen all diesen Konzepten gerecht werden. Während beispielsweise C++ Mehrfachvererbung unterstützt, erlaubt C# nur eine einfache Vererbung.