DSMaims to generate
code directly from the models without having to modify generated models or code.
This is the same recipe that made compilers successful. The difference betweenMDA
and DSM is very visible in agile processes and especially in maintenance, where
changes need to be made to models created earlier. In MDA, the obvious, and still
unresolved, challenge will be in correctly making changes to models that were created
partially by generation. Therefore, the MDA approach leads to the same results as
wizards: lots of code (and models) that you didn??™t write yourself but that you are
expected to maintain. Such wizards can sometimes be helpful, and they do offer
increased productivity at the start, but over time creating a mass of unfamiliar models
and code that needs maintaining tarnishes the picture considerably. The MDA idea
gets even worse when you consider round-tripping??”would you like to update the
manually made changes to the code and lower level models back to all the higher-level
models?
TheMDAway to handle such model updates, forgeting here reverse engineering, is
to use the same language at all the levels and use only a very fewconcepts, like a class.
This naturally lowers the abstraction level we can use in the models. Ironically, each
move toward better synchronization between the levels is thus a move away from
having a higher-level language and a lower-level language.
Pages:
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129