Merge short, simple use cases—such as Creating, Reading, Updating, and Deleting pieces of information into a single use case forming a conceptual unit.
Keywords: Create data, delete data, information handling, merge use cases, read data, short flow, short use case, simple operation, update data.
The CRUD: Complete pattern consists of one use case, called CRUD Information (or Manage Information), modeling all the different operations that can be performed on a piece of information of a certain kind, such as creating, reading, updating, and deleting it.
This pattern should be used when all flows contribute to the same business value and are all short and simple.
Quite often systems handle information that, from the system's viewpoint, is very easily created in the system. After a simple syntax or type check, and perhaps some trivial calculation or business-rule check (see Chapter 16, “Business Rules”), the information is simply stored in the system. No advanced calculations, verifications, or information retrieval will have to be performed. The description of the flow is only a few sentences long, and there are probably not more than one or two minor alternative paths in the flow. Reading, updating, or deleting the information are equally simple operations. Each of them can be described in a few sentences.
Should such operations be modeled as use cases and, if so, must they be included in the use-case model? The answer to both questions is yes. They are indeed use cases because something is to be performed in the system; someone is to use the system to create (read, delete, update) some piece of information in the system. Moreover, they must be included in the use-case model, or the model will not be complete. If these use cases are not included in the model, some stakeholder will probably miss them; otherwise, the functionality should not have been included in the system in the first place.
Luckily, this does not necessarily mean that this kind of functionality should be expressed as separate use cases. Instead, according to the CRUD: Complete pattern, we group them together in so-called CRUD use cases, including all four types of operations on some kind of information—creation, reading, updating, and deletion of any such information.
This procedure has a few obvious advantages. First, the size of the model will be reduced, which will make it easier to grasp because the number of use cases will be reduced. Second, nobody will be interested in a system containing only a subset of these use cases (for example, read and delete, but not create and update). Grouping these flows together in a single use case called something like CRUD X ensures that all four are included in the model, and makes it clear to every reader of the model that this is the use case where all this functionality is captured. Third, the value of each of the separate use cases is very small (if any) for the stakeholders; it is the whole collection of them that gives a value to the stakeholders. Together these use cases form one conceptual unit (see Figure 20.1).
Figure 20.1. The four simple operations should not be modeled as separate use cases. Instead, they should be merged into one use case including all four operations as separate flows.
Note that if only some of the four operations are simple while others are complex, you can group the simple operations into one use case and let the other ones be modeled as separate use cases, according to the CRUD: Partial pattern.
Note also that this is a typical situation where a use case does not have only one basic flow. None of them can be said to be more “basic,” or “normal,” than the others. Therefore, a CRUD use case will typically have four basic flows, and possibly a few alternative flows, as is shown in the following example.
An instance of a CRUD use case will perform either a creation, a reading, an updating, or a deletion, and after that it will cease to exist. This instance will not continue to live and wait for the next operation to be performed. That operation will be performed by another instance of the same use case.
A so-called CRUD use case may of course include other (basic) flows than the four common ones, such as searching for an item, or performing some simple calculation based on an item.
It is important not to merge advanced or complex operations into one use case. They should remain separate use cases instead, because they will probably be developed, reviewed, designed, and implemented separately.
As a general rule, when not sure whether to merge the different usages into one use case or to keep them as separate use cases, they should no doubt be kept apart. This decision will not affect the functionality of the system, only the model structure and hence its maintenance.
This section provides an example of the CRUD: Complete pattern. It models the registration of a new task to be performed sometime in the future, the modification of a registered but not performed task, the cancellation of such a task, and the presentation of tasks that either failed during their execution or have not yet been performed (see Figure 20.2). As you can see, the four different alternatives are quite simple and short, and they are expressed as four basic flows, because none of them can be said to be superior to the others. Therefore, this is an application of the CRUD: Complete pattern even if some of the four basic flows in this case are different from the standard ones.
Figure 20.2. The CRUD Task use case models the creation, modification, presentation, and cancellation of a task.
Error handling and exceptional flows are expressed as alternative flows of the use case.
The Item Look-Up and the Future Task blueprints are also useful in this example.
The analysis model of a CRUD use case is based on all the flows of the use case. It must include the realization of all the basic flows as well as the realization of the alternative flows.
However, because the flows are quite simple in this case, the model usually contains one boundary class for presentation and modification of the information, one control class to handle any checks, and one entity class (or perhaps a few) to store the information (see Figure 20.3). The flow starts in the System Form when the Information User requests to create, read, update, or delete the information. An instance of the Information Handler is created, which opens an instance of the Information Form to the Information User.
Depending on the chosen operation, the actor enters information about a new piece of information, or the Information Handler retrieves existing information and asks the Information User via the Information Form to select one item. The Information Form sends the new information or the identity of the selected item, respectively, to the Information Handler which performs the chosen operation. Finally, the Information Form and the Information Handler are removed and the use case ends.