Witwenstein
Zielorientierter Entwurf setzt voraus, daß das Ziel bereits vorgegeben ist. In der Praxis werden Systeme häufig
evolutionär entwickelt, um sie nach und nach in ihrer Funktionalität zu erweitern und sich ändernden
Anforderungen anzupassen. Daher scheint es besser, ein Informatiksystem als Gesamtheit relativ
unabhängiger, miteinander kooperierender Einheiten anzusehen, dem neue Einheiten hinzugefügt oder in dem
bereits vorhandene Einheiten modifiziert bzw. ersetzt werden können. Diese Einheiten repräsentieren Objekte
der realen Welt, und das Informatiksystem ist ein Produkt der objektorientierten Systementwicklung (Goos
1996).
Bis vor wenigen Jahren wurde der Begriff der Objektorientierung hauptsächlich mit bestimmten
Programmiersprachen in Verbindung gebracht. In letzter Zeit ist das "Objekt-Paradigma" indes zur Grundlage
des Systementwurfs geworden. "Wir modellieren die Wirklichkeit, einen Weltausschnitt so, wie er vom
Menschen gesehen wird" (Quibeldey-Cirkel 1994, 81).
"Da diese Art der Programmierung gewissen menschlichen Denk- und Verhaltensweisen, wie z. B, dem Auslösen einer Aktion
durch eine Nachricht, der eigenständigen Verantwortung eines Individuums für seinen Zustand, der Klassifizierung und
Kategorisierung von Information sowie dem Ausnutzen von bereits Bekanntem bei der Erweiterung des Wissens, ziemlich direkt
entspricht, werden wir von Anfang an ihre Terminologie verwenden und nicht über mehrere Zwischenstufen (wie strukturierte oder
modulare Programmierung) zum eigentlichen Ziel voranschreiten" (Guldenberg 1993, 11).
"Ausgehend von Smalltalk erkannte man seit Mitte der achtziger Jahre, daß Objektorientierung eine Modellierungs- und
Entwurfsmethode ist, die einen anderen Ansatz zur Systembeschreibung darstellt als strukturiertes und modulares
Programmieren. Strukturiertes Programmieren wird für das Programmieren im Kleinen und vor allem für die Datenmodellierung
verwendet. Die Modellierungsmethoden und die Verbesserung der Wiederverwendbarkeit von Entwürfen und Programmcode sind
die eigentlichen Vorzüge objektorlentierten Programmierens, nicht die speziellen Ausdrucksmittel bestimmter Programmiersprachen" (Goos 1996, 255).
Der Weg von einem Problem zum funktionierenden Informatiksystem gliedert sich in mehrere Phasen, an deren
letzter Stelle erst die eigentliche Programmierung steht. Die drei Hauptphasen
sind beim objektorientierten Vorgehen ineinander verzahnt. Die TerminoIogie, in der man das Problem analysiert
und das Informatiksystem entwirft, spiegelt sich oft direkt in der Programmiersprache wider. Auf diese Weise
gelangt man vergleichsweise schnell zu ausführbaren Prototypen, die anschließend nach und nach
("evolutionär", siehe oben) zum endgültigen Programm weiterentwickelt werden.
Die Analyse eines informatischen Problems führt zu einem Modell des Problembereichs, d. h. des
Weltausschnitts, der dem Problem entspricht. Das Systemmodell beschreibt die wichtigsten
Eigenschaften des geplanten Informatiksystems. Es ist anwendungsorientiert, nicht
implementierungsorientiert und stellt fest, was das System tun soll - nicht, wie es das tut. Vor der Frage
nach dem Wie kommen die Fragen nach dem Was und dem Warum.
Jedes System besteht aus - miteinander wechselwirkenden - Komponenten; die elementaren
Komponenten heißen (reale) Objekte. In einem Informatiksystem, das einem realen System entsprIcht,
werden die realen Objekte durch Datenobjekte repräsentiert. Eine Beschreibung der statischen
(unveränderlichen) Eigenschaften und Beziehungen der Datenobjekte zueinander heißt Datenmodell
(oder: Objektmodell) des Systems. Hinsichtlich der dynamischen Beziehungen unterscheiden wir das
Funktionsmodell, welches das Zusammenwirken der Teilsysteme zur Erfüllung der Aufgaben des
Systems erfaßt, vom Ablaufmodell, das den zeitlichen Ablauf dieser Kooperation beschreibt (Goos 1996,
152).
Zur Gewinnung des Datenmodells hat man u. a. folgende Fragen zu beantworten: Welche Objekte sind
relevant? Welche Merkmale sind für sie kennzeichnend? Wie lassen sich die Objekte klassifizieren?
Welche Beziehungen bestehen zwischen den Klassen?
a) Objekte und Klassen
Das zentrale Element des Datenmodells ist das Datenobjekt (kurz: Objekt). Jedes Objekt repräsentiert
einen Gegenstand (Person, Ding, Sachverhalt) des Problembereichs.
Bemerkung: In der Literatur finden sich statt "Datenobjekt" viele andere Termini: "Analyseobjekt",
"lnformationsobjekt", "programmsprachliches Objekt", "DV-Objekt" u. v. a. m.
Das Objekt ist eingekapselt in dem Sinne, daß sein Zustand ausschließlich über Nachrichten ermittelt
oder geändert werden kann.
Alle Objekte mit den gleichen Attributen und gleichen Methoden werden zu einer Objektklasse (kurz:
Klasse) zusammengefaßt; das einzelne Objekt ist ein Exemplar (engl.: instance) der Klasse. Die Objekte
einer Klasse bilden einen abstrakten Datentyp (siehe 17.2.2).
b) Klassenhierarchie mit Vererbung
Von einer gegebenen Objektklasse ausgehend werden untergeordnete Klassen gebildet, wobei letztere
alle Merkmale der übergeordneten Klasse "erben". Der Nutzen dieses Vorgehens besteht darin, daß
Attribute (und eventuell auch Methoden) wiederverwendet werden können. Der Begriff der Vererbung
kann verschiedene Beziehungen zwischen Objektklassen ausdrücken:
Beispiele: (1) Jeder Kunde ist ein Geschäftspartner, jeder Lieferant ist ein Geschäftspartner. Die Klasse der Kunden ist eine
Teilklasse der Klasse der Geschäftspartner. Bemerkung: Die Beziehung ist_ein (engl.: is-a) darf nicht mit der Elementbeziehung verwechselt werden, welche der
elementaren Prädikation entspricht (siehe 10. 1). Im Deutschen kann die Kopula "ist" beides bezeichnen: "Martina ist eine
Läuferin" (Prädikation, Elementbeziehung), "jede Läuferin ist eine Sportlerin" (Subordination, Teilmengenbeziehung). Aus
diesem Grund wird die Teilmengenbeziehung auch als Ako-Beziehung (engl.: a-kind-of) bezeichnet.
(2) A = Menge der Quadrate, B = Menge der Rechtecke. A übernimmt die Attribute Seitenlänge_a und Seitenlänge_b; in A gilt
Seitenlänge_a = Seitenlänge_b.
Beispiel: B = Klasse der Quadrate, Attribut: Seitenlänge_a, Methoden: berechne_Umfang und zeichne. A = Klasse der
Rechtecke. A übernimmt das Attribut Seitenlänge_a sowie die beiden Methoden und bekommt zusätzlich das Attribut
Seitenlänge_b. Die ererbte Methode berechne_Umfang wird neu vereinbart (überschrieben): 2*(Seitenlänge_a +
Seitenlänge_b). In diesem Sinne sind Rechtecke spezielle Quadrate