Having rules in the language provides many of the
bene?¬?ts of the DSM approach: they make a language domain-speci?¬?c. Typical
bene?¬?ts are as follows:
. Prevent errors early: illegal or unwanted models simply can??™t be made.
. Guide toward preferable design patterns.
. Check completeness by informing about missing parts. While not necessarily
relevant for the modeler, the code generator expects a ???complete??? speci?¬?cation.
It is worth noting that by ???complete??? we mean that models can be used as input
for full code generation.
. Minimize modeling work by conventions and default values.
. Keep speci?¬?cations consistent: if one element is changed in a model, the change
is re?¬‚ected elsewhere to either update models or report about the inconsistency.
In our experience, the rules are best de?¬?ned after having decided on the main
modeling concepts: then you start to see the patterns and rule types. It is not rare to
notice that a certain rule, such as occurrence, naming, or cardinality in a relationship, is
FIGURE 10.8 Sample model that is an instance of the metamodel speci?¬?ed in Fig. 10.7
250 DSM LANGUAGE DEFINITION
shared among many modeling concepts. We can divide the rules into those that
originate fromthe domain and those that deal with howthemodeling language operates.
10.4.1 Domain Rules
Most of the concepts in a modeling language come with rules.
Pages:
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455