With DSM, the code that is generated remains ?¬?rmly ???under the hood.???
The developer keeps working on the model level throughout development. There??™s
Domain-Speci?¬?c Modeling: Enabling Full Code Generation, Steven Kelly and Juha-Pekka Tolvanen
Copyright # 2008 John Wiley & Sons, Inc.
311
no working on an unholy interlinear mix of autogenerated and handwritten code.
What DSM does is raise the level of abstraction to a level where things are simple
for the developer. Of course, underneath there is code, and underneath that is
assembler, machine code, microcode, logic gates, electrons, and so on. The trick is
how successfully we can hide the next level down and keep it hidden. DSM does it,
most wizards do not.
If wizards represent something of a dead end in the evolution of reuse, how can we
best use components as part of aDSMsolution? In particular, given we quite probably
already have a library of components for our domain, what extra do we need to
take best advantage of them with DSM? In our experience, the best approach is
to create a separate layer, the domain framework, between the generator and the
components.
Fig. 12.1 compares manual coding, wizards, and DSM. The darker blocks
represent the artifacts that the developer must work with. In the ?¬?rst approach, manual
coding, all code is written and maintained by hand on top of an existing set of
components and platform.
Pages:
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583