For example, if you need to delete an existing concept and replace it
with two new ones, you can consider just refactoring the old one so that the model
changing work can be minimized. Naturally the old one is modi?¬?ed, if possible, to
resemble the more common concept in models. A DSM tool then makes the update at
least partly automated.
MAINTAINING THE LANGUAGES 265
10.9 SUMMARY
The goal of de?¬?ning a domain-speci?¬?c language is to provide the software modelers
and developers with a higher level language with which they can build systems. The
best advice is to forget the implementation and code structures, at least in the
beginning, and think about the problem domain. This raises the abstraction most and
leads to fundamental productivity improvements. If you focus on the code from the
start, the possibilities for automation may be easier to de?¬?ne but the gains are small,
10??“30% improvements on current manual practices.
While it makes sense to develop the whole DSM solution at the same time,
language de?¬?nition can be started even when other elements of the DSM solution, or
even the target environment for the resulting software, are not yet known. Modelers
can then start development work, while others implement the supporting target
environment, its libraries, and components along with code generators.
Pages:
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489