The developers of
the DSM solution update and share the related languages, generators, and domain
frameworks to modelers until they remain static. Then the DSM solution is reaching
the end of its life cycle, typically because the applications are no longer actively
developed, just their bugs are corrected. Most likely there is a newdomain or the target
environment for the application has changed beyond the reach of the original DSM
solution.
DSM ORGANIZATION AND PROCESS 91
4.7 SUMMARY
In DSM, there is no single place to raise the level of abstraction to provide automation.
Rather it is the task of experienced developers to divide the work between modeling
languages, code generators, and a domain framework.
For application developers, modeling languages are the most visible part of DSM:
they provide abstractions that are suitable for problem solving in the domain.
Generally, the major domain concepts map to modeling language objects, while other
concepts will be captured as object properties, relationships, submodels, or links to
models in other languages. The speci?¬?cation of the modeling language, a metamodel,
also covers rules. Rules are relevant to guide modeling work, prevent errors early, and
make the models created suitable for code generation.Alanguage also needs to have a
notation. Here DSM tries to mimic representations of the true domain whenever
possible, making models more acceptable and easier to create, read, remember,
understand, and maintain.
Pages:
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198