Three Layer Workflow Model - System Architecture

Chapter 3. System Architecture

3.1 Three Layer Workflow Model

To validate artifact accuracy on workflow specifications, we propose a simple type of workflow schema. This primitive workflow schema is reduced form well-formed workflow schema [15] and it can satisfy four primitive types of workflow structure defined in [1], which are "sequential", "parallel", "conditional branch", and "iterative structure". Besides, it is consider with: 1) the technique in [11]

2) representing artifacts the state transition diagrams with object-oriented techniques as in UML, 3) state joining for propagating artifact operations, 4) and state mapping for detecting artifact accuracy. Our model, on the view point of design, is named Three Layer Workflow Model (TLWM), as in Figure 3.1. TLWM represents workflow with three layers. A sample approach to designing methods applied in each layer is composed of workflow design, activity design and artifact design distinctly:

1. Workflow Design Layer: Describing the logistical control or execution order between activities, such as the sequence, choice, synchronization, and iteration… etc.

2. Activity Design Layer: Arranging artifact operations to be executed in an activity and conditions at the initialization and completion of the activity.

3. Artifact Design Layer: Defining the classes of artifacts, and all valid methods/operations of each artifact class.

Figure 3.1 Three Layer Workflow Model

.2 Workflow Design Layer

In Workflow Design Layer, a workflow model is used to describe a workflow sche

ma as the product of workflow design layer, based on the concept of well-formed workflow [15] to describe workflow schemas. The product of this layer is a workflow specification, and it is designed to describe the dependence between activities, i.e. the execution order of activities in a workflow. Control structures of a workflow form the execution order of the activities in the workflow. The four primitive control structures defined in [1] are "sequential", "parallel", "conditional branch", and "iterative structure".

In this thesis, a workflow specification is specified in a primitive workflow schema in Definition 3.2, which is constructed with control and activity nodes according to certain syntax rules. The basic unit of works is an activity, and it has pre-condition (entry criteria), post-condition (exit criteria), and activities with artifact operations, resource manipulations…, etc. An activity is usually called an activity node in contrast to a control node. Control nodes are used for constructing the

control structures, and there are four types of primitive control nodes in our thesis:

AND-SPLIT (AS), AND-JOINT (AJ), XOR-SPLIT (XS), XOR-JOINT (XJ) and LOOP. The connection between two nodes is flow, which indicates a transition from one node to another.

Figure 3.2 Notations in Workflow Diagram

Figure 3.2 shows the corresponding notations of control nodes, activity node, and flow. In addition, LOOP control node has two subtypes, LOOP-START and LOOP-END. The former indicates the start point of iteration, and the latter indicates the termination. The notation of a flow is a line with one arrow. The direction of an arrow implies the execution order. An activity node has only one inflow and one outflow, and a control node might have multiple inflows or outflows. Finally Start

node and End node take responsibility for initializing and finalizing a whole workflow.

Our workflow schema is represented with a set of nodes and directed edges, standing for the flow between nodes. It begins from Start node and terminates with End node. The intermediary nodes are arranged with workflow control structures. We define a primitive workflow model for discussing in this thesis.

Definition 3.1 Control Block

Any subflow in a workflow schema that satisfies the following conditions is called a control block.

1. A subflow begins from one control node and terminates at another corresponding control node.

2. There are only one inflow (entrance) and outflow (exit) for this subflow.

3. A subflow is either completely contained in another subflow or not contained in any other subflow.

In Definition 3.1, condition 1 constrains that leading control node and ending control node of a control block are paired, such as AND-SPLIT and AND-JOINT, XOR-SPLIT and XOR-JOINT, LOOP-START and LOOP-END. Condition 2 localizes a control block as a closed subflow. Condition 3 eliminates the possibility of subflow interleavings. For example, there are two control blocks A and B. Control block A contains a set of nodes denoted by α , and control block B contains a set of nodes denoted by β. In our model, there are exactly four possible relations between α and β.

1. β ⊂ : A completely contains B, and A is super-block of B. α 2. α ⊂ : B completely contains A, and A is sub-block of B. β

3. α Iβ =φ: Control block A and B do not overlap with each other.

4. α = : Control block A and B are identical. β

If a control block does not contain any other control block, it is called an atomic control block. Otherwise, it is called a nested control block. If an activity node is

not contained in any control block, it is called an un-blocked activity. A control block is called a top-level control block if it is not contained in any other control block.

Definition 3.2 Primitive Workflow Schema

A workflow schema built by a set of un-blocked activities nodes and top-level control blocks is called a primitive workflow schema.

According to definitions mentioned above, we conclude four types of workflow construction in our primitive workflow schema as follows.

1. Sequential Block: The activities in this block are executed in sequence under a single thread of executions. There is no control node or conditional branch between these activities. The main characteristic is that the target activity will execute after its preceding activity completes. In other words, the completion of a target activity triggers the execution of its succeeding activity.

2. Iteration Control Block: The activities within the control block grouped by loop control nodes will be executed repetitively until certain conditions are met.

3. AND Control Block: All outflows of an AND-SPLIT node are executed parallel and converge synchronously into an AND-JOIN node. An AND-JOIN node takes charge of synchronizing all threads from parallel inflows into the thread.

4. XOR (eXclusive OR) Control Block: An XOR-SPLIT node makes a decision upon which branches to take from multiple alternative outflows (workflow branches). And these branches converge to a single XOR-JOIN node. There is no

synchronization required because of no parallel thread executed.

Figure 3.3 Four Types of Workflow Construction in a Primitive Workflow Schema Figure 3.3 shows four types of workflow construction, and these workflow constructions can contribute to construct a primitive workflow schema. In addition, we use the notation (leading node, ending node) to indicate a block, starting from the leading node and terminating at ending node, in following sections.

3.3 Activity Design Layer

Activity specifications are anticipative products of this layer. Each activity has its own activity specification, which describes the operations associated with artifacts to perform to achieve the goal. Besides the manipulations of artifacts, there are also pre-condition and post-condition (optional) to be defined. The format of activity specifications are shown in Figure 3.4.

An activity is the smallest unit of work in workflow, and it performs a set of operations on certain artifacts to achieve its designed goal. All operations of an artifact which performs must be specified in the corresponding artifact specifications.

Besides, each activity may be designed with pre-condition and post-condition if

necessary. Artifact(s) acted on and/or concerned in pre-condition/post-condition in this activity will be retrieved to contribute to artifact analysis and validation.

ACTIVITY_NAME{

PRE-CONDITION:

//A logical expression evaluated by a workflow engine //to decide if this activity instance may be started or not.

//It may refer to certain artifact to check the current state of artifact.

ACTION:

//A sequence of operations performed on artifacts to achieve a goal.

ARTIFACT_NAME.OPERATION_NAME(PARAMETER_LIST);

POST_CONDITION:

//A logical expression evaluated by a workflow engine

//to decide if this activity instance is completed or terminated by failure.

//It may refer to certain artifact or external events etc.

}

Figure 3.4 Script of Activity Specification 3.4 Artifact Design layer

Artifact design layer is the bottom layer, and its contents are artifact specifications. All artifacts participating in a workflow execution must be pre-defined in artifact specifications. For each artifact, its specification contains a set of operations for legally manipulating on its internal data. An activity designed to manipulate a certain artifact can only performs these operations to interact with this artifact.

The main concept of artifact design layer is to make the internal design of artifacts independent from the workflow application. That brings following profits:

z An artifact has a set of interfaces, representing the operations on the artifact.

Modifications on implementing these operations will not impact the upper layer design if the format to invoke these operations keeps steady.

z The artifact manipulations in activities or workflows are bound in these (designed) specifications. Illegal or invalid operation on artifacts is not allowed.

It can also provide an implementation platform for authentication, and that is our future work.

z Independent designing of artifact operations facilitates classifying and grouping types of artifact operations. And it also provides an easier way to extract useful information of artifact operations in workflow execution.

Figure 3.5 shows format of an artifact specification.

ARTIFACT "ARTIFACT_NAME"

INTERNAL:

//Declare internal data, data source or destination OPERATION:

RETURN_TYPE OPERATIPON_NAME (ARTUMENT_LIST) { //Code for artifact manipulations

}

Figure 3.5 Script of Artifact Specification

Chapter 4. Artifacts

In this chapter, we will discuss the concept of artifact, artifact state diagram, state transition, and artifact inaccuracy and the corresponding outcomes.

4.1 Overview of Artifacts

An artifact describes any the data participating in workflow execution no matter its type is input, output, temporal or permanent. Moreover, it can be extended by combining some processing logic if necessary, such as e-form in AgentFlow [17]. An artifact can represent workflow control data, workflow relevant data, application data [18], electronic document, manual data, and every data item participating in workflow execution. In this thesis, we reduce the description power of artifacts, and focus on the artifacts visible in workflow specification (schema) by TLWM introduced in chapter 3.

Artifacts can be divided into five types:

1. Reference (Ri): A reference artifact in workflow is like the static variable or constant in programming language. It is rarely modified after initializing, and acts as an index of a certain instance or case. For example, the serial number of an official document, the number of identification card, etc.

2. Manipulation (Mi): A manipulation artifact acts as the processing target in/among activities. It can be an input, output, or processing results of an activity.

For example, the name of last editor, the total amount of goods, the population statistic…, etc.

3. Deterministic (Di): A deterministic artifact acts as the key condition result evaluated. It participates in the branch of control nodes (parallel, choice,

Iteration…, etc.), and conditional constrains in activity (pre-condition, post-condition, processing logic…, etc.). For example, the credit gained (if the credit gained is less then 24, the student is not allowed to apply for graduation.), department, or major…, etc.

4. Composite (Ci): A composite artifact is a composition of sub-artifacts. For example, an application form, an official document, a business contract…, etc.

5. Property (Pi): A property artifact is used to control process or the workflow execution and not accessible during application design. For example, state information about each workflow instance, dynamic state of workflow system, execution duration, or resource constrains, etc.

The classification of artifacts in type is neither absolute nor exclusive. Some artifacts are Mi and also are Di. In this thesis, we would not emphasize the type of artifacts discussed. The behavior and effect of artifact operations is the key interested.

Although the types of artifacts are not mentioned clearly here, the range of artifacts approximately contains Ri∪Mi∪Di∪Ci.

In general, the whole workflow is the scope of artifacts, including workflow engine, workflow instance, invoked application…, etc. However, in this thesis, we diminish the scope and only focus on artifact appearing in activities and workflow specification.

We group common operations of artifact into five types, which are Specify, Read, Write, Revise and Destroy.

1. Specify: an initialization activity of artifact, such as "fill in", "create", "define"…, etc.

2. Read: a reference to artifact, such as "use", "fetch", "select", "retrieve"…, etc.

3. Write: an artifact modification, such as "write", "change", "update"…, etc.

4. Revise: addition/deletion of a sub-artifact, such as merge, combine, divide…, etc.

5. Destroy: deletion of artifact, such as remove, erase, cancel, discard, etc.

4.2 Artifact State Diagrams

Generally, process design and flow design settle major part of workflow design, but the artifact design does not usually. Here we define a method based on state transition technique to model both behavior changes and state transitions of an artifact during workflow execution. There are five primitive operations, introduced in Section 4.1 for triggering artifact-state transition.

Start Specified.

Figure 4.1 An Example of an Artifact State Diagram

There is an example demonstrated in Figure 4.1; it shows the life cycle of an artifact during workflow execution. During its life time, the artifact is specified by activity A1, read by A2, written by A3, read by A4, revised by A5, read by A6 and finally destroyed by A7. Furthermore, this artifact state diagram implies one

reasonable execution order of these activities.

Definition 4.1 shows definition of artifact state diagram discussed in this thesis.

Definition 4.1 Artifact State Diagram

Artifact state diagram is 5-tuple ＜Q, O, T, q0, F＞

z Q: a finite set of states s1, s2… si, for i ≧1

z O: an input operation of artifact. O = [Specify | Read | Write | Revise | Destroy].

z T: transition function Q × O Æ Q z q0: start state or initial state z F: a set of final states, F ⊆ Q

The artifact state diagram is constructed by two components, state (circle) and transition (arc with arrow). The first transition starts from initial state q0 by default.

There are some criteria for drawing artifact state diagram as follows.

1. ⁱ ⁱ ^j ^j

p

ⁱ

s

ⁱ

Criterion 1 tells that every state has at least one input operation to trigger transition from itself to next state. Criterion 2 emphasizes that a transition transfers from one state to the same state if the type of input operation is Read. Criterion 3 indicates the input order of operations. There are two transitions among s_i, s_j, and s_k. And pi and pj are input operations for these transitions. We can conclude that operation p_i is performed before p_j in workflow execution order, and notation indicates a temporal relation between operations.

We will use artifact state diagram mentioned in this chapter to trace the artifact transition between activities within workflow schema and to validate artifact accuracy.

4.3 Artifact Inaccuracy

Inappropriate operations on artifact might lead the workflow (execution) into failure or cause illegal side effects. In this section, we point out the abnormal situations of artifact operations and discuss the potential problems they may bring.

We infer six types of artifact inaccuracy from cases observed. They are No Producer, No Consumer, Redundant Specify, Contradiction, Parallel Hazard and Branch Hazard.

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

在文檔中使用狀態圖在工作流程規格上進行定義Artifacts確認 (頁 16-0)