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

3.3.2 Identifying additional classes from the use cases

To finalise the above list, it is necessary to analyse the section of the requirements document dealing with the use cases of the system, and to apply the same guidelines and criteria for rejection. This may identify the need for additional classes, or it may provide information that enables us to eliminate more classes from our existing list.

Having underlined all the nouns and noun phrases in the Use cases section of the requirements document, eliminated classes already identified, and applied the rejection guidelines, we believe there are no additional classes. You may want to convince yourself of this by reading carefully through the Use cases section.

However, in our view, analysing the Use cases section of the requirements document allows us to replace two of the candidate classes by a single class, and reject one further class.

  • Male and female wards. We initially retained these as potentially giving rise to separate classes because we could not be sure that the two types of ward played a similar role in the system. However, the Use cases section of the requirements document makes clear that the two types of ward differ only in the sex of the patients that can be allocated to them. These classes can therefore be rejected in favour of a single class modelling wards with an attribute to denote the sex of the patients on the ward. (Note that in the similar case of junior doctor and consultant doctor, both classes are retained because there are differences in the role that each plays in the system domain.)

  • Care. The care of a patient, as described in the requirements document, is significant only in respect of which team provides that care; the description identifies no specific functionality or attributes with respect to the care itself. We conclude that (at this point) there is no need for a class modelling care, and that the care of a patient by a team can be modelled as a link between the relevant and objects.

This leaves the following list of conceptual classes:

Notice that these classes, now accepted as conceptual classes, are in the special font for representing conceptual classes.

M256_1

Take your learning further371

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 courses372.

If you are new to university level study, we offer two introductory routes to our qualifications. Find out Where to take your learning next?373 You could either choose to start with an Access courses374or an open box module, which allows you to count your previous learning towards an Open University qualification.

Not ready for University study then browse over 1000 free courses on OpenLearn375 and sign up to our newsletter376 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