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

Transcription

1 Technische Universität 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 1 st, 2001

2 Contents Figures iii 1. Introduction 4 2. Event-driven Process Chains (EPC) The Architecture of Integrated Information System (ARIS) Descriptive Views Descriptive Levels Description Methods The Function View: Function Tree The Organization View: Organizational Structure The Data View: Entity-Relationship Model The Control View: EPC EPC Notation Formal Description of EPC UML Activity Diagram The Unified Modeling Language (UML) Architectural Views UML Diagrams Structural Diagrams Behavioral Diagrams Activity Diagram Notation Usage of Activity Diagrams Comparison, Translation, and Integration Approach between EPC and UML Activity Diagram Comparison between EPC and UML Activity Diagram Context Exactness/Ambiguity Notation/Terminology Translation between EPC and UML Activity Diagram The Integration Approach: The Object-EPC (oepc) Motivation for Integration Modeling Business Objects Modeling Business Processes 37 Conclusion 41 Bibliography 42 ii

3 Figures 2.1. Business process and ARIS views ARIS views of the process model ARIS descriptive levels ARIS description methods in the requirements definition level Elements used in EPC diagram Use of process paths to show the connection from EPC1 to EPC Branch and merge in EPC Fork and join in EPC Inclusive OR connectors in EPC Forbidden connections in EPC Example of an EPC diagram showing an excerpt from procurement logistics Modeling a system s architecture Diagrams of the UML and their connections Elements of activity diagram Branch and merge in activity diagrams Fork and join in activity diagrams Iteration and dynamic concurrency Example of an activity diagram showing an excerpt from procurement logistics Two events arriving at one connector Example of notational correspondences in EPC and UML Activity Diagram Summary of comparison between EPC and UML Activity Diagram The branch/fork solution for the elementary or-connector Model of a business object with events Basic model of an event-based message Service-control relationship as encapsulated control flow Example for the oepc structure of the procurement logistics Class diagram for the procurement logistics example 39 iii

4 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 UML s 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 company s business processes and information systems should be able to be covered in a unified method. 4

5 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 symbol s 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 andalsowhentousethem. 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. 5

6 Chapter 2 Event-driven Process Chains (EPC) Event-driven Process Chains (EPC) is a method developed by Scheer, Keller and Nüttgens 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 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 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. 6

7 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

8 ARIS Organization Data Control Function Descriptive Levels Figure 2.2. ARIS views of the process model (from [Sch94]) 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. 8

9 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) Design specification Implementation description Requirement Definition Design Specification Implementation Description Data View Requirement Definition Design Specification Implementation Description Control View Requirement Definition Design Specification Implementation Description 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 Description Methods The ARIS architecture s 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

10 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 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 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, Chen s 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

11 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/ 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

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 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] Process 1 event N event 1 Process 2 [next functions and events 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 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

13 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 Figure 2.7. Branch and merge in EPC If either events E1 or E2 occur, function F1 starts 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 Figure 2.8. Fork and join in EPC If both events E1 and E2 occur, function F1 starts 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

14 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 Figure 2.9. Inclusive OR connectors in EPC If events E1 or E2 or both occur, function F1 starts 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 Forbidden connections in EPC 14

15 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 Sales Employee Information / resource Information flow Requirement captured Organization unit Organization unit assignment Check material on stock Procurement Control flow XOR on stock not on stock Procurement Procurement Get material from stock Order material Order provided ordered Figure 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

16 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 v a to a node v e is a finite sequence of nodes v i V, i =0,,n, γ =(v 0,v 1,,v n ), v 0 =v a,v n =v e, so that each two successive nodes form an edge: (v i,v i+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 γ = (v 0,v 1,,v n ) with v 0 =v n and v i, i=0,,n 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 u 1,u 2,, u n fromanodea=u 1 (E F P)toanodeb=u n (E F P) so that all intermediate nodes u i,2 i n-1, are connectors, u i L, we call a and b connector-connected. No event e E must be connector-connected to 16

17 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 Eor*v For*v Por*v Landv* Eorv* Forv* Porv* L. 3. Events, functions, and process paths are nonbranching, more exactly: For each event e E, *e 1and e* 1 foreachfunctionf 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 =1and *l 1) or ( *l 1and *l =1) 5. An event s E is called a start event if *s = andiscalledanendeventifs*=. There is at least one start event and one end event. 17

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 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 doesn t 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 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 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 project s life. A system s 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: Usecaseview. 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 system s architecture. 18

19 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 system s 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 system s 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 system s 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 Design View Implementation View system assembly configuration management behavior Use Case View performance scalability throughput Process View Deployment View system topology distribution delivery installation 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 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 system s 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 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

20 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 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

21 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 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 user s 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

22 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 object s 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 object s 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

23 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

24 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 state s 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