This week, at Amir’s request, Angela talks about what-ifs, scenarios and how a Use Case Diagram can show these.

What’s a Use Case Diagram and why do you need one?

You don’t. Says Martin Fowler.

As important as it is to focus on the content of a Use Case, his encouragement is that you stick to its textual description, rather than try and represent it as diagram. As with many things, he’s right: the content, rather than the form, is crucial in this case. Being visual people, though, we like our stuff in pictures here and diagrams are close to our hearts.

So what’s a Use Case, then?

You have a Use Case, when you want to achieve a goal and put together the possible scenarios and what-ifs that you might expect on your way.

Imagine you want to ask for a pay rise. How might things go?

Best case scenario

 

You walk into your boss’s office, state your number, he throws his arms up in delight and tells you he thought you’d never ask. You go back to your office in disbelief, gather your buddies, head for the local pub… But I digress.

Worst case scenario

After you state your number, your boss pulls out Benjamin, your pet bunny, out of a drawer and points a gun to his head. He then calmly reminds you about the latest e-mail campaign cock-up and suggests a pay cut.

Realistic scenario

You walk into your boss’s office, state your number, your boss listens, rubbing his chin. Before you get on with the arguments you’ve prepared as bullet points on the inside of your left palm, he lets out a deep sigh and mutters about recession, bad revenue and pay freezes. You pull out Berta, his pet hen, out of a bag and put a kitchen knife to her throat…

 

Now, Martin Fowler suggests that this is actually put in the following way:

Ask for pay rise

Main Success Scenario:
1. You walk into your boss’s office and ask for a pay rise, stating a number.
2. Your boss grants you the pay rise.
3. You walk out happy.

Extensions:
2a: You’ve made a recent cock-up:
…...1: Your boss reminds you about it and suggests a pay cut.
2b: Times are tough:
…...1: Your boss tells you so and refuses to raise your pay.

Put it on a diagram

Time to ‘shut up and draw’, which seems to have become our motto here:


Definitions

To see an explanation of the diagram’s label <uc Pay rise use case> have a look at our introduction to UML 2.0 Sequence Diagrams.

    • System boundary – that’s a box that’s drawn around the scenarios, which play in the system and that separates them from the actors.

 

    • Actor – anything or anyone who plays a role in interacting with the system. Represented by a stick figure. Possibly to save artwork time.

 

    • Main success scenario – that’s the scenario that would represent the normal sequence of events you’d expect. So, if you were designing a vending machine, a normal sequence of events would be: Customer inserts coins, pushes button, machine spits out a bag of sweets.

 

  • Extension – now we’re getting into the what-ifs: any scenario that represents an alternative to the main success scenario is said to extend it. In our vending machine example an extension could be: Customer inserts coins, pushes button, machine returns coins and flashes a “Sorry, out of sweets” sign, if it has run out of sweets.

Resources

As much as I would like to take credit for the knowledge in this article, all the UML stuff comes from:

 

The cool cartoons are courtesy of zlotence.

About the Author