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

cs 5150 so ware engineering 13 three popular
SMART_READER_LITE
LIVE PREVIEW

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

Cornell University Compu1ng and Informa1on Science CS 5150 So(ware Engineering 13. Three Popular Architectural Styles William Y. Arms Three Popular Architectural Styles Example 1: Three Tier Architecture This architecture is an extension of


slide-1
SLIDE 1

Cornell University Compu1ng and Informa1on Science

CS 5150 So(ware Engineering

  • 13. Three Popular Architectural Styles

William Y. Arms

slide-2
SLIDE 2

Example 1: Three Tier Architecture

Three Popular Architectural Styles

This architecture is an extension of the client/server model. It is the standard architecture for small and medium sized web sites.

slide-3
SLIDE 3

A Very Basic Web Site

WebBrowser WebServer HTTP dependency interface realiza.on This very basic web system has a client/server architecture.

slide-4
SLIDE 4

Web Server with Data Store

Web browser Advantage Server-side code can respond to user requests by accessing data, configuring pages, validaQng informaQon, etc. Data Server The basic client/server web site returns only fixed HTML pages. ARach the server to a data store, so that it can respond to requests from the client and return suitable content.

slide-5
SLIDE 5

Component Diagram

WebServer WebBrowser HTTP ODBC Database Server These components might be located on a single node Since components are replaceable binary elements:

  • Any web browser can access the web site.
  • The database server can be replaced by another database that

supports the same interface.

slide-6
SLIDE 6

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 External services

slide-7
SLIDE 7

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

Extending the Web with Executable Code that can be Downloaded

Data Server Web browser Executable code in a scripQng language such as JavaScript can be downloaded from the server. This can be done within the three Qer architecture. Java Script html

slide-9
SLIDE 9

Web Browser with JavaScript

HTTP JavaScript HTMLRender Each package contains several classes. Web Browser The Presentation Tier has become more complex. Since it still supports the same interface it is still a replaceable binary component. HTTP

slide-10
SLIDE 10

Example 2: Master File Update

Three Popular Architectural Styles

This architecture is an alternative to the repository model. It is very widely used in data processing systems.

slide-11
SLIDE 11

OrganizaQon ApplicaQon Master file TransacQons Cornell University registraQon students add/drop, record grade NYSEG uQlity billing householders pay bill, read meter Tompkins Trust banking customers deposit, withdraw

Master File Update

Characteristics

  • Many complex types of transaction, including reversals (corrections).
  • Correctness of master file is vital to the success of the organization.
  • Batch updating of master file is acceptable (e.g., overnight).
  • Must be able to answer customer queries, without waiting for full update.
slide-12
SLIDE 12

Example: Electricity U1lity Billing Requirements analysis idenQfies many transacQon types:

  • Create account / close account
  • Meter reading
  • Payment received
  • Other credits / debits
  • Check cleared / check bounced
  • Account query
  • CorrecQon of error
  • etc., etc., etc.,

Master File Update: Transactions

slide-13
SLIDE 13

Master File with Batch Processing: Dataflow Model

Master file Input and validation read only Master file update Pending transactions Output process New transactions Bills, reports, etc.

  • Input and validation process runs throughout the day. It processes

transactions when they arrive.

  • Master file update program runs once per day (usually at night).
  • Output process is run after the master file update finishes.

Checkpoints, audit trail

slide-14
SLIDE 14

Batch Processing: Input and Validation

Master file Input and validation read only Pending transactions Data input errors Paper transac.on Network transac.on read Because the input and validation process is able to read the master file, it can check that the transaction is compatible with the master file, e.g., file has a record for the customer. write

slide-15
SLIDE 15

Benefits of Batch Processing with Master File Update

Advantages:

  • Backup and recovery have fixed checkpoints.
  • BeRer management control of operaQons.
  • Efficient use of staff and hardware.
  • Error detecQon and correcQon is simplified.

Disadvantages:

  • InformaQon in master file is not updated immediately.
  • No good way to answer customer inquiries.
slide-16
SLIDE 16

Online Inquiry

Master file Input and validation Pending transactions New transac.on Customer service representaQve

  • Customer calls the organizaQon and speaks to a customer service representaQve.
  • The representaQve can read the master file and the pending file, but cannot change

them.

  • OpQonal. Customer can read selected parts of the master file and pending file

without going through customer service. read only

slide-17
SLIDE 17

Online Inquiry: Use Case

CustomerRep AnswerCustomer NewTransacQon <<includes>>

  • The representaQve can read the master file and pending file, but

not make changes to them.

  • If the representaQve wishes to change informaQon in the master

file, a new transacQon is created and sent to the input and validaQon process.

  • The representaQve can create an annotaQon, e.g., a note of a

telephone conversaQon with a customer. It is treated as a new transacQon.

slide-18
SLIDE 18

Example 3: Model/View/Controller (MVC)

Three Popular Architectural Styles

This architecture is used to control a complex user interface. It is the standard architecture for mobile apps and widely used in robotics.

slide-19
SLIDE 19

Model/View/Controller (MVC)

The definition of Model/View/Controller (MVC) is in a state of flux. The term is used to describe a range of architectures and designs.

  • Some are system architectures, where the model, view, and controller

are separate components.

  • Some are program designs, with classes called model, view, and

controller.

slide-20
SLIDE 20

Model/View/Controller as a System Architecture

Model View Controller State query State change View control External services

slide-21
SLIDE 21

Example: a Drone

The drone is a small unmanned airplane.

  • The drone is flown by a pilot who sits at a computer on the ground.
  • The drone is controlled by radio signals from the ground staQon

(e.g, changes to throRle, ailerons, flaps, etc.).

  • Sensors on the airplane send radio signals to the ground staQon

(e.g., air speed, GPS coordinates, control surface sefngs, etc.). This example is based on a CS 5150 project.

slide-22
SLIDE 22

Drone: View

The pilot sits at a computer on the ground with a user interface that represents the cockpit controls of a light airplane. This is the view. From a CS 5150 project Pilot

slide-23
SLIDE 23

Drone: Model

For the drone, the model:

  • maintains a record of the state of the drone, e.g., speed, fuel.
  • models future changes of state, e.g., rate of turn, changes of speed.
  • updates the state based on data from the controller, e.g., changes

in control sefngs.

  • updates the view with informaQon to be displayed in the user

interface. In general, a different drone will need a different model, but the view and controller are separate components and will not necessarily change.

slide-24
SLIDE 24

Drone: Controller

Scenario: The pilot wishes to change the flap sefngs to 20 degrees. This will allow slower speed for landing.

  • The view sends a message to the controller, setFlaps(20).
  • The controller sends a message to the airplane, setFlaps(20).
  • The airplane sets the flaps and sends a message to the controller,

flapsAreSet(20).

  • The controller relays the message to the model, flapsAreSet(20).
  • The model updates the state informaQon and recalculates the stall speed.
  • The model noQfies the view, flapsAreSet(20), and also the predicted change

to the stall speed.

  • The view displays the changed sefngs on the pilot’s console.
slide-25
SLIDE 25

View

The view presents the state of the interface to the user. It subscribes to the model, which noQfies it of events that change the state.

  • renders data from the model for the user interface
  • provides editors for properQes, such as text fields, etc.
  • receives updates from the model
  • sends user input to the controller

A given model may support a choice of alternaQve views. The CS 5150 project was to create a new view for the pilot. Since this was a separate component, it could replace the old view with no other changes to the system. View

slide-26
SLIDE 26

Model

The model records the state of the applicaQon and noQfies

  • subscribers. It does not depend on the controller or the view.
  • stores the state of the applicaQon in suitable data structures or

databases

  • responds to instrucQons to change the state informaQon
  • noQfies subscribers of events that change the state
  • may be responsible for validaQon of informaQon

Model

slide-27
SLIDE 27

Controller

The controller is the part of the system that manages user input and navigaQon within the applicaQon.

  • defines the applicaQon behavior
  • maps user acQons to changes in the state of the model
  • interacts with external services via APIs
  • may be responsible for validaQon of informaQon

Different frameworks handle controllers in different ways. In parQcular, there are several ways to divide responsibiliQes between the model and the controller, e.g., data validaQon, external APIs. Controller External services

slide-28
SLIDE 28

Model/View/Controller as a Program Design

Model View Controller State query State change View control External services For mobile apps, the MVC is a single component. The model, view, and controller are classes. The programs o(en use cloud-based external services, each with an API (e.g., locaQon, validaQon). These are usually managed by the controller.

slide-29
SLIDE 29

Apple’s Version of Model/View/Controller

Controller View Model User acQon NoQfy Update Update The MVC is a program design (not a system architecture).

  • The model, view, and controller are classes (not components).
  • All messages pass through the controller.
  • A multi-screen app will have several views and controllers sharing the

same model.

slide-30
SLIDE 30

Architectural Styles and Design PaRerns

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. In this course we disQnguish carefully between architectural styles and design paRerns. Architectural styles are part of system design. They are defined in terms

  • f subsystems, components, and deployment.

Design paRerns are part of program design. They are defined in terms

  • f classes.
slide-31
SLIDE 31

Cornell University Compu1ng and Informa1on Science

CS 5150 So(ware Engineering

  • 13. Three Popular Architectural Styles

End of Lecture