Assistance System for OCL Constraints Adaptation during Metamodel Evolution. Kahina Hassam, Salah Sadou, Vincent Le Gloahec, Régis Fleurquin To cite this version: Kahina Hassam, Salah Sadou, Vincent Le Gloahec, Régis Fleurquin. Assistance System for OCL Constraints Adaptation during Metamodel Evolution.. 15th European Conference on Software Maintenance and Reengineering (CSMR), 2011, Mar 2011, Oldenburg, Germany. pp.151 - 160, 10.1109/CSMR.2011.21. hal-00664786 HAL Id: hal-00664786 https://hal.archives-ouvertes.fr/hal-00664786 Submitted on 31 Jan 2012 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Assistance System for OCL Constraints Adaptation During Metamodel Evolution Kahina Hassam Salah Sadou Vincent Le Gloahec Valoria laboratory, Valoria laboratory, Alkante SAS, France Université de Bretagne-Sud, France Université de Bretagne-Sud, France Email: [email protected] Email: [email protected] Email: [email protected] Régis Fleurquin Valoria laboratory, Université de Bretagne-Sud, France Email: regis.fl[email protected] Abstract—Metamodels evolve over time, as well as other metamodel, the assistance system shows the constraints that artifacts. In most cases, this evolution is performed manually become obsolete or proposes a transformation of the latter, by stepwise adaptation. In MDE, metamodels are described whenever it is possible. For constraint transformation we use using the MOF language. Often OCL constraints are added to metamodels in order to ensure consistency of their instances grammar adaptation. Thus, operations on metamodel are for- (models). However, during metamodel evolution these constraints malized using the QVT Relation part of the OMG’s standard are omitted or manually rewritten, which is time consuming and Query/Views/Transformations (QVT). For each QVT Relation, error prone. we propose an adaptation to the constraints (also described We propose a tool to help the designer to make a decision using QVT Relation) that involve artifacts that are modified on the constraints attached to a metamodel during its evolution. Thus, the tool highlights the constraints that should disappear by the concerned operation. after evolution and makes suggestions for those which need In the next section we present an example that highlights adaptation to remain consistent. For the latter case, we formally the problem raised by metamodel evolution. we describe our describe how the OCL constraints have to be transformed to approach in Section III. In Section IV, we show how to adapt preserve their syntactical correctness. Our adaptation rules are constraints to a change in their metamodel. We present an defined using QVT which is the OMG standard language for specifying model-to-model transformations. implementation of our solution in Section V. And before concluding in Section VII, we give some related work in I. INTRODUCTION Section VI. Model Driven Engineering (MDE) [1] raises the abstrac- tion’s level of software development from code to models, with II. MOTIVATING EXAMPLE a great emphasis on focusing the developer concerns on the The work presented in this paper was mainly initiated problem domain rather than on the underlying technologies. by several requirements of our industrial partner, Alkante, a Metamodels are the definition of abstract syntax of languages. company specialized in the design of Web applications and However, structural constructions of metamodeling languages Geographical Information Systems. To build their applications, do not allow to express completely the syntax of a language the company has defined its own Architecture Description (e.g. context-sensitive properties). In consequence, to get co- Language (ADL), referred to as AlCoWeb [7]. The abstract herent models, it is necessary to add constraints expressed syntax of this ADL is inspired by the UML2 Component using the Object Constraint Language (OCL) [2]. model. Along with this ADL, the company has elaborated Moreover, metamodels evolve over time like other software a complete Model-Driven platform, AlCoWeb-Builder, which artifacts [3], [4], due to several reasons: to be consistent with allows the graphical definition of AlCoWeb models and the the evolution of the application domain scope, to improve automatic code generation of corresponding Web applications. or correct the abstract syntax of the language, etc. As a To ensure the quality of produced models, the AlCoWeb consequence, these changes may break consistency of related metamodel comes with a large set of OCL constraints that terminal models. The risks stem from the fact that constraints are checked during the design stage. Due to constant im- attached to metamodels are either omitted or manually rewrit- provements of its underlying Web development framework, ten, which is time consuming and error prone [4], [5]. the company makes evolve its ADL accordingly, but also has To address this problem, we propose an approach in order to deal with the co-evolution of OCL constraints. to assist designers in constraint adaptation during a stepwise The Figure 1 presents two versions of the AlCoWeb ADL evolution [6] of a metamodel. This approach consists in abstract syntax: on the left side, the initial version of the identifying the impact of a change, made at the metamodel, ADL (AlCoWeb-v1), and on the right side, a revised version on its associated constraints. After each modification of the obtained after several stepwise adaptations (AlCoWeb-v2). Importable Importable Property imported name imported Connector Property id name name type binding id id InstanceSpecification value type stereotype 0..* stereotype call value type order call AbstractComponent order visibility name visibility id end2 0..* 0..* property stereotype port Port AbstractComponent Connector Port property level 0..* name name binding name end name id id id order id 0..* 2 xp stereotype level type type order xp yp type port xp yp width xp yp 0..* component height yp width port port 0..* height Envelop required 1 1 provided reqPort provPort title 0..* RequiredInterface ProvidedInterface ownedReqOp ownedProvOp 0..* subcomponent subcomponent required 0..* 0..* provided reqPort provPort Operation name Envelop Component Operation id title name component Component requiredOp providedOp operation type id 0..* 0..* 0..* parameters type 0..* parameters call call operation order order visibility 0..* visibility AlCoWeb-V1 AlCoWeb-V2 Fig. 1. Evolution of AlCoWeb Metamodel Over Time OCL constraints defined on the initial version of the Al- difficult to maintain. The manual maintenance of constraints is CoWeb metamodel allow to ensure the respect of common an error-prone task, which could even lead maintainers to miss component model rules and those specific to AlCoWeb mod- some modifications. For example, consider the constraint (3) els. Here are some examples of OCL constraints attached to attached to the initial metamodel. The designer in charge of the the initial AlCoWeb-v1 metamodel: evolution of the metamodel, and its constraints, unfortunately −−(1) Provided operations must have made a mistake. In this particular example, the adaptation of −− a public visibility self.provided->notEmpty() self.required- c o n t e x t : P o r t the expressions and inv : self.provided −>forAll(o| o. visibility=’public’) >notEmpty() had been forgotten. The constraint is still syntac- −−(2) An envelope should not contain components tically valid on the new version of the AlCoWeb metamodel. −− with the same name Indeed, the provided and required properties still exist. But c o n t e x t : Envelop inv : self .component−>forAll(c1,c2|c1 <> c2 unfortunately, the meaning of the constraint has changed and i m p l i e s c1.name <> c2.name) its application requirements are not satisfied anymore. The −−(3) A port has either provided operations , problem was detected during the construction of a model −− or required operations , but not both and after several attempts to circumvent it. At the end, it c o n t e x t : P o r t inv : self.required −>notEmpty () i m p l i e s became necessary to return to the metamodel and to check self .provided −>isEmpty ( ) the consistency of its constraints. and self .provided −>notEmpty () Such mistakes often occur, and are very time consuming for i m p l i e s self .required −>isEmpty ( ) the maintainers. That is why the evolution of constraints have Here, below, an example of changes that were made to get to be automated as much as possible. the latest version of the AlCoWeb metamodel: III. APPROACH (i) Transform the association between metaclasses Envelop and Component in an association between metaclasses Envelop Our approach is to provide i) a set of basic operations to and AbstractComponent. modify a metamodel, ii) assistance in order to adapt constraints (ii) From the association between metaclasses Port and according to changes operated on their associated metamodel. operation, introduce a new metaclass (RequiredInterface), These basic operations are a synthesis made from those (iii) From the association between metaclasses