Write down a textual description (using the format of Table 2, reproduced below) of the use case check in guest, shown in Figure 3, also below. As part of your deliberations, identify any exceptions to the main success scenario.
Table 2 Textual description of a use case in the hotel domain
|Identifier and name||UC_1 Make reservation.|
|Initiator||Receptionist or Guest.|
|Goal||Reserve a room at a hotel for a guest.|
|Pre-condition||None (that is, there are no conditions to be satisfied prior to carrying out this use case).|
|Post-condition||A room of the desired type will have been reserved for the guest for the requested period and the room will be occupied for that period.|
|Assumptions||A guest can make a reservation via the Internet. The guest is not already known to the hotel's software system (see main success scenario, step 5).|
|Main success scenario|
|1||The guest requests a reservation.|
|2||The guest selects the desired hotel, dates and type of room.|
|3||The hotel receptionist provides the availability and price for the request (an offer is made).|
|4||The guest agrees to proceed with the offer.|
|5||The guest provides identification and contact details for the hotel's records.|
|6||The guest provides payment details.|
|7||The hotel receptionist creates a reservation and gives it an identifier.|
|8||The hotel receptionist reveals the identifier to the guest.|
|9||The hotel receptionist creates a confirmation of the reservation and sends it to the guest.|
You need to consider the exchanges that take place between each guest and the hotel's receptionist. Furthermore, you should ignore the guests who are trying to check out. The main success scenario, as shown in Table 4, describes the simplest path that leads to successfully checking a guest into a room in a hotel. There can, and will, be exceptions to the main success scenario, but these will be dealt with later.
Table 4 Textual description of a use case in the hotel domain
|Identifier and name||UC_2 Check in guest.|
|Goal||A guest takes up a reservation and occupies a room at the desired hotel.|
|Pre-condition||There is a reservation for the guest and there is, at least, one room available (of the desired type) and the guest can pay for the room.|
|Post-condition||The guest will have been allocated to a room for the period identified in the reservation and a bill will have been opened for the duration of the stay.|
|Assumptions||The guest is already known to the hotel's software system. The hotel is confident that the guest can pay. For example, the guest has a valid credit card.|
|Main success scenario|
|1||The guest provides a reservation reference number to the receptionist.|
|2||The receptionist uses the reference number to find the reservation.|
|3||The receptionist states the details of the room type and the duration of the stay recorded in the reservation.|
|4||The guest confirms the details of the room type and the duration of the stay.|
|5||The receptionist allocates a room to the guest.|
|6||The receptionist opens a bill for the guest. (It could be that there is a separate billing application, which must be notified upon check in.)|
|7||The receptionist issues a key to the guest.|
Possible exceptions include:
At step 1: The guest has forgotten or mislaid the reservation reference number.
At step 5: An appropriate room is not available.
What are the tasks involved in preparing a use case diagram?
For each use case diagram:
define the context for the model by identifying the actors involved in the aspect of the system in question;
analyse the behaviour that each actor expects from the proposed system and identify the use cases (as units of functionality within the overall requirements);
identify the common behaviour that may be reused by other actors and the variations on common behaviour (the stereotypes «include» and «extend»);
draw a model that shows the use cases, the actors and the relationships between them;
annotate the use cases as you learn more about the requirements.
For large projects, you will need to record separately any constraints that affect more than one use case diagram. One way is to produce a use case model at a higher level of abstraction.
Redraw Figure 6, taking into account the information contained in Figures 7 or 8 (all figures reproduced below), to show common tasks and any extensions to the main success scenario.
Do not show the log-on use case, described in Figure 7 or 8.
Our solution is given in Figure 9, below.
When a guest checks in, we have identified two components: identify reservation and check for available rooms. We have also added a note to say that at some later point, we may decide to replace the check for available rooms use case.
When a guest checks out, we can identify at least one component: prepare bill. A bill is assumed to exist because the check in guest use case includes open new bill for the guest. This is something for the analyst to check in discussions with the users. We shall also assume that the records of payments made by guests are held separately, which is a typical accounting procedure. Hence we have identified a new actor called AccountsSystem that communicates with open new bill and prepare bill.
Since a room must be cleaned after a guest has checked out, we have identified a use case named request room cleaning. This is the kind of detail that you are likely to discover as you find out more about the problem domain.
Undoubtedly, your diagram will differ in some aspects from Figure 9, but you should be able to justify your choices. You should have used «extend» to show variant behaviour and «include» to show the potential reuse of components. We have deliberately added enough new use cases to show how easy it is for use case diagrams to become quite complicated. Such complex use case diagrams are unlikely to be shown to the intended users; they are intended for the development team.
As you learn more about a problem domain, there are a number of choices to be made. You need to consider the use of the «extend» stereotype to handle the variant behaviour or extensions. At the same time, you can identify components that perform common tasks that might be used in more than one use case by applying the «include» stereotype.
A typical lending library keeps a stock of books for the use of its members. Each member can take out a number of books, up to a certain limit. After a given period of time, the library expects members to return the books that they have on loan.
When borrowing books members are expected to hand their chosen books to the librarian, who records each new loan before issuing the books to the member. When a book is on loan to a member, it is associated with that member: possession of the book passes from the library to the member for a defined time period. The normal loan period for each book is two weeks. If the member fails to bring the book back on or before the due date, the library imposes a fine.
In a proposed new system, anyone should be able to browse the stock of books held in the library, but only a member will be able to reserve a book.
Draw a simple use case diagram for the proposed system and identify the constraints or assumptions that you make. (For the moment, ignore the issue of fines because you would have to find out about the library's rules before including them.)
A good first step is to establish the context for the proposed system by identifying the actors that surround it. When you have identified the actors, you can investigate the behaviour that each one will expect from the proposed system, which will eventually form the use cases for your model.
Your task is to determine the roles that people will adopt in order to use the proposed system. In general, the customer (the person who is buying the new system) will have some say in who is a legitimate user. In this problem domain, the library owns the books. One of its employees, a librarian, is responsible for issuing books to a member. Typically, a librarian will also act on the member's behalf when recording a new loan. Hence we expect the librarian to be a key user of the new system.
Browsing through the library's catalogue is a common activity performed by both members and librarians. As a catalogue is only a kind of list that shows what the library offers for loan, it can be read by just about anyone – non-members are also to be allowed to browse the catalogue.
There appear to be two scenarios related to the activity of reservation. In the first, a member might want to borrow a specific book, but finds that all the available copies are out on loan. In the second, a member might want to make sure that at least one copy is available in order to avoid a wasted trip to the library.
We conclude that there are three basic actors:
What is missing from the given description of the system is any indication of how people join the library and become members. We have been told that there is a possible fine for overdue books, but is there a fee to join the library? Do prospective members have to prove their identity? How do members prove their membership?
Someone, a librarian we presume, will be expected to make sure that the catalogue reflects the actual stock held at the library. So, we have identified a corresponding use case for later elaboration.
Our solution includes six basic use cases for the library software system:
issue copy of book;
return copy of book;
look through catalogue;
enrol new member.
Figure 10 shows a possible use case diagram for the proposed system. You may have used different names on your diagram and you may have identified more or less than six use cases. There is no one correct solution; there are many possibilities. You may have defined use cases that combine two or more of our use cases, but in doing this it is likely that you would have assumed knowledge of the internal structure of the proposed system. In a use case diagram, you should identify only the behaviour that will bring some discernible value to the actors.
Finally, you should have included some notes with both the diagram and the elements in it. For example, Figure 10 shows a note with the issue copy of book use case indicating the loan period. This is an excellent way to record constraints on the functional requirements.
Another use of a note is to indicate something that needs further attention or revision. Figure 10 shows that both members and librarians are associated with reserving books. A note records the fact that librarians can reserve books on behalf of members.
At some future point, once you have learned more about the library, you will need to revise the use case diagram. In reaching your answer, you might have gone through several iterations. This is to be expected. You should focus on getting a useful result. A rough diagram that is useful is better than a pretty one that is not!