Chapter 4. Artifacts
4.3 Artifact Inaccuracy
4.3.1 No Producer
In general, the first operation on an artifact in workflow is Specify, acting as initialization. No Producer problem indicates that an artifact has a different operation earlier than Specify. It indicates that this workflow might fail due to retrieval error or an exception of missing target artifact. Figure 4.2 describes the five state transitions;
four of them causing No Producer problem and the one reasonable. The exception case is that this artifact is created by invoked application / outer system or is an existing artifact before this workflow execute. No Producer problem is a warning for potential error but not absolute one.
Start Written
Figure 4.2 No Producer Problem (part A, B, C, D) and Expectant (part E) 4.3.2 No Consumer
No Consumer problem means that there is no activity requesting the artifact after
last modification, which might be Specify, Write or Revise. There are two situations which this problem occurs in. First, this artifact is designed to be manipulated in this workflow and packed as a result artifact for access of external system. Second, this artifact is redundant and no succeeding activity (control node) for the access it. How to solve this problem depends on designers' desire or is according to system requirement.
4.3.3 Redundant Specify
Redundant Specify problem indicates that there is another specified state
following the first specified state. In other words, the artifact specified in current activity is specified by succeeding activity again. It will cause the confusion in maintaining artifacts and make exceptions in execution.
4.3.4 Contradiction
Contradiction problem describes a situation that current artifact state does not conform to the in-state specified in the pre-condition of a succeeding activity. Figure
4.3 shows a simple example of Contradiction problem. Figure 4.3(A) is a workflow schema shows the execution order of activities A1, A2, A3 and A4. Figure 4.3(B) is a set of activity specifications with pre-condition and post-condition. There is a Contradiction problem between A3 and A4.
Figure 4.3 Contradiction Problem
In an activity specification, the pre-condition and post-condition provide a mechanism to specify the in-state before and out-state after the execution of an
activity. More state constrains specified in pre-condition and in post-condition will make state-matching more precisely.
4.3.5 Parallel Hazard
Parallel Hazard problem happens because of conflict interleaving of concurrent
artifact operations in activities. When more than one concurrent subflow manipulates an artifact in parallel, and the activities in different subflows on the artifact are not in a deterministic execution order expect the concurrency constrains are defined.
The main characteristic patterns of artifact-state transition are concurrent operations and competition of state-mapping. Parallel Hazard problem will be recognized if there are multiple concurrent subflows operating the same artifact.
Besides, multiple state choices of incoming flow to an AND control block and multiple produced states of an AND control block are two symptoms of state-mapping competition. And state-mapping competition is prerequisite for potential Parallel Hazard. In Section 5.4, multiple produced states of out-states and multiple concurrent
subflows operating the same artifact are two major patterns of Parallel Hazard detection.
Figure 4.4 illustrates two simple examples of Parallel Hazard problem. In Figure 4.4(A1), Activity A1 and A2 are concurrent activities which are not in a strict execution order. Figure 4.4(A2) shows four situations that A1 and A2 have dependence of artifact manipulation. If the execution order conforms to dependence of artifact operations, there is no problem. Otherwise, Parallel Hazard will occur.
Figure 4.4(B) shows an example of state-mapping competition in a composite state extracted from a AND control block.
Regarding below five types of operation, only concurrent operations of Read will not cause Parallel Hazard. Other combinations of operations on the same artifact will bring Parallel Hazard potentially or absolutely. More explicit state and transition describing artifact (constrains of in-state or conditions of out-state) will make Parallel Hazard detection more precisely.
Figure 4.4 Parallel Hazard 4.3.6 Branch Hazard
Branch Hazard may be produced from an XOR control block because of the
possibility of selecting branch subflows, which contain operations on artifacts. For example, the result of artifact operations within a branch subflow, not selected for execution, can contribute to succeeding artifact operations outside of current XOR control block. Branch Hazard problem will occur at this case.
Another Branch Hazard is that there is no artifact state consistency between the
condition testing in XOR-SPLIT node and branch subflows. If a condition testing in XOR-SPLIT node is relative to the state of some artifacts, the state-mapping will be performed to detect Branch Hazard. If artifact state constrains on XOR-SPLIT are not totally compatible to in-state sets of branch subflows, there is a Branch Hazard detected inside the control block. The last situation of Branch Hazard is that there is losing out-state or insufficient in-state occurring between this XOR control block and outside of it.
There are three types of Branch Hazard as shown in Figure 4.5, which are hidden effect, condition mismatch, and insufficient in-state/losing out-state. Figure 4.5(A) is a partial workflow schema, containing a XOR control block and two activities A7, A9. Figure 4.5(B) is Branch Hazard of hidden effect. Figure 4.5(C) is Branch Hazard of condition mismatch. And Figure 4.5(D) is Branch Hazard of insufficient in-state/losing out-state.
These Six types or artifact inaccuracy mentioned above might impact on workflow execution potentially or absolutely. Following chapter will introduce how to extract information of artifact manipulations and detect these artifact inaccuracies to achieve artifact validation on workflow schema.
Figure 4.5 Branch Hazard
Chapter 5. Artifact Validation for Primitive Workflow
Artifact state diagrams and state transition criteria assist our work in tracing and validating manipulation of artifacts in workflow. TLWM and characteristics of primitive workflow schema reduce the complexity of artifact validation. Artifact inaccuracy mentioned in Chapter 4 makes a set of cases that might impact on the correctness of artifact manipulation. Our approach to validate the use of artifacts is based on workflow reduction and the state tracing on artifacts.
There are three steps during validation. The first is to extract state transitions from artifact manipulation within activities. The second is to perform the state mapping of artifacts within sequential blocks. At the same time, an artifact state diagram is constructed and artifact inaccuracy detection is achieved. The last is to perform the state combinations of artifacts in each control block according to its characteristic. Parallel Hazard and Branch Hazard are two noticeable artifact inaccuracy problems with control block; their detections are performed during combination of sub artifact-state transitions.
Extracting artifact-state transition here is a bottom-up style. It finds artifact-state transitions of each local block, and combines these artifact-state transitions according to their relative positions during workflow execution. The corresponding algorithms are presented one bye one where each algorithm handles a distinct workflow structure and inside the algorithm one artifact is considered only to prevent reciprocal effect between multiple artifacts.
5.1 A General Reduction Algorithm
Our artifact extraction algorithm constructs an artifact state diagram for each artifact to search the artifact inaccuracy in a primitive workflow schema. Due to the characteristics of primitive workflow schema, the input workflow schema is a sequence combination of un-blocked activities and top-level control blocks. Each atomic control block and each sequential block are reduced to corresponding composite activity nodes, and the reduction procedure can repeat bottom-up until there is no block left. During the reduction, artifact state tracing and validations both proceed. The bottom-up approach is done in a primitive workflow schema.
Algorithm 1. Validate a Primitive Workflow Schema – validate a primitive workflow schema by reducing it to one composite activity node and extracting the artifact-state transition to validate artifact accuracy.
StartNode = starting node of the input workflow schema;
EndNode = ending node of the input workflow schema;
ArtifactStateDiagram ASD = initializing artifact-state diagram;
TargetNode = Reduce_SequentialBlock(StartNode.next, EndNode.previous);
ASD = ExtractAST(TargetNode);
Trace ASD to search for No Producer, No Consumer, and Redundant Specify;
Output the artifact state diagram and artifact validation result;
Algorithm 1 processes the input primitive workflow schema, starting from Start Node and ending at End Node defined in Section 3.2, and output the produced artifact-state diagram and validation result. The input workflow schema is considered as a sequential block and proceeded by sub routine Reduce_SequentialBlock, describing in Algorithm 2 of Section 5.2. The output artifact-state diagram is the record of one artifact manipulating life cycle and meaningful for artifact analysis.
5.2 Reduction Algorithm for Sequential Block
In a sequential block, all activity nodes in this block are in sequential order. If the input schema contains a control block, this control block will be reduced as a composite activity node before reduction of the outer sequential block. Algorithm 2 describes algorithm Reduce_SequentialBlock. Reduce_SequentialBlock extracts artifact-state transitions from the nodes in the input block, connects them, create a composite activity node with the artifact-state transition, and replace the input block by this new created node.
Algorithm 2. Reduce_SequentialBlock(Node Ni, Node Nj) – reduce a sequential block, starting from Ni and ending at Nj, into a composite activity node and return it.
CurrentNode = Ni;
ArtifactStateTransition CurrentAST = initializing artifact-state transition;
WHILE ( CurrentNode is in the block (Ni, Nj) ) { IF ( CurrentNode.type == ActivityNode ) THEN // connect artifact-state transitions by sequential order
CurrentAST = Sequential_Join(CurrentAST, ExtractAST(CurrentNode));
CurrentNode = CurrentNode.next();
ELSE IF ( CurrentNode.type == LOOP-START ) THEN CurrentNode = Reduce_IterationControlBlock(CurrentNode);
ELSE IF ( CurrentNode.type == AND-SPLIT ) THEN CurrentNode = Reduce_ANDControlBlock(CurrentNode);
ELSE IF ( CurrentNode.type == XOR-SPLIT ) THEN CurrentNode = Reduce_XORControlBlock(CurrentNode);
}
Create a composite activity node Nij with CurrentAST;
Nij.previous = Ni.previous;
Nij.next = Nj.next;
RETURN Nij;
Extract_AST extracts artifact-state transition from an activity node and is defined in Algorithm 3. Sequential_Join called by Reduce_SequentialBlock is in charge of connecting two artifact-state transitions in sequential order, and its detail is described in Algorithm 4. Reduce_IterationControlBlock, Reduce_ANDControlBlock and Reduce_XORControlBlock reduce control blocks in the input block, and they will be introduced in following sections.
Algorithm 3. Extract_AST(ActivityNode Ni) – extract artifact-state transition from an activity node Ni
// a composite activity with an artifact-state diagram IF (Ni has an artifact-state transition bound in it) THEN RETURN the artifact-state transition;
// no artifact operation
IF (Ni has no operation on the artifact) THEN RETURN a null artifact-state transition;
// Read artifact operation
IF (the artifact operation of Ni is Read type) THEN
Create a pseudo in-state Si according to pre-condition of Ni;
Create a transition arc from Si to itself labeled as Read;
RETURN this artifact-state transition;
// other types of artifact operation
Create a pseudo in-state Si according to pre-condition of Ni;
Create an out-state Sj according to post-condition of Ni;
Connect Si and Sj with a transition arc labeled as the type of operation;
RETURE this artifact-state transition;
In Algorithm 3, there are four cases when Extract_AST is performed on the input activity node Ni:
1. Ni is a composite activity node reduced from a certain block and is associated with an artifact-state transition computed from reduction
algorithms. The artifact-state transition is returned directly.
2. Ni is an activity node with no operations on the artifact, and a null artifact-state transition is returned.
3. Ni is an activity node with Read operation on the artifact, and a transition of Read type is generated and returned.
4. Ni is an activity node with a not-Read operation, and an artifact-state transition is generated according to Pre-condition, Action, and Post-condition in the activity specification.
In case 1, the artifact-state transition might have multiple in-states (out-states) because it might be a combination of multiple artifact-state transitions of subflows inside the block. For an artifact-state transition with multiple in-states (out-states), each state of in-states (out-states) will be classified into four types:
1. Definite: this state is extracted from a composite activity node reduced from an XOR control block. Each Definite state might have Branch Hazard with other Definite state.
2. Potential: this state is extracted from a composite activity node reduced from an AND control block. Each Potential state might have Parallel Hazard with other Potential state.
3. Both of Definite and Potential: this state is propagated from AND and XOR control blocks. It might have Branch Hazard with other Definite state and Parallel Hazard with other Potential state.
4. Transparent: a transparent state is computed from an XOR control block to stand for a branch subflow which has no artifact state constrains or artifact operations.
These four classes of artifact state are useful in artifact-state joining and validation. More will be expressed in Algorithm 4 ,sections 5.4 and 5.5.
In Algorithm 4, Sequential_Join connects two artifact-state transitions in sequential order, and detects Artifact Inaccuracy. In this stage, Contradiction and Branch Hazard tests will be performed.
Algorithm 4. Sequential_Join(ArtifactStateTransition STi,
ArtifactStateTransition STj) – join two state transitions STi and STj.
IF ( STi == NULL ) THEN RETURN STj;
IF ( STj == NULL ) THEN RETURN STi;
Si := STi.out-state; Sj := STj.in-state;
SWITCH ( (|Si|,|Sj|) )
RETURN the joined artifact-state transition;
5.3 Reduction Algorithm for Iteration Control Block
An iteration control block is a block of nodes beginning from a Loop-Start and ending in a Loop-End. The procedure to transform an iteration control block into a composite activity node is listed in Algorithm 5. A new sequential block, created by unrolling the loop body twice, substitutes for the original iteration control block and then is processed by Reduce_SequentialBlock. The produced composite activity node is returned.
Algorithm 5. Reduce_IterationControlBlock(Node Ni) – reduce an iteration control block starting from Ni into a composite activity node and return it.
// locate the input iteration control block (Ni,Nj) CurrentNode = Ni.next();
Stack CNstack; // a stack to contain control nodes WHILE (1) {
IF ( CurrentNode.type == LOOP-START ) THEN
stack.push(CurrentNode); // nested iteration control block ELSE IF ( CurrentNode.type == LOOP-END ) THEN {
// for simulating iteration behavior
Unroll loop body of (Ni,Nj) twice into a new sequential block (ni',nj');
ni'.previous = Ni.previous;
nj'.next = Nj.next;
// perform sequential block reduction on (ni',nj') ActivityNode nij = Reduce_SequentialBlock(ni', nj') RETURN nij;
5.4 Reduction Algorithm for AND Control Block
AND control block is a workflow construction which starts from an AND-SPLIT, ends on an AND-JOIN, and has multiple concurrent subflows (paths). The most difference between AND control block and Sequential block is concurrent contradiction, which causes Parallel Hazard defined in Section 4.3.5. To validate each concurrent subflow and to merge these subflows into a composite activity are the major work in this stage.
Algorithm 6. Reduce_ANDControlBlock(Node Ni) – reduce an AND control block starting from Ni into a composite activity node and return it // locate the input AND control block (Ni,Nj)
CurrentNode = Ni.next();
// reduce these concurrent subflows, and join these concurrent state transitions ArtifactStateTransition CurrentAST = NULL;
FOR (each concurrent subflow (nk,nl) within block (Ni,Nj)) { ActivityNode SubNode = Reduce_SequentialBlock(nk, nl);
ArtifactStateTransition SubAST = ExtractAST(SubNode);
IF ( (SubAST != NULL ) THEN
CurrentAST = AND_Join(CurrentAST, SubAST);
}
// Continue above …
// check Parallel Hazard
IF ( ( | CurrentAST.out-state.Potential| > 1 ) ||
( | CurrentAST.in-state.Potential| > 1 ) ||
( multiple concurrent artifact operations exist) ) THEN Alarm Parallel Hazard;
// transform this AND control block into a composite activity Create a composite activity node Nij with CurrentAST;
Nij.previous = Ni.previous;
Nij.next = Nj.next;
RETURN Nij;
In Algorithm 6, there are four steps to reduce an AND control block: locating the input AND control block, reducing concurrent subflows, checking Parallel Hazard, and producing a composite activity node to substitute for the block. During reducing concurrent subflows, algorithm AND_Join is called for joining these concurrent artifact-state transitions.
Algorithm 7. AND_Join(STi,STj) – join two state transitions STi and STj, where STj is not null
// NULL Join
IF (STi == NULL) THEN RETURN STj;
// indicate in-state set and out-state set Si = STi.in-state; Ei = STi.out-state;
Sj = STj.in-state; Ej = STj.out-state;
// perform AND join calculation on STi and STj CurrentAST.in-state = Si☉Sj;
CurrentAST.out-state = Ei☉Ej;
// return the new state transition RETURN CurrentAST;
Algorithm 7 describes the AND_Join, which joins two input state transitions according to the characteristic of AND control block. The joining calculation function
☉ for AND_Join is defined in Definition 5.1.
For AND join calculation, the two input concurrent artifact-state transitions STi and STj are non-null. If there is only one state of in-state (out-state) of the input artifact-state transition, the state will be labeled as Potential state by default.
Definition 5.1 AND Join Calculation Function
For artifact-state transitions STi and STj, let α and β be the corresponding sets of in-states, and let γ and δ be sets the corresponding sets of out-states. To simplify the representation, we define AND join calculation with ☉ as follows.
α☉β= ＜α.D,α.P＞☉＜β.D,β.P＞
= ＜(α.D∪β.D), (α.P∪β.P∪α.D∪β.D)＞
γ☉δ= ＜γ.D,γ.P＞☉＜δ.D,δ.P＞
= ＜(γ.D∪δ.D), (γ.P∪δ.P∪γ.D∪δ.D)＞
where D is sets of Definite states and P is sets of Potential states.
Si∪Sj = Si + Sj – Si∩Sj
where∀s∈SiISj ,∃si∈Si,sj∈Sj,such that s ,siandsjarecompatoble
One special case is that the types of all concurrent operations are Read, and this control block will be considered as a composite activity with a Read operation. On the other hand, if there are multiple concurrent artifact-state transitions distributed in concurrent subflows, a Parallel Hazard might occur between these subflows.
5.5 Reduction Algorithm for XOR Control Block
An XOR control block is a workflow construction which starts from an XOR-SPLIT, ends at an XOR-JOIN, and it has multiple branch subflows. The major difference between XOR control block and AND control block is that the former has only one subflow will be selected to execute according to conditions of branch. It might lead to Branch Hazard defined in section 4.3.6. How to detect Branch Hazard and how to figure out in-state(s) and out-state(s) of the new composite activity are the major work in this section.
In Algorithm 8, there are four steps to reduce an XOR control block: locating the input XOR control block, reducing branch subflows, checking Branch Hazard, and producing a composite activity node to substitute for the block. During reducing Branch subflows, there are two parts different from algorithm Reduce_ANDControlBlock: inserting Transparent state to the current artifact-state transition if there is a NULL artifact-state transition and calling procedure XOR_Join to join these branch artifact-state transitions. The reason to insert a Transparent state, which is universally compatible to any artifact states outer of the current block, is to represent a branch path which will not impact the artifact-state transition.
Algorithm 9 describes procedure XOR_Join, which joins two input state transitions according to the characteristic of XOR control block. The joining calculation function for XOR_Join is defined in Definition 5.2.
In addition, all activity nodes with the XOR control block have no operation of the artifact, and this control block will be considered as a composite activity with no artifact operation.
Algorithm 8. Reduce_XORControlBlock(Node Ni) – reduce an XOR control block starting from Ni into a composite activity node and return it // locate the input XOR control block (Ni,Nj)
CurrentNode = Ni.next();
// reduce these branch subflows, and join these branch state transitions ArtifactStateTransition CurrentAST = NULL;
FOR (each branch subflow (nk,nl) within block (Ni,Nj)) { ActivityNode SubNode = Reduce_SequentialBlock(nk, nl);
ArtifactStateTransition SubAST = ExtractAST(SubNode);
IF ( (SubAST == NULL) ) THEN
CurrentAST.addState(TransparentState);
ELSE
CurrentAST = XOR_Join(CurrentAST, SubAST);
}
// check Branch Hazard
IF ( condition testing in the XOR-SPLIT node is not consistency with CurrentAST.in-states ) THEN
Alarm Branch Hazard;
// transform this XOR control block into a composite activity Create a composite activity node Nij with CurrentAST;
Nij.previous = Ni.previous;
Nij.next = Nj.next;
RETURN Nij;
Algorithm 9. XOR_Join(STi,STj) – join two state transitions STi and STj, where STj is non-null
// NULL Join
IF (STi == NULL) THEN RETURN STj;
IF (STi == NULL) THEN RETURN STj;