COMSATS University Islamabad, Islamabad Campus For the Degree of M.S.

Name of Student Taimoor Hassan

Department Department of Computer Science
Registration No. Date of Thesis
February 7, 2019
FA15-RSE-021 Registration
Name of Research
Supervisor
Dr. Shahid Hussain
Research Area Software Engineering
Members of Supervisory Committee
1
2
3
4
Title of Research Predicting the probability of change to measure ripple effect
Proposal

Signature of Student:
Summary of the Research
Change Impact analysis is one of the major issues in software engineering. Change in one
part or module of the modular system will have an impact on the other parts of the system
as well as it propagates. This change propagation is known as ripple effect. Due to the
ripple effect, the stability of the class is highly challenged. Many researchers have studied
the ripple effect measures by doing different changes in the modules and introduced new
metrics to better analyze class stability. REM (Ripple Effect Measure) metric is used to
evaluate the aforesaid probability of change impact in other classes when the parent class
is modified on the basis of attributes and methods it has. However, metrics which measure
the ripple effect on multiple inheritance (interfaces) and depth of level of inheritance
(multilevel inheritance) is still under discussion. Therefore, the current study aims to
introduce a new metric which will not only consider the depth of level of inheritance but
also multiple inheritance and aggregation to check the stability of the class. The
methodology adopted to carry out the research will be two-fold. One is theoretical and
other is empirical. To cross-validate the existing research, a tool is built. Both theoretical
and empirical validations will be performed on the basis of the existing validation criteria
to prove the conceptual model. Furthermore, for empirical validation, a case study for
open source Java classes will be conducted to verify the proposed conceptual model.
1 Introduction
Classes in object Oriented systems makes the basis of software architecture, hence, classes
in OO systems must be dealt with stability for the maintenance of a stable architecture [1].
Changes made to one class have an effect on the other classes too which cause the ripple
effect [2]. The primary attribute affecting the stability of the program is the ripple effect [3].
One should have the knowledge and understanding of the software components before
making any changes, otherwise, it produces a disastrous effect [4]. Therefore, while making
changes one should have a comprehensive knowledge of functionality structure and behavior
of the software system. However, identification of such changes is very difficult as these
modifications will cause ripple effect in other modules. Hence, calculation of class stability
by taking issues, for example, multiple inheritance (due to which changes propagate to other
class) before and after modifications is necessary to avoid problems of maintenance of
software [5].
For the evaluation of stability, three approaches are available [1]. According to the first
approach, stability inhibits changes to the system. The second approach defines that system
is stable if it avoids ripple effects by the addition of a new module or by bringing changes to
existing ones. The last but not least approach of stability, states that the addition of the new
modules in the prevailing systems can be added. In this study, the researcher will consider
the second approach and introduce a new metric to calculate ripple effect which will take
into account the measures of dependencies like the depth of level of inheritance and multiple
inheritance.

The chance of a module to adopt changes in the future is affected not only by the prospect
of altering the module itself but by possible modifications in other modules that might ripple
to it [6]. Along these lines, it very well may be derived that the change engendering for the
most part comprises of two factors: the interior likelihood to change (i.e., due to changes in
requirements or bug fixing, the probability of change in a module) and the outer likelihood
to change, which relates to the likelihood of a module to change because of expansive
influences (i.e., changes propagating from other modules). In this examination, we will
consider the outer likelihood to change that estimates the change proliferation based on the
conditions (that is numerous legacy and total) with different classes that can cause the
likelihood of a change being undulated starting with one class then onto the next class (i.e.
ripple effect).

Coupling metrics have been empirically investigated by many scholars to measure the ripple
effect which is the cause of instability in class [2][7][8][9]. There are two types of metrics to
check the stability of the class: traditional metrics and object-oriented metrics [10].
Traditional metrics are Cyclomatic Complexity, size, comment percentage etc [11].
Chidamber and Kemerer have proposed a metrics suite for object-oriented design that
includes depth of Inheritance (DIT) as well asWeighted Methods per Class (WMC). The
other metrics include Number of Children (NOC)and the important one is Coupling Between
Object classes (CBO). Response For a Class (RFC), Lack of Cohesion in Methods (LCOM)
were also a part of metrics [12].
The research objective is as follows:
Research Objective 1:
To determine the impact of multiple inheritance, multilevel inheritance and aggregation
simultaneously on class stability on design level
Research Objective 2:
To propose a new metric for class stability.
The current research will contribute towards the researchers and practitioners in the
following ways:
• IREM metric will be the optimal available assessor for evaluating change impact.
• The study will help researchers to transform IREM to assess the probability of
changes to propagate across components to fit architecture evaluation purposes.
• The study will provide a tool for ripple effect measure (IREM) which will further
help practitioners to measure the change impact in their software modules.

2 Related Work
Change proneness and class stability have gained the attention of many researchers and
practitioners in recent years. They have given paramount importance to change impact
analysis due to ripple effect which is the threat to the stability of class. Ripple effect is
differently measured by researchers. Logical stability of the object-oriented design is studied
and I was stated that if the stability of the design is poor then it had a bad impact on the
modifications and maintenance of the software modules [2]. It was also concluded that
stability in software design is a very important feature. That is why, to diagnose difficult
modification situations at an early stage that may occur during maintenance, the available
status of a verified set to check logical stability metrics for object-oriented designs is
important.
Many coupling metrics were introduced to check the effects of change propagation
caused due to different dependencies between classes in the object-oriented paradigm. The
quantification of ripple effect is done by Arvanitou et al. in their research and they introduced
as new coupling metric ripple effect measure (REM) to measure the change-proneness. They
have done both theoretical and empirical validation of this metric. The new metric is proved
to be mathematically sound and can be used to assess class proneness to ripple effect,
however, it does not consider the multiple inheritance and friend class issues [6]. They have
conducted another study related to change-proneness and investigated the GoF design pattern
on class stability. Authors have found that classes that in object-oriented way, the Aggregate
role player classes are in lower for stability than classes that play the Component role.
Inheritance in object oriented system has instinct that public superclasses are higher in
stability than Subclasses [13]. Furthermore, Arvanitou et al. extended their research and
measure the change proneness on the architecture level and introduced a new metric Module
Change Proneness Measure (MCPM). The strategy takes contributions from two sources: (a)
module conditions, which are utilized to figure the bit of the open interface of a module that
is utilized by different modules, and (b) module change history, which is utilized as an
intermediary of how much of the time support activities are performed (e.g., alter necessities,
fix bugs, and so on.). In the wake of measuring these two parameters (for all modules and
for every one of their conditions), MCPM can be determined at the design level, by utilizing
basic likelihood hypothesis [14]. Their condition to ascertain the progressively outstretching
influence are given in table 1. One of the specialists has created coupling, insecurity and
relevancy measurements dependent on Martin's standards for practicality and testability.
These measurements incorporate Duty Calculation (InRank), Dependence Calculation
(OutRank), double positioning flimsiness. Results demonstrate that bundles with lower
recently created coupling and dynamics measurements esteems have preferable viability
over those with higher recently created coupling and relevancy measurements esteems [15].
There are numerous other coupling measurements are proposed in various
investigates[16][17][18].

Table 1: Literature Review

Reference Equation Metrics Quality attribute

4.1 [6] 4.2 REM DEPENDENCY= 4.4 NDMC: 4.7 Reliability
No of various
4.3 NDMC+
function calls
NOP+NPrA/NOM+NA
from the needy
class to the
source class (in
addition,
superclass
function calls
for speculation)
NOP: No of
polymorphic
functions in the
source class
(legitimate just
for speculation)
NPrA: No of
secured
qualities in the
source class
(substantial just
for speculation
or companion
classes)
4.5 NOM:
No of
polymorphic
functions in the
source class
4.6 NA:
number of
properties in
the source
class.
4.8 [13 4.9 REM DEPENDENCY= 4.11 NDMC: 4.14 Maintainabilit
] No of various y
4.10 NDMC+
function calls
NOP+NPrA/NOM+NA
from the needy
class to the
source class (in
addition,
superclass
function calls
for speculation)
 NOP: No of
polymorphic
functions in the
source class
(legitimate just
for speculation)
NPrA: No of
secured
qualities in the
source class
(substantial just
for speculation
or companion
classes)
4.12 NOM:
number of
polymorphic
functions in the
source class
4.13 NA:
number of
properties in
the source
class.
[14] REM(B→A)= NDMC: Reliability
𝑖<𝑑𝑒𝑝𝑒𝑛𝑑𝑒𝑛𝑐𝑖𝑒𝑠(𝐴→𝐵)
∑𝑖=0 𝑁𝑃𝑟𝐴(𝐵𝑖) + number of
𝑁𝐷𝑀𝐶(𝐴𝑖→𝐵𝑖) direct function
𝑁𝑂𝑃(𝐵𝑖) + 𝑁𝑂𝑀(𝐵𝑖) +
calls
𝑁𝑂𝐴(𝐵𝑖) NOM: number
of functions
NOA: number
of attributes
NPrA: number
of protected
instance
variables
NOP: number
of polymorphic
functions
[1] StabilityCLASS = StabclassAL:Class -
StabClassAL + StabInterface + StabInhr access-level
+ StabMthd + StabVar + StabvarAL + Stabinterface :
StabMthdAL+StabBody / Class interface
propertiesCLASS name
StabInhr:Inherite
d class name
StabVar:Class
variable
 StabvarAL:Class
variable access-
level:
Method
signature
StabMthdAL:
Method access-
level
StabBody:
Method body

3 Problem statement
In literature, class stability and the ripple effect in the object-oriented paradigm are
studied in many different ways by the research community. Although, they have empirically
investigated certain metrics to calculate the stability of class. The most widely used stability
assessor are depth of inheritance level of tree (DIT) [2], coupling between objects (CBO)
[18][8], Ripple effect measure (REM) [6][13], module change proneness measure these
issues (MCPC) [14] to analyze the ripple effect. However, these metrics are not able to
compute the effect of Depth of level of inheritance, multiple inheritance, and aggregation for
multiple classes which are necessary to compute the quality of software. DIT will help to
measure the dependency of classes on the level of depth of level of inheritance [2][19].
The stability parameters with stability assessor are given in table 1. The table indicates
that still there is no stability assessor which used these parameters to calculate the stability
of a class. Therefore, the current study aims to enhance the existing work limitations by
introducing a newly improved coupling metric to calculate the probability of change
proneness in modules at a deeper level that is calculating class stability while assessing it on
parameters based on the depth of level of inheritance, multiple inheritance, and aggregation
issues.

Table 2: Comparison of Coupling metrics

Abbrv. Parameters for class stability DIT CBO REM

NPrA No of protected attributes X X √

NOP No of polymorphic functions X X √

DIT Level of inheritance √ X X
MI Multiple inheritance X X X
NOAC No of Aggregation classes X X X
NDMC No of distinct function call X X √
NOM No of functions X X √
NA No of attributes X X √

5 Proposed Methodology
The methodology we are adopting to conduct the study is shown in Figure 1.

Literature Literature
Dataset Proposed
Review Problem Review of Conceptual Theoratical Empirical
related to
creation and new metric
Identification metrics and Model Validation Validation
ripple effect tool building IREM
dataset

Figure 1: Proposed Methodology

4.1 Conceptual Model:
Change propagation from one class to another class is caused due to the concept of
dependencies in the object-oriented paradigm. In this study, we are considering three
dependent relationships that is the depth of level of inheritance, multiple inheritance, and
aggregation. To further illustrate the concept, consider a simple class diagram shown in
Figure 2. There are eight classes in the diagram including two friend classes and two
interfaces. Source class is inherited from Parent class which again inherited from
GarndParent2 and GrandParent 2 is inherited from GrandParent1. Source class is overriding
the function m2() which actually belongs to from Grandparent1. Source class is also
implementing the interface1 and interface2 and their method are being called in source class.
Two friend classes are associated with source class and calling its functions. Now
considering Figure 2, take the example scenario for multiple inheritance, Multilevel
inheritance, and aggregation. SourceClass is child or subclass of ParentClass. ParentClass is
a subclass of GrandParent2 and GrandParent2 is a child class of GrandParent1. These
relations exhibit the concept of multilevel inheritance. Now the change in the GrandParent1
function m2() will cause the ripple effect as it propagates the changes to all the derived
classes of the module. Therefore, the depth of the level of level of inheritance is a major
concern while measuring the ripple effect. Various Inheritance alludes to the idea of one
class broadening (Or acquires) more than one base class. The issue with "numerous legacy"
is that the determined class should deal with the reliance on at least two base classes. Java
classes have a special case. It implements the multiple inheritance using interfaces that are
in the given figure 2 Source Class depends on the interface of the associated with it. Any
changes in the source class will propagate to the associated interface. The concept of friend
function is not new in the classes. Friend functions use the aggregation relationship with the
source class. In figure 2, there are two friend classes which are associated with the source
class and if any change occurred in Friend1 or Friend2 class than Source class will be
affected because aggregated objects exist in Source class. Therefore, the calculation of the
improved ripple effect measure will be considering all these dependencies to provide a better
measure.
 Figure 1: Conceptual Model
For the above conceptual model, researcher make the equation to calculate the proposed
metric. In REM propagation factor was calculated in terms of five factors introduced for
measuring dependency between the two classes on the basis of single inheritance and
aggregation [21].
A refers to source class where B refers to the dependent class, then these factors include:
NDMC: No of distinct functions calls from B class to A class
NOP: No of polymorphic functions
NPrA: No of protected attributes in A
NOM: No of functions in A
NA: No of attributes in A.

Multilevel inheritance (Depth of Inheritance):

As all of these factors are included in the scenario depicted in figure 1, hence REM will
behave as a single factor. The scenario includes multilevel inheritance which was neglected
in finding REM factor. The multilevel inheritance has a shape of 4 classes in the hierarchy
as shown in figure 1.
Stability factor for multilevel inheritance
As it is a multilevel inheritance, hence there is always a hierarchy running down to source
class.
Hence, a combined effect of all the classes should be achieved as a propagating factor to
source class. Iteratively, the formula takes the following form.
 𝑛

𝑆𝐹𝑚𝑙 = ∑ [(𝑆𝐹𝑚𝑙 (𝑅𝐸𝑀(𝐶𝑙𝑎𝑠𝑠 𝑖) ∩ (𝐶𝑙𝑎𝑠𝑠 𝑛))])

𝑖=1
Where Class i will be the source class initially and Class j will be the topmost hierarchical
class. The two classes will intersect at common attributes and methods if any.
Multiple inheritance:
In REM [6] as multiple inheritances were totally neglected, however, in java multiple
inheritance is achieved via abstraction through interfaces which is among the main pillar of
object-oriented design. Again, considering the multiple inheritance scenarios via interfaces
in figure 1, it is noticed that these are the only methods that are needed to be addressed as
only methods are responsible to propagate change in source class. Two interfaces (Interface
1 and Interface 2) have one method each which are needed to be implemented in the source
class. The change in the method will produce a ripple effect, hence needs to be measured.
Stability factor for interfaces.
As interfaces will not have protected attributes. The parameter that can propagate change is
only the methods.
Hence,

NDMC+NOP
SFi = ( eq. 1)
NOM

Where NDMC = Number of distinct methods changed in the interface. Thus, if there are
more than two interfaces, the combined effect of both will be determined as follow:
𝑃 (𝐼1 𝑈 𝐼2) = 𝑃(𝐼1) + 𝑃(𝐼2) − 𝑃(𝐼1 ∩ 𝐼2) (𝑒𝑞. 2)

This is the joint probability of changes due to the two interfaces’ methods.
Assuming that a change in interface I1 will occur with a probability of 0.5 (P(I1) = 0.5) and
that this change will propagate to class Source with a probability of 0.5 (P(I1|I2) = 0.5), then:
P (I1| I2) = P (I1) + P (I2) – P (I1). P (I2)
= 0.5 + 0.5 – 0.5 x 0.5 = 0.75

4.2 Validation Process:

In this study, metric validation will be performed in two steps that are theoretical and
empirical validation as performed by many researchers to validate their metric [20][21].
Theoretical validation will answer our RO1 which is related to the map metrics on certain
defined criteria. This will include properties like
• Normalization & Non-Negativity
• Null Value & Maximum Value
• Monotonicity
• Merging of Classes
Empirical validation will answer our RO2 questions which aim to investigate the accuracy
of IREM with the corresponding quality factor. To empirically validate the proposed metric,
the researcher will be conducting case studies on two open source Java projects:
• JFlex
• JMol
• HTML Parser
 • QuickFIX/J
In these projects’ classes will be considered as cases therefore in this context the study will
be performed on Java classes. This will be tried utilizing 1061 IEEE Standard for Software
Quality Metrics which will incorporate
• Correlation
• Consistency
• Tracking
• Discriminating Power
and quality attributes that are:
• Reliability
• Maintainability

5 Conclusion:
The research aims to study the stability of class by introducing a new ripple effect metric.
Although, there are many existing coupling metrics which measure the ripple effect and are
empirically investigated by researchers, however, researchers remain ignorant about the
inclusion of issues of dependencies that are multiple inheritance, depth of level of inheritance
and aggregation in their measures to calculate the class stability. Current research will
include all these types of dependencies to calculate an improved version of the ripple effect
measure and also built the tool as a contribution to the research.

6 References:

[1] M. Alshayeb, M. Naji, M. O. Elish, and J. Al-Ghamdi, “Towards measuring object-

oriented class stability,” IET Softw., vol. 5, no. 4, p. 415, 2011.
[2] M. O. Elish and D. Rine, “Investigation of metrics for object-oriented design logical
stability,” Proc. Eur. Conf. Softw. Maint. Reengineering, CSMR, pp. 193–200, 2003.
[3] S. S. Yau and J. S. Collofello, “Design Stability Measures for Software Maintenance,”
IEEE Trans. Softw. Eng., vol. SE-11, no. 9, pp. 849–856, 1985.
[4] C. Gupta, M. Srivastav, and V. Gupta, “Software change impact analysis: an approach
to differentiate type of change to minimise regression test selection,” Int. J. Comput.
Appl. Technol., vol. 51, no. 4, p. 366, 2015.
[5] A. Baqais, M. Amro, and M. Alshayeb, “Analysis of the correlation between class
stability and maintainability,” Proc. - CSIT 2016 2016 7th Int. Conf. Comput. Sci. Inf.
Technol., pp. 1–4, 2016.
[6] E. Arvanitou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou, “Introducing a
Ripple Effect Measure : A Theoretical and Empirical Validation,” 2015 ACM/IEEE
Int. Symp. Empir. Softw. Eng. Meas., pp. 1–10, 2015.
[7] J. Al Dallal, “Object-oriented class maintainability prediction using internal quality
attributes,” Inf. Softw. Technol., vol. 55, no. 11, pp. 2028–2048, 2013.
[8] M. Child, P. Rosner, and S. Counsell, “A Comparison and Evaluation of Variants in
the Coupling Between Objects Metric,” J. Syst. Softw., vol. 151, pp. 120–132, 2019.
[9] E. Tempero and P. Ralph, “Science of Computer Programming A framework for
defining coupling metrics,” Sci. Comput. Program., vol. 166, pp. 214–230, 2018.
[10] N. Padhy and R. P. Singh, “State-of-the-Art Object-Oriented Metrics and Its
Reusability : A Decade State-of-the-Art Object-Oriented Metrics and Its Reusability :
A Decade Review,” no. January, 2018.
[11] Y. Suresh, J. Pati, and S. K. Rath, “Effectiveness of Software Metrics for Object-
oriented System,” Procedia Technol., vol. 6, pp. 420–427, 2012.
[12] C. F. Kemerer, “Kemerer , C . F .: A metric suite for object-oriented design . IEEE
 Trans . Softw . Eng .,” vol. 20, no. July 1994, pp. 476–493, 2015.
[13] A. Ampatzoglou, A. Chatzigeorgiou, S. Charalampidou, P. Avgeriou, and S. Member,
“The Effect of GoF Design Patterns on Stability : A Case Study,” IEEE Trans. Softw.
Eng., vol. 41, no. 8, pp. 781–802, 2015.
[14] E. M. Arvanitou, A. Ampatzoglou, K. Tzouvalidis, A. Chatzigeorgiou, P. Avgeriou,
and I. Deligiannis, “Assessing change proneness at the architecture level: An
empirical validation,” Proc. - 2017 24th Asia-Pacific Softw. Eng. Conf. Work.
APSECW 2017, vol. 2018–Janua, pp. 98–105, 2018.
[15] S. Almugrin, W. Albattah, and A. Melton, “The Journal of Systems and Software
Using indirect coupling metrics to predict package maintainability and testability,” J.
Syst. Softw., vol. 121, pp. 298–310, 2016.
[16] S. A. Ebad and M. A. Ahmed, “Measuring stability of object-oriented software
architectures,” IET Softw., vol. 9, no. August 2014, pp. 76–82, 2015.
[17] Y. Suresh, J. Pati, and S. K. Rath, “Effectiveness of software metrics for object-
oriented system,” vol. 6, pp. 420–427, 2012.
[18] M. Child, P. Rosner, and S. Counsell, “The Journal of Systems and Software A
comparison and evaluation of variants in the coupling between objects metric,” J. Syst.
Softw., vol. 151, pp. 120–132, 2019.
[19] E. Arvanitou, A. Ampatzoglou, and A. Chatzigeorgiou, “Software metrics
fluctuation : a property for assisting the metric selection process,” vol. 72, pp. 110–
124, 2016.
[20] L. Kumar, D. K. Naik, and S. K. Rath, “Validating the Effectiveness of Object-
Oriented Metrics for Predicting Maintainability,” Procedia Comput. Sci., vol. 57, pp.
798–806, 2015.
[21] E. M. Arvanitou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou, “Introducing
a Ripple Effect Measure: A Theoretical and Empirical Validation,” Int. Symp. Empir.
Softw. Eng. Meas., vol. 2015–Novem, pp. 192–201, 2015.