Research Topics in Software Evolution

1
Research Topicsin Software Evolution

• Dr. Tom Mens
• FWO Postdoctoral Fellow
• Programming Technology Lab
• Vrije Universiteit Brussel

2
Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems
3
Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems

• Anticipating evolution ( before)
• how can we improve the quality of the software?
• how can we identify unstable parts in the
  software?
• which parts are badly designed / need
  restructuring?
• Supporting evolution ( during)
• e.g. support for upgrading, restructuring,
  merging,
• documenting evolution
• Analysing evolution ( after)
• does the evolution have the desired effect?
• has the software quality improved?

4
Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems

• Wide range of evolution support tools is needed
• Upgrading software, frameworks and components
• involves version control, collaborative
  development, software merging
• Improving software quality, restructuring
• Assessing software quality, determining need for
  evolution
• Empirical and experimental research
• Management aspects
• Better understanding of the software evolution
  process itself
• Co-evolution, consistency maintenance, compliance
  checking
• Change propagation, impact analysis, effort
  estimation

5
Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems

• Scalability of the technique is essential
• must remain applicable for large-sized software
  systems and for large software development teams
• A major challenge for the research community is
  to develop a good theoretical understanding and
  underpinning for maintenance and evolution, which
  scales to industrial applications.
• K. H. Bennett, V.T. Rajlich, Software Maintenance
  and Evolution A Roadmap, The Future of Software
  Engineering, ACM Press, 2000
• Need for lightweight approaches

6
Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems

• Formal techniques enable domain-independence
• independent of the considered (OO) programming
  language
• e.g., Smalltalk, Eiffel, Java, C,
• independent of the phase in the software
  life-cycle
• e.g., analysis, software architecture, design,
  implementation
• Emphasis on following formalisms
• Graphs and graph rewriting
• Declarative reasoning techniques on top of OO
  language
• Software metrics

7
Current research
8
Current research
9
Better support for software merging

• Based on idea of reuse contracts
• Provide formalism based on graph rewriting
• Represent software by graphs
• Represent software evolution by graph rewriting
• Provide formal characterisation of merge
  conflicts
• Domain-independent approach
• Independent of the target language
• Independent of the phase in the life-cycle

10
Better support for software merging

• Example UML class diagram

Shape
center
area()
circumference()
vertices
3
11
Better support for software merging

• Use graphs to represent software

• Node types
• class
• attribute
• operation
• interface
• Edge types
• assoc
• aggregation
• inherits
• implements
• accesses
• updates
• invokes

12
Better support for software merging

• Use type graph to specify domain-specific
  constraints

assoc, aggregation, inherits
nested
attribute
class
updates, accesses
nested
implements
operation
interface
invokes
nested
inherits
Specify other constraints declaratively
13
Better support for software merging

• Use restricted set of primitive graph productions
  with application preconditions to specify
  software evolution
• AddNode
• DropNode
• AddEdge
• DropEdge
• RetypeNode
• RetypeEdge
• RelabelNode
• RelabelEdge

14
Better support for software merging

• Use single-pushout approach to apply graph
  production to a given initial graph G

AddEdge
m
15
Better support for software merging

• Detect syntactic merge conflicts as breaches of
  application preconditions
• corresponds to notion of parallel dependence
• can be implemented efficiently with a conflict
  table or merge matrix

P1
P2
16
Better support for software merging

• Detect semantic merge conflicts using the formal
  notion of pushouts and pullbacks
• More fine-grained conflict characterisation by
  detecting occurrence of graph patterns in result
  graph

17
Semantic Conflicts
18
Current research
19
Manage Evolution of Design Patterns

• Using declarative metaprogramming
• symbiosis between declarative metalanguage (e.g.
  Prolog) and OO base language (e.g. Smalltalk)
• allows declarative programs to reason about, or
  even generate, object-oriented code
• can be used to
• detect design patterns instances in the source
  code
• specify design patterns (and their instances)
  declaratively
• generate design patterns in the code
• explore the use of different variants of a design
  pattern
• manage evolution of design pattern instances
• Example
• Use declarative transformations to resolve merge
  conflicts between parallel evolutions of same
  design pattern instance

20
Manage Evolution of Design Patterns

• Example Abstract Factory design pattern

21
Manage Evolution of Design Patterns

• Abstract Factory evolution 1 addConcreteFactory(L
  inuxLook)

22
Manage Evolution of Design Patterns

• Declarative transformation
• rule addConcreteFactory(abstractFactory,?I,?CF)
  if addRole(?I,concreteFactory,?CF), ? ?AP
  such that role(?I,abstractProduct,?AP)
  input('Name of concrete ?AP created by concrete
  ?CF factory',?AP,?CF,?CP),
  addRole(?I,concreteProduct,?CP,?AP),
  addRole(?I,concreteRelation,?CF,?CP), ?
  ?Method such that role(?I,abstractFactoryMethod,?
  Method,_) addRole(?I,concreteFactoryMethod,
  ?Method,?CF)
• query addConcreteFactory(abstractFactory,AF,Linux
  Look)
• User input
• Name of concrete Window created by concrete
  LinuxLook factory LinuxWindow
• Name of concrete Button created by concrete
  LinuxLook factory LinuxButton

23
Manage Evolution of Design Patterns

• Abstract Factory evolution 2 addAbstractProduct(M
  enu)

24
Manage Evolution of Design Patterns

• When both Abstract Factory evolutions are
  performed manually by different developers, we
  get a merge conflict
• the Menu class does not contain a LinuxMenu
  subclass
• the LinuxLook class does not contain a newMenu
  factory method
• Solution
• specify the evolutions as explicit declarative
  design pattern transformations
• apply these transformations sequentially

25
Manage Evolution of Design Patterns

• End result after having applied both
  transformations

26
Current research
27
Assess need for evolution

• Use declarative metaprogramming and software
  metrics to
• analyse need for software evolution ( before)
• by identifying unstable parts, weak spots, bad
  design
• Example 1 automatically detect different uses of
  inheritance
• interface/implementation inheritance
• extension/cancellation inheritance
• abstraction/concretisation inheritance
• detect bad practices
• e.g. mixture of interface and implementation
  inheritance
• heavy use of cancellation and abstraction
  inheritance
• Example 2 identify opportunities for refactoring
• classes with common behaviour but no common
  superclass (and vice versa) gt introduce (resp.
  remove) abstract superclass

28
Software Metrics

• Use graphs to provide a generic framework for
  (object-oriented) software metrics
• automatically generate metrics suite for
  particular language
• In collaboration with Michele Lanza, University
  of Berne

Hierarchy Nesting Level Number of
(public/instance/...) attributes of a
class Number of (abstract/public/instance/...)
methods in a class Number of invocations in a
method Number of method lines/statements Number
of (immediate/transitive) parents/children of a
class Number of accessors of a given
attribute Method/Attribute Inheritance
Factor Method/Attribute Hiding Factor
29
International Contacts

• Co-founder, coordinator and secretary of FWO
  Wetenschappelijke OnderzoeksGemeenschap
  Fundamenten van Software-Evolutie
• January 2001 - December 2005
• 4 Flemish research institutes KUL, RUG, UA, VUB
• 5 European research institutes Bern, Vienna,
  Munich, Paderborn, Lisboa
• Co-organiser of Workshop on Formal Foundations of
  Software Evolution
• Lisboa, March 2001, co-located with CSMR 2001
• together with Prof. Michel Wermelinger,
  Universidade Nova de Lisboa
• Co-organiser of Workshop on Object-Oriented
  Architectural Evolution
• Budapest, June 2001, co-located with ECOOP 2001
• together with Prof. Galal H. Galal, University of
  Middlesex London
• Co-organiser of Workshop on Graph-Based Tools
• October 2002, co-located with ICGT 2002
• together with Andy Schurr and Gaby Taentzer