In the same way, notation can indicate missing properties, showing the model is
incomplete. It is generally better to place these special notational elements
close to the model element that has the error or missing information to give a
context. Textual model-wide checking reports are, however, better for more
complex cases since they allow giving an explanation for the error or even
instructions to correct the speci?¬?cation in a model. A hybrid solution??”
requiring more work??”is to have both: a special notational element indicating
the error in model and a model checking report that explains in more detail the
status of the model.
. You may also inspect your corporate documentation standards: applying their
look-and-feel in the modeling language improves acceptance and makes the
generated documents more readable. Examples of such guidelines are
classi?¬?cation schemes for the status of the model, such as draft, and frozen.
. Finally, do not be afraid to ask for help in making the notation: good
metamodelers are not necessarily good graphic designers.
10.7 TESTING THE LANGUAGES
It is always a good idea to have multiple concrete example cases to test the language
early on. Actually, the whole language creation could be considered as incremental
and test case driven: ?¬?rst, you de?¬?ne some of the language, then model a little, make
some extensions to the language, model some more, and so on.
Pages:
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479