a formalism for transformational software evolution

A Formalism forTransformational Software Evolution

Programming Technology Lab

Vrije Universiteit Brussel, Belgium

Tom Mens

[email protected]

http://prog.vub.ac.be/~tommens







2March 2001, Lisbon © Mens Tom, Programming Technology Lab

Need better tool support for

version control e.g. upgrading application frameworks

collaborative software development software merging

change management change propagation change impact analysis & effort estimation ripple effect ...

evolution at a high level of abstraction evolution of design patterns, refactorings architectural evolution ...

object-orientedsoftwareevolution


Need better tool support for

co-evolution between different phases maintaining consistency checking compliance between architecture and design, design and

implementation, ... re-engineering of legacy systems

program comprehension reverse engineering migration ...

empirical research on software evolution based on change metrics predictive models ...


Tool support must be

scalableapplicable to large-scale software systems

“A major challenge for the research community is to develop a good theoretical understanding an underpinning for maintenance and evolution, which scales to industrial applications.” [Bennett&Rajlich 2000]

domain-independent independent of the programming or modelling

languagegenerally applicable in all phases of the software life-

cycle


Our Approach:Reuse Contracts

Usegraph rewriting

to provide aformal foundation

forsoftware evolution

based onreuse contracts

http://prog.vub.ac.be/poolresearch/rcs/


Reuse Contracts Overview

Benefits of reuse contracts(illustrated with a simple example)

1. Document reuse and evolution

2. Deal with upgrade problems

3. Provide support for software merging

4. Provide support for framework refactoring

Generalising reuse contracts(using formalism of graph rewriting)

1. Apply reuse contracts to different domains analysis, architecture, design, implementation

2. Scale up reuse contracts to high-level transformations


1. Documenting Reuse

DesktopFolderpositioncontentsmove:add:addMany:

SizedFolder

add: item

size

reuseExtension(size, attribute)

Refinement(add, size, updates)

size =+ item.size



1. Documenting Evolution

evolution

Coarsening(addMany, add, invokes)



2. Dealing with Upgrade Problems


evolution


reuse

size not updated whenadding many items

SizedFolder

add: item

sizesize =+ item.size SizedFolder

add: item

size size =+ item.size




evolution


SizedFolder

add:

size

reuse Coarsening(addMany, add, invokes)

Extension(size, attribute)Refinement(add, size, updates)

inconsistent operation conflict


Conflict Table


extension

refinement

coarsening

extension refinement coarsening

no conflicts

no conflicts inconsistent operations

interfaceconflicts

operation capture,unanticipated recursion

operation capture,inconsistent operations

no conflicts no conflicts

operation capture,inconsistent operations

extension/cancellation: adding/removing an operation or attribute

refinement/coarsening: adding/removing invocation or attribute access

abstraction/concretisation: making an operation abstract/concrete


3. Support for Software Merging


evolution

DesktopFolder v1contentsadd:addMany:

evolutionExtension(position, attribute)Extension(move:, method)

Coarsening(addMany, add, invokes)

Extension(size, attribute)Refinement(add, size, updates)


DesktopFolder v2acontentssizeadd:addMany:


4. Support for FW Refactoring

Refactoring conflict !

Bank

Account

Loan

handlesCompany SplitClass

(Bank,[Bank,Agency])Agency

Account

Loanhandles

Bank Company

represents

AddClass(Safe)AddAssociation(Bank,Safe)

Bank

Account

Loanhandles

Company

Safe

Need for higher-level evolution transformationsNeed for user-defined conflict resolution


Reuse Contract Formalism

Domain-independent formalism Independent of the target language Independent of the phase in the life-cycle

Lightweight formalism to facilitate tool supportRepresent software artifacts by graphsRepresent software evolution by graph rewritingFormal characterisation of evolution conflicts


Graphs

G

Triangle «class»

Circle «class»

«inherits»

intersects «operation»

«assoc»

center

radius «attribute»

«aggregation»

vertices

{3}

Point «class»Shape «class»

area «operation»

circumference «operation»

x «attribute»

distanceTo «operation»

y «attribute»

«inherits»

Internal Graph Representation

+intersects(c: Circle)

-radius

Circle

+distanceTo(p: Point)

-x-y

Point

Triangle

+area()+circumfere()

Shapecenter

vertices 3

Example: UML class diagram Node types:

«class» «attribute» «operation» «interface»

Edge types: «assoc» «aggregation» «inherits» «implements» «accesses» «updates» «invokes»


Type Graph

v

e

node type

edge type

implements

nested

operation

attribute

interface

class

assoc, aggregation, inherits

inherits

updates, accesses

invokes

nested

nested

Used to specifydomain-specific constraints

Specify extra constraints declaratively


P

m

R

area «operation»

radius «attribute»«accesses»

G

Circle «class»

area «operation»

«accesses»



H

Circle «class»

area «operation»«accesses»



L

area «operation»


Graph Rewriting

Used to specify software evolution


Use restricted set of graph productions AddNode DropNode AddEdge DropEdge RetypeNode RetypeEdge RelabelNode RelabelEdge

Primitive Graph Productions

AddEdge(area,radius,«accesses»)

R

area «operation»


«a

ccesse

s»

L «a

ccesse

s»

area «operation»


DropNode(Triangle.area,«operation»)

R

Triangle

L

«operation»area

Triangle


Primitive Graph Productions

evolution

reuse DropEdge(addMany, add, «invokes»)

AddNode(size, «attribute»)AddEdge(add, size, «updates»)


SizedFolder «class»

size «attribute»

add: «operation»

DesktopFolder «class»

position «attribute»

contents «attribute»

move: «operation»

add: «operation»

addMany: «operation»

DesktopFolder «class»

position «attribute»

contents «attribute»

move: «operation»

add: «operation»

addMany: «operation»

«in

voke

s»«

up

da

tes»


Syntactic Conflicts

P1

P2 = DropNode(area,«operation»)

P1 = AddEdge(area,radius,«accesses»)P2

P1

P2

Undefined source conflict

Syntactic conflict if P1 and P2 are not parallel independent

G

Circle «class»

area «operation»

circumfere «operation»


<<uses>>

G2

Circle «class»



G1

Circle «class»

area «operation»


radius «attribute» «accesses»

«accesses»


Syntactic Conflicts

Use a syntactic conflict table Detect syntactic merge conflicts

in terms of transformation preconditions compare breaches of application preconditions

Advantages general

does not rely on predefined graph produtions scalable

can be used directly for composite or domain-specific graph productions


Syntactic Conflicts

-i +i source(e,v)

target(e,v)

label(i,L)

type(i,T)

-source(e,v)

-target(e,v)

-j if i=j

if i=j

if j=e if j=v

if j=e if j=v

if i=j if i=j if j=v if j=v

+j C1 if

i=j

C2 if e=j if v=j

C3 if e=j if v=j

C4 if i=j C5 if i=j C6 if j=vC7 if j=e

C8 if j=vC9 if j=e

source(f,w)

C10 if (e,v)=(f,w) if v=w

if (e,v)=(f,w)

target(f,w)

C11 if (e,v)=(f,w) if v=w

if (e,v)=(f,w)

label(j,L2)

C12 if i=j

type(j,T2)

C13 if i=j

-source(f,w)

C14 if e=f and vw

-target(f,w)

C15 if e=f and vw


Semantic Conflicts

L1

area «operation»


R1

area «operation»


G

Circle «class»

area «operation»

circumfer «operation»


G1

Circle «class»

area «operation»



«accesses»

«accesses»

m1

AddEdge(,area,radius,«accesses»)

H

Circle «class»

area «operation»



«accesses»

«accesses»

«invokes»

Pusho

ut

cons

tructi

on

L2

area «operation»


R2

area «operation»


«invokes»

G2

Circle «class»

area «operation»

«accesses»


radius «attribute»«invokes»

Refinement(,area,circumference,«uses»)

m2

L

area «operation»

Pullbac

k

constr

uction

area «operation»

area «operation»


Based on the formal notion of pushouts and pullbacks

Fine-grained conflict characterisation By detecting occurrence of graph patterns in result graph

Semantic Conflicts

addMany add size

«updates»

«invokes»

{added during reuse}

{removed during evolution}

inconsistent method conflict

«class»?

«class»?

«inherits»

«inherits»

{added by developer 2}

{added by developer 1}

cyclic inheritance


Structural Conflicts

Refactoring conflict !

Bank

Account

Loan

handlesCompany SplitClass

(Bank,[Bank,Agency])Agency

Account

Loanhandles

Bank Company

represents

AddClass(Safe)AddAssociation(Bank,Safe)

Bank

Account

Loanhandles

Company

Safe

More difficult to detect in a general wayCustomise conflict table with user-defined and domain-specific conflict resolution rules


Addressing Scalability

Use assertions to describe productions preconditions, postconditions, invariants

Use dependencies to address scalability1. Defining “atomic” composite productions from a

production sequence2. Reordering productions in a sequence3. Removing redundancy in a production sequence4. Factoring out commonalities from parallel production

sequences5. Parallellising subsequences


Example ctd.

L

Bank

Account

Loan

handles1

2

3

P

source(,3) source(,3)

+(,3,4,represents,assoc)+(4,Agency,class)

+1, +2, +3, +, +

-4

target(,1), target(,1)

source(,4) source(,4)

preconditions

invariants

R

Agency

Account

Loanhandles

Bank

represents1

2

3

4

postconditions


Using dependencies

Dependencies can be defined between productions based on relations between assertions

AddEdge(,3,4,represents,assoc)

DropEdge(,3,4)

-

label(,represents)

+

+3

type(,assoc)

source(,3)

-+3

+ target(,4) +4

+4source(,3)

target(,4)

-label(,*) -type(,*)


1. Composite productions

AddNode(4,Agency,class)

-4

type(4,class)+4 label(4,Agency)

RelabelNode(4,Agency,BankAgency)

label(4,Agency)

+4

label(4,BankAgency)

-4

+4 label(4,BankAgency) type(4,class)

(a) Calculate dependencies between productions in the sequence

(b) Calculate pre/postconditions of composite in terms of this information


2. Reordering productions




-

label(,represents)

+ target(,4)

source(,3)

+4 +3type

(,assoc)


label(4,Agency)

+4

label(4,BankAgency)

-4



-4


label(4,Agency)

+4

label(4,BankAgency)


-

label(,represents)

+ target(,4)

source(,3)

+4 +3type

(,assoc)


3. Removing redundancy

Simplify a production sequence

AddN(4)

AddN(3) AddN(4)RelabelN(1,2) AddE(,3,4)RetypeN(2) DropE(,3,4) DropN(3)

AddN(3) AddN(4) DropN(3)

AddN(3)AddN(4) DropN(3)

redundant pair

reorder

redundant pair


3. Removing Redundancy

-

+3

+4


DropEdge(,3,4)

-

label(,represents)

+

+3

type(,assoc)

source(,3)

-+3

+ target(,4) +4

+4source(,3)

target(,4)

-label(,*) -type(,*)


4. Factoring out commonalities

Find commonalities in two parallel sequences, and factor out facilitates merging and conflict detection

GP

H 1

H 2

QG

V 1H 1

H 2

V2

HC


Validation of Reuse Contracts

Industrial caseOne base release linemany customisations for

customer applicationsCollaborative software

developmentparallel changes to base

release and customisations

Provide support for customisation, refactoring,

upgrading, consolidation

7.2

7.4

10.x

11

12

NDR

DR

WDR 0.1

VTM

TV2

WDR 1.0

WDR 2.0


To Do

User-friendly tool support Perform large-scale experiments Validate scalability

Look at conflict resolution techniques Look at structural conflicts (refactoring) Address co-evolution


Future Research: Co-Evolution

Underlying ideaKeep representation of same software artifact at

different levels of abstraction (e.g. design and implementation) synchronised during evolution

Use triple graph grammars

refinement

abstractlayer

concretelayer

consistent???evolution

evolution

a formalism for transformational software evolution

Documents

lisbon mens tom

programming technology

programming technology

belgium tom

reuse contractshttp

reuse contractsuse graph

software lifecyclemarch

simple exampledocument