2.6 Visual Debugging
One of the most common questions regarding the DSM approach is
how to track down bugs in the generated code. Conventional debugging strategies
may be handy when we are building the framework and code generator for DSM, but
for the developer who is working with the DSM environment, the game of debugging
is indeed a fair bit different than with traditional IDEs. Let us first consider
these differences:
 | No
manual changes to generated code. The benefits of domain-specific modeling
are mostly due to the 100% code generation, which allows us to work on a higher
level than code. Bug corrections are thus not made to the final code, but to the
models instead.
|
| Errors
originate from designs, not from code. As code is generated automatically
and always with the same rules, there are no typical code level errors like
typos or syntactical mistakes. This means that for normal developers, errors
originate from the design level (the metamodeler will correct errors in the code
generators). |
Both these factors lead to the
conclusion that with DSM, not only design but also the debugging of designs
should happen on the model level. This is a significant improvement over
traditional non-DSM use of models, where the developer had to separately update
the design models after making the code corrections: now it is possible to make
the corrections in a single place.
When debugging on the model level, the important question
is how to find the faulty part of the model. Our original test environment for
watch applications provided a very limited solution for this problem by
providing information about the current application state at run-time. While
this was useful, we would like to have a more integrated solution. To that end,
we have implemented a visual debugging aid that lets to follow the execution of
our watches, by animating their state models in sync with the actual watch
running in the test environment.
