I liked a lot of the book but still felt much of it was too much BUFD, at least for what I do. As with any UML book or article I find myself lost between the similarities and subtle differences between many of the diagrams. I figure that if I am lost then surely the business experts and stakeholders I am working with will be too. The best thing I take away from this book is the real need to develop a high-level model, develop solid use cases or user stories, and then flesh out the model to handle these user stories.

I give it 4 stars because what is too much or too little in regards to UML and modeling in general is highly subjective and should not detract from the quality of the book.

I had to read this book for a class I took. Here is my interpretation of the purpose of this book:

"I think the world should have used my ICONIX process! This UML stuff is inferior. I hate UML, but I will use it to sell my book."

Fortunately, the class also used Martin Fowler's great UML Distilled book. If you want to know about UML, get that one instead!

If you are looking for a book on the Unified Process (as I was), then this book is not for you. This book covers the author's Iconix process. Considering the book's title I would have expected it to examine use cases and UML more than it does.

I was really intereted in the Unified Process. But, the Iconix methodology is a good one, and were it to be more prevalent in the industry I would take a harder look at it.

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.

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.

I expected this book to delve more into UML and use cases than it does. It really is a book about the ICONIX methodology. It only deals with UML and use cases at a high level.

The robustness analysis is interesting and may help people who have trouble linking the user interface to the model.

If you are looking for a book on the ICONIX methodology then this book is for you. If you are looking for a book on UML or use cases then this is not the right book.

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.

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.

Great book! A case-oriented followup to the original book (buy it first if you haven't already). This and the original are the best, no-nonsense, down-to-earth simplification of OOAD and UML that I've seen! Mandatory issue for all new developers where I work now. If only I had this book (and the original) several years ago when I started off with UML!

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)

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.

As a management consultant responsible for providing project management expertise during the custom application development lifecycle, I felt this book was light on content. Granted, it is a nice primer for someone who is new to the object oriented world; however, most managers will find it too elementary. Further, I find the Rational series to be too theoretical and not practical for organizations that have resource constraints.

In short, "too simple" and "nice in theory" characterize this whole series.

As I was learning OOAD concept and techniques, and the UML, the one thing I found lacking in most materials was application. There are a lot of great books on what OO is, with guidelines on good design, and great examples of diagrams you can create. None of them that I've read, with the exception of this work, has provided any look at how to put the pieces together in a sane fashion. Rosenberg succeeds admirably at this goal.

Contrary to what some reviewers seem to think, this isn't a book about the UML, and I don't believe it tries to be a definitive reference on methodology, either. Rather, Rosenberg presents (with a clear disclaimer) his perspective and method for performing OOAD; I find it a valuable one, at that.

If you're just getting started with OO and/or the UML, and want a good overview of how the pieces fit together, read this. I'd recommend it to all other comers, as well, unless you think reviewing an additional perspective (from a successful, well-regarded individual) isn't valuable.

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 <> and <>. 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.

I found this book very good. This book will help you write your "use cases" and make sure you don't forget important details in your design. My review for this book is simple: If you are stuck trying to start your design. If you have problems figuring out the how and what in terms of designing your systems. You must read this book. I'm sure the writing of use cases for my next project will be much easier.

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.

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.

"Use Case Driven Object Modeling with UML, A Practical Approach" is perhaps the best book on the market for a down-to-earth, hands-on introduction to the Unified Process. As the title suggests, it leans heavily on the methodology of Ivar Jacobson, one of the three amigos. If you are trying to figure out what to do or where to start, this will point you in the right direction.

Three things in particular I liked about the book:

1. "The Approach in a Nutshell" as well as constant reference back to it.

2. The lists of ten.

3. The chapter on "robustness analysis" showing the transition from analysis to design (always a difficult transition in any methodology). This is the best part of the book in my opinion. It was real "hands-on".

"The Approach in a Nutshell" gives a great overview of the process including milestones, and provides a framework for everything to fit into. As the reader progresses through the book, each chapter summarizes that part of "the approach in a nutshell" that the chapter fits into. If this was the only feature in the book, it would be worth the price.

If you have ever read another series with "lists of ten", these are better. The lists of ten (there are over half-a-dozen) are worth taping up on the walls. They reflect the experience of someone who has been there and done that. The lists of ten alone are worth the price of the book.

The transition from analysis to design has rather heavy focus in this book, and deservedly so. Going from analysis to design is tricky in any methodology, and "Use Case Driven Object Modeling with UML, A Practical Approach" shines in this area. The authors refer to this as "robustness analysis," and this section alone is worth the price of the book.

This won't be the only book concerning the Unified Process that you will ever buy. But it is more than likely going to be one of the most useful to you.

This is not a tutorial on the UML; purchase "UML Distilled, Second Edition" by Martin Fowler and Kendall Scott if that is what you are looking for. The title may be slightly misleading in this respect. The real focus is on the "Practical Approach" part. If you are trying to sort out HOW TO DO IT, then this is a necessary addition to your library. It won't replace your books on the UML or the Unified Process, but it will help you pull it all together into a cohesive whole so you can get a grasp on how to start and how to proceed.

In addition to being very informative and clear in direction, the book is also surprisingly interesting to read. Its clarity and brevity keep it simple. You won't get bogged down reading this one. It is very well written.

I am sturdying UML. This book is very good

...The author delivers a concise description of each technique in the process without going into so much detail that the reader gets bored or runs out of time to finish reading. This is the point of the process as well... do only what is necessary and do it well enough to meet the end goal which is delivering a system that meets the requirements of your customer.

The author is purposely brief in things such as grammatical analysis and refers the reader to more in-depth works for further reading. He specifically avoids wasting the readers' time with material already covered in great detail by other works. I found the material presented to be complete enough to get me going in the right direction. Further, I found the guidance (both in the text and the Top 10 lists) to be extremely valuable in helping me stay focused on the important issues. The author does explain the purpose of every technique in the process. Specifically, he states the impact each step has on the project outcome. I accept the author's occasional citation of "experience" as the reason for doing something as an honest attempt to pass along to the reader "what works in the real world" rather than an attempt to be arrogant...

This book is for OO practitioners who understand the basics: inheritance, aggregation, and terminology like methods, attributes, etc. If you are such a person and have seen projects fail either due to the complete lack of modeling or due to the application of modeling to the point of "analysis paralysis", then you will resonate with this book! I strongly believe that applying this process to your next project will lead to career advancement. Why? It will be the first project your manager has seen come in on time and perform as the customer wanted... that is, without a series of costly and unmaintainable hacks to "make it right" at the end.

I could not fine one piece of information in this book that was new or insightful. The author often uses a rational like "My experience has taught me this." This would mean so much more if he provided the logic behind his implied wizardry. It is also quite often the case that the book jumps around the UML and the author presents his (or is his company's) own special way of doing things. His section on grammatical analysis looks like a botched attempt to succinctly capture what Wirfs-Brock did so well in her "Designing Object-Oriented Software" (published in 1990 and still a "five star" excellent read). The "case study" used for the book is vague and will likely have the reader spending more time trying to decipher the case concept before understanding the notational concepts. The one good part of the book, which is not a new idea either but was worth brushing up on, was idea of traceability within a project lifecycle. Overall, "Applying Use Cases: a Practical Guide," by Schneider and Winters is a much better read and will get you further along in your Use Case endeavors.

If you are interested in the approach see the web-site instead. Why buy this guys company advertisement?

This short, well-written, well thought out book presents a roadmap complete with checklists to enable you to implement what you've read about from the three amigos. Very exciting--I read it cover-to-cover in one sitting, and will keep it at my side for ready reference throughout my projects.

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.

Easlily one of the more practical books on object-oriented design and modeling available today. The author uses good examples and plain English to convey his approach to designing and creating object oriented software. He lists a lot of "common" mistakes made during the design phase, and gives some practical ways to overcome 'analysis paralysis'. This book should be required reading for anyone ready to design a new system from the ground up.

Finalmente encontrei um livro sobre OO que vale a pena ser lido do in�cio ao fim. O autor sabe o que est� falando e tem consci�ncia sobre o tempo limitado que temos para fazer an�lise e desenho de sistemas. Ele nos orienta a dar �nfase nos elementos essencias da UML de forma direta e objetiva. O autor tem personalidade o suficiente para dizer o que � bom na UML e o que poderia ser melhor. Uma dessas contribui��es � o diagrama de robustez que suaviza o gap existente entre um caso de uso e o diagrama de sequ�ncia correspondente. Outra: a n�o recomenda��o em se utilizar os estere�tipos "uses" e "extends" para relacionar casos de uso e por a� vai... Em momentos oportunos ele faz refer�ncia � ferramenta CASE Rational Rose ressaltando caracter�sticas da ferramenta que normalmente n�o s�o abordados em outros livros, tais como a gera��o de scripts para automa��o e padroniza��o na gera��o dos modelos. O livro n�o se restringe apenas � UML (que � apenas uma nota��o) mas prop�em um processo definido para a aplica��o da mesma. Se voc� j� tem um conhecimento m�nimo de UML e gostaria de desenvolver um modelo OO do sistema antes de escrever o c�digo esse livro � para voc�

Finalmente encontrei um livro sobre OO que vale a pena ser lido do início ao fim. O autor sabe o que está falando e tem consciência sobre o tempo limitado que temos para fazer análise e desenho de sistemas. Ele nos orienta a dar ênfase nos elementos essencias da UML de forma direta e objetiva. O autor tem personalidade o suficiente para dizer o que é bom na UML e o que poderia ser melhor. Uma dessas contribuições é o diagrama de robustez que suaviza o gap existente entre um caso de uso e o diagrama de sequência correspondente. Outra: a não recomendação em se utilizar os estereótipos "uses" e "extends" para relacionar casos de uso e por aí vai... Em momentos oportunos ele faz referência à ferramenta CASE Rational Rose ressaltando características da ferramenta que normalmente não são abordados em outros livros, tais como a geração de scripts para automação e padronização na geração dos modelos. O livro não se restringe apenas à UML (que é apenas uma notação) mas propõem um processo definido para a aplicação da mesma. Se você já tem um conhecimento mínimo de UML e gostaria de desenvolver um modelo OO do sistema antes de escrever o código esse livro é para você.

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.

If you liked my book on Object-Oriented Software Engineering, you'll like this book.