The term “unified” is used in several different senses in this book. It refers to (1) a language applicable to most activities in the software development process; (2) unifying the notations of Booch, OOSE, and OMT; (3) using the object-oriented paradigm (and others) throughout the whole process; (4) a modeling language that some people hope will become a worldwide standard via OMG standardization; (5) being independent of system scale and, therefore, also applicable to large real world systems; and, finally, (6) being readable and usable by humans as well as machines.
The preface lists some further aims and ideals, including that readers should learn how to use the Unified Modeling Language (UML) effectively; that a modeling language should be precisely defined, like a programming language; and that the purpose of UML is “visualizing, specifying, constructing and documenting” systems. Furthermore, the authors indicate that UML is appropriate to nearly all types of practical systems, ranging from enterprise information systems, through Web-based applications, to hard real-time embedded systems.
This user guide is one of three introductory books on UML by the authors. The others are the UML Language Reference Manual and Development Process Using UML.
Essentially, UML is a collection of graphical languages annotated with text for describing structural and behavioral models. They are applied to identifiable subparts of the system description (subsystems, views with respect to behavior, or “abstractions” omitting details that are not necessary for a certain focus). The rest is then detail work, namely programming in a certain language and applying suitable quality assurance, management procedures, or documentation practices. The essence of all of this, however, can also be described in several diagrams of UML.
For this purpose, 11 kinds of language are introduced. Some languages appear only within diagrams (such as OCL to denote constraints). Some diagrams exist as subdiagrams of others (sequence and collaboration diagrams of interaction diagrams), some are elaborated by others (collaborations within object diagrams), and some appear as annotations of others (such as statecharts for describing the order in which the operations of a class-within-a-class diagram are executed). Some diagrams are “equivalent” or “nearly equivalent.” Relationships between diagrams must describe various consistency relations.
The discussion is rather abstract up to page 120, in the sense that structural or behavioral things (diagram nodes) and relations (diagram edges) are introduced. Later, they are instantiated for the different kinds of diagrams. In the first part, the explanation is on a metamodel level, which cannot be understood by someone who does not already know the various subsequent instantiations. The remainder of the book contains well-written chapters on state chart diagrams, but also some chapters that do not contain much information. A reader with a question concerning, for example, the elaboration of a functional requirements specification will have to look through nearly the whole book. Frequently information appears in unexpected places (as in chapters 21 and 24).
Readers will be left with many questions. In many cases, the modeling constructs must be interpreted. Furthermore, it remains unclear what particular diagrams may contain and what the consistency relations are within those diagrams or between diagrams, in order to handle consistencies and tracing. In general, it is left unclear how to manage the consistency of numerous diagrams in a practical project.
I wish there was a common, standardized modeling language used worldwide and suited for most activities in software development, whether UML or another. This would be extremely helpful for practitioners as well as for computer science education. Such a language should have a precise syntax and semantics for the sublanguages. It should make clear how sublanguages are composed and integrated on the language level and on the method level. It should make clear how to handle maintenance projects, since more than 80 percent of current software projects are of this kind. There should be a sketch detailing how to deal with different systems, such as information systems and embedded systems. Furthermore, different kinds of projects (new development, maintenance, and reuse) should be considered. The presentation of this language should include good, elaborated examples, not fragments of trivial systems, as we learn more from good examples than from languages or method descriptions.
This book is no help for someone who has no modeling experience. The authors adapt features from various programming languages, modeling approaches, and so on and try to “unify” them so that they are applicable for any development context. In doing so, they cannot provide precise answers to the above questions. Experienced readers, however, will find many useful modeling elements, especially on the level of predefined but not standardized constructs (stereotypes).
The book gives the impression, as do most method books, that top-down development of trivial examples shows how to deal with large, varied systems. With this kind of language approach and book presentation, the numerous aims mentioned in the introduction cannot be fulfilled, especially not the aim of successful and worldwide use in practical projects. Given the state of the art of modeling and of modeling languages, these aims can hardly be met. The reader, however, will find no discussion of this issue. Therefore, the authors become victims of their own promises.
Assuming that there are answers to the above questions--and indeed there are more answers than given in the book--can they be presented in the pages of one book? One could at least try. This, however, is not possible with the space-devouring style of writing used here, including useless notes and cross-references, endless repetitions and refinements by copy and paste, lengthy enumerations, and usually useless “getting started” subsections.
Writing a book is a modeling task: the authors have to make clear which readers they are addressing and what they are going to tell (requirements specification). The book has to be structured in a way that meets these requirements (architectural specification). Thus, the book should be either readable sequentially or driven by a certain focus.
This modeling task has not been addressed. The presentation is behind the state of the art in modeling. If I used this book for a course, I would have to give (partial) answers to all of the above questions by myself.
No references are given, although nearly all the ideas presented here stem from other sources. The only reference I could find was in a section on “Where to Go Next” (p. 433), where the reader is encouraged to read the earlier methods books by the authors, which this book supersedes.
This book does not help make UML a success. UML will only succeed if the above questions are answered in a way that can be understood by the community. Finally, there is the danger that the community will have moved on to another paradigm by the time the answers are available.
