Use Case Driven Object Modeling With Uml: Theory And Practice

by Doug Rosenberg

Use Case Driven Object Modeling with UML--Theory and Practice shows how to drive an object-oriented software design from use case all the way through coding and testing, based on the minimalist, UML-based ICONIX process. In addition to a comprehensive explanation of the foundations of the approach, the book makes extensive use of examples and provides exercises at the back of each chapter. This book leads by example. It demonstrates common analysis and design errors, shows how to detect and fix them, and suggests how to avoid making the same errors in the future. The book also encourages you to examine its UML examples and to search for specific errors. You'll get clues, then later receive the answers during "review sessions" toward the end of the book.

Genres: Coding

Paperback

First published June 23, 2006

Reviews

[Steve Whiting · Rating 4 out of 5]

This is another book with a hint of the curate's egg about it. On the one hand, I like the premise of their development method - simple, linked static & dynamic models, and getting the requirements gathering going by (quickly) building a basic domain model, which is then used to set the vocabulary for the rest of the project.

However, I think they go off the rails by getting involved with GUI issues far too early. In "Writing Effective Use Cases" (which I think is pretty much the bible on the subject), Cockburn insists that UI features have no place in use cases that are being used to elicit requirements. I think this is important to avoid having the customer thinking in terms of solutions rather than requirements: to have the requirements driven by a GUI storyboard, and leading to UCs with GUI actions identified, is going in totally the wrong direction - they're creating requirements from a programmer-centric point of view, rather than an analysis/design-centric point of view.

This is a significant flaw in their methodology, I feel, and the effect of this runs through the rest of the process, which is a shame, because if that could be stripped out and replaced by a separate UI specification step, the rest of the process is actually pretty good.

For example, the next stage after UC requirement capture is their 'robustness diagram', which is an excellent concept. This should be the first element of design - mapping the use case to the domain model, and starting to elicit system objects, but because of the 'pollution' from the GUI elements it's already including details written at far too low a level (eg, clicking buttons) when it should be concerned with activities.

All of this is a shame, because in most other respects, it's actually a very good book, with lots of good advice & practise, clearly explained - for example, most of section 3 (Design & Coding), is excellent, particularly the chapter on creating sequence diagrams and assigning methods to classes, and their illustrations of design & review processes which keep all the models and code in alignment.

[Danien · Rating 2 out of 5]

Theoretically, the checklists make sense but it feels a little disconcerting because of the heavy upfront design and model process, even though the text claims that it is agile and iterative.

After creating lots and lots of analysis, design, review, and implementation model diagrams based on presumably well-defined but not necessarily complete requirements, there are a couple of comprehensive review stages. Then coding and going through your diagrams and syncing them with the actual implementation. In theory, it sounds logical, but is this really practical? Maybe for projects that are already well-defined, like the web bookstore example in the book.

Using a progressively detailed iterative test-driven design seems to make more sense to help discover the requirements for less well-defined projects like games.

[Nita · Rating 3 out of 5]

Ketemu juga buku yang bisa bikin si sistem analis bisa nyambung sama si programmer :-)