GB2466344A - Method for automatic workflow graph refactoring and completion - Google Patents

Abstract

Methods, systems and programs for refactoring a directed workflow graph are disclosed. A workflow graph containing at least one start node s, and at least one end node t, with a multitude of nodes x residing between s and t on a directed path is first completed into a two terminal graph with a single start node and end node (if necessary) and then decomposed into a set of canonical R-fragments (A-I). The workflow graph is then expanded by splitting (X1' X1" X2' X2") shared nodes (X1, X2) between R-fragments (D, E). An R-fragment is a connected subgraph such that an R fragment has exactly two boundary nodes. A boundary node (X1, X2) of an R Fragment is a node of the fragment that has at least two edges incident to this node, one of which belongs to the fragment, while the other does not. Tests of a directed graph with multiple end nodes or of its expanded form or of R-fragments are generated and IOR joins are substituted with AND or XOR joins.

Description

METHOD AND SYSTEM FOR AUTOMATIC WORKFLOW GRAPH

REFACTORING AND COMPLETION

FIELD OF THE INVENTION

The invention relates generally to techniques for modeling business processes in terms of workflow graphs. Specifically, the invention provides methods for completing and for refactoring workflow graphs which yield unique results and thus can be automated.

BACKGROUND OF THE INVENTION

Workflow graphs are a commonly known and used method to model the control flow of business processes. There are various standardized graphical notations, such as BPMN (Business Process Modeling Notation), EPC (Event-driven Process Chain) diagrams or UML (Unified Modelling Language) activity diagrams geared at drawing business processes in terms of a directed workflow graph.

A workflow graph depicts the control flow of a business process as a directed graph. it is well known, however, that a workflow graph is a non-unique representation of a given business process in the sense that different workflow graphs can model the same behavior, i.e. the same control flow. Moreover, graph based representations such as BPMN do not contain any means for verifying whether the business model is in fact executable.

Thus, as a BPMN model is transformed into an execution language, such as BPEL (Business process Execution Language), problems may arise since the workflow graph may be found to be non-

executable.

Aside from the requirement that the workflow graph be valid in the sense that it can be translated into an executable program, the workflow graph should also have an easily comprehensible form, because workflow graphs are generally used for communicating business processes among different stakeholders of the business process, and not only among modeling experts. Thus, it is important for the workflow graph to have a clear structure, since this facilitates accessibility for users who may not be experienced in business process modeling.

It is generally known that the readability and understandability of a workflow graph can be enhanced by making the workflow graph well-structured. By definition, a workflow graph is well-structured if it consists of matching pairs of nodes that split the flow and nodes that join the flow. Each split node is associated with exactly one join node and vice versa, and each path in the workflow graph originating in a split node leads to its corresponding join node. Well-structured workflow graphs are generally preferred because -next to being easy to comprehend and analyze -they can be represented by a regular expression.

There are various known methods of transforming a general workflow graph into a well-structured workflow graph using local transformation rules that preserve the execution semantics.

Examples of such a transformation method are described in wTransforming Workflow Graphs" by J. Eder, W. Gruber and H. Pichler, ITEROP-ESA 2005, pages 203-214 (2005) as well as in "Analyzing Process Models Using Graph Reduction Techniques" by W. Sadiq and M.E. Orlowska, Inf. Syst. 25(2), pages 117-134 (2000) . While these methods yield well-structured workflow graphs, they are problematic in that they generally do not lead to a unique result but yield somewhat arbitrary solutions depending on the specific way the original workflow graph is drawn out. Thus, since the rules presented in these presentations yield ambiguous solution, it is not clear how to apply the rule to obtain a well-structured workflow graph automatically.

In order to transform a general workflow graph into a well-structured workflow graph, it is mandatory that the general workflow graph be a two-terminal graph having a unique start node (source) and a unique end node (sink) . Thus, if the general workflow graph has multiple end nodes, it is necessary to complete this workflow graph in such a way that the multiple end nodes are reduced to a single end node. This completion should be accomplished automatically and should yield a completed workflow graph with good execution properties.

SUMMARY OF THE INVENTION

It is an object of the invention to provide a method of transforming a general workflow graph into a form that makes its structure explicit and thus makes it easier to read and to understand, especially for an unexperienced user.

It is a further object of the invention to provide a method for transforming a general workflow graph into a well-structured workflow graph in such a way that the result is unambiguous, thus enabling an automatic execution of the method.

Furthermore, it is an object of the invention to provide a method for refactoring a general workflow graph in such a way that the resulting workflow graph is easily executable.

It is a yet further object of the invention to provide a method for completing a workflow graph with multiple end nodes in such a way that the completed workflow graph has only one (unique) end node.

Furthermore, it is an object of the invention to provide a method for completing a workflow graph with multiple end nodes in such a way that the resulting workflow graph allows correct and efficient execution.

These objects are achieved by the features of the independent claims. The other claims and the specification disclose advantageous embodiments of the invention.

According to a first aspect of the invention, a refactoring method of transforming a directed two-terminal graph Go with into a so-called expanded normal form G* of Go is provided. The method comprises the steps of (1) decomposing the two-terminal workflow graph comprising a multitude of nodes into a set of canonical R-fragments and (2) expanding the two-terminal workflow graph by splitting shared nodes between canonical R-fragments. In this context, an R-fragment F is defined as a connected subgraph of two-terminal workflow graph such that F has exactly two boundary nodes, an entry and an exit; an R-fragment F is called canonical if does not overlap with any other R-fragments F' of the workflow graph Go. By splitting nodes, complex nodes within the workflow graph Go, (i.e. nodes with more than three edges incident on this node) are resolved into plural nodes, thus making the structure of workflow graph Go more transparent and more well-structured.

According to a second aspect of the invention, a method of completing a directed graph G with multiple start nodes and/or multiple end nodes into an expanded normal form G* of G is provided. The method comprises the steps of (1) completing the graph G into a two-terminal workflow graph Go containing a multitude of nodes, but only a single start node and a single end node, (2) decomposing the two-terminal workflow graph Go into a set of canonical R-fragments and (3) expanding the two-terminal workflow graph by splitting shared nodes between canonical R-fragments. In a preferred embodiment, during the completion step an IOR-join is introduced which connects all end nodes of G to a unique new end node, and during the refactoring step this ICR-join is resolved into a multitude of ICR-joins which, in an additional step, are replaced by AND-joins or XCR-joins whenever applicable.

According to a third aspect of the invention, a method of completing a directed graph G with multiple end nodes into a two-terminal graph Go is provided. The method comprises the steps of (1) determining potential final states of the graph G, (2) computing so-called tests of graph G, wherein a test is defined as a set of end nodes such that each pair of end nodes is mutually exclusive and such that each final state has exactly one end node in the test, (3) creating an XCR-join for each test of the graph G and connecting all end nodes belonging to a given test to the respective XOR-join, (4) creating one final AND-join and one final end node and (5) connecting the XOR-joins to the final AND-join and connecting the final AND-join to the final end node.

According to a fourth aspect of the invention, a method of completing a directed graph containing multiple end nodes is provided, the method comprising the steps of (1) completing the graph G into a two-terminal workflow graph G0 containing a mu]titude of nodes, but on]y a sing]e start node and a sing]e end node, (2) decomposing this two-terminal graph G0 into a set of canonical R-fragments, (3) expanding the two-terminal workflow graph G0 by splitting shared nodes between R-fragments F containing the single end node, (4) replacing ICR-joins with AND-joins and XOR-joins where possible, (5) computing so-called tests for R-fragments that have an ICR-join as the exit node, a test being defined as a set of end nodes such that each pair of end nodes is mutually exclusive and such that each final state has exactly one end node in the test and. (6) implementing a completion with XOR-joins and AND-joins based on the tests. -Note that the computation of the tests (step (5)) can be made locally for each fragment, that is, the nodes and edges of other fragments can be abstracted away. Step (6) is done locally as well, and the results are merged back to the rest of the graph.

According to a fifth aspect of the invention, a computer system for refactoring a directed two-terminal graph Go is provided. The system comprises (1) a Graph Decomposition System for decomposing the two-terminal graph Go into a set of canonical R-fragments and (2) a Fragment Expansion System for expanding the two-terminal workflow graph (Go) by splitting shared nodes between R-fragments.

According to a sixth aspect of the invention, a computer system for completing a directed graph G containing multiple end nodes is provided. The system comprises (1) a Test Generating System for calculating tests of the two-terminal graph Go or of its expanded normal form G* or of R-fragments F thereof and (2) an AND-/XOR-Completion System for substituting IOR-joins of the two-terminal graph Go or of its expanded normal form G* or of R-fragments F. According to a seventh aspect of the invention, a computer system for completing a directed graph G containing multiple end nodes is provided. The system comprises (1) a Simple (IOR) Completion system for converting graph G into a two-terminal graph Go), (2) a Graph Decomposition System for decomposing the two-terminal graph into a set of canonical R-fragments, (3) a Fragment Expansion System for expanding the two-terminal workflow graph by splitting shared nodes between R-fragments F, and (4) an IOR Replacement System for replacing IOR-joins by XOR-or AND-joins according to predefined rules wherever applicable.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention together with the above-mentioned and other objects and advantages may best be understood from the following detailed description of the embodiments, but not restricted to the embodiments, wherein is shown in: FIG. la-id schematic diagrams of a workflow graph as it is subjected to a preferred embodiment of a refactoring method according to the invention: FIG. la a diagram of a two-terminal workflow graph; FIG. lb a decomposition of the two-terminal workflow graph of FIG. la in terms of canonical R-fragments; FIG. ic an expansion of the two-terminal workflow graph of FIG. lb in terms of canonical R-fragment F; FIG. id a diagram of the normal expanded form of the two-terminal workflow graph of FIG. la; FIG. 2 the refined process tree structure tree (RPTS) of the two-terminal workflow graph of FIG. ib; FIG. 3 a workflow graph with a subqraph which is not an R-fragment the workflow graph; FIG. 4a-4c examples of valid expansions of a workflow graph; FIG. 4d an example of an invalid expansion of a workflow graph; FIG. 4e-4f examples of redundant expansions of a workflow graph; FIG. 5a-5d schematic diagrams of a workflow graph as it is subjected to a preferred embodiment of a completion method ("Fast Completion Technique") according to the invention: FIG. 5a a directed graph G with multiple end nodes; FIG. 5b a simple ICR-completion of the graph of FIG. 5a; FIG. 5c a resolution of the final ICR-join of the graph of FIG. 5b in terms of multiple ICR-joins; FIG. 5d the graph of FIG. 5c after substitution of ICR-joins by AND-and XOR-joins; FIG. 6a-6d schematic diagrams of a workflow graph as it is subjected to a preferred embodiment of a completion method ("General Completion Technique") according to the invention: FIG. 6a a directed graph with multiple end nodes; FIG. 6b the graph of FIG. 6a after implementing General Completion; FIG. 6c a different directed graph with multiple end nodes; FIG. 6d a (non-local) completion of the graph of FIG. 6c; FIG. 7a-7f schematic diagrams of a workflow graph as it is subjected to a preferred embodiment of a completion method ("Hybrid Completion Technique") according to the invention: FIG. 7a a directed graph with multiple end nodes; FIG. 7b a simple IOR-completion of the graph of FIG. 7a; FIG. 7c a decomposition of the two-terminal graph of FIG. 7b in terms of canonical R-fragments; FIG. 7d an expansion of the two-terminal workflow graph of FIG. 7c in terms of terminal R-fragments; FIG. 7e the graph of FIG. 7d after substitution of IOR-joins by AND-and XOR-joins; FIG. 7f the graph of FIG. 7e after implementing the "Fast Comp]etion Method" on R-fragment FR; FIG. 8 a graph obtained by applying the "General Completion Technique" to the graph of FIG. 7a; FIG. 9 a schematic flow diagram of a refactoring method 100 for calculating an expanded normal form of a two-terminal graph; FIG. 10 a detailed flow diagram of a preferred embodiment of the expansion step 120 of the method of FIG. 9; FIG. 11 a schematic flow diagram of a preferred embodiment of a method ("Fast Completion Technique") for completing a directed graph with multiple end nodes; FIG. 12 a schematic flow diagram of a preferred embodiment of an alternate method ("General Completion Technique") for completing a directed graph G with multiple ends; FIG. 13 a detailed flow diagram of the AND-/XOR-completion implementation step 230 of FIG. 12; FIG. 14 a schematic flow diagram of yet another method ("Hybrid Completion Technique") for completing a directed graph with multiple ends; FIG. 15 a computer system implementation of a method for refactoring a directed graph; and FIG. 16 a computer system implementation of a method for completing a directed graph with multiple end nodes; FIG. 17 a computer system implementation of an alternate method for completing a directed graph with multiple end nodes.

In the drawings, like elements are referred to with equal reference numerals. The drawings are merely schematic representations, not intended to portray specific parameters of the invention. Moreover, the drawings are intended to depict only typical embodiments of the invention and therefore should not be considered as limiting the scope of the invention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. la shows an example of a workflow graph 11 expressed in terms of BPMN (Business Process Modeling Notation) . BPMN is a commonly known and used method for depicting the control flow of a business process as a directed graph using standard graphical elements. The workflow graph 11 contains flow objects (nodes x) such as events (denoted by circles), activities (denoted by rectangles) and gateways (denoted by diamonds) . Graph 11 is a directed graph in the sense that it contains a directed set of edges e (denoted by arrows) connecting the nodes x. There is one start node s and one end node t in workflow graph 11, the start node s having exactly one outgoing edge and the end node t having exactly one incoming edge. Each node x of workflow graph 11 is on a path from the start node s to end node t. Workflow graph 11 of FIG. la is complete in the sense that it is a two-terminal graph having a single entry (start node s) and a single exit (end node t) Workflow graph 11 comprises gateways which are defined as nodes x having more than one incoming edge or more than one outgoing edge and carrying a logic; they correspond to decisions, forking, merging and joining of paths. Using BPMN notation, gateways are generally denoted by diamonds. XOR gateways are identified by blank diamonds (such as the nodes xl, x2, x3 and in x4 FIG. la), AND gateways are identified by diamonds carrying a "+" sign (such as the node v in FIG. 5a) Besides XOR and AND gateways, workflow graphs may also contain gateways with inclusive OR (IOR) logic. An IOR gateway has non-local join behavior which is difficult to define if the (sub-) graph containing the IOR-join also contains a cycle; the semantics for the IOR-join is not settled in that case. Thus, for the purpose of the following description, while workflow graphs will be allowed to contain IOR gateways, regions of the workflow graph with IOR-joins contained in a cycle will be excluded from consideration.

A workflow graph is called well-structured if it consists of matching pairs of nodes that split the flow and nodes that join the flow. In this sense, workflow graph 11 of FIG. la is not well-structured: for example, gateway xl splits the flow threefold, and there is no unique join node associated with gateway xl such that each path in workflow graph 11 originating from split node xl leads to this corresponding join node.

Refactoring Method In order to make a two-terminal workflow graph 11 such as the one shown in FIG. la well-structured, a refactoring method 100 is suggested the schematic flow diagram of which is depicted in FIG. 9. This refactoring method 100 calculates a so-called normal form G* of a two-terminal graph Go (such as graph 11 of FIG. la) that makes the structure of Go more explicit. The refactoring method 100 furnishes a unique result and can therefore be automatized. As will become evident in the following description, refactoring method 100 is a local method in the sense that it decomposes workflow graph G0 into a hierarchy of subgraphs (so-called canonical R-fragments) and refactors these subgraphs. There are instances of workflow graph Go which cannot be transformed into a fully well-structured form using method 100 since this would require a non-local transformation. There are also workflow graphs that cannot be expressed as a well-structured workflow graph; understandably, these also cannot be transformed into a well structured form using method 100. However, in any case the (local) refactoring method 100 of FIG. 9 will yield a normal form G* of Go which is "more well-structured" than the original workflow graph Go.

The method 100 comprises a decomposition step 110 in which the workflow graph G0 is decomposed into logically atomic parts called canonical R-fragments, followed by a refactoring step 120 in which R-fragments are expanded by splitting entry and/or exit nodes or the R-fragments.

Method 100 begins with a directed two-terminal workflow graph Go.

In decomposition step 110, this two-terminal workflow graph Go is decomposed into a hierarchy of subgraphs, so-called canonical R-fragments F. An R-fragment F is defined as a connected subgraph of workflow graph Go such that it has exactly two boundary nodes, an entry and an exit. By definition, a node of a connected subgraph Gs of a workflow graph Go is called a boundary node if it is either the start node or the end node of G or if there are at least two edges incident to this node, one of which belongs to G while the other does not belong to G5. A boundary node is called an entry of R-fragment F if no incoming edge of this node is in F or if all outgoing edges of this node are in F. A boundary node is an exit of R-fragment F if all incoming edges of this node are in F or no outgoing edge of this node is in F. An R-fragment F is called canonical if it does not overlap with any other R-fragment F' of workflow graph Go. As a consequence of this definition, canonical R-fragments do not overlap with each other and hence form a hierarchy which can be represented by a tree structure called the refined process structure tree (RPST) of G0.

FIG. lb depicts a decomposition of the workflow graph 11 of FIG. la in terms of canonical R-fragments FA... Fi which are indicated by dotted boxes A... I in FIG. lb. Each of these fragments FA... Fj contains all edges which are either inside the respective box or cross the boundary of the box. Thus, the box marked D symbolizes an R-fragment FD containing the set of edges {(xl,al), (al,x2), (xl,a2), (a2,x2)}. Node xl is the entry and node x2 is the exit of R-fragment FD. The box marked E denotes an R-fragment FE with the set of edges {(x2,a4), (a4,x3), (x3,x2)} and with entry x2 and exit x3.

The tree structure (RPST) representing the hierarchy of the canonical R-fragments fragments FA... Fi of graph 11 is depicted in FIG. 2. These R-fragments FA.. . Fj form components of this tree and are connected to each other by so-called virtual edges.

Each original edge (xl,al), (xl,a2), etc. is shown in the tree underneath the unique R-fragment that contains that edge.

Therefore, each R-fragment determines a set of edges of the original graph, namely all the leaves of the subtree that this R-fragment corresponds to. Note that each leaf node of the RPST as shown in FIG. 2 represents an edge of the workflow graph, as each edge forms an R-fragment. The boundary nodes of this R-fragment are the two nodes that this edge connects. The largest fragment (fragment Fj) that contains the whole workflow graph 11 is the root fragment of the RPST. The child fragments of each fragment F are arranged underneath that (parent) fragment. For example, root fragment F1 has the child fragments (s,xl), FH and (x4,t) While the subgraphs indicated by dotted boxes A... I in FIG. lb correspond to R-fragments, FIG. 3 shows an example of a workflow graph 21 with a subgraph SG (indicated by a box S) which is not an R-fragment: SG contains a set of edges {(x5,a7), (a7,x6), (xG,x5)} and has two boundary nodes, x5 and x6. However, neither x5 nor x6 is an entry or an exit of SG since x5 contains an outgoing edge (x5,a6) which is not in SG and x6 contains an incoming edge (a6,x6) which is not in SG); since SG contains neither entry nor exit, SG is not an R-fragment.

The decomposition of a workflow graph Go in terms of canonical R-fragments is unique as well as modular in the sense that a local modification of the workflow graph Go will only cause a local modification of the decomposition (and thus only a local modification of the RPST) . A method for calculating the RPST in linear time, yielding a highly detailed decomposition, is disclosed in "The refined process structure tree" by J. Vanhatalo, H. Voelzer and J. Koehier, BPM 2008, volume 5240 of LNCS, pages 100 -115, Springer, Heidelberg, 2008. The contents of this publication are incorporated herein by reference.

Based on the decomposition of workflow graph Go in terms of canonical R-fragments as computed in step 110, the workflow graph Go is expanded in terms of its R-fragments in step 120. The expansion generates a so-called normal form of the workflow graph which maintains the workflow graph's structure given by the RPST but shows it more explicitly in the form of so-called normal R-fragments. By definition, a canonical R-fragment F is called normal if exactly one edge outside F is incident to the entry of F and exactly one edge outside F is incident to the exit of F. Analogously, a workflow graph G* is called normal if every proper canonical R-fragment F of G* is normal. An R-fragment F is called proper if F is not a trivial R-fragment (i.e. having a single edge), or a sequence (i.e. a union of two R-fragments such that the exit node of the first R-fragment is the entry node of the second R-fragment.

Non-normal R-fragments F17 are transformed into normal R-fragments by splitting the entry and/or the exit node of this non-normal R-fragment The node is split by replacing it by two identical copies of the original node and connecting the copies to neighboring nodes in such a way that the number of edges incident on each copy is less than the number of edges incident on the original node while maintaining the execution semantics of the original node. FIG. 4a -4c show three examples of valid expansions (G1,G�+) that split a node u into two nodes v and w in such a way that it preserves the execution semantics of the original workflow graph G1. FIG. 4a shows the splitting of a node u into a join and a split. FIG. 4b and 4c show splittings that separate different inputs and outputs of the node u respectively. Note that a splitting of the kind shown in FIG. 4d is invalid since the simultaneous separation of inputs and outputs does not preserve execution semantics (as the original path from b to c is lost) . All possible (i.e. valid) ways of splitting a node u into two nodes v and w obey the rules shown in Table 1 which defines a valid expansion of a workflow graph G1 into a new workflow graph G1+.

If (GI,GIil) is a valid expansion that splits a node u into two nodes v and w, it can be shown that if the logic of u is AND or XOR, then G1 and G1+ have the same behavior. Likewise, the behavior remains unchanged if the logic of u is ICR and u is not in a cycle. Thus, for all workflow graphs (or regions of workflow graphs) considered in the framework of this disclosure, a valid expansion will preserve the semantics of the workflow graph.

Definition of a valid expansion (G�,G�+) of two workflow graphs: Let G1 = (V1, E1, 1) and G1+ = (V1, E1+, be two (generalized) workflow graphs. The pair (G�,G1+) is a valid expansion if there exists two nodes v,w e V1 and a surjective mapping:V1+1 -> V1 such that -(v, w) e Elil (w, v) Elil; -( (v,x) a E11 and (y, w) a E11) ( (x = w) or (y = v)) -((x) = (y)) ((x = y) or {x,y} = {v,w}); -( (x) , (y) a E1 ((x, y) a E1+1 and (x, y) != (v, w)) -11((x)) = l1+1(x) (i.e. the logic of the expanded node remains unchanged)

Table 1

Note that there exist expansions which -while being valid -do not split gateways but create redundant nodes, since the nodes inserted during the expansion contain only one incoming and only one outgoing edge. FIG. 4e and 4f show two examples of such expansions. In both cases, no splitting of a node takes place; rather, the newly generated node corresponds to inserting an activity (task) . These kinds of expansions are called undesired expansions and should be excluded since they unnecessarily burden the workflow graph rather than enhancing its transparency. In contrast, all desired expansions split an existing node into two new nodes such that each of the new nodes has at least two incoming edges or at least two outgoing edges.

Note that the valid expansions depicted in FIG. 4a -4c are also desired expansions since each of the inserted nodes v and w has either more than one incoming or more than one outgoing edge. By applying the refactoring step 120 to desired expansions only, the application is restricted to node splitting. Note that a node can be split with many different valid expansions, but here, an R-fragment is used to specify certain valid expansion that are performed.

Since the refactoring step 120 is applied on the canonical R-fragments computed in decomposition step 110, the structure of workflow graph G is preserved, and the expansion will yield a unique result.

FIG. 10 shows a schematic flow diagram of a preferred embodiment of refactoring step 120: Based on the RPST of workflow graph G0 obtained from decomposition step 110, a list L containing all non-normal R-fragments of workflow graph G0 is compiled (step 121) . In a preferred embodiment, an initial list Lo containing the complete set of R-fragments of workflow graph Go is generated and iteratively reduced by all those R-fragments which are already normal (or which need not be refactored); the remainder of the list thus containing all non-normal proper R-fragments.

In particular, all entries of the list corresponding to R- fragments having exactly one edge (so-called trivial R-fragments) need not be considered since they are not proper.

Moreover, all entries of the list corresponding to R-fragment sequences (i.e. unions of two R-fragments such that the exit node of the first R-fragment is the entry node of the second R-fragment) need not be considered since they are also not proper.

Once these trivial R-fragments as well as R-fragment sequences have been removed from the list, the list is further processed to remove all R-fragments that are already normal. This furnishes a list L of all proper canonical R-fragments F1 of workflow graph G0 which are not normal.

In the example of FIG. lb. R-fragments FA, FB, F, FF, FG and F1 are eliminated from the list since they are sequences. While FH is not a sequence, it is normal since exactly one outside edge (s,xl) is incident on its entries xl and exactly one inside edge (x4,e) is incident its exit e. Thus, in the case of the workflow graph 11 of FIG. la, the list L of non-normal R-fragments will contain only two entries corresponding to R-fragments FD and FE.

Starting with this list L of non-normal proper canonical R-fragments of workflow graph Go, one item of this list corresponding to a specific R-fragment is chosen (step 123) The order in which those fragments are processed is not significant for the result. One way of processing them efficiently is bottom-up with respect to the refined process structure tree; however, any systematic way of processing the list is equally valid. Subsequently, workflow graph Go is transformed into a new workflow graph G0 by executing a so-called fragment based (F-based) expansion (Go,G0) with respect to (step 124) . Since R-fragment is not normal, more than one edge outside F,2 is incident to the entry node of and/or more than one edge outside is incident to the exit node of All nodes which are shared between R-fragment and any other fragment F are identified. The entry/exit node of with more than one outside edge is split by means of one of the valid expansions shown in FIG. 4a -4c, yielding a valid new subgraph F', and fragment F,,,, in original workflow graph Go is substituted by the new subgraph F', thus yielding a new workf low graph G0 (step 124) . This new expanded workflow graph G0 is "more normal" than Go in the sense that the expansion (Go,G0) transforms fragment into a fragment F' which is "more normal" than the original fragment F,,,,. Subsequently, the RPST is updated locally to correspond to the newly generated workflow graph G0 (step 125) . This splitting is carried out iteratively, based on a single R-fragments F,,,,. As long as the fragment or its derivatives contains a boundary node which has more than one incident edge outside the fragment then a split of this boundary node is performed with the fragment Fmi as a parameter.

If the R-fragment originating from the new subgraph F' is found to be normal, F,717 is removed from the list L of non-normal R-fragments (step 127) . Otherwise, another F-based expansion (G,G2) is executed with respect to F', and the RPST is updated locally to correspond to the newly generated workflow graph G2; this is repeated until the F-fragment originating from F1 is normal (loop 128) . Note that splitting can be performed twice per fragment, once for its entry and once for its exit. After these two splits (if they are both necessary) the fragment is always normal. -At this point, F,717 is removed from list L (step 127), and the next item on list L is chosen as the basis for an F-based expansion of G2 with respect to this R-fragment (step 123) . This is continued until there are no more R-fragments on list L (loop 129) . Once the list L is empty, the iteratively expanded workflow graph resulting from the last F-based expansion contains only normal fragments and constitutes the normal form G* of workflow graph Go and is returned (step 130) The fragment-based expansion is thus applied repeatedly until all R-fragments are normalized. This yields a normal generalized workflow graph G*. The normal generalized workflow graph G* is thus computed from the generalized workflow graph G0 by computing a sequence G0, . . . ,G�,G�+, ..., G, of generalized workflow graphs such that each pair (G1,G�+) is a fragment-based expansion. The normal form G* arises as the maximal expansion of Go. Note that although a given workflow graph Go allows different sequences of fragment-based expansions, one nevertheless obtains a unique result, which is called expanded normal form G* of Go.

In many cases, the expanded normal form G* will be well-structured, since each F-based expansion (GI,GIil) of a fragment F will make this fragment F more well-structured, thus improving the structuredness of the workflow graph.

Note that the method uses only local refactorings. It is known that some workflow graphs can only be transformed into well-structured graphs through non-local transformations, whereas there are also workflow graphs that have no well-structured equivalent. At any rate, the normal form G* of G0 will be "equally or more well-structured" than Go.

In the example of FIG. ib, list L contains entries corresponding to R-fragments ED and FE since these are the only non-trivial and non-normal R-fragments of workflow graph 11. Assume that ED as the first item on this list is chosen as the first one to be processed (step 123) . Nodes xl and x2 of ED are found to be shared with other R-fragments are thus identified as boundary nodes (entry and exit) of ED. Entry node xl of ED is found to have more than one incident edge outside ED, namely (s,xl) and (xl,a3) . Hence, node xl is split into two nodes xl' and xl" (see FIG. ic) . One copy -node xl" in the example of FIG. ic -is associated with the selected fragment ED while the other copy -node xl' in the example of FIG. lc -is associated with the environment of this selected fragment ED. After the split, the two copies xl', xl" are connected with a new single edge e".

Node copy xl" associated with the selected fragment ED is connected to the internal edges el, e2 of fragment ED which, before the split of node xl, were connected to this node xl.

Node copy xl' associated to the environment of fragment ED is connected to the external edge eO of the selected fragment (ED) This yields an updated fragment F' indicated as a dotted box D' in an expanded workflow graph 12 shown in FIG. lc (step 124); the RPST is updated accordingly (step 125) . In step 126, the updated F'io is found not to be normal since its exit node x2 has more than one incident edge outside E'D, namely (x2,a4) and (x3,x2) . Thus, node x2 is split into two nodes x2' and x2", and these new nodes x2' and x2" are connected to the rest of the graph according to rules described above, thus yielding an updated fragment F"D. F"D is found to be normal (step 126) and is therefore removed from list L. Note that the splitting of node x2 also made FE normal, so that after splitting xl and x2 the list L contains no more entries (step 122), and the resulting workflow graph 13 corresponds to the normal form G* (see FIG. id).

Note that it is possible to transform Go with an ED-based expansion of xl and x2 (as described above) or else with an ED- based expansion of xl and an FE-based expansion of x2. The ED-based and the FE-based expansions of x2 split x2 into nodes x2' and x2" in exactly the same way. Thus, the expanded normal workflow graph G* of FIG. ld may be obtained from workflow graph Go of FIG. la either through two ED-based expansions or else through one FE-based and one ED-based expansion.

The method 100 of calculating a normal form G* for a workflow graph Go as outlined above and depicted in FIG. 2 requires that the workflow graph Go to be decomposed be a two-terminal graph in the sense that the workflow graph Go have a single start node s and a single end node t. If a workflow graph G to be decomposed by using the refactoring method of FIG. 7 contains multiple end nodes t, a completion of the workflow graph G has to be performed before a calculation of the refined process structure tree (RPST) can begin.

Simple (IOR) Completion The simplest way to construct a completion of a workflow graph G comprising multiple end nodes consists in adding an inclusive OR-join (ICR-join) as well as an end node, connecting each original end node to the ICR join and connecting the IOR join to the added end node. FIG. 5a shows a workflow graph 30 with three end nodes ti, t2 and t3. FIG. 5b shows a simple completion 31 of the workflow graph G of FIG. 5a in which all original end nodes ti, t2 and t3 of graph 30 are connected to an added ICR-join j which in turn is connected to a unique end node t. Graph 31 is a two-terminal graph, since it has a unique start node s as well as a unique end node t. Thus, graph 31 may be subjected to the steps of method 100 to calculate the expanded normal form G* of G. Fast Completion Technique The simple completion illustrated in FIG. 5a and 5b can be used generally to translate a general directed graph G with multiple end nodes (as, for example, represented by a BPMN diagram) into executable form (e.g. BEL code) using the refined process structure tree (RPST) which requires a generalized workflow graph with a unique start and a unique end node. While simple completion yields a two-terminal workflow graph, there are various cases in which it is undesirable to complete a workflow graph using an ICR-join. In particular, ICR joins are known to be very time-consuming and thus expensive to execute since an evaluation of an ICR usually require non-local verification operations involving large fractions of the workflow graph.

Thus, when computing a completion of workflow graph G, it would be preferable to replace the final ICR-join with a combination of merges and joins, all of which can be executed locally. Such a method 100' of completing a generalized workflow graph G with multiple end nodes can be realized using the refactoring method of FIG. 7 in the following way ("Fast Completion Technique") As depicted in FIG. 11, the method 100' starts out with a generalized workflow graph G with multiple end nodes such as graph 30 depicted in FIG. 5a. This workflow graph G is completed using a simple ICR completion, yielding a completed workflow graph Go such as graph 31 shown in FIG. 5b. The simple completion step 140' adds an ICR-join as well as a unique end node t which allows the computation of the refined process structure tree (RPST) for the simply completed graph Go (step 110) as described above. Within the RPST, there will be one (or more) canonical R-fragments which contain the added IOR-join j of the completed workflow graph G0 as its (or their) exit node. By definition, an R-fragment containing the added final IOR-join j as its exit node is called an end fragment F of Go. In the example of FIG. 5b, the simply completed workflow graph 31 has two end fragments F, namely FM and EN, indicated by boxes N and N. Subsequently, an expansion step 120' is applied with respect to the end fragments F: of workflow graph G0, the expansion being restricted to the exit node j of these end fragments F:. Expansion step 120' follows the steps outlined in FIG. 10; however, in contrast to the (full) expansion step 120 of FIG. 10, now the list L of will contain only the end fragments F, and the expansion will only be carried out with respect to the end fragments' exit nodes. As a result of expansion step 120', the final IOR-join j is split into a number of IOR-joins ji, j2, one for each end fragment F according to the expansion technique presented in conjunction with FIG. 10 above. FIG. 5c shows the resulting expanded In a subsequent replacement step 150, the IOR-joins in this expanded workflow graph G0 are replaced by XOR-joins and AND-joins according to the following rule: -Whenever a fragment F (end fragment F) has neither an XOR-split nor an IOR-split as children, the IOR-join is replaced with an AND-join.

-Whenever a fragment F (end fragments F) has neither an AND-split nor an IOR-split as children, the IOR-join is replaced with an XOR-join.

In the example of FIG. 5c, the only direct child of fragment EN (node v) is an AND-split, and thus IOR-join ji may be replaced by and AND-split ji'. The splits that are direct children of fragment F1 (nodes u and w) both are XOR-split, and thus IOR-join j2 may be replaced by XOR-join j2'; note that node ji', even though it is contained in fragment Ff1, is not a direct child of F1 and thus is not considered when the rules described above are applied. These replacements yield as a result the completed It can be shown that the "Fast Completion Technique" 100' of FIG. 11 requires only linear time and is therefore very fast.

The power of this technique stems from the fact that it abstracts from the interior of the subfragments; for example, fragment FAJ of FIG. 5c is sequential, even though it contains a subfragment with concurrency. Note that the replacement step 150 of method 100' will also replace IOR-joins in the middle of a generalized workflow graph G, if it is applied to all R-fragments of the workflow graph Go. This replacement will be straightforward whenever the IOR-join to be replaced is not contained in a cycle; with suitable IOR-join execution semantics this technique can be applied also -at least in some cases -to setting in which the IOR-join is contained in a cycle. Thus, as indicated by the dotted box in FIG. 9, the replacement step 150 may also be applied as part of method 100 in order replace ICR-joins of the expanded norma] form G* of workf]ow graph G0 wherever possible.

While the fast completion technique 100' can be used analogously for completion of the beginning of a workflow graph that has multiple start nodes. In this case, entry nodes of so-called start fragments (i.e. R-fragments containing an initial ICR-split) are split in an expansion step 120" shown as a dotted box in FIG. 11. Method 100' may thus contain either expansion step 120' (relating to an expansion with respect to end fragments) or expansion step 120" (relating to an expansion with respect to start fragments) or both.

Note that while "Fast Completion Technique" 100' of FIG. 11 constitutes a very fast method for completing a workflow graph G comprising multiple end nodes, it is incomplete in the sense that the rules outlined as part of replacement step 150 may, in many instances, not allow replacing the IOR-join by and XOR-join or an AND-join. Since IOR-joins are known to be expensive to execute, it is highly desirable to remove the IOR-joins in all possible cases.

General Completion Technique An alternative method 200 ("General Completion Technique") for completing a workflow graph G containing multiple end nodes, the method avoiding IOR-joins whenever possible, is depicted in FIG. 12.

The method 200 resorts on exploring the semantics of the workflow graph G to be completed by using a token game (applying rules similar to a Petri net technique) : In it, each individual state S that the workflow graph G can assume is represented by tokens residing on the edges of the graph. A state S of a workflow graph G is defined as a mapping which assigns a natural number of tokens to each edge e of the workflow graph G. The semantics of the various nodes of the workflow graph G are defined by their logic: An AND gateway removes one token from each of its ingoing edges and adds one token to each of its outgoing edges. An XOR gateway non-deterministically chooses one of its incoming edges on which there is at least one token, removes one token from that edge, then non-deterministically chooses one of its outgoing edges and adds one token to that outgoing edge.

One possible way of expressing the semantics of the ICR gateway in a token game is as follows: The ICR gateway is activated if for each incoming edge e' of the gateway that carries no token and for each edge e" of the graph that carries a token, there is no directed path form e" to e' . When the ICR gateway executes, it consumes a token from each incoming edge that carries a token and produces a token for each edge of a nonempty subset of its outgoing edges. Note that, besides this ICR semantics, there are also other ICR gateway semantics that are compatible with the general completion technique shown in FIG. 12.

The initial state S0 of workflow graph G is the state in which there is exactly one token on the unique outgoing edge of the start node s and no token anywhere else. As the workflow graph is executed (step 212 of method 200), tokens are propagated through the workflow graph G according to the logic of the individual nodes and reach a particular final state in which they can not propagate any further. Each final state Sf of the workflow graph can be represented by a set of end nodes which carry a token in the given final state Sf.

In general, workflow graphs may comprise final states Sf which constitute a deadlock or a lack of synchronization. A final state Sf is a deadlock if it contains a token on some edge that is not an incoming edge of an end node (form which it follows that it must then be an incoming edge of a join) . This is clearly undesired. A reachable state S contains a lack of synchronization if there is more than one token on this edge.

Absence of lack of synchronization is a valuable design principle as it rules out that a task is executed concurrently to itself (so-called uncontrolled auto-concurrency) . In order to be able to translate a workflow graph to an executable language such as BPEL in a structured way, the workflow graph may contain neither deadlocks nor lack of synchronization. For the purpose of the following description, the workflow graph is assumed to be free of deadlocks not to contain any lack of synchronization.

Two distinct end nodes t, t' are called mutually exclusive if there is no final state Sf in which both end nodes t, t' occur together, i.e. in which both end nodes t, t' carry a token. A test is defined as a set of end nodes such that two nodes of a same final state Sf are not in a same test, that is, they are mutually exclusive.

As an example, consider the workflow graph 40 shown in FIG. 6a containing three end nodes ti, t2 and t3. A token starting from start node s will be propagated by XOR gateway u -either along edge el in which case a final state 5f1 = {tl,t3} will be reached, -or along edge e2 in which case a final state Sf2 = {t2,t3} will be reached.

When calculating the tests, the end nodes ti and t3 should not be in the same test, since they are in the same final state Sf1.

Analogously, end nodes t2 and t3 should not be in the same test, since they are in the same final state Sf2. Since ti and t3 are mutually exclusive in a test, and t2 and t3 are also mutually exclusive, and there are two tests, Ti = {tl,t2} and 12 = {t3}.

FIG. 6c shows an example of a workflow graph 50 with two end nodes t4 and t5. This workflow graph 50 has final states S = {t4,t5} and S = {t5}. There is only one test T3 = {t5}.

In step 210 of completion method 200 tests of workflow graph G are generated as defined above: Workflow graph G is executed (substep 212), and final states s are computed by a sets of end nodes which carry a token in a given final state. Based on the final states s, a set of tests is computed (step 216) such that each end node is in at least one test. Step 210 is terminated when enough tests of the workflow graph have been computed so that each end node is member of at least one test (substep 217) Note that while the sequence of substeps 212 -217 described above constitutes a preferred method of calculating tests, other methods may also be used.

It can be shown that a workflow graph G has a completion if and only if each end node belongs to a test. Once all tests of workflow graph have been computed (step 218) and it is found that there are end nodes which do not occur in any test, this indicates that no completion of the workflow graph avoiding bR-joins exists. The completion method 200 is terminated at this point (step 220), and a simple IOR completion such as the one described in conjunction with FIG. 5b is used.

By applying steps 212 -217 to the workflow graph 50 shown in FIG. 6c it is found that graph 50 does not have a completion because there is only one test T3 = {t5} and therefore end node t4 is not in any test. Thus, method 200 cannot complete workflow graph 50 in a way that avoids IOR-joins. -Note that it is generally impossible to obtain a completion if one of the final states is a subset of another one. Incidentally, while the method 200 outlined in FIG. 12 (being restricted to local operation) will not yield a completion for workflow graph 50 of FIG. 6c, FIG. 6d shows that it is nevertheless possible to complement graph 50 in such a way that a complete graph 51 is generated, albeit using a non-local method: by adding an AND-split w between nodes a2 and x, graph 50 can be transformed into a complete graph 51.

If during the computation of tests (step 210) it is found that all end nodes occurred in at least one test (substep 217), then a completion of workflow graph without an IOR-join is known to exist, and a so-called AND-/XOR-Completion can be implemented (step 230, shown in detail in FIG. 11) . This calculation comprises a substep 232 of extending workflow graph G by creating an XOR-join for each test of G and one final AND-join as well as a (unique) end node that the final AND-join is connected to. Each end node t of workflow graph G is connected to those XOR-joins that correspond to its respective test (step 234) . If an end node has to be connected to more than one XOR-join, an AND-split is inserted after the end node (step 236) All XOR-joins are connected to the final AND-join (step 238) yielding the completed workflow graph Go. Thus, the completion consists of three tiers: AND-splits, XOR-joins and a final AND-join.

FIG. 6b shows the completion 41 of the workflow graph 40 of FIG. 6a. Note that all gateways of completion that would have only a single incoming and a single outgoing edge can be omitted. Node y is an XOR-join that is created corresponding to the test Ti = {tl,t2}; end nodes ti and t2 contained in test Ti are connected to node y. The node created by the test T2 = {t3} is omitted since it is superfluous. Thus, node y and end node t3 are connected to the final AND-join z which in turn is connected to the unique end node t. Note that no AND-split was necessary for obtaining completion 41 of graph 40.

As described, the completion "General Completion Technique" 200 depicted in FIG. 12 and 13 furnishes a completion G0 of a generalized workflow graph G in such a way that G0 contains no ICR-joins (provided such a completion exists) . This completion technique 200 requires computing the final states Sf of the workflow graph G, which -just as the number of states explored to find the final states Sf -can be exponential to the number of edges/nodes of a workflow graph. The computation can be carried out by a simple state-space exploration but may become very time-consuming.

Hybrid Completion Technique FIG. 14 shows a schematic flow diagram of a "Hybrid Completion Technique" 200' that is a hybrid of methods 100' and 200 in the sense that it combines features of both methods 100', 200 to yield a completion technique 200' which is both complete (i.e. furnishing a completion without ICR-joins, if it exists) and fast in practice.

Hybrid method 200' begins by subjecting a workflow graph G with multiple end nodes to the Fast Completion Technique 100' of FIG. 11, i.e. by performing the steps of -simple (ICR) completion of workflow graph G by means of an ICR-join (step 140'), -decomposition of resulting two-terminal workflow graph G0 in terms of canonical R-fragments F (step 110), -expansion of end fragments F containing the final ICR-join as exit node, by iteratively splitting the exit node (step 140') and -replacing ICR-joins by AND-joins or XCR-joins according to the rules outlined above in conjunction with the Fast Completion Technique 100' (step 150) Subsequently, all end fragments F'1-containing ICR-joins which could not replaced during step 150 are subjected to the General Completion Technique 200 outlined in conjunction with FIGs 12 and 13: For these end fragments F'1-, a token game is carried out, and final states Sf of the end fragments F' are determined. A set of tests of the end fragments F' is computed such that each end node is in at least one test (step 210'). If all (original) end nodes of end fragment F' occur in at least one test, an AND- /XCR-completion of this end fragment F' avoiding ICR-joins exists, and this completion is implemented by carrying out the AND-/XCR-Completion step 230' (analogously to step 230 outlined in FIG. 13) . If during the evaluation of the tests it is found that there are end nodes which do not occur in any test, this indicates that no completion of the end fragment F'1-avoiding ICR-joins exists.

As an example, FIG. 7a shows a workflow graph 60 comprising five end nodes ti, ..., t5. In step 140', graph 60 is completed by adding an ICR-join connecting all end nodes ti, ..., t5 to a unique end node t, yielding completed graph 61 of FIG. 7b. A decomposition of workflow graph 61 in terms of canonical R-fragments F (step 110) yields three canonical end fragments F, FQ, and FR which contain the final ICR-node j as their exit node; they are indicated by boxes P, Q and R in FIG. 7c. As the workflow graph 61 is expanded with respect to these end fragments, the expansion being restricted to the exit node j of these end fragments, IOR-join j is split into multiple ICR-joins ji, ..., j3 (see FIG. 7d), yielding an expanded workflow graph 62. Of these, IOR-joins ji and j2 can be replaced by an XOR-join ji' and an AND-join j2', respectively, during ICR Replacement Step 150, since fragment F only contains XCR-joins (node xl) as direct children and fragment F0 contains only AND-joins (node p1) as direct children (see FIG. 7e) . Then fragment FR is extracted from workflow graph, and fragment FR is analyzed using the General Completion Technique 200, i.e. by conducting tests (step 210') and implementing the AND-/XCR Completion (step 230') on fragment FR. After this completion, the result is merged back into the rest of the workflow graph.

Note that in the example of Fig. 7e, the structure of fragment FR is identical to graph 40 of FIG. 6a. Thus, when executing the General Completion Technique 200 on fragment FR (corresponding to carrying out steps 210' and 230' of the Hybrid Completion Technique 200' of FIG. 14, fragment FR will be completed analogously to workflow graph 40 of FIG. 6a by adding AND-join j3' and XCR-join j3", analogously to workflow 41 of FIG. 6b. The thus completed fragment is merged back, resulting in workflow graph 64 as depicted in FIG. 7f.

Hybrid Completion Technique 200' combines features of the Fast Completion Technique 100' and the General Completion Technique in such a way as to profit from the advantages of both techniques: it using the refactoring method 100 of FIG. 9 first, the completion problem is restricted to very few end fragments (namely the ones containing the final ICR join); thus, the state space exploration which forms the basis of the General Completion Technique 200 needs only to be carried out for a few end fragments. Thus, compared to the General Completion Technique 200, the Hybrid Completion Technique 200' of FIG. 14 has the advantage of being computationally less expensive, since the computationally expensive part (i.e. the computation of final states Sf and of tests T) can be restricted to a few individual fragments which are usually significantly smaller than the whole workflow graph.

Another advantage of the Hybrid Completion Technique 200' is that the resulting completion is in general better structured, hence more readable. Consider the workflow graph 71 of FIG. 8 which is calculated by implementing the General Completion Technique 200 on multiple end-node workflow graph 60 of FIG. 7a.

As can be seen, while workflow graph 71 resulting from using the General Completion Technique 200 is more compact, it is much less structured and thus harder to grasp, especially for an unexperienced user.

Irrespective of this specific advantage of the Hybrid Completion Technique 200', all three completion methods 100', 200 and 200' outlined above present several advantages over known methods: -They use XOR-/AND-joins instead of ICR-joins whenever possible, thus reducing execution costs considerably.

-They facilitate dead path detection: When translating a BPMN model into SPEL, dead paths have to be detected and eliminated. While methods for dead path elimination are available, they are costly to execute. Thus, if ICR-joins can be replaced by merges and joins, dead path elimination can be switched off, thus saving the overhead of sending, propagating and synchronizing dead tokens along potentially long paths.

-The simplify termination verification: Checking whether a process has terminated also requires checking the entire (generalized) workflow graph for tokens. Assuming that the workflow graph contains neither deadlocks nor lack of synchronization, a workflow graph with a unique end node will signal termination through a single token on the unique end node. Thus, a completion at compile time provides a local termination detection at runtime.

Referring now to FIG. 15, a computer system 300 implementation of a preferred embodiment of the present invention is shown.

Specifically, the present invention can be implemented as a computer system 300 and/or program product for automatically refactoring a directed two-terminal graph, thus enhancing the graph's readability and making the graph more well-structured.

Analogously, FIGs. 16 and 17 show computer system 300', 300" implementations of further preferred embodiments of the present invention. Specifically, the invention can be implemented as a computer system 300', 300" and/or program product for automatically completing a directed graph containing multiple end nodes in such a way as to optimize the graph's execution properties.

As depicted, computer systems 300, 300', 300" generally comprise memory 312, input/output (I/O) interfaces 314, a central processing unit (CPU) 316, external devices/resources 318, bus 320 and data base 338. Memory 312 may comprise any known type of data storage and/or transmission media, including magnetic media, optical media, random access memory (RAM), read-only memory (RaM), a data cache, a data object etc. Moreover, memory 312 may reside at a single physical location, comprising one or more types of data storage, or can be distributed across a plurality of physical systems in various forms. CPU 316 may likewise comprise a single processing unit, or be distributed across one or more processing units in one or more locations, e.g. on a client and server. I/O interfaces 314 may comprise any system for exchanging information from an external source.

External devices 318 may comprise any known type of external device, including keyboard, mouse, voice recognition system, printer, monitor, facsimile etc. Bus 320 provides a communication link between each of the components in the computer system 300 and likewise may comprise any known type of transmission link, including electrical, optical, wireless etc. In addition, although not shown, additional components such as cache memory, communication systems, system software etc. may be incorporated into computer systems 300, 300', 300".

Database 338 provides storage for information necessary to carry out the present invention. Such information could include e.g. data relating to workflow graphs G0 and G, decompositions of the workgraphs in terms of a refined process structure tree (RPST) and its R-fragments, expanded norma] form G* of workflow graphs G0 and G etc. Database 338 may include one or more storage devices, such as a magnetic disk drive or an optical disk drive.

In another embodiment, database 338 includes data distributed across, for example, a local area network (LAN), wide are network (WAN) or a storage area network (SAN) . Database 338 may also be configured in such a way that one of ordinary skill in the art may interpret it to include one or more storage devices.

Moreover, it should be understood that database 338 could alternatively exist within computer system 300.

Computer System 300 of FIG. 15 is geared at executing a workflow graph Refactoring Technique according to the invention. Stored in memory 312 of computer system 300 is logic system 326. As depicted, logic system 326 generally includes a Graph Decomposition System 328 for decomposing a two-terminal graph Go into a set of canonical R-fragments and a Fragment Expansion System 330 for expanding the two-terminal workflow graph Go by splitting shared nodes between R-fragments F. Logic system 326 may also include a Simple (ICR) Completion System 327 for transforming a general graph G with multiple end nodes into a two-terminal graph Go.

Computer System 300' of FIG. 16 is geared at executing a General Completion Technique for completing a workflow graph with multiple end nodes. Stored in memory 312' of computer system 300' is logic system 326' . As depicted, logic system 326' generally includes a Test Generating System 332 for calculating test of the two-terminal graph G0 or of its expanded normal form G* or of R-fragments F thereof, and an AND-/XOR-Completion System 334 for substituting ICR-joins by AND-or XOR-joins in one of the (sub-) graphs Go, G* or F. Computer System 300" of FIG. 17 is geared at executing a Fast Completion Technique and/or a Hybrid Completion Technique for completing a workflLow graph with multiple end nodes. Stored in memory 312" of computer system 300" is logic system 326". As depicted, logic system 326" generally includes a Simple (ICR) Completion System 327 for transforming a general graph G with multiple end nodes into a two-terminal graph Go. Moreover, logic system 326" includes a Graph Decomposition System 328 for decomposing a two-terminal graph Go into a set of canonical R-fragments, a Fragment Expansion System 330 for expanding the two-terminal workflow graph Go by splitting shared nodes between R-fragments F and a ICR Replacement system for replacing ICR-joins by XCR-or AND-joins according to predefined rules wherever applicable. If computer system 300" is to be used for executing a Hybrid Completion Technique, it also includes a Test Generating System 332 for calculating test of the two-terminal graph Go or of its expanded normal form G* or of R-fragments F thereof, and an AND-/XOR-Completion System 334 for substituting IOR-joins by AND-or XOR-joins in one of the (sub-) graphs G0, G* or F. The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer readable medium providing program code for use by or in connection with a computer or any instruction execution system.

For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by on in connection with the instruction execution system, apparatus, or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read-only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.