traceability-based change management · 2020. 4. 6. · the model driven architecture (mda) raises...

Traceability-based Change Management

in the Model Driven Architecture

by M. R. Dee

Final Project

MSc Computer Science

Graduation committeeProf. dr. ir. M. Aksit

Dr. ir. K. G. van den BergDr. I. Kurtev

A. Goknil, MSc

ChairSoftware Engineering

FacultyElectrical Engineering, Mathematics and Computer Science

UniversityUniversity of Twente

3

Abstract

The Model Driven Architecture (MDA) raises the level of abstraction in software development by defining models and transformations between models, usually based on meta-models. In a MDA transformation, one can distinguish a source and target section. A transformation language is used to write a transformation specification, which defines a mapping between a source meta-model and a target meta-model. Subsequently a tool, which is able to execute the transformation specification, can now transform an instance of the source meta-model to an instance of the target meta-model. Applying changes to one or more model elements cannot be done without knowing the impact that the change will have on the model. To make the impact visible an impact analysis determines which of the elements in the model need to be considered when a change propagates. The implementation of a change, while preserving the consistency of the system, is planned and performed based on the results of the analysis. Instead of rerunning the entire transformation to implement a change, one can attempt to do this incrementally, which is based on a reuse of the un-impacted model elements and retransforming only the impacted model elements. Traceability is the degree to which elements can be related. In the field of requirements engineering this consists of following a requirement from the rationale behind the requirement to the elements implementing the requirement and visa versa. In this thesis, we investigate a change management framework for changes to source models in the MDA. We especially investigate the possibilities of tracing model transformations, how tracing information can support a change impact analysis and how tracing information can support change implementation incrementally. We propose a trace model in the MDA that consists of logging the execution of the transformation specification. A single trace consists of a source model element, a target model element and the transformation rule used. The ordered set of all traces represents the transformation information. This information can be created automatically by Borland Together, this however does not give insight into the creation of the traces and a meta-model for the traces. We have implemented a custom trace model as part of the transformation specification, which does gives this insight. Based on the traces created by the custom trace model, we create an automated impact analysis, which is sufficient for changing attributes (e.g. the identifier) of model elements. An impact analysis for the deletion and addition of elements to the source model needs more information, due to the restrictions of the meta-model. In addition, we describe how incremental model compilation can be used to implement the changes. If we view models as sets of elements, a compilation of the un-impacted target model elements and the changed target model elements can be made. The changed target model elements are created by the retransformation of the impacted source model elements, where the re-execution is planned based on the traceability-based impact analysis. In conclusion, we state that a change management framework in the MDA can partly be based on the reuse of the traces, which log a transformation. A complete framework however needs more information regarding meta-model restrictions.

5

Preface

This thesis is the final product of my, six years and 9 months, Computer Science study at the University of Twente. This thesis, however, could not have been written without the help of some people. First, I would like to give special thanks to my graduation committee for their weekly feedbacks, right from the beginning of this project. That helped me to understand the concepts better and in the end intensively helped me with the establishment of this thesis. I would like to thank Arda, for his keen eye and ability to stipulate problematic cases from my proposals and I hope that he will adjust soon to a rhythm in the Netherlands. Ivan, for his intensive knowledge on the MDA and transformation languages and constant reassurance that the subjects studied are very messy stuff. And finally, Klaas; Who made it possible for me to do this project at the University and, armed with his red pen, gave very well structured advices on the concepts, semantics and pragmatics in this thesis and has pointed out to me the crucial difference between the Costa Brava and Costa Blanca. Secondly, I would like to thank my parents for making it possible for me to undertake this education and for supporting my discoveries into the various aspects of student life, without exactly knowing what this consists of. They kept me going through the years, supporting me but also by guiding me in the path that I have chosen. Last but not least, I want to thank family, all my friends, fellow students and Sabine, who all made the come-back to Enschede un-regrettable and especially made the last year here (and the years prior to that, of course) worth my while. Everybody thanks a lot! Matthijs Dee, Enschede, April 20, 2007

7

Table of contents

Abstract_____________________________________________________________3

Preface _____________________________________________________________5

Table of contents _____________________________________________________7

List of figures _______________________________________________________11

List of tables ________________________________________________________13

List of listings _______________________________________________________15

List of abbreviations__________________________________________________17

1 Introduction ____________________________________________________19 1.1 Project description _______________________________________________ 19 1.2 Problem statement _______________________________________________ 19 1.3 Contributions____________________________________________________ 20 1.4 Thesis outline____________________________________________________ 21

2 Background ____________________________________________________23 2.1 The Model Driven Architecture_____________________________________ 23 2.2 Query/View/Transformation languages ______________________________ 25

2.2.1 Architecture __________________________________________________________25 2.2.2 QVT and graphs_______________________________________________________29 2.2.3 Relevance ___________________________________________________________29

2.3 Borland Together Architect ________________________________________ 29 2.4 Change management______________________________________________ 29

2.4.1 Maintenance _________________________________________________________29 2.4.2 Changes and impacts ___________________________________________________30 2.4.3 Relevance ___________________________________________________________32

2.5 Traceability _____________________________________________________ 33 2.5.1 Requirements traceability _______________________________________________33 2.5.2 Model transformations and traceability _____________________________________35 2.5.3 Relevance ___________________________________________________________37

2.6 Summary _______________________________________________________ 37 3 Traceability-based Change Management _____________________________39

3.1 Traceability in the MDA___________________________________________ 39 3.2 QVT language specifications and traceability _________________________ 40 3.3 Sample case – SimpleUML to Relational Database _____________________ 43

3.3.1 Source and target models________________________________________________43 3.3.2 Transformation specification _____________________________________________44 3.3.3 Trace information _____________________________________________________45 3.3.4 Referencing the sample to traceability in the MDA ___________________________45 3.3.5 Conclusion___________________________________________________________46

3.4 Evaluation of the tracing information________________________________ 46

8

3.4.1 Referencing the sample tracing to the MDA _________________________________46 3.4.2 Execution tree ________________________________________________________49 3.4.3 Resolve methods ______________________________________________________51 3.4.4 Scenarios ____________________________________________________________52 3.4.5 Conclusion___________________________________________________________52

3.5 Custom trace model ______________________________________________ 53 3.5.1 Custom trace model example_____________________________________________54 3.5.2 Conclusion___________________________________________________________56

3.6 Intra-level trace dependency cases __________________________________ 57 3.6.1 Inter-level and intra-level trace dependencies ________________________________57 3.6.2 Introduction on scenarios________________________________________________58 3.6.3 Case 1: One-to-one mappings ____________________________________________61 3.6.4 Case 2: One-to-many mappings___________________________________________65 3.6.5 Case 3: Many-to-one mappings ___________________________________________68 3.6.6 Case 4: Many-to-many mappings _________________________________________72 3.6.7 Evaluation of the cases _________________________________________________74

3.7 Adding and removing elements _____________________________________ 75 3.8 Transformation rules and changes __________________________________ 76 3.9 Example change impact analysis and implementations__________________ 77

3.9.1 One-to-one mapping with a single transformation rule _________________________80 3.9.2 Many-to-many mapping with multiple transformation rules_____________________83

3.10 Change management process in the MDA ____________________________ 85 3.11 Discussion_______________________________________________________ 86 3.12 Summary _______________________________________________________ 87

4 Case study – Flattening simpleUML models __________________________89 4.1 Introduction_____________________________________________________ 89 4.2 The case ________________________________________________________ 89 4.3 The transformation_______________________________________________ 91 4.4 Change cases ____________________________________________________ 95

4.4.1 One-to-one mapping with a single transformation rule _________________________96 4.4.2 Many-to-one mapping with a single transformation rule________________________98 4.4.3 Many-to-many mapping with a single transformation rule _____________________101

4.5 Evaluation _____________________________________________________ 104 4.5.1 Number of traces _____________________________________________________104 4.5.2 Custom tracing_______________________________________________________106 4.5.3 Updating a source model element ________________________________________106 4.5.4 Deleting a source model element_________________________________________107 4.5.5 Unmapped source model elements _______________________________________107 4.5.6 Resolving mappings __________________________________________________107

4.6 Summary ______________________________________________________ 107 5 Conclusions ___________________________________________________109

5.1 Introduction____________________________________________________ 109 5.2 Summary ______________________________________________________ 109 5.3 Conclusions ____________________________________________________ 111 5.4 Future work____________________________________________________ 113

References ________________________________________________________115

9

A Operational Mappings implementation in Borland Together ____________117 A.1 Main structure__________________________________________________ 117 A.2 Transformation declaration _______________________________________ 117 A.3 Imports________________________________________________________ 117 A.4 Mapping methods _______________________________________________ 118 A.5 Queries ________________________________________________________ 119

B SimpleUML meta-model _________________________________________121

C SimpleUML to simpleUML transformation __________________________123

D SimpleUML to simpleUML transformation with tracing and queries______127

E Java ChangeManager ___________________________________________133

F Sample cases – Transformation specifications________________________135

G Sample cases – Models and impact analysis__________________________145 G.1 One-to-one mapping with one transformation rule ____________________ 145 G.2 One-to-one mapping with multiple transformation rules _______________ 146 G.3 One-to-many mapping with one transformation rule __________________ 146 G.4 One-to-many mapping with multiple transformation rules _____________ 147 G.5 Many-to-one mapping with one transformation rule __________________ 148 G.6 Many-to-one mapping with multiple transformation rules______________ 149 G.7 Many-to-many mapping with one transformation rule_________________ 150 G.8 Many-to-many mapping with multiple transformation rules____________ 151

H Case study – Flattening transformation specification __________________153

I Case study – Intermediary model __________________________________157

11

List of figures

Figure 1 Research domains in this thesis _______________________________________________20 Figure 2 Software engineering cycle vs. MDA development cycle based on [15] ________________24 Figure 3 MDA transformation pattern based on [17]______________________________________25 Figure 4 Relationships between QVT meta-models [23]____________________________________26 Figure 5 Core domains and pattern dependencies [23] ____________________________________28 Figure 6 Retransformation (left) vs. live transformation (right) [13] __________________________33 Figure 7 Traceability meta-model [27]_________________________________________________33 Figure 8 The traceability meta-model, systems and packages [31] ___________________________36 Figure 9 Traceability feature diagram [10] _____________________________________________37 Figure 10 An abstraction from the development cycle and its relation to a MDA transformation ____40 Figure 11 Traceability and the MDA transformation pattern________________________________40 Figure 12 Source model Test for the simpleUML to RDB transformation ______________________43 Figure 13 RDB target model _________________________________________________________44 Figure 14 Generated traces in the simpleUML to RDB transformation sample __________________45 Figure 15 Elements used in the sample transformation mapped to traceability in the MDA ________46 Figure 16 Dependency graph showing some transformation elements from the sample ___________48 Figure 17 Trace meta-model derived from simpleUML to RDBS sample_______________________49 Figure 18 Execution graph of simpleUML to RDB sample transformation _____________________51 Figure 19 Execution graph of simpleUML to RDB sample mapping methods ___________________51 Figure 20 MDA transformation with custom tracing and querying activities____________________53 Figure 21 simpleUML input model ____________________________________________________55 Figure 22 Created intermediary model for simpleUML renaming example _____________________56 Figure 23 Inter-level and intra-level trace dependencies ___________________________________58 Figure 24 Legend for models used in following sub-sections ________________________________59 Figure 25 Example model ___________________________________________________________60 Figure 26 One-to-one mapping created with one transformation rule _________________________62 Figure 27 Delete change in one-to-one mapping _________________________________________63 Figure 28 Update change in one-to-one mapping_________________________________________63 Figure 29 One-to-one mapping created with multiple transformation rules_____________________64 Figure 30 One-to-many mapping created with a single transformation rule ____________________65 Figure 31 One-to-many mapping created with multiple transformation rules ___________________67 Figure 32 Many-to-one mapping created with one transformation rule _______________________69 Figure 33 Many-to-one mapping with multiple transformation rules __________________________71 Figure 34 Adding elements in the wrong order___________________________________________76 Figure 35 Adding elements in the correct order __________________________________________76 Figure 36 Source model for example change impact analysis and implementations ______________77 Figure 37 Source model with delete change implemented __________________________________78 Figure 38 Source model with update change implemented__________________________________78 Figure 39 One-to-one with one transformation rule example ________________________________80 Figure 40 Intermediary model for one-to-one case with one transformation rule ________________81 Figure 41 Changed intermediary model for the one-to-one case with the deletion implemented _____81 Figure 42 Changed intermediary model for the one-to-one case with the update implemented ______82 Figure 43 Un-impacted intermediary model _____________________________________________82 Figure 44 Changed sub-source model__________________________________________________82 Figure 45 Updated sub-target model __________________________________________________83 Figure 46 Many-to-many with multiple transformation rules example_________________________83 Figure 47 Intermediary model for the many-to-many case with the delete change implemented _____84 Figure 48 Intermediary model for the many-to-many case with the update change implemented ____85 Figure 49 Change management process ________________________________________________86 Figure 50 Example source model _____________________________________________________90 Figure 51 Example target model______________________________________________________90 Figure 52 SimpleUML source model for case study _______________________________________92 Figure 53 SimpleUML target model for Case study _______________________________________93

12

Figure 54 Intermediary model for case study, only showing source and target models ____________94 Figure 55 String changed to CharArray - updated intermediary model ________________________98 Figure 56 organizationName changed to companyName - updated intermediary model __________100 Figure 57 organizationName deleted - updated intermediary model _________________________101 Figure 58 ssn changed to uniqueID - updated intermediary model __________________________103 Figure 59 deleted ssn - updated intermediary model _____________________________________104 Figure 61 Overview_______________________________________________________________133 Figure 62 Java based impact analysis process __________________________________________134 Figure 63 traceabilityElements ______________________________________________________134 Figure 64 One-to-one mapping with one transformation rule example _______________________145 Figure 65 One-to-one mapping with multiple transformation rules example ___________________146 Figure 66 One-to-many mapping with one transformation rule example ______________________147 Figure 67 One-to-many mapping with multiple transformation rules example _________________148 Figure 68 Many-to-one mapping with one transformation rule example ______________________149 Figure 69 Many-to-one mapping with multiple transformation rules example__________________150 Figure 70 Many-to-many mapping with one transformation rule example_____________________151 Figure 71 Many-to-many mapping with multiple transformation rules example ________________152 Figure 72 Case study intermediary model______________________________________________157

13

List of tables

Table 1 Formal definitions for traceability [8] ___________________________________________30 Table 2 Core domain areas and pattern areas for relation ClassToTable ___________________42 Table 3 Core domain areas and pattern areas for Operational Mappings ______________________42 Table 4 Trace information used in the dependency graph in Figure 16 ________________________49 Table 5 Complete tracing information of simpleUML to RDBMS example _____________________50 Table 6 Cases and number of traces created_____________________________________________74 Table 7 Transformations implemented per scenario _______________________________________79 Table 8 Generated mappings during transformation ______________________________________94 Table 9 Selected mappings from case study _____________________________________________95 Table 10 Expected mappings between source and target model elements _____________________105

15

List of listings

Listing 1 Relations sample ____________________________________________________________________27 Listing 2 Trace class for relation ClassToTable in Core _____________________________________________28 Listing 3 Change impact analysis algorithm [5] ___________________________________________________32 Listing 4 ClassToTable relation [23] ____________________________________________________________41 Listing 5 Tracing class for relation ClassToTable [23] _________________________________________41 Listing 6 Mapping for class-to-table transformation in Operational Mappings ___________________________42 Listing 7 Main mapping method for sample: simple UML to Relational DB______________________________44 Listing 8 Query helper method _________________________________________________________________45 Listing 9 collectElems query ______________________________________________________________52 Listing 10 Resolve sample_____________________________________________________________________52 Listing 11 Late resolve sample _________________________________________________________________52 Listing 12 Statically implemented merge algorithm of two elements ____________________________________77 Listing 13 The copy mapping __________________________________________________________________78 Listing 14 The merge mapping _________________________________________________________________79 Listing 15 Impact analysis for a change to source model element Package 1 _____________________________81 Listing 16 Impact analysis for a change to source model element Package 1 in the many-to-many case________84 Listing 17 Impact analysis and re-execution schedule for <<primitive type>> String _____________97 Listing 18 Impact analysis and re-execution schema for change to organizationName _________________99 Listing 19 Impact analysis and re-execution schema for change to property ssn ________________________102 Listing 20 Operational transformation simpleUML to simpleUML renaming____________________________125 Listing 21 SimpleUML to SimpleUML renaming scheme with custom trace model _______________________130 Listing 22 Query to get the source model ________________________________________________________130 Listing 23 Query to get the target model ________________________________________________________130 Listing 24 Query to retrieve the traces __________________________________________________________131 Listing 25 Query to retrieve the relevant traces ___________________________________________________132 Listing 26 QVT library containing the custom trace model, copy mapping methods, merge mapping methods and queries___________________________________________________________________________________139 Listing 27 One-to-one mapping with a single transformation rule ____________________________________139 Listing 28 One-to-one mapping with multiple transformation rules ___________________________________140 Listing 29 One-to-many mapping with one transformation rule ______________________________________140 Listing 30 One-to-many mapping with multiple transformation rules __________________________________141 Listing 31 Many-to-one mapping with one transformation rule_______________________________________141 Listing 32 Many-to-one mapping with one transformation rule_______________________________________142 Listing 33 Many-to-many mapping with one transformation rule _____________________________________142 Listing 34 Many-to-many mapping with multiple transformation rules_________________________________143 Listing 35 Impact analysis for a change to Package 1 in the one-to-one mapping with one transformation rule example __________________________________________________________________________________145 Listing 36 Impact analysis for a change to Package 1 in the one-to-one mapping with two transformation rules example __________________________________________________________________________________146 Listing 37 Impact analysis for a change to Package 1 in the one-to-many mapping with one transformation rule example __________________________________________________________________________________147 Listing 38 Impact analysis for a change to Package 1 in the one-to-many mapping with multiple transformation rules example _____________________________________________________________________________148 Listing 39 Impact analysis for a change to Package 1 in the many-to-one mapping with one transformation rule example __________________________________________________________________________________149 Listing 40 Impact analysis for a change to Package 1 in the many-to-one mapping with multiple transformation rules example _____________________________________________________________________________150 Listing 41 Impact analysis for a change to Package 1 in the many-to-many mapping with one transformation rule example __________________________________________________________________________________151 Listing 42 Impact analysis for a change to Package 1 in the many-to-many mapping with multiple transformation rules example _____________________________________________________________________________152 Listing 43 Flattening simpleUML models implementation with custom trace model in the Operational Mappings_________________________________________________________________________________________155

17

List of abbreviations

(E)MOF (Essential) Meta-Object Facility

CIM Computational Independent Model

GUID Globally Unique Identifier

IEEE Institute of Electrical and Electronics Engineers

MDA Model Driven Architecture

MDD Model Driven Development

MDE Model Drive Engineering

OCL Object Constraint Language

OMG Object Management Group

PIM Platform Independent Model

PSM Platform Specific Model

QVT Query/View/Transformation

RDB(MS) Relational Database (Management System)

RFP Request For Proposal

UML Unified Modelling language

19

1 Introduction

In this introduction, we describe the main structure of this thesis. We do this by giving a description of the project, the formulation of the main problem statement and an outline of the thesis.

1.1 Project description The Model Driven Architecture (MDA) raises the level of abstraction in software development by defining models and transformations between models, usually based on meta-models. Several transformation languages have been proposed as an OMG/QVT (Query/View/Transformation) RFP (Request for Proposal) [23]. From this RFP we learn that Traceability is an optional requirement for transformation languages. Changes may occur in any model in the MDA, in structural models and in behavioural models. Based on traceability, the propagation of changes through models can be managed. The following topics are studied in this thesis:

- Traceability in model transformation languages (QVT languages) - (Meta-) models for traceability - Change propagation and change impact analysis in MDA - Change management and incremental model compilation

From the proposed methods and observations on traceability, a meta-model and change management framework for the MDA is derived. We test this trace model in the form of a case study, supported by a tool which implements MDA based transformations.

1.2 Problem statement With automated Model Driven Development (MDD) made possible with the MDA transformation pattern, the problem of ever changing requirements is still at hand and needs to be addressed. Rerunning a transformation or a set of transformations, which use the changed source model(s) as an input and create the changed target model(s), can potentially become resource consuming. Therefore, the goal of this project is to study the possibility of a change management approach, where the impact analysis and incremental model compilation are based on traces. The traces log the mappings from the source to the target models. The incremental compilation is based on the re-use of target model elements rather than recreating an entire new model. We formulate the following research question, which summarizes this main problem: With the option of traceability in QVT transformation languages, can an incremental

change management framework be based on tracing information, that is created during the execution of a QVT based MDA transformation?

To solve this problem we introduce sub-questions, which cope with the various domains, which are shown in Figure 1, of the research question:

20

How is tracing defined within the MDA and how is this specified within the proposed QVT languages?

Can a tracing meta-model be derived for model transformations, which are written in a QVT language, so that it can be used to structure tracing needed for change management?

To what extent is the MDA with tracing implemented in Borland Together? Which change scenarios can be identified and solved with respect to

traceability-based change management in the MDA? How can the target model be compiled incrementally based on a traceability-

based impact analysis, when a change to the source model propagates?

Figure 1 Research domains in this thesis

1.3 Contributions This project is the beginning of a long and winding road, concerning tracing in the MDA and what can be achieved with the trace information. However, in this journey we give some answers to questions, but we also introduce new questions along the way. The main contributions of this thesis are:

- A theoretical overview of traceability in the MDA is given based on the QVT language specifications. This overview creates the basis for the traceability-based change management. Implementations in a tool provide practical examples that show the applicability of the MDA and how traceability relates to the MDA.

- A study is made to discover the possibilities of inter-level traceability-based impact analysis and how this can be used to implement a change with an incremental model compilation. The possibilities of inter-level tracing are researched in this thesis and the limitations are made evident. The possibilities are illustrated with implemented examples.

21

1.4 Thesis outline This thesis is structured into five chapters, this introduction included:

- Chapter 2: The relevant theoretical background information, ranging from the MDA, the QVT languages to traceability and change management, is discussed.

- Chapter 3: The context gathered is used to structure an approach, of setting up the framework for traceability based change-management in the MDA.

- Chapter 4: The framework is evaluated in the form of a case study, where the results show the main possibilities and limitations.

- Chapter 5: The entire document is rounded up with the conclusions and recommendations for future work.

We have added some appendices for more illustrative examples and complete code listings, which are left out of the main document to keep the discussions to the point.

23

2 Background

Before any in-depth work can be made, the context of this project needs to be clear. This chapter discusses this necessary context. We make a literature study that varies from the MDA and QVT languages to change management and traceability. This creates a baseline of information for the remainder of this thesis.

2.1 The Model Driven Architecture The Model Driven Architecture (MDA) guide [22] introduces and overviews the MDA. The MDA Strives to be a framework based on modelling and transformations, which enables the specification of systems independently of a platform, the specification of platforms, choosing a certain platform for a system and transforming that system to specific platforms. To make the abstractive nature of the architecture more concrete the MDA introduces the following viewpoints during the software development stages, which all represent a system on a different level of abstraction:

- Computational Independent Model (CIM): This view holds the necessary system structure in the form of domain knowledge or business model from which the demands and mandates on a system can be derived

- Platform Independent Model (PIM): This view holds the requirements for the system, independent on the eventual implementation platform, capturing the functionalities of that system.

- Platform Specific Model (PSM): This view captures the same functionalities as the PIM, but now also combining these functionalities with platform specific knowledge.

In the MDA the term platform refers to a given set of subsystems and technologies, which can be used by an application (e.g. PSM), without having to know how these are implemented. The intended idea is to transform a PIM to one or more PSM models with a transformation specification, which provides a mapping between the meta-models. This transformation is executed on a transformation engine implemented in a tool and uses a PIM to create the desired PSM. Figure 2 shows where the abstract views are placed in contrast with the traditional software engineering cycle, which is an iteration of activities and the resulting artefacts from those activities.

24

Figure 2 Software engineering cycle vs. MDA development cycle 1 based on [15]

Kleppe et al. [15] elaborate on the main advantages of the MDA. They state that due to the automated transformation of PIM models to PSM models, the following benefits can be achieved:

- Larger productivity; although a transformation specification needs a large amount of time to create, once finished it can be reused in other transformations.

- Greater portability; A PIM can be transformed to several different platforms. - Greater inter-operatibility; When a PIM is transformed to two different

platforms, a bridge from the two created PSMs indicate where related elements occur.

- Consistent documentation; A PIM can be seen as high-level documentation of the system. When the PIM is changed, the system can be re-transformed to keep the relevant PSM consistent with the evolving PIM or documentation.

Kurtev [17] in chapter two of his book emphasizes the MDA transformation pattern in a more abstract fashion. He states that removing the notion of platform specific or independent models, but using source and target indications. These indications are also mentioned in the MDA guide [22]. In this pattern, a transformation specification is written in a transformation language. This specification maps a source meta-model to a target meta-model. A tool executes the specification; an instance of the source meta-model is used for the input and creates the target model, which is an instance of the target meta-model. The transformation pattern is shown in Figure 3.

1 The UML activity diagram shown in Figure 2 contains object flows that are represented by the dashed lines and control flows by solid ones.

25

Figure 3 MDA transformation pattern based on [17]

2.2 Query/View/Transformation languages This section gives a short review of the final proposal for the Query/View/Transformation (QVT) languages from the Object Management Group (OMG) merge group [23]. A QVT language is designed or modelled to transform models, based on some meta-model, to other models. The querying and viewing enables the architect and transformation experts to extract information and create certain views on the models, which are used in the transformation.

2.2.1 Architecture Chapter 6 in [23] shows that the QVT architecture (see Figure 4) consists of a two-level declarative architecture, which is accompanied with imperative mechanisms. In the specification, the proposed architectural components are reviewed as languages or models. The two-level declarative architecture consists of the Relations language and the Core language. These languages have the same expressiveness, but are on two different levels of abstraction. An analogy can be made with the Java language and how this relates to the Java Virtual Machine:

A Java compiler compiles Java code to Java Byte Code that can be run on a Java Virtual Machine. A transformation written in the Relations language can be transformed to a Core equivalent with the help of the Relations-to-Core transformation

26

(Chapter 10 in [23]) and can then be run in a tool, which can execute a transformation written in the Core language. We see that the Relations language relates to the Java language, the Relations to Core transformation relates to the Java compiler and the Java Byte Code relates to the Core language.

This analogy however does not imply that only the Core language can be implemented in a tool. According to the specification, also the Relations semantics are implement-able in a tool. The imperative mechanisms added to the architecture, consist of the Operational Mappings language and a Black Box plug-in system. The Black Box mechanism is added to be able to import any Meta-Object Facility (MOF) [25] compatible imperative implementations, for reuse purposes. The MOF is a language or model that can be used to model meta-models, which for instance can be used in the MDA. In the specification, a transformation is either a Core transformation, Relations transformation or Operational transformation. For the use within this thesis, we use a more abstract term: transformation specification. A transformation specification indicates a transformation written in either QVT proposed languages or a combination of those.

Figure 4 Relationships between QVT meta-models [23]

2.2.1.1 Relations language Specified in Chapter 7 of [23] the Relations language is a user-friendly declarative approach, which supports complex object pattern matching, complex object template creation and an implicit tracing facility. A transformation written in the Relations language consists of a set of relations between two meta-models. A meta-model defines several model types that can be used in the transformation. A single relation declares constraints on model types that either can be checked or enforced by a transformation. These constraints are defined in domains and each domain addresses a model type. A domain check, only makes sure if a relation holds and does not adjust the target model if the check fails. A domain enforce, also changes the target model to comply with the source model and the declared constraint(s) if the check fails. A when and where clause can be added, which constrain the relation itself. These constraints determine what needs to hold when the relation is provoked (when) and what should hold for all model elements used in the relation (where). The direction of the transformation is determined by selecting which model is the target. A sample, which shows the declaration of a transformation (umlRdbms) and a relation (ClassToTable), is shown in Listing 1. The

27

relation in this sample contains two domains (uml c:Class and rdbms t:Table) and is constrained by a when and where clause. The necessary trace classes are generated automatically during the execution of the transformation. Although the tracing information is made implicitly, the specification lacks an identification or elaboration on the tracing methodology. The specification however does contain a Relations-to-Core transformation, which also shows how the explicit Core trace classes are created from a transformation specification in the Relations language. transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) { … relation ClassToTable /* map each persistent class to a table */ { domain uml c:Class { namespace = p:Package {}, kind='Persistent', name=cn } domain rdbms t:Table { schema = s:Schema {}, name=cn, column = cl:Column { name=cn+'_tid', type='NUMBER'}, primaryKey = k:PrimaryKey { name=cn+'_pk', column=cl} } when { PackageToSchema(p, s); } where { AttributeToColumn(c, t); } } …

Listing 1 Relations sample

2.2.1.2 Core language Chapter 9 in [23] specifies the syntax and use of the Core language. In contrast to the Relations language, the Core language supports pattern matching only over a flat set of variables. The Core language is strived to be as close to the MOF and Object Constraint Language (OCL) as possible, which makes the language smaller and easier to understand than the Relations language. However, the Core based transformation specifications will become more verbose than the equivalent Relations based transformation specifications. In addition, the trace classes are declared explicitly, in contrast with the implicit tracing of the Relations language and Operational Mappings language. A transformation specification written in the Core language consists of a set of mappings. Each mapping contains several domains, where each domain handles a model type from the source meta-model or target meta-model. The different domain areas, which are contained in a Core based transformation, can be put into a matrix that shows the different domain areas and the dependencies between these (see Figure 5). The main idea is that the bottom pattern areas are allowed, when the guards in the guard pattern areas are passed. There then can be a

28

mapping, a one-to-one relation, between all bottom pattern areas, checking the relation or enforcing this. The middle column can be seen as the intermediate transformation stage, containing all information of both neighbourly models (i.e. tracing information).

Figure 5 Core domains and pattern dependencies [23]

An explicit trace class is defined per mapping. This class contains all used model elements used in the mapping. The Relations language and Operational Mappings language both create these classes implicitly. A trace class that corresponds with the relation ClassToTable in Listing 1 is shown in Listing 2. class TClassToTable { c: Class; p: Package; t: Table; s: Schema; }

Listing 2 Trace class for relation ClassToTable in Core

2.2.1.3 Operational Mappings language As is mentioned in the previous section, the declarative architecture also has an imperative counter part. The Operational Mappings is the imperative language proposed. In this section the Operational Mappings, as is specified in chapter 8 of [23] is summarized. The language is specified in Chapter 8 of [23] to be a standard for providing an imperative approach to implement a transformation specification, making it more accessible for programmers familiar with imperative languages. A combination of Operational Mappings and a Relations or Core based transformation is possible. However, a transformation can also be specified completely with Operational Mappings, which is indicated by an Operational Transformation. Since we have chosen a tool that implements the Operational Mappings, this is discussed in more detail in following Chapters.

29

2.2.2 QVT and graphs In [28], Rensink et al. describe a basic QVT based transformation with the help of graph production rules. This is illustrated by an example, which is implemented with the Groove tool set [29]. In this example, they use a simple graph representation for a model and a direct translation of a QVT proposed language, the Model Transformation Language (MTL), to a graph production rule set to create a transformation. The paper describes a proof of concept, where it shows that it surely is possible to create a model transformation based on the simple graph structure and graph production rules.

2.2.3 Relevance Transformations that are written in the QVT languages support traceability implicitly or explicitly. In the context of this thesis, the traceability feature is researched further. The tool used implements the Operational Mappings language and the practical use of tracing can be studied in this tool. The Core language uses an explicit declaration of trace classes in the transformation specification. We need to study these trace classes and to what extent this can be used for change management.

2.3 Borland Together Architect For this project, the tool Borland Together Architect2 [6] is used. This modelling platform enables architects to model UML 2.0 compliant models and business process models. From the 2006 version onwards, the platform is extended with MDA support. Implementing a subset of the Operational Mappings language and the complete OCL 2.0 language, the QVT based transformations can be coded with the help of syntax highlighting and checking. Using source model elements and target model elements, based on a large set of predefined meta-models, the operational transformation can be run on the Borland QVT interpreter. This executes the transformation and can, when desired, create tracing information for the user separate from the target model.

2.4 Change management In this thesis, we address the problem of changing models in the MDA with a desired change management framework as the result. In this section, we summarize some main points with respect to maintenance and change management.

2.4.1 Maintenance Ajila [3] categorizes maintenance in four types, namely perfective -, corrective -, adaptive maintenance and evolution. Here the first two types indicate maintenance while the product or system is still in development and the last two indicate maintenance after deployment. In [30] a summary is given for these maintenance efforts in software engineering. Here the main definition states that maintenance is the modification of a software product, before and after delivery. This modification is performed to change the product to correct faults, improve the performance or other attributes, or adapt to a change in the environment. They further summarize the need that this is done, while preserving the integrity of the product. 2 Borland Together Architect version 2006 R2

30

The following four categories can be distinguished in the maintenance question: Corrective maintenance: Coping with errors Adaptive maintenance: Changing the product to adapt to a changing or

changed environment Perfective maintenance: Improvement of the product’s performance or other

attributes Preventive maintenance: Search for faults, to change the product to cope with

them in the future In addition, they define that the maintenance process consists of the classification and identification, analysis, design, implementation, testing and (re-) delivery. Kurtev [17] describes three evolution scenarios with respect to a system that is composed of a set of solutions:

The additive scenario introduces a new solution that is derived from a new requirement and is put in the composition of all solutions to eventually form the entire system.

The replacement scenario takes a change or update to one of the existing solutions, and replaces that specific solution accordingly.

The subtractive scenario takes one solution and removes it from the composition.

2.4.2 Changes and impacts Cleland-Huang et al. [8] propose some formal notations in the context of traceability and change management. With the help of these formal notations, they specify certain error scenarios when looking at the maintenance process. Table 1 shows these definitions.

Table 1 Formal definitions for traceability [8]

Formal notation Description Artefact a A piece of information produced or

modified as part of the software engineering process

Artefacts {a1,…,an}=A The set of all artefacts Requirement r A requirement is one of the artefacts Requirements {r1,…,rk}=R The set of all requirements, a subset of or

equal to A Link(a,a’) A direct (no intermediate artefacts) or

indirect relationship between two artefacts

Change C Either a proposed change, indicating that an impact analyses should be performed, or an implemented change, which indicates that the all impacted artefacts need to be modified accordingly.

Linked(a) The set of all artefacts linked to artefact a

31

Related(a) The entire set of (intrinsically) related artefacts to artefact a. It isn’t desirable that all related artefacts are linked, this will help with the entire overview of the system

StrategyRelated(a) A subset of Related(a), which should ideally be the same as Linked(a).

Impacted(C,a) The entire set of impacted elements when change C is made on artefact a

Identified(C,a) All identified impacted artefacts, this is a subset or equal to Impacted(C,a)

Updated(C,a,t) The set of updated artefacts when change C is implemented on artefact a. Timestamp t indicates the time when all identified artefacts are updated

Traceability Path TP(aj,an) A set of direct links starting with artefact aj to artefact an. No links with intermediate artefacts are allowed

The following error scenarios, which can occur in the change maintenance process, are identified with the help of the definitions in Table 1:

- Scenario 1: No errors: All impacted artefacts are updated accordingly while the rest of the system stays in a consistent state.

o Impacted(C,a) = Identified(C,a) = Updated(C,a,t), indicating that the change was implemented and the entire system of artefacts was updated accordingly

o Impacted(C,a) = Identified(C,a) and Updated(C,a,t) = empty, indicating that the change was proposed but not yet implemented

o Linked(a) = StrategyRelated(a), all relevant links were put in the linked set

- Scenario 2: Identification errors: Not all impacts are identified. o Impacted(C,a) superset of Identified(C,a)

- Scenario 3: Update errors: Impacted artefacts are not updated when change C is implemented.

o Impacted(C,a) superset of Updated(C,a,t) - Scenario 4: Inclusion errors: Artefacts were updated, even when they aren’t

impacted by the change at hand. o Identified(C,a) and not Impacted(C,a) is not empty set

When no errors occur one can talk of a consistent set of artefacts, otherwise the set is inconsistent. Ajila in [3] states that when changes occur on objects or artefacts in a system, this brings along several issues:

- Identifying the victims of the change, - Identifying the type of the change, - Evaluating the effects of a change, and - Gathering knowledge on how to perform the change.

These set of issues can (partly) be resolved by a correct impact analysis method. Ajila defines impact analysis as the activity of identifying which object to modify to

32

accomplish a change. A good impact analysis method can estimate the cost of a change at hand, can determine the meaning of the relationship of the object to be changed and the system, keeps track of changes made over time and determine which parts of the system need retesting after the change is implemented. He proposes a framework in which a system is composed by a set of objects and a set of changes (or types of changes). He then defines a function which computes, given a change and an object, the entire set of compromised objects. The main focus will be on the objects forming the system, and the dependency relationships between them. A distinction is made into inter-phase relationships and intra-phase relationships. The phase indicates a process step in the development cycle. In [5] v.d. Berg focuses on the identification which elements are involved in a change, resulting in a change impact model. He distinguishes the following mappings, which are possible between source and target elements:

- Injection: Source and target element have a distinct relation - Scattering: Source element has various relations with multiple target elements - Tangling: Target element has various relations with multiple source elements - Crosscutting: Target element is both involved in scattering and tangling

For the impact analysis between two domains the calculation of the to be changed relationships and which relationships need to be preserved suffices. For a multi-level impact analysis a recursive method is used, resulting in a set of mappings which are subjected to the change at hand: impact(x,v) = change(x,v) + (preserve(u,v) | u predecessors(v); x≠u) + (impact(v,w) | w successors(v))

Listing 3 Change impact analysis algorithm [5]

Hearnden et al. [13] propose two different methods to do an incremental update, when a change or multiple changes are made to source models in model transformations. A change to a source model element can be implemented in two ways:

- A (partial) re-execution of the transformation, where the new target model must be merged with the old existing target model.

- The other method is to map the change to a change to the target model. This is done with the help of a live transformation which continuously keeps track of the transformation context.

For the second approach, they provide a mechanism to add and remove items to and from the source model. Both approaches are shown schematically in Figure 6.

2.4.3 Relevance Changes to a system of objects can occur during and after the software engineering process. The several types show the need to add, delete and update objects from the system to accomplish a change, while preserving the integrity of the entire system. We see from the error scenarios that several problems can occur when determining the impact of and implementing a change. A selection of the impacted elements throughout the entire set of artefacts is needed to implement a change. In addition, the

33

implementation of the change itself can cause errors and the several mappings possible between two domains need to be taken into account in the remainder of this thesis.

Figure 6 Retransformation (left) vs. live transformation (right) [13]

2.5 Traceability In this section, an introduction is given into traceability. We begin with a summary of definitions from requirements traceability, a field where traceability is widely studied. Then a summary is given for traceability and the relation to model transformations.

2.5.1 Requirements traceability In the context of requirements traceability, Gotel and Finkelstein [12] define requirements traceability as the ability to describe and follow the life of a requirement, in both a forwards and backwards direction. Ramesh and Jarke [27] define requirements traceability as a characteristic of a system in which the requirements can be linked to their sources and the artefacts created during the development life cycle. To accommodate traceability models they provide a simple traceability meta-model, which can be used as a language for defining traceability models (see Figure 7). With this meta-model and the results from a large-scale empirical study, they derive several reference models, which can be customized in accordance with the meta-model. The usage of these reference models is made more practical with the help of a database of actual recorded traces, from the chosen models.

Figure 7 Traceability meta-model [27]

34

Specializations of the elements in the meta-model are used for the following five informational representations:

1. What objects or artefacts relate to what objects or artefacts, 2. Who are the stakeholders responsible for the creation and/or maintenance of

objects, 3. Where (in which sources) is the information stored, this can be tangible or

intangible documentation, 4. How high is the level of formality in the sources, 5. Why objects are created, modified or deleted and 6. When the objects or relationships are created, modified or deleted.

In the presentation of the reference models, they make a distinction between low-end users and high-end users. Here the level of traceability information used by the low-end user is much less detailed than the information used by the high-end user. In the presented reference models only the artefacts from the development life cycle are included, this was done for a more abstract and comprehensible view. The reference models for the high-end users are divided into a Requirements management -, Evolution -, Rationale -, Design and allocation - and Compliance verification sub-model. In the introduction of the Evolution sub-model, they identify the following problem: The lack of comprehensive traceability is a primary reason for the inability to identify components that are linked to various objectives and modify them to meet the current requirements. Finally, they also define a traceability system as a semantic network of nodes (objects) among which traceability is established through links of different types and strengths. Pinheiro [26] adapts the definition by Gotel and Finkelstein on requirements traceability by adding the notion of forwards and backwards tracing, including the pre-requirements specification section in the development life cycle. The working definition he results in, defines requirements traceability as the ability to define, capture and follow the traces left by the requirements on other elements of the software development environment and the traces left by those elements on requirements. With the help of this addition he defines pre- and post-requirements specification tracing, forward- and backward tracing and inter- and extra requirements tracing. On top of these requirements tracing modes he defines the functional and non-functional tracing of requirements. Where the non-functional represent trace relationships where at least one object is intangible. He also stipulates that tracing is an auxiliary activity making higher-level actions more accessible. Knethen and Paech [16] use the IEEE software engineering standards’ definition for traceability [14] pg. 78: Traceability is the degree to which a relationship can be established between two or more products of the development process. They stipulate that a tracing approach should capture and manage the relationships between documentation entities. They make a distinction in the purpose of tracing, made by the different stakeholders involved during the development life cycle. A designer for instance has a different use of the tracing information, than a verifier.

35

2.5.2 Model transformations and traceability In the context of Model Driven Engineering (MDE), Aizenbud-Reshef et al. [2] define traceability as a relationship between a set of source and target entities. They use the classification presented by Ramesh and Jarke [27] to identify the different kinds of relationships for requirements traceability. They state that with the use of traceability, operational semantics can help with the querying, following the links along the life cycle of a project and primarily with keeping the system and documentation up to date, in a consistent state. The operational semantics for a traceability relationship is defined as a set of semantic properties, where a semantic property can be represented by the following triple:

{event, condition, action} Here an event defines the trigger, on which the semantic should respond. The condition is a simple guard, which determines if something should be done. The action can then be performed, either to react to the occurring event or to prevent something from changing the current system state. The definitions in the previous sections are made more abstract by the definition of Aizenbud-Reshef et al. in [1]. Here they elaborate that any relationship between artefacts in the software engineering process falls under the term traceability. They stipulate that this includes the links or mappings created during the execution of a transformation. Walderhaug et al. [31] underline that due to the intensive use of model transformations and code generation in the Model Driven Development (MDD), tracing the artefacts is important. They propose a traceability framework, which consists of the following four packages:

Traceability meta-model: a package for the creation and definition of trace models

• TraceModel, used to indicate which model artefacts need to be traced and which relations between those artefacts can be created

• TraceableArtifactType, defines a mapping between the model artefact type and the traceable artefact type.

• ArtifactTraceType, defines specific trace type for a TraceableArtifactType.

• RelationTraceType, defines a relationship type between a source and target artefact type.

Traceability system: a repository like data store Traceability use: a interfacing package making user actions possible EMOF: a single meta-class inclusion to create unique identification of the to

be traced artefacts in the framework With this framework, four main uses are pointed out: TraceModel management, trace creation, trace use and trace monitoring. The packages, classes and how these relate to each other is shown in Figure 8.

36

Figure 8 The traceability meta-model, systems and packages [31]

In their classification of model transformation approaches, Czarnecki and Helson [10] provide a feature overview of the different aspects in these approaches. One of the aspects handled in the paper is traceability. They state that traceability can be a part of the program itself and that the programmer, if desired, should manually model the links as for all other relationships. Other platforms provide dedicated traceability, which provide either an automated tracing mechanism or a manual coding scheme in the transformation rules. They finally stipulate that the traces, or trace information, can be stored in the models itself or can be stored in a separate location. The last option has their unexplained preference. These features are modelled and summarized in the feature diagram3 shown in Figure 9.

3 The feature diagram shown here is modelled according to [9]

37

Figure 9 Traceability feature diagram [10]

2.5.3 Relevance We see that traceability is used in the field of requirements engineering, to keep track of the requirements during the entire software engineering process. The tracing of transformations is the domain we are focussing on. For the MDD we see that a framework is already proposed, based on meta-model specialization and creating links between actual artefacts.

2.6 Summary In this chapter, we have made a literature study to determine the necessary theoretical context. We started the study with the Model Driven Architecture (MDA), which raises the level of abstraction in software development by defining models and transformations between models, usually based on meta-models. We can distinguish a source and target section in a MDA transformation. A transformation language is used to write a transformation specification. This specification defines a mapping between meta-model elements from the source meta-model to the target meta-model. We have selected the Borland Together platform for this project, which partly implements the MDA framework with a bound set of meta-models and a QVT language supported by an implementation of OCL 2.0. From the specifications of the proposed QVT languages, we have learned that they provide some sort of tracing mechanisms. The Relations language and Operational Mappings language use an implicit trace mechanism and the Core language uses an explicit trace mechanism. This explicit tracing is represented graphically in a table, showing a mapping from source-to-target meta-model elements. In the study into traceability, we have seen that this is widely used in requirements engineering. In this field, a requirement may be followed from the source (or rationale) of the requirement to the modules designing, implementing and testing the requirement. A proposed meta-model can be instantiated to support the different purposes of requirements tracing within the different stadia of the engineering cycle. The classification of traceability for transformation languages shows us which

38

possible features are expected and which are mandatory for traceability in model transformation tooling. The following changes types to elements of a system are distinguished in literature:

- Addition, adding a new element - Subtraction, deleting an existing element - Replacement, updating an existing element

From the literature on traceability in models, we have learned that a change affects not only the (to-be) changed element in the source, but also the related model elements in the target. In addition, some source model elements and target model elements, which are not directly impacted, need to be preserved that keeps the system consistent after the change is implemented. Several types of relations between elements are distinguished, from studies into multi-level processes. The inter-level trace dependencies are defined between artefacts residing in two different levels of the engineering cycle. The intra-level trace dependencies are defined between artefacts, which reside on the same level of abstraction. A live transformation is proposed to implement changes to source model elements incrementally, using the transformation information to recreate target model elements. Before any change implementation can be performed an impact analysis needs to be made, determining the affect the change has in the system. This results in the set of system elements, which should be changed or preserved to implement a change.

39

3 Traceability-based Change Management

In this chapter, a change management approach is discussed. This consists of the placement of the current knowledge on traceability within the existing MDA framework and exploring the transformations and automated tracing within the chosen tool, Borland Together Architect. From the exploration an approach is presented to cope with change impact analysis and incremental model compilation, all based on the tracing done during the actual transformation.

3.1 Traceability in the MDA The software development life cycle can be seen as a sequence of related steps, like the steps shown in Figure 2. In the research done on traceability, the artefacts and the elements that compose them are the objects to be traced. Within the scope of the MDA the meta-models can be used in the automation between those steps. With the help of a transformation specification and transformation engine, a model can be transformed to another model, according to some meta-model, which then can be used in other processes, like some further transformations (see the MDA transformation pattern in Figure 3). We now make an abstraction from the software engineering cycle (see Figure 2) and integrate the notion of a MDA transformation. This results in the activity diagram4 shown in Figure 10. The dependency relations (dashed associations) between artefacts A_1 and A_2 depict the traceability links. Our focus will shift from this view, the software engineering cycle, to the MDA transformation and especially to the two models M_1 and M_2. Because our view of traceability shifts from the artefacts to the models, we need to introduce traceability within the MDA. This integration is needed due to the automated tracing, which is done during the execution of a transformation specification. The trace information created, must comply with the elements of both source meta-model and target meta-model. A trace, which is illustrated by a transformation specification in the Core language, must also comply with a trace meta-model within the MDA and commonly useable within this framework. This main view is schematically shown in the activity diagram of Figure 11.

4 The activity diagrams, in this thesis, are created with the help of the Together Architect modelling tool, which is compliant to the UML 2.0 [24]. The UML 1.5 object-flows (dashed edges) are replaced by solid ones. Together adds an extra colour difference and allows process-flows, even when object-flows are created.

40

Figure 10 An abstraction from the development cycle and its relation to a MDA transformation

Figure 11 Traceability and the MDA transformation pattern

3.2 QVT language specifications and traceability According to the feature based classification of Czarnecki and Helsen [10] the implicit and explicit tracing mechanism from the QVT languages are automatic, because the explicit trace classes that are used in the Core language (cf. section 2.2.1.2) are also defined within the transformation specification itself.

41

However, in the process of making the implicitly created traces less transparent, we study if the Core domains and pattern dependencies (see Figure 5) can be used. Due to the fact that the Operational Mappings language utilizes the same tracing mechanism as the Relations language, we can review the Relations-to-Core transformation from [23] chapter 10 and try to map this to the Operational Mappings language. In this transformation, the first transformation rule creates the explicit trace classes from the Relations based transformation specification. The trace class itself contains an indicator for each object node, used in the various domains of a relation. The trace class can therefore be constructed by adjusting the name and adding instances of all used object nodes. The when and where clauses in a relation correspond to the middle area pattern. More specifically the when clause fills the guard and the where fills the bottom area pattern. The domain patterns fill up the corresponding left and right domain area patterns, in the matrix. Here the domain variables in the when clauses fill up the guard area patterns and the rest will be used for the bottom area patterns. To illustrate this Relations to Core transformation more specifically, the example relation from Listing 4 will be used. The first step will be the creation of the explicit trace class. As is explained in the previous section, we do this by taking an instance of every object node used in the relation. The derived trace class is shown in Listing 5. From [23] it is not clear to us where this class is used. However, when we review the sample transformation under discussion here, it becomes clear that this class holds all information from both left and right domain areas (UML and RDBMS respectively). relation ClassToTable { checkonly domain uml c:Class { namespace=p:Package {}, kind='Persistent', name=cn } checkonly domain rdbms t:Table { schema=s:Schema {}, name=cn } when { PackageToSchema(p, s); } where { AttributeToColumn(c, t); } }

Listing 4 ClassToTable relation [23]

class TClassToTable { c:Class; p:Package; t:Table; s:Schema; }

Listing 5 Tracing class for relation ClassToTable [23]

With the help of the first transformation rule from the Relations-to-Core transformation, we can fill the domain patterns. The results can be seen in Table 2. The middle domain area is filled with two mappings. The guard pattern makes sure that a package to schema relation holds and the bottom one makes sure that the subsequent relation holds. More concrete: PackageToSchema relates the correct package to the correct schema, e.g. setting the names correct. Now the AttributeToColumn can create the tracing

42

class, which can be seen in Listing 5, and makes sure that this is done for the correct attribute mappings from UML to RDBMS.

Table 2 Core domain areas and pattern areas for relation ClassToTable

UML domain area Middle domain area RDBMS domain area

p:Package PackageToSchema(p,s) s:Schema Guard pattern

area

c:Class c.kind=’Persistent’ c.name=cn

AttributeToColumn(c,t) t:Table t.name=cn

Bottom pattern

area

The equivalent Operational Mappings based transformation is shown in Listing 6. The when clause, used in the Relations language, creates dependency relations, which are used as pre-conditions for the relation or transformation rule. This clause is missing in a mapping method in the Operational Mappings language, but can be solved by looking at the invoking mapping and tracking the path of execution. The source and target instances can be used in the same manner as would be done with the Relations based transformation and fills the right and left domain areas. The assignments can be used for the same purpose. The corresponding domain areas and pattern areas for the persistentClass2table mapping is shown in Table 3.

Listing 6 Mapping for class-to-table transformation in Operational Mappings

Table 3 Core domain areas and pattern areas for Operational Mappings

UML domain area Middle domain area RDBMS domain area

pack:simpleuml::Package package2schema this:rdb::Schema Guard pattern

area

cls:simpleuml::Class cls.isPersistent() cls.name

class2columns(cls) this:rdb::Table this.name := cls.name;

Bottom pattern

area

mapping persistentClass2table(in cls: simpleuml::Class) : rdb::Table when { cls.isPersistent() } { name := cls.name; columns := class2columns(cls); primaryKey := class2primaryKey(cls); foreignKeys := class2foreignKeys(cls); }

43

The trace information consists of the complete transformational mapping from source to target. The Core domain and pattern areas matrix is a structured way of representing a transformation, but does not add any extra information or insight on tracing.

3.3 Sample case – SimpleUML to Relational Database Various tools provide MDA based transformation capabilities [6][19][18][21]. In this section, a sample case from the Borland Together tool [6] is described, which shows an operational transformation with automatically created trace information. From this sample case, a mapping can be made that indicates what information is already available for our framework and what information will have to be gathered otherwise (see Figure 11).

3.3.1 Source and target models In this case we use the simpleUML meta-model for the modelling of the source model (see Appendix A). The model (an instance of the meta-model) used, is shown in Figure 12. The Relational Database (RDB) meta-model is chosen from the Borland Together meta-model library for the target model. The modelling in Borland Together is done in a top down fashion. Starting from some main element, children elements (or sibling elements) can be created, which must comply with the structure of the meta-model. The source model is identified by Test. Model Test contains three types of persons: a Father, a Mother and a Child. On top of the inherited name, both the “parents” will have a Boolean typed attribute, indicating if they have any children. The child will have a count of the amount of parents. The associations in the model are between the parents and the child (hasChild) or between the parents, depicting a romantic relationship (relationship). The elements described above, are collected into a package (Family). We need the package with the primitive types for the typing of the different attributes of the created classes.

Figure 12 Source model Test for the simpleUML to RDB transformation

When the transformation specification is executed, the tree structure of the RDB target model in Figure 13 is generated. The tree like representation, which is also used

44

to model the source model, is used because no fancy graphical representation is available for the modelling of both the simpleUML and RDB meta-models. From the package Family a corresponding schema is created. This schema contains tables for every class from the source model. In addition, the attributes and inherited attributes (through the generalization associations) from the Person class are mapped correctly to columns in the tables. It must be noted that the extra information, like the identification and creation of the primary keys, are made possible with the help of annotations in the input model.

Figure 13 RDB target model

3.3.2 Transformation specification The QVT based transformation is available as a standard sample in Borland Together. The specification uses the elements from the meta-models, to create mappings from the source to the target model. Starting at the main mapping method, the transformation begins at the root of the source model. From this point onwards, a set of mappings, which declare the target model elements by using information from source model elements and query methods, which are mainly search and retrieve methods for model elements. The mapping shown in Listing 7 is the main mapping method that is used in the simpleUML to RDB transformation. Here the root source element, a model of type simple UML (simpleuml), is used to create the desired target model element, a model of type RDB (rdb). The source element’s properties are mapped to the desired properties of the output model (e.g. name := model.name). mapping main(in model: simpleuml::Model) : rdb::Model { name := model.name; schemas := package2schemas(model); }

Listing 7 Main mapping method for sample: simple UML to Relational DB

45

The follow-up query shown in Listing 8 shows how the elements for the schemas of the RDB target model are created from the packages in the source model. Beginning at the root package and walking through all the children packages recursively. query package2schemas(in root: simpleuml::Package) : OrderedSet(rdb::Schema) { package2schema(root)-> union(root.getSubpackages()-> collect (p | package2schemas(p)))-> asOrderedSet() }

Listing 8 Query helper method

3.3.3 Trace information The Together QVT interpreter can create trace information. This option, however, needs to be selected specifically. The traces contained in a separate trace file, consist of the mappings from source model elements to target model elements. In addition, the mapping method, which enforces the mapping, is stored. An example trace is the mapping from the package Family to the schema Family, enforced by the mapping method package2schema. Figure 14 shows the created traces for the sample transformation.

Figure 14 Generated traces in the simpleUML to RDB transformation sample

3.3.4 Referencing the sample to traceability in the MDA In the sample case discussed above, a source model is transformed to a target model. If we use the model in Figure 11 as a reference framework, we can map the various elements used in the transformation (described in sections 3.3.1-3.3.3) to the elements in this figure. This results in Figure 15. In addition, this figure shows the elements that cannot be identified by the elements from the transformation sample. The trace meta-model and trace model are not known, because the Operational Mappings based transformation does not specify the trace classes explicitly, but implicitly. Due to this automation, the tracing applied during the transformation is not transparent and only the actual traces are created, but no conclusions can be made on how this is done.

46

Figure 15 Elements used in the sample transformation mapped to traceability in the MDA

3.3.5 Conclusion This sample case shows the applicability and main structure of the QVT-based transformations in the Borland Together environment. This environment enables MDA transformations by a partial implementation of the Operational Mappings language and the OCL. The implemented language limits the user to top down modelling, always starting at some root node or model element. This element can however be chosen deeper in the meta-model, i.e. a model element can be chosen. The syntax highlighting and checking, namely type checking, helps the implementer to develop more efficiently and makes the entire transformation specification more transparent. In the modelling of the source models, the modeller however is limited to the set of meta-models, which are delivered with Borland Together. The evaluation and conclusions of the retrieved tracing information is discussed in the next section.

3.4 Evaluation of the tracing information From the trace information from the previous section, we can identify a couple of features. It however is not clear yet, if this is due to the simplicity of the chosen models or due to the chosen tool. These features are discussed in this section.

3.4.1 Referencing the sample tracing to the MDA First, we need to determine what information needs to be stored or gathered and where this should be done. Czarnecki and Helsen [10] do not specify this formally but only stipulate that this preferably should not be done in the source and target models, but rather in some external manner. They state that if every model element (in the source and target) receives a Globally Unique Identifier (GUID), the information can be stored elsewhere.

47

The information generated by Borland Together can be viewed in the form of a dependency graph, showing the source elements and the target elements. If we limit this view to some source model elements (model, packages and classes) and to the mapping methods related to those, the dependency graph in Figure 16 is created. Interesting to note is the notion of hierarchy in these mapping methods. Since the model is built in a tree like structure, the mapping methods can be placed on the nodes of the tree. With this information it is easy to see that from the main mapping method a step wise plan or execution schema can also be constructed in a tree like fashion. This is discussed further in section 3.4.2.

48

Table 4 shows the source model elements used in the dependency graph, which is a subset of the traces from section 3.3.3. In this table, the transformations are numbered with a main ID for the mapping method and a counter indicating the number of occurrence. For instance, the mapping method persistentClass2table is the third method executed and thus gets the main ID 3 and is used to transform three classes (R3.1 – R3.3) From the sample transformation, we see that the Borland Together based transformation creates traces in four sections:

1. Source Element 2. Target Element 3. (Mapping) method 4. Transformation identifier

Figure 16 Dependency graph showing some transformation elements from the sample

source Test:Model

Familiy:Package

Father:Class

target Test:Model

Mother:Class

Child:Class

Familiy:Schema

Father:Table

Mother:Table

Child:Table

R 1.1 R 2.1 R 3.1 R 3.2 R 3.3

49

Table 4 Trace information used in the dependency graph in Figure 16

Transformation ID

Source Target Mapping method

R 1.1 Test:Model Test:Model Main

R 2.1 Family:Package Family:Schema package2schema

R 3.1 Father:Class Father:Table persistentClass2table

R 3.2 Mother:Class Mother:Table persistentClass2table

R 3.3 Child:Class Child:Table persistentClass2table

On this platform, the names of the model elements are unique within the models, and can be used as indicators for the source and target elements. Due to the same argument, the names of the mapping methods can be used as indicators for these elements. The transformation identifier (the first column) is a simple counter, unique in its incremental fashion, associated to every execution of a mapping method. If we model this information, we get the trace meta-model that is shown in Figure 17.

Figure 17 Trace meta-model derived from simpleUML to RDBS sample

3.4.2 Execution tree If the tracing information from Table 5 is put on the nodes of a graph and the directed edges represent an invoking dependency, this will result in an execution graph5. Figure 18 shows this graph for the tracing information from the sample case. When the source model elements are now subjected to changes, we see that all the children nodes will also be impacted by the change. In Figure 18 this will be the sections of the graph, starting at the impacted node and fanning out to the right. The invoking relation, which is the path in the graph from the changed node going back to the root element, must be preserved with the undertaken changes. 5 These graphs are created with the help of the GROOVE tool, available from http://groove.sourceforge.net/groove-index.html

50

For instance, if we propagate a change to the element Father, this impacts elements in the sub-graph from node R4.1 and R3.1 to the right (marked with the ovals in Figure 18). Moreover, the R2.1 node needs to be preserved accordingly. This is a recursive effort, because in the preservation efforts changes possibly need to be made.

Table 5 Complete tracing information of simpleUML to RDBMS example

# From To Method R1.1 Model Test Model Test main()

R2.1 Package Family Schema Family package2Schema()

R3.1 Class Father Table Father persistentClass2table()

R4.1 Class Father Primary key PKFather class2primaryKey()

R5.1 Property isParent Table Column isParent primitiveAttribute2column()

R5.2 Property name Table Column Name primitiveAttribute2column()



R3.2 Class Mother Table Mother persistentClass2table()

R4.2 Class Mother Primary key PKMother class2primaryKey()

R5.5 Property isParent Table Column isParent primitiveAttribute2column()

R3.3 Class Child Table Child persistentClass2table()

R4.3 Class Child Primary key PKChild class2primaryKey()

R5.6 Property numParents

Table Column numParents

primitiveAttribute2column()

The information that is used and stored in the traces uses instances of meta-model elements. The information represents the model; if the meta-model dependencies need to be reviewed one has to check the mapping methods in the transformation specification. A meta-model representation, which shows the mappings used in the current sample, is shown in Figure 19. Here the edges have received labels representing the multiplicity of that rule, which indicates that the number of executions is not fixed.

51

Figure 18 Execution graph of simpleUML to RDB sample transformation

Figure 19 Execution graph of simpleUML to RDB sample mapping methods

3.4.3 Resolve methods In the use of Borland Together transformations, one can use Resolve methods to access the generated trace information. With these methods, the transformation writer has access to all created elements and can thus resolve bindings that need to be created between generated elements. With the help of an example some features of the resolve methods are reviewed. The transformation, which is used for this exemplification, makes a very simple one-to-one mapping from a simpleUML meta-model to another simpleUML meta-model, renaming all elements with an output_ prefix. Let us now look at the following query from the transformation specification:

52

query collectElems(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --collect the classes and associations handleCls(pack)->union(handleAsn(pack))->asOrderedSet(); }

Listing 9 collectElems query

This query calls two other queries, namely handleAsn and handleCls, which both transform all associations and classes, respectively. The actual implementation is not very important, but the order of execution is. If an association is found in the source model, this needs to be transformed to an association in the target model with correct bindings to the generated classes. This can be done in two different ways, which both utilize resolve methods. The first, more logical way, is to create all the classes and then create all the associations. Since all the classes are created, only a “normal” resolve method can query these results and bind the association to the correct classes. This is shown in the following sample: source := asn.source.resolve(simpleuml::Class)->any(true); target := asn.target.resolve(simpleuml::Class)->any(true);

Listing 10 Resolve sample

The second way is to change the order of execution, so the associations are transformed and then the classes are transformed. The late resolve methods can be used in this case. These late resolve methods can help with the referencing of objects that are not present at the current moment of execution, but will be created in the future. The following sample shows the use of the late resolve methods: source := asn.source.lateResolve(simpleuml::Class); target := asn.target.lateResolve(simpleuml::Class);

Listing 11 Late resolve sample

The created traces for the normal resolve will show that the associations are indeed transformed after the classes are transformed. When using the late resolve method, these are shown first. This order needs to be preserved in the transformation itself, if the order of execution is changed, to association before the classes, and not the late resolve method is used, the bindings of the created association will not be set correctly or not at all.

3.4.4 Scenarios In the previous sections, all mentioned transformations, create one-to-one mappings, i.e. a source has one target element related to it and visa versa. The question presenting itself is if this is always the case. The possibilities of other mappings should be researched and discussed, when the problem of changing a source model element is addressed.

3.4.5 Conclusion When a transformation, made with the help of Borland Together, is reviewed the execution of the rules and information created at run-time can be put in a hierarchal

53

tree like fashion. With this view, the impact of a change can be calculated by just following the execution of mapping methods. Borland uses resolve methods to make references to information, e.g. model elements, which is created a priory or is created in the future. The trace information created automatically cannot be altered by these methods. The transformations used in the examples use one-to-one mappings; this is studied further in the next sections.

3.5 Custom trace model A different approach, than the tracing from the previous section, is to store the trace information in the input and/or output model. By adapting from the transformation specification, we decorate the target model with the trace information needed. We need to create the traces into a model element, which is contained in the target meta-model. In our case, we implement the tracing in the Operational Mappings. We call this implementation, the custom trace model. The custom trace model is implemented by adding an intermediary step to the MDA transformation, which includes both the source and target models and relevant tracing information. We call the model resulting from this transformation, the intermediary model. Using this method needs extra transformations that generate certain views of the intermediary model. This is shown in Figure 20.

Figure 20 MDA transformation with custom tracing and querying activities

We see here that the MDA transformation pattern (see Figure 3) creates the intermediary model instead of the target model. This intermediary model needs to be queried to retrieve the desired models. In Figure 20 we see that we need three queries to retrieve the separate models from the intermediary model:

Source model Target model Trace model

54

We can also see an impact query, which uses the information from the intermediary model, to create an impact analysis for a change to the source model.

3.5.1 Custom trace model example In this section, a Borland Together implementation of the custom trace model is presented. For the basis, a simple one-to-one renaming transformation is used, which is added in full in appendix C. This transformation specification transforms a simpleUML model to a simpleUML model, where each name of a source model element is prefixed with the string output_.

3.5.1.1 The transformation The source model, which can be reviewed in Figure 21, consists of three packages, all containing sets of different classes and associations (the identifiers are chosen specifically as indicators and their meaning therefore is trivial). The transformation specification needs to rename all the source model elements, and needs to keep the bindings of the associations to be consistent with the created classes in the target model. The following algorithm is implemented:

Renaming algorithm 1. Rename model 2. Collect Packages

a. Rename packages b. Get packaged elements, per package c. Reset stereotype with information used in mapping

3. Collect Classes a. Rename classes b. Reset stereotype with information used in mapping

4. Collect Associations a. Rename associations b. From source class resolve new source class c. From target class resolve new target class d. Reset stereotype with information used in mapping

The main goal of the tracing addition to the specification is to indicate which source model elements are used to create which target model elements. The created intermediary model holds all source model elements, all target model elements and traces. The algorithm given above is now extended with the custom trace model:

Renaming algorithm with tracing 1. Copy the source model elements to the intermediary model

a. Collect all source model elements b. Put the source model elements in a simpleUML model

2. Renaming algorithm 3. Create tracing information

a. Collect all input model elements b. Resolve the created output elements c. Create trace class containing information

55

Figure 21 simpleUML input model

3.5.1.2 The traces The tracing information is stored as instances of type class, from the simpleUML meta-model. At first, the associations between source and target model elements are chosen to create the trace mappings. This, however, ended up in a dead end, due to meta-modelling limitations, when creating the in-model information. A package, for instance, cannot be linked to another package, because an association can only exist between two model elements of type class. In addition, the ability to create identification numbers for each execution of a transformation rule is not found. Therefore, this information cannot be stored in the custom traces. The intermediary model is shown in Figure 22, the un-collapsed items are the source elements and are identical to the ones that can be seen in Figure 21. The traces in the intermediary model, which contain the trace information, are shown at the bottom of the figure (Model traces). An example trace from this example:

trace_C2:Class ouput_C2:Class

We interpret the trace as follows:

Source model element C2 of type class is used to create target model element output_C2 of type Class. This information is also stored in two attributes of the trace. In this case the two added attributes have source C2:Class and target output_C2:Class attributes.

3.5.1.3 Querying the model The intermediary model created by the transformation contains three distinct models, which we see as the entire repository of transformation information. Eventually this information is needed and must be retrieved from this repository. We do this with three transformations, which are added in appendix D. These transformations needed here, respectively, are a retrieval of the source model, the target model and the traces from the intermediary model. Now we can also try to find the relevant trace information, when an element from the source model is subjected to a change. The impact analysis query, which is partly implemented in the Operational Mappings, only looks for traces containing the

56

impacted source model element. Creating a more elaborate analysis in the Operational Mappings language takes too much effort and time in the context of this project and another platform is chosen to create the impact analysis.

3.5.2 Conclusion The tracing information can be stored explicitly in an intermediary model. The addition of the source model in this model is possible. The trace information can be stored in any simple data structure or element from the target meta-model. However, when we add the source model elements to the intermediary model infers the use of the same meta-model for the target model. All the desired elements from the intermediary model can be queried. However, creating an entire impact analysis in the Operational Mappings language is very time consuming and does not add any extra insight into the tracing of transformations. The custom tracing does give us more insight into what is traced and how this is done, since the power of tracing lies within the transformation and makes the creation of the traces more transparent for the transformation writer.

Figure 22 Created intermediary model for simpleUML renaming example

57

3.6 Intra-level trace dependency cases The transformations used in the previous sections (cf. sections 3.3 and 3.5) all create one-to-one mappings between source model elements and target model elements. This implies that for every created target model element only one source model element is used. The trace information created, therefore, is distinct for every created target model element and the associated source model element. However, we assume the possibility to have mappings that are more complex, as is concluded from the different mappings possible between two domains (cf. section 2.4). The following sections elaborate on the scenarios that are possible, with respect to inter-level trace dependencies. We also take the number of transformation rules used into account. In addition, the manner in which impact analysis is performed for each case is investigated. We do this analysis by looking at the basic steps of changing a single source model element and we determine the impact this has on both the source and target models. The inter-level trace dependencies are chosen as the input for the analysis, because these are created by the trace models, discussed in the previous sections. The traces log the transformation execution, creating a trace for every mapping from source model element to target model element.

3.6.1 Inter-level and intra-level trace dependencies We limit the scope of this thesis to the inter-level trace dependencies between models. In the context of model transformations, we use the definitions of van den Berg [5] to distinguish between inter-level and intra-level trace dependencies. Van den Berg defines the intra-level trace dependencies between artefacts or products from the same level in the software engineering process. He defines the inter-level trace dependencies between artefacts from different levels of the software engineering process. In the context of a MDA transformation, these inter-level trace dependencies exist between elements from the source model elements to the target model elements. These dependencies are indicated as inter-level trace dependencies. The intra-level trace dependencies are the mappings between model elements within a model. We graphically demonstrate this in Figure 23, where the solid associations depict the intra-level trace dependencies and the dashed associations the inter-level trace dependencies.

58

Figure 23 Inter-level and intra-level trace dependencies

We see here that model element M1E1 has an intra-level trace dependency with the model element M1E2, which both are part of the model M1. In addition, the two model elements M2E1 and M2E2 in model M2 also have an intra-level trace dependency. The inter-level trace dependencies, dependencies between model elements in two different models, exist between model elements M1E1 and M2E1 and between model elements M1E2 and M2E2.

3.6.2 Introduction on scenarios In this section, we introduce the graphical - and formal notation, which we use in the subsequent sections. We specify a formal notation with the assumption that a model transformation is executed in some static hierarchy of transformation rules (cf. section 3.4.2) that makes it possible to reason on models in a set like fashion. In the following sections we make impact analyses, which are based on a single change to a source model element. The change types are limited to the (update) replacement of and (delete) subtraction of a source model element. We make this selection, because the scope is limited by the traces created during a transformation execution. These traces only log mappings from existing source model elements to target model elements. With this limitation, we cannot discuss the change scenario for adding source model elements, because no traces are based on source model elements that did not exist during the execution of the transformation.

3.6.2.1 Graphical notation In the following sections, models are used to show the inter-level trace dependencies between source and target model elements. The legend for these models is shown in Figure 24

59

Figure 24 Legend for models used in following sub-sections

A short description of the elements in this legend: Model domain: We only reason on some model elements, which are used in a

source model or target model. A model domain indicates that the model can consist out of more elements, but these do not take part in the case at hand.

Model element: An element residing in either a source model domain or target model domain, which is used in the case at hand. A source model element is used to create one or more target model elements.

Inter-level trace dependency: The trace logging an execution of a transformation rule, which maps a source model element to a target model element.

Change transition: When a change activity is made, then the model domains and traces are changed to an other state. Only one source model element can be subjected to a change.

Action: An activity can either be a change to a source model domain or an execution of a transformation rule.

Etc.: In some cases, the number of occurrences of traces and model elements is too large to put in the figures. The dots depict a set of model elements or traces.

An example model is shown in Figure 25. In this example, we see that a set of n source model elements is used to create one target model element. A single transformation rule is used to transform the set of source elements to the target model element. For every mapping from a source model element to the target model element an inter-level trace dependency exists, which is created by the transformation rule r1:

from source model element s1 to target model element t1 from source model element s2 to target model element t1

Etc. from source model element sn to target model element t1

60

Figure 25 Example model

3.6.2.2 Formal notation In the following sections, instances of source and target models are the subjects. These models are both composed of model elements and are used as sets of these elements: Source model S = {s1,s2,…,sn} Target model T = {t1,t2,…,tm} The target model is generated by an execution of some transformation specification. This transformation specification consists of a set of transformation rules: Transformation specification R = {r1,r2,…,rk} During the execution of the transformation specification traces are created. These traces map source to target model elements and log which transformation rule is used to create this mapping. This set and an example of a trace are: Traces I = {i1,i2,…,il} Trace i1 = (s1,t1,r1)

We need to indicate changes that are made to a model. Changes can also be seen as the complete set of possible changes that can be made on a model element. In the following sections, we limit ourselves to two change types: update and delete. In some cases, if we need to make a general remark about changing a certain element in a model, we use the change wildcard *: Change types C = {cu,cd,c*}

61

With this information, we can define a method that takes a change, a model and the impacted elements, and creates the new desired model:

change([change-type],[model],[element(s)]) = [model]’

[model] = a model

[element(s)] = a set of model elements [change-type] = a change-type

When applying a change to a source model, we need to keep the target model consistent with this change. This consistency is preserved with the implementation of the same change on the target model and thus the impacted element(s). We know that some transformation is used to create T from S, there now is a uni-directional relationship that can be pointed out. In the following sections this relationship is indicated by creates. This relationship is uni-directional because only sections of the source model may be used to create the target model. When the target model now is used to re-create the source model, this cannot be done completely. For instance: If we take a change to a source model S, e.g. implementing an arbitrary change to element s1, we get the changed model S’. From the traces, we know that element t1 in target model T is created by transformation rule r1, which takes s1 as input. We now know the following:

- S creates T - i1 = (s1,t1,r1) - Change(c*,S,{s1}) = S’ - Change(c*,T,{t1}) = T’

We now need to prove, with the help of the tracing information the following now holds:

- S’ creates T’

3.6.3 Case 1: One-to-one mappings In this case, a single source model element is mapped to a single target model element. This is done both for one transformation rule and for multiple transformation rules, where both create the target model element.

3.6.3.1 One-to-one mapping with one transformation rule Figure 26 shows a one-to-one mapping, where the model element s1 is transformed into model element t1 with the help of transformation rule execution r1(s1) = t1. The only trace created holds source element s1, target element t1 and transformation rule r1. The data contained in the source element s1 is mapped to target element t1. This indicates the lowest level of granularity on which this information is used to create source elements’ data.

62

Figure 26 One-to-one mapping created with one transformation rule

If a change propagates to s1, the impacted elements are found by following the only trace available, ending in target model element t1. If this knowledge is summarized, we end up with:

- S creates T - i = (s1,t1,r1) - Change(c*,S,{s1}) = S’ - Change(c*,T,{t1}) = T’

In the cases, we consider both the update and delete change types:

• Delete the source element Deleting s1 from S implies the deletion of t1 from T. This results in the change implementations, which creates the new source and target models: change(cd,S,{s1}) = S \ {s1} change(cd,T,{t1}) = T \ {t1}

• Update the source element

Updating s1 from S implies the re-execution of transformation rule r1 and replacing t1 with the newly created target model element. This results in the change implementation: change(cu,S,{s1}) = S \ {s1} U {s1’} where s1’ = manual input change(cu,T,{t1}) = T \ {t1} U {t1’} where t1’ = r1(s1’);

The change implementations are schematically shown in Figure 27 and Figure 28.

63

Figure 27 Delete change in one-to-one mapping

Figure 28 Update change in one-to-one mapping

64

3.6.3.2 One-to-one mapping with multiple transformation rules The one-to-one mapping can be extended; the source element is mapped to one target element, with the help of multiple transformation rules. This is schematically shown in Figure 29. It is possible that multiple rules are used to transform a single source model element to a single target model element. For instance, a distinction can be made which rule transforms what part of the source element, e.g. a rule able to transform a UML class and its attributes can be divided into a rule that copies the class and another rule that transforms the attributes. A difference between the two cases is the number of traces created during the execution of the transformation. In the previous example only one trace is created. In this example, a trace is created for every transformation rule used. To continue with the current work, the assumption is made that there is a fixed order in which these transformation rules are executed to create the desired target element (cf. Section 3.4.2). Because of this assumption we get a sequential list of transformation rules, {r1,r2,…,rn}. For every execution, a distinct trace is made from the source model element to the target model element, with the only difference being the transformation rule used. The set of traces therefore holds n elements, where n is the number of transformation rules needed. When these traces are collected, a list of traces with the following structure is created:

{(s1,t1,tr1),(s1,t1,tr2),…,(s1,t1,trn)}

Figure 29 One-to-one mapping created with multiple transformation rules

When the change types from the previous section are considered, only the update change-type needs to be changed, because of the one-to-one mapping between source and target model element s1 and t1. From the transformation creating this instance of t1, we deduce that with the same set of transformation rules a corresponding changed target model element is created:

65

• Update the source element Updating s1 from S implies the re-execution of transformation rules {r1,r2,…,rn} and replacing t1 with the newly created target model element. This results in the change implementation: change(cu,S,{s1}) = S \ {s1} U {s1’} where s1’ = manual input change(cu,T,{t1}) = T \ {t1} U {t1’} where

t1’ = r1(s1’); r2(s1’); …; rn(s1’);

3.6.4 Case 2: One-to-many mappings In the one-to-many case, a single source model element is mapped to multiple target model elements (scattering).

3.6.4.1 One-to-many mappings with a single transformation rule The change of source model element s1 now has multiple impacted elements in the target model {t1,t2,…,tn}. The traces created, during execution of r1 on element s1, have logged all mappings from s1 to the target elements, which are created from this execution: {(s1,t1,r1),(s1,t2,r1),…,(s1,tn,r1)}.

Figure 30 One-to-many mapping created with a single transformation rule

For the two change types, we formulate the following change implementations:

66

• Delete the source element When deleting s1 from S results in the deletion of all elements {t1,t2,…,tn} contained in T, that are created from s1. This results in the following change implementations: change(cd,S,{s1}) = S \ {s1} change(cd,T,{t1,t2,…,tn}) = T \ {t1,t2,…,tn}

The impacted elements {t1,t2,…,tn} can be found by following all traces starting at source element s1.


Changing data in s1 from S must be changed also in the created target elements. To do so we need to create a new set of elements from the changed model element s1’. This can be done with the help of the single transformation rule r1: change(cu,S,{s1}) = (S \ {s1}) U {s1’} where s1’ = manual input change(cu,T,{t1,t2,…,tn}) =

T \ {t1,t2,…,tn} U {t1’,t2’,…,tn’} where

{t1’,t2’,…,tn’} = r1(s1’);

The impacted elements can be found by following all traces beginning in s1. If we however know what data of s1 is used in what target elements and which section(s) of r1 use that data, a smaller replacement might be possible.

3.6.4.2 One-to-many mapping with multiple transformation rules The previous case can be extended with the notion of multiple transformation rules, which are used to create the desired output. When not every transformation rule creates dedicated target elements, like in the previous cases, but if the information from the source element is (partially) re-used in other target elements, the change implementation need to be revised. The possible mappings are schematically shown in Figure 31.

67

Figure 31 One-to-many mapping created with multiple transformation rules

In this case, a single source model element transforms into two or more target model elements. This is done with the help of multiple mapping methods. The target model elements created can now differ from each other, because of the different use of the source model element. The traces that log the impacted source element and map to the target elements can have one of the following structures:

- The source element maps to one target element, with one mapping method - The source element maps to one target element, with multiple mapping

methods - The source element maps to multiple target elements, with one mapping

method - The source element maps to multiple target elements, with multiple mapping

methods In the following implementations the source element s1 is changed. The impacts can be retrieved from the following set of traces:

I = {(s1,t1,r1),(s1,t2,r1),(s1,t2,r2),…,(s1,tn,rk)} We specify the change implementations for the delete and update change types:

• Delete the source element

When deleting s1 from S results in the deletion of all elements {t1,t2,…,tn} contained in T that are created from s1. This results in the following change implementations: change(cd,S,{s1}) = S \ {s1} change(cd,T,{t1,t2,…,tn}) = T \ {t1,t2,…,tn}

68

The impacted elements {t1,t2,…,tn} can be found by following all traces starting at source element s1.


Updating s1 from S must be changed also in the created target elements. To do so we need to create a new set of elements from the changed model element s1’. This can be done with the re-execution of the set of transformation rules: change(cu,S,{s1}) = (S \ {s1}) U {s1’} where s1’ = manual input change(cu,T,{t1,t2,…,tn}) =

(T \ {t1,t2,…,tn}) U {t1’,t2’,…,tn’} where

{t1’,t2’,…,tn’} = r1(s1’);

r1(s1’); r2(s1’); …; rk(s1’);

3.6.5 Case 3: Many-to-one mappings In the many-to-one case, multiple source model elements are mapped to a single target model element (tangling).

3.6.5.1 Many-to-one mapping with a single transformation rule In this example, where multiple source elements are mapped to a single target element, with the help of one transformation rule, the relevant traces, which have logged this transformation, all have the same target and transformation rule attribute in the triple. The main difference between this example and the next example is the change to a source element now has an indirect relation between at least one more source model element. This relation is created due to the execution of the single transformation rule, which takes more source model elements to create the target model element. This case is schematically shown in Figure 32.

69

Figure 32 Many-to-one mapping created with one transformation rule

A change to one of the source elements needs to be followed through to the entire set of source elements used in the transformation. In other words, we cannot assume that the re-execution of the changed source element results in the desired target element, but rather the collaboration of source elements in the transformation rule results in the target model element. In addition, since we are only exploring the possibilities of inter-level trace dependencies, we assume that

r1(s1,s2,…sn) = t1 = r1(s1); r1(s2) ; …; r1(sn);

From the set of traces, created during the execution of this example, we can extract the set of used source elements; {s1,s2,…,sn}. For now we will assume that the re-execution over the entire set is needed, when one of the elements from this set is subjected to a change. We get the following two change implementations for the delete and update change-types:

• Delete a source element When deleting an element from {s1,s2,…,sn} will result in the deletion of the data used from this element in target model element t1 contained in T. This results in the following change implementation, when element s2 is deleted from {s1,s2,…,sn}: change(cd,S,{s2}) = S \ {s2} change(cd,T,{t1}) = (T \ {t1}) U {t1’} where

t1’ = r1(s1); …; r1(sn);

70

In this case, we assume that the deletion of s2 does not inflict with the transformation rule used, because this cannot be checked with the information contained in the traces.

• Update a source element Changing an element from {s1,s2,…,sn} must also be changed in the created target element. The new target element can be created with the re-execution of the transformation rule with the replacement of the changed element in the set of used source elements. This results in the following change implementation, when s2 is changed: change(cu,S,{s2}) = (S \ {s2}) U {s2’} where s2’ = manual input change(cu,T,{t1}) =

(T \ {t1}) U {t1’} where

t1’ = r1(s1);

r1(s2’); …; r1(sn);

Again, we must assume that the update to s2 does not change the selection of source model elements for the transformation rule r1.

3.6.5.2 Many-to-one mappings with multiple transformation rules The previous example can be extended with the notion of multiple transformation rules. The set of source elements used to create the desired target element can now be grouped by the transformation rules:

- The (to be) changed source element is mapped to the target element, with one transformation rule

- The (to be) changed source element is mapped to the target element, with more than one transformation rule

71

Figure 33 Many-to-one mapping with multiple transformation rules

If the traces are ordered in this fashion, we know in what order the re-execution needs to take place. Let us assume that this is the case for the trace set I, which is created during the transformation execution. In the following change implementations, we change s2 from {s1,s2,…,sn}, where s2 is used three times namely:

I = {(s1,t1,r1),(s2,t1,r1),(s2,t1,r2),(s2,t1,rk),…,(sn,t1,rk)} We now get the following two change implementations for the delete and update change-types:

• Delete a used source element

In the deletion of some source element, from the set used to create the desired output, we need to skip every transformation rule execution, which uses that specific source element. In the following implementation, s2 is changed. To cope with that change in the target model, all transformation executions using source element s2 must be skipped: change(cd,S,{s2}) = S \ {s2} change(cd,T,{t1}) = (T \ {t1}) U {t1’} where

t1’ = r1(s1); …; rk(sn);

72

• Update a used source element Changing an element from {s1,s2,…,sn} must also be changed in the created target element. The new target element can be created with the re-execution of the transformation rule with the replacement of the changed element in the set of used source elements. This results in the following change implementation, when s2 is changed: change(cu,S,{s2}) = (S \ {s2}) U {s2’} where s2’ = manual input change(cu,T,{t1}) = (T \ {t1}) U {t1’} where

t1’ = r1(s1); r1(s2’); r1(s2’); r2(s2’); …; rk(sn);

3.6.6 Case 4: Many-to-many mappings In the next two examples the many-to-many case is discussed. In this case, it is possible that both tangling and scattering occurs.

3.6.6.1 Many-to-many mappings with a single transformation rule In this example, all traces created during the transformation execution use the same transformation rule. All relevant traces therefore have the same transformation rule. Since this transformation rule is the only commonality in the traces, we cannot just assume anything about the source or target elements, as was done in the previous cases. When we use the trace information, to make some impact analysis or change implementation, the only information usable from the trace-set is the order of the traces in which they were created. However, there are several possible mappings possible for a source element:

- The source element can map to one target element - The source element can map to several target elements

If a source element is changed, we know what target element(s) is (are) impacted. From these set of impacted elements, the set of source elements used to create these target elements can be derived. We now end up with a set of source elements, also containing the source element subjected to the change. In the following change implementations, we change s1 from {s1,s2,…,sn}, where s1 is used one time and s2 three times, namely:

I = {(s1,t1,r1),(s2,t1,r1),(s2,t2,r1),(s2,t3,r1),…,(sn,tm,r1)}

From the traces, we see that t1 is the directly impacted target model element. This element is created from multiple source elements, so some back-tracing is needed to find those source model elements. From this example we, for instance, see that s2 also is used to create t1. When this is done for all the target elements, which we will not further elaborate on now, we end up with the set of source elements, which must be used to implement the

73

change. However, when this set is used again in the re-execution also other duplicate target elements may be created. These must be discarded and not be put into the eventual updated target model. This discarding can be done by choosing the target model elements which were not directly impacted by the change, in this example those elements are {t2,t3}. We do not know if these elements are complete after the re-transformation or have other transformations completing them. To discard them in the union of the old target model and the new element(s) is the easiest manner to cope with this problem. For the delete and update change types we now get the following change implementations:

• Delete a used source element In the deletion of some source element, from the set used to create the desired target elements, we need to skip every transformation rule execution which uses that specific source element. In the following implementation s1 is changed from the example given above. To cope with that change in the target model, all transformation executions using the deleted source element must be skipped and the correct set of target elements need to be replaced in the target model. When source element s1 is deleted in the example: change(cd,S,{s1}) = S \ {s1} change(cd,T,{t1}) = ((T \ {t1}) U {t1’}) where

{t1’, t2’, t3’,…} = r1(s2);

• Update a used source element Changing an element from {s1,s2,…,sn} must also be changed in the created target elements. The new target element can be created with the re-execution of the transformation rule with the replacement of the changed element in the set of used source elements. This results in the following change implementation, when s1 is changed in the example: change(cu,S,{s1}) = (S \ {s1}) U {s1’} where s1’ = manual input change(cu,T,{t1}) = (T \ {t1}) U {t1’} where

{t1’, t2’, t3’,…} = r1(s1’); r1(s2); r1(s2); r1(s2);

3.6.6.2 Many-to-many mappings with multiple transformation rules In the case where the example given above is extended with multiple transformation rules, not much changes, since the rules are just needed for some re-execution. If we adapt the example with the following set of traces:

I = {(s1,t1,r1),(s2,t1,r1),(s2,t2,r2),(s2,t3,r2),…,(sn,tm,ro)}

74

We now get the following change implementations for the deletion and update change-types:

• Delete a used source element In the deletion of some source element, from the set used to create the desired target elements, we need to skip every transformation rule execution which uses that specific source element. In the following implementation s1 is changed from the example given above. To cope with that change in the target model, all transformation executions using the deleted source element must be skipped and the correct set of target elements need to be replaced in the target model. When source element s1 is deleted in the example: change(cd,S,{s1}) = S \ {s1} change(cd,T,{t1}) = ((T \ {t1}) U {t1’}) where

{t1’, t2’, t3’,…} = r1(s2);

• Update a used source element Changing an element from {s1,s2,…,sn} must also be changed in the created target elements. The new target element can be created with the re-execution of the transformation rule with the replacement of the changed element in the set of used source elements. This results in the following change implementation, when s1 is changed in the example: change(cu,S,{s1}) = (S \ {s1}) U {s1’} where s1’ = manual input change(cu,T,{t1}) = (T \ {t1}) U {t1’} where

{t1’, t2’, t3’,…} = r1(s1’); r1(s2); r2(s2); r2(s2);

3.6.7 Evaluation of the cases

Table 6 Cases and number of traces created

Case # rules # traces

1 1 one-to-one k k 1 m one-to-many k [k…k*m] 1 m many-to-one k [k…k*m] 1 [max(m,n)…m*n] many-to-many k [k*max(m,n)…m*n*k]

In the cases and examples given in the previous sections some abstractions can be made, regarding traceability based impact analysis and change implementation. The event-based changes (deletion and updating elements manually) made in these sections share commonalities:

75

- When a source element is subjected to some change, it is necessary to find the directly impacted target elements. This can be done by collecting all the traces starting at the source element that is subjected to the change and collecting all target elements that it is mapped to.

- In the examples where multiple transformation rules are used, the transformation rules can also be collected from the trace set. From this set of transformation rules we now know which rules must be used in the re-execution, needed for the change implementation.

- All change implementations that require re-transforming source elements to target elements, are derived from the trace set I where the ordering of the traces can be used to schedule the (partial) re-transformation.

There are also some new problems that arise from the cases, which must be addressed further:

- When traces exist from a source element to multiple target elements using the same transformation rule, we don’t know if this is done by one execution of that transformation rule (creating all target elements at once) or that it takes several executions (creating one or more elements per execution).

- The merging of the change in the source model and target model need to be supported on the chosen transformation platform.

- The discarding of some newly created elements, in the many-to-many case, needs to be identifiable with existing target model elements.

- The use of guards in the transformation rules is not handled.

3.7 Adding and removing elements Although the addition of new elements cannot be based on traces (inter-level trace dependencies), we however can say something about the introduction of elements. First, we must assume that the introduction of new elements is done in some specific order; during regular modelling activities, these restrictions are implied by the chosen meta-model. For instance, when one wants to introduce a new association in an UML model there should be two classes that can be associated. This sounds very trivial, but when one wants to create a new class and some association, or other relation, between that class and already existing one(s), the class needs to be added first and then the association needs to be added. When the association is added, prior to the class, the association is not used according to the UML meta-model. This is shown schematically in Figure 34 and Figure 35. The same ordering principle holds for the deletion of elements from the model. If we look back at the source model from Section 3.3, we cannot just delete a primitive type without deleting all the attributes which are typed with it. In short the addition or deletion of model elements must conform to the chosen meta-model.

76

Figure 34 Adding elements in the wrong order

Figure 35 Adding elements in the correct order

3.8 Transformation rules and changes Transformation rules can hold guards or selectors over source model elements. These limit the execution of the rule, if the guard fails. Applying changes to a model can therefore have a disastrous result on the re-execution of the transformation

77

specification. When this specification is not created to be capable to cope with the dynamic nature of meta-models, so not all possible instances of the source meta-model are taken into account when the specification is written, a change to the source model can render the transformation not executable. An example of this is the following merge implementation in the Operational Mappings language: query mergeQ(in model:simpleuml::Model): OrderedSet(simpleuml::Packageable) { merge ( model.ownedElements -> collect(oclAsType(simpleuml::ModelElement)) -> asOrderedSet() -> at(1), model.ownedElements-> collect(oclAsType(simpleuml::ModelElement)) -> asOrderedSet() -> at(2) )->asOrderedSet() } mapping merge (in modelElem1:simpleuml::ModelElement, modelElem2:simpleuml::ModelElement): simpleuml::Package { object { name := modelElem1.name + ' + ' + modelElem2.name + ' id=' + count; } }

Listing 12 Statically implemented merge algorithm of two elements

This implementation takes a UML model, selects the first two elements and creates one UML package, with a name containing a concatenation of the names of the first two elements. Let us now consider the possibility where we have a source model with two packages, for which this method was created. Now in the deletion of one of these two packages the transformation fails, because we need the statically chosen first and second element.

3.9 Example change impact analysis and implementations In this section the implementation and process of the example cases’ change impact analysis and implementation is practically tested. Because these implementations are more illustrative than elaborate, we use the small model from Figure 36.

Figure 36 Source model for example change impact analysis and implementations

The transformations that we have written, do not cover all meta-model instances, but are more a proof of concept for the sample cases. Therefore, the transformations only cover this model and the two instances of the changed (deletion and update) source model.

78

A delete change consists of the deletion of package 1 from the input model (see Figure 37) and the update change is represented by a renaming of Package 1 to Package 1_new (see Figure 38).

Figure 37 Source model with delete change implemented

Figure 38 Source model with update change implemented

The transformations written per case are simpleUML to simpleUML mappings. We use the following mapping methods in the various cases:

Copy: A copy of each package is made and placed in the target model. This is implemented by just mapping the names of the elements. This mapping takes a model element and creates a package in the target model containing the same name.

Copy twice: Makes multiple mappings of a source element to multiple target elements.

Merge: Collecting the two packages and creating one package with information from both source elements or just one element if one is available.

Merge and copy: Here a merge is created twice. mapping copy(in modelElem:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem.resolveByRule( 'copy',simpleuml::ModelElement ) -> size(); } object { name := modelElem.name + ' id=' + count; } }

Listing 13 The copy mapping

79

mapping merge(in modelElem1:simpleuml::ModelElement, modelElem2:simpleuml::ModelElement) : simpleuml::Package { init { var count := modelElem1.resolveByRule( 'merge',simpleuml::ModelElement ) -> size(); } object { name := modelElem1.name + ' + ' + modelElem2.name + ' id=' + count; } } mapping merge(in modelElem1:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem1.resolveByRule( 'merge',simpleuml::ModelElement ) -> size(); } object { name := modelElem1.name + ' id=' + count; } }

Listing 14 The merge mapping

The specifications for the cases are added in Appendix F. In some of the cases, the following scheme is used to work around some implementation issues:

- Overwrite: Because there is a need for multiple transformation rules, a scheme is used to cover this for some cases. The overwrite-action is created by just copying the normal copy method and creating a method that does the same, overwriting the elements created by the first copy method.

An overview of the methods used per case is added in Table 7

Table 7 Transformations implemented per scenario

Scenario One-to-one One-to-many # rules 1 K 1 k

transformation Copy Copy (+overwrite) Copy 2x Copy 2x Scenario Many-to-one Many-to-many # rules 1 K 1 k

transformation Merge Merge (+overwrite) Copy and

Merge

Copy and Merge (+ overwrite)

The implementations of the transformations need some extra information stored in the target model elements. Since some elements use the same name and the analysis is done on parsing and string comparisons, these target elements need to be more distinctive. We therefore have added an id tag to every target model element.

80

A Java program is used to perform the impact analysis. This program handles all the intermediary models created in the sample cases and therefore limits the number of transformations that need to be written. If this approach of specifying change impact analysis transformations is chosen, this will result in an extra transformation specification for every case, which would have an explosive effect. Preferably, this impact analysis is functionality that is available in the MDA tool chosen. In the Borland Together platform only the modelling of the source model, specifying the transformation specification, running the transformation and creating some tracing information is available. The notion of a live transformation, keeping the traces up-to-date, besides the models and transformation specification(s), therefore extends the capabilities of the platform. This makes it more flexible for changes, preferably doing this in the background. Implementing the change propagation falls outside the scope of this project. The re-execution of some rules needs to be the basis of the incremental change implementation. This is not possible in the Borland Together platform and can therefore only be described theoretically. The impact analysis is based on the results found in the previous section. As is mentioned there, the change implementation mimics the behaviour of the transformation rules which need to be re-executed. An architecture of the Java program is added in Appendix E.

3.9.1 One-to-one mapping with a single transformation rule

Figure 39 One-to-one with one transformation rule example

In this case, all the source elements are mapped to exactly one target element, where the name is used to create the target element. The created target model, decorated with traces can be seen in Figure 40.

81

Figure 40 Intermediary model for one-to-one case with one transformation rule

3.9.1.1 Impact Analysis When we want to change model element Package 1, we retrieve the impact analysis shown in Listing 15. This analysis consists of the directly impacted target model element Package 1 (id = 0) and that the source model element, which created it, Package 1. One trace is used to retrieve this information and shows that the transformation rule copy is used to create the target model element Package 1 (id = 0) from the source model element Package 1. One2OneSingle: impacted target elements: Package 1 id = 0, rule used = copy un-impacted target elements: Package 2 id = 0, rule used = copy preserve the following sources: Package 1 created by the following executions: copy(Package 1) = Package 1 id = 0 Re-execution schema for update: copy(Package 1_new) = Package 1_new id = 0

Listing 15 Impact analysis for a change to source model element Package 1

3.9.1.2 Delete change In the deletion of Package 1 from the source model, the desired new target model should also have the created Package 1 (id = 0) deleted. This results in the following model:

Figure 41 Changed intermediary model for the one-to-one case with the deletion implemented

82

In the update of the name of source model element Package 1 to Package 1_new, the target model should also be updated the created target element Package 1 (id = 0). This results in the following model:

Figure 42 Changed intermediary model for the one-to-one case with the update implemented

3.9.1.3 Implement the changes incrementally From the impact analysis, we see that the following section of the intermediary model is not changed:

Figure 43 Un-impacted intermediary model

This model immediately is the changed target model for the delete change. Running the transformation on an empty model results in an empty model and adds nothing to this model. For the update change, we however do not have an empty model, but the following model, where the source model element Package 1 name is changed to Package 1_new:

Figure 44 Changed sub-source model

The selection of transformation rule(s) is shown in the impact analysis done. Here we only need the copy method. In this case, we need to use the copy method and the custom trace methods. In addition, the queries supporting the copy and tracing methods are required. Remarkably we now have reassembled the entire transformation specification, which is used on the changed sub-source model. The new sub-target model created is:

83

Figure 45 Updated sub-target model

If this model now is merged with the un-impacted intermediary model from Figure 43, we get the correctly updated target model, which is show in Figure 42.

3.9.2 Many-to-many mapping with multiple transformation rules

Figure 46 Many-to-many with multiple transformation rules example

In this many-to-many case, two transformation rules are used which both merge two packages to two target model packages. The second rule overwrites the two packages, which are created by the first merging.

3.9.2.1 Impact analysis We again want to change source model element Package 1. The impact analysis created for this case is shown in Listing 16. We see that both the target model elements are directly impacted by the change. Due to the merging it is easy to see that both the source model elements are used in the transformation to create both the target model elements. Also a re-execution of both the transformation rules merge and merge2 is needed, because both have used the source model element Package 1. Both the target model elements have received the tag id = 0. This is explained by the fact

84

that the id is calculated according to the transformation rule used, which then can be used as a determinant between the two. Many2ManyMulti: impacted target elements: Package 1 + Package 2 id = 0, rule used = merge2 Package 1 + Package 2 id = 0, rule used = merge un-impacted target elements: preserve the following sources: Package 1 Package 2 created by the following executions: merge2(Package 1) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0 Re-execution schema for update: merge2(Package 1_new) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1_new) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0

Listing 16 Impact analysis for a change to source model element Package 1 in the many-to-many case

3.9.2.2 Delete change In the deletion of Package 1 from the source model, the desired new target model should also remove the Package 1 from the merge with Package2. This results in the following model:

Figure 47 Intermediary model for the many-to-many case with the delete change implemented

3.9.2.3 Update change In the update of the name of Package 1 to Package 1_new from the input model the desired new model should also update the created target element Package 1. This results in the following model:

85

Figure 48 Intermediary model for the many-to-many case with the update change implemented

3.9.2.4 Implement the changes incrementally From the impact analysis, we see that the entire source and target model need to be taken into account when a change to one source element is made. The change propagation to source model element Package 1 implies that also the source model element Package 2 is needed for the re-execution. For the delete change, we can just delete the source element Package 1 from the model, and rerun the entire transformation. This re-execution results in the intermediary model in Figure 47. When applying the update change to the model, we also need the source model element Package 2. This implies a reuse of the entire source model, with the changed name for Package 1 implemented. We therefore re-execute the entire transformation again and get the model in Figure 48.

3.10 Change management process in the MDA For the cases, described above, we can now determine what the impacted target elements, executed rules and used source elements are. The implementation of a change is only possible by a re-execution of the entire transformation, transforming the updated source model, from which the corresponding updated target model is created. The traces log the execution of the transformation, and can thus provide support for a live update, as described by Hearnden et al. [13] (see Section 2.4.2). This results in the process in Figure 49. This figure shows the process we use in this project. The modelling and initial transformation, with the creation of the intermediary model, is done in Borland Together. The Java program does the impact analysis. The last section, the actual change implementation, cannot be implemented easily on the Borland Together platform. We, however, are able to show what needs to be done in the transformation platform to implement the change at hand, incrementally. These steps are based on the impact analysis and re-execution schema, which are both results from the Java program. The activities in this change management process, which are also numbered in Figure 49, now are:

(1) Model the source model

86

(2) Specify the transformation specification, which includes the custom trace model

(3) Create the intermediary model, which contains the source model, target model and the traces

(4) Introduce a change to a source model element (5) Run the impact analysis by running the intermediary model with the change at

hand in the Java program (6) Determine the un-impacted intermediary model (7) Create the changed intermediary model (8) Merge the un-impacted and changed intermediary model

The following activities need to be made by hand:

- Discuss how the re-transformation is created or run; which rules are used, what inputs are needed and what outputs are retrieved.

- Discuss how to merge the resulting new model elements and the un-impacted model elements.

Figure 49 Change management process

3.11 Discussion The change management framework resulting from the previous sections is purely theoretical. The steps discussed to change a target model incrementally are made over a various set of platforms (Borland, Java, by hand). Ideally, this should be done in one

87

platform, where the change is just made and the implementation to the target model is done automatically (in the background). The custom trace model created takes a lot of work to implement and is only applicable to simpleUML to simpleUML transformations. The traces created by Borland Together contain sufficient information to support the change management process. However the platform lacks any support to do anything with these traces. It would have been possible to use this trace class as an input for the Java program, but would have needed a more extensive parser, parsing links between source and target model. In addition, the implementation of the custom trace model adds more insight to what is traced and how this is done. The resulting intermediary model after a transformation holds all the information needed to make an impact analysis, which would have taken all three models (source, target and trace) from the Borland Together platform. The Java program itself is written to support the change analysis on the sample cases described in the previous sections. This program only parses the elements and performs the impact analysis, which results in a set of target model elements and a set of source model elements that are used to create that impacted set of target elements. The steps done by hand are only there to show that the necessary steps can be made with the information at hand, and in some cases, show that the propagation of the change can be done with an incremental approach. However, it also shows that, due to the preservation of source model and impacts on the target model, a re-execution of the entire transformation, which is much more elaborate than just a re-execution when the source model is changed. The transformations written are limited to a small set of models. The transformation specifications cover not all possible meta-model instances, but are limited to the set of models at hand now.

3.12 Summary In this chapter, we propose a trace model in the MDA, which consists of logging the execution of the transformation specification. A single trace now is structured into a source model element, a target model element and the transformation rule used. The set of all traces represent the mappings made by the transformation. The traces can be created automatically by some tool, which does not give insight into the creation of the traces and a meta-model for the traces. We have made an implementation of the trace model into the transformation specification, which does gives this insight. We call this implementation the custom trace model. We use this custom trace model to give further insight into the creation of traces. We have implemented the custom trace model on the Borland Together platform and have introduced an intermediary model, which contains the source model, target model and traces. This approach however infers us to use the same meta-model for both source and target. We have determined that an impact analysis, based on the transformation context, is sufficient for changing attributes (i.e. the identifier) of model elements. An impact analysis for deleting and adding elements to the source model needs more information, due to meta-model restrictions. By viewing models as sets of elements, we have studied that incremental model compilation can be used to implement changes. In this method, a compilation of the un-impacted target model elements and the changed target model elements can be made. The changed target model elements are created by a retransformation of the

88

impacted source model elements, where the re-execution is planned based on the traceability-based impact analysis. We have written a Java program, which is used to perform this impact analysis. The incremental compilation or other change implementation, ideally is done on the implementation platform, which allows the changes to be re-executed by a selection from (a subset of) the transformation rules. This implementation falls outside the scope of this project. The transformations we have implemented show the various mappings possible between source model elements and target model elements, which are both discussed theoretically and practically. The change types that we have handled in these samples are limited to those which can be supported by tracing, e.g. inter-level trace dependencies. Adding source model elements, deleting source model elements and transformation rules’ guards need to also be supported by some meta-model restrictions.

89

4 Case study – Flattening simpleUML models

In this chapter, a case study is made on a more elaborate scale, than the ones from the previous chapter. The change management framework discussed in the previous chapter is used in the propagation of some changes to the chosen source model and shows the main pros and cons of the chosen approach.

4.1 Introduction In this chapter a more elaborate case study, which applies the change management process from Section 3.10, is made: First, we discuss the case study chosen, which is based on an Operational Mappings flattening transformation of simpleUML models. Next, we apply the change management process to some changes to source model elements. An evaluation of the use of the change management process is made at the end of this chapter.

4.2 The case In this case study, a flattening transformation of simpleUML class hierarchies is chosen. A source model is transformed to another simpleUML model in which only the leaf classes (classes not extended by other classes) in inheritance hierarchies are kept. An example source model is shown in Figure 50. The target model shown in Figure 51, is the result of the flattened source model. We start with the integration of the custom trace model in the transformation specification. Afterwards we create the intermediary model, using a source simpleUML model with generalization relations. The traces created are used to determine which mappings are available in the case. For each of these mappings a delete change and update change to a source model element is discussed, for which we use the change management process from the previous chapter (Section 3.10). The activities in this change management process, summarized, now are:

1. Model the source model 2. Specify the transformation specification, which includes the custom trace

model 3. Create the intermediary model, which contains the source model, target model

and the traces 4. Introduce a change to a source model element 5. Run the impact analysis by running the intermediary model with the change at

hand in the Java program 6. Determine the un-impacted intermediary model 7. Create the changed intermediary model 8. Merge the un-impacted and changed intermediary model

90

Figure 50 Example source model

Figure 51 Example target model

91

4.3 The transformation The transformation used in this case study implements the following flattening algorithm:

Flattening algorithm 1. Create target model 2. Copy the primitive types

a. Collect primitives b. Copy each primitive type a target primitive type

3. Collect the leaf Classes a. Collect properties of class b. Collect properties of general classes

4. Collect Associations a. Determine the source element to the correct leaf class by following the

generalization relations b. Resolve the target class from the list of created classes

5. Create traces The implementation consists of four mapping methods, besides the main mapping method, which combined create the desired flattening implementation:

• copyprimitive - Copy a simpleUML primitive type to a corresponding primitive type in the target model

• leafClass2Class - Copy a simpleUML class, which is not extended by other classes.

• copyAssociation - Copy a simpleUML association, with the correct source class, which inherits the association from a general class.

• property2property – Copy the properties, including the inherited properties from general classes.

The transformation specification for this case study is added in appendix H. The custom trace model, implemented and used in the previous chapter, is integrated to handle the tracing. The tree structure of the source model is shown in Figure 52 and the tree structure of the transformed source model is shown in Figure 53. Because the transformation can be reused for a change to the source model, the corresponding target model can be created for every change to the source model. The current implementation is not a complete flattening solution. The associations between general classes cannot be resolved in the transformation, and thus limits the number of source models it can transform. In addition, when an attribute is inherited from a general class, which has the same identifier as an attribute that already is a member of the class, this inherited attribute is neglected and thus is not added to the class in the target model.

92

Figure 52 SimpleUML source model for case study

93

Figure 53 SimpleUML target model for Case study

The intermediary model, which is the result from the transformation with the custom trace model, is shown in Figure 54. In this model only the input and output models are un-collapsed. The target model elements are marked with numbers. This is done for the same reason as in the sample cases: to be able to distinct elements with the same name. The entire intermediary model is added in appendix I. The mappings that are derived from the traces are summed up in Table 8. From these traces a selection is made for the change analysis and implementation in the following section. There exist target elements with the same name and identifier, because some properties have the same name but are created by another transformation rule.

94

Figure 54 Intermediary model for case study, only showing source and target models

Table 8 Generated mappings during transformation

Trace #

Source element

Target element Transformation rule

1 Car Car (id = 1) leafClass2Class

2 PhDStudent PhDStudent (id = 1) leafClass2Class

3 Professor Professor (id = 1) leafClass2Class

4 FullName FullName (id = 1) leafClass2Class

5 Course Course (id = 1) leafClass2Class

6 Address Address (id = 1) leafClass2Class

7 Car carOwnership (id = 1) copyAssociation

8 PhDStudent supervisor (id = 1) copyAssociation

9 PhDStudent attends (id = 1) copyAssociation

10 PhDStudent residesAt (id = 1) copyAssociation

11 Professor residesAt (id = 2) copyAssociation

12 carOwnership carOwnership (id = 1) copyAssociation

13 supervisor supervisor (id = 1) copyAssociation

95

Trace #

Source element

Target element Transformation rule

14 residesAt residesAt (id = 2) copyAssociation

15 residesAt residesAt (id = 1) copyAssociation

16 attends attends (id = 1) copyAssociation

17 name name (id = 1) property2property

18 ssn ssn (id = 2) property2property

19 ssn ssn (id = 1) property2property

20 school school (id = 1) property2property

21 organizationName organizationName (id = 1) property2property

22 PhDStudent name (id = 1) property2property

23 PhDStudent ssn (id = 1) property2property

24 PhDStudent school (id = 1) property2property

25 Professor name (id = 1) property2property

26 Professor organizationName (id = 1) property2property

27 Professor ssn (id = 2) property2property


29 FullName lastName (id = 1) property2property

30 FullName firstName (id = 1) property2property

31 firstName firstName (id = 1) property2property

32 lastName lastName (id = 1) property2property

33 Course name (id = 1) property2property


35 Address city (id = 1) property2property

36 Address street (id = 1) property2property

37 street street (id = 1) property2property

38 city city (id = 1) property2property

39 String String (id = 1) copyprimitive

4.4 Change cases In the previous chapter, all possible traces between source and target are discussed and sample transformations per case are specified. For this case study a selection of mappings, between source and target model elements, is based on the traces from the previous section that are created during the transformation. The selection of cases in this case study is narrowed, because not all possible mappings are available. The selection is shown in Table 9.

Table 9 Selected mappings from case study

Case Source element(s) Target element(s) 1 to 1 single transformation rule

<<Primitive type>> String

<<Primitive type>> String (id = 1)

1 to 1 multiple transformation rules

Not available -

1 to N single transformation rule

Not available -

1 to N multiple transformation rules

Not available -

96

Case Source element(s) Target element(s) N to 1 single transformation rule

Class Professor, Property orginizationName

Property orginizationName (id = 1)

N to 1 multiple transformation rules

Not available -

N to M single transformation rule

Class Professor, Class PhDStudent, Property ssn

Property ssn (id = 1) Property ssn (id = 2)

N to M multiple transformation rules

Not available -

As can be concluded from this table, three cases are selected. These cases are described in the next sections:

4.4.1 One-to-one mapping with one transformation rule, where the <<primitive type>> String is changed.

4.4.2 Many-to-one mapping with one transformation rule, where the attribute organizationName in general class Employed is changed.

4.4.3 Many-to-many mapping with one transformation rule, where the attribute ssn in general class Person is changed.

The activities in the change management process, which need to be executed in these sections are:

1. Introduce a change to a source model element 2. Run the impact analysis by running the intermediary model with the change at

hand in the Java program 3. Determine the un-impacted intermediary model 4. Create the changed intermediary model 5. Merge the un-impacted and changed intermediary model

Because we are still not able to perform a partial re-execution and merging of models, we suffice with a complete recreation of the intermediary model (activities 4 and 5)

4.4.1 One-to-one mapping with a single transformation rule In this flattening transformation only the element primitive type String, is transformed to exactly one element in the target model without any more source elements used. We now introduce a change to this source model element. Running the impact analysis on the intermediary model and the change to source model element primitive type String, creates the analysis in Listing 17, which shows the impact analysis and (re-)execution schema for this change. The re-execution is needed when the element is updated. In this case, the name is changed to CharArray (for some nostalgic reasons). The rule copyprimitive can be reused to create a new target element, which is added to the set of un-impacted target elements. The trace used for this impact analysis is then replaced by a new trace, holding the trace information from the re-execution. The resulting model is shown in Figure 55. The deletion of primitive type String is not allowed in this case. The typing of almost all properties in the model is based on the primitive type String. If this source model element is deleted all these typing issues need to be resolved and can therefore not be solved by the current trace set. The transformation of the source model with the deletion implemented crashes due to this.

97

Simpleuml_To_FlatenSimpleuml: impacted target elements: String id = 1, rule used = copyprimitive un-impacted target elements: Address id = 1, rule used = leafClass2Class Professor id = 1, rule used = leafClass2Class Course id = 1, rule used = leafClass2Class street id = 1, rule used = property2property Car id = 1, rule used = leafClass2Class firstName id = 1, rule used = property2property lastName id = 1, rule used = property2property FullName id = 1, rule used = leafClass2Class residesAt id = 2, rule used = copyAssociation supervisor id = 1, rule used = copyAssociation carOwnership id = 1, rule used = copyAssociation attends id = 1, rule used = copyAssociation name id = 1, rule used = property2property school id = 1, rule used = property2property city id = 1, rule used = property2property ssn id = 2, rule used = property2property PhDStudent id = 1, rule used = leafClass2Class residesAt id = 1, rule used = copyAssociation ssn id = 1, rule used = property2property organizationName id = 1, rule used = property2property preserve the following sources: String created by the following executions: copyprimitive(String) = String id = 1 Re-execution schema for update: copyprimitive(CharArray) = CharArray id = 1

Listing 17 Impact analysis and re-execution schedule for <<primitive type>> String

98

Figure 55 String changed to CharArray - updated intermediary model

4.4.2 Many-to-one mapping with a single transformation rule The property organizationName and the class Professor are mapped to the property organizationName (id = 0) in the target model. We now introduce a change to the source model element, property organizationName. The impact analysis shown in Listing 18 is the result from the intermediary model and the propagated change on the source model. We see now that the property organizationName is mapped with two traces to the target model, which show what source elements are used to create the target element Property organizationName (id = 1). The source elements used are the property organizationName and the class Professor that inherits the property of the general class Employed.

99

Simpleuml_To_FlatenSimpleuml: impacted target elements: organizationName id = 1, rule used = property2property un-impacted target elements: Address id = 1, rule used = leafClass2Class Professor id = 1, rule used = leafClass2Class Course id = 1, rule used = leafClass2Class street id = 1, rule used = property2property Car id = 1, rule used = leafClass2Class String id = 1, rule used = copyprimitive firstName id = 1, rule used = property2property lastName id = 1, rule used = property2property FullName id = 1, rule used = leafClass2Class residesAt id = 2, rule used = copyAssociation supervisor id = 1, rule used = copyAssociation carOwnership id = 1, rule used = copyAssociation attends id = 1, rule used = copyAssociation name id = 1, rule used = property2property school id = 1, rule used = property2property city id = 1, rule used = property2property ssn id = 2, rule used = property2property PhDStudent id = 1, rule used = leafClass2Class residesAt id = 1, rule used = copyAssociation ssn id = 1, rule used = property2property preserve the following sources: organizationName Professor created by the following executions: property2property(organizationName) = organizationName id = 1 property2property(Professor) = organizationName id = 1 Re-execution schema for update: property2property(companyName) = companyName id = 1 property2property(Professor) = companyName id = 1

Listing 18 Impact analysis and re-execution schema for change to organizationName

The update of the property organizationName consists of changing the name attribute of the property. In this case, the name is changed to companyName. In the re-execution, the newly created property can be added to the un-impacted target model and the updated intermediary model is created. The traces used for this analysis need to be removed from the trace model and the newly created traces by the re-execution need to be added to the target model. The intermediary model resulting from this is shown in Figure 56. We see that the merge of the new property companyName with the list of un-impacted elements in Listing 18 creates this model.

100

Figure 56 organizationName changed to companyName - updated intermediary model

A deletion of the property organizationName, needs to be followed through to the Class Professor (id = 1) in the target model. Deleting the property from the source model, infers the deletion of the property in the target element, class Professor (id = 1). In addition, both traces used for the impact analysis need to be removed from the trace model, to keep the trace set consistent with the changed source and target model. This change implementation results in the intermediary model shown in Figure 57. We see that the changed intermediary model consist of the un-impacted elements in the impact analysis. The traces mapping the property organizationName to the target model are deleted from the traces.

101

Figure 57 organizationName deleted - updated intermediary model

4.4.3 Many-to-many mapping with a single transformation rule The Property ssn, from the general Class Person, is mapped twice in the transformation. The first is to an element Property ssn (id = 1) in the Class PhDStudent (id = 1) and to an element Property ssn (id = 2) in the Class Professor (id = 1). We now introduce a change to source model element property ssn. The change impact analysis resulting from the intermediary model and the change to the source model element is shown in Listing 19.

102

Simpleuml_To_FlatenSimpleuml: impacted target elements: ssn id = 2, rule used = property2property ssn id = 1, rule used = property2property un-impacted target elements: Address id = 1, rule used = leafClass2Class Professor id = 1, rule used = leafClass2Class Course id = 1, rule used = leafClass2Class street id = 1, rule used = property2property Car id = 1, rule used = leafClass2Class String id = 1, rule used = copyprimitive firstName id = 1, rule used = property2property lastName id = 1, rule used = property2property FullName id = 1, rule used = leafClass2Class residesAt id = 2, rule used = copyAssociation supervisor id = 1, rule used = copyAssociation carOwnership id = 1, rule used = copyAssociation attends id = 1, rule used = copyAssociation name id = 1, rule used = property2property school id = 1, rule used = property2property city id = 1, rule used = property2property PhDStudent id = 1, rule used = leafClass2Class residesAt id = 1, rule used = copyAssociation organizationName id = 1, rule used = property2property preserve the following sources: Professor ssn PhDStudent created by the following executions: property2property(ssn) = ssn id = 2 property2property(Professor) = ssn id = 2 property2property(ssn) = ssn id = 1 property2property(PhDStudent) = ssn id = 1 Re-execution schema for update: property2property(uniqueID) = uniqueID id = 2 property2property(Professor) = uniqueID id = 2 property2property(uniqueID) = uniqueID id = 1 property2property(PhDStudent) = uniqueID id = 1

Listing 19 Impact analysis and re-execution schema for change to property ssn

The update of the source model element property ssn, must be followed through in the two leaf classes in the target model, class PhDStudent (id = 1) and class Professor (id = 1), which both inherit the property through the flattening of the generalization. After the addition of the newly created target elements, by the re-executions of the property2property rule, these can be added to the set of un-impacted target elements, creating the updated target model. The traces used for the impact analysis need to be removed and replaced by the traces registering the mappings of the newly created elements. The resulting intermediary model after the update is shown in Figure 58.

103

Figure 58 ssn changed to uniqueID - updated intermediary model

The deletion of the element property ssn, implies the deletion of the element in both the target model elements, class PhDStudent (id = 1) and class Professor (id = 1). These can be removed along with the traces used for to map the property ssn to the target model. The relevant updated intermediary model is shown in Figure 59, which is the set of un-impacted model elements and the traces without the traces mapping property ssn to the target model.

104

Figure 59 deleted ssn - updated intermediary model

4.5 Evaluation In this section, the main results from the case study are presented, showing the pros and cons of the chosen change management process and its current implementation.

4.5.1 Number of traces Since we are trying to discover what to trace and to what extent this is done, we start the evaluation with the traces we expected to be created. Because of the flattening, some source model elements are not mapped to any target model elements. These however are included in the list. The expected mappings can be found in Table 10. This table contains 23 complete traces, namely all the triples containing source and target model elements and a transformation rule. From the traces created by Borland Together and the traces from the custom tracing, we however see that there are more traces created, namely 39 traces.

105

Table 10 Expected mappings between source and target model elements

Source element Target element Transformation rule

Classes Course Course leafClass2Class EnrolledInSchool Student PhDStudent PhDStudent leafClass2Class Professor Professor leafClass2Class Car Car leafClass2Class Employee Person Adress Adress leafClass2Class Employed FullName FullName leafClass2Class

Primitive types String String copyprimitive

Associations Attends Attends copyAssociation resides at resides at copyAssociation resides at resides at copyAssociation supervisor supervisor copyAssociation car ownership car ownership copyAssociation

Properties Course.name Course.name property2popertyEnrolledInSchool.school PhDStudent.school property2popertyAdress.street Adress.street property2popertyAdress.city Adress.city property2popertyPerson.name PhDStudent.name property2popertyPerson.ssn PhDStudent.ssn property2popertyPerson.ssn Professor.ssn property2popertyEmployed.orginizationName Professor.orginizationName property2popertyProfessor.name Professor.name property2popertyFullName.firstName FullName.firstName property2popertyFullName.lastName FullName.lastName property2poperty If the mapping methods used, besides the main in the transformation specification, are looked upon closer, we see that the following methods are used:

simpleuml::Class::leafClass2Class(in model:simpleuml::Model) : simpleuml::Class

simpleuml::Association::copyAssociation( in sourceClass :simpleuml::Class ) : simpleuml::Association

simpleuml::Property::property2property( in ownerClass:simpleuml::Class ) : simpleuml::Property

simpleuml::PrimitiveType::copyprimitive() : simpleuml::PrimitiveType

We see here that most of the mapping methods take several inputs from the source model to create the desired target. In the leafClass2Class method the model:simpleuml::Model input is not used to create the target element, this is only used to check whether the self-instance of the class (simpleuml::Class) is a general or leaf class. The other mapping methods use both the self-instance and the input parameter to create the desired target model mapping. This implies that traces are created for both the inputs used that are used.

106

The simpleuml::Property::property2property, for instance, takes a simpleuml::Class as an input. If we look at the source model, we see that the class Professor has a property name of type FullName. After the transformation, two traces are created:

Professor::Class to Professor.name::Property Professor.name::Property to Professor.name::Property

The first trace shows the ownership of the property. The second is the mapping from the source property to target the target property.

4.5.2 Custom tracing The custom trace model is used to get a better insight into the extent of the tracing; what needs to be traced from the source to the target and with which rule this is done. Because the focus is on this custom model, the impact analysis is made on the basis of the traces created by the custom tracing. The traces however created by Borland, in this case study, also log the same traces as by the custom tracing. The tracing by Borland Together also creates traces, which are irrelevant to the transformation at hand. These are mostly the traces logging mappings to target model elements, which are created by the main mapping method. In the Operational Mappings implementation, these traces do not add extra information or insight for a change analysis and change implementation. The intermediary model resulting from the transformation together with a change to the source model is fed to the Java program for the impact analysis. Because the custom trace model creates the entire trace set, the analysis can be performed as specified in the process.

4.5.3 Updating a source model element In this case, as in the cases discussed in earlier chapters, the changes that can be made to the source model are very limited. Changing a name of an element or element’s properties are the limit to what can be done. An insight into this limitation can be simulated by the modelling practice itself:

When creating a UML model, in an environment checking the meta-model restrictions on the modelling practice, the modeller selects which element is added to the model. This addition is limited, based on the meta-model, e.g. in UML a class cannot be added to a class or a property cannot be added to a package.

When updating an already existing model, the change must be made or planned using the same meta-model restrictions, thus implying that update changes are limited to this. The actual update that is implemented, under these limitations, now is very simple. The structure of the model stays the same, before and after the change, and just the information used in the source and target model is changed, thus preserving the target model with the changed source model.

107

4.5.4 Deleting a source model element With the same logic of the update to a source element, the deletion of source elements is also bound to the meta-model restrictions (cf. Sections 3.7 and 3.8). However, the deletion of elements can disturb the structure of the model. Deleting generalizations from the model is allowed by the meta-model. This however has a major impact on the target model for which the change cannot be handled by the current tracing and impact analysis. If we for instance remove an arbitrary generalization from the source model, this implies that the flattening of this class to all subordinates needs to made undone, to keep the target model compliant with the source model. This problem cannot be handled by the tracing implemented in this project, because for the properties from the general classes no ownership is logged by the traces. To solve this problem, the meta-model restrictions need to be taken into account. Another example of this problem is the changing of the primitive types of the model. Most of the properties in the case study models are linked to the primitive type String. The change to the primitive type then needs to be followed through in the entire source model changing all property types to the new primitive type (Borland Together does the update automatically, because a reference is made to the typing class). The target model also needs to be changed accordingly but no traces are made, which map the primitive type String to the typing of the properties. The problem above shows that also an intra-level trace set needs to be available to make the incremental implementation possible.

4.5.5 Unmapped source model elements The flattening of simpleUML models infers that some source model elements are not mapped to the target model thus is not contained in any trace from the source to target models. These unmapped source model elements in this case study are the general classes in the simpleUML model. Updating the general class, e.g. renaming the class, will not have any implications on the target model, since the class itself is not traced to any target model element.

4.5.6 Resolving mappings Within Borland Together, the writing of transformations is made possible via the implementation of the Operational Mappings language. This implementation uses the resolve methods, which make the assignment of already created elements and the assignment of model target model elements, which are created in the future, possible. These assignments by resolving model elements are made in the body of a mapping method and can therefore not be traced by the custom trace model. Creating traces for these mappings can make the change analysis and – propagation less prone for problems. When using these resolve-methods one assumes that the selection of the element is correct. Currently an implementation of a change is made based on the trace information available without these mappings. The assumption that the resolving of elements is not impacted by the change is made. Removing this assumption and making a hard link, e.g. trace, of the resolved element removes this uncertainty.

4.6 Summary In this chapter, we have made a case study, which shows the applicability of the custom trace model and impact analysis based on the intermediary model on a larger scale. From the traces created during the execution of the transformation, which

108

creates the intermediary model, the scenarios with the one-to-one, many-to-one and many-to-many mappings are shown. In these different mapping scenarios, a single transformation rule is used. The number of elements used as input for the transformation rule and created by the transformation rule however varies. The changes that can be solved on the basis of inter-level dependencies remain the same, changing model element data, while preserving the model structure. The emerged observations and limitations are:

- The traces created do not only log the mappings from source to target, but can also contain some hierarchical information. In this case study this is the ownership of properties by classes.

- The custom trace model creates the intermediary model containing the source, target and trace models. This centralized manner gives a total overview of the transformation, containing the entire source and target models and a list of traces, which show how these are mapped to one another.

- Deleting elements from and to the source model need further information, mainly the limitations from the meta-model need to be added. These limitations show which changes are possible, which then structures an approach or ordering how the changes should be implemented.

- Updating source model elements that are not mapped to any target model element do not affect the target model.

- Assigning by resolving target model elements infers the assumption that this is not impacted by a change.

109

5 Conclusions

5.1 Introduction The problem investigated in this thesis is to study the possibility of a change management approach for the MDA, where the impact analysis and change implementation by an incremental model compilation are based on tracing transformation from a transformation execution. The research question formulated for this problem is:

With the option of traceability in QVT transformation languages, can a change management framework be based on tracing information that is created during the

execution of a QVT based transformation, within the MDA? In this chapter, this question is answered by first summarizing the previous chapters, after which the sub-research questions are answered. With this information, the main research question is answered and the gap closed is discussed. Finally, the open issues and future work are stated.

5.2 Summary In Chapter 2, we have made a literature study to determine the necessary theoretical context. We started the study with the Model Driven Architecture (MDA), which raises the level of abstraction in software development by defining models and transformations between models, usually based on meta-models. We can distinguish a source and target section in a MDA transformation. A transformation language is used to write a transformation specification. This specification defines a mapping between meta-model elements from the source meta-model to the target meta-model. We have selected the Borland Together platform for this project, which partly implements the MDA framework with a bound set of meta-models and a QVT language supported by an implementation of OCL 2.0. From the specifications of the proposed QVT languages, we have learned that they provide some sort of tracing mechanisms. The Relations language and Operational Mappings language use an implicit trace mechanism and the Core language uses an explicit trace mechanism. This explicit tracing is represented graphically in a table, showing a mapping from source-to-target meta-model elements. In the study into traceability, we have seen that this is widely used in requirements engineering. In this field, a requirement may be followed from the source (or rationale) of the requirement to the modules designing, implementing and testing the requirement. A proposed meta-model can be instantiated to support the different purposes of requirements tracing within the different stadia of the engineering cycle. The classification of traceability for transformation languages shows us which possible features are expected and which are mandatory for traceability in model transformation tooling. The following changes types to elements of a system are distinguished in literature:

- Addition, adding a new element - Subtraction, deleting an existing element - Replacement, updating an existing element

110

From the literature on traceability in models, we have learned that a change affects not only the (to-be) changed element in the source, but also the related model elements in the target. In addition, some source model elements and target model elements, which are not directly impacted, need to be preserved that keeps the system consistent after the change is implemented. Several types of relations between elements are distinguished, from studies into multi-level processes. The inter-level trace dependencies are defined between artefacts residing in two different levels of the engineering cycle. The intra-level trace dependencies are defined between artefacts, which reside on the same level of abstraction. A live transformation is proposed to implement changes to source model elements incrementally, using the transformation information to recreate target model elements. Before any change implementation can be performed an impact analysis needs to be made, determining the affect the change has in the system. This results in the set of system elements, which should be changed or preserved to implement a change. In Chapter 3, we propose a trace model in the MDA, which consists of logging the execution of the transformation specification. A single trace now is structured into a source model element, a target model element and the transformation rule used. The set of all traces represent the mappings made by the transformation. The traces can be created automatically by some tool, which does not give insight into the creation of the traces and a meta-model for the traces. We have made an implementation of the trace model into the transformation specification, which does gives this insight. We call this implementation the custom trace model. We use this custom trace model to give further insight into the creation of traces. We have implemented the custom trace model on the Borland Together platform and have introduced an intermediary model, which contains the source model, target model and traces. This approach however infers us to use the same meta-model for both source and target. We have determined that an impact analysis, based on the transformation context, is sufficient for changing attributes (i.e. the identifier) of model elements. An impact analysis for deleting and adding elements to the source model needs more information, due to meta-model restrictions. By viewing models as sets of elements, we have studied that incremental model compilation can be used to implement changes. In this method, a compilation of the un-impacted target model elements and the changed target model elements can be made. The changed target model elements are created by a retransformation of the impacted source model elements, where the re-execution is planned based on the traceability-based impact analysis. We have written a Java program, which is used to perform this impact analysis. The incremental compilation or other change implementation, ideally is done on the implementation platform, which allows the changes to be re-executed by a selection from (a subset of) the transformation rules. This implementation falls outside the scope of this project. The transformations we have implemented show the various mappings possible between source model elements and target model elements, which are both discussed theoretically and practically. The change types that we have handled in these samples are limited to those which can be supported by tracing, e.g. inter-level trace dependencies. Adding source model elements, deleting source model elements and

111

transformation rules’ guards need to also be supported by some meta-model restrictions. In Chapter 4, we have made a case study, which shows the applicability of the custom trace model and impact analysis based on the intermediary model on a larger scale. From the traces created during the execution of the transformation, which creates the intermediary model, the scenarios with the one-to-one, many-to-one and many-to-many mappings are shown. In these different mapping scenarios, a single transformation rule is used. The number of elements used as input for the transformation rule and created by the transformation rule however varies. The changes that can be solved on the basis of inter-level dependencies remain the same, changing model element data, while preserving the model structure. The emerged observations and limitations are:

The traces created do not only log the mappings from source to target, but can also contain some hierarchical information. In this case study this is the ownership of properties by classes.

The custom trace model creates the intermediary model containing the source, target and trace models. This centralized manner gives a total overview of the transformation, containing the entire source and target models and a list of traces, which show how these are mapped to one another.

Deleting elements from and to the source model need further information, mainly the limitations from the meta-model need to be added. These limitations show which changes are possible, which then structures an approach or ordering how the changes should be implemented.

Updating source model elements that are not mapped to any target model element do not affect the target model.

Assigning by resolving target model elements infers the assumption that this is not impacted by a change.

5.3 Conclusions

How is tracing defined within the MDA and how is this specified within the proposed QVT languages?

Can a tracing meta-model be derived for model transformations, which are written in a QVT language, so that it can be used to structure tracing needed for change management?

To what extent is the MDA with tracing implemented in Borland Together? Which change scenarios can be identified and solved with respect to

traceability-based change management in the MDA? How can the target model be compiled incrementally based on a traceability-

based impact analysis, when a change to the source model propagates? Before the main research question is answered, the sub-questions that guided the approach for this thesis are answered and summarize the achievements and limitations from the work done: - On what level is tracing defined within the MDA, and on what level is this

specified within the proposed QVT languages? Tracing is not defined in the MDA as such, but the definitions of traceability from other domains are adapted to cover tracing in the MDA. The tracing in the QVT

112

languages is stated very vaguely in the specifications. The specifications only mention that the mappings between source and target elements are traced, but not how this is done. The Core language gives the most insight into tracing, using a tabular notation for every transformation rule, stating under which conditions a meta-model element from the source is mapped to a meta-model element in the target. Placing traceability in the MDA framework can be done on every level within the framework:

The traceability meta-model that structures the trace model, for specialization per transformation case.

Trace model, using source meta-model elements and target meta-model elements and the transformation rules mapping the first to the latter.

The actual tracing information created during the transformation execution. - Can a tracing meta-model be derived for model transformations, which are

written in a QVT language, so that it can be used to structure tracing needed for change management?

The focus of this project is limited to how tracing can support change management. A trace meta-model, as described above, is derived from the automated and custom tracing and implemented within the transformation specification. This custom trace model can only be used in the simpleUML-to-simpleUML cases, but for the proof-of-concept, work done in this thesis it is sufficient. The traces are structured into a source model element, which is mapped to, a target model element and a transformation rule, which creates the mapping. The entire set of the traces forms the actual tracing information. - To what extent is the MDA with tracing implemented in Borland Together? In this project, the Operational Mappings implementation in Borland Together is chosen as the implementation platform. Some other tools with other QVT implementations are available, but are not discussed in detail in this project. The modelling of meta-models is not available on this platform, which forces to make certain design choices on our change management framework. Again, it is sufficient for the work in this thesis, but not for the long run. The Operational Mappings implementation is not complete, which only make the transformations in this project more verbose. - Which change scenarios can be identified and solved with respect to traceability-

based change management in the MDA? The traces created are inter-level trace dependencies, so only logging relations between source and target model elements. For the update and delete change cases in this project it was sufficient to only log these traces. The delete changes however can only be made based on the meta-model restrictions; deleting source model elements therefore are bound to some ordering. A Java program uses the intermediary model, which is the result of a transformation using the custom trace model, to create the desired impact analysis, consisting of:

The impacted target model elements The source elements that need are used to create those elements. An execution and re-execution schema, to propagate the desired change.

This program only handles the models discussed in this thesis and is therefore not usable outside of this project.

113

- What scenarios can be identified, with respect to change management in the MDA?

Change types researched, are update and delete types and this is only done in the scope of the source model. The introduction of new elements to the source model must comply with the chosen meta-model. Adding this information in addition to the currently kept traces needs to be researched further. - How can the target model be compiled incrementally based on a traceability-

based impact analysis, when a change to the source model propagates? A process of selecting the un-impacted target model elements and merging them with the newly created target model elements is proposed. This merge of model elements reuses some un-impacted sub-model of the original intermediary model and therefore is an incremental model compilation. For a complete change management framework (covering all possible change types), the intra-level trace dependencies need to be known. A change is bound to the chosen meta-model. The main research question can now be answered with the gathered information:

With the option of traceability in QVT transformation languages, can a change

management framework be based on tracing information that is created during the execution of a QVT based transformation, within the MDA?

Change management, covering the impact analysis and incremental change implementation, within a MDA transformation written in the Operational Mappings language, can be based on traces, which log the mappings created from a source model to a target model. The change, however, is bound to the chosen meta-model and cannot change the source models’ structure so it does not comply any more to the meta-model. Therefore, a complete framework also needs the meta-model restrictions, which include the guard information per transformation rule, added to the currently kept set of traces, to cope with source model changes.

5.4 Future work As can be concluded from the previous sections, some open issues remain: - In the context of the change management framework, as proposed from this

project, the possibilities of intra-level tracing in combination with inter-level tracing need to be researched. This should be done with an analysis of transformation rules and how meta-model limitations, on the selection of source model elements, are followed through after a change to the source model propagates.

- This project is only focusing on the meta-model for tracing and the application of this on the instance level. If the transformation specification is a basis for the generation of all traces this already contains all possible mappings between the source meta-model and target meta-model. This knowledge needs to be researched in combination with the inter-level tracing done in this project.

- When the change management framework is completed with the intra-level tracing, the change scenarios of adding new elements to the source model need to be studied.

114

- As it is concluded from the transformations written in this project, all transformation specifications implemented can only transform a very small set of meta-model instances. This is a problem, when considering that the MDA strives to write transformations, based on meta modelling. The transformations of instances of the meta-models (ideally) should not be limited by the transformation specification. From the transformations written in this thesis a different process or way of thinking is needed to make the transformation specifications less selective.

115

References

[1] Aizenbud-Reshef, N., Nolan, B. T., Rubin, J., Shaham-Gafni, Y. (2006). Model Traceability. IBM Systems journal, vol. 45, no. 3, pp. 515-526.

[2] Aizenbud-Reshef, N., Paige, R.F., Rubin, J., Shaham-Gafni, Y. and Kolovos, D.S. (2005). Operational Semantics for Traceability. In ECMDA-Traceability Workshop, Nuremberg, 7-14

[3] Ajila, S. (1995). Software maintenance: An approach to impact analysis of object change. Software - Practice and Experience, 25(10), 1155-1181.

[4] Bakker, J. (2005). Traceability of concerns. Computer Science Masters thesis, University of Twente (April 2005)

[5] Berg, K. v.d. (2006). Change impact analysis of crosscutting in software architectural design. In workshop on architecture-centric evolution (ACE-2006)

[6] Borland (2006). Borland Together TM Technologies, UML TM modeling for designing software architectures. http://www.borland.com/together last visisted 04-10-2006

[7] Boudé, L., Boulet, P. and Dekeyser, J. L. (2005). Traceability and Inter-operatibility at different levels of abstraction in Model Transformations. In forum on specification and design languages, FDL ’05 (Lausanne Switzerland September 2005)

[8] Cleland-Huang, J., Chang, C. K. and Christensen, M. (2003). Event based traceability for managing evolutionary change. IEEE Transactions on Software Engineering, 29, 9 (September 2003), pp. 796-810

[9] Czarnecki, H (1998). Generative Programming: Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models, Chapter 5: Feature modeling. Ph.D. thesis, Technische Universität Ilmenau, Germany, 1998

[10] Czarnecki, H and Helsen, S (2003). Classification of model transformation approaches. In workshop on generative techniques in the context of model driven architecture (OOPSLA ’03), USA

[11] Dalton, J., Norman, P.W., Whittle, S. and Rajabally, T.E. (2003). Using an MDA approach to model traceability within a modelling framework. In Metamodelling for MDA, (Kings Manor, York, England, 2003), 62-76.

[12] Gotel, O. C. Z. and Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. IEEE international conference on requirements engineering, Los Alamitos, California: IEEE computer society press, (April 1994), pp. 94-101

[13] Hearnden, D., Lawley, M. and Kerry, R. (2006). Incremental Model Transformation for the Evolution of Model-Driven Systems. In proceedings MoDELS 2006 conference, LCNS 4199, pp.321-335.

[14] IEEE (1990). IEEE standard computer dictionary: A compilation of IEEE standard computer glossaries. Institute of electrical and electronics engineers, New York

[15] Kleppe, A., Warmer, J. B. and Bast, W. (2003). MDA explained: the model driven architecture: practice and promise. Addison Wesley

116

[16] Knethen, A. and Paech, B. (2002). A survey on tracing approaches in practice and research. Fraunhofer IESE

[17] Kurtev, I. (2005). Adaptability of model transformations. PhD thesis, University of Twente, the Netherlands

[18] MDWorkbench (2006). http://www.mdworkbench.com [19] ModelMorf (2006). A model transformer.

http://www.tcs0trddc.com/modelmorf/index.htm [20] Nguyen, H.Q. (2006). Analysis of crosscutting concerns in QVT-based

model transformations. Computer Science Masters thesis, University of Twente (July 2006)

[21] Objecteering (2006). http://www.objecteering.com [22] OMG (2003). MDA guide, version 1.0.1 [23] OMG (2005). Revised Submission for MOF 2.0

Query/Views/Transformations RFP, QVT-Merge Group, version 2.0, OMG document ad/2005-03-02

[24] OMG (2005). UML superstructure, version 2.0 [25] OMG (2006). MOF core specification, version 2.0 [26] Pinheiro, F. A. C. (2003). Requirements Traceability. Chapter 5 of the book

Perspectives On Software Requirements, Kluwer Academic Publishers [27] Ramesh, B. and Jarke, M. (2001). Toward a Reference Model for

Requirements Traceability. IEEE Transactions on Software Engineering, 27, 1 (January 2001), pp. 58-93

[28] Rensink, A. and Nederpel, R. (2006). Graph transformation semantics for a QVT language. In proceedings International Workshop on Graph Transformation and Visual Modeling Techniques, Electronic Notes in Theoretical Computer Science, 2006 (to appear)

[29] Rensink, A., Kastenberg, H. and Staijen, T. (2006). User manual for the Groove tool set, department of computer science, University of Twente, March 2006

[30] SWEBOK (2004). Software maintenance, Chapter 6 of Software Engineering Body of Knowledge, IEEE Version 1.00 May 2004

[31] Walderhaug, S., Johansen, U., Stav, E. and Aagedal, J. (2006). Towards a generic solution for traceability in MDD. In proceedings ECMDA traceability workshop, SINTEF ICT, Norway (July 2006)

117

A Operational Mappings implementation in Borland Together

The Borland Together platform6 partly implements the Operational Mappings language, supported with a complete OCL 2.0 implementation. The operational language is used to write the desired transformation, mapping source meta-model elements to target meta-model elements. The OCL is used to write logical constraints and selectors on the source and target meta-model elements. In this section the structure of a transformation-specification written in Borland Together is explained.

A.1 Main structure A transformation-specification contains the following mandatory elements:

A transformation-declaration Imports of the meta-models A main mapping-method

Besides these mandatory sections, transformations can contain the following elements:

Imports of QVT-libraries Mapping methods Queries

In the following sub-sections these elements are introduced.

A.2 Transformation declaration When programming Java classes, these need to be declared at some point. In addition, transformations are declared, namely with a transformation declaration. This is a one lined argument, where the name of the transformation is stated, an example: transformation testTrasformation;

A.3 Imports A re-use of transformation methods and queries an import of libraries is possible. This is done with the import-keyword, followed by the QVT-library’s identifier. Mandatory meta-model imports are needed to write the transformation. Both the source and target meta-models are needed, but if this is the same for both, one meta-model import is sufficient. The imports of the meta-model(s) are made with the help of the metamodel-keyword. Examples of a QVT-library import and a meta-model import are shown in the following example: import testLibrary; metamodel 'http:///SimpleUML.ecore';

6 Borlang Together Architect version 2006 R2 for windows

118

A.4 Mapping methods A mapping method contains the mapping of source-model element’s data to a desired target-model element. Such a method therefore creates a new target element, which then is put into the created target model. The data that can be used varies from all the attributes which together form the model element. A mapping takes one or multiple source elements and creates one desired target element and at most one element. In the example declaration of a main mapping-method is shown: mapping main(in sourceElement: simpleuml::Model): simpleuml::Model { … } This main mapping method takes one source element, namely the source model (simpleuml::Model), and creates one target element, the target model (simpleuml::Model). Multiple inputs can be used, separated by a comma. OCL collection types can also be used as an input. The body of a mapping on itself can contain three sections, where the first two are optional and not mandatory:

- When - Init - Object

The when-section is an OCL-expression, which evaluates to a boolean-value. The execution of the init- and object- sections are only run when the expression results in the boolean-value true. The following example checks if the source model-element is defined or not: when { not sourceElement.oclIsUndefined() } The init-section contains declarations of variables which can be used locally in the mapping. The values assigned to these variables are useful, to make the mapping more readable or if some re-use of data is needed. The var keyword is used to declare variables. The typing of the variable can either be added to the declaration, or resolved automatically by the assigning of some value where the type of that value is used. The following example shows a declaration of a variable newName with of type String: init { var newName:String := sourceElement.name + ' nice new name!'; }

The object-section is the mandatory section of the mapping method. When no init-section is added to the mapping, the object keyword and body brackets aren’t necessary. This section creates a target element of the resulting type. Here mappings can be declared from source to target model elements. In this example the target-element’s attribute name is mapped to the attribute name of the source element, with a new addition. Since the selection of data is done using OCL, the types of the LHS and RHS must be equal, or need to be cast correctly:

119

object { name := sourceElement.name + ' nice new name!'; }

A.5 Queries The transformation can also contain helper methods; queries. These queries can contain large OCL-statements, which can help the readability of the specification. This example for instance returns a collection of all the names contained in the root source-element. When this needs to be done multiple times, recursively for instance, using this query makes the mapping method more readable and less verbose: query getNames(in sourceElement:simpleuml::Model): OrderedSet(String) { sourceElement.ownedElements -> collect(oclAsType(simpleuml::ModelElement).name) -> asOrderedSet(); }

121

B SimpleUML meta-model

The transformations in this thesis, which use tracing, all use the simpleUML meta-model, from the Borland Together platform, as the source and target meta-model. This meta-model is shown in Figure 60.

Figure 60 SimpleUML meta-model (simpleuml.ecore)

123

C SimpleUML to simpleUML transformation

The simpleUML to simpleUML transformation copies every element from the source model to the target model. This transformation implements the following scheme:

- Rename model with ‘output_’ prefix - Collect Packages

o Rename packages with ‘output_’ prefix o Get packaged elements, per package o Reset stereotype with information used in mapping

- Collect Associations o Rename associations with ‘output_’ prefix o From source class resolve new source class o From target class resolve new target class o Reset stereotype with information used in mapping

- Collect Classes o Rename classes o Reset stereotype with information used in mapping

transformation sUML2sUML; metamodel 'http:///SimpleUML.ecore'; /** * mappings **/ mapping main(in model: simpleuml::Model): simpleuml::Model { init { var newName := 'ouput_' + model.name; } object { --create other name name := newName; --copy the elements ownedElements := handlePacks(model); --create tracing information stereotype := 'main('.concat(model.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } mapping pack2pack(in pack:simpleuml::Package) : simpleuml::Package when { pack.oclIsKindOf(simpleuml::Package)} { init { var newName := 'ouput_' + pack.name; } object { --create new name name := newName; --copy classes --ownedElements := handleClasses(pack); --ownedElements := handleAss(pack); ownedElements := collectElems(pack); --create tracing information stereotype := 'pack2pack('.concat(pack.name).concat(')').concat('->').concat(newName)->asOrderedSet();

124

} } mapping cls2cls(in cls:simpleuml::Class) : simpleuml::Class when { cls.oclIsKindOf(simpleuml::Class) } { init { var newName := 'output_' + cls.name; } object { --create new name name := newName; --create tracing information stereotype := 'cls2cls('.concat(cls.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } mapping asn2asn(in asn:simpleuml::Association) : simpleuml::Association when { asn.oclIsKindOf(simpleuml::Association) } { init { var newName := 'ouput_' + asn.name; } object { --create new name name := newName; --make sure new source and target are okay /*source := asn.source;*/ source := asn.source.resolve(simpleuml::Class)->any(true); --source := asn.source.lateResolve(simpleuml::Class); /*target := asn.target;*/ target := asn.target.resolve(simpleuml::Class)->any(true); --target := asn.target.lateResolve(simpleuml::Class); --create tracing information stereotype := 'asn2asn('.concat(asn.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } /** * queries **/ query handlePacks(in packs:simpleuml::Model) : OrderedSet(simpleuml::Package) { --handle the first package and all subsequent ones packs.ownedElements->collect(pack2pack(oclAsType(simpleuml::Package)))->asOrderedSet(); } query collectElems(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --collect the classes and associations --handleCls(pack)->union(handleAsn(pack))->asOrderedSet(); --collect the associations and classes handleAsn(pack)->union(handleCls(pack))->asOrderedSet(); } query handleCls(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --handle all the classes pack.ownedElements->collect(cls2cls(oclAsType(simpleuml::Class)))->asOrderedSet(); } query handleAsn(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) {

125

--handle all the associations pack.ownedElements->collect(asn2asn(oclAsType(simpleuml::Association)))->asOrderedSet(); }

Listing 20 Operational transformation simpleUML to simpleUML renaming

127

D SimpleUML to simpleUML transformation with tracing and queries

The simpleUML to simpleUML transformation copies every element from the source model to the target model. This transformation implements the following scheme:

- Rename model with ‘output_’ prefix - Collect Packages

o Rename packages with ‘output_’ prefix o Get packaged elements, per package o Reset stereotype with information used in mapping

- Collect Associations o Rename associations with ‘output_’ prefix o From source class resolve new source class o From target class resolve new target class o Reset stereotype with information used in mapping

- Collect Classes o Rename classes o Reset stereotype with information used in mapping

- Create traces transformation specs.sUML2sUML; metamodel 'http:///SimpleUML.ecore'; /** * mappings **/ mapping main(in model: simpleuml::Model): simpleuml::Model { init { --var newName := 'ouput_' + model.name; var newName := 'input+output+tracing'; var old : OrderedSet(simpleuml::Packageable):= model.ownedElements; var new : OrderedSet(simpleuml::Packageable) := handlePacks(model); var traces : OrderedSet(simpleuml::Class) := handleTracing(model); } object { --create other name name := newName; --copy the elements ownedElements := old->union(new)->union(traces)->asOrderedSet(); ownedElements += object simpleuml::Model { name := 'input'; ownedElements := old; }; ownedElements += object simpleuml::Model { name := 'output'; ownedElements := new; }; ownedElements += object simpleuml::Model { name := 'traces'; ownedElements := traces; }; --create tracing information stereotype := 'main('.concat(model.name).concat(')').concat('-

128

>').concat(newName)->asOrderedSet(); } } mapping pack2pack(in pack:simpleuml::Package) : simpleuml::Package when { pack.oclIsKindOf(simpleuml::Package)} { init { var newName := 'ouput_' + pack.name; } object { --map new name name := newName; --copy classes --ownedElements := handleClasses(pack); --ownedElements := handleAss(pack); ownedElements := collectElems(pack)->asOrderedSet(); --create tracing information stereotype := 'pack2pack('.concat(pack.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } mapping cls2cls(in cls:simpleuml::Class) : simpleuml::Class when { cls.oclIsKindOf(simpleuml::Class) } { init { var newName := 'output_' + cls.name; } object { --create new name name := newName; --create tracing information stereotype := 'cls2cls('.concat(cls.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } mapping asn2asn(in asn:simpleuml::Association) : simpleuml::Association when { asn.oclIsKindOf(simpleuml::Association) } { init { var newName := 'ouput_' + asn.name; } object { --create new name name := newName; --make sure new source and target are okay source := asn.source.resolve(simpleuml::Class)->any(true); target := asn.target.resolve(simpleuml::Class)->any(true); --create tracing information stereotype := 'asn2asn('.concat(asn.name).concat(')').concat('->').concat(newName)->asOrderedSet(); } } mapping createTrace(in modElem:simpleuml::ModelElement) : simpleuml::Class { init { -- c.q. var newName := 'output_' + modElem.name; var oldName := modElem.name; var newName := modElem.resolve(simpleuml::ModelElement)->any(true).name; var oldTypeName := modElem.getType(); var newTypeName := modElem.resolve(simpleuml::ModelElement)->any(true).getType(); var content := 'trace_ '. concat(modElem.name). concat(':').

129

concat(oldTypeName). concat(' -> '). concat(newName). concat(':'). concat(newTypeName); var source: simpleuml::Property := object simpleuml::Property { name := oldName.concat(':').concat(oldTypeName); }; var target: simpleuml::Property := object simpleuml::Property { name := newName.concat(':').concat(newTypeName); } } object { --create name name := content; attributes += source; attributes += target; } } /** * queries **/ query handlePacks(in packs:simpleuml::Model) : OrderedSet(simpleuml::Package) { --handle the first package and all subsequent ones packs.ownedElements->collect(pack2pack(oclAsType(simpleuml::Package)))->asOrderedSet(); } query collectElems(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --collect the classes and associations handleCls(pack)->union(handleAsn(pack))->asOrderedSet(); } query handleCls(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --handle all the classes pack.ownedElements->collect(cls2cls(oclAsType(simpleuml::Class)))->asOrderedSet(); } query handleAsn(in pack:simpleuml::Package) : OrderedSet(simpleuml::Packageable) { --handle all the associations pack.ownedElements->collect(asn2asn(oclAsType(simpleuml::Association)))->asOrderedSet(); } query handleTracing(in elem:simpleuml::ModelElement) : OrderedSet(simpleuml::Class) { --create the trace associations elem.allInstances(simpleuml::ModelElement)->collect(createTrace(oclAsType(simpleuml::ModelElement)))->asOrderedSet(); } query simpleuml::ModelElement::getType() : String { if self.oclIsKindOf(simpleuml::Class) then 'Class' else if self.oclIsKindOf(simpleuml::Association) then 'Association' else if self.oclIsKindOf(simpleuml::Package) then 'Package' else 'other' endif endif endif

130

}

Listing 21 SimpleUML to SimpleUML renaming scheme with custom trace model

The following queries result in the relevant information from the intermediary model. The source, target and trace models are retrieved by these queries, respectively. The last query can be used to retrieve the relavent traces from the trace model, using a source model element as a selector. transformation specs.InputQuery; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var outputModel := model.allInstances(simpleuml::Model)-> select(me | me.name = 'input')-> any(true); } object { name := outputModel.name; ownedElements := outputModel.ownedElements; } }

Listing 22 Query to get the source model

transformation specs.OutputQuery; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var outputModel := model.allInstances(simpleuml::Model)-> select(me | me.name = 'output')-> any(true); } object { name := outputModel.name; ownedElements := outputModel.ownedElements; } }

Listing 23 Query to get the target model

transformation specs.TracesQuery; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var outputModel := model.allInstances(simpleuml::Model)-> select(me | me.name = 'traces')-> any(true); } object { name := outputModel.name; ownedElements := outputModel.ownedElements; } }

131

Listing 24 Query to retrieve the traces

transformation specs.ImpactQuery; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { -- we need an element that will be changed -- set of classes = { C1, .., C6 } -- set of associations = { A1, .., A3 } -- set of packages = { P1, .., P3 } -- set of models = { Test } -- now choose a class, namely C4, --> must also check other types var changeElem:simpleuml::Class := model.allInstances(simpleuml::Class)-> select(cls | cls.name = 'C4')->any(true); -- create the string which can be used to search for impacts, c.q. elementName : elementType var changeElemName := changeElem.name->any(true); var changeElemType := changeElem.getType()->any(true); var searchString:String := changeElemName.concat(':').concat(changeElemType); -- get all traces var traces:simpleuml::Model := model.allInstances(simpleuml::Model)-> select(me | me.name = 'traces')-> any(true); -- get all traces var output:simpleuml::Model := model.allInstances(simpleuml::Model)-> select(me | me.name = 'output')-> any(true); -- find the relevent trace classes var impacts := traces.getProps()->select(prop | prop.name = searchString).owner->asOrderedSet(); } object { name := 'impact analyses'; ownedElements += changeElem; ownedElements += impacts; ownedElements += output; } } query simpleuml::ModelElement::getType() : String { if self.oclIsKindOf(simpleuml::Class) then 'Class' else if self.oclIsKindOf(simpleuml::Association) then 'Association' else if self.oclIsKindOf(simpleuml::Package) then 'Package' else 'other' endif endif endif } query simpleuml::Model::getProps():OrderedSet(simpleuml::Property) { self.ownedElements->collect(oclAsType(simpleuml::Class).getProps())->asOrderedSet(); } query simpleuml::Class::getProps():OrderedSet(simpleuml::Property) { self.attributes->collect(oclAsType(simpleuml::Property))->asOrderedSet();

132

}

Listing 25 Query to retrieve the relevant traces

133

E Java ChangeManager

The Java change manager is structured into three packages (Figure 61): 1. traceabilityElements

The necessary classes to support tracing, consisting of source model elements, target model elements and a trace. Both source and target model elements are model element. The trace consist of a source model element, target model element and a string of the transformation rule, which creates the mapping. This is shown in Figure 63.

2. changeManUtils The parsers and writers of the input model and the impact analysis is implemented in this package.

3. example A simple package containing a sample program for the execution of the entire change manager.

The program is run via the example.Program main method. This method provokes the process shown in Figure 62. Here an intermediary model, from a hard coded location, is firstly parsed into a list of source model and target model elements and a list of the traces. These are then used to perform the impact analysis, resulting in the output, summarizing the impacted target elements, the source elements that need to be preserved and a re-execution list which mapping methods need to be re-run.

changeManUtilsClasses

SimpleUMLParserChangeManagerChange

exampleClasses

Program

traceabilityElementsClasses

SourceElementTargetElementModelElementTrace

Figure 61 Overview

134

Figure 62 Java based impact analysis process

Figure 63 traceabilityElements

135

F Sample cases – Transformation specifications

The sample cases all are implemented in the Borland Together platform. Because all cases use the same tracing mechanism and several mappings are re-used over all cases, these are collected and put into an QVT libarary, Listing 26. The implementations are therefore less verbose and are added in the listings below. library sampleCases; metamodel 'http:///SimpleUML.ecore'; /** * Copying mappings and queries **/ mapping copy(in modelElem:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem.resolveByRule('copy',simpleuml::ModelElement)->size(); } object { name := modelElem.name + ' id=' + count; } } mapping copy2(in modelElem:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem.resolveByRule('copy2',simpleuml::ModelElement)->size(); } object { name := modelElem.name + ' id=' + count; } } query copyQ(in model:simpleuml::Model): OrderedSet(simpleuml::Packageable) { model.ownedElements->collect(copy(oclAsType(simpleuml::ModelElement)))->asOrderedSet(); } query copyQ2(in model:simpleuml::Model): OrderedSet(simpleuml::Packageable) { model.ownedElements->collect(copy2(oclAsType(simpleuml::ModelElement)))->asOrderedSet(); } /** * Merging mappings and queries **/ mapping merge(in modelElem1:simpleuml::ModelElement,modelElem2:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem1.resolveByRule('merge',simpleuml::ModelElement)->size(); } object { name := modelElem1.name + ' + ' + modelElem2.name + ' id=' + count; } }

136

mapping merge(in modelElem1:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem1.resolveByRule('merge',simpleuml::ModelElement)->size(); } object { name := modelElem1.name + ' id=' + count; } } query mergeQ(in model:simpleuml::Model): OrderedSet(simpleuml::Packageable) { if model.ownedElements->size() = 2 then merge( model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(1), model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(2) )->asOrderedSet() else merge( model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(1) )->asOrderedSet() endif } mapping merge2(in modelElem1:simpleuml::ModelElement,modelElem2:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem1.resolveByRule('merge2',simpleuml::ModelElement)->size(); } object { name := modelElem1.name + ' + ' + modelElem2.name + ' id=' + count; } } mapping merge2(in modelElem1:simpleuml::ModelElement): simpleuml::Package { init { var count := modelElem1.resolveByRule('merge2',simpleuml::ModelElement)->size(); } object { name := modelElem1.name + ' id=' + count; } } query mergeQ2(in model:simpleuml::Model): OrderedSet(simpleuml::Packageable) { if model.ownedElements->size() = 2 then merge2( model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(1), model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(2) )->asOrderedSet() else merge2( model.ownedElements->collect(oclAsType(simpleuml::ModelElement))->asOrderedSet()->at(1) )->asOrderedSet() endif } /** * Custom tracing

137

**/ query handleTracing(in elem:simpleuml::Model, rule:String) : OrderedSet(simpleuml::Class) { --create the trace associations elem.allInstances(simpleuml::ModelElement)->collect(traceAll(oclAsType(simpleuml::ModelElement),rule))->asOrderedSet(); } query traceAll(in elem:simpleuml::ModelElement, rule:String) : OrderedSet(simpleuml::Class) { elem.resolveByRule(rule,simpleuml::ModelElement)->collect(elem.createSingleTrace(oclAsType(simpleuml::ModelElement),rule))->asOrderedSet(); } mapping simpleuml::ModelElement::createSingleTrace(in targetElem:simpleuml::ModelElement, rule:String) : simpleuml::Class { init { var oldName := self.name; var newElem := targetElem; var newName := newElem.name; var oldTypeName := self.getType(); var newTypeName := newElem.getType(); var content := 'trace_ '. concat(self.name). concat(':'). concat(oldTypeName). concat(' -> '). concat(newName). concat(':'). concat(newTypeName).concat(' rule:').concat(rule); var source: simpleuml::Property := object simpleuml::Property { --name := oldName.concat(':').concat(oldTypeName); name := 'source'; taggedValue += object simpleuml::TaggedValue { name := 'source_string'; value := oldName.concat(':').concat(oldTypeName); }; }; var target: simpleuml::Property := object simpleuml::Property { --name := newName.concat(':').concat(newTypeName); name := 'target'; taggedValue += object simpleuml::TaggedValue { name := 'target_string'; value := newName.concat(':').concat(oldTypeName); }; }; var ruleUsed: simpleuml::Property := object simpleuml::Property { --name := newName.concat(':').concat(newTypeName); name := 'rule'; taggedValue += object simpleuml::TaggedValue { name := 'rule_string'; value := rule; }; }; } object { --create name name := content; attributes += source; attributes += target; attributes += ruleUsed; } }

138

mapping createTrace(in modElem:simpleuml::ModelElement, rule:String) : simpleuml::Class when { not modElem.resolveByRule(rule,simpleuml::ModelElement)->isEmpty() }{ init { var oldName := modElem.name; var newElem := modElem.resolveByRule(rule,simpleuml::ModelElement)->asSequence()->at(1); var newName := newElem.name; var oldTypeName := modElem.getType(); var newTypeName := newElem.getType(); var content := 'trace_ '. concat(modElem.name). concat(':'). concat(oldTypeName). concat(' -> '). concat(newName). concat(':'). concat(newTypeName).concat(' rule:').concat(rule); var source: simpleuml::Property := object simpleuml::Property { --name := oldName.concat(':').concat(oldTypeName); name := 'source'; taggedValue += object simpleuml::TaggedValue { name := 'source_string'; value := oldName.concat(':').concat(oldTypeName); }; }; var target: simpleuml::Property := object simpleuml::Property { --name := newName.concat(':').concat(newTypeName); name := 'target'; taggedValue += object simpleuml::TaggedValue { name := 'target_string'; value := newName.concat(':').concat(oldTypeName); }; }; var ruleUsed: simpleuml::Property := object simpleuml::Property { --name := newName.concat(':').concat(newTypeName); name := 'rule'; taggedValue += object simpleuml::TaggedValue { name := 'rule_string'; value := rule; }; }; } object { --create name name := content; attributes += source; attributes += target; attributes += ruleUsed; } } /** * Typing check **/ query simpleuml::ModelElement::getType() : String { if self.oclIsKindOf(simpleuml::Class) then 'Class' else if self.oclIsKindOf(simpleuml::Association) then 'Association' else if self.oclIsKindOf(simpleuml::Package) then 'Package' else if self.oclIsKindOf(simpleuml::Property) then 'Property'

139

else 'other' endif endif endif endif } /** * Counting the created elements **/ query simpleuml::ModelElement::count(rule:String) : Integer { self.resolveByRule(rule,simpleuml::ModelElement)->size(); }

Listing 26 QVT library containing the custom trace model, copy mapping methods, merge mapping methods and queries

transformation One2OneSingle; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := copyQ(model)->asOrderedSet(); var traces := handleTracing(model,'copy'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; }; ownedElements += object simpleuml::Model { ownedElements := target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 27 One-to-one mapping with a single transformation rule

transformation One2OneMulti; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := copyQ(model)->asOrderedSet(); var traces := handleTracing(model,'copy'); target := copyQ2(model)->asOrderedSet(); traces += handleTracing(model,'copy2'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source';

140

}; ownedElements += object simpleuml::Model { ownedElements += target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 28 One-to-one mapping with multiple transformation rules

transformation One2ManySingle; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := copyQ(model)->asOrderedSet(); var traces := handleTracing(model,'copy'); var target2 := copyQ(model)->asOrderedSet(); traces += handleTracing(model,'copy'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; }; ownedElements += object simpleuml::Model { ownedElements := target; ownedElements += target2; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 29 One-to-many mapping with one transformation rule

transformation One2ManyMulti; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := copyQ(model)->asOrderedSet(); var traces := handleTracing(model,'copy'); var target2 := copyQ2(model)->asOrderedSet(); traces += handleTracing(model,'copy2'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source';

141

}; ownedElements += object simpleuml::Model { ownedElements := target; ownedElements += target2; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 30 One-to-many mapping with multiple transformation rules

transformation Many2OneSingle; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := mergeQ(model); var target2 := mergeQ(model); var traces := handleTracing(model,'merge'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; }; ownedElements += object simpleuml::Model { ownedElements += target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 31 Many-to-one mapping with one transformation rule

transformation Many2OneMulti; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := mergeQ(model); var traces := handleTracing(model,'merge'); target := mergeQ2(model); traces += handleTracing(model,'merge2'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; };

142

ownedElements += object simpleuml::Model { ownedElements += target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 32 Many-to-one mapping with one transformation rule

transformation Many2ManySingle; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := mergeQ(model)->asOrderedSet(); var traces := handleTracing(model,'merge'); target += mergeQ(model); traces += handleTracing(model,'merge'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; }; ownedElements += object simpleuml::Model { ownedElements := target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 33 Many-to-many mapping with one transformation rule

transformation Many2ManyMulti; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init { var source := model.ownedElements; var target := mergeQ(model); var traces := handleTracing(model,'merge'); target += mergeQ2(model); traces += handleTracing(model,'merge2'); } object { name := 'Input Output and Traces'; ownedElements += object simpleuml::Model { ownedElements := source; name := 'Source'; }; ownedElements += object simpleuml::Model {

143

ownedElements += target; name := 'Target'; }; ownedElements += object simpleuml::Model { ownedElements := traces; name := 'Traces'; }; } }

Listing 34 Many-to-many mapping with multiple transformation rules

145

G Sample cases – Models and impact analysis

All the sample cases from Section 3.6 are implemented in the Operational Mappings language (see Appendix F) with the custom trace model. All these use the same source model from the implementations shown in Section 3.9. For each of the cases an impact analysis is made, in the case a change propagates to source model element Package 1. For each case the mapping under discussion is shown in a model representation (see Section 3.6.2.1)

G.1 One-to-one mapping with one transformation rule In this case, the source model elements are copied to exactly one target model element. When we introduce a change to source model element Package 1, the mapping impacted by this is shown in Figure 64. We see that the Package is mapped to the target model element Package 1, which is created by the transformation rule copy. The impact analysis for this case is shown in Listing 35.

Figure 64 One-to-one mapping with one transformation rule example

One2OneSingle: impacted target elements: Package 1 id = 0, rule used = copy un-impacted target elements: Package 2 id = 0, rule used = copy preserve the following sources: Package 1 created by the following executions: copy(Package 1) = Package 1 id = 0 Re-execution schema for update: copy(Package 1_new) = Package 1_new id = 0

Listing 35 Impact analysis for a change to Package 1 in the one-to-one mapping with one transformation rule example

146

G.2 One-to-one mapping with multiple transformation rules In this case, all source model elements are copied to a single target model element, with two transformation rules. The first and second rule both copy to the same model element in which the second rule overwrites the target model element which is created by the first rule. In Figure 65 we see that this is done for the source model element Package 1, which is mapped to target model element Package 1. We now introduce a change to source model element Package 1. The subsequent impact analysis is shown in Listing 36.

Figure 65 One-to-one mapping with multiple transformation rules example

One2OneMulti: impacted target elements: Package 1 id = 0, rule used = copy2 Package 1 id = 0, rule used = copy un-impacted target elements: Package 2 id = 0, rule used = copy Package 2 id = 0, rule used = copy2 preserve the following sources: Package 1 created by the following executions: copy2(Package 1) = Package 1 id = 0 copy(Package 1) = Package 1 id = 0 Re-execution schema for update: copy2(Package 1_new) = Package 1_new id = 0 copy(Package 1_new) = Package 1_new id = 0

Listing 36 Impact analysis for a change to Package 1 in the one-to-one mapping with two transformation rules example

G.3 One-to-many mapping with one transformation rule In this case, all the source model elements are copied to two different target model elements with one transformation rule. This mapping is shown in Figure 66. We now introduce a change to source model element Package 1. The corresponding impact analysis for this change propagation is shown in Listing 37.

147

Figure 66 One-to-many mapping with one transformation rule example

One2ManySingle: impacted target elements: Package 1 id = 0, rule used = copy Package 1 id = 1, rule used = copy un-impacted target elements: Package 2 id = 0, rule used = copy Package 2 id = 1, rule used = copy preserve the following sources: Package 1 created by the following executions: copy(Package 1) = Package 1 id = 0 copy(Package 1) = Package 1 id = 1 Re-execution schema for update: copy(Package 1_new) = Package 1_new id = 0 copy(Package 1_new) = Package 1_new id = 1

Listing 37 Impact analysis for a change to Package 1 in the one-to-many mapping with one transformation rule example

G.4 One-to-many mapping with multiple transformation rules In this case, all the source model elements are copied to two different target model elements with two different transformation rules. This mapping is shown in Figure 67. We now introduce a change to source model element Package 1. The corresponding impact analysis for this change propagation is shown in Listing 38 Impact analysis for a change to Package 1 in the one-to-many mapping with multiple transformation rules example.

148

Figure 67 One-to-many mapping with multiple transformation rules example

One2ManyMulti: impacted target elements: Package 1 id = 0, rule used = copy2 Package 1 id = 0, rule used = copy un-impacted target elements: Package 2 id = 0, rule used = copy Package 2 id = 0, rule used = copy2 preserve the following sources: Package 1 created by the following executions: copy2(Package 1) = Package 1 id = 0 copy(Package 1) = Package 1 id = 0 Re-execution schema for update: copy2(Package 1_new) = Package 1_new id = 0 copy(Package 1_new) = Package 1_new id = 0

Listing 38 Impact analysis for a change to Package 1 in the one-to-many mapping with multiple transformation rules example

G.5 Many-to-one mapping with one transformation rule In this case, the two source model elements are merged into exactly one target model element with one transformation rule. The name for this target model element is constructed by a concatenation of the names of the merged source model elements. This mapping is shown in Figure 68. We now introduce a change to one of the source model elements used, source model element Package 1. The corresponding impact analysis for this change is shown in Listing 39.

149

Figure 68 Many-to-one mapping with one transformation rule example

Many2OneSingle: impacted target elements: Package 1 + Package 2 id = 0, rule used = merge un-impacted target elements: preserve the following sources: Package 1 Package 2 created by the following executions: merge(Package 1) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0 Re-execution schema for update: merge(Package 1_new) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0

Listing 39 Impact analysis for a change to Package 1 in the many-to-one mapping with one transformation rule example

G.6 Many-to-one mapping with multiple transformation rules In this case, the source model elements are merged to exactly one target model element with two transformation rules. Both transformation rules create the same target model element, but the target model element from the second rule overwrites the target model element created by the first. This mapping is shown in Figure 69. We now introduce a change to source model element Package 1. The corresponding impact analysis for this change is shown in Listing 40.

150

Figure 69 Many-to-one mapping with multiple transformation rules example

Many2OneMulti: impacted target elements: Package 1 + Package 2 id = 0, rule used = merge2 Package 1 + Package 2 id = 0, rule used = merge un-impacted target elements: preserve the following sources: Package 1 Package 2 created by the following executions: merge2(Package 1) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0 Re-execution schema for update: merge2(Package 1_new) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1_new) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0

Listing 40 Impact analysis for a change to Package 1 in the many-to-one mapping with multiple transformation rules example

G.7 Many-to-many mapping with one transformation rule In this case, the source model elements are merged twice, which creates two target model elements, with one transformation rule. This mapping is shown in Figure 70. We now introduce a change to source model element Package 1. The corresponding impact analysis for the change is shown in Listing 41.

151

Figure 70 Many-to-many mapping with one transformation rule example

Many2ManySingle: impacted target elements: Package 1 + Package 2 id = 1, rule used = merge Package 1 + Package 2 id = 0, rule used = merge un-impacted target elements: preserve the following sources: Package 1 Package 2 created by the following executions: merge(Package 1) = Package 1 + Package 2 id = 1 merge(Package 2) = Package 1 + Package 2 id = 1 merge(Package 1) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0 Re-execution schema for update: merge(Package 1_new) = Package 1 + Package 2 id = 1 merge(Package 2) = Package 1 + Package 2 id = 1 merge(Package 1_new) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0

Listing 41 Impact analysis for a change to Package 1 in the many-to-many mapping with one transformation rule example

G.8 Many-to-many mapping with multiple transformation rules In this case, the two source model elements are merged twice, which creates two target model elements for each merge, with two transformation rules. The second rule overwrites the results from the first rule. This mapping is shown in Figure 71. We now introduce a change to source model element Package 1. The corresponding impact analysis for this change is shown in Listing 42.

152

Figure 71 Many-to-many mapping with multiple transformation rules example

Many2ManyMulti: impacted target elements: Package 1 + Package 2 id = 0, rule used = merge2 Package 1 + Package 2 id = 0, rule used = merge un-impacted target elements: preserve the following sources: Package 1 Package 2 created by the following executions: merge2(Package 1) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0 Re-execution schema for update: merge2(Package 1_new) = Package 1 + Package 2 id = 0 merge2(Package 2) = Package 1 + Package 2 id = 0 merge(Package 1_new) = Package 1 + Package 2 id = 0 merge(Package 2) = Package 1 + Package 2 id = 0

Listing 42 Impact analysis for a change to Package 1 in the many-to-many mapping with multiple transformation rules example

153

H Case study – Flattening transformation specification

A flattening implementation is used for the case study in this project. The flatting transformation implements the following algorithm:

- copy the primitive types used - copy the the leaf classes

o Adding properties inherited by the generalization relations Do not add properties with the same name as properties native

to the class - copy the associations

o resolve the source element to the correct leaf class, by following the generalizations

o resolve the target class from the list of created classes - create the traces

The custom trace model is implemented into this transformation specification. transformation Simpleuml_To_FlatenSimpleuml; import sampleCases; metamodel 'http:///SimpleUML.ecore'; mapping main(in model: simpleuml::Model): simpleuml::Model { init{ var input := model; var primitiveTypes : OrderedSet(simpleuml::PrimitiveType):= model.getAllPrimitiveTypes().copyprimitive()->asOrderedSet(); var classes : OrderedSet(simpleuml::Class):= model.getAllClasses().leafClass2Class(model)->asOrderedSet(); var associations : OrderedSet(simpleuml::Association):= model.getAssociations(); var traces := handleTracing(model,'leafClass2Class'); traces += handleTracing(model,'copyAssociation'); traces += handleTracing(model,'property2property'); traces += handleTracing(model,'copyprimitive'); } ownedElements += object simpleuml::Model { name := 'Source'; ownedElements += input.ownedElements; }; ownedElements += object simpleuml::Model { name:= 'Target'; ownedElements+=classes; ownedElements+=primitiveTypes; ownedElements+=associations; }; ownedElements += object simpleuml::Model { name := 'Traces'; ownedElements += traces; }

154

} query simpleuml::Class::derivedAttributes() : OrderedSet(simpleuml::Property){ if self.generalizations->isEmpty() then self.attributes else self.attributes->union( self.generalizations->collect(g | g.general.derivedAttributes()->select(attr | not self.attributes->exists(att | att.name = attr.name) ) )->flatten() )->asOrderedSet() endif } query simpleuml::Model::getAssociations() : OrderedSet(simpleuml::Association){ self.getAllClasses()->select(cl | not self.allInstances(simpleuml::Generalization)->exists(g | g.general = cl))->collect(cl | cl.derivedAssociations(self).copyAssociation(cl))->flatten()->asOrderedSet(); } query simpleuml::Class::derivedAssociations(in model : simpleuml::Model) : OrderedSet(simpleuml::Association){ if self.generalizations->isEmpty() then model.allInstances(simpleuml::Association)->select(assoc | assoc.source = self)->asOrderedSet() else model.allInstances(simpleuml::Association)->select(assoc | assoc.source = self)->asOrderedSet()->union( self.generalizations->collect(g | g.general.derivedAssociations(model) )->flatten() )->asOrderedSet() endif } query simpleuml::Model::getAllClasses() : OrderedSet(simpleuml::Class){ self.ownedElements->select(el | el.oclIsKindOf(simpleuml::Class))->collect(el | el.oclAsType(simpleuml::Class))->asOrderedSet(); } query simpleuml::Model::getAllPrimitiveTypes() : OrderedSet(simpleuml::PrimitiveType){ self.ownedElements->select(el | el.oclIsKindOf(simpleuml::PrimitiveType))->collect(el | el.oclAsType(simpleuml::PrimitiveType))->asOrderedSet(); } mapping simpleuml::Class::leafClass2Class(in model : simpleuml::Model) : simpleuml::Class when {not model.allInstances(simpleuml::Generalization)->exists(g | g.general = self)}

155

{ name:= self.name + ' id='+ self.count('leafClass2Class'); abstract:= self.abstract; attributes:= self.derivedAttributes().property2property(self)->asOrderedSet(); } mapping simpleuml::Association::copyAssociation(in sourceClass : simpleuml::Class) : simpleuml::Association { name:=self.name + ' id='+ self.count('copyAssociation'); source:=sourceClass.resolveByRule('leafClass2Class', simpleuml::Class)->asSequence()->first(); target:= self.target.resolveByRule('leafClass2Class', simpleuml::Class)->asSequence()->first(); } mapping simpleuml::Property::property2property(in ownerClass : simpleuml::Class) : simpleuml::Property{ name:= self.name + ' id=' + self.count('property2property'); type:= self.type.resolveByRule('copyprimitive',simpleuml::PrimitiveType)->asSequence()->first(); owner:= ownerClass; } mapping simpleuml::PrimitiveType::copyprimitive() : simpleuml::PrimitiveType{ name:= self.name + ' id=' + self.count('copyprimitive'); }

Listing 43 Flattening simpleUML models implementation with custom trace model in the Operational Mappings

157

I Case study – Intermediary model

The entire intermediary model resulting after the execution of the flattening implementation, including source, target and trace model, is shown in Figure 72

Figure 72 Case study intermediary model

traceability-based change management · 2020. 4. 6. · the model driven architecture (mda) raises...

Documents