CHAPTER
3.3 System use cases
System use cases differ from business use cases (Section 2.3) in some aspects. For example, busi- ness actors may spend days or even weeks performing a business use case, while system use cases are often executed in a short period of time, usually minutes, with one or a few actors interacting with a system and obtaining a consistent and complete result for at least one of their goals. System use cases also must be performed without interruptions while business use cases are not restricted in that respect.
Another fundamental difference between a business use case and a system use case is that the business use case is usually performed by many human actors, while the system use case is nor- mally performed by a few (sometimes just one) human actors. The fact is that if a system use case is going to be performed by more than one human actor, then they should be interacting at the same time with the system, and that is not a common situation. Usually, each human actor accesses the system at a time of her convenience, accessing necessary data and performing the necessary actions. This leads to a sequence of system use cases and not to a single use case, as explained later. However, sometimes more than one human actor may be available online; for example, at a supermarket when a customer is buying goods, a supervisor may be summoned to perform actions that the cashier is not allowed to do (e.g., cancel a sale). The point is that the supervisor must be available online and the other actors must wait for her to show up before proceeding.
On the other hand, external computational systems may be considered online actors, because they are available continuously. For example, it can be assumed that a credit card operator is avail- able online continuously. At the moment a customer decides to make a payment with her credit card, the system actorCredit card operatorwill be available.
A high-level system use case is represented only by a name inside an ellipse. It is usually asso- ciated to one or more actors as seen inFigure 3.1.
In the diagram in Figure 3.1, the ellipses represent system use cases. By default, an actor is a role performed by a human. Other kinds of actors may be represented by the use of stereotypes, as shown in Figure 3.1, where the stereotype {systemc indicates that Credit card operator is an external system, not a human.
31 3.3 System use cases
The use case diagram is a very popular UML diagram, but it is also frequently misunderstood.
It is usual to see these diagrams with dozens of use cases and also some of their fragments attached.
However, during Inception, the important thing is to know what the major processes of the system are, and not to detail them. Thus, the presence of fragments in the diagram, and the use of the include andextend relationships between use cases (which sometimes reveal part of their internal structure) is not advisable. Concerns about fragments and use cases including or extending others may be left for the moment when those high-level processes are detailed by system sequence dia- grams (Section 5.8).
Usually there is not enough information to discover all of the fragments at this time. Why should only some of the use case fragments be shown and others not shown? Simply show none at all in the diagram during Inception! This prevents the diagram from having a large number of ellip- ses, which can hinder its comprehension. Thus, there is a need for strong criteria to decide which use cases should be maintained in the diagram to avoid, on one hand, a large number of excessively detailed processes, and on the other hand, too few processes, which could lack important features of the system.
The rule is to consider as a use case only those processes that can be performed in isolation.
Partial processes that mustnecessarilybe performed during other processes must not be represented in the system use case diagram.
However, even following this guide the number of use cases in a real-world system may still be too high, so that dealing with them may become difficult. To reduce the number without losing information and precision a second rule may be used. It consists of grouping use cases that are somewhat related, especially if that may be done more than once, like a pattern. For example, there could be four use cases such asCreate book,Retrieve book,Update book, andDelete book, or just one use case calledManage bookthat includes the four single processes. This is a pattern, because it may be repeated for other concepts:Manage publishermay be used instead ofCreate publisher, Retrieve publisher,Update publisher, andDelete publisher. This pattern is known asCRUD, which is an acronym forCreate,Retrieve,Update, andDelete.
The next subsections detail those rules and present other criteria for achieving the best use case granularity.
Livir
Order books
Pay for books Customer
<<system>>
Credit card operator FIGURE 3.1
System use case diagram.
32 CHAPTER 3 High-Level Requirements
3.3.1 Single session
A good system use case must be performed in a single session.2 This means that it should begin and finish without interruption. For example, the registration of an order is made during a single session of the system, involving the identification of the customer, book selection, price visualiza- tion, payment, address selection, etc. Each of these aspects is a functional requirement of the system.
Use cases must be performed as single processes. Processes that can only happen in the context of other processes are just fragments, not use cases.
In the case of the Livir system, calculating taxes is something that will happen only during the process of ordering books. Let’s suppose that the requirements of the system do not determine that it must be considered an independent process (although it could be, if requirements were different).
In this case,Calculating taxesis not a use case, and because of that fact, it should not be included in the diagram.Figure 3.2illustrates the situation that must be avoided using fragments in the diagram.
On the other hand, Order books can be considered a use case because it is a process with a well-defined start and finish, it occurs in a contiguous time interval (without interruptions), and it produces a sound result (the order is registered).
Livir
Order books
<<Include>>
avoid!
Pay for books Customer
<<system>>
Credit card operator
<<fragment>>
Calculate taxes
FIGURE 3.2
Example of a use case fragment.
2That idea follows Larman’s (2004) definition of anEBP(Elementary Business Process)use case. The EBP definition comes from the business process engineering field: “a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.”
33 3.3 System use cases
In the example represented in Figure 3.1, there are two possible scenarios that could be investigated:
• The system will only confirm the order if the payment is made online (it is not possible to save the shopping cart). In this case, the process of ordering books and paying are just fragments of a single use case that could be calledBuy books. If this is the real requirement, then the diagram must be changed and the two use cases replaced by a single use case named Buy books.
• The system will register the order, but not necessarily proceed to checkout, that is, the shopping cart may be stored until the customer decides to finish the order (which can be done
immediately or at some other time). This is the case represented inFigure 3.1. In this case, Order booksis one use case andPay for booksis another use case. They can be performed immediately one after the other, or with an interval of some days, and because of that, they should be considered independent use cases.
On the other hand, books are not automatically delivered when the order is paid: someone is responsible for verifying, from time to time, which orders have been issued; that person collects books in stock, and sends the package. The delivery process may happen just after the order is paid, but it can also happen on the next day (or even six to eight weeks later). This fact charac- terizes Delivery as a different use case. The Delivery use case has buying books as a precondi- tion, but buying is not part of delivery: delivery just happens after it. Thus, buying and delivering, although sequential and even part of the same business use case, must be considered as different system use cases, as shown in Figure 3.3 where the Send books use case is introduced.
Livir
Order books
Pay for books
Send books Customer
Dispatcher
<<system>>
Credit card operator
FIGURE 3.3
Use cases related to the business process of selling books.
34 CHAPTER 3 High-Level Requirements
3.3.2 Interactive
A use case must also be interactive, meaning that an actor must exist to interact with the system.
The internal processes of the system are not use cases no matter how complex they are. On the other side, a simple query on some information may be a use case if there is an actor that starts it.
The aforementioned internal processes are either part of a use case (as, for instance, Calculate taxesis part ofBuy books), or supplementary requirements (as, for instance, Store data at a rela- tional database). In the case of supplementary requirements, they are usually implemented by inter- nal mechanisms that do not depend on user interaction. During the Inception phase they are recorded as supplementary specifications (Section 3.4.8) or nonfunctional requirements (annotations on use casesSection 3.4.5), so that the risk and effort that they imply is not underestimated.
3.3.3 Consistent result
A use case must produce a consistent result, be it a complete entry or transformation on a piece of information, or simply a query where relevant information is passed to a user. A use case cannot leave the information at an inconsistent state at its end. For instance, the registering of an order cannot be concluded without the identification of the customer and the books she is ordering, or else the information about the order would be incomplete regarding the business rules; the book- store could not resume the order or charge it without knowing who the customer is and which books are ordered.
To decide if a use case has a consistent result, one could think like this: only a complete process is a system use case, in the sense that a user could go to the computer, turn it on, perform the pro- cess, and at its end, turn off the computer, because the process is complete, and some business goal was obtained (some relevant information was received or updated by the user).
This excludes from the use case definition fragments such asCalculate taxes, in the case of the bookstore example, because those taxes are calculated only inside the ordering process, and not as an isolated process. That also excludes operations such as Login, because performing a login and then turning off the computer cannot be seen as a complete process. It may be just part of one or more use cases (Figure 3.4).
To avoid representingLoginas a use case or even as part of one it may be simply assumed that every system operation could only be performed by a user that is regularly identified and autho- rized to perform it. This mechanism is part of the technological design of the system and does not need to be considered in the high-level use case model.
On the other hand, it is possible that complete use cases occur inside other use cases. For exam- ple, the process of registering a customer can be considered a complete use case. But that process
Login avoid!
Customer
FIGURE 3.4
Login must not be considered a complete use case.
35 3.3 System use cases
can also occur during book ordering, especially if it is the first time that the customer is using the system, or when she needs to update data (Figure 3.5).
The dependency association between use cases is stereotyped with {extendcto indicate that the process of ordering books may occasionally be extended by the process of registering the cus- tomer. Both processes may occur independently from each other, but the customer registration can also occur during book ordering.
To avoid abusing{extendcin the use case diagram, it is important to keep in mind that only complete use cases must be maintained in the diagram. Fragments like those shown inFigures 3.2 and 3.4must be avoided, even if they are extension points of a use case. These fragments will be addressed appropriately later, when the high-level use cases are detailed (Chapter 5). In practice, at this point, any association between use cases such as extend or include should be avoided in the diagram because they usually add no useful information for the Inception phase.
3.3.4 Essential
Two styles for writing use cases may be identified:
• Essential use cases, which do not mention interface technology.
• Concrete(orreal)use cases, which are specifically written for a given interface technology.
During requirements elicitation and analysis, system use cases are considered requirements, not design. It is a common mistake to include among these use case actions that are purely related to an interface technology (such asOpen main window,Print report, andLogin). People prepared to handle that facet of design will decide on those actions later, after the requirements are discovered.
Ambler (2000) points out that essential models are more flexible, leaving more options open and more readily accommodating changes in technology. He also says that essential models are more robust than concrete representations because they are more likely to remain valid in the face of changing implementation technology.
Thus, essential use cases must be considered as the correct option during requirements elicita- tion, although technology details or options may be annotated to allow risk management and effort calculation. Later in this book (Section 5.4.1), the difference between essential and concrete use cases will be explained in more detail.
Order books
Register customer
<<extend>>
Customer
FIGURE 3.5
Independent use cases that may be related.
36 CHAPTER 3 High-Level Requirements
3.3.5 Brief
During Inception use cases usually are brief, meaning that they are described just by their name or, in some cases, by one or two sentences. However, this is not the only way a use case may be described. Later they will be extended and contain more details about the requirements (Chapter 5).
Cockburn (2001) identifies three types of use cases with regard to the level of detail:
• Brief: A one-paragraph synopsis of the use case.
• Casual: Written in simple, paragraph, prose style. It is likely to be missing project information associated with the use case, and is likely to be less rigorous in its description than a fully dressed use case.
• Fully Dressed: Expanded to include a main flow and alternate flows, as well as other sections such as postconditions, preconditions, stakeholders, and technological variations.
In this book we expect that use cases considered during the Inception phase will be brief. This means that usually their name is sufficient to explain their meaning. However, additional explana- tion is allowed for the sake of requirements comprehension. Also, if some key use cases have to be expanded in order to identify risks regarding their inherent complexity, this is also acceptable.
Usually, fully dressed or expanded use cases will be useful only after Inception, when requirements must be detailed adequately.
3.3.6 System boundary
One of the decisions a team must make when designing system use cases is where to place the sys- tem boundary. Graphically, the boundary is only a rectangle that is placed on the diagram. Inside it are the use cases and outside are the actors. In business use case diagrams, the system boundary represents the limits of the organization (company, department, etc.). Here, it represents the limits of a computational system.
A decision was made earlier on which workers to include in the automation border. One exam- ple is the clerk that helps the customer buy books. In that case, when modeling system use cases theClerkdisappears, and the use case is performed by the customer itself.
However, if it was not a virtual bookstore, but a regular one where customers buy at a store, should the clerk be kept in the use case diagram? For a use case to be as essential as possible, it is recommended that only actors that are really interested in the use case be kept in the dia- gram. The clerk of the example is just a proxy of the customer; the clerk has no personal goals in the process of buying books. It acts simply as a system interface. Whether the bookstore is virtual or not, the essential use case should be the same, because the same information would be exchanged between the customer and the system; the clerk would only transmit information as she receives it. In this case, the only actor would be the customer and the clerk should not even appear in the diagram. In this way, the analysis will produce use cases that are technology independent.
Someone could ask the following: What if the clerk must indicate that she assisted in the sale so that a percentage would be paid to her? In that case, what we have is a use case that is different from the one mentioned in the last paragraph. Here, both the customer and the clerk should be actors: the customer is interested in the books and the clerk is interested in the percentage. Also, if 37 3.3 System use cases
the clerk may perform actions that are not allowed for the customer (e.g., overriding a product price) she must be considered an actor and may not be removed from the diagram.