Title: Research Topics in Software Evolution
1Research Topicsin Software Evolution
- Dr. Tom Mens
- FWO Postdoctoral Fellow
- Programming Technology Lab
- Vrije Universiteit Brussel
2Long-Term Research Goal
Developing formally-founded techniques for
managing evolution of large-scale object-oriented
software systems
3Long-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?
4Long-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
5Long-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
6Long-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
7Current research
8Current research
9Better 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
10Better support for software merging
- Example UML class diagram
Shape
center
area()
circumference()
vertices
3
11Better support for software merging
- Use graphs to represent software
- Node types
- class
- attribute
- operation
- interface
- Edge types
- assoc
- aggregation
- inherits
- implements
- accesses
- updates
- invokes
12Better 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
13Better 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
14Better support for software merging
- Use single-pushout approach to apply graph
production to a given initial graph G
AddEdge
m
15Better 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
16Better 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
17Semantic Conflicts
18Current research
19Manage 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
20Manage Evolution of Design Patterns
- Example Abstract Factory design pattern
21Manage Evolution of Design Patterns
- Abstract Factory evolution 1 addConcreteFactory(L
inuxLook)
22Manage 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
23Manage Evolution of Design Patterns
- Abstract Factory evolution 2 addAbstractProduct(M
enu)
24Manage 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
25Manage Evolution of Design Patterns
- End result after having applied both
transformations
26Current research
27Assess 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
28Software 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
29International 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