[PDF] - 38 Chapter 3 Ob ject-Orien ted Design A sup ercial PDF Document

SLIDE 1 38

SLIDE 2 Chapter 3 Ob ject-Orien ted Design A sup ercial description

f

the distinction b et w een an

b

ject-orien ted language, suc h as Ja v a, and a con v en tional programming language, suc h as P ascal, migh t concen trate

n

syn- tactic dierences. In this area discussion w

uld

cen ter

n

topics suc h as classes, inheritance, message passing, and metho ds. But suc h an analysis miss the most imp

rtan

t p

in

t

f
b

ject-orien ted programming, whic h has nothing to do with syn tax. W

rking

in an

b

ject-orien ted language (that is,

ne

that supp

rts

inheritance, message passing, and classes) is neither a necessary nor sucien t condition for doing

b

ject-orien ted programming. As w e emphasized in Chapter 1, an

b

ject-orien ted program is lik e a com- m unit y

f

in teracting individuals, eac h ha ving assigned resp

nsibilities,

w

rking

together to w ards the attainmen t

f

a common goal. As in real life, a ma jor asp ect in the design

f

suc h a comm unit y is determining the sp ecic resp

nsibilities

for eac h mem b er. T

this

end, practicioners

f
b

ject-orien ted design ha v e dev elop ed a design tec hnique driv en b y the sp ecication and delegation

f

resp

nsibilities.

This tec hnique has b een called r esp

nsibility-

driven design [Wirfs-Bro c k 1989b , Wirfs-Bro c k 1990 ]. 3.1 Resp

nsibilit

y Implies Nonin terference As an y

ne

can attest who can remem b er b eing a c hild,

r

who has raised c hildren, resp

nsi-

bilit y is a sw

rd

that cuts b

th

w a ys. When y

u

mak e an

b

ject (b e it a c hild

r

a soft w are system) resp

nsible

for sp ecic actions, y

u

exp ect a certain b eha vior, at least when the rules are

bserv

ed. But just as imp

rtan

t, resp

nsibilit

y implies a degree

f

indep endence

r

nonin terference. If y

u

tell a c hild that she is resp

nsible

for cleaning her ro

m,

y

u

do not normally stand

v

er her and w atc h while that task is b eing p erformed{that is not the nature

f

resp

nsibilit

y . Instead, y

u

exp ect that, ha ving issued a directiv e in the correct fashion, the desired

utcome

will b e pro duced. Similarly , in the

w

ers example from Chapter 1, I giv e the request to deliv er

w

ers to 39

SLIDE 3 40 CHAPTER 3. OBJECT-ORIENTED DESIGN m y

rist

without stopping to think ab

ut

ho w m y request will b e serviced. Flora, ha ving tak en

n

the resp

nsibilit

y for this service, is free to

p

erate without in terference

n

m y part. The dierence b et w een con v en tional programming and

b

ject-orien ted programming is in man y w a ys the dierence b et w een activ ely sup ervising a c hild while she p erforms a task, and delegating to the c hild resp

nsibilit

y for that p erformance. Con v en tional programming pro ceeds largely b y doing something to something else{mo difying a record

r

up dating an arra y , for example. Th us,

ne

p

rtion
f

co de in a soft w are system is

ften

in timately tied, b y con trol and data connections, to man y

ther

sections

f

the system. Suc h dep endencies can come ab

ut

through the use

f

global v ariables, through use

f

p

in

ter v alues,

r

simply through inappropriate use

f

and dep endence

n

implemen tation details

f
ther

p

rtions
f

co de. A resp

nsibilit

y-driv en design attempts to cut these links,

r

at least mak e them as unobtrusiv e as p

ssible.

This notion migh t at rst seem no more subtle than the notions

f

information hiding and mo dularit y , whic h are imp

rtan

t to programming ev en in con v en tional languages. But resp

nsibilit

y-driv en design elev ates information hiding from a tec hnique to an art. This principle

f

information hiding b ecomes vitally imp

rtan

t when

ne

mo v es from programming in the small to programming in the large. One

f

the ma jor b enets

f
b

ject-orien ted programming

ccurs

when soft w are subsystems are reused from

ne

pro ject to the next. F

r

example, a sim ulation system migh t w

rk

for b

th

a sim ulation

f

balls

n

a billiards table and a sim ulation

f

sh in a sh tank. This abilit y to reuse co de implies that the soft w are can ha v e almost no domain-sp ecic com- p

nen

ts; it m ust totally delegate resp

nsibilit

y for domain-sp ecic b eha vior to application- sp ecic p

rtions
f

the system. The abilit y to create suc h reusable co de is not

ne

that is easily learned{it requires exp erience, careful examination

f

case studies (paradigms, in the

riginal

sense

f

the w

rd),

and use

f

a programming language in whic h suc h delegation is natural and easy to express. In subsequen t c hapters, w e will presen t sev eral suc h examples. 3.2 Programming in the Small and in the Large The dierence b et w een the dev elopmen t

f

individual pro jects and

f

more sizable soft w are systems is

ften

describ ed as programming in the small v ersus programming in the large. Programming in the small c haracterizes pro jects with the follo wing attributes:

Co

de is dev elop ed b y a single programmer,

r

p erhaps b y a v ery small collection

f

programmers. A single individual can understand all asp ects

f

a pro ject, from top to b

ttom,

b eginning to end.

The

ma jor problem in the soft w are dev elopmen t pro cess is the design and dev elopmen t

f

algorithms for dealing with the problem at hand. Programming in the large,

n

the

ther

hand, c haracterizes soft w are pro jects with features suc h as the follo wing:

SLIDE 4 3.3. WHY BEGIN WITH BEHA VIOR? 41

The

soft w are system is dev elop ed b y a large team

f

programmers. Individuals in v

lv

ed in the sp ecication

r

design

f

the system ma y dier from those in v

lv

ed in the co ding

f

individual comp

nen

ts, who ma y dier as w ell from those in v

lv

ed in the in tegration

f

v arious comp

nen

ts in the nal pro duct. No single individual can b e considered resp

nsible

for the en tire pro ject,

r

ev en necessarily understands all asp ects

f

the pro ject.

The

ma jor problem in the soft w are dev elopmen t pro cess is the managemen t

f

details and the comm unication

f

information b et w een div erse p

rtions
f

the pro ject. While the b eginning studen t will usually b e acquain ted with programming in the small, asp ects

f

man y

b

ject-orien ted languages are b est understo

d

as resp

nses

to the problems encoun tered while programming in the large. Th us, some appreciation

f

the diculties in v

lv

ed in dev eloping large systems is a helpful prerequisite to understanding OOP . 3.3 Wh y Begin with Beha vior? Wh y b egin the design pro cess with an analysis

f

b eha vior? The simple answ er is that the b eha vior

f

a system is usually understo

d

long b efore an y

ther

asp ect. Earlier soft w are dev elopmen t tec hniques concen trated

n

ideas suc h as c haracterizing the basic data structures

r

the

v

erall sequence

f

function calls,

ften

within the creation

f

a formal sp ecication

f

the desired application. But structural elemen ts

f

the application can b e iden tied

nly

after a considerable amoun t

f

problem analysis. Similarly , a formal sp ecication

ften

ended up as a do cumen t understo

d

b y neither programmer nor clien t. But b ehavior is something that can b e describ ed almost from the momen t an idea is conceiv ed, and (often unlik e a formal sp ecication) can b e describ ed in terms meaningful to b

th

the programmers and the clien t. W e will illustrate the application

f

Resp

nsibilit

y-Driv en Design (RDD) with a case study . 3.4 A Case Study in RDD Imagine y

u

are the c hief soft w are arc hitect in a ma jor computer rm. One da y y

ur

b

ss

w alks in to y

ur
ce

with an idea that, it is hop ed, will b e the next ma jor success in y

ur

pro duct line. Y

ur

assignmen t is to dev elop the Inter active Intel ligent Kitchen Help er (Figure 3.1). The task giv en to y

ur

soft w are team is stated in v ery few w

rds,

written

n

what app ears to b e the bac k

f

a sligh tly-used dinner napkin, in handwriting that app ears to b e y

ur

b

ss's.

SLIDE 5 42 CHAPTER 3. OBJECT-ORIENTED DESIGN ' & $ % W elcome to the I IKH the In teractiv e In telligen t Kitc hen Help er Press Return to b egin

22222222

222222222 2222222 H H H H H H H

P

P P P P P

P

P P P P P H H H H H H H H H H H H H H

H

H H H H H H

P

P P P P P H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H H Figure 3.1: { View

f

the In teractiv e In telligen t Kitc hen Help er. 3.4.1 The In teractiv e In telligen t Kitc hen Help er Briey , the In teractiv e In telligen t Kitc hen Help er (I IKH) is a PC-based application that will replace the index-card system

f

recip es found in the a v erage kitc hen. But more than simply main taining a database

f

recip es, the kitc hen help er assists in the planning

f

meals for an extended p erio d, sa y a w eek. The user

f

the I IKH can sit do wn at a terminal, bro wse the database

f

recip es, and in teractiv ely create a series

f

men us. The I IKH will automatically scale the recip es to an y n um b er

f

servings and will prin t

ut

men us for the en tire w eek, for a particular da y ,

r

for a particular meal. And it will prin t an in tegrated gro cery list

f

all the items needed for the recip es for the en tire p erio d. As is usually true with the initial descriptions

f

most soft w are systems, the sp ecication for the I IKH is highly am biguous

n

a n um b er

f

imp

rtan

t p

in

ts. It is also true that, in all lik eliho

d,

the ev en tual design and dev elopmen t

f

the soft w are system to supp

rt

the I IKH will require the eorts

f

sev eral programmers w

rking

together. Th us, the initial goal

f

the soft w are team m ust b e to clarify the am biguities in the description and to

utline

ho w the pro ject can b e divided in to comp

nen

ts to b e assigned for dev elopmen t to individual

SLIDE 6 3.4. A CASE STUD Y IN RDD 43 team mem b ers. The fundamen tal cornerstone

f
b

ject-orien ted programming is to c haracterize soft w are in terms

f

b ehavior; that is, actions to b e p erformed. W e will see this rep eated

n

man y lev els in the dev elopmen t

f

the I IKH. Initially , the team will try to c haracterize, at a v ery high lev el

f

abstraction, the b eha vior

f

the en tire application. This then leads to a description

f

the b eha vior

f

v arious soft w are subsystems. Only when all b eha vior has b een iden tied and describ ed will the soft w are design team pro ceed to the co ding step. In the next sev eral sections w e will trace the tasks the soft w are design team will p erform in pro ducing this application. 3.4.2 W

rking

through Scenarios The rst task is to rene the sp ecication. As w e ha v e already noted, initial sp ecications are almost alw a ys am biguous and unclear

n

an ything except the most general p

in

ts. There are sev eral goals for this step. One

b

jectiv e is to get a b etter handle

n

the \lo

k

and feel"

f

the ev en tual pro duct. This information can then b e carried bac k to the clien t (in this case, y

ur

b

ss)

to see if it is in agreemen t with the

riginal

conception. It is lik ely , p erhaps inevitable, that the sp ecications for the nal application will c hange during the creation

f

the soft w are system, and it is imp

rtan

t that the design b e dev elop ed to easily accommo date c hange and that p

ten

tial c hanges b e noted as early as p

ssible.

(See Section 3.6.2; \Preparing for Change.") Equally imp

rtan

t, at this p

in

t v ery high lev el decisions can b e made concerning the structure

f

the ev en tual soft w are system. In particular, the activities to b e p erformed can b e mapp ed

n

to comp

nen

ts. 3.4.3 Iden tication

f

Comp

nen

ts The engineering

f

a complex ph ysical system, suc h as a building

r

an automobile engine, is simplied b y dividing the design in to smaller units. So, to

,

the engineering

f

soft w are is simplied b y the iden tication and dev elopmen t

f

soft w are comp

nen

ts. A c

mp
nent

is simply an abstract en tit y that can p erform tasks{that is, fulll some resp

nsibilities.

A t this p

in

t, it is not necessary to kno w exactly the ev en tual represen tation for a comp

nen

t

r

ho w a comp

nen

t will p erform a task. A comp

nen

t ma y ultimately b e turned in to a function, a structure

r

class,

r

a collection

f
ther

comp

nen

ts (a p attern). A t this lev el

f

dev elopmen t there are just t w

imp
rtan

t c haracteristics:

A

comp

nen

t m ust ha v e a small w ell-dened set

f

resp

nsibilities.
A

comp

nen

t should in teract with

ther

comp

nen

ts to the minimal exten t p

ssible.

W e will shortly discuss the reasoning b ehind the second c haracteristic. F

r

the momen t w e are simply concerned with the iden tication

f

comp

nen

t resp

nsibilities.

SLIDE 7 44 CHAPTER 3. OBJECT-ORIENTED DESIGN 3.5 CR C Cards{Recording Resp

nsibilit

y In

rder

to disco v er comp

nen

ts and their resp

nsibilities,

the programming team w alks through scenarios. That is, the team acts

ut

the running

f

the application just as if it already p

ssessed

a w

rking

system. Ev ery activit y that m ust tak e place is iden tied and assigned to some comp

nen

t as a resp

nsibilit

y . Comp

nent

Name Collab

rato

rs List

f
ther

c

mp
nents

Description

f

the resp

nsibilities

assigned to this comp

nen

t As part

f

this pro cess, it is

ften

useful to represen t comp

nen

ts using small index cards. W ritten

n

the face

f

the card is the name

f

the soft w are comp

nen

t, the resp

n-

sibilities

f

the comp

nen

t, and the names

f
ther

comp

nen

ts with whic h the comp

nen

t m ust in teract. Suc h cards are sometimes kno wn as CR C (Comp

nent,

Resp

nsibilit

y, Collab-

rato

r) cards [Bec k 1989 , Bellin 97 ], and are asso ciated with eac h soft w are comp

nen

t. As resp

nsibilities

for the comp

nen

t are disco v ered, they are recorded

n

the face

f

the CR C card. 3.5.1 Giv e Comp

nen

ts a Ph ysical Represen tation While w

rking

through scenarios, it is useful to assign CR C cards to dieren t mem b ers

f

the design team. The mem b er holding the card represen ting a comp

nen

t records the resp

nsibilities
f

the asso ciated soft w are comp

nen

t, and acts as the \surrogate" for the soft w are during the scenario sim ulation. He

r

she describ es the activities

f

the soft w are system, passing \con trol" to another mem b er when the soft w are system requires the services

f

another comp

nen

t. An adv an tage

f

CR C cards is that they are widely a v ailable, inexp ensiv e, and erasable. This encourages exp erimen tation, since alternativ e designs can b e tried, explored,

r

aban-

SLIDE 8 3.5. CR C CARDS{RECORDING RESPONSIBILITY 45 doned with little in v estmen t. The ph ysical separation

f

the cards encourages an in tuitiv e understanding

f

the imp

rtance
f

the logical separation

f

the v arious comp

nen

ts, helping to emphasize the cohesion and coupling (whic h w e will describ e shortly). The constrain ts

f

an index card are also a go

d

measure

f

appro ximate complexit y{a comp

nen

t that is exp ected to p erform more tasks than can t easily in this space is probably to

complex,

and the team should nd a simpler solution, p erhaps b y mo ving some resp

nsibilities

elsewhere to divide a task b et w een t w

r

more new comp

nen

ts. 3.5.2 The What/Who Cycle As w e noted at the b eginning

f

this discussion, the iden tication

f

comp

nen

ts tak es place during the pro cess

f

imagining the execution

f

a w

rking

system. Often this pro ceeds as a cycle

f

what/who questions. First, the programming team iden ties what activit y needs to b e p erformed next. This is immediately follo w ed b y answ ering the question

f

who p erforms the action. In this manner, designing a soft w are system is m uc h lik e

rganizing

a collection

f

p eople, suc h as a club. An y activit y that is to b e p erformed m ust b e assigned as a resp

nsibilit

y to some comp

nen

t. W e kno w, from real life, that if an y action is to tak e place, there m ust b e an agen t assigned to p erform it. Just as in the running

f

a club an y action to b e p erformed m ust b e assigned to some individual, in

rganizing

an

b

ject-orien ted program all actions m ust b e the resp

nsibilit

y

f

some comp

nen

t. The secret to go

d
b

ject-orien ted design is to rst establish an agen t for eac h action. 3.5.3 Do cumen tation A t this p

in

t the dev elopmen t

f

do cumen tation should b egin. Tw

do

cumen ts should b e essen tial parts

f

an y soft w are system: the user man ual and the system design do cumen- tation. W

rk
n

b

th
f

these can commence ev en b efore the rst line

f

co de has b een written. The user man ual describ es the in teraction with the system from the user's p

in

t

f

view; it is an excellen t means

f

v erifying that the dev elopmen t team's conception

f

the application matc hes the clien t's. Since the decisions made in creating the scenarios will closely matc h the decisions the user will b e required to mak e in the ev en tual application, the dev elopmen t

f

the user man ual naturally do v etails with the pro cess

f

w alking through scenarios. Before an y actual co de has b een written, the mindset

f

the soft w are team is most similar to that

f

the ev en tual users. Th us, it is at this p

in

t that the dev elop ers can most easily an ticipate the sort

f

questions to whic h a no vice user will need answ ers. The second essen tial do cumen t is the design do cumen tation. The design do cumen tation records the ma jor decisions made during soft w are design, and should th us b e pro duced when these decisions are fresh in the minds

f

the creators, and not after the fact when man y

f

the relev an t details will ha v e b een forgotten. It is

ften

far easier to write a general global

SLIDE 9 46 CHAPTER 3. OBJECT-ORIENTED DESIGN description

f

the soft w are system early in the dev elopmen t. T

so
n,

the fo cus will mo v e to the lev el

f

individual comp

nen

ts

r

mo dules. While it is also imp

rtan

t to do cumen t the mo dule lev el, to

m

uc h concern with the details

f

eac h mo dule will mak e it dicult for subsequen t soft w are main tainers to form an initial picture

f

the larger structure. CR C cards are

ne

asp ect

f

the design do cumen tation, but man y

ther

imp

rtan

t decisions are not reected in them. Argumen ts for and against an y ma jor design alternativ es should b e recorded, as w ell as factors that inuenced the nal decisions. A log

r

diary

f

the pro ject sc hedule should b e main tained. Both the user man ual and the design do cumen ts are rened and ev

lv

e

v

er time in exactly the same w a y the soft w are is rened and ev

lv

es. 3.6 Comp

nen

ts and Beha vior T

return

to the I IKH, the team decides that when the system b egins, the user will b e presen ted with an attractiv e informativ e windo w (see Figure 3.1). The resp

nsibilit

y for displa ying this windo w is assigned to a comp

nen

t called the Greeter. In some as y et unsp ecied manner (p erhaps b y pull-do wn men us, button

r

k ey presses,

r

use

f

a pressure- sensitiv e screen), the user can select

ne
f

sev eral actions. Initially , the team iden ties just v e actions: 1. Casually bro wse the database

f

existing recip es, but without reference to an y particular meal plan. 2. Add a new recip e to the database. 3. Edit

r

annotate an existing recip e. 4. Review an existing plan for sev eral meals. 5. Create a new plan

f

meals. These activities seem to divide themselv es naturally in to t w

groups.

The rst three are asso ciated with the recip e database; the latter t w

are

asso ciated with men u plans. As a result, the team next decides to create comp

nen

ts corresp

nding

to these t w

resp
nsibilities.

Con tin uing with the scenario, the team elects to ignore the meal plan managemen t for the momen t and mo v e

n

to rene the activities

f

the Recip e Database comp

nen

t. Figure 3.2 sho ws the initial CR C card represen tation

f

the Greeter. Broadly sp eaking, the resp

nsibilit

y

f

the recip e database comp

nen

t is simply to main- tain a collection

f

recip es. W e ha v e already iden tied three elemen ts

f

this task: The recip e comp

nen

t database m ust facilitate bro wsing the library

f

existing recip es, editing the recip es, and including new recip es in the database.

SLIDE 10 3.6. COMPONENTS AND BEHA VIOR 47 Greeter Collab

rato

rs Database Manager Plan Manager Displa y Informativ e Initial Message Oer User Choice

f

Options P ass Con trol to either Recip e Database Manager Plan Manager for pro cessing Figure 3.2: { CR C card for the Greeter. 3.6.1 P

stp
ning

Decisions There are a n um b er

f

decisions that m ust ev en tually b e made concerning ho w b est to let the user bro wse the database. F

r

example, should the user rst b e presen ted with a list

f

categories, suc h as \soups," \salads," \main meals," and \desserts"? Alternativ ely , should the user b e able to describ e k eyw

rds

to narro w a searc h, p erhaps b y pro viding a list

f

ingredien ts, and then see all the recip es that con tain those items (\Almonds, Stra wb erries, Cheese"),

r

a list

f

previously inserted k eyw

rds

(\Bob's fa v

rite

cak e")? Should scroll bars b e used

r

sim ulated th um b holes in a virtual b

k?

These are fun to think ab

ut,

but the imp

rtan

t p

in

t is that suc h decisions do not need to b e made at this p

in

t (see next section). Since they aect

nly

a single comp

nen

t, and do not aect the functioning

f

an y

ther

system, all that is necessary to con tin ue the scenario is to assert that b y some means the user can select a sp ecic recip e. 3.6.2 Preparing for Change It has b een said that all that is constan t in life is the inevitabilit y

f

uncertain t y and c hange. The same is true

f

soft w are. No matter ho w carefully

ne

tries to dev elop the initial sp ecication and design

f

a soft w are system, it is almost certain that c hanges in the user's needs

r

requiremen ts will, sometime during the life

f

the system, force c hanges to

SLIDE 11 48 CHAPTER 3. OBJECT-ORIENTED DESIGN b e made in the soft w are. Programmers and soft w are designers need to an ticipate this and plan accordingly .

The

primary

b

jectiv e is that c hanges should aect as few comp

nen

ts as p

ssible.

Ev en ma jor c hanges in the app earance

r

functioning

f

an application should b e p

ssible

with alterations to

nly
ne
r

t w

sections
f

co de.

T

ry to predict the most lik ely sources

f

c hange and isolate the eects

f

suc h c hanges to as few soft w are comp

nen

ts as p

ssible.

The most lik ely sources

f

c hange are in terfaces, comm unication formats, and

utput

formats.

T

ry to isolate and reduce the dep endency

f

soft w are

n

hardw are. F

r

example, the in terface for recip e bro wsing in

ur

application ma y dep end in part

n

the hardw are

n

whic h the system is running. F uture releases ma y b e p

rted

to dieren t platforms. A go

d

design will an ticipate this c hange.

Reducing

coupling b et w een soft w are comp

nen

ts will reduce the dep endence

f
ne

up

n

another, and increase the lik eliho

d

that

ne

can b e c hanged with minimal eect

n

the

ther.
In

the design do cumen tation main tain careful records

f

the design pro cess and the discussions surrounding all ma jor decisions. It is almost certain that the individuals resp

nsible

for main taining the soft w are and designing future releases will b e at least partially dieren t from the team pro ducing the initial release. The design do cumen- tation will allo w future teams to kno w the imp

rtan

t factors b ehind a decision and help them a v

id

sp ending time discussing issues that ha v e already b een resolv ed. 3.6.3 Con tin uing the Scenario Eac h recip e will b e iden tied with a sp ecic recip e comp

nen

t. Once a recip e is selected, con trol is passed to the asso ciated recip e

b

ject. A recip e m ust con tain certain information. Basically , it consists

f

a list

f

ingredien ts and the steps needed to transform the ingredien ts in to the nal pro duct. In

ur

scenario, the recip e comp

nen

t m ust also p erform

ther

activities. F

r

example, it will displa y the recip e in teractiv ely

n

the terminal screen. The user ma y b e giv en the abilit y to annotate

r

c hange either the list

f

ingredien ts

r

the instruction p

rtion.

Alternativ ely , the user ma y request a prin ted cop y

f

the recip e. All

f

these actions are the resp

nsibilit

y

f

the Recip e comp

nen

t. (F

r

the momen t, w e will con tin ue to describ e the Recip e in singular form. During design w e can think

f

this as a protot ypical recip e that stands in place

f

a m ultitude

f

actual recip es. W e will later return to a discussion

f

singular v ersus m ultiple comp

nen

ts.) Ha ving

utlined

the actions that m ust tak e place to p ermit the user to bro wse the database, w e return to the recip e database manager and pretend the user has indicated a desire to add a new recip e. The database manager someho w decides in whic h category

SLIDE 12 3.6. COMPONENTS AND BEHA VIOR 49 to place the new recip e (again, the details

f

ho w this is done are unimp

rtan

t for

ur

dev elopmen t at this p

in

t), requests the name

f

the new recip e, and then creates a new recip e comp

nen

t, p ermitting the user to edit this new blank en try . Th us, the resp

nsibilities
f

p erforming this new task are a subset

f

those w e already iden tied in p ermitting users to edit existing recip es. Ha ving explored the bro wsing and creation

f

new recip es, w e return to the Greeter and in v estigate the dev elopmen t

f

daily men u plans, whic h is the Plan Manager's task. In some w a y (again, the details are unimp

rtan

t here) the user can sa v e existing plans. Th us, the Plan Manager can either b e started b y retrieving an already dev elop ed plan

r

b y creating a new plan. In the latter case, the user is prompted for a list

f

dates for the plan. Eac h date is asso ciated with a separate Date comp

nen

t. The user can select a sp ecic date for further in v estigation, in whic h case con trol is passed to the corresp

nding

Date comp

nen

t. Another activit y

f

the Plan Manager is prin ting

ut

the recip es for the planning p erio d. Finally , the user can instruct the Plan Manager to pro duce a gro cery list for the p erio d. The Date comp

nen

t main tains a collection

f

meals as w ell as an y

ther

annotations pro vided b y the user (birthda y celebrations, anniv ersaries, reminders, and so

n).

It prin ts information

n

the displa y concerning the sp ecied date. By some means (again unsp ecied), the user can indicate a desire to prin t all the information concerning a sp ecic date

r

c ho

se

to explore in more detail a sp ecic meal. In the latter case, con trol is passed to a Meal comp

nen

t. The Meal comp

nen

t main tains a collection

f

augmen ted recip es, where the augmen tation refers to the user's desire to double, triple,

r
therwise

increase a recip e. The Meal comp

nen

t displa ys information ab

ut

the meal. The user can add

r

remo v e recip es from the meal,

r

can instruct that information ab

ut

the meal b e prin ted. In

rder

to disco v er new recip es, the user m ust b e p ermitted at this p

in

t to bro wse the recip e database. Th us, the Meal comp

nen

t m ust in teract with the recip e database comp

nen

t. The design team will con tin ue in this fashion, in v estigating ev ery p

ssible

scenario. The ma jor category

f

scenarios w e ha v e not dev elop ed here is exceptional cases. F

r

example, what happ ens if a user selects a n um b er

f

k eyw

rds

for a recip e and no matc hing recip e is found? Ho w can the user cancel an activit y , suc h as en tering a new recip e, if he

r

she decides not to con- tin ue? Eac h p

ssibilit

y m ust b e explored, and the resp

nsibilities

for handling the situation assigned to

ne
r

more comp

nen

ts. Ha ving w alk ed through the v arious scenarios, the soft w are design team ev en tually decides that all activities can b e adequately handled b y six comp

nen

ts (Figure 3.3). The Greeter needs to comm unicate

nly

with the Plan Manager and the Recip e Database comp

nen

ts. The Plan Manager needs to comm unicate

nly

with the Date comp

nen

t; and the Date agen t,

nly

with the Meal comp

nen

t. The Meal comp

nen

t comm unicates with the Recip e Manager and, through this agen t, with individual recip es.

SLIDE 13 50 CHAPTER 3. OBJECT-ORIENTED DESIGN

Plan

Manager Date Greeter Recip e Database Meal Recip e

@

@ H H H H H H H

Q

Q Q Q Q Figure 3.3: { Comm unication b et w een the six comp

nen

ts in the I IKH. 3.6.4 In teraction Diagrams While a description suc h as that sho wn in Figure 3.3 ma y describ e the static relationships b et w een comp

nen

ts, it is not v ery go

d

for describing their dynamic in teractions during the execution

f

a scenario. A b etter to

l

for this purp

se

is an inter action diagr am. Figure 3.4 sho ws the b eginning

f

an in teraction diagram for the in teractiv e kitc hen help er. In the diagram, time mo v es forw ard from the top to the b

ttom.

Eac h comp

nen

t is represen ted b y a lab eled v ertical line. A comp

nen

t sending a message to another comp

nen

t is represen ted b y a horizon tal arro w from

ne

line to another. Similarly , a comp

nen

t returning con trol and p erhaps a result v alue bac k to the caller is represen ted b y an arro w. (Some authors use t w

dieren

t arro w forms, suc h as a solid line to represen t message passing and a dashed line to represen t returning con trol.) The commen tary

n

the righ t side

f

the gure explains more fully the in teraction taking place. With a time axis, the in teraction diagram is able to describ e b etter the sequencing

f

ev en ts during a scenario. F

r

this reason, in teraction diagrams can b e a useful do cumen tation to

l

for complex soft w are systems. 3.7 Soft w are Comp

nen

ts In this section w e will explore a soft w are comp

nen

t in more detail. As is true

f

all but the most trivial ideas, there are man y asp ects to this seemingly simple concept. 3.7.1 Beha vior and State W e ha v e already seen ho w comp

nen

ts are c haracterized b y their b eha vior, that is, b y what they can do. But comp

nen

ts ma y also hold certain information. Let us tak e as

SLIDE 14 3.7. SOFTW ARE COMPONENTS 51 Greeter Database Recip e Planner Commen t Message b ro wse()

Message

displa y()

Return

from displa y()

Return

from b ro wse()

Message

mak ePlan()

Figure

3.4: { An Example in teraction diagram.

ur

protot ypical comp

nen

t a Recip e structure from the I IKH. One w a y to view suc h a comp

nen

t is as a pair consisting

f

b ehavior and state.

The

b ehavior

f

a comp

nen

t is the set

f

actions it can p erform. The complete description

f

all the b eha vior for a comp

nen

t is sometimes called the pr

to

c

l.

F

r

the Recip e comp

nen

t this includes activities suc h as editing the preparation instructions, displa ying the recip e

n

a terminal screen,

r

prin ting a cop y

f

the recip e.

The

state

f

a comp

nen

t represen ts all the information held within it. F

r
ur

Recip e comp

nen

t the state includes the ingredien ts and preparation instructions. Notice that the state is not static and can c hange

v

er time. F

r

example, b y editing a recip e (a b eha vior) the user can mak e c hanges to the preparation instructions (part

f

the state). It is not necessary that all comp

nen

ts main tain state information. F

r

example, it is p

ssible

that the Greeter comp

nen

t will not ha v e an y state since it do es not need to remem b er an y information during the course

f

execution. Ho w ev er, most comp

nen

ts will consist

f

a com bination

f

b eha vior and state. 3.7.2 Instances and Classes The separation

f

state and b eha vior p ermits us to clarify a p

in

t w e a v

ided

in

ur

earlier discussion. Note that in the real application there will probably b e man y dieren t recip es. Ho w ev er, all

f

these recip es will p erform in the same manner. That is, the b eha vior

f

eac h

SLIDE 15 52 CHAPTER 3. OBJECT-ORIENTED DESIGN recip e is the same; it is

nly

the state{the individual lists

f

ingredien ts and instructions for preparation{that diers b et w een individual recip es. In the early stages

f

dev elopmen t

ur

in terest is in c haracterizing the b eha vior common to all recip es; the details particular to an y

ne

recip e are unimp

rtan

t. The term class is used to describ e a set

f
b

jects with similar b eha vior. W e will see in later c hapters that a class is also used as a syn tactic mec hanism in Ja v a. An individual represen tativ e

f

a class is kno wn as an instanc e. Note that b eha vior is asso ciated with a class, not with an individual. That is, all instances

f

a class will resp

nd

to the same instructions and p erform in a similar manner. On the

ther

hand, state is a prop ert y

f

an individual. W e see this in the v arious instances

f

the class Recip e. They can all p erform the same actions (editing, displa ying, prin ting) but use dieren t data v alues. 3.7.3 Coupling and Cohesion Tw

imp
rtan

t concepts in the design

f

soft w are comp

nen

ts are coupling and cohesion. Cohesion is the degree to whic h the resp

nsibilities
f

a single comp

nen

t form a meaningful unit. High cohesion is ac hiev ed b y asso ciating in a single comp

nen

t tasks that are related in some manner. Probably the most frequen t w a y in whic h tasks are related is through the necessit y to access a common data area. This is the

v

erriding theme that joins, for example, the v arious resp

nsibilities
f

the Recip e comp

nen

t. Coupling,

n

the

ther

hand, describ es the relationship b et w een soft w are comp

nen

ts. In general, it is desirable to reduce the amoun t

f

coupling as m uc h as p

ssible,

since connections b et w een soft w are comp

nen

ts inhibit ease

f

dev elopmen t, mo dication,

r

reuse. In particular, coupling is increased when

ne

soft w are comp

nen

t m ust access data v alues{the state{held b y another comp

nen

t. Suc h situations should almost alw a ys b e a v

ided

in fa v

r
f

mo ving a task in to the list

f

resp

nsibilities
f

the comp

nen

t that holds the necessary data. F

r

example,

ne

migh t conceiv ably rst assign resp

nsibilit

y for editing a recip e to the Recip e Database comp

nen

t, since it is while p erforming tasks asso ciated with this comp

nen

t that the need to edit a recip e rst

ccurs.

But if w e did so, the Recip e Database agen t w

uld

need the abilit y to directly manipulate the state (the in ternal data v alues represen ting the list

f

ingredien ts and the preparation instructions)

f

an individual recip e. It is b etter to a v

id

this tigh t connection b y mo ving the resp

nsibilit

y for editing to the recip e itself. 3.7.4 In terface and Implemen tation{P arnas's Principles The emphasis

n

c haracterizing a soft w are comp

nen

t b y its b eha vior has

ne

extremely imp

rtan

t consequence. It is p

ssible

for

ne

programmer to kno w ho w to use a comp

nen

t dev elop ed b y another programmer, without needing to kno w ho w the comp

nen

t is implemente d. F

r

example, supp

se

eac h

f

the six comp

nen

ts in the I IKH is assigned to a dieren t programmer. The programmer dev eloping the Meal comp

nen

t needs to allo w

SLIDE 16 3.8. F ORMALIZE THE INTERF A CE 53 the I IKH user to bro wse the database

f

recip es and select a single recip e for inclusion in the meal. T

do

this, the Meal comp

nen

t can simply in v

k

e the b ro wse b eha vior asso ciated with the Recip e Database comp

nen

t, whic h is dened to return an individual Recip e. This description is v alid regardless

f

the particular implemen tation used b y the Recip e Database comp

nen

t to p erform the actual bro wsing action. The purp

seful
mission
f

implemen tation details b ehind a simple in terface is kno wn as information hiding. W e sa y the comp

nen

t enc apsulates the b eha vior, sho wing

nly

ho w the comp

nen

t can b e used, not the detailed actions it p erforms. This naturally leads to t w

dieren

t views

f

a soft w are system. The in terface view is the face seen b y

ther

programmers. It describ es what a soft w are comp

nen

t can p erform. The implemen tation view is the face seen b y the programmer w

rking
n

a particular comp

nen

t. It describ es how a comp

nen

t go es ab

ut

completing a task. The separation

f

in terface and implemen tation is p erhaps the most imp

rtan

t concept in soft w are engineering. Y et it is dicult for studen ts to understand,

r

to motiv ate. Informa- tion hiding is largely meaningful

nly

in the con text

f

m ultip erson programming pro jects. In suc h eorts, the limiting factor is

ften

not the amoun t

f

co ding in v

lv

ed, but the amoun t

f

comm unication required b et w een the v arious programmers and b et w een their resp ectiv e soft w are systems. As w e will describ e shortly , soft w are comp

nen

ts are

ften

dev elop ed in parallel b y dieren t programmers, and in isolation from eac h

ther.

There is also an increasing emphasis

n

the reuse

f

general-purp

se

soft w are comp

nen

ts in m ultiple pro jects. F

r

this to b e successful, there m ust b e minimal and w ell-understo

d

in terconnections b et w een the v arious p

rtions
f

the system. These ideas w ere captured b y computer scien tist Da vid P arnas in a pair

f

rules, kno wn as P arnas's principles:

The

dev elop er

f

a soft w are comp

nen

t m ust pro vide the in tended user with all the information needed to mak e eectiv e use

f

the services pro vided b y the comp

nen

t, and should pro vide no

ther

information.

The

dev elop er

f

a soft w are comp

nen

t m ust b e pro vided with all the information necessary to carry

ut

the giv en resp

nsibilities

assigned to the comp

nen

t, and should b e pro vided with no

ther

information. A consequence

f

the separation

f

in terface from implemen tation is that a programmer can exp erimen t with sev eral dieren t implemen tations

f

the same structure without aecting

ther

soft w are comp

nen

ts. 3.8 F

rmalize

the In terface W e con tin ue with the description

f

the I IKH dev elopmen t. In the next sev eral steps the descriptions

f

the comp

nen

ts will b e rened. The rst step in this pro cess is to formalize the patterns and c hannels

f

comm unication. A decision should b e made as to the general structure that will b e used to implemen t eac h comp

nen

t. A comp

nen

t with

nly
ne

b eha vior and no in ternal state ma y b e made

SLIDE 17 54 CHAPTER 3. OBJECT-ORIENTED DESIGN in to a function{for example, a comp

nen

t that simply tak es a string

f

text and translates all capital letters to lo w ercase. Comp

nen

ts with man y tasks are probably more easily implemen ted as classes. Names are giv en to eac h

f

the resp

nsibilities

iden tied

n

the CR C card for eac h comp

nen

t, and these will ev en tually b e mapp ed

n

to function

r

pro cedure names. Along with the names, the t yp es

f

an y argumen ts to b e passed to the function are iden tied. Next, the information main tained within the comp

nen

t itself should b e describ ed. All information m ust b e accoun ted for. If a comp

nen

t requires some data to p erform a sp ecic task, the source

f

the data, either through argumen t

r

global v alue,

r

main tained in ternally b y the comp

nen

t, m ust b e clearly iden tied. 3.8.1 Coming up with Names Careful though t should b e giv en to the names asso ciated with v arious activities. Shak e- sp eare has Juliet claiming that a name c hange do es not alter the

b

ject b eing describ ed, 1 but certainly not all names will conjure up the same men tal images in the listener. As go v ernmen t bureaucrats ha v e long kno wn,

bscure

and idiomatic names can mak e ev en the simplest

p

eration sound in timidating. The selection

f

useful names is extremely imp

r-

tan t, as names create the v

cabulary

with whic h the ev en tual design will b e form ulated. Names should b e in ternally consisten t, meaningful, preferably short, and ev

cativ

e in the con text

f

the problem. Often a considerable amoun t

f

time is sp en t nding just the righ t set

f

terms to describ e the tasks p erformed and the

b

jects manipulated. F ar from b eing a barren and useless exercise, prop er naming early in the design pro cess greatly simplies and facilitates later steps. The follo wing general guidelines ha v e b een suggested [Keller 1990 ]:

Use

pronounceable names. As a rule

f

th um b, if y

u

cannot read a name

ut

loud, it is not a go

d
ne.
Use

capitalization (or underscores) to mark the b eginning

f

a new w

rd

within a name, suc h as \CardReader"

r

\Card reader," rather than the less readable \cardreader."

Examine

abbreviations carefully . An abbreviation that is clear to

ne

p erson ma y b e confusing to the next. Is a \T ermPro cess" a terminal pro cess, something that terminates pro cesses,

r

a pro cess asso ciated with a terminal?

Av
id

names with sev eral in terpretations. Do es the empt y function tell whether something is empt y ,

r

empt y the v alues from the

b

ject?

Av
id

digits within a name. They are easy to misread as letters (0 as O, 1 as l, 2 as Z, 5 as S). 1 \What's in a name? That whic h w e call a rose, b y an y

ther

name w

uld

smell as sw eet; So Romeo w

uld,

w ere he not Romeo call'd, retain that dear p erfection whic h he

w

es without that title." R

me
and

Juliet, Act I I, Scene 2.

SLIDE 18 3.9. DESIGNING THE REPRESENT A TION 55 Date Collab

rato

rs Plan Manager Meal Main tain information ab

ut

sp ecic date Date(y ea r, month, da y){create new date Displa yAndEdit(){displa y date information in windo w allo wing user to edit en tries BuildGro ceryList(List &){add items from all means to gro cery list Figure 3.5: { Revised CR C card for the Date comp

nen

t.

Name

functions and v ariables that yield Bo

lean

v alues so they describ e clearly the in terpretation

f

a true

r

false v alue. F

r

example, \Prin terIsReady" clearly indicates that a true v alue means the prin ter is w

rking,

whereas \Prin terStatus" is m uc h less precise.

T

ak e extra care in the selection

f

names for

p

erations that are costly and infrequen tly used. By doing so, errors caused b y using the wrong function can b e a v

ided.

Once names ha v e b een dev elop ed for eac h activit y , the CR C cards for eac h comp

nen

t are redra wn, with the name and formal argumen ts

f

the function used to elicit eac h b eha vior iden tied. An example

f

a CR C card for the Date is sho wn in Figure 3.5. What is not y et sp ecied is ho w eac h comp

nen

t will p erform the asso ciated tasks. Once more, scenarios

r

role pla ying should b e carried

ut

at a more detailed lev el to ensure that all activities are accoun ted for, and that all necessary information is main tained and made a v ailable to the resp

nsible

comp

nen

ts. 3.9 Designing the Represen tation A t this p

in

t, if not b efore, the design team can b e divided in to groups, eac h resp

nsible

for

ne
r

more soft w are comp

nen

ts. The task no w is to transform the description

f

a

SLIDE 19 56 CHAPTER 3. OBJECT-ORIENTED DESIGN comp

nen

t in to a soft w are system implemen tation. The ma jor p

rtion
f

this pro cess is designing the data structures that will b e used b y eac h subsystem to main tain the state information required to fulll the assigned resp

nsibilities.

It is here that the classic data structures

f

computer science come in to pla y . The selection

f

data structures is an imp

rtan

t task, cen tral to the soft w are design pro cess. Once they ha v e b een c hosen, the co de used b y a comp

nen

t in the fulllmen t

f

a resp

nsibilit

y is

ften

almost self-eviden t. But data structures m ust b e carefully matc hed to the task at hand. A wrong c hoice can result in complex and inecien t programs, while an in telligen t c hoice can result in just the

pp
site.

It is also at this p

in

t that descriptions

f

b eha vior m ust b e transformed in to algorithms. These descriptions should then b e matc hed against the exp ectations

f

eac h comp

nen

t listed as a collab

rator,

to ensure that exp ectations are fullled and necessary data items are a v ailable to carry

ut

eac h pro cess. 3.10 Implemen ting Comp

nen

ts Once the design

f

eac h soft w are subsystem is laid

ut,

the next step is to implemen t eac h comp

nen

t's desired b eha vior. If the previous steps w ere correctly addressed, eac h resp

nsibilit

y

r

b eha vior will b e c haracterized b y a short description. The task at this step is to implemen t the desired activities in a computer language. In a later section w e will describ e some

f

the more common heuristics used in this pro cess. If they w ere not determined earlier (sa y , as part

f

the sp ecication

f

the system), then decisions can no w b e made

n

issues that are en tirely self-con tained within a single comp

nen

t. An decision w e sa w in

ur

example problem w as ho w b est to let the user bro wse the database

f

recip es. As m ultip erson programming pro jects b ecome the norm, it b ecomes increasingly rare that an y

ne

programmer will w

rk
n

all asp ects

f

a system. More

ften,

the skills a programmer will need to master are understanding ho w

ne

section

f

co de ts in to a larger framew

rk

and w

rking

w ell with

ther

mem b ers

f

a team. Often, in the implemen tation

f
ne

comp

nen

t it will b ecome clear that certain information

r

actions migh t b e assigned to y et another comp

nen

t that will act \b ehind the scene," with little

r

no visibilit y to users

f

the soft w are abstraction. Suc h comp

nen

ts are sometimes kno wn as facilitators. W e will see examples

f

facilitators in some

f

the later case studies. An imp

rtan

t part

f

analysis and co ding at this p

in

t is c haracterizing and do cumen ting the necessary preconditions a soft w are comp

nen

t requires to complete a task, and v erifying that the soft w are comp

nen

t will p erform correctly when presen ted with legal input v alues. This is establishing the correctness asp ect

f

the algorithms used in the implemen tation

f

a comp

nen

t.

SLIDE 20 3.11. INTEGRA TION OF COMPONENTS 57 3.11 In tegration

f

Comp

nen

ts Once soft w are subsystems ha v e b een individually designed and tested, they can b e in tegrated in to the nal pro duct. This is

ften

not a single step, but part

f

a larger pro cess. Starting from a simple base, elemen ts are slo wly added to the system and tested, using stubs{simple dumm y routines with no b eha vior

r

with v ery limited b eha vior{for the as y et unimplemen ted parts. F

r

example, in the dev elopmen t

f

the I IKH, it w

uld

b e reasonable to start in tegration with the Greeter comp

nen

t. T

test

the Greeter in isolation, stubs are written for the Recip e Database manager and the daily Meal Plan manager. These stubs need not do an y more than prin t an informativ e message and return. With these, the comp

nen

t dev elopmen t team can test v arious asp ects

f

the Greeter system (for example, that button presses elicit the correct resp

nse).

T esting

f

an individual comp

nen

t is

ften

referred to as unit testing. Next,

ne
r

the

ther
f

the stubs can b e replaced b y more complete co de. F

r

example, the team migh t decide to replace the stub for the Recip e Database comp

nen

t with the actual system, main taining the stub for the

ther

p

rtion.

F urther testing can b e p erformed un til it app ears that the system is w

rking

as desired. (This is sometimes referred to as inte gr ation testing.) The application is nally complete when all stubs ha v e b een replaced with w

rking

com- p

nen

ts. The abilit y to test comp

nen

ts in isolation is greatly facilitated b y the conscious design goal

f

reducing connections b et w een comp

nen

ts, since this reduces the need for extensiv e stubbing. During in tegration it is not uncommon for an error to b e manifested in

ne

soft w are system, and y et to b e caused b y a co ding mistak e in another system. Th us, testing during in tegration can in v

lv

e the disco v ery

f

errors, whic h then results in c hanges to some

f

the comp

nen

ts. F

llo

wing these c hanges the comp

nen

ts should b e

nce

again tested in isolation b efore an attempt to rein tegrate the soft w are,

nce

more, in to the larger system. Reexecuting previously dev elop ed test cases follo wing a c hange to a soft w are comp

nen

t is sometimes referred to as r e gr ession testing. 3.12 Main tenance and Ev

lution

It is tempting to think that

nce

a w

rking

v ersion

f

an application has b een deliv ered the task

f

the soft w are dev elopmen t team is nished. Unfortunately , that is almost nev er true. The term softwar e maintenanc e describ es activities subsequen t to the deliv ery

f

the initial w

rking

v ersion

f

a soft w are system. A wide v ariet y

f

activities fall in to this category .

Errors,
r

bugs, can b e disco v ered in the deliv ered pro duct. These m ust b e corrected, either in p atches to existing releases

r

in subsequen t releases.

Requiremen

ts ma y c hange, p erhaps as a result

f

go v ernmen t regulations

r

standard- ization among similar pro ducts.

SLIDE 21 58 CHAPTER 3. OBJECT-ORIENTED DESIGN

Hardw

are ma y c hange. F

r

example, the system ma y b e mo v ed to dieren t platforms,

r

input devices, suc h as a p en-based system

r

a pressure-sensitiv e touc h screen, ma y b ecome a v ailable. Output tec hnology ma y c hange{for example, from a text-based system to a graphical windo w-based arrangemen t.

User

exp ectations ma y c hange. Users ma y exp ect greater functionalit y , lo w er cost, and easier use. This can

ccur

as a result

f

comp etition with similar pro ducts.

Better

do cumen tation ma y b e requested b y users. A go

d

design recognizes the inevitabilit y

f

c hanges and plans an accommo dation for them from the v ery b eginning. 3.13 Chapter Summary Ob ject-orien ted programming b egins with

b

ject-orien ted design. Ob ject-orien ted design is c haracterized b y an emphasis

n

resp

nsibilit

y , rather than

n

structure. Resp

nsibilit

y and b eha vior are attributes that can b e disco v ered for a soft w are system w ell b efore an y

ther

features can b e iden tied. By systematically tracing the b eha vior

f

a system, the design

f

the soft w are elemen ts

ws

naturally from the general sp ecication. A k ey to

l

in the c haracterization

f

b eha vior is the idea

f

scenarios. Dev elop ers trace through the execution

f

an imaginary system, iden tifying actions that need to b e p erformed, and more imp

rtan

tly assigning the resp

nsibilities

for these actions to individual soft w are comp

nen

ts. A useful to

l

in this activit y is the CR C card, whic h is an index card that records the resp

nsibilities
f

a soft w are system. As design ev

lv

es, the descriptions

f

the actions

f

eac h comp

nen

t can b e rewritten in more precise formats. Dev eloping a w

rking

soft w are systems in v

lv

es man y steps, frequen tly termed the soft- w are life cycle. Design and implemen tation are the rst ma jor steps. Implemen tation can b e brok en in to the iden tication

f

comp

nen

ts, dev elopmen t and testing

f

comp

nen

ts in isolation, in tegration

f

comp

nen

ts in to larger units, and nally testing

f

the completed application. The life

f

a soft w are system do es not, ho w ev er, halt with the rst completed applications. Errors are unco v ered, requiremen ts c hange, and hardw are mo dications can all cause c hanges in the soft w are system. The managemen t

f

these c hanges that come after the rst release is kno wn as soft w are main tenance. Study Questions 1. What is the k ey idea driving

b

ject-orien ted design? 2. Ho w is the idea

f

resp

nsibilit

y tied to information hiding? 3. What are some

f

the c haracteristics

f

programming in the small?

SLIDE 22 3.13. CHAPTER SUMMAR Y 59 4. Ho w do es programming in the large dier from programming in the small? 5. Wh y is information hiding an imp

rtan

t asp ect

f

programming in the large? 6. Wh y should the design

f

a soft w are system b egin with the c haracterization

f

b eha v- ior? 7. What is a scenario? Ho w do es a scenario help the iden tication

f

b eha viors? 8. What do the three elds

f

a CR C card represen t? 9. What are some

f

the adv an tages

f

using a ph ysical index card to represen t a CR C card? 10. What is the what-who cycle? 11. Wh y should the user man ual b e written b efore actual co ding

f

an application is b egun? 12. What are the most common sources

f

c hange in the requiremen ts for an application

v

er time? Ho w can some

f

the diculties inheren t in c hange b e mitigated? 13. What information is b eing con v ey ed b y an in teraction diagram? 14. Describ e in y

ur
wn

w

rds

the follo wing asp ects

f

soft w are comp

nen

ts (a) Beha vior and state (b) Instances and Classes (c) Coupling and Cohesion (d) In terface and Implemen tation 15. What are P arnas's principles

f

information hiding? 16. What are some guidelines to follo w in the selection

f

names for comp

nen

ts, argumen ts, b eha viors, and so

n?

17. After design, what are the later stages

f

the soft w are life cycle? 18. What is soft w are main tenance?

SLIDE 23 60 CHAPTER 3. OBJECT-ORIENTED DESIGN Exercises 1. Finish the dev elopmen t

f

CR C cards for the I IKH. 2. Ha ving done Exercise 1, giv e a complete in teraction diagram for

ne

scenario use

f

the I IKH. 3. Describ e the resp

nsibilities
f

an

rganization

that includes at least six t yp es

f

mem b ers. Examples

f

suc h

rganizations

are a sc ho

l

(studen ts, teac hers, principal, janitor), a business (secretary , presiden t, w

rk

er), and a club (presiden t, vice-presiden t, mem b er). F

r

eac h mem b er t yp e, describ e the resp

nsibilities

and the collab

rators.

4. Create a scenario for the

rganization

y

u

describ ed in Exercise 1 using an in teraction diagram. 5. F

r

a common game suc h as solitaire

r

t w en t y-one, describ e a soft w are system that will in teract with the user as an

pp
sing

pla y er. Example comp

nen

ts include the dec k and the discard pile. 6. Describ e the soft w are system to con trol an A TM (Automated T eller Mac hine). Giv e in teraction diagrams for v arious scenarios that describ e the most common uses

f

the mac hine. 7. Consider a large program with whic h y

u

are familiar (not necessarily

b

ject-orien ted), and examine the names

f

v ariables and functions. Whic h names do y

u

think are particularly apt? wh y? Whic h names do y

u

think migh t ha v e b een badly selected?