Object Oriented Design

plumponionchipsSoftware and s/w Development

Nov 18, 2013 (3 years and 4 months ago)

52 views


If you're like most newcomers to object
-
oriented

methods, the hard part is now behind you. Most peo
-

ple
struggle when they first attempt to analyze a prob
-

lem using the OO mindset. It's not easy to define a

complete class hierarchy for most problems. Tha
t's

why OOA is iterative.

But eventually, the OOA model solidifies. And

when this happens, it's time to begin object
-
oriented

design (OOD).

Like all design, OOD translates a model that

describes the "what" of a system into another model

that describes the
"how." How will we implement the

objects that have been defined? How will the meth
-

ods perform processing on attributes? How will mes
-

sages be passed between objects, and what is the

message content? These and other questions are

answered as we create th
e design of an OO applica
-

tion.

It's important to note that the basic design princi
-

ples that we introduced in ESE Module 3
-
4 apply

equally well to OOD. If you haven't as yet viewed ESE

Module 3
-
4, we urge you to do so at this time. You'll

be better prep
ared to understand the OOD method.


Object
-
Oriented

Design

Concepts


The OOA model is an abstraction that must be trans
-

lated into something that brings us closer to imple
-

mentation. That's your job when you perform OOD.


Readings


The following excerpt
has been adapted from

Software Engineering: A Practitioner's Approach
and

presents key concepts that will help you better under
-

stand object
-
oriented design.


Bertrand Meyer [1] suggests five criteria for judging a

design method's ability to achieve modul
arity and relates

these to object
-
oriented design:




decomposability
--
the

facility with which a design

method helps the designer to decompose a large problem

into subproblems that are easier to solve;



composability
--
the

degree to which a design method

ensur
es that program components, once designed and

built, can be reused to create other systems;



understandability
--
the

ease with which a program com
-

ponent can be understood without reference to other infer
-

mation or other modules;



continuity
--
the

ability to

make small changes in a pro
-

gram and have these changes manifest themselves with

corresponding changes in just one or a very few modules;



protection
--
an

architectural characteristic that will

reduce the propagation of side affects if an error occurs in a

given module.


From these criteria, Meyer [1] suggests five basic design

principles that can be derived for modular architectures: (1)

linguistic modular units; (2) few interfaces; (3) small inter
-

faces (weak coupling); (4) explicit interfaces; (5) infor
ma
-

tion hiding.

Modules are defined as
linguistic modular units
when

they "correspond to syntactic units in the language used"

[1]. That is, the programming language to be used should

be capable of supporting the modularity defined directly.

For example,
if the designer creates a subroutine, any of the

more popular programming languages (e.g., FORTRAN, C,

Pascal) could implement it as a syntactic unit. But if a pack
-

age that contains data structures and procedures and iden
-

tifies them as a single unit we
re defined, a language such

as Ada (or other object
-
oriented languages) would be nec
-

essary to directly represent this type of module in the lan
-

guage syntax.

To achieve low coupling, the number of interfaces

between modules should be minimized ("few int
erfaces")

and the amount of information that moves across an inter
-

face should be minimized ("small interfaces"). Whenever

modules do communicate, they should do so in an obvious

and direct way (explicit interfaces). For example, if module

X and module Y
communicate through a global data area

(what we have called common coupling), they violate the

principle of explicit interfaces because the communication

between the modules is not obvious to an outside observer.

Finally, we achieve the principle of inform
ation hiding

when all information about a module is hidden from out
-

side access, unless that information is specifically defined

as public information.

The design criteria and principles presented in this

section can be applied to any design method (e.g.,

we can

apply them to structured design). As we will see, however,

the object
-
oriented design method achieves each of the cri
-

teria more efficiently than other approaches and results in

modular architectures that allow us to meet each of the

modularity cr
iteria most effectively.


Classes, Instances and Inheritance


Many objects in the physical world have reasonably similar

characteristics and perform reasonably similar operations.

If we look at the manufacturing floor of a heavy equipment

manufacturer, we
see milling machines, drill presses, and

jig borers. Although each of these objects is different, all

ESE

Module

5
-
3

Object
-
Oriented

Design

5
-
3.2

∙∙
Essential

Software

Engineering

belong to a larger class that is called metal cutting tools. All

objects in

the metal cutting tools class have attributes in

common (e.g., all use electric motors) and perform com
-

mon operations (e.g., cut, start or stop) Therefore, by cate
-

gorizing a "hobber" as a member of the class
metal cutting

machines, we know something a
bout its attributes and the

operations it performs even if we don't know what its

detailed function is.

Software realizations of real world objects are catego
-

rized in much the same way. All objects are members of a

larger class and inherit the private da
ta structure and oper
-

ations that have been defined for that class. An individual

object is therefore an instance of a larger class.

Recalling the SafeHome security system presented ear
-

lier, we conduct object
-
oriented analysis and identify can
-

didate c
lasses. One such class was sensor. From this class

definition one can instantiate specific sensor objects, entry

sensor, smoke sensor, and motion sensor. Using the pro
-

gram design language (PDL) we might write,


TYPE motion sensor IS INSTANCE OF sensor;


which implies inheritance of the attributes of sensor.

But what happens if inheritance isn't perfect? This situ
-

ation occurs when a candidate instance of a class shares

most, but not all, attributes of the class and requires all of

the operations of the c
lass as well additional operations

that are relevant only to the candidate member. For exam
-

ple, assume that a new sensor type is to be added to the

SafeHome system. Unlike smoke, entry and motion sen
-

sors, the new sensor is aggressive, that is it will p
erform

some action once an event is sensed. A fire sensor will not

only alert the SafeHome control panel, but will also spray a

fire retardant chemical into the air for a programmable

period of time. To accommodate the fire sensor, we create a

subclass
--
th
at is, the attributes and operations of the class

sensor are inherited, but they are modified to accommo
-

date the special characteristics of fire sensor. The original

sensor class and the new subclass, called aggressive sensor,

can be defined.

The use of
classes, subclasses, and inheritance is cru
-

cially important in modern software engineering. Reuse of

program components (our ability to achieve composition)

is attained by creating objects (instances) that build on

existing attributes and operations inhe
rited from a class or

subclass. We only need to specify how the new object dif
-

fers from the class, rather than defining all characteristics

of the new object.

Unlike other design concepts that are programming

language independent, the implementation of c
lasses, sub
-

classes and objects varies with the programming language

to be used. For this reason, the preceding generic discus
-

sion may require modification in the context of a specific

programming language. For example, Ada implements the

object as a pa
ckage and achieves instances through the use

of data abstractions and typing. The Smalltalk program
-

ming language, on the other hand, implements each of the

concepts described above directly, making it a true object

oriented programming language.

Object D
escriptions



A design description of an object (an instance of a class or

subclass) can take one of two forms [2]:


1. A
protocol desrription
that establishes the interface of an

object by defining each message that the object can receive

and the relate
d operation that the object performs when it

receives the message, and

2. An
implementation description
that shows implementa
-

tion details for each operation implied by a message that is

passed to an object. Implementation details include infer
-

mation
about the object's private part, that is, internal

details about the data structure and procedural details that

describe operations.


The protocol description is nothing more than a
set
of

messages and a corresponding comment for each message.

For example,

a portion of the protocol description for the

object motion sensor (described earlier) might be:


MESSAGE (motion sensor)
--
> read: RETURNS sensor ID,

sensor status;


which describes the message required to read the sensor.

Similarly,


MESSAGE (motion sen
sor)
--
> set: SENDS sensor ID,

sensor status;


sets or resets the status of the status of the sensor.

For a large system with many messages, it is often pos
-

sible to create message categories. For example, message

categories for the SafeHome system object

might include

system configuring messages, monitoring messages, event

messages and so forth.

An implementation description of an object provides

the internal ("hidden") details that are required for imple
-

mentation but are not necessary for invocation. T
hat is, the

designer of the object must provide an implementation

description and must therefore create the internal details of

the object. However, another designer or implementer who

uses the object or other instances of the object requires only

the prot
ocol description but not the implementation

description.

An implementation description is comprised of the fol
-

lowing information: (1) a specification of the object's name

and reference to class; (2) a specification of private data

structure with indicati
on of data items and types; (3) a pro
-

cedural description of each operation or alternatively,

pointers to such procedural descriptions. The implementa
-

tion description must contain sufficient information to pro
-

vide for proper handling of all messages d
escribed in the

protocol description.

Cox [3] characterizes the difference between the infor
-

mation contained in the protocol description and that con
-

tained in the implementation description in terms of

users" and "suppliers" of services. A user of the
"service"

provided by an object must be familiar with the protocol

for invoking the service, that is, for specifying what is

Object
-
Oriented

Design

∙∙

5
-
3.3

desired. The supplier of the service (the object itself) must

be concerned with how the service is
to be supplied to the

user, that is, with implementation details. This concept,

called
encapsulation,
is summarized as follows [3]:


[An object] delivers encapsulation,whereby a data

structure and a group of procedures for accessing it can be

put into serv
ice such that the users of that
capability
can

access it through a set of carefully documented, controlled

and standardized interfaces. These encapsulated data

structures, called objects, amount to active data that can be

requested to do things by sending
them messages.


[1] Meyer, B., Object
-
Oriented Software Construction, end

edition, Prentice
-
Hail, 1988.

[2] Goldberg, A. and D. Robson, Smalltalk
-
80, Addison
-

Wesley, 1983.

[3] Cox, B,
"Software
ICs and Objective C," Unixworld,

Spring,1985. O


Exercise

5
-
5,

Design Descriptions for Objects


Review the analysis model that you created as part of

Exercise 5
-
4. Develop protocol descriptions (see read
-

ing above) for all methods (operations) that you

described in the model. Select two or three opera
-

tions and

develop complete implementation descrip
-

tions for them.


Performing

Object
-
Oriented

Design


Object
-
Oriented Design (OOD) is a multi
-
stage

process. First, we focus on a design description of the

classes and objects that were defined to address the

problem

(application) domain. During this stage we

translate the OOA model into a design description.

Next, we design the human interaction component of

the system, defining the classes and objects required

to achieve human
-
machine interaction. Finally. we

design

the data and task management component

of the system.

In the reading that follows we introduce the

design approach, focusing on the problem domain. In

the video segment, we'll discuss the other stages of

OOD.


Readings


The following excerpt has been adap
ted from

Software Engineering: A Pracfifioner's Approach
and

discusses object
-
oriented design.


It is sometimes difficult to make a clear distinction between

object
-
oriented analysis and object oriented design. In

essence, object
-
oriented analysis (OOA) is

a classification

activity. That is, a problem is analyzed in an effort to deter
-

mine the classes of objects that will be applicable as a solu
-

tion is developed. Object
-
oriented design (OOD) enables a

software engineer to indicate the objects that are de
rived

from each class and how these objects interrelate with one

another. In addition, OOD should provide a notation that

depicts the relationships among objects. The terminology,

notation and approach presented for OOA are equally

applicable to the topics

presented in this reading.

OOD methods combine elements of all four design

layers discussed as part of the "design triangle." [See ESE

Modules 3
-
4 and 3
-
5 for details.] Data design, architectural

design, interface design, and procedural design are all

add
ressed.

By identifying classes and objects, data abstractions

are created. By coupling operations to data, modules are

specified and a structure for the software is established. By

developing a mechanism for using (e.g., generating mes
-

sages) the objects,

interfaces are described.

OOD approaches are typified by the following steps:


1. Refine the work done during OOA, looking for sub
-

classes, message characteristics, and other elaboration of

detail.

2. Represent the data structure(s) associated with
object

attributes.

3. Represent the procedural detail associated with each

operation.

4. Design the messaging protocol.

5. Design the human
-
computer interface.

6. Design mechanisms for achieving effective data man
-

agement.

7. If required, develo
p a design to handle task manage
-

ment.


Refining Operations


Once objects in the problem domain have been identified,

the designer selects the set of operations that act on the

objects. Operations are identified by examining all verbs

stated in the inform
al strategy (the processing narrative).

As an example, recall our discussion from ESE Module 5
-
1.

Although many different types of operations exist,

they can generally be divided into three broad categories:

(1) operations that manipulate data in some way
(e.g.,

adding, deleting, reformatting, selecting); (2) operations

that perform a computation; (3) operations that monitor an

object for the occurrence of a controlling event.

In ESE Module 5
-
1, we explored a fragment of the

SafeHome processing narrative: "
sensor
is assigned

a num
-

ber and type" and "a master password
is promammed

for

arming and disarming the system." These two phrases indi
-

cate a number of things:




that an assign operation is relevant for the sensor

object;



that a program operation will be

applied to the system

object;



that arm and disarm are operations that apply to sys
-

tem (also that system status may ultimately be defined

(using data dictionary notation) as


system status = [armed | disarmed]

PROC specification of related operations...

PRIVATE

data structure details for objects

PACKAGE BODY program
-
component
-
name IS

PROC operation.1 (interface description) IS


.


.


.

END

PROC operation.n (interface description) IS


.


.


.

END

END program
-
component
-
name


Referring to the Ada
-
like PDL (
program design lan
-

guage) shown above, a program component is specified by

indicating both data objects and operations. The specifica
-

tion
-
part of the component indicates all data objects

(declared with the TYPE statement) and the operations

(PROC for pr
ocedure) that act on them. The private part

(PRIVATE) of the component provide otherwise

hidden

details of data structure and processing. In the context of

our earlier discussion, the PACKAGE is conceptually simi
-

lar to the encapsulated object definition.

The first program component to be identified should

be the highest level module from which all processing orig
-

inates and all data structures evolve. Referring once again

to the SafeHome example considered in preceding sections,

we can define the highest

level program component as:


PROCEDURE SafeHome software


The SafeHome software component can be coupled with a

preliminary design for the following packages (objects):


PACKAGE system IS

TYPE system data

PROC install, define, build, load

PROC display, re
set, query, modify, call

PRIVATE

PACKAGE BODY system IS

PRIVATE

system.id IS STRING LENGTH (8);

verification phone number,

telephone number,... IS STRING LENGTH (8);

sensor table DEFINED

sensor type IS STRING LENGTH (2),

sensor number, alarm threshold IS

N
UMERIC;

PROC install RECEIVES (telephone number)

(design detail for operation install)


.


.


.

END system

The operation program is allocated during OOA, but dur
-

ing OOD it will be refined into a number of more specific

operations that are required to con
figure the system. For

example, after discussions with product engineering, the

analyst and possibly the marketing department, the

designer might elaborate the original processing narrative

and write the following narrative for program:


Program enables th
e SafeHome user to configure the

system once it has been installed. The user can (1) install

phone numbers; (2) define delay times for alarms; (3) build

a sensor table that contains each sensor ID, its type and

location; and (4) load a master password.


Th
erefore, the designer has refined the single opera
-

tion program and replaced it with the operations:
install
,

define
,
build

and
load
. Each of these new operations

becomes part of the system object, has knowledge of the

internal data structures that implem
ent the object's attrib
-

utes and are invoked by sending the object messages of the

form:


MESSAGE (system)
--
> install: SENDS telephone number;


which implies that to provide the system with an emer
-

gency phone number, an install message will be sent to

system
.

Verbs connote actions or occurrences. In the context of

OOD formalization, we consider not only verbs but also

descriptive verb phrases and predicates (e.g., "is equal to")

as potential operations. The grammatical parse is applied

recursively until

each operation has been refined to its

most detailed level.


Program Components and Interfaces


An important aspect of software design
quality
is modular
-

ity
-
that is, the specification of program components

(modules) that are combined to form a complete
program.

The object
-
oriented approach defines the object as a pro
-

gram component that is itself linked to other components

(e.g., private data, operations). But defining objects and

operations is not enough. During design, we must also

identify the interf
aces that exist between objects and the

overall structure (considered in an architectural sense) of

the objects.

Although a program component is a design abstrac
-

tion, it should be represented in the context of the pro
-

gramming language with which the de
sign is to be imple
-

mented. To accommodate OOD, the programming lan
-

guage to be used for implementation should be capable of

creating the following program component (modeled after

Ada):


PACKAGE program
-
component
-
name IS

TYPE specification of data objec
t

.

.

5
-
3.4 ∙ Essential

Software

Engineering


PACKAGE sensor IS

TYPE sensor data

PROC read, set, test

PRIVATE

PACKAGE BODY sensor IS

PRIVATE

sensor.id IS STRING LENGTH (8);

sensor

status

IS STRING LENGTH (8);

alarm characteristics DEFINED

threshold, signal
type, signal

level IS NUMERIC,

hardware interface DEFINED

type, a/d.characteristics,

timing.data IS NUMERIC,

END sensor

.

.

.

END SafeHome software


Data objects and corresponding operations are speci
-

fied for each of the program components for SafeHome

s
oftware. It should be noted that many details have not as

yet been specified about the private
-
part of the data objects

or details of the operations. These implementation details

are considered later.

Once program components have been identified, we

are re
ady to examine the evolving design and critically

assess the need for changes. It it likely that a review of the

first
-
cut definition of packages will result in modifications

that add new objects or return to earlier OOD steps (i.e.,

the informal strategy)

to assess the completeness of opera
-

tions that have been specified.


A Notation for OOD


In ESE Module 5
-
2, we used a graphical notation for the

representation of objects and other structures that has been

proposed by Goad and Yourdon [1]. This approach
is

extended to accommodate OOD and is discussed in some

detail in the video segment that follows this reading.


The remainder of this reading presents an overvie
w
of
an

alternative approach and notation proposed by Booch
[2].


Booch proposes the notation t
hat combines four distinct

diagrams to create an object
-
oriented design. A class dia
-

gram depicts classes and their relationships. An object
-
dia
-

gram represents specific objects (instances of a class) and

the messages that pass among them. Classes and ob
jects

are allocated to specific software components as part of a

physical design. The module diagram, sometimes called a

Booch diagram, is used to illustrate these program compo
-

nents. Because many object
-
oriented systems contain a

number of programs that

may be executing on a set of dis
-

tributed processors, Booch also suggests a notation, called

a process diagram, that enables the designer to depict how

processes are allocated to specific processors within a large

system.


Representing Class and Object R
elationships


Booch 12] suggests diagrams that depict classes and objects

and the relationships among them. The class diagram,

illustrated in Figure 1, indicates the class "architecture" for

a system. Inheritance is shown with an arrow symbol, and

the doub
le line connectors indicate that one class makes

use of information contained within another class. The

symbols at the ends of the uses (double line) notation indi
-

cate cardinality. For example, for every instance of class A

in the Figure, there will be o
ne or more instances (indicated

by the + sign) of class D. In addition to the class diagram

itself, each class can be defined with a template that

includes its name, attributes and operations, as well as

information about inheritance, parameters and behavi
or. It

should be noted that the class template is not actually part

of the diagram, but is created as a supplement to it.


Classes are defined as part of the design of a system

and exist regardless of the execution behavior of the sys
-

tem. Objects, howev
er, are created and removed dynami
-

cally as a program executes. For this reason, a notation that

captures the "dynamic semantics" or a "time lapse snap
-

shot" [2] of a program can be invaluable to a designer. The

object diagram (Figure 2) depicts each ins
tance of a class,

the operations that will be applied, and the messages that

are passed. The connecting line between objects that is ter
-

minated by a labeled square indicates the type of data that

is contained within a message. The arrow parallel to the

l
ine indicates the type of
synchronization
between objects

(e.g., synchronous, asynchronous, time
-
out). An object tem
-

plate is created for each object and defines the object and

the messages that are passed to it.

Object
-
Oriented

Design
..
5
-
3.5

5
-
3.6 ∙∙ E
ssential Software Engineering



Modularity is one of the most important concepts in soft
-

ware design. But how is the concept of a module defined

when OOD is applied? The answer to this question leads

us to a design notation that allocates classes and obj
ects to

physical program components (modules) and thereby rep
-

resents an implementation view of the program architec
-

ture. The module diagram represents a program compo
-

nent (object) as a box that can be divided into a specifica
-

tion part (visible to t
he outside) and a private part (also

called a body part) that is hidden from the outside. At this

stage, the implementation details that are part of the pri
-

vate part or package body are not yet specified. Data

objects are noted by an elongated oval while

operations

that act on the objects are notated by rectangles.


Software for a computer
-
based system is executed by

one or more processors (computers) that interact with other

devices through a series of defined connections. The use of

object
-
oriented des
ign and implementation does not alter

this fact. Therefore, the process diagram (Figure 3) is used

to indicate the processors (shaded boxes), devices (white

boxes) and connections (lines) that define the hardware

architedure of a system. The software proce
sses that exe
-

cute on a given processor are also noted on the diagram.

A detailed example using the notation presented in

this section is beyond the scope of ESE. The interested

reader should refer to Booch [2], or his more recent book

[3] , where case st
udies in a variety of application areas are

presented.

The use of graphical notation for OOD is not essential,

but it does provide an indication of relationships among

classes and objects that is lacking in a PDL representation.

The notation proposed by Bo
och can be used to represent

program components at a relatively high level of abstrac
-

tion. When implementation detail design commences, the

graphical notation is abandoned and PDL is used as the

design representation.


[1] Goad, P. and Yourdon E.(1991)
Object
-
Oriented Analysis,

Prentice
-
Hall, 2/e

[2] Booch, G.(1990)
Object
-
Oriented Design,
Benjamin
-

Cummings

[3] Booch, G. (1994)
Object
-
Oriented Analysis and Design,
2/e,
Benjamin
-
Cummings


Exercise 5
-
6

Developing a problem Domain Design


Using

the

ideas

presented

in

the

preceding

video

seg
-

ment

and

the

reading,

attempt

to

develop

a rudi
-

mentary

OOD

model

for

the

OOA

model

that

you

ore
-

ated

as

part

of

exercise

5
-
4.

Perform

the

following

tasks:


1.

Refine

the

work

done

during

OOA,

looking

for

sub
-

clas
ses,

message

characteristics,

and

other

elabora
-

tion

of

detail.


2. Represent

the

data

strrcture(s)

associated

with

object

attributes.


3.

Represent

the

procedural

detail

associated

with

each

operation.

You

may

choose

only

a

few

opera
-

tions

if

you'd

li
ke.


4.

Design

the

messaging

protocol

and

represent

actual

messages

to

be

passed

between

objects.


5.

Design

the

human
-
computer

interface

and

repre
-

sent

objects

that

are

required

to

implement

it.


6.

Design

mechanisms

for

achieving

effective

data

manag
ement.


7.

If

required,

develop

a design

to

handle

task

man
-

agement.


8. Discuss you r design with a colleague




Post
-
Test, Module 5
-
3


This

post
-
test

has

been

designed

to

help

you

assess

the

degree

to

which

you've

absorbed

the

information

presented

in

thi
s

ESE

Module.


Object
-
Oriented Design


1. When

we

apply

design

to

the

OOA

model,

attrib
-

utes

are

translated

into:

a.

data structures

b.

PDL

c.

a messaging protocol

d.

none

of

the

above


2.

When

doing

problem

domain

design,

the

source

of

information

required

to

develop

the

majority

of

the

algorithms

will

come

from

the:

a.

customer

b.

the

computing

environment

c.

the method

d.

the

development group


3.

Object orientation

leads

to:

a.

low coupling

b.

high

cohesion

c.

information

hiding

d.

all

of

the

above

e.

none

of the above


4.

When

an

object

receives

a message,

it:

a.

invokes an

attribute

b.

invokes a

method

c.

passes

it along

d.

does nothing


5.

Which

of

the

following

design

approaches

is

applicable

to

methods:

a.

stepwise

refinement

b.

structured

programming

c.

proof

of

correctness

d.

all

of

the above

e.

none

of

the

above


6.

Part

of

OOD

is

the

creation

of

a messaging

model

(MM).

The

best

way

to

begin

the

design

of

the

MM

is

by:

a.

examining

each

method

b.

studying

the

instance

connections

described

as

part

of

OOA

c.

examining the class

hierarchy

d.

examining

an

object diagram

Object
-
Oriented Design .. 5
-
3.7

7. Message

synchronization

describes:

a.

when

messages are sent

b.

how

the

message

is

timed

relative

to

system
functi
on

c.

how the sender and

receiver react when a
message

is

sent

d.

how

multiple

messages

are

synchronized

so
that they don’t conflict


8. Human

interaction

design

is

best

accomplished by:

a.

designing

all

objects

required

to

accomplish the

human

interfa
ce

b.

reusing as many GUI

classes as possible

c.

building

an

interface simulation

d.

identifying

all

interface

messages


9.

The objective of data

management design is:

a.

to

manage

user

data

b.

to

manage

objects

instantiated

during

the

execution

of

t
he

system

c.

to manage all

program data structures

d.

to

manage

all

attributes


10.

OOD

should

begin

with:

a.

problem domain

component

b.

human

interaction

component

c.

data

management component

d.

task

management component


11.

Task

management

desig
n

is

required

whenever:

a.

an

application

performs

more

than

a single

function

b.

an application spawns

multiple asynchronous

tasks

c.

an

application

is

implemented

as

part

of

a

real
-
time

system

d.

none of

the

above


12.

What

happens

if

an

object

receiv
es

a message

that

it

cannot

properly

process:

a.

nothing

b.

a return

value

is

generated

and

sent

to

the

sender

c.

task

management takes

over

d.

none

of

the

above

Copyright 1995 R.S. Pressman & Associates, Inc.

No part of this material may be electr
onically copied,
transmitted, or posted without the express written
permission of R.S. Pressman & Associates, Inc.


These materials have been posted on the Local Web
Server of the Department of Computer Science with
permission of R.S. Pressman & Associates
, Inc. and are
for use only by students registered for DCS/235 at
Queen Mary and Westfield College.