CONSTRUCTING AN ELH Estate Agent case study During this section we shall be referring to the Estate Agent case

study reduced in an earlier unit. The case study is reproduced below: The Estate Agents case study Clients wishing to put their property on the market contact the estate agent, who records details of their house, flat or bungalow - including the area, price range and type of property. The property is later evaluated and measured independently by the estate agent. Potential buyers register their details and preferences with the estate agent. Weekly, the estate agent matches the potential buyer requirements with the available properties and sends them the details of selected properties. When a sale is completed, the buyer confirms that the contracts have been exchanged, property details are removed from the property file, and an invoice is sent to the client. On receipt of the payment, and where the client has not other property registered with the estate agent, their details are archived. The buyers details are also removed from the file.

Stage of constructing Entity Life Histories As with the other analysis and design models that have been considered in this module, constructing the Entity Life Histories is an iterative process. It involves continued consultation with users to furnish missing information and resolve anomalies that come to light as a result of this work. During the course of constructing the Entity Life Histories, the analyst will be required to create a first attempt at a model, then to add new events to the model that may not have been stated earlier on in the specification of requirements, but that are essential for a fully functioning system. There are usually 5 main steps (which may be repeated a number of times) in the construction of Entity Life Histories:

Step 1 Identify events Step 2 Classify events (with an Entity/Event Matrix) Step 3 Order the events (for each effected entity) Step 4 Add events to Entity Life Histories for each effected entity Step 5 Validate each Entity Life History

We shall examine each of these steps with reference to the Estate Agent case study.

Step 1: Identify Events Constructing the Entity Life Histories commences with the identification of events that affect the entities. Where Data Flow Diagrams have been produced, the events can be identified from the lowest-level Logical Data Flow Diagrams. Events are either the arrival of inputs, or temporal events such as At the end of the week . . . . . . These are identified on the Data Flow Diagrams by tracing back from data flows entering the data stores, to the originating input data flow into the process which causes the data store to be updated. Where data flow models have not been constructed, it is possible to make up a list of candidate events in the same way by identifying inputs and temporal events. Many events are also implicit in the description of the activities that the system must support, or have to be added as housekeeping events. Step 2 Classify Events (with an Entity/Event Matrix) Having listed the events, the next stage involves classifying these by identifying whether an event causes an entity to be created, deleted or modified. An entity/event matrix is a useful tool for analysing and classifying events. It is simply a grid or crossreference table, which shows the entities from the Logical Data Structure as column headings along the top of the grid, and lists all of the events in rows down the left-hand side. Each event listed will affect at least one entity, and perhaps in a different way in each case. The square(s) at the appropriate intersection(s) between event and entity are marked with :

C where the event causes an entity occurrence to be created M where an entity occurrence is modified. D where the event causes an entity occurrence to be deleted

Where an event may result in modification or creation (or modification or deletion) the following is used:

C/M where the event causes an entity occurrence to be created or where an entity occurrence is modified M/D where an entity occurrence is modified or where the event causes an entity occurrence to be deleted

The general form of Entity/Event Matrices is something like the following:

<event A> <event B> <Event C> <event Z>

ENTITY 1 C/M

ENTITY 2 C M

ENTITY N C M/D

Step 3 Order the events (for each effected entity) Once all events are believed to have been found for a particular entity, the order of the events needs to be identified. Where there are only 3 events identified, create, modify and delete, the ordering is very straightforward. Ordered events are usually shown in a table, the general form of which is:

<creation event> <modification event 1> <deletion event>

ENTITY C M D

This ordering exercise becomes more complex the more events there are, and the more C/M and M/D events identified. Step 4 Add events to Entity Life Histories for each effected entity Having identified the events and their order for each entity the Entity Life Histories are constructed using the entity/event matrix. A model is drawn for each entity to represent the sequence in which events may occur throughout its life history. Creation events are drawn on the left of the diagram. There may be a number of possible creation events, however, a given occurrence of the entity can only ever be created once. Thus, these events are options and can be drawn as optional children from a single creation node. If there is only one possible creation event, this is simply drawn as a sequence box on the left-hand side of the tree. Deletion events must be on the right of the diagram. As for creation events, there can only be one deletion event that affects an occurrence of the entity, so all the possible deletion events should be organised as options from a single deletion node. In the estate agents example, New Property Offered is the creation event for the Property entity, and Property Sold is the deletion event. The remaining events must occur between the creation and deletion events. If it occurs only once in a well-defined position, then it is a sequence box. If it may occur many times, then it is either an iteration box or the child of an iteration box. If only one out of a number of events can happen, then it is an optional box or the child of an optional box. The model is built up in this way by combining the various Entity Life History elements. A basic rule that must be adhered to when combining sequence, iterations and selections is that all of the nodes and leaves grouped directly under one parent must be of the same type. Conversely, each parent can have only one type of child sequence, iteration or selection.

Step 5 Validate each Entity Life History There are a number of validation tests that can be performed on an Entity Life History diagram. Some of these include:

Is the entity the root of the tree? Is there at least one creation event? Is there at least one deletion event? Does every event affect one or more attributes of the entity Is every attribute value set at least once, either at creation or during the lifehistory? Is each iteration box the only child of its parent? Are all the siblings of an optional box also optional?

For each advanced feature there may also be associated validations, for example:

Does every quit have a (unique) resume and do the labels match properly? (this advanced feature of ELHs is described in the Additional Content section of this unit).

At this stage an analyst usually needs to go back and iterate through the 5 steps again a few more times, using the first-pass ELH as a support for communication and clarification with users.