Information Technology Reference
In-Depth Information
objects. Banerjee and Naumann [19] present a number of static analysis rules
for ensuring a property called by them safety , which is shown in their work to
imply confinement. The input is a class table and its division into three sets of
classes: Own and Rep , defining the possibly non-disjoint sets of owner and rep-
resentation classes, respectively, and Client with all other classes. The analysis
is modular, as only Own and Rep code is constrained (with one exception, for
new commands). They present the rules as follows:
1. Public methods declared in
Own
or subclasses cannot return
Rep
types; otherwise, references
to internal objects might leak to clients;
2. Methods inherited or declared by Own cannot have parameters of Rep types; otherwise, non-
owner subclasses might have access to Rep instances;
3. Rep classes cannot inherit any methods from non- Rep superclasses; for instance, a method
could return self to a client, which is highly undesirable;
4. For any field access e.f ,if e is of type Own , it cannot access fields of type Rep , unless e is self ;
this rule must be checked only for public fields, as it is guaranteed by type safety for private
fields;
5. For assignments
new
in
Client
,
B
cannot be
Rep
or any of its subclasses; otherwise,
x:=
B
these clients would have direct access to
Rep
instances;
6. For method calls
(or
subclasses), m cannot have Rep parameters (otherwise Rep instances could leak); also, (2) if
the call is within Own , m is declared in Own ,and e is self , parameters and return may be Rep
type. The second case in fact weakens the confinement constraints with a condition that can
be detected by static analysis.
e )
¯
:(1)if
e
is a
Client
object, and the call is within
Own
or
Rep
x:= e.m(
3Synchron on
Given a specific consistency relationship between object models and programs,
we formalize a unidirectional approach of model-driven refactoring by applying
synchronizers .
3.1 Synchronizers
For object models, we adopt the approach of primitive transformations being
composed into refactorings. To each Alloy law from the catalog we associate a
synchronizer - set of conditional program transformations disciplined by laws
of programming - to be applied to a program, making it consistent with the
transformed object model. The mechanics of the synchronization is depicted in
Figure 1, where OM represents an object model, and P a program. The first step
is the application of a model refactoring (a) - in this case, made up of two Alloy
laws, X and Y, applied from L-R. Next, each applied law is associated with a
synchronizer (depicted as “corresponds” in Figure 1; for instance, Law X corre-
sponds to Sync X ), applied to P. The sequential application of the synchronizers
in (b) results in a synchronized program.
A synchronizer carries out program refactoring by applying a sequence of law
applications, on the assumption of the consistency relationship defined in the
next section. The only preconditions for the application of synchronizers is that
the program must have confinement for a subset Own of classes and in syntactic
and semantic consistency with the previous version of the model. Therefore, the
synchronizers are especially conceived to exploit the model invariants that are
known to be met by the program; program transformations are specialized with
 
Search WWH ::




Custom Search