Rating: 
Summary: Gets you from use cases to code quickly and efficiently.
Review: If you liked my book on Object-Oriented Software Engineering, you'll like this book.
Rating:
Summary: One of my current favourites
Review: Okay. I was sold on the Iconix process after a series of 5 articles in Software Development magazine. I went out and bought the book anyway. Fortunately, after reading the book, you won't need to buy the methodology. I design community based web portal applications. Our applications are medium-sized, but complex. So RUP is too big, and XP is too small. The Iconix process presented here is just right for most of our applications. UML is a large language. About 20% of it is very useful. The trick is knowing what 20%, and how the artifacts should follow each other. The book presents a lightweight process which is reasonably easy to use. If you work in web development, read Conallen's "Building web applications with UML" also. The two books complement each other well. (See my review)
Rating: 
Summary: If you're overwhelmed by UML, this book whittles it down.
Review: Other UML books tell you about the capabilities of UML. This book tells you how to use a subset of UML to complete a software project rapidly, and for that I give it a cautious recommendation.
The fundamental philosophy, placing Use Cases at the center of the development process, is sound.
The reader should excercise caution: Some aspects of this book (robustness analysis) are out of the mainstream and others are off the charts (the appendix on uses vs. extends is one volley in a larger 'religious war').
If you're overwhelmed by UML and all its minutia, this book whittles it down--class diagrams, use cases, robustness diagrams, sequence diagrams--and presents a step by step development process.
Rating: 
Summary: Will the real UML please stand up?
Review: Stick with the Martin Fowler or Craig Larman books folks, this one is more confusing than helpful. It's also poorly written, with little coherence as ideas are scattered all over. A veritable stream of conciousness. Maybe because Rosenberg himself hasn't figured it all out. In fact, at the beginning of the chapter on interaction modeling, he says don't be surprised if this chapter doesn't make sense, because he was supporting this in his CASE tool for a year before he even knew what it did. Wow. So he's selling the product, but he's not even sure what it's for? The second chapter starts talking about domain modeling. Where'd he get the "relevant" material to look through? Oh, I see, he's reviewing the user manuals, documentation, GUI and tables from the old system. That works for him, but probably he ends up building systems that look like the old ones. Build the domain model (from the old system), then prototype the system, then write use cases, then figure out your requirements (chapter 7)? Too bad for people new to UML who try to make sense of this book. Probably the idea is to steer people to the cd, which will undoubtably make everything clear. It takes a while to figure out what this book is really about - and it's not the UML! If you read the beginning chapter, he talks about the Unified approach he developed with his colleagues. What, you think, is he leading Booch, Rumbaugh, Jacobson at Rational? Nah. He means his own "Iconix" Unified Modeling Language approach, with what he liked of himself, and those lesser guys, B, R and J. I can really see why he gets into some heated conversations on the Rational mailing lists. The appendix, with a summary of one of these exchanges, and the top ten lists are the best part of this book.
Rating:
Summary: The best "high-level" presentation of OO development to date
Review: The author's advice matches closely what has worked for me on OO projects. I came to similar conclusions partly by trial and error: this book will save you a lot of trouble by identifying a core set of modeling tasks to take you from use cases to code (and beyond). Rosenberg's presentation is in many ways a distillation of Jacobson's OOSE book, but with some twists. His contributions include a persuasive argument to perform domain modeling of objects in advance of use case development, which turned out to be excellent advice. This book is an excellent guide for developers new to OO with enough solid insights to be useful to those with more experience as well. Let me put it this way: I've adopted it as the "unofficial" process guide for my team. Although I would highly recommend reading more detailed theoretical books for anyone who wants to get into OO in depth, this is by far the best high level book on OO development on the market. And if you're not using use cases, this book will show you why you should.
Rating:
Summary: Object modeling: There IS a right way, and it's in here
Review: This book is as pertinent for the Web developer as it is for straight-up software geeks. As a professional working in information architecture, I strongly recommend this book. Rosenberg/Scott provide an excellent "cookbook" for creating and refining use cases. Methodology and documentation such as this, when judiciously applied, can mean the difference between success and disaster -- a lesson the Web industry needs to learn. It *could* use a cover redesign. I volunteer ;) Simple, clear diagrams illustrate information relationships comprehensible even to the beginner. A within-arm's -reach resource.
Rating:
Summary: Good and pragmatic ideas, especially for small projects
Review: This book is short, which is a first reason to give it 4 stars, and the authors really gives us a good ration information / volume. I found the approach especially adapted to 6 month or less project with small team, because the author do not drown readers under a lot of activities and artifacts. We continuously have a "you are here" picture of the overall methodology, and we are continuously directed to code production. The best part of the book is probably the robustess analysis, which allow to go from Use Cases to an Object model, its something you can buy anyway if you practice Use Cases.
Rating:
Summary: This book presents a practical guide to implementing OOAD.
Review: This is a practical guide to implementing OOAD. The author effectively presents both the why and how of OOAD. This book will be valuable to "newbies" and organizations just starting to implement OOAD. The author is an expert on the subject and presents a balance of tutorial and example information. I would recommend that this book be purchased by any software development organization for the purpose of training new employees and initiating start-up projects.
Rating:
Summary: great for beginners and small projects
Review: This is an excellent beginners guide to OOAD for small to medium sized projects. I've recently delved into learning OOAD and getting my company out of the dark ages. This book has been a great, concise, interesting start. There are a couple of things I disagree with, but they are small. For instance, I disagree with making up "precedes" and "invokes" instead of using <<include>> and <<extend>>. The author's usage of "Robustness Diagrams" is excellent. They are difficult to find in other texts, but are very helpfull. Although, I do disagree with his suggestion to assign controller functionality to boundary objects in later models. The author's process may not have the detail that the Rational Unified Process has, but it is far better for small projects.
Rating: 
Summary: Heresy! This is ICONIX, a compact method borrowing UML
Review: This is the eighth software engineering title that uses the UML (Unified Modeling Language) that I have read in the last five months as I work to establish a software engineering guide and reference framework for a small team at my technology company. This book really sets forth the ICONIX methodology, the author's streamlined approach to modeling using mostly, but not only, UML. Because of the author's quarrelsome nature and unusual departures from common progressions in the model views, I found this book less useful than the others. The author repeatedly explains (with a careful record of the dates) how much of his integration of the competing OO modeling methods preceded the work of the UML founders (Booch, Jacobson, and Rumbaugh) and frequently raises the small quarrels in the UML world for no purpose except to give a quick and unsupported opinion. Not surprisingly, ten of the twenty-five citations in the bibliography are the author's prior papers. Although the title claims the method is "use case driven," techniques and guidelines for use cases are poorly done; and the author suggests that the requirements stage should begin with domain modeling and "robustness diagrams" before text for use cases is written. The author also places heavy emphasis on screen mockups during the requirements stage. The contents would make a good lecture or two; but it is an annoying departure from the efforts of many to extend and enrich UML. Since the book is only 165 pages, it won't hurt for long, and there are thoughts here and there worth reading. Perhaps it's tongue-in-cheek, a test to see if we can spot obvious logical problems with the method.
| 
