Use Case Diagram

Before diving into classes and sequences, you need to understand what a system is supposed to do from the user's perspective. Who are the users? What goals can they accomplish with the system? This is where Use Case Diagrams come in. They are part of UML and are used to describe the functional requirements of a system.

A Use Case Diagram provides a high-level, black-box view of a system. It shows the different ways a user might interact with the system and the different outcomes of those interactions. It's less about how the system works internally and more about what the system does for its users.

Core Components of a Use Case Diagram

1. Actor: An entity that interacts with the system. An actor can be a human user, an external system, or a device. It is represented by a stick figure.
2. Use Case: A specific goal or task that an actor can accomplish with the system. It is represented by an oval.
3. System Boundary: A rectangle that separates the system from the external actors.

Relationships in Use Case Diagrams

1. Association

A simple line connecting an actor to a use case. It indicates that the actor participates in that use case.

2. Include

An <<include>> relationship is a dependency where one use case must include the functionality of another. For example, "View Account Balance" might be included in both "Withdraw Money" and "Transfer Funds" because you must check the balance first. It's a way to reuse common functionality.

3. Extend

An <<extend>> relationship is optional. It represents functionality that can extend the behavior of a base use case. For example, the "Calculate Bonus" use case might extend the "Login" use case, but only if the user is an employee.

Example: Modeling an ATM System

Let's model a simple ATM system to illustrate these concepts.

Actors:

• Customer
• Bank (as an external system for verification)

Use Cases:

• Withdraw Cash
• Check Balance
• Transfer Funds
• Validate User (included in other use cases)

Use Case Diagrams are excellent for the initial phase of a design interview. They help you clarify the scope of the problem and ensure you and the interviewer are on the same page about the system's requirements before you start designing the internal components.