In addition to making the model more compact and succinct, this fits our intuitive understanding of what is happening. As a driver, what I want the car to do is unlock. If it accepted my key without unlocking, I am not happy. So the real requirement on the car is for it to be able to unlock, and this single request shows that.
The questions to ask in creating the requests that populate a sequence diagram, are first, who is requesting what or whom to do what? In the aforementioned example, while the use case states the driver unlocks the car the request is actually from the driver to the car to unlock. It is the car that unlocks itself in response to a request from the driver. In many cases, asking who is requesting what? leads to a good, solid message name that clearly indicates the real action of the system at that point. Such messages are somehow satisfying in that they clearly communicate the meaning and intent of the request, and not just its form. If the messages in your model tend to be of the form, send this, or receive that, or get this, or provide that, then the real purpose of the system interaction is hidden behind these generic,
The way around this, when confronted with, say, a send customer profile, message is to ask, why is the system sending the customer profile to this other entity? Perhaps the answer is that the other entity needs the customer profile so it can validate the customer’s credit limit, in which case validate credit limit would be a much better name for that message. Keep asking why, until you get good, solid answers about what is going on.
It is also important to try to keep messages named in the commonly used language and jargon of the enterprise in which you are working. While modelers who have trained analytical minds might come up with superior terms, it is more important to keep models in a language that can be readily understood by business stakeholders. In a recent engagement, models were printed on large rolls of paper and hung in a high traffic area so that everyone in the company could see them. With only a brief explanation of what the models represent, stakeholders with no UML or modeling training could understand the models, primarily because they were couched in familiar business language.
Identifying operations from the sequence diagram
Once we have developed the
