SLIDE 1 Cornell University Compu1ng and Informa1on Science
CS 5150 So(ware Engineering
- 13. Three Popular Architectural Styles
William Y. Arms
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
A Very Basic Web Site
WebBrowser WebServer HTTP dependency interface realiza.on This very basic web system has a client/server architecture.
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 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
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
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
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
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
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 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 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 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
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 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 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 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
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 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
Model/View/Controller as a System Architecture
Model View Controller State query State change View control External services
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
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 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 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 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 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 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
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 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 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
SLIDE 31 Cornell University Compu1ng and Informa1on Science
CS 5150 So(ware Engineering
- 13. Three Popular Architectural Styles
End of Lecture