3.2.4 Guidelines for rejection of candidate classes
Though there are no hard and fast rules, your answers to the following questions should give you a strong indication of whether or not an entity really should be modelled using a class. Although, strictly speaking, it is the category of entity that is modelled by a class, we shall often use the word entity as if it were a category.
Is it a property?
Is it simply a property of some other type of entity in the system domain, or does it contribute to the system domain in its own right? If the former, it is likely to be appropriately modelled by an attribute of a class rather than a class itself.
As you will see below, a good test of whether an entity should be modelled using a class or an attribute is whether it has or does not have properties itself. If it has properties, then it is likely to be appropriately modelled by a class; if not, then it is likely to be appropriately modelled by an attribute.
Some examples of attributes from the DVD Library are:
title – an attribute of a film;
identifying number – an attribute of a DVD;
membership number – an attribute of a member;
member's name – another attribute of a member;
number of copies available – an attribute of film (but see further discussion below);
return date – an attribute of a loan;
date on which it was borrowed – an attribute of a loan.
What about ‘day'? Number of days is also a property of a loan. However, as all loans are of the same duration – three days – there is no need to record this information for each loan. You will see later how this information is taken into account.
Having decided above that ‘number of copies available’ is to be modelled by an attribute of a film, should ‘number of copies’ (that is, the total number of copies of a film, whether on loan or not) also be modelled by an attribute of a film? As you will see below, we believe that it is more appropriate to model ‘number of copies’ in terms of links between films and DVDs.
Does it refer to a behaviour of the system?
Does it name some process or result of a process that the system has to carry out?
In the DVD Library, a ‘list’ (of the film titles and return dates for each DVD) is something that the system needs to produce as part of its behaviour, rather than a category of entities that is significant for the system domain itself.
Something else that could fit into this category is ‘number of copies available’. We have identified DVD (copy) as another candidate class, and the number of copies available is something that the system is required to produce. However, ‘number of copies available’ can also be viewed as an attribute of a film, which is how we have chosen to model it.
Is it outside the scope of the system?
Is it a word or phrase that is used to help describe the general purpose of the system or what it consists of, but that does not actually refer to significant entities in the system domain?
The ‘library’ itself falls into this category. The system will operate in the context of the library, but will not need to represent the library per se. The significant entities are those with which the library is concerned – its members, DVDs etc. You could think of the library as being the boundary of the system domain. Had the system been required to administer a group of libraries, then ‘library’ might have given rise to a class, since it would probably be important to know, for example, which copy of a film was held at which library.
Things such as ‘user’ or, in the case of the DVD library, ‘library staff, also fall into this category; although they will use the system, they are outside its boundaries. In other words, the system does not need to refer to them.
Does it refer to an aspect of the user interface?
Does it concern the interaction of a user with the system, rather than something that is part of the system itself? There are no such examples in the DVD Library System, since the requirements document does not provide details of the user interface. A more detailed requirements document might include statements such as ‘The librarian enters the unique identifying number of the DVD using a barcode reader.’ In this case ‘barcode reader’ would be rejected as a class, since it refers to an aspect of the user interface.
Does it refer to connections between other significant entities in the system domain?
Such an entity might be more appropriately modelled by an association between two classes rather than a class. For example, it might appear at first sight that an entity ‘loan’ in the DVD Library System could be represented as a link between a member of the library and a DVD that they borrow. However, the DVD Library System requirements indicate the need to record the date on which a DVD is borrowed, and to provide information on when DVDs are due for return. These dates are properties of a loan, so in this case we will model loans using a class, with the two dates as attributes. However, if the entity ‘loan’ had not had properties, then it would have been more appropriate to model it as an association. Criteria for deciding whether an event, such as a loan, should be modelled as a class or an association will be discussed later in the course.
Is it a word or phrase that is used in talking about systems in general, rather than a reference to something in the system domain?
Words such as ‘system’, ‘behaviour’ and ‘requirement’ fall into this category: they do not refer to entities in the system domain.
Is it simply part of a language idiom?
The requirements document may contain words which are just part of general English usage. For example, ‘The system records the fact that this copy of the film is no longer available for loan …’ could equally well have been written as ‘The system records that this copy of the film …’ (i.e. excluding the phrase ‘the fact’), and the sentence ‘The DVD Library holds DVDs of a number of films’ would have meant exactly the same had the phrase ‘a number of’ been omitted.
A number of alternative solutions are possible when categorising and selecting from potential classes. We might, for example, have categorised ‘number of films available’ and ‘list of titles and return dates’ as aspects of the user interface (as this is where they would be displayed).
It may sometimes be the case that an entity in one of the above categories does need to be represented by a class in the core system, or that a decision is made to introduce a class not represented by a noun or noun phrase in the requirements document, or indeed not mentioned in the requirements at all. Furthermore, the same entity may perform more than one role. For example, if library members were able to use the system to reserve and check in DVDs themselves, ‘library member’ would be similar to ‘library staff in this context (and so outside the system boundary), as well as being one of the entities being modelled.
Having applied the guidelines to the entities identified in Activity 1, we are left with the following:
All four of these represent significant entities in the system domain, and none of them duplicates any of the others. They therefore suggest categories of entity that can each be modelled by a different class.