CHAPTER 6
The Life Cycle of an Object

Every object has a life cycle. An object’s main purpose might be minor and very specific, or it may be the object without which the system cannot function. No matter how significant an object is, every one must be created (C), read or reviewed (R), modified or updated (U), and purged or deleted (D). The object life cycle is thus represented by the acronym CRUD.

• What if we did not create a particular object? The responsibility for creating or setting up an object may belong to another group; the object is then out of scope for the system being analyzed. But we still need to identify who is ultimately responsible for the object—which group “owns” it. It may be necessary to build an interface to retrieve data related to the object from the other group or system.

• If we never have to read an object, there is no need for the object.

• What if we never have to update an object? This is possible if the responsibility for updating or modifying an object belongs to another group and therefore is out of scope for the system being analyzed. Most often, the owner of the object is responsible for maintaining data integrity.

• If we never delete or purge an object, we might face data explosion, in which the system gets overloaded with unwanted or unnecessary data. Obsolete or expired data may become part of normal processing and could slow the system down.

Using an Object Life Cycle Matrix

When you think you have finished your requirements gathering, as part of determining the completeness of your analysis, subject your events and objects to an object life cycle matrix like Table 6-1 to track life cycle activities and help ensure that all objects are created, read, updated, and deleted as necessary.

Refer back to Figure 3-2. Let’s say you’re analyzing the three events depicted in that figure: Customer makes a deposit, Customer makes a withdrawal, and Customer opens an account.

Think about the event Customer Makes a Deposit—what is happening to the object Customer? Is it being created, read, updated, or deleted? If the object Customer is being created, mark the column “C” under CRUD; if it is being read, mark the column “R”; if it is being updated, mark the column “U”; and, finally, if it is being deleted, mark the column “D.”

Then move on to the next objects Account and Deposit, asking the same questions. Continue the exercise until you’ve completed the matrix for all the events listed.

What does this table tell us? Start with the first column of objects, Customer. If we find that the object Customer is being created, but never read, updated, or deleted, two possibilities exist:

TABLE 6-1: Object Life Cycle Matrix

• The object is not required

• We are missing necessary events, such as a business requirement to retrieve information about the Customer under certain conditions.

Similarly, if you find that the object Customer is being read but was never created anywhere else, there is a problem. You need to find out where Customer information is being created, even if it is out of the scope of the target project, and ensure that Customer information is in fact available to the target system. If Customer creation is in scope, you have missed this event, e.g., Customer Opens an Account.

Or, instead of using the object life cycle matrix, you can add reading, updating, and deleting objects as events to your list of events. If you have defined 50 objects, you will end up with 50 such events:

• It is time to add/read/modify/delete Object 1

• It is time to add/read/update/delete Object 2

• It is time to add/read/modify/delete Object 50.

Then go through the list of business events you have documented, and identify which event allows you to read, update, or delete each one of the objects you’ve defined. When you find such events, you can delete the corresponding It is time to read/update/delete Object event.

For example, the objects Customer, Account, and Deposit participated in the event Customer makes a deposit. Based on the data flow diagram for this event (Figure 3-2), you know that the object Deposit was created and the objects Customer and Account were both used, or read. Therefore, the event It is time to create a deposit is not necessary because the deposit is created when the Customer makes a Deposit. You still must find an event in which the object Deposit is actually used (read), or when it is updated or deleted or archived. Under what circumstance will we ever need to get information about the deposit made by a customer? If it’s when a customer makes an inquiry about items in his or her statement, we have just found the missing event: A customer makes an inquiry about his account statement.

In Brief

As we analyze requirements, we strive to identify scope creep or find missing requirements. Both problems could derail system development. The CRUD analysis helps us identify these by pointing out the absence of necessary processes—creating, reading (using), updating, and deleting—in the life cycle of each object we are analyzing. If we determine that an object is not undergoing one of these processes, we can conclude that the object is not necessary or that we are missing at least one essential business event.