Here, modelers can be informed in different ways about the
results. The most natural option is showing the warning close to the model element or
highlighting the elements the rule is related to. For example, an element having an
error or not yet completely speci?¬?ed could be selected or reported. Each modeling
action can also inform about the possible illegal action or even inform the modeler
about other options of language use. The last option is to have a separate checking
report showing the results in some textual form, like an error dialog. Tools may also
help in the visualization, such as by allowing checking results to be traced back to the
model or model element having an error.
10.4.3 Rule De?¬?nition Process
In general, the rules of a language should work like ?¬?le security: nothing is permitted
unless it is speci?¬?ed. The advantage of this approach is obvious: language de?¬?nition
becomes easier to handle, as new rules can be set and tested incrementally. This is the
exact opposite of using pro?¬?les in UML: things are already allowed and then we start
adding extra rules to override those already de?¬?ned in the standard metamodel. This
not only complicates the de?¬?nition but also makes the rules cumbersome and
numerous. Try it yourself: implement the languages described in Part III using plain
252 DSM LANGUAGE DEFINITION
UML as a starting point and adding rules with pro?¬?les.
Pages:
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459