1. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Object Design: Closing the Gap Custom objects Application objects Off-the-shelf components Solution objects System Problem Machine System design gap (2) Object design gap (3) Requirements gap (1)

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Add Type Signature Information Hashtable +put() +get() +remove() +containsKey() +size() -numElements:int BEFORE AFTER

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Expressing Constraints in UML  A constraint also can be depicted as a note attached to the UML element. HashTable put(key,entry:Object) get(key):Object remove(key:Object) containsKey(key:Object):boolean > numElements >= 0 > !containsKey(key) > containsKey(key) > get(key) == entry size():int numElements:int

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Implement Associations  Be as uniform as possible  1-to-1 association  Role names are attributes  1-to-many association  Translate to Vector

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 1-to-Many Association LayerLayerElement 1* LayerLayerElement -containedIn:Layer-layerElements:Set +elements() +addElement(le) +getLayer() +setLayer(l) +removeElement(le) Object design model beforetransformation Object design model after transformation

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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: 1.Turn classes into attributes 2. Cache derived attributes to omit re-computation

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Optimization: Collapse Classes Person SocialSecurity ID:String Person SSN:String

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 To Collapse or not to Collapse?  Collapse a class into attributes when the only operations defined on the attributes are:  set()  get().

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Optimize: Lazy Evaluation (Proxy Pattern) Image filename:String width() height() paint() Image filename:String width() height() paint() RealImage width() height() paint() data:byte[] ImageProxy filename:String width() height() paint() image 10..1 Image may never be displayed Attributes may change more frequently than need to display

25. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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 doc comment */  One expects an XML generalization of this. Doclets.

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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., and  It causes a parse error.

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Example of a Class Doc Comment /** * A class representing a window on the screen. * For example: * * Window win = new Window(parent); * win.show(); * * @author Sami Shaio * @version 1.3.1 * @see java.awt.BaseWindow * @see java.awt.Button */ class Window extends BaseWindow { … }

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Example of a Method Doc Comment /** * Returns the character at the specified index. An index * ranges from 0 to length() - 1. * * @param index the index of the desired character. * @return the desired character. * @exception StringIndexOutOfRangeException * if the index is not in the range 0 * to length()-1. * @see java.lang.Character#charValue() */ public char charAt(int index) {... }

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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