Use case diagrams in Software Engineering - Full Explanation

Introduction

When building software, it can be hard to understand what users need and how they will interact with the system. Use case diagrams help by showing these interactions clearly, making it easier to design and communicate the system's functions.

Explanation

Actors

Actors represent people or external systems that interact with the software. They show who uses the system or who the system communicates with. Actors help identify the roles involved in the system's operations.

Actors define the users or external systems interacting with the software.

Use Cases

Use cases describe specific actions or services the system provides to actors. Each use case represents a goal or task that an actor wants to achieve using the system. They help clarify what the system should do from the user's perspective.

Use cases capture the goals or tasks users want to accomplish with the system.

Relationships

Relationships connect actors and use cases to show interactions. Common types include associations (who uses what), includes (shared steps between use cases), and extends (optional or conditional steps). These links explain how parts of the system work together.

Relationships illustrate how actors and use cases interact and depend on each other.

System Boundary

The system boundary is a box that encloses all use cases, showing what is inside the system and what is outside. It helps separate the system's responsibilities from the external environment. This boundary clarifies the scope of the system.

The system boundary defines what functions belong to the system and what lies outside.

Real World Analogy

Imagine planning a party where guests (actors) want to do things like eat, dance, or chat (use cases). The party organizer draws a map showing who does what and how activities connect, helping everyone understand the plan clearly.

Actors → Guests at the party who participate in activities

Use Cases → Activities like eating, dancing, or chatting that guests want to do

Relationships → Connections showing which guests join which activities and how activities relate

System Boundary → The party area that contains all planned activities, separating it from outside

Diagram

Diagram

┌─────────────────────────────┐
│         System Boundary      │
│  ┌───────────────┐          │
│  │ Use Case 1    │◄─────┐   │
│  └───────────────┘      │   │
│  ┌───────────────┐      │   │
│  │ Use Case 2    │◄─────┘   │
│  └───────────────┘          │
│                             │
│  Actor A ──────────────►     │
│  Actor B ──────┐             │
│                └─────────►   │
└─────────────────────────────┘

This diagram shows actors outside the system boundary interacting with use cases inside the system.

Key Facts

Actor → An entity outside the system that interacts with it, such as a user or another system.

Use Case → A specific function or goal that an actor wants to achieve using the system.

Association → A relationship showing which actors participate in which use cases.

Include Relationship → A use case that is always called as part of another use case.

Extend Relationship → A use case that adds optional or conditional behavior to another use case.

System Boundary → A box that defines the scope of the system by enclosing its use cases.

Common Confusions

Actors are often mistaken for users only.

Actors are often mistaken for users only. Actors can be any external entity interacting with the system, including other systems or devices, not just human users.

Use cases are thought to describe how the system works internally.

Use cases are thought to describe how the system works internally. Use cases focus on what the system does for actors, not the internal implementation details.

The system boundary is sometimes ignored or misunderstood as a physical boundary.

The system boundary is sometimes ignored or misunderstood as a physical boundary. The system boundary is a conceptual box that defines what is inside the system's scope, not a physical or hardware boundary.

Summary

Use case diagrams help visualize how users and external systems interact with software by showing actors and their goals.

Actors represent who interacts with the system, while use cases represent what the system does for them.

Relationships and system boundaries clarify how parts connect and what the system includes.

Practice

1. What is the main purpose of a use case diagram in software engineering?

easy

A. To test the software performance

B. To design the database schema

C. To write the program code

D. To show users and their interactions with system functions

Solution

1. Step 1: Understand the role of use case diagrams

   Use case diagrams visually represent how users (actors) interact with the system's functions (use cases).

2. Step 2: Compare with other software tasks

   Designing databases, coding, and testing are different activities not shown by use case diagrams.

3. Final Answer:

   To show users and their interactions with system functions -> Option D

4. Quick Check:

   Use case diagrams = show actors and interactions [OK]

Hint: Use case diagrams focus on users and their actions [OK]

Common Mistakes:

• Confusing use case diagrams with database design
• Thinking use case diagrams show code details
• Assuming use case diagrams test software

2. Which of the following is the correct symbol for an actor in a use case diagram?

easy

A. A stick figure

B. A rectangle

C. An oval

D. A diamond

Solution

1. Step 1: Identify actor symbol in use case diagrams

   Actors are represented by stick figures to symbolize users or external systems.

2. Step 2: Recognize other symbols

   Ovals represent use cases, rectangles and diamonds are not used for actors.

3. Final Answer:

   A stick figure -> Option A

4. Quick Check:

   Actor symbol = stick figure [OK]

Hint: Actors are stick figures in use case diagrams [OK]

Common Mistakes:

• Confusing actors with use cases (ovals)
• Choosing rectangles or diamonds for actors
• Not recognizing standard UML symbols

3. Consider a use case diagram with an actor "Customer" connected to two use cases: "Place Order" and "Track Order". What does this connection represent?

medium

A. Customer is a system component

B. Customer can perform both placing and tracking orders

C. Use cases depend on each other

D. Customer is a database entity

Solution

1. Step 1: Understand actor-use case connections

   Lines between an actor and use cases show the actor can perform those actions.

2. Step 2: Interpret the given connections

   Customer connected to "Place Order" and "Track Order" means the customer can do both activities.

3. Final Answer:

   Customer can perform both placing and tracking orders -> Option B

4. Quick Check:

   Actor connected to use cases = actor performs those actions [OK]

Hint: Lines show actor's possible actions [OK]

Common Mistakes:

• Thinking actors are system parts
• Assuming use cases depend on each other
• Confusing actors with database entities

4. A use case diagram shows an actor connected to a use case with a dashed arrow labeled "<<include>>". What is the likely issue if the arrow is drawn as a solid line instead?

medium

A. The diagram incorrectly shows a direct association instead of an include relationship

B. The actor symbol is wrong

C. The use case should be a rectangle

D. The diagram is missing actors

Solution

1. Step 1: Understand <<include>> notation

   The <<include>> relationship is shown with a dashed arrow from one use case to another, not from actor to use case.

2. Step 2: Identify the error in arrow style

   A solid line from actor to use case shows direct association, not an include relationship, so the diagram is incorrect.

3. Final Answer:

   The diagram incorrectly shows a direct association instead of an include relationship -> Option A

4. Quick Check:

   Include = dashed arrow between use cases, not solid actor line [OK]

Hint: <<include>> uses dashed arrows between use cases only [OK]

Common Mistakes:

• Drawing solid lines for <<include>>
• Confusing actor symbols with use case symbols
• Misplacing <<include>> arrows from actors

5. You want to model a system where a "User" can either "Login" or "Register" before accessing "Dashboard". Which use case diagram structure correctly shows that "Dashboard" use case requires either "Login" or "Register" first?

hard

A. "Login" and "Register" use cases extend "Dashboard" use case

B. "Dashboard" use case extends "Login" and "Register" use cases

C. "Dashboard" use case includes both "Login" and "Register" use cases

D. Login" and "Register" use cases are actors

Solution

1. Step 1: Understand include vs extend relationships

   Include means mandatory sub-function; extend means optional or conditional addition.

2. Step 2: Model login/register before dashboard

   Since "Dashboard" requires either "Login" or "Register" first, "Dashboard" use case includes both "Login" and "Register" use cases to show mandatory preconditions.

3. Final Answer:

   "Dashboard" use case includes both "Login" and "Register" use cases -> Option C

4. Quick Check:

   Include = mandatory use case inclusion [OK]

Hint: Use include for mandatory preconditions before main use case [OK]

Common Mistakes:

• Using extend instead of include for mandatory steps
• Confusing actors with use cases
• Reversing direction of include/extend arrows