Robin, the editor of The C++ Newsletter, can be contacted at [email protected].
The idea of Patterns is that the class is at too fine a level of abstraction to completely explain object-oriented design. Patterns are simply patterns of classes, ways that classes can be used together to solve common problems in software design. Patterns has been heavily hyped in some magazines, and after seeing some really dreadful articles about Patterns I felt quite skeptical that there was any substance to what otherwise seemed like a good idea.
I was pleasantly surprised when I began reading Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Having followed the group running the Patterns e-mail reflector out of the University of Illinois, I was already familiar with the concept of Patterns. Since Johnson runs that reflector, it isn't surprising that Design Patterns covers much of the same information, although the book is more coherent than the e-mail reflector itself. Style-wise, the book reminds me of Grady Booch's Object-Oriented Analysis and Design, which is to say it is very well written. (Booch wrote the forward for Design Patterns.)
Design Patterns has a good amount of C++ code, so it isn't all dry theory. Chapter Two is a case study in designing a document editor. It gives some interesting insights into the design process and builds confidence that the authors' methods can actually be applied. Chapters Three through Five present a "Design Pattern Catalog" that lists 23 different types of patterns with example C++ code. The appendices contain a guide to the book's object notation (which is based on OMT and is quite simple to understand) and their foundation classes (simple containers, mostly) that are used throughout the book. The book includes a glossary, bibliography, and index.
Even if you have reservations about Patterns (I do), Design Patterns is a book that belongs on your OOD reading list. To me, being thought-provoking, clear, and free of technical mistakes is more valuable in a book than being 100 percent in agreement with my own design beliefs. Design Patterns makes good arguments and is pleasant reading.
Source code for the book is available electronically by sending the message send design pattern source to [email protected].
All software engineers try to predict how big a program will be, how long it will take to build, and how many defects it will likely contain. Software metrics is the branch of software engineering that attempts to put some science behind this estimation process.
Metrics and Models in Software Quality Engineering, by Stephen Kan, makes a good introduction to the software-metrics field. Kan relates not only the use of metrics at his own employer (IBM Rochester), but gives examples from NEC Switching Systems Division, HP, Motorola, NASA, and IBM Federal Systems. If you intend to work on software with any of these companies, it would be useful to know their techniques.
Don't expect any object-oriented or C++ engineering here. Metrics and Models contains no code and is not object-oriented in its thinking. Kan says, "the waterfall process is very valuable," and that "there is very little information available about object-oriented development processes." Although Kan clearly states a preference for the waterfall process as "time-proven," little time is taken up with the waterfall process itself, and its mention should not be an impediment to OO readers. It does, however, leave some question in my mind as to how well these metrics will work in conjunction with OO techniques.
The use of metrics is geared toward big software projects, since so many of its methods are statistical. Even so, Kan admits in the small print that many of the metrics methods don't sample enough data to be considered statistically sound. What we have with the current state of the art in metrics is empirical. Perhaps, just as early astronomers could make decent calendars but couldn't understand the workings of the solar system, software metrics makes predictions without knowing exactly why they should be right.
Kan writes well and clearly, although a bit dry, and the book is generally enjoyable to read. One small, persistent annoyance is the author's overuse of the word "formal," which has a specific meaning to a mathematician or software engineer. "Formalization is the process by which mathematics is adapted for mechanical processing. A computer program is an example of a formalized text." This quote is not from Kan's book, but from The Mathematical Experience, by Davis and Hersh (ISBN 3-7643-3018-X). "Formal" can variously mean:
- Proven mechanically by mathematical logic.
- Rigorous.
- A social ritual.
Metrics and Models contains standard practices in the metrics field. The concise and clear explanation of function point counting is a jewel. If you are looking for just one book on metrics, this is a good choice. Good use of graphs and highly descriptive text keep the book moving. Although the book doesn't contain code, it does have lots of equations. For speaking intelligently to software metrics practitioners, or even performing metrics yourself, Metrics and Models should be on your bookshelf.
Software safety and reliability should interest not only the software engineer, but everyone in our society. Even if you choose not to take the risk of boarding a fly-by-wire jetliner, you still face the risk of being struck by falling airplane parts. In fact, the odds are actually considerably higher than your chances of winning a state-lottery jackpot. This is less a comment on the dangers of computer-controlled systems than on how society as a whole shares the risks of our increasingly automated civilization.
Peter Neumann is the moderator of the RISKS forum on Internet. A visit to comp.risks is the place to go to find out the latest happenings and concerns in software safety and security.
Neumann's Computer Related Risks can serve as an almanac or history of software disasters. If you have been frustrated by the lack of organization on the somewhat free-wheeling RISKS forum, you will be glad to see the information well organized, with deeper insight and more details. Just on the sheer breadth of available information, you have to look at this book. Want to know of a software failure caused by a dead cow? It's right there on page 17: "On May 4, 1991, four of the FAA's 20 major air-traffic control centers shut down for 5 hours and 22 minutes. The cause: 'Fiber cable was cut by a farmer burying a dead cow.'"
Neumann provides many similar anecdotes: submarine sinks trawler; Dutch chemical plant explodes due to typing error; Michigan factory worker killed by robot; robot camera runs away from Connie Chung; raccoons cripple the JPL; NASA rockets, set to explore thunderstorms, launched by accident when hit by lightning; interference from MacDonald's toasters increases employee paychecks; and so on. Don't get the idea that this is not a serious book. Neumann goes deeper, into the causes of software glitches, not just in the specific cases, but in general. He looks into weak links, single-point failure causes, multiple causes, and malicious acts. System security is a major focus of the book.
Nancy Leveson, a University of Washington professor, is a well-known software safety expert. Her paper on the Therac-25 medical accelerator software accidents published by IEEE is one the most well-known papers published in the field of software safety.
Leveson's Safeware: System Safety and Computers has much less to say about software itself, despite the title. It instead focuses on the bigger picture of accidents in general and how the software development process interacts with them. What Leveson is looking for are the root causes of accidents in general and how those apply to software specifically. After dispelling some "Software Myths" in Chapter Two, the focus is on people, not the machine or code. While Neumann's book focuses on how machines can go berserk, Leveson studies how people foul things up. Although Safeware is presented in a sedate textbook format, some may find it hard to read without getting good and mad that so many people recklessly endanger (and kill) others just because they don't want to believe an accident could happen.
Leveson looks at the history of engineering safety, particularly in aviation, to see what has worked and what hasn't. Several chapters are devoted to hazard analysis techniques, such as fault-tree analysis or state-machine hazard analysis. A chapter addresses applying hazard and requirements analysis to software. The chapter on hazard elimination provides many good insights but requires some further effort on the part of the reader to consider how it all applies to software. (It does.) Naturally, a book that is concerned with human factors looks into the design of human/machine interfaces.
Leveson has some outstanding case studies in the substantial appendices, divided in medical, aerospace, chemical, and nuclear categories. She examines the Therac-25, Apollo 13, the DC-10 cargo door, the Challenger, Seveso, Flixborough, Bhopal, Windscale, Three Mile Island, and Chernobyl. Leveson chose to focus on accidents for which significant information was available. She seeks the truth through deep insight. Neumann's book tries to cover the spectrum of software accidents and incidents, including those that are security related. He seeks the truth through a broad understanding.
Although both books reach many of the same conclusions, they are complementary. If you care about software safety you really need both. It's a bit surprising there isn't more overlap between the books in the software safety field. Both of these books are in some ways better than "Digital Woes" or "The Day the Telephones Stopped," but they don't supplant them. Safeware is obviously intended as a college text. Computer Related Risks is more of a crossover; it is breezier in tone and less rigorously organized, but it has student exercises at the end of each chapter, a feature Safeware lacks. Both books cover a number of software-related incidents, but Safeware goes for depth while Risks goes for breadth. However, they don't cover everything. The well-publicized but poorly researched Denver Airport baggage-handling-system fiasco is missing from both.
Both authors write well. Neumann is more fun, while Leveson is more scholarly. The bottom line is Computer Related Risks will have more appeal to programmers and even the general public. It is also a good "think" text for undergrads in computer science and other fields. Safeware is required reading for systems analysts and others concerned about the problems of engineering management. I enjoyed both and look forward to reading them again more leisurely. Both are excellent reference material.
Many software engineers are interested in the "Deming Method." Dr. Deming was responsible for quality and efficiency during urgent production improvement efforts in the U.S. during World War II. The success of his methods helped us win the war, but were seen as unnecessary in the post-war economic boom. Post-war Japan, however, was not in such good shape and invited Dr. Deming to teach his methods there. As a result Japan changed its production techniques so that "Made in Japan" was transformed from a synonym for shoddy to an indication of high quality. It would be 40 years before America rediscovered Deming.
Four Days with Dr. Deming is a summary of his management lectures. The book is too light, in my opinion, to serve as an introduction to Deming for engineers. (See The Deming Management Method, by Mary Walton, ISBN 0-399-55000-3, or Dr. Deming, by Rafael Aguayo, ISBN 0-671-74621-9 for popular paperbacks that present Deming in a more narrative form.) However, if you have been looking for a more approachable book on Deming to drop on a manager's desk, this is it. Moreover, if you are a Deming aficionado or want to train in his methods, you should spend a few days reading this book. It is the closest thing to a Deming cookbook. It's paperback with lots of illustrations and amusing anecdotes.
Design Patterns: Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Addison-Wesley Publishing, 1994, 416 pp., $37.75,
ISBN 0-201-63361-2
Metrics and Models in Software Quality Engineering
by Steven H. Kan
Addison-Wesley Publishing, 1994, 344 pp., $39.75,
ISBN 0-201-63339-6
Computer Related Risks
by Peter G. Neumann
Addison-Wesley Publishing, 1995, 367 pp., $22.95,
ISBN 0-201-55805-X
Safeware, System Safety and Computers
by Nancy G. Leveson
Addison-Wesley Publishing, 1995, 680 pp., $45.95,
ISBN 0-201-11972-2
Four Days with Dr. Deming
by William J. Latzko and David M. Saunders
Addison-Wesley Publishing, 1994, 344 pp., $25.95,
ISBN 0-201-63366-3
Copyright © 1995, Dr. Dobb's Journal
