Information Technology Reference
In-Depth Information
applied to the program; if this application is successful, then the composite tactic
succeeds. Otherwise
t
2
is applied. Finally, if
t
2
fails, then the whole tactic aborts
(which is a more critical situation than failure). When the tactic contains many
choices, the first choice that succeeds is selected. In addition, the language allows
us to define pattern matching within a program, with the constraint
applies to
.
For instance,
applies to
cmd
[(
X
)
e
]
do
t
applies the
t
tactic to every command
in the program that includes an expression cast with
X
.
Introduce Subclass.
Law 1(L-R) introduces a subsignature for one of the
declared signatures. This makes
U
abstract according to the modeled invariant
(
X=U-S-T
). Here we show the associated synchronizer, that accepts a consistent
program. However additional classes can be declared in the program hierarchy.
Tact i c
introduceSubclass
(
X,U
:
Class
)
X,X
)
(
law
rename
(
|
skip
)
;
law
classElimination
(
setExtends
(
X,U
)
, ←
)
;
law
newSuperclass
(
U,X,→
)
;
end
The trivial law
rename
(
X,X
) renames the
X
class. If it fails (for the case in
which the class is not declared), nothing happens (
skip
). If class
X
is already
present, it is freely renamed to
X'
, because
X
is considered in this case an
im-
plementation detail
that was not modeled. This action does not have impact on
the consistency, as renamed declarations are not in the model. Next, the syn-
chronizer introduces the new class
X
as a direct subclass of
U
,withLaw
class
elimination
[22].
setExtends
makes
X
a direct subclass of
U
. Other subsig-
natures of
U
will be declared as classes, although their inheritance relationship
with
U
may be indirect - implementation-only subclasses are allowed. Finally,
every
U
object creation in the entire program is replaced by
X
instantiations, by
Law 1 from L-R (
[
new
X/
new
U]
).
The synchronizer provides evidence on how model-driven refactoring can im-
prove tool support for refactoring, since the semantic properties from object
models can aid refactoring automation. In
introduceSubclass
, the program is
refactored to a specific configuration of
U
objects, making them
X
instances.
This information cannot be obtained solely from the source code, then introduc-
ing a plain subclass would not include the changes applied by the synchronizer.
Remove Subclass.
The opposite transformation given by Law 1 removes sub-
signature
X
assuming the invariant (
X=U-S-T
);
S
and
T
become the
U
's only
subsignatures. The synchronizer removes the corresponding
X
class, although,
differently from the model, the program class may declare fields and methods,
and may have implementation-only subclasses.
The following definition uses several auxiliary tactics, which are informally
shown in this paper; their complete definitions are described in [17].
Tact i c
removeSubclass
(
X
:
Class
)
tactic
moveUpFields
(
X
)
;
tactic
moveUpMethods
(
X
)
;
tactic
changeDeclarationsTypetoSuper
(
X
)
;
applies to
cmd
[(
X
)
e
]
do law
eliminateCastExpressions
(
cmd
[(
X
)
e
]
, →
)
;
Search WWH ::
Custom Search