Modelling object-oriented software – an introduction
Modelling object-oriented software – an introduction

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.

Free course

Modelling object-oriented software – an introduction

5 Modelling events

5.1 Criteria for modelling events

In the discussion of classes earlier in the course, we gave events as one category of ‘thing’ that could be modelled by classes. You saw an example of this in the DVD Library System, where the loan of a DVD by a library member was modelled as a Loan class connected to both the and the classes by associations. You have also seen examples where an event is modelled by an association. For example, we chose to model the treatment of a patient by a doctor in the Hospital System as a association between the and classes.

In this section, you will discover some criteria for deciding whether an event should be modelled as a class or as an association.

Self-assessment question 6

Why did we choose to model the loan of a DVD as a class, but the treatment of a patient as an association?


In the case of the loan event, there were requirements for additional information to be associated with each loan: the date on which the loan was made, and the return date. By modelling ‘loan’ as a class, we were able to model these additional requirements by including appropriate attributes.

In the case of the treatment of a patient, there was no requirement to record or provide any information specific to a treatment, other than the patient and doctor involved. If details of each treatment had been needed, then a class would have been a better choice.

The object diagrams in Figure 20, below, illustrate the examples that were the subject of SAQ 7.

Figure 20
Figure 20 Object diagrams representing loans and treatments

Figure 20(a) shows that is on loan to . If, at some future date, borrowed again, the loan involving these two objects would be recorded by a different object, say .

Figure 20(b) shows only that has treated . We know nothing about that treatment, or indeed whether the doctor has treated the patient more than once. In the solution to Activity 9 in the previous section, we said that it was not possible, with our chosen model, to record multiple treatments of a particular patient, say , by a particular doctor, say . If we needed to do this, we would have chosen to model the treatment of a patient by a doctor as a class, each object of which would be linked to a object and a object. A class diagram and an object diagram for this possibility, showing the treatments of by , are given in Figure 21.

Figure 21 Modelling the treatments of a patient by a doctor with a class

The class diagram (Figure 21(a)) shows that a doctor may provide any number of treatments, and that a patient may receive any number of treatments, but that each treatment involves exactly one doctor and one patient. The class might have attributes to record information such as the date and nature of the treatment, or it might not. The object diagram (Figure 21(b)) shows that this model allows for multiple objects, each involving and .

The two example systems which form the basis of the next two exercises demonstrate circumstances in which events that do not have properties of their own are nevertheless modelled as classes. But before discussing these circumstances, we would like you to familiarise yourselves with the requirements of these two systems by completing their class diagrams. In completing the diagrams you will also reinforce your understanding of some of the ideas introduced in the course so far.

Activity 10

Here is an excerpt from a requirements document for a Goat Breeding System.

A farm needs to record information on the breeding of its goats during the season. The goats are organised into herds, with each goat belonging to a single herd, and a herd containing many goats. There are three sorts of goat: billy-goats (males), nanny-goats (females) and kids (which, since they do not mate in the current season, are not considered to be either billy-goats or nanny-goats). The farm needs to have a record of the mating behaviour of each nanny-goat and billy-goat during a particular season, and of the offspring which result. A billy-goat mates one or more times during the season, but only with nanny-goats that are in its own herd. A nanny-goat mates exactly once per season. A mating may produce several offspring (kids) or none. All kids remain in the same herd as their parents.

The following classes have been identified as appropriate: , , , , and . Notice that the class represents an event involving a nanny-goat, a billy-goat and (possibly) several kids.

Use the above description to identify likely generalisation relationships, associations and multiplicities and draw the class diagram.


Our class diagram is shown in Figure 22.

Figure 22
Figure 22 Class diagram for the GoatBreeding System

You have almost certainly come up with different names for the associations. Incidentally, it's worth noting that there is no reason why you should not use the same name for two different associations – for example, you could have given the association between and the same name as the association between and , say . We have avoided the use of duplicate association names in this course, as this would make our models more difficult to discuss.

We have taken the view that a herd must contain at least two goats to exist.

Note that the class is abstract, as there are no goats per se, only billy-goats, nanny-goats and kids.

Mating is an example of an event that is modelled by a class. We will return to this shortly.

Activity 11

Here is an extract from the requirements for a system used in organising an Open University day school, referred to as the Day School System.

A region of the Open University needs to maintain information about a day school for M256. The day school consists of a number of sessions. Two types of participant, tutors and students, are involved in these sessions. The system must record the name and email address of each participant. Each session is taken by a single tutor, and each tutor must take at least one session, though some of the tutors will take a number of sessions. Students need to register for each session that they wish to attend. A maximum of 20 students can be catered for in each session. Once this limit is reached, no further students may register for that session. Only students who register for at least one session are recorded by the system. At each session a different booklet of exercises is used. Each booklet is written by a number of the tutors taking part in the day school, one of whom must be the tutor who is taking the session that uses the booklet.

The following classes have been identified as appropriate: , , , and .

Use the above description to identify likely generalisation relationships, associations and multiplicities and draw the class diagram.


Our class diagram is shown in Figure 23.

Figure 23
Figure 23 Class diagram for the Day School System

During the period of organisation for the day school it is possible that no student has (yet) registered for a particular session; hence the multiplicity of at the end of .

A session is an example of an event modelled by a class.

In each of Exercises 10 and 11 we chose to model an event as a class – in the Goat Breeding System and in the Day School System. But neither of these events has properties that need to be modelled as attributes.

Activity 12

Study the class diagrams for the Goat Breeding and Day School Systems. Can you identify any similarities in the ways in which the and classes fit into their respective class diagrams?


and each have associations with three distinct classes. is associated with , and ; is associated with , and .

The two systems you have just explored illustrate a common situation – where an event involves three or more types of entity from the system domain. A single mating event in the GoatBreeding System involves a nanny-goat, a billy-goat and the offspring which result from that mating. An association between any two of the participant classes fails to capture this three-way relationship. In this course an event that involves objects from more than two classes will always be modelled by a class, even if there are no properties associated with the event. Contrast this with the modelling of another event in the Day School System, a student registration. This involves only two classes – and . Furthermore, it has no properties of its own that need to be modelled as attributes. Registration is therefore modelled as a association between and .

What is really needed here is an association between three classes, but as associations can involve only two classes, an event class is introduced to link all three classes.


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