Only after that do you look at what the code might be for an
example usage, and work back from that code to the necessary generator change.
Changes to the generator??”whether refactorings or additions??”can always be checked
by comparing the output code from a known good model to its previous known good
output.
You will probably ?¬?nd it useful to keep a set of example models and output for this
purpose. If possible, do not let your work be based solely on these, but use real models
built by the modelers. One good approach in the long run is to always use your
example models to test changes, but each time use one other real model. Use a
different real model each time: although you will spend extra time because that model
will be unfamiliar, it forms a valuable part of the feedback loop between the language
developer and users.
PROCESS 305
11.5.2 Sharing and Maintaining Generators
Generators are coupled with the modeling language on one side, and the domain
framework, code architecture, and programming language on the other. A good
principle of modularization is to keep coupled elements close together, particularly
where a change in one often implies a corresponding change in the other. At the stage
when you are ?¬?rst writing the generator, the ?¬?rst coupling is stronger: the modeling
language is still likely to change, but for a given generator the programming language
is unlikely to change.
Pages:
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573