SLIDE 1
Cornell ¡University
Compu1ng ¡and ¡Informa1on ¡Science
CS ¡5150 ¡So(ware ¡Engineering ¡ Three ¡Popular ¡Architectural ¡Styles ¡
William ¡Y. ¡Arms
SLIDE 2 Examples
- ¡ ¡ ¡ ¡Electricity ¡uAlity ¡customer ¡billing ¡(e.g., ¡NYSEG)
- ¡ ¡ ¡ ¡Telephone ¡call ¡recording ¡and ¡billing ¡(e.g., ¡Verizon)
- ¡ ¡ ¡ ¡Car ¡rental ¡reservaAons ¡(e.g., ¡Hertz)
- ¡ ¡ ¡ ¡Stock ¡market ¡brokerage ¡(e.g., ¡Charles ¡Schwab)
- ¡ ¡ ¡ ¡E-‑commerce ¡(e.g., ¡Amazon.com)
- ¡ ¡ ¡ ¡University ¡grade ¡registraAon ¡(e.g., ¡Cornell)
System ¡Design ¡Study ¡1 ¡
Master ¡File ¡Update
SLIDE 3 Example: ¡Electricity ¡U1lity ¡Billing Requirements ¡analysis ¡idenAfies ¡several ¡transacAon ¡types:
- ¡ ¡ ¡ ¡Create ¡account ¡/ ¡close ¡account
- ¡ ¡ ¡ ¡Meter ¡reading
- ¡ ¡ ¡ ¡Payment ¡received
- ¡ ¡ ¡ ¡Other ¡credits ¡/ ¡debits
- ¡ ¡ ¡ ¡Check ¡cleared ¡/ ¡check ¡bounced
- ¡ ¡ ¡ ¡Account ¡query
- ¡ ¡ ¡ ¡CorrecAon ¡of ¡error
- ¡ ¡ ¡ ¡etc., ¡etc., ¡etc.,
Master ¡File ¡Update
SLIDE 4
First ¡Attempt
Data ¡input Master ¡file TransacAon Bill Each ¡transacAon ¡is ¡handled ¡as ¡it ¡arrives.
SLIDE 5 CriAcisms ¡of ¡First ¡A[empt
Where ¡is ¡this ¡first ¡a@empt ¡weak?
- All ¡acAviAes ¡are ¡triggered ¡by ¡a ¡transacAon
- A ¡bill ¡is ¡sent ¡out ¡for ¡each ¡transacAon, ¡even ¡if ¡there ¡are ¡several ¡
per ¡day
- Bills ¡are ¡not ¡sent ¡out ¡on ¡a ¡monthly ¡cycle ¡
- Awkward ¡to ¡answer ¡customer ¡queries ¡
- No ¡process ¡for ¡error ¡checking ¡and ¡correc1on
- Inefficient ¡in ¡staff ¡Ame
SLIDE 6
Batch ¡Processing: ¡Edit ¡and ¡ValidaAon
Data ¡input Master ¡file Edit ¡& ¡ validaAon read ¡only errors Batches ¡of ¡ validated ¡ transacAons Batches ¡of ¡ incoming ¡ transacAons
SLIDE 7
Deployment ¡Diagram: ¡ValidaAon
MasterFile ¡ Check EditCheck ValidData DataInput RawData
SLIDE 8
¡Batch ¡Processing: ¡Master ¡File ¡Update
Master ¡file update Bills Validated ¡ transacAons in ¡batches Sort ¡by ¡ account errors Reports Batches ¡of ¡ input ¡data Checkpoints ¡and ¡ audit ¡trail
SLIDE 9 Benefits ¡of ¡Batch ¡Processing ¡with ¡Master ¡File ¡Update
- All ¡transacAons ¡for ¡an ¡account ¡are ¡processed ¡together ¡at ¡
appropriate ¡intervals, ¡e.g., ¡monthly
- Backup ¡and ¡recovery ¡have ¡fixed ¡checkpoints
- Be[er ¡management ¡control ¡of ¡operaAons
- Efficient ¡use ¡of ¡staff ¡and ¡hardware
- Error ¡detecAon ¡and ¡correcAon ¡is ¡simplified
SLIDE 10
Architectural ¡Style: ¡Master ¡File ¡Update ¡(Basic ¡Version)
Master ¡file ¡ update Data ¡input ¡and ¡ validaAon Mailing ¡and ¡ reports Advantages: ¡ ¡ ¡ Efficient ¡way ¡to ¡process ¡batches ¡of ¡transacAons. Disadvantages: ¡ ¡ ¡ InformaAon ¡in ¡master ¡file ¡is ¡not ¡updated ¡immediately. ¡ ¡No ¡good ¡way ¡to ¡ answer ¡customer ¡inquiries. Example: ¡billing ¡system ¡for ¡electric ¡uAlity Sort
SLIDE 11
Online ¡Inquiry
Master ¡file read ¡only Customer ¡service ¡ RepresentaAve Customer ¡service ¡department ¡can ¡read ¡the ¡master ¡file, ¡make ¡annotaAons, ¡ and ¡create ¡transacAons, ¡but ¡cannot ¡change ¡the ¡master ¡file. New ¡ transacAon A ¡customer ¡calls ¡the ¡uAlity ¡and ¡speaks ¡to ¡a ¡customer ¡service ¡representaAve. ¡
SLIDE 12
Online ¡Inquiry: ¡Use ¡Case
CustomerRep AnswerCustomer NewTransacAon <<uses>> The ¡representaAve ¡can ¡read ¡the ¡master ¡file, ¡but ¡not ¡make ¡changes ¡ to ¡it. ¡ ¡ If ¡the ¡representaAve ¡wishes ¡to ¡change ¡informaAon ¡in ¡the ¡master ¡file, ¡ a ¡new ¡transacAon ¡is ¡created ¡as ¡input ¡to ¡the ¡master ¡file ¡update ¡ system.
SLIDE 13
Architectural ¡Style: ¡Master ¡File ¡Update ¡(Full)
Advantage: ¡ ¡ ¡ Efficient ¡way ¡to ¡answer ¡customer ¡inquiries. Disadvantage: ¡ ¡ ¡ InformaAon ¡in ¡master ¡file ¡is ¡not ¡updated ¡immediately. Example: ¡billing ¡system ¡for ¡electric ¡uAlity Customer ¡ services Master ¡file ¡ update Data ¡input ¡and ¡ validaAon Mailing ¡and ¡ reports Sort
SLIDE 14 Real ¡Time ¡TransacAons
Example: ¡A ¡small ¡bank
- ¡ TransacAons ¡are ¡received ¡by ¡customer ¡in ¡person, ¡over ¡the ¡
Internet, ¡by ¡mail ¡or ¡by ¡telephone.
- ¡ Some ¡transacAons ¡must ¡be ¡processed ¡immediately ¡(e.g., ¡
cash ¡withdrawal), ¡others ¡are ¡suitable ¡for ¡overnight ¡ processing ¡(e.g., ¡check ¡clearing). ¡
- ¡ ¡ ¡ ¡Complex ¡customer ¡inquiries.
- ¡ ¡ ¡ ¡Highly ¡compeAAve ¡market.
SLIDE 15
Real-‑Ame ¡TransacAons ¡& ¡Batch ¡Processing
Customer ¡& ¡account ¡ database Real-‑Ame ¡ transacAons Batch ¡data ¡ input This ¡is ¡a ¡combinaAon ¡of ¡the ¡ Repository ¡style ¡and ¡the ¡Master ¡ File ¡Update ¡style
SLIDE 16 PracAcal ¡ConsideraAon
- Can ¡real-‑Ame ¡service ¡during ¡scheduled ¡hours ¡be ¡combined ¡with ¡
batch ¡processing ¡overnight?
- How ¡will ¡the ¡system ¡guarantee ¡database ¡consistency ¡a(er ¡any ¡type ¡of ¡
failure? ¡ ¡ ¡ ¡ ¡ ¡ ¡reload ¡from ¡checkpoint ¡+ ¡log ¡ ¡ ¡ ¡ ¡ ¡ ¡detailed ¡audit ¡trail
- How ¡will ¡transac1on ¡errors ¡be ¡avoided ¡and ¡idenAfied?
- How ¡will ¡transac1on ¡errors ¡be ¡corrected?
- How ¡will ¡staff ¡dishonesty ¡be ¡controlled?
These ¡pracAcal ¡consideraAons ¡may ¡be ¡major ¡factors ¡in ¡the ¡choice ¡of ¡ architecture.
SLIDE 17 Many ¡data ¡intensive ¡systems, ¡e.g., ¡those ¡used ¡by ¡banks, ¡universiAes, ¡etc. ¡ are ¡legacy ¡systems. ¡ ¡They ¡may ¡have ¡been ¡developed ¡forty ¡years ¡ago ¡as ¡ batch ¡processing, ¡master ¡file ¡update ¡systems ¡and ¡been ¡conAnually ¡
- modified. ¡ ¡
- ¡ Recent ¡modificaAons ¡might ¡include ¡customer ¡interfaces ¡for ¡the ¡web, ¡
smartphones, ¡etc.
- ¡ The ¡systems ¡will ¡have ¡migrated ¡from ¡computer ¡to ¡computer, ¡across ¡
- peraAng ¡systems, ¡to ¡different ¡database ¡systems, ¡etc.
- ¡ The ¡organizaAons ¡may ¡have ¡changed ¡through ¡mergers, ¡etc.
Maintaining ¡a ¡coherent ¡system ¡architecture ¡for ¡such ¡legacy ¡systems ¡is ¡an ¡ enormous ¡challenge, ¡yet ¡the ¡complexity ¡of ¡building ¡new ¡systems ¡is ¡so ¡ great ¡that ¡it ¡is ¡rarely ¡a[empted.
Legacy ¡Systems
SLIDE 18 System ¡Design ¡Study ¡2
Three ¡Tier ¡Architecture
The ¡basic ¡client/server ¡architecture ¡of ¡the ¡web ¡has: ¡
- ¡ a ¡server ¡that ¡delivers ¡staAc ¡pages ¡in ¡HTML ¡format ¡
- ¡ a ¡client ¡(known ¡as ¡a ¡browser) ¡that ¡renders ¡HTML ¡pages ¡
Both ¡server ¡and ¡client ¡implement ¡the ¡HTTP ¡interface. ¡ Problem ¡ Extend ¡the ¡architecture ¡of ¡the ¡server ¡so ¡that ¡it ¡can ¡configure ¡ HTML ¡pages ¡dynamically.
SLIDE 19
Web ¡Server ¡with ¡Data ¡Store
Web ¡browser Advantage: ¡ ¡ ¡ Server-‑side ¡code ¡can ¡configure ¡pages, ¡access ¡data, ¡validate ¡ informaAon, ¡etc. ¡ Disadvantage: ¡ ¡ ¡ All ¡interacAon ¡requires ¡communicaAon ¡ ¡with ¡ ¡server Data Server
SLIDE 20
Architectural ¡Style: ¡Three ¡Tier ¡Architecture
Each ¡of ¡the ¡tiers ¡can ¡be ¡replaced ¡by ¡other ¡components ¡that ¡ implement ¡the ¡same ¡interfaces Presentation ¡ tier ¡ Application ¡ tier Database ¡ tier
SLIDE 21
Component ¡Diagram
WebServer WebBrowser HTTP ODBC Database ¡ Server These ¡components ¡might ¡be ¡ located ¡on ¡a ¡single ¡node
SLIDE 22
Three ¡Tier ¡Architecture: ¡Broadcast ¡Searching
User ¡interface ¡ service User Databases This ¡is ¡an ¡example ¡of ¡a ¡multicast ¡protocol. The ¡primary ¡difficulty ¡is ¡to ¡avoid ¡troubles ¡at ¡one ¡site ¡ degrading ¡the ¡entire ¡system ¡(e.g., ¡every ¡transaction ¡ cannot ¡wait ¡for ¡a ¡system ¡to ¡time ¡out).
SLIDE 23 Extending ¡the ¡Architecture ¡of ¡the ¡Web
Using ¡a ¡three ¡Aer ¡architecture, ¡the ¡web ¡has: ¡
- ¡ a ¡server ¡that ¡delivers ¡dynamic ¡pages ¡in ¡HTML ¡format ¡
- ¡ a ¡client ¡(known ¡as ¡a ¡browser) ¡that ¡renders ¡HTML ¡pages ¡
Both ¡server ¡and ¡client ¡implement ¡the ¡HTTP ¡interface. ¡ Problem ¡2 ¡ Every ¡interacAon ¡with ¡the ¡user ¡requires ¡communicaAon ¡between ¡the ¡ client ¡and ¡the ¡server. ¡ Extend ¡the ¡architecture ¡so ¡that ¡simple ¡user ¡interacAons ¡do ¡not ¡need ¡ ¡ messages ¡to ¡be ¡passed ¡between ¡the ¡client ¡and ¡the ¡server.
SLIDE 24
Extending ¡the ¡Web ¡with ¡Executable ¡Code ¡that ¡can ¡be ¡Downloaded
Data ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Server Web ¡browser Executable ¡code ¡in ¡a ¡scripAng ¡language ¡such ¡as ¡JavaScript ¡can ¡be ¡ downloaded ¡from ¡the ¡server ¡ ¡ Advantage: ¡ Scripts ¡can ¡interact ¡with ¡user ¡and ¡process ¡informaAon ¡locally ¡ Disadvantage: ¡ ¡ All ¡interacAons ¡are ¡constrained ¡by ¡web ¡protocols Java ¡ Script html
SLIDE 25
Web ¡Browser ¡with ¡JavaScript
HTTP JavaScript HTMLRender In ¡this ¡example, ¡each ¡ package ¡represents ¡a ¡ related ¡set ¡of ¡classes. Web ¡Browser
SLIDE 26 Extending ¡the ¡Architecture ¡of ¡the ¡Web
Using ¡a ¡three ¡Aer ¡architecture ¡with ¡downloadable ¡scripts, ¡the ¡web ¡ has: ¡
- ¡ a ¡server ¡that ¡delivers ¡dynamic ¡pages ¡in ¡HTML ¡format ¡
- ¡ a ¡client ¡(known ¡as ¡a ¡browser) ¡that ¡renders ¡HTML ¡pages ¡and ¡
executes ¡scripts ¡ Both ¡server ¡and ¡client ¡implement ¡the ¡HTTP ¡interface. ¡ Problem ¡3 ¡ Every ¡interacAon ¡between ¡the ¡client ¡and ¡a ¡server ¡uses ¡the ¡HTTP ¡
Extend ¡the ¡architecture ¡so ¡that ¡other ¡protocols ¡can ¡be ¡used.
SLIDE 27 Web ¡User ¡Interface: ¡Applet
Any ¡ ¡ server ¡ ¡Web ¡server Web ¡browser
- ¡ ¡ ¡ ¡Any ¡executable ¡code ¡can ¡run ¡on ¡client ¡
- ¡ ¡ ¡ ¡Client ¡can ¡connect ¡to ¡any ¡server ¡
- ¡ ¡ ¡ ¡FuncAons ¡are ¡constrained ¡by ¡capabiliAes ¡of ¡browser
Applets
SLIDE 28
Applet ¡Interfaces
WebBrowser WebServer HTTP XYZServer XYZInterface
SLIDE 29
Extending ¡the ¡Architecture ¡of ¡the ¡Web
These ¡examples ¡(three ¡Aer ¡architecture, ¡downloadable ¡scripts, ¡and ¡ applets) ¡are ¡just ¡some ¡of ¡the ¡ways ¡in ¡which ¡the ¡basic ¡architecture ¡has ¡ been ¡extended. ¡ ¡Here ¡are ¡some ¡more: ¡ Protocols: ¡ ¡ HTTP, ¡FTP, ¡etc., ¡proxies ¡ Data ¡types: ¡ ¡ ¡ helper ¡applicaAons, ¡plug-‑ins, ¡etc. ¡ Executable ¡code: ¡ ¡ Server-‑side ¡code, ¡e.g., ¡servlets, ¡CGI ¡ Style ¡sheets: ¡ ¡ CSS, ¡etc.
SLIDE 30
System ¡Design ¡Study ¡3 ¡ Model/View/Controller ¡for ¡Mobile ¡Apps
Model View Controller State ¡ ¡ query State ¡ ¡ change View ¡control
SLIDE 31 Model
The ¡model ¡records ¡the ¡state ¡of ¡the ¡applicaAon ¡and ¡noAfies ¡
- subscribers. ¡ ¡It ¡does ¡not ¡depend ¡on ¡the ¡controller ¡or ¡the ¡view. ¡
- stores ¡the ¡state ¡of ¡the ¡applicaAon ¡in ¡suitable ¡data ¡structures ¡or ¡
databases ¡
- responds ¡to ¡instrucAons ¡to ¡change ¡the ¡state ¡informaAon ¡
- noAfies ¡subscribers ¡of ¡events ¡that ¡change ¡the ¡state ¡
- may ¡be ¡responsible ¡for ¡validaAon ¡of ¡informaAon ¡
SLIDE 32 View
The ¡view ¡is ¡the ¡part ¡of ¡the ¡user ¡interface ¡that ¡presents ¡the ¡state ¡of ¡ the ¡interface ¡to ¡the ¡user. ¡ ¡It ¡subscribes ¡to ¡the ¡model, ¡which ¡noAfies ¡it ¡
- f ¡events ¡that ¡change ¡the ¡state. ¡
- renders ¡data ¡from ¡the ¡model ¡for ¡the ¡user ¡interface ¡
- provides ¡editors ¡for ¡properAes, ¡such ¡as ¡text ¡fields, ¡etc. ¡
- receives ¡updates ¡from ¡the ¡model ¡
- sends ¡user ¡input ¡to ¡the ¡controller ¡
A ¡given ¡model ¡may ¡support ¡a ¡choice ¡of ¡alternaAve ¡views. ¡
SLIDE 33 Controller
The ¡controller ¡is ¡the ¡part ¡of ¡the ¡user ¡interface ¡that ¡manages ¡user ¡ input ¡and ¡navigaAon ¡within ¡the ¡applicaAon. ¡ ¡
- defines ¡the ¡applicaAon ¡behavior ¡ ¡
- maps ¡user ¡acAons ¡to ¡changes ¡in ¡the ¡state ¡of ¡the ¡model ¡
- interacts ¡with ¡external ¡services ¡via ¡APIs ¡
- may ¡be ¡responsible ¡for ¡validaAon ¡of ¡informaAon ¡
Different ¡frameworks ¡handle ¡controllers ¡in ¡different ¡ways. ¡In ¡ parAcular ¡there ¡are ¡several ¡ways ¡to ¡divide ¡responsibiliAes ¡between ¡ the ¡model ¡and ¡the ¡controller, ¡e.g., ¡data ¡validaAon, ¡external ¡APIs. ¡
SLIDE 34
External ¡Services ¡for ¡Mobile ¡Apps
Model View Controller State ¡ ¡ query State ¡ ¡ change View ¡control External ¡ services Mobile ¡apps ¡o(en ¡make ¡extensive ¡use ¡of ¡cloud-‑based ¡external ¡services, ¡ each ¡with ¡an ¡API ¡(e.g., ¡locaAon, ¡validaAon). ¡ ¡These ¡are ¡usually ¡managed ¡ by ¡the ¡controller.
SLIDE 35
Other ¡Uses ¡of ¡Model/View/Controller
Model Controller View Example: ¡Control ¡of ¡a ¡unmanned ¡model ¡aircra( Controller: ¡ ¡Receives ¡instrument ¡readings ¡from ¡the ¡aircra( ¡and ¡sends ¡controls ¡ signals ¡to ¡the ¡aircra(. Model: ¡ ¡Translates ¡data ¡received ¡from ¡and ¡sent ¡to ¡the ¡aircra(, ¡and ¡instrucAons ¡ from ¡the ¡user ¡into ¡a ¡model ¡of ¡flight ¡performance. ¡ ¡Uses ¡domain ¡knowledge ¡ about ¡the ¡aircra( ¡and ¡flight. View: ¡ ¡Displays ¡informaAon ¡about ¡the ¡aircra( ¡to ¡the ¡user ¡on ¡the ¡ground ¡and ¡ transmits ¡instrucAons ¡to ¡the ¡model.
SLIDE 36 Architectural ¡Styles ¡and ¡Design ¡Pa[erns
There ¡are ¡many ¡variants ¡of ¡the ¡common ¡architectural ¡styles. ¡ ¡Do ¡not ¡be ¡ surprised ¡if ¡you ¡encounter ¡a ¡variant ¡that ¡is ¡different ¡from ¡the ¡one ¡described ¡ in ¡this ¡course. ¡ This ¡is ¡parAcularly ¡true ¡with ¡the ¡Model-‑View-‑Controller ¡style. ¡ ¡Several ¡ programming ¡frameworks ¡call ¡classes ¡that ¡implement ¡a ¡variant ¡of ¡the ¡ Model-‑View-‑Controller ¡architectural ¡style ¡a ¡design ¡pa[ern. ¡ In ¡this ¡course ¡we ¡disAnguish ¡carefully ¡between ¡architectural ¡styles ¡and ¡ design ¡pa[erns. ¡ Architectural ¡styles ¡are ¡part ¡of ¡system ¡design. ¡ ¡They ¡are ¡defined ¡in ¡terms ¡
- f ¡subsystems, ¡components, ¡and ¡deployment. ¡
Design ¡pa[erns ¡are ¡part ¡of ¡program ¡design. ¡ ¡They ¡are ¡defined ¡in ¡terms ¡
¡