Chapter 14: Design Method
---data and architectural design
Design -- A multistep process in
which representations of data
structure, program structure,
interface characteristics, and
procedural detail are synthesized.
S/W Architecture
Structure(s) of the system, which
comprise s/w components, the
externally visible properties of those
components, and the relationships
between them
2
October 2003 SRIMCA
S/W Architecture
Analyze the effectiveness of the design
in meeting its stated reqs.
Consider architectural alternatives at a
stage when making design changes is
still relatively easy.
Reducing the risks associated with the
construction of the s/w.
3
October 2003 SRIMCA
Why is Architecture important?
Enabler for comm. between parties
(stakeholders).
Highlights early design decisions which
affect all s.e. work that follows, resulting
into success of the system as operational
entity.
Constitutes a relatively small, whole model
of how the system is structured and how
components work together.
4
October 2003 SRIMCA
Data Design
What is data design?
Transform the information domain model
created during analysis into data structure
required to implement the software
Well-designed data lead to better program
structure and modularity, reduced
procedural complexity
5
October 2003 SRIMCA
Data Design Process
Define data structures identified during the
requirements and specification phase.
Often base decision on algorithm to be used.
Identify all program modules that must
operate directly upon the data structure
Constrain the scope of effect of data design
decisions
Or, from OO perspective, define all
operations performed on the data structure
6
October 2003 SRIMCA
Principles of Data Design
The systematic analysis principles applied
to function and behavior should also be
applied to data
All data structures and the operations to be
performed on each should be identified.
7
October 2003 SRIMCA
Principles of Data Design
A data dictionary should be established and
used for both data and program design
Low-level data design decisions should be
deferred until late in the design process
The representation of data structures should
be known only to those modules that must
make direct use of the data contained within
the structure.
Information hiding
8
October 2003 SRIMCA
Principles of Data Design (cont.)
A library of useful data structures and
the operations that may be applied to
them should be developed. – Reuse
The software design and programming
languages should support the
specification and realization of abstract
data types.
9
October 2003 SRIMCA
Architectural Styles
What is an architectural style?
A set of components than perform a function required by
the system
A set of connectors that enable communication, co-
ordination and co-operation among components.
Constraints that define how components can be
integrated to form the system.
Semantic models that enable designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.
10
October 2003 SRIMCA
Architectural Styles
Taxonomy of styles
Data-centered architectures
Data-flow architectures
Call and return architectures
– Main Program/Subprogram
– Remote procedure call
Object-oriented architectures
Layered architectures
Organization and refinement
Control
Data
11
October 2003 SRIMCA
Architectural Design
Objective
develop a modular program structure and represent
control relationships between modules
Data flow-oriented design
amenable to a broad range of applications
very useful when information is processed sequentially,
such as microprocessor control application; complex,
numerical analysis procedure; etc.
two approaches (transform and transaction mapping)
12
October 2003 SRIMCA
Architectural Design Process
Six-step Process
the type of information flow is established
flow boundary are indicated
data flow diagram is mapped into program
structure
control hierarchy is defined by factoring
resultant structure is refined using design
measures heuristics
the architectural description is refined and
elaborated.
13
October 2003 SRIMCA
(cont.)
Transform Flow
incoming flow outgoing flows
A transform B
center C
14
October 2003 SRIMCA
(cont.)
Transaction Flow
Transactio
n Action
T paths
Transaction
center
15
October 2003 SRIMCA
Transform Mapping
Allow data flow diagram(DFD) with
transform flow characteristics to be
mapped into a predefined template for
program structure
16
October 2003 SRIMCA
Level 0 Safehome DFD
17
October 2003 SRIMCA
Level 1 Safehome DFD
18
October 2003 SRIMCA
Level 2 Safehome DFD - Monitor
19
October 2003 SRIMCA
Transform Mapping (cont)
Design steps
Step 1. Review the fundamental system model.
Step 2. Review and refine data flow diagrams
for the software.
Step 3. Determine whether DFD has transform
or transaction flow characteristics.
– in general---transform flow
– special case---transaction flow
20
October 2003 SRIMCA
Level 3 DFD for Monitor Sensors
21
October 2003 SRIMCA
Transform Mapping (cont)
step 4. Isolate the transform center by
specifying incoming and outgoing flow
boundaries
different designers may select slightly differently
transform center can contain more than one bubble.
step 5. Perform “first-level factoring”
program structure represent a top-down distribution
control.
factoring results in a program structure(top-level,
middle-level, low-level)
number of modules limited to minimum.
22
October 2003 SRIMCA
First Level Factoring
23
October 2003 SRIMCA
Transform Mapping (cont)
step 6. Perform “second-level factoring”
– mapping individual transforms(bubbles) to
appropriate modules.
– factoring accomplished by moving outwards
from transform center boundary.
step 7. Refine the first iteration program
structure using design heuristics for
improved software quality.
24
October 2003 SRIMCA
Second Level Factoring
25
October 2003 SRIMCA
First-Cut Program Structure
26
October 2003 SRIMCA
Refined Program Structure
27
October 2003 SRIMCA
Transaction Mapping
A single data item triggers one or more information flows
28
October 2003 SRIMCA
Transaction Mapping Design
Step [Link] the fundamental system model.
Step [Link] and refine DFD for the software
Step [Link] whether the DFD has transform
or transaction flow characteristics
Step 4. Identify the transaction center and flow
characteristics along each of the action paths
– isolate incoming path and all action paths
– each action path evaluated for its flow characteristic.
29
October 2003 SRIMCA
Transaction Mapping (cont)
step 5. Map the DFD in a program
structure amenable to transaction
processing
incoming branch
– bubbles along this path map to modules
dispatch branch
– dispatcher module controls all subordinate action
modules
– each action path mapped to corresponding
structure
30
October 2003 SRIMCA
Transaction Mapping
31
October 2003 SRIMCA
First Level Factoring
32
October 2003 SRIMCA
First-cut Program Structure
33
October 2003 SRIMCA
Transaction Mapping (cont)
step 6. Factor and refine the transaction
structure and the structure of each
action path
step 7. Refine the first iteration program
structure using design heuristics for
improved software quality
34
October 2003 SRIMCA
Design Postprocessing
A processing narrative must be developed for
each module
An interface description is provided for each
module
Local and global data structures are defined
All design restrictions/limitations are noted
A design review is conducted
“Optimization” is considered (if required and
justified)
35
October 2003 SRIMCA
Interface Design
Interfaces between software modules
Interfaces between software and non-
human producers and consumers
For example, sensors and actuators
Interfaces between the human and
computer
37
October 2003 SRIMCA
INTERNAL & EXTERNAL
INTERFACE DESIGN
Intermodular interface design
DFDs show data flow between modules
Arrows map into parameters in and out of
interface
Determine functions & procedures
using/producing the data
External interface design
Typically involves both hardware & software
Often supplied by vendor, e.g., A/D boards
Often complex functionality
Data validation and error handling
October 2003 SRIMCA
HCI DESIGN MODELS
Design Model - data, architectural, interface,
and procedural representations
User Model - profile of end user,
categorization as novice, intermittent, or
frequent user & expert
System Perception - user’s model; end
user’s mental image of the system
System Image - outward appearance and
supporting information
October 2003 SRIMCA
The User Interface Design Process
User, task, and environment
analysis and modeling
Interface design
Interface construction
Interface validation
October 2003 SRIMCA
TASK ANALYSIS & MODELING
Define and classify tasks
Stepwise elaboration
Establish goals and intentions for task
Map goal to sequence of actions as it will
be executed through the interface
Specify action sequence
Indicate state of the system
Define control mechanism and effects on
system state
Indicate how user interprets system state
October 2003 SRIMCA
DESIGN ISSUES
System response time - primary user complaint
Length
Variability
User help facilities - integrated vs. add-on
Scope
Access methods
Representation
How return to normal process
Structure
October 2003 SRIMCA
DESIGN ISSUES - CONTINUED
Error information handling - reduce user
frustration
Understandable language
Constructive advice
Negative consequences of error
Audible or visible cue
Nonjudgmental (don’t call user an idiot)
Command labeling - hot keys vs. point and click
Scope
Form
Ease of use
Customization or abbreviation
October 2003 SRIMCA
DESIGN EVALUATION
Length and complexity of written specification
Number of commands, average number of
arguments per command, operations per
action
Number of actions, commands, and system
states -- memory load on user
Interface style, help facilities, and error
handling protocol
October 2003 SRIMCA
DESIGN EVALUATION
45
October 2003 SRIMCA
DESIGN GUIDELINES -
GENERAL INTERACTION
Be consistent
Offer meaningful feedback
Ask for verification of any destructive action
Permit easy reversal of actions
Reduce amount of information to be memorized
Seek efficiency in dialog, motion, and thought
Forgive mistakes
Categorize activities and organize
geographically
Provide help facilities
Use simple action verbs to name commands
October 2003 SRIMCA
DESIGN GUIDELINES -
INFORMATION DISPLAY
Display only information relevant to current
context
Use format that enables rapid assimilation of
information
Use consistent labels, abbreviations, and colors
Allow user to maintain visual context
Produce meaningful error messages
Use text formatting to aid understanding
Compartmentalize information
Use analog displays when appropriate
Use screen geography efficiently
October 2003 SRIMCA
DESIGN GUIDELINES -
DATA INPUT
Minimize number of input actions
Maintain consistency between display and input
Allow user to customize input
Allow for flexible interaction
Deactivate commands not relevant in current
context
Let user control interactive flow
Provide help
Eliminate unnecessary input
October 2003 SRIMCA
SUMMARY
THE INTERFACE TRIAD
Be good to your users
Do not deceive your users
Allow your users to use his/her mind to its
greatest potential
In other words:
Use common sense
Do undo your users as you would have
others do undo you
October 2003 SRIMCA
PROCEDURAL DESIGN
Basic constructs
Sequence, condition and repetition
Notations
Flow charts
Tabular
Program Description Language
50
October 2003 SRIMCA
FLOWCHARTS
51
October 2003 SRIMCA
TABULAR NOTATION
52
October 2003 SRIMCA
PROGRAM DESCRIPTION LANGUAGE
REPEAT UNTIL activate switch is turned off
reset all [Link] and swtiches;
DO FOR [Link] = smoke, fire, water, temp, burglar;
READ address [[Link]] [Link];
IF [Link] > bound[[Link]]
THEN [Link] = message [[Link]];
set [Link] to “on” for [Link];
PARBEGIN
CALL alarm PROCEDURE WITH “on”, time in sec.
CALL phone PROCEDURE WITH mess [[Link]],
[Link];
... 53
October 2003 SRIMCA
CONTROL STRUCTURE DIAGRAM
54
October 2003 SRIMCA