420 likes | 432 Views
Formal Foundations for Software Evolution. Programming Technology Lab To m Mens to mmens@vub.ac.be http://prog.vub.ac.be/~tommens. Need better tool support for. version control e.g. upgrading application frameworks collaborative software development software merging change management
E N D
Formal Foundationsfor Software Evolution Programming Technology Lab Tom Mens tommens@vub.ac.be http://prog.vub.ac.be/~tommens
Need better tool support for • version control • e.g. upgrading application frameworks • collaborative software development • software merging • change management • change propagation • change impact analysis • ripple effect • ... • evolution at a high level of abstraction • evolution of design patterns • 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 • scalable • applicable 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] • language-independent • independent of the programming or modelling language • generally applicable in all phases of the software life-cycle
Reuse Contracts Usegraph rewritingto provide aformal foundationforsoftware evolution based onreuse contracts
Benefits of Reuse Contracts • Document reuse and evolution • Deal with upgrade problems • Provide support for software merging • Provide support for framework refactoring • Are independent of kind of software artifact • analysis, architecture, design, implementation
DesktopFolder position contents move: add: addMany: Extension(size, attribute) Refinement(add, size, update) SizedFolder size add: item 1.Documenting Reuse reuse size =+ item.size
DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: Coarsening(addMany, add, calls) 1.Documenting Evolution evolution
DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: SizedFolder SizedFolder size =+ item.size size =+ item.size size size add: item add: item size not updated when adding many items 2.Dealing with Upgrade Problems evolution reuse
DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: SizedFolder size add: 2. Dealing with Upgrade Problems evolution reuse Coarsening(addMany, add, calls) inconsistent operation conflict Extension(size, attribute) Refinement(add, size, update)
2. Dealing with Upgrade Problems • extension/cancellation: adding/removing an operation or attribute • refinement/coarsening: adding/removing invocation or attribute access • abstraction/concretisation: making an operation abstract/concrete Conflict Table extension refinement coarsening interface conflicts extension refinement coarsening no conflicts no conflicts operation capture, unanticipated recursion operation capture, inconsistent operations no conflicts operation capture, inconsistent operations inconsistent operations no conflicts
DesktopFolder v1 DesktopFolder position contents move: add: addMany: contents add: addMany: 3.Support for Software Merging evolution evolution Extension(position, attribute) Extension(move:, method)Coarsening(addMany, add, calls) inconsistent operation conflict DesktopFolder v2a contents size add: addMany: Extension(size, attribute) Refinement(add, size, update)
DesktopItem Folder File size totalSize size PullUpVariable Folder File both calculate item size in bytes size size CreateSubclass Folder File Refactoring conflict ! After merging, size in NestingFolder accidentally overrides size in Folder, which has a different behaviour! totalSize size NestingFolder size size calculates numberof items in a folder 4. Support for FW Refactoring
Problems with reuse contracts • How to scale up to higher-level transformations • e.g. dealing with class collaborations • How to apply to other domains • e.g. software architectures • Solution: Provide a formal foundation for reuse contracts
Reuse Contract Formalism • Represent software artifacts by graphs • Represent software evolution by graph rewriting • Domain-independent formalism • Independent of the target language • Independent of the phase in the life-cycle • Lightweight formalism to facilitate tool support • Formal characterisation of evolution conflicts • Prototype tool implemented in Prolog
Example: UML class diagram • Internal Graph Representation G Shape«class» Point «class» area «operation» «assoc» x«attribute» Shape center center perimeter«operation» y«attribute» Point +area() -x +perimeter() distanceTo«operation» -y vertices 3 «is-a» «is-a» +distanceTo(p: Point) «has-a» {3} Circle «class» Triangle «class» radius «attribute» vertices Circle intersects«operation» -radius +intersects(c: Circle) Triangle Graphs • Node types: • «class» • «attribute» • «operation» • «interface» • Edge types: • «assoc» • «has-a» (aggregation) • «is-a» (generalisation) • «implements»
assoc, has-a, is-a nested class attribute nested implements uses v node type interface operation e edge type invokes nested is-a Type Graph • Used to specifydomain-specific constraints
(negative)precondition (positive)postcondition left-handside graph production right-handside R area «operation» «uses» P radius «attribute» L embedding in context m area «operation» G H radius «attribute» Circle «class» Circle «class» area «operation» area «operation» «uses» radius «attribute» radius «attribute» «uses» «uses» perimeter«operation» perimeter«operation» initial graph result graph graph rewriting Graph Rewriting • Used to specify software evolution
R R L Triangle area «operation» area «operation» «uses» «uses» AddEdge (area,radius,«uses») radius «attribute» radius «attribute» L Triangle DropNode (Triangle.area,«operation») «operation» area Primitive Graph Productions • Use restricted set of graph productions • AddNode • DropNode • AddEdge • DropEdge • RetypeNode • RetypeEdge • RelabelNode • RelabelEdge
G G1 Circle «class» Circle «class» area «operation» area «operation» «uses» radius «attribute» radius «attribute» «uses» «uses» perimeter«operation» perimeter«operation» P2 G2 P1 = AddEdge(area,radius,«uses») <<uses>> Circle «class» P1 P2 = DropNode(area,«operation») Undefined source conflict radius «attribute» «uses» perimeter«operation» Syntactic Conflicts Syntactic conflict if P1 and P2 are not parallel independent P1 P2
AddN(v,) DropN(v,) AddE(e,v,w,) AddE(e,u,v,) DropE(e,v,w,) DropE(e,u,v,) RetypeN(v,,1) RetypeE(e,v,w,,1) RetypeE(e,u,v,,1) AddNode(v,) AC1 DropNode(v,) AC2 AC3 AC4 AC9 AddEdge(e,v,w,) AC3 AC5 AddEdge(e,u,v,) AC4 AC5 DropEdge(e,v,w,) AC6 AC10if = DropEdge(e,u,v,) AC6 AC10if = RetypeNode(v,,2) AC9 AC7 RetypeEdge(e,v,w,,2) AC10if = AC8if = RetypeEdge(e,u,v,,2) AC10if = AC8if = Syntactic Conflict Table Complete fine-grained characterisation of syntactic conflicts
{added by developer 2} «inherits» {added during reuse} «class»? «class» ? «updates» addMany add size «inherits» «calls» {added by developer 1} {removed during evolution} Semantic Conflicts • Based on the formal notion of • pushouts and pullbacks • Fine-grained conflict characterisation • By detecting occurrence of graph patterns in result graph inconsistent method conflict cyclic inheritance
Shape Shape InsertClass(Shape,Quadrangle,[Square,Rectangle]) Square Rectangle Circle Quadrangle Circle AddSubclass(Shape,Parallellogram) AddSubclass(Shape,Triangle) Square Rectangle Shape Parallellogram Triangle Square Rectangle Circle Structural Conflicts More difficult to detect in a general way
Using Assertions • Problem • Using a predefined set of graph productions is not generic • Introducing new productions requires changes to conflict table • Does not scale up to composite graph productions • Solution • make formalism independent of chosen productions • define productions based on assertions only • preconditions, postconditions, invariants
L R uses surface area radius f uses attribute operation attribute a a c preconditions invariants postconditions Example ctd.
Syntactic Conflict Table • Detect syntactic merge conflicts • in terms of transformation preconditions • compare breaches of application conditions • Advantages • more general • does not rely on predefined graph produtions • more scalable • can be used directly for composite or domain-specific graph productions
-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=v C7 if j=e C8 if j=v C9 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 Syntactic Conflict Table
weak satisfaction dependency strong satisfaction dependency strong capture dependency derived assertions Using dependencies • Dependencies can be defined between productions • based on relations between assertions
Using dependencies • Dependencies can be used to address scalability • Reordering productions in a sequence • Defining “atomic” composite productions from a sequence of productions • Removing redundancy in a production sequence • Factoring out commonalities from parallel production sequences • Parallellising subsequences
Rena(c,d) Rety(d) AddN(a) AddN(b) AddE(a,b) DropE(a,b) DropN(a) AddN(a) AddN(b) DropN(a) AddN(b) AddN(a) DropN(a) AddN(b) 3. Removing redundancy • Allows us to simplify a production sequence redundant pair reorder redundant pair
4. Factoring out commonalities • Find commonalities in two parallel sequences, and factor out • facilitates merging and conflict detection
5. Parallellising subsequences RenameN(a,surface,area) AddN(b,perimeter,attribute) RetypeN(a, attribute,operation) RetypeN(b, attribute,operation) AddN(c,radius,attribute) AddE(e,b,c,uses,uses) AddE(f,a,c,uses,uses) DropE(e,b,c) DropN(b)
5. Parallellising subsequences RenameN(a,surface,area) RetypeN(a, attribute,operation) AddN(b,perimeter,attribute) AddN(c,radius,attribute) RetypeN(b, attribute,operation) AddE(e,b,c,uses,uses) AddE(f,a,c,uses,uses) DropE(e,b,c) DropN(b)
Validation of Reuse Contracts • Industrial case • One base release line with many customisations for different customer applications • Collaborative software development with parallel changes to base release and customisations 7.2 NDR 7.4 DR VTM 10.x WDR 0.1 TV2 11 WDR 1.0 12 WDR 2.0
Validation of Reuse Contracts • Use reuse contracts to document • evolution of base release line • customisation to different customer applications • evolution of customer applications • Use conflict detection to support • upgrades of customer application to more recent base release • refactoring of base release for easier future customisation • Provide help with consolidation • detect commonalities between different customisations • apply commonalities to base release
To Do • User-friendly tool support • Perform large-scale experiments • Validate scalability • Look at conflict resolution techniques • Deal with problem of co-evolution
abstractlayer evolution consistent??? refinement concretelayer evolution Co-Evolution • Underlying idea • Keep representation of same software artifact at different levels of abstraction (e.g. design and implementation) synchronised during evolution
Co-Evolution • needed for collaborative development • when different persons make changes to same software concept at different levels of abstraction • facilitates delta analysis • relate changes at analysis level back to the code and keep them synchronised • address architectural drift and software erosion • use a compliance checking algorithm • detect conflicts between changes at different levels