Rating: 
Summary: Recommended, but some code comments would have really helped
Review: 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.
Rating: 
Summary: Uncle Bob's advice could be harmful to your career
Review: 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.
Rating: 
Summary: An excellent teaching tool!
Review: 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!
Rating:
Summary: The Only UML Book You'll Ever Need
Review: 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!
Rating:
Summary: Good for java designers team
Review: The book is giving you a perfect idea in how to use UML for better java projects design, because not all java programs need UML, so when to use UML and when not to use it is covered in this book, also if you feel that UNL is a difficult thing to deal with, then the book makess it easier for you, the book also is covering XP process which may be used in your project development.
Rating: 
Summary: "Why I Hate UML" by Robert C. Martin
Review: 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.
Rating:
Summary: "Why I Hate UML" by Robert C. Martin
Review: 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.
Rating:
Summary: Outstanding UML and OO Design Essentials Primer
Review: 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.
Rating:
Summary: Best introduction to UML, especially if you use Java
Review: 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.
Rating:
Summary: Down-to-earth wisdom, tips, tricks, techniques
Review: UML For Java Programmers by computer expert and consultant Robert C. Martin is a first-rate guidebook to UML especially as a useful tool for Java developers. Shining the spotlight on the UML 1&2 features most relevant to writing better Java code, and ignoring those UML features that have nothing to offer Java, UML For Java Programmers is packed from cover to cover with problem-solving examples, down-to-earth wisdom, tips, tricks, techniques and so much more. UML For Java Programmers is very highly recommended -- especially for Java programmers who are new to UML.
|
