Customer Reviews

UML for Java™ Programmers

5 star:		(8)
4 star:		(2)
3 star:		(0)
2 star:		(1)
1 star:		(3)

 

 

This book could have easily been titled, "Bob Martin hates UML". Actually, that it isn't quite fair. Only the first part should have that title. The second section should be named, "UML is boring so let's design an object oriented coffee pot". The last section could be titled, "I don't have anything else to say so let me pad the book with 50 pages of Java code".

As far as UML goes, the book covers five diagrams. The author's advice can be summed up as "don't use UML except on the back of a napkin that you immediately throw away". Use cases are reduced to four pages and he advises against getting any real details. He likes sequence diagrams as long as they are so trivial that they impart no real information. He gives an example of a "too complex" diagram that in half of a page clearly and simply shows the inter-relationship between six classes. Trying to understand this same relationship with code could take hours.

The big problem for this book is that the author is in love with his process. He is an XP proponent and uses this book to push the XP paradigm. The problem is that a lot of programmers that are not using XP will not realize how XP-centric this book is from looking at the title. XP is not the only process and many programmers work in environments where designers design and developers write code. This book will not help them and could actually hinder them by giving them the wrong idea about the usefulness of UML. If you are looking for a book to help you understand how to use UML to design and develop complex J2EE applications then I strongly recommend "Enterprise Java and UML" (ISBN: 0471267783). I would avoid this book.

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.

Before you buy this book, consider your career, what's happening in technology. The advice this book offers is from a programmer-only point of view that may work quite well for small programmer teams, but not scale in the world I'm in--namely aerospace with complex comm protocols, embedded systems, multi-million lines of code for ground systems, hundreds of programmers, testers etc. Many of the premises the book is based on are not true. 1. The long pole in the tent is not the programming but the maintenance. It's when Uncle Bob has long left and the poor guy who has to fix the bugs left behind. Although Bob, who advocates throwing out UML regularly, can recall the key diagrams from 5 years ago, that certainly does my project little good. The architecture begins to rot because of incompleteness. 2. Uncle Bob and most other hacker-oriented programmers think UML is only for communicating to other people. Thus those who demand precision and detail are seen as UML police, creating a waste of documentation, etc. Uncle Bob promotes minimalism and thinks all you need is a whiteboard with little incentive to electronically manage it. He is living in a world of simple programs. We are way beyond that. In reality, our systems are too complex for us to analyze and build without automated tools. We don't have the luxury to ignore the millions of lines of legacy design. We feed UML to autoanalysis tools to find new design flaws early--before code is cut and tested. It costs us $1 to find it in design, $10 in code, and $100 in test. For example, we autoanalyzed UML from 3 large development teams and discovered some subtle errors. This was part of a system with over 6000 classes. Try doing that on a chalkboard. 3. UML should be thought of as an architecture-centric representation that lives throughout the entire life cycle. If you only think of UML as only a means to get to code, you'll continue to spend lots of money to reengineer your legacy system when you change jovial to Ada, Ada to C++, and C++ to Java, Java to ? 4. Uncle Bob doesn't think augmenting UML is worthwhile. Thus the major UML 2.0 enhancement using Profiles for domain-specific augmentation is totally ignored. Wow, thanks, Bob. I didn't know the 2 years of work the OMG started to develop Real-time, schedulability analysis profiles was just a waste of time. There is no mention of executable UML. On the plus side, Uncle Bob is an excellent programmer/designer and you can learn some good techniques to iteratively refine your design. His recommendation to keep conceptual models separate from implementation models is sound--but rarely followed in practice. (but augmentation could help here) His principles are generally OK, but if you want those, get his other book on Agile SW development. If you see your current career as just a programmer, you'll love this simple view of UML and racing to code. If you plan on becoming a system engineer/architect for large systems, be careful if all those programmers you manage, follow Bob's minimalistic advice. Some bad attitudes are hard to break--even when the technology that formed them no longer applies.

Before you start rolling your eyes over yet another UML book, buy this gem and give it a serious read. It's like no other UML book I've read. It's also the only UML book I'll ever need.

For starters, it's far too enjoyable a read to be lumped in with other crusty UML books. More importantly, it's Uncle Bob's no-nonsense, practical approach that sets this book apart. He's not afraid to tell you when some UML diagram or adornment is more trouble than it's worth. Indeed, throughout the book he puts the use of UML in its rightful place. Indeed, I wish this book had been around about 10 years ago, before we somehow got it into our heads that the models were the software.

After putting UML in its place, Bob teaches you how to wield it as a tool to assess the quality of a design using sound object-oriented design principles. Bob is a programmer's programmer, so everything he does is backed up with code. It's all great stuff you can start applying immediately.

We don't need yet another UML book, but we do need a book that teaches us how to use models to our advantage. This book definitely hits that mark!

There are many books that can be used to learn the Unified Modeling Language (UML). However, in most cases, they are not much more than a description of the language. Like the languages that humans use to communicate with each other, you can only learn UML if you use it in contexts that are familiar to you.
Martin starts with the initial assumption that the reader is fluent in Java and uses that as the basis for teaching the fundamentals of UML. If you are in this category, then I can strongly recommend the book. Unfortunately, this means that if you don't know Java, it will not be that much help to you. Early in the book, Martin eschews a lot of Java code, choosing to concentrate on the diagrams. Skeleton code is used, and it is as bare as it could possibly be. In the later sections, large blocks of Java code are used, particularly in the last chapter, which is the case study of a remote service project.
While I considered the combination of Java code and diagrams to be well done in the early chapters, there is a fundamental weakness in the last chapters. Martin made the decision to avoid putting comments in the code. Therefore, there are segments of code multiple pages in length where there is not a single comment explaining what it does. While I concede that it is possible to determine what the code is doing, that understanding does not come easy. In several cases it took me a significant amount of time before I was able to understand the whats, whys and hows of exactly how the parameters of the project were being implemented.
The first part of this book can be used to learn UML in a context that will be familiar to experienced Java programmers. However, while the later chapters can be understood, getting there requires a lot of effort, in my opinion, too much for a book where the goal is to teach UML rather than Java.

This book is a gold mine of insights into what is essential about OO design, UML notation, and their relationship to writing sound code. The book's focus is on how to create and understand essential UML design artifacts and fundamental OO design concepts to help you write better code. As the book proceeds, excellent examples are provided to ensure that the reader understands the crucial aspects of transforming code to UML and vice versa. UML's role in the development process is put in proper perspective as a tool rather than an end in itself. All the standard UML artifacts are covered: Class Collaboration, Sequence, and Object Diagrams, as well as Finite State Machines (the author isn't a big fan of Use Cases but they're briefly covered too). Moreover, the book includes excellent chapters on sound OO design principles for not only class hierarchies but also package and component building as well. A terrific synopsis of the author's take on an agile development methodology is presented and there are some meaty case studies against which one can try out his/her newly gained knowledge of the topics covered. If you want to learn solid OO design concepts and how to reliably and accurately represent them in UML then this book is for you. I'd also recommend the author's other recent book, Agile Software Development Principles, Patterns, and Practices which won a Software Development Magazine Jolt award.

This is a great book for learning or improving with UML. Topics are introduced at a level appropriate for beginners but each topic progresses at a nice pace into intermediate territory. There's even advice in here suitable for the best programmers I know.

I love the liberal use of source code throughout this book. We model in order to write code and Bob Martin clearly presents that perspective in this book. If code is the goal then it is worthwhile understanding the relationship between our models and our code. While all of the example code is in Java I'd still recommend this book to anyone who wants to learn more about modeling and who has even a passing familiarity with Java. C++ or other programmers should have no problem reading it, for example.

I like that the author goes beyond just describing each of the UML diagrams and takes the opportunity to teach good design while he's at it. As just one example, the "Single Responsibility Principle (SRP)" is discussed. This principle tells us that "a class should have only one reason to change." In other words, don't put everything into one class. That's pretty obvious but it's still a common mistake. The book shows a brief snippet of Java code that violates this principle and then shows the UML for how to design it better. More importantly, we're told how to recognize this problem in UML diagrams we create or inherit.

This book addresses one of the big problems I've had with many other UML books--it tells the reader right upfront that not all diagrams are equally important. I love that the author tells us things like that "in the last decade I think I have drawn less than a dozen object diagrams of this kind." That's great to know! Because many other books try to cover every diagram and modeling technique they all end up appearing equally important. In this book Bob Martin tells us that he's only going to cover what we really need to know to be better Java programmers. He achieves that goal with flying colors.

Oh! Come on. I just got the book today. What is this? Chapter 5, very important part of UML titled "Use cases", has only 3 pages with a single image of "System boundary diagram"!!! Is this that really matters in the Use cases? For haven sake! I run out of words to explain the quality of this book. Book is total disaster. Chapter 6, OOD, 20 pages, 6 subchapters, Single Responsibility Principle, etc. Who cares about RSP, OCP, LSP, DIP, ISP. Why whould this be more important than Activity diagrams explained in details with numerous examples.

What is this book about anyway. Skipping detailed explanation of use cases or of activity diagram or numerous important items in the UML world while providing me chapter about OOD, Iterative Development (3 pages), Planning.

Then again State and FSM diagrams only 7 or 10 pages. Why is this called an UML book?

Average free tutorial on UML is much better than this. Just go to google, IBM developer works, Borland community, wherever and get a decent UML introduction.

Is this some kind of a joke? I wonder who could rate this book so high, 4 stars in average! And what does give this book a "Java" in title? Perhaps several interfaces written in java? Wow! How about making an C++ edition, with cca 240 pages as well.

Oh come on, close this page about this book, go home, go to some other UML book. If only I had a chance to find and see a free preview of this book I would have never bought it.

Look for the free sample of excerpt of the book first somewhere on the web, ed2k, wherever, before buying it. - I would never have bought it.

Unlike a number of other UML books, this one is not only well-written, but interesting to read and it will make you a better programmer in addition to teaching you basic UML. The book doesn't cover UML in a void, as most do, but rather explains how, when, and why to use modeling, and probably better, when NOT to use it. The author understands that the models are simply descriptions of the code to make the code more understandable, and that models that do not do this are useless.

The topic of UML is not covered completely, but the level of coverage is appropriate to the subject matter. I particularly liked how the author showed that models can be used to identify bad code, and discussed some basic OOAD principles. The author also advocates a modified XP approach to design, and while my shop is not XP-based, there is a lot of good information that is not dependent on an XP approach.

This book will never be far from my desk so I can refer to it again and again.

Years ago I was working on a very complex project. One of the team members convinced the management that we needed CASE tools. After spending $$$ on them and countless hours learning them, we began to use them. I soon became convinced that they provided little to help the process and in the end, they nearly sunk the project. It was yet another pseudo code that did little to aid in the process of generating real code. So when UML came on the scene, knowing it's roots I was very suspicious. After looking more into it, I was pleasantly surprised by UML. I believe that most of my objections to CASE were addressed, but not all. I found that too many had simply replaced one dead weight with another. Again countless hours were spent generating documents that no one ever read or cared about. Yet UML was a valuable tool, why was this so? I shared this with my grown son who directed me to Martin's book, and it became clear that a valuable tool was simply being misused. It is obvious that Martin has been in the real world and knows when to use a tool like UML, how much to use it, and what it is best suited for. Rather than throwing the baby out with the bath water as I was tempted to do, Martin points out that UML is a good communication tool best used at a white board with a small team. Once everyone is on the same page, the team can proceed as a team. Martin doesn't over burden you with a lot of useless diagrams. He poses a problem, shows how UML addresses a design issue, and shows you the resultant design change. I subscribe to many of the XP techniques because I have used them and found them useful with the exception of pair programming which I did for a while and found it to reduce the productivity to the lowest common denominator between the pair. I highly recommend this book.