Use case diagrams in Software Engineering - Deep Dive

Overview - Use case diagrams

What is it?

Use case diagrams are simple visual tools that show how users interact with a system. They map out the different ways people or other systems use the software to achieve goals. Each use case represents a specific function or action the system performs for the user. This helps everyone understand what the system does from the user's perspective.

Why it matters

Use case diagrams exist to clarify and communicate the requirements of a system before building it. Without them, developers and stakeholders might misunderstand what the system should do, leading to wasted time and money. They help catch missing features early and ensure the system meets real user needs. This saves effort and improves the final product's quality.

Where it fits

Before learning use case diagrams, you should understand basic software requirements and system concepts. After mastering them, you can move on to detailed design diagrams like sequence diagrams or class diagrams. Use case diagrams are an early step in the software design process, bridging user needs and technical implementation.

Mental Model

Core Idea

Use case diagrams show who uses a system and what they want to do with it, focusing on user goals rather than technical details.

Think of it like...

Imagine a restaurant menu that shows what dishes customers can order and who can order them. The menu doesn’t explain how the kitchen cooks the food, just what customers can get. Use case diagrams are like that menu for software systems.

┌─────────────────────────────┐
│          System             │
│  ┌───────────────┐          │
│  │ Use Case 1    │◄─────┐   │
│  └───────────────┘      │   │
│  ┌───────────────┐      │   │
│  │ Use Case 2    │◄─────┘   │
│  └───────────────┘          │
└─────────────┬───────────────┘
              │
      ┌───────┴───────┐
      │    Actor      │
      │ (User/System) │
      └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Actors in Use Cases

Concept: Actors represent users or external systems that interact with the system.

Actors are the people, organizations, or other systems that use or interact with the software. They are drawn as stick figures or labeled boxes outside the system boundary. Actors show who initiates or participates in the system's functions.

Result

You can identify who will use the system and what roles they play.

Knowing actors helps focus on real users and external systems, which is essential to designing relevant features.

2

Foundation

Defining Use Cases as User Goals

Concept: Use cases describe specific goals or tasks that actors want to accomplish with the system.

Each use case is a named oval inside the system boundary. It represents a function or service the system provides to fulfill an actor's goal. For example, 'Place Order' or 'Login' are use cases. They focus on what the user wants to do, not how the system does it.

Result

You can list the main functions the system must support from the user's perspective.

Focusing on user goals rather than technical details keeps requirements clear and user-centered.

3

Intermediate

Drawing System Boundaries and Relationships

Concept: The system boundary box shows what is inside the system, and relationships connect actors to use cases.

Draw a rectangle to represent the system boundary. Place use cases inside it and actors outside. Connect actors to use cases with lines to show interaction. This visual separation clarifies what the system does and who interacts with it.

Result

You get a clear map of system scope and user interactions.

Visual boundaries help prevent scope creep by clearly defining what the system includes.

4

Intermediate

Using Include and Extend Relationships

🤔Before reading on: do you think 'include' means the same as 'extend' in use case diagrams? Commit to your answer.

Concept: Include and extend show how use cases relate by sharing or adding behavior.

'Include' means one use case always uses another as part of its process, like a shared step. 'Extend' means a use case adds optional or conditional behavior to another. These relationships help organize complex systems by reusing or customizing functions.

Result

You can model complex interactions clearly and avoid repeating steps.

Understanding these relationships improves diagram clarity and supports modular design.

5

Intermediate

Identifying Primary and Secondary Actors

🤔Before reading on: do you think all actors have equal importance in use case diagrams? Commit to your answer.

Concept: Primary actors initiate use cases, while secondary actors support or assist.

Primary actors are the main users who trigger use cases to achieve goals. Secondary actors provide services or information needed by the system but do not start the interaction. For example, a payment gateway is a secondary actor supporting an online store.

Result

You can prioritize system features based on actor roles.

Distinguishing actor roles helps focus development on key user needs first.

6

Advanced

Applying Use Case Diagrams in Agile Development

🤔Before reading on: do you think use case diagrams are only useful in traditional waterfall projects? Commit to your answer.

Concept: Use case diagrams can guide user story creation and iterative development in agile.

In agile, use case diagrams help identify user stories by breaking down use cases into smaller tasks. They provide a shared understanding for the team and stakeholders. Diagrams evolve as requirements change, supporting flexible planning and communication.

Result

You can use use case diagrams to improve collaboration and adapt to change.

Knowing how to adapt use case diagrams for agile boosts their practical value in modern projects.

7

Expert

Limitations and Misuse of Use Case Diagrams

🤔Before reading on: do you think use case diagrams alone are enough to fully specify a system? Commit to your answer.

Concept: Use case diagrams show interactions but not detailed behavior or data flow.

Use case diagrams do not capture how the system works internally or the sequence of steps. Overreliance on them can lead to missing important design details. They should be complemented with other diagrams like sequence or class diagrams for full system specification.

Result

You understand when to use use case diagrams and when to add more detailed models.

Recognizing their limits prevents incomplete designs and costly misunderstandings.

Under the Hood

Use case diagrams work by abstracting system functionality into user-centered goals and showing interactions as simple connections. Internally, they rely on a standardized notation from UML (Unified Modeling Language) that defines actors, use cases, and relationships. This abstraction hides technical complexity and focuses on communication between users and the system.

Why designed this way?

They were designed to bridge the gap between technical teams and non-technical stakeholders by using simple visuals. Early software projects struggled with unclear requirements, so use case diagrams provide a common language that anyone can understand. Alternatives like detailed flowcharts were too complex for broad communication.

┌─────────────────────────────┐
│        Use Case Diagram      │
│                             │
│  Actors       System         │
│  ┌───────┐   ┌───────────┐  │
│  │User A │──▶│ Use Case │  │
│  └───────┘   └───────────┘  │
│                             │
│  Relationships:             │
│  - Association (line)        │
│  - Include (dashed arrow)    │
│  - Extend (dashed arrow)     │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do use case diagrams show detailed system logic? Commit yes or no.

Common Belief: Use case diagrams show exactly how the system works internally.

Reality: They only show what the system does from the user's view, not internal logic or data flow.

Why it matters: Believing this leads to missing important design details and incomplete system understanding.

Quick: Are all actors in a use case diagram equally important? Commit yes or no.

Common Belief: All actors have the same role and importance in the system.

Reality: Actors have different roles; primary actors initiate use cases, secondary actors support them.

Why it matters: Ignoring actor roles can cause misprioritization of features and wasted effort.

Quick: Does 'include' mean the same as 'extend' in use case diagrams? Commit yes or no.

Common Belief: 'Include' and 'extend' are interchangeable ways to connect use cases.

Reality: 'Include' means mandatory shared behavior; 'extend' means optional or conditional additions.

Why it matters: Confusing these leads to unclear diagrams and misunderstandings about system behavior.

Quick: Are use case diagrams only useful in traditional waterfall projects? Commit yes or no.

Common Belief: Use case diagrams are outdated and only fit waterfall development.

Reality: They are useful in agile too, helping break down user stories and communicate requirements.

Why it matters: Ignoring their agile use limits communication and planning effectiveness in modern projects.

Expert Zone

1

Use case diagrams often omit non-functional requirements, which must be captured elsewhere.

2

Actors can represent external systems, not just human users, broadening the diagram's scope.

3

The choice between 'include' and 'extend' relationships affects how reusable and flexible the design is.

When NOT to use

Use case diagrams are not suitable for modeling detailed workflows, data structures, or internal system logic. For those, use sequence diagrams, activity diagrams, or class diagrams instead.

Production Patterns

In real projects, use case diagrams serve as a communication tool during requirements gathering and stakeholder meetings. They are often paired with user stories in agile and refined into detailed design diagrams during development.

Connections

User Stories

Use case diagrams help identify and organize user stories in agile development.

Understanding use cases clarifies user goals, making user stories more focused and valuable.

Sequence Diagrams

Sequence diagrams build on use case diagrams by detailing the order of interactions within a use case.

Knowing use cases first helps you understand the context for the detailed message flows in sequence diagrams.

Theater Scripts

Both use case diagrams and theater scripts describe roles (actors) and actions (scenes) to tell a story.

Recognizing this storytelling pattern helps appreciate how use case diagrams communicate system behavior through user interactions.

Common Pitfalls

#1 Confusing use case diagrams with detailed flowcharts.

Wrong approach:

Drawing every step and decision inside use cases as complex flowcharts within the diagram.

Correct approach:

Use use case diagrams to show high-level interactions and create separate flowcharts or sequence diagrams for detailed steps.

Root cause:

Misunderstanding the purpose of use case diagrams as high-level communication tools rather than detailed process maps.

#2 Treating all actors as equal without distinguishing roles.

Wrong approach:

Labeling all actors simply as 'User' without specifying primary or secondary roles.

Correct approach:

Identify and label actors clearly as primary or secondary based on their interaction with the system.

Root cause:

Lack of clarity about actor roles leads to poor prioritization and design decisions.

#3 Overusing 'extend' relationships for mandatory behavior.

Wrong approach:

Using 'extend' to connect use cases that always happen together.

Correct approach:

Use 'include' for mandatory shared behavior and reserve 'extend' for optional or conditional additions.

Root cause:

Misunderstanding the semantic difference between 'include' and 'extend' relationships.

Key Takeaways

Use case diagrams focus on who uses the system and what they want to achieve, not how the system works internally.

Actors represent users or external systems, and use cases represent their goals with the system.

System boundaries and relationships visually separate what the system does from who interacts with it.

Include and extend relationships organize shared and optional behaviors, improving diagram clarity.

Use case diagrams are valuable in both traditional and agile development but must be complemented with detailed diagrams for full system design.