UMLUse Case Diagrams

A use case diagram depicts actors, use cases, and the relationships among them. Use case is a software engineering term that is equivalent to a social scientist's notion of task. With some simple extensions, use case diagrams can be used to represent a usability professional's task model.

Who does the work?

The following figure shows the UML symbols for actor (the stick figure) and use case (the ellipse).

The two principal symbols in UML use case diagrams: the actor and the use case.

UML recognizes two kinds of actors, concrete actors and abstract actors. A concrete actor represents one user population operationally defined as a group of actors that share the same basic set of responsibilities. An abstract actor represents a user role which is the set of responsibilities common to multiple user populations. An abstract actor is used as a shorthand way to say, “Any concrete actor who fulfills this role.” On a UML use case diagram, a generalization relationship (a line with an open triangle pointing to the general case) shows which concrete actors fulfill which abstract actor's role.

A diagram fragment showing the generalization relationship between an abstract actor role and two concrete actors representing two user populations.

What is the actor doing?

A use case represents a task. A Task is simply some piece of goal-directed work performed by a user or organization (group of users). A task performed by an organization is also sometimes refered to as a Process. Some modelers, this author included, prefer to make a distinction between:

• Use case—a user task
• Business case—a business task performed by an organization (a group of users); also sometimes called an organization case

The following diagram fragment shows a use case representing the user task, Create Order.

The UML diagram symbol for a task, in this case a task named, Create Order.

UML notation also provides a way to indicate which use cases (tasks) are performed by which actors. This is indicated by the association relationship (a plain line) between an actor and a use case. The following diagram shows one role, Order Fulfiller, performing five use cases (tasks).

A use case diagram showing the association relationship between an abstract actor role, Order Fulfiller, and the five use cases that role performs.

Notice the notations concerning frequency and criticality attached to each link in the preceding diagram. The frequency and criticality of each combination of actor (Order Fulfiller) and task (Create Order, for example) is captured to facilitate the process of modeling users and their tasks. For more detail, see the sidebar, Frequency and Criticality.

What is the actor trying to accomplish?

One important aspect of use case modeling is the notion of tasks being driven by goals. A goal is a statement of the motivating force driving a user or an organization to complete a task. The goal a user is trying to acchieve will often bias both the way in which the user tries to complete a task and what will be judged as sucessful completion.

Here is a simple example of a user task goal. The user's task is to take a customer's order for widgets. The task of taking the order can be described as a procedure—a sequence of task steps. The user's goal in taking the order is to minimize the customer's need to make further contact with the widget pruveyor and so the user wants to take orders with great accuracy. At the same time it is nice to minimize the amount of customer time the order fulfiller takes up, but there is no special concern with the speed of the interaction.

In this situation, the interface designer can choose to optimize the UI for speed of task completion or accuracy of task completion, or the designer can build an interface that is a compromise between accuracy and speed. If the interface designer chooses to optimize for accuracy and, within the constraints imposed by that design, provides as much help in speeding the user along as possible, the user will be able satisfy her goal and complete the task in an efficient manner.

If, on the other hand, the user interface is optimized for speed of completion and fails to provide the user with adequate warning of impending mistakes, the interface designer is setting up conditions that lead to a failure of the user to reach her goal. This is an especially simple example but even obvious conflicts between task procedure and user goal are frequently perpetrated on users in day-to-day practice. To avoid this, usability professionals will go through each task a user performs and capture a short description of the goal a user is attempting to satisfy when they complete that task.

Beware the UI that forces the user to perform so called work-arounds. If an interface makes task completion akward or makes it in any way more difficult for a user to acchieve his task goal, a usability problem exists that should be addressed.

Usability problems related to goals can be especially hard to predict when the user's goals are at odds with the organization's goals but neither user nor organzition is aware of the conflict. This problem can be compounded if the usability professional is also unaware of the conflict. The interaction of user and organizational goals is explored in more depth in the sidebar, The Importance of Goals in Task Modeling.

How does one task relate to another?

In addition to showing which actors perform which use cases, a use case diagram can show relationships among use cases as well. The next use case diagram shows two relationships among the use cases.

Tasks that are steps within another task.

The first is an include or composition relationship. It shows how one use case can be decomposed into one or more other, usually more specific, use cases. A composition relationship implies that the composed use case (the one at the end of the arrow point) is a step in the composing use case's procedural definition. You can see a composition relationship between the Browse Order use case and the Find Order in Context use case. The relationship shows that Browse Order has, as one of its steps, the entire use case, Find Order in Context. This relationship also shows a constraint indicating that the Find Order in Context use case is optional. It is possible in the Browse Order use case to identify an Order by order number and therefore remove the need for the user to search for the appropriate Order.

Tasks that trigger other tasks.

The second relationship is an association, labeled triggers, that links two use cases. This relationship notes that it is common for the user to complete the origin task (Find Order, for example) with a goal that requires the user to begin performing the task at the destination end of the relationship (Browse Order, for example). Though not indicated here, the user is taking the result of one task (a selected Order in this example) and is basing performance of the next task on this result. The triggers relationship is an extension of the standard UML use case relationships and not one of UML's standard relationships. It should be used when one task may follow another, but the first task is not specifically related to the second in any way other than the work product of the first being consumed as a starting product of the second. To put these two tasks together in a task composition would ignore this work product relationship and imply a procedural relationship that isn't there (that is, the first task doesn't depend on successful completion of the second, as an include relationship would imply).

The figure below is a use case diagram showing the includes or composition relationship between two use cases as well as the triggers association also between two use cases.

Figure: a UML use case diagram, over 650 pixels wide—click here to open it in a separate window.

Summary

This discussion has shown how to use a UML use case diagram to depict a task model including the relationship of one or more user populations to abstract user roles and the relationship between either a user role or a user population and the use cases (tasks) that user performs. The relationships among tasks were also shown. This included the decomposition of one task into its component tasks and a relationship, triggers, that indicates when a user will want to frequently start a second task on the basis of the completed work product from a first task.