model level debugging and profiling, code generation conference 2014
DESCRIPTION
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.TRANSCRIPT
11 April 2014
Juha-Pekka Tolvanen
Supporting Debugging and Profiling on the Model Level
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. + …
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)
2. Animating
Highlight model elements during application execution: demonstration
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
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
Examples with breakpoints
Two breakpoints added ( )
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
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
5. With generated simulators
An application showing execution data
Monitoring motor
State of the app
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
5. With generated simulators
Monitor (domain-) specific parts: here clamp controls
5. With existing simulators [1/2]
Translate your model to existing simulation tools (demo)
5. With existing simulators [2/2]
Translate your model to existing simulation tools (demo)
6. Coverage
Highlight several elements, paths visited, failure propagation etc. (demo)
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
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
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
Questions, please?
For details of the described examples contact: [email protected]