1 / 42

Formal Foundations for Software Evolution

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

lpatricia
Download Presentation

Formal Foundations for Software Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Foundationsfor Software Evolution Programming Technology Lab Tom Mens tommens@vub.ac.be http://prog.vub.ac.be/~tommens

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

  3. 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 • ...

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

  5. Reuse Contracts Usegraph rewritingto provide aformal foundationforsoftware evolution based onreuse contracts

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

  7. DesktopFolder position contents move: add: addMany: Extension(size, attribute) Refinement(add, size, update) SizedFolder size add: item 1.Documenting Reuse reuse size =+ item.size

  8. DesktopFolder DesktopFolder position contents move: add: addMany: position contents move: add: addMany: Coarsening(addMany, add, calls) 1.Documenting Evolution evolution

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

  10. 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)

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

  12. 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)

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

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

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

  16. 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»

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

  18. (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

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

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

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

  22. {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

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

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

  25. Example

  26. L R uses surface area radius f uses attribute operation attribute a a c preconditions invariants postconditions Example ctd.

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

  28. -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 vw  -target (f,w) C15 if e=f and vw Syntactic Conflict Table

  29. weak satisfaction dependency strong satisfaction dependency strong capture dependency derived assertions Using dependencies • Dependencies can be defined between productions • based on relations between assertions

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

  31. 1. Reordering productions

  32. 2. Composite productions

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

  34. 3. Removing Redundancy

  35. 4. Factoring out commonalities • Find commonalities in two parallel sequences, and factor out • facilitates merging and conflict detection

  36. 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)

  37. 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)

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

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

  40. To Do • User-friendly tool support • Perform large-scale experiments • Validate scalability • Look at conflict resolution techniques • Deal with problem of co-evolution

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

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

More Related