1 Introduction

Software evolution has become a major concern for stakeholders involved in the process of designing and modeling computer systems. Because of the rudimentary nature of software systems to evolve and change over time in order to account for new requirements and different needs, software evolution is considered as a vital pillar within the area of software engineering to ensure consistency and maintainability as well as to allow the system to open up for new directions and strategic opportunities. Further, software architecture must evolve within existing production systems as it constitutes the favorable blueprint for supporting such evolvability at higher modeling levels [1]. This implies that evolution could be handled at earlier modeling phases where future changes could be anticipated. The area of software evolution has received unprecedented interest during the last two decades where numerous research studies have been published describing various methods and frameworks. In return, few studies have been devoted to present classification for software architecture evolution [2]. However, the main stream of most studies are either specialized in software architecture evolution as knowledge re-usability or addressing software evolution from an overall perspective [3, 4]. Buckley et al. (2005) proposed a taxonomy of software changes which characterize the mechanisms of change and their influencing factors. Williams et al. (2010) suggested that the key solution to address software changes is to identify the causes and effects which can be used to illustrate the potential impact of the change. The major drawback of their study is the lack of an explicit framework capable of positioning a given approach based on well-defined criteria or metrics. Introducing an evolution framework would fulfill the need to identify certain specifications according to which approaches can be classified. Because of the dearth of classification procedures that address the architectural evolution techniques with respect to well-defined dimensions, a conceptual framework that addresses the major concerns related to the evolution nature of software architecture is proposed in this research study. A framework can offer a structured and coherent design for examining the organizational aspect in software architecture evolution as well as assist architects to address decisions on new requirements. De facto, introducing a clear and concise architectural evolution framework would fulfill the need: (i) to identify certain specifications according to the major concerns related to the evolution nature of software architecture and, (ii) to provide a common vocabulary to understand, analyze and categorize a given evolution approach. The discussed model is inspired from the work of Buckley (2005) for software change in addition to the work of [5] for the architecture of information systems. The proposed framework is devised to reshape the dimensions reported in both earlier studies with a newly set of proposed metrics for the arena of software architecture evolution. Such metrics should assist to examine and assess evolution approaches through providing answers which revolve around these dimensions: What, Why, Where, Who, When and How the software architecture evolves? Based on these dimensions, the following research questions are addressed during this research study:

  • RQ1: What are the major metrics that can be used to analyze and compare the different architectural evolution methods?

  • RQ2: Based on such dimensions, can a classification framework devises to regroup and categorize architectural evolution approaches?

The remainder of the paper is organized as follows: the proposed dimensions defined for positioning architectural evolution and a method for classifying them are explained in the following section. The third section illustrates the results drawn by the application of the proposed framework on a set of well-known frameworks in the field of software evolution. The penultimate section is dedicated to discuss the findings to explore and compare the potentials of the proposed dimensions. Conclusions are drawn within the last section.

2 Proposed Framework

2.1 Framework Dimensions

What? Object of Evolution Dimension - The object of evolution is the subject on which the evolution is operated. It answers the what question and comprises of the following:

  • Artifact: is an abstraction of any element belonging to the architectural structure. It may be a software architecture, a component, a service and so forth. It can be simple and even concrete description as program codes for example.

  • Process: Process is as a set of interacting activities, which transforms inputs into outputs. Therefore the process also evolves and presents suitable means for anchoring the benefits pertaining to cost optimization and quality promotion [6], workflows in SOA are one of the best examples of processes.

Where? Hierarchical Level Dimension - Two types of hierarchical levels are commonly identified within the software engineering literature as depicted in Fig. 1, which are modeling and abstraction levels.

  • Modeling levels (\(\mathbf {M}_\mathbf {0}\) to \(\mathbf {M}_\mathbf {2}\mathbf{){:} }\) Software systems must be mapped over several levels, from lower-level constructs (code) to higher-level constructs, to ensure convergence [7]. Modeling level refers to one of the four levels (from \(\text {M}_\text {0}\) to \(\text {M}_\text {3}\)) as defined by the OMG [8].

  • Abstraction levels (\(\mathbf {a}_\mathbf {0}\) to \(\mathbf {a}_\mathbf {n}\mathbf{){:} }\) Experts often use abstraction as an approach to address complex problems. This is still very often used for solving problems related to software modeling. Thereby, a solution is performed through a series of model description at a number of abstraction levels referred to in the Fig. 1 as \(\text {a}_\text {0}\), \(\text {a}_\text {1}\)..., \(\text {a}_\text {n}\).

Fig. 1.
figure 1

Modeling levels vs. Abstraction-levels

Full size image

When? Time of Evolution - In respect of architectural viewpoint, the time of evolution embraces one of these metrics:

  • Design-time: Predicting evolution at the earlier stages of design allows improving and extending the system architecture. Model Driven Architecture is a good of methods addressing evolution at design-time, especially co-evolution approaches.

  • Run-time: The evolution can occur while the system is running [9]. So far, evolving at run-time is considered as a major topic to address architecture adaptation [10]. Noting that, this metric encompasses: compile-time, Load-time and Dynamic-time [10, 11].

Why? Type of Evolution Dimension - It is one of the most commonly-used metric when addressing classification issues. This dimension encloses the two following main sub-categories:

  • Main-categories: Instead of categories based on the architects intentions, main-categories sub-dimension is responding to the objective evidence of architect’s activities identifiable from observations and artifacts before and after comparison of the software architecture.

  • Main-Forms of resolution: Architects can use several strategies for the evolution problem-solving according to different forms. From the literature, the following two major studies discussed the various forms in the area of evolution.

  1. (i)

    Chaki et al. [12] grouped the different resolution methods into two main strategies:

    • Open evolution means from an initial architecture, of a new architecture reflecting a system solution in which a set of invariants and constraints are respected.

    • Close evolution means the evolution activity uses induction resolution to find the best permissible sequence of operations to be applied to achieve the desired result.

  2. (ii)

    Oussalah et al. [13] proposed two other forms:

    • Break evolution means that interventions are applied directly to the initial architecture without having the ability to go back on the trace of the evolution.

    • Seamless evolution denotes an evolution with trace whereby the architecture keeps a trace of its initial properties and operations performed before each evolving process.

    The proposed structuring for deducing the assumed evolution type for a particular method is shown in Table 1 such that the categorization is based hybridly on categories and forms of resolution. Herein, the proposed type of evolution is structured according to two main forms (curative or anticipative) which are explained as follows:

    • Curative - when new requirements arise unpredictably during the life cycle.

    • Anticipative - can be applied when evolution requirements are taken into account during the analysis.

Table 1. Structure of the type of evolution.
Full size table

The two main forms (Curative and Anticipative) can be set either to Close or Open. In the same way, the latter sub-forms can be set to Break or Seamless.

Who? Stakeholders - Stakeholders contribute in architecture enhancement in multiple roles regarding the responsibility they assume and the range of challenges they face [14]. For instance, this dimension covers only those stakeholders that operate evolution on the software system itself by referring to the development team enclosing researches, architects, designers, developers, analysts and programmers [10]. This dimension specifies two main knowledge about how are involved and interested by the evolution of software architecture.

How? Operating Mechanism of Evolution - The operating mechanism of evolution (OME) is introduced to refer to the general behavior and employed procedure by taking into account solely the described hierarchical levels. Mainly, evolution solving approaches commonly adhere to one of the two main following methods:

  • Reduce: For the reductionist evolution, the process gets through a predefined evolution path; until the solution is satisfied (evolved model). Brooks [15] 25 defines the reductionist approach as classical approach to problem solving to which the overall resolution task is decomposed into subtasks.

  • Emergence: On the contrary during an emergentist evolution approach, the process builds the path to a solution. The emergence exposes a passage between the activity of micro-level and that of macro-level.

3 Case Study

3.1 Metric Calculations

In order to clarify applicability of the proposed framework, two studies of architectural evolution are analyzed and compared. These studies are only cited as an example for evolution approaches among many other relevant approaches. The first study by Oussalah et al. [16] presents a software architecture evolution model (SAEV) which aims to describe and manage the evolution through the architectural elements of a given software architecture. SAEV considers software architecture elements (component, connector, interface and configuration) as first class entities. Managing these elements is conceived independently of any architecture language level by considering the different levels of modeling (meta-level, architectural level and application level). The second by Barnes et al. [17] is an automatic approach provided to assist architects by planning alternative evolution paths for evolving software architecture. An evolution path is expressed in terms of intermediate architecture generated from the initial state. If the architect’s goal is clear, this approach aims to assist architects to find the optimal path that meets the evolution requirements. The evolution path acts explicitly on software architecture and applies evolution from a higher to lower level to reach the desired architecture. This approach helps architects to find the optimal path for the evolved architecture. In order to apply the conceptual framework for the two approaches, all the discussed dimensions are quantified using three values 1, 0.5 and 0 which reflect respectively explicit, implicit and not mentioned. Conventionally, a dimension, which is explicitly mentioned, is assigned the value one. However, if it is shown in implicit fashion, 0.5 is assigned. Otherwise, the estimated value is zero. The values obtained from Table 2 shows that the two approaches have considered the six dimensions. For the where dimension for example, the first approach has explicitly expressed evolution at different modeling levels and implicitly shows the consideration of the abstraction levels which leads to a value of 1.5 from two of the whole dimension expressiveness which gives 75% against 25% for the second approach. These percentages serve as evaluation and comparison for determining the approach focus regarding the proposed dimensions. In similar fashion, the other dimensions are analyzed and compared accordingly. In summary, the first approach focuses on modeling levels of the architecture whereas the second is based on abstraction levels mainly used for reducing evolution complexity. It is noteworthy that the two approaches show identical values of object, type, stakeholder and time of evolution and both support the ‘reduce’ operating mechanism of evolution.

Table 2. Comparison of two evolution approaches using the framework
Full size table

3.2 Framework Assessment

Three prominent existing studies have been selected and surveyed to further evaluate the conceptual framework using the proposed metrics on their set of surveyed papers as follows:

The first considered survey study that involves 32 research papers was conducted by Ahmad [18] which focuses on approaches wherein changes impact the architectural level when analyzing and improving software evolvability. The investigation of the existing methods or techniques, either for systematic application or for empirical acquisition of architectural knowledge, categorizes evolution reuse knowledge into six broad themes: (i) evolution styles, (ii) change patterns, (iii) adaptation strategies and policies, (iv) pattern discovery, (v) architecture configuration analysis, and (vi) evolution and maintenance prediction. The proposed thematic classification focuses on both time of evolution and type of evolution for reuse knowledge.

The second study by Breivold et al. [2] where five main categories of themes are identified based substantially on research topics through an investigation of 82 research papers: (i) techniques supporting quality consideration during software architecture design, (ii) architectural quality evaluation, (iii) economic valuation, (iv) architectural knowledge management, and (v) modeling techniques. A set of specific characteristics is provided with a view to refine each category to subcategories reflecting a common specification in terms of research focus, research concepts and context.

The third by Chaki et al. [12] recommends three classes of common type for architectural evolution:

  • Maintenance focused evolution - these are works concerned with the use of correction decisions and architectural modifiability to address architects’ concerns. These works often require intervention at the lowest modeling level.

  • Open evolution - refers to all software architectural evolution works whose final architecture is not known a priori. These approaches infer, from an initial architecture, one or more solutions in respect of a context known beforehand.

  • Closed evolution - Categorizes works in which the target architecture of the model is known before proceeding to the evolution of the initial architecture. It is a question of finding a sequence of operations that may guide an initial architecture to a desired one.

It is worth emphasizing that the first step was to devise a set of projections for the conceptual benchmarks and afterwards for the proposed taxonomy. These projections aim to reveal the coverage of each of the benchmarks that appear most frequently across the range of architectural evolution studies. Table 3 summarizes the quantification using weighted results of the six dimensions. The percentage of each dimension is calculated by dividing the sum of expressed studies by the total number of investigated studies. Detailed illustration for the provided results in Table 3 relating to the Type dimension (including Forms and Categories) are further shown in Table 4. The results presented in both tables reveal the just proportion (or disproportion) between weights granted for each proposed dimension.

Table 3. Coverage percentages of the proposed dimensions.
Full size table
Table 4. Details of form and category percentages.
Full size table

4 Discussion

Significantly, Table 3 shows that over three-quarters of the selected studies have explicitly fostered modeling levels for all works, which explains these studies’ relevance to the architecture evolution topic. Further, percentages show that a wide range of studies are committed to artifact as an object of evolution, except for [12] which focuses on process evolution studies. This is due to the fact that both existing evolution support formalism (SAEV [16], Query/View/Transformation-based [19], ...) and architecture description languages (ADL, UML, xADL, ...) for evolution models are all artifact oriented. It is worth noting that styles and patterns are actually more suitable for evolving architecture elements (artifacts) but contribute little to address the evolution issue of the styles themselves [20]. In addition, the modeling level has attracted major interest from the evolution community for the reason that it overlaps with the abstraction level concept. In the same way, an overwhelming percentage deal with reducing evolution from higher to lower level, i.e. top-down hierarchy modeling fashion. In our view, this preponderance is mostly due to a deductive reasoning influence which promotes the top-down method (i.e. reduce OME). However, this reductionism may deprive software architecture systems to introduce new solution opportunities according to the current and/or future environment assumptions. Regarding the temporal dimension, values are systematically in favor of the design-time which in our opinion reflects the interest to the anticipation activity to deal with evolution. It is noted that all these studies specify the importance of stakeholders requirements when dealing with evolution. The percentages in Table 4, show that the main categories sub-dimension attracted an explicit interest from all the studies apart from Chaki et al. (2009).

5 Conclusion

In this paper, a conceptual framework is presented for modeling the classification of software architecture evolution approaches. This model is based on evaluating six proposed dimensions on a given approach. The proposal is part of a wider strategy to evaluate tendency of existing research within software architecture evolution according to well-defined dimensions. Thus, the proposed model provides architects with the capacity for understanding and analyzing the evolution before making technical choices. Considering the impact of evolution process through the hierarchical levels, an evolution framework of six different dimensions is devised. This would help to sketch the interior design of the architectural evolution solution space. Based on an experimental study of three well known classifications, the investigation of the coverage in software architecture evolution has drawn a number of conclusions on opportunities, strength and weakness of existing approaches. The obtained results highlight the lack of emergence techniques, which could be a very promising track. The proposed conceptual framework enjoys the merits of (i) compare different architectural evolution approaches, (ii) determine the appropriate evolution approach according to the dimensions that seems the most relevant to the application class and (iii) to guide thinking within research teams on new architectural evolution approaches.