Article Preview
Top1. 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):
(1)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.