1 / 26

Design Pattern Detection

Explore the world of design patterns and understand their importance in software engineering. Learn about the benefits, drawbacks, and how to effectively implement these patterns in your projects.

nbreece
Télécharger la présentation

Design Pattern Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Pattern Detection

  2. Design Patterns • A design pattern systematically names, explains and evaluates an important and recurring design problem and its solution • Good designers know not to solve every problem from first principles • They reuse solutions • This is very different from code reuse COSC6431

  3. Design Patterns – 2 • Definition • “We propose design patterns as a new mechanism for expressing object oriented design experience. Design patterns identify, name and abstract common themes in object oriented design. They capture the intent behind a design by identifying objects, collaborations and distribution of responsibilities.” • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ,“Design Patterns”, Addison-Wesley, 1995. ISBN 0-201-63361-2 COSC6431

  4. Others On Design Patterns • Christopher Alexander • “Each person describes a problem which occurs over and over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” • Cunningham • “Patterns are the recurring solutions to the problem of design. People learn patterns by seeing them and recall them when need be without a lot of effort” COSC6431

  5. Others On Design Patterns – 2 • Booch • “A pattern is a solution to a problem in a specific context. A pattern codifies specific knowledge collected from experience in a domain.” COSC6431

  6. Design Problems • Finding appropriate classes • Determine class granularity • Specify interfaces • Specify implementation • Put reuse to work • Client-supplier vs inheritance • Design for change COSC6431

  7. Common problems • Explicit object creation • Dependence on particular operations • Dependencies on hardware or software platforms • Dependencies on object representation • Dependencies on algorithms • Tight coupling COSC6431

  8. Claims of the Pattern Community • Well defined design principles have a positive impact on software engineering • Achievable reusability • Provide common vocabulary for designers • communicate, document, explore alternatives • Patterns are like micro architectures • Useful for building small parts of a system • Reduce the learning time for understanding class libraries • Avoid redesign stages by using encapsulated experience COSC6431

  9. When to Use Patterns • Solutions to problems that recur with variations • No need for pattern if the problem occurs in only one context • Solutions that require several steps • Not all problems need all steps • Patterns can be overkill if solution is a simple linear set of interactions • Solutions where the solver is more interested in “does there exist a solution?” than in a solution’s complete derivation • Patterns often leave out lots of detail COSC6431

  10. Pattern Benefits • Enable large scale reuse of software architectures • Explicitly capture expert knowledge and design trade-offs • Help improve developer communication • Help ease the transition to OO methods COSC6431

  11. Pattern Drawbacks • Patterns do not lead to direct code reuse • Patterns are often deceptively simple • You may suffer from pattern overload • Patterns must be validated by experience and debate rather than automated testing • Integrating patterns into a process is human intensive rather than a technical activity COSC6431

  12. General Template • Name • Intent • What does the pattern do? What problems does it address? • Motivation • A scenario of pattern applicability • Applicability • In which situations can this pattern be applied • Participants • Describe participating classes/objects COSC6431

  13. General Template – 2 • Collaborations • How do the participants carry out their responsibilities? • Diagram • Graphical representation of the pattern • Consequences • How does the pattern support its objectives? • Implementation • Pitfalls, language specific issues • Examples COSC6431

  14. Classification • Structural • Deal with decoupling interface and implementation of classes and objects • Behavioural • Deal with dynamic interaction among collections of classes and objects • Creational • Deal with initializing and configuring collections of classes and objects COSC6431

  15. Detecting design patterns • A difficult task • Patterns are primarily a literary form • No rigorous mathematical definitions • Automatic detection beyond the state of the art of Artificial Intelligence • Instead, detect the artifacts of implementing the solution of the design pattern COSC6431

  16. Detecting design patterns • Purely structural patterns are easier to detect • Purely behavioural patterns are much harder • Most patterns are somewhere in the middle COSC6431

  17. Template solution • A template solution needs to be both: • Distinctive • The static structure is not likely to be represented in a design that does not use the pattern • Unambiguous • Can only be done in one way (or in a small number of variants) • An object adapter is unambiguous but not distinctive COSC6431

  18. Adapter – Example • EDITOR expects a SHAPE • TEXT_VIEW is not a SHAPE • TEXT is a SHAPE • Features are mapped (body calls relevant method) to TEXT_VIEW SHAPE EDITOR FIGURE TEXT TEXT_VIEW COSC6431

  19. Analysis synergy • Both static and dynamic analysis are necessary in order to detect patterns • Static analysis • The static structure of the pattern has to match a subgraph of the static structure of the software system • Dynamic analysis • Message passing during run-time has to match the message flow that implements the behaviour of the pattern COSC6431

  20. An exampleComposite vs. Decorator • A Decorator is sometimes referred to as a degenerate Composite. • The static structure of the two patterns is very similar • The dynamic behaviour is also the same • The difference is in the intent. The Composite pattern groups components into a whole. The Decorator patterns enhances the responsibility of a component. COSC6431

  21. Kramer – Prechelt 96 • Patterns detected: Structural (Adapter, Bridge, Composite, Decorator, Proxy) • Each pattern expressed as a set of Prolog rules • No dynamic information used • Reported precision: 40% COSC6431

  22. Antoniol et al. 98 • Same patterns detected • No handling of polymorphism • Metrics were employed to help reduce false positives • Precision: 14 – 50% COSC6431

  23. SPOOL • A Bell Canada / University of Montreal project • Patterns detected: Template Method, Factory Method, Bridge • Design information stored in an OODBMS • Querying the database was able to recover many instances of patterns from three large C++ systems COSC6431

  24. Niere et al. 01 • Semi-automatic approach • Programs described in the form of Abstract Syntax Graphs • Patterns described as graph transformations • Limitation: Each variant has to be described as a separate transformation COSC6431

  25. IDEA • Detects patterns in UML diagrams • May suggest improvements on the application of the pattern (better naming, export status for features etc). • Many patterns cannot be accurately detected from diagrams COSC6431

  26. Heuzeroth et al. • We covered this one already… COSC6431

More Related