Synchronizing Model and Program Refactoring - Formal Methods: Foundations and Applications - page 108

block. In this case, the subclass X can be removed, given that U is an abstract
class.
Certainly there are several open questions. For instance, it is not clear how
invariants will be automatically identified by a refactoring tool for the application
of specific refactorings. Our intuition is that catalogs of program refactorings
could be extended with improvements based on invariants, conditionally applied
based on a set of invariants.
5.2 Quality of Refactorings
With formal synchronizers, quality factors such as cohesion and legibility still
requires some improvement in the resulting program. For instance, the succes-
sive application of removeSubclass may result in numerous implementations of
methods for eliminating type tests, which is clearly amenable to simplification.
Therefore, additional refactoring might be necessary, such as inlining these calls
and removing methods. These transformations are also formalizable as laws of
programming . Although theoretically feasible, these law applications could not
be automatically applied in the formal model, since our initial assumption is that
each synchronizer is recorded and independently applied in order, disregarding
the composed refactoring that was applied to the model.
In this scenario, we envisage developer feedback as a possible answer to this
challenge, in addition to complementary synchronizers . In this case, the appli-
cation of the model refactoring could bring additional information that is then
applied in the program refactoring, according to feedback from the developer of
a supporting tool. If the developer agrees, a complementary synchronizer, con-
taining the additional law applications, is automatically applied. The outcome of
the complementary synchronizer is an improved program, yet still conforming,
syntactically and semantically, to the refactored model.
5.3 Consistency and Synchronizers
The required consistency relationship was adjusted during the formalization of
synchronizers. Several choices have been considered and this scenario allowed
us to gather evidences on how the chosen consistency affects the final results of
model-driven program refactorings.
The rule of thumb states that, the more abstract are the models, the looser
(different possible implementations for the same object model) is the syntactic
consistency relationship. The syntactic mappings between model and program
declarations drive the freedom of implementation for modeled signatures and re-
lations. At the end, we adopted a tighter consistency relationship than initially
expected: signatures must be implementedasclassesandrelationsasfieldsin
the corresponding class. Nevertheless, the required consistency relationship still
preserves some abstraction: methods and additional classes can be freely im-
plemented, and hierarchies can contain more classes than modeled. In addition,
the modeled signatures and relations must be implemented in a uniform way, so
the synchronization is still compelling for the user. As refactoring is a structural