6.3 Key Strategies for Object Identification

Over the years, I've consulted in an extremely varied set of problem domains, from medical systems to factory automation to avionics and fire control (weapons control systems). The good part about consulting in such a broad range of fields is that it is extraordinarily interesting and one gets to learn daily.^[4] The bad part about that is that one is expected to sound intelligent about the problem almost immediately.^[5] For any consultant to be successful in that kind of environment, he or she must have some effective strategies for working with engineers and managers who understand their problem domain very well but who are often neophytes when it comes to the application of the UML to their problems. Table 6-1 outlines what I have found to be the most effective of these object-identification strategies.

^[4] Which has dropped me square in the middle of what I call the knowledge paradox: The more I learn, the less I know. I figure by the time I'm 60, I'll have learned so much that I will actually know nothing whatsoever! So far, I'm on target ;-)

^[5] Good looks and charm only get you so far when they actually want to fly the thing!

Table 6-1. Object Discovery Strategies

Strategy	Description
Underline the noun	Used to gain a first-cut object list, the analyst underlines each noun or noun phrase in the problem statement and evaluates it as a potential object.
Identify causal objects	Identify the sources of actions, events, and messages; includes the coordinators of actions.
Identify services (passive contributors)	Identify the targets of actions, events, and messages as well as entities that passively provide services when requested.
Identify messages and information flow	Messages must have an object that sends them and an object that receives them as well as, possibly, another object that processes the information contained in the messages.
Identify real-world items	Real-world items are entities that exist in the real world, but that are not necessarily electronic devices. Examples include respiratory gases, air pressures, forces, anatomical organs, and chemicals.
Identify physical devices	Physical devices include the sensors and actuators provided by the system as well as the electronic devices they monitor or control. In the internal architecture, they are processors or ancillary electronic widgets.
Identify key concepts	Key concepts may be modeled as objects. Bank accounts exist only conceptually, but are important objects in a banking domain. Frequency bins for an on-line autocorrelator may also be objects.
Identify transactions	Transactions are finite instances of associations between objects that persist for some significant period of time. Examples include bus messages and queued data.
Identify persistent information	Information that must persist for significant periods of time may be objects or attributes. This persistence may extend beyond the power cycling of the device.
Identify visual elements	User interface elements that display data are objects within the user interface domain such as windows, buttons, scroll bars, menus, histograms, waveforms, icons, bitmaps, and fonts.
Identify control elements	Control elements are objects that provide the interface for the user (or some external device) to control system behavior.
Apply scenarios	Walk through scenarios using the identified objects. Missing objects will become apparent when required actions cannot be achieved with existing objects.

This chapter discusses all these strategies, but note that the analyst need not use them all on any specific project. These approaches are not orthogonal and the objects they find will overlap to a significant degree. In fact, many subsets of the strategies will find the exactly the same set of objects. Some methods will fit some analysts' approaches better than others. It is common to select three or four strategies on a given project and apply them more or less simultaneously. As with all modeling strategies, use those that work well for you and discard the ones that do not.

6.3.1 Underline the Noun Strategy

The first strategy works directly with the written problem or mission statement. Underline each noun or noun phrase in the statement and treat it as a potential object. Objects identified in this way can be put into four categories:

• Objects of interest or their classes

• Actors

• Uninteresting objects

• Attributes of objects

The point of the exercise is to find objects within the first category objects of interest or their classes. Actors have usually already been identified in the use case model, but occasionally some new ones are identified here. Uninteresting objects are objects that have no direct relevance to your system. Attributes also show up as nouns in the problem statement. Sometimes an attribute is clearly just a property of an object. When in doubt, tentatively classify the noun as an object. If subsequent analysis shows the object is insufficiently interesting, it can be included as an attribute of some other object.

Let's see how this works by looking at an elevator, a real-time system familiar to everyone. We begin with a problem statement for an elevator system with the noun phrases emphasized:

A software system must control a set of eight Acme elevators for a building with 20 floors. Each elevator contains a set of buttons, each corresponding to a desired floor. These are called floor request buttons, since they indicate a request to go to a specific floor. Each elevator as well has a current floor indicator above the door. Each floor has two buttons for requesting elevators called elevator request buttons, because they request an elevator.

Each floor has a sliding door for each shaft arranged so that two door halves meet in the center when closed. When the elevator arrives at the floor, the door opens at the same time the door on the elevator opens. The floor does have both pressure and optical sensors to prevent closing when an obstacle is between the two door halves. If an obstruction is detected by either sensor, the door shall open. The door shall automatically close after a timeout period of 5 seconds after the door opens. The detection of an obstruction shall restart the door closure time after an obstruction is removed. There is a speaker on each floor that pings in response to the arrival of an elevator.

On each floor (except the highest and lowest), there are two elevator request buttons, one for UP and one for DOWN. On each floor, above each elevator door, there is an indicator specifying the floor that the elevator is currently at and another indicator for its current direction. The system shall respond to an elevator request by sending the nearest elevator that is either idle or already going in the requested direction. If no elevators are currently available, the request shall pend until an elevator meets the above-mentioned criterion. Once pressed, the request buttons are backlit to indicate that a request is pending. Pressing an elevator request button when a request for that direction is already pending shall have no effect. When an elevator arrives to handle the request, the backlight shall be removed. If the button is pressed when an elevator is on the floor to handle the request (i.e., it is slated to go in the selected direction), then the door shall stop closing and the door closure timer shall be reset.

To enhance safety, a cable tension sensor monitors the tension on the cable controlling the elevator. In the event of a failure in which the measured tension falls below a critical value, then four external locking clamps connected to running tracks in the shaft stop the elevator and hold it in place.

Many of these are clearly redundant references to the same object (synonyms). Others are not of interest. The elevator cable, for example, is not nearly as interesting to the safety system as the cable tension sensor.^[6] Likewise, the passengers (clearly actors) are not as interesting as the buttons they push and the indicators they read, which are likely to be inside the scope of the system under development. Other objects clearly need not be modeled at all.

^[6] That is, it need not be modeled within the system. The cable tension sensor, however, must be modeled.

A list can be constructed from the emphasized noun phrases of the likely candidate objects by this kind of analysis. Table 6-2 shows object quantities, where specified, with parentheses.

Table 6-2. Candidate Objects

system (1)	elevator (8)	building (1)
floor (20)	request	button
floor request button (8*20)	elevator request button (20*2)	current floor indicator (8)
door (20*8 + 8)	optical sensor	obstruction
pressure sensor	speaker	UP button
door half	elevator door	indicator
DOWN button	floor door	secondary pressure sensor
internal door set	OPEN button	CLOSE button
elevator control panel	alarm	central station
EMERGENCY CALL button	elevator request	door closure timer
electrical power	telephone	elevator occupants
Stop-Run Switch	switch	message
emergency locks	alarm area	mechanical locking clamp
pressure sensor	tracks	electrical power source

Some likely attributes of a couple of these objects are shown in Table 6-3.

Table 6-3. Object Attributes

Object	Attribute
Elevator	Direction Status Location
Button	Backlight
Alarm	Status
Cable tensor sensor	Cable tension Critical tension

You can see that this strategy quickly identified many objects but also identified nouns that are clearly not interesting to the analyst.

6.3.2 Identify the Causal Objects

Once the potential objects are identified, look for the most behaviorally active ones. These are objects that

• Produce or control actions

• Produce or analyze data

• Provide interfaces to people or devices

• Store information

• Provide services to people or devices

• Contain other types of fundamental objects

The first two categories are commonly lumped together as causal objects. A causal object is an object that autonomously performs actions, coordinates the activities of component objects, or generates events. Many causal objects eventually become active objects and serve as the root composite object of a thread.^[7] Their components execute within the context of the thread of the owner composite.

^[7] Although the thread model for the system isn't determined until architectural design, as discussed in Chapter 8.

Clearly, the most behaviorally active objects are few in number:

• Floor

• Elevator

• Door

• Button

• Request

• Indicator

• Cable tension sensor

• Mechanical locking clamp

6.3.3 Identify Services (Passive Contributors)

Passive objects are less obvious than causal objects. They may provide passive control, data storage, or both. A simple switch is a passive control object. It provides a service to the causal objects (it turns the light on or off on request), but does not initiate actions by itself. Passive objects are also known as servers because they provide services to client objects.

Simple sensors are passive data objects. An A/D converter might acquire data on command and return it to an actor, or as the result of an event initiated by an active object. Printers and chart recorders are common passive service providers because they print text and graphics on command. A hardware passive service provider might be a chip that performs a cyclic redundancy check computation over a block of data.

6.3.4 Identify Messages and Information Flows

For each message, there is an object that sends it, an object that receives it, and potentially, another object that processes it. Messages are the realization of information flows. Information flows, taken from older data flow diagram techniques, specify information flowing from one object to another. Information flow is usually applied in early analysis, while later analysis takes into account the packaging of these flows into messages and service calls. This strategy is very similar to the strategy of identifying service calls, but it can be applied earlier in analysis or at a higher level of abstraction. The UML 2.0 specification allows for information flows to be drawn on class diagrams; these will become associations among the classes of those objects acting as conduits for the specific messages derived from the flows.

Figure 6-4 shows an example of information flows in UML 2.0. This diagram captures, at a high level of abstraction, the information flowing from one class to another. Flows are classifiers in UML and so they can be defined using standard classifier techniques statecharts, activity diagrams, operations, and attributes. These flows can be described by showing a class box stereotyped «flow» somewhere on the diagram, usually close to the flow between the objects. Notice that the flow between objects is shown as a stereotype of dependency.

Figure 6-4. Information Flows

6.3.5 Identify Real-World Items

Embedded systems need to model the information or behavior of real-world objects even though they are not part of the system per se. For example, an anesthesia system must model the relevant properties of patients, even though customers are clearly outside the anesthesia system. Typical customer objects will contain attributes such as

• Name

• Social Security number

• Address

• Phone number

• Insurance reference

• Weight

• Sex

• Height

An ECG monitor might model a heart as containing

• Heart rate

• Cardiac output

• Frequency of preventricular contractions

• Electrical axis

In anesthesia systems, modeling organs as "sinks" for anesthetic agent uptake can aid in closed loop control of agent delivery and prevent toxemia.

This strategy looks at things in the real world that interact in the system. Not all of the aspects of these real-world objects are modeled, only the ones relevant to the system. For example, the color of the heart or its neural control properties won't typically be modeled within an ECG system. Those aspects are irrelevant to the use cases realized by the ECG monitor. However, modeling its beat and PVC rate, as well as cardiac output is appropriate and relevant. If the system manipulates information about its actors, then the system should model at least their relevant aspects as objects.

6.3.6 Identify Physical Devices

Real-time systems interact with their environment using sensors and actuators in a hardware domain. The system controls and monitors these physical devices inside and outside the system and these objects are modeled as objects. Devices must also be configured, calibrated, enabled, and controlled so that they can provide services to the system. For example, deep within the inner workings of the system, processors typically perform initial power-on self-tests (POSTs) and periodic (or continuous) built-in tests (BITs). Devices frequently have nontrivial state machines and must provide status information on command. When device information and state must be maintained, the devices may be modeled as objects to hold the information about their operational status and available services.

For example, a stepper motor is a physical device that can be modeled as an object with the attributes and behaviors, as shown in Table 6-4.

Table 6-4. Stepper Model Object

Attributes	Position
Operations	Step(nSteps) GetPos Zero

Normally, only the interfaces to physical devices are actually modeled within this kind of class because the object presents an interface to client objects within the system. The object itself usually focuses on the communication with the device to achieve its client's purposes and not how the device actually works. The only exception to this rule is in constructing simulation systems, in which case modeling the internal behavior of the device is the point of the object.

6.3.7 Identify Key Concepts

Key concepts are important abstractions within the domain that have interesting attributes and behaviors. These abstractions often do not have physical realizations, but must nevertheless be modeled by the system. Within the User Interface domain, a window is a key concept. In the banking domain, an account is a key concept. In an autonomous manufacturing robot, a task plan is the set of steps required to implement the desired manufacturing process. In the design of a C compiler, functions, data types, and pointers are key concepts. Each of these objects has no physical manifestation. They exist only as abstractions modeled within the appropriate domains as objects or classes.

6.3.8 Identify Transactions

Transactions are objects that must persist for a finite period of time and that represent the interactions of other objects. Some example transaction objects are outlined in Table 6-5.

Table 6-5. Example Transaction Objects

Object 1	Object 2	Association	Transaction Object
Woman	Man	Marriage	Marriage object: wedding date wedding location prenuptial agreement witnesses
Woman	Man	Marriage	Divorce object: filing date decree date maintenance schedule amount paid to lawyers
Controller	Actuator	Controls	Control message over bus
Alarming Class	Alarm Manager	Issues alarms	Silence Alarm
Customer	Store	Buys things at	Order Return
Display System	Sensor	Displays values for	Alarm Error
Elevator Request Button	Elevator	Issues request to	Request for elevator
Floor Request Button	Elevator	Issues request to	Request for floor
Task Plan	Robot Arm	Controls	Command

In the elevator case study, an elevator request is clearly a transaction. It has a relatively short life span, either

• Beginning when the (future) passenger pushes the elevator request button and ending when the elevator arrives and opens its doors, or

• Beginning when the passenger pushes the floor request button and ending when the elevator arrives at its destination and opens its doors.

Other examples of transactions are alarms and (reliable) bus messages. Alarms must persist as long as the dangerous condition is true or until explicitly handled, depending on the system. Alarms will typically have attributes such as

• Alarm condition

• Alarm priority

• Alarm severity^[8]

  ^[8] Priority and severity are orthogonal concepts. Priority refers to how a scheduler will resolve execution order when multiple events are waiting to be handled (and is a combination of importance and urgency); the severity refers to how bad the outcome of the fault condition may be if unhandled. These concepts are discussed in more detail in [5].

• Time of occurrence

• Duration of condition

Reliable message transfer requires that a message persist at the site of the sender until an explicit acknowledgement is received. This allows the sender to retransmit if the original message is lost. Bus messages typically have attributes such as

• Message type

• Priority

• Source address

• Target address

• Message data

• Cyclic redundancy check

6.3.9 Identify Persistent Information

Persistent information is typically held within passive objects such as stacks, queues, trees, and databases. Either volatile memory (RAM or SRAM) or long-term storage (FLASH, EPROM, EEPROM, or disk) may store persistent data.

A robot must store and recall task plans. Subsequent analysis of the system may reveal other persistent data. For example, the information in Table 6-6 may be persistent.

Table 6-6. Persistent Information Objects

Information	Storage Period	Description
Task plans	Unlimited	Programs for the robotic system must be constructed, stored, recalled for editing, and recalled for execution.
Errors	Between service calls	An error log holding the error identifier, severity, location, and time/date of occurrence will facilitate maintenance of the system.
Equipment alarms	Until next service call	Equipment alarms indicate conditions that must be brought to the attention of the user, even though they may not be errors. Tracking them between service calls allows analysis of the reliability of the system.
Hours of operation	Between service calls	Hours of operation aid in tracking costs and scheduling service calls.
Security access	Unlimited	Stores valid users, their identifiers, and passwords to permit different levels of access.
Service information	Unlimited	Service calls and updates performed can be tracked, including when, what, and by whom.

Such data can be used for scheduling equipment maintenance, and may appear in monthly or yearly reports.

6.3.10 Identify Visual Elements

Many real-time systems interact directly or indirectly with human users. Real-time system displays may be as simple as a single blinking LED to indicate power status or as elaborate as a full GUI with buttons, windows, scroll bars, icons, and text. Visual elements used to convey information to the user are objects within the user interface domain.

In many environments, user interface (UI) designers specialize in the construction of visual interaction models or prototypes that the developers implement.

For example, consider the sample screens for the elevator central control station shown in Figures 6-5 through 6-7.

Figure 6-5. Elevator Central Station Main View

Figure 6-6. Elevator Central Station Menu View

Figure 6-7. Elevator Central Station Zoom View

We see a number of common visual elements:

• Window

• Rectangle

• Rounded panel

• Horizontal scroll bar

• Scroll button (left, right, up, down)

• Button

• Menu bar

• Menu selection

• Drop-down menu

• Menu item

• List box

• Text

• Icon (for alarm silence)

Each of these is an object within the UI domain for the elevator central station. These UI objects are depicted in an object message diagram later in this chapter.

6.3.11 Identify Control Elements

Control elements are entities that control other objects. These are specific types of causal objects. Some objects, called composites, often orchestrate the behaviors of their part objects. These may be simple objects or may be elaborate control systems, such as

• PID control loops

• Fuzzy logic inference engines

• Expert system inference engines

• Neural network simulators

Some control elements are physical interface devices that allow users to enter commands. The elevator case study has only a few:

• Button (elevator and floor)

• Switch (elevator and floor)

• Keyboard (central station only)

• Mouse (central station only)

6.3.12 Apply Scenarios

The application of use case scenarios is another strategy to identify missing objects as well as to test that an object collaboration adequately realizes a use case. Using only known objects, step through the messages to implement the scenario. When "you can't get there from here," you've probably identified one or more missing objects.

In mechanical terms, this is done by refining the use case scenario. Remember from Chapter 5 that the structural context for a use case scenario is the system and the actors participating in the scenario. This means that a use case scenario cannot show objects internal to the system because they are not yet known. However, once you have identified and captured the set of objects in the collaboration, you can replace the single System object with the set of objects in the collaboration. This provides a more detailed or refined view of the scenario and ensures that the collaboration does, in fact, realize the use case.

For example, consider the use case scenario in Figure 6-8. It shows the black-box behavior of the pacemaker with respect to the actors Pacing Engine and Heart (and the Communications Subsystem). Using the object identification strategies previously mentioned, let's assume we can construct the model in Figure 6-9. We can now refine the scenario by elaborating the scenario with the set of identified objects, as shown in Figure 6-10. This is now a white-box view that we can relate directly to our black-box use case view. This more refined view of the same scenario, shown in Figure 6-8, shows how the objects in the collaboration work together. Note, for example, that when the Programmer instructs the pacemaker to go into AAI pacing mode, the Pacing Engine tells the Atrial Model to go to Inhibited model and the Ventricular Model to go to Idle mode. Figure 6-10 even shows the relationship between the scenario and the state models (not shown) of the Atrial Model and Ventricular Model objects.

Figure 6-8. Pace the Heart in AAI Mode (Use Case Level)

Figure 6-9. Pacemaker Object Collaboration

Figure 6-10. Pace the Heart in AAI Mode (Object Level)