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

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

4. Overview Domain-independent formalism Reuse Contract Approach
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
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.

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

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

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

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

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

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

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

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

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

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
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???

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

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

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