1.8. Identifying Events

To repartition the system, you first need to identify all events. An event list is an inventory of all the events affecting a system. You can make your event list more useful by paying particular attention to how you name the events. Event names should describe what happens in the terminator to generate the data flow to the system and why the system cares.

An analysis rule of thumb says that external event names should begin with the terminator’s name. The second part of the name gives the reason that the terminator sends the data flow to the system (why the system is interested in the data flow). For example, Customer decides to pay for services tells you that the system is interested in the incoming customer payment. It is interested because receiving payments is a fundamental activity of the system. Moreover, this event name strongly indicates what the system’s response is going to be. Aircraft arrives in airspace also indicates the reason for sending the data and the likely response from the system.

Don’t name your events after the data flow. Such names as Customer payment arrives or even Aircraft position notified are not really descriptive. They give you no guidance as to where to start looking for the appropriate responses. Aircraft position notified almost suggests that the correct response is to simply record the position and wait for something else to happen, whereas Aircraft arrives in airspace suggests that the controller does whatever is necessary to route the aircraft safely through the airspace.

Temporal event names describe what it is time for the system to do. For example, Time to analyze accounts and Aircraft is ten minutes from landing tell you what processes form the response to the event.

The payoff for choosing good names comes when you build your event-response models. When a descriptive name is a clear guide to the system’s response, to why the system is reacting, it is easier for you to find all the details, and to know whether all the details you find are really part of the response.

For each event on the list, append the incoming and outgoing boundary data flows for the event. One event can cause any combination of data flows into and out of the context—you must find enough events to account for all the flows on the context diagram.

Now that you have traveled along the safe and steady path through the current physical model, you are in a better position to answer this question: “Could you have developed an accurate event list without first building the current physical model?” Your answer depends on whether you have had experience with similar systems. Now that you know what is involved, could you have built the event list with less current physical modeling? Or would you feel happy starting the event list and retreating to build a physical model whenever you needed more information?

Whether you can complete the event list earlier in the project depends mainly upon the amount of user knowledge, your own understanding of the business being analyzed, and your access to expert users. If these factors all are favorable, then you could probably start the analysis by building a context diagram, a rough data model, and an event list with very little current physical modeling. If you know the right questions to ask, your expert users can help you build event-response models just as they can help you build a current physical model.

You’ll naturally want to get the essential requirements for the system as quickly as possible. Do not spend any more time than absolutely necessary on the current physical model. Start your essential modeling as soon as you can and begin to produce an event list.