1. 6894 · workshop in software design lecture 13 · november 25, 1998 · problem frames
write on board in advance: handouts, names, Hoare quote
do first 6 slides quickly
remember to leave time for students to fill in info sheet: 5m?
don't dwell on first abstraction slide
might not have time for last two abstraction slides

2. motivation two steps of software development
recognize problem as instance of familiar class
select solution method appropriate to class
realistic problems
combine different elementary problems
typically need several methods at once
measure of complexity
count the elementary problems
what makes a system hard is heterogeneity
5/17/2019 daniel jackson

3. example: dynamic information system
solution method
build a model of the real world: including how events change structure
describe queries, spontaneous reports as functions of the model
implement model as a data structure, events as updates, etc
what kinds of problem is this good for?
banking system (yes)
stock portfolio tracker (yes)
biblical concordance (no)
nuclear reactor control (no)
what characterizes the problems it suits?
real world is dynamic (rules out concordance)
real world is autonomous (rules out reactor)
what happens if you apply it to the wrong problem?
may still manage, but tool doesn’t fit job
reactor’s feedback loop is not addressed: can’t analyze safety
set up of concordance is kludged
5/17/2019 daniel jackson

4. desiderata analysis of problems
given a problem, want to identify its class
identifying misfits crucial
what do the edges look like?
details of how problem doesn’t quite fit are crucial
what won’t work
informal taxonomy
too subjective, hard to use
doesn’t address the edges
solution repertoire
ie, define classes by their solutions
GOF design patterns does this to some extent
but circular, and doesn’t cover wide variety of problems
what’s needed
general and abstract way to describe problems
can describe individual problems
can show relationships between problems
5/17/2019 daniel jackson

5. polya’s book a great little book
G. Polya, How To Solve It, Princeton, 1957
a manual for solving mathematical problems
largely based on the work of the Greeks (eg, Pappus)
many of our words related to problem solving are Greek
analysis, synthesis, method, system, theorem, heuristic, etc
basic insight
first you must know what kind of problem you face
then you can apply a systematic approach
Greeks divided problems into
problems to prove
problems to find
each kind of problem has
principal parts, related in a structure (or “problem frame”)
a solution task posed in terms of the parts
5/17/2019 daniel jackson

6. problems to prove example prove that
if the four sides of a quadrilateral are equal,
then its diagonals bisect each other
principal parts
hypothesis
the 4 sides of a quad are equal
conclusion
its diagonals bisect each other
solution task
demonstrate the conclusion from the hypothesis
recommended methods
try to think of a problem with the same conclusion
ask whether the problem is more likely to be true or false, given the hypothesis
consider what other conclusions follow from the hypothesis
5/17/2019 daniel jackson

7. problems to find example given: three lengths a, b and c
construct: a triangle whose sides are of those lengths
principal parts
unknown
a triangle
data
three lengths: a, b and c
condition
the three sides of the triangle are of the three lengths
solution task
find the unknown
recommended methods
split the condition into parts
think of a problem with a similar unknown
check that you’re using all the data
think of a variation of the unknown, or of the data, or both, so that the new unknown and the new data are nearer to each other
5/17/2019 daniel jackson

8. problem frames
idea
use Polya’s approach to characterize software problems
principal parts, solution tasks, recommended methods
basic elements
domains
may represent real world phenomena, machines, descriptions
conditions
may represent know invariants, requirements, etc
frames
particular structures of domains and conditions
elementary & composite
elementary frames
very simple
composite frames
parallel compositions of elementary frames
5/17/2019 daniel jackson

9. the general software development problem
elements
two domains
the machine
the world
one condition
the requirement
method
describe the requirement R (optative)
describe the world W (indicative)
design a specification S (optative)
show that W & S implies R
more radical than it seems. why?
Requirement
The Machine
The World
5/17/2019 daniel jackson

10. domains domains divide the world into domains Created each domain has
phenomena
characteristics
domains are linked
by sharing of phenomena
domain roles
domains may be
given (exist independently of system)
created (by system)
descriptions (of other domains maybe)
Created
Domain
Given
Domain
Condition
5/17/2019 daniel jackson

11. classifying phenomena
individuals
values
strings, social security numbers
entities
people, bicycles
events
pressing of elevator button
relations
truths: unchanging
5 > 3
states: may change
Likes (DJ, Thanksgiving)
roles: indicate participation of individual in event
IsButtonPress (b, p)
control
+p domain initiates phenomenon p
- p domain inhibits p
= t domain establishes truth t
5/17/2019 daniel jackson

12. simple control frame sets of phenomena C1 controlled by M
C2 controlled by C
C3 described by R
why C must be described
generally C1 != C3
when this frame breaks down
C1 cannot be determined from C2 alone
M: +C1
Required Behaviour R
Machine M
Controlled Domain C C3
C: +C2
5/17/2019 daniel jackson

13. information display frame
basic problem
machine maintains display about a connected part of the real world
note
again, note that S1 and S2 not the same as C1, C2
M: +C1
Display Rules R
Machine M
Information Display D S1 S2
Real World R
R: +C2
5/17/2019 daniel jackson

14. domain characteristics
domain controls its shared phenomena?
yes, all: domain is autonomous
no, none: domain is passive
some: domain is reactive
domain has state phenomena?
yes: dynamic
no: static
other terms
inert: reacts, but never initiates
controllable: phenomena can be controlled from outside
biddable: controllable to some degree
tangible: phenomena are physical
5/17/2019 daniel jackson

15. example: Parnas’s 4-variable model
MACHINE
INPUT: +IN
MACHINE: +OUT
INPUT
OUTPUT
WORLD
OUTPUT: +CONTROLLED
WORLD: +MONITORED
REQMT
5/17/2019 daniel jackson

16. example: package router
PACKAGES
CORRECT ROUTING
INFORMANT
ROUTER TOPOLOGY
SWITCHES & SENSORS
MATCH
MACHINE
ROUTER TOPOLOGY
MODEL
MACHINE
5/17/2019 daniel jackson

17. CTAS frame? domains PLANES AIRSPACE CONFIG CONTROLLERS HOST conditions
DISPLAY (tracks, etc)
COMPUTE (etas, rtas)
5/17/2019 daniel jackson

18. critique are frames at right level of granularity?
is phenomenological viewpoint the right one?
what’s omitted from a problem frame?
are frames composable?
can frame be constructed easily by domain expert?
should machine appear in frame?
5/17/2019 daniel jackson

19. references
M. Jackson. Software Development Method. In A Classical Mind, Essays in Honour of C.A.R. Hoare, ed. Roscoe, Prentice Hall 1994.
M. Jackson. Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices. Addison-Wesley, 1995.
C. Gunter, M. Jackson, P. Zave. A Reference Model for Requirements and Specifications. see
G. Polya. How To Solve It, Princeton, 1957
Lakatos. Proofs and Refutations, Cambridge, 1976
5/17/2019 daniel jackson