Using UML Patterns and Java ObjectOriented Software Engineering
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Reuse and Patterns III
Outline of the Lecture ¨ Review of design pattern concepts w What is a design pattern? w Modifiable designs More patterns: w w w Abstract Factory: Provide manufacturer independence Builder: Hide a complex creation process Proxy: Provide Location transparency Command: Encapsulate control flow Observer: Provide publisher/subscribe mechanism Strategy: Support family of algorithms, separate of policy and mechanism Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
Review: Design pattern A design pattern is… …a template solution to a recurring design problem w Look before re-inventing the wheel just one more time …reusable design knowledge w Higher level than classes or datastructures (link lists, binary trees. . . ) w Lower level than application frameworks …an example of modifiable design w Learning to design starts by studying other designs Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
Why are modifiable designs important? A modifiable design enables… …an iterative and incremental development cycle w concurrent development w risk management w flexibility to change …to minimize the introduction of new problems when fixing old ones …to deliver more functionality after initial delivery Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
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 w Abstract classes w Delegation Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
On to More Patterns! ¨ Structural pattern w Proxy ¨ Creational Patterns w Abstract Factory w Builder ¨ Behavioral pattern w Command w Observer w Strategy Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Proxy Pattern: Motivation ¨ It is 15: 00 pm. I am sitting at my 14. 4 baud modem connection and retrieve a fancy web site from the US. w This is prime web time all over the US. So I am getting 10 bits/sec. w The fancy web site has lots of images. w I’m still waiting… ¨ What can I do? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
Proxy Pattern ¨ What is expensive? w Object Creation w Object Initialization ¨ ¨ Defer object creation and object initialization to the time you need the object Proxy pattern: w Reduces the cost of accessing objects w Uses another object (“the proxy”) that acts as a stand-in for the real object w The proxy creates the real object only if the user asks for it ¨ Show page without images; use a proxy image; fill in with actual image later when explicitly asked for. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
Proxy pattern Subject Request() Proxy Request() ¨ ¨ real. Subject Request() Interface inheritance is used to specify the interface shared by Proxy and Real. Subject. Delegation is used to catch and forward any accesses to the Real. Subject (if desired) Proxy patterns can be used for lazy evaluation and for remote invocation. Proxy patterns can be implemented with a Java interface. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
Proxy Applicability ¨ Remote Proxy w Local representative for an object in a different address space w Caching of information: Good if information does not change too often ¨ Virtual Proxy w Object is too expensive to create or too expensive to download w Proxy is a standin ¨ Protection Proxy w Proxy provides access control to the real object w Useful when different objects should have different access and viewing rights for the same document. w Example: Grade information for a student shared by administrators, teachers and students. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
Virtual Proxy example Image bounding. Box() draw() Proxy. Image bounding. Box() draw() ¨ ¨ real. Subject Real. Image bounding. Box() draw() Images are stored and loaded separately from text If a Real. Image is not loaded a Proxy. Image displays a grey rectangle in place of the image The client cannot tell that it is dealing with a Proxy. Image instead of a Real. Image A proxy pattern can be easily combined with a Bridge Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
Before Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Controlling Access Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
After Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
Towards a Pattern Taxonomy ¨ Structural Patterns w Adapters, Bridges, Facades, and Proxies are variations on a single theme: t t t ¨ They reduce the coupling between two or more classes They introduce an abstract class to enable future extensions They encapsulate complex structures Behavioral Patterns w Here we are concerned with algorithms and the assignment of responsibilies between objects: Who does what? w Behavorial patterns allow us to characterize complex control flows that are difficult to follow at runtime. ¨ Creational Patterns w Here we our goal is to provide a simple abstraction for a complex instantiation process. w We want to make the system independent from the way its objects are created, composed and represented. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
A Pattern Taxonomy Pattern Creational Pattern Structural Pattern Behavioral Pattern Command Observer Strategy Abstract Factory Builder Pattern Singleton Adapter Bridge Bernd Bruegge & Allen H. Dutoit Facade Proxy Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
Singleton Pattern: Motivation ¨ You want to make sure there is only one instance of an object. You don’t want to pass the reference of the one instance around. ¨ Memory object in a CPU simulator application. ¨ w Many instruction objects will need access to this object to execute. w How get the Memory object reference to these instruction objects? w There is also only one CPU object. t t t The CPU needs access to the Memory. The Memory needs access to the CPU (flags/interrupts). Who creates who? Who gets created first? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
Singleton pattern ¨ ¨ public class Singleton { private int x; private static Singleton s; Singleton private Singleton() {x=5; } public int get. X() { get. Instance() return x; } public void set. X(int x) { this. x = x; Private constructor! } public static Singleton Static field reference get. Instance() { if (s == null) get. Instance controls access s = new Singleton(); to constructor return s; Returns field reference } Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
A Pattern Taxonomy Pattern Creational Pattern Structural Pattern Behavioral Pattern Command Observer Strategy Abstract Factory Builder Pattern Singleton Adapter Bridge Bernd Bruegge & Allen H. Dutoit Facade Proxy Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
Command Pattern: Motivation ¨ You want to “undo”/redo an action. ¨ You want to group a series of actions into a transaction. ¨ You want to log actions. ¨ Encapsulate an action/behavior into an object!! w w Invoker used to do the action/behavior themselves. Now, invoker creates a command object who does the action. We’ve decoupled the algorithm (action/behavior) from invoker We can store/log/use these “encapsulated” actions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
Command pattern Command Invoker execute() Client Receiver binds Concrete. Command action() ¨ ¨ ¨ execute() Client creates a Concrete. Command binds it with a Receiver. Client hands the Concrete. Command over to the Invoker which stores it. The Invoker has the responsibility to do the command (“execute” or “undo”). Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
Command pattern Applicability ¨ “Encapsulate a request as an object, thereby letting you w parameterize clients with different requests, w queue or log requests, and w support undoable operations. ” ¨ Uses: w Undo queues w Database transaction buffering Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
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: ¨ w Maintaining consistency across redundant state w Optimizing batch changes to maintain consistency Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
Observer pattern (continued) Observers Subject 9 Design. Patterns 2. ppt Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
Observer pattern (cont’d) Subject attach(observer) detach(observer) notify() observers * update() subject Concrete. Subject get. State() set. State(new. State) subject. State ¨ ¨ ¨ Observer Concrete. Observer update() observer. State 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. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
Sequence diagram for scenario: Change filename to “foo” a. File an. Info. View Attach() a. List. View Attach() set. State(“foo”) Subject goes through all its observers and calls update() on them, asking for the new state is decoupled from the notification notify() update() get. State() “foo” update() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
Animated Sequence diagram a. File an. Info. View Attach() a. List. View Attach() set. State(“foo”) notify() update() get. State() “foo” Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
Observer pattern implementation in Java // import java. util; public class Model extends Observable { private int x; public void set. X(int x) { this. x = x; notify. Observers(); } } public class View 1 implements Observer { public void update(Observable o, Object arg) { o. get. X(); } } Model m = new Model(); View 1 v 1 = new View 1(); m. add. Observer(v 1); m. set. X(5); Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
A Pattern Taxonomy Pattern Creational Pattern Structural Pattern Adapter Behavioral Pattern Command Observer Bridge Facade Bernd Bruegge & Allen H. Dutoit Strategy Abstract Factory Builder Pattern Proxy Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
Strategy Pattern ¨ ¨ Many different algorithms exists for the same task Examples: w Breaking a stream of text into lines w Parsing a set of tokens into an abstract syntax tree w Sorting a list of customers ¨ The different algorithms will be appropriate at different times w 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 May want to decide algorithm “on-the-fly” Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
Strategy Pattern Policy Context. Interface() * Strategy Algorithm. Interface Concrete. Strategy. A Concrete. Strategy. B Concrete. Strategy. C Algorithm. Interface() Policy decides which Strategy is best given the current Context Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
Like Bridge? !! ¨ Yes! ¨ Difference is the “Context” class uses the “Policy” class to make the decision (or, which strategy to use now). w User of strategy (Context) does not decide on strategy (Policy) w In other words, use is decoupled from decision. ¨ Bridge is more for permanent replacement not on-the-fly replacement. w Replace old XML-based data storage with My. SQL-based. w Ship a version that uses Post. Gre. SQL Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
A Pattern Taxonomy Pattern Creational Pattern Structural Pattern Adapter Behavioral Pattern Command Observer Bridge Facade Bernd Bruegge & Allen H. Dutoit Strategy Abstract Factory Builder Pattern Proxy Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
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 Mac. OS. w 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. w How can you write a single control system that is independent from the manufacturer? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
Abstract Factory Abstract. Product. A Abstract. Factory Client Create. Product. A Create. Product. B Product. A 1 Concrete. Factory 1 Product. A 2 Abstract. Product. B Create. Product. A Create. Product. B 1 Product. B 2 Concrete. Factory 2 Create. Product. A Create. Product. B Bernd Bruegge & Allen H. Dutoit Initiation Assocation: Class Concrete. Factory 2 initiates the associated classes Product. B 2 and Product. A 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Applicability for Abstract Factory Pattern ¨ Independence from Initialization or Represenation: w The system should be independent of how its products are created, composed or represented ¨ Manufacturer Independence: w A system should be configured with one family of products, where one has a choice from many different families. w 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 w A family of related products is designed to be used together and you need to enforce this constraint ¨ Cope with upcoming change: w 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. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
Example: A Facility Management System for the Intelligent Workplace Facility Mgt System Intelligent. Workplace Light. Bulb create. Blind Instabus. Light. Bulb Zumbobel. Light. Bulb Blinds Siemens. Factory create. Light. Bulb create. Blind Instabus. Blind Zumtobel. Factory create. Light. Bulb create. Blind Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
Comparison: Abstract Factory vs Builder ¨ Abstract Factory w Focuses on product family t The products can be simple (“light bulb”) or complex (“engine”) w Does not hide the creation process t The product is immediately returned Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
Summary ¨ Structural Patterns w Focus: How objects are composed to form larger structures w Problems solved: t t ¨ Realize new functionality from old functionality, Provide flexibility and extensibility Behavioral Patterns w Focus: Algorithms and the assignment of responsibilities to objects w Problem solved: t ¨ Too tight coupling to a particular algorithm Creational Patterns w Focus: Creation of complex objects w Problems solved: t Hide how complex objects are created and put together Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
Conclusion ¨ Design patterns w Provide solutions to common problems. w Lead to extensible models and code. w Can be used as is or as examples of interface inheritance and delegation. w Apply the same principles to structure and to behavior. ¨ ¨ Design patterns solve all your software engineering problems My favorites: Composite, Bridge, and Observer Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40
- Slides: 40