Detecting artifact anomalies in business process specifications with a formal model
Ching-Huey Wang
*, Feng-Jian Wang
Institute of Computer Science and Engineering, College of Computer Science, National Chiao Tung University, Room 510, EC Building, 1001 Ta-Hsueh Road, Hsinchu City, Taiwan, ROC
a r t i c l e
i n f o
Article history:
Available online 5 April 2009 Keywords: Workflow Business process Analysis Control flow Data flow Artifact Anomaly
a b s t r a c t
Many business process analysis models have been proposed, however there are few discussions for arti-fact usages in workflow specifications. A well-structured business process with sufficient resources might fail or yield unexpected results dynamically due to inaccurate artifact specification, e.g. an inconsistency between artifact and control flow, or contradictions between artifact operations. This paper, based on our previous work, presents a model for describing the input/output of a workflow process and analyzes the artifact usages upon the model. This work identifies and formulates thirteen cases of artifact usage anom-alies affecting process execution and categorizes the cases into three types. Moreover, the methods for detecting these anomalies with time complexities O(n2), less than O(n3) in previous methods, are
pre-sented. Besides, the paper uses an example to demonstrate the processing of them.
2009 Elsevier Inc. All rights reserved.
1. Introduction
A workflow is seemingly a set of interrelated tasks systematized to achieve certain business goals by accomplishing each task in a
particular order under automatic control (The Workflow
Manage-ment Coalition, 1995). Workflow implementation requires re-sources for supporting process execution. Resource allocation and resource constraint analysis (Senkul and Toroslu, 2005; Li et al., 2004; Liu et al., 2003; Du and Shan, 1999; Muehlen, 1999) are pop-ular workflow research topics. However, data flow within work-flow is seldom addressed (Sadiq et al., 2004; Sun and Zhao, 2004; Sun et al., 2004, 2006).
An artifact is a data instance within a workflow. Introducing artifact usage analysis into (control-oriented) workflow designs can help maintain consistency between execution order and data transition (Sadiq et al., 2004; Sun and Zhao, 2004; Sun et al., 2004, 2006), as well as prevents exceptions due to contradiction between data flow and control flow. In contrast to structural cor-rectness, accuracy in artifact manipulation helps determine whether the execution result of a workflow is meaningful and desirable. Our earlier work (Hsu, 2005; Wang et al., 2006; Hsu and Wang, 2007) introduced the artifact usage analysis into work-flow design phase and identified preliminary improper artifact usages affecting workflow execution.
This paper proposes a process model for describing the input/ output of business processes and addresses three types of artifact usage anomalies. The model is based on component-based design technique (Zhuge, 2003; Hitomi and Le, 1998) and is compatible
with existing control-oriented workflow design models. It provides an easier way to extract knowledge of artifact usages in a work-flow. With the model, an analysis procedure of artifact usage is ap-plied before deploying the workflow schema. On the other hand, the checking between data flow and control flow and the informa-tion of manipulating artifacts can be applied stepwise along with the specification process. An example demonstrating the contribu-tion of our work and a comparison among related works and ours is also presented.
The remainder of this paper is organized as follows. Section2
presents the research background and related works. Section3 pre-sents our process model, including the control flow and artifact flow. There are thirteen cases of artifact usage anomalies identified and then categorized into three types in Section4. In Section5, we present a method for detecting each type of anomalies. A compar-ison between our approach and some related works is given in Sec-tion6. Finally, a conclusion and some recommendations of future work are given in Section7.
2. Related work and background 2.1. Analysis in workflow specification
A workflow can be deemed as a collection of cooperating and coordinated activities designed to carry out a well-defined com-plex process, such as a trip planning, conference registration proce-dure, or business process in an enterprise. In addition, the technology is adopted further in developing service-oriented archi-tecture in the last decade (Yau et al., 2008, 2007). A workflow mod-el describes a workflow in terms of various mod-elements, such as roles and resources, tools and applications, activities, and data, which 0164-1212/$ - see front matter 2009 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2009.03.077 *Corresponding author.
E-mail address:[email protected](C.-H. Wang).
Contents lists available atScienceDirect
The Journal of Systems and Software
represent different perspectives of a workflow (Curtis et al., 1992; Jablonski and Bussler, 1996). Roles and resource elements repre-sent organizational perspective that describes the performers of the tasks instantiated. Tools and application elements represent operational perspectives by specifying what tools and applications are used to execute a particular task. Activity elements are defined with two perspectives: (1) functional: what tasks a workflow per-forms; and (2) behavioral: when and how tasks are performed. Data elements represent the informational perspective, i.e., what information entities are produced or manipulated in corresponding workflow activities.
A well-defined workflow model leads to efficient development of an effective and reliable workflow application. Correctness is-sues in a workflow might be classified into three dimensions: con-trol-flow, resource, and data-flow. Generally, the analyses in control-flow dimension are focused on correctness issues of con-trol structure in a workflow. Common concon-trol-flow anomalies in-clude deadlock, livelock (infinite loop), lack of synchronization, and dangling reference (Karamanolis et al., 2000a; van der Aalst, 1998a, 1997, 1998b; van der Aalst and ter Hofstede, 2000; van der Aalst et al., 2000a,b, 2003; van der Aalst and Basten, 2002; Ver-beek and van der Aalst, 2000; Karamanolis et al., 2000b; VerVer-beek et al., 2001). For example, a deadlock anomaly occurs if it is no longer possible to make any progress for a workflow instance, e.g. synchronization on two mutually exclusive alternative paths.
Activities belonging to different workflows or parallel activities in the same workflow might access the same resources. A resource conflict occurs when these activities execute over the same time interval. Thus, the analyses in resource dimension include identifi-cation of resource conflicts under resource alloidentifi-cation constraints and/or under temporal and/or causality constraints (Senkul and Toroslu, 2005; Li et al., 2004; Liu et al., 2003; Du and Shan, 1999; Muehlen, 1999). On the other hand, missing, redundancy, and con-flict use of data are common anomalies in data-flow dimension (Sadiq et al., 2004; Sun and Zhao, 2004; Sun et al., 2004, 2006). A missing data anomaly occurs when an artifact is accessed before it is initialized. A redundant data anomaly occurs when an activity produces an intermediate data output but this data is not required by any succeeding activity. A conflicting data anomaly represents different versions of the same artifact.
Current workflow modeling and analyzing paradigms mainly focus on soundness of control logic, i.e., in the control-flow dimen-sion, including process model analysis (van der Aalst and ter Hof-stede, 2000; van der Aalst et al., 2000a,b, 2003; van der Aalst, 1997, 1998b; van der Aalst and Basten, 2002; Verbeek and van der Aalst, 2000; Karamanolis et al., 2000b; Verbeek et al., 2001; Gong and Wang, 2004; Sadiq and Orlowska, 2000), workflow pat-terns (van der Aalst et al., 2000a,b, 2003; van der Aalst, 1997, 1998b; van der Aalst and Basten, 2002; Verbeek and van der Aalst, 2000; Karamanolis et al., 2000b; Verbeek et al., 2001; Gong and Wang, 2004; Sadiq and Orlowska, 2000, 1997, 1999; Russell et al., 2004) and automatic control of workflow process (Bae et al., 2004). Aalst and ter Hofstedevan der Aalst and ter Hofstede (2000)proposed a WorkFlow net (WF-net), based on Petri nets, to model a workflow: transitions representing activities, places repre-senting conditions, tokens reprerepre-senting cases, and directed arcs
connecting transitions and places. Son and Kim (2005)defined a
well-formed workflow based on closure and control block con-cepts. He claimed that a well-formed workflow is free from struc-tural errors, and that complex control flows can be made with nested control blocks.Sadiq and Orlowska (2000)proposed a visual verification approach and algorithm with a set of graph reduction rules to discover structural conflicts in process models for given workflow modeling languages.
There are several research topics discussed in resource dimen-sion, including resource allocation constraints (Senkul and Toroslu, 2005; Li et al., 2004), resource availability (Liu et al., 2003),
re-source management (Du and Shan, 1999) and resource modeling
(Muehlen, 1999). SenkulSenkul and Toroslu (2005)developed an architecture to model and schedule workflow with resource alloca-tion constraints and tradialloca-tional temporal/causality constraints.Li et al. (2004) concluded that a correct workflow specification should have resource consistence and provided a series of detec-tion algorithms. Both Pinar and Hongchen extended workflow specifications with constraint descriptions.Liu et al. (2003) pro-posed a three-level bottom-up workflow design method to effec-tively incorporate confirmation and compensation in case of failure.
There was little attention paid to the data-flow dimension, although related analysis in the data-flow dimension is very important since activities cannot be executed properly without sufficient data information. For example,Sadiq et al. (2004) identi-fied and justiidenti-fied the importance of data modeling in the overall workflow design process. In addition, data-flow validation issues and essential requirements of data-flow modeling in workflow specifications are identified. They illustrated and defined seven ba-sic data validation problems: redundant data, lost data, missing data, mismatched data, inconsistent data, misdirected data, and insufficient data. However, Sadiq worked only on the conceptual level and thus, neither concrete data-flow model nor detecting algorithms are proposed. Furthermore, operations on data are only classified into read and write type.
Sun and Zhao (2004), Sun et al. (2004, 2006)formulate the data-flow perspective by means of dependency analysis. The data-data-flow matrix and an extension of the unified modeling language (UML) activity diagram are proposed to specify the data flow in a business process. Then, three basic types of data-flow anomalies, missing data, redundant data, and conflicting data, were defined. Based on the dependency analysis, algorithms to data-flow analysis for discovering the data-flow anomalies are presented and execute in O(n3) time. However, as in Sun’s work, there is no explicit model
proposed to characterize data behaviors. Also, the operation types are considered only with read and initial write.
Our previous work (Hsu and Wang, 2007) was concerned with
five different types of operations, read, write, specify, destroy and revise, but the behaviors of an artifact are not explicitly modeled by a finite state machine. The three-layer workflow model is pro-posed for constructing state transition diagrams of each flow struc-ture to detect inaccurate artifact usage. Detection algorithms are designed based on critical paths for discover the inaccurate state transition of an artifact. However, the time complexity of the algo-rithms is O(n3).Table 2.1summaries the comparisons.
Table 2.1
Summary of comparisons.
Sadiq et al. Sun et al. Our previous approach
Process model Conceptual level Data-flow matrices process data diagram Three-layer workflow model State transition diagram
Operations concerned Read, write Read, write Read, write, specify, destroy, revise
Detecting method N/A Data dependency analysis Artifact usage analysis
Concrete algorithm N/A Yes Yes
Complexity N/A O(n3
) O(n3
2.2. BPEL, BPMN and loop-simplification
BPEL is one of the most popular workflow languages. In BPEL (Alves et al., 2007), the control structures, proposed to indicate the order where the individual activities are executed, include ‘‘sequential processing” (Sequence), ‘‘repetitive execution” (While and RepeatUtil), ‘‘parallel processing” (Flow), ‘‘exclusive branches” (If and Pick) and ‘‘inclusive branches” (OR and Complex). All types of business processes can be defined by nesting and/or combining the five structures in arbitrary ways (White, 2008).
BPMN (White, 2008) is a solution to represent the business pro-cess in a graph. The elements defined in BPMN are classified into sequence flow and object. A sequence flow links two objects to show the execution order. An object can be an event, a task or a gateway. An event may signal the start (start event), the end (end event) of a process, a message that arrives or a specific time-date being reached during a process (intermediate message/timer event). A task is an atomic activity and stands for the work to be performed with-in a process. A gateway is a routwith-ing construct used to control the divergence and convergence of sequence flow. For a set of parallel sequences, a parallel fork/join gateway creates/synchronizes concurrent sequence flows. For a set of exclusive sequences, a data/event-based XOR decision/merge gateway selects one from/ joins a set of mutually exclusive sequence flows. The selection is based on either the process data (data-based) or external event (event-based). Besides, there are two pairwise OR and complex
gateways: OR decision gateway, OR merge gateway, complex decision gateway and complex merge gateway, their functions can be re-placed by combining and/or nesting two or more gateways indi-cated above.
Ouyang et al. (2006)asserts that the control structures can be represented with BPEL or BPMN in patterns; moreover, the well-structured components representing these patterns with BPMN
are proposed.Fig. 2.1shows examples depicted with BPMN in a
well form. In the exclusive branch structures (c) and (d), no matter which succeeding sequence flow is selected (due to the data prop-agated from its preceding activities in (c) or an event signaled for a notification in (d)), the data propagation mechanisms of both cases are the same in an implicit data flow model (Sadiq et al., 2004). A data exchange between activities is done through global vari-able(s) stored in a common database. However, the analysis in an iteration is not well concerned.
The set of gateways defined in BPMN is not intended to be min-imal (White, 2008). The semantics of one structure might be imple-mented with other structure(s). To simplify the discussion, this paper minimizes the set of gateways by excluding the ones whose functions are replaceable. In addition, the elements defined in a general model, e.g. BPMN or BPEL, which do not support the anal-ysis of artifact usage, are omitted in our model. For example, the event object of BPMN determining the succeeding flow does not af-fect the design of data propagation mechanism, it is not concerned here.
3. Process modeling
3.1. Basic concept of loop reduction
Our major concern is to find artifact usage anomalies and re-duce the computation time. The basic concept of loop reduction is to transform a loop into an XOR structure. The condition(s) of a RepeatUntil structure R is evaluated after each iteration but that of a While structure W is done before each iteration. Obviously, the least time k of RepeatUntil(R)/While(W) execution is 1/0 if the evaluation result in R/W is not concerned. An artifact can be asso-ciated with a state representing the latest activity on the artifact (Hsu and Wang, 2007). For iteration times k > 2, all the possible state variations of the artifacts operated are the same as those for iterations k = 2. Therefore, the state variations in a loop can be grouped according to k. For R, there are two groups of state vari-ations. The first group is for k = 1 and the second one is for k P 2. For W, besides above two groups, there is a group for k = 0.
Each above group of operation(s) can be translated into a se-quence flow (of operations). The R and W can be represented with corresponding XOR gateways and the flows in order to analyze the abnormal behaviors due to these operations. The XOR structures for the loops shown inFig. 2.1e and f are presented inFig. 3.1a and b, correspondingly.
3.2. Process specifications
A process consists of a network of activities designed to produce a product or service for a particular customer or market. A process specification, a formalized view of a business process, defines a set of linked (parallel and/or sequential) activities associated with clear defined inputs and outputs respectively. Each activity takes a subset of the process input(s) or the output(s) of its previous activity(ies) and transforms them into data for later use or as pro-cess outputs. These data are called artifacts. Thus, a propro-cess speci-fication contains not only the control flow but also the artifact flow inside the business process. Here, we give a formal definition of process with these two parts in Definition 3.1.
Definition 3.1. A process specification is a tuple BP = (G, VT, D, IW, OW), where
– G = (V, E), representing the control flow, is a directed and acyclic graph, where V is a set of vertices of which each represents an activity and E V V is a set of directed edges indicating the precedence relation between two activities.
– VT : V ? T is a type function that maps each activity into one of the activity types in T, where
T ¼ fTask; SubProcess; ProcessStart; ProcessEnd; AndSplit; AndJoin; XorSplit; XorJoing:
The activities whose types are Task are called task activities while the others are called control activities.
– D is a set of artifacts used in the process.
– IW D, a subset of D, denotes the set of process inputs.
– OW D, a subset of D, denotes the set of process outputs.
3.3. Control flow specification 3.3.1. Activities and control blocks
An activity in a business process might be atomic or non-atomic (compound). An atomic activity is an indecomposable unit of work that is scheduled by a workflow engine. A sub-process activity within a process represents a compound activity. The function-based classification of atomic activities divides these activities into two groups: Task and control. A task activity is defined as making some function progress provided from its associated business pro-cess. Three pairs of control activities can be defined to bound a group of activities: (1) ProcessStart and ProcessEnd, (2) AndSplit and AndJoin and (3). XorSplit and XorJoin. Each pair and the activ-ities bounded by them are named as a control block. Notations for activities in BPMN (White, 2008) are partially adopted and shown inFig. 3.2.
Three control structures ‘‘sequential”, ‘‘parallel branch” and ‘‘conditional branch” are constructed from typed activities and their precedence relations, as the figures shown inFig. 3.3. These structures are used in analyzing the artifact usages. In this paper, the three structures are implemented with Sequential, AND Control and XOR Control Block, respectively. Statements of the four imple-mentations are given below:
Sequential block: Activities within this structure are executed sequentially. Serial activities are fired while completing their preceding activities. Succeeding activities are triggered after their execution.
AND control block: An AndSplit activity connects with more than one outflow. All outflows of the AndSplit activity execute cur-rently. These outflow executions merge synchronously into one on AndJoin activity.
XOR (eXclusive OR) control block: An XorSplit activity connects with more than one outflow, called branches. The evaluation result of the XorSplit activity decides one of the outflows to con-tinue. After execution, these branches converge on an XorJoin activity. No synchronization is required since there is only one thread chosen for execution.
The control flow G = (V, E) of a process specification is well-formed if the following constraints hold:
– G has a unique vertex
v
of type ProcessStart, which has no incom-ing edge and one outgoincom-ing edge.$!v : VT(
v
) = ProcessStart ? InDegree(v
) = 0 ^ OutDegree(v
) = 1. – G has a unique ProcessEnd vertexv
of type ProcessEnd, which hasone incoming edge and no outgoing edge.
$!v : VT(
v
) = ProcessEnd ? InDegree(v
) = 1 ^ OutDegree(v
) = 0. – Vertices of type AndSplit and XorSplit have one incoming edgeand more than one outgoing edge.
"v : (VT(
v
) = AndSplit _ XorSplit) ? InDegree(v
) = 1 ^ OutDegree(v
) > 1.– Vertices of type AndJoin and XorJoin have more than one incom-ing edge and one outgoincom-ing edge.
"v 2 (VT(
v
) = AndJoin _ XorJoin) ? InDegree(v
) > 1 ^ OutDe-gree(v
) = 1.– Any two control blocks can be nested but not overlapped. A typed control block b is denoted with a startVertex and an
endVertex. The two vertices corresponds to a pair of control activities defined in Section3.3.1.
8
b1¼ ½v
i;v
j; b2¼ ½v
x;v
y;b1–b2! b1 b2_ b2 b1_ b1\ b2¼ ;:
3.3.2. Relations among activities and control blocks
In this session, relations among activities and control blocks are identified as follows.
Definition 3.2 (Paths). A path from
v
1 tov
k is a sequence ofvertices h
v
1, . . . ,v
ki in a control graph G = (V, E) such that each nodeis connected to the next vertex in the sequence i.e., the edges (
v
i,v
i+1) for i = 1, 2, . . . , k 1 are in the edge set E. The path fromv
1tov
kis denoted by Path(v
1, vk).Definition 3.3 (Reachability). Given two vertices u and
v
, IsReach-able(u,v
) is a Boolean function that indicates whether there is a path from u tov
.8
u;v
2 V; IsReachableðu;v
Þ ¼ true $ 9Pathðu;v
Þ _ u ¼v
:Definition 3.4 (Predecessors and successors).
VIsPredecessor
v ¼ u 2 Vjðu;f
v
Þ 2 Eg;VIsPredecessorv ¼ t 2 Vjt 2 VIsPredecessorv _ 9u 2 VIsPredecessorv :t 2 VIsPredecessoru
n o ; VIsSuccessor v ¼ fu 2 Vjð
v
;uÞ 2 Eg; VIsSuccessorv ¼ t 2 Vjt 2 VIsSuccessorv _ 9u 2 VIsSuccessorv :t 2 VIsSuccessoru
n o
;
VIsPredecessor
v comprises the set of vertices which are the source of an
edge with destination vertex
v
2 V. Each element u in VIsPredecessorv is called a direct predecessor of the vertex and is denoted by u ?v
. VIsPredecessorv denotes the transitive closure of VIsPredecessorv . 8u 2 VIsPredecessorv ,
v
is reachable from u. Each element u in VIsPredecessorv is called a predecessor ofv
and is denoted by uv
. VIsSuccessorv and its
transitive closure VIsSuccessor
v are defined similarly.
Definition 3.5 (Ancestor blocks and level of an activity). "v 2 V, let v.PB denote the parent control block containing
v
. AncestorBlock comprises the set of all control blocks that containv
AncestorBlockð
v
Þ¼ fbjb ¼
v
:PB _ ðb 2 AncestorBlockðv
:PB:startVertexÞÞg:In addition, the cardinality of AncestorBlockð
v
Þ identifies the nested level ofv
Lev
elðv
Þ ¼ AncestorBlockðv
Þ ifv
2 V; AncestorBlockðv
:StartVertexÞif
v
represents a control block:8 > > > < > > > :
Definition 3.6 (Common ancestor blocks and nearest common ances-tor blocks). Given a set of vertices,
v
1, . . . ,v
n, Biis a common ancestorblock of
v
1, . . . ,v
nif and only if the following holds:Bi 2\
n
i¼1
AncestorBlockð
v
iÞ; denoted by Bi 2 CABðv
1; . . . ;v
nÞ:Biis the Nearest common ancestor of
v
1, . . . ,v
nif and only if thefol-lowing holds:
8
Bj 2 CABðv
1; . . . ;v
nÞ ^ Bj – Bi : Lev
elðBjÞ<Le
v
elðBiÞ; denoted by NCABðv
1; . . . ;v
nÞ ¼ Bi:Definition 3.7 (Parallel activities). Given two vertices, u and
v
, IsParallel(u,v
) is a Boolean function to represent if u andv
might be executed in parallel within a workflow instance.IsParallelðu;
v
Þ ¼ true () NCABðu;v
Þ:Type¼ \AND" ^ qIsReachableðu;
v
Þ ^ qIsReachableðv
;uÞ:IsParallel(u,
v
) = true, denoted as uv
, indicates that u andv
might be executed in parallel andv
is called a parallel activity of u. Definition 3.8 (Exclusive activities). Given two vertices, u andv
,IsExclusive(u,
v
) is a Boolean function to represent some XORcharacteristics of u and
v
. Within a workflow instance, if u will not be selected for execution,v
is selected for execution and vice versaIsExclusi
v
eðu;v
Þ ¼ true () NCABðu;v
Þ:Type¼ \XOR" ^ qIsReachableðu;
v
Þ ^ qIsReachableðv
;uÞ;IsExclusive(u,
v
) = true, denoted as uv
, indicates that at most one of u andv
can be selected for execution andv
is called an exclusive activity of u.Definition 3.9 (Companion activities). Given two vertices, u and
v
, IsCompanion(u,v
) is a Boolean function which indicates whether both u andv
are selected for computationIsCompanionðu;
v
Þ ¼ true ^ Lev
elðuÞ – Lev
elðv
Þ ()8
b2 AncestorBlockðuÞ [ AncestorBlockð
v
Þn CABðu;
v
Þ : b:type ¼ \AND";IsCompanionðu;
v
Þ ¼ true ^ Lev
elðuÞ ¼ Lev
elðv
Þ ()8
b2 fNCABðu;
v
Þg : b:type ¼ \AND";IsCompanion(u,
v
) = true, denoted as uv
, indicates that neither or both of them are selected for execution.v
is called a companion activity of u.3.4. Artifact flow specification
Currently, as identified inSadiq et al. (2004), there are three major implementation models for artifact flow: explicit data flow, implicit data flow through control flow, and implicit data flow through a process data store. This paper adopts implicit data flow model through a common process data store. Artifact exchanges between tasks are done through global variables stored in a com-mon database. In a workflow, some activities store their output artifacts in the database, and their following activities may access these artifacts later. The activities in our model are regarded as black boxes, i.e., neither the internal computations nor intermedi-ate execution stintermedi-ates are visible for each activity. Thus, the artifact usages of an activity are identified as the inputs/outputs of the activity.
3.4.1. Artifacts and artifact operations
Artifacts are the information entities involved in a process, including the input data to the process, the intermediate data duced within the process, and the (final) output data from the pro-cess. An artifact is an atomic data item (e.g. a number, a character string, or an image) or a collection of atomic data items (e.g. a doc-ument). Intuitively, all artifacts participating in a workflow execu-tion must be pre-defined in a process specificaexecu-tions. Each artifact contains a set of legal operations for its internal data. An activity designed to manipulate a certain artifact can work only with the legal operation(s) for the artifact. From the data storage point of view, each artifact operation can be regarded as one of the follow-ing operations, regardless of its semantic meanfollow-ing:
Initialize: all definition operations, e.g. ‘‘fill in”, ‘‘create”, and ‘‘define” operations.
Read: all reference operations, e.g. ‘‘use”, ‘‘fetch”, ‘‘select”, and ‘‘retrieve” operations.
Update: all modification operations, e.g. ‘‘write”, ‘‘change”, and ‘‘update” operations.
Destroy: all deletion operations, e.g. ‘‘remove”, ‘‘erase”, ‘‘cancel”, and ‘‘discard” operations.
In general, an Initialize operation is used to create an artifact in-stance in a process. Read and Update operations are then used to access the instance. Finally, a Destroy operation is used to delete the artifact instance. Destroy operations are applied for temporary artifacts created during the workflow execution, but may not be strict for all artifacts (seeFig. 3.4).
Fig. 3.4shows the state diagram of an artifact with the above four kinds of operations, ‘‘Uninitialized”, ‘‘Initialized”, ‘‘Updated”, and ‘‘Read”. ‘Uninitialized’ represents the initial state of an artifact. ‘‘Ini-tialized”, ‘‘Updated”, and ‘‘Read” represent states after an Initialize, Update, and Read operation is performed respectively. In addition, the artifact state is set to ‘‘Uninitialized” after a Destroy operation. 3.4.2. Artifact flow and artifact usages
To simplify the discussion of artifact usages, a formal and com-plete definition of a task/control activity is shown below: Definition 3.10 (Task/control activities).
An task/control activity is a tuple
v
= (ATv, SCv, ECv, RCv, Iv, Ov, ASv),where
ATvrepresents the type of the activity.
SCv, ECv, and RCvare the sets of logical expressions which are
evaluated by a workflow engine.
– SCvis the set of pre-conditions of which each is evaluated to
decide whether an activity within a process instance can be started (only used by task activities).
– ECvis the set of post-conditions of which each is evaluated to
decide whether an activity within a process instance is com-pleted (only used by task activities).
– RCvis the set of routing conditions of which each is evaluated
to decide the sequence of activity execution within a process (only used by control activities).
Iv, the input set, identifies all the artifacts required to be
accessed by the activity.
– For a task activity, Ivcontains all the artifacts required for its
computation.
– For a control activity, Ivcontains all the artifacts used to
eval-uate the routing conditions.
Ov, the output set, identifies all the artifacts produced, updated,
or destroyed after executing the activity
v
. Ovis divided into twodisjoint subsets, Oþv and Ov, where Oþv represents the set of the artifacts initialized or updated by
v
and Ov represents the set of the artifacts destroyed by
v
.ASvis the activity specification (only used by task activities).
Based on Definition 3.10, a usage relation between an activity and an artifact can be defined as follows:
Definition 3.11 (Consumer, producer, updator, and destroyer activ-ities of an artifact).
For a given artifact d, the memberships between artifact d and Iv ; Oþ
v , and Ov can be applied for identifying the usage of artifact d at activity
v
. All the possible usages are categorized as follows: if d 2 Ivand d R O þ v d R Ov,
v
is called a Reader (Activity) of artifact d. if d 2 Ivand d 2 Oþv;v
is called an Updator (Activity) of artifactd.
if d 2 Ivand d 2 Ov;
v
is called a Destroyer (Activity) of artifact d.if d R Ivand d 2 Ov,
v
is called a Illegal Destroyer1(Activity) of artifact d.if d R Ivand d 2 Oþv,
v
is called a Producer (Activity) of artifact d. if d R Iv and d R O þ v d R O v,
v
is called an Irrelevantor (Activity) of arti-fact d.In addition, if d 2 Iv,
v
is generally called a Consumer (Activity) of artifact d and if d 2 Oþv,
v
is generally called a Writer (Activity) of artifact d.Definition 3.12 (Consumer, updator, destroyer and producer activity sets of an artifact).
VIsConsumerd ¼ f
v
2 Vjd 2 Ivg is called the Consumer Activity Set ofartifact d.
VIsUpdatord ¼ f
v
2 Vjd 2 Ivand d 2 Oþvg is called the Updator Activ-ity Set of artifact d.VIsDestroyerd ¼ f
v
2 Vjd 2 Ivand d 2 Ovg is called the Destroyer
Activity Set of artifact d.
VIsProducerd ¼ f
v
2 Vjd R Ivand d 2 O þvg is called the Producer Activ-ity Set of artifact d.
VIsReaderd ¼ f
v
2 Vjd 2 Iv;d R Oþvand d R Ovg is called the Reader Activity Set of artifact d.4. Artifact usage anomalies 4.1. Artifact usage anomalies
In process specification, the following three types of anomalies might occur: (1) missing production, (2) redundant write, and (3) conflict write. In the subsections, these anomalies are defined and the corresponding usage patterns that cause the anomalies are identified. Every usage pattern is given a name, description, and formulated detection conditions.Table 4.1shows the symbols used in the usage patterns.
4.2. Missing production anomalies
A missing production anomaly occurs when an artifact is con-sumed before it is produced or after it is destroyed. In order to for-mulate this type of anomaly, the propagation of an artifact is introduced in Definition 4.1.
Definition 4.1 (Propagation of artifacts to an activity). Given an activity
v
, let a preceding execution order tov
denote an execution order leading tov
without any parallel activities ofv
, i.e., only consisting of the predecessors ofv
. Given an artifact d, if there is at least one preceding execution order tov
such that d is produced but not destroyed yet (i.e., d is not in Uninitialized state), d can be propagated tov
. The propagations of artifact d regarding only the preceding execution orders tov
are called preceding propagations of d tov
and can be classified into three cases: (1) no preceding propagation, (2) conditional preceding propagation, and (3) uncon-ditional preceding propagation:Case (1) indicates that d is always Uninitialized for all preceding execution orders to
v
.Case (2) indicates whether d is Uninitialized depends on the pre-ceding execution orders to
v
taken.Case (3) indicates that d is Initialized for all preceding execution orders to
v
.Let AAvbe the set composed of all artifacts which can be
prop-agated from the predecessors of
v
. AAvcan be divided into twodis-joint subsets, AAu
vand AAcv, where AAuvcontains artifacts propagated from the predecessors of
v
unconditionally and AAcvcontains those propagated from the predecessors ofv
conditionally.The causes of missing production anomalies can be discussed as follows. Intuitively, if
v
2 VIsConsumerd and d R AAv hold, a missing
production anomaly might occur due to No Preceding Propagation of d to
v
. Similarly, ifv
2 VIsConsumerd and d 2 AAc
vhold, a missing pro-duction anomaly might occur by Conditional Preceding Propagation of d to
v
. Furthermore, considering the parallel activities ofv
, evenTable 4.1
Symbols used in usage patterns.
Wd: a writer ðd 2 OþvÞ : no consumer of d exists
Cd: a consumer (d 2 Iv) : no producer of d exists
Ud: a updator ðd 2 Ivand d 2 Oþ
vÞ : no reader of d exists
Pd: a producer ðd R Ivand d 2 OþvÞ : no destroyer of d exists
Rd: a reader d 2 Ivand d R O þ v d R O v (): a control block Dd: a destroyer ðd 2 Ivand d 2 O
vÞ (): XOR control block
: reachable link (): AND Control block
1 The illegal destroyer is not concerned in our model because the activity destroy
artifact arbitrarily. Any useful artifact could be destroyed by the activity during the workflow execution.
though
v
2 VIsConsumerd and d 2 AA uv hold, a missing production
anomaly might occur when there is a destroy activity of d in the parallel activities. The execution order of the parallel activities de-cides the production of d. This kind of anomaly is named Uncertain Preceding Propagation.
For each cause of the missing production anomaly, possible usage patterns are characterized by its name, description, and re-quired condition as following:
(1) No preceding propagation:
v
2 VIsConsumerd ^ d R AAv.Usage Pattern 1: Cd
Name: No Production.
Description: Artifact d has at least one consumer activity
v
; however, no producer activity of d exists in theprocess.
Conditions: 9
v
2 VIsConsumerd ^ V IsProducerd ¼ ;.
Usage Pattern 2: CdPd Name: Delayed Production.
Description: Artifact d has a consumer activity
v
which precedes every producer activity of d.Conditions: 9
v
2 VIsConsumerd ^ ðV IsPredecessor v \ VIsProducerd Þ ¼ ; ^ ðVIsSuccessor v \ VIsProducerd Þ – ;. Usage Pattern 3: PdDdCdName: Early Destruction.
Description: Artifact d is produced and then destroyed before it is consumed. Conditions: 9
v
2 VIsConsumerd ^ d R AAv^ V IsPredecessor v \ VIsProducerd –; ^ VIsPredecessorv \ VIsDestroyerd –; Usage Pattern 4: ðCd PdÞ Name: Exclusive Production.Description: Given two exclusive activities
v
and u such thatv
is a consumer of artifact d and u is a producer of d. Due to the characteristic of exclusive activities, only one ofv
and u might be selected for execution. Although u is a producer of d, it makes no contribution to thepropaga-tion of d to
v
and thus a missing production anomalyoccurs. Conditions: 9
v
2 VIsConsumer d ^ d R AAv^ ðV IsExclusive v \ VIsProducerd Þ – ;. Usage Pattern 5: ðCd PdÞ Name: Uncertain Production.Description: Given two parallel activities
v
and u such thatv
is a consumer of artifact d and u is a producer of d. Due to the race hazard of parallel activities,v
might be executed before u. Therefore, u may not make contri-bution to the propagation of d forv
. Consequently, a missing production anomaly occurs if artifact d will not be propagated from the predecessors ofv
.Conditions:
9
v
2 VIsConsumerd ^ d R AAv^ ðVIsParallelv \ VIsProducerd Þ – ;.(2) Conditional Preceding Propagation:
v
2 VIsConsumerd ^ d 2
AAcv.Whether d is propagated depends on what preceding
path of
v
is taken. Consequently, a missing productionanomaly occurs when those preceding paths of v in which d is not propagated are taken.
Usage Pattern 6: ðPd ÞCd
Name: Conditional Production.
Description: Artifact d is produced conditionally before a consumer activity of d.
Conditions: 9
v
2 VIsConsumerd ^ d 2 AA cv.
Usage Pattern 7: PdðDd ÞCd
Name: Conditional Destruction.
Description: Artifact d is destroyed conditionally before a consumer activity of d.
Conditions: 9
v
2 VIsConsumerd ^ d 2 AA cv.
(3) Uncertain Preceding Propagation:
v
2 VIsConsumerd ^ d 2 AA uv. Usage Pattern 8: PdðDd CdÞ
Name: Uncertain Destruction.
Description: Given two parallel activities
v
and u such thatv
is a consumer of artifact d and u is a destroyer of d. Due to the race hazard of parallel activities,v
might be executed before u. d is unconditionally propagated from the predecessors of v, but d might be destroyed by u beforev
is executed. A missing production anomaly occurs. Conditions: 9v
2 VIsConsumer d ^ d 2 AA u v^ ðVIsParallelv \ VIsDestroyerd Þ – ;.Theorem 1 (Missing production verification). A process BP is free from missing production anomalies if the following condition holds: "v 2 V, "d 2 Iv: d 2 AAuv and ðVIsParallelv \ VIsDestroyerd Þ ¼ ;.
Proof. This theorem is proven by contradiction. Firstly, we assume a missing production anomaly in BP. The assumption indicates an activity
v
2 V, an artifact d 2 Iv, and an execution orderCsuch thatv
2Cand d is Uninitialized whenv
is selected for execution. How-ever, d 2 AAuvimplies that d is always propagated from the prede-cessors of
v
. Furthermore, ðVIsParallelv \ VIsDestroyerd Þ ¼ ; implies that
none of parallel activities of
v
affects the propagation of d tov
. Thus, no matter what preceding execution order ofv
is taken, d is always propagated tov
. It is obvious thatCdoes not exist. The fact contradicts the assumption given in the beginning and thus Theorem 1 holds. h4.3. Redundant write anomalies
A redundant write anomaly occurs when an artifact is written (produced or updated) by an activity but the artifact is neither re-quired by the succeeding activities nor a member of the process outputs. Redundancy is not an error; nevertheless, it causes ineffi-ciency. In order to formulate this type of anomalies, the set of arti-facts unused in the following activities is introduced in Definition 4.2.
Definition 4.2. (The set of artifacts unused before an
activ-ity). Given an activity
v
and an artifact d, if there is onepreceding execution path to
v
, where d is written but notconsumed, d is unused before
v
. If artifact d is unused for the predecessors of the Process End vertex and is not a member of the set of process outputs, a redundant write anomaly occurs. The anomalies can be divided into two classes: complete and condi-tional. Artifact d is completely unused indicates that d is unused for all preceding paths ofv
. Artifact d is conditionally unused indicates that d is unused in certain preceding path(s) ofv
, i.e.,that an anomaly occurs depending on which preceding path of
v
Let NCv be the set composed of all unused artifacts for the
predecessors of
v
. NCvcan be divided into two disjoint subsets NCuvand NCcv , where NCuv contains completely unused artifacts and NCcv contains conditionally unused artifacts.
The causes of redundant write anomalies can be discussed as follows. Intuitively, for every artifact d 2 NCuProcessEndand d R Ow, an
Explicit Redundant Write anomaly always occurs for artifact d of the process. For every artifact d 2 NCc
ProcessEndand d R Ow, a potential
redundant write anomaly might occur for artifact d.
For each category of the redundant write anomaly, the possible usage patterns are characterized by its name, description, and re-quired condition as following:
(1) Explicit redundant write Usage Pattern 9:
Wd
Wd
ð WdÞ
ð WdÞ
Name: No Consumption After Last Write.
Description: For an artifact d, d does not belong to the process outputs, when d is written by an activity
v
and when the artifact is unused for all succeeding activities ofv
, a redundant write occurs for the artifact.Conditions: 9d 2 NCuProcessEnd:d R Ow.
(2) Potential redundant write Usage Pattern 10:
Fig. 5.1. E-mail voting process.
Table 5.1
Artifacts in the e-mail voting process. Artifacts
d1Issue list d9Integrated results
d2Applicant data d10Data shared
d3Discussion participant data d11Deadline warning message
d4Calendar d12Conference time
d5Signature of manager d13Vote participant data
d6Announce issues d14Vote result
d7Comment on announce issues d15Increment tally
d8Discussion result d16Vote final result
Artifact usages
R Reader P Producer
WdðRd ð ^ ÞÞ
WdðDd ð ^ ÞÞ
ðRd WdÞð ^ Þ
ðDd WdÞð ^ Þ
Name: Conditional Consumption After Last Write. Description: For an artifact d, d does not belong to the
process outputs. When d is written by an activity
v
and the artifact is unused for some succeeding activities ofv
conditionally, a redundant write might occur for the artifact.Conditions: 9d 2 NCcProcessEnd:d R Ow.
Theorem 2 (Redundant write verification). A process BP is free from the redundant write anomalies if NCProcessEndnOw= ; holds.
Proof. NCProcessEndnOw= ; indicates that artifacts produced in the
process either contribute to the process output directly after its last write (d 2 Ow) or is read/destroyed after its last write on all
possible (preceding) execution orders leading to Process End (d R NCProcessEnd). Therefore, no redundant write anomaly exists if
NCProcessEndnOw= ; holds. h
4.4. Conflict writes anomalies
The conflict writes anomalies can be divided into three classes: (1) multiple parallel productions, (2) multiple parallel updates and (3) parallel read and update. An anomaly of multiple parallel productions occurs when more than one activity tries to initialize
the same artifact in parallel. An anomaly of multiple parallel up-dates occurs when more than one activity upup-dates the same arti-fact in parallel. An anomaly of parallel read and update anomaly occurs when two activities perform read and update on the same artifact concurrently. Each of these anomalies corresponds to the execution order. The anomalies make the artifact version hard to control.
Usage Pattern 11: ðPd PdÞ
Name: Multiple Parallel Productions.
Description: More than one activity initializes the same artifact in parallel. Conditions: 9
v
2 VIsProducerd ^ ðV IsProducer d \ V IsParallel v Þ – ;.Usage Pattern 12: PdðUd UdÞ
Name: Multiple Parallel Updates.
Description: More than one activity updates the same arti-fact in parallel. Conditions: 9
v
2 VIsUpdatord ^ d 2 AAv^ ðV IsUpdator d \ V IsParallel v Þ – ;. Usage Pattern 13: PdðRd UdÞName: Parallel Read and Update.
Description: Two activities perform read and update respectively on the same artifact concurrently.
Conditions: 9
v
2 VIsReaderd ^ d 2 AAv^ ðV IsUpdator d \ V IsParallel v Þ – ;.Theorem 3 (Conflict writes verification). A process BP is free from the anomalies of conflict writes if for any two parallel activities v and u, ðOþ
v n Iv Þ \ ðOþun IuÞ ¼ ;, ðOþv \ Iv Þ \ ðOuþ\ IuÞ ¼ ;, Iv \ ðOþu\ IuÞ ¼
;, and Iu\ ðOþv \ Iv Þ ¼ ; hold.
Table 5.2
Artifacts usages in the e-mail voting process.
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 ps P P P P t12 R t1 R R R R xs3 R P t2 R R U P P P U xs4 t3 R t13 R R P as1 t14 R R P xs1 R xj4 as2 P t15 U t4 P xs5 t5 P t130 R R P aj2 t140 R R P t6 R U xj5 as3 P t150 U t40 P xs6 t50 P t1300 R R P aj3 t1400 R R P t60 R U xj6 as4 P t1500 U t400 P xj3 D t500 P t16 R R R R R R R P aj4 as5 t600 R U t17 R R xj1 D t18 R t7 R R R aj5 t8 P pe t9 R xs2 R t10 P t11 R R xj2 aj1 C.-H. Wang, F.-J. Wang /The Journal of Systems and Software 82 (2009) 1600–1619
Table 5.3
Steps to detect missing production anomalies.
ps AAu = {d1, d2, d3, d13}, AAc= ; t1 AAu¼ fd1;d2;d3;d13g; AAc¼ ;; It1¼ fd1;d2;d3;d13g; It1n AA ¼ ; t2 AAu¼ fd1;d2;d3;d13;ðd5Þ; ðd6Þ; ðd7Þg; AAc¼ ;; It2¼ fd1;d2;d3;d13g; It2n AA ¼ ; t3 AAu¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; It3¼ fd6g; It3n AA ¼ ; as1 AAu¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; Ias1¼ ;; Ias1n AA ¼ ; xs1 AAu¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; Ixs1¼ fd3g; Ixs1n AA ¼ ; as2 AAu¼ fd1;d2;d3;d13;d5;d6;d7;ðd9Þg; AAc¼ ;; Ias2¼ ;; Ias2n AA ¼ ; t4 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd8Þg; AAc¼ ;; It4¼ ;; It4n AA ¼ ; t5 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd10Þg; AAc¼ ;; It5¼ ;; It5n AA ¼ ; aj2 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; Iaj2¼ ;; Iaj2n AA ¼ ; t6 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; It6¼ fd8;d9g; It6n AA ¼ ; as3 AAu¼ fd1;d2;d3;d13;d5;d6;d7;ðd9Þg; AAc¼ ;; Ias3¼ ;; Ias3n AA ¼ ; t40 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd8Þg; AAc¼ ;; It 40¼ ;; It40n AA ¼ ; t50 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd10Þg; AAc¼ ;; It 50¼ ;; It50n AA ¼ ; aj3 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; Iaj3¼ ;; Iaj3n AA ¼ ; t60 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; It 60 ¼ fd8;d9g; It60n AA ¼ ; as4 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d8;d10;ðd9Þg; AAc¼ ;; Ias4¼ ;; Ias4n AA ¼ ; t400 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d10;d9;ðd8Þg; AAc¼ ;; It 400¼ ;; It400n AA ¼ ; t500 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d8;d9;ðd10Þg; AAc¼ ;; It 500¼ ;; It500n AA ¼ ; aj4 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; Iaj4¼ ;; Iaj4n AA ¼ ; t600 AAu¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; AAc¼ ;; It 600¼ fd8;d9g; It600n AA ¼ ; xj1 AAu¼ fd1;d2;
d
3;d13;d5;d6;d7g; AAc¼ fd9;d8;d10g; IXj1¼ fd3g; IXj1n AA ¼ ; t7 AA u ¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; It7¼ fd3;d9;d11g It7n AA ¼ fd9;d11g ¼> no preceding propagation t8 AAu¼ fd1;d2;d3;d13;d5;d6;d7;ðd11Þg; AAc¼ ;; It8¼ ;; It8n AA ¼ ; t9 AA u ¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; It9¼ fd4g It9n AA ¼ fd4g ¼> no preceding propagation xs2 AAu¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; Ixs2¼ fd3g; Ixs2n AA ¼ ; t10 AAu¼ fd1;d2;d3;d13;d5;d6;d7;ðd12Þg; AAc¼ ;; It10¼ ;; It10n AA ¼ ; t11 AA u ¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ ;; It11¼ fd3;d12g It11n AA ¼ fd12g ¼> no preceding propagation xj2 AAu¼ fd1;d2;d3;d13;d5;d6;d7g; AAc¼ fd12g; Ixj2¼ ;; Ixj2n AA ¼ ; aj1 AAu ¼ fd1;d2;d13;d5;d6;d7;d11g; AAc¼ fd9;d8;d10;d12g; Iaj1¼ ; It7\ Oxj1¼ fd3g ¼> uncertain preceding propagation Ixs2\ O
xj1¼ fd3g ¼> uncertain preceding propagation It11\ O
xj1¼ fd3g ¼> uncertain preceding propagation
t12 AAu¼ fd1;d2;d13;d5;d6;d7;d11g; AAc¼ fd9;d8;d10;d12g; It12¼ fd6g; It12n AA ¼ ; xs3 AAu¼ fd1;d2;d13;d5;d6;d7;d11;ðd15Þg; AAc¼ fd9;d8;d10;d12g; Ixs3¼ fd13g; Ixs3n AA ¼ ; xs4 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15g; AAc¼ fd9;d8;d10;d12g; Ixs4¼ ;; Ixs4n AA ¼ ; t13 AA u¼ fd 1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It13¼ fd6;d9g It13\ AA c
¼ fd9g ¼> conditional preceding propagation
t14 AA
u
¼ fd1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It14¼ fd6;d9g It14\ AA
c¼ fd
9g ¼> conditional preceding propagation
xj4 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; Ixj4¼ ;; Ixj4n AA ¼ ; t15 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; It15¼ fd15g; It15n AA ¼ ; xs5 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15g; AAc¼ fd9;d8;d10;d12g; Ixs5¼ ;; Ixs5n AA ¼ ; t130 AA u ¼ fd1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It130¼ fd6;d9g It130\ AA c¼ fd
9g ¼> conditional preceding propagation
t140 AA
u¼ fd
1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It140¼ fd6;d9g It140\ AA
c
¼ fd9g ¼> conditional preceding propagation
xj5 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; Ixj5¼ ;; Ixj5n AA ¼ ; t150 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; It 150 ¼ fd15g; It150n AA ¼ ; xs6 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; Ixs6¼ ;; Ixs6n AA ¼ ; t1300 AA u¼ fd 1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It1300¼ fd6;d9g It1300\ AA c
¼ fd9g ¼> conditional preceding propagation
t1400 AA
u¼ fd
1;d2;d13;d5;d6;d7;d11;d15;ðd14Þg; AAc¼ fd9;d8;d10;d12g; It1400¼ fd6;d9g It1400\ AA
c
¼ fd9g ¼> conditional preceding propagation
xj6 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; Ixj6¼ ;; Ixj6n AA ¼ ; t1500 AAu¼ fd1;d2;d13;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; It 1500 ¼ fd15g; It1500n AA ¼ ; xj3 AAu¼ fd1;d2; ;d5;d6;d7;d11;d15;d14g; AAc¼ fd9;d8;d10;d12g; IXj3¼ fd13g; IXj3n AA ¼ ; t16 AAu¼ fd1;d2;d5;d6;d7;d11;d15;d14;ðd16Þg; AAc¼ fd9;d8;d10;d12g; It16¼ fd1;d2;d3;d6;d9;d13;d15g It16n AA ¼ fd3;d13g ¼> no preceding propagation It16\ AA c
¼ fd9g ¼> conditional preceding propagation
as5 AAu¼ fd1;d2;d5;d6;d7;d11;d15;d14;d16g; AAc¼ fd9;d8;d10;d12g; Ias5¼ ;; Ias5n AA ¼ ; t17 AA u ¼ fd1;d2;d5;d6;d7;d11;d15;d14;d16g; AAc¼ fd9;d8;d10;d12g; It17¼ fd13;d16g It17n AA ¼ fd13g ¼> no preceding propagation t18 AAu¼ fd1;d2;d5;d6;d7;d11;d15;d14;d16g; AAc¼ fd9;d8;d10;d12g; It18¼ fd16g; It18n AA ¼ ; aj5 AAu¼ fd1;d2;d5;d6;d7;d11;d15;d14;d16g; AAc¼ fd9;d8;d10;d12g; Iaj5¼ ;; Iaj5n AA ¼ ; pe AAu¼ fd1;d2;d5;d6;d7;d11;d15;d14;d16g; AAc¼ fd9;d8;d10;d12g; Ipe¼ ;; Ipen AA ¼ ;
Proof. If any pair of parallel activities
v
and u such that ðOþvn IvÞ \ ðOþun IuÞ ¼ ;, no two activities initializes the samearti-fact in parallel. If ðOþ
v\ IvÞ \ ðOþu\ IuÞ ¼ ;, then no two activities
updates the same artifact in parallel. Furthermore, Iv\ ðOþu\ IuÞ ¼
; and Iu\ ðOþv\ IvÞ ¼ ; indicate that no two activities perform read and update respectively on the same artifact. Thus, BP is free from conflict writes anomalies. h
5. The methods to detect artifact usage anomalies
The methods for detecting the artifact usage anomalies in a pro-cess specification are presented in this section. The goal in our study is to search the artifact usage anomaly only, and it is not nec-essary to construct the possible artifact activities in each process. Instead, loop can be replaced with a corresponding XOR structure. From the top-level view, a well-formed control flow can be deemed as one or a sequence of task(s) and/or top-level control block(s). Thus, an entire flow can be deemed as a sequence of nodes in which each node represents a task or a control block which repre-sents a group of sequential flows. The same perspective can also be applied to the branches of the control block(s). In our approach, a business process is transformed into a sequence of nodes before
applying the detection methods. Each method in Section 5.2 is
aimed at detecting a type of artifact usage anomalies identified in Section4.
5.1. Process transformation
Let control flow G = (V, E) of a business process be transformed into a sequence of nodes S. The data structure of S and the nodes within S are defined in Definition 5.1.
Definition 5.1 (The data structure of a sequence and a node). S: a structure containing a sequence of nodes (a node could represent a task or a control block)
S.startVertex: the vertex is the first node of the sequence
S.endVertex: the vertex is the termination of the sequence
S.nodes: a set of ordered nodes
node: a node is a structure denoted with type, startVertex, endVertex and subSequences
node.type: the type of a task or control block
node.startVertex: the start vertex of a control block
node.endVertex: the end vertex of a control block
node.subSequences: a set of sequences attached to
the node
The transformation is designed to convert a control flow en-closed by ProcessStart and ProcessEnd vertices. The initial value of the level attribute for each vertex in V is 0. An empty se-quence is declared for the control flow in the beginning. During the transformation, a node is created for each task and control block visited. The task node is appended to the sequence directly. Once a split activity s reached, its corresponding control block is identified by function SetLevel which traverses a path with the vertexes enclosed by s and its corresponding join activity j in G. During the traverse, the level attributes of the vertexes tra-versed are updated. The transformation is applied to the block identified. Such a recursive operation continues until all activities in the block are processed. The corresponding sequence of node(s) generated for each branch of a control block is attached to the node created for their own control blocks when the trans-formation completes at the end of the branch. The details of
transforming a task and a control block are shown in
PseudoCode1. Table 5.4
Steps to calculate the unused artifacts.
ps NCu = {d1, d2, d3, d13}, NCc= ; t1 NCu= { 2 3 13 1 }, NC c = ; t2 NCu= {(d5), (d6), (d7), (d13)}, NCc= ; t3 NCu= {d5, 6, d7, d13}, NCc= ; as1 NCu= {d5, d7, d13}, NCc= ; xs1 NCu= {d5, d7, d13}, NCc= ; as2 NCu¼ fd5;d7;d13;ðd9Þg; NCc¼ ; t4 NCu¼ fd5;d7;d13;d9;ðd8Þg; NCc¼ ; t5 NCu¼ fd5;d7;d13;d9;ðd10Þg; NCc¼ ; aj2 NCu¼ fd5;d7;d13;d9;d8;d10g; NCc¼ ; t6 NCu¼ fd5;d7;d13; 8 ;d10;ðd9Þg; NCc¼ ; as3 NCu¼ fd5;d7;d13;ðd9Þg; NCc¼ ; t40 NCu¼ fd5;d7;d13;d9;ðd8Þg; NCc¼ ; t50 NCu¼ fd5;d7;d13;d9;ðd10Þg; NCc¼ ; aj3 NCu¼ fd5;d7;d13;d9;d8;d10g; NCc¼ ; t60 NCu¼ fd5;d7;d13; 8 ;d10;ðd9Þg; NCc¼ ; as4 NCu¼ fd5;d7;d13;d10;ðd9Þg; NCc¼ ; t400 NCu¼ fd5;d7;d13;d10;d9;ðd8Þg; NCc¼ ; t500 NCu¼ fd5;d7;d13;d9;ðd10Þg; NCc¼ ; aj4 NCu¼ fd5;d7;d13;d9;d8;d10g; NCc¼ ; t600 NCu¼ fd5;d7;d13; 8 ;d10;ðd9Þg; NCc¼ ; xj1 NCu= {d5, d7, d13}, NCc= ; t7 NCu= {d5, d7, d13}, NCc= ; t8 NCu¼ fd5;d7;d13;ðd11Þg; NCc¼ ; t9 NCu= {d5, d7, d13}, NCc= ; xs2 NCu= {d5, d7, d13}, NCc= ; t10 NCu¼ fd5;d7;d13;ðd12Þg; NCc¼ ; t11 NCu= {d5, d7, d13}, NCc= ; xj2 NCu= {d5, d7, d13}, NCc= {d12} aj1 NCu¼ fd5;d7;d13;d11g; NCc¼ fd12g t12 NCu¼ fd5;d7;d13;d11g; NCc¼ fd12g xs3 NCu¼ fd5;d7; ;d11;ðd15Þg; NCc¼ fd12g xs4 NCu¼ fd5;d7;d11;d15g; NCc¼ fd12g t13 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g t14 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g xj4 NCu¼ fd5;d7;d11;d15;d14g; NCc¼ fd12g t15 NCu¼ fd5;d7;d11;d14;ðd15Þg; NCc¼ fd12g xs5 NCu¼ fd5;d7;d11;d15g; NCc¼ fd12g t130 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g t140 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g xj5 NCu¼ fd5;d7;d11;d15;d14g; NCc¼ fd12g t150 NCu¼ fd5;d7;d11;d14;ðd15Þg; NCc¼ fd12g xs6 NCu¼ fd5;d7;d11;d15;d14g; NCc¼ fd12g t1300 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g t1400 NCu¼ fd5;d7;d11;d15;ðd14Þg; NCc¼ fd12g xj6 NCu¼ fd5;d7;d11;d15;d14g; NCc¼ fd12g t1500 NCu¼ fd5;d7;d11;d14;ðd15Þg; NCc¼ fd12g xj3 NCu¼ fd5;d7;d11;d14;d15g; NCc¼ fd12g t16 NCu¼ fd5;d7;d11;d14; ;ðd16Þg; NCc ¼ fd12g as5 NCu¼ fd5;d7;d11;d14;d16g; NCc¼ fd12g t17 NCu¼ fd5;d7;d11;d14; g; NCc¼ fd12g t18 NCu¼ fd5;d7;d11;d14; g; NCc¼ fd12g aj5 NCu¼ fd5;d7;d11;d14g; NCc¼ fd12g pe NCu ¼ fd5;d7;d11;d14g; NCc¼ fd12g
PseudoCode 1 TransformControlBlock(G, v, level, controlNodes){
// Input: G=(V,E): a directed connected graph
// v: the traverse is started from vertex v.
// level: the level of start vertex v
// controlNodes: a stack containing a set of pairwise control
activities bounded control blocks
// Output: S: a structure containing a sequence of nodes Stack currentControlNodes = new Stack();
S.startVertex=currentVertex=v; while (currentVertex != null) {
switch (currentVertex.type) { case ‘‘ProcessStart”: nextVertex = currentVertex.next; break; case ‘‘Task”: newNode.type=currentVertex.type; newNode.startVertex=currentVertex; newNode.endVertex=currentVertex; newNode. subSequences.append(null); S.nodes.append(newNode); nextVertex = currentVertex.next; break;
case ‘‘AndSplit” or ‘‘XorSplit”:
newNode.type=currentVertex.type; newNode.startVertex=currentVertex; if (controlNodes.get(currentVertex) == null)
currentControlNodes.push(currentVertex.level, currentVertex);
for each edge (currentVertex, w) 2 E { //recursively transform each branch within a control block
if (w.level <= currentVertex.level) { controlNodes = SetLevel(w, current
Vertex.level++, currentControlNodes, controlNodes);
//record pairwise control activities in the branch } endVertex = contrlNodes.get (currentVertex); subsequence = TransformControlBlock(G’, currentVertex, currentVertex.level, controlNodes);
// the directed connected graph G’ of the branch bounded by currentVertex and endVertex
subsequence.parentBlock = newNode; //collect every subSequence (corresponding to each branch)
newNode.subSequences.append(subSequence); }
// assign ‘‘AndJoin” or ‘‘XorJoin”to be the end vertex of the node
newNode.endVertex= endVertex; S.nodes.append(newNode); nextVertex = newNode.endVertex.next; break; case ‘‘EndProcess”: exit while; }
previousVertex = currentVertex; //remember last
traversed vertex
currentVertex = currentVertex.next; //continue to traverse next node
}
}
PseudoCode SetLevel(startVertex, level, currentControlNodes, controlNodes) {
n = level;
currentVertex= startVertex;
while ((currentVertex.type != ‘‘AndJoin” & & currentVertex.type != ‘‘XorJoin”)jj n>=level) {
if (currentVertex.type== ‘‘AndSplit” jj currentVertex.type== ‘‘XorSplit”) { currentVertex.level=n; currentControlNodes.push(n, currentVertex); n ++; currentVertex=currentVertex.next;
// currentVertex.next returns the first node in one branch after currentVertex.
} else if (currentVertex.type== ‘‘AndJoin” jj currentVertex.type== ‘‘XorJoin”) {
n –;
currentVertex.level=n;
controlNodes.push(currentControlNodes.get (currentVertex.level),currentVertex);
// get the spilt activity s associated with level n from currentControlNodes stack and
// then push the pair (s, currentVertex) into controlNodes stack
currentControlNodes.pop(currentVertex.level); if (n<level) exit while;
else currentVertex= currentVertex.next; } else { currentVertex.level=n; currentVertex= currentVertex.next; } } return controlNodes; }
5.2. Anomaly detection methods
The methods for detecting the artifact usage anomalies in a pro-cess specification are presented in this section, named DetectMiss-ingProduction, DetectRedundantWrite and DetectConflictWrites, respctively. Each is aimed at detecting a type of artifact usage anomalies identified in Section 4. The details of these methods are shown in the following subsections. An example described in
Section 5.2.1.3 is adopted to demonstrate their how they work
correspondingly.
5.2.1. Method for detecting missing production anomalies
5.2.1.1. Calculation of propagated artifacts from predecessors. Given a sequence S of the process derived from transformation, let S.AAv
denote the set of artifacts propagated from the predecessors of activity
v
and S:AA0v be the set of artifacts of which each can be propagated to the direct successors of
v
after the execution ofv
. At the top level, S.AAS.startVertex= Iwfor the starting node of S. Duringthe traverse of sequence S, when a node n is reached, S.AA is calcu-lated as follows:
If n represents a task activity
v
,v has only one direct successor x. S:AA0vand S.AAxare calculated as follows:
– For each destroyed artifact d 2 Iv\ Ov, remove d from S:AAuv or S:AAc
vwhere d is included. – For each produced artifact d 2 ðOþ
vn IvÞ, add d to S:AAuv and remove d from S:AAcvif d is included.
Table 5.5
Steps to calculate the conflict write.
ps PA = {d1, d2, d3, d13}, UA = ;, RA = ; t1 PA = {d1, d2, d3, d13}, UA = ;, RA = {d1, d2, d3, d13} t2 PA ¼ fd1;d2;d3;d13;ðd5Þ; ðd6Þ; ðd7Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d3;d13g t3 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d3;d13;ðd6Þg as1 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d3;d13;d6g xs1 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;ðd3Þg as2 PA ¼ fd1;d2;d3;d13;d5;d6;d7;ðd9Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t4 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd8Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t5 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd10Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g aj2 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t6 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13;ðd9Þg; RA ¼ fd1;d2;d13;d6;d3;ðd8Þg as3 PA ¼ fd1;d2;d3;d13;d5;d6;d7;ðd9Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t40 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd8Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t50 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;ðd10Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g aj3 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3g t60 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13;ðd9Þg; RA ¼ fd1;d2;d13;d6;d3;ðd8Þg as4 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d8;d10;ðd9Þg; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d3;d8g t400 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d10;d9;ðd8Þg; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d3;d8g t500 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d8;d9;ðd10Þg; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d3;d8g aj4 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d3;d8g t600 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13;ðd9Þg; RA ¼ fd1;d2;d13;d6;d3;ðd8Þg xj1 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10g; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d3;d8g t7 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;ðd3Þ; ðd9Þ; ðd11Þg t8 PA ¼ fd1;d2;d3;d13;d5;d6;d7;ðd11Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d3;d9;d11g t9 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d3;d13;d6;ðd4Þg xs2 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d4;ðd3Þg t10 PA ¼ fd1;d2;d3;d13;d5;d6;d7;ðd12Þg; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d4;d3g t11 PA ¼ fd1;d2;d3;d13;d5;d6;d7g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d4;ðd3Þ; ðd12Þg xj2 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d12g; UA ¼ fd3;d13g; RA ¼ fd1;d2;d13;d6;d4;d3;d12g aj1 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12g; UA ¼ fd3;d13;d9g; 1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t12 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12g; UA ¼ fd3;d13;d9g; 1;d2;d13;d4;d3;d12;d8;d9;d11;ðd6Þg xs3 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;ðd15Þg; UA ¼ fd3;d13;d9g; 1;d2;d6;d4;d3;d12;d8;d9;d11;ðd13Þg xs4 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15g; UA ¼ fd3;d13;d9g; 1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t13 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9g; 1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg t14 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9g; 1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg xj4 RA ¼ fdPA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9g; 1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t15 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;ðd15Þg; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g xs5 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15g; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t130 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg t140 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg xj5 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9g; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t150 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;ðd15Þg; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g xs6 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t1300 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9;d15g; RA ¼ fd1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg t1400 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;ðd14Þg; UA ¼ fd3;d13;d9;d15g; RA ¼ fd1;d2;d13;d4;d3;d12;d8;d11;ðd6Þ; ðd9Þg xj6 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t1500 PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;ðd15Þg; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g xj3 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd1;d2;d13;d6;d4;d3;d12;d8;d9;d11g t16 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;ðd16Þg; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;ðd1Þ; ðd2Þ; ðd3Þ; ðd6Þ; ðd9Þ; ðd13Þ; ðd15Þg as5 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;d16g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;d1;d2;d3;d6;d9;d13;d15g t17 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;d16g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;d1;d2;d3;d6;d9;d15;ðd13Þ; ðd16Þg t18 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;d16g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;d1;d2;d3;d6;d9;d13;d15;ðd16Þg aj5 PA ¼ fd1 ;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;d16g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;d1;d2;d3;d6;d9;d13;d15;d16g pe PA ¼ fd1;d2;d3;d13;d5;d6;d7;d9;d8;d10;d11;d12;d15;d14;d16g; UA ¼ fd3;d13;d9;d15g; RA ¼ fd4;d12;d8;d11;d1;d2;d3;d6;d9;d13;d15;d16g
