The document discusses identifying design motifs (patterns) in object-oriented program architectures to improve understanding and quality. It proposes using design patterns from the Gang of Four as motifs and the PADL meta-model to model the program architecture and motifs. Motifs would be identified by representing the problem as a constraint satisfaction problem and using constraint programming to find similarities between the architecture and motifs.

1. Traceability of patterns for the
understanding and the quality
of object-oriented programs
Yann-Gaël Guéhéneuc
École des Mines
de Nantes, France
Object Technology
International, Inc., Canada
yann-gael@gueheneuc.net
www.yann-gael.gueheneuc.net

2. 2/64
Software understanding is about…
… Understanding!
n Do not hesitate to interrupt
n Questions are most welcome

3. 2/64
Software understanding is about…
… Understanding!
n Do not hesitate to interrupt
n Questions are most welcome

4. 3/64
Context
n Quality of object-oriented programs
n Quality of object-oriented program
architectures

5. 4/64
Motivations
n To ease the understanding of a program
architecture to improve its quality
« A style, individual or collective, is a
signature allowing recognition. » [Compagnon02]

6. 5/64
Example
n Do you know
– C++?
– Java?
– Lisp?
– Prolog?
– Smalltalk?

7. 6/64
C++
class Dog {
string name;
Dog(const Dog* dog) : name(dog→name) {}}
class Kennel { Dog* dog; string name; }
if (&kennel != this) {
this→dog =
new Dog(kennel.dog);
this→name = kennel.name;
}
return *this;
Suite…Bruce Eckel ; Thinking in C++ ; Volume 2, pages 551–553, Planet PDF, 2nd Edition, 2000.

8. 6/64
C++
class Dog {
string name;
Dog(const Dog* dog) : name(dog→name) {}}
class Kennel { Dog* dog; string name; }
if (&kennel != this) {
this→dog =
new Dog(kennel.dog);
this→name = kennel.name;
}
return *this;
Suite…Bruce Eckel ; Thinking in C++ ; Volume 2, pages 551–553, Planet PDF, 2nd Edition, 2000.
?

9. 6/64
C++
class Dog {
string name;
Dog(const Dog* dog) : name(dog→name) {}}
class Kennel { Dog* dog; string name; }
if (&kennel != this) {
this→dog =
new Dog(kennel.dog);
this→name = kennel.name;
}
return *this;
Suite…Bruce Eckel ; Thinking in C++ ; Volume 2, pages 551–553, Planet PDF, 2nd Edition, 2000.
?
Overriding of
operator =

10. 7/64
Java
final Object oldListOfEntities =
this.listOfEntities();
this.fireVetoableChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
this.removeEntity(anEntity);
this.firePropertyChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
Suite…

11. 7/64
Java
final Object oldListOfEntities =
this.listOfEntities();
this.fireVetoableChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
this.removeEntity(anEntity);
this.firePropertyChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
Suite…
?

12. 7/64
Java
final Object oldListOfEntities =
this.listOfEntities();
this.fireVetoableChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
this.removeEntity(anEntity);
this.firePropertyChange(
"RemoveEntity",
oldListOfEntities,
anEntity);
Suite…
?
Veto protocol
of JavaBeans

13. 8/64
(define (square ls)
(if (null? ls)
'()
(cons (( lambda(x) (* x x))
(car ls))
(square (cdr ls)))))
Lisp
Suite…

14. 8/64
(define (square ls)
(if (null? ls)
'()
(cons (( lambda(x) (* x x))
(car ls))
(square (cdr ls)))))
Lisp
Suite…
?

15. 8/64
(define (square ls)
(if (null? ls)
'()
(cons (( lambda(x) (* x x))
(car ls))
(square (cdr ls)))))
Lisp
Suite…
?Map

16. 9/64
Prolog
checkLt0(LA, LT, LD, NNLA, NNLT, NNLD) :-
nextEvent(
[],
E),
interpretEvent(E, IE),
checkLt1(IE, LA, LT, LD, NLA, NLT, NLD),
!,
(
(IE = programEnd,
NNLA = NLA,
NNLT = NLT,
NNLD = NLD)
;
checkLt0(NLA, NLT, NLD, NNLA, NNLT, NNLD)
).
Suite…

17. 9/64
Prolog
checkLt0(LA, LT, LD, NNLA, NNLT, NNLD) :-
nextEvent(
[],
E),
interpretEvent(E, IE),
checkLt1(IE, LA, LT, LD, NLA, NLT, NLD),
!,
(
(IE = programEnd,
NNLA = NLA,
NNLT = NLT,
NNLD = NLD)
;
checkLt0(NLA, NLT, NLD, NNLA, NNLT, NNLD)
).
Suite…
?

18. 9/64
Prolog
checkLt0(LA, LT, LD, NNLA, NNLT, NNLD) :-
nextEvent(
[],
E),
interpretEvent(E, IE),
checkLt1(IE, LA, LT, LD, NLA, NLT, NLD),
!,
(
(IE = programEnd,
NNLA = NLA,
NNLT = NLT,
NNLD = NLD)
;
checkLt0(NLA, NLT, NLD, NNLA, NNLT, NNLD)
).
Suite…
?Condition

19. 10/64
Smalltalk
Integer>>+ aNumber
^aNumber addInteger: self
Float>>+ aNumber
^aNumber addFloat: self
Integer>>addInteger: anInteger
<primitive: 1>
Float>>addFloat: aFloat
<primitive: 2>
Integer>>addFloat: aFloat
^self asFloat addFloat: aFloat
Float>>addInteger: anInteger
^self addFloat: anInteger asFloat
Kent Beck ; Smalltalk – Best practice patterns ; Pages 55–57, Prentice Hall, 1997, ISBN 0-13-476904-X.

20. 10/64
Smalltalk
Integer>>+ aNumber
^aNumber addInteger: self
Float>>+ aNumber
^aNumber addFloat: self
Integer>>addInteger: anInteger
<primitive: 1>
Float>>addFloat: aFloat
<primitive: 2>
Integer>>addFloat: aFloat
^self asFloat addFloat: aFloat
Float>>addInteger: anInteger
^self addFloat: anInteger asFloat
Kent Beck ; Smalltalk – Best practice patterns ; Pages 55–57, Prentice Hall, 1997, ISBN 0-13-476904-X.
?

21. 10/64
Smalltalk
Integer>>+ aNumber
^aNumber addInteger: self
Float>>+ aNumber
^aNumber addFloat: self
Integer>>addInteger: anInteger
<primitive: 1>
Float>>addFloat: aFloat
<primitive: 2>
Integer>>addFloat: aFloat
^self asFloat addFloat: aFloat
Float>>addInteger: anInteger
^self addFloat: anInteger asFloat
Kent Beck ; Smalltalk – Best practice patterns ; Pages 55–57, Prentice Hall, 1997, ISBN 0-13-476904-X.
?
Double
dispatching

22. 11/64
Conclusion on the example
n You identified idioms in the given pieces
of source code
n These idioms are motifs in a program
source code
n These motifs connote a recognized
style of programming

23. 12/64
Motivations
n To ease the understanding of a program
architecture to improve its quality
èTo identify motifs in the program
architecture

24. 13/64
Problems
n What motifs and what model for these
motifs?
n What model for the program
architecture?
n How to perform the identification?

25. 14/64
Our solution
n What motifs and what model for these
motifs?
n What model for the program
architecture?
n How to perform the identification?

26. 14/64
Our solution
n What motifs and what model for these
motifs?
n What model for the program
architecture?
n How to perform the identification?
Design patterns and
the PDL meta-model

27. 14/64
Our solution
n What motifs and what model for these
motifs?
n What model for the program
architecture?
n How to perform the identification?
Design patterns and
the PDL meta-model
Meta-modeling

28. 14/64
Our solution
n What motifs and what model for these
motifs?
n What model for the program
architecture?
n How to perform the identification?
Design patterns and
the PDL meta-model
Meta-modeling

29. 15/64
Our solution
n Design patterns from the Gang of Four
[Gamma94]
n Meta-model PDL [Albin-Amiot03, chapter 3]
– Model of design pattern solutions
– Manual mechanisms

30. 16/64
Our solution
n Meta-model PADL
– Extension of PDL
– Program architecture
• Classes
• Relations among classes
– Automated mechanisms
• Static analyses
• Dynamic Analyses

31. 17/64
Our solution
n Constraint satisfaction problem solved
with explanation-based constraint
programming
èTraceability of patterns for the
understanding and the quality of
object-oriented programs

32. 18/64
Design patterns
n [Alexander77, Gamma94] : sets
〈name, problem, solution, trade-offs〉
n Name a recurring problem, its solution
and the associated trade-offs
èDesign pattern solution
= design motif which connotes an
elegant architecture

33. 18/64
Design patterns
n [Alexander77, Gamma94] : sets
〈name, problem, solution, trade-offs〉
n Name a recurring problem, its solution
and the associated trade-offs
èDesign pattern solution
= design motif which connotes an
elegant architecture

34. 18/64
Design patterns
n [Alexander77, Gamma94] : sets
〈name, problem, solution, trade-offs〉
n Name a recurring problem, its solution
and the associated trade-offs
èDesign pattern solution
= design motif which connotes an
elegant architecture

35. 19/64
The Composite design pattern –
problem [Gamma94]
n To compose objects in a tree-like
structure to describe whole–part
hierarchies
n To let a client uniformly manipulate
objects and compositions of objects

36. 20/64
n Design motif
The Composite design pattern –
solution
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

37. 21/64
The Composite design pattern –
example
n Micro-architecture (instance of the motif)
Graphics
draw()
Text
draw()
Image
add(Graphics)
remove(Graphics)
getGraphics(int)
draw()
graphicComponents
For each graphicComponents
graphicComponent.draw()
1..n
Line
draw()
Rectangle
draw()

38. 22/64
The JHotDraw program –
example [Gamma98]
n 2D drawing
n Erich Gamma and
Thomas Eggenschwiler
n Design patterns

39. 23/64
TheJHotDrawprogram–
architecture
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

40. 23/64
TheJHotDrawprogram–
architecture
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

41. 24/64
Problem
How to identify
in the architecture
of a program
micro-architectures
similar to
design motifs
to explain the
problem solved?
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objects
in a tree-like structure
to describe whole–part
hierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component )
remove(Component )
getComponent (int)
operation()
ramification
For each components
component.operation ()
1..n
Client

42. 24/64
Problem
How to identify
in the architecture
of a program
micro-architectures
similar to
design motifs
to explain the
problem solved?
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objects
in a tree-like structure
to describe whole–part
hierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component )
remove(Component )
getComponent (int)
operation()
ramification
For each components
component.operation ()
1..n
Client
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

43. 24/64
Problem
How to identify
in the architecture
of a program
micro-architectures
similar to
design motifs
to explain the
problem solved?
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objects
in a tree-like structure
to describe whole–part
hierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component )
remove(Component )
getComponent (int)
operation()
ramification
For each components
component.operation ()
1..n
Client
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component
remove(Component
getComponent
1..
Client

44. 24/64
Problem
How to identify
in the architecture
of a program
micro-architectures
similar to
design motifs
to explain the
problem solved?
Figure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
To compose objects
in a tree-like structure
to describe whole–part
hierarchies
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component )
remove(Component )
getComponent (int)
operation()
ramification
For each components
component.operation ()
1..n
Client
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Component
operation()
Leaf
operation()
Composite
add(Component
remove(Component
getComponent
1..
Client
operation()
Leaf
operation()
Composite
add(Component )
remove(Component )
getComponent (int)
operation()
ramification
For each components
component.operation ()

45. 25/64
Characteristics
n Hypotheses (for today J)
– Model of the architecture
– Model of the design motif
n Similarities
– Precise ⇒ the architecture is elegant
– Loose ⇒ to explain why and to offer
possible modifications

46. 26/64
Characteristics
èNo a priori descriptions of similarities
èJustification of the identified micro-
architectures
èStrong interaction with the developers

47. 27/64
Constraint satisfaction problem
(CSP) [Montanari74]
n Set 〈V, C, D〉
– Variables V = {v1, …, vn}
– Constraints C = {C1, …, Ce}
– Domains D = {D1, …, Dn}

48. 28/64
CSP
n Putting together pieces of a car
V = {top, sides, roof}
C = {top ↔ sides, sides ↔ roof,
top ↔ roof}
D = {〈red, green, blue〉, 〈green, black〉,
〈green, blue, yellow〉}

49. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

50. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

51. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

52. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

53. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

54. 29/64
n Solution
– Instantiation
• top = 〈green〉
– Propagation
• top ↔ sides ⇒ sides = 〈green〉
• top ↔ roof ⇒ roof = 〈green〉
– Satisfaction
• sides ↔ roof
top
sides
roof
CSP

55. 30/64
CSP
n CSP deducted from
– Model of the design motif
• Participants → variables
• Relations among participants → constraints
– Model of the architecture of the program
• Classes of the program → domain
• Relations among classes of the program →
semantics of the constraints

56. 31/64
CSP
n Model of the Composite design motif
– Three participants ⇒ three variables
• component
• leaf
• composite
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

57. 32/64
CSP
n Model of the Composite design motif
– Relations among participants ⇒ constraints
• leaf < component
• composite < component
• composite u component
• Differences between classes
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

58. 32/64
CSP
n Model of the Composite design motif
– Relations among participants ⇒ constraints
• leaf < component
• composite < component
• composite u component
• Differences between classes
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
Differences between classes

59. 33/64
Relations among
classes, attributes
+
n Model of the architecture of the
JHotDraw program
– Classes of the program ⇒ domain
• DrawingEditor
• DrawingView
• Tool
• Drawing
• …
CSP
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure

60. 33/64
Relations among
classes, attributes
+
n Model of the architecture of the
JHotDraw program
– Classes of the program ⇒ domain
• DrawingEditor
• DrawingView
• Tool
• Drawing
• …
CSP
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Relations among
classes, attributes
+

61. 34/64
CSP
n Identification of the micro-architectures
similar to the Composite design motif
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}

62. 35/64
Constraint programming (CP) [Tsang93]
n Paradigm of resolution of CSP
n Resolution = to execute an algorithm to
get the solutions of a CSP
n Chronological backtrack, intelligent
backtrack, retrospective, prospective,
retro-prospective algorithms

63. 36/64
CP
n Solution
– ∃ instantiation of the variables all
constraints are satisfied
– Complete instantiation
– sides = 〈green〉 , roof = 〈green〉, top =
〈green〉
n Contradiction (no solution)
– Domain of a variable empty

64. 37/64
Explanation-based constraint
programming (e-CP) [Jussien01]
n Retro-prospective algorithm
– Reparation
• No more chronological backtrack
• Operations of removals from or restorations in
domains
n Tool : explanations
– Subset of the operations which leads to a
contradiction
– Dynamic management

65. 38/64
e-CP
n Solution
– ∃ operations of removals from or
restorations in domains complete
instantiation
n Contradiction
– Subset of the operations which leads to a
contradiction
– Set of explanations

66. 39/64
e-CP
V = {top, sides, roof}
C = {top ↔ sides, sides ↔ roof,
top ↔ roof}
D = {〈red, green, blue〉, 〈green, black〉,
〈green, blue, yellow〉}
top = 〈green〉 ∧ sides ↔ roof
→ ¬sides = 〈black〉
⇒ removal of black from the domain

67. 39/64
e-CP
V = {top, sides, roof}
C = {top ↔ sides, sides ↔ roof,
top ↔ roof}
D = {〈red, green, blue〉, 〈green, black〉,
〈green, blue, yellow〉}
top = 〈green〉 ∧ sides ↔ roof
→ ¬sides = 〈black〉
⇒ removal of black from the domain
ç

68. 39/64
e-CP
V = {top, sides, roof}
C = {top ↔ sides, sides ↔ roof,
top ↔ roof}
D = {〈red, green, blue〉, 〈green, black〉,
〈green, blue, yellow〉}
top = 〈green〉 ∧ sides ↔ roof
→ ¬sides = 〈black〉
⇒ removal of black from the domain
ç
ç

69. 40/64
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
e-CP

70. 40/64
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
e-CP

71. 40/64
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
e-CP

72. 40/64
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
e-CP

73. 41/64
e-CP
n Explanation of contradiction
– composite u component
n No solution with this constraint

74. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

75. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

76. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

77. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

78. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

79. 42/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
e-CP

80. 43/64
e-CP
n Explanation of contradiction
– leaf < component
– composite < component
– composite u component
n No solution with these constraints

81. 44/64
Approach
n Problem relaxation
n Constraint relaxation
n Constraint weight

82. 45/64
Problem relaxation [Petit02]
n To remove the constraint leading to a
contradiction
– composite u component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}

83. 45/64
Problem relaxation [Petit02]
n To remove the constraint leading to a
contradiction
– composite u component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}

84. 46/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Problem
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

85. 46/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Problem
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

86. 46/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Problem
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
For each components
component.operation()

87. 47/64
Constraint relaxation
n To replace a constraint with a weaker
constraint
– composite u component
– composite w component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}

88. 47/64
Constraint relaxation
n To replace a constraint with a weaker
constraint
– composite u component
– composite w component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Composition

89. 47/64
Constraint relaxation
n To replace a constraint with a weaker
constraint
– composite u component
– composite w component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Composition
Aggregation

90. 47/64
Constraint relaxation
n To replace a constraint with a weaker
constraint
– composite u component
– composite w component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Composition
Aggregation
w

91. 48/64
n To replace a constraint with a different
constraint
– leaf < component
– leaf < component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint relaxation
<

92. 48/64
n To replace a constraint with a different
constraint
– leaf < component
– leaf < component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint relaxation
<
Direct inheritance

93. 48/64
n To replace a constraint with a different
constraint
– leaf < component
– leaf < component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint relaxation
<
Direct inheritance
Indirect inheritance

94. 48/64
n To replace a constraint with a different
constraint
– leaf < component
– leaf < component
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint relaxation
<
Direct inheritance
Indirect inheritance
<< <<

95. 49/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client

96. 49/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
w
<< <<

97. 49/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
V = {component, leaf, composite}
C = {leaf < component, composite <
component, composite u component}
D = {〈DrawingEditor, DrawingView…〉}
Constraint
relaxation
Component
operation()
Leaf
operation()
Composite
add(Component)
remove(Component)
getComponent(int)
operation()
ramification
For each components
component.operation()
1..n
Client
w
<< <<
For each components
component.operation()

98. 50/64
Constraint weight
n Predefined order of problem relaxation
and constraint relaxation
– Experience of the developers
90 : Composition → aggregation
50 : Direct inheritance → Indirect
inheritance

99. 51/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Conclusion
n Weaker form of
the Composite
design motif
n Problem of the Composite design
pattern, trade-offs adapted to the
context

100. 51/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Conclusion
n Weaker form of
the Composite
design motif
n Problem of the Composite design
pattern, trade-offs adapted to the
context

101. 51/64
Frame
DrawingEditor
Tool
Handle
Panel
DrawingView
Drawing
Figure
AbstractFigure
CompositeFigureAttributeFigure PolyLineFigureDecoratorFigure
Conclusion
n Weaker form of
the Composite
design motif
n Problem of the Composite design
pattern, trade-offs adapted to the
context

102. 52/64
Conclusion
n Similarities
– Precise ⇒ the architecture is elegant
– Loose ⇒ to explain why and to offer
possible modifications
èNo a priori descriptions of the
similarities
èJustification of the identified micro-
architectures
èStrong interaction with the developers

103. 52/64
Conclusion
n Similarities
– Precise ⇒ the architecture is elegant
– Loose ⇒ to explain why and to offer
possible modifications
èNo a priori descriptions of the
similarities
èJustification of the identified micro-
architectures
èStrong interaction with the developers
ü

104. 52/64
Conclusion
n Similarities
– Precise ⇒ the architecture is elegant
– Loose ⇒ to explain why and to offer
possible modifications
èNo a priori descriptions of the
similarities
èJustification of the identified micro-
architectures
èStrong interaction with the developers
ü
ü

105. 52/64
Conclusion
n Similarities
– Precise ⇒ the architecture is elegant
– Loose ⇒ to explain why and to offer
possible modifications
èNo a priori descriptions of the
similarities
èJustification of the identified micro-
architectures
èStrong interaction with the developers
ü
ü
ü

106. 53/64
Implementation
n Extension of the e-CP framework
– Claire [Caseau96]
– Choco [Laburthe00]
– PaLM [Jussien00]
– Ptidej [Guéhéneuc01]

107. 54/64
Implementation
n Constraints
– Direct, indirect, strict inheritance
– Knowledge, association, aggregation,
composition, ignorance, creation
– Association distance, depth in the
inheritance tree
n Design motifs
– Composite, Façade, Abstract Factory…

108. 55/64
n Ptidej (Pattern Trace Identification, Detection, and Enhancement in Java) [Guéhéneuc01]
PaLM
Identified micro-architectures
PDL
Java Source code
Model of the architecture
Uses
Produces
Ptidej
Model of the design motifs
Introspector (PDL) JavaXL
Implementation

109. 55/64
n Ptidej (Pattern Trace Identification, Detection, and Enhancement in Java) [Guéhéneuc01]
PaLM
Identified micro-architectures
PDL
Java Source code
Model of the architecture
Uses
Produces
Ptidej
Model of the design motifs
Introspector (PDL) JavaXL
Implementation
PaLM
JavaXL

110. 56/64
Ptidej

111. 57/64
Ptidej

112. 58/64
Evaluation
n Difficult
– No other existing tools
– Differing semantics
n Need for a methodology [Albin-Amiot03, chapter 6]
– Postulate
– Hypotheses, interpretation of the pattern
– Extent of the motif identification

113. 59/64
Evaluation
Weak
Hits Miss False Hits
java.awt.* 121 1 1 1 1 7 82,6
JHotDraw 155 1 1 0,3 1 3 65,5
JUnit 34 1 1 0,4 1 7 22,9
JEdit 248 1,4 29,5
PatternsBox 52 0,3 3 40,3
610 3 2 1 0 0,7 3 0 0 20 48,2
Understanding (Ptidej)
Hits Miss False
t
(sec.)
t
(sec.)
Complete
Composite
Documentation (PatternsBox)
Design
patterns
Programs NLC Existing

114. 59/64
Evaluation
Weak
Hits Miss False Hits
java.awt.* 121 1 1 1 1 7 82,6
JHotDraw 155 1 1 0,3 1 3 65,5
JUnit 34 1 1 0,4 1 7 22,9
JEdit 248 1,4 29,5
PatternsBox 52 0,3 3 40,3
610 3 2 1 0 0,7 3 0 0 20 48,2
Understanding (Ptidej)
Hits Miss False
t
(sec.)
t
(sec.)
Complete
Composite
Documentation (PatternsBox)
Design
patterns
Programs NLC Existing

115. 59/64
Evaluation
Weak
Hits Miss False Hits
java.awt.* 121 1 1 1 1 7 82,6
JHotDraw 155 1 1 0,3 1 3 65,5
JUnit 34 1 1 0,4 1 7 22,9
JEdit 248 1,4 29,5
PatternsBox 52 0,3 3 40,3
610 3 2 1 0 0,7 3 0 0 20 48,2
Understanding (Ptidej)
Hits Miss False
t
(sec.)
t
(sec.)
Complete
Composite
Documentation (PatternsBox)
Design
patterns
Programs NLC Existing

116. 60/64
Evaluation
Weak
Hits Miss False Hits
java.awt.* 121 1 1 1 1 7 82,6
JHotDraw 155 1 1 0,3 1 3 65,5
JUnit 34 1 1 0,4 1 7 22,9
JEdit 248 1,4 29,5
PatternsBox 52 0,3 3 40,3
java.awt.* 121 0,2 1 7 82,6
JHotDraw 155 1 3 2 0,4 1 3 65,5
JUnit 34 1 1 0,2 1 7 22,9
JEdit 248 0,4 29,5
PatternsBox 52 0,3 3 40,3
java.awt.* 121 3 1,1 3 8 1 7
JHotDraw 155 2 2 1 1 0,5 2 37 1 103,7
JUnit 34 1 1 23
JEdit 248 0,1 6 29,7
PatternsBox 52 0,2 7 1 13,5
java.awt.* 121 12 75,6
JHotDraw 155 3 3 0,1 3 100 231,1
JUnit 34 8 22,7
JEdit 248 1 1 0,1 1 28,5
PatternsBox 52 79 36,5
java.awt.* 121 3,4 4 4 73,5
JHotDraw 155 2 2 3,2 2 2 2 61,4
JUnit 34 4 4 2,5 19,9
JEdit 248 3 3 13 3 27,8
PatternsBox 52 1 1 2,8 2 1 2 31,5
java.awt.* 121 3 3 0,7
JHotDraw 155 2 2 0,5
JUnit 34 0,4
JEdit 248 1
PatternsBox 52 1 1 0,5
610 30 28 2 3 1,3 18 9 262 50 50,7
Itérateur
Observateur
Singleton N/A
Composite
Décorateur
Méthode
usine
Documentation (PatternsBox)
Design
patterns
Programs NLC Existing
Understanding (Ptidej)
Hits Miss False
t
(sec.)
t
(sec.)
Complete

117. 60/64
Evaluation
Weak
Hits Miss False Hits
java.awt.* 121 1 1 1 1 7 82,6
JHotDraw 155 1 1 0,3 1 3 65,5
JUnit 34 1 1 0,4 1 7 22,9
JEdit 248 1,4 29,5
PatternsBox 52 0,3 3 40,3
java.awt.* 121 0,2 1 7 82,6
JHotDraw 155 1 3 2 0,4 1 3 65,5
JUnit 34 1 1 0,2 1 7 22,9
JEdit 248 0,4 29,5
PatternsBox 52 0,3 3 40,3
java.awt.* 121 3 1,1 3 8 1 7
JHotDraw 155 2 2 1 1 0,5 2 37 1 103,7
JUnit 34 1 1 23
JEdit 248 0,1 6 29,7
PatternsBox 52 0,2 7 1 13,5
java.awt.* 121 12 75,6
JHotDraw 155 3 3 0,1 3 100 231,1
JUnit 34 8 22,7
JEdit 248 1 1 0,1 1 28,5
PatternsBox 52 79 36,5
java.awt.* 121 3,4 4 4 73,5
JHotDraw 155 2 2 3,2 2 2 2 61,4
JUnit 34 4 4 2,5 19,9
JEdit 248 3 3 13 3 27,8
PatternsBox 52 1 1 2,8 2 1 2 31,5
java.awt.* 121 3 3 0,7
JHotDraw 155 2 2 0,5
JUnit 34 0,4
JEdit 248 1
PatternsBox 52 1 1 0,5
610 30 28 2 3 1,3 18 9 262 50 50,7
Itérateur
Observateur
Singleton N/A
Composite
Décorateur
Méthode
usine
Documentation (PatternsBox)
Design
patterns
Programs NLC Existing
Understanding (Ptidej)
Hits Miss False
t
(sec.)
t
(sec.)
Complete

118. 61/64
Our contributions
n Meta-modeling
– Program architecture (PADL)
• Definitions, automated mechanisms
– Design motifs (PDL) [Albin-Amiot03, chapter 3]
• Manual mechanisms
n Application of CSP to our software
engineering problem

119. 61/64
Our contributions
n Meta-modeling
– Program architecture (PADL)
• Definitions, automated mechanisms
– Design motifs (PDL) [Albin-Amiot03, chapter 3]
• Manual mechanisms
n Application of CSP to our software
engineering problem

120. 62/64
Limitations, perspectives
n Modeling motifs
– Structural design motifs
– Behavioural? Creational?
n Resolution of CSP
– Specialized algorithms
– Automation
– Interactions
– Scaling

121. 63/64
Limitations, perspectives
n Results of the identification
– Micro-architectures
• Weaker forms of a design motif
• Not a design motif (discovery?)
– Visualisation
• Model of the architectures
• Model of the design motifs
• Identified micro-architectures
• Solved problems

122. 64/64
Perspectives
n Design defects
– Program transformation
n Specialized motifs
– Quality characteristics
n Integration in the software development
process of the tool
– Evaluation

123. 65/64
[Albin-Amiot03] Hervé Albin-Amiot ; Idiomes et patterns Java : application à la synthèse de code et à la
détection ; Thèse de doctorat de l’université de Nantes, février 2003
[Alexander77] Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King
and Shlomo Angel ; A Pattern Language ; Oxford University Press, 1977, ISBN 0-19-501919-9.
[Caseau96] Yves Caseau and François Laburthe ; Claire: Combining Objects and Rules for Problem Solving ;
Proceedings of JICSLP, workshop on Multi-Paradigm Logic Programming, pages 105–114, TU Berlin,
September 1996.
[Compagnon02] Antoine Compagnon ; La notion de genre – Introduction : forme, style et genre littéraire ;
Décembre 2002, disponible à www.fabula.org/compagnon/genre1.php.
[Gamma94] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides ; Design Patterns – Elements of
Reusable Object-Oriented Software ; Addison-Wesley, 1994, ISBN 0-201-63361-2.
[Gamma98] Erich Gamma et Thomas Eggenschwiler ; JHotDraw ; Disponible à members.pingnet
.ch/gamma/JHD-5.1.zip et sur sourceforge.net.
[Guéhéneuc01] Yann-Gaël Guéhéneuc and Hervé Albin-Amiot ; Using Design Patterns and Constraints to
Automate the Detection and Correction of Inter-Class Design Defects ; Proceedings of the 39th TOOLS
USA conference, pages 296—305, IEEE Computer Society Press, July 2001.
[Jussien00] Narendra Jussien and Vincent Barichard ; The PaLM System: Explanation-Based Constraint
Programming ; Proceedings of TRICS, pages 118–133, National University of Singapore, September, 2000.
[Jussien01] Narendra Jussien ; Programmation par contraintes avec explications ; actes des 7e JNPC, pages
147–158, ONERA, juin 2001.
[Laburthe00] François Laburthe et le projet OCRE ; Choco : implémentation du noyau d'un système de
contraintes ; actes des 6e JNPC, pages 151–165, ONERA, juin 2000.
[Montanari74] Ugo Montanari ; Networks of constraints fundamental properties and applications to picture
processing ; Information Science, volume 7, number 2, pages 95–132, Elsevier Science, 1974.
[Petit02] Thierry Petit ; Modélisation et Algorithmes de Résolution de Problèmes Sur-Contraints ; Thèse de
doctorat de l’université du Languedoc, novembre 2002.
[OTI-IBM01] Object Technology International, Inc. / IBM ; Éclipse – Un plate-forme d’outillage universelle ;
Disponible à www.eclipse.org.
[Tsang93] Edward Tsang ; Foundations of Constraint Satisfaction ; Academic Press, 1993, ISBN 0-127-01610-4.

124. 66/64
Software development process
n Incremental / piecemeal growth
n Maintenance
– Retro-conception
– Re-conception
n Documentation

125. 67/64
e-CP
n Applications
– Assistance in case of contradiction
– Algorithms de interactive resolution
– New resolution algorithms
• Path-repair [Jussien02]
• Mac-DBT [Jussien00]
[Jussien02] Narendra Jussien and Olivier Lhomme ; Local search with constraint propagation and conflict-based
heuristics ; Journal of Artificial Intelligence, volume 139, number 1, pages 21–45, Elsevier Science,
July 2002.
[Jussien00] Narendra Jussien, Romuald Debruyne, and Patrice Boizumault ; Maintaining Arc-Consistency within
Dynamic Backtracking ; Proceedings of CP, pages 249–261, Springer-Verlag, September 2000.

126. 68/64
Some related work
n Modeling
– First-order logic [Eden00]
– Fragment-based model [Florijn97]
n Application
– Generating scripts [Budinsky96]
– Meta-logic programming [Eden97]
n Identification
– Logic programming (DMP J) [Wuyts98]
– Filters (metrics) [Antoniol98]

127. 69/64
Some related work
[Antoniol98] Giuliano Antoniol, Roberto Fiutem, and L. Cristoforetti ; Design Pattern Recovery in Object-Oriented
Software ; Proceedings of the 6th workshop on Program Comprehension, pages 153–160, IEEE Computer
Society Press, June 1998.
[Budinsky96] Frank J. Budinsky, Marilyn A. Finnie, John M. Vlissides, and Patsy S. Yu ; Automatic Code
Generation from Design Patterns ; IBM Systems Journal 35 (2), pages 151–171, February 1996.
[Eden97] Amnon H. Eden, Amiram Yehudai, and Joseph (Yossi) Gil ; Precise Specification and Automatic
Application of Design Patterns ; Proceedings of the 12th ASE conference, pages 143–152, IEEE Computer
Society Press, November 1997.
[Eden00] Amnon H. Eden ; Precise Specification of Design Patterns and Tool Support in their Application ; Ph.D.
thesis, Tel Aviv University, 2000.
[Florijn97] Gert Florijn, Marco Meijers, and Pieter Van Winsen ; Tool Support for Object-Oriented Patterns ;
Proceedings of the 11th ECOOP conference, Springer-Verlag, June 1997.
[Wuyts98] Roel Wuyts ; Declarative Reasoning About the Structure of Object-Oriented Systems ; Proceedings of
the 26th TOOLS USA conference, pages 112–124, IEEE Computer Society Press, August 1998.