14.2 A Use Case-driven approach | Advanced Object Oriented Programming with Visual FoxPro 6.0

A Use Case-driven approach

Ivar Jacobson first introduced the Use Case as the main application-analysis tool. Use cases are excellent tools to describe applications, including all involved processes, actors and stimuli (see below for a detailed definition of these terms). Use cases describe all necessary user actions as well as required software reactions and modified data.

The most important part of use cases is documents. Typically they are accompanied by a couple of diagrams that provide an overview. Due to their great level of detail, use cases accurately describe an application's functionality, which gives you a good foundation for the next step object modeling (see Chapter 15). Yet, because they are written in plain English, they are simple enough for users to understand and tell us whether the described scenario is accurate. In fact, use cases are so simple that both regular users and domain experts can help you write them.

What exactly is a use case?

My description of use cases above sounds almost too good to be true, doesn't it? I'm sure you are anxious to find out exactly what they are (I know I was when I first heard about them). However, it's hard to find a good definition. I've read a number of books that discuss use cases exclusively, and I still had to read the entire book to find out what a use case was. When I started to write this book, I promised myself I wouldn't make this mistake. But here we are, at the beginning of Chapter 14, the magical place where I define the term "use case" as briefly and accurately as possible.

A use case is a text document that gives a step-by-step description of a scenario that an application must handle. A complete description of an application requires a number of use cases. Each scenario is described in detail, listing all involved actors, all stimuli and all data.

An "actor" is an entity that interacts with the system. It might be a human user or a piece of hardware, as well as some other software component that talks to your application. A "stimulus" is any kind of action an actor takes to interact with the application. The term "data" mainly refers to data stored in tables, but it could also be data in variables, files, or any other kind of data storage such as queued messages.

Use cases are well-formatted documents. They usually start with a section that gives a quick overview of the entire document. Then they list preconditions as well as all involved actors and their roles. The most important part of the use case is the actual scenario that lists all actions, followed by the software reaction. It is followed by special notes, post conditions, GUI sketches, a list of exceptions and references to use cases that describe these exceptions, a list of dependencies (mainly to other use cases), and possibly a couple of domain-specific sections such as timing constraints for time-critical applications or parts of those. Later in this chapter I'll show you a use-case template and an actual use case.

What got me confused when I started learning about use cases was the number of different names for them. At the purest definition, a use case is "a behaviorally related sequence of transactions." In other words, a use case describes a series of actions (reactions) taken by the system once an actor gives a stimulus. However, you will hear people say, "We are currently working on the use cases." In this case they are talking about the whole process of creating documents (containing all the sections I described above) and diagrams that contain the use cases as well as their dependencies. This is an inaccurate use of the term "use case." However, it might also be the most typical use of this term.

Use case diagrams are rather simple. They describe how use cases and actors are related to each other. The definition of each use case (the actual document) is still stored in a regular document (which can be linked to the diagram if a use case tool such as Rational Rose is used).

When I use the term "use case" in this book, I'm referring to the document that describes "behavioral-related sequences of transactions" (the scenario) as well as all the other sections I mentioned above. When I talk about diagrams, I'll refer to them as "use case diagrams."

Once you have a finished use case, you stick it in an envelope (figuratively speaking, of course) and put a label on it. You can now treat this use case almost as if it were an object. You can refer to instances of a use case in larger scenarios. Let's assume we want to describe the scenario of purchasing a ticket for a movie playing in our theater. There are actually a number of steps and actors involved in this process. We obviously have a customer and a salesperson human actors. Note that I don't refer to them as "some person," but I give them a distinctive role. We also would have a use case that describes the process of checking whether a movie is playing and whether or not it's sold out, as well as printing the tickets. However, another use case might be involved if the user pays by credit card. Of course, we could describe the entire scenario in one large use case, but that wouldn't make a lot of sense because a credit-card use case is very generic. We could even reuse this use case in different projects. (Design reuse might even be more efficient than code reuse!) Along with this new use case, we also introduce a new actor: the credit card validation module. (Whether it is a piece of hardware or just a software component doesn't matter at this point.) Figure 1 shows a use case diagram describing this scenario. See Chapter 12 for a description of the notation.

Figure 1. A use case diagram gives a good overview of dependencies between
use cases and actors.

Treating use cases as objects or classes makes it easy for us to talk about the software to be produced. Instead of saying "If the customer pays by credit card, we use a verification module to verify the credit card and receive the payment," we can simply say "If the customer pays by credit card, we use the 'Verify Credit Card' use case." This not only makes it easier to talk about scenarios, but it also makes it more accurate, because the 'Verify Credit Card' use case defines the process in more detail than the first statement.

When treating use cases as classes, you might have the idea to subclass a use case, and indeed this is possible. For instance, you could create a use case that uses 'Verify Credit Card,' but it describes (very briefly) a slightly different scenario that uses a special kind of verification device (a software component instead of some hardware, for example) that requires some extra steps. It wouldn't be smart to rewrite an entire use case just because the software component required a password that the older hardware didn't require. However, keep in mind that we are still talking about regular text documents. "Subclassing" those documents isn't as straightforward as subclassing Visual FoxPro classes. You can simply put a remark in the "subclassed" document that mentions that another use case is to be used, with the exception of the facts in the current use case. For this reason, I recommend subclassing use cases only for small changes, or changes that can be described in a couple of continuous paragraphs. Don't subclass use cases and change nearly every other paragraph or sentence. This is very confusing and does more harm than good.

Transition of a requirement to a use case

Making the transition from requirements to use cases isn't hard, as long as you follow a couple of guidelines. Basically, you bring your list of requirements in a well-organized form and enhance the level of detail. By doing so, you identify the actors and the stimuli as well as the software reactions. You are also likely to discover holes in the requirement matrix, but that's fine. You now have the opportunity to discover those gray areas of the system and put some light on them before they turn into real problems.

Let's have a look at the entire process step by step.

Identify software use cases

The first step is to identify software requirements. All requirements not marked as software requirements do not qualify to get added to our list of use cases; however, they will influence use cases later on. The number of requirements that qualify for use cases can be enormous. However, you typically don't want a separate use case for every single requirement. This brings us to the next question right away: How many use cases do we need for our system? This question is one that people can never agree on. Some think a dozen use cases are sufficient for a two-year, 20-person project, while others aren't satisfied with 1200. It depends on your personal preference.

However, experience shows that too many use cases is more beneficial than too few, simply because large use cases are harder to maintain, handle, and understand. Also, the more use cases you have, the easier they are to group and reuse. For typical Visual FoxPro projects (18 months, up to five programmers), I try to keep the number of use cases in the two-digit range. Obviously I have more than 100 software requirements in most projects, so I typically start out using only the main requirements (for instance, I'd use requirement 1, but not 1.1) and add the other requirements to the Notes section of my use case (see below). This keeps the number of use cases low at the beginning.

However, some additional requirements that are only a note at this point end up as additional use cases later on, when I start to describe the scenarios. There is no real rule to identify additional use cases. This depends on your personal preference. There are various reasons why I would create a new use case. Large scenarios would be one; reusable scenarios would be another. The "Verify Credit Card" requirement might be a sub-requirement in a number of use cases. For this reason I export it into a separate document. Taking this approach, the quantity of use cases seems to emerge quite naturally.

Once I establish a first list of use cases (and a document for each one of those, of course), I start to describe the scenarios in the most detailed way possible. This includes all actors' input and all system reactions, including information displayed on the screen (and every other output media) as well as the required data manipulations.

While doing that, a lot of additional information surfaces, such as a list of actors, stimuli, preconditions, required GUI, dependencies and more. I add this information to the appropriate sections of my use case (see below) as soon as it emerges.

When to start creating use cases

Frequently, people ask me whether they have to find all requirements before starting the use cases. The answer is no. You can start writing use cases as soon as you have a fair number of requirements. However, defining a "fair number" is not quite as straightforward. Requirements often depend on each other, which also means that they change use cases dealing with other requirements. I recommend establishing requirement groups before starting with use cases. Once this is done, you can start writing use cases for the requirement groups that are completed or close to completion. This way, changes in other requirement groups are less likely to influence your work.

The process of converting requirements into use cases is an iterative one. As you create use cases, you will find shortcomings in the requirements that will force you to go back and add missing information. Typically you'll have to talk to the customer or a domain expert to do so. At this point of development, it is important to keep customers and domain experts involved not only to help with requirements, but also to approve use cases and possibly help develop them. As mentioned above, one of the great strengths of use cases is that they are very detailed and technically informative, yet easy for non-programmers to understand.

Establish standards

Before you start creating use cases, you should establish some standards and guidelines to follow in all use cases. Remember that all use cases together build the entire description of your system. It wouldn't be very helpful if every use case had its own naming convention, level of detail, sections in the document, and so forth.

One of the first things you should agree on is the naming convention for use case files. The convention I adopted is "UC### Use Case Name." The triple pound sign (###) stands for the use case number with zero filling. So the two use cases in the example above would be called "UC001 Purchase Tickets" and "UC002 Verify Credit Card." The file extension would typically be DOC, TXT or HTM, depending on your text processor and output format.

I recommend using one template for all use cases (see below). This makes it easy to find your way around in all use cases so you can focus on understanding information rather than finding it. It also makes all required information available in each use case.

Finally, you should establish some standards about the things you want to mention in your use cases. You should agree on what kind of stimuli you want to describe in your use cases. Some people think only human actors and hardware can cause stimuli. I believe that all kinds of actors can cause stimuli, including other software components or events within current applications. You also need to determine a base set of preconditions that must be fulfilled. You don't want to describe every single precondition in every use case, because the list would simply grow too long. However, many preconditions are true for most parts of the system. For instance, I wouldn't mention in every use case that the hardware has to be turned on. While this might be a stupid example, there are many other examples that aren't quite as obvious, but still just as stupid. Nevertheless, they are needlessly mentioned in the set of preconditions, making the use case unnecessarily complex.

Identify involved actors and stimuli

As mentioned above, actors and stimuli usually emerge while describing scenarios. To identify and properly document them, we have to look at the characteristics of actors and stimuli.

Let's start with the actors. As you already know, an actor can be anybody or anything that interacts with the system a human user as well as any kind of hardware and software component. When you identify actors, make sure you describe the role they play. Typically this isn't a problem when the actor is a hardware or software component, but it seems to be a bit more difficult when the actor is a human user. Often I see human actors labeled "User," which is inappropriate.

You need to identify the role the user plays. In the example above, "User" could be either a customer or a sales rep. The difference is quite significant. It makes a big difference whether a customer or a sales rep tries to change the price of a ticket. Had we simply labeled both of them "user," we wouldn't have found a possible security leak or other shortcomings. You might now think that the customer wouldn't have a chance to initiate something such as changing the ticket price because he stands at the other side of the glass. However, this is true only in scenarios where the customer actually walks up to the box office. If he orders his tickets over the Web, he would have simply been "yet another user." This could have given us a lot of trouble had we mislabeled him initially. Giving the customer a specific role prevents such mistakes.

Assigning roles to actors also makes it easier to deal with scenarios where the same human user might play different roles. In the evening a person might be a sales representative, while he wipes the floor or maintains system machinery during the day. By creating multiple actors with distinct roles, we don't care whether we're dealing with one or more people. This helps to avoid a lot of confusion.

Make sure you list all the actors and a description of their roles in the appropriate section of your use case including a brief description of the role they play as well as all their rights and responsibilities.

Now let's move on to the stimuli. A stimulus is any kind of interaction with the system, be it a mouse movement or click that requires some reaction, some text entry, a system event or a message sent by a hardware or software component. It's essential to describe all stimuli, no matter what. Don't just assume certain things (unless you previously agreed on them and documented them). It might be obvious to you that a dialog has some kind of OK button the user must press to proceed, but this might not be so obvious to another programmer.

Eventually, the other programmer might end up implementing a system that proceeds once the user selects an option in an option group, without waiting for the user to click OK or Cancel. It may seem difficult to imagine all possible stimuli, but in reality it isn't all that hard. Every time you describe something the system does without being triggered by a stimulus, you are missing some information. Depending on the format of your scenario description (see below), this is more or less difficult. If you find yourself tempted to skip stimuli, use the tabular format instead of plain text. This format makes such shortcomings very obvious.

Develop scenarios

Scenarios are the most important part of use cases. They describe, step-by-step, all the actions taken by the actors (stimuli) and all the reactions coming from the software. This is done in plain English, so the scenario is easy to understand, even for non-programmers such as the customer or domain expert. In fact, customers and domain experts can help to develop scenarios. (They can also help to describe actors and their roles. Beyond that, use cases are the responsibility of the analyst.)

When starting to develop scenarios, create a rough draft first and fill in the details in later iterations. The UML standard allows multiple scenarios per use case. However, it seems easier to describe only one scenario per use case. This makes use cases easier to understand and maintain, and it is also easier to find common functionality throughout the system. Later on, it is easier to trace requirements through use cases if there is only one scenario.

Remember that the process of developing use cases is iterative. With each iteration, more details will evolve. Make sure to validate the additions of each iteration with domain experts. This gives you a great opportunity to find and resolve problems early in your development cycle.

Let's look at an actual example. The requirements in Table 1 came from the list we developed in Chapter 13.

Table 1. Some entries of the requirements matrix developed in Chapter 13.

Entry #	Requirement	Type	Importance
3	Ticket sales shall be monitored and organized.	SW	High
3.1	Tickets shall be sold at ticket counters.	SW, HW	High
3.2	Tickets shall be sold over the Internet.	SW	Medium
3.3	Credit cards shall be accepted and verified online.	SW	Medium
3.3.1	The application shall continue to run while the credit card is processed, which usually takes a while.	SW, P	High

Each requirement in Table 1 is at least partially a software requirement, so we need to consider all of them directly in our scenario. As mentioned above, requirement 3.3 (which is very generic) will be described in a separate use case, though we wouldn't know that when we first started developing our use cases. In the following example, I refer to another use case, which means that the example doesn't represent the first iteration. Here it is:

The customer requests a certain quantity of tickets for a movie of his choice at the box office. The sales representative checks for the availability of those tickets. If they are available, the customer is told and payment is requested. The customer may pay by credit card (in this case, use case XXX is used to validate the payment) or cash. The amount is entered in the system by the sales rep and validated by the system. If the amount is valid, the tickets and a receipt are printed and handed over to the customer by the sales rep.

There is still some detail missing from this scenario, but more details will be determined during a later iteration. The scenario uses two actors (customer and sales rep), which must be defined in the "actors" section of our use case, like so:

Sales rep: A human user that interacts directly with the system. He is responsible for interacting with the customer. He may access the list of scheduled movies and he may access a list of available tickets (that he may sell). He may not change ticket prices.
Customer: A person who intends to buy tickets. He will not directly interact with the system, but only with the sales rep.

Typically, use cases describe the normal flow of events, such as "The customer walks up to the box office and asks for a ticket for one of the movies playing. The sales rep checks for available tickets, reserves the desired quantity, takes the money and hands the ticket to the customer." Obviously, there are a number of things that could go wrong. For instance, the desired movie could be sold out. Unless this problem is a minor one (which it probably isn't in this case, since it destroys the rest of the transaction), the exceptional scenario would not be described in the current use case, but in a separate one. This makes it easier to follow the scenario without getting distracted by unlikely events or complex scenarios that might not be directly related to the one described by the current use case.

As you may have noticed, we haven't yet handled some of the requirements we intend to cover in the current use cases. We haven't dealt with the Internet scenario, for instance, nor have we handled requirement 3.3.1 (The application shall continue to run while the credit card is processed ). Requirement 3.3.1 can be handled as a simple remark in the "Scenario Notes" section of our use cases, like so:

Execution of use case XXX (Credit Card Validation) may take a while. For this reason, all steps described in this use case shall be executed as a separate thread so it doesn't block the system, and so other sales representatives may continue to sell tickets.

There is a good reason why this requirement doesn't end up in the scenario: Requirement 3.3.1 describes an "implementation issue." We only have this requirement because of hardware-specific issues (verifying credit cards may take a while) not because the business requires a wait state at this point. (They'd be happy to verify credit cards more quickly.) However, use cases should not be cluttered with implementation issues. We'll take care of those in later steps, such as the object modeling step or (more likely) the implementation step.

The fact that the requirements mention the Internet as a possible medium is a different story. Earlier I mentioned that use cases could be treated as classes and could be subclassed, and the Internet requirement would be a good example for using this technique. We can simply create another use case that refers to the first one. This should be done in the "Preconditions" section of the use case. Here's how:

This use case subclasses use case XXX (Selling Tickets). All statements made in use case XXX are valid for this use case, with the exception of additional statements and definitions found in this document.

There are only a few more things that we have to explain in this new use case. First of all, the role of the sales rep changes. This actor is no longer a human user, but an Internet component (application) that communicates with the main system in a similar manner as a human sales rep. A number of technical issues arise with this change most likely, the entire architecture will change. A three-tiered model would be nice. We could have a middle-tier component that handles all logic, and we could have two different interfaces. The human sales rep could use one graphical user interface, and the Internet component could talk to a programming interface. However, at this point we shouldn't be concerned with technical aspects of the system we are going to build. We'll worry about these issues in the modeling step (see Chapter 15).

In addition to redefining the actors, we need to add a minor change to the actual scenario. It's obvious that an Internet component can't just hand tickets over to the customer. For this reason, we have to add some information about how the user will actually get his ticket. We have three options: 1) the user gets an electronic ticket with a confirmation number, 2) the customer can pick up the ticket at the box office, and 3) the customer can receive his tickets by mail. Each one of these options is complicated enough to require its own use case. We will simply refer to these use cases in the scenario. (I will not define these use cases here due to the amount of space it would take.)

So far, we used a simple "descriptive format" to describe our scenarios. In other words, we used regular English sentences in no particular format. However, that's only one of the possible options. The other option is to use a "tabular format." Let's have a look at both options in more detail.

Tabular format

The tabular format organizes scenarios in a table. It lists scenarios in two columns: actions taken by the actors (stimuli) and reactions from the system. Table 2 shows a template.

Table 2. A template for a scenario table.

Action (Stimulus)	Software Reaction
1. <Stimulus given by an actor>	1. <Description of the software reaction>
2. <Stimulus given by an actor>	2. <Description of the software reaction>

Typically, a scenario table is organized as a two-column table. However, in scenarios that have a lot of descriptive text, you might be more comfortable with the format shown in Table 3. This format consists of a narrow first column listing the number of the interaction, and a wide second column containing the description of the scenario. For every interaction, we reserve two rows: one for the stimulus and the other for the reaction.

Table 3. A scenario table that's more readable if you have lots of descriptive text.

Interaction	Description
1	<Stimulus given by an actor>
	<Description of the software reaction>
2	<Stimulus given by an actor>
	<Description of the software reaction>

However, it seems that the format used in Table 2 is easier to understand. For this reason I recommend using this format unless you have an extremely large quantity of text. I use the two-column format in most of my use cases. (Make sure you use the same format in all use cases belonging to one project; otherwise they can be difficult to read and compare.)

Table 4 shows the same scenario discussed above, but in tabular format. As you can see, it's a lot easier to identify stimuli, the overall flow of events, and missing information.

Table 4. Our sample scenario in tabular format.

Action (Stimulus)	Software Reaction
1. The customer walks up to the box office to purchase tickets. The sales rep starts a new ticket purchasing process.	1. The system displays an entry form with a selection box for all scheduled movies.
2. The customer chooses a movie, and the sales rep selects it in the displayed form.	2. The system retrieves information about the quantity of available tickets for the selected tickets.
3. The customer tells the sales rep the number of tickets he wants to purchase. The sales rep enters this information in the system.	3. The system checks whether the number of requested tickets is still available. This repeated verification is necessary, because other sales reps may have soled a number of tickets since step 2 was executed. The system calculates the price for the tickets and displays them on the screen.
4. The sales rep tells the customer the price and collects the money. If the customer pays cash, the user presses a "Cash" button (see GUI sketch) and enters the amount received.	4. The system calculates the change and displays the amount. It also prints the tickets and the receipt, which are handed to the customer by the sales rep.
5. If the customer chooses to pay by credit card, the sales rep presses a "Credit Card" button.	5. The system invokes use case XXX (Verify Credit Card). Once the card is verified, the tickets are printed.

As you can see, tabular formats tend to be better organized and provide more information. They make it very easy to identify steps that must be taken by the actors and reactions that you will have to program once you start to implement the application. I recommend using the tabular format especially if you are just starting to work with use cases. Table 4 shows a direct translation of the example I used earlier, but it contains much more detailed information. If I didn't include these details, the table would have appeared empty and it would have been obvious information was missing.

There are some disadvantages that come with this format. Most importantly, it is harder to subclass tabular scenarios than descriptive ones. But overall, the advantages seem to outweigh the disadvantages. I use the tabular format in all my use cases.

Descriptive format

The descriptive format (as I used in some examples above) seems a lot easier to write. Writing text in simple paragraphs rather than tables seems to be more natural. However, this format efficiently hides shortcomings and information holes. As I mentioned earlier, I prefer the tabular format over the descriptive format in any case. I can only recommend the descriptive format for extremely experienced analysts. For everybody else, failure seems to be preprogrammed.

Preconditions

Most use cases have preconditions that must be fulfilled before the described scenarios can occur. Typical preconditions include other parts of the system that have to be executed first, hardware that has to be in a certain state, or business rules that have to be fulfilled. In our "Purchase Tickets" use case, preconditions would be that the movie schedule has to be up to date, and the credit-card-verification hardware has to be connected (possibly online as well) in case we decide to accept credit cards. Beyond those technology-related preconditions, there might be some business-related aspects maybe we are not allowed to sell certain tickets before a certain date and time, and so on. Purists might now argue that I'm mixing different kinds of preconditions. In fact, the precondition that the credit-card module has to be online is entirely different from the precondition that tickets can't be sold more than three hours before the movie starts. This precondition is complex enough to require its own use case. However, in favor of the simplicity of this example, Ill leave it at that.

All preconditions must be listed in a special "Preconditions" section of our use case document. Do not make the mistake of explaining preconditions in the actual scenario. Preconditions just don't match the "action-reaction" format in which scenarios are written. It simply clutters the clarity of the scenarios. Also, you might end up reading and analyzing the use case and spending a lot of time with it, until you realize that the preconditions haven't been fulfilled. Having a separate section allows you to find use cases that match certain preconditions much more quickly and painlessly.

Never assume that programmers are aware of preconditions. It might be obvious that a movie schedule has to be set up before we can actually start selling tickets. However, during design and implementation, this might not be as obvious. Programmers might think they can sell the same kind of ticket every evening (which may or may not be true), or facts that seemed obvious during analysis might simply be forgotten during later phases when they're focusing on other challenges (such as technical issues or actual lines of code). The only preconditions you can assume to be known are those that are set and documented for the entire project.

Post-conditions

Post-conditions describe the status of a system after the scenario has been executed, including tasks that have been accomplished in the scenario that aren't yet clear. In our example, this includes the fact that the number of purchased tickets is subtracted from the number of available tickets. Basically, post-conditions provide a summary of things that changed while the scenario was executed.

Dependencies and relations

Use cases often refer to other use cases, as I mentioned above with the "Validate Credit Card" use case in our scenario. We can reference other use cases in more places than just the scenarios. Preconditions regularly refer to use cases. The precondition that states that a schedule has to be set up should refer to the use case that describes the scheduling process. We might have a note about this fact in the "Preconditions" section, but we should also list this use case in the "Dependencies and Relations" section. This allows us to quickly get an overview of all other use cases that describe a similar kind of scenario or those that are at least somehow related to the current one.

Other sections that might include references to other use cases include (but aren't limited to) the description of actors and stimuli, as well as the general use case overview, post-conditions, notes, and other sections.

GUI specifications and draft GUI sketches

Part of a use case is the actual description of the interface to be used, which is initially done using only words. Later in the process, you can (and should) create some draft sketches of the user interface. This will give the customer a rough overview of what he can expect to receive, and it will give the programmer a rough guideline for the actual implementation.

There are different ways to sketch interfaces. You can use scanned hand-drawings or graphical tools such as Corel Draw, or any other drawing program. I don't recommend using pixel-oriented tools such as MS Paint, because they don't allow you to change your sketches easily later on. I often use Visual FoxPro to design interface prototypes because it allows me to create them so quickly. When creating a Web-based application, I recommend Microsoft FrontPage or Visual InterDev (or any other HTML editor) to create a very rough version of the final interface. I've found that creating sketches that look like real interfaces, rather than just hand drawings or abstract versions of the final product, help to avoid confusion on the customer's end. However, I never tell the customer that the interface sketches are actual FoxPro forms or HTML pages. Customers usually confuse these early prototypes with the final product and expect too much too soon, so I leave them thinking that they are looking at nothing more than simple images.

Use case diagrams

Use case diagrams provide a quick overview of dependencies between use cases and actors. Figures 1 and 2 in this chapter show examples of such diagrams. Both diagrams were created using Rational Rose (see below). Use case diagrams are nice to have, but they are not an essential part of a typical set of use cases. In other words, you could easily do without use case diagrams, but your entire set of documents would be worthless without the scenarios. Nevertheless, use case diagrams provide a nice and easy-to-read summary of all facts listed in the "Dependencies" and "Actors" sections of the documents. For more information about UML use case diagrams, see Chapter 12.

A sample use case

Now that you have a lot of theoretical knowledge about use cases, you should examine an actual example. But first I'll provide a use case template as I promised earlier.

A use case template

The following template has always worked well for my use cases, although you might feel more comfortable with a slightly altered version. You can download an actual use case template in Microsoft Word format from the Developer's Download Files at www.hentzenwerke.com.

Use Case XXX: Use Case Name

Overview:

Notes:

Actors:

Preconditions:

Scenario:

Scenario Notes:

Post-Conditions:

Exceptions:

Required GUI and GUI Sketches:

Dependencies and Relations:

Additional sections to be added as needed

UC001: Purchase Tickets

Now that you know how a well-formatted use case document should look, take a look at an actual use case. Below is the entire "Purchase Ticket" use case that we've used in several examples in this chapter.

Use Case 001: Purchase Tickets

Overview:

This use case describes the process of purchasing tickets at the box office.

Actors:

Sales rep: A human user that interacts directly with the system. He is responsible for interacting with the customer. He may access the list of scheduled movies and he may access a list of available tickets (that he may sell). He may not change ticket prices.
Customer: A person that intends to buy tickets. He will not directly interact with the system, but only with the sales rep.

Preconditions:

A movie schedule has to be set up (as described by use case 021).
The sales rep has to be logged into the system (see use case 018).
The scenario described in this use case cannot be executed more than
three hours before the movie starts.

Scenario:

Use Case 001, continued

Scenario Notes:

Reaction #5 shall not block the server component while processing the credit card, to enable other sales reps to continue selling tickets.

Post-Conditions:

The number of purchased tickets has been subtracted from the ticket pool.

Exceptions:

Action 2 and/or 3 could be impossible if there aren't enough tickets left. In this case, the customer is told so and the use case starts over.
Step 5 might fail if the credit card isn't valid. This scenario is handled by use case 003 (Invalid Credit Card).

Required GUI and GUI Sketches:

The interface required for this scenario is rather simple. One of the main targets is to make it very easy to use. Sales reps at the box office might be students hired for short-term periods, so they won't receive extensive training. The interface could be implemented as a regular Windows interface or as an HTML page. The following two figures show examples of both versions.

Use Case 001, continued

Both interface components show the first step of selling a ticket. Once we've decided what kind of interface to use, in a later iteration we will describe other interface components required by this scenario.

Dependencies and Relations:

UC002: Verify Credit Card
UC003: Invalid Credit Card
UC018: User Login

UC021: Maintain movie schedule