Page 178 -

DOMAIN MODELING OF OBJECT-ORIENTED INFORMATION SYSTEMS 163
Redundant Classes

What is a redundant class? The following explanation is given:
If two classes express the same information, the most descriptive name should be kept. For
example, although customer might describe a person taking an airline flight, passenger is
more descriptive. (Rumbaugh et al., 1990, p. 153)
But in general, how do we know that two terms express the same concept? For example, in
the Gymnastics System, how do we know whether or not “competitor” and “member” of a team
refer to the same kind of objects? To find out, we need to carefully examine how these terms are
actually used by the stakeholders in the context of the application domain. But as to how we are
to carry out this examination, the text analysis approach seems to leave it entirely to the initiative
of the analyst.
The fact-based approach offers more definite criteria for discrimination. A concept (or an ORM
entity type) must have a reference scheme (how we identify an instance of this entity type), and
it must participate in a number of fact types. With that in mind, we can arrive at the following
clearer, and more workable, characterization: Two terms represent the same concept/class if their
instances have the same reference scheme and participate in the same set of fact types.
Vague Classes

This point is explained as follows:
A class should be specific. Some tentative classes may have ill-defined boundaries or be too
broad in scope. For example, Recordkeeping provision is vague. In the ATM problem, this
is part of Transaction. In other applications, this might be included in other classes, such as
Stock sales, Telephone calls, or Machine failures. (Rumbaugh et al., 1990, p. 155)

But as before, how do we recognize that a concept is ill-defined or too broad in scope? A few
examples of such classes, as given in the explanation above, will not be of much help when an
analyst faces a “vague” concept (which he or she may not recognize as such) in the analysis of
some particular application domain (with which he or she may not be quite familiar).
From the fact-based perspective, a “vague” concept, such as recordkeeping or recordkeeping
provision, if it is indeed vague, will not appear in a fact type. Why? Because at the very least we
have to ask: how are we going to identify an instance of this concept (its reference scheme)? If
we cannot find a reference scheme, then indeed it is vague or, in the language of the fact-based
approach, it is not a proper entity, and it will not appear in any fact type. On the other hand, if
there is some reference scheme for such a concept, then it may well represent a legitimate class
no matter how strange the term may sound to us. Thus, we have: If a concept is vague (ill-defined,
not representing a valid entity), then it will not appear in any fact type, and therefore will not be
in the domain model.

Attributes

How do we know, or decide, whether or not a concept is an attribute? The following advice is
given: