A Domain-Independent Formalism

1

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

2
Overview of Presentation - ?

• Introduction
• Motivation
• Reuse Contracts
• Example
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Scalability Issues
• Domain-Independence
• Experiments
• Conclusion

3
Motivation

• Address lack of tool support for software
  evolution
• CASE tools, IDEs, version control tools
• Provide formal foundation for reuse contracts
• clear and unambiguous definitions
• better insight in evolution process
• facilitate tool support
• improve scalability

4
Motivation ctd.

• Lack of formal approaches to software evolution
• very few formal approaches available
• always domain-specific
• architectural evolution
• evolving specifications
• usually focus on anticipated changes
• e.g. run-time software reconfiguration
• Need for domain-independent approach to
  unanticipated software evolution

5
Reuse Contracts

• Document unanticipated evolution in a disciplined
  way
• Allow to detect conflicts

• When upgrading to new versions of software

• When merging parallel evolutions of same
  software artifact (collaborative software
  development)

• Lightweight approach
• simple ideas, easy to implement customise

6
Example

• Evolution of UML class diagrams

?radius2
7
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Graphs
• Graph Rewriting
• Application Conditions
• Reuse Contract Formalism
• Scalability Issues
• Domain-Independence
• Experiments
• Conclusion

8
Graphs

• Node types
• class
• attribute
• operation
• interface
• Edge types
• assoc
• hasa (aggregation)
• isa (generalisation)
• implements

9
Type Graph

• Node edge subtype hierarchy
• Additional constraints needed
• e.g. inheritance hierarchy is acyclic

10
(Conditional) Graph Rewriting

• represents evolution of arbitrary software
  artifacts
• Algebraic single-pushout approach

11
Anticipated vs. Unanticipated

• Application conditions can be used to cope with
• Anticipated evolution
• restrict possible evolutions of a single graph
• attach application condition to graph
• restrict possible evolutions of all graphs
• attach application condition to graph rewriting
  system
• Unanticipated evolution (Reuse Contracts)
• Attach application condition to a graph
  production to detect structural conflicts more
  easily

12
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Detecting evolution conflicts
• Primitive contract types
• Applicability conflicts
• Evolution conflicts
• Scalability Issues
• Domain-Independence
• Experiments
• Conclusion

13
Detecting Evolution Conflicts

• Two kinds of evolution conflicts
• Syntactic conflicts
• Semantic conflicts
• Conservative approach only generate conflict
  warnings
• Approach
• Provide general formal definition
• in terms of graph rewriting formalism
• Complete fine-grained characterisation

14
Primitive Contract Types

• Use a restricted set of possible graph
  productions
• Extension
• Cancellation
• Refinement
• Coarsening
• NodeRetyping
• EdgeRetyping

15
Structural Conflicts

• Applicability conflict if P1 and P2 not parallel
  independent
• Gives rise to ill-formed result graph (syntactic
  conflict)

Refinement (e,area,radius,uses)
P1
Cancellation (area,operation)
P2
16
Applicability Conflict Table

• Complete fine-grained characterisation of
  applicability conflicts

17
Applicability Conflict Table ctd.

• Duplicate Node Conflict
• Double Cancellation Conflict
• Undefined Source Conflict
• Undefined Target Conflict
• Duplicate Edge Conflict
• Double Coarsening Conflict
• Double Node Retyping Conflict
• Double Edge Retyping Conflict
• Undefined Node Retyping Conflict
• Undefined Edge Retyping Conflict

18
Alternative Conflict Table

• Compare breaches of application conditions
• more general
• does not rely on primitive contract types
• more scalable
• can be used directly for composite contract
  types or domain-specific contract types

19
Alternative Conflict Table

v
type(v)?
type(e,v,w)t
AC1
?
?
?
?
?
AC9
AC3
AC2
?
?
?
v
AC5
AC3
?
?
?
?
AC6
AC10
?
?
?
?
AC7
AC9
?
type(v)?
?
?
?
AC8
AC10
type(e,v,w)t
?
?
?
?
20
Evolution Conflicts

21
Evolution Conflict Detection

• Finer-grained characterisation
• Compare pairs of primitive contract types
• double reachability conflict
• cycle introduction conflict
• Detect graph patterns in result of merge
• more general
• more scalable

22
Nesting

• Reduces complexity
• New primitive contract types
• MoveNode
• Promotion
• Demotion
• New conflicts
• e.g. MoveNode vs MoveNode appl. conflict
• e.g. Inconsistent source or target evol. conflict

23
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Scalability Issues
• Composite Contract Types
• Normalisation
• Domain-Independence
• Experiments
• Conclusion

24
Composite Contract Types

CreateSuperclass (Geo,Circle,Triangle)
25
Composite Contract Types ctd.

MoveNode(area,operation,Circle,Geo) MoveNode(cir
cumference,operation,Circle,Geo) Cancellation(Tr
iangle.area,operation) Cancellation(Triangle.cir
cumference,operation)
26
Composite Contract Types ctd.

• Composite contract types
• can be domain-independent
• can be domain-specific (e.g. CreateSuperclass)
• are defined as composite productions
• Conflicts can be detected directly
• using alternative applicability conflict table
• using graph pattern approach
• Advantages
• more practical in use
• atomic, more efficient
• remove unnecessary conflict warnings

27
Normalisation algorithm

• Remove redundancy in evolution sequence
• remove redundant couples
• Extension Cancellation
• absorb couples of primitive contract types
• Refinement EdgeRetyping Refinement
• Rearrange primitive contract types
• based on sequential independence
• canonical form
• Extensions NodeRetypings Refinements, ...

28
Normalisation ctd.

• Advantages
• compacts evolution sequence (reduces complexity)
• removes unnecessary conflict warnings
• makes evolution process easier to understand
• finding specific modifications
• comparing differences between parallel
  evolutions
• To do
• improve efficiency of normalisation algorithm
• rely on canonical form for merging normalised
  evolution sequences

29
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Scalability Issues
• Domain-Independence
• Possible Customisations
• Customising the formalism
• Case studies
• Experiments
• Conclusion

30
Possible Customisations

• class collaborations
• extension and generalisation of Lucas97
• similar to UML collaboration diagrams
  Mensal99
• UML class diagrams
• software architectures Romero99
• others
• other UML diagrams
• non-OO paradigms?

31
Case study UML class diagrams

• Specify type graph type constraints
• Specify domain-specific modifications
• Primitive contract types
• Extension AddOperation, AddAttribute,
  AddClassifier
• Cancellation DropOperation, DropAttribute,
  DropClassifier
• Refinement AddGeneralisation, AddAssociation
• Composite contract types (e.g. CreateSuperclass)
• Fine-tune conflict detection
• type graph gives rise to new applicability
  conflicts
• wf-constraints capture some evolution conflict
  warnings e.g. cycle introduction for
  inheritance-edges
• use domain-specific knowledge to ignore conflict
  warnings e.g. ignore cycle introduction for
  associations

32
Domain-specific normalisation

AddClass(B) AddClass(A) AddOperation(A.m)
DropClass(B) AddAttribute(A.a)
DropOperation(A.m)
AddClass(A) AddAttribute(A.a)
Domain-specific customisation
translation
translation
Extension(B,class) Extension(A,class)
Extension(A.m,operation) Cancellation(B,class
) Extension(A.a,attribute) Cancellation(A.m,o
peration)
normalisation
Extension(A,class) Extension(A.a, attribute)
Domain-independent framework
(not for composite contract types)
33
Case study software architectures

• need to detect more high-level conflicts
• introduce derived edges

34
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Scalability Issues
• Domain-Independence
• Experiments
• Conclusion

35
Experiments

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

36
Experiments ctd.

• Domain-specific customisation
• customisations of PROLOG framework
• UML class diagrams
• small experiments with UML CASE tools
• identify basic conflicts for class diagrams
  (based on small changes in industry case study)
• software architectures Romero99
• Further experiments needed
• develop and implement efficient algorithms
• validate scalability aspects
• integrate in CASE tool and version control tool

37
RCs for version control

• Current-day version control systems
• use version graph
• perform textual merging
• only research prototypes for syntactic/semantic
  merging
• Next generation version control tools
• Use normalisation
• to compact version graph
• to compare between alternative variants easily
• refactor commonalities in different variants
• More sophisticated merge tools
• syntactic and semantic merging
• domain-independent

38
Overview of Presentation - ?

• Introduction
• Graph Rewriting Formalism
• Reuse Contract Formalism
• Scalability Issues
• Domain-Independence
• Experiments
• Conclusion
• Contribution
• Future Work

39
Contribution

• Domain-independent formalism for evolution
• can be applied in all phases of software
  life-cycle
• Reuse contract formalism enables
• formal distinction between syntactic semantic
  conflicts
• complete fine-grained characterisation of
  conflicts
• scalability (composite contract types,
  normalisation)
• Simple yet general model for evolution
• easy to implement in tools
• simple ideas with large practical impact
• Better support for evolution in tools
• CASE tools, IDEs, version control systems

40
Future Work

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