EVOLUTION STYLES IN PRACTICE

Refactoring Revisited as Evolution Style

Olivier Le Goaer, Mourad Oussalah, Dalila Tamzalit

LINA, University of Nantes, My Street, Nantes, France

Djamel Serai

Department of Computing, Ecole des Mines de Douai, Douai, France

Keywords:

Software Evolution, Modeling, Components, Design, Languages.

Abstract:

The evolution of pure software systems remains a time-consuming and error-prone activity. But whatever

the considered domain, recurring practices can be captured and reused to alleviate the subsequent amounts

of effort. In this paper we propose to treat domain-speciﬁc problems-solutions pairs as ﬁrst-class entities

called “evolution styles”. As such, an evolution style is endowed with an instantiation mechanism and can

be considered at different conceptual levels. Applied on arbitrary domains, an evolution style is intended to

evolve a family of applications whereas its instances evolve given applications. The evolution style’s format

is a component triple where each component is highly reusable. In this way, evolution styles are scalable

knowledge fragments able to support large and complex evolutions, readily available to be played and replayed.

1 INTRODUCTION

To face changing desiderata, the evolution of software

intensive systems is an inevitable activity. Indeed,

software models must be changed very often to

remain useful and meaningful. Nowadays highly

reactive and interactive environments (e.g ubiquitous

computing (Greenﬁeld, 2006) and Ambient Intel-

ligence) calls for a new approach to facilitate and

replay these evolutions. This reactivity is crucial to

cope with the contemporaries open systems where

other ones can be plugged or unplugged, but also

with the fashionable agile software development

(Cockburn, 2002) which encourages many feedbacks

and hence countless requirements modiﬁcations. For

all these reasons, an evolution engineering emerged

over the last few years to address this challenge.

This promising engineering ﬁeld encompass popular

models transformations ﬁeld, various refactoring

techniques and modernization scenarios for good

practices, or more generally any principle for struc-

tural or behavioral alteration of an existent software

system. In this paper we argue in favor of analysis

and design steps dedicated to software evolution.

The key idea is to extract the evolution features

from traditional software design, for strong reuse

purposes. Indeed, we think that the reuse of recurring

evolution scenarios as patterns is a proﬁtable way to

alleviate the amount of effort required by software

maintenance activities. For that, we advocate that

software evolution has to be identiﬁed, encapsulated,

reused and managed. This calls for the treatment of

evolution as a ﬁrst-class entity, called an evolution

style. Externalization and modularization of features

variations and commonalities have been studied with

Traits (Ducasse et al., 2006), which are composable

units of behavior, and Classboxes (Bergel, 2005),

which are minimal module models supporting local

rebinding. Despite their added-value, these concepts

are not dedicated to evolution, lack of semantics and

are conﬁned to OO systems while evolution should

be challenged in a wider scope. Nevertheless, a

recent and promising work is the Changebox concept

(Nierstrasz et al., 2006), a component to scope

changes over time, even if no modeling conjecture is

given. On our side, an evolution style is a general-

purpose concept, applied to arbitrary domains, to

tame and model the evolution at a wide scope and in

a uniform way. It characterizes a family of evolutions

by factorizing commonalities of evolution practices

and expresses the semantics of changes. A style is

a fragment of knowledge speciﬁed as a component-

138

Le Goaer O., Oussalah M., Tamzalit D. and Serai D. (2007).

EVOLUTION STYLES IN PRACTICE - Refactoring Revisited as Evolution Style.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 138-143

DOI: 10.5220/0001341401380143

 SciTePress

triple which can be hierarchically organized. The

proposed speciﬁcation has a favorable inﬂuence on

other issues like evolution management, including

evolution styles matching and classiﬁcation, but this

is not discussed in this paper.

The remainder of this paper is organized as follows:

in the next section (sec. 2) we discuss the keys ideas

of our proposal. Section 3 describes the modeling en-

vironment we adopted to support the evolution style

approach. In section 5 we show how a well-known

refactoring can be revisited as an evolution style, be-

fore we conclude in section 6.

2 STYLES FOR SOFTWARE

EVOLUTION

In this section we introduce the foundation of our

work. We mainly describe the beneﬁts of the reiﬁ-

cation of evolution as a ﬁrst-class entity, the modular

speciﬁcation format chosen and the possible organi-

zations and capabilities of evolution styles.

2.1 Evolution as First-class Entity

According to us, the evolution features of a software

system being built must be analyzed and designed

separately from business features, in order to promote

reuse following two complementary axis. First, our

objective is to extract and modularize evolution, that

is, to capture the structure, behavior and the semantics

of evolution. As such, an evolution style encapsulates

important design decision about evolution, as pro-

moted by the principle of information hiding. Evolu-

tion styles factor commonalities between evolutions,

just like classes do for objects in the object-oriented

development. More precisely, they capture the param-

eters, assertions and implementation shared by sev-

eral evolutions. They express semantics of refactor-

ing and other changes. This last point is important

because we are convinced that stakeholders and tools

must be aware of meaning of evolution to work ef-

fectively. Thus, grouping evolutions into styles helps

avoid the speciﬁcation and storage of much redun-

dant information and hence constitutes the ﬁrst axis

of reuse. The second axis of reuse extends the in-

formation hiding capability one step further. The key

idea is to support fragmentation and extension of evo-

lution. Practically, the composition and inheritance

mechanisms encourage this kind of reuse and lead to

treat evolution on a hierarchical basis.

2.2 Evolution Style Speciﬁcation

The evolution style speciﬁcation is motivated by

the “componentization” of patterns and inﬂuenced

by Knowledge-based systems (KBS) (Oussalah,

2002). The proposed three-parts speciﬁcation to

address evolution question is the convergence of the

Context-Problem-Solution triple deﬁned by patterns

(Erich GAMMA and VLISSIDES, 1995) and the

Domain-Task-PSM

triple deﬁned by KBS.

Let us make a closer examination of the three compo-

nents constituting an evolution style:

• Domain: evolution depends on an area of knowl-

edge speciﬁed by a set of concepts and links

among them. It corresponds to a domain model

and hence deﬁnes a vocabulary through a set of

types. The instantiation of a domain engenders an

application able to be evolved.

• Header: evolution can be deﬁned by a contract

which stipulates the starting situation and the re-

sulting one. It is speciﬁed by inputs/outputs pa-

rameters typed with elements of the domain, plus

a set of assertions (post/pre-conditions, invariants)

as constraints for the evolution achievement.

• Competence: evolution contains a body of knowl-

edge to fulﬁll the evolution contract, that is, to en-

sure the morphing from the starting situation to

the resulting one. It can be speciﬁed by a block of

declarative or imperative instructions. The choice

is driven by the desired abstraction level.

The three points mentioned above can be described

formally and be clearly modularized as three indepen-

dent but complementary components. An evolution

style has a unique name, has a goal described in nat-

ural language, and is viewed as the aggregation (with

the object meaning) of a domain component, a header

component and optionally a competence component.

This partitioning promotes (a) description reuse be-

cause the components are quite interchangeable and

shareable by several styles at the same time, and (b)

ﬂexibility because the competence component can be

omitted when not enough information is available. In

this last case, we deal with abstract evolution styles.

2.3 Evolution Style Topologies

The evolution styles are arranged and linked to form a

graph or topology. The nodes are evolution styles and

the edges between two nodes represent specialization

Problem Solving Method

EVOLUTION STYLES IN PRACTICE - Refactoring Revisited as Evolution Style

139

or composition. As a result, the graph can be studied

following a composition viewpoint or a specialization

viewpoint.

Composition viewpoint. A composition hierarchy

is a hierarchy of evolution styles in which an edge

between a pair of nodes represents the IS-PART-OF

relationship, that is, the higher node is composed of

the higher level node. For a pair of evolution styles,

the level style is called a composite style and the lower

level style is a component style. A composite evolu-

tion style references multiple children styles. Each

child can in turn reference their own children styles.

A parent evolution style is dependent of its children

styles. This underlines that an evolution style pro-

vides a service but may requires other ones. This

property makes a distinction between independent

styles called Basic evolution styles and dependent

styles called Complex evolution styles. A methodol-

ogy is given further in this paper to extract a basis of

complex and basic evolution styles, named the evolu-

tion core.

Specialization viewpoint. A specialization hierar-

chy is a rooted hierarchy of evolution styles in which

an edge between a pair of nodes represents the IS-

KIND-OF relationship, that is, the lower node is a

specialization of the higher level node. For a pair of

evolution styles, the level style is called a superstyle

of the lower level style, and the lower level style is

substyle of the higher level class. The three compo-

nents (Domain, Header, Competence) speciﬁed for a

style are inherited by all its substyles. Hence, a sub-

style may have:

• a more speciﬁc domain: using the concepts and

concept-links provided by a more speciﬁc do-

main.

• a more speciﬁc header: adding or redeﬁning pa-

rameters and constraints.

• a more speciﬁc competence: redeﬁning the imple-

mentation block in case of a code-level represen-

tation, or adding new rules or states in case of a

rule-based or state-based representation.

The single root of the specialization hierarchy is a

system-deﬁned abstract evolution style named EVO-

LUTION whose wide semantics depicts all evolu-

tion practices supported on the considered domain.

There is also two system-deﬁned abstract evolution

substyles named COMPLEX and BASIC, as a stan-

dardized way to explicitly separate dependent and in-

dependent styles.

2.4 Evolution Core

To obtain the most ﬁne-grained and useful evolu-

tion styles, we propose a methodology which says to

project generic operators on relevant entities of the

considered domain. The resulting set of evolution

styles, called the evolution core, is enough to sus-

tain small but relevant evolution practices. In table

1 we have identiﬁed recurring operators encompass-

ing change activities during the software maintenance

phase, reconsidering a work on class characteristic

migrations (Castellani et al., 2001). Two kinds of op-

erators are mentioned: simple operators and advanced

operators. The latters need simple operators to be

functional. Consequently, the styles built from pro-

jection of simple operators are basic evolution styles

while the styles built from projection of advanced op-

erators are complex evolution styles. Therefore, after

an exhaustive analysis, for each domain, a set of ba-

sic and complex evolution styles has to be released or

extracted following this methodology.

Table 1: Simple and Advanced operators for evolution.

NAME DESCRIPTION

Simple

Add Connect an entity to another one

Remove Disconnect an entity from another one

Modify Alter an entity’s property

Advanced

Transfer Cut/Paste some entities from a location

to another

Clone Copy/Paste some entities from a loca-

tion to another

Merge Merge two entities into a single one

Split Split a monolithic entity into several

ones

Let us consider the Java Language for a quick exem-

pliﬁcation. Thus, starting from a Java domain meta-

model and the previous table, we can construct basic

evolution styles such as AddClass(Class super,

Class sub), to insert a new Java Class in a hierar-

chy, or ModifyClassName(Class super, String

newName) to rename an existing Java Class.

3 EVOLUTION STYLE

MODELING ENVIRONMENT

A strong abstraction purpose emerged in the last ten

years to help people to apprehend the variety, the

complexity and the synergies of software artifacts.

The same demand subsists to characterize the evolu-

tion in a global way. Therefore, the obscure or tacit

ICSOFT 2007 - International Conference on Software and Data Technologies

140

evolution activities should be reinterpreted as a clear

and coherent set of models.

4 LAYERED ARCHITECTURE

The modeling environment we work with is a layered

architecture of models, separated by an instantiation

relationship. This architecture exhibits three distinct

layers (or levels) and distinct concerns. We respect

the modeling attitude envisioned by the OMG’s mod-

eling stack.

Figure 1: Evolution style modeling stack.

The M2, M1 and M0 levels are separated by an on-

tological instantiation (instanceOf). In this way, an

element of a M

level is created from its deﬁnition of

the M

i+1

level. According to this architecture, run-

time evolutions (i.e evolution styles instances) are lo-

cated at M0, evolution styles are located at M1 and

the evolution style language is located at M2. In addi-

tion, the layers reveal three distinct stakeholders with

their own duties. The infrastructure builder intervenes

at the M2 level, the styles builder intervenes at the

M1 level and lastly the evolutions builder intervenes

at the M0 level. This cutting of responsibilities tends

to share the global evolution effort by separating the

concerns and skills.

4.1 Modeling Levels

Each level introduces particular conceptual abstrac-

tions and is intended to particular modeling purpose.

Les us make a closer but summarized examination of

the M2, M1 and M0 levels.

Model at level 2. Model at the level 2 is called a

meta-model, that is, a model deﬁning other models.

The infrastructure builder provides minimal but nec-

essary syntactic and semantic constructions allowing

experts to deﬁne evolution styles. The meta-model is

not given in this paper but can be summarized as fol-

lows:

• an evolution is an aggregation of a domain com-

ponent, a header component and a optionally a

competence component. The proposed theoretical

meta-model explicits various kind of relationship

between components, usually implicit.

• the meta-model is self-deﬁned, that is, is a domain

and an application at the same time. An evolution

core can be extracted from the meta-model and

the resulting evolution styles can be instantiated

to evolve the meta-model itself.

Model at level 1. The need for domain-speciﬁc evo-

lution libraries is the same than for API’s in the

programming language ﬁeld or components in large-

scale development ﬁeld: providing readily available

software units in order to alleviate the amount of

efforts. Styles builders (experts) describe evolution

styles by instantiating the elements of the M2 level

provided by the infrastructure builder. For each do-

main, a topology of styles is built incrementally, pack-

aged and released as an evolution library. Accord-

ing to the M2 level, a topology is also a domain.

The immediate result is that (a) evolution libraries are

viewed as components and hence are more easily dis-

tributable and subsequently integrable, and (b) evolu-

tion libraries can be evolved by instances of evolution

styles expressed at the M2 level. In other words, evo-

lution libraries are built and maintained by evolution

styles.

Model at level 0. The M0 level depicts the instance

of evolution style to evolve applications. The instan-

tiation of a style is performed by the instantiation of

its three components. Indeed, the instantiation of a

domain component engenders an application, the in-

stantiation of a header component engenders valued

parameters and constraints checking while the instan-

tiation of a competence component engenders the be-

havior execution. Note that for this reason, an abstract

evolution style cannot be instantiated.

5 REFACTORING SCENARIO

To illustrate our approach, we consider an object-

oriented system in which we attempt to restructure

some portion of code. This section reinterprets a well-

known refactoring example as an evolution style. Al-

though we present a small evolution style in this sec-

tion, the perspective still remains to build large evo-

lution styles by incremental composition of existing

ones.

EVOLUTION STYLES IN PRACTICE - Refactoring Revisited as Evolution Style

141

5.1 What is Refactoring?

According to Martin Fowler (Fowler, 1999), refac-

toring is a disciplined technique for restructuring an

existing body of code, altering its internal structure

without changing its external behavior. Its heart is a

series of small behavior preserving transformations.

Each transformation (called a ’refactoring’) does lit-

tle, but a sequence of transformations can produce

a signiﬁcant restructuring. Since each refactoring is

small, it’s less likely to go wrong. The system is also

kept fully working after each small refactoring, reduc-

ing the chances that a system can get seriously broken

during the restructuring.

5.2 Extract Method Refactoring

The Extract Method Refactoring consists into taking

a fragment of code inside a subroutine and turning

it into its own routine. The Object-oriented sys-

tems are particularly prone to such a refactoring

activity. The Java source code below, inspired from

Martin Fowler’s Web site’s examples

, clariﬁes the

before&after treatment.

void printOwing() {

printBanner();

//print details

_amount = _amount * 1.5;

System.out.println ("name: " + _name);

System.out.println ("amount " + _amount);

}

-----------------------------------------

AFTER THE EXTRACT METHOD REFACTORING

-----------------------------------------

void printOwing() {

printBanner();

printDetails();

}

void printDetails () {

_amount = _amount * 1.5;

System.out.println ("name: " + _name);

System.out.println ("amount " + _amount);

}

This simple modiﬁcation improves the understand-

ability and the reusability of code to make it easier

for human maintenance in the future. Likewise, the

Extract Method refactoring provides a more natural

pointcut that can be used with AOP (Binkley et al.,

2005).

http://www.martinfowler.com/

5.3 Evolution’s Abstraction

The purpose is to provide a style-based model for ex-

tract method refactoring on object-oriented systems.

Thus, the considered domain is the object-oriented

paradigm here. As an example, the domain is as-

sumed to be FAMIX (Demeyer et al., 1999), a com-

mon exchange model which provides a language-

independent representation of object-oriented source

code. The core presented in ﬁgure 2 is a simplistic

version of FAMIX but adequate here.

Figure 2: Core of FAMIX model.

At ﬁrst glance, the Extract Method pattern can be

summarized with a small set of changes:

1. Addition of a new method in the considered class;

2. Transfer of the considered code (here 1 write ac-

cess plus 2 invocations) from the initial method to

the new one;

3. Addition of an invocation to the new method in

the initial method;

The aforesaid changes are matching with some basic

evolution styles obtained following the methodology

introduced in section 2.4. More precisely, they are ex-

cerpts of projections of the simple operators Add and

Transfer on the FAMIX model. Next, the complex

evolution style named “ExtractMethod” is composed

from the four distinct basic evolution styles presented

in the table 2. The topology represented in ﬁgure 3

is a model for style-based Extract Method refactor-

ing, using the UML and OCL notations. The four

basic evolution styles discussed above and the com-

plex ExtractMethod evolution style are added into the

specialization hierarchy, starting from the three stan-

dardized abstract evolution styles. In this model we

also decided to add a supplementary abstract style

to factorize the common parameters for the transfer

from a method to another one. We have also extended

the initial ExtractMethod style to build the LazyEx-

tractMethod style. In this latter, a new precondition is

ICSOFT 2007 - International Conference on Software and Data Technologies

142

added to avoid to execute the extract method if there

is less than four instructions (accesses or invocations).

Table 2: Basic Evolution styles required.

STYLE OP ENTITIES

AddMethod Add Class x Method

TransferAccess Transfer Method x Method

x Access

TransferInvocation Transfer Method x Method

x Invocation

AddInvocation Add Method x

Invocation

Figure 3: Style-based Extract Method refactoring.

The orchestration of the composition is expressed

into the competence component of the ExtractMethod

style. In the event, the scheduling of the basic styles’

invocations is important to guaranty the scenario to

succeed. This behavioral aspect of evolution style can

be represented in various way. The schedule can be

given in a more abstract way by state models, e.g. ﬁ-

nite state machines or Petri nets, just as with rules,

or as detailed as on code level like in the given ex-

ample. Each representation has its own advantages

and disadvantages, and its choice is only driven by

the style builder needs. To overcome this unreliable

thing, we suggest to externalize the behavioral con-

tent and hence to locate and use it just like a resource.

6 CONCLUSION

In our opinion, providing readily available models of

evolution is a sound way to sustain a mass evolu-

tion. Evolution styles offer re-use beneﬁts, guidance

beneﬁts and communication beneﬁts for the evolution

engineering ﬁeld. In this paper, we explained that

evolution must be exhibited via styles for meaning

and reuse purposes, independently of the technology.

They are mechanisms to push changes through a sys-

tem in a controlled way. In addition, we have shown

how a well-known refactoring can be revisited as a

complex evolution style, built and released by a style

builder, and able to be instantiated on-demand by evo-

lution builders. The refactoring scenario illustrated

the organizational capabilities of our meta-model and

the methodology we provided, using both top-down

approach for style specialization and bottom-up ap-

proach for style composition.

REFERENCES

Bergel, A. (2005). Classboxes — Controlling Visibility of

Class Extensions. PhD thesis, University of Berne.

Binkley, D., Ceccato, M., Harman, M., and Tonella, P.

(2005). Automated pointcut extraction. In Proceed-

ings of the workshop on Linking Aspect Technology

and Evolution workshop.

Castellani, X., Jiang, H., and Billionnet, A. (2001). Method

for the analysis and design of class characteristic mi-

grations during object system evolution. Inf. Syst.,

26(4):237–257.

Cockburn, A. (2002). Agile software development.

Addison-Wesley Longman Publishing Co., Inc.,

Boston, MA, USA.

Demeyer, S., Tichelaar, S., and Steyaert, P. (1999). FAMIX

2.0 - the FAMOOS information exchange model.

Technical report.

Ducasse, S., Nierstrasz, O., Schärli, N., Wuyts, R.,

and Black, A. P. (2006). Traits: A mechanism for

ﬁne-grained reuse. ACM Trans. Program. Lang. Syst.,

28(2):331–388.

Erich GAMMA, Richard HELM, R. J. and VLISSIDES,

J. (1995). Design Patterns : Elements of Reusable

Object-Oriented Softwares. Addison Wesley.

Fowler, M. (1999). Refactoring: improving the design of

existing code. Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA.

Greenﬁeld, A. (2006). Everyware : The Dawning Age of

Ubiquitous Computing. New Riders Press.

Nierstrasz, O., Denker, M., G

ırba, T., and Lienhard, A.

(2006). Analyzing, capturing and taming software

change. In Proceedings of the Workshop on Revival

of Dynamic Languages (co-located with ECOOP’06).

Oussalah, M. (2002). Component-oriented kbs. In SEKE

’02: Procee dings of the 14th international conference

on Software engineering and knowledge engineering,

pages 73–76, New York, NY, USA. ACM Press.

EVOLUTION STYLES IN PRACTICE - Refactoring Revisited as Evolution Style

143