Object Design

1. Object Design • Object design • Detail requirements analysis & make implementation decisions • Iterate on placement of operations in the object model • The basis of implementation • Designer implements model to minimize execution time, memory, & other cost measures.

2. Object Design: Closing the Gap Pr oblem System Application objects Requirements gap (1) Solution objects Custom objects Object design gap (3) Off-the-shelf components System design gap (2) Machine

3. Object Design Issues • Full definition of associations • Full definition of classes • Choice of algorithms & data structures • Detect classes that are independent of application-domain (e.g., cache) • Optimization • Increase inheritance

4. Object Design Activities 1. Service specification • Describe precisely each class interface 2. Component selection • Identify off-the-shelf components 3. Object model restructuring • Improve object design’s understandability & reusability 4. Object model optimization • Improve object design with respect to performance criteria • E.g., response time &memory utilization.

5. Service Specification • Requirements analysis • Identify attributes & operations without types or parameters. • Object design • Specify visibility • Specify type signature • Specify contracts • pre & post conditions.

6. Add Visibility UML defines 3 levels of visibility: • Private • Attribute can be accessed only by the class in which it is defined. • Operation can be invoked only by the class in which it is defined. • Attributes & operations cannot be accessed by subclasses. • Protected • Same as Private access + any extension of the class. • Public • Attribute or operation can be accessed by any class.

7. Information Hiding Heuristics • Apply “Need to know” principle. • The less an operation knows • the less likely it is affected by a change in another class • the less likely a change affects another class. • Information hiding vs efficiency • Possible that efficiency is not lost due to smart compilation.

8. Information Hiding Design Principles • Book says: All data members are private. • Never use package or protected? • This may be extreme or purist. • Book says: Do not apply an operation to the result of another operation. • Write a new operation that combines the 2 operations. • This seems to me to be a bad idea: makes for entangled methods.

9. Add Type Signature Information Hashtable -numElements:int BEFORE +put() +get() +remove() +containsKey() +size() AFTER

10. Contracts • Class definer & client share assumptions via a contract. • Contracts include 3 types of constraints: • Invariant • A predicate that is true for all instances of the class. • A constraint associated with classes or interfaces. • Precondition • A predicate that must be true before a specific operation is invoked. • Typically, it involves constraints on arguments or the object’s state. • Postcondition • A predicate that must be true after an operation is invoked. • Typically, it involves constraints on modified arguments or the object’s state.

11. Expressing constraints in UML • OCL (Object Constraint Language) • OCL: constraints on [groups of] model element[s]. • A constraint is an OCL expression returning true or false. • Not a procedural language (no control flow). • OCL expressions for Hashtable put(): • Invariant • context Hashtable inv: numElements >= 0 • Precondition • context Hashtable::put(key, entry) pre:!containsKey(key) • Post-condition • context Hashtable::put(key, entry) post: containsKey(key) and get(key) = entry

12. Expressing Constraints in UML • A constraint also can be depicted as a note attached to the UML element. <<invariant>> numElements >= 0 HashTable <<precondition>> <<postcondition>> numElements:int !containsKey(key) get(key) == entry put(key,entry:Object) get(key):Object <<precondition>> remove(key:Object) containsKey(key) containsKey(key:Object):boolean size():int

13. Object Design Activities 1. Service specification • Describe precisely each class interface 2.Component selection • Identify off-the-shelf components 3. Object model restructuring • Improve object design’s understandability & reusability 4. Object model optimization • Improve object design with respect to performance criteria • E.g., response time &memory utilization.

14. Component Selection • Select existing off-the-shelf libraries of • Classes (e.g., JFC) • Frameworks (e.g., Java Mail) • Components (e.g., An EJB) • Adjust the class libraries, framework, or components • Adjust the API, if you have the source code. • Use an adapter or bridge pattern, if you don’t.

15. Object Design Activities 1. Service specification • Describe precisely each class interface 2. Component selection • Identify off-the-shelf components 3. Object model restructuring • Improve object design’s understandability & reusability 4. Object model optimization • Improve object design with respect to performance criteria • E.g., response time &memory utilization.

16. Restructuring Activities • Revise inheritance to remove implementation dependencies • E.g., Look & Feel • Factor out common aspects of groups of classes • Overload to create abstract class from several concrete classes. • Abstract classes increase • Modularity • Extensibility • Reusability

17. Implement Associations • Be as uniform as possible • 1-to-1 association • Role names are attributes • 1-to-many association • Translate to Vector

18. 1-to-Many Association Object design model before transformation Layer LayerElement 1 * Object design model after transformation Layer LayerElement -layerElements:Set -containedIn:Layer +elements() +getLayer() +addElement(le) +setLayer(l) +removeElement(le)

19. Object Design Activities 1. Service specification • Describe precisely each class interface 2. Component selection • Identify off-the-shelf components 3. Object model restructuring • Improve object design’s understandability & reusability 4. Object model optimization • Improve object design with respect to performance criteria • E.g., response time &memory utilization.

20. Design Optimizations • The requirements analysis model may be too inefficient. • Strike a balance between efficiency & clarity. • Optimization makes your model more obscure • Optimization activities during object design: • Turn classes into attributes 2. Cache derived attributes to omit re-computation

21. SocialSecurity Person ID:String Person SSN:String Optimization: Collapse Classes

22. To Collapse or not to Collapse? • Collapse a class into attributes when the only operations defined on the attributes are: • set() • get().

23. Design Optimizations … • Cache derived attributes • Derived attributes must be updated when base attribute values change. • Explicit code • Base attribute changer re-computes derived attributes. • Event notification • Objects that must re-derive attribute register interest in changes. • Base attribute notifies objects when it changes.

24. Image filename:String data:byte[] width() height() paint() Image filename:String width() height() paint() image RealImage ImageProxy 1 0..1 filename:String data:byte[] width() width() height() height() paint() paint() Optimize: Lazy Evaluation (Proxy Pattern) • Image may never be displayed • Attributes may change more • frequently than need to display

25. The Object Design Document (ODD) • Independent ODD • Redundant with RAD  consistency problem. • ODD as supplement to RAD • An optional more detailed view • Ok, if there is a CASE tool to support this. • Javadoc as an ODD.

26. ODD Conventions • Each subsystem provides a service (interface) • The operations provided by the subsystem • Specify a service operation as • Signature • Operation name, fully typed parameter list, & return type • Abstract: Describes the operation • Pre: Precondition for invoking the operation • Post: Postcondition describing subsystem state after the operation • Use JavaDoc to specify services • Treat subsystems simply as a Java interfaces.

27. JavaDoc • A doc comment consists of characters between /** & */ • When JavaDoc parses a doc comment, leading white space & ‘*’ characters on each line are discarded. • Doc comments may include HTML tags • Example of a doc comment: /** * This is a <b> doc </b> comment */ • One expects an XML generalization of this. Doclets.

28. Java Doc … • Doc comments are recognized only when placed immediately before class, interface, constructor, method, or field declarations. • When using HTML tags, do not use heading tags • E.g., <h1> and <h2> • It causes a parse error.

29. Class & Interface Doc Tags @author name-text • Creates an “Author” entry. @version version-text • Creates a “Version” entry. @see classname • Creates a hyperlink “See Also classname” @since since-text • Adds a “Since” entry. • Usually specifies that a feature or change exists since the release number specified in the “since-text” @deprecated deprecated-text • Adds a comment that this method can no longer be used. Convention is to describe method that serves as replacement • Example: @deprecated Replaced by setBounds(int, int, int, int).

30. Constructor & Method Doc Tags • Can contain @see tag, @since tag, @deprecated @param parameter-name description Adds a parameter to the "Parameters" section. The description may be continued on the next line. @return description Adds a "Returns" section, which contains the description of the return value. @exception fully-qualified-class-name description Adds a "Throws" section that has the name of the exception that may be thrown by the method. The exception is linked to its class documentation. @see classname Adds a hyperlink "See Also" entry to the method.

31. Example of a Class Doc Comment /** * A class representing a window on the screen. * For example: * <pre> * Window win = new Window(parent); * win.show(); * </pre> * * @author Sami Shaio * @version 1.3.1 * @see java.awt.BaseWindow * @see java.awt.Button */ class Window extends BaseWindow { … }

32. Example of a Method Doc Comment /** * Returns the character at the specified index. An index * ranges from <code>0</code> to <code>length() - 1</code>. * * @param index the index of the desired character. * @return the desired character. * @exception StringIndexOutOfRangeException * if the index is not in the range <code>0</code> * to <code>length()-1</code>. * @see java.lang.Character#charValue() */ public char charAt(int index) { ... }

33. Example of a Field Doc Comment • A field comment can contain only the @see, @since & @deprecated tags /** * The X-coordinate of the window. * * @see window#1 */ int x = 1263732;

34. Example: Specifying a Service in Java /** Office is a physical structure in a building. It is possible to create an office; add an occupant; get the name of the office */ public interface Office { /** Adds an occupant to the office * @param NAME name is a nonempty string */ public void addOccupant(string name); /** @Return Returns the name of the office. Requires that Office has been initialized with a name */ public string getName(); }

35. Implementation of Application Domain Classes • New objects are often needed during object design: • Use of Design patterns lead to new classes • The implementation of algorithms may necessitate objects to hold values • New low-level operations may be needed during the decomposition of high-level operations • Example: The EraseArea() operation offered by a drawing program. • Conceptually very simple • Implementation • Area represented by pixels • Repair () cleans up objects partially covered by the erased area • Redraw() draws objects uncovered by the erasure • Draw() erases pixels in background color not covered by other objects

36. Summary • Object design • add details to the requirements analysis • make implementation decisions • Object design includes 1. Service specification 2. Component selection 3. Object model restructuring 4. Object model optimization • Use tools such as JavaDoc for the ODD