Topic

Design: HOW to implement a system

Goals: Satisfy the requirements Satisfy the customer Reduce development costs Provide reliability Support maintainability Plan for future modifications

Topic

Design Issues

Architecture

User Interface

Data Types

Operations

Data

Representations

Algorithms

Topic

Design

System design (high level design) Focus on architecture

Identification of subsystems

Object design (lower level design) Modules and their implementations

Focus on data representations and

algorithms

Topic

System Design Choose high-level strategy for solving

problem and building solution Decide how to organize the system

into subsystems Identify concurrency / tasks Allocate subsystems to HW and SW

components

Topic

System Design

Major conceptual and policy decisions Approach for management of data stores Access mechanism for global resources Software control mechanism

Handle boundary conditions Prioritize trade-offs

Topic

Design Principles Consider alternative approaches

Do pro and con analysis Delay decisions until superior choice is

clear Isolate decisions so alternative

implementations can be evaluated later Avoid unnecessary embellishments But don’t oversimplify

Topic

Design Principles (cont.) Make design traceable to

requirements Use uniform documentation style Reuse existing designs when

possible Keep design simple unless

performance, maintainability, etc. DEMAND otherwise

Topic

Design Principles (cont.)

Define interfaces between modules carefully

Consider how to handle the unexpected Don’t code!! Document decisions Review, review, review . . .

Topic

System Architecture

Overall organization of system into subsystems

Decide basic interaction patterns Numerous architectural styles

for different applications Architecture provides context for

detailed design decisions

Topic

Subsystem Identification

Divide system into a manageable

number of components

Each major component is a

subsystem

Subsystem groups components

with common properties/function

Topic

Subsystem

Collection of Classes

Associations

Operations

Events

Constraints

Interrelated Good cohesion

Well-defined, small interface with other subsystems Low coupling

Identified by the service it provides

Topic

Subsystem Discussion

Provide services for other sub-

systems Group of related functions

Share a common purpose Divide system into components (>20)

Subsystems are decomposed . . . Module is the lowest level of subsystem

Topic

Subsystem Relationships

Client-Server relationship Client subsystems actively drive the system

by requesting services provided by a server

subsystem

Peer-to-peer relationship Subsystems interact and communicate to

accomplish a common goal

Topic

Client-Server Relationship

Server supplies services for clients Need not know identity of clients

Need not know interface of clients

Client calls server Client knows interface of server

Server performs some service and

returns a result

Topic

Peer-to-Peer Relationship

Subsystems call one another The results of/responses to calls may

not be immediately visible Subsystems must know the interfaces of

other subsystems More likely to have communication

dependencies

Topic

Strategies for Decompositions

Layers: Horizontal decomposition Open

Closed

Partitions: Vertical decomposition

System topology: General decompositions

Topic

Layered Subsystems

Set of “virtual” worlds Each layer is defined in terms of the layer(s)

below it Knowledge is one way: Layer knows about

layer(s) below it

Objects within layer can be independent Lower layer (server) supplies services for

objects (clients) in upper layer(s)

Topic

Example: Layered architecture

Interactive Graphics Application

Windows Operations

Screen Operations

Pixel Operations

Device I/O Operations

Topic

Closed Architectures

Each layer is built only in terms of the immediate lower layer

Reduces dependencies between layers

Facilitates change

Topic

Open Architectures

Layer can use any lower layerReduces the need to redefine

operations at each levelMore efficient /compact codeSystem is less robust/harder to

change

Topic

Properties of Layered Architectures

Top and bottom layers specified by the problem statement Top layer is the desired system Bottom layer is defined by available

resources (e.g. HW, OS, libraries)

Easier to port to other HW/SW platforms

Topic

Partitioned Architectures

Divide system into weakly-coupled

subsystems

Each provides specific services

Vertical decomposition of problem

Topic

Ex: Partitioned ArchitectureOperating System

File

System

Process

Control

Virtual

Memory

Manage-

ment

Device

Control

Topic

Typical Application Architecture

Application package

Window graphics

Screen graphics

Pixel graphics

Operating system

Computer hardware

User dialogue control

Simulation package

Topic

System Topology

Describe information flow

Can use DFD to model flow

Some common topologies

Pipeline (batch)

Star topology

Topic

Ex: Pipeline Topology

Lexical analyzer

Semantic analyzer

Code generator

Code optimizer

source program token stream

abstract syntax tree

code sequence

object code

Compiler:

Topic

Ex: Star ToplogyMonitoring system:

SafeHome software

Sensors

Control panel

Alarm

Telephone line

sensor status

display information

commands, data

On/Off signals, alarm type

number tones

Topic

Modularity Organize modules according to

resources/objects/data types Provide cleanly defined interfaces

operations, methods, procedures, ...

Hide implementation details Simplify program understanding Simplify program maintainance

Topic

Abstraction Control abstraction

structured control statements exception handling concurrency constructs

Procedural abstraction procedures and functions

Data abstraction user defined types

Topic

Abstraction (cont.)

Abstract data types

encapsulation of data

Abstract objects

subtyping

generalization/inheritance

Topic

Cohesion

Contents of a module should be

cohesive

Improves maintainability Easier to understand

Reduces complexity of design

Supports reuse

Topic

(Weak) Types of cohesiveness

Coincidentally cohesive contiguous lines of code not exceeding a

maximum size

Logically cohesive all output routines

Temporally cohesive all initialization routines

Topic

(Better) Types of cohesiveness

Procedurally cohesive routines called in sequence

Communicationally cohesive work on same chunk of data

Functionally cohesive work on same data abstraction at a

consistent level of abstraction

Topic

Example: Poor Cohesion

package Output is

procedure DisplayDice( . . .);

procedure DisplayBoard( . . .);Dice

Board

I/O device

Output

Topic

Example: Good Cohesion

package Dice is

procedure Display ( . . .);

procedure Roll( . . .);

I/O device

Dice

Board

Topic

Coupling

Connections between modules

Bad coupling

Global variables

Flag parameters

Direct manipulation of data structures by

multiple classes

Topic

Coupling (cont.)

Good coupling Procedure calls Short argument lists Objects as parameters

Good coupling improves maintain-ability Easier to localize errors, modify

implementations of an objects, ...

Topic

Information Hiding Hide decisions likely to change

Data representations, algorithmic details, system dependencies

Black box Input is known Output is predictable Mechanism is unknown

Improves maintainability

Topic

Information Hiding

Topic

Abstract data types Modules (Classes, packages)

Encapsulate data structures and their operations

Good cohesion implement a single abstraction

Good coupling pass abstract objects as parameters

Black boxes hide data representations and algorithms

Topic

Identifying Concurrency

Inherent concurrency May involve synchronization Multiple objects receive events at the same

time with out interacting Example:

User may issue commands through control panel at same time that the sensor is sending status information to the SafeHome system

Topic

Determining Concurrent Tasks

Thread of control Path through state diagram with only one active

object at any time

Threads of control are implemented as tasks Interdependent objects Examine state diagram to identify objects that can

be implemented in a task

Topic

Management of Data Stores

Data stores permit separations

between subsystems Internal or external

Common types of data stores Files

Databases

Topic

File Data Stores When to use a database

Require access to voluminous data at fine levels of detail by multiple users

Access can be efficiently managed with DBMS commands

Application must port across many HW and OS platforms

Store is to be accessed by multiple application programs

Topic

Database Data Stores

Advantages Infrastructure support Common interface Standard access language (SQL)

Disadvantages Performance penalty Awkward programming language

Topic

File Data Stores

When to use file data stores Data does not fit structure of DBMS Voluminous data that is low in information

density

“Raw” data

Volatile data only retained for a short time

Topic

Global Resources

Identify global resources and determine access patterns

Examples physical units (processors, tape drives) available space (disk, screen, buttons) logical names (object IDs, filenames) access to shared data (database, file)

Topic

Software Control Mechanism

How SW will control interactions between objects Internal control

flow of control within a process

External control flow of externally-visible events among

objects

Uniform control style for objects

Topic

Internal Control

Under control of programmer Structured for convenience

efficiency, clarity, reliability, . . .

Common types of control flow Procedure calls Quasi-concurrent inter-task calls Concurrent inter-task calls

Topic

External Control

Procedure-driven systems

Event-driven systems

Concurrent systems

Topic

Procedure-driven systems

Control resides within the program code procedure issues request, waits for reply,

then continues execution

System state defined by program counter, stack of procedure calls,

local variables

Topic

Event-Driven Systems Control resides within a central

dispatcher calls to the dispatcher send output or

enable input dispatcher invokes procedures when

events occur (“call back”) state maintained

using global variables, or by dispatcher for procedures

Topic

Concurrent Systems

Control resides concurrently in independent tasks

Events are implemented as messages between tasks

OS schedules tasks for execution

Topic

Boundary Conditions Initialization

Constants, parameters, global variables, tasks, guardians, class hierarchy

Termination Release external resources, notify other

tasks

Failure Clean up and log failure info

Topic

Identify Trade-off Priorities Establish priorities for choosing

between incompatible goals Implement minimal functionality

initially and embellish as appropriate Isolate decision points for later

evaluation Trade efficiency for simplicity,

reliability, . . .