chapter 8 object design
play

Chapter 8, Object Design: Object design is the process of adding - PDF document

Object Design Object-Oriented Software Engineering Chapter 8, Object Design: Object design is the process of adding details to the requirements analysis and making implementation decisions Reuse and Patterns I The object designer must


  1. Object Design Object-Oriented Software Engineering Chapter 8, Object Design: ♦ Object design is the process of adding details to the requirements analysis and making implementation decisions Reuse and Patterns I ♦ The object designer must choose among different ways to implement the analysis model with the goal to minimize Using UML, Patterns, and Java execution time, memory and other measures of cost. ♦ Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model ♦ Object Design: Iterates on the models, in particular the object model and refine the models ♦ Object Design serves as the basis of implementation Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Object Design: Closing the Gap Examples of Object Design Activities Problem System ♦ Identification of existing components Application objects ♦ Full definition of associations Requir ements gap ♦ Full definition of classes � System Design => Service � Object Design => API ♦ Specifying the contract for each component Solution objects ♦ Choosing algorithms and data structures Custom objects ♦ Identifying possibilities of reuse Object design gap ♦ Detection of solution-domain classes ♦ Optimization ♦ Increase of inheritance Off-the-shelf components ♦ Decision on control System design gap ♦ Packaging Machine Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 A More Detailed View of Object Design Activities Detailed View of Object Design Activities (ctd) Select Subsystem Check Use Cases Specification Reuse Identifying missing Restructuring Optimization Identifying components attributes & operations Revisiting Optimizing access Specifying visibility inheritance paths Adjusting components Specifying types & signatures Caching complex Collapsing classes computations Identifying patterns Specifying constraints Delaying complex Realizing associations computations Specifying exceptions Adjusting patterns Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Page 1

  2. A Little Bit of Terminology: Activities Outline of the Lecture ♦ Object-Oriented methodologies use these terms: ♦ Design Patterns � System Design Activity � Usefulness of design patterns � Design Pattern Categories � Decomposition into subsystems ♦ Patterns covered in this lecture � Object Design Activity � Composite: Model dynamic aggregates � Implementation language chosen � Facade: Interfacing to subsystems � Data structures and algorithms chosen � Adapter: Interfacing to existing systems (legacy systems) ♦ Structured analysis/structured design uses these terms: � Bridge: Interfacing to existing and future systems � Preliminary Design Activity ♦ More patterns: � Abstract Factory: Provide manufacturer independence � Decomposition into subsystems � Builder: Hide a complex creation process � Data structures are chosen � Proxy: Provide Location transparency � Detailed Design Activity � Command: Encapsulate control flow � Algorithms are chosen � Observer: Provide publisher/subscribe mechanism � Data structures are refined � Strategy: Support family of algorithms, separate of policy and mechanism � Implementation language is chosen � Typically in parallel with preliminary design, not a separate activity Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 The use of inheritance Metamodel for Inheritance ♦ Inheritance is used to achieve two different goals ♦ Inheritance is used during analysis and object design � Description of Taxonomies � Interface Specification Inheritance Object ♦ Identification of taxonomies Design � Used during requirements analysis. Analysis � Activity: identify application domain objects that are activity hierarchically related Inheritance Taxonomy � Goal: make the analysis model more understandable for Reuse ♦ Service specification � Used during object design � Activity: � Goal: increase reusability, enhance modifiability and extensibility Inheritance detected Inheritance detected Implementation Specification Inheritance by specialization by generalization Inheritance ♦ Inheritance is found either by specialization or generalization Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Taxonomy Example Implementation Inheritance ♦ A very similar class is already implemented that does almost the same as the desired class implementation. List Mammal � Example: I have a List Add () class, I need a Stack Remove() class. How about “Already subclassing the Stack implemented” class from the List class and providing three Stack methods, Push() and Push () Pop(), Top() ? Pop() Top() Tiger Wolf Wale � Problem with implementation inheritance: Some of the inherited operations might exhibit unwanted behavior. What happens if the Stack user calls Remove() instead of Pop()? Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Page 2

  3. Delegation as alternative to Implementation Implementation Inheritance vs Interface Inheritance Inheritance ♦ Implementation inheritance ♦ Delegation is a way of making composition (for example aggregation) as powerful for reuse as inheritance � Also called class inheritance � Goal: Extend an applications’ functionality by reusing functionality ♦ In Delegation two objects are involved in handling a request in parent class � A receiving object delegates operations to its delegate. � Inherit from an existing class with some or all operations already � The developer can make sure that the receiving object does not implemented allow the client to misuse the delegate object ♦ Interface inheritance � Also called subtyping calls Delegates to � Inherit from an abstract class with all operations specified, but not Delegate Receiver Client yet implemented Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Duck: Delegation vs. Inheritance Delegation instead of Implementation Inheritance Description: Decide whether to use delegation or ♦ ♦ Inheritance : Extending a Base class by a new operation or inheritance for designing the following classes. Specify the overwriting an operation. attributes and methods for each class. Draw the UML ♦ Delegation : Catching an operation and sending it to another diagram for the whole thing. object. � Array ♦ Which of the following models is better for implementing a � Queue stack? � Stack List � Tree Stack +Add() � Linked list List +Remove() Process: ♦ Remove() � Work in pairs +Push() Add() Stack +Pop() � You have about 10 minutes. +Top() +Push() +Pop() +Top() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Comparison: Delegation vs Implementation Inheritance Component Selection ♦ Delegation ♦ Select existing � Pro: � off-the-shelf class libraries � Flexibility: Any object can be replaced at run time by another one (as � frameworks or long as it has the same type) � components � Con: � Inefficiency: Objects are encapsulated. ♦ Adjust the class libraries, framework or components ♦ Inheritance � Change the API if you have the source code. � Pro: � Use the adapter or bridge pattern if you don’t have access � Straightforward to use ♦ Architecture Driven Design � Supported by many programming languages � Easy to implement new functionality � Con: � Inheritance exposes a subclass to the details of its parent class � Any change in the parent class implementation forces the subclass to change (which requires recompilation of both) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Page 3

Recommend


More recommend