Académique Documents
Professionnel Documents
Culture Documents
Object Design
Object design is the process of adding details to the 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: Iterates on the models, in particular the object model and refine the models Object Design serves as the basis of implementation
Off-the-shelf components
System design gap
Machine
Identification of existing components Full definition of associations Full definition of classes (System Design => Service, Object Design => API) Specifying the contract for each component Choosing algorithms and data structures Identifying possibilities of reuse Detection of solution-domain classes Optimization Increase of inheritance Decision on control Packaging
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
Specification
Reuse
Identifying components
Specifying visibility
Adjusting components Specifying types & signatures Identifying patterns Specifying constraints
Specifying exceptions
Adjusting patterns
Collapsing classes
Realizing associations
Decomposition into subsystems Implementation language chosen Data structures and algorithms chosen
Decomposition into subsystems Data structures are chosen Algorithms are chosen Data structures are refined Implementation language is chosen Typically in parallel with preliminary design, not a separate activity
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
2. Interface specification
Describes precisely each class interface
Mapping Models to Code lecture
Outline of Today
Reuse Concepts The use of inheritance Implementation vs Interface Inheritance Delegation Components Documenting the Object Design JavaDoc
Reuse Concepts
Application objects versus solution objects Specification inheritance and implementation inheritance The Liskov Substitution Principle Delegation (Section 8.3.3) Delegation and inheritance in design patterns
10
Application objects, also called domain objects, represent concepts of the domain that are relevant to the system.
They are identified by the application domain specialists and by the end users.
Solution objects represent concepts that do not have a counterpart in the application domain,
They are identified by the developers Examples: Persistent data stores, user interface objects, middleware.
11
Text box
Menu
Scrollbar
12
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
13
[Gamma et al 94]: Strict modeling of the real world leads to a system that reflects todays realities but not necessarily tomorrows. There is a need for reusable and flexible designs Design knowledge complements application domain knowledge and solution domain knowledge.
14
Identification of taxonomies
Used during requirements analysis. Activity: identify application domain objects that are hierarchically related Goal: make the analysis model more understandable
Service specification
Used during object design Activity: Goal: increase reusability, enhance modifiability and extensibility
Object Design
Analysis activity
Taxonomy Inheritance for Reuse
Specification Inheritance
Implementation Inheritance
16
Taxonomy Example
Mammal
Tiger
Wolf
Wale
17
Implementation Inheritance
A very similar class is already implemented that does almost the same as the desired class implementation.
Example: I have a List class, I need a Stack class. How about subclassing the Stack class from the List class and providing three methods, Push() and Pop(), Top()?
List
Add () Remove() Already implemented
Stack
Push () Pop() Top()
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 H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Implementation inheritance
Also called class inheritance Goal: Extend an applications functionality by reusing functionality in parent class Inherit from an existing class with some or all operations already implemented
Interface inheritance
Also called subtyping Inherit from an abstract class with all operations specified, but not yet implemented
19
Delegation is a way of making composition (for example aggregation) as powerful for reuse as inheritance In Delegation two objects are involved in handling a request
A receiving object delegates operations to its delegate. The developer can make sure that the receiving object does not allow the client to misuse the delegate object
Client
calls
Receiver
Delegates to Delegate
20
Inheritance: Extending a Base class by a new operation or overwriting an operation. Delegation: Catching an operation and sending it to another object. Which of the following models is better for implementing a stack? List
+Add() +Remove()
Stack
+Push() +Pop() +Top()
List
Remove() Add()
Stack
+Push() +Pop() +Top()
Bernd Bruegge & Allen H. Dutoit
21
Delegation
Pro:
Flexibility: Any object can be replaced at run time by another one (as long as it has the same type) Inefficiency: Objects are encapsulated.
Con:
Inheritance
Pro:
Straightforward to use Supported by many programming languages Easy to implement new functionality 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)
Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
Con:
23
Component Selection
Select existing
off-the-shelf class libraries frameworks or components
24
Reuse...
25
Frameworks
A framework is a reusable partial application that can be specialized to produce custom applications. Frameworks are targeted to particular technologies, such as data processing or cellular communications, or to application domains, such as user interfaces or real-time avionics. The key benefits of frameworks are reusability and extensibility.
Reusability leverages of the application domain knowledge and prior effort of experienced developers Extensibility is provided by hook methods, which are overwritten by the application to extend the framework.
Hook methods systematically decouple the interfaces and behaviors of an application domain from the variations required by an application in a particular context.
26
Classification of Frameworks
27
Middleware frameworks are used to integrate existing distributed applications and components.
Examples: MFC, DCOM, Java RMI, WebObjects, WebSphere, WebLogic Enterprise Application [BEA].
28
Whitebox frameworks:
Extensibility achieved through inheritance and dynamic binding. Existing functionality is extended by subclassing framework base classes and overriding predefined hook methods Often design patterns such as the template method pattern are used to override the hook methods.
Blackbox frameworks
Extensibility achieved by defining interfaces for components that can be plugged into the framework. Existing functionality is reused by defining components that conform to a particular interface These components are integrated with the framework via delegation.
29
Class Libraries:
Less domain specific Provide a smaller scope of reuse. Class libraries are passive; no constraint on control flow.
Framework:
Classes cooperate for a family of related applications. Frameworks are active; affect the flow of control.
30
Components
Self-contained instances of classes Plugged together to form complete applications. Blackbox that defines a cohesive set of operations, Can be used based on the syntax and semantics of the interface. Components can even be reused on the binary code level.
The advantage is that applications do not always have to be recompiled when components change.
Frameworks:
Often used to develop components Components are often plugged into blackbox frameworks.
31
WebServer
StaticHTML
RelationalDatabase
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
ODD Template:
http://www.oose.org
33
34
JavaDoc
Add documentation comments to the source code. A doc comment consists of characters between /** and */ When JavaDoc parses a doc comment, leading * characters on each line are discarded. First, blanks and tabs preceding the initial * characters are also discarded. Doc comments may include HTML tags Example of a doc comment:
/** * This is a <b> doc </b> comment */
35
More on JavaDoc
Doc comments are only recognized when placed immediately before class, interface, constructor, method or field declarations. When you embed HTML tags within a doc comment, you should not use heading tags such as <h1> and <h2>, because JavaDoc creates an entire structured document and these structural tags interfere with the formatting of the generated document. Class and Interface Doc Tags Constructor and Method Doc Tags
36
@version version-text
Creates a Version entry.
@see classname
Creates a hyperlink See Also classname
@since since-text
Adds a Since entry. Usually used to specify that a feature or change exists since the release number of the software 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).
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37
@return description
Adds a "Returns" section, which contains the description of the return value.
@see classname
Adds a hyperlink "See Also" entry to the method.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38
39
A field comment can contain only the @see, @since and @deprecated tags
/** * The X-coordinate of the window. * * @see window#1 */ int x = 1263732;
41
....
42
Package it all up
Pack up design into discrete physical units that can be edited, compiled, linked, reused Construct physical modules
Ideally use one package for each subsystem System decomposition might not be good for implementation.
Classes in client-supplier relationships are usually loosely coupled Large number of parameters in some methods mean strong coupling (> 4-5) Avoid global data
Maximize cohesion:
43
Packaging Heuristics
Each subsystem service is made available by one or more interface objects within the package Start with one interface object for each subsystem service
Try to limit the number of interface operations (7+-2)
If the subsystem service has too many operations, reconsider the number of interface objects If you have too many interface objects, reconsider the number of subsystems Difference between interface objects and Java interfaces
Interface object : Used during requirements analysis, system design and object design. Denotes a service or API Java interface: Used during implementation in Java (A Java interface may or may not implement an interface object)
44
Summary
Object design closes the gap between the requirements and the machine. Object design is the process of adding details to the requirements analysis and making implementation decisions Object design activities include:
Identification of Reuse Identification of Inheritance and Delegation opportunities Component selection Interface specification (next lecture) Object model restructuring Lecture on Mapping Models to Code Object model optimization
Object design is documented in the Object Design Document, which can be automatically generated from a specification using tools such as JavaDoc.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 45
Additional Slides
46
A2: Application Server A1: Application Server State Profil State Profil State Profil State Profil State Profil State
Web Server
47
Reuse
Main goal:
Reuse knowledge from previous experience to current problem Reuse functionality already available
Reuse Heuristics
49