Usually we should avoid automation
where a generator carries most of the burden. First and foremost, if modeling
languages are not used to increase the abstraction, the bene?¬?ts of having a generator
tends to be modest. Second, the maintenance of generators that aim to do most of the
work easily becomes the bottleneck. Generators tend to grow larger in the longer run,
and will even during generator construction if the modeling language is not suitable
for the design task. Alarge part of the generator is then for checking the validity of the
designs before starting the actual generation or for clumsy navigation in models using
data structures (i.e., a metamodel) that are not suitable for generation. This kind of
situation is usually detected when developers ?¬?nd themselves learning certain ways to
make models just to make the generator work. Then they are actually modeling to feed
the generator, not to design the application or the feature.
Similarly approaches where modeling languages can only capture partial design
information should be avoided. Usually this becomes evident quickly as it is dif?¬?cult
to use code generators if the input data are not adequate. The classic case here is using
plain class diagrams for code generation: generating a class de?¬?nition into a ?¬?le(s)
from a class diagram is simply transforming the representation from a diagram to text
rather than a helpful code generation step.
Pages:
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144