One of the most difficult, and crucial, activities in software development is the identification of system Business Process Modeling BPMN Use Case Model UML OCL specifications and class diagrams from use cases: a newtonian approach. BPMN is a profile which extends the UML language for a certain domain. Like with natural language you have a different wording to express. BPMN - Business Process Model and Notation BPMN. Use case diagram. Relations between the actors and the use cases: An actor that.
Cruz1,2Ricardo J. Machado2and Maribel Y. One of the most difficult, and crucial, activities in software development is the identification of system functional requirements. A popular way to capture and describe those requirements is through UML use case models.
A business process model identifies the activities, re- sources and data involved in the creation of a product or service, having lots of useful information for developing a supporting software system.
During system analysis, most of this information must be incorporated into use case descriptions. This paper proposes an approach to support the construction of use case models based on business process models.
The proposed approach obtains a complete use case model, including the identification of actors, use cases and the corresponding descriptions, which are created from a set of predefined natural language sentences mapped from BPMN model elements. Organizations need to have a clear notion of their internal processes in order to increase their effi- ciency and the quality of their products or services, increasing the benefits for their stakeholders.
For this reason, many organizations adopt a business process management BPM approach. BPM includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational busi- ness processes . A business process is a set of interrelated activities that are executed by one, or several, organizations working together to achieve a com- mon business purpose .
Among the various existing modeling languages, we? If on one hand the business process management and modeling are increas- ing their relevance, on the other hand the software development teams still have serious difficulties in performing elicitation and defining the applications require- ments .
In fact, one of the main software quality objectives is to assure that a software product meets the business needs . For that, the software product re- quirements need to be aligned with the business needs, both in terms of business processes and in terms of the informational entities that those processes deal with.
Relationship between Activity(BPMN) and UseCase
This drives us to the question: However, the tasks of business process analysis and soft- ware development are managed by different groups of people and commonly use different languages. Requirement elicitation is, indeed, a key step in the software development process. Use case models aim to capture and describe the functional requirements of a system . Dietz says that the use cases strong point is that once they are identified, the development of the software application goes well .
The weak point is the identification of use cases themselves. A use case model is a set of use case diagrams and the corresponding use case descriptions . The use case diagrams enable to perceive the need of describing the system behavior in response to messages received from outside the system i.
In this paper, we present an approach to obtain a complete use case model based on a business process model. All information existing in a BPMN model that cannot be represented as an actor or as a use case will be depicted as textual use case description.
Use case descriptions are, commonly, specified in Natural Language NL [11, 12]. As Fantechi et al. However, the generated descriptions are a set of controlled sentences previously defined in NL. The remainder of this paper is structured as follows. In the next section, BPMN and basic concepts of use case models are introduced and some related work is presented. Section 3 describes our approach for use case model creation and presents its application to an example. Finally, conclusions and some re- marks to future work are presented.
The BPMN basic process models can be grouped into two types of processes : Each private process is represented within a Pool. The process flow must be in one pool and should never cross the boundaries of that Pool.
The interaction between distinct private Business Processes can be represented by incoming and outgoing messages. Only activities that are used to communicate with the other participants must be included in the public process.
There are three kinds of Flow Objects: Events, Activities and Gateways. Data that flows through a process is represented by data objects. Persistent data can be represented by data stores. Data objects and data stores are exclusively used in private process diagrams . There are four types of connecting objects: A participant is a person, or something, involved in the process. Participants in the process can be grouped into pools or, more particularly, in Lanes.
A pool can be divided into several Lanes, for example, to represent the different departments of an organization involved in the process.
The transmission of the data created or used during a process execution can be represented by Messages or Data Associations. The following subsection addresses use case models. So, it is 4 Estrela Cruz et al. In  a use case is defined as a behavioral classifier that represents a declaration of a set of offered behaviors. Each use case specifies some behavior, possibly including variants, which the subject can perform in collaboration with one or more actors.
An actor is someone or something that interacts with the system . So, an actor is always related to one or more use cases. A use case is graphically represented by an ellipse and contains a brief description of the action . A use case diagram is composed by actors and use cases. Each use case shall have an associated description. There are some alternatives that can be used to describe a use case, like informal text, numbered steps, pseudo-code, among others .
Cockburn proposes a basic use case descriptions template that includes the use case name, actors, scope, context, pre-conditions, primary success scenario, alternate scenarios, amongst others . Therefore, it is natural to try an approxima- tion between business process modeling and software modeling. Requirements elicitation is usually the first phase on a software development process.
Several authors already propose approaches to derive use cases from business process models. Some of the existing approaches are presented next. Dijkman and Joosten propose an approach that maps a business process model modeled using the UML Activity Diagram into use case diagrams .
They also proposed an algorithm to derive a use case diagram from a business process modeled as activity diagrams . To do so, Dijkman and Joosten start by defining the activity diagram and the use case diagram meta-models. In a summarized way, in Rodriguez et al. All surveyed existing approaches obtain a use case diagram based on a busi- ness process model, but no one presents a proposal for obtaining the use cases description.
Nevertheless, the use cases descriptions are one of the most impor- tant components of the use case model [12, 21]. Moreover, without descriptions most information presented in a business process model will be lost when gen- erating the use case diagram from a business process model. The use case descriptions can specify all information needed.
But, how should the use cases be written?
Karl Cox also presents a set of structure guidelines for use case descriptions . Both provide improvements on use case descriptions quality  and subsequently improve the understanding between stakeholders. The next section describes our approach to obtaining the use case model from a business process model.
A BPMN pro- cess diagram is graphically more complex because it involves lots of graphical elements activities, events, gateways, data objects, pools, etc. However a use case model can represent as much information as a BPMN model, but most of the information must be embodied in use case descriptions. So, the approach presented here is specially focused on use case descriptions for which we present a template. The approach is divided in two main parts.
First we present a set of rules to obtain a use case diagram from a BPMN model. Then we address the rules to derive the description of the uses cases previously identified. The proposed approach is based on the following considerations: An activity may be atomic, usually represented as a task, or non-atomic, repre- sented as a sub-process.
To avoid information loss during the application of the proposed approach, the sub-processes must be expanded.
Nevertheless, the information about the task execution, like start and ending time or amount of resources produced and consumed, can be useful to the process monitoring to support and evaluate future decisions or improvements. We agree with Rodriguez et al. Accordingly, the rules to generate the use case diagram are explained below: A role played by a participant represented by a lane or a pool must be represented by an actor in the use case diagram.
The actor name is the participant name. A lane can be the sub-division of a pool or a sub-division of another lane. Each activity will be represented as a use case in the use case diagram.
The use case name brief description of the action is the activity name. An actor that represents a pool or a lane is related with all use cases representing the activities that belong to the pool or lane.
Use cases or business process maps, what technique to use?
The actor that represents the participant that sends or receives a mes- sage to an activity is related to the use case that represents that activity. Next subsection applies the described rules to the Nobel Prize example. The presented BPMN model comprises ten activities, consequently by rule R4 above there will be ten use cases on the generated use case diagram.
Four pools are involved in the process: By R1 the obtained use case diagram will have four actors with the corresponding names. The obtained Nobel Prize use case diagram is shown in Figure 2. The explanation for the other relationships is similar. We define a template to represent a use case description based on a simplification of the template presented by Cockburn in .
The proposed template is composed by six fields, which are named and described in Table 1. Cockburn says that a real big and complex system can be modeled with only seven use cases . This yields very complex use cases with several alternative scenarios. The use case name identifies the goal as a short active verb Use Case name phrase. Actors List of actors involved in the use case Conditions that must hold or represent things that happened Pre-Conditions before the use case starts.
Post-Conditions Conditions that must hold at the conclusion of the use case. Do remember the fact that BPMN is designed for business people while use case diagram is for system analysts or system developers. They serve different purposes and reads a business in two distinct perspectives.
That's why in the previous section I have summarized the relationship between BPD and use case diagram by saying "BPD helps you identify a use cases ". BPD can only give you hints when identifying use cases. There has no rule stating that every task existing in a BPD is equivalent to a use case. But we could elaborate a business process by a use case for automation of a feature by the target system.
In the case study, I will give you some idea about what you should pay attention to when transiting a BPD to a use case diagram. You will then understand how different they are. They sell distilled water for business and home use. The following is a textual description of their water delivery process. To order distilled water, customer either calls the ordering hotline or send us Email.
The customer service assistant who receives the order will check whether the customer is an existing customer or a new one. If the customer has never ordered before, the customer service assistant will create a customer account for him or her before proceeding to water delivery. The delivery of distilled water is carried out once a week on every Wednesday.
So on every Wednesday morning, the customer service assistant will forward orders to the Logistics Department for delivery. Once the manager in the Logistics Department has received the orders, he will arrange the delivery by assigning workers for different orders, printing and posting the schedule.
The workers receive the calls and deliver water to the customer accordingly. A business process model has been created based on the description. Now, you are requested to develop a computer system to optimize the whole process. The first thing you need to do is to develop a use case model. With the help of the BPD, try to develop a use case diagram.
Download Distilled Water Delivery.
How to Find Use Cases from Business Process (BPMN)?
You can also find this file at the bottom of this tutorial. Study the process flow carefully. The process starts when a customer places an order. Here we can think of a use case - Place Order. The use case will help automate the process by providing an interface for customer to place order without the assistance of customer service assistant, help verify customer identity and create account if customer does not exist.
- Use cases or business process maps, what technique to use?
This prompts the Transit Model Element window, where you can select the model to place the use case and actor, and rename them. In this case we are pleased with the names of the use case and the actor. Let's keep them unchanged. This forms a new use case diagram in UeXceler. Go back to the BPD.
Let's consider the task Create Customer Account. In the business process, the customer service assistant needs to create account for every new customer.How to Create Use Case Diagram from Business Process Diagram
In the new system, this can either be a part of the Place Order use case, or be a separate use case triggered by customer service assistant manually. In the real world situation, you should clarify this kind of doubt with the stakeholder because an incorrect use case model will lead to the development of functions that do not match user's expectation.
In this example, let's assume that the user wants the Create Customer Account task be a task done by the customer service assistant. Let's create a use case from it. Again, we are pleased with the name of the use case and actor. Keep everything in the Transit Model Element window unchanged. The use case diagram is updated with a new use case and actor. Let's move on to the sub-process Arrange Delivery.
The manager of the Logistics Department can use the system to perform scheduling and notify workers to deliver water. Therefore, this is also a use case of the system. Check the actor Manager in the Transit Model Element window. If we keep the name of actor as Manager, this is ambiguous in the use case model because there may be many departments with many different managers in the company.
Therefore, rename the actor to Logistic Department Manager. The use case diagram is updated. The final task Deliver Water is a job that can only be done by human and has nothing to do with the system's interaction. Therefore, we do not need to create a use case for it.
Suppose the regional manager wants the system to support a new function that can generate a report to show the statistics on orders. This function can help him review and refine the marketing strategy. Although this function had not been modeled in the business process model, we can draw it directly in the use case diagram. Open the use case diagram.