|
David C. Hay |
|
This paper presents a technique for tightly coupling models of business processes to those of data structure. It is largely based on the work of Chris Bird, John Hall, and Keith Robinson of Model Systems Consultants, Inc., although the technique was originally described by Michael Jackson (no, not the popular singer) in his 1983 book, System Development, and it is incorporated into the SSADM methodology widely used in Europe.
Oracle’s CASE*Method represents a particularly sophisticated approach to entity/relationship modeling, producing models which are both rigorous and accessible to users. The resulting models form a very good foundation for data base design.
The method is weaker, however, when it comes to capturing the essence of a company’s business functions rigorously enough and in enough detail to form a solid basis for developing software. The function side of analysis is explicitly separated from the data side, and the function hierarchy remains a somewhat subjective kind of model. The "CRUD" matrix. showing which functions create, retrieve, update, and delete which entities, provides some guidance for the way programs will use data, but without more rigor in the definition of functions, even this remains a weak tool.
In the 1970’s Ed Yourdon’s and Larry Constantine’s principles of structured design provided real guidance in defining modules, with rules for defining each module’s use of data. Unfortunately, however, the rules were defined in terms of third-generation programming languages, and don’t apply in the same way to fourth-generation languages and forms tools such as SQL*Forms.
The move towards an object-oriented approach to programming, however, and by extension to design and systems analysis, has provided some insights into modeling a business. Where CASE*Method represents data and function modeling as two parallel operations, object-orientation shows them as much more integrated, bringing together not only the function hierarchy and the data model, but other modeling techniques as well.
Figure 1 shows the three aspects of an organization that are the subject of most modeling techniques in use today, and how the techniques are related to them. The three aspects are:
The data model (entity/relationship model) provides a picture of the organization’s objects. (An "object" is an occurrence of an entity, and an "object class" is an entity.) The function hierarchy describes its functions. Events are not so much modeled as listed, but they play an important part in the other models.
The relationships between functions and objects are usually represented in function/entity matrices ("CRUD" matrices), showing which functions create, retrieve, update, and delete which entities. Relationships between events and functions are shown effectively in "essential data flow diagrams", as described originally by McMenamin and Palmer. The link between events and objects is shown by state/transition diagrams, described in, among other works, CASE Method: Function and Process Models, by Barbara and Richard Barker and Cliff Longman. This shows the sequence of states an entity goes through as it responds to events.
In the middle of the triangle is entity life histories, the subject of this paper. These models show the events that affect each entity and the operations (functions, activities) that are triggered as a result.
Figure 2 shows a portion of a data model for a purchasing and maintenance environment. The model describes purchase orders used to acquire materials and the work orders which consume them. The letters in parentheses next to the relationship names describe the referential integrity rules: "C" designates the "cascade" rule that if an occurrence of a parent entity is deleted, all children are to be deleted. "R" is the "restricted" rule that a parent may not be deleted if children exist.
The central entity in this model is purchase order, which is an agreement to pay for specified product types which are to be supplied by a party. A purchase order is itemized by line item, each of which is the fact that a particular product type has been specified in a particular purchase order.
An inventory is the fact that a location may be used to store a product type. (A location may store more than one, and a product type may be stored in more than one location.)
The entity representing transactions that move material in, out, and through the plant is movement. When a quantity of product type is received against a purchase order, for example, a movement is recorded from the line item where it was specified to a particular location. Should the product type be found to be faulty, it may be returned via a movement from the location to the line item (and by implication, to the vendor party).
When the time comes to use the product type, a work order is prepared authorizing that use, and material is drawn from an inventory to the work order, via a movement transaction. If not all the issued material is used, another movement transaction can reverse the process.
Sometimes it is necessary to move material from one inventory (location) to another, so another kind of movement records this. Sometimes also, physical counts of the inventory are done, and 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.
Attributes of some of these entities are shown in Table 1. The attributes are described here in "column" terms, including foreign and primary keys. Each attribute is shown to be fixed, replaceable, a foreign key, or part of the primary key. This determines, among other things, whether the attribute can be changed once it is set. An activity or operation may change the value of a replaceable attribute, but it could never change the value of a primary key or a fixed attribute.
| 1 | Inventory | Model number | |Compound |
|
Location ID |
|primary key |
||
|
Quantity |
Replaceable attribute | ||
| 2. | Line Item | PO number | |Compound |
| Line number | |primary key | ||
| Model number | Foreign key | ||
| Quantity | Replaceable Attribute | ||
| Price | Replaceable attribute | ||
| 3. | Location | Location ID | Primary key |
| Description | (Fixed? Replaceable) attribute | ||
| 4. | Movement | Movement ID | Primary key |
| Movement type ID | Foreign key | ||
| From line item | Foreign key | ||
|
From inventory |
Foreign key |
||
|
From work order |
Foreign key |
||
|
To line item |
Foreign key |
||
|
To inventory |
Foreign key |
||
|
To work order |
Foreign key |
||
|
Movement date |
Fixed attribute |
||
|
Quantity |
Fixed attribute |
||
|
5. |
Product type |
Model number |
Primary key |
|
Description |
Replaceable attribute |
||
|
6. |
Purchase order |
PO number |
Primary key |
|
Party (vendor) ID |
Foreign key |
||
|
Due date |
Replaceable attribute |
||
|
Terms |
Replaceable attribute |
||
|
Issue date |
Fixed attribute |
||
|
Closure date |
Fixed attribute |
||
|
Cancel date |
Fixed attribute |
||
|
Status |
Replaceable attribute |
McMenamin and Palmer, in their Essential Systems Analysis describe an essential activity as the complete response to an event. Each of the events listed above, therefore, corresponds to an essential activity, or in CASE*Method terminology, an "elementary business function". The function/entity matrix, then, can be modified to be a "event/entity" matrix. For example, this is shown in Table 3.
A few things should be noted about this matrix. First, where a relationship is "restricted", the deletion of one entity "reads" the controlling entity. For example, the event "Product type discontinuance" reads the entity line item, to see if it can be done. Similarly, where a relationship "cascades", the deletion of the parent entity also deletes all the children. For example discontinuing a product type also deletes all related occurrences of movement.
Also, whenever a child is created (for example, inventory), the parent entities are "read" (in this case, line item and product type).
Inventory |
Movement |
Line Item |
Product Type |
Location |
Purchase Order |
|
1. |
Product type definition |
C |
|||||
|
2. |
Product type description change |
U |
|||||
|
3. |
Product type discontinuance |
D |
R |
D |
|||
|
4. |
Purchase order issuance |
C |
R |
C |
|||
|
5. |
Purchase order change |
U |
R |
U |
|||
|
6. |
Purchase order close |
U |
|||||
|
7. |
Purchase order deletion |
D |
D |
||||
|
8. |
Location definition |
C |
|||||
|
9. |
Inventory definition |
C |
R |
R |
|||
|
10 |
Inventory discontinuance |
D |
D |
||||
|
11. |
Location discontinuance |
R |
D |
||||
|
12. |
Receipt of goods |
U |
U |
C |
U |
||
|
13. |
Return to vendor |
U |
U |
C |
U |
||
|
14. |
Transfer |
U* |
C |
||||
|
15. |
Adjustment |
U |
C |
Beginning with the top of the data model, Figure 3 shows the entity life history for movement. Each event is represented by a box. the entity whose history it is is shown by a round-cornered rectangle at the top.
Note that since movement is only a transaction event, occurrences are normally only created. this "Creation" may be either as a "Receipt of goods", "Return to vendor", "Transfer", or an "Adjustment of inventory quantity". (The complete model would also include movements associated with work orders, but they have been left out of this example to keep it simple.) The fact that only one option applies to the creation of an occurrence is represented by the "o" in the upper right corner of each event box.
Because it is reasonable to assume that occurrences of all entities are created, used and destroyed, it is possible to postulate the existence of an entity that was not evident in the event/entity matrix: "Movement deletion". This in turn is probably either one of two events: "Deletion of a purchase order", or the new "Deletion of a transfer or adjustment". These are shown to the right side of the model. Because the "cascade" rule applies to the relationship between movement and line item, "Line item drop" could also be a type of "Movement deletion". The cascade rule is probably provisional in this case, however, in that when a purchase order is being archived and dropped, presumably all line items should go with it, as should all movements attached to those line items. If the line item is simply being dropped from an active purchase order, however, probably the rule should be "restricted" — don’t drop any line items against which something has moved.
Figure 4 shows the entity life history for the inventory entity. An inventory begins its life by an "Inventory definition", and ends it either by an "Inventory discontinuance" (being discontinued as a place to store a particular product type), or by "Product type discontinuance" (discontinuance of the product type itself, cascading to include inventory.). Note that discontinuance of a location does not kill its inventory occurrences, since the restricted rule prevents deleting a location if any inventory occurrences exist.
In between an inventory’s definition and its discontinuance, and inventory may be subject to repeated "movements". the iterative nature of "movement" is shown by the asterisk (*) in the upper right corner of that event’s box. The set of movements constitute inventory’s "Inventory life". This is shown as a separate box in order to recognize that all occurrences of inventory have a life, even if for some it is a "null life" with no actual movements associated with it.
Each movement event must be one of those in the life history of the entity movement, with one exception: When a "transfer" occurs, not one but two occurrences of inventory are affected. An occurrence may be on the "to" side of the transfer event, or it may be on the "from" side. From the point of view of inventory, these are two kinds of events. For this reason, the "transfer" event appears twice, qualified in each case to indicate whether it is "in" (for transfers to the inventory) or "out" (for transfers from the inventory).
As before, note that any one "movement" must be only one of the optional kinds listed. Again, this is shown by the "o" in the upper right corner.
Note in the row above, however, that in the absence of an "o", all the events are expected to happen in the sequence shown in the course of the entity’s life. That is every inventory is expected to be subject to "Inventory definition", "Inventory life", and "Inventory discontinuance", in that order.
Figure 5 shows the entity life history for location. A location’s life begins with a "Location definition", and ends with a "Location discontinuance". In between, its "Location life" consists of one or more "Location events", each of which may be either an "Inventory definition" or an "Inventory end". Note that the events that affect inventory do not directly affect location, and they are not shown here. (In fact, location may be read for its "description" for example, but for simplicity, this is not shown.)
Figure 6 shows the entity life history for purchase order. It begins with "Purchase order issuance", and ends with the constructed event, "Purchase order end". In between its issuance and its end, its "Purchase order life" may consist of one or more "Purchase order transactions".
The life of the purchase order may consist of one or more "Purchase order events", each of which is either a "Purchase order change", a "Line item creation", or a "Line item deletion". A "Purchase order change" is the change of one of its replaceable attributes — in this case, "Terms change" or "Due date change".
The end of a purchase order is more complicated. Typically, a purchase order is not deleted when it is closed, but rather its status simply changes. "Normal end" takes several steps:
First, the last "Receipt of goods" on the last line item, changes the "status" attribute of purchase order" from "pending" to "complete". The policy of the company may be to consider the purchase order closed simply by virtue of having received all the material. Alternatively, it may be necessary for someone specifically to close the order, in which case that constitutes an event in its own right ("Purchase order close"). This is particularly the case where the last item received may be returned to the vendor ( "Return to vendor (last)"). Note that only the last occurrence of "Receipt of goods" and "Return to vendor" affects purchase order. Earlier ones have no effect.
(Note that only one of the events under "Normal end" is optional ("Return to vendor (last)"). This says that "Receipt of goods (last)", and "Purchase order close" must always happen. "Return to vendor (last)" This is not the way the situation is represented by Hall and Robinson, but their method is much more complicated.)
An alternative end for a purchase order occurs when it is canceled. "Purchase order cancel" changes the status to "canceled".
At some later date, regardless of how the purchase order was made inactive and depending on policies and schedules for archiving, the purchase order occurrence is physically deleted ("Purchase order deletion").
Figure 7 shows the entity life history for the component of a purchase order, the line item. Normally, the line item is born at the same time as the purchase order ("Purchase order issuance"). Once the purchase order has been created, however, line items may be added or dropped. The former is an alternative way to create a line item, and so "Line addition" is shown as one of the options for "Line item birth".
"Line item life", as with other lives, may consist of one or more "(Line item) events". Each replaceable attribute could change ("Price change" or "Quantity change"), material could be received against it ("Receipt of goods(not last)"), or material could be returned ("Return to vendor (not last)"). Note the "not last" designation. If it is the last receipt for a purchase order (or return of the last line item to be filled), the event is not part of the line item’s life, but rather it participates in its end. (Just to see if anyone actually reads this paper, the first five people contacting the author at 713-464-8316 before December 31, 1993 will receive a free copy of his new book on data modeling — when it is published in 1994.)
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 deleted subsequent to a "Canceled purchase order", or as the result of a "Line item drop". The normal end for a line item consists of first "Receipt of goods (last)", "Return to vendor (last)", and then, some time after the purchase order has been closed, through "Purchase order deletion". Note that since cancellation and closing of a purchase order merely change its status, and do not delete it, neither have any direct effect on line item.
The line item event "Purchase order deletion" is of course the same event as that which appears on purchase order’s entity life history. Deleting a purchase order according to the cascade rule also deletes all line items belonging to the purchase order. In fact, there are five other combinations of master and detail deaths.
Figure 8 shows the entity product type. Its first-level sequence of "Product type definition", "Product type life", and "Product type discontinuance" is much like that of the other entities we’ve seen. There are two kinds of "product type event — "Description change" modifies the product type occurrence itself, while the other three events affect its relationship with line item: "Purchase order issuance" will tie product type to a newly created line item, as will "Line item add"; "Line drop" will cut the link to a line item, just before the line item is deleted.
So far, we have diagrammed the relationships between events and object classes (entities). The next assignment is to fold in the functions (or activities). Actually, in this context, we will call them operations, since they are described at a very low level of detail. Specifically, operations are described in terms of the specific actions taken on various entities in response to each event. In object-oriented terms these are the behaviors or "methods" of each entity in response to each event or "message".
The principles of essential systems analysis say that the atomic process in the functional analysis of a business is that which is a complete response to an event. That is, complete external events and essential business activities have a one to one correspondence. To write programs, however, it is necessary to break these activities down into the manipulations appropriate to managing a body of data.
Table 3 lists the operations which respond to the events in purchase order’s entity life history. Figure 9 shows how these are added to the diagram.
The operations shown in Table 3 fall into the following categories:
For each entity life history, then, for each event, we can identify the definition, tying, cutting, and updating required.
The operations shown here can be made more sophisticated by adding the use of state variables, but that is beyond the scope of this paper. 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 entities. This model, called the "event process outline", takes an event (such as "Purchase order cancellation"), and shows the complete set of effects it has on various entities.
As described in the introduction, entity life histories bring together in one model the object classes, activities and operations, and events that constitute an organization’s operations. They present the effects of events and operations on entities in more business oriented terms than does a simple function/entity matrix, and they prepare the way for the object-oriented thinking about the behavior of entities.