# The Impact of the Object-Oriented Software Evolution on Software Metrics: The Iris Approach

Ra'Fat Al-Msie'Deen, Anas H. Blasi

► To cite this version:

Ra'Fat Al-Msie'Deen, Anas H. Blasi. The Impact of the Object-Oriented Software Evolution on Software Metrics: The Iris Approach. Indian Journal of Science and Technology, 2018, 11 (8), pp.1-8.
10.17485/ijst/2018/v11i8/121148. hal-04917789

HAL Id: hal-04917789

https://hal.science/hal-04917789v1

Submitted on 5 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# The Impact of the Object-Oriented Software Evolution on Software Metrics: The Iris Approach

Ra'Fat Al-Msie'deen* and Anas H. Blasi

Department of IT, Faculty of Information Technology, Mutah University, P.O. Box 7, Mutah 61710, Karak, Jordan;
rafatalmsiedeen@mutah.edu.jo, Ablasi1@mutah.edu.jo

## Abstract

The Object-Oriented (OO) software system evolves over the time to meet the new requirements. Based on the initial release of software, the continuous modification of software code leads to software evolution. Software needs to evolve over the time to meet the new user's requirements. Software companies often develop variant software of the original one depends on customers' needs. The main hypothesis of this paper states that the software when it evolves over the time, its code continues to grow, change and become more complex. This paper proposes an automatic approach (Iris) to examine the proposed hypothesis. Originality of this approach is the exploiting of the software variants to study the impact of software evolution on the software metrics. This paper presents the results of experiments conducted on three releases of drawing shapes software, sixteen releases of rhino software, eight releases of mobile media software and ten releases of ArgoUML software. Based on the extracted software metrics, It has been found that Iris hypothesis is supported by the computed metrics.

**Keywords:** Object-Oriented Software, Software Variants, Reverse Engineering, Software Engineering, Software Evolution, Software Metrics, Software Complexity.

## 1. Introduction

Object-Oriented (OO) software systems need enhancement to be used for long time¹. Lehman's laws² of software evolution show that continuous modification and development is essential to keep the software system for a long time. Moreover, Lehman has proposed that over the time, due to evolution, software system becomes complex and hard to add new features on it. The software metrics are affected by software evolution over the time³. In real world, software evolution could be an outcome of software maintenance⁴. This paper proposes a novel method called Iris to investigate the impact of the OO software evolution on software metrics. Iris stands for Impact of the object-oriented software evolution on Software metrics.

Lehman's laws state that during software evolution, due to growth and changes, software product becomes

more complex². The main objective of current approaches was to investigate the applicability of Lehman's laws of software evolution on software products using different metrics³, ⁴. Iris states that during software evolution, software code becomes more complex and it continues to change and grow. Iris suggests new metrics to measure software growth and complexity.

The main hypothesis of this work is that, if the software system evolves over the time, the software source code becomes more complex and it may continue to grow and change. In addition, to investigate the impact of software evolution related to the code complexity and its continuous growth and change, this paper suggests using the software metrics⁵ (aka measurements) to measure this hypothesis. Iris approach has computed the OO software metrics for several software variants. The computed metrics value for different versions has used as basis for examining the Iris hypothesis.

<footnote>*Author for correspondence</footnote>
Comparing with the *related work*, most of current approaches have designed to measure the software metrics in a single software system². Moreover, there are other studies have similar approaches like what have been done in this paper³,⁴. A new suggestion that has proposed in this paper is a new software metrics that measures a software growth and complexity. In order to measure the software complexity, this paper has proposed three metrics: number of inheritance relations, number of attribute accesses and number of method invocations. To measure the growth of a software code, Iris has suggested a new metrics such as, number of identifiers, and number of public methods.

Johari and Kaur² proposed an approach to study the effect of software evolution on software metrics. Their study has analyzed different releases of two open source software systems (JHotDraw and Rhino) developed in Java and released via evolution processes. The key objective of the research was to examine the applicability of Lehman laws on software variants. However, Iris does not examine Lehman's laws; it is suggesting a new metrics to measure software complexity and presenting new metrics to measure software growth and change.

Kaur et al.⁴ suggest a new method that study the applicability of Lehman laws on different releases of two software developed using C++. In their work, an experiment has been conducted on ten versions of flight gear simulator and graphics layout engine evolved over the period of eight years. Based on the extracted metrics, the laws of continuous change, growth and complexity were found applicable according to the metrics collected.

Israeli and Feitelson⁶ examined the Lehman's laws in the Linux kernel. Linux kernel versions released over a period of fourteen years. Linux kernel includes 810 releases. Lehman's laws include eight laws. All laws have

supported in their experiment except self-regulation and feedback system. Iris does not examine the Lehman's laws but examines the complexity, growth and change of software code during its evolution.

The current methods are designed to examine the applicability of Lehman laws on different releases of software systems. Iris studies the impact of software evolution on software metrics in a collection of software variants. During software evolution, software code becomes complex and it may continue to grow and change. However, Iris proves this hypothesis via new metrics.

The rest of the paper is organized as: section 2 shows an overview of Iris approach. Section 3 presents software metrics mining process step-by-step. Section 4 describes the experiments were conducted to validate Iris hypothesis. Finally, section 5 concludes and provides perspectives for this work.

## 2. Approach Overview

This section gives an overview of the Iris approach. It also presents software metrics used in the Iris approach and describes the toy example that illustrates the remaining of the paper.

### 2.1 Approach basics

The general objective of Iris is to study the impact of software evolution on the software metrics. Iris hypothesis states that the software during its evolution its code continues to grow, changes and becomes more complex. Iris approach proves this hypothesis via new software metrics. Iris exploits the software identifiers (i.e., package, class, attribute and method) and the main code dependencies between those identifiers (i.e., inheritance relation, method invocation and attribute access) to extract soft-

<figure><img src="image_2.png" /><figcaption>**Figure 1.** The software metrics mining process.</figcaption></figure>
ware metrics of a collection of software variants. Iris takes the source code of a collection of software variants as inputs and generates software metrics as output. Figure 1 shows the software metrics mining process.

The first step of the software metrics mining process aims to identifying software identifiers and code dependencies based on the static code analysis². The second step identifies software-by-metric matrix; in which the rows of the matrix correspond to software variants and the columns correspond to software metrics.

## 2.2 Metrics used in Iris approach

This section presents software metrics used in Iris approach. For measuring the software complexity at different level, it has considered inheritance relation⁸ at class level, attribute access and method invocation at method level. For measuring software growth and change, it has considered software identifiers⁹ to study this issue. Iris approach considers software metrics given in Table 1.

<table><caption>**Table 1.** Metrics used in Iris approach.</caption><thead><tr><td>#</td><td>Metric</td><td>Abbreviations</td></tr></thead><tbody><tr><td>1</td><td>Lines of code</td><td>LOC</td></tr><tr><td>2</td><td>Number of packages</td><td>NOP</td></tr><tr><td>3</td><td>Number of classes</td><td>NOC</td></tr><tr><td>4</td><td>Number of interfaces</td><td>NOI</td></tr><tr><td>5</td><td>Number of attributes</td><td>NOA</td></tr><tr><td>6</td><td>Number of methods</td><td>NOM</td></tr><tr><td>7</td><td>Number of local variables</td><td>NOL</td></tr><tr><td>8</td><td>Number of identifiers</td><td>NOID</td></tr><tr><td>9</td><td>Number of public methods</td><td>NOPM</td></tr><tr><td>10</td><td>Number of static methods</td><td>NOSM</td></tr><tr><td>11</td><td>Number of inheritance relations</td><td>NOIR</td></tr><tr><td>12</td><td>Number of attribute accesses</td><td>NOAA</td></tr><tr><td>13</td><td>Number of method invocations</td><td>NOMI</td></tr></tbody></table>

Lines of code metric counts software lines of code, except blank lines and code comments. Inheritance relation happens when a general class (super-class) is connected to its specialized classes (sub-classes). While, attribute access occurs when methods of one class use attributes of another class. Whereas, method invocation occurs when methods of one class use methods of another class¹⁰. Number of identifiers metric counts all software identifiers: packages, classes, attributes and methods.

## 2.3 An Illustrative Example

As a toy example, Iris considers the drawing shapes software¹¹. This software product family was developed by the authors and implemented using Java code. Drawing shapes software allows user to draw several kinds of shapes. Since its original issue in 2014, there have been several official versions so far. Table 2 summarizes changes made in each version of drawing shapes software systems. The scenarios comprise several types of changes involving include or exclude some kinds of shapes.

<table><caption>**Table 2.** Summary of evolution scenarios in drawing shapes software variants.</caption><thead><tr><td>Releases</td><td>Release description</td></tr></thead><tbody><tr><td>r1</td><td>Draw line, rectangle and oval functionality added.</td></tr><tr><td>r2</td><td>Draw line, 3D rectangle and round rectangle functionality included.</td></tr><tr><td>r3</td><td>Draw line, rectangle, 3D rectangle, round rectangle and oval functionality added.</td></tr></tbody></table>

Iris does not know the software metrics in advance. Drawing shapes software variants used for better explanation of software metrics mining process. We only use the source code of software variants as input of the software metrics mining process. Figure 2 shows the first and second versions of drawing shapes variants that were developed by clone-and-own approach. Figure 2 inspired by Martinez *et al.*¹².

All releases of drawing shapes software are developed by *copy-paste-modify* technique (i.e., clone-and-own approach) based on the initial release¹³. Drawing shapes variants represent a small case study (i.e., third version consists of 448 lines of code).

# 3. Software Metrics Mining Process

This section presents the software metrics mining process step-by-step. According to the proposed approach, Iris identifies the software metrics in two steps as detailed in the following.

## 3.1 Extracting software code

First step of Iris approach aims to extracting the source code of software variants. Moreover, Iris approach used
<figure><img src="image_3.png" /><figcaption>**Figure 2.** Two drawing shapes software variants developed by using clone-and-own approach.</figcaption></figure>

only the source code of software variants as inputs of the software metrics mining process. Also Iris extracts the source code of each software variant based on the static code analysis¹⁴. Iris code parser used to access and read the source code of software systems. Iris code parser identifies all software identifiers in addition to source code dependencies. The outputs of this step are a collection of software code files. Iris relies on the extracted code files to identify the software metrics.

## 3.2 Identifying software metrics

The second step of software metrics mining process aims to identifying the software metrics. This step accepts the code files and generates software metrics as output. Table 3 summarizes the obtained results for each drawing shapes software variant.

The initial version of drawing shapes software consists 386 lines of code and the newest version consists 448 lines of code (cf. Table 3). The size in terms of code lines has increased from the initial version to the latest version.

<table><caption>**Table 3.** Software metrics mined from drawing shapes software variants.</caption><thead><tr><th>Versions</th><th>Version date</th><th>LOC</th><th>NOP</th><th>NOC</th><th>NOA</th><th>NOM</th><th>NOID</th><th>NOI</th><th>NOIR</th><th>NOPM</th><th>NOSM</th><th>NOAA</th><th>NOMI</th></tr></thead><tbody><tr><td>Drawing shapes r1</td><td>3/8/2014</td><td>386</td><td>4</td><td>6</td><td>16</td><td>29</td><td>55</td><td>0</td><td>5</td><td>1</td><td>26</td><td>125</td><td>99</td></tr><tr><td>Drawing shapes r2</td><td>4/5/2016</td><td>374</td><td>4</td><td>6</td><td>16</td><td>29</td><td>55</td><td>0</td><td>5</td><td>1</td><td>26</td><td>125</td><td>99</td></tr><tr><td>Drawing shapes r3</td><td>1/2/2018</td><td>448</td><td>4</td><td>8</td><td>16</td><td>33</td><td>61</td><td>0</td><td>7</td><td>1</td><td>30</td><td>161</td><td>139</td></tr></tbody></table>
<figure><img src="image_4.png" /><figcaption>**Figure 3.** Charts summarize the extracted software metrics from drawing shapes software variants.</figcaption></figure>

According to Iris hypothesis the complexity of software system tends to grow over numerous versions of software due to the software evolution process. Iris considers the main code dependencies as a metric to measure the code complexity. For example, in the newest release of drawing shapes software, the number of method invocations increased to 139. While, the number of inheritance relations increased to 7 and, at last, the number of attribute accesses increased to 161 (cf. Table 3).

The software code growth can be interpreted as an increment in metrics size (e.g., lines of code and number of packages) or increment in the software functionality (e.g., number of classes and methods). Table 3 shows the growth of the size metrics and software functionalities for various versions of drawing shapes software. For example, lines of code increased from 386 to 448 in the newest version of drawing shapes. Also, the number of methods increased from 29 to 33 in the latest release of drawing shapes software. In Figure 3, charts summarize the extracted software metrics from drawing shapes software variants.

It is hard to distinguish between code growth and change. The change of software code can be due to some activities such as: software maintenance or added new functionality to the software. In case of drawing shapes software, version r1 and r2 are absolutely the same in terms of number

of classes and methods, but with different functionalities. Finally, the calculated metrics prove that software code becomes more complex and continues to grow and change during software evolution.

## 4. Experimentation

This section presents the experiments that conducted to validate Iris hypothesis. It also presents the case studies and, at last, it presents the extracted software metrics.

To validate Iris proposal, experiments conducted on four Java open-source software systems: drawing shapes, rhino, mobile media and ArgoUML. The four case studies show different sizes: ArgoUML (large system), rhino (medium system), mobile media (small system) and drawing shapes (small system). The four case studies are well documented as well.

Rhino¹⁵ software is an open-source application of JavaScript written completely in Java. Moreover, Rhino is embedded into Java applications to offer scripting to end users. Since its original issue in 1999, there have been sixteen versions so far. Table 4 presents the mined software metrics of all Rhino software releases using Iris prototype¹⁶.
<table><caption>**Table 4.** Software metrics mined from Rhino software variants.</caption><thead><tr><th>Releases</th><th>Release date</th><th>LOC</th><th>NOP</th><th>NOC</th><th>NOA</th><th>NOM</th><th>NOID</th><th>NOI</th><th>NOIR</th><th>NOPM</th><th>NOSM</th><th>NOAA</th><th>NOMI</th></tr></thead><tbody><tr><td>rhi. 1.4R3</td><td>10/5/1999</td><td>20335</td><td>7</td><td>95</td><td>955</td><td>1156</td><td>2213</td><td>16</td><td>21</td><td>324</td><td>862</td><td>19566</td><td>5031</td></tr><tr><td>rhi. 1.5R1</td><td>10/9/2000</td><td>29495</td><td>10</td><td>137</td><td>1186</td><td>1621</td><td>2954</td><td>16</td><td>33</td><td>455</td><td>1127</td><td>29084</td><td>8708</td></tr><tr><td>rhi. 1.5R2</td><td>27/7/2001</td><td>32060</td><td>7</td><td>131</td><td>1442</td><td>1760</td><td>3340</td><td>18</td><td>45</td><td>418</td><td>1035</td><td>32648</td><td>8945</td></tr><tr><td>rhi. 1.5R3</td><td>27/1/2002</td><td>32421</td><td>8</td><td>130</td><td>1455</td><td>1777</td><td>3370</td><td>17</td><td>45</td><td>426</td><td>1025</td><td>32766</td><td>8932</td></tr><tr><td>rhi. 1.5R4.1</td><td>10/2/2003</td><td>33800</td><td>8</td><td>142</td><td>1474</td><td>1891</td><td>3515</td><td>19</td><td>48</td><td>469</td><td>1011</td><td>35270</td><td>8957</td></tr><tr><td>rhi. 1.5R4</td><td>21/4/2003</td><td>33718</td><td>8</td><td>142</td><td>1472</td><td>1884</td><td>3506</td><td>19</td><td>48</td><td>468</td><td>1007</td><td>35235</td><td>8946</td></tr><tr><td>rhi. 1.5R5</td><td>25/3/2004</td><td>36051</td><td>8</td><td>145</td><td>1532</td><td>1944</td><td>3629</td><td>18</td><td>48</td><td>559</td><td>1023</td><td>36698</td><td>8806</td></tr><tr><td>rhi. 1.6R1</td><td>29/11/2004</td><td>37961</td><td>10</td><td>144</td><td>1621</td><td>2027</td><td>3802</td><td>18</td><td>33</td><td>603</td><td>1054</td><td>37059</td><td>9331</td></tr><tr><td>rhi. 1.6R2</td><td>19/9/2005</td><td>37771</td><td>12</td><td>141</td><td>1662</td><td>2021</td><td>3836</td><td>18</td><td>30</td><td>603</td><td>1027</td><td>36748</td><td>9215</td></tr><tr><td>rhi. 1.6R3</td><td>24/7/2006</td><td>37946</td><td>12</td><td>141</td><td>1672</td><td>2032</td><td>3857</td><td>18</td><td>30</td><td>606</td><td>1033</td><td>36947</td><td>9244</td></tr><tr><td>rhi. 1.6R4</td><td>10/9/2006</td><td>37960</td><td>12</td><td>141</td><td>1672</td><td>2033</td><td>3858</td><td>18</td><td>30</td><td>606</td><td>1033</td><td>36961</td><td>9250</td></tr><tr><td>rhi. 1.6R5</td><td>19/11/2006</td><td>37960</td><td>12</td><td>141</td><td>1672</td><td>2033</td><td>3858</td><td>18</td><td>30</td><td>606</td><td>1033</td><td>36961</td><td>9250</td></tr><tr><td>rhi. 1.6R6</td><td>30/7/2007</td><td>39914</td><td>13</td><td>152</td><td>1723</td><td>2124</td><td>4012</td><td>19</td><td>34</td><td>630</td><td>1077</td><td>38828</td><td>9777</td></tr><tr><td>rhi. 1.6R7</td><td>20/8/2007</td><td>39930</td><td>13</td><td>152</td><td>1723</td><td>2125</td><td>4013</td><td>19</td><td>34</td><td>630</td><td>1078</td><td>38837</td><td>9785</td></tr><tr><td>rhi. 1.7R1</td><td>6/3/2008</td><td>42830</td><td>13</td><td>165</td><td>1841</td><td>2270</td><td>4289</td><td>20</td><td>36</td><td>659</td><td>1151</td><td>41882</td><td>10718</td></tr><tr><td>rhi. 1.7R2</td><td>22/3/2009</td><td>43425</td><td>11</td><td>167</td><td>1854</td><td>2301</td><td>4333</td><td>21</td><td>36</td><td>669</td><td>1176</td><td>42227</td><td>10763</td></tr></tbody></table>

Mobile media¹⁷ application is Java-based open source software that manipulates image, music and video on mobile phones. Since its original issue was in 2007, there have been eight official versions so far. Mobile media application has been built as a software product line in eight versions. Figueiredo et al.¹⁸ summarize the evolution (aka changes made) in each release. Table 5 presents the mined software metrics from mobile media software variants.

ArgoUML¹⁹ software is a Java-based application. It is open source software and used for designing systems in the unified modelling language. The original ArgoUML software consists of nine features (aka functionalities) such as: class diagram. Since its initial version was in 2010, there have been several releases so far. Couto et al.²⁰ summarizes the evolution scenarios in ArgoUML software variants. The scenarios comprise several types of changes involving disable and enable some features. Table 6 presents the mined software metrics from ArgoUML software variants. Iris performed an evaluation of the execution time (in ms) of

its algorithm using the ArgoUML software variants. The algorithm execution time is equal to 12843 ms.

The extracted software metrics have proven the Iris hypothesis. During software evolution, therefore, the software code becomes more complex and the software code continues to grow and change.

## 5. Conclusion and future work directions

This paper proposed Iris approach that study the impact of software evolution on software metrics. Furthermore, the hypothesis of this approach stated that the software during the evolution processes, its code continued to grow, changed and became more complex. Iris approach was implemented on numerous case studies. Based on the results obtained, the extracted metrics proved the validity of the Iris hypothesis.
<table><caption>**Table 5.** Software metrics mined from mobile media software variants.</caption><thead><tr><th>Releases</th><th>Release date</th><th>LOC</th><th>NOP</th><th>NOC</th><th>NOA</th><th>NOM</th><th>NOID</th><th>NOI</th><th>NOIR</th><th>NOPM</th><th>NOSM</th><th>NOAA</th><th>NOMI</th></tr></thead><tbody><tr><td>Mobile media r1</td><td>3/9/2007</td><td>760</td><td>10</td><td>16</td><td>56</td><td>92</td><td>174</td><td>1</td><td>8</td><td>0</td><td>84</td><td>631</td><td>299</td></tr><tr><td>Mobile media r2</td><td>3/9/2007</td><td>1050</td><td>15</td><td>25</td><td>62</td><td>124</td><td>226</td><td>1</td><td>17</td><td>0</td><td>116</td><td>731</td><td>347</td></tr><tr><td>Mobile media r3</td><td>3/9/2007</td><td>1197</td><td>15</td><td>26</td><td>71</td><td>140</td><td>252</td><td>1</td><td>17</td><td>0</td><td>129</td><td>842</td><td>415</td></tr><tr><td>Mobile media r4</td><td>3/9/2007</td><td>1246</td><td>15</td><td>26</td><td>74</td><td>143</td><td>258</td><td>1</td><td>17</td><td>0</td><td>132</td><td>898</td><td>446</td></tr><tr><td>Mobile media r5</td><td>3/9/2007</td><td>1387</td><td>15</td><td>31</td><td>75</td><td>160</td><td>281</td><td>1</td><td>22</td><td>1</td><td>147</td><td>922</td><td>585</td></tr><tr><td>Mobile media r6</td><td>3/9/2007</td><td>1823</td><td>17</td><td>38</td><td>106</td><td>200</td><td>361</td><td>1</td><td>26</td><td>1</td><td>187</td><td>1246</td><td>781</td></tr><tr><td>Mobile media r7</td><td>3/9/2007</td><td>2214</td><td>17</td><td>47</td><td>133</td><td>239</td><td>436</td><td>1</td><td>35</td><td>1</td><td>212</td><td>1530</td><td>959</td></tr><tr><td>Mobile media r8</td><td>3/9/2007</td><td>2645</td><td>17</td><td>51</td><td>166</td><td>271</td><td>505</td><td>1</td><td>39</td><td>1</td><td>247</td><td>1790</td><td>1200</td></tr></tbody></table>

<table><caption>**Table 6.** Software metrics mined from ArgoUML software variants.</caption><thead><tr><th>Releases</th><th>Release date</th><th>LOC</th><th>NOP</th><th>NOC</th><th>NOA</th><th>NOM</th><th>NOID</th><th>NOI</th><th>NOIR</th><th>NOPM</th><th>NOSM</th><th>NOAA</th><th>NOMI</th></tr></thead><tbody><tr><td>Ar1</td><td>4/6/2010</td><td>120348</td><td>90</td><td>1939</td><td>3977</td><td>14904</td><td>20910</td><td>156</td><td>1402</td><td>654</td><td>11518</td><td>75813</td><td>56758</td></tr><tr><td>Ar2</td><td>4/6/2010</td><td>82924</td><td>63</td><td>1510</td><td>2783</td><td>11934</td><td>16290</td><td>150</td><td>1040</td><td>584</td><td>9248</td><td>54771</td><td>40537</td></tr><tr><td>Ar3</td><td>4/6/2010</td><td>118189</td><td>90</td><td>1939</td><td>3716</td><td>14901</td><td>20646</td><td>156</td><td>1402</td><td>653</td><td>11517</td><td>73749</td><td>55330</td></tr><tr><td>Ar4</td><td>4/6/2010</td><td>104029</td><td>77</td><td>1718</td><td>3496</td><td>13567</td><td>18858</td><td>150</td><td>1226</td><td>595</td><td>10308</td><td>67423</td><td>50361</td></tr><tr><td>Ar5</td><td>4/6/2010</td><td>114969</td><td>86</td><td>1881</td><td>3831</td><td>14483</td><td>20281</td><td>156</td><td>1351</td><td>650</td><td>11230</td><td>72517</td><td>54544</td></tr><tr><td>Ar6</td><td>4/6/2010</td><td>117636</td><td>87</td><td>1898</td><td>3906</td><td>14684</td><td>20575</td><td>156</td><td>1363</td><td>653</td><td>11392</td><td>74483</td><td>55421</td></tr><tr><td>Ar7</td><td>4/6/2010</td><td>117201</td><td>88</td><td>1906</td><td>3913</td><td>14667</td><td>20574</td><td>156</td><td>1371</td><td>654</td><td>11351</td><td>74190</td><td>55529</td></tr><tr><td>Ar8</td><td>4/6/2010</td><td>118769</td><td>88</td><td>1920</td><td>3948</td><td>14783</td><td>20739</td><td>156</td><td>1385</td><td>654</td><td>11426</td><td>75050</td><td>56117</td></tr><tr><td>Ar9</td><td>4/6/2010</td><td>116431</td><td>90</td><td>1904</td><td>3861</td><td>14508</td><td>20363</td><td>156</td><td>1371</td><td>652</td><td>11246</td><td>73596</td><td>55146</td></tr><tr><td>Ar10</td><td>4/6/2010</td><td>118066</td><td>89</td><td>1921</td><td>3900</td><td>14710</td><td>20620</td><td>156</td><td>1387</td><td>652</td><td>11397</td><td>74355</td><td>55771</td></tr></tbody></table>

For future work, Iris approach would include more metrics such as coupling between classes. Moreover, Iris approach would study more open source software systems. Also, Iris plans to exploit formal concept analysis²¹ to show the impact of software evolution on software metric values using the AOC-poset²². Iris will use formal concept analysis to identify the common metric values (i.e., no changes made) and different metric values (i.e., changes made) across software variants. For example, in the drawing shapes software, all variants have the same number of packages and different lines of code.

## 6. References

1. Drouin N, Badri M, Touré F. Analyzing Software Quality Evolution using Metrics: An Empirical Study on Open Source Software. Journal of software. 2013; 8(10): 2462-2473.

2. Lehman M. Laws of Software Evolution Revisited. In: proceedings of the 5th European Workshop on Software Process Technology. Springer-Verlag; 1996. P. 108-124.

3. Johari K, Kaur A. Effect of Software Evolution on Software Metrics: An Open Source Case Study. ACM SIGSOFT Software Engineering Notes. 2011; 36(5): 0163-5948.

4. Kaur T, Ratti N, Kaur P. Applicability of Lehman Laws on Open Source Evolution: A Case study. International Journal of Computer Applications. 2014; 93(18): 0975-8887.
5. Chidamber S, Chris K. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering. 1994; 20(6): 476-493.

6. Israeli A, Feitelson G. The Linux Kernel as a Case Study in Software Evolution. Journal of Systems and Software. 2010; 83(3): 485-501.

7. Al-Msie'deen R. Visualizing object-oriented software for understanding and documentation. International Journal of Computer Science and Information Security. 2015; 13(5): 18-27.

8. Al-Msie'deen R, Seriai A, Huchard M, Urtado C, Vauttier S. Mining features from the object-oriented source code of software variants by combining lexical and structural similarity. In: proceedings of the IEEE 14th International Conference on Information Reuse & Integration. IEEE Computer Society; 2013. P. 586-593.

9. Al-Msie'deen R. Automatic labeling of the object-oriented source code: The Lotus Approach. Science International-Lahore "Sci.Int.(Lahore)". 2018; 30(1): 45-48.

10. Al-Msie'deen R. Reverse Engineering Feature Models from Software Variants to Build Software Product Lines: REVPLINE Approach [PhD thesis]. University of Montpellier 2; 2014.

11. Drawing shapes software variants: https://sites.google.com/site/ralmsideen/tools

12. Martinez J, Ziadi T, Bissyandé T, Klein J, Traon Y. Automating the Extraction of Model-Based Software Product Lines from Model Variants. In: proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering. IEEE; 2015. P. 396-406.

13. Al-Msie'deen R, Seriai A, Huchard M. Reengineering Software Product Variants into Software Product Line: REVPLINE Approach. LAP LAMBERT Academic Publishing; 2014.

14. Al-Msie'deen R, Seriai A, Huchard M, Urtado C, Vauttier S, Eyal Salman H. Feature Location in a Collection of Software Product Variants Using Formal Concept Analysis. In: proceedings of the Safe and Secure Software Reuse - 13th International Conference on Software Reuse. Springer; 2013. P. 302-307.

15. Rhino home page: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino

16. Iris prototype: https://sites.google.com/site/ralmsideen/tools

17. Mobile media home page: http://homepages.dcc.ufmg.br/~figueiredo/spl/icse08/

18. Figueiredo E, Cacho N, Sant'Anna C, Monteiro Mario, Kulesza U, Garcia A, Soares S, Ferrari F, Khan S, Filho F, Dantas F. Evolving software product lines with aspects: an empirical study on design stability. In: proceedings of the 30th International Conference on Software Engineering. ACM; 2008. P. 261-270.

19. ArgoUML-SPL website: http://argouml-spl.tigris.org/

20. Couto M, Valente M, Figueiredo E. Extracting Software Product Lines: A Case Study Using Conditional Compilation. In: proceedings of the 15th European Conference on Software Maintenance and Reengineering. IEEE Computer Society; 2011. P. 191-200.

21. Al-Msie'deen R, Huchard M, Seriai A, Urtado C, Vauttier S. Reverse Engineering Feature Models from Software Configurations using Formal Concept Analysis. In: proceedings of the Eleventh International Conference on Concept Lattices and Their Applications. CEUR-WS.org; 2014. P. 95-106.

22. Al-Msie'deen R, Huchard M, Seriai A, Urtado C, Vauttier S, Al-Khlifat A. Concept Lattices: A Representation Space to Structure Software Variability. In: proceedings of the 5th International Conference on Information and Communication Systems. IEEE; 2014. P. 1-6.