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.5 Abstract classes

Activity 5

Read the following extract from the requirements for the Hospital System:

Each team is headed by a consultant doctor who is the only consultant doctor in the team; the rest of the team are all junior doctors, at least one of whom must be at grade 1. Each doctor is in exactly one team.

What can you infer from this extract about objects?


Because every doctor is in a team, and the only doctors in a team apart from the consultant are junior doctors, you can infer that each object is in fact an instance of either or . In effect, there are no objects as such

A class whose ‘instances’ are all actually instances of one of its subclasses is called an abstract class. (The word ‘abstract’ is commonly used to refer to something which is intangible or not concrete.) You may already have met the concept of an abstract software class in your study of object-oriented programming. Java does not allow you to create any instances of abstract classes, since every ‘instance of the abstract class’ is actually an instance of one of its subclasses. Do not confuse an abstract class with a class representing ‘abstract entities’, which you met at the end of SubSection 3.2. An abstract class is a class which conceptually has no instances of its own, but only instances of its subclasses. A class representing abstract entities may have instances, but instances which represent intangible entities like novels.

In this course we denote an abstract class in a class diagram by adding to the box representing the class, as shown in Figure 6. The <<…≫>> notation in the UML is known as a stereotype, which is a label giving additional information about some component of a model.

Figure 6
Figure 6 An abstract class with two subclasses

By no means all parent classes are abstract. If a class is not shown as , it is assumed to be a concrete class, i.e. it is intended that the class may have instances that are not instances of any of its subclasses.

Activity 6

Consider the three following excerpts from requirements documents. In each case decide whether any classes appear to be involved in a generalisation relationship. Where you decide that a generalisation relationship exists:

  • make a sketch of the generalisation relationship, in either of the styles shown in Figure 5. Your sketch should include a name for each class and should indicate which of the classes, if any, are abstract;

  • suggest a set of attributes for each class involved in the generalisation relationship.

  • (a) A department store has a number of departments, each of which is headed by a manager, whose salary depends on their grade. Sales assistants are assigned to a particular department. For security purposes each sales assistant is provided with a personal code, which they need to enter into the till when they make a sale. Department managers do not conduct sales transactions, though they sometimes advise customers on products. All staff, including department managers and sales assistants, have unique employee numbers.

  • (b) A car-hire firm rents out cars and vans. The firm identifies the vehicles in its fleet by their registration numbers. Customers book rental vehicles via the company's website. When booking a car the customer needs to select a type of car, e.g. ‘family saloon’ or ‘luxury model’, whereas when booking a van the customer needs to specify the load-carrying capacity, e.g. ‘800 kg’ or ‘1.5 tonnes’.

  • (c) A university records details of all its lecturers and students, including their postal and email addresses. All lecturers must teach at least one module each year, and may not teach more than four. Students may choose to study up to six modules each year.


(a) Here is our diagram.

Figure 7
Figure 7 Generalisation relationship representing staff in the department store
  • Figure 7 indicates a generalisation relationship with as the parent class, and and as its child classes. The final sentence in the extract implies that there are more categories of staff than just department managers and sales assistants. We do not know anything about these categories other than that they have an attribute, but it is reasonable to assume that they have some significance in the system domain. From the information provided, they can be modelled by the class, which should therefore be a concrete class.

    Suitable attributes for the three classes would be:

    • For :

    • For : ,

    • For :

(b) Here is our diagram.

Figure 8
Figure 8 Generalisation relationship representing vehicles in the car-hire firm
  • This description indicates a generalisation relationship with as the parent class, and and as child classes. The extract implies that all vehicles in the fleet are either cars or vans, so can be designated as an abstract class.

    Suitable attributes are as follows:

    • For :

    • For :

    • For :

  • (c) Conceptually, there is no generalisation relationship between and ; a student is not ‘a kind of’ lecturer, nor is a lecturer ‘a kind of’ student. The attributes of lecturers and students, as described in the extract, are identical, and both have a relationship with modules (though this relationship is not the same in each case – lecturers teach modules and students study them). However, the key point is that, conceptually, one class is not a generalisation of the other.

    Students and lecturers do have some things in common, and this might have led you to introduce a parent class for and classes, called something like . The reason why we consider this to be an inappropriate model at this stage is explained below.

In the Hospital System we noted that both and are subclasses of the abstract class . Since is an abstract class, it will not have any instances, so it might be thought that we could do without a class. The key reason why it should be retained is that it models a significant category of entities in the system domain.

The requirements document has significant things to say about doctors in general, for example:

Each doctor is in exactly one team.


A patient may be treated by any number of doctors but they must all be in the team that cares for the patient. A doctor can treat any number of patients.

As the aim is to model the system domain as closely as possible, it is entirely appropriate that a class should be included. In contrast, the description of aspects of a university in Activity 6(c) above says nothing about ‘members of the university’, a category which would include students and lecturers. So although students and lecturers have some shared attributes, there is no evidence to indicate that a grouping of these two categories is of significance to the system domain, and therefore no good reason for including a class as a parent class of and .

As a further example, consider the system for booking badminton and squash courts described in Self-assessment question 1 (at the end of SubSection 2.3). Here is part of the system description:

A computer system is required for booking badminton and squash courts in a sports centre …

Suppose that classes identified as necessary for modelling the system domain include , , and .

Although only badminton courts and squash courts are explicitly referred to, these two entities are clearly kinds of court, and the description indicates that they have a shared significance in the system domain – the fact that they are bookable. It could therefore be appropriate to include an abstract parent class, .


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