The key words in the title of this book are “problems” and “analyzing.” Jackson presents a way of categorizing and analyzing software problems that he calls “problem frames.” The book concentrates on analyzing problems--it does not deal with devising solutions to those problems or analyzing designs. In these respects, it is different from other software development books, stopping where most books start.

Jackson is careful not to present problem frames as a panacea. He says just the opposite, noting that they do not work in every situation. One major limitation is the emphasis on physical phenomena. Problems in mathematics or other areas with no physical domains or interfaces are not well suited to problem frames. Also, for cases such as graphical user interfaces or compilers, where existing tools allow building a solution directly in a standard style, problem frames are of little use.

The book has 12 chapters. The first chapter justifies the focus of the book: structuring and analyzing software development problems. Chapter 2 presents context diagrams, a graphical way to represent problem contexts as interconnected domains. Chapter 3 tackles decomposing the problem into subproblems, with each subproblem representing a projection or partial view of the real world and the machine solving the problem.

Chapter 4 introduces problem frames, a method of capturing families of problems in a general problem diagram. Jackson presents five basic classes of problem frames:

• required behavior--controlling some aspect of real-world behavior according to specified requirements;

• commanded behavior--controlling some aspect of the real world according to operator-specified commands;

• information display--reporting information on real-world states;

• workpieces--building a tool to create or modify some class of computer-processable objects; and

• transformation--changing input data into formatted output according to transformation rules.

Chapter 5 presents the basic frame concern, or fundamental analysis criterion, of each type of frame. The frame concern enumerates the problem descriptions that must be completed in order to show that the problem is well understood and sufficiently analyzed, and the necessary relationships between them.

Chapter 6 deals with the domain characteristics of each problem class. Chapter 7 describes model domains (such as databases) and the concerns they introduce for correctly determining the relationships between real-world states and model states. Common variants of the basic problem frames are presentedin chapter 8. These are typically cases where an extra domain is added to one of the basic problems.

Chapter 9 deals with five specific concerns that arise in many problem frames: initialization, reliability, completeness, overrunning, and identification. Problem decomposition techniques are explored in chapter 10. Chapter 11 continues with composite frames--that is, problem frames that require decomposition into a standard structure.

The last chapter puts problem frames into the broader perspective of software development. Here Jackson states the book’s main theme, namely, the maturing of software development as a profession: “The beginning of maturity in software development is the acknowledgement of variety. This is the centralmessage of this book.”

An appendix summarizes the notation used in drawing problem frame diagrams. A glossary of around 100 terms, a list of references, and an index are also included. Jackson illustrates his approach throughout with numerous examples. As he expands the concepts, adding flavors, variants, and additional concerns such as reliability and completeness, he shows how these are addressed by adding them to the examples. Unfortunately, this leads to a somewhat disjointed view of the technique. There is no good, full-scale example carried out in one place from start to finish. This makes the method a bit difficult to judge in its entirety.

The book might be a good supplement for software design courses. However, it lacks some features useful in a text: chapter summaries; exercises or questions to check the reader’s understanding of the material; and a list of references at the end of each chapter.Instead, references appear in sections titled “Any Questions?” along with other imaginary questions from the reader, as answers to “Where can I read more about….” Moretraditional citations, footnotes, or a list of references at the end of each chapter would have been more efficient and useful.

The value of problem frames lies in the approach, not in the diagrams. There is no magic about using certain types of pictures to represent problems, but a standard approach allows standard problems and their variants to be recognized and ensures that the standard concerns of each type of problem are addressed. It remains to be seen how successful problem frames will be in real development work.