The Case for Using Use Cases

The concept of a use case has created a bit of stir. Use cases were invented by one of the foremost experts in object-oriented design, Ivar Jacobson, who is now part of the team who created UML, the Unified Modeling Language. (And today, use cases are an important part of both UML and the Rational Unified Process™, which is one of the primary design methods that make use of UML.) Yet, in many ways, they are completely functional in nature, as opposed to object-oriented. But that’s okay. They work. And you should use them.

What’s a use case? A use case is a small description of one piece of functionality in your software. Right now I’m using Microsoft Word to type this chapter. Here are some of the use cases for this huge piece of software:

• Toggle italic

• Set a style

• Indent

• Run a particular macro

(I should mention, however, that some of the experts treat groups of functions as a single use case. Their idea is that a use case is a sequence of actions that together provide a result for the user. This is, in fact, the more formal definition of use cases. These people usually have a considerably smaller list of use cases when they design their software, but the use cases embody several features.)

Note

If you read Chapter 1, “The UUI: The Useable User Interface,” you might be experiencing a bit of d j vu: I talked about these features of the word processor, but in a different light. In that chapter, I talked about them as commands. They’re the same thing. From the user’s perspective, these are commands. From a design perspective, they are use cases.

When done properly, use case analysis helps you figure out the features of your software. Further, if you implement the command-driven approach I described in Chapter 1, then you can easily bring your use cases (and hence, your software functionality) to fruition.

Clearing Up Some UML Misconceptions

While on the topic of use cases, which are now an official part of UML, I’d like to clear up some misconceptions about UML. When asked what methodology people use, some people will say, “We use UML.” That’s not correct. If you’re interviewing for a job, and they say that, it means they’re not using any methodology, because if they were, they’d see the problem in that statement. UML, which stands for Unified Modeling Language, is not a methodology. UML is a visual language or notation. It is a set of diagrams along with a complete formal grammar describing how the diagrams interact with each other. Further, it is extensible; when necessary, you can add your own diagrams to the language. UML can be used in many areas of engineering, not just software. However, software is certainly where it is mostly used since, frankly, most people outside of the software world haven’t heardof UML.

Many programmers, when first exploring UML, quickly become disenchanted because they get a bit confused. They read a book on UML, and they learn what all the symbols mean, but they’re left with feeling lost in how to use UML to actually build a software system. That’s because they studied only half the story. They’re missing the second half, the process, which some people call a methodology.

The usual process people use with UML is the Rational Unified Process. (However, you can use other processes, too, with UML.) The Rational Unified Process, created by the same people who brought us UML (Grady Booch, Jim Rumbaugh, and our use-case pal Ivar Jacobson), is a formal set of steps that take you through the complete design and building of your software, all the way through testing and deployment. The process contains many of the usual steps you’ve come to expect out of a good methodology: requirements, analysis, design, implementation, and deployment.

If you want to learn more about both UML and the Unified Process, the best introductory text I have found is UML and the Unified Process by Jim Arlow and Ila Neustadt (Addison-Wesley, 2002).

Entire books have been written on use case modeling, and trying to cram it all into one section of one chapter would do the topic a serious disservice. So instead of teaching you use cases, I’m going to go up one step on the proverbial Ladder of Abstraction and explain how to make use cases work for your system.

Use case modeling takes place early on in the engineering process, long, long, long before you write any code. Use case modeling is part of the requirements phase. You write use cases in a human language such as English so that the managers can read them.

Note

Really, use cases don’t just describe the features of a system from a human perspective. If you’re building, for example, a system that primarily interacts with other software (such as a web server), you will still design use cases. But for these use cases, the user is not a human; it is another software system.

People heavily into object design like to use the term discover to describe how you create your use cases (and other parts of a system, such as objects, for that matter). I’m not fond of this, because I like to think of us engineers as having a little more cognition in the software process beyond simply discovering something as if it came to us out of the ether and fell into our laps. However, the people who use the term don’t really mean it like that, and so I’ll accept the word and use it too.

After you have followed the procedure for discovering use cases (such as that outlined in the Unified Process), I want you to do two things:

1. Hand the use cases off to somebody in the business who is not technical and understands typical users.

2. Take a good hard look at your own use cases from a user perspective.

As for number 1, wear a thick skin and allow the coworker to be brutal. (Better now than later when you start getting e-mails from the real users!) Listen, take notes, and take the user’s concerns seriously. Then go back and fix the problems. As for number 2, ask yourself: Are these use cases reasonable? Do they make sense? Are they easy to use? Are they complete?

But go beyond that. Here are some more questions:

• Can you combine some into a single use case?

• Is there any redundancy that will confuse the users?

• Are any of them too specific?

Here’s an example. Suppose you were creating a word processor, and you came up with the following two use cases:

• Turn italics on

• Turn italics off

So far these seem reasonable: You, as the user, highlight some text that’s not in italics, and you somehow initiate the Turn Italics On command (either through a keystroke, or a menu item, or a toolbar button). Then you realize the middle word shouldn’t be italicized, so you highlight that one word and trigger the Turn Italics Off command. And what if you highlight text that’s a mixture of italicized and non-italicized text? Then choosing Turn Italics On will make all the highlighted text italicized, while choosing Turn Italics Off will make all the highlighted text non-italicized.

But stop. Wait, time out! If you let this go all the way through the development process and into the final product, you’re going to have some unhappy customers. Imagine if the word processor had two separate buttons on the toolbar, one called Turn Italics On, and one called Turn Italics Off. Is that really necessary? Instead, is it possible to combine these into a single use case called Toggle italics?

If you use Microsoft Word, you will see that you have a single use case called Toggle italics. It’s not two separate ones, and it works fine: If you highlight non-italicized text and choose Toggle Italics (Ctrl+I works), the text becomes italicized. If you highlight italicized text and choose Toggle Italics, the text becomes non-italicized. And if you highlight a mixture of italicized and non-italicized text, all the text becomes italicized. It works fine, and it’s one less use case to worry about and one less angry customer who keeps clicking the wrong button. Oh yes, and one less confused customer who can only seem to turn italics on but just can’t seem to turn them off because somehow he accidentally removed the Turn Italics Off button from his toolbar and doesn’t understand how to bring it back by using the Customize dialog box in Microsoft Word. (Wouldn’t you like to work tech support when he calls?)

Incidentally, this toggle approach has the added benefit that the toolbar button can now show state: When you highlight italicized text, the toolbar button appears depressed. To unitalicize the text, “unclick,” or deselect, the toolbar button (that is, click it so it’s no longer depressed). It works great.

Now here’s another example of a Use Case Gone Bad. This is another one that might have ended up in our word processor program. This one fails in the question, “Are any of them too specific without enough configuration?” Here’s the use case: Indent every paragraph by a half inch. This one is easy to fix: Make the “half inch” part configurable! Change it to this: Indent every paragraph by a user-supplied amount.

That’s better, but still, a sophisticated word processor such as Microsoft Word wouldn’t have much use for a use case like this, because Word has a powerful set of use cases that deal with setting styles. You can define a style to have a certain indentation and assign that style to any paragraph you want. Then if you change the style’s indentation, every paragraph using that style will automatically change to the new indentation level.

So how did Microsoft come up with the notion of styles? I wasn’t there, so I can’t say exactly, but I suspect somebody had considered a use case such as the paragraph indentation one. I could imagine that somebody else might have then added a use case changing the font of every paragraph. And somebody else suggested that you somehow notate which paragraphs to change the font. This type of brainstorm is good, because if you go with it, you will get to the real solution, provided you don’t stop. If they had stopped, then I might be having to go through and somehow manually select each paragraph in this text as I write it, choose the special style the publisher created for me, and then one by one set the font attributes and indentation attributes.

But instead, Microsoft combined redundant use cases into a single set of use cases that are, in the end, extremely powerful. I like styles in Microsoft Word, because they make my life much easier, whether I’m writing a book or a letter.

Let’s continue with the brainstorm. Microsoft saw that these use cases were somehow related, and they saw the common thread: setting a feature in every paragraph. But thanks to the guy who suggested that you somehow notate which paragraphs to set, they decided to combine these: You can create a style (that’s a good word) and assign it to a paragraph (that’s a use case). Then you can set the indentation for that style (that’s a use case, too). And you can set the font for that style (another use case).

Now this leads to another rule for dealing with use cases:

RULE

Create logical groups for your use cases.

REAL WORLD SCENARIO: The Electronic Music Synthesizer that Had It All

I’m a musician, and back in the 1980s I remember seeing an issue of Keyboard Magazine that had a feature covering all the music synthesizers that were made by small startups (akin to the dot-coms 10 years later) that just never quite made it. These synthesizers were actually quite amazing, even if there was only one of each, and it was a prototype. They featured multiple keyboards stacked like you find on a pipe organ and some pretty advanced technologies that were ahead of their time. They used some modern digital techniques for sound synthesis, mixed with older analog techniques. They were what was at the time known as polyphonic (meaning they could play more than one note at once—a feature, believe it or not, that was not present in every synthesizer back then). Some even had pedals on the floor like a pipe organ has. Some had buttons, some had drawbars called stops like the old organs had (that’s where the phrase pulling out all the stops comes from), and some had dials and knobs like the newer keyboards. Some even had LED displays.

Are you starting to see the problem here? There was a common thread among all these keyboards that was the fundamental reason behind their failure in the sales department: They had way too many features.

When you start to discover the command approach to software present in such applications as Microsoft Office (as I described in Chapter 1), you start to realize how easy it is to add features to your software. But don’t do it! Settle on a good solid set of use cases, and once you begin coding the software, don’t add new features. Resist, resist, resist! Yes, you’ll likely discover some important (but minor) use cases you forgot, and you can go ahead and add them. But don’t keep adding more and more features. Otherwise you’ll have two results: (1) You will release your software far, far later than you planned (if ever), and (2) People won’t buy it because they’ll find it overwhelming, just like these synthesizers that failed. (And maybe 20 years from now your software will be mentioned in a book as an archeological oddity, like I’m mentioning these synthesizers. That alone should be reason not to let feature creep take over.)

You don’t want to just have a billion features in your product. Imagine if you had one menu, and that menu could scroll, and it would scroll endlessly, on and on, until you finally found that feature you wanted. Yuck. Or imagine if the software you used had only one toolbar and it had 350 buttons on it. Yikes! (I pity the graphic artist hired to come up with all 350 button images.) Instead, like the style use cases, your use cases should have logical groups. Then:

RULE

If you have a use case that doesn’t seem to have a group, reconsider the use case.

You might have a good reason to keep a use case that’s not part of the groups you created. It might be a powerful one, like Quit the application. However, most likely, either you’re missing some use cases or you have a use case that you don’t need. The use case about indenting every paragraph is an example of a use case without a group. By itself, it seemed a little bizarre and was probably the idea of somebody who has a fixation with indentations. But further analysis led to more use cases in a similar group, which ultimately led to my invention (oops, I mean Microsoft’s invention) of paragraph styles.