Unfortunately, such
solutions almost invariably turn into languages that describe code rather than things in
the problem domain. The result looks like a bad rehash of UML, without even the
chance to claim it is a standard. The level of abstraction is not raised, and there is no
real way to generate full code from such models.
As we build our modeling language to take us to a higher level of abstraction, there
can thus be no premature slipping back down the slope into code. When we have the
language ?¬?rmly established on a higher level of abstraction, it is refreshingly easy to
build a path back down to the code level. The information from the models seems to
?¬‚ow down naturally, as if by some gravity of abstraction, into the form needed for the
compiler. This ease should come as no surprise: it has always been easier to build a
compiler than a reverse compiler.
Developers are often afraid that they will produce a modeling language that would
have no sensible, easily performed mapping to code. While in theory this might be
possible, in practice any expert who has coded applications in the domain would be
most unlikely to do this. They will ?¬?nd themselves making decisions in the modeling
language that, in spite of their best efforts, are at least informed by their experience of
patterns of code in that domain.
Pages:
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492