Object-Oriented Design: ©ian Sommerville 2000 Software Engineering. Chapter 14 Slide 1

Chapter 14
Object-Oriented Design
©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 1

Objectives
● To explain how a software design may
be represented as a set of interacting
objects that encapsulate their own state
and operations.
● To describe (and illustrate) the activities
in the object-oriented design process.
(cont’d)

Objectives (cont’d)
● To introduce various models used to
describe an object-oriented design
● To show how the UML may be used to
represent these models

Topics covered
● Characteristics of OOD
● History of OOD as reflected by Sommerville
● Objects and object classes
● Generalization and inheritance
● An object-oriented design process (Weather
Station example)
● Design evolution

Characteristics of OOD
● Allows designers to think in terms of interacting
objects that maintain their own state and provide
operations on that state instead of a set of
functions operating on shared data.
● Objects hide information about the represen-
tation of state and hence limit access to it.
● Objects may be distributed and may work
sequentially or in parallel.

A design strategy based on
“information hiding”…
Another way to think about “information hiding”:
Potentially changeable design decisions

are isolated (i.e., “hidden”) to minimize
the impact of change.
- David Parnas
(Is there any connection between information

hiding and AOSD?)
Interacting objects
o1: C1 o3:C3 o4: C4

state o1 state o3 state o4
ops1() ops3 () ops4 ()
o2: C3 o6: C1 o5:C5

state o2 state o6 state o5
ops3 () ops1 () ops5 ()

Advantages of OOD
● Easier maintenance. Objects may be
understood as stand-alone entities (and
ripple effect is reduced).
● Objects are appropriate reusable

components.
● For some systems, there is an obvious
mapping from real world entities to
system objects.

Object-oriented development
● OO Analysis: concerned with developing
an object model of the application domain.
● OO Design: concerned with developing
an object-oriented system model to
implement requirements
● OO Programming: concerned with
realising an OOD using an OO pro-
gramming language such as Java or C++.

The history of OO Development as
reflected by Sommerville’s text
● 1st Edition (1982): No mention of OO
design!
● 2nd Edition (1985): …it has been sug-
gested that a better design methodology
is OO design… To place such comments
in perspective, many large systems have
been built using top-down design. Few
large systems have been built using
an object-oriented approach.

● 3rd Edition (1989): It is only within the
past few years that an alternative mode
of decomposition, OO design, has been
recognized as of value.
● 4th Edition (1992): OO methods are still
relatively immature and are changing
rapidly so are not nearly as widely used
as methods based on functional
decomposition. They will become more
widely used as they mature…

● 5th Edition (1995): Until relatively recently,
the most commonly used software design
strategy involved decomposing the design
into functional components with system
state information held in a shared data
area…It is only since the late 1980’s
that…OO design has been widely
adopted.

● 6th Edition(2001): An OO approach to the
whole (of) software development is now
commonly used…
Coverage of functional design is now
included in the new chapter on legacy
systems.

● 7th Edition (2004): Chapter on legacy
systems deleted.
Although many software developers
consider function-oriented design to be
an outdated approach, OO development
may not offer significant advantages (in
some) situations. An interesting
challenge…is to ensure that function-
oriented and OO systems can work
together.

● 8th Edition (2007): Chapter on Aspect-
Oriented Software Development added.
In most large systems...implementing a
change to a requirement may involve
understanding and changing many
components... AOSD is an emerging
approach...intended to address this problem.
Aspects are used alongside other
abstractions such as objects and methods.
(AOSD) support separating concerns into
independent elements...

Should we still be placing an
emphasis on OO Design?
● Extensive up-front design can be criticized
because the extensive analysis and design
effort is not well suited to incremental
development and delivery.
● Agile methods have been developed to
address this problem.

Should we still be placing an
emphasis on OO Design? (cont’d)
● Sommerville's view: extensive, “heavy-
weight” design is unnecessary for small
and medium-sized systems. But for large
systems, particularly critical systems, it is
essential to ensure that teams working on
different parts of the system are properly
coordinated.

Objects and object classes
● Objects are entities with state and a
defined set of operations on that state.
§ State is represented as a set of object
attributes.
§ Operations provide services to other objects
when requested.

Objects and object classes
(cont’d)
● Object classes are templates for objects.
§ An object class definition includes
declarations of all attributes and operations
associated with an object of that class.
§ They may inherit attributes and services
from other object classes.

The Unified Modeling Language
● Several different notations for OOD were
proposed in the 1980s and 1990s. (Booch,
Rumbaugh, Jacobson, Coad & Yourdon, Wirfs, …)
● UML is an integration of these notations.

● It describes a number of different models
that may be produced during OO analysis
and design (user view, structural view, behavioural
view, implementation view, …)
● The de facto standard for OO modelling.

Employee object class (UML)
Employee
name: string
address: string
Object dateOfBirth: Date
attributes employeeNo: integer
socialSecurityNo: string
department: Dept
ma nager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. ..
Services
join () to other
leave ()
retire () objects
changeDetails ()

Object communication
● Conceptually, objects communicate by
message passing.
● Messages include:
§ The name of the service requested,
§ A copy of the information required to carry out the
service, and
§ the name of a holder for the result of the service.
● In practice, messages are often imple-

mented by procedure calls

Message examples
// Call a method associated with a buffer
// object that returns the next value
// in the buffer
Holder v = circularBuffer.Get () ;
for result
Name of service
// Call the method associated with a

// thermostat object that sets the Info required
// temperature to be maintained
thermostat.setTemp (20) ;
(cf. XML text messages in service-based systems)
Generalization and inheritance
● Objects are members of classes which
define attribute types and operations.
● Classes may be arranged in a hierarchy
where one class (a super-class) is a
generalization of one or more other
classes (sub-classes)

Generalization and inheritance
● A sub-class inherits the attributes and
operations from its super class and may
add new methods or attributes of its
own.

A UML generalisation
hierarchy
Employee Definition on slide 19
Ma nager Programmer
budgetsControlled project
progLanguage
dateAppointed
Project De pt. Strategic

Ma nag er Ma nager Ma nag er
projects dept responsibilities

Advantages of inheritance
● It is an abstraction mechanism which may
be used to classify entities.
● It is a reuse mechanism at both the
design and the programming level.
● The inheritance graph is a source of
organizational knowledge about domains
and systems. (OO Analysis)

Problems with inheritance
● Object classes are not self-contained (i.e.,
they cannot be understood without Due to inherited
reference to their super-classes). attributes/ops
● Designers have a tendency to reuse the

inheritance graph created during analysis.
(Inheritance graphs of analysis, design and
implementation have different functions.)
Discipline/education
problem?

Inheritance and OOD
● Inheritance is a useful implementation
concept which allows reuse of attribute
and operation definitions.
● Some feel that identifying an inheritance
hierarchy or network is also a funda-
mental part of object-oriented design.
(Obviously, this can only be implemented directly using an
OOPL.)
(cont’d)

Inheritance and OOD (cont’d)
● Others feel this places unnecessary
restrictions on the implementation.*
● Inheritance introduces complexity and
this is undesirable, especially in critical
systems. (where design transparency is of utmost
importance)
* This appears to be Sommerville’s view

UML associations
● Objects and object classes participate in
various types of relationships with other
objects and object classes.
● In the UML, a generalized relationship is
indicated by an association.
(cont’d)

UML associations (cont’d)
● Associations may be annotated with (semantics)
information that describes their nature.
● Associations can be used to indicate that
an attribute of an object is an associated
object or that a method relies on an
associated object.

An association model
Employee
is-member-of Department
is-managed-by
annotations
manages
Manager

Concurrent objects
● The nature of objects as self-contained
entities make them well suited for con-
current implementation.
● The message-passing model of object
communication can be implemented
directly if objects are running on separate
processors in a distributed system. (as
opposed to using procedure calls)
(e.g., as XML text messages in service-based systems)

Concurrent object implementation:
servers and active objects
● Servers (Passive objects): entry points
correspond to object operations. If no calls are
made to it, the object suspends itself and waits
for further requests for service.
● Active objects: internal object state may be
changed by the object itself and not simply by
external calls.

Example: an active transponder
object
● A transponder object broadcasts an
aircraft’s position. (on demand)
● The object periodically updates the
position by triangulation from satellites.
(autonomously)

An active transponder object
class Transponder extends Thread {
Position currentPosition ;
Coords c1, c2 ;
Java-based interface
Satellite sat1, sat2 ;
Navigator theNavigator ; description
public Position givePosition ()
{ ON DEMAND
return currentPosition ;
}
public void run ()

{
while (true)
{ IN
c1 = sat1.position () ;
c2 = sat2.position () ;
currentPosition = theNavigator.compute (c1, c2) ;
BACKGROUND
}
} //Transponder
Active object implementation: Java
threads, Ada tasks, etc.
● Threads in Java are a simple construct
for implementing concurrent objects.
● Threads must include a method called
run() and this is started up by the Java
run-time system.
● Active objects typically include an infinite
loop so that they are always carrying out
the computation.

An object-oriented design
process (an iterative, boot-strapping process)

An object-oriented design
process (an iterative, boot-strapping process)
1. Define the context and modes of use of
the system.
2. Design the system architecture.
3. Identify the principal system objects.
4. Develop design models (static and
dynamic).
5. Specify object interfaces.

Weather system description
A weather data collection system is required to
generate weather maps on a regular basis using
data collected from remote, unattended weather
stations and other data sources such as weather
observers, balloons and satellites. Weather
stations transmit their data to the area computer
in response to a request from that machine.

Weather system description
The area computer validates the collected data
and integrates it with the data from different
sources. The integrated data is archived and,
using data from this archive and a digitized
map database, a set of local weather maps is
created. Maps may be printed for distribution
on a special-purpose map printer or may be
displayed in a number of different formats.

Weather station description
A weather station is a package of software

controlled instruments which collects data,
performs some data processing and transmits this
data for further processing. The instruments
include air and ground thermometers, an
anemometer, a wind vane, a barometer and a rain
gauge. Data is collected every five minutes.

Weather station description
When a command is issued to transmit the

weather data, the weather station processes and
summarises the collected data. The summarised
data is transmitted to the mapping computer when
a request is received.

1. Define system context and
modes of use
● Goal: develop an understanding of the
relationships between the software being
designed and its external environment.
● System context: a static model that
describes other systems in the environ-
ment.
● The context of the weather station is
illustrated below using UML packages.

Context of weather station
«subsystem»
Da ta collection «subsystem»
Da ta display
Observer Satellite
User Ma p
Co mms interface display
Weather Ma p
Balloon Ma p printer
station
«subsystem» «subsystem»
Da ta processing Da ta archiving
Da ta
Da ta Da ta storage
checking integration
Ma p store Da ta store

1. Define system context and
modes of use (cont.)
● Modes of system use: a dynamic model
that describes how the system will
interact with its environment.
● Modes of weather station use are
illustrated below using a UML use-case
model.

Use-cases for the weather station
Startup
Shutdown
External entity Possible

(weather data Re port interactions
collection sys)
Ca librate
Test

Use-case description
System Weather station
Use-case Report
Actors Weather data collection system, Weather station
Data The weather station sends a summary of the weather data that has been
collected from the instruments in the collection period to the weather data
collection system. The data sent are the maximum minimum and average
ground and air temperatures, the maximum, minimum and average air
pressures, the maximum, minimum and average wind speeds, the total rainfall
and the wind direction as sampled at 5 minute intervals.
Stimulus The weather data collection system establishes a modem link with the weather
station and requests transmission of the data.
Response The summarised data is sent to the weather data collection system
Comments Weather stations are usually asked to report once per hour but this frequency
may differ from one station to the other and may be modified in future.
basis for “information hiding”

2. Design system architecture
● A layered architecture is appropriate for the
weather station:
§ Interface layer for handling communications
§ Data collection layer for collecting and
summarizing weather data
§ Instruments layer for encapsulating instruments
used to collect raw data
● Rule of Thumb: There should be no more
than 7 entities in an architectural model. (See
Miller, "The Magical Number Seven, Plus or Minus Two,“
WOR. )

Weather station architecture
Weather station
Manages all
«subsystem» external
Interface communications
Collects and
«subsystem» summarises
Da ta collection weather data
Package of
«subsystem» instruments for raw
Instruments data collections
UML annotations
UML “nested packages”
3. Identify principal system
objects
● Identifying objects (or object classes) is
the most difficult part of OO design.
● There is no “magic formula” – it relies on
the skill, experience, and domain
knowledge of system designers
● An iterative process – you are unlikely to
get it right the first time.

Approaches to object
identification
● Use a grammatical approach based on a
natural language description of the
system (Abbott’s heuristic).
● Associate objects with tangible things in
the application domain (e.g. devices).
● Use a behavioural approach: identify
objects based on what participates in
what behaviour.

Approaches to object
identification (cont.)
● Use scenario-based analysis. The
objects, attributes and methods in each
scenario are identified.
● Use an information-hiding based
approach.* Identify potentially change-
able design decisions and isolate these
in separate objects.
* “Bonus” approach! (No extra charge.)

Weather station object
classes
● Weather station – interface of the weather
station to its environment. It reflects interactions
identified in the use-case model.
● Weather data – encapsulates summarised
data from the instruments.
● Ground thermometer, Anemometer,
Barometer – application domain “hardware”
objects* related to the instruments in the system.
* hardware-controlling SOFTWARE

Weather station object
classes
WeatherStation WeatherData
identifier airTemperatures
groundTemperatures
reportWeather () win dSpeeds
calibrate (instruments) win dDirections
test () pressures
startup (instruments) rainfall
shutdown (instruments)
collect ()
summarise ()
Ground Anemometer Ba rom eter

the rmometer pressure
win dSpeed
temperature win dDirection height
test () test ()
calibrate () test ()
calibrate ()

Other objects and object
refinement
● Use domain knowledge to identify more
objects, operations, and attributes.
§ Weather stations should have a unique
identifier.
§ Weather stations are remotely situated so
instrument failures have to be reported
automatically. Therefore, attributes and
operations for self-checking are required.

Other objects and object
refinement (cont.)
● Active or passive objects?
§ Instrument objects are passive and collect
data on request rather than autonomously.
This introduces flexibility (how?)* at the
expense of controller processing time.
§ Are any active objects required?
* Hint: consider potentially changeable design decisions

4. Develop design models
● Design models show the relationships
among objects and object classes.
§ Static models describe the static structure
of the system in terms of object and object
class relationships.
§ Dynamic models describe the dynamic
interactions among objects.

Examples of design models
● Sub-system models show logical
groupings of objects into coherent sub-
systems. (static)
● Sequence models show the sequence of
object interactions associated with
system uses. (dynamic)
(cont’d)

Examples of design models
(cont’d)
● State machine models show how indi-
vidual objects change their state in re-
sponse to events. (dynamic)
● Other models include use-case models,
aggregation models, generalisation
(inheritance) models, etc.

Subsystem models
● In the UML, these are shown using
packages, an encapsulation construct.
● This is a logical model – the actual
organization of objects in the system as
implemented may be different.

Weather station subsystems
«subsystem» «subsystem»
Interface Da ta collection
Active object
Co mmsCo ntroller WeatherData
Instrument
WeatherStation Status
Annotations
go here
«subsystem»
Instruments
Air
thermometer Ra inGauge Anemometer
Ground
thermometer Barometer Wind Vane

Sequence models
● Objects are arranged horizontally across
the top.
● Time is represented vertically; models
are read top to bottom.
● Interactions are represented by labelled
arrows – different styles of arrows
represent different types of interaction.
● A thin rectangle in an object lifeline
represents the time when the object is
the controlling object in the system.

Data collection sequence
area computer :CommsController :WeatherStation :WeatherData
request (report)
acknowledge ()
report ()
summarise ()
Return of
No reply expected
control
send (report)
reply (report)
acknowledge ()

Weather station state machine
model
Operation calibrate () Calibrating
calibration OK
startup () Waiting test () Testing
Shutdown
shutdown () transmission done test complete
Transmitting
clock collection
done reportWeather ()
weather summary
Summarising complete
Collecting

5. Object interface
specification
● Designers should avoid revealing data
representation information in their
interface design. (operations access and update
all data)
● Objects may have several logical

interfaces which are viewpoints on the
methods provided. (supported directly in Java)
● The UML uses class diagrams for
interface specification but pseudocode
may also be used.

Weather station interface
(Java-based)
interface WeatherStation {
public void WeatherStation () ;
public void startup () ;

public void startup (Instrument i) ;
public void shutdown () ;

public void shutdown (Instrument i) ;
public void reportWeather ( ) ;
public void test () ;

public void test ( Instrument i ) ;
public void calibrate ( Instrument i) ;
public int getID () ;
} //WeatherStation

Design evolution
● Hiding information in objects means that
changes made to an object need not
affect other objects in an unpredictable
way.
● Assume pollution monitoring facilities are
to be added to weather stations.
● Pollution readings are transmitted with
weather data.

Changes required
● Add an object class called “Air quality” as
part of WeatherStation.
● Add an operation reportAirQuality to
WeatherStation. Modify the control
software to collect pollution readings.
● Add objects representing pollution
monitoring instruments.
…and that’s all.

Pollution monitoring
WeatherStation
Air quality
identifier
NO Data
reportWeather () smokeData
reportAirQuality () benzeneData
calibrate (instruments)
test () collect ()
startup (instruments) summarise ()
shutdown (instruments)
Pollution monitoring instruments
NO meter SmokeMeter
BenzeneMeter

Key points
● OOD results in design components with their
own private state and operations.
● Objects should have constructor and
inspection operations. They provide services
to other objects. as do algebraic specs
● Objects may be implemented sequentially or

concurrently.
● The Unified Modeling Language provides
different notations for defining different
object models.
(cont’d)

Key points (cont’d)
● A range of different models may be
produced during an object-oriented
design process. These include static and
dynamic system models (See the OMG website
for sources.)
● Object interfaces should be defined

precisely.
● Object-oriented design simplifies system
evolution.

Chapter 14
Object-Oriented Design

Object-Oriented Design: ©ian Sommerville 2000 Software Engineering. Chapter 14 Slide 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object-Oriented Design: ©ian Sommerville 2000 Software Engineering. Chapter 14 Slide 1

Uploaded by

Copyright:

Available Formats

Chapter 14

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 1

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 2

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 3

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 4

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 5

Another way to think about “information hiding”:

Potentially changeable design decisions

(Is there any connection between information

o1: C1 o3:C3 o4: C4

o2: C3 o6: C1 o5:C5

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 7

● Objects are appropriate reusable

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 8

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 9

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 10

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 11

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 12

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 13

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 14

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 15

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 16

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 17

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 18

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 19

● UML is an integration of these notations.

● The de facto standard for OO modelling.

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 20

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 21

● In practice, messages are often imple-

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 22

// Call the method associated with a

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 24

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 25

Project De pt. Strategic

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 26

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 27

● Designers have a tendency to reuse the

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 28

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 29

* This appears to be Sommerville’s view

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 30

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 31

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 32

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 33

(e.g., as XML text messages in service-based systems)

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 34

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 35

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 36

public void run ()

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 38

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 39

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 40

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 41

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 42

A weather station is a package of software

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 43

When a command is issued to transmit the

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 44

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 45

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 46

©Ian Sommerville 2000 Software Engineering. Chapter 14 Slide 47

External entity Possible