Booch Method

Chapter 4. Classification

Katsuya Amako

Version

Questions List

HERE

Note:

The numbers in the parenthesis found in each question are sections referred to make the answer.
You can go back to the top of the page (Questions List) by clicking each question below.

1. The Importance of Proper Classification

Q1.1: What is the relation between classification and object-oriented development? (Ref: 4.1, p.146, p.167)

The identification of classes and objects is the fundamental issue and the hardest part of object-oriented analysis and design. Classification is fundamentally a problem of finding sameness, which helps to identify generalization, specialization and aggregation hierarchies among classes. Classification also guides us in making decisions about modularization.

The nature of classification is an incremental and iterative process.

Q1.2: Why is classification difficult? (Ref: 4.1, p.150)

There are two important reasons for this:

There is no such thing as a perfect classification, although certainly some classifications are better than others. Any classification is relative to the perspective of the observer doing the classification.
Intelligent classification requires a tremendous amount of creative insight. Sometimes the answer is evident, sometimes it is a matter of taste, and at other times, the selection of suitable components is a crucial point in the analysis.

2. Identifying Classes and Objects

Q2.1: What kinds of approaches are there in classification? (Ref: 4.2, p.150)

Historically, there have only been three general approaches to classification:

Classical categorization
In this approach, all the entities that have a given property or collection of properties in common form a category. Such properties are necessary and sufficient to define the category. For example,
- Married people constitute a category: one is either married of not, and the value of this property is sufficient to decide to which group a particular person belongs.
- Tall people do not form a category, unless we can agree to some absolute criteria for what distinguishes the property of tall from short.
To summarize, this approach uses related properties as the criteria for sameness among object. However, as the second example in the above suggests, this is not always satisfactory.
Conceptual clustering
This is a more modern variation of the classical approach. In this approach, classes are generated by first formulating conceptual descriptions of these classes and then classifying the entities according to the description. For example,
- We may state a concept such as a love song.
- This is a concept more than a property, for the love songess of any song is not something that may be measured empirically.
- However, we decide that a certain song is more of a love song than not, we place it in this category.
Thus conceptual clustering represents more of a probabilistic clustering of objects.
Prototype theory
There are still some situations in which the above two approaches are inadequate. This leads us to the more recent approach to classification called prototype theory. In this classification, a class of objects is represented by a prototypical object, and an object is considered to be a member of this class if and only if it resembles this prototype in significant way. For example,
- We understand beanbag chairs, barber chairs, and contour chairs as being chairs.
- This is not because these chairs share some fixed set of defining properties.
- But this is because each, in its different way, is sufficiently close to the prototype of the chair.
In conceptual clustering, we group things according to distinct concepts. In prototype theory, we group things according to the degree of their relationship to concrete prototypes.

Q2.2: How to use the classification approaches to OO design? (Ref: 4.2, p.154)

From practician's view point, the classification approaches in Q2.1 seems to be far removed from reality. However, these approaches have direct application to object-oriented design.

In our experience, we identify classes and objects first according to the properties relevant to our particular domain. Here, we focus upon identifying the structures and behavior that are part of the vocabulary of our problem space. This is the classical categorization approach.
If the above approach fails to yield a satisfactory class structure, then we next consider conceptual clustering. Here, we focus our attention upon the behavior of collaborating objects.
If either of the above approaches fails to capture our understanding of our the problem domain, then we consider classification by association, through which clusters of objects are defined according to how closely each resembles some prototypical object (prototype theory).

Q2.3: What kind of methodologies are there to find classes and objects? (Ref: 4.2, p.155)

Booch defines the object-oriented analysis and design as follows:

Analysis
In the object-oriented analysis, we seek to model the world by discovering the classes and objects that form the vocabulary of problem domain.
Design
In the object-oriented design, we invent the abstractions and mechanisms that provide the behavior that the model established in the analysis.

There are a number of proven approaches (methodologies) for analysis that are relevant to object-oriented systems.

Classical Approaches
In these approaches, classes and objects are derived from the requirements of the problem domain. These are called classical because they derive primary from the principles of classical categorization. FOe example, Shlaer and Mellor suggest that candidate classes and objects usually come from one of the following sources:
- Tangible things: Cars, telemetry data, pressure sensors
- Roles: Mother, teacher, politician
- Events: Landing, interrupt, request
- Interactions: Loan, meeting, intersection
Behavior Analysis
These approaches focus upon dynamic behavior as the primary source of classes and objects. These are more akin to conceptual clustering: we form classes based upon groups of objects that exhibit similar behavior. We group things that have common responsibilities, and form hierarchies of classes involving superclasses that embody general responsibilities and subclasses that specialize their behavior. Here responsibilities means the knowledge an object maintains and the actions an object can perform.
Domain Analysis
Domain analysis is defined as an attempt to identify the objects, operations, and relationships that domain experts perceive to be important about the domain. For example,
1. Construct a strawman generic model of the domain by consulting with domain experts.
2. Examine existing systems within the domain and represent this understanding in a common format.
3. Identify similarities and differences between the systems by consulting with domain experts.
4. Refine the generic model to accommodate existing system.
Use-Case Analysis
Use-case is defines as:
- a particular form or pattern or exemplar of usage,
- a scenario that begins with some user of the system initiating some transaction or sequence of interrelated events.
Briefly, we can apply use-case analysis as early as requirements analysis. A typical steps in this analysis are:
1. End users, other domain experts, and the development team enumerate the scenarios that are fundamental to the system's operation. These scenarios collectively describe the system functions of the application.
2. Analysis then proceeds by a study of each scenario, using storyboarding techniques similar to practices in the television and movie industry.
3. As the team walks through each scenario, they must identify the objects that participate in the scenario, the responsibilities of each object, and how these objects collaborate with other object, in terms of the operations each invokes upon the other.
CRC Cards
CRC cards have emerged as a simple yet marvelously effective way to analyze scenarios. A CRC card is nothing more than 3x5 index card, upon which the analyst writes the name of a class, its responsibilities and its collaborators. One card is created for each class identified as relevant to the scenario.
CRC cards can be spatially arranged to represent patterns of collaboration. As viewed from the dynamic semantics of the scenario, the cards are arranged to show the flow of messages among prototypical instances of each class. As viewed from static semantics of the scenario, the cards are arranged to represent generalization/specialization or aggregation hierarchies among the classes.
Informal English Description
In this approach a user writes an English description of the problem and then underlines the nouns and verbs. The nouns represent candidate objects, and the verbs represent candidate operations upon them. However, it is by no means a rigorous approach. For example, any noun can be verbed, and nay verb can be nouned.
Structured Analysis
This approach uses the products of structured analysis as a front end to object-oriented analysis. Booch discourage to use this approach.

3. Key Abstractions and Mechanisms

Q3.1: What is a key abstraction? (Ref: 4.3, p.162)

A key abstraction is a class or object that forms part of the vocabulary of the problem domain. The primary value of identifying such abstractions is that they give boundaries to our problem: they highlight the things that are in the system and therefore relevant to our design, and suppress the things that are outside the system and therefore superfluous.

The identification of key abstractions is highly domain-specific. The appropriate choice of objects depends, of course, on the purpose to which the application will be put and the granularity of information to be manipulated.

Q3.2: How to find a key abstraction? (Ref: 4.3, p.162)

The identification of key abstractions involves two processes:

Discovery
Through this, we come to recognize the abstractions used by domain experts. If the domain experts talks about it, then the abstraction is usually important.
(Memo: These abstractions are stable and don't change with time. This is the process in the analysis.)
Invention
Through this, we create new classes and objects that are not necessarily part of the problem domain, but are useful artifacts in the design or implementation. These abstractions are artifacts of the particular design, not the problem domain. (Memo: These abstractions are not stable and may change when the design changed. This is the process in the design.)

Booch recommend the use of scenarios to drive the processes of identifying classes and objects (key abstractions).

Q3.3: What is a mechanism? (Ref: 4.3, p.164)

A mechanism is a structure whereby objects collaborate to provide some behavior that satisfies a requirement of the problem. Whereas the design of a class embodies the knowledge of how individual objects behave, a mechanism is a design decision about how collections of objects cooperate.

Q3.4: How to find a mechanism? (Ref: 4.3, p.165)

For example, consider a system requirement for an automobile. Pushing the accelerator should cause the engine to run faster, and releasing the accelerator should cause the engine to run slower. How this actually comes about is absolutely immaterial to the driver. Any mechanism may be employed as long as it delivers the required behavior, and thus which mechanism is selected is largely a matter of design choice.