feb. 9, 2004cs 509 - wpi1 cs 509 design of software systems lecture #4 monday, feb. 9, 2004

26
Feb. 9, 2004 CS 509 - WPI 1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Upload: leona-lewis

Post on 19-Jan-2016

217 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 1

CS 509Design of Software Systems

Lecture #4Monday, Feb. 9, 2004

Page 2: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 2

Term Project AdministrationQuestionsQuiz #2Review of Chapters 6 & 7:Design Exercises:

Discuss how to organize design documentation

Begin CTS system design

Class Format for Today

Page 3: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 3

CTS Project & Questions

Phase 2 (Functional Specs) documents and Project Journals are due today.

Hand out Phase 3 (Design) assignmentQuestions?

About Term Project From last week’s class From the reading Anything else?

Page 4: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 4

Quiz #2

Chapters 3, 5, 6You have 15 minutes

Page 5: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 5

Chapter 6

System Design:Decomposing the

System

Page 6: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 6

Intro to System Design

Define design goals of systemDecompose system into smaller

subsystemsSelect strategies for building system:

Hardware & software Persistent data management Global control flow Access control policies Handling of boundary conditions

Page 7: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 7

Purpose of System Design

Make trade-off decisions: Identify & prioritize qualities to optimize Decide how to achieve various goals Goals may conflict with each other

Produce design model of system including: System decomposition addressing design

goals Description of design strategies

Page 8: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 8

Overview of System Design

Design goals derived from nonfunctional req’s

Software architecture describes decomposition: Subsystem responsibilities Dependencies among subsystems Mappings to hardware Policy decisions (control flow, access control, etc.)

Boundary use cases: Config, startup, shutdown, exception handling

Page 9: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 9

System Design Concepts

Decomposition: Subsystems, Packages, Classes

Services & subsystem interfacesCoupling vs. CohesionLayering and PartitioningArchitectural Styles

Page 10: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 10

Decomposition

What’s the difference between a Subsystem and a Package?

How many subsystems or packages do we need?

What classes make up a subsystem/package?

Where do we draw the lines?

Page 11: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 11

Services & Interfaces

A subsystem is characterized by the services it provides to other subsystems.

A service is a set of related operations that share a common purpose.

Examples of types of services? What operations are involved?

Interface independent of implementation, often defined during Object Design

Page 12: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 12

Coupling and Cohesion

Coupling measures dependencies between 2 subsystems

Cohesion measures dependencies among classes within a subsystem Want to minimize coupling and

maximize cohesion How can we do both? How are they

related?

Page 13: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 13

Layers & Partitions

Both are ways to manage complexityLayers are hierarchical; partitions are notEach layer uses services provided by

which other layer(s)?Layers have no knowledge of which other

layer(s)?Difference between open and closed

architectures?

Page 14: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 14

Architectural Styles

RepositoryModel-View-Controller (MVC)Client-serverPeer-to-peerTiered styles (3-tier, 4-tier)Pipe and filter

Page 15: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 15

Chapter 7

System Design:Addressing Design

Goals

Page 16: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 16

Activities Overview

Select off-the-shelf and legacy components

Mapping of subsystems to hardwareDesign of persistent data managementSpecification of access control policyDesign of global control flowHandling of boundary conditionsReviewing system design

Page 17: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 17

Select Existing Components

What is a legacy component? How do we know if it’s useful?

Other pre-existing components 3rd party packages may need to be

“wrapped”• What does this mean?

What are the trade-offs?Does building a component cost

more than buying it?

Page 18: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 18

Mapping to Platform

Select deployment hardware configuration “Who” is responsible for which

functionality? How is communication realized?

Select software platform: Operating system Virtual machine for development Other needed SW components

Reliability and performance issues

Page 19: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 19

Persistent Data

Data that outlives a single run of the system

Identification of storage subsystem(s) What data should be persistent? Where and how is data stored? How is it retrieved? (Who has access to

what?)Storage management strategies:

Flat files (serialization), RDBMS, OODB, etc.

Page 20: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 20

Access Control Policy

Shared objects are protected to control use How is access specified and realized? Impacts how objects are distributed

Policy should be consistent system-wide User roles & authentication

• Who has access to what, how are users identified?

Who can change access rights / privileges Data encryption, etc.

Use cases can help define policy

Page 21: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 21

Global Control FlowDetermine sequence of operations from 3

types: Procedure-driven

• Operations wait for input from user• Top-down, step-by-step, pre-defined flow• Well suited to procedural or functional languages

Event-driven• Flow determined by user action at run time• Better suited to object-oriented languages

Multi-threaded (concurrent)• Handle > 1 user or system interaction at the same

time• Requires language support

Page 22: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 22

Boundary ConditionsSystem initialization, startup and shutdownDetection & handling of exceptional cases

Hardware failures including system crash, data corruption, network outages

Changes in operating environment User errors such as data input

Impossible to anticipate all SW failures Can anticipate some unusual circumstances Handle in an appropriate way – “nice”

messages

Page 23: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 23

Reviewing System Design

Peer review helps ensure quality of design

Strive for following properties: Correct – based on req’s & analysis Complete – all req’s & design issues

addressed Consistent – model contains no contradictions Realistic – possible to implement system Readable / understandable

Page 24: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 24

Design Exercise

CTS System Design

Page 25: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 25

Meeting Agenda

Objective: Get started on system design of CTS

Tasks: How to organize design documentation Who will design what Discuss system design goals

Request for volunteer: To record minutes

Page 26: Feb. 9, 2004CS 509 - WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004

Feb. 9, 2004 CS 509 - WPI 26

For Next Time

No class next week (2/16) – Presidents Day

Read Chapters 8 & 9 – Object DesignBegin working on System Design

document

Next class (2/23) Quiz #3 on Chapters 7, 8, 9 Lecture on Object Design More in-class work on design documents