BOOK REVIEW: UML Components: A Simple Process for Specifying Component-Based Software
- By Charles Ashbacher
- August 1, 2001
By John Cheesman and John Daniels
Addison–Wesley, Reading, MA, 2001
166 pp., $29.95 (paper), ISBN 0-201-70851-5.
With few exceptions (and this is not one of them) in computing, the word, "simple" should only be applied with some form of a "relative-to" qualification. The dream of creating interchangeable parts of software has been a goal that first appeared on the horizon some time ago; but up until now, it has yet to make a complete appearance. The authors of UML Components: A Simple Process Specifying Component-Based Software acknowledge that fact in Chapter 8 and argue that with the availability and power of the Unified Modeling Language (UML) to standardize the design, coupled with standards such as COM+ and Enterprise JavaBeans (EJB) for the runtime side, it is about to happen. While these tools will no doubt accelerate the move to component reuse, the process of the increased adoption of components is more complicated than that.
However, in the arena of the specification of components software using the UML, this book has many positive attributes. There is no preamble or introduction to UML; for that, you must use another resource. This was a good decision on the part of the authors, as many people now know UML, and there are several good resources available. Furthermore, the explanations are such that one knowledgeable in computing would quite likely be able to discern what is being described without a detailed knowledge of UML.
As the authors stress, the set of steps that will turn a software segment into a component is not difficult to understand. The precise specification of what a component expects and what it is expected to do is the major task that needs to be addressed. A secondary, but necessary, task is that the details of the implementation are not part of the component specification; if they were, it would violate the concept of interchangeable parts. The basic structures of a design by contract are described using the Object Constraint Language (OCL). It is not necessary to know OCL to understand what is being described; a thorough background in Boolean expressions is all that is needed.
The example used throughout the book is that of a hotel room reservation system. It satisfies the three criteria that any such example must adhere to:
- It is an operation that is routine to most of us, so there is very little need to explain the basic premises. Additional realistic extensions can be added without any substantial explanation.
- There are enough different features that can be encapsulated into a component so that the complete example is complex enough to be an effective learning tool.
- The interactions among the components are complex enough so that the real problem of using components, namely specifying how they intercommunicate, can be sufficiently developed.
Projects are divided into two parts, the plan and the execution. If only one is done well, the project will not succeed. The same applies to components as well, whether you are defining them or describing how to define them. In this book, the authors also execute their well-conceived plan. The descriptions are complete, understandable, and in the proper order. While
UML Components is shorter than the typical technical book, I had no trouble reading it in two sessions, a morning and an afternoon in the same day. My attention did not waver and there were only a very few times when I stopped and either re-read or looked at a previous page for clarification.
You would have to be the programming equivalent of a cave dweller to believe components will not become a dominant technology in the very near future. With this book, you can face that future with much of the knowledge that will prevent you from being relegated to the recycle bin of history.