MASTER THESIS AUTOMATED BEHAVIOUR REFINEMENT USING INTERACTION PATTERNS C.J.H. Weeïnk FACULTY OF ELECTRICAL ENGINEERING, MATHEMATICS AND COMPUTER SCIENCE SOFTWARE ENGINEERING EXAMINATION COMMITTEE dr. L. Ferreira Pires L.M. Daniele MSc dr. I. Kurtev DOCUMENT NUMBER EWI/SE 2011-003 MAY 2011
Abstract Nowadays, mobile devices can obtain information that characterizes the environment of their users from a variety of sources. Applications running on these devices can use this information to anticipate future user actions and adapt their behaviour according to changes in this information. However, application functionality concerns easily become affected with implementation-specific concerns, such as acquiring this information. A model-driven approach can be used to separate application functionality from any technology-specific detail. Model transformations allow designers to gradually add these details, eventually resulting in complete applications. We consider in this work an approach that divides the specification of application behaviour in several abstraction levels, with increasing levels of detail. At a higher abstraction level, this approach considers the internal structure of an application and interactions between the components. At a lower abstraction level, it describes the internal behaviour of components as well. The models at these levels use reusable sequences of actions, called interaction patterns, to compose application behaviour. In this work, we define an automatic behaviour transformation that refines models at a higher abstraction level into models at a lower abstraction level, in the context of this approach. This transformation derives a the internal behaviour of a component by mapping interaction patterns in the former model to more detailed interaction patterns in the latter, and preserving the interactions represented at the higher level. We show that we have been able to successfully apply the automation of the refinement to a case study, although our approach still has some limitations.
Preface This thesis presents the results of the final project I carried out. It marks the end of an era, since I will be moving from being a student into a professional career. I would like to thank all people who have supported and helped me. Especially, I would like to thank Luís Ferreira Pires, Laura Daniele, and Ivan Kurtev for their supervision. The discussions, insights, and feedback on my writing really helped me driving this work. Furthermore, I would like to thank my family, especially my parents and brother, for supporting me and believing in me all these years throughout university. Finally, I would like to thank all my friends who have supported and helped me in various ways during my time as a student. Chris Weeïnk Enschede, May 2011
Table of contents List of abbreviations... ix List of figures... xi List of tables... xv Chapter 1 Introduction... 1 1.1 Motivation... 1 1.2 Objective... 2 1.3 Approach... 3 1.4 Contributions... 3 1.5 Outline... 4 Chapter 2 Background... 5 2.1 Models... 5 2.2 Model transformations... 6 2.3 Behaviour modelling... 7 2.4 Choreographies and orchestrations... 10 2.5 Correctness verification... 11 2.6 Conclusions... 11 Chapter 3 Behaviour modelling with BPMN... 13 3.1 Overview... 13 3.2 Choreography... 14 3.3 Process... 18 3.4 Collaboration... 21 3.5 Conclusions... 22
vi Table of contents Chapter 4 Interaction pattern refinement...23 4.1 Overview... 23 4.2 Basic patterns... 24 4.2.1 One-way... 26 4.2.2 Two-way... 27 4.3 Composite patterns... 28 4.4 Gateways... 30 4.4.1 Exclusive gateway... 31 4.4.2 Event-based gateway... 32 4.4.3 Parallel gateway... 33 4.5 Events... 34 4.5.1 None events... 34 4.5.2 Timer events... 35 4.5.3 Signal events... 36 4.6 Conclusions... 37 Chapter 5 Choreography refinement... 39 5.1 Overview... 39 5.2 Sequences... 40 5.3 Gateways... 41 5.4 Choreography models... 43 5.5 Related work... 44 5.6 Conclusions... 45 Chapter 6 Case study... 47 6.1 Introduction... 47 6.2 Results... 48 6.3 Generalizing the results... 53 6.4 Implementation... 58 6.5 Discussion... 58 6.6 Conclusions... 60 Chapter 7 Conclusions... 61 7.1 MDA-based methodology... 61 7.2 Behaviour refinement... 62 7.3 Case study... 63 7.4 Future work... 64 Bibliography... 65
Table of contents vii Appendix A Basic pattern mappings... 69 A.1... 69 A.2...70 A.3 Acceptance... 71 A.4 Rejection... 73 A.5 Search... 74 A.6 Update...76 A.7 Discover... 77 A.8 Service...78 A.9 Invoke...79 A.10 Set... 81 A.11 Alarm...82 A.12 Alert... 83 A.13 Context Query... 84 A.14 Subscribe... 86 A.15 Subscribe Event...87 A.16 Unsubscribe... 88 A.17 Unsubscribe Event... 89
List of abbreviations ATL ATLAS Transformation Language BPEL Business Process Execution Language BPMN Business Process Model and Notation version 2.0 CIM Computation-Independent Model CORBA Common Object Broker Architecture GPS Global Positioning System IM Instant Messaging MDA Model-Driven Architecture MOF Meta Object Facility OMG Object Management Group owfns Open Workflow Nets PDAs Personal Digital Assistants PIM Platform-Independent Model PNDs Personal Navigation Devices PSM Platform-Specific Model QVT Query/View/Transformation SDCM Service Design Component Model SDRM Service Design Refined Model SOA Service-Oriented Architecture SS Service Specification UML Unified Modelling Language
List of figures Figure 1.1. Thesis outline.... 4 Figure 2.1. Generic model transformation approach.... 6 Figure 2.2. Classes of model transformations.... 7 Figure 2.3. PIM design of the A-MUSE MDA-approach.... 9 Figure 2.4. Basic pattern representing a one-way interaction.... 9 Figure 2.5. Basic pattern representing a two-way interaction.... 9 Figure 2.6. Composite pattern with two basic patterns.... 10 Figure 2.7. Refinement approach.... 11 Figure 2.8. Refinement approach with correctness verification.... 11 Figure 3.1. A choreography model with one interaction.... 14 Figure 3.2. A collapsed sub-choreography... 15 Figure 3.3. An expanded sub-choreography.... 15 Figure 3.4. A call choreography.... 15 Figure 3.5. A data-based decision with two alternatives.... 16 Figure 3.6. An event-based gateway with two alternatives.... 17 Figure 3.7. A parallel gateway with two parallel flows.... 17 Figure 3.8. A choreography model with multiple events.... 17 Figure 3.9. A text annotation for a start event.... 18 Figure 3.10. A process model with one activity.... 19 Figure 3.11. An expanded sub-process with send and receive tasks.... 19 Figure 3.12. A process model with intermediate catch and throw events.... 20 Figure 3.13. A process model with data.... 20 Figure 3.14. A collaboration model with two message exchanges.... 21 Figure 3.15. A collaboration model with processes... 21 Figure 3.16. A pool with lanes.... 22 Figure 4.1. Interaction pattern refinement transformation overview.... 24 Figure 4.2. Overview of the pattern transformation specification.... 24 Figure 4.3. Abstract basic pattern representing a one-way interaction.... 25 Figure 4.4. Executable basic pattern representing a one-way interaction.... 25
xii List of figures Figure 4.5. Mapping of a one-way basic pattern with data.... 26 Figure 4.6. Mapping of a one-way basic pattern without data.... 26 Figure 4.7. Mapping of a two-way basic pattern.... 27 Figure 4.8. A composite pattern represented as a sub- and call choreography.... 29 Figure 4.9. A composite pattern with its internal composition.... 29 Figure 4.10. Mapping of a composite pattern.... 30 Figure 4.11. Mapping of exclusive gateways.... 31 Figure 4.12. Mapping of event-based gateways.... 32 Figure 4.13. Mapping of parallel gateways.... 33 Figure 4.14. Mapping of none events.... 34 Figure 4.15. Mapping of timer events.... 35 Figure 4.16. Mapping of signal events.... 36 Figure 5.1. Overview of the composition transformation specification.... 40 Figure 5.2. Refinement of an interaction pattern sequence for Participant A.... 41 Figure 5.3. Refinement of a gateway for Participant A.... 42 Figure 5.4. Mapping of a choreography model.... 43 Figure 6.1. Architecture of the case study.... 48 Figure 6.2. Composite pattern Remove Buddy at the SDRM level.... 49 Figure 6.3. Composite pattern Remove Buddy at the SDCM level.... 49 Figure 6.4. Mapping of basic pattern.... 50 Figure 6.5. Mapping of basic pattern Search.... 50 Figure 6.6. Mapping of basic pattern Update.... 51 Figure 6.7. Mapping of basic pattern Acceptance.... 52 Figure 6.8. Composition of abstract basic patterns.... 52 Figure 6.9. Composition of executable basic patterns.... 52 Figure 6.10. Abstract interaction pattern Update with message data.... 53 Figure 6.11. Abstract pattern User with Acceptance or Rejection.... 54 Figure 6.12. Executable pattern User with Acceptance or Rejection.... 55 Figure 6.13. Mapping of the reusable basic pattern.... 55 Figure 6.14. Mapping of the reusable basic pattern Search.... 56 Figure 6.15. Mapping of the reusable basic pattern Update... 57 Figure 6.16. Invalid event-based gateway refinement.... 59 Figure A.1. Mapping of basic pattern.... 69 Figure A.2. Mapping of basic pattern without arguments.... 70 Figure A.3. Mapping of basic pattern.... 71 Figure A.4. Mapping of basic pattern Acceptance.... 72 Figure A.5. Mapping of basic pattern Acceptance without arguments... 72 Figure A.6. Mapping of basic pattern Rejection.... 73 Figure A.7. Mapping of basic pattern Rejection without arguments.... 74 Figure A.8. Mapping of basic pattern Search.... 74 Figure A.9. Mapping of basic pattern Update.... 76 Figure A.10. Mapping of basic pattern Discover.... 77
List of figures xiii Figure A.11. Mapping of basic pattern Service.... 78 Figure A.12. Mapping of basic pattern Invoke....80 Figure A.13. Mapping of basic pattern Invoke without arguments.... 81 Figure A.14. Mapping of basic pattern Set.... 81 Figure A.15. Mapping of basic pattern Alarm.... 82 Figure A.16. Mapping of basic pattern Alert.... 83 Figure A.17. Mapping of basic pattern Context Query.... 84 Figure A.18. Mapping of basic pattern Subscribe....86 Figure A.19. Mapping of basic pattern Subscribe Event.... 87 Figure A.20. Mapping of basic pattern Unsubscribe.... 88 Figure A.21. Mapping of basic pattern Unsubscribe Event....89
List of tables Table 4.1. Mapping of elements from a one-way basic pattern with data.... 26 Table 4.2. Mapping of elements from a two-way basic pattern.... 28 Table 4.3. Mapping of elements from a composite pattern.... 30 Table 4.4. Mapping of elements from exclusive gateways.... 31 Table 4.5. Mapping of elements from event-based gateways.... 32 Table 4.6. Mapping of elements from parallel gateways.... 33 Table 4.7. Mapping of elements from none events.... 34 Table 4.8. Mapping of elements from timer events.... 35 Table 4.9. Mapping of elements from signal events.... 36 Table 5.1. Mapping of sequence flow elements in sequences for Participant A.... 41 Table 5.2. Mapping of sequence flow elements in gateways for Participant A.... 42 Table 5.3. Mapping of elements from choreography models.... 44 Table A.1. Mapping of elements from basic pattern.... 70 Table A.2. Mapping of elements from basic pattern.... 71 Table A.3. Mapping of elements from basic pattern Acceptance.... 72 Table A.4. Mapping of elements from basic pattern Rejection.... 73 Table A.5. Mapping of elements from basic pattern Search.... 75 Table A.6. Mapping of elements from basic pattern Update.... 76 Table A.7. Mapping of elements from basic pattern Discover.... 77 Table A.8. Mapping of elements from basic pattern Service.... 79 Table A.9. Mapping of elements from basic pattern Invoke....80 Table A.10. Mapping of elements from basic pattern Set.... 81 Table A.11. Mapping of elements from basic pattern Alarm.... 82 Table A.12. Mapping of elements from basic pattern Alert.... 83 Table A.13. Mapping of elements from basic pattern Context Query.... 85 Table A.14. Mapping of elements from basic pattern Subscribe....86 Table A.15. Mapping of elements from basic pattern Subscribe Event.... 87 Table A.16. Mapping of elements from basic pattern Unsubscribe.... 88 Table A.17. Mapping of elements from basic pattern Unsubscribe Event....90
Chapter 1 Introduction Models can be used for several purposes in software development, such as reasoning about system parts and promoting communication between stakeholders involved in the development process. In any case, models always have a purpose. Models that describe the static structure and the dynamic behaviour of the system should be used in the development process of software systems [1]. Depending on the purpose of the models, some details can become irrelevant for that purpose. For example, an abstract model that specifies system requirements may leave out details specific to the technology used to realize the system. More refined models that add technical details can be used later in the development process for implementation purposes using a specific technology. This work aims at automating the refinement of abstract behaviour models into more concrete models of the system under development. The structure of this chapter is the following: Section 1.1 presents the motivation of this work. Section 1.2 discusses our research objective, Section 1.3 describes the approach we have followed to reach this objective, Section 1.4 outlines the scientific contributions of this work, and finally, Section 1.5 presents the structure of this report. 1.1 Motivation Nowadays people use a broad range of mobile devices, such as mobile phones, Personal Digital Assistants (PDAs), and Personal Navigation Devices (PNDs) for a variety of purposes. People can stay in contact with their friends via telephone, e-mail, text messaging, Instant Messaging (IM), or through social networks. In addition, people use these devices to obtain different type of information, such as the weather at the user s location, additional information about a point of interest, and routes to these points. Sensors integrated in these devices can detect changes in the user s environment. Examples of these sensors are compasses, accelerometers, light and proximity sensors, and Global Positioning System (GPS) sensors. The information provided by these sensors can be used as context information to characterize the situation of a person, place, or object that is relevant to the interaction between a user and an application [2]. Context information is used by context-aware mobile
2 Chapter 1. Introduction applications to anticipate future user actions [3], adapt the application behaviour according to changes in this information, manipulate this information, and interact with the environment in order to obtain this information. For example, a contextaware device may mute itself, without explicit user intervention, if its user is in a movie theatre. Since context-aware applications obtain their context information from a variety of context information sources, application functionality concerns can easily be affected by implementation specific concerns, such as acquiring information from the context sources. This results in complex applications that are hard to maintain and extend. Model-Driven Architecture (MDA) [4, 5] principles can be used to facilitate the development of these applications by separating application functionality from any technology-specific detail. In this way, models provide a more comprehensible view of the application and become essential development artefacts in the design process. In [6] an MDA-based approach for the development of context-aware mobile applications is described. This approach divides the specification of application behaviour in several abstraction levels with different degrees of platformindependence. By using model transformations, the approach allows one to refine models at a higher abstraction level into models at a lower abstraction level. The highest level of abstraction describes application behaviour from an external perspective, abstracting from implementation-specific concerns. An intermediate abstraction level considers the internal structure of an application and the interactions between application components. Finally, the lowest abstraction level describes the internal behaviour of application components, by preserving the interactions represented at the intermediate level. Recurring sequences of interactions between components, called interaction patterns [6, 7, 8], have been identified during the development process to facilitate the automation of transformations between models at different abstraction levels. Interaction patterns can be composed into more complex behaviour using connectors. A first attempt to synthesize the behaviour of individual components using state machines is presented in [9]. This attempt identified several concurrency and synchronization issues that should be handled at design time to guarantee correct execution, regardless of the target technology. 1.2 Objective This work addresses the automation of a behaviour refinement from a model at a higher abstraction level, which represents the interactions that occur among application components in terms of interaction patterns, into a model at a lower abstraction level, which represents the realizations of these interactions as executable patterns. While the former model represents a behaviour with no internal details of specific components, namely from a global perspective, the latter represents this behaviour considering the internal details of a specific component, namely from a local perspective.
Chapter 1. Introduction 3 To achieve this, we define the following main objective: Define automatic behaviour transformations to refine an abstract behaviour model, which represents interactions between components from a global perspective, into more detailed models that represent these interactions from the local perspective of individual components, using interaction patterns. In [6, 9] the manual refinement of these transformations has been addressed to learn how they could possibly be automated. By using this knowledge, we were able to define a transformation specification for this refinement and automate it. Interaction patterns allowed us enforcing reuse during the automation 1.3 Approach In order to achieve our objective, we have performed the following steps: 1. We identified a model reduction technique and formalism to refine models that represent interactions from a global perspective into models that represent these interactions from the local perspective of individual components. 2. We used this formalism to define a transformation specification for the behaviour refinement. Based on this specification we implemented the transformation using a model transformation language and tool. 3. We applied the implementation of this behaviour refinement to a case study. In this way, we were able to test the applicability of the behaviour refinement in practice. 1.4 Contributions Our work contributes to behaviour modelling and transformations in model-driven development, in the following way: By defining a transformation specification to automate the refinement of behaviour models at a high abstraction level, which represent interactions between components from a global perspective, into models at a lower abstraction level that represent the internal behaviour of the components, preserving these interactions. In contrast to a manual refinement, our automation is more consistent and precise. For example, it refines model elements of a certain type always in the same way, while a human may produce typographical errors that are hard to detect. Furthermore, our automation does not require designers to have knowledge about how to generate models at low abstraction levels. By formalizing the transformation specification using the ATLAS Transformation Language (ATL) [10]. This ensures that the transformation specifications are unambiguous, and it enables their reuse across applications.
4 Chapter 1. Introduction 1.5 Outline Figure 1.1 shows the organisation of the remainder of this work. Chapter 2 Background Chapter 3 Behaviour modelling with BPMN Chapter 4 Interaction pattern refinement Chapter 6 Case study Chapter 5 Choreography refinement Chapter 7 Conclusions Figure 1.1. Thesis outline. Chapter 2 provides the background required for understanding our behaviour refinement problem. It introduces MDA, interaction patterns, and the modeldriven approach used in this work. Chapter 3 presents the most important concepts of Business Process Model and Notation version 2.0 (BPMN) [11], which we use to model behaviour throughout this work. Chapter 4 presents interaction patterns and connectors using BPMN. This chapter also discusses the mappings of these interaction patterns and connectors from a source model that represents interactions between components from a global perspective, onto a target model that represents these interactions from the local perspective of individual components. Chapter 5 discusses how to combine interaction patterns in more complex behaviours using connectors. This chapter also discusses the mappings of complex behaviours from a global to a local perspective, similarly to Chapter 4. Finally, it presents directions for future work. Chapter 6 demonstrates the applicability of the mappings defined in Chapter 4 and Chapter 5 by applying them to a case study in order to derive an application as a proof-of-concept. Chapter 7 presents the conclusions of our work and positions our work with respect to other scientific contributions.
Chapter 2 Background This chapter provides the background required for understanding the behaviour refinement problem. Section 2.1 and Section 2.2 present the basic concepts models and model transformations, which are necessary to understand this work. Section 2.3 presents interaction patterns as a way to incorporate behaviour in models as well as the model-driven approach used in this work. Section 2.4 relates this approach to the domain of Service-Oriented Architecture. Finally, Section 2.5 discusses correctness verification in combination with refinements. 2.1 Models Model-Driven Architecture (MDA) [4, 5] is a software development approach defined by the Object Management Group (OMG) [12] that prescribes the use of models as essential development artefacts, and separates the specification of the functionality of a system from the specification of its implementation [4]. This ensures that changes in the platforms and technologies used for realizations do not influence the functional specifications of the system. In addition, this separation allows developers to derive multiple implementations from one functional specification, by using different target platforms or technologies. In MDA, a model is a specification that describes the function, structure, or behaviour of a system [4]. It is written in a language that is represented by a metamodel, to enable automatic reasoning. A metamodel is the representation of the abstract syntax of the modelling language, and defines the elements that can be used in a model. Since models provide abstractions of systems, they allow designers to reason about a system by describing only the characteristics of interest. MDA defines three classes of models at different abstraction levels: Computation-Independent Model (CIM) A CIM describes the environment, or business domain, of a system and does not contain any details of the software system s internals. Platform-Independent Model (PIM) A PIM defines a system at a high abstraction level, independent of any realization platform or technology. In principle, one PIM can be realized by different PSMs.
6 Chapter 2. Background Platform-Specific Model (PSM) A PSM defines a system in terms of the technical details necessary to realize a PIM with some platform-specific technology. If a PSM provides sufficient level of detail, it can be executed directly or transformed to code. While MDA defines three classes of models, we only use the concepts of PIM and PSM. To illustrate these concepts, consider a model that describes the components of an application communicating through a client-server structure, but without any details of their realization. Another model can describe the communication between these components through a specific technology, such as web services [13] or Common Object Broker Architecture (CORBA) [14]. When considering these technologies as a platform, the first model represents a PIM and the second a PSM. Furthermore, different programming languages, such as C++ and Java, can be used to implement the communication described in models with these technologies. By considering these programming languages as a platform, the second model represents a PIM instead and the programming code represents a PSM. Therefore, the level of platform-independence depends on the concept of platform considered. 2.2 Model transformations Another important concept in MDA is model transformation, which consists of the (semi-)automatic generation of a target model from a source model, according to a transformation specification [5]. This transformation specification is written in a model transformation language. It relates elements of a source model to elements of a target model for reusability, by establishing traceability links between them. These traceability links allow elements of a target model to be traced back to the corresponding elements of the source model. Since transformation specifications have to be specified in an unambiguous way in order to be executed, they are models as well. Figure 2.1 shows the relations between models, metamodels, and model transformations with the transformation of a source model M a into a target model M b according to a transformation specification T a b. Conforms to Conforms to MMM Conforms to Conforms to MMa MMt MMb Conforms to Conforms to Uses Ta b Uses Conforms to Input Ma Input Transformation Output Mb Figure 2.1. Generic model transformation approach.
Chapter 2. Background 7 As shown in Figure 2.1, the source and target models conform to the metamodels MM a and MM b respectively. Although these metamodels have different names in Figure 2.1, in general they may refer to the same metamodel. Both metamodels conform to the MMM metametamodel, which can conform to any other metamodel again, creating a possible infinite metamodel hierarchy. The transformation specification T a b conforms to a metamodel MM t, which represents the model transformation language used. In our case, we use the ATLAS Transformation Language (ATL) [10, 15] as the model transformation language to define transformation specifications such as T a b. ATL has been developed according to the OMG Query/View/Transformation (QVT) requirements, and is specified as a metamodel and as a textual syntax that conforms to this metamodel. In this way, developers can specify their transformations using the textual syntax, and reason about it like with any other model. ATL tools include editors to define transformations using the textual syntax, but also a transformation engine that is able to execute these transformations on model instances. Model transformations can be classified depending on their purpose in the development of a system. For example, Figure 2.2 shows a transformation T 1 from a model M 1 at abstraction level A 1 to a model M 2 at abstraction level A 2, as well as a transformation T 2 from model M 1 to another model M 3 at the same abstraction level. Abstraction level A1 M1 T2 M3 T1 Abstraction level A2 M2 Figure 2.2. Classes of model transformations. As shown in Figure 2.2, two classes of model transformations can be identified by considering the abstraction levels of the source and target models: Vertical transformation A transformation where the source and target models belong to consecutive abstraction levels, such as transformation T 1 in Figure 2.2. Examples of vertical transformations are the refinement of an abstract model into a detailed model, or the realization of a PIM with a specific technology in order to obtain a PSM. Horizontal transformation A transformation where the source and target models belong to the same abstraction level, such as transformation T 2 in Figure 2.2. Examples of horizontal transformations are the addition of new features to a model, or the change of notation from one programming language to another. 2.3 Behaviour modelling Since MDA allows the separation of the functionality of a system from its implementation, PIMs should include all information necessary to generate executable code or execute the model [4, 16]. Since they define complete software
8 Chapter 2. Background systems independently of any realization platform or technology, these models can already be analysed and tested in the early phases of software design. However, these models need to incorporate behaviour as well. Various modelling notations for behaviour exist, such as in the Unified Modelling Language (UML). UML alone already allows one to represent behaviour as activity diagrams, sequence diagrams, or state machines. However, UML offers poor support for modelling different levels of abstraction and refinement, and lacks a commonly agreed formal semantics [17]. To overcome these problems, the A-MUSE project [18] proposed a design methodology based on MDA that incorporates behaviour aspects already in the PIM design. This approach has been applied to the behaviour modelling of distributed context-aware mobile applications. It divides the PIM design in three models, which have a gradually increasing level of detail: Service Specification (SS) Defines the system s behaviour from an external perspective, by representing the system as a black box that hides any implementation-specific constructs. The SS shows how the environment, which consists of users as well as other services, and the system interact with each other. The domain concepts that are being used in the behavioural model are defined in a separate information model. Service Design Refined Model (SDRM) Refines the SS in terms of a structured behaviour, by defining the system as a set of interacting components, while representing these components as black boxes. The SDRM is derived from the SS by mapping each action of the SS to interactions between components, which realize the action. The domain concepts that are being used in the behavioural model are defined in the same information model as in the SS. Service Design Component Model (SDCM) Refines the SDRM in terms of an executable behaviour, by defining the system as a set of interacting components with internal behaviour. The SDCM defines detailed platformindependent executable behaviour of the system s components, which can be realized directly by platform-specific tools and technologies. The SDCM is derived from the SDRM by mapping each interaction of the SDRM to internal component behaviours that preserve the original interaction. The domain concepts that are being used in the SDCM are the same as in the SDRM. Figure 2.3 illustrates the PIM design of the A-MUSE approach, by showing the three models with gradually increasing levels of detail from SS to SDCM, which are derived from each other through model transformations. The SS represents a system S with some Inputs and Outputs. This system is refined with a transformation T 1 to a system S that consists of the components C 1, C 2, and C 3 with four interactions. The resulting SDRM model preserves the original Inputs and Outputs. After transformation T 2, these components include several connected elements that represent their internal behaviours. The resulting SDCM model preserves the interactions between the components as well.
Chapter 2. Background 9 Inputs S Outputs SS T1 Inputs C1 C2 C3 S Outputs SDRM T2 Inputs C1 C2 C3 SDCM S Outputs Figure 2.3. PIM design of the A-MUSE MDA-approach. Interactions between the system s components are defined in terms of interaction patterns in the SDRM and SDCM models. Interaction patterns represent sequences of actions performed by two or more interacting components defined from the internal perspective of the system [6]. Interaction patterns are reusable pieces of behaviour at certain abstraction levels, which designers can use to compose a system s behaviour. Furthermore, connectors allow designers to define complex behaviour with alternative or parallel paths. During the design, transformation T 2 refines interaction patterns at a high abstraction level in patterns at a lower abstraction level. By replacing the latter with other interaction patterns, different architectures or behaviour can realize one model. Interaction patterns are either basic or composite. Basic patterns represent interactions between only two components, while composite patterns combine multiple basic patterns with connectors in order to represent interactions between more than two components. An example basic pattern named P 1 is shown in Figure 2.4, which represents an interaction where a component named C 1 sends a request to another component named C 2. Since C 1 sends a request to C 2, which does not send a response back, this type of interaction is referred to as a one-way interaction. C1 C2 P1 Figure 2.4. Basic pattern representing a one-way interaction. Another basic pattern named P 2 is shown in Figure 2.5, which represents an interaction where a component C 3 sends a response back after a request of component C 2. This type of interaction is referred to as a two-way interaction. C2 C3 P2 Figure 2.5. Basic pattern representing a two-way interaction.
10 Chapter 2. Background Figure 2.6 shows an example of a composite pattern named P 3, which combines the basic patterns of Figure 2.4 and Figure 2.5. The composite pattern specifies that basic pattern P 2 occurs after basic pattern P 1. P1 P2 P3 Figure 2.6. Composite pattern with two basic patterns. 2.4 Choreographies and orchestrations In the Service-Oriented Architecture (SOA) [13] domain, choreography models define collaborations between systems that achieve a particular goal from the perspective of a global observer who oversees all interactions [19, 20, 21]. This perspective is also referred to as global perspective and it entails all interactions between components that are required to meet the goal of the choreography model [20]. Since SDRM models define a system s behaviour as interactions between its components, we can view these models as choreography models [17]. In SOA, orchestration models focus on the perspective of a particular system, and define only the communication and internal actions involving this system [19, 20, 21]. This perspective is also referred to as local perspective [21]. Since SDCM models define a system s behaviour as interacting components with internal behaviour, we can view these models as sets of orchestration models connected through message links [17]. Since choreography and orchestration models are strongly related, an MDA-based approach can facilitate their reuse during the design of systems. By using model transformations to specify the refinement of choreography models into orchestration models, knowledge captured in the choreography models can be reused by creating traceability links between these models. With these traceability links, designers can focus on the abstraction level that is appropriate for the design phase of a system. Furthermore, designers can take advantage of models they created before. Since choreography models only define interactions between systems, refining them to orchestration models would only result in communication actions and not in internal actions. However, by representing interactions in choreography and orchestration models with interaction patterns, it is possible to represent complete behaviours of systems that include internal actions as well. By providing mappings that define the refinement of specific interaction patterns separately, the refinement transformation can be applied to different applications and architectures. This separation enables developers to derive different orchestration models from the same choreography model as well. Figure 2.7 illustrates this refinement approach, by showing a choreography model that is composed of Abstract interaction patterns, and refined to orchestration models that are composed of Executable interaction patterns. Separate mappings define the refinement of the interaction patterns, which are used by the refinement transformation to derive orchestration models. These interaction patterns are defined at a higher and lower abstraction level, respectively. In the remainder of this work, we refer to these pattern names to indicate the abstraction level.
Chapter 2. Background 11 Composed of Choreography model Abstract interaction patterns Mapping Executable interaction patterns Input Input Refinement Output Composed of Orchestration models Figure 2.7. Refinement approach. 2.5 Correctness verification When refining choreography models in orchestration models that realize them, the refinement transformation has to preserve interactions of the source choreography models. Furthermore, it has to ensure the correctness of the target models with respect to the source models [22, 23]. By using models with formal semantics defined in terms of a mathematical theory, correctness of the refinement can be assessed by using simulation or verification, possibly automatically. For example, developers can verify that the source and target models possess some desirable properties, or that some properties have been preserved during the refinement [22]. When the refinement transformation uses choreography and orchestration models that lack formal semantics, these models have to be transformed into models with equivalent behaviour specified in a formalism that does have formal semantics in order to allow the verification of correctness of the original models. Figure 2.8 extends Figure 2.7 to illustrate this approach, by defining mappings from the choreography and orchestration models to equivalent models with formal semantics. Composed of Choreography model Mapping Equivalent formal choreography model Abstract interaction patterns Mapping Executable interaction patterns Input Input Refinement Output Input Correctness verification Input Composed of Orchestration models Mapping Equivalent formal orchestration models Figure 2.8. Refinement approach with correctness verification. 2.6 Conclusions The aim of this chapter was to provide the background required for understanding the behaviour refinement problem. We introduced MDA and its basic concepts models, metamodels, and model transformations. Categorizing models according to their degree of platform-independence allows developers to separate the specification of the system s functionality captured in a PIM from the specification of the system s implementation captured in a PSM. In order for PIMs to include all information
12 Chapter 2. Background necessary for execution, they have to include behaviour. We explained the design methodology used in the A-MUSE project, which prescribes the use of behaviour modelling during the PIM design, especially for distributed context-aware mobile applications. It divides this design in three models that have a gradually increasing level of detail, and they are derived from each other through model transformations. The first model defines the system s behaviour from an external perspective, while the second defines the system as a set of interacting components. The third model also defines the internal behaviour of these components. This work focuses on the automation of the transformation from the second to the third model. In the remainder of this work, we refer to the behaviour of the second model as the abstract behaviour, while we refer to the behaviour of the third model as the concrete behaviour. We introduced interaction patterns as reusable pieces of behaviour at certain abstraction levels, which represent interactions between components. They are used to compose application behaviour in the latter two models. We showed that the latter two models of the A-MUSE approach correspond to choreography and orchestration models in the SOA domain. By using a model transformation to refine choreography models in orchestration models, knowledge captured previously in the former model can be reused in the latter. Furthermore, by specifying the refinements of interaction patterns separately, this transformation can be reused across applications and architectures. Since complex models cannot be verified by hand, choreography and orchestration models need formal semantics defined in terms of a mathematical theory in order to help ensure correctness of the orchestration models with respect to the choreography models. When these models lack formal semantics, they have to be transformed to models with equivalent behaviour specified in a notation with formal semantics. However, ensuring correctness with formal semantics is out of the scope of this work.
Chapter 3 Behaviour modelling with BPMN This chapter presents the most important concepts of BPMN, which we use to model behaviour throughout this work. Section 3.1 provides an overview of this language and justifies our choice of this language. Section 3.2 presents the concept of choreography model, which defines behaviour from a global perspective. Section 3.3 presents the concept of process model, which defines behaviour from the perspective of a particular process. Finally, Section 3.4 presents the concept of collaboration model, which defines interactions between process models. 3.1 Overview Business Process Model and Notation version 2.0 (BPMN) [11] is a graphical modelling notation for business processes defined by the OMG to bridge the gap between the design and implementation of business processes. It allows business analysts to specify business models that document business processes, whereas it enables ITspecialists to add technical details to these models and to execute them in process execution engines. BPMN allows the representation of process behaviours at various abstraction levels, through different types of models, which are: Choreography Defines the expected behaviour between interacting participants from a global perspective, by representing their interactions as atomic elements. Process Defines the behaviour of a business process as a flow of elements. Collaboration Defines the interactions between two or more participants in terms of atomic message exchanges, and may include nested choreography and process models. These models allow one to represent message exchanges between participants as well as between elements of their processes. Conversation Defines at a high abstraction level the groups of message exchanges that share a particular purpose between participants, providing an abstract view of the relations between them. Since our approach does not use conversation models, we do not discuss them further.
14 Chapter 3. Behaviour modelling with BPMN While the focus of BPMN focuses is on modelling control flows and dependencies between participants, it allows the representation of data as well. We use BPMN to define choreography and orchestration models that are used with the MDA-approach presented in Chapter 2, because BPMN allows one to represent behaviours from both global and local perspectives. Furthermore, it shares common concepts between these perspectives, such as messages. Since these concepts have the same semantics across the different perspectives, it is convenient for designers to work with them. Since BPMN has a well-defined metamodel along with tool support, it allows us to define transformation specifications that enable the automatic refinement of BPMN models. Designers can apply these transformations to any model, in order to obtain refined behaviours. A drawback is that BPMN lacks formal semantics defined in terms of a mathematical theory. As a result, BPMN alone is not enough to ensure correctness of models. However, we can obtain such semantics by mapping BPMN behaviours to their equivalent Petri Nets, using mappings available in literature [24, 25]. 3.2 Choreography Choreography models represent interactions between participants from a global perspective. They act like contracts that define sequences of message exchanges among their participants. Figure 3.1 shows a simple choreography model that consists of one interaction, called Interaction Name. Participant A initiates the interaction with another participant, called, by sending it a message called. Participant A Interaction Name Figure 3.1. A choreography model with one interaction. Choreography tasks represent interactions between two participants, as shown in Figure 3.1 by the rounded rectangle named Interaction Name. They contain bands at the top and bottom that represent the involved participants, such as participants Participant A and in the example. Bands that represent initiating participants are coloured white, while other bands are coloured grey. Envelopes attached through dotted lines to choreography tasks represent messages that are exchanged during interactions, such as message in Figure 3.1. Similar to bands, envelopes that represent initiating messages are coloured white, while other envelopes are coloured grey. No grey envelope is present in Figure 3.1, since does not send any reply back to Participant A. While choreography tasks represent atomic interactions between two participants, sub-choreographies represent compound interactions that involve two or more participants. For example, Figure 3.2 shows a choreography model with one compound interaction, called Compound Interaction Name, without its internal details. Like Figure 3.1, Participant A initiates the interaction, but this time it involves a participant called Participant C as well.
Chapter 3. Behaviour modelling with BPMN 15 Participant A Compound Interaction Name Participant C Figure 3.2. A collapsed sub-choreography. As shown in Figure 3.2, sub-choreographies are represented similarly as choreography tasks. When a sub-choreography s internal choreography is shown, it is referred to as an expanded sub-choreography. Otherwise a marker with a plus sign is shown, and the sub-choreography is referred to as a collapsed sub-choreography. For example, Figure 3.3 shows the expanded sub-choreography of Figure 3.2. Participant A initiates the sub-choreography by initiating the first interaction, called First Interaction Name, with. After the first interaction, initiates a second interaction, called Second Interaction Name, with Participant C. Participant A Compound Interaction Name Participant A First Interaction Name Second Interaction Name Participant C Participant C Figure 3.3. An expanded sub-choreography. As shown in Figure 3.3, the marker with the plus sign from Figure 3.2 is replaced by an internal choreography. Although only two choreography tasks represent the internal choreography in this example, any elements that make up choreography models can be used. Choreography tasks may have envelopes attached to them to represent message exchanges, but sub-choreographies do not define any message exchanges themselves. While sub-choreographies allow the reuse of behaviour within one choreography model, other choreography models cannot refer to them. Call choreographies allow one to reuse behaviour by calling a choreography model that is defined somewhere else, acting as a placeholder for inclusion. They are represented in a similar way as sub-choreographies, but with a thick borderline as the only difference. Like sub-choreographies, call choreographies may show a marker with a plus sign instead of their called choreography. For example, Figure 3.4 shows a call choreography that calls a choreography model consisting of the internal choreography of Figure 3.3. The two choreography tasks representing the called choreography are connected through a sequence flow. Participant A Compound Interaction Name Participant A First Interaction Name Second Interaction Name Participant C Participant C Figure 3.4. A call choreography.
16 Chapter 3. Behaviour modelling with BPMN Sequence flows are represented as solid lines with filled arrowheads. They define the sequencing of interactions by specifying a target element that follows some source element. In Figure 3.4, the sequence flow specifies that interaction Second Interaction Name follows interaction First Interaction Name, since the former is connected to the arrowhead and the latter to its tail. Next to normal sequence flows, conditional and default sequence flows can be used to represent decisions. For example, Figure 3.5 shows a choreography model with two interacting participants and a decision with two alternative interactions, which are called First Alternative Name and Second Alternative Name. A conditional sequence flow with condition expression Condition connects a gateway representing the decision with a choreography task representing interaction First Alternative Name. A default sequence flow connects the gateway with a choreography task that represents interaction Second Alternative Name. Finally, normal sequence flows connect the choreography tasks with another gateway. Participant A Condition First Alternative Name Participant A First Interaction Name Decision Participant A Second Alternative Name Figure 3.5. A data-based decision with two alternatives. Conditional sequence flows are similar to normal sequence flows, but also include condition expressions. They ensure that target interactions are initiated only when their condition expressions are true. Default sequence flows represent the chosen alternative when no condition expression is true. They are similar to normal sequence flows, but with a diagonal slash marker at the end of their tail, as shown in Figure 3.5 between the gateway and choreography task Second Alternative Name. Gateways represent branch and merge points in sequence flows, respectively such as the diamond shape named Decision and the unnamed one in Figure 3.5. Different types of gateways can be used, and the marker inside these diamonds denotes their type. The diamond shapes in Figure 3.5 contain X markers and represent exclusive gateways, which represent decisions to choose one out of multiple alternative answers. Although these gateways represent decisions, conditional sequence flows leaving the gateways determine whether a flow is initiated. In order to avoid nondeterminism, the condition expression of only one sequence flow can hold at some time. Exclusive gateways are also used to merge alternative flows again. Event-based gateways represent another type of decision, in which events represent the alternative answers. The decision depends on the occurrence of the first event. An example is shown in Figure 3.6, where two choreography tasks called First Alternative Name and Second Alternative Name represent the alternative interactions. The decision is based on reception of the messages First Alternative Message or Second Alternative Message in this case.