Craig Larman's classic has reach 10 years of prime position on my professional book shelf, the 1st edition now replaced with the 3rd. Whenever anyone asks for an introduction to UML, this is always my first recommendation. Though the book focusses on software construction from scratch, it still contains much brilliant guidance for enhancement work or implementation of software packages.

This book takes you in a logical, distilled process through pragmatic application of Unified Modelling Language on real projects for which people pay. Of course the examples are simple, but relevant and helpful. The book is chock full of diagrams and little text, which makes it quick to read and easy for reference.

You could do little wrong if you used only this book to guide your first application of UML to a real project.

I have 30 years in the industry (and in different industries in IS management) and one thing I dislike is the author's persistence do down-grade the waterfall or modified waterfall models. He should be more objective on his comments since the waterfall and modified waterfall do have their merits on projects -- refer to "Rapid Development, Training Wild Software Schedules" by Steve McConnell, Microsoft Press, ISBN 1-55615-900-5. I have used them very successfully on big programs. The key here is, with any model, in order to be successful you need quality communications with ALL stakeholders. Just like in our personal life's, communications is everything; the models can be secondary.

The author should also strictly follow the attributes of writing good requirements. On page 72, he wrote for "frequency of occurrence", "Could be nearly continuous". Now, I ask, how ambiguous is that????

As others have pointed out, the content on OO analysis and design is excellent. Equally important - Larman's book is also an excellent on "process".

Unlike many books that simply focus only on "programming", Larman gives you a working examples and excellent advice on overlapping fields like "requirements", "testing", "architecture" and "project management".

Craig Larman's "Applying UML and Patterns, 3rd Ed" is a wealth of practical advise, covering *all* significant aspects of successfully defining and implementing a non-trivial software project. If your team were to choose only one book as your "Bible" - this would be that book.

As pointed out by many, this book is a very nice introduction to Object Oriented Analysis and Design. The author's explanations were very clear. This book covers agile practices, UML, many patterns including Gang of Four (GoF), and software architecture. Overall I really enjoyed reading this book. From an industry standpoint as well as an academic standpoint, I believe this book does an excellent job. This book will be part of my library for a long time to come. Highly recommended.

Well, I think this book should be a must read for any pro or beginer in the software design/build area, it takes you from the start trying to make you understand what your client want you to understand, until the best practices to have patterns, tests, and a good team development, so do not hesitate to buy it!.

I had a degree in Computer Science from a respectable university when I read the book. Still, I learned from the book so much that I realized I barely scratched the surface of OO design before reading it.

It teaches OO Analysis and Design using many techniques, such as writing use cases, modeling the business domain, drawing UML diagrams, using CRC cards, and going through agile iterative development cycles.

This book will not only provide you with a chance to learn OO Design, but also requirements gathering, analysis, and basic architecture and project management.

This book is a great introduction to OOAD, agile development, Patterns and UML. It goes from the basic concepts to real world applications. It is has lots of content though but it is worth reading it from beginning to end.

I read the first edition of this book years ago when I was making the transition to objects. It was about the tenth book on the subject that I had read, but it was the first one that consistently anticipated the questions that came up when I was actually trying to build something using UML, long after the hype and "objects will save us" party atmosphere had died down. Craig Larman has carefully remembered, or has taught this enough to have been reminded of, the kinds of questions software practitioners actually encounter on the way to building systems using UML. This 3rd edition is twice as big as the first, and it is twice as good only because it is twice as much of Larman's excellent teaching.

This book is so good that even developers experienced with UML, the GRASP patterns, and agile development methods will gain from it, reminding us once again to balance the best practices that we apply perhaps a little unevenly at times. It is clearly a book by someone who has been there, and has remembered what it was like during the learning process. But perhaps its greatest strength is its application of very good theory in a very pragmatic way, in short, its balance. This is one of a very few books that I recommend to everyone I know in software.

Currently the best and famous OOAD books in markets. It covers detailed information and techniques(e.g. GRASP)on each steps for the whole process of analysing and designing OO applications and there're examples for illustration. A must of OO architect or equivalent.

I have to disagree with whoever said this is a great book for beginners. There is too much information to the point of overkill. I am getting more enlightenment from going to www.omg.org and reading the UML specs. The author interjects way too much unnecessary information, then takes a good example model (like on the back page) using default language, only to throw "veggieburger" in the middle of it all, which to a novice lends only to confusion.
I am in the middle of reading this so I may change my stripes by the end, but I really don't see it happening. "UML 2 Toolkit" and "Head First Design" have helped me learn this stuff much faster.

I've been reading this book over the holiday break. I find the introduction to iterative development, Unified Process, and agile approach refreshing. The discussion on patterns is something of a review to me because I've already read the GoF book, and many patterns are just common sense that a good experienced developer should already know. The way to apply UML in iterative development in UP fashion using GRASP is the goal of the book, and it is very educational. However, I find the book is geared towards beginners. The text is easy read; fonts are relatively large as compared to technical books; and the author seems to repeat the idea over and over again while incrementally adding a little idea with each repetition. And I am not referring about the iteration development process. I am referring the author's style of writing. To an experienced developer, the content of this book could have been cut in half. I am taking 1 star as a result of this. Otherwise, a fine book.

I have been using the 2nd edition to teach a semester long "Object-Oriented Software Engineering" subject at the School of Information Technology (James Cook University, Townsville, Australia) for the last 4 years (2002-2005), see

http://www.it.jcu.edu.au/Subjects/cp3120/2004-2/CP3120.HTML

On the positive side: It improved my own design and code dramatically. It looks like the Controller pattern has been overlooked by other pattern books. The book provides a seamless recipe for delivering design/code from the use cases (this is the only book that I know that actually does that). So I strongly recommend the book as a self-study book for a professional programmer.

However as a teaching tool: here are some of the problems that forced me to look for a different text book for the next year:

1A. The book still does not come with lecture notes. (I have to write my own for the 2nd edition)
1B. It does not have exercises/problems for teaching.
1C. It has no realistic java code examples (the old problem with explaining concepts using toy-examples).
1D. It completely ignores interaction with GUI (saying .... we are not modeling outside the domain?). This did not help as all our assignments have complicated GUIs (preparing for the real-world jobs).

2. Covering UP/RUP and patterns in one semester is too much. It is better to do less but better. UP/RUP is more relevant to a generic software engineering subject as the current best practice in SE. Plus after teaching from the book for 4 years, I cannot see how anyone could implement the UP following the book. You would still have to get a different book for it.

3. Some (if not most) students were really struggling with the book. Larman explains things in too many words (actually pages and pages of it), which is even for a native English speaker is a lot of reading for little TESTABLE reward, not to mention our Asian students.

4. Larman is expensive and physically big (less chances for students to carry it around for tutorial and lectures). The 3rd edition is even bigger.

Dmitry
dmitry.konovalov@jcu.edu.au

If you are looking for a UML book that details every single aspect of the UML, then this may not be what you're looking for.

This book hit me a bit by surprise. As I get more and more into OOA/D I found that learning the UML would probably be very beneficial. I decided to go ahead and pick up a UML primer in hopes of learning everything about the UML. I decided on this book. This books main focus isn't exactly on the UML (although you learn a great deal about that too). Instead this book focuses more on OOA/D theory and the unified process to software development. You learn all about how to create software in iterations rather then the common waterfall method. In a nutshell, you learn that it's not really such a good idea to plan out every aspect of your system, do all of the architecture and then implement (this is known as the waterfall method). Instead you learn about how to create software in iterations, treat each iteration as its own project and build to adapt for potential changes.

Along the way of learning OOA/D, the unified process and design theory, you also learn how to create the most common UML diagrams. This includes use case, domain model, interaction, class diagrams and others. Craig Larman also touches up on other topics such as design patterns, visual thinking and much much more. There is a whole lot of ground covered in this book.

While I was reading this book I was constantly reminded of Steve McConnell's writing style (in case you didn't know, Steve McConnell is the author of Code Complete 1st and 2nd edition, Rapid Development and a few other epic software titles). The writing style is very similar, which is a huge plus - as I am a big fan of Steve McConnell.

I highly recommend this title to all software developers. This is one of those eye-openers that will make a few flickering light bulbs shine brightly. If you are a fan of Steve McConnell books then I am almost 100% sure you will benefit from this exceptional title. Actually, whilst reading Steve McConnell's Code Complete I remember wishing Steve would write a book focusing on OOA/D. This is "almost" that book.

This book contains a very complicated writing style, it feels like the author used a thesaurus just to make the text harder. If english isn't your native language you should definetly not buy this book (as in my case). Add to the above that there is an obvious lack of flow in the book, and repetetive text making you think that you are reading the same pages over and over again.

For people like me, that its main knowledge's source are books, this one is the best I read about OO. There are many advices about how to make systems well, clears many obscure concepts (at least for me) and get us focused on a balance between the analysys and desing metodology and code construction.
Very well done!

I've been toying with the idea of a more agile programming environment coupled with good visual documentation for quite a while. I'm a project manager in a small software company and I've finally gotten the time to do what I'm meant to do - manage projects! We all know what it's like...

Although I've known of Agile programming methods (Extreme Programming for example) for a while and am well aware of the Waterfall Method's shortcomings - and I've known about and used quasi-UML now for about 3-4 years - it's never really synthesised sensibly for me.

I took a 10 minute, sit in the bookshop, read this book and the concepts started to come together for me; I learn by seeing how the concepts are applied to real things or projects and there's plenty of examples actually worked through rather than piecemeal.

This book has a tone such that the author is actually there with you. It's not at all boring, it invites you to think with the author and for yourself and it's great for people like me who hate being talked down to by an expert - even if we know that expert knows more than us - because it feels as though it's simply a more skilled person communicating his skills to you.

I heartily recommend this book.

DSL

There is a lot of textbooks on UML in the market, similarly on development processes like the Unified Process, design patterns and OOA/D. Many textbooks that I have seen provide a dry list of UML notations, or a dry list of process guidelines, or trivial examples on how a design pattern can be implemented. However, no other textbook in my opinion makes an excellent job in putting everything together in a case study (the 3rd edition provides two case studies) in order to illustrate (1) what is the significance of each one of the above, (2) how they fit together and (3) what are possible tradeoffs. The author very clearly explains what are the underlying principes behind object-oriented software development and (more importantly) how these principles can be put into practice.

Since the first edition I found Craig's writing style very easy to follow and as a graduate student taking software engineering and related classes I used this textbook as a self study to learn about OOA/D and UML. As an instructor I have been using this textbook for a number of software engineering and related classes (both senior level undergraduate and graduate), and the feedback I receive from students is very positive. I also recommend this book to students who are undertaking final-year undergraduate projects or graduate projects, and we have found this book to be very valuable for projects that involve several stages of analysis, design and implementation and who want to know how a process such as the Unified Process can be used in an agile manner. My experience tells me that this last point is very important for students who would work individually or in small groups over a (usually) short period of time to complete a development project.

Several of my previous students who are now employed in the IT industry as developers are telling me that they still use this book and find it a very valuable reference.

The book has also sparked interesting discussions among colleagues and researchers on various aspects on OOA/D and it is a valuable source. More particularly, the book successfully manages to integrate the principle of Design by Contract beyond implementation. Craig's approach to introduce operation contracts places emphasis on assertions from early stages of development and shows how this emphasis is propagated to detailed design (through UML communication diagrams) and through the use of responsibility patterns.

Regarding a comment on GRASP by a previous (and anonymous) reviewer, I would like to point out that a pattern is a set of principles (can be on any level of granularity) that solves a recurring problem at any stage during development. This (albeit informal) definition does not confine patterns to structural or behavioral design (along the lines of the GoF design patterns). Craig makes that very clear in the book particularly in the second and third edition) and I'm afraid to say that the reviewer who made the comment either skipped that part or misunderstood it.

I've come from a mainframe background. I took C++ and Java classes and still didn't know how to design OO. This book has helped me cross that bridge. Highly recommended!

GRASP is a series of patterns? That's a pile of crap. GRASP is a list of design techniques and principles. Calling the elements of GRASP "patterns" is a serious violation of semantic integrity and precision, and makes the book a lot less valuable than it should be.

Considering the semantic precision of the rest of the book (its intent is, ironically enough, to teach us semantic precision), this mis-labeling of one of its truly central elements creates a jarring cognitive dissonance.

I make a big deal of this because the GRASP principles are introduced at the pivotal moment in the process when analysis is being rendered into design. This is the moment where the rubber meets the road, and the moment that most of us buy such books for. To be led astray just exactly then by this whopper of a misclassification is a nearly fatal flaw.

The fact that the rest of the book is really terrific makes up for this, hence the restoration of 3 stars. The workaround is also fairly trivial: if the reader simply repeats (like Dorothy with "There's no place like home...") "GRASP is a collection of principles. There are no patterns in GRASP," then the problem completely corrects itself, and the book becomes useful again.

One of the more difficult concepts to bring to programming is the very basic concept of Object Orientation. Most programming efforts in the college/university level are really short and quick, while most software projects in the real world are much bigger. Combining all this together you have the potential for turning out graduates that have a hard time in the real world.

An interesting point of this book is its overall design, which is laid out like a software project. That way you are working within the broad concepts while you don't even know that you are being exposed to them.

This is not a book on programming. You should know at least one object oriented language before beginning it. Java is used for most examples, but one of the C's or Python could be used.

The title of the book is somewhat misleading to me. True it is about UML and Patterns, but it's really the sub-title that tells the story. This is a book on object oriented analysis and design (OOAD). UML and Patterns are simply two of the tools used to teach OOAD.

Coming from a VB6 (Book-Educated) background, OOA and OOD were very foreign to me. I had read some small explinations in a few books but it just wasnt enough to get me to start thinking in terms of OO.

This book finally did it for me. It leads you through the basic core concepts and patterns while showing you how to Diagram it in UML (This visual also helps in the learning process).

Overall a great find for me, after this I will be moving on to Object Oriented Construction.

If you want to introduce to the world of OOAD and Desing Patterns this is the best book for you ! Don't doubt to buy this book. It has been my inspiration to teach OOAD in my Technology Institute in Culiacán, Sinaloa México. Really UML and OOAD was another thing since i knew the Craig's Book !

This book nearly defies description in terms of the breath and depth of material it covers (and covers very well). In addition to OOA/D, you get essential and detailed information on Use Cases, Requirements gathering, UML, Design Patterns, and Iterative/Agile Development, as well as insights into Test Driven Development.

And the best part: all of this information is carefully integrated so you really get a deep feeling for the multitude of skills it takes to be a software developer/architect in the 21st century.

No book is a substitute for real world experience coupled with in depth instruction and mentoring, but this book comes as close as humanly possible to achieving those lofty goals without leaving your easy chair/workstation.

Most in-depth books leave me with a headache - you get the gist, and then the brick wall goes up when you get to the details. Mr. Larman slowly and steadily gets you into the details without ever over simplifying, yet without sacrificing the "meat"

Bravo!

I am in agreement with some of the observations made in the 1-out-of-5 review by wiredweird. However, I am inclined
to rate this book a 5 out of 5.

There are a lot of books out there that talk about O-O but stop at inane and condescending examples that limits
what knowledge, if any, you could get from the books. On the other side of the spectrum, you have outstanding
books like "Design Patterns" that might be a little hard to follow for people like, for instance, me. The uniqueness
of this book by Craig Larman is that it effectively bridges the yawning gap between the O-O for idiots approach and
the O-O for experts approach. Granted that Mr. Larman seems to be calling "Principles" as "Patterns" -- it is kind of a
stretch to call "Polymorphism" a pattern, but nomenclature aside, the emphasis is rightly on general principles that
prevade patterns of design. Larman might have stretched the limits of UML notation here and there -- but it is
almost always to emphasize an idea.

The main portion of the book deals with a case study involving a POS system -- good choice, a POS system is something
we are all familiar with and it offers a lot of possiblities to show the application of design principles and patterns.
Its possible that this is not the best book to teach (or to learn) O-O design -- but I havent come across one that is better.

An irritant i have with this book is the quality of the paper used -- it reflects light making it a strain to
read it under fluorescent light. Maybe they will fix it in the next edition so that the reader is the only one doing the
reflecting.

I can not recommend this book.

I find it confused and confusing, with no clear line between Larman's own diagrams and actual UML notation. Starting on page xvii (before the text even starts), this book mixes the UML comment notation with Larman's own boxes-and-arrows. Similar mixes appear on p.7 and many other places. By p.22 Larman has already confused comment and use-case notation. Diagrams like 17.4 use multiple different arrows to say apparently the same thing - or maybe not, it's not for the reader to know. A number of UML diagrams suffer similarly from creativity. It's never quite clear what marks are defined by the standard and which ones by Larman's over-active imagination.

It would have been so simple to fix that confusion, too. Even something like tinting the official UML and leaving his own markup in black and white would have shown which was which.

He uses common terms in baffling ways. I've been developing software for many years, and I thought I knew what development was. It's what a software developer does - it's all the work needed to start from nothing, then deploy and support the product. I was quite surprised to learn that planning and analysis are not part of the development cycle, but the start of Ch. 8 assures me that they are distinct. Larman asserts that development is architecture-centric, but makes this assertion when almost 90% of the how-to section has gone by. If archtiecture is so basic to all other design, then it really should have been there at the beginning. I've seen attempts to declare an architecture at the end of the project, and they are comical (as long as I'm nowhere near that project). I was also baffed to see "contracts" so deeply embedded in the UML methodology proposed. Contracts are good, I agree, but they don't become part of UML simply by wishing they were. This is the kind of presentation that will leave a UML novice (the book's intended reader) thoroughly misinformed.

Most other authors distinguish between design principles and design patterns, a line that Larman fails to draw. Principles give an idea of how to divide responsibilities, irrespective of what those responsibilities are. The Law of Demeter, cohesion, and the idea of polymorphism are design principles. Patterns state specific responsibilities and assign them to specific (if abstract) classes. Publish/subscribe (aka Observer) is a pattern. It states which object type originates data and which receives it. It states how the receiver makes itself known to the originator. Patterns apply to specific relationships or behaviors, principles apply to any relationship or pattern. Losing the distinction is a real loss of descriptive power, and a disservice to both principles and patterns.

The flaws go on, but this book has already taken up enough of my life. I strongly suggest that the reader look at any of the many other books on UML or on patterns. Even picking at random, you're likely to get a better reference.

This book uses a POS system example to give the idea of software development from the beginning to the end. It concentrates on software designs and artifacts on each phase with good detail description. However, since each software development phase is large topic, it can not give every aspect of design concept but it can give you an overview anyway. This book is great for anyone who interests to apply systematic process to software development but does not know where to start.

This book is a really well written, clear, comprehensive exposition of software delopment processes and best practices, uml and design patterns. An excellent read for someone who has just learned how to program in an object oriented language and wants to progress to the next level. The strong points of this book are: it is very clear, to the point and gives a broad coverage of all relevant problems and techiques in software development. Weak points: it is way too espensive, it could be more in depth in some areas, and it would benefit from the addition of a few chapters on how to use CASE tools. Also, it is nice to see the POS case study evolve throughout the book, but it would be even nicer if one could see a diagram or two from other areas and context once in a while.

Please see my expanded review at:
http://dotnetjunkies.com/weblog/fletcher.dunton/posts/5649.aspx

I picked this book up several years ago while writing curriculum for a training class on OOAD and UML. My reason for seeking it was that I needed an alternative to several of the books that Rational published, including UML Distilled and The Unified Modeling Language User Guide. The later two texts just did not tie UML, process and practical examples together and Larman's book did.

What appealed to me about "Applying UML and Patterns", is that it combined both theory and practice in manifold ways. I've critiqued each of the following areas:

Software Development Life Cycle
UML
Patterns
Practical Case Study and Examples

Overall, the book makes for good reading for developers and team leads alike. I recommend it as a baseline prior to choosing a UP based methodology and for those wanting to understand the big picture and how Use Case, UML, Patterns and UP can compliment on another.

Happy Reading : )

I read Larman's Applying UML And Patterns in my software engineering course at university. Some good points about the text: it was very readable, there were many helpful examples and diagrams, and it showed the UP for one example (the point-of-sale system) rather than several unrelated examples. I think many students are able to relate to the POS system example due to the large percentage of us working retail jobs.
Some negatives are that sometimes the prose rambles a bit or it seems like the author wrote it during a very late night. Also I would have liked more comparisons between the many (and sometimes confusing) diagrams in UML.
Overall, I thought this book did a great job teaching the reader about UML diagrams, software patterns, and the many iterations of the UP.

I felt that the this book descibed the individual patterns that could be implemented in the unified process well. The diagrams that were used in the book were extremely helpful in understanding the relationships between classes and enhanced the understanding of the patterns and the unified process.

This book was pretty informative concerning the application of UML, but only to an automated Point-of-Sale System. Lahrman included an excellent number of diagrams and examples of the different UML notations, however, they all focused on the POS system, and were thus sometimes hard to apply out of that context. The book did a good job presenting GRASP and GoF patterns, but the lack of variety in the examples made for confusion when discussing applying different patterns in the same type of system. One very nice feature of this book is the set of quick-reference diagrams inside the front and back covers of the book. These come in very handy.

This book helps introduce OOA/D, UML(very thoroughly), software patterns, use cases, iterative development, and other topics. It also gives insight on object oriented programming issues. One of the best features of the book is that you're able to read it and not have to illustrate by one programming language. I think the author using POS example was a good idea but could used couple more to add diversity. This book makes object oriented programming seems easy! Good start for students wanted to be software engineers.

While this book gives a good overview of the UP, I found it to be somewhat lacking in the "applying patterns" aspect. It did describe GRASP and GoF patterns consisely, but the examples, which all centered around a single system, were so simple and completely applicable, that it made applying the patterns to a totally different type of system, and seeing them from any but the very obvious angle in which they were introduced, difficult.

This book was used as are main text book for CprE 486 at Iowa State University. And proved to be highly useful for learning the concepts, but it stopped there. It seems like it introduces stuff and then almost immediately moves on. This makes it hard to try and use it as a reference when trying to accomplish assignments for it doesn't always provide clear and concise examples of how things are suppose to work. It introduces the notation, but leaves one kind of high and dry of how exactly to use. I would definitely recommend reading this book at least once, but whether or not it should be kept or traded in for Beer and Pizza is highly debatable.

JB

I enjoyed this book greatly. It provided me with a solid understanding of how to work with UML and OOA/D. It not only covers the basics of UML but brings the reader through the process of creating software, using a persistent example throughout the book. It helped improve my knowledge of object oriented design and overall software engineering skill.

I found the book clear and easy to understand. Additionally I found the examples very helpful in showing me exactly what needs to go into a certain UML artifact.

The discussions on the GRASP design patterns and GoF design patterns were both very thorough and helpful and opened my mind to new ways of handling various software problems.

The one problem I had with this book is the occasional instance in which the author contradicts himself.

Overall an excellent book and I would recommend it to any future software engineer.