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

About Scenarios

Scenarios should be one of the first things you do when you sit down to design your program. They are part of the object oriented analysis phase of the design process, and should not be implementation specific. there should be no method names, or classes designed at this point. Similarly, you don't want to use things like "click cancel," "click delete," etc. think of scenarios as stories told from the user's point of view of what they would like to happen in the program - not specifically what does happen from the programmer's point of view.


A previous professor explains:

Scenarios map to a portion of a use case description. Specifically that portion that deals usually with the "Happy Path" or the main success scenario portion of a use case (although failure paths can also be valuable). Use case scenarios are written in the language of the USER not the developer. Thus a scenario might say a user provides their user name and password – NOT user types information into a password dialog box and presses the OK button.

These scenarios then become valuable to reason about design options. If we put design in the scenario, we "overly-constrain" the design, a big no-no to us software engineering geeks! So if we just say the user provides their password we are then free to play around with a bunch of design alternatives–like use a dialog box, use a card scanner, use a vulcan mind meld whatever.


What to do:


What to avoid:


Letting scenarios help you in the future:


Scenarios are meant to help you model the most important behavior in a system. So, once you're done creating scenarios, they can be especially helpful in the later phases of the design process.

CRC Cards:
One thing that can be especially helpful is using them to create & verify your CRC cards. CRC cards can help you to make the transition from analysis (in the user's point of view) to implementation (in the developer's point of view). You probably want to start by making a few candidate classes & writing their names down on index cards. Now, go to your first scenario & decide what class/es will be responsible for getting everything done for each step.


UML Diagram:
Think about how you decide if a UML class diagram is complete or not. What I do is review all the requirements and walk through the scenarios that satisfy each requirement and check them off as they are accounted for.

For example, milestone 5 talks about saving the user's information to an XML file. This is something you should make sure is explicitly handled in your program. Walk through your scenario, and check off each step when you can see that it is implemented in your program. Maybe your scenario says something like:

1. Sally opens the financial manager to view her checking account.
2. Since she just took money out of the ATM, she enters a $50.00 withdrawal.
2. Sally now wants to save her changes to a file moneyToSpendOnDVDPlayer.xml so that she can transfer the data to her Palm Pilot & know exactly how much money she has when she goes shopping for a new DVD player this afternoon.
3. She's done now, so she exits the program & heads to Best Buy.

Now, you need to make sure each of these steps is handled in your program. Here's where you take a close look at the implemented structure of your program. You need to make sure there's a way to:



Think of scenarios as a contract between the developers and the customers as to what major features that are being implemented and an aggrement between the developers as to how it is accomplished.

If you create scenarios for higher level behavior (i.e. balance increasing transaction rather than depost/interest/etc..), you should list for each scenario where it is realized. Hence, you should have an exhaustive list of the places where "balance increasing transaction" can occur: savings deposit, interest, purchase stock, etc. A student pointed out a nice feature of this style. If you create the scenarios for "balance increasing transaction" and "balance decreasing transaction", it may be that "balance transfer transaction" simply refers to the other two. Again, you should list everywhere that a "balance transfer transaction" can occur, but this abstraction may help you think of things on high enough level and still be able to use it to verify the completeness of your UML class diagram structure.




Links to this Page