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

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

  • View
    216

  • Download
    3

Embed Size (px)

Citation preview

1 CS 501 Spring 2005

CS 501: Software Engineering

Lecture 13

System Architecture and Design I

2 CS 501 Spring 2005

Administration

BOOM

Wednesday, Duffield Atrium 4-6

3 CS 501 Spring 2005

Quiz 2

Question 1

At the end of your CS 501 project, you mount your programs and documentation on GForge. The project team gives the client an unrestricted license to use the project for the client's purposes but not to distribute it to others.

A year later, the members of your team decide to go into business, selling a product that is based on your CS 501 system. You start a small company and hire three programmers.

4 CS 501 Spring 2005

Quiz 2

(a) You would like to keep the specification of the system secret. For this purpose you remove the system from GForge. Can you claim legal protection of the specification as trade secret?

No. The presumption is that by placing it on the GForge for a year, trade secret protection was lost, unless the GForge site is securely protected and, from the very start, everybody who saw the specification was required to keep it secret.

5 CS 501 Spring 2005

Quiz 2

(b) Your company extends the system with a new component. Can you protect the specification of the new component as trade secret? If so, what procedure would you follow?

Yes, by creating procedures to keep the specification secret, e.g., by restricting access and my ensuring that everybody who has access understands the necessity of keeping it secret.

(c) Who owns the copyright in the original system? Who owns the copyright in your new component?

You own the copyright to the original system. To be more specific, the members of the project team jointly own the copyright.

The company owns the copyright to the new component.

6 CS 501 Spring 2005

Quiz 2

(d) Can you charge the CS 501 client money to use your new component?

Yes. Unless your license says otherwise.

(e) Two of your programmers leave and start their own company. What use can they make of the programs that they wrote while working for your company? Can they write new software based on the specification of your new component?

They can make no use of the programs, without permission from the company. They were created as work for hire.

They cannot write software based on this specification. The specification is a trade secret of the company. The former employees cannot use it, but they can use ideas from it.

7 CS 501 Spring 2005

System Architecture and Design

The overall design of a system:

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

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

• 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)

8 CS 501 Spring 2005

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.

9 CS 501 Spring 2005

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.

10 CS 501 Spring 2005

System Architecture Example:Extensibility in Web Browsers

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

Data types: helper applications, plug-ins

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

Executable code:CGI scripts at serverJavaScript at clientJava applets

Style sheets:

11 CS 501 Spring 2005

Web Interface: Basic

Web serverWeb browser

• Static pages from server

• All interaction requires communication with server

12 CS 501 Spring 2005

UML Notation: Deployment Diagram

WebBrowser

PersonalComp

WebServer

DeptServer

13 CS 501 Spring 2005

UML Notation:Application Programming Interface (API)

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

WebServer

Get Post

14 CS 501 Spring 2005

UML Notation: Interfaces

WebBrowser WebServer

HTTP

dependency

interface

realization

15 CS 501 Spring 2005

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

16 CS 501 Spring 2005

UML Notation: CGI Interface Diagram

CGIScript

HTTP

Apache

CGI

SQL

MySQL

These components might be located on a single node.

17 CS 501 Spring 2005

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

18 CS 501 Spring 2005

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

19 CS 501 Spring 2005

Example: Web Browser

HTTP

JavaScript

HTMLRenderEach package represents a group of objects.

WebBrowser

20 CS 501 Spring 2005

Web User Interface: Applet

Any server

Web serversWeb browser

• Any executable code can run on client

• Client can connect to any server

Applets

21 CS 501 Spring 2005

Applet Interfaces

WebBrowser WebServer

HTTP

XYZServer

XYZInterface

22 CS 501 Spring 2005

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.

23 CS 501 Spring 2005

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.

24 CS 501 Spring 2005

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.

25 CS 501 Spring 2005

System Design: Data Intensive Systems

Examples

• Electricity utility customer billing

• Telephone company call recording and billing

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

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

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

26 CS 501 Spring 2005

Batch ProcessingExample: Electricity Utility Billing

First attempt:

Data input Master fileTransaction Bill

Each transaction is handled as it arrives.

27 CS 501 Spring 2005

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.,

28 CS 501 Spring 2005

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

• No way to answer customer queries

• No process for error checking and correction

• All activities are triggered by a transaction

29 CS 501 Spring 2005

Batch Processing: Validation

Data input

Master file

Edit & validation

read only

errors

Batches of validated transactions

Batches of incoming transactions

30 CS 501 Spring 2005

UML Deployment Diagram:Batch Processing Validation

MasterFile

EditCheck

ValidData

DataInput

RawData

31 CS 501 Spring 2005

Batch Processing: Master File Update

Master fileupdate

Bills

Validated transactionsin batches

Sort by account

errors Reports

Instructions

32 CS 501 Spring 2005

Interfaces to DataInput

DataInput

RawData

EditCheckErrorUpdateError

DataforCheck

33 CS 501 Spring 2005

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

34 CS 501 Spring 2005

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

35 CS 501 Spring 2005

Online Inquiry: Use Cases

CustomerServer

AnswerCustomer

NewTransaction

<<uses>>

36 CS 501 Spring 2005

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

37 CS 501 Spring 2005

A Database Architecture

Database(s):

• 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)

38 CS 501 Spring 2005

Real-time Transactions

Customer & account database

Products & services database

External services

Real-time transactions

39 CS 501 Spring 2005

Real-time Transactions & Batch Processing

Customer & account database

Products & services database

External services

Real-time transactions

Batch processing

Data input

40 CS 501 Spring 2005

Stock Broker: Interface Diagram

CustomerDBProductDB

OnLineTR BatchTR

41 CS 501 Spring 2005

Architectural considerations to include in Specification

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

• Combine information from several databases

• Database consistency after any type of failure

two-phase commitreload from checkpoint + logdetailed audit trail

• How will transaction errors be avoided?

• How will transaction errors be corrected?

• How will staff dishonesty be controlled?

42 CS 501 Spring 2005

Data Intensive Systems: Merger of Two Banks

Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing.

The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches.

This is an example of working with legacy systems.

43 CS 501 Spring 2005

Merger of Two Banks: Options

???

???

AA BB

44 CS 501 Spring 2005

Merger of Two Banks: Architectural Options

I. Convert everything to System A

convert databasesretrain staffenhance System A (software and

hardware)discard System B

II. Build an interface between the databases in System A and System B

III. Extend client software so that it can interact with either System A or System B database