2019 IEEE Jordan International Joint Conference on Electrical Engineering and Information Technology (JEEIT)

A Code Complexity Model of Object Oriented

Programming (OOP)
Hiba Wasmi
Hussam Hourani Thamer Alrawashdeh
Faculty of Science and IT
Faculty of Science and IT Faculty of Science and IT
Al Zaytoonah University of Jordan
Al Zaytoonah University of Jordan Al Zaytoonah University of Jordan
Amman, Jordan
Amman, Jordan Amman, Jordan
hiba.sof.86@gmail.com
hussam.hourani@gmail.com thamer.r@zuj.edu.jo

Abstract— The Code Complexity and Object Oriented considering code complexity as a major factor when they
Programming (OOP) is an import topic due to the role of OOP build software applications, as this will improve code
playing in most of the software design and architectures quality, increase robustness and enhance the return on
nowadays. In OOP there are key design concepts like investment [2,3,4].
Encapsulation, Polymorphisms and Inheritance that affect the
coding design, structure and style. The challenge is how to Traditional code complexity metrics like Cyclomatic
minimize the Complexity in OOP and complying with the key Complexity (McCabe, 1976), is used to evaluates the code
concepts of OOP design. This paper reviews the literature on complexity of an algorithm in a method. Cyclomatic
current solutions for code complexity and proposes a new complexity measures the number of linearly independent
model for OOP code complexity. The new model has added paths through function or method’s code. It is one of most
into OOP complexity metrics the following characteristics: used metric among other metrics like: Line of code,
abstraction and class details complexity. The proposed model is Halstead’s measure and others [5, 6, 7]. Traditional metrics
based on the following attributes selection criteria: looked also into the code size, number of variables and
Readability, Understandability, Maintainability, Reusability, arguments and the comments percentages in the whole
Extensibility and Consistency of the programming code. program [8, 9].
Keywords— Code complexity, Object Oriented Programming, The idea behind the OOP was derived mainly from the
OOP, OOP Metrics, 2O2C Metrics. representation of knowledge in the human brain in according
to the real world. The idea and the theory of OOP were
I. INTRODUCTION developed by cognitive scientists. According to the object-
oriented paradigm, the object consists from: Attributes
Code Complexity (CC) Metrics refers to the software (Properties) and Methods (Actions). The main concepts
measurements used to indicate the complexity in a program. behind the OOP are showing in Figure 1, the following is the
It tells how complex the code is. IEEE defines complexity as explanation of the idea behind each concept:
“the degree to which a system's design or code is difficult to
understand because of numerous components or relationships
among components” or” the degree to which a system or
component has a design or implementation that is difficult to
understand and verify” [1]. There have been many proposed
code complexity metrics since the early stage of software
development itself. Code complexity measurement can
facilitate and ease the maintainability, extensibility,
readability, consistency and understandability of
programming code. Therefore, the code complexity metrics
is considered as a key quality driver for each software
developer. Measuring code complexity will structure how the
developers design their code and how to make it less
complex. Furthermore, minimizing the code complexity will
reduce the risks of introducing defects in the development
and the production environments and will have a great
benefits for testability and robustness. In Addition,
reusability of the code can save huge amount of money for
organization. Therefore, when minimizing the code
complexity and control, the code can be easily reuse and
maintain and easy to integrate between layers and Fig. 1. OOP key dimensions
components in an application. Organizations start

978-1-5386-7942-5/19/$31.00 ©2019 IEEE 560


  
 


  
 


 

x Encapsulation: “a software development technique x Response for a Class (RFC): A set of methods that
that consists of isolating a system function or a set of can potentially be executed in response to a message
data and operations on those data within a module received by an object of that class.
and providing precise specifications for the
module”[1]. x Lack of Cohesion in Methods (LCOM): Cohesion
metrics measure how well the methods of a class are
x Inheritance: “a semantic notion by which the related to each other.
responsibilities (properties and constraints) of a
subclass are considered to include the responsibilities
of a superclass, in addition to its own, specifically
declared responsibilities” [1].
x Polymorphisms: is implementing the same methods
or operators in varying or different ways.
Object oriented paradigm defers from traditional
programming in the mean that it controls complexity by
supporting hierarchical decomposition through both data and
procedural abstraction [10]. OOP software design and its
code complexity evolution as a research area started as early
as the OOP started. There are many researchers who looked
into this area and proposed metrics models.
The motivation for this work is to provide a new
comprehensive model for OOP complexity measurement, as
handling code complexity in OOP is one of the key
challenges for organizations and developers nowadays. The
challenge is how to manage, optimize and minimize code
complexity in object oriented programming by implementing
best practice and preserving key concepts in OOP. This Fig. 2. CK Metrics
paper has investigated the famous code complexity models in
the literature and proposed a new model for OOP code
complexity. The objective is to review the current OOP code A Key note for this model is that it didn’t take in
complexity models and propose a new model that considers consideration the Abstraction measurement along with other
the following keys: maintainability, extensibility, readability, dimensions. Also there is different interpretation of the
consistency and understandability of programming code in Weighted Method per Class dimension, as some consider as
OOP. number of methods per class and other consider it as
Cyclomatic complexity.
II. LITERATURE REVIEW
B. The R. C. Martins Metric

In OOP practices, the main benefit of using OO metrics

The R. C. Martin (Martin, 1994) is also a famous metrics
is to improve and enhance the quality by making the code
for OOP design complexity features that affect the classes
more readable and easy to maintain. The next section will
design. It consists of five dimensions as shown in Figure 3
highlight the famous models for evaluating the code
[8]. This metrics measures the quality of object-oriented
complexity in OOP.
design in terms of the interdependence between packages.
A. Chidamber and Kemmerer metric suite

The Chidamber & Kemerer (CK) that was introduced in

1991 is the most common metrics. It consists of 6
dimensions as shown in Figure 2 [11, 8, 12, 13, 14, 15].
The CK metrics consist of the following dimensions:
x Weighted Method per Class (WMC) : The sum of
the complexity of all methods defined in a class.
x Depth of Inheritance Tree (DIT): Maximum
inheritance path from the class to the root class.
x Number of Children (NOC): Number of immediate
sub-classes of a class.
Fig. 3. R.C Martin Metrics
x Coupling between Objects (CBO): Number of
classes to which a class is couple.

561

  
 


  
 


 

The R.C. Martins Metrics consists of the following
dimensions:
x Efferent Coupling (Ce): Total number of classes
inside a package that depend upon classes outside
this package [16].
x Afferent Coupling (Ca): Total number of classes
outside a package that depend upon classes within
that package [16].
x Instability: Measured by calculating the effort to
change a package without impacting other packages
within the application [16].
x Abstractness: The comparison of the number of
abstract classes (and interfaces) to the total number
of classes in the evaluated package [8].
x Normalized Distance from Main Sequence (Dn):
This dimension is a measure of abstractness and
stability[8].
The methodology for proposing the new model was
based on reviewing the previous models and review the key
concepts of OOP and suggest the new model. The proposed
model highlighted in Figure 5 is mainly different from other
models in two aspects: The first aspect is that it brings the
abstraction as a key driver for complexity, and the second
aspect it considers the class’s details are also a key factors
when counting the overall complexity for the program.
The proposed model has inherited some dimensions from
Chidamber and Kemmerer metric suite including: DIT,
NOC, CBO and COM. Other dimensions and attributes have
been added based on the above selection criteria. The 2O2C
Model consists of dimensions and attributes as shown in
Figure 5.

C. Othor OOP metrics

There are other metrics for OOP, the following are the
most common metrics: MOOD and MOOD2 metric suite
(Abreu, 1995) and Lorenz and Kidd metric suite (Lorenz &
Kidd, 1994), Design metrics for testing (Binder 1994),
product metrics for object-oriented design (Purao&Vaishnavi
2003, Vaishnavi et al 2007), Henderson–Sellers metrics
(Henderson–Sellers 1996) and many others [17,12,15,18].
The next section will highlight the proposed new model for
OOP Code complexity.

III. THE PROPOSED OOP METRICS MODEL

OOP can solve a problem by modeling software in a way

similar to the way that human models everything else in the
world. So object oriented programming is considered as a
framework for managing complexity if applying the key
concept of the OOP and when done right. The current OOP
code complexity models have been reviewed and some
aspects of the selected dimensions in each model analyzed as
well. A new OOP Code complexity model called: Object
Oriented Code Complexity (2O2C) Metrics has been
proposed. It mainly focuses on achieving the following six
objectives as shown in Figure 4: Readability,
Understandability, Maintainability, Reusability, Extensibility
and Consistency.
Fig. 5. 2O2C Dimensions and Attributes
Abstraction is one of the key concepts of object oriented
programming (OOP) languages. We have added this key
dimension to the proposed model as its main objective is to
handle complexity by hiding details from the user using
encapsulation. Users can build over classes without the need
to know every single detail inside the class, which simplifies
code complexity.
To measure the code complexity inside the classes,
another key dimension has been added to the proposed
model. This dimension is Detailed Class Complexity (DCC)
that accumulates the complexity of all highlighted sub
attributes as shown in the below equation (where n is number
of classes in the application):

Fig. 4. Selection Criteria Key Drivers

562

  
 


  
 


 

A. The proposed Model’s Attributes B. The2O2C suggested Measurment and KPIs

The proposed 2O2C Metrics Model consists of the Table 1 highlights the suggested metrics and the targets
following dimensions and attributes: for each dimension and attribute in the proposed Model [8,
19]:
x Weighted Class Abstraction (WCA): it estimates the
encapsulation, the generalization relationship and Table 1
specialization [2]. The more Abstraction the less Category Suggested Target Objective
complexity. Weighted Class The more WDA the less complexity High
Abstraction (by hiding details from the user)
x Depth of Inheritance Tree (DIT): A class instantiated
(WCA)
too deeply in the inheritance tree will be relatively
complex. The more deep the more complexity. Depth of If the DIT is more than six (Sinaalto, Low
Inheritance Tree 2009), it increases the design
x Number of Children (NOC): The number of (DIT) complexity [8]
immediate sub-classes subordinate to a class in the
class hierarchy. It is an indicator of the potential Number of If the NOC is high, dilution of Low
influence a class can have on the design or the Children (NOC) abstraction of classes takes place [8]
system [8].
Coupling If CBO is high, it complicates the Low
x Coupling between Objects (CBO): Coupling means Between testing process [8]
Objects (CBO)
that one or more objects depend on each other on the
design [2]. The higher object class coupling, the Cohesion in If the COM in methods is low then it High
more complexity. Methods (COM) increases the class design complexity
[8]
x Cohesion in Methods (COM): Cohesion measure the
relationships between attributes and methods [2]. Detailed Class This is the total complexity from its As per the
The higher the cohesion between attributes and Complexity attributes complexity, it is the DCC below sub
methods, the less complexity. (DCC) equation. attributes
objectives
x Detailed Class Complexity (DCC): The following is
the details of writing a Class and the related metrics: Cyclomatic As per [2]: Low
Complexity per x One to Ten: Simple and easy to
o Cyclomatic Complexity per Method Method (CCM) understand, no much risk
(CCM): A Cyclomatic complexity was x Eleven to Twenty:
Harder/complex, moderate risk
invented by a researcher McCabe 1976,
x Twenty one to fifty:
this metric works based on program Harder/Complex and involve
control structure [2]. The more Cyclomatic high rate of risk
complexity the more code complexity. x Fifty and above: Cannot be
tested, very high risk
o Number of Lines per Method (NLM):
Measure the size of the code (count of total Number of The less the better Low
number of lines excluding space and Lines per
comments lines) in a method, the more Method (NLM)
size of code the more complexity.
Number of The less the better Low
o Number of Variables per Method (NVM): Variables per
Method (NVM)
Measures number of variables per
methods, the more variables the more Number of The less the better Low
complexity. Parameters per
Method (NPM)
o Number of Parameters per Method (NPM):
Measures the number of parameters per Number of The less the better Low
method. The more parameters the more Attribute per
complexity. Class (NAC)

o Number of Attribute per Class (NAC): Number of The less the better Low
Measure number of attributes per class, the Methods per
more attributes the more complexity. Class NMC)

o Number of Methods per Class NMC): Class Comments 20% at least High
Measure number of methods per class, the Percentage
(CCP)
more methods the more complexity.
o Class Comments Percentage (CCP):
Measure size of comments per code, the
more comments the less complexity.

563















 
IV. CONCLUSION
The code complexity metrics is considered as a key
quality driver for each software developer. Measuring code
complexity will structure how the developers design their
code and how to make it less complex. Minimizing the code
complexity will reduce the risks of introducing new defects
in the development and the production environments and will
have a great benefits for applications testability and
robustness. In this paper, we highlighted the main metrics for
OOP paradigm that affect both design and implementation
and provided the details of CK and R.C.Martin models. We
have proposed a new OOP Code complexity metrics suite
called: Object Oriented Code Complexity (2O2C) Metrics
Suite. It mainly focuses on achieving the following six
objectives: Readability, Understandability, Maintainability,
Reusability, Extensibility and Consistency.
We based our new model on some of the Chidamber &
Kemerer model’s dimensions however we added the
Abstraction and the Detailed Class Complexity as
highlighted in Figure 5. We also added the abstraction as its
main objective is to handle complexity by hiding details from
the user. Also we detailed the class proprieties in 7 sub
attributes that control the complexity inside the class itself.
The 7 sub attributes in the Detailed Class Complexity (DCC)
handle the internal class structure and methods complexity
details. The proposed model can be used to measure the OOP
Code Complexity in a comprehensive and robust way and
can help the developers to simplify their code and enhance
the quality.
For future work: We didn’t experience the proposed
model on solutions yet. The future work can support the
proposed 2O2C model by applying the suggested metrics on
real solutions and compare the results with the other models.
We suggest applying the proposed model on three languages
like: Python, C++ and Java. Comparing the results from the
three languages will provide fair results to judge the
proposed model outcomes.
REFERENCES
[1] “24765-2010 - ISO/IEC/IEEE International Standard - Systems and
software engineering -- Vocabulary.”,2010.
[2] U. Eaganathan, M. Dehkordi and A.Ali," A Study of Object Oriented
software complexity and sizing measure," International Journal of
Pharmacy & Technology,pp.23027–23040 ,2016.
564
[3] U. Eaganathan, M. Dehkordi and A.Ali," A Study of Object Oriented
software complexity and sizing measure," International Journal of
Pharmacy & Technology,pp.23027–23040 ,2016
[4] K.Meftah,"A Comparison of CK and Martin's package metrics suites
in predicting package reusability in open source object-oriented
software," A dissertation submitted in partial fulfillment of the
requirement for the award of the Degree of Master of Computer
Science (Software Engineering), 2016.
[5] Ankita," An approach for improving the concept of Cyclomatic
Complexity for Object-Oriented Programming,"
[6] Á. Fóthi, J. Nyéky-Gaizler, and Z. Porkoláb, “The structured
complexity of object-oriented programs,” Mathematical and
Computer Modelling, vol. 38, no. 7-9, pp. 815–827, 2003.
[7] D. Pawade, D. J. Dave, and A. Kamath, “Exploring software
complexity metric from procedure oriented to object oriented,” 2016
6th International Conference - Cloud System and Big Data
Engineering (Confluence), 2016.
[8] Y. Suresh, J. Pati, and S. K. Rath, “Effectiveness of Software Metrics
for Object-oriented System,” Procedia Technology, vol. 6, pp. 420–
427, 2012
[9] M.Job," Analysis of Software Complexity Using Object Oriented
Design Metrics in Java Application," International Journal of
Advanced Research in Computer Engineering & Technology
(IJARCET),vol.5,no. 10,pp. 2492–2499,2016.
[10] U. Chhillar and S. Bhasin, "A New Weighted Composite Complexity
Measure for Object-Oriented Systems," International Journal of
Information and Communication Technology Research,
vol.1,no.3,pp.101-108,2011
[11] M. Hitz and B. Montazeri, “Chidamber and Kemerers metrics suite: a
measurement theory perspective,” IEEE Transactions on Software
Engineering, vol. 22, no. 4, pp. 267–271, 1996.
[12] M.Sarker and J.Borstler, " An overview of Object Oriented Design
Metrics," Master Thesis Department of Computer Science, Umeå
University, Sweden,pp.1-53, 2005.
[13] D. I. D. Silva, N. Kodagoda, S. R. Kodituwakku, and A. J.
Pinidiyaarachchi, “Limitations of an object-oriented metric: Weighted
complexity measure,” 2015 6th IEEE International Conference on
Software Engineering and Service Science (ICSESS), 2015.
[14] B. M. Goel, “A Study on Object-Oriented Testing Technique and
Object-Oriented Metrics Useful in Reducing Class Testing
Complexity,” 2014 Fourth International Conference on Advanced
Computing & Communication Technologies, 2014.
[15] J.Al-Ja'afer and K.Sabri,” Chidamber-Kemerer (Ck) And Lorenze-
Kidd (Lk) Metrics To Assess Java Programs”,2004
[16] G. Kaur and D. Sharma, “A Study on Robert C. Martins Metrics for
Packet Categorization Using Fuzzy Logic,” International Journal of
Hybrid Information Technology, vol. 8, no. 12, pp. 215–224, 2015.
[17] S. Misra, I. Akman, and M. Koyuncu, “An inheritance complexity
metric for object-oriented code: A cognitive approach,” Sadhana, vol.
36, no. 3, pp. 317–337, 2011
[18] B. Katoch and L.Shah,” A Systematic Analysis on MOOD and
QMOOD Metrics”,2014
[19] S. Pasupathy and R. Bhavani, “Object Oriented Metrics Evaluation,”
International Journal of Computer Applications, vol. 78, no. 1, pp.
30–37, 2013