Frames, Subproblems, and Methods

The following is quoted directly from Jackson, M.A.; Problem Analysis Using Small Problem Frames; Proceedings of WOFACS ’98, Special Issue of the South African Computer Journal, 22, pp47-60, March 1999 which can also be downloaded from Jackson's own web site.

The use of tightly constrained problem frames can offer two important advantages. The first advantage is that it underpins a repertoire of known and recognised subproblem classes into which realistic problems can be decomposed. The difficulties of unguided problem decomposition are now widely accepted. The traditional top-down process involves decomposing a problem of no recognised class into a number of subproblems also of no recognised class, and continuing recursively until - if the process succeeds - elementary subproblems are recognised at the lowest level. This process can not be expected to produce a good result. Fred Brooks sums up his experience in the aphorism: "Plan to throw one away; you will anyhow." The outcome of the process is not a good decomposition; it is a degree of insight into the difficulties of the problem, so that a second complete attempt can then be based - at least in part - on recognised problem characteristics. A sufficient repertoire of problem frames would allow the first decomposition to be guided by a more systematic problem taxonomy.

The second advantage is that a problem frame is, ideally, associated with one or more methods for capturing the problem in full detail and developing a solution. Software development method is chiefly concerned with stipulating the descriptions to be made, the languages to be used, and the large structures within which the descriptions are related. The decomposition of a problem into subproblems of recognised classes allows the appropriate method to be used for each subproblem. Within each frame the method stipulates descriptions of the problem's principal parts, and the particular way in which their large structures specialise the general structure.

A method associated with a tightly constrained problem frame can take advantage of the known characteristics of the problem in several ways. In particular, it can stipulate a less expressive language than might be needed in a more unconstrained problem. For example, a method may stipulate the use of a regular expression language. A problem whose relevant part can not be described by a regular expression may be deemed to fall outside the frame. Or, in some cases, the method may provide a technique for overcoming the difficulty. For example, the description may consist of two or more regular expressions over intersecting alphabets, perhaps with a corresponding problem decomposition. More fundamental difficulties may demand a further decomposition of the problem. The use of a model within the machine, simulating a part of the world outside it, may be the result of such a decomposition. This difficulty, and others, are illustrated in subsequent sections.