ISBN:0131428489Book Description
Preface It was 1991 when I got my first copy of Booch's classic Object Oriented Design with Applications (first edition). I had learned several OO languages by then, including C++ and Smalltalk. I was absolutely thrilled by the concept of Booch's notation. Those clouds! Those relationships! The message passing diagrams! As a software designer it was just what I needed! I also needed a tool to draw the diagrams. So I started writing a CASE tool in Think-C for the Macintosh. I remember spending a lot of time getting the cloud icon to look just right. Though I never finished that CASE tool, one artifact of it remains. The cloud icon I created has followed me from computer to computer, from Macintosh to Windows, and has been the source of all the cloud icons I have ever drawn in any book or article. I remember the incredible day that my office partner, Billy Vogel, was talking on the phone to a head-hunter. He looked over at me and said: "Uncle Bob, I think you should take this call." The recruiter was looking for consultants to work at Rational, with Grady Booch, on a CASE tool to draw Booch Diagrams! How could such luck drop right into my lap? A dozen years have passed. I still have my original copy of Booch's book. It's a bit frayed and dog-eared, but the book still has the power to evoke echoes of the same old thrills. Today, of course, we use UML -- the one-third offspring of Booch's notation. UML is a powerful and comprehensive notation, far grander in its sweep and scope than Booch's was. Whereas Booch's notation was good for drawing pictures of software, UML is apparently good for creating models of just about anything you can imagine -- or so say some of its pundits. As grand and all-encompassing as UML may be, I find that a reasonable subset is all I need for drawing pictures of software. The same kind of pictures I used to create with Booch's notation.This book is about that subset, and about those pictures. This book takes the vast richness of UML 2.0 and boils it down to the essence that every programmer needs in order to draw pictures of his, or her, software designs. This book reduces the panoply of UML widgets, icons, diagrams, relationships, and arrowheads, into a simple suite of tools that Java programmers can use to record their design decisions. Make no mistake about it. This book will not teach you everything about UML. But if you are a Java programmer, it will teach you what you need to know. /p>
Reviews From AMAZON.COM
Uncle Bob Could Have Done Better
A book with this title is much needed. Sadly, Uncle Bob's advice to write your UML on a napkin and later throw it away is not what we need. He is so flippant about UML that he comes across as arrogant and having much less credibility than he probably deserves. My advice to Uncle Bob: adopt a more humble attitude that will better serve your readers and write your second edition with a focus on accomplishing what the attractive title promises.
Good book, sprinkle with salt
I just led a study group of 15 people reading this book. The book is very down-to-earth with a lot of practical advice for how a group of programmers can effectively use UML to aid in communication of ideas across a team.
It only covers 5 of the 11 or so UML diagram types, but it covers the ones that will really be used by java programmers day-to-day, in design documents, whiteboards, etc. For each it talks about real world, practical approaches on how to use them to communicate ideas.
Bob Martin is an 'Agile' guy, and it really comes across in this book. A lot of his arguments come down to "A lot of the pomp and circumstance surrounding UML is pretty useless, except when it isn't", and while he tries to instill when that will be, that kind of knowledge reaslly only comes with experience. He also advocates that the diagrams should be 'lightweight enough to be thrown away', which is an opinion that can rub a lot of people the wrong way, is a very valid position. While there is nothing inherently 'good' or 'evil' about UML, it is often used to help create a 'documentation glut'. I have seen situations where the documentation falls out of sync with the code, or worse... the code can't change because the documentation cannot be updated (because of some beurocratic red tape). The author seems to have had some bad experiences along these lines, and seems to have a lot of reactionary thoughts.
This is good! while a couple of other reviews here have called such advice 'impractical' (which it can be in a lot of environments), the information in the book is very valuable and the thought provoking nature about 'be as lightweight as you can' and 'avoid the UML police' are useful as long as you can take them with a grain of salt and apply the advice judiciously in your own work environment.
I definitely recommend this book to Java Developers who need to better communicate their ideas to groups of other developers. After reading this, there are other references should you need to 'go down the UML Rabbit Hole' a little deeper. this book is better first though, because it puts the relevant diagrams into practical context.