As discussed in Chapter 3, a use-case is a tool used for modeling a unique function in a system. Use-cases should be easy to read, unambiguous, and generally provide a detailed explanation of the highlighted function.
It is really important that a use-case not leave any question unanswered. Remember that the functions as they are defined in use-cases become your software. If you mean one thing, but the developers interpret your comments in a different manner, the costs can be rather large.
Another important use-case development requirement to keep in mind is that use-cases model a single function in a system. That function has a distinct starting point and a distinct end value. A common mistake made by people when developing use-cases is to model the entire system as one large use-case. Modeling a system as a single use-case leads to confusion, and should only be done if the system exposes a single function.
It should be noted that the term used to describe the entity executing a use-case is Actor.
A use-case is performed by an Actor that may or may not be an actual person. In fact, in many situations the Actor performing a use-case is another piece of software.
A use-case is implementation-independent and, in fact, does not necessarily need to be implemented in software. One could easily write a use-case that models the process of driving a car, or even walking the dog. Although it might be rather exciting to model our entire lives via use-cases, doing so here would move this book into the self-help section, which is not a desired outcome of the “Actor writes a computer book” use-case. The use- cases developed in this chapter are implemented throughout the book in Java using each of the highlighted distributed object technologies.
Finally, use-cases apply to the general use of a system and not a specific interaction with the system. For example, a use-case titled “Actor searches for a reservation using a reservation number” is probably a valid use-case. A use-case titled “Actor searches for a reservation using reservation number #1013-42” is a use-case scenario since it
represents a distinct interaction with the system. Use-case scenarios are useful for modeling how special conditions are handled.
Use-Case Notation
Just as the UML provides symbols for modeling all parts of the software process, a series of UML symbols exist that are used with use-cases. The airline-reservation system use- cases do not take advantage of every symbol (most use-cases don’t), but as a reference they are all addressed here.
The first step when developing a series of use-cases is to identify the system that is being modeled. A square, with the name of the system written above it, denotes a single system. Figure 6.1 shows a model of the airline reservation system.
Figure 6.1: The square symbol denotes an entire system.
After identifying the system being modeled, use-cases that identify unique functions within the system are added. A use-case is denoted using an ellipse or oval with a logical name placed below it. The names applied to both use-cases and systems should be logical, easy-to-read names, and not obscure variable-like names. For example, a use- case that models a reservation search by reservation number should be titled “Search for a Reservation by Reservation Number,” not named resSearchByNum . Figure 6.2 shows a single use-case that becomes part of our system.
Figure 6.2: The ellipse or oval symbol denotes a use-case.
Use-Case Relationships
Within a given system, situations may arise where two or more use-cases share some features, or where two or more use-cases use each other. For these reasons, it is possible to model three different relationships between use-cases. These relationships
are defined as follows:
• Grouping—Similar to Java packages, the grouping relationship exists when multiple use-cases perform common tasks in a system.
• Uses—Similar to object composition, the uses relationship exists when multiple use- cases interact with each other.
• Extends—Similar to Java inheritance, the extends or generalization relationship allows one use-case to inherit functionality from a parent use-case.
The grouping relationship is defined using the UML package symbol. This symbol, shown in Figure 6.3, looks much like a file folder with a logical name near its top. There are zero functional implications presented by the grouping relationship. However, it does aid the logical grouping of use-cases. Systems with hundreds or thousands of use-cases employ this relationship to make their documents easier to understand.
Figure 6.3: The use-case grouping relationship is modeled with the package symbol.
The uses relationship is employed when one use-case takes advantage of functionality present in other use-cases. This relationship, shown in Figure 6.4, is modeled using a straight line ending in a triangle. The triangle points to the use-case being used and the line has the word <<uses>> written next to it.
Figure 6.4: The uses relationship allows one use-case to take advantage of functionality exposed by another usecase.
The extends relationship can be thought of in terms similar to Java or C++ inheritance.
This relationship is used when one use-case needs to inherit functionality from a parent use-case. For example, one use-case might be used to model making a standard airline reservation. Two additional use-cases could extend this parent use-case and model the situation when reservations are made using frequent flyer miles or a bounce pass (a ticket voucher or discount coupon given to passengers who volunteer to leave a over- booked flight). The extends relationship, shown in Figure 6.5, is shown using a line with a triangle at the end of it. The triangle points to the parent use-case and the line has the word <<extends>> written next to it.
Figure 6.5: The extends relationship allows one use-case to inherit functionality exposed by another use-case.
Use-Case Actors
As was earlier stated, an Actor performs a use-case. The Actor may or may not be an actual person; regardless, it is modeled using a stickman. Directly below the stickman, the Actor is labeled with a logical name. Figure 6.6 shows two potential Actors in our reservation system.
Figure 6.6: The stickman symbol denotes an Actor.
The development of a use-case is one of the most important tasks in a given software development project. Because use-cases drive the entire development process, it is critical that they unambiguously describe exactly what the software should do.
The development of a use-case is an iterative process that involves the user-base (client), project managers, and developers or development managers. Project managers through a dialog with the user base come up with initial copies of the use-cases. Often the project manager first interviews the user base to determine its needs. He then generates usecases and presents them to the client. This presentation process often involves physically acting out the use-case with different people playing the roles represented by different systems.
Once some level of agreement has been reached between the project manager and the client, a dialog between the project manager and the development manager begins. It is the duty of the development manager to ensure that all use-cases are technologically feasible. If, for example, the project manger writes a use-case titled “Actor thinks about an item and it materializes in his hand,” the development manager needs to use this
opportunity to put his foot down. This example does, however, bring up another point, which is that the project manager must be either technically savvy or must work with the development manager earlier in the use-case development process. If the project
manager is going to write pipe-dream use-cases, the development manger must reel him in before the client gets any far-off ideas.