Evolution Style Mining in Software Architecture

Kadidiatou Djibo

1,2

, Mourad Oussalah

and Jacqueline Konate

LS2N - UMR CNRS 6004, Nantes University, 110 Bd Michelet, Nantes, France

Faculty of Sciences and Techniques, USTTB University, Bamako, Mali

Keywords:

Software Architecture, Evolution Style, Mining, Pattern, Sequence, Process, Data Mining.

Abstract:

Sequential pattern extraction techniques are applied to the evolution styles of an evolving software architecture

in order to plan and predict future evolution paths for the architecture. We present in this paper, a formalism

to express the evolution styles in a more practical way. Then, we analyze these collected styles from the

formalism introduced by the techniques of sequential patterns extraction to discover the sequential patterns of

software architecture evolution. Finaly, from the analysis results, we develop a learning base and prediction

rules to predict future evolution paths.

1 INTRODUCTION

Software systems become more complex day after

day, and integrate many components. Thus, some re-

search has focused on planning and predicting soft-

ware evolution (Bhattacharya et al., 2012), (Goulão

et al., 2012). However, software architectures go

hand in hand with the software products they docu-

ment, they evolve together and constantly. Although

a lot of works have been directed towards the prob-

lem of reusing the evolution of software architectures

( (Cuesta et al., 2013), (Ahmad et al., 2012)), little

work has focused on the problem of planning and pre-

dicting the future evolution of software architectures.

The majority of research efforts focused on the speci-

ﬁcation, development, deployment of software archi-

tectures (Smeda et al., 2005) and the analysis, de-

sign and reuse of the software architectures evolution

((Sadou, 2007), (Hassan and Oussalah, 2018)). But

little works, to our knowledge, are devoted to plan-

ning and predicting future evolution in software ar-

chitectures.

From previous evolution data of an evolving ar-

chitecture over time A

to A

, the problem is to deter-

mine the recurrent evolution sequences, the architec-

tural elements most or least affected in order to iden-

tify and propose the possibilities and skills required to

move towards A

n+1

. To achieve this goal, the evolu-

tion style approach introduced in order to make the

software architectures evolution process reusable is

reused. the aim of this paper, is to extract software ar-

chitectures evolution sequential patterns, to plan and

predict future evolution paths. Thus, following pre-

vious software architectures evolutions, libraries of

evolution styles are built, from which software archi-

tectures evolution sequential patterns are extracted.

A meta-model of evolution style is proposed, it will

be endowed with a simple formalism to express the

evolution styles with more convenience. Data min-

ing techniques are applied to the evolution styles ex-

pressed to extract the sequential patterns, then a learn-

ing base is developed to predict the future architecture

evolution paths and evaluate the proposed paths. In-

deed, the principles of sequential patterns extraction

is used on software architectures evolution styles ex-

pressed through the deﬁned formalism in order to de-

termine the recurrent evolutions, the most or least af-

fected architectural elements and the actors participa-

tion rate in operations during these architectural evo-

lutions. By analogy with the approach of Agrawal

et al. in (Agrawal and Srikant, 1995), data (the evo-

lution styles expressed) is reorganized into a seven-

ﬁeld table where, is associated to an architectural el-

ement the date of evolution operation undergone, the

name, the evolution style header. From this table, an

algorithm to deﬁne evolution sequences by architec-

tural element is deﬁned, then the sequential patterns

that deﬁne the recurrent evolution sequences are de-

termined. Another algorithm was deﬁned, based on a

database of evolution sequences, it determines the ar-

chitectural elements evolution rate and the actors par-

ticipation rate in evolution operations.

The sequential patterns extraction is a very impor-

tant area of data mining. It has been used in sev-

Djibo, K., Oussalah, M. and Konate, J.

Evolution Style Mining in Software Architecture.

DOI: 10.5220/0009349203130322

In Proceedings of the 15th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2020), pages 313-322

ISBN: 978-989-758-421-3

313

eral studies on speciﬁc types of data including the

web (Wu and Chen, 2002), music (Hsu et al., 2001),

software engineering (Amaral et al., 2014), ontology

(Javed et al., 2011), medicine (Wright et al., 2015).

However, the main challenge in extracting sequential

patterns is related to the high costs of processing due

to the large amount of data. Thus different algorithms

have been proposed in previous studies to optimize

data processing costs to determine sequential patterns

(Agrawal and Srikant, 1995), (Srikant and Agrawal,

1996) (Mooney and Roddick, 2013).

This paper is organized as follows: Section 2

presents the state of the art of software architecture

evolution styles and knowledge extraction from data

(data mining). In Section 3, we present the evolu-

tion style meta-model and the new formalism that we

introduced to express evolution styles with more con-

venience. Section 4 presents the data analysis, we ap-

ply the mining sequential patterns techniques to the

data expressed according to the formalism introduced

through a case study. Finally in section 5, we con-

clude and give the perspectives of our work.

2 STATE OF THE ART

Some existing work related to software architecture

evolution styles and data mining are presented below.

2.1 Software Architecture Evolution

Style

An evolution style captures a characteristic way of

evolving all or part of a software architecture. It

serves as a guide for an architect who must conform

to the style (Le Goaer, 2009). Evolution styles aim to

make the evolution activity reusable to prevent archi-

tects from starting from scratch with each evolution

activity. They promote knowledge sharing but also

learning and knowledge extraction. We present some

team approaches. According to (Garlan, 2008), an

evolution style expresses the evolution of software ar-

chitecture as a set of potential evolution paths from

the initial architecture to the target architecture. Each

path deﬁnes a sequence of evolution transitions, each

of which is speciﬁed by evolution operators. The

team (Cuesta et al., 2013) has deﬁned evolution styles

based on architectural knowledge (AKdES), which

are also based on architecture design decisions each

time an evolution step is made. Each stage of evolu-

tion is preformed because a decision of evolution is

taken following the veriﬁcation of a decision of evo-

lution. According to (Oussalah et al., 2008), the main

idea of an evolution style is to model software archi-

tecture evolution activity in order to provide reusable

expertise of domain-speciﬁc evolution. They consider

an architectural evolution as consisting of modiﬁca-

tions (addition, update, deletion) of architectural ele-

ments (component, connector, interface).

2.2 Extracting Knowledge from Data

(Data Mining)

Extracting knowledge from data (data mining) has

been used in many areas to ﬁnd patterns to solve

decision-making or future projection problems in

companies. We then present some work done in

this direction. Agrawal et al. (Agrawal and Srikant,

1995), introduced the sequential pattern discovery

problem. From a database of client transactions,

they deﬁne a sequence database where each sequence

represents all the items purchased during a transac-

tion. It was a question of discovering all the se-

quential patterns with a speciﬁed minimum support.

They deﬁned three algorithms to solve the problem

including the AprioriAll, AprioriSome and Dynamic-

Some algorithms. In 1996, the same team proposed

an improvement of the previous result, they present

the GSP algorithm for the discovery of generalized

sequential patterns. A performance evaluation per-

formed in (Srikant and Agrawal, 1996) indicates that

GSP is performing better than AprioriAll presented

in (Agrawal and Srikant, 1995). (Javed et al., 2011)

study the change of ontology. They analyze ontology

change logs represented as graphs to determine fre-

quent and recurring changes. These frequent and re-

curring changes are identiﬁed as patterns of change

that can be reused. For this, they introduced two

algorithms to determine ontology change patterns,

which are the algorithm for searching complete and

ordered change patterns (OCP) and the search algo-

rithm for complete and unordered change patterns (

PCU). They then performed a performance study of

the two algorithms to determine the different limita-

tions.

The new model that we introduce to express and

analyze software architectures evolution styles in or-

der to predict and plan future evolutions of theses is

presented below.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

314

3 META-MODEL AND

SIMPLIFIED EXPRESSION OF

EVOLUTION STYLE

Our goal is to apply mining sequential patterns tech-

niques to software architectures evolution styles in or-

der to discover sequential patterns of architecture evo-

lution, determine the evolution rate of architectural el-

ements and the actors participation rate in the evolu-

tion operations in order to predict and plan the future

evolution of architectures. For this, we must ﬁrst have

a database of evolution styles. Previously, we have

deﬁned a meta-model of evolution style. We extend

it to deﬁne an evolution style as a process (Fig. 1)

by specifying the role, the architectural element and

the operation. Thus, the extended meta-model (Fig.

1) answers the following questions : what ? (what

is evolving ?) through the ArchitectureElement pack-

age, who ? (who did it ?) through the Actor concept,

when ? (when to evolve ?) from the TimeEvolution

concept and how ? (how to make it evolve ?) through

the concepts Header, Competence, Action ands Im-

pact. All the concepts Header, Competence, Action,

Impact deﬁne the operation. Through the class dia-

gram in Figure 1, we highlight the concepts and rela-

tions of our model.

Figure 1: Evolution Style Meta-model.

The evolution style meta-model presented in Figure 1

is described below.

3.1 Description of Evolution Style

Meta-model Concepts

The concept EvolutionStyle is the core of our model,

it encapsulates what allows to describe and apply an

operation of evolution to an architectural element. It

consists of two complementary parts: a header and a

competence. The Header class describes the signa-

ture of the operation. The competence class is split

into Action and Impact. Action is a procedure or

function of evolution that focuses on the evolving ar-

chitectural element. It describes an implementation

unit corresponding to the header. The Impact class

speciﬁes the evolution styles that will be impacted

by the execution of the currently deﬁned style. It al-

lows to establish a relationship between the evolution

styles. The Actor concept deﬁnes the actor, either

a natural person or a program that triggers the oper-

ation. The ArchitectureElement package including

the evolving element and its category allows to model

and reify any signiﬁcant element of an evolving ar-

chitecture. If an architectural concept is an instance

of this class (in the object-oriented sense), then it be-

comes possible to associate evolution styles with it.

In addition, the Category concept allow to share ar-

chitectural elements of the same nature in a class. The

TimeEvolution class indicates the date on which the

evolution operation is performed on the evolving ele-

ment.

It is the role (deﬁned through the Actor concept),

the architectural element and the operation (deﬁned

through the Header, Competence, Action and Impact

concepts) that allow our meta-model to deﬁne an evo-

lution style as a process (Fig. 1).

In the following, we introduce the formalism to

express the evolution styles according to the extended

meta-model (Fig. 1) in order to easily collect them.

3.2 Simpliﬁed Expression of Evolution

Style

While waiting to collect evolution data from software

architectures in order to extract sequential patterns,

we propose a formalism allowing evolution actors to

easily express software architectures evolution styles.

We use the introduced meta-model (Fig. 1) and deﬁne

a formalism that speciﬁes the actor, the architectural

element, the operation and the date of evolution. The

header deﬁned through the Header concept, identiﬁes

the signature of the evolution operation. It is unique,

so we replace the operation by the concept Header

and the architectural element by Element and Cate-

gory. Figure 2 below represents the formalism. This

Figure 2: Simpliﬁed Expression of Evolution Style.

ﬁnal expression (Fig. 2) will allow to name and ex-

press one by one all the evolution styles of an evolving

architecture A

to A

. After expressing all the evolu-

tion styles of the evolving architecture with the sim-

pliﬁed expression, a large amount of Evolution data is

obtained, it can be use to extract the sequential evo-

Evolution Style Mining in Software Architecture

315

lution patterns of software architectures, discover the

architectural elements change rate and the actors par-

ticipation rate in evolution operations in order to plan

and predict all possible paths towards the An+1 archi-

tecture.

We present below our approach to extract the se-

quential patterns of architectural evolution from the

data of evolution styles expressed by the formalism

introduced above.

4 SEQUENTIAL PATTERNS

EXTRACTION OF SOFTWARE

ARCHITECTURES

EVOLUTION

In artiﬁcial intelligence, there are 2 main extrac-

tion techniques, algorithmic and deep learning. We

chose the algorithmic. Referring to the deﬁnitions

in (Agrawal and Srikant, 1995), we deﬁne some con-

cepts that we use for the sequential patterns extraction

of software architectures evolution.

Evolution Sequence: We call an evolution sequence

an ordered sequence of evolution style headers ap-

plied to a given architectural element or performed

by a given actor. The order is established according

to the dates of evolution.

Support: The support of an evolution sequence is the

percentage of appearance of this sequence in the other

evolution sequences.

Sequential Pattern: We deﬁne sequential pattern of

software architectures evolution an ordered sequence

of evolution operations carried out in the same order

on a deﬁned number of architectural elements. This

number deﬁned by the user represents the minimum

support of an evolution sequence to be admitted as a

sequential pattern.

The Sequence Length: is the total number of evolu-

tion style headers contained in the sequence.

An architectural evolution consists of creation (C),

suppression (S) and modiﬁcation (M) of architectural

elements. An architecture can be created (C), sup-

pressed (S), modiﬁed (M) or migrated (Mg). The lat-

ter results in the creation of a new architecture (ad-

vanced version of the previous one). An architec-

ture change (M) consists of adding components (A

adding connectors (A

con

), removing components (S

removing connectors (S

con

) and changing architec-

tural elements. A modiﬁcation of architectural ele-

ments consists of adding ports (C

and C

pcon

), delet-

ing ports (S

and S

Pcon

) and changing ports (M

)

for components and (M

PCon

) for connectors. An ar-

chitectural evolution is an ordered set of evolution

operations carried out on the architectural elements

(modiﬁcation of architectural elements) in order to

reach a targeted result. An evolution style is a pro-

cess that describes an evolution operation carried out

on a given architectural element during an architec-

tural evolution. Thus, an architectural evolution can

be represented by an ordered set of evolution styles.

Based on this principle, we use the formalism intro-

duced to extract the sequential evolution patterns of

architectures in order to deﬁne evolution sequences

by architectural element in a category. To do this, we

reorganize the styles expressed by deﬁning a table in

which we deﬁne in column each element of the for-

malism.

To better explain our approach we refer, pedagog-

ically to the following case study of the evolution of

an initial architecture (deﬁned using components and

connectors) A

to an architecture A

where we apply

sequential pattern extraction techniques to predict the

possibles A

, A

, ..., A

4.1 Case Study

In this case study, we collect existing data on the evo-

lution of the initial architecture A

to A

, we express

them using the meta-model and the simpliﬁed expres-

sion and then we analyze them to predict the architec-

ture A

. Thus, this study is carried out in three phases,

including the expression phase of evolution styles, the

analysis phase of expressed styles and ﬁnally the pre-

diction phase.

4.1.1 The Expression Phase of Evolution Styles

We use the simpliﬁed evolution style expression in-

troduced to express all evolving architecture evolution

styles from the creation of the initial architectural ele-

ments until the last modiﬁcation operation carried on

the last version of this one in order to predict and plan

future developments. We refer to the following Figure

4 of evolution of the architecture A

to A

Figure 3: Evolution of the Architecture A

to A

The architecture A

at the beginning has three com-

ponents C

, C

and C

. Components are connected

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

316

by connectors C

on12

and C

on23

. The software architect

decides to migrate A

to A

by creating the compo-

nent C

and the connector C

on14

. In this case study

we start with two categories of architectural elements

(connector and component). We express the evolution

styles for the creation of the initial components and

connectors of the initial architecture A

and those for

the migration of A

to A

. For reasons of paper size,

we just give some expressions, the whole is given in

table 1.

: < Act1, (C

, Component), A

, 01-05-2017 >. Cre-

ation of the component C

: < Act1, (C

, Component), A

, 02-05-2017 >. Cre-

ation of the component C

: < Act1, (C

on12

, Connector), A

con

, 03-05-2017 >.

Creation of the connector C

on12

: < Act2, (C

, Component), C

, 03-05-2017 >.

Creating a port on the component C

: < Act2, (C

on12

, Connector), C

pcon

, 03-05-2017 >.

Creating a port on the connector C

on12

: < Act3, (C

, Component), M

, 03-05-2017 >.

Modiﬁcation of the port on the component C

to con-

nect C

on12

We get A

after the evolution operations e

to e

. We

analyze below these expressed evolution styles, in or-

der to determine the recurrent style sequences.

4.1.2 Analysis Phase of Expressed Styles

Inspired by (Agrawal and Srikant, 1995), we apply

the techniques of sequential patterns extraction to the

expressed evolution styles in order to determine the

recurrent evolution sequences by category of architec-

tural elements, the rate of change of architectural ele-

ments and the actors participation rate in the evolution

operations. First, we reorganize the data expressed in

a table (Table 1).

Indeed, we are interested in the evolution opera-

tions carried out on the architectural elements of the

same category during an architectural evolution and

the actors associated to these operations. The evo-

lution date allows us to deﬁne the operations in se-

quence by architectural element. After reorganizing

the data, we deﬁne a second table (Table 2) in which,

from the ﬁrst table deﬁned (Table 1), in a given cate-

gory we associate with each architectural element the

evolution sequence corresponding as in Table 2. The

empty sequence () is associated with the element that

has not undergone any evolution operation.

An interpretation of a line from Table 2 would

be: The architectural element C

after its creation has

undergone four evolution operations of header creat-

ing component port C

, component port modiﬁca-

tion M

, creating component port C

and compo-

nent port modiﬁcation M

respectively. From Table

2 we can determine the architectural elements most

or least affected by the length of their evolution se-

quence. The length of the evolution sequence associ-

ated with C

is four, while the length of the sequence

associated with C

is two, we conclude that among

the components C

, C

have undergone more evo-

lution operations. Thus, rules can be developed to

make decisions or draw conclusions. To do this, we

deﬁne an algorithm to compute and associate to each

architectural element its rate of evolution. The archi-

tectural element evolution rate is computed from the

length of its evolution sequence and the total number

of lines in Table 1, i.e. the total number of evolu-

tion styles collected. In the same way in the Table

3 we associate with each architecture its sequence of

evolution, we note that the architecture A

has under-

gone after its creation (C) ten modiﬁcations includ-

ing a component addition A

, connector addition A

con

etc. before migrating (Mg). From the tables Table

2 and Table 3, we determine the support of each se-

quence by category in the following Table 4 in order

to discover the sequential patterns.

We retain as a sequential pattern all evolution se-

quences with a support value greater than twenty-ﬁve

percent (25 %). This value is arbitrary and can be de-

ﬁned by the user. Table 5 represents the sequential

patterns by category of architectural elements.

More than twenty-ﬁve percent (25 % ) of compo-

nents have undergone evolution sequences (C

) and (C

). More than twenty-ﬁve per-

cent (25 % ) of connectors have undergone the se-

quence (C

pcon

). More than twenty-

ﬁve percent (25 % ) of architectures have undergone

the sequence (A

con

pcon

Mg).

The sequential evolution patterns of software ar-

chitectures correspond, in our case, to the sequences

or subsequences of evolution appearing in the evolu-

tion sequences of a number of architectural elements

greater than the minimum support speciﬁed by the

user (k). Thus, to extract them from the Table 2, each

sequence must be compared to all the other evolu-

tion sequences of the table. If a match is detected

its support is incremented. At the end of the table’s

path its support is calculated. All the evolution se-

quences in Table 2 are candidate sequences, i.e. the

associated support must be computed in order to ex-

tract the sequential evolution patterns of software ar-

chitectures. However, during the table run if an evo-

lution sub-sequence is read in another sequence, this

sub-sequence will also be added to the candidate se-

quences. Its support will also be computed. Finally,

all the sequences or subsequences having a calculated

support greater than k are retained as sequential pat-

Evolution Style Mining in Software Architecture

317

terns of software architectures evolution. Given the

amount of evolution data and processing complexity,

it is not easy to extract sequential patterns manually.

Thus, we propose an algorithm allowing to extract the

sequential patterns from any organized table like the

Table 2 whatever the quantity of data. But the main

challenge in deﬁning sequential pattern extraction al-

gorithms is the high cost of processing due to the high

amount of data (Chiu et al., 2004). Many studies have

been carried out in this context, proposing efﬁcient

and effective algorithms for the sequential patterns

extraction (Agrawal and Srikant, 1995), (Srikant and

Agrawal, 1996) (Chiu et al., 2004) (Mahajan et al.,

2014). Thus, our objective is centered on the sequen-

tial patterns extraction of software architectures evo-

lution. Inspired by this work already done to opti-

mize algorithms for extracting sequential patterns, we

try to propose computer algorithms to extract our se-

quential patterns of software architectures evolution

from our data formats deﬁned (Ex Table 2), compute

the evolution rate of an architectural element and the

participation rate of an actor in evolution operations.

4.1.3 Prediction Phase

To propose the possibles A

n+1

(the possibles A

for

this case study) to the architect, we develop a learn-

ing base (Figure 3 and Figure 5 below). We load the

Table 2, Table 3 and Table 5 tables resulting from the

analysis carried out in the previous phase. Figure 5

below provides an overview of the learning base.

Figure 4: Learning and Prediction.

We deﬁne some rules for prediction. The rules are

dynamic, they can be modiﬁed by the architect. We

distinguish four categories of rules: the structural evo-

lution rules, the behavioral evolution rules, the invari-

ant evolution rules and the business evolution rules.

Structural evolution rules refer to the evolution of the

structure of architectural elements. Behavioural evo-

lution rules refer to the way in which the behaviour of

architectural elements has evolved. The invariant evo-

lution rules guarantee properties on architecture and

its architectural elements. Business evolution rules

affect the costs (price, quality) and time (lifetime) of

element evolution. We give some examples of rules

by category.

Structural Evolution Rules

Rule 1

We deﬁne the notion of connectability of a compo-

nent. A component is said to be connectable if it is

possible to connect it to another component via a con-

nector. Indeed, the components contain the property

of number of ports (variable and deﬁnable by the ar-

chitect), if the number of existing connections reaches

the number of port of the component, it becomes not

connectable. Thus its status can switch to connectable

as soon as one of its ports is released following a dele-

tion or a modiﬁcation. The number of ports is spec-

iﬁed in the component properties. An unconnectable

component will not be affected during the prediction.

Behavioural Evolution Rules

Rule 1

The architect can deﬁne an architectural element that

is not sensitive to evolution (Properties, structure and

behaviour that make the element non-sensitive). In

this case, it will not be affected by future evolution

operations.

Rule 2

Architectural elements that have undergone an evolu-

tion rate greater than X % (X deﬁnable by the archi-

tect) are no longer sensitive to evolution.

Invariant Evolution Rules

Rule 1

The architecture must be for example a connected

graph.

Business Evolution Rules

Rule 1

The expensive elements, whose evolution is expen-

sive are less privileged.

Rule 2

Evolutions involving the architectural elements least

affected by previous evolution operations are given

priority to evolution.

For this case study, let’s apply:

Structural evolution rules, all components have three

ports deﬁned, you can not go beyond three connec-

tions on a component.

Behavioural evolution rules, the components C

, C

and C

are deﬁned as not sensitive to change and X

(minimum rate of change per architectural element)

is set at eighty-ﬁve percent (85 %).

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

318

Thus three paths of evolution open:

• Creating a connector between components C

and

, this associates with architecture A

the se-

quence (A

con

pcon

Mg) with the following architecture A

(Figure 6);

• Creating a component C

and a connector C

on62

this associates with architecture A

the sequence

con

pcon

Mg) with the following architecture A

(Figure 6);

• Creating a component C

and a connector C

on65

this associates with architecture A

the sequence

con

pcon

Mg) with the following architecture A

(Figure 6);

Figure 5: Possibilities.

4.1.4 Evaluation of Proposals

This evaluation is based on Table 5, the sequence as-

sociated with the architecture being migrated is com-

pared to the sequential patterns associated with the

architecture discovered (Table 5), if the sequence is

identical to one of the sequential patterns discovered

the weight one (1) is associated with the possibility

otherwise the zero weight (0) as represented in Table

If we apply the business evolution rules, the evo-

lutions carried out on the components C

and C

will

be preferred, so the proposal A

and A

will be ex-

cluded, A

would be the only proposal. This (only

one proposal) results from the case study chosen, de-

pending on the case, more can be achieved. The evo-

lution sequences by actor and the calculation of the

actors participation rate in the evolution operation al-

low to plan the proposed future evolution operation.

Indeed, for each path, we are able to propose the com-

petences (actors) that can be involved. Through Table

7 we give an overview of the other results obtained

from this case study in addition to the other tables de-

ﬁned.

In the following section, the principles adapted to

respectively deﬁne the algorithms for extracting se-

quential patterns of software architecture evolution

and calculating the architectural elements evolution

rate and the actors participation rate in evolution op-

erations are explained.

4.2 Principle to Extract Sequential

Patterns of Software Architectures

Evolution and Calculating the

Architectural Elements Change

Rate

(For reasons of paper size, we could not give an

overview of the deﬁned functions, but we explain the

principles.)

We deﬁne a ﬁrst function which, starting from

the Table 1, associates with each architectural ele-

ment, the corresponding evolution sequence. The

function named Sequence, retrieves the table (Table

1) sorted on the Category, TimeEvolution and Ele-

ment columns and associates with each architectural

element the corresponding evolution sequence. It pro-

vides as an output an equivalent of Table 2. The sec-

ond function named SequenceSupport allows to com-

pute and associate to each candidate sequence its sup-

port, it takes as input the candidate sequences deﬁned

from Table 2 (output of the previous function), then

computes and associates to each sequence its total

number of appearance among all the other candidate

sequences. It provides as an output a table that as-

sociates each candidate sequence with its total num-

ber of appearances. The SequentialPattern function

returns sequential patterns by category of architec-

tural elements with k support provided as a param-

eter. For example, if we take a k equal to twenty-ﬁve

percent, the sequential patterns will correspond to all

the evolution sequences or sub-sequences appearing

in the evolution sequences of more than twenty-ﬁve

percent of architectural elements in the same category.

It takes as input the output of the previous function,

computes and associates to each candidate sequence

its support in percentage and compares it to the mini-

mum support k provided in parameter. If a superiority

is read, the current sequence is stored in the sequen-

tial pattern table. At the end of the process, it pro-

vides this sequential pattern table which contains all

the sequences with a support higher than the k pro-

vided. The PercentageEvolution function takes as in-

put any table similar to Table 2 associated with Table

1 that contains all the evolution operations performed.

It associates to each architectural element, its rate of

evolution by multiplying the size of the evolution se-

Evolution Style Mining in Software Architecture

319

quence associated with the element by hundred then

dividing the result by n (the size of Table 1 or the total

number of evolution styles involved in the search for

sequential patterns). As an output, the algorithm pro-

vides a two-column table where, to each architectural

element is associated its rate of evolution or to each

actor its rate of participation in evolution operations.

5 CONCLUSION

In this paper, we have presented a technique based on

sequential pattern extraction to plan and predict fu-

ture evolution paths of an evolving software architec-

ture. In addition, we evaluated the proposed evolu-

tion paths and deﬁned some algorithms to deﬁne se-

quences, determine sequential patterns and compute

the architectural elements evolution rate and the ac-

tors participation rate in evolution operations.

In the next step, we propose to apply our approach

to a evolving software system in production , then to

an urban architecture evolutions in order to propose

a model that is easily usable, prospective and predic-

tive, allowing us to analyze, estimate and predict fu-

ture evolutions of urban architecture.

REFERENCES

Agrawal, R. and Srikant, R. (1995). Mining sequential pat-

terns. In icde, page 3. IEEE.

Ahmad, A., Jamshidi, P., Arshad, M., and Pahl, C.

(2012). Graph-based implicit knowledge discovery

from architecture change logs. In Proceedings of the

WICSA/ECSA 2012 Companion Volume, pages 116–

123. ACM.

Amaral, J. N., Jocksch, A. P., and Mitran, M. (2014). Min-

ing sequential patterns in weighted directed graphs.

US Patent 8,683,423.

Bhattacharya, P., Iliofotou, M., Neamtiu, I., and Faloutsos,

M. (2012). Graph-based analysis and prediction for

software evolution. In 2012 34th International Con-

ference on Software Engineering (ICSE), pages 419–

429. IEEE.

Chiu, D.-Y., Wu, Y.-H., and Chen, A. L. (2004). An efﬁcient

algorithm for mining frequent sequences by a new

strategy without support counting. In Proceedings.

20th International Conference on Data Engineering,

pages 375–386. IEEE.

Cuesta, C. E., Navarro, E., Perry, D. E., and Roda, C.

(2013). Evolution styles: using architectural knowl-

edge as an evolution driver. Journal of Software: Evo-

lution and Process, 25(9):957–980.

Garlan, D. (2008). Evolution styles-formal founda-

tions and tool support for software architecture evo-

lution. Computer Science Department, reports-

archive.adm.cs.cmu.edu, page 650.

Goulão, M., Fonte, N., Wermelinger, M., and e Abreu, F. B.

(2012). Software evolution prediction using seasonal

time analysis: a comparative study. In 2012 16th

European Conference on Software Maintenance and

Reengineering, pages 213–222. IEEE.

Hassan, A. and Oussalah, M. C. (2018). Evolution styles:

Multi-view/multi-level model for software architec-

ture evolution. JSW, 13(3):146–154.

Hsu, J.-L., Liu, C.-C., and Chen, A. L. (2001). Discover-

ing nontrivial repeating patterns in music data. IEEE

Transactions on Multimedia, 3(3):311–325.

Javed, M., Abgaz, Y. M., and Pahl, C. (2011). Graph-based

discovery of ontology change patterns.

Le Goaer, O. (2009). Styles d’évolution dans les architec-

tures logicielles. PhD thesis, Université de Nantes;

Ecole Centrale de Nantes (ECN).

Mahajan, S., Pawar, P., and Reshamwala, A. (2014). Per-

formance analysis of sequential pattern mining algo-

rithms on large dense datasets. International Journal

of Application or Innovation in Engineering & Man-

agement (IJAIEM), 3(2).

Mooney, C. and Roddick, J. F. (2013). Sequential pattern

mining - approaches and algorithms. ACM Comput.

Surv., 45:19:1–19:39.

Oussalah, M. C., Le Goaer, O., Tamzalit, D., and Seriai, A.

(2008). Evolution shelf: Exploiting evolution styles

within software architectures. In SEKE, pages 387–

392.

Sadou, N. (2007). Evolution Structurelle dans les Archi-

tectures Logicielles à base de Composants. PhD the-

sis, Université de Nantes et école centrale de Nantes,

archives-ouvertes.fr.

Smeda, A., Oussalah, M., and Khammaci, T. (2005).

Madl: Meta architecture description language. In

Third ACIS Int’l Conference on Software Engineering

Research, Management and Applications (SERA’05),

pages 152–159. IEEE.

Srikant, R. and Agrawal, R. (1996). Mining sequential

patterns: Generalizations and performance improve-

ments. In International Conference on Extending

Database Technology, pages 1–17. Springer.

Wright, A. P., Wright, A. T., McCoy, A. B., and Sittig, D. F.

(2015). The use of sequential pattern mining to predict

next prescribed medications. J. of Biomedical Infor-

matics, 53(C):73–80.

Wu, Y.-H. and Chen, A. L. (2002). Prediction of web

page accesses by proxy server log. World Wide Web,

5(1):67–88.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

320

APPENDIX

Table 1: The Evolution Styles of Architecture A

to A

Reorganised.

Architecture evolution Style Name Actor Element Category Header TimeEvolution

Act1 C

Component A

01-05-2017

Act1 C

Component A

02-05-2017

Act1 C

on12

Connector A

con

03-05-2017

Act2 C

Component C

03-05-2017

Act2 C

on12

Connector C

pcon

03-05-2017

Act3 C

Component M

03-05-2017

Act3 C

on12

Connector M

pcon

03-05-2017

Act2 C

Component C

03-05-2017

Initial e

Act2 C

on12

connector C

pcon

03-05-2017

architecture e

Act3 C

Component M

03-05-2017

creation e

Act3 C

on12

connector M

pcon

03-05-2017

Act1 C

Component A

04-05-2017

Act1 C

on23

connector A

con

05-05-2017

Act2 C

Component C

05-05-2017

Act2 C

on23

Connector C

pcon

05-05-2017

Act3 C

Component M

05-05-2017

Act3 C

on23

Connector M

pcon

05-05-2017

Act2 C

Component C

05-05-2017

Act2 C

on23

Connector C

pcon

05-05-2017

Act3 C

Component M

05-05-2017

Act3 C

on23

Connector M

pcon

05-05-2017

Act1 C

Component A

06-05-2018

Act1 C

on14

Connector A

con

07-05-2018

Act2 C

Component C

07-05-2018

Act2 C

on14

Connector C

pcon

07-05-2018

Act3 C

Component M

07-05-2018

Act3 C

on14

Connector M

pcon

07-05-2018

Act2 C

Component C

07-05-2018

Act2 C

on14

Connector C

pcon

07-05-2018

Act3 C

Component M

07-05-2018

Act3 C

on14

Connector M

pcon

07-05-2018

Act1 C

Component A

10-05-2019

Act1 C

on35

Connector A

con

11-05-2019

Act2 C

Component C

11-05-2019

Act2 C

on35

Connector C

pcon

11-05-2019

Act3 C

Component M

11-05-2019

Act3 C

on35

Connector M

pcon

11-05-2019

Act2 C

Component C

11-05-2019

Act2 C

on35

Connector C

pcon

11-05-2019

Act3 C

Component M

11-05-2019

Act3 C

on35

Connector M

pcon

11-05-2019

Evolution Style Mining in Software Architecture

321

Table 2: Evolution Sequence by Architectural Element and Category.

Category Element Evolution sequence

)

Component C

)

on12

pcon

)

Connector C

on23

pcon

)

on14

pcon

)

on35

pcon

)

Table 3: Evolution Sequence by Architecture.

Architecture Evolution sequence

con

pcon

Mg)

con

pcon

Mg)

()

Table 4: Support by Architectural Element and Category.

Category Evolution sequence support

Architecture (A

con

pcon

Mg) 66,6 %

Component (C

) 60 %

) 100 %

Connector (C

pcon

) 100 %

Table 5: Sequential Pattern by Category of Architectural Elements.

Category Sequential pattern >25 %

Architecture (A

con

pcon

Mg)

Component (C

)

Connector (C

pcon

)

Table 6: Evaluation.

Possibilities Evolution sequence Weight

con

pcon

Mg) 0

con

pcon

Mg) 1

con

pcon

Mg) 1

Table 7: Other Results.

Category Result

Architectural elements most affected C

, C

on12

, C

on23

, C

on14

, C

on35

Architectural elements less affected C

and C

The selected architecture A

The most active actors Act2 and Act3

The least active actors Act1

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

322