Die Entwicklung eines umfangreichen DV-Systems, etwa einer PPS-Lösung, gestaltet sich um so wirtschaftlicher, je höher der Anteil wiederverwendbarer Komponenten ist. Hilfsmittel dabei sind sogenannte Frameworks, also anwendungsneutrale Softwarekomponenten. Sie beinhalten generalisierbare Funktionen. Der Entwickler ergänzt die vom Framework vorgegebenen Klassenbibliotheken (Softwarekomponenten) um eigene Klassen. Hier kommen die objektorientierten Techniken "Vererbung" und "Template-Operationen" zum Einsatz. Die Anwendungsfunktionalität wird dann sowohl durch eigene Klassen als auch von Framework-Klassen abgebildet. Bezogen auf den Programmcode ist der Anteil an Framework-Klassen naturgemäß um so größer, je stärker die Anwendungsfunktionalität generalisiert werden kann.
Als Bausteine eines PPS-Modells dienen Business-Objekte. Sie werden aus den Beschreibungen der Geschäftsprozesse und aus den Klassendiagrammen des OOA-Modells abgeleitet. Dabei muß es möglich sein, daß sich wechselnde Geschäftsprozesse auch in den Business-Objekten widerspiegeln. Zur Steuerung dieser Veränderungen - eine Mehrfachverwendung der Komponenten vorausgesetzt - werden die Business-Objekte eingeteilt in Domain- und Applikationsobjekte.
Fachlicher Teil in Domain-Objekten
Aufgabe der Domain-Objekte ist die konsistente Bereitstellung aller Informationen, die für bestimmte Geschäftsprozesse notwendig sind. Sie repräsentieren damit den fachlichen Teil einer PPS-Implementierung. Zu ihren Aufgaben gehören:
-Speicherung der Informationen,
-Verwaltung der Beziehungen zu anderen Domain-Objekten und die Benachrichtigung bei Veränderungen,
-Konsistenzprüfungen,
-Kontrolle der Zugriffsberechtigung,
-Protokollierung von Veränderungen,
-automatische Ermittlung von Vorgabewerten sowie
-Persistenz und Transaktionen.
Applikationsobjekte werden in der Literatur auch als Controller-Objekte bezeichnet. Ihre Aufgabe ist primär die Vorgangs- oder Ablaufsteuerung. Im Falle von dialogorientierten Anwendungen übernehmen sie:
-die Verwaltung aller am Geschäftsprozeß beteiligten Domain-Objekte,
-die Weiterleitung von Aktionen des Benutzers an die betroffenen Modellobjekte und
-die Verwaltung aller für ein Domain-Objekt aktiven Dialogoberflächen.
Der eigentliche Dialog mit dem Anwender erfolgt durch User-Interface-Objekte, in denen die darstellungsspezifischen Informationen (Layout etc.) enthalten sind. Sie bilden die Schnittstelle zwischen den Applikationsobjekten und dem Anwender.
Berücksichtigt man noch die Schnittstelle zur Datenbank, entsteht auf diese Weise eine Vier-Schichten-Architektur, wobei den jeweiligen Objekten genau definierte Aufgabenstellungen zugeordnet sind. Das Modell bietet eine Reihe von Vorteilen. Da zwischen den einzelnen Schichten eindeutige Schnittstellen bestehen, kann die Verteilung der Objekte auf ein Rechner-Netzwerk erfolgen.
Bei "Fat-Clients" werden alle Schichten auf dem Client implementiert, die Kommunikation zur Datenbank erfolgt über die Objekte der Datenbank-Schnittstelle. "Thin-Clients" enthalten dagegen nur die Objekte der Dialogoberfläche. Weitere Aufteilungen sind möglich. Bei vielen PPS-Anwendungen ist es sinnvoll, Domain-Objekte zentral auf Servern zu implementieren, Applikationsobjekte und Dialogoberflächen jedoch auf dem Client zu lassen.
Die Anwendungslogik bleibt in dieser Konstellation unabhängig vom Fenstersystem und der verwendeten Datenbank. Das ermöglicht einen Austausch dieser Komponenten, beispielsweise den Einsatz eines Internet-Browsers anstatt der vom Betriebssystem vorgegebenen Fenstertechnik.
Kundenspezifische Änderungen in der Ablauflogik lassen sich durch Unterklassen ergänzen. Somit entsteht eine komplette Lösung aus dem Standardsystem mit den entsprechenden Oberklassen und den Erweiterungen in Form von Unterklassen.
Innerhalb grafischer Dialogoberflächen lassen sich passive Grafiken (Balkendiagramme, Netzdarstellungen) auch interaktiv bearbeiten. Die Verwendung interaktiver Dialoge führt dazu, daß sich die Komplexität der Software verringert, bei gleichzeitiger Steigerung von Funktionalität und Komfort. Dies kommt besonders PPS-Systemen zugute, bei denen üblicherweise 60 bis 70 Prozent des Codes von Stücklisten- und Arbeitsplan-Anwendungen für die Dialogsteuerung zuständig sind.
Dieser Anteil läßt sich durch die Einbindung von grafisch interaktiven Dialogen in der beschriebenen Vier-Schichten-Architektur erheblich verringern. Nahezu die gesamte Dialogfunktionalität ist anwendungsunabhängig durch Frameworks verfügbar. Dadurch ist es möglich, wesentlich variabler auf Veränderungen in den Dialogabläufen zu reagieren.
Wechselnde unternehmensinterne Aufgabenstellungen und variable von außen beeinflußte Geschäftsprozesse erfordern eine weitreichende Flexibilität auch bei der Kommunikation. Hier sollte ein sogenannter Kommunikationsbus als Bestandteil des PPS-Systems eingeführt werden. Absender und Empfänger von Nachrichten können in dieser Architektur sowohl die Anwender als auch Business-Objekte sein. Die Lösung unterstützt drei Kommunikationsrichtungen:
Im Fall "Anwender zu Anwender" arbeitet der Kommunikationsbus ähnlich wie ein E-Mail-System. Darüber hinaus bietet er die Möglichkeit, Domain-Objekte an die ausgetauschten Nachricht anzuhängen. Diese Fähigkeit unterstützt eine in vielen PPS-Geschäftsprozessen übliche Vorgehensweise, bei der ein Modellobjekt sukzessive von mehreren Anwendern bearbeitet wird. Ein Beispiel ist die Anlage und Überprüfung eines Auftrags. Der Empfänger einer Nachricht kann die angehängten Modellobjekte per Drag and drop in geeignete Dialogoberflächen integrieren und dort direkt weiterbearbeiten.
"Business-Objekt zu Business-Objekt" als zweite Kommunikationsvariante ist eine Alternative zur festen Verdrahtung von Domain-Objekt-Abhängigkeiten. Eine Veränderung führt hier nicht zur direkten Aktualisierung aller betroffenen Domain-Objekte. Statt dessen wird zunächst nur eine Nachricht an die Domain-Objekte geschickt. Dieses kann dann sowohl synchron als auch asynchron die notwendigen Reaktionen ausführen. Ein Filter im Kommunikationsbus sorgt dafür, daß die Häufigkeit dieser Nachricht einen eingestellten Sollwert nicht überschreitet.
Bleibt als dritte Kommunika- tionsrichtung noch "Business-Objekt zu Anwender". Sie unterstützt die Ereignisorientierung, so wie sie für viele PPS-Aufgaben gewünscht wird. Ein Modellobjekt benachrichtigt einen Anwender über ein Ereignis, das nicht automatisch vom System, sondern nur vom Benutzer bearbeitet werden kann. Hier greifen kundenspezifische Software-Agenten. Diese werden in den Kommunikationsbus geschaltet und sorgen dafür, daß sich einige der Ereignisse in eine Reihe automatischer Aktionen umsetzen lassen. Ihre Aufgabe ist es, die Nachrichten eines bestimmten Typs herauszufiltern und dann zu bearbeiten. Die Implementierung der Agenten kann schrittweise auch nach der Installation des PPS-Systems über standardisierte Schnittstellen erfolgen.*Uwe Hertel leitet die Firma Objekt Management für Software-Entwicklung und -Consulting in Tönisvorst.