Review: Activities and products of System design nonfunctional requirements Analysis Chapter 8: dynamic model Object design: Reusing Pattern Solutions analysis object model class diagram CS 4354 System design Fall 2012 design goals Jill Seaman subsystem decomposition software architecture Object design object design class diagram model 1 2 Object Design: closing the gap Main activities of Object Design System Problem • Reuse: Developers identify off-the-shelf components and design Application objects patterns to make use of existing solutions Chapter 8 Requirements gap • Interface specification: Developers precisely describe class interface(s) to represent each subsystem interface. Solution objects ✦ Chapter 9 Custom objects The subsystem API Object design gap • Restructuring: Developers transform the object design model to improve its understandability and extensibility. Off-the-shelf components ✦In order to meet design goals. Chapter 10 System design gap • Optimization: Developers transform the object design model to address performance criteria. Machine Chapter 10 Object design closes the gap between application objects identified during ✦Such as response time or memory utilization. requirements and off-the-shelf components selected during system design. 3 4 8.3 Reuse Concepts More Reuse Concepts 8.3.1 Application Objects and Solution Objects 8.3.2 Specification Inheritance+Implementation Inheritance • Application Objects, also called “domain objects”, represent • Specification Inheritance is the classification of concepts into concepts of the domain that are relevant to the system. type hierarchies ✦Primarily entity objects, identified during analysis. ✦Conceptually, subclass is a specialization of its superclass. ✦Independent of any system. ✦Conceptually, superclass is a generalization of all of its subclasses. • Solution Objects represent components that do not have a counterpart in the application domain, such as persistent data • Implementation Inheritance is the use of inheritance for the sole stores, user interface objects, or middleware. purpose of reusing code (from the superclass). ✦Includes boundary and control objects, identified during analysis. ✦the generalization/specialization relationship is usually lacking. ✦More solution objects are identified during system design and object ✦example: Set implemented by inheriting from Hashtable design, as part of their proecesses 5 6 Java Hashtable Set • Description: This class implements a hashtable, which maps keys • The interface to be implemented: to values. • Description: A collection that contains no duplicate element. ✦Any non-null object can be used as a key or as a value. • Set methods • Hashtable methods ✦put(element) ✦put(key,element) Adds the specified element to this set if it is not already present Maps the specified key to the specified value in this hashtable. ✦containsValue(element):boolean ✦get(key) : Object Returns true if the element is in the set, else false. Returns the value to which the specified key is mapped, or null if this map contains no mapping for the key. ✦containsKey(key): boolean ✦containsValue(element):boolean 7 8 Set implemented by extending Hashtable Evaluation of the inheritance version • Good: code reuse Hashtable // Set implemented using inheritance • Bad: Set is not a specialization of Hashtable class MySet extends Hashtable { put(key,element) ! MySet() { ... ✦it inherits methods that don’t make sense for it: get(key):Object ! } put(key, element), containsKey() containsKey(key):boolean containsValue(element):boolean ! void put(Object element) { Potential problem: a client class uses these methods on MySet, and then !!if (!containsKey(element)){ MySet is re-implemented by inheriting from some other class (like List). !!!put(element, this); ✦ !!} it doesn’t work as a Hashtable MySet ! } It cannot be used correctly as a special kind of Hashtable (ie passed to a ! boolean containsValue(Object function that takes Hashtable as an argument) put(element) Specifically containsValue() will not work as expected. containsValue(element):boolean !!!element){ !!return containsKey(element); • Liskov Substitution Property: if S is a subclass of T, then objects ! } ! /* Other methods omitted */ of type T may be replaced with objects of type S without altering } any of the desirable properties of the program. [Wikipedia] 9 10 Set implemented using composition/delegation 8.3.3 Delegation • Delegation: A special form of composition Hashtable // Set Implemented using delegation class MySet { ✦One class (A) contains a reference to another (B) (via member variable) private Hashtable table; put(key,element) ✦A implements its operations by calling methods on B. get(key):Object ! MySet() { containsKey(key):boolean (Methods may have different names) containsValue(element):boolean !!table = Hashtable(); table 1 ! } ✦Makes explicit the dependencies between A and B. ! void put(Object element) { 1 !!if (!containsValue(element)){ • Addresses problems of implementation inheritance: MySet !!!table.put(element,this); ✦Extensibility (allowing for change to implementation) !!} Internal representation of A can be changed without impacting clients of A put(element) ! } containsValue(element):boolean (methods of B are not exposed via A like they would be in inheritance) ! boolean containsValue(Object !!!element) { ✦Subtyping !!return A is not a special case of B so it cannot be accidentally used as a special !!(table.containsKey(element)); kind of B. (Does not violate LSP, because it does not apply) ! } } 11 12 8.3.5 Design Patterns Design Patterns • In object-oriented development, Design Patterns are solutions • The following terms are used to describe the class that collaborate that developers have refined over time to solve a range of recurring in a design pattern: problems. ✦The client class access the pattern classes • A design pattern has four elements ✦The pattern interface is the part of the pattern that is visible to the client ✦A name that uniquely identifies the pattern from other patterns. class (might be an interface or abstract class). ✦A problem description that describes the situation in which the pattern ✦The implementor class provides low level behavior of the pattern, usually can be used. [They usually address modifiability and extensibility design more than one. goals.] ✦The extender class specializes an implementor class to provide different ✦A solution stated as a set of collaborating classes and interfaces. implementation of ht pattern. Usually represent future classes anticipated by the developer. ✦A set of consequences that describes the trade-offs and alternatives to be considered with respect to the design goals being addressed. • Tradeoff: Simple architecture vs anticipating change (extensibility) ✦ Agile methods: use refactoring to adopt patterns when need arises 13 14 8.4.1 Encapsulating Data Stores with the Bridge Pattern Example: Abstracting database vendors Name: Bridge Design Pattern • Arena is the client, LeagueStore is the abstraction class Problem Description: Decouple an interface from an implementation so that the two can vary independently. • LeagueStoreImplementor is the common interface for various Solution: Abstraction is visible to the Client. Abstraction maintains a reference implementations of the storage. to its corresponding Implementor instance ✦Stub is for the prototype, XML is for a flat file system, JDBC is for a database. Arena imp LeagueStore LeagueStoreImplementor Stub Store XML Store JDBC Store Implementor Implementor Implementor 15 16 Example: Abstracting database vendors Bridge Pattern example: Shapes • LeagueStore has a different interface from LeagueStoreImplementor /** Implementor */ ✦LeagueStore may provide higher level functions interface DrawingAPI { public void drawCircle(double x, double y, double radius); ✦LeagueStoreImplementor may provide lower level functionality } • LeagueStore can have its own subclasses /** ConcreteImplementor 1/2 */ class DrawingAPI1 implements DrawingAPI { public void drawCircle(double x, double y, double radius) { System.out.printf("API1.circle at %f:%f radius %f\n", x, y, radius); Arena } } imp LeagueStore LeagueStoreImplementor /** ConcreteImplementor 2/2 */ class DrawingAPI2 implements DrawingAPI { public void drawCircle(double x, double y, double radius) { System.out.printf("API2.circle at %f:%f radius %f\n", x, y, radius); } } Stub Store XML Store JDBC Store Implementor Implementor Implementor 17 18 Bridge Pattern example: Shapes Bridge Pattern example: Shapes /** Abstraction */ interface Shape { ! public void draw(); /** Client */ ! public void resizeByPercentage(double pct); public class BridgePattern { } public static void main(String[] args) { Shape[] shapes = new Shape[2]; /** Refined Abstraction */ shapes[0] = new CircleShape(1, 2, 3, new DrawingAPI1()); class CircleShape implements Shape { shapes[1] = new CircleShape(5, 7, 11, new DrawingAPI2()); private double x, y, radius; private DrawingAPI drawingAPI; for (Shape shape : shapes) { shape.resizeByPercentage(2.5); public CircleShape(double x, double y, double radius, shape.draw(); DrawingAPI drawingAPI) { } !!this.x = x; this.y = y; this.radius = radius; } !!this.drawingAPI = drawingAPI; } ! } ! public void draw() { Output: !!drawingAPI.drawCircle(x, y, radius); ! } API1.circle at 1.000000:2.000000 radius 7.500000 ! public void resizeByPercentage(double pct) { API2.circle at 5.000000:7.000000 radius 27.500000 !!radius *= pct; ! } } 19 20 8.4.2 Encapsulating Legacy Components with the Bridge Pattern: consequences Adapter Pattern