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 ]