Models and modelling
Models and modelling

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

6.3 Describing use cases

To understand the work, you need a good idea of what each use case means. To get a feel for what this might entail, look again at Figure 3 (reproduced below) which shows a simple use case model for a hotel chain reservation system. Note that Figure 3 is not intended to be an exhaustive model of the hotel domain; the scope of the problem to be solved is confined to reservations and the processes of checking in and out.

Figure 3
Figure 3 A use case model for a system for checking in and out of a hotel

What do the use cases make reservation, check in guest and check out guest mean? No doubt, using your own experience of reserving rooms at hotels, the names of the use cases are quite indicative of what they represent. However, you should never rely on intuition or personal experience but rather create a description of the use cases that you and the stakeholders can agree upon. For example, suppose that the following is a description of the check in guest use case (for a particularly simple system).

Upon arrival at a hotel, a guest provides the reference number for his or her reservation to the hotel's receptionist, who uses it to find the details of that reservation so that each guest can confirm them. The receptionist allocates an appropriate room to that guest and opens a bill for the duration of the stay. The receptionist issues a key for the room.

Having read this description, you are probably thinking of all the deficiencies it contains. This is just what should happen: you need to check with the receptionist to clarify that the description contains all the necessary information. We shall not pursue this line of thought further now because we want to draw your attention to the following observations about the requirements of the check in guest use case.

There is a condition, known as a pre-condition, that must hold before a room can be allocated to a guest. It is as follows.

There must be a reservation for the guest and there must be at least one room available (of the desired type) and the hotel must be confident that the guest is able to pay for the room.

There is another condition, known as a post-condition, that must hold after a room has been allocated to a guest. It is as follows.

The guest will have been allocated to a room for the period identified in the reservation; the room will have been identified as being in use for a specific period and a bill will have been opened for the duration of the stay.

In other words, we have captured the meaning of check in guest in terms of two statements: one that must be true before the use case can be carried out – the precondition, and one that must be true once the use case has been completed – the postcondition. At some later point, the developer must decide how these conditions can be met as part of the design activity.

The advantage of describing a use case in terms of a pre-condition and a post-condition is that, when you go on to elaborate the use case in more detail, that is, to describe its components, you know that the components must also satisfy these same conditions. For example, it is no use if one of the components ignores the fact that there must be a vacant room on the dates requested and allows the reservation to go ahead, or if a component fails to indicate that the room, once booked, cannot be booked again until it becomes free.

Notice that such a specification does not say how a reservation must be performed; simply what conditions should be satisfied. The advantage of thinking in this way is that it avoids all issues to do with software and leaves the developers (who may specialise in design and programming) to choose an appropriate implementation, which is their field of expertise.

The two descriptions: the first, which is entirely prose, and the second, which is more formal using pre- and post-conditions, are both equivalent descriptions (specifications) of the requirements represented by the check in guest use case.

When something is described using natural language we often say that it is an informal description. When we use a more structured approach to descriptions, such as the way in which we described the pre- and post-conditions for the check in guest use case, we say that we are being more formal. The ultimate level of formality, when we want to be as precise and unambiguous as possible, is the use of mathematics. There are times when the use of mathematics is essential; typically when dealing with software that controls situations which, if incorrect, can lead to death (for example, aircraft and nuclear power stations). However, you would not want to be too formal in most situations otherwise stakeholders are very unlikely to understand your requirements.

Take your learning further

Making the decision to study can be a big step, which is why you'll want a trusted University. The Open University has 50 years’ experience delivering flexible learning and 170,000 students are studying with us right now. Take a look at all Open University courses.

If you are new to University-level study, we offer two introductory routes to our qualifications. You could either choose to start with an Access module, or a module which allows you to count your previous learning towards an Open University qualification. Read our guide on Where to take your learning next for more information.

Not ready for formal University study? Then browse over 1000 free courses on OpenLearn and sign up to our newsletter to hear about new free courses as they are released.

Every year, thousands of students decide to study with The Open University. With over 120 qualifications, we’ve got the right course for you.

Request an Open University prospectus371