3.1 Terminology and notation
In this section, you will learn ways of using a requirements document as the basis for identifying the conceptual classes needed to represent entities from the system domain.
First, though, we will present some terms and notation associated with the process of analysing the requirements document. Several of these will be familiar to you from your knowledge of software implementation, although here they will be used in a slightly different context, to describe conceptual entities in the system domain.
A class models a category of real-world entities from the system domain. Although these may be tangible real-world ‘things’, they may also be intangible things such as events, roles and organisational units. Whether the entities are tangible or not, the modelling elements that represent them are referred to as objects.
Objects of a particular class may have properties called attributes, corresponding to properties of their real-world equivalents. For example, an object representing a car entity may have an attribute colour that corresponds to the colour property of a car. (Note that, since objects of a particular class all have the same attributes, we also say that the class has those attributes.)
At any given time an attribute of an object has a value; that is, specific information that the object holds in respect of that attribute. For example, the colour red..
Objects may also have links to one or more other objects, representing connections between real-world entities. If objects of one class can be linked to objects of another class, there is an association between the classes.
Here is an example. Imagine a very simple system domain, where all we want to do is record information about a number of vehicles and their drivers, as follows:
the number of wheels each vehicle has, and its colour;
the name of each driver;
the driver who drives a particular vehicle or vehicles.
In modelling this system domain there are two classes, vehicle and driver.Vehicle has two attributes, number of wheels and colour.Driver has one attribute. . If a particular driver drives a particular vehicle, the corresponding objects are linked. The classes drivers and vehicles are associated, because objects of the two classes may be linked.
The UML provides notation for representing classes and associations using class diagrams, and objects and links using object diagrams. There they were being used to show software objects – in other words instances of software classes – but in this course we will use them to represent entities in the system domain.
The class diagram in Figure 2 shows the two classes vehicles drivers, their respective attributes, and the association between them, which we have called drives.
The inclusion of attribute names in the classes which make up a class diagram is optional. In this course we will henceforth leave them out and instead, as you will see, include them in textual class descriptions.
You might think that the name in Figure 2 implies that the association has a direction (i.e. a driver drives a vehicle), but it does not. We could equally well have called the association 'is driven by', instead (i.e. a vehicle is driven by a driver).
Figure 3 is an object diagram. It shows particular objects of the two classes shown in Figure 2 and the links between them that are instances of the association drives.
In this example an imaginary driver is represented by an object identified as driver 4. who drives vehicles represented by objects identified as vehicle 4. We have also invented some values for the attributes.
It is often, but not always, the case that the attributes identified at this stage are later implemented as instance variables, but note that, at the conceptual modelling stage, no assumption is made as to whether attribute values will eventually be implemented in the software by strings, integers or any other type. Consequently, the value of the name attribute for the object dirver 4 is not enclosed in quote marks as in Mr Jones , since this would imply that it was to be implemented by a string.
The links in Figure 3 are conceptual links, and at this stage no conclusions can be drawn about whether objects ‘know’ about vehicles, objects, objects ‘know’ about driver objects, or both these things. In fact, for all that is known, neither might apply! The conceptual links just mean that the real-world entities represented by the objects are related in some way. Only when deciding how the system will perform its tasks (i.e. during dynamic modelling), will it be possible to consider how the software objects may need to interact,
There is an important relationship between the kinds of diagram in Figures 2 and 3. The first – the class diagram – is general, and the second – the object diagram – is specific. A class diagram, as depicted in Figure 2, represents all the objects of the classes shown, and the association represents all the links between objects of the two classes. The object diagram in Figure 3 depicts particular objects and the particular links between them.
When you go from the general to the specific like this, you refer to the specific cases as instances of the general category. Thus an object is an instance of a class, and in exactly the same way a link is an instance of an association.
This will sound very familiar from programming – after all, you already know that classes have instances – but remember that we are not talking about software yet. At the moment we are still discussing categories and entities from the system domain.
The next subsection takes forward the idea of a class diagram. We begin by examining in more detail how to identify classes, attributes and associations from a requirements document.