• 沒有找到結果。

運用DCDC Model來遞增性分析高階程式之異常使用

N/A
N/A
Protected

Academic year: 2021

Share "運用DCDC Model來遞增性分析高階程式之異常使用"

Copied!
103
0
0

加載中.... (立即查看全文)

全文

(1)

資訊科學與工程研究所

運用 DCDC Model 來遞增性分析高階程式之異常使用

Detecting Artifact Usage Anomalies

in High-level Software Incrementally with DCDC Model

研 究 生:林建志

指導教授:王豐堅 教授

(2)

運用 DCDC Model 來遞增性分析高階程式之異常使用

Detecting Artifact Usage Anomalies

in High-level Software Incrementally with DCDC Model

研 究 生:林建志 Student:Chien-Chih Lin

指導教授:王豐堅 Advisor:Feng-Jian Wang

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

August 2008

(3)

中華民國九十七年八月

運用 DCDC Model

來遞增性分析高階程式之異常使用

研究生: 林建志 指導教授: 王豐堅 博士

國 立 交 通 大 學

資訊科學與工程研究所

碩 士 論 文

摘要

工作流程是由一組系統化組成的工作,經過特定的順序執行之後,能夠達成所要的 目標或是產品。其中資料是實作和執行工作流程不可或缺的元素。然而工作流程可能會 因為不適當的資料操作而產生預期外的結果,例如,遺失執行所需的資料或是收到多份 同名資料產生衝突等等。因此在設計流程的過程中,資料分析結果便能提供相關的幫助。 這篇論文提出了一個流程模組去描述一個 Well-formed 工作流程,這一名叫 DCDC Model 的模組顯示出四類的資料使用異常。因此我們提出了一些漸進式的演算法去偵測出這些 資料使用異常,以輔助使用者在工作流程之編輯。 關鍵字:工作流程、商業流程、控制流、資料、資料流、遞增分析、異常

(4)

Detecting Artifact Usage Anomalies

in High-level Software Incrementally with DCDC

Model

Student: Chien-Chih Lin Advisor: Dr. Feng-Jian Wang Institute of Computer Science and Engineering

National Chiao Tung University 1001 Ta Hsueh Road, Hsinchu, Taiwan, ROC

Abstract

Workflow is a set of tasks which are systematized to achieve certain business goal(s), complete where each task is executed in a particular order under automatic control. Artifacts, collections of data items, are necessary for workflow implementation and support process execution. However, a workflow may yield unexpected results in execution due to improper artifact manipulation; e.g. activities miss artifact, or artifact conflict occurs at an activity in run time. Therefore, the analyses on artifact usage in design phase are very important. This thesis presents a process model, named DCDC model, to describe a well-formed workflow. There are four types of artifact usage anomalies in DCDC identified. To help the edit of a process, the corresponding incremental algorithms are presented to detect these anomalies. Their time complexities are also studied.

Keywords: work flow, business process, control flow, artifact, artifact flow, incremental

(5)

誌謝

本篇論文的完成,首先要感謝我的指導教授王豐堅博士兩年來不斷的指導與鼓勵, 讓我在軟體工程及工作流程的技術上得到很多豐富的知識,使我可以在偵測資料使用異 常上找到靈感。另外,也非常感謝我的畢業口試評審委員朱治平博士以及朱正忠博士, 提供許多寶貴的意見,補足我論文裡不足的部分。 其次,我要感謝實驗室的學長姊們在研究生涯上的指導與照顧,尤其是懷中學長的 督促與幫忙,讓我學得許多做研究的方法和技巧,得以順利的撰寫論文。 最後,我要感謝我的家人,由於有你們的支持,讓我能讀書、作研究到畢業,此外, 謝謝同期碩士班好友們的打氣,在我遇到挫折時能互相勉勵並度過難關。由衷地感謝你 們大家一路下來陪著我走過這段研究生歲月。

(6)

Table of Contents

摘要 ... i Abstract ... ii 誌謝 ... iii Table of Contents ... iv List of Tables ... vi

List of Figures ... viii

Chapter 1. Introduction ... 1

Chapter 2. Related Work ... 3

2.1. Artifact Transmission Models ... 3

2.2. Previous Work ... 5

Chapter 3. A Process Model Based on Well-formed Workflow ... 7

3.1. Control Flow Specification ... 7

3.2. Relations between Activities and Control Blocks ... 15

3.3. Artifact Flow Diagram Specification ... 17

3.3.1. Artifact Operations and Usages ... 18

3.3.2. Artifact Flow Diagrams ... 21

3.3.3. An Example of an Artifact Flow Diagram ... 28

Chapter 4. Artifact Usage Anomalies ... 31

4.1. Missing Artifact Anomalies ... 31

4.2. Artifact Conflict Anomalies ... 33

4.3. Cross Passing Artifact Anomalies ... 36

4.4. Redundant Anomalies ... 38

Chapter 5. Incremental Algorithms for Anomalies Detection ... 41

(7)

5.2. Incremental Algorithms to Detect Artifact Usage Anomalies ... 45

5.3. Algorithms to Update an Artifact Flow Diagram ... 49

5.3.1. Construction of XBNodes ... 49

5.3.2. Update of the Properties of Flows ... 55

5.3.3. An Example for Illustration of Updating an Artifact Flow Diagram ... 60

5.4. Algorithms to Detect Artifact Usage Anomalies ... 64

Chapter 6. Examples for Illustrating Incremental Algorithms ... 68

6.1. Activity Modification ... 70

6.2. Pass Insertion ... 74

6.3. Pass Deletion ... 78

Chapter 7. Comparisons ... 83

7.1. Comparison of Artifact Transmission Models ... 83

7.2. Comparison of Artifact Analysis Approaches ... 85

Chapter 8. Conclusion ... 89

(8)

List of Tables

Table 3.1: The States of Each Activity in Figure 3.7 ... 29

Table 3.2: The States of Each XBNode in Figure 3.8 ... 30

Table 5.1: Edit Operations for a Process ... 41

Table 5.2: Construction of XBNodes in BuildXBNodes(𝑃𝑂𝑈𝑇𝑣𝑑1, 𝑣 1, 𝑋𝑂𝑈𝑇𝑣𝑑1) ... 62

Table 5.3: The States of Each XBNode in 𝑋𝑂𝑈𝑇𝑣𝑑1 ... 62

Table 6.1: The States of Each Activity in Figure 6.1 ... 69

Table 6.2: The States of Each Activity in Figure 6.2 ... 70

Table 6.3: The Anomalies Occur in Figure 6.2 ... 70

Table 6.4: The Anomalies Occur in Figure 6.3 ... 71

Table 6.5: The Anomalies Occur in Figure 6.4 ... 72

Table 6.6: The Anomalies Occur in Figure 6.5 ... 73

Table 6.7: The States of Activities 𝑣9 and 𝑣10 in Figure 6.6 ... 75

Table 6.8: The Anomalies Occur in Figure 6.6 ... 75

Table 6.9: The States of Activities 𝑣3 and 𝑣6 in Figure 6.7 ... 76

Table 6.10: The Anomalies Occur in Figure 6.7 ... 77

Table 6.11: The States of Activities 𝑣6 and 𝑣8 in Figure 6.8 ... 78

Table 6.12: The Anomalies Occur in Figure 6.8 ... 78

Table 6.13: The States of Activities 𝑣1 and 𝑣8 in Figure 6.9 ... 79

Table 6.14: The Anomalies Occur in Figure 6.9 ... 79

Table 6.15: The States of Activities 𝑣4 and 𝑣7 in Figure 6.10 ... 80

Table 6.16: The Anomalies Occur in Figure 6.10 ... 81

Table 6.17: The States of Activities 𝑣1 and 𝑣3 in Figure 6.11 ... 82

Table 6.18: The Anomalies Occur in Figure 6.11 ... 82

(9)

Table 7.2: Comparison of the Artifact Usage Anomalies Addressed ... 87 Table 7.3: Comparison with Previous Work ... 88

(10)

List of Figures

Figure 2.1: Three Major Artifact Transmission Models ... 3

Figure 3.1: Notations of Control Flow Graph ... 12

Figure 3.2: An Example of Control Flow Graph ... 12

Figure 3.3: Using a Loop Sub-Process Activity to Replace a Loop Structure ... 17

Figure 3.4: An Artifact Flow Diagram without XBNodes ... 23

Figure 3.5: An Example of Receiving and Sending Sets ... 25

Figure 3.6: An Artifact Flow Diagram with XBNode ... 26

Figure 3.7: An Example of a Control Flow Graph ... 28

Figure 3.8: The Corresponding Artifact Flow Diagram for d ... 29

Figure 4.1: An Example of an Explicit Missing Artifact Anomaly ... 32

Figure 4.2: An Example of an Implicit Missing Artifact Anomaly ... 32

Figure 4.3: An Example of a Destroyed Artifact Anomaly ... 33

Figure 4.4: An Example of an Explicit Artifact Conflict Anomaly ... 34

Figure 4.5: An Example of an Implicit Artifact Conflict Anomaly ... 35

Figure 4.6: An Example of a Production Conflict Anomaly ... 36

Figure 4.7: An Example of a Passing between Parallel Activities Anomaly ... 37

Figure 4.8: An Example of a Passing between Exclusive Activities Anomaly ... 38

Figure 4.9: An Example of a Redundant Update/Initialization Anomaly ... 39

Figure 4.10: An Example of a Redundant Pass Anomaly ... 40

Figure 5.1: An Example of Building XBNodes ... 60

Figure 5.2: The Corresponding Artifact Flow Diagram for d ... 61

Figure 6.1: An Example of a Control Flow Graph ... 68

Figure 6.2: The Artifact Flow Diagram for d ... 69

(11)

Figure 6.4: The Artifact Flow Diagram After Modifying 𝑣8 ... 72

Figure 6.5: The Artifact Flow Diagram After Modifying 𝑣2 ... 73

Figure 6.6: The Artifact Flow Diagram After Adding Pass(d, 𝑣10) into 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣9 ... 75

Figure 6.7: The Artifact Flow Diagram After Adding Pass(d, 𝑣6) into 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣3 ... 76

Figure 6.8: The Artifact Flow Diagram After Adding Pass(d, 𝑣6) into 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣8 ... 77

Figure 6.9: The Artifact Flow Diagram After Removing Pass(d, 𝑣8) from 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1 ... 79

Figure 6.10: The Artifact Flow Diagram After Removing Pass(d, 𝑣7) from 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣4 .... 80

Figure 6.11: The Artifact Flow Diagram After Removing Pass(d, 𝑣3) from 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1 .... 81

Figure 7.1: A Control Flow in GDS ... 83

(12)

Chapter 1. Introduction

Workflow is a set of tasks which are systematized to achieve certain business goals by completing each task in a particular order under automatic control [1]. On the other hand, resources are necessary for workflow implementation and support process execution. Resource allocation and resource constraint analysis [2 - 6] are popular topics of workflow research. However, data flow within workflow is seldom addressed [7, 8].

Artifacts are collections of data items involved in a process. Introducing analysis of artifact usage into workflow designs might help maintain data consistency, as well as prevent the exceptions. In contrast to structural correctness, accuracy in artifact manipulation can help determine whether the execution result of a workflow is meaningful and desirable.

Sadiq et al. [7] presented data flow validation issues in workflow modeling, including identifying requirements of data modeling and seven basic data validation problems: redundant data, lost data, missing data, mismatched data, inconsistent data, misdirected data, and insufficient data. However, there is no discussion about any implementation or formal method to demonstrate how to apply their researches and which types of workflow model are compatible with their activity-based data model.

Sun et al. [8] presented a data flow analysis framework for detecting data flow anomalies such as missing data, redundant data, and potential conflicts of data. In addition, several algorithms were provided to detect anomalies, however, the work is done only based on read and first initial write operations of an artifact.

(13)

Jin Hyun Son [14] defined a well-formed workflow based on the concepts of closure and control block. He claimed that a well-formed workflow is free from structure errors, and that complex control flows can be made with nested control blocks.

Aalst [9] identifies three major artifact transmission models in a workflow: (1) Global Data Store (GDS), (2) Integrated Control and Data Channels (ICDC), and (3) Distinct Control and Data Channels (DCDC). DCDC is more flexible for representing artifact transmission than GDS and ICDC. Therefore, this thesis proposes a process model for describing a well-formed workflow. The artifact transmissions in this model are based on DCDC model and four types of artifact usage anomalies are addressed.

Further, each artifact in this model has a corresponding artifact flow diagram for representing its transmissions and usages. This thesis presents a set of incremental algorithms to update the artifact flow diagrams when designer edits a workflow. By analyzing the updated artifact flow diagram, the artifact usage anomalies can be detected meanwhile. The warning messages are provided to the designers if artifact usage anomalies occur.

The remainder of this thesis is organized as follows. Chapter 2 presents the related work. Chapter 3 presents our process modeling based on well-formed workflow and the artifact flow diagram. Chapter 4 identifies four types of artifact usage anomalies. Chapter 5 proposes several incremental algorithms to update artifact flow diagram and detect artifact usage anomalies. Chapter 6 demonstrates our incremental algorithms with several scenarios. Chapter 7 compares this thesis with related work. Conclusions and future works are finally drawn in chapter 8.

(14)

Chapter 2. Related Work

To develop an effective and reliable workflow application, a well-defined workflow model is necessary. The correctness issues in a workflow might be classified into three dimensions: control flow, resource, and data flow. The analysis of control flow aspect includes structural correctness focuses on soundless of control logic [10], process model analysis, workflow patterns [11, 12], and automatic control of workflow process [13], etc. The analysis of resource aspect includes resource allocation constraints [2], resource availability [3], resource management [5], and resource modeling [6], etc. The analysis of data flow aspect includes data flow validation [7], data flow formulation [8], and artifact usage anomalies detection [8][15], etc,

2.1 Artifact Transmission Models

Aalst [11] identifies three major artifact transmission models in a workflow: (1) Global Data Store, (2) Integrated Control and Data Channels, and (3) Distinct Control and Data Channels. These transmission models are illustrated in Figure 2.1.

Figure 2.1: Three Major Artifact Transmission Models.

𝑣1 𝑣2 𝑣3

Global Shared Data

Data Data

(1) Global Data Store

𝑣1 Data 𝑣2 Data 𝑣3

(2) Integrated Control and Data Channels

𝑣1 𝑣2 𝑣3

Data

(15)

(1) Global Data Store (GDS):

Each artifact is only allowed to have one instance in a workflow and the instance is typically stored in a global shared data store. All activities share the same artifact instances in the global data store.

(2) Integrated Control and Data Channels (ICDC):

In this model, all artifacts are passed with control flows regardless of whether the next activity will use them or not.

(3) Distinct Control and Data Channels (DCDC):

Artifacts are passed between activities via explicit channels [16] which are distinct from control flows. Hence, each activity can decide where artifacts are passed.

Based on the introductions above, we discover that some behaviors or properties in DCDC are hard to represent in GDS and ICDC. For example in the aspect of artifacts security, let an artifact d in Figure 2.1 be updated by 𝑣1 and only allowed to be read by 𝑣3. In GDS, each activity can access the artifact d because it is store in the global data store. Therefore, it is hard to limit other activities to read or update d before 𝑣3 reads it.

In ICDC, if 𝑣3 is required to read the artifact d updated by 𝑣1, d has to be transferred through the activities between 𝑣1 and 𝑣3 in the control flow. In Figure 2.1 (2), 𝑣2 will receive d from 𝑣1 and pass it to 𝑣3 regardless of whether 𝑣2 requires d or not. Hence, it is also hard to limit 𝑣2 to read or update d before 𝑣3 receives it.

However, each activity in DCDC can decide where artifacts are passed. Activity 𝑣1 in Figure 2.1 (3) can simply decide to pass d to 𝑣3 and only 𝑣3 will receive it. The other

activities without receiving d can not access it. Therefore, DCDC is more flexible and is adapted to represent artifact transmission in this thesis.

(16)

2.2 Previous Work

Previous work presents a process model to describe workflow schemas. The definitions of a process, an activity, and a control block are proposed. The relations among activities and control blocks, e.g. paths, reachablility, predecessors, successors, parallel activities, and exclusive activities, are also defined.

In order to simplify analysis the artifact usages in GDS, every artifact operation can be regarded as one of the following operations: Initialize, Read, Updated, and Destroy, regardless of its semantic meaning. Further, the usage relation between an activity and an artifact can be identified as: Producer, Reader, Updater, Destroyer.

Based on the definitions above, previous work identifies the following artifact usage anomalies: (1) No Production, (2) Delayed Production, (3) Early Destruction, (4) Exclusive Production, (5) Uncertain Production, (6) Conditional Production, (7) Conditional Destruction, (8) Uncertain Destruction, (9) Explicit Redundant Update, (10) Potential Redundant Update, (11) Multiple Parallel Productions, (12) Multiple Parallel Updates, and (13) Parallel Read and Update. After identifying the causing conditions of each anomaly, previous work proposes a batch algorithm to traversal a control flow and detect whether anomalies occur or not.

Since previous work only discusses artifact transmission in GDS, the activities share the same artifact instances stored in global data store and an artifact is only allowed to have one instance in a process. However, the activity in DCDC can decide where artifacts are passed and an artifact is allowed to have multiple instances in a process.

(17)

Therefore, we extend the process model of previous work and present an artifact flow diagram for each artifact to represent the artifact usages and transmissions in this thesis. Based on the information in artifact flow diagram, the artifact usage anomalies in DCDC can be identified. The differences of anomalies between GDS and DCDC are discussed in Section 7.1. The comparison of the anomalies addressed in previous work and our work is discussed in Section 7.2.

Furthermore, our model proposes several edit operations for editing a process. In order to update the artifact flow diagram after each edit operation incrementally, the incremental algorithms are introduced for each edit operation. The detailed algorithms about how to construct artifact flow diagram are also described in this thesis.

(18)

Chapter 3. A Process Model Based on Well-formed Workflow

3.1 Control Flow Specification

As discussed in Section 2.2, [15] does not concern the activities can decide where artifacts are passed and the artifacts can have multiple instances in a workflow. To solve these problems, there are several features introduced in addition in this thesis. The new features are described in the following paragraphs. First, Definition 3.1 formally defines a process specification and Definition 3.2 describes the fundamental properties contained in each activity.

Definition 3.1 (Process Specification)[15]

A process specification p = (𝑉𝑝, 𝐹𝑝, 𝑅𝑝, 𝐶𝑝, 𝑆𝑝, 𝐸𝑝), where

 𝑉𝑝: The set of activities in p. The id of each activity is unique.  𝐹𝑝: The set of flows in p.

 𝑅𝑝: The set of resources (artifacts) used in p.

 𝐶𝑝: The set of control blocks in p. The id of each control block is unique.

 𝑆𝑝: The start activity of p.  𝐸𝑝: The end activity of p.

𝑆𝑝, 𝐸𝑝 ∈ 𝑉𝑝.

(19)

Definition 3.2 (Activity Fundamental Properties)

∀v ∈ 𝑉𝑝, there are two fundamental properties in v:

 v.type ∈ {Task, ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin, LoopSubProcess, SubProcess}.

 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣: A stack stores all the control blocks and branches where v resides. (The

control block and branch are defined further in Definition 3.4 and 3.6.)

For each activity v ∈ 𝑉𝑝, the property 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is a new feature and its usage is illustrated in Definition 3.9. The property v.type represents v‟s type. If v.type is SubProcess or LoopSubProcess, v is a compound activity. Definition 3.3 below introduces a new feature: subp to a compound activity.

Definition 3.3 (Compound Activity)

∀ v ∈ 𝑉𝑝, v is a compound activity when v.type ∈ {SubProcess, LoopSubProcess}.  v.type ∈ {SubProcess, LoopSubProcess}

 v.subp : The sub-process included within v.

In our model, there are three types control blocks, ”ROOT Control Block”, “AND Control Block”, and “XOR Control Block”, and the properties to record the execution order of these blocks are defined in Definition 3.4. Further, for an activity v, v is contained in c when v is reachable from c.start and c.end is reachable from v. For a flow f = (u, v) ∈ 𝐹𝑝, f is

(20)

Definition 3.4 (Control Block)

A control block c = (start, end, type)∈𝐶𝑝, where

 c.start = 𝑣𝑠, 𝑣𝑠 ∈ 𝑉𝑝 and 𝑣𝑠.type ∈ {ProcessStart, XorSplit, AndSplit}  c.end = 𝑣𝑒, 𝑣𝑒 ∈ 𝑉𝑝 and 𝑣𝑒.type =

ProcessEnd if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = ProcessStart XorJoin if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = XorSplit

AndJoin if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = AndSplit  𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑒

∄ v ∈ 𝑉𝑝, v.type ∈{ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin}, IsReachable(c.start, v) = ture, IsReachable(v, c.end) = ture, and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠.

 c.type ∈ {ROOT, AND, XOR}  c.type =

ROOT if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = ProcessStart

XOR if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = XorSplit AND if 𝑣𝑠. 𝑡𝑦𝑝𝑒 = AndSplit

 c.bcounter is a counter of branch id. The value of bcounter for c is set to 0 at the beginning of c‟s construction.

 c.totalbranches = outflows of 𝑐. 𝑠𝑡𝑎𝑟𝑡 . (The outflow is defined in Definition 3.7.)

For each control block c ∈ 𝐶𝑝, the properties c.start and c.end represent the start activity and end activity of c separately. If activity 𝑣𝑠 is the start activity and 𝑣𝑒 is the end activity, the following properties hold:

(a) 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑒.

(b) There is no such an activity v ∈ 𝑉𝑝, v.type∈{ProcessStart, ProcessEnd, XorSplit, XorJoin, AndSplit, AndJoin}, v is reachable from 𝑣𝑠, 𝑣𝑒 is reachable from v, and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣𝑠.

(21)

returns false. The function is defined in Definition 3.11.

Based on the type of c.start, the property c.type is one of the following types: “ROOT”, “AND”, and “XOR”. The property c.bcounter is a new feature and is used to count branch ids. The value of c.bcounter is increased by one when a new branch is added into c. The property c.totalbranches represents the number of branches in c.

Each process is only allowed to contain one root control block R. For a process p, p.start = ps, p.end = pe, the root control block R = (ps, pe, ROOT) and R.totalbranches is always 1.

Based on the Definition 3.4, a control activity is defined in Definition 3.5.

Definition 3.5 (Control Activity)

∀ v ∈ 𝑉𝑝, v is a control activity.

 v.type ∈ {ProcessStart, ProcessEnd, AndSplit, AndJoin, XorSplit, XorJoin}.

 v is the start activity of a control block if v.type ∈ {ProcessStart, AndSplit, XorSplit}.

 v is the end activity of a control block if v.type ∈ {ProcessEnd, AndJoin, XorJoin}.  v.cb represents the id of the block beginning from or ending at v.

 v.cb = R if v.type ∈ {ProcessStart, ProcessEnd}.

In addition, if an activity v ∈ 𝑉𝑝 is neither a control activity nor a compound activity, v is a task activity and v.type = Task.

Based on Definition 3.5, a branch in a control block is basically a path. Also the path begins at the start activity of the control block, and ends at the end activity of the control

(22)

block. In order to identify different branches in a control block, each branch contains a property id. When a new branch b is added into a control block c, c.bcounter is added by one and is set value of b.id. A branch is defined in Definition 3.6.

Definition 3.6 (Branch)

In a control block c which is not sequence, a branch b = (𝑣1, …, 𝑣𝑘), k≥2, where  ∃flow (𝑣𝑖, 𝑣𝑖+1) ∈ 𝐹𝑝, i = 1, 2, …, k-1

 𝑣1 = c.start  𝑣𝑘 = c.end

 b.id represents the id of b.

A flow in workflow specification represents the execution order of activities and is defined in Definition 3.7.

Definition 3.7 (Flow)

∀ f = (u, v) ∈ 𝐹𝑝, where u, v ∈ 𝑉𝑝.

 u is the source activity of f, and v is the sink activity of f.  f is an inflow of v and an outflow of u.

Figure 3.1 shows the corresponding notations of control activities, task activity, sub-process activity, loop sup-process activity, and flow.

(23)

Figure 3.1: Notations of Control Flow Graph.

Figure 3.2: An Example of Control Flow Graph.

Figure 3.2 shows an example of a well-formed control flow. In Figure 3.2, each activity is associated with an Ancestor Block Stack, ABStack, showing the control blocks where the activity resides. The properties about the relations between elements in an ABStack are described after illustrating the elements in Definition 3.8. Since all activities are contained in root control block R and R.totalbranches is always 1, an element (R, 1) is in the bottom of

(R, 1) (R, 1) 𝑣1 𝑣3 𝑣6 𝑣4 𝑣5 𝑣2 ps as1 pe xs1 aj1 xj1 (a1, 1) (R, 1) (x1, 1) (a1, 1) (R, 1) (x1, 2) (a1, 1) (R, 1) (a1, 1) (R, 1) (a1, 2) (R, 1) (a1, 2) (R, 1) (R, 1) (R, 1) (R, 1) (R, 1) 1 1 1 2 1 2 2 2 1 2 1 1 1 Branch’ id ABStack

Control Block a1 = (as1, aj1, AND) as1.cb = aj1.cb = a1 Control Block x1 = (xs1, xj1, XOR) xs1.cb = xj1.cb = x1 Control Block R = (ps, pe, ROOT) ps.cb = pe.cb = R

ProcessStart ProcessEnd AndSplit AndJoin XorSplit XorJoin Task

Sub-Process Loop Sub-Process Flow

(24)

each ABStack. For an activity v, each element in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 marks a control block containing v. An element inside an ABStack is formally defined in Definition 3.8.

Definition 3.8 (The element inside an ABStack)

An element e inside 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 contains two tuples (blockID, branchID),  blockID represents a control block containing v.

 branchID represents the id of the branch after the initial control activity of blockID.

An ABStack has the following properties:

1. Assume two elements, e1 and e2, exist in an ABStack. Element e1 is above e2 if and only if the block represented by the first tuple of e1 is contained in that represented by e2. For example, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2 in Figure 3.2 has two elements e1=(x1, 1) and e2=(a1, 1). Because x1 is contained in a1, e1 is above e2. By reading the elements top-down in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2, it is found that 𝑣2 is located on branch 1 of x1, x1 is located on branch 1 of a1, and a1 is

located in R. Thus, the 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣2 can be used to represent the location of activity 𝑣2.In this case, because x1 is contained in a1, x1 is deeper than a1 in this nested control blocks structure. In the same reason, because a1 is contained in R, a1 is deeper than R. Therefore, x1 is the deepest control block which contains 𝑣2 because x1 does not contain any control block.

2. Consider 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣, if there are some elements contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 but not in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣, u is contained in the blocks represented by the elements but v is not. For example, element (x1, 1) is contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝐵 but not contained in 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑥𝑗 1 in Figure 3.2. Therefore, control block x1 contains activity 𝑣2 but not

(25)

The operations associated with ABStack are defined in Definition 3.9. The construction of an ABStack is described in Algorithm 3.1.

Definition 3.9 (The operations associated with an ABStack)

The operations associated with an ABStack include:

1. push(E: element): Pushing an element into the top of ABStack. 2. pop(): Popping an element out from the top of ABStack.

3. isEmpty(): If the ABStack = ∅, return true. Otherwise return false.

4. getTopXOR(): Getting the first element from the top of ABStack and the type of the block associated with the element is XOR. For example, let 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = , x1 and x2 be XOR control blocks, a2 be an AND control block, then 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.getTopXOR() = (x2, 2).

5. removeIdenticalElements(A: ABStack): Removing the same elements in both A and the target ABStack. For example, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = and 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 = , 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢) = .

Algorithm 3.1 (Construction of an ABStack)

∀ v ∈ 𝑉𝑝, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is constructed by the following steps:

Algorithm ConstructABStack(v){

1. if(v.type == ProcessStart){

2. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣= ;

3. }else if(v.type ≠ ProcessStart and ∃inflow f=(u, v) ∈ 𝐹𝑝 and f is located in branch b){ 4. if(u.type ∉ {XorSplit, AndSplit}){

5. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢;

6. }else{

7. Create an element e1 = (u.cb, b.id); 8. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢.push(e1); 9. } (a2, 1) (x2, 2) (x1, 1) (a2, 1) (x2, 2) (R, 1) (x2, 2) (R, 1) (a2, 1) (R, 1)

(26)

10. if(v.type ∈ {XorJoin, AndJoin})

11. 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣.pop(); 12. }

13. } }

At line 1 to 2, if the type of v is ProcessStart, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 only contains one element(R, 1). If the type of v is not ProcessStart, v has inflow(s). Let f be the inflow (u, v) and f be located in branch b. If v has multiple inflows, random one of them is assigned to f. At line 4 to 9, if the type of u is not XorSplit and AndSplit, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 = 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢. Otherwise, u is the start activity of a control block. Hence, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 is equal to 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢 which is added an element (u.cb, b.id). At line 10 to 12, if the type of v is XorJoin or AndJoin, v is the end activity of a control block. Thus, 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣 pops an element.

3.2 Relations between Activities and Control Blocks

In a process, there are relations between activities and control blocks; e.g. path, reachability, etc. These relations are defined in the following definitions.

Definition 3.10 (Path)[17]

A path q = (𝑣1, … , 𝑣𝑘) in which 𝑘 ≥ 2 and the flow f = (𝑣𝑖, 𝑣𝑖+1) for i=1,2,...,k-1 ∈ 𝐹𝑝. The path from 𝑣1 to 𝑣𝑘 is denoted by 𝑃𝑎𝑡ℎ(𝑣1, 𝑣𝑘).

Definition 3.11 (Reachability)[17]

Given two activities u and v, 𝐼𝑠𝑅𝑒𝑎𝑐ℎ𝑎𝑏𝑙𝑒(𝑢, 𝑣) is a Boolean function that indicates whether there is a path from u to v. I.e.,

(27)

Definition 3.12 (Predecessors and Successors)

𝑉𝑣𝑖𝑠𝑃𝑟𝑒𝑑𝑒𝑐𝑒𝑠𝑠𝑜𝑟 = {𝑢 ∈ 𝑉

𝑝 | 𝐼𝑠𝑅𝑒𝑎𝑐ℎ𝑎𝑏𝑙𝑒 𝑢, 𝑣 = 𝑡𝑟𝑢𝑒}

𝑉𝑣𝑖𝑠𝑆𝑢𝑐𝑐𝑒𝑠𝑠𝑜𝑟 = 𝑢 ∈ 𝑉

𝑝 𝐼𝑠𝑅𝑒𝑎𝑐ℎ𝑎𝑏𝑙𝑒 𝑣, 𝑢 = 𝑡𝑟𝑢𝑒}

𝑉𝑣𝑖𝑠𝑃𝑟𝑒𝑑𝑒𝑐𝑒𝑠𝑠𝑜𝑟 is a set of activities and v is reachable from each activity in

𝑉𝑣𝑖𝑠𝑃𝑟𝑒𝑑𝑒𝑐𝑒𝑠𝑠𝑜𝑟 . Each activity u in 𝑉

𝑣𝑖𝑠𝑃𝑟𝑒𝑑𝑒𝑐𝑒𝑠𝑠𝑜𝑟 is called a predecessor of v. 𝑉𝑣𝑖𝑠𝑆𝑢𝑐𝑐𝑒𝑠𝑠𝑜𝑟

denotes the transitive closure of 𝑉𝑣𝑖𝑠𝑃𝑟𝑒𝑑𝑒𝑐𝑒𝑠𝑠𝑜𝑟 .

Definition 3.13 (Parallel Activities)

Given two activities u and v, IsParallel(u, v) is a Boolean function to represent if u and v might be executed in parallel.

𝐼𝑠𝑃𝑎𝑟𝑎𝑙𝑙𝑒𝑙 𝑢, 𝑣 = 𝑡𝑟𝑢𝑒 ↔ ∃𝑒1 ∈ 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢, 𝑒2 ∈ 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣

𝑒1. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷 = 𝑒2. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷 𝑒1. 𝑏𝑟𝑎𝑛𝑐ℎ𝐼𝐷 ≠ 𝑒2. 𝑏𝑟𝑎𝑛𝑐ℎ𝐼𝐷 𝑒1. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷. 𝑡𝑦𝑝𝑒 = AND

Definition 3.14 (Exclusive Activities)

Given two activities u and v, IsExclusive (u, v) is a Boolean function to represent if u is selected for execution then v won‟t be selected for execution and vice versa.

𝐼𝑠𝐸𝑥𝑐𝑙𝑢𝑠𝑖𝑣𝑒 𝑢, 𝑣 = 𝑡𝑟𝑢𝑒 ↔ ∃𝑒1 ∈ 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢, 𝑒2 ∈ 𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣

𝑒1. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷 = 𝑒2. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷 𝑒1. 𝑏𝑟𝑎𝑛𝑐ℎ𝐼𝐷 ≠ 𝑒2. 𝑏𝑟𝑎𝑛𝑐ℎ𝐼𝐷 𝑒1. 𝑏𝑙𝑜𝑐𝑘𝐼𝐷. 𝑡𝑦𝑝𝑒 = XOR

To simplify our analysis, the workflow specifications discussed in this thesis are well-formed. A well-formed workflow has four basic control structures: sequential, exclusive split, parallel split, and loop. The control blocks defined in Definition 3.4 can be used to represent exclusive split, and parallel split structures. As in BPMN [18], a loop structure can be replaced by a loop sub-process activity in our model.

(28)

Figure 3.3: Using a Loop Sub-Process Activity to Replace a Loop Structure.

Figure 3.3 (a) shows an example of a well-formed control flow and activities 𝑣2, 𝑣3, and 𝑣4 are located in a loop structure. In Figure 3.3 (b), a loop sub-process activity 𝑣6 is used to replace the loop structure and 𝑣6 contains a sub-process including 𝑣2, 𝑣3, and 𝑣4 in Figure 3.3 (c). Therefore, there is no cycle in a control flow graph in our model; i.e. a control flow graph in our model is a directed acyclic graph (DAG).

3.3 Artifact Flow Diagram Specification

As identified in [11], there are three models used to define artifact flow transmission in a workflow: (1) Global Data Store (GDS), (2) Integrated Control and Data Channels (ICDC), and (3) Distinct Control and Data Channels (DCDC). Since DCDC is more flexible for representing artifact flow, DCDC is adapted to express artifact flow in this thesis.

𝑣1 ps pe 𝑣2 𝑣3 𝑣4 𝑣5 (a) (b) (c) 𝑣1 ps pe 𝑣5 Loop Sub-Process 𝑣6 𝑣2 ps2 pe2 𝑣4 𝑣3 Sub-Process within 𝑣6

(29)

In this thesis, a verb “pass” is used to represent the action about sending an artifact to another activity [11]. For example, if an artifact d is sent from an activity v to u, it is described as that activity v passes artifact d to u. In other words, activity u receives artifact d from v.

In DCDC, artifacts are passed between activities via explicit channels [16] which are distinct from control flows. Hence, each artifact has a corresponding artifact flow diagram representing the artifact usages and transmissions in a workflow. In addition, artifacts transfers are passed by value in our model and an activity starts execution when it receives all necessary artifacts.

3.3.1 Artifact Operations and Usages

Artifacts are collections of data items involved in a process. Intuitively, all artifacts participating in a workflow execution are pre-defined in the process specification. Each artifact contains a set of legal operations for its internal data, and is applied in an activity to perform them. In the aspect of data usage, artifact operations can be conceptually classified as initialize, read, update, and delete [15].

Because artifacts are passed between activities via explicit channels distinct from control flows, activities can decide where the artifacts are passed. Here, an operation Pass(), passing an artifact to another activity, is defined. Let 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣 denote a linked list to record the pass operations in an activity v. Thus, Pass(d, u)∈ 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣 if and only if v passes artifact d

to activity u. In this case, v is a sender of d and u is a receiver of d.

Besides, the receiver can not receive the artifact if the receiver is executed before the sender. Hence, an activity can not pass artifacts to its predecessors.

(30)

For an activity v, the operations Pass() in 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣 are performed only when all the other operations, such as initialize, read, update, and delete, are completed.

In our model, artifact transfers are passed by value, more than one copy of an artifact may exist in a workflow. For example, given an artifact d and activities v, u, w, if Pass(d, u) and Pass(d, w) are contained in 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣, activities u and w will receive d separately. This case is called artifact split and there are two copies of d sent out after v.

In order to identify the artifact usages in an activity, each activity contains the following input and output artifacts sets: 𝐼, 𝑂, 𝑈+, and 𝑈−. These sets are defined in Definition 3.15.

Definition 3.15 (Input and Output Artifacts Sets)

For an activity v, v contains the following sets:

 𝐼𝑣 is a set of artifacts, of which each is read, updated, or deleted in v.

 𝑂𝑣 is a set of artifacts, of which each is passed from v after v‟s executing.  𝑈𝑣+ is a set of artifacts, of which each is initialized or updated in v.

 𝑈𝑣 is a set of artifacts, of which each is deleted in v.

To simplify our discussion, an activity v can be classified into the following roles of d: Producer, Reader, Updater, Destroyer, Irrelevantor, and Relevantor, based on the memberships between an artifact d and 𝐼𝑣, 𝑂𝑣, 𝑈𝑣+, and 𝑈𝑣−. Definition 3.16 shows how to identify these roles.

(31)

Definition 3.16 (Roles of an Activity in an Artifact Flow Diagram)

For an activity v, 𝑅𝑜𝑙𝑒𝑣𝑑 denotes v‟s role of d. Roles(v, d) is a function to identify v‟s role of d. All the possible usages are categorized as follows:

if(v.type ∉ {PrcoessStart, ProcessEnd}){

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Producer when d ∉ 𝐼

𝑣 and d ∈ 𝑈𝑣+.

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Destroyer when d ∈ 𝐼𝑣 and d ∈ 𝑈𝑣−.

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Reader when 𝑑 ∈ 𝐼

𝑣 and 𝑑 ∉ 𝑈𝑣 +

𝑑 ∉ 𝑈𝑣− .

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Updater when d ∈ 𝐼

𝑣 and d ∈ 𝑈𝑣+.

 When 𝑑 ∉ 𝐼𝑣 and 𝑑 ∉ 𝑈𝑣

+

𝑑 ∉ 𝑈𝑣− .

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Relevantor, if 𝑑 ∈ 𝑂𝑣 or ∃u∈𝑉𝑝 and

Pass(d, v)∈𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑢,.

 𝑅𝑜𝑙𝑒𝑣𝑑 = Roles(v, d) = Irrelevantor, if 𝑑 ∉ 𝑂𝑣 or ∄u∈𝑉𝑝 and

Pass(d, v)∈𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑢,.

}

if(v.type ∈ {PrcoessStart, ProcessEnd}){  For a ProcessStart Activity ps :

 𝑅𝑜𝑙𝑒𝑝𝑠𝑑 = Roles(ps, d) = Producer when 𝑑 ∈ 𝑂 𝑝𝑠.

 𝑅𝑜𝑙𝑒𝑝𝑠𝑑 = Roles(ps, d) = Irrelevantor when 𝑑 ∉ 𝑂𝑝𝑠.

 For a ProcessEnd Activity pe :

 𝑅𝑜𝑙𝑒𝑝𝑒𝑑 = Roles(pe, d) = Destroyer when ∃u∈𝑉𝑝 and Pass(d, pe)∈𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑢.

 𝑅𝑜𝑙𝑒𝑝𝑒𝑑 = Roles(pe, d) = Irrelevantor when ∄u∈𝑉

𝑝 and Pass(d, pe)∈𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑢.

(32)

3.3.2 Artifact Flow Diagrams

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

Definition 3.17 (An Artifact Flow Diagram)

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

𝑝𝑑, 𝐴𝐹𝑁𝑝𝑑), where

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

 𝐴𝐹𝐹𝑝𝑑 is a set of flows. For a flow (u, v)∈𝐴𝐹𝐹

𝑝𝑑 and u, v ∈𝐴𝐹𝑉𝑝𝑑, a Pass(d, v)

𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑢.

 𝐴𝐹𝑁𝑝𝑑 is a set of XBNodes existing in the artifact flow diagram. An XBNode is

introduced in the following paragraphs and is defined in Definition 3.19.

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

(33)

𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 be a set of activities, of which each passes d to v. Let 𝑆𝑒𝑛𝑑

𝑣𝑑 be a set of activities,

of which each receives d from v. Therefore, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 represents the number of inflows of

v in the artifact flow diagram for d. On the contrary, 𝑆𝑒𝑛𝑑𝑣𝑑 represents the number of outflows of v in the artifact flow diagram for d.

However, some activities in 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 might not pass d to v in run time. Therefore, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 is not always equal to the number of d received in v. Similarly, 𝑆𝑒𝑛𝑑

𝑣𝑑 is not

always equal to the number of d passed from v. In Figure 3.4 (a), (b), and (c), activity 𝑣1 passes artifact d to 𝑣2 and 𝑣3 respectively. Hence, their artifact flow diagrams for d in Figure 3.4 (d) contain activities: 𝑣1, 𝑣2, and 𝑣3, and flows: (𝑣1, 𝑣2) and (𝑣1, 𝑣3). 𝑆𝑒𝑛𝑑𝑣𝑑1 = {𝑣2, 𝑣3} and 𝑆𝑒𝑛𝑑𝑣𝑑1 = 2 in Figure 3.4 (a), (b), and (c).

In Figure 3.4 (a), because 𝑣2 and 𝑣3 are parallel activities, the number of d passed from 𝑣1 is 2. In Figure 3.4 (b), because 𝑣2 and 𝑣3 are exclusive activities, the number of d passed from 𝑣1 is 1. In Figure 3.4 (c), 𝑣2, 𝑣3, and 𝑣5 are exclusive activities and 𝑣1 does not pass d to 𝑣5. Therefore, the number of d passed from 𝑣1 is 0 if 𝑣5 is selected to execute. Otherwise, the number of d passed from 𝑣1 is 1. Obviously, the number of d passed from 𝑣1 is not always equal to 𝑆𝑒𝑛𝑑𝑣𝑑1 . The artifact flow diagram in Figure 3.4 (d) is ambiguous to

(34)

Figure 3.4: An Artifact Flow Diagram without XBNodes.

In order to solve this problem, the activities in 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 are categorized into two sets: 𝐸𝐼𝑁𝑣𝑑 and 𝑃𝐼𝑁

𝑣𝑑. 𝑃𝐼𝑁𝑣𝑑 contains the activities passing d to v potentially. 𝐸𝐼𝑁𝑣𝑑 contains

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

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

𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1= Pass(d, 𝑣2) → Pass(d, 𝑣3)

(a) Control Block a1 = (as1, aj1, AND) as1.cb = aj1.cb = a1 (b),(c) Control Block x1 = (xs1, xj1, XOR) xs1.cb = xj1.cb = x1

𝑣1 𝑣2 𝑣3 (a) (b) (c) (d) 𝑣1 𝑣2 𝑣3 𝑣4 as1 aj1 𝑣1 𝑣2 𝑣3 𝑣4 xs1 xj1 𝑣1 𝑣2 𝑣3 𝑣4 𝑣5 xs1 xj1 𝑆𝑒𝑛𝑑𝑣𝑑1 = {𝑣 2, 𝑣3}

(35)

Definition 3.18 (Receiving/Sending Sets)

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

 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 = {u∈𝐴𝐹𝑉

𝑝𝑑| ∃flow (u, v) ∈𝐴𝐹𝐹𝑝𝑑}

 𝑃𝐼𝑁𝑣𝑑 =

{u∈𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑| (∃e∈𝐴𝐵𝑆𝑡𝑎𝑐𝑘

𝑢.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣)) and

e.blockID.type = XOR and IsExclusive(u, v) ≠ true}  𝐸𝐼𝑁𝑣𝑑 = {u∈(𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑\𝑃𝐼𝑁𝑣𝑑) | IsExclusive(u, v) ≠ true}

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

 𝑃𝑂𝑈𝑇𝑣𝑑 =

{u∈𝑆𝑒𝑛𝑑𝑣𝑑| (∃e ∈𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑢.removeIdenticalElements(𝐴𝐵𝑆𝑡𝑎𝑐𝑘𝑣)) and

e.blockID.type = XOR and IsExclusive(v, u) ≠ true}  𝐸𝑂𝑈𝑇𝑣𝑑 = {u∈(𝑆𝑒𝑛𝑑𝑣𝑑\𝑃𝑂𝑈𝑇𝑣𝑑) | IsExclusive(v, u) ≠ true}

For a flow (u, v) ∈ 𝐴𝐹𝐹𝑝𝑑, if u and v are exclusive activities, u and v can not both be

executed. Therefore, v can not receive d from u. For this reason, u is not added into 𝑃𝐼𝑁𝑣𝑑 and 𝐸𝐼𝑁𝑣𝑑 when IsExclusive(u, v) = true. Similarly, u is not added into 𝑃𝑂𝑈𝑇𝑣𝑑 and 𝐸𝑂𝑈𝑇𝑣𝑑 when IsExclusive(v, u) = true. Based on Definition 3.18, Figure 3.5 shows the

(36)

Figure 3.5: An Example of Receiving and Sending Sets.

Further, the XOR Control Block Nodes, XBNodes, are used to replace the activities located in the same XOR control block in 𝑃𝐼𝑁𝑣𝑑/𝑃𝑂𝑈𝑇𝑣𝑑. For example in Figure 3.5 (b), 𝑣2 and 𝑣3 in 𝑃𝑂𝑈𝑇𝑣𝑑1 are contained by XOR control block x1. Whether 𝑣2 or 𝑣3 is selected to execute in x1, 𝑣1 always passes d to x1. Therefore, an unconditional XBNode n1 is used to replace 𝑣2 and 𝑣3 in 𝑃𝑂𝑈𝑇𝑣𝑑1. Because 𝑣1 passes d to x1 explicitly, n1 is moved to 𝐸𝑂𝑈𝑇𝑣𝑑1 from 𝑃𝑂𝑈𝑇

𝑣𝑑1. In Figure 3.5 (c), 𝑣2 and 𝑣3 in 𝑃𝑂𝑈𝑇𝑣𝑑1 are contained by XOR

control block x1. However, 𝑣1 does not pass d to x1 when 𝑣5 is selected to execute in x1. Hence, a conditional XBNode n2 is used to replace 𝑣2 and 𝑣3 in 𝑃𝑂𝑈𝑇𝑣𝑑1. The detailed algorithms of construction of XBNodes are illustrated in Section 5.3.

𝑃𝐼𝑁′ 𝑣 𝑑

and 𝐸𝐼𝑁′𝑣𝑑 are used to represent 𝑃𝐼𝑁𝑣𝑑 and 𝐸𝐼𝑁𝑣𝑑 whose activities are all replaced with XBNodes and all unconditional XBNodes are moved from 𝑃𝐼𝑁𝑣𝑑 to 𝐸𝐼𝑁𝑣𝑑.

(a) (b) (c) 𝑣1 𝑣2 𝑣3 𝑣4 as1 aj1 𝑣1 𝑣2 𝑣3 𝑣4 xs1 xj1 𝑣1 𝑣2 𝑣3 𝑣4 𝑣5 xs1 xj1 𝑆𝑒𝑛𝑑𝑣𝑑1 = {𝑣 2, 𝑣3} 𝐸𝑂𝑈𝑇𝑣𝑑1 = {𝑣 2, 𝑣3} 𝑃𝑂𝑈𝑇𝑣𝑑1 = ∅ 𝑆𝑒𝑛𝑑𝑣𝑑1 = {𝑣 2, 𝑣3} 𝐸𝑂𝑈𝑇𝑣𝑑1 = ∅ 𝑃𝑂𝑈𝑇𝑣𝑑1 = {𝑣 2, 𝑣3} 𝑆𝑒𝑛𝑑𝑣𝑑1 = {𝑣 2, 𝑣3} 𝐸𝑂𝑈𝑇𝑣𝑑1 = ∅ 𝑃𝑂𝑈𝑇𝑣𝑑1 = {𝑣 2, 𝑣3} 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1= Pass(𝑣2, d) → Pass(𝑣3, d)

(a) Control Block a1 = (as1, aj1, AND) as1.cb = aj1.cb = a1 (b),(c) Control Block x1 = (xs1, xj1, XOR) xs1.cb = xj1.cb = x1

(37)

Therefore, the number of d passed/received from/in v can be identified. Let 𝑁𝐼𝑁𝑣𝑑 be the number of d received in v, then 𝐸𝐼𝑁′𝑣𝑑 ≤ 𝑁𝐼𝑁𝑣𝑑 ≤ 𝐸𝐼𝑁′𝑣𝑑 + 𝑃𝐼𝑁′𝑣𝑑. Similarly, let 𝑁𝑂𝑈𝑇𝑣𝑑 be the number of d passed from v, then 𝐸𝑂𝑈𝑇′𝑣𝑑 ≤ 𝑁𝑂𝑈𝑇𝑣𝑑 ≤ 𝐸𝑂𝑈𝑇′𝑣𝑑 +

𝑃𝑂𝑈𝑇′ 𝑣

𝑑 . Figure 3.6 shows the artifact flow diagrams with XBNodes.

Figure 3.6: An Artifact Flow Diagram with XBNode.

In Figure 3.6 (d), because 𝐸𝑂𝑈𝑇′ 𝑣1

𝑑 = 2 and 𝑃𝑂𝑈𝑇 𝑣1

𝑑 = 0, the number of d passed

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

𝑣1 𝑣2 𝑣3 : Unconditional XBNode : Conditional XBNode (a) (b) (c) (d) (e) (f) 𝑣1 𝑣2 𝑣3 𝑣4 as1 aj1 𝑣1 𝑣2 𝑣3 𝑣4 xs1 xj1 𝑣1 𝑣2 𝑣3 𝑣4 𝑣5 xs1 xj1 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1= Pass(𝑣2, d) → Pass(𝑣3, d)

(a) Control Block a1 = (as1, aj1, AND) as1.cb = aj1.cb = a1 (b),(c) Control Block x1 = (xs1, xj1, XOR) xs1.cb = xj1.cb = x1

𝑣1 𝑣2 𝑣3 n1 𝑣1 𝑣2 𝑣3 n2 𝐸𝑂𝑈𝑇′ 𝑣1 𝑑 = {𝑣 2, 𝑣3} 𝑃𝑂𝑈𝑇′ 𝑣1 𝑑 = ∅ 𝐸𝑂𝑈𝑇′ 𝑣1 𝑑 = {n1} 𝑃𝑂𝑈𝑇′ 𝑣1 𝑑 = ∅ 𝐸𝑂𝑈𝑇′ 𝑣1 𝑑 = ∅ 𝑃𝑂𝑈𝑇′ 𝑣1 𝑑 = {n2}

(38)

Definition 3.19 (An XOR Block Node)

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

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

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

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

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

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

Based on above definitions, a flow in an artifact flow diagram contains the following properties: outBlock and inBlock. The property outBlock/inBlock is the id of an XBNode which contains sink/source activity. For example, let f be the flow (𝑣1, 𝑣2) in Figure 3.6 (e). The f.outBlock = n1 because 𝑣3∈ n1.cv_set. Definition 3.20 defines a flow in an artifact flow

diagram.

Definition 3.20 (A Flow in an Artifact Flow Diagram)

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

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

(39)

3.3.3 An Example of an Artifact Flow Diagram

Figure 3.7 shows an example of a control flow graph including PassList, 𝐼, 𝑂, 𝑈+, and 𝑈− for each activity.

Figure 3.7: An Example of a Control Flow Graph.

Figure 3.8 shows the artifact flow diagram for d extracted from Figure 3.7. Because 𝑅𝑜𝑙𝑒𝑥𝑠1𝑑 = Irrelevantor and 𝑅𝑜𝑙𝑒

𝑥𝑗 1𝑑 = Irrelevantor, control activities xs1 and xj1 are not

added into the artifact flow diagram.

There are three types of flows in an artifact flow diagram:

(1) Normal Flow: ∀flow (u, v)∈𝐴𝐹𝐹𝑝𝑑, IsParallel(u, v) = false and IsExclusive(u, v) = false.

(2) AND Flow: ∀flow (u, v)∈𝐴𝐹𝐹𝑝𝑑, IsParallel(u, v) = true.

(3) XOR Flow: ∀flow (u, v)∈𝐴𝐹𝐹𝑝𝑑, IsExclusive(u, v) = true.

𝑣2 𝑣3 𝑣4 𝑣5 𝑣1 xs1 xj1 𝑣6 (R, 1) (R, 1) (x1, 1) (R, 1) (x1, 2) (R, 1) (R, 1) (R, 1) xs1.cb = xj1.cb = x1 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣1= Pass(𝑣2, d) d ∉𝐼𝑣1 d ∈𝑈𝑣+1 d ∉𝑈𝑣1 d ∈𝑂𝑣1 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣2= Pass(𝑣3, d)→Pass(𝑣4, d) d ∈𝐼𝑣2 d ∉𝑈𝑣+2 d ∉𝑈 𝑣−2 d ∈𝑂𝑣2 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣3= Pass(𝑣5, d)→Pass(𝑣4, d) d ∈𝐼𝑣3 d ∉𝑈𝑣+3 d ∉𝑈 𝑣−3 d ∈𝑂𝑣3 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣4= Pass(𝑣5, d)→Pass(𝑣6, d) d ∈𝐼𝑣4 d ∈𝑈𝑣+4 d ∉𝑈 𝑣−4 d ∈𝑂𝑣4 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣5= Pass(𝑣6, d) d ∈𝐼𝑣5 d ∉𝑈𝑣+5 d ∈𝑈 𝑣−5 d ∈𝑂𝑣5 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣6= ∅ d ∉𝐼𝑣6 d ∉𝑈𝑣+6 d ∉𝑈 𝑣−6 d ∉𝑂𝑣6

(40)

Figure 3.8: The Corresponding Artifact Flow Diagram for d.

Table 3.1 shows all states of each activity in Figure 3.7.

Activities 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑 𝐸𝐼𝑁′𝑣𝑑 𝑃𝐼𝑁′𝑑𝑣 𝑆𝑒𝑛𝑑𝑣𝑑 𝐸𝑂𝑈𝑇′𝑣𝑑 𝑃𝑂𝑈𝑇′𝑣𝑑 𝑣1 ∅ ∅ ∅ {𝑣2} {𝑣2} ∅ 𝑣2 {𝑣1} {𝑣1} ∅ {𝑣3, 𝑣4} {n1} ∅ 𝑣3 {𝑣2} {𝑣2} ∅ {𝑣4, 𝑣5} {𝑣5} ∅ 𝑣4 {𝑣2, 𝑣3} {𝑣2} ∅ {𝑣5, 𝑣6} {𝑣5, 𝑣6} ∅ 𝑣5 {𝑣3, 𝑣4} {n2} ∅ {𝑣6} {𝑣6} ∅ 𝑣6 {𝑣4, 𝑣5} {𝑣5} {n3} ∅ ∅ ∅

Table 3.1: The States of Each Activity in Figure 3.7.

In Table 3.1, 𝑣3 passes d to 𝑣4 and 𝑣5; thus, 𝑆𝑒𝑛𝑑𝑑𝑣3 = {𝑣4, 𝑣5}. However, 𝑣3 and 𝑣4 are exclusive activities. Activity 𝑣4 is not added into 𝐸𝑂𝑈𝑇𝑣𝑑3 or 𝑃𝑂𝑈𝑇𝑣𝑑3. Therefore, 𝐸𝑂𝑈𝑇′

𝑣3 𝑑 = {𝑣

5} and 𝑃𝑂𝑈𝑇′𝑣3 𝑑

= ∅. On the other hand, 𝑣6 receives d from 𝑣4 and 𝑣5; thus, 𝑅𝑒𝑐𝑒𝑖𝑣𝑒𝑣𝑑6 = {𝑣4, 𝑣5}. Activity 𝑣6 can not receive d from 𝑣4 when 𝑣4 is not

: Normal Flow : Activity

: AND Flow : Unconditional XBNode : XOR Flow : Conditional XBNode

𝑣3 Reader 𝑣2 Reader 𝑣4 Updater 𝑣5 Destroyer 𝑣6 Relevantor n1 n2 n3 𝑣1 Producer

(41)

selected to execute. Activity 𝑣6 receives d from 𝑣4 potentially. Hence, 𝑣4 is added into 𝑃𝐼𝑁𝑣𝑑6. Since 𝑣6 can not receive d from x1 when 𝑣3 is selected to execute, a conditional n3

is used to replace 𝑣4 in 𝑃𝐼𝑁𝑣𝑑6. Finally, 𝐸𝐼𝑁′𝑑𝑣6 = {𝑣5} and 𝑃𝐼𝑁′𝑣𝑑6 = {n3}. Table 3.2 shows the states of each XBNode in Figure 3.7.

XBNodes blockID cv_set ABStack isUncond Parent Attached

n1 x1 {𝑣3, 𝑣4} true Null 𝑣2

n2 x1 {𝑣3, 𝑣4} true Null 𝑣5

n3 x1 {𝑣4} false Null 𝑣6

Table 3.2: The States of Each XBNode in Figure 3.8. (R, 1)

(R, 1) (R, 1)

(42)

Chapter 4. Artifact Usage Anomalies

In a process specification, there might be four classes of anomalies: (1) Missing Artifact Anomalies, (2) Artifact Conflict Anomalies, (3) Cross Passing Artifact Anomalies, and (4) Redundant Anomalies. These anomalies are defined in the following subsections. Besides, every class indicates several types of anomalies of which each is illustrated with an example to show the scenario.

4.1 MissingArtifact Anomalies

While an artifact d is used, including read, updated, deleted, or passed, in an activity v, a missing artifact anomaly occurs if v can not receive d in execution time. For a receiver activity, missing of an artifact can be divided into the two cases below:

(1) Explicit Missing Artifacts:

 Description: Activity v requires artifact d but can not receive d.  Conditions: 𝑣 ∈ 𝐴𝐹𝑉𝑝𝑑 ∧ 𝐸𝐼𝑁

𝑣

𝑑 = 0 ∧ 𝑃𝐼𝑁 𝑣 𝑑 = 0

∧ 𝑅𝑜𝑙𝑒𝑣𝑑 ∈ {Reader, Updater, Destroyer, Relevantor}

 Example: In the artifact flow of d in Figure 4.1, activity 𝑣2 is a reader of d.

Because no activity passes d to 𝑣2, 𝑣2 can not receive d. Therefore, 𝐸𝐼𝑁𝑣𝑑2 and 𝑃𝐼𝑁′

𝑣2

𝑑 are both 0. An explicit missing artifact anomaly occurs at 𝑣 2.

(43)

Figure 4.1: An Example of an Explicit Missing Artifact Anomaly.

(2) Implicit Missing Artifact:

 Description: Activity v requires artifact d but receives d implicitly; i.e. v might not receive d for beginning execution.

 Conditions: 𝑣 ∈ 𝐴𝐹𝑉𝑝𝑑 ∧ 𝐸𝐼𝑁′ 𝑣

𝑑 = 0 ∧ 𝑃𝐼𝑁 𝑣 𝑑 > 0

∧ 𝑅𝑜𝑙𝑒𝑣𝑑 ∈ {Reader, Updater, Destroyer, Relevantor}

 Example: In Figure 4.2, 𝑣2 is located in an XOR control block x1 and 𝑣2 passes

d to 𝑣4. If 𝑣2 is selected to execute in x1, 𝑣4 receives d. Otherwise, 𝑣4 can not receive d. Therefore, an implicit missing artifact anomaly occurs at 𝑣4.

Figure 4.2: An Example of an Implicit Missing Artifact Anomaly. Artifact Flow Diagram for d:

Control Flow Graph:

𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣2 = Pass(d, 𝑣4) d ∉𝐼𝑣2 d ∈𝑈𝑣+2 d ∉𝑈𝑣−2 d ∈𝑂𝑣2 𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣4 = ∅ d ∈𝐼𝑣4 d ∉𝑈𝑣+4 d ∉𝑈𝑣4 d ∉𝑂𝑣4 xs1.cb = xj1.cb = x1 𝑣2 Producer 𝑣4 Reader n1 𝑣1 𝑣2 𝑣4 𝑣3 xs1 xj1 (x1, 1) (R, 1) (R, 1) Control Flow Graph:

Artifact Flow Diagram for d:

𝑣2 Reader

𝑃𝑎𝑠𝑠𝐿𝑖𝑠𝑡𝑣2= ∅ d ∈𝐼𝑣2 d ∉𝑈𝑣+2 d ∉𝑈𝑣−2 d ∉𝑂𝑣2

𝑣1 𝑣2 𝑣3

數據

Figure 2.1: Three Major Artifact Transmission Models.
Figure  3.1  shows  the  corresponding  notations  of  control  activities,  task  activity,  sub-process activity, loop sup-process activity, and flow
Figure 3.3: Using a Loop Sub-Process Activity to Replace a Loop Structure.
Figure 3.5: An Example of Receiving and Sending Sets.
+7

參考文獻

相關文件

This research developed a model, which combines Fuzzy Delphi Method and Fuzzy Analytic Hierarchy Process, to evaluate building management company.. Important factors from the

We have presented a numerical model for multiphase com- pressible flows involving the liquid and vapor phases of one species and one or more inert gaseous phases, extending the

In this section, we consider a solution of the Ricci flow starting from a compact manifold of dimension n 12 with positive isotropic curvature.. Our goal is to establish an analogue

Therefore, in this research, we propose an influent learning model to improve learning efficiency of learners in virtual classroom.. In this model, teacher prepares

To convert a string containing floating-point digits to its floating-point value, use the static parseDouble method of the Double class..

To illustrate how LINDO can be used to solve a preemptive goal programming problem, let’s look at the Priceler example with our original set of priorities (HIM followed by LIP

“ Customer” ,employs the fuzzy analytic hierarchy process (FAHP) to develop a systematic model for the evaluations of knowledge management effectiveness , to reach the goal

The purpose of this thesis is to propose a model of routes design for the intra-network of fixed-route trucking carriers, named as the Mixed Hub-and-Spoke