Figure 3-7 Unlocking car: Cumbersome sequence

While this might be technically correct, it is less than optimal in the model for two main reasons. First, the car does not exist for the purpose of accepting a key. Even if unlocking the car were required to be by key versus some other means, saying that the required function for the car is to accept a key is not true, and misleading. Second, it requires an internal function, shown as a reflexive arrow on the sequence diagram, to be clear about what is going on.

This pattern, or we should say, anti-pattern, of a transaction-oriented message immediately followed by an internal function is quite commonly used by new practitioners. The solution is to combine the two by asking, what is the real function that is required of the car? To get at this, we can simply ask, why is the driver inserting the key (or sending the data) into the car. The answer is of course that the driver is really not just requesting the car to accept the key, but requesting the car to unlock. Thus we can better model it as a single message, unlock. Optionally, we can add key as a parameter on the unlock request, since the key is passed between the driver and the car as part of the request (Figure 3-8).

Figure 3-8 Unlocking car: Better sequence

Chapter 3. Black-box thinking: Defining the system context

61

Page 77
Image 77
IBM SG24-7368-00 manual Unlocking car Cumbersome sequence