Lesson 5	Identify classes and objects
Objective	Identify 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.

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.
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:

ASK

Identity.
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
Noun	Object (useful as test data) Class Attribute Attribute value (useful as test data)
Verb	Association Operation 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:

Is the term needed within the scope of the project?
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.
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.
Otherwise, is the noun an attribute of a class? What class? Write it down.
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