Evolution Taxonomy for Software Architecture Evolution

Noureddine Gasmallah

1,2,3

, Abdelkrim Amirat

and Mourad Oussalah

Department of Computer Science, University of Annaba, Sidi-Amar, 23000, Annaba, Algeria

Department of Maths and Computer Science, University of Souk-Ahras, Rte d’Annaba, 41000, Souk-Ahras, Algeria

Department of Computer Science, University of Nantes, 2 Rue de la Houssini´ere BP-92208, 44322, Nantes, France

Keywords:

Software Architecture, Software Evolution, Evolution Taxonomy, Quality Criteria.

Abstract:

Nowadays, architects are facing the challenge of proliferation of stakeholder requirements for preserving and

ensuring the effectiveness of the software, by using software evolution as a key solution. Hence, in terms

of landscaping evolution space there is a great need to deﬁne the thinking on which efforts to deal with this

issue have been based. In this paper, we propose a framework for software architecture evolution taxonomy

based on four structural dimensions. This framework could both position existing evolution models in the

ﬁeld and highlight gray areas for the future. Mapping over framework dimensions, a set of quality factors and

an investigation including 67 studies are performed to assess the proposals. The results contain a number of

relevant ﬁndings, including the need to improve software architecture evolution by accommodating predictable

changes as well as promoting the emergence of operating mechanisms.

1 INTRODUCTION

Nowadays, there is no doubt that software develop-

ment is facing a cumbersome process of handling or

modeling the inevitable evolution within open sys-

tems. Software architecture is a combination of a

set of architectural elements and their interconnec-

tions which are uniﬁed to satisfy design require-

ments. However, the architecture should adhere to the

changes required by the various stockholders in order

to avoid system erosion (Perry and Wolf, 1992) and

to meet their different goals. Thereby, software archi-

tecture must evolve as a systematic result of increased

concern about the environment(Jazayeri, 2005). Con-

sequently, evolution should be planned in the early

phases of modeling the software. These requirements

have in turn stimulated and challenged researchers to

develop new approaches for dealing with the archi-

tecture evolution topic. Despite this widespread inter-

est, few studies on architecture evolution taxonomy

have been found in literature. Therefore, there is a

clear need to bring structure into the software archi-

tecture domain to better landscape the wide array of

research devoted to covering this ﬁeld. This kind of

study is vital for both categorization of the existing

works and highlighting gaps that may provide new

trends for the future. This paper refers to some of the

most signiﬁcant of these. First, (Buckley et al., 2005)

adopt a complementary way of thinking to position a

taxonomy of software change using a non-exhaustive

set of factors inherent to mechanisms used to evolve

systems. These factors are categorized into two non-

separate sets of: dimensions as characterizing and

inﬂuencing factors. Meanwhile, in (Breivold et al.,

2012), the authors identiﬁed ﬁve main categories of

themes based substantially on research topics to con-

duct an investigation of 82 research papers. A set of

speciﬁc characteristics is provided with a view to re-

ﬁne each category to subcategories reﬂecting a com-

mon speciﬁcation on research focus, research con-

cepts and context. The proposed overview does not

mention an explicit framework for the proposed tax-

onomy but presents signiﬁcant descriptions of many

relevant studies for software evolution. However, a

recent study (Ahmad et al., 2014) has identiﬁed six re-

search themes of evolution reuse knowledge by inves-

tigating a set of existing methods, techniques and so-

lutions either for systematic application or for empir-

ical acquisition of architectural knowledge. The pro-

posed thematic classiﬁcation is focused on both time

of evolution (design or runtime) and type of evolution

(change execution or change mining) for reuse knowl-

edge. The lack of existing studies on characterization

of architectural evolution provide much scope for new

thinking about classifying the existing works (Gar-

lan et al., 2009)(Chaki et al., 2009). The aim of the

124

Gasmallah, N., Amirat, A. and Oussalah, M.

Evolution Taxonomy for Software Architecture Evolution.

In Proceedings of the 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering (ENASE 2016), pages 124-131

ISBN: 978-989-758-189-2

paper is threefold: (i) to provide a conceptual frame-

work by addressing major concerns (what, why, who,

how and when) about the evolution of software ar-

chitecture, (ii) to identify the main taxonomy classes

which could assist in both landscaping the ﬁeld and

highlighting gray areas, (iii) to identify a set of ex-

pected quality criteria which can elucidate the quality

criteria focus for each evolution mechanism. Our mo-

tivations are driven by the need to promote synergy

between the various existing mechanisms throughout

the software evolution ﬁeld. However, we attempt to

ﬁnd a simple and effective arrangement of approaches

which may serve, subsequently, as a standard for evo-

lution. To carry out this study, a set of 67 selected

papers have been classiﬁed into broad categories and

then utilized according to the experimental software

engineering guidelines (Wohlin et al., 2012). The re-

mainder of this paper is structured as follows: sec-

tion two introduces the dimensions of evolutionwhich

draw the conceptual framework and the structure of

the evolution taxonomy. The third section is devoted

to presenting a brief deﬁnition of qualitative expecta-

tions for an evolution model. Section four conducts

a proposal assessment to establish a more holistic un-

derstanding of our proposals. The last section recapit-

ulates our major ﬁndings and discusses implications

for further research.

2 TAXONOMIC FRAMEWORK

A taxonomic framework should be regarded rather

as a tool which provides meaningful benchmarks for

both coverage of the current state of the art and sup-

positions to guide new trends.

2.1 Framework for Software Evolution

By answering certain questions about: what, why,

who, how and when does software architecture

evolve? we can substantially identify the following

four dimensions throughout the current studies: lev-

els (who?), object (where?), type (what?) and the op-

erating mechanism (how?) of evolution (OME in the

following).

2.1.1 Levels of Evolution

This dimension emphasizes the importance of ad-

dressing architecture over one or several hierarchical

levels (Amirat et al., 2011). This entails consider-

ing distinctively the modeling and abstraction levels

during the evolution process as follows: (i) Model-

ing level (M

to M

)- is an abstract representation of

the structure and behavior of a system with a view to

provide a line of reasoning related to the system con-

sidered (B´ezivin, 2003); changes can be performed in

one or more of these levels (e.g. each instance’s ma-

nipulation is at a lower modeling level for the class

concept). (ii) Abstraction level (a

to a

)- is used

to address complex problems by deﬁning appropriate

levels of abstraction for relegation of irrelevantdetails

to a lower level with a view to restrict the semantic in-

formation (Oussalah et al., 2014) (e.g. reﬁning classes

to subclasses would be helpful and effective measures

for designers).

2.1.2 Object of Evolution

Means the subject on which the evolution is operated.

Object can be:(i) Artifact- an abstraction of any ele-

ment belonging to the architectural structure (archi-

tecture, component, service...), for example, when a

change is performed on a component port of an archi-

tecture (user interface, shared variable, ...), the evo-

lution is basically made on the artifact itself (compo-

nent). (ii) Process- an abstraction of all isolated or

combined operations or methods to be applied to a

process, e.g. installation of a new strategy in terms of

rules and constraints.

2.1.3 Operating Mechanism of Evolution (OME)

Outline the fashion in which an object of evolution

is involved over the different hierarchical levels con-

sidered during the evolution of the architecture. Two

main operating mechanisms can be identiﬁed accord-

ing to (Brooks, 1989): (i) Reduce- Brooks deﬁnes

the ”reductionist” approach as a ”classical” approach

to problem solving whereby the overall resolution

task is decomposed into subtasks. During this re-

ductionist evolution, the operating mechanism goes

through a pre-deﬁned evolution path, until the so-

lution is satisﬁed (evolved model) (e.g. the evo-

lution of classes impacts the instances). Distinc-

tions can be made in terms of three major cases: (a)

the reduction operating mechanism can involve sev-

eral modeling levels (Modeling level reduce) or only

one modeling level either over (b) several abstraction

levels(Inter-abstraction level reduce) or also only (c)

one abstraction level (Intra-abstraction level reduce).

(ii) Emergence- In contrast, during an ”emergentist”

evolution approach, the activity builds the path to

a solution. Indeed, the emergence exposes a pas-

sage between the activity of ”micro-level” and that of

”macro-level”(e.g. categorization of classes in super-

classes). Modeling level emergence, inter-abstraction

level emergence and intra-abstraction level emer-

gence are identiﬁed in the same way as by the reduce

Evolution Taxonomy for Software Architecture Evolution

125

Figure 1: Operating mechanism across hierarchical levels.

OME (Fig. 1).

2.1.4 Type of Evolution

This dimension is commonly used throughout the

software taxonomy (Williams and Carver, 2010)(Ah-

mad et al., 2014)(Buckley et al., 2005) but with dif-

ferent perceptions. The ﬁrst embodies the behavioral

aspect of maintainability according to type of main-

tenance. Meanwhile, the second type of evolution

focuses on the development environment being used

during the evolution (static, dynamic or load-time). In

this light, the evolution type has to be considered from

two relevant perspectives to achieve a reasonable as-

sessment. The ﬁrst concerns a technical view which

applies the notion of maintainability (corrective, per-

fective, adaptive and preventive). For the sake of sim-

plicity, this paper employs the following well known

categories: corrective, perfective and adaptive (Swan-

son, 1976). The second perception adopts an archi-

tectural viewpoint which mainly considers architec-

ture as an artifact of evolution (Chaki et al., 2009).

It expresses the reason for supporting and conduct-

ing software changes whether after (curative) or be-

fore (predictable) software delivery, regardless of the

technical type used.

(i) Curative- ensures that when new requirements

arise unpredictably or were poorly deﬁned or even un-

speciﬁed during the life cycle, the environment will

help to correct, perfect and adapt them by integrat-

ing the desired changes. Usually, the curative type

depends on the nature of problem that is being ad-

dressed, mainly in relation to its context and the re-

source deployed, and often is applied in an ad-hoc

manner as problems arise.

(ii) Predictable- ensures that evolution requirements

are taken into account during the analysis phase and

speciﬁed during the design. These requirements are

speciﬁed at an earlier stage of the design process and

deﬁne all anticipated changes allowed using any tech-

nical types for evolution. The latter can be divided

into two main categories depending on the architects

view: according to the predeﬁnition of the ﬁnal ar-

chitecture (Chaki et al., 2009) and depending on the

continuity of the evolved architecture (Oussalah et al.,

Figure 2: Type of evolution sub-dimensions.

1999). The ﬁrst category emphasizes two types of

evolution: (a) Open evolution- means a deduction,

from an initial architecture, of a new architecture re-

ﬂecting a system solution in which a set of invariants

and constraints are respected. (b) Closed evolution-

the ﬁnal architecture is considered as a premise. This

evolution consists of performing a valid sequence of

operations which, once they are applied to architec-

ture, lead without any ambiguity to the ﬁnal architec-

ture. This involves oriented knowledge construction

and requires a greater capacity of conceptual thinking.

The second category provides two kinds of evolution:

applied directly to the initial architecture without hav-

ing the ability to go back on the trace of the made

evolution (e.g. evolution by extensibility (open white

box), changes are performed directly on codes). (d)

Evolution with seamless- denotes an evolution with

trace where the architecture keeps a trace of its ini-

tial properties and operations performed before each

evolving operation. Such continuity is ensured by the

backup of the applied operation sequences (e.g. in

versioning technique, operations undertaken on ver-

sions are imperatively stored, which in turn preserves

the evolution history). In fact, open or closed types

of evolution can be either with break or seamless

(Fig. 2).

2.2 Evolution Taxonomy

The taxonomy allows presentation of the whole

solution space of architecture evolution. The pro-

posed taxonomy is based successively on the OME

dimension and on the modeling and abstraction levels

of the architecture affected during the evolution

activity. During evolution process, each OME

(reduce or emergent) can either impacts at least two

modeling levels of the architecture (modeling levels)

or preserving the same modeling level. In such case,

the OME should be speciﬁed whether it concerns

different abstraction levels (inter-Abstraction) or

simply evolved within the same level of abstraction

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

126

Figure 3: Architecture involvement through operating

mechanisms.

(intra-abstraction). Thereby, the evolution taxonomy

is structured around six classes for software architec-

ture evolution, as follows:

Intra-abstraction Level Reduce Oriented Evolu-

tion (class 1)- The OME consists of evolving one

or more architectural elements, of an architecture

sited at a deﬁned modeling level, within the same

abstraction level (e.g. modiﬁcation of one or more

component properties of an architecture).

Inter-abstraction Level Reduce Oriented Evolu-

tion (class 2)- The OME consists of evolving one

or more architectural elements sited at a deﬁned

modeling level, from their associated abstraction

level to the lower abstraction levels (e.g. evolution of

class impacts several sub-classes).

Modeling Level Reduce Oriented Evolution

(class 3)- The OME consists of evolving one or more

architectural elements on a downward modeling path

i.e. from their initial modeling level to the lower

modeling levels (e.g. evolution of classes impacts

instances).

Intra-abstraction Level Emergence Oriented

Evolution (class 4)- The OME consist of emerging

one or more architectural elements, of an architecture

sited at a deﬁned modeling level, within the same

abstraction level (e.g. categorization of classes by

creating a superclass).

Inter-abstraction Level Emergence Oriented

Evolution (class 5)- The OME consists of emerging

one or more architectural elements, belonging to

one deﬁned modeling level, from their associated

abstraction level up to the higher abstraction levels

(e.g. aggregation of classes in one class).

Modeling Level Emergence Oriented Evolution

(class 6)- The OME of evolution consists, on upward

path, of emerging one or more architectural elements

from their associated modeling level to the higher

modeling levels (e.g. creation of new classes to deal

with differences on multiple instances).

3 QUALITY EXPECTATION FOR

AN EVOLUTION MODEL

Expectancy indicates that better effort will result in

better performance (Vroom, 1964). Qualitative ex-

pectancy assumes that researchers have reasons for

favoring one set of conscious criteria over others. In-

deed, an architectural evolution model is operated to

satisfy a set of subjectivefactors to achievesome valid

goals. We are focused on devising a set of quality

criteria for a new evolution approach. We have esti-

mated that these are the minimum expected according

to an architectural point of view. However, these cri-

teria must not be interpreted as a restriction on quality

factors but rather as the common speciﬁc criteria for

our topic. Therefore, according to (Oussalah et al.,

1999), an evolution approach must be: (i) enunciated

to better provide a thorough behavior for the changes,

(ii) expressed to better outline the development and

reﬁnement characteristics of the desired model, and

ﬁnally, (iii) evaluated from the fact that the evolu-

tion model provides a set of quality appraisal criteria

aimed to estimate the relevance of the model com-

paratively to a goal commitment. Thus, quality ex-

pectancy can be structured into three capacities: Q

and Q

respectively for the enunciation, expres-

siveness and evaluation capacities. Furthermore, a

model of evolution can be evaluated to indicate its

representativeness expectancy, which means the per-

centage to which the evolution quality has met the ex-

pected quality criteria. These percentages can be used

as an indicator tool for assessing the evolution quality

of a model.

3.1 Enunciation Capacity

Enunciation is formalized in terms of criteria to: for-

mulate, manage the impacts of changes and keep track

between the starting model (before changes) and the

ﬁnal model. This capacity encompasses criteria of:

Formulation of evolution (F)- which reﬂects the level

of evolution visibility in terms of applying operators

to cause the initial architecture to evolve. Impact

management of the evolution (I)- means the result due

to the change of an architectural element of the model

in terms of inﬂuence on the other elements. Trace-

ability (T)- formalizes the model’s ability to keep

track of the sequence of evolution operations applied

for changing an initial architecture. The enunciation

capacity (Q

) can be expressed through a parametric

equation given by:

a× F(p) + b× I(p) + c × T(p)

a+ b+ c

(1)

Evolution Taxonomy for Software Architecture Evolution

127

Where parameter p is the degree of parameterization

for criterion. Coefﬁcients a, b and c are the associ-

ated weights by which we can establish a hierarchical

order of preference between criteria.

3.2 Model Expressiveness Capacity

This capacity indicates what this model is actually

capable of describing regarding the evolution of ar-

chitecture. Modeling level (M)- appoints the differ-

ent modeling levels affected during the OME. It can

be ﬂat trend in the case of an evolution on the same

modeling level, otherwise it affects different model-

ing levels to achieve the result. Abstraction level (A)-

deﬁnes the degree of reﬁnement within an evolution

in terms of the internal architecture details during the

reuse time. These details are presented in a white,

gray or black box. Expressiveness mode (E)- reﬂects

the chosen representation to express the model evolu-

tion. This criterion focuses on accuracy and simplic-

ity of expression and offers more semantics to enable

reuse. Operating mode (O)- prescribes the mode of

reasoning by which the evolution is managed. This

can be done by deduction or by induction or by clas-

siﬁcation. Domain (D)- represents the scope cov-

ered by the solution of the evolution model. In fact,

a generic domain means that multiple situations are

likely to adopt this solution without giving details of

their execution. In counterpart, the speciﬁc domain

provides a further investment of multiple aspects of

details to enable the architecture to evolve. The ex-

pressiveness capacity can be expressed by:

= (a × M(p) + b× A(p) + c× E(p)

+ d × O(p) + e × D(p))/(a + b+ c+ d+ e) (2)

3.3 Quality Evaluation Capacity of an

Evolution Model

The third dimension reﬂects the ability to measure the

capacities of the model to assess its quality, through:

Re-usability (R)- represents the degree of re-use given

by a model of evolution. Adaptability (A)- expresses

the ability to control and enable an evolution model

to be adapted dynamically. Performance (P)- de-

ﬁnes the faculty of the model to make the desired

changes by optimizing time, cost, space and speed ra-

tios. Support of evolution (S)- describes if the evo-

lution model has an predeﬁned or implemented tools

for the used evaluation mechanism. The evaluation

capacity can be formulated as:

a× R(p) + b× A(p) + c× P(p) + d× S(p)

a+ b+ c+ d

(3)

Application Example: For the simplicity of under-

standing the example, some assumptions are made:

(i) for handling criteria values, numerics 1, 0.5 and

0 are assigned respectively to explicit, implicit and

not recognized criteria, (ii) the common associated

weights used in each equation such as a, b ,c, .., d

have been set to 1, (iii) parameters p- are considered

equivalent for simplicity of calculation, thus equal

values have been assigned to each one of them, and

(iv) representativenessratio is in the range of three in-

tervals: 0 ≤ weak < 1/3 ≤ medium < 2/3 ≤ high ≤ 1.

Prospection of the paper by (Oussalah et al., 2006) led

to the following criteria results: enunciation capac-

ity (F=1, I=1, T=0), expressiveness capacity (M=1,

A=0.5, E=1, O=1, D=1) and evaluation quality capac-

ity (R=1, A=1, P=1, S=0). Then applying equations

(1),(2), (3) results: Q

= (1× 1+ 1× 1+ 1 × 0)/3 =

0.67; Q

= (1 × 1 + 1 × 0,5 + 1 × 1 + 1 × 1 + 1 ×

1)/5 = 0.90; Q

= (1× 1+ 1×1+1×1+1× 0)/4=

0.75. The quality expectancy given by the capacities:

Q(Oussalahet al.,2006) = (0,66+0,90+0,75)/3=

0.77 which means that the model presents a high rep-

resentativeness for software architecture evolution.

4 PROPOSAL ASSESSMENT

Substantially, selection of papers focused on: (i) pa-

pers studying either a software architecture evolution

or software engineering evolution thematic, or both of

these, and (ii) according to two potential criteria: ﬁrst,

papers used within other classiﬁcations research, and

second, well known papers using the indicator cited

index paper. The preparation of the review was done

through devising a prospective study sheet in accor-

dance with (Wohlin et al., 2012). Once the appropri-

ate information had been gathered, calculations were

conducted as shown in the previous example. After-

ward, representativenessexpectancy was assessed and

studies with a weak expectancy were removed. Fi-

nally, 67 selected papers were selected that to the best

of our knowledge are the most representative studies

in the ﬁeld.

4.1 Evolution Mechanism Categories

In order to provide clariﬁcation and therefore wider

understanding of the proposed taxonomy, the selected

papers were divided into ﬁve thematic categories to

reﬂect the broadest range of well known mechanisms

for dealing with evolution. Each category includes

mechanisms that share conceptually low close reﬂec-

tions regardless of the technique used for modeling

(static or dynamic):

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

128

(i) Evolution Change-based Approaches (Gott-

lob et al., 1996)(Bengtsson et al., 2004)(Oreizy

et al., 1999)- encompass work related to: (i)

Maintainability- reﬂects changes into software after

its implementation, (ii) Modiﬁability- describes the

architectures ability to be changed in response to

changes due to the environment or stockholder re-

quirements or functional speciﬁcations, and (iii) Self-

changes- comprise automation in computing which

refers to execution of important computing opera-

tions. It includes: automatic computation, self-

management, self-organization, self-adaptive.

(ii) Evolution Algorithmic-based Approaches (En-

gel and Browning, 2008)(Wermelinger and Fiadeiro,

2002)- include all reﬂections for improving software

architecture by providing simple structures, deal-

ing with similarity of objects. It contains mecha-

nisms of categorization, reorganization, incremental

approaches and refactoring.

(iii) Evolution Trace-based Approaches (Cicchetti

et al., 2008)(Herrmannsdoerfer et al., 2009)- includes

mechanisms where traceability is seen as a key insight

for evolution to promote consistency and compliance.

This category encompasses mechanisms related to:

migration, co-evolution, versioning and view-point.

(iv) Evolution Transformation based Approaches

(Zhao et al., 2007)(Engels and Heckel, 2000)- in-

clude mechanisms wherein changes are applied us-

ing one or more transformation rules for transform-

ing or verifying or validating models (Mens and

Van Gorp, 2006). Model driven architecture ap-

proaches and graph-transformation approaches are

approaches dealing with such topics.

(v) Evolution style based approaches (Garlan et al.,

2009)(Le Goaer et al., 2010)- designate high-level

modeling approaches, using architectural style for

modeling the evolution. Evolution-styles help to

specify the basic structure to evolve in software ar-

chitecture.

4.2 Results and Discussion

Results are discussed according to:

(i) Framework Dimensions: Investigated papers

were compared to the framework using the represen-

tativeness percentage, which represents the quotient

of the number of explicit and implicit (weighted) ex-

pressions of criteria relatively to the total number of

papers within a category. Afterwards, percentages

were reported in the Table 1, in which: Explicitly,

overall the studied evolution mechanisms focus on:

(i) the artifact as an object of evolution with more than

70%, to the detriment of the process object, which re-

mains a very promising direction (minus 30%), par-

Table 1: Representativeness of the framework dimensions.

Framework dimensions Metrics %

Object of evolution

Artifact 71.64

Process 28.36

Level of evolution

Modeling 67.76

Abstration 32.24

OME of evolution

Reduce 89.56

Emergence 10.44

Type of evolution

Technical 55.33

Architectural 44.67

ticularly because the process is usually considered as

a dynamic speciﬁcation of the artifact, without ne-

glecting that the artifact provides an advantageous al-

ternative through UML modeling speciﬁcations, (i)

abstraction level has attracted less interest (nearly

33%) from the evolution community for the reason

that it overlaps with the modeling level concept, (iii)

the ”Reduce” OME is the most covered, scoring more

than 89% as against 11% for the ”Emergent”, mainly

due to the developer opting for rigorous mathemati-

cal reasoning based on a formal logic, which favors

the deduction process, and (iv) technical type (55%)

is relatively better represented than architectural type.

The study has also found an overwhelmingrate for the

”Predictable” type (97%), absolutely justiﬁed by the

rough dynamicity of the environment and the instabil-

ity of stakeholder requirements at the different mod-

eling levels, with an advantage for the ”Open” type

of more than 70%. In addition, the study indicates

that almost 80% of the selection are devoted to cor-

rective and perfective typology. It should furthermore

be noted that adaptability produced a low represen-

tation percentage (less than 20%), mainly due to the

difﬁculty of dynamic evolution at the design-time.

(ii) Evolution Taxonomy: Evolution mechanisms

were ranked according to the suggested taxonomy

with the aim of assessing the cover achieved by each

category of mechanisms and to deduce the least con-

sidered taxonomy classes. By using the percentage of

representativeness in the same way as described pre-

viously, Table 2 displays the different hedging of each

mechanism and clariﬁes that existing studies have

fostered the modeling-level reduce oriented evolution

class (class 3), with trace-based approaches being the

most signiﬁcant in 68% of the work. The 14% of stud-

ies in intra-abstraction level reduce oriented evolution

(class 1) is justiﬁed by the presence of techniques sup-

porting quality, assessment, and analysis at the archi-

tectural level. Classiﬁcation of the selection reveals a

Table 2: Class percentages of evolution taxonomy.

C-1 C-2 C-3 C-4 C-5 C-6

14.93 5.97 68.66 5.96 1.49 2.99

Evolution Taxonomy for Software Architecture Evolution

129

Table 3: Criterion and capacity percentages (%).

enunciation

=22.60 Q

expressiveness

= 54.29 Q

evaluation

=23,11

F I T M A E O D R A P S

11.80 6.16 4.64 12.51 6.56 12.21 10.90 12.11 6.66 5.95 6.26 4.24

signiﬁcant shortage in research focusing on the emer-

gence OME.

(iii) Quality Expectancy: This evaluation can rule

on potential strengths and weaknesses of each cate-

gory of the architectural evolution mechanisms. Ta-

ble 3, which presents the percentage of representa-

tiveness of a quality criterion across all the studied

papers, shows that for the studied models the appro-

priateness of the measurement formulation capacity

for the enunciation dimension is the most respected

aspect in terms of the fact that all the selected works

were revised and published. Traceability capacity had

the weakest representation, possibly because of the

priority that approaches attach to ﬁnding a new so-

lution. Regarding the expressiveness capacities, all

modeling levels were covered, from the lowest level

) to the meta-modeling level(M

). However, a

weak separation between modeling and abstraction

levels was formulated (almost 32%). Expressiveness

mode, operating mode and domain applicability are

strongly expressed criteria in the studied models. In

addition, evaluation criteria are considered in a less

rigorous manner in the selection, by which we de-

duce that the ﬁeld of architectural evolution has not

yet reached a sufﬁcient level of saturation and matu-

rity to focus primarily on quality evaluation. Never-

theless, the research displays more consideration of

re-usability criterion, and to a lesser extent of adapt-

ability and performance criteria, while the support of

quality assessment tools proposed by approaches re-

mains a very promising track. Table 4 sets out the

representativeness percentage of the expected qualita-

tive capacities for each evolution mechanism. On this

basis, the main ﬁndings are as follows: (i) the trans-

formation based approaches present the higher enun-

ciation ratio in comparison to the other categories, due

essentially to its great ability for traceability and for-

malization, (ii) the algorithmic-based approaches fo-

cus largely on criteria related to expressivenesscapac-

Table 4: Capacity percentages by mechanism category.

Evolution mech. (%) Q

Enun

Expr

eval

Change-based 20,77 54,62 24.62

Algorithmic-based 20.99 57.41 21.60

Trace-based 21.47 55.21 23.31

Transformat-based 30.77 55.38 13.85

Style-based 23.75 51.91 24.34

Average 22.60 54.29 23.11

ity through the operating and expressiveness modes,

domain of speciﬁcation and modeling level identiﬁ-

cation, and (iii) throughout all categories, there is in-

sufﬁcient representation of quality evaluation capac-

ity which denotes slightly higher representation of

change based and style-based approaches.

5 CONCLUSION

The ﬁrst goal of this study was to devise a framework

for software architecture evolution. This framework

attempts to provide a structural organization which,

while far from considering qualitative speciﬁcations,

is organized in four main dimensions: levels, ob-

ject, type and operation mechanism of evolution. The

evolution taxonomy, as a second goal, offers a land-

scape of what was being done and what remains to

be done. It has unveiled a lack of emergence ap-

proaches. The third goal was to deal with the real

challenge of achieving representativeness of a given

evolution model in the ﬁeld. The paper recapitulated

a large number of quality criteria crucial to evalua-

tion of effectiveness of the effort-making in terms of

devising a model that meets the quality expectations.

The latter were arranged into the following three im-

portant capacities: enunciation, expressiveness and

quality evaluation. The results shows that criteria re-

lated to expressiveness are often given more weight as

opposed to enunciation and evaluation quality. Like-

wise, our study limitation relates to the estimation of

qualitative criteria either in terms of assigning a par-

ticular value for each criterion (explicit and implicit)

or in terms of adopting an equal weight value for pa-

rameters over all criteria. Thus, we believe that the

conceptual framework that we have presented could

be applied in future studies to: (i) determine the ap-

propriate evolution approach according to the crite-

ria that seem the most relevant, (ii) highlight how the

quality criteria of an evolution approach would inﬂu-

ence its representativeness, and (iii) provide guidance

in particular research ﬁelds, such as the study of emer-

gent operating mechanisms. Moreover, future studies

could use the proposed framework to explore many

of the research papers investigated by previous taxo-

nomic studies in the software engineering domain. In

this light, it would be invaluable to provide a meta-

classiﬁcation which could be instantiated according

to the ﬁeld specialization.

ENASE 2016 - 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering

130

REFERENCES

Ahmad, A., Jamshidi, P., and Pahl, C. (2014). Classiﬁca-

tion and comparison of architecture evolution reuse

knowledgea systematic review. Journal of Software:

Evolution and Process, 26(7):654–691.

Amirat, A., Menasria, A., and Gasmallah, N. (2011). Evolu-

tion framework for software architecture using graph

transformation approach.

Bengtsson, P., Lassing, N., Bosch, J., and van Vliet,

H. (2004). Architecture-level modiﬁability analysis

(alma). Journal Syst.and Software, 69(1):129–147.

B´ezivin, J. (2003). La transformation de mod´eles. INRIA-

ATLAS & Universit de Nantes, 2003. Ecole dEt dIn-

formatique CEA EDF INRIA 2, cours #6.

Breivold, H. P., Crnkovic, I., and Larsson, M. (2012).

A systematic review of software architecture evolu-

tion research. Information and Software Technology,

54(1):16–40.

Brooks, R. A. (1989). A robot that walks; emergent behav-

iors from a carefully evolved network. Neural compu-

tation, 1(2):253–262.

Buckley, J., Mens, T., Zenger, M., Rashid, A., and Kniesel,

G. (2005). Towards a taxonomy of software change.

Journal of Software Maintenance and Evolution: Re-

search and Practice, 17(5):309–332.

Chaki, S., Diaz-Pace, A., Garlan, D., Gurﬁnkel, A., and

Ozkaya, I. (2009). Towards engineered architecture

evolution. In Proceedings of the 2009 ICSE Work-

shop on Modeling in Software Engineering, pages 1–

6. IEEE Computer Society.

Cicchetti, A., Di Ruscio, D., Eramo, R., and Pierantonio, A.

(2008). Automating co-evolution in model-driven en-

gineering. In Enterprise Distributed Object Comput-

ing Conference, 2008. EDOC’08. 12th International

IEEE, pages 222–231. IEEE.

Engel, A. and Browning, T. R. (2008). Designing systems

for adaptability by means of architecture options. Sys-

tems Engineering, 11(2):125–146.

Engels, G. and Heckel, R. (2000). Graph transformation as

a conceptual and formal framework for system mod-

eling and model evolution. In Automata, Languages

and Programming, pages 127–150. Springer.

Garlan, D., Barnes, J. M., Schmerl, B., and Celiku, O.

(2009). Evolution styles: Foundations and tool sup-

port for software architecture evolution. In Software

Architecture, 2009 & European Conference on Soft-

ware Architecture. WICSA/ECSA 2009. Joint Working

IEEE/IFIP Conference on, pages 131–140. IEEE.

Gottlob, G., Schreﬂ, M., and R¨ock, B. (1996). Extending

object-oriented systems with roles. ACM Transactions

on Information Systems (TOIS), 14(3):268–296.

Herrmannsdoerfer, M., Benz, S., and Juergens, E. (2009).

Cope-automating coupled evolution of metamodels

and models. In ECOOP 2009–Object-Oriented Pro-

gramming, pages 52–76. Springer.

Jazayeri, M. (2005). Species evolve, individuals age. In

Principles of Software Evolution, Eighth International

Workshop on, pages 3–9. IEEE.

Le Goaer, O., Tamzalit, D., and Oussalah, M. (2010). Evo-

lution styles to capitalize evolution expertise within

software architectures. In SEKE 2010, pages to–

appear.

Mens, T. and Van Gorp, P. (2006). A taxonomy of model

transformation. Electronic Notes in Theoretical Com-

puter Science, 152:125–142.

Oreizy, P., Gorlick, M. M., Taylor, R. N., Heimbigner, D.,

Johnson, G., Medvidovic, N., Quilici, A., Rosenblum,

D. S., and Wolf, A. L. (1999). An architecture-based

approach to self-adaptive software. IEEE Intelligent

systems, 14(3):54–62.

Oussalah, M. et al. (1999). G´enie objet: analyse et concep-

tion de l’´evolution. Herm`es Science publications.

Oussalah, M. et al. (2014). Architectures logicielles :

Principes, techniques et outils. Hermes Science Pub-

lications (12 fvrier 2014).

Oussalah, M., Sadou, N., and Tamzalit, D. (2006). Saev:

A model to face evolution problem in software archi-

tecture. In Proceedings of the International ERCIM

Workshop on Software Evolution, pages 137–146.

Perry, D. E. and Wolf, A. L. (1992). Foundations for the

study of software architecture. ACM SIGSOFT Soft-

ware Engineering Notes, 17(4):40–52.

Swanson, E. B. (1976). The dimensions of maintenance.

In Proceedings of the 2nd international conference

on Software engineering, pages 492–497. IEEE Com-

puter Society Press.

Vroom, V. H. (1964). Work and motivation. new york: John

willey & sons.

Wermelinger, M. and Fiadeiro, J. L. (2002). A graph

transformation approach to software architecture re-

conﬁguration. Science of Computer Programming,

44(2):133–155.

Williams, B. J. and Carver, J. C. (2010). Characterizing

software architecture changes: A systematic review.

Information and Software Technology, 52(1):31–51.

Wohlin, C., Runeson, P., H¨ost, M., Ohlsson, M. C., Reg-

nell, B., and Wessl´en, A. (2012). Experimentation in

software engineering. Springer Science & Business

Media.

Zhao, C., Kong, J., Dong, J., and Zhang, K. (2007).

Pattern-based design evolution using graph transfor-

mation. Journal of Visual Languages & Computing,

18(4):378–398.

Evolution Taxonomy for Software Architecture Evolution

131