12.11.24, 04:56 Uhr

Aufrufe: 162, Hits: 163

Objektorientierte Modellierung mit der UML 2.5. Für Programme und Datenbanken. (Version 2024)

 

Copyright 2024 Prof. Dr. Josef L. Staud

 

Autor: Josef L. Staud

 

Umfang des gedruckten Textes: 110 Seiten

Dieser Text ist eine aktualisierte Version meiner Texte zur Objektorientierung mit der UML 2.5. Er beschreibt die Strukturaspekte und nimmt eine Datenbankperspektive ein. Etwa jährlich erscheint eine überarbeitete neue Version.

Diese HTML-Seiten wurden mit Hilfe eines von mir erstellten Programms erzeugt: WebGenerator2 (Version 2023). Es setzt Texte in HTML-Seiten um und wird ständig weiterentwickelt. Die "maschinelle" Erstellung erlaubt es, nach jeder Änderung des Textes diesen unmittelbar neu in HTML-Seiten umzusetzen. Da es nicht möglich ist, nach jeder Neuerstellung alle Seiten zu prüfen, ist es durchaus möglich, dass irgendwo auf einer "abgelegenen" Seite Fehler auftreten. Ich bitte dafür um Verzeihung und um Hinweise (hs@staud.info).

Die Veröffentlichung im Web erfolgt ab 2022 in zwei Versionen: Mit und ohne Frame-Technologien. Zu meinem Bedauern wird die Frame-Technologie inzwischen von den Verantwortlichen als unerwünscht angesehen und es häufen sich die Hinweise, dass bestimmte Browser Frame-basierte Seiten nicht mehr korrekt interpretieren können. Deshalb habe ich eine zweite Version meines Programms WebGenerator erstellt, die ohne Frames realisiert ist.

Urheberrecht

Dieser Text ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Textes oder von Teilen dieses Textes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.

Warenzeichen und Markenschutz

Alle in diesem Text genannten Gebrauchsnamen, Handelsnamen, Marken, Produktnamen, usw. unterliegen warenzeichen-, marken- oder patentrechtlichem Schutz bzw. sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Inhaber. Die Wiedergabe solcher Namen und Bezeichnungen in diesem Text berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Gesetzgebung zu Warenzeichen und Markenschutz als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

 

 

Prof. Dr. Josef Ludwig Staud

 

Vorwort, Inhalt, Abkürzungen

Vorwort

Der Gegensatz von Struktur und Verhalten ist in der IT (bei den Digitalisierungsbemühungen) allgegenwärtig. Denken wir nur Programme und Datenbanken. Oder an Geschäftsprozesse vs. Datenbanken. Für "Struktur" in diesem Sinne wurden vor Jahrzehnten ausgefeilte Datenbanktechniken entwickelt, die derzeit mit NoSQL-Datenbanken eine an die Anforderungen des Internetzeitalters angepasste Form gefunden haben. Für "Verhalten" in diesem Sinne wurden die Programmiersprachen entwickelt, die schon immer erlaubten, Verarbeitungsvorgänge zu erfassen (dafür wurden sie geschaffen) und die es heute erlauben, die Dynamik ganzer Geschäftsprozesse in Programmen darzustellen.

Struktur und Verhalten

In den Ansätzen vor der Objektorientierung war die Aufteilung recht klar und einfach. Die Strukturen waren informationelle Strukturen und wurden per Datenmodellierung bewältigt. Die "Dynamik" (Verhalten, Abläufe, Geschäftsprozesse) wurde per Systemanalyse in Modelle umgesetzt, die Geschäftsprozesse wurden nicht oder getrennt betrachtet.

Mit der objektorientierten Theorie wurde dies etwas anders. Es werden zwar "structure" und "behavior" (wie die US-amerikanische Literatur es nennt) immer noch getrennt, mit der Einbindung von Methoden bei den Klassen sind diese aber auch gleich mit wichtigen Aspekten von Dynamik ausgestattet. Im Basiselement Klasse werden also Struktur (durch Daten in Attributen, usw.) und Verhalten (durch Programme in Methoden, usw.) integriert erfasst.

Statische und dynamische Aspekte des Anwendungs-
bereichs

Leider ist die Darstellung der objektorientierten Theorie in der Literaur sehr oft programmzentriert. Das Hauptgewicht liegt z.B. auf der Beschreibung der Klassenmerkmale, die für das Programm von Bedeutung sind. Die inhaltlichen Strukturaspekte des Anwendungsbereichs kommen zu kurz.

Das ist einer der Gründe für die Erstellung dieses Textes. Hier steht die semantische Struktur des Anwendungsbereichs, ihre Abbildung in objektorientierte Strukuren, im Vordergrund. Ein weiterer Grund war der Wunsch, eine verständliche Form der Darstellung der objektorientierten Theorie zu erhalten.

Motivation

 

Abkürzungsverzeichnis


IKS

Informations- und Kommunikationssysteme

IT

Informationstechnologie/n

KI

Künstliche Intelligenz

OCL

Object Constraint Language

OID

Objektidentifizierer

UML

Unified Modeling Language

vs.

versus (gegen, kontra)

 

1 Einleitung

1.1 Objektorientierung als solche

Entwicklungsstand

Die objektorientierte Theorie ist mittlerweile im Bereich der Programmiersprachen fest etabliert. Dies betrifft nicht nur Java oder C++, sondern die meisten neuen Sprachen, v.a. auch die für Webanwendungen. Entweder sind sie gleich objektorientiert oder ihre eigentlich prozedurale Grundstruktur wird um objektorientierte Komponenten erweitert.

Programmierung

Damit und auch unabhängig davon (als Modellierungsinstrument) ist sie in Systemanalyse und -design ebenfalls umfassend eingeführt, wobei zu beobachten ist, dass das Systemdesign noch umfassender objektorientiert erfolgt als die Systemanalyse. Die Ursache liegt sicherlich darin, dass sich die heutigen grafischen Bedienoberflächen sehr leicht und umfassend objektorientiert denken lassen. Auf der anderen Seite ist die Umsetzung der Funktionalität eines Anwendungsbereichs in objektorientierte Modelle oftmals nicht so einfach möglich oder macht zumindest mehr Schwierigkeiten. Zumal es auch Funktionalität gibt, die sich dem objektorientierten Ansatz ganz entzieht.

Systemanalyse
und -design

Nicht so weit mit dem Vordringen der objektorientierten Theorie ist es bei Datenbanksystemen. Hier ist zwar in der Theorie alles vorbereitet und es existieren auch kommerziell verfügbare Datenbanksysteme mit einem "Stück Objektorientierung", der große Durchbruch in der Praxis lässt allerdings auf sich warten. Und dies schon recht lange.

Datenbanken

Objektorientierung

Was ist das nun, Objektorientierung? Es bedeutet eine bestimmte Art und Weise, mit der in der Informatik und Wirtschaftsinformatik Realweltphänomene wahrgenommen werden. In der Systemanalyse und Programmierung die der zu programmierenden Anwendung. Im Bereich der Datenbanken der so genannte Anwendungsbereich, der zur Modellierung ansteht.

Objektorientierte Modellierung

Die objektorientierte Theorie ist also ein Modellierungsansatz, ein Werkzeug zur adäquaten Beschreibung eines Anwendungsbereichs. Für die Anwendungsentwicklung als Systemanalyse und Systemdesign, für Datenbanken als Datenmodell. Diese Modelle dienen dann der konkreten Programmierung bzw. der Einrichtung der Datenbank. Das Ergebnis der Modellierungsbemühungen wird Objektorientiertes Modell genannt.

Objektorientierte Modelle

Zusätzlich zu obigem behaupten wichtige Vertreter der objektorientierten Theorie (vor allem die Autoren der UML, worauf hier immer wieder eingegangen wird) seit einigen Jahren, dass die objektorientierte Theorie auch geeignet sei, Geschäftsprozesse zu modellieren. Dass also das Instrumentarium zur Beschreibung von Abläufen, vom Zusammenspiel in Systemen, auch geeignet sei für die Prozessmodellierung. Eine Einschätzung hierzu findet sich in [Staud 2019].

Auch für Geschäfts­prozesse?

1.2 Die UML

Die Unified Modeling Language stellt derzeit und schon recht lange einen Standard für objektorientiertes Modellieren dar. Die Leistung der UML-Autoren bestand u.a. darin, eine Vereinheitlichung der verschiedenen objektorientierten Theorieansätze durchzuführen.

Die aktuelle Version (August 2024) der Texte zur UML kann von dieser Adresse heruntergeladen werden: http://www.omg.org/spec/UML/2.5/. Sie wird von der Object Management Group (OMG) bereitgestellt.

Es war aber nicht nur die Vereinheitlichung, sondern auch die Präzisierung und Vertiefung, die den Wert der UML ausmacht. Hier auch durch eine ausgefeilte Metamodellierung.

Hauptwirkungsbereich der objektorientierten Theorie war und bleibt die Systemanalyse mit ihrer Zweiteilung zwischen Struktur und Verhalten (im Anwendungsbereich). Diese Zweiteilung wurde in der objektorientierten Theorie von Anfang an übernommen, vor der UML und dann auch durch die UML-Autoren. Das ist nun mal ein wesentliches Strukturmerkmal von Systemen, aber auch von anderen Anwendungsbereichen, z.B. Geschäftsprozessen (wo sich dies in Abläufen und genutzten Daten artikuliert).

Statik vs. Dynamik -
Struktur vs. Verhalten

Die folgende Abbildung aus den Original quellen zeigt die thematische Abdeckung der UML und macht auch die Aufteilung in Struktur- und Verhaltensabbildungen deutlich. Im vorliegenden Text geht es um die wichtigsten Methoden zur Erfassung der Strukturen. Diese sind in der Abbildung mit verdickter Randlinie dargestellt.

Abbildung 1.1/ 1.2-1: Abbildungen für die Struktur- und Verhaltensmodellierung in der UML
Quelle: (OMG 2017, S. 685, Figure A.5), grafisch verändert.

Eine Beschreibung der wichtigen Methoden zur Verhaltenmodellierung aus der UML findet sich in [Staud 2019].

1.3 Verwendete Datentypen

In den in den folgenden Kapiteln gezeigten Beispielen werden auch Datentypen angegeben. Folgende werden in den Texten der UML und in [Rumbaugh, Jacobson und Booch 2005] verwendet und sollen deshalb auch hier zum Einsatz kommen:

UML-Datentypen

  • Category
  • Money
  • String
  • Date
  • Integer
  • Boolean
  • TimeofDay

Einige Beispiele werden auch in C++ angegeben. Da finden folgende Datentypen Verwendung:

C++

  • Char
  • Float
  • Double
  • Int

Wo nötig und sinnvoll sind noch selbsterklärende weitere Datentypen eingefügt.

1.4 Formatierung und Schreibweise

Im Text und in den Grafiken wird jeweils ein bestimmtes Schriftformat für Anwendungsbereiche, Objektorientierte Modelle, Klassen, Objekte, Attribute und Methoden verwendet. Außerdem schreibt die UML bei einigen dieser Bezeichner einen bestimmten Aufbau des Wortes bzgl. Kleinschreibung, Großschreibung und Unterstreichung vor. Dieser wird hier schon mal vorgestellt, bei der Einführung des jeweiligen Theorieelements dann erläutert.

Hier die für diesen Text gewählte Formatierung:

  • Anwendungsbereiche: Unternehmen (Arial, fett, 11)
  • Objektorientierte Modelle: Personalwesen (Arial, fett, Großbuchstaben, 9).
  • Klassen: Angestellte (Arial, fett, 9)
  • Objekte: Maier:Angestellte (Arial, 8; zum Aufbau vgl. unten)
  • Attribute: datumEinstellung (Arial, 9; zum Aufbau vgl. unten)
  • Methoden/Operationen: einstellen() (Arial, 9; zum Aufbau vgl. unten)

 

2 Objekte und Objektklassen

Zwei Basisbegriffe

Mit Hilfe der objektorientierten Theorie werden Modelle und Programme erstellt. Typischerweise von einem Anwendungs- oder Gegenstandsbereich. Z.B. von einem Geldautomaten, den Geschäftsprozessen in einer Abteilung, dem Mahnwesen eines Internetunternehmens, usw. Diese Modelle dienen dann der Erstellung der Software und der Einrichtung der objektorientierten Datenbank.

Modelle erstellen

Ganz zu Beginn dieser Modellierungsprojekte muss man sich somit mit der Realwelt auseinandersetzen. Deshalb braucht man einen Begriff für die ersten noch vagen Eindrücke, die man erhält, wenn man mit der Untersuchung beginnt.

Realweltphänomen

Dieser Begrift ist Realweltphänomen. Er bezeichnet also unsere noch nicht modelltechnisch strukturierten Wahrnehmungen zu Beginn der Modellierung.

Hat man dann die Realweltphänomene strukturiert und mit Informationen versehen, müssen sie auch wieder abstrakt benannt werden können. Die UML-Autoren nutzen dafür den Begriff entity.

entity

Untersucht man den Sprachgebrauch [Anmerkung] , stellt man fest, dass mit entity in den UML-Texten wie auch ansonsten in Teilen der US-amerikanischen Informatikliteratur tatsächlich so etwas wie Informationsträger gemeint ist: Es existiert und hat Eigenschaften, die hier in der objektorientierten Theorie als Attribute festgehalten werden.

Informationsträger

Hintergrund:

Jede Theorie hat Begriffe und Konzepte, die sie nicht aus sich heraus erklären kann, sondern auf denen sie aufbaut. Sie entstammen ihrer begrifflichen und philosophischen Umwelt. In der objektorientierten Theorie im Allgemeinen und in der UML im Besonderen ist einer dieser Begriffe entity.

2.1 Einführung

Wir alle benutzen umgangssprachlich den Begriff Objekt. Es wäre wohl auch Übereinstimmung zwischen uns allen herstellbar, dass der Begriff etwas Zusammengehöriges bezeichnet. Genau das war die Motivation für die Wortwahl, ganz am Anfang des objektorientierten Denkens: Die elementaren Einheiten einer Modellierungstheorie sollten etwas Zusammengehöriges beschreiben und nicht Teile davon.

Zusammengehörig

Überwindung der Aufteilung von Information also. Motiviert war dies v.a. durch die relationale Datenbanktheorie, die durchaus für ein Realweltphänomen (ein Objekt) eine Vielzahl von Relationen fordert. Einen Ausdruck fand dieses Denken in dem in der Randspalte angegebenen Satz von Roger King [King 1989].

"My cat is object-oriented".

Nun wissen wir auf- oder besser abgeklärten Menschen des neuen Jahrtausends, dass Zusammengehörigkeit letztendlich auch eine Illusion ist. Alle was ist, besteht aus Teilen, diese auch wieder, usw. Trotzdem bedarf es eines Angel- oder Ankerpunktes, mit dem wir arbeiten können, sonst wäre Realitätserfassung nicht mehr möglich.

So kommt es, dass wir den Wald (der Spaziergänger) oder die Fichten, Tannen, Laubbäume aller Art, usw. (der Förster) erfassen und nicht die Bestandteile Blätter, Zweige, usw., vom weiteren inneren Aufbau ganz zu schweigen.

Obiges macht zweierlei klar: Erstens die Wahl eines "Ankerpunktes" in der sozusagen senkrechten "Zerlegungsdimension" und zweitens die Subjektivität des Vorgangs. Denn der "einfache" Waldbesucher nimmt anderes wahr als der Förster und dieser wiederum anderes als eine durch den Wald wandernde Biologin, ganz zu schweigen von einem durch den Wald flanierenden Liebespaar, dessen konzentrierte Wahrnehmung kaum von den Waldbestandteilen jeglicher Art gestört wird.

Ankerpunkt und Subjektivität

Das, wofür man sich letztendlich entscheidet, wird dann Objekt genannt. Also z.B. Abteilung, Stelle, Geldautomat, Rechnung, usw.

Objekte in der objektorientierten Theorie

Wie kann das nun für die objektorientierte Theorie präzisiert werden? Zuerst einmal knüpfen wir an das an, was wir auch umgangssprachlich darunter verstehen. Objekte sind die Dinge (die UML-Autoren haben dafür den Begriff Classifier, vgl. unten), die wir wahrnehmen und denen wir dadurch Informationen zuordnen.

Informationen zuordnen

Damit sind wir einen Schritt weiter. Wahrnehmung bedeutet Informationen zuzuordnen. Dadurch werden Realweltphänomene (vgl. oben) zu etwas fassbarem.

Diese erste Wahrnehmung der Realität ist Thema der sog. Konzeptionellen Modellierung und wird hier nicht weiter thematisiert. Nur zwei Aspekte sollen angesprochen werden. Erstens ist unsere Wahrnehmung nicht nur subjektiv, wenn wir einen Anwendungsbereich betrachten (siehe oben), sondern auch zielgerichtet, idealerweise auf das Ziel, die Geschäftstätigkeit des Unternehmens zu unterstützen. Zweitens sind es im wesentlichen Attribute (vgl. zu Attributen [Staud 2021]), die wir für die Modellierung verwenden. Auf Attribute fallen also die Informationen zurück, die oben angesprochen wurden.

Selektive,
hoffentlich aber
gezielte
Wahrnehmung

Doch zurück zu den Objekten. In einem Theoriegebäude wird so ein Konzept der Alltagswelt dann natürlich präzisiert. So sind die "wahrgenommenen Informationen" hier die gerade eingeführten Attribute (die gegenüber Eigenschaften präziser gefasst sind) und zusätzlich wird die Möglichkeit der Informationsverarbeitung bedacht:

Objekte haben Methoden, die angeben, welche Informationsverarbeitung mit ihren Attributsausprägungen möglich ist.

Nehmen wir als Beispiel die Angestellen eines Unternehmens. Sie sind Objekte und haben Attribute. Z.B. name, vorname, datumEinstellung. Als Methoden kommen einstellung(), gehaltszahlung(), versetzung(), usw. in Frage.

Beispiel Angestellte

Vgl. zur Formatierung der Bezeichnungen von Attributen und Methoden Abschnitt 1.4.

Wichtig war den ersten Autoren der objektorientierten Theorie auch der direkte Bezug von Realwelt und Modell. Einem Objekt der Realwelt (z.B. einer Angestellten in einem Unternehmen) sollte eine integrierte Repräsentation im Modell gegenüberstehen.

Objekte sind damit die kleinsten Einheiten eines objektorientierten Modells, die, auf denen das restliche Modell aufbaut. So wie Relationen ("Tabellen") in der relationalen Theorie, Entitäts- und Beziehungstypen in der ER-Modellierung, Funktionen und Ereignisse in der Geschäftsprozessmodellierung mit EPKs, usw. Aufbauend darauf können Objekte wie folgt definiert werden:

Basiseinheiten

Objekte
im Sinne des objektorientierten Ansatzes sind Realweltphänomene, die durch Attribute beschrieben und/oder denen Methoden zugewiesen werden.

Mittlerweile kann diese Definition dahingehend ergänzt werden, dass natürlich weitere Informationstypen wie Grafik, Bild, Text, usw. ebenfalls zur Identifizierung und Spezifizierung von Objekten dienen können.

In der praktischen Arbeit ist die Bildung korrekter Objekte von großer Bedeutung. Ein Weg dahin geht über die Betrachtung der Attribute, die erfasst werden sollen. Geht es nur um ein einzelnes Attribut für das Realweltphänomen (z.B. abteilungsbezeichnung) wird dieses zu einer beschreibenden Information für ein anderes Realweltphänomen (z.B. Angestellte). Geht es dagegen um mehr als ein Attribut (z.B. abteilungsbezeichnung und abteilungsleiter) entsteht ein Informationsträger im Sinne der konzeptionellen Modellierung und hier in der objektorientierten Theorie ein Objekt. Natürlich muss mindestens eines der Attribute identifizierenden Charakter haben.

Ganz pragmatisch:

Objektfindung durch
Attribute

Objektfindung

Es werden also alle die Realweltphänomene zu Objekten, denen man neben einem identifizierenden Attribut (oder einer identifizierenden Attributkombination) mindestens ein weiteres zuordnet.

Identifizierende(s) Attribut(e) + ein weiteres beschreibendes (mindestens) ==> Objekt

Ausgangspunkt Realwelt-
phänomene

bezPS

Noch einige Beispiele

Nehmen wir das Attribut bezPS (Bezeichnung einer Programmiersprache). Dies kann einfach ein Attribut sein, z.B. von den Angestellten eines Softwarehauses (die Programmiersprache, mit der sie hauptsächlich programmieren). Entschließt man sich aber, die Programmiersprache näher zu beschreiben, z.B. durch Angabe des Compilers (bezComp), entstehen datenbanktechnisch Programmiersprachen als Objekte. Der Schlüssel ist dann bezPS, die Bezeichnung des Compilers ist ein beschreibendes Attribut.

bezProjekt

Angenommen, in einem Anwendungsbereich Unternehmen sollen Projekte erfasst werden. Dann kann z.B. das Attribut persNr (Personalnummer) zusammen mit einem Attribut bezProjekt (Projektbezeichnung) festhalten, welcher Angestellte in welchem Projekt mitarbeitet. Es beschreibt also Projektmitarbeit. Kommt dann aber z.B. das Attribut name (Name des Angestellten) hinzu, entstehen zusätzlich Objekte, die Angestellte beschreiben. Erst mal mit persNr und name, im weiteren dann sicherlich auch mit wohnort, plz, strasse usw.

Dies löst auch die in der Literatur immer wieder gestellte Frage, wann ein beobachtetes Phänomen Objekt oder Eigenschaftist. Dient es dazu, etwas anderes zu beschreiben, ist es Eigenschaft und wird als Attribut bzw. Attributsausprägung modelliert. Wird es selber durch andere Informationen beschrieben, ist es Objekt. Hierzu ein Beispiel:

Objekt oder
Eigenschaft?

Wenn es Geschäftsstellen eines Unternehmens in mehreren Städten gibt, sollten dann die Städte eine Eigenschaft der Objekte Geschäftsstellen sein oder sollten sie zu eigenständigen Objekten werden?

Mit der oben eingeführten Regel kommt man zu folgendem Ergebnis: Werden die Städte näher beschrieben, z.B. durch einwohnerzahl, kaufkraft, region, usw. müssen eigene Objekte angelegt werden. Sind die Städte über ein identifizierendes Attribut allein als Eigenschaften der Geschäftsstellen geführt, dann sollten sie Attribut der Geschäftsstellen sein.

Zuordnung

Objektklassen

Objekte, die dieselben Attribute und Methoden haben, die also strukturell gleich sind, werden zu Objektklassen (kurz auch Klassen) zusammengefasst.

Von Objekten zu Objektklassen

Auch dieser Abstraktionsvorgang ist uns vertraut. Schließlich nehmen wir, wenn wir aus einiger Entfernung eine Ansammlung bestimmter Bäume sehen, diese als Wald war. D.h. wir abstrahieren und fassen Tannen, Fichten, Laubbäume, usw. als Einheit auf. Diese Klassenbildung ist ein gängiger Abstraktionsmechanismus aller Modellierungsansätze, ein Schritt, um die Komplexität der realen Welt für die gezielte Modellierung zu reduzieren.

...durch Abstraktion

Es werden also z.B. alle Angestellten eines Unternehmens zusammengefasst, um im obigen Beispiel zu bleiben. Aber schon, wenn wir für unterschiedliche Gruppen von Angestellten teilweise unterschiedliche Attribute und/oder Methoden haben, ist dies nicht mehr so einfach (vgl. Kapitel 6).

Die Klasse erhält dann eine Bezeichnung und sie hat die für die Einzelobjekte eingeführten Attribute und Methoden.

Natürlich werden einer Objektklasse nur Attribute zugeordnet, die genau diese Objekte beschreiben - und zwar mit jeweils genau einer Attributsausprägung - und nur Operationen, die auf genau diesen Objekten ausführbar sind.

Attributs-
zuordnung

Deshalb wird bei dem Realweltphänomen Rechnung zwischen Rechnungskopf und Rechnungspositionen unterschieden. Rechnungsköpfe haben die Attribute rechnungsnummer, rechnungsdatum, usw. Rechnungspositionen dagegen die Attribute positionsnummer, artikelbezeichnung, menge, einzelpreis und positionsgesamtpreis. D.h. es entstehen Objekte, die Rechnungsköpfen und andere Objekte, die Rechnungspositionen entsprechen.

Beispiel

Bezeichnungen von Attributen und Methoden/Operationen: zu ihrem Aufbau vgl unten, zur Formatierung Abschnitt 1.5.

Wie sehen dies die UML-Autoren und wie betten sie das Klassenkonzept in ihr Theoriegebäude ein? Sie gehen aus vom Ziel einer Klasse, das sie wie folgt definieren: Eine Klasse soll eine Klassifizierung von Objekten leisten und die Struktur- und Verhaltenseigenschaften dieser Objekte festlegen [OMG 2003a, S. 87]. Dies entspricht dem oben ausgeführten.

Die Sicht der UML-Autoren

Für die UML-Autoren ist eine Klasse ein sog. Classifier (vgl. Abschnitt 2.8.4) und zwar einer, der Attribute und Operationen hat [OMG 2003a, S. 87].

Classifier

Die oben schon angeführte strukturelle Gleichheit aller Objekte betont die folgende Definition:

Klasse
Eine Klasse beschreibt eine Menge von Objekten, die dieselben Merkmale, Einschränkungen (semantische Integritätsbedingungen) und dieselbe Semantik besitzen. ([OMG 2003a, S. 86], Übersetzung durch den Verfasser). Mit Merkmalen sind hier Eigenschaften/Attribute gemeint (Staud).

Womit sie dann das Ziel einer Klasse präzisieren können:

Das Ziel einer Klasse ist die Klassifikation von Objekten und die Festlegung der Merkmale, die die Struktur und das Verhalten dieser Objekte festlegen. ([OMG 2003a, S. 87], Übersetzung durch den Verfasser).

Weiter geben sie einen wichtigen Hinweis auf korrekte Modellierung, wenn sie ausführen, dass die Objekte einer Klasse für jedes Attribut, das zur Klasse gehört, Werte enthalten müssen [Anmerkung] [OMG 2003a, S. 87]. Denn das bedeutet, dass jedes Attribut für alle Objekte Gültigkeit haben muss. Dies verhindert zum Beispiel, dass das Attribut (beherrschte) Programmiersprache für alle Angestellten angelegt wird, wenn es Angestellte gibt, die nicht programmieren (vgl. zu dieser Problematik auch Kapitel 6).

Sehr wichtig, oft nicht beachtet!

Sie weisen auch darauf hin, dass es voreingestellte Werte für die Attribute geben kann, die bei der Objekterzeugung (Instantiierung, vgl. unten), falls nicht anders gewollt, genutzt werden. Diese werden dann beim Attribut vermerkt.

Voreinstellung für die Instantiierung

Soweit die UML-Autoren. Zusammenfassend kann dann wie folgt definiert werden:

Objektklasse
In einer Objektklassesind Objekte zusammengefasst, die dieselben Attribute und Methoden haben.

In einem objektorientierten Modell gibt es in der Regel zahlreiche Objektklassen. Diese beschreiben zum einen jeweils eine Menge von Objekten der Realwelt, zum anderen stehen sie in Beziehungen (dazu unten mehr).

Objektorientierte Modelle

Mit obigem sollte es bereits klar geworden sein: Auch die objektorientierte Theorie baut, wie die meisten anderen Modellierungsansätze, auf dem Attributkonzept auf. Attribute sind das zentrale Beschreibungsmittel, Attribute bestimmten, welche Realweltphänomene zu Objekten werden und welche dann zu Klassen zusammengefasst werden.

Objekte - Attribute - Methoden

Wir können also zu Beginn einer Modellierung von folgenden notwendigen Schritten ausgehen:

Notwendige Schritte

  • Im ersten Schritt werden bestimmte Realweltphänomene durch Attribute beschrieben, wodurch sie zu Objekten werden. Ihnen werden Methoden zugeordnet.
  • Im zweiten Schritt werden die Objekte, die dieselben Attribute haben und denen dieselben Methoden zugeordnet sind, zu Objektklassen zusammengefasst.

Methoden

Was ist nun, etwas genauer, mit Methoden gemeint? Mit Objekten der Realwelt können bestimmte Dinge gemacht werden, bzw. sie haben ein bestimmtes Verhalten. Einiges davon ist im Anwendungsbereich von Bedeutung. Zum Beispiel:

Verhalten - aktiv und passiv

  • Objekte Studierende: Sie können immatrikuliert und exmatrikuliert werden, sie können Prüfungen besuchen und Noten erhalten.
  • Objekte PCs für ein Unternehmen: Sie können beschafft, in einer Abteilung installiert, einem Angestellten zugewiesen oder auch ausgemustert werden.
  • Objekte Abteilungen in einem Unternehmen: Sie können eingerichtet, mit Personal versehen, einen geografischen Standort mit bestimmten Räumen zugeordnet bekommen oder auch geschlossen werden.
  • Objekte Angestellte eines Unternehmens: Sie können eingestellt, entlassen, befördert, versetzt werden und Gehälter bekommen.
  • Objekte Rechnungen: Sie können entstehen, bezahlt, storniert oder gemahnt werden.

Weil diese Methoden einzelne Instanzen betreffen und nicht die gesamte Klasse (vgl. unten), werden sie auch Instanzmethoden genannt.

Für Methoden gibt es in der Literatur zwei Interpretationen, die passive ("können gemacht werden") und die aktive ("haben Verhalten"). Beide sind richtig. Es geht immer um Aktivitäten, die mit den Objekten in Zusammenhang stehen.

Passiv und aktiv

Die UML-Autoren sprechen in [OMG 2003a] nur von behavior, wenn sie die dynamischen Aspekte eines Anwendungsbereichs thematisieren. Dazu unten mehr.

So wie die Realweltobjekte durch die Modellobjekte in der Datenbank repräsentiert werden, wird das Verhalten durch die Methoden repräsentiert. "Einstellen" also durch eine Methode, die eine Personalakte in den Datenbanken des Unternehmens anlegt, usw.

Realwelt vs. Modell

Die folgende Abbildung fasst dies alles zusammen: erstens den Zusammenhang zwischen Realwelt und Modell, zweitens den Zusammenhang zwischen Attributen, Objekten und Methoden.

Abbildung 2.1-1: Realwelt und ihre Repräsentation im Objektorientierten Modell

Damit wird wieder der qualitative Sprung deutlich, der hier gegenüber älteren Modellierungsansätzen vorliegt. In der objektorientierten Modellierung werden die Objekte nicht nur informationell durch Attribute beschrieben, sondern es wird auch ihr Verhalten modelliert.

Operationen

Im objektorientierten Modell werden diese Methoden durch Operationen repräsentiert.

Oftmals werden Methoden und Operationen so abgegrenzt, dass Operationen als die "Dienstleistungen, die von einem Objekt angefordert werden können" und Methoden als die Implementierungen der Operationen definiert werden [Oestereich 1998, S. 236].

Methoden vs. Operationen

Welche Methoden bzw. Operationen auf ein Objekt anwendbar sind, hängt sehr stark von dessen Aufgabe im Anwendungsbereich ab. Einige Operationen sind aber natürlich von grundlegender Bedeutung und liegen immer vor. So z.B. die für die Erzeugung oder die Löschung eines Modellobjektes.

Insgesamt geht es also darum, die "Dreiecksbeziehung" zwischen Attributen, Objekten und Methoden zu klären, d.h., identifizierte Objekte mit gewünschten Attributen und Methoden in eine geeignete Struktur zu bringen.

Dreiecksbeziehung

Abbildung 2.1-2: "Dreierbeziehung" Objekte - Attribute - Methoden

Die UML-Autoren sehen Operationen so, dass diese auf einem Objekt aufgerufen werden und Änderungen in den Attributsausprägungen ("Werte der Attribute") des Objekts bewirken können. Sie können auch als Ergebnis einen Wert zurückgeben, wenn ein "Ergebnis-Typ" für die Operation definiert wurde. Darüberhinaus kann der Aufruf von Operationen auch Veränderungen in den Werten anderer Objekte bewirken, die - direkt oder indirekt - von dem Objekt, auf dem die Operation aufgerufen wird angesteuert werden können [OMG 2003a, S. 87].

Änderung von Attributs-
ausprägungen - hier und dort

Sie weisen außerdem darauf hin, dass durch den Aufruf von Operationen auch die Erzeugung und Löschung von Objekten veranlasst werden kann.

Betrachten wir nochmals das oben schon eingeführte Beispiel der Angestellten eines Unternehmens. Sie existieren, wir nehmen sie wahr, wir weisen Informationen zu (die für die Geschäftsprozesse benötigten), z.B.

Beispiel Angestellte

  • Personalnummer
  • Name
  • Vorname
  • Postleitzahl (PLZ)
  • Ort
  • Straße
  • Einstellungsdatum
  • Geburtstag

usw. Sie benötigen aber auch Methoden wie

  • Einstellen (des Realweltobjekts, Erzeugung des Datenbankobjekts)
  • Entlassen (des Realweltobjekts, Löschen des Datenbankobjekts)
  • Versetzen
  • Befördern
  • Gehalt zahlen

usw.

2.2 Instantiierung und Klassifikation

In der objektorientierten Theorie, vor allem in der objektorientierten Programmierung, werden Objekte oft als Instanzen bezeichnet. Woher kommt dieser Begriff?

Instanzen

Bei der Bildung von Objektklassen werden die Definitionsmerkmale der Objekte bei der Klasse hinterlegt, so dass formuliert werden kann:

Die Objekte einer Klasse werden durch die Klassendefinition beschrieben.

Erzeugt nun (z.B. in einem Programm) die Klasse ein Objekt (z.B. mit Hilfe einer Methode CREATE) nutzt sie die hinterlegten Definitionsmerkmale und richtet das Objekt ein. Z.B., um im obigen Beispiel zu bleiben, für einen neuen Angestellten. Dieser Vorgang wird als Instantiierung (instantiation) bezeichnet. Daher rührt dann der Begriff Instanz für das neu entstehende Objekt.

Instantiierung führt zu Instanzen

Instantiierung bedeutet somit, dass ein und dieselbe Definition benutzt wird, um Objekte mit demselben Aufbau und demselben Verhalten zu erzeugen. Konkret wird u.a. folgendes festgelegt:

  • die Menge der Attribute der Instanzen
  • die Menge der Operationen
  • die Menge der Methoden, die den Operationen entsprechen

Dieser Schritt von der Klasse zum Einzelobjekt hat als Gegenstück den ursprünglichen, der von den Einzelobjekten zur Klasse führte (vgl. oben). Er beruhte auf der (strukturellen) Gleichheit der Objekte und wird Klassifikation (classification) genannt.

Klassifikation

Hier nun die allgemeine Definition der UML-Autoren von Instanzen auf der Basis des Begriffs entity:

Instanz
"An entity that has unique identity, a set of operations that can be applied to it, and state that stores the effects of the operations." [OMG 2003a, S. 10]

Zum Begriff und Konzept entity vgl. Kapitelanfang.

2.3 Objektklassen als Verwalter von Information

So wie sie nun hier definiert sind, werden Objektklassen auch zu Verwaltern von Informationen. Zu den Informationen, die bei der Klasse verwaltet werden, gehören

  • die Informationen der einzelnen Instanzen,
  • Informationen zur Klasse als Ganzes,
  • Prozeduren, mit denen die interne Repräsentation der Datenstruktur (Beschreibung der Objekte) verändert wird.

Zu den Informationen für die Klasse als Ganzes gehören Attribute, die für alle Instanzen gleich sind und aggregierte Informationen wie "Anzahl Objekte" oder der Mittelwert eines entsprechenden Attributs. Solche Attribute werden Klassenattribute genannt. Sie sind so definiert, dass eine Ausprägung die gesamte Klasse betrifft. Ihre Kennzeichnung erfolgt durch Unterstreichung. Beispiele sind anzahlMitarbeiter und gehaltssumme in einer entsprechenden Klasse zu den Angestellten eines Unternehmens.

Klassenattribute

Bezeichnungen von Attributen und Methoden/Operationen: zu ihrem Aufbau vgl unten, zur Formatierung Abschnitt 1.4.

Daneben gibt es auch klassenbezogene Methoden (class methods). Sie sind unabhängig von der Existenz der einzelnen Objekte, sie betreffen die Gesamtheit der Objekte der Klasse. Beispiele in einer Klasse Angestellte könnten feststellenAnzahl und berechnenGehaltssumme sein, passend zu den obigen Attributen. Auch hier erfolgt die Kennzeichnung durch Unterstreichung.

Klassenmethoden

Wie in der UML vorgeschlagen, werden in den textlichen und grafischen Darstellungen von Objektklassen Klassenattribute und -methoden durch Unterstreichung gekennzeichnet (vgl. die Abbildungen unten).

Klassenmethoden und -attribute machen einen grundsätzlichen Unterschied bei der Klassenbildung im objektorientierten Ansatz und bei älteren Modellierungsansätzen, z.B. der Bildung von Entitätstypen in der ER-Modellierung, deutlich. Sie zeigen, dass hier auch die Klassen selbst Träger von Attributen und Methoden sein können.

Klassen als Träger von Attributen und Methoden

2.4 Grafische und textliche Darstellung

2.4.1 Klassen

Die Darstellung von Klassen erfolgt durch ein Rechteck mit der Bezeichnung der Klasse. Folgende weitere Festlegungen für die grafische Darstellung gelten in der UML [OMG 2003a, S. 88]:

  • Die Bezeichnung der Klasse wird zentriert und in Fettschrift gesetzt
  • Der erste Buchstabe der Klassenbezeichnung wird groß gesetzt
  • Besteht die Bezeichnung aus mehreren Wörtern, werden diese jeweils mit Großbuchstaben begonnen und ohne Leerzeichen aneinandergefügt.

Die folgende Abbildung zeigt einige Beispiele.

Abbildung 2.4-1: Grafische Darstellung einer Objektklasse

In der UML ist das auch die grafische Darstellung eines Classifiers, der "obersten" (abstrakten) Klasse in der Metamodellierung (vgl. Abschnitt 2.8.4), und Klassen sind davon abgeleitet. Deshalb müsste eigentlich über der Klassenbezeichnung das Schlüsselwort class stehen. Dieses wird bei Klassen aber weggelassen, da, wie die UML-Autoren schreiben, Klassen die am meisten genutzten Classifier sind. So wird es auch hier gehalten.

Classifier

Das Rechteck kann Unterbereiche haben für Attribute und Methoden. Werden die Attribute hinzugenommen ergibt sich mit dem obigen Beispiel zu den Angestellten die Darstellung wie in der folgenden Abbildung.

Die Attribute und Operationen werden textlich wie folgt angegeben:

  • Sie werden in Normalschrift gesetzt und links ausgerichtet
  • Sie werden klein geschrieben
  • Falls sie aus mehreren Wörtern bestehen, wird das zweite Wort mit einem Großbuchstaben begonnen und direkt an das erste angefügt. Für ein evtl. drittes Wort gilt entsprechendes.

Beispiele: gehalt, alter, datumEinstellung. Die Festlegung der Formatierung und des Schriftformats ist in Abschnitt 1.5 angegeben.

Abbildung 2.4-2: Darstellung von Objektklassen mit Attributen

Ergänzt man zusätzlich die Methoden / Operationen wird ein weiterer Bereich mit der Auflistung der Operationen unten angefügt. Die Operationen werden textlich wie die Attribute gestaltet, zusätzlich werden die Funktionsklammern, mit oder ohne Parameter, angegeben. Beispiele: zahlenGehalt(), einstellen(), entlassen().

Klassenattribute und -methoden werden genauso dargestellt und zusätzlich unterstrichen. Mit obigen Instanz- und Klassenmethoden sowie Klassenattributen ergibt sich damit die Klasse Angestellte wie in der folgenden Abbildung.

Abbildung 2.4-3: Grafische Darstellung von Objektklassen mit Attributen, Methoden, Klassenattributen und Klassenmethoden

Bedeutung der Attribute und Methoden

Attribute (immer auf die einzelnen Angestellten bezogen):

  • persNr: Personalnummer
  • name: Name
  • vname: Vorname
  • plz: Postleitzahl
  • ort: Wohnort der Adresse
  • strasse: Straße der Adresse
  • datumEinst: Datum der Einstellung
  • gebTag: Geburtstag

Klassenattribute:

  • anzMitarb(): Anzahl der Mitarbeiter
  • summeGehalt(): Gehaltsumme der Angestellten

Methoden:

  • einstellen(): Systemseitige Durchführung einer Einstellung.
  • entlassen(): Systemseitige Durchführung einer Entlassung.
  • versetzen(): Systemseitige Durchführung einer Beförderung.
  • befoerdern(): Systemseitige Durchführung einer Beförderung.
  • zahlenGehalt(): Systemseitige Durchführung einer Gehaltszahlung.

Klassenmethoden:

  • feststAnzahl(): Bestimmung der Gesamtzahl der Angestellen
  • berGehSumme(): Bestimmung der Gehaltssumme aller Angestellten

Zusätzlich ist es möglich, Voreinstellungen bei den Attributen anzugeben. Dies erfolgt nach der Festlegung des Datentyps. Z.B., wenn in der obigen Klasse die meisten Angestellten aus Ravensburg kommen, so:

Voreinstellungen

ort: string = 'Ravensburg'

plz: string = 'D-88212'

Vgl. weitere Beispiele mit Datentypen, die aus der Anwendung heraus entstanden sind (Area, Rectangle, XWindow) im folgenden Abschnitt.

2.4.2 Instanzen bzw. Objekte

Manchmal ist es sinnvoll, einzelne Instanzen und ihr Zusammenspiel zu betrachten. Dann müssen einzelne Instanzen (Objekte) dargestellt werden. Dies geschieht ebenfalls durch Rechtecke. Dabei wird im oberen Teil das Objekt und die zugehörige Klasse angegeben:

  • Objektbezeichnung:Klassenbezeichnung

Ein Beispiel für ein Objekt aus der Klasse Angestellte:

  • müller:Angestellte

Ist die Benennung eines bestimmten Objekts nicht wichtig, nicht sinnvoll oder nicht möglich, wird die Objektbezeichnung weggelassen:

  • :Angestellte

Darunter folgen die Attribute mit der zur Instanz gehörenden Attributsausprägung:

  • Attributsbezeichnung = attributsausprägung

Z.B.

  • ort = München

Im Vergleich zur Darstellung von Klassen werden hier also statt der Attribute mit ihren Datentypen die Attributsbezeichnungen und Attributsausprägungen angegeben. Statt konkreter Werte bei den Attributsausprägungen können auch Wertebereiche angegeben werden. Die folgende Abbildung zeigt die abstrakte grafische Darstellung.

Abbildung 2.4-4: Darstellung eines Objekts in Objektdiagrammen

Der Ausdruck Objektbezeichnung:Klassenbezeichnung wird nicht fett gesetzt. Die ganze Bezeichnung wird unterstrichen. Folgende Abbildungen mit dem Beispiel der Klasse Angestellte und dem Objekt Widder mögen dies illustrieren.

Oftmals genügt es bei Objektdiagrammen, nur die Bezeichnung von Objekt und Klasse anzugeben. Deshalb ist die in der folgenden Abbildung angegebene Variante die am häufigsten vorkommende Notation.

Abbildung 2.4-5: Grafische Darstellung von Objekten/Instanzen ohne Attribute

In manchen Situationen ist es aber sinnvoll, nicht nur das Objekt zu benennen, sondern auch einige seiner Attribute. Dann werden diese in einem zweiten Bereich angegeben. Die Liste der Attribute muss nicht vollständig sein, sondern kann sich auf die konzentrieren, die für die jeweilige Analyse von Bedeutung sind.

Abbildung 2.4-6: Grafische Darstellung von Objekten/Instanzen - mit Attributen

Genügt in der Analysesituation die Angabe der Objektbezeichnung, kann auch die folgende Darstellung gewählt werden.

Abbildung 2.4-7: Grafische Darstellung von Objekten/Instanzen - nur Objektbezeichnung

2.5 Sichtbarkeit

Stark von der objektorientierten Programmierung inspiriert sind die weiteren Möglichkeiten, Attribute und Methoden zu kennzeichnen und zu gruppieren. Dabei geht es vor allem um die Sichtbarkeit eines Modellelements im jeweiligen Modell bzw. um das Zusammenwirken von Methoden verschiedener Klassen (vgl. Kapitel 7).

  • Mit public werden die Attribute und Methoden bezeichnet, die grundsätzlich auch anderen Klassen zur Verfügung stehen.
  • Mit private werden die Attribute und Methoden bezeichnet, die nur innerhalb der Klasse genutzt werden können.
  • Mit protected werden die Attribute und Methoden bezeichnet, die für die Klassen sichtbar sind, die in einer Generalisierung (vgl. Kapitel 6) übergeordnet sind.

Dazu ein Beispiel aus den UML-Texten. Die Kursivsetzung der Bezeichnung bedeutet, dass es sich um eine abstrakte Klasse (eine die keine eigenen Instanzen hat; näheres hierzu findet sich in Abschnitt 6.7) handelt.

abstrakte Klasse Window

Abbildung 2.5-1:Darstellung von Klassen in der UML - Gruppierung nach Sichtbarkeit
Quelle: [OMG 2003a, S. 89, Figure 38], [OMG 2017, S. 196, Figure 11.17]

Statt der Begriffe public, protected und private können auch die in der folgenden Abbildung angegebenen Zeichen "+", "#" und "-" benutzt werden.

Abbildung 2.5-2:Darstellung von Klassen in der UML - Gruppierung nach Sichtbarkeit
Quelle: [OMG 2003a, S. 88, Figure 37]

2.6 Kapselung

Es gehört zu den Grundmerkmalen objektorientierter Modelle, dass Attribute vor direkten Zugriffen geschützt sind. Normalerweise kann auf ihre Ausprägungen nicht direkt zugegriffen werden, so wie z.B. in Relationalen Datenbanken, sondern nur über die Methoden, die für die Objekte definiert sind.

Geschützte Attribute

Dies wird als Kapselung (encapsulation) bezeichnet. Ganz wird dieses Prinzip allerdings nicht durchgehalten. So erlauben objektorientierte Datenbanksysteme meist den direkten Zugriff auf die Attributsausprägungen, z.B. zum Zwecke der Abfrage.

Kapselung

Geleistet wird durch die Kapselung folgendes: Die Datenstrukturen (die Objekte und Beziehungen repräsentieren) und die Prozeduren zur Manipulation der internen Repräsentation der Datenstruktur werden logisch und softwaretechnisch zusammengefasst. Dieses Konzept geht auf das der abstrakten Datentypen zurück. Jedes Objekt enthält und definiert die Prozeduren (Methoden) und die Schnittstelle (das Interface) durch die es angesprochen und manipuliert werden kann (durch andere Objekte). Die Schnittstelle eines Objekts besteht aus einer Menge von Operationen, die auf das Objekt angewandt werden können. Somit kann der Zustand eines Objekts (the state of an object), d.h. die konkreten Ausprägungen seiner Attribute, nur durch die Methoden verändert werden, die durch die entsprechenden Operationen aufgerufen werden.

Kapselung in objektorientierten Modellen

Damit bleibt die interne Repräsentation der Datenstruktur und der Methoden dem Nutzer verborgen. D.h. die Nutzer sehen nur die Objekte, usw., wie diese intern realisiert werden, bleibt für sie unsichtbar. Kapselung erlaubt somit information hidding.

Information hidding

Durch die Kapselung ist es auch möglich, dass sich z.B. die Methoden einer Klasse ändern können, ohne dass der übrige Bereich der Anwendung tangiert wird (falls die Schnittstelle gleich bleibt).

2.7 Beispiele

In diesem Text werden u.a. Beispiele aus zwei Anwendungsbereichen verwendet: Hochschule und Angestellte. Im Hochschulbeispiel wird vor allem das Geschehen rund um die Vorlesungs- und Prüfungsdurchführung betrachtet. Bezüglich der Angestellten eines Unternehmens werden die Zugehörigkeit zu Abteilungen, die Mitarbeit in Projekten und die Nutzung von Computern betrachtet.

Hier nun - dem Kapitel entsprechend - eine erste Sammlung von Attributen und Methoden und eine erste Klassenbildung.

2.7.1 Hochschule

Betrachten wir beispielhaft eine Hochschule und stellen wir uns vor, der Vorlesungsbetrieb sollte modelliert werden. Dann würden zwei Objektklassen sich geradezu aufdrängen: Studierende und Dozenten.

Als Attribute für Studierende sind unschwer zu erkennen Matrikelnummer (matrikelNr), name, vorname, plz, ort, straße, Zeitpunkt des Beginns (beginnStudium) und des Endes des Studiums (endeStudium), studiengang und fachsemester. Als Operationen: immatrikulieren(), exmatrikulieren(). Als Klassenattribut anzahl() mit der Klassenmethode anzahlStud().

Studierende

Abbildung 2.7-1: Objektklasse Studierende

Für die Dozenten finden sich auf Anhieb die Attribute Personalnummer (persNr), name, vorname und die Operationen Vorlesungs- und Prüfungsdurchführung (haltenVorlesung(), haltenPrüfung()).

Dozenten

Abbildung 2.7-2: Objektklasse Dozenten

2.7.2 Angestellte eines Unternehmens

Berücksichtigen wir aus diesem Anwendungsbereich die Abteilungszugehörigkeit, die Projektmitarbeit (Angestellte arbeiten in Projekten in wechselnder Zusammensetzung mit) und den PC-Einsatz, sind im ersten Schritt die nachfolgend angeführten Attribute zu erheben.

Für die Angestellten Personalnummer (persNr), Name (name), Vorname (vname), Postleitzahl (plz), Ort (ort), Straße (strasse), Einstellungsdatum (datumEinst) und Geburtstag (gebTag). Außerdem sollen die jeweilige Anzahl der Mitarbeiter (anzMitarb) und die Gehaltssumme (summeGehalt) ausgewiesen werden. Letztere sind Klassenattribute.

Angestellte

Bezüglich der Methoden erfassen wir Einstellung, Entlassung, Versetzung, Beförderung und Gehaltszahlung (einstellen(), entlassen(), versetzen(), befoerdern(), zahlenGehalt()).

Die folgende Abbildung zeigt die Klasse. Dort wurden auch die Klassenmethoden Anzahl feststellen (feststellenAnzahl()) und Gehaltssumme berechnen (berechneGehaltssumme()) eingefügt.

Abbildung 2.7-3: Anwendungsbereich Angestellte, Klasse Angestellte

Für die Projekte, die im Unternehmen mit wechselnder personeller Zusammensetzung realisiert werden, werden die Bezeichnung (bez), der Standort (standort), der Einrichtungstag (tagEinr) und die geplante Dauer in Monaten (dauer) erfasst.

Projekte

Abbildung 2.7-4: Anwendungsbereich Angestellte, Klasse Projekte

Für die Personal Computer (PC) die Inventarnummer (invNr), die Bezeichnung (bez) und der Typ (typ).

Personal Computer

Abbildung 2.7-5: Anwendungsbereich Angestellte, Klasse PC

Für die Abteilungen die Abteilungsbezeichnung (abtBez), den Namen des Abteilungsleiters (abtLeiterNa) und den Standort (standort) der Abteilung (Gebäude x im Unternehmensteil y).

Abteilungen

Abbildung 2.7-6: Anwendungsbereich Angestellte, Klasse Abteilungen

2.8 Vertiefung

2.8.1 Klassenbildung und Objektfindung

Eine angedachte Klassenbildung sollte bereits bei der Objektfindung berücksichtigt werden. Realweltphänomene sollten nur dann zu Objekten gemacht werden, wenn aus diesem Schritt mehrere Objekte entstehen, die dann zu einer Objektklasse werden können. D.h., parallel zum Suchen nach den geeigneten Objekten muss bereits reflektiert werden, welche Objekte zusammen in eine Objektklasse gehören.

Klassenbildung bei Objektfindung

Oftmals denkt man auch bereits an Objektklassen, wenn man über Objekte redet, da man den Abstraktionsschritt von den Objekten zur Klasse fast automatisch vollzieht.

Wie findet man nun ganz konkret Objekte? Der sicherste Weg ist der in Abschnitt 2.1 beschriebene, der über die Betrachtung von Attributen und Realweltphänomenen zum Ziel führt.

Objekte finden

Andere Autoren (v.a. die mit einem Datenbankhintergrund) behelfen sich einfach mit einem Hinweis auf die entsprechenden Realweltobjekte, wie z.B. Bertino und Martino:

"In object-oriented systems, each real world entityis represented by an object to which is associated a state and a behavior." [Bertino und Martino 1993, S. 14].

Damit ist das Problem - zumindest was das Finden (bzw. Festlegen) der Objekte angeht - aber nur verlagert, denn Realweltobjekte besitzen auch nicht immer die Eindeutigkeit, die für eine Lösung der Frage notwendig wäre.

[Meier und Wüst 1997, S. 3] definieren Objekte als "Grundbausteine, aus welchen objektorientierte Anwendungssysteme aufgebaut werden" und präzisieren dann:

"Unter einem Objekt versteht man einen wohlunterscheidbaren Gegenstand aus der realen Welt oder einen abstrakten Begriff aus der Vorstellung." [Meier und Wüst 1997, S. 13]

Wohlunterscheid-
barer Gegenstand

Ähnliche Definitionen finden sich in großer Zahl in der Literatur. Sie helfen ein Stück weit, auf dem Hintergrund der heutigen Speichertechnologien führt aber die im vorigen Abschnitt beschriebene Herleitung über die Attributkonstellation schneller zu besseren Ergebnissen.

Methoden werden üblicherweise von Objekten abgeleitet und dann mit diesen verwaltet. Oftmals geben Methoden aber auch Hinweise auf zu identifizierende Objekte. Nehmen wir z.B. die Methode Rechnungsstellung. Sie gibt nicht nur einen eindeutigen Hinweis auf die Objekte Rechnungen, sondern auch gleich auf die Adressaten der Rechnungen (Kunden) und die Waren oder Dienstleistungen, um die es geht.

Objektfindung durch Methoden

Nicht vergessen werden soll an dieser Stelle, dass Methoden auch Hinweise auf zu erfassende Attribute geben. Eine Methode Gehaltszahlung erzwingt z.B. die Erfassung von Attributen wie Familienstand, Steuerklasse, usw.

Durch Methoden zu Attributen

Im Bereich der objektorientierten Datenmodellierung gehen einige Autoren so weit, eine 1:1-Beziehung zwischen den Objekten der Datenbank und denen des Anwendungsbereichs (hier auch oft Weltausschnitt genannt) zu fordern.

1:1-Abbildung

Diese direkte Übereinstimmung zwischen Realweltobjekten und Datenbankobjekten, bzw. Elementen des Datenmodells, wird im Datenbankbereich geradezu als zentral angesehen. Ein Grund dafür ist der Wunsch, die Segmentierung der Information für ein Objekt in konventionellen Datenbanken zu überwinden. In relationalen Datenbanken werden zum Beispiel die Attribute zur Beschreibung eines Objekts in der Regel über eine größere Zahl von Relationen verteilt. Da üblicherweise eine Relation auch einer Datei entspricht, führt dies zu einer Segmentierung auf logischer und auf physischer Ebene, die viele Auswertungen, Abfragen, usw. sehr kompliziert macht.

Keine Zerlegung

2.8.2 Identität und Gleichheit

In der objektorientierten Theorie wird ein Merkmal von Objekten und Objektklassen gefordert, das insbesondere für die objektorientierte Datenmodellierung von Bedeutung ist: die eindeutige, persistente (beständige) und von der Beschreibung durch Attribute unabhängige Identifizierbarkeit der Objekte.

Dies geschieht durch einen Objektidentifizierer (OID) (object identifier), der vom System vergeben wird. Er ist unabhängig von den Attributen der Objektklasse. Insbesondere darf dieser OID nicht mit einem inhaltlich basierten Schlüssel (z.B. Projektbezeichnung) verwechselt werden, wie es ihn z.B. bei Relationen in der Datenbanktheorie gibt. Vom Aufbau her ähnelt er den Schlüsseln, die als laufende Nummer angelegt und vom System verwaltet werden.

Objektidentifizierer

Mit diesem Konzept kann dann zwischen Identität und Gleichheit von Objekten unterschieden werden. Mehrere Objekte können absolut gleich sein, gemessen an den Ausprägungen ihrer Attribute, und sind doch nicht identisch. Ein Beispiel wären die Produkte einer Serienfertigung, z.B. Fernsehapparate, die - gemessen an den beschreibenden Attributen - absolut gleich sind.

Gleich und doch nicht identisch

Eine solche Objektidentifikation wird auch als Surrogat (surrogate) bezeichnet. Der Begriff soll andeuten, dass die identifizierende Information Stellvertreter für das Realweltobjekt ist. Folgende Eigenschaften werden für Surrogate definiert:

Surrogat

  • Unveränderbarkeit: Ein einmal vergebener Wert bleibt unverändert, er wird nicht neu vergeben, auch wenn das Objekt gelöscht wird.
  • Ortsunabhängigkeit: Sie werden unabhängig vom geografischen Speicherungsort und von der Speicherungsform vergeben.

2.8.3 Komplexe Objekte

Objekte werden auch im objektorientierten Ansatz in erster Linie durch Attribute beschrieben. Attribute in der ganz üblichen Auffassung wie oben beschrieben. Zusätzlich können hier allerdings die Ausprägungen eines Attributs nicht nur die üblichen einfachen Attributsausprägungen sein, sondern ganze Objekte, Mengen von Attributsausprägungen oder Mengen von Objekten. In diesem Kontext werden dann einfache Attributsausprägungen als primitive objects bezeichnet.

Nicht-primitive Objekte

Liegen nun aber als "Attributsausprägungen" nicht-primitive Objekte vor, spricht man von komplexen oder zusammengesetzten Objekten.

Damit können komplexe Objekte als Objekte beschrieben werden, "deren Attribute selbst wiederum Objekte sein können" ([Balzert 1999, S. 542], [Meier und Wüst 1997, S. 6]).

2.8.4 Eine ganz besondere Klasse - Classifier

Die UML-Autoren haben in ihrem Theoriegebäude eine Vielzahl von Elementen (Begriffe, Konzepte, Konstrukte), die sie im Rahmen ihrer Metamodellierung auch in Beziehung setzen. Vor allem in eine Beziehung, die hier mit "ist abgeleitet von" beschrieben werden soll und die wir weiter unten als Generalisierung/Spezialisierung näher kennenlernen werden (Kapitel 6).

B ist abgeleitet von A,
C von B,
D von C, ...

Durch eine solche Beziehung entsteht eine Hierarchie, in der die Elemente quasi untereinander angeordnet sind und die ein Element "ganz oben" benötigt (oftmals hier Wurzel (root) genannt, in diesem Bild wäre die Spitze aber dann unten). Dieses ganz oben angesiedelte Element ist im Theoriegebäude der UML der sog. Classifier.

Von ihm sind also die meisten anderen Theorieelemente abgeleitet, was natürlich zu Folge hat, dass er sehr abstrakt definiert sein muss.

Er ist eine sog. abstrakte Metaklassse . "Meta" bedeutet hier "übergeordnet" (konzeptionell über anderen Klassen angesiedelt), abstrakte Klassen werden unten (vgl. Abschnitt 6.7) ausführlich vorgestellt, hier soll folgendes genügen:

Abstrakte Klassen haben keine Objekte (Instanzen). In der Sprache der UML: Sie können nicht instanziieren [Rumbaugh, Jacobson und Booch 2005, S. 129].

Die UML-Autoren definieren nun einen Classifier als eine Sammlung von Instanzen, die sich ähnlich sind:

"A collection of instances that have something in common. A classifier can have features that characterize its instances. Classifiers include interfaces, classes, datatypes, and components." [OMG 2003a, S. 6]

Definition

Damit gewinnt die Definition Konturen. Systemsicht Interfaces, Klassen, Datentypen und Komponenten sind Informationsträger und sie werden klassifiziert, nach bestimmten ihrer Eigenschaften. Das Ergebnis dieser Klassifikation sind die Classifier.

Klassifizierte
Informationsträger

Im Deutschen steht dafür eigentlich der Begriff Kategorie zur Verfügung. Hier soll trotzdem der englische Begriff benutzt werden (Klassifizierer würde doch recht seltsam klingen), auch um den Zusammenhang mit der objektorientierten Theorie gleich herzustellen.

In [Booch, Rumbaugh und Jacobson 2005] wird für Classifier die Übersetzung Dingverwendet. Dies ist ein mutiger Vorschlag, da er auch die Allgemeinheit des Begriffs (und Konzepts) zum Ausdruck bringt. Allerdings wird er hier nicht nachvollzogen, da er sprachlich zu argen Wortungetümen führen würde.

Ding

Dass sich die UML-Autoren mit der Definition hier nicht leicht tun, zeigt auch folgendes Zitat:

"A classifier models a discrete concept that describes things (objects) having identity, state, behavior, relationships, and an optional internal structure." [Rumbaugh, Jacobson und Booch 2005, S. 48; Hervorhebung durch den Verfasser].

Diese Schwierigkeiten bei der Definition sind nicht überraschend. Der Begriff Classifier ist ein Grundbegriff mit philosophischen Aspekten und bedarf daher eines hohen Abstraktionsgrades.

Grafische Darstellung

Die grafische Standardnotation für einen Classifier ist eine Rechteck mit durchgezogenen Linien, in dem die Bezeichnung des Classifier angegeben ist. Der Typ des Classifier kann in Guillemets über der Bezeichnung angegeben werden. Optional können Bereiche durch horizontale Linien abgetrennt werden. In diesen Bereichen werden Merkmale oder andere Elemente des Classifier eingetragen.

Rechteck mit Bezeichnung und Bereichen

Folgende weiteren Festlegungen gelten:

  • Der genaue Typ des Classifier kann in Guillemets über der Bezeichnung angegeben werden.
  • Die Spezialisierungen von Classifiern haben ihre eigene grafische Notation.
  • Liegt ein abstrakter Classifier vor, wird die Bezeichnung kursiv gesetzt.

Ist ein Classifier eine Klasse, ergibt sich die Darstellung wie in der folgenden Abbildung.

Classifier
Klasse

Abbildung 2.8-1: Grafische Darstellung eines Classifiers am Beispiel einer Klasse.

Hier noch ein Beispiel für die Darstellung von Unterbereichen in Classifiern, wieder am Beispiel einer Klassendarstellung:

Unterbereiche in Classifiern

Abbildung 2.8-2: Grafische Darstellung eines Classifiers mit Unterbereichen am Beispiel einer Klasse.

Da Klassen die am häufigsten vorkommenden Classifier sind, kann bei ihnen die Bezeichnung des Typs ("class") weggelassen werden. Dies geschieht auch in diesem Text.

 

Verwendete Fachbegriffe in diesem Kapitel

abstrakte Klassse

abstract class

abstrakte Metaklassse

abstract meta class

Attribut

attribute

Informationsträger

entity

Informationsträger (auch: Ding, bei [Booch, Rumbaugh und Jacobson 2005])

classifier

Instantiierung

instantiation

Instanz

instance

Kapselung

encapsulation

Klassenattribut

class attribute

klassenbezogene Methoden

class methods

Klassifikation

classification

Konzeptionelle Modellierung

conceptual modeling

Methoden

methods

Methoden, klassenbezogene

class methods

Operation

operation

Links der in diesem Text verwendete Begriff. Rechts der in der objektorientierten Theorie bzw. in der UML verwendete Begriff. Begriffe ohne Übersetzung wurden auch im Text in englischer Sprache verwendet.

 

3 Assoziationen

3.1 Definition

Im vorigen Kapitel wurden die Grundkonzepte Objekt und mm eingeführt. In diesem Abschnitt geht es nun um die Techniken, mit denen diese Objekte bzw. Objektklassen miteinander in Beziehung gesetzt werden können, denn natürlich stehen in objektorientierten Modellen die einzelnen Objektklassen nicht unverbunden nebeneinander. Dabei geht es vor allem um objektorientierte Modellierung der zu verarbeitenden Daten.

Objekte in eine inhaltliche Beziehung setzen

Diese Beziehungen sind inhaltliche, sie kommen aus der Semantik des Anwendungsbereichs und werden ausgewählt nach den Anforderungen der Modellierung.

Nehmen wir als Beispiel wieder den Anwendungsbereich Hochschule mit den Klassen Dozenten, Vorlesungen, Studierende, Räume und Prüfungen. Die Anwendung soll den Lehrbetrieb erfassen. Dann wären dies Beziehungen wie:

  • Dozenten halten Vorlesungen
  • Studierende besuchen Vorlesungen
  • Vorlesungen finden in Räumen statt
  • Studierende besuchen Prüfungen

Es gibt natürlich mehr solche Beziehungen in einem Anwendungsbereich. Ausgewählt werden aber nur die, die für die Anwendung (z.B. bestimmte Geschäftsprozesse) von Bedeutung sind.

Assoziationen werden meist auf Klassenebene betrachtet, stellen aber ganz konkret Instanzen der beteiligten Klassen miteinander in Beziehung.

Instanzen

Grundsätzlich gibt es folgende Möglichkeiten der Bildung von Assoziationen:

  • Eine Assoziation einer Klasse mit sich selbst (einstellig)
  • Eine Assoziation zwischen zwei Klassen (zweistellig, binär)
  • Eine Assoziation zwischen mehr als zwei Klassen (mehrstellig, z.B. ternär)

Beispiele für einstellige Assoziationen sind Stücklisten ("ist enthalten in") oder ein Vorgesetztenverhältnis ("ist vorgesetzt").

Zweistellige Assoziationen sind sehr zahlreich. Im Anwendungsbereich Hochschule z.B. Prüfungsbesuch (beteiligte Klassen wären Studierende und Prüfungen) oder Vorlesungsbesuch (Studierende und Vorlesungen). Im Anwendungsbereich Angestellte z.B. Abteilungszugehörigkeit (beteiligte Klassen: Angestellte und Abteilungen).

Zweistellig

Mehrstellige Assoziationen kommen nicht sehr oft vor. Hier zwei Beispiele, mit denen die oben angeführten zweistelligen Assoziationen zum Anwendungsbereich Hochschule inhaltlich ausgebaut werden.

Mehr als zwei Klassen

Im Anwendungsbereich Hochschule ist eine dreistellige (ternäre) Assoziation denkbar, die den Besuch von Lehrveranstaltungen beschreibt. Sie verbindet die Klassen Studierende, Dozenten und Lehrveranstaltungen und kann so interpretiert werden: Ein Studierender besucht eine Vorlesung bei einem Dozenten. Vgl. das Hochschulbeispiel unten.

Eine weitere dreistellige Assoziation, die im Hochschulbeispiel unten betrachtet wird, ist die zwischen Studierende, Lehrveranstaltungen und Prüfungen. Sie kann so interpretiert werden: Ein Studierender besucht eine Prüfung, die sich auf eine Lehrveranstaltung bezieht.

Beide dreistelligen Assoziationen unterscheiden sich in ihrer Aussagekraft von den gleichnamigen zweistelligen. Dazu unten mehr.

3.2 Grafische Darstellung

Eine zweistellige Assoziation wird normalerweise einfach durch eine durchgezogene Linie dargestellt, die die beiden Klassen verbindet. An der Linie sind die Bezeichnungen der Assoziation angegeben. Es sind zwei, eine für jede Richtung.

Linie mit zwei Bezeichnungen ohne ...

Abbildung 3.2-1: Grafische Darstellung einer zweistelligen Assoziation - ohne Raute

Die gefüllten Dreiecke bei den Assoziationsbezeichnungen zeigen die Leserichtung (vgl. die Beispiele unten).

Jede Assoziation kann auch mit einer Raute gezeichnet werden. Dann verbindet eine durchgezogene Linie jede beteiligte Klasse mit der Raute. Die nächste Abbildung zeigt ein abstraktes Beispiel.

... oder mit Raute

Abbildung 3.2-2: Grafische Darstellung einer zweistelligen Assoziation - mit Raute

Liegen mehr als zwei Klassen vor, ist die Assoziation also mehr als zweistellig, kann sie nur mit einer Raute gezeichnet werden.

Eine einstellige Assoziation wird normalerweise einfach durch eine durchgezogene Linie dargestellt, die die Klasse mit sich selbst verbindet. Auch hier werden zwei Assoziationsbezeichnungen angefügt.

Einstellig

Abbildung 3.2-3: Grafische Darstellung einer einstelligen Assoziation

Die Darstellung mit einer Raute ist ebenfalls möglich.

Mit Raute

Abbildung 3.2-4: Grafische Darstellung einer einstelligen Assoziation mit Raute

Die folgende Abbildung zeigt die grafische Darstellung einer dreistelligen Assoziation. Hier wird die Bezeichnung der Assoziation an der Raute angebracht.

Dreistellig

Abbildung 3.2-5: Grafische Darstellung einer dreistelligen Assoziation

Bei jeder Klasse sind im konkreten Fall noch Wertigkeiten anzufügen. Vgl. hierzu die Ausführungen unten.

Außerdem kann durch einen Schrägstrich vor der Assoziationsbezeichnung die Assoziation als "abgeleitet" gekennzeichnet werden (vgl. unten). Wird keine Assoziationsbezeichnung angegeben, genügt in solch einem Fall der Schrägstrich alleine.

Abgeleitet

Generalisierungen (vgl. unten) zwischen Assoziationen können durch einen Generalisierungspfeil, der zwischen den betreffenden Assoziationssymbolen eingefügt wird, ausgedrückt werden.

Generalisierungen
zwischen
Assoziationen

Das Assoziationsende kann beschriftet werden. Dann wird die Bezeichnung des Assoziationsendes in der Nähe des Linienendes platziert. Als Assoziationsende bezeichnen die UML-Autoren die Verbindung zwischen der Linie, die die Assoziation darstellt und dem grafischen Element für die Klasse.

Assoziationsende

Grundsätzlich sind, so die UML-Autoren, Assoziationen nicht nur zwischen Klassen, sondern zwischen Classifiern aller Art möglich.

Nicht nur Klassen

3.3 Hintergrund

Das Konzept der Assoziation, wie es in der objektorientierten Theorie ausformuliert wird, entspricht dem "in Beziehung setzen" von Modelleinheiten (Relationen, Entitätstypen) in der klassischen Datenbanktheorie. Werden dort, z.B. in der ER-Modellierung, die Entitätstypen Dozenten und Vorlesung in die Beziehung "Dozent hält Vorlesung" gesetzt (durch einen Beziehungstyp), entspricht dies einer Assoziation. In relationalen Datenmodellen wird eine solche Beziehung sogar gleich datentechnisch durch Schlüssel / Fremdschlüssel-Beziehungen "physisch" umgesetzt.

Vorgänger
Datenbanktheorie

In der objektorientierten Systemanalyse ist allerdings die Sichtweise meist eine andere. Hier wird oft betont, dass die Assoziationen notwendig sind, damit Objekte miteinander kommunizieren können (vgl. beispielhaft [Oestereich 1998, S. 268]). Damit wird die Tatsache angesprochen, dass in einem objektorientierten System die einzelnen Klassen und ihre Objekte bei der Erledigung der Aufgaben zusammenwirken (vgl. Kapitel 7). Dies geschieht aber entlang der oben eingeführten semantisch wichtigen Beziehungen zwischen den Klassen. Insofern ergibt sich kein Widerspruch.

Assoziationen als
Kommunikations-
pfade

Insbesondere in Abgrenzung zum relationalen Modell muss hier noch darauf hingewiesen werden, dass die konkrete Realisierung dieser Beziehungen zwischen Objekten modelliert wird, indem die entsprechenden Objekte mithilfe ihrer Objektidentifizierer verknüpft werden und nicht mithilfe attributbasierter Schlüssel.

Verknüpfung durch Objektidentifizierer

3.4 Wertigkeiten

Oben wurden schon mehrfach Wertigkeiten von Assoziationen angegeben. Hier nun die Präzisierung.

Die Wertigkeiten [Anmerkung] von Assoziationen geben an, wieviele Objekte jeder beteiligten Klasse an der Assoziation teil haben. Es gibt also für jede an der Assoziation beteiligten Klasse eine solche Wertigkeit.

Wertigkeiten (Multiplizitäten, Kardinalitäten)

Folgende Darstellung haben die UML-Autoren festgelegt:

  • 1 (einfach). Genau ein Objekt der jeweiligen Klasse geht in die Beziehung ein)
  • 0..1 (konditionell einfach). Kein oder ein Objekt der jeweiligen Klasse geht in die Beziehung ein.
  • * (konditionell mehrfach). Null, eines oder viele Objekte der jeweiligen Klasse geht in die Beziehung ein).

Weitere Konkretisierungen bezüglich der maximalen und minimalen Anzahl von Objekten können erfolgen, so dass z.B. folgende Angaben möglich sind:

  • fünf oder mehr: 5..*
  • null bis drei: 0..3
  • genau fünf: 5
  • drei, vier oder acht: 3, 4, 8
  • alle natürlichen Zahlen außer elf: 1..10, 12..*

Balzert führt zusätzlich die Begriffe Kann- und Muss-Assoziationen ein. Kann-Assoziationen haben als Untergrenze die Kardinalität 0, Muss-Assoziationendie Kardinalität 1 oder größer [Balzert 1999a, S. 41f].

Kann- und
Muss-Assoziationen

In den Abbildungen werden die Wertigkeiten an den Assoziationsenden vermerkt. Vgl. die Beispiele unten und die Hinweise zur Anordnung der Wertigkeiten in den Abbildungen.

3.5 Beispiele

Hier nun Beispiele von Assoziationen mit unterschiedlichen Wertigkeiten.

Zweistellige Assoziationen

Die folgende Abbildung erfasst eine mögliche Variante des Verhältnisses von Angestellten und PC. Hier gilt:

Angestellte - PC

  • Ein Angestellter benutzt genau einen PC.
  • Ein PC ist mindestens einem Angestellten zugeordnet.

Die kursiv gesetzten Texte in der Abbildung machen die Positionierung der Wertigkeiten deutlich: Wieviele Objekte einer Klasse an der Assoziation teilhaben wird jeweils am entgegengesetzten Ende der Assoziation vermerkt.

Abbildung 3.5-1: Zweistellige Assoziation mit Wertigkeiten und benannten Beziehungen

Die Beziehungen können so wie in der Abbildung angegeben gelesen werden.

Das zweite Beispiel zeigt eine Assoziation zwischen Angestellte und Abteilungen. Es gelten folgende Wertigkeiten:

Angestellte - Abteilungen

  • Ein Angestellter ist genau einer Abteilung zugeordnet.
  • Eine Abteilung hat üblicherweise mehrere zugehörige Angestellte (genauer: keinen, einen oder mehrere).

Abbildung 3.5-2: Zweistellige Assoziation mit Wertigkeiten und benannten Beziehungen

Von zwei- zu dreistelligen Assoziationen

Mit den dreistelligen Assoziationen soll an den Beispielen Prüfungsbesuch und Vorlesungsbesuch auch der Unterschied zwischen einer zweistelligen und dreistelligen Assoziation erläutert werden.

Prüfungsbesuch zweistellig

Eine zweistellige Assoziation Prüfungsbesuch muss als Grundlage folgende Klassen haben:

  • Klasse Studierende
  • Klasse Prüfungen. In dieser Klasse muss als Attribut festgehalten sein, welche Lehrveranstaltung durch jede Prüfung geprüft wird.

In der folgenden Abbildung ist deshalb in Prüfungen das Attribut BezugLV eingefügt, das angibt, auf welche Lehrveranstaltung sich die Prüfung bezieht. Die Wertigkeiten bedeuten hier, dass ein Studierender keine, eine oder mehrere Prüfungen besucht und dass eine Prüfung von keinem, einem oder mehreren Studierenden aufgesucht werden kann.

Abbildung 3.5-3: Zweistellige Assoziation - Beispiel Prüfungsbesuch zweistellig

Sind dagegen die konkreten Lehrveranstaltungen oder die Prüfungen zu einer eigenständigen Existenz gekommen, ergibt sich eine andere Situation. Dies soll hier der Fall sein, weil die Prüfungen "an sich" erfasst werden, ohne Bezug zu einer konkreten Lehrveranstaltung. Damit sind in Prüfungstyp nur Einträge wie in der folgenden Tabelle möglich.

Prüfungsbesuch dreistellig

Prüfungstypen

pruefNr

bezPruef

laenge

1

Klausur

60

2

Klausur

90

3

Mündliche Prüfung

30 Minuten

4

Laborarbeit

1 Semester

5

Praktische Arbeit

1 Semester

5

Diplomarbeit

4 Monate

6

Bachelorarbeit

3 Monate

Mögliche Prüfungstypen im Anwendungsbereich Hochschule

Würde man die Prüfungstypen direkt bei den Lehrveranstaltungen mit verwalten, ergäbe sich eine große Redundanz, da die Daten der Prüfung dann bei jeder einschlägigen Lehrveranstaltung erfasst werden müssten.

Redundanz?

Die Wertigkeiten bei den einzelnen Klassen beziehen sich hier im dreistelligen Fall nicht auf "gegenüberliegende" Klassen wie bei den zweistelligen Assoziationen (geht ja nicht), sondern auf die Assoziation als solche. Hier also:

  • In einem Prüfungsgeschehen nimmt mindestens ein Studierender teil.
  • In einem Prüfungsgeschehen liegt ein bestimmter Prüfungstyp vor.
  • In einem Prüfungsgeschehen geht es um genau eine Lehrveranstaltung.

Abbildung 3.5-4: Dreistellige Assoziation - Beispiel Prüfungsbesuch

Nun das Beispiel zum Vorlesungsbesuch, zuerst zweistellig. Die Wertigkeit für Studierende bedeutet: Ein Studierender kann keine oder beliebig viele Lehrveranstaltungen besuchen. Die für Lehrveranstaltungen: Eine Lehrveranstaltung hat mindestens 5 Studierende, die sie besuchen, sonst findet sie nicht statt.

Vorlesungsbesuch zweistellig

Abbildung 3.5-5: Zweistellige Assoziation - Beispiel Veranstaltungsbesuch

Obige Lösung geht davon aus, dass jede Lehrveranstaltung einmalig ist, dass dieselbe Lehrveranstaltung (zum Beispiel BWL 1) wirklich nur einmal und nur von einem Dozenten angeboten wird. Wird Sie, z.B. wegen hoher Studierendenzahlen, mehrfach angeboten (von einem Dozenten oder von mehreren), ist diese Tatsache nicht im Modell ausdrückbar.

Bei einer dreistelligen Assoziation dagegen ist dies kein Problem mehr. Der Veranstaltungsbesuch wird dann durch die kombinierte Information aus Studierenden / Lehrveranstaltung / Dozenten erfasst. Damit wäre es möglich, dass die drei Dozenten Maier, Müller und Bauch alle je eine Lehrveranstaltung BWL 1 geben. Ein Studierender besucht dann eine Lehrveranstaltung bei einem Dozenten. Vgl. dazu auch das Hochschulbeispiel unten.

Vorlesungsbesuch dreistellig.

Die Wertigkeiten bedeuten:

  • Bei Studierende: Mindestens 5 Studierende nehmen teil.
  • Bei Lehrveranstaltungen: Es geht jeweils um genau eine Lehrveranstaltung.
  • Bei Dozenten: Jeweils ein Dozent hält die Lehrveranstaltung.

Würde man auch die Variante berücksichtigen wollen, dass u.U. mehrere Dozenten gemeinsam eine bestimmte LV durchführen, dann müsste die Wertigkeit bei Dozenten verändert werden.

Abbildung 3.5-6: Dreistellige Assoziation - Beispiel Veranstaltungsrealisierung

Einstellige (rekursive) Assoziationen

Bei den einstelligen (rekursiven) Assoziationen geht es um Beziehungen innerhalb einer einzigen Klasse.

etrachten wir als Beispiel eine Objektklasse Angestellte mit den üblichen Hierarchiestufen (z.B. Sachbearbeiter, Abteilungsleiter, Hauptabteilungsleiter, usw.). Hier stehen tatsächlich die Angestellten untereinander in einer Beziehung. Z.B. alle Sachbearbeiter einer Abteilung mit dem Abteilungsleiter und umgekehrt. Die Wertigkeiten und Rollenangaben in der folgenden Abbildung bedeuten:

  • Jeder Sachbearbeiter hat genau einen Vorgesetzten, den Abteilungsleiter
  • Jeder Abteilungsleiter hat mindestens einen Untergebenen.

Abbildung 3.5-7: Einstellige (rekursive) Assoziation zu Angestellten

Das bekannte Beispiel einer Stückliste kann auch hier zur weiteren Veranschaulichung einer rekursiven Definition einer Objektklasse benutzt werden. Geht es um die zwei Beziehungen "Teil von" und "Obermenge von", kann eine Stückliste so wie in der nächsten Abbildung grafisch dargestellt und entsprechend modelliert werden.

Beispiel Stückliste

Bis auf ein Teil (das "oberste") ist jedes "Teil von" genau einem anderen, woraus sich die Wertigkeit "0..1" (konditionell einfach) für diese Richtung ergibt. Sollte es Teile geben, die in mehreren enthalten sind, müsste die Wertigkeit verändert werden.

Umgekehrt kann jedes Teil "Obermenge von" vielen anderen Teilen sein, muss aber nicht (die "untersten"), woraus sich die konditionell mehrfache Assoziation in diese Richtung ergibt (vgl. auch [Meier und Wüst 1997, S. 25f]).

Abbildung 3.5-8: Stückliste als einstellige (reflexive) Assoziation

Der Sachverhalt Stückliste kann - mit mehr Aussagekraft - auch als Aggregation modelliert werden. Vgl. Kapitel 5, insbesondere Abbildung 5.2-2.

3.6 Rollen

Die Objekte einer Klasse können an mehreren Assoziationen teilhaben. So könnten z.B. die Angestellten zum einen als PC-Nutzer fungieren (wie im obigen Beispiel), zum anderen aber auch als Projektmitarbeiter. Diese unterschiedlichen Funktionen werden hier als Rollen bezeichnet, als Rollen der Objekte in der jeweiligen Assoziation. Diese können in der grafischen Darstellung angegeben werden. Sie werden an die Assoziationslinie auf der Seite hinzugefügt, auf der sich die Objektklasse befindet, deren Rolle in der jeweiligen Beziehung geklärt werden soll. Die folgenden Abbildungen zeigen zwei Beispiele.

Nicht nur eine
Assoziation

Beispiel Angestellte

In der ersten Abbildung wurde ein Beispiel von oben wieder aufgenommen, jetzt aber mit einer zusätzlichen Klasse Projekte und einer umfangreicheren Klassendarstellung.

Angestellte mit Projekte

Das Beispiel enthält zwei Assoziationen. Die zwischen Angestellte und PC betrifft die PC-Nutzung. Die Angestellten des Unternehmens sind in Bezug auf diese Assoziation PC-Nutzer, die PCs haben hier die Rolle einer DV-Ausstattung.

Assoziationen
PC-Nutzung und
DV-Ausstattung

Die zweite Assoziation verknüpft Angestellte und Projekte. Hier haben die Angestellten die Rolle Projektmitarbeiter. Die Wertigkeiten bei der neuen Assoziation bedeuten:

  • Ein Angestellter arbeitet in keinem, einem oder mehreren Projekten mit.
  • Ein Projekt hat mindestens einen Angestellten als Projektmitarbeiter.

Abbildung 3.6-1: Assoziationen mit Rollen im Anwendungsbereich Angestellte

Beispiel Hochschule

Die nächste Abbildung stellt die Dozenten einer Hochschule und die Lehrveranstaltungen (Vorlesungen, Übungen, Praktika) in Beziehung. Die Dozenten haben hier die Rolle als Lehrende, die Lehrveranstaltungen als Studienbetrieb. Die Wertigkeiten bedeuten:

Dozenten und
ihre Lehre

  • Ein Dozent hält keine, eine oder mehrere Lehrveranstaltungen.
  • Eine Lehrveranstaltung wird entweder von einem oder von zwei Dozenten gehalten.

Abbildung 3.6-2: Rollen in Assoziationen

3.7 N-stellige Assoziationen vertieft

Oben wurde die Grundform einer dreistelligen Beziehung schon vorgestellt. Allgemein spricht man bei Assoziationen mit mehr als zwei beteiligten Klassen von n-stelligen Assoziationen. Die Wertigkeit von n-stelligen Assoziationenmit n größer als 2 ist wie folgt definiert:

Mehr als zwei!

Die Wertigkeit an einem Assoziationsende stellt die potentielle Anzahl von Werten dar, wenn die Werte an den n-1 anderen Enden auf bestimmte Werte fixiert sind.

Damit ist folgendes gemeint: Liegen insgesamt n Enden vor, wird eine beliebige Auswahl von n-1 Enden genommen, denen ja jeweils Instanzen zugeordnet sind. Dann wird die Menge der Verknüpfungen dieser n-1 Assoziationen eine ganz bestimmte Menge von Instanzen am anderen Ende identifizieren (vgl. die Beispiele unten). Spielt man alle Wertigkeiten der n-1 Klassen durch, erhält man den Rahmen für die Wertigkeit der n-ten Klasse.

Beispiel Hochschule

Das erste Beispiel beschreibt wiederum den Lehrbetrieb an Hochschulen, jetzt am Beispiel einer vierstelligen Assoziation: Dozenten halten Lehrveranstaltungen für Studiengänge in bestimmten Räumen. Grundlage dieses Beispiels ist, dass alle vier Klassen existieren, dass also alle vier Realweltphänomene als Klassen modelliert wurden.

Lehrbetrieb durch vierstellige Assoziation

Zu beachten ist, dass es nicht um Lehrveranstaltungstermine geht, sondern um die Lehrveranstaltung als solche, bzw. als Gegenstand der Studienordnung.

Die Wertigkeiten bei den Klassen bedeuten:

  • Ein Dozent oder maximal zwei führen die Lehrveranstaltung durch.
  • Es geht jeweils um eine Lehrveranstaltung.
  • Üblicherweise findet eine Lehrveranstaltung in einem einzelnen Studiengang statt. Es können aber auch zwei sein, wenn z.B. AI (Angewandte Informatik) und WI (Wirtschaftsinformatik) gemeinsam Mathematik 1 hören, usw.
  • Eine konkrete Lehrveranstaltung findet in genau einem Raum statt.

Nehmen wir obigen Gedankengang - Fixierung von n-1 Enden, Betrachtung des n-ten Assoziationsendes - auf, ergibt sich folgendes:

Fixieren und betrachten

  • Fixieren wir Dozenten, Räume und Studiengänge auf den jeweils untersten Wert. Dann gibt es für einen Dozenten, einen Raum und einen Studiengang genau eine Vorlesung. Entsprechendes gilt auch für die jeweils obersten Werte. In diesem Fall gestalten zwei Dozenten in einem Raum für zwei Studiengänge eine Vorlesung.
  • Fixieren wir nun Dozenten, Lehrveranstaltungen und Studiengänge mit den minimalen Werten. Dann gestaltet ein Dozent eine Lehrveranstaltung für einen Studiengang in genau einem Raum.
  • Zuletzt noch eine Fixierung von Lehrveranstaltungen (auf 1), Studiengänge (auf 2) und Räume (auf 1). In diesem Fall wird eine Vorlesung in einem Raum für 2 Studiengänge von einem oder auch mehreren Dozenten getätigt.

Abbildung 3.7-1: N-stellige (vierstellige) Assoziation und ihre Wertigkeiten

Das zweite Beispiel spiegelt Trainingsdurchführung wider. Es wird angenommen, dass Trainer, Trainingsorte und Mannschaften eigenständige Klassen darstellen. Sie haben also eigene Attribute und Methoden. Die ternäre Assoziation beschreibt die Trainingsdurchführung. Die Wertigkeiten ergeben sich dann wie folgt: Eine Trainingsdurchführung (zu einem Zeitpunkt, zur "Zeitproblematik" vgl. unten) findet statt ...

Beispiel Trainings-
geschehen

  • ... mit einem Trainer oder mit zweien
  • ... an einem Trainingsort
  • ... mit einer Mannschaft oder mit zweien

Abbildung 3.7-2: Dreistellige Assoziation Trainingsdurchführung

3.8 Klassendiagramme - Definition und Beispiele

Stellt man für ein objektorientiertes Modell die Klassen und ihre Assoziationen zusammen, entsteht ein Klassendiagramm. Das ist dann aber nur die Grundversion, die durch viele weitere Theorieelemente ausgebaut werden kann. Z.B. durch grafische Elemente für die in den nächsten Kapiteln einzuführende Aggregation und Komposition Kapitel 5) sowie Generalisierung / Spezialisierung (Kapitel 6). Insbesondere aber auch durch die Verhaltensaspekte, die durch Methodenaufrufe modelliert werden können (vgl. [Staud 2019, ab Kapitel 8]).

Klassen + Assoziationen

Die Klassendiagramme sind im Rahmen der objektorientierten Modellierung die wichtigsten Diagramme (So auch [Rumbaugh, Jacobson und Booch 2005, S. 217]).

Die folgenden zwei Beispiele zu den Anwendungsbereichen Hochschule und Angestellte geben einen Eindruck von der Grundversion. Die Beispiele werden in den nächsten Kapiteln ausgebaut.

Ziel der Anwendung beim Hochschulbeispiel ist die Verwaltung des Vorlesungsbetriebs und der Studierendenakten (bzgl. Vorlesungs- und Prüfungsbesuch) sowie des Betreuungsverhältnisses zwischen Dozenten und Studierenden (bzgl. Diplomarbeiten, Bachelerarbeiten, Projektarbeiten, usw.).

Beispiel Hochschule

Folgende Klassen wurden gefunden:

  • Dozenten
  • Studierende
  • Lehrveranstaltungen
  • Prüfungen

Die ersten drei dürften unstrittig sein. Was die Prüfungen angeht, wurde hier die oben eingeführte Lösung gewählt: Die Prüfungen werden "an sich" festgehalten, d.h. ohne Bezug zu konkreten Lehrveranstaltungen.

Von den Assoziationen ist wohl nur das Prüfungsgeschehen erklärungsbedürftig. Diese dreistellige Assoziation erfasst den Besuch von Prüfungen, die sich ja immer auf bestimmte Lehrveranstaltungen beziehen, durch Studierende. Die Wertigkeiten bedeuten:

Die Assoziationen

  • 1..* bei Studierende (Rolle Prüfungsteilnehmer): An einem Prüfungsgeschehen nimmt mindestens ein Studierender teil.
  • 1 bei Lehrveranstaltungen (Rolle Prüfungsgegenstand): Ein Prüfungsgeschehen bezieht sich auf eine Lehrveranstaltung.
  • 1 bei Prüfungen (Rolle Prüfung): Ein Prüfungsgeschehen erfolgt auf eine bestimmte Prüfungsart (Klausur, mündliche Prüfung, usw.).

Dass dieselbe Lehrveranstaltung u.U. am Ende eines jeden Semesters geprüft wird und damit entlang der Zeitachse mehrfach vorkommt, ist hier noch nicht berücksichtigt, kommt unten aber dazu.

Wer bei diesem Klassendiagramm "Unbehagen" verspürt und sich z.B. fragt, wo denn die Prüfungsergebnisse abgelegt werden, spürt richtig. Vgl. hierzu das nächste Kapitel.

Unbehagen?

Abbildung 3.8-1: Klassendiagramm zum Anwendungsbereich Hochschule - Prüfungsgeschehen dreistellig.

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

- Eine dreistellige Assoziation

- Mehrere zweistellige Assoziationen

- Objekte mit verschiedenen Rollen

Außerdem zahlreiche beschriftete Assoziationen.

Dass je nach Festlegung der Semantik unterschiedliche objektorientierte Modelle entstehen, zeigt die folgende Variante des obigen Modells. Für dieses wurde angenommen, dass der Lehrveranstaltungsbesuch durch eine dreistellige Assoziation erfasst wird. Der Unterschied zu oben besteht darin, dass jetzt bei jedem Lehrveranstaltungsbesuch das Tripel Dozent / Studierende(r) / Lehrveranstaltung erfasst wird, während oben zwei zweistellige Assoziationen diesen Sachverhalt abdeckten (Studierende / Lehrveranstaltung bzw. Dozenten / Lehrveranstaltung).

Semantikvarianten

Grundsätzlich gilt, dass eine solche dreistellige Assoziation bzgl. dreier Klassen A, B und C mehr von der Semantik der Beziehung erfasst als die zweistelligen Assoziationen AB, AC und BC.

Mehr Semantik

Abbildung 3.8-2: Klassendiagramm zum Anwendungsbereich Hochschule - Prüfungsgeschehen und Lehrveranstaltungsbesuch dreistellig

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

- Zwei dreistellige Assoziationen

- Objekte mit verschiedenen Rollen

Außerdem zahlreiche beschriftete Assoziationen.

Im Beispiel zum Anwendungsbereich Angestellte (wie er hier kurz genannt wird) werden die hierzu oben eingeführten Modellfragmente zusammengeführt. Im Mittelpunkt steht die Klasse Angestellte. Ihre Objekte sind gleichzeitig Projektmitarbeiter, Mitarbeiter in Abteilungen, PC-Nutzer, sowie Abteilungsleiter bzw. Sachbearbeiter.

Anwendungs-
bereich "Angestellte eines Unternehmens"

Entsprechend ergeben sich die Assoziationen. Die Assoziation zwischen den Klassen Projekte und Angestellte hält fest, welche Angestellten in welchen Projekten tätig sind. Die unteren Werte sind Null, weil wir hier auch Projekte anlegen wollen, die noch keine zugewiesenen Angestellten haben und weil es auf der anderen Seite (natürlich) Angestellte gibt, die in keinem Projekt sind.

Amgestellte mit vielen Rollen

Die Assoziation zwischen den Klassen Angestellte und Abeilungen hält die Abteilungszugehörigkeit fest. Hier wird angenommen (bzw. wurde festgelegt), dass jeder Angestellte in genau einer Abteilung ist und dass eine Abteilung mindestens einen Angestellten hat.

Die Assoziation zur PC-Nutzung hält fest, dass ein PC keinem, einem oder vielen Angestellten zugeordnet sein kann. Der Hintergrund könnte sein, dass in der Anwendung und in der zugrundeliegenden Datenbank neu angeschaffte PC und PC in Reparatur keine Zuordnung zu Angestellten haben. Einem Angestellten ist kein PC oder maximal einer zugeordnet.

Bleibt noch die rekursive Assoziation, die das Vorgesetztenverhältnis erfasst.

Abbildung 3.8-3: Klassendiagramm zum Anwendungsbereich Angestellte

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

- Eine einstellige Assoziation

- Objekte mit verschiedenen Rollen

Außerdem zahlreiche beschriftete Assoziationen.

3.9 Navigierbarkeit

Die Entscheidung, ob ein Assoziationsende navigierbar ist oder nicht, hängt davon ab, ob eine Assoziation eine Eigenschaft hat. Wenn eine Eigenschaft am Ende einer Assoziation zu einem der assoziierten Classifier gehört, stellt sie ein navigierbares Ende der Assoziation dar. In diesem Fall ist die Eigenschaft auch ein Attribut des assoziierten Classifiers. Nur binäre Assoziationen haben navigierbare Enden.

Navigierbare Enden für binäre Assoziationen

Die Navigierbarkeit kann in den Grafiken angezeigt werden oder nicht. Sie kann in beide Richtungen existieren oder auch nur in eine. In den Grafiken wird sie durch Pfeile und Kreuze angezeigt.

  • Eine nicht gefüllte Pfeilspitze am Ende einer Assoziation bedeutet, dass das Ende navigierbar ist.
  • Ein kleines x am Ende der Assoziation bedeutet, dass das Ende nicht navigierbar ist.

Die folgende Abbildung zeigt einige Beispiele.

Assoziationen und Navigierbarkeit

  • Oberstes Paar AB: Binäre Assoziation mit zwei navigierbaren Enden.
  • CD: Binäre Assoziation mit zwei nicht-navigierbaren Enden.
  • EF: Binäre Assoziation mit nicht festgelegter Navigierbarkeit
  • GH: Binäre Assoziation, bei der ein Ende navigierbar ist und das andere nicht.
  • IJ: Binäre Assoziation, bei der ein Ende navigierbar ist und bei dem dies für das andere Ende nicht festgelegt ist.

Abbildung 3.9-1: Assoziationen - Navigierbarkeit von Enden
Quelle: [OMG 2003a, S. 85, Figure 33]

Die folgende Abbildung zeigt ein navigierbares Ende mit der Attributnotation. Diese Darstellung ist möglich, weil ein navigierbares Ende ein Attribut ist.

Abbildung 3.9-2: Navigierbares Ende einer Assoziation in Attribut-Notation
Quelle: [OMG 2003a, S. 86, Figure 34]

Oben wurde der Begriff schon eingeführt: Assoziationsende für die Enden einer Assoziation, von denen jede Assoziation mindestens zwei hat. Diese Assoziationsendenkönnen Eigenschaften haben, die in den Grafiken angegeben werden können.

Enden einer
Assoziation

Diese "Präzisierungen" werden am Linienende in geschweiften Klammern angegeben. Folgendes ist möglich:

  • Das Ende ist eine Teilmenge einer Eigenschaft. Dies wird durch {subsets <property-name>} angegeben. <property-name> ist die Eigenschaft.
  • Das Ende <end-name> wird durch das betreffende Ende neu definiert. Dies wird durch {redefined <end-name>} angegeben.
  • Das Ende ist die Vereinigung seiner Teilmengen. Dies wird durch {union} angegeben.
  • Das Ende stellt eine geordnete Menge dar. Dies wird durch {ordered} angegeben.
  • Das Ende ist eine Sammlung, in der ein Element mehrfach vorkommen kann. Dies wird durch {bag} angegeben.
  • Das Ende ist eine Sequenz (eine geordnete Sammlung). Dies wird durch {sequence} or {seq} angegeben.
  • Falls das Ende navigierbar ist, kann jede Eigenschaft, die zu einem der Attribute gehört, angegeben werden.

Falls das Assoziationsende abgeleitet ist, kann dies durch einen Schrägstrich vor der Bezeichnung gezeigt werden. Falls keine Bezeichnung vorliegt, kann der Schrägstrich auch alleine eingefügt werden.

Subset / Teilmengen

Das Ende einer Assoziation kann unter folgenden Umständen als eine Teilmenge des Endes einer anderen gekennzeichnet werden:

Enden und Teilmengen

  • Beide haben dieselbe Anzahl von Enden.
  • Jede der Type-Mengen, die durch die teilmengenbildende Assoziation verbunden werden, entspricht einem entsprechenden Type, der durch die aufgeteilte Assoziation verknüpft ist.

In diesem Fall ist die Sammlung des teilmengenbildenden Endes vollkommen enthalten in der Sammlung, die durch das aufgeteilte Ende bezeichnet ist.

Neudefinition (redefining)

Ein Assoziationsende kann als neudefinierend für ein anderes bezeichnet werden, falls gilt:

  • Beide haben dieselbe Anzahl von Enden
  • Jede der Type-Mengen, die durch die neudefinierende Assoziation verknüpft sind, entspricht einem entsprechenden Type, der durch die neudefinierte Assoziation verknüpft ist.

Ist also eine Menge von spezifischen Instanzen für die anderen Enden beider Assoziationen gegeben, gilt: Die Sammlungen der neudefinierenden und der neudefinierten Enden sind dieselben.

Spezialisierung von Assoziationen.

Assoziationen können auch spezialisiert werden. Das Bestehen einer Verknüpfung einer spezialisierenden Assoziation bedeutet die Existenz einer Verknüpfung, die dieselbe Menge von Instanzen in einer spezialisierten Assoziation in Beziehung setzt.

Spezialisiert und spezialisierend

Die folgende Abbildung zeigt Assoziationen, die zahlreiche der hier oben und in den oberen Abschnitten angeführten Beschreibungsmerkmale aufweisen:

Beispiele

  • Drei der vier Enden haben Bezeichnungen: a, b und d.
  • Alle Enden haben Beziehungswertigkeiten von 0..1 bei a, * bei b, 1 bei dem nicht benannten Ende und 0..1 bei d.
  • Festlegung, dass am Assoziationsende b eine Reihenfolge vorliegt.
  • Teilmengenbildung bei d. Für eine Instanz der Klasse C ist die Sammlung d eine Teilmenge der Sammlung b.

Abbildung 3.9-3: Assoziationsenden mit verschiedenen Ergänzungen
Quelle: [OMG 2003a, S. 84, Figure 32].

3.10 Objektdiagramme

In einem Klassendiagramm sind die Klassen des Anwendungsbereichs zusammengestellt. In manchen Situationen ist es aber auch gewünscht, einzelne Objekte und ihren jeweiligen Zustand (die aktuellen Daten) zu betrachten.

Von den Klassen zu Objekten

Dies ist möglich, weil ein objektorientiertes Modell wie oben gesehen Daten widerspiegelt, die als Attribute bzw. deren Ausprägungen angelegt sind. Betrachtet man deshalb ein objektorientiertes Modell zu einem bestimmten Zeitpunkt, kann man den Zustand der Daten zu diesem Zeitpunkt feststellen. Dazu ist es aber notwendig, nicht die Klassen, sondern einzelne Objekte (Instanzen) mit ihren Beziehungen untereinander zu betrachten. Diese Beziehungen sind hier erst mal nur die Assoziationen, später kommen Generalisierung / Spezialisierung (vgl. Kapitel 6) sowie Aggregation und Komposition (vgl. Kapitel 5) hinzu.

Zustand der Daten zu einem bestimmten Zeitpunkt

Eine solche Abbildung, die dann als Knoten nur einzelne Objekte (Instanzen) enthält, wird Objektdiagrammoder Objektmodellgenannt. Es enthält die ausgewählten Objekte mit Assoziationen und die interessierende Datenlage.

Abbildung mit Objekten

Die folgende Abbildung zeigt ein Beispiel in Anlehnung an das objektorientierte Modell Angestellte. Vgl. Abschnitt 2.4.2 für die grafische Darstellung von Objekten. Es ist tatsächlich ein "Schnappschuss", z.B. in einer Anwendung, die Projektmitarbeit abfragt.

Ausgedrückt ist, dass der Angestellte Paul Maier im Projekt bpr (Business Process Reengineering) mitwirkt und dass er den PC A1723 nutzt.

Abbildung 3.10-1: Objektdiagramm zum Klassendiagramm Angestellte.

 

Verwendete Fachbegriffe in diesem Kapitel

Assoziation, einstellige

unary association

Assoziation, mehrstellig

n-ary association

Assoziation, rekursive

recursive association

Assoziation, zweistellig / binär

binary association

Assoziationsende

association end

Assoziationsende, abgeleitetes

derived association

Assoziationsklasse

association class

Klassendiagramm

class diagram

Navigierbarkeit

navigability

Objektdiagramm

object diagram

Rolle

role

Links der in diesem Text verwendete Begriff. Rechts der in der objektorientierten Theorie bzw. in der UML verwendete Begriff.

 

4 Assoziationsklassen

4.1 Einführung

Attribute und Methoden auf Beziehungen

Beziehungen zwischen Objekten bzw. Objektklassen hatten in der bisherigen Darstellung keine eigenen Attribute und Methoden, sie stellten einfach eine auf semantischen Gegebenheiten beruhende Verknüpfung von Objekten dar. Dies ist auch oft der Fall, allerdings bei weitem nicht immer, wie ja auch die älteren Datenmodellierungsansätze zeigen, wo Beziehungen sehr oft durch Attribute beschrieben werden.

Auch das obige etwas ausführlichere Beispiel zum Anwendungsbereich Hochschule musste dem aufmerksamen Leser einige Fragen stellen:

Attribute auf Assoziationen

  • Wo werden die Daten, die aus der dreistelligen Assoziation Prüfungsgeschehen herrühren, gespeichert und damit verfügbar gemacht (z.B. für den Ausdruck von Notenlisten)?
  • Wo wird erfasst, wann ein Lehrveranstaltungsbesuch tatsächlich stattfand, unabhängig davon ob er in einer zwei- oder dreistelligen Assoziation modelliert wurde?
  • Wie erfolgt die Erfassung der Zeitaspekte, hier in den Beispielen (wesentliches Merkmal einer Prüfung ist der Zeitpunkt, an dem sie stattfindet) und grundsätzlich?

Offensichtlich gibt es also Attribute und auch Methoden, die der Assoziation zugeordnet werden müssen und die im Modell zu erfassen sind.

Grundsätzlich wäre auch denkbar, dass die objektorientierte Modellierung Attribute und Methoden von Beziehungen auf andere Weise modelliert, nicht durch die Präzisierung der Modellierung von Beziehungen. Dies scheinen auch viele Autoren in diesem Bereich zu denken, die auf die Betrachtung dieses Sachverhalts verzichten, wodurch er - da er ja nicht verschwindet - direkt in die zu programmierenden Anwendungen verlagert wird und das heißt, in das Software Engineering und die Systemanalyse.

Entweder im
objektorientierten Modell oder direkt im Anwendungs-
programm

Es geht also darum, Attribute und Methoden, die zur Assoziation gehören, zu erfassen. Das Werkzeug hierfür sind die sog. Assoziationsklassen. Sie sind sozusagen gleichzeitig Klasse und Assoziation, was auch die Definition der UML-Autoren ausdrückt:

Auch Beziehungen haben Attribute und Methoden

"A model element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties." [OMG 2003a, S. 5]

Vgl. auch die Ausführungen in [Balzert 1999a, S. 45], [Oestereich 1998, S. 272ff] und [Meier und Wüst 1997]). Andere Bezeichnungen sind Assoziative Klassen (Balzert), Beziehungsklassen (Meier und Wüst) oder auch Attributierte Assoziationen (Oestereich).

Assoziative Klassen
Beziehungsklassen
Attributierte Assoziationen

Wie Meier und Wüst diese sehen, machen die folgenden Zitate deutlich.

"Verfügen Beziehungen zwischen Klassen selbst über beschreibende Attribute oder Methoden, so muss zu diesem Zweck eine explizite Beziehungsklasse definiert werden. Eine Beziehungsklasse (association class) ist eine Klasse, die von mehr als einer Klasse abhängig ist." [Meier und Wüst 1997, S. 22]

Sie präzisieren und begründen dann wie folgt:

"Typisch bei jeder Beziehungsklasse ist, dass die Beziehungsattribute weder der einen noch der anderen Klasse zugeordnet werden können, da solche Merkmale ein Verhältnis zwischen mindestens zwei Klassen ausdrücken." [Meier und Wüst 1997, S. 22]

Die richtige Zuordnung der Attribute ist hier von großer Bedeutung. Nur genau die Attribute, die für die Beziehung gültig sind, gehören in die Assoziationsklasse. Hierzu einige Beispiele:

Kritische Situation

  • Nehmen wir an, dass es in einem objektorientierten Modell die Klassen Männer und Frauen sowie die Assoziationsklasse Ehe gibt. Dann gehören in die Klasse Ehe eben nur Attribute wie Beginn, zahlKinder, usw.
  • Angenommen, in einem objektorientierten Modell gibt es die Klassen Kraftfahrzeuge und (Kraftfahrzeuge verkaufende) Händler und eine Assoziation zwischen diesen ("wer verkauft welche Kraftfahrzeuge"). Dann gehört ein Attribut listenpreis in die Klasse Kraftfahrzeuge, während ein Attribut marktpreis für den jeweils niedrigsten Preis der Assoziation zuzuordnen ist.

Die Thematik ist im Übrigen eine alte, die in der klassischen Datenmodellierung auch gelöst werden musste. Z.B. in der Relationalen Datenmodellierung bei der Erfassung von n:m-Beziehungen und der Zuordnung von Attributen zur Verbindungsrelation (vgl. [Staud 2005, Kapitel 3], [Staud 2021]).

Schlüssel

Sobald einem Realweltphänomen Attribute zugeordnet werden, muss es auch eine identifizierende Information erhalten. In der relationalen Datenbanktheorie wird dies - wenn es um die Verknüpfung zweier Relationen geht - in der Regel durch zwei Attribute gelöst, die Schlüssel der beteiligten Relationen. Grundsätzlich ist auch die Vergabe eines Schlüssel für die Beziehung möglich, so dass z.B. jeder Prüfungsbesuch (wenn es um Studierende und Prüfungs geht, eine eigene Nummer erhält.

Beziehungen identifizieren

In den Texten zur objektorientierten Theorie wird dieses Problem oft ignoriert oder es wird in der Assoziationsklasse eine "Id" vergeben, die strukturell der oben angeführten zweiten Möglichkeit entspricht. Oftmals werden dann aber doch die "Ids" der beteiligten Klassen zusätzlich mitangegeben.

"Id's"

Um alle Möglichkeiten offen zu halten, wird in den Beispielen hier ähnlich verfahren: Zu Beginn der Attributliste werden neben einer identifizierenden Information die identifizierenden Informationen der beteiligten Klassen angegeben.

4.2 Grafische Darstellung

Die Assoziationsklasse wird als Klasse angelegt und mittels einer gestrichelten Linie mit der Assoziationslinie verbunden. Bei einer zweistelligen Assoziation einfach mit der Linie, so wie es die folgende Abbildung zeigt.

Abbildung 4.2-1: Grafische Darstellung einer Assoziationsklasse an einer zweistelligen Assoziation

Bei einer n-stelligen Assoziation wird die gestrichelte Linie mit der dann ja notwendigen Raute verbunden. Die folgende Abbildung zeigt eine Assoziationsklasse an einer dreistelligen Assoziation.

Abbildung 4.2-2: Grafische Darstellung einer Assoziationsklasse an einer dreistelligen Assoziation

4.3 Beispiele

Das obige Beispiel zu Angestellten und ihren PCs wurde hier um eine Assoziationsklasse mit Attributen zu folgenden Sachverhalten ergänzt:

  • Art des "Besitzverhältnisses": als Administrator, als Nutzer, als Gast (mit jeweils spezifischen Rechten)
  • Beginn und Ende der Nutzung

Die Wertigkeiten seien jetzt so, dass einem Angestellten mindestens ein PC zugeordnet ist und einem PC kein oder maximal ein Angestellter.

Methoden in der Assoziationsklasse könnten die notwendigen Einträge in die Datenbank sein, sowie das Erstellen einer Mitteilung bezüglich Eintragung, Austragung oder Änderung an eine zentrale Nutzerverwaltung sein.

Beispiel Angestellte, PC

Abbildung 4.3-1: Assoziationsklasse PC-Nutzung auf zweistelliger Assoziation

Die folgende Abbildung zeigt eine Assoziationsklasse für eine dreistellige Assoziation zwischen PC, Angestellten und Abteilungen. Grundlage dieser Art der Modellierung ist, dass die Klasse Abteilungen eingeführt wurde, weil Abteilungen im Modell zu einer eigenständigen Existenz fanden.

Beispiel
Angestellte - PC - Abteilungen

Die Wertigkeiten bedeuten hier bezüglich einer PC-Nutzung:

  • Die Nutzung erfolgt in einer Abteilung
  • Es geht jeweils um einen PC
  • Die Nutzung betrifft einen oder zwei Angestellte

In der Spezifizierung der Assoziation wird zusätzlich zum Eintragen, Austragen und Ändern noch eine Methode eingebaut, die festzuhalten erlaubt, auf welche Kombination von Abteilung und PC sich die konkrete Nutzung bezieht.

Abbildung 4.3-2: Assoziationsklasse auf dreistelliger Assoziation

Aufgelöste Assoziationsklasse

In der Literatur zur UML fehlt nicht der Hinweis, dass eine solche Beziehungsklasse im Feindesign der Systemanalyse zu einer "richtigen" Klasse wird, wobei dann natürlich die Wertigkeiten der Beziehung entsprechend übernommen werden müssen (vgl. auch [Oestereich 1998, S. 274]).

Aufgelöste Assoziationsklasse durch
Feindesign

Die folgende Abbildung zeigt das obige Beispiel einer zweistelligen Assoziation zu Angestellten und PC mit der Assoziationsklasse PC-Nutzung entsprechend aufgelöst. Die aufgelöste Assoziationsklasse erhält die Bezeichnung Besitzverhältnis. Die Wertigkeiten bestehen jetzt jeweils in Bezug auf das Besitzverhältnis:

Beispiel Angestellte, PC

Aus Ein Angestellter nutzt mindestens einen PC wird

  • Ein Angestellter hat mindestens ein Besitzverhältnis und
  • Ein Besitzverhältnis bezieht sich auf einen Angestellten

Aus Ein PC ist keinem oder maximal einem Angestellten zugeordnet wird

  • Ein PC hat kein oder maximal ein Besitzverhältniss und
  • Ein Besitzverhältnis bezieht sich auf genau einen PC.

Von einer Instanz der Assoziationsklasse aus ist die Wertigkeit der Assoziationsenden immer 1 (vgl. auch [OMG 2003a, S. 119]).

Abbildung 4.3-3: Aufgelöste Assoziationsklasse

Beispiel Hochschule

Hier nun das im letzten Kapitel vorgestellte Klassendiagramm Hochschule zum gleichnamigen Anwendungsbereich, jetzt aber mit einer Assoziationsklasse.

Die Assoziationsklasse hat die Bezeichnung StudAkten (Studierendenakten). Sie ist notwendig, weil beim Prüfungsbesuch Daten anfallen, die direkt zur Assoziation gehören und nicht bei den beteiligten Klassen untergebracht werden können [Anmerkung] . Dies sind hier die Prüfungsergebnisse mit den angegebenen Attributen:

Assoziationsklasse StudAkten

  • Die Prüfungsnummer (pruefNr) nummeriert einfach alle Prüfungen durch.
  • Die Matrikelnummer (matrikelNr) hält den Studierenden fest, der die Prüfung besucht.
  • Die Prüfungstypnummer (prTypNr) hält fest, um welchen Prüfungstyp (Klausur, usw.) es sich handelt.
  • In bezLV ist festgehalten, auf welche Lehrveranstaltung sich die Prüfung bezieht.
  • datum hält fest, wann die Prüfung stattfand.
  • note hält fest, welche Note erzielt wurde.
  • gewichtung hält fest, welche Gewichtung die Note im gesamten Notenspektrum hat.

Mögliche Einträge wären (nach der obigen Attributreihenfolge und mit den Ausprägungen bei pruefNr: 1 = Klausur, 2 = Laborarbeit):

  • 007 / 1 / DBS / 15.2.09
  • 007 / 2 / DBS / 31.12.08 (Abgabetermin)
  • 008 / 1 / DBS / 15.2.07

Mit der Methode eintragen() werden die Noten jeweils in die Datenbank eingetragen.

Abbildung 4.3-4: Klassendiagramm Hochschule mit Assoziationsklasse StudAkten

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

- Eine dreistellige Assoziation

- Objekte mit verschiedenen Rollen

Außerdem zahlreiche beidseitig beschriftete Assoziationen.

Beispiel Angestellte

Auch das Klassendiagramm Angestellte wurde um eine (naheliegende) Assoziationsklasse ergänzt, die oben schon eingeführte mit der Bezeichnung PC-Nutzung. Sie beschreibt mit Art der Nutzung (Administrator, normaler Nutzer, "Superuser", Gast, ...), Beginn der Nutzung und Ende der Nutzung einige zentrale Fakten rund um die PC-Nutzung.

Assoziationsklasse PC-Nutzung

Abbildung 4.3-5: Klassendiagramm Angestellte mit Assoziationsklasse PC-Nutzung

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

- Eine Assoziationsklasse an einer zweistelligen Assoziation

- Eine einstellige (rekursive) Assoziation

- Mehrere zweistellige Assoziationen

- Objekte mit fünf verschiedenen Rollen

Außerdem zahlreiche beidseitig beschriftete Assoziationen.

 

 

5 Aggregation und Komposition

5.1 Definition

Aggregation

Im wirklichen Leben gibt es ein allgegenwärtiges Strukturmerkmal, das so beschrieben werden kann: Es gibt Dinge, die andere Dinge enthalten. Und auch letztere können wieder aus Dingen bestehen. Die einfachsten Beispiele finden sich im technischen Bereich: Ein Airbus besteht aus Grobkomponenten, diese aus feineren Komponenten, diese auch wieder - bis man bei elementaren Teilen angekommen ist.

Dinge, die andere Dinge enthalten

Ein so wichtiges Strukturmerkmal muss dann natürlich auch bei der Realitätsmodellierung, sei es für Systeme, für Datenbanken oder für Geschäftsprozesse, zur Verfügung stehen.

Das Konzept für die Modellierung dieses Strukturmerkmals wird in der objektorientierten Modellierung Aggregation genannt. Es ist eine spezielle Ausprägung einer Assoziation, allerdings können nur zweistellige Assoziationen Aggregationen sein.

Bei der Aggregation geht es also um Beziehungen zwischen Klassen, die den Tatbestand beschreiben, dass bestimmte Objekte in anderen enthalten sind [Anmerkung] . Deshalb nennen die UML-Autoren (und ihre Vorgänger) diese Beziehung auch whole-part relationship. In der deutschsprachigen Literatur wird diese Beziehung daher Teil_von-Beziehung genannt.

Komposition

Kompositionen (composite aggregation) sind ebenfalls Aggregationen, allerdings mit einer zusätzlichen Bedingung: Jedes Objekt einer Komponentenklasse darf zu einem bestimmten Zeitpunkt nur Komponente eines einzigen Objekts der Aggregatklasse sein. Außerdem ist das Aggregatobjekt verantwortlich für die Entstehung und Zerstörung der Komponenten.

Es muss also bei der Aggregationsklasse eine Kardinalität von nicht größer als eins vorliegen. Außerdem gilt, dass bei einem Löschen eines Aggregationsobjekts die entsprechenden Komponentenobjekte ebenfalls gelöscht werden. Die Komponenten sind also existenzabhängig vom Ganzen.

unshared aggregation,
strong ownership

Eine Komposition wird auf dieselbe Weise dargestellt wie eine zweistellige Assoziation, aber mit einer gefüllten Raute am Assoziationsende.

5.2 Einführende Beispiele mit grafischer Notation

Aggregationen

Ein PC (Personal Computer) besteht typischerweise (u.a.) aus einer Hauptplatine, Festplatten und einem Bildschirm. Auf der Hauptplatine wiederum finden sich (u.a.) Prozessoren, Speicherbausteine und Bussysteme (vgl. das Beispiel unten). Beliebt in der Literatur ist auch das Beispiel moderner Flugzeuge, die natürlich - vielstufig - aus zahlreichen Komponenten bestehen.

Komponenen eines PC

In der folgenden Abbildung ist das oben erwähnte Beispiel in der UML-Notation angegeben. Jede Verbindungslinie von einer Komponenten- zu einer Aggregationsklasse bedeutet eine Teil_von-Beziehung und wird durch eine Raute wie in der Abbildung gezeigt grafisch ausgedrückt [Anmerkung] . Die Raute kennzeichnet die Aggregation.

Die einzelnen Beziehungen werden auch als Assoziationen bezeichnet und können ebenfalls mit den in Abschnitt 3.4 eingeführten Wertigkeiten spezifiziert werden.

Abbildung 5.2-1: Erfassung einer Komponentenstruktur durch Aggregation

Eine textliche Beschreibung der Assoziationen ist in der Abbildung angegeben. Die Wertigkeiten legen die Beziehungen beispielhaft fest:

  • Ein PC hat genau eine Hauptplatine
  • Eine Hauptplatine steckt in maximal einem PC
  • Ein PC hat mindestens eine Festplatte
  • Jede Festplatte gehört zu maximal einem PC
  • Ein PC hat genau einen Bildschirm
  • Ein Bildschirm gehört zu maximal einem PC
  • Eine Hauptplatine enthält mindestens einen, maximal vier Prozessoren
  • Jeder Prozessor gehört zu maximal einer Hauptplatine
  • Eine Hauptplatine enthält mindestens einen Speicherbaustein
  • Jeder Speicherbaustein gehört zu maximal einer Hauptplatine. Damit wird deutlich, dass es nicht um Typen (von Speicherbausteinen), sondern um einzelne Exemplare geht.
  • Eine Hauptplatine enthält mindestens ein, maximal drei Bussysteme
  • Jedes Bussystem gehört zu einer Hauptplatine

Die Grenze zwischen "einfachen" Assoziationen und Aggregationen ist fließend. Deshalb kann die oben als einfache Assoziation modellierte Stücklistenbeziehung (vgl. Abbildung 3.5-8) hier als Aggregation angeführt werden.

Stückliste

Abbildung 5.2-2: Stücklistenbeziehung als Aggregation

Allerdings ist diese Modellierung aussagekräftiger als die oben, da sie zusätzlich zur semantischen Verknüpfung noch das Enthaltensein ausdrückt.

Kompositionen

Bei Kompositionen wird die Raute eingeschwärzt, ansonsten ist die grafische Notation dieselbe wie für Aggregationen. Die Wertigkeit auf der Seite der Aggregation ist auf Grund der Definition von Kompositionen immer eins, so dass sie oft auch weggelassen wird.

Existenz­abhängigkeit

Ein Beispiel für eine Komposition ist die Beziehung zwischen einem Rechnungskopf und den Rechnungspositionen, das in der folgenden Abbildung angegeben ist.

Abbildung 5.2-3: Die Beziehung zwischen Rechnung(skopf) und Rechnungspositionen als Komposition

Ein anderes gern angeführtes Beispiel ist das der Baumstruktur eines Dateien verwaltenden Systems, z.B. des Windows Explorer. Löscht man ein Dateiverzeichnis, werden die enthaltenen Dateien und Verzeichnisse auch gelöscht. Außerdem kann eine konkrete Datei nur in einem Verzeichnis sein.

Baumstruktur

 

6 Generalisierung / Spezialisierung

6.1 Definition

Stellen wir uns folgende Situtation 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 Gruppierung von Attributen und Methoden erlaubt dieses Konzept eine "sparsame" Modellierung (und später dann Programmierung), denn eine Alternative wäre, die Attribute (und Methoden) der generalisierten Einheit (Klasse, Entitätstyp, ...) allen spezialisierten Einheiten zuzuweisen. Die andere Alternative, alle Attribute und Methoden aller Spezialisierungen und der Generalisierung in eine Einheit (Klasse, Entitätstyp, ...) zu tun, kommt wegen der dann auftretenden grundsätzlichen Probleme ebenfalls nicht in Frage.

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 Superklassefü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.

6.2 Grafische Darstellung

Auch hier orientiert sich die grafische Notation an der UML 2.5. Vgl. [OMG 2017, Abschnitt 9.7.4]. 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.

Abbildung 6.2-1: Grafische Darstellung einer Generalisierung / Spezialisierung

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

6.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

Abbildung 6.3-1: Generalisierung / Spezialisierung - 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.

Generalisierungsmengen

Jede einzelne Beziehung zwischen einer spezialisierten und einer generalisierten Klasse wird Generalisierungsbeziehung genannt. 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.

Generalisierungs-
beziehung und Generalisierungs-
menge

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.

Abbildung 6.3-2: Generalisierung / Spezialisierung - Generalisierungsmengen

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

Abbildung 6.3-3: Generalisierung / Spezialisierung - alternative grafische Gestaltung

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

Abbildung 6.3-4: Generalisierung / Spezialisierung - Generalisierungsmengen durch Strichlinien

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.

Abbildung 6.3-5: Generalisierung/Spezialisierung mit mehreren Generalisierungsmengen

Es ist also möglich, dieselbe Superklasse mehrfach zu spezialisieren (mehreren Diskriminatoren auszusetzen) und dies in einer einzigen 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.

6.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
  • NoSQL-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.

Abbildung 6.4-1: Generalisierung / Spezialisierung für Datenverwaltende Systeme.

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. Insgesamt können folgende Subklassenvarianten unterschieden werden:

Überdeckung

  • 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

Abbildung 6.4-2: Disjunkte Subklassen und vollständige Überdeckung der Superklasse durch die Subklassen in einer Generalisierung / Spezialisierung.

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

Abbildung 6.4-3: Disjunkte Subklassen und unvollständige Überdeckung der Superklasse durch die Subklassen in einer Generalisierung / Spezialisierung

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

Abbildung 6.4-4: Überlappende Subklassen und vollständige Überdeckung der Superklasse durch die Subklassen in einer Generalisierung / Spezialisierung

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

Abbildung 6.4-5: Überlappende Subklassen und unvollständige Überdeckung der Superklasse durch die Subklassen in einer Generalisierung / Spezialisierung

6.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

Abbildung 6.5-1: Generalisierung / Spezialisierung mit mehreren Ebenen.

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

- Mehrere Generalisierungsebenen

- Zahlreiche 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 nicht. Letztere finden sich dann in der Generalisierung Beschäftigte.

Noch ein Beispiel: Beschäftigte

Die Arbeiter könnten unterteilt werden in Arbeiter des Unternehmens (Arbeiter d.U.) 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.

Abbildung 6.5-2: Generalisierung / Spezialisierung mit mehreren Generalisierungsmengen und in mehreren Ebenen

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

- Mehrere Generalisierungsebenen

- Zahlreiche Generalisierungen / Spezialisierungen

Außerdem zahlreiche vollständige Überdeckungen.

6.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.

6.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.

Abbildung 6.7-1: Abstrakte Klasse Window
Quelle: [OMG 2017, S. 196, Figure 11.16]

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

Abstrakte Operationen

AbstrakteOperationensind 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.

Verwendete Fachbegriffe in diesem Kapitel

Abstrakte Klasse

abstract class

Abstrakte Operation

abstract operation

Generalisierungsbeziehung

generalization relationship

Generalisierungsmenge

generalizatiion set

Ist_ein - Beziehung

is a - relationship

konkrete Klasse

concrete class

konkrete Operation

concrete operation

Mehrfachvererbung, mehrfache Vererbung

multiple inheritance

Subklasse

subclass

Superklasse

superclass

Vererbung

inheritance

Links der in diesem Text verwendete Begriff. Rechts der in der objektorientierten Theorie bzw. in der UML verwendete Begriff.

 

7 Zusammenwirken durch Nachrichtenverkehr

7.1 Einführung

Von Anbeginn an war das Konzept des Nachrichtenaustausches zwischen Objekten Gegenstand der objektorientierten Theorie. Botschaften, wie sie auch genannt werden, wiesen auch schon fast alle Vorgänger der UML auf (vgl. [Stein 1994, S. 78]). Sie wurden gesehen als Werkzeug zur "Interobjektkommunikation" [ebenda, S. 179].

Objekte kommunizieren

Mit dem Konzept des Nachrichtenaustausches wird die Ebene der Strukturbeschreibung (wie in den obigen Kapiteln vorgestellt) verlassen und die der Verhaltensbeschreibung erreicht, denn Nachrichten sind Ausdruck der "Funktionalität eines objektorientiert entwickelten Systems" und die gesamte Funktionalität beruht auf dem Nachrichtenaustausch [Schader und Rundshagen 1994, S. 16].

Von der Struktur- zur Verhaltens-
beschreibung

Der Übergang zu den "Verhaltensaspekten" führt auch dazu, dass in diesem Kapitel einige neue Grundbegriffe erläutert werden müssen, Kollaborationen, Rollen und Lebenslinien, bevor dann der eigentliche Gegenstand (Nachrichten, Kommunkationsdiagramme) vorgestellt werden kann.

Hintergrund

Wie oben gezeigt, sind bei den Objektklassen Methoden hinterlegt, mit denen die Objekte der jeweiligen Klasse bearbeitet werden können.

Hinterlegte Methoden

Genauer:

Verarbeitet werden die Ausprägungen der Attribute, durch die die Objekte beschrieben sind. Die interne Repräsentation der Objekte.

Dabei handelt es sich um Methoden, die zur Erfüllung einer Teilaufgabe in der Gesamtanwendung dienen. Für viele Aufgaben ist es aber notwendig, dass die Methoden verschiedener Objektklassen im korrektem Zusammenspiel aufgerufen werden. Dies wird so realisiert, dass Objekte der einen Objektklasse Methoden einer anderen aufrufen können. Modellierungstechnisch wird dies mit dem Konzept von Nachrichten, die zwischen den Objekten und Objektklassen ausgetauscht werden, realisiert.

Methoden im Zusammenspiel

Den einfachsten Fall eines solchen Nachrichtenaustausches können wir bereits darstellen: Die Kommunikation zweier Objekte miteinander.

Der einfachste Fall

Stellen wir uns vor, bei einer Klasse Rechnungsköpfe sei die Methode für das Erstellen und den Ausdruck von Rechnungen hinterlegt. Dann gibt es eine Stelle in diesem Ablauf, an dem das jeweilige Objekt (in der folgenden Abbildung als anonymes Objekt dargestellt) von einem Objekt der Klasse Kunden die Kundendaten (Name, Adresse, usw.) anfordert. Dies kann wie in der folgenden Abbildung gezeigt, dargestellt werden (zur grafischen Darstellung vgl. unten).

Rechnungskopf braucht Kundendaten

Abbildung 7.1-1: Nachrichtenaustausch zum Zwecke der Kooperation

Voraussetzung für das Gelingen ist, dass in der Klasse Kunde eine entsprechende Methode kundendaten() vorhanden ist.

Begriffe

Meist werden in der deutschsprachigen Literatur die Begriffe Nachricht und Nachrichtenaustausch verwendet. Bei einigen Autoren (so z.B. bei den beiden Balzerts) auch Botschaft. Die UML und die übrige englischsprachige Literatur verwenden die Begriffe message und message passing.

Nachricht oder auch Botschaft

Nachrichten

Hier eine erste Klärung des Nachrichtenbegriffs, mehr dazu in Abschnitt 7.5. Nachrichten stehen in einem engen Zusammenhang mit Methoden und Operationen. Definiert man, wie in Kapitel 2 geschehen, Operationen als Dienste, die von einem Objekt angefordert werden können, und als Methoden die Implementierungen der Operationen, dann können Nachrichten so definiert werden:

Nachrichten fordern Operationen an

"Eine Nachricht überbringt einem Objekt die Information darüber, welche Aktivität von ihm erwartet wird, d.h. eine Nachricht fordert ein Objekt zur Ausführung einer Operation auf." [Oestereich 2004, S. 355]

Nur unwesentlich verkürzt bei Meier und Wüst:

"Unter einer Nachricht (engl. message) versteht man die Aufforderung eines Objektes an ein anderes, eine bestimmte Methode auszuführen." [Meier und Wüst 1997, S. 32]

Meldungsverkehr

Die Menge der Botschaften, auf die Objekte einer Klasse reagieren können, wird als Protokoll(protocol) der Klasse bezeichnet" [Balzert 2001, S. 206f].

Protokoll

Unterschieden wird dabei der Aufruf von Instanzmethoden und von Klassenmethoden. Wie in Kapitel 2 gezeigt wurde, sind erstere Methoden, die einzelne Instanzen betreffen, z.B. eine Preisänderung bezüglich einer Instanz einer Objektklasse zu Produkten. Zweitgenannte betreffen Methoden, durch die alle Objekte einer Objektklasse angesprochen sind, z.B. die Feststellung der Gesamtzahl der Angestellten oder der Lohnsumme in einer Klasse zu den Angestellten.

Instanzmethoden
und
Klassenmethoden

Interaktion

Für die UML-Autoren fällt der Nachrichtenverkehr zwischen Objekten unter den Begriff der Interaktion. Für sie basiert eine Interaktion auf einem strukturierten Classifier oder auf einer Kollaboration. Die Interaktion kann im Rahmen der UML als Sequenz mit Sequenzdiagrammen oder als Kommunikation mit Kommunikationsdiagrammen beschrieben werden, die jeweils unterschiedliche Aspekte der Interaktion betonen [Rumbaugh, Jacobson und Booch 2005, S. 37].

Basis einer Interaktion: strukturierte Classifier oder Kollaborationen

Unter einem strukturierten Classifier kann man sich z.B. ein objektorientiertes Modell mit einem Kommunikationsdiagramm vorstellen, Kollaborationen werden im nächsten Abschnitt vorgestellt.

In den Originalquellen und bei den meisten sonstigen Autoren wird auch betont, dass als Versender wie auch als Empfänger von Nachrichten Rollen (vgl. unten) betrachtet werden und nicht die Klassen als solche (vgl. z.B. [Rumbaugh, Jacobson und Booch 2005, S. 39]). Deshalb erfolgt in Abschnitt 7.3 auch eine vertiefte Klärung des Rollenbegriffs.

Rollen gestalten den Nachrichten-
verkehr

7.2 Kollaborationen

7.2.1 Definition

Oben wurde es angeführt: Neben den strukturierten Classifiern (i.d.R. objektorientierte Modelle die sich als Klassendiagramme grafisch artikulieren) sind Kollaborationen die Basis für die Betrachtung des Nachrichtenverkehrs.

Dieses Theorieelement ist eigentlich nicht notwendig, da "Zusammenarbeit" in vielen anderen Theorieelementen der UML modelliert wird. In Booch et al wird aber dann doch die Motivation deutlich, die hinter diesem Konstrukt steht. Es soll "Verhalten im Kleinen" modellieren. Der Schlüssel(neben)satz für dieses Verständnis ist der folgende:

Verhalten "im Kleinen"

"Eine Kollaboration benennt eine Gemeinschaft von Klassen, Interfaces und anderen Elementen, die zusammenarbeiten, um ein kooperatives Verhalten hervorzurufen, das mehr ist als die Summe seiner Teile." ([Booch, Rumbaugh und Jacobson 2006, S. 425], Hervorhebung durch den Verfasser).

Also sinnvoll abgegrenzte Systemkomponenten (die Autoren denken nur an Systeme, das macht die Wortwahl deutlich), bei denen alles übrige, was nicht mit dem ausgewählten Verhalten zu tun hat, weggelassen wird.

Dies sind so etwas wie elementare Systembestandteile, die nicht nur jeweils einzeln mehr sind als die Summe ihrer Teile, sondern die auch jeweils einen wichtigen Beitrag zum Gesamtsystem leisten:

Elementare Systembestandteile

"Das Herz der Architektur eines Systems schlägt in seinen Kooperationen, alle gut strukturierten objektorientierten Systeme sind aus einer regulären Menge mittlerer Größe solcher Kollaborationen aufgebaut, ..." [Booch, Rumbaugh und Jacobson 2006, S. 431]

Damit wird deutlich, dass es wesentlich um Systemdesign geht. Hier ist tatsächlich das Finden der elementaren Verhaltenseinheiten von entscheidender Bedeutung für die Qualität der dann entstehenden Software.

Die Beschreibung dieses eng umgrenzten Verhaltens soll dann auch die Rollen angeben, die die Partizipanten dabei einnehmen. Dies ist den UML-Autoren sehr wichtig. Die Betonung der Rollen geht so weit, dass die UML-Autoren hier die "collaborating elements" und die Rollen gleichsetzen [ebenda].

Rollen

Eine Kollaboration kann damit z.B. eine Operation beschreiben oder aber einen Anwendungsfall (vgl. Kapitel 12), in dem die Classifier und Assoziationen angegeben werden, die für seine Leistung notwendig sind [OMG 2003a, S. 157], [OMG 2005, S. 157].

Auch dies gibt Hinweise auf die Motivation für dieses doch etwas überraschende Theorieelement. Es geht wohl auch um den Wunsch, einzelne Anwendungsfälle näher zu beschreiben.

Auf jeden Fall aber sind die Grundlage von Kollaborationen Teile, die zusammenarbeiten (in UML-Sprache: Teile eines Classifier) und andere Elemente, die diese verknüpfen. Im Standardfall also Klassen und Assoziationen.

Auch bei diesem Konzept denken die UML-Autoren in erster Linie an Systeme: "Its primary purpose is to explain how a system works ..." (OMG 2005, S. 164) [ebenda]. Aber dies ist ja nicht überraschend, sondern im größten Teil der UML-Texte so.

Systeme

Kollaborationen haben nur eine eingeschränkte Aussagekraft. Will man genauer wissen, wie das Zusammenspiel und der dafür notwendige Nachrichtenverkehr erfolgt, dann sind Kommunikations- oder Sequenzdiagramme besser geeignet.

Begrenzte Aussagekraft

Booch et al. weisen noch darauf hin, dass es auch eine Beziehung zwischen Kollaborationen gibt, Verfeinern [Booch, Rumbaugh und Jacobson 2006, S. 431f]. Dabei wird in der "verfeinerten" Kollaboration ein Teil des Verhaltens der anderen erfasst.

7.2.2 Grafische Darstellung

Eine Kollaboration wird als Ellipse mit gestrichelter Linie dargestellt. In der Ellipse wird die Bezeichnung der Kollaboration vermerkt.

Abbildung 7.2-1: Grafische Darstellung einer Kollaboration

Die interne Struktur der Kollaboration (Rollen und Konnektoren) kann ebenfalls in der Ellipse angegeben werden, getrennt von der Bezeichnung durch eine gestrichelte Linie. Vgl. dazu die Beispiele.

7.2.3 Beispiele

Im ersten Beispiel ist angedeutet, dass die Kollaboration Rechnung schreiben von den beiden Komponenten Rechnungskopf und Rechnungspositionen realisiert wird.

Beispiel Rechnungen

Abbildung 7.2-2: Kollaboration Rechnungserstellung

Alternativ kann ein Komponentendiagramm genutzt werden. In diesem Fall werden die beteiligten Classifier mit dem Symbol für die Kollaboration verbunden.

7.3 Rollen

Der Begriff Rolle wurde oben in dem Kapitel zu Assoziationen schon angesprochen. Dort wurden z.B. die Angestellten in ihrer Rolle als PC-Nutzer oder in ihrer Rolle als Gehaltsempfänger modelliert.

Benötigt wird der Begriff in der UML für Kollaborationen, für den Begriff "Part" und für Assoziationen.

Die UML-Autoren definieren eine Rolle als eine Menge von Merkmalen, die benannt sind und die sich auf eine Sammlung von Entitäten beziehen, die in einem bestimmten Zusammenhang stehen [OMG 2003a, S. 14]. Bei der Fortsetzung der Definition unterscheiden sie zwischen Kollaborationen, "Parts" und Assoziationen:

  • Bei Kollaborationen sprechen sie von einer benannten Verhaltensmenge einer Klasse oder eines "Part", die in einem bestimmten Zusammenhang stehen.
  • Bei "Part" von einer Teilmenge einer bestimmten Klasse, die einen Teil der Merkmale der Klasse besitzt.
  • Bei Assoziationen stellt eine Rolle ein Synonym für ein Assoziationsende dar, das sich auf eine Teilmenge der Classifier-Instanzen bezieht, die an der Assoziation teilhaben [ebenda].

Für eine vertiefte Darstellung vgl. [Booch, Rumbaugh und Jacobson 2006, S. 432ff]

7.4 Lebenslinien

Während in populären Darstellungen (vgl. zum Beispiel [Balzert 2000, Abschnitt 4.4]) gleich von Objekten die Rede ist, die Nachrichten (bei den beiden Balzert: Botschaften) versenden oder empfangen, ist in den UML-Texten von lifelines als Trägern des Nachrichtenverkehrs die Rede.

Versender der Nachrichten

Lifeline

Wörtlich: Rettungsleine, fig. Lebensader im Sinne von Versorgungsweg, was hier wohl am besten passt. In diesem Buch wird die in [Booch, Rumbaugh und Jacobson 2006] vorgeschlagene Übersetzung Lebenslinie benutzt.

Eine Lebenslinie repräsentiert einen einzelnen Teilnehmer an der Interaktion. Dies kann ein beliebiger Classifier sein, also z.B. auch eine Instanz (ein Objekt) einer Klasse.

Grafische Darstellung

Eine Lebenslinie wird durch ein Rechteck und eine senkrechte gestrichelte Linie dargestellt. Das Rechteck bildet sozusagen den Kopf, darunter folgt die Linie (vgl. die folgende Abbildung). Die Linie repräsentiert - bei einer entsprechenden Darstellungstechnik (vgl. Sequenzdiagramme in Kapitel 11) - die Dauer der Existenz des Kommunikationsteilnehmers (also z.B. der Instanz einer Klasse).

Abbildung 7.4-1: Grafische Darstellung einer Lebenslinie

Diese Darstellung wird in Sequenzdiagrammen benutzt. In den in diesem Kapitel betrachteten Kommunikationsdiagrammen wird die gestrichelte Linie nicht benötigt.

Vgl. Kapitel 11

Im Rechteck wird also die Bezeichnung der Lebenslinie festgehalten. Diese besteht aus einer Zeichenfolge, die nacheinander folgende Elemente enthält:

  • Bezeichnung des verknüpfbaren Elements (so die Bezeichnung aller verknüpfbaren Elemente in der UML, zu der auch die Lebenslinien gehören).
  • Eine Auswahl (selector), falls nötig (vgl. unten).
  • Einen Doppelpunkt
  • Die Bezeichnung des Classifiers, meist also die Bezeichnung der Klasse.

Handelt es sich bei den Lebenslinien um Instanzen (Objekte) einer Klasse, wird die Bezeichnung unterstrichen, wie es für Instanzen üblich ist (vgl. Abschnitt 2.4.2).

Instanzen als Lebenslinien

Beispiele:

  • wire:Wire, left:Bead, right:Bead aus [Rumbaugh, Jacobson und Booch 2005, S. 243, Figure 14-64]
  • c:Controller, :Cache aus [Booch, Rumbaugh und Jacobson 2006, S. 259, Abbildung 16.4]
  • c:Kunde, p:ODBCProxy aus [Booch, Rumbaugh und Jacobson 2006, S. 295, Abbildung 19.1]

Lässt man die Bezeichnung des verknüpfbaren Elements weg, entstehen, in Anlehnung an den Begriff der anonymen Objekte, sog. anonyme Lebenslinien. Beispiele dafür:

Anonyme Lebenslinien

  • :Controller, :Window, :Line aus [Rumbaugh, Jacobson und Booch 2005, S. 243, Figure 14-64]
  • :OrderTaker, :TicketDB, :CreditBureau, aus [Rumbaugh, Jacobson und Booch 2005, S. 107, Figure 9-4]
  • c:View, aus [Booch, Rumbaugh und Jacobson 2006, S. 259, Abbildung 16.4]
  • :Transaktion aus [Booch, Rumbaugh und Jacobson 2006, S. 295, Abbildung 19.1]

Falls das zu verknüpfende Element mehrwertig ist (Wertigkeit größer 1), dann kann die Lebenslinie einen Ausdruck (den "selector") haben, der festlegt, welcher Teil durch die Lebenslinie repräsentiert wird. Liegt bei einer Wertigkeit größer als eins keine Auswahl vor, bedeutet das, dass ein beliebiger Repräsentant genommen wird.

Auswahl

Ist die Bezeichnung der Lebenslinie das Schlüsselwort self, dann repräsentiert die Lebenslinie das Objekt des Classifiers, das die Interaktion umfasst, zu der die Lebenslinie gehört [OMG 2003a, S 428].

Schlüsselwort self

7.5 Nachrichten

7.5.1 Definition

Im ersten Abschnitt dieses Kapitels wurden Nachrichten bereits vorgestellt. Zu ergänzen ist noch, dass Nachrichten eine Bezeichnung und Parameter haben. Die Bezeichnungen der Nachricht und der Methode zusammen mit den Ein- und Ausgabeparametern werden als Signaturbezeichnet.

Da es wie oben ausgeführt tatsächlich so ist, dass meist Objekte von Klassen Nachrichten aussenden und empfangen, reduzieren viele Autoren den Nachrichtenbegriff auch darauf.

In der UML wurde dieses Konzept übernommen, präzisiert und ergänzt. Hier ist eine Nachricht eine Kommunikation zwischen den Lebenslinien einer Interaktion. Dies kann sein:

UML-Sichtweise

  • Senden und Empfangen eines Signals
  • Aufruf einer Operation
  • Erzeugung oder Zerstörung einer Instanz

Die Nachricht legt nicht nur die Art der Kommunikation fest, sondern auch den Sender und den Empfänger.

Ergänzend wird in der UML ein Ereigniskonzept hinzugefügt. Ereignisse lösen einerseits die Nachrichten aus (beim Sender) und entstehen andererseits durch das Eintreffen der Nachricht beim Empfänger. Eine für Ablaufbeschreibungen naheliegende Ergänzung.

Ereigniskonzept

Die Bezeichnung der Nachricht spezifiziert das Ereignis [Grässle, Baumann und Baumann 2000, S. 211], die Argumente enthalten die Informationen, die der Nachricht mitgegeben werden, damit der Empfänger die geforderten Aktivitäten ausführen kann. Zu diesen Informationen gehören auch Kontroll- und Steuerungsinformationen.

In der UML kann eine Nachricht ein Signal oder der Aufruf einer Operation sein. Ein Signal kann als Empfänger auch mehrere Objekte haben, ein Operationsaufruf bezieht sich immer auf nur ein Objekt.

Unterschieden werden die Nachrichtentypen Call, Return, Send, Create und Destroy.

Die übersandten Nachrichten lösen typischerweise Aktivitäten aus und führen evtl. auch zur Übermittlung von Ergebnissen in der Antwort. So kann z.B. die Nachricht bestimmePosSu() (bestimme die Summe der Rechnungspositionen) an eine Klasse Rechnungspositionen zum Aufruf der entsprechenden Methode und zur Antwort mit dem berechneten Wert führen.

Rückgabewerte

Erhält ein Objekt einer Klasse eine Nachricht, führt es eine Operation aus. Im Rahmen der Ausführung dieser Operation ist es möglich, dass weitere Nachrichten erzeugt und versandt werden. Ein einfaches Beispiel zum Druck einer Rechnung ist unten angegeben. Wenn ein Objekt der Klasse Rechnungspositionen (bzw. RechPos) die Aufgabe erhält, die Rechnungspositionen zusammenzustellen, ruft es selbst eine Methode von Artikel auf.

Nachricht erzeugt Nachricht

7.5.2 Synchron und Asynchron

Nachrichten können synchron oder asynchron ausgetauscht werden. Dabei bedeutet ein synchroner Nachrichtenaustausch, dass der Sender wartet, bis der Empfänger den betreffenden Methodenaufruf beendet hat und erst dann wieder aktiv wird. In vollem Umfang, was eigene Verarbeitungsschritte angeht und was weitere auszusendende Nachrichten angeht.

Synchroner
Nachrichten-
austausch

Eine Operation, die durch eine synchrone Nachricht ausgelöst wurde, kann im Rahmen der Antwort Werte zurückgeben. Bei der Rückgabe erhält der Sender dann auch die Kontrolle (über den Kontrollfluss) zurück.

Asynchron dagegen bedeutet, dass das Senderobjekt mit seinem weiteren Tun nicht wartet, bis die aufgerufene Aktion durchgeführt ist, sondern gleich wieder irgendwelche Verarbeitungsschritte durchführen kann.

Asynchroner Nachrichten-
austausch

Gängige objektorientierte Programmiersprachen wie Java und C++ haben z.B. synchrone Operationsaufrufe. D.h., es existiert nur ein einziger Kontrollfluss, zu einem bestimmten Zeitpunkt wird immer nur eine einzige Anweisung ausgeführt.

Balzert führt aus, dass in Komponentenmodellen (wozu objektorientierte Modelle gehören) der synchrone Nachrichtenaustausch Standard ist, dass aber der asynchrone Austausch insbesondere in Verbindung mit Ereignissen sinnvoll ist, z.B. wenn die durch das Ereignis angesprochenen Empfänger nur informiert werden sollen [Balzert 2001, S.913].

Im Falle eines asynchronen Nachrichtenaustausches wird Nebenläufigkeitermöglicht. Dies ist, so [Booch, Rumbaugh und Jacobson 2006, S. 259] von großer Bedeutung "für die heutige Welt von nebenläufiger Verarbeitung".

Nebenläufigkeit

Exkurs: Einige einfache Beispiele

In der Datenübertragung: Erfolgt diese synchron, bleiben zeitliche Beziehungen zwischen den Daten bei der Übertragung erhalten. Dies ist z.B. notwendig bei der Übertragung von Filmen, weil da der zeitliche Abstand zwischen aufeinanderfolgenden Bildern wichtig ist. Bei einer asynchronen Datenübertragung müssen solche zeitlichen Bedingungen nicht streng eingehalten werden. Zum Beispiel bei einem File-Transfer.

Netze: Ein Beispiel für ein synchrones Netz ist das klassische Fernsprechnetz und das daraus abgeleitete ISDN-Netz. Ein Beispiel für ein asynchrones Netz ist das Internet.

7.5.3 Sequenznummern

Rumbaugh et al. weisen auf einen Schwachpunkt von Diagrammen hin, in denen einfach nur die auszuführenden Nachrichten vermerkt sind. Z.B. also bei einem Klassendiagramm, in dem die Nachrichten ergänzt wurden (vgl. Abbildung 7.7-2). In einem solchen Fall ist die Abfolge der Nachrichten (genauer: der Kontrollfluss) nur bei genauem Studium des Diagramms erkennbar, falls überhaupt. Das macht die Diagramme schwer lesbar. Deshalb geben sie die Abfolge der Nachrichten durch Sequenznummern (sequence numbers) an [Rumbaugh, Jacobson und Booch 2005, S. 241].

Keine zeitliche Dimension

Die Sequenznummern entsprechen einer Dezimalklassifikation, wie sie in Büchern oft verwendet wird (und auch in diesem Text). Die erste zu erfassende Nachricht erhält die Nummer 1, die zweite die Nummer 2, usw. Wird innerhalb der Abarbeitung von Nachricht 2 eine weitere aufgerufen, erhält diese die Nummer 2.1, eine weitere die Nummer 2.2, usw. Wird innerhalb der Ausführung der Operation von Nachricht 3 eine weitere Nachricht aktiviert (3.1) und sendet dieses im Rahmen ihrer Abarbeitung zwei Nachrichten aus, erhalten diese, gemäß ihrer Rangfolge, die Nummerierung 3.1.1 und 3.1.2.

Reihenfolge mit Hilfe der Dezimal-
klassifikation

Die Sequenznummern werden zusammen mit einem Doppelpunkt vor die Nachricht gesetzt. Z.B. also:

1: anfrageLagerbestand(anzahl)

1.1: abzählenWarengruppe()

2: berechnenGesamtsumme()

2.1: berechnenPositionssumme(anzahl, einzelpreis)

Dieses Konzept erlaubt also die Erfassung von Verschachtelungen, ein insgesamt doch sehr dürftiges Kontrollflusskonzept, das aber durch die zwei nachfolgenden Elemente (Wiederholung, Parallelität) etwas erweitert wird. Für die Vorbereitung der Programmierung gibt es aber zumindest Hinweise.

Syntax der Nachrichtenbezeichnung

Insgesamt ergibt sich dann folgender Aufbau für die Nachrichtenbezeichnung:

 

Sequenznummer attribut=Nachrichtenbezeichnung(Liste Parameter):Rückgabewert

 

Soll eine Nachricht wiederholt werden, kann dies in der Nachrichtenbezeichnung ausgedrückt werden. Dazu wird ein Stern (*) nach der Sequenznummer und vor der Nachrichtenbezeichnung eingetragen. Ein Beispiel ist die Nachricht bestimmtePos() an eine Klasse Rechnungspositionen, die so oft gesandt wird, bis alle Positionen abgearbeitet sind. Die wiederholte Ausführung kann auch genauer beschrieben werden, indem in eckigen Klammern eine Präzisierung erfolgt, z.B.

Schleife

*[i == 1..n]

Sogar eine parallele Ausführung kann angefordert werden. Dazu werden nach dem Stern zwei senkrechte Striche eingefügt:

Parallelität

*|| (vgl. [OMG 2003b, S. 447])

7.5.4 Grafische Darstellung

In der grafischen Darstellung objektorientierter Datenmodelle werden Nachrichten durch Pfeilsymbole zwischen den Sendern und Empfängern kenntlich gemacht. Die Richtung der Nachricht zeigt von der sendenden zur empfangenden Lebenslinie. Falls eine Rückantwort (vgl. unten) erfolgen soll, wird eine entsprechende Antwortnachricht modelliert. Die konkrete Gestaltung des Pfeils variiert:

  • Synchrone Nachrichtenwerden durch eine durchgezogene Pfeillinie und eine gefüllte Pfeilspitze gekennzeichnet.
  • Asynchrone Nachrichtenerhalten ebenfalls eine durchgezogene Pfeillinie sowie eine Pfeilspitze ohne Füllung (nur mit Strichen).
  • Eine Antwort auf eine synchrone Nachrichtwird durch eine gestrichelte Pfeillinie und eine Pfeilspitze ohne Füllung gekennzeichnet.

Abbildung 7.5-1: Grafische Darstellung von Nachrichten

7.6 Kommunikationsdiagramme

7.6.1 Definition

Jetzt kann endlich das neue Theorieelement vorgestellt werden. Ein Kommunikationsdiagramm erfasst den für eine Aufgabenerfüllung notwendigen Nachrichtenaustausch zwischen Lebenslinien (im einfachsten Fall: zwischen Objekten). Die Abfolge der Nachrichten wird durch Sequenznummern erfasst.

Aufgabenerfüllung durch Nachrichten-
austausch

Sequenzen und Sequenzdiagramme (vgl. [Staud 2019] Kapitel 11) erfassen bzw. beschreiben dieselbe Information, stellen sie nur unterschiedlich dar. Booch et al. weisen auf die Motive für die beiden Visualisierungen hin. Sequenzdiagramme betonen die zeitliche Reihenfolge der Nachrichten, während Kommunikationsdiagramme die strukturelle Organisation der Nachrichten sendenden Objekte in den Vordergrund stellen [Booch, Rumbaugh und Jacobson 1999, S. 243]. Ansonsten betonen sie aber die semantische Gleichwertigkeit der beiden Konzepte.

Hinweis: Kommunikationsdiagramme wurden in früheren UML-Versionen Kollaborationsdiagramme genannt.

Sequenz- und Kommunkationsdiagramme werden auch unter dem Begriff Interaktionsdiagramm zusammengefasst.

Interaktions-
diagramme

Innere Struktur

Die innere Struktur wird dargestellt, indem die Kompenten (z.B. die Objekte), ihre semantischen Verknüpfungen (z.B. die Assoziationen) und dann eben der für die jeweilige Aufgabe notwendige Nachrichtenaustausch angegeben wird. Da im Rahmen einer Aufgabenerfüllung die Komponenten (z.B. Objekte) meist spezifische Rollen einnehmen, wird hier das oben eingeführte Rollenkonzept verwendet.

Im Falle von Objekten entsteht also ein Kommunikationsdiagramm aus einem Klassendiagramm, in dem die Nachrichten mit Hilfe der oben eingeführten Pfeile vermerkt sind.

Fowler weist darauf hin, dass standardmäßig in der UML in Klassendiagrammen keine Nachrichten angezeigt werden [Fowler 2004, S. 107], dass dies aber möglich ist. Geschieht es, werden an den Seiten von Assoziationen Pfeile hinzugefügt, die mit dem Namen der Nachrichten beschriftet sind (wie oben gezeigt). Er weist außerdem darauf hin, dass für einen Nachrichtenverkehr nicht unbedingt eine Assoziation vorliegen muss (ebenda).

Standardmäßig keine Klassendiagramme

7.6.2 Grafische Darstellung

Die folgende Abbildung zeigt die grafische Darstellung von Kommunikationsdiagrammen. Sie kann nicht so allgemeingültig sein wie sonst, da es für die unterschiedliche Anzahlen von Komponenten und für die unterschiedliche innere Struktur keine Abstraktionsmöglichkeit gibt.

Hier das Beispiel dreier Objekte, die zusammenwirken. Objekt 1 sendet zwei Nachrichten, die Reihenfolge ist durch die Sequenznummern angegeben. Die zweite Nachricht wird wiederholt versendet. Beide Nachrichten haben Parameter und damit Argumente.

Abbildung 7.6-1: Darstellung von Kommunikationsdiagrammen (beispielhaft)

7.7 Beispiel Rechnungsdruck

Das folgende Kommunikationsdiagramm zeigt den (vereinfachten) Nachrichtenaustausch rund um den Druck einer Rechnung (vgl. auch das nachfolgende Klassendiagramm mit diesem Nachrichtenverkehr):

Schritt um Schritt zur Rechnung

  • (1) Nach Eingehen der Aufforderung, die Rechnung zu drucken, fordert die Lebenslinie RechnKöpfe (Rechnungsköpfe) von der Lebenslinie Kunden die Kundendaten an.
  • (2) RechnKöpfe hat eine Methode zur Erstellung der Rechnung. Diese fordert von RechnPos (Rechnungspositionen) solange die Positionsdaten (Positionsnummer, Artikelbeschreibung, Anzahl, Positionssumme) an, bis alle Positionen abgearbeitet sind.
  • (2.1) Lebenslinie RechnPos schickt jedesmal eine Nachricht zu Artikel mit der Aufforderung, die Artikelbezeichnung und den Einzelpreis des durch die Artikelnummer (artNr) identifizierten Artikels zu liefern.
  • (2.2) Anschließend berechnet RechnPos durch Aufruf einer seiner Methoden die gewünschten Angaben und liefert sie an RechnKöpfe zurück.
  • (3) RechnKöpfe bestimmt dann durch Aufruf einer seiner Methoden die Rechnungssumme, MWSt und eventuelle weitere auf die Gesamtrechnung bezogene Daten.
  • (4) Nach Einholen aller notwendigen Informationen und Beendigung aller Berechnungen erstellt RechnKöpfe mit Hilfe seiner Methode druckeRechnung() die Rechnung.

Auch wenn dieses Beispiel den Vorgang nur andeuten kann, sollte es doch das diesem Theorieelement zugedachte Modulierungsziel verdeutlichen: Aufgabenerledigung im Kleinen, im Gegensatz zu längeren Abläufen oder Geschäftsprozessen (vgl. dazu [Staud 2019]).

Abbildung 7.7-1: Kommunikationsdiagramm Rechnungsdruck

Die folgende Abbildung zeigt nun diesen Nachrichtenverkehr in einem Klassendiagramm. Die Elemente sind hier die ganz normalen Klassen des objektorientierten Modells, deren Bezeichnungen aus Gründen der Anschaulichkeit länger gewählt wurden. Zusätzlich zu den Nachrichten sind hier noch die Antworten angegeben.

Nachrichtenverkehr im
Klassendiagramm

Auch hier ist natürlich der Kontrollfluss auf das verschachtelte Aussenden der Nachrichten mit Wiederholung und Parallelität beschränkt und insofern von eingeschränkter Aussagekraft.

Die grafische Darstellung zeigt außerdem, dass auch diese Darstellung des kooperativen Miteinanders nur bei kleinen Modellen interpretierbar ist.

Abbildung 7.7-2: Nachrichtenverkehr im Klassendiagramm - am Beispiel Rechnungsdruck

8 Schlussbemerkung

Soweit die Modellierung der statischen Aspekte der Anwendungsbereiche durch die UML. Für Abläufe, Geschäftsprozesse, aufeinanderfolgende Handlungen, kurz: für die dynamischen Aspekte des jeweiligen Anwendungsbereichs liegen in der UML weitergehende Modellelelmente vor. Dies sind insbesondere

  • Aktionen
  • Aktivitäten
  • Sequenzen
  • Anwendungsfälle (use cases)
  • Zustandsautomaten

Vgl. dazu [Staud 2019] für eine umfassende Darstellung.

 

9 Literatur

Allweyer 2008
Allweyer, Thomas: BPMN. Business Process Modeling Notation. Einführung in den Standrd für die Geschäftsprozessmodellierung. Norderstedt 2008

Balzert 1998
Balzert, Helmut: Lehrbuch der Software-Technik. Softwarem-Management. Software-Qualitätssicherung. Unternehmensmodellierung. Heidelberg und Berlin 1998

Balzert 1999
Balzert, Heide: Lehrbuch der Objektmodellierung. Analyse und Entwurf, Heidelberg und Berlin 1999

Balzert 2000
Balzert, Heide: Objektorientierung in 7 Tagen. Vom UML-Modell zur fertigen Web-Anwendung. Heidelberg und Berlin 2000

Balzert 2001
Balzert, Helmut: Lehrbuch der Software-Technik. Software-Entwicklung (2. Auflage). Heidelberg und Berlin 2001

Booch, Rumbaugh und Jacobson 1999
Booch, Grady; Rumbaugh, James; Jacobson, Ivar: Das UML-Benutzerhandbuch. Bonn u.a. 1999

Booch, Rumbaugh und Jacobson 2006
Booch, Grady; Rumbaugh, James; Jacobson, Ivar: Das UML-Benutzerhandbuch. Aktuell zur Version 2.0, München u.a. 2006

Eriksson und Penker 2000
Eriksson, Hans-Erik; Penker, Magnus: Business Modeling with UML. Business Pattern at Work. New York u.a. 2000

Fowler 2004
Fowler, Martin: UML - konzentriert. Eine kompakte Einführung in die Standard-Objektmodellierungssprache. Bonn u.a. 2004

Fowler 2004
Fowler, Martin: UML konzentriert. Eine kompakte Einführung in die Standard-Objektmodellierungssprache. München u.a. 2004

Fowler und Scott 1998
Fowler, Martin; Scott, Kendall: UML - konzentriert. Die Standardobjektmodellierungssprache anwenden. Bonn u.a. 1998

Grässle, Baumann und Baumann 2000
Grässle, Patrick; Baumann, Henriette; Baumann, Philippe: UML projektorientiert. Geschäftsprozessmodellierung, IT-System-Spezifikation und Systemintegration mit der UML. Bonn 2000

Jeckle, Rupp, Hahn u.a. 2004
Jeckle, Mario; Rupp, Chris; Hahn, Jürgen; Zengler, Barbara und Queins, Stefan: UML 2 glasklar. München und Wien 2004

Kerner und Horn 1997
Kerner, Immo O.; Horn, Christian (Hrsg.): Lehr- und Übungsbuch Informatik. Band 3: Praktische Informatik. München und Wien 1997

King 1989
King, Roger: Object-oriented concepts, databases and applications, New York 1989

Marshall 2000
Marshall, Chris: Enterprise Modeling with UML. Designing Successful Software through Business Analysis. Reading (Mass.) u.a. 2000

Meier und Wüst 1997
Meier, Andreas; Wüst, Thomas: Objektorientierte Datenbanken. Ein Kompaß für die Praxis. Heidelberg 1997

Oestereich 1998
Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language (4. Auflage). München und Wien 1998

Oestereich 2004
Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der UML 2.0 (6. Auflage). München und Wien 2004

OMG 1999
Object Management Group: OMG Unified Modeling Language Specification, Version 1.3, June 1999

OMG 2003a
Object Management Group: UML 2.0 Superstructure Specification (Unified Modeling Language: Superstructure, version 2.0, final Adopted Specification, ptc/03-08-02), August 2003

OMG 2003b
Object Management Group: UML 2.0 Infrastructure Specification (Unified Modeling Language (UML) Specification: Infrastructure, version 2.0, ptc/03-09-15), Dezember 2003

OMG 2003c
Object Management Group: UML 2.0 OCL Specification (OCL 2.0 OMG Final Adopted Specification, ptc/03-10-14), Oktober 2003

OMG 2017
Object Management Group (OMG): OMG Unified Modeling Language (OMG UML). Version 2.5.1 December 2017. (OMG Document Number: formal/17-12-05. www.omg.org/spec/UML/About-UML/)

Prata 2005
Prata, Stephen: C++. Primer Plus (Fifth Edition). Indianapolis 2005

Ratz et al. 2018
Ratz, Dietmar; Schulmeister-Zimolong, Dennis; Seese, Detlef; Wiesenberger, Jan: Grundkurs Programmieren in Java (8. Auflage). München 2018

Rumbaugh, Jacobson und Booch 2005
Rumbaugh, James; Jacobson, Ivar; Booch, Grady: The Unified Modeling Language Reference Manual. Second Edition. Boston u.a. 2005

Schader und Rundshagen 1994
Schader, Martin; Rundshagen, Michael: Objektorientierte Systemanalyse. Eine Einführung, Berlin u.a. 1994

Smith und Smith 1977a
Smith, John Miles und Smith, Diane C.P.: Database Abstractions: Agregation. In: Communications of the ACM, June 1977, Volume 20, Number 6, S. 405 - 413

Smith und Smith 1977b
Smith, John Miles und Smith, Diane C.P.: Database Abstractions: Agregation and Generalization. In: ACM Transactions on Database Systems, Vol. 2, No. 2, June 1977, S. 105 - 133

Staud 2005
Datenmodellierung und Datenbankentwurf. Berlin u.a. 2005 (Springer-Verlag)

Staud 2006
Staud, Josef: Geschäftsprozessanalyse. Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware (3. Auflage). Berlin u.a. 2006 (Springer-Verlag)

Staud 2019
Staud, Josef Ludwig: Unternehmensmodellierung - Objektorientierte Theorie und Praxis mit UML 2.5. Berlin u.a. 2019 (Springer Verlag)

Staud 2021
Staud, Josef Ludwig: Relationale Datenbanken. Grundlagen, Modellierung, Speicherung, Alternativen. 2. Auflage 2021. Verlag tredition GmbH

Stein 1994
Stein, Wolfgang: Objektorientierte Analysemethoden. Vergleich, Bewertung, Auswahl, Mannheim u.a. 1994

Ullenboom 2022
Ullenboom, Christian: Java ist auch eine Insel. Einführung, Ausbildung, Praxis. (16. Auflage). Bonn 2022 (Rheinwerk-Verlag)