Chapter 3. A Process Model Based on Well-formed Workflow
3.1. Control Flow Specification
As discussed in Section 2.2, [15] does not concern the activities can decide where artifacts are passed and the artifacts can have multiple instances in a workflow. To solve these problems, there are several features introduced in addition in this thesis. The new features are described in the following paragraphs. First, Definition 3.1 formally defines a process specification and Definition 3.2 describes the fundamental properties contained in each activity.
Definition 3.1 (Process Specification)[15]
A process specification p = (𝑉𝑝, 𝐹𝑝, 𝑅𝑝, 𝐶𝑝, 𝑆𝑝, 𝐸𝑝), where
𝑉𝑝: The set of activities in p. The id of each activity is unique.
𝐹𝑝: The set of flows in p.
𝑅𝑝: The set of resources (artifacts) used in p.
𝐶𝑝: The set of control blocks in p. The id of each control block is unique.
𝑆𝑝: The start activity of p.
𝐸𝑝: The end activity of p.
𝑆𝑝, 𝐸𝑝 ∈ 𝑉𝑝.
𝐶ℎ𝑖𝑙𝑑𝑝 = {sp | ∀compound activity v∈ 𝑉𝑝, v.subp = sp}.
Definition 3.2 (Activity Fundamental Properties)
∀v ∈ 𝑉𝑝, there are two fundamental properties in v:
v.type ∈ {Task, ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin, LoopSubProcess, SubProcess}.
𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣: A stack stores all the control blocks and branches where v resides. (The control block and branch are defined further in Definition 3.4 and 3.6.)
For each activity v ∈ 𝑉𝑝, the property 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is a new feature and its usage is illustrated in Definition 3.9. The property v.type represents v‟s type. If v.type is SubProcess or LoopSubProcess, v is a compound activity. Definition 3.3 below introduces a new feature:
subp to a compound activity.
Definition 3.3 (Compound Activity)
∀ v ∈ 𝑉𝑝, v is a compound activity when v.type ∈ {SubProcess, LoopSubProcess}.
v.type ∈ {SubProcess, LoopSubProcess}
v.subp : The sub-process included within v.
In our model, there are three types control blocks, ”ROOT Control Block”, “AND Control Block”, and “XOR Control Block”, and the properties to record the execution order of these blocks are defined in Definition 3.4. Further, for an activity v, v is contained in c when v is reachable from c.start and c.end is reachable from v. For a flow f = (u, v) ∈ 𝐹𝑝, f is contained in control block c when u and v are both contained in c.
Definition 3.4 (Control Block)
A control block c = (start, end, type)∈𝐶𝑝, where
c.start = 𝑣𝑠, 𝑣𝑠 ∈ 𝑉𝑝 and 𝑣𝑠.type ∈ {ProcessStart, XorSplit, AndSplit}
c.end = 𝑣𝑒, 𝑣𝑒 ∈ 𝑉𝑝 and 𝑣𝑒.type =
ProcessEnd if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = ProcessStart XorJoin if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = XorSplit AndJoin if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = AndSplit
𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑒
∄ v ∈ 𝑉𝑝, v.type ∈{ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin}, IsReachable(c.start, v) = ture, IsReachable(v, c.end) = ture, and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠.
c.type ∈ {ROOT, AND, XOR}
c.type =
ROOT if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = ProcessStart XOR if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = XorSplit AND if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = AndSplit
c.bcounter is a counter of branch id. The value of bcounter for c is set to 0 at the beginning of c‟s construction.
c.totalbranches = outflows of 𝑐. 𝑠𝑡𝑎𝑟𝑡 . (The outflow is defined in Definition 3.7.)
For each control block c ∈ 𝐶𝑝, the properties c.start and c.end represent the start activity and end activity of c separately. If activity 𝑣𝑠 is the start activity and 𝑣𝑒 is the end activity, the following properties hold:
(a) 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑒.
(b) There is no such an activity v ∈ 𝑉𝑝, v.type∈{ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin}, v is reachable from 𝑣𝑠, 𝑣𝑒 is reachable from v, and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠.
The function IsReachable(c.start, v) in Definition 3.4 represents whether v is reachable
returns false. The function is defined in Definition 3.11.
Based on the type of c.start, the property c.type is one of the following types: “ROOT”,
“AND”, and “XOR”. The property c.bcounter is a new feature and is used to count branch ids.
The value of c.bcounter is increased by one when a new branch is added into c. The property c.totalbranches represents the number of branches in c.
Each process is only allowed to contain one root control block R. For a process p, p.start
= ps, p.end = pe, the root control block R = (ps, pe, ROOT) and R.totalbranches is always 1.
Based on the Definition 3.4, a control activity is defined in Definition 3.5.
Definition 3.5 (Control Activity)
∀ v ∈ 𝑉𝑝, v is a control activity.
v.type ∈ {ProcessStart, ProcessEnd, AndSplit, AndJoin, XorSplit, XorJoin}.
v is the start activity of a control block if v.type ∈ {ProcessStart, AndSplit, XorSplit}.
v is the end activity of a control block if v.type ∈ {ProcessEnd, AndJoin, XorJoin}.
v.cb represents the id of the block beginning from or ending at v.
v.cb = R if v.type ∈ {ProcessStart, ProcessEnd}.
In addition, if an activity v ∈ 𝑉𝑝 is neither a control activity nor a compound activity, v is a task activity and v.type = Task.
Based on Definition 3.5, a branch in a control block is basically a path. Also the path begins at the start activity of the control block, and ends at the end activity of the control
block. In order to identify different branches in a control block, each branch contains a property id. When a new branch b is added into a control block c, c.bcounter is added by one and is set value of b.id. A branch is defined in Definition 3.6.
Definition 3.6 (Branch)
In a control block c which is not sequence, a branch b = (𝑣1, …, 𝑣𝑘), k≥2, where
∃flow (𝑣𝑖, 𝑣𝑖+1) ∈ 𝐹𝑝, i = 1, 2, …, k-1
𝑣1 = c.start
𝑣𝑘 = c.end
b.id represents the id of b.
A flow in workflow specification represents the execution order of activities and is defined in Definition 3.7.
Definition 3.7 (Flow)
∀ f = (u, v) ∈ 𝐹𝑝, where u, v ∈ 𝑉𝑝.
u is the source activity of f, and v is the sink activity of f.
f is an inflow of v and an outflow of u.
Figure 3.1 shows the corresponding notations of control activities, task activity, sub-process activity, loop sup-process activity, and flow.
Figure 3.1: Notations of Control Flow Graph.
Figure 3.2: An Example of Control Flow Graph.
Figure 3.2 shows an example of a well-formed control flow. In Figure 3.2, each activity is associated with an Ancestor Block Stack, ABStack, showing the control blocks where the activity resides. The properties about the relations between elements in an ABStack are described after illustrating the elements in Definition 3.8. Since all activities are contained in root control block R and R.totalbranches is always 1, an element (R, 1) is in the bottom of
each ABStack. For an activity v, each element in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 marks a control block containing v. An element inside an ABStack is formally defined in Definition 3.8.
Definition 3.8 (The element inside an ABStack)
An element e inside 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 contains two tuples (blockID, branchID),
blockID represents a control block containing v.
branchID represents the id of the branch after the initial control activity of blockID.
An ABStack has the following properties:
1. Assume two elements, e1 and e2, exist in an ABStack. Element e1 is above e2 if and only if the block represented by the first tuple of e1 is contained in that represented by e2. For example, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2 in Figure 3.2 has two elements e1=(x1, 1) and e2=(a1, 1). Because x1 is contained in a1, e1 is above e2. By reading the elements top-down in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2, it is found that 𝑣2 is located on branch 1 of x1, x1 is located on branch 1 of a1, and a1 is located in R. Thus, the 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2 can be used to represent the location of activity 𝑣2. In this case, because x1 is contained in a1, x1 is deeper than a1 in this nested control blocks structure. In the same reason, because a1 is contained in R, a1 is deeper than R. Therefore, x1 is the deepest control block which contains 𝑣2 because x1 does not contain any control block.
2. Consider 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣, if there are some elements contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 but not in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣, u is contained in the blocks represented by the elements but v is not.
For example, element (x1, 1) is contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝐵 but not contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑥𝑗 1 in Figure 3.2. Therefore, control block x1 contains activity 𝑣2 but not
The operations associated with ABStack are defined in Definition 3.9. The construction of an ABStack is described in Algorithm 3.1.
Definition 3.9 (The operations associated with an ABStack) The operations associated with an ABStack include:
1. push(E: element): Pushing an element into the top of ABStack.
2. pop(): Popping an element out from the top of ABStack.
3. isEmpty(): If the ABStack = ∅, return true. Otherwise return false.
4. getTopXOR(): Getting the first element from the top of ABStack and the type of the block associated with the element is XOR. For example, let 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = , x1 and x2 be XOR control blocks, a2 be an AND control block, then 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.getTopXOR() = (x2, 2).
5. removeIdenticalElements(A: ABStack): Removing the same elements in both A and the target ABStack. For example, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 = , 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢) = .
Algorithm 3.1 (Construction of an ABStack)
∀ v ∈ 𝑉𝑝, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is constructed by the following steps:
Algorithm ConstructABStack(v){
1. if(v.type == ProcessStart){
2. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣= ;
3. }else if(v.type ≠ ProcessStart and ∃inflow f=(u, v) ∈ 𝐹𝑝 and f is located in branch b){
4. if(u.type ∉ {XorSplit, AndSplit}){
5. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢;
10. if(v.type ∈ {XorJoin, AndJoin}) 11. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.pop();
12. } 13. } }
At line 1 to 2, if the type of v is ProcessStart, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 only contains one element(R, 1). If the type of v is not ProcessStart, v has inflow(s). Let f be the inflow (u, v) and f be located in branch b. If v has multiple inflows, random one of them is assigned to f. At line 4 to 9, if the type of u is not XorSplit and AndSplit, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢. Otherwise, u is the start activity of a control block. Hence, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is equal to 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 which is added an element (u.cb, b.id). At line 10 to 12, if the type of v is XorJoin or AndJoin, v is the end activity of a control block. Thus, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 pops an element.