Allenthalben ist von Business Re-engineering die Rede; die fachlichen Abläufe in den Unternehmen werden prozeßorientiert organisiert. Dabei entfaltet die Objektorientierung durch die Integration organisatorischer und informatischer Vorgehensweisen ihre Vorteile: Die DV-Systeme werden objektorientiert realisiert und verknüpfen die Informationsstruktur des Unternehmens - statische fachliche Objekte - mit den Unternehmensprozessen, mit dynamischen Objekten.

Die Gestaltung objektorientierter Lösungen besteht im wesentlichen aus der fachlichen und technischen Modellierung des DV-Systems. Es beginnt mit der Analyse des Ist- und Soll-Systems sowie einer groben Beschreibung der Aufgaben mit Hilfe der Use-Case-Methodik.

Die Ergebnisse einer vorangegangenen Prozeßanalyse lassen sich ideal als Basis für die Modellierung nutzen. Die einzelnen Arbeitseinheiten, die ein Sachbearbeiter an einem Ort ohne Unterbrechung mit DV-Unterstützung erledigt, sind die Use-Cases bei der fachlichen Analyse und die dynamischen fachlichen Klassen (Prozesse, Geschäftsvorgänge, Tätigkeiten) bei der Modellierung des DV-Systems.

Auf dieser Basis beginnt die fachliche Modellierung mit der Beschreibung der Informationen unter dem Titel Aufgaben in einem Objektmodell. Dies sind dann die statischen fachlichen Klassen. Die aus den vorgegebenen Use-Cases abgeleiteten Prozesse, die dynamischen fachlichen Klassen, benutzen, ändern oder erzeugen Objekte der ersten Klassen. Deshalb sollte zuerst das Objektmodell entstehen und dann die Modellierung der Prozesse. Letztere sollten zumindestens verbal beschrieben, besser noch durch dynamische Modelle dokumentiert werden.

Nach der Aufstellung der ersten "stabilen" Version des Objektmodells empfiehlt sich ein dynamisches Prototyping der aus den definierten Aufgaben (Use-Cases) abgeleiteten Prozesse. Die Prototypen zeigen die später als grafische Oberfläche sichtbaren Abläufe der Prozesse. Dadurch lassen sich in Zusammenarbeit mit den künftigen Anwendern und der Fachabteilung Probleme erkennen und Ungereimtheiten ausräumen.

Die objektorientierte Methode erlaubt eine parallele Vorgehensweise im Projekt. Das kann die Projektdauer - nicht aber den Gesamtaufwand - erheblich reduzieren. Und es verringert die während der Projektentwicklung auftretenden Änderungen in der Fachabteilung.

Die Mitarbeiter eines Projektteams sollten aus drei unterschiedlichen Bereichen kommen: Zum einen sind es Mitarbeiter der Fachabteilung beziehungsweise Anwender. Sie besitzen das Know-how in der Abwicklung der Fachvorgänge und kennen die zu erwartenden Aufgaben, ihre Wichtigkeit und die Notwendigkeit einer optimierten DV-Unterstützung. Ohne die Einbeziehung der Fachabteilungen ist keine bessere DV-Unterstützung für die Geschäftsprozesse zu erwarten.

Zum zweiten sind es die Organisatoren, besser: die Modellierer. Sie abstrahieren die Aufgabenstellung, integrieren das Projekt in die Unternehmensziele, sorgen für die Abstimmung mit den vorhandenen Systemen und setzen die Objektorientierung durch. Die DV-Entwickler setzen schließlich als dritter Bereich das fachliche Modell in ein objektorientiertes DV-Konzept um, führen zusammen mit den Modellierern das Prototyping durch, definieren die Systemarchitektur und übernehmen die technische Implementierung.

Die objektorientierte Vorgehensweise basiert auf einer der bekannten Methoden, vorzugsweise der Unified Modeling Language (UML). Die Methodik definiert die Regeln für die Beschreibung der Aufgaben durch die Use-Case-Modellierung und für die Aufstellung des Objektmodells für die statischen fachlichen Klassen.

Zur Modellierung der Prozesse sollte das Projektteam typische Szenarien durchspielen und, soweit erforderlich, in Sequenzdiagrammen (Event-Trace, Object-Message-Diagrams) dokumentieren. Dies verdeutlicht den Botschaftsfluß beziehungsweise die Kommunikation zwischen den Objekten. Darüber hinaus besteht die in der Praxis nur wenig genutzte Möglichkeit, die Dynamik der Prozeßobjekte in Zustands-Übergangs-Diagrammen festzuhalten.

Eine projektübergreifende fachliche Applikationsarchitektur, das Framework, verbindet die Ergebnisse der Modellierung. Es erlaubt eine umfangreiche Wiederverwendung von Strukturen, Komponenten und Szenarien.

Die technische Modellierung setzt auf den Lösungen der bereits realisierten objektorientierten DV-Systeme auf, nutzt die dort erstellten Generalisierungskonzepte sowie Strukturen und erweitert sie. Hierzu gehören Komponenten, die den Zugriff auf die verschiedensten Datenbanksysteme und die Kommunikation zwischen den DV-Systemen ermöglichen. Außerdem werden Basisklassen eingesetzt, mit denen man nicht-objektorientierte Programmbausteine einbinden und die komfortable Standardsoftware verwenden kann.

Es folgt die Überführung der Modelle in die technische Struktur. Dies beginnt mit der Feinplanung und schließlich der Fertigstellung der Klassen des statischen Modells. Der andere Aufgabenbereich besteht darin, die Prozesse (Use-Cases) zu strukturieren, in Klassen zu gliedern und zu implementieren.

Dauerthema aller Diskussionen um Objektorientierung ist die Datenspeicherung. Unverändert ist ein Kompromiß für objektorientierte Applikationen üblich: Die Speicherung der gemeinsamen Unternehmensdaten erfolgt auf Mainframes, auf dezentralen Daten-Servern und auf verteilten Objekt-Servern, und zwar überwiegend in relationalen Datenbanksystemen.

Objektorientierte Datenbanksysteme werden in den nächsten Jahren zusammen mit den geeigneten Kommunikationsmitteln einen gewissen Marktanteil erobern. Hierbei sind allerdings noch einige Hindernisse in puncto Sicherheit, Performance und Anbindung nicht-objektorientierter Anwendungen zu überwinden. Dies gilt vor allem für Großprojekte im organisatorischen Umfeld mit vielen Anwendern.

Für den Praktiker bedeutet dies, daß er heute mit relationalen Datenbanksystemen leben und gleichzeitig die objektorientierte Applikationsarchitektur so gestalten muß, daß er ohne großen Änderungsaufwand auf andere Datenbanksysteme migrieren kann, sobald dies für die weitere DV-Zukunft ratsam ist.

Der Trend geht hier zusammen mit Intranet-Applikationen zu Systemen mit verteilten Objekten, die Objekte relational speichern. Objekt-Server stellen Objekte und ihre Funktionalität bereit, Broker verteilen sie. Im Gegensatz hierzu stehen in klassischen Client-Server-Lösungen die Objekte und ihre Funktionalitäten auf jedem einzelnen Client separat zur Verfügung, während die Server lediglich Datensätze verwalten.

Für den Erfolg entscheidend ist eine Vorgehensweise, die sich in fachliche und technische Bestandteile gliedert. Dies ermöglicht eine hohe und mehrfache Parallelität, so daß man bereits parallel zur fachlichen Modellierung die technische Infrastruktur, also generalisierte Klassen, GUI-Richtlinien, Kommunikationskomponenten etc., aufbauen kann.

Wesentliche Teile des statischen fachlichen Modells lassen sich automatisch in "Sourcecode" umsetzen. Das relationale Schema kann generiert und die entsprechenden Tabellen der Datenbank automatisch erstellt werden. Durch die Generierung und durch die wiederverwendeten Komponenten entstehen zirka 70 bis 80 Prozent der statischen fachlichen Klassen, einschließlich der Datenbankzugriffe mit Transaktionen, Caching etc.

Zunächst brauchen alle Beteiligten ein Basistraining, das ihnen die Begriffswelt, die Methoden, die geplante Vorgehensweise und den Einsatz der erprobten Werkzeuge nahebringt. Der externe Berater mit einschlägiger Erfahrung unterstützt das Team als technischer Projektleiter bei der Definition einer Vorgehensweise, die sicher zum Ziel führt.

Die Arbeitsverteilung im Team sauber definieren

Er setzt die erforderlichen Methoden nutzbringend im Projekt ein und moderiert die Modellierung der Applikation. Hierzu gehört auch die Festlegung beherrschbarer Aufgabenpakete, die mehrere Teams parallel bearbeiten können.

Die technische Modellierung und die Implementierung sollten versierte Software-Entwickler mit Abstraktionsvermögen voranbringen, die dann zum einen die Programmierer bei der Realisierung beraten und ihnen zum anderen Hilfestellung bei der Auswahl und Verwendung von Software-Tools geben. Gleichzeitig erhöht sich die Produktivität durch die Entwicklung zentraler Module. Im Lauf der Realisierung wird das Entwicklerteam die Fähigkeit gewinnen, das Projekt selbständig zu betreuen und weitere Projekte unter eigener Regie anzugehen.

Nur eine solche professionelle Vorgehensweise führt zu produktiven, bezahlbaren und wiederverwendbaren Applikationen. Sie motiviert Geschäftsleitung, Mitarbeiter und Anwender, weitere Schritte in Richtung objektorientierte Systeme zu unternehmen.

Die objektorientierten und prozeßorientierten Vorgehensweisen verändern die DV-Welt in den Betrieben. Nur qualifizierte und teamorientierte Mitarbeiter ermöglichen erfolgreiche Projekte. Die neuen Anforderungen an ihre Qualifizierung wirken sich auf die Welt der Modellierer, Organisatoren, Analytiker, Designer, Implementierer und Anwender aus. Hiervon ist auch das Projekt-Management betroffen, das in Zukunft nicht mehr mit einer sequentiellen Methode nach dem "Wasserfall-Modell" rechnen kann. Vielmehr wird ein paralleles Vorgehen mit entsprechenden Meilensteinen und Iterationen benötigt.

Allein schon die Wiederverwendung von geprüften und dokumentierten Methoden, Architekturen und Klassen macht eine entscheidende Qualitäts- und Produktivitätssteigerung sehr wahrscheinlich. Darüber hinaus verbessern die Modellierung des Umfelds, die systematische Zusammenarbeit von Fachabteilung, Modellierern und DV-Entwicklung, die Gliederung in statische, wenig veränderliche Datenklassen und dynamische Geschäftsvorgänge, die sich häufig und schnell durch geänderte Anforderungen (aus dem Fachbereich) weiterentwickeln können, die Qualität der Software.

Kürzere Projektzeiten und geringere Kosten lassen sich insbesondere durch die Reduzierung der Zeit zwischen der Definition des Soll-Konzepts und der Implementierung erreichen. Wesentliche Faktoren sind die Wiederverwendung der Applikationsarchitektur, der Klassen des Objektmodells und der Basisklassen sowie die Benutzung von Generatoren, die standardisierte Bausteine erzeugen.

Literatur

- Große, S.; Anwendungsentwicklung mit Java und CORBA: Steckbrief JavaIn: Web Open Nr. 03/04 1997, S. 86-90.

- Letters, F.; Der OO-Führerschein für konventionelle Software-Entwickler und System-AnalytikerIn: Objekt-Spektrum Nr. 3, Mai/Juni 1995, S. 20-25.

- Schmidberger, R.; Client/Server-Realisierung mit C++: Standarddesign reduziert KostenIn: Datenbank Fokus Nr. 07/1996, S. 35-39.

- Schmidberger, R.; Umschalten ins Internet: Active X für MFC-ApplikationenTutorial im Rahmen der OOP 1997 in München 07.02.97.

- Booch, G., Rumbaugh J., Jacobson i.; The Unified Modeling Language for Object-Oriented Development, Version 1.0; Santa Clara: Rational 97.- Wanner, G.; Datenbanksysteme und Objektverteilung in kommerziellen SystemenIn: it Management Nr. 11/12 1996, S. 18-26.

Angeklickt

Die objektorientierte Vorgehensweise erlaubt es, moderne DV-Lösungen mit verteilten Objekten oder typische Client-Server-Systeme systematisch und effizient zu planen und zu realisieren. Entscheidende Erfolge setzen allerdings gut ausgebildete und motivierte Mitarbeiter voraus. Darüber hinaus ist eine durchgängige Methodik erforderlich, die durch geeignete Werkzeuge unterstützt wird und die garantiert, daß sich die fachlich definierten Aufgaben produktiv umsetzen lassen.

*Dr. Fritz Letters ist Geschäftsführer der IBL Ingenieurbüro Letters GmbH in Nürtingen und liest als Lehrbeauftragter der Fachhochschule für Technik in Esslingen Vorlesungen zu den Themen Datenmodellierungund objektorientierte Software-Entwicklung.