Auf das DV-Management kommt ein erheblicher Umdenkprozeß zu: Künftig wird die Systementwicklung immer stärker geprägt sein vom Zusammenwirken der Faktoren Objektorientierung, unternehmensweites Datenmodell und biokybernetisches Systemverständnis. Dieter Hieke, Volker Oesinghaus und Hartmut Skubch* beschreiben eine Methode, die auf diesen Voraussetzungen basiert.

Die DMO-Methode besteht aus zwei aufeinander aufbauenden Teilen: der DMO-Analyse (DMO-A) und dem DMO-Design (DMO-D). Bei der DMO-Analyse ist ausschließlich das fachliche Problemfeld Gegenstand der Betrachtung. Erst beim DMO-Design werden Fragen zur Benutzerschnittstelle sowie zur Hard- und Software-Architektur der Zielumgebung (verteilte Systeme, Parallelverarbeitung etc.) berücksichtigt.

Die wichtigsten Begriffe (Meta-Elemente), die im Rahmen der DMO-Methode verwendet werden, sind:

- Objekte,

- Objekt-Attribute (Daten der Objekte),

- Objekt-Funktionen (Prozeduren der Objekte),

- Beziehungen (des Datenmodells), und

- Nachrichtenverbindungen (zeigen an, welche Objekte miteinander kommunizieren).

Ausgangslage für die DMO-Analyse ist ein - möglichst unternehmensweites - Datenmodell (UDM), außerdem eine Funktionsstruktur, wie sie im Rahmen der Entwicklung eines UDM in der Regel erstellt wird. Sie muß nicht unternehmensweit konsolidiert sein. Zusätzlich wird eine Sammlung von exemplarischen Geschäftsvorfällen benötigt; gewonnen werden können sie aus Aufzeichnungen der UDM-Interviews, aus Test-Geschäftsvorfällen, die für das UDM verwendet wurden, und aus existierenden Programmdokumentationen.

In der DMO-Analyse werden Objekte vom Typ "Datenmodell-(DM-)Objekt" beschrieben. Ein DM-Objekt basiert unmittelbar auf dem Datenmodell. Bei der Konstruktion dieser Objekte ist ihre Wiederverwendbarkeit von großer Bedeutung. Reihenfolge und Umfang der Geschäftsvorfall-Abwicklung spiegeln sich hier noch nicht wider. Alle DM-Objekte erben folgende Basis-Objektfunktionen: Erzeugen, Ändern, Löschen und Suchen/Anwählen.

Bei der DMO-Analyse wird in drei Schritten vorgegangen: Zunächst wird die gewünschte Anwendung grob spezifiziert, die abzubildenden Geschäftsvorfälle werden beschrieben und die zugehörigen Funktionen identifiziert; zusätzlich wird der benötigte Datenmodellausschnitt festgelegt.

Anschließend werden die DM-Objekte (Attribute, Objektfunktionen) definiert. Hierbei spielen die abgeleiteten Attribute und ihre zugehörigen Regeln (Objektfunktionen) eine große Rolle.

Unter Zuhilfenahme der Beziehungen des Datenmodells werden dann die Nachrichtenverbindungen erfaßt. Eine Nachrichtenverbindung ist vom Sender zum Emfänger gerichtet: "Sender sendet eine Nachricht; Empfänger empfängt eine Nachricht; Empfänger antwortet Sender".

Das DMO-Design ergänzt das in der DMO-Analyse erstellte Modell um die Kommunikation mit dem Benutzer und um die technologischen Komponenten. Im folgenden wird der Konstruktionsprozeß für eine Dialoganwendung detaillierter beschrieben. Hierzu wird ein weiter Begriff (Objekttyp) erforderlich, der des Dialog-Objekts.

Objekte vom Typ Dialog-Objekt (Dia-Objekt) stehen in direkter Verbindung zur Abwicklung von Geschäftsvorfällen, so daß innerhalb eines Dia-Objektes ein eng umgrenzter Arbeitsbereich (zum Beispiel Bearbeitung von Auftragsdaten) und durch Verkettung verschiedener Dia-Objekte - ein vollständiger Arbeitsablauf unterstützt wird. Das Dia-Objekt beschreibt Maskenlayout (Befehlsmenüs, Arbeitsbereich, Funktionstastenbelegung), Dia-interne Objektfunktionen (beispielsweise Berechnung eines Summenfeldes) und Objektfunktionen, die als Befehle über Menü-Auswahl oder Funktionstaste angesprochen werden können (zum Beispiel Verzweigen zu anderen Dia-Objekten oder Anstoßen einer DM-Objektfunktion).

Der Objektfunktion "Ereignis-Manager" kommt eine besondere Bedeutung zu. Der "Ereignis-Manager" übernimmt die Kontrolle, sobald ein Dia-Objekt aktiviert wird. Er reagiert auf Ereignisse wie Mausklick oder Funktionstaste und stößt die entsprechenden Objektfunktionen an. Objekte, die solche Objektfunktionen beinhalten, heißen "aktive" Objekte.

Eine Matrix (Dialog/Dialog), die die Verzweigungsmöglichkeiten von einem Dia-Objekt zu den anderen angibt, beschreibt den potentiellen Netzfahrplan des Anwendungssystems. Aus der Menge aller möglichen Verbindungen können - für bestimmte Benutzergruppen - Teilmengen identifiziert und in eine feste Reihenfolge gebracht werden, um bestimmte Arbeitsabläufe vorzugeben oder Lernkurven von Anwendern zu berücksichtigen.

Die Kommunikation mit dem Benutzer erfolgt entsprechend SAA-CUA-Standards, also mit Fenstertechnik inklusive Rollbalken, Größenveränderung und Verschieben sowie mit Pull-down-Menüs, Dialog-Boxen etc. Dabei wird beim Dia-Objekt nur von diesen Grundmöglichkeiten ausgegangen und die Hardware-abhängige Umsetzung zunächst außer acht gelassen. Die Umsetzung erfolgt erst in der darüberliegenden Schicht "Terminal-spezifische Übersetzung".

Je nach Art und Möglichkeiten der Hardware und des verwendeten Betriebssystems lassen sich weitere Objekt-Typen ergänzen, so Window-Objekte oder Grafik-Objekte (wie sie zum Beispiel im OS/2-Betriebssystem definiert sind). Jede weitere Rahmenbedingung der Implementierung kann zur Definition weiterer Objekttypen führen, beispielsweise Kommunikations-Objekte bei verteilter Datenverarbeitung. Für Batch-Anwendungen werden analog den Dialog-Objekten Batch-Objekte, für Reporte und Statistiken Report/Statistik-Objekte definiert. Jede weitere Anforderung führt zur Ergänzung des bestehenden Modells um weitere, sauber abgrenzbare Einheiten (Objekte).

Man sollte meinen, eine derartige Methode lasse sich kaum in einer traditionellen Entwicklungs- und Produktionsumgebung wirksam anwenden. Doch dies trifft nicht zu. Die DMO-Methode ist in ihrem Kern technikunabhängig. Erst in der Phase DMO-Design werden auch technologische Rahmenbedingungen berücksichtigt.

Vor der Implementierung stellt sich die Frage nach der Programmiersprache, der zu verwendenden Datenhaltung und dem einzusetzenden TP-Monitor. Da die DMO-Methode der objektorientierten Gedankenwelt sehr nahe steht, läßt sie sich am einfachsten mit einer OO-Sprache und einer zugehörigen OO-Datenbank implementieren. OO-Produkte finden aber erst sehr langsam in der kommerziellen Welt Verbreitung. Prozedurale Sprachen wie Cobol und PL/1 sowie 4GLs und hierarchische oder relationale Datenbanken sind derzeit die "Marktbeherrscher".

Andererseits beschreibt die DMO-Methode nur eine bestimmte Art, die Welt zu sehen. Die Umsetzung ist - bei entsprechend disziplinierten Vorgehen - auch mit traditionellen Sprachen und Datenbanken möglich. So können alle zu verwendenden Daten in einem Datenmodell beschrieben und in einer relationalen Datenbank definiert werden. Die zu verwendenden Objektfunktionen (mit Objektkennung) lassen sich in einer Prozedur-

Bibliothek ablegen. Ein zentraler "lnterpreter kann darin als Briefkasten fungieren, der Nachrichten entgegennimmt, den Empfänger identifiziert, die zugehörige Empfänger-Objektfunktion ausführt und dem Sender den Empfang bestätigt.

Die DMO-Methode ermöglicht durch die Erzeugung stabiler Einzelteile (Objekte) ein grundsätzlich anderes Vorgehen bei der Systementwicklung, als es das bisherige Wasserfallmodell angeboten hat. Bisherige Vorgehensmodelle spezifizieren ein System in Phasen möglichst detailliert und vollständig. Spätere Anpassungen sind kostspielig, aufwendig und erfreuen sich unter dem Aspekt der Wartung geringer Beliebtheit. Die Entwicklung mittels der DMO-Methode gleicht hingegen der Arbeit mit einem Legobaukasten, aus dem immer neue Entwicklungen hervorgehen und in der praktischen Anwendung reifen.

Die Anpassungsfähigkeit der mittels der DMO-Methode entwickelten Systeme wird erheblich erhöht durch die Einbettung in ein Schichtenmodell. Dieses Schichtenmodell orientiert sich an den unterschiedlichen Einflüssen, die auf ein Informationssystem wirken: an den Innovationen der l+K-Technologie, Änderungen der Aufbau- und der Ablauforganisation sowie des Geschäftsfeldes. Jede Klasse von Änderungen wird in einer eigenen funktionalen Schicht behandelt; dies kanalisiert ihre Auswirkung und begrenzt sie somit lokal.

Die fachliche Schicht wird mittels der DMO-Methode auf der Basis des unternehmensweiten Datenmodells entwickelt. Damit wirken nur noch Änderungen des Geschäftsfeldes auf diese Schicht.

Die Einbindung von Altsystemen gelingt ebenfalls über eine gesonderte Schicht, die im wesentlichen Schnittstellensysteme umfaßt. So können bestehende Systeme und Datenbestände schrittweise durch die neue Architektur abgelöst werden.

Entwickelt man den Gedanken: "Das unternehmensweite Datenmodell definiert alle wesentlichen lnformationszusammenhänge im Unternehmen" konsequent weiter, so ist es nur zwingend, daß der Sachbearbeiter am Bildschirm nicht mehr über vorgedachte, häufig nicht sehr ergonomische Dialogabläufe geführt wird, sondern daß ihm grundsätzlich die Strukturen und Kommunikationspfade des Datenmodells offenstehen. Erforderliche Einschränkungen beziehungsweise Führungshilfen können dynamisch in einer Steuerungsdatenbank implementiert werden. Das Datenmodell gewinnt damit eine ganz neue Qualität: Es wird zum Kommunikationsinstrument im Unternehmen schlechthin.

Objektorientierte Vorgehensweisen führen zu anpassungsfähigen Anwendungs-Architekturen. Sie benötigen als Stabilitätsfaktor ein unternehmensweites Datenmodell, das damit künftig noch mehr an Bedeutung gewinnen wird.

DMO ist eine Methode, die den bekannten Graben bei der Umsetzung der fachlichen Beschreibung in eine DV-technische Konzeption systematisch überbrückt. Diese Methode baut auf den Methoden E/R und SA auf, und viele DV-Abteilungen setzen sich bereits mit der Anwendung der Objektorientierung auseinander.

Werkzeuge, die die Ganzheitlichkeit dieses Vorgehens unterstützen, werden sich künftig am Markt durchsetzen und schrittweise Methoden wie DMO einbinden. Aber auch dies ist ein evolutionärer Prozeß; zum einen läßt sich DMO mit traditioneller Technologie verwirklichen, zum anderen ist CASE ebenfalls ein IV-System, das in der realen Umwelt reifen muß.

Die Anwendung dieser Methode hat eine Reihe von Auswirkungen: Die Projektlaufzeiten bis zur Freigabe der ersten Version einer Anwendung verkürzen sich erheblich. Die Zusammenarbeit mit den Fachbereichen wird konkreter und erfahrbarer. Software-Entwicklung bedeutet dann mehr ein Konstruieren und Montieren als ein permanentes individuelles Neuentwickeln.

Der Arbeitsplatz des Systementwicklers wird sich schrittweise technologisch verbessern. Sein organisatorisches Arbeitsumfeld und sein gesamtes Berufsbild erfährt aber grundlegende Veränderungen. Die Aufhebung der Trennung zwischen Entwicklung und Wartung ist dabei nur ein Aspekt. Den traditionellen Programmierer wird es für Neuentwicklungen bald kaum mehr geben. Kenntnisse in den klassischen Methoden (E/R und SA) sind eine gute Voraussetzung für den neuen Weg.

Auf das DV-Management kommt ein erheblicher Umdenkprozeß zu, der erforderlich ist, um den bevorstehenden Wandel zu gestalten. Nur wer selbst zum "Agent of Change" wird und nicht zum Objekt des Wandels, kann seine Mitarbeiter in notwendiger Weise motivieren.

Die Fachbereiche werden zügiger mit Anwendungen bedient und stärker in die Entwicklung eingebunden. Sachbearbeiter arbeiten künftig unmittelbar mit dem Datenmodell und erfüllen es so mit Leben. Durch die erreichte Flexibilität lassen sich verschiedene Organisationsformen auch parallel unterstützen.

Für das Unternehmen bedeutet dies vor allem Kostensenkung durch Wiederverwendung von Bausteinen und höhere Flexibilität bei organisatorischen und geschäftlichen Veränderungen.