Most Model-Driven Development today drops right back down to the code level as soon as developers have to debug, profile or otherwise analyse the running application. Debugging code you have never seen is a major productivity killer – just as it was when early 3GLs lacked support for source-level debugging. In this session we will show how true model-level debugging, profiling and runtime analysis can realise the full value of MDD. We will show how models can be used as first class citizens not only for code generation but also during debugging and profiling: animating application execution, showing data on the current state, highlighting the paths executed, adding performance and trace information into the models. Breakpoints can be set in the model, just as you would in an IDE. All this can be added to any modelling language with minimal effort, integrating with your existing code IDE back-end, as we shall show with practical examples in tools like MetaEdit+, Visual Studio and Eclipse.

1. 11 April 2014
Juha-Pekka Tolvanen
Supporting Debugging and
Profiling on the Model Level

2. Code is now generated, what next?
1. Autobuild
2. Animating models
3. Debugging on the model level
4. Profiling on the model level
5. Simulator/monitor application
6. Coverage shown in models
7. Models updated/changed
8. + …

3. 1. Autobuild
 Directly from model to execution for all developers, hiding
– libraries
– build scripts
– compiler calls
– simulator calls
– tool chains
– paths settings, moving files etc. other repeated parts
 Parameters for autobuild set separately for tools, paths,
platforms
– often part of the language itself
• Android app demo (generate, build, use simulator & run)

4. 2. Animating
 Highlight model elements during application execution:
demonstration

5. 2. Animating: Design flow
 Animate execution in PC or animate execution in real
target device
– Sample*
 Considerations for animation support:
– What makes sense to animate (vary on languages)
– Distribution
• Is execution and animation running in the same machine
– How often to animate
 Generator for production and generator for animation can
be the same
– Animation in the framework rather than in generator
Safa, L,. The Making Of User-Interface Designer, 7th
DSM Workshop at OOPSLA

6. 3. Debugging
 Obviously all IDE features are available but....
… does it make sense to debug the generated code?
– By others than generator developer?
 Debug instead directly in the model
– Provide functionality (demo)
• Add breakpoint to the language
• Provide framework
• Make generator
– Use the created model debug functionality (demo)
• Set breakpoint
• Run generator

7. Examples with breakpoints
 Two breakpoints added ( )

8. 4. Profiling
 Update models with the relevant execution information
 Use the original source model or a copy of it: demo
Djukić, V., et al. Model Execution: An Approach based on extending Domain-Specific Modeling with
Action Reports, ComSIS Vol. 10, No. 4, Special Issue, 2013

9. 4. Profiling
 Considerations for profiling support:
– Decide what kind of data/variable values to be shown
– Show data in the original “source” model or in copy of it?
– Show data in modeling tool or in run-time
environment/external simulator?
• In modeling tool:
– Use as derived values or be persistent (store in models)
• In run-time environment/simulator:
– Run-time environment calls modeling tool to update models
– Modeling on ”hot”: run-time asks from modeling tool if
things has changed and runs generators again

10. 5. With generated simulators
 An application showing execution data
Monitoring motor
State of the app

11. 5. With generated simulators
 A separate application showing variables values: demo
Djukić, V., et al. Domain-Specific Modeling Languages for Medical Device Development, embedded.com, 2014

12. 5. With generated simulators
 Monitor (domain-) specific parts: here clamp controls

13. 5. With existing simulators [1/2]
 Translate your model to existing simulation tools (demo)

14. 5. With existing simulators [2/2]
 Translate your model to existing simulation tools (demo)

15. 6. Coverage
 Highlight several elements, paths visited, failure
propagation etc. (demo)

16. 7. Update models
 Update models with persistent data, show results during
execution/analysis directly in model
– Example on simulating performance (demonstration)
Vatjus-Anttila, J., et al. Domain-specific front-end for virtual system modeling, ECFMA Workshop on
Graphical Modeling Language Development, Denmark, 2012

17. Use generators for others than code
 Example: Hofernet PISCAS use heavily generators
Leitner, A., et al. Effective development of automation systems through domain-specific modeling in a
small enterprise context, Journal Software and Systems Modeling (SoSyM), Volume 13, Issue 1, 2014

18. After generating code:
1. Autobuild
2. Other than code (single source, multiple targets)
3. Simulator/monitor application
4. Animating models
5. Debugging on the model level
6. Profiling on the model level
7. Models updated/changed
8. Coverage shown in models

19. Questions, please?
For details of the described examples contact:
jpt@metacase.com