1. Design: HOW to implement a system
Goals:
Satisfy the requirements
Satisfy the customer
Reduce development costs
Provide reliability
Support maintainability
Plan for future modifications

2. Design Issues Architecture User Interface Data Types Operations
Data Representations
Algorithms

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

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

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

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

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

8. Design Principles (cont.)
Define interfaces between modules carefully
Consider how to handle the unexpected
Don’t code!!
Document decisions
Review, review, review . . .

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

10. Subsystem Identification
Divide system into a manageable number of components
Each major component is a subsystem
Subsystem groups components with common properties/function

11. Subsystem Collection of Interrelated Good cohesion Classes
Associations
Operations
Events
Constraints
Interrelated
Good cohesion
Well-defined, small interface with other subsystems
Low coupling
Identified by the service it provides

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

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

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

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

16. Strategies for Decompositions
Layers: Horizontal decomposition
Open
Closed
Partitions: Vertical decomposition
System topology:
General decompositions

17. 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)

18. Example: Layered architecture
Interactive Graphics Application
Windows Operations
Screen Operations
Pixel Operations
Device I/O Operations

19. Closed Architectures
Each layer is built only in terms of the immediate lower layer
Reduces dependencies between layers
Facilitates change

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

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

22. Partitioned Architectures
Divide system into weakly-coupled subsystems
Each provides specific services
Vertical decomposition of problem

23. Ex: Partitioned Architecture
Operating System
Virtual
Memory
Manage-
ment
File
System
Process
Control
Device
Control

24. Typical Application Architecture
Application package
Window graphics
Screen graphics
Pixel graphics
Operating system
Computer hardware
User dialogue control
Simulation package

25. System Topology Describe information flow Some common topologies
Can use DFD to model flow
Some common topologies
Pipeline (batch)
Star topology

26. Ex: Pipeline Topology Compiler: Lexical analyzer Semantic analyzer
source program
Lexical analyzer
Semantic analyzer
token stream
abstract syntax tree
code sequence
object code
Code generator
Code optimizer

27. Ex: Star Toplogy Monitoring system: Alarm Sensors SafeHome software
sensor status
On/Off signals, alarm type
SafeHome software
commands, data
Telephone line
Control panel
number tones
display information

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

29. Abstraction Control abstraction Procedural abstraction
structured control statements
exception handling
concurrency constructs
Procedural abstraction
procedures and functions
Data abstraction
user defined types

30. Abstraction (cont.) Abstract data types Abstract objects
encapsulation of data
Abstract objects
subtyping
generalization/inheritance

31. Cohesion Contents of a module should be cohesive
Improves maintainability
Easier to understand
Reduces complexity of design
Supports reuse

32. (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

33. (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

34. Example: Poor Cohesion
package Output is
procedure DisplayDice( . . .);
procedure DisplayBoard( . . .);
Dice
I/O device
Output
Board

35. Example: Good Cohesion
package Dice is
procedure Display ( . . .);
procedure Roll( . . .);
Dice
I/O device
Board

36. Coupling Connections between modules Bad coupling Global variables
Flag parameters
Direct manipulation of data structures by multiple classes

37. Coupling (cont.) Good coupling Good coupling improves maintain-ability
Procedure calls
Short argument lists
Objects as parameters
Good coupling improves maintain-ability
Easier to localize errors, modify implementations of an objects, ...

38. Information Hiding Hide decisions likely to change Black box
Data representations, algorithmic details, system dependencies
Black box
Input is known
Output is predictable
Mechanism is unknown
Improves maintainability

39. Information Hiding

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

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

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

43. Management of Data Stores
Data stores permit separations between subsystems
Internal or external
Common types of data stores
Files
Databases

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

45. Database Data Stores Advantages Disadvantages Infrastructure support
Common interface
Standard access language (SQL)
Disadvantages
Performance penalty
Awkward programming language

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

47. 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)

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

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

50. External Control Procedure-driven systems Event-driven systems
Concurrent systems

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

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

53. Concurrent Systems Control resides concurrently in independent tasks
Events are implemented as messages between tasks
OS schedules tasks for execution

54. Boundary Conditions Initialization Termination Failure
Constants, parameters, global variables, tasks, guardians, class hierarchy
Termination
Release external resources, notify other tasks
Failure
Clean up and log failure info

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