The best UML book you can read is one that you didn’t even know it existed. One that has zero reviews on Amazon. And it wasn’t written by Martin Fowler or “The three amigos“. Instead, it is written by a group of Austrian professors! (but don’t worry I’m not going to ask you to read in German). Yes, I know, I’ll have a hard time trying to sell you this book and convince you that indeed, this is the UML book I recommend the most (even if there are other good UML books too).
First things first, this is the UML book I’m talking about: UML @ Classroom
The book covers the five main UML diagrams (class diagrams, sequence diagrams, state machines diagrams, activity diagrams and use case diagrams) and how they complement each other to model a software system using simple but intuitive examples. The book covers the UML syntax (as expected) but also the semantics of the language and its pragmatics (that is, how to actually use the language).
Why I like this UML book
After reading the book cover to cover, let me give you a few reasons why I enjoyed and I think you will too
- It’s written by people that have been teaching UML for a long long time. And not to a bunch of undergrads, we’re talking thousands. Around 1000 students every year take their UML course. And this book is the result of all these years of experience teaching UML. This is something very few people can claim and something that you feel in the book
- It’s more than a book. They have a complementary website with plenty of slides you can use to teach UML yourself following the book guidelines (creative commons license)
- It includes summary tables for each kind of diagram that can be used as UML cheat sheets and quick reference guides when needed.
- It’s able to clearly explain complicated UML semantics. For instance, the difference between subtyping , <<extend>> and <<include>> relationships between use cases (something many novices struggle with, no surprise it is a frequent topic in Stack Overflow)
- It’s not only about the syntax. Similar to Ambler’s book , they also take the time to comment on typical mistakes people do when drawing UML models and include recommendations and best practices to get started.
- They go deep in the semantics when needed. Many books will describe the syntax of UML but few will put the effort in making sure you clearly understand what you are modeling. A good example of this is when the authors explain the differences between ternary associations and (in theory) equivalent designs where the association is “reified” (i.e. depicted itself as a class). I’m sure if I ask around most people won’t be able to explain the semantic differences between the two designs! (if you want to know, read the book 🙂 )
- The integrated examples at the end help the reader to put everything in perspective
And a few little things I don’t like about it
There is always room for improvement so let me also be clear on some aspects that could be improved (if I only say good things you’ll assume I’m paid by the authors to write this review, rest assured, I’m not!).
- Profiles are only introduced at the end. While it’s true many readers won’t go around defining stereotypes or full profiles, most of them will run into at least some stereotypes (it happens even in the book itself, for instance when talking about the relationships among use cases we mentioned above) early on and may wonder what they are until they reach the end of the book.
- They mostly ignore OCL . Sure, OCL is not part of UML but a language that complements it. Still, any serious project will require adding to the UML models some textual annotations to describe or specify things that are difficult to model graphically. OCL is the best language for that.
- You feel the book is written by academics and published by a science publisher. The design of the book looks too serious sometimes which may scare out some readers. For instance, citations to other works are added using a numbered reference style (like “[1]”) as if we were reading a scientific paper
- Not exactly part of the “cons”, but worth saying that the book will expect you to put some thinking into it. It’s indeed a book for beginners but learning requires attention and focus. If you just want to draw and not to model, then take an easier route to UML.
This UML book is for you if:
you’re looking for a book with a good balance between the very shallow and notation-oriented UML distilled, the complete coverage of the “official” UML guides and the advice for professionals in Ambler’s book.
And if this book opens your appetite for more modeling-related stuff, you may want to consider my own model-driven software engineering book next!
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Thanks for a good reference.
As a matter of debates, I don’t think that Profiles and especially OCL are so important for the student community. 😉
While most of the engineers will face creating diagrams and using UML, very few will actually touch OCL. I also do not envie those guys, since OCL is very particular language, hard to deal with and debug. Hope there will be a better proposal of a more convenient constraint language – easy to use and debug. On our side, we are happy with Java+API for this. 🙂
For profiles, many good industrial engineering practices only restrict UML without particular need for Profiles. I would go for Profiles when required to beautify and simplify UML for particular domains, for example SQL design.
OK, it does look like a good book. You have it first on your list of good UML books, which makes sense given what you say here. But you say you recommend “Applying UML and Patterns” by Craig Larman as a text for an introductory course. Why is that?
I’d say this book is better for an “Introductory UML course”. Larman does a better job for an “Introductory Object-Oriented Analysis and Design with UML” course.
(Larman goes beyond teaching UML and introduces a number of pattern and analysis+design concepts but as a trade-off it puts less attention in the language parts)
I hate to admit that you’re probably right regarding OCL (though this is a situation I’d like to see changing in the future, not sure the problem is in the language, I think it’s more in the tools that are not good enough to do interesting things easily with OCL)
For the profiles, my point is that many readers will run into examples of profiles even if they never use one themselves (this even happens in the book) so it may be a good idea to make the reader aware of this “strange” << >> symbols he’ll probably see at some point.