Description

Comments on Property-Based Software Engineering Measurement: Refining the Additivity Properties

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.

Related Documents

Share

Transcript

190IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 23, NO. 3, MARCH 1997
Comments on “Property-Based SoftwareEngineering Measurement: Refining theAdditivity Properties”
Geert Poels and Guido Dedene,
Member
,
IEEE
Abstract
—The recently published measure property set of Briand,Morasca, and Basili [1] establishes the foundation of a real softwaremeasurement theory. Unfortunately, a number of inconsistenciesrelated to additivity properties might hinder its acceptance and furtherelaboration. In this paper, it is shown how to remove the ambiguity inthe property definitions.
Index Terms
—Software measurement, measurement properties,measurement theory, additivity, module connection strength.
————————
✦
————————
1 I
NTRODUCTION
O
NE
of the top priority areas in software engineering measure-ment is the definition of valid measures for the internal attributes[2] of software artifacts. Real-time measurements of these attrib-utes, especially those related to complexity, coupling and cohe-sion, provide developers with continuous feedback on the effec-tiveness of the design techniques they apply [3]. To ensure thevalidity of the measures a number of researchers have proposedsets of properties, sometimes also called axioms, that each measureof a measurement concept should satisfy. In this context a meas-urement concept is a general attribute (e.g., complexity) that canhave many different related, sometimes even contradicting, view-points (e.g., structural, psychological, computational, logical, lexi-cal/textual and readability complexity [4]). Especially for themeasurement of complexity [5], [6], [7], [8], [9], [10] and to a lesser
degree coupling [11], a number of property sets have beenproposed.Some of these research efforts result in inconsistent propertysets, meaning that the properties cannot simultaneously be ful-filled by the same measure, since different properties require dif-ferent interpretations of the concept to be measured [12], [13]. For
instance, some of Weyuker’s axioms [7] require complexity to bedefined as comprehensibility, while for other axioms to be satis-fied complexity must be related to size. Even for consistent sets,the axiomatic approach suffers from the flaw that the proposedproperties are necessary but not sufficient. As a consequence it ispossible (as has been demonstrated in [14]) to define measures that
satisfy all axioms while at the same time being completely mean-ingless and not related to any intuitive notion regarding the meas-ured concept.To make things even worse, conflicting properties may occur inthe sets of different authors. As a consequence, a measure may bevalid according to one property set, but invalid according to an-other set.Consider for instance the complexity properties related to ad-ditivity. The relevant question is whether the complexity of a sys-tem composed of two software entities (e.g., program segments,modules, object classes, …) is equal to the sum of the complexitiesof the individual entities. In [5], the complexity of a system isgreater than or equal to the sum of the complexities of its parts.Also in [7], it is stated that complexity does not have to be addi-tive. In fact, the complexity of the whole may be strictly greaterthan the summed complexities of the parts. In [8], strict additivityis required when program segments are sequenced. Other authorsrequire additivity for some, but not all, viewpoints on complexity[6], [9], [10].
The recently published property set of Briand, Morasca, andBasili is a clear exception in this pattern [1]. The range of concepts
covered by the properties is wide: size, length, complexity, cou-pling, and cohesion. The properties may be used to classify meas-ures according to the concept they are purported to measure. Sec-ondly, in [1] it is nowhere claimed that this set is sufficient to vali-date a measure. At most the properties are necessary, which im-plies they can be used to invalidate measures. Further it is arguedthat the property set is generic. Software systems are representedin an abstract model using a graph-theoretic approach, allowing to be mapped to a wide range of software artifacts (e.g., USESgraphs, Is-Component-of graphs, control flow graphs, etc. [1]).Moreover, software systems and the properties that characterisethe measurement concepts are formally described using set-theoretic notation, which should guarantee precise and unambi-guous definitions. Also, it is shown that the properties do notcontradict most axioms formulated in previous axiom sets, be-cause they are weak enough to capture the corresponding parts inotherwise conflicting properties. Finally, Briand, Morasca, andBasili explicitly relate their properties to existing concepts of measurement theory (see e.g., [15]), showing the similarities in
both approaches.It is hoped that this property set is widely discussed and ac-cepted in the software measurement community, both by scientistsand practitioners. Its wide coverage of measurement concepts, theformality of its definitions, and its correspondence with earlierpublished axiom sets and measurement theory are clear advan-tages not exhibited by previous research. Besides, the explicit rec-ognition that the properties alone are not sufficient to validate ameasure is an invitation for continuous improvement. Briand,Morasca, and Basili invite other researchers to extend their set toother concepts (e.g., reuse), to formulate additional properties orto refine existing properties. The convergence of all these ideascould ultimately lead to the foundation of a real software meas-urement theory.Unfortunately, the mathematical treatment in [1] is just not pre-cise enough to guarantee an unambiguous interpretation of theproperty definitions. Especially for the additivity-related propertiesthere exist a number of inconsistencies that might result in confusionand hinder the further elaboration of the framework. The inconsis-tencies in [1] can be traced back to the definition of a union operatorfor software entities, that, while being sufficiently formal and cor-rect, is not conscientiously applied in the rest of the text.We believe that to reach a consensus on a universal softwaremeasurement theory, the relationship between the measurementconcepts and their additivity properties must be further clarified.The ambiguity in the definition of the properties introduced in [1]can possibly result in wasted research time and costs if it is notrecognised and removed. In Section 2, the basic definitions of thesoftware system and the additivity-related properties, such aspresented in [1], are reproduced. In Section 3, the inconsistencies
in the definitions are removed by introducing an ordinal scale of connection strength between software modules, and by relatingthis scale to the additivity properties. In Section 4, the srcin of theinconsistencies is traced back to the definition of a module unionoperator, and an alternative definition is proposed. Finally, in Sec-tion 5 conclusions are presented.
0098-5589/97/$10.00 © 1997 IEEE
————————————————
•
G. Poels and G. Dedene are with the Department of Applied Economic Sciences,Katholieke Universiteit Leuven, Naamesestraat 69, B-3000 Leuven Belgium.
E-mail: {geert.poels, guido.dedene}@econ.kuleuven.ac.be. Manuscript received Sept. 25, 1996.Recommended for acceptance by S.H. Zweben.For information on obtaining reprints of this article, please send e-mail to:transse@computer.org, and reference IEEECS Log Number S96154.
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 23, NO. 3, MARCH 1997191
2 B
ASIC
D
EFINITIONS
All definitions presented in this section are taken from [1].D
EFINITION
1.
A system
S
is a pair
<E, R>,
where
E
is the set of ele-ments of
S
, and
R
⊆
E × E
is a binary relation on
E
representingthe relationships between the elements of
S.The representation of a system in [1] is general enough to bemapped to a wide range of software artifacts. For instance, if S is acontrol flow graph of a program, then E is the set of code state-ments (i.e., the nodes in the graph) and R is the set of control flows between code statements (i.e., the edges in the graph).D
EFINITION
2.
Given a system
S = <E, R>
and a system
m = <E
m
, R
m
>:m
is a module of
S
⇔
m
⊆
S
⇔
E
m
⊆
E
and
R
m
⊆
R.Modules are systems in their own right that are contained inother systems. For instance, a module may be the control flowgraph of a subprogram. Modules may be connected with the restof the system through relationships. For a module m, the incomingand outgoing relationships are captured by the sets InputR(m) andOutputR(m), respectively.D
EFINITION
3
. Given a system
S = <E, R>
and a system m =
<E
m
, R
m
>
such
that
m
is a module of
S: InputR(m) = {<e
1
, e
2
>
∈
R
e
2
∈
E
m
and
e
1
∈
E – E
m
};OutputR(m) = {<e
1
, e
2
>
∈
R
e
1
∈
E
m
and
e
2
∈
E – E
m
}.To define meaningful measurement concept properties a num- ber of operators are defined on modules.D
EFINITION
4.
Given a system
S = <E, R>,
a system
m
i
= <E
mi
, R
mi
>
and a system
m
j
= <E
mj
, R
mj
>, where
m
i
and
m
j
are modules of
S:1)
the union of
m
i
and
m
j
(notation:
m
i
∪
m
j
)
is the system
<E
mi
∪
E
mj
, R
mi
∪
R
mj
>
which is a module of
S;2)
the intersection of
m
i
and
m
j
(notation:
m
i
∩
m
j
)
is the system
<E
mi
∩
E
mj
, R
mi
∩
R
mj
>
which is a module of
S;3)
the modules
m
i
and
m
j
are disjoint
⇔
E
mi
∩
E
mj
=
∅
;
1
4)
the modules
m
i
and
m
j
are not connected
⇔
E
mi
∩
E
mj
=
∅
and
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
.These concepts are illustrated using the system S = <E, R> of Fig. 1.
Fig. 1. The system S = <E, R> [1].
The system S = <E, R> is fully described by <{a, b, c, d, e, f, g, h,i, j, k, l, m}, {<b, a>, <b, f>, <c, b>, <c, d>, <c, g>, <d, f>, <e, g>,<f, i>, <f, k>, <g, m>, <h, a>, <h, i>, <i, j>, <k, j>, <k, l>}>.Four modules of S are identified in the figure:m
1
= <{a, b, f, i, j, k}, {<b, a>, <b, f>, <f, i>, <f, k>, <i, j>, <k, j>}>m
2
= <{f, j, k}, {<f, k>, <k, j>}>m
3
= <{c, d, e, f, g, j, k, m}, {<c, d>, <c, g>, <d, f>, <e, g>, <f, k>, <g, m>, <k, j>}>m
4
= <{d, e, g}, {<e, g>}>
1. In [1], modules m
i
and m
j
are said to be disjoint if m
i
∩
m
j
=
∅
. Butsince E
mi
∩
E
mj
=
∅
⇒
R
mi
∩
R
mj
=
∅
, Definition 4.3 is equivalent to the srci-nal definition.
m
1
⊆
S, m
3
⊆
S, m
2
⊆
m
1
, m
2
⊆
m
3
and m
4
⊆
m
3
.Note that m
2
is the intersection of m
1
and m
3
(i.e., m
2
= m
1
∩
m
3
). The union of m
1
and m
3
is given by m
1
∪
m
3
= <{a, b, c, d, e, f,g, i, j, k, m}, {<b, a>, <b, f>, <c, d>, <c, g>, <d, f>, <e, g>, <f, i>,<f , k>, <g, m>, <i, j>, <k, j>}>.Note also that b
∈
E
m1
, c
∈
E
m3
and <c, b>
∈
R, but <c, b>
∉
R
m1
∪
R
m3
.
2
According to [1] the coupling and cohesion concepts are onlymeaningful in the context of modular systems. A system is amodular system if its set of elements is partitioned into the sets of elements of its modules. As a consequence, all modules in amodular system are disjoint.D
EFINITION
5.
A modular system
MS = <E, R, M>
is a system
<E, R>,
where
M
is a set of modules such that:
1)
∀
e
∈
E:
∃
m = <E
m
, R
m
>
∈
M
such that
m
⊆
S
and
e
∈
E
m
;2)
∀
m
i
= <E
mi
, R
mi
>, m
j
= <E
mj
, R
mj
>
∈
M: m
i
and
m
j
aredisjoint
.Relationships in a modular system are either intermodule orintramodule.D
EFINITION
6.
Given a modular system
MS = <E, R, M>
, where
M ={m
1
, m
2
, …, m
n
}
and
m
i
= <E
mi
, R
mi
> for i = 1, …, n:
the set of intramodule
relationships
is:IRR
mi
=
=
in
1
U
,
the set of intermodule relationships is
R – IR.These concepts are illustrated using the modular system MS =<E, R, M> of Fig. 2.
Fig. 2. The system MS = <E, R, M> [1].
MS = <E, R, {m
1
, m
2
, m
3
}> IR = {<b, a>, <c, d>, <c, g>, <e, g>, <f, i>, <f, k>, <g, m>, <h, a>, <i, j>, <k, j>, <k, l>}R – IR = {<b, f>, <c, b>, <d, f>, <h, i>}According to Briand et al., Size, Complexity, and Couplingmeasures should be additive when systems are made of disjointmodules [1]. Hence, for each of these measurement concepts adisjoint module additivity property is defined.
•
Size
. Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
>and a system m
j
= <E
mj
, R
mj
>:(m
i
⊆
S and m
j
⊆
S and E = E
mi
∪
E
mj
and E
mi
∩
E
mj
=
∅
)
⇒
Size(S) = Size(m
i
) + Size(m
j
)
•
Complexity
. Given a system S = <E, R>, a system m
i
= <E
mi
,R
mi
> and a system m
j
= <E
mj
, R
mj
>:(S = m
i
∪
m
j
and m
i
∩
m
j
=
∅
)
⇒
Complexity(S) = Complexity(m
i
) + Complexity(m
j
).
2. In [1], the relationship <c, b> is included in m
1
∪
m
3
. This is not correct,according to the definition of the module union operator.
192IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 23, NO. 3, MARCH 1997
•
Coupling
. Given a modular system MS’ = <E, R, M’> and amodular system MS” = <E, R, M”>, with the same underly-ing system <E, R>, such that M” = M’ – {
¢
m
i
,
¢
m
j
}
∪
{m”},with
¢
m
i
,
¢
m
j
∈
M’, m” =
¢
m
i
∪
¢
m
j
and m”
∉
M’ and In-putR(
¢
m
i
)
∩
OutputR(
¢
m
j
) =
∅
and InputR(
¢
m
j
)
∩
Out-putR(
¢
m
i
) =
∅
, then1) Coupling(m”) = Coupling(
¢
m
i
) + Coupling(
¢
m
j
).2) Coupling(MS’) = Coupling(MS”)According to the same authors, Length and Cohesion measuresare not additive. Length measures for systems made up of disjointmodules must satisfy the following nonadditive property:
•
Length
. Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
>and a system m
j
= <E
mj
, R
mj
>: (S = m
i
∪
m
j
and m
i
∩
m
j
=
∅
and E = E
mi
∪
E
mj
)
⇒
Length(S) = max(Length(m
i
),Length(m
j
)).Cohesion measures satisfy the following nonadditive property:
•
Cohesion
. Given a modular system MS’ = <E, R, M’> and amodular system MS” = <E, R, M”>, with the same underly-ing system <E, R>, such that M” = M’ – {
¢
m
i
,
¢
m
j
}
∪
{m”},with
¢
m
i
,
¢
m
j
∈
M’, m” =
¢
m
i
∪
¢
m
j
and m”
∉
M’ and In-putR(
¢
m
i
)
∩
OutputR(
¢
m
j
) =
∅
and InputR(
¢
m
j
)
∩
Out-putR(
¢
m
i
) =
∅
, then:1) max(Cohesion(
¢
m
i
), Cohesion(
¢
m
j
))
≥
Cohesion(m”)2) Cohesion(MS’)
≥
Cohesion(MS”).
3 A
DDITIVITY AND
C
ONNECTION
S
TRENGTH
The modules in a software system can be connected with eachother in many possible ways. Some modules may have commonrelationships, while other modules may only have common ele-ments. Disjoint modules can be connected by intermodule rela-tionships or can be unconnected. The connection strength betweenmodules determines the nature of the additivity-related proper-ties, i.e., certain measurement concepts are additive given someassumptions concerning the connection strength of the modules. If these assumptions are not met, the additivity property does nothold. To clarify the relation between additivity and connectionstrength, first an ordinal scale of connection strength is defined.Next, this scale will be used to examine the additivity-relatedproperties in [1].D
EFINITION
7.
Given a system
S = <E, R>
, a system
m
i
= <E
mi
, R
mi
>
and a system
m
j
= <E
mj
, R
mj
>
, with
m
i
, m
j
⊆
S.
The conditions for the different levels of connection strength are:Level 0
.
no restrictions on connection typesLevel 1.
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
.
Level 2.
R
mi
∩
R
mj
=
∅
.
Level 3
. R
mi
∩
R
mj
=
∅
and
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
.
Level 4
. E
mi
∩
E
mj
=
∅
.
Level 5
. E
mi
∩
E
mj
=
∅
and
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
.According to Definition 4, level 4 modules are disjoint andLevel 5 modules are not connected. Since the condition for level 4modules is contained in the condition for level 5 modules, notconnected modules are always disjoint. Note however, that theopposite is not true: disjoint modules may be connected. Modularsystems are by definition composed of disjoint modules. Hence,the connection strength in a modular system is level 4 or level 5.Since for some levels the condition is contained in the conditionof another level, an ordinal scale [15] of connection strength can bedefined.D
EFINITION
8.1) <
c
⊆
{0, 1, 2, 3, 4, 5} × {0, 1, 2, 3, 4, 5}: i <
c
j
⇔
modules
atlevel
i
are less connected than modules at level
j.2) <
c
= {<5, 4>, <5, 3>, <5, 2>, <5, 1>, <5, 0>, <4, 2>, <4, 0>,<3, 2>, <3, 1>, <3, 0>, <2, 0>, <1, 0>}.3) <
c
is irreflexive, asymmetric, and transitive; hence, it defines astrict partial order on the levels of connection strength
[15].
3
The connection strengths between the modules of the systemS = <E, R> of Fig. 1 and the modular system MS = <E, R, M> of Fig. 2 are tabulated in Tables 1 and 2, respectively.
TABLE 1C
ONNECTION
S
TRENGTH BETWEEN
M
ODULES IN
S = <E, R>
OF
F
IG
. 1
connectionstrengthmodule m
1
module m
2
module m
3
module m
4
module m
1
level 1level 0level 4module m
2
level 1level 1level 4module m
3
level 0level 1level 1module m
4
level 4level 4level 1
TABLE 2C
ONNECTION
S
TRENGTH BETWEEN
M
ODULES IN
MS = <E, R, M>
OF
F
IG
. 2
connectionstrengthmodule m
1
module m
2
module m
3
module m
1
level 4level 4module m
2
level 4level 4module m
3
level 4level 4
For the system S of Fig. 1 the following statements hold:1) At level 4, modules are disjoint
⇒
m
1
and m
4
are disjoint; m
2
and m
4
are disjoint.2) At level 5, modules are not connected
⇒
All modules areconnected to some degree.Since the modules in a modular system are disjoint, the con-nection strength between the modules in MS is at least at level 4.In the modular system MS of Fig. 2 each module is connected toeach of the other modules.The inconsistencies introduced in [1] are related to both the con-cepts of additivity and connection strength. More precisely, accord-ing to Briand, Morasca, and Basili for some measurement conceptslike complexity and coupling additivity holds when modules aredisjoint (i.e., connection strength level 4). Consequently, these prop-erties are called disjoint module additivity properties. However, based on the definitions of these properties provided in [1] for mostconcepts additivity holds only when modules are not connected (i.e.,connection strength level 5). Since disjoint modules may be con-nected (i.e., <4, 5>
∉
<
c
), the definition of the properties contradictsthe assertion that complexity and coupling are additive for (all) dis- joint modules. To formally show this, the following theorem isneeded (a proof can be found in the Appendix
)
.T
HEOREM
1.
Given a system
S = <E, R>,
a system
m
i
= <E
mi
, R
mi
>
anda system
m
j
= <E
mj
, R
mj
>:
3. A function
µ
: level i
→
{0, 1, 2, 3}:
µ
(level 0) = 3,
µ
(level 1) = 2,
µ
(level 2)= 2,
µ
(level 3) = 1,
µ
(level 4) = 1,
µ
(level 5) = 0 is a valid ordinal measure of the connection strength between modules since it satisfies
∀
levels i, j
∈
{0,1, 2, 3, 4, 5}: i <
c
j
⇔
µ
(
level i) <
µ
(level j).
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 23, NO. 3, MARCH 1997193
S = m
i
∪
m
j
and
E
mi
∩
E
mj
=
∅
⇒
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
.By means of Theorem 1 for each of the additivity-related prop-erties the maximum connection strength that is allowed can beidentified. As mentioned before, for some measurement propertiesinconsistencies between property names and definitions show up.
3.1 Complexity
Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
> and a systemm
j
= <E
mj
, R
mj
>:(S = m
i
∪
m
j
and m
i
∩
m
j
=
∅
)
⇒
Complexity(S) = Complexity(m
i
)+ Complexity(m
j
)
⇒
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and InputR(m
j
)
∩
OutputR(m
i
) =
∅
(Theorem 1)
⇒
m
i
and m
j
are not connected (level 5)For disjoint modules (level 4), it suffices that E
mi
∩
E
mj
=
∅
, butintermodule relationships may exist. Hence, not all disjoint mod-ules satisfy the additivity property: (E = E
mi
∪
E
mj
and E
mi
∩
E
mj
=
∅
)
/ﬁ
Complexity(S) = Complexity(m
i
) + Complexity(m
j
).However for disjoint modules the complexity monotonicityproperty holds (see [1]): (m
i
∪
m
j
⊆
S and R
mi
∩
R
mj
=
∅
)
⇒
Com-plexity(S)
≥
Complexity(m
i
) + Complexity(m
j
).This property holds for all modules at level 2, and for all mod-ules at level i such that i <
c
2 (i.e., 3, 4, and 5). Hence, disjointmodules satisfy monotonicity. Only when they are not connectedcomplexity is additive.
3.2 Coupling
Given a modular system MS’ = <E, R, M’> and a modular systemMS” = <E, R, M”>, with the same underlying system <E, R>, suchthat M” = M’ – {
¢
m
i
,
¢
m
j
}
∪
{m”}, with
¢
m
i
,
¢
m
j
∈
M’, m” =
¢
m
i
∪
¢
m
j
and m”
∉
M’ and InputR(
¢
m
i
)
∩
OutputR(
¢
m
j
) =
∅
and In-putR(
¢
m
j
)
∩
OutputR(
¢
m
i
) =
∅
, thenCoupling(m”) = Coupling(
¢
m
i
) + Coupling(
¢
m
j
); Coupling(MS’) = Coupling(MS”).Modular systems are by definition composed of disjoint mod-ules, but it is also required that InputR(
¢
m
i
)
∩
OutputR(
¢
m
j
) =
∅
and InputR(
¢
m
j
)
∩
OutputR(
¢
m
i
) =
∅
. Hence, only not-connectedmodules (level 5) satisfy the additivity property.However, disjoint modules satisfy the following couplingproperty (see [1]): Given a modular system MS’ = <E, R, M’> and amodular system MS” = <E, R, M”>, with the same underlyingsystem <E, R>, such that M” = M’ – {
¢
m
i
,
¢
m
j
}
∪
{m”}, with
¢
m
i
,
¢
m
j
∈
M’, m” =
¢
m
i
∪
¢
m
j
and m”
∉
M’, then:Coupling(m”)
≤
Coupling(m
i
) + Coupling(m
j
); Coupling(MS”)
≤
Coupling(MS’).Since this property holds for all modules in a modular system(level 4 and all levels i such that i <
c
4, i.e., all connection strengthlevels in a modular system), it also holds for disjoint modules,while coupling measures must only be additive for not connectedmodules.
3.3 Length
Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
> and a systemm
j
= <E
mj
, R
mj
>: (S = m
i
∪
m
j
and m
i
∩
m
j
=
∅
and E = E
mi
∪
E
mj
)
⇒
Length(S) = max(Length(m
i
), Length(m
j
)) E = E
mi
∪
E
mj
is already implied by S = m
i
∪
m
j
⇒
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and InputR(m
j
)
∩
OutputR(m
i
) =
∅
(Theorem 1)
⇒
m
i
and m
j
are not connected (level 5).Since disjoint modules (level 4) may be connected they do not sat-isfy this nonadditivity property.
3.4 Size
Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
> and a systemm
j
= <E
mj
, R
mj
>:(m
i
⊆
S and m
j
⊆
S and E = E
mi
∪
E
mj
and E
mi
∩
E
mj
=
∅
)
⇒
Size(S)= Size(m
i
) + Size(m
j
)Disjoint modules (level 4) satisfy this size additivity property, re-gardless whether they are connected or not. Since 5 <
c
4, the prop-erty also applies for not connected components (i.e., not connectedcomponents are disjoint by definition). Besides, size is only relatedto the elements of a system and not to relationships. Therefore,only connections through common elements matter. Disjointmodules do not have common elements.
3.5 Cohesion
Given a modular system MS’ = <E, R, M’> and a modular systemMS” = <E, R, M”>, with the same underlying system <E, R>, suchthat M” = M’ – {
¢
m
i
,
¢
m
j
}
∪
{m”}, with
¢
m
i
,
¢
m
j
∈
M’, m” =
¢
m
i
∪
¢
m
j
and m”
∉
M’ and InputR(
¢
m
i
)
∩
OutputR(
¢
m
j
) =
∅
and In-putR(
¢
m
j
)
∩
OutputR(
¢
m
i
) =
∅
, thenmax(Cohesion(
¢
m
i
), Cohesion(
¢
m
j
))
≥
Cohesion(m”) Cohesion(MS’)
≥
Cohesion(MS”)Analogous to the definition of the coupling additivity prop-erty, modules may not be connected (level 5). Curiously, andopposed to the definition of the coupling additivity property, in[1] it is not claimed that this property holds for all modules in amodular system.These results are summarized in Table 3. In each cell thelevel(s) of connection strength are indicated. Note that levels 0 to 3are not defined for modular systems such as required for themeasurement of cohesion and coupling.
TABLE 3R
ELATIONSHIP
C
ONNECTION
S
TRENGTH BETWEEN
M
ODULESAND
A
DDITIVITY
P
ROPERTIES
Concept/ Propertiesadditiverelationnonadditiverelationno definiterelationsize4-50, 1, 2, 3length50, 1, 2, 3, 4complexity50, 1, 2, 3, 4cohesion54coupling54
In [1] a similar table (Table 1, p. 81) appears in which it isclaimed that complexity and coupling are additive for both level 4and level 5 modules. We believe this table must be refined to ac-commodate the notion of connection strength between modules.
4 A
N
A
LTERNATIVE
D
EFINITION OF THE
U
NION
-O
PERATOR
The srcin of the inconsistencies in [1] can be traced back to confu-sion arisen by the definition of the union-operator of modules.Given the union-operator such as defined in [1] Theorem 2 (aproof can be found in the Appendix) states that a system is equal
194IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 23, NO. 3, MARCH 1997
to the union of its modules if and only if these modules are notconnected through common incoming and outgoing relationships.T
HEOREM
2.
Given a system
S = <E, R
>, a system
m
i
= <E
mi
, R
mi
>
anda system
m
j
= <E
mj
, R
mj
>
such that
m
i
and
m
j
are modules of
S
and
E = E
mi
∪
E
mj
:S = m
i
∪
m
j
⇔
InputR(m
i
)
∩
OutputR(m
j
) =
∅
and
InputR(m
j
)
∩
OutputR(m
i
) =
∅
Whenever an incoming relationship of one module is an out-going relationship of the other module, the system is no longer theunion of its modules. An alternative definition of the union op-erator can be given such that whenever E = E
mi
∪
E
mj
it holds thatS = <E, R> is the union of its modules m
i
= <E
mi
, R
mi
> and m
j
=<E
mj
, R
mj
> (Theorem 3; a proof can be found in the Appendix).D
EFINITION
9.
The union of
m
i
and
m
j
(notation
m
i
∪
’ m
j
)
is the system
<E
mi
∪
E
mj
, R
mi
∪
R
mj
∪
(InputR(m
i
)
∩
OutputR(m
j
))
∪
(InputR(m
j
)
∩
OutputR(m
i
))>.T
HEOREM
3.
Given a system
S = <E, R
>, a system
m
i
= <E
mi
, R
mi
>
anda system
m
j
= <E
mj
R
mj
>
such that
m
i
and
m
j
are modules of
S
and
E = E
mi
∪
E
mj
:S = m
i
∪
’ m
j
The properties of
∪
’ are: Given a system m
i
= <E
mi
, R
mi
> and asystem m
j
= <E
mj
, R
mj
> such that E
mi
∩
E
mj
=
∅
:1) (m
i
∪
m
j
)
⊆
(m
i
∪
’ m
j
)2) If m
i
and m
j
are not connected, then (m
i
∪
m
j
) = (m
i
∪
’ m
j
)3) If S = <E, R> = m
i
∪
m
j
, then m
i
and m
j
are not connected4) If S =<E, R> = m
i
∪
’ m
j
, then m
i
and m
j
are connected if andonly if (m
i
∪
m
j
)
⊂
(m
i
∪
’ m
j
).We believe that while having defined the union-operator as
∪
(cf. Definition 4), Briand, Morasca, and Basili use it as if it were theunion-operator
∪
’ (cf. Definition 9). For instance, in [1] for thesystem S = <E, R> of Fig. 1 the relationship <c, b> is included inR
m1
∪
R
m3
, although <c, b>
∉
R
m1
and <c, b>
∉
R
m3
(cf. also foot-note 2). However, it does hold that <c, b>
∈
R
m1
∪
’ R
m3
.Suppose now that all union operators
∪
are replaced by unionoperators
∪
’. The consequences for the additivity-related proper-ties for the different concepts are:
4.1 Size
No difference since only the elements of a system are relevant andthe set of elements of the union of two modules is the union of thesets of elements of these modules, no matter how union is defined.
4.2 Length
Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
> and a systemm
j
= <E
mj
, R
mj
>: (S = m
i
∪
’ m
j
and m
i
∩
m
j
=
∅
)
⇒
Length(S) =max(Length(m
i
), Length(m
j
)).Since S = m
i
∪
’ m
j
and m
i
∩
m
j
=
∅
do not imply that modulesmay not be connected, only connection strength level 4 (disjointmodules) is required.Suppose now that the measure Length is defined as follows:Length = max(shortest path in a system between any two con-nected
4
elements).Fig. 3 is obtained by adding the relation <e, d> to the system Sdepicted in Fig. 1. The modules m
1
and m
4
are disjoint (but con-nected through <d, f>). Suppose S
14
= <E
14
, R
14
> = m
1
∪
m
4
and
¢
S
14
= <E
14
,
¢
R
14
> = m
1
∪
’ m
4
. According to the definitions of theunion operators
∪
and
∪
’ the relation <d, f> belongs to
¢
S
14
, butnot to S
14
. Calculating Length results in:
4. Given a system S = <E, R>.
∀
e
1
, e
2
∈
E: e
1
is connected with e
2
⇔
<e
1
, e
2
>
∈
TC(R), where TC(R) is the transitive closure of R:
∀
e
1
, e
2
∈
E: <e
1
,e
2
>
∈
R
⇒
<e
1
, e
2
>
∈
TC(R);
∀
e
1
, e
2
, e
3
∈
E: <e
1
, e
2
>
∈
R and <e
2
, e
3
>
∈
TC(R)
⇒
<e
1
, e
3
>
∈
TC(R).
Length(m
1
) = 3Length(m
4
) = 1Length(S
14
) = 3Length(S)
14
¢ =
4While Length satisfies the nonadditivity property defined withthe union operator
∪
(as in [1]), it does not satisfy the non-additivity property defined with the alternative operator
∪
’.
Fig. 3. Adding <e, d> to the system S.
4.3 Complexity
Given a system S = <E, R>, a system m
i
= <E
mi
, R
mi
> and a systemm
j
= <E
mj
, R
mj
>: (S = m
i
∪
’ m
j
and m
i
∩
m
j
=
∅
)
⇒
Complexity(S) =Complexity(m
i
) + Complexity(m
j
). Again, only connectionstrength level 4 (disjoint modules) is required.Suppose a measure Complexity(S) is defined as the cardinalityof R, where S = <E, R>. Calculating Complexity for m
1
, m
4
, S
14
=m
1
∪
m
4
and
¢
S
14
= m
1
∪
’ m
4
results in:Complexity(m
1
) = 6Complexity(m
4
) = 2Complexity(S
14
) = 8Complexity(S)9
14
¢ =
Complexity satisfies additivity if union is defined with
∪
, but notif union is defined with
∪
’.
4.4 Cohesion
No difference since only intramodule relationships are consideredin the concept properties. Hence, it does not matter whether theunion of modules contains the intermodule relationships betweenthe modules or not.
4.5 Coupling
For the coupling disjoint module additivity property it is explicitlyrequired that no intermodule relationships between the modulesexist. Therefore, for all modules
¢
m
i
and
¢
m
j
that satisfy the condi-tions of the property, m” =
¢
m
i
∪
¢
m
j
=
¢
m
i
∪
’
¢
m
j
, since m
i
and m
j
may not be connected. Therefore, in this case we believe ambiguitycan be removed by changing the name of the property from dis- joint module additivity to not connected module additivity. Atleast for length and complexity the relationship between additiv-ity-related properties and connection strength must be formallydefined since ambiguities (e.g.,
∪
or
∪
’) may lead to measures being accepted or rejected for the wrong reasons.
5 C
ONCLUSION
Briand, Morasca, and Basili established the foundation of a formaland rigorous approach to property-based software engineeringmeasurement. Compared to property sets that were previouslypublished, their set shows a number of benefits. The wide cover-age of measurement concepts, the formality of the definitions, andthe correspondence with earlier published axiom sets and meas-

Search

Similar documents

Related Search

Component Based Software EngineeringComponent-Based Software Engineering (CBSE)Search Based Software EngineeringValue Based Software EngineeringEvidence Based Software EngineeringSoftware EngineeringAgent Oriented Software EngineeringWeb, Graphic Design and Software EngineeringPerformance Based Earthquake EngineeringSoftware Engineering education

We Need Your Support

Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks