Presented at NDC 2011 in Oslo (9th June 2011) Video available via http://www.softdevtube.com/2011/11/01/framing-the-problem/ The focus of software development and technology tends to be very solution–centric, often at the expense or in the absence of a proper understanding of what problem is to be solved. Without necessarily intending to, developers, architects and other technical roles often try to force the problem domain into code–based thinking. Business analyst says number, developer hears int, double or decimal. Customer says stock data, architect hears database. The problem domain and motivation are often abstracted away altogether or too early in the technical solution process. This session takes a look at ways of characterising system types and organising problems, so that problem domains are understood on their own terms. In addition to classic analysis techniques, problem frames are examined as a tool for structuring the phenomena that technical solutions need to express.

1. Framing the Problem
Kevlin Henney
kevlin@curbralan.com
@KevlinHenney

2. See http://programmer.97things.oreilly.com
(also http://tr.im/97tepsk)
and follow @97TEPSK

3. A criticism often leveled at
software development is that,
individually and culturally, it is
often too solution-centric [...].
Either the world of the solution
absorbs software developers to
the detriment of the problem be
solved or, in more extreme
cases, solutions precede the
problems that they might solve:
there sometimes appears to be
an abundance of ‘solutions’ in
search of a problem.

4. We know that every pattern is an instruction of the general form:
context  conflicting forces  configuration
So we say that a pattern is good, whenever we can show that it
meets the following two empirical conditions:
1. The problem is real. This means that we can express the problem
as a conflict among forces which really do occur within the
stated context, and cannot normally be resolved within that
context. This is an empirical question.
2. The configuration solves the problem. This means that when the
stated arrangement of parts is present in the stated context, the
conflict can be resolved, without any side effects. This is an
empirical question.
Christopher Alexander, The Timeless Way of Building

5. So, even within the world of patterns,
which intentionally promote friendly
relations between the worlds of the
problem and the solution, there is often
still a lingering solution bias that
assumes a proper understanding of the
problem domain [...].
The common, stock answer to all of this
is to adopt a prescribed method that
has, within its lifecycle, an extensive
analysis activity that follows one
specific particular school of thought.
[...] Many such approaches, however,
can end up resembling more of a
synthesis (composing a solution to a
problem) than an analysis
(understanding the problem), trying to
shoehorn a problem into a view that
does not fit comfortably.

6. Description and Prescription
 Describing is not the same as
prescribing
 Indicative properties assert facts about
a domain
 Optative properties express a desired
outcome that one has on a domain,
i.e., requirements
 The distinction is subtle but important

7. Requirements come in many possible flavours, but are
commonly cast into two categories: functional and non-
functional requirements. As a label, it has to be admitted
that non-functional is fairly lame. It is unhelpfully vague
and amusingly ambiguous.
Most things that are non-functional don’t work: washing
machines, cars and programs that are non-functional are
broken. Also, by prefixing functional requirements with non,
other requirements seem to be relegated to second- or
third-class citizenship.
Requirements can be better and more fairly considered
under the headings of functional requirements, operational
requirements and developmental requirements.
Kevlin Henney, "Inside Requirements"

8. An abstract model (or conceptual model) is a theoretical
construct that represents something, with a set of variables
and a set of logical and quantitative relationships between
them. Models in this sense are constructed to enable reasoning
within an idealized logical framework about these processes
and are an important component of scientific theories.
Idealized here means that the model may make explicit
assumptions that are known to be false (or incomplete) in
some detail. Such assumptions may be justified on the grounds
that they simplify the model while, at the same time, allowing
the production of acceptably accurate solutions.
http://www.wikinfo.org/index.php/Model_(abstract)

9.  A given model will emphasise one
perspective at the expense of others
 Good abstraction omits irrelevant
detail
 Poor abstraction omits necessary detail
or retains unnecessary detail
 The identification of (in)appropriate
detail is key to effective modelling
Model Properties

10. To deal with a significant problem
you have to analyse and structure it.
That means analysing and
structuring the problem itself, not
the system that will solve it. Too
often we push the problem into the
background because we are in a
hurry to proceed to a solution. If
you read most software
development texts thoughtfully,
you will see that almost everything
is about the solution; almost
nothing is about the problem.

11. Context Diagrams
 Context diagrams offer a big picture
of the world around the software
 They are not use case diagrams
 They are not architectural diagrams
 Different approaches, from
intentional to physical, can be used
 UML "use–case-less" diagrams, DFD-
centred diagrams, etc.

12. Jackson Context Diagram
Heating
Controller
Operator Furnace
Heating
Plan
Heated
Rooms
The machine domain
A designed domain
A given domain

13. Kinds of Domains
Heating
Controller
Operator Furnace
Heating
Plan
Heated
Rooms
B
X
C
C
A lexical domain
A biddable domain A causal domain

14. Shared Phenomena
Heating
Controller
Operator Furnace
Heating
Plan
Heated
Rooms
B
X
C
C
Temperature
Temperature Knob
Water Flow
Water Heat
Flame On
Flame Off
Flame State
Pump On
Pump Off
Water Temperature
Room
Start Time
End Time
Enter Room
Enter Start Time
Enter End Time

15. phenomenon (plural: phenomena):
An element of what we can observe in
the world. Phenomena may be
individuals or relations. Individuals are
entities, events, or values. Relations
are roles, states, or truths.
individual: An individual is a
phenomenon that can be named and
is distinct from every other individual:
for example, the number 17, George
III, or Deep Blue's first move against
Kasparov.
relationship: A kind of phenomenon.
An association among two or more
individuals, for example, Mother(Lucy,
Joe). Also, generally, any pattern or
structure among phenomena of a
domain.

16. Events. An event is an individual
happening, taking place at some particular
point in time. Each event is indivisible and
instantaneous.
Entities. An entity is an individual that
persists over time and can change its
properties and states from one point in
time to another.
Values. A value is an intangible individual
that exists outside time and space, and is
not subject to change.
States. A state is a relation among
individual entities and values; it can
change over time.
Truths. A truth is a relation among
individuals that cannot possibly change
over time.
Roles. A role is a relation between an
event and individuals that participate in it in
a particular way.

17. Subproblems
 A subproblem is a projection or slice
of the whole problem space
 A subproblem may correspond to a set
of use cases or features, or the
operation of some domain
 Requirements are relationships or
constraints imposed on a domain or
between domains

18. Problem Diagrams
Heating
Controller
Operator
Heating
Plan
B
X
Heating
Plan Entry
Rules
Requirements
imposed on a slice of
the problem space

19. A problem frame is a
generalization of a class of
problem. If there are many
other problems that fit the
same frame as the problem
you’re dealing with, then you
can hope to apply the method
and techniques that worked
for those other problems to
the problems you’re trying to
solve right now.

20. Control
Machine
Controlled
Domain
C
Required
Behaviour
Required behaviour: there is some part of the physical world
whose behaviour is to be controlled so that it satisfies certain
conditions. The problem is to build a machine that will impose
that control.

21. Control
Machine
Operator
Controlled
Domain
B
C
Commanded
Behaviour
Commanded behaviour: there is some part of the physical
world whose behaviour is to be controlled in accordance with
commands issued by an operator. The problem is to build a
machine that will accept the operator’s commands and
impose the control accordingly.

22. Information
Machine
Display
Real
World
C
C
Display ~
Real World
Information display: there is some part of the physical world
about whose states and behaviour certain information is
continually needed. The problem is to build a machine that
will obtain this information from the world and present it at
the required place in the required form.

23. Editing
Tool
User
Work
Pieces
B
X
Command
Effects
Simple workpieces: a tool is needed to allow a user to create
and edit a certain class of computer-processable text or
graphic objects, or similar structures, so that they can be
subsequently copied, printed, analysed or used in other ways.
The problem is to build a machine that can act as this tool.

24. Transform
Machine
Outputs
Inputs
X
X
I/O Relation
Transformation: there are some given computer-readable
input files whose data must be transformed to give certain
required output files. The output data must be in a particular
format, and it must be derived from the input data according
to certain rules. The problem is to build a machine that will
produce the required outputs from the inputs.

25. Frame Applicability
 Whether you use Jackson's frames
directly or not is not the concern
 And, similarly, whether you choose to
use them formally or informally
 The value is in slicing up and
characterising the problem space
 Different kinds of problem have their
own terms of description

26. Bounding the problem is an
important ingredient in successful
software development. A pattern-
based approach aims to do this by
understanding the forces within a
given context that give rise to the
problem that the pattern’s solution
part resolves. There is no formal
guidance, however, for identifying
the context, its forces, and the
motivation that gives rise to the
problem.

27. In contrast, problem frames propose a
discipline for talking about and
delimiting the world of the problem
without involving or being distracted by
solution specifics. Within a given
problem frame there are likely to be
some patterns that are readily
applicable at a strategic level and some
that are not. For example, within a
composite frame comprising Simple
Workpieces and an Information
Display, Model–View–Controller
suggests itself as such a strategic
pattern, defining the core shape and
style of the architecture.

28. Composite Frames
 Realistic problems typically
embrace many frame concerns
 E.g., consider the frames involved in a
browser or word processor... more than
just either Information Display or Simple
Workpieces
 Composite frames are not different
problem frames that are 'glued'
together at 'component' boundaries

29. Framing Bias
The first step in making a decision is to frame the
question, but it is also where you can first go
wrong. The way a problem is framed can
profoundly influence the subsequent choices we
make. People tend to accept the frame they are
given; they seldom stop to reframe it in their own
words.
Lee Merkhofer
http://www.maxwideman.com/guests/portfolio/framing.htm

30. The ability to simplify means to eliminate the
unnecessary so that the necessary may speak.
Hans Hofmann