a formalism for transformational software evolution
DESCRIPTION
A Formalism for Transformational Software Evolution. Programming Technology Lab Vrije Universiteit Brussel, Belgium To m Mens to [email protected] http://prog.vub.ac.be/~tommens. Need better tool support for. version control e.g. upgrading application frameworks - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/1.jpg)
A Formalism forTransformational Software Evolution
Programming Technology Lab
Vrije Universiteit Brussel, Belgium
Tom Mens
http://prog.vub.ac.be/~tommens
![Page 2: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/2.jpg)
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
![Page 3: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/3.jpg)
3March 2001, Lisbon © Mens Tom, Programming Technology Lab
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 ...
![Page 4: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/4.jpg)
4March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 5: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/5.jpg)
5March 2001, Lisbon © Mens Tom, Programming Technology Lab
Our Approach:Reuse Contracts
Usegraph rewriting
to provide aformal foundation
forsoftware evolution
based onreuse contracts
http://prog.vub.ac.be/poolresearch/rcs/
![Page 6: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/6.jpg)
6March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 7: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/7.jpg)
7March 2001, Lisbon © Mens Tom, Programming Technology Lab
1. Documenting Reuse
DesktopFolderpositioncontentsmove:add:addMany:
SizedFolder
add: item
size
reuseExtension(size, attribute)
Refinement(add, size, updates)
size =+ item.size
![Page 8: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/8.jpg)
8March 2001, Lisbon © Mens Tom, Programming Technology Lab
DesktopFolderpositioncontentsmove:add:addMany:
1. Documenting Evolution
evolution
Coarsening(addMany, add, invokes)
DesktopFolderpositioncontentsmove:add:addMany:
![Page 9: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/9.jpg)
9March 2001, Lisbon © Mens Tom, Programming Technology Lab
2. Dealing with Upgrade Problems
DesktopFolderpositioncontentsmove:add:addMany:
evolution
DesktopFolderpositioncontentsmove:add:addMany:
reuse
size not updated whenadding many items
SizedFolder
add: item
sizesize =+ item.size SizedFolder
add: item
size size =+ item.size
![Page 10: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/10.jpg)
10March 2001, Lisbon © Mens Tom, Programming Technology Lab
2. Dealing with Upgrade Problems
DesktopFolderpositioncontentsmove:add:addMany:
evolution
DesktopFolderpositioncontentsmove:add:addMany:
SizedFolder
add:
size
reuse Coarsening(addMany, add, invokes)
Extension(size, attribute)Refinement(add, size, updates)
inconsistent operation conflict
![Page 11: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/11.jpg)
11March 2001, Lisbon © Mens Tom, Programming Technology Lab
Conflict Table
2. Dealing with Upgrade Problems
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
![Page 12: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/12.jpg)
12March 2001, Lisbon © Mens Tom, Programming Technology Lab
3. Support for Software Merging
DesktopFolderpositioncontentsmove:add:addMany:
evolution
DesktopFolder v1contentsadd:addMany:
evolutionExtension(position, attribute)Extension(move:, method)
Coarsening(addMany, add, invokes)
Extension(size, attribute)Refinement(add, size, updates)
inconsistent operation conflict
DesktopFolder v2acontentssizeadd:addMany:
![Page 13: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/13.jpg)
13March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 14: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/14.jpg)
14March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 15: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/15.jpg)
15March 2001, Lisbon © Mens Tom, Programming Technology Lab
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»
![Page 16: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/16.jpg)
16March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 17: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/17.jpg)
17March 2001, Lisbon © Mens Tom, Programming Technology Lab
P
m
R
area «operation»
radius «attribute»«accesses»
G
Circle «class»
area «operation»
«accesses»
circumference «operation»
radius «attribute»
H
Circle «class»
area «operation»«accesses»
circumference «operation»
radius «attribute»«accesses»
L
area «operation»
radius «attribute»
Graph Rewriting
Used to specify software evolution
![Page 18: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/18.jpg)
18March 2001, Lisbon © Mens Tom, Programming Technology Lab
Use restricted set of graph productions AddNode DropNode AddEdge DropEdge RetypeNode RetypeEdge RelabelNode RelabelEdge
Primitive Graph Productions
AddEdge(area,radius,«accesses»)
R
area «operation»
radius «attribute»
«a
ccesse
s»
L «a
ccesse
s»
area «operation»
radius «attribute»
DropNode(Triangle.area,«operation»)
R
Triangle
L
«operation»area
Triangle
![Page 19: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/19.jpg)
19March 2001, Lisbon © Mens Tom, Programming Technology Lab
Primitive Graph Productions
evolution
reuse DropEdge(addMany, add, «invokes»)
AddNode(size, «attribute»)AddEdge(add, size, «updates»)
inconsistent operation conflict
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»
![Page 20: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/20.jpg)
20March 2001, Lisbon © Mens Tom, Programming Technology Lab
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»
radius «attribute»«accesses»
<<uses>>
G2
Circle «class»
circumfere «operation»
radius «attribute»«accesses»
G1
Circle «class»
area «operation»
circumfere «operation»
radius «attribute» «accesses»
«accesses»
![Page 21: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/21.jpg)
21March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 22: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/22.jpg)
22March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 23: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/23.jpg)
23March 2001, Lisbon © Mens Tom, Programming Technology Lab
Semantic Conflicts
L1
area «operation»
radius «attribute»
R1
area «operation»
radius «attribute»«accesses»
G
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»«accesses»
G1
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«accesses»
«accesses»
m1
AddEdge(,area,radius,«accesses»)
H
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«accesses»
«accesses»
«invokes»
Pusho
ut
cons
tructi
on
L2
area «operation»
circumfer «operation»
R2
area «operation»
circumfer «operation»
«invokes»
G2
Circle «class»
area «operation»
«accesses»
circumfer «operation»
radius «attribute»«invokes»
Refinement(,area,circumference,«uses»)
m2
L
area «operation»
Pullbac
k
constr
uction
area «operation»
area «operation»
![Page 24: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/24.jpg)
24March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 25: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/25.jpg)
25March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 26: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/26.jpg)
26March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 27: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/27.jpg)
27March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 28: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/28.jpg)
28March 2001, Lisbon © Mens Tom, Programming Technology Lab
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(,*)
![Page 29: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/29.jpg)
29March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 30: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/30.jpg)
30March 2001, Lisbon © Mens Tom, Programming Technology Lab
2. Reordering productions
AddNode(4,Agency,class)
type(4,class)+4 label(4,Agency)
AddEdge(,3,4,represents,assoc)
-
label(,represents)
+ target(,4)
source(,3)
+4 +3type
(,assoc)
RelabelNode(4,Agency,BankAgency)
label(4,Agency)
+4
label(4,BankAgency)
-4
AddNode(4,Agency,class)
type(4,class)+4 label(4,Agency)
-4
RelabelNode(4,Agency,BankAgency)
label(4,Agency)
+4
label(4,BankAgency)
AddEdge(,3,4,represents,assoc)
-
label(,represents)
+ target(,4)
source(,3)
+4 +3type
(,assoc)
![Page 31: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/31.jpg)
31March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 32: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/32.jpg)
32March 2001, Lisbon © Mens Tom, Programming Technology Lab
3. Removing Redundancy
-
+3
+4
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(,*)
![Page 33: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/33.jpg)
33March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 34: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/34.jpg)
34March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 35: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/35.jpg)
35March 2001, Lisbon © Mens Tom, Programming Technology Lab
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
![Page 36: A Formalism for Transformational Software Evolution](https://reader036.vdocuments.us/reader036/viewer/2022062423/56814657550346895db3713a/html5/thumbnails/36.jpg)
36March 2001, Lisbon © Mens Tom, Programming Technology Lab
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