Chapter 7, Object design is the process of adding details to the - PDF document

✍ ✞ ☞ ✌ ✍ ✏ ✔ ✞ ✒ ✍ ✚ ✛ ☎ ✜ ☞ ✞ ✕ ✞ ✒ ✚ ✣ ✤ ✍ ✁ ✞ ✎ ✔ ✒ ✚ ✟ ✔ ✄ Object Design Chapter 7, ● Object design is the process of adding details to the Object Design 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. ● Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model ● Object Design: We iterate on where to put these operations in the object model ● Object Design serves as the basis of implementation 15-ObjectDesign 1 2 15-ObjectDesign Object Design: Closing the Object Design Issues Gap �✂✁ ☎✝✆ System ● Full definition of associations Application objects ● Full definition of classes ✢✘✞ ✟✥✞ ✗✓✡ ● Choice of algorithms and data structures ● Detection of new application-domain Solution objects independent classes (example: Cache) Custom objects ✗✝✎✘✗✙✡ ● Optimization ● Increase of inheritance Off-the-shelf components ● Decision on control ✑✓✒ ✟✖✕✝✞ ✗✝✎✘✗✙✡ ● Packaging 3 4 15-ObjectDesign ✠☛✡ ✎✝✞ 15-ObjectDesign Terminology of Activities Object Design Activities ● Object-Oriented Methodologies ■ System Design 1. Service specification ◆ Decomposition into subsystems ■ Describes precisely each class interface ■ Object Design 2. Component selection ◆ Implementation language chosen ■ Identify off-the-shelf components and additional solution objects ◆ Data structures and algorithms chosen 3. Object model restructuring ● SA/SD uses different terminology: ■ Transforms the object design model to improve its ■ Preliminary Design understandability and extensibility ◆ Decomposition into subsystems 4. Object model optimization ◆ Data structures are chosen ■ Transforms the object design model to address performance ■ Detailed Design criteria such as response time or memory utilization. ◆ Algorithms are chosen ◆ Data structures are refined ◆ Implementation language is chosen ◆ Typically in parallel with preliminary design, not separate stage 6 15-ObjectDesign 1

Service Specification Add Visibility UML defines three levels of visibility: ● Requirements analysis ● Private: ■ Identifies attributes and operations without specifying ■ A private attribute can be accessed only by the class in which it is their types or their parameters. defined. ● Object design ■ A private operation can be invoked only by the class in which it is defined. ■ Add visibility information ■ Private attributes and operations cannot be accessed by ■ Add type signature information subclasses or other classes. ● Protected: ■ Add contracts ■ A protected attribute or operation can be accessed by the class in which it is defined and on any descendent of the class. ● Public: ■ A public attribute or operation can be accessed by any class. 7 8 15-ObjectDesign 15-ObjectDesign Information Hiding Design Information Hiding Heuristics Principles ● Build firewalls around classes ● Only the operations of a class are allowed to manipulate its attributes ■ Carefully define public interfaces for classes as well as ■ Access attributes only via operations. subsystems ● Hide external objects at subsystem boundary ● Apply “Need to know” principle. The fewer an ■ Define abstract class interfaces which mediate between system operation knows and external world as well as between subsystems ■ the less likely it will be affected by any changes ● Do not apply an operation to the result of another operation. ■ the easier the class can be changed ■ Write a new operation that combines the two operations. ● Trade-off ■ Information hiding vs efficiency 9 10 15-ObjectDesign 15-ObjectDesign Add Type Signature Contracts Information ● Contracts on a class enable caller and callee to share the Hashtable same assumptions about the class. -numElements:int ● Contracts include three types of constraints: +put() +get() ■ Invariant: A predicate that is always true for all instances of a +remove() class. Invariants are constraints associated with classes or +containsKey() +size() interfaces. Invariants are used to specify consistency constraints among class attributes. Hashtable ■ Precondition: A predicate that must be true before an operation is invoked. Preconditions are associated with a specific operation. -numElements:int Preconditions are used to specify constraints that a caller must +put(key:Object,entry:Object) +get(key:Object):Object meet before calling an operation. +remove(key:Object) +containsKey(key:Object):boolean ■ Postcondition: A predicate that must be true after an operation is +size():int invoked. Postconditions are associated with a specific operation. Postconditions are used to specify constraints that the object must ensure after the invocation of the operation. 11 12 15-ObjectDesign 15-ObjectDesign 2

Expressing constraints in UML Expressing Constraints in UML ● OCL (Object Constraint Language) ● A constraint can also be depicted as a note ■ OCL allows constraints to be formally specified on single model elements or groups of model elements attached to the constrained UML element by a ■ A constraint is expressed as an OCL expression returning the value true dependency relationship. or false. OCL is not a procedural language (cannot constrain control flow). <<invariant>> ● OCL expressions for Hashtable operation put(): numElements >= 0 Context is a class HashTable ■ Invariant: OCL expression operation <<precondition>> <<postcondition>> numElements:int ◆ context Hashtable inv: numElements >= 0 !containsKey(key) get(key) == entry put(key,entry:Object) get(key):Object <<precondition>> ■ Precondition: containsKey(key) remove(key:Object) containsKey(key:Object):boolean ◆ context Hashtable::put(key, entry) pre:!containsKey(key) <<precondition>> size():int <<postcondition>> containsKey(key) !containsKey(key) ■ Post-condition: ◆ context Hashtable::put(key, entry) post: containsKey(key) and get(key) = entry 13 14 15-ObjectDesign 15-ObjectDesign Object Design Areas Component Selection 1. Service specification ● Select existing off-the-shelf class libraries, ■ Describes precisely each class interface frameworks or components 2. Component selection ● Adjust the class libraries, framework or ■ Identify off-the-shelf components and additional solution objects components 3. Object model restructuring ■ Change the API if you have the source code. ■ Transforms the object design model to improve its ■ Use the adapter or bridge pattern if you don’t have understandability and extensibility access 4. Object model optimization ■ Transforms the object design model to address performance criteria such as response time or memory utilization. 15 16 15-ObjectDesign 15-ObjectDesign Reuse... Object Design Areas ● Look for existing classes in class libraries 1. Service specification ■ JSAPI, JTAPI, .... ■ Describes precisely each class interface 2. Component selection ● Select data structures appropriate to the ■ Identify off-the-shelf components and additional solution objects algorithms 3. Object model restructuring ■ Container classes ■ Transforms the object design model to improve its ■ Arrays, lists, queues, stacks, sets, trees, ... understandability and extensibility ● Define new internal classes and operations only if 4. Object model optimization necessary ■ Transforms the object design model to address performance criteria such as response time or memory utilization. ■ Complex operations defined in terms of lower-level operations might need new classes and operations 17 18 15-ObjectDesign 15-ObjectDesign 3