Date post: | 18-Jan-2016 |
Category: |
Documents |
Upload: | clare-bradley |
View: | 219 times |
Download: | 2 times |
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
Long-Term Research GoalLong-Term Research Goal
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?
Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems
4
Long-Term Research GoalLong-Term Research Goal
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
Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems
5
Long-Term Research GoalLong-Term Research Goal
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
Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems
6
Long-Term Research GoalLong-Term Research Goal
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
Developing formally-founded techniques for managing evolution of large-scale object-oriented software systems
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
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
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
Better support for software mergingBetter support for software merging
+intersects(c: Circle)
-radius
Circle
+distanceTo(p: Point)
-x-y
Point
Triangle
+area()+circumference()
Shapecenter
vertices 3
Example: UML class diagram
11
Better support for software mergingBetter support for software merging
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
Better support for software mergingBetter support for software merging
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
Better support for software mergingBetter support for software merging
AddEdge(area,radius,«accesses»)
R
area «operation»
radius «attribute»
«a
ccesse
s»
L «a
ccesse
s»
area «operation»
radius «attribute»
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»
circumference «operation»
radius «attribute»
H
Circle «class»
area «operation»«accesses»
circumference «operation»
radius «attribute»«accesses»
L
area «operation»
radius «attribute»
Better support for software mergingBetter support for software merging
Use single-pushout approach to apply graph production to a given initial graph G
15
Better support for software mergingBetter 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 = DropNode(area,«operation»)
P1 = AddEdge(area,radius,«accesses»)P2
P1
P2
Undefined source conflict
G
Circle «class»
area «operation»
circumfere «operation»
radius «attribute»«accesses»
G2
Circle «class»
circumfere «operation»
radius «attribute»«accesses»
G1
Circle «class»
area «operation»
circumfere «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
Better support for software mergingBetter support for software merging
«class» «class»«inherits»
«inherits»
{added by developer 2}
{added by developer 1}
cyclic inheritance
17
Semantic ConflictsSemantic Conflicts
L1
area «operation»
radius «attribute»
R1
area «operation»
radius «attribute»«accesses»
G
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»«accesses»
G1
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«accesses»
«accesses»
m1
AddEdge(,area,radius,«accesses»)
H
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«accesses»
«accesses»
«invokes»
Pushout
construction
L2
area «operation»
circumfer «operation»
R2
area «operation»
circumfer «operation»
«invokes»
G2
Circle «class»
area «operation»
«accesses»
circumfer «operation»
radius «attribute»«invokes»
Refinement(,area,circumference,«uses»)
m2
L
area «operation»
Pullback
construction
area «operation»
area «operation»
18
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
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
Manage Evolution of Design PatternsManage Evolution of Design Patterns
Example: Abstract Factory design pattern
MSLook
newWindownewButton
MacLook
newWindownewButton
Look
newWindownewButton
Widget
Window Button
MSWindow
MacWindowMacButton
MSButton
21
Manage Evolution of Design PatternsManage Evolution of Design Patterns
Abstract Factory evolution 1: addConcreteFactory(LinuxLook)
MSLook
newWindownewButton
MacLook
newWindownewButton
Look
newWindownewButton
LinuxLook
newWindownewButton
Widget
Window Button
MSWindow
MacWindowMacButton
LinuxButtonLinuxWindow
MSButton
22
Manage Evolution of Design PatternsManage 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,[LinuxLook])
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 PatternsManage Evolution of Design Patterns
Abstract Factory evolution 2: addAbstractProduct(Menu)
MSLook
newWindownewButtonnewMenu
MacLook
newWindownewButtonnewMenu
Look
newWindownewButtonnewMenu
Widget
WindowButton
MSWindow
MacWindowMacButton
MSButton
MacMenu
MSMenu
Menu
24
Manage Evolution of Design PatternsManage 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 PatternsManage Evolution of Design Patterns
End result after having applied both transformations:
MSLook
newWindownewButtonnewMenu
MacLook
newWindownewButtonnewMenu
Look
newWindownewButtonnewMenu
LinuxLook
newWindownewButtonnewMenu
Widget
WindowButton
MSWindow
MacWindowMacButton
LinuxButtonLinuxWindow
MSButton
MacMenu
MSMenu
Menu
LinuxMenu
26
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
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