Martin Fowler
Addison-Wesley, 2003 (3rd Edition)
Martin Fowler
Addison-Wesley, 2003 (3rd Edition)
ISBN 0321193687 (paper)
Buy it from Amazon.com
Buy it from Amazon.co.uk
Short books on UML are better than long books on UML.
This is still the best short book on UML.
Alistair Cockburn
This trim paperback in the Object Technology Series provides a compact and readable overview of the Unified Modeling Language (UML). The third edition has been fully updated to bring it into line with the Object Management Group (OMG) standard for UML 2.0.
The third edition is even better than the second, for two reasons. Firstly, UML 2.0 corrects several problems in the visual 'language' itself: it is now more expressive, in places more compact, and is certainly better able to handle a wider range of situations including systems other than software. Secondly, the discussion has been sharpened: while the UML has grown (with four new types of diagram), the book has actually become shorter. But happily, the fewer words on each topic share out more experience working with the diagrams, and the text is admirably helpful. You can usually get the right idea on a UML concept within a minute or two by searching from the index to the text, or simply from the inside covers of the book, which also provide a page-number index to the book.
Topics covered include techniques (supported by different types of diagram) for eliciting requirements, describing object behaviour and interactions, modelling object classes, purposes, and control structure.
This is in fact a very wide range of techniques, ranging from working out requirements with users right through to coding. Obviously in the space of under 200 pages the book cannot deal with all the techniques in detail. What it does do is to introduce about ten of the most useful of the numerous allowed types of UML diagram. There are chapters on use cases; class diagrams; interaction (i.e. sequence and collaboration) diagrams; package, state, and activity diagrams; and even physical deployment and component diagrams.
These chapters are bracketed by a brisk trot through a lightweight "low-ceremony" version of the development process, with reference to the Rational Unified Process (RUP) at the front, and at the back a helpful pair of appendices on the uses of the techniques, and changes between UML versions. The book is not meant as an account of the software or requirements engineering processes, though it does contain useful hints and advice on these. It also cross-refers the reader to approaches such as Extreme Programming which come from the same object-oriented world. For the curious, the introduction even ventures a brief history with names and mini-biographies of the main players.
The book is written in a relaxed, even conversational style, and the author allows himself some jokes. The discussion is simple and down-to-earth, and the examples are easy to follow. The UML syntax itself is neatly summarized inside the front and back covers, and explained clearly and informally in the text. The activity diagram, for instance, is exemplified by a small composite diagram with a fork and join, a branch and merge, activities in parallel and start and end points. The text discusses quite helpfully how these diagrams can be used to describe sequences of activities (functionally), without necessarily assigning activities to (software) objects. Variations such as overlaying an activity diagram on a set of swimlanes to indicate the actors (i.e. roles) responsible are also helpfully drawn and discussed.
It is perhaps the semantics of some UML diagrams that is most questionable, and indeed critics have launched numerous attacks on this aspect of the UML (not to mention its complexity). Fowler is very open about the weaknesses: he explains where he believes rigour and a measure of complexity help, and where they get in the way. The wider debate is of course out of the book's scope.
The text is pleasingly frank about some of UML's shortcomings, explaining that the misleading term 'Actor' should have been 'Role' but was supposedly mistranslated from the Swedish (of Jacobson). Aktör has shifted its meaning from the original French term, and is ambiguous in meaning between Actor and Role in Swedish, so perhaps there was a muddle.
The diagram shown above (from the 2nd Edition) is not a good example of clarity; of course, it deliberately includes all the different elements but it does illustrate how easy it is to create visual clutter. The semantics are not agreed either -- do actors include external systems and humans, or only the initiators of use cases, or anyone that gets value from the use cases? The book recommends the last of these, as well as taking care to examine the meaning of making systems into actors. Often, you need to go and "find out what the real user goals are, and consider alternative ways of meeting those goals". In other words, use cases should describe problems, not solutions, even when the existence of some systems is already known or assumed. Elsewhere, Cockburn stoutly criticises the tendency for tool vendors and their customers to stress the drawing of use case and other diagrams over the accurate description of real-world processes and models in appropriate text and attributes. Fowler wisely agrees:
"I must stress that you don't need to draw a diagram to use use cases. One of the most effective projects I know [kept] each one on an index card..."
This is a useful little book for those new to the UML and as a quick reference for more experienced developers who may have knowledge of, say, UML 1.1. The UML is now an OMG Standard, as well as being the de facto industry standard for object modelling. This was of course Rational's objective in bringing together Booch, Jacobson, and Rumbaugh (who have written the much larger but very helpful UML Reference Manual). There is inevitably a degree of self-referential definition within such a world: the reader needs to know what an interaction diagram is in the introduction, but needs to read the text to find out. Ultimately Fowler does an excellent job in showing how the parts of the UML fit together, and he does the reader the service of saying how he personally gets the parts to work.
Engineers, programmers and students will find this a valuable introduction and quick reference to the UML.
© Ian Alexander 2000, 2004, 2005
You may also like:
