chapter

LEARNING OBJECTIVES
After reading this chapter, you should be able to:

e Explainthe purposeand objectivesof object-oriented design be

¢ Develop design classdiagrams

¢ Developinteractiondiagramsbasedon the principles of object responsib;

1Oh
case controllers :

©Develop
detailed
sequence
diagrams
asthecoreprocess
insystems
design
ag
ea

¢ Developcommunicationdiagramsas part of systemsdesign ae

¢ Documentthe architecturaldesign using package diagrams

 ‘heUP?
Since
the
BANK:
UP
is ¢ 1 PART 1

hiccupsat the beginningof the project,

v. Bill Santora, who was the project
t of an integrated customeraccount
st finished a technical review of the new
w committee.
Thisfirst-cutdesignfo-
j been chosen as the most fundamen- ysem
working
intwo
orthree
more
weeks.”
mplemented in the first iteration of the Well,building
it incrementally
makes a lotof sense
andcertainly
seems
tobeworking.
| especially
liked
thedetailed
sequence
diagrams
you
showedfor each use case.It was terrific how you showed that the three-
isingobject-oriented
languages
for quite
layer
design
supported
each
use
case.
Even
though
| donotconsider
myself
adoptobject-orienteddevelopment tech- anadvanced object-oriented
technician,
| couldunderstand
howeachuse
volved
in some
earlypilotprojects
thathadused
the Casewasimplemented. | thinkyouwowedeverybody whenyou demon-
theUnifiedModelingLanguage (UML)to develop stratedhowyoucouldusethesamebasicdesignto supportboth our inter-
jevelopmentprojectwashis first large-scale
project nalbank
tellers
andaWeb
portal
forourcustomers.
Congratulations.”
biect-oriented
Bill'sresponse
reflectedMary’senthusiasm.
“How aboutthe design
5 presentation materials, his supervisor,Mary Class
diagrams?
Don’ttheygivea niceoverviewof the classesand the
nical review went very well, Bill. The committee methods?
Weusethemextensively
asa focusfor discussion
on the team.
‘emsthat needto be fixed.Eventhough| amnot Theyreallyhelptheprogrammers
writegood,solidcode.”
Liew
‘'d
at‘he
lo
weeks,”
you
believe
new
presented
object-oriented
that you
andwill
howhave
techniques,
these
these
core
six
itfunctions
pieces
waseasy
imple-
will
for “By theway,haveyouscheduled
a reviewwith the users?”Mary

“No.Weworkedintimatelywith the userson developingthe use

casesand creatingthe fully developed
usecasedescriptions.
We also
ee
“actions
Silllaughed,
Coded
“Itand
won't
running
beready
doesn't
for the
meanthatwe
usersthen. heusers
todevelop
prototype
screens
forallofthese
use
ectisstillgoingto takea yearto complete.”
''s nicethatwewillhave
something
to show
‘'ydo| feelmoreconfident
about
this
|
ngs
developing,
* rea

everybody
that:re ‘ojec
SINCE
eachenitionis
 men
If we comp arethedevelop
‘ness
modeling
.
andrequirements
oe
arelikethear, ‘
drawings.
Thosedrawingsdepict what theh
for rooms, floors,; laylayout
location
onthelot,andsoforth.However
ever,t
andsketches
areinadequate for a contractorto build the house.Thea
ch moredetail.So,the architecttakesthe initial drawings and buil
mu _ $0, | f
detailed plans called blueprints,which show exact Measurements for w
for plumbing and electricalwiring; and eventh
ceilings;specifications si "even
rints are similar to the desi
th
ane

developers
build. ie
Theanalogy
canbeextended
evenfurther.Whilethesketches
are b
homeowner is very involved in dictating his or her desires, but duri
thedetailed
blueprints,
thehomeowner
is lessinvolved.Heor shedoe
? ~ ets
ify the specificationsin the blueprints, but an expert, the archite
ot

contractor
later.Similarly,
in system
development,
softwaredesign’
detailed designspecifications,with occasional input by the users-
cation of the design. ‘ae
So what is object-oriented design?It is the process by which
oriented
design
models
isbuilt,which
theprogrammers
will i

operwould nevertry to developa largesystemwithout a set of

Sometimes
students
whoarebuilding
personal
Webpages
OF
SI
he
assignmentsthink that design models are unnecessary. Just rem
maynotbenecessary
for adoghouse,
but theyarecriticalfor:
plex, such as a home.

co

ne point
that requi aPoutadaptive4PProaches(including th
quirements
anddesignared ncluding the

294
 =

Sy
03)
aa34
a ey

FIGURE g-4
Obiect.
Onlented
event-driven
Program flow
 ation back to the Input window object to dis
sends that inform
dates(meg,
nothersequenceof messages
is sent to update the
Student 0
. ion in
the student information in |the data base.
mee
One common question about ob} sie ae
?Most
object-oriented
programs
areevent
driven.
Program
eee
by an actor wanting to Carryouta usecase,
thatis,a business
even;re
cutedbyaset of collabor atingand interactingobjects.Thus, a single
Pra
does not need to be inch arge.A particularobject program is in as
Ige¢
case,not the entire executable program.The program simply must Wai
message—an event—from an actor. | 2a
Let's use an analogy
toclarify
object-oriented
programs
further.
4;
sonal
computers
c
consists
ofmanyindividual
computers
connected
by 4 “yen

askforassistance.
Forexample,
someof theindividualcomputers
ont
large
diskdrives
andspecial
databases
thatyoucanaccess.
Theyarec le
Otherresources,
suchasprinters,arealsoon the network.Typically

ing objective. This networked system functions in much the sam

orientedsystemor programis designedto. I

and program logic encapsulatedwithin it. Analysts define thes

logic and data fields by defining a class.The class definition de
a template of what an executingobject looks like. The object i
creation
the template
of aninstantiation
object
provided
based
by the
on
existenceuntil the program begins to execute.We call that inst

Class
definition _ sent betweentheseobjects.
OBJECT-ORIENTED DESIGN MODELS

The objectiveof object-orienteddesign is to identify and speci

that must work together to carry out each use case. As seen in Fig

user-interface
objects,
problem
domain
objects,
anddatabase
jects
toperform
specific
services,
suchaslogonauthentication,
Dividing
theobjects
intodifferent
groupsiscalled
multilayer
de
pose,
oneofthemajor
responsibilities
ofdesign
istoidentify
a

296
 The other major design model, which you will also learn to develop in this chapter '

classesthat will be built for the new system. Design class diagrams are the end result of
the design process. They describe the set of object-oriented classesneeded for program
ming, navigation between the classes,attribute names and properties, and method names
andproperties.
A design
class
diagram
isasummary
ofthe finaldesign
thatwasdevel-
opedusing
thedetailed
sequence
diagrams.
It summarizes
thedesign
andisuseddirectly
in the development of the programming code, Figure 8-2 is an example of one class from
a design class diagram. Notice that it specifies the attributes and methods for a class.

«Design Class»
Student

- studentID: integer {key}

- name: string
- address: string
- dateAdmitted: date ;
- lastSemesterCredits: number
- lastSemesterGPA: number
- totalCreditHours: number
- totalGPA: number
- major: string

+ createStudent
(name,
address,
major):
Student
+ createStudent(studentID): Student
PCS VEL 2
+ changeName (name)
+ changeAddress (address)
+ changeMajor (major)
+ getName () : string ~
+ getAddress () : string
+ getMajor ( ) : string
+ getCreditHours ( ) :number
+ updateCreditHours
()

As an object-orientedsystemdesigner,you Wil
that a programmer can write the initial classdefir
tail to the code. For example,a designclassspecil
themethods.Youwill learnthedetailednotation
but asa preliminary example,observeFigure8-2
and(b).Figure
8-3shows
some
detailed
progran
illustratesthe codein Java,andpart(b) illustrate
able to see where the attributes and method sign
shown in Figure 8-3. Notice that the class name,
are derived from the design class notation. Of co
libertiesby abbreviating
firstnameandlastnam
the componentsof an addressinto onefield call
whethera programmerwill know that he or she
out into the detailed fields, then the designer shi

CASE
REALIZATION:
THEDESIGN
DISCIPLINE
WITHIN
 FIGURE
8-3 code
thatneeds
sign
models.tobe
Aswe added
tothe
discuss class
design definition
classes,
besurecan
to beback
deriveg
refer tofrhethe
Oh
language
(b)Visual
Basic Anothermodelthat weusein designis a detailedStatech Ndpio.

public class Student

{
//attributes
private int studentID;
private String firstName;
private String lastName;
private String street;
private String city;
private String state;
private String zipcode;
private Date dateAdmitted;
private float numberCredits;
private String lastActiveSemester;
private float lastActiveSemesterGPA;
private float gradePointAverage;
private String major;

//constructors
public Student (String inFirstName, String inLast
String inCity, String inState, String inZip,
{

firstName = inFirstName;
lastName = inLastName;
}

public
;
Student (int inStudentIpD
,
//read database
} 3
//get and set meth
public String getFu
{ 3
return firsth
} 4
public void setFi
{ q
firstName =
} 4
public float getGP
{ q
return grade
}
//and so on

//processing methog
public void update¢
{ 4
//access coy
//to-date cre

298 PART
 « Student
—a5>

studentID As Integer
+e firstName As String
e lastName As String
pr? street As String
pre city As String
Pre state As String
priv zipcode As String
dateAdmitted As Date
te numberCredits As gj
ate lastActiveSemester

firstName = inFirstName
lastName = inLastName

Public
End
‘getSub
and
Function
set accessor
GetFullName()
methods
—
 A statechart diagram captures information about the valid states
and y
object.Statechartsare an effectivetool, but in designingbusines
used for special situations. We will discuss how and when to us
e Statech,
in the next chapter.
A final model that we use to document subsystems is called a
A package diagram is useful to denote which classes work together as lag

Figure
8-4illustrates
whichrequirements
models
aredirectlya apter,
FIGURE 8-4
scriptions and activity diagrams, domain model class diagram
Design models with their S,System
respective input models grams,andstatechart
diagrams—are
thosethat weredevelopeddaca

Requirements Models

Use case diagrams

Use case descriptions

and activity diagrams

Domain model class diagrams

Class name Customer

Design
statechart
d
=
 Those on the right side—design classdiagrams, interaction diagrams, statechart dia-
grams,andpackage
diagrams—will
bedeveloped
duringdesign.Asyou might infer
from the number of arrows pointing to them in the figure, interaction diagrams are
the core diagrams in design, and you will learn how to develop interaction diagrams
in this chapter.
Asshownin Figure8-4,designinformationis derivedfromtwosources:
thedomain
model class diagram and the interaction diagrams. In fact, notice that the arrow between
design class diagrams and interaction diagrams points two ways. The two-headed arrow
indicates that some information in the design class diagram is needed to complete inter-
actiondiagramsandthat informationin the interactiondiagramsis usedto develop
design class diagrams.
These other
We will also describe other models and diagrams as part of OO design.
models,
suchaspackage
diagrams
anddeployment
diagrams,
arehelpfulassupporting
documentation. Remember, however, that the primary OO design models are design
classdiagramsandinteractiondiagrams,
with anoccasional
statechart
diagram
where
necessary.

OBJECT-ORIENTED DESIGN PROCESS

Object-oriented design is use casedriven, meaning that we develop a design with a
sequence diagram use caseby use case—one at a time. The process of designing re-
quires several steps, or iterations. First, a preliminary version, or first-cut model, of the
design
class
diagrams
iscreated.
Some
basic
information,
suchasattribute
names,
must be obtained from the first-cut model to develop the interaction diagrams.
ction diagrams—resultingin one se-

gether.Developmentof the interaction

design.
Asshownin Figure
8-4,inputn
diagrams, use case descriptions, system
tn
ization of use cases | The end result of the development of
*ectication
yy
of all detailed §
|
cuses.In this instance,the term realization
ystem
Processing
for each that the systemmust do to carryout the
use Case
wareblueprints.Notice that just asobje
byusecases,
soalsoare
object-oriented
use case-by-use case basis.
The third step in OO design is to Te
method
names
based
oninformation
¢
diagrams.
Thenavigation
visibilityand
eration of the design class diagram.
The final designstepis to partition
using package diagrams. There are s¢ vel
way is by subsystem.Another is by laye
architectures and multiple tiers. In this
class diagrams into packagesto repres
focus on a basic multilayer design con
thedomainlayer(problem
domaincl
and the data layer (databaseaccessclas
thedomain
layer.
Synonymous
terms!
business
logiclayer.PackagediagramsP
final system.
302 LASSES AND DESIGN CLASS DIAGRAMS
DESIGN C
As shown in Figure8-4, the design classdiagrams and the detailed
gramsuseeachother as inputs for design and are developed at the
intera

neering
design
principles.
Thepreliminary
Gesien
class
diagram
jgthes
elopinteraction
diagrams.
Asdesigndecisions
aremadedurin
dev 8deve}
diagrams,the resultsare used
interaction . to refine;the design clas8diagra
Aswementioned previously, thedesign Class diagram isanextension
model class
diagramdeveloped during OOrequirements: Thedomain m.
gram shows asetofproblem domain Classes andtheir association
relatios
specification
ofrequirements, since itisa discOneny process, analysts
gene
worry too much about the details of the classattributes or the methods,
object-oriented
programming,
theattributes
ofa
class
must
bedeclared
private,
andeach attribute
mustalsobedefined
byNgtype,suchas
During
design,
it isimportant
toelaborate
these
details,
aswellasto de
that are passedto the methods and return values from methods. So 7
alsodefine
theinternal
logicof eachmethodatthispoint.So,thedesi
isamore
detailed
version
ofthedomain
model
class
diagram.
Weco
gratinginformationfrom interactiondiagramsand other models. ~

wereoriginally
defined
in thedomainmodel.Sincetheobjective
of r .

to understand the businessneed, the focus was only on specifying

tst
4
7

ohh c

such as user-interface classes.At times, we may also develo

subsystem.
Thepointisthatclassdiagramming
is a too
ways.
Wenowturntodesign
class
diagram
notation
andth
thefirstiterationof developing
thedesignclassdiagram.
»

DESIGN CLASS SYMBOLS 4

Unified
Modeling
Language
(UML)
does
notspecifically
class
notation
anddomain
modelnotation.
However,
pr
cause
oftheirobjectives.
Domain
modeling
shows
thin x
he

@
element
way
indicated
Of categorizing
byby
itsguillemets
characteristics,
stereotype
a model
(« »)
 ee

SSEQRjEH )
eo

oe PUaS
pup
By
MLA2U?
U2IMIAQ
‘12[[ONUOD
10 391
01
pasn
SI
a Be
Sse}>SSQ2>p
ep Xe
ye1]sya{qossep>
Aue Wa10Daup0}way?Puespure
spalqossep>
[JSaSessaul
ay}YI O}SIAypiqisuodsai
Sit‘Sp1oM
TOMI UT‘sesse|> Pue Jafe|MaiAg
P Arepunogaypuaamiaqsayetpautet SSUD
ESESSM[O09 VW
PYPOQYI
IMseRty
-goepiaqut
Jasn
ay}WIIpareDosse
sasse[
Joyro
au}[TP
pue Auapue
Sass
5fees
‘3p
uy3qPp[nom
sassep
asaup
‘Laisks
dovjseP
evuyAlepunog
uoNeuo} UsIM
Jaq
SMeIpay
aoe
soaat]01pauBisap
AqTe2yDads
st3eUp
sseP&SE
SSI?LAPPUTION
V SSE
. ie -gseqeiep 10 ajy & OFINOI ALM
\ up‘{JsnoLAqQ
‘UMOPp
INYs
StWlaIsAs
aUJIVE
ystsiod
JsNUI
k1ep
24}
i1bwiesZoidJU}JayesIstxeJey}aUOSIssY]Iquaqsisiad
YW “SASSeP
UI}
@aie Aayypur ‘SuryppAue
op AaypB1OJaqINDIOO}SIULAY SSOUISTIG
TOF
‘za1ssedAyjeuIOUare s}alqo asy,L [PPOU!ULBUIOP
24} WOT SOTO?
se] ulewopWafqord
e10jraynuap!
UsIsap
aypStssvj9
Quusuy BJB}Sisixg
EU)
ssejy
hiss R
Ssej>
SSP|9
W9|Goud
SSE}>
UleWop
WUI\SiIsjad
Ajiqua
e404Jay)
f ;
:a
B . 5 =,
XY
NUSP!
Ubis

sepeeyaqiepsO
«SSed0Vveyep»

MOPUIMJEPJO
«Asepunoqg»
sjapow ubisep
Ul PUNO}sadAjoasals
plepue

s-8 aundld

JejpueHeseoesy
«|OJJUOD»

Jsewo sng -
«A\qua»
 Language (SQL) statements, into the entity class methods
access
thedatabase
is oftenincludedin thedesign.
DESIGN CLASS NOTATION

«StereotypeName»
Class Name::Parent Class

FIGURE 8-6
Internal symbols used to define Attribute list aoe
a design class visibility
name:type-expression
= initial-value
{prop

Attribute visibility. Visibi/j ty denotes wh

cessthe attribute.A + (plus) signindicates an’a
anda- (minus)
signmeans
thatit isnotvisi D1
e Attribute name 3

Type-expression. A type-expression
can be
ber, currency, or date.
° Initial-value

method signature
notation that shows all of the
Thethirdcompartment
contains
themethod
sig
signature shows all of the information needed to im
informationneededto invoke,
or call, the method theformatof themessage
thatmustbesent,
which«

© Method name

orientedprogramming,analystsuseth
method.SomeOO languagesallow multiple methods

304
 ID number or by the customer name. We c

erlD) and getCustomer (customerName).

, We Say that me
method to invoke, the run-ti
cluded—in this case, whe
was entered.
=a
=
== class
tion system.
diagramFigure
Student
8-7class
showsforan
comparison
enhanced domain model Student classand the design

ET

studentiD -studentID:integer{key}
name | -name:string
| address — _| -address: string
| dateAdmitted -dateAdmitted:
date
| lastSemesterCredits -lastSemesterCredits:
number
lastSemesterG
PA -lastSemesterGPA:
number
totalCreditHours -totalCreditHours:
number
totalGPA umber
-totalGPA: number daveihinestieabinnnsean
major -major: string 6 ririt: s

+createStudent
+createStude
(name,
address,
udentiD): |
major):
Student
eignits

+changeAd
+changeMé
+getName
(;
+getAddress
+getMajor
()
: st
+getCreditHou
+updateCre
+findAboveho

“ent B g URE 8 7
“ Class : Oo iT
gram
Oesign spare ments activities. The design class diagram ir
: .
If
types, initial values, and properties.
It can4a
and the Student class is shown as an «ently

Mostof themethod
signatures
willbeds .

sameasprogramming
methodnotation.
—
notationweuseiscreateStudent
(name,
a
structoristhemethodthatmakes
aOe
languages, the constructor is gt
tion, we usea createstatementtofollo
action diagrams. The figure also
 theconstructor
itselfmustfill in theinformationaboutthestudengThe
quiresaccessto a databaseto get valuesfor the fields. i sips ete

underlined name, is a special kind of method. Remember,in the objec

proach,
a class
isatemplate
tocreate
individual
objects
or instances,
odsapplytoeach
instance
oftheclass.
However,
frequently
analysts.
i
class-level method
a method that is associated which is denotedby an underline. In VB .NETit is a sharedmethod, we 3
with a class instead of with ob- static method. This type of method is executed by the class instead 6 1
jects of the class of the class.Becausethesemethods are used at the classlevel, they d
the existenceof a particular object and, if necessary,can accessdata x

classandreturnsthosehavingtotalhoursgreaterthanthe input para;

SOME FUNDAMENTAL DESIGN PRINCIPLES

Nowthatyouunderstand
howanobject-oriented
program
works
and
notationfor a designclass,let’sreviewseveralbasicprinciplesthatwi
decisions.Wewill mention theseprinciples of good object-orientedd
the chapter as we discuss the steps of object-oriented design. The followin;
ciples
areimportant
toallpartsofobject-oriented
design. 4
ENCAPSULATION AND INFORMATION HIDING

encapsulation Encapsulation is the design concept that each object is a self-contain

a design principle of objects in both data and program logic. Each object internally carries its own data
which both data and program
logic are included within a
setof methods
thataccess
thedata.Eachobjectalsoprovides
a setof set
single self-contained unit
invoked by calling the object’s methods. One of the benefits of this appt
isthatasoftware
developer
candesignthesystem
in abuilding-block
allengineering
disciplines
have
standard
unitsthatserve
as
building
ble
canbecombined
into a finaldesign.Encapsulated
objectsarethesoftw

object reuse
a design principle in which a set
of standard objects can be used
over and over again within
providebasic
servicesthatareusedmanytimesin thesamesystem-ane
a system evenin multiplesystems.
Onefrequent
applicationof reuseisin thedes

soforth.Problem
domainclasses
canalsobereused. Eee:
‘:
information hiding Relatedto encapsulationis the concept of information hiding. Infor!
a design principle in which data
associatedwith an object are
dictates
thatthedataassociated
withanobject
arenotvisibletoth
not visible to the outside world, otherwords,theobject'sattributesareprivate.A setof methods1sPf
but methods are provided to
thedataandtomodify
orchange
them.
Although
thisprinciple
is Be:
accessor change the data
gramming
concept
andismostbeneficial
for programming
andtesUBs
systemis better if accessto data attributes is done via a standard in
names, as explained in the next section. ,

NAVIGATION VISIBILITY +a
Asstatedearlier,an object- ect

uring designdocumentwhat interac

which objects.However,
for oneobjectto interactwith another
306 PART 3 THE DESIGN DISCIPLINE = f
 the first object must be visible to the second object.
this context refers to the ability of one obj

Inprogramming
jargon,
invoking
ametho
tion to invoke the correct method on the correctobject.Sometim
navigation
visibility
Asa designer, you asmust
just navigation
alwaysbeor justof
aware visibility.
navigationvisibility.!nteractionsbe-
jects can only be accomplished with navigation visibility. One of the respons
pilitiesob
tween of a designis to specifywhichclasses
havenavigationvisibility to othe
er object
Navigationvisibility canbe eitheronewayor two way.Forexample,a Custom
may be able to view an Order object. That means that the Customer object kn
which ordersa customerhasplaced.In programmingterms,the Customerclasshas a
variable, or array of variables, that points to the Order object OFobjects for that cus-
tomer. If navigation is two way, then each Order object will also have 4 variable that
5to theCustomer
object.
If thenavigation
isnottwoway,thenOrderobjects
will
not havea variableto point to the Customerobject.In a designclassdiagram, naviga-
tion visibility is identified by an arrow between the classes,where the arrow points to

the visible class. tween the Customer

Figure 8-8 shows one-waynavigation
visibility be rder in the Customer class.This
ere is a variable called myO the referencevariable
Order class. Notice that th
ferto anorderinstance.
Frequently, arrow indicatesthat
variable holds a value to re ass.The navigation
myOrder is not explicitly shown in the design cl emphasize the
visibility is required. We have included the variable in this example to

concept.

nightPhone
myOrder

isageneral
termthatisderived
fron
example,
where Customerhad navigationvisibilit
Coupling
Customer and Order are coupled, oFlinke A
throughoutall the classes
in the entiresystem.C
closelythe classes
in a designclassdiagramare’i
coupling is the number of navigation arrows © 1
pling for the systemis usuallybetterthanhigh C
tion visibility arrowsindicatethat a systemis ea!
Wesaythatcoupling
isaqualitative
measure
coupling in a system.A designermust develop a
thereigto0-muchieouplingOfte?knowwhat is

ASEREALIZATION:THE DESIGNDISCIPLINEW
 casedesign has a reasonablelevel of coupling, the enti
Refer back to Figure 8-1 and observe the flow of m
Obviously, objects that send messagesto each other

Database
object,
sothose
objects
arenotcoupled.
If wedesigne
a hs
Input window object accessedthe Database object, th

cohesion Cohesion refers to the consistency of the functions within a sin;

a qualitative measure of the qualitative measure of the focus or unity of purpose within a si
consistencyof functions within
308 a single class
in Figure8-1, you would expectthe Student classto have meth,
enter student information suchasstudent identification n mi

assignmentsor assign pre

cohesivenessof the classwould be reduced.
Classes with low cohesion have several negative effects.
tain. Since they do many different functions, they tend to
within the system,suffering from ripple effects.Second, it is har
Since they have many different—and often unrelated—funetie
make senseto reuse them in other contexts. For example, a]

and userlogonshasverylimited
* - reusability.
- . A final drawbae
BS
not cohesive are usually difficult to understand
. Frequently,
twinedandtheirlogicis complex. j

ple of very low cohesion woul

for services in different functional areas, such as
the Internet and a database. These two types of activities are
customer accounts, such as

The common solutio Sesare acceptable in system design.

sign to separate disparate tasks into distinct

classes. Think of separati onof res ponsibilities
siverclasses! onsibiliti asanotherwayto develophighly cohe-

BEST
P " ; \
p coupling low and cohesion high. Always keep itt
concepts in mind when designing.

DEVELOPING THE FIRST-CUT DESIGN CLASS DIAGRAM

Tostartthedesign
process,
wedevelop
afirst-cutdesign
class
diagram
based
onlyon
the domain model. Figure 8-9 repeats the domain model class diagram for RMO devel-
oped in Chapter5. Asyou learnedearlier,thefocusduringrequirements
wasto iden-
tify the classes, their attributes, and the relationships between the classes.
Thefirst-cutdesignclassdiagramis developed
by extendingthe domainmodel
class diagram. It requires two steps: (1) elaborating the attributes with type and initial
valueinformation
and(2)adding
navigation
visibilityarrows.
Figure
8-10
i i
classdiagramfor RMOshowingthe resultsof thesetwo steps.
Theelaboration
of theattributes
isfairly
straightforward.
Thetypeinformation
is _—~
determined
bythedesignerbasedonhisorherepertise.F in most
instances,
;
attributes
arekeptinvisibleor private,
asindig
in the diagram. _
Navigation visibility is a little more diffice
signing just the first-cut class diagram, SOWE
rows as the design progresses. The basic ques!
visibility is, Which classesneedto havereferences
to,

© One-to-many
relationships
that
it
are usually navigatedfrom the suf
Orderto Orderltem.
Sometimes
t
ains, for example, from ¢
gation ch in whi
e Mandatoryrelationships,
objects of another class,are usu
class
tothedependent
class,
foré
e When an objectneedsinformaic
rowmayberequired,
pointing§
e hierarchy.
Navigation mayalsobeJE
arrows
Asindicated
intheguidelines,
Figure
¢
visibility to Order. Order has nave
Returnitem.Catalog,Productitem,
anc ©
 catalog!D {key}
effectiveDate
description
endDate
season
year specialPrice
price

inventory!lD {key}
size

productiD
(key) 0.." color
vendor options
gender quantityOnHand
description 1 averageCost
reorderQuantity

Returnitem 0..
quantity
price
quantity backorderStatus
price
reason

condition
disposal

Customer
orderlD
orderDate
accountNo
{key} 0;.* priorityCode
name shipping&Handling
billingAddress tax
shippingAddress grandTotal
dayPhone
nightPhone

emailAddress
replyMethod phoneClerk
callStartTime
lengthOfCall

going from top to bottom. CatalogProduct, as an assoe¢

Vhereare still a couple of unresolved issuesat th

between Orderltem and Inventoryltem, and Orde
clearwhatis thebestwayto implementnavigation
310 PART 3 THE DESIGN DISCI
 -grandTotal:
float -shipperlD:
-name:
-address:
-contactName:
-telephone:
string
string
integer
string
string

-trackingNo:
-dateSent:
-timeSent:
time
date
string

™|
_| -orderID:
-orderDate:
Orderltem
integer
date

RI
NT
-productiD: integer
-inventorylD: integer
-description: string
-price: float
-inventory|D:
string -quantity:integer
-price:float -backorderStatus:string
-reason:string
condition:string
-disposal: string

Customer cab
a
baie
Eas
9nd
“oriorityCode: string {
"accountNo:string Bro jaHandiing
float
‘name:
string -tax: float H
‘billingAddress:
string
‘ShippingAddress:
string
“dayPhone:
string
“ightPhone:string

| -emailAd
-replyMethod:
dress:
string
string

SY
:
Processing
indicates
that
Pnnaple
design
objects
responsible
which
are
system
Carrying
out
TOF

how explain
to
used
they
be
also
can how
to
is
design.
do
interacti
diagrams
and
design
class
as
such 2ples
app
tn
can
be

this
.section
of
ective
case—ijg
use
the etails,
Fj
sal.
ecisions
im
nd
arrows
= uence
munica-

diagram
for
partial
design
class
the
up
Look
availability
item
case
use
FIGURE
8-11
 ing responsibility ea i

CRC (class-responsibility-
collaboration) cards
lar methodsof assigningresponsibilitieswas developed using 3° x 5" in
These
cards,called CRC
cards—forclass-responsibility-coll
index cards that are used to
responsibilities of each class for each use case collabor,
document the Classes in a
is still used in many places to assist in the design process,
ation.TheCRCcard
collaborate,
ities
system,
of each
the
and
class
ways
thefor
responsibil-
the
each
classes
use

2 Gass
usesystem
case
case
Cesgners
controllers
collaboration
Ceste USE CASE CONTROLLER

Normally, each use casecan have many different input messa

temal actors.A systemsequencediagram (SSD) developed
ASPart of the Tequir
discipline shows these input messages,but it only indic
gOto the system.However,during design we must deci
these messages.To simplify the collection
case,systemsdesigners frequently make up a new class that can se 7
point for incoming messages. We call these cl Tveas a collectio
the use caseLook up item availability, there might be a controller class Named
314
to sve a5 a collection point for
NCOMINGmessages
AvailabilityHandler.A usecasecontroller is a completely artificial class,
person doing the system design. Sometimes these cl
artifact called a asses
thatarejustmade
up.
which meanssomething created for a specific purpose just because
its
2 Gass vented by a system
needed_ We add this term because you will find it
Cesigner
to handle
3 needed
Essentially,an artifact is
usedfrequentlyin industry.
—
system function

models
wearecreating
in thischapter
canbeconsidered
artifacts. oe

e ain objects. The coupling between the Inpui

FIGURE 8-12
SSD for the Look up item

availabilityuse case
 re
3
-. .. :

exp
step
in
Figure
first
The
8-12.
in
SSD
the
defined indi
is :System
rae
Replace
the
8-12.
ure
example
there
this
case—in
“use
the diagram.
Message
from
input
an
select
to
then, design
class
the
in
illustrates
Figure
8-13 SSD
The design
L
the
for
proceed
with
case.
carry
use
the
out
to Let's
involved
may
be
need
objects andsystem
was
SSD,
the
system.
words,
an
for
other
In
design.
detailed
Cases,
is intern
by
replaced
the
object
;System
of
all
is
that and
somessages
that
objects
detailed qa.
so
the
life
on
ob
SS
an
In
sin
wi
ar
tw

design
is
objects.
the
of
Part
internal
correct
for up
ithe Objects
Look
in
included
first-cut
«sequence
accepts
It
ssages
case.
use
a the
in
included
be
will

dto mee
and
objects
al
identify
the The
SSD.
San
wi
list
eter
U
i701

cates
tha uto
at

8-13
FIGURE
See

;
size)
;

st
 di
AvailabiltyHandler Catalog :Productitem :CatalogProduct

Clerk '
; '

, inquireOnitem 1
; (catalog!D,prodlD, size)
'
1

1
1
inquireOnltem
1
(prodiD, size)
'
1
1
1 desc := :
1 getDescription ()
'
\
1 price:=getPrice
()! pate ae
!
. I
1
quantity := getQty (size) quantity :=
\
1 ry :
1
'
1
'
ift
1 ! '
1 le — ——— !
1
i t
1
1
(desc,
price,
quantity)
' =
j | | | ing the usecase,or
; | |

t 1 1 i ;
‘ ; ; !
A

/ X

First-cut
1 sequence diagram for q 4
the Look up item availability :Productltemto :Inventoryltem or come directly
; from :Catalog. As ,illustrated in
in Figu!
Figure
use Case

design
asshown
isthebettersolution.
a . na

activation lifelines
the activation lifelines.Rememberfrom Chapter 6 that the lifeline of an object!
vertical rectangles in a sequence
diagram that indicate when an sented
byavertical
- dashed
line.
P Anobjectcanbein eitheranactive
1 or iinactive ermi-
ive state
An object is activewhile it iSexecuting a i i re

Ch
Sr
USE CASE REAL! y
 320

electroni
system.
the
Once
and
users
between
interface
dialogs
the
in
used \<classes.
layer
adding
data
and
view
before
solid
more
€com
logic
tog
P&
mixe

th
on
edits
.)

Sepa
Oo
be
: ETT
inte
Tchas
0

l
‘ 1
{

fae
availability
use
item
UP
user-
and
layer
view
With inquire
|
Clerk
|

8-15
FIGURE
object
interface size)
prodiD,
' (catalog!D,
REA
CASE
USE —-e ee ee ee ee
 SE —

human beings,may not understandexactly what they need unle

experience ‘SSthey
theend product.Asa result,the most effective®PProACh én
t6 buy
tems—especially
thepartsinvolvingtheuserinterface—is
to actiVely iny
ZM
through the use of prototypes, mock-ups, and storybo dIve
ards,
Acombinat;
onaie
ingandmodel
building
isthemost
effective
approach,
Sometimes
dl Of
temptedto build a systembasedonly on prototyping and skip the E
Thismay
workforverysmall
systems,
butasexpressed
atthe
beginn:B
models are necessaryto produce a truly robust
andcorrect System.You,
to use all the skills and techniques you have to ensure that the Systemsiya
high-quality, strong systems.
«boundary»
DESIGNING THE DATA ACCESS LAYER ‘ProductQuery

The principle of separation of responsibilities also applies to th

data ace
smaller systems,two-layer designs exist. in which the SQL state Clerk
1
baseare embedded within the business logic layer. In OO two-
pliesthatSQLstatements
areincludedin methods
of theprob
layer
des: '
'

lem doma inquire ‘

However, on larger, more complex systems, it makessenseto createclasses (catalog!D,
prodiD,size
responsibility is to execute database SQL statements, get the results of the q 1
1
provide that information to the domain layer. As hardware and networks ~MUery,
bec t
'
sophisticated,multilayer designbecamemore important to support multi 1

inwhich
thedatabase
server
wasononemachine,
thebusiness
logicwas« ;
1
1

server,
andtheuserinterface
wason several
desktopclientmachines.Thisne '
'
1
'
In Chapter
5,youlearned
howto builda domainmodelto describe 1

or entities, about which information is to be maintained. The dom 1

!

two purposes. First, of course, it is used to develop the database for the new J
1
Chapter 10 explains how
tousethedomainmodelto design
thedatabase.
7 1
1
purpose,aswe haveseen,is to identify the internal classesthat make up 1

tem.It shouldbeapparent
thataveryclosecorrelation
will existbetween 1
t
tables and the design classes.Both come from the same domain model. oie '
1
In your database course, you learn how to access the tables in the relat t
‘

base
byusing
SQL
statements.
Executing
SQLstatements
ona database
ei 1

gram to accessa record or a set of records from the database.One of the

object-oriented
programs
thatusedatabases
isaslightmismatch
betweenprogt
ming languagesand databaseSQLstatements.For example,in a datab:

FIGURE 8-16
Partial
three-layer
design
for
Look
upitem
availability
ty andarebeingprocessed
classesdo not haveforeign keys.
bythesystem.
In other
|
Thesedifferencesbetweenprogramming languagesand databaselat
Partially driven the trend to a
tenance
ofa system
areeasier
if separate classes are defined to access the d:
get the data in a form that i
the businesslogic with the
let each focus on its prima
ty responsibility. This idea is an application ©

322

USECASE
R
 oS
:ProductQuery
«boundary»
SES

its data.It sendsa messageto the :CatalogDAobject with a referencetoi

aC, to read and retrieve the data from the database. The data access ¢}

base withaSQL statement and places theappropriate attribute informat

inal object by using the passedreferenceparameter. In Figure 8-16, all,

ously defined. One ofthebenefits ofdeveloping sequence diagramsin tw

the first cut focusing only on the domain objects, is that the problem of

collaborating
domainobjects
canbesolved
without
worrying
about
the
of dataaccess.
The domain objectsthat havedata stored in a database are often Teferred
|
sistent
classes.
Asweexplained
earlier,
apersistent
class
isanentitythatr us
terthecomputer
system
isshutdown.
Of course,
thememory objectitse
exist after the computer is turned off, but the data must persist between
thetermisusedwhenreferringto objectsor classes
that requirepermanent
Figure 8-17 is the complete sequencediagram for the Look up item a
case.At first, it looks ratherintimidating, but as you study it carefully, youy
we havediscussedthe conceptualbasisfor every messagein the figure.So,
it is fairly complex—it has lots of messages—you should be able to see
ternaswellasunderstand
allof thedetails. 4

This example began simply—as a single query to the database. We ide

domain objects that neededto be involved and designed a solution. Othe!
plexdatabase
solutions
couldhavebeendesigned
basedon database
joins
a

We will again take a multistep approach by first designing the use case
domain objectsand then adding multilayer objects.

DEVELOPING A FIRST-CUT SEQUENCE DIAGRAM FOR

AN RMO TELEPHONE ORDER

Figure 6-17 from Chapter 6 presented an SSD fora telephone order from R
8-18 is another version of the telephone order, This SSD is for the telep
oftheCreate
neworder
usecase.
Asbefore,
wewilldoadesign
foreach
inp
intheSSD.
Thedesign
components
forallthemessages
arecombined
t
comprehensive sequencediagram for the entire use case. As in Figure 8-4,
|
fromtheSSD
andthefirst-cut
design
class
diagram
willagain
beused
todeve FIGURE 8-17
sequencediagram, with one exception. We define a controller object fort Completed
three-layer
design
with the name of ;OrderHandler. We anticipate that this controller may$ °FLook
upitemavailability
creatingnew orders and for maintaining existing orders. Whether this 1s
willbedecided
after
other
usecases
have
been
designed
andthedesign
f
viewedfor good designprinciples.
The first input messa
8¢ is startOrder(accountNo), which comesfro!
Clerk to the :System.W
hat does the system need to do to start an order?
needs to create a new Order object and connect that Order object to 4 Cu
Thus,
aMessage
tocreate
aneworder
isneeded.
Thedestination
ofthe!
the Order object j A

324
 326
telephone
order
the
for
SSD
new
Create
the
of
scenario
case
use 8-18
FIGURE
order Clerk
Order

1
’

.S
‘ge
s
steps.
later
in
this
for
need
the
see
will
We s:—
iWhich
is,
controls
that
the
other
¢
is
source
Message,
then
create
or
date tory ne
the
that
find
model,
we
domain
should
decision
jtant
object
message,
source
the
query
object the
th
to
items
message
line
add
peating
system.)
So
by
the
checked
be :totalDue
<
to
need
will
yOu
identify
sthe
we
As (message
addItem
is
input
next
The

message
a
of
initiator
or
source
object
the
is

SSS
:

gS:
jet
Bee

8
“WAPTER
CASE
RE/
USE

tif
id
been
have
 i
t
.
i' 1
'71
! '
t i
! '
' 1 11
'
1 1
'
'3

;
;1
quantity)
Size,
add
will
clerk accoun
at sign,
includ
of>{

°¢
pal
°ee

ed.
8-20
‘igur
>
bee
also
sho
the
to
added
is
item
each
After
'>

!
' '
' 1
1 '
\ ral
=r '
1' : 1 i

'
a
i —--
Ra
aie
AEE { n
aa

SE
1

' 1

Z .

Orde
1 Praia.
ag
co
ang
 «uboundary”
MainWindow
Urea
'
1 \ '

\ '
'
1‘ ' 1
' '

startOrder(accountNo) . ; i 1
' teOrder(accountNo) 1

' . 1 1 i '
;

' ke ——-— -— > T 1 ' 4

i anOrd l 1 g

Loopforallitems
) '! 1 ’ 1 ' 1
:OrderWindow

odID, size. qu t

'

'
i ' 1 Zz
' 1 ' ' 1 es
' 1 y ' 1
' : '

f] ) 1(catalog!D,
prodiD. \
' 1 1size, quantity) 1 ; i
' ‘ ‘ 1 1
1 ' ' 1 1
' ' ' ' '

' 1 ' price := getPrice () 1

' ' t
' ' 1 1
‘ ' ' '

‘ ‘ 1 ;
' ' 1 7

' ‘ 1 i

1
'
f)' ‘
i
1
i
‘ ' ' ' 4 ;
1 1 ' ! : 1 x

1
1
je --—-—-—
1
K--—-—- - 4
orderitem details
'1 '
‘
1
i
' ' 1 = ' u 1
‘ ‘ ' 1 ‘ ' 1
' i ' ' ‘ : '
1 7 4 1 1 J

‘ ‘ { 1 f
4 Se eae ' ‘
f ‘ totalAmount

makePa:
yment (ccinformation) | createPayment <p Z ram or the startOrder
; ‘ 1 , (paymentAmt,payMethod,ccInformation) message
' 1
'
U
'
f >
‘ i ' '
‘ 1 i

FIGURE 8-24
<

equence diagrarn for the

telephone order scenario of the
Create new order use case

330
PART 3 THE DESIGN DISCIPLINE
 Q ler |
! «boundary»
ji

OrderWindow ; ——

Order
Sn
Clerk r
| Clerk
Y | 1
' : | 1

1newltem
() >dl anOrd:Order
create () SOOUNCEDS
co NewitemWin
Dre I
' '
1 T
1 '
‘ additem i
' (catalog!D,
prodlD,
D size,
quantity); '
'
' '
t Invoke Look up item '
1
availability use case '
'
'
: '
'
' additem
'
' (catalogID,prodiD, size, quantity)
. ' CatalogProduct
t
I
' additen\
1 || quantity)
'
' 1

' createOrditem ;
1 (catalog!D, prodlD, size] 2. quantity)}
1 1 — anO!:Orderltem
1 i
1 price := getPrice ()
'

\ description:= getDes
\
; -

status := updateQty

:OrderltemDA

saveOrderltem (anOl
1
e-—-—-] anol 1 |
; anol : b,
!
1 anol i a '
t A ! =
1 1 1 L
FIGURE 8-24

FIGURE 8-23 or the final messages

Telephoneorder sequence
appropri as

€sof eachusecasewithoutprogrammingcomplications.
It sh
be noted th : s
atnodesign
ures in the use case. [
elements
havebeenaddedyetto covererrorhandli
T what does the System do f It edits
y' if the inp

PART 3
 May 15, 2006

To: JohnMacMurty :

RE: Customer
Support
System
status ?
‘An actor who sends
ve are
i i need
to proceed
along
several
fronts
atthesame
time,Asyou the initial message

diagram
forthat
usecase.
Before
wefinalize
the
design
ofany
use
case,
webuild
afew
prototypes
of.
1am
pleased
withtheprogress
wearemaking.
[ amespecially
confident
thatthedesign
issolidand
. ’
thattheworkflowsandscreens,are
acceptableto the users. ,

Completedduring the last period (two weeks)

Wehave
completed
thedesign
of threeusecases,
Update
customer
account,
Lookupitemavailability, _ ;
andCreateneworder.Thefirst usecase,Updatecustomeraccount,includesboth adding new
customerinformationandupdatingexistingcustomers.The Createnew order use case only includes
the telephoneorderscenario.(You rememberwe discussedearlier that we would focus on the
telephoneordersfirst.)

Plans
forthenextperiod(twoweeks) ;
é ; FIGURE 8-25
Duringthenexttwo weeks,we will finish thedesignof all the usecasesin this iteration. We will'also Thesymbolsof a
Starttomorrowon programmingthe usecasesthat we have finished. So, by the end of the next two
weeks,
weshould
havesome
complete
usecases
that
wecan
show
theusers.
Theywillonlyhave
been communication
diagram Thelsyntavonthenme
scenario,
each
message
is nun
sass
The
Problems, issues,open items ass

Thereareno majorproblemsat thispoint.Almostall of the issueson the OutstandingItems Log

havebeenresolved.You might testthe watersfor us at the oversightcommittee meeting to make sure x

the usersarehappy,Fromour perspective,they seemto be very excited about the progressthatwe ~ * links links. Ina commun
aremaking.I wouldjust like to makesurethatthefeelingis the sameat the seniorexecutivelevel. Notations
in
diagram acommunication
that Carrymessages one
sends
BH between
objects
orbetween
actorsand objects
cc. StevenDeerfield,Ming Lee,JackGarcia

Communicationdia : and

334
specify
objects.
symbols
to
The
used
iconic
are
that
two
showed
shows messages
material
your
you
construct
set
the
of
an
in
format,
outline
as
would
do
with

prodiD,
size)
price,
quan
desc,
2:
t=

Order
Clerk
338
availability
up
Look
stem
use
8-28
FIGURE
()
Inquire
1:

PAR
S€looks
the
on syntax
process
Thus,
method.
a
for
the
very
like
much
of
ad
baseding
class.
one
work
The
Let's anthan every
aiprocess
is
message
some update
asia
objects.
Since
and
retrieve
initiate
more
and
every
message
words,
object.
other
In
appeats
that
on
method
example
through
Order methods
attribute
set
Get
values.
activity.
nothing
This
|f(Jinitinquir
3:
/
/

/
Wa
Jf

—_—

quence
:
Figure in)

signatures,
for
the
Order
class
Design
class,
with
method
FIGURE
8-29
CASE
RE:
USE
us

design
the
ae
values,
:return

use
order
new
 feat
ae
(catalog!D,
prodID,
-amount:
quantity)
size,
( -description:
string
;
340
diagram
design
Updated
class
layer
domain
the
for ~dayPhone:
(catal
+addltem
string
: Reeser
-grandTotal:
float
; ~year:
8-30
FIGURE
K
:;
string
-reason:
string
a string
-gender:
integer
+gelOty
-quantity:
-inventory|D: ees
-description:
string
-color
-productiD:
integer tiveDate:
P e(size): rer.
-inventory|D:
integer
string
-descnption: ae
mar
string
-size;
date
-options:
string string
telephone
-
Productitem090,
ry
(0):Order prodiD,
]size)
_

integer
-orderiD:
date
-orderDate: +getPrice
():
float
a
1tity):
strin -price:
float
,prodlD,
size,
au
:
():
reSent:
+
H
integer -catalo
string
-produ
string
Order

-date:
date

string
-name:
;
String
-address:
time integer
-timeSent:~shippe

diagram
RMO
for
Package
 aelement
affect
other
element
in relat
amo
elem
in
diagram
that
indicate
which
system,
designer
so
that
diagra
and
intera
packa
diagra
Class
changes
effects
of

ay
c

system the
Packages et
view through
layer
do
ally
not
cary
domain
the
to
domain
the
layer
and
Figure
view
the
both
tween
that
5-31
layer
and
changes
domain
require
the
at
access
usually
data
layer, ages
packag
or
between
Classes
withinwh
packages.
indicates 4
arr
sy
Th
oth
pa
da
us
ka
di
on
ais
Packages.
of
‘levels
different
diagrams
Package
show
to
nested
be
also
can

Tent
dif
assigned
to
ackages
be
can
dep
(the
Nt
ta
view
the there
f-
-

|
&
|
&
aie
Packages
subsystem
RMO
8-32
FIGURE ae
Layer Som
ai

View
Gu

aes
:
3
4
4

a
system
¢input
ete
data
validate
and
Edit
Ye
-layer
classes
input
domain
the
to
data
°Forward
st
Sufficient
and
placed
methods
there
:classes
are
in
the
correct
that
system
up
the
down
shut
and
eStart
ae
essin
‘i i
A
Sequence
rans.
dia
sing
require
at
:'z

in
elines
to
def,

maintaine
easily
systems
ar
that
develops
design encap
include
jented
design
principles
principles.
These
‘
Three-layer
ra

by the
access
to
notrefe
and
said
is
it
certain
sending
receiving
and
which
classes
be
should
wea
object
responsib
Finally,
coupling.
om
inks
has
too
much
preference.
tabbed
a
denoted
is
which
diagram, principle
classes
applies
that
of
set
entire
the
to
,Classes.
to
othe
have
visibility
classes
or
certain
that
In
Cohesive.
it
other
words,
disparate
processes,
be
Whe
diagrams.
wassequence
to
alternative
Viable
notation
type
of
Finally,
new
a make
of
use
designers
can
that
learned
also
You
REVIEW QUESTIONS
346
10.
11.

Which three models are most used to do object-oriented 20.

is
19.
18.
16,
1i7,.
14,
13.
V2

design?
Why do we say that design is “use case driven”? design?In otherwords, in w
Four icons, or shortcuts, can be used to depict different designed?
types of classes. List the four icons, tell what each means,
and show the symbol for it.
Todevelop
thefirst-cutsequenc
followthreesteps.
Briefly
descri
List the elements included in a method signature. Give Steps. +i .
an example of a method signature with all elements listed
correctly.
What notation is used to indicate a stereotype? Show an
example of a stereotyped class.
diagram. y
What is meant by navigation visibility? How is it shown in
Whatisthepurpose
of a package
UML? How is it implemented in programming code? is used? Show an example.
What doescouplingmean?Why is too much coupling How is dependency
indicated
on a
considered bad? What does it mean? c. ieee
What are some of the problems that occur when classes
List the primary responsibilitiesof
have low cohesion?
Now do the samefor the domain|;
What is meant by object responsibility? Why is it such an layer. ied.
important concept in design?
What is the objective of a use case controller class? What
What
isthedifference
between
an
andanetwork-based
system?
oeae
design principles does it typify?
What is three-layer design? What are the most common
layersfound in three-layerdesign?

~* ste

PART 3