LESSON 2.

1 ENTITY LIFE HISTORIES (ELH) (ASHWORTH90)

Learning Objectives:

After this lesson the student will be able to understand:

Why Entity Life Histories (ELHs) provide us with our third view of the system?
The Differrent views of the system ( the dynamic sequence, or time-based view of the
system),
How to construct sequence, selection and iteration diagrams in ELH.

Keywords and Phrases

LEARNER

Entity Iteration

Entity Life Histories Parallel Structures

Sequence

Selection

Introduction

A major reason for building computer-based information systems is to

provide up-to-date and accurate information. Information is constantly changing,
for example the number of beds available in a hospital, the price of gasoline,
peoples names and addresses. An information system (IS) must be able to keep
track of those changes. ELHs model the system from the viewpoint of how
information is changed. They show the full set of changes that can possibly
occur to manage information within the system, together with the context of each
change.
Initially, each entity within a system is examined in isolation, as this is
manageable unit of information to model. It is the stimuli of the changes that are
modeled rather than the processes that operate to implement those changes. By
specifying the set of changes that will occur within the system.
 An ELH is a diagramatratic representation of the life of single entity from
its creation to its deletion. The life is express as the permitted sequence of
events that cause the entity to change. An event may be thought of us whatever
brings a process into action to change entities, so although it is a process that
changes the entity, it is the event that is the cause of the change.

BANK
ACCOUNT

ACCOUNT ACCOUNT ACCOUNT

OPENED LIFE ACCOUNT DELETION
CLOSURE

TRANSACTION

PAY DIRECT CHEQUE

DEPOSIT DEPOSIT CASHED

Figure 1.ELH
The elements of the notation used in this example are:
Sequence: the boxes read left to right from Account Opened to Account
Deletion. Thus Account Closure must happen before Account Deletion.
Selection: the boxes with small circles in the top right corners are alternatives
for one another, so each Transaction is one of Pay Deposit, Direct Deposit or
Cheque Cashed.
Iteration: the box with the asterisk in the top right corner represents iteration,
many Transactions can occur one after another.
All the elements of the notation are described in detail in the next section.

Terms and Notation

An entity may be affected by several different events. In the banking

example the events Account Opened, Pay Deposit, Direct Deposit, Cheque
Cashed, Account Closure, and Account Deletion all affect the entity Bank
Account.
 An event may also affect several entities. For example, when a Bank
Account was opened, a Rosicar Escober occurrence of the entity, Customer
would also have been created. The event Account Opened affects two entities:
Bank Account and Customer.
Thus an entity can be affected by a number of events, and an event may
affect a number of different entities. To describe the particular interaction
between a single event and a single entity, the term effect is used. The box on
the Entity Life History of Bank Account represents the Event Account Opened on
the entity Bank Account. Although the box represents the effect of the event the
name inside the box is always the name of the event.
Within an Entity Life History Diagram, the effect boxes have no other
boxes directly beneath them. Intermediate boxes with other boxes directly
beneath them are called nodes. Nodes have no significance other than in
expressing the valid event sequences within the context of Entity Life History
Diagram. Within an Entity Life History Diagram, the names in the boxes will
reflect the names of events if they are effect boxes and the names will reflect a
particular section of the Entity Life History if they are node boxes.
An Entity Life History diagram is constructed for each entity on the Logical
Data Structure. The entity is placed in a box at the top of the diagram, and all
possible progressions through the life of the entity are overlaid on one another, to
form a picture that fits every occurrence.

Entity Life History diagrams use the following diagramming components:

1. Sequence.
2. Selection.
3. Iteration.

All Entity Life Histories can be built up using just these three components.
However, certain complex situations can be simplified by the use of two other
conventions:
4. Parallel Structures.
5. Quit and resume.
For clarity, the diagramming component types may not be mixed at the same
level within the same part of the diagram. Thus, an iteration may not be placed
at the same level as a sequence; instead. A node is placed within the sequence
and the iteration dropped down a level. The component types are described
here, but their use within SSADM is described in later sections.

Sequence

A sequence is represented by a series of boxes reading from left to right

as shown in Fig 2.
ENTITY X

A B C D
 Figure 2.ELH

The box labeled A will always be the first to occur followed by B, which in
turn is followed by C then D. This sis the only possible sequence. Although the
sequence may be thought of us a progression through time, there is no indication
of the time intervals between the boxes within a sequence. These could span
minutes, hours, days, or years.

Selection

A selection defines a number of effects or nodes that are alternatives to

one another at a particular point in the Entity Life History. A selection is
represented by a set of boxes with circles in the top right corners as shown in Fig
3 ELH.

ENTITY X

A B C D

E F G

Fig. 3 ELH.
As node A is at the beginning of the Entity Life History, this diagram
shows that an occurrence of entity X must be created only one of three events:
E, F or G. If there is a requirement to show that one of the options need not be
selected, a null box may be added as shown in Fig4 ELH. This extension to the
banking example shows that a Bank Account could start with a Pay Deposit, a
Direct Deposit, or neither of these.

POSSIBLE
DEPOSIT

PAY DIRECT
DEPOSIT DEPOSIT
 Figure 4. ELH

The null box does not represent an effect or node, but is a notational
device to indicate the situation where something may or may not happen. If the
null box is selected, the Entity Life History continues directly to the next node or
effect.

Iteration

An iteration is where an effect or node may be repeated any number of

times at the same point within an Entity Life History. A restriction upon the
iteration is that each occurrence of the iteration must be complete before the next
begins. This is most relevant where a node is being repeated. Iteration is
represented by an asterisk in the top right hand corner of a box as shown in Fig 4
ELH.

ENTITY X

A B C D

E F G H
Figure 5.ELH
After entity X has been created by E, F, or G, the event H may affect the
entity any number of times. Here it is important to note that any number of
times includes none, so an iteration is another way of showing that something
may occur or it may not. However, the iteration must not be used where an effect or
node occurs either once or not at all. In this situation the null box is more
accurate as in Fig 4.

Parallel structures
 A parallel structure is used in the situation where effects or nodes occur in
no predictable sequence or concurrently. A parallel structure is shown as a
parallel bar on the Entity Life History diagram as in Fig 6 ELH. This represents
the situation where the sequence of K, L, and M occurs at this point in the Entity
Life History, and event N may affect the entity a number of times during this
sequence. The node I, representing the sequence, and the node J, representing
the iteration, are shown under the parallel bar.

ENTITY X

A B C D

E F G H

I J

K L M N

Figure 6.ELH
Figure 6 ELH could be drawn without the use of the parallel structure, as
shown in Fig 7 ELH. In order to shown that the event N may occur anywhere in
the sequence of K, L, and M, the iteration of N must be repeated several times.
The diagram is made much more clearly by the use of the parallel structure.

ENTITY
X

A B J K J L J M J D

H N N N N
 Figure 7. ELH
Quit and resume

The quit and resume conventions is used in situations where the

diagramming conventions excessively constrain the Entity Life History, or force a
very complex artificial structure in an attempt to model a particular situation. The
use of this convention allows a quit from one part of an Entity Life History
diagram to resume in another part of the diagram. In the simple case, the right-
hand side of a box on the diagram places a Q and a number, and a
corresponding R and the same number are placed by the left-hand side of a box
in another part of the diagram. This shows that the effect or node that follows in
sequence the box annotated with the Q is always the box annotated with the
corresponding R (See Fig. 6. ELH For an example, where Q1 and R1 are the quit
and resume, respectively.)
ENTITY X

A B C D

R1
E F G H *

I J

K L M N
*
Figure 8. ELH.
When an occurrence of entity X has been created by event F, the next
event to affect the entity will always be D and cannot be H, K, or N.
To avoid any ambiguity, Fig. 8. ELH could be redrawn to give the structure
shown in Fig. 9.ELH
 ENTITY X

P D

F G

A B C

E G H*

I J

K L M N*

Figure 9.ELH

Two new nodes, P and Q, have been introduced into the diagram to
ensure that objects of the same type remain at the same level. In practice, if
quits and resumes are all removed, the diagrams become very complex,
reducing the clarity of the diagrams. Thus a compromise between ambiguity and
clarity is made.
BANK
In the banking example, it ACCOUNT
is possible to reopen a bank account that has
been closed, but not yet deleted. In this case, the event Account Reopened
causes a quit back to the part of the Entity Life History before Account Closure.
This backwards quit is shown by Q1 and R1 in Fig.10.ELH
ACCOUNT ACCOUNT ACCOUNT POSSIBLE ACCOUNT
OPENED LIFE CLOSURE RE-OPEN DELETION
Another use of the quit and resume convention allows a quit from the main
structure of an Entity Life History, and a resume at a box on a stand-alone
structure. This is used where an event might occur at any time, altering the
sequence of the Entity Life* History.ACCOUNT
TRANS As it is impossible to predict where on the
RE-OPENED
diagram the quit mightACTIONoccur, no Q is placed on the structure. Instead, a
sentence indicating the area of the Entity Life History the quit might occur from
and the circumstances that cause the quit is placed at the bottom of the diagram.
The stand-alone
PAY
boxDIRECT
or substructure is annotated with the DEATH
CHEQUE
R that corresponds to
STRUCTURE
the QDEPOSIT
detailed in thisDEPOSIT
sentence. AnCASHED
example of this random quit is shown by Q2
and R2 in Fig. Here, the death of a customer may occur at any time after the

CUSTOMER CUSTOMER
DEATH DELETION

Figure 10. ELH

account has been opened. If a customer dies, the normal sequence is no longer
applicable and this account is placed into suspension. The account is deleted
when the customer is finally deleted from the system.

BANK
ACCOUNT

ACCOUNT ACCOUNT ACCOUNT POSSIBLE ACCOUNT

OPENED LIFE CLOSURE RE-OPEN DELETION

TRANS * ACCOUNT
RE-OPENED
ACTION

DEATH
PAY DIRECT CHEQUE STRUCTURE
DEPOSIT DEPOSIT CASHED

CUSTOMER CUSTOMER
DEATH DELETION

Figure 10. ELH

Q2: Quit from anywhere on Customer death to R2

If necessary, it is permitted to quit from this substructure back into the

body of the Entity Life History.
In general, it is possible to have more than one quit point with the same
identifier on the same diagram, but there must only be resume point with the
same identifier to avoid ambiguity.

More examples..

Figure 11 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.
 Figure 11: Inventory

In between an inventorys 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 events box. The set of movements
constitute inventorys "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 entitys life. That is every inventory is
expected to be subject to "Inventory definition", "Inventory life",
and "Inventory discontinuance", in that order.

Location
Figure 12 shows the entity life history for location. A
locations 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 12: Location

Purchase Order
Figure 13 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".
 Figure 13: Purchase Order

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

Line Item
Figure 14 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".
 Figure 14: Line Item

"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 items life, but rather it participates in its end. The
options for ending a line items 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 orders 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.
Masters death kills current details.
Masters death occurs after details death.
Masters death does not affect current details but
prevents new details.
Masters death is the same event which causes the
loss of the last detail. (A soft example of this is the
situation where closure of the last line item closes
the purchase order.)
Masters death cuts a changeable relationship from
master to detail.

Product Type
Figure 15 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 weve 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.
 Figure 15: Product Type

Operations
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 1 the operations which respond to the events in purchase

orders entity life history. Figure 17 shows how these are added
to the diagram.

Purchase Order Issuance

1. Create purchase order.
2. Tie purchase order to party
3. Create one or more line items, and tie them to a purchase
order.
4. Set purchase order(Status) to "open".
5. Set purchase order(Issue date).
6. Set purchase order(Terms).
7. Set purchase order(Due date).

Purchase order change

o Update purchase order (Terms).
o Update purchase order (Due date).

Line addition
10. (3., above)

Line drop
11. Cut line item from purchase order (before deleting
the line item.)

Receipt of goods (last)

12. Update purchase order(status) = "complete" .

Return to vendor (last)

13. Update purchase order (status) = "open".

Purchase order close

14. Update purchase order (status) = "closed".
15. Update purchase order (closure date)

Purchase order cancellation

16. Update purchase order (status) = "canceled".
17. Update purchase order (cancellation date)

Purchase order deletion

18. Cut purchase order occurrence from party
 19. Delete each line item for this occurrence of purchase
order.
20. Delete purchase order occurrence.

Table 1: Operations

The operations shown in Table 1 fall into the following

categories:

Occurrences are created, initializing key attributes

and sometimes other (fixed and replaceable)
attributes.
Relationships between masters and details 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.
Primary key attributes may not be changed. Fixed
attributes and non-changeable foreign keys 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 masters.

For each entity life history, then, for each event, we can
identify the definition, tying, cutting, and updating required.
 Figure 18: Operations

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

Reading Assignment:
 Link:

E-Journals/E-Books
PUP website: infotrac.galegroup.com/itweb/pup
Password: powersearch

Exercises/Written Assignment:
Case No. 1

Draw an ELH for the application entity in the following scenario:

An applicant to the L.J.M.U. sends in an application form. From the details contained on
the application form the applicant is either rejected, given a conditional offer or given an
unconditional offer.

If an unconditional offer is made, then the offer may either be accepted or rejected by the
applicant.

If a conditional offer is made then the applicant upon notifying the University of their
results will either be given an unconditional offer, which can be accepted or rejected or
they will be rejected by the University.

Case No. 2

Draw an ELH for the Account Entity in the following scenario:

A bank account is opened by Winston Smith at the BB Bank PLC. During the following
year Winston makes a number of transactions which are either deposits or withdrawals.
At the end of the year the account is audited and the interest due is added to the account.
On 12th February the following year Winston closes his bank account.

Case No. 3

Draw an ELH for the target entity in the following scenario:

In the Eurofighter 2000.75, the control system for target acquisition and destruction
operates as follows:

The pilot of the aircraft activates the TAD system (Target acquisition & destruction), the
system will then automatically seek any active infra-red sources within the current target
area. The pilot may override the target area definition if necessary. If no active infra-red
sources are detected, the system will inform the pilot of this fact, otherwise it will map
out onto the holographic head-up display, the targets identified and their status. The pilot
can either track a selected target, deactivate the system or engage the automatic firing
sequence. If the tracking option is selected the system will track the target until the pilot
deactivates the system. If the automatic firing sequence is engaged the system will select,
arm and fire appropriate weapons systems until the target is destroyed. Upon destruction
of the selected target, the pilot can either chose to track another target, engage the
automatic firing sequence for another target or deactivate the sequence.

References/Bibliography

Systems Analysis and Design in a Changing World, John SAtzinger, Robert Jackson and
Stephen Burd, 5th edition , Thomson Course Technology, 2009

Systems Analysis and Design, Allan Dennis and Barbara Haley Wixom, John Wiley and
Sons, 2000

Ashworth, Caroline; Goodland Mike; SSADM; A Practical Approach; Copyright

1990, McGraw Hill Book Co. (UK) Ltd.

Date, Chris, An Introduction to Database Systems, Vols. I and II. Fourth Edition.
Addison-Wesley, Reading, MA, 1987.

Dierkes, Meinoff;Antal, Ariane; Child John; Nonaka Ikujiro (eds.), Handbook of

Organizational Learning and Knowledge, Oxford University Press, 2001

Hawryskiewycz, IT Introduction to Systems Analysis and Design Second Edition;

Copyright

Hoffer, J. A, George J.F Valacieh, J.S, Modern Systems Analysis and Design
Copyright 1996 by the Benjamin/Cumming Publishing Co. Inc.

Kendall, Kenneth E; Kendall Julie E, 2nd Ed. Systems Analysis and Design
Copyright 1992 by Prentice Hall Inc.

Martin E. Modell, A Professionals Guide to Systems Analysis. Second Edition. United

States of America, 2003

Silver, Gerald A; Silver, Myrna L.; Systems Analysis and Design; Copyright 1989
by Addison-Wesley Publishing Company, Inc.