Assistance System for OCL Constraints Adaptation during Metamodel Evolution

Abstract

Abstract-Metamodels evolve over time, as well as other artifacts. In most cases, this evolution is performed manually by stepwise adaptation. In MDE, metamodels are described using the MOF language. Often OCL constraints are added to metamodels in order to ensure consistency of their instances (models). However, during metamodel evolution these constraints are omitted or manually rewritten, which is time consuming and error prone.We propose a tool to help the designer to make a decision on the constraints attached to a metamodel during its evolution. Thus, the tool highlights the constraints that should disappear after evolution and makes suggestions for those which need adaptation to remain consistent. For the latter case, we formally describe how the OCL constraints have to be transformed to preserve their syntactical correctness. Our adaptation rules are defined using QVT which is the OMG standard language for specifying model-to-model transformations. I. INTRODUCTION Model Driven Engineering (MDE)[1] raises the abstraction's level of software development from code to models, with a great emphasis on focusing the developer concerns on the problem domain rather than on the underlying technologies. Metamodels are the definition of abstract syntax of languages. However, structural constructions of metamodeling languages do not allow to express completely the syntax of a language (e.g. context-sensitive properties). In consequence, to get coherent models, it is necessary to add constraints expressed using the Object Constraint Language (OCL) [2]. Moreover, metamodels evolve over time like other software artifacts [3], [4], due to several reasons: to be consistent with the evolution of the application domain scope, to improve or correct the abstract syntax of the language, etc. As a consequence, these changes may break consistency of related terminal models. The risks stem from the fact that constraints attached to metamodels are either omitted or manually rewritten, which is time consuming and error prone [4], [5].To address this problem, we propose an approach in order to assist designers in constraint adaptation during a stepwise evolution [6] of a metamodel. This approach consists in identifying the impact of a change, made at the metamodel, on its associated constraints. After each modification of the

Metamodel and Constraints Co-evolution: A Semi Automatic Maintenance of OCL Constraints

“…Hassam et al [7] proposed to co-evolve OCL constraints using QVT [22] a transformation language. Similarly, Markovic et al [16,17] proposed to refactor, based on QVT, OCL constraints annotated on UML class diagrams when these last evolve.…”

“…However, existing approaches [7,5,6,16,17,13] propose a unique resolution per metamodel change. They neither consider the two above issues, nor interact with the user.…”

Co-evolving meta-models and their instance models: A formal approach based on graph transformation

“…These are model transformations [54], OCL constraints [55], and meta-model hierarchies with more than two levels [56]. A taxonomy for the evolution of modeling languages discussing different scenarios including the evolution of meta-models and the migration of models and model transformations, can be found in [40].…”

A semi-automatic maintenance and co-evolution of OCL constraints with (meta)model evolution

“…Manual co-evolution can be tedious, time-consuming, and an error-prone task [13,2], in particular when hundreds of OCL constraints are impacted by the changes. In such context, it is crucial to support software engineers with an automatic co-evolution for two reasons.…”

“…Consequently, it is crucial to consider the two above issues when coevolving OCL constraints. However, existing approaches [13,9,10,30,31,25,6] neither consider the two above issues, nor interact with the user. We think that a co-evolution approach should nd a balance between manual intervention and full automation.…”