￿The second would be read: The human resources system requests the payroll system to get the payroll record. This now seems odd. It implies that the payroll system must get the payroll record. From where? From some other system? Would not the payroll system be expected to have the payroll record in its database somewhere? This message likely indicates a very common error. The use case step probably reads something like this: The human resources system gets the payroll record from the payroll system.

This correct line in the use case flow was mistranslated into the message just illustrated. The message should have been translated as a request from the human resources system to the payroll system to send (or provide, deliver) the payroll record.

￿Taking the third, fourth, and fifth messages in the illustration, we should find that if we read them in their full English version as shown, they do indeed make sense, and that the indicated operations make sense as operations of the payroll system:

Calculate deductions

Change benefit plan

Pay bonus

￿The final message reads: The payroll system requests the human resources system to complete benefit enrollment. Assuming that completing benefit enrollment is something the human resources system has to be capable of doing, this message is shown correctly.

Toward better requests

When first creating MDSD models, practitioners tend toward using transactional-sounding names such as send, receive, accept, provide, and the like. Using the earlier example of a car, when the driver goes to unlock the car, we might be tempted to write a request from the driver to the car to accept the key, followed by an internal function of the car to unlock the door, as shown in Figure 3-7.

60Model Driven Systems Development with Rational Products

Page 76
Image 76
IBM SG24-7368-00 manual Toward better requests