The initial description of a use case is text. We can formalize the definition of a use case in terms of preconditions and postconditions. Preconditions state what must be true for the use case to execute. Postconditions state what must be true when the use case has completed. The formulation of a use case in terms of pre- and postconditions is both precise and concise, in no way presupposes a particular design, and avoids the pitfall of specifying the use case in an overly procedural form. 4.4.1 PreconditionsEach use case may have zero or more preconditions. Definition: A use case precondition denotes a relevant, verifiable property of the system that is required to be true before the use case is performed. To help identify preconditions, examine the use case's parameters. For example, Add Item to Order has the parameters Order Number, Book Number, and Quantity. This raises questions about each of these items. What must be so? In the case of Add Item to Order, then, we expect the following to be true:
4.4.2 PostconditionsEach use case has at least one postcondition. Definition: A use case postcondition represents what must be true when the use case has completed. After Add Item to Order completes successfully, we expect the following to be true:
We can write a use case in terms of preconditions and postconditions, as seen in Figure 4.9. Figure 4.9. Preconditions and Postconditions for Add Item to Order4.4.3 Linked Use CasesOne use case's postcondition is often another's precondition. This is especially true when we have sequences of use cases characterized as activities, as you can see in Figure 4.10. Figure 4.10. Connecting Preconditions and Postconditions |