Complexity Metrics

for Component-Based Software System

Rajni Sehgal, Deepti Mehrotra and Renuka Nagpal

Abstract Today, softwares are influencing almost every process involved in our
day-to-day life. The dependence of our routine processes of software system makes
the reliability of these softwares a major concern of industry. Various metrics and
benchmark are designed to ensure the smooth design and implementation of soft-
ware, among which complexity is one. It is always a desire software architect to
design software with lesser complexity. In this paper, component-based software
is considered and metrics to measure the complexity of the software is proposed.
Complexity needs to be measured at component level and its relationship with other
components. UML diagram is drawn to propose a new metrics, and dependency
of one component to another component is measured. Various complexity metrics
namely Method Complexity MCOM, Number of Calls to Other Methods (NCOM),
Component Complexity (CCOM) is evaluated, and Emergent System Complexity
(ESCOM) and overall complexity of the system are evaluated incorporating the con-
tribution of each.

Keywords Complexity · UML · CPDG · MCOM · NCOM · CCOM

1 Introduction

Software complexity is one of the biggest challenges for the software industry to
maintain the quality of the software. As the software grows in size, software com-
plexity also increases and becomes difficult to measure [1]. The complexity of a

R. Sehgal (B) · D. Mehrotra · R. Nagpal

Amity School of Engineering and Technology, Amity University,
Noida, Uttar Pradesh, India
e-mail: rsehgal@amity.edu
D. Mehrotra
e-mail: dmehrotra@amity.edu
R. Nagpal
e-mail: rnagpal1@amity.edu

© Springer Nature Singapore Pte Ltd. 2019 13

K. Ray et al. (eds.), Soft Computing: Theories and Applications,
Advances in Intelligent Systems and Computing 742,
https://doi.org/10.1007/978-981-13-0589-4_2
14 R. Sehgal et al.

software system developed based on the component-based software engineering is

dependent on the various parameters: (i) Number of components (ii) Number of
interfaces (iii) Usage of a component (iv) and Number of dependency of one com-
ponent on another. Software metrics plays a major role in measuring the attributes
of software quality. Complexity of a software system is a measurable parameter of
software engineering and can be measured well with the help of complexity metrics.
This paper considers component-based software which is having 15,000 LOC and
12 components. Various complexity metrics namely Method Complexity MCOM,
Number of Calls to Other Methods (NCOM), Component Complexity (CCOM),
Emergent System Complexity (ESCOM) are evaluated. A new metrics to measure
the complexity of the software is proposed based on the metrics that can be calculated
at the time of design of the software using the UML diagram [2]. A Component
Dependency Graph (CPDG) is constructed based on the sequence diagram showing
the relative dependencies between several components and how many times these
components interact with one another [3]. It gives an overall description of the entire
system that includes all the components involved in the system. This paper is divided
into six sections. Section 2 presents the work done by the various authors in the field of
software complexity. Section 3 describes the framework to propose the new metric.
In Sect. 4, the methodology is discussed. Section 5 presents the results obtained
during the study. Finally, the conclusion is discussed in Sect. 6.

2 Related Work

Shin and Williams [1] perform the statistical analysis on nine software complexities
and analyze that the software complexity plays a major role in software quality.
Nagappan et al. [4] apply the principal component analysis to find out the cyclomatic
complexity which strongly affects the complexity of the code. D’Ambrogio et al. [2]
discussed a method of prediction of software reliability which predicts the reliability
at earlier stages in the development process using the fuzzy method. This paper
contains a more generalized approach, and the reliability is calculated using the fault
tree method. This approach principally makes use of UML diagrams developed in
the earlier stages of software development lifecycle making it easier to predict the
software reliability at the more initial stages saving cost, time, and money. Ali et al.
[5] discussed a technique for early reliability prediction of software components
using behavior models. The behavior models are the diagrams which predict the
reliability by showing the interaction between these components, and how these
components work with each other to perform the desired functionalities. Bernardi
et al. [6] predict the software reliability by using fuzzy methods. The paper contains
a more generalized approach, and the reliability is calculated using the fault tree
method with the use of UML diagrams. System dependability is defined as the degree
to which the system can be considered dependable. System dependability is measured
using the following factors, or it considers the following factors: fault tolerance, fault
prevention, fault removal, and fault forecasting. Sahoo and Mohanty [7] predict the
Complexity Metrics for Component-Based Software System 15

Fig. 1 Frame work to

propose a new complexity Consider a Component
metric based system

Construct a class diagram

to measure complexity at
design time

Sequence Diagram

Component Dependency
Graph

New Metrics based on the

design of the software

testing effort of software tester using UML Diagrams. Software testing is essential
to maintain the quality of the software. Accurate test cases defined for the system are
significant for checking as to what degree the software is reliable. Estimation of test
cases done at earlier stages of the SDLC [8] is very challenging and has its issues
because very less knowledge is available about the system in these initial phases
of SDLC [9], [10]. The functional requirements are ready during the requirement
phase. Hence, there is a need of the hour for early test prediction at the requirements
specification stage and are accomplished using UML diagrams. UML gives enough
information about the system which is necessary for the prediction of test cases [11].

3 Framework for Proposed Model

In this study, various complexities are evaluated at various levels which include
(i) Level-1 Complexity called Method Complexity (MCOM).
(ii) Level-2 Complexity Component Complexity (CCOM).
(iii) Level-3 Complexity Emergent System Complexity (ESCOM) of a component-
based system is measured by using various design metrics which is given in
the literature.
(iv) Level-4 Complexity metrics is proposed by using the parameter coupling and
interaction probabilities between the components [12]. To evaluate this metric,
framework is given in Fig. 1.
16 R. Sehgal et al.

Fig. 2 Class diagram

material button elevation effect circular material panel floating label material line field renderer material material ripple effect ripple animation
textfield combobox iconbutton
getlevel()

paint(g:Graphics)

update() materialcombobox()

getlevel() paint(g:Graphics)
paint(g:Graphics2D)

isFloatingAbove() paint(g:graphics) RippleEffect(final comp:JComponent)

setLevel(level:int)

update()

setlevel() addRipple()

setlevel(level:int) floatinglabel start()

getlevel() libe(target:JComponent())

getwidth()
material color scrollbar popup

Fig. 3 Sequence diagram

4 Methodology

In order to calculate metric, the following steps are followed.

Step1: Component-based software is considered which is having 15,000 LOC is
considered and various UML diagrams: (i) Class diagram and (ii) Sequence diagram
is drawn in order to achieve the design level complexity by calculating the dependency
of one component to another which is shown in Figs. 2 and 3.
Step2: A component dependency graph (CPDG) is developed which gives us the
estimation of dependency of components with each other. This is given in Fig. 4.
Step3: Various complexities are measured at level-1, level-2 and Level-3 for
component-based software, which is given in Eqs. 1–3 and new metrics which is
called Level-4 complexity metrics is proposed in Eq. 6.
Complexity Metrics for Component-Based Software System 17

Fig. 4 CPDG graph

Table 1 Method complexity

Class name Cyclomatic Components NCOM(mi)
Complexity CC(mi)
Roboto 14 C1 2
Material Color 2 C2 5
Material Shadow 14 C3 0
Material Button 27 C4 1
Material Formatted 27 C5 1
Text Field
Material progress 2 C6 1
Spinner
Material Password 15 C7 2
Field
Material Text Field 15 C8 0
Line 1 C9 2
Elevation Effect 9 C10 0
Ripple Effect 9 C11 1
Material Combobox 3 C12 1
Icon button 10
Icon button Window 2
Icon button Panel 4
Ripple Animation 1

(i) Level-1 Method Complexity (MCOM) is calculated as given in Eq. (1) and
shown in Table 1.

MCOM(mi )  CC(mi ) + NCOM(mi ) (1)

where CC is the Cyclomatic Complexity, NCOM is the Number of Calls to other

methods (Table 1).
The total method complexity of a component Cj (TMCOM) is the sum of all
complexities of individual methods and is estimated as:
18 R. Sehgal et al.

Table 2 Component complexity

Component name Components NIMC NOIC NCOC V
MaterialFormattedTextField C1 2 1 0
ElevationEffect C2 5 2 1
MaterialButton C3 0 0 2
MaterialCombobox C4 1 1 1
MaterialColor C5 1 2 2
Circular C6 1 1 0
FieldRenderer C7 2 3 2
RippleEffect C8 0 2 2
RippleAnimation C9 2 1 0
MaterialPanel C10 0 0 2
FloatingLabel C11 1 1 2
Line C12 1 0 0

n
TMCOM(Cj)  MCOM(mi )  155 + 16  171
i1

(ii) Level-2 Component Complexity (CCOM) which can be calculated in Eq. 2

and given in Table 2.

CCOM(Ci )  NIMC(C) + NOIC(C) + NCOC(C) (2)

where
NIMC Number of Internal Method Calls
NOIC Number of Interfaces of a Component
NCOC Number of Couplings to Other Components
The Total Component Complexity (TCCOM) based on all components Ci in a
component-oriented software system S is estimated as
TCCOM(S)  ni1 CCOM (ci )  16 + 14 + 14  44 for all components Ci of
a software system.
(iii) Level-3 Emergent System Complexity (ESCOM) of a component-oriented sys-
tem S could be represented by a function f for the two given values (i) Number
of Links Between Components (NLBC) and (ii) Depth Of the Composition
Tree (DOCT) can be calculated in Eq. 3 and shown in Table 3.

ESCOM(S)  f(NLBC(S), DOCT(S)) (3)

where Depth Of the Composition Tree (DOCT): It is the number of levels in the
entire system. Thus, emergent complexity is the summation of NLBC and DOCT
values, ESCOM  22 + 5 = 27.
Complexity Metrics for Component-Based Software System 19

Table 3 NLBC values Interacting components NLBC value

C1,2 2
C2,4 3
C2,3 2
C5,4 1
C6,5 4
C6,3 1
C6,7 1
C7,8 1
C7,11 1
C8,9 2
C10,11 3
C11,12 1

Thus, the overall complexity of the system is TMCOM (Cj ) + TCCOM(S) +

ESCOM  177 + 44 + 27  248.
(iv) Level-4 New Proposed metrics to measure the complexity of component-
based system
The new proposed metrics is based on the two parameters (i) coupling between
the components (ii) Interactions probabilities between the components which are
described below
(a) Coupling: coupling is defined as the degree to which the components present
in the system are related to each other i.e., how much dependency is present
among the components Eq. (4) [13]. A highly coupled system is one in which
the directed graph is dense and it requires more precise reliability estimation
since the components are dependent on each other vice versa id for low coupling
systems
 
∪1≤i≤mij NUj,i 
NUj    (4)
Nj |+|Uj 

where NJ and UJ are set of methods and instance variable of component.

(b) Interaction probabilities: Interaction probability that is pij is the probability of
transition tij being executed, where i and j represent the source component and
destination component, respectively, and it is estimated from the percentage
of the number of messages that the source component Ci sends to the target
component Cj to the total number of messages that the source component Ci
sends to all other components Ck in the architecture as given in Eq. 5 [14]
20 R. Sehgal et al.

Table 4 Probability distribution table

1 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
2 C1 0 0 0 0 0 0 0 0 0 0 0 0
3 C2 1 0 0 0 0 0 0 0 0 0 0 0
4 C3 0 1 0 0 0 1 0 0 0 0 0
5 C4 1 0 0 0 0 0 0 0 0 0 0 0
6 C5 0 0 0 0 0 0 0 0 0 0 0 0
7 C6 0 0 0 1 1 0 1 0 0 0 0
8 C7 0 0 0 0 0 0 0 0 0 0 0 0
9 C8 0 0 0 0 0 0 1 0 1 0 0 0
10 C9 0 0 0 0 0 0 0 0 0 0 0 0
11 C10 0 0 0 0 0 0 0 0 0 0 1 0
12 C11 0 0 0 0 0 0 1 0 0 0 0 1
13 C12 0 0 0 0 0 0 0 0 0 0 0 0

 
Interact ci , cj
pij     (5)
Interact ci , cj

Hence, final New Proposed Level-4 complexity is calculated as Eq. 6

n 
Level − 4 Complexity  Ci ∗ Pij (6)
i1

where
Ci Coupling between the components
pij Interaction Probablities.

5 Results

In order to calculate the probabilities of interaction between the components, pairwise

comparison is done using Fig. 3 which is given in Table 4.
After the pairwise comparison of interaction between the component, probability
and coupling are calculated using Eqs. 4 and 5. Level 4 complexity is calculated
using Eq. 6 shown in Table 5.
The overall complexity of the given software using the new proposed complexity
metrics is 10.6.
Complexity Metrics for Component-Based Software System 21

Table 5 Probability of interaction between the components

Cij (Pairwise Pij Coupling between Level 4 complexity
components) objects (CBO)
C2,1 1 2 1
C3,2 0.66 4 2.64
C4,2 1 1 0.66
C5,4 1 2 1.32
C6,5 0.4 2 0
C6,7 0.5 1 0.66
C8,9 0.66 2 1.32
C8,7 0.33 2 1
C10,11 1 2 1
C11,7 0.5 1 1
C11,12 0.5 0 0
Overall complexity 10.6

6 Conclusion

A new level of complexity component-based software is proposed. We calculated

the level 4 complexity for each component in the system. The components whose
complexity came out to be zero can be removed as they do not contribute to sys-
tem’s performance. By eliminating such component, we make our system’s perfor-
mance fast and reliable, also we need less of testing time, manpower, and resources
when such components are removed. The calculations and results we obtained are of
great importance and significance in the field of future research. This area of study
needs more of practical implementation and validation from large and complicated
data that is used for industry purposes. We will be able to find a good relationship
between metrics values and development and maintenance efforts, which are the most
cost-determining factors in software projects when used on implemented and large
projects. There is another significant point that must be taken into consideration is
that it is difficult to determine metric values from system designs and usually devel-
opers do complain that collection of metrics is a very boring and time-consuming
task.

References

1. Shin, Y., Williams, L.: Is complexity really the enemy of software security?. In: Proceedings
of the 4th ACM Workshop on Quality of Protection. ACM (2008)
2. D’Ambrogio, A., Iazeolla, G., Mirandola, R.: A method for the prediction of software reliability,
Department of Computer Science, S&P University of Roma, Italy Conference Paper, Nov 2012
22 R. Sehgal et al.

3. Balsamo, S., et al.: Model-based performance prediction in software development: a survey.

IEEE Trans. Softw. Eng. 30(5), 295–310 (2004)
4. Nagappan, N., Ball, T., Zeller, A.: Mining metrics to predict component failures. In: Proceed-
ings of the 28th International Conference on Software Engineering (ICSE’06), pp. 452–461,
Shanghai, China, 20–28 May 2006
5. Ali, A., Jawawi, D.N.A., Isa, M.A., Babar, M.I.: Technique for Early Reliability Prediction of
Software Components Using Behaviour Models, Published: 26 Sept 2016
6. Bernardi, S., Merseguer, J., Petriu, D.C.: 1Centro Universitario de la Defensa, Dependability
Modeling and Assessment in UML-Based Software Development, Department of Systems and
Computer Engineering, Carleton University, Ottawa, ON, Canada, 25 May 2012
7. Sahoo, P., Mohanty, J.R.: Early Test Effort Prediction using UML Diagrams, School of Com-
puter Engineering, KIIT University, Campus-15, Bhubaneswar (2017)
8. Software Safety, Nasa Technical Standard. NASA-STD- 8719.13A, 15 Sept 2000
9. Yacoub, S.M., Ammar, H.H.: A methodology for architecture level reliability risk analysis.
IEEE Trans. Softw. Eng. 28(6), 529–547 (2002)
10. Ammar, H.H., Nikzadeh, T., Dugan, J.B.: Risk assessment of software system specifications.
IEEE Trans. Reliab. 50(2) (2001)
11. Jatain, A., Sharma, G.: A systematic review of techniques for test case prioritization. Int. J.
Comput. Appl. (0975 – 8887) 68(2) (2013)
12. Chen, J., Wang, H., Zhou, Y., Bruda, S.D.: Complexity metrics for component-based software
systems. Int. J. Digit. Content Technol. Appl. 5(3), 235–244 (2011)
13. Talib, M.A.: Towards early software reliability prediction for computer forensic tools (case
study), June 2016
14. Vinod, G.: An Approach for Early Prediction of Software Reliability, Nov 2011