Published in TDAN.com 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.
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.
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.
Events
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…
Site What events cause a site…
Asset type What events cause an asset type…
Physical asset What events cause a physical asset…
Contract What events cause a contract…
Line item What events cause a line item…
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 |
| Parties | ||||||||
| 1 | Party recognized | C | ||||||
| 2 | Party data found incorrect | U | ||||||
| 3 | Party no longer needed | D | R | D | ||||
| Sites | ||||||||
| 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 | ||||
| Assets | ||||||||
| 10 | Physical asset received (not last) | R(DI) | R(DI) |
U(Inv)* C(DI) |
U | C (Receipt) | ||
| Physical asset received (last) | R(DI) | R(DI) |
U(Inv)* C(DI) |
U | U | C (Receipt) | ||
| 11 | Physical asset found unsatisfactory (not last) |
U(Inv) D(DI) |
U | C (Return Inv, DI) | ||||
| Physical asset found unsatisfactory (last) |
U(Inv) D(DI) |
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 | |||
|
18 |
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 |
R |
R |
C |
||||
|
23 |
Price incorrect |
U |
||||||
|
24 |
Quantity incorrect |
U |
||||||
|
25 |
Line item no longer needed |
R |
D |
D |
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
Contract
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.
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”.
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.
Movement
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).
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:
(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.
Table 3 lists the activity fragments which respond to the events in contract’s entity life history.
Contract Issued
Contract found incorrect
Party no longer needed
New line item needed
Physical Asset received (last)
Physical Asset found unsatisfactory (last)
Contract deemed complete (and closed)
Contract no longer needed
Contract found obsolete
Table 3: Activity fragments
The activity fragments shown in Table 3 fall into the following categories:
occurrence is created.
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.
for a full page version of this graphic – click here
Conclusion
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.
