Classification

1
Lesson 6

• Classification

2
Definition

• Classification is the means whereby we order
  knowledge.
• The grouping together of things that have a
  common structure, or exhibit common behavior.

3
(c) 1994 Booch
4
The Importance of Proper Classification

• Classification is important to every aspect of
  OOAD
• Analysis
• Helps us identify inheritance and aggregation
  hierarchies among classes.
• Design
• Helps us invent mechanisms by recognizing common
  patterns of interaction among objects.
• Helps us choose how to place objects into modules.

5
Importance (continued)

• Classification tends to be incremental and
  iterative. A common pattern is
• Problems are solved ad hoc.
• With experience, some solutions are found to work
  better than others. This folklore is passed on
  informally to others.
• Useful solutions are systematically codified and
  analyzed.

6
Importance (continued)

• Theories are developed which prescribe general
  solutions and automated implementation.
• A more sophisticated level of practice develops,
  and harder problems are now attacked. The cycle
  repeats itself.
• This pattern affects how we develop an OO
  architecture
• A class structure is created early in design, and
  revised continually as design proceeds.

7
Importance (continued)

• Once in use, the quality of the class structure
  is evaluated.
• The class structure may then be revised
• May split a large class into several smaller ones
  (factorization).
• May create a larger class by combining smaller
  ones (composition).
• May create a new class by discovering previously
  unrecognized commonality (abstraction).

8
Importance (continued)

• Classification is difficult.
• There is no perfect classification.
• But some classifications are definitely better
  than others.
• There are many ways to classify the same object.
• Classification is relative to the perspective of
  the observer.
• Classification often requires creative insight.

9
(c) 1994 Booch
10
Approaches to Classification

• Classical Categorization
• All entities that have a given property or set of
  properties in common form a category.
• E.g. marital status never married, married,
  divorced, widow or widower.
• Works best when the properties dont interact
  much.
• E.g. size, color, shape, substance.

11
Approaches (continued)

• The particular properties to use for
  classification are domain-specific.
• E.g. the color of a cow is important for a judge
  in a 4H Club, but not for a scientist monitoring
  mad cow disease.
• Conceptual Clustering
• Conceptual categories are first created.
• Entities are placed into one of these categories
  according to its best fit.

12
Approaches (continued)

• E.g. concept of elegance
• A particular restaurant is placed in this
  category according to the judgment of the
  observer.
• Elegance is not empirically measurable.
• Prototype Theory
• A class is represented by a prototypical object.
• An object belongs to this class if it resembles
  the prototype in significant ways.
• E.g. chair class

13
Classification in OO Analysis

• In analysis, we model the world by discovering
  classes and objects, using the vocabulary of the
  problem domain.
• Classical approach
• Based on classical categorization.
• Identify classes and objects by looking at
• tangible things cars, telemetry data, sensors
• roles mother, teacher, politician

14
Classification (continued)

• events landing, interrupt, request
• interactions loan, meeting, intersection
• etc.
• Behavior Analysis
• Identify classes based upon objects that exhibit
  similar behavior.

15
Classification (continued)

• Domain Analysis
• Identify classes that are common to all
  applications within a given domain.
• E.g. Accounting software, securities trading,
  etc.
• Use-Case Analysis
• Scenarios are identified which collectively
  describe the system functions

16
Classification (continued)

• Each scenario is walked through to identify
• objects that participate in the scenario
• their responsibilities
• how the objects collaborate, and what operations
  they perform on each other.
• Later, new scenarios are added to consider
  exceptional conditions and secondary system
  behaviors.

17
Classification (continued)

• CRC Cards
• Used to analyze scenarios.
• As classes are identified, you write on a 3 x 5
  card
• class name
• its responsibilities
• its collaborators.

18
Classification (continued)

• Informal English Description
• Write an English description of the problem.
• Underline all the nouns and verbs.
• Nouns represent candidate objects.
• Verbs represent candidate operations.

19
Classification (continued)

• Structured Analysis
• Identify classes and objects by looking at the
  essential model
• data dictionary
• context diagram
• other DFDs
• Use of structured analysis is discouraged as a
  front end to OOD.

20
Identifying Key Abstractions and Mechanisms

• A key abstraction is a class or object that
  forms part of the vocabulary of the problem
  domain.
• Identifying key abstractions is important.
• Places a boundary on the problem tells us what
  is inside and outside of the system.
• The appropriate choice of key abstractions is
  highly domain-specific.

21
Identifying (continued)

• Involves two processes
• Discovery (analysis) recognize the abstractions
  used by domain experts.
• E.g. banking accounts, deposits, withdrawals,
  etc.
• Invention (design and implementation) create
  useful new classes and objects to make a working
  system.
• E.g. lists, queues, databases, etc.

22
Identifying (continued)

• Key abstractions are refined as development
  proceeds.
• The naming of classes, objects, modules and
  methods should be carefully considered.
• A mechanism is a structure that allows objects to
  collaborate, to provide some specified behavior.

23
Identifying (continued)

• Mechanisms are designed
• What particular mechanism is chosen is
  immaterial, as long as it gives the right
  behavior.
• Mechanisms are embodied in the methods of the
  classes of collaborating objects.

24
This presentation is based on the following book
Object Oriented Analysis and Design by G.Booch
and partially compiled by Leonard Manzara.