Problem Analysis  «Prev  Next»
Lesson 5Identify classes and objects
ObjectiveIdentify classes and objects from the problem domain vocabulary.

Identify Classes and Objects when Object Modeling

Up to this point, we have discussed what a domain class is. But would you know one when you see it? Would everyone in the team agree with your decision with respect to your interpretation of the problem domain? What happens when you find some new information that changes your opinion?

Keep track of how a Decision was Derived

One common mistake in modeling is when we do not keep track of how we arrived at a decision.
Question: It is kind of like math class back in school. When you showed your work, the teachers could figure out where you went wrong. They could help you understand how to arrive at the correct answer consistently.
But if you did not show your work, there was no way to know whether you got the problem right by skill or just by dumb luck.
Working in a team makes showing your work even more critical. No two people think exactly the same way or at the same pace. Not everyone is in every conversation or meeting. Finally, no one is right all the time. If you document how you arrived at a decision, then you can always return to the decision process, reevaluate, and change the decision. Equally important is the fact that you preserve a record of the process for everyone to learn from.

Noun Extraction

Another approach to identifying classes that is somewhat simplistic and yet often useful, is called noun extraction.
The basic idea is this: read over the system requirements/use case flows of events, and note the nouns that appear.
  1. Some of the nouns that appear, especially the ones that appear frequently will turn out to refer to objects that need to be represented by classes in the final system.
  2. Other nouns will turn out to represent other elements, including: 1. Attributes of objects, rather than objects in their own right. An important skill to develop is being able to distinguish the two. Recall that objects have three essential characteristics:
  1. Identity.
  2. State (often complex - i.e. involving more than a simple value). c) Behavior
Examples: ASK for Wheels examples of attributes that are not objects in their own right, and why things like customer name, bicycle rental rate, date due are attributes.
2. Actors or other objects that are outside the scope of the system.
Example: ASK for Wheels examples Receptionist: Note that since we do not have to build models of these, they do not need to be represented by classes inside the system.
C. Finally, sometimes there may be a generalization-specialization relationship between nouns - implying an inheritance relationship between the corresponding classes.
D. Apply noun-extraction to use cases for AddressBook system.
Here is a simple technique for tracking down classes which could represent the problem domain and will enable you to show your work.
Step 1: Find the nouns
Read through the problem statement and the associated documentation and highlight the nouns. Parts of speech translate very nicely into object model elements. Nouns translate into classes or objects, attributes, or attribute values. (Verbs often reveal operations or associations.)

Part of Speech Model Element
  1. Object (useful as test data)
  2. Class
  3. Attribute
  4. Attribute value (useful as test data)
  1. Association
  2. Operation
  3. Event
Adjective State

Gather the most Significant Documents

I use this technique without exception. When I walk into a consulting situation, I am expected to come up to speed instantly. I immediately gather the most significant documents, highlight the nouns and verbs, and build a data dictionary. Through this process of highlighting the nouns and verbs, I am able to generate classes that best represent the situation at hand. Invariably, I am able to ask probing questions that challenge the (SME) subject matter experts simply by scrutinizing their own vocabulary. By asking the users of the system questions with respect to the problem domain, I am assured that the client I am communicating with, has a deep understanding of the problem domain.

Step 2:

Evaluate the nouns to find classes
Questions to ask to evaluate nouns to find classes:
  1. Is the term needed within the scope of the project?
  2. If so, then does the noun qualify as a problem domain resource? Think of an appropriate class name for the domain resource to which the noun refers.
  3. Otherwise, is the noun an example of a class, for example, an object, an instance of a class? What class? Write down this fact and refer back to it when you need test data.
  4. Otherwise, is the noun an attribute of a class? What class? Write it down.
  5. Otherwise, is the noun an example of an attribute, for example, an attribute value? Write down this fact and refer back to it when you need test data.

Be sure to reconcile terms. You will often encounter synonyms. Pick the most meaningful term and point the other terms to it. Be certain that the users agree with your choice.

Step 3:

Define the purpose
Describe why the class is a required resource of the problem domain.
Here is an example of the process just described from the course project. From the problem statement (nouns in bold):
Our auditorium is used for different types of events. Some of the events are one-time events, such as basketball games. Other events consist of a number of shows, such as plays or concerts.

Candidate Term Not a class because Class Name Class Purpose
Auditorium   Auditorium The facility in which the events are held and for which tickets are sold
Event   Event A performance negotiated by the event planner and presented in one or more shows
Basketball game It is a type of event    
Show   Show A single presentation of an event
Play It is a type of event    
Concert It is a type of event    

Classes Objects - Exercise

Click the Exercise link below to identify the classes in the course project problem statement.
Classes Objects - Exercise