a comparison of event-driven process chains and uml ...€¦ · an additional view, thus forming...
TRANSCRIPT
Technische Universität Hamburg-HarburgArbeitsbereich Softwaresysteme
A Comparison of Event-driven ProcessChains and UML Activity Diagram for
Denoting Business Processes
Project Work
submitted byFerdian (15986)
Information and Communication SystemsMasters Program
Supervisors:Prof. Dr. J.W. Schmidt
Dipl-Inform. Axel [email protected]
April 1st, 2001
ii
Contents
Figures iii
1. Introduction 4
2. Event-driven Process Chains (EPC) 62.1. The Architecture of Integrated Information System (ARIS) 6
2.1.1. Descriptive Views 62.1.2. Descriptive Levels 82.1.3. Description Methods 9
2.1.3.1. The Function View: Function Tree 102.1.3.2. The Organization View: Organizational Structure 102.1.3.3. The Data View: Entity-Relationship Model 102.1.3.4. The Control View: EPC 11
2.2. EPC Notation 112.3. Formal Description of EPC 15
3. UML Activity Diagram 183.1. The Unified Modeling Language (UML) 18
3.1.1. Architectural Views 183.1.2. UML Diagrams 19
3.1.2.1. Structural Diagrams 203.1.2.2. Behavioral Diagrams 21
3.2. Activity Diagram Notation 233.3. Usage of Activity Diagrams 27
4. Comparison, Translation, and Integration Approach between EPC and UMLActivity Diagram 284.1. Comparison between EPC and UML Activity Diagram 28
4.1.1. Context 284.1.2. Exactness/Ambiguity 294.1.3. Notation/Terminology 31
4.2. Translation between EPC and UML Activity Diagram 334.3. The Integration Approach: The Object-EPC (oEPC) 35
4.3.1. Motivation for Integration 354.3.2. Modeling Business Objects 364.3.3. Modeling Business Processes 37
Conclusion 41Bibliography 42
iii
Figures
2.1. Business process and ARIS views 72.2. ARIS views of the process model 82.3. ARIS descriptive levels 92.4. ARIS description methods in the requirements definition level 112.5. Elements used in EPC diagram 112.6. Use of process paths to show the connection from EPC1 to EPC2 122.7. Branch and merge in EPC 132.8. Fork and join in EPC 132.9. Inclusive OR connectors in EPC 142.10. Forbidden connections in EPC 142.11. Example of an EPC diagram showing an excerpt from procurement logistics 153.1. Modeling a system’s architecture 193.2. Diagrams of the UML and their connections 223.3. Elements of activity diagram 233.4. Branch and merge in activity diagrams 243.5. Fork and join in activity diagrams 253.6. Iteration and dynamic concurrency 253.7. Example of an activity diagram showing an excerpt from procurement logistics 264.1. Two events arriving at one connector 304.2. Example of notational correspondences in EPC and UML Activity Diagram 314.3. Summary of comparison between EPC and UML Activity Diagram 334.4. The branch/fork solution for the elementary or-connector 344.5. Model of a business object with events 374.6. Basic model of an event-based message 384.7. Service-control relationship as encapsulated control flow 384.8. Example for the oEPC structure of the procurement logistics 394.9. Class diagram for the procurement logistics example 39
4
Chapter 1
Introduction
In the world where business is much more competitive and the customer power is gainingits determining force, the companies has no choice but to be more responsive to changes inthe market. These changing market dynamics are compelling many enterprises to rethinkboth their organizational structure and the use of technology [CKL98]. In the past,‘economies of scale’ – that is, the reduction of costs by increasing output – producedbenefits by offering standardized products to stable and large consumer markets. Theinformation 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 survivein a very competitive market, the enterprises must focus on creating value for customersand adopt business-process orientation to reorganize their business processes intoadaptable corporate structures. The essential prerequisite for optimizing business processesis an integrated information system. Thus the companies must integrate informationtechnology to reengineer the whole processes to improve their effectiveness.
There have been many approaches to model the structure of an enterprise in whichbusiness processes are to be reorganized [KT98]. One of the frameworks is theArchitecture of Integrated Information System (ARIS). In research as well as in practice,the ARIS is accepted as a standard framework for business process engineering. Themethod of Event-driven Process Chain (EPC) [KNS91] has been developed within theframework of ARIS and is used by many companies for modeling, analyzing, andredesigning business processes. The resulting EPC models are used as a starting point forthe development of information systems.
On the other hand, the development of information technology has driven the object-oriented paradigm to be used in modeling, analyzing and designing the enterpriseinformation system. The Unified Modeling Language (UML) is a common standard forobject-oriented modeling and is derived from a shared set of commonly accepted conceptswhich have successfully been proven in the modeling of software systems [NFZ98].However, the object-oriented methods were used to cover the implementation aspects, notthe business processes. The developers of UML realized the need to extend UML’scapability to model business processes, therefore diagrams like use cases and activitydiagrams are incorporated into the UML.
The need of an integrated view of business processes as well as information system as awhole makes the business-oriented view of EPC and IT-oriented view of UML converge. Itis therefore required that both process- and object-oriented modeling of an enterprise beintegrated. With this approach, all the aspects of a company’s business processes andinformation systems should be able to be covered in a unified method.
5
Chapter 2 discusses briefly the ARIS framework with its descriptive views, levels and themethods used. Within this framework the EPC is used to model the business processes.The notation of EPC symbols is explained together with each symbol’s terminology. SinceEPC is a ‘de facto’ standard but not formally developed, an attempt to give formaldescription to EPC will be described in the last part of this chapter. The reader who is notinterested in this formal description can skip this part.
Chapter 3 discusses the architectural views of UML and explains briefly the diagrams usedin UML to describe static and dynamic aspects of a system. Since a process is consideredas dynamic behavior of a system, the activity diagram based on state machine is used tomodel processes as well as operations. The notations used in activity diagrams is describedand also when to use them.
Chapter 4 compares the EPC and activity diagrams to determine the correspondences anddifferences. Based on the identified correspondences, an informal translation procedurebetween them is described. Because of the complementary differences between them, thelast part of the chapter argues for an integrated approach, as exemplified by a semi-formalproposal by Scheer et al. [SNZ97] called the object-EPC. Finally conclusion summarizesthe results of this work.
6
Chapter 2
Event-driven Process Chains (EPC)
Event-driven Process Chains (EPC) is a method developed by Scheer, Keller and Nüttgenswithin the framework of Architecture of Integrated Information System (ARIS) to modelbusiness processes [KNS91]. It is widely used in commercial projects from the field ofmanagement information systems. Before we go through the EPC first we take a brief lookat the ARIS concept.
2.1. The Architecture of Integrated Information System (ARIS)
The ARIS concept involves dividing complex business process into separate views andintegrating these views to form a complete view of the whole business process. A startingpoint to form these views is to understand and model a business process. The processcontains operational activities connected in chronological sequence as well as otherresources such as the human resources/organizations, information resources and the datathat contain the information itself. This high complexity of interdependencies among thecomponents in a business process is the driving force for breaking down the problem intodifferent views. This dismantling procedure is based on the principle that components withhigh interdependency are grouped in one view and components with low interdependencyare separated into different views. The result is that there are three views focusing on theirhigh dependency inside the view, and the relationships between these views are restored inan additional view, thus forming four descriptive views in the EPC.
A further partitioning inside the views is attained via the descriptive levels. Thesedescriptive 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 toinformation technology. The descriptive levels cover areas starting from business tasks tothe technical aspects of system implementation. They consist of requirement definition,design specification, and implementation description. Each description level within eachview is supported by a description method.
2.1.1. Descriptive Views
As already mentioned above, the concept of ARIS lies on reducing complexity intodifferent views. Figure 2.1 illustrates an excerpt from a business process, which serves toillustrate the concept of views. The components taking part and their interrelationships tobe described in a computer-supported business process include processes,activities/functions, events, statuses, users, organizational units, and informationtechnology resources. A simultaneous look at all the effects on all components of theprocess when designing an information system would severely complicate the model andthus prevent direct handling of individual aspects.
7
Orderconfirmation
Customerorder
received
Orderconfirmation
prepared
Ordertracking
Productionplanning
Customer Article
Capacities ...
UserDepartment ......
Data view
Function view
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 representdiscrete design aspects and can be handled independently, which simplifies the task. Thecriteria for separating into individual views are based on the fact that relationships betweencomponents in the same view are relatively strong and relationships between componentsof 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 objectsthat are represented by data. Statuses such as “customer status” and “article status” arealso represented by data.
• Function view. The function view contains the description of the activities to beperformed, the enumeration of the individual subfunctions that belong to the overallrelationship, and relationships that exist between the functions.
• Organization view. The structure and the relationships between users and organizationunits constitute the organization view. Users are assigned to organization units, whichare formed according to criteria such as the same function or the same work object.
• Resource view. Information technology components constitute the fourth descriptiveobject, that is, the resource view. However this view is significant for businessconsiderations only insofar as it results in general conditions for describing othercomponents that are more strongly geared toward business.
The relationships between the views as expressed by the arrows in the process model infigure 2.2 are restored by introducing a control view. The control view is an essentialARIS component that distinguishes it from other architectures such as Computer IntegratedManufacturing – Open System Architecture (CIM-OSA), Semantic Object Model (SOM),or Object-Oriented Information Engineering (OOIE) [KT98]. This process results in thefour ARIS views as shown in Figure 2.2.
8
Organization
ControlData Function
ARIS
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 descriptivelevels takes place within the ARIS concept. The transformation of business problem intoan integrated information system solution is achieved in the ARIS approach through fivephases:• 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 alldescription views of ARIS. The result is the representation of relationships betweenorganization 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. Thisaffects on using semi-formal description method to represent the description of thebusiness problem.
• In the second phase the individual views are modeled by requirements definition. Therequirements definition has to be supported in a formalized language so that it can beused as a starting point for a translation into information technology withoutconsidering the aspects of implementation.
• The third phase involves design specification. In this phase the concepts of therequirements definition are transferred to the categories of Electronic-Data-Processing(EDP) and adapted to the request of the implementation tools. This process is not aconcrete tool and is independent of technical aspects. The transformation betweenrequirements definition and design specification has to be arranged so thatmodifications in the design specification do not affect the requirements definition.
• In the fourth phase the implementation description transfers the design specification toconcrete hardware and software components. In this phase the physical link to theinformation technology is established.
• The fifth phase is the information technology realization. It contains the functions thatsupport the operation and maintenance of the implemented system.
9
The descriptive levels are characterized by different update cycles. The requirementsdefinition level is relatively longer and constant compared to other levels. It is particularlysignificant because it possesses the longest lifecycle and through their close affinity to thedescription of the business problem they also document the heaviest use of the informationsystem. On the other hand the implementation description level is subject to ongoingrevisions because of the fast innovation cycle of the information technology such as thedevelopment of new database systems, networks, hardware, etc.
Operationalbusiness problem
RequirementDefinition
DesignSpecification
ImplementationDescription
Require-ments definition
Design Specification
Implementation Description
RequirementDefinition
DesignSpecification
ImplementationDescription
RequirementDefinition
DesignSpecification
ImplementationDescription
DataView
ControlView
Function View
OrganizationView
Requirements definition(semantic models)
Design specification
Implementationdescription
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 individualdescriptive levels. This additional partitioning enables to take different perspectives in eachview and to adjust the modeling parallel to the process in detail. Figure 2.3 shows differentviews and the partitioning in descriptive levels.
2.1.3. Description Methods
The ARIS architecture’s descriptive views and levels are fixed. What is necessary then isto select and portray suitable description methods for each component. The criteria forselecting 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 technologyA more detailed description about this is available in [Sch94]. In this paper only methodsin the requirement definitions are introduced, to show the position of EPC in the ARISframework and the relationship between EPC as the most important method to portraybusiness processes and other description methods used in the ARIS concept.
10
2.1.3.1. The Function View: Function Tree
In the function view, there is a function for each process, which describes what should bedone. 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 bythe description methods of hierarchy diagrams or function trees. Hierarchy diagrams areself-explanatory, as shown in the following diagram.
Functions are represented by round-cornered boxes and can be divided across severalhierarchy 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. Thesefunctions are called elementary functions. There are no definitive criteria for determiningthe functional structure, although some possible breakdown criteria include the division ofsubfunctions according to their approximate temporal sequence, the fact that they processthe 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 asenterprises, these structures must be broken down into manageable units. The rulesrequired for this process are referred to as “organization”, and the resulting manageableunits are called “organizational units”. If the structuring process relates to the company asa static system, the set of rules designed for this purpose is referred to as structuralorganization.
The principal task of the organizational structure is coordinating as inexpensively aspossible the communication needs that arise from breaking down a complex unit.Generally there is no “optimal” organizational structure, depending on the specificity oftask and change of problems of the task. Normally the type of organizational structure ishierarchical, but if the rate of change is high the “self-organizing” network is moresuitable.
2.1.3.3. The Data View: Entity-Relationship Model
Whereas the function or organization view requires one concept, namely the function ororganization units, many concepts are used within the data view, such as entity types,relationship types, attributes, domains, etc. The description of the requirement definition ofthe data view is therefore highly demanding, since it plays an important role in informationsystem development. The easier it is to use higher programming languages to createsupplemental functions in existing programming systems, the more important it becomes toprovide these functions with the proper data structures.
To provide the data view with a description method, Chen’s entity-relationship (ER)model was adopted into the ARIS framework [Sch94], since it was the most widespreaddesigning method in the area of data modeling. The ER model used in ARIS framework isthe extended one [Sch94] that introduces new design rules for supporting data structuringsuch as classification, generalization, aggregation, and grouping.
11
2.1.3.4. The Control View: EPC
The control view links functions, organization and data. It unites the design results, whichwere initially developed separately for reasons of simplification. The functions, events,information resources, and organization units are connected into a common context by theprocess flow. The resulting model is the complete EPC. So the EPC serves as a descriptionmethod 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 portrayingbusiness information system while at the same time incorporating other important featuressuch as functions, data, organizational structure and information resources as alreadydescribed before. This makes EPC a widely acceptable standard to denote businessprocesses.
Control Flow
XOR OR AND
Event FunctionInformation/
MaterialOrganization Unit Process Path
Logical Connectors Information FlowOrganization Unit
Assignment
Figure 2.5. Elements used in EPC diagram (from [KT98])
12
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 ofevents are “requirement captured”, “material on stock”, etc. In the EPC graph an eventis represented as hexagon.
• Function. Functions are active elements in EPC. They model the tasks or activitieswithin the company. Functions describe transformations from an initial state to aresulting state. In case different resulting states can occur, the selection of therespective resulting state can be modeled explicitly as a decision function using logicalconnectors. Functions can be refined into another EPC. In this case it is calledhierarchical function. Examples of functions are “capture requirement”, “checkmaterial on stock”, etc. In the EPC graph a function is represented as roundedrectangle.
• Organization unit. Organization units determine which person or organization withinthe structure of an enterprise is responsible for a specific function. Examples are “salesdepartment”, “sales manager”, “procurement manager”, etc. It is represented as anellipse with a vertical line.
• Information, material, or resource object. In the EPC the information, material, orresource 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 dataproduced by a function. Examples are “material”, “order”, etc. In the EPC graph suchan object is represented as rectangle.
• Process path. Process paths serve as navigation aid in the EPC. They show theconnection 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 fromprocess 1 to process 2 with a process path at the end of process 1 pointing to process 2and in the beginning of process 2 referring to process 1. A process path is representedin EPC as a “function and event” symbol (function symbol in front of event symbol).
Process 2
event N
Process 1
event 1
[previous functionsand events in EPC1]
[next functions andevents in EPC2]
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 logicalconnectors creating chronological sequence and logical interdependencies betweenthem. A control flow is represented as a dashed arrow.
• Logical connector. In the EPC the logical relationships between elements in thecontrol flow, that is, events and functions, are described by logical connectors. Withthe help of logical connectors it is possible to split the control flow from one flow to
13
two or more flows and to synchronize the control flow from two or more flows to oneflow. 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 flowand two or more outgoing control flows. When the condition is fulfilled, a branchactivates 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 incomingcontrol flows and one outgoing control flow. A merge synchronizes an activatedand the deactivated alternatives. The control will then be passed to the next elementafter the merge. A branch in the EPC is represented by an opening ‘XOR’, whereasa merge is represented as a closing ‘XOR’ connectors.
If function F1 completes, either events E1 or E2 occur If either events E1 or E2 occur, function F1 starts
XOR
E1
F1
E2
XOR
E1
F1
E2
Figure 2.7. Branch and merge in EPC
Fork/Join. Fork and join correspond to activating all paths in the control flowconcurrently. A fork may have one incoming control flow and two or moreoutgoing control flows. When the condition is fulfilled, a fork activates all of theoutgoing control flows in parallel. A join may have two or more incoming controlflows and one outgoing control flow. A join synchronizes all activated incomingcontrol flows. In the EPC diagram how the concurrency achieved is not a matter. Inreality the concurrency can be achieved by true parallelism or by virtualconcurrency achieved by interleaving. A fork in the EPC is represented by anopening ‘AND’, whereas a join is represented as a closing ‘AND’ connectors.
If function F1 completes, both events E1 and E2 occur If both events E1 and E2 occur, function F1 starts
AND
E1
F1
E2
AND
E1
F1
E2
Figure 2.8. Fork and join in EPC
‘OR’. An ‘OR’ relationship corresponds to activating one or more paths amongcontrol flows. An opening ‘OR’ connector may have one incoming control flowand two or more outgoing control flows. When the condition is fulfilled, anopening ‘OR’ connector activates one or more control flows and deactivates therest of them. The counterpart of this is the closing ‘OR’ connector. When at least
14
one of the incoming control flows is activated, the closing ‘OR’ connector will passthe control to the next element after it.
If function F1 completes, events E1 or E2 or both occur If events E1 or E2 or both occur, function F1 starts
OR
E1
F1
E2
OR
E1
F1
E2
Figure 2.9. Inclusive OR connectors in EPC
• Information flow. Information flows show the connection between functions and inputor output data, upon which the function reads, changes or writes.
• Organization unit assignment. Organization unit assignments show the connectionbetween 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 tomodel a business process using EPC. The following are some hints and constraints inconnecting these elements to form an EPC diagram (a formal description of syntacticalcorrectness 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 withevents, not with functions.
• If the graphs have process paths that link them, in the source graph the process pathshould be put at the end of the graph after the end event, and in the target graph theprocess 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 theother 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 onlyby an ‘AND’ connector, not an ‘OR’ or ‘XOR’ connectors.
OR
E1
F1 F2
XOR
E1
F1 F2
Figure 2.10. Forbidden connections in EPC
15
• A function is an active element. This means that it can be used to make decisions andto trigger parallel activities. Therefore any of the logical connectors can follow afunction.
• Logical connectors should match, meaning that an opening ‘XOR’ serving as a branchshould 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 wouldhave no meaning or contribution to the whole process.
Requirementoccured
Capturerequirement
Requirementcaptured
Check materialon stock
Materialon stock
Materialnot on stock
Get materialfrom stock
Ordermaterial
Materialprovided
Materialordered
XOR
Material
Employee
Material
Sales
Procurement
Material Order
ProcurementProcurement
Function
Event
Organizationunit
Organization unitassignment
Informationflow
Controlflow
Information /resource
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 EPCmodel can be described as a graph-based model consisting of nodes and edges. The usedelements, that is, node elements and edge elements will first be described using the graphtheory. After that, the syntax of EPC will be defined, and the correct properties that mustbe fulfilled will be described based on the graph theory. Examples of nodes are events andfunctions; examples of edges are control flow and information flow.
16
In this formal description of EPC only the nodes and edges of control flow will bediscussed. This is due to the fact that control flow is the most important flow in EPCrepresenting the business process. Another reason is that in the EPC the other two edgeelements, that is, information flow and organization unit assignment, are only simplegraphs (the organization unit assignment only connects an organization unit to a functionand the information flow connects an information material to a function).
We first recapitulate some basic ideas from the graph theory in order to provide descriptionfor 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 functionN : A → V × V,
which assign to each a ∈ A the ordered pairN(a) ∈ V × V,
which consists of the input node and the output node of the edge a. In this definitionboth parallel edges and loops are allowed. In the following we will regard only directedgraphs, 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 loopsare allowed. The edges of a simple graph are determined by the specification of theinitial and terminal vertex. Therefore we use the notation G = (V, A) with a number ofnodes V and an irreflexive relation A ⊂ V × V for the designation of a simple directedgraph 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 sequenceof 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 twonodes 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 followingproperties: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 pathsL = set of binary connectors of type “AND”, “OR”, “XOR”.
2. The set of edges A is an antisymmetric relation on VxV with the followingcharacteristics: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, wecall a and b connector-connected. No event e ∈ E must be connector-connected to
17
an event f ∈ E. No function of process path f ∈ (F ∪ P) must be connector-connected to another function of process path g ∈ (F ∪ P).
b. The predecessors of a node belong to one type of node, and likewise all successorsbelong 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* ≤ 1for each function f ∈ F,
*f = f* = 1and for each process path p ∈ P,
*p + p* = 14. 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.
18
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 modelinglanguage in the area of software development. It was developed by Booch, Rumbaugh, andJacobson and was later accepted as standard in object-oriented modeling by the ObjectManagement Group (OMG). The current version is UML 1.3 [BRJ99a]. Unlike othertechniques in the UML, the activity diagram doesn’t originate from the previous works ofthe three amigos, instead it combines the ideas from several techniques: the event diagramof Jim Odell, SDL state modeling techniques, and Petri nets [Fow97]. It is incorporated toextend 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 thatthe model of the system is built in a precise, unambiguous, and complete way. The UMLuses graphs to visualize the model so that developers can have a common interpretationwhen exchanging ideas. The UML is not a visual programming language, but tools canprovide code generators from UML into a variety of programming languages. The UML isalso the tool to document the project during software development. One important point isthat UML is a language to model a system. It is process independent, which means that theuser 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 thesystem be viewed from a number of perspectives. Different participants in the softwaredevelopment project such as end users, analysts, developers, system integrators, testers,technical writers, and project managers look at the system in different ways at differenttimes over the project’s life. A system’s architecture is perhaps the most important artifactthat can be used to manage these different viewpoints and so control the development ofthe system.
As figure 3.1 illustrates, the architecture of a software system can be described by fiveviews. Each view is a projection into the organization and structure of the system, focusedon 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 doesnot really specify the organization of a software system, but rather specifies the forcesthat shape the system’s architecture.
19
• Design view. This view of a system encompasses the classes, interfaces, andcollaborations that form the vocabulary of the problem and its solution. This viewprimarily supports the functional requirements of the system, meaning the services thatthe system should provide to its end users.
• Process view. This view of a system encompasses the threads and processes that formthe system’s concurrency and synchronization mechanism. This view primarilyaddresses the performance, scalability, and throughput of the system.
• Implementation view. This view of a system encompasses the components and filesthat are used to assemble and release the physical system. This view primarilyaddresses the configuration management of the system’s releases, made up ofsomewhat independent components and files that can be assembled in various ways toproduce a running system.
• Deployment view. This view of a system encompasses the nodes that form thesystem’s hardware topology on which the system executes. This view primarilyaddresses the distribution, delivery, and installation of the parts that make up thephysical system.
Design View Implementation View
Process View Deployment View
Use CaseView
system assemblyconfiguration management
system topologydistributiondeliveryinstallation
vocabularyfunctionality
behavior
performancescalability
throughput
Figure 3.1. Modeling a system’s architecture (from [BRJ99b])
In each of these views there are UML diagrams described later that cover the static anddynamic aspects of the system. The use case view is primarily captured in use casediagrams. 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 indeployment diagrams. In all these views the dynamic aspects are captured in behavioraldiagrams 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 systemcan focus on the issues of the system’s architecture that most concern them. These viewsalso interact with one another – nodes in the deployment view hold components in theimplementation 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 amust when solving problems in software development, but they are mostly likely to beused in the analysis and design. Indeed the UML provides extensibility so that we can
20
define other stereotypes, but these diagrams are usually sufficient to cover all aspects insoftware system. There are eight diagrams available, grouped into structural diagrams thatdeal with static aspect of a system, and behavioral diagrams that deal with dynamic aspectof a system.
3.1.2.1. Structural Diagrams
Structural diagrams in the UML serve to visualize, specify, construct, and document thestatic aspects of a system (both software and hardware systems). They describe the kindsof objects important to a system and to its implementation, as well as the relationshipsamong the objects. The static structures in software development system are classes,interfaces, collaborations, objects, components, and nodes. The UML diagrams that handlethese structures are:• Class Diagram.
The class diagram is the basic yet most important diagram in the UML. It is the centralpart in modeling object-oriented systems. A class diagram shows a set of classestogether with their relationships. There are some important terms and concepts relatedto 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 thatare part of our vocabulary. For example “wall” can be considered a class. Everyclass must have a name that distinguishes it from other classes.
Attribute. An attribute is a named property of a class that describes a range ofvalues that instances of a class may hold. As an example, some attributes of theclass “wall” may be color, height, thickness, etc. At a given moment, an object of aclass will have specific values for every attribute of its class.
Operation. An operation is the implementation of a service that can be requestedfrom any object of the class to affect its behavior. In our wall example theoperations might be to paint the wall.
Visibility. The visibility level determines whether the attributes and operations canbe accessed from outside. There are three visibility levels: private, protected, andpublic.
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 sometimescalled an “is-a-kind-of” relationship.
Aggregation. An aggregation is a relationship in which one class represents largerthing 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 therelationship, 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 softwarecomponents, including source codes, binary codes, run-time executables, and softwaredocuments. Components may also be connected to components by physical
21
containment representing composition relationship. A component diagram is composedfrom 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 interfaceis a list of operations supported by a piece of software. Each component embodiesthe implementation of certain classes from the system design. In the UML acomponent is drawn as a rectangle with two small rectangles on its left side. It maybe 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. Acomponent package in UML is represented as a directory symbol.
• Deployment DiagramThe deployment diagram and component diagram are two diagrams used in UML tomodel physical aspects of an object-oriented system. A deployment diagram shows theconfiguration 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 beencompiled) do not appear in these diagrams, they should be shown in a componentdiagram. The main element in the deployment diagram is node. A node is a physicalobject (usually a piece of hardware) that represents a processing resource, generally,having at least memory and processing capability. It is drawn as three-dimensionalcube. Components can be drawn inside together with the dependencies. An associationbetween 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 thedynamic aspects of a system. The dynamic behavior describes the history of objects overtime and the communication among them. In a software system these are the things such asthe flow of messages over time and the physical movement of components across anetwork. 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. Itis the basic diagram to understand the system from the end user’s perspective.According to [Fow97], use cases used to be described using sentences, then Jacobsonintroduced 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 currentsystem.
Use case. Use cases represent what the system do with respect to the user. Theydescribe a scenario, in which each sequence in the scenario represents theinteraction between the user and the system. A use case has a name and a textualdescription.
Association. Association is a bi-directional relationship between a user and a usecase or between use cases. In addition to association between use cases twostereotypes are defined:o Stereotype extends means that the extended use case is a variation to the other
use case.
22
o Stereotype includes means that the included use case is used together by two ormore use cases.
Generalization. Generalization between use cases means that a general use casehas 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. Thediagram shows an example of objects and the messages that are passed between theseobjects. 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 attop of the graph, and a lifeline is shown to represent the object’s life duringinteraction. Each message is represented by an arrow between the lifelines of twoobjects.
Collaboration diagram emphasizes the structural organization of the objects thatsend 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 overtime. The difference between them is that an interaction diagram is aimed at showinginteraction of objects while a state diagram is aimed at describing all possible states aparticular object can get into and how the object’s state changes as a result of eventsreaching the object. State diagrams are normally drawn for a single class to show thelifetime 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 DiagramActivity diagram is just like a state diagram and is intended to model workflows andprocesses. It will be described later in more detail.
Figure 3.2. Diagrams of the UML and their connections (from [LA98a])
23
3.2. Activity Diagram Notation
An activity diagram is a special case of state diagram in which all or most of the states areactivity states and in which all or most of the transitions are triggered by completion of theactivities in the source state. The entire activity diagram is attached through the model to aclass, an operation or to a use case. The purpose of this diagram is to focus on flows drivenby internal processing as opposed to external events. Figure 3.3 shows the elements used inactivity 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. Activitiesultimately result in some action, which is made up of executable atomic computationsthat 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. Actionstates cannot be decomposed. The atomic property of action states means that eventsmay occur, but the work of the action state is not interrupted. The work of action stateis 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 otheractivity diagrams. They are not atomic, meaning that they may be interrupted andgenerally considered to take some duration to complete. With this definition, we cansay 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 otheractivity states and action states. There is no difference in notation between activitystates and action states, except that an activity state may have an entry and exit actionsas well as submachine specifications. Activity states and action states are representedin the activity graph using a lozenge shape (a symbol with horizontal top and bottomand convex sides).In addition to activity states and action states, two special states are defined in activitydiagram to mark the beginning and end of control flow. Those are the start staterepresented in activity graph as a solid ball, and the stop state represented as solid ballinside a circle. Nevertheless sometimes it is not necessary to mark the beginning or endof control flow when the start and end activities are clear or when the control flow isintended to continue indefinitely.
24
• Transitions.When the action or activity of a state completes, the flow of control passes immediatelyto the next action or activity state. This flow is specified using transitions to show thepath from one action or activity state to the next action or activity state. Once the actionof the source state completes, if there is any exit action then the state’s exit action isexecuted, and next the control passes to the target action, execute its entry action (ifany), its action, and so on. In the activity graph this transition is represented as a simpledirected line.
• Branches and Merges.In many cases of control flow we need to make some kind of decision between two ormore choices. This is accomplished in the state machine by a branch, which specifiesexclusive alternate paths taken based on a Boolean expression, which means that flowof control will pass to either one of the outgoing paths from the branch. In the activitygraph this branch is represented as a diamond. A branch may have one incomingtransition and two or more outgoing ones. On each outgoing transition, a Booleanexpression 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 beambiguous), but they must cover all possible choices (otherwise the flow would freezein the branch). As a convenience, we can use the keyword guard ‘else’ to one outgoingtransition; the path taken if no other guard expression is true.Multiple paths coming from the same branch can be merged into one transition. It isrepresented as multiple transitions merging into a diamond.
A1 A2
[Condition1]
[else]
If the guard expression in Condition1 is fulfilled,activity A1 is executed, otherwise A2 is executed
Branch
Merge
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 activitydiagrams to describe parallel activities. Parallelism is often encountered whenmodeling business processes or multitasking/multithreading software operations thatinvolve concurrencies among activities. In the UML, we use a synchronization bar tospecify the forking and joining of these parallel flows of control. A synchronization baris rendered as a thick horizontal or vertical line.A fork represents the splitting of a single flow of control into two or more concurrentflows of control. A fork may have one incoming transition and two or more outgoingtransitions, each of which represents an independent flow of control. Below the fork,the activities associated with each of these paths continue in parallel. Conceptually, theactivities of each of these flows are truly concurrent, although in reality these flows
25
may be either truly concurrent or sequential yet interleaved giving the illusion ofconcurrency.
A1
A2 A3 A4
Fork
Join
[Condition1]
As soon as activity A1 finishes, activities A2 and A3 are executedconcurrently 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. Ajoin may have two or more incoming transitions and one outgoing transition. Above thejoin, 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 flowshave 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 belowthe guard would only be activated or executed when the condition of the guard isfulfilled. Again care must be taken so that the flow of control will not be stuck in thefork.
• Iterations.Another form of parallel activities can be performed as iterations. This is accomplishedusing what is called multiple trigger – the same activity is triggered repeatedly. We canindicate this trigger by attaching a ‘*’ (multiplicity sign) to the transition that drives theactivity and specifying it with a guard, for example [for each item on]. Thecomplement of this is usually a synchronization bar down in the diagram that brings theparallel threads together. This iteration can also be represented as an activity withdynamic concurrency, meaning that it is executed multiple times where the number ofconcurrent activities depends on some arguments.
Check itemon stock
* [for each itemon order]
Check itemon stock
*
Figure 3.6. Iteration and dynamic concurrency
26
• Swimlanes.Activity diagrams tell us what happens, but they do not tell us who does what. Insoftware system this means that the diagram doesn’t convey which class is responsiblefor each activity. In business modeling this means that the diagram doesn’t conveywhich department or person/actor is responsible for each activity. Therefore it is usefulmainly in modeling business processes to partition the activity states on an activitydiagram into groups, each group representing the business organization responsible forthose activities. In the UML, each group is called a swimlane because visually eachgroup is divided from its neighbor by a vertical solid line.Each swimlane has a name unique within its diagram. A swimlane really has no deepsemantics, except that it may represent some real-world entity. Each swimlanerepresents a high-level responsibility for part of the overall activity of an activitydiagram, and each swimlane may eventually be implemented by one or more classes.In an activity diagram partitioned into swimlanes, every activity belongs to exactly oneswimlane, but transitions may cross lines.
• Object Flow.Objects may be involved in the flow of control associated with an activity diagram. Wecan specify the things that are involved in an activity diagram by placing these objectsin 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 calledan 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 alsoshow how its role, state and attribute value change. As shown in the figure, werepresent the state of an object by naming its state in brackets below the object’s name.Similarly, we can represent the value of an object’s attributes by rendering them in acompartment below the object’s name.
CaptureRequirement
CheckStock
ProvideMaterial
OrderMaterial
o:Requirement[captured]
o:Requirement[checked]
Sales Procurement
StartSate
Activity
Object
Swimlane
[on stock]
ObjectFlow
Transition
StopState
Figure 3.7. Example of an activity diagram showing an excerpt from procurement logistics
27
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 theirgreat 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 aresuitable 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 aclass. In this case we are only interested in understanding what actions need to takeplace and what the behavioral dependencies are. Using an activity diagram to model anoperation is simply like using it as a flowchart that supports concurrencies amongthreads in an operation.
• Modeling a workflow.Activity diagrams are best suited to model workflows across use cases that involvemany actors or business organizations. In this case we focus on activities as seen by theactors that collaborate with the system.
28
Chapter 4
Comparison, Translation, and IntegrationApproach between EPC and UMLActivity Diagram
We have already discussed the Event-driven Process Chain (EPC) in chapter two and theUML Activity Diagram in chapter three. In this chapter first we will compare bothdiagrams as the tools to denote business processes. The purpose of comparing bothdiagrams is to show the strengths and weaknesses of each diagram when we use them todenote business processes. After comparing both diagrams the next approach is how wecan translate from one diagram to another. The purpose of this translation procedure is toshow how we can understand the idea of a business process from both diagrams and toillustrate the results from the comparison we made before. As a third and final step, we willintroduce an integration approach. The integration approach chosen here does not meanthat we try to integrate EPC with activity diagrams; instead we show how to bring EPC andUML 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 differencesbetween 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, butboth have different contexts under which they are developed.
• Exactness/Ambiguity. In modeling business processes, it is possible that the EPC orActivity Diagrams that are created would be ambiguous. Examples of this are implicitdecisions, possibility of having blocking, etc. Therefore it is necessary to take a look atthe exactness or ambiguity of the diagrams constructed with EPC or UML ActivityDiagram.
• Notation/Terminology. Both the EPC and UML activity diagrams have similarconcepts – such as fork/join, branch/merge, atomic/extended activity, etc – but they arerepresented using different notation and terminology. Some notation does not have acounterpart in the other diagram. This indicates the semantic differences between them.Therefore we will compare both notations and terminologies to see the correspondenceof 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 denotebusiness processes, they were developed in different contexts. This pragmatic difference
29
comes from the different modeling approaches that drive the EPC and UML. There are twoapproaches to model a system:• Process-oriented modeling.
In process-oriented modeling, the main focus of modeling a system is the processinside the system. A process consists of sequences of events triggeringactivities/functions. The events themselves are the results of other functions apart frominitial events that trigger the whole process. By introducing logical operators, thisevent-driven control structure can be expanded to a complex control flow illustratingrelevant decisions and potential for concurrency that happen in the process. Thisprocess-oriented modeling is the basis for the EPC, which found its way as a standardfor modeling business processes of an enterprise. The basic EPC model can beextended by further semantic components to illustrate the elements participating in theprocess such as information objects and organization units.
• Object-oriented modeling.In object-oriented modeling, the main focus of modeling a system is the objects insidethe system. A system is a bunch of objects that have relationships among them. Theseobjects communicate each other by exchanging messages. An object is a discrete anddifferentiable entity in a system. Each object has properties and exchanges messagesthrough operations. This object-oriented modeling is the basis for UML, which ismainly used in software development such as enterprise information system. Initiallyactivity diagrams are targeted for modeling the dynamics of internal object’s actions.Because of its characteristics similar to flowcharts and its capability to visualizeconcurrent 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 chapter2 by [KT98] based on graph theory. The formal description of EPC can be used to analyzethe syntactical correctness of an EPC diagram. However in practice there are still someproblems regarding the exact meaning of some elements in the EPC. The ambiguities arisefrom the analysis of how elements in an EPC diagram interact in a flow of process (shownas tokens). Those ambiguities are:• Conjunction of start events.
An ambiguity concerning the modeling of start and end events occur in the EPC. It isobvious that nodes without input edges are the start events and similarly nodes withoutoutput edges are the end events. But the interpretation is left to the reader, whichcombination of start and end events he should see as admissible, that is, as seen inreality. 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 timebefore by the first start events. These usually represent communication with externalentity. 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 logicalconnectors to events and functions in the control flow. We know that because an eventcannot 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
30
connectors, especially in the ‘XOR’ and ‘OR’ connectors. Consider the case in figure4.1. In the case of ‘AND’ connector, the function F1 can only start when both eventsE1 and E2 occur. That is clear, the ‘AND’ connector serves to synchronize by waitinguntil both events have occurred. In the case of ‘XOR’ connector, the switching rule ofthe ‘exclusive or’ connector says that if either event E1 or event E2 occurs, thefollowing function F1 can start. One question arises, what does the rule mean, whenboth events occur one after another, for example E1 occurs first then after some timeE2 occurs? Can the function then run twice: The first time after the occurrence of thefirst event, and the second time after the occurrence of the second event? There areseveral interpretations for what the modeler wants to express, when he uses thisconnector:a. When both events occur at the same time, they block the following function, orb. Both events cannot occur at the same time, orc. When the following function starts, then exactly one of both events must have
occurredFor the ‘OR’ connector, the following rule applies: when at least one of the eventsoccurs, the following function can start; when both events occur at the same time, thefunction 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 severalinterpretations 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 notblocked.
AND
E1
F1
E2
XOR
E1
F1
E2
OR
E1
F1
E2
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 forcomplex graphs we need a tool to analyze them. It is possible that even when the graphis semantically correct according to the definition of EPC in chapter 2, still an analysisshows there can be deadlocks when executing the process according to the diagram. Adeadlock 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 endstates. Possible causes of deadlocks are mismatches of logical connectors – especiallyin complex graphs where connectors link to other connectors – and differentinterpretation of logical connectors. For an example an ‘OR’ connector can work eitherin ‘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, adeadlock would happen. This can be solved if the closing ‘OR’ connector ‘knows’ inadvance in which mode the opening ‘OR’ connector works.Another possible problem discovered by graph analysis is looping. A loop may cause aprocess to run forever. This is usually not intended to occur in business processes.
31
These ambiguity problems have been addressed in [LSW97]. They used the Petri netapproach to analyze the problems. The methodology that they present consists oftransforming an EPC diagram into a Petri net and then analyzing it. The Petri netformalism used to analyze it is a variant of colored place-transition Petri net which theycallBoolean Petri net. The semantics of Petri nets are very well-defined and they aredeveloped formally in academic research, therefore the result of the Petri net analysis isvery reliable. They solve the problems by explicitly passing information in the form of aBoolean 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 moredetailed description of the Boolean Petri net and its analysis to prove whether thetransformed EPC is semantically and operatively correct (meaning that there are nodeadlocks and loops when the token of Petri net is passed in the diagram) the reader canrefer to [LSW97].
Since activity diagrams are derived from SDL and Petri net [Fow 97] which has very well-defined 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 betweenthem. These notational correspondences and differences will be discussed here and we willuse the result of these notational comparisons for the translation from EPC to UMLActivity Diagram and vice versa later on. For comparing the notations of both diagrams wewill use the EPC diagram from chapter 2 and activity diagram from chapter 3.
CaptureRequirement
Check materialon stock
ProvideMaterial
OrderMaterial
o:Requirement[captured]
o:Requirement[checked]
Sales Procurement
[on stock]
Requirementoccured
Capturerequirement
Requirementcaptured
Check materialon stock
Materialon stock
Materialnot on stock
Get materialfrom stock
Ordermaterial
Materialprovided
Materialordered
XOR
Material
Employee
Material
Sales
Procurement
Material Order
ProcurementProcurement
[not onstock]
Figure 4.2. Example of notational correspondences in EPC and UML Activity Diagram
32
The notational correspondences and differences of both diagrams can be categorized asfollows:• Functions and Activity/Action States.
Both the functions in the EPC and activity/action states in UML Activity Diagrams arethe active elements that represent what a person of an organization unit or an actor in ause case diagram do with respect to the process. Therefore it is clear that functions andactivity/action states represent specific business tasks within a company. That meansthat they share the same role within their respective diagrams. An activity or a functionusually takes some extended time to execute.
• Events.In the EPC an event is a passive element that triggers a function and is a result ofanother function. The events can also show the change of status of an object over theprocess chain. There is no correspondence of events in activity diagrams, even thoughthe activity diagrams are based on state diagram, but the states are mostly activitystates, while an event is not an activity. Nevertheless if we take a look at the exampleof EPC some of the events, especially those that are the direct results of a function, areredundant. For example in the figure 4.2 the result of the function ‘capturerequirement’ is ‘requirement captured’ which means that the resulting event is just toshow that when the function finishes control will pass to the event which in turntriggers the next function. However in activity diagram this intermediate result is notexplicitly declared. This is because the transition in activity diagrams means that assoon as an activity state finishes it does not have to wait (which correspond to theevent) 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 overtime from one event that triggers a business function that in turn results in anotherevent. Activity diagrams are based on state diagrams in which transitions are defined;transitions show the change of states over time. Control flow and transitions areinstantaneous; 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 anevent.
• Logical connectors.Logical connectors allow the splitting of control flow in the EPC and transitions inactivity diagrams. For the splitting regarding to taking a decision between differentalternative paths, both diagram have a similar construct, which is known asbranch/merge. The branching and merging of control flows in the EPC is representedusing the logical ‘XOR’ connector plus the events following it. The same mechanismin activity diagrams is implemented using the decision diamond symbol and transitionlabels. Both diagrams also support the notation of parallelism known as fork/join. Theforking and joining in the EPC is shown using the logical ‘AND’ connector while inactivity diagrams it is shown using the synchronization bar. Actually a synchronizationbar corresponds to an ‘AND’ connector together with the events before it, because asynchronization bar waits for all transitions to arrive. The main difference betweenEPC 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.
33
• Organization units and Swimlanes.An organization unit in the EPC is attached to a function its responsibility for therespective business task. In the activity diagrams this is accomplished by arranging theactivities that belong to the same department in a company or activities being done bythe 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 followingtable:
EPC UML Activity Diagram
Context Process-oriented modeling(business oriented)
Object-oriented modeling(IT oriented)
Exactness/Ambiguity ‘Event from the side’,deadlocks, loops, logicalconnector semantics
-
Notation/Terminology
Active Element Function Activity/Action state
Passive Element Event -
Process chain Control flow Transition
Logical connectors
Branch/Merge ‘XOR’ connector Decision diamond
Fork/Join ‘AND’ connector Synchronization bar
‘Inclusive or’ ‘OR’ connector -
Actor Organization unit Swimlane
Iteration - ‘*’ (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 theresults from the comparison between EPC and UML Activity Diagram as alreadydiscussed before. To translate from an EPC diagram to an activity diagram, the followingguidelines 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 unitsinto separate swimlanes in an activity diagram.
2) Transform each function into activity/action states in the activity diagram and put it inthe swimlane of the organization unit being responsible for it. If the function is acomplex hierarchical function (which is also called a process), the refined EPC for thatspecific function can be either drawn as a complex activity state (meaning that insidethe activity state we must specify some actions performed in the activity as well as
34
entry and exit actions) or it would be better to draw the function in a separate activitydiagram.
3) Transform the corresponding logical connectors from the EPC into the correspondingelements in the activity diagram. The branches and merges represented by ‘XOR’connectors are transformed into decision diamonds and the forks and joins representedby ‘AND’ connectors are transformed into synchronization bars.
4) Connect the activities and decision diamonds or synchronization bars according to thecontrol flow in the EPC.
5) Add the start event(s) and end event(s). It is possible to have multiple start events andend events. This can be considered as multiple start events in the EPC or can also beconsidered as several scenarios in one diagram.
However, there are some problems with regard to the translation from an EPC to anactivity 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 thislogical 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 twovariables 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 anda closing ‘OR’ connectors into the following diagram:
OR
F1 F2
OR
F1 F2 F1 F2
Figure 4.4. The branch/fork solution for the elementary or-connector
However if the ‘OR’ connector connects more that two alternative paths the resultingtranslation in the activity diagram would be very complicated.
• The organizational responsibility for activities is expressed in activity diagrams usingswimlanes. However, swimlanes are not sufficient for modeling advanced and preciseorganizational relationships. These are important for example for the definition ofworkflows when support through workflow management systems is intended.
• Another problem with respect to translation from EPC to activity diagram is related tothe 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 object’s state as an object with the object flow in anactivity diagram, but if there are many information/resource objects in an EPC, theywould make the diagram very hard to read.
35
• The definition of activity diagrams as state machines is quite problematic for applyingactivity diagrams according to the UML definition for business process modelingbecause 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 astransition labels especially after a branch can be more or less transformed into eventsafter an ‘XOR’ connector. If there is an object flow in the activity diagram, that can beused as a guide to create the events, e.g. the ‘requirement [captured]’ object state canbe transformed into the ‘requirement captured’ event.
4) Connect the elements (events, functions, and logical connectors) with the control flowaccording to the transitions in the activity diagram.
5) Connect the functions with the respective organization units transformed fromswimlanes 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 thattrigger functions and events as the results of functions. Object flows and transitionlabels or guards can be used as a reference to create events, but that is not a generalsolution. The only guaranteed solution is to try to understand the process that ismodeled 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 modeldirectly 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 thecontrol flow and organization units.
• Since there is no corresponding notation for iteration in the EPC, we need to constructa loop for that. An additional effort to control the loop is needed so that it works as inthe activity diagram.
4.3. The Integration Approach: The Object-EPC (oEPC)
This section argues for an integrated approach to object-oriented process modeling anddescribes selected aspects of an exemplary approach by [SNZ97] called the object-orientedEPC (oEPC).
4.3.1. Motivation for Integration
We have already discussed in the first part of this chapter the contextual background ofEPC and UML activity diagrams. The EPC is developed in the context of business processmodeling and the UML is developed in the context of software development. Nowadaysthe successful development of business information systems requires an integrated
36
approach which includes the seamless design of both the business processes andinformation systems development supporting the business processes. The businessprocesses are modeled in a process-oriented framework, while on the other hand object-oriented modeling methods are used only on aspects which are close to softwareimplementation, not the business processes. However these two fields are moving closertogether 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 anoverall description of a company’s business processes and its object-orientedinformation systems it is therefore necessary to integrate business process modelinglanguages 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-orientedapproaches can also be used on the business level for identifying the objects to be dealtwith in a business process and its relationships.
• With the development of business objects as software components which can beassembled to an information systems according to the user’s specific requirements, it isnecessary to provide means for defining how a business process is supported by thecooperation of business objects.
For these reasons and due to the fact that the translation approach between EPC and UMLactivity diagrams has posed some significant problems, it is reasonable to think of anapproach for integrating the strengths and advantages of the EPC and the UML to create amethod that cover both areas of business process modeling and object-oriented informationsystem. The purpose of the integration approach is on the one hand to preserve thepotential and the end user’s acceptance of the standard EPC method for business processmodeling 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 acompany’s business processes and its object-oriented information system without the needfor switching between different modeling paradigms or for translating between differentmodeling languages.
Within this concept, a business process is defined as the event-driven processing and thecorresponding interaction of business objects in the same diagram. The oEPC differentiatesbetween business process, business object, the corresponding resources such asorganization units, information resources and events. Business objects can be grouped intoclasses. Each business object class has attributes and methods or functions. For modelingbusiness processes, the interaction between objects takes place via message exchangesdenoted 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 anobject’s methods. The method protocol, that is, how and when the method can be called, isaccessible 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 oEPCdiagram. The symbol for a business object is the same as the symbol for a class in the
37
UML. To show the attributes and called methods of an instance of the class, we can showthe attributes on the left and methods on the right of the business object.
business objectclass 1
event 1 event 2 ...
*
logical connector
method m1()method m2()
attribute a1attribute a2
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, theevents are drawn using their own symbol. This is a fundamental difference with UMLinteraction diagrams in which events are not explicitly shown but implicitly represented asarrows between two objects, thus leaving out some important semantics from thedescription of dynamic system relationships. In figure 4.4 the events are represented belowthe object. Since an object can send more than one message at the same time with differentcontents 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 thecorresponding events.
4.3.3. Modeling Business Processes
For the modeling of business processes as interactions between business objects, two typesof message exchange are distinguished:• Event-based messages.
They describe the control flow and the decision logic. The message contains theinformation about the state transition of a business object at a certain time caused bythe execution of one of its methods. This is explicitly modeled by events. Hence objectclasses are connected via events in order to describe a business process.As a substantial aspect of business process modeling, the assignment of theorganization units or the persons carrying out the tasks to the business objects can alsobe shown here similar to the standard EPC, thus the relevant organization units can bemodeled in the context of the respective process and their role during the process canbe illustrated.
• Service-control messages.This type of message is used to define client-server relationships among classes. Thesender (client) triggers the recipient (server) to deliver a service which the sender needsfor further execution of the process. However this client-server relationship is not thefocus of attention within the business process analysis.
38
Object class A
Start event
Event/MessageObject class A
Object class B
Event/MessageObject class B
control flow
Organizationunit 1
Organizationunit 1
TransitionObject A
TransitionObject B
Figure 4.6. Basic model of an event-based message (from [SNZ97])
Object class A
Start event
Event/Message A
Object class C
Object class A
Start event
Event/Message A
Object class C
Job MessageA1 ('get')
Result MessageC1 ('send') Object class 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 changeof object’s status. Similarly, it is possible that an object can only execute its method whenseveral events occur. In order to model these cases and other similar interdependencies, thelogical connectors ‘AND’, ‘OR’, and ‘XOR’ are introduced into the oEPC. Thecombination of these Boolean operators and the events makes up the link to commonbusiness roles in analogy to the standard EPC.
39
Figure 4.7 shows an exemplary structure of a business process model by means of oEPCsymbols and terminology illustrating graphically the control flow defined by event-drivenmessages. The relationships among business object classes involved in the process can bedescribed using a class diagram (as opposed to entity-relationship model used in thestandard EPC) as illustrated in figure 4.8.
Requirementoccured
Requirementcaptured
Materialon stock
Materialnot on stock
Materialprovided
Materialordered
XOR
Material
Employee
Sales
Procurement
Order
Procurement
Requirement
Material
Material Material
determineMaterial()determineAmount()determineReceiver()
checkStock()
getFromStock() orderMaterial()
business objectclass Requirement
event/messageobject classRequirement
active functions
Figure 4.8. Example for the oEPC structure of the procurement logistics
Material
NameAmount on Stock
checkStock()getFromStock()orderMaterial()
Order Item
1..1
0..*
AmountStatus
determineMaterial()determineAmount()
Requirement
determineReceiver()
Order
DateStatus
Employee0..* 1..1
g
Figure 4.9. Class diagram for the procurement logistics example
40
A possible critique of their approach is about the classes participating in the messageexchange. Because in oEPC the message exchange is represented between classes (unlikecollaboration diagram where the message exchange is between objects), the diagramcannot express whether the same objects or different objects appear for the participatingclasses. In the above example after the ‘requirement captured’ event, an object of class‘material’ receives the message. After the object executes the method ‘checkStock()’, thequestion is whether the object sends the resulting message to itself or to another object ofclass ‘material’. This is not explicitly shown here, while it can be clearly shown in acollaboration diagram.
41
Conclusion
The comparison between EPC and UML activity diagrams shows that even if bothmethods were developed in different contexts, they are usable for modeling businessprocesses. However as we can see from the comparison, the EPC covers more aspects suchas a detailed description of business organization units together with their respectivefunctions as well as information and material resources used in each function. Theseessential relationships are not explicitly shown in activity diagrams. Instead we need toderive from other elements such as object flow or even we need to model these aspects inother diagrams of the UML. However the EPC is sometimes imprecise or even ambiguouswhen we analyze its process, but this problem has been addressed by utilizingtransformation approach to Petri net which can be analyzed to prove the correctness of theEPC.
Based on the comparison we can also see that there are a lot of concepts which arecommon to both EPC and activity diagrams. These common concepts make it possible totranslate both diagrams back and forth between the different notations. Nevertheless thereare also some basic different concepts which has no correspondence in the other one. Thisraises problems such as information loss when translating from EPC to activity diagramsdue to less aspects of activity diagrams and loss of details such as iteration and objectidentity when translating from activity diagrams to EPC.
Because of the problems of translating between EPC and activity diagram the twoapproaches - the object-oriented paradigm which is closer to information technology andthe process-oriented one which is closer to business aspects (organization, information andmaterial, function) – need to be brought closer. A semi-formal proposed solution for this isthe object-oriented event-driven process chain (EPC). This integrated approach is apromising candidate for solving these aspects in one unified method.
42
Bibliography
[BRJ99a] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling LanguageReference Manual. Addison Wesley, 1999.
[BRJ99b] G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language UserGuide. Addison Wesley, 1999.
[CKL98] T. Curran, G. Keller, A. Ladd. SAP R/3 Business Blueprint. Understanding thebusiness 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 für Standardsoftware: Anforderung, Nutzung und
methodische Grundlagen. Diplomarbeit, Fachbereich Informatik UniversitätHamburg, 2001.
[KNS91] G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung aufder Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichungdes Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 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 – AnApproach for Integrating UML and Event-Driven Process Chain (EPC).Publication of the Institut für Wirtschaftsinformatik, Paper 144, Saarbrücken,1998 (http://www.iwi.uni-sb.de/iwi-hefte/iwih144.ps).
[LA98b] P. Loos, T. Allweyer. UML und EPK - auf dem Weg zur ’Unified ProcessLanguage’? - IDS Prof. Scheer GmbH, Saarbrücken, 1998.
[LSW97] P. Langner, C. Schneider, J. Wehler. Ereignisprozessketten und Petri-Netze.Fachbereich Informatik Universität Hamburg FBI-HH-B-196/97, 1997.
[NFZ98] M. Nüttgens, T. Feld, V. Zimmermann. Business Process Modeling with EPCand UML – Transformation or Integration? Publication of the Institut fürWirtschaftsinformatik, Saarbrücken, 1998.
[Sch94] A.-W. Scheer. Business Process Engineering. Reference Models for IndustrialEnterprises. Springer-Verlag, 1995.
[SNZ97] A.-W. Scheer, M. Nüttgens, V. Zimmermann. ObjektorientierteEreignisgesteuerte Prozesskette (oEPK) – Methode und Anwendung.Veröffentlichung des Institut für Wirtschaftsinformatik, Paper 141,Saarbrücken, 1997 (http://www.iwi.uni-sb.de/iwi-hefte/heft141.ps).