This is possible because the generator (and
modeling language) is made to satisfy the demands of a narrow application domain??”
used inside one company. We must emphasize that this does not mean that all code
used is generated. That??™s why we have a domain framework and a target environment.
They may be generated from different models or, as is most likely today, programmed
manually. The generator itself, like the domain framework and target environment,
can be largely invisible to the developers in the same way as black-box components or
compilers are not visible.
Code generators can be classi?¬?ed differently and perhaps the most used is dividing
them into declarative and operational, or a mixture. This classi?¬?cation is based on the
approach used to specify generators. In the declarative approach, mapping between
elements of the source (metamodel) and target programming language is described.
Operational approaches, such as graph transformation rules, de?¬?ne the steps required
to produce the target code from a given source model.
Although it is possible to view and edit the generated code in DSM applications,
developers usually do not need to inspect the results of the generator. Editing
generated code is (or should be) analogous to manually editing machine code after C
compilation, which typically is unnecessary.
Pages:
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173