CISC 323 Intro to Software Engineering A design pattern identifies - - PowerPoint PPT Presentation

1

CISC 323 Intro to Software Engineering

Topic 7: Software Architecture

Readings:

• in courseware
• taken from:

Software Architecture – Perspectives on an Emerging Discipline by M. Shaw and D. Garlan

CISC 323, Winter 2003, Software Architecture 2

Recall: Design Patterns

• A design pattern
• identifies and describes the key aspects of a solution to a

common design problem

Which classes, objects? How do they collaborate?

What is its impact on quality attributes and thus system requirements?

• allows the efficient communication of design expertise

A design pattern catalogue

• provides vocabulary/toolbox to discuss and weigh design

solutions

• allows designers to make informed decisions efficiently

CISC 323, Winter 2003, Software Architecture 3

Recall: Design Patterns (cont’d)

But also:

• A pattern only solves a single, local problem that the

system construction poses => A system could use/consist of several patterns

• Design patterns are not meant to describe the overall,

global architecture of a system

• While more abstract than code, some patterns are still

somewhat low-level and implementation-oriented, e.g.,

Iterator

Visitor

Builder

CISC 323, Winter 2003, Software Architecture 4

Software Architecture

“The architecture of a software system defines that system in terms of computational components and interactions among those components”.

• -- Shaw & Garlan, page 3

Examples for

• components: clients and servers, databases, filters, and

layers in a hierarchical system

• interactions: procedure/method calls, shared variable

accesses, client-server protocols, database protocols etc

An architecture shows

• global topology of system and its
• impact on the system requirements

2

CISC 323, Winter 2003, Software Architecture 5

Very Simple Software Architecture Example

E-commerce system supporting ordering of books on the WWW

Customers use web browser to find books, read about books, make orders

Inventory subsystem can estimate time before book is sent

• Some books in inventory, some need to be ordered from

publisher

After order is placed, sent to shipping subsystem to be filled

For an example, see http://www.amazon.com HTTP Server

(e.g. Apache)

HTTP Client

(e.g., Netscape, Internet Explorer)

Order System Inventory Catalogue

Requests for book info, delivery times, orders, etc. HTML document Requests for book info Requests for delivery time Order placement Request availability

CISC 323, Winter 2003, Software Architecture 7

Components and Connectors

Component Component: A software or hardware entity implementing some part of the system’s functionality Connector: a mechanism allowing components to interact. In this example, we have 3 different connectors

CISC 323, Winter 2003, Software Architecture 8

Example Connectors

HTTP Connector: source component issues HTTP requests, target component responds with HTML document CGI Connector: source component calls target component; target component responds with HTML document Java Call Connector: source component calls method of target component using standard Java method calling conventions; target component returns some Java type

3

CISC 323, Winter 2003, Software Architecture 9

Analyzing Architectures

Possibly important quality attributes of this architecture:

• Availability: What are risks of system not being

available (e.g., going down?)

Redundant servers?

• Security: What are risks of (e.g.) credit card information

being intercepted

Perhaps use HTTPS connector instead of HTTP connector?

• Performance: What are risks in case of many users?

Perhaps use array of servers, with server redirection?

• Modifiability: What if we want to add a telephone
• rdering service?

CISC 323, Winter 2003, Software Architecture 10

Attribute-Driven Design

Use quality attributes to motivate design decisions

Analyze architectural choices based on software architecture chosen

CISC 323, Winter 2003, Software Architecture 11

Review of Quality Attributes

Recall

• Requirements analysis determines desired quality

attributes of system

• When designing software architecture, attempt to

Identify areas of risk where quality attributes may not be met

Reduce risk through architectural choices

• Some attributes amenable to mathematical expression

(performance, availability), others less so (modifiability)

CISC 323, Winter 2003, Software Architecture 12

Quality Attributes

Runtime

• Performance, Security, Availability

Development Time

• Modifiability, Portability, Reusability, Testability

4

CISC 323, Winter 2003, Software Architecture 13

How to Measure Performance?

Feedback time

• Time it takes system to respond to user’s actions
• For highly interactive tasks (e.g., drawing a box in

PowerPoint), typical requirement = 100 ms

• For less interactive tasks (e.g., clicking a button), typical

requirement = 1 s

• For computational tasks may be longer (e.g., time to load

a web page might be acceptable at 10 s)

Feedthrough time

• Time until other users can see result of one user’s actions
• For highly interactive tasks (e.g., collaborative drawing,

Internet telephone), typical requirement = 300 ms

CISC 323, Winter 2003, Software Architecture 14

How to Measure Performance? (cont’d)

Jitter

• Variance in feedback time

E.g. in command-line systems such as Unix, low variance in time to complete commands may be more important than feedback time itself

• Variance in delivery of continuous media such as video

Broadcast frame rate = 30 frames per second

Therefore frames delivered at 33 ms intervals

For video played over Internet (e.g., video on CBC web site), delivery of frames from remote source may not be at such an even rate

CISC 323, Winter 2003, Software Architecture 15

Buffering: Trading off Feedthrough Time and Jitter

Video Source Video Player Video frames Video Source Video Player Video frames Video frames

1) Best Feedthrough Time 2) Best Jitter

Buffer used to smooth jitter. E.g., buffer 10 s

• f frames

Questions:

• Which is better for an IP telephone?
• Which is better for viewing the CBC news?

CISC 323, Winter 2003, Software Architecture 16

How to Measure Performance (cont’d)

Turnaround time

• Average time to complete a batch job
• For example, a database query

Throughput

• Average number of jobs / requests processed per time

unit

• For example,

number of database queries per second

number of polygons rendered per second

5

CISC 323, Winter 2003, Software Architecture 17

Availability

Intuitively represents how much of the time the system is available for use

System may cease to be available through

• Network failure
• Computer hardware failure (e.g., bad memory, disk

crash)

• Software failure

Failure of application or operating system

Failure of application components to correctly interoperate

CISC 323, Winter 2003, Software Architecture 18

May be measured as Mean time to failure Mean time to failure + Mean time to repair

Availability (cont’d)

For example, if system fails on average every 20 days and takes one day to fix: Availability = 20 / (20 + 1) = 0.952

CISC 323, Winter 2003, Software Architecture 19

Mechanisms for Improving Availability

May improve availability by

• increasing mean time to failure,
• decreasing mean time to repair or
• both

Techniques for decreasing mean time to repair:

?

CISC 323, Winter 2003, Software Architecture 20

Mechanisms for Improving Availability

May improve availability by

• increasing mean time to failure,
• decreasing mean time to repair or
• both

Techniques for decreasing mean time to repair:

• redundancy
• checkpointing
• logging

6

CISC 323, Winter 2003, Software Architecture 21

Component Redundancy

A component responds to requests/updates from other sources

Forwards all requests/updates to shadow component (e.g., on different machine)

If component fails, clients reconnect to shadow component and keep going

Shadow Component Component Requests / updates Requests / updates Responses

CISC 323, Winter 2003, Software Architecture 22

Component Redundancy (cont’d)

A component responds to requests/updates from other sources

Forwards all requests/updates to shadow component (e.g., on different machine)

If component fails, clients reconnect to shadow component and keep going

Shadow Component Component Requests / updates Requests / updates Responses

CISC 323, Winter 2003, Software Architecture 23

Checkpointing/Logging

If component fails, need to retrieve its state when it is restarted

Checkpointing: periodically write component state to disk

Logging: write updates to file

• n disk; can replay updates

when component restarted

Can combine checkpointing and logging - e.g., log goes back to last checkpoint

Component Requests / updates updates Responses Log

CISC 323, Winter 2003, Software Architecture 24

Checkpointing/Logging

Component Requests / updates updates Responses Log Check- point system state

If component fails, need to retrieve its state when it is restarted

Checkpointing: periodically write component state to disk

Logging: write updates to file

• n disk; can replay updates

when component restarted

Can combine checkpointing and logging - e.g., log goes back to last checkpoint

7

CISC 323, Winter 2003, Software Architecture 25

Summary

Desired quality attributes are identified during requirements phase

Choice of architecture impacts quality attributes

Architectural choices trade off different attributes

• E.g., buffering in video player trades off jitter vs

feedthrough time

• E.g., checkpointing/logging trade off time to develop,

storage compactness (performance) vs availability

Challenge: How do you determine efficiently which kind of architecture will give a system satisfying the requirements?

CISC 323, Winter 2003, Software Architecture 26

Recall: Design Patterns

A design pattern

• identifies and describes the key aspects of a solution to a

common design problem

Which classes, objects? How do they collaborate?

What is its impact on quality attributes and thus system requirements?

• allows the efficient communication of design expertise

A design pattern catalogue

• provides vocabulary/toolbox to discuss and weigh design

solutions

• allows designers to make informed decisions efficiently

CISC 323, Winter 2003, Software Architecture 27

Recall: Design Patterns (cont’d)

But also:

• A pattern only solves a single, local problem that the

system construction poses => A system could use/consist of several patterns

• Design patterns are not meant to describe the overall,

global architecture of a system

• While more abstract than code, some patterns are still

somewhat low-level and implementation-oriented, e.g.,

Iterator

Visitor

Builder

CISC 323, Winter 2003, Software Architecture 28

Architecture Styles

An architectural style defines a family of systems that share a certain pattern of structural organization. In other words, “.. an architectural style defines a vocabulary of component and connector types and a set of constraints on how they can be combined”

• - Shaw & Garlan, page 20

Ideally, description of architectural style should also explain

• how to combine components and connectors (syntax)
• where this style should be applied (domain description)
• properties of this architecture (reasoning framework)

8

CISC 323, Winter 2003, Software Architecture 29

Architecture Styles vs Design Patterns

An architectural style can be thought of as a global, more abstract design pattern

• They have similar goals:

identify solution to common problem

allow efficient communication of design expertise

facilitate efficient, informed design decisions

• but occupy different levels of scale and abstraction:

architectural style provides solution to more global design problem

architectural style described in more abstract terms than design pattern

CISC 323, Winter 2003, Software Architecture 30

Architecture Styles: Example 1

In this course, we’ve already seen one architectural style

Remember?

CISC 323, Winter 2003, Software Architecture 31

Architecture Styles: Example 1 (cont’d)

The Unified Approach advocates the use of a layered architecture

User Interface (View) Layer: for user interaction

Data Workstation

Ow ner Name Title Address

Business Layer: for computation Access Layer: for retrieval and storage

CISC 323, Winter 2003, Software Architecture 32

Architectural Style: Layered Systems

Components: several hierarchal layers where

• each layer

provides service to the layer above it by

using the layer below it and

typically hides some functionality from layer above

Connectors/Interactions:

• given by protocols that define how layers interact

Constraints:

• only adjacent layers can interact

Properties:

• we’ll see later

9

CISC 323, Winter 2003, Software Architecture 33

Software Architecture: Overview

Subtopics:

• 7.1: Introduction
• Architectural Styles:

7.2: Pipe and Filter

7.3: Data Abstraction and Object Organization

7.4: Event-Based, Implicit Invocation

7.5: Layered Systems

7.6: Repositories

7.7: Interpreters

7.8: Process Control

• 7.9: Case Studies

Instrumentation Software

Mobile Robotics

CISC 323, Winter 2003, Software Architecture 34

Other Architectural Styles

Pipe and Filter

Layered Systems

Data Abstraction and Object Organization

Event-Based, Implicit Invocation

Repositories

Interpreters

Process Control