Page 164 -

DOMAIN MODELING OF OBJECT-ORIENTED INFORMATION SYSTEMS 149
Figure 9.3 The Scoring of a Competition

Meet: Town Invitational
Date: 12/02/2006
Competition: Women’s Senior Team

Event Scores

Club Beam Vault Bar Floor

Flippers 41.5 40.3 44.6 43.7
Acrobats 42.2 38.5 41.0 40.7
Tumblers 38.4 39.8 42.6 41.3
Jugglers 36.2 41.0 37.4 39.6

Source: Based on Figure 3–4 in White (1994).

Gymnastics System is the entire system, not one object. The project is best named “Gym-
nastics System.” (p. 33)

Comment 2. Few of us, if any, would include the Gymnastics System as a class in the domain
model (though we could argue that it is an object in the application domain). In ORM modeling,
there will be no fact type involving “gymnastic system” as a participating entity. Consequently,
“gymnastic system” will not be part of the domain model. The issue would not arise in the first
place.

Definition, registration, scoring, and record keeping are operations that the system will have
to carry out. These are general functions, not classes. (p. 33)

Comment 3. In ORM modeling, we would not have any fact types that involve terms describing
the system’s functions. Therefore, these terms will automatically be excluded from consideration
for the domain model.

Here is a brief description of a gymnastic league and one of their contests: a league is a
group of clubs that compete against each other. Each team recruits members to participate
in the contests. . . . [Keywords are italicized for subsequent analysis]

“Contests” is a vague word. Certainly contest will be a key abstraction, but a bit farther down
in the statement are several other terms that could be considered as contests. (p. 34)

Comment 4. We may wonder: by what criteria is “contests” a vague word? In fact, this issue is
never revisited. And when the key classes are later listed (p. 38), it is simply not there.