g., CDIF, XML), and repository
de?¬?nitions.
Metamodels have been used in standardization efforts, but often only in a limited
way: they are not made suf?¬?ciently precise and formal and there is no reference
implementation in terms of metamodel instantiation. For example, past versions of
76 ARCHITECTURE OF DSM
UML and its derivatives like SysML have been de?¬?ned using metamodel fragments,
related documentation, and example models. As they are not consistent, the language
de?¬?nitions are left with multiple interpretations. Metamodels in DSM are different as
they are formal and have tool support to enable model-based code generation. They
also have a reference implementation, although it might be the only implementation
of the language.
4.3 MODELS
In DSM, models are the primary source in which developers create, edit, and delete
speci?¬?cations of a system. Although changes to the language, generator, and
domain framework are possible, most developers typically focus on modeling.
Domain-speci?¬?c models are then used to directly generate the code. In DSM,
we should avoid situations in which models are translated to other models for
future editing. This approach did not work in the past with code and it won??™t work
with models either. Use internal to a tool as an intermediate product is a different
story.
Pages:
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166