6. Basic Methods II Overview 6.1 Models 6.2 Taxonomy 6.3 Finite State Model 6.4 State Transition Model 6.5 Dataflow Model 6.6 User Manual [ §6 : 1 ]
Download
Report
Transcript 6. Basic Methods II Overview 6.1 Models 6.2 Taxonomy 6.3 Finite State Model 6.4 State Transition Model 6.5 Dataflow Model 6.6 User Manual [ §6 : 1 ]
6. Basic Methods II
Overview
6.1 Models
6.2 Taxonomy
6.3 Finite State Model
6.4 State Transition Model
6.5 Dataflow Model
6.6 User Manual
[ §6 : 1 ]
6.5 Dataflow Model
Need to go past data modeling to discuss data storage, flow, etc.
E.g., Process Control Applications
Environment (abstract external interfaces)
inputs (data and events) are stimuli
outputs are externally visible responses
System (software functionality)
the system maintains a certain amount of data
the system’s response to inputs is a complex set of internal actions and
external outputs
[ §6 : 2 ]
Model
Dataflow diagrams notation
functions—deterministic
input/output transformations
triggered by the presence of
all needed inputs
flows—unbounded queues
stores—global system data
terminators—interface
models
minispecs—semantics of
the lowest level functions
Top-down functional
decomposition provides a
complexity control
mechanism
Data dictionary tracks the
(global) names and their
interpretation
Execution model
fully concurrent
interpretation (any change
can occur asynchronously)
explicitly marked critical
sections (restricts
concurrency)
stimulus/response
interpretation (reactive)
[ §6 : 3 ]
Notation
operator
verify
customer
customer
file
phone
order
update
customer
data
customers
item
mailing
address
update
stock
item
profile
inventory
order
prepare
order
shipping
[ §6 : 4 ]
Documentation
1. Introduction
2. General description
3. Specific requirements
…
3.1 Context diagram
- system and its environment
- terminator definitions
3.2 Dataflow diagrams
4. Performance requirements
- hierarchical decomposition
of functions, inputs, outputs
5. Design constraints
- minispecs for lowest-level
functions (e.g., pseudocode)
6. Attributes
7. Other requirements
3.3 Data dictionary
- Layout of flows and stores
[ §6 : 5 ]
Critique
Semantics of dataflow is often left undefined
atomicity (granularity of actions)
fairness (scheduling)
Concurrent semantics are complex and may allow race
conditions to occur
The lack of minispecs for the high-level functions makes
analysis and precise understanding difficult
The diagrams are easy to understand only when the complexity
is low, the development cost is high, and the communication
bandwidth may be low
Improper abstraction for the terminators leads to complex
specifications (e.g., repetition for related interface scenarios)
[ §6 : 6 ]
Complexity Control
Hierarchical
decomposition
Horizontal partitioning
Terminators can become abstract
objects
Stores can become abstract data
objects
Messages can become objects
All objects may be instances of
classes
Classes may be defined in terms of
each other by employing inheritance
Reduces repetition, duplication
Inheritance and instance diagrams
can by used to capture the relations
among classes and objects
[ §6 : 7 ]
Case Study: Train Routing
switch
Consider a system designed to
route trains automatically
setting
Upon arrival at some light
train is assigned a new route
location
Train
Router
which takes it to the next light
The system selects proper position
for each switch along the route.
detector
directive
light
route
station
[ §6 : 8 ]
Case Study: Train Routing
Data stores
network layout
traffic
Stimuli
arrival at a light
unlock side protection lights
identify blocked trains
reprocess their routes
get new route
lock side protection lights on red
turn light green (if successful)
[ §6 : 9 ]
6.6 User Manual
For Applications Involving Human Interfaces
Effective specifications often require the integration of
multiple related models
Human/computer interactions are too complex for
commonly used requirements techniques
The User Manual can be used as a substitute for
(and/or can grow out of) large sections of the SRS
[ §6 : 10 ]
Documentation
1. Introduction
2. General description
3. Specific requirements
…
4. Performance requirements
5. Design constraints
6. Attributes
7. Other requirements
3. Specific requirements
- conceptual model
3.1 Navigation
- screen/window types and
flows among them
- common interactions
3.2 Screens/windows
- layout and information
contents
- command semantics
[ §6 : 11 ]
Navigation
Identify the screens/windows
Define permitted transitions
among them as a graph
Identify the events that
trigger moves from one
screen/window to another
Identify interactions common
among screens/windows
specific to the user interface
paradigm in use
[ §6 : 12 ]
Conceptual Model
A mental map
Helps the user anticipate
system behavior (navigation,
information, commands)
“Principle of least surprise”
open dispatch
record
similar dispatch
records
"note pad"
" copies of filed
records"
Metaphors
Effective tools for building
conceptual models
Draw on users’ previous
experience
open record
followed by the
visited dispatch
records
remaining
similar dispatch
records
" three ring
binder"
[ §6 : 13 ]
Screen/Window Specifications
Maximize readability (of both
layout and structure)
Optimize performance for the
typical workflow
simplicity
regularity of structure
minimality
Minimize potential for user
errors (in both interactions
and general feel)
Design for the common cases
Ensure “happy path” works
well
Engineer each screen and also
the entire ensemble
predictability
uniformity
forgiveness
Grid based design (next slides)
Design for exceptional cases
Allow out-of-order sequences
(as appropriate)
[ §6 : 14 ]
Ad-Hoc Solution
logout
clear
file
12:23 pm
10/26/96
dipatcher
Dana R. Logmire
id ...
up
id ...
down
id ...
name
phone
mark
address
name
phone
notes
address
notes
AMBEX
[ §6 : 15 ]
A Grid-based Design
logout
A
B
E
X
up
12:23 pm
id ...
10/26/96
id ...
dipatcher
id ...
down
Dana R. Logmire
name
name
phone
phone
address
address
notes
notes
clear
file
mark
[ §6 : 16 ]
Final Design
logout
A
B
E
X
up
12:23 pm
id ...
10/26/96
id ...
dipatcher
id ...
down
Dana R. Logmire
name
name
phone
phone
address
address
notes
notes
clear
file
mark
[ §6 : 17 ]
Multiple Models
If the user manual cannot capture all functional aspects
of the system, then a second model is needed
Consistency must be maintained
The state representation should be that used in the SRS
(common abstract state)
User commands are specified only once (as state
transitions over the abstract state of the system)
State information needed for screen presentation is
assumed to be directly available
[ §6 : 18 ]
Multiple Models
User
Manual
S RS
other
interf aces
user
interf ace
abstract
state
user
command
[ §6 : 19 ]
Building on the SRS
User interface complexity
if mainly due to navigation
and interaction patterns,
postpone development until
SRS is completed
User
Manual
user
interf ace
data entity names
state transition names
Data and transition names
Can be used directly as in
the SRS when needed
S RS
other
interf aces
[ §6 : 20 ]
Case Study: Paint Dryer
Consider a controller for a paint
drying oven application
Painted parts enter the oven
one at a time
Control software ensures that
the part is dried at a specified
temperature for a specified
duration before leaving the oven
The operator can override the
duration or temperature for
custom parts
System monitors duration and
temperature settings and allows
for changes in these settings
Only one setting is used at any
one time
Production costs may limit the
interface to a simple display
(e.g., data window + 2 buttons)
Drying Oven
[ §6 : 21 ]