Download 14-SystemsDesign.pdf

Design:
HOW to implement a system
●
System Design
Goals:
Satisfy the requirements
Satisfy the customer
■ Reduce development costs
■ Provide reliability
■ Support maintainability
■ Plan for future modifications
■
■
14-SystemDesign
1
14-SystemDesign
Design Issues
System Design
●
●
Architecture
●
Operations
●
User Interface
●
Data
●
Data Types
●
Representations
●
●
●
Algorithms
14-SystemDesign
3
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
14-SystemDesign
Strategic vs. Local Design
Decisions
4
System Design
●
Defn: A high-level or strategic design decision is one that
influences the form of (a large part) of the final code
●
Strategic decisions have the most impact on the final
system
●
So they should be made carefully
●
Question: Can you think of an example of a strategic
decision?
14-SystemDesign
2
●
Defn: The high-level strategy for solving an [information
flow] problem and building a solution
■
■
■
●
5
Includes decisions about organization of functionality.
Allocation of functions to hardware, software and people.
Other major conceptual or policy decisions that are prior to
technical design.
Assumes and builds upon thorough requirements and
analysis.
14-SystemDesign
6
1
Taxonomy of System-Design
Decisions
System Architecture
●
●
●
●
Devise a system architecture
Choose a data management approach
Choose an implementation of external control
●
●
●
A collection of subsystems and interactions among
subsystems.
Should comprise a small number (<20) of subsystems
A subsystem is a package of classes, associations, operations,
events and constraints that are interrelated and that have a
reasonably well-defined interface with other subsystems,
Example subsystems:
■
■
14-SystemDesign
7
14-SystemDesign
●
●
●
Decompose into subsystems layers and partitions.
Separate application logic from user interface
Simplify the interfaces through which parts of the system
will connect to other systems.
In systems that use large databases:
■
■
●
●
●
Devise a system architecture
Choose a data management approach
Choose an implementation of external control
Distinguish between operational (transactional) and inquiry
systems.
Exploit features of DBMS
14-SystemDesign
9
14-SystemDesign
Choosing a Data Management
Approach
●
Databases:
■
◆
◆
◆
◆
◆
“Flat” files
■
Efficient management
multi-user support.
Roll-back support
◆
■
Performance overhead
Awkward (or more complex) programming interface
Hard to fix corruption
14-SystemDesign
Advantages:
◆
Disadvantages:
Easy and efficient to construct and use
More readily repairable
Disadvantages:
◆
◆
◆
11
10
Choosing a Data Management
Approach (continued)
●
Advantages:
◆
■
8
Taxonomy of System-Design
Decisions
Architectural Design Principles
●
Database management systems (RDBMS)
Interface (GUI) package
No rollback
No direct complex structure support
Complex structure requires a grammar for file format
14-SystemDesign
12
2
Flat File Storage and Retrieval
●
Useful to define two components (or classes)
■
■
●
●
Reader reads file and instantiates internal object
structure
Writer traverses internal data structure and writes out
presentation
●
●
●
Both can (should) use formal grammar
■
Java Data Marshalling
Provides a means of “serializing” a set of objects
Requires classes to implement the “Serializable”
interface.
Stream can be written/read to a file
Stream can be written/read to a network socket.
Tools support: Yacc, Lex.
13
14-SystemDesign
14-SystemDesign
14
Taxonomy of System-Design
Decisions
Serialization Example
●
private void writeObject(java.io.ObjectOutputStream out) throws IOException;
private void readObject(java.io.ObjectInputStream in)
●
throws IOException, ClassNotFoundException;
●
Devise a system architecture
Choose a data management approach
Choose an implementation of external control
FileOutputStream ostream = new FileOutputStream("t.tmp");
Interface
ObjectOutputStream p = new ObjectOutputStream(ostream);
p.writeInt(12345);
p.writeObject("Today");
p.writeObject(new Date());
Example use
p.flush(); ostream.close();
14-SystemDesign
15
14-SystemDesign
Implementation of External
Control
Implementation of External
Control
Four general styles for implementing software control
●
●
●
Control = location in the source code.
■
Requests block until request returns
Concurrent
■
Procedure-driven:
■
■
Control resides in multiple, concurrent objects
Objects communicate by passing messages
◆
●
■
■
Uses callback functions registered for events
■
■
Dispatcher services events by invoking callbacks
17
across busses, networks, or memory.
Transactional
Event-Driven: Control resides in dispatcher
14-SystemDesign
16
Control resides in servers and saved state
Many server-side E-systems are like this
14-SystemDesign
18
3
Sample Concurrent System
1ST
target acquisition
target loss
distance
Control
x1: integer
x2: integer
tinc: integer
vc: integer
vt:integer
v:integer
tmin: integer = 2
z1: integer
z2: integer
xhit: integer
xcoast: integer
setspd: integer
a: integer = 15
closing: boolean
MVC (Model/View/Controller)
Radar
carspeed
v: integer
vc: integer
vt: integer
x: integer
tmode: booelan
∆ data
Representation
(view)
19
1st Qtr
2nd Qtr
3rd Qtr
4th Qtr
change events
Controller
(interface for
data changes)
1st Qtr
2nd Qtr
3rd Qtr
4th Qtr
Representation consumer
(view)
observable
20
14-SystemDesign
Events
Process
event type N
Application code
Window
manager
21
Typical Dispatcher Code
Widget1
(e.g. Button)
Button
Listener
Widget2
(e.g. TextBox)
Text
Listener
User-interface
component
Application
code
Widget3
(e.g. Dialog)
Listener
22
14-SystemDesign
Transactional Model
Startup
Server
System/network
Mimics event-driven
Application/initial
while (!quit) {
WaitEvent(timeout, id);
switch (id) {
case ID1: Procedure1(); break;
case ID2: Procedure2(); break;
….
}
}
14-SystemDesign
East
10
0
Get events
and
dispatch
Process
event type 2
14-SystemDesign
Event Loop
20
5
Process
event type 1
Window manager
&
Notifier
25
Event-driven architecture in modern UI
toolkits
(event driven)
Get event,
call a
procedure
40
Model
(data)
Dispatcher Model
Events
35
30
20
15
setv: integer
realv: integer
14-SystemDesign
40
10
4th
Car
carspeed
throttle control
5
Separates data model,
2nd
data view, and behavior
into separate components 3rd
State manager
Dispatch based
on previous state
Application/Classes
Object A
23
Restore
state
Object B
14-SystemDesign
Object C
24
4
Layered Subsystems
Example: Layered architecture
●
Set of “virtual” worlds
●
Each layer is defined in terms of the layer(s) below it
■
Interactive Graphics Application
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)
Windows Operations
Screen Operations
Pixel Operations
Device I/O Operations
14-SystemDesign
25
14-SystemDesign
Open Architectures
Closed 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
● Each
layer is built only in terms
of the immediate lower layer
● Reduces
dependencies between
layers
● Facilitates
change
14-SystemDesign
27
14-SystemDesign
●
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
14-SystemDesign
29
28
Partitioned Architectures
Properties of Layered Architectures
●
26
●
Divide system into weakly-coupled
subsystems
●
Each provides specific services
●
Vertical decomposition of problem
14-SystemDesign
30
5
Ex: Partitioned Architecture
Typical Application Architecture
Operating System
Application package
File
Process
Memory
Device
System
Control
Manage-
Control
Window graphics
User
dialogue
control
Virtual
Screen graphics
Simulation
package
Pixel graphics
Operating system
ment
Computer hardware
31
14-SystemDesign
System Topology
●
●
Ex: Pipeline Topology
Compiler:
Describe information flow
■
source
program
Can use DFD to model flow
Some common topologies
■
Pipeline (batch)
■
Star topology
Code
generator
33
Code
optimizer
Organize modules according to
resources/objects/data types
●
Provide cleanly defined interfaces
●
Hide implementation details
●
Simplify program understanding
●
Simplify program maintenance
On/Off signals,
alarm type
commands, SafeHome
data
software
14-SystemDesign
code
sequence
●
Alarm
display
information
Semantic
analyzer
object
code
34
Modularity
Monitoring system:
Control
panel
token stream
14-SystemDesign
Ex: Star Topology
sensor
status
Lexical
analyzer
abstract syntax tree
14-SystemDesign
Sensors
32
14-SystemDesign
number
tones
■
Telephone
line
35
operations, methods, procedures, ...
14-SystemDesign
36
6
Abstraction
●
Abstraction (cont.)
Control abstraction
■
■
■
●
Procedural abstraction
●
Data abstraction
■
■
●
structured control statements
exception handling
concurrency constructs
Abstract data types
■
●
procedures and functions
encapsulation of data
Abstract objects
■
subtyping
■
generalization/inheritance
user defined types
14-SystemDesign
37
Cohesion
●
Contents of a module should be cohesive
●
Improves maintainability
■
Easier to understand
■
Reduces complexity of design
■
Supports reuse
(Weak) Types of cohesiveness
●
Coincidentally cohesive
■
Logically cohesive
●
Temporally cohesive
■
●
●
40
14-SystemDesign
package Output is
procedure DisplayDice( . . .);
procedure DisplayBoard( . . .);
routines called in sequence
Communicationally cohesive
■
all initialization routines
Example: Poor Cohesion
Procedurally cohesive
■
all output routines
39
(Better) Types of cohesiveness
●
contiguous lines of code not exceeding a
maximum size
●
■
14-SystemDesign
38
14-SystemDesign
Dice
work on same chunk of data
Functionally cohesive
■
work on same data abstraction at a consistent
level of abstraction
14-SystemDesign
41
I/O
device
Output
Board
14-SystemDesign
42
7
Coupling
Example: Good Cohesion
package Dice is
procedure Display ( . . .);
procedure Roll( . . .);
Dice
I/O
device
●
Connections between modules
●
Bad coupling
■
Global variables
■
Flag parameters
■
Direct manipulation of data structures by multiple
classes
Board
14-SystemDesign
43
14-SystemDesign
Coupling (cont.)
●
■
■
●
Information Hiding
●
Good coupling
■
●
■
■
●
Data representations, algorithmic details,
system dependencies
Black box
■
Easier to localize errors, modify implementations
of an objects, ...
14-SystemDesign
Hide decisions likely to change
■
Procedure calls
Short argument lists
Objects as parameters
Good coupling improves maintainability
■
Input is known
Output is predictable
Mechanism is unknown
Improves maintainability
45
14-SystemDesign
Information Hiding
46
Abstract data types
●
Modules (Classes, packages)
■
Encapsulate data structures and their
operations
Good cohesion
■
Good coupling
■
Black boxes
■
◆
◆
◆
14-SystemDesign
44
47
implement a single abstraction
pass abstract objects as parameters
hide data representations and algorithms
14-SystemDesign
48
8
Identifying Concurrency
●
Determining Concurrent Tasks
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
14-SystemDesign
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
49
14-SystemDesign
Global Resources
Boundary Conditions
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)
14-SystemDesign
50
●
Initialization
■
●
Termination
●
Failure
■
■
51
Constants, parameters, global variables, tasks,
guardians, class hierarchy
Release external resources, notify other tasks
Clean up and log failure info
14-SystemDesign
52
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, .
..
14-SystemDesign
53
9