Transcript Lecture 1 for Chapter 8, Object Design: Reusing Pattern

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 8, Object
Design: Reuse and
Patterns
(Lecture I)
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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2
Object Design: Closing the Gap
Problem
System
Application objects
Requir ements gap
Solution objects
Custom objects
Object design gap
Off-the-shelf components
System design gap
Modified from Bruegge & Dutoit’s originals
Machine
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
3
Examples of Object Design Activities



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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
A More Detailed View of Object Design Activities
Select Subsystem
Specification
Identifying missing
attributes & operations
Reuse
Identifying components
Specifying visibility
Adjusting components
Specifying types &
signatures
Identifying patterns
Specifying constraints
Specifying exceptions
Modified from Bruegge & Dutoit’s originals
Adjusting patterns
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
Detailed View of Object Design Activities (ctd)
Check Use Cases
Restructuring
Optimization
Revisiting
inheritance
Optimizing access
paths
Collapsing classes
Caching complex
computations
Realizing associations
Delaying complex
computations
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
A Little Bit of Terminology: Activities

Object-Oriented methodologies use these terms:
 System Design Activity

Decomposition into subsystems
 Object Design Activity



Implementation language chosen
Data structures and algorithms chosen
Structured analysis/structured design uses these terms:
 Preliminary Design Activity


Decomposition into subsystems
Data structures are chosen
 Detailed Design Activity




Algorithms are chosen
Data structures are refined
Implementation language is chosen
Typically in parallel with preliminary design, not a separate activity
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
Plan for the next Lectures
1. Reuse: Identification of existing solutions
 Use of inheritance
 Off-the-shelf components and additional
solution objects
 Design patterns
Object
Design
lectures
2. Interface specification

Describes precisely each class interface
3. Object model restructuring
 Transforms the object design model to
improve its understandability and extensibility
4. Object model optimization
Mapping
Models to Code
lecture
 Transforms the object design model to address
performance criteria such as response time or
memory utilization.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
8
Outline of Today







Reuse Concepts
The use of inheritance
Implementation vs. Specification Inheritance
Delegation
Components and Frameworks
Documenting the Object Design
JavaDoc
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
Application domain vs solution domain objects

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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
11
Application Domain vs Solution Domain Objects
Requirements Analysis
(Language of Application
Domain)
Object Design
(Language of Solution Domain)
Incident
Report
Incident
Report
Text box
Modified from Bruegge & Dutoit’s originals
Menu
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Scrollbar
12
Implementation of Application Domain Classes

New objects are often needed during object design:
 The use of design patterns introduces 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 in 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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13
Observation about Modeling of the Real World

[Gamma et al 94]:
Strict modeling of the real world leads to a system that reflects
today’s realities but not necessarily tomorrow’s.

There is a need for reusable and flexible designs

Design knowledge complements application domain
knowledge and solution domain knowledge.

Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Reuse

Main goal:
 Reuse knowledge from previous experience to current problem
 Reuse functionality already available

Composition (also called Black Box Reuse)
 New functionality is obtained by aggregation
 The new object with more functionality is an aggregation of existing
components

Inheritance (also called White-box Reuse)
 New functionality is obtained by inheritance.

Three ways to get new functionality:



Implementation inheritance
Specification inheritance
Delegation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
The use of inheritance

Inheritance is used to achieve two different goals
 Description of Taxonomies
 Interface Specification

Identification of taxonomies
 Used during requirements analysis.
 Activity: identify application domain objects that are
hierarchically related
 Goal: make the analysis model more understandable

Interface specification
 Used during object design
 Activity: identify abstract classes and common behaviors
 Goal: increase reusability, enhance modifiability and extensibility

Inheritance is found either by specialization or generalization
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
16
Metamodel for Inheritance

Inheritance is used during analysis and object design
Inheritance
Object
Design
Analysis
activity
Taxonomy
Inheritance detected
by specialization
Modified from Bruegge & Dutoit’s originals
Inheritance detected
by generalization
Inheritance
for Reuse
Specification
Inheritance
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Implementation
Inheritance
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
19
Implementation Inheritance vs Specification Inheritance

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

Specification inheritance
 Also called subtyping
 Inherit from an abstract class with all operations specified, but not
yet implemented
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Exercise 8-2: Implementation or Specification Inheritance?

Rectangle class inherits from Polygon class
 Specification

Set class inherits from BinaryTree class
 Implementation

Set class inherits from Bag class
 Specification

Player class inherits from User class
 Specification

Window class inherits from Polygon class
 Implementation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Delegation as alternative to Implementation
Inheritance


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
Bernd Bruegge & Allen H. Dutoit
calls
Receiver
Delegates to
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Delegate
22
Delegation instead of Implementation Inheritance



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()
Bernd Bruegge & Allen H. Dutoit
Stack
+Push()
+Pop()
+Top()
Object-Oriented Software Engineering: Using UML, Patterns, and Java
List
Remove()
Add()
23
Comparison: Delegation vs Implementation Inheritance

Delegation
 Pro:

Flexibility: Any object can be replaced at run time by another one (as
long as it has the same type)
 Con:


Inefficiency: Objects are encapsulated.
Inheritance
 Pro:



Straightforward to use
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
24
Lecture on
Design Patterns
Many design patterns use a
combination of inheritance and
delegation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
28
Classification of Frameworks

Frameworks can be classified by their position in the software
development process.

Frameworks can also be classified by the techniques used to
extend them.
 Whitebox frameworks
 Blackbox frameworks
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
29
Frameworks in the Development Process

Infrastructure frameworks aim to simplify the software
development process and are use internally in a project
 Examples: ACE, Java Swing.

Middleware frameworks are used to integrate existing
distributed applications and components.
 Examples: MFC, DCOM, Java RMI, WebObjects, WebSphere,
WebLogic Enterprise Application.

Enterprise application frameworks support the development of
end-user applications. They are application specific and focus
on domains
 Example domains: telecommunications, avionics, environmental
modeling, manufacturing, financial engineering, enterprise business
activities.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
30
White-box and Black-Box Frameworks

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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
31
Class libraries and Frameworks

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.

In practice, developers often use both:
 Frameworks often use class libraries internally to simplify the
development of the framework.
 Framework event handlers use class libraries to perform basic tasks
(e.g. string processing, file management, numerical analysis…. )
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
32
Components and Frameworks

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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
33
Example: Framework for Building Web Applications
WebObjects
WebBrowser
WebServer
StaticHTML
WOAdaptor
WoRequest
WebObjectsApplication
WORequest
Template
EOF
RelationalDatabase
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
34
Documenting the Object Design: The Object Design
Document (ODD)

Object design document
 Same as the Requirements Analysis Document (RAD) plus...
 … additions to object, functional and dynamic models (from solution
domain)
 … navigational map for object model
 … Javadoc documentation for all classes

ODD Management issues





Update the system models in the RAD?
Should the ODD be a separate document?
Who is the target audience for these documents (Customer, developer?)
If time is short: Focus on the Navigational Map and Javadoc
documentation?
ODD Template:
 http://oose.globalse.org
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
35
Documenting Object Design: ODD Conventions

Each subsystem in a system provides a service (see Chapters on
System Design)
 Describes the set of operations provided by the subsystem

Specifying a service operation as
 Signature: Name of operation, fully typed parameter list and return
type
 Abstract: Describes the operation
 Pre: Precondition for calling the operation
 Post: Postcondition describing important state after the execution of
the operation

Use JavaDoc for the specification of service operations.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
36
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
*/
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
37
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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
38
Class and 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 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).
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
39
Constructor and Method Doc Tags

Can contain @see tag, @since tag, @deprecated as well as:
@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, which contains 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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
40
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 %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/
class Window extends BaseWindow {
...
Modified from Bruegge
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
} & Dutoit’s originals
41
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 StringIndexOutOfRangeException
*
if the index is not in the range <code>0</code>
*
to <code>length()-1</code>.
* @see
java.lang.Character#charValue()
*/
public char charAt(int index) {
...
}
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
42
Example of a Field Doc Comment

A field comment can contain only the @see, @since and
@deprecated tags
/**
* The X-coordinate of the window.
*
* @see window#1
*/
int x = 1263732;
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
43
Example: Specifying a Service in Java
/** Office is a physical structure in a building. It is possible to create an
instance of a office; add an occupant; get the name and the number of
occupants */
public class 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();
....
}
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
44
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.

Two design principles for packaging
 Minimize coupling:



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:

Classes closely connected by associations => same package
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
45
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)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
46
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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
47
Additional Slides
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
48
ACE Framework
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
49
A2: Application Server A1: Application Server
State Profil
State Profil
State Profil
State Profil
State Profil
State
Database Server
(Database Framework)
HTTP
Web Browser
(UI Framework)
Modified from Bruegge & Dutoit’s originals
Web Server
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
50
Reuse Heuristics

Look for existing classes in class libraries
 JSAPI, JTAPI, ....

Select data structures appropriate to the algorithms
 Container classes
 Arrays, lists, queues, stacks, sets, trees, ...

Define new internal classes and operations only if necessary
 Complex operations defined in terms of lower-level operations
might need new classes and operations
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
51