Framing the Problem

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. Model Properties  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

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 A given domain Heating Plan Heated Rooms Heating Controller A designed domain Operator Furnace The machine domain

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

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

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 Plan X Heating Plan Entry Rules Heating Controller Operator B 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 Required Behaviour C 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. Controlled Domain C Commanded Behaviour Control Machine Operator B 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. Real World C Display ~ Real World Information Machine Display C 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. Work Pieces X Command Effects Editing Tool User B 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. Inputs X Transform Machine I/O Relation Outputs X 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