Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 61
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