Tracing Interfaces from Use Cases
The primary purpose of interaction diagrams is to discover and justify the interfaces of the classes in your model.
Using scenarios from the use cases ensures that the interfaces support the goals of the system. This approach allows you to trace a class interface back to the requirements as defined in the use case model.
Because this approach provides a connection between the use cases and the object model, it is possible to identify interfaces that are introduced without direct support from the user requirements.
Alternatively, there are times when project participants believe that an interface is required that is not found in the use case model. When this happens, a review of the use cases is justified to find out why use cases are not included, thus uncovering requirements that may have been missed.
This reconciliation process illustrates the value of comparing and contrasting the different diagrams as a tool for discovery during analysis.
Alternatively, there are times when project participants believe that an interface is required that is not found in the use case model. When this happens, a review of the use cases is justified to find out why use cases are not included, thus uncovering requirements that may have been missed.
This reconciliation process illustrates the value of comparing and contrasting the different diagrams as a tool for discovery during analysis.
Use Case
A use case is the specification of a set of actions performed by the subject, possibly including variants, which yields an observable result of value to one or more actors or other stakeholders of the subject. A use case is actually a description of one or more scenarios of interaction of an actor (or actors) and the subject,
that conveys how the subject is used in a particular situation and how it should behave in order to achieve a certain business goal or function.
It may be regarded as an outwardly visible and testable behavior of the subject with a clear goal, or a description of a collaboration between the subject and one or more actors.
Let us consider a classical example of an Automatic Teller Machine (ATM) as the subject. The use cases (shown in Figure 3-4) could be the following:
- Withdraw Cash: A Client (as an actor) can take an amount of money out of her account in a Bank (as another actor of the ATM).
- Transfer Money: A Client can transfer an amount of money from her account to another account.
- Check Balance: A Client can find out how much money there is in her account.
- Disable ATM: An Administrator (as another actor) can disable the machine. The machine becomes inoperable.
- Enable ATM: An Administrator can enable a disabled ATM. The machine becomes operable.
- Read Log: An Administrator can read the log file of the ATM in order to investigate its operation.
