Making Your Entities Behave

Published in January 2003

The characteristic of object classes in object models that distinguishes them from entity types in entity type relationship diagrams is the specification of their behavior. Since system classes
(design artifacts) are themselves pieces of code, using a kind of pseudo code to describe this behavior in design object models makes sense. The behavior description can easily be included in an
extension of the object class box, as specified for the UML. See Figure 1 for an example from Martin Fowler.

Figure 1 : An Object Class (with behavior)

Here, “dateReceived”, “isPrepaid”, “number”, and “price” are all attributes. (UML provides for specifying the format of each attribute—”date”, “boolean”, etc.) The lines
“dispatch()” and “close()” are the names of program modules that carry out the behaviors of an Order. Behavior for an instance of a class (an object) is invoked in response to triggers (events)
sent from other objects.

It seems a reasonable extension to suggest, then, that when entity types representing things in the world are specified in requirements analysis, entity relationship models could also be extended
to represent the behavior of these entity types, along with their triggers. What steps, for example, are required to create an occurrence of person, and what causes these steps to be followed?

The problem is that the behavior of a real-world entity type is often much more complex than a simple list of steps. While it is appropriate to want to know what functions are performed around the
entity type, this is much more than a simple narrative added to an entity type box.

One way of addressing the question of an entity type’s behavior is to create a matrix associating each entity type with the activities that affect it. This is the “CRUD” matrix, that shows
which activities (c)reate, (r)etrieve, (u)pdate, and (d)elete each entity type.

A more sophisticated approach is the entity life history diagram. It is largely based on the work of Keith Robinson and John Hall of Model Systems Consultants, Inc.,
although the technique was originally described by Michael Jackson (no, not the popular singer), and it is incorporated into the “Structured Systems Analysis and Design Method” (SSADM) widely
used in Europe. The materials presented here are based on Messrs. Robinson and Hall’s 1991 white paper, Logical Data Modeling and Process Specification.

The entity life history diagram is a comprehensive representation of the things that happen to an entity type—the events that cause it to change state and the functions that are performed
when it does. It combines the data model with the state transition diagram for a more robust description of each entity type’s behavior than could be described in entity type boxes.

A Data Model

Figure 2 shows an example of a data model for a purchasing environment. The model describes contracts used to acquire materials. For purposes of this exercise, the referential integrity
constraints, usually documented behind the scenes, are shown explicitly. The letters in parentheses next to the relationship names describe the referential integrity rules: The symbol “(c)”
designates the “cascade” rule that if an occurrence of a parent entity type is deleted, all children are to be deleted. The symbol “(r)” is for the “restricted” rule that a parent may not be
deleted if children exist.

The central entity type in this model is contract, which is an agreement by a party to pay for specified asset types which are to be supplied by another party. A contract must be composed of one or
more line items, each of which must be for a particular asset type. Note the “(c)” by the relationship from contract to line item. This means that if a contract is deleted, all its associated
line items will be deleted as well. The “(r)” by each relationship from party to contract means that a party cannot be deleted if any contracts are associated with it.

An asset type is the definition of a product, material, or other physical thing of interest to the organization. A physical asset is a physical example of an asset type. An asset type, for example,
could be an IBM ThinkPad Model 600, as described in IBM’s advertising. A physical asset, then, is the ThinkPad 600 (serial number 47-DCH54) owned by your author.

A physical asset must be either a discrete item—uniquely identifiable with a serial number or something similar—or an inventory—a quantity of undifferentiated things. The
aforementioned author’s computer is an example of a discrete item, while fifty light switches in a hardware store is an example of an inventory.

Because a physical asset is a physical example of an asset type, it must be (currently) located at one and only one site. A site, in turn, is a location which serves a particular function,
such as a warehouse location, or a work center.

The entity type representing transactions that move material in, out, and through the plant is movement. When a physical asset is received against a purchasing contract, for example, a movement (a
receipt) is recorded both from the party (person or organization) that sold it and to a particular site. Should the physical asset be found to be faulty, it may be returned via another movement (a
return) from the site to the party that sold it.

Figure 2: Entity / Relationship Model
for a full page version of this graphic – click here

Sometimes it is necessary simply to transfer material from one site to another, so transfer (a kind of movement) records this. Sometimes the meaning of this entity type can also be
extended to include inventory adjustments based on physical counts of the inventory, and these inventory adjustments increase or reduce the balance. An increase can be recorded as a movement
to an inventory with no “from” indicated, and a decrease can be recorded as a movement from an inventory with no “to” identified.

To summarize, each movement may be from a site or from a party and may be to a site or to a party.

Note the business rule that says when a movement is of inventory from one site¸ the “Quantity” of the inventory (currently) located at that site
must be reduced by the “Quantity” of the movement. At the same time, if the movement is to another site, th “Quantity” of the inventory (currently) located at the destination site must
be increased by the movement “Quantity”. If a single discrete item is moved, the link to the from site must be disconnected and a new link to the to site must be created.


For purposes of this case study, the entity types shown in Figure 2 are subject to the events shown in Table 1, above.

Party                   What events cause a party…

      …to be born?       Party recognized
…to be changed?       Party data found incorrect
            …to die?*     Party no longer needed

Site                   What events cause a site…

      …to be born?       New site recognized
…to be changed?       Site description is incorrect
            …to die?*     Site not needed

Asset type                   What events cause an asset type…

      …to be born?       New asset type recognized
…to be changed?       Asset type data found incorrect
            …to die?*     Asset type discontinued

Physical asset                   What events cause a physical asset…

      …to be born?       Discrete item received (not last)
    Discrete item received (last)
    Inventory defined
…to be changed?       Inventory quantity found to be incorrect
    Inventory received (not last)
    Inventory received (last)
    Inventory found unsatisfactory (not last)
    Inventory found unsatisfactory (last)
           …to move?      Transfer of physical asset required
            …to die?*       Inventory no longer needed (and discontinued)
    Discrete item found obsolete (and deleted)
    Discrete item found unsatisfactory (not last)
    Discrete item found unsatisfactory (last)

Contract                   What events cause a contract…

      …to be born?       Contract issued
…to be changed?       Contract found incorrect
    Contract closed
    Contract no longer needed (and canceled)
            …to die?*       Contract found obsolete (and deleted)

Line item                   What events cause a line item…

      …to be born?       New line item needed
…to be changed?       Price incorrect
    Quantity incorrect
    Physical asset received (not last)
    Physical asset received (last)
    Physical asset found unsatisfactory (not last)
    Physical asset found unsatisfactory (last)
            …to die?*       Line item no longer needed (and deleted)
    Contract found obsolete (and deleted)
Table 1: Events

Event / Entity Type Matrix

A first cut at describing the functions affecting each entity type is the function/entity type matrix (also known as the CRUD matrix, mentioned above). Each of the events listed above, therefore,
will trigger a function. The function/entity type matrix, then, can be modified to be a “event/entity type” matrix. For our example here, this is shown in Table 2.

A few things should be noted about this matrix. First, where a relationship is “restricted” (represented by “(r)” on the data model), an attempt to delete one entity type “reads” the
controlling entity type to see if the deletion is permitted. For example, the event “Asset type discontinued” reads the entity type line item, to see if it can be done. Similarly, where a
relationship “cascades”, the deletion of the parent entity type also deletes all the children. For example discontinuance of an asset type also deletes all related occurrences of movement. This
means it “deletes” movement.

Also, whenever a child is created (for example, inventory), the parent entity types are “read” (in this case, site and asset type).


Event Party site asset type phys-ical asset cont- ract line item move- ment
1 Party recognized C            
2 Party data found incorrect U            
3 Party no longer needed D       R   D
4 New site recognized   C          
5 Site description is incorrect   U          
6 Site not needed   D   R     D
  Asset Types              
7 Asset type recognized     C        
8 Asset type data found incorrect     U        
9 Asset type discontinued     D R   R  
10 Physical asset received (not last)   R(DI) R(DI) U(Inv)*
  U C (Receipt)
  Physical asset received (last)   R(DI) R(DI) U(Inv)*
U U C (Receipt)
11 Physical asset found unsatisfactory (not last)       U(Inv)
  U C (Return Inv, DI)
  Physical asset found unsatisfactory (last)       U(Inv)
U U C (Return Inv, DI)
12 New inventory defined   R R C      
13 Inventory quantity found to be incorrect       U     C (Inv. Adj.)
14 Transfer of physical asset required       U**     C (Transfer)
15 Inventory no longer needed (and discontinued)       D     D
16 Discrete item found obsolete (and deleted)       D     D
17 Contract issued R   R   C C  


Contract found incorrect         U    
19 Contract closed         U    
21 Contract no longer needed (and canceled)         U    
20 Contract found obsolete (and deleted)         D D D
  Line Items              
22 New line item needed    







Price incorrect          




Quantity incorrect          




Line item no longer needed  





Table 2: Entity Type/Event Matrix

NOTE: In the above list, these are events—something that happens in the world—not our reaction to what happens. Consequently, for example, you have “line item
no longer needed”, not “line item destroyed”. For clarity, though, in some cases, the typical response is included in parentheses. The operations carried out in response to events will be
described below.

In the following sections, we will take the set of events that affect contract, line item, and movement to assemble entity life histories for each of these.

The Drawings


Figure 3 shows the entity life history for contract. Contract is shown with attributes for “Contract number”, various dates, “Terms”, and “Status”. A particular contract begins with
“Contract issued”, and ends with a three-step process involving first being complete, then ending, and then finally being deleted when it is found to be obsolete. In between, as with the other
entity life histories we have seen, is “contract life”.

Specifically, the contract’s life consists of one or more “Contract events”, where each “Contract event” must be either:

  • “Contract found incorrect”, resulting in corrections being made to it,
  • “Party no longer needed”, resulting in an attempt to delete the party, which is thwarted because of the existence of the contract.
  • “New line item needed”, resulting in the addition of a line item to the contract.

Figure 3: Contract
for a full page version of this graphic – click here

Ending a contract takes place in one of two ways. Either it can be completed and closed, or it may be cancelled. It is not physically deleted until later.

First, the “physical asset received (last)” (on the last line item), changes the “status” attribute of contract” from “pending” to “complete”. If one or more of the purchased
physical assets is found unsatisfactory, they are returned to the vendor which sold them. Until the last occurrence of this, the state of the contract is unaffected by receipt of items against it.
(It might be appropriate to record receipt of a “not last” physical asset on a line item (see next section), but it is not appropriate to record that fact on a contract.) If the last occurrence
of “physical asset found unsatisfactory” happens after the last occurrence of “physical asset received”, this will be the transaction which completes the contract.

The policy of the company may be to consider the contract closed simply by virtue of having been complete. In this example, however, it is necessary for someone specifically to deem it complete and
close it. This is one of the options for “contract end”. An alternative way for a contract to end is to discover that it is “no longer needed”, and cancel it.

At some later date, regardless of how the contract was completed and ended, and depending on policies and schedules for archiving, the contract occurrence is “found obsolete”, and physically
deleted (“Contract deletion”).

Line item

Figure 4 shows the entity life history for a component of a contract, the line item. Normally, the line item is born at the same time as the contract (“Contract issued”). Once the contract has
been created, however, line items may be added or dropped. The former (“New line item needed”) is an event that is part of “Line item birth”, while the latter (“Line item no longer needed”)
is part of “Line item end”.

Figure 4: Line item
for a full page version of this graphic – click here

“Line item life”, as with other lives, may consist of one or more “Line item events”. Two events trigger changes to line item data (“Price incorrect” or “Quantity incorrect”). Other events
include “Receipt of physical asset (not last)”, and “Physical asset not satisfactory (not last)”. The “not last” means that all receipts and returns other than the last ones simply update or
query the line item, without affecting its life span. The last receipt or the last return is the signal that the line item’s life is over.

The options for ending a line item’s life are more complicated. A line item can end its life either as a “Normal line item end”, or it can be canceled when a “Line item [is] no longer
needed”, or it can end with a “Contract found obsolete (and deleted)” (as described above). The normal end for a line item consists of “Receipt of physical asset (last)” or “physical asset
not satisfactory (last)”.

Contracts and their line items may continue to exist in a closed state for a long time, until the “contract is found obsolete” and deleted, along with all of its line items.


Figure 5 shows the entity life history for movement. Note that since movement is a transaction entity type, occurrences are normally only created, although the first row in the diagram shows the
possibility of a movement’s being both created and deleted.

Creation may be triggered by one of the four events shown in the third row of the diagram, under “Creation”:

  • “Physical asset received”, which creates a movement, as well as either creating an occurrence of discrete item or updating the “Quantity” of an inventory.
  • Transfer [of a physical asset] required, which results in a movement that represents either a discrete item’s being unlinked from one site and linked to another, or one inventory’s
    “Quantity” being reduced and another’s incremented.
  • Physical asset not satisfactory, which results in a movement that represents the physical asset’s being returned to a vendor.
  • Inventory quantity incorrect, which results in creation of a movement to adjust it.

There are six circumstances under which a movement transaction might be deleted:

  • The party to which or from which things were moved is no longer needed (and deleted).
  • The site to which or from which things were moved is no longer needed (and deleted).
  • The line item under which the movement took place is no longer needed (and deleted).
  • The discrete item that was moved has been discontinued (and deleted).
  • Contract found obsolete (and deleted).
  • Inventory no longer needed (and discontinued).
Figure 5: Movement
for a full page version of this graphic – click here

Activity fragments

So far, we have diagrammed the relationships between events and entity types (object classes). The next assignment is to fold in the functions (or activities). In this context, we will call them
activity fragments, since they are described at a very low level of detail. It is only a collection of these that could be called an essential “business function”. Specifically, activity
fragments are described in terms of the specific data actions taken on various entity types in response to each event. In object-oriented terms these are the behaviors or “methods” of each entity
type in response to each event or “message”.

So, for example, the event “Contract issued” would be implemented by an essential activity, but this can be described by eight data-oriented activity fragments:

Create contract.
Tie contract to from party.
Tie contract to to party.
Create one or more line items, and tie each to the contract.
Set contract “Issue Date”.
Set contract “Due Date”.
Set contract “Status” to “open”.
Set contract “Terms”.

(The activity fragments for each of the other events are described in Table 3, below.)

In general, there are five combinations of parent and child deaths.

Parent’s death kills current children.
Parent’s death occurs after child’s death.
Parent’s death does not affect current children but prevents new children.
Parent’s death is the same event which causes the loss of the last child. (A soft example of this is the situation where closure of the last line item closes the contract.)
Parent’s death cuts a changeable relationship from parent to child.

Table 3 lists the activity fragments which respond to the events in contract’s entity life history.

Contract Issued

1. Create contract.
2. Tie contract to from party.
3. Tie contract to party.
4. Create one or more line items, and tie them to a contract.
5. Set contract (Status) to “open”.
6. Set contract (Issue date).
7. Set contract (Terms).
8. Set contract (Due date).

Contract found incorrect

9. Update contract (Terms).
10. Update contract (Due date).

Party no longer needed

11. Prevent deletion of PARTY

New line item needed

12. (4., above)

Physical Asset received (last)

13. Update contract (status) = “complete”.

Physical Asset found unsatisfactory (last)

14. Update contract (status) = “open”.

Contract deemed complete (and closed)

15. Update contract (status) = “closed”.
16. Update contract (closure date).

Contract no longer needed

17. Update contract (status) = “canceled”.
18. Update contract (cancellation date).

Contract found obsolete

19. Cut contract occurrence from from party.
20. Cut contract occurrence from to party.
21. Delete each line item for this occurrence of contract.
22. Delete contract occurrence.

Table 3: Activity fragments

The activity fragments shown in Table 3 fall into the following categories:

Occurrences are created, initializing key attributes and sometimes other (fixed and replaceable) attributes.
Relationships between a parent and its children may be tied, cut, or swapped.
“Non-key” attributes may be set. Replaceable attributes may be replaced, initialized, incremented, or decremented as frequently as necessary.
Unique identifier attributes may not be changed. Fixed attributes and non-changeable relationships may not be changed once they are set, but they do not necessarily have to be set when the
occurrence is created.
Occurrences and their children (if permitted) may be destroyed, after being cut from their parents.

For each entity life history, then, for each event, we can identify the definition, tying, cutting, and updating required. Figure 6 shows the activity identifiers attached to each triggering event
in the entity life history.

The activity fragments shown here can be made more sophisticated by adding the use of state variables, but that is beyond the scope of this book. Also subject to further discussion is the process
of rotating the model ninety degrees so as to capture the full effects of an event on all entity types. This model, called the event process outline, takes an event (such
as “Contract cancellation”), and shows the complete set of effects it has on various entity types. A variation on this latter technique is used in object oriented design and called a
sequence diagram in the UML.

Figure 6: Activity fragments
for a full page version of this graphic – click here


This technique is not for the faint-hearted, nor is it recommended if you do not have a CASE tool to support it. Just writing this article was difficult, making sure that the events listed in the
CRUD matrix matched those on the diagrams.

However, the technique reveals a great deal about the nature of the environment in which the entity types exist, and this provides a very good basis for the object-oriented design that will take
place based on the entity/relationship diagrams.

Share this post

David Hay

David Hay

In the Information Industry since it was called “data processing”, Dave Hay has been producing data models to support strategic and requirements planning for thirty years. As President of Essential Strategies International for nearly twenty-five of those years, Dave has worked in a variety of industries and government agencies. These include banking, clinical pharmaceutical research, intelligence, highways, and all aspects of oil production and processing. Projects entailed defining corporate information architecture, identifing requirements, and planning strategies for the implementation of new systems. Dave’s recently-published book, “Enterprise Model Patterns: Describing the World”, is an “upper ontology” consisting of a comprehensive model of any enterprise—from several levels of abstraction. It is the successor to his ground-breaking 1995 book, “Data Model Patterns: Conventions of Thought”–the original book describing standard data model configurations for standard business situations. In addition, he has written other books on metadata, requirements analysis, and UML. He has spoken at numerous international and local data architecture, semantics, user group, and other conferences.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept