Software Engineering-Identifying Elements of Object Model

The elements of an object model—classes and objects, attributes, operations, and messages—were each defined and discussed in the preceding section. But how do we go about identifying these elements for an actual problem? The sections that follow present a series of informal guidelines that will assist in the identification of the elements of the object model.

Identifying Classes and Objects

If you look around a room, there is a set of physical objects that can be easily identified, classified, and defined (in terms of attributes and operations). But when you "look around" the problem space of a software application, the objects may be more difficult to comprehend.

We can begin to identify objects by examining the problem statement or performing a "grammatical parse" on the processing 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 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. Objects can be

External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system.
Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem.
Occurrences or events (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 application.
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.

This categorization is but one of many that have been proposed in the literature. For example, Budd  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" . For example, if the developers of software for a medical imaging system defined an object with the name image inversion, 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 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. We already performed a "grammatical 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

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 sensor event occurs.

When a sensor event is sensed by the software, it rings an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information 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 consider each further before a final decision is made. Coad and Yourdon suggest six selection characteristics that should be used as an analyst considers each potential object for inclusion in the analysis model:

1. Retained information. The potential object will be useful during analysis only if information about it must be remembered so that the system can function.

2. Needed services. The potential object must have a set of identifiable operations that can change the value of its attributes in some way.

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 object and these operations apply to all occurrences of the object.

6. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as objects in the requirements 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 potential 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
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 characteristics 1 and 2 and would have been accepted).

Specifying Attributes

Attributes describe an object that has been selected for inclusion in the analysis model. In essence, it is the attributes that define the object—that clarify what is meant by the object in the context of the problem space. For example, if we were to build a system that tracks baseball statistics for professional baseball players, the attributes of the object player would be quite different than the attributes of the same object when it is used in the context of the professional baseball pension system. In the former, attributes such as name, position, batting average, fielding percentage, years played, and games played might be relevant. For the latter, some of these attributes would be meaningful, but others would be replaced (or augmented) by attributes like average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like.

To develop a meaningful set of attributes for an object, the analyst can again study the processing narrative (or statement of scope) for the problem and select those things that reasonably "belong" to the object. In addition, the following question should be answered for each object: "What data items (composite and/or elementary) fully define this object in the context of the problem at hand?"

To illustrate, we consider the system object defined for SafeHome. Homeowner can configure the security system to reflect sensor information, alarm response information, activation/deactivation information, identification information, and so forth. Using the content description notation defined for the data dictionary , we can represent these composite data items in the following manner:

sensor information = sensor type + sensor number + alarm threshold
alarm response information = delay time + telephone number + alarm type
activation/deactivation information = master password + number of allowable tries + temporary  password
identification information = system ID + verification phone number + system status

Each of the data items to the right of the equal sign could be further defined to an elementary level, but for our purposes, they constitute a reasonable list of attributes for the system object .
Defining Operations

Operations define the behavior of an object and change the object’s attributes in some way. More specifically, an operation changes one or more attribute values that are contained within the object. Therefore, an operation must have "knowledge" of the nature of the object's attributes and must be implemented in a manner that enables it to manipulate the data structures that have been derived from the attributes.

Although many different types of operations exist, they can generally be divided into three broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting), (2) operations that perform a computation, and (3) operations that monitor an object for the occurrence of a controlling event.

As a first iteration at deriving a set of operations for the objects of the analysis model, the analyst can again study the processing narrative (or statement of scope) for the problem and select those operations that reasonably belong to the object. To accomplish this, the grammatical parse is again studied and verbs are isolated. Some of these verbs will be legitimate operations and can be easily connected to a specific object. For example, from the SafeHome processing narrative , we see that "sensor is assigned a number and type" or that "a master password is programmed for arming and disarming the system." These two phrases indicate a number of things:

That an assign operation is relevant for the sensor object.
That a program operation will be applied to the system object.
That arm and disarm are operations that apply to system (also that system status may ultimately be defined (using data dictionary notation) as

system status = [armed | disarmed]


Upon further investigation, it is likely that the operation program will be divided into a number of more specific suboperations required to configure the system. For example, program implies specifying phone numbers, configuring system characteristics (e.g., creating the sensor table, entering alarm characteristics), and entering password(s). But for now, we specify program as a single operation.

In addition to the grammatical parse, we can gain additional insight into other operations by considering the communication that occurs between objects. Objects communicate by passing messages to one another. 

Finalizing the Object Definition

The definition of operations is the last step in completing the specification of an object. Operations were culled from a grammatical parse of the processing narrative for the system. Additional operations may be determined by considering the "life history"  of an object and the messages that are passed among objects defined for the system.

The generic life history of an object can be defined by recognizing that the object must be created, modified, manipulated or read in other ways, and possibly deleted. For the system object, this can be expanded to reflect known activities that occur during its life (in this case, during the time that SafeHome is operational). Some of the operations can be ascertained from likely communication between objects. For example, sensor event will send a message to system to display the event location and number; control panel will send system a reset message to update system status; the audible alarm will send a query message; the control panel will send a modify message to change one or more attributes without reconfiguring the entire system object; sensor event will also send a message to call the phone number(s) contained in the object. Other messages can be considered and operations derived. The resulting object definition is shown in figure.
A similar approach would be used for each of the objects defined for SafeHome. After attributes and operations are defined for each of the objects identified to this point, the beginnings of an OOA model would be created.
Software Engineering-Identifying Elements of Object Model Reviewed by 1000sourcecodes on 06:20 Rating: 5
Powered by Blogger.