Use Case Diagrams

Summary

This video explains how to transform static context diagrams into full use case diagrams by identifying primary and secondary actors, and mapping functional requirements. Primary actors, such as card holders and bank customers, interact directly with the system to achieve goals, while secondary actors, like Visa or bank authentication systems, assist the system in achieving its goals. The video outlines the steps involved, including adding actors, defining system boundaries, and addressing use case variations. Finally, it introduces use case bodies to detail system dynamics, which will be explored in later lectures.

Takeaways

• 😀 Primary actors are users who interact with the system to achieve a goal (e.g., card holder, bank customer, maintenance operator).
• 😀 Secondary actors are systems or entities used by the system to achieve a goal (e.g., Visa authentication system, bank authentication system).
• 😀 The relationship between actors and use cases is the foundation of a use case diagram.
• 😀 Primary actors perform actions with the system, while secondary actors support the system’s functionality.
• 😀 The use case diagram helps clarify functional requirements and actor interactions with the system.
• 😀 Use cases may differ depending on the actor. For example, withdrawing money may vary for a card holder and a bank customer.
• 😀 It’s important to define system boundaries to distinguish which use cases belong to the system.
• 😀 Some actors may inherit use cases from others, such as a bank customer inheriting actions from a card holder.
• 😀 A use case diagram often includes both primary and secondary actors, which may be shown outside the system boundary.
• 😀 Use case bodies provide more detail about actor interactions, order of actions, and potential failure or success conditions.
• 😀 In use case diagrams, actors are kept general rather than being specifically named to avoid overly detailed relationships.

Q & A

What is the key distinction between primary and secondary actors in a use case diagram?

Primary actors use the system to achieve a goal, such as a card holder or bank customer. Secondary actors, on the other hand, are systems or entities that assist the primary actors in achieving their goals, like the Visa or bank authentication systems.

Why is it important to distinguish between primary and secondary actors?

This distinction helps clarify the roles in the system and ensures proper mapping of actors to relevant use cases. Primary actors interact with the system directly, while secondary actors support the system's operations.

How does the use case diagram visually represent system boundaries?

The system boundary is drawn to indicate which use cases are part of the system and which are not. This helps define the scope of the system's functionality and delineates the interactions between actors and the system.

What is the role of use case bodies in understanding system dynamics?

Use case bodies provide detailed descriptions of how use cases unfold, including the order of events, successes, and failures. They offer a more granular understanding of the system's behavior compared to high-level use case diagrams.

Why is it important to keep actors general in the use case diagram?

Actors are kept general to avoid specifying particular individuals, as one person could play multiple roles. For instance, a maintenance operator could also be a card holder, so the actor's roles are represented without names.

How do you handle use cases that differ depending on the actor's role?

You separate these use cases into distinct cases. For example, a card holder and a bank customer may have different processes for withdrawing money, so these would be represented as separate use cases, such as 'withdraw money via Visa' and 'withdraw money via internal bank system.'

What does the inheritance of use cases between actors mean?

Inheritance means that one actor (e.g., a bank customer) can inherit the use cases of another actor (e.g., a card holder). This helps define roles where some actors have access to the same functionalities as others, enabling smoother role transitions or system upgrades.

How do you represent the relationship between inherited use cases in the diagram?

The relationship is represented with an arrow pointing from the inheriting actor to the inherited use case, indicating that the inheriting actor has access to all the use cases of the other actor.

Why might you have duplicate use cases in a system diagram?

Duplicate use cases may arise when different actors have distinct but similar actions. For example, different ways of withdrawing money for various actors (e.g., via Visa vs. internal bank systems) might result in similar but separate use cases.

How do secondary actors typically appear in use case diagrams?

Secondary actors typically appear on the right side of the diagram, and all their relationships with the system are tagged with a secondary actor label. These actors assist in fulfilling the use cases but do not directly interact with the system's users.