Page 169 -

154 NGUYEN AND DILLON
easily see that a team (which is an entity that participates in a meet) should be identified by a
meet name, a competition type name, and the club name. With this reference scheme, the current
concept of “team” can be clearly distinguished from other possible concepts of “team” that may
also be relevant to this application domain: other concepts of “team,” if applicable, must have
different reference schemes. Thus, in the practice of fact-based analysis, the problem of mutating
concepts is resolved as a matter of routine: In forming the fact types, because we are required to
specify the reference schemes explicitly, all the issues related to mutating concepts are naturally
resolved. The reference schemes clearly identify the concept that a particular term stands for and
clearly distinguish it from other concepts that may be expressed by the same term.

Identifying Fact Types on the Basis of Use Cases

We now consider the practical problem of how to efficiently identify fact types for large-scale
information systems. In theory, we can identify fact types in any order. But in practice, especially
for large-scale information systems, in order for the process to be carried out effectively, we need
some strategy to divide and conquer. Our suggested divide-and-conquer strategy is based on a
kind of ordering of use cases.
Theoretical considerations and experience have convinced us that the fact-identifying process
can be carried out most effectively in the order of “data entry dependency.” Informally speaking,
this is the order in which the data are stored in the system. This order entails a certain amount of
“existence dependency.” For example, we must first create a particular meet before we can enter
information about a competition that belongs to the meet (and this is what we mean by “data entry
dependency”). So quite naturally, in identifying fact types, it makes sense—and it is much more
efficient—to proceed in that same order; that is, we should identify the fact types related to meets
before those related to competitions. This leads to the technique of considering use cases based
on their order of dependency.
For the Gymnastics System, the fact types can be effectively identified by considering use
cases in the following order: (1) Add a club, (2) Enter a gymnast, (3) Enter a competition type,
(4) Enter an event type, (5) Enter a judge, (6) Create a meet, (7) Enter a competition (for a meet),
(8) Enter an event (for a competition), (9) Enter judges for events, (10) Register a team (for a
competition), and (11) Enter a score.
Note that for the purpose at hand, which is to identify fact types, it is sufficient in most cases
to consider only those use cases that cause data to be added to the information base. The idea is
to perceive a sequence of use cases or events, such as the one listed above, that can generate all
the relevant fact types (except possibly for the derived fact types). Moreover, while identifying
fact types generated by an event, we can also identify the constraints applied to these fact types. In
the context of use cases, fact types and constraints are easier to identify (because of the temporary
focus on specific use cases). The use cases can also be used to organize the recording of the fact
types for documentation purposes.
The application of the suggested process for the Gymnastics case study is outlined below.

Fact Types About Clubs and Gymnasts

Add a club. When a club is formed and registered, the following fact types are generated:

Club (name) . . . has Phone (code) . . .
Club (name) . . . is at Address (text) . . .