Katholieke Universiteit Leuven112 April 2000 Research Topics in Software Evolution Dr. Tom Mens FWO...

112 April 2000 Katholieke Universiteit Leuven

Research Topicsin Software Evolution

Research Topicsin Software Evolution

Dr. Tom Mens

FWO Postdoctoral Fellow

Programming Technology Lab

Vrije Universiteit Brussel

2

Long-Term Research GoalLong-Term Research Goal

Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems

3


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


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


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


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 researchCurrent researchE V

O L

U T

I O

N

Better support for software merging

Manage evolution of design patterns

Assess needfor evolution

F O

R M

A L

I S

M SGraph

rewriting

Declarative reasoning

Softwaremetrics

8


O L

U T

I O

N




F O

R M

A L

I S

M SGraph

rewriting


Softwaremetrics

9

Better support for software mergingBetter 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


+intersects(c: Circle)

-radius

Circle

+distanceTo(p: Point)

-x-y

Point

Triangle

+area()+circumference()

Shapecenter

vertices 3

Example: UML class diagram

11


Use graphs to represent software

G

Triangle «class»

Circle «class»

«inherits»

intersects «operation»

«assoc»

center

radius «attribute»

«aggregation»

vertices

{3}

Point «class»Shape «class»

area «operation»

circumference «operation»

x «attribute»

distanceTo «operation»

y «attribute»

«inherits»

Node types:«class»

«attribute»

«operation»

«interface»

Edge types:«assoc»

«aggregation»

«inherits»

«implements»

«accesses»

«updates»

«invokes»

12


implements

nested

operation

attribute

interface

class

assoc, aggregation, inherits

inherits

updates, accesses

invokes

nested

nested

Use type graph to specify domain-specific constraints

Specify other constraints declaratively

13

Use restricted set of primitive graph productions with application preconditions to specify software evolution

AddNode DropNode AddEdge DropEdge RetypeNode RetypeEdge RelabelNode RelabelEdge


AddEdge(area,radius,«accesses»)

R

area «operation»


«a

ccesse

s»

L «a

ccesse

s»

area «operation»


DropNode(Triangle.area,«operation»)

R

Triangle

L

«operation»area

Triangle

14

AddEdge

m

R

area «operation»

radius «attribute»«accesses»

G

Circle «class»

area «operation»

«accesses»



H

Circle «class»

area «operation»«accesses»



L

area «operation»



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

15


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 = DropNode(area,«operation»)

P1 = AddEdge(area,radius,«accesses»)P2

P1

P2

Undefined source conflict

G

Circle «class»

area «operation»

circumfere «operation»


G2

Circle «class»



G1

Circle «class»

area «operation»


radius «attribute» «accesses»

«accesses»

16

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


«class» «class»«inherits»

«inherits»

{added by developer 2}

{added by developer 1}

cyclic inheritance

17

Semantic ConflictsSemantic Conflicts

L1

area «operation»


R1

area «operation»


G

Circle «class»

area «operation»

circumfer «operation»


G1

Circle «class»

area «operation»



«accesses»

«accesses»

m1

AddEdge(,area,radius,«accesses»)

H

Circle «class»

area «operation»



«accesses»

«accesses»

«invokes»

Pushout

construction

L2

area «operation»


R2

area «operation»


«invokes»

G2

Circle «class»

area «operation»

«accesses»


radius «attribute»«invokes»

Refinement(,area,circumference,«uses»)

m2

L

area «operation»

Pullback

construction

area «operation»

area «operation»

18


O L

U T

I O

N




F O

R M

A L

I S

M SGraph

rewriting


Softwaremetrics

19

Manage Evolution of Design PatternsManage 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


Example: Abstract Factory design pattern

MSLook

newWindownewButton

MacLook

newWindownewButton

Look

newWindownewButton

Widget

Window Button

MSWindow

MacWindowMacButton

MSButton

21


Abstract Factory evolution 1: addConcreteFactory(LinuxLook)

MSLook

newWindownewButton

MacLook

newWindownewButton

Look

newWindownewButton

LinuxLook

newWindownewButton

Widget

Window Button

MSWindow

MacWindowMacButton

LinuxButtonLinuxWindow

MSButton

22


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,[LinuxLook])

User input:• Name of concrete Window created by concrete LinuxLook factory: LinuxWindow• Name of concrete Button created by concrete LinuxLook factory: LinuxButton

23


Abstract Factory evolution 2: addAbstractProduct(Menu)

MSLook

newWindownewButtonnewMenu

MacLook


Look


Widget

WindowButton

MSWindow

MacWindowMacButton

MSButton

MacMenu

MSMenu

Menu

24


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


End result after having applied both transformations:

MSLook


MacLook


Look


LinuxLook


Widget

WindowButton

MSWindow

MacWindowMacButton

LinuxButtonLinuxWindow

MSButton

MacMenu

MSMenu

Menu

LinuxMenu

26


O L

U T

I O

N




F O

R M

A L

I S

M SGraph

rewriting


Softwaremetrics

27

Assess need for evolutionAssess 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) => introduce (resp. remove) abstract superclass

28

Software MetricsSoftware 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 classNumber of (abstract/public/instance/...) methods in a classNumber of invocations in a methodNumber of method lines/statements

Number of (immediate/transitive) parents/children of a classNumber of accessors of a given attribute

Method/Attribute Inheritance FactorMethod/Attribute Hiding Factor

Sy Cl Me

At

Ca

St

Li

Co Co

Co

Ac

Co

Co

Co

In Ov,Ex

In

PathLengthNodeCountEdgeCount

RatioSumAverage

29

International ContactsInternational 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

Katholieke Universiteit Leuven112 April 2000 Research Topics in Software Evolution Dr. Tom Mens FWO...

Documents

Transcript of Katholieke Universiteit Leuven112 April 2000 Research Topics in Software Evolution Dr. Tom Mens FWO...