CS 5150 So(ware Engineering Three Popular Architectural - - PowerPoint PPT Presentation

cs 5150 so ware engineering three popular architectural
SMART_READER_LITE
LIVE PREVIEW

CS 5150 So(ware Engineering Three Popular Architectural - - PowerPoint PPT Presentation

Cornell University Compu1ng and Informa1on Science CS 5150 So(ware Engineering Three Popular Architectural Styles William Y. Arms System Design Study 1 Master


slide-1
SLIDE 1

Cornell ¡University
 Compu1ng ¡and ¡Informa1on ¡Science

CS ¡5150 ¡So(ware ¡Engineering ¡ Three ¡Popular ¡Architectural ¡Styles ¡

William ¡Y. ¡Arms

slide-2
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
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
SLIDE 4

First ¡Attempt

Data ¡input Master ¡file TransacAon Bill Each ¡transacAon ¡is ¡handled ¡as ¡it ¡arrives.

slide-5
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
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
SLIDE 7

Deployment ¡Diagram: ¡ValidaAon

MasterFile ¡ Check EditCheck ValidData DataInput RawData

slide-8
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
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
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
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
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
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
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
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
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
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
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
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
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
SLIDE 21

Component ¡Diagram

WebServer WebBrowser HTTP ODBC Database ¡ Server These ¡components ¡might ¡be ¡ located ¡on ¡a ¡single ¡node

slide-22
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
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
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
SLIDE 25

Web ¡Browser ¡with ¡JavaScript

HTTP JavaScript HTMLRender In ¡this ¡example, ¡each ¡ package ¡represents ¡a ¡ related ¡set ¡of ¡classes. Web ¡Browser

slide-26
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 ¡

  • protocol. ¡

Extend ¡the ¡architecture ¡so ¡that ¡other ¡protocols ¡can ¡be ¡used.

slide-27
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
SLIDE 28

Applet ¡Interfaces

WebBrowser WebServer HTTP XYZServer XYZInterface

slide-29
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
SLIDE 30

System ¡Design ¡Study ¡3 ¡ Model/View/Controller ¡for ¡Mobile ¡Apps

Model View Controller State ¡ ¡ query State ¡ ¡ change View ¡control

slide-31
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
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
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
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
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
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 ¡

  • f ¡classes. ¡

¡