Page 157 -

142 NGUYEN AND DILLON
ficult task. Most business information systems typically present the analyst with a large number
of business-related concepts, complex relationships among business entities, intricate business
rules, and operational procedures, most of which are often not obvious and have to be carefully
unearthed and documented. In such cases, the popular text analysis method, as will be illustrated
in this chapter, may not be able to handle the task effectively. The aim of the chapter is to identify
a number of problems associated with the text analysis approach, and to propose the use of a fact-
based approach, also known as Object-Role Modeling or ORM, as a supporting technique for the
construction of domain models for object-oriented information systems.
The following three sections present a brief review of current approaches to domain modeling;
briefly introduce the basic concepts of ORM; and describe the Gymnastics System case study,
which will be used throughout the chapter. The next section examines in detail a particular domain
modeling process that applies the text analysis approach to the Gymnastics System case study,
and identifies various shortcomings of the text analysis approach in general. We then show how
ORM can be combined with the use case approach to provide a very effective method for the
construction of the domain model. Finally, to provide further insights, we examine the difference
between the text analysis and ORM on a more theoretical basis.

A REVIEW OF APPROACHES TO DOMAIN MODELING

The domain model is made up of the following main elements: classes, relationships (inheritance,
association, and aggregation), attributes (for classes and associations), and methods. Of all of
the elements, classes and relationships are of primary importance. The two most basic issues
are: (1) how are we to discover the relevant classes? and (2) how are we to discover the relevant
relationships? Once these two questions have been resolved, other issues can be more readily
addressed.
As expected, a number of approaches have been suggested to identify classes and relationships.
To help make sense of what seems to be a diversity of approaches, it is useful to observe that they
can be broadly described in terms of two dimensions: perspective and discovery techniques. The
perspective can be top-down, or bottom-up, and the discovery techniques can be text analysis,
collaboration analysis, or fact analysis.
Perspective relates to whether or not we divide the subject matter into various parts and work
on those parts in the process of developing the complete model. Considering that the majority of
methods propose the use of nouns and noun phrases for identifying classes, we may ask: Where are
we to look for these nouns and noun phrases? As stated in Delisle, Barker, and Biski (1999), the
answer varies: in a concise summary of the subject matter (Coad and Yourdon, 1990), in a descrip-
tion of the problem space (Pressman, 1997), in a description of the user requirements (Rumbaugh
et al., 1990), or in descriptions of use cases, scenarios (Whitten, 1998). To make some sense of
all of these answers, let us note that the ultimate source for relevant concepts must be the subject
matter itself—that is, anything that can be uttered about the system at hand. But the practical
source has to be a manageable subset of the ultimate source. Any of the following may be part of
that practical source: a summary description of the subject matter, the transcripts of interviews,
a set of use case descriptions, and so forth. The kind of practical source we use depends on our
perspective. We may adopt a top-down perspective and simultaneously concern ourselves with
the whole system, or we may construct the domain model incrementally from considerations of
parts of the system (e.g., use cases), that is, by pursuing a bottom-up approach.
Let us now consider a sample of methods. George and colleagues (2004, pp. 208–209) suggest
that domain modeling can be done from a top-down or a bottom-up perspective or by using a