Identifying Classes and Objects
20.3.1 Identifying Classes and Objects
If you look around a room, there is a set of physical objects that can be easily iden- “The really hard
tified, classified, and defined (in terms of attributes and operations). But when you problem [in OO] is
"look around" the problem space of a software application, the objects may be more discovering what are
difficult to comprehend. the ‘right’ objects in
We can begin to identify objects 4 by examining the problem statement or (using the first place.” the terminology from Chapter 12) by performing a "grammatical parse" on the pro-
Carl Argila
cessing narrative for the system to be built. Objects are determined by underlining each noun or noun clause and entering it in a simple table. Synonyms should be
4 In reality, OOA actually attempts to define classes from which objects are instantiated. Therefore, when we isolate potential objects, we also identify members of potential classes.
F I G U R E 20.9
Occurrences
Roles
How objects
Things
Organizational units
manifest
Places
themselves External entities
Structures
Class name Attributes:
Operations:
noted. If the object is required to implement a solution, then it is part of the solution space; otherwise, if an object is necessary only to describe a solution, it is part of the problem space. What should we look for once all of the nouns have been isolated?
Objects manifest themselves in one of the ways represented in Figure 20.9. Objects can be
• ? External entities (e.g., other systems, devices, people) that produce or con-
How do I
pick out
sume information to be used by a computer-based system.
objects as I study the problem to be
• Things (e.g, reports, displays, letters, signals) that are part of the information
solved?
domain for the problem. • Occurrences or events 5 (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. • Roles (e.g., manager, engineer, salesperson) played by people who interact
with the system. • Organizational units (e.g., division, group, team) that are relevant to an appli-
cation. • Places (e.g., manufacturing floor or loading dock) that establish the context of
the problem and the overall function of the system. • Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a
class of objects or in the extreme, related classes of objects.
5 In this context, the term event connotes any occurrence. It does not necessarily imply control as it did in Chapter 12.
CHAPTER 20
OBJECT-ORIENTED CONCEPTS AND PRINCIPLES
This categorization is but one of many that have been proposed in the literature. For example, Budd [BUD96] suggests a taxonomy of classes that includes producers (sources) and consumers (sinks) of data, data managers, view or observer classes, and helper classes.
It is also important to note what objects are not. In general, an object should never have an "imperative procedural name" [CAS89]. For example, if the developers of software for a medical imaging system defined an object with the name image inver- sion, they would be making a subtle mistake. The image obtained from the software could, of course, be an object (it is a thing that is part of the information domain). Inversion of the image is an operation that is applied to the object. It is likely that inversion would be defined as an operation for the object image, but it would not be defined as a separate object to connote "image inversion." As Cashman [CAS89] states: "the intent of object-orientation is to encapsulate, but still keep separate, data and operations on the data."
To illustrate how objects might be defined during the early stages of analysis, we return to the SafeHome security system example. In Chapter 12, we performed a "gram- matical parse" on a processing narrative for the SafeHome system. The processing narrative is reproduced:
SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel shown in Figure 11.2.
During installation, the SafeHome control panel is used to "program" and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a
A grammatical parse
sensor event occurs.
can be used to isolate
When a sensor event is sensed by the software, it rings an audible alarm attached to the
potential objects
system. After a delay time that is specified by the homeowner during system configuration
(nouns) and
activities, the software dials a telephone number of a monitoring service, provides infor-
operations (verbs).
mation about the location, reporting and the nature of the event that has been detected. The number will be redialed every 20 seconds until telephone connection is obtained.
All interaction with SafeHome is managed by a user-interaction subsystem that reads input provided through the keypad and function keys, displays prompting messages on the LCD display, displays system status information on the LCD display. Keyboard interaction takes the following form . . .
Extracting the nouns, we can propose a number of potential objects:
Potential Object/Class
General Classification
homeowner
role or external entity
sensor
external entity
control panel
external entity
installation
occurrence
system (alias security system)
thing
number, type
not objects, attributes of sensor
Potential Object/Class
General Classification
master password
thing
telephone number
thing
sensor event
occurrence
audible alarm
external entity
monitoring service organizational unit or external entity The list would be continued until all nouns in the processing narrative have been
considered. Note that we call each entry in the list a potential object. We must con- sider each further before a final decision is made.
Coad and Yourdon [COA91] suggest six selection characteristics that should be used as an analyst considers each potential object for inclusion in the analysis model:
? How do I
know
1. Retained information. The potential object will be useful during analysis only
whether a
if information about it must be remembered so that the system can function.
potential object is
a good candidate
2. Needed services. The potential object must have a set of identifiable opera-
for use in an OO
tions that can change the value of its attributes in some way.
system?
3. Multiple attributes. During requirement analysis, the focus should be on "major" information; an object with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another object during the analysis activity.
4. Common attributes. A set of attributes can be defined for the potential object and these attributes apply to all occurrences of the object.
5. Common operations. A set of operations can be defined for the potential should satisfy most or
A potential object
object and these operations apply to all occurrences of the object. all of these
6. Essential requirements. External entities that appear in the problem space characteristics if it is to
be used in the analysis and produce or consume information essential to the operation of any solu- model.
tion for the system will almost always be defined as objects in the require- ments model.
To be considered a legitimate object for inclusion in the requirements model, a potential object should satisfy all (or almost all) of these characteristics. The decision for inclusion of potential objects in the analysis model is somewhat subjective, and later evaluation may cause an object to be discarded or reinstated. However, the first step of OOA must be a definition of objects, and decisions (even subjective ones) must
be made. With this in mind, we apply the selection characteristics to the list of poten- tial SafeHome objects:
Potential Object/Class
Characteristic Number That Applies
homeowner rejected: 1, 2 fail even though 6 applies sensor
accepted: all apply
control panel
accepted: all apply
installation
rejected
system (alias security system)
accepted: all apply
CHAPTER 20
OBJECT-ORIENTED CONCEPTS AND PRINCIPLES
number, type rejected: 3 fails, attributes of sensor master password
rejected: 3 fails
telephone number
rejected: 3 fails
sensor event
accepted: all apply
audible alarm
accepted: 2, 3, 4, 5, 6 apply
monitoring service rejected: 1, 2 fail even though 6 applies It should be noted that (1) the preceding list is not all-inclusive, additional objects
would have to be added to complete the model; (2) some of the rejected potential objects will become attributes for those objects that were accepted (e.g., number and type are attributes of sensor, and master password and telephone number may become attributes of system); (3) different statements of the problem might cause different "accept or reject" decisions to be made (e.g., if each homeowner had an individual password or was identified by voice print, the homeowner object would satisfy char- acteristics 1 and 2 and would have been accepted).