Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

23.08.1991 - 

Noch gibt es Hürden auf der "Prachtstraße zum Software-Entwurf", Teil 2

Objektorientierung - eher eine Methode als eine Philosophie

Nichts ist falscher, als ein Objekt mit einem realen Ding zu identifizieren: Objekte sind logische Einheiten, die nur in ihrem spezifischen Kontext existieren. Auch Objektorientierung (OO) kann in verschiedenen Zusammenhängen recht verschiedene Dinge bedeuten.

Ich beginne den Ausflug die höheren Sphären von OO mit der Sprache, da die unmittelbare Bedeutung des Worts Objektorientierung eine Art Folie ist, auf der sich die fachspezifischen Bestimmungen darstellen.

Der Begriff Objekt ist sehr abstrakt. Er unterscheidet einen beliebigen Sachverhalt lediglich in zweierlei Hinsicht von anderen: Erstens wird dieser Sachverhalt als selbständige Einheit gekennzeichnet, und zweitens wird er einem Subjekt gegenübergestellt, also als Gegenstand eines Willens betrachtet. Das Subjekt kann mit dem Objekt tun, was es will, vorausgesetzt, daß es die Merkmale und inneren Gesetzmäßigkeiten des spezifischen Gegenstandes beachtet. Objektorientiert bedeutet also nichts weiter, als Sachverhalte als Einheiten zu betrachten - unter dem Gesichtspunkt, was man mit ihnen anstellen kann beziehungsweise will .

Diese Bindung an bestimmte Vorhaben eines Subjekts ist von entscheidender Wichtigkeit, da man ansonsten nicht versteht, wieso dasselbe Ding in ganz verschiedener Hinsicht Objekt sein kann beziehungsweise - schärfer - sich als verschiedene Objekte darstellen kann. So ist ein PC vom Standpunkt des Herstellers etwas völlig anderes als vom Standpunkt des Benutzers. Der eine betrachtet ihn als eine Liste von Teilen, die in bestimmter Ordnung montiert werden müssen, während der andere ihn als Hardwarebasis seiner Programme schätzt. Erst wenn er nicht mehr funktioniert, fällt dem Benutzer sein PC als Herstellerobjekt in dem Sinne wieder ein, daß er versucht, das schadhafte Teil auswechseln zu lassen. Als Objekt ist ein Ding also immer in Beziehung auf ein Subjekt gedacht. Nicht der PC im engeren Sinne ist das Objekt, sondern die jeweilige Relation (PC - Produzent oder PC - Benutzer).

Keine Identifikation mit dem realen Ding

Nehmen wir statt des Benutzers einen Verkäufer. Es liegt auf der Hand, daß der PC als Objekt eines Anwendungssystems für die Produktion, wo er über den Status seiner Montage Auskunft geben muß, völlig anders aussieht als im System "Vertriebsunterstützung", in dem er über so illustre Attribute wie Preis und Bestellnummer verfügt, die in der Herstellung keine Rolle spielen. Nichts ist falscher, als den Ausdruck Objekt mit Ding zu identifizieren - obwohl natürlich die spezifischen Eigenschaften des Dings die Grundlage der Beziehung zum Subjekt und damit der Objektkonstitution sind.

Im folgenden soll aufgezeigt werden, was OO sinnvollerweise auf den verschiedenen Ebenen der Anwendungsentwicklung bedeuten kann.

Maus, Icons und Fenster haben an sich mit Objektorientierung nichts zu tun. Sie können allerdings Mittel sein, eine wirklich objektorientierte Oberfläche zu gestalten. Eine Auswahl ist nämlich die zentrale Idee einer OO-Oberfläche.

Der prozedurale Ansatz, also das übliche Maskendesign, besteht demgegenüber darin, sofort die Einheit von Objekt und Aktion im Arbeitsvorgang als Menüpunkt auf dem Bildschirm darzustellen (also: "Vertrag ändern", "Kunde anlegen"). Das Ändern unter einer Funktionstaste, das je nach Vorauswahl des Objekts auf "Vertrag" und "Kunde" wirkt, ist ein Polymorphismus, auch wenn der Programmdesigner dieses schwierige Wort gar nicht kennt. Solch ein Bildschirm ist dem OO-Gedanken näher als der Klick auf einen Button der "Datei suchen" auslöst.

Die zentrale Idee einer OO-Oberfläche besteht darin, auf dem Schirm die Objekte zu repräsentieren, die der Benutzer, das Subjekt, zu manipulieren gedenkt, und ihm die Instrumente für diese Manipulationen zur Verfügung zu stellen. Die Benutzerschnittstelle erscheint als Angebot, entsprechend den Möglichkeiten der Objekte, sie mit Tastatur- oder - beim Graphical User Interface (GUI) - mit Mauseingaben frei zu bearbeiten.

Betrachten wir beispielsweise den Platz eines Sachbearbeiters in einer Versicherung, so werden in einer OO-Oberfläche Verträge, Briefe, Partner, Schäden etc. symbolisch repräsentiert, und die Sachbearbeitung ist eine symbolische Manipulation der Repräsentanten. Die Imageverarbeitung erlangt in diesem Zusammenhang große Bedeutung, da durch sie in vielen Bereichen nützliche Bildschirmobjetkte generiert werden können. Dadurch ist sie eine wirkliche Basis für die produktive Nutzung einer grafischen Benutzeroberfläche an heutigen Bildschirm-Arbeitsplätzen.

Farben, Fenster und Maus bilden für sich keineswegs bei jeder Anwendung einen Fortschritt an Software-Ergonomie. Eine reale Arbeitserleichterung läßt sich aber erzielen, indem die Anzahl der Übergänge vom einen Medium (Papier) zum anderen (Bildschirm) reduziert wird.

Mit Hilfe der Imageverarbeitung können beispielsweise die zu bearbeitende Eingangspost oder die gängigen Formulare als Bildschirm Objekte dargestellt werden. Ein Sachbearbeiter kann beispielsweise die gescannte Eingangspost ansehen, indem , er das sie repräsentierende Icon mit Hilfe der Maus über einen ebenfalls als Icon dargestellten Browser bewegt.

Falls es sich um einen Beschwerdebrief handelt, kann der Bearbeiter diesen zügig im elektronischen Papierkorb abgelegen. Geht es um eine Vertragsänderung, so werden die zu modifizierenden Daten mit der Maus dem Objekt Vertrag übergeben. Auf diese Weise erhöht sich die Qualität der Arbeit, da Lese- oder Tippfehler des Sachbearbeiters ausgeschaltet werden. Dieses Beispiel zeigt, wie sich die Vorteile eines GUI in eine objektorientierte Bildschirmgestaltung einpassen.

Ein Blick auf das, was 0()Fans als Steinzeit gilt: Heute hat der Sachbearbeiter einen Stapel Unterlagen, loggt sich in t in System ein, startet seine Anwendung und beginnt eine Schadensbearbeitung. Falls ein Brief geschrieben werden muß, kann an Objekten, die durch den Arbeitsplatz definiert (zum Beispiel "Vertrag", "Kunde"), in herkömmlicher Menütechnik präsentiert und mit einer Auswahl von Verarbeitungsmethoden durch Funktionstasten versehen ist ("Löschen", "Ändern"), bedeutet durchaus schon einen Ansatz zu OO. Die Spaltung eines Arbeitsprozesses in Objekte (zum Beispiel Vertrag) und Aktionen (zum Beispiel Löschen) eine weitere Anwendung aufgerufen werden, die im günstigsten Fall bereits eingegebene Daten übernimmt. Mit solchen Neandertaler-Systemen gibt es gewisse Probleme:

- Die durch das Design gegebene Reihenfolge der Bearbeitungsschritte ist im allgemeinen nicht sachlich notwendig. So wird die Flexibilität beschränkt.

- Die verschiedenen Aspekte der Tätigkeit des Sachbearbeiters sind im allgemeinen nicht vollständig integriert, ja sie sind nicht einmal vollständig durch Anwendungen unterstützt

- Die Anwendungssysteme sind nicht so einfach, daß die Fachkenntnisse ausreichen, um sie zu beherrschen. Die Vorteile einer OO-Oberfläche werden plakativ dadurch beschrieben, daß man in den letzten Sätzen das Wort "nicht" streicht. Für den Benutzer gibt es keine Anwendungen mehr (Application transparency), sondern nur noch Objekte, mit denen er symbolisch umgeht, und zwar nach Regeln, die ihm als Fachmann bekannt sind beziehungsweise als mögliche Manipulationen angeboten werden.

Was man mit den Objekten anstellen kann, ist entweder als Sammlung von Prozeduren abgelegt oder beruht auf Nachrichtenaustausch zwischen verschiedenen Exemplaren. So kann ein Vertrag zum Beispiel gedruckt oder geändert werden. Drucken beruht auf einer Kommunikation mit dem Objekt Drucker. Diese wird auf dem Bildschirm durch Verschieben mit der Maus von "Vertrag A" auf "Drucker X" symbolisiert. Ändern ist hingegen eine Aktion, sie geht nicht über das Objekt hinaus. Wohlgemerkt: Auf der Ebene der Oberfläche! Die sich in der Oberflächengestaltung eines Arbeitsunterstützungsystems ergebenden Objekte fallen keineswegs mit denen der anderen Ebenen (Analyse, Design) zusammen.

Betrachten wir einen Augenblick eine mögliche Implementierung: Hier wäre "Vertrag" eine Klasse und der zu ändernde Vertrag xy eine Instanz. "Ändern" wäre eine Methode, die dem Objekt, das die Vertragsdaten enthält, angehört. Da Objektexemplare nur temporär im Hauptspeicher existieren, ist eine Transaktion unterstellt, die den Inhalt der Veränderung auf eine Datenbank sichert. Bevor eine Änderung wirklich durchgeführt wird, finden allerdings vielfältige Prüfungen statt, um ihre Korrektheit zu garantieren. Dies bedeutet Nachrichtenaustausch zwischen verschiedenen Objekten. So erscheint, was auf der Oberfläche eine Aktion ist, auf der Ebene des Designs als Kommunikation.

Eine Grundidee der OO-Oberfläche besteht in der Freisetzung des Benutzers von durch Menühierarchien fixierten Arbeitsabläufen. Er soll seinen Umgang mit den Objekten flexibel bestimmen können. Hierin offenbart sich die Herkunft des Konzepts aus der Region des Personal Computing und der selbständigen und vielfältigen Schreibtischarbeit.

Das bedeutet auch, daß es bei einer Einführung nur um Arbeitsplätze gehen kann, auf denen die mögliche Flexibilität und Autonomie auch gewünscht ist. Es versteht sich von selbst, daß Eingaben, die einem starren Muster folgen sollen, nicht durch OO verbessert werden können. Im Gegenteil: Man würde Fehlermöglichkeiten schaffen.

Diese Tatsache rechtfertigt allerdings keine prinzipielle Skepsis gegenüber der Praxisrelevanz des Konzepts. Arbeitsprozesse, die keine Kreativität und damit Flexibilität erfordern, sind prinzipiell automatisierbar. So lassen sich zum Beispiel mit den Fortschritten der Imageverarbeitung Data-Entry-Plätze stark reduzieren.

Umgekehrt dürfte die Sachbearbeitung anspruchsvoller werden können. Das wird auch tatsächlich geschehen, denn hier liegt ein echtes Rationalisierungspotential. Es handelt sich um mechanische, geistig anspruchslose Tätigkeiten, deren rein elektronische Abwicklung qualitätserhöhend und - bei entsprechender Entwicklung der Hardwarepreise - auch kostensenkend wirken würde.

In dem skizzierten Arbeitsplatz-Modell einer OO-Oberfläche ist ein Ideal fixiert. Die Vielzahl der Anforderungen von Benutzern wird nicht vollständig und endgültig von den Entwicklern erfüllt, wie es stillschweigend vorausgesetzt wurde. Aber man kann eine OO-Oberfläche in Grundausstattung kaufen, zum Beispiel Officevision/2 von IBM oder New-Wave von HP.

Nun lassen sich zusätzliche Objekte integrieren, die die bereits vorhandenen benutzen. Für die Implementierung dieser Integration werden APIs von den Anbietern zur Verfügung gestellt. Es ist natürlich auch denkbar, Objekte als Standardsoftware ergänzend zu kaufen. Hier spielt allerdings die Problematik der Kompatibilität unmittelbar hinein. Die formale Integration bestehender Altanwendungen jedenfalls - mit Klick auf ein schickes Icon direkt zu einer antiken Menühierarchie - kann nur ein Durchgangsstadium sein.

In großen Unternehmen ist es sicher so, daß für spezielle Prozesse konstruierte Objekte geschrieben werden müssen. Voraussetzung hierfür ist eine

OO-Analyse. Diese hat es naturgemäß mit sehr viel mehr Objekten zu tun als nur mit den auf dem Bildschirm repräsentieren. Die dem Zugriff des Benutzers entzogenen, vollständig automatisierten Vorgänge müssen ja auch erfaßt werden.

Wie in jeder die Softwareproduktion vorbereitenden Analyse geht es um die Fixierung dessen, was geleistet werden soll. Zunächst muß der Problembereich festgelegt werden, also zum Beispiel ein Flugsystem (Coad/Yourdon verwenden dieses Beispiel in der Darstellung ihres OOA-Dialekts, Prentice Hall, Englewood Cliffs 1990) oder auch eine Fertigungssteuerung.

Dann sind die Objekte zu identifizieren. Diese Aufgabe ist keineswegs trivial, da die Objekte erst durch das Vorhaben, also den Problembereich, konstituiert werden. Der PC ist, wie erwähnt, in der Fertigungssteuerung ein Objekt, aber er ist dort ein vollkommen anderes Objekt, als er es innerhalb seines Vertriebs ist.

Der Inhalt eines Objekts entscheidet sich an seinen Attributen, das heißt der Art der Daten, durch die es in dem spezifischen (Geschäfts-)Prozeß definiert ist.

Es müssen also diese Attribute aufgrund des Problembereiches isoliert werden. Das ist alles andere als eine vollständige Beschreibung eines Dings oder Sachverhalts. Überhaupt sind Objekte nicht unbedingt äußere Gegenstände. Das Objekt "Patient" in einem Krankenhaussystem ist zum Beispiel eine Rolle, in die eine Person mehr oder weniger freiwillig schlüpft; der "Vertrag" in einem System für Versicherungen ist ein Rechtsverhältnis, der "Tarif" im selben System ist eine verbindliche Festlegung etc.

Objekte können prinzipiell in drei Arten von Beziehungen zueinander stehen:

- Abstraktion/Konkretion

So ist unser PC eine Konkretion der Abstraktion "Rechner". Ob es Sinn macht, die Abstraktion eines Objekts als Oberklasse zu definieren oder nicht, hängt rein vom Problembereich ab! Geht es um ein Produktionssystem, so ist diese Oberklasse vom Analysestandpunkt aus nützlich, geht es um einen reinen PC-Vertrieb, nicht.

Beim Programmieren hingegen bilde ich unter Umständen Oberklassen, die in einer vernünftigen Analyse keinen Platz haben - lediglich um den Mechanismus der Vererbung auszunutzen. Auch in der Designphase ist das möglich. Ein Beispiel wäre der "Partner" in einem Versicherungssystem. Diese Klasse umfaßt alle juristischen und natürlichen Personen, mit denen ein Versicherungsunternehmen Beziehungen unterhält. Sie bildet eine für Vererbungszwecke brauchbare Abstraktion, ist aber unter dem Analyseblickwinkel im allgemeinen zu dünn.

- Teil/Ganzes

Ein Prozessor wäre Teil unseres PCs, eines Ganzen. Diese vernünftige Strukturbeziehung wird meines Wissens aber kaum in der Implementierung durch OO-Sprachen unterstützt. Trotzdem ist sie in der Analysephase wichtig und spielt unter dem Stichwort Wiederverwendbarkeit (Reusability) auch im Design eine bedeutende Rolle.

- Kommunikation

Hier ist die Hauptarbeit zu leisten! Die Darstellung des Geschäfts- oder Produktionsprozesses ist das Kernstück der OOA. Vereinfacht kann zum Beispiel eine Buchung als Austausch zwischen drei Objekten dargestellt werden. Das Objekt "Buchung" (B) sendet an "Konto" (A) die Nachricht "100 an C" etwa in der Form (A, Subtrahiere, 100, C). "Konto" (C) empfängt von B (C, Addiere, 100, A). Nun müssen A und C noch ihre Aktionen bestätigen. Die Summe der an ein Objekt adressierbaren Nachrichten definiert den Leistungsumfang seiner Methoden und den notwendigen Satz von Daten, den es enthält. So muß die Klasse "Konto" in unserem Beispiel Informationen enthalten zum Buchungsdatum, zu Kontostand sowie Herkunft und Ziel einer Buchung. In diesem Sinne kann man (mit Coad/Yourdon) sagen, daß die Identifikation der Messages die Definition von Services erlaubt die die Objekte bieten sollen.

Die Modellierung des Kommunikationszusammenhangs ist eine Validierung des bereits gefundenen Ensembles von Attributen. Falls das Objekt "Konto" vom Objekt "Haftpflichtvertrag" gefragt werden kann, ob der Beitrag bereits bezahlt ist, müssen entsprechende Attribute und zum Service korrespondierende Prozeduren vorhanden sein.

Das Resultat der Analyse ist somit ein modulares und erweiterbares Modell von nach Abstraktion und Teil-Ganzes-Beziehung klassifizierten Objekten, die durch Attribute (Daten) und Dienste (Methoden) definiert sind und deren Beziehungen unter anderem durch den Austausch von Nachrichten gestaltet werden.