12.3 PROVIDING AN INTERFACE FOR THE GENERATOR
The generator takes input in a format speci?¬?ed by the modeling language, and
produces output that must run under the domain framework. Since both modeling
FIGURE 12.3 Watch in Nokia, Motorola, and Sun MIDP emulators, and browser applet
PROVIDING AN INTERFACE FOR THE GENERATOR 317
language and framework are created speci?¬?cally for the same problem domain, there
is often a good correspondence between them. The better the correspondence is,
the easier it is for the generator to map from its input to its output. In Fig. 12.4, there is
a good correspondence between the Display modeling concept in the metamodel
and the AbstractDisplay class in the framework. The three lists from the model can
thus map one-to-one with the lists in the generated code: the only change is that
the modeling language calls the middle list ???UnitZones,??? whereas the Java class
calls it ???times.???
An exact one-to-one correspondence may not however be desirable in all cases:
It leads to a domain framework that has to be completely driven by data structures
that mimic the model. While completely data-driven code will work, it requires a
large amount of work in the domain framework, can be harder to follow, and is almost
always slower than more traditional code. Parts of the generated code may well
be data-driven, for instance, the basic structures of a state machine.
Pages:
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595