Object Design Object design w Detail requirements analysis
Object Design ¨ Object design w Detail requirements analysis & make implementation decisions w Iterate on placement of operations in the object model w The basis of implementation ¨ Designer implements model to minimize execution time, memory, & other cost measures. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1
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) Bernd Bruegge & Allen Dutoit Machine Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Object Design Issues ¨ Full definition of associations ¨ Full definition of classes ¨ Choice of algorithms & data structures ¨ Detect classes that are independent of applicationdomain (e. g. , cache) ¨ Optimization ¨ Increase inheritance Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3
Object Design Activities 1. Service specification w Describe precisely each class interface 2. Component selection w Identify off-the-shelf components 3. Object model restructuring w Improve object design’s understandability & reusability 4. Object model optimization w Improve object design with respect to performance criteria t E. g. , response time &memory utilization. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
Service Specification ¨ Requirements analysis w Identify attributes & operations without types or parameters. ¨ Object design w Specify visibility w Specify type signature w Specify contracts t pre & post conditions. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
Add Visibility UML defines 3 levels of visibility: ¨ Private w Attribute can be accessed only by the class in which it is defined. w Operation can be invoked only by the class in which it is defined. w Attributes & operations cannot be accessed by subclasses. ¨ Protected w Same as Private access + any extension of the class. ¨ Public w Attribute or operation can be accessed by any class. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
Information Hiding Heuristics ¨ Apply “Need to know” principle. w The less an operation knows ¨ t the less likely it is affected by a change in another class t the less likely a change affects another class. Information hiding vs efficiency w Possible that efficiency is not lost due to smart compilation. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
Information Hiding Design Principles ¨ Book says: All data members are private. w Never use package or protected? t ¨ This may be extreme or purist. Book says: Do not apply an operation to the result of another operation. w Write a new operation that combines the 2 operations. w This seems to me to be a bad idea: makes for entangled methods. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
Add Type Signature Information Hashtable -num. Elements: int +put() +get() +remove() +contains. Key() +size() BEFORE AFTER Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
Contracts ¨ Class definer & client share assumptions via a contract. ¨ Contracts include 3 types of constraints: ¨ Invariant w A predicate that is true for all instances of the class. w A constraint associated with classes or interfaces. ¨ Precondition w A predicate that must be true before a specific operation is invoked. w Typically, it involves constraints on arguments or the object’s state. ¨ Postcondition w A predicate that must be true after an operation is invoked. w Typically, it involves constraints on modified arguments or the object’s state. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
Expressing constraints in UML ¨ OCL (Object Constraint Language) w OCL: constraints on [groups of] model element[s]. w A constraint is an OCL expression returning true or false. w Not a procedural language (no control flow). ¨ OCL expressions for Hashtable put(): w Invariant t context Hashtable inv: num. Elements >= 0 w Precondition t context Hashtable: : put(key, entry) pre: !contains. Key(key) w Post-condition t context Hashtable: : put(key, entry) post: contains. Key(key) and get(key) = entry Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11
Expressing Constraints in UML ¨ A constraint also can be depicted as a note attached to the UML element. <<invariant>> num. Elements >= 0 Hash. Table <<precondition>> !contains. Key(key) <<precondition>> contains. Key(key) Bernd Bruegge & Allen Dutoit num. Elements: int put(key, entry: Object) get(key): Object remove(key: Object) contains. Key(key: Object): boolean size(): int Object-Oriented Software Engineering: Conquering Complex and Changing Systems <<postcondition>> get(key) == entry 12
Object Design Activities 1. Service specification w Describe precisely each class interface 2. Component selection w Identify off-the-shelf components 3. Object model restructuring w Improve object design’s understandability & reusability 4. Object model optimization w Improve object design with respect to performance criteria t E. g. , response time &memory utilization. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
Component Selection ¨ Select existing off-the-shelf libraries of w Classes (e. g. , JFC) w Frameworks (e. g. , Java Mail) w Components (e. g. , An EJB) ¨ Adjust the class libraries, framework, or components w Adjust the API, if you have the source code. w Use an adapter or bridge pattern, if you don’t. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
Object Design Activities 1. Service specification w Describe precisely each class interface 2. Component selection w Identify off-the-shelf components 3. Object model restructuring w Improve object design’s understandability & reusability 4. Object model optimization w Improve object design with respect to performance criteria t E. g. , response time &memory utilization. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
Restructuring Activities ¨ Revise inheritance to remove implementation dependencies w E. g. , Look & Feel ¨ Factor out common aspects of groups of classes w Overload to create abstract class from several concrete classes. ¨ Abstract classes increase w Modularity w Extensibility w Reusability Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16
Implement Associations ¨ Be as uniform as possible ¨ 1 -to-1 association w Role names are attributes ¨ 1 -to-many association w Translate to Vector Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
1 -to-Many Association Object design model before transformation Layer 1 * Layer. Element Object design model after transformation Layer. Element -layer. Elements: Set +elements() +add. Element(le) +remove. Element(le) Bernd Bruegge & Allen Dutoit -contained. In: Layer +get. Layer() +set. Layer(l) Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18
Object Design Activities 1. Service specification w Describe precisely each class interface 2. Component selection w Identify off-the-shelf components 3. Object model restructuring w Improve object design’s understandability & reusability 4. Object model optimization w Improve object design with respect to performance criteria t E. g. , response time &memory utilization. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19
Design Optimizations ¨ The requirements analysis model may be too inefficient. ¨ Strike a balance between efficiency & clarity. w Optimization makes your model more obscure ¨ Optimization activities during object design: 1. Turn classes into attributes 2. Cache derived attributes to omit re-computation Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20
Optimization: Collapse Classes Social. Security Person ID: String Person SSN: String Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21
To Collapse or not to Collapse? ¨ Collapse a class into attributes when the only operations defined on the attributes are: w set() w get(). Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22
Design Optimizations … ¨ Cache derived attributes ¨ Derived attributes must be updated when base attribute values change. ¨ Explicit code w Base attribute changer re-computes derived attributes. ¨ Event notification w Objects that must re-derive attribute register interest in changes. w Base attribute notifies objects when it changes. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23
Optimize: Lazy Evaluation (Proxy Pattern) Image filename: String data: byte[] width() height() paint() • Image may never be displayed • Attributes may change more frequently than need to display Image filename: String width() height() paint() Image. Proxy filename: String width() height() paint() Bernd Bruegge & Allen Dutoit image 1 0. . 1 Real. Image data: byte[] width() height() paint() Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24
The Object Design Document (ODD) ¨ Independent ODD w Redundant with RAD consistency problem. ¨ ODD as supplement to RAD w An optional more detailed view w Ok, if there is a CASE tool to support this. ¨ Javadoc as an ODD. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25
ODD Conventions ¨ Each subsystem provides a service (interface) w The operations provided by the subsystem ¨ Specify a service operation as w Signature t Operation name, fully typed parameter list, & return type w Abstract: Describes the operation w Pre: Precondition for invoking the operation w Post: Postcondition describing subsystem state after the operation ¨ Use Java. Doc to specify services ¨ Treat subsystems simply as a Java interfaces. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26
Java. Doc ¨ ¨ A doc comment consists of characters between /** & */ When Java. Doc 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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
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 w E. g. , <h 1> and <h 2> w It causes a parse error. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28
Class & Interface Doc Tags @author name-text w Creates an “Author” entry. @version-text w Creates a “Version” entry. @see classname w Creates a hyperlink “See Also classname” @since-text w Adds a “Since” entry. w Usually specifies that a feature or change exists since the release number specified in the “since-text” @deprecated-text w Adds a comment that this method can no longer be used. Convention is to describe method that serves as replacement w Example: @deprecated Replaced by set. Bounds(int, int). Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29
Constructor & Method Doc Tags Can contain @see tag, @since tag, @deprecated @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. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30
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. Base. Window * @see java. awt. Button */ class Window extends Base. Window {… } Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31
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 String. Index. Out. Of. Range. Exception * if the index is not in the range <code>0</code> * to <code>length()-1</code>. * @see java. lang. Character#char. Value() */ public char. At(int index) {. . . } Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
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; Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33
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 add. Occupant(string name); /** @Returns the name of the office. Requires that Office has been initialized with a name */ public string get. Name(); Bernd Bruegge & Allen Dutoit } Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34
Implementation of Application Domain Classes ¨ New objects are often needed during object design: w Use of Design patterns lead to new classes w The implementation of algorithms may necessitate objects to hold values w New low-level operations may be needed during the decomposition of high-level operations ¨ Example: The Erase. Area() operation offered by a drawing program. w Conceptually very simple w Implementation t t 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 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35
Summary ¨ Object design w add details to the requirements analysis w make implementation decisions ¨ Object design includes 1. Service specification 2. Component selection 3. Object model restructuring 4. Object model optimization ¨ Use tools such as Java. Doc for the ODD Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36
- Slides: 36