If generators of code, simulation, testing, and so on, are already available
for the language, developers have extra motivation as models ?¬?nally serve some other
purpose than just documenting designs.
A large portion of the tests can be done by the language creators. This is natural,
especially in the beginning, as the language is not necessarily complete, many
changes may still be made, and multiple iterations can occur within a day. Later, when
the modeling language is more complete, other developers should be involved. Their
feedback is important not only for testing but also to smooth acceptance of the DSM
solution.
At this stage, feedback is typically received about notation. Do the symbols look
nice? As anybody can have an opinion on the notation, it is more relevant for DSM
to focus on the language??™s capabilities??”conceptual structure instead of
representation. It is often effective to ask language users to correct representational
issues, such as how symbols should look, and in this way try to move testing to
more substantial issues. Another good practice is to gather experiences while
modeling by including in the language a special comment element: modelers may
thus highlight issues they found relevant, but that could not be described with the
language, and so on.
There are not many publications on testing and validating modeling languages
(e.
Pages:
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481