g., Fitzgerald, 1991; Schipper and Joosten, 1996. While testing the language, we
have found three issues to be relevant (Tolvanen, 1998).
1. Abstraction: expressive power when describing the problem domain
2. Model consistency: organizing and keeping models consistent, guiding on
reuse
3. Support for generators: producing required output from models, typically the
code
(1) Abstraction deals with comparing how well the given test case or application
domain in general can be captured with the de?¬?ned language. Modelers easily
get back to you if the expressiveness is not adequate, but you may also check
issues like
. Could the abstraction be higher? If the same kinds of patterns or
combinations of model elements occur often, they should be replaced with a
new modeling concept. Then, there is less to model and reuse of good
practices is easier as the language provides concepts for them.
. Does the language minimize the modeling effort? If there are repeating
elements used just to make the model complete, these could be left to the
262 DSM LANGUAGE DEFINITION
generator. For example, in the mobile phone case (Chapter 8) almost half of
the navigation ?¬‚ows can be removed in typical applications by moving
standard cancel navigation to the generator.
. Have modelers made their own extensions? Models including special
naming policies, such as pre?¬?x, post?¬?x, capital letters, and special
characters, can indicate that modeling power is not adequate.
Pages:
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482