Skip to main content
SpringerLink
Log in

Assessing architectural evolution: a case study

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

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 multi-faceted 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 long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know 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 approach.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16

Similar content being viewed by others

Notes

  1. http://www.graphviz.org/

  2. http://code.google.com/apis/visualization/interactive_charts.html

  3. We should point out that the axioms are only meant to distinguish the concept(s) being measured by a metric; the axioms don’t enforce independence of the metrics. For example, coupling and cohesion aren’t completely independent of complexity because the latter is based on all relations, whereas the former two are based on the subsets of inter-module and intra-module relations, respectively. This means that the various monotonicity axioms together impose that adding intra-module relations will decrease neither cohesion nor complexity, and likewise adding inter-module relations doesn’t decrease coupling and complexity.

  4. http://www.stan4j.com

References

  • Basili V, Briand L, Melo W (1996) A validation of object-oriented design metrics as quality indicators. IEEE Trans Softw Eng 22(10):751–761

    Article  Google Scholar 

  • Ben-Ari M (1982) Principles of concurrent programming. Prentice-Hall, Englewood Cliffs

    MATH  Google Scholar 

  • Beyer D (2008) CCVisu: automatic visual software decomposition. In: Proc int’l conf on software engineering, companion volume. ACM, New York, pp 967–968

    Google Scholar 

  • Beyer D, Noack A, Lewerentz C (2005) Efficient relational calculation for software analysis. IEEE Trans Softw Eng 31(2):137–149

    Article  Google Scholar 

  • Bloch J (2001) Effective Java. Addison-Wesley, Reading

    Google Scholar 

  • Bois BD, Rompaey BV, Meijfroidt K, Suijs E (2008) Supporting reengineering scenarios with FETCH: an experience report. In: Electronic communications of the EASST 8, selected papers from the 2007 ERCIM symp on software evolution

  • Briand LC, Morasca S, Basili VR (1996) Property-based software engineering measurement. IEEE Trans Softw Eng 22(1):68–86

    Article  Google Scholar 

  • Briand LC, Morasca S, Basili VR (1997) Response to: comments on “Property-based software engineering measurement: refining the additivity properties”. IEEE Trans Softw Eng 23(3):196–197

    Article  Google Scholar 

  • Briand LC, Wüst J, Daly JW, Porter DV (2000) Exploring the relationship between design measures and software quality in object-oriented systems. J Syst Softw 51(3):245–273

    Article  Google Scholar 

  • Brown W, Malveau R, Mowbray T (1998) AntiPatterns: refactoring software, architectures, and projects in crisis. Wiley, New York

    Google Scholar 

  • Ciupke O (1999) Automatic detection of design problems in object-oriented reengineering. In: Proc 30th int’l conf on technology of object-oriented languages and systems. IEEE, Piscataway, pp 18–32

    Google Scholar 

  • Crespo Y, López C, Marticorena R, Manso E (2005) Language independent metrics support towards refactoring inference. In: Int’l workshop on quantitative approaches in object-oriented software engineering

  • Dagpinar M, Jahnke JH (2003) Predicting maintainability with object-oriented metrics—an empirical comparison. In: Proc working conf on reverse engineering. IEEE, Piscataway, pp 155–164

    Google Scholar 

  • Eldredge N, Gould SJ (1972) Punctuated equilibria: an alternative to phyletic gradualism. In: Schopf T (ed) Models in palaeobiology. Freeman and Cooper, San Francisco, pp 82–115

    Google Scholar 

  • Emam KE, Benlarbi S, Goel N, Rai SN (2001) The confounding effect of class size on the validity of object-oriented metrics. IEEE Trans Softw Eng 27(7):630–650

    Article  Google Scholar 

  • Eysenck HJ (1976) Case studies in behaviour therapy. Routledge, Evanston. Chap Introduction

  • Fernández-Ramil J, Lozano A, Wermelinger M, Capiluppi A (2008) Empirical studies of open source evolution. In: Software evolution, chap 11. Springer, New York, pp 263–288

    Google Scholar 

  • Flyvbjerg B (2006) Five misunderstandings about case-study research. Qual Inq 12(2):219–245

    Article  Google Scholar 

  • Fowler M, Beck K, Brant J, Opdyke W, Roberts D (1999) Refactoring: improving the design of existing code. Addison-Wesley, Reading

    Google Scholar 

  • Gamma E, Helm R, Johnson R, Vlissides J (1995) Design patterns: elements of reusable object-oriented software. Addison-Wesley, Reading

    Google Scholar 

  • Godfrey MW, Tu Q (2000) Evolution in open source software: a case study. In: Int’l conf on software maintenance. IEEE, Piscataway, pp 131–142

    Google Scholar 

  • Hansen KM, Jónasson K, Neukirchen H (2009) An empirical study of open source software architectures’ effect on product quality. Tech Rep VHI-01-2009, Engineering Research Institute, Univ of Iceland

  • Hou D (2007) Studying the evolution of the Eclipse Java editor. In: Proc OOPSLA workshop on eclipse technology exchange. ACM, New York, pp 65–69

    Chapter  Google Scholar 

  • Johnson RE, Foote B (1988) Designing reusable classes. J Object-Oriented Program 1(2):22–35

    Google Scholar 

  • Juergens E, Deissenboeck F, Hummel B, Wagner S (2009) Do code clones matter? In: Proc int’l conference on software engineering. IEEE, Piscataway, pp 485–495

    Google Scholar 

  • Kuhn TS (1987) What are scientific revolutions? In: The probabilistic revolution, vol 1. MIT, Cambridge, pp 7–22

    Google Scholar 

  • Lakos J (1996) Large-scale C+ + software design. Addison-Wesley, Reading

    Google Scholar 

  • Lehman MM, Belady LA (1985) Program evolution: processes of software change. Academic, New York

    Google Scholar 

  • Lehman MM, Ramil JF, Wernick PD, Perry DE, Turski WM (1997) Metrics and laws of software evolution—the nineties view. In: Proc symp on software metrics. IEEE, Piscataway, pp 20–32

    Chapter  Google Scholar 

  • Lieberherr KJ, Holland I, Riel A (1988) Object-oriented programming: an objective sense of style. In: Proc int’l conf on object oriented programming, systems, languages, and applications, pp 323–334

  • Liskov B (1987) Data abstraction and hierarchy. In: Proc int’l conf on object oriented programming, systems, languages, and applications. ACM, New York, pp 17–34

    Chapter  Google Scholar 

  • Marinescu R (2001) Detecting design flaws via metrics in object oriented systems. In: Proc int’l conf on technology of object-oriented languages and systems. IEEE, Piscataway, pp 173–182

    Google Scholar 

  • Martin RC (1996) Granularity. C+ + Report 8(10):57–62

    Google Scholar 

  • Martin RC (1997) Large-scale stability. C+ + Report 9(2):54–60

    Google Scholar 

  • Medvidovic N, Dashofy EM, Taylor RN (2007) Moving architectural description from under the technology lamppost. Inf Softw Technol 49(1):12–31

    Article  Google Scholar 

  • Melton H (2006) On the usage and usefulness of OO design principles. In: Companion to the 21st OOPSLA. ACM, New York, pp 770–771

    Google Scholar 

  • Melton H, Tempero E (2007) An empirical study of cycles among classes in Java. Empir Software Eng 12(4):389–415

    Article  Google Scholar 

  • Mens T, Fernández-Ramil J, Degrandsart S (2008) The evolution of Eclipse. In: Proc 24th int’l conf on software maintenance. IEEE, Piscataway, pp 386–395

    Google Scholar 

  • Meyer B (1988) Object-oriented software construction. Prentice-Hall, Englewood Cliffs

    Google Scholar 

  • Meyer B (1992) Applying ‘design by contract’. Computer 25(10):40–51

    Article  Google Scholar 

  • Moha N, Guéhéneuc YG, Leduc P (2006) Automatic generation of detection algorithms for design defects. In: Proc int’l conf on automated software engineering. IEEE, Piscataway, pp 297–300

    Google Scholar 

  • Munro M (2005) Product metrics for automatic identification of “bad smell” design problems in Java source-code. In: Proc int’l symp on software metrics. IEEE, Piscataway, pp 15–24

    Google Scholar 

  • Parnas DL (1972) On the criteria to be used in decomposing systems into modules. Commun ACM 15(12):1053–1058

    Article  Google Scholar 

  • Popper KR (1959) The logic of scientific discovery. Hutchinson, London

    MATH  Google Scholar 

  • Ratiu D, Ducasse S, Girba T, Marinescu R (2004) Using history information to improve design flaws detection. In: Proc European conf on software maintenance and reengineering. IEEE, Piscataway, pp 223–232

    Google Scholar 

  • Riel A (1996) Object-oriented design heuristics. Addison-Wesley, Reading

    Google Scholar 

  • Simon HA (1962) The architecture of complexity. Proc Am Philos Soc 106(6):467–482

    Google Scholar 

  • Stevens W, Myers G, Constantine L (1979) Structured design. In: Classics in software engineering. Yourdon Press, Upper Saddle River, NJ, USA, pp 205–232

    Google Scholar 

  • Tahvildari L, Kontogiannis K (2003) A metric-based approach to enhance design quality through meta-pattern transformations. In: Proc European conf on software maintenance and reengineering. IEEE, Piscataway, pp 183–192

    Google Scholar 

  • Tourwe T, Mens T (2003) Identifying refactoring opportunities using logic meta programming. In: Proc European conf on software maintenance and reengineering. IEEE, Piscataway, pp 91–100

    Google Scholar 

  • van Belle T (2004) Modularity and the evolution of software evolvability. PhD thesis, University of New Mexico

  • Walter B, Pietrzak B (2005) Multi-criteria detection of bad smells in code with UTA method. In: Extreme programming and agile processes in software engineering. Springer, New York, pp 154–161

    Chapter  Google Scholar 

  • Wermelinger M, Yu Y (2011) Some issues in the ‘archaeology’ of software evolution. In: Generative and transformational techniques in software engineering III. LNCS, vol 6491. Springer, New York, pp 426–445

    Chapter  Google Scholar 

  • Wermelinger M, Yu Y, Lozano A (2008) Design principles in architectural evolution: a case study. In: Proc 24th int’l conf on software maintenance. IEEE, Piscataway, pp 396–405

    Google Scholar 

  • Wong K (1998) The Rigi user’s manual, version 5.4.4

  • Wu J, Spitzer C, Hassan A, Holt R (2004) Evolution spectrographs: visualizing punctuated change in software evolution. In: Proc 7th intl workshop on principles of software evolution. IEEE, Piscataway, pp 57–66

    Google Scholar 

  • Xing Z, Stroulia E (2004) Understanding class evolution in object-oriented software. In: Proc int’l workshop on program comprehension. IEEE, Piscataway, pp 34–43

    Chapter  Google Scholar 

Download references

Acknowledgements

We thank Markus Keller, Daniel Megert, and Martin Aeschlimann from the IBM Zurich Rational Lab for their feedback, partly given during the preparation of release 3.6, Dirk Beyer for helping us use CCVisu more effectively, and the anonymous reviewers for their detailed and insightful comments, which helped improve the paper.

The 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 Policy.

Author information

Authors and Affiliations

  1. Computing Department & Centre for Research in Computing, The Open University, Milton Keynes, UK

    Michel Wermelinger & Yijun Yu

  2. ICTEAM, Université catholique de Louvain, Place Sainte Barbe, 2, 1348, Louvain-la-Neuve, Belgium

    Angela Lozano

  3. School of Computing, Information Technology and Engineering, University of East London, London, UK

    Andrea Capiluppi

Authors
  1. Michel Wermelinger
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Yijun Yu
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Angela Lozano
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Andrea Capiluppi
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Michel Wermelinger.

Additional information

Editors: Muhammad Ali Babar, Arie van Deursen, and Patricia Lago

Appendices

Appendix A: Web Companion

The ‘web companion’ to this paper is a compressed folder, available from http://oro.open.ac.uk/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 3.3 and displays interactive visualizations in SVG format.

Appendix B: Questionnaire

The following are the questions sent by e-mail to the developers mentioned in the acknowledgements.

  1. Q1

    We 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 3rd-party plugins, or some other reason? If no, is there some other reason that might lead to few deletions?

  2. Q2

    We found that the number of plugins and their dependencies (as declared in the plugin.xml and manifest.mf files) grows more than linearly and that the average size (number of classes) of a plugin has been decreasing. Is this finer-grained modularization of Eclipse an explicit architectural design aim? Has the rapidly growing number of plugins and dependencies caused any development problems or delays, e.g. because it is harder for each developer to keep in their head an overview of the architecture?

  3. Q3

    We 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?

  4. Q4

    We found only one cyclic static dependency during the whole history, existing from 2.1 until 2.1.3. The cycle is between three plugins ui, ui.editors, ui.workbench.texteditor in the platform feature. The cycle was broken in 3.0. Is the absence of cyclic dependencies an explicit aim of yours?

  5. Q5

    Release 3.0 had the biggest growth in number of dependencies; and Release 3.1 is the only one in which that number decreased. Was that reduction of dependencies an explicit aim of release 3.1, i.e. an architectural cleanup after 3.0, to reduce the complexity of the architecture?

  6. Q6

    We found the following about extension points.

    • Most new extension points are added to existing plugins (rather than appearing with new plugins). Is this to ‘open up’ existing functionality? Why tend new plugins not to have extension points?

    • Extension points are never deleted by themselves, they disappear when their plugin is deleted. Is this to keep backward compatibility?

    • Those extension points not used by the SDK itself more than duplicated in 3.4 but then were deleted in 3.5. What is the reason for such big changes?

  7. Q7

    We clustered plugins according to whether they were created, deleted, or had their dependencies or extension points changed in the same release. Plugins closer together have more co-changes. We found that on average plugins in different subsystems (org.eclipse.ui.*, org.eclipse.pde.*, etc.) are closer together than those in different features, i.e. there are more co-changes across subsystem boundaries than across feature boundaries. This finding means that it might be slightly harder to implement changes if developers are allocated to subsystems rather than to features. Could you briefly comment on this and how work is allocated among the SDK team?

  8. Q8

    We also clustered plugins according to how many dependencies there are between them, and did so release by release and saw a trend that the difference between intra-unit (subsystem or feature) and inter-unit clustering is diminishing, i.e. plugin dependencies across subsystems and features tend to be on par with dependencies within subsystems and features. This could be interpreted as a sign of architectural decay or lack of cohesion, as coarse grained modules (subsystems and features) are becoming less the containers of strongly dependent plugins. Could you comment on this? Have you experienced increasing difficulties in coordinating architectural changes across sub-teams? Or are subsystems and features not very important for architectural design, plugin modularisation, and work allocation?

  9. Q9

    We have found an architectural core (set of plugins and dependencies) that remains unchanged since 1.0. Is this something you are aware and hence avoid making architectural changes there? Was it designed from the start to be a stable core?

Rights and permissions

Reprints and permissions

About this article

Cite this article

Wermelinger, M., Yu, Y., Lozano, A. et al. Assessing architectural evolution: a case study. Empir Software Eng 16, 623–666 (2011). https://doi.org/10.1007/s10664-011-9164-x

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-011-9164-x

Keywords

Search

Navigation