Lallchandani 2011

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,
VOL. 37,
NO. 6,
NOVEMBER/DECEMBER 2011
737
A Dynamic Slicing Technique

for UML Architectural Models
Jaiprakash T. Lallchandani and R. Mall, Senior Member, IEEE
AbstractThis paper proposes a technique for dynamic slicing of UML architectural models. The presence of related information in
diverse model parts (or fragments) makes dynamic slicing of Unified Modeling Language (UML) models a complex problem. We first
extract all relevant information from a UML model specifying a software architecture into an intermediate representation, which we call
a Model Dependency Graph (MDG). For a given slicing criterion, our slicing algorithm traverses the constructed MDG to identify the
relevant model parts that are directly or indirectly affected during the execution of a specified scenario. One novelty of our approach is
computation of dynamic slice based on the structural and behavioral (interactions only) UML models as against independently
processing separate UML models, and determining the implicit interdependencies among different model elements distributed across
model views. We also briefly discuss a prototype tool named Archlice, which we have developed to implement our algorithm.
Index TermsSoftware architecture, UML, architectural metamodel, dynamic slicing, impact analysis.
INTRODUCTION
HE
architecture of an object-oriented software system

defines its high-level design structure [1]. With increased complexity and size of software products [10],
architectural design models have become important design
artifacts. Evaluation, understanding, and testing a design
solution constitute a few of the important uses of an
architectural design model. An architectural design model
allows an architect to reason about various system properties at a higher level of abstraction. In recent times, Unified
Modeling Language (UML) is extensively being used for
representing the architectural models of software systems
[12], [13]. UML provides a wide range of visual artifacts to
model different aspects of a system.
The task of analyzing UML models poses a challenge
since the system information is distributed across several
model views. As a result, the analysis of the impact of a
change to one model on other model parts is a nontrivial
problem. For example, if an operation returning a value
changes, then several classes may get affected either due to
the variable being used in guard conditions in various
interactions or because of operation invocations.
With increase in product sizes and complexities, UML
models themselves tend to become large and complex and
may involve thousands of interactions involving hundreds
of objects. For such large architectures, it becomes exceedingly difficult to understand and analyze these models.
Moreover, it becomes tedious on one hand and equally
valuable on the other to determine the impact of a certain
change to one model element on other model parts. For large
architectures, determining the impact of a change would
. The authors are with the Department of Computer Science and

Engineering, Indian Institute of Technoloqy Kharagpur, Kharagpur
721302, WB, India. E-mail: {jtl, rajib}@cse.iitkgp.ernet.in.
Manuscript received 17 Mar. 2009; revised 27 Nov. 2009; accepted 20 Mar.
2010; published online 29 Dec. 2010.
Recommended for acceptance by A. Wolf.
For information on obtaining reprints of this article, please send e-mail to:
tse@computer.org, and reference IEEECS Log Number TSE-2009-03-0058.
Digital Object Identifier no. 10.1109/TSE.2010.112.
0098-5589/11/$26.00 2011 IEEE
require taking into account the various types of dependencies that might exist among different model elements. This
analysis can become even more complex when one tries to
consider the relations among objects that get dynamically
formed and dissolved during a run of the system. On the
other hand, development of an impact analysis technique can
help understanding, testing, reengineering, maintenance,
and reuse of large software architectures.
In this context, researchers have proposed using dynamic program slicing techniques to decompose large
architectures into manageable portions. These techniques
not only facilitate comprehending large architectures, but
also help perform impact analysis and reliability prediction
based on architectural models [19], [30], [45], [46]. Besides,
architecture model slicing can also be used to compute
various types of metrics to characterize software architectures. Static slicing techniques can also be used for similar
purposes, but the computed static slices would be relatively
conservative. This poses a serious limitation on the
applicability of such static model slices.
1.1 Program Slicing

Slicing [31], [37], [40], [41], [42] is a technique for focusing
on certain aspects of a programs behavior and removing all
other parts of code not concerned with this behavior.
Alternatively, we can state that slicing is a technique to
identify program sections relevant to a slicing criterion. This
suggests that the slicing criteria have a key role in slice
computation based on identifying dependence relations
among the parts of the program.
Weiser [40], [42] was the first to introduce the concept of
a static slice. A static program slice s, of a program p, is
constructed with respect to a slicing criterion (V,i),
where V is a set of variable identifiers and i is a program
point. Statements in p that cannot affect the values of V
when the next statement to be executed is at point i may
be removed from p to form s. In contrast, Korel and Laski
[20] defined a dynamic program slice that is computed
with respect to a specific input in V and is only valid for
Published by the IEEE Computer Society
738
VOL. 37,
NO. 6,
that input. A dynamic slicing criterion was defined to

consist of a set of variables, a line number in the program
code and a sequence of input values.
1.2 Slicing Software Architectures

Architectural slicing is a decomposition technique to extract
and identify relevant model parts (or fragments) or related
elements across diverse model views. In this context, a
slicing technique for software architectures needs to take
into account various classifiers and their relations and
objects and their interactions. This is due to the fact that a
UML metamodel extends support to describe structural and
behavioral aspects of an architecture. For instance, the
structural models (e.g., class diagrams) are used to describe
various relations among classes, such as aggregation,
association, composition, and generalization/specialization.
On the other hand, the behavioral models (e.g., communication and sequence diagrams) are used to depict a sequence of
actions in an interaction, through which a use case is
realized. Traditional slicing is usually performed solely
based on data and control dependency relationships existing
among program statements. However, in architectural
slicing of UML design models, several other types of model
relations, such as class-class, class-operation, operationoperation, class-object, object-object, etc., need to be taken
into account. Therefore, to perform architecture slicing
efficiently, it appears necessary to first formulate an
appropriate intermediate representation that can capture
various types of dependence relationships that may exist
among classes, subclasses, operations, and attributes, and
call sequences.
1.3 Contributions
The major contributions of our present work to dynamic
slicing of UML architectural models are the following:
1.
2.
Intermediate representation: We propose an intermediate representation for a software architecture by

extracting relevant information from UML structural
and behavioral models into a single system model.
This model represents various types of dependencies existing among different model elements. We
have named this representation the Model Dependency Graph (MDG). We incrementally construct an
MDG by considering the UML behavioral model
along with the information from the structural
model. It should be noted here that our MDG
representation only models object interactions as
behavioral parts. However, representation of other
behavioral modeling features, such as state-machines or activities, has been kept pending as a
future work.
Dynamic slicing algorithm: We have named our
proposed algorithm Dynamic Slicing of UML Architectural Models (DSUAM). Our slicing algorithm is
based on traversing the edges in the MDG for any
given slicing criterion. Through MDG traversal,
DSUAM identifies the relevant model parts from
an architecture based on the dependencies among
them to compute a dynamic architectural model
slice. A novelty of DSUAM is its computation of a
slice based on the combination of structural and
Fig. 1. Activity diagram of our dynamic slicing technique.
behavioral information from any UML model, and

finding the implicit interdependencies among different model elements distributed across various
model views. This is in contrast to the related work,
where slicing is based on individual UML models.
Our technique to compute a dynamic slice from
UML models is schematically shown in Fig. 1, using
an activity diagram.
3. Performance: Our algorithm identifies the dependencies among model elements as and when they
arise and cease during execution of a scenario. Such
an approach is time and space efficient and
completely does away with the necessity to maintain
a trace file. As a result, our technique eliminates the
slow file I/O operations that occur in conventional
techniques while accessing a trace file. This improves the response time of slicing commands.
4. Applications: We show the use of computed
dynamic architectural slices in regression testing,
reliability prediction, impact analysis, etc., as some
of the important applications of the DSUAM.
Finally, as a proof of concept, we present a tool Archlice,
which computes a dynamic slice for UML architectural
models based on the intermediate representation MDG and
our proposed DSUAM algorithm. Archlice supports both
dynamic as well as static analysis of the Extensible Markup
Language (XML) representation of UML models.
1.4 Paper Outline

The rest of this paper is organized as follows: The next section
reviews related work. Section 3 presents a UML metamodel
for our MDG representation. Our intermediate representation MDG is discussed in Section 4. Section 5 presents an
overview of some basic concepts relevant to our discussion
along with a few definitions. Section 6 presents our algorithm
for computing a dynamic architectural model slice along with
an example to illustrate the working of our algorithm.
Section 7 discusses an implementation of our slicing
algorithm along with some experimental results. Section 8
outlines some of the important applications of our slicing
algorithm in some key areas of software engineering. Section 9
compares our work with related work, and Section 10
concludes the paper.
RELATED WORK
In this section, we briefly review the reported work on

architectural and model slicing. Most of the works reported
LALLCHANDANI AND MALL: A DYNAMIC SLICING TECHNIQUE FOR UML ARCHITECTURAL MODELS
in the literature address development of techniques for

slicing the architectural description of a system given in
different architecture description languages (ADLs), such as
Aesop, C2, Darwin, Meta-H, Rapide, UniCon, and Wright
[2]. Research work on slicing UML architectural models has
scarcely been reported in the literature, though UML is
being used as an ADL [28], [29].
Zhao [43] investigated a novel dependence analysis
technique, called architecture dependence analysis, to
support software architecture development. Though his
work considered Acme ADL, he has shown his architecture
dependence analysis approach to be independent of any
specific ADL.
Zhao introduced a static architecture slicing technique
[44] which operates by removing unrelated components
and connectors and ensures that the behavior of a sliced
system remains unaltered. The work reported by Zhao in
[44] is an extension of his earlier work reported in [43] and
is based on Wright ADL [2].
Kim introduced an architectural slicing technique called
dynamic software architecture slicing (DSAS) in [19]. Kims
work is able to generate a smaller number of components and
connectors in each slice as compared to [44]. This is especially
true in situations where a large number of ports are present
and their invocation can change the values of some variables
or the occurrence of certain events.
Korel et al. [21] present an approach to slicing statebased models, such as EFSMs (Extended Finite State
Machines). They present two types of slicingdeterministic
and nondeterministic slicing. Their approach also includes
a slice reduction technique to reduce the size of a computed
EFSM slice. Korel et al. [21] also report a tool that
implements their slicing technique for EFSM models.
Kagdi et al. [15] introduce the concept of model slicing as
a means to support maintenance through the understanding, querying, and analyzing large UML models. Kagdi et al.
construct model slices from UML class models. Their slicing
approach extracts parts of a class diagram in order to
construct submodels from a given model of a system.
However, class models are devoid of explicit behavioral
information and depict only structural behavior.
Wu and Yi [11] develop a new kind of dependence
analysis method for UML class diagrams. Their approach
uses different class relationships and defines a set of
dependence relations corresponding to the relations among
classes. Then, based on these dependence relations, they
construct a dependence graph from a class diagram. Their
work mainly focuses on the construction of a representation
model for class diagrams. Their model can be used in two
important applications, viz., slicing and measurement
coupling. As their graph representation has been derived
from class diagrams alone, the techniques usefulness is
limited to understanding only the static aspects of a
modeled system.
Ojala [33] uses the slicing techniques (see, for example, the
survey [37]) on UML state-machines, and implement a statemachine slicer. His slicing of state-machines is done in three
parts: First, he constructs a control flow graph (CFG) from the
state-machines, then he calculates various dependencies
between the CFG nodes, and in the last part, he computes the
739
slice using these calculated dependencies and the available

CFG. Further, in his slicer implementation he removes
triggers, guards, and effects that do not affect the functionality of interest from the state-machines, and applies his
computed slices to ease the model checking tasks.
Wang et al. [39] present a method for slicing hierarchical
automata, with their properties to be verified as a slicing
criterion. Their method is based on representation of UML
statecharts by hierarchical automata for modeling dynamic
aspects of reactive software. Based on the analysis of
characteristics, such as hierarchy, concurrency, and synchronization, they specify a set of dependence relations using the
hierarchical automata representation. The slicing algorithm
for statecharts is then applied on this representation. An
important feature of Wang et al.s algorithm is its ability to
remove the hierarchies and concurrent states, which are
irrelevant to the properties of the hierarchical automata.
Moreover, it efficiently reduces the state space in model
checking UML statecharts.
Langenhove [26] presents an algorithm for reducing the
number of interference dependencies used in slicing
statecharts with concurrent states. This approach considers
data dependencies resulting from the definition and use of
variables that are common to parallel executing statements,
as interference dependencies. The key idea to improving the
precision of interference dependencies is to define a
happens-before relation between states and transitions of
orthogonal regions. He achieves this by exploiting the
internal broadcasting mechanism, and at the same time
maintaining the statecharts execution semantics. Moreover,
this approach reduces the size of statechart models, which
improves the efficiency of model checking.
Bae et al. [3] present a slicing algorithm for extracting
diagram-specific metamodels from the UML metamodel.
Their approach is based on managing the complexity of the
UML metamodel by modularizing the metamodel into a set
of small metamodels for different UML diagram types. In a
way, a single UML metamodel of a large size is decomposed into a number of small metamodels.
Koskinen et al. [22] develop a technique that synthesizes
statechart diagrams from the UML sequence diagrams.
Their technique implemented as a tool, Minimally Adequate Synthesizer (MAS), can also synthesize sequence
diagrams into the manually constructed statechart diagrams. In addition, their technique can be used in understanding the statechart diagrams with the help of
membership and equivalence queries.
Briand et al. [9] present a methodology to handle the
impact analysis and change management of analysis and
design documents in the context of UML-based development. Though this work does not directly address model
slicing, we refer to it here as it considers an important
application area for slicing. For their variation of the UML
metamodel, they use OCL constraints to formally define the
consistency rules between UML diagrams, automated
change identification and classification between two versions of a UML model, as well as the impact analysis rules.
They also define a distance measure to sort impacts,
according to their likelihood of occurrence in the code,
740
VOL. 37,
NO. 6,
Fig. 2. Class diagram for the MDG metamodel.
based on the distance between changed model elements

and the impacted elements.
FRAMEWORK OF OUR MDG METAMODEL
In this section, we present an overview of our intermediate

representation for a UML model, which we have named
MDG. We first discuss the key elements of MDG, and then
outline the representation of a generic system using MDG.
A more detailed discussion on the relationships among
different elements of MDG is given in Section 4.
3.1 Elements of MDG

A class diagram of an MDG has been shown in Fig. 2. It
gives an overview of the elements involved in the structural
design of an MDG metamodel. Each instance of an MDG is
composed of one or more nodes of different types along
with one or more edges representing different types of
dependencies, as shown in the class diagram of Fig. 2. We
discuss how structural and behavioral UML models can be
used together to realize an MDG in a later section.
In the following, we list the two different types of
elements of an MDG. First are the nodes in the MDG that
represent different UML model elements. Second are the
edges in the MDG that represent the dependencies and
relations among these model elements. The various MDG
nodes can be listed as:
1. Class Access (CA) node,
2. Operation Access (OA) node,
3. Attribute (AT) node,
4. Parameter (PR) node,
5. Return (RT) node,
6. Predicate Class (PC) node, and
7. Interaction (IT) node.
Moreover, the edges representing the dependencies among
these seven nodes types are as follows:
1. member dependence edge,
2. operation dependence edge,
3. relationship dependence edge,
4. data dependence edge, and
5. message dependence edge.
The different metaclasses depicted in Fig. 2, along with their
relations, form the metamodel for MDG. The next section
gives an overview of the relation between elements in MDG
based on the corresponding UML model elements.
Fig. 3. One-to-one mapping of UML model elements to their

corresponding nodes in the MDG representation.
3.2 UML Model and Its MDG Representation

Fig. 3 depicts a one-to-one mapping of different kinds of
UML elements into corresponding kinds of MDG node
elements. A class (see Fig. 3, entry A) from the UML model
is represented using a class access (CA) node in the MDG. On
the other hand, an attribute (AT) node represents a class
attribute (see Fig. 3, entry B), and an operation access (OA)
node represents a class operation (see Fig. 3, entry C). A
CA node (that is a dependee node) is connected to every OA
and AT node (which are the dependent nodes) of the
corresponding class through dependence edges. The formal
parameters of a class operation are represented using
parameter (PR) nodes (see Fig. 3, entry D), while the return
values are represented using return (RT) nodes (see Fig. 3,
entry E). An OA node (that is a dependee node) is connected
to PR and RT nodes (which are the dependent nodes) by
dependence edges. Also, an RT node (that is a dependent
node) may be connected to an AT node (which is a
dependee node) by a dependence edge. In addition to the
representation of a class and its features, the combined
fragments and interaction occurrences used in an interaction are also represented in the MDG.
The combined fragments in UML define conditional
structures in interactions. And, every combined fragment
consists of an interaction operator, one or more interaction
operands, and an optional guard condition. Furthermore,

combined fragments are used to group sets of messages
together to show conditional flows in an interaction [6], [14].
Commonly used combined fragments are alternatives (or
alt), options (or opt), and loops (or loop) [38]. As depicted in
Fig. 3 (see entry F), for every UML model element, such as a
combined fragment, the corresponding element in the MDG
representation is a predicate class (PC) node. It should be
noted here that the possibility of a PC node exists only to
represent such a combined fragment from an interaction
through a CA node along with its subsequent conversion
into a PC node.
On the other hand, a feature known as interaction
occurrence (or interaction use) has been introduced in UML2
[38]. An interaction occurrence is an interaction that is
referenced in another interaction frame. A use of interaction
occurrences is to take common content from one interaction
and reuse it in another [6]. To represent such interaction
occurrences from the UML model into its MDG representation (see Fig. 3, entry G), an interaction (IT) node is used.
The exact details of the dependency types and their
semantics are discussed in Section 4.
3.3 System Representation Using MDG

We now discuss how the model elements of a UML model
can be represented using the different elements of an MDG.
This view presents a system modeled in terms of UML
classes and interactions into its corresponding MDG
representation. The exact details of such systems are given
in Section 7.2 to illustrate the working of our dynamic
slicing algorithm using different UML models.
Let a UML model consist of different instance specifications CL1 . . . CLn, and every class has i attributes and
m operations. The MDG of such a UML model can be
described as follows:
.
Representation of model elements:
The classes are represented by class access (CA)

nodes CACL1 . . . CACLn .
The attributes of every class CL(n) are represented by attribute (AT) nodes AT1 . . . ATi .
The operations invoked for every class CL(n)
are represented by operation access (OA) nodes
OA1 . . . OAm .
The k parameters 1 . . . k in an operation invocation are represented by parameter (PR) nodes
PR1 . . . PRk .
The return parameters for m operation invocations are represented by return (RT) nodes
RT1 . . . RTm .
Representation of relations among model elements:
-
All the respective AT and OA nodes representing

the attributes and operations of the class CL(n)
are connected to the class access (CA) node
CACLn using dependence edges.
Similarly, the parameters and return values
represented using PR and RT nodes of every
invoked operation m are connected to the operation access node OAm through dependence edges.
741
In addition, the various interactions represented

in a system model form the different dependencies in the MDG using the dependency semantics discussed in Section 4.3.
MODEL DEPENDENCY GRAPH (MDG)
MDG represents both the structural as well as the behavioral

aspects of a modeled system. The process of constructing an
MDG involves combining the behavioral model information
along with the structural information using an incremental
process and is discussed in the next section. MDG thus
provides a coherent view of all system scenarios. It is, in fact,
not very different from a UML model, but makes interdependencies existing among models explicit.
An MDG consists of different types of nodes that may
either correspond to model elements based on the classes
and their relationships or objects and their interactions.
Every dependence represented in an MDG has a pair of
classes, attribute(s), operations(s), and its parameters and
return values associated with it. All such CA, AT, OA, PR,
and RT nodes that represent these classes and its features
are added using the class information to the MDG. In
addition, an IT node is added to the MDG in case an
interaction occurrence is used in a scenario. Similarly, a
PC node is added to the MDG when an interaction
possesses a combined fragment.
The different nodes in an MDG are interconnected using
two categories of dependence edges as follows:
Edges of the MDG can be based on the classes and
their relationships. Different types of edges in this
category include member dependence, operation
dependence, data dependence, and relationship
dependence edges.
. Edges of the MDG can be based on the objects and
their interactions. We call all such edges message
dependence edges. However, message dependence
edges can be of the following types: call dependence,
return dependence, data dependence, control dependence, and intersequence dependence edges.
Both the above categories of dependence edges have data
dependence edges. The former data dependencies are based
on the information in anchored notes in the structural
models, and the latter are due to the messages in the
behavioral models. Fig. 4 depicts a mapping of different
combinations of UML elements that form the corresponding
kinds of MDG edge elements.
.
4.1 MDG Nodes

In the following, we define the different elements of an MDG:
.
.
.
.
Class Access (CA) nodeA CA node is defined for

every class in the UML architectural model.
Attribute (AT) nodeAn AT node is defined for
every class attribute.
Operation Access (OA) nodeAn OA node is defined
for every operation of a class.
Parameter (PR) nodeA PR node is defined for every
operation parameter specified in an operation
signature.
742
VOL. 37,
NO. 6,
of UML2 superstructure specification [38], when a combined

fragment has a guard condition associated with an object of a
class CLn in an interaction, it is represented by a predicate
class (PC) node PCCLn in the MDG. The predicate class (PC)
node PCX represents the corresponding alt combined
fragment used in an interaction depicted in entry F of Fig. 3.
In addition, if an object of a class CLn has an
interaction occurrence associated with it, then it is represented as an interaction (IT) node in the MDG. For
instance, an interaction occurrence referred to by X in the
lifeline of an anonymous object of ClassY is represented
by an IT node labeled ITX in entry G of Fig. 3. Moreover,
for every class that possesses a constructor (create) or a
destructor (destroy) operation or both, the corresponding
MDG represents such constructor and destructor operations using two special operation access (OA) nodes, OAc
and OAd , respectively. For example, ClassE has one such
operation, namely, create_E() and ClassF has an
operation destroy_F() in Fig. 5a. The corresponding
MDG shown in Fig. 6 represents these operations using
two OA nodes viz., OAc associated with CAE , and OAd
associated with CAF , respectively, through member dependence edges.
Fig. 4. Mapping of UML model elements to their corresponding edges in

the MDG representation.
Return (RT) nodeAn RT node is defined for every

return parameter specified in an operation signature.
. Predicate Class (PC) nodeA PC node is defined for
every combined fragment used in an interaction.
. Interaction (IT) nodeAn IT node is defined for
every interaction occurrence used in a scenario.
We now briefly present our terminology pertaining to
predicate class (PC) and interaction (IT) nodes. In the context
.
4.2 MDG Edges

Member dependence edges (see Fig. 4, entry H) represent the
class membership of operations and attributes, while operation dependence edges (see Fig. 4, entry I) represent the
dependence of the call parameters and return values (if any)
on an operation. Data dependence edges (see Fig. 4, entry K)
represent flow of data among statements of a class operation.
Data dependencies arise when the class operations, their
parameters, and return values directly or indirectly make use
of the class attributes. In addition, data dependence edges
also represent the effect of calling parameters on the return
value of an operation. Relationship dependence edges (see
Fig. 4, entry J) represent how a class is related to other classes
or how an instance of a class is related to the other class
instances. It is to be noted that an MDG represents each class
along with its features such that the interdependencies
among them get easily identified in the process of slice
computation. At the same time, an MDG does not represent
class relations in any different way compared to its
corresponding class model. For example, the arrow style
for representing generalization, aggregation, and composition relations using the relationship dependence edges in the
MDG exactly matches the UML notations used to represent
these class relationships. However, the association relation is
not represented in the MDG directly. This does not imply that
the association relations in the structural model are not
addressed in the MDG. In fact, the association used to express
structural connections among the classes and their manipulation (e.g., create and destroy operations) are represented
in the MDG when they result in message transfers in an
interaction. An extension to this is an association relation
representing classes which are likely to communicate with
other classes due to an operation invocation. The dependencies arising out of such operation invocations are available
from the behavioral models and represented from the
corresponding interactions in the MDG.
Message dependence edges represent flow of messages
among objects. Each message dependence edge is annotated
743
Fig. 5. A partial view of an example UML model. (a) Classes depicted using a class diagram, (b) and (c) interactions depicted using two sequence
diagrams.
with a label. The kth message in an interaction i is

represented by a message dependence edge annotated by
Ii k in an MDG. If a message transfer between classes
involves an operation call (implicit or explicit), we represent
this message dependency by a call dependence edge (see Fig. 4,
entry L). If a message transfer is a self-call (a message from an
object to one of its own operations), the corresponding
message dependency is also represented by a call dependence
edge. When an object instantiates another object, it is also
represented as a call dependence edge because it involves an
implicit call to the constructor operation of the class. On the

other hand, a message transfer representing a value return on
account of an operation invocation by an object is represented
as a return dependence edge (see Fig. 4, entry L). Further, objects
of classes in an interaction can have a type of definition-use
relationship. The concept of definition-use is commonly used
in the program slicing paradigm to identify data dependencies indicating that a variable defined at a particular point (or,
line number) has been used, or referred to, at some later stage
(or, line number) during the execution of that program [42].
744
VOL. 37,
NO. 6,
corresponding notations for each of the dependencies and

their source in the UML model are depicted in Fig. 7.
4.4 Definition of MDG

In this section, we give in the following a formal definition of
MDG based on our discussion about the nodes and edges in
the MDG and their corresponding dependency semantics.
Definition 1 (Model Dependency Graph (MDG)). An
MDG GM of an architectural model M is a directed multigraph
NM ; EM , where NM is a set of nodes representing the model
elements and EM NM NM is the set of edges representing
dependencies among model elements. An MDG may contain
the following seven types of nodes:
1. Class Access (CA) node,
2. Operation Access (OA) node,
3. Attribute (AT) node,
4. Parameter (PR) node,
5. Return (RT) node,
6. Predicate Class (PC) node, and
7. Interaction (IT) node.
An MDG may contain the following five types of edges:
Fig. 6. MDG representation of the example UML model of Fig. 5.
We consider an extension of such a definition-use concept in

the context of UML models to find out data dependencies in
an interaction. Based on this, we have a dependency
considering a pair of associated objects from an interaction
model to hold a comparable relationship between them if
their corresponding classes are related in the class model.
This case arises when a definition of a class attribute and its
corresponding use are across different objects in an interaction. It should be known that interacting objects can have
information on such definition and use of attributes and an
MDG represents such dependencies between objects of
classes using a data dependence edge (see Fig. 4, entry K).
Moreover, the interaction operands in a combined fragment
may be associated with an object, resulting in a predicate class
(PC) node in the MDG. The corresponding messages grouped
in such combined fragments form a control dependency on that
PC node, and are represented using a control dependence edge
(see Fig. 4, entry M) in the MDG. In addition, an object may
refer to other interactions using an interaction occurrence. Such
an interaction occurrence forms an IT node and possesses a
dependence relation with other MDG nodes. This results in
another type of message dependency, termed an intersequence
dependency in the MDG. Such intersequence dependence edges
(see Fig. 4, entry N) are used to represent a dependency of a
scenario on some interaction.
4.3 Dependency Semantics in MDG

The edges in the MDG follow certain semantics based on
the pair of nodes, which are connected to form a
dependence edge. These semantics are based on the type
of model elements, and their representations in the UML
model. We represent an edge in the MDG using a node pair
as (from node; to node). Moreover, the from node is said to
be dependent on the to node, with the dependence
direction toward the to node in the MDG. The different
dependency semantics used in the MDG along with the
1.
2.
3.
4.
5.
relationship dependence edges,

member dependence edges,
operation dependence edges,
data dependence edges, and
message dependence edges.
For any pair of nodes u; v 2 NM , there exists an associated

edge u; v 2 EM , v is a successor of u, and u is a predecessor
of v, such that there is a dependency of u on v, iff any one of
the following conditions holds in the MDG GM of an
architectural model M:
.
Both of the nodes in the node pair are either

CA nodes or PC nodes, and there exists a relationship
dependence from the former to the latter.
One of the nodes in the node pair is either an
OA node or an AT node and the other is a CA node,
and there exists a member dependence from the former
to the latter.
One of the nodes in the node pair is either a PR
node or an RT node and the other is an OA node,
and there exists an operation dependence from the
former to the latter.
One of the nodes in the node pair is either a CA node or
a PC node or an AT node or an OA node or a PR node or
an RT node and the other is an AT node, and there
exists a data dependence from the former to the latter.
There can exist a message dependence due to one of the
following:
-
Both or either of the nodes in the node pair are CA

nodes or PC nodes or OA nodes, and there exists a
call dependence from the former to the latter.
One of the nodes in the node pair is a CA node or
a PC node or an OA node or an AT node and the
other is an RT node, and there exists an return
dependence from the former to the latter.
One of the nodes in the node pair is a CA node
or a PC node and the other is a PC node, and
745
Fig. 7. Dependency semantics in MDG and their corresponding notations.
there exists control dependence from the former

to the latter.
One of the nodes in the node pair is a CA
node or a PC node and the other is an IT
node, or vice versa, and there exists an
intersequence dependence edge from the former
to the latter.
4.5 An Example MDG

In this section, we explain the construction of the MDG for
the example UML model given in Fig. 5. Fig. 6 shows the
MDG representation obtained using the information extracted from the given UML model.
Let the classes in the given model be represented using

the class diagram of Fig. 5a. And let the two interactions,
labeled I1 and I2 , in this model, be represented using the
sequence diagrams of Figs. 5b and 5c, respectively. Let us
assume that interaction I1 has been arbitrarily selected prior
to I2 . In this case, the incremental graph construction
process discussed in Section 5.5 yields the MDG of Fig. 6.
The example model has seven classes, ClassA . . . ClassG,
but the interactions modeled using I1 and I2 use objects of
only six classes, ClassA . . . ClassF. None of the objects of
ClassG participate either in I1 or I2 . Therefore, the
corresponding class access node CAG is not represented in
746
the MDG of Fig. 6. Moreover, I2 contains an interaction

occurrence eg_sd in the lifeline of anonymous object of
ClassF, and has been represented as interaction (IT) node
IT21 in the MDG of Fig. 6.
The MDG of Fig. 6 has nine call dependence edges
annotated with labels I1 1, I1 2, I1 3, I1 4, I1 6, I1 7,
I1 9, I1 10, and I1 11. An edge PCA ; BOA1 forms a call
dependence edge and is annotated with label I1 2 in the
MDG. Here, OA1 denotes the operation access (OA) node for
the operation opr_b1() in ClassB. The other call dependence edges from I2 are similarly represented by I2 1, I2 2,
I2 5, I2 7, I2 9, and I2 10, respectively, in the MDG.
The edge PCA ; CRT1 represents a return dependence
edge and has been labeled I1 5 in the MDG. Here, RT1
denotes the return (RT) node representing the return value
of operation opr_c1() in ClassC. The other return
dependence edges in MDG of Fig. 6 have been annotated
with labels I1 8, I2 4, I2 7, and I2 9, respectively.
It can be seen in the MDG of Fig. 6 that all the message
transfers from interactions I1 and I2 have been represented
with distinct labels. From I1 , they are represented by
I1 1 . . . I1 11 in the MDG, and from I2 , they are
represented by I2 1 . . . I2 10, as shown in the MDG of
Fig. 6. These distinct labels to represent the different
message transfers from various interactions into the MDG
are used for identifying the unique system scenarios in
MDG during its traversal for slice computation.
REQUIREMENTS, CONCEPTS, AND DEFINITIONS
In this section, we first present certain aspects of structural

and behavioral models relevant to our work and then discuss
a few concepts related to MDG. We then present some
important definitions that have been used in our architectural model slicing technique discussed subsequently.
5.1
Presumption on the Use of Views of a UML

Model
Our dynamic slicing technique considers both structural and
behavioral UML models. Though our technique considers
both these models, at certain instances, for simplicity of
understanding we base our discussion by taking class and
sequence diagrams separately as examples for structural
and behavioral models. To avoid any ambiguity, the
discussion on the MDG metamodel presented in this paper
is entirely based on specific kinds of model elements as
defined using the standard UML2 language specification.
This does not limit our technique to specific diagram types
or system views, but considers the different model elements
given in UML2 superstructure [38] as a specific use of our
approach. Our subsequent discussions are based on this fact.
5.2
Requirements for Customizing Notes in

Structural Models
In UML, a note can be anchored with every model element,
irrespective of its type. However, the attached notes can
contain any text for which there is no formal syntax. To be
able to automatically process the information present in
attached notes, we define certain syntax rules and semantics
for the UML notes. This can help to automatically identify
relevant data dependencies from the text present in the notes.
We define a simple set of rules for writing notes. The text in
the notes can either start with a word uses or invokes,
VOL. 37,
NO. 6,
and the words in the text followed by uses and

invokes are separated by a comma. We use notes to
represent the following types of information: 1) An operation
can use one or more class attributes. 2) An operation can
contain an invocation to one or more class operations.
We now define the semantics of the notes anchored to an
operation of a class:
If the text string representing a note begins with the
word uses, then the rest of the words in the text
string represent the class attributes on which an
operation is data dependent.
2. If the text string representing a note begins with the
word invokes, then the rest of the words in the
text string represent the operations that are invoked
by an operation anchored with the note.
In Fig. 5a, a note containing the description uses
attrib_c1 has been shown anchored to an operation
opr_c2() in ClassC. This information given in the note
is processed to extract the data dependency of opr_c2()
on attrib_c1 and represented in the MDG. In the rest
of the paper, we assume that notes are used to represent
the information related to the usage of data in the system
being modeled.
1.
5.3 Naming Requirements for Interactions

We have shown two example interactions using sequence
diagrams comprising rectangles to depict objects (or lifelines) in the UML model of Fig. 5. The arrows connecting
the objects represent messages, and are labeled with their
names, sequence numbers, and arguments. It also depicts
the use of the combined fragments alt and loop in Fig. 5b.
However, consider a system having multiple scenarios, and
the same are modeled using different interactions. In such
systems, we identify each interaction by an arbitrary label
assigned to it. Also, once an interaction is assigned a label, it
is not changed. Moreover, no two interactions can be
assigned the same label. As an instance, for an example
system model given in Fig. 5, these interactions may be
labeled as I1 and I2 , respectively.
Further, every scenario in an interaction can be labeled
Sjk , indicating the kth scenario in an interaction Ij . Each
scenario Sjk is comprised of message transfers among
objects involved in execution of the kth scenario in Ij . Each
message transfer in scenario Sjk can be represented by a
triplet hMessageId; F romObject; T oObjecti. It is to be
noted that the numbering of scenarios is not meant to
implicitly introduce an ordering on scenarios described by
an interaction. We have used integers as identifiers of the
scenarios without any implicit ordering.
The three scenarios in interaction I1 of Fig. 5b are identified
as S11 , S12 , and S13 , respectively, in Fig. 8. And, each of the
scenarios S11 , S12 , and S13 is comprised of 9, 8, and 8 triplets of
the form hMessageId; F romObject; T oObjecti, respectively.
As an example, the first triplet in S11 is h1; : ClassA; : ClassBi
indicating a message transfer from an object of ClassA to an
object of ClassB.
5.4 Use of Scenarios in Slice Computation
We define an operation MessageList in the following. To
compute a slice for a specified scenario, discussed in the
747
Fig. 8. Four scenarios for the interactions in the UML model of Fig. 5.
next section, the exact messages involved during the

execution of a scenario are identified using MessageList
prior to the traversal of MDG.
Definition 2 (MessageList(scenario)). Given a scenario Sjk
for any interaction Ij , the operation MessageList(Sjk )
computes the list of message transfers involved during the
execution of the scenario Sjk in Ij .
For a specific scenario S12 in the interaction I1 of Fig. 5b,
the list of message transfers participating in S12 can be
computed using the operation MessageListS12 as follows:
MessageListS12 f1; 2; 3; 7; 8; 9; 10; 11g
fI1 1; I1 2; I1 3; I1 7; I1 8; I1 9;
I1 10; I1 11g:
Fig. 9. The process of incremental construction of MDG from a UML

model.
Definition 3 (Traversal Path). Let N; Ndr ; NX ; NY ; NZ be the

nodes in MDG GM . Suppose Ndr be one of the directly reachable
nodes from N. A path P in GM is a Traversal path when
transitively traversed under the following conditions:
1.
The result obtained using the operation MessageListS12

can be verified based on the messages listed for scenario S12
in Fig. 8.
2.
5.5
3.
Incremental Extraction of Information from UML

Models
We now briefly discuss how the information from the
structural and behavioral models can be extracted to
construct an MDG. The incremental process of extracting
model information is schematically shown in Fig. 9. The
extraction process is carried out over many steps. The exact
number of steps may vary depending on the number of
interactions present in a given UML model. In Step-1, an
arbitrarily selected interaction Ii along with the information
present in structural model is used to construct a partial
MDG, MDG1 . Next, the process carried out in Step-1 is
repeated during Step-2 on another arbitrarily selected
interaction Ij . This step also updates MDG1 constructed in
previous step, resulting in a partial MDG, MDG2 . The same
process is repeated till all the interactions have been
considered. For extracting information from a model with
n interactions, the Step-n will result in MDGn . The MDGn
constructed after n steps is the final MDG obtained at the
end of incremental extraction.
Interestingly, irrespective of the order of selection of
interactions, the extraction process always yields the same
MDG. A formal proof of this has been reported in [23].
5.6 MDG Traversal Policy
In this section, we first define two important terms traversal
path and traversal point in the following:
N is the start node, such that an outgoing edge N; Ndr

is the first edge traversed in P.
For nodes NX , NY in P such that edge Ndr ; NX exists,
and condition 1 holds iteratively on NX and on one of
its directly reachable nodes along with some other
transitively reachable node NY .
NZ is the end node with an out-degree zero in P, such
that NY ; NZ is the last edge traversed in P.
Using the above definition, a path in MDG is a traversal

path if its start node is a CA (or PC) node. However, no such
condition about the node type is applicable on intermediate
nodes, or the last node in the traversal path.
Definition 4 (Traversal Point). Given a traversal path P in
MDG GM . A node in GM participating in more than one
traversal paths is referred as a Traversal point.
We illustrate the concepts of traversal path and traversal
point using an example given in Fig. 10. One path which can
be directly traversed is N ! N1 ! NX ! NY ! ! NZ ,
which is a traversal path such that N is a start node, N1 is
one of the directly reachable nodes of N, and NZ is the end
node. Moreover, this path satisfies condition 2 in Definition 3
as NX ; NY are reachable from node N and in both cases
iteratively the first traversed edge is N; N1 , the next edge is
Fig. 10. Traversal path and traversal point in MDG.
748
N1 ; NX , and transitively, NY is reachable through N !

N1 ! NX ! NY . At the same time, on this traversal path
node N1 has other outgoing edges which can result in other
traversal paths through N1 such that node N1 becomes a
traversal point. However, nodes NX and NY have an outdegree of 1. There are no other possible traversal paths except
one, and so NX and NY cannot be termed as traversal points. In
case, node NY has an out-degree more than 1, other traversal
paths are then possible through nodes NX and NY , making
both of those nodes as traversal points. On the other hand, if
the out-degree of node NX is more than 1 and out-degree of
node NY remains 1, only node NX becomes a traversal point.
An examination of an MDG (discussed in Section 4) reveals
that the dependence edges in an MDG can be classified into
two categories, viz., nonannotated edges and annotated
edges. The nonannotated edges in an MDG result from
incorporation of the static information from the underlying
UML structural model. On the other hand, the annotated
edges in the MDG are created based on the dynamic
information arising out of model interactions that are
extracted from the UML behavioral model. Based on this,
we consider following two parameters to identify the
traversal paths in the MDG:
Messages represented by annotated edges from
interaction models into the MDG.
2. Association of default value(s) with class attributes,
operation parameters, operation return values, guard
condition in fragments, and parameters in interaction
occurrence as initialization data in MDG nodes.
Additionally, considering specific values used for
execution of a particular scenario in an interaction.
Our purpose for MDG traversal is to compute model
slices. Further, such computed slices can either be static or
dynamic. In case we are interested in computing a static
slice (see Section 6.5), the second parameter mentioned
above for deciding the traversal path is not required. The
second parameter is required only when dynamic model
slices are to be computed. Next, we first discuss the details
of the first parameter, which is followed by the details of the
second parameter. In addition, our next section will discuss
how these parameters become a part of the slicing criterion
and prove useful in dynamic slicing.
1.
5.6.1 Specification of Messages for MDG Traversal

Considering the scenarios in specification of messages for
dynamic slice computation, it is possible to specify the
messages for MDG traversal in the following way:
All messages given by Sij . It indicates all the
messages in the jth scenario of an interaction Ii .
For the above specification of messages, an operation
MessageList was defined in Definition 2 (see Section 5.4),
which identifies the exact message. Furthermore, in Section 5.4 we illustrated the MessageList operation using an
example. The example illustrating MessageListS12
showed f1; 2; 3; 7; 8; 9; 10; 11g as the corresponding list of
messages. These messages are represented by message
dependence edges in the MDG with annotations
fI1 1; I1 2; I1 3; I1 7; I1 8; I1 9; I1 10; I1 11g. We discuss next how these annotations are used during MDG
traversal.
VOL. 37,
NO. 6,
Fig. 11. Edge selection based on annotation during MDG traversal.
5.6.2 Selection of Edges During MDG Traversal

In this section, we address the issue of selecting edges in
MDG traversal when a node has many outgoing edges. For
a node having edges with distinct annotations, the annotation itself is used to decide the edge selection during
traversal. In Fig. 11, for node N having a pair of outgoing
edges annotated with Ii m1 and Ii m2 , respectively, the
edge with annotation Ii m1 is selected first for traversal,
given m1 < m2 . However, if more than one outgoing edge has
the same annotation, the edge selected for traversal is based
on its dependence type. Considering such a case, the
selection of edges is done in the order of control
dependence edge, call dependence edge, data dependence
edge, and return dependence edge. In addition, for
nonannotated outgoing edges, the selection is done in the
following order: relationship dependence edge, operation
dependence edge, and member dependence edge. This
process of selecting an edge to decide the traversal path in
MDG is termed the edge selection mechanism.
5.6.3 Specification of Model Data for MDG Traversal
Initialization of class attributes, fragment local attributes,
guard conditions, operation invocation by value, etc., are
only a few examples of data associated with models. We
use the term model data to mean all possible forms of data
associated with a UML model. In general, model elements
associated with the class and interaction models, when
initialized (either assigned a default value, or specific to a
scenario), collectively comprise the model data. We refer to
such model data by the term DM in all our subsequent
discussion. As model data plays a significant role in
computing a dynamic model slice, we include the
DM parameter in the slicing criterion (see Section 5.7) that
computes a dynamic model slice. In the following, we list
those model elements that are represented in the MDG,
and can have some form of data associated with them
through initialization:
.
Class Attributes. These comprise those attributes from

the class model which have been assigned a default
value or a value that is valid for a particular scenario
execution.
Operation Parameters. These comprise those operation
parameters which either have an associated default
value in the class model or are given a scenario
specific value in the interaction model.
Operation Return Values. Like operation parameters,
these comprise those operation return values which
either have an associated default value in the class
model or take up a value computed in an operation
invocation during a scenario execution.
Fragment Parameters. The condition(s) associated
with a combined fragment can comprise class
attributes or local fragment attributes. Like class

attributes, they comprise those fragment attributes
which have some particular value for a specific
scenario execution against some boundary value for
the fragment condition in the interaction model.
. Interaction Use Parameters. Like operation parameters, they comprise those interaction use parameters which either have an associated default value
or are passed by a scenario specific value in the
interaction model.
All the above ways of associating data with different
model elements in the class and interaction models
comprise the model data. The model data are represented
through a node corresponding to the associated model
element in the MDG of a model. This would allow the use of
model data during the traversal process for dynamic slice
computation. In the following, we list the different model
data and their association in the MDG:
.
.
.
.
The data initializing the class attributes get associated with an attribute (AT) node.
The data initializing the operation parameters get
associated with a parameter (PR) node.
The data in the operation return value get associated
with a return (RT) node.
The data defining a fragment condition(s) get
associated with the corresponding predicate class
(PC) node.
The data in interaction use parameters get associated
with an interaction (IT) node.
5.6.4 Process of MDG Traversal

Given a CA (or PC) node, a message sequence, and model
data, in this section we discuss how different traversal paths
can be determined using our seven-step MDG traversal
process.
1.
2.
3.
4.
Traversal begins on any of the CA (or PC) nodes in

MDG.
The traversal path cannot be initiated from a CA (or PC)
node with no outgoing edges, but possible otherwise.
The traversal process cannot proceed if the outgoing
annotated dependence edges from the start CA (or
PC) node does not represent any one of the
messages in the given message sequence. However,
considering any arbitrary message from a given
message sequence relaxes the message execution
order in a scenario. In case a strict ordering on
message execution in a scenario is followed, the
start CA (or PC) node should have one of its
outgoing annotated dependence edges representing
the first message in the given message sequence.
Use of such a restriction during traversal ensures
that the order of selection of edges matches the
execution order of messages in a scenario. In
addition, the possibility of computed model slices
to be executable increases.
The next node in the traversal path from the starting
CA (or PC) node is determined by its outgoing
annotated dependence edges based on the edge
selection mechanism (see Fig. 11).
5.
749
Due to our consideration of a message sequence in

MDG traversal, after the next node is determined in
4 above, the traversal path is based on the conditions
given in Definition 3 along with one of the following
additional conditions:
Nodes on the traversal path should have at least

one outgoing annotated dependence edge representing a message in the message sequence
for a given model data.
b. In case a node on the traversal path has only
nonannotated edges, one of these edges should
lead to a next node which should satisfy
condition 5a above.
6. Any traversal point on the traversal path is marked.
On reaching the end node in a traversal path, the
next traversal path is through the last marked
traversal point. However, between the present
traversal path and last identified traversal path, the
path till the last marked traversal point is common.
This process continues till all traversal paths along
with their marked traversal points are considered.
7. The traversal path ends on a node, where either of
conditions 5a or 5b fail.
The above process of MDG traversal is implemented in
procedure TraverseMDG(). We discuss in Section 6.2 how
TraverseMDG() is invoked during the dynamic slicing of
UML models.
a.
5.7 Definitions Pertinent to Slicing

A dynamic architectural model slice is constructed with
respect to specific input parameters and is only valid for
those parameters. The details on such parameters to be
referred by the term DM were presented in our discussion on
model data in the last section. A slicing criterion to compute a
dynamic slice should consist of all such parameters. In
addition, an object of a model class and a reference to a
specific scenario from an interaction also form the part of
the slicing criterion. An object of class CL(n) is represented
using a CA node CACLn and the jth scenario in an
interaction Ii as Sij . These notations on CA node and
scenarios have been discussed in detail in Section 3 and
earlier in this section, respectively.
Using the information given in the criterion for a
scenario under execution, the slicing process uses the
defined slicing criterion to compute the dynamic slice.
Subsequently, as an end result, the slicing activity appropriately identifies the model elements and their interdependencies from the MDG of a UML model. These
identified architectural elements comprise the classes and
their objects, different attributes, and relevant operation
invocations. We term the identified group of model
elements collectively as a dynamic slice of an architectural
model. These model elements are said to be identified based
on the corresponding slicing criterion.
We illustrate the use of slicing criterion and its use in
dynamic slice computation using an example UML model
and its MDG in Figs. 12 and 13, respectively.
Consider the MDG in Fig. 13a for the example UML
model obtained after the extraction process discussed in
Section 5.5. The corresponding MDG (parts highlighted in
750
VOL. 37,
NO. 6,
Fig. 12. An example UML model. (a) Classes depicted using a class diagram and (b) an interaction depicted using a sequence diagram.
black) of the sliced model is given in Fig. 13b considering

the following conditions:
Given attribX1 > 10.
Given a scenario comprising messages 1, 2, and 3
between objects of ClassX and ClassY.
3. Compute a model slice for an object of ClassX for a
scenario description given in 2 above.
The above three conditions together are termed a slicing
criterion. Using these conditions, the exact messages that
are executed in a scenario specified in condition 2 can be
decided using the parameters given in condition 1. As an
effect of these conditions, message 2 is never executed in the
interaction depicted in Fig. 12b. This impact is depicted in
the MDG shown in Fig. 13b. The highlighted nodes in the
MDG depicted in Fig. 13b and the dependencies among
them identify the relevant model parts that comprise the
dynamic architectural model slice under computation.
In the following, we define a slicing criterion and its
corresponding computed dynamic slice for an architectural model.
1.
2.
Definition 5 (Slicing Criterion). Given the MDG GM of an

architectural model M, and a CA node CACLn in GM . For a
given scenario Sij governed by DM such that Sij involves an

execution of k message transfers, each represented by Ii k
based on the arguments in DM , a slicing criterion is a triplet of
the form CACLn ; Sij ; DM .
Definition 6 (Dynamic Architectural Model Slice). Given a
slicing criterion CACLn ; Sij ; DM , the dynamic architectural
model slice is defined as the part of an architectural model
comprising a set of classes along with their related attributes
and operations which participate, either directly or indirectly,
during the execution of a scenario Sij using DM .
We represent the dynamic architectural model slice by
DynamicArchModelSlice (DAMS). Subsequently, a dynamic
slice for an architectural model with respect to a slicing criterion
CACLn ; Sij ; DM is represented by DAMS(CACLn ; Sij ; DM ).
Definition 7 (Computation of Dynamic Slice). Given a
slicing criterion CACLn1 ; Sij ; DM . Let the corresponding
dynamic slice for an architectural model be DAMSCACLn1 ;
Sij ; DM . Let fCACLn1 ; CACLn2 ; . . . ; CACLn1 ; CACLnk g be
the set of all dependence edges that can be traversed from
CACLn1 in MDG GM during the execution of a scenario Sij
using DM . Then, the dynamic slice is computed using a
transitive closure as follows:
Fig. 13. MDG representation for the example UML model given in Fig. 12. (a) View before slicing and (b) view on slicing.
DAMSCACLn1 ; Sij ; DM fCACLn1 ; CACLn2

[ . . . [ CACLn1 ; CACLnk g
[ DAMSCACLn2 ; Sij ; DM
[ . . . [ DAMSCACLnk ; Sij ; DM :
DYNAMIC SLICING OF ARCHITECTURAL MODELS
We have named our dynamic slicing algorithm Dynamic

Slicing of UML Architectural Models (DSUAM). DSUAM
takes a UML architectural model and a slicing criterion as
its input and produces a computed dynamic slice for the
execution of a specified scenario. The operation of our
dynamic slicing algorithm can be divided into two main
phases: 1) incremental extraction of information from
structural and behavioral models to construct an MDG,
and 2) traversal of MDG to compute a dynamic slice.
In the first phase, an MDG is constructed by extracting
model information through static analysis of the UML
structural and behavioral models. The MDG constructed
during the first phase is traversed for a given slicing
criterion in the second phase of DSUAM. The traversal of
MDG helps to identify different architectural elements
forming the dynamic slice. This slice is stored in DAMS and
can be fetched anytime through a simple look up operation.
This helps DSUAM to save storage space as the same slice
information is not stored at any other nodes in the MDG.
6.1 Construction of MDG

We now present the procedure ConstructMDG() for the
construction of an MDG using the incremental extraction
process explained in Section 5.5. The construction of an MDG
involves a preprocessing activity of annotating each dependence edge with a label In m based on the message transfers
in an interaction. Next, based on the objects that are used
across different interactions, the class access (CA) nodes along
with the associated AT, OA, PR, and RT nodes, predicate
class (PC) nodes and interaction (IT) nodes are added to the
MDG. In the final step, all these nodes are connected using
edges which represent the different types of dependencies
among model elements extracted from the structural and
behavioral models. The procedure ConstructMDG() contains a call to few other procedures. The pseudocode for these
called procedures are given in [24].
The ConstructMDG() procedure in the pseudocode
presented in Fig. 14 takes two parameters, viz., a set of
classes (SetClass) and a set of interactions (SetInteraction), and it returns the constructed MDG. Lines 1-7
initialize the different variables used by ConstructMDG().
In line 1, the MDG is initialized to NULL indicating that
initially the MDG contains no nodes, or edges. The while
loop in lines 8-30 implements the process of extraction.
The loop condition at line 8 ensures that all of the
interactions are considered. A call to procedure GetArbitraryInteraction() at line 9 initiates the model
extraction process by arbitrarily selecting an interaction In
from a set of unprocessed interactions SetInteraction.
The loop of lines 10-29 adds various nodes and edges
based on an selected interaction, and from all those classes
which have been referred due to a message transfer in the
751
selected interaction. The loop of line 11 runs for every

message transfer in the selected interaction and makes a call
to procedure GetMessageType() at line 13.
The inner loop in lines 16-28 executes once for every
message transfer represented by In m from In in the MDG.
The call at line 18 to procedure Get_Combined_
Fragment_Info() can detect a combined fragment in an
interaction and at the same time is responsible for gathering
all the information needed to add predicate class nodes and
control dependence edges in the MDG. This loop makes a
call to two other procedures viz., AddMDGNode() and
AddMDGEdge(). The loop of line 19 calls a procedure
AddMDGNode() to add nodes in the MDG, such that no
duplicate nodes are added during the process of MDG
construction. After appending these nodes at line 22, a
call to procedure AddMDGEdge() adds different dependence edges among these nodes except the intersequence
dependence edges. Next, the MDG construction process
adds IT nodes and intersequence dependence edges as
shown using a call to procedures GetAssociated_CANode() and AddMDG_ITNodeEdges() at lines 25 and 26,
respectively, of the ConstructMDG() procedure. The
construction of MDG completes with the addition of the
various nodes and dependence edges, as shown using
the loop in lines 8-30 of ConstructMDG() procedure.
Line 31 finally returns the MDG for the corresponding
UML architectural model, which also completes the incremental extraction process.
The different procedures called by ConstructMDG()
perform the tasks described in the following:
.
GetMessageType()This procedure identifies a

message type for a specific message transfer in an
interaction. It takes In m as a parameter, representing the mth message in an interaction In , and returns
the type of message represented by In m.
FetchClassPair()This procedure finds a pair
of classes for a message transfer between two objects.
It takes In m as a parameter, representing the
mth message in an interaction labeled In , and returns
a class pair for an object pair with an mth message
between them.
Get_Combined_Fragment_Info()This procedure gets all the information related to a combined
fragment when one is found. It returns a list of class
attributes and local attributes used as interaction
operands to express the condition associated with a
combined fragment. It also returns a list of predicate
classes based on these attributes, along with a list of
messages grouped in a combined fragment.
AddMDGNode()This procedure creates a node in
the MDG. It creates a CA node for every object used
in an interaction, if it has not already been done. It
ensures that a CA node involving multiple message
dependencies with other CA nodes arising due to
multiple interactions among similar objects is not
duplicated in the MDG. At the same time, there is
the possibility of a repeated use of the objects of the
same class across several interactions. This procedure guarantees that only a single CA node is added
to an MDG for all occurrences of an object in
752
VOL. 37,
NO. 6,
Fig. 14. Pseudocode for the ConstructMDG() procedure.
multiple interactions. It also converts a CA node to a

predicate class (PC) node in case a condition
associated with a combined fragment in an interaction is linked to a CA node. It also adds related
OA nodes (representing class constructors and
operations) along with the PR and RT nodes and
the attribute (AT) nodes to an MDG for all such
classes. It takes two parametersan object and a list
of predicate classes, if any, from an interaction.
AddMDGEdge()This procedure inserts appropriate dependence edges in the following two ways:
First, it adds member, operation, data, and relationship dependence edges based on the classes available
from the structural model. Second, it adds control,

call, return, and data dependence edges based on the
interactions from the behavioral model. It takes five
parameters. The first parameter is the label to be
annotated with a dependence edge. The second and
third parameters are used to identify the CA nodes
between which a dependence edge is to be added.
Moreover, the second and third parameters are used
to decide how the dependence edges between the CA,
AT, OA, PR, and RT nodes are to be added. The fourth
and fifth parameters representing the information
related to a combined fragment are used to add
control dependence edges in the MDG. In addition,
this procedure incorporates dependency semantics in

the process of adding different dependence edges, as
discussed earlier in Section 4.3, into the MDG.
The above discussed procedures called by ConstructMDG() help add various nodes and edges to an
MDG. However, the IT nodes and their associated
dependence edges have not yet been represented in the
MDG. The loop in lines 23-27 adds IT nodes and related
edges based on the selected interaction In to the MDG by
making calls to two procedures, viz., GetAssociated_
CANode() and AddMDG_ITNodeEdges(). The different
procedures called by ConstructMDG() to represent an
interaction occurrence in the MDG perform the tasks
described in the following:
IdentifyITNode()This procedure creates an
IT node, that is subsequently added in the MDG.
It takes two parameters, viz., two interactions
labeled Ij and In , and returns an IT node ITnj .
. GetAssociated_CANode()This procedure locates a corresponding CA node that forms an
intersequence dependency with an IT node ITnj
returned by a procedure IdentifyITnode() in
line 24.
. AddMDG_ITNodeEdges()This procedure connects two nodes ITnj and the corresponding CA node
using intersequence call and intersequence return
dependence edges in the MDG. It takes two
parameters, viz., a CA node returned by GetAssociated_CANode() and the IT node ITnj .
A single execution of the pseudocode in lines 8-30
constitutes a single step in the incremental extraction process
depicted in the schematic given in Fig. 9. In addition, every
subsequent execution updates the MDG available from the
previous step. After completion of the last step of extraction,
line 31 returns the constructed MDG.
.
corresponding to Im k 2 ScenarioMsgList
based on DM during execution of scenario Smj do
TraverseMDGMDG; Im k; DM ;
DAMS(SCd )=Track DynSliceMDG; Im k; DM ;
end for
DisplaySlice(DAMS(SCd ));
End DSUAM
After the slicing criterion is given as an input, DSUAM
computes a dynamic slice on the fly by executing Phase 2 of
the algorithm.
SetClass and SetInteraction are first initialized to
fCL1 . . . CLng and fI1 . . . Im g, respectively, indicating
that initially the architectural model consists of n classes
and m interactions. The MDG is initialized to NULL,
indicating that initially no nodes or edges exist in the
MDG. The loop of Phase 2 traverses the MDG for any given
slicing criterion. This loop calls two other procedures, viz.,
TraverseMDG() and Track_DynSlice(). Next, Phase 2
of the algorithm ends with a call to the procedure
DisplaySlice(). A detailed description of the various
procedures called during execution of DSUAM is available
in [23], including the pseudocode representation. The
different procedures called in Phases 1 and 2 of DSUAM
perform the following tasks:
.
6.2 Pseudocode of DSUAM Algorithm

This section presents our DSUAM algorithm in pseudocode
form. It assumes that the information about the classes and
the interactions is available from a given UML model.
Algorithm DSUAM
Requires : SetClass fCL1 . . . CLn}
{* Set of classes in a model *}
SetInteraction fI1 . . . Im }
{* Set of interactions in a model *}
Initialization : GraphMDG NULL
ListScenarioMsgList NULL
{*Slicing Criterion *}
Input : SCd CACLn ; Smj ; DM
Output : DAMS(CACLn ; Smj ; DM )
Phase 1 : Incremental extraction of information from structural
and behavioral models to construct an MDG
{* Call a procedure for MDG construction *}
MDG ConstructMDGSetClass;
SetInteraction;
Phase 2 : Traversal of MDG to compute a dynamic slice
{* Dynamic slice for execution of a scenario *}
ScenarioMsgList = MessageListSmj ;
for every dependent node traversed from CACLn
753
ConstructMDG()This procedure implements the

steps of the incremental extraction process discussed
in the previous section. It takes two parameters, viz.,
a SetClass, and SetInteraction, and constructs
the MDG.
TraverseMDG()This procedure identifies the
dependence edges based on the slicing criterion
and traverses the nodes of the MDG through the
dependence edges. It takes three parameters, viz., an
MDG, Im k, and DM . The second parameter representing a dependence edge is obtained using the
MessageList (see Definition 2) operation, and the
third parameter is taken from the given slicing
criterion representing the arguments needed for a
scenario execution, respectively, using which the
MDG is traversed to compute a dynamic slice using
the policy presented in Section 5.6. This process of
traversing the nodes in the MDG identifies all the
relevant model parts to be included in the dynamic
slice. The details about the use of parameter DM in
the process of slice computation have been discussed
in Section 5.7.
Track_DynSlice()This procedure tracks the
process of dynamic slice computation during MDG
traversal. It stores the computed slice using the data
structure DAMS. It takes three parameters exactly
similar to the immediate last call to TraverseMDG()
procedure.
DisplaySlice()This procedure takes only one
parameter representing the computed dynamic slice,
viz., DAMSCACLclass ; Smj ; DM , and displays it.
6.3 Complexity Analysis of DSUAM

In this section, we analyze the space and time complexities
of DSUAM. To conserve space, the detailed proofs for the
754
space and time complexities of DSUAM are not reported

here and can be found in [23]. We first present an analysis
of space complexity, and then highlight a few important
aspects relevant to the time complexity of DSUAM.
Let M be an UML architectural model. Let GM be an MDG
of M. The following factors determine the total space
requirement considering model M and its MDG GM during
slicing using the DSUAM algorithm:
VOL. 37,
NO. 6,
6.3.2 Space Required During Execution of Phase 2 of

DSUAM
Phase 2 of DSUAM performs MDG traversal and computes
a dynamic model slice. In the process of dynamic slice
computation, it can be seen from the pseudocode that
during execution of Phase 2 of DSUAM the following
parameters essentially decide the space requirements:
To maintain a list of messages using Scenario
MsgList.
2. To maintain the list of nodes traversed in MDG
during slice computation on execution of procedure
TraverseMDG().
3. To store the dynamic model slice using DAMS.
It is evident from the above details that the space needed
during execution of Phase 2 of DSUAM mainly comprises
three different lists. The parameter listed in 1 above is a
message list, which gets initialized based on the slicing
criterion SCd and is considered to compute the dynamic slice.
On the other hand, the parameters shown in 2 and 3 above
represent the list of nodes traversed in MDG and DAMS to
store the corresponding model elements in the slice,
respectively, for a given SCd . It should be noted here that
DAMS contains the model elements forming the dynamic
slice, and is obtained by reverse mapping the corresponding
nodes from the list (parameter 2 above) fetched by execution
of procedure TraverseMDG(). Furthermore, in comparison
to the ScenarioMsgList, the list corresponding to parameters 2 and 3 above can decide the bound on the runtime
space, as well as the space needed to store the dynamic
model slice in Phase 2 of DSUAM.
For a system model M and its MDG GM , we give
NodesT GM as a bound on the number of nodes traversed
in MDG for P
a given slicing criterion SCd .
Suppose
nT
nt is the total number of different nodes
traversed in MDG GM . Then, NodesT GM can be expressed as
X
NodesT GM
nT
5
nt ;
1.
Space required during execution of Phase 1 of

DSUAM. This space is needed to construct and store
the MDG GM of a UML model M. We denote such a
space requirement by S1 DSUAM.
. Space required during execution of Phase 2 of
DSUAM. This is determined by the space requirement in the process of dynamic model slice
computation on the MDG GM . We denote such a
space requirement by S2 DSUAM.
We now analyze in the following the space complexity of
each of the above parameters and, using these, determine
the overall space requirement of DSUAM.
.
6.3.1 Space Required During Execution of Phase 1 of

DSUAM
The bound on the space requirement for representing a
graph is available in standard literature [4], and is of the
order of OjNj2 , where jNj indicates the number of nodes in
a graph. This result can be used to define the upper bound
on the space requirement of MDG GM . A bound NodesGM
on the nodes in the MDG GM can be expressed as
X
nnt ;
1
NodesGM
8nt
where nnt is the number of nodes of type nt in MDG, such

that nt fCA; AT; OA; PR; RT; PC; ITg.
Using the bound on nodes in MDG given in (1), we
compute the upper bound sizeGM on the space needed by
an MDG GM , and this can be expressed as
sizeGM OjNodesGM j2 :
The nodes in the MDG GM represent the model elements in

the corresponding UML model M. These model elements are
added to the MDG based on every model interaction
considered in the incremental MDG construction process
discussed in Sections 5.5 and 6.1. Suppose jMEI j is the
number of model elements across interactions in model M,
which are represented as nodes in the MDG GM . Substituting jMEI j in (2), we get
8nt
nT
nt
is the number of traversed nodes of type nt in

where
MDG such that nt fCA; AT; OA; PR; RT; PC; ITg.
Using the bound on the nodes traversed in MDG given
by (5), we compute the upper bound S2 DSUAM on space
needed during execution of Phase 2 of DSUAM that
computes the dynamic model slice. This can be expressed as
S2 DSUAM OjNodesT GM j:
Equation (3) also denotes the bound S1 DSUAM on the

space needed during execution of Phase 1 of DSUAM. It can
be expressed as
Let jMEDS j be the number of model elements in the

computed dynamic model slice DAMS, which are represented as nodes in any traversal path in MDG for the slicing
criterion SCd . Using the result derived in (6) and substituting jMEDS j for jNodesT GM j, we can give the upper bound
S2 DSUAM on space needed during execution of Phase 2 of
DSUAM, and this can be expressed as
S1 DSUAM sizeGM
S2 DSUAM OjMEDS j:
sizeGM OjMEI j2 :
OjMEI j :
The above bound suggests that the space needed to

maintain an MDG GM is a polynomial function of the
number of model elements in a model M.
6.3.3 Overall Space Complexity of DSUAM

Using the bounds S1 DSUAM and S2 DSUAM on the space
needed during execution of Phases 1 and 2 of DSUAM, we
can express the overall space complexity of DSUAM.
Let S(DSUAM) be the space complexity of DSUAM. For a

model with jMEI j model elements, let jMEDS j be the number of
model elements in the computed dynamic model slice, such
that jMEDS j jMEI j because MEDS MEI . Using the results
derived on S1 DSUAM and S2 DSUAM in (4) and (7),
S(DSUAM) can now be expressed as
SDSUAM S1 DSUAM S2 DSUAM;
OjMEI j OjMEDS j
OjMEI j2 :
Substituting T for jMEI j in the above equation, we get

SDSUAM OT2 :
10
A detailed analysis of time complexity of DSUAM can

be made in a similar manner as the space complexity
analysis presented above. Let T1 DSUAM and T2 DSUAM be
the time required to execute each of Phases 1 and 2,
respectively, of DSUAM. We should know that T1 DSUAM
corresponds to the construction time of MDG GM , while
T2 DSUAM is the time required for traversal of MDG GM in
the process of dynamic slice computation for the model M.
Further, it is obvious from the pseudocode of DSUAM that
the time requirement T1 DSUAM is similar to that of
procedure ConstructMDG() (see Section 6.1) invoked
during Phase 1. A close examination of the pseudocode of
ConstructMDG() given in Fig. 14 reveals that it can
construct the MDG GM for any UML model M in
polynomial time, given by
2
T1 DSUAM OT ;
11
where T is the number of model elements across interactions in model M.

After the MDG is constructed, Phase 2 of DSUAM
traverses the MDG in linear time to compute the dynamic
model slice, and the corresponding time given by T2 DSUAM
can be expressed as
T2 DSUAM OT:
12
6.3.4 Overall Time Complexity of DSUAM

Let T(DSUAM) be the time complexity of DSUAM. Using
the bounds T1 DSUAM (see (11)) and T2 DSUAM (see (12)) on
the time needed during execution of Phases 1 and 2 of
DSUAM, we can now determine the overall time complexity T(DSUAM) of DSUAM
TDSUAM T1 DSUAM T2 DSUAM;
13
OT2 OT
OT2 :
14
Hence, the time complexity of DSUAM is of the polynomial

order in the number of model elements.
We illustrate the working of DSUAM using three
examples in the next section followed by an overview of
an implementation of the DSUAM algorithm.
6.4 Illustration of Working of DSUAM

We explain the working of our DSUAM algorithm by using
the example MDG of Fig. 6, which has been obtained at the
755
end of Phase 2 of the algorithm. Please note that the

information regarding classes and their interactions (for the
UML model given in Fig. 5) is already available at the end
of Phase 1 of the algorithm.
Let us consider three examples showing the computation
of the dynamic architectural model slice. The first example
considers the slicing criterion PCC ; S12 ; DM fattrib a1
1; attrib a2 xxy; attrib c1 0; attrib c2 5g, while
the second example considers
NULL ; S12 ; DM fattrib a1 1;attrib a2 xxy;
attrib c1 0; attrib c2 5g:
The third example computes the slice for the slicing criterion:
CAF ; S21 ; DM fattrib d1 aaa; attrib d2 1;
attrib f1 1; attrib f2 2;
attrib f3 3; attrib e1 abag:
We show the MDG obtained during Phase 2 of DSUAM in
Figs. 15 and 16, displaying the classes, operations, attributes, and interactions contributing to the corresponding
slice. The MDGs of Figs. 15 and 16 are identical except for
the fact that each of them have different dependence edges
highlighted for the particular slicing criterion. Moreover,
the model parts representing the dynamic slice in MDG are
shown in black. And, all the remaining model elements and
dependencies among them have been shown in gray,
indicating their nonparticipation in the computed slice.
Example 1. Fig. 15a shows the MDG traversal using the
predicate class (PC) node for class ClassC highlighted
for the slicing criterion PCC ; S12 ; DM fattrib a1 1;
attrib a2 xxy; attrib c1 0; attrib c2 5g. It depicts the MDG maintained by the architectural model
slicer for the predicate class node PCC denoting ClassC.
It shows control dependency PCC ; PCA , call dependencies PCA ; PCC and PCA ; COA2 , data dependencies
COA2 ; CAT1 and COA2 PR1 ; AAT2 , member dependencies AT2 ; PCA , AT1 ; PCC , and OA2 ; PCC , operation
dependencies PR1 ; COA2 , and RT2 ; COA2 , and return
dependence edge PCA ; CRT2 highlighted (in black)
indicating the traversed edges. Therefore, the dynamic
slice for the slicing criterion,
PCC ; S12 ; DM fattrib a1 1; attrib a2 xxy;
attrib c1 0; attrib c2 5g;
includes only those nodes that can be traversed
through these edges. Moreover, the model elements
corresponding to these traversed nodes are said to
comprise the computed dynamic slice. This implies
that the anonymous objects of ClassA, and ClassC,
operation opr_c2(), and attributes attrib_a2 and
attrib_c1 of ClassA and ClassC, respectively,
contribute to the slice when we consider the dynamic
slice computation for an interaction comprising of
messages represented by I1 3, I1 7, I1 8, and I1 9
in a specified scenario S12 . This example shows how the
process of dynamic slicing takes into account only those
dependencies for an interaction that are relevant with an
object of interest for the given arguments in DM during
756
VOL. 37,
NO. 6,
Fig. 15. (a) MDG showing dynamic architectural model slice computed for the slicing criterion PCC ; S12 ; DM fattrib a1 1; attrib a2
xxy; attrib c1 0; attrib c2 5 during the execution of Phase 2 of DSUAM, and (b) MDG showing dynamic architectural model slice computed
for the slicing criterion PCC ; S12 ; DM NULL during the execution of Phase 2 of DSUAM.
the execution of a particular scenario. We can verify from

the computed dynamic slice that messages represented
by I1 1, I1 2, I1 10, and I1 11 from the interaction of
Fig. 5b in the MDG do not contribute to the slice as their
execution, directly or indirectly, does not affect the object
of ClassC. Moreover, though the messages represented
by I1 4, I1 5, and I1 6 are associated with an object of
ClassC, they have no effect on the computed dynamic
slice. In the given slicing criterion, we have the data
value of attribute attribute_a1 initialized to -1. This
condition variable associated with the alt combined
fragment in the interaction of Fig. 5b results in the
execution of only the else-part, and so the messages in
the if-part represented by I1 4, I1 5, and I1 6 never get

executed, and do not contribute to the computed
dynamic slice.
Fig. 15b presents an MDG for a slicing criterion
similar to that used in Example 1. However, after the
DM parameter is set to NULL , we apply DSUAM and
obtain the slice. As no data values are considered in this
case, DSUAM does the MDG traversal considering
execution of all the messages in the interaction shown
in Fig. 5b. The resultant MDG of Fig. 15b seemingly
shows up a greater number of nodes traversed as
compared to the MDG of Fig. 15a. This is because, when
DM is set to NULL , the computed slice is a static slice, and
Fig. 16. (a) MDG showing dynamic architectural model slice computed for the slicing criterion NULL ; S12 ; DM fattrib a1 1; attrib a2 xxy,
attrib c1 0; attrib c2 5g during the execution of Phase 2 of DSUAM, and (b) MDG showing dynamic architectural model slice computed for
the slicing criterion CAF ; S21 , DM fattrib d1 aaa, attrib d2 1; attrib f1 1; attrib f2 2; attrib f3 xyx, attrib e1 aba during the
execution of Phase 2 of DSUAM.
it will always comprise a greater number of model

elements than the corresponding dynamic slice for a
criterion with DM not set to NULL . The MDG of Fig. 15b
depicts this fact with a greater number of nodes and
related dependencies shown in black, compared to the
MDG of Fig. 15a. We do not discuss here the details of
static slice, but one conclusion can be derived from this
example, that static slices are larger and do not have that
degree of advantage in its application due to its
conservative nature. Empirically, for this example, the
ratio of number of model elements in dynamic slice to
that in static slice is 7/12, i.e., 0.583, or approximately
41.7 percent a static slice is larger than the corresponding
dynamic slice in this case.
Example 2. Fig. 16a shows the MDG traversal during the
same scenario S12 , but does not consider any specific
class access (CA) node as in the previous case. This
results in the slicing criteria,
NULL ; S12 ; DM fattrib a1 1; attrib a2 xxy;
attrib c1 0; attrib c2 5g;
which makes the first parameter in the criterion triplet set
to _NULL_. In addition to the model elements forming
the slice in Example 1, the computed slice in Example 2 is
also affected by the messages represented by I1 1, I1 2,
I1 10, and I1 11. This is due to the fact that Example 2
computes the slice without considering any specific CA
node in the MDG. This can be seen in Fig. 16a, as none of
the CA or PC nodes is shown highlighted. Further, in
addition to the dependencies that contribute to the slice
in Example 1, the computed slice in Example 2 involves
c a l l d e p e n d e n c i e s PCA ; CAB , PCA ; OA1 , a n d
PCA ; BOA1 ) , d a t a d e p e n d e n c i e s ( AOA1 ; AAT1 ,
AOA1 ; AAT2 , and AOA1 ; CAT2 , member dependencies OA1 ; PCA , AT1 ; PCA , AT2 ; PCA , OA1 ; CAB , and
AT2 ; PCC , and operation dependency PR1 ; BOA1 ,
shown highlighted in Fig. 16a. Moreover, it is evident
that additional nodes are traversed in the MDG in
Example 2 in comparison to Example 1. This increases
the size of computed dynamic slice in Example 2, and the
extent to which the slice is increased is equivalent to the
number of model elements corresponding to the additionally traversed MDG nodes. This implies that the
anonymous objects of ClassA, ClassB, and ClassC,
operations opr_a1(), opr_b1(), and opr_c2(), and
attributes attrib_a1, attrib_a2, attrib_c1, and
attrib_c2 contribute to the computed slice. The
difference (in terms of number of model elements) in
the computed slices in Examples 1 and 2 is significant
indicating the effects of changing slicing criteria.
It shows the call dependencies DOA2 ; FOA2 , DOA2 ;

FOA3 , and CAD ; FOAd , member dependencies
AT2 ; CAF , AT3 ; CAF , OAd ; CAF , OA2 ; CAF , and OA3 ;
CAF , operation dependencies RT2 ; FOA2 and RT3 ;
FOA3 , data dependencies FOA2 ; AT2 and FOA3 ; AT3 ,
and intersequence dependencies IT21 ; CAF and
CAF ; IT21 highlighted, indicating the traversed edges.
Therefore, the dynamic slice for the given slicing criterion
includes all those nodes connected by these edges. This
implies that anonymous objects of ClassD and ClassF,
operations getAttrib_f2(), getAttrib_f3(), and
destroy_F(), attributes attrib_f2 and attrib_f3
of ClassF contribute to the slice. This example shows
how slicing can uncover the data dependencies arising
out of invocation of an operation.
6.5
Modifications to DSUAM to Compute Static

Slices
DSUAM computes dynamic architectural model slices. Static
architectural model slice (SAMS) can also be computed using
DSUAM by incorporating the following modifications:
1.
Change to the Form of the Slicing Criterion.

A dynamic slice is computed by considering a
specific message transfer, or an execution scenario
along with any associated model data (see Section 5.6).
But a static slice can be computed for a specific object
without any regard to related interactions and the
corresponding available model data. This fundamental difference in slicing criteria requires changes in the
input and output parameters, shown in the pseudocode of the DSUAM algorithm in Section 6.2 as
follows:
Input : SCs CACLn {*Slicing Criterion *}
Output : SAMS(CACLn )
2.
Changes to Phase 2 of DSUAM to Compute a Static Slice.

Following is the pseudocode for Phase 2 of
DSUAM that computes a static slice:
for every dependent node traversed from
CACLn do
TraverseMDGMDG; CACLn ;
SAMSSCs Track SSliceMDG; CACLn ;
end for
DisplaySlice(SAMS(SCs ));
The different procedures called in Phase 2 of DSUAM

after adjustments perform the following tasks:
.
Example 3. Fig. 16b shows MDG traversal using the class

access (CA) node of ClassF highlighted for the slicing
criterion:
CAF ; S21 ; DM fattrib d1 aaa; attrib d2 1;
attrib f1 1; attrib f2 2;
attrib f3 xyx; attrib e1 aba:
757
TraverseMDG()This same procedure is called by

DSUAM during MDG traversal for dynamic slice
computation. However, for static slice computation
it has different calling parameters due to its
polymorphic behavior. This procedure identifies
the dependence edges based on the slicing criterion,
and traverses the nodes of the MDG. It takes one
parameter from the given slicing criterion viz., a
CACLn , and the other is the MDG to be traversed.
Track_SSlice()This procedure tracks the process of static slice computation during MDG
traversal. It stores the computed slice using the
758
VOL. 37,
NO. 6,
data structure SAMS. It takes two parameters similar

to the TraverseMDG() procedure called for static
slice computation.
The functionality of DisplaySlice() remains unchanged, but it now displays a static slice instead of a
dynamic slice.
6.6 MDG Scaling

With the increase in the size of UML models, there is an
increase in the number of model elements which need to be
represented in the corresponding MDG. This clearly raises
an issue of what are the possible approaches to limit the size
of MDG so that large-size UML models can be represented
efficiently. This will have twin benefits: One, it will conserve
space, and second, the model extraction process, its MDG
construction, as well as traversal for slice computation will
also be time efficient. In the following, we list a few effective
implementations of MDG for handling complex and largesized UML models:
.
Approach I. No addition of irrelevant nodes in

MDG. This can be made mandatory in two cases,
first, when the elements from the structural model
are not referred in the behavioral model (e.g., no
object for a class takes part in an interaction), and
second, the related model elements of the unreferred
elements are also not incorporated in the MDG.
Approach II. Rather than constructing a single
large MDG, partial MDGs can be constructed on a
per interaction basis, which would contain both
the structural and behavioral information. This
would require combining the model information
represented in partial MDGs on the requirement of
slice computation. This has a major space benefit
as it would limit the size of the resultant partial
MDGs bounded by the number of model elements
in an interaction, or maybe a few interactions, or a
usage scenario, but not to the total number of
model elements.
Approach III. A variation of the previous approach
can be to construct MDG as a layered graph. Each
layer in the MDG is then a partial MDG representing
a different interaction. The layered graph can be
useful when the relation between different layers has
a well-defined semantics. Finally, the slice is
computed using a combination of multiple layers
based on a specific slicing criterion.
Approach IV. A different approach in comparison to
what the previous two approaches would be,
maintain multiple graphs, but every partial graph
does not contain structural and behavioral information together, but rather, different graphs for
representing structural and behavioral information.
The class information based on the structural models
in structure dependence graph (SDG) and interaction-related information in interaction dependence
graph (IDG). This additionally requires a correlation
between different model elements from the structural model (represented using SDG) with its usage in
the behavioral model (represented using IDG) in the
process of slice computation.
Fig. 17. A schematic design model of the prototype tool Archlice.
PROOF OF CONCEPT
In this section, we present an implementation of our

DSUAM algorithm. We have implemented a prototype tool
to compute dynamic architectural model slices using our
DSUAM algorithm and have named it Archlice. Our tool can
be integrated with many UML model development tools
such as MagicDraw UML [32], which can export UML
models in XML format. This makes Archlice independent of
any specific UML modeling tool [16]. We have implemented our tool using Java and used the Document Object
Model (DOM) API of Java for parsing XML files. DOM
provides a standard programming interface that is used in a
wide variety of modeling environments and applications.
Moreover, XML is increasingly being used for representing
different kinds of models to facilitate their use across
diverse systems [25]. Additionally, XML represents the data
associated with UML models as documents, enabling DOM
to be used to manage this data.
7.1 Implementation of DSUAM

A schematic design of Archlice is shown in Fig. 17. The
different components of this design are explained in the
following:
Archlice takes as input a UML architectural model
comprising the classes and interactions, in XML format.
This is parsed by the Parser Module to extract information
regarding different classes, their attributes and operations
from the structural model. This module also gathers
behavioral information regarding objects of different classes
by analyzing the interactions among them. The information
obtained using the Parser Module is then used to initialize all
the data structures needed to construct the MDG.
The Naming Module assigns labels to the various model
elements. Every class and interaction is first appropriately
labeled and added to SetClass and SetInteraction,
respectively. This aspect is shown in the schematic of Fig. 17
by the outgoing arrows SetClass and SetInteraction
from the Naming Module block. Moreover, using the
information present in the data structures initialized by the
Parser Module, the corresponding model elements from each
of the class and interaction are also assigned suitable labels to
represent them in the MDG. The Extraction and Graph
Construction Module constructs an MDG by using the sets
SetClass and SetInteraction. This module implements the ConstructMDG() procedure that is executed
during Phase 1 of the DSUAM. The Parser Module, the Naming
Module, and the Graph Construction Module together implement the Phase 1 of DSUAM. Next, based on the specified
TABLE 1
Artifacts for Classes Considered in Each System Model
NC indicates total number of classes,

NA indicates sum total of all class attributes,
NO indicates sum total of all class operations,
NAsR indicates sum total of associations among classes,
NAgR indicates sum total of aggregations among classes,
NIR indicates sum total of inheritance relationships among classes,
MID indicates maximum inheritance depth in a class hierarchy.
slicing criterion, the Dynamic Slicer Module of Archlice

traverses the MDG for computation of the dynamic slice.
Archlice supports a graphical user interface (GUI) for all
user interactions, such as specification of model, the slicing
criteria, display of computed slice, etc. The Dynamic Slicer
Module traverses the MDG through the dependence edges
based on the specified slicing criterion and computes a
dynamic architectural model slice. The GUI Module presents
the computed slice through highlighting relevant nodes and
dependence edges on the MDG. Together, the Dynamic
Slicer Module and the GUI Module implement the Phase 2 of
DSUAM. The finer implementation details are out of the
scope of the present discussion. The exact details on
Archlice, along with its UML model for our implementation,
were reported in [24].
7.2 UML Models Used in Experiments

Several benchmark programs are available for validating
program slicing algorithms. But this is not the case with
architectural models. Due to the nonavailability of such
benchmark models, we use example models available from
the assignment submissions of our departmental courses.
The case study was conducted in a laboratory environment. A batch of 39 participants, from academia (faculty in
the department of computer engineering in different
colleges in eastern India) and professionals from industry,
participating in a proficiency development course at IIT
Kharagpur, were considered. Counting participant roles,
17 individuals taught software modeling and programming, 9 individuals were assisting the software architects in
their respective companies, 8 individuals were middle-level
faculty who have been supervising term projects in software engineering and object-oriented programming, and
5 individuals were professional programmers. All participants were first asked to design a UML model for a system
description given as exercises in chapter 6 of a software
engineering book [27]. For experimental models to exhibit
heterogeneous design characteristics structurally, we selected 10 suitable UML models from the 39 models
submitted. It is to be noted that this model design exercise
was not meant to select the best UML design models. It was,
in fact, carried out to select a set of experimental models
that possesses such varying characteristics, which can
uncover the different facts of our slicing technique using
the results obtained in our experiments. Besides the
759
TABLE 2
Artifacts for Interactions Considered in Each System Model
NIC indicates total number of objects,

NMsg indicates total number of messages,
NCf indicates total number of combined fragments,
NIo indicates total number of interaction occurrences.
moderate sizes of the models considered, a threat to the

validity of the presented results arises from the limited
number of models considered and the fact that the
experimental models were developed by participants of
the aforementioned course. Even then, considering the
precautions we have taken, we are convinced that the
presented results (see Section 7.4) do portray the overall
capability of our approach.
The models were constructed using MagicDraw UML and
their corresponding XML representation was available for
the implementation purpose. The detailed description of
each design and the design documents for the 10 systems
were taken directly from the design solutions to assignments,
and we do not include these models here due to space
limitations. To summarize, the experimental tasks listed in
the next section were carried out on each of the UML
architectural models for 10 different software systems to test
the Archlice implementation of the DSUAM algorithm.
The different designed models consisted of between 4
and 175 classes, and included, in addition to the classes, a
minimum of eight objects, and maximum of 409 instances of
different classes. The classes and their objects were
represented in various class and sequence diagrams of the
software systems. To make the construction of MDG, and
subsequent computation of the dynamic slices for different
architectural models comparable, each of the class diagrams
were developed with the anchored notes appropriately
customized. Additionally, the class diagrams were designed to model different class relationships, such as
generalization, association, aggregation, and composition.
Table 1 summarizes the counts related to different artifacts
and relationships used in modeling class diagrams for
different systems considered. On the other hand, the design
of sequence diagrams considered application of different
message types along with the use of interaction occurrences
and combined fragments to model system scenarios. Table 2
summarizes the sizes related to various artifacts used in
modeling sequence diagrams for the considered aforementioned systems.
7.3 Experimental Tasks and Objectives

For a systems UML architectural model, three sets of tasks
are performed with their respective objectives. First, we
carry out static analysis of the XML representation of UML
models [25]. This involves parsing the XML representations
for each of the 10 UML models considered and gathering
information about different model elements. This task gives
an indication of the size of the UML model. During this
activity of assembling the model elements from across the
760
various UML models, the information regarding the

relationships among them is also gathered.
The second task involves assigning suitable labels to each
of the identified model elements, and maintaining a one-toone mapping between a model element and its assigned
label. This mapping is used after the computation of the
slice for reverse mapping the assigned labels to the
corresponding model elements. Additionally, after naming
the model elements, the relationship information among
different model elements is used to construct the MDG.
Finally, the constructed MDG is displayed in the Archlice
GUI environment.
The third task consists of a number of subtasks. It begins
with the specification of the slicing criterion. Ideally, slicing
criteria (i.e., triplets of the form [class, scenario, data])
would be chosen that might be used by an architect during
maintenance. However, since we are unfamiliar with the
benchmarks, we instead elected to exhaustively generate
slicing criteria for each model, i.e., we instructed the
10 participants whose UML design models had been taken
as the test-bench for DSUAM to generate all possible [class,
scenario, and data] triplets for the model using a criterion
generator available with Archlice. The criterion generation
process works with one restriction, that the associated data
in every slicing criteria be referenced in a scenario usage.
This ensures that results are not biased because of a
particular choice of slicing criteria. However, we restricted
the initial slicing criteria to come from only those interactions in which the greatest number of messages were
actually executed during a scenario usage to ensure the
availability of dynamic model information (e.g., data
dependencies among model elements). Choosing criteria
from interactions in which most of the messages were not
executed on any scenario run would likely result in many
trivially small slices since no changing model information
would exist for such interactions.
Various combinations of slicing criteria were applied on
the MDG of different UML models manually using
DSUAM. For the given slicing criterion, the MDG is
traversed, and the corresponding dynamic slice is computed. In addition, the same slicing criteria were used to
compute dynamic slices using Archlice. The computed slice
is in the form of model elements represented as labeled
nodes in the MDG. These are mapped back to identify the
corresponding model elements that form the dynamic slice.
In addition, the MDG is displayed with the corresponding
nodes and dependence edges highlighted. The dynamic
slices obtained in both the runs of slice computation
(manual and using Archlice) were compared to validate
the correctness of our algorithm and its implementation.
We report the performance of DSUAM using Archlice
on different UML models through our experimental
studies. The following are the major objectives of our
experimentation:
.
.
First, we quantify the use of varying sizes of

architectural models in testing Archlice.
Second, we investigate the impact of architectural
size on runtime and memory requirements of
DSUAM, as discussed later in Section 7.4.
VOL. 37,
NO. 6,
Third, we investigate the computation process of

different combinations of slicing criteria and its
impact on the slice size.
Fourth, we investigate the size characteristics of
MDG representation based on the model size. This
would have a definite impact on runtime memory
requirements of DSUAM.
Fifth, we classify the slicing criteria in three
categories based on DM , viz., _NULL_, _FEW_, and
_ALL_. We then investigate how the data values
specified using DM in the slicing criteria for these
three categories affect the slice.
Finally, we analyze the effectiveness of our proposed
approaches (see Section 6.6) in successfully representing large-sized UML models.
7.4 Experimental Results

We have conducted several experiments using Archlice on a
number of architectures described using UML. In our
prototype implementation, we assume that the information
about various attributes used by a class operation are
available in a note attached to the corresponding class. This
information is used to determine different data dependencies. To find the runtime and memory requirements of
DSUAM, we determine how Archlice performs on some
example models described in Section 7.2. The system
configuration used to run Archlice is Windows XP service
pack 2, Pentium 4, running at 3 GHz, with 1 GB RAM. All
measured times reported in this section are overall times,
measured between invocation of the slicing commands and
retrieval of the slicing results, including parsing and building
of the MDG representation. In addition, any size measurements are in terms of the number of model elements in a UML
model. On the other hand, the size of MDG is determined in
terms of number of nodes along with their interdependencies.
A summary of the results obtained from our experimental
studies have been presented in Tables 3, 4, 5, 6, 7, 8, 9.
We report in Table 3 a model description of various
experimental UML models along with their corresponding
MDG sizes. We have specifically used models of varying
sizes to understand their impact on the MDG size and the
overall slicing paradigm. A close look at the table would
reveal that the first two models have the CA, AT, and
OA nodes in MDG in direct correlation with the corresponding classes, attributes, and operations in the model
description given in column two. This is not the case in the
models that follow. The models and their MDG exhibit
fewer number of nodes in comparison to the corresponding number of model elements for each of the remaining
listed models. The reasons for MDGs to have such effects
due to the model specification were discussed earlier in
Section 4. The details showing the number of MDG
elements (see columns three and four) for the corresponding number of model elements (see column two) in Table 3
validate the aforementioned facts.
Table 4 presents the model details in a consolidated
manner along with the number of slicing criteria used per
model to compute dynamic slices in our experiments. This
also shows that some slicing criteria (NtSC NuSC ) are trivial
and not useful in the overall experimental run. The number
of slicing criteria, shown as NuSC , are the ones used in our
761
TABLE 3
Model Specification in Terms of Model Elements and Their Corresponding MDG Size
in Terms of Different Node and Dependency Types
model slicing experiments. The classification of the slicing

criteria into three different categories is shown in Table 5.
This classification is based on the DM parameter in the slicing
criterion. Three possible cases of usage of DM considered in
our studies are NULL , FEW , and ALL . The criteria
classified with DM NULL indicates that no attributes are
used in such slicing criterion, while DM FEW indicates
some relevant attributes to a scenario execution are
initialized to values in the slicing criterion. And, DM
ALL indicates all relevant attributes to a scenario execution
are initialized to values in a slicing criterion. This consideration of slicing criterion decides how changing criteria
affect the dynamic slice sizes. The average number of model
elements per slice in each category is different, as can be
seen from Table 5. Moreover, the category DM NULL is a
special case of static slice computation. We have considered
a classification of DM in three categories to give insight into
the impact of changing DM on the computed slices, but a
variation of the similar analysis can be performed step-wise
by considering one additional attribute at a time in DM . This
will result in n categories of slicing criteria in case there are
n relevant attributes used in an interaction from the
considered model.
Table 6 compares the size of the computed slices with
respect to different aspects of the model. This is one indication
of the usefulness of the computed slices for different
applications, discussed in Section 8. Table 6 shows various

ratios computed for different models. It also shows the effect
of changing slicing criteria on the number of model elements
(NsME ) and the corresponding dependencies (Nas
D ). Table 5
depicts details of the computed dynamic slices when the
parameter DM is changed in the slicing criteria. The results
presented in Table 6 have been obtained based on manual
slice computations, as well as that obtained using Archlice.
The same slicing criterion was used in both the cases, and
slices obtained in both approaches (manual and using
Archlice) were compared to validate the correctness of our
algorithm and the implementation. It should be noted here
that as the procedure for manual slice computation is very
tedious, we have considered approximately 17 percent
(17,441 out of 102,592) of the total slicing criteria during
manual slice computation in comparison to those slicing
criteria considered with Archlice.
Table 7 summarizes the average runtime requirements
and overhead costs of the DSUAM algorithm. From the
experimental results, it can be observed that the average
runtime requirement increases sublinearly with model size.
Fig. 18 presents this result graphically. The increase in
runtime with model size is possibly due to the additional
time needed with the increased size of the constructed DOM
tree resulting from parsing the XML representations of the
model. This increases the average runtime to execute Phase 1
762
VOL. 37,
NO. 6,
TABLE 4
Sizes and Descriptions of Models and Slicing Criteria Used in Experiments
TABLE 5
Effect of Slicing Criteria on the DSUAM Slice Size with Varying DM
TABLE 6
Models and Their Corresponding MDG Sizes (Consolidated), and Impact of Slicing Criteria on DSUAM Slice Size
of the DSUAM. Moreover, any large-sized UML model

would finally require traversal of a large MDG during Phase 2
and contribute to increased average runtime of DSUAM.
Table 8 summarizes the memory requirements of the

DSUAM algorithm. These results have been plotted in Fig. 19.
The plot of Fig. 19 shows that the average memory
763
TABLE 7
Average Runtime Requirements of DSUAM Algorithm
TABLE 8
Memory Requirements of DSUAM Algorithm
requirement of DSUAM increases almost linearly with model

size. This can be attributed to the fact that the model size is
described in terms of number of model elements comprising
classes, and objects and their interactions, which determine
the runtime memory requirement to maintain the data
structures for the MDG. Also, the DOM tree maintained to
construct the MDG incurs memory overhead that is of the
order of its number of nodes. The number of nodes in a DOM
tree depends on the size of an architecture. Typically, the size
of each node of a DOM tree is 24 bytes. However, Table 8 does
not show the memory (in terms of executable code size)
needed for execution of Archlice, which for our implementation is 149 KB and remains almost constant for all cases.
Moreover, our technique represents every class using a
unique class access (CA) node in the MDG. This is irrespective
of the number of objects of a class existing across various
interactions. This obviates the necessity to create additional
nodes in case of repeated instantiation of any architecture
classes and their objects. This ensures that the data structures
TABLE 9
Summary of Results on Handling Large-Sized UML Models Using Our Four Approaches Proposed in Section 6.6
764
VOL. 37,
NO. 6,
Fig. 18. Increase in average runtime of DSUAM with increase in model

size.
Fig. 19. Increase in memory requirements of DSUAM with increase in

model size.
used to maintain an MDG remain bounded by the number of

classes. Taking all these factors into consideration, we feel
confident that Archlice can be used to slice large architectures.
Table 9 presents a summary of results obtained for our
four approaches (see Section 6.6) proposed for handling large
UML models. Out of the experimental models considered,
we have presented only three of the largest experimental
models (see models 8, 9, and 10) listed in Tables 1 and 2,
respectively. The aforementioned results obtained for our
experimental models depict the impact of using each of those
four approaches on the corresponding graph size, number of
graph(s) needed to represent a model, memory required to
store those graphs, time needed to execute Phases 1 and 2 of
DSUAM, as well as their effectiveness to compute dynamic
slices for large UML models. Based on the results depicted in
Table 9, we have the following conclusions:
impact on the runtime of each of the phases, and

the resultant effectiveness (speed up) on computing
dynamic slices using DSUAM. These results have
been depicted in columns 7-11 in Table 9. It should
be known from columns 9 and 10 that the average
runtime of DSUAM decreases while using Approach I. However, for Approaches II-IV, the average
runtime of DSUAM is comparably higher. At the same
time, the ratio computed in column 11 indicates that
when MDG is constructed using Approaches II-IV,
though the runtime of DSUAM is higher, the effective
time to compute dynamic slices is considerably lower
than Approach I for large-sized models. This is also
indicative (as can be seen from column 7) that the
runtime of Phase 1 to construct MDG is higher
through Approaches I-IV, which actually is responsible for lowering the runtime of Phase 2 of
DSUAM in each of the cases.
Approach I constructs a single large graph (see

column 4) for each of the models in comparison to
the other three approaches. Column 4 depicts the
average number of nodes in a graph(s) representing
a corresponding model. For a model comprising
2,457 model elements, the average number of nodes
in the corresponding MDG constructed using Approach I has 1,511 nodes. On the other hand, in case
of Approaches II-IV, the average number of nodes in
the partial graphs used to represent the corresponding MDG is reduced to 80, 80, and 53 nodes,
respectively. It should be noted that the number of
partial graphs representing an MDG in each of the
Approaches II-IV has been given in brackets in
column 3 of Table 9.
In comparison to the approach for MDG construction presented in Section 6.1, Approach I conserves
memory space for each of the considered models;
however, Approaches II-IV require more memory.
These results have been depicted in column 6, which
shows negative percentages (indicates decrease in
memory requirement) for Approach I and positive
percentages for the remaining three approaches.
The Phase 1 of DSUAM (see Section 6.2) constructs the
MDG using our approach presented in Section 6.1.
However, we considered each of the Approaches I-IV
to construct the MDG in Phase 1 of DSUAM to find its
7.5 Analysis of Experimental Results

In this section, we present an analysis of the experimental
results presented in the previous section. The empirical data
obtained for the 10 UML models considered in our model
slicing experiments have been plotted in Figs. 18, 19, 20, 21, 22,
23, 24. In addition, an understanding of those experimental
data would give an insight into the adequacy of the obtained
results for different practical purposes.
Fig. 20a presents a histogram showing the UML model
sizes NME and their corresponding MDG sizes (NN Nbs
D ). The
histogram reveals that with increase in the model size, the
MDG for that model also increases. Though the MDG is
constructed based on the UML model, the plot in Fig. 20a
shows the difference (NN Nbs
D NME ) between the model
and its MDG sizes. The size difference in terms of the number
of MDG nodes and edges to the corresponding number of
model elements arises due to the following factors:
.
The implicit dependencies based on the class

relations in a model get explicitly represented in its
corresponding MDG.
The information specified in UML notes is extracted
and represented as data and operation dependencies
in the MDG.
765
Fig. 20. Plots based on experimental data presented in Tables 3 and 6. (a) Increase in MDG size with increase in model size and (b) decrease in
relevant model elements due to slicing.
The parameters and return values in operation

signatures are represented as separate nodes in the
MDG.
. The use of combined fragments in various interactions adds control dependencies along with the
corresponding data dependencies based on the
interaction operands of a fragment in the MDG.
. The operation invocations in various interactions use
different actual parameters that may have additional
data dependencies for every invocation.
The plot in Fig. 20a shows that the model and MDG sizes
for the initial two experimental models are comparable. But
then onward, the increase in MDG size is higher than the
corresponding model size. This may be due to the use of
notes anchored to classes that carry important dependency
information along with increasing number of relationships
among classes that arise for increasing model sizes. In
addition, increased message transfer in interactions for
modeling complex scenarios may equally affect the corresponding MDG sizes. With frequent use of model elements
such as combined fragments and interaction occurrences, an
increase in the MDG size becomes inevitable.
Fig. 20b plots the reduction in the relevant model

elements due to slicing. The length of arrows pointing
south in the plot indicates the extent of reduction resulted
due to slicing by DSUAM. This is possibly the main reason
that makes DSUAM slices useful in different applications.
Some conclusions regarding the slicing process and the
nature of computed slices can be derived from the changing
length of different arrows for each of the experimental
models used to analyze our DSUAM slices. In the plot of
Fig. 20b, there is a gradual increase in the length of
the arrow from left to right. For each model, the rear of the
arrow indicates the number of model elements before
slicing. In addition, on application of different slicing
criteria there is a decrease in the number of model elements
in each case. The head of the arrow indicates the minimum
number of model elements that comprise a slice for that
experimental model. Any further reduction to the slice sizes
may result in loss of precision of the computed slices.
Though for initial four experimental models the difference
between the model elements (represented in MDG) before
and after slicing is negligible, it gets more prominent for the
remaining six experimental models. This reveals the fact
Fig. 21. Decrease in average number of dependencies among model

elements due to slicing by DSUAM.
Fig. 22. Change in average slice size with increase in number of slicing
criteria used with parameter DM NULL .
766
VOL. 37,
NO. 6,
criteria used with parameter DM FEW .
criteria used with parameter DM ALL .
that increased model sizes and the use of a large number of

varying slicing criteria together reduce the average number
of model elements in the computed dynamic slice.
MDG uncovers many implicit dependencies among
model parts, along with the explicit dependencies that are
directly represented from the structural and behavioral
models. For such models, the presence of large number of
dependencies limits their use in different applications.
However, the reduction in dependencies due to slicing by
DSUAM makes the computed slices favorable for practical
purposes. The sum of all such dependencies among model
elements before slicing, along with the corresponding
average number of dependencies for all slicing criteria
considered with an experimental model, have been shown
in Fig. 21. The vertical lines plot the former, and the curve
passing across all the vertical lines at the bottom of the plot
shows the latter. One possible conclusion from this plot can
be that there is a considerable reduction in the average
number of dependencies for a sliced model. This is
indicative of how the dependencies participate in the slices
computed by DSUAM. At the same time, it gives an idea
regarding the effectiveness of DSUAM in identifying
precise dependencies. This can be noted from the curve
labeled Slicing effect in the plot of Fig. 21. The
intersection points of the curve with the vertical lines
indicate the average number of dependencies on slicing,
and its comparison to the height of the vertical lines in the
plot validates the claim.
The results for three categories of slicing criteria based
on varying parameter DM were presented in the previous
section. We now present a comparative study of the
experimental results of Table 5 and, for each category, use
three histogram plots, one each for DM NULL , DM FEW ,
and DM ALL , respectively, in Figs. 22, 23, 24.
The plot of Fig. 22 for parameter DM NULL is a special
case of static slice computation. As no data values are
specified in all slicing criteria under this category, the
computed DSUAM slices become conservative and are
based on the traversal of large part of the MDG of a model.
This directly impacts the size of the slice. The large slice
sizes can be noted for the considered slicing criterion along
with adjoining long histogram bars for average slice sizes

for each of the experimental models in Fig. 22.
Figs. 23 and 24 show a considerable lower slice size with
very small histogram bars for the considered slicing criterion
in each experimental model. It is important to note the
significant scale change on the y-axis between the plots of
Fig. 22 [scale 0-3,500] and Figs. 23 and 24 [scale 0-16,000]. This
is also because, for the model slicing experiments in two
categories DM FEW and DM ALL , a large number of
slicing criterion test cases have been considered. This along
with the specification of relevant attributes to a scenario in DM
has a considerable impact on the average dynamic slice size in
these categories. This can also be seen from different ratios
computed in three columns on the right in Table 5. This
illustrates the usefulness of DSUAM slices for different
practical purposes. The decreased slice sizes can be indicative
of the effort required in different applications, like regression
testing, impact analysis, understanding of models, etc.
SUITABILITY OF DSUAM SLICES FOR DIFFERENT

APPLICATIONS
Model slices computed using DSUAM can be used in

several applications. We list a subset of such applications in
the following:
1. Metrics for UML models.
2. Understanding large architectures.
3. Early reliability prediction.
4. Impact analysis of design changes.
5. Regression testing.
6. Identifying critical model elements.
7. Testing complexity.
8. Animation.
To conserve space, we do not present our methodology to
apply DSUAM slices for each of the listed applications. The
details of different methods using DSUAM slices for a wide
range of key areas in software engineering have been
reported in [23]. In the following, we discuss the details of
two application areas listed in 1-8 above.
8.1 Impact Analysis of Design Changes

Impact analysis is the process of identifying the probable
effects of a change to a model element. Several change
impact analysis strategies require source code analysis (see,
for instance, the strategies reported in [8]), whereas a few
are model-based. A UML model-based approach to impact
analysis can be applied before a change actually takes place,
thus allowing an early decision-making and change-planning process. Due to limited space, we restrict ourselves to
only a few relevant issues and omit the details of our impact
analysis methodology using model slices.
We can summarize a changed model as any modifications to a model arising from error corrections, design
improvements, or requirement changes. In the following,
we give a list of changes in behavioral models that can be
identified using our methodology:
Addition and removal of messages in an interaction.
Addition of new objects and removal of existing
objects from an interaction.
3. Addition of fragments and interaction use, and their
removal, if any, in an interaction.
4. Changes in definition of an interaction, by use of
overloaded operations.
5. Change in data dependencies of an interaction when
a structural model is changed.
We use the following terminology in the impact analysis
in software models: The architectural model before applying
changes of any type is referred to as INITIAL. The
architecture obtained after incorporating changes in INITIAL
is referred to as CHANGED. Let GINIT IAL and GCHANGED be
their respective MDGs. Dynamic slice DAMS is computed
using GINIT IAL , and DAMS0 is computed using GCHANGED . We
briefly outline the steps in our method of impact analysis
using DSUAM model slices in the following:
1.
2.
Compute dynamic model slices DAMS and DAMS0 by

applying the same slicing criterion SCd on GINIT IAL
and GCHANGED , respectively.
Find the difference between DAMS and DAMS0 . This
can identify the model element changes of the types
listed in 1-5 above.
After model element changes have been detected in
CHANGED with respect to INITIAL, the next step is
to determine what model elements could be
directly, or indirectly (through transitive closure)
impacted in CHANGED by each model element
change. This can be achieved using a rule-based
strategy reported in [9].
8.2 Regression Testing

In this section, we discuss how regression testing of
architectures can be an important application of the model
slices computed by our slicing algorithm.
Software architecture maintainers (or architects) often
need to perform regression testing of architectures, that is,
retesting a architecture after a modification. The goal of
regression testing is to ensure that the design level architectural bug fixes, and newly added functionality in interactions do not adversely affect the correctness of the original
functionalities. Regression testing usually involves execution
of large architectural UML specifications on a large number
767
of test cases; thus it can be expensive. Many approaches to

regression testing have been proposed [5], but almost all of
them have been based on analysis of the program code. Our
proposed approach to perform regression testing of models
can be applied in the early as well as later phases of software
development to support maintenance activity.
We use the following terminology in our approach to
regression testing of software architectures: The previously
working version of an architectural model is referred to as
OLD. The architecture obtained by modifying OLD is referred
to as NEW. Let GOLD and GNEW be their respective MDGs. A
test suite is a set of test cases that can be applied to the UML
specification. Test suite T SOLD is the test suite used to test
OLD and test suite T SNEW is the test suite used to test NEW.
Regression testing involves creating a test set T SNEW to
validate NEW and then running NEW on T SNEW . In practice,
test suite T SNEW typically contains all of T SOLD plus new
tests designed to test the new functionality added to NEW.
Running NEW on all these tests is usually very expensive. In
case of regression testing of architectures, we need to ensure
that the test cases and the architectural model slices from
their execution on OLD are available to the architect.
Incremental regression testing attempts to exploit this
information in two ways. First, if a new interaction can be
tested by an existing test case, then the cost of construction of
a new test case can be avoided. For this reason, many
techniques attempt to maximize the reuse of tests from
T SOLD . Second, it may be asserted that, for a subset of T SOLD ,
NEW will produce the same output as OLD, then the
potentially costly execution of NEW on this subset can be
avoided. This occurs, for example, if unchanged interactions
in the UML specification are executed by the test and the
slices do not contain model parts from any newly added
interactions, or any other new model elements.
Our method to incremental regression testing of software
architectures is based on Binkleys approach [7] of applying
program slicing to regression testing. Our approach is
essentially an adaptation that makes it suitable for regression testing using architectural model slicing. Our method
consists of the following steps:
Identify a set of affected interactions of NEW based on
the computed model slices using GNEW in comparison
to the model slices computed using GOLD .
2. For architecture NEW, identify a subset of T SOLD
that tests the affected interactions.
3. Identify untested interactions of NEW that must be
covered by new tests and those architectural slices of
NEW that contain the untested interactions.
4. Create new tests for the uncovered interactions of
NEW.
5. Run NEW on T SNEW , the union of the tests
produced in Steps 2 and 4.
The following is a brief explanation of how our approach
works:
1.
Step 3 is performed by running NEW on the tests

from Step 2 and marking the interactions that are
executed. The unmarked interactions are those
identified by Step 3.
The size of T SNEW can be minimized.
768
.
.
To revalidate the functionality inherited from OLD

(i.e., to ensure that no errors are introduced into
NEW), T SOLD can be a subset of T SNEW .
If T SOLD is adequate for OLD, then T SNEW should
similarly be adequate for NEW.
To perform Step 1, a mapping between the interactions of OLD and NEW is required, and this will also
affect the corresponding MDGs GOLD and GNEW ,
respectively. We can either develop such a mapping
prior to testing and take it as an input, or it can be
done during testing.
COMPARISON WITH RELATED WORK
Although program slicing [37], [40], [41] has been widely

studied in the literature, little work has been done with
respect to UML models. Architecture slicing of ADL
architectural models has been investigated by Stafford et al.
[34], [35], Zhao [44], and Kim [19]. Korel [21], Langenhove
[26], and Ojala [33] report a work on slicing state-based
models. Those are not directly comparable to our work since
most of those use architecture descriptions using some ADLs
or use some form of FSMs to consider architectures, whereas
we consider architectures represented in UML notation. The
architectures used in those techniques do not clearly
distinguish between the structural and behavioral aspects
of a system. This does not allow the computed architectural
slices to accurately consider the dependencies existing
among different model elements. Kagdis [15] work focuses
on slicing UML class diagrams and, on the other hand, Wu
and Yi [11] report a dependence analysis technique for class
diagrams. These two approaches again are not directly
comparable to our work since they do not consider any
behavioral information from the UML models. In addition,
Bae et al. [3] report a work on metamodel slicing. In the
absence of any directly comparable work, we compare our
technique with the existing architectural and model slicing
methods reported for other ADLs and EFSM architectural
models.
Our algorithm for dynamic slicing of UML architectural
models incorporates several novelties as compared to other
work reported in the literature. One important novelty is in
the computation of a slice based on consideration of
structural and behavioral models together. The computed
slice is based on the dependencies existing among different
model elements that are distributed across various UML
model views. Slicing based on extraction of such model
information can efficiently correlate different model parts or
its elements and help understand how changing any one of
them will impact the rest of the model architecture.
The graph representations used in [43], [44] are based on
information flow. Stafford et al. [34] construct a dependence
table for a model description and use it as an intermediate
representation to understand the ways in which two
architectural elements can be related. However, those in
[17], [18], [19] essentially use an event-based ADL executable
specification rather than any intermediate representation.
These representations do not distinguish among the various
control, data, communication, or event dependencies that
arise among components and connectors. There is therefore
always a possibility of computation of an inaccurate slice.
Wang et al. [39] use Extended Hierarchical Automata (EHA)
as an intermediate representation, which is a hierarchical
VOL. 37,
NO. 6,
formal automata. In addition, they use different model

characteristics to identify the dependencies in the statecharts
instead of using the model elements. On the other hand,
Ojala [33] uses a control-flow based representation to capture
all the possible executions from the UML state machines. In
comparison, our MDG is a multigraph representation and is
substantially different from all the other existing representations. It takes care of various model dependencies along with
identifying the data dependencies extracted from various
UML architectural models.
One parameter that is important to any slicing technique
is the composition of its slicing criterion. Different
techniques consider different features from an architectural
model, which affects how a slicing criterion is framed and
the elements in the resultant slice as well. Stafford et al. [34]
define a slicing criterion for an architectural description as a
set of ports of a component. On the other hand, Zhao [43],
[44] uses two forms of slicing criterion, viz., a set of ports of
a component or a set of roles of a connector for an
architectural specification. This difference in the slicing
criterion used by Stafford et al. [34] allows the slices
computed by Zhao [44] to be more informative and useful.
At the same time, the slices computed by Zhao [44] would
cover the effect of changes in connectors, along with the
changes in the system components. However, the work in
Zhao [43] is similar to a chaining technique discussed in
Stafford et al. [34]. Moreover, Ojala [33] uses a set of
transitions from a collection of UML state machines as a
slicing criterion to compute slices. Wang et al. [39] define
their slicing criteria based on the states, as well as
corresponding transitions from state models. We use a
triplet of the form [class, scenario, data values] to
define a slicing criterion, and therefore, it is comparatively
different than the others.
Korel et al. [21] compute static model slices of EFSM
models and then apply a slice reduction step to the computed
slice. Wu and Yi [11] compute static dependence relations
among the classes represented in UML class diagrams and,
based on this, they compute static slices. Kagdi et al. [15] also
focus on model slicing by considering the structural
information from UML class diagrams only. However, both
[11], [15] are designed for a general-purpose goal, that is,
simply finding all the relevant classes for a given class. We
found that just a simple use of their algorithms to our
problem can lead to incomplete diagram-specific metamodels. That is, it is not possible to develop a UML-based slicing
technique based on metamodel slices obtained from using
their approaches. For example, if we slice the Class with
their approach, Class cant have attributes. Because Class
doesnt have attributes directly in UML metaclass and
StructuralClassifier, which is a superclass of Class,
has attributes, they do not consider classes as types along
with transitive generalization and/or association relationships. In comparison to [11], [15], our slicing technique is
based on an intermediate metamodel representation constructed from structural and behavioral models, and
computes dynamic model slices. In addition, DSUAM can
be easily modified to compute static slices as well. At the
same time, our technique overcomes the overhead of a slice
reduction step applied by Korel et al. [21].
Langenhove [26] considers only the statechart models in
comparison to our technique that uses both the structural
and behavioral models. However, they compute static slices
769
TABLE 10
Summary of Comparison with Related Work
in presence of concurrency and communication, which is not

considered at present in our technique. Moreover, their
method of computing slices focuses on reduction of interference dependencies, which are a form of data dependencies. At this point, it is to be noted that the work in
Langenhove [26] and Ojala [33] are not directly comparable.
The former deals with slicing statecharts with orthogonal
regions while the latter performs slicing on a CFG constructed using the state-machines in a UML model. In
addition to handling interference dependencies during
slicing by Langenhove, data and control dependencies are
also addressed by Ojala. This is in contrast to our technique
that considers a number of different structural and behavioral dependencies, which also includes the data and control
dependencies among model elements, and therefore possibly has a wider scope of application. One exception to this is
that we do not consider state models of an object in this
present work, and plan to take it up as a future work.
Bae et al. [3] consider static slicing of a UML metamodel as
against our technique that uses a UML model for a system to
compute its dynamic slice. This limits Baes techniques
usefulness in extracting specific features for a diagram
metamodel. In comparison, our technique can use information available in different models together to identify the
relations and dependencies among them in the process of
model slicing. In summary, the main objective of Bae et al. is

to manage the complexity of the UML metamodel by
modularizing the metamodel into small metamodels, which
is also the computed slice. This objective is different from our
technique, which considers model dependencies based on a
set of values (or model data) to decide a scenario execution,
and this same information is further used to compute a
dynamic slice.
The worst-case time and space complexity for the
architecture slicing algorithms reported by Zhao [43], [44]
is quadratic in the number of components, connectors, and
the attachments. The computation of architecture slice in
[17], [18], [19] is based on filtering events depending on the
slicing criterion. The DSAS algorithm of Kim et al. [17],
[18], [19] needs ON 2 , space in the worst case and ON
time to extract architecture slices, where N is the total
number of event occurrences. Note that N may be
unbounded for large systems containing event cycles.
The space and time complexity of our DSUAM algorithm
is OT2 (see Section 6.3, (10) and (14)), where T is the
number of model elements represented as nodes in an
MDG. DSUAM does not incur any additional space
overhead at runtime as no new nodes are added to the
MDG during the process of slice computation.
770
We summarize the comparison of related work in Table 10.

It can be noted from the techniques listed in Table 10 that each
technique uses a different form of model specification (see
column 2 of the table) and different intermediate representation (see column 5 of the table). In addition, the nature of the
slicing criterion (see column 6 of the table) is different for
different techniques, as are the respective resultant slices.
This makes it difficult to attempt a direct comparison
between them. However, the type elements of the computed
slices for different techniques are summarized in the last
column of Table 10 along with the type of the slices (see
column 4 of the table). We summarize our work in the last row
shown as Present work in Table 10. It can be seen that
except for Kims [17], [18], [19] work, all other considered
approaches compute a static slice, while we compute
dynamic as well as static slices using DSUAM. The intermediate representation used in almost all the related work
considers only the structural aspects of a model. On the other
hand, our MDG representation considers structural as well as
the behavioral aspects in a UML model. This is also evident
from the nature of our slicing criteria, as well as the
composition of our computed slices.
10 CONCLUDING REMARKS AND FUTURE WORK

We have presented a technique for dynamic slicing of UML
architectural models. Slicing UML architectural models is a
difficult problem since the model information is distributed
across several model views with implicit dependencies
among them. We first construct an intermediate representation called MDG by synthesizing information present in the
structural and behavioral models of an architectural design.
Our DSUAM algorithm uses the MDG representation to
compute dynamic slices. The computed slices can be used for
studying the impact of design changes, reliability prediction,
understanding large architectures, regression testing, etc.
We are now trying to enhance our intermediate model by
incorporating the state information from behavioral models
for improving the precision of the computed dynamic slices.
This requires considering UML state-machines that are used
for modeling the discrete behavior of an object through
finite-state transitions. However, we plan to take them into
consideration in the process of computing a slice only when
the corresponding objects in an interaction exhibit complex
state-based behavior. Such states and transitions are critical
in deciding specific operation calls based on the conditions
arising during a scenario execution. Moreover, state induced
data dependencies would be incorporated into the MDG in
addition to the existing dependencies, and would impact the
precision of the computed slices.
With the growing importance of domain-specific architectural models, we plan to extend DSUAM algorithm for
slicing SysML models. The extension to slice SysML models
involves additional handling of some systems engineering
features by DSUAM. This is due to the fact that SysML is
essentially a UML profile that represents a subset of UML2
along with some extensions. Examples of a few such
extensions [36] include: 1) The constructs like blocks in
SysML reuse and extend the UML classes and may include
both structural and behavioral features. 2) SysML has
introduced an extension to a comment called rationale to
capture decisions. Besides, another extension called problem
is introduced to reflect a problem or issue that can be
VOL. 37,
NO. 6,
attached to any model element. 3) Complex scenarios may

require decomposition of lifelines. The changes that need to
be made in DSUAM to handle these extensions for slicing
SysML models include the following:
The extensions listed above will require the representation of such model elements from SysML
models into the MDG.
2. Though comment extensions rationale and problem do
not have any defined syntax for their associated texts,
we need to define them, along with their semantics
(like in Section 5.2), to enable their use in slicing.
3. The changes in 1 and 2 will incorporate new
dependencies into the MDG, and their corresponding semantics need to be defined then.
Another possible direction of future work can be an
extension to DSUAM to compute slices for componentbased software architectures. Moreover, it is possible to
generate an equivalent source code from UML models
using available IDEs (e.g., NetBeans IDE) or XDEs (e.g., IBM
Rational Rose XDE Developer). In such a case, one can slice
an architectural model by slicing the corresponding source
code using the existing code-based slicing techniques [20],
[37], [40], [41], rather than directly slicing the models. After
the code-based slice is computed, it can then be converted
to the corresponding model slice. This can also serve as a
validation for the computed model slices using the
traditional program slicing methods.
1.
ACKNOWLEDGMENTS
The authors are grateful to the anonymous referees for their
detailed comments and insightful suggestions, which
helped in refining and improving the presentation of the
paper. The authors thank the staff of the Software Lab,
Computer Science and Engineering Department of the
Indian Institute of Technology Kharagpur, West Bengal,
India, for extending all support to implement Archlice and
to perform model slicing experiments. Aritra Nayak of
MNIT, Allahabad, India, also deserves a big thank for his
programming support.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
R.B. Allen and D. Garlan, A Formal Approach to Software

Architectures, Proc. IFIP 12th World Computer Congress on
Algorithms, Software, ArchitectureInformation Processing, vol. 1,
pp. 134-141, 1992.
R.J. Allen, A Formal Approach to Software Architecture, PhD
thesis, School of Computer Science, Carnegie Mellon Univ., Jan.
1997.
J.H. Bae, K. Lee, and H.S. Chae, Modularization of the UML
Metamodel Using Model Slicing, Proc. Fifth Intl Conf. Information
Technology: New Generations, pp. 1253-1254, 2008.
J. Bang-Jensen and G. Gutin, Digraphs Theory, Algorithms and
Applications. Springer-Verlag, Aug. 2007.
B. Beizer, Software Testing Techniques, second ed. Van Nostrand
Reinhold, 1990.
D. Bell, UML Sequence Diagram, Elect. Release, http://
www-128.ibm.com/developerworks/rational/library/3101.html,
Feb. 2004.
D. Binkley, The Application of Program Slicing to Regression
Testing, Information and Software Technology, vol. 40, nos. 11/12,
pp. 583-594, 1998.
S.A. Bohner and R.S. Arnold, Software Change Impact Analysis.
IEEE CS Press, 1996.
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
L.C. Briand, Y. Labiche, L. OSullivan, and M.M. Sowka,

Automated Impact Analysis of UML Models, J. Systems and
Software , vol. 79, no. 3, pp. 339-352, 2006.
P. Clements, R. Kazman, and M. Klein, Evaluating Software
Architectures: Methods and Case Studies. Addison Wesley Professional, Oct. 2002.
W. Fangjun and Y. Tong, Dependence Analysis for UML Class
Diagrams, J. Electronics (China), vol. 21, no. 3, pp. 249-254, May
2004, doi 10.1007/BF02687879.
D. Gasevic, N. Kaviani, and M. Hatala, On Metamodeling in
Megamodels, Model Driven Eng. Languages and Systems. Springer,
Sept. 2007.
T. Girba, J.-M. Favre, and S. Ducasse, Using Meta-Model
Transformation to Model Software Evolution, Electronic Notes
in Theoretical Computer Science, vol. 137, no. 3, pp. 57-64, Sept.
2005.
Object Management Group, Unified Modeling Language Specification, version 2.0, www.omg.org, Aug. 2005.
H. Kagdi, J.I. Maletic, and A. Sutton, Context-Free Slicing of
UML Class Models, Proc. 21st IEEE Intl Conf. Software Maintenance, pp. 635-638, 2005.
G. Keith, H. Andrew, and M. Malcolm, Software Architecture
Visualization: An Evaluation Framework and Its Application,
IEEE Trans. Software Eng., vol. 34, no. 2, pp. 260-270, Mar./Apr.
2008.
T. Kim, Y.-T. Song, L. Chung, and D.T. Huynh, Dynamic
Software Architecture Slicing, Proc. 23rd Intl Computer Software
and Applications Conf., pp. 61-66, 1999.
T. Kim, Y.-T. Song, L. Chung, and D.T. Huynh, Software
Architecture Analysis Using Dynamic Slicing, Proc. AoM-IAoM
17th Intl Conf. Computer Science, Aug. 1999.
T. Kim, Y.-T. Song, L. Chung, and D.T. Huynh, Software
Architecture Analysis: A Dynamic Slicing Approach, J. Computer
and Information Science, vol. 1, no. 2, pp. 91-103, 2000.
B. Korel and J. Laski, Dynamic Program Slicing, Information
Processing Letters, vol. 29, no. 3, pp. 155-163, Oct. 1988.
B. Korel, I. Singh, L. Tahat, and B. Vaysburg, Slicing of StateBased Models, Proc. Intl Conf. Software Maintenance, pp. 34-43,
2003.
J. Koskinen, E. Makinen, and T. Systa, Implementing a
Component-Based Tool for Interactive Synthesis of UML
Statechart Diagrams, Acta Cybernetica, vol. 15, no. 4, pp. 547565, 2002.
J.T. Lallchandani, Slicing UML Models, PhD thesis, Indian Inst.
of Technology Kharagpur, May 2010.
J.T. Lallchandani and R. Mall, Dynamic Slicing of UML Models,
Technical Report IIT-CS08-SE-14, Indian Inst. of Technology
Kharagpur, Apr. 2008.
R. Lammel, S. Kitsis, and D. Remy, Analysis of Xml Schema
Usage, Proc. Conf. XML 2005. Nov. 2005.
S. Van Langenhove, Internal Broadcasting to Slice UML State
Charts: As Rich as Needed, Proc. Abstracts of the FNRS
Contact Day: The Theory and Practice of Software Verification, Oct.
2005.
R. Mall, Fundamentals of Software Eng., second ed. PHI Learning
Private Limited, Aug. 2008.
N. Medvidovic, D.S. Rosenblum, D.F. Redmiles, and J.E. Robbins,
Modeling Software Architectures in the Unified Modeling
Language, ACM Trans. Software Eng. and Methodology, vol. 11,
no. 1, pp. 2-57, Jan. 2002.
N. Medvidovic and R.N. Taylor, A Classification and Comparison Framework for Software Architecture Description Languages, IEEE Trans. Software Eng., vol. 26, no. 1, pp. 70-93, Jan.
2000.
D. Milicev, Automatic Model Transformations Using Extended
UML Object Diagrams in Modeling Environments, IEEE Trans.
Software Eng., vol. 28, no. 4, pp. 413-431, Apr. 2002.
G.B. Mund, R. Mall, and S. Sarkar, An Efficient Dynamic
Program Slicing Technique, Information and Software Technology,
vol. 44, no. 2, pp. 123-132, 2002.
N.M.Inc., Magicdraw UML v11.6, http://www.magicdraw.
com., 2010.
V. Ojala, A Slicer for UML State Machines, Technical Report
HUT-TCS-B25, Helsinki Univ. of Technology, Laboratory for
Theoretical Computer Science, 2007.
771
[34] J. Stafford, D. Richardson, and A. Wolf, Aladdin: A Tool for

Architecture-Level Dependence Analysis of Software Systems,
Technical Report CU-CS-858-98, Dept. of Computer Science, Univ.
of Colorado, Apr. 1998.
[35] J. Stafford, A. Wolf, and M. Caporuscio, The Application of
Dependence Analysis to Software Architecture Descriptions,
Lecture Notes in Computer Science, pp. 52-62, Springer, 2003.
[36] SysML, OMG Systems Modeling Language (OMG SysML), v1.1,
OMG, Nov. 2008.
[37] F. Tip, A Survey of Program Slicing Techniques, J. Programming
Languages, vol. 3, no. 3, pp. 121-189, Sept. 1995.
[38] UML, Unified Modeling Language Superstructure Specification,
v2.2, OMG, Feb. 2009.
[39] J. Wang, W. Dong, and Z.-C. Qi, Slicing Hierarchical Automata
for Model Checking UML Statecharts, Proc. Fourth Intl Conf.
Formal Eng. Methods: Formal Methods and Software Eng., pp. 435-446,
Oct. 2002.
[40] M. Weiser, Program Slices: Formal Psychological, and Practical
Investigations of an Automatic Program Abstraction Method,
PhD thesis, Computer and Comm. Sciences Dept., Univ. of
Michigan, 1979.
[41] M. Weiser, Program Slicing, Proc. Fifth IEEE Intl Conf. Software
Eng., pp. 439-449, 1981.
[42] M. Weiser, Program Slicing, IEEE Trans. Software Eng., vol. 10,
no. 4, pp. 352-357, July 1984.
[43] J. Zhao, Using Dependence Analysis to Support Software
Architecture Understanding, New Technologies on Computer Software, pp. 135-142, Intl Academic Publishers, Sept. 1997.
[44] J. Zhao, Applying Slicing Technique to Software Architectures,
Proc. Fourth IEEE Intl Conf. Eng. of Complex Computer Systems,
pp. 87-98, Aug. 1998.
[45] J. Zhao, On Assessing the Complexity of Software Architectures, Proc. Third Intl Software Architecture Workshop, pp. 163-166,
Nov. 1998.
[46] J. Zhao, A Slicing-Based Approach to Extracting Reusable
Software Architectures, Proc. Conf. Software Maintenance and
Reeng., pp. 215-223, Oct. 2000.
Jaiprakash T. Lallchandani is a senior research fellow in the Department of Computer
Science and Engineering, Indian Institute of
Technology (IIT) Kharagpur, India.
R. Mall received the BE, ME, and PhD degrees

from the Indian Institute of Science (IISc),
Bangalore, India. He is currently a professor in
the Department of Computer Science and
Engineering, Indian Institute of Technology
(IIT) Kharagpur, India. He is a member of the
domain experts board of the International
Journal of Patterns (IJOP). He was the general
chair of IEEE Indicon 2004 and program chair for
CIT 2005. He has also been a program
committee member for a large number of international conferences.
He has published more than 100 refereed research papers and has
authored two books. His current research interests include analysis and
testing of object-oriented programs. He is a senior member of the IEEE.
. For more information on this or any other computing topic,

please visit our Digital Library at www.computer.org/publications/dlib.

Lallchandani 2011

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lallchandani 2011

Uploaded by

Copyright:

Available Formats

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

A Dynamic Slicing Technique

architecture of an object-oriented software system

. The authors are with the Department of Computer Science and

1.1 Program Slicing

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

that input. A dynamic slicing criterion was defined to

1.2 Slicing Software Architectures

Intermediate representation: We propose an intermediate representation for a software architecture by

Fig. 1. Activity diagram of our dynamic slicing technique.

behavioral information from any UML model, and

1.4 Paper Outline

In this section, we briefly review the reported work on

in the literature address development of techniques for

slice using these calculated dependencies and the available

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

Fig. 2. Class diagram for the MDG metamodel.

based on the distance between changed model elements

FRAMEWORK OF OUR MDG METAMODEL

In this section, we present an overview of our intermediate

3.1 Elements of MDG

Fig. 3. One-to-one mapping of UML model elements to their

3.2 UML Model and Its MDG Representation

operands, and an optional guard condition. Furthermore,

3.3 System Representation Using MDG

Representation of model elements:

The classes are represented by class access (CA)

All the respective AT and OA nodes representing

In addition, the various interactions represented

MODEL DEPENDENCY GRAPH (MDG)

MDG represents both the structural as well as the behavioral

4.1 MDG Nodes

Class Access (CA) nodeA CA node is defined for

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

of UML2 superstructure specification [38], when a combined

Fig. 4. Mapping of UML model elements to their corresponding edges in

Return (RT) nodeAn RT node is defined for every

4.2 MDG Edges

with a label. The kth message in an interaction i is

implicit call to the constructor operation of the class. On the

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

corresponding notations for each of the dependencies and

4.4 Definition of MDG

We consider an extension of such a definition-use concept in

4.3 Dependency Semantics in MDG

relationship dependence edges,

For any pair of nodes u; v 2 NM , there exists an associated

Both of the nodes in the node pair are either

Both or either of the nodes in the node pair are CA

Fig. 7. Dependency semantics in MDG and their corresponding notations.

there exists control dependence from the former

4.5 An Example MDG

Let the classes in the given model be represented using

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

the MDG of Fig. 6. Moreover, I2 contains an interaction

REQUIREMENTS, CONCEPTS, AND DEFINITIONS

In this section, we first present certain aspects of structural

Presumption on the Use of Views of a UML

Requirements for Customizing Notes in

and the words in the text followed by uses and

5.3 Naming Requirements for Interactions

next section, the exact messages involved during the