CHAPTER
UCP 5 UUCP TCF EF For the running example we obtain
5.7 Other sections of an expanded use case
In this example, two business rules were used to identify exceptions:
• The identification code for publishers must be unique, which must be verified both when a new instance is included and when an instance is updated. This produces exceptions in step 1a.1 and 1c.2, which may be identified as a single exception (1a.1,1c.2)a.
• If the publisher already has a book associated to it (and that association is mandatory for books, i.e., every book must be linked to a publisher) then it cannot be deleted. This is a structural rule that must appear explicitly in the conceptual model as a mandatory role from book to publisher (Section 6.4.1).
Figure 5.20presents the CRUD use caseManage customers, which is a variation on the pattern.
A customer can retrieve and modify only her own data. Thus, the use case must be adapted to that fact. On the other hand, it may be desirable that a system manager could access data from any cus- tomer. For that manager the use case would be a regular CRUD. Would two use cases be created here? One for the customer to manage her own data and the other for the system manager to manage data from all users? Maybe. . . but it seems that this approach would be quite repetitive. To make things even worse, imagine that it is possible for a regional manager to access the data of users only from her region. Would this be a third use case? This does not sound like a good solution.
To solve this issue in an elegant way, the use case could be parameterized, indicating that the user can only access data from customers she is authorized to review. When customers are being managed, what must be verified by a given business rule is whether the user really has permission to access or change the data from the customer she is trying to access or change. InFigure 5.20 checking that permission is performed by exception handler (1b.1,1d.1)a:Access not authorized.
Notice that the use case in Figure 5.20 is a CRUD variation that could be called CRUD with access restriction, because the access to data depends on who is the user.
Other CRUD variations exist, such as:
• CRUDL: Including a variant to list the existing elements. Thus, instead of simply identifying an object to retrieve, update, or delete, the user canselectit from a list.
• SCRUD: Including a variant to search elements.
• RUD: Where elements may be retrieved, updated, and deleted, but not created.
• CRU: Where elements may be created, retrieved, and updated, but not deleted.
Many other variations may be invented depending on the need and the cost/benefit of having more patterns to remember.
There is a simpler way to define a pattern-based use case if it fits perfectly on the pattern. This consists of simply listing the field to be filled and the business rules to be observed. For the rest, the pattern is applied.Figure 5.21shows an example.
With the information given in Figure 5.21 and the template of Figure 5.18 it is possible to implement the use case without expanding it.
Use Case 11: Manage Customers <<crud>>
1. User chooses:
• Create customer: Variant 1a
• Retrieve customer: Variant 1b
• Update customer: Variant 1c
• Delete customer: Variant 1d Variant 1a: Create customer
1a.1. User provides customer’s name, ID, address, phone, and email.
Variant 1b: Retrieve customer
1b.1. User identifies a customer.
1b.2. System presents customer’s name, ID, address, phone, and email.
Variant 1c: Update customer
1c.1. Include variant 1b: Retrieve customer
1c.2. User provides new values for customer’s name, ID, address, phone, and email.
Variant 1.d: Delete customer
1d.1: User identifies a customer to be deleted.
Exception (1a.1,1c.2)a: ID already exists.
(1a.1,1c.2)a.1: System informs user that there is already a customer with the given ID.
(1a.1,1c.2)a.2: Return to the step that caused the exception.
Exception (1b.1,1d.1)a: Access not authorized.
(1b.1,1d.1)a.1. System informs user that access is denied.
(1b.1,1d.1)a.2. Return to the step that caused the exception.
Exception 1d.1b: There are orders associated to the customer.
1d.1b.1: System informs user that it is not possible to delete a customer with orders associated to it
1d.1b.2: Return to step 1d.1.
FIGURE 5.20
An expanded CRUD use case with access restrictions.
90 CHAPTER 5 Expanded Use Cases
and “alternate flows” sections are fundamental for any detailed use case description. However, other sections can be included if the analyst needs them. Some of the most popular are presented in the next subsections.
5.7.1 Stakeholders
There are often scenarios where groups other than actors are relevant to a use case. Other sectors of the company could have some interest in the use case. For example, in the use caseOrder books the only actor is the customer. But the results of that use case may interest the stock and accounts departments, because the results of a sale may affect both the quantity of books in stock as well as the quantity of money available or to be received. Thus, even if those departments are not partici- pants in the use case, they can be listed asstakeholders.
The utility of the stakeholders list for a use case is that the use case must satisfy all stake- holders. Thus, the documentation will be useful to remind the analyst to seek information that needs to be stored, processed, or transmitted, so that those interests can be satisfied.
5.7.2 Preconditions
By definition, preconditions are facts considered true before a use case even starts. Preconditions must not be confused with exceptions: exceptions may be detected only after the use case has started. Exceptions are detected during a use case because most of the time it is not possible to ver- ify if the conditions were true or not before the use case begins. For example, it is not possible to assure that the customer has enough credit to pay for the order before starting theOrder booksuse case, because the value of the order cannot be known at that time; therefore this is an exception.
However, it is possible to admit that only a book that was sold and delivered can be returned.
Thus, the sale and delivery of the book is a precondition for its return.
As preconditions are accepted as true facts before the use case starts, they will not be checked during the use case. Although there can be other interpretations in literature, these kind of
Use case 12: Manage books <<crud>>
Fields:
• ISBN, title, author, page count, publisher, price.
Rules for insert and update:
• The ISBN is unique, i.e., different books cannot have the same ISBN number.
Rules for delete:
• A book that has sold copies cannot be deleted.
FIGURE 5.21
Example of brief expansion for a CRUD use case.
91 5.7 Other sections of an expanded use case
preconditions do not generate exceptions. If they are false it should be impossible to start the use case (otherwise they are exceptions, not preconditions).
5.7.3 Success post-conditions
Success post conditionsestablish the results of a use case, that is, what will be true after the use case is executed. For example, theOrder booksuse case may have as a post-condition the follow- ing result: “the order was registered by the system.”
5.7.4 Open issues
Sometimes, without the presence of the client, the team cannot decide about some issue that may depend on company policies. For example, may the customer pay the order in installments? Are there special offers for customers that buy more than certain quantities?
If the client is not immediately available, these doubts must be recorded in the use case section
“open issues” in order to be solved as soon as possible.
At the end of the analysis activities of one iteration it is expected thatallopen issues have been resolved and incorporated into the use case description.