Auch eine Bank agiert heute in einem stark wettbewerbsorientierten Umfeld. Daher müssen Bankdienstleistungen nicht nur marktorientiert, sondern auch in technologisch fortschrittlicher Form angeboten werden. Gisela Huhn* beschreibt, wie sich ein Banken-Informationssystem mit Hilfe des objektorientierten Ansatzes entwickeln läßt.

Der objektorientierte Ansatz leistet einen Beitrag dazu, die Aktivitäten einer Bank von einem umfassenden Standpunkt aus zu betrachten. Gleichzeitig wird damit ein neues Verständnis für das Bankengeschäft und seine Beziehungen zu anderen Wirtschaftseinheiten erweckt. Der objektorientierte Ansatz bietet nämlich die Möglichkeit, ein Modell zu entwickeln, das das Bankgeschäft in seiner Realität widerspiegelt.

Zunächst muß jedoch klar definiert werden, was unter einem objektorientierten Ansatz zu verstehen ist - insbesondere im Hinblick auf die Entwicklung eines -computergestützten Informationssystems: Innerhalb des objektorientierten Ansatzes wird das Informationssystem quasi als ein Modell der realen Welt betrachtet. Daten und Funktionen sind nicht mehr als getrennte Einheiten zu verstehen, sondern bilden ein in sich geschlossenes (gekapseltes) Objekt, das durch Datenstrukturen, Methoden und Kontrollstrukturen näher definiert wird. Dementsprechend stellt ein objektorientiertes System eine. Menge von Objekten dar, die zueinander in Beziehung stehen und über das Versenden von Nachrichten (Message-Passing) miteinander kommunizieren.

Während einige objektorientierte Systeme nur eine baumartige Hierarchie von Objektklassen erlauben, sind in anderen auch netzwerkartige, zyklenfreie Hierarchien erlaubt, wobei im zweiten Fall Strategien spezifiziert werden müssen, mit denen die Vererbung der Daten und Funktionen ausgeschlossen werden kann. Weitere Varianten beziehen sich auf die Auswahl der auszuführenden Methoden (Operationen), die entweder schon während der Compilierung feststehen (statische Bindung) oder erst zur Laufzeit des Programmes ausgewählt werden (dynamische Bindung).

Grundsätzlich läßt sich jedoch sagen, daß objektorientierte Systeme bezüglich ihrer theoretischen Konzeption der menschlichen Denkweise relativ nahe kommen. An dieser Stelle soll auf Parallelen zu den hierarchischen Netzwerkmodellen der Wissenspräsentation aus dem Bereich der kognitiven Theorie verwiesen werden. Entsprechungen gibt es vor allem in der hierarchischen Anordnung von Wissen auf verschiedenen Ebenen und in der Vererbung von Eigenschaften.

Variablen von Objektklassen

Ein aus dem Bankenumfeld genommenes Beispiel für eine Objekthierarchie ist die Klasse "Transaktion". Die für die Objektklasse charakteristischen Daten werden durch Klassenvariablen definiert. Auf der obersten Abstraktionsebene lassen sich der Klasse Variablen wie Betrag, Währung, Buchungstag und Valuta zuordnen.

Eine Spezialisierung dieser Transaktion stellt die Unterteilung in disjunkte Teilmengen (Subklassen) wie Einzahlung und Auszahlung dar. Die oben aufgezählten Variablen werden an die untergeordnete Klassen vererbt. Eine Einzahlung ist also ebenso durch einen Betrag, eine Währung, einen Buchungstag und eine Valuta gekennzeichnet wie eine Auszahlung. Die beiden Subklassen besitzen alle Eigenschaften der Oberklasse, können jedoch auch andere charakterisierende Eigenschaften besitzen.

Dasselbe gilt für die Methoden. Diese Methoden führen - im Gegensatz zu herkömmlichen Operationen - nur Operationen auf die Objekte der Klasse aus, für die sie definiert wurden. Methoden können also nicht unabhängig von den Objekten einer Klasse verstanden werden.

Diese zunächst als Einschränkung erscheinende Eigenschaft ergibt bei einer genaueren Betrachtung Sinn - auch im Hinblick auf eine Annäherung des Modells an die Realität. So wird eine Einzahlung zum Beispiel niemals auf eine Nachricht reagieren wie: "Bewege dich vom festen Punkt (X,Y) in eine bestimmte Richtung im zweidimensionalen Raum." Die entsprechende Methode wurde für die Subklasse Einzahlung einfach nicht definiert.

Die Vererbung ist eine der wichtigsten Eigenschaften objektorientierter Systeme. Sie sorgt dafür, daß untergeordnete Klassen auf die Methoden der Oberklasse reagieren können. Falls das System dies erlaubt, kann eine Unterklasse auch mehreren Oberklassen angehören und deren Methoden erben. In diesem Fall spricht man auch von multipler Vererbung.

Auch die Vererbung von Methoden läßt sich am Beispiel einer Transaktion demonstrieren. Sowohl Einzahlung als auch Auszahlung reagieren auf die Message: "Gib die Summe aller Geldbeträge an, die am 31. Dezember 1990 verbucht wurden." Der Grund dafür ist der, daß diese Methode bereits in der Klasse Transaktion definiert wurde.

Änderungen nur an einer Stelle

Die beiden Unterklassen erben also gleichermaßen den Code ihrer Objektklasse sowie deren Schnittstellen. Damit wird die Wiederverwendbarkeit des Codes sowie die Änderbarkeit existierender Systeme unterstützt.

Alle Unterklassen müssen im Hinblick auf ihre geerbten Eigenschaften ein konsistentes Verhalten aufweisen. Um dieser Forderung gerecht zu werden, brauchen Änderungen nur an einer übergeordneten Stelle vorgenommen zu werden und sind aufgrund des Vererbungskonzeptes automatisch auch für alle unteren Klassen gültig. Wichtig ist nur, daß für die Veränderung der richtige Einstiegspunkt innerhalb der Klassenhierarchie gewählt wird.

Die Kommunikation zwischen den Objekten verläuft über Nachrichten, die das Objekt veranlassen, eine bestimmte Methode auszuführen. Diese Messages sind also nichts anderes als die Spezifikation einer Objektmanipulation, wobei jede dieser Nachrichten durch die Angabe des Empfängers, des Selektors und der aktuellen Daten gekennzeichnet ist.

Der Austausch von Messages

Ein weiteres Merkmal objektorientierter Systeme ist der Polymorphismus. Der Begriff kommt aus dem Griechischen, wo er "Auftreten eines Stoffes in mehreren Erscheinungsformen" bedeutet. In der objektorientierten Systementwicklung bedeutet Polymorphismus, daß ein und dieselbe Nachricht an unterschiedliche Objektklassen gesendet wird, und diese Objekte auf die Nachricht in der Weise antworten, wie sie für die jeweilige Klasse definiert wurde.

Überträgt man diesen Gedanken auf ein Beispiel, so ist die Methode "Berechne Ertrag!" sowohl in der Klassenhierarchie Aktivgeschäft als auch in der Klassenhierarchie Passivgeschäft denkbar. Wird nun eine Nachricht an ein Objekt gesendet, so ist das Auftreten dieser Nachricht lediglich daran gebunden, ob der Empfänger über eine entsprechende Methode verfügt. Auf diese Weise wird die Unabhängigkeit der Entwicklung von Modulen unterstützt und gleichzeitig die Definition einheitlicher Schnittstellen erleichtert.

Ein weiteres Beispiel stellt die Programmierung zum Ausdrucken von Dokumenten dar: Ein Dokument wird ausgedruckt, indem ihm die Nachricht "Drucken" gesendet wird. Obwohl das Drucken bei verschiedenen Objekten unterschiedlich abläuft, wird "Drucken" vom gleichen Methodenselektor ausgelöst.

Kommt nun eine neue Dokumentenart hinzu, beispielsweise eine Tabelle, so kann dieses neue Dokument integriert werden, ohne den bestehenden Code zu ändern. Dazu wird dem neuen Objekt "Tabelle" lediglich die Methode "Drucken" zugewiesen. Auf diese Weise kann die Wartung großer Module werden.

Bindung erst zur Laufzeit

Unterschiedliche Nachrichten lösen jeweils unterschiedliche Methoden aus. Da Variablen in vielen objektorientierten Programmiersprachen nicht statisch typisiert sind, ist die auszuführende Methode erst dann eindeutig bestimmt, wenn die Nachricht versendet wird, also zur Laufzeit.

Im allgemeinen kann zur Compilier-Zeit nicht festgestellt werden, welches Objekt sich gerade im Nachrichtenaustausch befindet. Der Compiler ist demnach auch nicht in der Lage, den Nachrichtenaustausch an eine auszuführende Methode zu binden. Deshalb ist es sinnvoll, diese Bindung erst zur Laufzeit herzustellen. Dies steht im Gegensatz zu prozeduralen Sprachen wie Pascal, C oder Ada, bei denen ein Prozeduraufruf statisch vom Compiler an die auszuführende Prozedur gebunden wird.

Ein unmittelbarer Nachteil, der sich aus der dynamischen Bindung ergibt, ist die im Vergleich zur statischen Bindung längere Laufzeit. Diesem Nachteil stehen aber erhebliche Vorteile gegenüber: die Erleichterung der Modifikation, die Erweiterbarkeit von Softwaresystemen und die Wiederverwendungsmöglichkeiten des Codes.

Trotz ihrer vielfältigen neuen Ideen bildet die Idee des objektorientierten Ansatzes keinen Gegensatz zum funktions- und datenorientierten Ansatz. Vielmehr wird derzeit versucht, innerhalb des objektorientierten Ansatzes Merkmale des daten- und des funktionsorientierten Ansatzes zu berücksichtigen beziehungsweise diese etablierten und bewährten Ansätze zur Entwicklung von Systemen um objektorientierte Konstrukte zu ergänzen.

Frühere Ansätze konzentrierten sich bei der Entwicklung komplexen Systeme nur auf bestimmte Teilaspekte; mit dem objektorientierten Ansatz wird hingegen versucht, sämtliche Aspekte durch geeignete Methoden zu berücksichtigen. Demzufolge können das funktions- und das datenorientierte Modell als Teilmodelle eines objektorientierten Modells, das objektorientierte Modell hingegen als ein umfassendes globales Modell, das unterschiedliche Teilaspekte integriert, verstanden werden.

Ein Ausschnitt der realen Welt

Zurück zum Bank-Szenario: Bei dem zu modellierenden System handelt es sich um eine Bankorganisation, die ans verschiedenen Bankabteilungen besteht. Wesentliche Operationen sind die Bearbeitung von Geschäftsvorfällen, die weitgehend auf Formularen dokumentiert werden. Diese Formulare bestehen einerseits aus leeren Feldern, die iterativ mit Informationen ausgefüllt werden, andererseits aus Instruktionen, wie diese Felder auszufüllen sind und wohin diese Formulare nach jedem Bearbeitungsschritt weiterzuleiten sind. Auf diese Weise lassen sich alle Aktivitäten einer Bank vollständig dokumentieren.

Mit dem objektorientierten Ansatz kann dieses System derart modelliert werden, daß die Objekte, deren Verhalten und die Organisationsstruktur abbildet. Deshalb spiegelt dieses Modell einen Ausschnitt der realen Welt wider. Bei der Entwicklung eines objektorientierten Modells sind drei Schritte durchzuführen: Zunächst werden die Objekte identifiziert, die für die Abwicklung des Bankgeschäftes relevant sind.

In unserem Beispiel können wir diese Objekte aus dem Inhalt der Formulare ableiten. Die Bank besteht aus unterschiedlichen Abteilungen; diese Abteilungen sind mit Personal besetzt, das bestimmte Operationen ausführt; die auszuführenden Operationen werden auf den Formularen dokumentiert.

In einem zweiten Schritt müssen die Verbindungen zwischen den Objekten analysiert werden. Aus denn Text können wir weiter folgern, daß die Bank eine Vielzahl von Kunden hat, die mit Dienstleistungen zu versorgen sind. Das Personal bearbeitet die Formulare, wobei jedes Formular eine vollständige Operation darstellt.

Drittens sind die Merkmale der Objekte und deren Beziehungen zueinander zu identifizieren. So können zum Beispiel die leeren Felder der Formulare als Objektattribute (Daten) und die Instruktionen, wie diese Felder zu füllen sind, als Funktion (Methode) modelliert werden. Die Instruktion, wie die Formulare weiterzuleiten sind, läßt sich hingegen als Kontrollfluß (Life) bezeichnen.

Die logische Verknüpfung mit dem Inhalt, daß das Personal die Formulare bearbeitet, kann statisch als N-zu-m-Beziehung und dynamisch als Nachricht modelliert werden. Dazu ist die Information wichtig, wer das Formular für die Ausführung eines bestimmten Bearbeitungsschrittes erhält. Aus dem Formular muß also die Zuordnung eines Bankangestellten sind des von ihm auszuführenden Bearbeitungsschrittes ersichtlich sein. Im Idealfall geht aus dem Formular auch die zeitliche Abfolge der einzelnen Bearbeitungsschritte hervor.

Im Hinblick auf die wachsende Funktionalität einer Bankenapplikation sind alle diese Schritte wiederholt durchzuführen. Dabei können die bereits definierten Objekte wiederverwendet werden. Bereits existierende Objekte lassen sich verfeinern und zu neuen Objekten umbilden, sofern die Erfüllung einer neuen Operation dies erfordert.

Vorteile und Nachteile

Im Vergleich dazu ist die traditionelle Entwicklung einer Applikation oft unvollständig und redundant. Mit einer objektorientierten Analyse und einem entsprechenden Design lassen sich solche Nachteile vermeiden und eine Basis für die effiziente Entwicklung neuer Softwarelösungen herstellen. Im einzelnen weist der objektorientierte Ansatz folgende Vorteile auf:

- Er erlaubt die Entwicklung komplexen und trotzdem stabiler Systeme,

- minimiert das Risiko bei der Entwicklung komplexen Systeme und

- unterstützt die Wiederverwendung.

- In besonderem Maße lassen sich damit Redundanze, vermeiden.

- Außerdem bieten sich bessere und gezieltere Wartungsmöglichkeiten komplexen Systeme, da Schwachstellen besser lokalisiert werden.

- Und last, but not least kommt dieser Ansatz der menschlichen Denkweise nahe, so daß die Einarbeitung in das System leichter fällt.

Im Vergleich zum daten- und funktionsorientierten Ansatz weist der objektorientierte Ansatz allerdings auch einen Nachteil auf. Es wird eine längere Entwicklungszeit für komplexe Systeme benötigt, da der objektorientierte Ansatz sehr umfassend ist. Aber nur weil er das ist, kann er die Wiederverwendung unterstützen, die Weitergabe von Fehlern verhindern und so die Wartung vereinfachen.

*Gisela Huhn promoviert extern am Handelsinstitut für empirische Wirtschaftsforschung der Universität des

Saarlandes bei Professor Bruno Tietz.