Transkript

1 Workow-Modellierung in NetCASE Jörg Jooss Fachbereich 4: Informatik Institut für Softwaretechnik Universität Koblenz-Landau Zusammenfassung Für die graphische Modellierung von Workows ist eine mächtige und zugleich intuitive Art der Darstellung wünschenswert. Diese sollte es zudem erlauben, neben dem reinen Ablauf von Prozessen auch den Informationsaustausch zwischen Workow-Aktivitäten sowie die beteiligten Ressourcen unmittelbar abzubilden. Im NetCASE-Ansatz stehen zur Workow-Prozeÿmodellierung die semiformalen APRIL-Diagramme und zur Ressourcenmodellierung Objektmodell-Diagramme zur Verfügung. Diese beiden Diagrammarten bilden im Rahmen von NetCASE die ausschlieÿlich benötigte Grundlage für die Erstellung von Workow-Modellen. Den Kern eines Workow-Modells bilden dabei die Prozeÿdenitionen, die die einzelnen Workows in Form von Aktivitäten, Kontrolluÿ und Datenuÿ darstellen. Dabei nehmen die Prozeÿdenitionen Bezug auf die an ihnen beteiligten Ressourcen (Akteure, Daten und Anwendungen), die im Organisationsmodell, im Datenmodell und in der Anwendungsdeklaration explizit beschrieben werden. Neben der vollständigen Abbildung aller workow-relevanten Informationen ermöglicht die Animation von APRIL-Diagrammen eine lebendige Darstellung, die zu einem besseren Verständnis der modellierten Prozesse bei den beteiligten Entwicklern und Anwendern beiträgt. 1 NetCASE ein Überblick NetCASE ist eine Petri-Netz-basierte Methode für den konzeptuellen Softwareentwurf. Der Fokus der Anwendungsentwicklung mit NetCASE liegt auf der Entwicklung von Informationssystemen (vgl. [Marx95] und [Marx97]). Über die Code-Generierung zur Interpretation innerhalb einer Workow-Laufzeitumgebung hinaus besteht hierdurch die Möglichkeit, die erstellten Diagramme direkt für den Softwareentwurf zu verwenden. Im Gegensatz zu anderen Methoden wie z.b. Leu [Slag96] ist Workow-Modellierung bei NetCASE daher nicht der einzige Anwendungsbereich. Deshalb wurde ein pragmatischer Ansatz gewählt, der es erlaubt, die bereits für den Softwareentwurf verwendeten Modellierungstechniken und deren Notation auch für den Workow-Entwurf zu nutzen. Bei den für den Workow-Entwurf verwendeten Diagrammarten handelt es um APRIL- Diagramme (Animated Process Illustration) [Schw97] und um die Objektdiagramme der Object Modeling Technique nach Rumbaugh et al. [Rumb93]. Auf letztere soll an dieser Stelle aufgrund ihres groÿen Bekanntheitsgrades nicht weiter eingegangen werden. APRIL-Diagramme APRIL-Diagramme dienen zur anschaulichen Darstellung von Abläufen und sind daher konzeptionell mit anderen Prozeÿdarstellungsmethoden wie FUNSOFT-Netzen [GrKa96] oder ereignisgesteuerten Prozeÿketten (EPK ) [KeNü92] vergleichbar. APRIL-Diagramme sind bewuÿt darauf ausgerichtet, von Auftraggebern und Entwicklern gleichermaÿen genutzt werden zu können eine gewisse Unschärfe in der Modellierung ist dabei sogar erwünscht. jooss@uni-koblenz.de

2 In APRIL-Diagrammen wird wie in Petri-Netzen zwischen zwei Arten von Knoten unterschieden: Aktionen stellen die aktiven, mit Transitionen vergleichbaren Elemente dar. Objektspeicher stellen die passiven Elemente dar, die Informationen aufnehmen und abgeben können, d.h. sie sind mit Stellen vergleichbar. Die Aktionen werden mit Kontrolluÿkanten verbunden, die mit Übergangsbedingungen versehen sein können. Aktionen und Objektspeicher können untereinander auÿerdem auch durch Objektuÿkanten verbunden sein, die einen lesenden, schreibenden oder verändernden Datenzugri beinhalten und anzeigen. Der Kontrolluÿ kann sich zwischen Aktionen entweder in Form von Nebenläugkeiten oder Alternativen verzweigen. Wenn eine Aktion nicht weiter ausgezeichnet ist, hat sie stets synchronisierenden Charakter (für Nebenläugkeit), ansonsten vereinigenden Charakter (für Alternativen). Die explizite Darstellung von Kontroll- und Datenuÿ in demselben Diagramm ist ein entscheidender Unterschied zu den bereits erwähnten FUNSOFT-Netzen oder EPK. Im Gegensatz zu Petri-Netzen sind APRIL-Diagramme keine bipartiten Graphen. Die Kontrolle wird direkt zwischen Aktionen weitergereicht, während Daten zwischen beiden Knotentypen in beliebiger Kombination ausgetauscht werden dürfen, d.h. Informationen können ohne die Verwendung von Zwischenspeichern bzw. ohne das explizite Eingreifen von Aktionen ausgetauscht werden. APRIL-Diagramme können auf mehrere Arten miteinader verknüpft werden. Die Hierarchisierung erlaubt die Verfeinerung von Aktivitäten. Derart verfeinerte Aktivitäten werden Prozesse genannt. 1 Durch die Verwendung externer Objektspeicher ist ein Informationsaustausch zwischen verschiedenen APRIL-Diagrammen möglich. Fener können Aktionen durch das Auslösen von Ereignissen Aktionen in anderen APRIL-Diagrammen anstoÿen. Für APRIL-Aktionen existiert keine formale Schaltregel. Das dynamische Verhalten des Systems wird durch Animationen visualisiert, die der Entwickler explizit im Rahmen von Drehbüchern entwirft. Diese beschreiben exemplarische Systemabläufe. Drehbücher nehmen vor allem Bezug auf die Diagrammstruktur und lassen die diversen Diagramman- bzw. - inschriften weitgehend auÿen vor. An der Universität Koblenz-Landau wird das CASE-Werkzeug NEPTUN entwickelt, daÿ alle für den Software- und den Workow-Entwurf mit NetCASE notwendigen Werkzeuge bereitstellt, insbesondere graphische Editoren für APRIL-Diagramme und deren Animation. Auf die Bereitstellung einer Entwurfsmethode für Workows wird zur Zeit noch verzichtet. 2 Workow-Modellierung in NetCASE Ein vollständiges Workow-Modell in NetCASE besteht aus vier Komponenten: Den Prozeÿdenitionen, dem Organisationsmodell, dem Datenmodell und der Anwendungsdeklaration. Diese Modelle und deren Umsetzung in NetCASE sollen in diesem Abschnitt anhand einer Beispielmodellierung erläutert werden. Der NetCASE-Ansatz nutzt den Vorschlag der Workow Management Coalition zur Entkopplung von Entwurfs- und Laufzeitumgebungen für Workow-Systeme. Dieser Vorschlag beruht auf der Denition einer Workow-Beschreibungssprache, der Workow Process Denition Language (WPDL). Somit können die in NetCASE erstellten Modelle als WPDL-Code exportiert werden. Die Namen der vier oben genannten Modelle wurden so gewählt, daÿ sie unmittelbar mit den von der WfMC gewählten Bezeichungen korrespondieren (vgl. [WfMC97] und [WfMC94]). 1 Der Begri Prozeÿ ist leider etwas unglücklich gewählt und sollte nicht mit Prozeÿ im Kontext von Workows verwechselt werden.

3 Prozeÿdenitionen werden im NetCASE-Ansatz durch APRIL-Diagramme dargestellt. Diese erlauben es, den Kontrolluÿ, den Datenuÿ, die beteiligten Akteure und Werkzeuge innerhalb eines Diagramms festzuhalten. Die erstellten Prozeÿdenitionen können animiert dargestellt werden, so daÿ Workow-Entwürfe gut visualisierbar sind. Darüberhinaus erönen sich eine Reihe von Prüf- und Analysemöglichkeiten, mit denen ein Workow-Modell auf zahlreiche Eigenschaften hin untersucht werden kann. Grundlegende Voraussetzung dazu ist die korrekte Abbildung von Abhängigkeiten und Beziehungen zwischen Aktionen, deren Zugri auf die verschiedenen Arten von Betriebsmitteln sowie die Spezikation der letzteren innerhalb der von NetCASE bereitgestellten Diagrammarten. Zum einen kann durch Überprüfung der Struktur der APRIL-Diagramme sichergestellt werden, daÿ nur für Prozesse erlaubte Strukturen verwendet werden. Potentielle Medienbrüche lassen sich durch die Art und Weise, in der Aktivitäten auf Daten zugreifen, erkennen. Ferner können die von der WfMC für Workow- Modelle vorgesehenen Simulationsdaten für Analyseanwendungen genutzt werden. So lassen sich mit diesen beispielsweise die Durchlaufzeiten und Kosten von Prozessen oder alternativer Ausführungspfade berechnen. Da auf nebenläugen Pfaden durch konkurrierende Betriebsmittelzugrie Konikte entstehen können, können solche Engpässe durch den Vergleich der benötigten und der vorhandenen Betriebsmittelinstanzen identiziert werden. Zur Erstellung des Datenmodells, des Organisationsmodells und der Anwendungsdeklaration werden wie beim NetCASE-Softwareentwurf Objektdiagramme eingesetzt. Auch hier ergeben sich Prüfmöglichkeiten zur Wahrung der Vollständigkeit des Workow-Modells, da der Verwendung eines Betriebsmittels dessen Denition im Organisationsmodell, Datenmodell bzw. in der Anwendungsdeklaration vorausgehen muÿ. Das hier verwendete Beispiel, dem eine reale Anwendung zugrunde liegt, zeigt das Vorgehen eines Performance-Monitoring-Teams, das regelmäÿig die Festplattenbelegung von Fileservern in einem Computernetzwerk überwacht und verhindert, daÿ die Festplattenbelegungen der Fileserver einen als kritisch angesehenen Grenzwert überschreiten. 2 Prozeÿdenitionen Den Kern eines Workow-Modells bilden die Prozeÿdenitionen, die die einzelnen Workows beschreiben. Sie bestehen im wesentlichen aus zwei Elementen: Aktivitäten und Transitionsinformationen (Kontrolluÿ). Auÿerdem nimmt eine Prozeÿdenition Bezug auf alle an dem Prozeÿ beteiligten Betriebsmittel. Unter dem Begri Betriebsmittel verstehen wir hier (menschliche) Akteure, Anwendungsprogramme und Daten. Diese werden im Organisationsmodell, im Datenmodell und in der Anwendungsdeklaration beschrieben (s.u.). Abbildung 1 zeigt die Prozeÿdenition Kapazitaetsanalyse als APRIL-Diagramm. Aktivitäten werden als APRIL-Aktionen (Rechtecke), Subprozesse als APRIL-Prozesse (Rechtecke mit Doppelrahmen) und Betriebsmittel als Objektspeicher (Kreise) dargestellt. Transitionsinformationen werden als APRIL-Kontrolluÿ mit gestrichelten, Betriebsmittelzugrie als APRIL-Datenuÿ mit durchgezogenen Kanten dargestellt. Es gibt jeweils exakt einen ausgezeichneten Start- und Endknoten. Um die drei verschiedenen Arten von Betriebsmitteln unterscheiden zu können, werden für Akteure, Daten und Anwendungen jeweils unterschiedliche Icons verwendet. Auch Aktivitäten können durch die Verwendung von Icons dekoriert werden, um einen graphischen Hinweis auf die verrichtete Tätigkeit zu geben. Der Prozeÿ beginnt mit der Aktivität Belegungsanalyse zur Erstellung eines Auslastungsberichts. Der Bericht wird in der Berichtedatenbank gespeichert. Anschlieÿend wird versucht, durch das Löschen unbenötigter bzw. temporärer Daten (Festplatten saeubern) und das Ver- 2 Das Beispiel basiert auf den Erfahrungen des Autors bei einer IT-Unternehmensberatung.

4 Abbildung 1: Die Prozeÿdenition zu Kapazitaetskontrolle schieben von Benutzer-Verzeichnissen auf weniger ausgelastete Platten (User umziehen) wieder mehr Platz zu schaen. Das Verschieben von Benutzern wird auÿerdem in der Aktionsdatenbank protokolliert. Aufraeumen und User umziehen können parallel erfolgen. Daher verzweigt sich der Kontrolluÿ nebenläug über diese beiden Aktivitäten. Danach wird in der Bedarfsanalyse der Kontrolluÿ wieder synchronisiert und der tatsächliche Bedarf an neuen Festplatten ermittelt. Die von Systemmanager zu den vier genannten Aktivitäten laufenden Objektuÿkanten bedeuten, daÿ diese Aktivitäten jeweils von einem Systemmanager ausgeführt werden müssen. Die von Systemmanagement-Tool auslaufenden Objektuÿkanten zu Belegungsanalyse bzw. Bedarfsanalyse zeigen, daÿ diese Aktivitäten unter Verwendung dieser Applikation durchgeführt werden. Für den Kontrolluÿ ergeben sich anschlieÿend zwei Alternativen, erkennbar an den Kantenanschriften. Wenn die bisherigen Aktionen bereits ausreichend Platz geschaen haben, d.h. Bedarf = 0, wird der Prozeÿ mit der Aktivität Abschluss fortgesetzt. Ansonsten (Bedarf > 0) ist die Anschaung neuer Festplatten notwendig. Die Aktivität Abschluss dient lediglich zur Zusammenführung der Alternativen. Der vereinigende Charakter dieser Aktivität wird durch den in das Rechteck eingezogenen Kreis symbolisiert. 3 Danach ist der Prozeÿ beendet. Die Prozeÿdenition Kapazitaetsanalyse nimmt Bezug auf mehrere extern modellierte Entitäten: Systemmanager ist eine Entität des Organisationsmodells, Systemmanagement-Tool wird in der Anwendungsdeklaration beschrieben und der Subprozeÿ Bestellen wird eine durch eigene Prozeÿdenition (z.b. Hardwarebeschaung) mit einem separaten APRIL-Diagramm deniert. Organisationsmodell Das Organisationsmodell in NetCASE deniert alle für die Workows relevanten Akteure. Die explizite Organisationsmodellierung wird von der WfMC nicht gefordert, dennoch ist sie gerade im Hinblick auf die Wiederverwendbarkeit unverzichtbar. Das NetCASE-Organisationsmetamodell basiert auf dem korrespondierenden Metamodell des WfMC -Vorschlags und unterscheidet sieben Klassen von Akteuren: Organisationseinheit 3 Dies ist leider in der Abbildung nicht gut erkennbar, da diese suggeriert, der Kreis sei Teil des den Aktivitätsknoten schmückenden Icons.

5 sowie die drei Verfeinerungen Stelle, Unternehmen und Komplexe Organisationseinheit und ferner Rolle, Person und Ressource. Die letzt genannte Klasse erachten wir eigentlich nicht als Teil des Organisationsmodells, sie ist aber enthalten, um die Konformität zum WfMC - Metamodell zu wahren. Die Instanzen des Organisationsmodells werden aus den Klassen des Organisationsmetamodells gebildet. Dabei steht es dem Entwickler oen, die Klassen des Metamodells um eigene Attribute zu erweitern. Eine Erweiterung des Metamodells um Assoziationen und Methoden wird aus Konformitätsgründen zur WfMC nicht unterstützt. An dem Prozeÿ Kapazitaetskontrolle ist nur eine Art von Akteuren beteiligt, der Systemmanager. Dabei handelt es sich um eine Rolle (Funktion), die auf alle Organisationseinheiten bzw. Stellen abgebildet wird, die mit der Rolle assoziiert sind. Beispielsweise kann das zuvor erwähnte Performance-Monitoring-Team als mit Systemmanager assoziierte Organisationseinheit modelliert werden, so daÿ jedes Teammitglied über die Rolle Systemmanager verfügt. Als Alternative hierzu könnte das Team auch aus einzelnen Stellen gebildet werden, die dann explizit der Rolle Systemmanager zugeordnet werden. Das APRIL-Diagramm zeigt ferner, daÿ zwei Instanzen von Akteuren mit der Rolle Systemmanager vorhanden sein müssen, damit die beiden Aktivitäten Festplatten saeubern und User umziehen wirklich nebenläug durchgeführt werden können. Die Ermittlung solcher kritischen Pfade, bei denen Aktivitäten potentiell gleichzeitig auf dieselbe Klasse von Betriebsmitteln zugreifen, ist zugleich ein Beispiel für eine auf APRIL-Diagrammen aufsetzende Analyseanwendung. Datenmodell Das Datenmodell beschreibt alle Daten, die für Anwendungen und Workows benötigt werden. Hierbei handelt es sich zum einen um in den Aktivitäten zu bearbeitende bzw. zwischen Aktivitäten auszutauschende Dokumente. Der Begri Dokument umfaÿt hier sowohl Dokumente in elektronischer als auch in nichtelektronischer Form. Den anderen Teil des Datenmodells bilden die für den Kontrolluÿ von Prozessen notwendigen Entscheidungsparameter. Der Entwickler kann durch die Verwendung elementarer Datentypen und Typkonstruktoren (Tupel, Liste und Menge) eigene Datentypen erstellen und im Objektmodell nach seinem Ermessen Generalisierungs- und Aggregationsbeziehungen sowie binäre Assoziationen einführen. Die Verwendung von Methoden ist innerhalb des Datenmodells nicht erlaubt. Der Beispielprozeÿ verwendet zwei Datentypen, die jeweils auf Datenspeichern abgelegt werden: Die erzeugten Auslastungsberichte werden in der Berichtedatenbank gespeichert. Falls Benutzerverzeichnisse verschoben werden, wird dies in der Aktionsdatenbank gespeichert. Daher sind im Datenmodell wenigstens die beiden Klassen Bericht und Aktion als abstrakte Dokumente zu denieren. Ferner muÿ der Entscheidungsparameter Bedarf im Datenmodell abgebildet werden. Anwendungsdeklaration Die Anwendungsdeklaration beschreibt alle Computerapplikationen, die in den denierten Workows Verwendung nden. Der Entwickler erstellt hierzu je nach gewünschtem Abstraktionsgrad für jede Anwendung entweder eine Klasse, eine Klasse und eine oder mehrere Instanzen oder ausschlieÿlich Instanzen. Wird eine Anwendung nur in Form einer Klasse abgebildet, stellt diese eine Abstraktion einer Menge realer Applikationen dar, d.h. Anwendungen werden nur in Form allgemeiner Begrie wie Textverarbeitung oder WWW-Browser dargestellt. Die Zuordnung dieser abstrakten Beschreibungen zu konkreten Anwendungen muÿ in diesem Fall vom Workow- Laufzeitsystem erledigt werden. Dies erhöht die Flexibilität des Workow-Entwurfs. Der Entwickler darf in seinem Klassenmodell Generalisierungsbeziehungen einführen, aber keine At-

6 tribute, Methoden oder sonstige Assoziationen, da diese nicht in WPDL überführt werden können. Wird eine Anwendungsklasse um Instanzen ergänzt, kann der Entwickler hiermit die konkreten Anwendungen beschreiben. Durch die explizite Begrenzung der vorhandenen Instanzen einer Anwendung können Ressourcenbeschränkungen abgebildet werden, beispielsweise weil für eine Software nur begrenzt Nutzungslizenzen verfügbar sind. Wenn eine umfassende Abbildung der vorhandenen Applikationen nicht erwünscht oder nicht benötigt wird, kann sich der Workow-Entwickler auf die Erstellung von Instanzen beschränken. Dieser Ansatz stellt eine schlichte Aufzählung der verfügbaren Applikationen dar und eignet sich aufgrund seiner geringen Flexibilität nur für kleinere Workow-Anwendungen. Die Signatur der Anwendungen wird durch ihre Assoziation mit vom Entwickler konstruierten Parameterklassen als Aufruf- und Rückgabeparameter beschrieben. Die konkreten Aufrufe der Anwendungen werden durch die Zuordnung von Parameterinstanzen ausgedrückt. Wenn für eine Anwendung sowohl eine Klasse als auch Instanzen erstellt werden, kann überprüft werden, ob die in Prozessen verwendeten Anwendungsaufrufe der Signatur der Anwendungen entsprechen wird zu einer Anwendung keine Klasse erstellt, ist dies nicht möglich. In dem Beispielprozeÿ Kapazitaetsanalyse wird zweimal eine Instanz der Applikation Systemmanagement-Tool verwendet. Dies ist eine abstrakte Beschreibung, die vom Workow-Laufzeitsystem einer vorhandenen Software zugeordnet werden muÿ. Die Verwendung einer rein abstrakten Beschreibung ist in diesem Beispiel sinnvoll, da zu verschiedenen Server-Plattformen herstellerspezische Managementwerkzeuge existieren können, so daÿ der Entwurf unabhängig von der Zielumgebung sein sollte. 3 Fazit und Ausblick Wir haben den im Rahmen der Softwareentwurfsmethode NetCASE entwickelten Ansatz zur Erstellung WfMC -konformer Workow-Modelle vorgestellt. Den Kern eines Workow-Modells bilden hierbei die Prozeÿdenitionen, die mit Hilfe der semiformalen APRIL-Diagramme dargestellt werden. Den Prozeÿdenitionen werden das Organisationsmodell, die Anwendungsdeklaration und das Datenmodell in Form von Objektdiagrammen zur Seite gestellt, die die für das Workow-Modell relevanten Akteure, Anwendungen und Daten denieren. An einem Beispiel haben wir die Modellierung einer praktischen Anwendung skizziert. Der NetCASE-Ansatz der Workow-Modellierung zielt auf drei Aspekte ab. Die lebendige Darstellung von Prozessen mittels Animationen dient einer erhöhten Anschaulichkeit der Entwürfe für Anwender und Entwickler. Der Export von Workow-Modellen als WPDL- Code ermöglicht die Verwendung der Entwürfe in WfMC -konformen Laufzeitsystemen. Die Möglichkeit zur Analyse- und Überprüfung der Modelle, die hier nur knapp skizziert werden konnte, erönet zahlreiche Möglichkeiten zur Sicherstellung ihrer syntaktischen Korrektheit, Vollständigkeit und der Identikation bzw. Berechnung relevanter Eigenschaften wie Betriebsmittelengpässen. Mein Dank gilt Herrn Thomas Marx für seine tatkräftige Unterstützung während der Erstellung meiner Arbeit. Literatur [GrKa96] Gruhn, V., Kampmann, M. (1996): Modellierung unternehmensübergreifender Geschäftsprozesse mit FUNSOFT-Netzen. In: Wirtschaftsinformatik

7 38 (1996) 4, S [Herr98] [KeNü92] [LaSc97] [Marx95] [Marx97] [Rumb93] [Schw97] [Slag96] [WfMC94] Herrmann, G. (1998): Transformation von APRIL-Diagrammen in Petri- Netze. Diplomarbeit (in Arbeit), Koblenz: Universität Koblenz-Landau, Fachbereich Informatik. Keller G., Nüttgens M., Scheer, A.-W. (1992): Semantische Prozeÿmodellierung auf Grundlage,Ereignisgesteuerter Prozeÿketten (EPK)`. Saarbrücken: Veröentlichungen des Instituts für Wirtschaftsinformatik (IWi), Universität des Saarlandes. Langner, P., Schneider, C., Wehler, J. (1997): Prozeÿmodellierung mit ereignisgesteuerten Prozeÿketten (EPKs) und Petri-Netzen. In: Wirtschaftsinformatik 39 (1997) 5, S Marx, T. (1995): NetCASE a Petri Net based Method for Database Application Design and Generation. Koblenz: Universität Koblenz-Landau, Fachbereich Informatik. Marx, T. (1997): A Petri Net Approach to Conceptual Modelling and CASE. In: CAiSE'97. Proceedings of the 4th Doctoral Concortium on Advanced Information Systems Engineering. Barcelona. Rumbaugh, J. et al. (1993): Objektorientiertes Modellieren und Entwerfen. München: Hanser; London: Prentice Hall. Schweitzer, T. (1997): APRIL Animierter Prozessillustrator. Diplomarbeit, Koblenz: Universität Koblenz-Landau, Fachbereich Informatik. Slaghuis, H. (1996): Der direkte Übergang von BPR zum Workow mit Leu. In: Becker, J. et al. (Hrsg.): Workowmanagement Stateof-the- Art aus Sicht von Theorie und Praxis. Proceedings zum Workshop vom 10. April Münster, S Workflow Management Coalition (1994): The Workow Reference Model. Brüssel: Workow Management Coalition. [WfMC97] Workflow Management Coalition (1997): Interface 1: Process Denition Interface. Brüssel: Workow Management Coalition.