Rational Software Corp.

TOC PREV NEXT INDEX


Use-Case Diagrams and Specifications

Contents

This chapter is organized as follows:

Use-Case Diagram Overview

Use-case diagrams present a high-level view of how a system is used as seen from an outsider's (or actor's) perspective. These diagrams graphically depict system behavior (also known as use cases). A use-case diagram may depict all or some of the use cases of a system.

A use-case diagram can contain:

Use-case diagrams can be used during analysis to capture the system requirements and understand how the system should work. During the design phase, use-case diagrams can be used to specify the behavior of the system as implemented.

You can create or display a use-case diagram in one of three ways:

Actors

Actors represent system users. They help define the system and give a clear picture of what the system should do. It is important to note that an actor interacts with, but has no control over, the use cases.

An actor is someone or something that:

Actors are discovered by examining:

An actor is a stereotype of a class and is depicted as a "stickman" on a use-case diagram. The name of the actor is displayed below the icon.

Use Case

A use case is a sequence of events (transactions) performed by a system in response to a trigger initiated by an actor. A use case contains all the events that can occur between an actor-use case pair, not necessarily the ones that will occur in any particular scenario.

In its simplest form, a use case can be described as a specific way of using the system from a user's (actor's) perspective. A use case also illustrates:

Use cases provide a means to:

Use cases are best discovered by examining what the actor needs and defining what the actor will be able to do with the system; this helps ensure that the system will be what the user expects.

Since all the needs of a system typically cannot be covered in one use case, it is usual to have a collection of use cases. Together this use case collection specifies all the ways of using the system.

A use case may have a name, although it is typically not a simple name. It is often written as an informal text description of the actors and the sequences of events between objects. Use case names often start with a verb.

The name of the use case is displayed below the icon.

Flow of Events

A flow of events is a sequence of transactions (or events) performed by the system. They typically contain very detailed information, written in terms of what the system should do, not how the system accomplishes the task. Flows of events are created as separate files or documents in your favorite text editor and then attached or linked to a use case using the Files tab of a model element. See the Files Tab for a discussion the Files tab.

A flow of events should include:

You can use activity diagrams to further model flows of events.

Relationships

Relationships show interactions between actors and use cases. Association, dependency, and generalization relationships can be drawn from an actor to a use case. The generalize relationship can be drawn between actors.

Any association relationships are also presented in a text format on the Relations tab (described later) for a selected use case or actor.

Association

An association provides a pathway for communication between use cases and actors. Associations are the most general of all relationships and consequentially, the most semantically weak. If two objects are usually considered independently, the relationship is an association. The association name and its stereotype are typically verbs or verb phrases and are used to identify the type or purpose of the relationship.

There are two different types of associations connected with use-case diagrams: uni-directional and bi-directional.

Uni-directional association: By default, associations in use cases are uni-directional and drawn with a single arrow at one end of the association. The end with the arrow indicates who or what is receiving the communication.

Bi-directional association: To change the communication to be bi-directional, double-click the association to view the Association Specification. Click the appropriate Role A (or B) Detail tab, select the Navigable check box, and click Apply. You have now made the association bi-directional. The graphic changes from a line with an arrow at one end to a line with no arrow.

If you prefer, you can also customize the toolbox to include the bi-directional tool in the use-case toolbox. See Customizing the Toolbox for information on adding or deleting diagram toolbox tools.

Dependency

A dependency is a relationship between two model elements in which a change to one model element will affect the other model element. Use a dependency relationship to connect model elements with the same level of meaning. Typically, on class diagrams, a dependency relationship indicates that the operations of the client invoke operations of the supplier.

You can connect model elements with dependencies on any diagram except state machine diagrams and object diagrams. For example, you can connect a use case to another use case, a package to another package, and a class to a package. Dependencies are also used on component diagrams to connect model elements.

Extend Stereotype

An extend relationship is a stereotyped relationship that specifies how the functionality of one use case can be inserted into the functionality of another use case. You can place extend stereotypes on all relationships. However, most extend stereotypes are placed on dependencies or associations. Extend relationships are important because they show optional functionality or system behavior.

Include Stereotype

An include relationship is a stereotyped relationship that connects a base use case to an inclusion use case. An include relationship specifies how behavior in the inclusion use case is used by the base use case. Include relationships are important because they represent that the inclusion use case functionality is used by the base use case.

Refine Stereotype

A refine relationship is a stereotyped relationship that connects two or more model elements at different semantic levels or development stages. It represents a fuller specification of something that has already been specified at a certain level of detail. For example, a design class is a refinement of an analysis class. In a refine relationship, the source model element is general and more broadly defined whereas the target model element is more specific and refined.

Generalization

A generalization relationship is a relationship between a more general class or use case and a more specific class or use case. A generalization is shown as a solid-line path from the more specific element to a more general element. The tip of a generalization is a large hollow triangle pointing to the more general element.

You can place a stereotype on any generalization through the Generalization Specification. However, three common stereotypes for generalizations are extends, includes, and generalization.

Use-Case Diagram Toolbox

The graphic below shows all the tools that can be placed on the use-case diagram toolbox. Refer to "Customizing the Toolbox" on page 14 for information on adding or deleting diagram toolbox tools.

The application window displays the following toolbox when the current window contains a use-case diagram and As Unified is selected from the View menu.

Some icons will be different if As Booch or As OMT is selected from the View menu.

Figure 43 Use Case Diagram Toolbox

Use-Case Specification

A Use-Case Specification allows you to display and modify the properties and relationships of a use case in the current model.

Specification Content

The Use-Case Specification contains the following tabs: General, Diagram, Relations, and Files.

Use-Case Specification--General Tab
Figure 44 Use-Case Specification--General Tab

Refer to the descriptions in the Introduction to Specifications chapter for information on the specification elements not covered in the following section.

Name

A use case name is often written as an informal text description of the external actors and the sequences of events between elements that make up the transaction. Use-case names often start with a verb. The name can be entered or changed on the specification or directly on the diagram.

Package

This static field identifies the package to which the components belong.

Rank

The Rank field prioritizes use cases. For example, you can use the rank field to plan the iteration in the development cycle at which a use case should be implemented.

Abstract

An abstract notation indicates a use case that exists to capture common functionality between use cases (uses) and to describe extensions to a use case (extends).

Use-Case Specification--Diagram Tab
Figure 45 Use-Case Specification--Diagram Tab

Refer to the descriptions in the Introduction to Specifications chapter for information on the specification elements not covered in the following section.

Diagram List

The diagram list contains all the diagrams owned by the use case. The diagram list consists of two columns. The first (unlabeled) column displays the diagram icon type for the diagram. The second column displays the diagram name. To insert a new diagram in the list, click one of the Insert choices in the shortcut menu that corresponds to the diagram type.

Use-Case Specification--Relations Tab
Figure 46 Use-Case Specification--Relations Tab

Refer to the descriptions in the Introduction to Specifications chapter for information on the specification elements not covered in the following section.

Relations

The Relations tab lists all the association relationships that correspond to the selected use case. The client and supplier names and type icons are displayed to the right of the relation name. Double-clicking on any column in a row displays the element's specification.

Generalize Specification

A Generalize Specification allows you to display and modify the properties and relationships of a use case in the current model.

Specification Content

The Generalize Specification contains the General tab.

Generalize Specification--General Tab
Figure 47 Generalize Specification--General Tab

Refer to the descriptions earlier in this chapter or in the Introduction to Specifications chapter for information on the specification elements not covered in the following section.

Stereotype

Stereotypes allow you to provide additional distinctions in your model that are not explicitly supported by the UML. The use of stereotypes makes it easy to add information about modeling elements that may be specific to a project or process.

The Generalize Specification uses stereotypes to create two new use-case relationships that can be attached to a model element to indicate a special relationship between use cases.

Friendship Required

Select the Friendship required check box to specify that the supplier class has granted rights to the client class to access its non-public members.

Virtual Inheritance

Select the Virtual inheritance check box to ensure that only one copy of the base class will be inherited by descendants of the subclasses.

Actor Specification

An Actor Specification is similar to a Class Specification, except that the stereotype field is set to actor. However, some of the fields in the Class Specification are not applicable to actors and are therefore disabled. Refer to Class Specification for more information.

Rational Software Corporation  http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX