39
A Domain-Independent Formalism for Software Evolution Tom Mens Programming Technology Lab Vrije Universiteit Brussel February, 2000
| Date post: | 25-Dec-2015 |
| Category: |
Documents |
| Upload: | rhoda-wilson |
| View: | 214 times |
| Download: | 0 times |
A Domain-Independent Formalismfor Software Evolution
Tom MensProgramming Technology Lab
Vrije Universiteit Brussel
February, 2000
2
Overview of Presentation -
Introduction Motivation Reuse Contracts Example
Graph Rewriting Formalism Reuse Contract Formalism Scalability Issues Domain-Independence Experiments Conclusion
3
Motivation
Address lack of tool support for software evolution CASE tools, IDEs, version control tools
Provide formal foundation for reuse contracts clear and unambiguous definitions better insight in evolution process facilitate tool support improve scalability
4
Motivation ctd.
Lack of formal approaches to software evolution very few formal approaches available always domain-specific
architectural evolution evolving specifications
usually focus on anticipated changes e.g. run-time software reconfiguration
Need for domain-independent approach to unanticipated software evolution
5
Reuse Contracts
Document unanticipated evolution in a disciplined way Allow to detect conflicts
upgradereuse upgrade
conflict
evolutionevolution merge
conflict
When merging parallel evolutions of same software artifact (collaborative software development)
When upgrading to new versions of software
Lightweight approach simple ideas, easy to implement & customise
6
Pointcenter vertices
Circle
radius
area()circumference()
Triangle
area()circumference()
center 11 3
Example
Evolution of UML class diagrams
{*radius2}
Pointcenter vertices
Circle
radius
Triangle
1 3
Geo
area()circumference()
7
Overview of Presentation -
Introduction Graph Rewriting Formalism
Graphs Graph Rewriting Application Conditions
Reuse Contract Formalism Scalability Issues Domain-Independence Experiments Conclusion
8
Graphs
G
Triangle «class»
Circle «class»
«isa»
intersects «operation»
«assoc»
center
radius «attribute»
«hasa»
vertices
{3}
Point «class»Geo «class»
area «operation»
circumference «operation»
x «attribute»
distanceTo «operation»
y «attribute»
«isa»
• Internal Graph Representation
intersects(c: Circle)
radius
Circle
distanceTo(p: Point)
xy
Point
Triangle
area()circumference()
Geocenter
vertices 3
• Example: UML class diagram Node types:
«class» «attribute» «operation» «interface»
Edge types: «assoc» «hasa»
(aggregation) «isa»
(generalisation) «implements»
9
Type Graph
Node & edge subtype hierarchy Additional constraints needed
e.g. inheritance hierarchy is acyclic
v
e
node type
edge type
implements
nested
operation
attribute
interface
class
assoc, hasa, isa
isa
uses
invokes
nested
nested
10
(Conditional) Graph Rewriting
L
area «operation»
radius «attribute»
P
m
R
area «operation»
radius «attribute»
«uses»
G
Circle «class»
area «operation»
«uses»
circumference «operation»
radius «attribute»
L’
area «operation»
radius «attribute»
C
s
use application conditions: more expressive and concise
represents evolution of arbitrary software artifacts Algebraic single-pushout approach
H
Circle «class»
area «operation»«uses»
circumference «operation»
radius «attribute»«uses»
pushout
constr
uction
11
Anticipated vs. Unanticipated
Application conditions can be used to cope with Anticipated evolution
restrict possible evolutions of a single graph attach application condition to graph
restrict possible evolutions of all graphs attach application condition to graph rewriting system
Unanticipated evolution (Reuse Contracts) Attach application condition to a graph production
to detect structural conflicts more easily
12
Overview of Presentation -
Introduction Graph Rewriting Formalism Reuse Contract Formalism
Detecting evolution conflicts Primitive contract types Applicability conflicts Evolution conflicts
Scalability Issues Domain-Independence Experiments Conclusion
13
Detecting Evolution Conflicts
Two kinds of evolution conflicts Syntactic conflicts Semantic conflicts
Conservative approach: only generate conflict warnings
Approach Provide general formal definition
in terms of graph rewriting formalism
Complete fine-grained characterisation
14
Use a restricted set of possible graph productions
Extension Cancellation
Refinement Coarsening
NodeRetyping EdgeRetyping
Primitive Contract Types
Refinement(,area,radius,«uses»)
R
area «operation»
radius «attribute»
«u
ses»
L «u
ses»
area «operation»
radius «attribute»
Cancellation(area,«operation»)
L
«operation»area
R
15
Structural Conflicts
Refinement(,area,radius,«uses»)
• Applicability conflict if P1 and P2 not parallel independent• Gives rise to ill-formed result graph (syntactic conflict)
G
Circle «class»
area «operation»
circumference «operation»
radius «attribute»«uses»
<<uses>>
G2
Circle «class»
circumference «operation»
radius «attribute»«uses»
G1
Circle «class»
area «operation»
circumference «operation»
radius «attribute»«uses»
«uses»
Cancellation(area,«operation»)
Undefined source conflict
Refinement
Cancellation
P1
P2
16
Applicability Conflict Table
Complete fine-grained characterisation of applicability conflicts
AC3
Extend(v,)
Cancel(v,)
Refine(e,v,w,)
Refine(e,u,v,)
Coarsen(e,v,w,)
Coarsen(e,u,v,)
Nretype(v,,)
ERetype(e,v,w,,)
ERetype(e,u,v,,)
Extension(v,)
AC1
Cancellation(v,)
AC2 AC3 AC4 AC9
Refinement(e,v,w,)
AC5
Refinement(e,u,v,)
AC4 AC5
Coarsening(e,v,w,)
AC6 AC10
if =
Coarsening(e,u,v,)
AC6 AC10
if =NodeRetype
(v,,) AC9 AC7
EdgeRetype(e,v,w,,)
AC10
if = AC8
if =
EdgeRetype(e,u,v,,)
AC10
if = AC8
if =
17
Applicability Conflict Table ctd. Duplicate Node Conflict Double Cancellation Conflict Undefined Source Conflict Undefined Target Conflict Duplicate Edge Conflict Double Coarsening Conflict Double Node Retyping Conflict Double Edge Retyping Conflict Undefined Node Retyping Conflict Undefined Edge Retyping Conflict
18
Alternative Conflict Table
Compare breaches of application conditions more general
does not rely on primitive contract types
more scalable can be used directly for composite contract types
or domain-specific contract types
19
AC1
AC8
AC7
AC10
AC6 AC10
AC9
AC9
AC5
AC3
AC3
AC2
Alternative Conflict Table
v v v we v we type(v)= type(e,v,w)=
v
v
v we
v we
type(v)=
type(e,v,w)=
20
Evolution Conflicts
L1
area «operation»
radius «attribute»
R1
area «operation»
radius «attribute»«uses»
G
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»«uses»
G1
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«uses»
«uses»
m1
Refinement(,area,radius,«uses»)
H
Circle «class»
area «operation»
circumfer «operation»
radius «attribute»
«uses»
«uses»
«uses»
Pushout
construction
L2
area «operation»
circumfer «operation»
R2
area «operation»
circumfer «operation»
«uses»
G2
Circle «class»
area «operation»
«uses»
circumfer «operation»
radius «attribute»«uses»
Refinement(,area,circumference,«uses»)
m2
L
area «operation»
Pullback
construction
area «operation»
area «operation»
21
Finer-grained characterisation Compare pairs of primitive contract types
double reachability conflict cycle introduction conflict
Detect graph patterns in result of merge more general more scalable
Evolution Conflict Detection
«uses»area radius
«uses»
{evolver 1}
{evolver 2}
23
Overview of Presentation -
Introduction Graph Rewriting Formalism Reuse Contract Formalism Scalability Issues
Composite Contract Types Normalisation
Domain-Independence Experiments Conclusion
24
Composite Contract Types
G0
Triangle «class»
area «operation»
Circle «class»
area «operation»
«assoc»center
circumference «operation» circumference «operation»
«assoc»
center
radius «attribute»
«hasa»vertices
Point «class»
G1
Triangle «class»
area «operation»
Circle «class»
area «operation»
circumference «operation» circumference «operation»
«assoc»
center
radius «attribute»
«hasa»vertices
Point «class»Geo «class»
«isa»«isa»
CreateSuperclass(Geo,[Circle,Triangle])
Extension(Geo,«class»)Refinement(,Circle,Geo,«isa»)
Refinement(,Triangle,Geo,«isa»)Coarsening(center,Circle,Point,«assoc»)
Coarsening(center,Triangle,Point,«assoc»)Refinement(center,Geo,Point,«assoc»)
25
Composite Contract Types ctd.
MoveNode(area,«operation»,Circle,Geo)MoveNode(circumference,«operation»,Circle,Geo)
Cancellation(Triangle.area,«operation»)Cancellation(Triangle.circumference,«operation»)
Refactor(Geo,[area,circumference])
G1
Triangle «class»
area «operation»
Circle «class»
area «operation»
circumference «operation» circumference «operation»
«assoc» cente
r
radius «attribute»
«hasa»vertices
Point «class»Geo «class»
«isa»«isa»
G2
Triangle «class»
Circle «class»
«assoc»center
radius «attribute»«hasa»vertices
Point «class»
Geo «class»
«isa»
«isa»
area «operation»
circumference «operation»
26
Composite Contract Types ctd.
Composite contract types can be domain-independent can be domain-specific (e.g. CreateSuperclass) are defined as composite productions
Conflicts can be detected directly using alternative applicability conflict table using graph pattern approach
Advantages more practical in use atomic, more efficient remove unnecessary conflict warnings
27
Normalisation algorithm
Remove redundancy in evolution sequence remove redundant couples
Extension; Cancellation
absorb couples of primitive contract types Refinement; EdgeRetyping = Refinement
Rearrange primitive contract types based on sequential independence canonical form
Extensions; NodeRetypings; Refinements, ...
28
Normalisation ctd.
Advantages compacts evolution sequence (reduces
complexity) removes unnecessary conflict warnings makes evolution process easier to understand
finding specific modifications comparing differences between parallel evolutions
To do improve efficiency of normalisation algorithm rely on canonical form for merging normalised
evolution sequences
29
Overview of Presentation -
Introduction Graph Rewriting Formalism Reuse Contract Formalism Scalability Issues Domain-Independence
Possible Customisations Customising the formalism Case studies
Experiments Conclusion
30
Possible Customisations
class collaborations extension and generalisation of [Lucas97] similar to UML collaboration diagrams
[Mens&al99]
UML class diagrams software architectures [Romero99] others
other UML diagrams non-OO paradigms?
31
Case study: UML class diagrams
Specify type graph & type constraints Specify domain-specific modifications
Primitive contract types Extension: AddOperation, AddAttribute, AddClassifier Cancellation: DropOperation, DropAttribute, DropClassifier Refinement: AddGeneralisation, AddAssociation
Composite contract types (e.g. CreateSuperclass)
Fine-tune conflict detection type graph gives rise to new applicability conflicts wf-constraints capture some evolution conflict
warnings e.g. cycle introduction for inheritance-edges
use domain-specific knowledge to ignore conflict warnings e.g. ignore cycle introduction for associations
32
Domain-specific normalisation
AddClass(B); AddClass(A); AddOperation(A.m);
DropClass(B); AddAttribute(A.a);
DropOperation(A.m)
Extension(B,«class»); Extension(A,«class»);
Extension(A.m,«operation»); Cancellation(B,«class»);
Extension(A.a,«attribute»); Cancellation(A.m,«operation»)
Extension(A,«class»); Extension(A.a, «attribute»)
normalisation
AddClass(A); AddAttribute(A.a)
Dom
ain-
inde
pend
ent
fram
ewor
k
Dom
ain-
spec
ific
cu
stom
isat
ion
translation translation
(not for composite contract types)
33
Case study: software architectures
need to detect more high-level conflicts introduce derived edges
in
«gate»
out
«gate»
«link»
Parser «component»
Pipe2 «connector»
Semantor «component» Coder «component»
Pipe3 «connector»
«link» «link» «link»
SequentialCompiler «architecture»
Lexer «component»
Pipe1 «connector»
«link» «link»
«binding» «binding»
in
«gate»
in
«gate»
in
«gate»
in
«gate»
in
«gate»
in
«gate»
in
«gate»
out
«gate»
out
«gate»
out
«gate»
out
«gate»
out
«gate»
out
«gate»
out
«gate»«pipe» «pipe» «pipe»
34
Overview of Presentation -
Introduction Graph Rewriting Formalism Reuse Contract Formalism Scalability Issues Domain-Independence Experiments Conclusion
35
Experiments
Implementation of basic formalism primitive contract types, conflict detection implemented in PROLOG
rapid prototyping expressing conflict detection rules directly unification mechanism for detecting graph patterns use SOUL to access and reason about Smalltalk code
Scalability normalisation algorithm no validation of composite contract types
lack of adequate (large-scale) industry case
36
Experiments ctd.
Domain-specific customisation customisations of PROLOG framework
UML class diagrams small experiments with UML CASE tools identify basic conflicts for class diagrams
(based on small changes in industry case study) software architectures [Romero99]
Further experiments needed develop and implement efficient algorithms validate scalability aspects integrate in CASE tool and version control tool
37
Current-day version control systems use version graph perform textual merging
only research prototypes for syntactic/semantic merging
Next generation version control tools Use normalisation
to compact version graph to compare between alternative variants easily refactor commonalities in different variants
More sophisticated merge tools syntactic and semantic merging domain-independent
RCs for version control
38
Overview of Presentation -
Introduction Graph Rewriting Formalism Reuse Contract Formalism Scalability Issues Domain-Independence Experiments Conclusion
Contribution Future Work
39
Contribution
Domain-independent formalism for evolution can be applied in all phases of software life-cycle
Reuse contract formalism enables formal distinction between syntactic & semantic conflicts complete fine-grained characterisation of conflicts scalability (composite contract types, normalisation)
Simple yet general model for evolution easy to implement in tools simple ideas with large practical impact
Better support for evolution in tools CASE tools, IDEs, version control systems
40
Future Work
Focus on conflict resolution More scalability issues
techniques to reduce potential conflicts use more sophisticated conflict detection techniques
in presence of composite contract types modify normalisation algorithm factorisation algorithm for generating composite contract types formal properties (e.g. commutativity, inverse, ...)
Co-evolution between different models / between model and metamodel
Enhancing underlying graph formalism nested hyperedges, encapsulation mechanism, parameterisation
mechanism, more complex application conditions, ... extension needs to preserve formal properties
