Research Topics in Software Evolution - PowerPoint PPT Presentation

About This Presentation
Title:

Research Topics in Software Evolution

Description:

Better understanding of the software evolution process itself ... Co-organiser of Workshop on Object-Oriented Architectural Evolution ... – PowerPoint PPT presentation

Number of Views:26
Avg rating:3.0/5.0
Slides: 30
Provided by: EDS88
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com