Strukturen in Klassendiagrammen

Jeder von uns kennt die Kunststoffbausteine von „Lego“. Das jahrelang konsequent verfolgte Prinzip und der damit erzielte Erfolgt beruhte auf dem Aufbau der einzelnen Modelle auf einer relativ geringen Anzahl von Grundbausteinen, wie sie in Abbildung 4-9 zu sehen sind.

Lego-Bausteine

Der Vorteil für den Kunden sowie für den Hersteller liegt auf der Hand: die Steine sind nahezu beliebig kombinierbar und damit in vielen neuen Gebilden einsetzbar. Der Hersteller greift bei neuen Modellen immer wieder auf die gleichen Grundbausteine zurück, was die Produktionskosten enorm senkt, aber auch die Konstruktionspläne stark vereinfacht. Ein weiteres Beispiel für die Anwendung des Baukastenprinzips ist die Verwendung sog. Plattformen bei der Konstruktion und dem Bau verschiedener Fahrzeugmodelle eines Automobilkonzerns.

Aber auch modellübergreifende Konzepte einer gemeinsamen Entwicklungsplattform bei der Konstruktion eines neuen Modells waren in den vergangenen Jahren immer wieder zu beobachten, wie die folgenden Abbildungen veranschaulichen.

Das Grundkonzept des VW-Busses T6.1, umgesetzt in verschiedenen Modellen.

Eine ähnliche Motivation liegt dem Bemühen zugrunde, innerhalb der Klassendiagramme eine Art von immer wieder verwendbaren Bausteinen zu entwerfen, ohne dabei die Möglichkeit individueller Variationen zu vernachlässigen.
In Fortführung des Beispiels des Schreibwarenhandels wird dies nun am konkreten Beispiel erklärt:

Der Handelsbetrieb bietet neben den reinen Handelswaren auch selbstgefertigte Artikel an, die im folgenden als Lagerartikel bezeichnet werden. Wie bei allen Artikeln soll die permanenten Lieferbereitschaft auch bei den Lagerartikeln gewährleistet sein.

Eine ähnliche Motivation liegt dem Bemühen zugrunde, innerhalb der Klassendiagramme eine Art von immer wieder verwendbaren Bausteinen zu entwerfen, ohne dabei die Möglichkeit individueller Variationen zu vernachlässigen.
In Fortführung des Beispiels des Schreibwarenhandels wird dies nun am konkreten Beispiel erklärt:

Der Handelsbetrieb bietet neben den reinen Handelswaren auch selbstgefertigte Artikel an, die im folgenden als Lagerartikel bezeichnet werden. Wie bei allen Artikeln soll die permanenten Lieferbereitschaft auch bei den Lagerartikeln gewährleistet sein.

1 Generalisierung

Im Ergebnis erhalten wir durch eine relativ einfache Ergänzung zwei Arten von Artikeln, nämlich die Lagerartikel und die fremdgefertigten Artikel. Hierbei wird deutlich, dass zwischen den beiden Klassen eine Abhängigkeit besteht: Lagerartikel beinhalten die selben Eigenschaften der Artikel; im Umkehrschluss stellt man fest, dass Artikel nicht alle Eigenschaften der Lagerartikel enthalten. Es ergibt sich eine Abhängigkeit der beiden Klassen voneinander, in der die Klasse Artikel als Oberklasse (super class) und die Klasse Lagerartikel als Unterklasse (sub class) erscheint.

Die Beziehung zwischen einer allgemeinen Klasse (Oberklasse) und einer spezialisierten Klasse (sub class) bezeichnet man als Generalisierung.

2 Abstrakte Datentypen vs. Generalisierung mittels abstrakten Klassen

Im folgenden sehen Sie die Klassen Kunde und Lieferant.

Eine andere Möglichkeit, die Vorteile der Bildung von Datatypes ohne diese zu realisieren, wäre die Bildung sog. abstrakter Klassen. In unserem Beispiel der Schreibwarenhandels können wir die Gemeinsamkeiten der Klassen Kunde und Lieferant zu einer Klasse Geschäftspartner zusammenfassen:

Als Kennzeichen dafür, dass es sich um eine abstrakte Klasse handelt, die für sich keine Objekte ausbilden kann, ist die Klassenbezeichnung kursiv dargestellt.

Wie zu sehen ist, greifen beide Klassen Kunde und Lieferant auf die Attribute der abstrakten Klasse Geschäftspartner zu. Die Sichtbarkeit der Attribute in Geschäftspartner muss demzufolge auf „#“ gesetzt sein, damit sie innerhalb der Generalisierungsstruktur von den Klassen Kunde und Lieferant gelesen werden kann.

Eine eindeutige Entscheidung zwischen der Bildung von Datatypes, der Bildung von Generalisierungen oder einer hybriden Lösung lässt sich nicht formulieren. Hier kommt es darauf an, dass für den jeweiligen Fall bzw. die jeweilige Anwendung die vorteilhaftere Lösung gewählt wird.

Pakete als Teilsysteme im Klassendiagramm

Um aus Gründen der Systematisierung aber auch Übersichtlichkeit die Strukturierung des Klassendiagramms voranzutreiben, ist es möglich, sogenannte Pakete zu bilden, welche – jedes für sich – einzelne Abläufe voneinander abgrenzen.
So kann man die Abläufe in unserem Schreibwarenversand anhand der betriebswirtschaftlichen Grundfunktionen einteilen in: Bestellwesen mit Lieferungen, Aufträge und Materialwirtschaft bzw. Lagerhaltung.

Das Paket wird als Rechteck mit einem Reiter dargestellt, der den Paketnamen enthält.

Zwischen den Paketen bestehen Beziehungen, welche durch die Importpfeile näher beschrieben werden. So zeigt die Spitze des Pfeils auf dasjenige Paket, das importiert werden soll. Konkret: für die Artikelverwaltung ist es wichtig, über die Bestellungen informiert zu sein. Für die Auftragsabwicklung ist es von Bedeutung, Informationen über den Stand der Lieferungen zu erhalten. Für die Sichtbarkeit der Attribute bedeutet dies, dass Elemente, welche mit einem „~“ gekennzeichnet (private) sind, nur innerhalb des Paketes sichtbar sind, während das „+“ (public) dafür sorgt, dass das jeweilige Attribut auch in einem anderen Paket verwendet werden kann.

Das vorliegende Skript soll einen Einblick in die Bemühungen geben, Fehler, die sich auf dem Weg vom ersten Kontakt mit dem späteren Anwender einer Software bis hin zu deren Auslieferung ergeben können, nach Möglichkeit zu vermeiden. Dies geschieht mit Hilfe der Unified Modeling Language – kurz UML.

Es wurde dabei bewusst auf die Darstellung mancher Details, wie z.B. die einzelnen Ausprägungsformen von Assoziationen verzichtet, um dem selbst vorgegebnen Ziel gerecht zu werden, lediglich einen Einblick und damit eine Übersicht über Vorgehensweisen und Einsatzbereiche der UML zu geben.