Assessing architectural evolution a case study

Authors: Michel Wermelinger Yijun Yu Angela Lozano Andrea Capiluppi

Publish Date: 2011/06/11

Volume: 16, Issue: 5, Pages: 623-666

PDF Link

Abstract

This paper proposes to use a historical perspective on generic laws principles and guidelines like Lehman’s software evolution laws and Martin’s design principles in order to achieve a multifaceted process and structural assessment of a system’s architectural evolution We present a simple structural model with associated historical metrics and visualizations that could form part of an architect’s dashboard We perform such an assessment for the Eclipse SDK as a case study of a large complex and longlived system for which sustained effective architectural evolution is paramount The twofold aim of checking generic principles on a wellknow system is on the one hand to see whether there are certain lessons that could be learned for best practice of architectural evolution and on the other hand to get more insights about the applicability of such principles We find that while the Eclipse SDK does follow several of the laws and principles there are some deviations and we discuss areas of architectural improvement and limitations of the assessment approachWe thank Markus Keller Daniel Megert and Martin Aeschlimann from the IBM Zurich Rational Lab for their feedback partly given during the preparation of release 36 Dirk Beyer for helping us use CCVisu more effectively and the anonymous reviewers for their detailed and insightful comments which helped improve the paperThe third author has been supported by the ICT Impulse Programme of the Institute for the encouragement of Scientific Research and Innovation of Brussels ISRIB and by the Interuniversity Attraction Poles IAP Programme of the Belgian State Belgian Science PolicyThe ‘web companion’ to this paper is a compressed folder available from http//oroopenacuk/28753 containing all the figures of Section 4 and additional ones in a larger and easier to read format than in this paper Once the folder has been downloaded and uncompressed open the included HTML file in a web browser The file is fed by the Google spreadsheets mentioned in Section 33 and displays interactive visualizations in SVG formatWe found that very few plugins extension points and dependencies are deleted compared to additions Is this an explicit aim of yours If yes is it to keep backwards compatibility of existing 3rdparty plugins or some other reason If no is there some other reason that might lead to few deletionsWe found that the number of plugins and their dependencies as declared in the pluginxml and manifestmf files grows more than linearly and that the average size number of classes of a plugin has been decreasing Is this finergrained modularization of Eclipse an explicit architectural design aim Has the rapidly growing number of plugins and dependencies caused any development problems or delays eg because it is harder for each developer to keep in their head an overview of the architectureWe found that architectural changes plugin and dependency additions and removals were done a mostly in early milestones b some in the release candidates but freezing the architecture in the last release candidates and c hardly ever in service releases Is that an explicit architectural change process you follow

Keywords: