ObjectOriented Software Engineering An Agile Unified Methodology by
Object-Oriented Software Engineering: An Agile Unified Methodology by David Kung Chapter 10: Applying Responsibility Assignment Patterns Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Key Takeaway Points • Design patterns are abstractions of proven design solutions to commonly encountered design problems. • The controller, expert, and creator patterns are applicable to almost all objectoriented systems. 10 -2 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying Patterns in the Methodology Context Use case-iteration allocation matrix Business goals & needs Current situation Accommodating Requirements Change Acquiring Requirements (Domain Modeling) Customer feedback Iteration use cases Domain Modeling Preliminary requirements Domain model Deriving Use Cases from Requirements Domain model Actor-System Interaction Modeling Abstract & high level use cases, use case diagrams Expanded use cases & UI design Behavior Modeling & Responsibility Assignment Allocating Use Cases & Subsystems to Iterations Behavior models Use case-iteration allocation matrix Deriving Design Class Diagram Producing an Architecture Design class diagram Software architecture (a) Planning Phase control flow Test Driven Development, Integration, & Deployment (b) Iterative Phase – activities during each iteration data flow control flow & data flow 10 -3 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
What Are Design Patterns? • Design patterns are proven design solutions to commonly encountered design problems. • Each pattern solves a class of design problems. • Design patterns codify software design principles and idiomatic solutions. • Design patterns improve communication among software developers. • Design patterns empower less experienced developers to produce high-quality designs. • Patterns can be combined to solve a large complex design problem. 10 -4 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Example: The Singleton Pattern • Pattern name: Singleton • Design Problem: How do we ensure that a class has only one globally accessible instance? • Example uses: – System configuration class – System log file 10 -5 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Singleton Pattern public class Catalog { private static Catalog instance; private Catalog() {. . . } // private constructor public static Catalog get. Instance() { if (instance==null) instance=new Catalog(); return instance; } // other code } 10 -6 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Example: The Singleton Pattern <<Singleton>> Config -$ instance: Config // other attributes Stereotype shows the pattern name - Config() +$ get. Instance(): Config // other operations if (instance==null) instance=new Config(); return instance; +: public -: private $: static 10 -7 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Describing Patterns • The pattern name conveys the design problem as well as the design solution. • Example: Singleton – How to design a class that has only one globally accessible instance? – The singleton pattern provides a solution. • Pattern description also specifies – benefits of applying the pattern – liabilities associate with the pattern, and – possible trade-offs 10 -8 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
More About Design Patterns • Patterns are recurring designs. • Patterns are not new designs. • Most patterns aim at improving the maintainability of the software system. – easy to understand – easy to change (significantly reduce change impact) • Some patterns also improve efficiency or performance. 10 -9 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Commonly Used Design Patterns • The General Responsibility Assignment Software Patterns (GRASP) • The Gang of Four Patterns due to the four authors of the book. 10 -10 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
GRASP Patterns • • • Expert Creator Controller Low coupling High cohesion • • Polymorphism Pure fabrication Indirection Do not talk to strangers 10 -11 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Gang of Four Patterns • Creational patterns deal with creation of complex, or special purpose objects. • Structural patterns provide solutions for composing or constructing large, complex structures that exhibit desired properties. • Behavioral patterns are concerned with – algorithmatic aspect of a design – assignment of responsibilities to objects – communication between objects 10 -12 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Go. F Patterns Creational Patterns • Abstract factory • Builder • Factory method • Prototype • Singleton Structural Patterns • Adapter • Bridge • Composite • Decorator • Facade • Flyweight • Proxy Behavioral Patterns • Chain of responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template method • Visitor 10 -13 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying GRASP through a Case Study • • • Examine a commonly seen design. Discuss its pros and cons. Apply a GRASP pattern to improve. Discuss how the pattern improves the design. During this process, software design principles are explained. 10 -14 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
A Checkout Sequence Diagram presentation : Checkout. Gui <<call number >> Patron : DBMgr l: Loan msg : = check. Out (call. No: String): String business objects d : = get. Document (call. No: String): Document alt [d!=null] alt GUI is assigned [a] too many responsibilities. a: =is. Available(): boolean create(p: Patron, d: Document) save(l: Loan) save(d: Document) [else] d: Document set. Available(false: boolean ) msg : = “Checkout successful. ” msg : = “Document not available. ” Tight presentation msg : = coupling “Document between not and business found. ” objects 10 -15 <<msg>> Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Problems with This Design • Tight coupling between the presentation and the business objects. • The presentation has been assigned too many responsibilities. • The presentation has to handle actor requests (also called system events). • Implications – Not designing “stupid objects. ” – Changes to one may require changes to the other. – Supporting multiple presentations is difficult and costly. 10 -16 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
A Better Solution • Reduce or eliminate the coupling between presentation and business objects. – the Low Coupling design principle • Remove irrelevant responsibilities from the presentation. – the separation of concerns principle – it achieves high cohesion and – designing “stupid objects” • Have another object (class) to handle actor requests (system events). 10 -17 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Who Should Handle an Actor Request? : Checkout. GUI <<uid, cn. List>> ? msg: =checkout(uid, cn. List): String <<msg>> Assign the responsibility for handling an actor request to a controller. : Checkout. GUI <<uid, cn. List>> : Checkout. Controller msg: =checkout(uid, cn. List): String <<msg>> 10 -18 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Controller Pattern • Actor requests should be handled in the business object layer. • Assign the responsibility for handling an actor request to a controller. • The controller may delegate the request to business objects. • The controller may collaborate with business objects to jointly handle the actor request. 10 -19 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Types of Controller • Use case controller – It handles all actor requests relating to a use case. • A checkout controller handles all actor requests to checkout a document. • Role controller – It represents a role played by an actor (Librarian, Bank Teller). • Facade controller – It represents the overall system (Library System, Banking System). – It represents the organization (Library, Bank). 10 -20 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying the Controller Pattern • Descending Preference: – use case controller – role controller – system controller – organization controller • Applying role controller or facade controller – When there are only a few system events and system will not expand in the future. – It is not possible to handle the actor request by using a use case controller. • example: interlibrary loan 10 -21 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying Use Case Controller • Each use case has its own use case controller: – Checkout Controller for Checkout Use Case – Return Controller for Return Use Case • There is only one controller for each use case. • There is a one-to-one correspondence: – Checkout Use Case, Checkout GUI, Checkout Controller – Login Use Case, Login GUI, Login Controller • The use case controller maintains the state of the use case, and identifies out-of-sequence system events. 10 -22 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Benefits of The Controller Pattern • • Separation of concerns High cohesion Low coupling Supporting multiple interfaces Easy to change and enhance Improving software reusability It can keep track of use case state, and ensure that the correct sequence of events is being handled. 10 -23 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Liabilities of The Controller Pattern • More classes to design, implement, test and integrate. • Need to coordinate the developers who design and implement the UI, controllers and business objects. – This is not a problem when the methodology is followed. • If not designed properly, it may result in bloated controllers. 10 -24 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Bloated Controller • A bloated controller is one that is assigned too many unrelated responsibilities. • Symptoms – There is only one controller to handle many actor requests. • This is often seen with a role controller or a facade controller. – The controller does everything to handle the actor requests rather than delegating the responsibilities to other business objects. – The controller has many attributes to store system or domain information. 10 -25 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Cures to Bloated Controllers • Symptoms – only one controller to process many system events – the controller does all things rather than delegating them to business objects – the controller has many attributes to maintain system or domain information • Cures – replace the controller with use case controllers to handle use case related events – change the controller to delegate responsibilities to appropriate business objects – apply separation of concerns: move the attributes to business objects or other objects 10 -26 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Class Exercise • Complete the sequence diagram for the “Checkout Document” use case. : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout(uid, cn. List): String <<msg>> 10 -27 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
What Should the Checkout Controller Do? : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout (uid, cn. List): String : DBMgr <<get ? >> <<access db>> <<process info>> <<update db>> <<msg>> What should the controller get from the DBMgr? How should the controller process the result? How should the controller update the database? 10 -28 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Conventional Design : Checkout GUI <<uid, call. No>> : Checkout Controller msg: =checkout (uid, call. No): String UML 1. 0 conditional check : DBMgr b 1: =has. Patron (uid): boolean [b 1]: msg: =process (call. No): String b 2: =is. Available (call. No): boolean [b 2] set. Available (call. No, false) [b 2] set. Checkout(uid, call. No) <<msg>> 10 -29 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Problems with the Conventional Design • The database manager has to know a lot of database detail. • The database manager is not “stupid. ” • Responsibilities are not correctly assigned. • It is designed with a procedural programming mindset! • It is not an object-oriented design! 10 -30 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying The Expert Pattern • Expert Pattern: Assign the request to the information expert. – It is the object that stores the information needed to fulfill the request. ? request() Who should handle the request? responsibility Assign the responsibility to the object that has the information to fulfill the request – the object that has an attribute that stores the information. 10 -31 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying The Expert Pattern : Checkout GUI <<uid, call. No>> : Checkout Controller msg: =checkout(uid, call. No): String : DBMgr b 1: =has. Patron (uid): bool [b 1]: process (call. No) Does the DB manager have the attribute to fulfill these? b 2: =is. Available (call. No): boolean [b 2] set. Available (call. No, false) [b 2] set. Checkout (uid, call. No) <<msg>> Who has the information to fulfill this? 10 -32 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying The Expert Pattern : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout(uid, cn. List) : DBMgr l: Loan d: Document u: =get. User(uid): user [u!=null & cn in cn. List]*: msg: = process(cn): String UML 1. 0 notation for loop d: =get. Document(cn): Document a: =is. Available() Controller has the parameters needed to call the constructor of Loan. [a]create(u, d) [a]save(l) [a]set. Available(false) [a]save(d) <<msg>> expert pattern – Document has the attribute 10 -33 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Expert Pattern • It is a basic guiding principle of OO design. • ~70% of responsibility assignments apply the expert pattern. • It is frequently applied during object interaction design – constructing the sequence diagrams. 10 -34 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Benefits of The Expert Pattern • • Low coupling High cohesion Easy to comprehend and change Tend to result in “stupid objects” 10 -35 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Class Exercise Draw a sequence diagram to realize a webbased “reset password” use case: Actor: User System: Web App 0) The system displays a page with a “Reset Password” link. 1) TUCBW the user clicks the 2) The system shows a page “Reset Password” link. requesting the user id. 3) The user enters the user id 4) The system asks an and clicks the Submit button. authentication question. 5) The user enters the answer 6) If authenticated, the system shows a confirmation message. and clicks the OK button. 7) The user sees the confirmation message. 10 -36 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
A Reset Password Sequence Diagram <<JSP>> Reset. PW <<uid>> : Reset. PW Controller q: =get Question(uid): String : DBMgr q: =get. Quest (uid): String <<question q>> <<JSP>> Authen <<answer>> [b]<<success>> [not b]<<fail>> b: =check Ans (answer): boolean b: =check. Ans (answer): boolean What is “wrong” with this design? 10 -37 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Problems with the Design • It assigns get. Quest() and check. Ans() to the wrong object – DBMgr, which does not have the attributes to fulfill the requests. • It does not design “stupid objects. ” • It violates the expert pattern. • It is designed with a conventional mindset. 10 -38 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Applying The Expert Pattern <<JSP>> Reset. PW <<uid>> : Reset. PW Controller q: =get. Question (uid): String <<question>> <<JSP>> Authen <<answer>> msg: =check. Ans (answer): String <<msg>> : DBMgr u: User u: =get. User (uid): User q: =get. Quest(): String User has the information to fulfil these two requests. msg: =check. Ans (answer): String 10 -39 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Creator Pattern • Who should create a given object? : ? ? ? create(. . . ) c: Chapter Who should create a chapter of a book? loan: Loan Who should create a Loan object in a library system? : DBMgr Who should create a DB manager? : Checkout Controller Who should create a checkout controller? 10 -40 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Creator Pattern • Object creation is a common activity in OO design – it is useful to have a general principle for assigning the responsibility. • Assign class B the responsibility to create an object of class A if – B is an aggregate of A objects. – B contains A objects, for example, the dispenser contains vending items. – B records A objects, for example, the dispenser maintains a count for each vending item. – B closely uses A objects. – B has the information to create an A object. 10 -41 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
The Creator Pattern • Who should create these objects? : Book ? : Checkout ? Controller create(. . . ) c: Chapter loan: Loan Because a chapter is a part of a book. Because Checkout Controller has the information to call the constructor of Loan. 10 -42 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
Benefits of The Creator Pattern • Low coupling because the coupling already exists. • Increase reusability. • Related patterns – Low coupling – Creational patterns (abstract factory, factory method, builder, prototype, singleton) – Composite 10 -43 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.
- Slides: 43