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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 6. Change Dynamics<br />

had to modify many classes. The developers, in effect, had to make<br />

changes in a number <strong>of</strong> classes in new versions as they attempted to<br />

adhere to the st<strong>and</strong>ards incrementally. Furthermore, the lack <strong>of</strong> coherent<br />

reusable components <strong>and</strong> libraries, also meant that they had<br />

to improve existing classes rather than upgrade external libraries <strong>and</strong><br />

components.<br />

To ensure completeness, we investigated two other systems in our data<br />

set that share a similarity with iText, Saxon <strong>and</strong> Axis in terms <strong>of</strong> their<br />

functional domain. The two systems were, Xerces-2 XML processor <strong>and</strong><br />

Xalan XSL-T processor. Both these products also satisfy st<strong>and</strong>ardised<br />

XML technology specifications developed by W3C. Interestingly, these<br />

projects made very different choices at the start <strong>of</strong> their life cycle. The<br />

Xerces-2 project was a complete re-write <strong>of</strong> the Xerces-1 platform, however,<br />

for the new build, developers satisfied most <strong>of</strong> the core specification<br />

in an initial release rather than via incremental refinement. Further,<br />

based on the experience gained from earlier attempts, the Xerces-2<br />

developers built a modular architecture that allowed them to make incremental<br />

adjustments [309] to changing specifications, but the bulk<br />

<strong>of</strong> the code remained stable. The Xalan project did not have a previous<br />

release <strong>and</strong> knowledge base to build on top <strong>of</strong> [307]. The development<br />

team, however, chose to create a highly modular architecture with well<br />

defined functional boundaries that permitted incremental refinement<br />

<strong>and</strong> the ability to replace libraries <strong>and</strong> components [308]. They also<br />

relied on a number <strong>of</strong> existing stable libraries to provide common functionality<br />

(unlike iText <strong>and</strong> Saxon where developers built many key data<br />

structures <strong>and</strong> algorithms). The change analysis data suggests that<br />

these choices have helped the team as they evolve <strong>and</strong> adapt the systems.<br />

The development strategy <strong>and</strong> choices made by the developers has an<br />

impact on the change pr<strong>of</strong>ile. Despite the type <strong>of</strong> approach taken, all<br />

five systems (iText, Saxon, Axis, Xerces-2 <strong>and</strong> Xalan) have continuously<br />

evolved, potentially satisfying user needs. However, our study suggests<br />

that when attempting to match formal st<strong>and</strong>ards, a modular architecture<br />

built after a careful analysis <strong>of</strong> the entire specification can help<br />

reduce the frequency <strong>and</strong> magnitude <strong>of</strong> changes. The strategy <strong>of</strong> us-<br />

173

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

Saved successfully!

Ooh no, something went wrong!