model level debugging and profiling, code generation conference 2014

Post on 10-May-2015

1.423 Views

Category:

Software

6 Downloads

Preview:

Click to see full reader

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: jpt@metacase.com

top related