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 veriﬁcation.

Abstract:

This paper deﬁnes 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

speciﬁcation 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

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 simpliﬁes the calculation of the slice, and

means it is possible to detect speciﬁcation ﬂaws 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,

f→includes(e), f→excludes(e), f→includesAll(e),

f→excludesAll(e), ref.f = e, ref.f→includes(e),

ref.f→excludes(e), ref.f→includesAll(e),

ref.f→excludesAll(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

 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 br→size() ≤ n.

We will slice a class diagram speciﬁcation 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 speciﬁcation M is a ﬁnite 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

of C.

The deﬁnition 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 ﬁnal

state s of M is also a valid history with ﬁnal state s in

S, and if the values of the features in the slice set V in

S in the ﬁnal state of σ are equal to the values of these

features in M at the ﬁnal 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 ﬁrst 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 deﬁne 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

be the (non-reﬂexive)transitive closure of this

relation. Then the feature dependency relation ρ

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

• g 7→ f if g@pre 7→ f is in r

• 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

(| 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

as its

classiﬁerBehavior (Lano, 2009b), this state machine

deﬁnes what sequences of operations can be applied

to the object, and under what conditions. SM

can be

used as the basis of the data and control ﬂow graph

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

are:

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

260

• The basic states of SM

• A precondition/guard node pre

for each transi-

tion t of SM

• A postcondition node post

for each transition t of

Within each node pre

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

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 ﬂow

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 ρ

is then the transi-

tive closure of the union of the data-dependency and

control-ﬂow 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

. We associate a set V

of features

to each basic state node of the data and control ﬂow

graph.

1. Initialise each V

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

the set

−1

(| V

|) of features upon which V

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

, post

which are in ρ

−1

(| ps |) where ps is

the set of predicates contained in post

which have

write occurrences of features in V

. The set of

features (with pre removed) used in the marked

predicates are also added to V

The second step is iterated until a ﬁxed point is

reached. Each V

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

sets, for all states

x on paths from the initial state of SM

to s. The set

of features retained in the slice S will be set equal to

′

The transformation we have described above does

produce a semantically correct slice S of a model M,

using the deﬁnition =

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

of the features upon which V in s depends,

for each state x of any path to s, and hence V

′

contains V

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 ﬂow 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 modiﬁed.

• 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 deﬁned techniques for slicing of UML class

diagram and state machine models. These enable

models to be simpliﬁed 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 speciﬁcations for veriﬁcation. 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 speciﬁcations. ACM

Sigplan, 39(8).

ICSOFT 2010 - 5th International Conference on Software and Data Technologies

262