Page 177 -

162 NGUYEN AND DILLON
can supply an exhaustive, or at least nearly so, list of potentially valid candidate classes for the
analysis model? How do we tell whether or not a given problem statement is adequate for this
purpose? And what can we do if it is inadequate?
Another consequence of the first premise is that, unless appropriate tools are used, there would
be problems with scaling up. If the problem statement is written in detail for a large system, there
will be a large number of “good” nouns and a huge number of “bad” ones. The list of candidate
classes could be quite long. The elimination process, being unsystematic, would be quite un-
manageable. As mentioned earlier, linguistic analysis tools could be very useful for dealing with
these problems.
As to the second premise, how effectively can the suggested criteria be applied to eliminate
improper candidate classes? Let us consider the criteria suggested by OMT.
Relevant Classes

What is meant by “relevant”? In Rumbaugh and colleagues (1990) (from which the above proce-
dure is taken), the following explanation is given:

If a class has little or nothing to do with the problem, it should be eliminated. This involves
judgment, because in another context the class could be important. (Rumbaugh et al., 1990,
p. 155)

Thus, the explanation defines “irrelevant” as “having little or nothing to do with the problem.”
But this kind of elaboration offers very little help. Indeed, we can ask, if a concept has little or
nothing to do with the problem, why is it included in the problem statement at all? More impor-
tant—How can we tell if a concept that occurs in the problem statement has little or nothing to
do with a problem?
Let us try to look at this issue from the fact-based point of view. A very important property of
those classes to be included in the domain class model is that they carry information required for
the operation of the enterprise. This is obviously true, for example, for the domain model of the
Gymnastics System. The analysis model has classes such as Club, Gymnast, CompetitionType,
EventType, Judge, Meet, Team, Score, and so on. Each of these classes carries certain information
required for the running of the competitions.
To be clearer on this point, let us consider an application that manages bank accounts. When
we observe what is happening in the real world, we see, for example, that people use automatic
teller machines (ATMs) to carry out banking transactions. Then, should we include ATM in the
domain class model? The answer is: it depends! If we need to keep records of the ATM involved
in the transactions, then the answer is definitely “yes.” But suppose we do not need to do that;
then the answer is “no.” In the latter case, the ATM will play exactly the same role as a desk in a
library, or a screen on a computer terminal. It may or may not be modeled as a control class, but
certainly not as a domain class.
From the fact-based perspective, clearly if a class carries certain information required for the
enterprise’s operation, then it must appear in some fact type. Thus, we have the following char-
acterization for “relevant”: A concept is relevant for the domain model if, and only if, it appears
in at least one elementary fact type.
Thus, “relevant” is linked ultimately to “information.” If a concept represents some sort of
information to be maintained by the system, then it is relevant and it should be included in the
domain model as a class, an attribute, or a relationship.