Evolution Impact on Architecture Stability in Open-Source Projects

Evolution Impact on Architecture Stability in Open-Source Projects

Mamdouh Alenezi (Prince Sultan University, Riyadh, Saudi Arabia) and Fakhry Khellah (Prince Sultan University, Riyadh, Saudi Arabia)
Copyright: © 2015 |Pages: 12
DOI: 10.4018/IJCAC.2015100102
OnDemand PDF Download:
No Current Special Offers


Software systems usually evolve constantly, which requires constant development and maintenance. Subsequently, the architecture of these systems tends to degrade with time. Therefore, stability is a key measure for evaluating an architecture. Open-source software systems are becoming progressively vital these days. Since open-source software systems are usually developed in a different management style, the quality of their architectures needs to be studied. ISO/IEC SQuaRe quality standard characterized stability as one of the sub-characteristics of maintainability. Unstable software architecture could cause the software to require high maintenance cost and effort. In this work, the authors propose a simple, yet efficient, technique that is based on carefully aggregating the package level stability in order to measure the change in the architecture level stability as the architecture evolution happens. The proposed method can be used to further study the cause behind the positive or negative architecture stability changes.
Article Preview

1. Introduction

Software evolution is the vigorous activities of software systems while they are improved and maintained over their lifespans (Lehman, 1980; Godfrey & German, 2013; Alenezi & Almustafa, 2015). Software systems change and evolve throughout their life cycle to accommodate new features and to improve their quality. Software needs to evolve in order to survive for a lengthy period. The changes that software undergo lie within corrective, preventive, adaptive and perfective maintenance that lead to software evolution. A major characteristic of software evolution is architecture evolution. While a specific system is evolving, its architecture is affected. In opposition, having a plan for how an architecture should evolve is a powerful mechanism to plan and guide software evolution.

Software Architecture is defined in the IEEE standards (ISO/IEC/IEEE, 2011) as “fun- damental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. One desired quality of the software architecture is stability. Stability is one of the maintainability characteristics of the ISO/IEC SQuaRe quality standard (ISO/IEC, 2011). According to this standard, stability is defined as the degree to which the software product can avoid unexpected effects from modifications of the software. (ISO/IEC, 2011).

Abundant research studies addressed the software evolution of open-source systems, with more than one hundred research papers referenced in recent systematic literature reviews (Breivold, Chauhan, & Babar, 2010; Syeed, Hammouda, & Syat¨a, 2013). Although there are abundant research studies that investigated the evolution of these softwares, very little effort targeted the architecture in general and no work addressed the architectural stability of these systems. Almost all stability related studies target the package level stability by using various metrics. In this work, we concentrate on the most frequently used metric for assessing the package stability which is defined as (Martin, 2003):


The I metric for a package is defined as the ratio of efferent coupling Ce to total coupling Ce + Ca for the package. The Ca denotes the number of other packages that depend upon classes within the package (fan-in). It measures the incoming dependencies. The Ce denotes the number of other packages that the classes in the package depend upon (fan-out). It measures and counts the outgoing dependencies. The I metric indicates how a flexible a package is to change. The metric ranges from zero to one, one indicates a completely unstable package whereas zero indicates a completely stable package. Martin (Martin, 2003) suggests that some packages are easier to change than others. Easy to change packages should depend on less easy to change packages. Depending on packages make a package less stable, as changes affecting depended-upon packages propagate to the depending package. Having other packages depend on a certain package make that package more stable, as more effort is needed to merge changes with all dependent packages. The I metric shows how easy a package is to change.

Due to system evolution, the overall system stability is affected. This is due to mainly changes in the currently existing packages and the instability incurred due to the added new packages. It is very important for system architect to monitor the overall system instability due to various maintenance task such as adding and removing packages, hence, changing the packages dependency relationships. However, calculating an aggregate value that shows the overall system stability due to evolution has not been addressed in literature.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 11: 4 Issues (2021): 1 Released, 3 Forthcoming
Volume 10: 4 Issues (2020)
Volume 9: 4 Issues (2019)
Volume 8: 4 Issues (2018)
Volume 7: 4 Issues (2017)
Volume 6: 4 Issues (2016)
Volume 5: 4 Issues (2015)
Volume 4: 4 Issues (2014)
Volume 3: 4 Issues (2013)
Volume 2: 4 Issues (2012)
Volume 1: 4 Issues (2011)
View Complete Journal Contents Listing