Use Case Driven Object Modeling with UMLTheory and Practice: Theory and Practice

by Doug Rosenberg, Matt Stephens

Diagramming and process are important topics in today’s software development world, as the UML diagramming language has come to be almost universally accepted. Yet process is necessary; by themselves, diagrams are of little use. Use Case Driven Object Modeling with UML - Theory and Practice combines the notation of UML with a lightweight but effective process - the ICONIX process - for designing and developing software systems. ICONIX has developed a growing following over the years. Sitting between the free-for-all of Extreme Programming and overly rigid processes such as RUP, ICONIX offers just enough structure to be successful.

Genres: Coding

471 pages, Hardcover

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 :-)