Professional Documents
Culture Documents
Establishingtheoverall
structureofasoftwaresystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide1
Objectives
Tointroducearchitecturaldesignandtodiscussits
importance
Toexplainwhymultiplemodelsarerequiredto
documentasoftwarearchitecture
Todescribetypesofarchitecturalmodelthatmay
beused
Todiscusshowdomainspecificreferencemodels
maybeusedasabasisforproductlinesandto
comparesoftwarearchitectures
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide2
Topicscovered
Systemstructuring
Controlmodels
Modulardecomposition
Domainspecificarchitectures
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide3
Softwarearchitecture
Thedesignprocessforidentifyingthesub
systemsmakingupasystemandtheframework
forsubsystemcontrolandcommunicationis
architecturaldesign
Theoutputofthisdesignprocessisadescription
ofthesoftwarearchitecture
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide4
Architecturaldesign
Anearlystageofthesystemdesignprocess
Representsthelinkbetweenspecificationand
designprocesses
Oftencarriedoutinparallelwithsome
specificationactivities
Itinvolvesidentifyingmajorsystemcomponents
andtheircommunications
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide5
Advantagesofexplicitarchitecture
Stakeholdercommunication
Systemanalysis
Architecturemaybeusedasafocusofdiscussionbysystem
stakeholders
Meansthatanalysisofwhetherthesystemcanmeetitsnon
functionalrequirementsispossible
Largescalereuse
Thearchitecturemaybereusableacrossarangeofsystems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide6
Architecturaldesignprocess
Systemstructuring
Controlmodelling
Thesystemisdecomposedintoseveralprincipalsubsystems
andcommunicationsbetweenthesesubsystemsareidentified
Amodelofthecontrolrelationshipsbetweenthedifferentparts
ofthesystemisestablished
Modulardecomposition
Theidentifiedsubsystemsaredecomposedintomodules
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide7
Subsystemsandmodules
Asubsystemisasysteminitsownrightwhose
operationisindependentoftheservicesprovided
byothersubsystems.
Amoduleisasystemcomponentthatprovides
servicestoothercomponentsbutwouldnot
normallybeconsideredasaseparatesystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide8
Architecturalmodels
Differentarchitecturalmodelsmaybeproduced
duringthedesignprocess
Eachmodelpresentsdifferentperspectivesonthe
architecture
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide9
Architecturalmodels
Staticstructuralmodelthatshowsthemajor
systemcomponents
Dynamicprocessmodelthatshowstheprocess
structureofthesystem
Interfacemodelthatdefinessubsystem
interfaces
Relationshipsmodelsuchasadataflowmodel
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide10
Architecturalstyles
Thearchitecturalmodelofasystemmayconform
toagenericarchitecturalmodelorstyle
Anawarenessofthesestylescansimplifythe
problemofdefiningsystemarchitectures
However,mostlargesystemsareheterogeneous
anddonotfollowasinglearchitecturalstyle
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide11
Architectureattributes
Performance
Security
Isolatesafetycriticalcomponents
Availability
Usealayeredarchitecturewithcriticalassetsininnerlayers
Safety
Localiseoperationstominimisesubsystemcommunication
Includeredundantcomponentsinthearchitecture
Maintainability
Usefinegrain,selfcontainedcomponents
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide12
Systemstructuring
Concernedwithdecomposingthesysteminto
interactingsubsystems
Thearchitecturaldesignisnormallyexpressedas
ablockdiagrampresentinganoverviewofthe
systemstructure
Morespecificmodelsshowinghowsubsystems
sharedata,aredistributedandinterfacewitheach
othermayalsobedeveloped
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide13
iidenO
V
sty
o
n
tsyb
e
m
jifecam
tionconA
rtm
G
r
i
p
e
r
o
l
e
r
c
o
n
t
o
l
P
aseclykeg
itm
n
o
P
asycktein
g
o
n
v
e
y
o
r
mC
ctrl
Packingrobotcontrolsystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide14
Therepositorymodel
Subsystemsmustexchangedata.Thismaybe
doneintwoways:
Shareddataisheldinacentraldatabaseorrepositoryandmay
beaccessedbyallsubsystems
Eachsubsystemmaintainsitsowndatabaseandpassesdata
explicitlytoothersubsystems
Whenlargeamountsofdataaretobeshared,the
repositorymodelofsharingismostcommonly
used
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide15
D
e
s
i
g
n
C
o
d
e
d
t
o
r
g
e
n
r
a
t
r
itranlagtnor D
D
e
s
P
r
o
j
e
c
t
P
r
o
g
a
m
e
p
s
i
r
y
e
d
i
t
r
sanlyign
e
R
e
p
o
r
t
ergna
CASEtoolsetarchitecture
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide16
Repositorymodelcharacteristics
Advantages
Efficientwaytosharelargeamountsofdata
Subsystemsneednotbeconcernedwithhowdataisproduced
Centralisedmanagemente.g.backup,security,etc.
Sharingmodelispublishedastherepositoryschema
Disadvantages
Subsystemsmustagreeonarepositorydatamodel.Inevitablya
compromise
Dataevolutionisdifficultandexpensive
Noscopeforspecificmanagementpolicies
Difficulttodistributeefficiently
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide17
Clientserverarchitecture
Distributedsystemmodelwhichshowshowdata
andprocessingisdistributedacrossarangeof
components
Setofstandaloneserverswhichprovidespecific
servicessuchasprinting,datamanagement,etc.
Setofclientswhichcallontheseservices
Networkwhichallowsclientstoaccessservers
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide18
C
lient1C
lienW
t2idebandw
lithnetw
C
ieonrtk3C
lient4
aC
C
tasterllvo
g
u
e
V
i
d
e
o
P
i
c
t
u
r
e
H
y
p
e
r
t
x
s
r
v
s
e
v
s
v
ilfm
ecslippD
ihogtizraepdhsH
yp
ew
rbtx
ogueF
Filmandpicturelibrary
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide19
Clientservercharacteristics
Advantages
Distributionofdataisstraightforward
Makeseffectiveuseofnetworkedsystems.Mayrequirecheaper
hardware
Easytoaddnewserversorupgradeexistingservers
Disadvantages
Noshareddatamodelsosubsystemsusedifferentdata
organisation.datainterchangemaybeinefficient
Redundantmanagementineachserver
Nocentralregisterofnamesandservicesitmaybehardtofind
outwhatserversandservicesareavailable
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide20
Abstractmachinemodel
Usedtomodeltheinterfacingofsubsystems
Organisesthesystemintoasetoflayers(orabstract
machines)eachofwhichprovideasetofservices
Supportstheincrementaldevelopmentofsub
systemsindifferentlayers.Whenalayerinterface
changes,onlytheadjacentlayerisaffected
However,oftendifficulttostructuresystemsinthis
way
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide21
V
eO
sD
rb
ijaO
ctpbam
o
n
asretninyg
egstem
tm
n
syem
Versionmanagementsystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide22
Controlmodels
Areconcernedwiththecontrolflowbetween
subsystems.Distinctfromthesystem
decompositionmodel
Centralisedcontrol
Onesubsystemhasoverallresponsibilityforcontrolandstarts
andstopsothersubsystems
Eventbasedcontrol
Eachsubsystemcanrespondtoexternallygeneratedevents
fromothersubsystemsorthesystemsenvironment
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide23
Centralisedcontrol
Acontrolsubsystemtakesresponsibilityfor
managingtheexecutionofothersubsystems
Callreturnmodel
Topdownsubroutinemodelwherecontrolstartsatthetopofa
subroutinehierarchyandmovesdownwards.Applicableto
sequentialsystems
Managermodel
Applicabletoconcurrentsystems.Onesystemcomponentcontrols
thestopping,startingandcoordinationofothersystemprocesses.
Canbeimplementedinsequentialsystemsasacasestatement
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide24
M
a
i
n
p
r
o
g
m
R
o
u
t
i
n
e
1
R
o
u
t
i
n
e
2
R
o
u
t
i
n
e
3
R
outine1.R
outine1.2R
outine3.1R
outine3.2
Callreturnmodel
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide25
S
e
n
s
o
r
A
c
t
u
a
o
r
procecS
p
r
o
e
s
y
s
t
e
m
o
n
r
o
l
r
C
om
trcesaioninU
p
u
stfearc hF
anu
ldter
Realtimesystemcontrol
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide26
Eventdrivensystems
Drivenbyexternallygeneratedeventswherethe
timingoftheeventisoutwiththecontrolofthesub
systemswhichprocesstheevent
Twoprincipaleventdrivenmodels
Broadcastmodels.Aneventisbroadcasttoallsubsystems.Anysub
systemwhichcanhandletheeventmaydoso
Interruptdrivenmodels.Usedinrealtimesystemswhereinterrupts
aredetectedbyaninterrupthandlerandpassedtosomeother
componentforprocessing
Othereventdrivenmodelsincludespreadsheetsand
productionsystems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide27
Broadcastmodel
Effectiveinintegratingsubsystemsondifferent
computersinanetwork
Subsystemsregisteraninterestinspecificevents.When
theseoccur,controlistransferredtothesubsystem
whichcanhandletheevent
Controlpolicyisnotembeddedintheeventandmessage
handler.Subsystemsdecideoneventsofinterestto
them
However,subsystemsdontknowiforwhenanevent
willbehandled
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide28
S
ubs1ytemS
ubs2
tE
y
e
m
S
u
b
s
y
t
e
m
S
u
b
s
y
t
e
m
3
4
ventandm
esagehandler
Selectivebroadcasting
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide29
Interruptdrivensystems
Usedinrealtimesystemswherefastresponseto
aneventisessential
Thereareknowninterrupttypeswithahandler
definedforeachtype
Eachtypeisassociatedwithamemorylocation
andahardwareswitchcausestransfertoits
handler
Allowsfastresponsebutcomplextoprogramand
difficulttovalidate
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide30
I
n
t
e
r
u
p
t
s
IH
tandlevrecrouptH
n
a
n
d
l
e
r
H
a
n
d
l
e
r
H
a
n
d
l
e
r
1
2
3
4
P
ro1cesP
ro2cesP
ro3cesP
ro4ces
Interruptdrivencontrol
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide31
Modulardecomposition
Anotherstructurallevelwheresubsystemsare
decomposedintomodules
Twomodulardecompositionmodelscovered
Anobjectmodelwherethesystemisdecomposedinto
interactingobjects
Adataflowmodelwherethesystemisdecomposedinto
functionalmoduleswhichtransforminputstooutputs.Also
knownasthepipelinemodel
Ifpossible,decisionsaboutconcurrencyshould
bedelayeduntilmodulesareimplemented
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide32
Objectmodels
Structurethesystemintoasetoflooselycoupled
objectswithwelldefinedinterfaces
Objectorienteddecompositionisconcernedwith
identifyingobjectclasses,theirattributesand
operations
Whenimplemented,objectsarecreatedfrom
theseclassesandsomecontrolmodelusedto
coordinateobjectoperations
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide33
tcncudaestroitm
C
u
s
o
m
e
r
R
e
c
i
p
t
esperr#iod idnm
i
n
v
o
i
#
d
a
t
m
u
n
t
I
n
v
o
i
c
e
c
s
o
m
e
r
#
v
o
i
c
e
#
a
t
u
n
t
c
s
o
m
e
r
P
a
y
m
e
n
t
i
u
(
)
s
e
n
d
R
e
m
i
n
d
e
r
(
)
idcnm
iatseoucm
v
o
#
a
c
p
t
P
a
y
t
nter# cp
Invoiceprocessingsystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide34
Dataflowmodels
Functionaltransformationsprocesstheirinputsto
produceoutputs
Maybereferredtoasapipeandfiltermodel(asin
UNIXshell)
Variantsofthisapproachareverycommon.When
transformationsaresequential,thisisabatch
sequentialmodelwhichisextensivelyusedindata
processingsystems
Notreallysuitableforinteractivesystems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide35
I
s
u
e
R
e
c
i
p
t
s
r
e
c
i
p
t
s
R
eiaInnd
vo
ivoscicueesdpP
Iadayeym
nm
tiefnysts payF
im
n
d
I
s
u
e
eutsrpeaym
tidr R
n
em
inders
Invoiceprocessingsystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide36
Domainspecificarchitectures
Architecturalmodelswhicharespecifictosome
applicationdomain
Twotypesofdomainspecificmodel
Genericmodelswhichareabstractionsfromanumberofreal
systemsandwhichencapsulatetheprincipalcharacteristicsofthese
systems
Referencemodelswhicharemoreabstract,idealisedmodel.Provide
ameansofinformationaboutthatclassofsystemandofcomparing
differentarchitectures
Genericmodelsareusuallybottomupmodels;
Referencemodelsaretopdownmodels
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide37
Genericmodels
Compilermodelisawellknownexamplealthough
othermodelsexistinmorespecialisedapplication
domains
Lexicalanalyser
Symboltable
Syntaxanalyser
Syntaxtree
Semanticanalyser
Codegenerator
Genericcompilermodelmaybeorganisedaccordingto
differentarchitecturalmodels
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide38
S
y
m
b
o
l
t
a
e
talacsi S
y
n
eanm
alynsticgenC
ord
eation
eanxliycsalS
L
Compilermodel
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide39
ianlycsaelraS
L
e
x
yn
tlasx
S
e
m
a
n
t
i
c
e
r
a
n
l
y
s
e
r
tE
rp
P
din
e
y
A
b
s
t
r
a
c
t
G
r
a
m
a
r
O
p
t
i
m
z
e
r
ritorsyS
ny
tam
x
e
d
e
f
i
n
t
o
n
beolR
O
u
t
p
C
o
d
e
d
e
f
i
n
o
n
g
e
n
r
a
t
r
epositry
Languageprocessingsystem
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide40
Referencearchitectures
Referencemodelsarederivedfromastudyofthe
applicationdomainratherthanfromexisting
systems
Maybeusedasabasisforsystemimplementation
ortocomparedifferentsystems.Itactsasa
standardagainstwhichsystemscanbeevaluated
OSImodelisalayeredmodelforcommunication
systems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide41
7654A
tT
iS
lP
p
c
a
o
n
A
p
l
i
c
a
t
o
n
r
e
s
n
i
P
r
e
s
n
i
i
o
S
i
o
r
a
n
s
p
r
t
T
r
a
n
s
p
r
t
321N
tP
eD
w
o
k
N
e
t
w
o
r
k
N
e
t
w
o
k
ahyslcianC
om
lP
D
iuhnyiscatnionsm
a
D
a
l
i
n
P
h
y
s
c
a
edium
OSIreferencemodel
Application
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide42
Keypoints
Thesoftwarearchitectisresponsibleforderivinga
structuralsystemmodel,acontrolmodelandasub
systemdecompositionmodel
Largesystemsrarelyconformtoasinglearchitectural
model
Systemdecompositionmodelsincluderepository
models,clientservermodelsandabstractmachine
models
Controlmodelsincludecentralisedcontrolandevent
drivenmodels
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide43
Keypoints
Modulardecompositionmodelsincludedataflow
andobjectmodels
Domainspecificarchitecturalmodelsare
abstractionsoveranapplicationdomain.They
maybeconstructedbyabstractingfromexisting
systemsormaybeidealisedreferencemodels
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide44