Design: HOW to implement a system
 Goals:
» Satisfy the requirements
» Satisfy the customer
» Reduce development costs
» Provide reliability
» Support maintainability
» Plan for future modifications
Dillon: CSE470: SYSTEM DESIGN
1
Design Issues


Architecture
User Interface

Operations

Data
Representations

Data Types

Dillon: CSE470: SYSTEM DESIGN
Algorithms
2
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
Dillon: CSE470: SYSTEM DESIGN
3
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

Dillon: CSE470: SYSTEM DESIGN
4
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

Dillon: CSE470: SYSTEM DESIGN
5
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

Dillon: CSE470: SYSTEM DESIGN
6
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

Dillon: CSE470: SYSTEM DESIGN
7
Design Principles (cont.)

Define interfaces between modules
carefully

Consider how to handle the
unexpected

Don’t code!!

Document decisions

Review, review, review . . .
Dillon: CSE470: SYSTEM DESIGN
8
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
Dillon: CSE470: SYSTEM DESIGN
9
Subsystem Identification
 Divide
system into a manageable
number of components
 Each
major component is a
subsystem
 Subsystem
groups components
with common properties/function
Dillon: CSE470: SYSTEM DESIGN
10
Subsystem

Collection of

» Classes
» Associations

» Operations
» Events
» Constraints
Dillon: CSE470: SYSTEM DESIGN

Interrelated
» Good cohesion
Well-defined, small
interface with other
subsystems
» Low coupling
Identified by the
service it provides
11
Subsystem Discussion

Provide services for other subsystems
» Group of related functions
» Share a common purpose

Divide system into components (>20)

Subsystems are decomposed . . .
» Module is the lowest level of subsystem
Dillon: CSE470: SYSTEM DESIGN
12
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
Dillon: CSE470: SYSTEM DESIGN
13
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
Dillon: CSE470: SYSTEM DESIGN
14
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
Dillon: CSE470: SYSTEM DESIGN
15
Strategies for
Decompositions
 Layers: Horizontal decomposition
» Open
» Closed
 Partitions: Vertical decomposition
 System
topology:
» General decompositions
Dillon: CSE470: SYSTEM DESIGN
16
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)
Dillon: CSE470: SYSTEM DESIGN
17
Example: Layered architecture
Interactive Graphics Application
Windows Operations
Screen Operations
Pixel Operations
Device I/O Operations
Dillon: CSE470: SYSTEM DESIGN
18
Closed Architectures
 Each
layer is built only in
terms of the immediate lower
layer
 Reduces
dependencies
between layers
 Facilitates
Dillon: CSE470: SYSTEM DESIGN
change
19
Open Architectures
 Layer
can use any lower layer
 Reduces the need to redefine
operations at each level
 More efficient /compact code
 System is less robust/harder
to change
Dillon: CSE470: SYSTEM DESIGN
20
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
Dillon: CSE470: SYSTEM DESIGN
21
Partitioned
Architectures
 Divide
system into weakly-
coupled subsystems
 Each
provides specific services
 Vertical
decomposition of
problem
Dillon: CSE470: SYSTEM DESIGN
22
Ex: Partitioned Architecture
Operating System
Virtual
File
Process
Memory
Device
System
Control
Manage-
Control
ment
Dillon: CSE470: SYSTEM DESIGN
23
Typical Application Architecture
Application package
Window graphics
User
dialogue
control
Screen graphics
Simulation
package
Pixel graphics
Operating system
Computer hardware
Dillon: CSE470: SYSTEM DESIGN
24
System Topology
 Describe
information flow
» Can use DFD to model flow
 Some
common topologies
» Pipeline (batch)
» Star topology
Dillon: CSE470: SYSTEM DESIGN
25
Ex: Pipeline Topology
Compiler:
source
program
Lexical
analyzer
token stream
Semantic
analyzer
abstract syntax tree
Code
generator
Dillon: CSE470: SYSTEM DESIGN
code
sequence
Code
optimizer
object
code
26
Ex: Star Toplogy
Monitoring system:
Alarm
Sensors
sensor
status
commands, SafeHome
data
software
Control
panel
Dillon: CSE470: SYSTEM DESIGN
display
information
On/Off signals,
alarm type
Telephone
line
number
tones
27
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
Dillon: CSE470: SYSTEM DESIGN
28
Abstraction

Control abstraction
» structured control statements
» exception handling
» concurrency constructs

Procedural abstraction
» procedures and functions

Data abstraction
» user defined types
Dillon: CSE470: SYSTEM DESIGN
29
Abstraction (cont.)
 Abstract
data types
» encapsulation of data
 Abstract
objects
» subtyping
» generalization/inheritance
Dillon: CSE470: SYSTEM DESIGN
30
Cohesion

Contents of a module should be
cohesive

Improves maintainability
» Easier to understand
» Reduces complexity of design
» Supports reuse
Dillon: CSE470: SYSTEM DESIGN
31
(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
Dillon: CSE470: SYSTEM DESIGN
32
(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
Dillon: CSE470: SYSTEM DESIGN
33
Example: Poor Cohesion
package Output is
procedure DisplayDice( . . .);
procedure DisplayBoard( . . .);
I/O
device
Dillon: CSE470: SYSTEM DESIGN
Dice
Output
Board
34
Example: Good Cohesion
package Dice is
procedure Display ( . . .);
procedure Roll( . . .);
Dice
I/O
device
Board
Dillon: CSE470: SYSTEM DESIGN
35
Coupling

Connections between modules

Bad coupling
» Global variables
» Flag parameters
» Direct manipulation of data structures
by multiple classes
Dillon: CSE470: SYSTEM DESIGN
36
Coupling (cont.)

Good coupling
» Procedure calls
» Short argument lists
» Objects as parameters

Good coupling improves maintainability
» Easier to localize errors, modify
implementations of an objects, ...
Dillon: CSE470: SYSTEM DESIGN
37
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
Dillon: CSE470: SYSTEM DESIGN
38
Information Hiding
Dillon: CSE470: SYSTEM DESIGN
39
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
Dillon: CSE470: SYSTEM DESIGN
40
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
Dillon: CSE470: SYSTEM DESIGN
41
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
Dillon: CSE470: SYSTEM DESIGN
42
Management of Data Stores
 Data
stores permit separations
between subsystems
» Internal or external
 Common
types of data stores
» Files
» Databases
Dillon: CSE470: SYSTEM DESIGN
43
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
Dillon: CSE470: SYSTEM DESIGN
44
Database Data Stores
 Advantages
» Infrastructure support
» Common interface
» Standard access language (SQL)
 Disadvantages
» Performance penalty
» Awkward programming language
Dillon: CSE470: SYSTEM DESIGN
45
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
Dillon: CSE470: SYSTEM DESIGN
46
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)
Dillon: CSE470: SYSTEM DESIGN
47
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
Dillon: CSE470: SYSTEM DESIGN
48
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
Dillon: CSE470: SYSTEM DESIGN
49
External Control
 Procedure-driven
 Event-driven
 Concurrent
Dillon: CSE470: SYSTEM DESIGN
systems
systems
systems
50
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
Dillon: CSE470: SYSTEM DESIGN
51
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
Dillon: CSE470: SYSTEM DESIGN
52
Concurrent Systems
 Control
resides concurrently in
independent tasks
 Events
are implemented as
messages between tasks
 OS
schedules tasks for
execution
Dillon: CSE470: SYSTEM DESIGN
53
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
Dillon: CSE470: SYSTEM DESIGN
54
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, . . .

Dillon: CSE470: SYSTEM DESIGN
55