The Use Case Chronicles – Part 2: Unveiling Use Case Structure

In the second part of The Use Case Chronicles, I continue to discuss use cases. In the first part, you can read about what a use case is, who invented it, where you can use it, and in what format. Here, let’s discover the structure of use cases.

Both text and graphical views are based on the same concepts. In order to explore elements and connections of use cases, let’s first focus on the graphical view. It has less information and details and it is more intuitive. Afterwards, let’s consider additional elements and templates for the text view.

A UML Use Case Diagram serves as a basis for the graphical view here. It may be expanded depending on the company and author; however, here, I will be using a traditional UML version.

Base Elements

1. Use case

The main content of the diagram. A use case specifies the behavior that a system or a part of a system performs to get a valuable result for a user. It can be some function, process, or action, including variants, or a set of them.

Graphically, a use case is rendered as an ellipse.

Every use case must have a name that distinguishes it from other use cases. Name is usually a short active verb phrase naming some behavior: perform a transaction, process a bill, display a movie, order a ticket, etc.

2. Subject/system

A system (or a part of a system) that is described and to which use cases apply.

Typically, a system is rendered as a frame around the use cases, with a name at the top.

Sometimes, this element may not be shown, but anyway, you have to understand, what system you are describing.

3. Actors

An actor represents somebody or something that uses the system in different scenarios or that is required for different cases. Typically, an actor represents a role that a human plays with a system, but it also can be a hardware device or even another system.

Usually, actors are rendered as stick figures, but you can also use other symbols to visually indicate different actors. For example, a system might be rendered as a rectangle, a database as a figure, and human actors as stick figures.

Every actor must have a name. Typically, the name of an actor is a noun: client, enterprise, customer, database, etc.

4. Association

Each actor should be connected to some use cases; this connection is called an association. An association indicates that the actor and the system interact with one another in the context of the use case.

If there are several actors associated with a use case, that means all of them participate in this use case (AND semantics).

An association is rendered as a solid line (or a solid arrow).

📝 Example

Let’s model base elements for a mobile application for food ordering:

1. A system is a mobile application

   
   

2. Who can interact with an app (who are the actors)? Clients (place orders), restaurants (place their menus), couriers (deliver orders), etc. For an example, let’s consider only a client.

   
   

3. How a client can use the app? Let's highlight 4 main use cases:

   • choose the restaurant

   • choose dishes

   • place an order

   • track an order

     
     

4. An actor can represent also a role of another system. For example, in the app, there is a database that contains lists of orders, restaurants, and their dishes. DataBase is an actor too.

   
   

Here is a diagram:

Relationships

In addition to the association – the actor ↔ use case connection, there are relations between use cases use case ↔ use case and between actors actor ↔ actor. There are three types of relationships that are applicable both for use case ↔ use case and actor ↔ actor: extension, inclusion, and generalization.

All relations between cases are rendered inside a frame representing a system.

Below are examples and descriptions of each relationship considered for use cases, but keep in mind that all the same relationships are applicable to actors.

1. Extend

The base use case may stand alone, but its behavior may be extended by the behavior of another use case. The extended relationship can model what the user may see as optional system behavior.

View: dotted arrow with the caption extends in the direction:

case_extension → base_use_case

2. Include

The base use case explicitly incorporates the behavior of another use case. That relation shows reusable functions; instead of describing the same flow several times, you can put common behavior in a use case (like a subprocess).

View: dotted arrow with the caption include in the direction:

included_use_case → base_use_case

3. Generalization

There are the parent cases and children cases. The child use case inherits the behavior and meaning of the parent use case, but the child may add to or override the behavior of its parent. In other words, you can create a new case (child) based on another one (parent).

View: A solid arrow with an empty tip in the direction:

case_child → case_parent

📝 Example

Let’s expand the model for a mobile application for food ordering.

1. There is a use case "Place an order." If a user wants to place an order, he/she needs to confirm it and pay for it. These are use cases too, but they are parts of the bigger use case, they are included in placing an order.

2. Now, let’s look at “Choose a restaurant.”Basically, restaurant selection means searing through a list of restaurants. An app can have a feature that suggests a restaurant to a user, making a search more convenient and personalized. That feature is a use case too, and it extends the base case.

3. Last, but not least, the “Pay for an order” case. Payment may be realized in different ways (bank or PayPal), which are use cases too. Some way of payment inherits the meaning of a “Pay for an order” case but overrides the behavior–generalization relationship.

   
   

   Difference from other relationships:

   • they are not sub-processes of a payment, but types (not include)
   • they cannot be optionally included or not included in the payment (not extend)

Additional Elements for Text Representation

I mentioned above that a text view is more suitable for a detailed description. It is easier to place additional details through a table or text, so the following elements are usually used in text-based templates.

Depending on the template, any useful information can be added to the use case description, but typically authors suggest including the following elements:

1. Preconditions

Preconditions define what must happen before the system can begin executing the use case. Preconditions can describe both actors and the system states, but they don’t describe a user’s intent.

For example, the “place an order” button will not appear until the user adds at least one dish to the cart. Another example: to make a transfer in an online bank, the user must log in first.

If the system knows from the start that it cannot complete the use case successfully, but proceeds anyway, some errors might occur. Checking preconditions before executing the use case can prevent these errors.

2. Trigger

That is the starting point for executing the use case, something that provokes it.

When the system detects the trigger event, it checks preconditions (the trigger event itself is not one of the preconditions) and (if all preconditions are true) starts executing the use case.

For example, placing an order begins by clicking the "Place an order" button.

3. Goal

The result of a use case is the result of an actor's interaction with the system. What should happen or what will guarantee success when the use cases are executed correctly?

4. Basic flow as a more detailed description of a Use case

That is a normal flow for the use case when everything works fine and without errors. It’s also called the main flow, basic flow, normal course, primary scenario, main success scenario, sunny-day scenario, happy path, and so on.

Basic flow describes events that happen to lead the user from a trigger to a result.

The reason it’s not the same thing as a use case is that, besides the basic flow, there can be other scenarios within the same use case (alternative flows).

5. Alternative flows

Alternative flows represent less common or lower-priority flows in a use case, the most likely deviations from the main scenario. The normal flow might at some point branch off into an alternative flow and might (or might not) rejoin the normal flow later. Quite frequently, alternative flows describe the system’s possible reaction to various errors.

To write an alternative flow, you need to check every step of the basic flow and ask yourself the question, “What happens if...”

For example, what happens if the website crashes while a user is placing an order? What happens if the client adds all products to the cart in an online store and closes the app?

📝 Example

Let's extend the mobile application for the food ordering model, and describe one use case as a table with new elements.

Conclusion

This concludes the second part of the Use Case Chronicles. The third part will focus on the templates and tips for creating use cases.