010821_Presentation_OTI.ppt.pdf

Transcript

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 Constraints Basic 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. Interaction Basic 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. Detection Basic 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/)