The details vary according to the need and the modeling language, but one solution
is to add a ???Hack??? object type to the modeling language. The object contains a
free form text ?¬?eld, into which the modeler can enter one or a few lines of code. The
generator for these objects simply outputs their code at the appropriate places of
the output ?¬?le, as determined by the positions and relationships of the Hack objects
in the model.
Having a single source can be good, in particular if the Hack objects are short
enough to be read as part of the model without cluttering up the display. If they become
too large or numerous, they will tend to reduce the ef?¬?ciency of using the DSM
language. Also, code longer than a line or two would bene?¬?t from being entered in an
IDE, rather than a simple text box. It is thus time to look at the ?¬?nal way of integrating
code and models.
Files Referenced by Models The obvious next step from code in models is to
move the code to its own ?¬?les and have the models refer to the ?¬?les. This promotes the
???Hack??? object to an ???External Function??? object, with a simple string representing the
?¬?le name. Each piece of code can be in its own ?¬?le, and that ?¬?le can be edited in an
IDE??”at best along with the current generated code, easing any necessary integration
with that code.
Pages:
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551