Formal Foundations for Software Evolution

1
Formal Foundationsfor Software Evolution

• Programming Technology Lab
• Tom Mens
• tommens_at_vub.ac.be
• http//prog.vub.ac.be/tommens

2
Need better tool support for

• version control
• e.g. upgrading application frameworks
• collaborative software development
• software merging
• change management
• change propagation
• change impact analysis
• ripple effect
• ...
• evolution at a high level of abstraction
• evolution of design patterns
• architectural evolution
• ...

object-orientedsoftwareevolution
3
Need better tool support for

• co-evolution between different phases
• maintaining consistency
• checking compliance between architecture and
  design, design and implementation, ...
• re-engineering of legacy systems
• program comprehension
• reverse engineering
• migration
• ...
• empirical research on software evolution
• based on change metrics
• predictive models
• ...

4
Tool support must be

• scalable
• applicable to large-scale software systems
• A major challenge for the research community is
  to develop a good theoretical understanding an
  underpinning for maintenance and evolution, which
  scales to industrial applications.
  BennettRajlich 2000
• language-independent
• independent of the programming or modelling
  language
• generally applicable in all phases of the
  software life-cycle

5
Reuse Contracts

• Usegraph rewritingto provide aformal
  foundationforsoftware evolution based onreuse
  contracts

6
Benefits of Reuse Contracts

• Document reuse and evolution
• Deal with upgrade problems
• Provide support for software merging
• Provide support for framework refactoring
• Are independent of kind of software artifact
• analysis, architecture, design, implementation

7
1. Documenting Reuse
reuse
size item.size
8
1. Documenting Evolution
evolution
9
2. Dealing with Upgrade Problems
evolution
reuse
10
2. Dealing with Upgrade Problems
evolution
reuse
Coarsening(addMany, add, calls)
inconsistent operation conflict
Extension(size, attribute) Refinement(add, size,
update)
11
2. Dealing with Upgrade Problems

• extension/cancellation adding/removing an
  operation or attribute
• refinement/coarsening adding/removing
  invocation or attribute access
• abstraction/concretisation making an operation
  abstract/concrete

Conflict Table
extension
refinement
coarsening
interface conflicts
extension refinement coarsening
no conflicts
no conflicts
operation capture, unanticipated recursion
operation capture, inconsistent operations
no conflicts
operation capture, inconsistent operations
inconsistent operations
no conflicts
12
3. Support for Software Merging
evolution
evolution
Extension(position, attribute) Extension(move,
method)Coarsening(addMany, add, calls)
inconsistent operation conflict
DesktopFolder v2a
contents size add addMany
Extension(size, attribute) Refinement(add, size,
update)
13
4. Support for FW Refactoring
14
5. Independent of software artifact
provider WebNavigation
client PDFNavigation

collaboration

participant extension

interface
Document
gotoPage
added
participant refinement
participant coarsening
15
Problems with reuse contracts

• How to scale up to higher-level transformations
• e.g. dealing with class collaborations
• How to apply to other domains
• e.g. software architectures
• Solution Provide a formal foundation for reuse
  contracts

16
Reuse Contract Formalism

• Represent software artifacts by graphs
• Represent software evolution by graph rewriting
• Domain-independent formalism
• Independent of the target language
• Independent of the phase in the life-cycle
• Lightweight formalism to facilitate tool support
• Formal characterisation of evolution conflicts
• Prototype tool implemented in Prolog

17
Graphs

• Node types
• class
• attribute
• operation
• interface
• Edge types
• assoc
• has-a (aggregation)
• is-a (generalisation)
• implements

18
Type Graph

• Used to specifydomain-specific constraints

19
Graph Rewriting

• Used to specify software evolution

20
Primitive Graph Productions

• Use restricted set of graph productions
• AddNode
• DropNode
• AddEdge
• DropEdge
• RetypeNode
• RetypeEdge
• RelabelNode
• RelabelEdge

21
Syntactic Conflicts
Syntactic conflict if P1 and P2 are not parallel
independent
P1
P2
22
Syntactic Conflict Table

• Complete fine-grained characterisation of
  syntactic conflicts

23
Semantic Conflicts

• Based on the formal notion of
• pushouts and pullbacks
• Fine-grained conflict characterisation
• By detecting occurrence of graph patterns in
  result graph

inconsistent method conflict
cyclic inheritance
24
Structural Conflicts
More difficult to detect in a general way
25
Using Assertions

• Problem
• Using a predefined set of graph productions is
  not generic
• Introducing new productions requires changes to
  conflict table
• Does not scale up to composite graph productions
• Solution
• make formalism independent of chosen productions
• define productions based on assertions only
• preconditions, postconditions, invariants

26
Example
27
Example ctd.
28
Syntactic Conflict Table

• Detect syntactic merge conflicts
• in terms of transformation preconditions
• compare breaches of application conditions
• Advantages
• more general
• does not rely on predefined graph produtions
• more scalable
• can be used directly for composite or
  domain-specific graph productions

29
Syntactic Conflict Table
30
Using dependencies

• Dependencies can be defined between productions
• based on relations between assertions

31
Using dependencies

• Dependencies can be used to address scalability
• Reordering productions in a sequence
• Defining atomic composite productions from a
  sequence of productions
• Removing redundancy in a production sequence
• Factoring out commonalities from parallel
  production sequences
• Parallellising subsequences

32
1. Reordering productions
33
2. Composite productions
34
3. Removing redundancy

• Allows us to simplify a production sequence

redundant pair
reorder
redundant pair
35
3. Removing Redundancy
36
4. Factoring out commonalities

• Find commonalities in two parallel sequences, and
  factor out
• facilitates merging and conflict detection

37
4. Factoring out Example
38
4. Factoring out Example
39
5. Parallellising subsequences
RenameN(a,surface,area)
AddN(b,perimeter,attribute)
RetypeN(a, attribute,operation)
RetypeN(b, attribute,operation)
AddN(c,radius,attribute)
AddE(e,b,c,uses,uses)
AddE(f,a,c,uses,uses)
DropE(e,b,c)
DropN(b)
40
5. Parallellising subsequences
RenameN(a,surface,area)
RetypeN(a, attribute,operation)
AddN(b,perimeter,attribute)
AddN(c,radius,attribute)
RetypeN(b, attribute,operation)
AddE(e,b,c,uses,uses)
AddE(f,a,c,uses,uses)
DropE(e,b,c)
DropN(b)
41
Validation of Reuse Contracts

• Industrial case
• One base release line with many customisations
  for different customer applications
• Collaborative software development with parallel
  changes to base release and customisations

7.2
NDR
7.4
DR
VTM
10.x
WDR 0.1
TV2
11
WDR 1.0
12
WDR 2.0
42
Validation of Reuse Contracts

• Use reuse contracts to document
• evolution of base release line
• customisation to different customer applications
• evolution of customer applications
• Use conflict detection to support
• upgrades of customer application to more recent
  base release
• refactoring of base release for easier future
  customisation
• Provide help with consolidation
• detect commonalities between different
  customisations
• apply commonalities to base release

43
To Do

• User-friendly tool support
• Perform large-scale experiments
• Validate scalability
• Look at conflict resolution techniques
• Deal with problem of co-evolution

44
Co-Evolution

• Underlying idea
• Keep representation of same software artifact at
  different levels of abstraction (e.g. design and
  implementation) synchronised during evolution

45
Co-Evolution

• needed for collaborative development
• when different persons make changes to same
  software concept at different levels of
  abstraction
• facilitates delta analysis
• relate changes at analysis level back to the code
  and keep them synchronised
• address architectural drift and software erosion
• use a compliance checking algorithm
• detect conflicts between changes at different
  levels