1 / 24

AGTIVE Workshop

AGTIVE Workshop. Conditional Graph Rewriting as a Domain-Independent Formalism for Software Evolution Tom Mens Programming Technology Lab Vrije Universiteit Brussel, Belgium September 1 , 1999. Motivation. CASE tools and IDEs provide poor support for unanticipated software evolution

diep
Download Presentation

AGTIVE Workshop

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. AGTIVE Workshop Conditional Graph Rewriting as a Domain-Independent Formalism for Software Evolution Tom Mens Programming Technology Lab Vrije Universiteit Brussel, Belgium September 1, 1999

  2. Motivation • CASE tools and IDEs provide poor support for unanticipated software evolution • support is ad-hoc, or restricted to a specific phase in the software life-cycle • Need for a uniform and formal approach to deal with evolution of arbitrary software artifacts • Reuse Contracts are a suitable candidate • Use graph rewriting as underlying formalism

  3. evolution evolution merge conflict Reuse Contracts • Document unanticipatedevolution in a disciplined way • Allow to detect merge conflicts • When mergingparallel evolutions of same software artifact (collaborative software development) • Lightweight formalism

  4. Overview • Domain-independent formalism • Graphs • Graph Rewriting • Reuse Contract Approach • Scalability • Conclusion

  5. Representing Software Artifacts • Labelled Graphs = natural way to describe arbitrary software artifacts • Typed[Corradini,Montanari,Ehrig,Lowe] • classification mechanism • Nested (or hierarchical) [Engels,Schürr] • reduces complexity

  6. Internal Graph Representation • Example: UML class diagram G Geo«class» Point «class» area «operation» «assoc» x«attribute» center circumference«operation» y«attribute» Geo Point center -x distanceTo«operation» -y +area() «isa» «isa» +distanceTo(p: Point) +circumference() «hasa» {3} vertices 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» • «hasa» (aggregation) • «isa» (generalisation) • «implements»

  7. assoc, hasa, isa nested class attribute nested implements uses interface operation invokes nested isa v node type e edge type Type Graph • Node & edge subtype hierarchy • Additional constraints needed • e.g. acyclic inheritance

  8. Representing Evolution • Graph Rewriting = natural way to describe evolution of software artifacts • Use algebraic single-pushout approach • [Löwe] • Use application conditions • [Habel,Heckel,Taentzer,Wagner] • more expressive • more concise

  9. e.g. negative application precondition C R L P area «operation» area «operation» «uses» radius «attribute» radius «attribute» m m* L’ G H area «operation» s Circle «class» Circle «class» radius «attribute» area «operation» area «operation» «uses» P* radius «attribute» radius «attribute» «uses» «uses» circumference«operation» circumference«operation» Conditional Graph Rewriting

  10. Overview • Domain-independent formalism • Reuse Contract Approach • Detecting Merge Conflicts • Primitive Contract Types • Applicability Conflicts • Evolution Conflicts • Domain-specific customisation • Scalability • Conclusion

  11. Detecting Merge Conflicts • Distinguish between • Structural conflicts (syntactic) • Behavioural conflicts (semantic) • Conservative approach: detect only conflict warnings • Provide formal but intuitive definition • Complete fine-grained characterisation • Conflict table

  12. R R L Triangle area «operation» area «operation» «uses» «uses» AddEdge (e,area,radius,«uses») radius «attribute» radius «attribute» L Triangle DropNode (Triangle.area,«operation») «operation» area Primitive Contract Types • Only use restricted set of graph productions(“contract types”) • AddNode • DropNode • AddEdge • DropEdge • RetypeNode • RetypeEdge • MoveNode • Promotion • Demotion

  13. G G1 Circle «class» Circle «class» area «operation» area «operation» «uses» radius «attribute» radius «attribute» «uses» «uses» circumference«operation» circumference«operation» P2 G2 P1 = AddEdge(e,area,radius,«uses») <<uses>> Circle «class» P1 P2 = DropNode(Circle.area, «operation») Undefined source conflict radius «attribute» «uses» circumference«operation» Structural Conflicts • Def.: “Applicability” conflict if P1 and P2 not parallel independent • P1 and P2 cannot be sequentialised because of application conditions P1 P2

  14. Extend(v,) Cancel(v,) Refine(e,v,w,) Refine(e,u,v,) Coarsen(e,v,w,) Coarsen(e,u,v,) Nretype(v,,1) ERetype(e,v,w,,1) ERetype(e,u,v,,1) Extension(v,) AC1         Cancellation(v,)  AC2 AC3 AC4   AC9   Refinement(e,v,w,)  AC3 AC5       Refinement(e,u,v,)  AC4  AC5      Coarsening(e,v,w,)     AC6   AC10if =  Coarsening(e,u,v,)      AC6   AC10if = NodeRetype(v,,2)  AC9     AC7   EdgeRetype(e,v,w,,2)     AC10if =   AC8if =  EdgeRetype(e,u,v,,2)      AC10if =   AC8if = Applicability Conflict Table Complete fine-grained characterisation of structural conflicts

  15. L1 R1 L P1 area «operation» area «operation» area «operation» «uses» radius «attribute» radius «attribute» Pullback construction m1 m1* G G1 L2 Circle «class» Circle «class» area «operation» area «operation» P1* area «operation» «uses» radius «attribute» radius «attribute» circumferenc «operation» m2 «uses» «uses» circumfere «operation» circumfere «operation» Pushout construction P2* P2 G2 H R2 Circle «class» Circle «class» area «operation» area «operation» «invokes» m2* area «operation» «uses» «invokes» «invokes» radius «attribute» radius «attribute» circumfere «operation» «uses» «uses» circumfere «operation» circumfere «operation» Behavioural Conflicts

  16. Domain-Specific Customisation • Specify domain-specific contract types • AddNode AddClass, AddOperation • DropNode DropClass, DropAttribute • AddEdge AddGeneralisation, AddAssociation • Use domain-specific info to ignore conflicts • e.g. ignore cycle introduction for «assoc»-edges • Domain-specific wf-rules • give rise to new structural conflicts • capture certain behavioural conflict warnings • e.g. cycle introduction of «isa»-edges

  17. Overview • Domain-independent formalism • Reuse Contract Approach • Scalability • Composite Contract Types • Normalisation • Conclusion

  18. Composite Contract Types • Predefined sequence of primitive contract types • Advantages • more intuitive in use, more practical • atomic • allow us to reduce unnecessary conflict warnings • Composite contract types • can be domain-independent • can be domain-specific

  19. Normalisation algorithm • Remove redundancy in arbitrary evolution sequence • redundant: e.g. AddNode(v); …; DropNode(v) • absorbing: e.g. AddEdge(e); …; RetypeEdge(e) • compacts evolution sequence (reduces complexity) • removes unnecessary conflict warnings • Rearrange primitive contract types in sequence • based on sequential independence • canonical form: AddNodes; AddEdges; RetypeEdges... • makes evolution sequence easier to understand

  20. Overview • Domain-independent formalism • Reuse Contract Approach • Scalability • Conclusion • Summary • Experiments • Future Work

  21. Summary • General formalism for unanticipated evolution • Customisable to different domains • class diagrams, class collaborations, software architectures • Defined in terms of conditional graph rewriting • pushout, parallel & sequential dependence, confluency, ... • Approach is scalable • normalisation, composite contract types, … • need to address efficiency issues • need to validate on large industrial case study • Lightweight approach • easy to implement, straightforward algorithms, easy to use

  22. Industrial Relevance • RCs enhance existing tools with formal support for evolution • CASE tools, IDEs • Version management tools • More sophisticated merge tools • behavioural merge conflicts (instead of textual or structural) • Use normalisation • to compact version graph • to compare between alternative variants easily

  23. Experiments • Carried out • Validate basic reuse contract formalism • implemented in PROLOG • declarative, unification mechanism, rapid prototyping • Normalisation algorithm • Small CASE tool experiments (UML) • To do • Perform large-scale industrial case study • Validate scalability • Integration in version control tool, UML CASE tool • Apply RCs to implementation level

  24. Future Work • Focus on conflict resolution • Scalability issues • merge & normalise composite contract types • techniques to remove unnecessary conflict warnings • address efficiency aspects • Enhance underlying graph formalism • hyperedges, nested edges, parameterised nodes • encapsulated graphs, modular graph transformation • formalisation of well-formedness constraints

More Related