Page 180 -

DOMAIN MODELING OF OBJECT-ORIENTED INFORMATION SYSTEMS 165
Roles

The following advice is given:

The name of a class should reflect its intrinsic nature and not a role that it plays in an as-
sociation. For example, Owner would be a poor name for a class in a car manufacturer’s
database. What if a list of drivers is added later? What about persons who lease cars? The
proper class is Person (or possibly Customer), which assumes various different roles, such
as owner, driver, and lessee. (Rumbaugh et al., 1990, p. 155)

But in practice, we do model Owner, Driver, or Lessee as classes, most likely as subclasses of
Person, or BusinessEntity (because an owner can be a company). So what can really help us to
decide whether a particular name represents a role rather than a class?
From the fact-based perspective: We do not need to consider whether or not a name represents
a role. We need to be concerned only with whether the name would appear in some fact type and
how it is identified. Moreover, the technique of subtype analysis (which is done in terms of fact
types [see Halpin, 2001] would take care of the case where a certain object appears to play dif-
ferent roles.

Implementation Constructs

Further explanation is given as follows:

Constructs extraneous to the real world should be eliminated from the analysis model. They
may be needed later during design, but not now. For example, CPU, subroutine, process,
algorithm, and interrupt are implementation constructs for most applications [and should
be excluded from the analysis model]. . . . (Rumbaugh et al., 1990, p. 155)

From the fact-based point of view: Nouns that represent implementation constructs (CPU, sub-
routine, etc.), though they may appear in the problem statement, will not appear in any fact type
and therefore will be automatically excluded from the domain model.
Note: Another commonly given piece of advice concerns the kinds of things we may be look-
ing for as potential candidates for domain classes. In Bennett, McRobb, and Farmer (2002, p.
184), for example, we are advised to look for the following kinds of things: (a) People (e.g., Mr.
Smith); (b) Organization (e.g., Jones & Co.); (c) Structures (e.g., teams, projects); (d) Physical
things (e.g., car, truck); (e) Abstractions of people (e.g., employee, supervisor); (f) Abstractions
of physical things (e.g., vehicle, goods); (g) Conceptual things (e.g., project, qualification); (h)
Enduring relationships (e.g., sale, contract). But it can easily be seen that this kind of advice
has quite limited use. After all, a concept such as “judging panel,” which fits really well into the
category of “structure,” is rejected in the analysis of the Gymnastics case study. Similarly, it is
also the case for the rejected concept of “contest,” which fits well into the category of “enduring
relationship.” Clearly, the categories enumerated above can be used to classify the kinds of things
that a concept (or a noun) may fall into, but that “classifying” ability cannot be a means of telling
us which concept (or noun) should or should not be kept as candidate domain classes. As a mat-
ter of fact, note that most nouns, regardless of whether or not they can be candidates for classes,
would belong to one or more of the suggested categories.