×

Software requirements and design. The work of Michael Jackson. (English) Zbl 1201.68033

Chatham, NJ: Good Friends Publishing Company (ISBN 978-0-557-44467-0/pbk). 409 p. (2010).
This very well written Festschrift is about various aspects of the fruitful separation of the “hard” formal concerns of the software developer (and computing scientist) from the “soft” concerns of the analyst addressing the informal aspects of the world outside the computer system. Michael Jackson notes (similarly to D. Bjørner [Software engineering 1–3. Texts in Theoretical Computer Science. An EATCS Series. Berlin: Springer (2006; Zbl 1095.68020, Zbl 1095.68021, Zbl 1095.68022)]): “Having created the technology that spawns huge discrete complexity of the problem domain, we [software developers] have a moral obligation to contribute to mastering that complexity”. This is so because programmers have to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before [E. W. Dijkstra, “On the cruelty of really teaching computing science”, Commun. ACM 32, 1397–1414 (1989)]. Furthermore, throughout the book, Jackson emphasizes that the problem world “is central to a computer-based system, and so the task of describing it is central to software development”. Unfortunately, this position is not readily acknowledged by too many software engineers, and this results in more or less well-known system failures.
11 out of 18 papers in the book are written or co-written by Michael Jackson (some of them are reprints). Three papers, by C. A. R.  Hoare, Cliff Jones, and Anthony Hall, further explain (and expand) some of the most important contributions by Jackson. Most of these papers are accessible to anyone having some programming (or mathematical) maturity. While the other papers are somewhat more technical, they are also understandable to non-experts in specific languages, methods, or tools. The book is not language- or tool-oriented at all, in excellent agreement with Parnas’s remark: “Engineering procedures are based on science and mathematics; and graduates are expected to understand the reasons for the rules, not just blindly apply them” [D. Parnas, “Risks of undisciplined development”, Commun. ACM 53, No. 10, 25–27 (2010)].
The earliest (Jackson’s) paper in the book was first published in 1973, and it is still relevant, as are the main concepts of Jackson’s program design method JSP (Jackson Structured Programming) and system development method JSD (Jackson System Development). While these methods are applicable only to some well-defined problem worlds, these worlds are encountered quite often, and so the methods demonstrate how real world problems may be rigorously defined and solved in a clear and repeatable manner leading to “normal design”, well-known in other areas of engineering. Even more importantly, however, is Jackson’s emphasis on engineering approaches to problem world analysis and to software design in general. As in any branch of engineering, “for each system the developers must investigate and analyze the properties of the problem world domains and of their interactions with each other and with the machine to be built: they must devise a machine whose interactions with the domain to which it is directly connected will ensure that the system requirements – the purposes of the system – are satisfied”. In most branches of traditional engineering, the problem world domains, the system, and the most important aspects of the machine are well known and explicitly described, leading to successful specialization of engineers where, as Jackson observed, handbooks and well-established approaches are taken for granted (and learning from failures is considered to be normal). In some “traditional” branches of software engineering (operating systems, compilers, etc., for which the problem worlds are rather formal) this is also the case; but in many others this is not so. The problem worlds for the latter are quite informal, and they can “readily falsify almost any formal assumption about their properties and behavior”. This often leads to “radical designs” where reuse patterns are less well known (if known at all) and the approaches used may be (much) less successful, although unfortunately well-established, as observed in a recent paper by Parnas [loc. cit.].
At the same time, as emphasized, for example, by Gerald Weinberg, “the student trained in general systems thinking can move quickly into entirely new areas and begin speaking the language competently within a week or two” [G. M. Weinberg, Rethinking systems analysis and design. Boston and Toronto: Little, Brown and Company (1982)] – and good programmers have to be good abstractionists and thus good systems thinkers because, as also noted by E. W. Dijkstra and D. Bjørner, no other discipline has appropriate intellectual tools to master complexity. In particular, creative composition [H. Kilov, “Finding work: an IT expert as an entrepreneur”, in: Proceedings of the OOPSLA2002 workshop on behavioral semantics, Northeastern University, Boston, 105–117 (2002)] of components which are objects of normal analysis or design becomes possible. This is certainly not always the case in software engineering, and Jackson urges for “a degree of culture change across the whole range of software development”, so that design mistakes will be understood and not be repeated again and again. In order to do that, education is of utmost importance, and Jackson observes the “disdain for the inconveniently messy real world” in software engineering textbooks that include mostly (only?) small problems that provide neatly circumscribed class exercises.
Jackson clearly distinguishes between the requirement describing the desired relationships in the (future) environment of the machine and the specification of that machine describing the behavior of the machine at its interface with the environment; both are expressed in terms of the environment phenomena. Thus, “a specification is a staging post on the hazardous journey from a requirement to a program” (Jackson). The “designation set” of the environment phenomena clearly shows the subject matter of the requirement and obviously separates requirements from solutions. Explicit designations make the descriptions refutable. The relationship between the environment, requirements, and specifications is emphasized in several papers by Jackson (including those on “problem frames” that may be characterized as “molecular” business patterns [H. Kilov and I. Simmonds, “Business patterns: reusable abstract constructs for business specification”, in: Implementing systems for supporting management decisions: concepts, methods and experiences. Chapman and Hall, 225–248 (1996)] in an unreliable and open – that is, unpredictable – world) and was considered so important by Anthony Hall that he stated: “It is the \(E=mc^2\) that suddenly explains what was previously obscure!”. Hall also observes that introducing a machine may change the environment in completely unanticipated ways. Jackson reminds the reader that the subject matter domain and its model domain are distinct realities, and it is a pity that after the excellent book by W. Kent [Data and reality. North-Holland (1978)] this has to be reiterated again and again. Note that more work is needed in problem world modeling within Jackson’s excellent framework, for example, by emphasizing the importance of relationships among the environment phenomena (that obviously do not exist in isolation).
Several more technical papers are about feature interaction in general and distributed feature composition in particular – these are well-known problems existing not only in telecommunication. For a good specification of distributed telecommunication feature composition, feature development is modular, so that features interact only through the specified mechanisms of the architecture, as opposed to monolithic programming of features that leads to failures due to excessive complexity.
The bold, explicit, and thought-provoking papers by Michael Jackson are well characterized by van Lamsweerde in the last sentence of the book: “The requirements engineering community owes much to Michael for the clarity and elegance of his thinking and his so enjoyable style of writing”. I would generalize this debt to the software engineering and, moreover, to the systems thinking community.
Unfortunately, the book has no index.

MSC:

68Nxx Theory of software
68-06 Proceedings, conferences, collections, etc. pertaining to computer science
01A75 Collected or selected works; reprintings or translations of classics
00B30 Festschriften

Biographic References:

Jackson, Michael
PDFBibTeX XMLCite