Model use cases that work

Think succinct

Use case modeling in practice

Here's an exercise from the book, on opening an account. See how many errors you can spot in the following use case, and try to rewrite the use case text - hint: this relates back to the items numbered 10 and three in our list. Once you're done, compare your rewritten version with our "fixed" version. Good luck!

BASIC COURSE: The system displays the Create New Account page and enters the following fields: Username (must be unique), password, confirm password, first name, last name, address (first line), address (second line), city, state, country, zip/postal code, telephone number, and e-mail address. Then the user clicks the Submit button; the system checks that the Username is unique, creates the new user account, and displays the main Hub Page, along with a message indicating that the user account is now created and logged in.

ALTERNATE COURSES: Password and Confirm Password don't match: The page is redisplayed with a validation message.
Username not unique: The page is redisplayed and the user is asked to choose a different username.

What's wrong? Answer: This use case gets bogged down in presentation details. It spends too long listing the fields to be found on the Create New Account page, with the result that the text doesn't follow a noun-verb-noun sentence structure.

Padded-out use cases of this sort often take up much more than two paragraphs. This doesn't help, as you want your use case to be succinct enough to translate to a single sequence diagram. We'll come back to this point in the fourth and final part of this series.

Instead, the fields should be added as attributes to the appropriate class in your domain model - most likely the Customer class. Then, when you need them later, they'll be right there. The fixed version follows.

BASIC COURSE: The system displays the Create New Account page and enters the fields to define a new Customer account. Then the user clicks the Submit button; the system checks that the Username is unique, creates the new user account, and displays the main Hub Page, along with a message indicating that the user account is now created and logged in.

ALTERNATE COURSES: Password and Confirm Password don't match: The page is redisplayed with a validation message.
Username not unique: The page is redisplayed and the user is asked to choose a different username.

In this excerpt we covered how to write the kinds of use cases that can be used to drive a software design. In the next installment we tackle robustness analysis, a form of preliminary design that helps to prepare your use cases for detailed design, testing and coding.

Use Case Driven Object Modeling with UML: Theory and Practice is available for purchase through Register Books, at the special price of £34.99. ®

Sponsored: Network DDoS protection