DE19705955A1 - Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung - Google Patents

Description

1. Hintergrund der Erfindung 1.1 Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf das technische Gebiet des Prozeßmanagements einer Workflow-Umgebung auf Computersystemen. Genauer bezieht sich die vorliegende Erfindung auf eine Erweiterung einer Workflow-Umgebung und ihre Kombination mit einer Objektumgebung, wobei beide Umgebungen auf einem Computersystem residieren und durch es ausführbar sind.

1.2 Beschreibung und Nachteile des Standes der Technik

Der Prozeß des Entwerfens, Entwickelns und Herstellens eines neuen Produktes und der Prozeß des Änderns oder Anpassens eines vorhandenen Produktes bietet viele Herausforderungen für Produktmanager und Ingenieure, um das Produkt zu den geringsten Kosten und innerhalb eines Zeitplanes auf den Markt zu bringen, während die Produktqualität beibehalten oder sogar erhöht wird. Viele Firmen erkennen, daß der übliche Produktentwurfsprozeß nicht befriedigend ist, um diesen Bedürfnissen zu entsprechen. Sie fordern frühes Einbeziehen der Arbeitsplanung, der Kostenplanung, der logistischen Planung, der Beschaffung, der Herstellung, des Service und der Unterstützung bei den Entwurfsbemühungen. Darüber hinaus fordern sie Planung und Steuerung der Produktdaten während des Entwurfs, der Freigabe und der Herstellung.

Die richtige und wirkungsvolle Ausführung von Geschäftsprozessen in einer Firma, z. B. von Entwicklungs- oder Produktionsprozessen, ist von enormer Wichtigkeit für eine Firma und hat bedeutenden Einfluß auf den Gesamterfolg der Firma am Markt. Daher müssen diese Prozesse ähnlich wie Technologieprozesse betrachtet werden und müssen geprüft, optimiert und überwacht werden. Das Management solcher Prozesse wird gewöhnlich durch ein auf einem Computer basierenden Prozeß- oder Workflow-Managementsystem durchgeführt und unterstützt.

In D.J. Spohn: "Project Management Environment", IBM Technical Disclosure Bulletin, Vol. 32, Nr. 9A, Februar 1990, Seiten 250 bis 254, ist die Umgebung eines Prozeßmanagements beschrieben, die eine Arbeitsumgebung, Datenelemente und Anwendungsfunktionen und Prozesse einschließt.

In R.T. Marshak: "IBM′s FlowMark, Object-Oriented Workflow for Mission-Critical Applications", Workgroup Computing Report (USA), Vol. 17, Nr. 5, 1994, Seiten 3 bis 13, ist der Objektcharakter von IBM FlowMark als ein Client/Server-Produkt beschrieben, das auf einem genauen Objektmodell aufgebaut ist, das auf die Anwendungsentwicklung und Entfaltung eines für den Auftrag kritischen Produktionsprozesses zielt.

In H.A. Inniss und J.H. Sheridan: "Workflow Management Based on an Object-Oriented Paradigm", IBM Technical Disclosure Bulletin, Vol. 37, Nr. 3, März 1994, Seite 185, sind andere Aspekte des objektorientierten Modellierens bei Kundenanpassung und Änderungen beschrieben.

In F. Leymann und D. Roller: "Business Process Management with FlowMark", Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, Seiten 230 bis 234, ist das zum Stand der Technik gehörende Computerwerkzeug IBM FlowMark für das Prozeßmanagement beschrieben. Das Metamodell von IBM FlowMark ist dargestellt wie auch die Implementierung von IBM FlowMark. Die Möglichkeiten von IBM FlowMark zum Modellieren von Geschäftsprozessen wie auch ihre Ausführung werden diskutiert. Das Produkt IBM FlowMark ist für verschiedene Computerplattformen verfügbar, und die Dokumentation für IBM FlowMark ist in jeder IBM-Geschäftsstelle verfügbar.

In F. Leymann: "A meta model to support the modelling and execution of processes", Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Vienna, Austria, April 21 to 24, 1992, World Scientific 1992, Seiten 287 bis 294, wird ein Metamodell zum Steuern von Geschäftsprozessen vorgestellt und im einzelnen diskutiert.

Die Veröffentlichung "IBM FlowMark for OS/2", document number GH 19-8215-01, IBM Corporation, 1994, die in jedem IBM- Verkaufsbüro erhältlich ist, stellt ein typisches, modernes, kompliziertes und mächtiges System für das Workflow-Management dar. Es unterstützt das Modellieren von Geschäftsprozessen als ein Netzwerk von Aktivitäten. Dieses Netzwerk von Aktivitäten ist als ein gerichteter, azyklischer, gewichteter, kolorierter Graph aufgebaut. Die Knoten des Graphen stellen die Aktivitäten dar, die durchgeführt werden. Die Kanten des Graphen, die Steuerverbinder, beschreiben die mögliche Folge der Ausführung der Aktivitäten. Die Definition des Prozeßgraphen erfolgt über die IBM FlowMark- Definitionssprache, abgekürzt als (FDL = FlowMark Definition Language), oder den eingebauten graphischen Editor. Die Bearbeitungszeit-Komponente des Workflow-Managers interpretiert den Prozeßgraphen und verteilt die Ausführung von Aktivitäten an die richtige Person am richtigen Platz, z. B. durch Zuweisen von Aufgaben zu einer Arbeitsliste entsprechend der betreffenden Person, wobei die Arbeitsliste als digitale Daten in dem Computersystem für das Workflow- oder Prozeß-Management gespeichert ist.

In F. Leymann und W. Altenhuber: "Managing business processes as an information resource", IBM Systems Journal, Vol. 32(2) 1994, ist die dem IBM FlowMark-Produkt zugrunde liegende mathematische Theorie beschrieben.

In D. Roller: "Verifikation von Workflows in IBM FlowMark", in J. Becker und G. Vossen (Hrsg. ): "Geschäftsprozeßsmodellierung und Workflows", International Thompson Publishing, 1995, ist die Voraussetzung und Möglichkeit der Verifikation von Workflows beschrieben. Darüber hinaus ist das Merkmal der graphischen Belebung für die Verifikation der Prozeßlogik dargelegt, wie sie in dem IBM FlowMark-Produkt implementiert ist.

Für das Implementieren eines auf dem Computer basierenden Systems für das Prozeßmanagement müssen zuerst die Geschäftsprozesse analysiert werden, und als Ergebnis dieser Analyse muß ein Prozeßmodell als ein Netzwerk von Aktivitäten aufgebaut werden, die dem Geschäftsprozeß entsprechen. In dem IBM FlowMark-Produkt werden die Prozeßmodelle nicht in ein ausführbares Modell transformiert. Während der Laufzeit wird eine Instanz des Prozesses aus dem Prozeßmodell erstellt, die Prozeßinstanz genannt wird. Diese Prozeßinstanz wird dann dynamisch durch das IBM FlowMark-Produkt interpretiert.

Eine frühere Patentanmeldung des gleichen Anmelders, Anmeldungsnummer PCT/EP95/03345 mit dem Titel "Method and Computer System for Generating Process Management Computer Programs from Process Models", lehrt, wie ein Prozeßgraph in ein C++-Programm transformiert werden kann, wenn der Prozeß durch einen Benutzer zu einem Zeitpunkt an einer Stelle nacheinander ausgeführt wird.

Das technologische Gebiet der Objektumgebungen ist zum Beispiel bekannt geworden durch den Common Object Request Broker (CORBA) standard of the Object Management Group (OMG). Ausführliche Informationen über CORBA finden sich in "The Common Object Request Broker: Architecture and Specifications", OMG Document Number 91.12.1, Revision 1.1. CORBA ist Teil einer größeren Objektarchitektur, die in großen Zügen dargestellt ist in der Anleitung der OGM "Object Management Architecture (OMA) Guide". Einzelheiten über die OMA finden sich in Object Management Architecture (OMA) Guide Revision 2.0, Second Edition, September 1, 1992, OMG TC Document 92.11.1. Im Hinblick auf CORBA sind verschiedene Implementierungen und Erweiterungen dieses Standards kommerziell verfügbar, wie z. B. das System-Objekt-Modell, abgekürzt als (SOM), von IBM. Natürlich sind andere Objektumgebungen, die nicht dem CORBA-Standard entsprechen, Teil des Standes der Technik oder können es sein.

1.3 Aufgabe der Erfindung

Die Erfindung beruht auf der Aufgabe, eine neue Art der Erweiterung eines Prozeßmodells innerhalb einer Workflow- Umgebung anzugeben, die eine automatische und von einem Computer durchgeführte Generierung einer Implementierung des Prozeßmodells in einer Objektumgebung aus löst und bei der die Implementierung des Prozeßmodells auf einem Computersystem ausführbar ist.

2. Zusammenfassung und Vorteile der Erfindung

Die Aufgabe der Erfindung wird durch die unabhängigen Ansprüche 1 und 5 gelöst. Weitere Ausfürungsbeispiele der Erfindung werden in den entsprechenden abhängigen Ansprüchen offenbart.

Gemäß dem Anspruch 1 lehrt die Erfindung ein Verfahren zum Erweitern der Spezifikationen eines Prozeßmodells in einer Workflow-Prozeßumgebung, wobei das Prozeßmodell eine Prozeßaktivität definiert, die durch mindestens ein Computersystem verwaltet und ausgeführt wird. Das Verfahren des Erweiterns verbindet das Prozeßmodell mit einer Objektumgebung, innerhalb derer die Prozeßaktivität zu implementieren ist. Diese Verbindung wird realisiert durch einen Schritt des Verknüpfens der Prozeßaktivität des Prozeßmodells mit mindestens einer Objektklasse und einer Objektmethode, die innerhalb der Objektumgebung residieren und eine Prozeßaktivität implementieren.

Aufgrund dieser Erweiterungen der Spezifikationen eines Prozeßmodells wurde die Lücke zwischen zwei unterschiedlichen und getrennten Umgebungen, einer Workflow-Prozeßumgebung auf der einen Seite und einer Objektumgebung auf der anderen Seite, ausgefüllt. Gemäß der vorliegenden Erfindung ist jetzt ein nahtloser Übergang durchführbar.

Als einen weiteren Vorteil stellen die erweiterten Spezifikationen eine vereinheitlichte Modellumgebung der Prozeßmodelle dar, unabhängig von den tatsächlichen Implementierungen des Prozeßmodells. Daher erlauben die erweiterten Spezifikationen es, sich auf die höchst wichtige Aufgabe, die Spezifikation von Workflow-Prozeßmodellen, unabhängig von ihrer tatsächlichen Implementierung, zu konzentrieren, was gemäß der vorliegenden Erfindung in einer Objektumgebung realisiert werden kann.

Viele der Objektumgebungen, wie die SOM-Objektumgebung von IBM, die für das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung von Wichtigkeit sind, lassen es zu, Objektstrukturen in fast jeder Implementierungssprache (C++, C, COBOL, . . . ) zu implementieren. Daher führt die obige Erweiterung eine vollständige Unabhängigkeit der Implementierung für ein Prozeßmodell ein. Mehr noch, Objektstrukturen und Objektmethoden, die bereits in einer Objektumgebung implementiert sind, was typischerweise für eine Menge von Geschäftsobjekten der Fall ist, können nun direkt als Implementierungen von Prozeßaktivitäten wiederverwendet werden.

Zusätzliche Vorteile werden nach Anspruch 2 erreicht. Gemäß einem weiteren Ausführungsbeispiel der vorgeschlagenen Erfindung verknüpft die Methode des Erweiterns auch die Felder der Input- und Output-Container mit den Input- und Output- Parametern der zugeordneten Objektmethode.

Diese Lehre überbrückt zwei unterschiedliche Konzepte. Das Container-Konzept auf der Seite der Workflow-Prozeßumgebung, das eine Sammlung der augenblicklichen Input-/Output- Datenfelder eines aktiven Prozesses speichert, und das Konzept der Methodenparameter auf der Seite der Objektumgebung, das die entsprechende Lösung zum Speichern von Input-/Output- Informationen für aktive Objektmethoden innerhalb der Objektumgebung darstellt.

Zusätzliche Vorteile werden nach den Ansprüchen 3 und 4 erreicht.

Gemäß einem weiteren Ausführungsbeispiel der vorgeschlagenen Erfindung verknüpft das Verfahren des Erweiterns Ausnahmesituationen, die durch die zugeordnete Objektmethode innerhalb der Objektumgebung signalisiert werden können, mit Return-Code-Feldern des Prozeßmodells und bildet sie ab.

Das Konzept der Ausnahmesituationen ist ein eindeutiger Lösungsweg der Objektumgebungen, der innerhalb einer Workflow- Prozeßumgebung nicht benutzt wird. Durch Einführen der obigen Lehre realisiert die vorliegende Erfindung eine nahtlose Integration des Konzeptes der Ausnahmesituationen innerhalb der Workflow-Prozeßumgebung.

Gemäß Anspruch 5 lehrt die vorliegende Erfindung ein mit einem Computer durchzuführendes Verfahren für das automatische Generieren einer Implementierung eines Prozeßmodells, das durch zumindest ein Computersystem verwaltet und ausgeführt wird. Das Verfahren des Generierens benutzt die Spezifikationen eines Prozeßmodells, das durch Spezifikationen erweitert wird, die das Prozeßmodell mit Objektstrukturen außerhalb der Workflow-Prozeßumgebung verknüpfen, und generiert eine Implementierung des Prozeßmodells als Objektstrukturen, die innerhalb einer Objektumgebung residieren. Die generierte Implementierung des Prozeßmodells umfaßt eine Implementierungskomponente, die innerhalb der Prozeßumgebung residiert, und eine Implementierungskomponente, die innerhalb der Objektumgebung residiert. Das Verfahren des Generierens umfaßt einen Schritt zur Analyse der Spezifikationen des Prozeßmodells. Aufgrund dieser Analyse generiert das Verfahren die zugeordneten Objektklassen und die zugeordneten Objektmethoden als Implementierungen der Prozeßaktivitäten, wenn diese zugeordneten Objektklassen und zugeordneten Objektmethoden noch nicht existieren. Zum Aufrufen der generierten und implementierenden Objektmethode aus der Workflow-Prozeßumgebung wird in einem anderen Schritt ein Aufruftext generiert.

Es ist vorteilhaft, daß alle Spezifikationen, die in der Workflow-Prozeßumgebung verfügbar sind, ausgenutzt werden können und der automatischen Generierung der Implementierungsstrukturen genügen, die sich außerhalb der Prozeßumgebung befinden. Keine menschliche Intervention ist länger erforderlich, um die Objektstrukturen zu erstellen. Darüber hinaus ist aufgrund des Automatismus des Verfahrens keine weitere Kenntnis der Besonderheiten der Objektumgebung für das Erstellen der Prozeßmodelle erforderlich. Als Folge stellt die Prozeßmodellierung in der Workflow-Prozeßumgebung eine vereinheitlichte Modellierungsumgebung dar, die unabhängig von tatsächlichen Implementierungen des Prozeßmodells ist. Daher können Benutzer der Erfindung sich auf die höchst wichtige Aufgabe konzentrieren, die Spezifikation der Workflow-Prozeßmodelle, unabhängig von ihrer tatsächlichen Implementierung, die gemäß der vorliegenden Erfindung automatisch als Objektstrukturen innerhalb einer Objektumgebung generiert werden kann. Alle verfügbaren Werkzeuge innerhalb der Workflow-Prozeßumgebung, die die Definition von Prozeßmodellen unterstützen, können jetzt benutzt werden, um auch die implementierenden Objektstrukturen zu generieren.

Viele Objektumgebungen, wie die SOM-Objektumgebung von IBM, die von Wichtigkeit für das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung sind, lassen es zu, Objektstrukturen in fast jeder Implementierungssprache (C++, C, COBL, . . . ) zu implementieren. Selbst vorhandene Objektstrukturen und Objektverfahren, die bereits in einer Objektumgebung implementiert sind, was typischerweise für eine Reihe von Geschäftsobjekten der Fall ist, können jetzt direkt als Implementierungen von Prozeßaktivitäten wiederverwendet werden.

Es ist weiter vorteilhaft, daß die generierten Objektstrukturen ausführbare Programme sind, so daß das Verarbeiten eines Prozeßmodells über die Ausführung eines Programms durchgeführt wird anstatt über die dynamische Interpretation des Prozeßmodells durch die Workflow- Prozeßumgebung. Dies erlaubt es der Workflow-Prozeßumgebung, mit bedeutend geringerem Betriebsmittelverbrauch zu arbeiten, d. h. mit weniger Rechen- und Speicherhilfsmitteln, bei sogar höherer Geschwindigkeit.

Als ein weiterer Vorteil generiert die vorliegende Erfindung nicht nur die implementierenden Objektstrukturen in der Objektumgebung, sondern auch einen Aufruftext, um die zugeordneten Objektmethoden aus der Workflow-Prozeßumgebung aufzurufen.

Zusätzliche Vorteile werden nach Anspruch 6 erreicht. Gemäß einem weiteren Ausführungsbeispiel der vorgeschlagenen Erfindung generiert das Verfahren in einem weiteren Schritt Input- und Output-Variablen für jedes Feld des Input-und Output- Containers, das mit Input- und/oder Output-Parametern der zugeordneten Objektmethoden verknüpft ist.

Es ist sehr zeitaufwendig, diese Variablen zu generieren, ohne durch einen automatischen Prozeß unterstützt zu werden. Auch ist diese Aufgabe typischerweise sehr fehlerträchtig, wenn sie nicht durch solch eine Art des Automatismus bewerkstelligt wird.

Zusätzliche Vorteile werden nach Anspruch 7 und 8 erreicht. Gemäß einem weiteren Ausführungsbeispiel der vorgeschlagenen Erfindung generiert das Verfahren innerhalb des Aufruftextes auch Verarbeitungsfolgen zum Kopieren von Werten der Felder der Input-Container in die generierten Input-Variablen. Dieser Aufruftext ist ausgestattet, zugeordnete Objektklassen zu instanziieren und zugeordnete Objektmethoden für die Ausführung der implementierenden Prozeßaktivität aufzurufen. Der Aufruftext ist weiter ausgestattet, um mögliche Ausnahmesituationen, die in der Objektumgebung signalisiert werden, zu analysieren und zu behandeln und sie zu der Workflow-Prozeßumgebung zu übertragen. Schließlich sorgt der generierte Aufruftext dafür, die generierten Input- und Output-Variablen zu löschen.

Diese Aufgabe automatisch zu bewerkstelligen ist von großer Wichtigkeit, da das Erstellen dieses Aufruftextes die Kenntnis beider Umgebungen erfordert, die der Workflow-Umgebung wie auch die der Objektumgebung. Wenn, wie im vorliegenden Fall, alle diese Schritte automatisch durchgeführt werden können, erhält man eine nahtlose Verbindung einer Workflow- Prozeßumgebung und einer Objektumgebung. Darüber hinaus ist es in diesem Fall ein weiterer Vorteil, daß das Workflow- Prozeßmodell einen vereinheitlichten Modellierungsweg für Prozeßmodelle darstellt, unabhängig von den tatsächlichen Implementierungen des Prozeßmodells.

3. Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Schema, das die Spezifikation vergegenwärtigt, um aufgrund eines Beispiels eine registrierte Objektklasse mit einem Klassennamen zu verknüpfen;

Fig. 2 ist ein Schema, das die Spezifikation vergegenwärtigt, um aufgrund eines Beispiels eine Objektmethode, die eine Prozeßaktivität implementiert, mit einer Prozeßaktivität zu verknüpfen;

Fig. 3 veranschaulicht die Spezifikationen, die es erlauben, die Felder der Input- und Output-Container auf die Input-, Output- und INOUT-Methodenparameter der registrierten Objektmethoden abzubilden;

Fig. 4 veranschaulicht eine bestimmte Form des Verknüpfens einer Variablen, die eine Ausnahmesituation von Signifikanz in der Objektumgebung speichert, mit dem Return-Code von Signifikanz innerhalb der Prozeßumgebung;

Fig. 5 veranschaulicht eine bestimmte Form des Verknüpfens eines spezifischen Wertes, der eine Ausnahmesituation von Signifikanz in der Objektumgebung darstellt, mit dem Return-Code von Signifikanz innerhalb der Prozeßumgebung;

Fig. 6 veranschaulicht eine Input- oder Output-Variable, die während des Generierungsprozesses unter der Annahme erstellt wird, daß der Analyseschritt eine Spezifikation feststellte, die Felder der Input- oder Output-Container mit Input- oder Output-Parametern der Objektmethoden verknüpft;

Fig. 7 veranschaulicht eine während des Generierungsprozesses erstellte Variable, die sich auf eine Ausnahmesituation bezieht unter der Annahme, daß der Analyseschritt eine Spezifikation zur Abbildung von Ausnahmesituationen in der Objektumgebung auf ein Feld des Return-Codes in der Prozeßumgebung feststellte;

Fig. 8 faßt das Verfahren des Generierens einer Implementierung eines Prozeßmodells in einer Objektumgebung zusammen, die von einer Prozeßumgebung zugänglich ist;

Fig. 9 veranschaulicht eine generierte Implementierungsfolge für das Aufbauen einer Input-Variablen einer Objektmethode;

Fig. 10 veranschaulicht eine generierte Implementierungsfolge für das Instanziieren einer zugeordneten Objektklasse;

Fig. 11 veranschaulicht eine generierte Implementierungsfolge für das Aufrufen einer zugeordneten Objektmethode;

Fig. 12 veranschaulicht eine generierte allgemeine Implementierungsfolge für die Prüfung, ob eine aufgerufene Objektmethode eine Ausnahmesituation verursachte;

Fig. 13 veranschaulicht eine generierte Implementierungsfolge für das Prüfen, ob eine aufgerufene Objektmethode eine Ausnahmesituation des Systems verursachte;

Fig. 14 veranschaulicht eine generierte Implementierungsfolge für das Prüfen, ob eine aufgerufene Objektmethode eine Ausnahmesituation verursachte, unter besonderer Beachtung der Analyse der Art der Ausnahmesituation, die in der Objektumgebung auftrat;

Fig. 15 veranschaulicht eine generierte Implementierungsfolge, wenn die Prüfung einer möglichen Ausnahmesituation die Abbildung der Werte der Ausnahmesituation einschließt;

Fig. 16 veranschaulicht eine generierte Implementierungsfolge für das Behandeln einer Ausnahmesituation, die durch eine Objektmethode verursacht wurde, wenn die Ausnahmesituation nicht identifizierbar ist und statt dessen ein Return-Code für eine Standard- Ausnahmesituation des Systems benutzt wird;

Fig. 17 veranschaulicht eine generierte Implementierungsfolge für das Prüfen, ob eine aufgerufene Objektmethode eine Ausnahmesituation verursachte, wenn keine Ausnahmesituation festgestellt werden konnte;

Fig. 18 vergegenwärtigt einen Prozeßablauf an einem einfachen Beispiel, das sich auf den Vorgang der Abhebung von einem Bankkonto bezieht;

Fig. 19 stellt die Definitionen des Prozeßmodells für das ABHEBUNGS-Beispiel dar, das in der FlowMark- Definitionssprache (FDL) dargestellt ist, einschließlich der Spezifikationen, die gemäß der Lehre der vorliegenden Erfindung generiert werden und die Verknüpfung zwischen der Prozeßumgebung und der Objektumgebung für das Prozeßmodell darstellen;

Fig. 20 zeigt die generierten Strukturen der SOM-Klasse in ihrem IDL (Interface Definition Language)-Ausdruck, wenn sie nicht bereits durch andere Prozeduren verfügbar sind, wie die Implementierung des Teils des Prozeßmodells, das in der SOM-Objektumgebung gemäß der Lehre der vorliegenden Erfindung generiert wurde;

Fig. 21 spiegelt die Klassenerweiterungen der DatenFeld (dataItem)-Klasse wieder, die den Prozeß des Kopierens der Werte der Container-Felder in die Parameter der Objektmethoden unterstützen;

Fig. 22 vergegenwärtigt den Code, der gemäß der Lehre der vorliegenden Erfindung generiert wurde, der aus der FlowMark-Prozeßumgebung eine zugeordnete Objektmethode einer zugeordneten Klasse aufruft, die die Aktivität des Beispiels in der SOM-Objektumgebung implementiert.

Die Codefolge assembliert einen Aufruftext für das Aufrufen der zugeordneten Objektmethode.

4. Beschreibung des bevorzugten Ausführungsbeispiels 4.1 Einleitung

Die folgende Beschreibung der Erfindung basiert auf dem FlowMark-Workflow-Manager von IBM. Ohne irgendeine Beschränkung des Schutzumfangs der Erfindung kann irgendein anderer Workflow- Manager statt dessen für eine Implementierung der Erfindung verwendet werden.

In ähnlicher Weise zielt das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung auf das System-Objekt-Modell, abgekürzt als (SOM), von IBM als Objektumgebung, für die die Objektimplementierungen generiert werden. Wieder begrenzt diese Wahl einer Objektumgebung nicht den Schutzumfang der Erfindung. Die vorgeschlagenen Methoden sind auf irgendeine andere Implementierung des OMG CORBA-Standards und irgendeine andere mögliche Objektumgebung anwendbar.

Auf dem technischen Gebiet der Objektorientierung wird der Ausdruck "Objekt" bisweilen in einem weiteren Sinne benutzt, der faktisch eine Objektklasse bezeichnet, und bisweilen wird er in einem engen Sinn benutzt, wobei er eine Instanz einer Klasse von Objekten bezeichnet. Ebenso kann der Ausdruck "Objekt" faktisch dazu benutzt werden, eine Instanz eines Klassenobjektes zu bezeichnen. Abhängig von dem Zusammenhang, in dem der Ausdruck benutzt wird, ist es offensichtlich, auf welche der verschiedenen Bedeutungen sich der Ausdruck bezieht.

Die vorliegende Erfindung generiert Objektstrukturen in der Objektumgebung als C++ -Programme. Die Lehre der vorliegenden Erfindung ist von allgemeiner Art, und daher kann der Generierungsprozeß diese Objektstrukturen in irgendeiner anderen Programmiersprache erstellen.

4.2 Konzepte

Die IBM FlowMark-Familie implementiert einen Workflow-Manager. Er unterstützt das Modellieren von Geschäftsprozessen als ein Netzwerk von Aktivitäten. Dieses Netzwerk von Aktivitäten ist als ein gerichteter, azyklischer, gewichteter, kolorierter Graph aufgebaut. Die Knoten des Graphen stellen die Aktivitäten dar, die durchgeführt werden. Die Kanten des Graphen beschreiben die mögliche Folge der Ausführung der Aktivitäten. Die Definition des Prozeßgraphen geschieht über die IBM FlowMark- Definitionssprache (FDL) oder den eingebauten graphischen Editor. Die Bearbeitungszeit-Komponente des Workflow-Managers interpretiert den Prozeßgraphen und verteilt die Ausführung der Aktivitäten auf die richtige Person am richtigen Platz.

IBM FlowMark implementiert das Konstrukt einer Programmaktivität. Die Programmaktivität nimmt Bezug auf ein Programmobjekt, das die Informationen über das Programm liefert, wie beispielsweise einen Aufrufmechanismus, einen durch ein Programm aktivierbaren Namen, Input- und Output-Datenstrukturen und eine Ausführungsumgebung. Diese Informationen werden benutzt, um das Programm aufzurufen, das der Programmaktivität zugeordnet ist. Daher ist das Programmobjekt die Verbindung zwischen der Definition der Programmaktivität, d. h. dem Prozeßmodell, und dem ausführbaren Programm, das diese Aktivität implementiert.

Das System-Objekt-Modell (SOM) ist IBM′s Implementierung binärer, kompatibler Klassenbibliotheken. SOM ist vollständig beschrieben in "IBM SOM Objects Developer Toolkit Users Guide", erhältlich in der IBM-Niederlassung. Klassen werden mittels OMG′s Schnittstellen-Definitionssprache (IDL) beschrieben. Aus dieser Definition generiert der SOM-Compiler (1) die geeignete Kopfzeilendatei für das Einfügen in ein Programm, das diese Klasse benutzt, und (2) eine Schablone für das Implementieren der Methoden durch den Methodenimplementierer. Wahlweise speichert der SOM-Compiler alle SOM-Klasseninformationen in dem SOM-Schnittstellenspeicher, abgekürzt als (SOM IR = SOM Interface Repository). SOM liefert Klassen und zugeordnete Methoden, um auf den SOM-Schnittstellenspeicher zuzugreifen.

In vielen Fällen werden diese Programmaktivitäten als Maßnahme- Objekt-Paare ausgedrückt. Bei einer Darlehensanwendung können die Aktivitäten ausgedrückt werden als Risikoabschätzung, Kreditablehnung und Kreditgewährung. Dies führt selbst zu der Interpretation von Aktivitäten als dem Aufrufen einer Methode für ein Objekt.

Die beschriebenen Methoden der Erfindung lehren, wie das FlowMark-Prozeßmodell erweitert werden kann, um das Aufrufen von Methoden gegenüber SOM-Objekten als eine Implementierung einer Programmaktivität zu unterstützen. Die Felder in dem Input- Container werden in die Parameterfelder der Methode kopiert, die Methode wird ausgeführt, die Ausnahmesituationen, die durch die Methode rückgemeldet werden, werden in das Konstrukt des Return- Codes des Prozeßmetamodells übersetzt, und die Parameterfelder der Methode werden in die geeigneten Felder des Output- Containers kopiert. Daher ermöglicht die vorliegende Erfindung es den Benutzern, Anwendungen durch Benutzen der IBM FlowMark- Definitionssprache zu erstellen, um Methoden gegenüber Geschäftsobjekten zusammenzuschreiben, die als SOM-Klassen implementiert wurden.

4.3 Ergänzungen des Prozeßmodells

Ein neuer Registrierungsmechanismus für das Registrieren von SOM Klassen wird der FlowMark Definitionssprache als ein Satz von zusätzlichen Spezifikationen hinzugefügt. Dieser Mechanismus wird nach dem Programm-Registrierungsmechanismus als ein getrennter Abschnitt modelliert. Jede SOM-KLASSE ist über das Schlüsselwort SOMKLASSE (SOMCLASS) registriert. Auf dieses Schlüsselwort folgt der Name der SOM-Klasse. Dieser Name wird von einer Programmaktivität benutzt, um auf die SOM-Klasse Bezug zu nehmen. Der eigentliche Name der SOM-Klasse wird über das Schlüsselwort KLASSENNAME (CLASSNAME) angegeben. Wenn nicht angegeben, erscheint als faktischer Name der SOM-Klasse der Registrierungsname. Alle Klasseninformationen werden durch Zugreifen auf den SOM-Schnittstellenspeicher erhalten. Fig. 1 zeigt die Registrierung der Konto-Klasse (account class) unter dem Registrierungsnamen von Konto (Account). Der Klassenname Konto (account) wird benutzt, um auf den SOM- Schnittstellenspeicher zuzugreifen.

Der Programmaktivitätsmechanismus von IBM FlowMark wird erweitert, um das Aufrufen der Methoden gegenüber den SOM- Objekten als eine Implementierung einer Programmaktivität zu unterstützen. Dies erfordert, daß die folgenden Informationen dem PROGRAMM AKTIVITÄTS (PROGRAMM ACTIVITY)-Schlüsselwort hinzugefügt werden:

• 1. der Name der SOM-Klasse über das SOMKLASSE (SOMCLASS)-Schlüsselwort
• 2. der Name der Methode über das METHODEN (METHOD)- Schlüsselwort und
• 3. die Identifizierung des Objektes über das OBJEKTID (OBJECTID)-Schlüsselwort.

Bestimmte dieser Spezifikationen, die die Verknüpfung mit einer Objektmethode als Implementierung einer Aktivität modellieren, sind in Fig. 2 dargestellt. Speziell zeigt Fig. 2 das Abheben von Geld von einem Konto. Dies wird durchgeführt durch Aufrufen der Abhebungs-Methode für ein Abhebungs-Objekt.

Der Name des Objektes, wie er über das OBJEKTID (OBJECTID)- Schlüsselwort angegeben ist, identifiziert die Instanz der SOM- Klasse, für die die Methode aufgerufen werden sollte. Mehrere Instanzen einer bestimmten SOM-Klasse können innerhalb des Prozesses gleichzeitig vorhanden sein. Für jede SOM-Klasse wird eine globale Instanz aufrechterhalten. Diese globale Instanz wird benutzt, wenn keine Objektidentifizierung angegeben ist.

Die Abbildungen zwischen den Methodenparametern und den Feldern in dem Input-/Output-Container werden über ein Abbildungsschema ausgedrückt. Dieses Abbildungsschema definiert, wie die Werte der Felder des Input-Containers in die Methodenparameter kopiert werden, die als IN oder INOUT definiert sind, und nach der Ausführung der Methode, wie die Werte der Methodenparameter, die mit INOUT oder OUT definiert sind, in die geeigneten Felder in dem Output-Container kopiert werden. Die Einzelheiten des Abbildungsschemas sind in dem Kapitel "Parameterabbildung" beschrieben.

Ausnahmesituationen sind die Mittel, durch die SOM-Methoden, die in der Objektumgebung ausführen, anzeigen, daß die Methode einen Fehler festgestellt hat. Sie werden über die Umgebungsstruktur (environment structure) rückgemeldet, die als ein Parameter in der Methode weitergeleitet wird. Ein Return- Code, der als das RC-Feld in dem Output-Container implementiert ist, ist das Mittel, durch das Programme dem IBM FlowMark anzeigen, daß sie einen Fehler festgestellt haben. Ein Abbildungsschema ist vorgesehen, das es erlaubt, den SOM- Fehlermechanismus auf den IBM FlowMark-Fehlermechanismus abzubilden, das heißt, die SOM-Ausnahmesituationen auf die IBM FlowMark-Return-Codes abzubilden. Einzelheiten des Abbildungsschemas werden in dem Kapitel "Behandlung von Ausnahmesituationen" beschrieben.

4.3. 1 Parameterabbildung

Die Regeln zum Abbilden von Feldern des Input-Containers auf die IN- und INOUT-Parameter der Methode und das Abbilden der INOUT- und OUT-Parameter auf den Output-Container können auf den ansteigenden niedrigeren Niveaus der Klasse, der Methode und des Programmaktivitätsniveaus angegeben werden. Abbildungen auf einem niedrigeren Niveau setzen die Abbildungen auf höheren Niveaus außer Kraft.

Der Unterabschnitt INPUTABBILDUNG (INPUTMAPPING) innerhalb der FlowMark-Definitionssprache startet die Menge von Regeln für das Abbilden der Felder des Input-Containers auf die Methodenparameter; der Unterabschnitt OUTPUTABBILDUNG (OUTPUTMAPPING) startet die Menge von Regeln für das Abbilden von Methodenparametern auf die Felder des Output-Containers.

Das Schlüsselwort DATENSTRUKTUR (DATASTRUCTURE), auf das eine Zeichenkette folgt, erlaubt es, den Namen der Datenstruktur anzugeben, die durch die Zeichenkette identifiziert wird, die die Felder enthält, für die das Abbilden angegeben ist. Die Spezifikation des DATENSTRUKTUR (DATASTRUCTURE)- Schlüsselwortes ist bedeutungslos, wenn sie auf dem Aktivitätsniveau angegeben ist. Die tatsächliche Abbildung wird über die Schlüsselwortpaare BILDE AB/AUF (MAP/TO) angegeben. Auf das Schlüsselwort BILDE AB (MAP) folgt der Name des Feldes in der Datenstruktur, auf das das AUF (TO)-Schlüsselwort folgt, auf das der Name des Methodenparameters folgt. Fig. 3 zeigt das Abbilden des Feldes KontoNr. (accountNr.) in der Datenstruktur Konto (Account), d. h. in dem Input-Container, auf den Parameter Konto (account) der Objektmethode. Da die Spezifikation auf dem Klassenniveau erfolgt, wird dieses Abbilden auf alle Methoden angewandt, die ein Parameterfeld aufweisen mit dem Namen Konto (account), und der Input-Container der zugeordneten Programmaktivität nimmt Bezug auf die Datenstruktur mit dem Namen Konto (Account).

Wenn keine Abbildung angegeben ist, erfolgt die Abbildung durch den Feldnamen. Wenn keine Übereinstimmung gefunden wird, wird der Methodenparameter auf NULL (NULL) gesetzt für Parameter von der Art ZEICHENKETTE (STRING) und auf null für Parameter von der Art LANG (LONG) oder VARIABEL (FLOAT).

4.3.2 Behandlung von Ausnahmesituationen

SOM unterscheidet zwei Arten von Ausnahmesituationen. Ausnahmesituationen des Systems und Ausnahmesituationen der Benutzung. Der Satz von Ausnahmesituationen des Systems wird durch CORBA definiert und kann durch irgendeine Methode rückgemeldet werden. Genauere Information über CORBA findet man in "The Common Object Request Broker: Architecture and Specifications", OMG Document Number 91.12.1, Revision 1.1. Ausnahmesituationen der Benutzung müssen mit der SOM-Klasse registriert werden. Die Menge von Ausnahmesituation der Benutzung, die durch eine Methode rückgemeldet werden können, sind zusammen mit der Methode angegeben.

4.3.2.1 Ausnahmesituation des Systems

Wenn eine Ausnahmesituation des Systems rückgemeldet wird, dann muß die Ausnahmesituation des Systems auf einen Wert abgebildet werden, der in dem RC-Feld in dem Output-Container zu speichern ist. Dieser Wert wird aus einer Tabelle generiert, die durch den Benutzer gewartet werden kann. Die Tabelle enthält eine Menge von Einträgen, wobei jeder Eintrag aus einer durch CORBA spezifizierten Ausnahmesituation und dem Return-Code besteht, auf den die Ausnahmesituation abgebildet werden sollte. Wenn eine bestimmte Ausnahmesituation in der Tabelle nicht definiert ist, wird ein durch den Benutzer definierbarer Standard-Return- Code für eine Ausnahmesituation des Systems benutzt. Wenn der Benutzer keinen Wert für diesen Return-Code einer Systemausnahmesituation angegeben hat, wird ein durch das System definierter Standard-Return-Code von -100 für eine Ausnahmesituation des Systems benutzt.

4.3.2.2 Ausnahmesituation der Benutzung

Wenn eine Ausnahmesituation der Benutzung rückgemeldet wird, muß die Ausnahmesituation der Benutzung auf einen Wert abgebildet werden, der in dem RC-Feld in dem Output-Container zu speichern ist. Die Abbildungsregeln können auf den ansteigenden niedrigeren Niveaus der Klasse, der Methode und des Programm- Aktivitätsniveaus definiert werden. Abbildungsregeln auf einem niedrigeren Niveau setzen die entsprechenden Abbildungsregeln auf höheren Niveaus außer Kraft.

Der Unterabschnitt BENUTZUNGAUSNAHMESITUATION (USEREXCEPTION) in den Spezifikationen der FlowMark-Definitionssprache startet die Menge von Abbildungsregeln, die unter Benutzung des Schlüsselwortpaares ABBILDUNG-(VON/AUF) (MAP-(FROM/TO)) definiert sind. Diese Spezifikationen verkörpern eine Verknüpfung zwischen den möglicherweise auftretenden Ausnahmesituationen während der Ausführung einer Objektmethode in der Objektumgebung und einem Return-Code innerhalb der Prozeßumgebung. Auf das Schlüsselwort ABBILDUNG (MAP) folgt eine Zeichenkette, die die Ausnahmesituation der Benutzung identifiziert, worauf entweder das AUF (TO)- oder das VON (FROM)-Schlüsselwort folgt, und die durch eine Zeichenkette beendet wird, welche entweder der Name eines Feldes ist, das in der Ausnahmesituation definiert ist, oder eine ganze Zahl.

Das VON (FROM)-Schlüsselwort wird benutzt, um anzugeben, daß die Zeichenkette ein Feld in der Ausnahmesituation definiert. Der Inhalt dieses Feldes wird zu dem RC-Feld für den Return-Code in dem Output-Container übertragen. Das Feld muß von der Art LANG (LONG) oder VARIABEL (FLOAT) sein. Fig. 4 zeigt, daß das Feld FehlerCode (errorCode) ausgewählt wird als das Feld, aus dem der Wert entnommen und in dem RC-Feld gespeichert wird.

Das AUF (TO)-Schlüsselwort wird benutzt, um anzugeben, daß die Zeichenkette einen ganzzahligen Wert enthält. Wenn die Ausnahmesituation ausgelöst wird, wird das RC-Feld des Output- Containers mit der ganzen Zahl gefüllt. Fig. 5 zeigt, daß 30 in das RC-Feld eingesetzt werden sollte, wenn die Ausnahmesituation UngültigesKonto (invalidAccount) rückgemeldet wird.

Wenn keine Abbildung für eine Ausnahmesituation der Benutzung definiert ist, wird die Ausnahmesituation nach Feldern von der Art LANG (LONG) oder KURZ (SHORT) durchsucht. Das Feld wird gemäß der folgenden Suchreihenfolge ausgewählt:

• 1. wenn nur ein Feld von der Art LANG (LONG) definiert ist, wird dieses Feld ausgewählt,
• 2. wenn nur ein Feld von der Art KURZ (SHORT) definiert ist, wird dieses Feld ausgewählt,
• 3. wenn mehrere Felder von der Art LANG (LONG) definiert sind, wird beim Lesen des SOM-Schnittstel­ lenspeichers das erste Feld der Art LANG (LONG) ausgewählt, und
• 4. wenn mehrere Felder der Art KURZ (SHORT) definiert sind, wird beim Lesen des SOM-Schnittstellenspei­ chers das erste Feld der Art KURZ (SHORT) ausgewählt.

Wenn die Ausnahmesituation kein Feld aufweist oder ihr kein Feld von der Art LANG (LONG) oder KURZ (SHORT) zugeordnet ist, wird ein durch die Benutzung definierter Standard-Return-Code für eine Ausnahmesituation der Benutzung dem Return-Code zugeordnet. Wenn der Benutzer keinen Standard-Return-Code für eine Ausnahmesituation der Benutzung definiert hat, wird ein vom System definierter Return-Code von +100 für eine Ausnahmesituation der Benutzung benutzt.

4.4 Programmgenerierung

Aufgrund der zusätzlichen Spezifikationen der FlowMark- Definitionssprache, die in dem Kapitel "Ergänzungen des Prozeßmodells" dargelegt wurden, kann ein Programmgenerierungsverfahren dazu benutzt werden, um automatisch die Objektstrukturen zu generieren, die die angebebenen Aktivitäten implementieren. Die spezifische Unterstützung von Methodenaufrufen gegenüber SOM-Objekten als Implementierung von Programmaktivitäten erfordert einen eindeutigen Generierungsprozeß.

Insbesondere während der Phase 1 der vorzuschlagenden Generierungsmethode muß der neue FDL-Abschnitt für die Registrierung der SOM-Klassen und der neuen Schlüsselwörter für den Abschnitt PROGRAMM AKTIVITÄT (PROGRAM ACTIVITY) durch den Generierungsprozeß erkannt werden.

In Phase 2 der Generierungsmethode müssen der richtige Code für die Unterstützung der SOM-Objekte und die Methodenaufrufe für diese Objekte generiert werden. Darüber hinaus müssen die Kopfzeile des Programms und der Programmrumpf entsprechend generiert werden.

4.4.1 Generierung der Programmkopfzeile

Für jede SOM-Klasse wird die richtige Einfügeanweisung für die Kopfzeilendatei der Klasse in der Form #füge "Klassennamen.xh ein" (#include "classname.xh") erstellt.

Die DatenFeld (dataItem)-Klassen, die die Klassen sind, die für die Implementierung und Instanziierung des Input- und Output- Containers benutzt werden, werden mit einer neuen Methode ErstelleWert (CreateValue) erweitert. Diese neue Methode wird benutzt, um einen Parameter der Methode durch Kopieren aus einem Feld in dem Input-Container einzusetzen. Wenn das Containerfeld keinen Wert enthält, wird ein NULL (NULL)-Zeiger den Parametern von der Art ZEICHENKETTE (STRING) zugeordnet und null (zero) den Parametern von der Art LANG (LONG) und VARIABEL (FLOAT).

4.4.2 Generierung des Programmrumpfes

Eine Anzahl von Definitionen wird generiert, um SOM einschließlich der SOM-Umgebungsvariablen, der Variablen zur Behandlung von SOM-Ausnahmesituationen und Vorgaben für Return- Codes zu unterstützen.

Für jeden Parameter in jeder Methode wird eine Programmvariable der geeigneten Art erstellt. Diese Variablen werden später mit Werten aus den Feldern des Input-Containers gefüllt und dann zu der Methode übertragen. Nach dem Aufruf der Methode werden die Werte der Parameter in die richtigen Felder des Output- Containers kopiert. Fig. 6 zeit die Definition des Kontofeldes (account field) mit der Abhebungsmethode (withdraw method) der Konto-Klasse (account class).

Danach werden Zeiger auf die SOM-Ausnahmesituationen für diejenigen SOM-Ausnahmesituationen definiert, die keine Felder besitzen. Fig. 7 zeigt die Definition solch eines Zeigers für die Ausnahmesituation FehlAufruf (badCall) der Konto-Klasse (account class).

Ein vollständig anderer Abschnitt von Code muß für diejenigen Programmaktivitäten generiert werden, die als Methodenaufrufe für SOM-Objekte implementiert sind. Fig. 8 zeigt in einem Ablauf die auszuführenden Schritte, um den Code für jede dieser Aktivitäten zu generieren. Diese Schritte sind:
# Analysiere (einmal für das Programm) die Spezifikationen des Prozeßmodells, d. h. die FDL,
# Generiere (einmal für das Programm) die Programm- Kopfzeile,
# Generiere das Kopieren der Methodenparameter, die mit IN oder INOUT definiert sind, aus den Input- Containerfeldern, wie durch die Abbildungsregeln definiert,
# Generiere die SOM-Objekterstellung, wenn nicht schon generiert,
# Generiere den Methodenaufruf,
# Generiere das Management des Systems und der Benutzungs-Ausnahmesituationen der Methode gemäß den Abbildungsregeln,
# Generiere das Kopieren der Methodenparameter, die durch OUT oder INOUT definiert sind, in die Output-Containerfelder, wie durch die Abbildungsregeln definiert,
# Generiere das Löschen der Variablen der Methodenparameter

4.4.3 Einsetzen der Methodenparameter

In die Parameter, die als IN oder INOUT definiert sind, werden die Werte der Felder in dem Input-Container eingesetzt wie in den Abbildungsregeln definiert. Das Kopieren wird durchgeführt durch Ausführen der Methode ErstelleWert (CreateValue) mit den geeigneten Instanzen der Input-Containerfelder mit dem richtigen Methodenparameter als dem Ziel der Rückmeldewerte. Fig. 9 zeigt, wie das Feld KontoNr (accountNr) in dem Input-Container auf das Parameterfeld Konto (account) der SOM-Methode abgebildet wird. Diese Maßnahmen, die durch die Methode ErstelleWert (createValue) der Klasse DatenFeld (dataItem) ausgeführt werden, hängen von der Datenart des Parameters ab. Wenn der Parameter von der Art VARIABEL (FLOAT) oder LANG (LONG) ist, wird der Feldwert des Container-Datenfeldes in das Parameterfeld kopiert; wenn der Parameter von der Art ZEICHENKETTE (STRING) ist, wird ein Zeichenkettenfeld zugeordnet, der Wert wird auf die Zeichenkette kopiert und der Zeiger auf die Zeichenkette wird rückgemeldet und in dem Parameter gespeichert. Wenn kein entsprechendes Feld für einen Methodenparameter in dem Input- Container gefunden werden kann, wird der Parameter auf null gesetzt für VARIABEL (VARIABLE)- und LANG (LONG)-Felder und auf NULL (NULL) für ZEICHENKETTEN (STRING)-Felder.

4.4.4 Objekterstellung

Wenn bisher keine Instanz der SOM-Klasse mit dem definierten Objektbezeichner erstellt wurde, wird die richtige Instanz erstellt. Wenn OBJEKTID (OBJECTID) nicht angegeben wurde, wird die globale Identifizierung für die SOM Klasse benutzt. Fig. 10 zeigt das Erstellen eines SOM-Objektes für die Klasse Konto account.

4.4.5 Methodenaufruf

Das Aufrufen der Methode ist der normale Methodenaufruf zur SOM- Distanzresolution. Fig. 11 zeigt den Aufruf der Abhebungsmethode (withdraw method) gegenüber dem angegebenen SOM-Objekt der Konto (account)-Klasse.

4.4.6 Prüfen der Ausnahmesituation und des Return-Codes

Das Prüfen der Ausnahmesituationen der Methode beginnt mit dem Prüfen, welche Art von Ausnahmesituation, falls überhaupt eine, aufgetreten ist. Dies geschieht, wie das in Fig. 12 dargestellt ist, durch Prüfen des Hauptfeldes (major field) in der Umgebungsstruktur (environment structure), die durch SOM aufrechterhalten wird.

Zum Behandeln von Ausnahmesituationen des Systems wird der Teil des Codes, der in Fig. 13 dargestellt ist, generiert. In das RC-Feld wird der vom Benutzer definierte, vorgegebene Return- Code für eine Ausnahmesituation des Systems eingesetzt. Dann wird der Speicher, der durch SOM für das Behandeln von Ausnahmesituationen zugeordnet wurde, freigegeben.

Das Verarbeiten von Benutzungs-Ausnahmesituationen und ihre Abbildung auf das RC-Feld hängt von der Abbildung der Benutzungs-Ausnahmesituation auf den Return-Code ab. Fig. 14 zeigt den generierten Code, wenn die Abbildung aus einem Feld in der Ausnahmesituation auf den Return-Code erfolgt. Wenn die Ausnahmesituation FehlAufruf (badCall) rückgemeldet wird, wird das Feld Fehlercode (errorCode) der Ausnahmesituation FehlAufruf (badCall) ausfindig gemacht und sein Inhalt zu dem RC-Feld übertragen.

Wenn die Abbildung der Ausnahmesituation auf das RC-Feld als Abbildung auf eine Konstante angegeben wurde, wird der in Fig. 15 gezeigte Code generiert. Immer dann, wenn die Ausnahmesituation UngültigesKonto (invalidAccount) festgestellt wird, wird der Return-Code auf 30 gesetzt.

Wenn keine Abbildung der Ausnahmesituation angegeben wurde und die Ausnahmesituation keine Felder aufweist, wird der Return- Code auf einen systemweiten Vorgabewert gesetzt, wie das in Fig. 16 gezeigt ist.

Wenn keine Ausnahmesituation gefunden wird, wie das in Fig. 17 gezeigt ist, muß nur der durch SOM zugeteilte Speicher für das Behandeln der Ausnahmesituation freigegeben werden.

4.4.7 Füllen des Output-Containers

Nach dem erfolgreichen Verarbeiten werden die Werte aller Parameterfelder, die mit INOUT und OUT definiert wurden, in die richtigen Felder in dem Output-Container kopiert.

4.5 Das KONTO (ACCOUNT)-Beispiel

Zur Erläuterung der vorliegenden Erfindung wird ihre Lehre mit Hilfe eines Beispiels demonstriert. Das einfache KONTO (ACCOUNT)-Bei­ spiel erläutert das Verfahren durch das Überweisen von Geld von einem Bankkonto auf ein anderes. Der Prozeß wird begonnen durch das Eingeben des Kontos, von dem das Geld abgehoben wird, des Kontos, auf das das Geld überwiesen wird und des zu überweisenden Geldbetrages. Wenn das Konto, von dem das Geld abzuheben ist, nicht genügend Geldmittel enthält, wird ein Fehlerauszug gedruckt. Wenn die Überweisung erfolgreich ist, wird ein Auszug für beide Konten gedruckt. Dieser Prozeßablauf ist in Fig. 18 veranschaulicht.

Das Beispiel besteht aus den folgenden Elementen:
# dem Prozeßmodell für das KONTO (ACCOUNT)-Beispiel, das in der FlowMark-Definitionssprache (FDL) dargestellt ist einschließlich der Spezifikationen, die gemäß der Lehre der vorliegenden Erfindung generiert werden und die Verknüpfung zwischen der Prozeßumgebung und der Objektumgebung für das Prozeßmodell darstellen;
# den generierten Strukturen der SOM-Klasse als Implementierung des Prozeßmodells in der SOM- Objektumgebung, die gemäß der Lehre der vorliegenden Erfindung generiert werden;
# den Klassenerweiterungen der Klasse DatenFeld (dataItem), die den Prozeß des Kopierens der Werte der Felder der Container in die Parameter der Objektmethoden unterstützt;
# dem Code, der gemäß der Lehre der vorliegenden Erfindung generiert wird, der aus der FlowMark- Prozeßumgebung eine Objektmethode einer zugeordneten Klasse aufruft, die die Aktivität des Beispiels in der SOM-Objektumgebung implementiert. Diese Codefolge wandelt einen Aufruftext für das Aufrufen der zugeordneten Objektmethode um.

4.5.1 Prozeßdefinition in FDL

Fig. 19 stellt die Definitionen des Prozeßmodells für das KONTO (ACCOUNT)-Beispiel dar, das in der FlowMark-Definitionssprache (FDL) dargestellt ist, einschließlich der Spezifikationen, die gemäß der Lehre der vorliegenden Erfindung generiert werden und die Verknüpfung zwischen der Prozeßumgebung und der Objektumgebung für das Prozeßmodell darstellen. Besondere Aufmerksamkeit sollte geschenkt werden:
# der Anweisung KLASSENNAME′Konto′ (CLASSNAME ′account′), die eine Verknüpfung mit einer zugeordneten Objektklasse in der SOM-Objektumgebung herstellt,
# der Anweisung INPUTABBILDUNG (INPUTMAPPING), die eine Verknüpfung zwischen Containerfeldern und Parametern der zugeordneten Objektmethoden herstellt,
# der Anweisung BENUTZUNGSAUSNAHMESITUATION (USEREXCEPTION), die eine Verknüpfung zwischen einer Ausnahmesituation in der SOM-Objektumgebung und den Return-Codes innerhalb der Prozeßumgebung herstellt;
# den verschiedenen PROGRAMM AKTIVITÄTS (PROGRAM ACTIVITY)- Anweisungen, die eine Verknüpfung zwischen einem Prozeßmodell innerhalb der Prozeßumgebung und einer zugeordneten Objektklasse und ihrer das zugeordnete Objekt implementierenden Methode herstellt.

Zum Beispiel verknüpft PROGRAMM AKTIVITÄT′EinlageKonto′ (PROGRAM ACTIVITY′DepositAccount′) die Prozeßaktivität EinlageKonto (DepositAccount) mit der zugeordneten Objektmethode Einlage (deposit) der zugeordneten SOM- Klasse Konto (Account).

4.5.2 Die SOM Klasse′Konto′ (′Account′)

Fig. 20 zeigt die generierten SOM-Klassenstrukturen als Implementierung des Prozeßmodells der SOM-Objektumgebung, die gemäß der Lehre der vorliegenden Erfindung generiert wurden. Die SOM-Klasse, die gemäß der vorliegenden Lehre generiert wurde, ist die Klasse Konto(Account). Besondere Aufmerksamkeit sollte auch den generierten, zugeordneten Objektmethoden DruckeFehlerauszug (PrintErrorStatement), DruckeAuszug (PrintStatement), Zahle ein (deposit) und Hebe ab (withdraw) geschenkt werden. Die beiden Attribute sind in dem Implementierungsabschnitt definiert, so daß keine Hol (get)- und Setz (set)-Methoden erstellt werden.

4.5.3 Klassenerweiterungen

Fig. 21 spiegelt die Klassenerweiterungen der Klasse DatenFeld (dataItem) wider, die den Prozeß des Kopierens der Werte der Felder der Container auf die Parameter der Objektmethoden unterstützt. Diese Funktion wird erreicht durch die Methode ErstelleWert (CreateValue).

Die Methodenparameter werden als Programmvariablen zugeteilt. Die neue Methode ErstelleWert (CreateValue) für die DatenFeld (dataItem)-Klassen wird benutzt, um den Wert einer DatenFeld (dataItem)-Instanz in einen Parameter zu kopieren. Wenn die DatenFeld (dataItem)-Instanz keinen Wert hat, wird einer ZEICHENKETTEN (STRING)-Variablen der Wert NULL (NULL), null einer VARIABEL (FLOAT)- oder LANG (LONG)-Variablen zugeordnet.

4.5.4 Generierter Aufruftext

Fig. 22 veranschaulicht den gemäß der Lehre der vorliegenden Erfindung generierten Code, der aus der FlowMark-Prozeßumgebung eine zugeordnete Objektmethode einer zugeordneten Klasse aufruft, die die Aktivität des Beispiels in der SOM- Objektumgebung implementiert. Diese Codefolge wandelt einen Aufruftext für den Aufruf der zugeordneten Objektmethode um. Fig. 22 zeigt den für die Aktivität AbhebungKonto (withdrawAccount) des Prozeßmodells generierten Code.

Im Hinblick auf Fig. 22 sollte den folgenden Merkmalen Aufmerksamkeit geschenkt werden:
# Die Anweisungen {01} bis {04} fügen für das Betriebssystem und die Bibliothek spezifische Kopfzeilendateien ein.
# Anweisung {05} fügt die Kopfzeilendatei für die Kontoklasse ein.
# Die Anweisungen {06} und {07} fügen die Kopfzeilendateien für die Aktivitäts- und die Datenfeldklasse ein
# die Anweisung {11} definiert einen Zeiger auf die SOM Umgebungsstruktur, die erhalten wird durch Aufrufen somHoleGlobaleUmgebung (somGetGlobalEnvironment).
# Die Anweisung {12} definiert einen Zeiger auf den Bezeichner der SOM-Ausnahmesituation.
# Die Anweisungen {13}, {14} und {15} definieren Konstanten, die benutzt werden, um das Feld_RC für den Return-Code der Aktivität zu setzen.
# Die Anweisungen {15} bis {21} erklären die Programmvariablen, die als Methodenparameter benutzt werden. Eine Variable wird jedem Parameter in jeder Methode zugeordnet. Die Zuordnung von Werten wird über die Methode ErstelleWert (CreateValue) der Datenfeld (dataItem)-Klassen durchgeführt.
# Die Anweisung {22} ist die Vereinbarung für die definierte SOM-Ausnahmesituation FehlAufruf (badcall).
# Die Anweisungen {33} und {34} kopieren die Werte der entsprechenden Felder des Input-Containers auf die Programmvariablen für die Methodenparameter.
# Die Anweisung {35} erstellt das Objekt, wenn das Objekt nicht früher erstellt wurde. Da kein Objektbezeichner für die Programmaktivität angegeben wurde, wird der prozeßweite, globale Objektbezeichner für die SOM-Klasse benutzt.
# Die Anweisung {36} ist der Aufruf der Methode gegenüber dem SOM-Objekt.
# Die Anweisung {37} prüft die Art der Ausnahmesituation, die durch die Methode rückgemeldet wurde. Sie wird in dem Hauptfeld (major field) der Umgebungsstruktur gefunden.
# Die Anweisung {38} ist wahr, wenn der Return-Code eine Ausnahmesituation des Systems angibt, wie das in dem SOM-Benutzerhandbuch dokumentiert ist.
# In diesem Fall setzt die Anweisung {39} den Return-Code auf die durch den Benutzer angegebene Vorgabe für eine Ausnahmesituation des Systems, die Anweisung {40} gibt den Puffer frei, der durch SOM für das Übertragen des Fehlers zugeordnet ist, und die Anweisung {41} erzwingt das Ende der Umschaltanweisung.
# Die Anweisung {42} ist wahr, wenn der Return-Code eine Benutzungs-Ausnahmesituation angibt, d. h. eine Ausnahmesituation, die durch den Definierer der Klasse definiert wurde. In diesem Fall müssen Prüfungen durchgeführt werden, um zu prüfen, welche Bedingungen ausgelöst wurden.
# Die Anweisung {43} adressiert den Bezeichner für eine SOM- Ausnahmesituation.
# Die Anweisung {44} bestimmt, ob der Bezeichner der Ausnahmesituation gleich dem definierten ist, der FehlAufruf (badCall) ist.
# Falls wahr, adressiert die Anweisung {45} die Struktur, die durch die Ausnahmesituation definiert ist.
# Die Anweisung {46} kopiert dann den Wert des Feldes, das als das festgestellt wurde, das den Return-Code enthält, auf die Return-Code-Variable.
# Die Anweisung {47} gibt den Puffer frei, der für das Rückmelden der Fehlerinformation zugeordnet wurde, und die Anweisung {48} beendet die Fehlerverarbeitung.
# Die Anweisung {50} bestimmt, ob die Ausnahmesituation UnzureichendesKapital (insufficientFunds) rückgemeldet wurde.
# Da die Ausnahmesituation weder ein Feld enthält noch eine Abbildung dafür angegeben wurde, setzt die Anweisung {51} den Return-Code auf die vom Benutzer definierte Vorgabe des Return-Codes für eine Benutzungs- Ausnahmesituation.
# Die Anweisung {54} bestimmt, ob die Ausnahmesituation ungültiges Konto (invalidAccount) rückgemeldet wurde. In diesem Fall setzt, da eine Abbildung für die Ausnahmesituation definiert wurde, die Anweisung {55} den Return-Code auf den angegebenen Wert.
# Die Anweisung {58} ist wahr, wenn der Methodenaufruf ohne irgendeinen Fehler ausgeführt wurde. In diesem Falle setzt die Anweisung {59} den RC auf null, und die Anweisung {60} beendet die Fehlerverarbeitung.
# Die Anweisungen {61} und {62} löschen die Programmvariablen. Variablen von der Art Zeichenkette (STRING) werden gelöscht, Variablen von der Art VARIABEL (FLOAT) und LANG (LONG) werden auf null gesetzt.

5 Akronyme

CORBA Common Object Request Broker Architecture (Allgemeine Architektur zum Vermitteln von Objektanforderungen)
FDL FlowMark Definition Language (FlowMark-Definitionssprache)
IDL Interface Definition Language (Schnittstellen-Definitionssprache)
OMA Object Management Architecture (Objektmanagement-Architektur)
OMG Object Management Group (Objektmanagement-Gruppe)
SOM System Object Model (System-Objekt-Modell)

Claims (8)

1. Verfahren zum Erweitern der Spezifikationen eines Prozeßmodells innerhalb einer Workflow-Prozeßumgebung, bei dem das Prozeßmodell eine Prozeßaktivität definiert, die von mindestens einem Computersystem verwaltet und ausgeführt wird,
wobei das Verfahren des Erweiterns das Prozeßmodell mit einer Objektumgebung verbindet, innerhalb derer die Prozeßaktivität zu implementieren ist,
und das Verfahren des Erweiterns einen Registrierungsschritt einer Objektklasse umfaßt, der das Prozeßmodell mit mindestens einer zugeordneten Objektklasse verknüpft, die innerhalb der Objektumgebung residiert, und die zugeordnete Objektklasse eine Prozeßaktivität implementiert und der Registrierungsschritt der Objektklasse die Verknüpfung als Spezifikation einer zugeordneten Objektklassen in dem Prozeßmodell speichert,
wobei das Verfahren des Erweiterns einen Registrierungsschritt einer Objektmethode umfaßt, der das Prozeßmodell mit zumindest einer zugeordneten Objektmethode verknüpft, die eine Methode der zugeordneten Objektklasse ist und innerhalb der Objektumgebung residiert, und die zugeordnete Objektmethode die Prozeßaktivität implementiert und der Registrierungsschritt der Objektmethode die Verknüpfung als Spezifikation der zugeordneten Objektmethode in dem Prozeßmodell speichert.

2. Verfahren des Erweiterns gemäß Anspruch 1, bei dem das Prozeßmodell mindestens einen Input-Container und/oder mindestens einen Output-Container aufweist,
wobei das Verfahren des Erweiterns einen optionalen Verknüpfungsschritt des Input-Containers umfaßt, der mindestens ein Feld des Input-Containers mit einem Input­ parameter der zugeordneten Objektmethode verknüpft und die Verknüpfung als Spezifikation der Input-Container- Verknüpfung in dem Prozeßmodell speichert,
und das Verfahren des Erweiterns einen optionalen Verknüpfungsschritt des Output-Containers umfaßt, der mindestens ein Feld des Output-Containers mit einem Output­ parameter der zugeordneten Objektmethode verknüpft und die Verknüpfung als Spezifikation der Output-Container- Verknüpfung in dem Prozeßmodell speichert.

3. Verfahren des Erweiterns gemäß Anspruch 1 oder 2, wobei das Verfahren einen Verknüpfungsschritt für Ausnahmesituationen umfaßt, der mindestens eine Ausnahmesituation, die von der zugeordneten Objektmethode innerhalb der Objektumgebung signalisiert werden kann, mit einem Return-Code-Feld des Prozeßmodells verknüpft und die Verknüpfung als eine Spezifikation der Verknüpfung von Ausnahmesituationen in dem Prozeßmodell speichert.

4. Verfahren des Erweiterns gemäß Anspruch 3,
bei dem der Verknüpfungsschritt der Ausnahmesituation sich entweder auf eine Ausnahmesituations-Variable bezieht, die die Ausnahmesituation in dem Return-Code-Feld speichert, oder
bei dem der Verknüpfungsschritt der Ausnahmesituation einen Wert der Ausnahmesituation mit dem Return-Code-Feld verknüpft.

5. Verfahren zur elektronischen Datenverarbeitung, das automatisch eine Implementierung eines Prozeßmodells generiert, das durch mindestens ein Computersystem verwaltet und ausgeführt wird, wobei das Verfahren des Generierens Spezifikationen eines Prozeßmodells benutzt, das in einer Workflow-Prozeßumgebung residiert, und das Verfahren die Implementierung des Prozeßmodells als Objektstrukturen generiert, die in einer Objektumgebung residieren,
wobei das Verfahren des Generierens einen Analyseschritt zum Analysieren der Spezifikationen des Prozeßmodells umfaßt,
und das Verfahren des Generierens einen Generierungsschritt einer zugeordneten Klasse zum Generieren einer zugeordneten Objektklasse als implementierender Klasse innerhalb der Objektumgebung umfaßt, wenn eine Spezifikation der zugeordneten Objektklasse durch den Analyseschritt festgestellt wurde und wenn die zugeordnete Objektklasse noch nicht generiert wurde,
und das Verfahren des Generierens einen Schritt des Generierens einer zugeordneten Objektmethode zum Generieren einer zugeordneten Objektmethode als einer implementierenden Objektmethode der zugeordneten Objektklasse umfaßt, wenn eine Spezifikation einer zugeordneten Objektmethode durch den Analyseschritt festgestellt wurde und wenn die zugeordnete Objektmethode noch nicht generiert wurde,
wobei das Verfahren des Generierens den Schritt eines Implementierungsaufrufs zum Generieren eines Aufruftextes umfaßt, um aus der Prozeßumgebung die zugeordnete Objektmethode aufzurufen und die zugeordnete Objektmethode innerhalb der Objektumgebung zu aktivieren.

6. Verfahren zum Generieren gemäß Anspruch 5, wobei das Verfahren zum Generieren den Schritt des Generierens einer Input-Variablen umfaßt, der, wenn eine Spezifikation für eine Verknüpfung mit dem Input-Container und/oder eine Spezifikation einer Verknüpfung mit dem Output-Container in dem Analyseschritt festgestellt wurde, eine Input-Variable für jeden Input-Parameter und/oder eine Output-Variable für jeden Output-Parameter generiert.

7. Verfahren zum Generieren gemäß Anspruch 6,
bei dem der Schritt zum Implementierungsaufruf, wenn eine Spezifikation zum Verknüpfen des Input-Containers in dem Analyseschritt festgestellt wurde, das Generieren einer Installationsfolge für Input-Parameter innerhalb des Aufruftextes einschließt, die die Werte des Input- Containerfeldes den Input-Variablen zuschreibt wie in der Spezifikation der Verknüpfung für den Input-Container definiert,
bei dem der Schritt zum Implementierungsaufruf, wenn eine Spezifikation der zugeordneten Objektklasse in dem Analyseschritt festgestellt wurde, das Generieren einer Objektinstanziierungsfolge in dem Aufruftext einschließt, und die Objektinstanziierungsfolge eine zugeordnete Objektinstanz der zugeordneten Objektklasse instanziiert, wenn die zugeordnete Objektinstanz noch nicht instanziiert wurde,
bei dem der Schritt zum Implementierungsaufruf das Generieren einer Folge zum Aufruf der zugeordneten Objektmethode in dem Aufruftext einschließt, und die Aufruffolge für die zugeordnete Objektmethode die zugeordnete Objektmethode mit den Input- und Output- Variablen aufruft,
bei dem der Schritt zum Implementierungsaufruf das Generieren einer Folge zur Behandlung der Ausnahmesituation innerhalb des Aufruftextes aufruft, wobei die Folge zur Aufrufbehandlung prüft, ob die zugeordnete Objektmethode eine Ausnahmesituation auslöste,
wenn die Ausnahmesituation identifizierbar ist und wenn eine Spezifikation einer Ausnahmesituation durch den Analyseschritt festgestellt wurde, das Schreiben der Ausnahmesituation in ein Return-Code-Feld des Prozeßmodells,
wenn die Ausnahmesituation nicht identifizierbar ist, das Schreiben eines Return-Codes einer Standard- Ausnahmesituation des Systems in das Return-Code-Feld des Prozeßmodells,
wobei der Schritt des Implementierungsaufrufes, wenn eine Spezifikation einer Verknüpfung des Output-Containers durch den Analyseschritt festgestellt wurde, das Generieren einer Folge zum Installieren der Output-Parameter innerhalb des Aufruftextes einschließt, und die Installierungsfolge für die Output-Parameter das Schreiben von Werten der Output- Variablen in die Felder des Output-Containers einschließt wie in der Spezifikation der Verknüpfen des Output- Containers definiert.

8. Verfahren des Generierens gemäß Anspruch 7, bei dem der Schritt des Implementierungsaufrufs das Generieren einer Folge zum Löschen der I-/O-Variablen innerhalb des Aufruftextes einschließt, wobei die Folge zum Löschen der I-/O-Variablen die Input- und/oder Output- Variablen löscht.