The
interface will consist of data structures to be ?¬?lled in, places to add code generated
from models, and components to be extended by generated code. The aim is to support
the largest possible extent of the desired application space, for the smallest amount of
work for the modeller??”and to a lesser extent, the metamodeler.
Domain frameworks tend to differ somewhat from traditional frameworks, for
instance, in greater use of inversion of control and metaprogramming. There is also
often a tendency toward small singleton classes in the generated code using the
domain framework. Depending on the domain, there may also be other considerations
such as the framework size, generated code size, or total executable size or speed.
These will in?¬‚uence the strategies and programming style used in the framework, but
in a way already familiar to any experienced developer in that domain.
Building the domain framework can happen at any time in the overall DSM
process: as the ?¬?rst step, after the modeling language, with the generator, or after the
generator.We have seen and worked on successful cases in all of these different ways.
Until you have the experience of a couple of successful DSM solutions under your
belt, however, we would recommend that you leave the framework until after the ?¬?rst
version of the generator.
Pages:
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616