3.7. Review: Identifying Events

Your task was to name all the events. Let’s start with the data flow CAMPAIGN REQUIREMENTS, which is tagged to event 1. Since the flow comes from the terminator ADVERTISING AGENCIES, it’s an external event. Something happens in the agencies to cause this data flow to enter the Piccadilly context. We suggested that descriptive names for external events consist of the terminator’s name, and the reason that the terminator sends the system the data.

Following our suggestion and using the singular form, you’d name the first part of the event name “Agency.” Next consider the reason an agency sends CAMPAIGN REQUIREMENTS to Piccadilly. Remember, Stamford Brook told you, “Our clients are the advertising agencies, which are hired by companies that want to run advertising campaigns for their products.” So the reason that agencies send CAMPAIGN REQUIREMENTS to Piccadilly is they want to run a campaign. This means the event should be called Agency wants to run a campaign. So much for the first one. You should give the other events similarly descriptive names. (Ours are in the list in Figure 3.7.2.)

Figure 3.7.1: Piccadilly context diagram with tagged data flows. The numbers correspond to those in the event list in Figure 3.7.2.

Figure 3.7.2: Event list for Piccadilly.

You were also asked to annotate your list with all the data flows connected with each event-response. The current physical model for the Sales Department (Figure 3.6.5) reveals that SUGGESTED CAMPAIGN is output from this event-response. That gives us

1. Agency wants to run a campaign           CAMPAIGN REQUIREMENTS (IN)
                                         SUGGESTED CAMPAIGN (OUT)

Temporal events take place because the system has a contract with a terminator to provide information at a certain time. You begin temporal event names with “Time to,” and you add whatever the system is expected to do. For example, the information about the Programme Transmission Department in Chapter 1.4 The Piccadilly Organization told you, “Every quarter, finalized programme transmission schedules are sent to the Sales, Commercial Booking, and Research departments, as well as to the Broadcasting Board for its review. The version of the schedule that Perry sends to all of the agencies highlights the new high-rating programmes in the hope that it will encourage them to book their spots early.”

This description says that an event occurs whenever it is Time to finalize new programme schedule, and the associated output data flow is, naturally enough, PROGRAMME TRANSMISSION SCHEDULE. This is in our list as event 16. Notice the annotation 2:2 {PROGRAMME TRANSMISSION SCHEDULE} to indicate that two copies of the schedule leave the context of the system as a result of event 16. Your context diagram shows that one copy is sent to the advertising agencies and another is sent to the Broadcasting Board. We know there are three other copies of the schedule that are sent to internal Piccadilly departments, but you are not concerned with these internal flows when making your event list. For the moment you are focusing only on the context flows for each event because this will provide you with minimally connected subsystems, one for each event. Later, when you model the details of each event-response, you will deal with these internal flows.

Note that we are only dealing with the events that are caused by the flows in the context diagram. These flows concentrate on activities that are fundamental to the system. If your work in event partitioning caused you to identify other potential context flows and events that are concerned with maintaining the data, congratulations! You have exceeded requirements. We’ll come back later to discuss these other events.

A difficult part of this exercise is deciding exactly what is an event, and what is part of an event. Think of an event-response as a chain reaction that continues until all the resulting data flows have reached data stores or terminators.

The response may end before you expect. Take, for example, event 1 Agency wants to run a campaign. The incoming flow CAMPAIGN REQUIREMENTS triggers the sales executive into action. When the response generates the flow SUGGESTED CAMPAIGN, the action finishes. Because SUGGESTED CAMPAIGN goes to a terminator, and the system has to wait for the terminator’s action, that’s the end of the response. The executive now has to wait until the agency decides what it’s going to do. When the terminator does act, it is a separate event, and has its own response. The agency contact may call back soon to say that the campaign will run, or the agency may take a few days to call back. (When the agency responds, it is event 12.) The agency may never call back.

A response may generate some data flows that you didn’t expect. We show event 12 Agency chooses spots for a campaign with these data flows:

SELECTED SPOTS (IN)

AGREED CAMPAIGN (OUT)

PREEMPTION REPLACEMENT (OUT)

Why is PREEMPTION REPLACEMENT included as part of the response to this event? Why isn’t it the response to a separate event Spot is preempted? To answer this, let’s look at what happens when the flow SELECTED SPOTS arrives at Piccadilly (see Figure 3.7.3).

The agency tells the sales executive which spots are wanted for a campaign. The executive tells the Commercial Booking people about the agreed campaign so that they can put the spots on the breakchart. Sometimes, placing new spots on the breakchart causes spots from another campaign to be preempted. When this happens, the Commercial Booking people tell the appropriate sales executives, who each tell the agency concerned about the preemption and recommend a preemption replacement. In this case, PREEMPTION REPLACEMENT is part of the chain reaction when the system responds to an agency choosing spots for a campaign.

Figure 3.7.3: Event-response model for event 12 Agency chooses spots for a campaign. The numbers in the bubbles are those of the process in the current physical model. They are included to make it easier for you to relate this model to the diagrams in the current physical model.

Notice that the response to event 11 Agency wants to upgrade a spot can also produce the data flow PREEMPTION REPLACEMENT. When a spot is upgraded, it may displace another spot, which in turn may displace another, and so on. If there is no more room on the breakchart for the last displaced spot, it is preempted, and the chain reaction results in a PREEMPTION REPLACEMENT.

Don’t be tempted to group similar processes and call it one event. For example, all of the agency’s communications about spots might be lumped together under the name Agency changes its spots. This event would cover events 10, 11, and 12. Even if the agency sent the same type of message (say it used the same printed form for all three events), the response the system would make is different in each case. If the events require different responses by the system, they are different events. The result of following these guidelines is manageably sized subsystems, one for each event. Later on in the Project, you will model each event-response in detail and you will model the inter-event dependencies.

When you are satisfied with your efforts, proceed to your next assignment.