47
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

  • View
    217

  • Download
    0

Embed Size (px)

Citation preview

Page 1: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

1 CS 501 Spring 2007

CS 501: Software Engineering

Lecture 13

System Architecture and Design I

Page 2: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

2 CS 501 Spring 2007

Administration

Quizzes

There are 4 quizzes, each with 2 questions. The final grade will be based on the best 6 questions out of 8.

Uncollected answer books are at 301 College Avenue.

Average grades:

Quiz 1 Q1 Quiz 1, Q2 Quiz 2 Q1 Quiz 2 Q2

8.4 5.8 7.2 7.0

Page 3: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

3 CS 501 Spring 2007

Quiz 2, Question 2

The Pizza Ordering System

The system allows the user of a cellular telephone with a Web browser to order pizza for home delivery. To place an order, a user searches to find items to purchase, adds items one at a time to a shopping cart, and possibly searches again for more items. When all items have been chosen, the user provides a delivery address, and may provide credit card information if not planning to pay with cash.

Page 4: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

4 CS 501 Spring 2007

Quiz 2, Question 2

The following diagram illustrates various factors that, in combination, determine the usability of a computer system.

interface design

functional design

data and metadata

computer systems and networks

mentalmodel

Page 5: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

5 CS 501 Spring 2007

Quiz 2, Question 2

(a) What is the mental model for the Pizza Ordering System?

Page 6: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

6 CS 501 Spring 2007

Quiz 2, Question 2

(a) What is the mental model for the Pizza Ordering System?

A shopping model: select items from menu, add to shopping cart, check out, credit card payment.

Page 7: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

7 CS 501 Spring 2007

Quiz 2, Question 2

(b) In this system the cellular phone is being used as a small computer. How do the usability characteristics of this computer and the network over which it operates constrain the design of this system? List three characteristics and the constraints that they place on the system.

Page 8: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

8 CS 501 Spring 2007

Quiz 2, Question 2

(b) In this system the cellular phone is being used as a small computer. How do the usability characteristics of this computer and the network over which it operates constrain the design of this system? List three characteristics and the constraints that they place on the system.

• small screen size -- difficult to display graphics

• restricted keyboard -- input tedious, no mouse

• slow network connection -- slow response, limited information

• etc.

Page 9: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

9 CS 501 Spring 2007

Quiz 2, Question 2

(c) List two important functions that the interface must support?

Page 10: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

10 CS 501 Spring 2007

Quiz 2, Question 2

(c) List two important functions that the interface must support?

• Select a type of pizza with toppings

• Input delivery address

Page 11: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

11 CS 501 Spring 2007

Quiz 2 Question 2

(d) Choose one important function and describe a possible interface design for this part of the system. State which function this part of the interface supports, how it relates to the conceptual model, and how your interface deals with the constraints that you listed in part (b).

Page 12: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

12 CS 501 Spring 2007

Quiz 2, Question 2

(d) Answer

Select a type of pizza with toppings.

Types of pizza are displayed as a scrollable text list. Each has a number. User selects by keying the number. If the pizza has options, they are displayed as a second text list.

Constraints: Consistent with small display, simple numeric input, little data to transmit.

Conceptual model: Similar to choosing from a food menu.

Page 13: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

13 CS 501 Spring 2007

System Architecture and Design

The overall design of a system:

• Computers and networks (e.g., monolithic, distributed)

• Interfaces and protocols (e.g., http, ODBC)

• Databases (e.g., relational, distributed)

• Security (e.g., smart card authentication)

• Operations (e.g., backup, archiving, audit trails)

• Software environments (e.g., languages, source control tools)

Page 14: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

14 CS 501 Spring 2007

UML: System and Subsystem Modeling

Subsystem model

A grouping of elements that specifies what a part of a system should do.

Component (UML definition)

"A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system."

A component can be thought of as an implementation of a subsystem.

Page 15: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

15 CS 501 Spring 2007

UML Notation: Component & Node

orderform.java

A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.

Server

A node is a physical element that exists at run time and represents a computational resource, e.g., a computer.

Page 16: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

16 CS 501 Spring 2007

Components and Replaceability

Components allow system to be assembled from binary replaceable elements.

• A component is physical -- bits not concepts

• A component can be replaced by any other component(s) that conforms to the interfaces.

• A component is part of a system.

• A component provides the realization of a set of interfaces.

Page 17: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

17 CS 501 Spring 2007

System Architecture Example:Extensibility in Web Browsers

Web browsers provide a flexible user interface through an extensible architecture.

Protocols:HTTP, WAIS, Gopher, FTP, etc., proxies

Data types: helper applications, plug-ins, etc.

Executable code:CGI scripts at serverJavaScript at clientJava applets

Style sheets:

CSS, etc.

Page 18: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

18 CS 501 Spring 2007

Web Interface: Basic

Web serverWeb browser

• Static pages from server

• All interaction requires communication with server

Page 19: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

19 CS 501 Spring 2007

UML Notation: Deployment Diagram

WebBrowser

PersonalComp

WebServer

DeptServer

Page 20: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

20 CS 501 Spring 2007

UML Notation:Application Programming Interface (API)

API is an interface that is realized by one or more components.

WebServer

Get Post

Page 21: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

21 CS 501 Spring 2007

UML Notation: Interfaces

WebBrowser WebServer

HTTP

dependency

interface

realization

Page 22: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

22 CS 501 Spring 2007

Web User Interface: CGI Script

Web browser

• Scripts can configure pages

• Scripts can validate information

• All interaction requires communication with server

Data

CGIScripts

Web server

Page 23: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

23 CS 501 Spring 2007

UML Notation: CGI Interface Diagram

CGIScript

HTTP

Apache

CGI

ODBC

MySQL

These components might be located on a single node.

Page 24: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

24 CS 501 Spring 2007

Web User Interface: JavaScript

Data

CGIScripts

Web server

Web browser

• JavaScripts can validate information as typed

• Some interactions are local

• Server interaction constrained by web protocols

JavaScript

html

Page 25: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

25 CS 501 Spring 2007

UML Notation: Package

A package is a general-purpose mechanism for organizing elements into groups.

Note: Some authors draw packages with a different shaped box:

JavaScript

JavaScript

Page 26: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

26 CS 501 Spring 2007

Example: Web Browser

HTTP

JavaScript

HTMLRenderEach package represents a group of objects.

WebBrowser

Page 27: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

27 CS 501 Spring 2007

Web User Interface: Applet

Any server

Web serversWeb browser

• Any executable code can run on client

• Client can connect to any server

Applets

Page 28: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

28 CS 501 Spring 2007

Applet Interfaces

WebBrowser WebServer

HTTP

XYZServer

XYZInterface

Page 29: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

29 CS 501 Spring 2007

UML Diagrams and Specifications

For every subsystem, there is a choice of diagrams

Choose the diagrams that best model the system and are clearest to everybody.

In UML every diagram must have supporting specification

The diagrams shows the relationships among parts of the system, but much, much more detail is needed to specify a system explicitly.

For example, in the Applet Interface slide, at the very least, the specification should include the version of the protocols to be supported at the interfaces, the options (if any), and implementation restrictions.

Page 30: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

30 CS 501 Spring 2007

Components and Classes

Classes represent logical abstractions. They may be grouped into packages.

Components represent physical things. They may live on nodes.

Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.

Page 31: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

31 CS 501 Spring 2007

System Design: Data Intensive Systems

Examples

• Electricity utility customer billing (e.g., NYSEG)

• Telephone call recording and billing (e.g., Verizon)

• Car rental reservations (e.g., Hertz)

• Stock market brokerage (e.g., Charles Schwab)

• E-commerce (e.g., Amazon.com)

• University grade registration (e.g., Cornell)

Page 32: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

32 CS 501 Spring 2007

Example: Electricity Utility Billing Transaction Types

Requirements analysis has identified several transaction types:

• Create account / close account

• Meter reading

• Payment received

• Other credits / debits

• Check cleared / check bounced

• Account query

• Correction of error

• etc., etc., etc.,

Page 33: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

33 CS 501 Spring 2007

Batch Processing DesignExample: Electricity Utility Billing

First attempt:

Data input Master fileTransaction Bill

Each transaction is handled as it arrives.

Page 34: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

34 CS 501 Spring 2007

Criticisms of First Attempt

Where is this first attempt weak?

• A bill is sent out for each transaction, 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 correction

• All activities are triggered by a transaction

Page 35: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

35 CS 501 Spring 2007

Batch Processing: Validation

Data input

Master file

Edit & validation

read only

errors

Batches of validated transactions

Batches of incoming transactions

Page 36: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

36 CS 501 Spring 2007

UML Deployment Diagram:Batch Processing Validation

MasterFile

EditCheck

ValidData

DataInput

RawData

Page 37: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

37 CS 501 Spring 2007

Batch Processing: Master File Update

Master fileupdate

Bills

Validated transactionsin batches

Sort by account

errors Reports

Instructions

Page 38: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

38 CS 501 Spring 2007

Interfaces to DataInput

DataInput

RawData

EditCheckErrorUpdateError

DataforCheck

Page 39: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

39 CS 501 Spring 2007

Benefits of Batch Updating

• All transactions for an account are processed together at appropriate intervals

• Backup and recovery have fixed checkpoints

• Better management control of operations

• Efficient use of staff and hardware

Page 40: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

40 CS 501 Spring 2007

Online Inquiry

Master file

read only

Customer Service

Customer Service department can read file, make annotations, and create transactions, but cannot change the master file.

New transaction

Page 41: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

41 CS 501 Spring 2007

Online Inquiry: Use Cases

CustomerServer

AnswerCustomer

NewTransaction

<<uses>>

Page 42: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

42 CS 501 Spring 2007

Data Intensive SystemsExample: A Small-town Stockbroker

• Transactions

Received by mail or over telephone

For immediate or later action

• Complex customer inquiries

• Highly competitive market

Page 43: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

43 CS 501 Spring 2007

A Database Architecture

Databases:

• Customer and account database

• Financial products (e.g., account types, pension plans, savings schemes)

• Links to external databases (e.g., stock markets, mutual funds, insurance companies)

Page 44: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

44 CS 501 Spring 2007

Real-time Transactions

Customer & account database

Products & services database

External services

Real-time transactions

Page 45: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

45 CS 501 Spring 2007

Real-time Transactions & Batch Processing

Customer & account database

Products & services database

External services

Real-time transactions

Batch processing

Data input

Page 46: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

46 CS 501 Spring 2007

Stock Broker: Interface Diagram

CustomerDBProductDB

OnLineTR BatchTR

External

Page 47: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 13 System Architecture and Design I

47 CS 501 Spring 2007

Practical considerations to include in Architecture and Specification

• Real-time service during scheduled hours with batch processing overnight

• Database consistency after any type of failure

two-phase commitreload from checkpoint + logdetailed audit trail

• How will transaction errors be avoided and identified?

• How will transaction errors be corrected?

• How will staff dishonesty be controlled?

These practical considerations may be major factors in the choice of architecture.

*