![](bg2.png)
the features in post form are assumed to be writable
in this case, and to be mutually data-dependent.
For any system there are also implicit operational
constraints which relate the two ends of binary asso-
ciations. Assertion constraints arise from the multi-
plicity restrictions of association ends, ie, a 0..n mul-
tiplicity end br has a constraint br→size() ≤ n.
We will slice a class diagram specification M by
slicing the controller class C of M: this class is di-
rectly or indirectly a client of all other classes in M
and is not a supplier of any other class in M.
A history of a specification M is a finite sequence
of invocations of update operations on instances of C.
A history is valid if operations are only invoked on
instances which have been created, and for which the
operation precondition is true at the point of call, in
addition the history should conform to the protocol
state machine SM
C
of C.
The definition of slicing we will use for class dia-
grams M is the following: S <
syn
M if S has a subset
of the elements of M. S =
sem
M holds, for a given
state s in the protocol state machine of C, and set V
of data features of M, if any valid history σ with final
state s of M is also a valid history with final state s in
S, and if the values of the features in the slice set V in
S in the final state of σ are equal to the values of these
features in M at the final state when σ is applied to
both models, starting from the same initial values for
the features they have in common. We assume that
the protocol state machines of C in M and S have the
same states.
The first step in producing a slice of a class C is
to normalise the class invariant, and each pre and post
condition, so that these are all in the form of conjunc-
tions of predicates. Then the effective invariant pred-
icates are copied to the postconditions of each update
operation.
For each postcondition predicate p we define the
sets of features read and written in p, and its internal
data dependencies:
• wr(p) is the set of features written to in p. If p is
operational, this set is the single writable feature
of p, otherwise it is the set of features not in pre
form in p.
• rd(p) is the set of features read in p. If p is op-
erational this is the set of all features occurring in
the test, value, reference or index expressions in
p, and the pre form f@pre of the writable feature
f (in the case of a simple equality f = e, the pre
form f@pre of the writable feature f itself is not
included, unless it occurs in e). For other predi-
cates rd(p) is the set of features in pre form, or
input parameters.
• In the case of a formula
C.allInstances()→exists(P) specifying creation
of an instance of C satisfying P, C.allInstances()
is a written feature and C.allInstances()@pre a
read feature.
• In the case of formulae x.oclIsNew() or
x.isDeleted(), where x is of class type C,
C.allInstances() is a written feature and
C.allInstances()@pre and x are read features.
• The internal data-dependencies of an operational
predicate p are then:
dep(p) = rd(p) × wr(p)
and for a non-operational predicate
dep(p) = (rd(p) ∪ wr(p))× wr(p)
The write frame of an operation op is the union of
wr(p) for the predicates p in its postcondition, this is
denoted wr(op).
The predicates in the postcondition of an opera-
tion are assumed to be control dependent on the pred-
icates in the precondition (Bruckner and Wehrheim,
2005).
At the level of particular features, f, g, there is a
direct dependency of f on g in an operation op, if:
• g 7→ f is in some dep(p) for a postcondition pred-
icate p of op.
Let r
op
be the (non-reflexive)transitive closure of this
relation. Then the feature dependency relation ρ
op
of
op includes the pairs:
• g 7→ f if g occurs in the precondition and f is in
wr(p) for some postcondition predicate p
• g 7→ f if g is an input parameter of the operation,
or is a feature not in wr(op), and g 7→ f is in r
op
• g 7→ f if g@pre 7→ f is in r
op
• x 7→ x if x 6∈ wr(op).
The meaning of this relation is that the value of g at
the start of the operation may affect the value of f at
the end. Initial values of features not in ρ
−1
op
(| V |) can-
not affect the value of any feature in V at termination
of the operation.
In order to analyse dependencies between data in
different operations, we need to consider the possi-
ble life histories of objects of the class. A UML
class C may have a protocol state machine SM
C
as its
classifierBehavior (Lano, 2009b), this state machine
defines what sequences of operations can be applied
to the object, and under what conditions. SM
C
can be
used as the basis of the data and control flow graph
G
C
of the class C. We carry out normalisation of the
pre and post-conditions of each transition of t, so that
these are conjunctions of predicates.
The primary nodes of G
C
are:
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
260