Software Quality Assurance Problem frames

1
Software Quality AssuranceProblem frames

• Charles Wallace
• Michigan Technological University
• wallace_at_mtu.edu

2
Information problem frame(Jackson, 2000)
real world
a
a
information system
report-world
b
information requesters
c
a RW!WorldInfo b IR!Queries,
IS!Reports c IR!DisplayState
When world state is so-and-so... machine detects
state info... if user then queries world-state
data... machine sends report... causing
appropriate change in display state.
3
Information problem

• real world may be static or dynamic
• follows some rules "laws of nature
• information requesters may be passive
  (predictable queries)
• or active (unpredictable)
• common variation machine-real world connection
  domain
• real world interpreted by sensor or "data-entry"
  person

real world
a S!SensorData b RW!WorldData
b
sensor
a
information system
Usual concerns apply with regard to connection
domains failure, translation, ...
4
Machine must model the real world e.g. patient
modeled as temp, blood pressure, pulse rate
gap between model and real world how accurate
must model be?
requirement If P(rw), then display
"P(rw)". solution create model m If Q(m(rw)),
then display "P(rw)".
may need to ensure that Q(m(rw)) ? P(rw) (no
"false positives") stronger requirement Q(m(rw))
? P(rw)
In dynamic world, frequency of model state
checking affects accuracy e.g. Patient
monitoring medical staff select frequency
Language of events responses between machine
requester Validation rules filtering out invalid
requests
5
Information requesters domain user (autonomous)
display (controlled) Prescriptive
(constraining) reference refers only to I/O
device doesn't make sense to constrain
user Maybe we can break this frame down further
real world
a
a
information system
report-world
c
b
I/O device
Information Display problem
d
d IOD!DisplayState
information requesters
6
Query Validation problem (special case of
Transformation problem)
I/O device
f
f
query validation system
valid-queries
e
information requesters
e
e IR!UserQueries f IOD!SystemQueries
7
Information problem issues

• Objects in the real world (plus attributes and
  relations)
• Real world data to be stored/displayed
• Real world events that may trigger changes to
  query results
• Language of queries
• Distortions arising from data granularity
• Distortions and delays arising from connection
  domains
• System event responses How model changes in
  response to
• machine-detectable events
• Validation rules for real-world and user data
• How queries are entered
• How information is displayed

8
Required behavior problem frame(Jackson, 2000)
behavior rules
a
controller machine
b
controlled domain
a CM!Commands, CD!DomainState b
CD!DomainState
Machine issues commands... (possibly after
considering current domain state
information)... that keep domain in an acceptable
state. Like real world in information
problem, controlled domain follows laws of
nature difference machine can affect domain
state
9
Required behavior problem
If effects of commands are totally
predictable, and only controller affects domain,
then machine needs no state info Can controller
take domain to a state that's no longer
controllable? If so, need to disable certain
sequences of commands Connection domain possible
between controller and controlled domain e.g.
Direction problem machine issues "commands" to
human How confident can we be in effects of
commands?
10
Commanded behavior problem frame(Jackson, 2000)
operator
a
a
controller machine
behavior rules
b
controlled domain
c
a O!OperatorCommands b CM!MachineCommands c
CD!DomainState
"Operator issues commands... machine rejects
non-sensible ones... machine ignores commands
unviable in current domain state... machine
issues sensible, viable commands... which change
the domain state according to the behavior rules."
11
Commanded behavior problem
sensible commands have some reasonable meaning
given the context of previous commands viable
commands have some reasonable meaning given
the current state of the controlled domain
12
Occasional sluice gate control problem(Jackson,
2000)

• A small sluice, with a rising and falling gate,
  is used in a simple
• irrigation system. A computer system is needed
  to raise and
• lower the sluice gate in response to the commands
  of an operator.
• The gate is opened and closed by rotating
  vertical screws.
• The screws are driven by a small motor, which can
  be controlled by
• clockwise, anticlockwise, on and off pulses.
  There are sensors at the
• top and bottom of the gate travel at the top
  it's fully open, at the
• bottom it's fully shut. The connection to the
  computer consists of four
• pulse lines for motor control, two status lines
  for the gate sensors,
• and a status line for each class of operator
  command.

13
Occasional sluice gate problemas a commanded
behavior problem
sluice operator
a
a
sluice controller
raise lower gate
b
gate motor
c
a SO!raise,lower,stop b SC!cw,anticw,on,off,
GM!top,bottom c GM!open,shut,rising,falling
14
Occasional sluice gate problem
stop command not sensible in command
context ... raise, lower, stop, stop raise
command not viable in domain state where gate
already at top
15
Behavior of controlled sluice gate (finite-state
automaton)
idle-midway -rise -fall -open -shut
lower
raise
stop
stop
falling -rise fall -open -shut
rising rise -fall -open -shut
when (shut)
when (open)
lower
raise
idle-bottom -rise -fall -open shut
idle-top -rise -fall open -shut
Is "lower,lower" ever sensible? How about
"lower,raise"?
16
Required/Commanded behavior problem issues

• Objects in the controlled domain (plus attributes
  and relations)
• Causal laws of the controlled domain
• Behavior rules How commands change controlled
  domain
• Language of sensible commands
• Viability conditions
• Distortions and delays arising from connection
  domains
• Mapping Operator commands to machine commands
• System event responses (if domain is being
  modeled)
• Validation rules for commanded-domain and
  operator data
• How commands are entered

17
Workpieces problem frame(Jackson, 2000)
user
a
a
editor tool
edit workpieces
b
workpieces
c
a U!UserCommands b ET!WorkpieceOperations c
WP!WorkpieceState
Workpieces intangible software objects (e.g.
documents, files) designed domain software
creates, destroys domain elements
18
Workpieces problem
Similar to Commanded behavior frame --- but
"controlled domain" here is totally
computer-internal easy(?) to control very often
a designed domain our right/responsiblity to
co-design it Key to workpieces problems define
user commands, workpiece operations, mapping
between them define workpiece format
19
Workpieces problem issues

• Workpiece format
• Language of user commands
• Language of workpiece operations
• Behavior rules How commands change workpieces
• Language of sensible commands
• Viability conditions
• Mapping User commands to workpiece commands
• Validation rules for workpiece and user data
• How commands are entered

20
Transformation problem frame(Jackson, 2000)
source
a
a
mapping
transformer
b
destination
b
a S!InputData b D!OutputData
Source produces input data... Machine responds
with output data that respects the mapping.
21
Transformation problem exampleTree
encodingadapted from (Hamlet Maybee, 2000)
take user-entered text as input and display it as
a tree Q What do you mean by "tree"?
(un)labeled? (un)rooted? A Labeled, rooted,
undirected acyclic graph (Customer would most
likely describe by example)
22
Tree encoding Solution 1
keywords tree, label, root, edge, endtree tree
syntax tree label ( node-ID , node-label ) , ...
root root-node-ID edge ( node-ID , node-ID
) , ... endtree
23
Solution 1 example
tree label (a, degrees), (b, BS), (c, MS), (d,
PhDCS), (e, PhDCSE), (f, BSCS), (g, BSCSS), (h,
BSSE) root degrees edge (a, b), (a, c), (a, d),
(a, e), (b, f), (b, g), (b, h) endtree
degrees
BS
MSCS
PhDCS
PhDCSE
BSSE
BSCS
BSCSS
24
Tree encoding Solution 2

• tree syntax (Node-specification)
  (Node-specification)
• node-specification syntax node-label
  child-node-label ...
• First node-specification defines root
• For subsequent node-specifications, node-label
  must appear
• as a child-node-label in an earlier
  node-specification

25
Solution 2 example
(degrees BS MSCS PhDCS PhDCSE) (BS BSCS BSCSS
BSSE)
degrees
BS
MSCS
PhDCS
PhDCSE
BSSE
BSCS
BSCSS
26
Solution 2
Q Can a child-node-label appear without being
subsequently specified? A Yes --- in this case,
child node has no children
Q What about duplicate labels? e.g. (root a
b) (b a c) (a d) (child of root or child of
b?) A node-specification S with label x is
linked to the nearest child-node-label x
preceding S
root
a
b
a
c
d
27
Transformation problem issues

• Set of valid inputs
• Set of possible outputs
• Mapping Input values to output values
• Validation rules for source data
• Error handling behavior

28
References

• D. Hamlet and J. Maybee. The Engineering of
  Software. Addison Wesley, 2000.
• M.A. Jackson. Software Requirements and
  Specifications. Addison Wesley, 1995.
• M.A. Jackson. Problem Frames. Addison Wesley,
  2000.