thesis - Faculty of Information and Communication Technologies ...
thesis - Faculty of Information and Communication Technologies ...
thesis - Faculty of Information and Communication Technologies ...
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 />
the change properties identified suggest that there is an 80% probability<br />
that at least 25 classes will be modified. Our observations also<br />
identified that as s<strong>of</strong>tware matures, these properties (Equations 6.2.9<br />
<strong>and</strong> 6.2.10) are much more likely to hold. Our results suggest that maturity<br />
increases the resistance to change as developers are likely to be<br />
comfortable with the current set <strong>of</strong> abstractions.<br />
The change properties themselves cannot be directly used to assess the<br />
quality <strong>of</strong> a s<strong>of</strong>tware project. Rather, they serve as effective <strong>and</strong> useful<br />
feedback mechanism allowing managers <strong>and</strong> developers to underst<strong>and</strong><br />
the evolution <strong>of</strong> a s<strong>of</strong>tware system better <strong>and</strong> review the code more effectively.<br />
We highlight the value <strong>of</strong> these properties with two examples<br />
which had unusually high violations <strong>of</strong> the properties.<br />
The first example is the Ant build system, a project that exhibited the<br />
greatest amount <strong>of</strong> violations (in our data set) <strong>of</strong> the two change properties<br />
(Equations 6.2.9 <strong>and</strong> 6.2.10). Our analysis shows that most <strong>of</strong><br />
these violations are primarily driven by the plug-in architecture style<br />
used in this s<strong>of</strong>tware system. Ant is a build automation s<strong>of</strong>tware similar<br />
to make [258]. This s<strong>of</strong>tware was conceptualised <strong>and</strong> built around<br />
a plug-in based architecture where new build automation tasks can be<br />
developed <strong>and</strong> added with minimal changes to the existing code. Most<br />
<strong>of</strong> the enhancements to Ant came as new plug-ins that provided new<br />
build automation tasks. The core <strong>of</strong> the system is only modified if a large<br />
number <strong>of</strong> plug-ins are replicating similar functionality. This plug-in<br />
architecture allows developers to create <strong>and</strong> add new classes without<br />
requiring many changes in the existing code base. This modular architectural<br />
style <strong>and</strong> the domain <strong>of</strong> the application in effect meant that in<br />
most new releases, there was a greater proportion <strong>of</strong> new classes compared<br />
to modified classes (violating the change properties at a greater<br />
rate than expected).<br />
The second example is Struts, another project that also had a large<br />
number <strong>of</strong> violations for the change properties (nearly 50% <strong>of</strong> the releases).<br />
An investigation into the release notes <strong>and</strong> source code <strong>of</strong> Struts<br />
shows that changes can be attributed to the developers rewriting large<br />
parts <strong>of</strong> the codebase twice. The first complete re-write used a small<br />
166
Change language