On the Definition of Dynamic Software Measures
Luigi Lavazza, Sandro Morasca, Davide Taibi, Davide Tosi
Dipartimento di Scienze Teoriche e Applicate
Università degli Studi dell’Insubria
Via Mazzini 5, I-21100, Varese, Italy
{luigi.lavazza, sandro.morasca, davide.taibi, davide.tosi}@uninsubria.it
ABSTRACT
The quantification of several software attributes (e.g., size,
complexity, cohesion, coupling) is usually carried out in a
static fashion, and several hundreds of measures have been
defined to this end. However, static measurement may only
be an approximation for the measurement of these attributes
during software use. The paper proposes a theoretical frame-
work based on Axiomatic Approaches for the definition of
sensible dynamic software measures that can dynamically
capture these attributes. Dynamic measures based on this
framework are defined for dynamically quantifying size and
coupling. In this paper, we also compare dynamic measures
of size and coupling against well-known static measures by
correlating them with fault-pronenesses of four case studies.
Categories and Subject Descriptors
H.4 [Information Systems Applications]: Miscellaneous;
D.2.8 [Software Engineering]: Metrics—complexity mea-
sures, performance measures
General Terms
Measurement
Keywords
Dynamic measures, dynamic coupling, dynamic size, code
coverage
1. INTRODUCTION
The vast majority of the measures for internal software
attributes (e.g., structural size, structural complexity, cohe-
sion, coupling) have been defined in a static way. However,
the dynamic aspects of these attributes still remain to be
largely investigated. For instance, just statically looking at
the potential interactions between a software module and
the rest of a software system may not tell the entire story,
when assessing the coupling of the module. Suppose that
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
ESEM’12, September 19–20, 2012, Lund, Sweden.
Copyright 2012 ACM 978-1-4503-1056-7/12/09 ...$10.00.
39
module A has fewer static connections with the rest of the
system than module B does, but that module A at run-time
interacts with the rest of the system much more frequently
than B does. So, B may be considered to have a higher cou-
pling than A from a static perspective, while the converse
may be true from a dynamic point of view. When predicting
the number of faults found due to integration problems, the
dynamic interactions between classes may be more relevant
than the static ones.
As another example, static size measurement does not
capture the difference between heavily used and lightly used
software code and may even take into account dead code.
Routine A may be longer than another routine B, but it
may turn out that fewer lines of code are executed in A
than in B at run-time. Again, when estimating the num-
ber of faults found in a routine, dynamic size may be more
relevant than static size, as one may reasonably hypothesize
that the number of faults found increases with the number
of lines of code exercised, rather than with the sheer number
of lines of code.
Thus, it should be investigated whether dynamic measures
may be used alongside static measures in the assessment of
some software quality of interest or even if dynamic mea-
sures may be more useful than static ones. The distinction
between static and dynamic internal software measures par-
allels, from a practical point of view, the distinction between
static and dynamic analysis in software verification and val-
idation. Both kinds of analysis may be useful when look-
ing for software faults or when assessing some nonfunctional
properties, like maintainability, performance, or usability.
The definition and use of a new measure for an internal
software attribute entails two kinds of validation.
• Theoretical validation. We need to make sure that the
new measure is adequate for quantifying the software
attribute it is supposed to measure, so its values can
be given a sensible interpretation. This activity can
be carried out by using one of the available methods
used in the Software Measurement literature, namely
Measurement Theory. [8, 13] or Axiomatic Approaches
[15, 6, 9].
• Empirical validation. It is necessary to check whether
the new measure is practically useful, by showing that
it is correlated to some variable of industrial interest.
This activity can be carried out via empirical studies.
However, in the Software Measurement literature, mea-
sures have often been defined without undergoing a theo-
retical or an empirical validation. So, there exist literally
thousands of measures for which there is no assessment as
to whether they actually measure what they are supposed
to measure or whether they are really useful. The end result
is that the vast majority of measures has not survived the
definition phase.
The contribution of this paper is therefore twofold, as we
define measures for dynamic software attributes and address
both kinds of validation.

• First, we introduce a framework that can be used for

the definition of sensible measures for dynamic soft-
ware attributes, based on Axiomatic Approaches [15,
6, 9]. As such, each dynamic software attribute may
be associated with a set of necessary properties for
the measures that purport to measure that attribute.
These properties can guide software measurers in defin-
ing new measures for dynamic software attributes and Figure 1: A UML-like Class Diagram
assess the adequacy of existing ones. We have cho-
sen size and coupling due to their importance in soft- Definition 1. System. A system S is a pair S =< E, R >,
ware development. Also, size allows us to investigate where
dynamic attributes for software modules in isolation,
regardless of the existence of other modules, and cou- • E represents the set of elements of S
pling allows us to investigate dynamic attributes for
• R ∈ N E×E×T
modules related to other modules in a software sys-
tem. The measures we define for dynamic size and where T is a finite set of types of relationships (N is the set
coupling comply with the properties we proposed. of natural numbers, including 0).

• Second, we have also applied these measures to a few
software systems, to carry out an empirical investiga-
tion on whether these measures may be useful in prac-
tice for estimating fault proneness and compare their
usefulness with static measures. Our results show that
some dynamic measures can estimate fault proneness
better than traditional static measures.
The remainder of the paper is organized as follows. Sec-
tion 2 summarizes the basic concepts and notation used
throughout the paper, which were introduced in previous
work about static attribute measurement. Section 3 intro-
duces dynamic aspects needed in the modeling of dynamic
attribute measurement, via the notions of execution trace
and its underlying module. Section 4 illustrates our pro-
posed approach for the quantification of two specific dy-
namic software attributes: size and coupling. In Section
5, we define a few dynamic measures for size and coupling
and we show that they comply with the properties required
for dynamic size and coupling measures proposed in Section
4. Section 6 provides examples of use of the measures de-
fined in Section 5. Related work is concisely reviewed in
Section 7, both on coverage measures and measures that
have been defined in the literature for various internal soft-
ware attributes. Conclusions and an outline for future work
are in Section 8.
2. STATIC ATTRIBUTES: BASIC CONCEPTS
AND NOTATION
Here, we summarize the basic concepts and notation used
in [9] for the Axiomatic Approaches for static attributes,
as they are the basis for the proposal of this paper too.
We basically view a system as a multigraph, where each
arc is associated with a multiset of relationships, and each
relationship has a type.
Specifically, << a, b, t >, n >∈ R associates < a, b, t >,
i.e., a typed relationship between elements a and b, with
a natural number n, which describes how many times the
typed relationship < a, b, t > occurs in the system.
This general representation may be adapted to different
application cases. For instance, system elements (i.e., the
nodes of the graph) may denote code statements, methods,
classes, etc. The existence of a multiset of typed relation-
ships associated with each arc of the graph allows one to
model different kinds of interactions that may exist between
system elements. For instance, suppose that a system ele-
ment represents an OO class. Two OO classes may be linked
by method calls or by variable uses at run-time, so differ-
ent kinds of relationships may be needed. Also, each type
of relationship associated with an arc may have a different
cardinality. For instance, two OO classes may be linked by
5 variable uses and 20 method calls.
Figure 1 shows a system, in which we have used capital
letters to denote elements and lowercase letters to denote
relationships. For simplicity, all relationships in the graph
have the same type.
In what follows, the same symbol (e.g., ∪ for union) may
denote an operation between sets when sets of elements are
involved, or an operation between multisets when multisets
of typed relationships are involved. Even though these oper-
ations are different, no confusion will arise because there will
never be an operation whose operands are a set of elements
and a multiset of typed relationships.
Some software attributes require that parts of a system
be identified. For instance, coupling may be defined for a
specific part of the system (e.g., a class or a package) or an
entire system. These parts of a system are actually subsys-
tems that we call modules.
Definition 2. Module. Given a system S =< E, R >, a
module m =< Em , Rm > is a system such that Em ⊆ E ∧
Rm ⊆ R.

40
 Thus, for maximum generality and simplicity, a module is
simply a subsystem, with no additional characteristics (e.g.,
an interface).
Given a module m of a system S =< E, R >, the multiset
of those relationships that involve one element within m and
one element outside m is called the set of outer relationships
of m and is denoted as OuterR(m), with OuterR(m) ⊆ R.
In Figure 1, UML-like packages 1 m1 , m2 , m3 , m4 , m5 , m6 ,
may be interpreted as modules. For notational convenience,
it will be implied in the remainder of the paper that the set
of elements and the multiset of relationships of a system or
a module have the same subscript as the system or module,
unless otherwise explicitly specified. For instance, it will be
implied that m1 has the set of elements E1 and the multiset
of relationships R1 . If no subscript appears in the name
of the system or module, then no subscript appears in the
name of its set of elements and multiset of relationships.
We now define an algebra for modules, based on set and
typed multiset operations.
Inclusion. Module m1 is said to be included in module
m2 (notation: m1 ⊆ m2 ) if E1 ⊆ E2 ∧ R1 ⊆ R2 . In Figure
1, m5 ⊆ m4 .
Union. The union of modules m1 and m2 (notation: m1 ∪
m2 ) is the module < E1 ∪ E2 , R1 ∪ R2 >. In Figure 1,
m1 = m2 ∪ m3 .
Intersection. The intersection of modules m1 and m2
(notation: m1 ∩ m2 ) is the module < E1 ∩ E2 , R1 ∩ R2 >. In
Figure 1, m2 ∩ m3 is the module whose elements are classes
C and D and whose relationships are < i, 1 > and < h, 1 >.
Empty module. Module < ,  > (denoted by ) is
the empty module.
Disjoint modules. Modules m1 and m2 are said to be
disjoint if m1 ∩m2 = . In Figure 1, m3 and m6 are disjoint.
Unconnected modules. Two disjoint modules m1 and
m2 of a system are said to be unconnected if OuterR(m1 ) ∩
OuterR(m2 ) = . In Figure 1, m4 and m6 are unconnected,
while m3 and m6 are not unconnected.
Sets of axioms have been introduced based on these defini-
tions. Each set of axioms describes the properties expected
for the measures related to a specific software attribute, e.g.,
structural size, structural complexity, cohesion, coupling [6,
9].
3. EXECUTION TRACES AND DYNAMIC
MODULES
Section 2 introduced the basic concepts used for the def-
inition of static measures. In this section, we introduce the
concepts related to the dynamic aspects of systems and mod-
ules in such a way that we can introduce sets of axioms for
specific dynamic software attributes (see Section 4) in a way
that is consistent with the axiom sets for static software at-
tributes of [9].
In the context of a system, the dynamic view identifies a
specific part of the entire system, i.e., a subsystem that we
say is executed in a dynamic activity. We say that a part of
a system is “executed” to encompass different activities like
running some executable artifact such as software code and
the inspection of some artifact. Even though it is usually
classified as “static analysis” because it does not involve the
1
Note that our definition of “module” is more general than
the definition of packages in UML, which may not share
classes.
41
machine execution of software code, the inspection of a soft-
ware artifact is a dynamic activity for the software inspector
that examines the software code (or any software artifact).
Any subsystem is a module, based on the definitions of Sec-
tion 2, so we say that a module is executed in a dynamic
activity.
We assume that, during an execution, the elements and
relationships of a system are exercised in a sequence, which
we now formalize in the notion of execution trace.
Definition 3. Execution Trace. Given a system S =<
E, R > and a finite nonnegative integer number n, an exe-
cution trace tr is defined as follows:
• if n > 0, tr is a function
tr : 1..n → E ∪ R
that associates a system element or relationship with
any index value i ∈ [1..n], in such a way that, if tr(i)
is a relationship, then tr(i − 1) is the start element
of relationship tr(i) and tr(i + 1) is the end element
of relationship tr(i); throughout the paper, such an
execution trace is denoted either by its name tr or by
the ordered sequence of its values;
• if n = 0, tr is the empty trace, which is denoted
throughout the paper as .
For notational convenience, we denote
• the length n of execution trace tr as |tr|
• the set of elements appearing as components of an exe-
cution trace tr as Etr = {e ∈ E|∃i ∈ [1..|tr|]tr(i) = e}
• the set of component relationships of an execution trace
tr as Rtr = {r ∈ E|∃i ∈ [1..|tr|]tr(i) = r}.
For instance, in the system of Figure 1
tr =< A, a, C, i, D, j, B, C, e, J, f, D,
B, x, H, q, G, A, l, B, y, G, L, s, K >
is an execution trace (Formula 1).
Note that, based on the definition, a relationship may
be included in an execution trace only if it is immediately
preceded in the trace by its start element, and, whenever a
relationship is included in the trace, it is followed by its end
element. A similar requirement does not apply to elements,
though. An element may not necessarily be immediately
preceded by a transition in an execution trace, i.e., several
nodes may be contiguously found in an execution trace. For
instance, a software inspector may very well sequentially
inspect a number of software classes in isolation without
looking at the relationships that may exist between them.
Another implication of the definition of execution trace is
that there the first component of an execution trace is always
an element, if the execution trace is not empty.
Given a module m and an execution sequence tr, some of
the components of tr may belong to m, while others may
not. We introduce the notion of dynamic module of a static
module under an execution trace, to identify the part of the
module that is involved in the execution trace.
Definition 4. Dynamic Module of a Module under an Ex-
ecution Trace. The dynamic module of a static module

Figure 2: Dynamic Modules
m =< Em , Rm > under an execution sequence tr (nota-
tion DynM odule(m, tr))is composed of all of the elements
and relationships appearing in both m and tr, i.e.,
DynM odule(m, tr) =< EDM , RDM >, where EDM =
Em ∩ Etr and RDM = Rm ∩ Rtr The underlying module
m(tr) of an execution trace tr is composed of all of the ele-
ments and relationships appearing in tr.
Also, an execution trace has an underlying static mod-
ule composed of all the elements and the relationships that
appear in the execution trace.
Definition 5. Underlying Module of an Execution Trace.
The underlying module m(tr) of an execution trace tr is
composed of all of the elements and relationships appearing
in tr.
For instance, Figure 2 shows the entire underlying module
m(tr) of the execution trace tr of Formula (1). The dynamic
module of module m1 in Figure 2 under execution trace tr
of Formula (1) is the portion of Figure 2 strictly contained
within the border of module m1 .
Like with modules, we now introduce an algebra that can
be used to work with execution traces. We introduce the
operations of that algebra intuitively and formally.
Inclusion. Intuitively, an execution trace tr1 is included
in execution trace tr2 if it is possible to obtain tr1 by elimi-
nating elements of tr2 .
Formally, execution trace tr1 is said to be included in exe-
cution trace tr2 (notation: tr1 ⊆ tr2 ) if ∀i, j ∈ 1..|tr1 |, ∃s, t ∈
1..|tr2 |(i < j ∧ s < t ∧ tr1 (i) = tr2 (s) ∧ tr1 (j) = tr2 (t)). Exe-
cution trace tr1 ⊆ tr2 is also said to be a subtrace of execu-
tion trace tr2 . As a consequence, given any trace tr,  ⊆ tr,
i.e., the empty trace is included in all other traces. For in-
stance, < C, i, D, j, B, C, e, J, H, q, G, A, l, B, y, G >⊆ tr for
trace tr of Formula (1).
Union. Intuitively, the union of two traces tr1 and tr2
combines those two traces by interleaving the elements of
tr1 and tr2 in a specified way.
Formally, the union of traces tr1 and tr2 according to
indexing in (i.e., the function that specifies how the two
traces are to be interleaved) is a trace tr12 (notation: tr12 =
tr1 ∪in tr2 ) such that the indexing schema in is a surjective
function in : [1..|tr1 | + |tr2 |] → [1..n] for some integer value
of n that provides an index in tr12 for each component of
42
either tr1 or tr2 in such a way that ∀i ∈ [1..|tr1 |]tr12 (in(i)) =
tr1 (i), ∀i ∈ [|tr1 | + 1..|tr1 | + |tr2 |]tr12 (in(i)) = tr2 (i), and
∀k ∈ [1..|tr1 | + |tr2 |], ¬∃i ∈ [1..|tr1 |], j ∈ [|tr1 | + 1..|tr1 | +
|tr2 |](in(i) = in(j) ∧ tr1 (i) = tr2 (j)). As a consequence, tr1
and tr2 are subtraces of tr12 . Whenever the specific indexing
chosen is immaterial, we use the abbreviated notation tr12 =
tr1 ∪ tr2 . As an additional property, for any given indexing,
we have tr = tr ∪ , i.e., the empty execution trace is the
null element of this algebra of traces.
Note that, if a specific run-time execution of a software
system is modeled by an execution trace, the effect of a set of
run-time executions of the software system is still modeled
by an execution trace, obtained as the union of the execution
traces corresponding to the individual run-time executions.
For instance, < A, a, C, i, D, j, B, B, x, H, q, G, A, l, B, y, G >
∪ < C, e, J, f, D, L, s, K >= tr for trace tr of Formula (1).
Concatenation. Intuitively, the concatenation of traces
tr1 and tr2 is simply the trace obtained by adding trace tr2
at the end of trace tr1 .
Formally, the concatenation of traces tr1 and tr2 is the
trace tr12 = tr1 · tr2 such that |tr12 | = |tr1 | + |tr2 | and
∀i ∈ [1..|tr1 |]tr12 (i) = tr1 (i) and ∀i ∈ [|tr1 | + 1..|tr1 | +
|tr2 |]tr12 (i + |tr1 |) = tr2 (i). So, a concatenation is a spe-
cial case of union with a specific indexing, in which the
components of tr2 all appear in tr12 after the components
of tr1 . This is the only operation in this algebra that is
not commutative, as we may very well have tr12 = tr1 ·
tr2 = tr2 · tr1 = tr21 . For instance, < A, a, C, i, D, j, B, >
· < C, e, J, f, D, B, x, H, q, G, A, l, B, y, G, L, s, K >= tr for
trace tr of Formula (1).
Intersection. Intuitively, the intersection of traces tr1
and tr2 is the longest trace that is included in both tr1 and
tr2 .
Formally, the intersection of traces tr1 and tr2 is the max-
imal subtrace tr12 (notation: tr12 = tr1 ∩ tr2 ) such that
tr12 ⊆ tr1 ∧ tr12 ⊆ tr2 . Specifically, tr12 is maximal in the

sense that there does not exist another trace tr12 such that
  
tr12 ⊆ tr1 ∧ tr12 ⊆ tr2 and tr12 ⊆ tr12 . As a consequence,
the intersection of any trace with the empty trace is the
empty trace . For instance, < A, a, C, i, D, j, B, C, e, J >
∩ < C, e, J, f, D, B, x, H, q, G, A, l, B, y, G >=< C, e, J >
for trace tr of Formula (1).
Disjoint traces. Intuitively, two traces are disjoint if
their intersection is empty.
Formally, traces tr1 and tr2 are said to be disjoint if tr1 ∩
tr2 = . For instance, < A, a, C, i, D, j, B > ∩ < I, c, J >=
.
Unconnected traces. Intuitively, two disjoint traces tr1
and tr2 are unconnected if their underlying modules are also
unconnected.
Two disjoint traces tr1 and tr2 of a system are said to be
unconnected if OuterR(m(tr1 ))∩OuterR(m(tr2 )) = . For
instance, < A, a, C, i, D, j, B > ∩ < H, q, G >= .
The algebra of traces and the algebra of their underlying
modules are related, as we now show. Suppose that m is
any module of a system S.
Inclusion: tr1 ⊆ tr2 ⇒ DynM odule(m, tr1 )
⊆ DynM odule(m, tr2 ).
Union: ∀in, tr12 = tr1 ∪in tr2 ⇒ DynM odule(m, tr12 ) =
DynM odule(m, tr1 ) ∪ DynM odule(m, tr2 ).
Intersection: tr12 = tr1 ∩ tr2 ⇒ DynM odule(m, tr12 ) =
DynM odule(m, tr1 ) ∩ DynM odule(m, tr2 ).
Disjoint traces tr1 ∩ tr2 =  ⇒ DynM odule(m, tr1) ∩
DynM odule(m, tr2 ) = 
4. AN AXIOMATIC APPROACH FOR TWO
DYNAMIC SOFTWARE ATTRIBUTES:
SIZE AND COUPLING
Here, we focus on dynamic size and coupling, by provid-
ing definitions for what we believe are necessary properties
for their measures. Therefore, we provide an axiom set for
dynamic size and an axiom set for dynamic coupling. It can
be shown that these two axiom sets are consistent with the
necessary properties for static size and coupling of [9].
4.1 Dynamic Size
Dynamic size is based on the multisets of elements appear-
ing in an execution trace of a module, as described by the
following axioms. We denote a dynamic size measure for a
given module m under execution trace tr as DynSize(m, tr),
to denote the dependence of the dynamic size of module m
on the specific execution trace tr.
First, the dynamic size DynSize(m, tr) of module m com-
posed of two possibly overlapping modules, under execution
trace tr, is not greater than the sum of the dynamic sizes of
the two modules, each taken in isolation, under tr.
Dynamic Size Axiom 1. Union of Modules. Suppose we
have two modules m1 and m2 and an execution trace tr.
The dynamic size of m = m1 ∪ m2 under tr is never greater
than the sum of the dynamic sizes of m1 and m2 under tr,
i.e.,
m = m1 ∪ m2 ⇒ DynSize(m, tr) ≤
DynSize(m1 , tr) + DynSize(m2 , tr)
For instance, DynSize(m2 ∪ m3 , tr) ≤ DynSize(m2 , tr) +
DynSize(m3 , tr) in Figure 2.
The basic idea is that the intersection of the two dynamic
modules may or may not be taken into account twice when
m is executed under tr. However, when the two dynamic
modules are disjoint, dynamic size is additive.
Dynamic Size Axiom 2. Dynamic Size Additivity. Sup-
pose we have two disjoint modules m1 and m2 and an exe-
cution trace tr. The dynamic size of m = m1 ∪ m2 under
tr is equal to the sum of the dynamic sizes of m1 and m2
under tr, i.e.,
m = m1 ∪ m2 ⇒ DynSize(m, tr) =
DynSize(m1 , tr) + DynSize(m2 , tr)
Thus, DynSize(m2 ∪ m4 , tr) =
DynSize(m2 , tr) + DynSize(m4 , tr) in Figure 2.
Several properties can be derived from these axioms. We
now list a few.
1. The dynamic size of the empty module under any ex-
ecution trace is zero.
2. The dynamic size of a module under any execution
trace is nonnegative.
3. Adding elements to a module cannot decrease its dy-
namic size under any execution trace.
43
4.2 Dynamic Coupling
Dynamic coupling is about the amount of relationships
between the elements of the dynamic module (of a mod-
ule under an execution trace) and the elements of the other
dynamic modules under the same execution trace. We de-
note a dynamic coupling measure as for a given module m
under execution trace tr as DynCoupling(m, tr), to denote
the dependence of the dynamic coupling of module m on the
specific execution trace tr.
Dynamic Coupling Axiom 1. Monotonicity.
Adding a new relationship to a module m1 or to its set of
outer relationships OuterR(m1 ) does not decrease its dy-
namic coupling if the added relationship is added to an ex-
ecution trace. So, if m2 is a module such that E2 = E1 and
tr1 ⊆ tr2 we have
OuterR(m1 ) ⊆ OuterR(m2 ) ∧ R1 ⊆ R2 ∧ tr1 ⊆ tr2 ⇒
DynCoupling(m1 , tr1 ) ≤ DynCoupling(m2 , tr)
A module with no outer relationships has zero dynamic
coupling under all execution traces, regardless of its internal
relationships.
Dynamic Coupling Axiom 2. Null Value. The coupling of
a module with no outer relationships is null under all exe-
cution traces.
When two modules are merged in a single module, the
relationships that connect them to each other become inter-
nal ones, so the dynamic coupling of the new module is not
higher than the sum of the dynamic couplings of the two
modules.
Dynamic Coupling Axiom 3. Merging of Modules. The
dynamic coupling of the union of two dynamic modules m1
and m2 under any specific execution trace tr is not greater
than the sum of the dynamic couplings of the two modules
under tr
∀tr(DynCoupling(m1 ∪ m2 , tr) ≤
DynCoupling(m1 , tr) + Coupling(m2 , tr))
Thus, DynCoupling(m2 ∪m3 , tr) ≤ DynCoupling(m2 , tr)
+ Coupling(m3 , tr) in Figure 2.
Coupling is additive for a system composed of two uncon-
nected modules.
Dynamic Coupling Axiom 4. Unconnected Modules. The
dynamic coupling of the union of two unconnected dynamic
modules under an execution trace tr is equal to the sum of
their couplings.
OuterR(DynM odule(m1 , tr)) ∩ OuterR(DynM odule(m2 , tr))
=  ⇒ ∀tr(DynCoupling(m1 ∪ m2 , tr) = DynCoupling(m1 , tr)
+DynCoupling(m2 , tr))
Thus, DynCoupling(m4 ∪m6 , tr) = DynCoupling(m4 , tr)
+ Coupling(m6 , tr) in Figure 2.
As a derived property, the dynamic coupling of a module
under any execution trace is nonnegative.
5. DYNAMIC MEASURES FOR SIZE AND
COUPLING
We now provide a few examples of dynamic measures for
size and coupling, which we use in the experiments of Section
6. Thus, an execution trace is related to a specific execution [4].
or a set of executions of a module. Here, we show that these
measures are dynamic size and coupling measures according
to the axiom sets of Section 4.
5.1 Dynamic Size Measures
Blocks: The number of blocks (i.e., the sequence of byte-
code instructions without any jumps or jump targets) ex-
ercised by the test suite. A block is considered as exer-
cised when its last instruction has been executed. A module
in this case is statically modeled as a block control-flow,
in which bytecode blocks are represented by the nodes of
the graph (i.e., the elements of the system) and control-
flow transfers between blocks are represented by the arcs
of the graph (i.e., the relationships of the system). We
now show that Blocks is a size measure according to the
axiom set in Section 4.1. First, given an execution trace
tr and the corresponding DynM odule(m, tr), let us take
two execution traces tr1 and tr2 such that tr = tr1 ∪ tr2
and, therefore DynM odule(m, tr) = DynM odule(m, tr1 ) ∪
DynM odule(m, tr2 ). The number of blocks in DynM odule(m, tr) the dynamic couplings of c and c . Finally, if, in a specific
is clearly never greater than the sum of the numbers of blocks
in DynM odule(m, tr1 ) and DynM odule(m, tr2 ), since
DynM odule(m, tr1 ) and DynM odule(m, tr2 ) may have some
blocks in common. So, Axiom 1 is satisfied. Likewise, if
modules DynM odule(m, tr1 ) and DynM odule(m, tr2 ) are
disjoint, no overlap of blocks exist and the number of blocks
in DynM odule(m, tr) is equal to the sum of the numbers
of blocks in DynM odule(m, tr1 ) and DynM odule(m, tr2 ).
So, Axiom 2 is satisfied too and Blocks is a size measure
according to the axiom set in Section 4.1.
Instructions: The number of bytecode instructions ex-
ercised. A module in this case is statically modeled as a
control-flow graph, in which bytecode instructions are rep-
resented by the nodes of the graph and control-flow transfers
between bytecode instructions are represented by the arcs of
the graph. We can prove that Instructions is a size measure
in much the same way as we proved that N umberOf Blocks
is a size measure according to the axiom set in Section 4.1,
by replacing blocks with instructions.
SLOC: The number of Java source lines of code exercised.
A module in this case is statically modeled as a control-flow
graph, in which source lines of code are represented by the
nodes of the graph and control-flow transfers between source
lines of code are represented by the arcs of the graph. We can conducted to provide a first empirical validation of the dy-
prove that SLOC is a size measure in much the same way
as we proved that Blocks and Instructions size measures
according to the axiom set in Section 4.1.
Methods: The number of distinct methods exercised. A
method is considered as exercised if at least one statement
of the method has been executed. A module is statically
modeled as a sheer sequence of methods declared in a class,
so methods are represented by the nodes of the graph. The
node representing a method is linked to the next node (which
represents the next method in the sequence) by an arc. The
proof that M ethods is a size measure is analogous to the
previous proofs.
Types: The number of distinct Java type exercised. A
Java type is considered as exercised if it has been loaded
and initialized. The proof that T ypes is is a size measure is
analogous to the previous proofs.
5.2 Dynamic Coupling Measures
We collected three dynamic coupling measures, defined in
Distinct method invocations: The count, within a
runtime session, of the total number of distinct methods
invoked by each method in each object. By modeling each
method as a module, each statement in the module as an
element, and each control flow transfer within the method
or to another method, the proof that Distinct method in-
vocations is a dynamic coupling measure according to the
axiom set of Section 4.2, can be carried out as follows: As
for Axiom 1, adding a new invocation within the class or to
its set of invocations of methods of other classes does not de-
crease its dynamic coupling if the added invocation is added
to any execution trace. A class that is not linked to any
other classes has no direct method invocations, so Distinct
method invocations is null and Axiom 2 is satisfied. Let us
now examine Axiom 3. If two classes c1 and c2 are merged
into a single class c, the invocations of methods between c1
and c2 are no longer counted as contributing to the coupling
of c towards the rest of the system in any execution trace,
so the dynamic coupling of c is not greater than the sum of
1 2
execution there are no methods invoked between c1 and c2 ,
the number of distinct method invocations of c is the sum of
the distinct method invocations of c1 and c2 , and Axiom 4 is
satisfied. So, Distinct method invocations is a coupling
measure according to the axiom set of Section 4.2.
Dynamic messages: The count, within a runtime ses-
sion, of the total number of distinct messages sent from one
object of a class to other objects. Two messages are not
distinct if their source and target classes, the method in-
voked in the target class, and the statement from which it
is invoked in the source class are the same. The proof that
Dynamic messages is a dynamic coupling measure can be
carried out along the lines as the previous proof.
Distinct classes: The count of the distinct number of
classes that a method uses within a runtime session. Here,
we can use the same modeling as for Distinct method in-
vocations and we can show that Distinct classes is a
dynamic coupling measure in a similar way.
6. EXPERIMENTING
DYNAMIC MEASURES
This section presents the results of four case studies we
namic measures we discussed above. Firstly, we present the
methodology we follow, the environmental setup and the ob-
jectives of this experimentation. Secondly, we provide and
we discuss quantitative results about size and coupling dy-
namic measures when compared against well-known static
measures.
6.1 Methodology
We selected four open-source Java projects, specifically
HttpUnit v1.7, Jakarta Commons IO v1.4, Log4J v1.2.16
and PMD v4.2.5 to evaluate dynamic size and coupling as-
pects.
HttpUnit is a tool to emulate the relevant portions of
browser behavior and allows Java test code to examine re-
44
turned pages either as text, an XML DOM, or containers of
forms, tables, and links. The considered HttpUnit release
consists of 19810 lines of code (SLOC) in 10 source pack-
ages, 286 classes and 3764 methods (after removing classes
related to test cases and methods used to profile the source
code of the application). In our experiments, we used all the
10 packages contained in the src folder of HttpUnit. How-
ever, two of them were excluded from the final computation
due to the lack of test cases.
Jakarta Commons IO is a library of utilities (such as
Input, Output, Filters, Comparators and Monitor classes)
to assist with developing IO functionality. The considered
Commons IO release consists of 2931 lines of code (SLOC) in
5 source packages, 74 classes and 422 methods (after remov-
ing classes related to test cases and methods used to profile
the source code of the application). As for this experiment,
we collected data for all the 5 packages contained in the src
folder of Jakarta.
Log4J is a package to enable logging of an application
context at runtime without modifying the application bi-
nary. The considered Log4J release consists of 11774 lines
of code (SLOC) in 22 source packages, 181 classes and 1032
methods (after removing classes related to test cases and
methods used to profile the source code of the application).
As for this experiment, we collected data only for the 10
packages contained in the src folder of Log4J equipped with
test cases.
PMD is a library to scan Java applications and look for
possible bugs, dead / suboptimal / duplicate code, and over-
complicated expressions. The considered PMD release con-
sists of 49162 lines of code (SLOC) in 17 source packages,
642 classes and 4439 methods (after removing classes related
to test cases and methods used to profile the source code of
the application). As for this experiment, we collected data
for all the 17 packages contained in the src folder of PMD.
However, one package was excluded from the final compu-
tation due to the lack of test cases.
We focused on collecting different types of data referring
to the static, dynamic size, dynamic coupling measures, and
number of bugs for each case study at a package granularity.
We collected the following static measures (by means of the
Metrics plugin [3] v1.3.8): Number of Methods, Number
of Classes, Afferent Coupling (Ca), Efferent Coupling (Ce),
Package Instability (i.e., Ce / (Ca+Ce)) , Coupling Between
Objects (CBO max and mean), and McCabe Complexity
(max and mean.)
As for collecting dynamic size measures, we used the EclEmma
Eclipse plugin [2]. EclEmma is a free Java code coverage
tool for Eclipse that does not require modifying the source
code of the applications. We used the test cases provided
along with each application to exercise the system of each
case study, and by means of EclEmma we are able to com-
pute at run-time the measures we discussed in subsection
5.1. Specifically, we compute the percentage of blocks, in-
structions, SLOCs, methods and types exercised by the test
cases.
As for collecting the dynamic coupling measures (i.e., dy-
namic messages, distinct methods, and distinct classes), we
profiled each application by means of Aspect-Oriented Pro-
gramming (AOP) and we exercised the system by means of
each test suite. The test cases have been used to simulate
the users’ interactions with the application in order to exer-
cise as much functionalities of the application as possible.
45
We used the AJDT Eclipse plugin (based on the AspectJ
runtime library) [1] to define an aspect (i.e., a stand-alone
module that contains cross-cutting concerns), a pointcut
(i.e., a set of join points that are able to capture well-defined
moments in the execution of a program, like method call, ob-
ject instantiation, or variable access), and an advice (i.e., the
code to run before, after, or around the specified join point)
able to trace all the calling classes and methods, the called
classes and methods, and the statements from which calls
originate. The pseudo code of the most relevant part of the
defined aspect looks like as follows:
public aspect DynamicCouplingAspect {
pointcut executionTree():
within(TestClass_a) ||
... ...
within(TestClass_n) &&
call (* *(..));
Object around(): executionTree() {
print(thisJointPointStaticPart.getSignature);
print(thisJointPointStaticPart.getDeclaringType);
... ...
}
... ...
}
As for collecting bugs data, we manually surfed the bug
tracker system of each case study to identify all the valid
bugs (i.e., open, closed, confirmed with the exception of un-
confirmed bugs) that refer to the version of the target ap-
plication. Each identified bug has been manually classified
in the package it belongs to. To avoid biases, we try to
reduce subjectivity in the manual analysis of each bug as
much as possible, and we also try to replicate step by step
the methodology we used for surfing each bug tracker. In
any case, we are aware that bugs data are often non ho-
mogeneous due to different policies of each community in
collecting, reporting and tracking bugs. For instance, the
Jakarta Commons IO project uses the JIRA bug tracker,
HttpUnit and PMD use the Sourceforge bug tracker, while
Log4J uses the Bugzilla bug tracker system. For each pack-
age, we computed the
6.2 Objectives and Results
With these experiments, we are interested in collecting
data to show:
Q1: whether there is a correlation between dynamic size
and coupling measures with some relevant static mea-
sures;
Q2: whether dynamic measures are better than static mea-
sures in predicting some software quality aspects. In
this paper, we limited our experimentation in inves-
tigating the fault-proneness aspect, thus we used as
dependent variable the number of bugs of each appli-
cation. We correlated dynamic measures and static
measures with these bug data, and we compared the
computed coefficients of correlation to understand the
ability that dynamic and static measures have in pre-
dicting the fault-proneness of an application;
To answer question Q1 we used non parametric test, be-
cause distributions are generally not normal.
Table 1 reports the results of the Kendall’s and Spear-
man’s tests applied to Log4J dynamic size measures with
all the seven static measures we listed above. We are not
 Table 1: Correlation between static and dynamic size measures for Log4J (10 data points)
Blocks Instructions SLOC Methods Types
Num. Methods — tau = 0.511 — — —
rho = 0.661
Num. Classes tau = 0.688 tau = 0.777 tau = 0.733 — —
rho = 0.794 rho = 0.903 rho = 0.854
CBO max tau = 0.539 tau = 0.449 tau = 0.494 tau = 0.494 —
rho = 0.705 rho = 0.656 rho = 0.693 rho = 0.669

able to find any significant correlation for HttpUnit, PMD

and Jakarta. Contrariwise, we found several correlations for
Log4J (see Table 1 ). Due to the heterogeneity in the ob-
tained results, no general conclusions can be derived.
Tables 2 to 4 report the results of the Kendall’s and Spear-
man’s tests applied to HttpUnit, PMD and Log4J dynamic
coupling measures with all the seven static measures we
listed above, respectively. For the Jakarta project no sig-
nificant correlation could be found, but this is probably due
to the small number of available datapoints (5). As a matter
of fact, for Dynamic Messages vs. NumClasses and Distinct
Methods vs. NumClasses fairly high values of Kendall’s tau
and Spearman’s rho were found, but with p-value well above
the chosen threshold (0.05).
As for the correlations between static measures and dy-
namic coupling measures, we can weakly state that dynamic
messages, distinct methods and distinct classes correlate well
with the number of methods, number of classes, efferent cou-
pling, and McCabe (max) static measures (this can be de-
rived by intersecting the HttpUnit results with the Log4J
results). These results are limited to HttpUnit and Log4J,
the only two projects that provide some correlations.
Table 2: Correlation between static and dynamic
coupling measures for HttpUnit (8 data points)
Dynamic Distinct Distinct
Messages Methods Classes
Num. tau = 0.786 tau = 0.929 tau = 0.857
Methods rho = 0.905 rho = 0.976 rho = 0.929
Num. tau = 0.786 tau = 0.929 tau = 0.857
Classes rho = 0.905 rho = 0.976 rho = 0.929
Efferent rho = 0.762 rho = 0.810 rho = 0.786
Coupling
CBO max — tau = 0.618 —
rho = 0.778
Package tau = 0.643 tau = 0.643 tau = 0.714
Instability rho = 0.833 rho = 0.810 rho = 0.881
McCabe tau = 0.593 tau = 0.667 tau = 0.593
max rho = 0.711 rho = 0.795 rho = 0.730
Table 3: Correlation between static and dynamic
coupling measures for PMD (16 data points)
Dynamic Distinct Distinct
Messages Methods Classes
CBO mean — rho = 0.538 —
To answer question Q2, we built models –via Ordinary
Least Squares (OLS) regression– involving
Table 4: Correlation between static and dynamic
coupling measures for Log4J (10 data points)
Dynamic Distinct Distinct
Messages Methods Classes
Num. tau = 0.556 tau = 0.644 tau = 0.629
Methods rho = 0.721 rho = 0.794 rho = 0.754
Num. tau = 0.644 tau = 0.556 tau = 0.539
Classes rho = 0.782 rho = 0.721 rho = 0.711
Afferent tau = 0.540 — tau = 0.523
Coupling rho = 0.657 rho = 0.640
Efferent tau = 0.540 tau = 0.540 tau = 0.523
Coupling rho = 0.669 rho = 0.669 rho = 0.659
McCabe tau = 0.523 tau = 0.523 tau = 0.598
max rho = 0.689 rho = 0.665 rho = 0.731
McCabe tau = 0.584 tau = 0.674 tau = 0.705
mean rho = 0.760 rho = 0.815 rho = 0.826
• dependent variables representing defect density at the
package level: the absolute number of bugs (Num-
Bugs); the relative number of bugs (NumRelBugs),
obtained as the ratio between the number of bugs of
a package and the total number of bugs of the appli-
cation; the number of bugs per LOC (BugsPerLOC);
the ratio between the number of bugs and the number
of classes (NumBugs/NumClasses); the ratio between
the number of bugs and the number of methods (Num-
Bugs/NumMethods).
• independent variables representing all the seven static
measures and the dynamic measures of size and cou-
pling.
We built both linear models and models obtained by ap-
plying OLS regression to log-log transformed data.
Not all the possible pairs of independent and dependent
variables provided statistically significant models. The sig-
nificant models obtained via OLS regression after log-log
transformation are synthetically reported in Table 5.
In Table 5 we have reported for completeness also the
models for Jakarta Commons IO, but we must remember
that such model is based on 5 data points only, therefore it
is not very reliable.
Table 5 shows that the number of distinct methods and
distinct classes executed are the measures that in general
correlate better with the various measures of defects for most
projects, while static measures in general do not provide a
reliable indicator on fault-proneness of a project (e.g., static
measures provided heterogeneous results if comparing the
models of the four case studies).
We are aware that the quality of the found models depends
strongly on the quality of the partial results computed by

46
 Table 5: Independent variables of log-log models (R2 in parentheses)
Dep. Var. Indip. Var. (R2 )
HTTPunit Jakarta
Distinct Methods(0.604) Distinct Methods(0.928) CBO max(0.466)
Distinct Classes(0.529) Distinct Classes(0.932)
Pack. Instability(0.564)
Num. Bugs
Afferent Coupling(0.665) Distinct Methods(0.928) Afferent Coupling(0.698) Distinct Methods(0.732)
Distinct Classes(0.932)
Num. rel. Bugs
Distinct Methods(0.895)
Bugs per LOC
Distinct Classes(0.891)
Num. Bugs / McCabe Max(0.869)
N.Classes
Num. Bugs /
N.Methods
each intermediate tool, on the accuracy of each community
in collecting and reporting bugs data, and on the number of
case studies and data points available. We are extending this
work by collecting new data (at a class granularity instead
of at the package granularity), to increase significantly the
number of data points.
7. RELATED WORK
Several works exist on the measurement of static prop-
erties for software systems. In addition to classical works
that define static measures such as lines of code, cohesion,
coupling and other measures [14], a lot of recent works for-
mally define static attributes [10, 9, 6] for object-oriented
systems, while other works empirically evaluate the correla-
tion among static attributes with subjective aspects such as
maintainability and trustworthiness of object-oriented open-
source software systems [5].
Recently, the introduction of profiling and probing mech-
anisms based on assertions, invariants, and aspects to mon-
itor the dynamic behavior of software systems has shown
how software systems often do not behave at run-time as ex-
pected at design-time [12]. Static measures are not able to
detect misbehaviors and unexpected properties of the soft-
ware, thus they need to be complemented with measures
that work at run-time.
Starting from these considerations, some dynamic mea-
sures have been defined in the literature. For example, Ya-
coub et al. define dynamic object-oriented coupling mea-
sures based on executable Real-time Object Oriented Mod-
eling (ROOM) [16]. These models are a specialization of se-
quence diagrams that allow execution simulations of the soft-
ware system, thus providing a way to calculate the number of
messages sent between two distinct objects in a given ROOM
diagram. Unfortunately, the proposed approach works stati-
47
PMD Log4J
Distinct Methods(0.738)
Distinct Classes(0.741)
McCabe max(0.545)
Num. Methods(0.887)
Afferent Coupling(0.637)
Efferent Coupling(0.817)
Instructions Perc.(0.529)
SLOC Perc.(0.493)
Instructions Perc.(0.819) Distinct Classes(0.735)
Methods Perc.(0.757) McCabe max(0.542)
Num. Methods(0.883)
Afferent Coupling(0.646)
Efferent Coupling(0.817)
Instructions Perc.(0.544)
SLOC Perc.(0.51)
Num. Methods(0.968)
Blocks Perc.(0.604)
Methods Perc.(0.772) Distinct Methods(0.816)
Distinct Classes(0.906)
Instructions Perc.(0.517)
cally simulating the behavior of the system and the coupling
measures defined in their work are not compliant with our
axiomatic framework. In our work, we describe how to use
aspect-oriented programming to instrument the source code
of the system and how to collect traces at runtime to com-
pute dynamic size and coupling attributes.
In [4], a set of dynamic coupling measures has been defined
and validated against static size measures. We extended this
work, by adding and formally defining, in an operational
form, dynamic size measures, and we provide a set of ex-
periments with the aim of demonstrating the potentialities
of dynamic measures. We also show, by means of four case
studies, how AOP can actually support the computation of
dynamic measure.
In [7], the authors propose a way to estimate dynamic
coupling metrics early in the software development lifecycle.
They introduce the concept of ”pseudo dynamic metrics”,
which are static metrics adjusted to reflect the operational
profile of the expected software usage. They draw their ap-
proach starting from the assumption that dynamic metrics
can only be computed at an advanced stage of the software
development, because they need additional code to be wrote
to detect dynamic behaviors. In our work, we demonstrated
how it is simple to define advices and pointcuts able to mon-
itor at run-time the behavior of the software system. Of
course, our approach needs the availability of external in-
puts (such as test cases) that trigger and stimulate the sys-
tem. We think that these external inputs are early available
because test cases are normally coded in parallel with the de-
velopment of the system, as software engineering guidelines
and best practices suggest.
Other dynamic measures have been informally defined.
For example, Munson et al. [11] obtained a sort of dynamic
complexity (they call ”relative complexity”) starting from
the static complexity of a software component and its fre-
quency of execution. Our axiomatic framework for dynamic
measures is open to new formal definitions. We are extend-
ing this work by formally defining other dynamic measures
and the properties that characterize these measures.
In the research filed of software testing, a lot of work exists
about how software systems are exercised at runtime by a
test suite. This field studies coverage criteria to understand
how good and adequate is a test suite in exercising all the
criticisms of a software system. Several coverage and ade-
quacy criteria have been defined in the literature. In [17] a
comprehensive survey of these criteria is provided. For ex-
ample, the Statement Coverage criteria reports whether each
executable statement of the system is encountered when exe-
cuting the test suite; the Condition Coverage criteria reports
the true or false outcome of each boolean sub-expression,
separated by logical-and and logical-or if they occur; the
Path Coverage criteria reports whether each of the possible
paths in each function have been followed. Several other
criteria are available, and to the best of our knowledge, we
think that these criteria should be investigated and adapted
to collect dynamic software measures.
8. CONCLUSIONS AND FUTURE WORK
In this paper, we have proposed a framework for the defi-
nition of sensible measures of dynamic internal software at-
tributes. The framework is based on Axiomatic Approaches
and is consistent with previous work about static measures
[9]. We have also provided examples to show how dynamic
measures may be defined, collected, and used.
Future work will address several avenues of research, in-
cluding:
• definition of axiom sets for other dynamic attributes
like dynamic complexity and dynamic cohesion
• definition of additional measures and refinement of ex-
isting ones according to the axiom sets defined
• additional empirical studies (collecting data at the class
granularity) to assess the practical usefulness of these
measures.
9. ACKNOWLEDGMENT
The research presented in this paper has been partially
funded by the IST project “QualiPSo,” funded by the EU in
the 6th FP (IST-034763); the FIRB project “ARTDECO,”
sponsored by the Italian Ministry of Education and Uni-
versity; and the projects “Elementi metodologici per la de-
scrizione e lo sviluppo di sistemi software basati su modelli”
and “La qualità nello sviluppo software,” funded by the Uni-
versità degli Studi dell’Insubria.
10. REFERENCES
[1] AJDT: AspectJ Development Tools. Web published:
www.eclipse.org/ajdt/. Accessed: March 2012.
[2] The EclEmma Eclipse Plugin. Web published:
www.eclemma.org. Accessed: March 2012.
[3] Metrics. Web published:
http://metrics2.sourceforge.net/. Accessed: March
2012.
[4] E. Arisholm, L. C. Briand, and A. Føyen. Dynamic
coupling measurement for object-oriented software.
IEEE Trans. Software Eng., 30(8):491–506, 2004.
48
[5] V. D. Bianco, L. Lavazza, S. Morasca, D. Taibi, and
D. Tosi. An investigation of the users perception of
OSS quality. In International Conference on Open
Source Systems (OSS), 2010.
[6] L. C. Briand, S. Morasca, and V. R. Basili.
Property-based software engineering measurement.
IEEE Trans. Software Eng., 22(1):68–86, 1996.
[7] R. Gunnalan, M. Shereshevsky, and H. H. Ammar.
Pseudo dynamic metrics [software metrics]. In
International Conference on Computer Systems and
Applications (AICCSA), page 117, 2005.
[8] D. Krantz, R. Luce, P. Suppes, and A. Tversky.
Foundations of measurement, volume 1: Additive and
polynomial representations. Academic Press, New
York, 1971.
[9] S. Morasca. Refining the axiomatic definition of
internal software attributes. In Proceedings of the
Second International Symposium on Empirical
Software Engineering and Measurement (ESEM),
pages 188–197, 2008.
[10] S. Morasca. A probability-based approach for
measuring external attributes of software artifacts. In
Proceedings of the Second International Symposium on
Empirical Software Engineering and Measurement
(ESEM), pages 44–55, 2009.
[11] J. C. Munson and T. M. Khoshgoftaar. Measuring
dynamic program complexity. IEEE Software,
9(6):48–55, 1992.
[12] J. H. Perkins and M. D. Ernst. Efficient incremental
algorithms for dynamic detection of likely invariants.
In Proceedings of the International Symposium on
Foundations of Software Engineering (FSE), pages
23–32, 2004.
[13] F. Roberts. Measurement theory, with applications to
Decision Making, Utility and the Social Sciences.
Addison-Wesley, Boston, 1979.
[14] D. Stavrinoudis and M. N. Xenos. Comparing internal
and external software quality measurements. In
Knowledge-Based Software Engineering, Proceedings of
the Eighth Joint Conference on Knowledge-Based
Software Engineering, (JCKBSE), pages 115–124,
2008.
[15] E. J. Weyuker. Evaluating software complexity
measures. IEEE Trans. Software Eng.,
14(9):1357–1365, 1988.
[16] S. M. Yacoub, H. H. Ammar, and T. Robinson.
Dynamic metrics for object oriented designs. In IEEE
International Software Metrics Symposium
(METRICS), pages 50–61, 1999.
[17] H. Zhu, P. A. V. Hall, and J. H. R. May. Software unit
test coverage and adequacy. ACM Comput. Surv.,
29(4):366–427, 1997.