Wenn Software zur Unterstützung der Leistungserstellung dienen soll, muß es eine eindeutige und dauerhafte Verbindung zwischen dem Geschäftsprozeßmodell und der SW-Struktur geben.
Dabei definiert sich ein Geschäftsprozeß als eine Menge von unternehmensspezifischen Aktivitäten, die in logischem und zeitlichem Zusammenhang stehen und inhaltlich abgeschlossen sind. Im Rahmen eines Geschäftsprozesses werden Produktionsfaktoren kombiniert und Unternehmensleistungen erstellt.
Eine Verbindung von Geschäftsprozessen und Softwarestruktur läßt sich allerdings nicht problemlos herstellen. Die Methoden der Modellierung und der Objektorientierung scheinen sich zu widersprechen. Die Geschäftsprozeßmodellierung beschreibt Aufgaben und Funktionen im Rahmen der Leistungserstellung, der zentrale Aspekt ist dabei der Prozeß. Eine Vermeidung von Redundanzen und die Wiederverwendung von Modellkomponenten sind in vielen Fällen nur untergeordnete Ziele.
Anders verhält es sich bei der Objektorientierung. Sie dient der Beschreibung von Begriffen aus der Sicht der Software-Entwicklung. Das wesentliche Ziel dabei ist ein hohes Maß an Wiederverwendung, um das Produkt möglichst einfach pflegen zu können. Zwischen der Sicht der Geschäftsprozeßmodellierung und der Objektorientierung klafft somit eine Lücke, die durch eine methodische Verbindung überwunden werden muß.
Dabei sieht eine typische Aufgabenstellung wie folgt aus:
- Der Auftraggeber möchte ein objektorientiertes Konzept für ein Softwaresystem.
- Die zentralen Begriffe und Konzepte des Aufgabengebiets sind bekannt und lassen sich modellieren.
- Es ist schwer zu beurteilen, ob in dem so entstandenen Klassenmodell alle nötigen Klassen und Methoden zur Aufgabenerfüllung enthalten sind.
Der Blickwinkel von Anwendern ist in der Regel prozeßorientiert. Die Entwickler jedoch sehen die einzelnen Aufgaben prozeßübergreifend. So sollen etwa unter dem Gesichtspunkt der Wiederverwendbarkeit Teile des Systems in mehreren Prozessen benutzbar sein.
Anwendungsfälle beschreiben
Um eine Verbindung zwischen diesen beiden unterschiedlichen Sichten zu erreichen, ist eine Komponente nötig, die sich unter beiden Gesichtspunkten als Ausdrucksmittel eignet. Diese Verbindung läßt sich unter anderem durch die hauptsächlich von Ivar Jacobson eingeführte Methode des "Use Case" herstellen.
Unter Use Case, einem Anwendungsfall, versteht man eine mögliche Art Systeme zu benutzen, definiert durch eine Folge von Interaktionen zwischen den Objekten eines Systems. Wesentliches Kriterium eines Use Case ist der zeitliche Zusammenhang der Interaktionen. Typischerweise nimmt bei dialogorientierten Systemen der Nutzer als auslösendes und steuerndes Objekt eine zentrale Rolle ein.
Damit beschreibt ein Use Case die Bearbeitung einer Teilaufgabe innerhalb eines Geschäftsprozesses (siehe Kasten unten). Dabei lassen sich diese auch als Nachrichtenaustausch zwischen Objekten darstellen; die entsprechende Darstellungsform wird als Szenario bezeichnet. Use Cases können somit Verbindungen zwischen der prozeßorientierten Sicht des Anwenders und der auf Wiederverwendung ausgerichteten Sicht des SW-Entwicklers herstellen.
Als Hilfsmittel für die praktische Arbeit hat sich darüber hinaus eine Prozeß-Klassentabelle bewährt, in der sich Zusammenhänge zwischen Geschäftsprozessen und Klassen darstellen lassen (siehe Tabelle oben).
Ausgangspunkt sind hier die Geschäftsprozesse, mit denen sich die Leistungserstellung einer Organisation abbilden läßt. Im oberen Teil der Prozeß-Klassentabelle finden sich Geschäftsprozesse inklusive der Reihenfolge aller Vorgänge. Für jeden Use Case werden im unteren Teil der Prozeß-Klassentabelle die betroffenen Klassen und die dabei aufgerufenen Methoden dokumentiert.
Auf diese Weise entstehen Zusammenhänge zwischen Geschäftsprozeß- und Objektmodell. Vor allem ist erkennbar, ob die Klassen und Methoden vollständig sind. Ist das System zu erweitern und anzupassen, läßt sich anhand der Tabelle überprüfen, in welchen Geschäftsprozessen mit welchen Methoden auf einzelne Klassen zugegriffen wird.
Das auf diese Weise entstandene Klassenmodell läßt sich zudem genauer untergliedern. Der ersten Kategorie entsprechen Organisationseinheiten, die an der Abwicklung von Prozessen beteiligt sind. Sie finden ihren Niederschlag im Klassenmodell, wo sie als einzelne Objekte identifiziert und gespeichert werden. So stellt etwa ein Sachbearbeiter eine interne Organisationseinheit dar, die Prozesse steuert.
Eine zweite Kategorie liefern die Prozesse selbst. Darin liegt ein scheinbarer Widerspruch, da Prozesse eigentlich Gegenstand der Geschäftsprozeßmodellierung sind, während im Klassenmodell die Objekte beschrieben werden sollen, die in den Prozessen erzeugt und bearbeitet werden. In der Praxis ist diese Trennung häufig nicht einzuhalten. Um etwa betriebliche Abläufe zu dokumentieren, läßt sich für jeden Geschäftsprozeß eine Klasse definieren, deren Instanzen die konkreten Ausführungen dieses Prozesses sind und Informationen über den Zustand einer Prozeßausführung enthalten. Eine Klasse "Auftrag" umfaßt beispielsweise alle Informationen zu einem Auftrag und beschreibt den Prozeß zur Abwicklung von Aufträgen. Das Objekt Auftrag 0815 vom 17.12. 1996 zur Lieferung einer Waschmaschine an Willi Huber ist eine Instanz dieser Klasse.
Die dritte Kategorie bilden die Informationseinheiten. Jeder Begriff oder Gegenstand, der mit der Leistungserstellung zusammenhängt, ist als Objekt einer entsprechenden Klasse identifizierbar.
Das Geschäftprozeßmodell wird bei dieser Darstellungsweise zur direkten Grundlage des objektorientierten Modells. Änderungen von Geschäftsprozessen lassen die Auswirkungen auf die Software relativ leicht erkennen, Redundanzen erscheinen vermeidbar. Die Prozeß-Klassentabelle unterstützt damit das Finden von Klassen und Methoden, die Prüfung des Klassenmodells auf Vollständigkeit sowie eine Darstellung des Zusammenhangs zwischen Geschäftsprozessen und Klassen.
Beispiel - CASE
Die die Schritte des Use Case "Auftragsannahme" werden zunächst einmal beschrieben:
Auslöser des Use Case: Anruf eines Kunden
Interaktionen: (hier als Pseudocode formuliert)
Kunden nennt Name/Vorname
Sachbearbeiter sucht nach Kunde
WENN Kunde noch nicht vorhanden Sachbearbeiter legt Kunde an
Sachbearbeiter erfragt Kundendaten
Sachbearbeiter legt Auftrag an
Sachbearbeiter erfragt Auftragspositionen/Artikel
System prüft Verfügbarkeit und Liefertermin
Sachbearbeiter gibt voraussichtlichen Liefertermin an Kunde
WENN Kunde einverstanden Auftragsbestätigung
SONST Auftrag löschen
Ergebnis des Use Case: Bestätigter Auftrag
*Werner Achtert ist freier Autor aus Obermeitingen.