Use cases and use case diagrams

The use case model is the start of functional modeling: it shows what users want to do with the system. The diagram itself is simple (stick figures, ovals, lines), but marks are lost on the exam precisely over details: mixing up include and extend, drawing the arrow the wrong way, making a step into a use case, mistaking data for an actor. A typical exam question: a paragraph scenario is given and you are told “Identify the actors and use cases and draw the use case diagram”.

Golden rules:

1. An actor is a role, outside the system. It can be a person, an external system or time.
2. A use case is a goal that gives value to the actor. Its name is verb + object: “Book Class”.
3. Include is mandatory, extend is conditional. The include arrow goes from the base to the included one, the extend arrow from the extending one to the base.
4. Generalization is a solid line with a triangle head, from the bottom to the top.

Basic elements

Actor

An actor is a role outside the system that exchanges information with it. Three points to watch on the exam:

• A role, not a person. Not “Professor Ahmet” but “Instructor”.
• External systems are actors. The payment provider, the university’s student information system.
• Time can be an actor. The “Time” actor that starts automatic jobs such as “generate a report at the end of every month”.

A primary actor is the actor that starts the use case and gets value from it. A secondary (supporting) actor is the actor from which the system gets help to do the job (e.g. Payment Service).

Use case

A use case is a complete goal that the actor accomplishes with the system and at the end of which they can say “I’m done”. Check questions:

• Does it give the actor a valuable result?
• Is it completed in a single session (in one go)?
• Is it in the actor’s language or in technical language?

Good: “Reserve Book”, “Pay Fine”, “Track Order”. Bad: “Login Screen” (a screen), “Validate Input” (a step), “Database” (a technology).

Relationships

Association

The solid line between an actor and a use case. It shows that the actor takes part in this use case. An arrowhead is not required. Optionally, multiplicity can be written.

Include

The shared behavior that several use cases need every time is extracted into a separate use case. The base use case cannot be completed without the included one.

(Book Class) - - <<include>> - -> (Verify Membership)
(Check In)   - - <<include>> - -> (Verify Membership)

Extend

Behavior added to the base use case only under a certain condition. The base use case can also be completed without the extension. The extension point can be named inside the base use case.

(Pay Reactivation Fee)
      - - <<extend>> - -> (Renew Membership)
  condition: membership ended more than 30 days ago

PITFALL · arrow directions. Include: “Book Class includes Verify Membership” → the arrow leaves Book Class. Extend: “Pay Reactivation Fee extends Renew Membership” → the arrow leaves Pay Reactivation Fee. Form the sentence, and the arrow starts at the subject.

Generalization

Actor generalization: The child actor inherits all the relationships of the parent actor. Front Desk Staff and Trainer are special cases of Staff.

Use case generalization: Special kinds of a use case. “Pay Fee” is general, “Pay by Card” and “Pay by Cash” are subtypes.

Front Desk Staff ---|>  Staff
Trainer          ---|>  Staff
(Pay by Card)    ---|>  (Pay Fee)

Here ---|> represents a solid line with a hollow triangle head.

Comparing include, extend, generalization

Worked example: the FitHub gym

Scenario: “A person becomes a member at the reception through a front desk staff member. Members renew their membership online; if the membership ended more than 30 days ago, they pay a reactivation fee. Payments are taken through an external payment service. Members reserve places in group classes and cancel their reservations. They check in at the turnstile when entering the gym. For reservation and check-in, the membership is verified to be active every time. Trainers manage the class schedule. At the end of every month the system automatically generates a monthly report and sends it to the managers. Front desk staff and trainers share common tasks as staff.”

Step 1: Find the actors. Scan the nouns, select the roles that interact with the system.

Step 2: Find the use cases. Scan the verbs.

Step 3: The diagram.

+------- FitHub Membership System ---------+
|                                          |
|  (Register Member)                       |
|  (Renew Membership)<-<<ext>>-(Pay React. |
|        |                       Fee)      |
|  (Book Class)--<<inc>>-->(Verify         |
|  (Check In)----<<inc>>--> Membership)    |
|  (Cancel Booking)                        |
|  (Manage Class Schedule)                 |
|  (Generate Monthly Report)               |
+------------------------------------------+

Associations (from outside):
 Member ......... Renew, Book, Cancel, Check In
 FrontDeskStaff . Register Member
 Trainer ........ Manage Class Schedule
 Payment Service  Renew Membership
 Time ........... Generate Monthly Report
Generalization:
 Front Desk Staff --|> Staff
 Trainer          --|> Staff

Step 4: Check.

• Is every actor connected to at least one use case? Yes. (Staff is a parent actor; if a shared use case is added, e.g. “View Member Profile”, it is connected to that.)
• Is every use case reached by an actor or linked by include/extend? Yes.
• There are 9 use cases inside the boundary. That is at the limit of readability; in a larger system it is divided into packages.

Where do use cases come from?

Use cases are derived from the functional requirements you gathered in week 5. Every functional requirement must be traceable to at least one use case (traceability). Nonfunctional requirements do not appear in the diagram; they are written in the “special requirements” part of the relevant use case description (week 7).

Common mistakes