3.9. Review: Refining an Event-Response

The event-response model that you have built in Chapter 1.9 Modeling an Event-Response is a collection of processes in the current system that reacted to the event. Now that you have brought the processes together, you can eliminate anything that does not contribute to the essence of the system.

We’ll start by eliminating the implementation processes, and then consider the data. You may feel more comfortable starting with the data model, and then determining which processes are necessary to support that data. If so, read our treatment of the data model before you look at the discussion of the processes.

Now let’s run bubble ENTER NEW AGENCY *1.7* through the Techn-O-Filter and see if any essential policy remains. The computer operator enters the NEW AGENCY FORM into the computer system as a NEW AGENCY TRANSACTION. The data dictionary definitions for NEW AGENCY FORM and NEW AGENCY TRANSACTION are identical, and this process does not have any other inputs or outputs. So the bubble does nothing more than transport data from one technology, the clerk, to another, the computer system. There is no essential policy here, and as you have already eliminated the process that received the NEW AGENCY TRANSACTION, you can do the same to ENTER NEW AGENCY *1.7*.

You are left with bubble ASSIGN AGENCIES TO EXECUTIVE *3.8*. At the moment, it is recording the new agency, as well as assigning the executive. You can, if you wish, split this functionality into two bubbles. We are leaving it as one as we think that the process is simple enough to specify. We can always break it up later should the need arise. The last physical detail we can remove from the bubble is the number *3.8* that ties it to the current physical viewpoint. The essential number of the bubble is 9 to tie it to event 9. The resulting model is in Figure 3.9.1.

Figure 3.9.1: The more essential event-response process model for event 9 New agency wants to do business. The implementation-dependent processes have been eliminated, but the current system’s data stores are still there.

Congratulate yourself if you raised the question “Should there be a data flow to the agency to tell who the assigned sales executive is?” This is a business policy question and can only be answered by the users. The analyst’s job is to raise the question. Detailed event-response modeling will help you to think of questions that may not have occurred to you before. To keep things simple, we’ll act the part of the users and answer that there is no need for a data flow back to the advertising agency.

1. It records the agency’s name, address, and phone number in the AGENCY ACCOUNTS FILE.

2. It looks at the SALES EXECUTIVE REGISTER to find the sales executive most suitable for selling to the new agency.

3. It records the agency’s name, address, and phone number, and the sales executive’s name in the AGENCY REGISTER.

4. It records the agency’s name and the servicing start date in the SALES EXECUTIVE REGISTER.

You’ll notice some duplication in the data storage, since in the current physical world, technological boundaries sometimes make this necessary. In the essential world, each piece of data needs to be remembered only once. To eliminate the duplication, partition the essential data into data entities and relationships. Look at the data elements that are stored or retrieved by the process, and attribute them to the appropriate data entity or relationship.

Accesses 1 and 3 from the above list give you a data entity

Advertising Agency = Agency Name + Agency Address + Agency Phone Number

Accesses 2 and 3 yield an entity

Sales Executive = Sales Executive Name

and a data-bearing relationship

Selling = Servicing Start Date

Why is this a relationship? Access 4 tells you that the agency name is recorded against the selected sales executive in the SALES EXECUTIVE REGISTER because Piccadilly needs to know which executive services which agency. However, the SALES EXECUTIVE entity cannot hold data about an agency. (Remember that all the attributes of an entity describe only that entity.) To remember the link between an executive and the agency, we must establish a relationship between the two.

The SERVICING START DATE is an attribute of the relationship. It doesn’t describe the executive, and it doesn’t describe the agency. However, it does describe the relationship. In fact, if there was no relationship between the entities, there would be no reason to remember this date.

Figure 3.9.2 is the essential data model for the response to the event 9 New agency wants to do business. The C and R annotation is the start of a CRUD check, which will eventually be used to verify all the events and to ensure that no process nor data has been missed. For instance, the R in the SALES EXECUTIVE data entity means that this event references that entity. It does this to get the name of the sales executive chosen to deal with the account. Similarly, the SELLING relationship is referenced to assess each sales executive’s work load. When an executive is selected, the event-response creates a selling relationship between that executive and the newly created agency.

Figure 3.9.2: The essential data model that satisfies the requirement to relate an advertising agency with the sales executive responsible for selling to it. This models the event-response from the point of view of the essential data.

If you have not been using an early version of the data model that you built in the Project (Figure 3.2.8 or Figure 3.4.1), now is a good time to refer to it. There are data entities called ADVERTISING AGENCY and SALES EXECUTIVE and a SELLING relationship between them. You added these to the model because your knowledge of the business led you to suspect that you needed them. It seemed like a reasonable assumption, although at the time you had no details or proof. Now the event-response model confirms your choice. Moreover, it has established some of the attributes for the data entities and the relationship.

The next step is to replace the physical files in the event-response model with the essential entities and relationships.

The model in Figure 3.9.3 shows the relationship SELLING as a data store because it contains data, the SERVICING START DATE. When relationships do not contain data, you should omit them from the event-response process model.

Figure 3.9.3: The essential event-response process model for event 9. Notice that the names used for the entities and relationship in the essential data model are identical to the names of the stores in the essential process model.

That almost completes the first event-response model for the Project. Now update your data dictionary with the preliminary definitions of the new entities and relationship. The next step is to write a mini specification for the process.

We’ve constructed this event-response model in a very detailed, methodical way. Our intention was to give you a complete explanation of the procedure for building these models. Now that you understand it, you can speed up a little. For example, you need not draw two versions of the model with the implementation-dependent processes removed. Nor do you need to draw the current physical response in the first place. Once you feel you understand the actions and data of the event-response, you can skip the first two steps and model only the essentials. If you find this doesn’t work for you, you can always revert to the step-by-step approach. Although there are benefits in having separate event-response data models, you may feel happier modeling the response’s data in the system data model.

Use the remainder of the Project to find a way of working that is most productive for you without sacrificing the ability to accurately capture all the details.

You need to separate the method used from the work being done. For example, recording a new agency is the work. Recording it in a book or in a computer file is the method. Note that because some bubbles carry out both essential policy and implementation processing, you of course need to retain the essential part when eliminating the implementation.

Go back over the event-response model you built in Chapter 1.9 Modeling an Event-Response. For every process and data element, ask whether each has to do with the work or with the method used to do the work. Read carefully through our explanation of why some parts of the model are essential, and why some exist because of the implementation.

It may be useful, now that you have attempted a Piccadilly example, to revisit Chapter 2.10 Essential Viewpoint for its definitions of what is essential and what is not. It may also be worth revisiting Chapter 2.11 Event-Response Models for the material on event-response data models.

If you have already done that, stick with the Project. Although the pace is going to speed up, there are many more opportunities for you to improve your skills with the Piccadilly work and the discussions about each chapter.

Here we go.