Page 179 -

164 NGUYEN AND DILLON
Names that primarily describe individual objects should be restated as attributes. For ex-
ample, name, age, weight, and address are usually attributes. If the independent existence
of a property is important, then make it a class, not an attribute. For example, an employee’s
room would be a class in an application to reassign rooms after a reorganization. (Rumbaugh
et al., 1990, p. 155)

Should “independent existence” be used as a basic criterion to distinguish between attributes
and classes? If something, let us call it A, cannot exist without something else, let us call it B,
then should we make A an attribute of B?—Not necessarily! We frequently have objects whose
existence requires the existence of another kind of object (e.g., copies of books in a library cannot
exist without the abstract books, often identified by their ISBN).
So really, how can we decide whether a concept should be an attribute or a class? Let us look
at this issue from the fact-based approach. Consider, for example, the case where we have fact
of type:

A Person (name) . . . was born in a City (name) . . .

Should City be an attribute? The answer is: it depends! If City is involved in no other fact type,
then it is reasonable to answer “yes.” However, if it is also involved in other fact types such as
City (name) . . . has Postcode (code) . . .
City (name) . . . has Population (nr+) . . .

then it is no longer feasible to represent City as an attribute. Therefore, whether or not a concept
should be regarded as an object depends largely on the relationships it has with other concepts.
More precisely, the issue of whether a concept should be represented as an object or an attribute
can be resolved only by considering (explicitly or implicitly) (1) all the fact types in which the
concept is involved, and (2) whether or not some of these fact types contain other information
about the concept.

Operations
The following advice is given:

If a name describes an operation that is applied to objects and not manipulated in its own
right, then it is not a class. For example, a telephone call is a sequence of actions involving
a caller and a telephone network. If we are simply building telephones, then Call is part of
the dynamic model and not a class. [ . . . ] An operation that has features of its own should
be modeled as a class, however. For example, in a billing system for telephone calls a Call
would be an important class with attributes such as date, time, and destination. (Rumbaugh
et al., 1990, p. 155)

Clearly, from the fact-based point of view, the above advice is an obvious consequence of the
following simpler and more general guideline: We do not need to consider whether or not a name
is an operation. If a concept, irrespective of whether or not it normally indicates some sort of
operation, carries information to be maintained, that is, it appears in some fact type, then include
it in the domain model. Otherwise, do not.