2.1. Purpose

To represent high-level functional interactions between actors (users or systems) and the system. These diagrams help define the scope of the system and its functionality.

The purpose of UML (Unified Modeling Language) diagrams is to provide a visual representation of how different entities interact within a system. Specifically, it highlights the interactions between actors—who can be users or other systems—and the system itself. This is crucial to understand the system’s capabilities and functionalities, allowing stakeholders to identify what the system is supposed to do and how it serves its users.

Think of a UML diagram like a movie script. In a script, characters (actors) engage with the storyline (system), and the audience (stakeholders) needs to know what happens in the plot (scope and functionalities) to understand the film. Just as a script outlines character roles and interactions, UML diagrams outline the interactions between users and the system.

Key Components: ● Actors: External users or systems interacting with the application ● Use Cases: Functionalities the system provides ● System Boundary: Encapsulates use cases within the system ● Relationships: ○ Include: A use case always includes another (common logic) ○ Extend: A use case optionally extends another (conditional logic) ○ Generalization: Inheritance between actors or use cases

Use case diagrams consist of several key components. Actors represent any external entity that interacts with the system. Use cases outline the specific functionalities the system provides. The system boundary visually separates the system from external factors, showing what is included within the system. Additionally, relationships define how different use cases relate to each other, such as inclusion, which signifies that one use case is always part of another, and extension, which signifies optional use cases.

Consider a restaurant scenario: the 'actor' could be a 'Customer', while 'Use Cases' might include 'Order a Meal' or 'Make a Reservation'. The 'System Boundary' distinguishes what's handled within the restaurant app compared to external factors like delivery or payment systems. Using these relationships, you can understand that 'Ordering a Meal' may include actions like 'Choosing a Dish' and might extend to 'Making a Special Request'.

BA’s Usage: ● Define system functionality from an end-user perspective ● Identify user roles and their goals ● Validate functional scope with stakeholders

Business Analysts (BAs) use use case diagrams for several important tasks. They define how the system functions from the perspective of end-users, which helps in identifying the key roles that users play and what they aim to achieve with the system. This process is crucial for validating the scope of functionalities with stakeholders, ensuring everyone has a common understanding of what the system should deliver.

Imagine a travel booking website from the perspective of a BA. By applying use case diagrams, the BA identifies roles like 'Traveler' and functionalities such as 'Book a Flight' and 'Cancel Reservation'. This structured approach helps the BA collaborate with stakeholders (like marketing or customer service teams) to confirm that these functionalities align with user expectations and business objectives.

--