ANSWER

At the most basic level, the Use Case Diagram is a UML (Unified Modeling Language) diagram which shows in visual form (aka diagram) the interactions between a system’s users and the functions supported by the system.

Before we expand the definition, let’s focus on the key visual elements of a use case diagram:

• Use Cases - A use case, depicted by an oval shape, represents a given system function or action which the user (actor) can initiate within the system.  

  • The use case diagram is a functional diagram (not a technical diagram therefore, a use case represents a piece of functionality (aka “the what”) and not system design (aka “the how”).  

  • Use cases can also be thought of as goals aka what a user may want to do with the system.  Example use case names: “Add New Customer”, “Generate Monthly Report”, “Withdraw Money”.

  • Did you notice how use cases are named? They are verb phrases.  Very important!

• Actors - These are entities which interact with the system.  While the use case actors are visually represented as a human stick figure, the use case actors do not merely represent a human user but anything which interacts with the system and is outside the boundary of the system.

  • Actors could be entities which invoke use cases or trigger use cases.  Example: a “Bank Customer” actor may initiate the “Withdraw Money” use case.

  • Actors can also be other systems with which the system being represented by the boundary interacts with.  Example: a “Purchase Baseball Ticket” use case for a third party seller may interact with the “MLB System” actor to record the ticket sale.

• Associations - The association, visually depicted as a solid line with an arrow at one end, represents the interaction between an actor and a use case.  The arrow points away from the object which initiates the interactions.

  • Example: the association between the “Bank Customer” actor and the “Withdraw Money” use case points to the use case because it is initiated by the “Bank Customer”.

  • Example: the association between the “Purchase Baseball Ticket” use case and the “MLB System” actor points to the “MLB System” because the interaction is initiated by the “Purchase Baseball Ticket” use case.

• Relationships - Well… relationships are really a type of association - they are standard UML relationships and are used to visually display a relationship between two use cases.  There are three types of relationships in a use case diagram:

  • Generalization Relationship - shows that one use case (or actor)  is based on another aka it indicates that the child receives all the attributes and characteristics of the parent.  Some like to refer to the generalization relationship as inheritance.

  • Include Relationship - is a relationship between two use cases in which one use case uses or includes the functionality of another.  The include relationship is handy when the same piece of functionality is common among two or more use cases.  In this case, a common use case can be depicted and “included” or shown as being used by other use cases.

  • Extend Relationship - is also a relationship between two use cases where the functionality of the extension use case is not essential to and is optional for the use case being extended.

• System Boundary - The system boundary is a rectangle which contains inside the use cases which are part of the system or subsystem being depicted with all the actors residing outside of the system boundary.  A good practice is to place the name of the system, or the area being studied, at the top of the system boundary - just inside the boundary.

So… What is a Use Case Diagram?   Let’s try to refine the definition first given:

A Use Case Diagram is a UML (Unified Modeling Language) diagram which shows in visual form (aka diagram):

• the interactions between a system’s functions and external actors (human or not) which trigger functionality or are needed to fulfill a system functionality,

• the relationships between various actors where there is a need to show that some actors are similar to others, and

• the relationship between various system capabilities depicting when a given functionality is related to another in some way: inherited, re-used, optional, etc.

What do you think a Use Case Diagram is?