When I started reading this book I had no real idea of
what the UML is, so I thought a "tutorial" is a good way
of getting a feeling for it. I read this book from beginning
to end, and I guess now I have a "feeling" for it. Not more
and not less. In that sense the book can be a suggested
reading. But some knowledge of a 00P-language is definitely
mandatory.
I am surprised by the fact, that many people seem to use this
book mainly as a reference. This is definitely no good reference
because the real content is much too sparse (but verbosely expressed)
and introductory to serve as a reference. If one wants to know something
specific of a given UML feature, he most of the time wont find sufficient
information in this book.
But even the few things it covers are not always comprehensible
for a novice to the UML, e.g. the chapter on "Common Mechanisms"
gives absolutely no idea on what these things really are and
how to use them (like stereotypes). And sometimes one just finds
sentences like "you may also draw this kind or that kind of
relation between these kinds of things" without any further
explanation, what kind of semantics this could have. This seems
to be the main dilemma of this book, and the UML in general,
that they try to explain their models without giving
semantics. Also this book "smuggles" semantics in by
referring to OOP-languages, but in an inconsequent manner.
Sometimes they do, sometimes they don't. So many things stay
completely unclear to the reader.
A whole lot of the text is written in an maddening verbose, complicated
way, like "A message is a specification of a communication between
objects that conveys information with the expectation that activity will
ensue.". I have sometimes the impression, the UML people try to
hide the triviality of their models behind an almost pseudo-philosophical
blurry language. Why? To ease the sale of lots of seminars?
One can read David Harel's original paper on Statecharts, and after
just a few pages one knows everything in great detail. With this
book you read hundreds of pages, and still you just have a
a blurry, minimal idea of the "things" of the UML (they really
call it "things").
After reading the 450 pages I had the impression that all that
could have been said also on 40 pages. In that sense this book
is a great waste of time. On the other hand it gave me an
introduction into it, and at least now I have a (misty-eyed)
big picture of what all this is about. So, if you have the
time, it might be a useful introduction. But there must be
much better ways of explaining these (trivial) things.
