AN ALGORITHM TO DERIVE USE CASES FROM BUSINESS PROCESSES

Remco M. Dijkman Stef M.M. Joosten University of Twente Ordina Finance Utopics, and P.O. Box 217, 7500 AE Open University of the Netherlands Enschede, The Netherlands P.O. Box 2960, 6401 DL email: [email protected] Heerlen, The Netherlands email: [email protected]

ABSTRACT process models, and to compare these metamodels. The This paper describes an algorithm to transform business comparison of the two metamodels gives rise to a formal process models into a functional requirements mapping that forms the basis for our algorithm. In this specification, specified in the form of use case diagrams. paper we only introduce the metamodels and their formal The benefit of such an algorithm is that it helps to draw up mapping briefly. A detailed overview can be found in [6]. a functional requirements specification more quickly, The remainder of this paper is organized as follows. because business process models may be available in an Section 2 and section 3 briefly introduce use case and enterprise, while use case diagrams have to be developed business process modeling. These sections also present the by performing interviews. The use case diagrams that metamodels of both modeling techniques. Section 4 result from applying the algorithm, specify a software describes a formal mapping between the two metamodels. system that provides automated support for the original Based on this mapping, section 5 defines the actual business processes. We show this with a case study from algorithm. Section 6 explains industrial experience we practice. have with the technique. The paper finishes with some concluding remarks. KEY WORDS Business process modeling, model transformation, 2 UML Use Case Modeling requirements engineering, method engineering A use case diagram describes how an entity may use the system under development. To this end, a use case 1 Introduction diagram contains actors and use cases. An actor is an Requirements engineering is widely considered to be one entity that may interact with the system. A use case is a of the most difficult tasks in software engineering. At the set of interactions between any number of actors and the same time, errors made in this phase are among the most system under development. Thus, a use case describes a difficult to detect and the most expensive to correct [1]. part of the behavior of the system. Therefore, much can be gained from requirements An example of a use case diagram is shown in figure engineering techniques that help to produce robust 1. The ovals represent use cases, and the puppets represent requirements specifications, and speed up the actors. A line between an actor and a use case represents requirements engineering process. In this paper we the actors involvement in one or more of the interactions propose such a technique. The technique shows how use covered by the use case. case based requirements engineering [2, 3, 4, 5] may be When two use cases partly share the same behavior, improved by using business process models as this behavior may be put into a third use case, and the requirements. original two use cases may be defined to ‘include’ the We introduce an algorithm to transform business behavior of this new use case. The description of the process models into use case diagrams. The benefit of original use cases specifies the point at which to include having such an algorithm is that business process models this behavior. The goal of the include relation is to remove are often available in a company in the form of working redundancy. An include relationship is represented by a instructions or administrative handbooks. Therefore, use dashed arrow, labeled «include». case diagrams can be produced more quickly when they When one use case is a generalized form of another are developed with existing business process models and use case, we can draw a generalization relationship the algorithm than when they are developed from scratch. between them. We could, for example, draw a The approach we used to design the algorithm was to generalization relationship from the use case ‘process create metamodels for use case diagrams and for business complaint’ to the use case ‘process incoming mail’.

techniques. From this study we were able to draw up a Enter <> generalized metamodel of business process modeling. Mortgage Figure 3 presents a simplified version of this metamodel. Check Credit Although all business process modeling techniques have Administrative means to model aspects other than behavior, such as Worker Draw up <> organizational structure, and data objects, we will focus Offer Advise on modeling behavior. The reason for this is that use case diagrams do not have means to model aspects other than behavior. Therefore these aspects can not be mapped, and Inform about Advisor Rejection are thus irrelevant in this paper.

Figure 1. Example use case diagram Start End Actor Generalization Branch Model 1 +actor +generalization +specialization Role +responsible * * Element 1 * Task +child * 1 1 +parent +source 1 1 +destination * * +usecase +base Guard Transition Association Use Case * Include +guard

* 1 1 + include 0..1 1 1 1 +addition* +extension 1 1 +extension +base point Figure 3. Business process metamodel * +extend * * Extension Point 1..* * Extend A business process model describes the tasks that have to be carried out to reach a certain goal, and the order in +extension which these tasks have to be carried out. A task is the point smallest unit of work that makes sense to a user. Each task is assigned to a role. A role is a group of entities that have Figure 2. Use case metamodel the same rights and obligations with respect to performing Generalization relation ships can also exist between a task or a group of tasks. A role may be assigned to any actors. The actor `employee', for example, is a number of tasks, and an entity may act in any number of generalization of the actor `administrative worker'. A roles. generalization relationship is represented by a solid line In this paper, we use UML activity diagrams to model with a hollow arrowhead from the specific to the generic business processes. Activity diagrams have been shown to use case or actor. be useful for business process modeling in [11, 12]. An We may describe an extension to a use case's example of an activity diagram that models a business behavior, that is only carried out under a certain condition. process for mortgage processing is shown in figure 4. The To do this, we define an extension relation between this rounded rectangles represent tasks, and the arrows use case, and the use case that describes the extension. If represent transitions between tasks. The names in the at a predefined point (an extension point) in the execution columns represent roles, and a task in the column of a role of the base use case, a specified condition is met, then the represents that this task is assigned to that role. The bullet, extension use case is carried out. An extension relation is and the bulls eye, represent the beginning and the end of represented by a dashed arrow, labeled «extend». the business process respectively. Each use case can be described in detail, by describing We can use a guard to model a condition that must be the interactions between the actors and the system, and the met before starting the next task. A guard could be, for order in which they occur. Many description techniques example, `legal act received'. A guard is graphically exist to detail a use case. We could, for example, use state represented as a label between square brackets on a machines [7], activity diagrams [8], or informal text [9]. transition. In this paper we use activity diagrams both for describing We can use a branch to model a choice on the task that use cases in detail and for business process modeling, has to be started after the current task has finished. A because this makes the transformation algorithm branch has decision criteria attached to it that define under straightforward. which condition, which task is started. Decision criteria The metamodel of a use case diagram is shown in could be, for example, `if amount ≤ 50, start task A, figure 2. It is a simplified version of the metamodel that otherwise start task B'. Decision criteria cannot have can be found in the UML specification [7]. overlapping values. A branch is represented by a diamond with one incoming arrow and at least two outgoing 3 Business Process Modeling arrows. The outgoing arrows have guards attached to them that represent the decision criteria. Many techniques for business process modeling exist. In We can use a fork to model that two or more tasks are an earlier study [10], we studied 18 of the most referenced started in parallel (i.e. are carried out in random order) after the current task has finished. When two or more offer', for example can be a step. `Send offer and process tasks are started in parallel, we may want to wait for all reply' cannot be a step, because time passes between tasks to be finished before going on to the next task. This sending an offer and receiving the reply. Since a step is a can be achieved by using a join. A fork is represented by sequence of tasks that can be performed by the same role an arrow to a thick line, from which arrows leave to the without interruption, users experience a step as a unit of tasks that have to be started. A join is represented by a set work that is completed when it ends, after which it can be of incoming arrows to a thick line, from which an arrow performed again. Therefore, a step does describe a leaves to the task that has to be started next. complete sequence, and can be mapped to a use case. We map `Role' to `Actor', and the association between a step and a role to an association between the Administrative Worker Advisor corresponding actor and use case. Since all tasks in a step are performed by the same role, a role and a step are

Enter Client Data associated when the role is associated to any of the tasks in the step.

Enter Mortgage Data Since a step is defined as a sequence of tasks, each step forms a sub-diagram of the original business process model. Because we decided that use cases are described in Check Credit detail by activity diagrams, we can use the sub-diagrams Approve that are formed by the steps, to detail the use cases that [Disapproved] Mortgage Inform Client correspond to these steps. Also, we call the tasks that about Rejection [Approved] detail a use case: interactions, because a use case model a sequence of interactions between the system and its users. Advise Client The definition of the mapping leads to an integrated metamodel that contains both the use case and the Process Changes business process metamodel. Figure 5 shows this integrated metamodel. To keep the figure simple, it does not show include, extend, or generalization relations

Check Credit between use cases. However, these relations are part of the integrated metamodel. We chose to represent a mapping

Draw up Offer from concept A to concept B by an inheritance relation from B to A. A mapping between two associations can be represented as an OCL constraint. For example, the Figure 4. Example business process model mapping between the association between step and role, and the association between use case and actor, can be We chose to disregard the fork and join construct in represented by the following OCL constraint: this paper to simplify the algorithm. Therefore, task that context Step inv: are actually out in sequence. The fork and join construct self.association.actor → includes(self.responsible) can be added in future work. We also need an OCL constraint that expresses that steps can not contain steps: 4 Mapping context Step inv: self.contains → excludesAll(Step.allInstances) We created a mapping between the two metamodels by assessing from their definitions, which concepts or 5 The Transformation Algorithm relations in the business process metamodel map to which concepts or relations in the use case metamodel. We then From the mapping that we defined in the previous section, defined and evaluated the mapping formally [6]. In this we derived an algorithm to transform a business process section we give an informal description of the mapping. model into a use case diagram. In this section we will The mapping is straightforward, except for finding a explain this algorithm. The algorithm is based on an business process concept that maps to the concept `Use algorithm to create steps from tasks [14]. Case'. We may be tempted to map the `Task' concept to To develop the algorithm, we assume that a set of the `Use Case' concept. However, according to the UML instances exists for each concept in the integrated semantics [7], a use case must describe a complete metamodel. We also assume that a new sequence. This means that a use case specifies all the operator exists, which adds a new instance to the set of interactions that have to be carried out to bring the system instances of the concept that follows the operator, and in a state in which the use case can be performed again. A returns this instance. For example, new Step adds a new task does not enforce this constraint, and thus does not step to steps, and returns this it. describe a complete sequence. Therefore, we introduce the `Step' concept [13]. A step is a sequence of tasks that can be performed by the same role without interruption. `Send Transition Start Guard +guard 1 0..1 * +contains * * End Role 1 +source 1 +destination transition points to a model element in another step. If this +responsible Model Branch 1 * Element step was not yet created, then it will be. If the step was already created, but there exists no start state in this step 1..* +contains that has a transition to the model element, then a start state Actor Task Step and a transition from this start state to the model element have to be added. This procedure is repeated until no new 1 +actors steps are added, and the steps themselves also do not * change anymore. Association Use Case +usecase oldsteps = EmptySet * 1 while oldsteps != steps do oldsteps = steps foreach s in steps do Figure 5. Integrated Metamodel foreach tr in transitions do if tr.source in s and The algorithm should start by identifying the tasks that !tr.processed and tr.destination !in end denote interactions with the system under development, then because only these tasks are interesting from a use case if !tr.timepassing and point of view. In this section we assume that interactions tr.destination.responsible = s.responsible have already been defined, and we refer to [6] for an then elaborate discussion on this topic. After the interactions s.contains += {tr.destination, tr} tr.processed = true have been identified, we do the following. else First, we create an actor for each role in the business if tr.destination !in steps.contains then process model. Step newS = new Step actors = roles newS.responsible = tr.destination.responsible Second, we create steps around the tasks in the Start newSt = new Start business process model. Initially we create steps around Transition newTr = new Transition newTr.source = newSt the tasks that are in the same role and can be reached newTr.destination = tr.destination directly from a start state. We add start states to the newTr.guard = tr.guard newS.contains += created steps to denote where they can start. {newSt, newTr, tr.destination} steps = EmptySet tr.processed = true foreach r in roles do newTr.processed = true if exists m in modelElements where else r = m.responsible and if !exists tr’ in transitions where exists tr in transitions where tr’.source in start and tr.destination = m and tr’.destination = tr.destination tr.source in start then then Start newSt = new Start Step newS = new Step Transition newTr = new Transition Start newSt = new Start newTr.source = newSt newS.contains += {newSt} newTr.destination = tr.destination newS.responsible = r newTr.guard = tr.guard foreach m in modelElements do tr.destination.step.contains += if r = m.responsible then {newSt, newTr} foreach tr in transitions do tr.processed = true if tr.destination = m and newTr.processed = true tr.source in start fi then fi Transition newTr = new Transition fi newTr.source = newSt fi newTr.destination = m od newTr.guard = tr.guard od newS.contains += {newTr, m} od newTr.processed = True Third, we create a use case for each step that we fi od identified. Also, we create an association between an actor fi and a use case when an association exists between the role od fi that corresponds to the actor, and a step that corresponds od to the use case. Each step is then extended with the model elements usecases = steps foreach s in steps do that: (1) have the same responsible role as the step, and (2) Association newA = new Association can be reached from model elements within the step, and newA.actor = (Actor) s.responsible newA.usecase = (UseCase) s (3) can be performed without waiting. We assume that od each transition has a property timepassing that denotes if time passes before the transition can be made. This Fourth, we restructure the use case diagram that results allows us to check (3). The user of the algorithm must from applying the algorithm. This can be done according define the value of this property for each transition. If a to normal restructuring rules, like, the ones described in transition points to a model element with a different [5]. However, when using the algorithm, some constructs responsible role or time passes on a transition, then the need special attention. Therefore, we will point out some restructuring actions that are normally necessary when using the algorithm. Due to space limitations, we only 6 Case Study discuss the restructuring rules informally. First, we found out that tasks are often described In a case study, we applied the algorithm in the mortgage multipletimes. The reason for this is that business process department of a bank, and evaluated the quality of the modeling techniques do not cater for reuse of tasks. resulting use case diagrams by comparing them to use However, in use case diagrams reuse is possible by means case diagrams that were constructed from scratch. From of the include relation. Therefore, we search the use cases the results we derived some recommendations that were for interactions that are defined more than once. We put incorporated in the restructuring step of the algorithm. these interactions in a separate use case, and we draw an In the case study, we investigated a total of 6 business include relation from the original use cases to this separate processes, from which we derived 42 use cases. When use case. comparing the use case diagrams, 17 use cases contained Second, the algorithm does not cater for inclusion, improper constructs: of 2 use cases some of the tasks were extension or generalization of use cases. Therefore, it may defined more than once, 3 use cases were completely be useful to split up some use cases into a base use case redundant, and 12 use cases only delivered a result of and an extension or addition use case, or into one value in combination with another use case. We corrected generalized and multiple specialized use cases. these errors by introducing the restructuring actions that are described in the previous section. A simplified example that shows how a business Enter Mortgage process model was transformed into a use case diagram Data Check Credit during the case study is shown in figure 6. The figure Approve shows two of the use cases that result from applying the Mortgage Enter algorithm to the business process model from figure 4. It Cliente Data shows how each use case is detailed by an activity Administrative diagram that is a part of the original diagram. It also Worker Enter Mortgage shows the transitions that contain information about the [Mortgage Not Approved] relations between the use cases, but that are not part of the [Mortgage Not Approved] use cases themselves. These transitions may be used later Inform Client on to build a system that controls the order in which the Advisor about Rejection use cases may occur (such as a workflow engine).

Inform about Rejection 7 Conclusion Figure 6. Resulting Use Case Diagram In this paper we introduced an algorithm to transform

business process models into UML use case diagrams. Third, according to its definition a use case delivers a The algorithm is based on a formal mapping between the result of value to its user. However, in the case study we metamodels of the two modeling techniques. We have found situations in which users experienced that a use shown in a case study that the application of the algorithm case only delivered a result of value when it was results in use case diagrams that can serve as a basis for combined with another use case. This situation can be further system development. solved by verifying if each use case delivers a result of The study described in this paper is related to the value to its users, and, if not, by combining it with other fields of requirements, and method engineering. Much use cases such that it does. work is done in both fields to study how models of Fourth, the choice to describe use cases that belong to different types can be generated from each other. Research the same business process in one use case diagram is done to how business processes can be described using suggests that each system is built for only one business use case diagrams [5, 7, 16]. We, however, do the process. Also, it suggests that only one system is built for opposite, and use business processes to derive use cases. each business process. However, this is rarely the case. A Eriksson and Penker describe a procedure to derive use client database, for example, is usually used by all cases from business processes that is similar to ours in primary business processes. Therefore, once a use case [15], but less detailed. diagram is drawn, we must evaluate which use cases will The use case diagrams that result from the application be implemented by which system. This decision will be of the procedure have limitations. based on what systems already exist to support other First, use case diagrams specify a typical information business processes. When we decide that a use case is system, in the sense that they do not specify control partly implemented by one system, and partly by another information that is above step level. For example, the use system, we must split up the use case. Eriksson and case diagram from figure 1 does not specify whether client Penker describe a procedure for doing this in [15]. data must be entered before mortgage data or not. Our Fifth, the algorithm does not add end states to the algorithm partly caters for this, but we have not activity diagrams that detail the use cases. To be complete, investigated this thoroughly. we should add end states to these diagrams. Second, the use case diagrams are as detailed as the

business processes from which they have been derived. A use case may, for example, contain the interaction ‘enter [8] M. Fowler, & K. Scott, UML Distilled: Applying the client data’, or the interactions ‘search client’, if the client Standard Object Modeling Language (Reading, MA: was not found ‘create new client data’. The second set of Addison-Wesley, 1997). interactions provides a more precise specification than the [9] J. Rumbaugh, I. Jacobson, & G. Booch, The Unified Modeling Language Reference Manual (Reading, MA: first set of interactions. Therefore, depending on the detail Addison-Wesley, 1999). specified in the business processes, it may be necessary to [10] W. van Dommelen, S. Joosten, & M. de Mol, Comparative perform refine the use case diagrams that result from the Study to Aids for Managing Business Processes (in dutch: algorithm further. The extend to which this is a problem vergelijkend warenonderzoek hulpmiddelen beheersing can not be assessed from one case study. bedrijfsprocessen) (The Hague, The Netherlands: Department of Finance, 1999). REFERENCES [11] G. Booch, J. Rumbaugh, & I. Jacobson, The Unified Modeling Language User Guide (Reading, MA: Addison- [1] B. Boehm, Software Engineering Economics (Englewood Wesley, 1999). Cliffs, NJ: Prentice Hall, 1981). [12] M. Dumas, & A. ter Hofstede, UML activity diagrams as a [2] A. Cockburn, Structuring use cases with goals, Journal of workflow specification language, Proc. UML 2001 Conf. on Object Oriented Programming, 10(7), 1997, 35-40. Modeling Languages, Concepts and Tools, Toronto, Canada, [3] A. Cockburn, Structuring use cases with goals, Journal of 2001, 76-90. Object Oriented Programming, 10(8), 1997, 56-62. [13] S. Joosten, G. Aussems, M. Duitshof, R. Huffmeijer, & E. [4] I. Jakobson, M. Christerson, P. Jonsson, & G. Övergaard, Mulder, An Empirical Study about the Practice of Workflow Object Oriented Software Engineering: A Use Case Driven Management (Enschede, The Netherlands: University of Approach (Workingham, United Kingdom: Addison- Twente, 1994). Wesley, 1992). [14] J. van Beek, Generation Workflow: How Staffware [5] I. Jacobson, G. Booch, & J. Rumbaugh, The Unified Workflow Models can be Generated from Protos Business Software Development Process (Reading, MA: Addison- Models, University of Twente, Enschede, The Netherlands, Wesley, 1999). 2000. [6] R. Dijkman, & S. Joosten, Deriving use case diagrams from [15] H.-E. Eriksson, & M. Penker, Business Modeling with UML: business process models, CTIT Technical Report 02-08, Business Patterns at Work (New York, NY: Wiley, 2000). CTIT, Enschede, The Netherlands, 2002. [16] S. Nurcan, G. Grosz, & C. Souveyet, Describing business [7] OMG, OMG Unified Modeling Language Specification processes with a guided use case approach, Proc. 1998 Conf. version 1.4, OMG Specification formal/2001-09-67, 2001. on Advanced Information Systems Engineering, Pisa, Italy, 1998, 339-362.