Tag: France

🎸 Retired but Not Gone — and Rhapsody Plays On

April 13, 2026 / rhapsody207 / 0 Comments

So. It finally happened. And for a career spent living out of airports, I marked the occasion by doing the most gloriously retired thing I could think of: I took the train to Paris. No security lines, no gate changes — just the countryside sliding by, a coffee that didn’t cost eight euros, and absolutely nowhere I needed to be in a hurry. Retirement, lesson one: take it easy.

As of Wednesday, April 8th, I am officially retired — after 25 years with Willert and later SodiusWillert (to April 11th, if we’re being precise about it, and after this many years I’ve earned the right to be precise). A quarter of a century. That is… a lot of models.

There’s a lovely bit of symmetry to the timing, too. April 8th also happens to be Jannie’s birthday — my wife, who came along for the trip (that’s her in the photos below). So this year I gave her a slightly unconventional present: a full-time husband. She is being remarkably gracious about it.

And fittingly, I didn’t sign the papers at some grey desk back home. I signed them in Paris — a city that does endings and beginnings better than anywhere, with good coffee, better views, and not a single license-server error in sight. If you’re going to draw a line under a career, do it somewhere with a proper terrace. Highly recommended.

And before anyone starts writing the eulogies: I’m retired, not gone. There’s a difference, and it’s an important one.

Here’s what retired means for me: no more 6 AM alarms to catch a flight to a customer site. No more license-server tickets at 23:00 on a Friday (Classic Rhapsody veterans know exactly what I’m talking about). No more juggling five time zones in a single week. I’ve done enough of that — honestly, I’ve done plenty. It’s time for the quieter life: more time with Jannie, more time for the things I kept saying I’d get to “after this next project.”

Here’s what not gone means: I’m still here. Still writing this blog — probably more of it, now that I actually have the time. Still an IBM Champion, still knee-deep in Model-Based Systems Engineering, because you don’t spend 25 years loving this stuff and then just switch it off like a license server (which, again — IYKYK). You’ll still find me at DCUG Day, at TechXChange, at MESCONF, at ESE, at the conferences, in the community. Just… without the alarm clock.

Think of it as going from full-time to full-enthusiasm.

Meanwhile, the world keeps turning — Rhapsody 10.0.3

And of course, the field doesn’t pause just because I clocked out. Right on cue, IBM Engineering Rhapsody 10.0.3 landed — and it’s a genuinely good release, aimed squarely at large models and distributed teams. A few things caught my eye:

One-Click Environment Setup. Cygwin and the Rhapsody transforms installed in a single click, turning what used to be an afternoon of yak-shaving into a couple of minutes. Every new engineer who never has to fight that setup owes 10.0.3 a quiet thank-you.
A load progress indicator that actually moves. Small thing, huge relief. No more staring at a frozen-looking Rhapsody wondering if it died or is just thinking. It’s thinking. Now it tells you.
Zoom (100–500%) and type-to-filter in tables and matrices. If you live in the big traceability matrices like I do, this is the quality-of-life upgrade you didn’t know you were allowed to ask for.
Auto-generated flowcharts from legacy code. Point it at the old code, get operational flowcharts out. Anyone who’s ever inherited a mystery codebase will appreciate this one.

And then there’s the one that made me laugh out loud: 10.0.3 ships an MCP server — read access to your Rhapsody models via the Model Context Protocol, near-instant analytics, “Bring Your Own AI.” Now… where have I heard that idea before? 😏 Those of you who’ve followed my little rhapsodymcp.com adventures know this has been my personal playground for a while now. So let me just say: it’s wonderful to see MCP go official in the product. Great minds, and all that. I’ll be poking at IBM’s version very soon — retired hobby project, meet enterprise feature.

One more chapter

The best part of retirement, I’m discovering, is that curiosity doesn’t retire. I get to play with Rhapsody 10.0.3 purely because I want to, not because a project needs it by Thursday. That’s a good place to be.

So: thank you — to everyone at Willert and SodiusWillert, and to everyone I’ve worked with, learned from, argued about UML with, and shared a stage (or a beer) with over these 25 years. This isn’t goodbye. It’s just the start of a slightly slower, considerably more enjoyable, verse.

See you in the comments. And at the next conference.

P.S. — Yes, I’ll still answer your Rhapsody questions. No, not before coffee. Some things retirement will never change. And Jannie — happy birthday. Sorry the gift was me.

What’s your favourite 10.0.3 feature so far — and if you’ve stepped back from the daily grind but not the passion, how’s that working out for you? Let me know in the comments below.

Happy Modeling ( preferably with Rhapsody)!!

Walter van der Heiden
walter@vdh-informatica.com

Using MatLab Simulink with Rhapsody

April 3, 2024 / rhapsody207 / 0 Comments

Back in Nantes

Since we are together with Sodius I have my regular visits to Nantes. Luckily! I really like Nantes and of course my colleagues in Nantes. Always big fun and great to see beautiful Nantes.

Simulink

People still use Simulink; I’m always surprised that nobody objects to the fact that it generates code; people use it without thinking. When it’s Rhapsody, millions of objections pop up against Code Generation. Probably, it is because Simulink is used by all kinds of engineers and Rhapsody by Software Engineers who feel attacked in their honor by Rhapsody (That does an excellent job generating code,..)

Now, with the Automotive Extension, there is another way to integrate the two tools: ARXML. That’s a “lightweight” integration; it doesn’t add much. The real benefit comes from co-simulation, and that’s what Andy does in his video. AFAIK that still works (I do not own a Simulink license, I cannot try it)

Resources

Now, I could be explaining here how it works but other people have done that already, way better than I can.

Andy’s (old) video. Explains it really good.

Justin Dyer IBM explaining. A tiny bit newer than Andy’s video.

Frank Braun’s video. Great explanation!

IBM TechXChange Lab (Also by Andy, you need an IBM ID for that)

TechXChange

Coincidently I answered a question on TechXChange, about this, it seems the Library for CygWin is broken:

OK. Not so easy but it works:

Add to your configuration in the “Settings” Tab under: “Link Switches”:
"<<UserShare>>/LangCpp/lib/cygwinsimulinkintegrationapplx64.a"

(Replace the <<UserShare>> with the path to your UserShare directory.)

Then you need to build the Simulink library, the following files need to be placed:

– In the directory <<Share>>\LangCpp\SimulinkIntegration the file cygwinsimulinkintegration.mak

– In the directory <<Share>>\LangCpp\ the file cygwinbuild.mak

Then call “Code” and “Build the Framework” from the menu. there is 1 warning, you can ignore that.

You can also edit sitec++.prp and add the Cygwin makefilecontent with the changed linker statement. But this works too.

So. That’s it for today! Happy simulinking with Rhapsody!

Walter van der Heiden walter@sodiuswillert.com

Absolutely Relative in Bordeaux

November 28, 2019 / rhapsody207 / 4 Comments

Bordeaux

This time not Nantes… but Bordeaux. OK, first Nantes, there was some work to be done, but after that there was room for some personal time-off.
A friends 50th birthday was there and had to be celebrated big time.

His wife rented an old castle (France has about a million of these) where the celebration would take place. We celebrated heavily… drank a lot of wine.
We also visited a Safran Farm, of course, a vineyard and an old village with a magnificent church (No photo’s allowed, sorry.)

Absolute and relative paths.

Unfortunately the default in Rhapsody is to use absolute paths. And it will use absolute when in doubt.

There are 3 properties that control the switch from Absolute to Relative:

1. General::Model::PathInProjectList, this is the path that models have in a project list (“Workspace”

2. General::Model::ReferenceUnitPath, this is the path where units are stored. When this is relative paths are stored relative to the model directory.

3. C_ReverseEngineering::Main::useCodeCentricAbsolutePath, is a new property to indicate if reverse engineered sources are stored absolute or relative

Use Rhapsody Workspace

A bit hidden is the posibility to use multiple projects inside one open Rhapsody. It is in the menu under “File”, there is “Insert Project >” and then “New…” or “Existing…”. Selecting a Rhapsody project will shift both the open project and the newly opened project under a “Projects” folder.
One of the projects (The last opened) is writable (or “active”), indicated by the BOLD name and all others are read-only, indicated by the (RO) behind the name.
You can right-click the project and select “Set as Active Project” to switch to another project.

Copy Paste

It is now possible to copy or link elements from one project in another project. Beware: You can only copy units (Rhapsody elements that are save in their own file, indicated by the small decorator icon in the left lower corner, grey or red)
Just drag and drop will create a reference, indicated with a (REF) behind the name, holding CTRL during the drag and drop will create a real copy.

Absolute vs Relative

This is where property “1” comes into play. This defines how the paths are stored when you have multiple models in one workspace. When you leave Rhapsody with a workspace open, Rhapsody will ask you if the project-list must be saved.
It will save a file in the directory of the first project. The paths to each one of
the projects will be stored according to the setting of the property “1” in that project.
You can edit the project file by hand, you can even move the project file (Take care that you keep the project paths correctly!) but there is a nicer way to do this: just right-click on the Folder “Projects” then select “Edit Unit”. There you can edit the name of the file and the location. You should then figure out how you want to store the paths to the model. My Tip: only use absolute if you are absolutely sure that the paths will be the same on all computers of all people involved in the project. Otherwise: use relative!

Unit

A unit is, as mentioned, a Rhapsody model element that is stored in a separate file. My advice is to keep the default settings (That are good, for a change…) and only take packages, components and the project file as a unit ( project.rpy(x), component.cmp(x) and package.sbs(x), the last two are stored in the project_rpy directory )
Property “2” defines how these paths are stored, here also use relative unless you are absolutely sure you can use absolute.

Conclusion

Bordeaux is fantastic, we had a great weekend and we will definitely return there someday.
Use relative unless absolute will work for you, make sure you have the same setting in all projects!
Using multiple projects in a workspace is perfect if you have divided your model in separate parts that are included in each other.

Remember: Everything is relative, absolutely!

Keep modeling with Rhapsody! wvdheiden@sodiuswillert.com

Walter.

Paris Code Generation.

September 29, 2019 / rhapsody207 / 0 Comments

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 done 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 one 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 with 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

Travel, travel, travel and… my EW 2019 Presentation

April 11, 2019 / rhapsody207 / 0 Comments

Back in the air

The travel continues but hey… I’m the traveling modeler…. Last week I had an appointment in France but close to Switzerland so I took the plane to Geneva again.
As usual the moment of booking is mostly right before the mail or call with the question if you could also show up somewhere else.
Flexible as I am, I always try to arrange that. This was not so easy… I had to be in the south of Germany (Rietheim) and I was in France (Cluses). On the map that was 225km. Via the road it turned out to be almost 500…. The Swiss have these “Mountains” that really take in a lot of space…
But I organize all of it and so I took the train to Schiphol (My second home) and then the plane to Geneva. Unfortunately (also as usual) flights were cancelled and I was rebooked to another flight via Paris. Via CdG, not really my favorite airport (I try to be polite)
CdG lived up to its reputation… although I was only a few meters away from the gate of my connections flight I had to take a detour to go through the pass control… ( What happened to Schengen?) But I made it in time to the connecting flight (I could even drink coffee in the lounge.)

Platinum

Yes. The lounge… since recently KLM has handed me my platinum card. I crossed 300XP within one year. (Yes KLM no longer has miles… you earn XP when you fly, like in Pokémon Go)
This makes the traveling life much more easy and comfortable. And a comfortable place to write BLOg entries…

Snow!

Yep… Snow. And a lot. After flying the second leg of the trip to Genève, I picked up my rental car and drove out of the parking lot and asked myself: What is this white stuff falling from the sky??
It was snowing. I did not expect that. Luckily Hertz was so friendly to rent me a BMW 120d xDrive. (4-wheel Drive ) with decent wintertyres. That helped. But is was quite a drive. So finally I arrived at the hotel that luckily had parking places. And (what I first noticed in the morning, a Skipass machine… I was in a ski area….

Switzerland

the next day, after a good day at the customer I drove to Rietheim in south-Germany. That was a seriously long drive. Through a lot of snow.. And again arriving in the hotel at 10pm… After the customer visit the next day I had to drive almost the same distance back. Not as far because I had a hotel room close to the airport. The next day I returned the car and flew back without trouble.

Embedded World 2019

I have written about that already: EW 2019, we had a booth there but I also had a presentation! Not entirely about Rhapsody but about SECollab, also interesting enough! Here is the link to it: video, it is in English.

That was it! Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Machines in Nantes

October 14, 2018 / rhapsody207 / 0 Comments

I’ve been to Nantes a couple of times. I really like it there. It is a great city, quite large but with a very nice old town. This time I was not alone, the whole company joined me.

We are closely cooperating with Sodius. They are located mainly in Nantes and we wanted to give all colleagues a chance to learn to know each other.

So all the German and US colleagues flew over to have a weekend of getting to know each other better.

The French really made an effort to show the best of their city, country and themselves, it was brilliant!

We had a party on a boat on the river, we were having dinner in the “Machines”, we played “live” monopoly in the city, we visited a vineyard and we had some presentations so that we now know a lot more of each other.

We have a lot to do to integrate both companies but we are all very enthusiastic about the opportunities.

I added some pictures of Nantes and the fantastic weekend we had.

What is the impact of the cooperation for Rhapsody?

We hope a lot and not a lot… what I mean is that I hope that the effects will be positive for our customers. We are now selling our Rhapsody version in France and in the USA as well, that is good, the more customers the better the product gets.

Together with Sodius we own a large part of the Rhapsody eco-system. We now do the code generator, the framework, the XMI and AUTOSAR import and export and some more. It is good to have that in one company, that improves the interfaces for the extensions. Our very close cooperation and vicinity to and with BTC is also an advantage.

Furthermore we now have an extremely interesting product that we will be developing further together, SEcollab. This is a tool that can read data from various other tools like Rhapsody, Doors, EA, MagicDraw, Simulink, MS Office and many more sources, of course it can handle OSLC. It then presents this data in a web browser, readable for everybody (who has the access rights of-course) It can then help you link the information and support in doing reviews.

Other use-cases are the ability to do global configuration (not yet fully implemented) It can even act as a viewer for the data from all sources ( so also Rhapsody! I don’t know how many people have asked me for that in the past years…)

I will write more about SEcollab in one of the next BLOG entries.

For now, happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Paris, Pense!

October 8, 2018 / rhapsody207 / 0 Comments

Salut!

Just back from Munich I was one day at home to switch my suitcase and get prepared for the next trip. This time a bit longer and further away but the start was in Paris.

I had to go to France anyway so I combined the visit with a visit to the Louvre. No not the museum, IBM organized the IBM Think! Conference there.

This was a cool conference, the only problem is that everybody spoke French and all the presentations (but one) were in French.

My French is not as sophisticatedly my German and English, unfortunately… but I managed. There were 2 presentations with fast and unclear speaking people where I really struggled to understand what they were telling, but most was understandable.

The one presentation that was in English was also the coolest (by far…) :

INFRASTRUCTURES ET PERFORMANCES
Aston Martin Red Bull Racing – Brian Jones, Head of Software Development

I think that at least 2/3 of the audience left the room, because it was in English…. Their bad because Brian had a cool story to tell about using big data in formula 1 to achieve an advantage on the competition. Very very interesting, thanks Brian!

At night there was time left to visit the Mondial, the Paris Auto Salon. A nice view on the new cars of today and new technology, very cool!

AUTOSAR

This was a nice “bridge” to the subject of today. The use of Rhapsody in an Automotive environment. We at Sodius and Willert are working very hard at creating solutions that will support automotive engineers to do their complex jobs as good and right as possible.

That is not easy, many OEMs and TIERx companies have very well defined processes and always a high degree of time pressure that makes it difficult for them to change anything in their daily work.

As Henry Ford already said: If I had asked my customers what they wanted they would have said: “A faster horse”. So you can ask your customer (and you should surely do that!) but you have to define your own way at least partly and then convince customers that your way is the better way.

Since using Rhapsody with Code Generation will already change a lot in the daily routine of everybody but certainly in that of the automotive engineer who already has defined run-time systems (that mostly use periodic tasks) The Rhapsody generated code assumes a preemptive OS that allows you to send and receive events and react to them if they appear, and sleep when there is nothing to do. This is a fundamentally different approach than the MatLab approach that even uses “polled” state machines.

This kind of programming is also much closer to the human way of thinking. Many people consider a polling, or synchronous, system to be more deterministic than an asynchronous system. It is not, asynchronous systems are much more scalable and run without collision much longer than synchronous systems. They also fit better in Object Oriented Designs.

Many Automotive systems are only doable when using synchronous systems. All Control Loops work way better and simpler when you do them in Simulink. But there are lots of systems that are asynchronous. Think about everything that is under direct user control, indicator, power windows, HVAC control panel etc. There is lots of asynchronous stuff in a car.

The more complex systems in cars use both synchronous and asynchronous components. The easiest and nearest way to solve them is by using MatLab. Now that tool really helps you to do the synchronous stuff and it also can do asynchronous stuff with no real penalty. So that prevents people from using UML for creating code in an automotive environment.

Now MatLab and its friends will not really help you to gain understanding and reducing of the complexity in new systems. UML/SysML will, they allow you to setup an understandable architecture. But the real benefit will come from using it to program the asynchronous parts of the application and use the code generation.

The funny thing is that most people do not want the code that is generated from a UML tool like Rhapsody but have no objection against code from a MatLab Simulink model.
It took me a while to figure out why but I think I understand that now. Simulink, used by a Systems Engineer generates just a bit of code that is the exact representation of the algorithm. Writing the code for that would be difficult, the formulas are mathematical things that everybody hates to remember and understand. To generate the code actually relieves you from a lot of extra knowledge.
Generating code from UML is not that easy, you need a lot of extra knowledge to apply that. So people do generally not like to use it.

Another big difference with MatLab is that Simulink Code is mostly used in continuous algorithms, the code is incomprehensible but the diagram is easy to understand. UML (and certainly Rhapsody) excel in discrete algorithms. There the diagrams are also relatively light to understand, as is the code, but the code needs some extra stuff around it to work. That is where people stop using it, it is just not straight forward.

So this is the big dilemma of the Sodius Willert developers, but I think we have some pretty good solutions to use mixed UML/Simulink/AUTOSAR environments. We have a very minimal framework that is easily to use inside an SWC, per ECU we only need one Framework, it can handle multiple instances. You can also import and export ARXML to be converted in stereotyped UML/SysML elements. We will present some solutions on several congresses in the next months.

We have experience in using UML in AUTOSAR environments, we have ASPICE experts on board, certainly in environments where certification is an issue (ASIL C or D) we have expertise and matching tools. And we can train you in using them!

SECollab

A nice opportunity to introduce the Sodius/Willert Tool SECollab (Systems Engineering Collaboration). This helps System Engineers to control all data that they use in their development process, they can make links to achieve traceability, use it for reviews (You don’t even need a license for the original tool to do that!) and derive documents for certification purposes.

SECollab is a server based solution, clients use Web Access, so no tiresome installation issues, just login on the website and access all information available (to you, of course!)

Take a look at it, if you like it, contact me for a demo!

Happy modeling with Rhapsody (and SECollab!)

Walter van der Heiden (wvdheiden@willert.de)

Deploy back

April 25, 2018 / rhapsody207 / 0 Comments

Introduction

The title is a bit double today, i was deployed back from india to home and I will explain how you can deploy to your Rhapsody project and not lose the “roundtrip” feature!

Deploy back Rhapsody

The purpose is to deploy and leave all files exactly where Rhapsody has generated them so that you are still able to do roundtripping.
It is not completely straightforward but certainly doable.

Assuming that you have a directory c:\work. In that you have 2 directories, Model and Code. The structure is as follows:

c:\Work
- \Model
  - \MyModel
    - \MyComponent
      - \MyConfiguration
        
        “This is where Rhapsody generates your code”
- \Code
  - “This is where the project file for the IDE is
  - “Generated Model”
  - “RXF”
RXF install
- Tools
  - WSTDeployer
    - WSTDeployyer.properties

The trick is to map the “Generated Model” directory to the “MyConfiguration” Directory. Depending on the age of your deployer this is very easy, easy or just a bit of work….

In some deployers you can edit the name of the “Generated Model” directory in the dialog. If not than there is a deployer.ini file in the RXF installation directory, you can change the name of the “Generated Model” directory to the name of MyConfiguration.

Then move the project file (or the complete project if you have already content in it) to the MyComponent directory, start the Deployer Configuration (In Rhapsody under “Tools”) and select the just moved project file.

That’s it.

Deploy back the traveling modeler

Now that turned out to be a lot more difficult… The planning was to fly home on Sunday Evening. Or technically on monday morning, the flight from Delhi to Paris would leave at 00:15 Delhi Time, 19:45 CET ) I had a late flight (19:30-21:50) from Hyderabad to Delhi and so less than 1,5 hours for my stop-over. From the trip to India I had learned that this was not nearly enough.
At first I thought, well lets just see what happens but since I did not book the flight as a complete flight, missing the plane from Delhi (to Paris) would not be an option.
So I checked the goindigo.in website and I found out I had been clever enough to book a flight with rebook and cancel options. Yeah….
So I rescheduled that flight to be early enough (16:00-18:25) That would be more than enough.
So I left the hotel exactly at 12:00 (CET: 7:30 Sunday )packed and paid. On my way home! I took a Uber to the airport, that was almost an hour drive ( and almost €8.- )

There I tried to figure out where I had to be. That is not too easy, the airport did not make announcements and I was pretty early so my flight did not yet show up on the monitors. But I could check in my luggage (I had booked the Fast Forward Option, a good idea in India…) quite fast. I did not have to stand in line.
So I was there hours too early but hee… better than 1 minute too late…. Spend some time shopping for home, drinking a Mango Lassi, eating something.
The plane left in time and flew on-time. My suitcase was in-time, the bus was easy to find and even waited for me so I was on the correct airport terminal early. checked in my suitcase within an hour of landing…. So it is possible.
But I seriously doubt if that is reproducible, So i did not mind being early. What I did mind is that just before boarding time, Air France started to make announcements about delays.

The plane was delayed. For more than an hour. Not cool, my connection in Paris was only 1:20…. not too long.
The plane left too late but promised to make up for lost time. It was an old Airbus 330. Also no USB chargers and very limited seating room for a continental flight..
On top of that the two ladies in front of me immediately reclined their seats the moment the “Fasten your Seatbelts” light went of. Sigh.

Next to me sat an old lady, very friendly but she only spoke French. i do speak a little French but not nearly as much as English or German… This was going to be a long flight.
Normally (I’m used to KLM) on long flights, you first get a drink, then dinner, with drinks and another drink or coffee after dinner. Then the lights go out and you can sleep (if you like) Air France pushed out drinks together with the food as fast as possible.
The ladies in front of me continued “sleeping” and did not eat. And refused to put her chair back. So I had about 30cm for my food. Thanks!
I managed to eat and drink that without accidents and noticed that there was not going to be anything more to drink or eat.
The ladies in front of me thought that this was the right time to change their minds and to order food and drinks. Thanks!
Chairs were kept in the sleep position, of course.
I got my earplugs and my face-mask and prepared to sleep. At take-off the family in the middle row, 2 rows before me already had trouble with their 3 kids but as soon as the lights went out the kids decided that it was time to start waking up the other passengers. Thanks!
The seats in the old A330 were clearly out-dated. So with a back that hurt, no sleep what so ever I ate my breakfast. The pilot had broken his promise and did not make up for the lost time so I would arrive an hour late in CDG, not really my favorite airport..
Flight attendants could not give much information, just that we landed on terminal 2F and that I had to go to 2E. Sounds close, but I know CDG, it is not close…
I gathered my luggage before the landing so I could run out of the plane fast, I even ignored the ladies in front of me and as soon as the plane was stopped I ran to the door. There I waited until it opened and I started my morning sport… I had less than 20 minutes but…. I made it! In spite of passport check and even a security check (WHY???) that cost me my water (grrr) I made it to the plane in time.
I crashed in my seat, luckily here there were some better tempered passengers, they had fun about me sweating and panting.
I didn’t care, I made it in time. I was pretty sure that my suit-case would not but I did not care. Air France would take care of that.

And then the pilot announced that we would have some delay because of the fog in the Netherlands… To make a long story short… that took 3,5 hours. Leaving the plane was not allowed (They would not let you in again…. many passengers with connecting flights left because they would not make their flights) so I stayed. There was water and a sandwich and finally we took off.
I arrived at Schiphol around . I thought: well there is a sunny side: My suitcase has made it now: not. CDG was not able to adapt. So I waited at the luggage belt for nothing. Then to KLM, report missing luggage, then the train home. I arrived home at 5:30pm, 32 hours after I left the hotel…

Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Nantes – Jules Verne

February 5, 2018 / rhapsody207 / 0 Comments

Introduction

The coolest thing about traveling: you always learn new stuff. Not necessarily about modeling but also about the cities and countries that you visit. I had to do work in the nice city of Nantes in France for 3 days. Nantes is about 1000km through the air and a lot more in a car or by train so we took the plane.
When flying, you have the choice when you’re on location, hire a car or use public transportation.
I’ve been to Nantes before and I remembered that they had Uber there and that the traffic is not really “my style” so I decided to do that. The Uber driver told us a lot about Nantes and one of its famous inhabitants: Jules Verne. There is even a museum there. Also there is a warship museum in the harbor where the film “??” was recorded. Not that we had time for that… but nice to know for the next visit.

What Diagram shall I use?

As long as you use UML to document your software, it does not really matter which Diagram you use for what. It does not even matter if you use the UML correctly. Or even worse, you don’t know while you cannot check if you use the UML correctly. At least in Rhapsody you can generate code to check if your model does what you specified. But there is enough left to do wrong… you can only generate code from Class-, Object-, Package-, State-machine- and activity Diagrams.

Admitted, the UML is not clear on when to use what diagram. The argument for not having that is that it is a programming language. “C does not tell you when to you which statement either”. Correct but if someone else does something in a certain way, that does not force me to do the same….

So the UML lacks a “process” that divides your development in stages with deliverables and rules on what to use when and how.

V-Model

The V-model is still used widely in software development. As it should be because it is a proven way to develop software. The exact way it is used changed over the last decades. From a waterfall model where each stage was finished completely before starting the next to the agile process we use now that makes the V-model more a system where you store your development artifacts.

Process

There are numerous processes that describe how to develop software. Some of them are more common and some of them specify UML or even Rhapsody specific, like IBM’s Harmony. Older processes are still used like RUP from rational, Ropes from Bruce and many more like Automotive Spice (a-spice)
You don’t need to try and follow these processes, you can use them to describe your own process. How thorough you do that is mostly depending on the safety level of your software. Railway systems or cars or planes have huge processes that require really thoroughly described steps.

Requirements

When you don’t know what to do, you cannot do it. So you first have to be clear on what it is that you are building. This is a difficult part for experienced software developers… We (Yes I am a software developer…) are very solution oriented. If somebody describes a problem to us we immediately start to think solution. Write down the real requirements of your product. Concentrate on “What do I need” not on “How do I do that”. You can use a Requirements Management Tool like DOORS (Next) or Polarion or even Word or Excel (Not good for linking and traceability but will work)

May be you are lucky and you will receive the requirements from your stakeholder, like in the Automotive industry.

Then import the requirements in your UML model. In Rhapsody you can use either the Gateway of the Willert RequirementXChanger. These tools will create a package with your requirements. They can even synchronize them if the requirements change and mark the changed requirements accordingly so you can do impact analysis on changes.

What diagram should you use for requirements? That is a good question since the UML does not know a requirement diagram. There are a couple of possibilities in Rhapsody, you can stereotype an OMD (Object Model Diagram) as a new term “Requirement Diagram”. Very elegant way, Rhapsody creates a category for new Terms so that you see them as a folder in the browser. Another possibility is to not show the requirements on diagrams but to create a table where you have the requirements on one axis and your linked model elements on the other. Have a dependency with “trace” stereotype as cell item and you can link requirements very easily. Also possible is to drag your requirements in the diagrams where you have the model elements that you want to link. This will make your diagrams messy but there is a solution for that too! You can apply filters (actually queries) to your diagrams and blend out certain elements.

Analysis

The next step is to analyze your requirements and create diagrams where you extract behavior.
The Diagram of choice here is a Sequence Diagram (At least that is my opinion) The nice thing about Sequence Diagrams is:

Even non-techies understand SD’s
They are easy to draw
They can be used for tests!

You just start drawing the first diagram by treating your system as a black-box, defining what output you expect for certain input. You then create new SD’s by refining the first one in horizontal way (splitting up the system in sub-systems, then sub-sub-systems until you are at Class level) and vertical way (split the functions in sub-functions and so on…)
You can use Class Diagrams (Or Object Model Diagrams) to already start drawing your system architecture that you find out when drawing the SD’s.
Some use Activity Diagrams or even State-charts for this part. There is nothing against that, I just don’t like it. Activity Diagrams are more or less OK but I think State-charts are just too complicated and distract your mind too much during analysing your system. Also if you need to speak with non-technical people about the exact requirements of the system, State-charts are much less “natural” to use.

Design/Implementation

Here you use the same diagrams as in the Analysis and now it is time for state-machines. Together with the state-machines you start creating tests for all your sequence diagrams, in that way you can immediately test if what you have created is correct. And even better: you can do so whenever you have made changes.
This allows you to do Analysis/Design/Implementation in a sort of spiral model. Just keep adding small pieces of functionality, keep starting automated tests (using Test Conductor) and you always have a working system.

Some pictures from Nantes