A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED

SOFTWARE ARCHITECTURE

Mohamed Oussama Hassan, Laurent Deruelle, Henri Basson and Adeel Ahmad

Universit

e Lille Nord de France

Laboratoire d’Informatique, Signal et Image de la C

ote d’Opale

50 rue Ferdinand Buisson BP 719, 62228 Calais Cedex, France

Keywords:

Distributed software architecture analysis, Change propagation, Knowledge-based system.

Abstract:

In the context of software architecture evolution, understanding the impacts of a change to be applied on a

distributed software architecture is necessary for various activities related to maintenance and change man-

agement. In this paper, we propose formal models and a platform based on eclipse plugins for modeling and

analysis of the software architecture description and their related source codes. The proposed models aim at

the construction of graph representation based on the architecture description and the software source codes.

The graph implementation is mapped with facts of a distributed knowledge-based system, which performs

change propagation rules to evaluate the impact of a change performed on distributed components.

1 INTRODUCTION

Nowadays practices of software engineering are often

asked to respond to development or evolution of dis-

tributed applications on heterogeneous platforms with

less delay, lower cost, and better quality. The applica-

tions are continuously growing in size and complex-

ity making the change more difﬁcult to control and

to manage. Moreover, it is largely admitted that the

quality of large applications can be improved using

formalized architectural models at the earlier phases

of requirements speciﬁcations and design. There-

fore, over the past decade software architecture has

received increasing attention as an important subﬁeld

of software engineering aiming to face the growing

size and complexity of software (Taylor et al., 2009).

It is inevitable that a software undergoes some

changes in its lifetime. A change introduced to one

component of an application has often effects on sev-

eral others parts. If this process is uncontrolled,

changes may have unexpected side effects or com-

plex implications on the behavior of the whole sys-

tem. The cost to ﬁx an error or an incoherence, result-

ing from changes during requirements, or early de-

sign phases, is largely lower than the cost of correct-

ing the same error found during system testing or in

production (Clements et al., 2002). The change im-

pact analysis refers to track the effects of a change

by providing visibility of the potential effects of the

proposed change before it is implemented. It greatly

helps maintainers to determine appropriate actions to

take with respect to change in decisions, schedule

plans, cost and resource estimations.

2 OBJECTIVES

In this paper, we propose a model, called Architec-

ture Software Components Model (ASCM), to rep-

resent and to unify the major concepts deﬁned in

a large number of existing architecture description

languages (ADL). The ASCM is coupled to another

model called Source Code Structural Model (SCSM)

(Deruelle et al., 2001; Deruelle et al., 2007) in order to

represent relationships between components from the

architecture level and those of the source code level.

The two models represent the architecture and the

source codes as graphs, in which the nodes are com-

ponents and the edges are relationships. The graphs

are distributed according to the location of the archi-

tecture speciﬁcation and the relevant source codes.

The main purpose of our models is to provide a ba-

sis to track the change propagation process using ad-

equate graphs on which we deﬁne formal propagation

rules.

The rest of the paper is organized as follows: Sec-

tion 3 presents related works for distributed software

Oussama Hassan M., Deruelle L., Basson H. and Ahmad A. (2010).

A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED SOFTWARE ARCHITECTURE.

In Proceedings of the Fifth International Conference on Evaluation of Novel Approaches to Software Engineering, pages 78-85

DOI: 10.5220/0002998400780085

 SciTePress

architecture evolution. Section 4 describes our formal

model ASCM to represent the common concepts de-

ﬁned in the major ADLs. Section 5 proposes a typol-

ogy of formalized change operations applied on soft-

ware architecture and permitting the change impact

analysis. Section 6 deﬁnes a formal process to deal

with the change propagation process for distributed

software. Section 7 presents our integrated platform

that implements the formal models and a knowledge-

based system to support the change propagation pro-

cess. Section 8 gives a scenario of a change impact

analysis performed on a distributed software architec-

ture. Finally, section 9 provides some conclusions and

perspectives.

3 DISTRIBUTED SOFTWARE

ARCHITECTURE EVOLUTION:

RELATED WORKS

Software architecture has emerged as an area of in-

tense research over the last decade. Many approaches

have been proposed to deal with architectural speci-

ﬁcation and analysis (Medvidovic and Taylor, 2000;

Bass et al., 1998; Clements and Shaw, 2009). In these

approaches, a large number of ADLs have been de-

veloped to represent different aspects of distributed

software architectures based on the middlewares. The

ADLs do not provide features to deal with the evolu-

tion management of architecture description in a dis-

tributed environment.

Many works have been done for studying the evolu-

tion mechanism in the ADLs. We note that the spec-

iﬁcation of the evolution is realized by the ADL that

serves for the architecture description. Therefore, the

evolution management is included in the architectural

speciﬁcation, and so it will be difﬁcult to be distin-

guished. Moreover, it is almost impossible to iden-

tify all possible evolutions operations that may occur

when specifying architecture.

It is hard to deal with the non planned evolution,

considering the difﬁculty to study and analyze au-

tomatically the changes impact without incoherence.

The number of propositions dealing with architecture

change impact analysis is very restricted.

4 DISTRIBUTED SOFTWARE

ARCHITECTURE MODELING:

ASCM

Many resarch works have been done to provide archi-

tectural modeling (Garlan et al., 1997), in which the

following common high-level:

1. The Components are units of computation or a

data stores. For example, a component can be a

Thread, a Procedure or a whole application. An

instance of a component may be distributed on

many sites and may interoperate with other dis-

tributed components.

2. The Connectors are architectural building blocks

used to represent the interactions between lo-

cal and distributed components. For example, a

T hread deployed on one site can be connected to

another T hread deployed on another site to send

messages. The second component may treat mes-

sages using local components.

3. The Conﬁgurations are connected graphs of local

and distributed components and connectors that

describe the structure of the distributed architec-

ture.

Although these concepts deﬁne a high-level common

structure for the distributed software architecture, we

need to reﬁne them in a more accurate model to de-

scribe more precisely the structure of a distributed ar-

chitecture.

The model ASCM leads to represent the dis-

tributed software architecture, based on architecture

speciﬁcations described using different ADLs. Our

work consists to represent in a model the common

high-level concepts deﬁned in the major ADLs. This

allows us to analyze various architectural description

documents, which specify distributed software archi-

tectures, in order to extract the elements and to repre-

sent them using ASCM.

By comparing in more detail the deﬁnition of the

ADLs, we can reﬁne these elements to provide a more

precise model. Let us describe the ASCM model pre-

sented in ﬁgure 1:

• The interface deﬁnes the services that other com-

ponents wants to invoke. An interface may deﬁne

ports used by a connection. A port can be used by

several connectors. In the ADLs, an interface is

mandatory to describe a distributed component in

the architecture.

• The implementation reﬂects the source codes of

the services deﬁned in the interface. For exam-

ple, the implementation can describe how a com-

ponent calls sub-programs to realize the services.

• The connection provides a link mechanism be-

tween distributed components to exchange infor-

mation. The link is usually managed using a mid-

dleware that allows a component deployed on one

system to access programs and data on another

one.

A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED SOFTWARE ARCHITECTURE

Figure 1: ASCM: UML-based representation of Architecture Description Languages.

• The middleware is a set of services that allows in-

teractions between multiple components running

on many sites. It helps to solve heterogeneity, in-

teroperability and distributed computed problems.

• The instance represents a sub-component belong-

ing to a component. The sub-component is instan-

tiated from the interface or the implementation of

another component.

• The site is the element on which the instances of

a component will be deployed on. It deﬁnes the

hardware and software requirements for the in-

stances running.

• The properties can specify constraints on the

interface or the implementation of a component.

The constraints may be functional or not, such as

related source code of a component, performance,

reliability and availability.

We coupled ASCM with SCSM, which is fully

described in (Deruelle et al., 2001; Deruelle et al.,

2007) by formalizing a generic relationship that may

exist between their respective elements. The rela-

tionship will be used for propagating the impact of a

change done on the architectural description to its cor-

responding source code and reciprocally. The models

SCSM and ASCM are coupled by a projection rela-

tionship. When a projection relationship exists, the

software modeling is more precise and the change im-

pact analysis is performed on the architectural level

and the source codes one.

Hereafter, we propose a typology of formalized

change operations applied on the distributed archi-

tecture, which are represented by ASCM model in-

stances.

5 TYPOLOGY OF CHANGE

OPERATIONS

A typology of change operations is presented in the

table 1, using the assertion formalism. Assertions are

widely used in the software community to formalize

the programs behavior (Mens, 2001). For each op-

eration, we specify a pre-condition to be checked in

order to allow the execution of the operation. The

post-condition indicates the operation results. The in-

variants represent the propositions to be veriﬁed be-

fore and after the operation execution.

Hereafter, we describe a change operation to illus-

trate the assertion formalism and the impact on the

distributed architecture and on the source codes.

Let us to consider the operation

del comp imp(c, cimp), which consists to delete the

implementation cimp associated to the component

interface c. To allow the operation, the implementa-

tion of the component had to exist in the architecture

and therefore a corresponding node must be present

in the ASCM graph. The invariant stipulates that

the existence of the interface component c must be

veriﬁed before and after the operation realization. No

instance of cimp should be deﬁned in the architecture

(−subComp(∗, cimp)). cimp should not contain any

subcomponents (−source(hasSubComp∗, cimp)).

The result of the operation is the deletion of the

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

Table 1: Typology of change operations applied on Software Architecture.

Name Operation Pre-condition Post-condition Invariant

Component interface

adding

add int comp(c, t) −c

+c −edge(∗, c)

Component imple-

mentation adding

add imp comp(cimp, c) −cimp +cimp

+edge(∗, c, cimp)

Port adding add port(a, p) −p +p

+type(p, port)

+edge(hasPort∗, a, p)

Subcomponent

adding

add sub comp(a, s, t) −s ∨

(+s ∧ −edge(e, a, s))

+edge(e, a, s)

+type(e, hasSubComp)

Component interface

deletion

del comp int(a) +a −a

−impl(∗, a)

−edge(∗, a)

−subComp(∗, a)

(−subComp(∗, ai),

+ im pl(ai, a))

Component imple-

mentation deletion

del comp imp(c, cimp) +cimp −cimp

−edge(∗, cimp)

−subComp(∗, cim p)

−source(hasSubComp∗,

cimp)

Connector deletion del conn(cn, c, a, b) +cn

+edge(hasConn∗, c, r)

+edge(usePortSrc∗, cn, a)

+edge(usePortDst∗, cn, b)

−cn

−edge(∗, cn)

Port deletion del port(a, p) +p

+type(p, port)

+edge(e, a, p)

−p

−edge(∗, p)

−dest(usePortSrc∗, p)

−dest(usePortDst∗, p)

Subcomponent dele-

tion

del subcomp(a, s) +s

+edge(hasSubComp∗, a, s)

−s

−edge(∗, s)

−connSubComp(∗, s)

Table 2: Assertions list for the graph marking.

Assertion Signiﬁcation

mark(el) ∀el ∈ E ∨ el ∈ N, state(el) = a f f ected

mark(v, op) ∀e ∈ E, v

∈ N : ((+edge(e, v, v

) ∨ +edge(e, v

v)) ∧ +conductivity(op, e, v, v

))

−→ mark(e) ∧ mark(v

)

mark(source(t∗, v), op) ∀e ∈ E, v

∈ N : (type(e) = t ∧ +edge(e, v, v

) ∧ +conductivity(op, e, v, v

))

−→ mark(e) ∧ mark(v

)

mark(target(t∗, v), op) ∀e ∈ E, v

∈ N : (type(e) = t ∧ +edge(e, v

, v) ∧ +conductivity(op, e, v, v

))

−→ mark(e) ∧ mark(v

)

component implementation and all of its input and

output edges. In the case of at least one invariant is

not respected, an impact is propagated locally to the

linked nodes (components) in the ASCM graph.

Considering the distributed environment, and dur-

ing software analysis, the graphs are constructed on

each site and are interconnected. Then, the implemen-

tation deletion may have an impact on other nodes

belonging to an ASCM graph which is distributed

on a remote site. This is done by the distributed

knowledge-based system.

6 CHANGE IMPACT

PROPAGATION IN

DISTRIBUTED SOFTWARE

ARCHITECTURE

The change impact propagation process refers to the

process of actually carrying out a set of initial mod-

iﬁcations to the software components, and to re-

establish the system consistency, by making a set of

estimated consequent changes. This process would

involve advising the user the software components to

be changed and the types of the changes.

Our approach is based on the ECA formalism

(Event - Condition - Action) to describe the change

impact propagation rules (Hassan et al., 2009). It con-

sists of analyzing the impact on the distributed archi-

tecture by deﬁning generic rules. These could be ap-

plied, independently of ADLs, to propagate the im-

pact locally from the architecture to its corresponding

source codes and then to the distributed ones.

6.1 Knowledge-based System for

Change Impact Propagation

The change impact analysis is based on a knowledge-

based system to manage evolution rules for dis-

tributed architecture and source codes. These rules

estimate the impact of a change performed on any

component belonging to the architecture or to the

source codes. The knowledge-based system consists

of three main components: the facts base, the rules

base and the inference engine. The facts base consti-

tutes the working memory and the dynamic part of the

A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED SOFTWARE ARCHITECTURE

knowledge-based system (KBS). It contains the facts

set that allows ﬁring change propagation rules. A Fact

represents a graph node or edge representing the ele-

ments of ASCM or SCSM models. These are added

to the facts base during the analysis phase of the ar-

chitecture speciﬁcation and related source codes. Ap-

plying a change on a node is reﬂected in the fact base

and may cause the inference engine to ﬁre rules to

perform change impact analysis.

6.2 Change Propagation Rules

Deﬁnition

The change propagation rules describe formally the

impact of the change operations performed on the el-

ements of the ASCM model. The fact correspond-

ing to the changed node or edge is updated in the

knowledge-based system. This starts the change

propagation process by selecting the set of rules hav-

ing the updated fact in their pre-condition.

The table 2 shows the formalization of the mark-

ing assertions, which consists to identify the compo-

nents and the relationships affected by a change oper-

ation. The impact propagation to the neighborhood of

a marked component is deﬁned following the nature

of incoming and outgoing relationships. This refers to

the impact conductivity of each relationship. The as-

sertion +conductivity(op, e, A, B) formalizes the im-

pact conductivity of a relationship e : A −→ B, with A

is the source component of e, B the destination com-

ponent of e and op is the change operation applied on

A.The marking assertions are deﬁned as follows:

• The assertion mark(el) consists to change

the state of components and relationships as

a f f ected, in the facts base.

• The assertion mark(v, op) indicates for an oper-

ation op applied on v, that the edges of v are

marked as affected, according to the conductivity

of the relationship.

• The assertions mark(source(t∗, v, op)) and

mark(target(t∗, v, op)) consists to mark the

relationships e of type t having v as a source node

or target node and to mark the related target node

or source node of each relationship e following

its conductivity for the operation op.

The process of marking nodes and propagating the

impact stops when all rules are ﬁred and there is no

more candidate facts.

We deﬁne three generic rules to deal with the

change impact propagation:

Rule Execute Operation(Op, el){

T RUE(Op.Pre −Condition) ∧ T RUE(Op.Invariant)

−→ Op.Post −Condition

}

The rule Rule Execute Operation(Op, el) con-

sists to perform the change operation op on an archi-

tectural element el when the pre-conditions and in-

variants of op are satisﬁed. There is no impact on the

distributed architecture.

Rule

Impact Operation(Op, el){

T RUE(Op.Pre −Condition) ∧ FALSE(Op.Invariant)

−→ mark(el)

}

The rule Rule Impact Operation(Op, el)

changes the state of el to a f f ected in order to

identify the impact of op when at least one invariant

is not respected for op.

Rule Propagate Impact(Op, el){

+ state(el,

a f f ected

)

−→ mark(el, op)}

}

The rule Rule Propagate Impact(Op, el) propa-

gates the impact to the neighborhood of an affected

element el. The propagation is based on the marking

assertions in order to change the state of the edges and

of the linked nodes.

7 CHANGE IMPACT

PROPAGATION IN

DISTRIBUTED SOFTWARE

ARCHITECTURE

The ﬁgure 2 presents the global architecture of our

platform based on Eclipse which is extended for the

change impact analysis. The extensions of our plat-

form are divided into four main components:

The multi-languages analyzer allows analyzing

the source codes and the architectural description of

a software. The analysis is based on the grammar of

each language used to write a project ﬁle. The multi-

languages analyzer is based on parsers which are gen-

erated through the Java Compiler Compiler (JavaCC).

The multi-languages analysis result consists of pro-

ducing XML descriptions that are used for the graph

construction by the second plugin.

The software modeler is the second Eclipse plu-

gin that contains the implementation of both SCSM

and ASCM models. It provides an XML ﬂow an-

alyzer that matches the components or relationships

deﬁned in our model with the XML tags provided by

the multi-language analyzer. The two models are in-

stantiated as graph where nodes represent the com-

ponents and edges their relationships. The software

modeler performs fact assertions in the knowledge-

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

Figure 2: The architecture of the eclipse-based platform.

Figure 3: Distributed Architecture evolution and related graphs resulting from the port deletion operation.

A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED SOFTWARE ARCHITECTURE

based system, which is the central component of our

implementation and provides the change impact prop-

agation mechanism.

The expert system engine is the third plugin

and represents the implementation of the knowledge-

based system. It allows implementing the change

impact propagation process and manages the change

propagation rules.

The user interface is the forth Eclipse plugin that

allows the graph visualization and the execution of

change operations on it. It allows maintainer to man-

age interactively the evolution and the maintenance of

a software system.

Hereafter, we propose a scenario to illustrate the

graph representation of a software architecture and

the change propagation process.

8 CHANGE PROPAGATION

SCENARIO

The proposed scenario illustrates the change impact

analysis on a distributed and multi-threaded appli-

cation. The application deﬁnes client threads that

send messages using Remote Procedure Call proto-

col (RPC). The messages are consumed by threads

deployed on a server. This application architecture

is speciﬁed using the AADL language, presented in

listings on the Figure 3.

The scenario consists to delete the server

port in

msg using the change operations called

del port(a, p). Regarding the operation invariants

and the ASCM graph, an edge exists between the

node EDPname = in msg and the node EDCname =

C1. This edge provides conductivity of the impact of

the port component. The rule ImpactDeletePort, de-

scribed below marks and changes the state of the port

node to a f f ected. This ﬁres the second rule, called

PropagateImpactDeletePort to mark the edges en-

tering in the port and the related target nodes. These

marked nodes are sent to the Eclipse client to be in-

serted in the distributed fact base and which will ﬁre

the rules for propagating locally the impact. The

propagation is done through relationships according

to theirs conductivity. The result of the change prop-

agation process can be shown in ﬁgure 3. The nodes

and the edges, which have been marked by our expert

system, are shown with the a f f ected label. The re-

sult shows the projection relationship which leads the

impact to the source codes.

rule "ImpactDeletePort"

when

n: ArchitectNode(

stateNode==ArchitectNode.STATE_DELETED,

typeNode=="EDP"

)

n1: ArchitectNode()

e: ArchitectEdge()

eval((e.getNodeDest()==n && e.getNodeSrc()==n1)

(e.getNodeSrc()==n && e.getNodeDest()==n1)

)

then

n.setLabel("AFFECTED "+n.getLabel());

n.setStateNode(ArchitectNode.STATE_IMPACTED);

end

rule "PropagateImpactDeletePort"

when

n: ArchitectNode (

stateNode==ArchitectNode.STATE_IMPACTED,

typeNode=="EDP"

)

n1: ArchitectNode()

e: ArchitectEdge()

eval((e.getNodeDest()==n && e.getNodeSrc()==n1)

(e.getNodeSrc()==n && e.getNodeDest()==n1)

)

then

e.setState(ArchitectEdge.STATE_IMPACTED);

n1.setStateNode(ArchitectNode.STATE_IMPACTED);

end

9 CONCLUSIONS AND FUTURE

WORKS

In this paper, we have presented a ASCM model and a

distributed knowledge-based system approach to deal

with the change impact analysis on distributed soft-

ware architecture. Our model represents the informa-

tions extracted from architectural descriptions, inde-

pendently of the ADLs, as distributed graphs which

are stored as facts in the distributed knowledge-based

system. The facts ﬁre the change propagation rules in

order to identify the impact of a change and to propa-

gate it to linked nodes. Our approach is implemented

as many plugins in Eclipse Environment.

Perspectives of our work consists to enhance our

change impact analysis approach to deal with qualita-

tive aspects of a software at the architecture level.

REFERENCES

Bass, L., Clements, P., and Kazman, R. (1998). Software

Architecture in Practice. Addison Wesley.

Clements, P., Kazman, R., and Klein, M. (2002). Evaluat-

ing Software Architectures: Methods and Case Stud-

ies. Addison Wesley.

ENASE 2010 - International Conference on Evaluation of Novel Approaches to Software Engineering

Clements, P. and Shaw, M. (2009). ”the golden age of soft-

ware architecture” revisited. IEEE Software, 26:70–

72.

Deruelle, L., Basson, H., Bouneffa, M., and Hattat, J.

(2007). An eclipse platform extension for analysis and

manipulation of multi-language software code. pages

174–179.

Deruelle, L., Bouneffa, M., Melab, N., and Basson, H.

(2001). A change propagation model and platform for

multi-database applications. Software Maintenance,

IEEE International Conference on, pages 42–51.

Garlan, D., Monroe, R., and Wile, D. (1997). Acme: An

architecture description interchange language. In in

Proceedings of CASCON97, pages 169–183.

Hassan, M. O., Deruelle, L., and Basson, H. (2009).

Towards a change propagation process in software

architecture. In 18th International Conference on

Software Engineering and Data Engineering (SEDE-

2009), pages 85–90, Las Vegas, Nevada, USA.

Medvidovic, N. and Taylor, R. (2000). A classiﬁcation and

comparison framework for software architecture de-

scription languages. IEEE Transactions on Software

Engineering, 26:70–93.

Mens, T. (2001). Transformational software evolution by

assertions. Workshop on Formal Foundations of Soft-

ware Evolution, CSRM 2001.

Taylor, R. N., Medvidovic, N., and Dashofy, E. M. (2009).

Software Architecture: Foundations, Theory, and

Practice. Wiley Publishing.

A CHANGE PROPAGATION PROCESS FOR DISTRIBUTED SOFTWARE ARCHITECTURE