Use Case Concepts in Object-Oriented Analysis
Use cases are a powerful way of modeling what the system needs to do. Read this section to learn about use case diagrams and how they capture functional requirements.
2. Use Case Granularity
Ariadne (2001) elaborate clearly that it can be difficult to decide upon the granularity of use cases in particular scenario, should each user-system interaction be a use case, or should the use case encapsulate all of the interactions? Taking an example of the ATM system in Figure 3.3 to allow a user to withdraw money, we may have the following interactions:
- Enter card
- Enter pin number
- Select amount required
- Confirm amount required
- Remove card
- Take receipt
Should each of these steps e.g. "enter pin number" be a use case?
This is a classic mistake in construction of use cases. Here we have generated a large number of small, almost inconsequential use cases. In any non-trivial system, we would end up with a huge number of use cases, and the complexity would become overwhelming.
Figure 3.4: A Not Useful Use Case Diagram
To handle the complexity of even very large system, we need to keep the use cases at a fairly "high level". The best way is to keep the following rule-of-thumb in mind.
"A Use Case should satisfy a goal for the actor"
If we apply this simple rule to our example above, we can notice than none of the presented use cases in Figure 3.4 is qualifying to be a use case, since they do not describe the goal of the use case. The goal of use cases could be withdraw money, deposit money etc as shown in figure 3.5.
Figure 3.5: A More Focused Use Case Diagram