1. Module 4: Modeling Techniques

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.

Use case diagrams serve as a visual tool to capture and communicate how different users or systems (called actors) interact with a software application. This helps stakeholders understand the functionalities that the system offers and outlines what to expect from it. Essentially, they provide a bird's-eye view of user actions and the system’s responses.

Think of a use case diagram like a map for a shopping mall. Just as a mall map shows you where various stores (functionalities) are located and how customers (actors) can navigate to them, a use case diagram illustrates the different functionalities of a system and how users can interact with them.

● 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

Key components of use case diagrams include:

• Actors: These are the users (like customers) or other systems interacting with the primary system.

• Use Cases: These represent different operations or functions that the system performs, like 'Register' or 'Checkout'.

• System Boundary: It's like an imaginary line that defines what functionalities are part of the system. Everything inside it are features available for use.

• Relationships: These show how the use cases and actors relate to each other. For example, the 'Include' relationship indicates that one use case is a mandatory part of another, whereas 'Extend' signifies optional features.

Consider a video game. The players (actors) can perform actions like starting a game (use case), saving progress (another use case), and accessing settings (another use case). The system boundary would define what’s included in the game versus what’s outside it, like a game manual. The relationships help understand dependencies between these actions: you must start the game before you can save progress.

In an e-commerce system: ● Actor: Customer ● Use Cases: Register, Login, Search Product, Add to Cart, Checkout, Make Payment

In the context of an e-commerce platform, the customer is an actor interacting with the system. The various use cases represent functionality that the customer can leverage, such as registering for an account, logging in, searching for products, adding items to the shopping cart, proceeding to checkout, and ultimately making a payment. Each of these actions corresponds to a specific interaction that encapsulates what the system does for the user.

Imagine shopping at an online store as a customer. You register to set up an account, then log in to shop. You look for products (search), add them to your cart, checkout, and pay. Each of these steps represents a 'transaction' with the e-commerce system, just like going through different stations at a checkout line in a physical store.

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

Business Analysts (BAs) utilize use case diagrams primarily to define functionality from the perspective of end-users. This ensures that the design aligns with user needs. Additionally, BAs identify different user roles who will interact with the system, along with their specific goals, which helps expose key functionalities that must be included. Finally, use case diagrams serve as a discussion tool with stakeholders to validate that the documented scope of the project meets user expectations and needs.

Consider BAs as travel planners. They talk to various travelers (users) to understand how they wish to experience a trip (functional requirement). They map out roles like 'Business Traveler' or 'Family with Kids'. By presenting a travel plan—what each traveler can expect—they gather feedback to finalize the itinerary before confirming bookings (validation), ensuring the trip meets all travelers' expectations.

--