1. A Domain-Independent Formalism for Software Evolution Tom Mens Programming Technology Lab Vrije Universiteit Brussel February, 2000

2. 2 Overview of Presentation -  ¶ Introduction lMotivation lReuse Contracts lExample · Graph Rewriting Formalism ¸ Reuse Contract Formalism ¹ Scalability Issues º Domain-Independence » Experiments ¼ Conclusion

3. 3 Motivation lAddress lack of tool support for software evolution l CASE tools, IDEs, version control tools lProvide formal foundation for reuse contracts l clear and unambiguous definitions l better insight in evolution process l facilitate tool support l improve scalability ¶

4. 4 Motivation ctd. lLack of formal approaches to software evolution l very few formal approaches available l always domain-specific l architectural evolution l evolving specifications l usually focus on anticipated changes l e.g. run-time software reconfiguration lNeed for domain-independent approach to unanticipated software evolution ¶

5. 5 Reuse Contracts lDocument unanticipated evolution in a disciplined way lAllow to detect conflicts ¶ upgrade reuse upgrade conflict evolution merge conflict l When merging parallel evolutions of same software artifact (collaborative software development) l When upgrading to new versions of software lLightweight approach l simple ideas, easy to implement & customise

6. 6 Point centervertices Circle radius area() circumference() Triangle area() circumference() center1 13 Example l Evolution of UML class diagrams {  *radius 2 } Point center vertices Circle radius Triangle 13 Geo area() circumference() ¶

7. 7 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism l Graphs l Graph Rewriting l Application Conditions ¸ Reuse Contract Formalism ¹ Scalability Issues º Domain-Independence » Experiments ¼ Conclusion

8. 8 Graphs G Triangle «class» Circle «class» «isa» intersects «operation» «assoc» center radius «attribute» «hasa» vertices {3} Point «class»Geo «class» area «operation» circumference «operation» x «attribute» distanceTo «operation» y «attribute» «isa» Internal Graph Representation intersects(c: Circle) radius Circle distanceTo(p: Point) x y Point Triangle area() circumference() Geo center vertices3 Example: UML class diagram l Node types: l«class» l«attribute» l«operation» l«interface» l Edge types: l«assoc» l«hasa» (aggregation) l«isa» (generalisation) l«implements» ·

9. 9 Type Graph lNode & edge subtype hierarchy lAdditional constraints needed le.g. inheritance hierarchy is acyclic v e node type edge type implements nested operation attribute interface class assoc, hasa, isa isa uses invokes nested ·

10. 10 (Conditional) Graph Rewriting L area «operation» radius «attribute» P m R area «operation» radius «attribute» «uses» G Circle «class» area «operation» «uses» circumference «operation» radius «attribute» L’L’ area «operation» radius «attribute» C s luse application conditions: more expressive and concise lrepresents evolution of arbitrary software artifacts l Algebraic single-pushout approach · H Circle «class» area «operation» «uses» circumference «operation» radius «attribute» «uses» pushout construction

11. 11 Anticipated vs. Unanticipated lApplication conditions can be used to cope with lAnticipated evolution l restrict possible evolutions of a single graph lattach application condition to graph l restrict possible evolutions of all graphs lattach application condition to graph rewriting system lUnanticipated evolution (Reuse Contracts) l Attach application condition to a graph production to detect structural conflicts more easily ·

12. 12 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism ¸ Reuse Contract Formalism l Detecting evolution conflicts l Primitive contract types l Applicability conflicts l Evolution conflicts ¹ Scalability Issues º Domain-Independence » Experiments ¼ Conclusion

13. 13 Detecting Evolution Conflicts l Two kinds of evolution conflicts l Syntactic conflicts l Semantic conflicts l Conservative approach: only generate conflict warnings l Approach l Provide general formal definition l in terms of graph rewriting formalism l Complete fine-grained characterisation ¸

14. 14 l Use a restricted set of possible graph productions l Extension l Cancellation l Refinement l Coarsening l NodeRetyping l EdgeRetyping Primitive Contract Types ¸ Refinement ( ,area,radius,«uses») R area «operation» radius «attribute» «uses» L area «operation» radius «attribute» Cancellation (area,«operation») L «operation» area R

15. 15 Structural Conflicts Refinement ( ,area,radius,«uses») Applicability conflict if P 1 and P 2 not parallel independent Gives rise to ill-formed result graph (syntactic conflict) G Circle «class» area «operation» circumference «operation» radius «attribute» «uses» > G2G2 Circle «class» circumference «operation» radius «attribute» «uses» G1G1 Circle «class» area «operation» circumference «operation» radius «attribute» «uses» ¸ Cancellation (area,«operation») Undefined source conflict Refinement Cancellation P1P1 P2P2

16. 16 Applicability Conflict Table Complete fine-grained characterisation of applicability conflicts AC 3 Extend (v,  ) Cancel (v,  ) Refine (e,v,w,  ) Refine (e,u,v,  ) Coarsen (e,v,w,  ) Coarsen (e,u,v,  ) Nretype (v, ,   ) ERetype (e,v,w, ,   ) ERetype (e,u,v, ,   ) Extension (v,  ) AC 1  Cancellation (v,  )  AC 2 AC 3 AC 4  AC 9  Refinement (e,v,w,  )  AC 5  Refinement (e,u,v,  )  AC 4  AC 5  Coarsening (e,v,w,  )  AC 6  AC 10 if  =   Coarsening (e,u,v,  )  AC 6  AC 10 if  =  NodeRetype (v, ,   )  AC 9  AC 7  EdgeRetype (e,v,w, ,   )  AC 10 if  =   AC 8 if  =   EdgeRetype (e,u,v, ,   )  AC 10 if  =   AC 8 if  =  ¸

17. 17 Applicability Conflict Table ctd. lDuplicate Node Conflict lDouble Cancellation Conflict lUndefined Source Conflict lUndefined Target Conflict lDuplicate Edge Conflict lDouble Coarsening Conflict lDouble Node Retyping Conflict lDouble Edge Retyping Conflict lUndefined Node Retyping Conflict lUndefined Edge Retyping Conflict ¸

18. 18 Alternative Conflict Table l Compare breaches of application conditions l more general l does not rely on primitive contract types l more scalable l can be used directly for composite contract types or domain-specific contract types ¸

19. 19 AC1 AC8 AC7 AC10 AC6AC10 AC9 AC5 AC3 AC2 Alternative Conflict Table v v vw e vw e type(v)=  type(e,v,w)=  v v vw e vw e type(v)=  type(e,v,w)=              ¸

20. 20 Evolution Conflicts L1L1 area «operation» radius «attribute» R1R1 area «operation» radius «attribute» «uses» G Circle «class» area «operation» circumfer «operation» radius «attribute» «uses» G1G1 Circle «class» area «operation» circumfer «operation» radius «attribute» «uses» m1m1 Refinement ( ,area,radius,«uses») H Circle «class» area «operation» circumfer «operation» radius «attribute» «uses» Pushout construction ¸ L2L2 area «operation» circumfer «operation» R2R2 area «operation» circumfer «operation» «uses» G2G2 Circle «class» area «operation» «uses» circumfer «operation» radius «attribute» «uses» Refinement ( ,area,circumference,«uses») m2m2 L area «operation» Pullback construction area «operation»

21. 21 l Finer-grained characterisation l Compare pairs of primitive contract types l double reachability conflict l cycle introduction conflict l Detect graph patterns in result of merge l more general l more scalable ¸ Evolution Conflict Detection «uses» arearadius «uses» {evolver 1} {evolver 2}

22. 22 Nesting l Reduces complexity l New primitive contract types l MoveNode l Promotion l Demotion l New conflicts l e.g. MoveNode vs MoveNode appl. conflict l e.g. Inconsistent source or target evol. conflict MoveNode (D, ,A.B,A.C) A B C «»«» D L A C B «»«» D R ¸

23. 23 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism ¸ Reuse Contract Formalism ¹ Scalability Issues l Composite Contract Types l Normalisation º Domain-Independence » Experiments ¼ Conclusion

24. 24 Composite Contract Types G0G0 Triangle «class» area «operation» Circle «class» area «operation» «assoc» center circumference «operation» «assoc» center radius «attribute» «hasa» vertices Point «class» G1G1 Triangle «class» area «operation» Circle «class» area «operation» circumference «operation» «assoc» center radius «attribute» «hasa» vertices Point «class» Geo «class» «isa» CreateSuperclass (Geo,[Circle,Triangle]) Extension(Geo,«class») Refinement( ,Circle,Geo,«isa») Refinement( ,Triangle,Geo,«isa») Coarsening(center,Circle,Point,«assoc») Coarsening(center,Triangle,Point,«assoc») Refinement(center,Geo,Point,«assoc») ¹

25. 25 Composite Contract Types ctd. MoveNode(area,«operation»,Circle,Geo) MoveNode(circumference,«operation»,Circle,Geo) Cancellation(Triangle.area,«operation») Cancellation(Triangle.circumference,«operation») Refactor (Geo,[area,circumference]) G1G1 Triangle «class» area «operation» Circle «class» area «operation» circumference «operation» «assoc» center radius «attribute» «hasa» vertices Point «class» Geo «class» «isa» G2G2 Triangle «class» Circle «class» «assoc» center radius «attribute» «hasa» vertices Point «class» Geo «class» «isa» area «operation» circumference «operation» ¹

26. 26 Composite Contract Types ctd. lComposite contract types l can be domain-independent l can be domain-specific (e.g. CreateSuperclass) l are defined as composite productions lConflicts can be detected directly l using alternative applicability conflict table l using graph pattern approach lAdvantages l more practical in use l atomic, more efficient l remove unnecessary conflict warnings ¹

27. 27 Normalisation algorithm lRemove redundancy in evolution sequence l remove redundant couples l Extension; Cancellation l absorb couples of primitive contract types l Refinement; EdgeRetyping = Refinement lRearrange primitive contract types l based on sequential independence l canonical form l Extensions; NodeRetypings; Refinements,... ¹

28. 28 Normalisation ctd. lAdvantages l compacts evolution sequence (reduces complexity) l removes unnecessary conflict warnings l makes evolution process easier to understand l finding specific modifications l comparing differences between parallel evolutions lTo do l improve efficiency of normalisation algorithm l rely on canonical form for merging normalised evolution sequences ¹

29. 29 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism ¸ Reuse Contract Formalism ¹ Scalability Issues º Domain-Independence l Possible Customisations l Customising the formalism l Case studies » Experiments ¼ Conclusion

30. 30 Possible Customisations lclass collaborations l extension and generalisation of [Lucas97] l similar to UML collaboration diagrams [Mens&al99] lUML class diagrams lsoftware architectures [Romero99] lothers l other UML diagrams l non-OO paradigms? º

31. 31 Case study: UML class diagrams lSpecify type graph & type constraints lSpecify domain-specific modifications lPrimitive contract types lExtension: AddOperation, AddAttribute, AddClassifier lCancellation: DropOperation, DropAttribute, DropClassifier lRefinement: AddGeneralisation, AddAssociation lComposite contract types (e.g. CreateSuperclass) lFine-tune conflict detection l type graph gives rise to new applicability conflicts l wf-constraints capture some evolution conflict warnings e.g. cycle introduction for inheritance-edges l use domain-specific knowledge to ignore conflict warnings e.g. ignore cycle introduction for associations º

32. 32 Domain-specific normalisation AddClass(B); AddClass(A); AddOperation(A.m); DropClass(B); AddAttribute(A.a); DropOperation(A.m) Extension(B,«class»); Extension(A,«class»); Extension(A.m,«operation»); Cancellation(B,«class»); Extension(A.a,«attribute»); Cancellation(A.m,«operation») Extension(A,«class»); Extension(A.a, «attribute») normalisation AddClass(A); AddAttribute(A.a) Domain-independent framework Domain-specific customisation translation º (not for composite contract types)

33. 33 Case study: software architectures l need to detect more high-level conflicts l introduce derived edges in «gate» out «gate» «link» Parser «component» Pipe2 «connector» Semantor «component» Coder «component» Pipe3 «connector» «link» SequentialCompiler«architecture» Lexer «component» Pipe1 «connector» «link» «binding» in «gate» in «gate» in «gate» in «gate» in «gate» in «gate» in «gate» out «gate» out «gate» out «gate» out «gate» out «gate» out «gate» out «gate» «pipe» º

34. 34 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism ¸ Reuse Contract Formalism ¹ Scalability Issues º Domain-Independence » Experiments ¼ Conclusion

35. 35 Experiments lImplementation of basic formalism l primitive contract types, conflict detection l implemented in PROLOG l rapid prototyping l expressing conflict detection rules directly l unification mechanism for detecting graph patterns l use SOUL to access and reason about Smalltalk code lScalability l normalisation algorithm l no validation of composite contract types l lack of adequate (large-scale) industry case »

36. 36 Experiments ctd. lDomain-specific customisation l customisations of PROLOG framework l UML class diagrams l small experiments with UML CASE tools l identify basic conflicts for class diagrams (based on small changes in industry case study) l software architectures [Romero99] lFurther experiments needed l develop and implement efficient algorithms l validate scalability aspects l integrate in CASE tool and version control tool »

37. 37 lCurrent-day version control systems l use version graph l perform textual merging l only research prototypes for syntactic/semantic merging lNext generation version control tools l Use normalisation l to compact version graph l to compare between alternative variants easily l refactor commonalities in different variants l More sophisticated merge tools l syntactic and semantic merging l domain-independent RCs for version control »

38. 38 Overview of Presentation -  ¶ Introduction · Graph Rewriting Formalism ¸ Reuse Contract Formalism ¹ Scalability Issues º Domain-Independence » Experiments ¼ Conclusion l Contribution l Future Work

39. 39 Contribution lDomain-independent formalism for evolution lcan be applied in all phases of software life-cycle lReuse contract formalism enables lformal distinction between syntactic & semantic conflicts lcomplete fine-grained characterisation of conflicts lscalability (composite contract types, normalisation) lSimple yet general model for evolution leasy to implement in tools lsimple ideas with large practical impact lBetter support for evolution in tools lCASE tools, IDEs, version control systems ¼

40. 40 Future Work l Focus on conflict resolution l More scalability issues l techniques to reduce potential conflicts l use more sophisticated conflict detection techniques l in presence of composite contract types l modify normalisation algorithm l factorisation algorithm for generating composite contract types l formal properties (e.g. commutativity, inverse,...) l Co-evolution l between different models / between model and metamodel lEnhancing underlying graph formalism lnested hyperedges, encapsulation mechanism, parameterisation mechanism, more complex application conditions,... l extension needs to preserve formal properties ¼