The recently-released UML 2.0 specification is much less readable than the original UML 1.1 specification. The UML has grown more complex, and therefore, the need for a thorough reference book from the creators of the language is more pronounced than it was when the first edition was published more than five years ago. This timely second edition has been thoroughly revised, expanded, and updated to reflect the intricacies of the latest version of UML. The authors have incorporated feedback from the first edition. Significant changes include revisions in the area of sequence diagrams, activity models, action models, protocol state machines, components, internal structure of classes and components, and profiles. The result is a thoroughly useful reference that is completely up-to-date and essential to any software practitioner who needs to understand the inner-workings of the industry standard modeling language.
James E. Rumbaugh is an American computer scientist and object-oriented methodologist who is best known for his work in creating the Object Modeling Technique (OMT) and the Unified Modeling Language (UML).
UML has something of a mixed history. In the last decade it has been picked up, at least in part, by several programmers. Even so, it hasn't been a runaway success.
The reference manual contains about 100 pages of an overview of UML plus 400 pages of reference material. The overview provides a good introduction to the subject. UML provides important insights into object oriented design, improvements over traditional state charts and a decent way to depict the internals of concurrent and networked systems.
The book covers things about as well as can be expected. However, now that I've had more time to consider UML, I'm no longer convinced it has an important role to play in software development. Sure, some of the charts show important data, but many of the charts are nothing more than a way for developers to waste time, and even the useful charts can easily be replaced with other ways of showing the same information.
UML is meant to give a high level overview of the software in question, and it's been my experience that a high level overview is almost useless. Bugs generally lurk in the details and in the interactions that UML doesn't cover.
Like all dynamic languages, the Unified Modeling Language (UML) is growing more complex over time. While it is true that for most developers, this means that you will regularly use a smaller percentage of the language, the actual percentage will vary from person to person and from day to day. Therefore, no abridged UML manual could possibly be adequate. Written by the three creators of the UML, this manual is clearly definitive and one that all developers should have at extended arms reach. Designed to cover the changes in the recently released UML 2.0, which were significant, a CD with the full text in Adobe PDF form with hotlinks to the definitions of the key terms is also included.
The opening chapter is an overview of the UML and most people can skip it. Chapter two is an overview of models, and this one is worth reading. Short, it introduces some of the fundamental terminology and approaches. A walkthrough of UML is done in chapter three, which introduces the various formal views of a project. They are: static, design, use case, state machine, activity, interaction, deployment, and model management. Each of these views is then explained in a short chapter. These chapters should be required reading for users of the book, as they establish much of the notational and definitional background used in the reference section.
The real value of the book is in the five hundred plus pages of detailed definitions of the key terms and phrases in the UML. Listed in alphabetical order, each entry has the following form:
*) Entry name: the term or phrase.
*) A brief definition, generally one or two sentences.
*) The semantics of the term, generally using several paragraphs. This section Includes the structure, subordinate items and often an example.
*) The notation of usage. Options and guidelines for use are often included.
*) Discussion (occasional), where the author's opinions and/or a background explanation of the term are given.
*) History (where appropriate), the changes in how the term is interpreted from earlier versions of the UML.
Quite frankly, I cannot see how it would be possible for any developer to use anything more than a very tiny subset of the UML if they do not have access to this book. All speakers of a language can use that language in informal communication, but when we want to communicate ideas formally and precisely, a dictionary is essential. That is the role that this book will fill, as no human communication is more precise than when we do it with notations that describe software.
Published in the online Journal of Object Technology, reprinted with permission.
Ce second volet de la trilogie UML est aussi le plus aride. La plus grande partie du livre est de type encyclopédique, car elle décrit alphabétiquement les notions utilisées dans UML. A noter que cet ouvrage comprend un CD reprenant l'intégralité de la version papier au format Acrobat, et qu'il peut ainsi être utilisé "en ligne". Ce livre intéressera les spécialistes de la notation UML qui souhaitent rentrer dans le détail de la sémantique de la notation, mais on ne saurait lire ce livre linéairement.
Good at what it sets out to do but neither a an easy read nor a particularly interesting one. It should also be noted that once i read this I so thoroughly disagreed with UMLs process wrapper that the book's rating also reflects my dislike for the method.
Useful dictionary on terms and concepts in software engineering using UML. My only complaint is that the explanations are too verbose, not very succinct or pragmatic.