Books Uneven text on CASE for design and practice CASE." computer-aided software engineering T G Lewis Van Nostrand Reinhold (1991) 593pp £33.50 ISBN 0-442-00361-7

This book includes much information about some rather unusual computer- aided software engineering (CASE) tools, embedded in what would appear to be Lewis' university course in software engineering generally.

First, the coverage of CASE tools par- ticularly: all CASE tools discussed run on and, for the most part, only on Apple Macintoshs. Some are commercial pro- ducts; some are local products of Oregon State University at Corvalis, USA, the results of student projects and appar- ently available from the author. A few tools are uncredited, but obviously exist because they, like most others in the text, are discussed to the accompaniment of endless illustrations of their many menus and output screens.

In several cases this merely underlines the difficulty of using necessarily linear text descriptions of highly nonlinear con- cepts. In all cases the amount of detail devoted to 'which mouse button to push' seems out of place in what is not a user manual but a textbook.

Second, the coverage of software engi- neering in general: the best I can say is 'uneven', or perhaps 'idiosyncratic'; important issues are left out or glossed over, others are laboured to death. In the 'left-out' category I would put at the t o p of the list careful discussion of the differ- ence between specification and design models. There is no discussion of 'imple- mentation-free' specification models, of the concept of domain modelling, or of how to move from a formal problem description to a design.

The rather cursory discussion of data- flow modelling merely reinforces this lack of distinction. For instance, what is meant to be a specification dataflow diagram (for a problem that is about cost estimation) includes stores with labels such as 'RAM' , 'file', and 'printer'.

Even more fundamentally, Lewis seems to feel that a method without a CASE tool is a fish without a bicycle - - that it will not get very far. I was sur- prised. Many times I have clarified my thinking about a complex subjectmatter by drawing a simple data model on the back of a fish. I've used dataflow diagrams to help discuss problems with fish. I make sense of communications

protocols by turning them into state models. I have borrowed 'how to start ' heuristics from Yourdon, Ward, or Shlaer and Mellor when I am beginning a model of a problem. Methods, and their component notations, are tools for thought. Many companies have bought CASE tools, but not taught their employees how to think with the ideas behind them. Result: disaster. For years, electronics engineers successfully used finite-state machine notations to model complex digital problems without the help of computer-aided engineering. They may have occasionally made mis- takes, but their digital design work could not have been done without the disci- pline of paper-and-pencil work with decision tables and state models. 'Computer-aided' is not a synonym for 'useful'.

Other highly contentious and I think wrong claims are made. For instance, 'There are no guide-lines for combining methods when appropriate 't. Or 'None of the methods guarantee incremental correctness of design' ( 'guarantee', maybe not, but 'help verify' or 'assist in', certainly).

There is some confusion between methods, notations advocated by them, and tools used to expedite the use of either. A naive student might assume for instance that data dictionaries and the use of a data composition notation is a feature of Anatool, as opposed to a reali- sation of a concept common to many methods.

The coverage of many major methods and notations is half-hearted. Any book that includes dataflow diagrams with no arrows on any of the data flows is proba- bly not taking the concept behind the diagrams very seriously. There is vir- tually no coverage of data-modelling/ entity-relationship-diagram notations and the methods that use them. The few pages devoted to them use the eccentric term ' en t i tyca tegory relation', which (notation? method?) is introduced with- out discussion or definition. The reader is given the impression that such notations and the models built with them arc only, or mostly, to do with the physical design of databases.

'Object oriented' is interpreted as encapsulation, and as a design issue. There is no coverage or mention of object-oriented or domain analysis. Inheritance is only mentioned once or twice, and then not helpfully; 'subtype/ supertype' appears to be equated with

'instance/class'. Real-time issues are relegated to one

two-paragraph programmatic sidebar. There is little coverage of methods or notations used for real-time analysis and design. State models are not discussed or taught, but only briefly mentioned, and then only as a notation for communicat- ing with a user-interface design tool. Jackson Structured Programming (JSP) is discussed, but not Jackson Structured Design (JSD). Just to keep things inter- esting, JSP is called JSD in the text.

Although the preface claims a reader- ship of 'practitioners who manage, design, code, test and market . . . ' soft- ware, most of them will probably fall asleep over the chapters on mathematical verification and software metrics. The former is fuzzily written and too shallow to teach a beginner anything useful. The latter leads the eager practitioner - - as software metrics often seem to - - nowhere much. Nor do the pages on the mathematics of reliability statistics and cost estimates. The pages 'adapted from the IEEE Standard for Configuration Management Plan' teach nothing and are likely to induce terminal coma.

Lewis' heart would seem to be in design and implementation; his coverage of lower-CASE tools and the concepts behind them is excellent. He makes good use of quantitative data (I had not before run into Card's wonderful result suggest- ing that small modules are more expen- sive to maintain?). Testing, programming style and complexity, and coding standards are covered well.

The text occasionally gets bogged down in programming details of no general consequence. There are pages devoted to Macintosh system program- ming, down even to hex listings of icon and mask resources.

Coverage of project management issues is deeper than what usually gets into an introductory software engineer- ing text, and much more than one would expect from a book purportedly about CASE. My main protest would be the use made of Boehm's spiral model. Lewis leaves out all mention of risk, and uses the spiral model as a mechanism for dis- cussing rapid prototyping using very- high-level code generators. Boehm's risk- driven model is easy to understand, and I believe really should be discussed when- ever the concept of prototyping comes up.

The book could have benefited from better production. Graphics are derived

416 Information and Software Technology

from poor-resolution computer output, suffer from the jaggies, and are often dif- ficult to read. Heading typefaces are occasionally used inconsistently, with consequent confusion. The index is terr- ible, useless, awful. Infelicities such as 'Prototyping is a kind of CASE t o o l . . . ' or ' . . . the behaviour carries out the operation . . . ' could have been avoided by better editing.

In summary, an uneven course text, of limited use without access to a Macin- tosh and all or most of the CASE tools discussed. With access to such hardware and software, the book might just be worth considering if one was more inter- ested in teaching good design and imple- mentation practice, and less interested in the modelling concepts that underlie domain and problem modelling.

A CAMPBELL Brighton, UK

References 1 Cameron, J R, Campbell, A and Ward,

P T 'Comparing software develop- ment methods: an example' Inf. Soft. Technol. Vol 33 No 6 (July/August 1991) pp 385-402

Stimulating read attempts to bridge the ignorance gap Programming as if people mattered." friendly programs, software engineering and other noble delusions N S Borenstein Princeton University Press (1991) $29.95 ISBN 0-691-08752-0 (CL)

The author's aim is to bridge the gap between two professions that he suggests 'are separated by a wide gulf of ignor- ance'. These professions are software engineers and user-interface experts. Apparently, there is 'general disdain on the part of user-interface specialists for the methods and techniques of software engineering', while 'from the perspective of the software builder, things are a lot easier if you can keep people out of the picture'. Borenstein hopes the discipline of 'human-oriented software engineer- ing' will emerge, and that this book will contribute to such a body of knowledge.

The book explains who it is aimed at: first and foremost, it is for managers of user-interface programming projects. Further audiences are students of pro- gramming who are contemplating a career in user-interface software develop- ment; software engineering researchers interested in extending methodologies in the user-interface area; and human- computer interaction (HCI) researchers.

The strength of the book is that it is compact and readable and contains a good number of salutary anecdotes. In keeping with the intriguing title of the book, chapter names such as 'Break all the rules', 'Lie to your managers', 'The men in suits', and 'Pretend that small is beautiful, but don' t believe it' whet the appetite. In addition, every chapter is prefaced with a one-page example of a user-interface gaff, which can arouse embarrassed memories or even cajole a chuckle on page 104. It is a pity the illus- trations are not in colour; the black-and- white screen images look curiously dated. The binding and art deco dust- jacket are fine, and I enjoyed many of the quotations that introduce each chapter.

I think it fair to warn the reader what the book does not contain. There is no exposition on different types of user interface; no advice on how to design software so that the user-interface com- ponent is kept separate from the underly- ing application code; nothing about the merits or otherwise of object-oriented user interfaces; no opinions about CUA, Motif, or OpenLook. There is a bit about selecting user-interface programming environments, and some advice on the management of user-interface software development. As the main audience is management, this may seem a bit thin. The core of the book, the ten command- ments of user-interface design, are really addressed to Borenstein's own pro- fession - - the programmer or software engineer.

I wonder whether the book will not grate on those that Borenstein wishes to influence. He slates everyone but the pro- grammers in one way or another. 'The worst kind of arbitrary requirements often imposed by management are those born of sheer ignorance, superstition, fear or laziness'; 'managers who under- stand how to let software creators do their job are quite rare'; 'like any other technically uninformed user of the soft- ware, the manager was . . . unable to understand the solution perceived by the designers'. Then, after warning us to treat user-interface research conclusions with 'a decidedly sceptical eye', he is generous enough to warn 'don ' t assume it's all worthless'! University teaching is not forgotten: 'To d a t e . . , it has failed to address seriously the difficult questions of training practical programmers'. The users are let off lightly, even though 'many of them fancy themselves as experts in user-interface design'. 'Think of the user community as being like a pre-school of screaming three-year olds', he advises. Meanwhile, we are reminded that 'programmers have a sense of beauty in their work, and strive for clean- liness, elegance and simplicity'. It is

good, knock-about stuff, but will it not alienate the intended audience? And for many programmers, working on infor- mations systems in corporate data-pro- cessing departments, the advice may be off-target, as the influence they can have over the user interface is limited: the user interface is defined by the systems ana- lyst or designer, who is not a program- mer; and the design is typically con- strained by company standards, the platforms previously selected, or the package chosen. So Borenstein is right, it is the management that must heed the lessons of the book, as it is management that has the power to introduce user- interface prototyping, to encourage user- interface innovation, and to introduce experts from other disciplines. I am afraid the 'us' programmers feel of the book may well result in ' them' manage- ment taking an aversion to the author's anecdotal advice.

I suggest the book is a reasonable buy for the corporate or university library - - or even a public library - - as I believe many people involved in user-interface design will find the book a fascinating one-off read. I suggest it is less suitable for a personal purchase - - I really do not think there is enough in it to warrant the $30 purchase price. And once read, there is no index or summary charts to look up those anecdotes and commandments; summaries and an index would result in a book of more lasting value.

Although the basic message of the book (that the best technique for design- ing the user interface is by allowing users to exercise prototypes) is hardly a new one, the book provides a stimulating read, with a fair sprinkling of contro- versial opinions from which the intelli- gent'reader (and we are left in no doubt who the intelligent people are) will draw their own conclusions.

J DODD JMA Information Engineering Ltd,

Ashford, UK

Vol 34 No 6 June 1992 417