Design: HOW to implement a system

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 dont 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
• Dont 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
• 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 (gt20)
• 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
• Can use DFD to model flow
• Some common topologies
• Pipeline (batch)
• Star topology

26
Ex Pipeline Topology
Compiler
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
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/da
  ta types
• Provide cleanly defined interfaces
• operations, methods, procedures, ...
• Hide implementation details
• Simplify program understanding
• Simplify program maintainance

29
Abstraction

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

30
Abstraction (cont.)

• Abstract data types
• 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
• 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
• 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
• 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
• 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, . .
  .