4.7. Solutions: Event-Response Models
Exercise 1: Dentist Performs Service
The essential activity for the system is to record the services that have been performed. The service takes place outside the system; both the patients and the dentists are terminators in the context diagram. Note that this event-response establishes the VISIT and relates it to the SERVICE.
Note that the VISIT entity is different from the APPOINTMENT entity. A visit is a record of a patient being treated by a dentist, whereas an appointment is a reservation of the dentist’s time. Not all appointments are kept, and appointments can be canceled, but visits can’t. Patients can also make walk-in emergency visits without appointments. This event may establish the relationship between visit and appointment, or the receptionist may establish it when the patient arrives at the office. In that case, there may be another event, Patient arrives at office. We must go back to the users to ask them.
Exercise 2: Time to Produce Appointment Schedule
The data dictionary entry looks like this:
Appointment Schedule = Appointment Date + Dentist Name
+ {Appointment Time + Patient Name
+ {Service Identification}}
The receptionist makes up a schedule for each dentist. This is why there is only one dentist’s name on the schedule. The {SERVICE IDENTIFICATION} is on the schedule so that the dentist has some warning of any major operations.
The event-response model for event 1 is shown in Figure 4.7.6. This response happens when a customer brings in a radio to be repaired. First, Sid inspects the radio to assess the problem. Depending on what he finds, he either gives the customer a quote for the job, or agrees with the customer that the repairs are to be done on a time-and-materials basis. In the latter case, he gives the customer a TIME AND MATERIALS NOTE to outline his charges.
Figure 4.7.6: Event-response process and data models for event 1 Customer needs radio to be repaired.
The response to event 2 Customer authorizes repair can have several outcomes. If Sid has both the specification and the parts, he can repair the radio and send the pick-up notice to the customer. On the other hand, if he needs a specification, the processing for the Customer authorizes repair event-response stops, and the system waits for the event Manufacturer sends specification. Similarly, if he needs parts, the event-response stops, and the system waits for Supplier delivers parts. PICK-UP NOTICE is also an output of the response to these other events.
Figure 4.7.7: Event-response process model, showing one essential activity for event 2 Customer authorizes repair.
Figure 4.7.8: Lower-level model for event 2 Customer authorizes repair. The one bubble in the previous model is too complex for one mini specification, so the bubble is partitioned to produce this model with three primitive processes.
Note that in the response to event 2 (Figure 4.7.9), there are two relationships between JOB and CUSTOMER. The QUOTING relationship is established when Sid gives the customer a note explaining the charges involved in fixing the radio. The AUTHORIZING relationship is established when the customer decides to have the radio repaired.
Figure 4.7.11: Leveled process model for event 3 Manufacturer sends specification. Notice that the processes DO RADIO REPAIR and CHECK FOR NEEDED PARTS are identical with those in the model for event 2. Although you draw the processes in both models, you’ll write the mini specifications only once.
Figure 4.7.12: Event-response data model for event 3 Manufacturer sends specification. This data model is almost identical with that for event 2.
Figure 4.7.13: Event-response process model for event 4 Supplier delivers parts. The data model for this event is very similar to that for event 3, and that’s why we don’t show it.
Figure 4.7.15: Event-response process and data models for event 6 Time to pay supplier. There is some doubt about the cardinality, hence the question mark. Does Sid make a single payment for each invoice? Perhaps if business is slow, Sid may make several partial payments.
The response to event 7 is shown in Figure 4.7.16. The triggering data flow CUSTOMER JOB PICKUP, carries the customer’s identity, the job identifier, and the cash payment for the job. Note the 1:1 cardinality of the CUSTOMER PAYMENT to the JOB. This is because Sid demands that his customers pay in full before they remove their radios from his shop. The 1:N CUSTOMER to CUSTOMER PAYMENT is because some customers may have several radios repaired over a period of time.
Note that there is no event Repair is completed. If you disregard the implementation of the system (Sid, who is only human, takes lunch breaks and works at normal human speed), any repair would be carried out instantaneously. In other words, the radio is repaired in response to the authorization, the delivery of the parts, or the arrival of the specification.
Custodial Activities
As Sid sends data flows to suppliers and manufacturers, he has to keep information about them, so there are additional events whose responses will be mainly custodial activities:
8. Create new manufacturer
9. Update manufacturer details
10. Delete manufacturer
11. Create new supplier
12. Change supplier details
13. Delete supplier
There are no data flows in the context diagram that suggest how Sid gets this information, so you will have to question him further to find the missing boundary data flows.
Figure 4.7.17: This system data model for Sid Edison’s Radio Repairs is an amalgamation of all the event-response data models.
Sid doesn’t indicate what information he keeps about his customers. He may keep none at all once the radio is collected. If he does store information about customers, then you will need
14. Update customer
15. Delete customer
We suggest that you ask Sid if you need
16. Update supplier invoice details
17. Delete supplier invoice (although we think that this last one is questionable)
The system stores specifications. This probably means you need
18. Update specification (He may not do this, as the manufacturer may send a new specification to replace an old one.)
19. Delete specification (The manufacturer would have to send notice of a deletion.)
Note that there are more events concerned with custodial activities than events for fundamental processing. This is a normal pattern for most systems. Note, too, that the custodial events indicate there are missing data flows that will have to be added to the context diagram. This is also normal for most systems.
All trails: Return to