Event Modelling: Entity Life Histories

Aims and Objectives

In this session you will be able to: Define ELHs and describe why they are used in systems analysis. Recognise the structure of an ELH. Describe ELH notation. Construct an ELH from a given example. Explain the use of state indicators.

1 What is an Entity Life History?

A major reason for building computer-based information systems is to provide up-todate and accurate information. Information is constantly changing or evolving, for example the number of beds available in a hospital, the price of petrol, and people's names and addresses. An information system must be able to keep track of these changes. Previous notes have described how the system is modelled from the viewpoint of information flows (DFDs) and from the viewpoint of the information (i.e. entities) that is held (ER modelling). Entity Life Histories (ELH) model the system from the viewpoint of how the entities/information in a system evolves over time. What the ELHs show is the full set of changes that can possibly occur to the entities/information within the system, together with the context of each change. Initially, each entity within a system is examined in isolation as this is a manageable unit of information to model. It is the stimuli of the changes that are modelled rather than the entity, a composite picture is formed, eventually specifying the full set of changes that will occur within the system. An ELH is a diagrammatic representation of the life of a single entity, from its creation to its deletion. The life is expressed as the permitted sequence of events that can cause the entity to change. An event may be thought of as 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.

1.2 Creation of Entity Life Histories

The necessary pre-requisites for the development of life histories is knowledge of the following three ELH components:

The system entities and their attributes. The events which affect one or more of the system entities during their lifetime in the system. A basic notation for describing graphically the chronological sequence in which the events and event sub structures may occur.
1

1.3 Structure of Entity Life Histories

The general form of an ELH follows certain conventions and has the appearance shown in figure one.
ENTITY NAME

BIRTH EVENT

MIDDLE LIFE EVENTS

DEATH EVENTS

ITERATION * OF EVENTS

Figure One Structure of an ELH Diagram The general structure of an ELH as shown in figure one shows that there exist three fundamental event types:

Birth Events Death Events Middle Life (or update) Events

The corresponding effects of these are that they cause an occurrence of the entity to be:

Created by the system. Deleted by the system. Modified in terms of changes to its attribute values.

Thus the initial questions to ask when attempting to identify life history events are:

How does the system get to know about this entity? Why does it leave the system? What causes changes to its attributes?

All ELHs contain two types of node:

Intermediate nodes and Leaf (or terminal) nodes.

In figure one Birth event, Iteration of events and Death event are all leaf nodes, Middle life events is an intermediate node. The root of the tree gives the name of the entity whose life we wish to analyse. An ELH diagram is constructed for each entity in the ER diagram.
2

The passage of time is assumed to be a uniform flow from left to right of the diagram. At time zero in the life of an entity the system gets to know about it by virtue of the arrival of one (or generally one of a set) of system events resulting in the creation of an occurrence of the entity in the system. The middle life, the period between birth and death, is typically a set of recurring or iterating events causing changes to the entity. This period represents the majority of the life of the entity in the system, as such this part of the diagram can get quite complex. Eventually, the life is terminated by the arrival of a 'death' event causing that entity occurrence to be deleted and removed from the system.

2 ELH Notation
The basic notation of life histories is used after event identification to record graphically the sequence in which events and event sub-structures may legally occur. No attempt is made to show how we recognise events - this task having been attempted before the charting commences. The number of distinct symbols for initial ELH work is limited to only three, which together with the convention for representing the passage of time, complete the notation. The symbols are:

Entity names, group headings and events. * 0 Event repetition or iteration. A selection between two or more events.

2.2 Control Structures

There are three control structures that can be applied to an ELH: 1. Event Sequence 2. Event Selection 3. Event Iteration

2.2.1

Event Sequence

A sequence is represented by a series of boxes reading from left to right as shown in figure two.

ENTITY X

Figure Two Event Sequence The box labelled A will always be the first to occur, followed by B which in turn is followed by C then D. This is the only possible sequence. Although the sequence may be thought of as 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. 2.2.2 Event Selection

A selection defines a number of effects or nodes that are alternatives to one another at a particular point in the ELH. Note that one, and only one, of two or more possible events will occur at a particular time in a sequence. A selection is represented by a set of boxes with circles in the top right corners as shown in figure three.

ENTITY X

Figure Three Event Selection As node A is at the beginning of the ELH, this diagram shows that an occurrence of entity X must be created by only one of three events: E, F or G.

2.2 3

Event Iteration

An iteration is where an effect or node may be repeated any number of times at the same point within an ELH. 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. An iteration is represented by an asterisk in the top right-hand corner of a box as shown in figure four.
ENTITY X

Figure Four Event Iteration 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 or may not occur.

2.3 The 'Levels' in an ELH

An ELH structure can extend to several levels of detail where each level is represented by a horizontal bar, immediately above which will be a group heading and below it the 'details' which collectively describe the construct of the heading. Life history structures should be minimal structures in terms of levels necessary to describe an entity's lifetime as a collection of system events. A fundamental requirement that directly affects the number of levels shown in particular situations is that since all the boxes below a horizontal line describe the construct of the box above it, the mixing of constructs in boxes below a horizontal line would result in a contradictory description. In practice this means that all boxes hanging below a horizontal line must have the same construct (sequence of event types, iterations or a selection). Whenever this requirement cannot be met, new levels and group headings must be introduced to rectify the situation.

3 Worked Example (Ashworth & Goodland, 1990)

Imagine that Maurice Moneybags has decided he wants to open a bank account at Cash & Grabbs Bank. When Maurice has persuaded Mr Cash, the manager, that he would be suitable as a customer, Mr Cash turns to his computer terminal and records Maurice's new bank account code in the system. The ER diagram of the bank computer system contains an entity called Bank Account. The event occurrence that creates the Maurice Moneybags occurrence of the entity Bank Account is the opening of the account by Mr Cash. This event occurrence and the ones that follow it are: Account opened for M. Moneybags Cash Deposit 2000 Cheque Cashed for 20 Direct Deposit 1000 Cheque Cashed for 20 Direct Deposit 2000 etc. Percy Penniless is another customer at the bank, the event occurrences that affect his bank account are: Account Opened for P. Penniless Pay Deposit by Credit Transfer 500 Cheque Cashed for 200 Cheque Cashed for 300 Cheque Cashed for 300 Other accounts may behave in similar ways, none of which are precisely the same. However, it is possible to build up a general picture that will fit all occurrences of Bank Accounts at the Cash & Grabbs Bank. Basically, all accounts are opened, and several deposits and several withdrawals may be made. The way that these events affect the entity Bank Account is shown in figure five.
Bank Account

Account Opened

Account Life

Account Closure

Account Deletion

Transaction

Pay Deposit

Direct Deposit

Cheque Cashed

Figure Five ELH for Bank Account (Cash & Grabb Bank)

This ELH shows that the first event to affect the entity Bank Account will be Account Opened for all occurrences. Next, the account has a life which is a series of transactions. Each Transaction is one of: a Pay Deposit, a Direct Deposit, or a Cheque Cashed. After an undefined number of Transactions have taken place, the Account will be closed and finally deleted.

4 Addition of State Indicators

A state indicator can be thought of as a data item within an entity that is updated every time an event affects it. This means that the value of the state indicator will show where in its ELH an entity is at any one time. The values given to the state indicator have no significance provided that each effect assigns a unique value to it. The convention is to start with a value of 1 and increment it by one each time an event affects an entity. The first thing to do is to assign a value to each of the effect boxes on the ELH as shown in figure six.
Booking

Booking Creation

Driver Allocation

Mid Life

Booking Finalised

End

Receipt of o Request

Vehicle o Relocation 3

Driver o Allocation 4

Agency o Allocation 5

Amendment

Booking o Cancellation 8

o Hire Period

Booking o Archive

Customer o Archive

Booking Request 1

Booking Confirmed 2

Booking Amendment 6

Booking Confirmed 7

Vehicle Departure 9

Possible Write-off

Invoice Issued 12

Vehicle o Return 10

Vehicle o Written off 11

Figure Six The Booking ELH with Partial State Indicators (Source: Ashworth & Goodland, 1990) The numbers underneath the effect boxes show the value that the state indicator has been set to after the event has finished affecting the entity occurrence. For example, after the occurrence has been created by the Booking Request event, the state indicator is set to the value '1'. Therefore, if we find that the state indicator of a Booking occurrence is '1', we know that it has been created but has not yet been confirmed. The state indicator values can be used to help in determining whether or not we can allow an event to affect an entity. If the state indicator is not equal to '1', the Booking
7

Confirmed event cannot be allowed to affect this entity. For each effect box on the ELH, we can define a set of values of the state indicator that are valid before the event can be allowed to affect the entity. These are added to the diagram in front of the 'set to' value, separated by a '/'. If there is more than one 'valid previous' value, these are separated by commas. If the 'set to' value of the state indicator is '4' and the 'valid previous' values are either '2' or '3', then the set of values shown underneath the box will be 2, 3/4. The Booking ELH now looks like figure seven.

Booking

Booking Creation

Driver Allocation

Mid Life

Booking Finalised

End

Receipt of o Request

Vehicle o Relocation -/3

Driver o Allocation 2,3/4

Agency o Allocation 2,3/5

Amendment

Booking o Cancellation 4,5,7/8

o Hire Period

Booking o Archive 8,12/-

Customer o Archive 8,12/-

Booking Request -/1

Booking Confirmed 1/2

Booking Amendment 4,5,7/6

Booking Confirmed 6/7

Vehicle Departure 4,5,7/9

Possible Write-off

Invoice Issued 10,11/12

Vehicle o Return 9/10

Vehicle o Written off 9/11

Figure Seven The Booking ELH with State Indicators (Source: Ashworth & Goodland, 1990) The state indicator values depend entirely upon the structure of the ELH:

Creation effects have a null valid previous value because the state indicator does not exist before the creation of the event. Where there is a selection, all effects that are alternatives to one another have the same set of valid previous state indicator values as shown by the Driver Allocation and Agency Allocation both having the valid previous values of 2 and 3. Where there is an iteration, the value set by the repeating effect will also be included as one of the valid previous values for that effect. This is shown by the fact that one of the valid previous values for the Booking Amendment effect is '7' which is the value set by the subsequent Booking Confirmed effect.

Source of State Indicators' for Figure Seven State Explanation Indicator -/1 Just beginning
8

1/2 -/3 2,3/4

Sequence (Booking Request & Booking Confirmation) Most recent state 1 Selection (Receipt of Request & Vehicle Relocation) If Vehicle Relocation selected then Just Beginning Selection (Receipt of Request & Vehicle Relocation) If Receipt of Request 2 If Vehicle Relocation 3 Selection (Driver Allocation & Agency Allocation) So identical Most recent state (Driver Allocation or Agency Allocation) 4 5 Because of iteration loop may have been done once, so most recent state is 7 (i.e. sequence Booking Amendment & Booking Confirmed) Sequence (Booking Amendment & Booking Confirmed) Most recent state 6 Most recent state from iteration sequence is 7 Iteration may occur zero or more times Selection (Driver Allocation & Agency Allocation) 4 5 Selection (Booking Cancellation & Hire Period) So identical Sequence (Vehicle Departure, Possible Write-off & Invoice Issued) Most recent state 9 Selection (Vehicle Return & Vehicle Written Off) So identical Most recent state from Selection Vehicle Return 10 Vehicle Written Off 11 Hyphen represents death Most recent state Invoice Issued 12 Selection (Booking Cancellation & Hire Period) 8

2,3/5 4,5,7/6

6/7 4,5,7/8

4,5,7/9 9/10 9/11 10,11/12

8,12/-

5.1 Entity Definition & Identification

In SSADM the entities will have been defined in the Logical Data Structure (also known as the Entity Relationship Diagram). In other methodologies the definition is more vague: 'something of interest in the problem domain', ' a thing about which information is held'. An entity can be either physical or conceptual i.e. a person or a project.
9

5.2 Event Definition & Identification

An event is something that happens in the real world to cause a change of state to the database. The 'trigger' that causes the event to occur may be as a result of three things: i) Externally generated, such as a training officer placing bookings for staff to attend a course; ii) Internally generated, such as course numbers falling below a critical level, so canceling the running of a course; iii) Time-based, such as the automatic rising of invoices at a set time of the month. In SSADM, the lowest level of the DFD should show us the events that will constitute the ELH. However, different naming conventions should be employed as more than one trigger may be required to activate the DFD process, each trigger being a different event. It therefore follows, that the same event can occur in more than one ELH.

5.3 Parallel Life

The ELH maps out the events that can impact upon an entity in the sequence in which they will occur. However, whilst most events can be modelled in such a sequence, some will happen at random. For example, a customer can change address whilst orders are still being processed: the customer record will need amending & so will the order record to show the new delivery address. Therefore, some updates to an entities attributes can occur at any point in the life history, the timing of such events can not be predicted and so cannot be placed in any particular sequence on the ELH diagram. Similarly, when such events do occur, they will not impact on the main sequence of events in the life history. These sorts of events are frequently concerned with the alteration of reference information to the entity. The structure we use to record this is a 'parallel life'. The construct is used when the sequence of events is not predictable or can occur concurrently. The notation to show a parallel life is the double horizontal bar (see below). There are no limits to the number of parallel lives allowed. Consider the following example

Parallel Life Construct

The parallel life indicates that transactions and overdrafts can occur at the same time..

5.4 Quits and Resumes

In the example below an account may be suspended and at some later point re-opened in which case it continues its account life. Note the use of the null selection - it is not an inevitable part of Bank Account that the account will be suspended.

10

Illustration of the Use of Quits and Resumes

The Q1 indicates the points at which the diagram is left and the R1 where it is rejoined. There may be more than one quit and resume on a diagram hence the number following the letter. If it is possible to quit from anywhere on a diagram a separate diagram can be created for the resume section.

6. How to Derive Entity Life Histories

In order to create Entity Life Histories SSADM suggests the following activities:

6.1 Create Entity / Event Matrix

A grid is created. Down the side of the grid we list all the entities identified during the creation of the entity-relationship diagram. Along the top of the grid we list all the events identified. An event is an action within a process which provides an update to a data store on the lowest level of the logical DFDs. Consider the following partial entity/event matrix for the entities 'Fossil'.
Catalogue Addition Fossil etc. 1 Loaned Returned Damaged M Returned Not Damaged M Lost

The entity/event matrix shows how many times an event can occur (1, many or none). From this the ELH can be drawn.

11

6.2 Draw First Cut ELH

We can now draw the ELH. Start with details entities from the LDS. Use constructs to represent the life of the entity.

ELH Derived from the Entity/Event Matrix of Figure above

6.3 Review Entity Life History

Consider the following: interaction between entities, particularly their disconnection and reconnection; abnormal death events (use separate Q and R); reversions i.e. resumption of normal life; random events using parallel life structure.

6.4 Add Operations

The end leaf of an entity represents the effect or action . The operations provide a way of describing these effects. The logical operations which should be documented are: Store <attribute>, keys, remaining attributes, <attribute> using <expression>; Replace <attribute>, <attribute> by <expression>; Tie to <entity> (establish relationship with master); Cut from <entity> (remove relationship with master); Gain <entity> (establish relationship with detail); Lose <entity> (remove relationship with detail). The addition of operations can be illustrated by the following example:

12

Illustration of Addition of Operations

6.5 Adding State Indicators

In the logical design stage of SSADM state indicators are added to ELHs. By adding state indicators to ELHs we can see which event occurred last and which event can occur. A state indicator is a numeric value which identifies the completion of an event. The following information is added to the end leaves of the ELH: valid previous values is a list of values a state indicator can have for the event to be allowed; value a state indicator is set to by the event. State indicators are added by: first adding set to values; then considering the sequence of events to determine the valid previous values. An example is shown below:

Illustration of the Addition of State Indicators

For more information on state indicators read the Goodland and Slater recommend reading (pp.329-341).

13