Filter
Top Products
60 Model Driven Systems Development with Rational Products
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.