System Design
CSE 870: Adavnced Software Engineering
Design:
HOW to implement a system
Goals:
Satisfy the requirements
Satisfy the customer
Reduce development costs
Provide reliability
Support maintainability
Plan for future modifications
CSE 870: Adavnced Software Engineering
1
Design Issues
Architecture Operations
User Interface Data Representations
Algorithms
Data Types
CSE 870: Adavnced Software Engineering
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
CSE 870: Adavnced Software Engineering
2
Strategic vs. Local Design Decisions
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?
CSE 870: Adavnced Software Engineering
System Design
Defn: The high-level strategy for solving an [information
flow] problem and building a solution
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.
CSE 870: Adavnced Software Engineering
3
Taxonomy of System-Design
Decisions
Devise a system architecture
Choose a data management approach
Choose an implementation of
external control
CSE 870: Adavnced Software Engineering
System Architecture
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:
Database management systems (RDBMS)
Interface (GUI) package
CSE 870: Adavnced Software Engineering
4
System Topology
(also known as SW Architecture)
Describe information flow
Can use DFD to model flow
Some common topologies
Pipeline (batch)
Star topology
Client-server; P2P
Layered
CSE 870: Adavnced Software Engineering
Ex: Pipeline Topology (Architecture)
Compiler:
source
program Lexical token stream Semantic
analyzer analyzer
abstract syntax tree
code object
Code sequence Code code
generator optimizer
CSE 870: Adavnced Software Engineering
5
Ex: Pipeline Topology
(DFD notation example)
Grammar
Compiler:
source
program Lexical token stream Semantic
analyzer analyzer
abstract syntax tree
code object
Code sequence Code code
Platform
generator optimizer
CSE 870: Adavnced Software Engineering
Ex: Star Topology (Architecture:
Components/Connectors)
Monitoring system:
Alarm
Sensors sensor
status On/Off signals,
alarm type
commands, SafeHome
data software Telephone
number line
Control
panel display tones
information
CSE 870: Adavnced Software Engineering
6
Client-‐Server
Architecture
Two
types
of
components:
Server
components
offer
services
Clients
access
them
using
a
request/reply
protocol
Client
may
send
the
server
an
executable
func?on,
called
a
callback
The
server
subsequently
calls
under
specific
circumstances
CSE 870: Adavnced Software Engineering
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)
CSE 870: Adavnced Software Engineering
7
Architectural Design Principles
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:
Distinguish between operational (transactional) and inquiry
systems.
Exploit features of DBMS
CSE 870: Adavnced Software Engineering
Example: Layered architecture
Interactive Graphics Application
Windows Operations
Screen Operations
Pixel Operations
Device I/O Operations
CSE 870: Adavnced Software Engineering
8
Closed Architectures
Each layer is built only in terms
of the immediate lower layer
Reduces dependencies between
layers
Facilitates change
CSE 870: Adavnced Software Engineering
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
CSE 870: Adavnced Software Engineering
9
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
CSE 870: Adavnced Software Engineering
Partitioned Architectures
Divide system into weakly-coupled
subsystems
Each provides specific services
Vertical decomposition of problem
CSE 870: Adavnced Software Engineering
10
Ex: Partitioned Architecture
Operating System
Virtual
File Process Memory Device
System Control Manage- Control
ment
CSE 870: Adavnced Software Engineering
Typical Application Architecture
Application package
Window graphics
User
Simulation
dialogue Screen graphics
package
control
Pixel graphics
Operating system
Computer hardware
CSE 870: Adavnced Software Engineering
11
Taxonomy of System-Design
Decisions
Devise a system architecture
Choose a data management approach
Choose an implementation of
external control
CSE 870: Adavnced Software Engineering
Choosing a Data Management
Approach
Databases:
Advantages:
o Efficient management
o multi-user support.
o Roll-back support
Disadvantages:
o Performance overhead
o Awkward (or more complex) programming
interface
o Hard to fix corruption
CSE 870: Adavnced Software Engineering
12
Choosing a Data Management
Approach (continued)
“Flat” files
Advantages:
o Easy and efficient to construct and use
o More readily repairable
Disadvantages:
o No rollback
o No direct complex structure support
o Complex structure requires a grammar for file format
CSE 870: Adavnced Software Engineering
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
Tools support: Yacc, Lex.
CSE 870: Adavnced Software Engineering
13
Taxonomy of System-Design
Decisions
Devise a system architecture
Choose a data management approach
Choose an implementation of
external control
CSE 870: Adavnced Software Engineering
Implementation of External
Control
Four general styles for implementing software control
Procedure-driven:
Control = location in the source code.
Requests block until request returns
Event-Driven: Control resides in dispatcher
Uses callback functions registered for events
Dispatcher services events by invoking callbacks
CSE 870: Adavnced Software Engineering
14
Implementation of External
Control
Concurrent
Control resides in multiple, concurrent objects
Objects communicate by passing messages
o across busses, networks, or memory.
Transactional
Control resides in servers and saved state
Many server-side E-systems are like this
CSE 870: Adavnced Software Engineering
Sample Concurrent System
target acquisition
target loss
Control
distance Radar
x1: integer
x2: integer v: integer
tinc: integer vc: integer
carspeed vt: integer
vc: integer
vt:integer x: integer
v:integer tmode: booelan
tmin: integer = 2
z1: integer
z2: integer
xhit: integer Car
xcoast: integer carspeed
setspd: integer throttle control setv: integer
a: integer = 15 realv: integer
closing: boolean
CSE 870: Adavnced Software Engineering
15
MVC (Model/View/Controller)
1ST 5
Separates data model,
2nd 10
data view, and behavior
into separate components 3rd 20
4th 40
Model
(data)
change events
Controller
Δ data
(interface for
data changes)
Representation Representation consumer
(view) (view) observable
CSE 870: Adavnced Software Engineering
Dispatcher Model
(event driven)
Process
event type 1
Process
Events Get event, event type 2
call a
procedure
Process
event type N
Window manager & Notifier Application code
CSE 870: Adavnced Software Engineering
16
Event-driven architecture in UI toolkits
Window User-interface Application
manager component code
Widget1 Button
Get events (e.g. Button) Listener
and
dispatch
Widget2 Text
(e.g. TextBox) Listener
Events
Widget3
Listener
(e.g. Dialog)
CSE 870: Adavnced Software Engineering
Typical Dispatcher Code
Event Loop Startup
while (!quit) {
WaitEvent(timeout, id);
switch (id) {
case ID1: Procedure1(); break;
case ID2: Procedure2(); break;
….
}
}
CSE 870: Adavnced Software Engineering
17
Transactional Model
Server Mimics event-driven
System/network
Application/initial
Restore
State manager
state
Application/Classes Dispatch based
on previous state
Object A Object B Object C
CSE 870: Adavnced Software Engineering
General Design Concerns
Modularity
Abstraction
Cohesion
Coupling
Information Hiding
Abstract Data Types
Identifying Concurrency
CSE 870: Adavnced Software Engineering
Global Resources
18
Modularity
Organize modules according to
resources/objects/data types
Provide cleanly defined interfaces
operations, methods, procedures, ...
Hide implementation details
Simplify program understanding
Simplify program maintenance
CSE 870: Adavnced Software Engineering
Abstraction
Control abstraction
structured control statements
exception handling
concurrency constructs
Procedural abstraction
procedures and functions
Data abstraction
user defined types
CSE 870: Adavnced Software Engineering
19
Abstraction (cont.)
Abstract data types
encapsulation of data
Abstract objects
subtyping
generalization/inheritance
CSE 870: Adavnced Software Engineering
Cohesion
Contents of a module should be cohesive
Somehow related
Improves maintainability
Easier to understand
Reduces complexity of design
Supports reuse
CSE 870: Adavnced Software Engineering
20
(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
CSE 870: Adavnced Software Engineering
(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
CSE 870: Adavnced Software Engineering
21
Example: Poor Cohesion
package Output is
procedure DisplayDice( . . .);
procedure DisplayBoard( . . .);
Dice
I/O Output
device
Board
CSE 870: Adavnced Software Engineering
Example: Good Cohesion
package Dice is
procedure Display ( . . .);
procedure Roll( . . .);
Dice
I/O
device
Board
CSE 870: Adavnced Software Engineering
22
Coupling
Connections between modules
Bad coupling
Global variables
Flag parameters
Direct manipulation of data structures by
multiple classes
CSE 870: Adavnced Software Engineering
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, ...
CSE 870: Adavnced Software Engineering
23
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
CSE 870: Adavnced Software Engineering
Information Hiding
CSE 870: Adavnced Software Engineering
24
Abstract data types
Modules (Classes, packages)
Encapsulate data structures and their
operations
Good cohesion
o implement a single abstraction
Good coupling
o pass abstract objects as parameters
Black boxes
o hide data representations and algorithms
CSE 870: Adavnced Software Engineering
Identifying Concurrency
Inherent concurrency
May involve synchronization
Multiple objects receive events at the same
time with out interacting
Example:
o User may issue commands through control panel at
same time that the sensor is sending status
information to the SafeHome system
CSE 870: Adavnced Software Engineering
25
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
CSE 870: Adavnced Software Engineering
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)
CSE 870: Adavnced Software Engineering
26
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
CSE 870: Adavnced Software Engineering
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, . . .
CSE 870: Adavnced Software Engineering
27