1 A Graph Rewriting Formalism for Object-Oriented Software Evolution Tom Mens [email protected] FWO Postdoctoral Fellow Programming Technology Lab Vrije Universiteit Brussel Belgium
1 A Graph Rewriting Formalism for Object-Oriented Software Evolution Tom Mens [email protected] FWO Postdoctoral Fellow Programming Technology Lab Vrije.
Mar 31, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
A Graph Rewriting Formalism forObject-Oriented Software Evolution
A Graph Rewriting Formalism forObject-Oriented Software Evolution
Tom [email protected] Postdoctoral Fellow
Programming Technology Lab
Vrije Universiteit Brussel
Belgium
2ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Thesis StatementThesis Statement
A formal foundation (of reuse contracts) allows us to deal with (object-oriented)
software evolution in a domain-independent and scalable way.
3ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
OverviewOverview
Formal techniques enable domain-independence independent of the considered (OO) programming language
e.g., Smalltalk, Java, C++, … independent of the phase in the software life-cycle
e.g., analysis, software architecture, design, implementation
Provide formalism based on graph rewriting Represent software by graphs Represent software evolution by graph rewriting
Use formalism to support software merging and upgrading Provide formal characterisation of merge conflicts Facilitate detection (and resolution) of conflicts
4ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
workstation 1
fileserver 1
workstation 2printer 1
workstation 3
1. originate(p)
2. send(p)
3. accept(p)
4. send(p)
5. accept(p)
6. send(p)7. accept(p)
8.print(p)
Running example: LAN simulationRunning example: LAN simulation
5ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: UML class diagramExample: UML class diagram
accept(p:Packet)originate(p:Packet)
Workstation
contents
Packet
accept(p:Packet)send(p:Packet)
Nodeoriginator
name
accept(p:Packet)print(p:Packet)
PrintServer
accept(p:Packet)save(p:Packet)
FileServer
addresseenextNode
6ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: graph representationExample: graph representation
«assoc» originatorPacket «class»Node «class»
accept «operation»
send «operation»
«inherit»
Vertex types:
«class»
«attribute»
«operation»
. . .
Edge types:
«assoc»
«inherit»
«invoke»
«access»
«update»
. . .
«assoc» addressee
name «attribute»
contents «attribute»
Workstation «class»
accept «operation»
originate «operation»
Transcript «class»
println «operation»
nextNode «attribute»«access»
«access»
«invoke»
«invoke»«invoke»
«invoke»
«invoke»
7ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: type graphExample: type graph
nested
operation
attributeclass
assoc, inherit
updateaccess
invoke
nested
Use type graph to specify domain-specific constraints
8ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Use restricted set of primitive graph productions with application preconditions to specify software evolution
AddVertex
DropVertex
AddEdge
DropEdge
RetypeVertex
RetypeEdge
RedirectSource
RedirectTarget
RelabelVertex
RelabelEdge
Evolution by graph productionsEvolution by graph productions
AddEdge(invoke,send,getName)
getName «operation»
send «operation»
«invoke»
getName «operation»
send «operation»
«invoke»
RedirectSource(access,send,name,getName)
send «operation»
name «attribute»
«access»
getName «operation»
«access»
send «operation»
name «attribute»
getName «operation»
«access»
9ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: software evolutionExample: software evolution
P1: Add accessor operation getName for attribute name
Node «class»
accept «operation»
send «operation»
name «attribute»
nextNode «attribute»«access»
«access»
«invoke»
«in
voke
»
Node «class»
accept «operation»
send «operation»
name «attribute»
nextNode «attribute»
«access»
«invoke»
«invoke»
getName «operation»
«in
voke
»«
acc
ess
»
AddVertex(operation,getName)RedirectSource(access,send,name,getName)
AddEdge(invoke,send,getName)
send «operation»
name «attribute»
«access»
getName «operation»
name «attribute»
«access»
send «operation»
«invoke»
P1
10ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: software evolutionExample: software evolution
P2: Factor out logging behaviour
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»«access»
«access»
«invoke»
«in
voke
»«
invo
ke»
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»
«access»
«invoke»
«invoke»
«in
voke
»
log «operation»
«in
voke
»«
acc
ess
»
AddVertex(operation,log)AddEdge(invoke,send,log)
RedirectSource(invoke,send,println,log)RedirectSource(access,send,name,log)
send «operation»
name «attribute»
«access»
println «operation»
«invoke»send «operation»
name «attribute»
«access»
println «operation»«invoke»
log «operation»«invoke»
P2
11ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»«access»
«access»
«invoke»
«inv
oke»
«inv
oke»
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»
«access»
«invoke»
«invoke»
«inv
oke»
log «operation»
«inv
oke»
«acc
ess»
Node «class»
accept «operation»
send «operation»
name «attribute»
nextNode «attribute»
«access»
«invoke»
«invoke»
getName «operation»
«inv
oke»
«acc
ess»
send «operation»
name «attribute»
«access»
getName «operation»
name «attribute»
«access»
send «operation»
«invoke»
send «operation»
name «attribute»
println «operation»
«access»
«invoke»
send «operation»
name «attribute»
println «operation»
«access»
«invoke»
log «operation»«invoke»
send «operation»
name «attribute»
«access»
Example: Software MergingExample: Software Merging
Use pullback to detect potential merge conflicts
P2
P1
12ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»«access»
«access»
«invoke»
«inv
oke»
«inv
oke»
Node «class»
accept «operation»
send «operation»
name «attribute»
Transcript «class»
println «operation»
nextNode «attribute»
«access»
«invoke»
«invoke»
«inv
oke»
log «operation»
«inv
oke»
«acc
ess»
Node «class»
accept «operation»
send «operation»
name «attribute»
nextNode «attribute»
«access»
«invoke»
«invoke»
getName «operation»
«inv
oke»
«acc
ess»
Example: Software MergingExample: Software Merging
AddVertex(operation,log)
AddEdge(invoke,send,log)
RedirectSource(invoke,send,println,log)
RedirectSource(access,send,name,log)
AddVertex(operation,getName)
RedirectSource(access,send,name,getName)
AddEdge(invoke,send,getName)
• Conflict if productions are parallel dependent• Detect by violations of application preconditions
syntactic conflict !
13ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Example: Software MergingExample: Software Merging
RedirectSource(access,send,name,log)
send «operation»
name «attribute»
log «operation»
«a
cce
ss»
getName «operation»
send «operation»
name «attribute»
log «operation»
«a
cce
ss»
getName «operation»
send «operation»
name «attribute»
log «operation»
getName «operation»
«a
cce
ss»
RedirectSource(access,send,name,getName)
precondition edge (access,send,name)
not satisfied !
precondition edge (access,send,name)
not satisfied !
mergeconflict
Can be implemented efficiently using conflict table
14ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
Addressing scalabilityAddressing scalability
Normalisation algorithm Removes redundant productions in a sequence Reorders the remaining productions into a canonical form
Predefine composite productions as sequences of productionsSplitMethod(m1,m2,OutEdges) =
AddVertex(operation,m1), AddEdge(invoke,m1,m2),
RedirectSource(type,m1,target,m2) forall (type,target) in OutEdges
P1 = SplitMethod(send,log,{(invoke,println),(access,name)}) Use high-level information about the evolution transformations to
detect and resolve evolution conflicts Formalisation of object-oriented refactorings
Detect their applicability; ensure their behaviour-preservation; analyse their complexity
Evolution of design pattern instances“A Declarative Evolution Framework for Object-Oriented Design Patterns”. Tom Mens, Tom Tourwe, ICSM 2001
15ICSM, November 2001, Firenze © Tom Mens, Vrije Universiteit Brussel
ConclusionConclusion
Conditional graph rewriting is a feasible and useful formalism to address the problem of software merging in a domain-independent way.
Further work needed practical validation in industrial setting integrate ideas in CASE tools of IDEs address scalability better deal with conflict resolution
Related Documents
