1. CEN 4010 Ninth Lecture March 4, 2005 Introduction to Software Engineering (CEN-4010) Spring 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Classes/CEN-4010/ Object Design: Reuse and Patterns II

2. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 2 Acknowledgements  Dr. Bernd Bruegge  Dr. Allen Dutoit  Dr. Betty Cheng Overview: Motivation Overview Design Patterns Summary

3. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 3 Agenda  Motivation  Overview  Some Design Patterns  Summary Overview: Motivation Overview Design Patterns Summary

4. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 4 Motivation (1)  Developing software is hard  Designing reusable software is more challenging –finding good objects and abstractions –flexibility, modularity, elegance –takes time for them to emerge, trial and error  Successful designs do exist –exhibit recurring class and object structures Overview: Motivation Overview Design Patterns Summary

5. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 5 Motivation (2)  During Object Modeling we do many transformations and changes to the object model.  It is important to make sure the object design model stays simple!  We show how to use design patterns to keep system models simple. Overview: Motivation Overview Design Patterns Summary

6. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 6 Motivation (3) Modeling must address our mental limitations: –Our short-term memory has only limited capacity (7+-2)  Good Models deal with this limitation, because they –Do not tax the mind  A good model requires only a minimal mental effort to understand –Reduce complexity  Turn complex tasks into easy ones (by good choice of representation)  Use of symmetries –Use abstractions  Ontology and taxonomy –Have organizational structure:  Memory limitations are overcome with an appropriate representation (“natural model”) Overview: Motivation Overview Design Patterns Summary

7. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 7 Motivation (4)  The hardest problems in object-oriented system development are: –Identifying objects –Decomposing the system into objects  Requirements Analysis –focuses on application domain –Object identification  System Design –addresses both, application and implementation domain –Subsystem Identification  Object Design –focuses on implementation domain –Additional solution objects Overview: Motivation Overview Design Patterns Summary

8. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 8 Techniques for Finding Objects  Requirements Analysis –Start with Use Cases. Identify participating objects –Textual analysis of flow of events (find nouns, verbs,...) –Extract application domain objects by interviewing client (application domain knowledge) –Find objects by using general knowledge  System Design –Subsystem decomposition –Try to identify layers and partitions  Object Design –Find additional objects by applying implementation domain knowledge Overview: Motivation Overview Design Patterns Summary

9. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 9 Agenda  Motivation  Overview  Some Design Patterns  Summary Overview: Motivation Overview Design Patterns Summary

10. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 10 Another Source of Objects  Design Patterns  What are Design Patterns? –A design pattern describes a problem which occurs over and over again in our environment –It describes the core of the solution to that problem, in such a way that you can use the this solution a million times over, without ever doing it the same twice. Overview: Motivation Overview Design Patterns Summary

11. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 11 Design Patterns (1) A design pattern is… …a template solution to a recurring design problem –Look before re-inventing the wheel just one more time. …reusable design knowledge –Higher level than classes or data structures (link lists, binary trees...). –Lower level than application frameworks. …an example of modifiable design –Learning to design starts by studying other designs. Overview: Motivation Overview Design Patterns Summary

12. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 12 Design Patterns (2)  Describes recurring design structure –names, abstracts from concrete designs –identifies classes, collaborations, responsibilities –applicability, trade-offs, consequences  Design patterns represent solutions to problems that arise when developing software within a particular context –“Patterns == problem/solution pairs in a context”  Patterns capture the static and dynamic structure and collaboration among key participants in software designs –Especially good for describing how and why to resolve non-functional issues  Patterns facilitate reuse of successful software architectures and designs. Overview: Motivation Overview Design Patterns Summary

13. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 13 Essential Elements  Pattern name  Problem  Solution  Consequences Overview: Motivation Overview Design Patterns Summary

14. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 14 Applications  Wide variety of application domains: –drawing editors, banking, CAD, CAE, cellular network management, telecomm switches, program visualization  Wide variety of technical areas: –user interface, communications, persistent objects, O/S kernels, distributed systems Overview: Motivation Overview Design Patterns Summary

15. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 15 Why modifiable designs? A modifiable design enables… …an iterative and incremental development cycle –concurrent development –risk management –flexibility to change …to minimize the introduction of new problems when fixing old ones …to deliver more functionality after initial delivery Overview: Motivation Overview Design Patterns Summary

16. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 16 What makes a design modifiable?  Low coupling and high cohesion  Clear dependencies  Explicit assumptions How do design patterns help?  They are generalized from existing systems  They provide a shared vocabulary to designers  They provide examples of modifiable designs –Abstract classes –Delegation Overview: Motivation Overview Design Patterns Summary

17. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 17 Design Pattern Space  Creational patterns: –Deal with initializing and configuring classes and objects  Structural patterns: –Deal with decoupling interface and implementation of classes and objects –Composition of classes or objects  Behavioral patterns: –Deal with dynamic interactions among societies of classes and objects –How they distribute responsibility Overview: Motivation Overview Design Patterns Summary

18. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 18 Categorize Design Patterns CreationalStructuralBehavioral Factory Method Abstract Factory Prototype Singleton Builder Adapter (class) Adapter (object) Bridge Flyweight Decorator Proxy Composite Facade Template Method Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Interpreter Visitor Purpose Class Object Scope Abstract Factory Adapter (class) Adapter (object) Bridge Proxy Composite Facade Command Observer Strategy Overview: Motivation Overview Design Patterns Summary

19. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 19 Agenda  Motivation  Overview  Some Design Patterns  Summary Overview: Motivation Overview Design Patterns Summary

20. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 20 Composite Pattern  Models tree structures that represent part- whole hierarchies with arbitrary depth and width.  The Composite Pattern lets client treat individual objects and compositions of these objects uniformly Client Component Leaf Operation() Composite Operation() AddComponent RemoveComponent() GetChild() Children Overview: Motivation Overview Design Patterns Summary

21. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 21 Example Client Component Leaf Operation() Composite Operation() AddComponent RemoveComponent() GetChild() Children Overview: Motivation Overview Design Patterns Summary

22. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 22 Example: Java AWT Package Graphics Component Button TextField Label * TextArea Text Component Container add(Component c) paint(Graphics g) getGraphics() Overview: Motivation Overview Design Patterns Summary

23. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 23 Adapter pattern  Delegation is used to bind an Adapter and an Adaptee  Interface inheritance is used to specify the interface of the Adapter class.  Target and Adaptee (usually called legacy system) pre-exist the Adapter. Client ClientInterface Request() LegacyClass ExistingRequest() Adapter Request() adaptee Overview: Motivation Overview Design Patterns Summary

24. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 24 Adapter Pattern  “Convert the interface of a class into another interface clients expect.”  The adapter pattern lets classes work together that couldn’t otherwise because of incompatible interfaces  Used to provide a new interface to existing legacy components (Interface engineering, reengineering).  Also known as a wrapper  Two adapter patterns: –Class adapter:  Uses multiple inheritance to adapt one interface to another –Object adapter:  Uses single inheritance and delegation  Object adapters are much more frequent. We will only cover object adapters (and call them therefore simply adapters) Overview: Motivation Overview Design Patterns Summary

25. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 25 Bridge Pattern  Use a bridge to “decouple an abstraction from its implementation so that the two can vary independently”. (From [Gamma et al 1995])  Also know as a Handle/Body pattern.  Allows different implementations of an interface to be decided upon dynamically. Overview: Motivation Overview Design Patterns Summary

26. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 26 Bridge Pattern Overview: Motivation Overview Design Patterns Summary

27. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 27 Using a Bridge  The bridge pattern is used to provide multiple implementations under the same interface.  Examples: Interface to a component that is incomplete, not yet known or unavailable during testing  JAMES Project: if seat data is required to be read, but the seat is not yet implemented, known, or only available by a simulation, provide a bridge Overview: Motivation Overview Design Patterns Summary

28. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 28 Example Client Seat (in Vehicle Subsystem) SeatImplementation Stub Code SARTSeat AIMSeat imp GetPosition() SetPosition() Overview: Motivation Overview Design Patterns Summary

29. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 29 Adapter vs Bridge  Similarities: –Both are used to hide the details of the underlying implementation.  Difference: –The adapter pattern is geared towards making unrelated components work together  Applied to systems after they’re designed (reengineering, interface engineering). –A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.  Green field engineering of an “extensible system”  New “beasts” can be added to the “object zoo”, even if these are not known at analysis or system design time. Overview: Motivation Overview Design Patterns Summary

30. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 30 Facade Pattern  Provides a unified interface to a set of objects in a subsystem.  A facade defines a higher-level interface that makes the subsystem easier to use (i.e. it abstracts out the gory details)  Facades allow us to provide a closed architecture Overview: Motivation Overview Design Patterns Summary

31. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 31 Example: Subsystem Design  The ideal structure of a subsystem consists of –an interface object –a set of application domain objects (entity objects) modeling real entities or existing systems  Some of the application domain objects are interfaces to existing systems –one or more control objects  We can use design patterns to realize this subsystem structure  Realization of the Interface Object: Facade –Provides the interface to the subsystem  Interface to existing systems: Adapter or Bridge –Provides the interface to existing system (legacy system) –The existing system is not necessarily object-oriented! Overview: Motivation Overview Design Patterns Summary

32. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 32 Encouraging Reusable Designs  A facade pattern should be used by all subsystems in a software system. The façade defines all the services of the subsystem.  Adapters should be used to interface to existing components.  Bridges should be used to interface to a set of objects. Use it for testing.  Model/View/Controller should be used when the interface changes much more rapidly than the application domain. Is MVC a DP? Overview: Motivation Overview Design Patterns Summary

33. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 33 Proxy Pattern  What is expensive? –Object Creation –Object Initialization  Defer object creation and object initialization to the time you need the object  Proxy pattern: –Reduces the cost of accessing objects –Uses another object (“the proxy”) that acts as a stand-in for the real object –The proxy creates the real object only if the user asks for it Overview: Motivation Overview Design Patterns Summary

34. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 34 Proxy pattern  Interface inheritance is used to specify the interface shared by Proxy and RealSubject.  Delegation is used to catch and forward any accesses to the RealSubject (if desired)  Proxy patterns can be used for lazy evaluation and for remote invocation.  Proxy patterns can be implemented with a Java interface. Subject Request() RealSubject Request() Proxy Request() realSubject Overview: Motivation Overview Design Patterns Summary

35. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 35 Proxy Applicability  Remote Proxy –Local representative for an object in a different address space –Caching of information: Good if information does not change too often  Virtual Proxy –Object is too expensive to create or too expensive to download –Proxy is a standin  Protection Proxy –Proxy provides access control to the real object –Useful when different objects should have different access and viewing rights for the same document. –Example: Grade information for a student shared by administrators, teachers and students. Overview: Motivation Overview Design Patterns Summary

36. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 36 Command Pattern  It is desirable to undo/store/redo a command without knowing the meaning of a command.  Example –Recording the moves in a game to replay. –However, we do not want the classes involved in recording the moves to be dependent on a specific game. Overview: Motivation Overview Design Patterns Summary

37. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 37 Command pattern Move execute() GameBoard action() Client Match ChessMove execute() binds Overview: Motivation Overview Design Patterns Summary Play() Replay()

38. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 38 Command pattern Applicability  “Encapsulate a request as an object, thereby letting you –parameterize clients with different requests, –queue or log requests, and –support undoable operations.”  Uses: –Undo queues –Database transaction buffering Overview: Motivation Overview Design Patterns Summary

39. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 39 Observer pattern  “Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.”  Also called “Publish and Subscribe”  Uses: –Maintaining consistency across redundant state –Optimizing batch changes to maintain consistency Overview: Motivation Overview Design Patterns Summary

40. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 40 Observer pattern  The Subject represents the actual state, the Observers represent different views of the state.  Observer can be implemented as a Java interface.  Subject is a super class (needs to store the observers vector) not an interface. Observer update() Subject attach(observer) detach(observer) notify() ConcreteSubject getState() setState(newState) subjectState ConcreteObserver update() observerState observers subject * Overview: Motivation Overview Design Patterns Summary

41. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 41 Strategy Pattern  Many different algorithms exists for the same task  Examples: –Breaking a stream of text into lines –Parsing a set of tokens into an abstract syntax tree –Sorting a list of customers  The different algorithms will be appropriate at different times –Rapid prototyping vs delivery of final product  We don’t want to support all the algorithms if we don’t need them  If we need a new algorithm, we want to add it easily without disturbing the application using the algorithm Overview: Motivation Overview Design Patterns Summary

42. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 42 Strategy Pattern Policy decides which Strategy is best given the current Context Strategy AlgorithmInterface Context ContextInterface() ConcreteStrategyC AlgorithmInterface() * ConcreteStrategyB AlgorithmInterface() ConcreteStrategyA AlgorithmInterface() Policy Overview: Motivation Overview Design Patterns Summary

43. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 43 Example: A Database Application Strategy Sort() Database Search() Sort() Strategy * BubbleSort Sort() QuickSort Sort() MergeSort Sort() Overview: Motivation Overview Design Patterns Summary

44. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 44 Applicability of Strategy Pattern  Many related classes differ only in their behavior. Strategy allows to configure a single class with one of many behaviors  Different variants of an algorithm are needed that trade-off space against time. All these variants can be implemented as a class hierarchy of algorithms Overview: Motivation Overview Design Patterns Summary

45. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 45 Abstract Factory Motivation  2 Examples  Consider a user interface toolkit that supports multiple looks and feel standards such as Motif, Windows 95 or the finder in MacOS. –How can you write a single user interface and make it portable across the different look and feel standards for these window managers?  Consider a facility management system for an intelligent house that supports different control systems such as Siemens’ Instabus, Johnson & Control Metasys or Zumtobe’s proprietary standard. –How can you write a single control system that is independent from the manufacturer? Overview: Motivation Overview Design Patterns Summary

46. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 46 Abstract Factory CreateProductA CreateProductB CreateProductA CreateProductB AbstractProductA ProductA1 ProductA2 AbstractProductB ProductB1 ProductB2 ConcreteFactory1 CreateProductA CreateProductB ConcreteFactory2 Client Initiation Assocation: Class ConcreteFactory2 initiates the associated classes ProductB2 and ProductA2 Overview: Motivation Overview Design Patterns Summary

47. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 47 Applicability  Independence from Initialization or Represenation: –The system should be independent of how its products are created, composed or represented  Manufacturer Independence: –A system should be configured with one family of products, where one has a choice from many different families. –You want to provide a class library for a customer (“facility management library”), but you don’t want to reveal what particular product you are using.  Constraints on related products –A family of related products is designed to be used together and you need to enforce this constraint  Cope with upcoming change: –You use one particular product family, but you expect that the underlying technology is changing very soon, and new products will appear on the market. Overview: Motivation Overview Design Patterns Summary

48. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 48 Agenda  Motivation  Overview  Some Design Patterns  Summary Overview: Motivation Overview Design Patterns Summary

49. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 49 Summary (1)  Design patterns are partial solutions to common problems such as – such as separating an interface from a number of alternate implementations –wrapping around a set of legacy classes – protecting a caller from changes associated with specific platforms.  A design pattern is composed of a small number of classes –use delegation and inheritance –provide a robust and modifiable solution.  These classes can be adapted and refined for the specific system under construction. –Customization of the system –Reuse of existing solutions Overview: Motivation Overview Design Patterns Summary

50. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 50 Summary (2)  Structural Patterns –Focus: How objects are composed to form larger structures –Problems solved:  Realize new functionality from old functionality,  Provide flexibility and extensibility  Behavioral Patterns –Focus: Algorithms and the assignment of responsibilities to objects –Problem solved:  Too tight coupling to a particular algorithm  Creational Patterns –Focus: Creation of complex objects –Problems solved:  Hide how complex objects are created and put together Overview: Motivation Overview Design Patterns Summary

51. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 51 Summary (3)  Composite: Model dynamic aggregates  Facade: Interfacing to subsystems  Adapter: Interfacing to existing systems  Bridge: Interfacing to existing and future systems  Abstract Factory: Provide manufacturer independence  Proxy: Provide Location transparency  Command: Encapsulate control flow  Observer: Provide publisher/subscribe mechanism  Strategy: Support family of algorithms, separate of policy and mechanism Overview: Motivation Overview Design Patterns Summary

52. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 52 Conclusions  Design patterns:  Provide solutions to common problems.  Lead to extensible models and code.  Can be used as is or as examples of interface inheritance and delegation.  Apply the same principles to structure and to behavior. Overview: Motivation Overview Design Patterns Summary

53. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 53 Nonfunc. Reqs.  Design Patterns (1)  Read the problem statement again  Use textual clues (similar to Abbot’s technique in Analysis) to identify design patterns  Text: “manufacturer independent”, “device independent”, “must support a family of products” –Abstract Factory Pattern  Text: “must interface with an existing object” –Adapter Pattern  Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated” –Bridge Pattern Overview: Motivation Overview Design Patterns Summary

54. Ninth Lecture on March 4, 2005CEN 4010: Introduction to Software Engineering 54 Nonfunc. Reqs.  Design Patterns (2)  Text: “complex structure”, “must have variable depth and width” –Composite Pattern  Text: “must interface to an set of existing objects” –Façade Pattern  Text: “must be location transparent” –Proxy Pattern  Text: “must be extensible”, “must be scalable” –Observer Pattern  Text: “must provide a policy independent from the mechanism” –Strategy Pattern Overview: Motivation Overview Design Patterns Summary