Use case diagram

From Wikipedia, the free encyclopedia

In the Unified Modeling Language, a use case diagram is a sub class of behavioral diagrams.

The UML defines a graphical notation for representing use cases called the Use case model. UML does not define standards for the written format to describe use cases, and thus many people have the misapprehension that this graphical notation defines the nature of a use case; however, a graphical notation can only give the simplest overview of a use case or set of use cases. Use case diagrams are often confused with use cases. While the two concepts are related, use cases are far more detailed than use case diagrams.

While SysML uses the same notation as UML for use cases, system engineers model at the system or systems-of-systems level.

Contents 1 UML Use Case Diagram 1.1 Use Case Relationships 1.1.1 Include 1.1.2 Extend 1.1.3 Generalization 2 External links

[edit] UML Use Case Diagram

OMG's UML standard defines a graphical notation for diagramming use cases, but no format for describing use cases. Many people suffer under the misapprehension that a use case is its graphical notation (or is its description). While the graphical notation and descriptions are important, they are documentation of the use case -- a purpose that the actor can use the system for.

The true value of a use case lies in two areas:

• The written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.

• 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.

It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance.

The diagram on the right 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 modelled, 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. However, note that actors are a form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person.

[edit] Use Case Relationships

Three major relationships among use cases are supported by the UML standard, which describes graphical notation for these relationships.

[edit] 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.

[edit] 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, or in accommodating new requirements during system maintenance and extension.

[edit] 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 with same as except details in the specialized cases. Another concept is Depends on.

[edit] External links

• Creating Use Case Diagrams shows a common mistake about use case extension
• Introduction to Use Cases