Artifact Flow Diagrams

Each artifact in a workflow has a corresponding artifact flow diagram to represent the usages and transmissions of it. For artifact d, an activity v is in the artifact flow diagram for d if d is used by v; i.e. 𝑅𝑜𝑙𝑒_𝑣^𝑑 ≠ Irrelevantor. The flows between activities in the artifact flow diagram for d represent the transmissions of d. Definition 3.17 defines an artifact flow diagram for an artifact.

Definition 3.17 (An Artifact Flow Diagram)

For an artifact d, artifact flow diagram for d in process p is denoted by 𝐴𝐹_𝑝^𝑑 which contains two tuples (𝐴𝐹𝑉_𝑝^𝑑, 𝐴𝐹𝐹_𝑝^𝑑, 𝐴𝐹𝑁_𝑝^𝑑), where

 𝐴𝐹𝑉_𝑝^𝑑 is a set of activities. For an activity v∈𝐴𝐹𝑉_𝑝^𝑑, 𝑅𝑜𝑙𝑒_𝑣^𝑑 ≠ Irrelevantor.

 𝐴𝐹𝐹_𝑝^𝑑 is a set of flows. For a flow (u, v)∈𝐴𝐹𝐹_𝑝^𝑑 and u, v ∈𝐴𝐹𝑉_𝑝^𝑑, a Pass(d, v) ∈ 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡_𝑢.

 𝐴𝐹𝑁_𝑝^𝑑 is a set of XBNodes existing in the artifact flow diagram. An XBNode is introduced in the following paragraphs and is defined in Definition 3.19.

In Definition 3.17, a flow (u, v) is added into 𝐴𝐹𝐹_𝑝^𝑑 when a Pass(d, v) is added into 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡_𝑢. If there is a Path (v, u) ∈ 𝐴𝐹_𝑝^𝑑, a loop structure is formed in the artifact flow diagram after adding flow (u, v) into 𝐴𝐹𝐹_𝑝^𝑑. The activities in the loop wait for the artifact cyclically and a deadlock occurs. In order to avoid the deadlock, the loop structure is not allowed to exist in an artifact flow diagram. Therefore, Pass(d, v) can not be added into 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡_𝑣 when a Path(v, u) exists in 𝐴𝐹_𝑝^𝑑.

In order to detect some artifact usage anomalies, the number of an artifact

𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 be a set of activities, of which each passes d to v. Let 𝑆𝑒𝑛𝑑_𝑣^𝑑 be a set of activities, of which each receives d from v. Therefore, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 represents the number of inflows of v in the artifact flow diagram for d. On the contrary, 𝑆𝑒𝑛𝑑_𝑣^𝑑 represents the number of outflows of v in the artifact flow diagram for d.

However, some activities in 𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 might not pass d to v in run time. Therefore, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 is not always equal to the number of d received in v. Similarly, 𝑆𝑒𝑛𝑑_𝑣^𝑑 is not always equal to the number of d passed from v. In Figure 3.4 (a), (b), and (c), activity 𝑣₁ passes artifact d to 𝑣₂ and 𝑣₃ respectively. Hence, their artifact flow diagrams for d in Figure 3.4 (d) contain activities: 𝑣₁, 𝑣₂, and 𝑣₃, and flows: (𝑣₁, 𝑣₂) and (𝑣₁, 𝑣₃). 𝑆𝑒𝑛𝑑_𝑣^𝑑₁

= {𝑣₂, 𝑣₃} and 𝑆𝑒𝑛𝑑_𝑣^𝑑₁ = 2 in Figure 3.4 (a), (b), and (c).

In Figure 3.4 (a), because 𝑣₂ and 𝑣₃ are parallel activities, the number of d passed from 𝑣₁ is 2. In Figure 3.4 (b), because 𝑣₂ and 𝑣₃ are exclusive activities, the number of d passed from 𝑣₁ is 1. In Figure 3.4 (c), 𝑣₂, 𝑣₃, and 𝑣₅ are exclusive activities and 𝑣₁ does not pass d to 𝑣₅. Therefore, the number of d passed from 𝑣₁ is 0 if 𝑣₅ is selected to execute.

Otherwise, the number of d passed from 𝑣₁ is 1. Obviously, the number of d passed from 𝑣₁ is not always equal to 𝑆𝑒𝑛𝑑_𝑣^𝑑₁ . The artifact flow diagram in Figure 3.4 (d) is ambiguous to represent the number of an artifact passed/received from/in an activity.

Figure 3.4: An Artifact Flow Diagram without XBNodes.

In order to solve this problem, the activities in 𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 are categorized into two sets:

𝐸𝐼𝑁_𝑣^𝑑 and 𝑃𝐼𝑁_𝑣^𝑑. 𝑃𝐼𝑁_𝑣^𝑑 contains the activities passing d to v potentially. 𝐸𝐼𝑁_𝑣^𝑑 contains the activities passing d to v explicitly. Similarly, the activities in 𝑆𝑒𝑛𝑑_𝑣^𝑑 are categorized into two sets, 𝑃𝑂𝑈𝑇_𝑣^𝑑 and 𝐸𝑂𝑈𝑇_𝑣^𝑑 . 𝑃𝑂𝑈𝑇_𝑣^𝑑 contains the activities receiving d from v potentially. 𝐸𝑂𝑈𝑇_𝑣^𝑑 contains the activities receiving d from v explicitly.

For example in Figure 3.4 (a), because 𝑣₁ always passes d to 𝑣₂ and 𝑣₃, 𝐸𝑂𝑈𝑇_𝑣^𝑑₁ = {𝑣₂, 𝑣₃} and 𝑃𝑂𝑈𝑇_𝑣^𝑑₁ = ∅. In Figure 3.4 (b), activity 𝑣₁ does not pass d to 𝑣₂ when 𝑣₂ is not selected to execute in x1. Hence, 𝑣₁ passes d to 𝑣₂ potentially. For the same reason, 𝑣₁ also passes d to 𝑣₃ potentially. Therefore, 𝐸𝑂𝑈𝑇_𝑣^𝑑₁ = ∅ and 𝑃𝑂𝑈𝑇_𝑣^𝑑₁ = {𝑣₂, 𝑣₃}. The formal definitions of these sets are defined in Definition 3.18.

𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡_𝑣1= Pass(d, 𝑣₂) → Pass(d, 𝑣₃)

Definition 3.18 (Receiving/Sending Sets)

For activity v ∈ 𝐴𝐹𝑉_𝑝^𝑑, v contains the following sets:

 𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑 = {u∈𝐴𝐹𝑉_𝑝^𝑑| ∃flow (u, v) ∈𝐴𝐹𝐹_𝑝^𝑑}

 𝑃𝐼𝑁_𝑣^𝑑 =

{u∈𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑| (∃e∈𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑢.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑣)) and e.blockID.type = XOR and IsExclusive(u, v) ≠ true}

 𝐸𝐼𝑁_𝑣^𝑑 = {u∈(𝑅𝑒𝑐𝑒𝑖𝑣𝑒_𝑣^𝑑\𝑃𝐼𝑁_𝑣^𝑑) | IsExclusive(u, v) ≠ true}

 𝑆𝑒𝑛𝑑_𝑣^𝑑 = {u∈𝐴𝐹𝑉_𝑝^𝑑| ∃flow (v, u) ∈𝐴𝐹𝐹_𝑝^𝑑}

 𝑃𝑂𝑈𝑇_𝑣^𝑑 =

{u∈𝑆𝑒𝑛𝑑_𝑣^𝑑| (∃e ∈𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑢.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑣)) and e.blockID.type = XOR and IsExclusive(v, u) ≠ true}

 𝐸𝑂𝑈𝑇_𝑣^𝑑 = {u∈(𝑆𝑒𝑛𝑑_𝑣^𝑑\𝑃𝑂𝑈𝑇_𝑣^𝑑) | IsExclusive(v, u) ≠ true}

For a flow (u, v) ∈ 𝐴𝐹𝐹_𝑝^𝑑, if u and v are exclusive activities, u and v can not both be executed. Therefore, v can not receive d from u. For this reason, u is not added into 𝑃𝐼𝑁_𝑣^𝑑 and 𝐸𝐼𝑁_𝑣^𝑑 when IsExclusive(u, v) = true. Similarly, u is not added into 𝑃𝑂𝑈𝑇_𝑣^𝑑 and 𝐸𝑂𝑈𝑇_𝑣^𝑑 when IsExclusive(v, u) = true. Based on Definition 3.18, Figure 3.5 shows the elements in 𝑆𝑒𝑛𝑑_𝑣^𝑑₁, 𝐸𝑂𝑈𝑇_𝑣^𝑑₁, and 𝑃𝑂𝑈𝑇_𝑣^𝑑₁.

Figure 3.5: An Example of Receiving and Sending Sets. algorithms of construction of XBNodes are illustrated in Section 5.3.

𝑃𝐼𝑁^′_𝑣^𝑑 and 𝐸𝐼𝑁^′_𝑣^𝑑 are used to represent 𝑃𝐼𝑁_𝑣^𝑑 and 𝐸𝐼𝑁_𝑣^𝑑 whose activities are all

Therefore, the number of d passed/received from/in v can be identified. Let 𝑁𝐼𝑁_𝑣^𝑑 be the number of d received in v, then 𝐸𝐼𝑁^′_𝑣^𝑑 ≤ 𝑁𝐼𝑁_𝑣^𝑑 ≤ 𝐸𝐼𝑁^′_𝑣^𝑑 + 𝑃𝐼𝑁^′_𝑣^𝑑. Similarly, let 𝑁𝑂𝑈𝑇_𝑣^𝑑 be the number of d passed from v, then 𝐸𝑂𝑈𝑇^′_𝑣^𝑑 ≤ 𝑁𝑂𝑈𝑇_𝑣^𝑑 ≤ 𝐸𝑂𝑈𝑇^′_𝑣^𝑑 + 𝑃𝑂𝑈𝑇^′_𝑣^𝑑 . Figure 3.6 shows the artifact flow diagrams with XBNodes.

Figure 3.6: An Artifact Flow Diagram with XBNode.

In Figure 3.6 (d), because 𝐸𝑂𝑈𝑇^′_𝑣^𝑑₁ = 2 and 𝑃𝑂𝑈𝑇^′_𝑣^𝑑₁ = 0, the number of d passed from 𝑣₁ is 2. In Figure 3.6 (e), because 𝐸𝑂𝑈𝑇^′_𝑣^𝑑₁ = 1 and 𝑃𝑂𝑈𝑇^′_𝑣^𝑑₁ = 0, the number of d passed from 𝑣₁ is 1. In Figure 3.6 (f), because 𝐸𝑂𝑈𝑇^′_𝑣^𝑑₁ = 0 and 𝑃𝑂𝑈𝑇^′_𝑣^𝑑₁ = 1, the number of d passed from 𝑣₁ is 0 or 1. Definition 3.19 defines an XBNode and its properties.

𝑣₁

Definition 3.19 (An XOR Block Node)

Let an XBNode n be used to represent an XOR control block x. XBNode n contains four tuples (blockID, cv_set, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑛, isUncond),

 blockID represents the id of an XOR control block which n expressed; thus, blockID = x.

 cv_set is a set of activities ∈ PIN/POUT and the activities in cv_set are all located in different branches of x.

 𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑛 represents the location of x; hence, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘_𝑛 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘_{𝑥.𝑠𝑡𝑎𝑟𝑡}.

 isUncond is a Boolean value. The value is true when n is unconditional. Otherwise, the value is false.

 n.Parent = Null or the id of an XBNode containing n.

 n.Attached = Null or the id of an activity where n is attached.

Based on above definitions, a flow in an artifact flow diagram contains the following properties: outBlock and inBlock. The property outBlock/inBlock is the id of an XBNode which contains sink/source activity. For example, let f be the flow (𝑣₁, 𝑣₂) in Figure 3.6 (e).

The f.outBlock = n1 because 𝑣₃∈ n1.cv_set. Definition 3.20 defines a flow in an artifact flow diagram.

Definition 3.20 (A Flow in an Artifact Flow Diagram)

For a flow f = (u, v) ∈ 𝐴𝐹𝐹_𝑝^𝑑 and activities u, v ∈ 𝐴𝐹𝑉_𝑝^𝑑, flow f has the following properties:

 f.outBlock = Null or n if v ∈ n.cv_set.

 f.inBlock = Null or n if u ∈ n.cv_set.

n is an XBNode.