Figure 3-4 Incorrect sequence diagram

This would mean that the driver is requesting the car to approach. What is the right way to represent this? We get the answer from the second part of that step in the use case. When the driver approaches the car, he or she is actually

requesting the car to unlock. We thus draw a message arrow from the driver to the car and label it unlock. Note that this allows great flexibility in

implementation—the unlocking can be accomplished by an automatic proximity key, a biometric sensor, a conventional key, or any other means. This is one of

the important features of MDSD. Because we treat the car as a black box in describing this use case, we abstract away all of the details of how the car

performs the required behavior.

One might note here that after the analysis of this use case fragment, the driver approaching the car turns out not to be significant in the design of the system. Unless we are planning on designing a car that somehow detects the driver approaching, the use case should really begin with the driver unlocking the car (Figure 3-5).

Figure 3-5 Correct sequence diagram

56Model Driven Systems Development with Rational Products

Page 72
Image 72
IBM SG24-7368-00 manual Incorrect sequence diagram