Now that server functionality has been modeled, we can concentrate on modeling client functionality. Where the server use-cases concentrate on modeling the business logic of our system, the client use-cases can concentrate on modeling usability issues. As with the server use-cases, the client use-cases follow the outline specified earlier in this chapter.
The decision to model the client and server separately was made due to the nature of the n-tier application we are building. All business logic in an n-tier environment is placed at the server level, and a thin client attaches to the server to allow access to its functionality.
The server, in turn, connects to other servers and the persistence mechanism (database, flat file, and so forth).
As an example of how the client and server differ, consider modeling the ability to search for a flight. In the real world, users rarely have a reservation consisting of a single flight but instead book at least one flight in each direction, and potentially more. At the server level, the only consideration when providing flight data is to obtain the single flight that best matches the specified criteria. At the client level, searching for a flight involves searching for multiple flights, displaying them all onscreen, and choosing certain flights to be used in a reservation. Client use-cases can also take into consideration issues regarding the User Interface (UI). The client-side use-cases are shown in Figure 6.9 and described in the following pages.
Figure 6.9: The reservation client use-cases.
Actor Searches for a Flight
Actor. Human user of client software.
Desired Outcome. Collection of flights meeting search criteria is returned to the user.
Entered When. Actor clicks the UI element titled “Flight Search.”
Finished When. Reservations are returned to the user and are displayed onscreen.
Description. When searching for the flights necessary to make a reservation, the Actor may want to simultaneously search for multiple fights. For example, if the flight is round- trip, the Actor wants to search for one flight from origin to destination and another flight from destination back to origin. Additionally, Actors may want to create reservations for flights between multiple cities. For this reason, the screen that supports searching for flights should allow multiple, simultaneous search results to be displayed onscreen at the same time. Since the server only supports executing a single search, the client software has to break up all searches, execute each in a separate thread, and show all results onscreen.
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.
Further information on the expected values for these data elements is found in Table 6.1.
Actor Selects a Flight
Actor. Human user of client software.
Desired Outcome. Flights desired by the Actor are selected.
Entered When. Actor clicks a UI element adjacent to the target flight(s) and then clicks a UI element titled “Select Flights.”
Finished When. Flight selection is communicated to the server and UI is updated to show available seats.
Description. After viewing the results of each search, the Actor has the option to either perform another search or to begin making flight reservations.
Data Needed. Logically, to select a flight, the Actor must have some collection of available flights from which to choose.
Actor Selects Seats on Flight
Actor. Human user of client software.
Desired Outcome. A collection of seats on the desired number of flights is reserved for the Actor.
Entered When. The UI element titled “Select Flights” mentioned in “Actor Selects a Flight”
is clicked.
Finished When. The Actor clicks UI elements identifying all desired seats and clicks a UI element titled “Choose Seats.”
Description. After choosing flights to place under a reservation umbrella, the next step in making a reservation is to pick seats. In this function, the UI displays seat plans for each of the planes and visually identifies each available seat.
Data Needed. To select desired seats, the Actor must be presented with a list of available seats.
Actor Makes Reservation
Actor. Human user of client software.
Desired Outcome. A reservation is made and the unique reservation number is returned.
Entered When. The UI element “Choose Seats” (mentioned in “Actor Selects Seats on Flight”) is clicked.
Finished When. Actor enters demographic and payment data and clicks the UI element titled “Make Reservation”; the unique reservation is returned.
Description. The final steps in making a reservation are to enter passenger demographics, payment information, and to click the UI element titled “Make Reservation.” Passenger demographics collected include billing address, mailing address, and frequent flyer number. A unique flight number is given to the Actor upon successful booking of the reservation. Further information on the expected values for these elements is found in Table 6.2.
Data Needed. Billing address, mailing address, frequent flyer number, payment
information, and flight data.
Comments. In most situations this use-case terminates according to the description under “Finished When.” If the server rejects payment information, the server asks the Actor to either enter new payment information or to cancel the reservation. See “Actor Cancels Reservation” for information on reservation canceling.
Actor Cancels Reservation
Actor. Human user of client software.
Desired Outcome. A reservation either in progress of being made, or already made but not taken is cancelled.
Entered When. Actor clicks any of the many “Cancel Reservation” UI elements present at various stages of the reservation process. The elements first appear once “Actor Selects a Flight” has completed execution. The element is also present when viewing the results of “Actor Searches for an Active Reservation,” assuming the reservation has yet to occur.
Finished When. Reservation is cancelled and (where applicable) any of the following occur: Seats are returned to the available pool, a refund is generated, a new reservation is generated with flights not cancelled.
Description. When an Actor clicks any “Cancel Reservation” button he is presented with a list of flights present on that reservation. The Actor then clicks a UI element next to each flight to be cancelled and then clicks a UI element titled “Process Cancellation.” If less than 100% of all flights in the reservation are cancelled, a new reservation is generated and reservation number is returned to the user.
Data Needed. Reservation and flights to be cancelled.
Actor Searches for an Active Reservation
Actor. Human user of client software.
Desired Outcome. Actor obtains data on a series of reservations that match his specified search criteria.
Entered When. Actor clicks the UI element titled “Reservation Search.”
Finished When. The search results are returned to the Actor.
Description. It is a common occurrence that an Actor wants to obtain information on an active reservation after the reservation was 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 by another application.
Data Needed. To search for a reservation, an Actor must provide the name under which the reservation was made as well as 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 (see Table 6.3). Due to the fact that some searches are more limiting than others, this function only returns the top 50 available reservations that match the search criteria. Once the search results are obtained, the following data elements for each flight are displayed in a multi-list: departure time, departure date, arrival time, arrival date, flight duration, number of layovers. From this multi-list, the Actor may click a UI element that alters the display causing full flight details to be displayed for a unique flight.
TABLE 6.3 DATA ELEMENTS USED WHEN SEARCHING FOR A FLIGHT
Name Description
Departure time Time (24-hour clock) of the flight departure.
Departure date Date (must be year 2000-compliant) of the flight departure.
Arrival time Time (24-hour clock) of the flight arrival.
Arrival date Date (must be year 2000-compliant) of the flight arrival.
Flight duration Length (in hours and minutes) of the flight.
Number of layovers Total number of layovers experienced during the flight as a whole.
Comments. This function presents security issues because 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.
Although we now have a complete picture of the server functionality, there is one additional step that aids developers. We develop the activity diagram for the system in this last step. The diagram, shown in Figure 6.10, depicts the flow of action in the system as a whole.
Figure 6.10: An activity diagram for the reservation system depicts the flow of work executed within the application as a whole.
The use-cases presented in this chapter exist as a final product that has been approved by the client (user-base), product manager, and development manager. At this point it is possible to turn them over to the programming staff for modeling and code development.
What is important to keep in mind is that the UML is used not only for use-case
development, but also for class modeling, object and state modeling, architecture design, and all other steps in the development process. These steps are rather implementation- specific and are illustrated in the chapters of the book where the software is actually implemented.
FROM HERE
This chapter introduces the concepts behind using the UML to model a system in an
implementation-independent fashion. Those concepts were then applied to model an airline reservation system. Later in this book the specifications are turned into more UML models, and then into actual software. Each of those implementations is found in one of the following chapters:
• Chapter 14, “Socket-Based Implementation of the Airline Reservation System.”
• Chapter 16, “RMI-Based Implementation of the Airline Reservation System.”
• Chapter 19, “Servlet-Based Implementation of the Airline Reservation System.”
• Chapter 26, "CORBA-Based Implementation of the Airline Reservation System.”
• Chapter 35, “Voyager-Based Implementation of the Airline Reservation System.”