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!
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 firstname.lastname@example.org