Technische Universitt Hamburg-Harburg Arbeitsbereich Softwaresysteme

A Comparison of Event-driven Process Chains and UML Activity Diagram for Denoting Business Processes
Project Work

submitted by Ferdian (15986) Information and Communication Systems Masters Program ferdian@tu-harburg.de

Supervisors: Prof. Dr. J.W. Schmidt j.w.schmidt@tu-harburg.de Dipl-Inform. Axel Wienberg ax.wienberg@tu-harburg.de

April 1st, 2001

Contents
Figures 1. Introduction 2. Event-driven Process Chains (EPC) 2.1. The Architecture of Integrated Information System (ARIS) 2.1.1. Descriptive Views 2.1.2. Descriptive Levels 2.1.3. Description Methods 2.1.3.1. The Function View: Function Tree 2.1.3.2. The Organization View: Organizational Structure 2.1.3.3. The Data View: Entity-Relationship Model 2.1.3.4. The Control View: EPC 2.2. EPC Notation 2.3. Formal Description of EPC 3. UML Activity Diagram 3.1. The Unified Modeling Language (UML) 3.1.1. Architectural Views 3.1.2. UML Diagrams 3.1.2.1. Structural Diagrams 3.1.2.2. Behavioral Diagrams 3.2. Activity Diagram Notation 3.3. Usage of Activity Diagrams 4. Comparison, Translation, and Integration Approach between EPC and UML Activity Diagram 4.1. Comparison between EPC and UML Activity Diagram 4.1.1. Context 4.1.2. Exactness/Ambiguity 4.1.3. Notation/Terminology 4.2. Translation between EPC and UML Activity Diagram 4.3. The Integration Approach: The Object-EPC (oEPC) 4.3.1. Motivation for Integration 4.3.2. Modeling Business Objects 4.3.3. Modeling Business Processes Conclusion Bibliography iii 4 6 6 6 8 9 10 10 10 11 11 15 18 18 18 19 20 21 23 27

28 28 28 29 31 33 35 35 36 37 41 42

ii

Figures
2.1. Business process and ARIS views 2.2. ARIS views of the process model 2.3. ARIS descriptive levels 2.4. ARIS description methods in the requirements definition level 2.5. Elements used in EPC diagram 2.6. Use of process paths to show the connection from EPC1 to EPC2 2.7. Branch and merge in EPC 2.8. Fork and join in EPC 2.9. Inclusive OR connectors in EPC 2.10. Forbidden connections in EPC 2.11. Example of an EPC diagram showing an excerpt from procurement logistics 3.1. Modeling a systems architecture 3.2. Diagrams of the UML and their connections 3.3. Elements of activity diagram 3.4. Branch and merge in activity diagrams 3.5. Fork and join in activity diagrams 3.6. Iteration and dynamic concurrency 3.7. Example of an activity diagram showing an excerpt from procurement logistics 4.1. Two events arriving at one connector 4.2. Example of notational correspondences in EPC and UML Activity Diagram 4.3. Summary of comparison between EPC and UML Activity Diagram 4.4. The branch/fork solution for the elementary or-connector 4.5. Model of a business object with events 4.6. Basic model of an event-based message 4.7. Service-control relationship as encapsulated control flow 4.8. Example for the oEPC structure of the procurement logistics 4.9. Class diagram for the procurement logistics example 7 8 9 11 11 12 13 13 14 14 15 19 22 23 24 25 25 26 30 31 33 34 37 38 38 39 39

iii

Chapter 1 Introduction
In the world where business is much more competitive and the customer power is gaining its determining force, the companies has no choice but to be more responsive to changes in the market. These changing market dynamics are compelling many enterprises to rethink both their organizational structure and the use of technology [CKL98]. In the past, economies of scale that is, the reduction of costs by increasing output produced benefits by offering standardized products to stable and large consumer markets. The information system was just used to automate some certain business functions. By contrast, the companies today must be able to produce better, faster, and cheaper. In order to survive in a very competitive market, the enterprises must focus on creating value for customers and adopt business-process orientation to reorganize their business processes into adaptable corporate structures. The essential prerequisite for optimizing business processes is an integrated information system. Thus the companies must integrate information technology to reengineer the whole processes to improve their effectiveness. There have been many approaches to model the structure of an enterprise in which business processes are to be reorganized [KT98]. One of the frameworks is the Architecture of Integrated Information System (ARIS). In research as well as in practice, the ARIS is accepted as a standard framework for business process engineering. The method of Event-driven Process Chain (EPC) [KNS91] has been developed within the framework of ARIS and is used by many companies for modeling, analyzing, and redesigning business processes. The resulting EPC models are used as a starting point for the development of information systems. On the other hand, the development of information technology has driven the objectoriented paradigm to be used in modeling, analyzing and designing the enterprise information system. The Unified Modeling Language (UML) is a common standard for object-oriented modeling and is derived from a shared set of commonly accepted concepts which have successfully been proven in the modeling of software systems [NFZ98]. However, the object-oriented methods were used to cover the implementation aspects, not the business processes. The developers of UML realized the need to extend UMLs capability to model business processes, therefore diagrams like use cases and activity diagrams are incorporated into the UML. The need of an integrated view of business processes as well as information system as a whole makes the business-oriented view of EPC and IT-oriented view of UML converge. It is therefore required that both process- and object-oriented modeling of an enterprise be integrated. With this approach, all the aspects of a companys business processes and information systems should be able to be covered in a unified method.

Chapter 2 discusses briefly the ARIS framework with its descriptive views, levels and the methods used. Within this framework the EPC is used to model the business processes. The notation of EPC symbols is explained together with each symbols terminology. Since EPC is a de facto standard but not formally developed, an attempt to give formal description to EPC will be described in the last part of this chapter. The reader who is not interested in this formal description can skip this part. Chapter 3 discusses the architectural views of UML and explains briefly the diagrams used in UML to describe static and dynamic aspects of a system. Since a process is considered as dynamic behavior of a system, the activity diagram based on state machine is used to model processes as well as operations. The notations used in activity diagrams is described and also when to use them. Chapter 4 compares the EPC and activity diagrams to determine the correspondences and differences. Based on the identified correspondences, an informal translation procedure between them is described. Because of the complementary differences between them, the last part of the chapter argues for an integrated approach, as exemplified by a semi-formal proposal by Scheer et al. [SNZ97] called the object-EPC. Finally conclusion summarizes the results of this work.

Chapter 2 Event-driven Process Chains (EPC)

Event-driven Process Chains (EPC) is a method developed by Scheer, Keller and Nttgens within the framework of Architecture of Integrated Information System (ARIS) to model business processes [KNS91]. It is widely used in commercial projects from the field of management information systems. Before we go through the EPC first we take a brief look at the ARIS concept.

2.1. The Architecture of Integrated Information System (ARIS)

The ARIS concept involves dividing complex business process into separate views and integrating these views to form a complete view of the whole business process. A starting point to form these views is to understand and model a business process. The process contains operational activities connected in chronological sequence as well as other resources such as the human resources/organizations, information resources and the data that contain the information itself. This high complexity of interdependencies among the components in a business process is the driving force for breaking down the problem into different views. This dismantling procedure is based on the principle that components with high interdependency are grouped in one view and components with low interdependency are separated into different views. The result is that there are three views focusing on their high dependency inside the view, and the relationships between these views are restored in an additional view, thus forming four descriptive views in the EPC. A further partitioning inside the views is attained via the descriptive levels. These descriptive levels are not ordered according to a procedural model like the waterfall model for the development process; instead they are defined based on their proximity to information technology. The descriptive levels cover areas starting from business tasks to the technical aspects of system implementation. They consist of requirement definition, design specification, and implementation description. Each description level within each view is supported by a description method. 2.1.1. Descriptive Views As already mentioned above, the concept of ARIS lies on reducing complexity into different views. Figure 2.1 illustrates an excerpt from a business process, which serves to illustrate the concept of views. The components taking part and their interrelationships to be described in a computer-supported business process include processes, activities/functions, events, statuses, users, organizational units, and information technology resources. A simultaneous look at all the effects on all components of the process when designing an information system would severely complicate the model and thus prevent direct handling of individual aspects.

Capacities

...

Data view

Customer

Article Order tracking

Customer order received

Order confirmation

Order confirmation prepared Production planning

Function view

Department

User

...

...

Organization view

Resource view

Figure 2.1. Business process and ARIS views (from [Sch94]) In order to reduce this complexity, the model is divided into individual views that represent discrete design aspects and can be handled independently, which simplifies the task. The criteria for separating into individual views are based on the fact that relationships between components in the same view are relatively strong and relationships between components of different views are relatively weak. In ARIS this organization results in these views: Data view. The data view contains events and statuses. Events such as customer order received, completion notice received, or invoice written are information objects that are represented by data. Statuses such as customer status and article status are also represented by data. Function view. The function view contains the description of the activities to be performed, the enumeration of the individual subfunctions that belong to the overall relationship, and relationships that exist between the functions. Organization view. The structure and the relationships between users and organization units constitute the organization view. Users are assigned to organization units, which are formed according to criteria such as the same function or the same work object. Resource view. Information technology components constitute the fourth descriptive object, that is, the resource view. However this view is significant for business considerations only insofar as it results in general conditions for describing other components that are more strongly geared toward business. The relationships between the views as expressed by the arrows in the process model in figure 2.2 are restored by introducing a control view. The control view is an essential ARIS component that distinguishes it from other architectures such as Computer Integrated Manufacturing Open System Architecture (CIM-OSA), Semantic Object Model (SOM), or Object-Oriented Information Engineering (OOIE) [KT98]. This process results in the four ARIS views as shown in Figure 2.2.

ARIS

Organization

Data

Control

Function

Figure 2.2. ARIS views of the process model (from [Sch94]) 2.1.2. Descriptive Levels In addition to the descriptive views described above, a further partition into descriptive levels takes place within the ARIS concept. The transformation of business problem into an integrated information system solution is achieved in the ARIS approach through five phases: In the first phase the operational business problem through process chains is described and analyzed. The process chains are based on a first analysis and contain roughly all description views of ARIS. The result is the representation of relationships between organization units, data, and functions in order to form the base for an initial solution. The description of business processes is oriented closely to the user objectives. This affects on using semi-formal description method to represent the description of the business problem. In the second phase the individual views are modeled by requirements definition. The requirements definition has to be supported in a formalized language so that it can be used as a starting point for a translation into information technology without considering the aspects of implementation. The third phase involves design specification. In this phase the concepts of the requirements definition are transferred to the categories of Electronic-Data-Processing (EDP) and adapted to the request of the implementation tools. This process is not a concrete tool and is independent of technical aspects. The transformation between requirements definition and design specification has to be arranged so that modifications in the design specification do not affect the requirements definition. In the fourth phase the implementation description transfers the design specification to concrete hardware and software components. In this phase the physical link to the information technology is established. The fifth phase is the information technology realization. It contains the functions that support the operation and maintenance of the implemented system.

The descriptive levels are characterized by different update cycles. The requirements definition level is relatively longer and constant compared to other levels. It is particularly significant because it possesses the longest lifecycle and through their close affinity to the description of the business problem they also document the heaviest use of the information system. On the other hand the implementation description level is subject to ongoing revisions because of the fast innovation cycle of the information technology such as the development of new database systems, networks, hardware, etc.
Requirements definition Design Specification

Organization View

Operational business problem

Implementation Description

Requirements definition (semantic models)

Requirement Definition Design Specification Implementation Description

Requirement Definition Design Specification Implementation Description

Requirement Definition Design Specification Implementation Description

Design specification

Implementation description

Data View

Control View

Function View

Information technology

Figure 2.3. ARIS descriptive levels (from [Sch94]) The phases 2,3 and 4 are the starting point for the arrangement of the model into individual descriptive levels. This additional partitioning enables to take different perspectives in each view and to adjust the modeling parallel to the process in detail. Figure 2.3 shows different views and the partitioning in descriptive levels. 2.1.3. Description Methods The ARIS architectures descriptive views and levels are fixed. What is necessary then is to select and portray suitable description methods for each component. The criteria for selecting the methods are: Simplicity of the means of portrayal Suitability for the subject contents that are specifically to be expressed The ability to use consistent methods for all applications to be portrayed The existing or anticipated degree of familiarity with the methods and The degree of independence of the methods from technical developments in information and communication technology A more detailed description about this is available in [Sch94]. In this paper only methods in the requirement definitions are introduced, to show the position of EPC in the ARIS framework and the relationship between EPC as the most important method to portray business processes and other description methods used in the ARIS concept. 9

2.1.3.1. The Function View: Function Tree In the function view, there is a function for each process, which describes what should be done. A function can be complex, therefore it can be broken down into subfunctions. Breaking down functions serves to reduce their complexity. This process is concretized by the description methods of hierarchy diagrams or function trees. Hierarchy diagrams are self-explanatory, as shown in the following diagram. Functions are represented by round-cornered boxes and can be divided across several hierarchy levels, as illustrated by the subfunctions of order processing and reservation. The division process ends when functions are reached that are processed in one-job cycle, i.e., when it no longer makes sense from a business standpoint to divide them. These functions are called elementary functions. There are no definitive criteria for determining the functional structure, although some possible breakdown criteria include the division of subfunctions according to their approximate temporal sequence, the fact that they process the same information objects or that they do so using the same operations. 2.1.3.2. The Organization View: Organizational structure In order for human beings to be able to handle complex social structures such as enterprises, these structures must be broken down into manageable units. The rules required for this process are referred to as organization, and the resulting manageable units are called organizational units. If the structuring process relates to the company as a static system, the set of rules designed for this purpose is referred to as structural organization. The principal task of the organizational structure is coordinating as inexpensively as possible the communication needs that arise from breaking down a complex unit. Generally there is no optimal organizational structure, depending on the specificity of task and change of problems of the task. Normally the type of organizational structure is hierarchical, but if the rate of change is high the self-organizing network is more suitable. 2.1.3.3. The Data View: Entity-Relationship Model Whereas the function or organization view requires one concept, namely the function or organization units, many concepts are used within the data view, such as entity types, relationship types, attributes, domains, etc. The description of the requirement definition of the data view is therefore highly demanding, since it plays an important role in information system development. The easier it is to use higher programming languages to create supplemental functions in existing programming systems, the more important it becomes to provide these functions with the proper data structures. To provide the data view with a description method, Chens entity-relationship (ER) model was adopted into the ARIS framework [Sch94], since it was the most widespread designing method in the area of data modeling. The ER model used in ARIS framework is the extended one [Sch94] that introduces new design rules for supporting data structuring such as classification, generalization, aggregation, and grouping. 10

2.1.3.4. The Control View: EPC The control view links functions, organization and data. It unites the design results, which were initially developed separately for reasons of simplification. The functions, events, information resources, and organization units are connected into a common context by the process flow. The resulting model is the complete EPC. So the EPC serves as a description method in the control view to show the flow of process.

Figure 2.4. ARIS description methods in the requirements definition level (from [LA98a])

2.2. EPC Notation

The strength of EPC lies on its easy-to-understand notation that is capable of portraying business information system while at the same time incorporating other important features such as functions, data, organizational structure and information resources as already described before. This makes EPC a widely acceptable standard to denote business processes.

Event

Function

Organization Unit

Information/ Material

Process Path

XOR

OR

AND

Control Flow

Logical Connectors

Information Flow

Organization Unit Assignment

Figure 2.5. Elements used in EPC diagram (from [KT98]) 11

In the following the elements used in EPC diagram will be described: Event. Events are passive elements in EPC. They describe under what circumstances a function or a process works or which state a function or a process results. Examples of events are requirement captured, material on stock, etc. In the EPC graph an event is represented as hexagon. Function. Functions are active elements in EPC. They model the tasks or activities within the company. Functions describe transformations from an initial state to a resulting state. In case different resulting states can occur, the selection of the respective resulting state can be modeled explicitly as a decision function using logical connectors. Functions can be refined into another EPC. In this case it is called hierarchical function. Examples of functions are capture requirement, check material on stock, etc. In the EPC graph a function is represented as rounded rectangle. Organization unit. Organization units determine which person or organization within the structure of an enterprise is responsible for a specific function. Examples are sales department, sales manager, procurement manager, etc. It is represented as an ellipse with a vertical line. Information, material, or resource object. In the EPC the information, material, or resource objects portray objects in the real world, for example business objects, entities, etc., which can be input data serving as the basis for a function, or output data produced by a function. Examples are material, order, etc. In the EPC graph such an object is represented as rectangle. Process path. Process paths serve as navigation aid in the EPC. They show the connection from or to other processes. Figure 2.6 illustrates the use of process paths. There are two EPCs process 1 and process 2. We can show the continuation from process 1 to process 2 with a process path at the end of process 1 pointing to process 2 and in the beginning of process 2 referring to process 1. A process path is represented in EPC as a function and event symbol (function symbol in front of event symbol).
[previous functions and events in EPC1] event N event 1 Process 2 [next functions and events in EPC2] Process 1

Figure 2.6. Use of process paths to show the connection from EPC1 to EPC2 Control flow. A control flow connects events with functions, process paths, or logical connectors creating chronological sequence and logical interdependencies between them. A control flow is represented as a dashed arrow. Logical connector. In the EPC the logical relationships between elements in the control flow, that is, events and functions, are described by logical connectors. With the help of logical connectors it is possible to split the control flow from one flow to

12

two or more flows and to synchronize the control flow from two or more flows to one flow. There are three kinds of logical relationships defined in EPC: Branch/Merge. Branch and merge correspond to making decision of which path to choose among several control flows. A branch may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, a branch activates exactly only one of the outgoing control flows and deactivates the others. The counterpart of a branch is a merge. A merge may have two or more incoming control flows and one outgoing control flow. A merge synchronizes an activated and the deactivated alternatives. The control will then be passed to the next element after the merge. A branch in the EPC is represented by an opening XOR, whereas a merge is represented as a closing XOR connectors.
F1 E1 E2

XOR XOR

E1

E2

F1

If function F1 completes, either events E1 or E2 occur

If either events E1 or E2 occur, function F1 starts

Figure 2.7. Branch and merge in EPC Fork/Join. Fork and join correspond to activating all paths in the control flow concurrently. A fork may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, a fork activates all of the outgoing control flows in parallel. A join may have two or more incoming control flows and one outgoing control flow. A join synchronizes all activated incoming control flows. In the EPC diagram how the concurrency achieved is not a matter. In reality the concurrency can be achieved by true parallelism or by virtual concurrency achieved by interleaving. A fork in the EPC is represented by an opening AND, whereas a join is represented as a closing AND connectors.
F1 E1 E2

AND AND

E1

E2

F1

If function F1 completes, both events E1 and E2 occur

If both events E1 and E2 occur, function F1 starts

Figure 2.8. Fork and join in EPC OR. An OR relationship corresponds to activating one or more paths among control flows. An opening OR connector may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, an opening OR connector activates one or more control flows and deactivates the rest of them. The counterpart of this is the closing OR connector. When at least

13

one of the incoming control flows is activated, the closing OR connector will pass the control to the next element after it.
F1 E1 E2

OR OR

E1

E2

F1

If function F1 completes, events E1 or E2 or both occur

If events E1 or E2 or both occur, function F1 starts

Figure 2.9. Inclusive OR connectors in EPC Information flow. Information flows show the connection between functions and input or output data, upon which the function reads, changes or writes. Organization unit assignment. Organization unit assignments show the connection between an organization unit and the function it is responsible for.

After knowing the elements in the EPC, the next step is how to use these elements to model a business process using EPC. The following are some hints and constraints in connecting these elements to form an EPC diagram (a formal description of syntactical correctness of an EPC diagram will be described later): An event can only be followed by a function. A function has always a following event. In a single EPC graph without process paths, the graph must have at least one start event and one end event. In other words, a graph must be started and ended with events, not with functions. If the graphs have process paths that link them, in the source graph the process path should be put at the end of the graph after the end event, and in the target graph the process path should be put at the beginning of the graph before the start event. A combination of functions and events can be achieved using logical connectors. Logical connectors can be placed between functions on the one hand and events on the other hand, but the alternation of functions and events must always be maintained. An event is a passive element. This means that it cannot be used to make decisions, but it can be used to trigger parallel activities. Therefore an event can be followed only by an AND connector, not an OR or XOR connectors.
E1 E1

OR

XOR

F1

F2

F1

F2

Figure 2.10. Forbidden connections in EPC

14

A function is an active element. This means that it can be used to make decisions and to trigger parallel activities. Therefore any of the logical connectors can follow a function. Logical connectors should match, meaning that an opening XOR serving as a branch should be closed by another XOR connector. The same rule applies to fork/join using AND connector and OR connector. All elements must be connected to the control flow, because an isolated element would have no meaning or contribution to the whole process.
Event Requirement occured Function Capture requirement Employee Requirement captured Organization unit assignment Check material on stock Control flow XOR Material on stock Procurement Get material from stock Material Material provided Material ordered Order material Order Material not on stock Procurement Procurement Organization unit Information flow Sales

Material

Information / resource

Material

Figure 2.11. Example of an EPC diagram showing an excerpt from procurement logistics

2.3. Formal Description of EPC

In the following the declarative description of the EPC syntax will be given. The EPC model can be described as a graph-based model consisting of nodes and edges. The used elements, that is, node elements and edge elements will first be described using the graph theory. After that, the syntax of EPC will be defined, and the correct properties that must be fulfilled will be described based on the graph theory. Examples of nodes are events and functions; examples of edges are control flow and information flow.

15

In this formal description of EPC only the nodes and edges of control flow will be discussed. This is due to the fact that control flow is the most important flow in EPC representing the business process. Another reason is that in the EPC the other two edge elements, that is, information flow and organization unit assignment, are only simple graphs (the organization unit assignment only connects an organization unit to a function and the information flow connects an information material to a function). We first recapitulate some basic ideas from the graph theory in order to provide description for the EPC syntax: 1. We understand a directed graph G as a tuple G = (V, A, N) consisting of a set of vertices V, set of edges A and a function N : A V V, which assign to each a A the ordered pair N(a) V V, which consists of the input node and the output node of the edge a. In this definition both parallel edges and loops are allowed. In the following we will regard only directed graphs, so that in general we omit the addition of word "directed". 2. In most works we will regard only simple graphs, i.e. neither parallel edges nor loops are allowed. The edges of a simple graph are determined by the specification of the initial and terminal vertex. Therefore we use the notation G = (V, A) with a number of nodes V and an irreflexive relation A V V for the designation of a simple directed graph as the set of edges. 3. A path in a simple graph G = (V, A) from a node va to a node ve is a finite sequence of nodes vi V, i = 0, ,n, = (v0, v1,,vn), v0 = va, vn = ve, so that each two successive nodes form an edge: (vi, vi+1) A, i = 0,,n 1, form an edge i. n is called the length of the path. The path is called simple if no two nodes v are equal. A cycle is a path = (v0, v1,,vn) with v0 = vn and vi, i = 0,,n 1. 4. A graph G = (V, A) is called connected, if for any two nodes v,w V there exists a path from v to w or a path from w to v. We define the syntax of EPC by following definition: An Event-driven Process Chain (EPC) is a directed, connected, and simple graph EPC = (V, A) with the following properties: 1. The set of nodes V is the union of four disjoint sets: E = set of events F = set of functions P = set of process paths L = set of binary connectors of type AND, OR, XOR. 2. The set of edges A is an antisymmetric relation on VxV with the following characteristics: a. If there is a path u1, u2,, un from a node a = u1 (E F P) to a node b = un (E F P) so that all intermediate nodes ui, 2 i n-1, are connectors, ui L, we call a and b connector-connected. No event e E must be connector-connected to 16

an event f E. No function of process path f (F P) must be connectorconnected to another function of process path g (F P). b. The predecessors of a node belong to one type of node, and likewise all successors belong to one type, i.e. for each node v V applies: *v E or *v F or *v P or *v L and v* E or v* F or v* P or v* L. 3. Events, functions, and process paths are nonbranching, more exactly: For each event e E, *e 1 and e* 1 for each function f F, *f = f* = 1 and for each process path p P, *p + p* = 1 4. Connectors have either several incoming edges and one outgoing edge or one incoming edge and several outgoing edges, (*l = 1 and *l 1) or (*l 1 and *l = 1) 5. An event s E is called a start event if *s = and is called an end event if s* = . There is at least one start event and one end event.

17

Chapter 3 UML Activity Diagram

Activity diagrams are one of the five diagram types in the Unified Modeling Language (UML) for modeling dynamic aspect of systems. The UML itself is a standard modeling language in the area of software development. It was developed by Booch, Rumbaugh, and Jacobson and was later accepted as standard in object-oriented modeling by the Object Management Group (OMG). The current version is UML 1.3 [BRJ99a]. Unlike other techniques in the UML, the activity diagram doesnt originate from the previous works of the three amigos, instead it combines the ideas from several techniques: the event diagram of Jim Odell, SDL state modeling techniques, and Petri nets [Fow97]. It is incorporated to extend the UML for modeling processes and workflows.

3.1. The Unified Modeling Language (UML)

The UML is a general-purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of a software system [BRJ99a]. Specifying means that the model of the system is built in a precise, unambiguous, and complete way. The UML uses graphs to visualize the model so that developers can have a common interpretation when exchanging ideas. The UML is not a visual programming language, but tools can provide code generators from UML into a variety of programming languages. The UML is also the tool to document the project during software development. One important point is that UML is a language to model a system. It is process independent, which means that the user is free to use any methodology for constructing and using the UML diagrams. 3.1.1. Architectural Views Visualizing, specifying, constructing, and documenting a software system demands that the system be viewed from a number of perspectives. Different participants in the software development project such as end users, analysts, developers, system integrators, testers, technical writers, and project managers look at the system in different ways at different times over the projects life. A systems architecture is perhaps the most important artifact that can be used to manage these different viewpoints and so control the development of the system. As figure 3.1 illustrates, the architecture of a software system can be described by five views. Each view is a projection into the organization and structure of the system, focused on a particular aspect of that system: Use case view. This view of a system encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. This view does not really specify the organization of a software system, but rather specifies the forces that shape the systems architecture.

18

Design view. This view of a system encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users. Process view. This view of a system encompasses the threads and processes that form the systems concurrency and synchronization mechanism. This view primarily addresses the performance, scalability, and throughput of the system. Implementation view. This view of a system encompasses the components and files that are used to assemble and release the physical system. This view primarily addresses the configuration management of the systems releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system. Deployment view. This view of a system encompasses the nodes that form the systems hardware topology on which the system executes. This view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system.
vocabulary functionality system assembly configuration management

Design View
Use Case View

Implementation View

behavior

performance scalability throughput

Process View

Deployment View

system topology distribution delivery installation

Figure 3.1. Modeling a systems architecture (from [BRJ99b]) In each of these views there are UML diagrams described later that cover the static and dynamic aspects of the system. The use case view is primarily captured in use case diagrams. The static aspects of the design and process view are captured in class diagram, those of the implementation view in component diagrams, and the deployment view in deployment diagrams. In all these views the dynamic aspects are captured in behavioral diagrams of UML such as the interaction diagrams, state diagrams, and activity diagrams. Each of these five views can stand alone so that different participants in software system can focus on the issues of the systems architecture that most concern them. These views also interact with one another nodes in the deployment view hold components in the implementation view that, in turn, represent the physical realization of classes, interfaces, collaborations, and active classes from design and process views. 3.1.2. UML Diagrams In the following the diagrams used in UML are described briefly. These diagrams are not a must when solving problems in software development, but they are mostly likely to be used in the analysis and design. Indeed the UML provides extensibility so that we can

19

define other stereotypes, but these diagrams are usually sufficient to cover all aspects in software system. There are eight diagrams available, grouped into structural diagrams that deal with static aspect of a system, and behavioral diagrams that deal with dynamic aspect of a system. 3.1.2.1. Structural Diagrams Structural diagrams in the UML serve to visualize, specify, construct, and document the static aspects of a system (both software and hardware systems). They describe the kinds of objects important to a system and to its implementation, as well as the relationships among the objects. The static structures in software development system are classes, interfaces, collaborations, objects, components, and nodes. The UML diagrams that handle these structures are: Class Diagram. The class diagram is the basic yet most important diagram in the UML. It is the central part in modeling object-oriented systems. A class diagram shows a set of classes together with their relationships. There are some important terms and concepts related to the class diagram: Class. A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class is an abstraction of the things that are part of our vocabulary. For example wall can be considered a class. Every class must have a name that distinguishes it from other classes. Attribute. An attribute is a named property of a class that describes a range of values that instances of a class may hold. As an example, some attributes of the class wall may be color, height, thickness, etc. At a given moment, an object of a class will have specific values for every attribute of its class. Operation. An operation is the implementation of a service that can be requested from any object of the class to affect its behavior. In our wall example the operations might be to paint the wall. Visibility. The visibility level determines whether the attributes and operations can be accessed from outside. There are three visibility levels: private, protected, and public. In the class diagram there are different relationships between classes: Association. An association is a structural relationship between instances of classes in the same level. Generalization. A generalization is a relationship between a general thing (called superclass) and a more specific kind of that thing (called subclass). It is sometimes called an is-a-kind-of relationship. Aggregation. An aggregation is a relationship in which one class represents larger thing composed of smaller things (called parts). It is sometimes called a has-a relationship. To each of these relationships we can additionally describe them by adding name of the relationship, role of the class participation in the relationship, and multiplicity (number of instances participating in the relationship). Component Diagram. The component diagram shows the relationship and dependencies among software components, including source codes, binary codes, run-time executables, and software documents. Components may also be connected to components by physical 20

containment representing composition relationship. A component diagram is composed from the following elements: Component. A component is a physical unit of implementation with well-defined interfaces that is intended to be used as a replaceable part of a system. An interface is a list of operations supported by a piece of software. Each component embodies the implementation of certain classes from the system design. In the UML a component is drawn as a rectangle with two small rectangles on its left side. It may be attached by solid lines to circles that represent its interfaces. Component package. Component packages bundle physical components together. Typically a component package corresponds to a directory in the file system. A component package in UML is represented as a directory symbol. Deployment Diagram The deployment diagram and component diagram are two diagrams used in UML to model physical aspects of an object-oriented system. A deployment diagram shows the configuration of run time processing nodes and the components that live on them. Components that do not exist as run-time entities (because they have already been compiled) do not appear in these diagrams, they should be shown in a component diagram. The main element in the deployment diagram is node. A node is a physical object (usually a piece of hardware) that represents a processing resource, generally, having at least memory and processing capability. It is drawn as three-dimensional cube. Components can be drawn inside together with the dependencies. An association between nodes can also be illustrated using a line.

3.1.2.2. Behavioral Diagrams Behavioral diagrams in the UML serve to visualize, specify, construct, and document the dynamic aspects of a system. The dynamic behavior describes the history of objects over time and the communication among them. In a software system these are the things such as the flow of messages over time and the physical movement of components across a network. The UML diagrams addressing this dynamic behavior are: Use Case Diagram. A use case diagram serves to model typical interactions between a user and a system. It is the basic diagram to understand the system from the end users perspective. According to [Fow97], use cases used to be described using sentences, then Jacobson introduced use case diagram to visualize them. The elements of a use case diagram are: Actor. An actor is a role that a user plays with respect to the system. It can be human beings as well as external systems that need information from the current system. Use case. Use cases represent what the system do with respect to the user. They describe a scenario, in which each sequence in the scenario represents the interaction between the user and the system. A use case has a name and a textual description. Association. Association is a bi-directional relationship between a user and a use case or between use cases. In addition to association between use cases two stereotypes are defined: o Stereotype extends means that the extended use case is a variation to the other use case.

21

o Stereotype includes means that the included use case is used together by two or more use cases. Generalization. Generalization between use cases means that a general use case has relationship with other special use cases. Interaction Diagram. Interaction diagrams describe how a set of objects collaborates in some behavior. Typically, an interaction diagram captures the behavior of a single use case. The diagram shows an example of objects and the messages that are passed between these objects. There are two kinds of interaction diagram: Sequence diagram shows the chronological passing of messages between objects from top to bottom over time. Each object participating in the interaction is put at top of the graph, and a lifeline is shown to represent the objects life during interaction. Each message is represented by an arrow between the lifelines of two objects. Collaboration diagram emphasizes the structural organization of the objects that send and receive messages. The sequence is indicated by numbering the messages. State Diagram. Just like interaction diagram, state diagrams also capture the behavior of a system over time. The difference between them is that an interaction diagram is aimed at showing interaction of objects while a state diagram is aimed at describing all possible states a particular object can get into and how the objects state changes as a result of events reaching the object. State diagrams are normally drawn for a single class to show the lifetime behavior of a single object. Elements of a state diagram are: State of the described object containing the name of the state and the action to be executed. Transition between states including an event that describes uninterruptible process, a guard of the transition, or a message sent to or received from another object. Activity Diagram Activity diagram is just like a state diagram and is intended to model workflows and processes. It will be described later in more detail.

Figure 3.2. Diagrams of the UML and their connections (from [LA98a]) 22

3.2. Activity Diagram Notation

An activity diagram is a special case of state diagram in which all or most of the states are activity states and in which all or most of the transitions are triggered by completion of the activities in the source state. The entire activity diagram is attached through the model to a class, an operation or to a use case. The purpose of this diagram is to focus on flows driven by internal processing as opposed to external events. Figure 3.3 shows the elements used in activity diagram.

Activity/Action State

Start State Stop State

Transition

Decision

Synchronization Bar

Object Flow

Object

Figure 3.3. Elements of activity diagram An activity diagram contains the following elements: Activity states and Action states. An activity is an ongoing non-atomic execution within a state machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in a change in state of the system or the return of a value. Action states are states of the system that represent the execution of an action. Action states cannot be decomposed. The atomic property of action states means that events may occur, but the work of the action state is not interrupted. The work of action state is generally considered to take insignificant execution time. Examples of actions are capture requirement, check stock, etc. On the other hand, activity states can be further decomposed and represented by other activity diagrams. They are not atomic, meaning that they may be interrupted and generally considered to take some duration to complete. With this definition, we can say that an action state is an activity state that cannot be further decomposed. Similarly, we can think of an activity state as a composite, whose control flow is made up of other activity states and action states. There is no difference in notation between activity states and action states, except that an activity state may have an entry and exit actions as well as submachine specifications. Activity states and action states are represented in the activity graph using a lozenge shape (a symbol with horizontal top and bottom and convex sides). In addition to activity states and action states, two special states are defined in activity diagram to mark the beginning and end of control flow. Those are the start state represented in activity graph as a solid ball, and the stop state represented as solid ball inside a circle. Nevertheless sometimes it is not necessary to mark the beginning or end of control flow when the start and end activities are clear or when the control flow is intended to continue indefinitely.

23

Transitions. When the action or activity of a state completes, the flow of control passes immediately to the next action or activity state. This flow is specified using transitions to show the path from one action or activity state to the next action or activity state. Once the action of the source state completes, if there is any exit action then the states exit action is executed, and next the control passes to the target action, execute its entry action (if any), its action, and so on. In the activity graph this transition is represented as a simple directed line. Branches and Merges. In many cases of control flow we need to make some kind of decision between two or more choices. This is accomplished in the state machine by a branch, which specifies exclusive alternate paths taken based on a Boolean expression, which means that flow of control will pass to either one of the outgoing paths from the branch. In the activity graph this branch is represented as a diamond. A branch may have one incoming transition and two or more outgoing ones. On each outgoing transition, a Boolean expression or a guard is placed, which is evaluated only once on entering the branch. Across all these outgoing transitions, guards must not overlap (otherwise it would be ambiguous), but they must cover all possible choices (otherwise the flow would freeze in the branch). As a convenience, we can use the keyword guard else to one outgoing transition; the path taken if no other guard expression is true. Multiple paths coming from the same branch can be merged into one transition. It is represented as multiple transitions merging into a diamond.
Branch

[else] [Condition1]
A1 A2

Merge

If the guard expression in Condition1 is fulfilled, activity A1 is executed, otherwise A2 is executed

Figure 3.4. Branch and merge in activity diagrams Forks and Joins. The strength of activity diagrams over flowcharts is that it is possible in activity diagrams to describe parallel activities. Parallelism is often encountered when modeling business processes or multitasking/multithreading software operations that involve concurrencies among activities. In the UML, we use a synchronization bar to specify the forking and joining of these parallel flows of control. A synchronization bar is rendered as a thick horizontal or vertical line. A fork represents the splitting of a single flow of control into two or more concurrent flows of control. A fork may have one incoming transition and two or more outgoing transitions, each of which represents an independent flow of control. Below the fork, the activities associated with each of these paths continue in parallel. Conceptually, the activities of each of these flows are truly concurrent, although in reality these flows 24

may be either truly concurrent or sequential yet interleaved giving the illusion of concurrency.
A1 Fork

[Condition1]
A2 Join A3 A4

As soon as activity A1 finishes, activities A2 and A3 are executed concurrently with A4 if guard Condition1 is fulfilled

Figure 3.5. Fork and join in activity diagrams A join represents the synchronization of two or more concurrent flows of control. A join may have two or more incoming transitions and one outgoing transition. Above the join, the activities associated with each of these paths continue in parallel. At the join, the concurrent flows synchronize, meaning that each waits until all incoming flows have reached the join, at which point one flow of control continues below the join. It is possible to put a guard on a transition below a fork. This means that the path below the guard would only be activated or executed when the condition of the guard is fulfilled. Again care must be taken so that the flow of control will not be stuck in the fork. Iterations. Another form of parallel activities can be performed as iterations. This is accomplished using what is called multiple trigger the same activity is triggered repeatedly. We can indicate this trigger by attaching a * (multiplicity sign) to the transition that drives the activity and specifying it with a guard, for example [for each item on]. The complement of this is usually a synchronization bar down in the diagram that brings the parallel threads together. This iteration can also be represented as an activity with dynamic concurrency, meaning that it is executed multiple times where the number of concurrent activities depends on some arguments.

* [for each item on order] Check item on stock Check item on stock

Figure 3.6. Iteration and dynamic concurrency 25

Swimlanes. Activity diagrams tell us what happens, but they do not tell us who does what. In software system this means that the diagram doesnt convey which class is responsible for each activity. In business modeling this means that the diagram doesnt convey which department or person/actor is responsible for each activity. Therefore it is useful mainly in modeling business processes to partition the activity states on an activity diagram into groups, each group representing the business organization responsible for those activities. In the UML, each group is called a swimlane because visually each group is divided from its neighbor by a vertical solid line. Each swimlane has a name unique within its diagram. A swimlane really has no deep semantics, except that it may represent some real-world entity. Each swimlane represents a high-level responsibility for part of the overall activity of an activity diagram, and each swimlane may eventually be implemented by one or more classes. In an activity diagram partitioned into swimlanes, every activity belongs to exactly one swimlane, but transitions may cross lines. Object Flow. Objects may be involved in the flow of control associated with an activity diagram. We can specify the things that are involved in an activity diagram by placing these objects in the diagram, connected using a dependency to the activity or transitions that creates, destroys, or modifies them. This use of dependency relationships and objects is called an object flow because it represents the participation of an object in a flow of control. In addition to showing the flow of an object through an activity diagram, we can also show how its role, state and attribute value change. As shown in the figure, we represent the state of an object by naming its state in brackets below the objects name. Similarly, we can represent the value of an objects attributes by rendering them in a compartment below the objects name.
Sales
Start Sate Transition Capture Requirement

Procurement
Swimlane

Activity Object Flow Check Stock

o:Requirement [captured]
Object [on stock]

o:Requirement [checked]

Provide Material

Order Material

Stop State

Figure 3.7. Example of an activity diagram showing an excerpt from procurement logistics 26

3.3. Usage of Activity Diagrams

Like any other diagrams in UML, activity diagrams have also strengths and weaknesses. The strength of activity diagrams lies on their ability to support parallel behavior, but their great disadvantage is that they do not make clear the links between activities and objects, which are visualized better using interaction diagrams or state diagrams. However they are suitable mostly when we deal with the following situations: Modeling an operation. Activity diagrams can be used to model an operation associated with a use case or a class. In this case we are only interested in understanding what actions need to take place and what the behavioral dependencies are. Using an activity diagram to model an operation is simply like using it as a flowchart that supports concurrencies among threads in an operation. Modeling a workflow. Activity diagrams are best suited to model workflows across use cases that involve many actors or business organizations. In this case we focus on activities as seen by the actors that collaborate with the system.

27

Chapter 4 Comparison, Translation, and Integration Approach between EPC and UML Activity Diagram
We have already discussed the Event-driven Process Chain (EPC) in chapter two and the UML Activity Diagram in chapter three. In this chapter first we will compare both diagrams as the tools to denote business processes. The purpose of comparing both diagrams is to show the strengths and weaknesses of each diagram when we use them to denote business processes. After comparing both diagrams the next approach is how we can translate from one diagram to another. The purpose of this translation procedure is to show how we can understand the idea of a business process from both diagrams and to illustrate the results from the comparison we made before. As a third and final step, we will introduce an integration approach. The integration approach chosen here does not mean that we try to integrate EPC with activity diagrams; instead we show how to bring EPC and UML closer together using object-oriented EPC.

4.1. Comparison between EPC and UML Activity Diagram

When comparing the EPC and UML Activity Diagram for denoting business processes, there are some aspects from which we can view the correspondences and differences between these two methods. The comparisons can be mainly grouped into three aspects: Context. This aspect covers in which context the EPC or UML Activity Diagram are developed and used. Both diagrams can be used for modeling business processes, but both have different contexts under which they are developed. Exactness/Ambiguity. In modeling business processes, it is possible that the EPC or Activity Diagrams that are created would be ambiguous. Examples of this are implicit decisions, possibility of having blocking, etc. Therefore it is necessary to take a look at the exactness or ambiguity of the diagrams constructed with EPC or UML Activity Diagram. Notation/Terminology. Both the EPC and UML activity diagrams have similar concepts such as fork/join, branch/merge, atomic/extended activity, etc but they are represented using different notation and terminology. Some notation does not have a counterpart in the other diagram. This indicates the semantic differences between them. Therefore we will compare both notations and terminologies to see the correspondence of symbols of one diagram in another diagram and the differences between them. 4.1.1. Context Even though the EPC and UML Activity Diagrams are used or can be used to denote business processes, they were developed in different contexts. This pragmatic difference 28

comes from the different modeling approaches that drive the EPC and UML. There are two approaches to model a system: Process-oriented modeling. In process-oriented modeling, the main focus of modeling a system is the process inside the system. A process consists of sequences of events triggering activities/functions. The events themselves are the results of other functions apart from initial events that trigger the whole process. By introducing logical operators, this event-driven control structure can be expanded to a complex control flow illustrating relevant decisions and potential for concurrency that happen in the process. This process-oriented modeling is the basis for the EPC, which found its way as a standard for modeling business processes of an enterprise. The basic EPC model can be extended by further semantic components to illustrate the elements participating in the process such as information objects and organization units. Object-oriented modeling. In object-oriented modeling, the main focus of modeling a system is the objects inside the system. A system is a bunch of objects that have relationships among them. These objects communicate each other by exchanging messages. An object is a discrete and differentiable entity in a system. Each object has properties and exchanges messages through operations. This object-oriented modeling is the basis for UML, which is mainly used in software development such as enterprise information system. Initially activity diagrams are targeted for modeling the dynamics of internal objects actions. Because of its characteristics similar to flowcharts and its capability to visualize concurrent activities, they can be generalized to model operations, use case scenarios, workflows and business processes. 4.1.2. Exactness/Ambiguity An attempt to standardize the syntax of EPC has been introduced in the last part of chapter 2 by [KT98] based on graph theory. The formal description of EPC can be used to analyze the syntactical correctness of an EPC diagram. However in practice there are still some problems regarding the exact meaning of some elements in the EPC. The ambiguities arise from the analysis of how elements in an EPC diagram interact in a flow of process (shown as tokens). Those ambiguities are: Conjunction of start events. An ambiguity concerning the modeling of start and end events occur in the EPC. It is obvious that nodes without input edges are the start events and similarly nodes without output edges are the end events. But the interpretation is left to the reader, which combination of start and end events he should see as admissible, that is, as seen in reality. The problem becomes obvious when there exists events from the side meaning start events in the middle of the process which has been started some time before by the first start events. These usually represent communication with external entity. However this conjunction of start events is not explicitly modeled in EPC. Semantics of logical connectors. There are three logical connectors in EPC, that is, XOR, OR, and AND connectors. In chapter two we have already discussed how to connect these logical connectors to events and functions in the control flow. We know that because an event cannot be used to make decisions, an event cannot be followed by logical connectors XOR and OR. Nevertheless there is also an ambiguity in the semantic of logical 29

connectors, especially in the XOR and OR connectors. Consider the case in figure 4.1. In the case of AND connector, the function F1 can only start when both events E1 and E2 occur. That is clear, the AND connector serves to synchronize by waiting until both events have occurred. In the case of XOR connector, the switching rule of the exclusive or connector says that if either event E1 or event E2 occurs, the following function F1 can start. One question arises, what does the rule mean, when both events occur one after another, for example E1 occurs first then after some time E2 occurs? Can the function then run twice: The first time after the occurrence of the first event, and the second time after the occurrence of the second event? There are several interpretations for what the modeler wants to express, when he uses this connector: a. When both events occur at the same time, they block the following function, or b. Both events cannot occur at the same time, or c. When the following function starts, then exactly one of both events must have occurred For the OR connector, the following rule applies: when at least one of the events occurs, the following function can start; when both events occur at the same time, the function can only start once. A similar question arises for the OR connector as for the XOR one that is, whether the function runs once or twice. Again, there are several interpretations when the events occur one after another, but in the case of OR connector it is obvious that when both events have occurred the function is not blocked.
E1 E2

E1

E2

E1

E2

AND

XOR

OR

F1

F1

F1

Figure 4.1. Two events arriving at one connector Deadlocks and Loops. For simple EPC graphs it is easy to analyze whether the graphs work or not, but for complex graphs we need a tool to analyze them. It is possible that even when the graph is semantically correct according to the definition of EPC in chapter 2, still an analysis shows there can be deadlocks when executing the process according to the diagram. A deadlock means that in reality when the start events occur thus the process runs after some time the process is stuck somewhere in the graph unable to reach the end states. Possible causes of deadlocks are mismatches of logical connectors especially in complex graphs where connectors link to other connectors and different interpretation of logical connectors. For an example an OR connector can work either in XOR mode or in AND mode. If an opening OR connector works in XOR mode but the closing OR connector works in AND mode or the other way around, a deadlock would happen. This can be solved if the closing OR connector knows in advance in which mode the opening OR connector works. Another possible problem discovered by graph analysis is looping. A loop may cause a process to run forever. This is usually not intended to occur in business processes. 30

These ambiguity problems have been addressed in [LSW97]. They used the Petri net approach to analyze the problems. The methodology that they present consists of transforming an EPC diagram into a Petri net and then analyzing it. The Petri net formalism used to analyze it is a variant of colored place-transition Petri net which they callBoolean Petri net. The semantics of Petri nets are very well-defined and they are developed formally in academic research, therefore the result of the Petri net analysis is very reliable. They solve the problems by explicitly passing information in the form of a Boolean token (token 1 means activation and token 0 means deactivation of an element) along the graph. A connector must wait until complete information from the tokens arrives for connectors constructing loop however this has to be treated differently. For a more detailed description of the Boolean Petri net and its analysis to prove whether the transformed EPC is semantically and operatively correct (meaning that there are no deadlocks and loops when the token of Petri net is passed in the diagram) the reader can refer to [LSW97]. Since activity diagrams are derived from SDL and Petri net [Fow 97] which has very welldefined semantics, they are more precise and can be formalized using Petri net analysis. 4.1.3. Notation/Terminology Since both EPC and UML Activity Diagram serve to visualize processes and workflows, both diagrams have similar notations for some common terminologies such as activities, branches and merges, forks and joins, etc. as well as some notational differences between them. These notational correspondences and differences will be discussed here and we will use the result of these notational comparisons for the translation from EPC to UML Activity Diagram and vice versa later on. For comparing the notations of both diagrams we will use the EPC diagram from chapter 2 and activity diagram from chapter 3.
Requirement occured Material Capture requirement Employee Requirement captured Capture Requirement Sales

Sales

Procurement

Material

Check material on stock

Procurement

o:Requirement [captured]

Check material on stock

[on stock]
XOR

o:Requirement [checked]
[not on stock] Order Material

Material on stock
Procurement

Material not on stock

Procurement

Provide Material

Get material from stock Material Material provided

Order material Order Material ordered

Figure 4.2. Example of notational correspondences in EPC and UML Activity Diagram

31

The notational correspondences and differences of both diagrams can be categorized as follows: Functions and Activity/Action States. Both the functions in the EPC and activity/action states in UML Activity Diagrams are the active elements that represent what a person of an organization unit or an actor in a use case diagram do with respect to the process. Therefore it is clear that functions and activity/action states represent specific business tasks within a company. That means that they share the same role within their respective diagrams. An activity or a function usually takes some extended time to execute. Events. In the EPC an event is a passive element that triggers a function and is a result of another function. The events can also show the change of status of an object over the process chain. There is no correspondence of events in activity diagrams, even though the activity diagrams are based on state diagram, but the states are mostly activity states, while an event is not an activity. Nevertheless if we take a look at the example of EPC some of the events, especially those that are the direct results of a function, are redundant. For example in the figure 4.2 the result of the function capture requirement is requirement captured which means that the resulting event is just to show that when the function finishes control will pass to the event which in turn triggers the next function. However in activity diagram this intermediate result is not explicitly declared. This is because the transition in activity diagrams means that as soon as an activity state finishes it does not have to wait (which correspond to the event) but instead it will trigger the next activity. Control flow and Transitions. Control flow in the EPC corresponds to the transitions in UML Activity Diagram. Control flow is used in a process-oriented approach to show the process chain over time from one event that triggers a business function that in turn results in another event. Activity diagrams are based on state diagrams in which transitions are defined; transitions show the change of states over time. Control flow and transitions are instantaneous; they are assumed not to take so much time. However in the EPC, between two functions there can be some time for the control/token to be kept in an event. Logical connectors. Logical connectors allow the splitting of control flow in the EPC and transitions in activity diagrams. For the splitting regarding to taking a decision between different alternative paths, both diagram have a similar construct, which is known as branch/merge. The branching and merging of control flows in the EPC is represented using the logical XOR connector plus the events following it. The same mechanism in activity diagrams is implemented using the decision diamond symbol and transition labels. Both diagrams also support the notation of parallelism known as fork/join. The forking and joining in the EPC is shown using the logical AND connector while in activity diagrams it is shown using the synchronization bar. Actually a synchronization bar corresponds to an AND connector together with the events before it, because a synchronization bar waits for all transitions to arrive. The main difference between EPC and activity diagrams in the case of logical connectors is that EPC supports inclusive or connector while there is no notation in activity diagrams to denote the OR connector.

32

Organization units and Swimlanes. An organization unit in the EPC is attached to a function its responsibility for the respective business task. In the activity diagrams this is accomplished by arranging the activities that belong to the same department in a company or activities being done by the same actor in a use case into swimlanes. Iteration. Activity diagrams support the notation for iteration which is not available in the EPC.

The comparison between EPC and activity diagrams are summarized in the following table: EPC Process-oriented modeling (business oriented) Event from the side, deadlocks, loops, logical connector semantics Function Event Control flow XOR connector AND connector OR connector Organization unit UML Activity Diagram Object-oriented modeling (IT oriented) -

Context Exactness/Ambiguity

Notation/Terminology Active Element Passive Element Process chain Logical connectors Branch/Merge Fork/Join Inclusive or Actor Iteration

Activity/Action state Transition Decision diamond Synchronization bar Swimlane * (multiplicity sign)

Figure 4.3. Summary of comparison between EPC and UML Activity Diagram

4.2. Translation between EPC and UML Activity Diagram

In translating from EPC to activity diagram and the other way around, we will use the results from the comparison between EPC and UML Activity Diagram as already discussed before. To translate from an EPC diagram to an activity diagram, the following guidelines can be used: 1) Determine the organization units involved in the process chain together with the functions that each of the organization is responsible for. Align the organization units into separate swimlanes in an activity diagram. 2) Transform each function into activity/action states in the activity diagram and put it in the swimlane of the organization unit being responsible for it. If the function is a complex hierarchical function (which is also called a process), the refined EPC for that specific function can be either drawn as a complex activity state (meaning that inside the activity state we must specify some actions performed in the activity as well as

33

entry and exit actions) or it would be better to draw the function in a separate activity diagram. 3) Transform the corresponding logical connectors from the EPC into the corresponding elements in the activity diagram. The branches and merges represented by XOR connectors are transformed into decision diamonds and the forks and joins represented by AND connectors are transformed into synchronization bars. 4) Connect the activities and decision diamonds or synchronization bars according to the control flow in the EPC. 5) Add the start event(s) and end event(s). It is possible to have multiple start events and end events. This can be considered as multiple start events in the EPC or can also be considered as several scenarios in one diagram. However, there are some problems with regard to the translation from an EPC to an activity diagram: As can be seen from the comparison, not all logical connectors for splitting and joining the control can be modeled in a straightforward way. The main problem is with the OR connector; there is no corresponding element in activity diagram to represent this logical connector. One solution is to express this OR connection in terms of XOR and AND connectors. To show this, we know from the logic theory that for two variables x and y, the following equation applies x or y (x xor y) xor (x and y). Using this equation we can translate two alternate paths taken based on an opening and a closing OR connectors into the following diagram:

OR

F1

F2

F1

F2

F1

F2

OR

Figure 4.4. The branch/fork solution for the elementary or-connector However if the OR connector connects more that two alternative paths the resulting translation in the activity diagram would be very complicated. The organizational responsibility for activities is expressed in activity diagrams using swimlanes. However, swimlanes are not sufficient for modeling advanced and precise organizational relationships. These are important for example for the definition of workflows when support through workflow management systems is intended. Another problem with respect to translation from EPC to activity diagram is related to the loss of important information contained in events and information/resource objects. Some of the events are related to the change of state of an information/resource object. We can show this change of objects state as an object with the object flow in an activity diagram, but if there are many information/resource objects in an EPC, they would make the diagram very hard to read. 34

The definition of activity diagrams as state machines is quite problematic for applying activity diagrams according to the UML definition for business process modeling because actually not all business functions can be regarded as internal action states, e.g. interaction with outside business units. A reverse procedure can also be applied to translate an activity diagram into an EPC: 1) Transform the activity/action states from the activity diagram into functions in the EPC. 2) Transform the corresponding decision diamonds or synchronization bars into XOR or AND connectors. 3) Create dummy events before and after each function. For self-explanatory events as the results of their respective previous functions it is easy to fill them. Conditions as transition labels especially after a branch can be more or less transformed into events after an XOR connector. If there is an object flow in the activity diagram, that can be used as a guide to create the events, e.g. the requirement [captured] object state can be transformed into the requirement captured event. 4) Connect the elements (events, functions, and logical connectors) with the control flow according to the transitions in the activity diagram. 5) Connect the functions with the respective organization units transformed from swimlanes using organization unit assignment. Again, there are also problems with regard to the resulting EPC diagram: Since there is formally no information about events in an activity diagram, the main problem in translating from an activity diagram to an EPC is to create the events that trigger functions and events as the results of functions. Object flows and transition labels or guards can be used as a reference to create events, but that is not a general solution. The only guaranteed solution is to try to understand the process that is modeled with the activity diagram and use the events based on this domain knowledge, but this is not a very good one because in that case it would be more efficient to model directly using the EPC. Because activity diagrams contain no information about information or material object, the resulting EPC diagram is not a complete diagram, instead it contains only the control flow and organization units. Since there is no corresponding notation for iteration in the EPC, we need to construct a loop for that. An additional effort to control the loop is needed so that it works as in the activity diagram.

4.3. The Integration Approach: The Object-EPC (oEPC)

This section argues for an integrated approach to object-oriented process modeling and describes selected aspects of an exemplary approach by [SNZ97] called the object-oriented EPC (oEPC). 4.3.1. Motivation for Integration We have already discussed in the first part of this chapter the contextual background of EPC and UML activity diagrams. The EPC is developed in the context of business process modeling and the UML is developed in the context of software development. Nowadays the successful development of business information systems requires an integrated 35

approach which includes the seamless design of both the business processes and information systems development supporting the business processes. The business processes are modeled in a process-oriented framework, while on the other hand objectoriented modeling methods are used only on aspects which are close to software implementation, not the business processes. However these two fields are moving closer together because of several driving forces: Object-oriented implementation languages such as C++ or Java play an increasingly important role for the development of business information systems. In order to give an overall description of a companys business processes and its object-oriented information systems it is therefore necessary to integrate business process modeling languages with object-oriented modeling ones. Object-orientation becomes more and more popular not only as a software paradigm, but also as a way of mentally structuring complex systems. Thus, object-oriented approaches can also be used on the business level for identifying the objects to be dealt with in a business process and its relationships. With the development of business objects as software components which can be assembled to an information systems according to the users specific requirements, it is necessary to provide means for defining how a business process is supported by the cooperation of business objects. For these reasons and due to the fact that the translation approach between EPC and UML activity diagrams has posed some significant problems, it is reasonable to think of an approach for integrating the strengths and advantages of the EPC and the UML to create a method that cover both areas of business process modeling and object-oriented information system. The purpose of the integration approach is on the one hand to preserve the potential and the end users acceptance of the standard EPC method for business process modeling and on the other hand to integrate the object-oriented methods with the EPC. With this approach it is supposed to be possible to model all relevant aspects of a companys business processes and its object-oriented information system without the need for switching between different modeling paradigms or for translating between different modeling languages. Within this concept, a business process is defined as the event-driven processing and the corresponding interaction of business objects in the same diagram. The oEPC differentiates between business process, business object, the corresponding resources such as organization units, information resources and events. Business objects can be grouped into classes. Each business object class has attributes and methods or functions. For modeling business processes, the interaction between objects takes place via message exchanges denoted as event-driven control flow. 4.3.2. Modeling Business Objects In the object-oriented paradigm, data can only be created, read, or changed by calling an objects methods. The method protocol, that is, how and when the method can be called, is accessible by other objects, but the implementation of the method is kept hidden (information hiding). Figure 4.4 shows how to represent a business object in an oEPC diagram. The symbol for a business object is the same as the symbol for a class in the

36

UML. To show the attributes and called methods of an instance of the class, we can show the attributes on the left and methods on the right of the business object.

attribute a1 attribute a2

business object class 1 method m1() method m2()

logical connector

*
event 1 event 2 ...

Figure 4.5. Model of a business object with events Since events are represented as messages and this is a matter of object meta-model, the events are drawn using their own symbol. This is a fundamental difference with UML interaction diagrams in which events are not explicitly shown but implicitly represented as arrows between two objects, thus leaving out some important semantics from the description of dynamic system relationships. In figure 4.4 the events are represented below the object. Since an object can send more than one message at the same time with different contents based on its state, a connector can be used to connect the object with the events. This connector contains conditions (mechanisms and rules) for the choice of the corresponding events. 4.3.3. Modeling Business Processes For the modeling of business processes as interactions between business objects, two types of message exchange are distinguished: Event-based messages. They describe the control flow and the decision logic. The message contains the information about the state transition of a business object at a certain time caused by the execution of one of its methods. This is explicitly modeled by events. Hence object classes are connected via events in order to describe a business process. As a substantial aspect of business process modeling, the assignment of the organization units or the persons carrying out the tasks to the business objects can also be shown here similar to the standard EPC, thus the relevant organization units can be modeled in the context of the respective process and their role during the process can be illustrated. Service-control messages. This type of message is used to define client-server relationships among classes. The sender (client) triggers the recipient (server) to deliver a service which the sender needs for further execution of the process. However this client-server relationship is not the focus of attention within the business process analysis.

37

Start event

Transition Object A

Object class A

Organization unit 1

control flow Event/Message Object class A

Transition Object B

Object class B

Organization unit 1

Event/Message Object class B

Figure 4.6. Basic model of an event-based message (from [SNZ97])

Start event

Start event

Job Message A1 ('get')

Object class A

Object class C

Object class A

Object class C

Event/ Message A

Result Message C1 ('send')

Object class A

Event/ Message A

Figure 4.7. Service-control relationship as encapsulated control flow (from [SNZ97]) As already described in the business object model, several events can result from a change of objects status. Similarly, it is possible that an object can only execute its method when several events occur. In order to model these cases and other similar interdependencies, the logical connectors AND, OR, and XOR are introduced into the oEPC. The combination of these Boolean operators and the events makes up the link to common business roles in analogy to the standard EPC.

38

Figure 4.7 shows an exemplary structure of a business process model by means of oEPC symbols and terminology illustrating graphically the control flow defined by event-driven messages. The relationships among business object classes involved in the process can be described using a class diagram (as opposed to entity-relationship model used in the standard EPC) as illustrated in figure 4.8.
Requirement occured Material Requirement Employee Requirement captured Procurement Material checkStock() active functions Sales determineMaterial() determineAmount() determineReceiver() business object class Requirement

event/message object class Requirement

XOR Material on stock Material not on stock

Procurement

Material

Material

Order

getFromStock() Material provided Material ordered

orderMaterial()

Figure 4.8. Example for the oEPC structure of the procurement logistics
Material Name Amount on Stock checkStock() getFromStock() orderMaterial() 1..1

0..* Order Date Status g Amount Status determineMaterial() determineAmount() Order Item

Requirement

0..*

1..1

Employee

determineReceiver()

Figure 4.9. Class diagram for the procurement logistics example 39

A possible critique of their approach is about the classes participating in the message exchange. Because in oEPC the message exchange is represented between classes (unlike collaboration diagram where the message exchange is between objects), the diagram cannot express whether the same objects or different objects appear for the participating classes. In the above example after the requirement captured event, an object of class material receives the message. After the object executes the method checkStock(), the question is whether the object sends the resulting message to itself or to another object of class material. This is not explicitly shown here, while it can be clearly shown in a collaboration diagram.

40

Conclusion
The comparison between EPC and UML activity diagrams shows that even if both methods were developed in different contexts, they are usable for modeling business processes. However as we can see from the comparison, the EPC covers more aspects such as a detailed description of business organization units together with their respective functions as well as information and material resources used in each function. These essential relationships are not explicitly shown in activity diagrams. Instead we need to derive from other elements such as object flow or even we need to model these aspects in other diagrams of the UML. However the EPC is sometimes imprecise or even ambiguous when we analyze its process, but this problem has been addressed by utilizing transformation approach to Petri net which can be analyzed to prove the correctness of the EPC. Based on the comparison we can also see that there are a lot of concepts which are common to both EPC and activity diagrams. These common concepts make it possible to translate both diagrams back and forth between the different notations. Nevertheless there are also some basic different concepts which has no correspondence in the other one. This raises problems such as information loss when translating from EPC to activity diagrams due to less aspects of activity diagrams and loss of details such as iteration and object identity when translating from activity diagrams to EPC. Because of the problems of translating between EPC and activity diagram the two approaches - the object-oriented paradigm which is closer to information technology and the process-oriented one which is closer to business aspects (organization, information and material, function) need to be brought closer. A semi-formal proposed solution for this is the object-oriented event-driven process chain (EPC). This integrated approach is a promising candidate for solving these aspects in one unified method.

41

Bibliography
[BRJ99a] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual. Addison Wesley, 1999. [BRJ99b] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. Addison Wesley, 1999. [CKL98] T. Curran, G. Keller, A. Ladd. SAP R/3 Business Blueprint. Understanding the business process reference model. Prentice Hall, 1998. [FOW97] M. Fowler. UML Distilled. Addison Wesley, 1997. [Gro99] Object Management Group. OMG Unified Modeling Language Specification (draft). OMG, 1999. [Haa01] C. Haasis. Referenzmodelle fr Standardsoftware: Anforderung, Nutzung und methodische Grundlagen. Diplomarbeit, Fachbereich Informatik Universitt Hamburg, 2001. [KNS91] G. Keller, M. Nttgens, A.-W. Scheer. Semantische Prozessmodellierung auf der Grundlage Ereignisgesteuerte Prozessketten (EPK). Verffentlichung des Institut fr Wirtschaftsinformatik, Paper 089, Saarbrcken, 1991 (http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps). [KT98] G. Keller, T. Teufel. SAP R/3 prozessorientiert anwenden. Addison Wesley, 1998. [LA98a] P. Loos, T. Allweyer. Process Orientation and Object Orientation An Approach for Integrating UML and Event-Driven Process Chain (EPC). Publication of the Institut fr Wirtschaftsinformatik, Paper 144, Saarbrcken, 1998 (http://www.iwi.uni-sb.de/iwi-hefte/iwih144.ps). [LA98b] P. Loos, T. Allweyer. UML und EPK - auf dem Weg zur Unified Process Language? - IDS Prof. Scheer GmbH, Saarbrcken, 1998. [LSW97] P. Langner, C. Schneider, J. Wehler. Ereignisprozessketten und Petri-Netze. Fachbereich Informatik Universitt Hamburg FBI-HH-B-196/97, 1997. [NFZ98] M. Nttgens, T. Feld, V. Zimmermann. Business Process Modeling with EPC and UML Transformation or Integration? Publication of the Institut fr Wirtschaftsinformatik, Saarbrcken, 1998. [Sch94] A.-W. Scheer. Business Process Engineering. Reference Models for Industrial Enterprises. Springer-Verlag, 1995. [SNZ97] A.-W. Scheer, M. Nttgens, V. Zimmermann. Objektorientierte Ereignisgesteuerte Prozesskette (oEPK) Methode und Anwendung. Verffentlichung des Institut fr Wirtschaftsinformatik, Paper 141, Saarbrcken, 1997 (http://www.iwi.uni-sb.de/iwi-hefte/heft141.ps).

42