Object Life History

This prototyping technique goes by many names. The object life history is a state model (also known as a state transition diagram) that shows which states the objects for a class (sometimes called entities) may take, and illustrates the transitions between those states. Whatever you call it, the idea is to take a key business objectone whose subject matter is the concern of a number of use casesand use a state model to show the things that might happen to that object during its lifetime. When you have completed the life history of the object, consider whether there are sufficient functional requirements to cover all the happenings.

Maiden, Neil, and Suzanne Robertson. Integrating Creativity into Requirements Processes: Experiences with an Air Traffic Management System. International Conference on Software Engineering, May 2005.

Figure 12.10 shows a state model for a road, one of the more important business objects in the IceBreaker system. A state is a steady condition for the object, and each rectangle in the model identifies a different state that this object will be in at one time or another. For example, the road object is normally in the condition of being safe for use. It continues in that steady condition until something happens to change the state. In this case, the safe state is interrupted by a prediction that, due to ice formation, the road is about to become unsafe for traffic.

Figure 12.10.

This state model or object life history for the business object Road identifies the states in which a road can exist and the events that cause a transition from one state to another.

Once that interruption happens, the road is in a different state. It will remain in the unsafe state until something else happens to change it. The diagram indicates that there are three possibilities: (1) the road can be treated, in which case it moves back to being safe; (2) the surface temperature can rise enough so the ice melts; or (3) enough ice can form to make the road truly dangerous, in which case it is closed to traffic. Treating it or waiting for the ice to melt is the way to make this road safe to use again.

What's the point of this model? The story. In this example it is the story of a road and the things that might happen to it within the scope of the work that we are studying. Here is part of this story:

"When the A1(M) road was predicted to be unsafe for use last January, we could not treat it before it became unsafe for use and we had to close the road."

You can see this part of the story reflected in the state model in Figure 12.10.

The story is told not so much by the states, as by the transitions between states.

The story is told not so much by the states, as by the transitions between states. These transitions are caused by the business events that affect the work. Using Figure 12.10 as an example, "Ice formation predicted" is a transition brought about by business event 8, "Time to detect icy roads."(Chapter 4 has a complete list of business events for IceBreaker.) "Road treated" is the result of business event 9, "Truck treats a road." If you examine the state model, you should be able to correlate all of the transitions with the business events.

When we built the first version of this model, we found that we had the requirements for all the events shown in the object life history model, except one. Our original model said that a closed road becomes safe for use when it is treated. When we showed this model to a user, he pointed out that the road would also become safe when the ice melts. We had missed this transition out of the "Road closed" state.

Thus the model told us that there are more requirements. In fact, it identified a new business event, "Time to monitor closed roads, " to see whether the roads have become safe without treatment. The new business event should added to the context model, and the business use case explored and its requirements written.

We suggest you build object life histories for the key business objects. Your intention is to discover more about the work and to unearth any additional business events that must be taken into account.