4.2.2 Use cases
The DVD Library System will provide support to the library by enabling the library staff to do the following:
-
A: Get Number Available. The staff member identifies the film. The system displays the number of copies available.
-
B: List Films. The staff member identifies the member. The system displays a list of the film titles and return dates for each DVD that the member has on loan.
-
C: Borrow DVD. The staff member identifies the DVD and the member who is borrowing it. The system records the fact that this copy of the film is no longer available for loan, that it is on loan to the member identified, and the date on which it was borrowed.
-
D: Return DVD. The staff member identifies the DVD. The system records the fact that this copy of the film is now available for loan and that it is no longer on loan to the member who returned it.
Concentrating on the nouns which represent classes allows us to disregard relationships that involve other aspects of the system, such as attributes, general behaviour and user interface, or entities outside the scope of the system. Here are some examples of the sorts of thing that can be ruled out:
-
relationships involving classes and their attributes, e.g. ‘films have title’;
-
relationships describing the behaviour of the system, e.g. ‘system displays number of copies';
-
Relationships involving entities outside the scope of the system, e.g. ‘library holds DVDs’, ‘staff member identifies member’.
Remembering that ‘copy’ is a synonym for ‘DVD’, underlined phrases such as
-
DVDs of a number of films
-
copies of each film
suggest an association between and
representing the fact that a DVD is a copy of a film.
The situation involving members, DVDs and loans is a little more complicated. Here are some of the relevant phrases.
-
library member can borrow … DVD
-
library member returns … DVD
-
copy … is on loan to the member
These might initially appear to indicate an association between and
, as in the following class diagram.

Figure 10 Possible association between and
.
However, the dates on which a loan (or borrowing) is issued and is due for return also need to be modelled, and in this course associations do not have attributes. This is why we decided to introduce a class. Returning to the phrases above Figure 10, you can see that both members and DVDs (copies) are associated with loans: a loan is to a member and consists of a DVD. So we need two additional associations, giving us three in all:
-
between
and
-
between
and
-
between
and
These associations are illustrated in the class diagram in Figure 11.

The phrases linking entities which correspond to the classes often do more than just suggest the existence of an association; for example, phrases like ‘no member can have more than six DVDs on loan at once’ give us information about the number of links that are possible between an object of one class and objects of an associated class at any given time. We will return to this in the next subsection.
The next activity asks you to apply your new skills of identifying associations to the Hospital System.
The requirements document for the Hospital System is set out in the PDF document below. You will need to refer to this in order to complete Activity 7.
Click the link below to open Hospital requirements
Requirements [Tip: hold Ctrl and click a link to open it in a new tab. (Hide tip)]
Activity 7
Conduct a textual analysis of the requirements document for the Hospital System and draw up a list of possible associations. Remember that you are only looking for likely associations that involve the conceptual classes that have been identified:
,
,
,
,
and
. (You might want to refer back to Self-assessment question 2 in Subsection 3.4, where several of the required associations have already been identified).
Discussion
Our list of associations is as follows. In each case we have added, in parentheses, a quote from the requirements document which supports the need for this association.
-
between
and
(’… wards, each of which may… have on it one or more patients’)
-
between
and
(‘doctors … are organised into teams’)
-
between
and
(‘Each team is headed by a consultant doctor’)
-
between
and
(‘patient… is under the care of … team’)
-
between
and
(‘consultant … is responsible for… patient’)
-
between
and
(‘A patient may be treated by … doctors’)
The accompanying phrases indicate that all these associations appear to represent significant connections between entities in the system domain. But as with other aspects of the analysis process, identifying associations is not an exact science, so do not worry if your list was not the same as ours. At the very least, some of the names you have chosen will probably differ (though they should still be meaningful).
It is now possible to produce a class diagram (Figure 12) showing the set of classes and associations identified for modelling the Hospital System requirements. The diagram is not yet complete, as it still requires some additional items of information.
