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, . . .