20.01.2014 Views

thesis - Faculty of Information and Communication Technologies ...

thesis - Faculty of Information and Communication Technologies ...

thesis - Faculty of Information and Communication Technologies ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 6. Change Dynamics<br />

6.2.2 Rate <strong>of</strong> Modification<br />

As noted in the previous section, a relatively small set <strong>of</strong> classes in<br />

any given version is subject to change. However, how <strong>of</strong>ten are these<br />

classes modified? What does the distribution <strong>of</strong> this modification look<br />

like? In order to underst<strong>and</strong> this better, we investigated the number<br />

<strong>of</strong> times a class is modified. We ignore the total number <strong>of</strong> releases<br />

for a project intentionally as it will reveal if there is a common pattern<br />

between systems at an absolute level. For example, we can answer the<br />

question - what is the probability that developers will modify a class more<br />

than 3 times? In essence, we are making the assumption that after<br />

a certain point (say the first few releases) the maturity <strong>of</strong> a s<strong>of</strong>tware<br />

system will have a minimal impact on the number <strong>of</strong> times a class is<br />

modified.<br />

For the analysis, we measured the number <strong>of</strong> times a class has been<br />

modified since birth across the entire data set (approximately 55300<br />

classes across all projects). In our data, on average 45% <strong>of</strong> the classes<br />

were never modified once created. However, when the data was analyzed<br />

by project, the range <strong>of</strong> classes that were never modified was<br />

between 22% <strong>and</strong> 63%. For instance, in Saxon only 22% <strong>of</strong> the classes<br />

were unchanged, while at the other end in Jung <strong>and</strong> ActiveMQ 63%<br />

<strong>of</strong> the classes were unchanged after birth. Only considering classes<br />

that have been modified at some point in their life cycle <strong>and</strong> counting<br />

the number <strong>of</strong> times that they have been changed, we can observe that,<br />

approximately 60% <strong>of</strong> the classes are modified less than 4 times (see<br />

Figure 6.5). The range is however fairly broad. In Jung, for example,<br />

90% <strong>of</strong> modified classes are changed less than 3 times.<br />

Furthermore, though most systems have a similar modification pr<strong>of</strong>ile<br />

(see Figure 6.5), a few systems (Axis, iText, Saxon, Jung <strong>and</strong> ActiveBPEL)<br />

show up as clear outliers. Axis, iText <strong>and</strong> Saxon had relatively<br />

higher number <strong>of</strong> classes that underwent modification, we noticed that<br />

Jung <strong>and</strong> ActiveBPEL were at the other extreme with fewer classes that<br />

underwent changes. In 33 systems less than 10% <strong>of</strong> all modified classes<br />

were changed more than 8 times. This suggests that the probability that<br />

a class is modified multiple times is quite low <strong>and</strong> that this probability<br />

153

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!