The document summarizes a presentation about applying and detecting design patterns. It discusses the need for a common description of design patterns to enable both application and detection. It presents a meta-model for describing design patterns and tools developed for applying patterns to source code using JavaXL and detecting patterns using explanation-based constraint programming (e-Constraints). The goal is to enable a "round-trip" process of seamlessly applying and detecting design patterns.

1. 1
Design Patterns: A Round-trip
A trip in the marvellous
country of design pattern
application and detection
Good afternoon Ladies and Gentlemen.
The topic is about design patterns: How to apply them, and how to detect
them.
(This handout is an improved version of the talk given at OTI, on Tuesday,
August 21st, 2001. It corrects some minor defects in the talk and in the
comments. A re-factored and much improved version will be available later,
based on the comments received after the presentation and a discussion with
Kevin McGuire.)

2. 2
n Hervé Albin-Amiot
– 3rd year PhD student
– Partly funded by Soft-Maint, S.A. (France)
n Yann-Gaël Guéhéneuc
– 2nd year PhD student
– Partly funded by Object Technology
International, Inc. (Canada)
n Pr. Pierre Cointe
– Supervisor
n Dr. Narendra Jussien
– Assistant-professor Constraints Team
My name is Yann… As most of you already know ;-)
I served several co-op terms at OTI.
I am now a PhD student at the École des Mines de Nantes.
I work with Pr. Pierre Cointe, Dr. Narendra Jussien and another PhD
student, Hervé Albin-Amiot.
Our common interest is software engineering, and the improvement of
software quality.
In this presentation, I will first summarize the reasons why we talk about
design patterns.
Then, I will present the current state of our research.

3. 3
One observation
n Software quality
– ISO/IEC 9126
• Functionality, reliability, usability, efficiency,
maintainability, portability
– ISO/IEC 14598
– Coupling, cohesion, method replacement…
n Maintenance = 75%
n Design defects
Here is one observation.
Quality is very important.
And quality is a challenge for software developers.
But quality is very subjective, even if some authors propose kind of
“objective” tools, such as metrics, there is no consensus on what a good
design is, it’s too context-dependent.
As a proof, just look at the many standards for software quality and the
many independent quality characteristics.
The ISO 9126 standard is a standard that divides software quality in six
characteristics.
And so on…
So now, what is the reason to be concerned by software quality?
If you take maintenance, for instance, maintenance is (at least) 75% of the
life-cycle of a software.
It takes lots of time, of effort, and of people.
It cost billions of dollars each year.
How to decrease maintenance time? We must improve software quality!
How to improve software quality? We must look for design defects!

4. 4
One classification
n Intra-class / Inter-class / Behavioural
Number: 39/61 (64%)
Detection–correction: 25%
Number: 13/61 (21%)
Detection–correction: 8%
In OO programming languages, we define three categories of design
defects:
•Intra-class design defects are related to the internal structure of the classes.
For example, unused fields.
•Inter-class design defects are related to the external structure of the classes,
to their public interfaces. For example, a “middle-man” is a class with too
many delegating methods.
•Behavioural design defects are related to the semantics of the classes. For
example, the Y2K bug.
We made a survey of the literature on design defects.
We found that:
•Intra-class design defects, studied a lot, well-known.
•Inter-class design defects, studied a little bit, rely on “feelings”, “bad
smells”, “heuristics”, …

5. 5
One long-term plan
n To identify inter-class design defects
– Classification
– Automated detection mechanisms
+
n To correct inter-class design defects
– Solutions
– Automated correction mechanisms
Those are the reasons why our long-term plan is to help in identifying
and correcting inter-class design defects.
From our classification of design defects, we would like:
•To propose a methodology and the tools to automate the detectionof inter-
class design defects.
•To propose solutions and the tools to automate the correction of those
defects.

6. 6
On inter-class design defects
n Design patterns are useful when:
– Designing / implementing / Re-engineering
– Documenting
n [Gamma et al. 1994]
– Quality architectural solutions
• Flexibility, understandability
– Language independent
• General Smalltalk- or C++-level
– Domain independent
Now, when we started our research, we looked around and we tried to find
related problems.
That’s how we came to ask the question: “What’s the link between design
defects and design patterns?”
Design patterns are useful
•To design.
•To implement.
•To re-engineer.
•To document.
They are good solutions to recurring architectural problems.
And they are language and context independent.
That’s true, at least, for the design patterns presented by the GoF.
Especially, in the GoF, they emphasize the idea that design patterns
improve the flexibility and understandability of the software.

7. 7
On inter-class design defects
n Design patterns, design defects = dual
problems
n Working hypotheses
– Groups of entities similar to a design
pattern = Inter-class design defects
+
– Making these groups of entities closer to a
design pattern = Improving architectural
quality (flexibility and understandability)
Then, because design patterns affect the software quality, we can assume
that there is a connection between design patterns and architectural
quality. More precisely, that design patterns and design defects are dual
problems.
From this observation, we propose two working hypotheses:
•We make the hypothesis that groups of entities that look like a design
pattern, but not quite, represent a design defect.
•We make the hypothesis that transforming these groups of entities (such
that they look more closely like a design pattern) actually improves the
overall architectural quality.
Those are working hypotheses, you may disagree with them, and I will
be glad to discuss them with you. But, we use them as a starting point and
we may confirm or refute them later on.

8. 8
Our short-term goals
n Design patterns are difficult to use
– Lack of formalism
– Lack of automation
n We want to provide
round-trip using
design patterns
From software quality, we went to design defects.
From design defects, we went to design patterns.
So, what do we want, now?
We want:
•To help designers.
•To help maintainers.
In using design patterns.
(We do not want to replace them.)
We propose the notion of design patterns round-trip.
Round-trip is the seamless application and detection of design patterns
(of design pattern solution micro-architectures).

9. 9
Our short-term goals
n We need
– A common description for design patterns
• Application viewpoint
• Detection viewpoint
– A way to apply physically design patterns
– A way to detect physically design patterns
Œ
•
Ž
To offer design pattern round-trip, we need:
•A common description for design patterns, specifically tailored towards
application and detection. Several authors already proposed formalisms for
design patterns, but none designed with round-trip in mind.
•A way to apply a design pattern. That is, we need a way to modify or to
generate source code.
•A way to detect a design pattern. That is, we need a way to retrieve in
random source code the design patterns present.
In the rest of this presentation, I will focus on those three points one after
the other. If I have time left, I will present two tools we developed to apply
and to detect design patterns. Then, I will conclude on some future work.

10. 10
Œ
n We need a common description for
design patterns
– Application viewpoint
– Detection viewpoint
The starting point is a common description for design patterns. This
description must be specifically oriented towards application and detection.

11. 11
Meta-modelŒ
The accepted way to describe or to formalize a design pattern is using a
meta-model. Several meta-models exist for design patterns, the one we
developed is different in that it comprises all the entities, elements, and
mechanisms needed to define, to apply, and to detect a design pattern.
A design pattern is defined as a subclass of class Pattern, for instance, the
Composite design pattern.
A design pattern is defined using the entities and elements offered by the
meta-model (new entities and new elements may be added).
A design pattern is defined as a first-class entity in our system, we can
manipulate it as we would manipulate a class and its instances (through
message sends).

12. 12
Informal descriptions
from [Gamma et al.]
Instance of class PDelegation
Instance of class PInterface
Instance of class PClass
Instance of class PAssoc
name() Instance of class PMethod
Instance of class Pattern
Pattern, PInterface, PClass, PAssoc,
PDelegation, and PMethod are
classes defined in our meta-model
Translates into
Abstract model of CompositeŒ
Let’s take an example.
From the description and the OMT diagram proposed by the GoF for the
Composite pattern.
We extract all the needed information and we formalize the design pattern
using our meta-model.
Here you can see the Composite pattern abstract model, where each entities
and elements are instances of constituents of our meta-model.
We call this an abstract model because it represents the design pattern
solution, independently of any context, specific cardinality, and so on.

13. 13
Abstract model
n Each constituent of the meta-model
deliver its associated code
– New language are added using an
instance of the Visitor design pattern
– Modifications of an existing source code is
(only) provided for Java using JavaXL
n Each constituent of the meta-model
detect its associated instances
Œ
An abstract model is a first-class entity in our system.
It know how to generate the source code associated with itself.
It know how to detect its own instances in source code.

14. 14
Abstract model
Composite pattern abstract model
Composite pattern concrete model 1 Composite pattern concrete model n
PatternsBox •
• •
Composite pattern concrete model 1
(source code)
Composite pattern concrete model n
(source code)
•• ‚‚
Ptidej ‚
‚ ‚
Œ
To understand fully what is an abstract model, consider the following
example.
We developed two tools, I will present these tools more in details later (if
we have some time left ;-).
From the Composite design pattern abstract model, PatternsBox allows us
“to concretize” this abstract model. This means that we can specify role
names, cardinalities... This is basically like a parameterization of the
abstract model. The results are, for instance, two concrete models:
•One representing a dummy example (on the left).
•One representing a sub-set of the Java AWT hierarchy (on the right).
From these concrete models, we can generate the corresponding source
code.
Now, we have this second tool, Ptidej, which from the source code (any
source code), builds back concrete models of a given design pattern
abstract model.

15. 15
•
n We need a way to apply physically
design patterns
– At the source code level
– With as few modifications as possible
The second point deals with the application of a design pattern in a given
source code.
Because we want to help the developers and the maintainers to use
design patterns, we must apply design patterns at the source code level
(level where the developers and maintainers work) while modifying the
source code as little as possible.

16. 16
JavaXL
n Extension to the Java reflection APIs
n Working at the source code level
n Modifying the user source code as little
as possible
n Modifications are reversible
•
We developed an extension of the Java reflection APIs. This extension
works at the source code level, to the contrary of already existing
extensions, such as Javassit or OpenJava.
The modifications are minimal and reversible.

17. 17
JavaXL
n High-level abstraction
– Multiple language
– No semantics
n High-level interface
– Specific Java implementation to VAJ
– Refactorings (Eclipse, Grant Gayed)
•
Basically, JavaXL defines high-level abstractions, that are language
independent and that provide no semantic checks.
JavaXL is also a high-level interface that hides implementation details.
So far, we have a Java-specific implementation, closely related to VAJ.
But we can imagine to have a version working on top of refactorings, such
as the one implemented in Eclipse or using XML and the mechanisms
proposed by Grant Gayed.

18. 18
Singleton
n Example of the Singleton pattern
for (Iterator i = aClass.getConstructors().iterator();
i.hasNext();) {
XMethod currentMethod = (XMethod) i.next();
currentMethod.setModifiers(Modifier.PRIVATE);
}
XField xf = new XField();
xf.setModifiers(Modifier.STATIC & Modifier.PRIVATE);
xf.setName("soleInstance");
…
Basic
A
Example:•
Here is a basic example of JavaXL in action.
This is an extract from the transformation needed to apply the Singleton
pattern.
In the loop, for each constructor of the class represented by aClass, we
create an instance of XMethod and we modify its modifiers.
Then, we create an instance of XField, set its modifiers to static-private,
then we name this field “soleInstance” and so on…

19. 19
Ž
n We need a way to detect physically
design patterns
– Use of a design pattern solution
• Well written code
• Notion of complete version
– Other uses of a design pattern solution
• Code improvement
• Notion of proximal version
+ No up-front descriptions of the variations
The third and last point concerns the detection of design patterns.
What is important to notice, is that design patterns are never applied “by
the rules”, there are always adapted and modified.
We need a mechanism able to detect the use of design pattern solutions is
well-written code, that is the notion of complete solutions. And a
mechanism able to detect the variations of a design pattern solutions in to-
be-improved code, that is the notion proximal solutions.

20. 20
Complete and proximal versions
n Related works
– The search of sub-graphs in a graph
– The adaptation phase in case-based
reasoning
– Logic programming
ÆExplanation-based constraint
programming (e-Constraints)
Ž
There are several related work, although none is specifically oriented
towards the detection of the complete and proximal solutions.
What is important, is that we do not want to describe a priori the
variations.
We do not want / we cannot think about all the variations beforehand.
Thus, we need:
•Explanations for why there is or not solutions.
•A way to know why a solution is a solution.
•A way to look for more solutions.
•A strong user interaction.
All these requirements led us to look at explanation-based constraint
programming, a.k.a. e-Constraints.

21. 21
e-Constraints
n Set of constraints justifying an
action performed by the solver
–Value removal
–Contradiction
n Trace of the solver behaviour
Ž
An explanation is a set of constraints that justify an action performed by the
solver (value removals, contradiction...)
Explanations are computed by tracing the behaviour of the solver.

22. 22
e-Constraints
n An implementation: PaLM
–Developed by Narendra Jussien, on
top of Choco, written in Claire
–Used for
• Path-Repair
• Mac-DBT
• Assistance upon failure
• Interactive solvers
Ž
We have an implementation of e-Constraints: the PaLM system, which uses
Choco and Claire.
The PaLM system is developed by Narendra Jussien at the École des Mines.
This system has been used (its explanations) to:
•Provide assistance upon failure (debugging tools).
•Design interactive solvers (dynamic addition and removal of
constraints).
•Design new search algorithm (guided by the explanations).
It is a reliable and efficient implementation of e-Constraints.

23. 23
Our application
n The design pattern abstract model
– A class defines a variable
– Relationships among classes define
constraints
n The source code of the application
– The classes define the domain of the
variables
– Relationships among classes give the
semantics of the constraints
Ž
In our application of e-Constraints.
We define a CSP using a design pattern abstract model and the given
source code.
From the design pattern abstract model:
•A class defines a variable
•Relationships among classes define constraints
From the source code of the application:
•The classes define the domain of the variables
•Relationships among classes give the semantics of the constraints

24. 24
Our application
n e-Constraints enables
– Complete and proximal versions
– Justifications
• Explain why / how a solution is a solution
• Explain why / how the code is modified
– Strong interactivity with the user
• Dynamic description of the variations
Ž
Programming is an artistic activity, in the sense that there are no good
designs but best designs depending on the context (expected life time, cost,
experience of the developer…).
We need the justification provided by e-Constraints to explain why and how
a solution is solution, thus why and how the code is to be modified.
A complete solution = A solution with all the constraints.
A proximal solution = A solution with some constraints removed.
The idea is to associate a reason for a constraint to be there. This reason
may be textual, but it may also contain executable code, written in terms
of JavaXL, to provide the transformations needed to correct the code.
We need to interact heavily with the developer: We cannot / do not want
to think about all the possible cases!

25. 25
n The Composite design pattern solution
n Its constraints
ConstraintsBasic
A
Example:
composite < component
leaf < component
composite ⊃ component
Ž
For example, if we take the Composite design pattern abstract model.
The constraint associated with this model are …
These constraints are automatically generated by the abstract model,
we come back to the point that we want a common description of design
pattern tailored for application and generation.
(Beware of the < symbol which is different from the object-oriented way of
thinking.)

26. 26
InteractionBasic
A
Example:
composite < component
leaf < component
composite ⊃ component
Ž
From the constraints, and given a source code, the e-Constraints PaLM
system allow us to find all the complete solutions; and, to find all the
proximal solutions (or at least, the ones we are interested in) by
removing or adding constraint dynamically.
Of course, we can potentially explore an exponential universe, but it does
not matter because the user directs the search and stops it when she judges
that it does not make sense to remove constraints further.

27. 27
n We needed
– A common description for design patterns
• Application viewpoint
• Detection viewpoint
– A way to apply physically design patterns
– A way to detect physically design patterns
Œ + • + Ž = PatternsBox + Ptidej
Basic
A
Example
Œ
•
Ž

28. 28
Application
n PatternsBox is a tool to
instantiate design
patterns from a
repository of patterns
Basic
A
Example:

29. 29
Application
n From the pattern, we
access the pattern
description
Basic
A
Example:

30. 30
Application
n We adapt actors and
roles to the current
context
Basic
A
Example:

31. 31
Application
n The tool generates the code required
for the design pattern in Java
public interface MyComponent {
public abstract void myOperation();
}
public class MyComposite implements MyComponent {
// Association: myChildren
private java.util.Vector myChildren = new java.util.Vector();
public void add (MyComponent myComponent) {
myChildren.addElement(myComponent);
}
public void remove (MyComponent myComponent) {
myChildren.removeElement(myComponent);
}
// Method linked to: myChildren
public void myOperation() {
for (Enumeration enum = myChildren.elements();
enum.hasMoreElements(); ((MyComponent)
enum.nextElement()).myOperation());
}
}
public class MyLeaf implements MyComponent {
public void myOperation() {
}
}
Basic
A
Example:

32. 32
Detection
n Ptidej detects instances
of an abstract model
Basic
A
Example:

33. 33
Detection
n It generates a CSP from the design
Basic
A
Example:

34. 34
DetectionBasic
A
Example:
n The PaLM e-Constraint solver

35. 35
Detection
n It highlights design patterns
Basic
A
Example:

36. 36
Detection
n It shows the differences
Basic
A
Example:

37. 37
Correction
n It applies the source transformations
Basic
A
Example:

38. 38
Back to the future
n Design pattern, design defects = dual
problems
– Meta-model, abstract model
– Source-to-source transformation engine
– e-Constraints
n Two tools
Œ + • + Ž = PatternsBox + Ptidej
= Round-trip
So, in this (long ;-) presentation, I talked about software quality, and how
it is related to design defects, and how those are related to design
patterns.
Then, I presented a meta-model to express design patterns. This meta-
model is tailored towards detection and application. I introduced the
concepts of abstract and concrete models.
Then, I presented JavaXL. JavaXL is an extension to the Java reflection
API. We use JavaXL to modify the source code. These modifications are as
small as possible.
And, then, I presented a new paradigm of constraint programming,
explanation-based constraint programming, a.k.a. e-Constraints. We use e-
Constraints to detect complete and proximal versions of a design pattern.
Finally, I briefly show two tools, PatternsBox and Ptidej, implementing
our ideas.

39. 39
Future
n Meta-model, abstract models
– [Gamma et al. 1994] design patterns
– Design defects
n Source-to-source transformation engine
– Refactorings
n e-Constraints
– Interaction
– Previous solutions as knowledge
First, we would like to improve the meta-model and develop design
patterns and design defects abstract models.
Second, we will enhance the source-to-source transformation engine, to
integrate it with refactorings, either to use refactorings or to develop
refactorings with it.
Finally, we will improve the interaction and the automation of the constraint
system. And we are investigating the use of previous solutions as
knowledge to help the developers in their choices.

40. 40
Future
And, of course, because the future is already there, we are integrating our
tools with Eclipse!
Ptidej, the detection tool, is already half-done.
PatternsBox, JavaXL should come out soon…
Thank you very much for your attention.
If you have any question or comment, please feel free to ask.
If you want a demo, feel free to ask!
You may also contact us at:
•cointe@emn.fr (Team leader ;-)
•jussien@emn.fr (e-Constraints, www.e-constraints.net)
•albin@emn.fr (Application, JavaXL, PatternsBox,
www.emn.fr/albin)
•guehene@emn.fr (Detection, Ptidej, Eclipse, www.yann-
gael.gueheneuc.net/Work/)