Page 158 -

DOMAIN MODELING OF OBJECT-ORIENTED INFORMATION SYSTEMS 143
combination of both. The top-down approach derives the model from an “intimate understanding
of the nature of the business, rather than from any specific information requirements in computer
displays, reports, or business forms.” To help develop a model from this perspective, a number of
key questions are suggested. To identify classes, it is suggested that we ask: “What are the subjects/
objects of business?” “What types of people, places, things, and materials are used or interact in
this business?” “How many instances of each object may exist?” Similar sorts of questions are
suggested for identifying attributes, associations, aggregations, compositions, generalization, and
so on, including integrity rules and security controls. These authors also embrace the bottom-up
approach by “reviewing specific business documents—computer displays, reports, business
forms—handled within the system. These displays, reports, forms can be attached to the relevant
use case.” Thus, this approach can be broadly characterized as being both top-down and bottom-
up in perspective, and using text-analysis as the discovery technique.
Bennett, McRobb, and Farmer (2002) strongly advocate the identification of classes and rela-
tionships through analysis of use cases by (1) first trying to identify the actors and the classes (or
objects) that are involved, then (2) trying to sketch an initial collaboration diagram, and (3) from
there, trying to determine the relevance of the classes (identified earlier in the analysis of the use
case) and their relationships (Bennett et al., 2002, 176–195). Thus, the main approach these authors
recommend is bottom-up in perspective and uses collaboration analysis as the discovery technique.
However, they also take the view that it is feasible to develop a domain model that is “independent
of any particular use cases.” In addition, they advise that it helps to know what you are looking for
by keeping in mind (1) a set of categories of things and concepts that can be potential candidates
for representation (people, organizations, structures, physical things, etc.), and (2) some guidelines
to eliminate unsuitable candidates. Thus, the method is mainly, but not exclusively, bottom-up in
perspective and uses collaboration and text analysis as discovery techniques.
Object modeling technique (OMT; Rumbaugh et al., 1990) is largely top-down and text analysis
in character. As is common with text analysis approaches, two kinds of heuristics are provided to
help the analyst identify the appropriate concepts: (1) a set of categories of things to watch out for
as potential candidates, and (2) a set of guidelines to evaluate the suitability of a candidate concept.
The evaluation guidelines of OMT will be discussed in detail in a later part of the chapter.
The Responsibility-Driven approach (Wirfs-Brock, Wilkerson, and Wiener, 1990) places an
emphasis on behavior. The approach’s starting point is the perceived responsibilities of the system.
The tasks to be done by the system are considered in turn. And, for each task, the first question
is: Which class is responsible for carrying it out? The next question is: With which other classes
does this class have to collaborate in order to perform its duty? And so on. The classes and their
collaborations are usually recorded using the Class-Responsibility and Collaborator (CRC) cards
(Beck and Cummingham, 1989). This approach is thus bottom-up in perspective and uses col-
laboration analysis as the main discovery technique. Note that this approach still needs to initially
identify the relevant classes, and this is usually done by simple brainstorming or by some text
analysis technique.
The Unified Process or UP (Jacobson, Booch, and Rumbaugh, 1999) provides a general devel-
opment process framework that can be customized for specific projects. Judging by the published
literature on UP in relation to domain modeling, UP domain modeling can be broadly described
as embracing both the top-down and bottom-up approaches with text analysis and collaboration
analysis as its discovery techniques.
Extreme Programming or XP (Beck, 2000) advocates the writing of stories (scenarios, use cases)
and test cases, and possibly with a minimum amount of analysis, proceeding to programming—
relying on refactoring techniques to incorporate additional functionality and to cope with changes.