DE19951152A1 - Startbedingungen für Aktivitäten in Workflow Management Systemen - Google Patents

Abstract

Die vorliegende Erfindung betrifft Mittel zur Definition und Berechnung einer Startbedingung für Aktivitäten in einem Prozeßmodell, das von einem Workflow Management System (WFMS) verarbeitet werden kann; das genannte Prozeßmodell umfaßt Aktivitäten, die Knoten eines Graphen sind, und gerichtete Steuerungskonnektoren, die einen potentiellen Steuerungsfluß definieren. DOLLAR A Die Mittel zur Definition einer Startbedingung ermöglichen die Spezifikation eines ersten und/oder eines zweiten logischen Ausdrucks. Enthalten sind Sofort-Berechnungsmittel zur Bewertung des Wahrheitswerts des genannten ersten logischen Ausdrucks unmittelbar in Antwort auf einen abgelegten Wahrheitswert eines ankommenden Steuerungskonnektors einer Ziel-Aktivität. Mittel zur verzögerten Berechnung sind enthalten, die den Wahrheitswert des genannten zweiten logischen Ausdrucks erst dann bewerten, wenn der Wahrheitswert aller ankommenden Steuerungskonnektoren, der Teil des genannten zweiten logischen Ausdrucks ist, abgelegt ist. Die Verarbeitung zum Starten der genannten Zielaktivität wird erst fortgesetzt, wenn der genannte erste und/oder der genannte zweite logische Ausdruck mit TRUE bewertet wird.

Description

1 Hintergrund der Erfindung 1.1 Gebiet der Erfindung

Die vorliegende Erfindung betrifft Mittel zur Definition und Mittel zur Berechnung von Startbedingungen für die Aktivitäten in einem Prozeßmodell, das von einem Workflow Management System (WFMS) oder von einem Rechnersystem mit vergleichbaren Funktionen verarbeitet werden kann.

1.2 Der Stand der Technik und seine Nachteile

Ein neuer Technologiebereich von zunehmender Bedeutung ist das Gebiet der Workflow Management Systeme (WFMS). WFMS un­ terstützen die Modellierung und Ausführung von Geschäftspro­ zessen. Geschäftsprozesse steuern, welche Aufgaben eines Netzwerks von zu erledigenden Aktivitäten von wem ausgeführt werden und welche Ressourcen hierfür herangezogen werden, d. h., ein Geschäftsprozeß beschreibt, wie ein Unternehmen seine Geschäftsziele erreichen kann. Die einzelnen Aufgaben können auf eine Vielzahl verschiedener, miteinander vernetz­ ter Rechnersysteme verteilt sein.

Der Prozeß des Entwerfens, Entwickelns und Herstellens eines neuen Produkts und der Prozeß der Veränderung oder Adaption eines vorhandenen Produkts steilen Produkt-Manager und Inge­ nieure gleichermaßen vor die Lösung komplexer Aufgaben, da das Produkt möglichst kostengünstig und zeitgerecht auf den Markt gebracht werden und die Produktqualität dabei erhalten bleiben oder erhöht werden soll. In vielen Unternehmen hat man inzwischen erkannt, daß der herkömmliche Prozeß des Pro­ duktentwurfs hierfür oft nicht ausreicht. Bereits zu einem sehr frühen Zeitpunkt müssen in die Entwurfsarbeiten Fragen der Fertigungstechnik, der Kostengestaltung, der logistischen Planung, der Beschaffung, der Fertigung sowie Service- und Supportfragen einbezogen werden. Darüber hinaus ist eine Planung und Kontrolle der Produktdaten beim Entwurf, bei der Freigabe und der Herstellung des Produkts notwendig.

Die richtige und effiziente Ausführung der Geschäftsprozesse innerhalb eines Unternehmens, z. B. der Entwicklungs- oder Produktionsprozesse, ist für ein Unternehmen von enormer Be­ deutung und ist am Gesamterfolg eines Unternehmens auf dem Markt wesentlich beteiligt. Aus diesem Grund sind diese Pro­ zesse ähnlich zu bewerten, wie die technologischen Prozesse und müssen ebenso wie diese geprüft, optimiert und überwacht werden. Die Verwaltung solcher Prozesse wird gewöhnlich mit Hilfe eines rechnergestützten Verfahrens oder eines Workflow Management Systems durchgeführt und unterstützt.

In "Project Management Environment" von D. J. Spoon, IBM Technical Disclosure Bulletin, Band 32, Nr. 9A, Februar 1990, Seite 250 bis 254, wird eine Prozeßmanagementumgebung mit einer Betriebsumgebung, Datenelementen sowie Anwendungsfunktionen und -prozessen beschrieben.

In "IBM's FlowMark, Object-Oriented Workflow for Mission- Critical Applications" von R. T. Marshak, Workgroup Computing Report (USA), Band 17, Nr. 5, 1994, Seite 3 bis 13, wird der Objektcharakter von IBM FlowMark als einem Client/Server-Produkt beschrieben, das auf einem echten Objektmodell aufgebaut ist, welches für die Entwicklung und den Einsatz einer Anwendung für unternehmenswichtige Produktionsprozesse konzipiert wurde.

In "Workflow Management Based on an Object-Oriented Paradigm" von H. A. Inniss und J. H. Sheridan, IBM Technical Disclosure Bulletin, Band 37, Nr. 3, März 1994, Seite 185, werden andere Aspekte der objektorientierten Modellierung im Zusammenhang mit der Anpassung an Kundenbedürfnisse und in Verbindung mit Änderungen beschrieben.

In "Business Process Management with FlowMark" von F. Leymann und D. Roller, Digest of papers, Kat. Nr. 94CH3414-0, Spring COMPCON 94, 1994, Seite 230 bis 234, wird das neueste rechnergestützte Prozeßmanagement-Tool, IBM FlowMark, beschrieben. Es wird sowohl das Metamodell von IBM FlowMark als auch die Implementierung von IBM FlowMark vorgestellt. Die Möglichkeiten von IBM FlowMark für die Modellierung von Geschäftsprozessen sowie auch deren Ausführung werden erörtert. Das Produkt IBM FlowMark ist für die verschiedenen Rechnerplattformen erhältlich, eine Dokumentation zu IBM FlowMark kann über jede IBM Niederlassung angefordert werden.

In "A meta model to support the modeling and execution of processes" von F. Leymann, Proceedings of the 11^th European Meeting on Cybernetics and System Research EMCR92, Wien, Österreich, 21. bis 24. April 1992, World Scientific 1992, Seite 287 bis 294, wird ein Metamodell zur Steuerung von Ge­ schäftsprozessen vorgestellt und im einzelnen erörtert.

"IBM FlowMark for OS/2", Dokument Nr. GH 19-8215-01, IBM Corporation, 1994, erhältlich in jeder IBM Verkaufsniederlassung, ist ein typisches modernes, hochentwickeltes und leistungsstarkes Workflow Management System. Es unterstützt die Modellierung von Geschäftsprozessen als ein Netzwerk von Aktivitäten; siehe hierzu beispielsweise "Modeling Workflow", Dokument Nummer SH 19-8241, IBM Corporation, 1996. Als weitere Informationsquelle über Workflow Management Systeme, die in den IBM Verkaufsniederlassungen erhältlich ist, seien fol­ gende Dokumente erwähnt: IBM MQSeries Concepts and Architecture, Dokument Nummer GH 12-6285; IBM MQSeries Getting Started with Buildtime, Dokument Nummer SH 12-6286; IBM MQSeries Getting Started with Runtime, Dokument Nummer SH 12-6287. Dieses Aktivitäten-Netzwerk, das Prozeßmodell, ist aufgebaut als gerichteter, azyklischer, gewichteter, farbiger Graph. Die Knotenpunkte dieses Graphs sind die durchzuführenden Aktivitäten oder Arbeitselemente. Die Kanten des Graphs, die Steuerungskonnektoren, beschreiben den potentiellen Ablauf für die Ausführung der Aktivitäten. Die Definition des Prozeßgraphs erfolgt über die IBM FlowMark Definition Language (FDL) oder den eingebauten Graphikeditor. Die Laufzeitkomponente des Workflow Managers interpretiert den Prozeßgraphen und verteilt die Ausführung der Aktivitäten auf die richtige Person am richtigen Platz, z. B. durch Zuweisen von Aufgaben zu einer Aufgabenliste für die betreffende Person, wobei diese Aufgabenliste in Form von digitalen Daten in dem genannten Workflow- oder Prozeßmanagement-Rechnersystem gespeichert ist.

In "Managing business processes as an information resource" von F. Leymann und W. Altenhuber, IBM Systems Journal, Band 32(2), 1994, wird die mathematische Theorie beschrieben, die dem IBM FlowMark-Produkt zugrundeliegt.

In "Verifikation von Workflows in IBM FlowMark" von D. Roller und in "Geschäftsprozeßmodellierung und Workflows" von J. Becker und G. Vossen (Hrsg.), International Thompson Publishing, 1995, wird die Notwendigkeit und die Möglichkeit einer Verifikation von Workflows beschrieben. Des weiteren wird das Merkmal der graphischen Animation zur Verifikation der Prozeßlogik vorgestellt, wie es in IBM FlowMark implementiert wurde.

Zur Implementierung eines rechnergestützten Prozeßmanagementsystems müssen zunächst die Geschäftsprozesse analysiert und als Ergebnis dieser Analyse ein Prozeßmodell in Form eines Aktivitätennetzwerks aufgestellt werden, das die einzelnen Geschäftsprozesse enthält. In IBM FlowMark werden die Prozeßmodelle nicht in ein ablauffähiges Programm transformiert. Bei Laufzeit wird aus dem Prozeßmodell eine Instanz des Prozesses erstellt, die als Prozeßinstanz bezeichnet wird. Diese Prozeßinstanz wird dann dynamisch von IBM FlowMark interpretiert.

Im typischen Fall arbeitet ein Benutzer mit dem Workflow Ma­ nagement System über eine graphische Benutzerschnittstelle, auf der die vom Benutzer auszuführenden Aufgaben in Form von Icons dargestellt sind. Die Arbeit für eine bestimmte Aufgabe wird vom Benutzer durch Doppelklick auf das betreffende Icon gestartet. Hierdurch wird ein Programm gestartet, das die jeweilige Aktivität ausführt.

Wie bereits weiter oben erwähnt wird bei einem Prozeßmodell eine Aktivität, die Ursprungsaktivität, mit einer anderen Aktivität, der Zielaktivität, über Steuerungskonnektoren miteinander verbunden. Wenn eine Aktivität der Ursprung mehrerer Steuerungskonnektoren ist, bezeichnet man sie als Verzweigungsaktivität. Alle Aktivitäten, die Zielaktivitäten der von der Verzweigungsaktivität abgehenden Steuerungskonnektoren sind, werden parallel ausgeführt. Eine Aktivität, die das Ziel mehrerer Steuerungskonnektoren ist, wird als Verbindungsaktivität bezeichnet. Allen Aktivitäten sind Bedingungen zugeordnet, die festlegen, wann die Aktivität ausgeführt werden kann und wann sie erfolgreich ausgeführt ist. Verbindungsaktivitäten sind mit einer Zusatzbedingung verbunden, die angibt, wann eine Aktivität, in die ein Steuerungskonnektor einmündet, beginnen kann. Diese Bedingung heißt Startbedingung. Nur wenn die Startbedingung mit TRUE bewertet wird, kann die eigentliche Verarbeitung der Zielaktivität gestartet werden, beispielsweise mit der Verarbeitung der Aktivie­ rungsbedingungen, die weitere Kriterien enthalten können, die zu erfüllen sind, bevor die Zielaktivität ausgeführt werden kann.

Folgende Möglichkeiten für die Behandlung von Startbedingun­ gen sind bisher bekannt:
Nur MQSeries Workflow unterstützt Startbedingungen als Teil seines Metamodells, d. h., innerhalb des Prozeßmodells. Alle anderen Workflow Management Systeme unterstützen diese Art von Bedingung für Aktivitäten nicht. In diesem zuletzt ge­ nannten Fall wird die Aktivierungsbedingung geprüft, unmit­ telbar nachdem ein Steuerungskonnektor am Verbindungsknoten eingetroffen ist; mit anderen Worten, es wird keine Verarbeitung von Startbedingungen angeboten, da die Verarbeitung der Zielaktivitäten sofort gestartet wird, wenn ein Steuerungskonnektor einen logischen TRUE-Wert für die Zielaktivität abgelegt hat. Der Arbeitsfluß wartet nicht, bis andere Steuerungskonnektoren an der Aktivität angekommen sind. Wenn ein zweiter Steuerungskonnektor an der Aktivität ankommt, wird die Aktivität ein zweites Mal ausgeführt. Der Prozeßentwerfer muß sicherstellen, daß dies entweder nicht passiert oder daß die zweite Verarbeitung der Aktivität keine negativen Auswirkungen hat. MQSeries Workflow implementiert eine einfache Version einer Startbedingung.

Die Verbindungsaktivität wird als Synchronisationspunkt behandelt. Die Bewertung findet erst statt, wenn alle ankommenden Steuerungskonnektoren an der Aktivität angekommen sind. Die beiden einzigen Einstellungen, die von der Startbedingung unterstützt werden, sind ALL oder LEAST ONE. Wenn ALL vorgegeben ist, müssen alle ankommenden Steuerungskonnektoren mit TRUE bewertet worden sein; wenn LEAST ONE vorgegeben ist, muß mindestens einer der ankommenden Steuerungskonnektoren mit TRUE bewertet worden sein.

Keine dieser Möglichkeiten, also überhaupt keine Startbedin­ gungen oder der Synchronisationstyp der Startbedingung, ist vollkommen zufriedenstellend. Mit der heutigen Technik können nicht alle Arten von Beziehungen zwischen den ankommenden Steuerungskonnektoren abgewickelt werden. Bei der heutigen Technik wäre es also erforderlich, daß die Aktivität selbst bestimmte Prüfungen im Hinblick auf den Status anderer ankommender Steuerungskonnektoren übernehmen würde; dies widerspricht aber dem grundlegenden Ansatz des WFMS, nämlich aus einem Netzwerk von sich gegenseitig beeinflussenden Aktivitäten alle Steuerungsinformationen in Bezug auf diese gegenseitigen Wechselbeziehungen zu extrahieren und die einzelnen Aktivitäten in Bezug auf diese Wechselbeziehungen zu in sich geschlossenen Programmen zu machen.

1.3 Aufgabe der Erfindung

Die Erfindung hat die Aufgabe, Möglichkeiten für die Defini­ tion und für die Berechnung von Startbedingungen für Aktivitäten innerhalb eines Prozeßmodells zu verbessern, das von einem Workflow Management System (WFMS) verarbeitet wird.

2. Zusammenfassung und Vorteile der Erfindung

Die Aufgaben der Erfindung werden von den Ansprüchen 1 und 5 gelöst. Weitere vorteilhafte Anordnungen und Ausführungsbei­ spiele der Erfindung sind in den jeweiligen Unteransprüchen dargelegt.

Die Erfindung betrifft Mittel zur Definition von Startbedin­ gungen und Mittel zur Berechnung von Startbedingungen in ei­ nem Rechnersystem, das als Workflow Management System (WFMS) arbeitet. Das WFMS umfaßt mindestens ein Prozeßmodell, wobei das genannte Prozeßmodell ein oder mehrere Prozeßaktivitäten umfaßt, die Knoten eines beliebigen Graphen sind, und gerichtete Steuerungskonnektoren des genannten Graphen, die einen potentiellen Steuerungsablauf in dem genannten Prozeßmodell definieren. Die Startbedingungs- Berechnungsmittel definieren und bewerten, ob eine Zielaktivität gestartet werden kann, abhängig vom Wahrheitswert ankommender Steuerungskonnektoren der genannten Zielaktivität.

Die Startbedingungs-Definitionsmittel erlauben die Vorgabe eines ersten logischen Ausdrucks. Die Startbedingungs- Berechnungsmittel umfassen Sofort-Berechnungsmittel zur Bewertung des Wahrheitswerts des genannten ersten logischen Ausdrucks, unmittelbar in Antwort auf einen abgelegten Wahrheitswert eines ankommenden Steuerungskonnektors, der Teil des genannten ersten logischen Ausdrucks ist. Die Startbedingungs-Berechnungsmittel setzen dann die Verarbeitung fort und starten die genannte Zielaktivität nur dann, wenn der genannte erste logische Ausdruck mit TRUE bewertet wird.

Alternativ oder zusätzlich erlauben die Startbedingungs- Definitionsmittel die Vorgabe eines zweiten logischen Ausdrucks. Die Startbedingungs-Berechnungsmittel umfassen Mittel zur verzögerten Berechnung, die den Wahrheitswert des genannten zweiten logischen Ausdrucks erst bewerten, wenn der Wahrheitswert aller ankommenden Steuerungskonnektoren, der Teil des genannten ersten logischen Ausdrucks sind, abgelegt ist. Die Startbedingungs-Berechnungsmittel setzen dann die Verarbeitung fort und starten die genannte Zielaktivität erst dann, wenn der genannte zweite logische Ausdruck mit TRUE bewertet wird.

Die vorliegende Erfindung stellt eine wesentliche Verbesse­ rung dieser Bearbeitung bei der Berechnung von Startbedingungen dar. Erstens können Startbedingungen jetzt logische Ausdrücke von beliebiger Komplexität sein, basierend auf den logischen Werten der ankommenden Steuerungskonnektoren. Zweitens kann durch die Einführung zweier dedizierter Zeitpunkte für die Bewertung der Startbedingungen die Erfindung jede zeitliche Beziehung zwischen ankommenden Steuerungskonnektoren bearbeiten. Prozeßmodelle, die bis jetzt nur statische Bedingungen modellierten, wurden also erweitert und können jetzt mit zeitlichen Abhängigkeiten ankommender Steuerungskonnektoren arbeiten. Natürlich ist die hier vorgestellte Methode auch in der Lage, das Bewertungsverhalten von Startbedingungen der bisherigen Workflow Management Systeme zu reproduzieren. Zeitliche Abhängigkeiten ankommender Steuerungskonnektoren, die nach dem bisherigen Stand der Technik innerhalb der Prozeßaktivitäten selbst abgewickelt werden müßten, können jetzt auf der Ebene des Workflow Management Systems abgewickelt werden; sie wurden dadurch auf der globalen Ebene der Prozeßmodelle deutlich gemacht und sind nicht mehr innerhalb der Aktivitätsimplementierungen "versteckt".

Die Erweiterung der Startbedingungsdefinition und der Start­ bedingungsberechnung durch Nachbearbeitungsfunktionen, die ausgeführt werden, wenn der logische Ausdruck der Startbedingung mit TRUE bewertet wird, führt zu einer weiteren Erhöhung der Flexibilität. Bevor die eigentliche Aktivitätenverarbeitung gestartet wird, sind die Nachbearbeitungsfunktionen der ideale Ort für die Bearbeitung des in Instanzen zerlegten Prozeßmodells als Ergebnis der Entscheidung, die genannte Zielprozeßaktivität zu starten. Wie in einem weiteren Ausführungsbeispiel der vorliegenden Erfindung vorgeschlagen wird, wäre es mit den genannten Nachbearbeitungsfunktionen möglich, alle später ankommenden Steuerungskonnektoren der Zielaktivitäten innerhalb des genannten, in Instanzen zerlegten Pro­ zeßmodells zu ignorieren. Dadurch wird es möglich, Situatio­ nen zu modellieren, in denen eine bestimmte Zielaktivität nur einmal ausgeführt wird. Wie in einem weiteren Ausführungsbeispiel der vorliegenden Erfindung vorgeschlagen wird, würden die genannten Nachbearbeitungsfunktionen eine Beendigung aller Aktivitäten erlauben, die der genannten Zielaktivität innerhalb des genannten, in Instanzen zerlegten Prozeßmodells vorangehen. Damit wird es sogar möglich, eine zusätzliche Bearbeitung von Aktivitäten zu vermeiden, die das Gesamt-Verarbeitungsergebnis des in Instanzen zerlegten Prozeßmodells nicht mehr beeinflussen.

Um die Definition komplexer logischer Ausdrücke als Startbe­ dingungen etwas komfortabler zu gestalten, wird in einem weiteren Ausführungsbeispiel der Erfindung eine Unterstützung für die Definition eines logischen Ausdrucks M_OUT_OF eingeführt, der von dem genannten WFMS mit TRUE bewertet wird, wenn mindestens M Steuerungskonnektoren einer vorgegebenen Menge von ankommenden Steuerungskonnektoren der genannten Zielaktivität mit TRUE bewertet werden.

3. Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Diagramm, das die Verarbeitung für eine "Verbindungsaktivität" zeigt.

Fig. 2 zeigt eine Verbindungsaktivität, die das Ziel dreier Steuerungskonnektoren ist. Das Beispiel ist die Grundlage für die Erörterung von verschiedenen Beispielen logischer Ausdrücke, die Startbedingun­ gen zugeordnet werden können.

Fig. 3 zeigt einen Teil eines Prozeßmodells, das die Ver­ arbeitung von Konferenzunterlagen abwickelt. Das Beispiel dient zur Erläuterung des Nachbearbei­ tungsvorgangs IGNORE.

Fig. 4 zeigt einen Teil eines Anspruchs-Prozeßmodells, das die Verarbeitung der Kommunikation mit einem Kunden abwickelt. Das Beispiel dient zur Erläuterung des Nachbearbeitungsvorgangs TERMINATE.

4. Beschreibung des bevorzugten Ausführungsbeispiels

Die vorliegende Erfindung wird anhand des Workflow Managment Systems IBM FlowMark erläutert. Natürlich könnte statt dessen auch ein anderes WFMS eingesetzt werden. Des weiteren gilt die vorliegende Lehre auch für jede andere Art von System, das WFMS-Funktionen nicht in einem separaten WFMS, sondern innerhalb eines anderen Systemtyps anbietet.

4.1 Einführung

In den nun folgenden Abschnitten wird ein kurzer Überblick über die grundlegenden Konzepte eines Workflow Management Systems auf der Basis des WFMS IBM FlowMark gegeben:
Aus der Sicht des Unternehmens gewinnt die Verwaltung von Geschäftsprozessen immer mehr an Bedeutung:
Geschäftsprozesse oder ein Prozeß für die kurzfristige Entscheidung darüber, welche Arbeit von wem ausgeführt werden soll und welche Ressourcen für diese Arbeit eingesetzt werden sollen. Ein Geschäftsprozeß beschreibt also, wie ein Unternehmen seine geschäftlichen Ziele erreichen kann. Ein WFMS kann sowohl die Modellierung von Geschäftsprozessen als auch ihre Ausführung unterstützen.

Die Modellierung eines Geschäftsprozesses als eine syntakti­ sche Einheit in einer von einem Softwaresystem direkt unter­ stützten Weise ist von hohem Interesse. Das Softwaresystem kann darüber hinaus als Interpretierer arbeiten, in den grundsätzlich als Eingang ein solches Modell eingegeben wird: das Modell, das als Prozeßmodell oder Workflow-Modell bezeichnet wird, kann dann in Instanzen zerlegt werden und der individuelle Ablauf der Arbeitsschritte kann, abhängig vom Kontext der Modellinstanzen, bestimmt werden. Ein solches Modell eines Geschäftsprozesses kann als Schablone für eine Klasse von ähnlichen Prozessen betrachtet werden, die in einem Unternehmen ablaufen; es ist ein Schema, in dem alle möglichen Ausführungsvarianten eines bestimmten Geschäftsvorgangs beschrieben werden. Eine Instanz eines solchen Modells und ihre Interpretation stellt einen einzelnen Prozeß dar, d. h., eine konkrete, kontextabhängige Ausführung einer von dem Modell vorgeschriebenen Variante. Ein WFMS vereinfacht die Verwaltung von Geschäftsprozessen. Es stellt ein Mittel dar für die Beschreibung von Geschäftsprozeßmodellen (Aufbauzeit) und es steuert Geschäftsprozesse anhand eines zugehörigen Modells (Laufzeit). Das Metamodell des WFMS FlowMark von IBM, also die syntaktischen Elemente zur Beschreibung von Ge­ schäftsprozeßmodellen, und die Bedeutung und Interpretation dieser syntaktischen Elemente werden im folgenden beschrie­ ben.

Ein Prozeßmodell ist eine komplette Darstellung eines Prozesses und umfaßt ein Prozeßdiagramm und die Einstellungen, welche die Logik der Diagrammkomponenten definieren. Mit Hilfe verschiedener, von FlowMark bereitgestellter Dienste werden dann diese Aufbau- Definitionen, die Prozeßmodelle, in Prozeßschablonen umgewandelt, die von FlowMark während der Laufzeit verwendet werden. Die folgenden Komponenten sind wichtige Komponenten eines FlowMark-Prozeßmodells:

• - Prozesse
• - Aktivitäten
• - Blöcke
• - Steuerungsflüsse
• - Konnektoren
• - Daten-Container
• - Datenstrukturen
• - Bedingungen
• - Programme
• - Personal

Einige dieser Elemente werden in den folgenden Abschnitten beschrieben.

Vor diesem Hintergrund ist ein von einem Prozeßmodell in FlowMark modellierter Prozeß eine Folge von Aktivitäten, die zur Erfüllung einer bestimmten Aufgabe ausgeführt werden müssen. Der Prozeß ist das Element auf der obersten Ebene eines FlowMark Workflow-Modells. In einem FlowMark-Prozeß kann folgendes definiert werden:

• - Wie der Arbeitsfortschritt von einer Aktivität bis zur nächsten aussehen soll
• - Welche Personen die Aktivitäten ausführen sollen und welche Programme sie hierfür verwenden sollen
• - Ob andere Prozesse, die als Teilprozesse bezeichnet werden, in dem Prozeß verschachtelt sind

Natürlich können mehrere Instanzen eines FlowMark-Prozesses parallel ablaufen.

Aktivitäten sind die grundlegenden Elemente des Metamodells. Eine Aktivität ist ein Geschäftsvorgang, der aus einer be­ stimmten Perspektive betrachtet eine eigene semantische Entität darstellt. Bezogen auf das Modell des Geschäftsprozesses kann er eine Feinstruktur aufweisen, die dann wiederum in einem Modell dargestellt wird, oder die Einzelheiten des Vorgangs sind in Bezug auf die Modellierung des Geschäftsprozesses nicht von Interesse. Die Verfeinerung von Aktivitäten über Prozeßmodelle erlaubt eine Modellierung der Geschäftsprozesse sowohl von unten nach oben als auch von oben nach unten. Die Aktivitäten, die innerhalb eines Prozesses eine Stufe darstellen, stellen eine Arbeit dar, die von der hierfür bestimmten Person durch Starten eines Programms oder eines anderen Prozesses ausgeführt werden kann. In einem Prozeßmodell sind jeder Aktivität die folgenden Informationen zugeordnet:

• - Welche Bedingungen erfüllt sein müssen, bevor eine Aktivität gestartet werden kann
• - Ob die Aktivität manuell von einem Benutzer gestartet werden muß oder automatisch starten kann
• - Durch welche Bedingung angezeigt wird, daß die Aktivität abgeschlossen ist
• - Ob die Steuerung automatisch von der Aktivität aus er­ folgen kann, oder ob die Aktivität zuerst von einem Be­ nutzer als abgeschlossen bestätigt werden muß
• - Wie viel Zeit für die Erledigung der Aktivität benötigt werden darf
• - Wer verantwortlich ist für die Erledigung der Aktivität
• - Welches Programm oder welcher Prozeß für die Erledigung der Aktivität eingesetzt wird
• - Welche Daten als Eingangsdaten für die Aktivität und welche als Ausgangsdaten von der Aktivität benötigt werden

Ein FlowMark-Prozeßmodell besteht aus den folgenden Aktivitäten:
Programmaktivität: Für ihre Ausführung wird ein Programm zu­ gewiesen. Das Programm wird aufgerufen, wenn die Aktivität gestartet wird. In einem vollautomatischen Arbeitsablauf führt das Programm die Aktivität ohne menschliches Eingreifen durch. In einem halbautomatischen Arbeitsablauf muß der Benutzer die Aktivität starten, indem er sie aus einer Laufzeit-Arbeitsliste auswählt. Die Programmausgangsdaten können in der Exit-Bedingung für die Programmaktivität und für die Übergangsbedingungen zu anderen Aktivitäten eingesetzt werden.

Prozeßaktivität: Für ihre Ausführung wird ein (Teil-)Prozeß zugewiesen. Der Prozeß wird aufgerufen, wenn die Aktivität gestartet wird. Eine Prozeßaktivität stellt eine Möglichkeit dar, eine Gruppe von Aktivitäten, die für verschiedene Pro­ zesse gemeinsam gelten, wiederzuverwenden. Die Prozeßaus­ gangsdaten können in der Exit-Bedingung für die Prozeßaktivität und für die Übergangsbedingungen zu anderen Aktivitäten eingesetzt werden.

Der Ablauf der Steuerungsvorgänge, der Steuerungsfluß durch einen laufenden Prozeß, bestimmt die Reihenfolge, in der die Aktivitäten ausgeführt werden. Der FlowMark Workflow Manager steuert einen Pfad durch den Prozeß, dessen Verlauf davon bestimmt wird, ob die Startbedingungen, die Exit-Bedingungen und die Übergangsbedingungen mit TRUE bewertet werden.

Die Ergebnisse, die im allgemeinen von der durch eine Aktivität repräsentierten Arbeit erzeugt werden, werden in einem Ausgangs-Container abgelegt, der jeder Aktivität zugewiesen wird. Da eine Aktivität im allgemeinen auf die Ausgangs-Container anderer Aktivitäten zugreifen muß, ist jeder Aktivität außerdem noch ein Eingangs-Container zugeordnet. Während der Laufzeit stellen die tatsächlichen Werte für die formalen Parameter, aus denen der Eingangs- Container einer Aktivität besteht, den tatsächlichen Kontext einer Instanz der Aktivität dar. Jeder Daten-Container ist durch eine Datenstruktur definiert. Eine Datenstruktur ist eine geordnete Liste von Variablen, Elemente genannt, die einen Namen und einen Datentyp besitzen. Datenkonnektoren stellen den Transfer der Daten von Ausgangs-Containern zu Eingangs-Containern dar. Wenn ein Datenkonnektor einen Ausgangs-Container mit einem Eingangs-Container verbindet und die Datenstrukturen der beiden Container genau übereinstimmen, bildet der FlowMark Workflow Manager die Daten automatisch ab.

In einem Prozeßmodell sind die Aktivitäten durch Konnektoren miteinander verknüpft. Mit Konnektoren wird die Ablauffolge der Aktivitäten und die Übertragung von Daten zwischen Aktivitäten festgelegt. Da die Aktivitäten nicht beliebig ausgeführt werden können, werden sie miteinander über Steue­ rungskonnektoren verbunden. Ein Steuerungskonnektor kann be­ trachtet werden als gerichtete Kante zwischen zwei Aktivitäten; die Aktivität am Endpunkt des Konnektors kann nicht gestartet werden, bevor die Aktivität am Startpunkt des Konnektors (erfolgreich) abgeschlossen ist.

Steuerungskonnektoren modellieren also den potentiellen Steuerungsfluß innerhalb eines Geschäftsprozeßmodells. Standardkonnektoren geben an, wie der Steuerungsfluß ablaufen soll, wenn die Übergangsbedingung keines anderen Steuerungskonnektors, der von einer Aktivität abgeht, mit TRUE bewertet wird. Durch Standardkonnektoren kann das Workflow-Modell mit außergewöhnlichen Ereignissen umgehen. Datenkonnektoren geben den Datenfluß in einem Workflow-Mo­ dell an. Ein Datenkonnektor entspringt aus einer Aktivität oder einem Block und hat eine Aktivität oder einen Block als Ziel. Man kann vorgeben, daß die Ausgangsdaten zu einem Ziel oder zu mehreren Zielen gehen sollen. In ein Ziel kann mehr als ein Datenkonnektor einmünden.

Mit Bedingungen kann der Steuerungsfluß in einem Prozeß vor­ gegeben werden. In FlowMark können die logischen Ausdrücke von Prozeßmodellen definiert werden, die dann von FlowMark während der Laufzeit ausgewertet werden, um festzustellen, wann eine Aktivität beginnen, enden und die Steuerung an die nächste Aktivität übergeben werden kann. Startbedingungen sind Bedingungen, die festlegen, wann eine Aktivität mit einmündenden Steuerungskonnektoren beginnen kann. Die Startbedingung kann vorschreiben, daß alle einmündenden Steuerungskonnektoren mit TRUE bewertet werden müssen, oder sie kann vorgeben, daß mindestens einer von ihnen mit TRUE bewertet werden muß. Ganz gleich, wie die Startbedingung lautet, alle ankommenden Konnektoren müssen ausgewertet werden, bevor die Aktivität beginnen kann. Wenn eine Aktivität keine ankommenden Steuerungskonnektoren hat, wird sie fertig, wenn der Prozeß oder der Block, der die Aktivität enthält, gestartet wird. Zusätzlich ist jeder Steuerungskonnektor ein boolescher Ausdruck, Übergangsbedingung genannt, zugeordnet. Parameter von Ausgangs-Containern von Aktivitäten, die ihre Ergebnisse be­ reits vorliegen haben, werden als Parameter verfolgt, die in Übergangsbedingungen referenziert werden. Wenn während der Laufzeit eine Aktivität erfolgreich beendet wird, werden alle von dieser Aktivität abgehenden Steuerungskonnektoren bestimmt und der Wahrheitswert der zugehörigen Übergangsbedingungen wird auf der Grundlage der tatsächlichen Werte ihrer Parameter berechnet. Nur die Endpunkte der Steuerungskonnektoren, deren Übergangsbedingungen mit TRUE bewertet wurden, gelten als Aktivitäten, die auf der Basis des eigentlichen Kontexts des Geschäftsprozesses ausgeführt werden können.

Übergangsbedingungen modellieren also den kontextabhängigen tatsächlichen Steuerungsfluß innerhalb eines Geschäftsprozesses (also die Instanz eines Modells).

Geschäftsprozesse beinhalten im allgemeinen Aktivitäten mit langer Laufzeit; bei einer solchen Aktivität muß eine Unterbrechung möglich sein. Die Beendigung einer Aktivität zeigt nicht notwendigerweise an, daß die zugehörige Aufgabe erfolgreich abgeschlossen wurde. Um eine Bemessung des Erfolgs einer von einer Aktivität durchgeführten Arbeit zu ermöglichen, ist jeder Aktivität ein boolescher Ausdruck, Exit-Bedingung genannt, zugeordnet. Genau diejenigen Aktivitäten, deren Exit-Bedingung im tatsächlichen Kontext mit TRUE bewertet wurde, werden als erfolgreich abgeschlossen bewertet. Zur Festlegung des tatsächlichen Steuerungsflusses werden dann genau diese erfolgreich abgeschlossenen Aktivitäten berücksichtigt. Der logische Ausdruck einer Exit-Bedingung muß also, wenn vorgegeben, mit TRUE bewertet werden, damit die Steuerung von einer Aktivität oder einem Block weitergegeben werden kann.

Neben der Beschreibung des potentiellen Steuerungs- und Da­ tenflusses zwischen den einzelnen Aktivitäten schließt ein Geschäftsprozeßmodell auch die Beschreibung des Aktivitäts­ flusses selbst zwischen "Ressourcen" ein, die die von jeder Aktivität dargestellten Arbeitselemente tatsächlich ausfüh­ ren. Eine Ressource kann ein bestimmtes Programm, eine Per­ son, eine Funktion oder eine Organisationseinheit sein. Wäh­ rend der Laufzeit werden Aufgaben zu Aufforderungen an be­ stimmte Personen aufgelöst, bestimmte Aktivitäten auszufüh­ ren, die dann zu Arbeitseinheiten für diese Personen werden. Über Personalzuteilungen werden die Aktivitäten in der durch den Steuerungsflußaspekt eines Geschäftsprozeßmodells vorge­ schriebenen Reihenfolge auf die richtigen Leute verteilt. Jede Aktivität in einem Prozeß wird einem oder mehreren Mit­ arbeitern zugeteilt, die in der FlowMark-Datenbank festgelegt sind. Unabhängig davon, ob eine Aktivität manuell von einem Benutzer oder automatisch vom Workflow Manager in FlowMark gestartet wird, ob zu ihrer Ausführung ein Eingreifen des Benutzers notwendig ist oder ob sie automatisch abläuft, muß ihr ein Mitarbeiter zugewiesen werden. Die Personalzuteilung in FlowMark ist aber mehr als nur eine Eingabe von Mitarbeitern des Unternehmens in die FlowMark-Datenbank. Für jeden eingegebenen Mitarbeiter können eine bestimmte Ebene, eine Organisation und mehrere Funktionen angegeben werden. Diese Attribute können bei Laufzeit eingesetzt werden, um dynamisch Aktivitäten denjenigen Leuten zuzuweisen, die die geeigneten Attribute besitzen.

Die Prozeßdefinition beinhaltet die Modellierung von Aktivitäten, von Steuerungskonnektoren zwischen den Aktivitäten, von Eingangs-/Ausgangs-Containern und von Datenkonnektoren. Ein Prozeß wird dargestellt als ein gerichteter azyklischer Graph mit den Aktivitäten als Knoten und den Steuerungs-/Datenkonnektoren als Kanten des Graphs. Der Graph wird über einen eingebauten, ereignisgesteuerten, CUA-konformen Graphikeditor beeinflußt. Die Daten-Container sind als mit Namen versehene Datenstrukturen spezifiziert. Diese Datenstrukturen selbst werden über die Datenstruktur- Definitionsfunktion spezifiziert. FlowMark unterscheidet drei Hauptarten von Aktivitäten: Programmaktivitäten, Prozeßaktivitäten und Blöcke. Programmaktivitäten werden durch Programme implementiert. Die Programme werden über die Programmdefinitionsfunktion registriert. Blöcke enthalten dieselben Konstrukte wie Prozesse, zum Beispiel Aktivitäten, Steuerungskonnektoren etc. Sie besitzen jedoch keinen Namen und haben ihre eigene Exit-Bedingung. Wenn die Exit- Bedingung nicht erfüllt wird, wird der Block erneut gestartet. Der Block implementiert also ein DO UNTIL- Konstrukt. Prozeßaktivitäten werden als Prozesse implementiert. Diese Teilprozesse werden separat als normale benannte Prozesse mit allen üblichen Eigenschaften definiert. Prozeßaktivitäten bieten eine große Flexibilität hinsichtlich der Prozeßdefinition. Es ist nicht nur möglich, einen Prozeß durch ständige Verfeinerung der Aktivitäten in Programm- und Prozeßaktivitäten (von oben nach unten) aufzugliedern, sondern ein Prozeß kann auch aus einer Gruppe von vorhandenen Prozessen (von unten nach oben) aufgebaut werden. Insbesondere helfen die Prozeßaktivitäten bei der Organisation der Modellierungsarbeit, wenn mehrere Pro­ zeßgestalter zusammenarbeiten. Die Team-Mitglieder haben so die Möglichkeit, voneinander unabhängig an verschiedenen Aktivitäten zu arbeiten. Programm- und Prozeßaktivitäten können mit einem zeitlichen Limit einander zugeordnet werden. Anhand des zeitlichen Limits wird angegeben, wieviel Zeit die Aktivität in Anspruch nehmen darf. Wenn die Zeit überschritten wird, wird eine bestimmte Person benachrichtigt. Wenn diese Person nicht innerhalb eines weiteren zeitlichen Limits reagiert, wird der Prozeßadministrator benachrichtigt. Hiermit können nicht nur kritische Situationen erkannt sondern auch Prozeßmängel festgestellt werden, da alle Benachrichtigungen in einem Buchungsprotokoll aufgezeichnet werden.

Alle Datenstrukturen, die als Schablonen für die Container der Aktivitäten und Prozesse verwendet werden, werden über die Datenstruktur-Definitionsfunktion definiert. Datenstruk­ turen sind Namen und werden als elementare Datentypen, bei­ spielsweise als Gleitpunkt, Ganzzahl oder Kette, und als Querverweise auf vorhandene Datenstrukturen definiert. Das Verwalten von Datenstrukturen in Form von getrennten Entitä­ ten hat den Vorteil, daß alle Schnittstellen von Aktivitäten und ihre Implementierungen konsistent an einer Stelle verwaltet werden (ähnlich den Header-Dateien in Programmiersprachen).

Alle Programme, die Programmaktivitäten implementieren, wer­ den über die Programmregistrierungsfunktion definiert. Für jedes Programm ist der Programmname, der Ort, an dem sich das Programm befindet und die Aufrufkette registriert. Die Aufrufkette besteht aus dem Programmnamen und der an das Programm übergebenen Befehlskette.

Bevor Prozeßinstanzen erzeugt werden können, muß das Prozeß­ modell übersetzt werden, um die Richtigkeit und Vollständig­ keit des Prozeßmodells zu gewährleisten. Die übersetzte Ver­ sion des Modells dient als Schablone bei der Erstellung einer Prozeßinstanz. Hierdurch können Änderungen an dem Prozeßmodell durchgeführt werden, ohne daß davon gerade ausgeführte Prozeßinstanzen betroffen sind. Eine Prozeßinstanz wird entweder über die graphische Schnittstelle oder über die aufrufbare Prozeß- Programmierschnittstelle gestartet. Wenn ein Prozeß gestartet wird, werden die Startaktivitäten lokalisiert, die richtigen Leute werden bestimmt und die Aktivitäten werden in die Aufgabenliste der ausgewählten Personen als Ar­ beitseinheiten eingetragen. Wenn ein Benutzer die Arbeitseinheit auswählt, d. h. die Aktivität, wird die Aktivität ausgewählt und aus der Aufgabenliste eines jeden anderen Benutzers, für den die Aktivität eingetragen worden war, entfernt. Nachdem eine Aktivität ausgeführt wurde, wird ihre Exit-Bedingung ausgewertet. Wenn diese Bedingung nicht erfüllt ist, wird die Aktivität erneut zur Ausführung eingeplant, andernfalls werden alle abgehenden Steuerungskonnektoren und die damit verbundenen Übergangsbedingungen ausgewertet. Ein Steuerungskonnektor wird ausgewählt, wenn die Bedingung mit TRUE bewertet wird. Dann werden die Zielaktivitäten der ausgewählten Steuerungskonnektoren ausgewertet. Wenn ihre Start­ bedingungen TRUE sind, werden sie in die Aufgabenliste der ausgewählten Personen eingetragen. Ein Prozeß gilt als been­ det, wenn alle Endaktivitäten ausgeführt sind. Um sicherzu­ stellen, daß alle Endaktivitäten abgeschlossen werden, wird eine sogenannte "Sackgasseneliminierung" (dead path elimina­ tion) durchgeführt. Hierbei werden alle Kanten des Prozeßgraphen, die aufgrund fehlender Übergangsbedingungen nicht erreicht werden können, entfernt. Sämtliche Informationen über den aktuellen Zustand eines Prozesses werden in der vom Server gepflegten Datenbank gespeichert. Hierdurch ist eine vorwärtsgerichtete Fehlersuche bei einem Crash gewährleistet.

4.2 Die Struktur der Verbindungsaktivität

Die Verarbeitung in Zusammenhang mit einer Verbindungsaktivität hat die in Fig. 1 gezeigte globale Struktur.

Generell sind nicht alle Eigenschaften Teil der Metamodelle, die von den verschiedenen Workflow Management Systemen implementiert werden. Offensichtlich gibt es kein bestimmtes Workflow Management System, das alle Eigenschaften unter­ stützt. Die Spezifikation einer bestimmten Eigenschaft ist im allgemeinen nicht obligatorisch; wenn keine bestimmten Vorgaben gemacht wurden, werden typischerweise Standardwerte eingesetzt.

Fig. 1 zeigt N Steuerungskonnektoren p1 (101) bis pn (102), die in eine Verbindungsaktivität einmünden. Die Startbedin­ gung (103) gibt an, welche Steuerungskonnektoren in die Aktivität eingeflossen sein müssen und wie ihr geeigneter Wahrheitswert aussehen muß. Weitere Einzelheiten finden sich im nächsten Abschnitt.

Die Aktivierungsbedingung (104) spezifiziert die Kriterien, die erfüllt werden müssen, bevor die Aktivität ausgeführt werden kann. Die Aktivierungsbedingung wird erst dann ausge­ wertet, wenn die Startbedingung mit TRUE ausgewertet wurde. Die Abfrage für die Organisation DB (Personalzuteilung) (105) legt fest, wer für die Ausführung der Aktivität eingeteilt werden soll. Die eigentliche Implementierung (106) ist das Programm oder der Prozeß, der bei der Ausführung der Aktivität eingesetzt wird. Die Exit-Bedingung (107) nennt die Kriterien, die zu erfüllen sind, bevor die Aktivität beendet werden kann. Die verschiedenen Eigenschaften werden in der gezeigten Reihenfolge ausgeführt, also von oben nach unten.

Wie bereits erwähnt sind die Startbedingungen in den bisher bekannten WFMS entweder nicht bekannt, oder die verfügbare Technologie ist nur unzureichend.

Im ersten Fall wird die Aktivierungsbedingung unmittelbar nachdem ein Steuerungskonnektor in den Verbindungsknoten eingetreten ist geprüft. Der Arbeitsfluß wartet nicht, bis die anderen Steuerungskonnektoren in die Aktivität eingetre­ ten sind. Wenn ein zweiter Steuerungskonnektor in die Aktivität einmündet, wird diese ein zweites Mal ausgeführt. Der Prozeßentwerfer muß sicherstellen, daß dies entweder nicht vorkommt, oder daß die zweite Verarbeitung der Aktivität keine negativen Auswirkungen hat.

Im zweiten Fall sind die beiden einzigen Einstellungen, die die Startbedingung unterstützt, "ALL" oder "AT LEAST ONE". Wenn "ALL" angegeben wurde, müssen alle ankommenden Steue­ rungskonnektoren mit TRUE bewertet worden sein; wenn "AT LEAST ONE" angegeben wurde, muß mindestens einer der ankom­ menden Steuerungskonnektoren mit TRUE bewertet werden.

4.3 Die Lösung

Die gewünschte Flexibilität erreicht man, indem man dem Pro­ zeßgestalter erlaubt, individuell eine Reihe von verschiede­ nen Eigenschaften für die Startbedingungen anzugeben.

Die möglichen Eigenschaften, die von einem Prozeßmodellierer definiert und von dem WFMS während der Abarbeitung des Pro­ zeßmodells ausgewertet werden können und von der vorliegenden Erfindung vorgeschlagen werden, sind folgende:
der eigentliche Ausdruck, der ausgewertet wird,
der Zeitpunkt, an dem der Ausdruck ausgewertet wird, und
alle zusätzlichen Vorgänge, die stattfinden sollen, wenn das Ergebnis der Auswertung des Startbedin­ gungsausdrucks positiv ist.

Wenn der Startbedingungsausdruck mit TRUE bewertet wird, wird die Verarbeitung der Aktivität mit der Auswertung der Aktivierungsbedingung fortgesetzt. Wenn die Startbedingung mit FALSE bewertet wird, wird die Aktivität nicht ausgeführt, die abgehenden Steuerungskonnektoren werden als FALSE gekennzeichnet (Sackgassenbeseitigung) und die Navigation wird dementsprechend fortgesetzt.

Um die verschiedenen Eigenschaften im einzelnen zu erörtern, soll das folgende Beispiel dienen, das in Fig. 2 dargestellt ist. Das Beispiel dient zur Erläuterung der Fähigkeiten der erweiterten Startbedingungen. Fig. 2 zeigt eine Verbindungs- Aktivität (201), die das Ziel dreier Steuerungskonnektoren (202, 203, 204) ist.

Bei den meisten Workflow Management Systemen wird eine anwendereigene Sprache zur Beschreibung der Prozeßmodelle in Textform verwendet. Das obige Beispiel wird im folgenden au­ ßerdem in der Workflow-Definitionssprache der MQ-Serie ausgedrückt. Natürlich sind nach dem Stand der Technik eine Vielzahl von äquivalenten Methoden bekannt. Die Verwendung der Workflow-Definitionssprache der MQ-Serie ist daher nur als Beispiel zu verstehen.

Unter Anwendung der Workflow-Definitionssprache der MQ-Serie könnte das Beispiel der Fig. 2 wie folgt ausgedrückt werden:

4.3.1 Ausdruck

Als Herz der Startbedingung wird die Einführung boolescher Ausdrücke vorgeschlagen, die aus einer Reihe von booleschen Variablen und booleschen Operatoren aufgebaut sind. Die boo­ leschen Variablen beziehen sich auf die verschiedenen Steue­ rungskonnektoren, die durch Positionierung ihrer Wahrheits­ werte in die Aktivität einmünden. Wenn ein Steuerungskonnek­ tor in eine Aktivität einmündet, wird ihm ein Wahrheitswert, TRUE oder FALSE, zugewiesen. Die Wahrheitswerte der Steue­ rungskonnektoren werden dann in den Startbedingungsausdruck eingesetzt, um den Wahrheitswert der Startbedingung zu be­ stimmen. Die booleschen Operatoren sind die typischen Opera­ toren, beispielsweise AND, OR, XOR oder NOT.

Der folgende Ausdruck ist ein typischer (einfacher) Startbe­ dingungsausdruck für das gegebene Beispiel:

Er gibt an, daß die Startbedingung mit TRUE bewertet wird, wenn (a) der Steuerungskonnektor AD mit TRUE bewertet wird, oder (b) beide Steuerungskonnektoren BD und CD mit TRUE be­ wertet werden, oder (c) alle drei Steuerungskonnektoren AD, BD und CD mit TRUE bewertet werden.

Wenn man sicherstellen will, daß entweder der Steuerungskon­ nektor AD oder der Steuerungskonnektor BD und CD TRUE sind, muß der boolesche Operator XOR verwendet werden, wie es in dem folgenden booleschen Ausdruck dargestellt ist:

Nachdem die Fähigkeit, boolesche Ausdrücke zu spezifizieren, eingegeben wurde, können mit dem verfügbaren Satz an boole­ schen Operatoren fast alle vorkommenden Situationen spezifi­ ziert werden. Die Spezifikation kann jedoch äußerst mühsam werden, insbesondere dann, wenn eine größere Anzahl von Steuerungskonnektoren in die Aktivität einmündet. Somit wird eine Gruppe spezieller Funktionen unterstützt, um eine einfache Beschreibung typischer Situationen zu ermöglichen.

Ein sehr komfortables Konstrukt eines logischen Ausdrucks ist das nächste Beispiel, welches das Konstrukt M_OUT_OF einführt:

Diese Spezifikation gibt an, daß mindestens zwei der ankom­ menden Steuerungskonnektoren mit TRUE bewertet werden müs­ sen. Sie könnte beispielsweise zur Implementierung einer Ab­ stimmung eingesetzt werden. Hierbei ist zu beachten, daß diese Funktion nur eine Kurzschriftnotation ist; hiermit wird eine Spezifizierung aller möglichen Kombinationen vermieden. Der Ausdruck (AD AND BD) OR (AD AND CD) OR (BD AND CD) erbringt dasselbe Ergebnis.

4.4 Bewertungszeit

Die vorliegende Erfindung schlägt zwei konzeptuale Zeitpunkte vor, an denen der Startbedingungsausdruck ausgewertet werden kann:
wenn alle Steuerungskonnektoren in die Aktivität eingetreten sind und dort logische Werte abgelegt haben, oder
wenn ein neuer Steuerungskonnektor in die Aktivität eintritt und dort seinen logischen Wert ablegt.

Wenn alle Steuerungskonnektoren in die Aktivität eingetreten sein müssen, ist die Verbindungsaktivität ein Synchronisati­ onspunkt. Er verlangt, daß alle Aktivitäten in den davorlie­ genden parallelen Pfaden abgeschlossen sein müssen.

Typisch wäre hierfür die Reservierung einer Reise, bei der die Reservierung des Autos und die Reservierung des Fluges parallel abgewickelt werden. Nur wenn beide erfolgreich abgeschlossen wurden, kann die Aktivität, welche den Reiseplan ausdruckt, ausgeführt werden.

Wenn der Startbedingungsausdruck ausgewertet wird, sobald ein neuer Steuerungskonnektor in die Aktivität eintritt, ist die Verbindungsaktivität kein Synchronisationspunkt. Wenn der Startbedingungsausdruck mit TRUE bewertet wird, wird die Verarbeitung der Aktivität mit der Auswertung der Aktivierungsbedingung fortgesetzt. Die Verarbeitung der übrigen Steuerungskonnektoren muß getrennt definiert werden; wir werden diesen Punkt im folgenden Abschnitt noch ausführlich erörtern.

Typisch für eine Aktivität, für die diese Art von Verarbei­ tung gilt, ist eine Aktivität, die den Eingang einer Kunden­ antwort verarbeitet. Diese Kundenantwort könnte als e-mail oder Fax eintreffen, die beide gegenüber der Kundenantwort- Verarbeitungsaktivität als Ereignis mit Steuerungskonnektoren dargestellt werden. In diesem Fall kann die Verarbeitung fortgesetzt werden, sobald eines der Ereignisse stattgefunden hat und der betreffende Steuerungskonnektor in die Kundenantwort- Verarbeitungsaktivität eingetreten ist.

Um beide Situationen und Kombinationen dieser Situationen bearbeiten zu können, wird der Startbedingungsausdruck aufgeteilt in einen ersten Teil, der ausgewertet wird, sobald ein neuer Steuerungskonnektor, die in diesem ersten logischen Ausdruck spezifiziert wird, in die Aktivität eintritt, und einen zweiten Teil, der ausgewertet wird, wenn alle Steuerungskonnektoren, die in diesem zweiten logischen Ausdruck spezifiziert werden, in die Aktivität eingetreten sind, so daß die verzögerte Auswertungszeit des zweiten logischen Ausdrucks nur von den Steuerungskonnektoren abhängt, die an dem zweiten logischen Ausdruck beteiligt sind.

Für die Definition dieser logischen Ausdrücke müssen in das WFMS neue Definitionsmittel eingeführt werden. Die vorlie­ gende Erfindung schlägt vor, ein neues Konstrukt für die De­ finitionssprache des Arbeitsflusses zu verwenden, um eine Spezifikation eines jeden Teils des logischen Ausdrucks zu ermöglichen. Das Schlüsselwort IMMEDIATE weist darauf hin, daß der zugehörige erste Ausdruck sofort ausgewertet werden soll, d. h., sobald ein neuer Steuerungskonnektor, der in diesem ersten Ausdruck spezifiziert wurde, durch Ablegen seines logischen Werts in die Zielaktivität eingetreten ist; das Schlüsselwort DEFERRED weist darauf hin, daß der zugehörige zweite Ausdruck ausgewertet werden soll, nachdem alle Steuerungskonnektoren, die in diesem zweiten Ausdruck spezifiziert wurden, in die Aktivität eingetreten sind, d. h., nicht bevor alle Steuerungskonnektoren ihre logischen Werte abgelegt haben. In einer zusätzlichen Erweiterung der vorliegenden Erfindung kann das Bewertungsergebnis des ersten logischen Ausdrucks, das zu dem Schlüsselwort IMMEDIATE gehört, und das Bewertungsergebnis des zweiten logischen Ausdrucks, das zu dem Schlüsselwort DEFERRED gehört, durch zusätzliche logische Operatoren (wie beispielsweise die Operatoren AND und OR) zu einem logischen Gesamtausdruck zusammengeführt werden.

Das folgende Beispiel verdeutlicht die Definition der Ausführungszeit-Spezifikation:

IMMEDIATE (AD OR BD) OR DEFERRED (CD)

Das obige Spezifikationsbeispiel zeigt mehrere Aspekte der Erfindung. Zunächst einmal zeigt es die Formulierung eines ersten logischen Ausdrucks, der sofort ausgewertet wird, und eines zweiten logischen Ausdrucks, der später ausgewertet wird. Zweitens zeigt das Beispiel die logische Kombination beider logischer Ausdrücke. Drittens zeigt das Beispiel die Zusammenführung des ersten und des zweiten logischen Aus­ drucks zu einem dritten logischen Ausdruck.

Das Spezifikationsbeispiel zeigt einen logischen Ausdruck (AD ODER BD), der zu dem Schlüsselwort IMMEDIATE gehört. In diesem Fall wird der Ausdruck ausgewertet, sobald mindestens eine der spezifizierten Steuerungskonnektoren, AB, BD, in die Aktivität eingetreten ist. Der IMMEDIATE-Teil des Start­ bedingungsausdrucks wird mit TRUE bewertet, wenn entweder AD oder BD mit TRUE bewertet werden.

Das Spezifikationsbeispiel zeigt außerdem einen logischen Ausdruck (CD), der zu dem Schlüsselwort DEFERRED gehört. Dieser zweite logische Ausdruck wird ausgewertet, nachdem alle Steuerungskonnektoren, die in diesem zweiten logischen Ausdruck spezifiziert wurden, in die Aktivität eingetreten sind. Da in diesem Ausdruck nur ein Steuerungskonnektor spezifiziert wurde, nämlich CD, wird der zweite logische Ausdruck ausgewertet, nachdem der Wahrheitswert von CD abgelegt wurde. Dieser Teil des Startbedingungsausdrucks wird mit TRUE bewertet, wenn CD, unabhängig vom Wahrheitswert von entweder AD oder BD, mit TRUE bewertet wird.

Schließlich zeigt das obige Beispiel eine logische OR-Ver­ knüpfung zwischen dem logischen Wert des ersten Ausdrucks, der sofort ausgewertet wird, und dem logischen Wert des zweiten Ausdrucks, der später ausgewertet wird.

4.4.1 Aktionen

Wenn der Startbedingungsausdruck mit TRUE bewertet wurde, wird die Verarbeitung der Zielaktivität mit der Auswertung der Aktivierungsbedingung fortgesetzt.

Wenn der Startbedingungsausdruck nur eine DEFERRED- Spezifikation enthält, müssen keine weiteren Aktionen definiert werden, da keine weitere "spät kommende" Steuerungsbedingung zu erwarten ist. Wenn sie jedoch eine IMMEDIATE-Spezifikation enthält, müssen die durchzuführenden Aktionen definiert werden, wenn eine der Steuerungsbedingungen, die nicht ausgewertet worden war, in die Aktivität eintritt. Mit einer Nachbearbeitungsfunktion können solche Fälle abgewickelt werden.

Die folgenden Aktivitätsdefinitionsoptionen, die von der vorliegenden Erfindung vorgeschlagen werden, sind typische Beispiele dafür, welche Aktion spezifiziert werden könnte; es können jedoch auch andere Optionen in Betracht gezogen werden.

• - IGNORE gibt an, daß bei Eintritt einer der übrigen Steuerungsbedingungen in die Aktivität diese einfach ignoriert werden soll.
• - TERMINATE gibt an, daß alle Aktivitäten, die sich auf den davorliegenden Pfaden des Prozeßmodells befinden, beendet werden sollen.

Die folgenden Beispiele sollen den Zweck einer jeden der verschiedenen Aktionen verdeutlichen.

4.4.1.1 Die Aktion IGNORE

Fig. 3 zeigt einen Teil eines Prozesses, der die Verarbeitung von Konferenzunterlagen abwickelt. Das in Fig. 3 dargestellte Beispiel bezieht sich tatsächlich auf ein Abstimmsystem.

Nachdem die Unterlage von einer Prüferin geprüft wurde, gibt diese an, ob die Unterlage akzeptiert werden soll, oder nicht. Bei Ja (J) wird der Steuerungskonnektor mit der Über­ gangsbedingung J mit TRUE bewertet und der Steuerungskonnek­ tor mit der Übergangsbedingung N wird mit FALSE bewertet; bei Nein (N) wird die Steuerungsbedingung mit der Übergangs­ bedingung N mit TRUE bewertet und die Steuerungsbedingung mit der Übergangsbedingung J wird mit FALSE bewertet. Eine Unterlage ist akzeptiert, wenn zwei der drei Prüfer mit Ja gestimmt haben; sie wird abgelehnt, wenn zwei der drei Prüfer mit Nein gestimmt haben. Fig. 3 veranschaulicht einen solchen Prüfungsprozeß. In Fig. 3 stellen (301, 302, 303) die Aktivität von 3 Prüfern dar und (304, 305) stellen die Aktivitäten dar, die diese Entscheidungen abwickeln.

In diesem Fall wird die Startbedingung mit IMMEDIATE (2 OUT_OF 3) IGNORE) definiert. Immer dann, wenn ein Prüfer die Prüfung abgeschlossen hat, werden die betreffenden Steue­ rungsbedingungen ausgewertet. Sobald zwei Steuerungsbedingungen, die in die Aktivität "Unterlage akzeptieren" (304) oder "Unterlage ablehnen" (305) eintreten, mit TRUE bewertet werden, wird die Verarbeitung der betreffenden Aktivität ausgeführt. Wenn die dritte Prüfung abgeschlossen ist, werden auch die betreffenden Steuerungsbedingungen ausgewertet. Die Aktion "Ignorieren" definiert dann, was passieren soll, wenn die Steuerungsbedingung für eine bereits gestartete Aktivität mit TRUE bewertet wird. Wenn beispielsweise die beiden ersten Prüfer mit J für die Annahme der Unterlage gestimmt haben, wurde hierdurch die Aktivität "Unterlage akzeptieren" (304) gestartet; die Aktivität "Unterlage ablehnen" (305) wartet noch, da keine eintreffende Steuerungsbedingung mit TRUE bewertet wurde. Unabhängig davon, wie der dritte Prüfer abstimmt, wird die Aktivität "Unterlage akzeptieren" (304) das Ergebnis ignorieren. Wenn beispielsweise der dritte Prüfer mit Ja abstimmt, wird die Steuerungsbedingung, die in die Aktivität "Unterlage akzeptieren" (304) eintritt, mit TRUE bewertet und die Steuerungsbedingung, die in die Aktivität "Unterlage ablehnen" (305) eintritt, wird mit FALSE bewertet. Die Aktivität "Unterlage akzeptieren" (304) ignoriert die Steuerungsbedingung, das heißt, sie ist ein Leerbefehl (do nothing). Für die Aktivität "Unterlage ablehnen" (305) sind jetzt alle Steuerungsbedingungen ausgewertet. Da keine Steuerungsbedingung mit TRUE bewertet wurde, wurde die Startbedingung nicht erfüllt und die Aktivität wird übersprungen.

4.4.1.2 Die Aktion TERMINATE

Fig. 4 zeigt einen Teil eines Modells zur Bearbeitung von Ansprüchen, das die Verarbeitung der Kommunikation mit einem Kunden zeigt. Das Beispiel dient zur Erläuterung der Nachbe­ arbeitungsaktion TERMINATE.

Zur Bearbeitung des Anspruchs werden weitere Informationen vom Kunden benötigt; es wird ein Brief an den Kunden ge­ schickt, in dem er um die Angabe weiterer Informationen gebeten wird (401). Der Kunde könnte auf die Anfrage entweder durch das Senden eines Briefes (402), einer e-mail (404) oder eines Faxes (403) antworten. Es werden also drei Ereignisse definiert, um die einzelnen Methoden, auf die Anfrage zu antworten, zu behandeln. Es reicht aus, wenn der Kunde unter Anwendung einer Methode antwortet. Unter Bezugnahme auf Fig. 4; die Startbedingung wird also definiert mit IMMEDIATE (FG OR FH OR FI) TERMINATE). Diese Startbedingung wird mit TRUE bewertet, sobald eine Antwort eingegangen ist. Da es nicht länger notwendig ist, die anderen Ereignisse abzuwarten, bewirkt die Aktion TERMINATE, daß diese anderen Ereignisse beendet werden; das bedeutet, daß der Prozeß nicht länger auf diese Ereignisse wartet.

Claims (11)

1. Mittel zur Berechnung einer Startbedingung in einem Computersystem, das als Workflow-Management-System (WFMS) arbeitet, oder einem Computersystem mit vergleichbaren Funktionen,
wobei das genannte WFMS mindestens ein Prozeßmodell um­ faßt, das genannte Prozeßmodell eine oder mehrere Pro­ zeßaktivitäten umfaßt, die Knoten eines beliebigen Gra­ phen sind, und gerichtete Steuerungskonnektoren des ge­ nannten Graphen, die einen potentiellen Steuerungsfluß innerhalb des genannten Prozeßmodells definieren; und
wobei das genannte Mittel zur Berechnung einer Startbe­ dingung auswertet, ob eine Zielaktivität gestartet wer­ den kann, abhängig vom Wahrheitswert ankommender Steue­ rungskonnektoren der genannten Zielaktivität;
und weiter gekennzeichnet dadurch, daß
das genannte Mittel zur Berechnung einer Startbedingung Sofort-Berechnungsmittel umfaßt für die Auswertung des Wahrheitswerts eines ersten logischen Ausdrucks, unmit­ telbar in Antwort auf einen abgelegten Wahrheitswert eines ankommenden Steuerungskonnektors, der Teil des genannten ersten logischen Ausdrucks ist, und
die Fortsetzung der Verarbeitung zum Starten der genannten Zielaktivität nur dann, wenn der genannte erste logische Ausdruck mit TRUE bewertet wird; und/oder
das genannte Mittel zur Berechnung einer Startbedingung ein Mittel für die verzögerte Berechnung umfaßt, um den Wahrheitswert des zweiten logischen Ausdrucks erst aus­ zuwerten, nachdem der Wahrheitswert aller ankommenden Steuerungskonnektoren, der Teil des genannten zweiten logischen Ausdrucks ist, abgelegt ist, und
die Fortsetzung der Verarbeitung zum Starten der genannten Zielaktivität nur dann, wenn der genannte zweite logische Ausdruck mit TRUE bewertet wird.

2. Mittel zur Berechnung einer Startbedingung nach Anspruch 1, wobei das Mittel zur Berechnung der Startbedingung wei­ ter Mittel umfaßt zur Auswertung eines dritten logischen Ausdrucks, der den genannten ersten und den genannten zweiten logischen Ausdruck umfaßt.

3. Mittel zur Berechnung der Startbedingung nach Anspruch 1 oder 2, weiter umfassend Nachbearbeitungsmittel, die ausgeführt werden können, nachdem der genannte erste oder der ge­ nannte zweite logische Ausdruck mit TRUE bewertet wurde, und die ausgeführt werden können, bevor die eigentliche Verarbeitung der genannten Zielaktivität gestartet wird.

4. Mittel zur Berechnung einer Startbedingung nach Anspruch 3,
bei dem das genannte Nachverarbeitungsmittel kontrol­ liert, nachdem der genannte erste oder der genannte zweite logische Ausdruck mit TRUE ausgewertet wurde,
ob ein weiterer abgelegter Wahrheitswert eines an­ kommenden Steuerungskonnektors der genannten Zielaktivität ignoriert werden soll oder nicht; und/oder
ob Aktivitäten, die in dem genannten Prozeßmodell vor der genannten Zielaktivität liegen, beendet werden sollen.

5. Mittel zur Berechnung von Startbedingungen nach Anspruch 1, 3 oder 4, bei dem der genannte erste und/oder der genannte zweite logische Ausdruck ein beliebiger boolescher Ausdruck ist, der abgelegte Wahrheitswerte von jeder der genann­ ten ankommenden Steuerungskonnektoren der genannten Zielaktivität umfaßt.

6. Mittel zur Definition einer Startbedingung für ein Pro­ zeßmodell eines Workflow-Management-Systems (WFMS) oder eines Computersystems mit vergleichbaren Funktionen, wobei das genannte Prozeßmodell eine oder mehrere Prozeß-Aktivitäten umfaßt, die Knoten eines beliebigen Graphen und gerichtete Steuerungskonnektoren des genannten Graphen sind, die einen potentiellen Steuerungsfluß innerhalb des genannten Prozeßmodells definieren; und
das genannte Prozeßmodell das genannte Mittel zur Defi­ nition von Startbedingungen umfaßt, um zu definieren, wann eine Zielaktivität gestartet werden kann, abhängig von dem Wahrheitswert der ankommenden Steuerungskonnek­ toren der genannten Zielaktivität;
und weiter gekennzeichnet dadurch, daß das genannte Mittel zur Definition der Startbedingung einen ersten logischen Ausdruck umfaßt, der von dem ge­ nannten WFMS während der genannten Ausführung des ge­ nannten Prozeßmodells unmittelbar in Antwort auf einen abgelegten Wahrheitswert eines ankommenden Steuerungs­ konnektors, der Teil des genannten ersten logischen Ausdrucks ist, ausgewertet wird; und
das genannte WFMS die Verarbeitung fortsetzt, um die genannte Zielaktivität nur dann zu starten, wenn der genannte erste logische Ausdruck mit TRUE bewertet wird; und/oder
das genannte Mittel zur Definition der Startbedingung einen zweiten logischen Ausdruck umfaßt, der von dem genannten WFMS während der genannten Ausführung des ge­ nannten Prozeßmodells erst dann ausgewertet wird, wenn der Wahrheitswert aller ankommenden Steuerungskonnekto­ ren, der Teil des genannten zweiten logischen Ausdrucks ist, abgelegt wurde; und
das genannte WFMS die Verarbeitung fortsetzt, um die genannte Zielaktivität nur dann zu starten, wenn der genannte zweite logische Ausdruck mit TRUE bewertet wird.

7. Mittel zur Definition einer Startbedingung nach Anspruch 6, wobei das genannte Mittel zur Definition einer Startbe­ dingung weiter Mittel umfaßt zur Auswertung eines drit­ ten logischen Ausdrucks, der den genannten ersten und den genannten zweiten logischen Ausdruck umfaßt.

8. Mittel zur Definition einer Startbedingung nach Anspruch 6 oder 7, weiter umfassend Nachbearbeitungs-Definitionsmittel, um, nachdem der genannte erste oder der genannte zweite logische Ausdruck mit TRUE bewertet wurde, zu definieren, ob eine weitere Nachbearbeitung ausgeführt werden soll, bevor die eigentliche Verarbeitung der genannten Zielaktivität gestartet wird.

9. Mittel zur Definition einer Startbedingung nach Anspruch 8, bei dem die genannten Nachbearbeitungs-Definitionsmit­ tel, nachdem der genannte erste oder der genannte zweite logische Ausdruck mit TRUE bewertet wurde, folgendes definieren:
ob ein zusätzlich abgelegter Wahrheitswert eines ankommenden Steuerungskonnektors der genannten Zielaktivität ignoriert werden soll oder nicht; und/oder
ob Aktivitäten, die in dem genannten Prozeßmodell vor der genannten Zielaktivität liegen, beendet werden sollen.

10. Mittel zur Definition einer Startbedingung nach Anspruch 6 oder 9, bei dem das genannte Startbedingungs-Definitionsmittel die Definition des genannten ersten und/oder des genann­ ten zweiten logischen Ausdrucks als einen beliebigen booleschen Ausdruck unterstützt, der abgelegte Wahr­ heitswerte von jedem der genannten ankommenden Steue­ rungskonnektoren der genannten Zielaktivität umfaßt.

11. Mittel zur Definition einer Startbedingung nach einem jeden der Ansprüche 6 bis 10, bei dem das genannte Mittel zur Definition einer Start­ bedingung die Definition eines logischen Ausdrucks M_OUTOF unterstützt, der von dem genannten WFMS als TRUE bewertet wird, wenn mindestens M aus einer vorgegebenen Menge von ankommenden Steuerungskonnektoren der genann­ ten Zielaktivität mit TRUE bewertet werden.