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