A Framework for Business Model Driven Development

A Framework for Business Model Driven Development Philip Liew1, Kostas Kontogiannis1, Tack Tong2 1

2

Dept. of Electrical and Computer Engineering University of Waterloo 200 University Ave. West Waterloo, ON N2L3G1

IBM Canada IBM Toronto Laboratory 8200 Warden Avenue, Markham, ON, L6G 1C7

Canada {pliew, kostas}@swen.uwaterloo.ca

Canada [email protected]

Abstract Typically, large companies in an effort to increase efficiency specify business processes using workflow languages, while software designers specify the systems that implement these processes with the use of languages like UML. This separation of domain expertise allows for software engineers from each individual area to work more efficiently using domain specific languages and tools. However, models in these two domains evolve independently and inconsistencies may occur when two models become unsynchronized due to constant revision or evolution of processes and design artifacts. In this paper, we present a set of transformations to automatically generate a specific set of UML artifacts from the business process specifications. In particular, we examine and investigate a preliminary framework for the necessary annotations that need be applied to a Business Process Model so that the generation of UML use cases, activity diagrams, collaboration diagrams and deployment diagrams could be feasible. The objective of this work is to be able to generate rich Platform Independent UML models that can be used for automating the generation of design artifacts and source code by using a Model Driven Architecture approach. By doing so, we aim to decrease software design time, reduce maintenance costs and better support system evolution.

1. Introduction A business process model (BPM) captures the activities that govern the interaction between various entities in an organization and is usually represented by workflow technology that denotes business rules and activities in a standardized manner. Typically, business domain experts use these workflows to

capture and model out requirements, which are then translated by software architects into a software oriented modeling language such as UML. The UML models can then be used as design documents by developers when implementing the system. This clear separation of business domain and software domain has the distinct advantage of allowing each respective expert to work in their own domain using their own language. Yet problems emerge when either model undergoes numerous updates to meet changing requirement, thus causing drift between them. In this paper, we investigate the issue of re-using business domain solutions to help generate artifacts for the software domain. With the derived UML models, the information can be refined to produce models rich enough for code generation according to MDA principles. To achieve this goal, we first specify the set of informational assets needed to give the business process model enough semantic detail to produce valid UML models, and second, the set of transformations that utilize the existing workflow to produce UML specific artifacts. In order to realize these goals, we first standardize on the use of BPMN to capture business processes, and then compare its meta-model to the meta-model of UML diagrams. Through comparison we assess the relevant information needed for comprehensive generation of models, and if not provided through the existing workflow language facilities, extend the model through annotations to provide rich enough semantic detail. For our transformations, we focus specifically on mappings between the Business Process Model Notation (BPMN) and UML (v 1.5) activity, use case, collaboration, and deployment diagrams. We define a set of procedures to produce equivalent models in UML. The rest of this paper is organized as follows. Section 2 presents related research and discusses how

Proceedings of the 2004 International Workshop on Software Technology and Engineering Practice (STEP’04) 0-7695-2293-9/04 $20.00 © 2004

IEEE

our findings build upon previously published results focused in the area of requirements engineering. Section 3 gives a brief introduction of the Business Process Modeling Notation. Section 4 introduces the set of informational assets that are used as the basis for the mapping and transformations specified in detail in Section 5. Section 6 provides an example showcasing our approach, and finally Section 7 gives the conclusion and directions for future research.

2. Related Research The Model Driven Architecture (MDA) [8] is an approach of building software from models. This software is built (semi-)automatically from abstract models, which are specified using standard languages such as UML [6]. The Object Model Group (OMG) defines four types of models in MDA: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM), and Implementation Specific Model (ISM). Transformations between one set of model type [8] to the other is the basic underpinning of MDA. By transforming from PIM, to PSM, to, ISM we create executable code from analysis models and gain all the benefits of producing high level designs. To implement this vision, OMG has standardized on a set of tools consisting of technologies like Unified Modeling Language (UML), Meta-Object Facility (MOF), and XML Metadata Interchange (XMI) [9]. MOF and UML are primarily for the design of models while XMI is used for the interchange of these models between applications based on XML. Thus, using another XML technology like Extensible Stylesheet Language Transformations (XSLT), we have a framework for developing model transformation tools. Similarly, research in requirements specification has focused mainly on re-use of software domain models rather than extracting details from business domain models. Algorithms from Dijkman and Joosten [2] focus on deriving use cases from business processes from workflows expressed as activity diagrams. Their process uses one to one mappings of activity diagram objects to use case objects, and uses custom algorithms to increase the resolution of detail in their use cases. Applying their algorithms to case studies showed they were able to show relevant data for requirements elicitation. By using similar refined mapping patterns we achieve better logic and understanding through better implementation of the facilities of UML. Another similar approach is introduced by Stolfa and Vondrak whom use a similar mapping basis to achieve their use cases. Drawbacks occur in that large activity

diagrams will result in overly complex use cases which can become unusable. Our approach takes a different approach by incorporating the control flow logic of business processes as ways to separate granularity, as well as taking sound concepts from both [2][4]. Gardner in [10] discusses the generation of UML artifacts from BPEL specifications. In [11] and [12] the use of UML Action Semantics in model transformations is presented. Finally, in [13], [14] prototype tools and lessons learnt for supporting automatic generation of software artifacts from specifications within the context of MDA are presented. White in [3] introduces the 21 fundamental patterns that describe business process behavior. Though intended as a comparison of readability and technical facilities, it serves as a valuable mapping of patterns from BPMN to UML activity diagrams. Due to their similar functions, near one-to-one mapping is achieved and the discussion of BPMN to activity diagram is left out of this paper. In [5] the usage of a two-space framework for model transformation forms the basic architecture that we build our model transformation tool on. This basis is used to convert our M2 models to and from using XML, XMI, and XSLT technologies.

3. Business Process Modeling Notation BPMN is a modeling notation standard set by the Business Process Management Initiative (BPMI). Its primary design goal is a readily understandable notation that can be easily used by the process creators, process implementers, or process managers. In [1] BPMN is described as a flowcharting technique tailored for creating graphical models of business process operations. The elements within a business process diagram consist of flow objects, connecting objects, swimlanes and artifacts. Each type of objects is discussed in further detail in the subsequent sections followed by an example.

3.1. Flow Objects A list of all type of flow objects is shown below in Table 1 followed by a brief description of each element. • Event – is something that happens during the course of the process and effects the flow of the process Name Diagram Event Activity


IEEE

Gateway Login

Client Id

Table 1 - Flow Objects Name Sequence Flow Message Flow Association

Browse and Select Merchandise

Diagram Item, Client Id

Table 2 - Connecting Objects Name

Diagram

Payment Transaction

List of Items, Client Id

Add Items to Shopping Cart

Pool Figure 1 - Example Business Process Lane

3.3. Swimlanes Table 3 - Swimlanes Name Data Object

Diagram

Swimlanes are used as a mechanism to organize activities into separate visual categories. These categories can fall under functional capabilities, or responsibilities.

Group

•

Annotation

•

Pool – used to either graphically partition activities or represent a participant Lane – used to sub-partition a pool

3.4. Artifacts Table 4 - Artifacts • •

Activity – is an atomic or non-atomic item that describes the work a company performs Gateway – is used to control the divergence and convergence of sequence flow such as branching, forking, and merging

3.2. Connecting Objects Connecting objects are typically used to connect flow objects to each other or other information. • • •

Sequence Flow – used to show the order that activities will be performed in a process Message Flow – used to show messages passed between the participants of a process Association – Used to associate information with flow objects

Artifacts are used to allow flexibility to the basic notation. • • •

Data Object – are associated with activities and show input/output of activities Group – Used for analysis or documentation but doesn’t affect control flow Annotation – A method to provide additional text information to modelers

3.5. Example Business Process An example business process is shown in Figure 1 demonstrating the typical business process for payment transaction

4. Informational Annotations Generating UML diagrams from business processes requires additional semantic information to provide enough detail for the mapping process.


IEEE

Business Modeling

Software Design

BPMN

UML

(Workflow)

(Activity Diagram)

BPMN Extension Level 1 (Sequencing information, input/output flows)

BPMN Extension Level 2

•

UML (Use Cases, State, Sequence, Collaboration)

UML (Component, Deployment)

•

(Runtimes, Services)

Figure 2 - Leveled Mappings In order to determine them, we analyzed the metamodels of each notation (BPMN, Activity, Collaboration, Use Case, and Deployment) and listed out the necessary annotations that would need to be included in our BPMN model which our mapping algorithms would be based on. The general framework is to extend the BPMN language using annotations. Mapping from BPMN to UML activity diagrams is easily provided using XMI as a basis of representation. With the extended annotations, we achieve a second layer of information that can be used to transform to second level UML models. This tiered transformation framework is shown below in Figure 2. Each annotation level is described in detail below followed by how it will be presented using BPMN facilities. •

Role – In order to identify the stakeholders of a software system, it is necessary to associate tasks and processes with the roles that perform the action. Within BPMN, roles can be specified according to swimlanes, but it leaves out the ability to define a role with a specific task or processing element. Thus the use of a text annotation specifying the role per processing object is used.

•

•

Automation Level - Workflow elements map out high level concepts, and thus intersperse system automated components with personally executed processes [2]. With UML used to design the system automated components, this information will be used to ascertain the necessary objects that will be implemented. The classification for automation level falls under automated, supported and manual. Automated specifies tasks performed by the system without assistance, supported requires support from external entities, and manual is when the task is performed by an external entity. In order to add this extra information, we use the text annotation facilities in BPMN and associate it with the specified object Data Item Abstract Data Type Mapping – Data Items within BPMN are used to model out data objects. These data objects are then passed from process step to the next. These entities need to be mapped out to existing Abstract Data Types (ADT), or ones that will be created. In order to specify this, a text annotation associated with the Data object will specify the mapped ADT structure. Processing Element Abstract Data Type Mapping - unlike Data Objects in the BPMN model, there might not be a direct mapping from a task, or process to a data type. If a one-to-one mapping does occur, an annotation specifying the associated ADT will be listed. Flow Object Pre/Post Conditions - much like formal specifications it is necessary to specify functions at an intermediate level to help determine functionality. In order to do this, we introduce annotations describing preconditions, and post-conditions. Preconditions, are a statement about the function parameters stating, what is invariably true before the function is executed. Where as post-conditions are statements about a function parameter, which specify what is invariable true after the function is executed. Together, these conditions form the function specification. Our implementation of function specifications will use OCL as the predicate language to determine the ‘true’ statements about the element. Thus, a process, subprocess, task, and decision element will each have pre/post conditions set. In the decision element, each decision branch will have an associated post-condition that specify the predicate.


IEEE

•

BPMN Deployment Associations - In order to map a BPMN model to a deployment diagram, annotations are necessary associating processing elements (tasks, processes, sub-processes), repositories, or services to run-time components and hardware nodes. This is provided through the text annotation facilities of BPMN.

Business Concept

Process

Role Step Association between Role and Step Task Task in a Step Transition between Tasks in the same Step Transition between Steps Alternative Path through Branch

Use Case Concept Actor Use Case Association between Actor and Use Case Interaction Interaction in a Use Case Ordering between Interactions in the same Use Case Including a Use Case Extending a Use Case

Table 5 - Mapping from BPMN to Use Case Concept

5. BPMN to UML Transformations Each subsequent section outlines the mapping from BPMN notation to the specified UML diagram. As mentioned in the related research, [3] has outlined the 21 patterns that can be mapped from BPMN to Activity diagrams. Due to the similarities between workflows and activity diagrams, and the nearly oneto-one mappings, we leave the mapping out of this paper and focus on use cases, collaboration, and deployment diagrams.

5.1. Use Case Diagram Mapping In order to map from BOM to UML, an algorithm based on roles, and automation level is used to map objects, and to identify relevant use case scenarios. In some algorithms, the typical approach is to map each processing element (i.e. task) to a use case. Though this might seem reasonable, typical workflows contain a large amount of tasks, and the transformation procedure will produce an overly complex use case. In [2] a solution to the granularity issue by proposing a higher construct defined as a Step, which can then be mapped to a use case is proposed. More formally, a Step is a sequence of tasks that can be performed without interruption by the same role. Thus in order to identify steps, we take the first task in the procedure model, and determine the tasks that:

1. 2. 3.

Is directly connected to this task by a transition Are assigned to the same role Do not have time passing between them

For each task that is directly connected by a transition to a task in the first step, we repeat the procedure Table 5 illustrates the mappings between business process concepts to use case concepts. These mappings can be used to generate initial use case descriptions from Business Process Models. The automatic generation of Use Case models has a twofold effect. First allows for software engineers to better capture and specify the requirements and an initial object model for the system from high level descriptions, and second allows for traceability to be established early on between high level system descriptions and requirements/design artifacts.

5.2. Collaboration Diagram Mapping Mapping from BPMN concepts to collaboration diagram concepts relies on evaluating stepwise each processing element within the BPMN workflow. Information regarding roles, process element ADT mappings, and function specifications are used to determine the sequence of messages initiated by an Actor. The corresponding algorithm to generate a collaboration diagram from annotated business process descriptions is outlined below: 1. 2. 3. 4. 5. 6. 7.

8.

9.

Role of task in BPMN is mapped to initializing actor in UML Initialize sequence number 0.0 Enumerate the tasks (nodes) in the workflow P using a breadth first traversal method Identify the set S of elements in the workflow P that can be mapped to an ADT Select the first task in the process model Increment the leftmost sequence number by 1 The tasks ADT object mapping annotation is mapped directly to a class object instance in the collaboration diagram. Post-condition annotation is mapped to the outgoing message of the associated class object mapped in step 4. If no mapped object, then it is outgoing message of last known class object in workflow Increment the right-most digit in the sequence number and attach to message. For alternative flows use the sequencing a, b, c, …


IEEE

10. If there is no other task in the workflow – stop, else select the next task in the workflow 11. If the task is associated with an ADT go to Step 6, else go to Step 7. This algorithm uses the controlled direction of a workflow to determine sequence patterns. This property is also used to determine associations among objects. If ADT classes are not associated with a task (using an annotation), the function specification is determined to be generated by the last associated ADT class in the control flow. We assume that the domain classes associated are correct, and if so, are properly mapped in the workflow. An example of the application of the algorithm is given in Section 6.

5.3. Deployment Diagram Mapping The mapping for deployment diagrams is heavily dependent on a tasks associated run-time process, and hardware description annotations. The corresponding algorithm for generating a UML Deployment Diagram from an annotated business flow is outlined below. 1.

2. 3. 4. 5. 6.

7. 8.

Identify all hardware nodes, and their associated run-time components that would be used to deploy the proposed system Draw the UML diagram for each component Take first task in workflow process model If associated with run-time, store in previous run-time variable Proceed to next task unless end of process If current task is associated with run-time, make dependency relation between previous run-time and current run-time Set previous run-time as current run-time Go to step 5

We are able to map these dependency relations due to the concept of workflow dependency. In order for one task to proceed to the next, it is dependent on the fact that all previous tasks were completed properly. This outlines a hierarchical dependency graph where each node is dependent on the previous. By mapping out the associated run-time processes, it was possible to derive information from the workflow as well to determine the dependencies.

Pay by Cash or Check Take Cash or Check

Prepare Package for Customer

Identify Payment Method Paymen Method

Pay by Credit Card

Swipe Card and Sign

Figure 3 – Workflow for a Payment Transaction

6. Example Problem The mapping algorithms specified in Section 5 are applied to the sample workflow presented in Figure 3 to produce the resulting models. In the following sections we present the necessary annotations from the nodes of the sample process illustrated in Figure 1. Name

Value

Role Input Output Automation Level ADT Pre-condition Post-condition

Customer Service Representative Customer Order Customer Order Supported

Deployment Association

None CustomerOrder null (CustomerOrder.PayByCreditCard = true) xor (Customerorder.PayByCashOrCheck = true) None

Table 6 - Annotations for Identify Payment Method Name

Value

Input Output1 Output2 Automation Level ADT Pre-condition Output 1 Postcondition Output 2 Postcondition Deployment Association

Customer Order Customer Order Customer Order Supported None CustomerOrder null (Customerorder.PayByCashOrCheck = true) (CustomerOrder.PayByCreditCard = true) None

Table 7 – Annotations for Payment Method Decision

Name

Value


IEEE

Role Input Output Automation Level ADT Pre-condition Post-condition Deployment Association

Customer Service Representative Customer Order Customer Order Supported None CustomerOrder null (CustomerOrder.Paid = true) CashTill

Table 8 - Annotations for Take Cash or Check Name

Value

Role Input Output Automation Level ADT Pre-condition Post-condition Deployment Association

Customer Service Representative Customer Order Customer Order Supported None CustomerOrder null (CustomerOrder.Paid = true) CreditCardProcessor

Table 9 - Annotations for Swipe Card and Sign Name

Value

Role Input Output Automation Level ADT Pre-condition Post-condition

Packager Customer Order Customer Order Supported

Deployment Association

Figure 4 - Use Case Diagram Finally, the “Prepare Package for Customer” task requires the completion of the “Take Cash or Check”, and “Swipe card and Sign” tasks. Annotations to the Business Flow that could also help and consider adding include quantifications whether a task is required for the completion of a flow/segment, how often is used, and whether it is considered as an exceptional case or a frequent task.

Packager CustomerOrder null (CustomerOrder.AvailableOrderItem = true) and (CustomerOrder. DeliveryDate = today) CashTill

Table 10 - Annotations for Prepare Package for Customer

6.2. Use Case Diagram In the above diagram the actor interacts with the system assuming a role. The role is that of a “Customer Service Representative”. With this role we can annotate all the nodes in the sample flow, and therefore can participate on the formation of the Use Case diagram. The actor interacts with the first task in the flow “Identify Payment Method”. As per the mapping algorithm alternative tasks are modeled with the stereotype. In this case, “Take Cash or Check”, and “Swipe card and Sign” can be considered as alternative scenarios to “Identify Payment Method”.

Figure 5 - Collaboration Diagram These additional annotations can help determine more accurately the stereotypes for the generated Use Case diagram. The resulting Use Case diagram is illustrated in Figure 4.

6.3. Collaboration Diagram In this diagram an enumeration of the tasks in the flow is performed, and the actor is initialized with a specific role (the same role that was used in the Use Case diagram). Furthermore, only the “Prepare Package for Customer” has been identified with a corresponding ADT. The sequence numbering starts at 0.0 and is incremented to 1.0 at Step 6 of the algorithm. The workflow is traversed and the sequence numbers of the activities are added in the rightmost digit of the sequence numbers. The alternative tasks in


IEEE

through the use of business process modeling as a high-level software design tool. As part of on-going research, we intend to first investigate the formalization of model mappings and transformations using EMF [8] and to provide a framework that will automatically generate UML artifacts. Figure 6 - Deployment Diagram

the workflow model “Take Cash or Check”, and “Swipe card and Sign” and modeled by using the sequencing 1.2a, and 1.2b (Step 9 of the mapping algorithm). The resulting collaboration diagram is illustrated in Figure 5.

6.4. Deployment Diagram For the deployment diagram we first identify the hardware and run time components that pertain to the workflow. These are considered as orthogonal annotations to the workflow and can be modified as the system design evolves. In this particular example, a “CashTill”, and a “CreditCardProcessor” components have been identified. The tasks in the workflow that have been annotated with a Deployment link (please see Tables 7-10) were “Take Cash or Check” with “CashTill” deployment node, the “Swipe card and Sign” with the “CreditCardProcessor” node, and the “Prepare Package for Customer” task with the “CashTill” deployment node. Since there is a data flow in the workflow model between “Take Cash or Check” and “Prepare Package for Customer” we include a link between the corresponding deployment nodes. Additional annotations that could have helped making the Deployment Diagram more detailed and we plan to incorporate include services, interface descriptions, and annotations on what hardware node these run time services are best deployed. The resulting Deployment diagram is illustrated in Figure 6.

7. Conclusion In this paper, we have introduced a basis for generating UML diagrams from business process models. As part of our theory, we have introduced additional annotations which are used to enrich the business process with enough detail to aid in the generation process. Using the built-in facilities within BPMN, we extend the language to provide the additional information which is then used as the basic building blocks for our mapping algorithms. The focus of this paper is to extract the necessary data and patterns necessary to aid in the software design phase

References [1] S.A. White, “Introduction to BPMN”, www.bpmn.org, May 2004. [2] R.M. Dijkman, and S.M. Joosten, “Deriving Use Case Diagrams from Business Process Models”, 2002. [3] S.A. White, “Process Modeling Notations and Workflow Patterns”, www.bpmn.org, January 2004. [4] S. Stolfa, I Vondrak, “Using the Business Process for Use Case Model Creation”, ISIM ’03, 2003. [5] M. Peltier, F. Ziserman, J. Bezivin, “On Levels of Model Transformation”, In XML Europe 2000, Paris, France, June 2000, Graphic Communications Association, pp. 1-17 [6] A. Brown, “An introduction to Model Driven Architecture Part I: MDA and today’s systems”, IBM, January 2004. [7] S. Mellor, K. Scott, A. Uhl, D. Weise, “MDA Distilled: Principles of Model-Driven Architecture”, Addison-Wesley, 2004. [8] F. Budinsky et.al. “Eclipse Modeling Framework” Addison-Wesley, 2004. [9] Object Management Group, “Extensible Metadata Interchange”, http://www.omg.org/technology/xml/ [10] T. Gardner “UML Modeling of Automated Business Processes with a mapping to BPEL4WS”, In Proceedings of the European Workshop on Web Services and Object orientation, ECOOP July 2003. [11] D. Varró, and A. Pataricza, “UML Action Semantics for Model Transformation Systems”. In Periodica Polytechnica, vol. 47, No. 3, pp. 167-186. [12] G. Sunye et.al. “Using UML Action Semantics for Model Execution and Transformation”. In proceedings of the 13th International Conference on Advanced Information Systems Engineering (CAiSE*01), pp.445-457. [13] G. Boas, “From the Work floor: Developing Workflow for the Generative Model Transformer”. In Proceedings of the OOPSLA 2002 Workshop on Generative Techniques in the Context of Model Driven Architecture [14] L. Bichler, “A flexible code generator for MOFbased modeling languages”. In Proceedings of the OOPSLA 2002 Workshop on Generative Techniques in the Context of Model Driven Architecture.


IEEE