Hotspots: Admin Pages | Turn-in Site |
Current Links: Case 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:
- Do your scenarios first. It's easy, and it is a huge help when you are doing your CRC cards and your class diagram. All you have to do is make up enough stories to cover the requirements.
- Write short text descriptions of what happens from the user's point of view for every important task / requirement of the program
- Try to use specific examples instead of generic descriptions. For example, say "Richard buys 13 grams of COKE" instead of "a user buys a number of grams of some rock".
What to avoid:
- namely, scenarios for stuff a customer does not care about. For example:
- Automatic credit of interest (this is a system feature rather than a user task). Note that explicit credit of interest may be included if determined to be a priority task of sufficient complexity.
- Accessors/Modifiers like setting the balance (this may be too trivial to be of use modelling)
- Most of the behavior built for M1 (again, even things like making deposits may be too fine of granularity). Whenever possible, look to factor behavior into an encompassing scenario: rather than depost/withdrawal, you could model the larger task of a "balance increasing transaction" or a "balance decreasing transaction" or a "balance transfer transaction" that encompasses all three account types with a common interface for all three (note that having this common interface is good design anyway, so developing these scenarios helps yet again to improve your product).
- Don't overdo your scenarios. Just tell the story and be done with it. A few sentences is fine.
- Don't have options. A scenario is one usage story. Save all the options for the detailed requirements (assuming you do them at all – in this class you do not.)
- Don't cover every possibility. Just make a point to cover "the most important behavior."
- Don't confuse a trace of method calls, for the scenario itself. If you do a message trace, put it beside the scenario, not inlined with it. The methods shouldn't even exist at the time you do a scenario.
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:
- open the FinancialManager with saved data: is there a class on your UML diagram that contains a method to start the FinancialManager with the name of a file where data is stored?
- view an account: maybe there is a list of all accounts, when the user clicks on one, he/she can see transactions for that account - is there a variable somewhere that contains this list? how is it being stored? is there a method to change the display from the first account to the second account?
- enter a transaction: maybe there is a button "Withdrawal" that pops up a dialog box with fields that take in a description, type of transaction, date, ammount & category - what class is responsible for instantiating this button? is there a method to pop up the dialog box & add the a new Transaction to the account?
- save data: maybe there is a button that says "Save To XML" that pops up a dialog box asking for the file name - where are the methods for writing data out to a file?
- ...etc.
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