The Blog for Rhapsody (Power) Users.

Month: September 2019

Paris Code Generation.

Introduction

Lately I do a lot of my travel to France or via France. Of course we are now, as SodiusWillert, located in Bückeburg but also in Nantes (and in Detroit)
But that is not all France… I prefer flying by KLM and that comes automatically with Air France and the occasional stop-over in Paris CdG.
Not my favorite airport as my regular readers know.
But sometimes the flight is just more convenient or just cheaper via CdG.

Not this time, I actually had to be in Paris. Closer to Orly than to CdG so I decided to fly there. The KLM-Air France “El Cheapo” airline “Transavia” flies to Orly and it was really quite cheap. The reason for that became clear when I was sitting in the train to Schiphol: I received a text message that my flight was cancelled. 15 Minutes later an email arrived with my options:

  • fly on another day
  • fly to a different place
  • ask my money back.

neither of these options was what I wanted, so I called the Transavia Hotline. After 15 minutes of waiting (“It will come in time” – Billy Preston and Syreeta on repeat…) the call was answered and the train entered a tunnel… so after 15 more minutes I was again in contact.
“We are currently busy checking all passengers out”, “please call back in half an hour” she said. After some pressure she promised to call me back as soon as she knew more. Apparently she is not much smarter because she still hasn’t called me.

I already expected that and started calling after 15 minutes. The next call center person was not able to do anything for me, she said. I had to do that in Schiphol at the rebook desk in terminal 2.
In the meantime I arrived and went to the desk. I already figured out there were 2 flights with KLM-Air France to Paris. One in 45 minutes (do-able since I had only carry-on luggage) and one on 21:30 in the evening.

To cut a long story short, I had to visit 2 more desks to finally buy a new ticket (€ 600) to Paris because nobody could rebook my flight. Of course I had the late flight, missed the early one due to the slow response and the lack of information. And I was at CdG so the Uber took an hour instead of 10 minutes. Thanks Transavia!

Code Generation

But I arrived in Paris and had to speak the next day about Code Generation. I got the usual questions like:

  • “Why Code generation”
    because it’s the only way. Everywhere you look companies are already very low on staff, programming takes longer and longer, offshore programmers do not really help since we have to increase the effort for specification. Having code generated from a good spec dramatically decreases the time needed to deliver good quality software.
  • If that is so then why doesn’t everybody uses CG?
    We started selling Rhapsody with CG about 20 years ago. At that time there was no other tools that had CG. So sales people from all competitors would claim that CG was something nobody needed. A really annoying statement that is still haunting us (
  • We can just start by drawing pictures and then when we have learned UML we can try CG..
    Sounds like a cool idea. But it isn’t. think 25-30 years back. The time where ‘C’ came up. People were all using assembler and considered ‘C’ as being difficult, ‘C’-compilers were “eating memory” and everybody thought that this ‘C’ thing would go over because it wasn’t useful. Maybe only for documentation (Sounds familiar?)
    Now if you are using ‘C’ to document your code and you’d be programming assembler, what is the chance that you have learned ‘C’ after a few months? I can tell you: zero.
    You learn ‘C’ by developing in it and observe the compiler telling you what you did wrong. And after that the debugging of your programming. Then you learn ‘C’.
    Same thing with UML. You will learn that when you’ve seen and debugged the code. Not by just drawing pictures.
  • But UML is better for documentation isn’t it?
    Depends. As said before, just using UML without checking if you have don it right only increases the work you spend. Don’t forget that UML is a language with a lot of redundancy in it. You have to do a lot of work to create seamless documentation. Then why not generate code from it?

So what does a good UML Code generator needs?

We have tried to create an external code generator before (For EA, maybe you remember) This was not very successful, partly because there was no real integration.
Also many people thought they could take their existing models and then generate code from them, which is, of course, never going to work since you can do a lot in a UML Tool that does not make sense for Code Generation.
You can generate code from the following Diagrams:

  • Class Diagrams
    – Classes -> .cpp/.h (or .c/.h)
    – pointers or embedded classes for relations,
    – code for ports
  • State Diagrams
    – State machine that is connected to a class. All instantiated objects have this state-machine
  • Activity Diagrams
    – code for a Class, you can use a limited version to describe code for functions
  • Sequence Diagrams/Interaction Overview Diagrams
    – Lifelines are classes (Instances but they have to be classes first)
    – messages are events or operations. In theory it would be possible to generate behavior from Interaction Overview Diagrams.
  • Object Diagrams
    – Objects are Objects/instances
    – Links are assignments of object pointers to attributes
  • Package/Profile Diagrams
    – packages can have code, they need to bring the “glue” code for instantiating and connecting objects. Profiles influence the generated code.
  • Composite Structure Diagram
    – instantiates objects and connects them
  • Component Diagram
    – knows the relation of Components and could generate “make” files that links the correct components

No code is generated from:

  • Usecase Diagrams
    – Oh how we would love that, don’t we 😉 No, is not really possible. I would rather write something that generates code directly from requirements….
  • Deployment Diagrams
    – Not really feasible
  • Communication Diagram
    – Possible but who would want that?
  • Timing Diagrams
    – That is also possible but we haven’t worked that one out yet.

So we established that once of the important things for Code Generation is the integration with the UML Tool.
This needs to guide you with the model so that code can be generated from it.
Also we need to directly show the generated code in a window in the tool. Feedback is the most important thing.
Roundtrip and reverse engineering are very important. We need to able to change the code outside of the tool in “our favorite editor”. Also we must be able to use legacy code in an easy way.

  • Generated Code must be understandable by developers
  • it must be efficient in code size and in run-time behavior
    • at least as optimised as hand-written code
    • must satisfy timing requirements.
  • it must fulfil safety aspects if used in safety-critical systems.
    • code must be compliant wit standards like MISRA
  • The generated code must be abstracted from RTOS/CPU and Compiler (The framework will do that)
  • it should not be unnecessarily dependent on other stuff

Up till today, there is still only one tool that does this way better than all others and that is Rhapsody. More than 20 years old and still going strong.

So. That’s it, have fun generating code with Rhapsody!

Walter van der Heiden wvdheiden@willert.de

 

Model Transformation

Introduction

What?!? No travel? Well… yes. too much travel. Hence the low posting frequency. Apart from moving with my family from our old house (that was sold and where we had to leave in 3 weeks) to a temporary vacation home that is not even large enough to house the family of 4 (well, 5 with the dog) let alone has enough place for all our stuff.
So most of it is stored at the moving company and will be brought to our new home when it’s finished (Planning date is December 13. But we all know what planning dates mean, do we….)

Luckily there was (and will be) much traveling in the last weeks and the coming months. I already visited Munich, for our MESCONF, Paris (just for flying to Schiphol), Bückeburg (For work, and we are also moving there), Köln (Cologne) and Zürich.

In the next weeks I’ll be traveling to Bückeburg (Office), Paris, Nantes, Berlin, Possibly Detroit, Ft Myers, Boston, Sindelfingen (ESE), Munich and more.

Transforming your Models

But that is not what I wanted to talk about. There is a more technical topic that needs attention.
Everybody knows (or should know) that we are no longer Willert but SodiusWillert and that we are awesome in connecting engineering data in the widest form possible.
Connecting Jira to IBM via OSLC, connecting the world of ALM to PLM by linking PTC Windchill to IBM with OSLC but also transforming your UML (or even SysML) model to code in C or C++.
One of the questions we receive is that to connect, sync or convert models into other models.

AUTOSAR

One of the models a lot of our customers use is AUTOSAR. That is a standard used in Automotive and contains a standard data format for exchanging information between tools. It is called ARXML (AUTOSAR XML) and is very complex. With ARXML you can exchange very detailed information about the software you make for car ECU’s. You have to use it if you want to create a run-time system for your ECU (RTE – Run-Time Environment) but also to use the Basic Software for your ECU.
But AUTOSAR also defines a model structure that can be used to define your ECU Architecture. Rhapsody can do that, you just load the AUTOSAR profile and you can model AUTOSAR. (Made by SodiusWillert)

Now this modeling structure has some similarities with SysML (Also uses Blocks and Ports etc) but that is, unfortunately, not really the same. AUTOSAR was, at the start, set up to improve cooperation between different automotive companies but somehow this path was left some time ago. IMHO opinion it is needlessly complex and tries to cover all possible ways to do something instead of limiting the users to the bare necessities and introduce an abstraction that would make life easier.
This is where the problems start when you want to use SysML to do architecture modeling, there is no defined path from SysML to AUTOSAR.

Different soup: M2M

That’s how this is called in German: everybody is boiling their own soup. That leads to the fact that there is no single correct solution but a tailor-made solution for every user.
That is where the SodiusWillert M2M comes in. Louis Talvande from SodiusWillert designed this tool to do a model transformation based on rules that the user can define himself.
These rules are part of your Rhapsody model so you can easily select your model elements.

Example of Transformation Rules

When started M2M will transform your current model to another model using the rules you have defined.

More than just transformation

Sometimes (or actually mostly….) just mapping one element to another just isn’t enough. That’s why M2M allows you to not only map single elements to multiple elements but also 1:n or n:1 or n:n.
You can also define conditions in your mapping rules that can decide if a transformation should be made.
And if that is not enough, you can also define scripts (Javascript) comfortably inside your Rhapsody model, to post-process your elements. The complete Rhapsody Java API is to your disposal there.

Merging

Of course, transforming a model is cool. But what if you make changes to the original model? Of course you can always throw away your target model and transform again but what if you also have made changes to the target model?
Rhapsody comes with DiffMerge built-in. Since you are using all standard Rhapsody elements Diffmerge works out-of-the-box.

Features of the M2M Tool

  • Transforms Rhapsody models into Rhapsody models
  • Flexible (user modifiable) transformation rules
  • Transformation can be launched via commandline
  • Portable mapping rules, so you can upgrade from e.g AUTOSAR 4.22 to AUTOSAR 4.31
  • Merging capability with DiffMerge
  • 1:1, 1:n, n:1 and n:n mappings
  • post-processing very easily possible
    • conditional mapping
    • creating new elements using the JAVA API

Just contact me or Louis if you want to learn more about M2M

Well… that’s it for today! Have fun transforming with Rhapsody

Walter van der Heiden ( wvdheiden@willert.de )
Louis Talvande ( ltalvande@sodius.com )

© 2025 Rhapsody Tech Blog

Theme by Anders NorenUp ↑