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:
 | Needs
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.
|
| All
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.
