DSM does not expect that all code can be generated from models, but anything
that is modeled from the modelers??™ perspective, generates complete ?¬?nished code.
This completeness of the transformation has been the cornerstone of automation and
raising abstraction in the past. In DSM, the generated code is functional, readable,
and ef?¬?cient??”ideally looking like code handwritten by the experienced developer
who de?¬?ned the generator. Here DSM differs from earlier CASE and UML tools:
the generator is written by a company??™s own expert developer who has written
several applications in that domain. The code is thus just like the best in-house code
at that particular company rather than the one-size-?¬?ts-all code produced by a
generator supplied by a modeling tool vendor.
The generated code is usually supported by purpose-built framework code as
well as by existing platforms, libraries, components, and other legacy code. Their
use is dependent on the generation needs, and later in this book (Part III), we
illustrate DSM cases that apply and integrate to existing code differently. Some
cases don??™t use any additional support other than having a generator.
At this point, we need to emphasize that code generation is not restricted to
any particular programming language or paradigm: the generation target can be,
for instance, an object-oriented as well as a structural or functional programming
language.
Pages:
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52