CSE 5324: Software Engineering I
(Analysis, Design, Creation)
Fall 1997
Design - Methods of Design
What is design?
Why design?
Makes Implementation Mechanical
Different from Requirement or Code
How is design done:
Many methods:
Structured
OO
Etc.
Goal:
Define process (or system) in enough detail to
Implement. (Create, realize)
What is designed:
Data
Architecture
Interface
Procedural
Data design:
Wasserman:
"Select logical representations of data objects"
Should apply same analysis principles as
applied to function
Identify data structures and operations
performed on them
Data dictionary
Defer low-level data decisions
Hide data representation in modules
Develop library of data structures and operations
(reuse)
Use appropriate programming language
Architecture design:
Develop modular program structure and show
control relationships
This is very important: this shows the "outline" of
the entire system.
(This started from "top-down" and "structured-
programming" and "modular" ideas of late 1960’s
and early 1970’s)
Data-flow oriented design:
Natural flow from analysis
Find type of information flow
Find flow boundaries
Map DFD to program flow
Factor control
Refine structure
Find type of information flow
Transform Flow
Transaction Flow
Transform Flow
Incoming flow -> Transform center ->
Outgoing flow
Overall flow is sequential, one of few paths
Look at DFD for few (one) straight line paths
Transaction Flow
Data Item triggers other flows
Select from many paths
Transaction->Transaction Center->
->Many
->Paths
In most systems BOTH flows are present.
(Find flow boundaries)
Map DFD to program flow
Transform Mapping – DFD with Transform Flow
mapped to template for program structure
Design Steps:
Review Level 0 DFD (system spec and SRS)
Refine Data Flow (Show Details)
Is DFD transform or transaction?
Find and isolate transform center (find
in and out flow boundaries )
Do a first level factoring
(top down distribution of control)
Do a second level factoring
(individual DFD bubbles to modules)
Refine using heuristics for design
Transaction Mapping:
Similar to above, BUT
Find transaction center
Factoring is on path basis
Afterwards:
Need to describe processing for each module
Describe Interfaces
Local and Global Data structures
Note Limits, Restrictions
Review
Optimize
Design Optimization:
Knuths Law: "Don’t"
Use CASE tools
Analyze hot spots (time hogs), use appropriate
Algorithms
Use appropriate programming Language
Use instrumentation to find heavy loaded
modules: SW or HW
Redo those
Interface Design:
Internal
External
Human
Some guidelines:
Simplify information passing
No globals
Validate data
Error handling and propagation: fix it,
or pass it up.
User Interface
KISS
WIMP (?)
Who are users?
User Model
Experiences, other background
Novices, intermittant, frequent users
Design Issues:
HELP:
How can User get "Help"?
Is help available for all functions?
Which?
How to show help?
How to get out of help?
ERRORS:
How to show error messages
Provide some advice
Indicate any unexpected: (File lost, etc)
Don’t blame User
COMMANDS:
Short cuts
Menus
Customization
Offer feedback (when slow, etc.)
Hints:
Iterate
Prototype
Use tool kits
USE IT!
User Interface Guidelines:
General:
Be consistent
Undo
Make destruction difficult
Display:
Show (only) important info
Be consistent, predictable
Compartmentalize
Show analog displays (guage)
Data Input:
Minimize
Consistent
Let user control flow
Customize
Procedural Design:
Structured:
Sequence, condition, repetition
Graphical:
Flow Chart
Nassi-Shneiderman
Tables:
Decision Tables: (Like PLA’s)
PDL (Program Design Language)
Pseudocode, structured English
Combined:
CSD (Control Structure Diagram)
(Mostly with CASE tools)
Why is design Important?
Is Structured Design the way to go?
Pro:
Popular
Fits with SA
Lots of Experience
Tools
The way you think
Flexible
Cons:
Like SA
Is OO more "natural"
Easy to omit, forget, etc. functions
Maintenance
Why Design at all?