CSE3009: (Software Architecture and Design) Yann-Gal

Quality “Important assumptions – That patterns can be codified in such a way that they can be shared between different designers – That reuse will lead to “better” designs. There is an obvious question here of what constitutes “better”, but a key measure is maintainability” —Zhang and Budgen, 2012 (With minor adaptations) 37/162

Quality “Advantages: – Using patterns improves programmer productivity and program quality – Novices can increase their design skills significantly by studying and applying patterns – Patterns encourage best practices, even for experiences designers – Design patterns improve communication, both among developers and from developers to maintainers” —Zhang and Budgen, 2012 (With minor adaptations) 38/162

Outline  Definition  Quality  Form  Example  Catalogue  Practice  Conclusion 39/162

Form  Several books, articles – “Theoretical” – With examples – Among others… 40/162

Form  Several books, articles – Amazon.com • Books › Computers & Technology › Programming › Software Design, Testing & Engineering › Object- Oriented Design › "patterns" • 224 results on May 31, 2013 41/162

Form  Several books, articles – Amazon.com • Exclusion – Unreleased books – Specific to a technology or frameworks » e.g., MVVM Unleashed by Michael Brown – Process oriented, user-interface, programming languages » e.g., Process Patterns: Building Large-Scale Systems Using Object Technology by Scott W. Ambler and Barbara Hanscome – Proceedings of conferences – Unrelated to software engineering 42/162

Form Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects: Volume 2 (Wiley Software... Object-Oriented Modeling and Design with UML (2nd Edition) by Michael R. Blaha and James R Rumbaugh 1. 37. by Douglas C. Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware (Wiley 38. Pattern-Oriented Software Architecture, Patterns for Resource Management: Volume 3 (Wiley Software Patterns Software... by Markus Völter, Michael Kircher and Uwe Zdun 2. Series... by Michael Kircher and Prashant Jain Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools (Wiley Application 39. 3. Pattern-Oriented Software Architecture, A System of Patterns: Volume 1 (Wiley Software Patterns Series) by Frank Development... by Jack Greenfield, Keith Short, Steve Cook and Stuart Kent Buschmann, Regine Meunier, Hans Rohnert and Peter Sommerlad Refactoring to Patterns by Joshua Kerievsky 40. Pattern-Oriented Software Architecture For Dummies (For Dummies (Computers)) by Robert Hanmer 4. Architecting Enterprise Solutions: Patterns for High-Capability Internet-based Systems (Wiley Software Patterns... 41. Web Security Patterns by Ramesh Nagappan and Christopher Steel by Paul Dyson and Andrew Longshaw 5. 6. Safe C++ by Vladimir Kushnir 42. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML by Jim Arlow and Ila Neustadt Programming in the Large with Design Patterns by Eddie Burris 7. Data Access Patterns: Database Interactions in Object-Oriented Applications by Clifton Nock 43. Elemental Design Patterns by Jason McC. Smith 8. Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans Java Application Architecture: Modularity Patterns with Examples Using OSGi (Robert C. Martin Series) by Kirk 44. 9. Knoernschild Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems by Sherif M. Yacoub, 45. Hany H. Ammar, Sherif Yacoub and Hany Ammar Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley 10. Signature... by Gregor Hohpe and Bobby Woolf Java Extreme Programming Cookbook by Eric M. Burke and Brian M. Coyner 46. 11. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) by Martin Fowler 47. J2EE Best Practices: Java Design Patterns, Automation, and Performance (Wiley Application Development Series) by Darren Broemmer Cognitive Patterns: Problem-Solving Frameworks for Object Technology by Robert K Konitzer, Bobbin Teegarden, 12. Alexander Rush and Karen M Gardner Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems by Bruce Powel Douglass 48. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services by Robert Design Patterns Java¿ Workbook by Steven John Metsker 13. 49. Daigneau EJB Design Patterns: Advanced Patterns, Processes, and Idioms by Floyd Marinescu 50. The ACE Programmer's Guide: Practical Design Patterns for Network and Systems Programming by Stephen D. 14. Streamlined Object Modeling: Patterns, Rules, and Implementation by Jill Nicola, Mark Mayfield and Mike Abney 51. Huston, James CE Johnson and Umar Syyid 52. Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway and James Trott Patterns for Parallel Software Design (Wiley Software Patterns Series) by Jorge Luis Ortega-Arjona 15. Small Memory Software: Patterns for systems with limited memory (Software Patterns Series) by James Noble 53. 16. Design Patterns in Object-oriented ABAP by Igor Barbaric and Charles Weir Object-Oriented Reengineering Patterns by Oscar Nierstrasz, Stéphane Ducasse and Serge Demeyer 17. AntiPatterns in Project Management by William J. Brown, Hays W. "Skip" McCormick III and Scott W. Thomas 54. Dependency Injection by Dhanji R. Prasanna 18. Pattern Languages of Program Design 4 (Software Patterns Series) by Brian Foote, Neil Harrison and Hans 55. Object-Oriented Software Engineering Using UML, Patterns, and Java (3rd Edition) by Bernd Bruegge and Allen H. Rohnert 19. Dutoit Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert V. Binder 56. J2EE Design Patterns by William Crawford and Jonathan Kaplan 20. 57. Design Patterns and Contracts by Jean-Marc Jezequel, Michel Train and Christine Mingins 21. Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design and Iterative Development by Object-Oriented Software Development Using Java: Principles, Patterns, and Frameworks (1/e) by Xiaoping Jia 58. Craig Larman Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant and William Opdyke 59. Object-oriented Analysis and Design Using Umlan Introduction to Unified Process and Design Patterns by Mahesh P. 22. More Process Patterns: Delivering Large-Scale Systems Using Object Technology (SIGS: Managing Object 60. Matha Technology... by Scott W. Ambler C++ Design Patterns and Derivatives Pricing (Mathematics, Finance and Risk) by M. S. Joshi 23. Pattern Hatching: Design Patterns Applied by John Vlissides 61. Effective Java (2nd Edition) by Joshua Bloch 24. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown, Raphael C. Malveau, 62. Patterns for Fault Tolerant Software (Wiley Software Patterns Series) by Robert Hanmer 25. Hays W. "Skip" McCormick and Thomas J. Mowbray 26. Implementation Patterns by Kent Beck A Little Java, A Few Patterns (Language, Speech, & Communication) by Matthias Felleisen, Daniel P. Friedman 63. Patterns for Computer-Mediated Interaction (Wiley Software Patterns Series) by Till Schummer and Stephan Lukosch and Ralph E. Johnson 27. Pattern Oriented Software Architecture Volume 5: On Patterns and Pattern Languages by Frank Buschmann, Kevlin Pattern Languages of Program Design 3 (v. 3) by Robert C. Martin, Dirk Riehle and Frank Buschmann 28. 64. Henney and Douglas C. Schmidt Object Models: Strategies, Patterns, and Applications (2nd Edition) by Peter Coad, David North and Mark Mayfield 65. 29. Object-Oriented Analysis and Design with Applications (3rd Edition) by Grady Booch, Robert A. Maksimchuk, Michael Analysis Patterns: Reusable Object Models by Martin Fowler 66. W. Engle and Bobbi J. Young Patterns of Software: Tales from the Software Community by Richard P. Gabriel 67. Head First Object-Oriented Analysis and Design by Brett D. McLaughlin, Gary Pollice and Dave West 30. Pattern Languages of Program Design 2 (v. 2) by John Vlissides, James O. Coplien and Norman L. Kerth 68. Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin 31. Software Patterns by James Coplien 69. 32. Design Patterns For Dummies by Steve Holzner Software Architecture: Perspectives on an Emerging Discipline by Mary Shaw and David Garlan 70. Pattern Languages of Program Design 5 by Dragos Manolescu, Markus Voelter and James Noble 33. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns: The Demeter Method with 71. Design Patterns in Java(TM) (Software Patterns Series) by Steven John Metsker and William C. Wake 34. Propagation... by Karl Lieberherr Object-Oriented Design and Patterns by Cay S. Horstmann 35. Pattern Languages of Program Design by James O. Coplien and Douglas C. Schmidt 72. 43/162

Form “Each pattern is a three part rule, which express a relation between a context, a problem, and a solution.” —Christopher Alexander, 1977 44/162

Form  General form as for the GoF also inspired by Coplien’s form – Name – Problem(s) – Solution – Consequences 45/162

Form (Extended)  General form as for the GoF also inspired by Coplien’s form – Name – Problem (s) – Example(s) – Solution – Example(s) – Consequences – (Follow-up) 46/162

Form  General form as for the GoF also inspired by Coplien’s form – Not formal – Room for interpretation – But… • UML-like class diagrams • UML-like sequence diagrams • Smalltalk / C++ example code 47/162

Example (1/5)  Simplified compiler – Parse files to build an AST – Iterate over the AST • Build DefaultMutableTreeNode s javax.swing.tree.DefaultMutableTreeNode for a graphical representation of the AST • Bind types • Generate code • … 49/162

Example (1/5)  Simplified compiler – Parse files to build an AST – Iterate over the AST • Build DefaultMutableTreeNode s javax.swing.tree.DefaultMutableTreeNode for a graphical representation of the AST • Bind types • Generate code • … 50/162

Example (2/5)  AST CompilationUnit Main generateCode() Class generateCode() Field Method generateCode() generateCode() Statement generateCode() 51/162

Example (3/5) package compiler; import java.util.Set; public class Method { private Set statements; public void addStatement( final Statement aStatement) { this .statements.add(aStatement); } public void removeStatement( final Statement aStatement) { this .statements.remove(aStatement); } } package compiler; package compiler; public class Field { public class Statement { /* To be implemented. */ /* To be implemented. */ } } 52/162

Example (4/5) package compiler; import java.util.Set; public class Class { private String name; private Set methods; private Set fields; public String getName() { return this .name; } public void addMethod( final Method aMethod) { this .methods.add(aMethod); } public void removeMethod( final Method aMethod) { this .methods.remove(aMethod); } public void addField( final Method aField) { this .fields.add(aField); } public void removeField( final Field aField) { this .fields.remove(aField); } } 53/162

Example (5/5) package compiler; import java.util.Iterator; import java.util.Set; public class CompilationUnit { private Set classes; public void addClass( final Class aClass) { this .classes.add(aClass); } public void removeClass( final Class aClass) { this .classes.remove(aClass); } public Class getClass( final String aName) { final Iterator iterator = this .classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); if (aClass.getName().equals(aName)) { return aClass; } } return null ; } } 54/162

Naïve Implementation (1/7)  How to generate microcode for – Microsoft Windows operating system – Intel Pentium processor Add a generateCode() method in each class 55/162

Naïve Implementation (2/7) public class Method { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iterator = this .statements.iterator(); while (iterator.hasNext()) { final Statement aStatement = (Statement) iterator.next(); generatedCode += aStatement.generateCode(); } /* Do something at the end. */ return generatedCode; } } public class Field { public class Statement { … … public String generateCode() { public String generateCode() { String generatedCode = ""; String generatedCode = ""; /* Do something. */ /* Do something. */ return generatedCode; return generatedCode; } } } } 56/162

Naïve Implementation (3/7) public class Class { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iteratorOnFields = this .fields.iterator(); while (iteratorOnFields.hasNext()) { final Field aField = (Field) iteratorOnFields.next(); generatedCode += aField.generateCode(); } final Iterator iteratorOnMethods = this .methods.iterator(); while (iteratorOnMethods.hasNext()) { final Method aMethod = (Method) iteratorOnMethods.next(); generatedCode += aMethod.generateCode(); } /* Do something at the end. */ return generatedCode; } } 57/162

Naïve Implementation (4/7) public class CompilationUnit { … public String generateCode() { String generatedCode = ""; /* Do something at the beginning. */ final Iterator iterator = this .classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); generatedCode += aClass.generateCode(); } /* Do something at the end. */ return generatedCode; } } 58/162

Naïve Implementation (5/7) m : Main cu : c : Class m : Method s : Statement CompilationUnit generateCode( ) generateCode( ) generateCode( ) generateCode( ) 59/162

Naïve Implementation (6/7)  Limitations of the naïve implementation – What about generating code for • Linux on PowerPC? • Linux on Motorola 68060? • OS/400 on AS/400? Combinatorial explosion of generateCodeForXXX() methods in each class 60/162

Naïve Implementation (7/7)  Requirements – Decouple the data structure • The AST – From algorithms on the data structure • The generateCodeForXXX() method • And others, including type binding! The Visitor design pattern guides you to do that! 61/162

Visitor (2/13)  Name : Visitor  Intent : “Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.” 62/162

Visitor (3/13)  Motivation : “Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for "static semantic" analyses like checking that all variables are defined. It will also need to generate code.” 63/162

Visitor (4/13)  Motivation (cont’d): “[…] It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. […] It would be better if each new operation could be added separately, and the node classes were independent of the operations that apply to them.” 64/162

Visitor (5/13)  Motivation (cont’d): “We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it's traversed.” 65/162

Visitor (6/13)  Motivation (cont’d): “When an element accepts the visitor, it sends a request to the visitor that encodes the element's class. It also includes the element as an argument. The visitor will then execute the operation for that element—the operation that used to be in the class of the element.” 66/162

Visitor (8/13)  Applicability – An object structure contains many classes of objects with differing interfaces… – Many distinct and unrelated operations need to be performed on objects in an object structure… – The classes defining the object structure rarely change, but you often want to define new operations over the structure… 67/162

Visitor (9/13)  Structure 68/162

Visitor (10/13)  Participants – Visitor ( NodeVisitor ) – ConcreteElement • Declares a Visit operation for ( AssignmentNode ) each class… • Implements Accept … – ConcreteVisitor – ObjectStructure ( Program ) ( TypeCheckingVisitor ) • Can enumerate its elements • Implements each Visit… • May provide a high-level – Element ( Node ) interface to allow the visitor • Defines an Accept operation… to visit its elements • May either be a composite (see Composite) or a collection 69/162

Visitor (11/13)  Collaborations 70/162

Visitor (13/13)  Consequences : …  Implementation : …  Sample code : …  Known uses – ASTs – Meta-models – …  Related patterns : Composite 71/162

Better Implementation (1/6) package compiler.visitor; import compiler.Class; import compiler.CompilationUnit; import compiler.Field; import compiler.Method; import compiler.Statement; public interface Visitor { void open( final Class aClass); void open( final CompilationUnit aCompilationUnit); void open( final Method aMethod); void close( final Class aClass); void close( final CompilationUnit aCompilationUnit); void close( final Method aMethod); void visit( final Field aField); void visit( final Statement aStatement); } 72/162

Better Implementation (2/6) public class Method { … public void accept( final Visitor aVisitor) { aVisitor.open( this ); final Iterator iterator = this .statements.iterator(); while (iterator.hasNext()) { final Statement aStatement = (Statement) iterator.next(); aStatement.accept(aVisitor); } aVisitor.close( this ); } } public class Field { … public void accept( final Visitor aVisitor) { aVisitor.visit( this ); } } public class Statement { … public void accept( final Visitor aVisitor) { aVisitor.visit( this ); } } 73/162

Better Implementation (3/6) public class Class { … public void accept( final Visitor aVisitor) { aVisitor.open( this ); final Iterator iteratorOnFields = this .fields.iterator(); while (iteratorOnFields.hasNext()) { final Field aField = (Field) iteratorOnFields.next(); aField.accept(aVisitor); } final Iterator iteratorOnMethods = this .methods.iterator(); while (iteratorOnMethods.hasNext()) { final Method aMethod = (Method) iteratorOnMethods.next(); aMethod.accept(aVisitor); } aVisitor.close( this ); } } 74/162

Better Implementation (4/6) public class CompilationUnit { … public void accept( final Visitor aVisitor) { aVisitor.open( this ); final Iterator iterator = this .classes.iterator(); while (iterator.hasNext()) { final Class aClass = (Class) iterator.next(); aClass.accept(aVisitor); } aVisitor.close( this ); } } 75/162

m : Main cu : c : Class m : Method s : Statement v : IVisitor CompilationUnit Better implementation (5/6) accept(IVisitor) open(CompilationUnit) accept(IVisitor) m : Main cu : c : Class m : Method open(Clas s) s : Statement CompilationUnit accept(IVisitor) generateCode( ) open(Method) generateCode( ) accept(IVis itor) visit(Statement) generateCode( ) generateCode( ) close(Method) close(Class) close(CompilationUnit) 76/162

m : Main cu : c : Class m : Method s : Statement v : IVisitor CompilationUnit Better implementation (5/6) accept(IVisitor) open(CompilationUnit) accept(IVisitor) m : Main cu : c : Class open(Clas s) m : Method s : Statement CompilationUnit accept(IVisitor) generateCode( ) open(Method) generateCode( ) accept(IVis itor) visit(Statement) generateCode( ) generateCode( ) close(Method) close(Class) close(CompilationUnit) 77/162

Better Implementation (6/6)  By using the visitor design pattern – Decouple data structure and algorithms – Put the traversal in only one place, in the AST – Allow the addition of new algorithms without changing the data structure Much better, clearer implementation! 78/162

Conclusion on the Example  The Visitor design pattern is useful anywhere you have – A data (stable) structure – Algorithms (infinite) on that data structure  Design patterns provided good solution to recurrent problems! 79/162

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ; Design Patterns: Elements of Reusable Object-Oriented Software ; 81/162 Addison-Wesley, 1995

Catalogue  Design patterns – Development and maintenance – Design/implementation levels – Examples in C++ and Smalltalk  Divided in three categories – Behavioural – Creational – Structural 82/162

Catalogue 83/162

Catalogue  Abstract Factory (87) – Provide an interface for creating families of related or dependent objects without specifying their concrete classes  Adapter (139) – Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces 84/162

Catalogue  Bridge (151) – Decouple an abstraction from its implementation so that the two can vary independently  Builder (97) – Separate the construction of a complex object from its representation so that the same construction process can create different representations 85/162

Catalogue  Chain of Responsibility (223) – Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it 86/162

Catalogue  Command (233) – Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations  Composite (163) – Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly 87/162

Catalogue  Decorator (175) – Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality  Facade (185) – Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use 88/162

Catalogue  Factory Method (107) – Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses  Flyweight (195) – Use sharing to support large numbers of fine- grained objects efficiently 89/162

Catalogue  Interpreter (243) – Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language  Iterator (257) – Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation 90/162

Catalogue  Mediator (273) – Define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently  Memento (283) – Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later 91/162

Catalogue  Observer (293) – Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically  Prototype (117) – Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype 92/162

Catalogue  Proxy (207) – Provide a surrogate or placeholder for another object to control access to it.  Singleton (127) – Ensure a class only has one instance, and provide a global point of access to it 93/162

Catalogue  State (305) – Allow an object to alter its behaviour when its internal state changes. The object will appear to change its class  Strategy (315) – Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it 94/162

Catalogue  Template Method (325) – Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure 95/162

Catalogue  Visitor (331) – Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates 96/162

Practice “The strict modeling of the real world leads to reflect today’s realities but not necessarily tomorrow’s. The abstractions that emerge during design are key to making a design flexible.” —Erich Gamma, 1994 98/162

Practice “The description of communicating objects and classes customized to solve general design problem in a particular context.” —Erich Gamma, 1994 99/162

Practice “Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.” —Erich Gamma, 1994 100/162

CSE3009: (Software Architecture and Design) Yann-Gal - PowerPoint PPT Presentation