2.1 Einführung

Am Ende des Textes  ist eine Liste der verwendeten Fachbegriffe in Deutsch und Englisch angegeben.

2.1.1 Zwei Basisbegriffe

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

Modelle erstellen

Ganz zu Beginn dieser Modellierungsprojekte muß 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, hier in der objektorientierten Theorie als Attribute festgehalten.

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.2 Objekte in dieser Welt

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.

Ü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 [Anmerkung] .

„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ürde 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 ein durch den Wald wandernder Biologe, 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.

2.1.3 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) fassbar, bzw 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 2005]) 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 Informa­tionsverarbeitung mit ihren Attributsausprägungen möglich sind.

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

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 eine anderes Realweltphänomen (z.B. Angestellte). Geht es dagegen um mehr als ein Attribut (z.B. abteilungsbezeichnung und abteilungsleiter) entsteht ein Informationsträger im Sinne der konzeptionellen Modellierung und hier in der objektorientierten Theorie ein Objekt. Natürlich muss mindestens eines der Attribute identifizierenden Charakter haben.

Ganz pragmatisch:

Objektfindung durch
Attribute

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

2.1.4 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 diese 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 ).

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 muß. 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 Objektklasse sind 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.

2.1.5 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. "Eingestellt werden" 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.

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

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

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

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

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

Beispiel Angestellte

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

usw. Sie benötigen aber auch Methoden wie

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

usw.

2.2 Instantiierung und Klassifikation

2.2.1 Instanzen

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

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

2.2.2 Klassifikation

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.

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

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

Zum Begriff und Konzept entity vgl. Kapitelanfang.

2.3 Objektklassen als Informationsverwalter

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

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

Klassenmethoden

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

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

Klassen als Träger von Attributen und Methoden

2.4 Grafische und textliche Darstellung

2.4.1 Klassen

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

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

Die folgende Abbildung zeigt einige Beispiele.

In der UML ist das auch die grafische Darstellung eines Classifiers, der „obersten“ Klasse in der Metamodellierung (vgl. WebZumBuch_UM03), 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 die Attribute und Methoden. Werden die Attribute hinzugenommen ergibt sich mit dem obigen Beispiel zu den Angestellten die Darstellung wie in der folgenden Abbildung.

2.4.2 Aufbau der Bezeichnungen von Attributen und Methoden/Operationen

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 Text 1 angegeben.

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 Klassenattributen und –methoden ergibt sich damit die Klasse Angestellte wie in der folgenden Abbildung.

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

2.4.3 Instanzen bzw. Objekte

Instanzen  (Objekte) werden ebenfalls als Rechtecke dargestellt. Die Bezeichnung einer Instanz ist wie folgt aufgebaut:

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:

anonymes Objekt

:Angestellte

Im Vergleich zur Darstellung von Klassen werden hier 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 grafische Darstellung.

Grafische Darstellung

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

Die erste Abbildung zeigt die am häufigsten vorkommende Notation (volle Bezeichnung, ohne Attribute).

In manchen Situationen ist es nicht nur sinnvoll, 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.

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

2.5 Sichtbarkeit

2.5.1 Public, Private, Protected

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

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

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.

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 . 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 Beispiele aus drei Anwendungsbereichen verwendet: Hochschule, WebShop und Angestellte. Im Hochschulbeispiel wird vor allem das Geschehen rund um die Vorlesungs- und Prüfungsdurchführung betrachtet. Beim WebShop konzentriert sich die Betrachtung auf das Zahlungs- und Mahnwesen. 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().

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

2.7.2 WebShop

Kunden, Rechnungsköpfe, Rechnungspositionen, Artikel

Betrachten wir das Geschehen rund um einen WebShop, sind ebenfallssehr schnell sehr viele Attribute und Klassen erkennbar. Hier sollen im ersten Schritt die Kunden, die Rechnungsköpfe und Rechnungspositionen sowie die Artikel betrachtet werden.

Für die Kunden werden die Attribute Kundennummer (kNr), name, vorname, plz, ort, strasse, Mailadresse (mail), telefon und Kundenstatus (status) sowie die Methoden Rechnungs- und Mahnungserstellung (erstellenRechnung(), erstellenMahnung()) erfasst.

Die Rechnungsköpfe können mit den Attributen Rechnungsnummer (rechnNr), Rechnungsdatum (rechnDatum), Kundennummer (kNr), zahlungsart und versandart beschrieben werden. Für jede Rechnung wird auch noch die Rechnungssumme (rechnSumme) und die angefallene Mehrwertsteuer (mwst) erfasst.

Attribute von Rechnungsköpfen

Bei den Methoden sollen für’s erste das Lesen der Rechnungspositionsinformationen (lesePos()), die Bestimmung der Rechnungssumme und die Bestimmung der Mehrwertsteuer reichen (bestimmeRS(), bestimmeMWSt()).

… und Methoden

Die Attribute der Klasse Rechnungspositionen ergänzen die der Klasse Rechnung um die Informationen, die positionsspezifisch sind. Dies sind die Positionsnummer (posNr), die Artikelnummer (artNr), die Mengenangabe bei der Position (anzahl) sowie der Positionspreis (posPreis) und der Mehrwertsteuerbetrag der Position (mwst). Das Attribut Rechnungsnummer (rechnNr) hält fest, zu welcher Rechnung die jeweiligen Rechnungspositionen gehören.

Rechnungs­positionen

In der Klasse Artikel wird die Artikelnummer (artNr), die Artikelbezeichnung (artBez), die Artikelbeschreibung (artBeschr), der Listenpreis (listPreis) sowie der minimale Lagerbestand (bei dessen Erreichen oder Unterschreiten nachbestellt wird) (lagMin) festgehalten.

Artikel

Elementare Methoden begleiten hier die Entnahme von und das wieder Hinzufügen von Artikeln in das Lager (entnahme(), hinzufügen()).

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

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

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

Personal Computer

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

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 oben 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 entity is 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

Ein Modellierungskonzept, das für die objektorientierte Unternehmensmodellierung mit Sicherheit von Bedeutung ist, wird vor allem in der Diskussion um objektorientierte Datenbanken betont: die eindeutige, beständige und von der Beschreibung durch Attribute unabhängige Identifizierbarkeit der Objekte.

Bei objektorientierten Datenbanken soll jedes Datenbankobjekt eindeutig identifiziert werden durch einen Objektidentifizierer (OID) (object identifier), der vom Datenbanksystem 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 z.B. vom Datenbanksystem verwaltet werden.

Objektidentifizierer

Mit diesem Konzept der OID 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 Surrogaten 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.

Dies macht sie geeignet für den "referenzbasierten Aufbau von Beziehungen“ zwischen Objektklassen (vgl. unten sowie [Meier und Wüst 1997, S. 16], [Geppert 1997, S. 2]).

Meier und Wüst weisen weiter darauf hin, dass trotz der Existenz dieses Systemschlüssels andere benutzerbezogene Identifikations- oder Zugriffsschlüssel eingerichtet werden können. Dies erfolgt über die Attribute, z.B. Personalummern, Produktnummern, Kontonummern, Artikelnummern, usw. Die entstehenden Attributskombinationen werden wertbasierte Suchschlüssel genannt.

Wertbasierte
Suchschlüssel

"Ein wertbasierter Suchschlüssel (value-based search key) ... identifiziert ein bestimmtes Objekt aufgrund von Attributwerten oder Attributwertkombinationen." [Meier und Wüst 1997, S. 38].

Seine Spezifizierung erfolgt durch den Zusatz Key in der Klassendefinition, z.B. Key(Personalnummer).

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.

Entsprechend beschreiben [Balzert 1999, S. 542] und [Meier und Wüst 1997, S. 6] komplexe Objekte als Objekte, „deren Attribute selbst wiederum Objekte sein können“.

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 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]

Sammlung von (teilweise) gleich strukturierten „Dingen“

Damit gewinnt die Definition Konturen. 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 Ding verwendet. 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

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

Unterbereiche in Classifiern

Da Klassen die am häufigsten vorkommenden Classifier sind, kann bei ihnen die Bezeichnung des Typs („class“) weggelassen werden.

2.9 Beitrag zur Unternehmensmodellierung

Gehen wir von einem Unternehmen als Anwendungsbereich aus.

Klassen bilden durch die Attribute das informationelle Grundgerüst des Unternehmens ab. Sie beschreiben aus Prozesssicht alle Dokumente (z.B. auch Geschäftsobjekte) und sonstigen Informationen, die bei der Abwicklung der Geschäftsprozesse und bei der Realisierung der Funktionen benötigt werden.

Informationelles Grundgerüst des Unternehmens

Durch die zusätzliche Erfassung der Methoden erfassen sie auch elementare Verarbeitungsschritte von Informationen, allerdings – erst mal – nur solche, die sich auf die Objekte der eigenen Klasse beziehen. Wobei mit Methoden allein kein Geschäftsprozess modelliert werden kann (vgl. hierzu die Diskussion in Kapitel 7).

Elementare Verarbeitungs-
schritte von Informationen

Insgesamt also eine gute Ausgangssituation. Klassen erscheinen durch ihre Verbindung von statischen und dynamischen Aspekten geradezu prädestiniert für die Unternehmensmodellierung. Mehr dazu in den folgenden Texten.