Transcript Design: HOW to implement the system

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

Operations

Data
Representations

Data Types

Topic
Algorithms
Design
 System

Focus on architecture

Identification of subsystems
 Object
Topic
design (high level design)
design (lower level design)

Modules and their implementations

Focus on data representations and
algorithms
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

Topic

Constraints


Interrelated
 Good cohesion
Well-defined, small
interface with other
subsystems
 Low coupling
Identified by the
service it provides
Subsystem Discussion

Provide services for other subsystems

Group of related functions

Share a common purpose

Divide system into components (>20)

Subsystems are decomposed . . .

Topic
Module is the lowest level of subsystem
Subsystem Relationships
 Client-Server


relationship
Client subsystems actively drive the
system by requesting services provided by
a server subsystem
Peer-to-peer relationship

Topic
Subsystems interact and communicate to
accomplish a common goal
Client-Server Relationship


Server supplies services for clients

Need not know identity of clients

Need not know interface of clients
Client calls server
Topic

Client knows interface of server

Server performs some service and
returns a result
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
Topic
decompositions
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
Topic
change
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
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
Topic
decomposition of problem
Ex: Partitioned Architecture
Operating System
Virtual
File
Process
Memory
Device
System
Control
Manage-
Control
ment
Topic
Typical Application Architecture
Application package
Window graphics
User
dialogue
control
Screen graphics
Pixel graphics
Operating system
Computer hardware
Topic
Simulation
package
System Topology
 Describe
information flow
 Can
use DFD to model flow
 Some
common topologies
 Pipeline
 Star
Topic
(batch)
topology
Ex: Pipeline Topology
Compiler:
source
program
Lexical
analyzer
token stream
Semantic
analyzer
abstract syntax tree
Code
generator
Topic
code
sequence
Code
optimizer
object
code
Ex: Star Toplogy
Monitoring system:
Alarm
Sensors
sensor
status
commands, SafeHome
data
software
Control
panel
Topic
display
information
On/Off signals,
alarm type
Telephone
line
number
tones
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

Topic
user defined types
Abstraction (cont.)
 Abstract
data types
 encapsulation
 Abstract
of data
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


Logically cohesive


contiguous lines of code not exceeding
a maximum size
all output routines
Temporally cohesive

Topic
all initialization routines
(Better) Types of cohesiveness

Procedurally cohesive


Communicationally cohesive


routines called in sequence
work on same chunk of data
Functionally cohesive

Topic
work on same data abstraction at a
consistent level of abstraction
Example: Poor Cohesion
package Output is
procedure DisplayDice( . . .);
procedure DisplayBoard( . . .);
I/O
device
Topic
Dice
Output
Board
Example: Good Cohesion
package Dice is
procedure Display ( . . .);
procedure Roll( . . .);
Dice
I/O
device
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 maintainability

Topic
Easier to localize errors, modify
implementations of an objects, ...
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

Good coupling
 pass

abstract objects as parameters
Black boxes
 hide
Topic
a single abstraction
data representations and algorithms
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
Topic
retained for a short time
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
 Event-driven
 Concurrent
Topic
systems
systems
systems
Procedure-driven systems
 Control
resides within the program
code

procedure issues request, waits for reply,
then continues execution
 System

Topic
state defined by
program counter, stack of procedure calls,
local variables
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
Topic
schedules tasks for execution
Boundary Conditions
 Initialization

Constants, parameters, global variables,
tasks, guardians, class hierarchy
 Termination

Release external resources, notify other
tasks
 Failure

Topic
Clean up and log failure info
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, . . .

Topic