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ägerim 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 Eigenschaft ist. 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

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

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 Darstellung

Grafische und textliche Darstellung

2.4.1 Klassen

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

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

Die folgende Abbildung zeigt einige Beispiele.

Abbildung 2.4-1: Grafische Darstellung einer Objektklasse

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

Classifier

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

Die Attribute und Operationen werden textlich wie folgt angegeben:

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

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

Abbildung 2.4-2: Darstellung von Objektklassen mit Attributen

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

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

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

Bedeutung der Attribute und Methoden

Attribute (immer auf die einzelnen Angestellten bezogen):

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

Klassenattribute:

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

Methoden:

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

Klassenmethoden:

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

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

Voreinstellungen

ort: string = ‚Ravensburg’

plz: string = ‚D-88212’

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

2.4.2 Instanzen bzw. Objekte

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

• Objektbezeichnung:Klassenbezeichnung

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

• müller:Angestellte

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

• :Angestellte

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

• Attributsbezeichnung = attributsausprägung

Z.B.

• ort = München

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

Abbildung 2.4-4: Darstellung eines Objekts in Objektdiagrammen

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

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

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

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

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

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

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

2.5 Sichtbarkeit

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

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

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

abstrakte Klasse Window

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

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

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

2.6 Kapselung

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

Geschützte Attribute

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

Kapselung

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

Kapselung in objektorientierten Modellen

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

Information hidding

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

2.7 Beispiele

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

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

2.7.1 Hochschule

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

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

Studierende

Abbildung 2.7-1: Objektklasse Studierende

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

Dozenten

Abbildung 2.7-2: Objektklasse Dozenten

2.7.2 Angestellte eines Unternehmens

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

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

Angestellte

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

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

Abbildung 2.7-3: Anwendungsbereich Angestellte, Klasse Angestellte

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

Projekte

Abbildung 2.7-4: Anwendungsbereich Angestellte, Klasse Projekte

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

Personal Computer

Abbildung 2.7-5: Anwendungsbereich Angestellte, Klasse PC

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

Abteilungen

Abbildung 2.7-6: Anwendungsbereich Angestellte, Klasse Abteilungen

2.8 Vertiefung

2.8.1 Klassenbildung und Objektfindung

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

Klassenbildung bei Objektfindung

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

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

Objekte finden

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

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

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

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

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

Wohlunterscheid-
barer Gegenstand

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

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

Objektfindung durch Methoden

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

Durch Methoden zu Attributen

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

1:1-Abbildung

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

Keine Zerlegung

2.8.2 Identität und Gleichheit

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

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

Objektidentifizierer

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

Gleich und doch nicht identisch

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

Surrogat

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

2.8.3 Komplexe Objekte

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

Nicht-primitive Objekte

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

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

2.8.4 Eine ganz besondere Klasse - Classifier

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

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

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

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

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

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

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

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

Definition

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

Klassifizierte
Informationsträger

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

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

Ding

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

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

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

Grafische Darstellung

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

Rechteck mit Bezeichnung und Bereichen

Folgende weiteren Festlegungen gelten:

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

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

Classifier
Klasse

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

Hier noch ein Beispiel für die Darstellung vonUnterbereichen in Classi­fiern, 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.

2.9 Java-HS1

Dieses und die folgenden Projekte zeigen den elementaren Umgang mit Klassen, Objekten, Methoden. Dabei werden auch die dafür in Java notwendigen Programmierkonsstrukte bzgl. Eingaben, Ausgaben, usw. vorgestellt.

Java-Exkurs, Projekt HS1 (Hochschule 1)

Aufbau der Java-Beispiele

Der Aufbau dieser Projektbeschreibungen ist immer gleich: Zuerst das Hauptprogramm (Klasse HP), dann die inhaltlichen Klassen. Alle Programme werden mit Erläuterungen angegeben. In [Lesehilfe] findet sich auch eine Fassung ohne Erläuterungen zum Kopieren und für den schnellen Überblick. Im letzten Abschnitt wird, falls es sinnvoll ist, ein exemplarischer Programmlauf angegeben.

Zum Projekt - Klassen und Objekte

Hier in HS1 geht es schlicht darum, eine einfache Klasse Stud (Studierende) anzulegen, Objekte zu erzeugen und mit ihnen zu arbeiten. Die Klasse Stud beschreibt Studierende, ein weiterer Programmteil, sozusagen das Hauptprogramm (HP) beschreibt die dynamischen Aspekte, hier lediglich einige Handlungen mit den Objekten.

HP

Die Java-Erschaffer haben festgelegt, dass alle Programmelemente in Java-Programmen als Klassen angelegt werden müssen. Der gesamte Programmcode einer Anwendung ist also in Klassen gepackt, auch wenn dies manchmal keine Klassen im eigentlichen Sinn sind, wie schon das Beispiel hier mit dem Hauptprogramm ("main") und seinem Ablauf zeigt.

Das erste Beispiel (HS steht für Hochschule) zeigt eine schlanke Fassung der obigen Klasse zu Studierenden. Sie wird Stud genannt.

Abbildung 2.9-1: Klasse Stud (Studierende) aus Projekt HS1

Diese Klasse hat die angeführten Attribute, den Standardkonstruktor und eine Methode ausgeben() zum Ausgeben der Daten jeweils eines Objekts auf dem Bildschirm. Außerdem ein Klassenattribut, in dem die Anzahl der Objekte der Klasse festgehalten wird. Mit public vor der Deklaration der Attribute wird festgelegt, dass die jeweiligen Attribute und Methoden allen übrigen Klassen zur Verfügung stehent. Insgesamt gibt es in Java folgende Ausprägungen dieser Sichtbarkeit, wie dies auch genannt wird:

• Public
• Package-private
• Private
• Protected

Vgl. zu den Definitionen der UML Abschnitt 2.5, zur Umsetzung in Java [Lesehilfe 4.1.2].

2.9.1 Klasse HP

In der objektorientierten Programmierung mit Java braucht man zusätzlich zu den durch die Semantik und die Programmrealisierung festgelegten Klassendefinitionen noch eine Klasse für den Start des Programms. Hier public class HP. In dieser muss sich das Hauptprogramm (public static void main(String[] args)) befinden.

Nun zu den Programmen. Siehe Lesehhilfe Java-Programme, Projekt HS1 für weitere Erläuterungen und eine Programmversion ohne Erläuterungen.

Gleich zu Beginn wird ein Objekt erzeugt, s0 ("s" steht für Student/in). Dabei wird der Standardkonstruktor verwendet. In der Klasse Stud ist zu sehen, dass es möglich ist, dem Standardkonstruktor ein Klassenattribut mit einer Wertezuweisung zuzuordnen.

Nacheinander werden vier unterschiedliche Konstruktoren, die in der Klasse Stud angelegt sind, eingesetzt. Java wählt jeweil den geeigneten aus. D.h.: Eine Klasse kann verschiedene Konstruktoren besitzen.

Konstruk-
toren

Programm HP

package hochschule;

public class HP {

Oben: Auch das jeweilige Hauptprogramm (HP / main) muss in eine Klasse gepackt sein, vgl. die Anmerkung oben.

  public static void main(String[] args) {

  Stud s0 = new Stud();

Objekt s0 wird mit dem Standardkonstruktor erzeugt (instanziiert) und mit dem Klassenattribut anzStud (Anzahl Studierende). Vgl. Klasse Stud.

  System.out.println("s0 ohne Daten, nach Instanziierung:\n");

  s0.ausgeben();

Zur Veranschaulichung die Ausgabe der Objektdaten: Nach der Instanziierung sind die Attribute mit Default-Werten beschrieben. Das Klassenattribut anzStud hat den Wert 1. Unten wird gezeigt, dass der Werte des Klassenattributs bei jeder Instanziierung um 1 erhöht wird.

  Stud s1 = new Stud();

  System.out.println("");

  System.out.println("s1 ohne Daten, nach Instanziierung:\n");

  s1.ausgeben();

Dasselbe wie oben, jetzt für das zweite Objekt s1. Das Klassenattribut hat jetzt den Wert 2.

  s0.mNr = 12345;

  s0.name = "Sauer";

  s0.vName = "Otto";

  s0.anzSem = 5;

  s0.gebTag = "21.09.2002";

Objekt s0 wird beschrieben. Dies ist einfach. Objekt- und Attributsbezeichnung identifizieren den konkreten Informationsträger, ansonsten Zuweisung wie bei Attributen.

  System.out.println("");

  System.out.println("s0 beschrieben:\n");

  s0.ausgeben();

Das Objekt s0 wird mit der Instanzmethode ausgeben() aus der zum Projekt gehörenden Klasse Stud auf der Konsole ausgegeben. Innerhalb desselben Projekts genügt der Aufruf ohne Klassenangabe.

Bei jedem Aufruf der Methode wird der Werte des hochgezählten Attributs anzStud ausgegeben. Siehe Programmlauf.

  s1.mNr = 98765;

  s1.name = "Widder";

  s1.vName = "Andrea";

  s1.anzSem = 2;

  s1.gebTag = "2.7.2005";

  System.out.println("");

  System.out.println("s1 beschrieben:\n");

  s1.ausgeben();

Auch das Objekt s1 wird beschrieben und ausgegeben.

  Stud s2 = new Stud(1111, "Maier", "Klara", 5, "21.09.2002");

  System.out.println("\ns2 mit Daten vom Konstruktoraufruf:\n");

  s2.ausgeben();

Nun der zweite Konstruktor, siehe Klasse Stud. Hier werden alle Attribute in der Parameterliste beschrieben.

  Stud s3 = new Stud(1111, "Maier", "Klara");

  System.out.println("\ns3 mit teilweisen Daten vom Konstruktoraufruf:\n");

  s3.ausgeben();

Der dritte Konstruktor erhält nur einen Teil der Attributsausprägungen über die Parameterliste: mNr, name, vName. Für die übrigen nimmt er die Standardwerte null, false bzw. 0.

Java entscheidet aufgrund des Konstruktoraufrufs, hier auf Basis der Parameterliste, welcher der Konstruktoren aus der Klasse Stud verwendet wird.

    }

}

2.9.2 Klasse Stud

package hochschule;

public class Stud {

Oben: Beginn der Klassendefinition

  public int mNr; //Matrikelnummer

  public String name;

  public String vName; //Vorname

  public int anzSem; //Erreichtes Semester

  public String gebTag; //Geburtstag

Inhaltliche Attribute zur Beschreibung der Objekte (Instanzen). Diese werden auch Instanz

  static int anzStud = 0;

Definition eines Klassenattributs (statisches Attribut) mit Anfangswert. Static fixiert die Unveränderlichkeit, int legt den Datentyp fest und anzStud = 0 einen Anfangswert.

  public Stud () {

    anzStud++;

  }

Aufruf Konstruktor 1. Der Standardkonstruktor trägt Standardwerte in die Attribute des Objekts ein (o, null, false). Ergänzt hier durch den Wert des Klassenattributs anzStud (Zähler für die Objekte der Klasse).

  public Stud (int mNr, String name, String vName, int anzSem, String gebTag) {

    this.mNr =mNr;

    this.name =name;

    this.vName = vName;

    this.anzSem = anzSem;

    this.gebTag = gebTag;

    anzStud++;

  }

Aufruf Konstruktor 2, siehe Klasse Stud. Hier werden alle Attribute in der Parameterliste beschrieben

  ::ii::Konstruktor mit Parameterliste::j::

  public Stud (int mNr, String name, String vName) {

    this.mNr =mNr;

    this.name =name;

    this.vName = vName;

    anzStud++;

  }

Aufruf Konstruktor 3, siehe Klasse Stud. Dieser legt nur einen Teil der Attributsausprägungen in der Parameterliste fest: mNr, name, vName. Für die übrigen nimmt er die Standardwerte null bzw. 0.

  void ausgeben() {

    System.out.println("Matrikelnummer: " + mNr);

    System.out.println("Name: " + name);

    System.out.println("Vorname:" + vName);

    System.out.println("Erreichtes Semester: " + anzSem);

    System.out.println("Geburtstag: " + gebTag);

    System.out.println("Anzahl Studierende: " + anzStud);

    }

}

Instanzmethode zum Ausgeben der Daten eines Objekts. Das Klassenattribut anzStud gibt jeweils an, wieviele Objekte angelegt sind. Vgl. Programmlauf.

  }

}

2.9.3 Programmlauf

s0 ohne Daten, nach Instanziierung:

Matrikelnummer: 0

Name: null

Vorname:null

Erreichtes Semester: 0

Geburtstag: null

Anzahl Studierende: 1

s1 ohne Daten, nach Instanziierung:

Matrikelnummer: 0

Name: null

Vorname:null

Erreichtes Semester: 0

Geburtstag: null

Anzahl Studierende: 2

s0 beschrieben:

Matrikelnummer: 12345

Name: Sauer

Vorname:Otto

Erreichtes Semester: 5

Geburtstag: 21.09.2002

Anzahl Studierende: 2

s1 beschrieben:

Matrikelnummer: 98765

Name: Widder

Vorname:Andrea

Erreichtes Semester: 2

Geburtstag: 2.7.2005

Anzahl Studierende: 2

s2 mit Daten vom Konstruktoraufruf:

Matrikelnummer: 1111

Name: Maier

Vorname:Klara

Erreichtes Semester: 5

Geburtstag: 21.09.2002

Anzahl Studierende: 3

s3 mit teilweisen Daten vom Konstruktoraufruf:

Matrikelnummer: 1111

Name: Maier

Vorname:Klara

Erreichtes Semester: 0

Geburtstag: null

Anzahl Studierende: 4

2.10 Java-HS2

Java-Exkurs, Projekt HS2

Hier werden zwei Objekte (stud0 und stud1) eingerichtet und mit Ihnen umgegangen. Es soll deutlich werden, dass bei einer Vorgehensweise wie hier ein Objekt das aktive ist. Um den Umgang mit dem Programm zu vereinfachen, werden gleich zwei Objekte angelegt, mit denen dies geprüft werden kann. Es gibt ein Konsolenmenü ...

1 = Eingabe

2 = Ausgabe

3 = Aktives Objekt wechseln

4 = Programm beenden

... mit einer grafischen Eingabe per JOptionPane.showInputDialog (siehe Programmlauf).

Da im Programm schon zwei Objekte angelegt sind, kann der Punkt 3 gleich ausprobiert werden. Dazu wird zuerst 2 angefordert, was zur Anzeige des aktiven Objekts führt. Dann wird mit 3 das Objekt gewechselt und wiederum mit 2 das jetzt aktive Objekt angezeigt.

Mit 1 können neue Objekte eingegeben werden, die dann jeweils das aktive sind. Wie zu sehen ist, werden immer nur zwei Objekte bereitgehalten. Mehr dazu unten.

2.10.1 Klasse HP

package hochschule;

import javax.swing.JOptionPane;

Oben: Anmelden der Klasse javax.swing für die grafische Eingabe.

public class HP {

  public static void main(String[] args) {

    String eingabe;

    Stud stud0 = new Stud();

    Stud stud1 = new Stud();

Erzeugen zweier Objekte mit dem Standardkonstruktor.

    Stud stud = stud0;

Weiteres Objekt, mit Referenzcharakter.

    //Daten zum Testen:

    stud0.matrikelNr = "12345";

    stud0.name = "Erster";

    stud0.vName= "Paul";

    stud0.plz = "7878";

    stud0.ort="Weingarten";

    stud0.strasse="Hinterm Berg";

    stud0.hausnummer=99;

    stud1.matrikelNr = "12345";

    stud1.name = "Zweite";

    stud1.vName= "Viola";

    stud1.plz = "8989";

    stud1.ort="Ravensburg";

    stud1.strasse="Hauptstr.";

    stud1.hausnummer=88;

Oben: Damit nicht gleich zum Ausprobieren Daten eingegeben werden müssen, werden stud0 und stud1 mit Daten beschrieben. So ist es möglich, gleich nach dem Start die Ausgabe mit dem aktiven Objekt anzufordern (es kommt stud0), dann mit Punkt 3 das aktive Objekt zu wechseln (auf 1) und dieses wieder auszugeben. Das ist dann stud1.

    System.out.println("Eingabe von Daten in die ");

    System.out.println("Studierendendatei");

    System.out.println("-------------------------------");

Überschrift zur Konsolenausgabe

    boolean fertig = false;

  while (!fertig) {

Beginn einer While-Schleife. Ende siehe am Programmende.

    System.out.println(" ");

    System.out.println("1 = Eingabe");

    System.out.println("2 = Ausgabe");

    System.out.println("3 = Aktives Objekt wechseln");

    System.out.println("4 = Programm beenden");

Menüauswahl auf Konsole. Anzeige siehe unten. Die Anforderung einer Leerzeile mit System.out.println(" ") wird unabhängig vom konkreten Betriebssystem realisiert, ist also plattformübergreifend.

    eingabe = JOptionPane.showInputDialog("Ihre Wahl");

Einlesen der Eingabe in die String-Variable Eingabe. Zur grafischen Eingabemaske siehe Programmlauf.

    int auswahl = Integer.parseInt(eingabe);

Die String-Variable eingabe wird in einen Integer-Wert gewandelt ("parseInt") und in die Integer-Variable auswahl geschrieben.

    System.out.println("\nEingegeben wurde: " + auswahl + "\n");

      switch(auswahl) {

Verzweigung mit switch auf Basis der Nutzereingaben, die in Integerwerte gewandetl wurden.

        case 1:

        eingabe = JOptionPane.showInputDialog("Matrikelnummer:");

        stud.matrikelNr = eingabe;

        eingabe = JOptionPane.showInputDialog("Name:");

        stud.name = eingabe;

        eingabe = JOptionPane.showInputDialog("Vorname:");

        stud.vName = eingabe;

        eingabe = JOptionPane.showInputDialog("Postleitzahl:");

        stud.plz = eingabe;

        eingabe = JOptionPane.showInputDialog("Ort:");

        stud.ort = eingabe;

        eingabe = JOptionPane.showInputDialog("Straße:");

        stud.strasse = eingabe;

        eingabe = JOptionPane.showInputDialog("Hausnummer: ");

        stud.hausnummer = Integer.parseInt(eingabe);

        break;

Studierendendaten eingeben. Bespielt wird Objekt stud. Es erfolgt jeweils eine grafische Anzeige der Eingabeaufforderung (vgl. unten) und das Spielen der Nutzereingabe in die String-Variable eingabe. Diese wird in das entsprechende Objektattribut geschrieben. Für die Hausnummer wurde die Umwandlung des Strings in eine Integerzahl vorgenommen (mit parseInt).

break: Wird für jede Case-Variante verlangt. Damit wird die Switch-Verzweigung verlassen.

      case 2: // Studierendendaten ausgeben

        System.out.println(stud.matrikelNr);

        System.out.println(stud.vName + " " + stud.name);

        System.out.println(stud.plz + " " + stud.ort);

        System.out.println(stud.strasse + " " + stud.hausnummer);

        break;

Diese Wahl führt zur Ausgabe der Studierendendaten des jeweils "aktiven" Objekts.

      case 3:

Hier sollen die Daten der zwei Objekte getauscht werden.

        eingabe = JOptionPane.showInputDialog("Welcher Student (0 oder 1)?");

        int nr = Integer.parseInt(eingabe);

        if (nr == 0) {

        stud = stud0;

stud0 wird auf stud gespielt - nur REFERENZ

        } else if (nr ==1) {

        stud = stud1; //stud1 wird auf stud gespielt

        } else {

        System.out.println("Eingabefehler!");

        }

        System.out.println("\nAktives Objekt wurde geändert!\n");

        break;

Einfaches Beispiel für die Arbeit mit Objekten. Jeweils ein Objekt soll das aktive sein. Dieses wird mit stud verknüpft, d.h. stud stellt einen Verweis auf das ausgewählte Objekt dar.

      case 4: // Programm beenden

        fertig = true;

Bei Eingabe der Zahl 4 wird das Programm beendet.

        break;

      default:

        System.out.println("Eingabefehler!");

      }

    }

Ende der While-Schleife.

  }

Ende des Hauptprogramms.

}

Ende des Programms

2.10.2 Klasse Stud

package hochschule;

public class Studierende {

  public String matrikelNr; //Instanzvariablen

  public String name;

  public String vName;

  public String plz;

  public String ort;

  public String strasse;

  public int hausnummer;

}

2.10.3 Beispielhafter Programmlauf

Nach dem Start des Programms erscheint das Konsolenmenü und die grafische Eingabeaufforderung. Hier wurde, wie oben vorgeschlagen, zuerst 2 angefordert, dann mit 3 zum Objekt 1 gewechselt, dann wieder 2 angefordert.

Folgende zwei Eingabemasken sind eingebaut:

Der Programmlauf:

Eingabe von Daten in die

Studierendendatei

-------------------------------

1 = Eingabe

2 = Ausgabe

3 = Aktives Objekt wechseln

4 = Programm beenden

Eingegeben wurde: 2

12345

Paul Erster

7878 Weingarten

Hinterm Berg 99

1 = Eingabe

2 = Ausgabe

3 = Aktives Objekt wechseln

4 = Programm beenden

Eingegeben wurde: 3

Aktives Objekt wurde geändert!

1 = Eingabe

2 = Ausgabe

3 = Aktives Objekt wechseln

4 = Programm beenden

Eingegeben wurde: 2

23456

Viola Zweite

8989 Ravensburg

Hauptstr. 88

1 = Eingabe

2 = Ausgabe

3 = Aktives Objekt wechseln

4 = Programm beenden

2.11 Java-HS5

Java-Exkurs, Projekt HS5

Hier werden mit java.util.Scanner Konsoleneingaben (Integerwerte und Strings) gelesen. Vgl. Abschnitt 4.1. Dann wird ein Objekt erzeugt und mit den eingelesenen Daten bespielt. Mithilfe der Instanzmethode ausgeben() aus Stud.java wird dann dieses Objekt auf dem Bildschirm angezeigt. Abschließend wird das Hochzählen einer Klassenvariablen demonstriert.

Zusammengefasst:

• Konsoleneingaben mit java.utilScanner
• Klassenattribut
• Konstruktor mit Klassenattribut
• Instanzmethode

Bitte die Beispielprogramme nicht falsch verstehen: Hier werden aus didaktischen Gründen und wegen der Übersichtlichkeit die Eingaben nicht auf syntaktische Korrektheit kontrolliert. Das geht natürlich im realen Programmierer/innen-Leben nicht! Da wird jede Eingabe auf syntaktische und - soweit möglich - semantische Korrektheit geprüft.

2.11.1 Klasse HP

package hochschule;

import java.util.Scanner;

Oben: Importieren der Klasse für das Einlesen von der Konsole mit den Methoden nextLine() und nextInt().

public class HS5 {

  public static void main(String[] args) {

    System.out.println("Objekt eingeben (j/n): ");

    String s = new java.util.Scanner(System.in).nextLine();

Frage und Antwort von der Konsole.

    switch(s) {

Klassisches Switch-Programmierkonstrukt (für Verzweigungen).

      case "j":

Falls oben "j" eingegeben wurde, wird dieser Block bearbeitet.

        System.out.println("Eingabe:");

        System.out.print("Matrikelnummer: ");

        int mNr = new java.util.Scanner(System.in).nextInt();

Das Einlesen eines Integer Werts erfolgt mit der Methode nextInt().

        System.out.print("Name: ");

        String name = new java.util.Scanner(System.in).nextLine();

Das Einlesen einer Zeile mit einer Zeichenkette erfolgt mit der Methode nextLine().

        System.out.print("Vorname: ");

        String vName = new java.util.Scanner(System.in).nextLine();

        System.out.print("Aktuelles Semester: ");

        java.util.Scanner scanner = new java.util.Scanner(System.in);

        int anzSem = scanner.nextInt();

Der Befehl String vName = new java.util.Scanner(System.in).nextLine() erzeugt in Ecliopse eine Warnung ("unassigned closeable value"). Die Aufspaltung wie hier oben vermeidet diese Fehlermeldung. Dabei werden das Einlesen und das Zuweisen in das Attribut getrennt.

        System.out.print("Geburtstag: ");

        String gebTag = new java.util.Scanner(System.in).nextLine();

        Stud s100 = new Stud();//neues Objekt erzeugen

        s100.mNr = mNr;

        s100.name = name;

        s100.vName = vName;

        s100.anzSem = anzSem;

        s100.gebTag = gebTag;

Anlegen des Objekts s100 und Bespielen mit den von der Konsole eingelesenen Werten.

        System.out.println("\n-----Objekt mit externer Methode anzeigen:");

        System.out.println("");

        s100.ausgeben();

Anzeigen der Werte von s100 mit der Instanzmethode ausgeben() aus der Klasse Stud.

        break;

      default: System.out.println("Abbruch");

Falls zu Beginn nicht "j" eingegeben wurde.

        break;

Jede Verzweigung mit case braucht am Schluss diesen Befehl;

      }

  }

}

2.11.2 Klasse Stud

package hochschule;

public class Stud {

  public int mNr; //Matrikelnummer

  public String name;

  public String vName;

  public int anzSem; //Erreichtes Semester

  public String gebTag; //Geburtstag

  static int anzStud = 0;

Oben: Klassenattribut/statisches Attribut anzStud mit Anfangswert.

  public Stud () {

    anzStud++; //Zähler für Klassenattribut

  }

Konstruktor mit Klassenattribut als Zähler. Bei jedem Aufruf wird er um 1 höher gesetzt.

  void ausgeben() {

    System.out.println("Matrikelnummer: " + mNr);

    System.out.println("Name: " + name);

    System.out.println("Vorname:" + vName);

    System.out.println("Erreichtes Semester: " + anzSem);

    System.out.println("Geburtstag: " + gebTag);

  }

Methode zum Ausgeben der Daten eines Objekts.

}

2.11.3 Beispielhafter Programmlauf

Objekt eingeben (j/n):

j

Eingabe:

Matrikelnummer: 12345

Name: Studer

Vorname: Guiseppe

Aktuelles Semester: 8

Geburtstag: 21.9.2000

-----Objekt mit externer Methode anzeigen:

Matrikelnummer: 12345

Name: Studer

Vorname:Guiseppe

Erreichtes Semester: 8

Geburtstag: 21.9.2000

Der Programmlauf zeigt, dass die Dateneingabe mit java.util.Scanner recht schlicht ist. Deshalb werden hier in den weiteren Programmen noch andere Vorgehensweisen demonstriert.

2.12 Java-HS3

Java-Exkurs, Projekt HS3

Hier werden mehrere Objekte mit zufallsgenerierten fiktiven Daten erzeugt. Damit man nicht die Objekte einzeln im Progamm generieren muss und um diese Programmiertechnik zu demonstrieren, wird ein Array zu Hilfe genommen, in dem die Objekte per Programm angelegt werden. Ein solches Array wird auch komplexes Objekt genannt.

Realisiert wird dies hier durch folgende Befehle:

Stud[] studiosi;

studiosi = new Stud[ianz]; //ianz: Anzahl der Objekte

Die Kurzfassung für diese beiden Befehle ist:

Stud[] studiosi = new Stud[ianz];

Die Bedeutung ist wie folgt. Es geht um die Klasse Stud. Mit ...

Stud[] studiosi;

... wird bzgl. der Klasse Stud ein Array angefordert, das die Bezeichnung studiosi haben soll.

Mit ...

Studiosi = new Stud[ianz];

... wird ein Array eingerichtet mit "Leerobjekten" (vgl. unten).

Nun zum Programm

Im Programm HP wird zuerst gefragt, wieviele Objekte generiert werden sollen, dann wird ein Array mit dieser Länge angelegt. In diesem werden dann gleich viele Objekte mit Leereinträgen erstellt. Diese haben die Attributsausprägungen 0 (für numerische Instanzvariablen), null (für Strings) und false (für boolesche Attribute). Damit liegt also ein Array mit Objekten vor. Wenn es 5 Objekte sind, haben diese die Nummerierungen 0 bis 4 und die Adressen studiosi[i] für i gleich 0 bis 4. Über diese Array-Adresse können die Objekte angesprochen werden.

Für die zu generierenden Objekte liegen zwei String-Arrays vor, einer mit 20 Nachnamen, einer mit 20 Vornamen. Auf deren Basis werden mit Hilfe der Methode java.util.Random() zufällige Namen und Vornamen erzeugt. Auch die übrigen Attributsausprägungen werden zufällig generiert.

Neue Aspekte sind hier also:

• Erzeugen eines Arrays aus Objekten (komplexes Objekt)
• Nutzung der Methode Random

In diesem einführenden Beispiel wird wie immer hier nicht die Eingabe und die "Tiefensemantik" kontrolliert. Z.B. könnte das Programm zwei gleiche Matrikelnummern erzeugen.

2.12.1 Klasse HP

package hochschule;

import java.util.Random;

Oben: Klasse Random hinzuziehen für die Erzeugung von Zufallszahlen.

import javax.swing.JOptionPane;

Klasse für die Methode JOptionPane.showInputDialog(). Sie stellt Methoden für die grafische Eingabe zur Verfügung.

public class HP {

public static void main(String[] args) {

  System.out.println("---Objekte mit generierten Daten anlegen\n");

  String eingabe;

  int ianz;

  eingabe = JOptionPane.showInputDialog("Wieviele Objekte (maximal 100):");

  ianz = Integer.parseInt(eingabe);

Erfragen der Anzahl Objekte, d.h. der gewünschten Länge des Array. Um den String eingabe in eine Integerzahl zu wandeln wird parseInt eingesetzt.

  System.out.println("Anzulegende Objekte: " + ianz);

  System.out.println();

  Stud[] studiosi = new Stud[ianz];

Der Konstruktoraufruf new Stud[ianz] führt zu einem Feld (array) der gewünschten Länge mit "Leer-Objekten".

studiosi : Feld von Objekten

  String[] namen = {"Ritter", "Knecht", "Maier", "Müller", "Stauder", "Siskor", "Oduro", "Picarda", "Ricker", "Maistro", "Müller", "Studer", "Saskor", "Podur", "Prickel", "Ricker", "Bond", "Jones", "Riker", "Nobel"};

  String[] vornamen = {"Paul", "Frieder", "Angelika", "Karolin", "Xian", "Ezri", "Jadzia", "Miriam", "Elfriede", "Josef", "Guiseppe", "Angie", "Frieda", "Andrea", "Karolin", "Ludwig", "Ricardo", "Andrea", "Lisa", "Friedrich"};

Anlage zweier Zeichenketten mit Namen und Vornamen, die im Programm zufällig in den Objekten zusammengestellt werden. Jeweils 20 Nachnamen und 20 Vornamen.

  for (int i=0; i< studiosi.length; i++) {

  studiosi[i] = new Stud();

  }

Zuerst einmal werden in der gewünschten Anzahl "leere" Objekte erzeugt.

  System.out.print("Inhalte generieren und Objekte ausgeben\n");

  var r = new Random();

Ein neues Objekt r der Klasse Random wird erzeugt.

  int nr = 0;

  while (nr >= 0 amp;amp; nr < studiosi.length amp;amp; nr <= ianz) {

In dieser While-Schleife werden die Objekte mit zufällig generierten Attributsausprägungen bespielt.

    System.out.println();

    System.out.print("Objekt nr = " + nr);

    //Matrikelnummer

    int mNr = r.nextInt(10000, 20000);

    studiosi[nr].mNr = mNr;

Die Matrikelnummern sollen zwischen den obigen zwei Werten liegen. Um bei diesem Zufallsprozess zwei gleiche zu verhindern, müsste eine entsprechende Kontrolle eingefügt werden.

    //Namen

    int tt = r.nextInt(20);

    String name = namen[tt];

    studiosi[nr].name = name;

Der Nachnamen wird zufällig aus dem String-Array namen bestimmt.

    //Vornamen

    int tu = r.nextInt(20);

    String vName = vornamen[tu];

    studiosi[nr].vName = vName;

Der Vorname wird zufällig aus dem String-Array vornamen bestimmt.

    //Semesteranzahl

    int ii = r.nextInt(1, 20);

    studiosi[nr].anzSem = ii;

Generierung einer zufälligen Semesteranzahl.

    //Datum generieren

    //Monat

    int monatber = r.nextInt(12);

Generierung eine zufälligen Monats für das Geburtsdatum.

  //Tag

  int tagber = 0;

  if (monatber == 2) {

  tagber = r.nextInt(1, 29);

  } else if ((monatber == 1) || (monatber == 3) || (monatber == 5) || (monatber == 7) || (monatber == 10) || (monatber == 12)) {

  tagber = r.nextInt(1, 30);

  }

  else {

  tagber = r.nextInt(1, 31);

  }

In diesen einführenden Beispielen wurden die Eingaben nicht kontrollliert und die "Tiefensemantik" (z.B. der Datumsangaben) nicht kontrolliert. Ein klein wenig geschah es dann oben doch.

  //Jahr

  int jahrber = r.nextInt(1995, 2007);

  String monats = monatber + ".";

  String jahrs = jahrber + " ";

  String tags = tagber + ".";

  studiosi[nr].gebTag = tags + monats + jahrs;

  System.out.println();

  studiosi[nr].ausgeben();//Methode in Klasse Stud

  nr++;

  }

System.out.println("\nAnzahl Studierende: " + Stud.anzStud + "\n");

  }

}

2.12.2 Klasse Stud

package hochschule;

public class Stud {

  public int mNr; //Matrikelnummer

  public String name;

  public String vName;

  public int anzSem; //Erreichtes Semester

  public String gebTag; //Geburtstag

  static int anzStud = 0;

Klassenattribut/statisches Attribut mit Anfangswert

  public Stud () {

  anzStud++; //Zähler für Klassenattribut

  }

Konstruktor

  void ausgeben() {

    System.out.println("Matrikelnummer: " + mNr);

    System.out.println("Name: " + name);

    System.out.println("Vorname:" + vName);

    System.out.println("Erreichtes Semester: " + anzSem);

    System.out.println("Geburtstag: " + gebTag);

    }

}

Methode zum Ausgeben der Daten eines Objekts

2.12.3 Programmlauf

Hier wurden drei Objekte angefordert.

---Objekte mit generierten Daten anlegen

Anzulegende Objekte: 3

Inhalte generieren und Objekte ausgeben

Objekt Nr = 0

Matrikelnummer: 17591

Name: Saskor

Vorname:Jadzia

Erreichtes Semester: 17

Geburtstag: 27.10.2006

Objekt Nr = 1

Matrikelnummer: 16863

Name: Ricker

Vorname:Miriam

Erreichtes Semester: 14

Geburtstag: 13.3.2005

Objekt Nr = 2

Matrikelnummer: 15464

Name: Oduro

Vorname:Ezri

Erreichtes Semester: 3

Geburtstag: 20.0.2002

Anzahl Studierende: 3

2.13 Java-HS8

Java-Exkurs, Projekt HS8

Bisher wurden in den Projekten alle Attribute und Methoden mit dem Sichtbarkeitsmodifizierer Public versehen. Hier nun ein erster und kleiner Schritt zu den übrigen Modifizieren. Vgl. zu Modifizierern in Java [Lesehilfe, Abschnitt 4.1.2], in der UML Abschnitt 2.5 dieses Textes. Ein weiteres Beispiel hierzu findet sich in Projekt HS7 im Kontext einer Vererbungshierarchie.

Die Möglichkeit, Daten und Methoden zu verbergen (Kapselung, encapsulation), ist tief in der objektorientierten Theorie verankert. Sie war sogar gleich am Anfang bei der Motivierung dabei: Die (damalige) Offenheit meist relationaler Datenbanken gegenüber unberechtigten Zugriffen (Eintragen, Löschen, Ändern) sollte überwunden werden. Nur die jeweils Berechtigten erhalten bei einer objektorientierten Datenbank Zugriffsmöglichkeiten. Dies gilt auch für Programme. Auch hier soll der geschickte Einsatz der Sichtbarkeitsmodifizierer für mehr Sicherheit sorgen.

Kapselung

2.13.1 Klasse Stud

Hier soll mit der Klasse Stud begonnen werden. Ihre Klassendefinition weist bei den Attributen die Sichtbarkeitsmodifizierer Private, Protected und Paketsichtbar auf.

package hochschule;

  public class Stud {

    private String mNr; //Matrikelnummer

    protected String name;

    String vName; //Modifizierer Paketsichtbar

    private int anzSem; //Erreichtes Semester

    public String gebTag; //Geburtstag

    public Stud (String mNr, String name, String vName, int anzSem, String gebTag) {

      this.mNr = mNr;

      this.name =name;

      this.vName = vName;

      this.anzSem = anzSem;

      this.gebTag = gebTag;

    }

Oben: Konstruktor mit Parameterübergabe. Er wird vom HP aufgerufen, in der Klasse Stud (natürlich) ausgeführt, deshalb spielen die Sichtbarkeitsmodifizierer keine Rolle.

    public Stud() {

    }

Standardkonstruktor.

    public String getName(){

      return name;

    }

Getter-Methode. Mit ihr ist es möglich, trotz Sichtbarkeitsmodifizierer protected das jeweilige Attribut abzufragen. Siehe HP.

    //Setter

    public void setName(String name) {

      this.name = name;

    }

Setter-Methode. Mit ihr ist es möglich, trotz Sichtbarkeitsmodifizierer protected das jeweilige Attribut zu beschreiben. Siehe HP.

    void ausgeben() {

      System.out.println("\nMatrikelnummer: " + mNr);

      System.out.println("Name: " + name);

      System.out.println("Vorname:" + vName);

      System.out.println("Erreichtes Semester: " + anzSem);

      System.out.println("Geburtstag: " + gebTag);

      }

Methode zum Ausgeben der Daten eines Objekts.

}

2.13.2 Klasse HP

package hochschule;

public class HP {

  public static void main(String[] args) {

    Stud s1 = new Stud();

Oben: S1 wird mit dem Standardkonstruktor erzeugt.

    System.out.println("Leeres Objekt von HP aus mit Methode aus Stud ausgeben:");

    s1.ausgeben();

Oben: Dies klappt, wegen dem Modifizierer paketsichtbar, der eingestellt ist, falls kein anderer Modifizierer explizit angegeben wird. Genauso bei protected. Gibt man dagegen in Stud vor der Methode ausgeben() private an, ist die Methode vom HP aus nicht sichbar. Ausprobieren!

    Stud s0 = new Stud("123", "Maier", "Klara", 5, "21.09.2002");

S0 wird erzeugt (instantiiert) und per Parameter mit Daten versorgt.

    System.out.println("\nBeschriebenes Objekt von HP aus mit Methode aus Stud ausgeben:");

    s0.ausgeben();

Klappt wiederum, weil Zugriff vom HP kommt und der Modifizierer es erlaubt (vgl. oben).

    System.out.println("\nDie Ausgabe des Geburtstags klappt: " + s0.gebTag);

Das Attribut gebTag kann wegen Sichtbarkeit public abgefragt werden.

    System.out.println("\nDas klappt nicht: s0.name= 'Erwin'");

    System.out.println("\nDas auch nicht: System.out.println(s0.name ohne Setter= + s0.name)");

Zwei Fehlschläge, verursacht durch den Sichtbarkeitsmodizierer.

    System.out.println("\nDirekte Abfrage s0.name mit Getter-Methode: " + s0.getName());

"Getter" hilft.

    System.out.println("\nDirektes Beschreiben s0.name mit Setter-Methode (Millifranz): ");

    s0.setName("Millifranz");

    System.out.println("\nGeänderter Name: " + s0.getName());

"Setter" ebenso.

  }

}

2.13.3 Programmlauf

Leeres Objekt von HP aus mit Methode aus Stud ausgeben:

Matrikelnummer: null

Name: null

Vorname:null

Erreichtes Semester: 0

Geburtstag: null

Beschriebenes Objekt von HP aus mit Methode aus Stud ausgeben:

Matrikelnummer: 123

Name: Maier

Vorname:Klara

Erreichtes Semester: 5

Geburtstag: 21.09.2002

Die Ausgabe des Geburtstags klappt: 21.09.2002

Das klappt nicht: s0.name= 'Erwin'

Das auch nicht: System.out.println(s0.name ohne Setter= + s0.name)

Direkte Abfrage s0.name mit Getter-Methode: Maier

Direktes Beschreiben s0.name mit Setter-Methode (Millifranz):

Geänderter Name: Millifranz

3 Assoziationen

3.1 Definition

Im vorigen Kapitel wurden die Grundkonzepte Objekt und Objektklasse 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

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

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.

3.11 Assoziationen in Java

Java ist eine objektorientierte Programmiersprache, kein objektorientiertes Datenbanksystem. Das merkt man hier, beim Thema Assoziationen, besonders deutlich. Ihre Umsetzung in Java ist nicht nur komplex, sondern auch kompliziert. Sie werden in der Java-Literatur auch selten thematisiert, eine kurze Darstellung findet sich in [Ullenboom 2022, Abschnitt 7.1].

Hat man Datenstrukturen zu bewältigen, für die Assoziationen benötigt werden, sollte man daher ein objektorientiertes Datenbanksystem wählen oder eine der Möglichkeiten, mit Java "SQL-Datenbanken", d.h. Relationale Datenbanken, zu nutzen. Vgl. die entsprechenden Kapitel in [Ullenboom 2022].

Trotzdem bleibt das Thema Zusammenarbeit von Klassen, Aufruf von Methoden im Rahmen der Aufgabenerledigung, ein wichtiges, das hier wenigstens kurz betrachtet werden soll. Dabei geht man, wenn auch ohne sichtbare Berücksichtigung im Programmcode, auch von Assoziationen aus, denn nur entlang dieser ist sinnvolle Zusammenarbeit möglich.

Im folgenden Beispiel werden die beiden Klassen Stud und Noten verknüpft, um die Noten eines Studierenden bezüglich eines Fachs (z.B. einer Klausur) festzuhalten. Außerdem sollen hier Konstruktoren mit Übergabe der Werte per Parameterliste gezeigt werden.

Zur Assoziation

Die Min-/Max-Angaben sind wie folgt:

• Ein Studierender hat keine (vor der ersten Prüfung) oder mehrere Prüfungen absolviert.
• Jede Notenangabe gehört zu genau einem Studierenden.

Realisiert wird die Assoziation hier durch die Matrikelnummer, die in beiden Klassen angelegt ist. Dies ist eine datenbanktechnische Sicht.

Der Startpunkt für ein Programm wie dieses wäre also die Stelle, wo die beteiligten Objekte identifiziert sind und bereitstehen. Das leistet üblicherweise ein datenverwaltendes System (vgl. die Anmerkungen oben).

Startpunkt

Abbildung 3.11-1: Studierende und ihre Noten

3.12 Java-HS4

Java-Exkurs, Projekt HS4

3.12.1 Klasse HP

Die Klasse HP erfasst den Programmablauf. Dazu wird, wie immer in Java, ein Hauptprogramm ("main") eingerichtet. Die ersten beiden hervorgehobenen Zeilen zeigen die Konstruktoraufrufe bezüglich der Objekte (Studierenden) s0 und s1. Die dritte zeigt den Konstruktoraufruf bzgl. der Klasse Noten.

Abschließend wird die Ausgabe verknüpfter Daten gezeigt. Insgesamt erfolgt hier an folgenden Stellen ein Aufruf einer anderen Klasse:

• s0.ausgeben() ruft die Klasse Stud mit ihrer Methode ausgeben() auf.
• s1.name fordert den Namen der Instanz s1 an, usw.
• n1.fach fordert das Studienfach der Notenvergabe an, usw.

In Stud ist ein Klassenattribut eingefügt: anzStud. Es hält die Anzahl der Studierenden (die Anzahl der Objekte von Stud) fest. Das Hochzählen erfolgt im Konstruktor von Stud.

Klassen-
attribut

Klasse HP

package hochschule;

public class HP {

  public static void main(String[] args) {

    Stud s0 = new Stud("123", "Maier", "Klara", 5, "21.09.2002");

Oben: Konstruktor für das Objekt s0. Die Attribute des Objekts werden über die Parameterliste des Konstruktors befüllt. Vgl. Stud für den entsprechenden Aufbau des Konstruktors. In [Lesehilfe, Abschnitt 4.2] finden sich Erläuterungen hierzu.

    System.out.println("Ausgabe in HP mit Methode der Klasse Stud:");

    s0.ausgeben();

Aufruf der Instanzmethode ausgeben() der Klasse Stud.java.

    Stud s1 = new Stud("234", "Müller", "Ulla", 5, "1.1.1999");

    s1.ausgeben();

Ein weiteres Objekt von Stud entsteht und wird ausgegeben.

    Noten n1 = new Noten("234", "EinfWI", "3,5");

    n1.ausgNote();

Konstruktor der Klasse Noten mit Dateneingabe per Parameter,. Es entsteht Objekt n1. EinfWI bedeutet: Einführung in die Wirtschaftsinformatik.

Dann Aufruf der Instanzmethode ausgNote() von Noten.

    System.out.println("\nAusgabe der Noten in Klasse HP:");

    System.out.println("Matrikelnummer: " + s1.mNr + "\nName: " + s1.name + "\nVorname: " + s1.vName + "\nFach: " + n1.fach + "\nNote: " + n1.note);

Von HP aus Ausgeben verknüpfter Daten von s1 und n1.

Das Beispiel ist aus didaktischen Gründen stark fokussiert auf die Aufruf- und Konstruktorthematik. In Wirklichkeit müssten natürlich die passenden Studierenden und Noten zuerst gesucht werden.

  }

}

3.12.2 Klasse Noten

Die Klasse Noten erfasst mit den Attributen mNr (Matrikelnummer), fach (Studienfach) und note (erreichte Note in Klausur, mündlicher Prüfung, Hausarbeit, usw.).die Noten der Studierenden.

Der Konstruktor ist wiederum so angelegt, dass die Attributsausprägungen (Werte) gleich beim Aufruf übergeben werden. Eine Methode ausgNote() erlaubt es, die Noten eines Studierenden bzgl. eines Faches anzeigen zu lassen.

package hochschule;

public class Noten {

  public String mNr; //Matrikelnummer

  public String fach;

  public int note;

  public Noten(String matrNr, String fach, String note)

  {

    this.mNr = matrNr;

    this.fach = fach;

    this.note = 2;

  }

Oben: Ein Konstruktor mit Werteübergabe in der Parameterliste. Damit entsteht dann nicht ein unbeschriebenes Objekt mit 0, null und false, sondern gleich eines mit beschriebenen Attributsausprägungen.

Der Aufruf im HP ist wie folgt: Noten n1 = new Noten("12345", "EinfWI", "3,5"). Zu beachten ist die Zuweisung der übergebenen Werte an die Attribute des Objekts mittels desw Schlüsselwortes this.

  void ausgNote() {

    System.out.println("\nAusgabe der Daten in Klasse Noten:");

    System.out.println("Student (Matrikelnummer): " + mNr);

    System.out.println("Fach: " + fach);

    System.out.println("Note: " + note);

  }

Definition der Instanzmethode ausgNote(). Diese steht dann im gesamten Programm zur Verfügung, dank package hochschule.

Aufruf im HP z.B. so: n1.ausgNote().

}

3.12.3 Klasse Stud

Die Klasse Stud enthält neben den Attributen mNr (Matrikelnummer), name (Name), vName (Vorname), gebTag (Geburtstag) und anzSem (erreichtes Semester) das Klassenattribut anzStud (Anzahl Studierende). Diese wird bei der Einrichtung auf einen Anfangswert gesetzt.

Die hier gewählte Konstruktorvariante zeigt die Erstellung eines Objekts mit Hilfe der Parameterliste. Wie der zugehörige Aufruf aussieht, zeigt die Klasse HP. Die Einträge der im Aufruf übergebenen Werte erfolgt mit Hilfe des Key Words this. Außerdem wird hier wiederum gleich beim Konstruktor das Attribut anzStud um 1 hochgezählt.

Die Klasse hat außerdem die Methode ausgeben(), mit der die Daten des gerade erstellten Objekts auf der Konsole angezeigt werden.

package hochschule;

public class Stud {

  public String mNr; //Matrikelnummer

  public String name;

  public String vName;

  public int anzSem; //Erreichtes Semester

  public String gebTag; //Geburtstag

Oben: Instanzattribute zur Beschreibung der Objekte.

  static int anzStud = 0;

Oben: Klassenattribut (statisches Attribut) mit Anfangswert:

  public Stud (String mNr, String name, String vName, int anzSem, String gebTag) {

    this.mNr =mNr;

    this.name =name;

    this.vName = vName;

    this.anzSem = anzSem;

    this.gebTag = gebTag;

    anzStud++; //Zähler für Klassenattribut

  }

Konstruktor mit Parameterliste. Zu beachten ist das Eintragen der Parameterwerte mittel this in die Attribute.

Der Aufruf im HP ist hier wie folgt: Stud s0 = new Stud("1111", "Maier", "Klara", 5, "21.09.2002").

Das Klassenattribut anzStud() wird bei jedem Konstruktoraufruf um 1 erhöht.

  void ausgeben() {

    System.out.println("\nMatrikelnummer: " + mNr);

    System.out.println("Name: " + name);

    System.out.println("Vorname:" + vName);

    System.out.println("Erreichtes Semester: " + anzSem);

    System.out.println("Geburtstag: " + gebTag);

  }

Methode zum Ausgeben der Daten eines Objekts. Der Aufruf im HP ist z.B. wie folgt: s1.ausgeben();

}

3.12.4 Programmlauf

Ausgabe der Daten in HP mit Methode der Klasse Stud:

Matrikelnummer: 123

Name: Maier

Vorname:Klara

Erreichtes Semester: 5

Geburtstag: 21.09.2002

Matrikelnummer: 234

Name: Müller

Vorname:Ulla

Erreichtes Semester: 5

Geburtstag: 1.1.1999

Ausgabe der Daten in Klasse Noten:

Student (Matrikelnummer): 234

Fach: EinfWI

Note: 2