Information Technology Reference
In-Depth Information
In software, several measures of coupling were proposed. For example, in the OOT
case, such as the study in Section 13.3, we propose the following coupling measure
(
C
F
) between the software classes (Figure 13.9)
i
=
1
p
J
=
1
is rel
c
i
,
p
c
j
C
F
=
(13.15)
p
2
−
p
where
p
is the total number of objects (DPs) in the concerned software, and
1 f s
i
has a relation with class
j
0
is rel
=
Otherwise
The relation might be that class
i
calls a method in class
j
or has a reference to class
j
or to an attribute in class
j
. In this case,
C
F
measures the strength of intermodule
connections with the understanding that a high coupling indicates a strong dependence
between classes, which implies that we should study modules as pairs. In general, a
low coupling indicates independent modules, and generally, we desire less coupling
because it is easier to design, comprehend, and adapt.
Dharma (1995) proposed the following coupling metric:
k
M
m
c
=
(13.16)
=
d
i
+
×
c
i
+
d
o
+
×
c
o
+
g
d
+
×
g
c
+
+
M
2
2
2
w
r
(13.17)
with the following arguments:
Data and control flow coupling
d
i
=
number of input data parameters
c
i
=
number of input control parameters
d
o
=
number of output data parameters
c
o
=
number of output control parameters
Global coupling
g
d
=
number of global variables used as data
g
c
=
number of global variables used as control
Environmental coupling
w
=
number of modules called (fan-out)
r
=
number of modules calling the module under consideration (fan-in)
The more situations encountered, the greater the coupling and the smaller
m
c
.
One
problem is parameters and calling counts do not guarantee the module is linked to
the FRs of other modules.
Search WWH ::
Custom Search