UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A proposal for a process modeling methodology Wang, Qingyu 2002

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2003-0131.pdf [ 4.6MB ]
Metadata
JSON: 831-1.0090921.json
JSON-LD: 831-1.0090921-ld.json
RDF/XML (Pretty): 831-1.0090921-rdf.xml
RDF/JSON: 831-1.0090921-rdf.json
Turtle: 831-1.0090921-turtle.txt
N-Triples: 831-1.0090921-rdf-ntriples.txt
Original Record: 831-1.0090921-source.json
Full Text
831-1.0090921-fulltext.txt
Citation
831-1.0090921.ris

Full Text

A PROPOSAL FOR A PROCESS MODELING METHODOLOGY by Qingyu Wang B.Sc, Xi'an Electronic Sci. & Tech. University, PRC, 1990 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN BUSINESS ADMINISTRATION i n THE FACULTY OF GRADUATE STUDIES (Faculty of Commerce and Business Administration) We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA August 2002 © Qingyu Wang, 2002 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, 1 agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada Date 4><^y><r\o, Q-OO DE-6 (2/88) A B S T R A C T Process models are often used to describe organizational processes in contexts such as information system development, introduction of ERP (enterprise resource planning) systems, or the redesign of business processes. A technique for describing a process is termed a Process Modeling Language (PML). Current PMLs suffer from several shortcomings. First, different languages emphasize different aspects of processes, and thus might have problems in terms of their expressiveness. Second, many PMLs are intended to support information systems development, rather than model general business processes. As such, they may not have a complete set of clear concepts to represent real world processes. Third, often, PMLs provide a notation, but do not have rules to guide the construction of a process model. This thesis develops a theory-based process modeling methodology. The research starts by observing five PMLs: EPC (Event-controlled Process Chains), IDEFO (Integrated Definition 0), IDEF3 (Integrated Definition 3), UML (Unified Modeling Language) Activity Diagrams and the EDPM (Event-Driven Process Model) Method. Based on analyzing the constructs of these PMLs, the thesis identifies and defines a set of generic PML constructs and uses them to compare the five PMLs. It then analyzes the notion of a process based on Bunge's ontology (as adapted by Wand and Weber, and termed BWWP) and develops an ontology-based process model (termed OBPM). The analysis leads to two outcomes: a set of rules to map generic PML constructs to BWWP constructs, and a set of ontology-based integrity rules for building process models. The first outcome is used to evaluate the five PMLs in terms of completeness and clarity. The evaluation helps to clarify the basic ii concepts of each process modeling methodology and identify possible weaknesses. The second outcome is used to generate an ontology-based process modeling algorithm. This algorithm can be used to guide the construction of process models, where the integrity rules should be followed. Together, the generic process model, the mapping and integrity rules, and the algorithm provide for a theory-based process modeling methodology. The methodology provides the basic concepts, procedures and rules to build a generic process model, which covers all aspects of processes: functional, behavioral, organizational and informational. The integrity rules enable the checking of process models for semantic correctness. The algorithm provides a modeling procedure (based on the mapping rules) to create a process model for a given situation. Finally, the mapping rules and the algorithm can be used to point our missing information in models based on PMLs currently in use. iii T A B L E O F C O N T E N T S Abstract ii Table of contents iv List of Tables vii List of Figures viii Chapter one: Introduction 1 1.1 State of problems - 2 1.2 Thesis Objectives 2 1.3 Related work 3 1.4 Thesis Outline 4 Chapter Two: A Survey of Process Modeling Languages 6 2.1 Introducing Five Currently Used PMLs 7 2.1.1 Event-controlled Process Chains Method (EPC) 8 2.1.2 IDEFO 8 2.1.3 IDEF3 9 2.1.4 U M L Activity Diagram 11 2.1.5 EDPM Method 12 2.2 An Example of Business Processes 13 2.2.1 Process Description 14 2.2.2 Model the Process with PMLs 15 Chapter Three: Generic PML Constructs 19 3.1 Generic PML Constructs 19 3.2 Comparison of the Five PMLs - 20 3.2.1 Generic PML Constructs in EPC 20 3.2.2 Generic PML Constructs in IDEFO 22 3.2.3 Generic PML Constructs in IDEF3 23 3.2.4 Generic PML Constructs in UML Activity Diagram 24 3.2.5 Generic PML Constructs in EDPM Method 25 3.3 Summary of the Comparison 24 Chapter Four: Theoretical Foundations 27 4.1 Objective of this Chapter 27 4.2 Choosing BWW Ontology 28 4.3 The Fundamental Premise of BWW Ontology — 29 4.4 Original BWW Ontological Constructs 30 4.5 Process-related BWWP Constructs 31 iv 4.6 Ontological Model of a Process 33 4.6.1 A System of Four Things 33 4.6.2 Ontological Analysis -34 4.6.3 State Curves —- — 38 4.7 PML-BWWP Construct Mapping Rules 40 4.7.1 PML-Agent 41 4.7.2 PML-Resource 42 4.7.3 PML-Data 42 4.7.4 PML-Event 44 4.7.5 The Sequence of "event— o^peration—>event" in PML 46 4.7.6 PML-State - 48 4.7.7 PML-State of a Joint Agent 49 4.7.8 PML-Activity and PML-Operation 49 4.7.9 PML-Logical Connector —- 51 4.7.10 PML-Business rule 52 4.7.11 PML-Input/out object 53 4.8 Summaries of the Two Outcomes 53 4.8.1 Summary of the PML-BWWP Construct Mapping Rules -53 4.8.2 Summary of the Ontology-based Integrity Rules 54 Chapter Five: Evaluation of PMLs 56 5.1 Evaluation of EPC 56 5.2 Evaluation of IDEFO 58 5.3 Evaluation of IDEF3 60 5.4 Evaluation of U M L Activity Diagram 63 5.5 Evaluation of EDPM Method 64 Chapter Six: OBPM Modeling Algorithm 66 6.1 Ontology-based Process Model (OBPM) Algorithm 66 6.2 Algorithm Description 68 6.2.1 The Main Algorithm 68 6.2.2 Subroutine: Affected_Thing(input: Thing t, Event e) 69 6.2.3 Subroutine: Decompose(input: Agent a, Event e) 70 6.3 Theoretical foundations of the algorithm 71 6.4 WaterSystem Example 72 6.4.1 Running the algorithm on case A 74 6.4.2 Running the algorithm on case B 78 6.4.3 Running the algorithm on case C 79 v 6.5 Evaluation oftheOBPM Algorithm - 80 6.5.1 Basic Concepts 81 6.5.2 Basic Procedures 81 Chapter Seven: Conclusion 83 7.1 Conclusion 83 7.2 Contributions - 84 7.3 Limitations and Future Research - 84 Bibliography 86 Appendix I: WaterSystem Example 89 Appendix II: Ontological Analysis of PML-Logical Connectors 99 vi L I S T O F T A B L E S Table 2-1: Classification of five PMLs 7 Table 2-2: Definition of "Order processing" process 14 Table 3 -1: Generic PML constructs 19 Table 3-2: Identifying the generic PML constructs from EPC - 21 Table 3-3: Identifying the generic PML constructs from IDEFO 22 Table 3-4: Identifying the generic PML constructs from IDEF3 — 23 Table 3-5: Identifying the generic PML constructs from UML Activity Diagram 24 Table 3-6: Identifying the generic PML constructs from EDPM Method 25 Table 4-1: Original constructs of BWW Ontology 30 Table 6-1: OBPM algorithm and the ontology-based integrity rules 72 Table I-1: Definition of "Order taking" process - 89 Table 1-2: Definition of "Order processing" process 90 Table 1-3: Definition of "Assembly" process 91 Table 1-4: Definition of "Purchasing" process 92 Table 1-5: Definition of "Arrival" process - 92 vii L I S T O F F I G U R E S Figure 1-1: Thesis outline - 5 Figure 2-1: EPC basic constructs 8 Figure 2-2: IDEFO basic constructs - 9 Figure 2-3: IDEF3 Schematics — - 10 Figure 2-4: IDEF3 Process Schematic basic constructs 10 Figure 2-5: IDEF3 Transition Schematic basic constructs 11 Figure 2-6: IDEF3 Enhanced Transition Schematic basic constructs 11 Figure 2-7: UML Activity Diagram basic constructs 12 Figure 2-8: EDPM Method basic constructs 12 Figure 2-9: Logical connectors in EDPM Method 13 Figure 2-10: EPC model of "Order processing" process - 15 Figure 2-11: IDEFO model of "Order processing" process 16 Figure 2-12: IDEF3 Process Schematic model of "Order processing" process 11 Figure 2-13: IDEF3 Transition Schematic model of "Order processing" process 17 Figure 2-14: UML Activity Diagram model of "Order processing" process Figure 2-15: EDPM Method model of "Order processing" process — 18 Figure 3-1: Logical conjunctions in UML Activity Diagram - 24 Figure 3-2: Comparison of the five PMLs 26 Figure 4-1: Two-way mappings 28 Figure 4-2: Ontological completeness and ontological clarity 30 Figure 4-3: BWWP constructs related with thing 33 Figure 4-4: A system of four things 34 Figure 4-5: Ontological analysis to the four things' interaction 36 Figure 4-6: State curves of each thing 39 Figure 4-7: BWWP-state in PML - 44 Figure 4-8: BWWP-stable state of actor B 45 Figure 4-9: BWWP-unstable state of actor B - 45 Figure 4-10: BWWP-event in PML - — —-46 Figure 4-11: BWWP-extemal event for actor A in PML 47 Figure 4-12: B WWP-internal event for actor A in PML - 48 Figure 4-13: A state curve of two operations 50 Figure 4-14: PML-BWWP construct mapping rules 54 viii Figure 5-1: Mapping EPC constructs to BWWP concepts 57 Figure 5-2: Mapping IDEFO constructs to BWWP concepts 59 Figure 5-3: Mapping IDEF3 constructs to BWWP concepts 61 Figure 5-4: Mapping Activity Diagram constructs to BWWP concepts 63 Figure 5-5: Mapping EDPM Method constructs to BWWP concepts 64 Figure 6-1: The main algorithm 67 Figure 6-2: Subroutine Affected_Thing(t, e) 67 Figure 6-3: Subroutine Decompose(a, e) — — 68 Figure 6-4: EPC model of "Order processing" process 73 Figure 6-5: Running the algorithm on case A 75 Figure 6-6: Final model of case A 78 Figure 6-7: Final model of case B - — — 79 Figure 6-8: Final model of case C 80 Figure 1-1: EPC Model of WaterSystem Example 93 Figure 1-2: IDEFO Model of WaterSystem Example 94 Figure 1-3: IDEF3 Process Schematic Model of WaterSystem Example 95 Figure 1-4: IDEF3 Transition Schematic Model of WaterSystem Example 96 Figure 1-5: UML Activity Diagram Model of WaterSystem Example 97 Figure 1-6: EDPM Model of WaterSystem Example 98 Figure II-1: Ontological analysis to "one event —> AND —* two operations" 100 Figure II-2: Ontological analysis to "one event —• OR —> two operations" 101 Figure II-3: Ontological analysis to "one event —• XOR —• two operations" 102 Figure II-4: Ontological analysis to "two events —»• AND —> one operation" 103 Figure II-5: Ontological analysis to "two events —> OR —• one operation" - 104 Figure II-6: Ontological analysis to "one operation —• XOR —• two events" 106 ix Chapter 1 I N T R O D U C T I O N In order to show the essentials of complex problems, we need to set up models to abstract from the real world, neglect those aspects that we are not interested in, and highlight those which are of interest. The power of models comes from its ability to simplify the real-world system they represent, and make predictions about that system based on the facts within the models. The real-world system the thesis aims to model is business processes. Business attains its goals via its business processes. According to Davenport and Short (1990), a business process is a set of logically related tasks that use the resources of an organization to achieve a defined business outcome. It is a set of sequenced activities leading to some outcome such as a product or a service for a customer. Examples of typical business processes could be: Proposal development, Sales tracking, Order processing, Claims processing, Assembly, and so on. Process models are created for business users to represent their perspectives of how the business is conducted. These models form a basis for information system development such as Enterprise Resource Planning (ERP) system and Customer Relationship Management (CRM) system. A good business process model is also critical for understanding and improving business processes effectively. This could help in achieving the benefits of many new management philosophies such as Total Quality Management (TQM), Activity-based Costing (ABC), Business Process Re-engineering (BPR), and Work Flow Management (WFM) as the decision-making under these management strategies are heavily relying on the definitions of business processes. l A Process modeling language (termed as PML) is a technique used for describing, documenting and analyzing a businesses process. 1.1 State of the problems The existing process modeling languages have problems in terms of their expressiveness. The identified problems are: (1) As different languages emphasize different aspects of business processes, thus they might have problems in terms of their expressiveness. For example, they may have some constructs overlapping each other, or some necessary constructs are simply missing in the PMLs. (2) Many PMLs are intended to support information systems development, rather than model general business processes, therefore, they might not have complete and clear concepts to represent the real world process. For example, most PMLs construct process models by looking at the information flow such as input or output data rather than investigating the facts regarding how concrete objects interact with each other during the processes. (3) Most PMLs provide a notation, but do not have formally defined rules to guide the construction of a process model. For example, the PMLs construct a process model based on the procedures obtained from traditional process modeling heuristics or observations. They do not have formal rules to follow. 1.2 Thesis Objectives The purpose of the thesis is to develop a theory-based process modeling methodology, which is intended to support both information systems as some PMLs do (such as EPC, IDEFO, etc.) and general business processes in real world. Therefore, it does not just emphasize the specific information processing aspects of business processes, but also 2 presents the organizational, functional and behavioral aspects of processes. The methodology should have the following features: (1) Cover all the aspects of a business process rather than specific aspects. (2) Include clearly defined constructs that are derived from ontological concepts. (3) Provide a procedure for constructing a process model in a given situation. (4) Have a set of integrity rules to enable checking that the model is semantically correct. The thesis achieves it objectives by the following steps: • Compare five currently used PMLs and identify the generic PML constructs. • Associate the process modeling languages with BWW Ontology (an ontology presented by Bunge and extended by Wand and Weber), and find the PML-BWWP construct mapping rules between the basic concepts of each other. • Generate a group of ontology-based integrity rules that should be followed to build a theory-based process model. • Use the mapping rules as a guideline to evaluate the currently used five PMLs in terms of their expressiveness. • Use the integrity rules to generate an algorithm on building an Ontology-based Process Model (OBPM). 1.3 Related work In the information system requirements modeling area, several modeling languages have been analyzed based on the theory of ontology up to date. According to Green and Rosemann (2000), the ontological analysis work has been done as follows: traditional modeling languages by P. Green in 1997, structured language such as Data Flow Diagrams by Wand and Weber in 1989, data-centered languages such as Entity-Relationship Diagram 3 by Wand and Weber in 1989 and 1993, relational model by Sinha and Vessey in 1995, NIAM by Weber and Zhang in 1996, OO model by Sinha and Vessey in 1995, Parsons and Wand in 1997. Some ontological analysis to PMLs has been done by Peter Green and M. Rosemann (2000). They analyzed the ARIS architecture with BWW Ontology, found the mapping rules between the concepts of each, and evaluated the architecture in terms of ontological completeness and ontological clarity. However, to the best of our knowledge there is no ontological study done on generic process modeling language constructs so far. Additionally, we did not see any previous work that attempts to find the theory-based integrity rules for constructing an ontology-based process model. 1.4 Thesis Outline Chapter two presents a general review of five currently used PMLs by introducing their basic constructs and modeling rules. It is followed by an example of several business processes in a middle-sized real world manufacturing enterprise. The five PMLs are applied in the example to compare their expressiveness in different aspects. Chapter three identifies the generic PML constructs that are necessary in a process modeling language based on the observation and modeling experience in the previous chapter. And, the five PMLs are compared with each other in terms of each generic PML construct to find the strengths and weakness of each PML. Chapter four investigates the theoretical foundations of the PMLs by looking at BWW Ontology concepts. Process-related BWW Ontological concepts are organized as BWWP concepts. By analyzing how things communicate from an ontological perspective, a set of PML-BWWP construct mapping rules and a set of ontology-based integrity rules are found. Chapter five focuses on the application of the first set of rules: PML-BWWP construct 4 mapping rules. It evaluates the five PMLs using the rules and finds their problems in terms of their ontological completeness and clarity. This evaluation helps to clarify the basic concepts of the process modeling methodology. Chapter six focuses on the application of the second set of rules: Ontology-based integrity rules. A conceptual modeling algorithm on how to establish an "Ontology-based Process Model" (OBPM) is generated, and an example has been used to illustrate the procedures of running the algorithm. The OBPM algorithm defines the procedures on building a process model for the methodology, and the ontology-based integrity rules show how to check that the model is semantically correct. Chapter seven summarizes the thesis on its contribution, limitations and future research. Chapter 1-3 PML-BWWP mapping rules Ontology-based inte grity rules IT Introduction Two outcomes Chapter 4 Ontological model of process IT BWWP concepts IT BWW Ontology Figure 1-1: Thesis outline 5 Chapter 2 A S U R V E Y O F P R O C E S S M O D E L I N G L A N G U A G E S Information system requirements-modeling languages have progressed from simple flowcharts, to data flow diagrams, to entity-relationship diagrams, to object-oriented schemas and integrated process modeling systems. Process modeling languages (PML) are the main components in the integrated process modeling system. There are different categories of PMLs used for various purposes of business process management applications. According to Huckvale and Ould (1995), most PMLs fall into four categories based on the different application fields: • Functional PML The languages focuse on representing what operations are being performed and what dataflow connects them. For example, EPC, IDEFO, IDEF3 Process Schematics and Transition Schematics, UML Activity Diagram and EDPM method are all functional PMLs. • Behavioral PML PMLs in this category focus on representing the sequencing, feedback loops, iteration, decision-making and triggering conditions when operations are performed. For example, EPC, IDEF3 Process Schematics and Transition Schematics, UML Activity Diagram and EDPM method are behavioral PMLs. • Organizational PML This kind of PMLs concentrates on representing where and by whom activities are performed, plus physical communication mechanisms and storage media. For example, EPC, IDEFO, UML Activity Diagram and EDPM method are organizational PMLs. • Informational PML 6 Informational PMLs focus on representing the entities such as documents, data, artifacts and products generated or manipulated by a process, including their structures and inter-relationships. For example, EPC, IDEFO, IDEF3 Transition Schematics and EDPM method are all informational PMLs. As each modeling method and its associated architectural representations are designed to focus on one or some characteristics of a process, a variety of PMLs are necessary to meet the need of different kinds of applications. According to Zachman, there is not a "right" method or a "wrong" method, and each of them is additive and complementary to another (Mayer, 1995). 2.1 Introducing five currently used PMLs The five PMLs introduced in this section are EPC, IDEFO, IDEF3, UML Activity Diagram, and EDPM Method. They are chosen to be investigated in the thesis because they cover all the four types of process modeling languages together. Table 2-1 shows the classification of the five chosen PMLs. ^ ^ A s p e c t Funct iona l Behav io ra l Organ iza t iona l In format iona l E P C It has " funct ion" a n d " info in/out" cons t ruc ts . It has logical connec to rs . It h a s "o rgan iza t iona l unit" cons t ruc t . It has " info in/out" cons t ruc ts . IDEFO It has " funct ion" a n d " input /output" cons t ruc ts . It has logical connec to rs . It has " m e c h a n i s m " cons t ruc t . It has " input /output" cons t ruc ts . IDEF3 It has " U O B " const ruct . It has logical connec to rs . — It has "object" const ruc t . U M L A D It has "act iv i ty" const ruc t . It has logical connec to rs . It has s w i m l a n e s . — E D P M It has "act iv i ty /operat ion" and " input /output" cons t ruc ts . It has logical connec to rs . It has "agent " const ruc t . It h a s " input /output" cons t ruc ts . Table 2-1: Classification of the five PMLs The purpose of this survey is to find what constructs are commonly used by the five PMLs, and what are bearing different implications on different PMLs. After practicing in 7 modeling some business processes in an example, this chapter suggests some observations on the implications of generic PML constructs. 2.1.1 Event-controlled Process Chains method (EPC) Event Info in Info out Function Ofg. Unit Event Event Control Flow Information Flow Organization assignment Figure 2-1: EPC basic constructs Event-controlled Process Chains method is the modeling tool adopted by SAP R/3 system based on the Architecture of Integrated Information Systems (ARIS). SAP R/3 is an enterprise-wide, integrated information system which is playing a leading role in the Enterprise Resource Planning (ERP) market. EPC method has the following basic constructs: Organizational unit, Event, Function, Information in; Information out, and Logical connector. 2.1.2 IDEFO The Integrated DEFinition (IDEF) methodology is a suite or family of methods that supports a paradigm capable of addressing the modeling needs of an enterprise and its business areas. IDEF technologies have grown over the past four to five years, the Department of Defense is a prime user of the technologies, and some of the largest U.S. corporations have adopted the IDEF technologies for competitive advantage (Mayer, 1995). IDEFO is a "Function Modeling Method" of the IDEF modeling method family. It is used to produce a "function model", which is a structured representation of the functions, activities or processes within the modeled system or subject area. Inputs Controls i 1 Controls Function Outputs Mechanisms Inputs ± ± Function Outputs Mechanisms Figure 2-2: IDEFO basic constructs IDEFO was developed for the US Air Force Program for Integrated Computer Aided Manufacturing (ICAM) for the purpose of increasing manufacturing productivity by systematic application of computer technology. Although IDEFO was originally intended for use in system engineering, it has evolved and contains the necessary notations to support business applications. IDEFO basic constructs are: Function, Controls, Mechanisms, Inputs, Outputs and Logical connector. 2.1.3 I D E F 3 IDEF3 is a "Process Description Capture Method'1 of the IDEF modeling method family. It was created specifically to capture descriptions of sequences of activities. It provides a structured method by which a domain expert can express knowledge about the dynamic operation of a particular system or organization. This includes capturing the state situations of the objects that participate in the process and objects that support the process, as well as the precedence and causality relations between events and processes (Mayer, 1995). An IDEF3 Process Description is developed using two knowledge acquisition strategies: a process-centered strategy and an object-centered strategy. Two types of IDEF3 semantics parallel the two knowledge acquisition strategies. IDEF3 Process Schematics show a process-centered view of a scenario, and Object Schematics display the object-centered information. The Object Schematics that display an object-centered view of a single scenario are called Transition Schematics, and those that display the object-centered view of multiple scenarios are simply called Object Schematics. Transition Schematics that display additional objects and object relations to provide context-setting information are called Enhanced Transition Schematics (Mayer, 1995). IDEE? Schematics Process Schematics Object Schematics Object Schematics Enhanced Transition Schematics Figure 2-3: IDEF3 Schematics Basic constructs of IDEF3 are: Unit of behavior (UOB), Object's state and Logical connector. U O B 1 Node R e » IDEF Reffl & U O B 2 Node Refft IDEF Reffl U O B 3 Node Reffi ffiEF Reffl Figure 2-4: IDEF3 Process Schematic basic constructs 10 Referent type/ Label 1 Locator Referent type/ Label 3 Object a:^  State 2 , Referent Referent type/ type/ Label 2 Label 4 Locator Locator Figure 2-5: IDEF3 Transition Schematic basic constructs Liquid Subkind -of Subkind -of Figure 2-6: IDEF3 Enhanced Transition Schematic basic constructs 2.1.4 UML Activity Diagram The latest Unified Modeling Language (UML) specification describes Activity Diagrams as a mechanism to capture business workflows, processing actions, and use-case flows of execution (OMG Unified Modeling Language Specification Version 1.3., 1999). A UML Activity Diagram documents the logic of a single operation or method, or the flow of logic of a business process. It shows the sequential flow of activities in a process, which could be one after another or in parallel. 1 The basic constructs are: Activity, Agent, Condition, and Logical connector. 1 Note: Choosing UML Activity Diagram is just for illustration of one PML in this thesis. The analysis and evaluation to the Activity Diagram does not apply to other diagrams in UML, and it is not intended to evaluate UML. 11 The concept of agent in Activity Diagrams is expressed by swimlanes. [Condition'. Agentl | AgentZ f7. \ [Condition 1] uwtivity 11— ft ^ctivity 2) (^ctivity 7)<-AgentS [Condition [Cdndition 4] (Ac ctmty 3) Agent4 i j] . •^Activity 6J Figure 2-7: UML Activity Diagram basic constructs 2.1.5 EDPM Method The Event-Driven Process-Modeling (EDPM) method introduced here was developed by Jacob Steif based on the notation of Martin and Odell (1992). Event <inputl> Activityl pperationllj Operational {agentl, ...} [resourcel] (rulel,...) <input2> -^[outputl] Activity2 (+>n) Operational Operation22 {agent2, ...} [resource2,] (rule2, ...) [output2] Figure 2-8: EDPM Method basic constructs The basic constructs are as follows: Agent, Activity, Operation, Event, Resource, Input, Output, Logical connector and Business rule. 12 The logical relations between events and activities are shown in Figure 2-9. Link Events triggering an activity Events created by an activity OR YY > — • > — > XOR YY n. .71 > | — • > — > AND Figure 2-9: Logical connectors in EDPM Method 2.2 An example of business processes To understand how to use each PML introduced above, we need to go through a real-world process example and model it with the five PMLs. This is an example of typical business processes in a middle-sized manufacturing enterprise. The enterprise assembles water purification systems from components purchased locally or internationally, and sells them to the local market. Its supply chain model adopts the "Build-To-Order" strategy, and the manufacturing or purchasing starts only when customer places orders and their payment is made. This strategy enables the enterprise to keep low inventory level and make quick response to customers' requests. For enterprise privacy and the easy reference in later chapters, the enterprise' name is omitted, and the example is to be referenced as "WaterSystem" in later parts. There are five processes in the example: 1. Order taking 2. Order processing 3. Assembly 4. Purchasing 5. Arrival. For simplicity, only "Order processing" process which includes most complicated cases and covers all the aspects of a business process will be illustrated here modeled by different PMLs, and the complete business process models could be found in Appendix I. 13 2.2.1 Process Description The triggering events of this process are "customer payment made" generated from "Order taking" process and "assembledproducts ready" coming from "Assembly" process. When the first triggering event occurs, the Account Receivable department will collect customer's payment into the company's bank account. The section clerk might use bank machines or ask a bank teller for help. S t a r t i n g e v e n t T r i g g e r e d o p e r a t i o n E n d i n g e v e n t R e s o u r c e u s e d A g e n t D a t a P a y m e n t m a d e Col lec t p a y m e n t P a y m e n t co l lec ted B a n k m a c h i n e , bank te l ler A / R C u s t o m e r fi le P a y m e n t co l lec ted C h e c k o rder in w a r e h o u s e O r d e r ready X O R order not ready - W a r e h o u s e -O r d e r not ready — - - W a r e h o u s e -O r d e r ready O R a s s e m b l e d p roduc t ready Sh ip p roduc ts Order sh ipped Forklif t , e levator W a r e h o u s e -Order sh ipped R e a r r a n g e w a r e h o u s e W a r e h o u s e rea r ranged Forkl i f t W a r e h o u s e -W a r e h o u s e rea r ranged - — - W a r e h o u s e -O r d e r sh ipped S e n d invoice Invoice sent Mai l Sa les dept -Invoice sen t C l o s e o rder O r d e r c losed C o m p u t e r S a l e s dept -O r d e r c losed - - - S a l e s dep t . -Table 2-2: Definition of "Order processing"process After payment is collected, the Warehouse department clerk will check if the order is ready for shipping. If not ready, she might wait for notification from the manufacturing department. If the order is ready in warehouse OR the assembled products are ready for shipment (which is the second triggering event), the Warehouse department will ship the order with help of a forklift and an elevator. When the order is shipped, two things need to be done: The Sales department should send invoice to the customer by mail and close the order, and the Warehouse department should rearrange the warehouse space for new products and components. 14 The sample process covers all aspects of a business process. For example, the organizational aspects could be "A/R department", "Warehouse department", and "Sales department". The functional aspects could be "collect payment", "ship products" and "send invoice". The behavioral aspects could be the rule that, when an order is ready or the assembled products are ready, the warehouse department will ship products. The informational aspects could be a customer file and a bank machine, which are used when A/R department collect payment. 2.2.2 Model the process with PMLs Payment made ( Order processing T I Customer file Collect payment (^v£rehoi)se Payment collected 1 Check order in W/H , (xoi) ., Order ready Order not ready Ship products 1 I Order shipped (Sales dep) Rearrange warehouse 'arehouse earranaed Send invoice i 1 Invoice ' \ sent / Close order Order closed I Assembled roduct rdv/ Figure 2-10: EPC model of "Orderprocessing"process 15 In order to compare the expressiveness and the ease-of-use of each PML, the "Order processing" process is modeled by the five PMLs. For simplicity, IDEF3 Enhanced Transition Schematic model, which focuses on the static state of a system, is omitted. The models are displayed in Figure 2-10, 2-11, 2-12, 2-13, 2-14 and 2-15. Payment made Bank rules Customer -> file Collect payment "T" A/P Ban Tmac^  Payment collected h./tiller Check order in w/h Order processing Order not ready | X Warehouse Assembled product ready Order ready Ship products Product file i W a r e h o u s e T Forklift, elev. Invoice-Order shipped Send invoice Invoice sent Sales crept. Ivfail Close ordei OrdeK closad ^ Rearrange W / H Warehouse Sales deptt dm puter Warehouse rearrangedi , ' Figure 2-11: IDEFO model of "Orderprocessing"process 16 A r r a n g e p a y m e n t 4 C o l l e c t C h e c k order p a y m e n t in W / H 13 14 Order processing S h i p products 16 A d to W / H 11 R e a r r a n g e w/h 17 S e n d C l o s e i n v o i c e order 18 19 v. Figure 2-12: IDEF3 Process Schematic model of "Orderprocessing"process /Sales? -^J Paym't) Collect payment 13 / M a n u f ^ ^Assemble \ y product J Vready/ Check order in w/h 14 / w / h : \ Order , not / Vready/ Ship products 16 , w/h: \ y Order ,)_>(gf Rearrange w/h Send invoice 18 *i Sales:' Unvoice' \ s e n t / 'v Order processing V ' Figure 2-13: IDEF3 Transition Schematic model of "Orderprocessing"process 17 M a n u f . d e p t . /' A d d to A •warehousy A / R d e p t . / 1 / C o l l c c t ' N j ^ p a y m e n t / " W a r e h o u s e d e p t . j [ O r d e r ready] ,^/Check order. \. i n W II ,' | O r d e r not ready > S h i p ) . p r o d u c t s I—*#) l • •' / Rearrange \ warehouse I •* Q S a l e s d e p t . i ' A r r a i Vpaym l g e \, j ent/' | J Send ^ ^ Close N>,—>, £ • invoicey order J Order processing j Figure 2-14: UML Activity Diagram model of "Orderprocessing"process A s s e m b l e d products ready for ship P a y m e n t made • C o l l e c t p a y m e n t J A / R } P a y m e n t c o l l e c t e d C h e c k order in warehouse! ' W a r e h o u s e ! Order] ready S h i p products {Warehouse Products, sh ipped R e a r r a n g e w a r e h o u s e W a r e h o u s e j W / H rearranged >o J < C u s t o m e r [ M o n e y ] C u s t o m e r F i l e > | . i l c > Order processing O r d e r not r e a d y <Hnd produets> < P O > >o S e n d i n v o i c e Sales dept.] Invo Isenl C l o s e order (Sales dept.] O r d e r c l o s e d • >o Figure 2-15: EDPM Method model of "Orderprocessing"process 18 Chapter 3 G E N E R I C P M L C O N S T R U C T S Based on previous observations, it is clear that a process model defines the dynamic features of a system. It abstracts from the uninteresting details of the real-world process, and only describes the facts about the following: the participants in the process, the activities triggered by an event or events, the events that trigger an activity or activities, the order of activities to be performed, the order of events occurred, the resource utilized in an activity, and the input and output objects of an activity. This chapter attempts to summarize the generic PML constructs that are necessary to represent a good process model, and compare the five PMLs in terms of those constructs. 3.1 Generic PML constructs Based on the five PMLs' notations and the observations on their modeling practice, the basic constructs which are needed to model a business process are summarized and defined below: PML construct Explanation Process A process is a sequence of activities or operations leading to a desired outcome or goal. It may involve one or many participants, which interact with each other by executing activities and operations. When all participants stop their state-changes, the process is over. Agent An agent is a person or an organizational unit that participates in the process. It is the active participant of the process that executes activities and operations. An agent could execute an activity or operation and keep changing until it is stable. It can also activate other participants to start changing. Non-agent or Resource Another kind of participant in a process is a non-agent or a resource, which is not able to activate any participants including itself during the process. It might be a resource which is utilized by an agent in an activity or an operation, or an object which is transformed or produced by the activity or operation. - To be continued to the next page 19 P M L cons t ruc t Exp lana t ion Act iv i ty A n act iv i ty is the e lemen ta ry task an a g e n t s h o u l d p e r f o r m in a p rocess . T h e execu t ion of an act iv i ty is a tomic , w h i c h m e a n s that o n c e the act iv i ty s tar ts it wil l f inal ly c o m p l e t e a n d t h e a g e n t wi l l no t c h a n g e its s ta te un less it is t r iggered to c h a n g e aga in . O p e r a t i o n A n opera t ion is a c o m p o n e n t o f an activity. A n act iv i ty is d iv ided into opera t ions so that t he agen t ' s in te rmed ia te s ta tes cou ld be c a p t u r e d . T h e s e in te rmed ia te s ta tes might t r igger o the r agen ts to c h a n g e , or m igh t c a u s e the agen t itself to con t inue its s ta te -change . Even t A n even t is a no tab le o c c u r r e n c e at a par t icu lar po in t o f t ime , w h i c h c a u s e s the s ta te o f an agen t or a non-agen t to c h a n g e . State T h e state is regarded as the va lues of all p roper t ies o f a par t ic ipant at a part icu lar point o f t ime. Data Data represents the s ta te o f a n a g e n t or non -agen t . For e x a m p l e , t he data of p roduc t quant i ty rep resen ts the s ta te o f a n o n - a g e n t "product " . T h e da ta w h i c h is n e c e s s a r y for the func t ion to p rocess is t h e input da ta , a n d the da ta w h i c h resul ts f r o m the execu t ion o f a func t ion is ou tpu t d a t a . Log ica l c o n n e c t o r T h e logical c o n n e c t o r s cou ld b e c o n s i d e r e d a s t h e def in i t ion o n t h e precond i t ions o f an act iv i ty to be in i t ia ted, or the post cond i t i ons w h e n a n act iv i ty is c o m p l e t e d . T h e y de f ine the ru les b e t w e e n act iv i t ies (opera t ions) a n d even ts . T h e r e a re th ree k inds o f logical c o n n e c t o r s : " A N D " , " O R " a n d " X O R " . Bus iness rule Bus iness ru les p rov ide the law or rules w i th in a n act iv i ty or opera t ion that the agen t shou ld fol low. If th is act iv i ty or ope ra t i on is d e c o m p o s e d , the bus iness ru les will be eventua l l y e x p r e s s e d by logical c o n n e c t o r s b e t w e e n t h e re f ined act iv i t ies o r opera t ions . Input Inputs a re the da ta or ob jec ts that a re t r a n s f o r m e d by the ope ra t i on or act iv i ty into output . Ou tpu t Ou tpu ts a re the data or ob jec ts p r o d u c e d by the ope ra t i on o r activi ty. Table 3-1: Generic PML constructs 3.2 Comparison of the five PMLs Identifying the generic PML constructs from the five PMLs shows that each of them has different focus in modeling the dynamic world. Also, some of them are similar in constructs and rules while some are complimentary to each other. 3.2.1 Generic PML constructs in EPC Identifying the generic PML constructs from EPC gives the following table: 20 P M L cons t ruc t Exp lana t ion in E P C Agent R e s o u r c e Act iv i ty Opera t i on Even t State Da ta Logica l c o n n e c t o r Bus iness rule Input /output (ob ject ) T h e const ruc t of agen t in E P C is n a m e d "Organization unit. It is d i rect ly assoc ia ted wi th the cons t ruc t of "Function" in the no ta t ion , ind icat ing w h o per fo rms this func t ion . E P C d o e s not cap tu re the resources u s e d in a p rocess . Cons t ruc t of act iv i ty in E P C is n a m e d "Function" in its no ta t ion , w h i c h is used to exp ress the act ion the agen t execu tes . T h e cons t ruc t o f "Function" is not d i f ferent ia ted into act iv i ty a n d opera t ion in E P C . T h e r e is no w a y in E P C to f ind w h i c h func t ion is a n activity, a n d w h i c h is jus t an opera t ion . E P C expl ic i t ly cap tu res the even t o c c u r r e n c e in a d y n a m i c s y s t e m . Events are c rea ted by a func t ion a n d will t r igger the next func t ion if t he ac t ive agen t d o e s not ach ieve its goa l . O r s o m e even ts m a y t r igger a n o t h e r agen t to start change . E P C uses even ts to cont ro l t he cha in of func t ions . E P C d o e s not expl ic i t ly keep t rack o f e a c h agen t ' s s ta te w h i c h keeps c h a n g i n g wi th in a func t ion . However , t he s ta te b e t w e e n t w o act iv i t ies or opera t ions is impl ied in the cons t ruc t o f "Event. E P C c lear ly p resen t da ta by the cons t ruc ts o f "Information in" a n d "Information out'. " In fo rmat ion in" rep resen ts the da ta that is on ly referred in a func t ion , a n d " In fo rmat ion out" rep resen ts the da ta that m igh t be newly g e n e r a t e d or upda ted in the func t ion . T h e logical re la t ionships b e t w e e n even ts a n d func t ions a re e x p r e s s e d clear ly: A N D , O R , a n d Exc lus i ve -OR. E P C d o e s not inc lude this cons t ruc t in the m o d e l . E P C d o e s not cons ide r the concre te ob jec ts tha t a re input to the func t ion or p r o d u c e d by the func t ion . Table 3-2: Identifying the generic PML constructs from EPC Generally speaking, EPC method covers almost every necessary aspect in a process model except the concepts of resource, business rule and input/output object. Missing these concepts causes this method lack of information. Users are not able to know which participants are utilized as resources when an organizational unit completes a function, which rules the organizational unit must follow to complete a function, and what input objects are transformed into what output objects. 21 3.2.2 Generic PML constructs in IDEFO Identifying the generic PML constructs from IDEFO gives the following table: P M L cons t ruc t Exp lana t ion in IDEFO A g e n t R e s o u r c e Act iv i ty Opera t i on Even t State Data Logica l c o n n e c t o r s Bus iness rule Input /output (object ) T h e agen t in IDEFO is exp ressed in " M e c h a n i s m s " cons t ruc t . T h e o ther part o f M e c h a n i s m s is resource . IDEFO a lso represents the c o n c e p t o f resou rce in its " M e c h a n i s m " const ruc t . Th is wil l c a u s e con fus ion w h e n peop le read the d i a g r a m a n d a t temp ts to ident i fy w h o pe r fo rms the func t ion a n d w h o is on ly ut i l ized in the func t ion . T h e concep t o f act iv i ty is e x p r e s s e d by "Func t i on " cons t ruc t in IDEFO. IDEFO does not m a k e d i f ference b e t w e e n a n act iv i ty a n d a n opera t i on . Bo th o f t h e m are all in "Func t ion" . In IDEFO, t r igger ing even ts a re h idden in the cons t ruc t o f "Cont ro ls " , b e c a u s e the t r igger ing even ts cont ro l w h i c h func t ions a re to be p e r f o r m e d . N e w events cou ld be found in the const ruc t o f "Ou tpu ts " in IDEFO, a s the n e w even ts a re c rea ted by the func t ion a n d t rans fe r red w i th o the r ou tpu t ob jec ts toge the r to the next s tage. There fo re , a n ou tpu t o f o n e func t ion cou ld be a contro l of ano the r func t ion . T h e r e is not a state cons t ruc t in IDEFO m e t h o d . Input da ta is part of IDEFO's " Inputs" cons t ruc t , a n d ou tpu t da ta is part of IDEFO "Outpu ts " const ruc t . IDEFO d o e s not prov ide r ich s y m b o l s to rep resen t the logical con junc t ions of " A N D " , "OR" , and " X O R " . W h e n t w o even ts a re n e e d e d to t r igger a func t ion , its "Cont ro ls " cons t ruc t on ly s h o w s that t he t w o even ts reach a func t ion together , but it d o e s not c lear ly s h o w t h e logical re la t ionsh ip b e t w e e n the t w o even ts . IDEFO puts the concep t o f bus iness rule in the "Cont ro ls " cons t ruc t . A s " t r igger ing event " is a lso e x p r e s s e d in the "Cont ro ls " cons t ruc t , it is not c lear to the m o d e l readers . Input ob ject is part o f IDEFO's " Inputs" cons t ruc t , a n d ou tpu t ob jec t is part o f IDEFO's "Outpu ts " const ruc t . Table 3-3: Identifying the generic PML constructs from IDEFO From the above analysis, IDEFO method has the following confusions in its constructs: The construct of "Controls" includes (1) PML-business rule (2) PML-triggering event. The construct of "Mechanisms" includes (1) PML-agent and (2) PML-Resource. The construct of "Inputs" includes (1) PML-input data and (2) other physical input 22 objects. The construct of Outputs" includes (1) PML-output data, (2) PML-new events and (3) other concrete output objects. 3.2.3 Generic PML constructs in IDEF3 As there are two types of IDEF3 schematics {Process Schematic and Object Schematic) and they could be used in parallel in the process knowledge acquisition, the constructs of both schematics are analyzed together in the following table: P M L cons t ruc t Exp lana t ion in I D E F 3 A g e n t R e s o u r c e Act iv i ty Opera t i on Even t State Data Logica l c o n n e c t o r Bus iness rule Input /output (ob ject ) T h e r e is no agen t cons t ruc t in I D E F 3 P r o c e s s S c h e m a t i c s , but it has a cons t ruc t "Object in Ob jec t S c h e m a t i c s . A n ob jec t cou ld be a n y par t ic ipant in the p rocess that need to be m o d e l e d . T h e s t reng th o f th is is that the m o d e l is not restr ic ted to m o d e l the behav io r o f agen ts only. It a lso cap tu res the s ta tes of non-agen ts . However , m ix ing a g e n t s w i th non -agen ts can lead to lack o f clarity. T h e r e is no resource cons t ruc t in I D E F 3 . Eve ry par t ic ipant is m o d e l e d as a n "Object " in I D E F 3 Objec t S c h e m a t i c s . Act iv i ty is n a m e d "UOB - Uni t o f behav ior " in I D E F 3 . T h e r e is no dist inct ion b e t w e e n a n act iv i ty a n d a n ope ra t i on in I D E F 3 . I D E F 3 d o e s not cap tu re the in fo rmat ion o f even ts . T h e Ob jec t S c h e m a t i c that d isp lays a n ob jec t -cen te red v i e w o f a single scenar io is ca l led Transition Schematic. In th is s c h e m a t i c , I D E F 3 keeps t rack of a n object 's s ta tes c h a n g e . N o in format ion o f da ta is cap tu red . Each s c h e m a t i c in I D E F 3 has its o w n set o f log ica l c o n n e c t o r s . Bus iness rules a re not m e n t i o n e d in I D E F 3 . Not ava i lab le in I D E F 3 . Table 3-4: Identifying the generic PML constructs from IDEF3 The two types of schematics in IDEF3 are normally used together to model complicated process requirements. It also includes a static model of the objects in the Enhances Transition Schematics. 23 3.2.4 Generic PML constructs in UML Activity Diagram Identifying the generic PML constructs from UML Activity Diagram gives the following table: P M L cons t ruc t Exp lana t ion in U M L Act iv i ty D i a g r a m A g e n t T h e agen t cons t ruc t in Act iv i ty D i a g r a m is e x p r e s s e d by sw in lanes , e a c h o f w h i c h represents the behav io r o f o n e agent . W h e n there is no s w i m l a n e s , the a s s u m p t i o n is that t he w h o l e p r o c e s s is to be e x e c u t e d by the s a m e agent , w h i c h d o e s not n e e d to be e x p r e s s e d in the d i a g r a m . R e s o u r c e Not ava i lab le . Act iv i ty T h e act iv i ty cons t ruc t in Act iv i ty D i a g r a m is "Activity". Opera t ion It d o e s not m a k e any d i f ference b e t w e e n a n act iv i ty a n d a n opera t ion . Even t Not ava i lab le . State Not ava i lab le . Data Not ava i lab le . Log ica l c o n n e c t o r Act iv i ty D i a g r a m s use "Cond i t ion" to spec i fy the cond i t ions , w h i c h c lear ly s h o w s the E x c l u s i v e - O R logical re la t ionsh ip . It a lso has its w a y to exp ress " A N D " a n d " O R " . S e e Figure 3 - 1 . Bus iness rule Not ava i lab le . Input /output (ob ject ) Not ava i lab le . Table 3-5: Identifying the generic PML constructs from UML Activity Diagram AND O R X O R c^tivityT)-{Activity2)-^ctivity ^ _ (Activity 2)-(Activity^ -^ctivity 3)-[^Activity 3 ) -[ condition!] [condition3] [condition2] -^ctivity 3) [condition4] ^ctivity 2) {Activity 4) Figure 3-1: Logical conjunctions in UML Activity Diagram 24 Overall speaking, a UML Activity Diagram is comparatively simple to use but not as clear as other PMLs. An analyst could use Activity Diagrams to start the requirement analysis, and when the process is getting clearer, other PMLs with richer constructs could be considered. 3.2.5 Generic PML constructs in EDPM Method EDPM Method is comparatively complete in terms of the number of constructs. P M L cons t ruc t Exp lana t ion in E D P M M e t h o d T h e const ruc t o f agen t in E D P M M e t h o d is "Agent'. R e s o u r c e is e x p r e s s e d a s "Resource" in E D P M M e t h o d . T h e const ruc t o f act iv i ty is "Activitf in E D P M M e t h o d . E D P M M e t h o d has the cons t ruc t o f "Operation" w h i c h e n a b l e s a n act iv i ty to be d e c o m p o s e d . T h e const ruc t o f event is "Event' in E D P M M e t h o d . N o ava i lab le . Data is e x p r e s s e d as part of "Input' a n d "Output in E D P M M e t h o d . T h e r e a re logical connec to rs a s A N D , O R a n d X O R in E D P M M e t h o d . Bus iness ru les a re cap tu red as "Rule" in E D P M M e t h o d . Input a n d ou tpu t ob jects a re e x p r e s s e d a s part o f " Input" a n d "Outpu t " in E D P M M e t h o d . Table 3-6: Identifying the generic PML constructs from EDPM Method 3.3 Summary of the comparison The differences among the five modeling languages in terms of generic PML constructs are illustrated in Figure 3-2. A g e n t R e s o u r c e Act iv i ty Opera t i on Even t State Data Logical c o n n e c t o r Bus iness rule Input /output (object ) 25 PML construct EPC IDEFO IDEF3 UML A.D. EDPM Agent Mechanisms Object By swimlanes {agent} Resource N/A Mechanisms N/A N/A [resource] Activity Function Function UOB (Activi™ Activity Operation Function Function UOB ^ctrvit^ i'Oper^ ti( n Event ^ Event ^ 1 Controls Outputs N/A N/A Event State N/A N/A Object state ( j N/A N/A Data Info in input output N/A N/A <input> [output] Info ou: ^ Logical Connector © © ® Not explicitly expressed. CH LH CH ® @ ® Business Rule N/A jCoi tiro Is N/A N/A (rule) Input/output object Info in input output N/A N/A <input> [output] Info ou: ^ Figure 3-2: Comparison of the five PMLs 26 Chapter 4 T H E O R E T I C A L F O U N D A T I O N S A conceptual model such as a business process model is created for the purpose of capturing the knowledge of a real-world domain. Therefore, the concepts that are used in the modeling languages should be able to completely and clearly represent the constructs in the real-world domain. All the five PMLs introduced in previous chapters are used in describing business process models. However, each of them might have weakness in expressing the real-world system behaviors. Despite of the fact that most of their graphical symbols are intuitively defined and are easy to understand, they might have deficient, excessive, overloaded and redundant constructs that might lead to a vague model of the real-world process. And, this final model might either describe the business processes incompletely, or the representation might be not clear enough. 4.1 Objective of this chapter The objective of this chapter is to examine the theoretical foundations of PMLs by the following steps: • Introduce the well-defined BWW Ontology and its fundamental premise. • Introduce the basic BWWP concepts, which are the process-related BWW Ontological concepts. • Analyze the process model from the ontological point of view, and identify the ontology-based integrity rules. • Map PML constructs to BWWP concepts, and find the PML-BWWP construct mapping rules to form a clear semantics for PMLs. 27 This chapter follows the notion of ontological expressiveness of modeling languages (Wand and Weber, 1993). Mapping from a modeling language to ontology is attempting to interpret the language constructs by ontological concepts, and mapping from ontological concepts to a modeling language is attempting to represent the real world concepts by modeling language constructs. The objective of this chapter is to complete the interpretation mapping analysis, which is to map PML constructs to BWWP concepts. Interpretation Mapping BWWP P M L Concepts Constructs Representation Mapping Figure 4-1: Two-way mappings As EPC modeling language is widely used in the field of business process modeling, its graphical symbols are adopted as a representation for a generic PML in most parts of the following discussions. However, due to the fact that some general constructs such as resource, input/output concrete object and business rule are missing in this language, it will not be used when discussing these constructs. 4.2 Choosing BWW Ontology The intention of the thesis is to build a general model of a process. To do this, we use the theoretical foundation of ontology. Ontology is a well-established theoretical domain within philosophy dealing with models of reality. It indicates what exists in the real world, and what rules are followed for things to interact in the real world. Wand and Weber have adopted an ontology presented by Mario Augusto Bunge (1977, 1979) and applied it to the modeling of information systems (Wand and Weber, 1989, 1990, 1993). The thesis will refer to this ontology as the BWW Ontology. Bunge's ontology is chosen as the foundation for our work due to the following strengths: 28 • It is well formulated in terms of set theory. • It has been applied in a number of studies related to information systems modeling and object-oriented concepts, thus providing a benchmark for evaluating other models (Green and Rosemann, 2000; Wand and Weber, 1993). • It has been used to suggest an ontological meaning to object concepts (Wand, 1989). • It has been used to generate predictions about conceptual models that have been corroborated empirically (Gemino, 1999; Weber and Zhang, 1996). 4.3 The fundamental premise of BWW Ontology The fundamental premise on BWW Ontology is that any modeling language must be able to represent all relevant concepts in the real world that might be of interest to users (Wand and Weber, 1993, 1995). Otherwise, the modeling language is regarded as incomplete from ontological point of view. This might, in turn, lead to incomplete or ambiguous models. If the model is incomplete, the final computerized information system might not adequately reflect the real-world domain. However, even if the model is complete, there still might exist the ontological clarity problems in the model. Two major situations that might occur when a modeling language is analyzed (Wand and Webber, 1993) are displayed in following: 1. Ontological completeness: For each ontological concept in the investigated domain, if there is at least one construct in the modeling language that could correspond to it, the language is regarded as "ontologically complete". 2. Ontological clarity: For the ontologically complete languages, there might exist one or more of the following deficiencies from the perspective of ontological clarity: • Construct Excess: There exists at least one element in the modeling language that does not have a counter-part in ontology. 29 • Construct Overload: There exists at least one element in the modeling language that has multiple interpretations in ontology. • Construct Redundancy: There exist at least two elements in the modeling language that share one ontological interpretation. Ontologically incomplete BWWO- P M L -concepts constructs Ontologically complete but unclear BWWO- P M L -concepts c o n s t r u c t s Ontologically complete and clear BWWO- PML-concepts constructs Construct Excess Construct Overload Construct Redundancy • © © # « # Figure 4-2: Ontological completeness and ontological clarity Ontologically incomplete models will lead to inadequate information systems which may partially represent the reality, while ontologically unclear models could generate faulty information systems which might be meaningless, ambiguous or redundant. 4.4 Original BWW Ontological constructs The modeling constructs in BWW Ontology can be organized into the following four categories (Wand and Weber, 1990; Zhao, 1995): Category Original Construct of BWW Ontology Static model of an individual 1. Thing, composite thing 2. Property, intrinsic property and mutual property, hereditary property and emergent property 3. State, conceivable state space, state law 4. Class, kind, natural kind To be continued in the next page 30 C a t e g o r y Or ig inal Cons t ruc t of B W W O n t o l o g y D y n a m i c m o d e l o f a n indiv idual 1. Event , conce ivab le even t s p a c e 2. Trans fo rmat ion , t rans fo rmat ion law 3. History Stat ic m o d e l of a s y s t e m 1. Coup l ing 2. S y s t e m 3. S y s t e m c o m p o s i t i o n , s y s t e m e n v i r o n m e n t , s y s t e m s t ruc tu re , s y s t e m d e c o m p o s i t i o n , s u b s y s t e m , level s t ruc tu re D y n a m i c m o d e l of a s y s t e m 1. Stable state a n d uns tab le state 2. Internal event and ex terna l even t 3. Wel l -de f ined even t a n d poor ly de f ined even t Table 4-1: Original constructs of BWW Ontology There ontological meaning will be explained in section 4.5. 4.5 Process-related BWWP constructs Some of the original BWW Ontological concepts are closely related with the concept of process, and those process-related BWW ontological concepts are referred to as BWWP constructs. The BWWP constructs include the original BWW Ontological constructs of thing (simple thing and composite thing), property (intrinsic property and mutual property, hereditary property and emergent property), state (stable state and unstable state), event (internal event and external event), transformation, and law (state law and transformation law). The new concepts added in BWWP construct set are: actor, non-actor, actuator, propagator, and process. The basic BWW ontological constructs can be summarized as follows (Evermann and Wand, 2001a; Wand and Weber 1995; Wand and Weber, 1990b): The world is made up of substantial thing. Things possess properties that are either intrinsic or mutual. A property could be mtrmsk'ii it is possessed by the thing itself (e.g. color of a car), or it could be mutual'ti it is commonly possessed by two or more things (e.g. distance between two cars). Things can combine to form a composite thing. Composite things possess emergent properties that are not possessed by any component (e.g. the speed of a car is the emergent property of a car that is not possessed by 31 any components of a car). The properties that are only possessed by components in a composite thing are hereditary properties (e.g. the horsepower of car engine). Attributes are representations of the properties of a thing as perceived by an observer. They can be modeled in terms of state junctions that are functions on time. A set of attributes used to describe a set of things with common properties is called a fmtianal schemt - common sets of attribute functions. The set of values of the state functions at a given time comprises the state of the thing. A state may be stable - which means it will not change until the thing is affected by another thing, or unstable - where the thing will undergo a spontaneous state transition. A lawis a relationship between properties. In particular, a law can be specified in terms of precedence of properties: Property A precedes property B if and only if whenever a thing possesses B, it possesses A The state-change from one to another over time is a transformation. The transformations a thing can undergo are determined by its transformation law. The state law restrict the values of the properties of a thing to a subset that is deemed lawful because of natural laws or human laws. Interaction is defined through the state history of a thing: If state changes in one thing depend on the presence of another, the second is said to act on the first. Interactions may be described in terms of changs in mutual properties (Evermann and Wand, 2001a). A change of state is termed an event. A n event can be described as an ordered pair of state <Sl, s2 > where s l and s2 are the state before and after the change, respectively A n external event is an event that arises in a thing, subsystem or system by virtue of the action of some thing in the environment on the thing, subsystem or system The before-state of an external event is always stable. The after-state maybe stable or unstable. A n internal event is an event that arises in a thing, subsystem, or system by virtue of lawful transformations in the thing, subsystem, or system The before-state of an internal event is always unstable. The after-state maybe stable or unstable (Wand and Weber, 1995). For example, let a thing be in a stable state s l . A n interaction with other things can change its state, say to s\ We shall call <S 1, s' > an external event. Now, if the state s' is unstable, then according to the assumptions the thing will keep changing its state until it reaches a new stable state s2. Note, s2 is actually defined by the lawful transformations of the thing. The event <s', s2 >is an internal event. The internal event does not depend on the interaction with other things but only on the lawful transformations that are intrinsic characteristics of the thing itself (Wand and Weber, 1990b). Besides the original BWW ontological concepts introduced above, some new concepts are added in BWWP. They are described as follows: A thing could be differentiated into an actor or a non-actor. A n actor is a thing that changes the state of itself or at least one other thing (actor/non-actor). A non-actor is a thing that does not change the state of any thing including itself. The state of a non-actor can only be changed by an actor. For example, when a clerk walks, her state is changed by herself and she is an actor. When a clerk uses a telephone set to make a call, 32 the clerk changes the state of herself and also the state of the telephone set, so the clerk is an actor. The telephone set is a non-actor as it is not able to change the state of itself, nor is it able to change any other things. Its state could only be changed by the clerk An actor could be an actuator if it changes the state of at least one other thing (actor or non-actor). For example, if the clerk just walks, she is not an actuator because she does not change the state of any other things. When she makes telephone calls, she is an actuator because she changes the state of at least one other thing: the telephone set. An actuator could be upropagttorii it changes the state of at least one other actor. For example, if the clerk makes a phone call and a worker is activated by her to move a forklift, the clerk is a propagator because she changes the state of another actor: the worker. Propagator BWWP-Thing Figure 4-3: BWWP constructs related with t h i n g A process involves a set of actors and non-actors who interact one another. The process is actiiated when at least one actor is changed from stable state to unstable state. One or more events could trigger a process. The process is completed-when all actors and non-actors are in stable states. 4.6 Ontological model of a process An ontological model of process is the description of a business process using ontological concepts rather than PML concepts. We start to analyze how several things interact in a system in terms of BWWP concepts. Some questions need to be clarified, such as: What is the system like before the process starts? How do things interact with each other? When do things stop changing? What is the state of the system when the process is completed? 4.6.1 A system of four things To capture the essentials of an ontological process model, an ontological analysis is needed for a generic scenario of a system that is composed of several things (including actors Non-actor Actor 'Actuator 33 and non-actors, simple or composites). The ontological analysis here is performed by considering the state-change happened to each thing in the system. The scenario being used here is described in Figure 4-4. For simplicity, we do not distinguish the concepts between property and attribute. Figure 4-4: A system of four things There are four individual things: A, B, C, and D. A, B and C are actors, and D is a non-actor which only interacts with B. A has properties: pi, and p2. B has properties: p2, p3, p4, and p5. The mutual property of A and B is p2. C has properties p4, p6. The mutual property of B and C is p4. Non-actor D has property p3. It does not have any other properties. The mutual property of B and D is p3. Composite thing A+B is also an actor, it has emergent properties p6, p7 and p8. P6 is the mutual property of C and A+B. 4.6.2 Ontological analysis Figure 4-5 displayed the interactions between the four things from BWWP ontological perspective. For clarity, all the stable states are labeled as sl, s2, s3, ... and all unstable states are labeled as ul, u2, u3, .... Based on the definitions of BWWP concepts, the 34 analysis in this section attempts to find the ontological principles of thing's interaction in a process, and demonstrate them by the example. The ontological principles found in this section will be summarized as a set of ontology-based integrity rules later. The detailed analysis is presented as follows: (1) All things stay in stable states before the process starts. Demonstration: Before the process starts, A, B, C and D are all in stable states. (2) The first change in the system is triggered by the system environment. This change is effected by a thing in the environment to change the mutual property of a thing in the system. Demonstration: A thing in the environment changes the value of pi (mutual property of the thing in the environment and actor A) and triggers A to change from stable state sl to unstable state u l . The process is activated now. (3) Based on BWW Ontological principle of interaction, all things interact by changing the value of mutual properties. Demonstration: A thing in the environment interacts with actor A by changing the value of mutual property pi. Actor A interacts with actor B by changing the value of mutual property p2. Actor B interacts with non-actor D by changing the value of mutual property p3. Actor B interacts with actor C by changing the value of mutual property p4. Actor C interacts with composite actor A+B by changing the value of mutual property p6. Composite actor A+B interacts with a thing in the environment by changing the value of mutual property p8. (4) When an actor modifies its intrinsic properties, it does not affect any other things but only changes the actor itself. Demonstration: Actor B modifies the value of p5 (intrinsic property) and this only causes B to continue changing. Composite actor A+B modifies the value of p7 (intrinsic property) and this only causes A+B to continue changing. 35 Actor B Non-actor D Stay in stable state. Value of pi is set by environment. ' >i Changing value of p2: A, B mutual' property Value of p2 is changed. Stay in stable state. Stay in stable state. Changing value of p7: intrinsic property Value of p7 is changed Lj Changing value of p8: mutual property of A+B and environme Value of p8 is changed. Stay in stable state ul 0 Stay in stable state. Stay in stable state. New value of p2 triggers B to change states. Changing value of p3: mutual property ofBandD. Value of p3 is changeaT^ T Changing value of p4: mutual property —f* of B andC. Value of p4 is changeuT^ Changing value of p5: intrinsic property Value of p5 is changed. Actor A+B New value of p3 triggers D to changej states. New value of p6 triggers A+B to change states. sl Actor ( sl Stay in stable state. sl s2 New value of p4 triggers C to change states. s l Changing value of p6: mutual property" ofC and A+B. Value of p6 is changed. LJ u 1 Stay in stable stater Non-actor Triggering event I D Stable state, values: sl, s2, s3,.. Unstable state, values: ul, u2, u3,. Explanation j Life line of a thing Figure 4-5: Ontological analysis to the four things 'interaction 36 (5) After a thing starts change, it modifies all its properties and eventually reaches a new stable state. Demonstration: Actor A stops changing after all its properties (pi and p2) are modified, and stays in a new stable state. Actor B stops changing after all its properties (p2, p3, p4 and p5) are modified, and stays in a new stable state. Same to actor C and composite actor A+B. Non-actor D stops changing after its only property p3 is modified, and stays in a new stable state. (6) A non-actor is not able to change any thing including itself. Therefore, all its properties are mutual with actors, and its intrinsic properties are of no interest in the model. Its state-changes are always caused by actors through changing the values of the mutual properties, and they are always from a stable state to another stable state. Demonstration: Non-actor D does not have any intrinsic properties. D changes from a stable state to another stable state. (7) The interaction between a composite thing and a simple thing or another composite thing follows the same principle: the interaction is performed by changing the value of mutual properties. Demonstration: Actor C interacts with composite actor A+B by changing the value of mutual property p6. (8) A composite thing and its components are observed from different standpoints. Demonstration: When composite actor A+B is changing, we have no idea what happens in its components A and B. Similarly, when actor A and B are changing, we have no idea what happens in composite thing A+B. (9) The process is completed when the last thing (actor or non-actor) stops changing and all things are in stable state. Demonstration: A stops changing first, and D, B, C stops later on. The last thing A+B stops finally and then the process is completed. 2 Note: If we are interested in state transitions of a non-actor, we could look at it as an actor. In this case, its intrinsic properties can be included in the model. 37 4.6.3 State curves A state curve diagram in Figure 4-6 is used to analyze the concepts of external event, internal event and transformation in a process. Like in the previous section, a demonstration in the example will follow the principles found in the analysis. (1) In order to change, things must interact with its environment. Therefore, each thing must be activated by an external event. An external event occurs by virtue of an interaction with the thing's environment. Demonstration: A, B, C, D and A+B all start change when triggered by an external event. These external events are: A (sl, ul) ; B (sl, ul) ; C (sl, ul) ; D (sl, s2); A+B (sl, u l ) . (2) The before-state of an external event is always stable. An actor has its external event end with an unstable state so that it could keep changing itself or another thing. A non-actor has it external event end with a stable state because it is unable to change any thing including itself. Demonstration: The before-state of each external event are all stable. The end-state of external event for actors A, B, C and A+B are unstable. The end-state of external event of non-actor D is stable. (3) Internal events occur by virtue of transformations in a thing. For an actor, all the subsequent events following an external event are internal events. As an actor has at least one transformation to reach stable state again, there is at least one internal event during an actor's change. Similarly, as a non-actor is not possible to have transformation, it does not have any internal events. Demonstration: A has internal events (ul,s2). B has (ul, u2), (u2, u3), (u3, s2). C h a s ( u l , s 2 ) . A+B has (ul, u2), (u2, s2). Non-actor D does not have any internal events. 3 Note: A state curve shows how an actor changes its state over time. The x-axis indicates the time, which is considered discrete when a state-change needs to be shown. The y-axis indicates the value of properties (i.e., state). For an unstable state, the value on y-axis varies in some extent showing that the state is not as stable as a straight line. However, the variance on y-axis is regarded as "no change" if it does not surpass a threshold. When the value on y-axis varies over a threshold, it is regarded as a state-change. For a stable state, the value on y-axis does not have any variance. 38 A s2(pl = l.p2=n Statc u l (p l = l , p2=0) ext. e sl(p_is0,p2=0) ->| transf. j ^ - Time B State S 2(p2=l,p3=l,p4=l ,e5=tpli-lnt.c u3fp2=l. p3=l. p4=l, p5=fl) | int.e u2(p2= 1, p3=1, p4=0, p5=0) int.e u 1 (p2=1. p3=0, p4=0, p5=9)- r-cxt.c s 1 (p2=0. p3=0, p4=0, p5=0> T — X transfi-4—transftf—transf.|<— Time c State s2(p4=l. p6=n ul(p4=l. p6=0) sl(p4=0, p6=0) T —>| transformation |<— Time D State s2(p3=ll. sl(p3=0) ext. a T Time A+B State s2(p6=l.p7=l.p8=l) -A int. e| u2(p6=l. p7=l. p8=0) _ [ uUp6=l.p7=0.p8=01 sUp6=0. p7=0. p8=0) int. e ext. —>) transf.-j- transf. Time Figure 4-6: State curves of each thing 39 (4) An actor undergoes a transformation when its state is changed from one to another over time. For a non-actor, since its state changes from stable to stable with no time, it does not undergo any transformations. Demonstration: A, B, C and A+B undergoes transformations D doesn't. (5) After an actor starts to change, whenever it modifies one property, it undergoes one transformation. When an actor modifies all its properties, it undergoes one sequence of transformations. Demonstration: After A starts to change (pi is modified by the environment), A modifies another property p2 and undergoes a transformation. It also undergoes a sequence of transformation that comprises only one transformation. After B starts to change (p2 is modified by A), B modifies p3, p4 and p5. Each modification leads B to a transformation. When all of p3, p4 and p5 are modified, B undergoes a sequence of transformations. Same to C and A+B. (6) A transformation always starts from an unstable state. It could end with either a stable state or an unstable state. Demonstration: The only transformation of A starts from an unstable state: u l . It ends with a stable state s2. All the transformations of B start from an unstable state: u l , u2 and u3. They end with different states of u2, u3 and s2 respectively. (7) The concept of external event, internal event and transformation also applies to composite thing. 4.7 PML-BWWP construct mapping rules After doing a detailed ontological analysis to a business process, the counterparts of PML constructs in BWWP can be described. In the following, we attempt to look at a process from both BWWP and PML perspectives, and find the mapping rules between them. To avoid confusions between the two types of concepts, the prefixes of BWWP- and PML- are used. The PML concepts will be analyzed in the following order: Agent, resource, data, event, 40 state, activity/operation, logical connector, business rule, input object and output object. 4.7.1 PML-Agent A PML-agent is normally defined as "a person or an organizational unit who executes the process activities." There are two kinds of participants in a process. The active participants who have the ability to take actions in the process are considered as agents, and the passive participants whose states are totally affected by agents' behaviors are PML-non-agents. For example, the agents could be human beings and organizations such as a company, a department, a political parties and a team, and non-agents could be resources used by agents during the process such as a document, a computer program, and some tools. The behavior of agents is the main focus of PMLs. The construct in BWW Ontology that defines the entity to be modeled is "thing", which is defined as a substantial individual that is perceived to exist physically. A PML-agent could be either a person or a material organizational unit, which is also composed of persons and other substantial individuals. For example, an organization such as a company, a political party, a department, a team, etc. is the object on behalf of which that human being participates in the process. The concept of BWWP-actor extends the concept of "thing" and expresses an active participant that can cause other participants or itself to change states, which is the same implication of PML-agent concept. Accordingly, we claim that a PML-agent is represented by a BWWP-actor. Mapping rule 1: PML-agent maps to BWWP-actor. In the WaterSystem example (the complete example is presented in Appendix I), the agents are "Sales dept.", "Warehouse dept.", "Manufacturing dept.", "Purchase dept.", and "Accounting dept.". All of them are substantial entities, and their actions cause other 41 participants change. 4.7.2 PML-Resource A PML-resource is a substantial thing that is utilized or referenced by an agent to assist the execution of the activity. The difference between a FML-resource and a YML-agent is that a resource is unable to change the state of any participant including the resource itself. The state of a resource could only be changed by one or more agents. If its state is temporarily changed and will be changed back when the activity is over, this resource is called "carried forward' resource. In the WaterSystem example, in the process of "Arrival' when the agent "Warehouse dept." performs the activity "Add to warehouse", it utilizes a forklift as a tool. This forklift will be changed back to its previous state when the activity is over. Therefore, it is a "carried forward" resource. On the other hand, if the state of a resource is changed permanently during the activity, the resource is called "consumable" resource. In the example, in the process of "Assembly" when agent "Manufacturing dept." executes the activity "Assemble product", it consumes electric power. In BWWP concepts, a non-actor is defined as a thing that is not able to change the state of any thing including the non-actor itself. Hence, we have the following rule: Mapping rule 2: PML-resource maps to BWWP-non-actor. 4.7.3 PML-Data In PMLs, data is a special kind of resource that also can be utilized, referenced or modified when an agent is performing a task. But the difference is that data is conceptual rather than material. Data would be a representation of the states of other substantial things For example, the data of a product's diameter could be regarded as the value of a property "diameter" of the thing "product". An agent who involves in an activity may access this state information by sharing the 42 representation in some way between the agent and the data owner. This access is the interaction between two physical things: agent and the represented thing. The changes to data, in turn, could represent the outcomes of interactions where the represented thing changes states. For example, if an agent "worker" changes the data "product file", it represents an outcome of interaction between a worker and a product that the worker has changed the product's properties such as "diameter" or "length", which means, the state of product is changed. However, the represented thing behind data is not of interest to most PMLs. We do not discuss what data represents in this paper, and a deeper meaning of data could provide new insights in future research. Mapping rule 3: PML-data maps to BWWP-state of the represented thing. Data could also be differentiated into two types: • Read only data - the data that do not change during the activities and can be reused many times without modification by the same or different agents. In this case, the represented thing is not changed during the activity. • Read and write data - the data that could be read by an agent and modified later on by the same agent during the execution of a particular activity. This reflects that the state of the represented thing is changed. 4.7.4 PML-Event A PML-event is a notable occurrence at a particular point in time, which causes an agent or a resource to start change or continue to change. It is the cause or the trigger for an activity or an operation to be invoked. From ontological perspective, B WWP-event is defined as a state-change of a thing caused by the interaction with some things in the environment, or by the transformations of 43 the thing itself. It is clear that there exists a difference between PML-event and BWWP-event concepts. PML-event is actually the starting point of a thing's state-change while BWWP-event is the state-change itself. Therefore, they cannot be simply mapped to each other. When attempting to find the ontological counterpart for PML-event, it is convinced that a PML-event which occurs to an agent is actually a vector of values of the agent's properties at the time when an expected fact occurs, which expresses the implication of BWWP-state concept. Hence, we have the following mapping rule: Mapping Rule 4: PML-event maps to BWWP-state of an actor. The PML-event that invokes next PML-operation could be named "triggering event". Similarly, the PML-event which is the result of a PML-operation could be named "resulting event". i operation operation Figure 4-7: BWWP-state in PML There are two types of PML-events: • Type one: For a PML-agent, when one activity (or a sequence of operations) is completed, it reaches a stable state and will never change until a new event arouses it. The PML-event at the end of an agent's activity could be mapped to BWWP-stable state of the actor (PML-agent). Mapping rule 5: The PML-event at the end of an agent's activity maps to BWWP-stable state of 44 the agent (BWWP-actor). In "Order Processing" process of the WaterSystem example, the event "Order closed" is the BWWP-stable state of the agent "Sales dept.", and the event "Paid vendors" is the BWWP-stable state of agent "Account payable dept.". • Type two: If the PML-event triggers an agent to change, it means that the agent is in unstable state and its change starts. Similarly, the PML-event which locates between an agent's two consecutive PML-operations (if any) is also an unstable state, because there is an operation following it and the agent will continue to change to another state later on. Mapping rule 6: An agent's all PML-events except the final event map to BWWP-unstable states of the agent (BWWP-actor). 1 ^ operation A. C a^gent A^) operation event operation operation event C^agent~C )^ operation Figure 4-8: BWWP-stable state of actor B Figure 4-9: BWWP-unstable state of actor B In the "Order Taking" process of the WaterSystem example, the event "Order placed" is a BWWP-unstable state for agent "Sales dept.". In the "Assembly" process, the event "Assembly done" is a BWWP-unstable state for agent "Manufacturing dept.". All these unstable states will keep changing till the agent reaches a stable state. 45 4.7.5 The sequence of "event-* operation—event" in PML The following question will be: what should be the counterpart for BWWP-event in PML. As mentioned before, a BWWP-event is defined as a state-change of a thing, which is normally expressed as a pair of states <sl, s2>. In PMLs, when an agent need to change states, it follows the procedures below: (1) A PML-event occurs. (2) A PML-operation starts. (3) A new PML-event occurs. The first PML-event gives the agent's state before the agent changes, and the second PML-event gives the agent's state after it changes. The PML-operation in between indicates the task that the agent need to do in order to change it state from one to another. Therefore, the sequence of "event-^ operation-'-event" in PMLs describes the "state-change" of the agent through an PML-operation, and it can be mapped to BWWP-event concept in ontology. Mapping Rule 7: The sequence of "event—-operation—-event" in PML maps to BWWP-event. Figure 4-10: BWWP-event in PML Here, we need to further differentiate the concepts of BWWP-external event and BWWP-internal event. • A BWWP-external event to an agent describes an agent's state-change that is caused by the interaction with a thing in the agent's environment. Hence, the external event must 46 represent the state-change of an external thing. Mapping rule 8: The sequence of "event-*operation-*event" which belongs to a thing in an agent's environment and activates the agent to start change is mapped to BWWP-external event of the agent (B WP-actor). In "Order processing" process of the WaterSystem example, the sequence "Order approved-* Arrange payment-* Payment made" which belongs to the state-change of another agent "Sales dept." is an external event for the agent "A/R dept." to start "Collect payment" operation. operation 1 Cjigent A^> Figure 4-11: BWWP-external event for actor A in PML • A BWWP-internal event to an agent describes an agent's state-change that is achieved by its lawful transformation. Hence, the internal event must represent the state-changes of the agent itself, which are accomplished through its operations. Mapping rule 9: For each sequence of "event-*operation-*event" of an agent, if the "operation" is performed by the agent, then the sequence maps to BWWP-internal event of this agent (BWWP-actor). In the "Order taking" process of the WaterSystem example, the sequence of "Product available-* Approve order-*Order approved" is an internal event for agent "Sales dept.". 47 Figure 4-12: BWWP-internal event for actor A in PML 4.7.6 PML-State A PML-state represents the values of all properties of a participant at a particular point of time when a PML-event occurs. Similarly, a BWWP-state is defined as the vector of values for all attribute functions (or properties) of a BWWP-thing. It could be interpreted as a complete assignment of values to all n attribute functions Fi (A, t) in the function schema, where n is the number of attribute functions, i is from Won, A is the agent, and / is the time when triggering event occurs. Therefore, we have the following mapping rule: Mapping Rule 10: PML-state maps to BWWP-state. As both VML-event and VML-state have the same ontological counterpart of BWWP-state, most PMLs only use one of the constructs in order to avoid ontological redundancy. In the "Purchasing" process of the WaterSystem example, the agent "Purchasing dept." has the following properties: Property p i : Purchase plan situation. Possible value: Purchase needed/not needed. 48 Property p2: Order to vendor situation. Possible value: Order placed/Order not p laced. There are two states before and after the activity "Place order with vendors": State s l : p i = Purchase needed, p2 = Order not p laced; State s2: p i = Purchase needed, p2 = Order p laced. 4.7.7 PML-State of a joint agent There might be a situation where two or more agents are involved in one PML-operation. In this case, the PML might need to capture the states of the joint agent that is composed of the individual agents. From BWW Ontological point of view, this joint agent is the BWWP-composite thing, whose states are the values of emergent properties that do not belong to any of the components. Mapping rule 11: PML-joint agent involved in a PML-operation could be mapped to BWWP-composite thing, and PML-state of the joint agent could thus be mapped to BWWP-state of the composite thing. For example, an activity is executed by a joint agent "A" that is composed to two individual agents " A l " and " A 2 " . The states that PML need to keep track of are the BWWP-states of BWWP-composite thing A, which gives the values of the emergent properties of BWWP-composite thing A. These emergent properties belong neither to A l nor to A2. 4.7.8 PML-Activity and PML-Operation PML-activity and PML-operation represent the actual tasks that an agent carries out in order to change the states of itself or other participants. A PML-activity is an atomic action in a process, which means once it starts it will eventually reach an end. A PML-operation is a component of an activity. A PML-activity need to be divided into operations so that the agent's intermediate states could be captured. These intermediate states might trigger other agents to change, or might cause the agent itself to continue its change. 49 In this sense, both a PML-activity and a PML-operation can be regarded as a BWWP-transformation, which represents an agent's state-change over time. The difference is, an operation could be any transformation (which always starts from an unstable state) and an activity is a sequence of operations where the first follows a state-transition from stable to unstable (i.e. an external event), and the last ends with a stable state. State stable: s2 unstable: u2 unstable: ul stable: sl * 1 1 1 1 1 1 1 ! i ta j i ! ta+1 tb ! operationl tb+l tc operation2 tc+l Time i i |. activity Figure 4-13: A state curve of two operations Figure 4-13 presents a state curve of an agent, which start to change at time ta+1 and its change stops at time tc+l. It is clear that the agent undergoes two operations: the first changes the state from unstable to unstable, and the second from unstable to stable. The whole sequence of operations forms an activity, where the first operation follows a transition from stable state sl to unstable state ul (this change represents an external event <sl, ul>), and the last operation ends with a stable state. Mapping Rule 12: PML-operation maps to BWWP-transformation. Mapping Rule 13: PML-activity maps to a sequence of BWWP-transformation, where the first follows a state-transition from stable to unstable (i.e. an external event), and the last ends with a stable state. Therefore, PML-operation and PML-activity represent two different ontological concepts, 50 and A PML-operation is not simply a component of a PML-activity. In the "Order processing" process of the WaterSystem example, the agent "Warehouse dept." undergoes three PML-operations: "Check order in warehouse", "Ship products" and "Rearrange warehouse". The sequence of the three operations could be regarded as one PML-activity named "Arrange shipment". 4.7.9 PML-Logical connector A rule in a business process maps to the BWWP-law concept. A rule can be expressed by a logical connector or a business rule in general. The logical connectors in PMLs are used to define the order of activities in a process by expressing the logical relationships between PML-events and PML-activities (such as in EPC, IDEF3 Transition Schematics and EDPM Method). Some PMLs use logical connectors to express the relationships of activities only (such as IDEF3 Process Schematics and UML Activity Diagram), while other PMLs (such as IDEFO) do not explicitly provide the detailed logical connectors. Taking the most complicated case into consideration, the PML-logical connectors attempt to capture the causal relationships between events and activities in the following three categories: (1) One PML-event logical connector — two or more PML-operations (2) Two or more PML-events — logical connector — one PML-operation (3) One PML-operation — logical connector — two or more PML-events The detailed ontological analysis could be seen in Appendix II "Ontological analysis of PML-logical connectors". As a logical connector defines the rules between activities or operations, it might map to the concept of BWWP-/aw. 51 BWWP-law has two types: state-law and transformation-law. A BWWP-state law restricts the states of a thing to a subset that is deemed lawful because of a natural law or human law (here, when considering business process, the natural law could be some business rules). From PML perspective, the end of an PML-operation could possibly initiates all of, one of or either oj'the two or more different PML-events according to the defined logical relations of "AND", "OR" or "XOR". These PML-events restrict the agent's states to a subset rather than all the possible values, which is regarded as lawful states based on the given rules. Mapping rule 14: The sequence of "operation-*logical connector-'-eyent" in PML maps to BWWP- state law. On the other hand, when a PML-event is going to invoke two or more operations according to the logical relations of "AND", "OR" or "XOR", the two or more alternative operations are deemed lawful in the process, and any other operations are not allowed. This restricts the possible alternative operations (which maps to BWWP-transformation) in a process. As a BWWP-transformation law determines all the transformations a thing can undergo, we have the following mapping rule: Mapping rule 15: The sequence of "event-^logical corinector-*operation'' in PML maps to BWWP- transformation law. 4.7.10 PML-Business rule There are two different mechanisms that PMLs use to capture rules in a business process: They use the concept of PML-/og/ca/ connector for rules between operations, and the concept of YML-business rule for rules within an operation. The construct of "controls" in IDEFO and the construct of "rules" in EDPM Method are both PML-business rule concepts. In the "Assembly" process in the WaterSystem example, 52 the "Product assemble guide" is a business rule for activity "Assemble product" of agent "Manufacturing dept.". A PML-business rule could be considered as a set of PML-logical connectors when used in executing an operation or activity. The concept could be eventually decomposed into PML-logical connectors when decomposing an operation or activity. Mapping rule 16: PML-business rule maps to BWWP-law. 4.7.11 PML-input object and PML-output object As a PML-input object represents the concrete object which is transformed by an activity or operation into output object, and a PML-output object is the concrete object which is produced by the activity or operation, both the PML concepts could be mapped to BWWP-non-actor concept. Mapping rule 17: PML-input object and PML-output object map to BWWP-non-actor. 4.8 Summaries of the two outcomes We have two findings in this chapter: one is a set of PML-BWWP construct mapping rules, and another is a set of ontology-based integrity rules. They are summarized in the following parts for the easy use in the following chapters. 4.8.1 Summary of the PML-BWWP construct mapping rules The PML-BWWP construct mapping rules are summarized in Figure 4-14. This mapping summery will be used in the next chapter to evaluate the five PMLs. 53 BWWP concepts PML constructs Thing Actor • - © Agent Non-actor • — o Resource ^ - 0 Input/output object State State — 0 Event - o State Stable state • * — o Agent's final event Unstable state • - — o Agent's all events except the final event Representation of a thing's state • « o Data Event Event • - — 0 A sequence of "event - operation - event" External event • « — o A sequence triggering the agent in env. Internal event • ^ — 0 All other sequences Transformation A sequence of transformations • « — 0 Activity Transformation • — o Operation Law Law • - — 0 Business rule State-law • " —o Operation - logical connector - event Transformation law • « — 0 Event - logical connector - operation Figure 4-14: PML-BWWP construct mapping rules 4.8.2 Summary of the ontology-based integrity rules The ontology-based integrity rules have been discussed in section 4.6 "Ontological model of a process". These rules form the foundation of an algorithm on how to construct a theory-based process model rather than a process model built on observation and empirical experience. The algorithm will be presented in Chapter six. The rules are summarized as follows: (1) All things stay in stable states before the process starts. (2) All things interact by changing the value of mutual properties. (3) The first change in the system is triggered by the system environment. This change is effected by a thing in the environment to change the mutual property of a thing in the system. (4) When an actor modifies its intrinsic properties, it does not affect any other things but only changes 54 the actor itself. (5) After a thing starts change, it modifies all its properties and eventually reaches stable. (6) All properties an non-actor are mutual with actors, and its intrinsic properties are of no interest in the model. Its state-changes are always caused by actors, and they are always from a stable state to another stable state. (7) A composite thing and its components are observed from different standpoints. (8) The process is completed when the last thing stops changing and all things are in stable state. (9) In order to change, each thing must be activated by an external event. (10) The before-state of an external event is always stable. An actor has its external event end with an unstable state. A non-actor has it external event end with a stable state. (11) All the subsequent events following an external event are internal events for an actor. There is at least one internal event during an actor's change. A non-actor does not have any internal events. (12) After an actor starts to change, whenever it modifies one property, it undergoes one transformation. When an actor modifies all its properties, it undergoes one sequence of transformations. (13) An actor undergoes a transformation when its state is changed from one to another over time. A non-actor does not undergo any transformations. 55 Chapter 5 E V A L U A T I O N O F P M L S The observations on the five PMLs in Chapter two and three show that these PMLs have problems in their expressiveness. As the PML-BWWP construct mapping rules obtained in Chapter four form clear semantics for PMLs, the five PMLs can be evaluated in terms of ontological completeness and ontological clarity based on the construct mapping rules. Identifying possible ontological deficiencies of the current PMLs can help to clarify the basic concepts for the process modeling methodology. 5.1 Evaluation of EPC Figure 5-1 shows the details in mapping EPC constructs to BWWP concepts and the generic PML concepts. Several observations need to be addressed here: • Missing the concept of PML-resource, input/output object PML-resource and input/output object concepts represent a non-actor in BWWP concepts. They are used to model the participants whose states are changed only by actors. In the real world, a PML-resource is a thing that is utilized or consumed by an agent during the agent's state-change, a PML-input object is a thing that is transformed by the activity or operation into output object, and a PML-output object is a thing that is produced by an activity or operation. It is possible for an agent to change its state without utilizing a resource or an input object and without producing any output objects as well. For example, without using any tools, a clerk can ask a worker start assembling products. Therefore, a modeling language does not necessarily need to show PML-resource and PML-input/output object in the model. In such case, EPC could be sufficiently complete. • Missing the concept of PML-state 56 Based on PML-BWWP mapping rule 4, both PML-event and PML-state map to a single BWWP concept of BWWP-state. EPC already includes the PML-event concept, which indicates the "state" of the agent before and after a transformation. Thus, it avoids the problem of "Construct redundancy". BWWP concepts PML constructs EPC constructs Thing Actor • - — 6 Agent Organizational unit Non-actor • O Resource N/A o Inputfoutput object N/A State State • « 0 Event Event o State N/A Stable state • - 0 Agent's final event Agent's final event Unstable state • - 0 Agent's all ev. except final Agent's all events except final Repr. of state • - 0 Data Information in/out Event Event • — 0 A seq. of "ev. - op. - ev." A sequence of "ev. - func. - ev.' External event • - Q A seq. triggering the agent A sequence triggering the agent Internal event • — o All other sequences All other sequences Transformation A seq. of transf • - — o Activity Function Transformation • * — 0 Operation Function Law Law « 0 Business rule N/A State-law • * — o Op. -connector - ev. Function -connector - event Transformation law • — © Ev. -connector - op. Event -connector - function Figure 5-1: Mapping EPC constructs to BWWP concepts • Missing the concept of PML-business rule Without PML-business rule construct, EPC is unable to express the rules WITHIN activities or operations. However, it has a PML-logical connector construct, which enables EPC users to express the rules BETWEEN activities or operations. Lacking PML-business rule construct will not cause a big problem because whenever an activity or operation is decomposed, the business rules within it could be eventually expressed by logical connectors between decomposed activities or operations. • Construct overload: Mixing PML-activity and PML-operation EPC does not differentiate PML-activity and PML-operation. Both concepts are expressed by the construct of "function". Mixing the two concepts causes the problem of "Construct overload'. Users do not understand which function of an agent is to be triggered by its environment, which function is an intermediate operation that the agent will perform spontaneously without help from its environment, and which function is the last operation before the agent stops. Generally speaking, EPC is ontologically complete but has a problem of "Construct overload". 5.2 Evaluation of IDEFO Figure 5-2 shows the mapping from IDEFO to BWWP constructs. For each BWWP construct, IDEFO has at least one concept corresponding to it, so IDEFO is ontologically complete. However, the language is not ontologically clear enough. • Construct overload: Mixing PML-agent and PML-resource IDEFO does not explicitly include the concepts of PML-agent and PML-resource. Both of them are hidden in the construct of Mechanisms. Even though the Mechanisms construct maps to BWWP-thing (which includes both actor and non-actor), there is still the deficiency in that a single concept maps to two different BWWP construct (actor and non-actor). As the method does not differentiate PML-agent and PML-resource, users are hard to clearly identify the process,participant who executes an activity or operation and the participant who is only utilized in an activity or operation. This causes the problem of "Construct overload" and the modeling language is ontologically unclear even though it is complete. 58 BWWP concepts PML constructs IDEFO constructs Thing Actor • -« 0 Agent Mechanisms Non-actor • 0 Resource Mechanisms 49 Input/output object Input, output State State • H Event (1) Control (2) Output ® State N/A Stable state w 41 Agent's final event Agent's final output Unstable state w -« ® Agent s all event except final Agent's all cont./output except final Repr. of state ^ © Data Input, output Event Event # © A seq. of"ev. - op. -ev." A seq. of "control - function - output' External event • ® A seq. triggering the agent A sequence triggering the agent Internal event • ® Al l other sequences Al l other sequences Transformation A seq. of transf # -« ® Activity Function Transformation # * Operation Function Law Law # © Business rule Control State-law • ® Op. -connector - ev. Function -implicit connector - output Transformation law • O Ev. -connector - op. Output-implicit connector - function Figure 5-2: Mapping IDEFO constructs to BWWP concepts • Construct overload: Mixing PML-output object, PML-event and PML-data The same situation occurs with the concept of output in IDEFO. IDEFO-output has three roles: The first one is an output object. The second one is generated by an activity/operation as a new PML-event to trigger another activity/operation, and the third one is a PML-output data generated by an activity/operation. Therefore, the overloaded construct IDEFO-output maps to three BWWP concepts: BWWP-non-actor (PML-output object), BWWP-stote of the actor (PML-event) and BWWP'-representation of the state of anther thing (PML-data). • Construct overload: Mixing PML-event and PML-business rule The third "construct overload" problem occurs with the concept of Control. The IDEFO-control construct represents two things: one is a PML-event that triggers a new activity/operation, and the other is a PML-business rule used in an activity/operation. 59 Ontologically speaking, IDEFO-Control maps to two BWWP concepts: BWWP-state (PML-event) and BWWP-taw (PML-business rule). This problem potentially reduces the clarity of the model again. • Construct overload: Mixing PML-activity and PML-operation IDEFO does not differentiate PML-activity and PML-operation. Like in EPC, both concepts are expressed by the construct of "function". • Construct redundancy: mapping two constructs (IDEFO-control & IDEFO-output) to BWWP-state When used to trigger activities, PML-event concept is sometimes seen in the IDEFO-control construct, and sometimes seen in the IDEFO-output construct. Both the IDEFO constructs map to BWWP concept of state, causing a problem of "Construct redundancy". • Construct redundancy: mapping three constructs (IDEFO-mechanisms, IDEFO-input/output) to BWWP-non-actor The concept of BWWP-non-actor is seen in IDEFO constructs of Mechanisms, Input and Output. Overall speaking, IDEFO method is ontologically complete, but it has the problems of "construct overload" and "construct redundancy". 5.3 Evaluation of IDEF3 IDEF3 method introduced in Chapter two includes three diagrams: Process Schematics (Figure 2-4), Transition Schematics (Figure 2-5) and Enhanced Transition Schematics (Figure 2-6). Considering all three diagrams entirely, the mapping to BWWP concepts could be seen in Figure 5-3. • Ontological incompleteness: Missing PML-agent in the Process Schematics 60 In the Process Schematics, both PML-agent and PML-resource concepts are missing. The model describes a sequence of behaviors but does not mention who just participates in the behaviors and who is undergoing state-change. This causes the problem of "Ontological incompleteness". At the same time, the missing concepts are included the Transition Schematics and the Enhanced Transition Schematics. In these two diagrams, an agent and a resource are regarded as an object whose PML-states are captured in this object-centered view of IDEF3. In this aspect, the Transition Schematics are the compensation to the Process Schematics. BWWP concepts PML constructs IDEF3 constructs Thing Actor © A 8 E N T Non-actor • *~ © Resource © Input/output object N/A in (1); Object in (2)(3) N/A in (1); Object in (2)(3) N/A State State • © E v e n t State Stable state • © Agent s final event Unstable state © © Agent's all event except final Repr. of state • © Data N/A in (1)(2)(3) State in (2) (3) Object's final state in (2)(3) Object's other states in (2)(3) N/A in 0X2X3) Event Event © -« © A seq. of "ev. - op. - ev." External event • •* ® A seq. triggering the agent Internal event • •* © All other sequences State-UOB-state (2); N/A (1X3) State-UOB-state (2); N/A (1X3) State-UOB-state (2); N/A (1)(3) Transformation A seq. of transf | 4 Q Activity Transformation © -« © Operation UOB UOB Law Law • © Business rule State-law © + © Op. -connector - ev. Transformation law • •* © Ev. -connector - op. N/A State-connector-state in (2) UOB - connector - UOB in (1) Note: (1) Process Schematics (2) Transition Schematics (3) Enhanced Transition Schematics Figure 5-3: Mapping IDEF3 constructs to BWWP concepts • Construct overload: Mixing PML-agent with resource in Transition Schematics 61 However, as the PML-agent and PML-resource are equally treated as an object without differentiating into BWWP-actor and BWWP-non-actor, the problem of "Construct overload" exists in Transition Schematics. • Ontological incompleteness: Missing PML-event in the Process Schematics As there is not a PML-event concept in Process Schematics, this process-centered view of an agent's behaviors is not able to express the accurate events (or the agent's states) which trigger units of behavior (UOB). It only shows the order of UOBs, but never indicates the agent's states when the UOBs start and end. This is a problem of "Ontological incompleteness". There is a PML-state concept (which is ontologically equivalent to PML-event) in the Transition Schematics, which compensates on the weakness of the Process Schematics. • Construct Excess in the Enhanced Transition Schematics The Enhances Transition Schematics provide a static view of objects participating in a process. The model is similar to "Entity-Relationship" model, and includes BWW Ontological static concepts of thing, composite thing, property, class, and kind. As these concepts are not related with process models, the problem here could be regarded as "Construct excess". Sometimes the model provides two views of a process (dynamic and static) in a single diagram, and the excessive constructs give the diagram reader unrelated information about a process. • Construct overload: mixing PML-activity and PML-operation In IDEF3 Process Schematics, the concept of "Unit of behavior (UOB)" does not make distinction between a PML-activity and a PML-operation. As mentioned before, it causes the problem of "construct overload" which reduces the language's clearness to represent the real-world business process. 62 Overall speaking, IDEF3 is ontologically incomplete. In terms of ontological clearness, it has the problems of "construct excess" and "construct overload" in some diagrams. 5.4 Evaluation of UML Activity Diagram Figure 5-4 clearly shows that most of BWWP concepts do not have counterparts in UML Activity diagram, which indicates the problem of "Ontological incompleteness". BWWP concepts PML constructs Activity Diagram constructs Thing Actor • •« © Agent Separated by swim lanes Non-actor © 0 Resource N/A 0 Input/output object N/A State State © © Event N/A © State N/A Stable state © © Agent's final event N/A Unstable state © © Agent's all ev. except final N/A Repr. of state © © Data N/A Event Event © © A seq. of "ev. - op. - ev." N/A External event # ® A seq. triggering the agent N/A Internal event © © All other sequences N/A Transformation A seq. of transf # •* © Activity Activity Transformation # •* © Operation Activity Law Law • © Business rule N/A State-law • 0 Op. -connector - ev. N/A Transformation law • "* O Ev. -connector - op. Activity - connector - activity Figure 5-4: Mapping Activity Diagram constructs to BWWP concepts An Activity Diagram does not include BWWP concepts of non-actor, state, stable state, unstable state, event, external event, internal event, and state-law. Without these concepts, the modeling language is week in expressiveness and the constructed model is incomplete in representing the real process. For example, users might not know the states of the agent before and after an activity/operation, which external event triggers the activity/operation, 63 and which states are lawful after an activity/operation. Another problem is that Activity Diagram mixes the concepts of PML-activity and PML-operation. As mentioned before, it causes the problem of "Construct overload". Generally, Activity Diagram is neither ontologically complete nor clear. 5.5 Evaluation of EDPM Method Figure 5-5 shows that EDPM Method is ontologically complete as every BWWP concept has its counterpart in this modeling language. BWWP concepts PML constructs EDPM Method constructs Thing Actor • •« © Agent Non-actor • -« Q Resource © Input/output object Agent Resource Input, output State State • # E v e n t © State Stable state • * ' & Agent s final event Unstable state • « © Agent s all ev. except final Repr. of state 9 * © D a t a Event N/A Agent's final event All event's except final Input, output Event Event © A seq. of'ev. -op. -ev." External event • « © A seq. triggering the agent Internal event # « •• © All other sequences A seq. of "event - activity - event" A sequence triggering the agent All other sequences .transformation A seq. oftransf 9 + © Activity Transformation • © Operation Activity Operation Law Law • * © Business rule State-law • « © Op.-connector - ev. Transformation law • © Ev. -connector - op. Business rules Activity -connector - event Event - connector - activity Figure 5-5: Mapping EDPM Method constructs to BWWP concepts The following issues need to be addressed here: • Construct overload: Mixing PML-input/output object and PML-input/output data concepts As EDPM-input/output concept represents both PML-input/output object and PML-input/output data, it has two counterparts in BWWP: non-actor arid representation of a thing's state. This causes the problem of "Construct overload". • Construct redundancy: mapping two constructs (EDPM-resource and EDPM-input/output) to BWWP-non-actor Both EDPM-resource (which is a PML-resource) and EDPM-input/output (which represents PML-input/output object) concepts are mapped to one BWWP concept: non-actor. • PML-activity and PML-operation EDPM Method is the only language that differentiates these two concepts among the five PMLs. This differentiation enables the model users to decompose an activity when it is necessary to capture the intermediate states of an agent. It also gives the users an idea that an activity involves a sequence of operations, and it is atomic and will eventually reach a stable state once it starts. This helps the users to understand the agent's behaviors more accurately. • PML-business rule and PML-logical connector Both of these concepts capture the rules of a process from different perspectives. A logical connector indicates the rules between activities/operations, and business rule shows the rules within an activity/operation. Therefore, including both concepts does not cause the any ontological problems. Generally speaking, EDPM Method is ontologically complete, but it has the problem of "Construct overload" and "Construct redundancy". 65 Chapter 6 O B P M M O D E L I N G A L G O R I T H M The evaluation of the five PMLs shows that they have some shortcomings. First, they are information-systems oriented rather than real-world oriented. Second, most of them are either ontologically incomplete or unclear. Finally, they do not have formally defined rules to follow when constructing a business process model. In this chapter, a theory-based modeling algorithm is developed to provide general procedures for building an ontology-based process model (OBPM). The basic concepts and modeling rules are derived from BWW Ontology, which enables avoiding many problems of IS-oriented PMLs. The theoretical foundation is the set of ontology-based process model integrity rules found in Chapter four. The purpose of the algorithm is to provide a set of formal procedures for constructing theory-based process models. As well, if the algorithm is used in the context of a specific PML, it can indicate the information that cannot be captured by this PML. Moreover, it can uncover the missing information in specific PML models. The chapter will present the algorithm and demonstrate it with a business process example to show how the algorithm works. 6.1 Ontology-based Process Model (OBPM) algorithm This section introduces the proposed conceptual modeling algorithm which is derived from BWW ontology theory for constructing an OBPM model. The purpose of this algorithm is to identify the triggering event(s) for a process, find all participants (agents and resources), recursively identify the activities and operations for each participant, and find out their sequences. For a particular process, the inputs of the algorithm are the process domain 66 and environment situation. After the algorithm is executed, the users could obtain the following outputs: (1) A list of agents who participate in.the process: agent_list (2) A list of resources which are used or modified in the process: resource_list (3) The events that occur in the process, and their sequence. (4) For each agent, there are: • A list of activities the agent executes, and their sequences: activity_list • For each activity in activity Jist, a list of operations involved, and their sequences: operation Jist Main(environment. process domain) Identify all triggering events from environment. FOR E A C H triggering event e, DO: Identify all things affected by e in process domain. IF empty T H E N EXIT ELSE FOR E A C H affected thing t, DO: Invoke Affected_Thing(t, e). EXIT Figure 6-1: The main algorithm Affected ThingrThing t. Event IF t changes states from stable to stable T H E N Add t to resource_list; ELSE Add t to agent_list if not already there Decompose(t, e) EXIT Figure 6-2: Subroutine Affected_Thing(t, e) 67 Decompose(Agent a. Event e) Identify sequence of events (e15 e2, e3, e„) until a reaches a stable state. Index e as e0 Add transformation of <e0, en> as an activity to a's activity_list if it is not there. FOR E A C H event e; in sequence (i=l to n), DO: Add transformation of <e,.1, e> to a's operation_list of this activity. Identify all other things affected by e;. IF empty T H E N CONTINUE to next event. ELSE FOR E A C H affected thing aff_t, DO: Invoke AffectedJThing(aff_t, ef EXIT v : : J Figure 6-3: Subroutine Decompose(a, e) 6.2 Algorithm description The proposed algorithm for identifying these lists consists of the following three parts: The main algorithm Main(environment, process domain), subroutine Affected_Thing(thing, event) and subroutine Decompose(agent, event). It provides a recursive mechanism to investigate the state-changes of each agent, and generates a process model when it is completed. The main algorithm identifies the triggering events from the environment that occur in order, and identifies all the things affected by the events. For each affected thing, it calls the Affected_Thing() subroutine. The Affected_Thing() subroutine first looks at the state-change of the affected thing, and identifies the agents and resources. For an agent, the subroutine DecomposeQ is invoked to find out each agent's operations and activities, as well as the events generated during the state-changes. 6.2.1 The main algorithm Given the process domain knowledge and the environment situation, the algorithm shows how to identify the affected things and how to handle them in later steps. • Input 1: Environment situation Environment situation provides the information of the triggering event(s) that is needed to start the process. For example, when customer payment is made, OR assembled products 68 are ready, the "order processing" process is triggered. • Input 2: Process domain knowledge The process domain knowledge gives the information such as which things are affected by the triggering event(s). Here, the word "affected" means that the thing's stable state is changed. It could either change to an unstable state and keep changing till stable, or move to another stable state directly. The domain expert may be asked the following questions: What are the participants in the process? When the triggering event(s) occurs, which participants will start to change states? If no things are affected by the triggering event(s) e, the algorithm will exit, which means that the environment could not affect the process. Otherwise, for each affected thing t the algorithm will invoke a subroutine Affected_Thing(t, e) to find what happens when thing t is affected by event e. 6.2.2 Subroutine: Affected_Thing(input: Thing t, Event e) This procedure gives the instructions on how to differentiate resource and agent when thing t is affected by event e, and how to deal with the state-change of an agent. The two inputs are: Thing t and Event e. The subroutine starts by looking at the response of affected thing / to the event e: We ask the domain expert: Does this affected thing change its states from stable to stable, or from stable to unstable? (1) Affected thing ris a resource If its state-change is from stable to stable, that means fs state-change is not able to affect other things in the domain. Therefore, we could consider it as a resource used by the agent t during one of its operations or activities. In this way, the resource t is added to the process' 69 resource Jist. (2) Affected thing / is an agent Otherwise, if the state-change oft is from a stable to an unstable state, the thing will keep changing and might change the state of other things. This thing should be added to the process's agent Jist if it has not been added to the list before. (3) Decompose the change into activities and operations When an agent's state-change is triggered, a procedure to decompose the agent's state-change into activities and operations is needed. The subroutine Decompose(Agent t, Event e) is invoked for this purpose. 6.2.3 Subroutine: Decompose(input: Agent a, Event e) This subroutine provides instructions on how to decompose the state-change of an agent a into activities and operations when it is triggered by event e. The inputs are: Agent a and event e. (1) Identify the sequence of events until agent a reaches stable state. The first question we need to ask is: When event e occurs and agent a undergoes a state-change, what other events in sequence could occur to the agent a? In order to easily label the activities and operations, each event in the sequence is indexed from 1 to n (n is the number of events in the sequence), and the triggering event e is indexed as eO. (2) Add an activity to the agent's activity_list Each pair of any consecutive events represents an operation, and an activity comprises the whole sequence starting from eo to en. This activity should be added to the agent a's activity Jist. The last event e„ in the sequence is a stable state of agent a, and it might be the 70 goal of this agent in the process if the agent has no future change. When this goal is achieved, the agent will stay in stable state till another agent triggers it to change state for a new goal. (3) Add all operations in the current activity to the agent's operation_list of this activity. The second question to ask the domain expert is: What are the operations that agent a performs to finish the current activity? As each event-pair of any consecutive events in the sequence of {eo, ei, e°2, en} is an operation, we need to add them to the agent's operation_list. (4) For each event in sequence, find the affected things. The third question to ask the domain expert is: For each event in the sequence, which things are affected by it? If there are not any things affected by the event, it means that the agent is changing continuously without affecting other things. Therefore, we will not include the agent itself from the affected things list. The algorithm will continue and check the next event in the sequence till the end. (5) For each affected thing / by each event e, invoke Affected_Thing(t, e). For each event e; in the sequence, if it affects other things, the algorithm will recursively call the subroutine Affected_Thing (t, d) to each affected thing t, until the state-change of all things t affected by e,- are decomposed into activities and operations. As previously described, this subroutine will recursively do the following: Find out whether the affected thing ris a resource or an agent. If it is a resource, add it to the resoucejist of the activated operation of t. And if it is an agent, the subroutine Decompose^, ej will be invoked recursively. 6.3 Theoretical foundation of the algorithm The algorithm is generated based on the ontological-based integrity rules, which are 71 summarized in Chapter four. Table 6-1 shows the relationships between the steps in the OBPM algorithm and the ontology-based integrity rules. Algorithm Step Rule number Main() Identify all triggering events from environment. (1), 0), (9) Identify all things affected by each triggering event. (2), (3), (10) Affected_Thing(t, e) If t changes state from stable to stable, then add it to resourcejist. (2), (6), (10), (13) Otherwise, add t to agentjist. (2), (10), (12), (13) Decompose^, e) Identify sequence of event until a reaches stable. (5), (8), (12), (13) Add the whole sequence as an activity to activityjist. (12), (13) Add each pair of consecutive events as an operation to operationjist. (12), (13) Note: The ontology-based integrity rules are listed as follows for easy reference. (1) A l l things stay in stable states before the process starts. (2) A l l things interact by changing the value of mutual properties. (3) The first change in the system is triggered by the system environment. This change is effected by a thing in the environment to change the mutual property of a thing in the system. (4) When an actor modifies its intrinsic properties, it does not affect any other things but only changes the actor itself. (5) After a thing starts change, it modifies all its properties and eventually reaches stable. (6) A l l properties an non-actor are mutual with actors, and its intrinsic properties are of no interest in the model. Its state-changes are always caused by actors, and they are always from a stable state to another stable state. (7) A composite thing and its components are observed from different standpoints. (8) The process is completed when the last thing stops changing and all things are in stable state. (9) In order to change, each thing must be activated by an external event. (10) The before-state of an external event is always stable. A n actor has its external event end with an unstable state. A non-actor has it external event end with a stable state. (11) A l l the subsequent events following an external event are internal events for an actor. There is at least one internal event during an actor's change. A non-actor does not have any internal events. (12) After an actor starts to change, whenever it modifies one property, it undergoes one transformation. When an actor modifies all its properties, it undergoes one sequence of transformations. (13) A n actor undergoes a transformation when its state is changed from one to another over time. A non-actor does not undergo any transformations. Table 6-1: OBPM algorithm and the ontology-based integrity rules 6.4 WaterSystem Example For illustration purpose, this section will use the "Order processing" process in the WaterSystem example introduced in Chapter two to present how to use the algorithm to generate an OBPM model. Figure 6-4 shows the EPC model of the process. There are two external events generated from the process' environment. One is eOl (eOl = Payment made by customer) generated by the "Order taking" process, and the other is e02 (eOl = Assembled products ready) generated by the "Assembly" process. Taking their sequence of occurrence into consideration, and also considering the value of event e2 which is the state of warehouse dept. after checking the order in warehouse, we need to analyze the final model for the following three cases: eot / Pay™111 ) \ made / Order Processing ehouse ± Collect Payment . / Payment \ e \ Collected / Check order in W/H e2 \ ready / \ not ready / 1 KV Ship Products e3 / Order \ \ Shipped / e4 Rearrange Warehouse arehouse \ earranaed / e5 e6 / Order \ \ closed / les Debt Send Invoice * > / Invoice N \ sent / Close order e02 I /AssembledX Vodupt rdv/ I I . J Figure 6-4: EPC model of "Orderprocessing"process (1) Case A: eOl occurs first, e2 = order not ready, and then e02 occurs. 73 (2) Case B: eOl occurs first, e2 = order ready, and then e02 occurs. (3) Case C: e02 occurs before eOl. 4 6.4.1 Running the algorithm on case A Figure 6-5 presents the steps of running the algorithm on Case A. Step 1 and 2 identifies the triggering events: eOl and e02. eOl = Payment made e02 = Assembled products ready Steps 3 to 6 handle the state-changes of the affected things of eOl: A/R dept., Bank machine and Bank teller. Steps 7 to 10 handle the state-changes of the affected things of e02: Warehouse dept., Forklift and Elevator. Among these steps, 5, 6, 9 and 10 simply add the resources into resource_list because the affected things only changes states from stable to stable. Steps 4 and 8 deal with the situations that the affected things change states from stable to unstable. The most important steps are explained below. 6.4.1.1 Analyzing step 4: Affected_Thing(A/R, eOl) This step deals with the procedures needed for A/R dept. when it is affected by eOl (eOl = Payment made) . First (in step 41) it is noticed that the A/R dept. changes states from stable to unstable, which means it is an agent rather than a resource. Thus, the A/R dept. is added to the agent_list, which is empty at the moment. Then in step 42 the algorithm attempts to decompose the state-change of A/R dept. into activities and operations through invoking Decompose(A/R., eOl). 6.4.1.2 Analyzing step 42: Decompose(A/R, eOl) First, identify a sequence of events until the A/R dept. reaches a stable state. Only one event is found: 4 Note: The three cases in this example indicate three different workflows of the same process. 74 1. eOl = Payment made 2. e02 = Assembled products ready 2iAffertedJhjnjgj)fj!0^^^ 4. AffectedJThing(A/R, eOl) 41. Agent list: {A/R} (42. Decompose(A/R, eOl) 421. el = Payment collected 422. A/R activityjist: {<eOI, el>} 423. A/R first activity'soperationjist: {<e01, el>} 424. Affected thm^sj)f_eJ_:JW/H]__ Return 425. Affected_Thing(W/H, el) 4251. Agentjist: {A/R, W/H} 4252. Decomposer.W/H, el) 42521. e2 = Order not ready 42522. W/H activityjist: {<el, e2>} 42523. W/H first actvity'soperationjist: {<el, e2>} 42524. Affected things of e2: {} Return Return Return 5. Affected_Thing(Bank machine, eOl) 41. Resource_list: {Bank machine} Return 6. Affected_Thing(Bank teller, eOl) 51. Resourcejist: {Bank machine, Bank teller} Return ^Affer tedjhmjj^^ 8. Affected_Thing(W/H, e02) 81. Agentjist: {A/R, W/H} 82. Decompose(W/H, e02) 821. e3 = Order shipped 822. e4 = Warehouse rearranged 823. W/H activityjist: {<el, e2>, <e02, e4>} 824. W/H second activity's operationjist: {<e02, e3>} 825. Affected things of e3: {Sales, Mail} : 826. Affected_Thing(Sales, e3) 8261. Agentjist: {A/R, W/H, Sales} 8262. Decompose(Sales, e3) 82621. e5 = Invoice sent 82622. e6 = Order closed 82623. Sales activityjist: {<e3, e6>} 82624. Sales first activity's operationjist: {<e3, e5>} 82625. Affected things of e5: {Sales, Computer} 82626. Affected_Thing(Computer, e5} 826261. Resource list: {Bk mchn, Bk tlr, Cmpt.: Return 82627. Sales first activity's operationjist: {<e3, e5>, <e5, e6>} 82628. Affected things of e6: {} Return Return Return 827. AffectedJThingiMail, e3) 8271. Resourcejist: {Bank machine, Bank teller, Computer, Mail} Return 828. W/H second activity's operationjist: {<e02, e3>, <e3, e4>} 829. Affected things of e4: {} Return 9. Affected_Thing(Forklift, e02) 91. Resourcejist: {Bank machine, Bank teller, Computer, Mail, Forklift} Return 10. Affected_Thing(Elevator, e02) 101. Resourcejist: {Bank machine, Bank teller, Computer, Mail, Forklift, Elevator} Return Figure 6-5: Running the algorithm on case A 75 e l = Payment collected Next, an activity of <e01, el> is added to A/R's activitylist. This is the first activity of the A/R dept. in the list. A/R's activityjist: {<e01, el>} (Namely, Collect payment) Next, operations are identified for this first activity. Only one operation is found, and it is added to the operation_list of this activity: A/R's first activity's operationjist: {<e01, e l >} (Namely, Collect payment) Next, the affected things of event el are found: Warehouse dept. only. The algorithm will deal with the situation again that an agent is affected by an event. This is executed in step 425. 6.4.1.3 Analyzing step 425: Affected_Thing(Warehouse dept., el) When the Warehouse dept. is affected by el (e l = Payment col lected), the algorithm adds the Warehouse dept. into the agent_list as it changes states from stable to unstable. Then it decomposes the state-change of the Warehouse dept. into activities and operations. Similar to step 42, it first identifies the sequence of events, which has only one event e2 (e2 = Order not ready). Then it adds the first activity <el, e2> (Namely, Check order in Warehouse) into the Warehouse dept.'s activity list, adds the only operation <el, e2> (Namely, Check order in Warehouse) into the operation_list of this activity, and check if anything is affected by e2. Fortunately, nothing is affected and the subroutine returns. 6.4.1.4 Analyzing step 8: Affected_Thing(Warehouse dept., e02) Similar to step 4, step 8 also deals with the situation that the Warehouse dept. is affected by event e02. It first identifies two new events: e3 = Order shipped e4 = Warehouse rearranged The activity <e02, e4> (Namely, ship products and rearrange warehouse) is the second 76 activity of the Warehouse dept. It is identified in step 823 and added to the activityjist of the Warehouse dept. And, two operations are added to the second activity's operationjist. The first operation <e02, e3> (Namely, ship products) is added to the list in step 824, and the second operation <e3, e4> (Namely, rearrange warehouse) is added in step 828. Some resources (Computer and Mail) are added to the resource_list in step 82625 and 8271. Step 826 deals with the situation that the Sales dept. is affected by the event e3. 6.4.1.5 Analyzing step 826: Affected_Thing(Sales dept., e3) As the Sales dept. is a new agent, it is added to the agent_list. When decomposing the Sales dept.'s state-change, two new events are identified: e5 = Invoice sent e6 = Order closed An activity is found for the Sales dept. in step 82623, and two operations are added to the operation_list of this activity in steps 82624 and 82627: one is <e3, e5> (Namely, Send invoice) and <e5, e6> (Namely, Close order). 6.4.1.6 Final output of case A The final output of the algorithm is the OBPM model the user obtained. Case A has the following outputs: Triggering event: eOl = Payment made by customer e l = Payment collected e2 = Order not ready e3 = Order shipped e4 = Warehouse rearranged e5 = Invoice sent e6 = Order closed Agentjist: {A/R department, Warehouse department, Sales department} Resourcejist: { Bank machine, Bank teller, Computer, Mail, Forklift, Elevator} 77 A/R dept. activityjist: {<e01, el>} A/R dept. operationjist of first activity: {<e01, el>} Warehouse dept. activityjist: {<el, e2>, <e2, e4>} Warehouse dept. operationjist of first activity: {<el, e2>} Warehouse dept. operationjist of second activity: {<e02, e3>, <e3, e4>} Sales dept. activityjist: {<e3, e6>} Sales dept. operationjist of first activity: {<e3, e5>, <e5, e6>} The final model of case A is presented as Figure 6-6. Environment Sales dept. : Ordisr shipped lesburce: Resource uter :e sent Figure 6-6: Final model of case A: triggered by eOl & e02, and e2 = order not ready 6.4.2 Running the algorithm on case B In case B, eOl occurs first, e2 = order ready, and then e02 occurs. As e2 = order ready, the agent Warehouse dept. is at an unstable state and it will continue its state-change till it reaches a stable state. Thus, a sequence of events <el, e4> is an activity and it has three operations: <el, e2> (Namely, check order in warehouse), <e2, e3> (Namely, ship products) and <e3, e4> (Namely, rearrange warehouse). Therefore, when the Warehouse dept. is at 7 8 unstable states and keeps changing, the occurrence of e02 (Namely, Assembled products ready) will have no effect on it. The algorithm determines that the set of affected thing by e02 is empty, and returns. If e02 occurs when the Warehouse dept. finishes the activity of "ship product and rearrange warehouse" and stays in a stable state, it will check the affected thing by e02 and proceed. Environment eOl Payment made e02 = A s s e m b l e d products ready A / R dept. 4-Warehouse dept. Resource: 'iank nificlt. tejler I I * * — I Order rda Ship products L e g e n d : ^ Even t Ope ra t i on Sales dept. Figure 6-7: Final model of case B: triggered by eOl, and e2 = order ready The result of running the algorithm on case B is omitted. The final model of case B is presented in Figure 6-7. 6.4.3 Running the algorithm on case C In case C, e02 occurs before eOl, and e2 could be whichever values. Before eOl (eOl = Payment made by customer) and e02 (e02 = Assembled products ready) occur, the Warehouse dept. is in a stable state. Event e02 triggers the Warehouse dept. to change until it reaches a stable state. The algorithm would add the first activity <e02, e4> 79 to the Warehouse dept.'s activityjist, and find its operations <e02, e3> (Namely, Ship products) and <e3, e4> (Namely, Rearrange warehouse). It also identifies the activities and operations for the Sales dept. If eOl (eOl = Payment made by customer) occurs in the meantime and el (el = Payment collected) occurs when the Warehouse dept. does not finish its current activity, it will not affect the Warehouse dept. as it is in unstable states. If el occurs when the Warehouse dept. finishes its first activity and stays in a stable state, el will cause the agent to change again and a second activity is added, which could be <el, e2> if e2 = order not ready, or <el, e4> if e2 = order ready. The final model of case C is displayed in Figure 6-8. Environment Sales dept. e02 = Assembled products ready Figure 6-8: Final model of case C: e02 occurs before eOl 6.5 Evaluation of the OBPM algorithm The OBPM algorithm provides a set of necessary concepts and formal instructions on 80 how to build a process model. It is necessary to evaluate its usefulness in terms of its basic concepts and procedures. 6.5.1 Basic concepts The OBPM algorithm generates the following information in the final model: agent, resource, event, activity, operation, as well as business rule. It is noted that the concept of business rule is not explicitly expressed in the algorithm; however, an analyst could generate different outputs according to different situations of the process domain. This implicitly expresses the business rules in the process. For example, in the previous discussion of case A, B and C, the business rules are implied in the order of the event's occurrence. The basic concepts of OBPM algorithm are derived from BWWP ontological constructs. And this enables the algorithm to capture the real world knowledge of a business process as complete and clear as possible. On the other hand, as we discussed previously, most of the five PMLs have ontological problems in terms of constructs expressiveness. Therefore, it is necessary to use the algorithm with the PMLs together so that a theory-based process model could be obtained. 6.5.2 Basic procedures The OBPM algorithm sets up its modeling procedures according to the ontology-based integrity rules. The rules represent the basic truth and the general law of cause and effect of the real world. For example, one of the rules mentioned: "All things interact by changing the value of mutual properties." It is clear for a model builder that if two things do not have mutual property, they have no way to interact. While in most PMLs, the procedures on how to build a process model are not well defined. They are based on traditional process-modeling heuristics, and do not have formal rules to follow. An analyst could only discover the domain knowledge from particular facts 81 and examples, and move to a solution by trial and error. It is convinced that using PMLs which are guided by the OBPM algorithm is necessary to build a reasonable model for a real-world business process. 82 Chapter 7 C O N C L U S I O N 7.1 Conclusion The thesis developed a theory-based process modeling methodology. The methodology covers all the aspects (such as functional, behavioral, organizational and informational aspects) of process modeling languages. It includes the constructs and rules that are derived from BWWP ontological concepts, and the OBPM algorithm that suggests a procedure for constructing a process model in a given situation. Additionally, it presents integrity rules that show the way to check that a process model is semantically correct. The thesis starts by comparing five currently used process modeling languages including EPC, IDEFO, IDEF3, UML Activity Diagram, and EDPM Method. It finds the generic constructs needed for a PML by observing the difference between five PMLs as well as what they have in common. In order to gain a clear understanding of these modeling languages' expressiveness, each of them is used to model a whole set of five business processes of a manufacturing enterprise. The next step is to examine the process related ontological concepts (BWWP concepts) to define an ontology-based process model. This ontological model of a process is investigated by doing ontological analysis to a sample process. The process model includes four things, three of them are actors and one is a non-actor. The things interact with each other. The model also incorporates composite things. By looking at each thing's state curve, the relationships between PML constructs and BWWP concepts are clarified. A set of PML-BWWP construct mapping rules is finally generated, and leads to a set of ontology-based process-model integrity rules. These two 83 outcomes have the following benefits: (1) The PML-BWWP mapping rules are used as a guideline to evaluate a general process modeling language. The thesis specifically evaluates the five PMLs based on these mapping rules, and their ontological deficiencies are found accordingly. (2) Ontology-based integrity rules are used to set up an "ontology-based process-modeling" algorithm. 7.2 Contributions A significant contribution of the thesis is the PML-BWWP concept mapping rules. The mapping rules could be used in future research to evaluate other process-modeling languages, and could also guide the applications of PMLs in the business practices. In addition, the OBPM algorithm on how to establish an ontology-based process model can be used for automatically generating a process model. The strength of this conceptual modeling algorithm is that it is derived from the formal ontological foundation rather than from traditional process-modeling heuristics. 7.3 Limitations and future research One limitation of the OBPM algorithm is that it does not include the "Data" concept. As "Data" represents the stable state of a thing in ontology and the represented thing behind data is not of interest to most PMLs, we have not addressed it. A deeper meaning of data could provide new insights in future research. Even though the algorithm generates a resource_list in the model, it does not tell who utilized the resource in the list during which operation. The algorithm need to be refined to find the operation that the resource is used/modified, and the agent who uses/modifies the resource in future research. And, it also need to be refined to clearly present the logical connectors and business rules instead of implying them by a number of cases. Moreover, it 84 should be able to identify the input/output concrete objects in the future. By adding a standard set of symbols and giving them meanings, OBPM algorithm could be further developed into a process-modeling language in the future. Also, as the OBPM algorithm is new to the process-modeling field, and it was only tested in a limited number of examples. In future research, a CASE tool could be developed to automate the model generation procedures, so that the OBPM algorithm could be applied and tested in more complicated cases. Finally, the empirical studies could be conducted to examine the usefulness and the ease-of-use of the OBPM algorithm as well. 85 B I B L I O G R A P H Y Ambler, Scott W. (2000). How to dram UML Activity Diagrams, IBM DeveloperWorks, September 2000 Ambrose, Paul J. and Ramaprasad, Arkalgud. (1997). Developing Sustained Competitive Advantage: Business Process Reengineering versus Management of Information as a Resource, Association for Information Systems, 1997 America Conference, Indianapolis, Indiana, August 15-17, 1997 Bider, Ilia. (2000). IbisSoft Inc. Stockholm Sweden, Business Process Modeling -Concepts, Workshop on Practical Business Process Modeling (PBPM*00), Stockholm, 5-6 June 2000 Bunge, M.A. (1977). Ontology I: The Furniture of the World, Vol. 3 of Treatise on Basic Philosophy. D. Reidel Publishing Company, Dordrecht, Holland. Bunge, M.A. (1979). Ontology II: A World of Systems, Vol. 4 of Treatise on Basic Philosophy. D. Reidel Publishing Company, Dordrecht, Holland. Davenport, T.H. & Short, J.E. (1990). "The New Indusgtrial Engineering: Information Technology and Business Process Redesign", Sloan Management Review, pp. 11-27. Evermann, Jeorg and Wand, Yair. (2001a). Towards Ontologically Based Semantics for UML Constructs, Conceptual Modeling - ER 2001, 20th International Conference on Conceptual Modeling Proceedings, P354 - 367 Evermann, Jeorg and Wand, Yair. (2001b). An Ontological Examination of Object Interaction in Conceptual Modeling, Proceedings of the Eleventh Annual Workshop on Information Technologies & Systems, WITS '01, New Orleans, Louisiana, USA, P91-96 Gemino, A. (1999). Empirical Comparisons of Systems Analysis Modeling Techniques. Ph. D. Thesis, University of British Columbia, Canada. Green, P. (1997). Use of Information Systems Analysis and Design (IS AD) Grammars in Combination in Upper CASE Tools - An Ontological Evaluation. In Proceedings of the 2nd CAiSE/IFIP8.1 International Workshop on the Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'97). Barcelona, Spain, 1-12. 86 Green P. and Rosemann M. (2000) Integrated Process Modeling: An Ontological Evaluation, Information Systems, 25(2), 73-87. Grover, Varun and Kettinger, William J. (1995). Business Process Change: Reengineering, Concepts, Methods and Technologies, IDEA Group Publishing. Hanrahan, Robert P. (1995). The IDEF Process Modeling Methodology, CrossTalk Journal of Defense Software Engineering, U.S.Air Force's Software Technology Support Center, June 1995 Huckvale, Tim and Ould, Martyn (1995). Process Modeling - Who, What and How: Role Activity Diagramming. IDEA Group Publishing. Jablonski, Stefan and Bussler, Christoph (1996). Workflow Management: Modeling Concepts, Architecture and Implementation. International Thomson Publishing Company. Jung, Darrell. (1997). Object-oriented Modeling: From Analysis to logical Design, Master's thesis, Faculty of Commerce and Business Administration, University of British Columbia, August 1997 Knowledge Based Systems Inc., (2000) IDEF3 Process Flow and Object State Description Capture Method Overview, 2000 Mayer, Richard J., et al., (1992). IDEF Family of Methods for Concurrent Engineering and Business Re-engineering Applications, Knowledge-Based Systems, Inc., 1992. Mayer, Richard J., et al. (1995). Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report, September 1995. Martin, J. & Odell, J. (1992). "Object Oriented Analysis & Design". PTR Prentice Hall 1992, ISBN 0-13-630245-9. OMG Unified Modeling Language Specification Version 1.3. (1999). Paulson, Dan and Wand, Yair. (1992). An Automated Approach to Information Systems Decomposition, IEEE Transactions on Software Engineering, Vol. 18, No. 3, March 1992. Scheer, August-Wilhelm. (1989). Business Process Engineering: Reference Models for Industrial Enterprises, Springer-Verlag Berlin, Heidelberg 1989. 87 US Department of Commerce. (1993). Federal Information Processing Standard Publication 183 (FIPSPUB 183), Announcing the Standard for Integration Definition for Function Modeling (IDEFO), Dec 21, 1993. Wand, Y. (1989). A Proposal for a Formal Model of Objects. In W. Kim and F.Lchovsky, editors, Object-Oriented Concepts, Languages, Applications and Databases, pages 537-559. ACM Press. Addison-Wesley. Wand, Yair and Wang Richard Y. (1996): Anchoring data quality dimensions in ontological foundations. Communications of the ACM, vol. 39, no. 11, pp. 86-95. Wand, Y. and Weber, R. (1989). An ontological evaluation of systems analysis and design methods. Information System Concepts: An In-depth Analysis, E.D. Falkenberg, P. Lindgreen, ediors, pp. 79-107, North-Holland. Wand, Y. and Weber, R. (1990a). An ontological model of an information system, IEEE Transactions on Software Engineering, 16(11), 1281-1291. Wand, Y. and Weber, R. (1990b). Mario Bunge's Ontology as a Formal Foundation for Information Systems Concepts. Studies on Mario Bunge's Treatise. Rodopi B.V., Amsterdam-Atlanta, GA, (pi 23-149) Wand, Y. and Weber, R. (1993) On the ontological expressiveness of information systems analysis and design grammars, Journal of Information Systems, 3(4), 217-237. Wand, Yair and Weber, R. (1995). On the deep structure of information systems, Info Systems Journal 1995. 5, 203 - 223. Wand, Yair and Woo, Carson. (2000). Object-Oriented Modeling: From Enterprise Model to Logical Design, Proceedings WIT's 2000 Zhao, Hao. (1995). Object-oriented Enterprise Modeling, Master's thesis, Faculty of Commerce and Business Administration, University of British Columbia, July 1995 88 Appendix I W A T E R S Y S T E M E X A M P L E 1. Process Description The five business processes are presented here. The concepts used to depict the processes in the tables are based on EPC constructs. • Process 1: Order taking The process starts when a customer has placed an order. The Sales department will check if the ordered products are available. The department's clerk will use the information system in computer to check products availability. If the ordered products are not available in warehouse, the clerk will make an assembly application so that the ordered products could be assembled when the required components are available. Starting event Triggered operation Ending event Resource used Agent Order placed Check product availability Product available XOR product unavailable. Computer Product unavailable Apply for assembly Assembly application made - Sales Product available OR Assembly application made Approve order Order approved Computer dept. Order approved Arrange payment Payment made Telephone, fax Table I -I: Definition of "Order taking"process If the products are available in warehouse, or the unavailable products' assembly application is made, the order will be approved by the department manager, and the customer file will be updated. Then, the department will call or fax the customer according to the purchase order information and arrange them to make payment. • Process 2: Order processing The triggering events of this process are "customer payment made" generated from 89 "Order taking" process and "assembledproducts ready" coming from "Assembly" process. When the first triggering event occurs, the Account Receivable section of Accounting department will collect customer's payment into the company's bank account. The section clerk might use bank machines or ask bank teller for help. Starting event Triggered operation Ending event Resource used Agent Payment made Collect payment Payment collected Bank machine, bank teller A/R Payment collected Check order in warehouse Order ready XOR order not ready -Warehouse Order not ready - - - Warehouse Order ready OR assembled product ready Ship products Order shipped Forklift, elevator Warehouse Order shipped Rearrange warehouse Warehouse rearranged Forklift Warehouse Warehouse rearranged - - - Warehouse Order shipped Send invoice Invoice sent Mail Sales dept Invoice sent Close order Order closed Computer Sales dept Order closed - - - Sales dept. Table I -2: Definition of "Order processing " process After payment is collected, the Warehouse department will check if the order is ready for shipping. If not ready, she might wait for notification from the manufacturing department. If the order is ready in warehouse OR the assembled products are ready for shipment (which is the 2nd triggering event), the Warehouse department will ship the order with help of a forklift and an elevator. When order is shipped, two things need to be done: Sales department should send invoice to the customer by mail and close the order, and Warehouse department should rearrange the warehouse space for new products and components to enter in (both assembled products and purchased components are stored in the same warehouse). • Process 3: Assembly 90 The process is triggered by one or both of the two events: (1) Assembly application was made AND customer payment is made in the process of "Order taking"; OR (2) Warehouse department found an assembly application in the waitlist when new components arrived and added to warehouse in the process of "Arrival". Starting event Triggered operation Ending event Resource used Agent Assembly application made OR Assembly application waiting Check components availability Enough stock XOR short stock Computer, product specification Enough stock Assemble product Assembly done Product spec, assembly machines Manuf. dept. Short stock Put assembly application to waitlist Assembly application on waitlist -Short stock Make purchase application Purchase needed -Table I -3: Definition of "Assembly " process The Manufacturing department will then check the components availability based on the ordered products' specification and the information system. If the required components are out of stock, two operations need to be done: (1) Manufacturing department will put the assembly application to the waitlist; AND (2) Manufacturing department will make purchase application. The latter case will trigger the process of "purchasing" which will be described later. When the components are all available, the Manufacturing department will start assembling the ordered products, and add them to the Warehouse when assembly is done. Till then, the assembled product is ready for shipment. • Process 4: Purchasing This process is triggered by the event of "purchase needed' sent from the process of "Assembly". The Purchasing department will prepare a purchase plan, and then will place order with vendors. When orders are placed, the Account Payable section of Accounting 91 department will make payment to the vendors and the process is completed. Starting event Triggered operation Ending event Resource used Agent Purchase needed Make purchase plan Plan made - Purchasing dept Plan made Place order with vendors Order placed with vendors Telephone, fax Order placed with vendors Pay vendors Paid vendors Bank account A/P Paid vendors - - - A/P Table I-4: Definition of "Purchasing"process • Process 5: Arrival The triggering event "components arrived" comes from the environment. When a truckload of purchased components arrives, the Warehouse department will add them to the warehouse with help of forklift and elevator. And then, the Warehouse department will check if there are any waiting assembly applications. If there is no waiting application, the process is completed. Otherwise, it will trigger the "Assembly" process to manufacture the ordered products with the new arrived components. Starting event Triggered operation Ending event Resource used Agent Components arrived Add to warehouse In warehouse Forklift, elevator Warehouse In warehouse Check waiting assembly applications Assembly application waiting XOR no assembly application waiting Computer Warehouse No assembly application waiting - -Table I -5: Definition of "Arrival"process 2. Model the processes with five PMLs For simplicity, IDEF3 Enhanced Transition Schematic model is omitted. 92 Figure I-l: EPC Model ofWaterSytem Example 93 Order placed C o m p o n e n t s a r r i v e d PO C h e e k p r o d u c t a v a i l a b i l i t y P r o d u f t f i lc~f ^ Sales dept. C o m p u t P O " I " JL . P r o d u c t not a v a i l a b l e P r o d u c t a v a i l a b e A p p l y for a s s e m b l y A s m b l y i made Saletdept. A p p r o v e o r d e r | O r d e r ^ a p p r o v e d S a l e s dept. C o m p i t c r C u s t o m e r f i le T " S a l e s dept A r r a n g e p a y m e n t T e l , faid i^ Order taking P a y m e n t made ap_p_ A d d c o m p . to w a r e h o u s e C o m p o n e n t f i l e W a r e h o u s e F o r k l i f t , e lev. O r d e r f i l e -w a r c n o u s c Check w a i t i n g a s m b l y a p p r Warehouse N o a p p l . w a i t i n g A p p l . w a i t i n g r C o m p u t e r Arrival A s m b l y . appl. P a y m e n t made A s m b l y . made | i | a p p l . w a i t i n g • C o m p o n e n t file -re-p a y m e n t made B a n k rules Customer file! *" S h o r t s tock |Check c o m p o n c n t s | a v a i l a b i l i t y T C o m p u t e r M a n u f . dept. 1 Add a s b l y . a p p l to w a i t l i s t A p p l . on| w a i t l i s t | E n o u g h s t o c k M a n u f . dept. P u r c h a s e p o l i c i e s 1 M a k e p u r c h a s e a p p l P u r c h a s e ar|p^. A s s e m b l e g u i d e P u n nee A s s e m b l e p r o d u c t M a n u f . dept. A s s e m b l e d p r o d u c t | l A s s c m b l y Adone M a n u f . dept A d d to w/h Assembly M a n u f . dept. A s s e m b l e d j ^ p r o d u c t s rc^dy I I y C o l l e c t p a y m e n t A / P B a n l t m a c ^ Order processing) h . / t e l l e r P a y m e n t c o l l e c t e d C h e c k order i n w/h O r d e r not r e a d y i W a r e h o u s e A s s e m b l e d odpet ready proi I Orde S h i p p r o d u c t s T Warehouse" F o r k l i f t I I P r o d u c t file I P u r c h a s e n e e d e d B a n k rules c lev . I n v o i c e -O r d e r s h i p p e d S e n d i n v o i c e Sales dept. I n v o i c e sent ^ a i l C l o s e order R e a r r a n g e W / H W a r e h o u s e Ploscfd V c i Sa les dept 1. C o m p u t e r | W a r e h o u s e rearrangei j M a k e purchase p l a n ^ P u r c h a s e dept. dors f i l e • P l a c e o r d e r w i t h v e n d o r s P u r c h a s e p l a n made O r d e r p l a c e d with v e n d o r s P u r c h a s e dept. T e l , fax V e n d o r s f i l e Pay v e n d o r s P u r c h a i c p lan P a i d j Vendjirs^ Purchasing A / P B a n k acc . Figure 1-2: IDEFO Model of WaterSytem Example 94 Figure 1-3: IDEF3 Process Schematic Model ofWaterSytem Example 95 Figure 1-4: IDEF3 Transition Schematic Model ofWaterSytem Example 96 86 sjduivxg warfsJdfVAi f° PP°Fi MdQ3 :9'I ^unSij Appendix II O N T O L O G I C A L A N A L Y S I S O F P M L - L O G I C A L C O N N E C T O R S The ontological analysis to PML-logical connectors is part of the analysis work in Chapter four. Altogether three situations are investigated here: 1. One event -*• logical connector two and more operations One PML-event of thing A triggers two PML-operations, which could be executed by A, B or C. There are following two cases: (1) A — A, B (one thing changes the state of another thing and itself) (2) A — B,C (one thing changes the state of two other things) (3) A — A, A (one thing changes the state of itself) (4) A — B,B (one thing changes the state of another thing) 1.1 Logical connector "AND" For logical connector "AND", case (3) and (4) are not possible because the event of a thing is not able to cause two simultaneous operations of either the thing itself or a different thing at the same time. For case (1), when thing A ends its state-change at PML-event e, both thing A and thing B start their state-change immediately at the same time. For case (2), when thing A ends its state-change at PML-event e, both thing B and thing C start their state-change immediately at the same time. 99 Figure II-1: Ontological analysis to "one event —* AND —> two operations" 1.2 Logical connector "OR" For logical connector "OR", case (3) and (4) are not possible to define, because the event of a thing is not able to cause either of the two operations of the same thing. For case (1), when thing A ends its state change at PML-event e, at least one of thing A and thing B starts its state-change immediately. For case (2), when thing A ends its state-change at PML-event e, at least one of thing B and thing C starts its state-change immediately. 100 I) A —>A, B al a2 2) A —> B, C al ig A A igB A W c n : a2 a3 Thing C A A j f A B A i /\/vVJ c 1 A I ^ >t Figure U-2: Ontological analysis to "one event —> OR —* two operations" 1.3 Logical connector "XOR" For logical connector "XOR", cases (1), (2), (3), and (4) are all possible. For case (1), when thing A ends its state-change at PML-event e, either of thing A or thing B starts its state-change immediately. For case (2), when thing A ends its state-change at PML-event e, either of thing B or thing C starts its state-change immediately. For case (3), when thing A ends its state-change at PML-event e, A starts its another state-change immediately, either in one way or in another. For case (4), when thing A ends its state-change at PML-event e, B starts its state-change immediately, either in one way or in another. 101 102 2. Two and more events -*• logical connector -*• one operation Two or more PML-events of thing A triggers one PML-operations, which could be executed by A, B or C. There are following two cases: (5) A, B A (two actors change the state of one of them) (6) A, B —• C (two actors change the state of a third thing) 2.1 Logical connector "AND" For case (5) A "AND" B -> A, only when both A and B complete their state-changes will A start the next state-change immediately. For case (6) A "AND" B -> C, only when both A and B complete their state-changes will C start its state-change immediately. Figure II-4: Ontological analysis to "two events —> AND —> one operation " 2.2 Logical connector "OR" 103 For case (5) A "OR" B ->A, whenever at least one of thing A and thing B has completed its state-change, A will start its next state-change immediately. For case (6) A "OR" B -> C, whenever at least one of thing A and thing B has completed its state-change, thing C will start its state-change immediately. A's first change is broken and 2nd starts from the current unstable state. 2)A,B—> C ThingA A ) B ) al a2 ( 3 3 ( 3 ) Thing B a3 Figure II-5: Ontological analysis to "two events —* OR —» one operation' 2.3 Logical connector XOR Logical connector "XOR" in this case is just the variance of "OR". 3. One operation -* logical connector -* two and more events 104 This is the situation that one operation could lead to two different stable states. Therefore, the logical connector "AND" and "OR" are not possible, and there are four cases for the logical connector "XOR": (7) A A, B (one thing changes the state of either another thing or itself) (8) A -* B, C (one thing changes the state of only one of the two other things) (9) A -* A, A (one thing changes the state of itself either like this or like that) (10) A -»• B, B (one thing changes the state of another thing either like this or like that) 3.1 Logical connector "XOR": For case (7) A -> A "XOR" B, the operation of thing A will lead to two different states: high and low. If A reaches high, A will continue its state-change from the state point of high. On the other hand, if A reaches low, B will start its state-change right after. For case (8) A -> B "XOR" C, if A reaches high, B will start its state-change immediately after. If A reaches low, C will start its state-change right after. For case (9) A -> A "XOR" A, if A reaches high, A will continue its state-change starting from state point of high. If A reaches low, A will continue its state-change starting from state point of low. For case (10) A -> B "XOR" B, if A reaches high, B will start its state-change in one way, and if A reaches low, B will start its state-change in another way. 105 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0090921/manifest

Comment

Related Items