Yann-Gaël Guéhéneuc, profile picture
Uploaded byYann-Gaël Guéhéneuc
50 views

010821+presentation+oti.ppt

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.

Embed presentation

Download to read offline
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 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 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 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 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 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 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 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 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 Π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 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 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 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 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 • 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 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 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 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 Ž 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 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 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 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 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 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 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 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 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 Application n PatternsBox is a tool to instantiate design patterns from a repository of patterns Basic A Example:
29 Application n From the pattern, we access the pattern description Basic A Example:
30 Application n We adapt actors and roles to the current context Basic A Example:
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 Detection n Ptidej detects instances of an abstract model Basic A Example:
33 Detection n It generates a CSP from the design Basic A Example:
34 DetectionBasic A Example: n The PaLM e-Constraint solver
35 Detection n It highlights design patterns Basic A Example:
36 Detection n It shows the differences Basic A Example:
37 Correction n It applies the source transformations Basic A Example:
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 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 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/)

More Related Content

PPT
Design Pattern
bywiradikusuma
 
PPT
Design patterns ppt
byAman Jain
 
PDF
Module 2 design patterns-2
byAnkit Dubey
 
PDF
Introduction to Design Pattern
bySanae BEKKAR
 
PPT
Introduction to design patterns
byAmit Kabra
 
PPTX
Design Pattern in Software Engineering
byManish Kumar
 
PDF
Design patterns tutorials
byUniversity of Technology
 
PPTX
Design pattern - Software Engineering
byNadimozzaman Pappo
 
Design Pattern
bywiradikusuma
 
Design patterns ppt
byAman Jain
 
Module 2 design patterns-2
byAnkit Dubey
 
Introduction to Design Pattern
bySanae BEKKAR
 
Introduction to design patterns
byAmit Kabra
 
Design Pattern in Software Engineering
byManish Kumar
 
Design patterns tutorials
byUniversity of Technology
 
Design pattern - Software Engineering
byNadimozzaman Pappo
 

What's hot

PPTX
Design Patterns - General Introduction
byAsma CHERIF
 
PDF
Basic design pattern interview questions
byjinaldesailive
 
PPTX
Behavioral pattern By:-Priyanka Pradhan
byPriyanka Pradhan
 
PPTX
Modeling and meta-modeling presentation at LTH, Sweden
bySaïd Assar
 
PPTX
Cs 1023 lec 9 design pattern (week 2)
bystanbridge
 
PPTX
Let us understand design pattern
byMindfire Solutions
 
PPTX
Design pattern
byJasdhir Singh
 
PDF
Meta-modeling: concepts, tools and applications
bySaïd Assar
 
PPTX
How I Learned To Apply Design Patterns
byAndy Maleh
 
PPTX
Bridging the gap between AI and UI - DSI Vienna - full version
byLiad Magen
 
PDF
The I in PRIMM - Code Comprehension and Questioning
bySue Sentance
 
PPTX
Applying design patterns
byYogeshwaranT
 
PPTX
MetaScience: Holistic Approach for Research Modeling and Analysis
byJordi Cabot
 
PPT
Design Patterns
byppd1961
 
PDF
Gof design pattern
bynaveen kumar
 
PDF
Analysing the concept of quality in model-driven engineering literature: a sy...
byFáber D. Giraldo
 
PPTX
NLP Project Presentation
byAryak Sengupta
 
PPTX
Creational Patterns
byAsma CHERIF
 
PPT
Design Patterns (Examples in .NET)
byAniruddha Chakrabarti
 
PDF
Partial Models: Towards Modeling and Reasoning with Uncertainty
byMichalis Famelis
 
Design Patterns - General Introduction
byAsma CHERIF
 
Basic design pattern interview questions
byjinaldesailive
 
Behavioral pattern By:-Priyanka Pradhan
byPriyanka Pradhan
 
Modeling and meta-modeling presentation at LTH, Sweden
bySaïd Assar
 
Cs 1023 lec 9 design pattern (week 2)
bystanbridge
 
Let us understand design pattern
byMindfire Solutions
 
Design pattern
byJasdhir Singh
 
Meta-modeling: concepts, tools and applications
bySaïd Assar
 
How I Learned To Apply Design Patterns
byAndy Maleh
 
Bridging the gap between AI and UI - DSI Vienna - full version
byLiad Magen
 
The I in PRIMM - Code Comprehension and Questioning
bySue Sentance
 
Applying design patterns
byYogeshwaranT
 
MetaScience: Holistic Approach for Research Modeling and Analysis
byJordi Cabot
 
Design Patterns
byppd1961
 
Gof design pattern
bynaveen kumar
 
Analysing the concept of quality in model-driven engineering literature: a sy...
byFáber D. Giraldo
 
NLP Project Presentation
byAryak Sengupta
 
Creational Patterns
byAsma CHERIF
 
Design Patterns (Examples in .NET)
byAniruddha Chakrabarti
 
Partial Models: Towards Modeling and Reasoning with Uncertainty
byMichalis Famelis
 

Similar to 010821+presentation+oti.ppt

PDF
Generation of Automatic Code using Design Patterns
byIRJET Journal
 
PPT
Chapter 4_Introduction to Patterns.ppt
byRushikeshChikane1
 
PPT
Chapter 4_Introduction to Patterns.ppt
byRushikeshChikane2
 
PDF
(E book pdf) thinking in patterns with java
byRaffaella D'angelo
 
PDF
TOOLS USA01.ppt
byPtidej Team
 
PPTX
Final sdp ppt
bynancy_17
 
PDF
Patterns Overview
byFáber D. Giraldo
 
DOCX
Design Pattern Notes: Nagpur University
byShubham Narkhede
 
PDF
Toolsusa01.ppt
byYann-Gaël Guéhéneuc
 
PPT
Unit4
byanuragmbst
 
PDF
ECOOP01 AOOSDM.ppt
byPtidej Team
 
PDF
Ase01.ppt
byYann-Gaël Guéhéneuc
 
PPTX
Lecture-7.pptx software design and Arthitechure
byMuhammadAbubakar114879
 
PPT
Design pattern & categories
byHimanshu
 
DOCX
Unit iii design patterns 9
bykiruthikamurugesan2628
 
PPT
designpatterns structural,functional,behavioral..ppt
byflutterlyuser
 
PPT
CS6201 Software Reuse - Design Patterns
byKwangshin Oh
 
PPTX
Design patterns Structural
byUMAR ALI
 
PPTX
Design Pattern Slide 01bbbbbbbbbbbbbbbbbbbbbbb.pptx
bynrezaeeof
 
PPTX
Design patterns software re engineering lect 10
byHibaAmjadSiddiqui
 
Generation of Automatic Code using Design Patterns
byIRJET Journal
 
Chapter 4_Introduction to Patterns.ppt
byRushikeshChikane1
 
Chapter 4_Introduction to Patterns.ppt
byRushikeshChikane2
 
(E book pdf) thinking in patterns with java
byRaffaella D'angelo
 
TOOLS USA01.ppt
byPtidej Team
 
Final sdp ppt
bynancy_17
 
Patterns Overview
byFáber D. Giraldo
 
Design Pattern Notes: Nagpur University
byShubham Narkhede
 
Toolsusa01.ppt
byYann-Gaël Guéhéneuc
 
Unit4
byanuragmbst
 
ECOOP01 AOOSDM.ppt
byPtidej Team
 
Ase01.ppt
byYann-Gaël Guéhéneuc
 
Lecture-7.pptx software design and Arthitechure
byMuhammadAbubakar114879
 
Design pattern & categories
byHimanshu
 
Unit iii design patterns 9
bykiruthikamurugesan2628
 
designpatterns structural,functional,behavioral..ppt
byflutterlyuser
 
CS6201 Software Reuse - Design Patterns
byKwangshin Oh
 
Design patterns Structural
byUMAR ALI
 
Design Pattern Slide 01bbbbbbbbbbbbbbbbbbbbbbb.pptx
bynrezaeeof
 
Design patterns software re engineering lect 10
byHibaAmjadSiddiqui
 

More from Yann-Gaël Guéhéneuc

PDF
Empirical Studies on Software Quality v1.2
byYann-Gaël Guéhéneuc
 
PDF
Evolution and Examples of Java Features, from Java 1.7 to Java 25
byYann-Gaël Guéhéneuc
 
PDF
WASM or Realising the Dream of Write Once, Run Anywhere?
byYann-Gaël Guéhéneuc
 
PDF
Rights, Copyrights, and Licences for Software Engineering Research v1.0
byYann-Gaël Guéhéneuc
 
PDF
Evolution and Examples of Java Features, from Java 1.7 to Java 24
byYann-Gaël Guéhéneuc
 
PDF
Projects Panama, Valhalla, and Babylon: Java is the New Python v0.9
byYann-Gaël Guéhéneuc
 
PDF
Consequences and Principles of Software Quality v1.0
byYann-Gaël Guéhéneuc
 
PDF
About Empirical Studies on Software Quality
byYann-Gaël Guéhéneuc
 
PDF
A (Very) Brief History of Ethics for Software Engineering Research
byYann-Gaël Guéhéneuc
 
PDF
Project Manifold (Forwarding and Delegation)
byYann-Gaël Guéhéneuc
 
PDF
Reviewing Processes and Tools, Publishers, Open Access
byYann-Gaël Guéhéneuc
 
PDF
Custom Annotations in Java with Project Lombok
byYann-Gaël Guéhéneuc
 
PDF
Some Pitfalls with Python and Their Possible Solutions v1.0
byYann-Gaël Guéhéneuc
 
PDF
Advice for writing a NSERC Discovery grant application v0.5
byYann-Gaël Guéhéneuc
 
PDF
Ptidej Architecture, Design, and Implementation in Action v2.1
byYann-Gaël Guéhéneuc
 
PDF
Evolution and Examples of Java Features, from Java 1.7 to Java 22
byYann-Gaël Guéhéneuc
 
PDF
Consequences and Principles of Software Quality v0.3
byYann-Gaël Guéhéneuc
 
PDF
Some Pitfalls with Python and Their Possible Solutions v0.9
byYann-Gaël Guéhéneuc
 
PDF
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
byYann-Gaël Guéhéneuc
 
PDF
An Explanation of the Halting Problem and Its Consequences
byYann-Gaël Guéhéneuc
 
Empirical Studies on Software Quality v1.2
byYann-Gaël Guéhéneuc
 
Evolution and Examples of Java Features, from Java 1.7 to Java 25
byYann-Gaël Guéhéneuc
 
WASM or Realising the Dream of Write Once, Run Anywhere?
byYann-Gaël Guéhéneuc
 
Rights, Copyrights, and Licences for Software Engineering Research v1.0
byYann-Gaël Guéhéneuc
 
Evolution and Examples of Java Features, from Java 1.7 to Java 24
byYann-Gaël Guéhéneuc
 
Projects Panama, Valhalla, and Babylon: Java is the New Python v0.9
byYann-Gaël Guéhéneuc
 
Consequences and Principles of Software Quality v1.0
byYann-Gaël Guéhéneuc
 
About Empirical Studies on Software Quality
byYann-Gaël Guéhéneuc
 
A (Very) Brief History of Ethics for Software Engineering Research
byYann-Gaël Guéhéneuc
 
Project Manifold (Forwarding and Delegation)
byYann-Gaël Guéhéneuc
 
Reviewing Processes and Tools, Publishers, Open Access
byYann-Gaël Guéhéneuc
 
Custom Annotations in Java with Project Lombok
byYann-Gaël Guéhéneuc
 
Some Pitfalls with Python and Their Possible Solutions v1.0
byYann-Gaël Guéhéneuc
 
Advice for writing a NSERC Discovery grant application v0.5
byYann-Gaël Guéhéneuc
 
Ptidej Architecture, Design, and Implementation in Action v2.1
byYann-Gaël Guéhéneuc
 
Evolution and Examples of Java Features, from Java 1.7 to Java 22
byYann-Gaël Guéhéneuc
 
Consequences and Principles of Software Quality v0.3
byYann-Gaël Guéhéneuc
 
Some Pitfalls with Python and Their Possible Solutions v0.9
byYann-Gaël Guéhéneuc
 
An Explanation of the Unicode, the Text Encoding Standard, Its Usages and Imp...
byYann-Gaël Guéhéneuc
 
An Explanation of the Halting Problem and Its Consequences
byYann-Gaël Guéhéneuc
 

Recently uploaded

PPTX
‘Analyzing Application Logs Using AI’ Webinar
byTier1 app
 
PDF
openstack_operations_slides_version1.3_pp.pdf
byssuser47d511
 
PDF
Complete iOS Delivery App Features & Admin Tools
byShiv Technolabs Pvt. Ltd.
 
PDF
On Demand Massage Therapist Booking App Development
byV3CUBE TECHNOLABS
 
PPTX
Best Digital Marketing Company in Lucknow
bydigitallearning9277
 
PDF
Clean Architecture with Vertical Slice Architecture in .NET 8
byVineet Sharma
 
PDF
Jira, Powered by Enterprise-Grade Intelligence from NeoroTalks.pdf
byNeoro Talks
 
PDF
SAP ERP to SAP S_4HANA Cloud Private Edition Delta Scope
bychuck78
 
PDF
Versnel innovatie met GitHub Enterprise - Rick Smit GitHub
byDelta-N
 
PDF
Lost Android Phone Recovery_ Steps That Work Fast.pdf
byIsabella Reed
 
PPTX
Prime Teams – Real-Time Employee Monitoring & Project Management Software
byPrime Teams
 
PDF
Ready, Set, REST! Introducing MySQL's Built-In REST Service
byMiguel Araújo
 
PDF
Prompt Engineering vs Content Engineering vs RAG.pdf
byVineet Sharma
 
PDF
Mastering Zero-Allocation Parsers: A Deep Dive into High-Performance C#
byVineet Sharma
 
PPTX
Installing Python in Visual Studio Code
bydabydcatahanibmcom
 
PDF
Introduction to Modern Artificial Intelligence.pdf
byAI n Dot Net
 
PDF
Routing Guidelines: Unlocking Smarter Query Routing in MySQL Architectures
byMiguel Araújo
 
PDF
eresource Xcel ERP for Maunfacturing - Best Manufacturing ERP for SME
byeresource Infotech Pvt.Ltd
 
PPTX
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
PPTX
Connecting to MCP Servers in OutSystems Platform
byOzanCali
 
‘Analyzing Application Logs Using AI’ Webinar
byTier1 app
 
openstack_operations_slides_version1.3_pp.pdf
byssuser47d511
 
Complete iOS Delivery App Features & Admin Tools
byShiv Technolabs Pvt. Ltd.
 
On Demand Massage Therapist Booking App Development
byV3CUBE TECHNOLABS
 
Best Digital Marketing Company in Lucknow
bydigitallearning9277
 
Clean Architecture with Vertical Slice Architecture in .NET 8
byVineet Sharma
 
Jira, Powered by Enterprise-Grade Intelligence from NeoroTalks.pdf
byNeoro Talks
 
SAP ERP to SAP S_4HANA Cloud Private Edition Delta Scope
bychuck78
 
Versnel innovatie met GitHub Enterprise - Rick Smit GitHub
byDelta-N
 
Lost Android Phone Recovery_ Steps That Work Fast.pdf
byIsabella Reed
 
Prime Teams – Real-Time Employee Monitoring & Project Management Software
byPrime Teams
 
Ready, Set, REST! Introducing MySQL's Built-In REST Service
byMiguel Araújo
 
Prompt Engineering vs Content Engineering vs RAG.pdf
byVineet Sharma
 
Mastering Zero-Allocation Parsers: A Deep Dive into High-Performance C#
byVineet Sharma
 
Installing Python in Visual Studio Code
bydabydcatahanibmcom
 
Introduction to Modern Artificial Intelligence.pdf
byAI n Dot Net
 
Routing Guidelines: Unlocking Smarter Query Routing in MySQL Architectures
byMiguel Araújo
 
eresource Xcel ERP for Maunfacturing - Best Manufacturing ERP for SME
byeresource Infotech Pvt.Ltd
 
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
Connecting to MCP Servers in OutSystems Platform
byOzanCali
 

010821+presentation+oti.ppt

  • 1.
    1 Design Patterns: ARound-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 Softwarequality – 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 nTo 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 designdefects 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 designdefects 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 nDesign 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 nWe 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 needa 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 wayto 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 [Gammaet 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 Eachconstituent 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 patternabstract 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 needa 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 tothe 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 ofthe 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 needa 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 proximalversions 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 ofconstraints 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 Thedesign 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-Constraintsenables – 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 Compositedesign 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 isa tool to instantiate design patterns from a repository of patterns Basic A Example:
  • 29.
    29 Application n From thepattern, we access the pattern description Basic A Example:
  • 30.
    30 Application n We adaptactors and roles to the current context Basic A Example:
  • 31.
    31 Application n The toolgenerates 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 detectsinstances of an abstract model Basic A Example:
  • 33.
    33 Detection n It generatesa CSP from the design Basic A Example:
  • 34.
  • 35.
    35 Detection n It highlightsdesign patterns Basic A Example:
  • 36.
    36 Detection n It showsthe differences Basic A Example:
  • 37.
    37 Correction n It appliesthe source transformations Basic A Example:
  • 38.
    38 Back to thefuture 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, abstractmodels – [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/)