A Pattern-Based and Model-Driven Approach for ...

A Pattern-Based and Model-Driven Approach for Deriving IT System Functional Models from Annotated Business Models∗ Javier Berrocal, Jos´e Garc´ıa-Alonso, C. Vicente-Chicote and Juan Manuel Murillo

Abstract Companies increasingly demand IT systems to support (part of) their business. In order to maximize return on investment, these systems need to be perfectly aligned both with the business and with the legacy applications with which they will be integrated. In this vein, this paper presents a pattern-based and model-driven approach for deriving IT system functional models from annotated business models. First, we explain how to annotate the BPMN 2 business models with information useful for deriving the functionalities. Then, we introduce a set of patterns aimed to help identifying the functionalities and the relationships existing among them from the annotated business models. Finally, we present an ATL model transformation that, based on the previous patterns, allows us to obtain UML2 Use Case Diagrams.

1 Introduction In the development of a software system, the business has to be deeply analysed in order to understand the organization’s goals, its tasks and strategies, and the context with which the system has to interact [7]. Thus, the software engineer can clearly identify the system requirements aligned with the business [14]. Currently, there are proposals, such as BPCM [12] or BMM [5], offering some guidelines for documenting this knowledge, so that it can be later analysed to define the system requirements aligned with it. In order to facilitate this analysis, some approaches, such as those proposed by Siqueira [16] and Vara [21], offer different mechanisms for deriving the functional requirements from the business specification. These requirements capture the intended behaviour of the system [22]. ∗ Additional material related to this paper can be found in the following website: http://bpmn2uc.zentipede.org

Javier Berrocal, Jos´e Garc´ıa-Alonso, C. Vicente-Chicote, Juan Manuel Murillo University of Extremadura, Avda. de la Universidad s/n, 10003, e-mail: {jberolm, jgaralo, cristinav, juanmamu}@unex.es

1

However, these approaches do not cover the derivation of the relationships between functionalities or between them and other business elements (e.g., legacy systems). Requirements relationships concern actions performed on one requirement that may affect or interact with other elements [9]. Identifying these relationships in the early stages of the development is crucial to achieve the business-IT alignment. Otherwise, the system might need to be re-implemented or even re-designed [9], usually meaning higher costs and project delays. There are some approaches dealing with the identification of relationships between functional requirements. In particular, [10] and [18], like the present work, are focused on the analysis of business processes. While the aforementioned approaches adequately meet a range of possible relationships, they do not address some situations (e.g., Use Cases covering exception flows) and relationships (e.g., include relationships) that need to be covered to achieve a complete alignment. The work presented in this paper tries to overcome some of these limitations by (1) providing an algorithm for annotating BPMN 2.0 [6] business models with information relevant for extracting IT system functionalities from them; (2) defining a comprehensive set of patterns for deriving the relationships existing among them from the annotated business models; and (3) a set of model transformations implemented in ATL [2] that, relying on the power of Model-Driven Engineering (MDE) techniques [17], and based on the previous patterns, allow us to obtain UML2 Use Case Diagrams. The proposed approach aims to improve the business-IT alignment reducing the risk of system integration problems from the earliest stages. This work is part of a more extensive work that advocates for making the relationships between business elements and requirements explicit, so that they can be reused during the overall system design process [4]. The rest of the paper is organized as follows. Section 2 motivates the research and presents the case study used to illustrate the proposal. Section 3 outlines the overall research line in which this work is framed. Section 4 proposes a method for annotating business processes. Section 5 presents the patterns and the ATL transformations defined for identifying the requirements relationships. Section 6 reviews some related works and Section 7 draws the conclusions and future works.

2 Motivation Business Driven Development is a discipline aimed at developing IT systems aligned with the business [3]. Approaches, such as [12] and [5], support this discipline by specifying how to document the business information. Business processes specified at a business analysis level with these approaches can be used for specifying the functional requirements required to support them [19]. Figure 1 shows a process, modeled with BPMN, for handling the orders of an online-shop. A description of this notation can be found in [1]. This figure only shows the part of the process relevant to the present study. This model gathers information related to the task sequencing, the roles responsibilities, and the input and output data.

Fig. 1 Business process for handling the orders of an online-shop.

Some approaches define methods that facilitate the derivation of Use Cases [10] or Tasks Descriptions [21] from business processes. For example, in [21], the authors define a new BPMN flow connector to specify which tasks are executed consecutively. All consecutive tasks are then mapped to a Task Description. For the online-shop example, the engineer could use this connector to map all the consecutive flow nodes concerning the placing of an order to a Task Description, and all the consecutive flow nodes concerning its validation to another one. For improving business-IT alignment, it is not enough to extract functional requirements from business models; it is also essential to explicitly identify the relationships among them. For instance, in the online-shop example, let us associate a Use Case to each of the two Task Descriptions previously described (order placement and order validation, respectively). As shown in Figure 1, if any order is modified before being validated, it is made again. In order to document this interaction, a relationship between the two Use Cases needs to be defined. If it is missed, a source of misalignment will be introduced that will need to be corrected in a later stage. Currently, some works define patterns for deriving the relationships between Use Cases from process models. In [10] and [18] two patterns are defined. Although these patterns are really useful, some relations are beyond their control (e.g., the relations between Use Cases identified in exception or in parallel flows). For example, in the online-shop example, two flows are merged into one by a parallel gateway. If these flows are supported by different Use Cases, there should be an include relationship between them. This relation cannot be identified by the previous patterns. In order to overcome this limitation, we have identified additional patterns addressing different situations for which relationships can be derived from the business models. Furthermore, some of these new patterns also take into account the relations between requirements and other business elements, such as legacy systems. These relations can help avoiding system integration problems in later development stages.

3 Annotating the Business Processes for Deriving the System Functionalities and Design The research presented in this paper is part of a more extensive work aimed to make the relationships between business elements and between requirements explicit, so that they can be reused during the system design. A complete specification of the work can be found in [4]. This work proposes new activities focused on the specification and analysis of these relations. These activities are the following: • Model the context information. The business processes are annotated with information, firstly, on the relationships between process tasks and business goals or legacy systems and, secondly, on the system functionalities that are going to support the business tasks. A set of annotations has been defined to model this information. These annotations are added to the model by the engineer. • Define the requirements relationships. The relationships between the system requirements are specified. To identify these relationships from the previously annotated business processes, a set of patterns and ATL model transformations have been defined. In addition, these transformations automatically derive the system functional models. • Analyse the requirements relationships. The requirements and their relationships are analysed with the aim of delimiting the architectural patterns that facilitate their fulfilment. We have defined model transformations to facilitate this task. This paper focuses on part of the first and second activities. Specifically, for the first activity, it indicates how the business tasks are annotated with the functional requirements and the legacy systems that support them. For the second one, it details how to automatically derive the system functionalities and their relationships.

4 Annotating the Business Processes This section describes the methodology guiding the business expert and the requirements engineer in the annotation of the business processes (activity 1 in Section 3). These annotations document the legacy systems and the Use Cases that are going to support each business task. Once the processes have been modeled, using some of the techniques previously indicated, first, the engineers should indicate what business tasks are already supported by legacy systems. In order to model this information the Group artifact is used. This artifact groups flow elements by a specific criterion. This criterion is specified by the CategoryValue attribute. Each Legacy System (LS) is modeled in the business process using a group with Category “LS” and Value “the LS’s name”. Figure 2 shows the online-shop example process annotated with the legacy system “LS:Stock Control”. This legacy system supports the “Restore Stocks” subprocess and the “Reject Order” task. Thus, the points in which the new system has to interact with this legacy system are also apparent in Figure 2.

Fig. 2 The online shop example process annotated with the BUCs.

Subsequently, the support the new system is going to provide to each business task has to be defined. To do so, the engineers and the business experts have to discuss what tasks are going to be automated, which are going to be performed with the support of the system, and which are going to be done manually. To model this information, a task is annotated as Service Task if it is going to be automated, User Task if it is going to be supported, or Manual Task if it is going to be done manually. Figure 2 shows the online-shop example process annotated with the kind of support that the system has to provide to each task. For example, the tasks “Make Order” and “Validate Order” have been defined as supported tasks. The next step is the identification of the system functionalities required to support the process. For that purpose an algorithm is proposed. The algorithm ensures that Business Use Cases (BUC)2 are identified at a proper granularity. It is based on the Cockburn’s “Coffee-break” rule [8] and on the “Step” concept [10]. Both rules indicate that a Use Case is a set of tasks that an actor can do without interruption. The following pseudo-code presents the proposed algorithm. As we did before with the legacy systems, we use the Group artifact to model each identified BUC. The Category of all these groups is “BUC” and their Value is “the BUC‘s name”. Algorithm for the identification of Business Use Cases 1. Begin with the first element of the business process. 2. All consecutive flow elements are part of the same BUC. 2

The term “Business Use Case” is used here to group business tasks, even though it is similar to the term System Use Case [8].

3. A BUC ends when: A. The control flow passes from one Lane to another. B. There is a time transition between tasks. This is: I. There is a task marked as manual. II. There is an intermediary event or a sub-process. III. There is a communication with an external agent. This indicates the start (input of data) or end (output of data) of the BUC. IV. There is a task performed by a legacy system. C. The end of the process is reached

Figure 2 also shows the BUCs identified for the online-shop process. For instance, the “BUC: Check Order” groups the elements for checking the order until the result is sent to the customer. Modeling these elements in the BPMN diagrams provides the engineer with a first approximation to the system functionalities, and facilitates their discussion with the business experts. The annotation of the business process is a guided set of activities in which the business expert and the requirements engineer have to analise them in order to annotate the business tasks. Nevertheless, the identification of the business tasks already supported by legacy systems can be semi-automated [15]. Also, the algorithm for the identification of BUCs can be implemented in order to provide a possible set of functionalities supporting the process tasks.

5 Deriving the Functional Requirements and their Relationships This section details how the new IT system functional requirements (defined using a Use Case Diagram) and the relationships among them are automatically derived from the annotated business processes by means of an ATL model transformation.

5.1 Deriving the Use Cases Once the BUCs have been modeled, it is possible to derive a Use Case Diagram from the annotated processes. First, the actors are extracted. These are the roles responsible for each business task (modeled in BPMN with Pools or Lanes), and the legacy systems with which the new IT system has to interact (modeled with the Group artifact and the LS category). Then, each BUC is mapped to a Use Case. rule lane2Actor{ from lane : inMM!Lane to actor: outMM!Actor ( name