aus : Baumann, 1996, S. 277 - 279

Objektorientierte Systementwicklung



Die Welt ist die Gesamtheit der Dinge, nicht der Tatsachen. Form, Gestalt und Struktur sind Eigenschaften der Dinge. Dinge stehen in Wechselwirkung mit anderen Dingen. Jedes Ding ändert sich. Kein Ding entsteht aus dem Nichts, keines wird zu nichts. Jedes Ding richtet sich nach Gesetzen.

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.


18.1 Objektorientiertes Modellieren und Entwerfen



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:

  • A ist_ein B: Jedes Objekt von A ist ein Objekt von B, die Unterklasse A übernimmt alle Attribute und Methoden von B. Die Objekte von A und B werden verhaltensgleich oder konform genannt; es handelt sich um konforme Vererbung.

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

    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.

  • A ist eine Spezialisierung von B: Die Objektklasse A schränkt B zugunsten eines spezifischen Verhaltens ein.

    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

    Zusammenfassung