Home > Articles > Programming > Java

Java Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Use Case Diagrams

Last updated Mar 14, 2003.

When modeling a system, a good place to start is with use cases. Use cases define how external "actors," which may be people or other systems, are expected to use your system to accomplish a business objective. Defining use cases involves a couple steps:

  1. Defining your actors
  2. Defining the interactions that you expect your actors to perform

Actors can be users, external systems, or even local processes that trigger some action in your system. If you were building an online book store, you might identify actors such as users that purchase books, administrators that add new books to your inventory, book distributors that send your system a manifest of books that are being shipped to you, an external book seller that sends you an order for books, an automated trigger such as a cron job or scheduled task that reconciles inventory at 2:00am every morning, and so forth. The point is that you need to identify all external "things" that will interact with your system and group them into roles that you'll call actors.

Once you have identified your actors, the next step is to outline, from a high-level, how you expect those actors to interact with your system. A use case defines, from a user perspective, a complete use of your system. This means that use cases are written with verbiage that is very business-centric. For example, a use case might be "Create a new account," "Add a book to a shopping cart," "Order an out-of-stock book," "Reserve a new book," "Checkout and pay for my books," and so forth. The point is to think about how your actors will use your system in terms of the objectives they are trying to obtain and what they will need to do to obtain those objectives.

Actors can be represented in UML in one of two ways:

  • A stick figure with the actor's name below the stick figure
  • A box with the <<actor>> stereotype added to it

Figure 1 shows two actors (User and Administrator) in MagicDraw.

Figure 1

Figure 1. UML Representations of Use Case Actors

In most cases people opt to present actors using the stick figure notation, but you should be aware of the alternate notation in case you see it in a diagram.

Actors can be defined individually or using an inheritance relationship if you have actors that truly are specialized cases of other actors. Consider the example of a user and an administrator: you would expect an administrator to be able to do everything that a user could do, but with added functionality, such as the ability to add books to the database. Figure 2 shows how specialization is depicted between actors.

Figure 2

Figure 2. Use Case Actor Inheritance

In figure 2, the Administrator actor is a specialization of the User actor, or put another way, the administrator is a special type of user.

Once you have your actors identified, it is time to analyze your system with the intent of determining what actions you expect your users to perform with your system. In UML, use cases are represented with an oval with the name of the use case inside. This is shown in figure 3.

Figure 3

Figure 3. Use Case Bubble

A use case oval alone is not very interesting, what makes it more interesting is when you include actors and use cases together and show which actors perform which use cases. Figure 4 shows a use case diagram that contains use cases, actors, and associations between actors and use cases.

Figure 4

Figure 4. Use Case Diagram

Figure 4 shows five use cases executed by the User actor and two executed by the Administrator actor. Use cases themselves are more than a singe statement and contain things like:

  • Goal in Context: a description of what the use case is attempting to achieve
  • Preconditions: things that are required before the use case can run
  • Successful End Condition: what you expect the system to accomplish if the action is successful, such as "New account created"
  • Failed End Condition: the behavior of the system if the use case fails, such as "Account creation is rejected"
  • Primary Actors: the primary actors expected to execute this use case
  • Secondary Actors: actors that might be involved in the use case, but are not the ones that instigate the use case
  • Trigger: the behavior performed by the actor to start the use case, such as "User asks the system to create a new account" (and note that this is very generic verbiage that does not include implementation details like "User enters a username and password on the create new user page and presses the create account button." We want to keep this as abstract as we can.)
  • Main flow: the steps that the system performs to accomplish the use case
  • Extensions (or alternate scenarios): different behaviors that might occur in the use case based on different conditions. For example, an alternate scenario to the create user account might define a failure condition when a user tries to create an account with an existing username

As you define the details of your use case you might start to notice that some steps are repeated between use cases. For example, you might need to validate that the user has an active account before allowing him to add books to a shopping cart or check out. If that is the case, you can define another use case that contains that specific set of steps and then include it into your other use cases. This is accomplished in UML by defining the new use case and drawing a dashed arrow to it with the stereotype "<<include>>" on the line. This is shown in figure 5.

Figure 5

Figure 5. Use Case Diagram with <<include>> stereotype

This visually shows that the bottom four use cases include the "Validate that the user has an account" use case. In the detailed flows of the use case (main and secondary) you would simply add an "include: Validate that the user has an account" statement where belongs in the flow.

The include stereotype allows you to include a specific set of steps in your flows, but what happens if you want to take an existing use case and create a new one that modifies some part of its behavior? The include stereotype requires that each step be included in the new use case verbatim, but UML supports the notion of use case inheritance by using the generalization arrow. Figure 6 shows an example of use case inheritance.

Figure 6

Figure 6. Use Case Diagram showing use case inheritance

If figure 6, the "Create a new user account" and "Create a new administrator account" use cases are specializations of the "Create a new account" use case. When defining the steps in the flows you can show the steps that are different between the general use case and the specialized use case.

The final use case relationship concept that you should be familiar with is the "extends" relationship. Unfortunately, extends has nothing to do with inheritance, as Java programmers would think, but rather it means that one use case may or may not include the entirety of another use case based on some condition. For example, you might define an auditing use case and optionally include it if account creation fails.

Figure 7 shows an example of the extends stereotype.

Figure 7

Figure 7. Use Case Diagram showing the extends stereotype

In figure 7, if an error occurs then the "Record Errors" use case is executed.

Use case diagrams are a good way of presenting the actors that use your system as well as the actions that your system performs, with support for componentizing use cases with the include stereotype, creating specialization use cases with the generalization arrow, and identifying optional includes using the extends stereotype.