Use case diagram

A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML) and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for which actors. Roles of the actors in the system can be depicted.

Use Case Diagrams

Use Case diagrams are formally included in two modeling languages defined by the OMG. Both the UML and SysML standards define a graphical notation for modeling use cases with diagrams. One complaint about the standards has been that they do not define a format for describing these use cases. Generally, both graphical notation and descriptions are important as they document the use case, showing the purpose for which an actor uses a system.

The use case diagram shows the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

This diagram describes the functionality of a simplistic "Restaurant System". Use cases are represented by ovals and the actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modeled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

Actor Generalization

The only relationship allowed between actors on a use case diagram is generalization. This is useful in defining overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor.

Use Case Relationships

Three (3) relationships among use cases are supported by the UML standard, which describes graphical notation for these relationships and created by boot.

Include

In one form of interaction, a given use case may "include" another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "«include»". This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values.

Extend

In another form of interaction, a given use case (the extension) may "extend" another. This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label "«extend»". This can be useful for dealing with special cases (when A extends B, A is a special case of B), or in accommodating new requirements during system maintenance and extension.

Modelers use the «extend» relationship to indicate use cases that are "optional" to the base use case. Depending on the modeler's approach "optional" may mean "potentially not executed with the base use case" or it may mean "not required to achieve the base use case goal."

Generalization

In the third form of relationship among use cases, a "generalization/specialization" relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal "same as except" details in the specialized cases.

External links

* [http://www.developer.com/design/article.php/2109801 Creating Use Case Diagrams shows a common mistake about use case extension]
* [http://www.parlezuml.com/tutorials/usecases.htm Introduction to Use Cases & Use Case Diagrams]
* [http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html UML Use Case Diagrams: Tips]