3.6 Class or attribute?
In determining suitable classes and attributes for the Hospital System, this section has presented a number of guidelines and techniques as if applying these were a fairly straightforward process:
conduct a textual analysis;
apply the rejection guidelines;
complement this by considering categories of likely classes;
identify the attributes;
identify any generalisation relationships.
In practice, arriving at a set of appropriate classes and attributes is rarely so straightforward. Rather than working with a short, relatively simple description, you may find that a requirements document describes a system domain with much greater complexity of detail and meaning. One issue that arises time and time again is whether something is an entity or the property of an entity. Should it be modelled as a class or an attribute?
This difficulty can be illustrated with reference to a couple of examples.
Suppose that during the requirements specification phase you had asked the Chief Physician what sort of detail is needed about doctors, and that she had replied:
As well as a name, a doctor has a title; also, a record is kept of the institution where he or she qualified.
It seems fairly obvious that title is just another attribute of , but how would you model the reference to institution? Would you introduce an class or would it be sufficient, for example, to add an attribute to the class? This depends on what sort of information about institutions needs to be recorded. You would need to question the Chief Physician further. Suppose that in response to further questioning she added:
I need to know how many of my junior doctors qualified at a particular institution, and the name of the Chief Physician at that institution.
This indicates that is significant in its own right – it has properties – and will need to be included as a class in the model. On the other hand, her reply might have been:
Just the name of the institution will do. That will enable me to research any further details.
In this case an attribute in would be all that was needed.
Now let's revisit the vehicle hire example in Activity 6(b). The description contains the following statement:
When booking a car the customer needs to select a type of car, e.g. ‘family saloon’ or ‘luxury model’ …
From this information alone, it was reasonable to model as an attribute of , but what you know about car hire might lead you to question whether the type of car might have a significance in its own right. Wouldn't the system need to record the properties of each type of car, such as its number of seats or hire cost? If so, then might be a valid conceptual class. As an analyst you would need to question the client further about this.
One of the strengths of an object-oriented development approach such as the one adopted in this course is that the activity of building a conceptual model forces the developer to examine the meaning of statements about the system domain. This iterative questioning is also indicative of a good analytical approach in general – an active exploration of meaning rather than a passive acceptance of ‘requirements’.
Having identified an initial set of classes and attributes for the Hospital System (and which of these classes might be generalisations of others, and/or abstract), it is now possible to move on and consider the associations between the classes. However, it is important to bear in mind that the process of developing a conceptual model is an iterative one, and that this set of conceptual classes is still provisional. It may be that the analysis of the associations between classes will require them to be revised.