5.1 Definition

Stellen wir uns folgende Situation vor: Im Rahmen einer Anwendungsentwicklung (für die Datenbank, die Systementwicklung, ...) müssen alle Personen erfasst werden, die in einer Hochschule tätig sind oder die dort studieren. Beim Sammeln der Attribute und Methoden (falls objektorientiert modelliert wird) wird man schnell merken, dass z.B. alle Beschäftigten viele Attribute und Methoden gemeinsam haben, einige aber auch nicht.

Ähnlichkeit

Dies ist eine vor allem aus der semantischen Datenmodellierung (z.B. der ER-Modellierung, vgl. [Staud 2005]) gut bekannte Struktur, für die man dort schon sehr früh ein Konzept fand, das Generalisierung / Spezialisierung genannt wurde Dabei bildet man einen Entitätstyp mit den Attributen, die allen gemeinsam sind und jeweils einen spezifischen Entitätstyp mit denen, die spezifisch sind.

Generalisierung / Spezialisierung

Bei der Übertragung auf die objektorientierte Modellierung wurde das Konzept um die Methoden erweitert: Gemeinsame Attribute und Methoden werden der generalisierten Klasse zugeordnet, die Methoden und Attributen der spezialisierten Klassen kommen in diese.

Die generalisierte Klasse wird oft auch Superklasse genannt, die spezialisierten Klassen Subklassen.

Begriffe

Durch diese Zuordnung von Attributen und Methoden erlaubt dieses Konzept eine „sparsame“ Modellierung (und später dann Programmierung), denn eine Alternative [Anmerkung] wäre, die Attribute (und Methoden) der generalisierten Einheit (Klasse, Entitätstyp, ...) allen spezialisierten Einheiten zuzuweisen.

Sparsam modellieren

Dieses Konzept drückt Ähnlichkeit zwischen den erfassten Informationsträgern aus, hier in der objektorientierten Modellierung also die Ähnlichkeit von Objekten bzw. Objektklassen. Ähnlich sind damit Objekte aus verschiedenen Objektklassen, falls sie Attribute und/oder Methoden gemeinsam haben. Ähnlichkeit bedeutet hier also auch, dass Objekte teilweise ein „gleiches Verhalten“ haben, bzw. dass auf sie dieselben Methoden anwendbar sind.

Ähnlichkeit

Eine andere Sichtweise betont den Vorgang der Unterscheidung von Objekten, der hier vorliegt. Die Unterscheidung in „über-„ und „untergeordnete“ Objekte und dann – genauso wichtig – die Unterscheidung der untergeordneten voneinander. Dieses Kriterium, nach dem die Objekte unterschieden und die Objektklassen gebildet wurden, wird auch Diskriminator, genannt (vgl. z.B. [Oestereich 1998, S. 261f]).

Diskriminatoren

Dabei kann eine Spezialisierungshierarchie durchaus mehrere Diskriminatoren berücksichtigen und diese können in der grafischen Notation angegeben werden (vgl. unten).

Die Generalisierung/Spezialisierung führt zu einer Baumstruktur mit über- und untergeordneten Klassen. Daher kommen die oben schon angeführten Bezeichnungen Subklasse für eine untergeordnete Klasse (eine Spezialisierung) und Superklasse für die übergeordnete Klasse (die Generalisierung).

Baumstruktur mit
Superklassen
und Subklassen

An der Spitze der so entstehenden Baumstruktur ist die Wurzel, sozusagen die allgemeinste Objektklasse des Modells, z.B. „Objekte an sich“. Die Wurzel ist Superklasse für alle anderen, die jeweils unterste Ebene der Objektklassen hat nur die Eigenschaft Subklasse zu sein, alle Objektklassen dazwischen sind gleichzeitig Super- und Subklassen.

Wurzel

In der objektorientierten Modellierung wird solch ein "Baum" als Klassenhierarchie bezeichnet.

Stellen wir uns die Baumstruktur so vor, dass die Wurzel oben angeordnet ist und nach unten jeweils die Verzweigungen, dann liegen von oben nach unten Spezialisierungen und von unten nach oben Generalisierungen vor.

Die Beziehungen zwischen den einzelnen Klassen werden, von der Super- zur Subklasse, auch als „Ist_ein-Beziehung“ bezeichnet.

5.2 Grafische Darstellung

Auch hier orientiert sich die grafische Notation an der UML 2.0. In ihr wird von jeder Subklasse zur Superklasse eine Linie mit einem großen nicht gefüllten Pfeil geführt. Die folgende Abbildung zeigt die Darstellung am Beispiel dreier Subklassen.

Die möglichen Varianten dieser Darstellungsweise werden im nächsten Abschnitt vorgestellt.

5.3 Beispiel Hochschule und grafische Varianten

Die folgende Abbildung zeigt ein Beispiel. Die Superklasse soll die Personen darstellen, die an einer Hochschule den Lehrbetrieb sichern. Diese kann man sich aufgeteilt denken in Angestellte und Beamte der Hochschule sowie in externe Dozenten (Lehrende, die nicht an der Hochschule angestellt sind).

Beschäftigte einer Hochschule

In diesem Beispiel und in den folgenden werden die Klassen nur mit ihren Bezeichnungen angegeben (ohne Attribute, Methoden, usw.), da es hier nur um die Beziehungen zwischen den Klassen geht. Allerdings ist für diese Art der Modellierung unabdingbar, dass es allgemeine Attribute und / oder Methoden für die Generalisierung und jeweils spezielle Attribute und / oder Methoden für die Spezialisierungen gibt.

Nur Bezeichnungen bei den Klassen

Betrachten wir obige Generalisierungshierarchie auf Klassenebene. Die Klasse Personen enthält dann die Attribute und Methoden, die für alle Objekte Gültigkeit besitzen. Die Klassen Externe Dozenten, Angestellte und Beamte enthalten die Attribute und Methoden, die jeweils nur für die Klasse gelten. Also z.B.

• Personen die Attribute beginnTätigkeit, geburtsdatum, name und vorname.
• Externe Dozenten die spezifischen Attribute wohnort (mit PLZ), straße, organisation (Arbeitsplatz), tarif (Stundensatz).
• Angestellte die spezifischen Attribute tarifgruppe und status,
• Beamte die spezifischen Attribute fakultät, fach, amtsbezeichnung, besoldungsstufe.

Die folgende Abbildung zeigt ein weiteres Beispiel. Hier sind die an der Hochschule beschäftigten Personen unterteilt in halbtags und ganztags Beschäftigte. Wieder gilt, dass – natürlich – halbtags- und ganztags Beschäftigte gemeinsame Attribute und Methoden haben, aber natürlich auch unterschiedliche.

Zeitlicher Beschäftigungs-
umfang

Bei diesem  Diskriminator, der Umfang Beschäftigung genannt werden kann, umfassen die Subklassen genau die Attribute und Methoden, die sich mit dem Zeitaspekt der Beschäftigung befassen.

Generalisierungsmengen

Jede einzelne Beziehung zwischen einer spezialisierten und einer generalisierten Klasse wird Generalisierungsbeziehung genannt.

Generalisierungs-
beziehung

Die Generalisierungsbeziehungen, die gemeinsam eine Klasse unterteilen, stellen in der Sprache der UML-Autoren eine Generalisierungsmenge dar.

Nun gilt, dass sich sehr oft in der konkreten Modellierung mehrere Generalisierungsmengen für eine Superklasse ergeben. Auch dies sollen die folgenden Beispiele zeigen.

Die nächste Generalisierung / Spezialisierung enthält zum einen die von oben schon bekannte Generalisierungsmenge mit voll- und teilzeit Beschäftigten (Umfang Beschäftigung). Außerdem enthält sie eine weitere Generalisierungsmenge mit Studierende und Professoren, die mit Rolle im Lehrbetrieb bezeichnet wird.

Generalisierungsbeziehungen können also benannt werden und alle gleich benannten gehören zur selben Generalisierungsmenge.

Die Pfeile, die zur selben Generalisierungsmenge gehören, können auch zu einer Pfeillinie zusammengefasst werden, wie es die folgende Abbildung zeigt.

Alternative grafische Darstellung

Alternativ können die Generalisierungsmengen auch durch gestrichelte Linien, die die entsprechenden Generalisierungsbeziehungen schneiden, dargestellt werden. Vgl. die folgende Abbildung.

Nehmen wir obige zwei Generalisierungsmengen und eine weitere, die die Beschäftigten in Angestellte und Beamte (Generalisierungsmenge Art Arbeitsverhältnis) unterteilt, dann entsteht die folgende zusammengefasste Generalisierung/Spezialisierung. Die Objektklasse Personen ist dreifach unterteilt (mit drei Generalisierungsmengen):

• Nach Art Arbeitsverhältnis in Angestellte und Beamte.
• Nach Umfang Beschäftigung in Vollzeitbeschäftigte und Teilzeitbeschäftigte.
• Nach Rolle im Lehrbetrieb in Professoren und Studierende.

Es ist also möglich, dieselbe Superklasse mehrfach zu spezialisieren (mehreren Diskriminatoren auszusetzen) und dies in einer Abbildung (d.h. einem Modellelement) zusammenzufassen.

Zu beachten ist dabei aber, dass im Vergleich zu den Modellelementen, wo jeweils nur eine Generalisierungsmenge vorliegt, hier die Superklasse weniger gemeinsame Attribute und Methoden enthält. Während sie im einfachen Fall z.B. die Attribute enthält, die Vollzeit- und Teilzeitbeschäftigte gemeinsam haben, hat sie hier jetzt nur die, die alle spezialisierten Klassen gemeinsam besitzen. Bei der konkreten Umsetzung in eine Datenbank oder in ein Anwendungsprogramm muss dies berücksichtigt werden.

5.4 Überlappung und Überdeckung

Die Beispiele oben wurden so angelegt, dass die einzelnen Generalisierungsbeziehungen jeweils disjunkte (sich nicht überschneidende) Subklassen bilden. Dies ist oft der Fall, muss aber nicht sein. Nehmen wir eine Superklasse Datenverwaltende Systeme mit folgenden Subklassen:

Überlappung

• Dateisysteme
• Relationale Datenbanksysteme
• Objektorientierte Datenbanksysteme
• Information Retrieval Systeme

Dann werden sich die Subklassen nicht überschneiden. Nehmen wir allerdings noch die Subklassen

• Entwicklungssysteme und
• Verteilte Datenbanksysteme

hinzu, sieht dies anders aus. Entwicklungssysteme können Relationale Datenbanksysteme oder auch Objektorientierte Datenbanksysteme sein, Verteilte Datenbanksysteme ebenfalls. Bei genauerem Hinsehen wird man außerdem entdecken, dass Entwicklungssysteme auch Verteilte Datenbanksysteme sein können.

Ein zweiter Unterschied zwischen Generalisierungen / Spezialisierungen ergibt sich daraus, ob die Subklassen insgesamt alle Objekte der Superklasse abdecken oder nicht. Nehmen wir die im nächsten Abschnitt vorgestellte Superklasse Fahrzeuge mit ihren Subklassen PKW, LKW, Busse und Kettenfahrzeuge, dann decken die Spezialisierungen nicht alle möglichen Fahrzeuge ab (z.B. fehlen die Bagger), weshalb es sich um eine unvollständige Überdeckung handelt.

Überdeckung

Insgesamt können folgende Subklassenvarianten unterschieden werden:

• Disjunkte Subklassen / Vollständige Überdeckung
• Disjunkte Subklassen / Unvollständige Überdeckung
• Überlappende Subklassen / Vollständige Überdeckung
• Überlappende Subklassen / Unvollständige Überdeckung

Ein Beispiel für die erste Variante ist die obige Einteilung der Hochschulbeschäftigten in Teilzeit- und Vollzeitbeschäftigte. Diese Subklassen stellen auch eine vollständige Überdeckung dar. Die folgende Abbildung drückt dies grafisch aus.

disjunkt und vollständig

Sehr oft liegt auch die zweite Variante vor: die Subklassen sind disjunkt, umfassen aber nicht alle Objekte der Superklasse. Ein Beispiel, wiederum in Bezug auf den Anwendungsbereich Hochschule, ist die Bildung der Klassen Studierende und Dozenten, wenn die Superklasse alle Personen umfasst, die mit der Hochschule zu tun haben.

disjunkt, nicht vollständig

Der nächste Fall betrifft die Situation, dass die Überdeckung vollständig ist (in der Abbildung stellen wieder die drei Teilmengen zusammen die Superklasse dar), die einzelnen Subklassen sich aber überschneiden. Ein Beispiel sind hier die oben angeführten Datenverwaltenden Systeme, wenn man annimmt, dass wirklich alle Arten dieser Systeme erfasst wurden.

nicht disjunkt, vollständig

Im letzten Fall liegen wieder überlappende Subklassen vor, allerdings ist die Überdeckung nicht vollständig. Als Beispiel stellen wir uns vor, bei den oben angeführten Datenverwaltenden Systemen würden nur Relationale Datenbanksysteme, Objektorientierte Datenbanksysteme, Entwicklungssysteme und Verteilte Datenbanksysteme betrachtet.

nicht disjunkt,
nicht vollständig

5.5 Mehrere Ebenen

Von einer Baumstruktur zu sprechen hat nur Sinn, wenn es mehrere Ebenen gibt, wenn also Subklassen auch gleichzeitig wieder Superklassen sind.

Betrachten wir zur Veranschaulichung den Anwendungsbereich Fahrzeuge (aller Art). Hier kann man leicht sehr viele Fahrzeugtypen finden, die jeweils teilweise unterschiedliche Attribute und vielleicht auch Methoden haben. Damit werden sie dann in verschiedenen Klassen modelliert. Auf diesen Klassendefinitionen kann eine Generalisierungshierarchie angelegt werden, da sie ja alle auch Attribute und Methoden gemeinsam haben.

An der Spitze dieser Hierarchie soll eine Klasse Fahrzeuge (im Sinne von "Fahrzeuge aller Art") stehen mit den Attributen und Methoden, die allen Fahrzeugen gemeinsam sind.

Die Subklassen dieser Klasse sollen hier PKW, LKW, Busse und Kettenfahrzeuge sein. Weitere wären natürlich denkbar. Wie oben angeführt, handelt es sich damit um ein Beispiel für eine unvollständige Überdeckung.

Die Subklasse PKW weist nun ebenfalls Subklassen auf, für die sie Superklasse ist: Limousinen, Cabriolets, Sportwagen, Familienautos.

Gleichzeitig
Super- und Subklasse

Die Klasse Familienautos ist dann noch weiter unterteilt in Vans und Mini-Vans.

Ähnlich bei den Kettenfahrzeugen. Diese sind noch unterteilt in zivile und militärische, letztere hier dann noch in Kampfpanzer und Brückenlegepanzer.

Insgesamt haben dann in diesem Beispiel folgende Klassen die Doppelfunktion als Super- und Subklassen:

• PKW
• Familienautos
• Kettenfahrzeuge
• Militärische Kettenfahrzeuge

Das obige Klassendiagramm enthält u.a. folgende Komponenten:

• Mehrere Generalisierungen / Spezialisierungen
• Mehrere mehrstufige Generalisierungen / Spezialisierungen

Außerdem vollständige und unvollständige Überdeckungen.

Die folgende Abbildung zeigt ein weiteres Beispiel. Es soll um die Beschäftigten eines Unternehmens gehen. Hier kann man sich ohne Schwierigkeiten eine Einteilung in Arbeiter, Angestellte und Auszubildende vorstellen, die zwar bestimmte Attribute und Methoden gemeinsam haben, andere aber auch gemeinsam. Letztere finden sich dann in der Generalisierung Beschäftigte.

Noch ein Beispiel: Beschäftigte

Die Arbeiter könnten unterteilt werden in Arbeiter des Unternehmens und Leiharbeiter, die Angestellten in solche mit und ohne Führungsaufgaben und die Auszubildenden in kaufmännische und gewerbliche. Damit liegen dann jeweils drei Generalisierungsebenen vor.

Mit der Unterteilung der Angestellten ohne Führungsaufgaben in Entwickler, Programmierer und sonstige Angestellte liegen bei den Angestellten sogar vier Ebenen vor.

Wie schon ausgeführt, hätte eine solche Unterteilung nur Sinn, wenn in den Spezialisierungen jeweils spezifische Attribute vorlägen: Mehr als in der Generalisierung und teilweise andere als in den anderen Spezialisierungen derselben Ebene.

Das obige Klassendiagramm enthält u.a. folgende Komponenten:

• Mehrere Generalisierungen / Spezialisierungen
• Mehrere mehrstufige Generalisierungen / Spezialisierungen

Außerdem zahlreiche  vollständige Überdeckungen.

5.6 Vererbung

Mithilfe der Baumstruktur, die eine Generalisierung / Spezialisierung darstellt, kann nun ein zentrales Element des objektorientierten Ansatzes eingeführt werden, die Vererbung. Durch sie enthält jede Superklasse die Attribute und Methoden, die alle ihre Subklassen gemeinsam haben. Jede Subklasse wiederum ergänzt ihre spezifischen Attribute und Methoden um die der Superklasse.

Weitergeben von Attributen und Methoden

Vererbung meint also den Vorgang, dass die Subklasse die Attribute, Methoden und auch Nachrichten (vgl. Kapitel 7) der Superklasse besitzt, sie von ihr sozusagen „weitergereicht bekommt“.

Durch die Vererbung wird die Klassenhierarchie und die Ist_ein - Beziehung geklärt. An der Spitze der Hierarchie steht die allgemeinste Klasse, mit Attributen und Methoden, die alle Klassen gemeinsam haben. Die erste Ebene der Subklassen ergänzt diese dann um ihre jeweiligen spezifischen Attribute, usw.

Eine mögliche programmtechnische Umsetzung soll das folgende Beispiel andeuten. Es handelt sich um einen Auszug aus obiger Klassenhierarchie zu Fahrzeugen, die beiden Klassen Fahrzeuge und PKW.

Beispiel: Fahrzeuge

In der Klasse Fahrzeuge sind die allgemeinsten Attribute und Methoden (in diesem Kontext operations genannt) angeführt. Die Klasse Autos enthält die spezifischen und auch den Eintrag „INHERIT Fahrzeuge“, was bedeuten soll, dass sie von der Klasse Fahrzeuge erbt, dass also die Attribute und Methoden der Superklasse ebenfalls zur Verfügung stehen.

Das Beispiel zeigt auch, dass es möglich ist, ein Attribut in einer Subklasse neu zu definieren, wie es hier mit Kraftstofftyp geschehen ist (unter der Annahme, dass PKW nur verbleiten oder unverbleiten Kraftstoff tanken).

CLASS Fahrzeuge

 PROPERTIES

   Kennzeichen, Fabrikat, Modell: String;

   Farbe: FarbenTyp;

   Kilometerstand: Integer:

   Kraftstofftyp: (verbleit, unverbleit, Diesel);

   Erstzulassung: Integer;

 OPERATIONS

   Neues_Fahrzeug (...)

   Wert (...)

   Fahren (...)

   Verkaufen (...)

END Fahrzeug

CLASS PKW

 INHERIT Fahrzeuge

 PROPERTIES

  Kraftstofftyp: (verbleit, unverbleit); //neu definiert

  //zusätzliche Eigenschaften von Autos:

   Größe. (kompakt, mittel, groß)

   Extras. Menge(OptionsTyp):

END Auto

Ausnahmen

Natürlich muss hier auch die Situation der „Ausnahmen“ berücksichtigt werden, dass – z.B. bezüglich einer Methode – bestimmte Objekte einer Objektklasse eine Methode nicht ohne Modifikation „erben“ können. Stellen wir uns dazu eine Objektklasse Vögel vor. Deren Instanzen haben sicherlich alle die Eigenschaft „kann fliegen“, bis auf einige Ausnahmen. Solche Ausnahmen können erfasst werden, indem für die Ausnahmeobjekte die „geerbten“ Methoden und Attribute überschrieben werden können.

Vögel, die nicht fliegen

Mehrfachvererbung

Die sich oben ergebende Baumstruktur wird durchbrochen, wenn eine Subklasse zwei oder mehr Superklassen hat. Dann liegt eine sog. mehrfache Vererbung (multiple inheritance) vor. In einem solchen Fall erbt eine Subklasse die Methoden und Attribute mehrerer übergeordneter Klassen.

Mehrfach erben

Während die „einfache“ Vererbung zwischen einer Superklasse und einer Subklasse bei der Umsetzung in der Programmierung leicht zu lösen ist, bereitet die Mehrfachvererbung größere Probleme. Hier kann es zu kollidierenden Attributen und Methoden kommen, z.B. wenn ein Attribut in zwei übergeordneten Superklassen mit unterschiedlichen Wertebereichen auftritt.

5.7 Abstrakte Klassen

Abstrakte Klassen mussten oben schon mehrfach angeführt werden, jetzt, mit dem Konzept der Generalisierung / Spezialisierung werden sie vertieft betrachtet.

Klassen ohne Instanzen

Wie in Kapitel 2 angemerkt, haben abstrakte Klassen keine Instanzen, sie können nicht instanziieren. Sie haben aber von ihnen abgeleitete Klassen, die Instanzen haben. Ja, sie sollten sie sogar haben, nur dann ist ihre Definition sinnvoll [Rumbaugh, Jacobson und Booch 2005, S. 129].

Beispiel

Stellen wir uns im Systemdesign einer Anwendungssoftware die verschiedenen Fenster vor. Dann könnte eine abstrakte Klasse Window, die Attribute und Methoden enthalten, die alle Fenster gemeinsam haben, z.B. size, visibility, display(), hide(). Sie hätte aber keine eigenen Objekte (Instanzen). Erst die von ihr abgeleiteten konkreten Fenster hätten welche. Die folgende Abbildung zeigt eine solche Klasse.

Klasse ohne eigene Objekte

Für die Notation im Rahmen der UML gilt, dass die Bezeichnung von abstrakten Klassen kursiv gesetzt wird.

Klassen, die nicht abstrakt sind, werden konkrete Klassen (concrete classes) genannt.

Abstrakte Operationen

Abstrakte Operationen sind solche, die keine Implementierung (Methode) haben [Rumbaugh, Jacobson und Booch 2005, S. 129]. Sie können nur in abstrakten Klassen vorkommen. Sie werden in Superklassen angelegt, um dann in zahlreichen Subklassen verwendet werden zu können. Konkrete Subklassen müssen sogar die abstrakten Operationen einer übergeordneten Superklasse besitzen [ebenda].

Operationen ohne Implementierung

Die Bezeichnung einer abstrakten Operation wird kursiv gesetzt. Alternativ kann das Schlüsselwort abstract in geschweiften Klammern zur Bezeichnung hinzugetan werden.

Eine abstrakte Klasse kann also konkrete und abstrakte Operationen haben, eine konkrete Klasse nur konkrete Operationen.