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äftsprozesse? |
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++ |
|
|
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: |
|
|
|
Ist die Benennung eines bestimmten Objekts nicht wichtig, nicht sinnvoll oder nicht möglich, wird die Objektbezeichnung weggelassen: |
|
|
|
Darunter folgen die Attribute mit der zur Instanz gehörenden Attributsausprägung: |
|
- Attributsbezeichnung = attributsausprägung
|
|
Z.B. |
|
|
|
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. |
Existenzabhä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) |
|
|
|
|
|
|