UML for Java™ Programmers [Paperback]

Robert C. Martin (Author)

Book Description

ISBN-10: 0131428489 | ISBN-13: 978-0131428485 | Publication Date: June 6, 2003

The Unified Modeling Language has become the industry standard for the expression of software designs. The Java programming language continues to grow in popularity as the language of choice for the serious application developer. Using UML and Java together would appear to be a natural marriage, one that can produce considerable benefit. However, there are nuances that the seasoned developer needs to keep in mind when using UML and Java together. Software expert Robert Martin presents a concise guide, with numerous examples, that will help the programmer leverage the power of both development concepts. The author ignores features of UML that do not apply to java programmers, saving the reader time and effort. He provides direct guidance and points the reader to real-world usage scenarios. The overall practical approach of this book brings key information related to Java to the many presentations. The result is an highly practical guide to using the UML with Java.

Editorial Reviews

From the Back Cover

UML for Java Programmers

Robert C. Martin

All the UML Java developers need to know

You don't use UML in a vacuum: you use it to build software with a specific programming language. If that language is Java, you need UML for Java Programmers. In this book, one of the world's leading object design experts becomes your personal coach on UML 1&2 techniques and best practices for the Java environment.

Robert C. Martin illuminates every UML 1&2 feature and concept directly relevant to writing better Java software--and ignores features irrelevant to Java developers. He explains what problems UML can and can't solve, how Java and UML map to each other, and exactly how and when to apply those mappings.

• Pragmatic coverage of UML as a working tool for Java developers
• Shows Java code alongside corresponding UML diagrams
• Covers every UML diagram relevant to Java programmers, including class, object, sequence, collaboration, and state diagrams
• Introduces dX, a lightweight, powerfully productive RUP & XP-derived process for successful software modeling
• Includes a detailed, start-to-finish case study: remote service client, server, sockets, and tests

About the Author

ROBERT C. MARTIN is President of Object Mentor Inc., a leading consultancy in object-oriented design, patterns, UML, agile methodologies, and eXtreme programming. He authored the JOLT Award-winning publication Agile Software Development: Principles, Patterns, and Practices (Prentice Hall) and the best-selling Designing Object-Oriented C++ Applications Using the Booch Method (Prentice Hall). He edited Pattern Languages of Program Design 3 (Addison-Wesley), edited More C++ Gems, and co-authored XP in Practice with James Newkirk (Addison-Wesley). A well-known speaker at international developer's events, Martin edited the C++ Report for four years.

See all Editorial Reviews

Product Details

• Paperback: 288 pages
• Publisher: Prentice Hall (June 6, 2003)
• Language: English
• ISBN-10: 0131428489
• ISBN-13: 978-0131428485
• Product Dimensions: 9.1 x 7 x 0.7 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars  See all reviews (14 customer reviews)
• Amazon Best Sellers Rank: #340,432 in Books (See Top 100 in Books)
  • #46 in Books > Computers & Technology > Programming > Software Design, Testing & Engineering > UML

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

27 of 36 people found the following review helpful:

2.0 out of 5 stars "Why I Hate UML" by Robert C. Martin, July 10, 2003

By 

Thomas Paul (Plainview, NY USA) - See all my reviews
(VINE VOICE)    (REAL NAME)   

This review is from: UML for Java™ Programmers (Paperback)

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.

5 of 6 people found the following review helpful:

4.0 out of 5 stars Good book, sprinkle with salt, May 17, 2005

By 

David Bock "javaguy" (Hamilton, VA USA) - See all my reviews
(REAL NAME)   

Amazon Verified Purchase

This review is from: UML for Java™ Programmers (Paperback)

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.

26 of 37 people found the following review helpful:

1.0 out of 5 stars Uncle Bob's advice could be harmful to your career, June 14, 2004

By 

Phillip P. Schmidt "philschmidt" (Los Angeles, CA USA) - See all my reviews
(REAL NAME)   

This review is from: UML for Java™ Programmers (Paperback)

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.