From Actors to Actions: Designing a Box Office System with UML Use Case Modeling

A Comprehensive Case Study on Capturing Functional Requirements Through the Use Case View

Introduction

In the complex landscape of software development, one of the most persistent challenges is bridging the gap between stakeholder expectations and technical implementation. How do we ensure that a system does what users actually need before a single line of code is written? The answer lies in requirements modeling—and specifically, in the Use Case View of the Unified Modeling Language (UML).

Use case modeling provides a powerful, user-centric framework for capturing system functionality from the perspective of external actors. Rather than diving into technical architecture or database schemas, use cases answer a fundamental question: “Who interacts with the system, and what do they want to accomplish?”

This case study explores the application of UML use case diagrams through a practical, relatable scenario: modernizing a theater box office system. We will walk through the identification of actors, the definition of functional goals, the modeling of relationships between use cases, and the application of industry best practices. Whether you are a business analyst gathering requirements, a developer designing system behavior, or a student learning UML fundamentals, this guide provides actionable insights for translating user needs into clear, testable specifications.

By the end of this article, you will understand not only how to create effective use case diagrams, but why this approach remains a cornerstone of user-focused system design.

Understanding the Use Case View: Foundational Concepts

Before diving into the case study, let’s establish the core principles that make use case modeling effective:

What Is a Use Case?

A use case represents a coherent unit of functionality—a complete goal that an actor achieves by interacting with the system. It is not a single button click or database operation; it is an end-to-end transaction, such as “Buy Tickets” or “Generate Sales Report.”

The Role of Actors

Actors are roles played by human users or external systems that interact with the application. Crucially:

• Actors exist outside the system boundary

• They initiate or participate in use cases

• They are defined by responsibility, not job title (e.g., “Clerk” not “Jane Smith”)

System Boundary and Scope

The rectangular boundary in a use case diagram defines the scope of the system under design. Everything inside is part of the solution; everything outside represents users, external services, or legacy systems.

Relationships That Add Clarity

• Association: A solid line connecting an actor to a use case they participate in

• <<include>>: Indicates mandatory behavior reused across multiple use cases (e.g., payment processing)

• <<extend>>: Represents optional or conditional behavior that augments a base use case

These elements combine to create a visual contract between stakeholders and developers—a shared understanding of what the system must do.

Case Study: Modernizing the Theater Box Office System

Business Context & Objectives

A mid-sized community theater seeks to replace its manual ticketing process with a digital Box Office Management System. Key objectives include:

• ✅ Enable self-service ticket purchases via lobby kiosks

• ✅ Support staff-assisted sales at the counter

• ✅ Integrate secure credit card processing

• ✅ Provide supervisors with real-time sales analytics

• ✅ Maintain compatibility with existing subscription programs

Identifying the Actors

Through stakeholder workshops, the team identified four key roles:

💡 Key Insight: The Customer is intentionally excluded as a direct actor because they never interact with the application code—they always interface through the Kiosk or Clerk. This preserves clean separation of concerns.

Defining Core Use Cases

The team mapped functional requirements to discrete, goal-oriented use cases:

Use Case Breakdown

Modeling Critical Relationships

The <<include>> Pattern: Reusing Payment Logic

Both buy tickets and buy subscription require payment processing. Rather than duplicating payment logic, the model uses an <<include>> relationship:

[buy tickets] ──<<include>>──> [make charges]
[buy subscription] ──<<include>>──> [make charges]

Why this matters:

• ✅ Ensures consistent payment handling across all sales channels

• ✅ Simplifies maintenance: update payment logic in one place

• ✅ Clarifies that payment is mandatory for transaction completion

External System Integration

The make charges use case communicates with the Credit Card Service, modeled as a secondary actor. This explicitly acknowledges:

• The dependency on an external API

• Potential failure points (network timeout, declined card)

• The need for error handling and retry logic

Key UML Concepts in Practice

Visual Syntax Reference

Naming Conventions That Scale

• ✅ Use verb-noun phrases: buy tickets, make charges, survey sales

• ✅ Be specific but concise: Prefer process refund over handle money stuff

• ❌ Avoid technical jargon: validateCreditCardToken belongs in design docs, not use cases

• ❌ Don’t name after UI elements: click submit button is an action, not a goal

Scope Management: What Belongs Inside?

A common pitfall is over-scoping. Ask: “Is this functionality part of the system we’re building?”

Practical Guidelines for Effective Use Case Modeling

1. Start with User Goals, Not Features

Instead of listing “search functionality,” ask: “What does the user want to achieve?” → find available seats for an event.

2. Keep Use Cases at the Right Level of Abstraction

3. Document Assumptions and Preconditions

Every use case should clarify its context:

**Use Case**: buy tickets  
**Preconditions**: 
- Event is published and not sold out
- System has connectivity to payment gateway
- Actor has selected at least one seat

4. Prioritize Clarity Over Completeness

A use case diagram is a communication tool—not an exhaustive specification. It’s better to have 5 clear, well-understood use cases than 20 ambiguous ones.

5. Validate with Stakeholders Early

Walk through the diagram with:

• End users: “Does this match how you work?”

• Developers: “Is this implementable with our architecture?”

• Testers: “Can we write test cases from this?”

Pro Tips and Common Pitfalls to Avoid

✅ Do: Use <<extend>> for Optional Behavior

Example: A apply promo code use case that extends buy tickets only when a discount is provided.

[buy tickets] <──<<extend>>── [apply promo code]
                     (extension point: "before payment")

❌ Don’t: Model Internal System Steps as Use Cases

Avoid: validate user session, log transaction to database
These belong in Sequence or Activity diagrams, not use case views.

✅ Do: Place Actors Strategically

• Primary actors (initiators) → Left side

• Secondary actors (supporting services) → Right side

• Improves readability and reinforces interaction flow

❌ Don’t: Overuse Include Relationships

If >3 use cases include the same behavior, consider whether that behavior should be a separate system component.

✅ Do: Iterate and Refine

Use case modeling is collaborative. Expect to:

1. Draft initial diagram with core actors/goals

2. Review with stakeholders

3. Add detail (preconditions, extensions)

4. Validate against user stories or acceptance criteria

Conclusion: The Enduring Value of User-Centric Modeling

The Theater Box Office case study demonstrates that effective system design begins not with technology, but with understanding human goals. By adopting the Use Case View, teams gain:

🔹 Shared Language: Business stakeholders and developers align on what the system must do before debating how to build it.
🔹 Scope Control: Clear boundaries prevent feature creep and keep projects focused on delivering value.
🔹 Testability: Each use case becomes a natural unit for acceptance testing and user validation.
🔹 Flexibility: Modular use cases (via <<include>>/<<extend>>) accommodate changing requirements without redesigning the entire system.

While modern agile practices emphasize user stories and prototypes, use case diagrams remain uniquely powerful for visualizing system scope, identifying integration points, and documenting functional requirements in a format accessible to non-technical audiences.

As software systems grow increasingly complex—and user expectations increasingly demanding—the discipline of asking “Who does what, and why?” has never been more valuable. The Use Case View isn’t just a diagramming technique; it’s a mindset that keeps the user at the center of every design decision.

Final Thought: A well-crafted use case diagram doesn’t just describe a system—it tells the story of how people will achieve their goals with it. And in the end, that story is what determines whether technology truly serves human needs.

Suggested Next Steps

1. Draft your own use case diagram for a familiar system (e.g., coffee shop ordering, library checkout)

2. Write a full specification for one use case using the template in this guide

3. Map use cases to user stories: “As a [actor], I want to [goal] so that [benefit]”

4. Explore complementary diagrams: Sequence diagrams for interaction flow; Activity diagrams for complex workflows

What system will you model next? 🎭✨