View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

How to Make Good Scenarios

by Kyle Spafford

This assumes you have already made your CRC cards.

Step One: Think About Use Cases

First and foremost, a scenario is a sequence of reponsibility driven events that bring about some change in your system. In order to pick out a good scenario, it helps to think about what a user might want to do with your system. At first, don't dismiss any potential scenarios as too trivial or too complicated. Try to sort your brainstorming by complexity. Try to have some basic cases, a lot of average cases, and a few "corner" or special cases.

Step Two: Roleplay Round 1

Take your CRC cards and try to roleplay through some of your most basic use cases. This can be done very quickly, and is almost always worth the time. This ensures you didn't miss anything crucial on your initial CRC brainstorming. As you roleplay different scenarios, gradually increase the complexity of what the scenario tries to accomplish. As you do this, you'll realize more and more responsibilities and collaborators to add to your CRC cards.

Nota Bene: While refactoring your CRC cards, do not worry about implementation details.

Use this incremental process to flush out your design and give you an expert understanding of the sequence of events that define one of your system's operations.

Step Three: Adding Some Detail

Now that you have your CRC cards full of responsibilities and collaborators, you need to outline how the user will interact in your system with a higher degree of specificity. This includes determining when you'll need a button, checkbox, or pull-down menu. However, you still want a high degree of abstraction in this process. You don't need to worry about the code behind a button, just that the button exists and will perform what you expect it to do. Keep a list of all of the GUI components that the user will use to interact with your system. This becomes the initial candidate class list for your lower-level, implementation specific design. Again, proceed incrementally, add a few CRC cards and roleplay with increasingly complicated scenarios.

Step Four: Choosing the Most Effective Scenario for the Turn-In

Now that you have developed several scenarios, it's time to pick one to write up and polish. The common pitfall is to pick a scenario that is too easy. A scenario shouldn't be something that is trivial. You want your scenario to be on something that is complex enough that it conveys information about your design. However, you also don't want a corner case that is unnecessarily complicated and rarely occurs. Once you've picked a scenario, be sure to give it "color" with examples. Instead of "the user makes a crc card with a responsibility" have something like "John makes a new CRC card for the Clock device with the responsibility 'keeps track of time'." This makes the scenario easier to conceptualize and understand.

Real Examples

As an exercise, think about what is wrong with the following scenarios:

1. User starts Ecode, opens a created CRC card, andds a responsibility, and saves it.

2. Annabelle wants to create a UML diagram for ther Living Ocean program. She makes sure all of her CRC cards are complete with relationships, and clicks on the design tab. She chooses the create UML class diagram button, and the program automatically creates a diagram with all of the classes Annabell has created, and the relationships she specified.

3. Jim wants to create a new CRC Card from the list of brainstormed classes
-Jim chooses a class from the list of brainstormed classes
-He selects Create Card
-He is prompted to enter the superclass, purpose, pattern, stereotype
-Subclass information for each card is updated

Answers to the Examples

While there can be more than one right answer, here are some thoughts about the examples.

1. First off, this scenario is too simple. Even if things were fleshed out a bit better, we still wouldn't not be able to learn much about the system from it. It is also too generic, and would benefit from specific examples of a CRC card, responsibility, etc. This scenario also neglects to state what the user will perform to accomplish his or her goals. How will the user save the CRC card? Will he use a button or pull-down menu?

2. This scenario is a drastic improvement over the first, but still lacks real content. The problems with it stem from "the program automatically creates a diagram." Speaking about the system in such high level terms is no better than saying "the program performs the scenario." It does not convey any information. For this scenario to improve, it should reference (even if at a high-level) the interaction between the various domain objects that are involved.

3. The problem with this scenario is that is is too simple. It does, however, give a short and sweet description of what happens in the system for this event. It includes information about what the user has to do, and what happens to the object model.

Links to this Page