Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system

or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system. Note, that UML 2.4 specification also describes use case diagrams as a specialization of class diagrams, and class diagrams are structure diagrams. Use case diagrams are in fact twofold - they are both behavior diagrams (because they describe behavior of the system), and they are also structure diagrams- as a special case of class diagrams where classifiers are restricted to be either actors or use cases related with association. Use case diagrams are used to specify: (external) requirements on a subject, required usages of a system - to capture what a system under construction is supposed to do; the functionality offered by a subject what system can do; requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services. Major elements of the use case diagram are shown on the picture below.

Use case diagram major elements.

You can find some examples of use case diagrams here: Business model - Airport check-in and security screening Business model - Restaurant e-Library online public access catalog use cases Point of Sales Terminal Use cases for a retail website Credit card processing system ATM use cases Hospital Management Read some FAQs - questions and answers related to use cases here - Use Case Diagrams FAQ.

Subject
The subject (of use cases) is the system under analysis or design to which a set of use cases apply. The subject could be a business or company, software system, physical system or device, or a smaller subsystem having some behavior. In UML terms, subject is a use case classifier playing the "subject" role. Use case classifier is classifier extended with the capability to own use cases. The required behavior of the subject is specified by one or more use cases, which in turn are defined according to the needs of actors. Subject is presented by a rectangle with subject name in upper corner with applicable use cases inside the rectangle and actors - outside of the system boundaries.

Books Online (subject) with applicable use cases and Web Customer actor.

Business Model Subject

Use cases could be used to model business to analyse business processes, recognize the problems being experienced, determine the opportunities to better serve customers. Subject of use cases in this case is business, enterprise, company or its division, department, team. Examples of business subjects: Department Store Airport Restaurant UML provides no standard stereotypes to model business processes but we can use custom stereotypes like business or department, if needed for clarity. Example below shows business Restaurant with business actors Customer, Advertiser and Supplier and related business use cases.

Restaurant business subject with business actors and applicable use cases

Example below shows typical misconception for the business Restaurant with business actors mistakenly including Waiter and Cashier. These are both working for the restaurant and are part of the business. They should not be shown as actors because actors are external users (customers) of the business (system).

Mistake: Restaurant business should not have Waiter and Cashier as actors

Software System Subject

System use cases describe a system that automates some business use case(s) or process. Subject in this case is software and/or hardware system, subsystem, component or device. Examples of systems: Web Site Payment System Automated Teller Machine (ATM) Point of Sale (POS) Terminal UML provides no standard stereotypes for subject (i.e. use case classifier) but UML 2.4 specification examples use the stereotypes from components: subsystem process service component

Weather Service subject stereotyped as service.

Applicability of Use Cases

Use cases visually located inside the system boundaries are use cases applicable to the subject (but not necessarily owned by the subject).

Use cases Browse Items and Buy Items are applicable to Retail Website subject

It is possible for some use cases to be applicable to multiple subjects.

Ownership of Use Cases

In UML 2.4 subject could own some or all of applicable use cases. This owning (nesting) of a use case is represented using the standard notation for nestedclassifier.

Retail Website subject owns use cases

Actor
An actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject. The term "role" is used informally as some type, group or particular facet of users that require specific services from the subject modeled with associated use cases. When an external entity interacts with the subject, it plays the role of a specific actor. That single physical entity may play several different roles, and a specific role may be played by single or multiple different instances. Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates the subject. All actors must have names according to the assumed role. Examples of actor names (user roles): Customer Web Client Student Passenger Payment System

Standard UML notation for actor is "stick man" icon with the name of the actor above or below of the icon. Actor names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should be shown in italics.
Student actor

Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for non-human actors.

Custom icon for Web Client actor

Custom icon for Bank actor

An actor may also be shown as a class rectangle with the standard keyword actor, having usual notation for class compartments, if needed.

Customer actor as Class

An actor can only have binary associations to use cases, components, and classes.

Business Actor

A business actor (introduced in Rational Unified Process (RUP) to support business modeling) represents a role played by some person or system externalto the modeled business and interacting with the business. Note, business actor is not defined in UML standard. Some typical examples of business actors are: Customer Supplier Patron Passenger Authority Bank Each business actor represents something outside of the modeled business and should be involved with at least one business use case. Business actor is represented in RUP by "stick man" icon with a line crossing its head.

Business actor Passenger

Relationships Between Actors

We can define abstract or concrete actors and specialize them using generalization relationship. Generalization between actors is rendered as a solid directed line with a large arrowhead (same as for generalization between classes).

Web Client actor is abstract superclass for Administrator, Editor and Customer

Associations Between Actors and Use Cases

Each use case specifies a unit of useful functionality that the subject provides to actors. This functionality should be initiated by an actor. Actors may be connected to use cases only by binary association relationship. An association between an actor and a use case indicates that the actor and the use case communicate with each other. An actor could be associated to one or several use cases.

Actor Customer associated with two use cases

Use case may have one or several associated actors. It may not be obvious from use case diagram which actor initiates the use case, i.e. is "primary actor". (In non-standard UML, primary actors are those using system services, and supporting actors are actors providing services to the system.)

Use case Manage Account associated with Customer and Bank actors.

When an actor has an association to a use case with a multiplicity that is greater than one at the use case end, it means that a given actor can be involved inmultiple use cases of that type. The specific nature of this multiple involvement depends on the case on hand and is not defined in the UML 2.4 specification. Thus, use case multiplicity could mean that an actor initiates multiple use cases: in parallel (concurrently), or at different points in time, or mutually exclusive in time.

Actor Bank is involved in multiple Use cases Transfer Funds.

When a use case has an association to an actor with a multiplicity that is greater than one at the actor end, it means that more than one actor instance is involved in initiating the use case. The manner in which multiple actors participate in the use case depends on the specific situation on hand and is not defined in the UML 2.4 specification. For instance, actor's multiplicity could mean that: a particular use case might require simultaneous (concurrent) action by two separate actors (e.g., in launching a nuclear missile), or it might require complementary and successive actions by the actors (e.g., one actor starting something and the other one stopping it).

Two or more Player Actors are required to initiate Play Game Use case.

Use Case
A use case is behaviored classifier which specifies behavior of a subject (system under construction or consideration) by describing a set of sequences of actions performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system. In other words, each use case describes a unit of complete and useful functionality that the subject provides to its users. This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is considered complete if after its execution the subject will be in a state in which no further inputs or actions are expected and the use case can be either initiated again or is in an error state. Each use case must have a name. Examples of use case names: Place Order Update Subscription

Transfer Funds Hire Employee Use case is usually shown as an ellipse containing the name of the use case.

User Registration use case

Name of the use case could also be placed below the ellipse.

Transfer Funds use case

If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note, that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier. Use cases have no standard keywords or stereotypes. Use case could be shown with a custom stereotype above the name. As a classifier, use case hasproperties. A list of use case properties - operations and attributes - could be shown in a compartment within the use case oval below the use case name.

Use Case User Sign-In stereotyped as authentication

Use case with extension points may be listed in a compartment of the use case with the heading extension points.

Registration Use Case with extension points Registration Help and User Agreement

A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper right-hand corner of the rectangle and with optional separate list compartments for its features.

Registration Use Case shown using the standard rectangle notation for classifiers

The detailed behavior of a use case can be described by any means and techniques intended to define behaviors, in a separate diagram or textual document such as interactions, activities, state machines, pre- and post-conditions natural language text It may also be described indirectly through a Collaboration that uses the use case and its actors as the classifiers that type its parts. Which of these techniques to use depends on the nature of the use case behavior as well as on the intended reader. These descriptions can be combined. An execution of a use case is an occurrence of emergent behavior. Every instance of a classifier realizing a use case must behave in the manner described by the use case. Use case could be rendered in the frame labeled as use case or in abbreviated form as uc. The content area of the frame could contain different kinds of UML diagrams. For example, use case could be described with activity diagram or state machine.

Use case Search Items rendered as frame with associated Activity diagram

Abstract Use Case

UML 2.4 does not mention, define or explain abstract use cases. UML 1.x specification mentioned that "the name of an abstract use case may be shown in italics" but since UML 2.0 this sentence was removed from UML specifications without any explanations.

One reason that the sentence was removed could be that because use case is a classifier, and any classifier could be abstract (with the name shown in italics), it is obvious that it should be applicable to the use cases as well. On the other hand, as the sentence was removed and UML 2.4 does not mention abstract use cases at all and does not provide even a single example of abstract use cases, it could mean that they expect all use cases to be concrete, not abstract. In this case, it would be reasonable to have this situation explained explicitly in UML specification. Assuming use case could be abstract and applying appropriate definition for the classifier, abstract use case is use case which does not have complete declaration (is incomplete) and ("typically", as UML specification says) can not be instantiated. An abstract use case is intended to be used by other use cases, e.g., as a target of generalization relationship. I hope that "the name of an abstract use case may be shown in italics" is still applicable in UML 2.4, as it was specified in UML 1.x.

Web User Authentication use case is abstract use case specialized by Login, Remember Me and Single Sign-On use cases.

When UML 2.4 specification describes include relationship between use cases, they explain that "what is left in a base use case is usually not complete", but for some reason avoiding to call it abstract use case. Generally, it should mean that including use case is always abstract.
Bank ATM Transaction use case becomes abstract use case as a result of including Customer Authentication use case.

Though UML specification avoids doing it, it is quite common to find sources that define including use cases as abstract use cases or essential use cases. While we may assume that including use cases are always abstract, included use case could probably be either abstract or concrete. Amazingly, there are some sources - that I can't agree with - providing exactly opposite explanation that including (base) use cases are "usually concrete", while included ("addition") use cases are "usually abstract". To add even more to the confusion, yet other sources define abstract use cases as use cases described at the abstract level (business use cases, sometimes called essential use cases) as opposed to the system use cases.

Business Use Case

Though support for business modeling is declared as a goal of UML, UML specification provides no notion for business use cases. Business use cases were introduced in Rational Unified Process (RUP) to support Business Modeling to represent business function, process, or activity performed in the modeled business. Business use case should produce a result of observable value to a business actor. A business use case defines what happens in the business when the use case is requested by business actor, it describes complete workflow or business process that produces results required or in need of business actor.

Business use case is represented in RUP with use case oval and a line crossing it as shown below.

Business use case Individual Check-In

There are two alternative approaches to name business use cases. Use case could be named from the point of view of business actor - expressing goal or need of the actor - or from the point of view of business itself - by giving names to business processes or services provided to business actors.

Business use case - Candidate Applies for Job

The Apply for Job business use case expresses the goal of the Candidate business actor. Alternative name from business view would be Hire Staff.

Business use case - Business Serves Meal to Customer

In this case, business use case is named according to the business process or service business Serves Meal to Customer. Alternative name from actor view would be Have Meal. You can see other differences between these two approaches by comparing examples of business use case diagrams for Restaurant.

Relationships Between Use Cases

Use cases could be organized using following relationships: generalization association extend include

Generalization Between Use Cases

Generalization between use cases is similar to generalization between classes child use case inherits properties and behavior of the parent use case and may override the behavior of the parent. Generalization is shown as a solid directed line with a large hollow triangle arrowhead, the same as for generalization between classifiers, directed from the more specific use case to the general use case.
Web User Authentication use case is abstract use case specialized by Login, Remember Me and Single Sign-On use cases.

Association Between Use Cases

Use cases can only be involved in binary associations.

Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the system.

Extend Relationship
Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case. Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended. The extension takes place at one or more extension points defined in the extended use case. Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword extend.

Registration use case is meaningful on its own. It could be extended with optional Get Help On Registration use case

The condition of the extend relationship as well as the references to the extension points are optionally shown in a comment note attached to the corresponding extend relationship.

Registration use case is conditionally extended by Get Help On Registration use case in extension point Registration Help

Extension Point
An extension point is a feature of a use case which identifies (references) a point in the behavior of the use case where that behavior can be extended by some other (extending) use case, as specified by extend relationship. Extension points may be shown in a compartment of the use case oval symbol under the heading extension points. Each extension point must have a name, unique within a use case. Extension points are shown as a text string according to the syntax: extension point ::= name [: explanation ] The optional explanation is some description usually given as informal text. It could be in other forms, such as the name of a state in a state machine, an activity in an activity diagram, some precondition or postcondition.
Registration use case with extension points Registration Help and User Agreement

Extension points may be shown in a compartment of the use case rectangle with ellipse icon under the heading extension points.
Extension points of the Registration use case, shown using the rectangle notation

Include Relationship
An include relationship is a directed relationship between two use cases when required, not optional behavior of the included use case is inserted into the behavior of the including (base) use case. Including use case depends on the addition of the included use case. Including use cases are usually not complete by themselves and require the included use cases. For whatever reasons, UML 2.4 does not refer to those asabstract use cases which seems very appropriate. Many other sources define abstract use case as including use case, while in fact it has to be expressed the other way around: including use case is abstract use case. See discussion of the definition of abstract use cases. The include relationship could be used: when there are common parts of the behavior of two or more use cases, to simplify large use case by splitting it into several use cases. Included use cases are required, not optional for the inclusion. Execution of the included use case is analogous to a subroutine call or macro command in programming. All of the behavior of the included use case is executed at a single location in the including use case before execution of the including use case is resumed. Note, while UML 2.4 defines extension points for the extend relationship, there are no "inclusion points" to specify location or condition of inclusion for theinclude. Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case. The arrow is labeled with the keyword include. When two or more use cases have some common behavior, this common part could be extracted into a separate use case to be included back by the use cases with include.

Both Deposit Funds and Withdraw Cash use cases require (include) Customer Authentication use case.

Large and complex use case could be simplified by splitting it into several use cases each describing some logical unit of behavior. Note, that including use case becomes incomplete by itself and requires included use cases to be complete.

Checkout use case includes (possibly several) Scan Item, Calclulate Total and Tax, and Payment use cases

Use Case Relationships Compared

This site received many requests related to which use case relationship should be used in which situation. I combined several key points from UML 2.4 Specification into the table below. Also, take a look at related discussion in the next paragraph.

Generalization

Extend

Base use case could be abstract use case(incomplete) or complete (concrete).

Base use case is complete (concrete) by itself, defined independently.

Base

Specialized use case is required, not optional, if base Extending use case is optional, supplementary. use case is abstract. No explicit location to use specialization. No explicit condition to use specialization. Has at least one explicit extension location. Could have optional extension condition.

Inclu

No ex locati

No ex

Missing Use Case Relationship

I was baffled while creating some use case diagrams and answering some questions of this website users, all with a similar problem and no obvious solution usingUML 2.4. One quite seemingly simple but insolvable example is to specify relationships between Payment, Payment by Credit, Payment by Cash, etc. use cases when we want to allow customers to pay partially by cash, partially by credit, etc. This is quite common situation for POS terminal checkout in supermarkets. (Another similar example is Plan Trip and Find Flight, Find Hotel, Find Car, etc. where user might want to search not just for one but for several things at a time.) Though use case generalization seems natural for Payment, Payment by Credit, Payment by Check, etc., but we can't use it because it suggests using only one specific form of payment at a time. Extend seems appropriate because it has extension points with extension conditions, but we can't use it because the base use case Payment must be complete by itself, which is obviously not the case that we have.

Include seems fine because the base use case Payment is not complete by iself and all different kinds of payments supplement it, but we can't use it because for include relationship included case is not optional but required (and there is no inclusion condition), which means that customer will have to pay using all methods of payment which is dead wrong. My hope is that they will update the include to allow inclusion conditions and locations similar way as it was done for extend, or at least will provide some diagram example for the situation described above in some of the next releases of UML specification.

Search

Home Use Case Diagrams Use Case Diagrams Reference Use Case Diagrams Examples Use Case Diagrams FAQ UML Index

Use Case Diagrams Reference

Notation Subject
Books Online (subject) with applicable use cases and Web Customer actor.

Descrip

The subject (of use cases) is the system under design or con could be a physical system, software program, or smaller elem or even class. Subject is presented by a rectangle with subject name in uppe and actors - outside of the system boundaries.

Weather Service subject stereotyped as service.

Standard UML stereotypes and keywords for the subject are subsystem process service component

Applicability of Use Cases

Use cases visually located inside the system boundaries are th necessarily owned by the subject). Use cases Browse Items and Buy Items are applicable to Retail Website subject.

Ownership of Use Cases

Retail Website subject owns use cases.

The nesting (ownership) of a use case by a classifier is repres

Actor

Standard UML icon for actor is "stick man" icon with the nam

Student actor.

should follow the capitalization and punctuation guidelines fo italics. All actors must have names. Custom icons that convey the kind of actor may also be used non-human actors.

Custom icon for Web Client actor. Custom icon for Bank actor.

Business actor Passenger.

A business actor (introduced in Rational Unified Process to some person or system external to the modeled business. Bus Business actor is shown as "stick man" icon with a line cross

Customer actor as Class.

An actor may also be shown as a class rectangle with the keyw compartments, if needed.

Generalization between actors

Generalization between actors is rendered as a solid directed generalization between classes). Web Client actor is abstract superclass for Administrator, Editor and Customer.

Use Case
User Registration Use Case. Transfer Funds Use Case. Business use case Individual Check-In.

Every use case must have a name. Use case is shown as an ell A use case could be shown as an ellipse with the name of the

Business use case was introduced in Rational Unified Proce function, process, or activity performed in the modeled busin Business use case is represented in RUP with use case oval ic

Use Case User Sign-In stereotyped as authentication Registration Use Case with extension points Registration Help and User Agreement. Registration Use Case shown using the standard rectangle notation for classifiers.

An optional stereotype keyword may be placed above the nam included below the name in a compartment.

Use case with extension points may be listed in a compartme

A use case can also be shown using the standard rectangle not righthand corner of the rectangle and with optional separate li

Use case could be rendered in the frame labeled as use case o The content area of the frame could contain different kinds of with activity diagram or state machine. Use case Search Items rendered as frame with associatedActivity diagram.

Generalization between use cases

Web User Authentication use case is abstract use casespecialized by Login, Remember Me and Single Sign-On use cases.

Generalization between use cases is similar to generalization behavior of the parent use case and may override the behavior It is rendered as a solid directed line with a large arrowhead, t

Extend

Registration use case is meaningful on it's own, and it could be extended with optional Get Help On Registration use case.

Extend is a directed relationship that specifies how and whe (optional) extending use case can be inserted into the behavio Extended use case is meaningful on its own, it is independen defines optional behavior that is not necessarily meaningful b Extend relationship between use cases is shown by a dashed a case to the extended (base) use case. The arrow is labeled wi

The condition of the extend relationship as well as the referen a comment note attached to the corresponding extend relation Registration use case is conditionally extended by Get Help On Registration use case in extension point Registration Help.

Extension Point

Registration Use Case with extension points Registration Help and User Agreement.

An extension point is a feature of a use case which identifies that behavior can be extended by some other (extending) use c Extension points may be shown in a compartment of the use c extension point must have a name, unique within a use case. E syntax: extension point ::= name [: explanation ]

Extension points of the Registration use case shown using the rectangle notation.

Extension points may be shown in a compartment of the use c heading extension points.

Include

Both Deposit Funds and Withdraw Cash use cases require (include) Customer Authentication use case.

An include relationship is a directed relationship between tw the included use case is inserted into the behavior of the inclu The include relationship is analogous to a subroutine call or m when there are common parts of the behavior of two to simplify large use case by splitting it into several u An include relationship between use cases is shown by a dash to the included use case. The arrow is labeled with the keywo

Large and complex use case could be simplified by splitting it of behavior. Note, that including use case becomes incomplet Checkout use case includes (possibly several) Scan Item, Calclulate Total and Tax, and Payment use cases

Association
Actor Customer associated with two use cases.

An association between an actor and a use case indicates that An actor could be associated to one or several use cases.

Use case Manage Account associated with Customer and Bank actors.

Use case may have one or several associated actors. It may not be obvious from use case diagram which actor init standard UML, primary actors are those using system servic the system.)

Actor Bank is involved in multiple Use cases Transfer Funds.

When an actor has an association to a use case with a multip that a given actor can be involved in multiple use cases of tha is not defined in the UML 2.2. Use case multiplicity could mean that an actor initiates multip in parallel (concurrently), or at different points in time, or

mutually exclusive in time.

When a use case has an association to an actor with a multipl that more than one actor instance is involved in initiating th actors participate in the use case is not defined in the UML 2 For instance, actor's multiplicity could mean that: Two or more Player Actors are required to initiate Play GameUse a particular use case might require simultaneous (co a nuclear missile), or case. it might require complementary and successive actio other one stopping it).

Noticed some spelling error? Select the text with your mouse and press Ctrl + Enter.

0 Comments
o
Disqus Like Dislike

2 people liked this.

Add New Comment

Image Post as

Showing 0 comments
Sort by
blog comments powered by DISQUS

Subscribe by email

Subscribe by RSS

This document describes UML 2.4 and is based on OMG Unified Modeling Language (OMG UML) 2.4 specification [UML 2.4 - Superstructure]. All UML diagrams were created in Microsoft Visio 2007, 2010 using UML 2.2 stencils by Pavel Hruby.

Images of UML elements and diagrams may be used without written permission for any personal, educational, or nonprofit use provided this website is credited. Any commercial or other use requires prior written permission. You can send your comments and suggestions to web master at webmaster@uml-diagrams.org.