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
Packingrobotcontrolsystem
Vision
system
Object
identification
system
Arm
controller
Gripper
controller
Packaging
selection
system
Packing
system
IanSommerville2000
Conveyor
controller
SoftwareEngineering,6thedition.Chapter10
Slide14
Therepositorymodel
Subsystemsmustexchangedata.Thismaybe
doneintwoways:
Shareddataisheldinacentraldatabaseorrepositoryandmay
beaccessedbyallsubsystems
Eachsubsystemmaintainsitsowndatabaseandpassesdata
explicitlytoothersubsystems
Whenlargeamountsofdataaretobeshared,the
repositorymodelofsharingismostcommonly
used
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide15
CASEtoolsetarchitecture
Design
editor
Design
translator
Project
repository
Design
analyser
IanSommerville2000
Code
generator
Program
editor
Report
generator
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
Filmandpicturelibrary
Client 1
Client 2
Client 3
Client 4
Wide-bandwidth network
Catalogue
server
Video
server
Picture
server
Hypertext
server
Catalogue
Film clip
files
Digitiz ed
photographs
Hypertext
web
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
Versionmanagementsystem
Version management
Object management
Database system
Operating
system
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
Callreturnmodel
Main
program
Routine 1
Routine 1.1
IanSommerville2000
Routine 2
Routine 1.2
Routine 3
Routine 3.1
SoftwareEngineering,6thedition.Chapter10
Routine 3.2
Slide25
Realtimesystemcontrol
Sensor
processes
Actuator
processes
System
contr oller
Computation
processes
IanSommerville2000
User
interface
SoftwareEngineering,6thedition.Chapter10
Fault
handler
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
Selectivebroadcasting
Sub-system
1
Sub-system
2
Sub-system
3
Sub-system
4
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide29
Interruptdrivensystems
Usedinrealtimesystemswherefastresponseto
aneventisessential
Thereareknowninterrupttypeswithahandler
definedforeachtype
Eachtypeisassociatedwithamemorylocation
andahardwareswitchcausestransfertoits
handler
Allowsfastresponsebutcomplextoprogramand
difficulttovalidate
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide30
Interruptdrivencontrol
Interrupts
Interrupt
vector
Handler
1
Handler
2
Handler
3
Handler
4
Process
1
Process
2
Process
3
Process
4
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
Invoiceprocessingsystem
Customer
customer#
name
address
credit period
Payment
invoice#
date
amount
customer#
IanSommerville2000
Receipt
Invoice
invoice#
date
amount
customer
invoice#
date
amount
customer#
issue ()
sendR eminder ()
acceptPayment ()
sendR eceipt ()
SoftwareEngineering,6thedition.Chapter10
Slide34
Dataflowmodels
Functionaltransformationsprocesstheirinputsto
produceoutputs
Maybereferredtoasapipeandfiltermodel(asin
UNIXshell)
Variantsofthisapproachareverycommon.When
transformationsaresequential,thisisabatch
sequentialmodelwhichisextensivelyusedindata
processingsystems
Notreallysuitableforinteractivesystems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide35
Invoiceprocessingsystem
Read issued
invoices
Invoices
IanSommerville2000
Issue
receipts
Receipts
Find
payments
due
Issue
payment
reminder
Identify
payments
Reminders
Payments
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
Compilermodel
Symbol
table
Lexical
analysis
IanSommerville2000
Syntactic
analysis
Semantic
analysis
SoftwareEngineering,6thedition.Chapter10
Code
generation
Slide39
Languageprocessingsystem
Lexical
analyser
Syntax
analyser
Semantic
analyser
Prettyprinter
Abstract
syntax tree
Grammar
definition
Optimizer
Editor
Symbol
table
Output
definition
Code
generator
Repository
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide40
Referencearchitectures
Referencemodelsarederivedfromastudyofthe
applicationdomainratherthanfromexisting
systems
Maybeusedasabasisforsystemimplementation
ortocomparedifferentsystems.Itactsasa
standardagainstwhichsystemscanbeevaluated
OSImodelisalayeredmodelforcommunication
systems
IanSommerville2000
SoftwareEngineering,6thedition.Chapter10
Slide41
OSIreferencemodel
7
Application
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Data link
Data link
Data link
Physical
Physical
Physical
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