SLICING OF UML MODELS
K. Lano and S. Kolahdouz-Rahimi
Department of Computer Science, King’s College London, London, U.K.
Keywords:
UML, Model transformations, Software verification.
Abstract:
This paper defines techniques for the slicing of UML models, that is, for the restriction of models to those
parts which specify the properties of a subset of the elements within them. The purpose of this restriction is to
produce a smaller model which permits more effective analysis and comprehension than the complete model,
and also to form a step in factoring of a model. We consider class diagrams, individual state machines, and
communicating sets of state machines.
1 INTRODUCTION
In this paper we show how slicing techniques for
specification languages such as Z (Wu and Yi, 2004)
and Object-Z (Bruckner and Wehrheim, 2005) can be
combined with the semantic slicing of (Lano, 2009a)
to slice UML class diagrams and state machines.
A slice can be considered to be a transformed ver-
sion S of an artifact M which has a lower value of
some complexity measure, but an equivalent seman-
tics with respect to the sliced data (Harman et al.,
2003):
S <
syn
M S =
sem
M
The form of slicing used depends on the type of analy-
sis we wish to perform on M: S should have identical
semantics to M for the properties of interest, but may
differ for other properties.
In general, applying slicing at a high level of ab-
straction simplifies the calculation of the slice, and
means it is possible to detect specification flaws at an
early development stage, thus reducing development
costs.
2 SLICING OF CLASS
DIAGRAMS
We assume that the client-supplier relation between
different classes in a class diagram forms a tree struc-
ture. The class at the root of this tree is termed the
controller class of the system: it will usually serve as
the access point to the services of the system for exter-
nal users. Operations are assumed to be deterministic.
The data features of such a system are all the at-
tributes of classes in the system, including association
ends owned by the classes.
Slicing will be carried out upon class invariants
and operation pre and postconditions by considering
the predicates P of which they are composed. A pred-
icate is a truth-valued formula, whose main operator
is not and. Class invariant predicates can be either as-
sertions: propertieswhich are expected to be invariant
for objects of the class, but which do not contribute
to the effect of operation postconditions, or effective:
implicitly conjoined to the postcondition of each up-
date operation.
In order to reduce the dependencies in a model,
we assume that certain effective class invariant pred-
icates, and operation postcondition predicates are op-
erational if they have the form
L implies R
where R is a formula such as f = e,
fincludes(e), fexcludes(e), fincludesAll(e),
fexcludesAll(e), ref.f = e, ref.fincludes(e),
ref.fexcludes(e), ref.fincludesAll(e),
ref.fexcludesAll(e). f is a feature name, pos-
sibly with a selector at(g) in the case of equality,
for some expression g, in the case of an ordered role
f. f is not a pre-form of a feature (ie, not x@pre for
some feature x). f is called the writable feature of the
constraint. L may be omitted. L is the test part of the
predicate, e the value part, ref the reference part, and
g the index part.
Other predicates are termed non-operational, they
may (in the case of postcondition predicates) consist
of a mixture of features in pre form and post form, all
259
Lano K. and Kolahdouz-Rahimi S. (2010).
SLICING OF UML MODELS.
In Proceedings of the 5th International Conference on Software and Data Technologies, pages 259-262
DOI: 10.5220/0002913202590262
Copyright
c
SciTePress
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 brsize() 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
The basic states of SM
C
A precondition/guard node pre
t
for each transi-
tion t of SM
C
A postcondition node post
t
for each transition t of
SM
C
.
Within each node pre
t
there are subordinate nodes for
each predicate of the guard of t, and each predicate of
the precondition of the operation op that triggers t.
Within each node post
t
there are subordinate nodes
for each predicate of the postcondition of t, and each
predicate of the postcondition of the operation op that
triggers t.
There is direct data dependency from a write oc-
currence d of a feature f within predicate p of a post-
condition node n, to a read occurrence d
of f within
predicate q of a node n
if either:
1. n = n
, p 6= q and both d and d
are f
2. n 6= n
, d is f, d
is f@pre in a postcondition node,
or f in a precondition node, and n
is reachable
from n along a path σ following the control flow
of the state machine, and there is no intermedi-
ate node m strictly between n and n
in σ which
contains a write occurrence of f in its predicates.
The dependency relation ρ
C
is then the transi-
tive closure of the union of the data-dependency and
control-flow relations on predicates.
The following algorithm is used to compute a
slice, with respect to a state s and set V of features,
from the graph G
C
. We associate a set V
x
of features
to each basic state node of the data and control flow
graph.
1. Initialise each V
x
with the empty set of features,
except for the target state s, which has the set V of
features.
2. For each transition t : s1 s2, add to V
s1
the set
ρ
1
op
(| V
s2
|) of features upon which V
s2
depends,
via the version of the operation op executed by
this transition (with precondition and postcondi-
tion formed from both the class and state machine
predicates for op and t).
Mark as included in the slice those predicates of
pre
t
, post
t
which are in ρ
1
C
(| ps |) where ps is
the set of predicates contained in post
t
which have
write occurrences of features in V
s2
. The set of
features (with pre removed) used in the marked
predicates are also added to V
s1
.
The second step is iterated until a fixed point is
reached. Each V
x
then represents the set of features
whose value in state x can affect the value of V in
state s, on one or more paths from x to s. (Parameter
values of operations along the paths may also affect V
in s). Let V
be the union of the V
x
sets, for all states
x on paths from the initial state of SM
C
to s. The set
of features retained in the slice S will be set equal to
V
.
The transformation we have described above does
produce a semantically correct slice S of a model M,
using the definition =
sem
of semantic equivalence, be-
cause, if σ is a valid history of M (ie, of the controller
class C of M), ending in the slice target state s, and V
a set of features of M, then:
σ is also a valid history of S, since the set of
states in the controller class state machine are the
same in both models, as are the preconditions and
guards of each transition in the models
the features retained in S are the union V
of the
sets V
x
of the features upon which V in s depends,
for each state x of any path to s, and hence V
contains V
x
for each state on the history σ, and in
particular for the initial state
since the values of the features of V
in the initial
state are the same for S and M, and the values
of operation parameters are also the same in the
application of σ to S and M, the values of V in s
are also the same in both models.
3 STATE MACHINE SLICING
Slicing can be carried out for UML state machines,
using data and control flow analysis to remove ele-
ments of the machine which do not contribute to the
values of a set of features in a selected state of the
machine (Lano, 2009a).
The following transformations are used to slice
state machines:
Delete states which cannot occur in paths from
the initial state to the selected state, and delete the
transitions incident to the deleted states.
Slice transition actions to remove assignments
which cannot affect the value of the variables of
interest in the selected state.
Delete transitions with a false guard.
Merge two transitions which have the same
sources, targets and actions. The guard of the re-
sulting transition is the disjunction of the original
guards.
Replace a feature v by a constant value e through-
out a state machine, if v is initialised to e on the
initial transition of the state machine, and is never
subsequently modified.
Merge a group K of states into a single state k if
SLICING OF UML MODELS
261
the states are connected only by actionless transi-
tions and all transitions which exit K are triggered
by events distinct from any of the events that trig-
ger internal transitions of K.
State machine slicing for behaviour state machines of
objects and operations has been implemented in the
UML2Web tool (Lano, 2008).
The above slicing approach can be extended to
systems which consist of multiple communicating
state machines, attached to linked objects, provided
that the communication dependencies M1 M2 (M1
sends messages to M2) form a tree structure.
4 SUMMARY
We have defined techniques for slicing of UML class
diagram and state machine models. These enable
models to be simplified and factored on the basis of
groups of features. Extension of this work to AND
composite states in state machines, and to activity di-
agrams and sequence diagrams is planned.
ACKNOWLEDGEMENTS
The work described here has been funded by the UK
EPSRC project SLIM.
REFERENCES
Bruckner, I. and Wehrheim, H. (2005). Slicing Object-
Z specifications for verification. In ZB 2005, LNCS
3455, pages 414–433. Springer-Verlag.
Harman, M., Binkley, D., and Danicic, S. (2003). Amor-
phous program slicing. Journal of Systems and Soft-
ware, 68(1):45 – 69.
Lano, K. (2008). Constraint-driven development. Informa-
tion and Software Technology, 50:406–423.
Lano, K. (2009a). Slicing of UML state machines. In AIC
’09.
Lano, K. (2009b). UML 2 Semantics and Applications. Wi-
ley.
Wu, F. and Yi, T. (2004). Slicing Z specifications. ACM
Sigplan, 39(8).
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
262