In this approach, all possible behavior of applications in the domain is
covered in the engine. Any given application speci?¬?es its subset of this behavior space
as data, which is read and acted on dynamically by the engine. In a way, the engine is an
interpreter for the data supplied by themodels, as opposed to the earlier cases where the
generator acted more like a compiler to turn the models into code.
Theoretically, the engine could read the models directly from the memory
structures in the running modeling tool. Since this requires the modeling tool itself to
be present at runtime of the applications, it is hardly ever used for deployment. It may
however be useful in some cases for simulation: the engine runs the models directly,
and interacts with the modeling tool to visually trace the execution in the models. This
kind of visual trace is however also possible with more traditional generation.
The engine could also read the models directly from the ?¬?les they are stored
in on disk. In practice, the model ?¬?les will normally contain a substantial amount of
information that is redundant for the execution, for example, the layout coordinates of
each model element and various documentation ?¬?elds.
326 DOMAIN FRAMEWORK
More normally, the models are exported by generators into code that instantiates
framework data structures to recreate the relevant model structures, or into a simple
?¬?le format that is easily read by the engine.
Pages:
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612