Customer Reviews

Advanced Use Case Modeling: Software Systems (v. 1)

5 star:		(5)
4 star:		(1)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

This book has some powerful advice for those projects that use Use Cases to drive their analysis and design efforts. It lays out a good process to follow for developing the Use Cases so you don't jump right into the details without a plan. Much of the advice is good Software Engineering practices, but a lot of people seem to forget that it still applies even when making use of newer techniques such as Use Cases.

The chapters pertaining to relating the Use Cases to other artifacts - such as test cases, the User Interface, and the Object Model - offer very practical and sound advice. You can tell that the authors have actually done it before and are speaking from experience and lessons learned.

The chapter explaining Extend Relationships offered the clearest and most complete description of the Extend Relationship that I have encountered.

All of the writing is very approachable and the examples sprinkled throughout the book and in the Appendixes are very helpful.

Granville Miller and Frank Armour have created an essential text for understanding Use Case Modeling theory. This book explains the basics of UML in the initial chapters, but quickly moves on to detail advanced Use Case theories and the best ways to apply those theories. I approached the book as a beginner, but had little difficulty understanding the presented ideas and theories. I would recommend this book for anyone involved with Use Case Modeling - from beginner to advanced. For beginners, this book offers a solid introduction and quickly prepares you for the advanced topics. For intermediate to advanced users, this book offers a compilation of theories and practices and is certain to give you insight to pieces of the UML puzzle.

Each step of the design process is explained thoroughly, and several alternative procedures are presented. Also, the appendices are valuable references of themselves. They contain a Use Case Development Review Checklist and a complete Development Case, which outlines each major step on the use case modeled development cycle.

The authors have also done an excellent job in bringing together information from outside sources to compile their work. Rather than preaching a specific format or model, the reader is presented with many different customizable options for applying the theories in the book. The carefully cited sources also give excellent direction for further reading.

I was disappointed to find a flaw with the printing of the book. In my copy the pages containing the table of contents were out of order. However, I found that I was more disappointed because a potential reader might skip this book on the shelf just because of a printing mishap. This information within is too valuable to miss.

A real danger with theory books is the potential to either underestimate the reader or talk over the reader's head. This book walks that fine line with ease. I felt that the ideas and terms were presented in a logical and clear manner. It is a valued reference for my work.

I have found this book of tremendous help in my work.

My first books on use cases focused more on UML rather than use cases. I did not give a hoot on use cases, because they look so simple on paper (and that's why I didn't buy a book specifically on use cases!) But as I grew as a developer, I began to believe that use case modelling if done well can significantly reduce development effort and bring about quality solutions. Use cases are the foundation to the understanding of the system that you are trying to develop. Use cases deserve serious attention.

The main problem with use cases is that you either don't know how to start or when to stop. This book tells you both. It tells you how to develop your use case model systematically from scratch and how to make provisions so that your use case model can grow. IMO, that's the main draw for this book.

The authors also give good insights on the possible approaches the reader can take to expand his/her use case model iteratively. It cautions the modeller to keep a balanced model so that stakeholders can understand, rather than one that specifies everything but gets bogged down by the details.

Semantics, you can get it elsewhere, but this book discusses it pretty well too. The examples are clear and relevant.

All in all, Frank and Granville did an excellent job covering the topic.

This is a very good book on use cases. Concepts are well-explained. Use cases are placed properly into the UML framework. Typical forms and diagrams are presented and discussed. The process of developing and refining use cases gets full and detailed attention, as does testing.

So - good instructional material, and the book is compact and well-organized enough to also serve as a reference. It is crystal clear and very readable.

What follows below is not more book review. If my experiences and commentary regarding use cases interests you, read on, but be aware that it doesn't bear directly on the book itself.

My background first: I started as a developer, moved into technical management, project management, business analysis management, IT senior management, and currently serve in an IT governance role in one of the largest companies in the US.

I'm not an enthusiastic use case advocate. Having managed or had oversight for more development activities than I care to recall over the last 30 years, I've only run into a handful of people who were competent enough to produce a set of use cases usable and complete enough to feed into the next design stage. (Understanding, of course, that this methodology was in its infancy during part of that period.) Many claim to know use cases and modeling. Then again, most developers involved in any kind of distributed systems, web, n-tier, PC-based development, etc. claim to be OO competent, too (Uh-huh ...). I've written use cases and developed apps from them and still only consider myself marginally competent. I used a consultant to help then, and would do so again. Use cases are exceedingly difficult to write well for non-trivial applications and, because of their text content, deceptively simple-looking. Don't be fooled.

The few I've encountered who could produce good use cases have invariably been knowledgeable technical leads who were competent across the entire span of activities from requirements through post-deployment support. They were also intimately familiar with the particular business space. This is not an easy combination to find.

That those who best understand use cases are typically highly technical is kind of perverse, as the intent of use cases is to keep them firmly in the end-user's conceptual space. In trying - and failing repeatedly - to get end users and business analysts trained in use cases - and, for that matter, trying to get the business to understand and accept them, I finally came up with something that worked. That is, develop conventional, text-based project charters and requirements documents, then have the dev teams and leads develop the use cases from the business docs.

This results in an interative process between use case development and the requirements - adding work - but it also cuts the inexpert out of the parts of the process that they never quite fathom anyway, such as alternative flows, extensions and generalization, includes relationships, etc. Even pre and post-conditions, which business people intuitively understand, are problematic because they typically can't get enough rigor into a use case without assistance, so the iteration helps with that also. What you wind up with is use case documention in the technical space, not the users'. That turns the process on its head but results in usable use cases. You also have to adjust how you handle non-interface content such as verification when end users aren't directly participating in use case creation. Such workflow and documentation issues lead to the next point:

Further complicating the adoption of use case modeling is the fact that use cases (and the UML) are easiest to adopt when supported by an end-to-end software suite, like Rational's. Anyone who has tried to implement such a suite knows that it is excruciating. Rational themselves will tell you that the setup of the software and underlying database is critically dependent on the specific forms approach you use, your methodology variation and workflow, even your org structure. The message is that you have to have a very full understanding of what you're doing in order to implement. Most bring Rational in on a consulting basis as a result.

Adoption is also complicated in large firms by the simple fact that most activity is on legacy systems, and that modern modeling and design methodologies aren't well-suited to those systems.

The final comment I'd make is on value. I haven't found that the adoption of use cases - even good ones - yields better systems or even better documentation than other means of systems design and interface functional specification.

Returning again to the book itself - by all means buy it if you are looking for a single volume focused on use case development. It really is a good use case text. Beware the pitfalls going down the use case adoption route, however. If ever there was something that deserved a pilot, this would be it.

It is refreshing to a read a text that caters for those of use who already have experience in this domain and are seeking to develop their skills - without reverting to acadamia style writing. Useful examples, balanced descriptions, and an excellent coverage are all attributes of this text.

I strongly recommend this book!