Filter
Top Products
62 Model Driven Systems Development with Rational Products
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, transaction-oriented terms.
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 black-box sequence diagrams for each of the use
cases, we are ready to identify the operations—our reason for doing all the
sequence diagrams. Looking at a black-box sequence diagram, focus on an
element and you see that some of the arrows are pointing in toward the element’s
lifeline (the vertical line dropping from the element at the top of the diagram) and
some arrows point away from this lifeline.