1 cs 501 spring 2004 cs 501: software engineering lecture 15 system architecture and design 2

1 CS 501 Spring 2004

CS 501: Software Engineering

Lecture 15

System Architecture and Design 2

2 CS 501 Spring 2004

Administration

3 CS 501 Spring 2004

Quiz 2, Question 1

You are developing the requirements for an online shopping system. To place an order, a user connects to the system, searches to find items to purchase, selects one or more items, and supplies credit card information to pay for them.

(i) Create a scenario for a user making a purchase.

A scenario should follow an individual user through a single interaction with the system.

See Lecture 8, slides 11 to 14 for a typical example.

4 CS 501 Spring 2004

Quiz 2, Question 1

(ii) Develop a use case diagram and brief specification for a use case, PlaceOrder, which is modeled on this scenario. The use case should show a relationship to a previously specified use case, Pay, which models credit card payments. (You do not need to specify the Pay use case.)

PayPlaceOrder<<includes>>

Shopper

The subject of a use case is an actor, with a generic role.

For an example of a specification, see Lecture 8 slides 26-27

5 CS 501 Spring 2004

Quiz 2, Question 1

CheckOrder

(iii) A user might interact with the online shopping system in other ways. Draw a diagram for a different use case in which the same actor interacts with the online shopping system.

Shopper

Note same actor for this different use case.

6 CS 501 Spring 2004

Coupling and Cohesion

Coupling is a measure of the dependencies between two subsystems. If two systems are strongly coupled, it is hard to modify one without modifying the other.

Cohesion is a measure of dependencies within a subsystem. If a subsystem contains many closely related functions its cohesion is high.

An ideal breakdown of a complex system into subsystems has low coupling between subsystems with high cohesion within subsystems.

7 CS 501 Spring 2004

Architectural Styles

An architectural style is system architecture that recurs in many different applications.

See: Mary Shaw and David Garlan, Software architecture: perspectives on an emerging discipline. Prentice Hall, 1996

8 CS 501 Spring 2004

Architectural Style: Repository

Repository

Input components

Transactions

Example: A digital library

Advantages: Flexible architecture for data-intensive systems.

Disadvantages: Difficult to modify repository since all other components are coupled to it.

9 CS 501 Spring 2004

Architectural Style: Repository with Storage Access Layer

Data Store

Input components

Transactions

Advantages: Data Store subsystem can be changed without modifying any component except the Storage Access.

Storage Access

This is sometimes called a "glue" layer

Repository

10 CS 501 Spring 2004

Architectural Style:Model/Controller/View

ModelController View

Example: An unmanned aircraft

Controller: Sends control signals to the aircraft and receives instrument readings.

Model: Translates data received from and sent to the aircraft into a model of flight performance. It uses domain knowledge about the aircraft and flight.

View: Displays information about the aircraft to the user.

11 CS 501 Spring 2004

Architectural Style: Client/Server

Example: the Web

Mozilla client

Apache server

The control flows in the client and the server are independent. communication between client and server follows a protocol.

In a peer-to-peer architecture, the same component acts as both a client and a server.

12 CS 501 Spring 2004

Architectural Style: Pipe

Example: A three-pass compiler

ParserLexical analysis

Code generation

Output from one subsystem is the input to the next.

13 CS 501 Spring 2004

Distributed Computing: General Problem

An application that is running on one computer wishes to use data or services provided by another:

• Network connectionprivate, public, or virtual private networklocation of firewalls

• Protocolspoint-to-point, multicast, broadcastmessage passing, RPC, distributed objectsstateful or stateless

• Performance

quality of service

14 CS 501 Spring 2004

Network Choices

Public Internet:

Ubiquitous -- worldwideLow cost

Private network:

Security / reliabilityPredictable performanceChoice of protocols (not constrained to TCP/IP)

15 CS 501 Spring 2004

Quality of Network Services

Criteria in choosing a system architecture

Performance

Maximum throughputLatencyVariations in throughputReal-time media (e.g., audio)

Business

Suppliers, costTrouble shooting and maintenance

16 CS 501 Spring 2004

Firewall

Public network

Private network

Firewall

A firewall is a computer at the junction of two network segments that:

• Inspects every packet that attempts to cross the boundary

• Rejects any packet that does not satisfy certain criteria, e.g.,

an incoming request to open a TCP connectionan unknown packet type

Firewalls provide security at a loss of flexibility and a cost of system administration.

17 CS 501 Spring 2004

Distributed Data

two copies of the same data

18 CS 501 Spring 2004

Distributed Data and Replication

Distributed Data

Data is held on several computer systems. A transaction may need to assemble data from several sources.

Replication

Several copies of the data are held in different locations.

Mirror: Complete data set is replicated

Cache: Dynamic set of data is replicated (e.g., most recently used)

With replicated data, the biggest problems are concurrency and consistency.

19 CS 501 Spring 2004

Distributed Computing: Searching

User interfaceserverUser

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

Broadcast Searching

20 CS 501 Spring 2004

Distributed Computing:Stateless Protocol v. Stateful

Stateless protocol

Example: http

Open connectionSend message Return replyClose connection

State in http must be sent with every message (e.g., as parameter string)

Cookies are a primitive way of retaining some state

21 CS 501 Spring 2004

Stateless Protocol v. Stateful

Stateful (session) protocol

Example: Z39.50

Open connectionBegin sessionInteractive sessionEnd sessionClose connection

Client and server remember the results of previous transactions (e.g., authentication, partial results) until session is closed.

22 CS 501 Spring 2004

Distributed Computing: UseNet

This is an example of an epidemic protocol. Such protocols are especially useful in networks with intermittent connectivity, e.g., mobile computing.

The biggest problem is ensuring that the data is distributed effectively.

23 CS 501 Spring 2004

Distributed Computing: The Domain Name System

.edu server

cornell.edu server

cs.cornell.edu server

First attempt to resolve www.cs.cornell.edu

1

2

3

24 CS 501 Spring 2004

Distributed Computing:The Domain Name System

.edu server

cornell.edu server

cs.cornell.edu server

Better method

3

1

almaden.ibm.comcornell.eduece.cmu.eduibm.comacm.org.edu

2

Localcache

local DNS server

25 CS 501 Spring 2004

Distributed ComputingDomain Name System

For details of the actual protocol read:

Paul Mockapetris, "Domain Names - Implementation and Specification". IETF Network Working Group, Request for Comments: 1035, November 1987.

http://www.ietf.org/rfc/rfc1035.txt?number=1035

26 CS 501 Spring 2004

Distributed Computing: Web Server

http messagedaemon

spawned processesTCP port 80

The daemon listens at port 80

When a message arrives it:spawns a processes to handle the messagereturns to listening at port 80

27 CS 501 Spring 2004

Time-Critical Systems

A real time (time-critical) system is a software system whose correct functioning depends upon the results produced and the time at which they are produced.

• A soft real time system is degraded if the results are not produced within required time constraints

• A hard real time system fails if the results are not produced within required time constraints

28 CS 501 Spring 2004

Time-Critical System: Autonomous Land Vehicle

Sensors

GPS

Sonar

Laser

Signal processing

Model Control signals

Steer

Throttle

Controls

29 CS 501 Spring 2004

Time-Critical System:CD Controller

Input block Output

block

12

345

67

Circular buffer

30 CS 501 Spring 2004

Software Considerations of System Architectures

In some types of system architecture, non-functional requirements of the system may dictate the software design and development process.

31 CS 501 Spring 2004

Time-Critical System: Routers and Other Network Computing

• Interoperation with third party devices

• Support for several versions of protocols

• Restart after total failure

• Defensive programming -- must survive

=> erroneous or malicious messages

=> extreme loads

• Time outs, dropped packets, etc.

• Evolution of network systems

32 CS 501 Spring 2004

Time-Critical System: Software Development

Developers of advanced time-critical software spend almost all their effort developing the software environment:

• Monitoring and testing -- debuggers

• Crash restart -- component and system-wide

• Downloading and updating

• Hardware troubleshooting and reconfiguration

etc., etc., etc.

33 CS 501 Spring 2004

Software Considerations of System Architectures: Performance

Resource considerations may dictate software design and implementation:

• Low level language (e.g., C) where programmer has close link to machine

• Inter-process communication may be too slow (e.g., C fork).

• May implement special buffering, etc., to control timings

34 CS 501 Spring 2004

Software Considerations of System Architectures: Multi-Threading

Several similar threads operating concurrently:

• Re-entrant code -- separation of pure code from data for each thread• May be real-time (e.g., telephone switch) or non-time critical

The difficult of testing real-time, multi-threaded systems may determine the entire software architecture.

• Division into components, each with its own acceptance test.

35 CS 501 Spring 2004

Time-Critical System:Embedded Real-time Systems

Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task:

• Digital telephone

• Automobile engine control

• GPS

• Scientific instruments

• Seat bag controller

The software may be embedded in the device in a manner that cannot be altered after manufacture.

36 CS 501 Spring 2004

Software Considerations:Embedded Real-time Systems

Design of embedded systems requires close understanding of hardware characteristics

• Special purpose hardware requires special tools and expertise.

• Some functions may be implemented in either hardware of software (e.g., floating point unit)

• Design requires separation of functions

Distinction between hardware and software may be blurred.

Hardware v. Software

37 CS 501 Spring 2004

Software Considerations of System Architectures: Continuous Operation

Many systems must operate continuously

• Software update while operating

• Hardware monitoring and repair

• Alternative power supplies, networks, etc.

• Remote operation

These functions must be designed into the fundamental architecture.