The ?¬?rst assumption drags the modeling
language down toward the abstraction level of the implementation, forcing the same
division of information as there. While partial classes or preprocessor include
statements may help in some cases, it is much better if the generator facilities do not
impose their ownviewon the relationship between the structures ofmodels, generators,
and output. A single generator should be able to output multiple ?¬?les, a single ?¬?le
should be able to be built from information spread across multiple models, and so on.
Output Filtering After navigation, the second main task of the generator facility
is output of information from models. If the information is already exactly in the
format desired, that will be simple. Often, however, this would require modelers to
know and remember exactly how a given string in a model will be used in the
generated output: if it becomes a variable name, no spaces will be allowed; if it will be
in an XML ?¬?le, ampersands must be replaced with the & entity. Rather than
burden the modeler and force models to be less readable, it is better that the generator
language offers good facilities for translating output.
Generic functions like ???toUpperCase(char *)??? may be useful, but there will always
be newcases and exceptions.Within a givenDSMsolution, certain of these translators
will be used many times, so having a shorter syntax will also be useful.
Pages:
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731