Mining High-Level Use Cases Descriptions for Objects

I l @ ve RuBoard

The traditional wisdom is that you develop your list of objects by detailing all the use cases and then extracting all the nouns. I find that you can get to the same place much faster by describing the application at a high level (as kind of a mission statement for an application) and isolating the nouns from that description.

Here is the mission statement for the BFG Web site:

A user enters the site. There the user is presented with a list of products organized into categories. He can place products into his shopping cart, select a shipping address from his address book or enter it manually, specify an existing credit card from his wallet or enter the card number manually, and approve the order. The credit card is then validated and an order is generated. The price of products could be affected by promotions that are currently running on the site. The user can also add, edit, and delete entries from his address book and wallet.

Now let's take another look at it, with the potential objects in italics:

A user enters the site. There the user is presented with a list of products organized into categories. He can place products into his shopping cart, select a shipping address from his address book or enter it manually, specify an existing credit card from his wallet or enter the card number manually, and approve the order. The credit card is then validated and an order is generated. The price of products might be affected by promotions that are currently running on the site. The user can also add, edit, and delete entries from his address book and wallet.

Note that it is a good idea to be judicious in your selection of nouns. Some books advocate literally grabbing every noun (which would have included words such as site, entries, and list ), but it is preferable to filter out the nouns that don't really translate into real objects as you look over the description.

At this point, it becomes a matter of personal style regarding how you proceed. I usually like to sketch out the class diagram before proceeding to use cases. Some might argue that this is backward, that you need to have your use cases fully realized before you design your objects. I disagree , for two reasons:

• Even before you dive into use cases, you normally have a pretty good idea what the application needs to do. Thus, you can take a first cut at the attributes that each class will make use of before you dive into details.

• For me, at least, doing use cases isn't an exercise in isolation. I'm also starting to think about implementation as I detail the cases. Knowing what my palette of objects is before I start helps that process.

The case against this approach is that you can end up refactoring your objects a lot as you gain more detailed knowledge of the application. While this might be an issue once you begin coding, it isn't often a real problem when refactoring is still in the paper-and-pencil stage. Clearly, you want to understand the entire application through a detailed set of use cases before you begin to create a database schema, but this shouldn't prevent you from drawing out a few rough ideas of table layouts before you start.

I l @ ve RuBoard