Step: Supplement the use-case descriptions

The description of each use case is not always sufficient for finding analysis classes and their objects. The customer generally finds information about what happens inside the system uninteresting, so the use-case descriptions may leave such information out. In these cases, the use-case description reads like a ‘black-box’ description, in which internal details on what the system does in response to an actor’s actions is either missing or very summarily described. To find the objects which perform the use case, you need to have the ‘white box’ description of what the system does from an internal perspective.

Example

In the case of an Automated Teller Machine (ATM), the customer of the system may prefer to say

"The ATM validates the Bank Customer’s card."

To describe the user authentication behavior of the system. While this may be sufficient for the customer, it gives us no real idea of what really happens inside the ATM to validate the card.

In order to form an internal picture of how the system really works, at a sufficient level of detail to identify objects, we may need additional information. Taking the ATM card validation activity as an example, the expanded description would read as:

"The ATM sends the customer’s account number and the PIN to the ATM Network to be validated. The ATM Network returns success if the customer number and the PIN match and the customer is authorized to perform transactions , otherwise the ATM Network returns failure."

This level of detail gives us a clear idea of what information is required (account number and PIN) and who is responsible for the authentication (the ATM Network, an actor in the Use Case model). From this information, we can identify two potential objects (a Customer object, with attributes of account number and PIN, and an ATM Network Interface) as well as their responsibilities.

Examine the use-case description to see if the internal behavior of the system is clearly defined. The internal behavior of the system should be unambiguously, so that it is clear what the system must do. It is not necessary to define the elements within the system (objects) that are responsible for performing that behavior – just a clear definition of what needs to be done.

Sources of information for this detail include domain experts who can help define what the system needs to do. A good questions to ask, when considering a particular behavior of the system, is "what does it mean for the system to do that thing?". If what the system does to perform the behavior is not well defined enough to answer that question, there is likely more information that needs to be uncovered.

The following alternatives exist for supplementing the description of the Flow of Events:

• Do not describe it at all. This might be the case if you think the collaboration diagrams are self-explanatory, or if the Flow of Events of the corresponding use case provides a sufficient description.
• Supplement the existing Flow of Event description. Add supplementary descriptions to the Flow of Events in areas where the existing text is unclear about the actions the system should take.
• Describe it as a complete textual flow, separate from from the "external" Use Case Flow of Events description. This is appropriate in cases where the internal behavior of the system bears little resemblance to the external behavior of the system. In this case, a completely separate description is warranted.