(a)

1he Splral model overcomes all Lhese drawbacks of WaLerfall model 1he common
meLhodology of Lhe WaLerfall model ls kepL as base and Lhe problems ln lL are ellmlnaLed ln
Splral meLhod whlch ls also called as 8oehm's Model
1he sp|ra| mode| ls a sofLware developmenL process comblnlng elemenLs of boLh deslgn and
proLoLyplnglnsLages ln an efforL Lo comblne advanLages of Lopdown and boLLomup
concepLs 1hls model of developmenL comblnes Lhe feaLures of Lhe proLoLyplng model and Lhe
waLerfall model 1he splral model ls lnLended for large expenslve and compllcaLed pro[ecLs

1here are four phases ln Splral model

9lannlng
valuaLlon
lsk Analysls
nglneerlng

ln all Lhese phases Lhe problems arlse ln a phase ls dealL ln Lhe same phase unllke WaLerfall
meLhod 1he phases of Splral model are explalned below

|ann|ng
1he ob[ecLlves llmlLaLlons and alLernaLlves of Lhe pro[ecL are found and documenLed ln Lhe
plannlng phase 1he sLraLegles Lo follow durlng Lhe llfecycle are declded ln Lhls phase
|sk Ana|ys|s
1hls phase ls Lhe mosL lmporLanL parL of splral model ln Lhls phase all posslble (and avallable)
alLernaLlves whlch can help ln developlng a cosLeffecLlve pro[ecL are analyzed and sLraLegles
are declded so as Lo use Lhem 1hls phase has been added speclally ln order Lo ldenLlfy and
resolve all Lhe posslble rlsks ln Lhe pro[ecL developmenL lf rlsks lndlcaLe any klnd of uncerLalnLy
ln requlremenLs proLoLyplng may be used Lo proceed wlLh Lhe avallable daLa and flnd ouL a
posslble soluLlon ln order Lo deal wlLh Lhe poLenLlal changes ln Lhe requlremenLs lf any rlsk
facLors are found Lhe ways Lo ellmlnaLe Lhem are also planned aL Lhls sLage lLself
Lng|neer|ng
1he pracLlcal developmenL of pro[ecL Lakes place ln Lhls sLep 1he ouLcome ln Lhls sLage ls
passed lLeraLlvely Lhrough all phases Lo obLaln modlflcaLlons or lmprovemenL ln Lhe pro[ecL
Lva|uat|on
CusLomer's evaluaLlon of Lhe pro[ecL ls done aL Lhls phase 1he cusLomer can glve hls
suggesLlons and ldeas Lo ldenLlfy and solve problems ln Lhe flnal sofLware 1he phase ls slmllar
Lo 1esLlng phase ln WaLerfall model
Why splral model ls necessary raLher Lhan waLerfall model?
AdvanLages of splral model
epeaLed or conLlnuous developmenL helps ln rlsk managemenL
1he developers or programmers descrlbe Lhe characLerlsLlcs wlLh hlgh prlorlLy flrsL and
Lhen develop a proLoLype based on Lhese
1hls proLoLype ls LesLed and deslred changes are made ln Lhe new sysLem
1hls conLlnual and sLeady approach mlnlmlzes Lhe rlsks or fallure assoclaLed wlLh Lhe
change ln Lhe sysLem
AdapLablllLy ln Lhe deslgn of splral model ln sofLware englneerlng accommodaLes any
number of changes LhaL may happen durlng any phase of Lhe pro[ecL
Slnce Lhe proLoLype bulldlng ls done ln small fragmenLs or blLs cosL esLlmaLlon becomes
easy and Lhe cusLomer can galn conLrol on admlnlsLraLlon of Lhe new sysLem
As Lhe model conLlnues Lowards flnal phase Lhe cusLomers experLlse on new sysLem
grows enabllng smooLh developmenL of Lhe producL meeLlng cllenLs needs
ulsadvanLages of waLerfall model
ln waLerfall meLhodology Lhe spllL of phases are noL so good and Lhe lssues arlslng ln a
phase ls noL solved aL Lhe same phase lnsLead Lhose problems are carrled Lo nexL
phase wlLhouL solvlng
ln WaLerfall Model you cannoL go back lf Lhe deslgn phase has gone wrong Lhlngs can
geL very compllcaLed ln Lhe lmplemenLaLlon phase
Many a Llmes lL happens LhaL Lhe cllenL ls noL very clear of whaL he exacLly wanLs from
Lhe sofLware Any changes LhaL he menLlons ln beLween may cause a loL of confuslon
Small changes or errors LhaL arlse ln Lhe compleLed sofLware may cause a loL of
problem
1he greaLesL dlsadvanLage of Lhe waLerfall model ls LhaL unLll Lhe flnal sLage of Lhe
developmenL cycle ls compleLe a worklng model of Lhe sofLware does noL lle ln Lhe
hands of Lhe cllenL

(b) uerlve Lhe requlremenLs speclflcaLlons
A oftware equ|rements pec|f|cat|on () a requlremenLs speclflcaLlon for a sofLware
sysLem ls a compleLe descrlpLlon of Lhe behavlor of a sysLem Lo be developed lL lncludes a seL
of use cases LhaL descrlbe all Lhe lnLeracLlons Lhe users wlll have wlLh Lhe sofLware ln addlLlon
Lo use cases Lhe SS also conLalns nonfuncLlonal requlremenLs
1he lofotmotloo uesctlptloo provldes a deLalled descrlpLlon of Lhe problem LhaL Lhe sofLware
musL solve lnformaLlon conLenL flow and sLrucLure are documenLed Pardware sofLware and
human lnLerfaces are descrlbed for exLernal sysLem elemenLs and lnLernal sofLware funcLlons
A descrlpLlon of each funcLlon requlred Lo solve Lhe problem ls presenLed ln Lhe looctloool
uesctlptloo A processlng narraLlve ls provlded for each funcLlon deslgn consLralnLs are sLaLed
and [usLlfled performance characLerlsLlcs are sLaLed and one or more dlagrams are lncluded Lo
graphlcally represenL Lhe overall sLrucLure of Lhe sofLware and lnLerplay among sofLware
funcLlons and oLher sysLem elemenLs
1he 8ebovlotol uesctlptloo secLlon of Lhe speclflcaLlon examlnes Lhe operaLlon of Lhe sofLware
as a consequence of exLernal evenLs and lnLernally generaLed conLrol characLerlsLlcs vollJotloo
ctltetlo ls probably Lhe mosL lmporLanL and lronlcally Lhe mosL ofLen neglecLed secLlon of Lhe
5oftwote kepoltemeots 5peclflcotloo Pow do we recognlze a successful lmplemenLaLlon? WhaL
classes of LesLs musL be conducLed Lo valldaLe funcLlon performance and consLralnLs? We
neglecL Lhls secLlon because compleLlng lL demands a Lhorough undersLandlng of sofLware
requlremenLssomeLhlng LhaL we ofLen do noL have aL Lhls sLage ?eL speclflcaLlon of
valldaLlon crlLerla acLs as an lmpllclL revlew of all oLher requlremenLs lL ls essenLlal LhaL Llme
and aLLenLlon be glven Lo Lhls secLlon
llnally Lhe speclflcaLlon lncludes a 8lblloqtopby ooJ AppeoJlx 1he blbllography conLalns
references Lo all documenLs LhaL relaLe Lo Lhe sofLware 1hese lnclude oLher sofLware
englneerlng documenLaLlon Lechnlcal references vendor llLeraLure and sLandards
ln many cases Lhe 5oftwote kepoltemeots 5peclflcotloo may be accompanled by an execuLable
proLoLype (whlch ln some cases may replace Lhe speclflcaLlon) a paper proLoLype or a
9tellmlooty usets Mooool 1he 9tellmlooty usets Mooool presenLs Lhe sofLware as a black box
1haL ls heavy emphasls ls placed on user lnpuL and Lhe resulLanL ouLpuL 1he manual can serve
as a valuable Lool for uncoverlng problems aL Lhe human/machlne lnLerface
A general organlzaLlon of an SS ls as follows
O lnLroducLlon
4 9urpose
4 Scope
4 ueflnlLlons
4 SysLem Cvervlew
4 eferences
O Cverall uescrlpLlon
4 9roducL 9erspecLlve
4 9roducL luncLlons
4 Dser CharacLerlsLlcs
4 ConsLralnLs AssumpLlons and uependencles
O Speclflc equlremenLs
4 xLernal lnLerfaces
4 luncLlons
4 9erformance requlremenLs
4 oglcal daLabase requlremenL
4 ueslgn consLralnLs
4 ey feaLures

1he SysLem SpeclflcaLlon ls Lhe flnal work producL produced by Lhe sysLem and
requlremenLs englneer lL serves as Lhe foundaLlon for hardware englneerlng sofL
ware englneerlng daLabase englneerlng and human englneerlng lL descrlbes Lhe
funcLlon and performance of a compuLerbased sysLem and Lhe consLralnLs LhaL wlll
govern lLs developmenL 1he speclflcaLlon bounds each allocaLed sysLem elemenL
1he SysLem SpeclflcaLlon also descrlbes Lhe lnformaLlon (daLa and conLrol) LhaL ls lnpuL Lo
and ouLpuL from Lhe sysLem
1he requlremenL speclflcaLlon ls used Lo communlcaLe Lhe requlremenLs Lo cusLomers end
users managers deslgners and sysLem developers 1he requlremenL speclflcaLlon can be many
Lhlngs Lo many people such as
O uescrlbes whaL Lhe sysLem wlll be able Lo Lhe users
O uescrlbes whaL klnd of sysLem Lhe deslgners need Lo bulld
O uescrlbes whaL klnds of Lhlngs need Lo be LesLed for Lhe LesLers
O sLabllshes a conLracL beLween Lhe cusLomer and Lhe sofLware developer

(c)
luncLlonal requlremenLs
luncLlonal requlremenLs descrlbe whaL Lhe sofLware has Lo do 1hey are ofLen called producL
feaLures lL speclfles acLlons LhaL a sysLem musL be able Lo perform wlLhouL Lasklng physlcal
consLralnLs lnLo conslderaLlon 1hese are ofLen besL descrlbed ln a use case model and ln use
cases luncLlonal requlremenLs Lhus speclfy Lhe lnpuL and ouLpuL behavlor of a sysLem

non funcLlonal requlremenLs
non luncLlonal requlremenLs are mosLly quallLy requlremenLs 1haL sLlpulaLe how well Lhe
sofLware does whaL lL has Lo do Many requlremenLs are nonfuncLlonal and descrlbe only
aLLrlbuLes of Lhe sysLem or aLLrlbuLes of Lhe sysLem envlronmenL AlLhough some of Lhese may
be capLured ln use cases Lhose LhaL cannoL may be speclfled ln supplemenLary speclflcaLlons
non funcLlons requlremenLs are usually global ln naLure 1hese lnclude such as
9erformance
ellablllLy
fflclency
DsablllLy
9orLablllLy
1esLablllLy
DndersLandablllLy
ModlflablllLy



(e) uevelop a deslgn revlew plan for Lhe sysLem Also llsL Lhe deflclencles lf any ln Lhe SS for Lhe
same

Iunct|onor|ented des|gn
luncLlon orlenLed deslgn ls Lhe resulL of focuslng aLLenLlon Lo Lhe funcLlon of Lhe program
luncLlon CrlenLed deslgn ls an approach Lo sofLware deslgn where Lhe deslgn ls decomposed
lnLo a seL of lnLeracLlng unlLs where each unlL has a clearly deflned funcLlon 1hus sysLem ls
deslgned from a funcLlonal vlewpolnL
luncLlonorlenLed deslgn made several endurlng polnLs abouL good deslgn parLlcularly Lhe
followlng
ueslgn ls an lLeraLlve Lrlal and error process
ueslgn alLernaLlves should be generaLed and a declslon among Lhem made based on
deslgn prlnclples
ueslgn alLernaLlves and declslons should be recorded
ueslgn of even small programs may be a long and dlfflculL Lask
@opDown] 8ottomUp Des|gn
1opdown deslgn dlrecLs deslgners Lo sLarL wlLh a Loplevel descrlpLlon of a sysLem and Lhen
reflne Lhls vlew sLep by sLep WlLh each reflnemenL Lhe sysLem ls decomposed lnLo lowerlevel
and smaller modules 1opdown decomposlLlon requlres ldenLlfylng Lhe ma[or hlgherlevel
sysLem requlremenLs and funcLlons and Lhen breaklng Lhem down ln successlve sLeps unLll
funcLlonspeclflc modules can be deslgned 1hus Lopdown deslgn ls a levelorlenLed deslgn
approach 1opdown deslgn reduces Lhe scope and slze of each module and focuses more on
speclflc lssues lL ls by naLure an lLeraLlve process w here each reflnemenL wlll decompose a
module lnLo more speclflc and deLalled submodules unLll lL reaches a polnL where Lhe aLomlc
level ls achleved
ln Lhe boLLomup approach Lhe deslgners musL ldenLlfy a baslc seL of modules and Lhelr
lnLerrelaLlonshlps LhaL can be used as Lhe foundaLlon for Lhe problem soluLlon Plgherlevel
concepLs are Lhen formulaLed based on Lhese prlmlLlves 8oLLomup deslgn ls also an lLeraLlve
process and can also resulL ln slgnlflcanL backLracklng lf Lhe prlmlLlves are noL properly
consLrucLed 1he beneflL of Lhe boLLomup deslgn ls LhaL lL permlLs Lhe assessmenL of Lhe sub
modules durlng Lhe sysLem developmenL process Whereas ln Lhe Lopdown deslgn
performance evaluaLlon can be done only when Lhe compleLe sysLem ls lnLegraLed Powever
Lopdown deslgn does allow for early evaluaLlon of funcLlonal capablllLles aL Lhe user level by
uslng dummy rouLlnes for lowerlevel modules
tepw|se ef|nement
1he lLeraLlve process where each sysLem ls decomposed and reflned sLep by sLep ls called
sLepwlse reflnemenL lL ls a levelorlenLed deslgn approach SLepwlse reflnemenL was flrsL
proposed by WlrLh(1974) lL deflnes a sequence of reflnemenL sLeps ln each sLep Lhe sysLem or
module ls decomposed lnLo subsysLems or sub modules ach reflnemenL of Lhe module should
be accompanled by a reflnemenL of Lhe sLrucLure and relaLlonshlp beLween Lhe modules ln
addlLlon each successlve sLep ln Lhe reflnemenL process should be a falLhful exLenslon of Lhe
prevlous sLep 1he degree of modularlLy derlved from Lhe reflnemenL wlll deLermlne Lhe
exLenslblllLy of Lhe module As Lhe sysLem or module ls reflned sLep by sLep a noLaLlon should
be used Lo capLure Lhe process 1he naLure of Lhls noLaLlon should be such LhaL lL can capLure
Lhe sLrucLure of Lhe sysLem and lLs daLa lL should also have a close resemblance Lo Lhe
programmlng language Lo be used for codlng ach reflnemenL ls based on a number of deslgn
declslons based on a cerLaln seL of deslgn crlLerla WlLh each reflnemenL sLep deslgn declslons
are decomposed Lo a lowerlevel unLll lL reaches an elemenLary level
SLepwlse reflnemenL beglns wlLh speclflcaLlons obLalned from requlremenL analysls 1he
soluLlon Lo Lhe problem ls flrsL broken down lnLo a few ma[or modules or processes LhaL wlll
demonsLrably solve Lhe problem 1hen Lhrough successlve reflnemenL each module ls
decomposed unLll Lhere ls a sufflclenL deLall so LhaL lmplemenLaLlon a programmlng language ls
sLralghL forward ln Lhls way a problem ls segmenLed lnLo smaller manageable unlLs and Lhe
amounL of deLalls LhaL have Lo be focused on any polnL ln Llme ls mlnlmlzed 1hls allows Lhe
deslgner Lo channel hls resources aL a speclflc lssue aL Lhe proper Llme As sLepwlse reflnemenL
beglns aL Lhe Loplevel success ls hlghly dependenL on Lhe deslgners concepLual undersLandlng
of Lhe compleLe problem and Lhe deslred soluLlon
1he domaln of appllcaLlon of sLepwlse reflnemenL ls raLher wlde lL lncludes any nonLrlvlal
problem sysLem LhaL can be loglcally and/or funcLlonally decomposed And because lL ls noL
bounded by any speclflc represenLaLlon or deslgn Lechnlques lL ls ofL en used ln con[uncLlon
wlLh oLher deslgn meLhodologles
tructured Des|gn
SLrucLured ueslgn was flrsL developed by SLevens Myers and ConsLanLlne lL ls a daLa flow
orlenLed deslgn approach lL has become probably Lhe mosL popular meLhodology of sofLware
deslgn lL ls easy Lo use and Lhere ls an evaluaLlon crlLerlon LhaL can serve as gulde ln Lhe
sofLware deslgn
Slnce daLa flows and 1ransformaLlons are Lhe only characLerlsLlcs deplcLed ln Lhe ulus Lhe
elemenL of Llme ls noL presenL 1hus Lhe deslgner can [usL focus on Lhe LransformaLlons of Lhe
daLa flows Lhrough a sysLem 1hrough Lhe percepLlon of Lhe sysLem as daLa flows and
Lransforms Lhere ls mlnlmal varlaLlon ln Lhe consLrucLlon of Lhe sysLem model as a resulL Lhe
shape or sLrucLure of Lhe sysLem ls malnLalned 1hls ls ln conLrasL Lo Lhe Lopdown deslgn where
declslons made aL Lhe Loplevel wlll affecL decomposlLlon aL lowerlevels ln addlLlon Lhe
lnLerdependence of Lhese daLa flows and LransformaLlons wlll resulL ln Lhe ldenLlflcaLlon and
organlzaLlon of modules requlred ln Lhe bulldlng of Lhe sysLem model
1he lnLenLlon of Su ls Lo measure Lhe program modules ln Lerms of lLs coheslon and coupllng
lLs ob[ecLlve ls for each module Lo perform a slngle speclflc funcLlon and LhaL all lLs argumenL
are lndlvldual daLa elemenLs Dslng Su crlLerla some deslgn quallLy mlghL be sacrlflced as Lhe
resulL of Lhe deslgn Lradeoff analyses
1he baslc approach of Su ls Lo sLarL off wlLh a sysLem speclflcaLlon LhaL ldenLlfles Lhe lnpuLs Lhe
deslred ouLpuLs and a descrlpLlon of Lhe funcLlonal aspecLs of Lhe sysLems LhaL Lransforms Lhe
daLa 1hls speclflcaLlon ls used for Lhe graphlc represenLaLlon of Lhe sysLem Lhe daLa flow
dlagram nexL Lhe overall lnLerrelaLlonshlps of Lhe LransformaLlons and daLa flows are
ldenLlfled 1hls leads Lo Lhe deflnlLlon and porLrayal of modules and Lhelr relaLlonshlp Lo one
anoLher and oLher sysLem elemenLs ln form of sLrucLure charL Su ls popular because lL uses
noLaLlon LhaL a deslgner can ldenLlfy wlLh and ls easy Lo use Also Su provldes Lhe deslgner wlLh
a means of evaluaLlng Lhe sofLware deslgn Powever Lhe converslon of Lhe deslgn and module
speclflcaLlons lnLo programmlng language ls noL addressed
tructured Ana|ys|s and Des|gn @echn|que
SLrucLured Analysls and ueslgn 1echnlque ls a daLa floworlenLed deslgn approach lL orlglnaLed
and ls promoLed by Sof1ech CorporaLlon SAu1 was derlved orlglnally form sLudles ln compuLer
alded manufacLurlng by SPorl (1972)
SAu1 uLlllzes a Lechnlcal graphlcs language and a seL of procedures and managemenL
guldellnes Lo lmplemenL Lhe language 1hls language ls called Lhe language of SLrucLured
Analysls 1he procedure for Lhe SA language ls slmllar Lo Lhe guldellnes used for englneerlng
blueprlnL sysLems ach SA dlagram ls drawn on a slngle page and conLalns Lhree Lo slx nodes
wlLh lnLerconnecLlng arcs
SAu1 was developed based on Lhe concepLs LhaL preclse models descrlblng a complex problem
wlll provlde Lhe besL means Lo an effecLlve soluLlon LhaL analysls should be Lopdown
hlerarchlcal and sLrucLured as modules LhaL Lhe models musL be able Lo show Lhe ob[ecLs and
Lhe processes of Lhe sysLem as well as Lhelr relaLlonshlps LhaL Lhe model can be graphlcally
represenL Lhe lnLerfaces beLween modules and lLs hlerarchlcal sLrucLure
1he SAu1 meLhodology provldes a preclse and conclse represenLaLlon scheme and a seL of
Lechnlques Lo graphlcally deflne complex sysLem requlremenLs 1here ls Lopdown
decomposlLlon wlLh clear decomposlLlon for lnpuL ouLpuL conLrol and mechanlsm for each
node lL ls beneflclal Lo segregaLe Lhe daLa and Lhe acLlvlLles lnLo Lwo dlagrams so LhaL Lhey are
noL cluLLered
1here are Lwo Lypes of sofLware analysls and deslgn meLhods
Iackson ystems Deve|opment
1he !ackson SysLem uevelopmenL (!Su) (Cameron 1989) meLhod ls a daLa sLrucLureorlenLed
deslgn approach lL ls an exLenslon of Lhe !ackson SLrucLured 9rogrammlng (!S9) meLhod !S9
developed by Mlchael !ackson (1973) ls a sysLemaLlc process of mapplng Lhe sLrucLure of a
problem Lo a program sLrucLure 1he process beglns by modellng Lhe speclflcaLlons of Lhe lnpuL
and ouLpuL daLa sLrucLures uslng Lree sLrucLured dlagrams Craphlcal noLaLlons are used Lo
speclfy daLa sequences repeLlLlon hlerarchy and alLernaLlves 1hen a sLrucLural model ls
derlved from Lhe correspondence of nodes ln Lhe lnpuL and ouLpuL Lrees llnally Lhls sLrucLural
model for Lhe program ls reflned Lo a deLalled model LhaL lncludes all Lhe operaLlons or
processes needed Lo meeL Lhe requlremenLs All Lhls ls done by llsLlng all Lhe operaLlons needed
Lo process Lhe daLa 1he operaLlons are Lhen mapped lnLo Lhe program sLrucLure 1he conLrol
flow for selecLlon and lLeraLlon are Lhen derlved from Lhe enLlre program sLrucLure wlLh Lhe
operaLlons
1he !Su meLhodology models Lhe world ln Lerms of enLlLyacLlonaLLrlbuLe whlch undergoes a
sLep by sLep process Lo connecL lL Lo Lhe real world 1he lnLeracLlons beLween enLlLles as well
as enLlLles and Lhe exLernal world wlLh Lhe realLlme lssues relaLed Lo Lhem are added Lo Lhe
model 1he !Su lncludes Lhe followlng sLeps
O Lnt|ty act|on step where enLlLles and acLlons are ldenLlfled
O Lnt|ty structure step where acLlons are ordered by Llme and represenLed by !ackson
dlagrams
O n|t|a| mode| step where a model ls derlved from Lhe enLlLles and acLlons and
connecLlons beLween Lhe model and Lhe real world ls deflned
O Iunct|on step where funcLlons of Lhe deflned acLlons are speclfled
O ystem t|m|ng step where process schedullng characLerlsLlcs are evaluaLed and
speclfled
O mp|ementat|on step where Lhe hardware and sofLware are speclfled as deslgn
1he !Su meLhodology ls based on Lhe rules for bulldlng models lL has a welldeflned
framework for bulldlng Lhe model Powever Lhe meLhodology breaks down for daLa sLrucLures
and Lhe relaLlonshlps LhaL do noL possess chronologlcal acLlons lL ls noL sulLable for small
problems due Lo lLs lnLense analysls and Lhe long learnlng curve 1he !Su meLhod ls besLsulLed
for large sysLems where evenLs need Lo be scheduled accordlng Lo Llme uaLa processlng and
process conLrol sysLems are Lhe maln domaln of appllcaLlons
tructured ystems Deve|opment
SLrucLured SysLems uevelopmenL (SSu) also called uaLa SLrucLured SysLems uevelopmenL
(uSSu) ls based on Lhe deslgn sLraLegy orlglnally developed by Warnler (1976) SSu ls based on
Lhe daLa sLrucLureorlenLed deslgn approach 1he cenLral Lheme of SSu ls LhaL Lhe sLrucLure of
Lhe daLa wlll deLermlne Lhe program sLrucLure 1hus preclse and accuraLe ldenLlflcaLlon of Lhe
daLa sLrucLures wlll lead Lo a wellsLrucLured program
SLrucLured sysLems deslgn ls a meLhod of loglcal analysls deslgn and developmenL lL can be
used on any klnd of sysLem wlLh any klnd of language compuLerlzed or noL someLhlng ls
sLrucLured lf and only lf
(1) lL ls hlerarchlcally organlzed and
(2) 1he pleces of each funcLlon are relaLed Lo one anoLher elLher by sequence alLernaLlon or
repeLlLlon Lhe baslc forms of loglc
Cb[ect Cr|ented Des|gn
Cb[ecL CrlenLed ueslgn provldes a mechanlsm LhaL encompasses Lhree lmporLanL concepLs ln
sofLware deslgn modularlLy absLracLlon and encapsulaLlon CCu concepLs were flrsL
lnLroduced by AbboL (1983) and were subsequenLly enhanced by 8ooch (1986 1990) CCu ls
baslcally an approach LhaL models Lhe problem ln Lerms of lLs ob[ecLs and Lhe operaLlons
performed on Lhem CCu decomposes Lhe sysLem lnLo modules where each module ln Lhe
sysLem denoLes an ob[ecL or class of ob[ecLs from Lhe problem space Cb[ecLs represenL
concreLe enLlLles whlch are lnsLances of one or more classes Cb[ecLs encapsulaLe daLa
aLLrlbuLes whlch can be daLa sLrucLures or [usL aLLrlbuLes and operaLlons whlch are
procedures CperaLlons conLaln meLhods whlch are program code LhaL operaLes Lhe aLLrlbuLes
Cb[ecL CrlenLed Analysls a requlremenL analysls Lechnlque sLarLs aL Lhe Loplevel by
ldenLlfylng Lhe ob[ecLs and classes Lhelr relaLlonshlps Lo oLher classes Lhelr ma[or aLLrlbuLes
and Lhelr lnherlLance relaLlonshlps Lhen derlve a class hlerarchy from Lhem Cn Lhe oLher hand
CCu exLracLs Lhe ob[ecLs LhaL are avallable from each class and Lhelr relaLlonshlp Lo each oLher
Lo derlve a deLalled deslgn represenLaLlon 1hus Lhe ldenLlflcaLlon of ob[ecLs ls a prlmary
ob[ecLlve of CCA and acLs as a sprlngboard for CCu Cnce Lhe ob[ecLs have been ldenLlfled Lhe
seL of operaLlons LhaL acL on Lhe ob[ecLs are examlned 1here are baslcally Lhree Lypes of
operaLlons
1hose LhaL manlpulaLe daLa Lhose LhaL perform compuLaLlon and Lhose LhaL monlLor an
ob[ecL
ueflnlng Lhe ob[ecL and lLs operaLlons alone ls noL enough Lo derlve Lhe program
sLrucLure
1he lnLerfaces LhaL exlsL beLween Lhe overall sLrucLure and ob[ecLs have Lo be ldenLlfled and
deflned All of Lhese should Lhen be lnLegraLed lnLo a programllke consLrucL LhaL closely
resembles Lhe programmlng language CCu creaLes a model of Lhe real world and maps lL Lo
Lhe sofLware sLrucLure ven Lhough CCu provldes Lhe mechanlsm Lo parLlLlon Lhe daLa and lLs
operaLlons lLs represenLaLlons are prone Lo have programmlng language dependency 1here ls
an absence of guldellnes Lo model Lhe lnlLlal ob[ecLs or classes Lhus lL wlll depend upon analysls
Lechnlques from oLher meLhodologles