Syncing Model with Code

Round-Trip Engineering is one of the most requested features for our code generation solution. While people agree that it’s hard to get right and consequently are disappointed by many implementations thereof, it’s nonetheless a feature which can improve – when done correctly – your workflow.

Unfortunately, round-trip engineering is quite hard a challenge even for structural code generation, but for behavioral code generation usually all bets are off. Existing products often resort to kludges and hacks to implement this feature, sometimes making it downright dangerous. While sometimes useful, it’s not a feature you’d like to use from day to day.

We at LieberLieber believe that we can improve the modeling workflow now, without the need for full round-trip and its drawbacks.

That’s why we’ve created Code Sync for Embedded Engineer.

The premises are simple:

• The model is the one-and-only source for generated code – no exceptions
• Structural changes are done in the model

This ensures that your model is always up-to-date, and there’s no way around that. This in turn improves the utility of your model as documentation – because what good is a documentation if it only remotely documents the thing you’re shipping?

Now these premises would restrict you to model-only engineering, basically. But that can be tedious when you start to do behavioral modeling, where you also include source code in the model.

That’s where Code Sync comes into play.

Before generating code, Code Sync looks for existing code blocks – that is, code which can safely be changed by the user – and detects the following changes:

• The model changed, but the code didn’t. It’s safe to overwrite the code.
• The code changed, but the model didn’t. It’s safe to sync the model with the code.
• Both sources changed. Apparently there have been changes in the model as well as the code, so Code Sync let’s you decide how to merge the code.

This way you can efficiently modify the generated code, and as soon as you sync/regenerate it, your changes are incorporated in the model.

You also get a report documenting the changes (pictured above), be it changes in the model, the code, or conflicting changes which may require your attention.

Coming in Embedded Engineer 2.0