{"title":"Use Case Diagram","description":null,"content":"Imagine you’ve been asked to design a new software system—say, an online food delivery app. Before you dive into writing classes, functions, or database schemas, the first question is:\n\n**\"What exactly should this system do?\"**\n\nYou need to understand the problem from the user’s point of view.\n\nThat’s where **Use Case Diagrams** come in.\n\nIn this chapter, we will explore:\n\n- What a Use Case Diagram is?\n- Building Blocks of a Use Case Diagram\n- How to Draw a Use Case Diagram (Step-by-Step)\n\n---\n\n# 1. What is a Use Case Diagram?\n\nA **use case diagram** is a behavioral diagram from UML that shows the interactions between external entities (called actors) and the functionality a system provides (called use cases). \n\nThink of it as a bird's-eye map of your system's capabilities, drawn from the user's perspective rather than the developer's.\n\nIt answers one fundamental question: **\"Who can do what with this system?\"**\n\nNotice what it does not answer. It doesn't explain how a feature is implemented, what classes are involved, or what the database schema looks like. A use case diagram deliberately stays at the requirements level. It captures scope and user goals, nothing more.\n\nUse Case Diagrams are typically used in the **early phases** of software development right after the requirements are gathered and before detailed design begins.\n\n\n> **TIP**\n>\n> In LLD interviews, you don't always need to draw a formal use case diagram. But spending some time listing actors and use cases before diving into class design shows structured thinking and saves you time during design and implementation phase.\n\n\n---\n\n# 2. Building Blocks of a Use Case Diagram\n\nA use case diagram has four building blocks: actors, use cases, the system boundary, and relationships. Each one is simple on its own, but combining them gives you a powerful tool for capturing requirements.\n\nLet’s explore each of them in detail.\n\n## 1. **Actors**\n\nAn **actor** is anything that interacts with the system from outside. Most commonly actors are people (a customer, an admin, a driver), but they can also be external systems (a payment gateway, a notification service, a third-party API).\n\nActors are drawn as **stick figures** along with their label.\n\n\n\n\n\nThere are two types of actors, and the distinction matters.\n\n**Primary actors** initiate interactions with the system. They have a goal they want to achieve. A customer who wants to book a ticket is a primary actor. A rider who wants to request a ride is a primary actor. Primary actors are typically drawn on the left side of the diagram.\n\n**Secondary actors** are called upon by the system to help fulfill a use case, but they don't initiate the interaction. A payment gateway doesn't decide to process a payment on its own; the system calls it during checkout. Secondary actors are typically drawn on the right side.\n\n## 2. **Use Cases**\n\nA **use case** is a specific goal or function that the system provides to an actor. It represents a complete interaction, something that starts, does something meaningful, and ends with a result.\n\nUse cases are drawn as **ovals** with a descriptive name inside.\n\n\n\n\n\nGood use cases follow three rules:\n\n- **Start with a verb.** \"Book Ticket\" not \"Ticket Booking.\" The verb makes the action clear.\n- **Represent a complete goal.** \"Book Ticket\" is a complete goal. \"Enter Credit Card Number\" is a single step within a goal, too granular for a use case diagram.\n- **Deliver a meaningful result.** After \"Book Ticket\" completes, the actor has a confirmed booking. That's a meaningful outcome.\n\n## 3. **System Boundary**\n\nThe **system boundary** is a rectangle that encloses all the use cases. It visually defines what's inside your system and what's outside. The system name is written at the top of the rectangle.\n\nActors sit outside the boundary (they're external to the system). Use cases sit inside (they're functionality your system provides). \n\n\n\n\n\n## 4. **Relationships**\n\nRelationships are the lines connecting actors to use cases, and use cases to each other. There are four types.\n\n#### a. **Association**\n\nAn **association** is a **solid line** connecting an actor to a use case. It means \"this actor participates in this use case.\" It's the most basic relationship and the one you'll draw most often.\n\n\n\n\n\n#### b. **Include**\n\nAn include relationship means one use case always triggers another as a mandatory part of its execution. The base use case cannot complete without the included use case running.\n\n\n\n\n\n\"Checkout\" includes \"Validate Payment.\" Every single time someone does a checkout, payment processing happens. There's no purchase without payment. The dashed arrow with the label `<>` points from the base use case to the included use case.\n\n#### c. **Extend**\n\nAn extend relationship means one use case optionally adds behavior to another under certain conditions. The base use case works perfectly fine on its own; the extending use case just enhances it sometimes.\n\n**Notation**: Dashed arrow with label `<>`\n\n\n\n\n\n\"Apply Coupon\" extends \"Book Ticket.\" A customer can book a ticket without applying a coupon. But if they have a coupon, they can optionally apply it during booking. The dashed arrow points from the extending use case back to the base use case.\n\n#### d. **Generalization**\n\n**Generalization** shows **inheritance** between actors or between use cases. A child actor inherits all the associations of the parent actor, plus may have additional ones.\n\n**Notation**: Directed arrow with a triangle arrowhead from child to parent\n\n\n\n\n\nExample: **Admin** is also a type of **User**. They inherit everything a User can do (browse movies, view showtimes), but an Admin might additionally be able to add/edit movies.\n\n---\n\n# 3. How to Draw a Use Case Diagram (Step-by-Step)\n\nLet's build a use case diagram from scratch for a **Movie Ticket Booking System**. We'll go through each step, and build up to a complete diagram at the end.\n\n### **Step 1: Identify Actors**\n\nStart by asking: who or what interacts with this system from outside?\n\nFor a movie ticket booking system, the actors are:\n\n- **Customer** (primary)\n- **Admin** (primary)\n- **Payment Gateway** (secondary)\n\n\n\n\n\n### **Step 2: **List the Use Cases\n\nNow ask: what does each actor want to accomplish?\n\n- **Customer:** Browse Movies, Book Ticket, Cancel Ticket, View Booking History\n- **Admin:** Add Movie, Update Showtime\n- **System-level:** Process Payment (called during booking)\n\n### **Step 3: Define the System Boundary**\n\nDraw a box around all the use cases and label it with the name of your system. This box represents your system and visually defines the scope.\n\nAnything inside the box is your responsibility to implement. Anything outside is external.\n\n\n\n\n\n### **Step 4: **Draw Associations\n\nConnect each actor to the use cases they participate in with solid lines.\n\n- **Customer** connects to **Browse Movies**, **Book Ticket**, **Cancel Ticket**\n- **Admin** connects to **Add Movie**, **Update Showtime**\n- **Payment** Gateway connects to **Make Payment**\n\n### **Step 5: **Add Include, Extend, and Generalization Relationships\n\nLook for mandatory dependencies and optional extensions.\n\n- **Book Ticket** includes **Make Payment** (you can't book without paying)\n- **Browse Movies** is extended by **Filter by Genre** (optional filtering)\n\nHere's the complete use case diagram for the Movie Ticket Booking System, combining all the elements we've identified.\n\n\n\n","pageType":"lld-interviews"}

Get Premium