Transformation contracts in practice

Abstract

Model-driven development (MDD) is a software engineering discipline which suggests that software development should be done at the modeling level and that applications should be generated from models. The MDD approach is becoming more mature in time with new techniques and tools being defined to support it, also as a result of intensive research in this field. A key concept of MDD is a model transformation that generates applications from models. Since models are "first-class" citzens in MDD their verification and validation is an important task. Of course, also are model transformations. In this paper we apply the transformation contract approach to model transformations. A transformation contract is a specification of what a particular model transformation must implement and essentially specifies a relation between metamodels, the transformation metamodel, and properties that such a relation must satisfy, such as invariants in the Object Constraint Language (OCL). A transformation contract is said to be correct when a source model in conformance with its metamodel implies in a target model in conformance with the target metamodel and the joined model of source and target is in conformance with the transformation metamodel, where model conformance means that all the properties of a metamodel hold in a model. We have defined a design pattern that enforces transformation contract correction over model transformations, that is, a model transformation implemented following our transformation contract will be verified and validated following transformation contracts correctness. We have also developed model transformations using our transformation contract design pattern. The UMLToEJB model transformation generates application code in Enterprise Java Beans, from class diagrams described in the Unified Modeling Language. This paper reports on our proposed design pattern, the design of UMLToEJB, and illustrates how our approach may help different actors in MDD with transformation contracts, including model transformation designers, to identify erroneous situations.

Model Transformation Testing and Debugging: A Survey

“…The work by Cariou et al [25] is the irst that investigates and discusses the relevance of OCL for deining MT contracts. Then, Braga et al [15,16] formalize the concept of contract as transformation contract, which is essentially a transformation model. Similarly, Gogolla and Vallecillo (et al) [44,127] present the concept of Tract as a generalization of the concept of contract.…”

Automating the analysis of NCL documents with a model-driven approach

“…A abordagem de análise (dirigida a modelos) apresentada neste artigo segue uma abordagem de contratos de transformação [6], como apresentado na Figura 1. Um contrato de transformaçãoé uma especificação de uma transformação de modelos como um modelo K que relaciona os metamodelos das duas linguagens de modelagem.…”

Uma abordagem de desenvolvimento de linha de produtos orientada a modelos para a construção de famílias de sistemas embarcados críticos

“…No trabalho descrito por Braga et al (2012), os autores focam em problemas práticos envolvidos na engenharia de linha de produtos para estabelecer uma infraestrutura de LP para certificação de produtos. Nesse trabalho, os autores propõem um metamodelo para capturar as entidades envolvidas na certificação de LP e a relação entre elas.…”

“…Segundo Braga et al (2012), a verificação busca ter certeza de que um modelo tem propriedades gerais, tais como: "consistência (BRAGA; HaeUSLER, 2010), o que garante que as propriedades de um modelo são satisfeitas e, portanto, ele pode ser instanciado; ou, temporais (CLARKE JR.; GRUMBERG; PELED, 1999), que são aquelas relacionadas com os aspectos comportamentais de um modelo. A validação procura aferir que um conjunto de invariantes (WARMER; KLEPPE, 2003) realize um cenário ou modelo específico, tais como examinar a presença de ciclos em uma hierarquia de classes em um diagrama de classes qualquer que seja uma instância do metamodelo UML.…”

“…Pode ser necessário, por exemplo, desenvolver um único metamodelo para os múltiplos sub-domínios, e então desenvolver diferentes sintaxes concretas, de forma que estes sub-domínios estejam integrados mas ainda assim possuam diferentes visões (LUCRÉDIO, 2009). Fonte: Braga et al (2012) Nesta atividade, as interdependências entre sub-domínios são explicitadas, pois podem ter impacto nas decisões de projeto, principalmente quando relacionam sub-domínios do fluxo de software com sub-domínios do fluxo de hardware. As restrições de inclusão e exclusão mútua entre as features indicam algumas destas dependências, porém outras podem se tornar aparentes somente após a implementação estar avançada (LUCRÉDIO, 2009).…”