| Resumo: |
Program transformation is current practice in software development, especially refactoring. However, in general, there is no precise specification of these transformations and, when it exists, it is neither proved sound nor validated systematically, which can cause static semantic or behavioural errors in the resulting programs, after each transformation application. This work proposes a strategy to validate program transformation specifications grounded by a formal infrastructure built predominantly in Alloy. In this work we focus on transformations in languages that support OO features such as Java, ROOL, the calculus of refinement of component and object-oriented systems known as rCOS and an OO language with reference semantic. The scope of this work, concerning the strategy implementation, is a subset of Java. Complementarily to testing, formal languages provide a mathematically solid reasoning mechanism to establish the soundness of transformations. Unfortunately, a complete formal treatment for transformations in OO languages is ruled out because even for Java there is no complete formal semantics. We investigate the trustworthiness of program transformations by using an approach that combines (bounded) model finding and testing. Our Alloy formal infrastructure comprises four main Alloy models: (1) a metamodel for a subset of OO language features and a set of predicates that capture the static semantics, where the main predicate is able to determine if a program is well–formed; (2) a Transformation-Specific model for each program transformation being investigated; (3) a Static Semantics Validator model; and (4) a Dynamic Validator Model, which generates all possible instances (according to the scope specified), each one having a representation of a program before and after the transformation application. If any instances are generated in (3), this means that there is a failure in the transformation specification. So, in this case it is necessary to correct the specification and re–submit it to the Alloy Analyzer. This process is repeated until no more instances are found by the Static Semantics Validator Model. Hence, the instances generated by the Dynamic Validator model only represent well–formed programs since it is only applied after the Static Semantics Validator model. Afterwards, the instances generated by (4) are further submitted to a tool, called Alloy-To-Java Translator, which generates Java programs corresponding to these instances along with tests to be applied in each side of the transformation. These programs are finally validated with regard to dynamic semantic problems, based on these automatic tests generated in (4). In this way, a developer can implement the transformations with some confidence on their behavioural preservation, after validating the transformation specifications using the proposed framework. The strategy we propose seems promising since it is an alternative to validate transformations even when a complete semantics of the languages is not available. The results of the validation of a representative set of transformations found in the literature show that some transformation issues, concerning both static and dynamic behaviour, can be detected. |
|---|
