Neue Ideen loesen bei den einen Begeisterungsstuerme aus, bei anderen Aengste und Ablehnung. Die Objektorientierung ist zwar gar nicht so neu, wenn man an Simula und Smalltalk aus den 70er und Clascal aus den 80er Jahren denkt. Aber der Weg von den Universitaeten und Forschungseinrichtungen in die Welt des Geschaefts dauert ja oft in vielen Bereichen zehn Jahre.

Reserviertheit begegnete auch uns, als wir vor etwa drei Jahren zum erstenmal versuchten, Objektorientierung in die Projektarbeit einfliessen zu lassen: "Haelt das Neue, was es verspricht?" "Wie werden Alt- und Neusysteme gekoppelt?" "Muss ich jetzt meine Entwicklungsmannschaft austauschen?" Und in den Koepfen der Anwendungsentwickler: "CASE, Workstation-Anwendungen und nun auch noch Objektorientierung. Schaffe ich den Sprung in diese neue Welt?"

Eine neue Methode muss nicht nur offene Probleme der Systementwicklung loesen, sondern auch Investitionsschutz gewaehrleisten und einen schrittweisen Uebergang sicherstellen. Nur so ist Akzeptanz zu erreichen, die eine wesentliche Voraussetzung fuer das Umsetzen von Neuerungen ist.

Kombination zweier Vorgehensweisen

Anforderungen aus den Bereichen Geschaeftspolitik, Aufbau- und Ablauforganisation und technologische Entwicklung verlangen vom Informations-Management ein flexibles und schnelles Reagieren, und das zu vertretbaren Kosten. Dazu sind heute die wenigsten Unternehmen in der Lage. Auch die Anstrengungen und Investitionen fuer CASE fuehrten in vielen Faellen nicht zu den gewuenschten Ergebnissen, da die Resultate der fruehen Phasen nicht in ein Moduldesign ueberfuehrt werden konnten, das Wiederverwendbarkeit und flexibles Konfigurieren (Steuerung) ermoeglicht.

DMO loest diese Probleme durch die Kombination einer Top-down- und einer Bottom-up-Vorgehensweise. Bottom-up wird den Anwendungsentwicklern eine im Unternehmen verbindliche DV- technische Anwendungsarchitektur (vgl. Abbildung 1) zur Verfuegung gestellt, die klare Schnittstellen zu immer wiederkehrenden Funktionen wie Oberflaechen-, Steuerungs-, Daten-, Kommunikations- und Systemdiensten beschreibt. Dadurch kann sich die Top-down- Methodik auf die geschaeftlichen Inhalte konzentrieren, um hier moeglichst glatt von der Analyse zu Design und Realisierung zu kommen und wiederverwendbare Anwendungsbausteine zu erhalten.

Wiederverwendbarkeit und Montierbarkeit werden also auf zwei Ebenen erreicht: der der DV-technischen Anwendungsarchitektur, die - transparent fuer den Entwickler - fuer unterschiedliche Zielplattformen implementiert sein kann, und der der Anwendungsbausteine, die durch die DMO-Methode wiederverwendbar konstruiert werden.

Das Vorgehen nach der DMO-Methode ist bestimmt durch kurze, evolutionaere Systementwicklungszyklen. Ausgehend vom abzubildenden Geschaeftsvorfall, werden (fuer Dialoganwendungen) die Schritte DMO- Analyse und DMO-Design im Wechselspiel durchgefuehrt. Die in diesem Prozess erzeugten Objekte (Dialog-, DM- und Reportobjekte) werden dann in der jeweiligen, fuer diese Objekte vorbereiteten Zielplattform zu einer lauffaehigen Teilanwendung verbunden. Diese kann getestet und ueberarbeitet werden und bildet den zu ergaenzenden Kern fuer die naechsten Analyse- und Designschritte. Da auf diese Weise geschaeftliche Analyse und schon auf die Realisierung ausgerichtetes Design sehr nahe beieinanderliegen, sollte in den Entwicklungsteams entsprechendes Know-how vertreten sein.

Ausgangspunkt der DMO-Methode ist ein Datenmodell (Entity Relationship Modell) des Problembereichs mit einer ausfuehrlichen Dokumentation der geschaeftlichen Bedeutung der darin enthaltenen Informationsobjekte mit ihren Attributen und Beziehungen. Es wird ergaenzt durch eine Beschreibung der dem Problembereich zugeordneten Funktionalitaet. Dies kann durch eine Sammlung von Funktionen oder eine Funktionsstruktur, zumindest aber durch eine Darstellung der relevanten Geschaeftsvorfaelle geschehen.

Aus diesen Vorgaben wird das Anwendungs-Objektmodell gebildet, wobei die Objekttypen (Klassen) dieser Datenmodell-objekte (DM- Objekte) im grossen und ganzen den Informationsobjekttypen des Datenmodells entsprechen. Die Attribute werden uebernommen, die Geschaeftsvorfaelle in objektbezogene Funktionalitaeten zerlegt.

Strikte Trennung der Verantwortlichkeiten

Die Schnittstelle zum Benutzer wird durch Dialogobjekte realisiert. Fuer Reports und Statistiken stehen Reportobjekte und fuer Hintergrundaktivitaeten Batch-Objekte zur Verfuegung. Die Methode ist gekennzeichnet durch eine strikte Trennung der Verantwortlichkeiten fuer verschiedene Aufgabenbereiche, wie sie einer modernen Anwendungsarchitektur einerseits und der Objektorientierung anderseits entspricht.

Im Unterschied zu anderen OO-Methoden werden Dialogebene (Dialogobjekte) und Anwendungsebene (DM-Objektevoneinander getrennt. Dies dient dazu, Geschaeftsvorfaelle zu zerlegen in nur vom Geschaeftsinhalt abhaengige Teile (DM-Objekte mit ihren Nachrichtenverbindungen) und in Teile, die von der Abfolge der Bearbeitung abhaengen (Dialogobjekte mit ihren Nachrichtenverbindungen). So sollen sich Aenderungen der Arbeitsorganisation in der Dialogebene abfangen lassen. Die DM- Ebene bleibt stabil.

Ein einfaches Beispiel aus der Touristikbranche soll zur Erlaeuterung der Methode dienen.

Es soll ein Anwendungssystem fuer ein Reisebuero entwickelt werden. Der hier abzubildende Geschaeftsvorfall heisst: "Kunde schliesst Vertrag". Der zugehoerige Datenmodellausschnitt ist in Abbildung 2 dargestellt.

Aus den abgebildeten Informationsobjekten werden DM-Objekte - genauer: DM-Objekttypen -, wobei "Kunde" und "Veranstalter" Subtypen von "Partner" werden (Vererbung). Die Attribute der Informationsobjekte sind demnach die Attribute der DM-Objekte. Den Objekten werden anschliessend Basis-Objektfunktionen zugeordnet, die ihren Lebenszyklus abbilden, wie "Anlegen", "Aendern", "Loeschen", "Stornieren", "Archivieren", "Status setzen" etc., und die Informationen aus dem einzelnen Objekt oder mehreren Objekten (zum Beispiel "Suchen") liefern. Fuer unseren Geschaeftsvorfall werden nur Basis-Objektfunktionen benoetigt: "Kunde: Suchen", eventuell: "Kunde: Anlegen (Key,...) und "Vertrag: Anlegen (Key,...,Kunde.Key)". In komplexeren Situationen kann eine Objektfunktion auch die Objektfunktion eines anderen Objekts zur Folge haben, dann wird diese von der ersten getriggert. So koennen Kaskaden von Objektfunktionen entstehen.

DMO-Design bezieht die Schnittstelle ein

Im DMO-Design wird das fachliche Modell um die Benutzer- Schnittstelle erweitert. Der Benutzer kann sich dabei der Dialog-, Report- und Hintergrund(Batch)-Objekte bedienen, um die fachlichen Funktionalitaeten der DM-Objekte fuer sich zu nutzen. Dialogobjekte verantworten die Darstellung und Verwaltung der fachlichen Objekte auf der Oberflaeche fuer den Benutzer. Ein Dialogobjekttyp ist dabei einem DM-Objekttyp direkt zugeordnet. Es kann zusaetzliche abgeleitete Attribute haben und zeigt die Verbindungen zu anderen Objekten, die ueber Beziehungen erreicht werden koennen.

Fuer das Beispiel werden die Dialogobjekte "Dia-Kunde" und "Dia- Vertrag" mit den Dia-Objektfunktionen "Dia-Vertrag: Anlegen", "Dia-Vertrag: Verzweigen (Kunde)" und "Dia-Kunde: Auswaehlen" benoetigt. Die Dia-Objektfunktionen triggern DM-Objektfunktionen und stellen so die Nachrichtenverbindung zwischen Dia- und DM- Objekten her. "Dia-Vertrag" und "Dia-Kunde" sind hier zu einem Dialog geklammert, in dem der Vertrag neu angelegt und die Beziehung zwischen Vertrag und Kunde hergestellt wird (vgl. Abbildung 3). Die Verwaltung aller Dialoge uebernimmt ein Dialog- Manager.

Report-Objekte fuer die Ausgabe zustaendig

Report-Objekte sind verantwortlich fuer alle Ausgaben ueber Druckdateien oder Drucker. Sie verwalten ferner das Layout des Ausdrucks und die technischen Daten. Dazu gehoeren der Name des Druckers, die Anzahl der Kopien, die Formularnummer und die Ausdruckszeit.

Ein Hintergrund(Batch)-Objekt kann asynchron zum Dialog oder vollkommen getrennt zu einem anderen Zeitpunkt laufen. Es steuert den Ablauf eines oder mehrerer Geschaeftsvorfaelle, die zumeist als Massenverarbeitung abgewickelt werden. Dazu benutzt es ausschliesslich DM-Objektfunktionen, die es aus einer eigenen Ablaufsteuerung aufruft.

Wenn man keine OO-Datenbanken einsetzt, sondern die Daten klassisch, zum Beispiel relational, abgelegt werden, so ist die Datenhaltung auf externen Speichern nicht in die DM-Objekte integriert. Beim Aufruf einer Objektfunktion, also dem Aufbau der Nachrichtenverbindung, sorgt eine gesonderte Objekttypfunktion dafuer, dass das gerufene Objekt sich im Hauptspeicher befindet und seine Adresse bekannt ist. Wie es dies bewerkstelligt, liegt nicht im Wissen des Objekts, sondern in einer eigenen Schicht. So entsteht Unabhaengigkeit von der darunterliegenden Datenbank. Der gleiche Weg wird fuer die Datenbanktransaktionen gewaehlt. Die Dialog-, Hintergrund- oder DM-Objekte bestimmen den Zusammenhang von gemeinsamen Objektveraenderungen in der Datenbank, indem sie Anfang und Ende der Transaktion setzen. Der Transaktions-Manager sorgt fuer deren korrekte Ausfuehrung oder Ruecksetzung.

Die DMO-Methode setzt auf bekannten Methoden der Datenmodellierung und Geschaeftsvorfall-Beschreibung auf.

Die DV-technische Anwendungsarchitektur trennt Datenhaltung, fachliche Verarbeitung, Oberflaechendarstellung und Dialogsteuerung.

Der Einstieg in die Objektorientierung auf der Datenhaltungsseite sollte auf jeden Fall mit relationalen Datenbanken und einer entsprechenden Schnittstelle erfolgen, solange objektorientierte Datenbanken noch nicht ihre Feuertaufe bestanden haben.

Die Realisierung der DMO-Methode ist auch mit traditionellen Programmiersprachen moeglich, wenngleich an die Disziplin der Realisierer groessere Anforderungen gestellt werden.

Das evolutionaere Prototyping in der Designphase draengt sich mit dem hier beschriebenen Vorgehen geradezu auf. Man erstellt die Objekte mit einigen Basismethoden und fuegt immer mehr Funktionalitaet und Ablaufsteuerung hinzu.

Kommunikation wurde einfacher

Im praktischen Einsatz hat sich gezeigt, dass DMO die Kommunikation zwischen Analytikern aus dem Fachbereich und Anwendungsentwicklern wesentlich vereinfacht. Auf der einen Seite werden die Geschaeftsvorfaelle eingehend analysiert und mit Hilfe der DM- und Dialogobjekte sinnvoll zergliedert. Die Schublaeden, in die eingeordnet werden soll, sind ja vorgegeben. Auf der anderen Seite ist diese Zergliederung schon so fein und geordnet, dass die Anwendungsentwickler ihre Module fast greifen koennen. Zur Dokumentation der DM-Objekte und der Nachrichtenverbindungen eignen sich auch Nicht-OO-Tools wie Bachman. Falls Dialogobjekte kein Pendant im Metamodell eines CASE-Tools haben, muss man sich mit der Definition eigener Dialogentitaeten oder der Dokumentation in einem Dialog-Editor behelfen.

Um DMO oder geeignete Elemente von DMO nutzen zu koennen, eignet sich eine Einfuehrung in drei Schritten:

- Durchfuehrung eines vier- bis fuenftaegigen Workshops auf der Basis eines realen Datenmodellausschnitts und tatsaechlicher Geschaeftsvorfaelle. Teilnehmer: Fachbereichsmitarbeiter, Anwendungsentwickler und Methodiker.

- Umsetzung der Workshop-Ergebnisse in eine Pilotanwendung.

- Einarbeiten der fuer richtig erkannten Resultate in das unternehmenseigene Vorgehens- und Methodenmodell.

Literatur:

Hieke, D.; Oesinghaus, V.; Skubch, H.: Unternehmens-Datenmodell plus OO-Ansatz gleich Synergieeffekt. In: CW 49 und CW 50/1990.

Unterlagen zu den Seminaren OBJ-A, OBJ-M und DMO der Informatik Training GmbH, Radolfzell.

*Werner Hegelin ist Leitender Berater und Dieter Hieke Management- Berater bei der Plenum Management GmbH in Wiesbaden.

Abb. 1: DV-technische Architektur

Eine einheitliche und verbindliche Anwendungsarchitektur erleichtert die Arbeit der Entwickler. Quelle: Hegelin/Hieke

Abb. 2: Datenmodell "Reisebuero"

Die DMO-Analyse bildet den Geschaeftsvorfall "Kunde schliesst Vertrag ab". Quelle: Hegelin/Hieke

Abb. 3: Dialog: Vertrag / Kunde

Das DMO-Design erweitert das rein fachliche Modell um die Gestaltung der Benutzerschnittstelle. Quelle: Hegelin/Hieke