Row Three: The Architect s View

Team-Fly

---

 

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents
	Chapter 7.  Column Five: Timing

---

Row Three: The Architect's View

In Row Two of the Architecture Framework, the concern is with the business activities that take place in response to events such as those just described. Row Three is more concerned with the data-transformation activities responding to each event.

Events and States

One way in which the architect's view differs from the business owners ' is that the entity types subject to a Row Three state/transition diagram (for example) are those that have been generalized into an architect's data model. The state/transition diagram for Row Two presented in Figure 7.2, for example, might be very similar to one for Row Three, but in Row Three, instead of being described for a PURCHASE ORDER, the states are described for the more general concept, CONTRACT or ORDER.

Generalizing the entities in Row Three will, of course, also require us to generalize the states as well. Whereas a purchase order may go through many more specific states than are shown in the example in Figure 7.2, "pending", "complete", "closed", and " canceled " may be as specific as we can get in a Row Three model.

In addition, note that while the triggers of a Row Three state/transition diagram are still events in the world, the actions that cause the state change are data actions. That is, they are the creation, deletion, or modification of dataspecifically, in our example, of the data describing the CONTRACT . Moreover, the "state" of the entity type is the state of the data, not of the thing in the world that the data represent.

Two techniques are added to our repertoire as we move to the architect's view:

• Essential data flow diagram Organization and presentation of an enterprise's activities in terms of the events that trigger them.

• Entity life history Descriptions of the structure of the events and activities that affect each entity type.

Essential Data Flow Diagrams

As discussed in Chapter 4, Stephen McMenamin and John Palmer, in their 1984 Essential Systems Analysis , describe the essential data flow diagram. What is important about an essential data flow diagram (or the "essential" level in a function hierarchy) is that its structure is determined by the events in the world that affect the company. That is, an essential activity is defined as the complete response to an external event. To summarize what was written in Chapter 4, the process of developing an essential data flow diagram from a physical data flow diagram is as follows :

1. Explode the data flow diagram down to the lowest level that seems reasonable, producing a set of "activity fragments ".

2. Identify and remove nonessential activity fragments (mechanisms) . These include references to physical media, internal validity checks, buffers, and so forth.

3. Identify all the real-world events that impinge on the activity fragment . These are either temporal events or things happening in the outside world that cause the enterprise to react . These may be identified from the context data flow diagram. As described above, these might include such things as a customer inquiry, a customer order, receipt of purchased goods, a person applying for a job, and so forth. (We are not concerned here with internal events, such as the completion of a process.)

4. For each external event, identify the activity fragments that are carried out in response to that event.

5. Define a parent activity that encompasses these activity fragments that are the response to that event. This is a fundamental essential activity .

6. Examine the data stores used by the essential activities. Are there activities that update those stores? If so, define additional custodial activities. For example "Manage customer reference data" might be a custodial activity.

7. Eliminate any activity fragments that are not part of a fundamental or custodial essential activity.

It may be the case that a particular fragment is used by more than one essential activity. In this case it is appropriate to break out the fragment as its own essential activity.

Note from this description that an essential activity is not necessarily the lowest level at which a business can be described. The more atomic process fragments that comprise an essential activity are, however, specific to the company and, at least to some extent, are technologically bound. For example, instead of separately verifying an order, recording its receipt, and updating appropriate inventories, the company could employ new bar-coding technology that would do all the necessary checks, recording, and notification at the same time the shipment is moved into inventory.

Below the essential level, the activities are chosen by the enterprise as a mechanism for carrying out the essential business function. As a consequence, they could be changed in a new system. Consequently, while they may be the proper object of a business process re-engineering effort, they are not of concern in an analysis diagram. The analyst is interested only in the essential level and abovethe description of the things an enterprise must do, regardless of the technology it uses.

Thus, it is the events described in the Timing column that profoundly affect the definitions of activities described in the Activities column. In addition, it is events that ultimately determine the boundaries of business process engineering.

Entity Life Histories

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 objects (Row Four 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 7.3 for an example from Martin Fowler's 2000 book, UML Distilled .

Figure 7.3. An Object Class (with Behavior).

Here, "dateReceived", "isPrepaid", "number", and "price" are all attributes. (UML requires 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 Rows Two and Three, 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 an ORDER, and what causes them 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. We saw the function/entity type matrix in Chapters 3 and 4, and it is described further on page 267 below.

A more sophisticated approach is the entity life history diagram . 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 "Structured Systems Analysis and Design Method" (SSADM) widely used in Europe. The materials presented here are based largely on the work of Keith Robinson and John Hall of Model Systems Consultants, Inc. Specifically , the material is from their 1991 white paper, Logical Data Modeling and Process Specification . ^[1]

^[1] Your author wishes to express his particular appreciation to John Hall for his assistance with this chapter.

While the essential data flow diagram shows the relationships of events to activities, the entity life history diagram shows the relationship of events to data.

The entity life history diagram is a comprehensive representation of the things that can happen to an entity typethe 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 given in entity type boxes.

A Data Model

Figure 7.4 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.

Figure 7.4. Entity / Relationship Model.

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 LINE ITEM, each of which is to buy 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 the from and to relationships between PARTY and 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 similaror an INVENTORY a quantity of undifferentiated things. The aforementioned author's computer is an example of a DISCRETE ITEM , while a collection of 50 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 from the PARTY ( PERSON or ORGANIZATION ) that sold it 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.

Sometimes it is necessary simply to transfer material from one SITE to another, so TRANSFER records this. Sometimes the meaning of MOVEMENT 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 rules that say when a MOVEMENT is of INVENTORY from one SITE the "Quantity" of the INVENTORY at that SITE must be reduced by the "Quantity" of the MOVEMENT . At the same time, if the MOVEMENT is to another SITE, the "Quantity" of the INVENTORY at the destination SITE must be increased by the MOVEMENT "Quantity". If a single DISCRETE ITEM is moved, the link to its SITE must be disconnected and a new link to the destination SITE must be created.

Events

Each entity type is primarily controlled by the following events:

Party :	What events cause a PARTY...
	...to be born?	P ARTY recognized
	...to be changed?	P ARTY data found incorrect
	...to die? [a]	P ARTY no longer needed
Site :	What events cause a SITE...
	...to be born?	New SITE recognized
	...to be changed?	S ITE description is incorrect
	...to die?	S ITE not needed
Asset type:	What events cause an ASSET TYPE...
	...to be born?	New ASSET TYPE recognized
	...to be changed?	A SSET TYPE data found incorrect
	...to die?	A SSET TYPE discontinued
Physical asset :	What events cause a PHYSICAL ASSET...
	...to be born?	P HYSICAL ASSET received (not last)
		P HYSICAL ASSET received (last)
	...to die?	P HYSICAL ASSET found unsatisfactory (not last)
		P HYSICAL ASSET found unsatisfactory (last)
	...to be born?	I NVENTORY defined
	...to be changed?	I NVENTORY quantity found to be incorrect
	...to move?	Transfer of PHYSICAL ASSET required
	...to die?	I NVENTORY no longer needed (and discontinued)
	...to die?	D ISCRETE ITEM no longer needed (and destroyed )
Contract :	What events cause a CONTRACT...
	...to be born?	C ONTRACT issued
	...to be changed?	C ONTRACT found incorrect
	...to die?	C ONTRACT closed
	...to die?	C ONTRACT found obsolete (and canceled)
Line item:	What events cause a LINE ITEM...
	...to be born?	New LINE ITEM needed
	...to have its price changed?	"Price" incorrect
	...to have its quantity changed?	"Quantity" incorrect
	...to die?	L INE ITEM no longer needed

^[a] Note that to "die" in this case may simply mean to be rendered inoperative, not necessarily to be physically deleted from a database.

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). As stated above, an essential activity is the complete response to an event. Each event listed above, therefore, will trigger an essential activity or, in these terms, a function. The function/entity type matrix, then, can be modified to be an "event/entity type" matrix. Table 7.1, then, shows all of the events affecting each entity type.

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 "A SSET 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).

Note : In the above list, these are events something that happens in the worldnot our reaction to what happens. Consequently, for example, you have " DISCRETE ITEM no longer needed", not " DISCRETE ITEM destroyed". For clarity, though, in some cases, the typical response is included in parentheses.

Table 7.1. Event / Entity Type Matrix

#	Event	Party	Site	Asset type	Physical asset	Contract	Line item	Work order	Movement
	Party
1	P ARTY recognized	C
2	P ARTY data found incorrect	U
3	P ARTY no longer needed	D				R			D
	Site
4	New SITE recognized		C
5	S ITE description is incorrect		U
6	S ITE not needed		D		R				D
	Asset Type
7	A SSET TYPE recognized			C
8	A SSET TYPE data found incorrect			U
9	A SSET TYPE discontinued			D	R		R
	Asset
10	P HYSICAL ASSET received (not last)		R(DI) [a]	R(DI)	U(Inv) C(DI)	U	U		C (Receipt)
11	P HYSICAL ASSET received (last)		R(DI)	R(DI)	U(Inv) C(DI)	U	U		C (Receipt)
12	P HYSICAL ASSET found unsatisfactory (not last)				U(Inv) D(DI)		U		C (Inv Return) D (DI)
13	P HYSICAL ASSET found unsatisfactory (last)				U(Inv) C(DI)	U	U		C (Inv Return) D (DI)
14	New INVENTORY defined		R	R	C
15	I NVENTORY "quantity" found to be incorrect				U				C (Inv. Adj.
16	Transfer of PHYSICAL ASSET required		R(DI) ( to [b] )		U				C (Transfer)
17	I NVENTORY no longer needed (and discontinued)				D(Inv)				D
18	D ISCRETE ITEM no longer needed (and destroyed)				D(DI)				D
	Contracts
19	C ONTRACT issued	R		R		C	C
20	C ONTRACT found incorrect					U
21	C ONTRACT deemed incomplete (and closed)					U
22	C ONTRACT no longer needed (and canceled)					U
23	C ONTRACT found obsolete (and deleted)					D			D
	Line Item
24	New LINE ITEM needed			R		R	C
25	"Price" incorrect						U
26	"Quantity" incorrect						U
27	L INE ITEM no longer needed			R			D		D

^[a] "Inv" means INVENTORY; "DI" means DISCRETE ITEM

^[b] Note that if the movement is of INVENTORY , then two occurrences of INVENTORY are affectedthe "from" INVENTORY and the "to" INVENTORY .

Asset Type

An entity life history always has an entity type in the center of the top of the diagram. This is the entity type whose history is being characterized. The events that affect it are shown as boxes below it. There are three constructs for these boxes:

• Sequence the events on a row will be encountered in the sequence shown. This is the case if there are no special markings .

• Iteration an event may occur one or more times, or not at all. This is shown by an asterisk (*) in the upper right corner of the event box.

• Selection only one of the events shown in a row may occur for each occurrence of the event above. This is shown by a small circle (o) in the upper right corner of the event box.

Figure 7.5 shows the entity type ASSET TYPE , with its attributes "Model number", "Description", and "Standard Cost". The first row below the entity type is an example of "sequence", in that each occurrence of ASSET TYPE must first be "recognized", have a "life", and ultimately become "discontinued". Note that there are no special marks on these boxes.

Figure 7.5. Asset Type.

"Asset type life" consists of "Asset type event", an example of an "iteration". This is shown by an asterisk in the upper right corner of the box. During an "Asset type life" an ASSET TYPE may have one or more "Asset type events" or none.

Below "A SSET TYPE event" is example of "selection". For each "Asset type event", one and only one of the following events may occur:

• "A SSET TYPE data incorrect", resulting in correction of the data,

• "C ONTRACT issued", including the creation of associated LINE ITEMS referring to existing ASSET TYPES . (See the discussion of LINE ITEM below on page 276.)

• "New LINE ITEM needed", calling for creation of a LINE ITEM that refers to an existing ASSET TYPE.

• " LINE ITEM no longer needed", calling for deletion of the association between a line item and this ASSET TYPE.

• "New INVENTORY defined", resulting in creation of an INVENTORY of an ASSET TYPE .

• " PHYSICAL ASSET received", creating an occurrence of a PHYSICAL ASSET that is an example of the ASSET TYPE .

Note that the set of events that constitute the " leaves " of the hierarchy tree correspond exactly to events in the function/entity type matrix (Table 7.1, above).

Physical Asset

Figure 7.6 shows the entity life history for PHYSICAL ASSET . The PHYSICAL ASSET entity type is shown, along with its sub-types INVENTORY and DISCRETE ITEM. That is, as described above, a PHYSICAL ASSET must be either a specific DISCRETE ITEM , identified uniquely with a "Serial number", or simply an INVENTORY , whose "Quantity" may vary over time. Note that the attribute of PHYSICAL ASSET , "Identifier", is "inherited", so it applies both to DISCRETE ITEM and INVENTORY. (An "Identifier" is simply a sequence number uniquely identifying each PHYSICAL ASSET .)

Figure 7.6. Physical Asset.

A particular PHYSICAL ASSET begins its life when it is recognized, either by receipt of a DISCRETE ITEM or by definition of an INVENTORY .

The center of the diagram shows that a PHYSICAL ASSET'S "Physical asset life" consists of one or more "Physical asset events", or it may have none at all. Each "Physical asset event", in turn, must be either a "Movement life", or a "Reference life".

Note that, since there can be one or more "Physical asset events", one of them can be a "Movement life" and another can be a "Reference life". It is just that a single "Physical asset event" can be only one of those.

An occurrence of "Movement life" may consist of one or more "Movements". Each "Movement", then, must be affected by one of the events shown in the next row:

• "I NVENTORY received", which updates the "quantity" of an INVENTORY

• "I NVENTORY found unsatisfactory", which results in a MOVEMENT of the INVENTORY being returned to a vendor (the "quantity" is returned to its original value)

• "I NVENTORY "quantity" found incorrect", which results in its being updated

• "Transfer of PHYSICAL INVENTORY required", which results in either a DISCRETE ITEM being unlinked from one SITE and linked to another, or one INVENTORY "Quantity" being reduced and another incremented

An occurrence of "Reference life", similarly, consists of one or more occurrences of "Reference", where each "Reference" must be the occurrence of either "S ITE not needed" or "A SSET TYPE discontinued". In either case, the event results in an attempt to delete the specified entity type. This in fact may be thwarted by the existence of a PHYSICAL ASSET.

The effect of this structure is that a PHYSICAL ASSET event may be a combination of movementssay, receipt of INVENTORY plus finding INVENTORY unsatisfactory. Similarly, a PHYSICAL ASSET event may consist of more than one reference.

The "End of a PHYSICAL ASSET" must be from either "I NVENTORY no longer needed (and discontinued)", a "D ISCRETE ITEM found unsatisfactory" (and returned to a vendor), or a "D ISCRETE ITEM no longer needed (and destroyed)".

Site

Figure 7.7 shows the entity life history for SITE . S ITE is shown as an entity type with the attributes "Identifier" and "Description". A site's life begins with a "New SITE recognized" and ends with a "S ITE not needed". In between, its "S ITE life" consists of one or more "S ITE events". Each " SITE event" either recognizes that a "new INVENTORY [is] defined", identifies that the "site description is incorrect", recognizes that a DISCRETE ITEM is received, or recognizes that a "transfer (in) is required". Note that other events that affect INVENTORY do not directly affect SITE , so they are not shown here. (In fact, SITE may be read for its "description", for example, but for simplicity this is not shown.)

Figure 7.7. Site.

Note that the same Site event may appear in more than one entity life history. "Transfer (of a physical asset) required" affects both SITE and PHYSICAL ASSET.

Contract

Figure 7.8 shows the entity life history for CONTRACT. C ONTRACT is shown with attributes for "Contract number", various dates, "Terms", and "Status". A particular contract begins with "C ONTRACT 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".

Figure 7.8. Contract.

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

• "C ONTRACT found incorrect", resulting in corrections being made to it,

• "P ARTY no longer needed", resulting in an attempt to delete the PARTY , which is thwarted because of the existence of the CONTRACT, OR

• "New LINE ITEM needed", resulting in the addition of a LINE ITEM to the CONTRACT.

As was seen in the state/transition diagram for PURCHASE ORDER in Figure 7.2, ending a CONTRACT takes place in one of two ways. Either it can be completed and closed, or it may be cancelled. That model is not concerned if it is physically deleted.

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 are found unsatisfactory, they are returned to the vendor that 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. In the state/transition diagram for PURCHASE ORDER in Figure 7.2, this event changed its state to "Cancelled".

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 ("C ONTRACT deletion").

Line Item

Figure 7.9 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 7.9. Line Item.

"Line item life", like 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 "P HYSICAL 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 as a "Normal line item end", or it can be canceled when a "L INE ITEM [is] no longer needed". The normal end for a line item consists of "Receipt of physical asset (last)" or "physical asset not satisfactory (last)".

Movement

Figure 7.10 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 shows the possibility of a MOVEMENT 's being both created and deleted.

Figure 7.10. Movement.

Creation may be triggered by one of the four events shown in the third row under "Creation":

• "P HYSICAL 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

• P HYSICAL ASSET not satisfactory, which results in a MOVEMENT that represents the PHYSICAL ASSET' s being returned to a vendor.

• I NVENTORY quantity incorrect, which results in creation of a MOVEMENT to adjust it.

There are four 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 DISCRETE ITEM that was moved is no longer needed (and deleted).

• I NVENTORY no longer needed (and discontinued).

• The LINE ITEM under which the MOVEMENT took place is no longer needed (and deleted).

• C ONTRACT found obsolete (and deleted).

Activity Fragments

So far, we have diagrammed the relationships between events and entity types (or 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. Specifically, activity fragments are described in terms of the specific 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".

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. In other words, each of the events portrayed here triggers a single essential business activity. Moreover, each business event is atomic. And, while there may be component activities that constitute the way the work is carried out, the essential activity must complete in order to pass an entity from one business state to another. 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.

So, for example, the event "C ONTRACT issued" would be implemented by an essential activity, but this can be described by eight activity fragments:

1. Create CONTRACT .

2. Tie CONTRACT to from PARTY.

3. Tie CONTRACT to to PARTY.

4. Create one or more LINE ITEMS , and tie them to a CONTRACT .

5. Set CONTRACT (Issue date).

6. Set CONTRACT (Due date).

7. Set CONTRACT (Status) to " open ".

8. Set CONTRACT (Terms).

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

To understand how each of these activities works, however, it is necessary to understand the predicates of each of the entity types they will act upon.

Predicates (attributes and relationships) of some of the entity types are shown in Table 7.2. Each attribute is shown to be a fixed or replaceable attribute, a fixed relationship, ^[2] or part of the unique identifier. This determines, among other things, whether the predicate can be changed, once it is set. An activity fragment may change the value of a replaceable predicate, but it could never change the value of a unique identifier or a fixed predicate.

^[2] For the sake of this exercise, all relationships are assumed to be fixed. In a real situation it is possible that events could have the affect of reassigning a relationship to a different occurrence of an entity type.

Table 7.2. Predicates

	Entity Type	Predicate	Predicate Type
1.	ASSET TYPE	Model number	Unique identifier
		Description	Replaceable attribute
		Standard cost	Replaceable attribute
2-a.	INVENTORY	( PHYSICAL ASSET ) identifier	Inherited unique identifier
		( PHYSICAL ASSET ) unit cost	Inherited replaceable attribute
		Quantity	Replaceable attribute
		an example of ASSET TYPE	Inherited relationship
		(currently) located at SITE	Inherited relationship
2-b.	DISCRETE ITEM	( PHYSICAL ASSET ) identifier	Inherited unique identifier
		( PHYSICAL ASSET ) unit cost	Inherited replaceable attribute
		Serial number	Fixed attribute
		an example of ASSET TYPE	Inherited relationship
		(currently) located at SITE	Inherited relationship
3.	SITE	Site identifier	Unique identifier
		Description	Replaceable attribute
4.	CONTRACT	Contract number	Unique identifier
		Issue date	Fixed attribute
		Due date	Replaceable attribute
		Closure date	Fixed attribute
		Cancelation date	Fixed attribute
		Terms	Replaceable attribute
		Status	Replaceable attribute
		from PARTY	Fixed relationship
		to PARTY	Fixed relationship
5.	LINE ITEM	Line number	Part of compound unique identifier
		Quantity	Replaceable attribute
		Price	Replaceable attribute
		Total received	Calculated attribute
		part of CONTRACT	Relationship, part of compound unique identifier
		for ASSET TYPE	Fixed relationship
6.	MOVEMENT	Movement identifier	Unique identifier
		Movement date	Fixed attribute
		Quantity	Fixed attribute
		from SITE	Fixed relationship
		from PARTY	Fixed relationship
		to SITE	Fixed relationship
		to PARTY	Fixed relationship
		authorized by CONTRACT	Fixed relationship

These predicates are an important aspect of the activity fragments that take place in response to events.

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.

• The death of the last child causes parent's death. (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 7.3 lists the activity fragments which respond to the events in CONTRACT' s entity life history.

Table 7.3. Activity Fragments

C ONTRACT issued

1. Create CONTRACT .

2. Tie CONTRACT to from PARTY.

3. Tie CONTRACT to to PARTY.

4. Create one or more LINE ITEMS , and tie them to a CONTRACT .

5. Set CONTRACT (Issue date).

6. Set CONTRACT (Due date).

7. Set CONTRACT (Status) to "open".

8. Set CONTRACT (Terms).

C ONTRACT found incorrect

9. Update CONTRACT (Terms).

10. Update CONTRACT (Due date).

P ARTY no longer needed

2. Prevent deletion of PARTY

New LINE ITEM needed

3. (4, above)

P HYSICAL ASSET received (last)

4. Update CONTRACT (status) = "complete".

P HYSICAL ASSET found unsatisfactory (last)

5. Update CONTRACT (status) = "open".

C ONTRACT deemed complete (and closed)

6. Update CONTRACT (status) = "closed".

7. Update CONTRACT (closure date).

C ONTRACT no longer needed (and cancelled)

8. Update CONTRACT (status) = "canceled".

9. Update contract (cancellation date).

C ONTRACT found obsolete (and deleted)

10. Cut CONTRACT occurrence from from PARTY.

11. Cut CONTRACT occurrence from to PARTY.

12. Delete each LINE ITEM for this occurrence of CONTRACT.

13. Delete contract occurrence.

The activity fragments shown in Table 7.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 7.11 shows the activity identifiers attached to each triggering event in the entity life history.

Figure 7.11. Activity Fragments.

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 90 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.

---

Team-Fly

Top