Now that we have covered the technical aspects of use-case development, let’s turn our user interviews into use-cases. Figure 6.8 shows the use-case diagram that depicts our system. We model the server functionality in this section. The next section models the client functionality. In developing use-cases for client/server applications, it is common to create one set of use-cases that model server functionality and another that model client functionality. As you are developing thin-client applications, all business logic (see following Note) is placed at the server level, and server use-cases comment on this.
Client-side use-cases spend time focusing on usability issues.
The following sections contain text descriptions for each use-case. The descriptions conform to the following outline, which allows readers to easily pick out key pieces of information. Note, however, that the outline is by no means a UML requirement. It is instead my preferred manner of developing a use-case. Also note that not all use-cases make use of every element in the outline; for example, some use-cases need no data for completion.
Note The term business logic refers to any code that exists to represent a transaction performed in the target domain. For example, any logic in a banking environment that applies interest to accounts is considered business logic. Code that obtains the name associated with an account is not
considered business logic.
Figure 6.8: The airline reservation server described using use-case notation.
• Actor—Name of the Actor performing the use-case.
• Desired Outcome—Desired return value and changes to state caused by this use- case assuming an affirmative executing.
• Entered When—Discussion of pre-conditions and general entry point for the use- case.
• Finished When—Conditions that must be achieved for the use-case to complete.
• Description—Detailed description of the use-case, along with any additional
information that may be needed. This section is also used to discuss general issues of how the use-case fits into the global picture of the system under development.
• Data Needed—Required information for execution to occur. This section is omitted if no data is sent to the use-case.
• Comments—Any additional information not presented under Description. This section is often used for notes on a future version of the use-case, client thoughts on the use- case, or any other additional information. This section may be omitted if not needed.
Diving into the use-case development, wherever possible we move through the system in a manner similar to that followed by an actual user. This workflow begins when an Actor searches for a flight, and ends when a reservation is booked or cancelled.
Actor Searches for a Flight
Actor. Reservation client.
Desired Outcome. Actor finds a collection of flights that meet his search criteria. Note that this collection may include zero flights if his criteria does not match any active schedules.
Entered When. Actor invokes search function in the server.
Finished When. A collection of flight entities are returned to the Actor. An empty collection is returned if no flights meet the specified criteria.
Description. The purpose of this function is to identity a single flight path from point A to point B. If the Actor desires round-trip information, multiple searches are performed. The server does support simultaneously exposing multiple flight schedules, but it is the burden of the client software to present the data in an easy-to-read fashion. In
representing a single flight path, the following data elements are presented for each leg of the journey: origin airport code, origin time, origin date, arrival airport code, arrival time, and arrival date. Further information on the value expected for each element is contained in Table 6.1.
TABLE 6.1 DATA ELEMENTS USED WHEN SEARCHING FOR A FLIGHT
Name Description
Origin airport code
Unique airport code identifying the point of origin.
Origin time Time of day (24-hour clock) of departure.
Origin date Date (must be year 2000-compliant) of departure.
Arrival airport code
Unique airport code identifying the arrival location.
Arrival time Time of day (24-hour clock) of arrival.
Arrival date Date (must be year 2000-compliant) of arrival.
Data Needed. Data is passed to this function detailing date of origin, time of origin, airport code of origin, airport of destination, number of needed seats, and a range of 0–48 hours, specifying a flexibility in schedule allowed by the Actor if a lower price exists. Again, values for these data elements are detailed in Table 6.1.
Actor Selects a Flight
Actor. Reservation client.
Desired Outcome. Actor selects a target flight from the collection of available flights presented to him.
Entered When. Flight collection is notified of choice flight.
Finished When. Both Actor and server have confirmed the choice flight, and additionally those flights that are not selected.
Description. This use-case is important because it acts as a signal to the system that the Actor has selected a single flight. Any flights that were part of the original collection of flights are no longer candidates for selection once this use-case has exited.
Data Needed. Collection of flights that meet the original search criteria. See “Actor Searches for a Flight” for additional information.
Actor Looks at Available Seats
Actor. Reservation client.
Desired Outcome. Collection of available seats is returned to the Actor.
Entered When. Actor requests seat configuration information for a unique flight.
Finished When. Seat information has been returned to the Actor.
Description. At a given point in time, any flight returned from “Actor Searches for a Flight”
has at least one available seat. This function allows viewing of all unreserved and unlocked seats.
Data Needed. The seat block to be locked.
Comments. It is important to note that the system is multiuser and more than one Actor may be making reservations on the same flight at the same time. Due to this fact, a search has to be coupled with an immediate request from the Actor to lock access to the desired block of seats. See “Actor Locks Access to a Seat” for further information.
Actor Locks Access to a Seat
Actor. Reservation client.
Desired Outcome. A collection of seats is reserved in the system for a specific user.
Entered When. Actor obtains a collection of available seats on a unique flight.
Finished When. Actor identifies the desired seats as a subset of the available collection obtained from “Actor Looks at Available Seats.”
Description. The multiuser nature of the reservation system requires that desired seats on a flight be locked before the actual reservation is made. This locking prevents another Actor from viewing the desired seats as available before the actual reservation is made.
Since many exception situations may occur after the seats are locked and could prevent the reservation from being made, seat locks not turned into reservations become unlocked after 20 minutes.
Actor Makes Reservation
Actor. Reservation client.
Desired Outcome. A reservation is made in the system.
Entered When. Actor requests access to the parts of the system that allow for making reservations.
Finished When. A reservation that meets the Actor’s requested flight criteria is made and a reservation number is returned to the Actor.
Description. Most other use-cases aid in the gathering of the data needed to make an actual reservation; in this use-case the actual reservation is made in the system. A reservation is not limited to a unique flight, but can act as an umbrella under which multiple flights are collected.
Data Needed. In order to make a reservation, the Actor must include all of the following pieces of information: flight and seat information for all flights, method of payment, and passenger demographics. Passenger demographics to be collected include name, billing address, mailing address, and frequent flyer number. Information describing the expected values of each data element is contained in Table 6.2.
TABLE 6.2 DATA ELEMENTS USED WHEN SEARCHING FOR A FLIGHT
Name Description
Name Both the first and last name of the passenger.
Billing address Address to which the reservation was billed.
Mailing address Address at which the passenger accepts mail; usually this matches the billing address.
Frequent flyer
number Alphanumeric ID of the passenger’s frequent flyer account.
Comments. Since locked seats revert to the available pool if they are not turned into a reservation after 20 minutes, the reservation must occur within 20 minutes of the seat locking. As part of the reservation process, all credit card payments must be verified against available funds. If the credit card is denied, the Actor is either prompted to enter another card or to cancel the reservation. See “Actor Cancels Reservation” for
information on reservation canceling.
Actor Cancels Reservation
Actor. Reservation client.
Desired Outcome. Reservation in progress, or already made, is cancelled.
Entered When. The system receives a request to cancel at least one flight owned by a reservation.
Finished When. The flight(s) is cancelled, seats are returned to the available pool, and (if applicable) a refund less cancellation fees is generated. If certain flights on a reservation are to be kept, the entire reservation is still cancelled and the flights that remain are moved to a new reservation.
Description. A user may cancel a reservation at any point after a seat lock has been obtained and before the flight takes place. The most important part of the cancellation process involves removing the lock that has been placed on reserved seats.
Data Needed. The reservation and flights to be cancelled.
Comments. To facilitate historical information gathering, nothing is ever deleted from the database itself. A cancelled flight, therefore, is simply tagged as cancelled and not deleted from the system.
Actor Searches for an Active Reservation
Actor. Reservation client.
Desired Outcome. A collection of reservations is returned to the Actor based upon search criteria. If there are no active reservations that meet the specified criteria, the returned collection is empty.
Entered When. Actor requests that a search be performed.
Finished When. The collection of available flights is returned to the Actor. If no flights meet the specified criteria, an empty collection is returned.
Description. It is a common occurrence that an Actor wants to obtain information on an active reservation after the reservation has been made. This function allows searching of the system for reservations that have either not occurred, or have occurred within the past 60 days. After 60 days, historical information is moved to a data warehouse and is obtained using another application.
Data Needed. To search for a reservation, an Actor must provide the name under which the reservation was made, in addition to any of the following data elements: credit card number used to book the reservation, date of any leg of any flight in the reservation, or time of any leg of any flight in the reservation. Due to that fact that some searches are more limiting than others, this function only returns the top 50 available reservations that match the search criteria.
Comments. This function does present security issues, since reservation information should not be given out if the requestor is not the same individual who booked the flight (or is not a trusted third party). It is up to the reservation operator to follow an authentication procedure to determine if the information requestor is approved for information
dissemination.