Sometimes during code generation you may need
to follow a particular naming policy (uppercase, lowercase, etc.) to map to the
selected implementation target. Although it is possible to make the generator do
the translations, de?¬?ning a DSM solution becomes easier if the naming policy is
supported by the language. This applies not only to checking values entered in
the models but also to naming modeling concepts. For example, in the IP
telephony service example (Chapter 5), the naming of modeling concepts is
taken directly from the domain and expected output. The naming applied in
language types can then be straightforwardly used by the generator to produce
names for XML. Having multiple implementation targets, however, often means
the generator translates model data to the given target language.
. Keep the language simple and minimal: One of the most typical errors is trying
to cope with all possible imaginary scenarios or make the language theoretically
???complete.??? This makes things unnecessarily complex and increases the burden
of de?¬?ning a higher abstraction. It is best to stick with the identi?¬?ed needs and
support them ?¬?rst. You can always extend the languages later if needed. If we
stay with the watch example, the language for logical behavior now supports
basic arithmetic operations for time, but for the sake of covering a larger set of
operations, we could also add, or example, multiplication and division.
Pages:
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447