[.ca] Applying UML and Patterns: An Introduction to ... (ISBN 0131489062)

From Amazon.co.uk:
Good software starts with a good design, and Applying UML and Patterns' subtitle, "An Introduction to Object-oriented Analysis and Design (OOA/D) and the Unified Process" reflects this. The first edition of Applying UML and Patterns became a standard. The second edition uses the unified process (UP) as the interactive process within which OOA/D is introduced and extends the case study used in the first edition. Other changes have been made to reflect the growing consensus on the most effective ways to work with OOA/D and patterns. Although you will learn UML this isn't what Applying UML and Patterns is all about. It's designed to teach you to think of software as a collection of objects with properties and to manipulate the relationships between them. This is far more profound. The case study enables Craig Larman to carry the design through to Java code. In practice you will need a basic understanding of OO programming to benefit from Applying UML and Patterns though you needn't know Java--you could implement the designs in the OO language of your choice with equal facility. When it comes right down to it, Applying UML and Patterns is all about providing you with a language in which to think about software design. This is quite a different from learning a language in which to code a design. A facility with OOA/D will enable you to design and discuss programs independent of code, to produce more elegant and maintainable software and to take a 30,000-foot view of the way your software interacts with the world. In effect, it can shift your viewpoint from that of a mechanic to the more sophisticated viewpoint of an engineer. --Steve Patient

The best tutorial on OOA/D:
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!

The best book for introducing in OOAD and Design Patterns:
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 !

Keep looking.:
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.

A good introduction, and more, to OO Analysis and Design:
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.

A great learning book for overview of software engineering:
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.