6 - Object Design and Patterns v1

6 - Object Design and Patterns v1 - Object Design and...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Object Design and Patterns Topics 1.  2.  3.  4.  5.  6.  Object Design Finding Objects Commonality Variability Analysis Design for Reusability Design for Changes Design Patterns 2 1. Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions.   The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost.   Object design serves as the basis of implementation.   3 Object Design (cont.)   Requirement analysis o  Identify domain objects o  System is described in terms of external behavior   System design o  Identify design goals o  Design system decomposition to address functional and nonfunctional requirement   Object design o  Objectives o  Identify new solution objects o  Adjust off-the-shelf components o  Precisely specify each subsystem interface and class o  Activities o  Reuse o  Interface specification o  Restructuring o  Optimization 4 2. Finding Objects   Two types of objects o  Domain (application) objects o  Represent concepts of the domain that are relevant to the system o  Solution (software, design) objects o  Represent software components, e.g., persistent data stores, user interface objects, or middleware. 5 Techniques for Finding Domain Objects   Requirements analysis o  Use domain (application, customer) language o  Explore business models and use cases to identify participating domain objects o  Perform textual analysis of flow of events (find nouns, verbs, ...) o  Find domain objects by using general knowledge, interviewing clients, and demonstrating GUI prototypes o  Discover entity objects that are application objects and independent of any specific system o  Identify solution objects that are visible to the actor, e.g., boundary and control objects representing forms and transactions 6 Techniques for Finding Solution Objects (cont.)   System Design o  Perform subsystem decomposition o  Identify layers and partitions o  Identify new solution objects   Object Design o  Find additional software objects by implementing domain knowledge o  Find additional software objects by performing commonality variability analysis o  Find additional software objects by incorporating design patterns 7 How Do We Design Application Logic with Objects?   Create software objects with names and information similar to the real-world domain   Assign application logic responsibilities to them 8 Domain Model and Design Model 9 3. Commonality Variability Analysis   Commonality analysis o  o  o  o    Relates to the conceptual view of the problem domain Seeks structure that is unlikely to change overtime Gives the architecture its longevity Initiates the representation of common concepts by abstract classes Variability analysis o  o  o  o  Relates to the implementation, i.e., to specific cases Captures structure that is likely to change Drives the architecture fitness for use Initiates the implementation of variations by concrete classes 10 Commonality Variability Analysis (cont.) Analysis Perspectives Conceptual Commonality AbstractClass +operation() Specification Variability ConcreteClass Implementation ConcreteClass +operation() +operation() 11 Specification   Specification o  Describes conceptually similar objects o  Becomes an abstract class or an interface at the implementation level By looking at what a set of objects must do (conceptual perspective), we determine how to call them (specification perspective)   When implementing these classes, ensure that the API provides sufficient information to enable proper implementation and decoupling   12 Specification (cont.)   When defining an abstract class, ask What interface is needed to handle all of the responsibilities of this class?   When defining derived classes, ask o  Given this particular variation, how can I implement it with the given specification? 13 A Partial Business Process Contact Information Lead [Raw] Manage Lead Request for Quotation Product/Service Information Manage Opportunity Opportunity [Raw] Lead Management Rules Rule Setting Criteria Quotation Contract [Raw] Opportunity Management Rules Manage Rule Contract Management Rules Manage Contract Contract [Final] Contract Concerns 14 A Business Subprocess Lead [Raw] Import Lead Lead [Imported] Assign Lead Lead Assignment Rules Lead [Assigned] Contact Information Lead Qualification Rules Qualify Lead Opportunity [Raw] Lead [Unique] Merge Lead Lead Merging Rules 15 Processes, Use Cases, and Commonality Marketing System Other Systems* Sales Management System Manage Lead Raw lead Manage Opportunity Manage Contract Raw opportunity Raw contract Import raw opportunity Import raw contract Qualify lead‡ Qualify opportunity‡ Approve contract‡ (Loop) Raw opportunity Raw contract Final contract Final contract Import raw lead Assign lead‡ Merge lead‡ Raw lead * Accounting, ERP, SCM, legal, etc. ‡ Acquire applicable rules 16 Business process diagram Contact Information Lead [Raw] Process Lead Request for Quotation Product/Service Information Process Opportunity Opportunity [Raw] Lead Management Rules Rule Setting Criteria Quotation Contract [Raw] Opportunity Management Rules Manage Rule Contract Management Rules Process Contract Contract [Final] Contract Concerns 17 Business subprocess diagram Additional Contract Information Contract [Raw] Import Contract Contract [Imported] Contract [Draft] Finalize Contract Contract [Final] Contract [Approved] Contract Rules Prepare Contract Contract [Denied] Approve Contract Opportunity [Raw] Approval Rules 18 Processes, Use Cases, and Commonality Marketing System Other Systems* Sales Management System Manage Lead Raw lead Manage Opportunity Manage Contract Raw opportunity Import opportunity Final contract Raw contract Import contract Import lead Assign lead‡ Merge lead‡ Prepare contract Qualify lead‡ Qualify opportunity‡ Approve contract‡ Loop Finalize contract Raw lead Raw opportunity Raw contract Final contract * Accounting, ERP, SCM, legal, etc. ‡ Acquire applicable rules 19 Processes, Use Cases, and Commonality Other Marketing System Sales Management System Commonality Flow Import item In Systems* Manage Lead Manage Opportunity Manage Contract Raw lead Raw opportunity Import raw lead Import raw opportunity Final contract Raw contract Import raw contract Assign lead‡ Assign item Merge assigned leads to unique lead‡ Merge item Produce reviewable lead Qualify lead ‡ Produce approvable quote Approve quote ‡ Prepare draft contract Approve draft contract Produce item ‡ Convert qualified lead to raw opportunity Raw lead Convert approved quote to raw contract Convert approved contract to final contract Raw opportunity Raw contract Final contract Loop Approve item Finalize item Out * Accounting, ERP, SCM, legal, etc. ‡ Acquire applicable rules 20 Processes, Use Cases, and Commonality Other Marketing System Sales Management System Commonality Flow In Systems* Manage Lead Manage Opportunity Manage Contract Final contract Raw lead Raw opportunity Raw contract Import raw lead Import raw opportunity Import raw contract Import item Assign lead‡ Assign raw opportunity Assign raw contract Assign item Merge assigned leads to unique lead‡ Merge assigned opportunities to unique opportunity Merge assigned contract to unique contract Merge item Update unique lead with addition info Update unique opportunity with additional info Update unique contract with additional info Update item Produce reviewable lead Produce approvable quote Produce draft contract Produce item Qualify lead‡ Approve quote‡ Approve draft contract‡ AppEvaluate item Convert qualified lead to raw opportunity Convert approved quote to raw contract Convert approved contract to final contract Convert item Raw contract Final contract RawAccounting, ERP, SCM, legal, etc. Raw opportunity * lead ‡ Acquire applicable rules Loop Out 21 4. Design for Reusability   Main goal of reuse o  Reuse knowledge from previous experience to current problem o  Reuse functionality already available   Three ways to get new functionality o  Interface inheritance o  Implementation inheritance o  Delegation 22 Interface Inheritance vs. Implementation Inheritance Interface inheritance describes when different types of objects can be used in place of each other Implementation inheritance defines an object’s implementation in terms of the implementation of another Table HashTable +putAt() +removeAt() +putAt() +removeAt() HashTable BTree +putAt() +removeAt() +putAt() +removeAt() Set +add() +remove() 23 Delegation     Delegation is a way of making composition as powerful for reuse as inheritance In delegation, two objects are involved in handling a request o  A receiving object delegates operations to its delegate o  The developer makes sure that the receiving object does not allow the client to misuse the delegate object Client Receiver Delegates to Delegate 24 Implementation Inheritance vs. Delegation Hashtable put(key,element) get(key):Object containsKey(key):boolean containsValue(element):boolean Hashtable put(key,element) get(key):Object containsKey(key):boolean containsValue(element):boolean table MySet put(element) containsValue(element):boolean MySet put(element) containsValue(element):boolean 25 Implementation Inheritance vs. Delegation /* Implementation of MySet using inheritance */ class MySet extends Hashtable { /* Constructor omitted */ MySet() { } void put(Object element) { if (!containsKey(element)){ put(element, this); } } boolean containsValue(Object element){ return containsKey(element); } /* Other methods omitted */ } /* Implementation of MySet using delegation */ class MySet { private Hashtable table; MySet() { table = Hashtable(); } void put(Object element) { if (!containsValue(element)){ table.put(element,this); } } boolean containsValue(Object element) { return (table.containsKey(element)); } /* Other methods omitted */ } 26 Delegation Instead of Inheritance What happens if the Stack user calls remove() instead of pop()? List List +add() +remove() +add() +remove() Stack Stack +push() +pop() +top() +push() +pop() +top() 27 5. Design for Changes   Two mandates o Find what varies and encapsulate it. o Favor delegation over implementation inheritance.   Consider what you want to be able to change without redesign   Focus on encapsulating the concept that varies   Contains each variation in its own abstract classes, thereby allowing for future variations without affecting code   “Closed for modification, but open for extension” 28 Encapsulation Promotes Low Coupling   Encapsulate the concepts that varies   Hide classes using abstract classes   Using composition of a reference to an abstract class hides the variations   Use encapsulation to create layers between objects   Enables the designer to change things on different sides of the layers independently 29 Two Views of an Object   Traditional view o  An object is data with methods o  Implementation perspective   New view o  An object is an entity with responsibilities o  Conceptual perspective 30 Two Views of Encapsulation   Traditional view o  Data hiding   New view o  Encapsulation of data, methods, subclasses, and other objects 31 Two Views of Inheritance   Traditional view o  For reuse. o  Specialization/generalization   New view o  Think concrete classes as a whole o  Design to an interface 32 6. Design Patterns   Provide template solutions to a recurring design problem o  Look before re-inventing the wheel just one more time   Provide reusable design knowledge o  Higher level than classes or data structures (link lists, binary trees,, etc.) o  Lower level than application frameworks   Provide examples of modifiable designs o  Learning to design starts by studying other designs   Provide a shared vocabulary to designers 33 Observation by the Gang of Four (GoF) Strict modeling of the real world leads to a system that reflects today’s realities but not necessarily tomorrow’s   There is a need for reusable and flexible designs   Design knowledge complements domain knowledge and implementation knowledge   Think about tomorrow! 34 Design Patterns: Mechanisms   Design patterns incorporate o  delegation o  interface inheritance o  recursion   Design patterns decouple the interface of a subsystem from its actual implementation 35 GoF Patterns   Creational Patterns o  o  o  o  o    Abstract Factory Builder Factory Method Prototype Singleton Structural Patterns o  o  o  o  o  o  o  Adapter Bridge Composite Decorator Facade Flyweight Proxy   Behavioral Patterns o  o  o  o  o  o  o  o  o  o  o  Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor 36 Design Patterns Categories: Motivations   Creational Patterns o  Abstract the instantiation process o  Make a system independent from the way its objects are created, composed and represented   Structural Patterns o  Reduce the coupling between two or more classes o  Introduce an abstract class to enable future extensions o  Encapsulate complex structures   Behavioral Patterns o  Deal with algorithms and the assignment of responsibilities between objects o  Characterize complex control flow that is difficult to follow at runtime 37 Design Patterns Categories: Focus & Problems Solved   Creational Patterns o  Focus: Creation of complex objects o  Problems solved: o  Hide how complex objects are created and put together   Structural Patterns o  Focus: How objects are composed to form larger structures o  Problems solved: o  Realize new functionality from old functionality, o  Provide flexibility and extensibility   Behavioral Patterns o  Focus: Algorithms and the assignment of responsibilities to objects o  Problem solved: o  Too tight coupling to a particular algorithm 38 Why Study Design Patterns?                 Reuse existing, high-quality solutions to commonly recurring problems Establish common terminology to improve communication within teams Shift the level of thinking to higher perspective Decide whether I have the right design, not just one that works Improve individual learning and team learning Improve the modifiability of code Facilitate adoption of improved design alternatives, even when patterns are not use explicitly Discover alternatives to large inheritance hierarchies 39 Details and Themes Design patterns mesh and overlap   Selecting the right pattern is not trivial   Design patterns must be refined   There are hundreds of published design patterns   Most more complex or specialized patterns can be analyzed in terms of basic families   Understanding their underlying basic themes helps us to cut through the myriad details   40 Art is the imposing of a pattern on experience, and our aesthetic enjoyment in recognition of the pattern. Alfred North Whitehead, 1943 41 References Gamma, E., Helm, R., Johnson, R., and Vlissides J., Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995   Kerievsky, I., Refactoring to Patterns, Addison -Wesley, 2005   Metsker, J. and Wake, W., Design Pattern in Java, Addison-Wesley, 2006   Shalloway, A., Design Patterns Explained, 2nd edition, Addison-Wesley, 2005   42 ...
View Full Document

This note was uploaded on 03/03/2010 for the course CMPE 133 taught by Professor Fayad,m during the Spring '08 term at San Jose State.

Ask a homework question - tutors are online