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 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 We have chosen for reuse contracts because they have already illustrated their practical use, and because they have already been defined for different kinds of software artifacts (software requirements in OBA, class inheritance hierarchies in Smalltalk and Java, collaboration diagrams in UML). Interesting formal properties: confluence, parallel and sequential independence, etc...

Reuse Contracts Document unanticipated evolution in a disciplined way Allow to detect merge conflicts When merging parallel evolutions of same software artifact (collaborative software development) evolution merge conflict Document unanticipated reuse and evolution in a disciplined way. By formally documenting unanticipated evolution, RCs make it possible to solve evolution problems. Eigenlijk zijn er 2 manieren om to deal with evolution: anticipated and unanticipated. The former approach can be dealt with by restricting the possible evolutions by putting constraints on the software artifact that is being evolved. Reuse contracts take the latter approach of detecting unanticipated evolution as well. Allow to detect conflicts. Two kinds of conflicts can be distinguished: Upgrade conflicts occur when a certain software artifact, which is already reused or incrementally modified (e.g., by means of an inheritance mechanism), is upgraded to a new version. This focus has been taken in [Lucas97] and earlier papers on reuse contracts (so-called “base class exchange”) Merge conflicts occur when the same software artifact is changed in parallel by different software developers for different reasons, and inconsistencies turn up when these parallel changes are merged. This often occurs in collaborative software development, where many developers simultaneously work on the same code. This is the focus taken in this dissertation. Lightweight formalism: Trade-off between ease of use and formality ease of use:do not burden software developer with formal details Formality: To have clear and unambiguous definitions; Make use of existing properties and theorems; To facilitate tool support; To improve scalability Lightweight formalism

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

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 Graphs = natural way to describe arbitrary software artifacts. Graphs are particularly useful to describe the structural aspects of software. Edges can be used to express data-flow dependencies, control-flow dependencies, etc... This is already sufficient for expressing a wide range of interesting evolution conflicts. Maybe there are certain things that cannot be expressed in graphs.

Graphs Example: UML class diagram Internal Graph Representation +intersects(c: Circle) -radius Circle +distanceTo(p: Point) -x -y Point Triangle +area() +circumference() Geo center vertices 3 Example: UML class diagram 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» Internal Graph Representation Node types: «class» «attribute» «operation» «interface» Edge types: «assoc» «hasa» (aggregation) «isa» (generalisation) «implements»

Type Graph Node & edge subtype hierarchy Additional constraints needed implements nested operation attribute interface class assoc, hasa, isa isa uses invokes v e node type edge type Node & edge subtype hierarchy Additional constraints needed e.g. acyclic inheritance Need to specify additional domain-specific well-formedness constraints: «isa»-edges must connect nodes of the same type «isa»-hierarchy should be acyclic

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

Conditional Graph Rewriting area «operation» radius «attribute» C s e.g. negative application precondition L area «operation» radius «attribute» P P* m m* R «uses» G Circle «class» circumference «operation» H We use a category-theoretical, or algebraic, approach towards graph rewriting. More specifically, we have chosen for the single-pushout approach. An alternative would have been the double-pushout approach, but productions in the SPO are significantly simpler, substantially reducing many proofs. Moreover, SPO is more general than DPO [Lowe93]. A disadvantage of SPO over DPO is that there can be unintuitive side-effects: dangling edge conflict, identification conflict. However, our primitive productions will be chosen in such a way that these side-effects will not occur.

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

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 As already mentioned before, the idea of RCs is to use the contract type (which documents the modifications that are being made in a precise way) to detect conflicts when merging parallel modifications of the same sofware artifact. Two kinds of merge conflicts can be distinguished: Applicability conflicts correspond to structural or semantic problems. Only (a subset of) these conflicts can be detected by commercially available merge tools. Evolution conflicts are more important since they correspond to behavioural or semantic inconsistencies. This cannot be detected by commercially available merge tools. For both kinds of conflicts we can provide a general formal definition based on RCs, as well as a complete fine-grained characterisation based on the contract types that are involved. In this way, conflict tables can be set up to detect the conflicts more efficiently and to give detailed feedback about the kind of conflict that has occurred.

Primitive Contract Types Only use restricted set of graph productions (“contract types”) AddNode DropNode AddEdge DropEdge RetypeNode RetypeEdge MoveNode Promotion Demotion AddEdge (e,area,radius,«uses») R area «operation» radius «attribute» «uses» L DropNode (Triangle.area,«operation») Triangle «operation» area We have defined an orthogonal set of primitive contract types that are expressive enough to descirbe any possible kind of graph modification. The primitive contract types are defined as conditional graph productions. The possible productions correspond to: adding/removing a node in a graph adding/removing an edge in a graph changing the type of a node or edge in a graph

P2 = DropNode(Circle.area, «operation») Structural Conflicts Def.: “Applicability” conflict if P1 and P2 not parallel independent P1 and P2 cannot be sequentialised because of application conditions G Circle «class» area «operation» circumference «operation» radius «attribute» «uses» G1 Circle «class» area «operation» circumference «operation» radius «attribute» «uses» P1 P1 P2 Undefined source conflict Applicability conflicts are conflicts that would lead to an ill-formed result graph when two parallel modifications of the same software artifact are merged. Using conditional graph rewriting these conflicts can be detected very easily, if one of the two productions is not applicable after the other. Formally this means that P1 and P2 are not parallel independent. P2 <<uses>> G2 Circle «class» circumference «operation» radius «attribute» «uses» P2 = DropNode(Circle.area, «operation») P1 = AddEdge(e,area,radius,«uses»)

Applicability Conflict Table Complete fine-grained characterisation of structural conflicts AC3   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 AC4 AC9 Refinement (e,v,w,) AC5  Refinement (e,u,v,) Coarsening (e,v,w,) AC6 AC10 if = Coarsening (e,u,v,) NodeRetype (v,,2) AC7 EdgeRetype (e,v,w,,2) AC8 if = EdgeRetype (e,u,v,,2) The example of the undefined source conflict on the previous slide occurs when a Refinement is combined with a Cancellation. In the symmetric conflict table above it is shown by means of filled red rectangles (conflict AC3).

Behavioural Conflicts area «operation» radius «attribute» R1 «uses» G Circle «class» circumfere «operation» G1 P1* m1 P1 m1* L area «operation» Pullback construction L2 area «operation» circumferenc «operation» R2 circumfere «operation» «invokes» G2 Circle «class» «uses» radius «attribute» m2* P2 m2 P2* H Circle «class» area «operation» circumfere «operation» radius «attribute» «uses» «invokes» Pushout construction Formally, an evolution conflict can be detected between two primitive productions P1 and P2 if the pullback of m1 and m2 is not empty. This indicates potential problems in the pushout of P1* and P2*. In the example, area is a point of interaction between both independent evolutions P1* and P2*. It leads to two different (maybe incompatible) paths from area to radius. Hence it gives rise to a potential evolution conflict. “Potential” because the conflict depends on the precise behaviour that is associated with the graph (i.e. The software artifact). Because the evolution conflicts that are detected are only potential, reuse contracts can only give an upper bound approximation of the conflicts. The more domain-specific information is known, the better the approximation of the conflicts will be. The example above is a double reachability conflict. It occurs in presence of a Refinement versus Refinement. In a similar way, other behavioural (or semantic) merge conflicts can be identified, such as the cycle introduction conflict that arises when a cycle is unexpectedly introduced because of parallel modifications. All these conflicts can be put in a conflict table, similar to the applicability conflicts. Nadeel: de conservative approach die hierboven beschreven is geeft soms te veel unnecessary conflict warnings. Techniques are needed to reduce these warnings to a more managable number.

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 Transitive closure Using a straightforward algorithm, calculating the transitive closure of a graph requires O(n3) time, where n is the number of nodes in the graph [Warshall62]. More efficient algorithms have been developed but are only useful if the matrix representation of the transitive closure graph is sparse. Other primitive contract types Each time we want to add new primitive contract types to the formalism, we need to investigate if and how these modifications interact with the existing ones and to which conflicts they can give rise. Scalability This will be discussed in the next part of the presentation.

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

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 Allow us to reduce some conflicts: Niet dieper op ingaan tenzij expliciet gevraagd. Voorbeeldje: Factorisation. (+ uitleg) Wat is de invloed van composite contract types op evolution conflicts en applicability conflicts? Kan je nog steeds dezelfde formele definities gebruiken???

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

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

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 CASE tool support by means of RCs E.g. General support for evolution in UML case tools Version management tools Better support for merging parallel modifications and detecting conflicts because RCs allow to detect behavioural conflicts (as opposed to existing merge tools) The normalisation algorithm can also be used for compacting changes by removing redundant information.

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

Experiments Carried out To do 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

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 Focus on conflict resolution In our dissertation we only looked at techniques for conflict detection. However, an equally important topic is to resolve the conflicts in a semi-automated way after they have been detected. Scalability issues Techniques to reduce number of detected conflicts Impact analysis techniques make use of sophisticqted search algorithms that take more factors into account than just plain dependencies. They can make use of heuristics that suggest which paths could be avoided or use stochastic probabilities to determine the likelihood of an impact. A conflict never comes alone. Often, a problem situation can give rise to a whole bunch of conflicts. By solving the problem, all of these conflicts are solved at the same time. This is for example the case with transitive closure conflicts. A first-order conflict gives rise to a second-order conflict somewhere else, etc... By using application conditions to specify evolution conditions (on a graph) and evolution invariants (on the rewriting system), many of the evolution conflicts can be avoided since the set of possible evolutions that can be made to a graph is reduced.