Formal Foundations for Software Evolution Programming Technology Lab Tom Mens [email protected]...

Formal Foundationsfor Software Evolution

Programming Technology Lab

Tom Mens

[email protected]

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







2January 2001 © 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


Strategy

Use lightweight formalismsdeclarative reasoninggraph rewriting

Tackle problems from formal as well as practical sideBottom-up approach: rely on existing formalisms to

provide a clear and unambiguous definition of evolution problems

Top-down approach: look at real-world situations to ensure usefulness and scalability


General Setup

declarativerepresentation

declarativereasoning engine

(for software evolution)

high-level descriptions and transformations(e.g. design patterns and refactoring)

implementation(source coderepository)

formal definitions and properties

rep

rese

nta

tio

nal

map

pin

g


Presentation overview

Bottom-up approach Graph rewriting as a formal foundation for software evolution

Based on the idea of reuse contracts

Top-down approach Support evolution of design patterns

Use declarative metaprogramming as a technique

Future Research Intrests uniform use of graph rewriting or declarative programming co-evolution support ...


Bottom-up approach:Reuse Contracts

Usegraph rewriting

to provide aformal foundation

forsoftware evolution

based onreuse contracts


Reuse Contracts Overview

1. 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

2. Generalising reuse contracts(using formalism of graph rewriting)

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

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

Prototype tool implemented in Prolog


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()+circumference()

Shapecenter

vertices 3

Example: UML class diagram Node types:

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

Edge types: «assoc» «aggregation» «inherits» «implements»


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»


radius «attribute»«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,«uses»)P2

P1

P2

Undefined source conflict

Syntactic conflict if P1 and P2 are not parallel independent

G

Circle «class»

area «operation»

perimeter «operation»

radius «attribute»«uses»

<<uses>>

G2

Circle «class»


radius «attribute»«uses»

G1

Circle «class»

area «operation»


radius «attribute» «uses»

«uses»


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


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


Using dependencies

Dependencies can be used to address scalability1. Defining “atomic” composite productions from a

sequence of productions

2. Reordering productions in a sequence

3. Removing redundancy in a production sequence

4. Factoring out commonalities from parallel production sequences

5. Parallellising subsequences


1. Composite productions

AddN (b!,perimeter, attribute )

-b

label(b,perimeter)+b type(b, attribute )

RetypeN (b, attribute ,operation )type(b, attribute )

+b

type(b, operation )

-b

+b type(b, operation ) label(b,perimeter)

1. Define dependencies between productions based on relations between pre/postconditions and assertions

2. Calculate pre/postconditions of composite in terms of this information


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


Top-down approach: Declarative metaprogramming

Goal: use declarative reasoning as a technique for managing evolutionManaging refactoringManaging design patternsManaging co-evolution ...


What is DMP?

combines declarative meta language with object-oriented base languagee.g. Prolog (SOUL) and Smalltalk (Squeak)

explicit symbiosis between meta language and base language representational mapping: base-level programs can

be manipulated as terms, facts or rules in the meta level

allows declarative reasoning over, and manipulation of, object-oriented programs


Current Focus

Use DMP for supporting1. Evolution conflicts (detection and resolution)

use DMP instead of graph rewriting to support reuse contracts

(High-level) refactoring transformations Evolution of design patterns

Design pattern variants Design pattern detection Design pattern generation Design pattern evolution

Co-evolution between design and implementation


Evolving Design Patterns:Dealing with variants

Abstract Factory variant 1uses factory methods

MSLook

newWindownewButton

MacLook

newWindownewButton

Look

newWindownewButton

Widget

Window Button

MSWindow

MacWindowMacButton

MSButton



Abstract Factory variant 2uses prototype and singleton pattern

<<public>> create: aName<<private>> addProduct: aProduct named: aName

<<class method>> MacLook

<<class method>> MSLook

WindowLook

products

Widget

Button

MSWindow

MacWindow MacButton

MSButton

aMSLook : Look

products={(#newWindow,MSWindow),(#newButton,MSButton)}

aMacLook : Look

products={(#newWindow,MacWindow),(#newButton,MacButton)}



Declarative specification ofAbstract Factory common part:

patternInstance(AF1,abstractFactory).role(AF1,abstractFactory,Look).role(AF1,concreteFactory,MSLook).

role(AF1,concreteFactory,MacLook).role(AF1,genericProduct,Widget).role(AF1,abstractProduct,Window).

role(AF1,abstractProduct,Button).role(AF1,concreteProduct,[MSWindow,Window]).

role(AF1,concreteProduct,[MSButton,Button]).role(AF1,concreteProduct,[MacWindow,Window]).role(AF1,concreteProduct,[MacButton,Button]).

role(AF1,absRelation,[Look,Window]).role(AF1,absRelation,[Look,Button]).

role(AF1,conRelation,[MSLook,MSWindow]).role(AF1,conRelation,[MacLook,MacWindow]).role(AF1,conRelation,[MSLook,MSButton]).role(AF1,conRelation,[MacLook,MacButton]).



Declarative specification of Abstract Factory variant 1

pattern(absFacVariant1,abstractFactory, [abstractFactoryMethod,concreteFactoryMethod]).

patternInstance(AF2,absFacVariant1).

role(AF2,abstractFactoryMethod,[newWindow,Look]).role(AF2,abstractFactoryMethod,[newButton,Look]).role(AF2,concreteFactoryMethod,[newWindow,MSLook]).role(AF2,concreteFactoryMethod,[newWindow,MacLook]).role(AF2,concreteFactoryMethod,[newButton,MSLook]).role(AF2,concreteFactoryMethod,[newButton,MacLook]).



Declarative specification ofAbstract Factory variant 2

pattern(absFacVariant2,abstractFactory,[productDictionary,addProductMethod,productCreationMethod]).

patternInstance(AF2,absFacVariant2).

role(AF2,productDictionary,[products,Look]).role(AF2,addProductMethod,[addProduct:named:,Look]).role(AF2,productCreationMethod,[create:,Look]).



Declarative constraints for Abstract Factory variant 1

rule patternConstraint(?I,abstractFactory) if ! ?AF such that role(?I,abstractFactory,?AF) % there must be exactly one abstract factory

rule patternConstraint(?I,abstractFactory) if ?AF such that role(?I,abstractFactory,?AF): ?CF such that role(?I,concreteFactory,?CF): hierarchy(?AF,?CF) % all concrete factories must be descendants of the abstract factory ?C such that concreteSubclass(?AF,?C): role(?I,concreteFactory,?C) % all concrete subclasses of the abstract factory must be concrete factories

...


Evolving Design Patterns:Evolution transformations

Abstract Factory evolution 1: addConcreteFactory(LinuxLook)

MSLook

newWindownewButton

MacLook

newWindownewButton

Look

newWindownewButton

LinuxLook

newWindownewButton

Widget

Window Button

MSWindow

MacWindowMacButton

LinuxButtonLinuxWindow

MSButton



rule addConcreteFactory(abstractFactory,?I,[?CF]) if addRole(?I,concreteFactory,?CF), ?AP such that role(?I,abstractProduct,?AP): input('Name of concrete ?AP created by concrete ?CF factory',[?AP,?CF],?CP), addRole(?I,concreteProduct,[?CP,?AP]), addRole(?I,concreteRelation,[?CF,?CP]), ?Method such that role(?I,abstractFactoryMethod,[?Method,_]): addRole(?I,concreteFactoryMethod,[?Method,?CF])

query addConcreteFactory(abstractFactory,AF,[LinuxLook])

User input:• Name of concrete Window created by concrete LinuxLook factory: LinuxWindow• Name of concrete Button created by concrete LinuxLook factory: LinuxButton



Abstract Factory evolution 2: addAbstractProduct(Menu)

MSLook

newWindownewButtonnewMenu

MacLook


Look


Widget

WindowButton

MSWindow

MacWindowMacButton

MSButton

MacMenu

MSMenu

Menu


Evolving Design Patterns:Evolution conflicts

Straighforward merging of both evolved versions does not work: the Menu class does not contain a LinuxMenu subclass the LinuxLook class does not contain a newMenu factory

method

Solution: specify the design pattern transformations declaratively apply these transformations one after the other



MSLook


MacLook


Look


LinuxLook


Widget

WindowButton

MSWindow

MacWindowMacButton

LinuxButtonLinuxWindow

MSButton

MacMenu

MSMenu

Menu

LinuxMenu

End result after having applied both transformations:



Composite design pattern version 1:composite method generate with internal action and

postorder traversal

SumProduct

parts

Expression

bytecode

generate: Stream

Number

Int

generate: Stream

Float

generate: Stream

CompoundExpr

generate: Stream {traversal(postorder), action(internal)}

Division Subtract



Composite version 2a:generate action is externalised

SumProduct

parts

Expression

bytecode

generate: Stream

Number

Int

generate: Stream{v.genInt(self)}

Float

generate: Stream{v.genFloat(self)}

CompoundExpr

generate: Stream {traversal(postorder), action(external)}

Division Subtract

CodeGenerator

genComp: CompoundExprgenInt: IntgenFloat: Float

v



Composite version 2b:composite method serialise is added

SumProduct

parts

Number

Division Subtract

Expression

bytecode

generate: Streamserialise: Stream

CompoundExpr

generate: Stream {traversal(postorder), action(internal)}

serialise: Stream {traversal(preorder), action(internal)}

Float


Int




Merging version 2a and 2b gives a problem:serialise action must be externalised first

SumProduct

parts

Number

Int

generate: Stream {v.genInt(self)}

serialise: Stream {v.serInt(self)}

Float

generate: Stream {v.genFloat(self)}

serialise: Stream {v.serFloat(self)}

Division Subtract

CodeGenerator

genComp: CompoundExprgenInt: IntgenFloat: Float

v

CompoundExpr

generate: Stream {traversal(postorder), action(external)}

serialise: Stream {traversal(preorder),action(external)}

Expression

bytecode

generate: Streamserialise: Stream Serialiser

serComp: CompoundExprserInt: IntserFloat: Float



Visitor design pattern version 1

SumProduct

parts

Expression

bytecode

accept: TreeVisitor

Number

Int

accept: TreeVisitor {v.visitInt}

Float

accept: TreeVisitor {v.visitFloat}Division Subtract

v

TreeVisitor

visitComp: CompoundExprvisitInt: IntvisitFloat: Float

CompoundExpr

accept: TreeVisitor {visit(visitComp)}

CodeGenerator

visitComp: CompoundExpr {traversal(postorder)}

visitInt: IntvisitFloat: Float

Serialiser

visitComp: CompoundExpr {traversal(preorder)}




Two parallel evolutions: Add a TypeChecker visitor Factor out the traversal algorithm from the visitor using a

Strategy pattern

Behavioural conflict The parallel evolutions cannot be merged correctly: For type checking, accept in CompoundExpr needs to be

overwritten in a subclass Division For the refactoring, accept in CompoundExpr must be

reimplemented to take into account the traversal strategy Solution: Use conflict table approach a la reuse contracts?



Merging both parallel evolutions gives a behavioural conflict

Sum

Product

parts

Expression

bytecode

accept: TreeVisitor

NumberInt

accept: TreeVisitor {v.visitInt}

Float

accept: TreeVisitor {v.visitFloat}

Subtract

v

CompoundExpr

accept: TreeVisitor{v.visitComp}

Division

accept: TreeVisitor {v.visitDiv}

TraversalStrategy

PreOrder PostOrder

s

TreeVisitor

createTraversalvisitComp: CompoundExprvisitInt: IntvisitFloat: FloatvisitDivision: Division

CodeGenerator

createTraversalvisitComp: CompoundExpr {traversal(postorder)}


Serialiser

createTraversalvisitComp: CompoundExpr {traversal(preorder)}


TypeChecker

createTraversalvisitComp: CompoundExpr {traversal(postorder)}

visitInt: IntvisitFloat: FloatvisitDiv: Division


3. Co-Evolution

Underlying ideaKeep representation of same software artifact at

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

refinement

abstractlayer

concretelayer

consistent???evolution

evolution


WHAT NEXT ???

Possible ways of cooperation? Concrete experiments? Applying FAMOOS tools in the context of

software evolution? Applying reuse contract ideas in FAMOOS

context?

Formal Foundations for Software Evolution Programming Technology Lab Tom Mens [email protected]...

Documents

Transcript of Formal Foundations for Software Evolution Programming Technology Lab Tom Mens [email protected]...