Filter
Top Products
58 Model Driven Systems Development with Rational Products
Specifying request signatures
We can make such a request more complete by including the notation of the
entities carried along with it. A request from the homeowner to the mortgage
company to apply the payment must be accompanied by the actual payment.
Thus we would write the request fully as:
apply mortgage payment (mortgage payment)
A full signature also specifies the entities that travel back to the requester as a
result of the request. If the mortgage company is expected to send back a
statement as a result of the payment, the full signature would then read:
apply mortgage payment (mortgage payment, statement)
In practice, we sometimes omit these full signatures (request along with entities
items passed back and forth) in the early stages of building the model. If
including the signature adds clarity and does not slow down the modeling
process, then by all means it can be included as the models are developed. If
additional research or thinking is required to fully specify the signatures, then a
decision can be made to either spend that time on the first pass, return later, or
perhaps delegate this work to a sub-team.
Entities included in signatures should match the level of decomposition at which
the modeler is working. When working with an enterprise use case for instance,
we might use customer information to refer to a set of information that at a lower
level would be further described as a set of specific fields. These entities
exchanged between system elements and actors also appear in the model as the
I/O entities discussed earlier in the section on context diagrams. They also
become the foundation for the more complete domain model described in a later
section.
Information in the MDSD model
An MDSD model is an abstraction of the system being developed, in fact,
multiple abstractions at different levels. Thus we seek to represent information in
the model also in an abstract way. The information entities that appear in the
signatures of messages are one way to do this. In these messages, we show
information at a high level, for example, we might show something like
customer
information
, instead of listing out name, address, phone, account number,
purchasing history, and so forth. This allows us to show the information used at a
high level, recognizable by all stakeholders. Most stakeholders are not able to
makes sense of a detailed information design, such as a database schema or
data dictionary, and these would be far too much information for the purposes of
the higher levels in the model.