Month: August 2018

Uninstall Rhapsody

Uninstalling is easy, when you know what to do…

[wpvideo 6icZXjQk]

Installing Rhapsody

This video tells you what options you have to install Rhapsody. It gives a proposal for the best way to do it.

[wpvideo icJnAjFR]

Configuring Rhapsody

And when installed, you have to know how to start the correct version. This video helps!

[wpvideo Bk3M0Y63]

So… that’s it for today

Have fun with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Introduction

This week I’m in Boston at a customer that is starting a new project. I’m helping setting it up, setting up the model and the rest of the development environment.

In the beginning of our Rhapsody days, we were always happy to tell people we were the experts in “Systems with limited resources”. Now. in fact, we still are, just because we have a lot of experience in that area. I don’t think many people know how to handle the specific requirements of modeling in small 8- or 16bit systems with kilobytes of memory and microseconds to respond.

But slowly we have been growing with our customers and we also do larger systems. This week I helped setting up a “larger” system. This a “normal” PC with Linux on it, accompanied by a couple of other boards that do small tasks (and have smaller controllers!)

The use of Linux as operating system immediately introduced one big question: how are we going to implement a framework?
Linux has processes and threads. ( See BLOG entry ) Are we using a distributed framework? Or the normal framework with Threads?
Both have advantages and disadvantages. Distributed Framework is more difficult to implement but just threads will influence the way you can use your system and will not give you all the advantages of memory protection.

We decided to use both ways with a “simple” framework and use IPC to communicate. So we would actually use multiple applications that communicate with the use of the OS.
The trouble with IPC is always that you need some base information to start the communication. You can use a “zeroconf” system like Apple’s bonjour where every client starts and assumes it is the “Master” until it finds another client that already is the master. Or you create a Master that is known by all clients.

We have chosen the last variant. A Master-broker is in the system, waiting and listening on a fixed IPC Channel. Clients report to that Channel with their name and the Master sets up the communication. The client then opens up for its local clients to publish/subscribe that it will communicate with the Master-broker that registers all clients in the complete network. C++ makes a lot of this easier.

It was real fun to set this up. Most work was spend on setting up the development environment and describing how to use it. We use GIT and Sharepoint to do that.
The compiler/IDE is Eclipse in Ubuntu Linux, we deploy code to a shared directory with Windows. IPC on Linux is done with named pipes.

We spend some tie setting up the Rhapsody model so that the package structure was logical and ready for use by multiple people. The model will contain a lot of components that must be built separately. Luckily you can tell Rhapsody to “build all” (which will generate and deploy all in our case) Eclipse can also build a complete project with multiple executables. We also built some test tools to test the Broker setup.

This is what many people underestimate when starting to use MBSE. The UML Tool will not do that for you. It is a a UML Tool, UML is a language, not a process nor a development environment. It is very important to spend time setting that up and documenting it. Use a central documentation tool like Confluence, Sharepoint or MediaWiki, your success depends on it!

So… just work in Boston? Nope… in my 3rd Boston visit I finally had the time to visit “Cheers”, the bar of one of my favorite TV series.
I’ll end this one with a quote from Norm:

“Can I pour you a beer, Mr. Peterson?”
“A little early isn’t it, Woody?”
“For a beer?” “No, for stupid questions.”

“Cheers!” and Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Vacation!

Hi! And sorry for the low BLOG frequency. It’s vacation time. Not that I am on vacation, that would actually mean I have more time to write… No, I am busy at the moment, other are on vacation which leads to more work and I have a lot to do  privately: I’m building a new house.
That is… I have other people build me a house… As I always say: I have two right hands but unfortunately I am left-handed… (BTW: Today August 13 is international left-hander day!!)
So I do not build but that does not mean my work is done… there is a lot to do besides physically building.
So we did not planned a holiday because the house should have been finished around this time….
“Should have been”?? Yep. It’s not.

When software projects go rogue and take longer than planned, one of the things people (non-involved people…) say is: “These software projects… always late… they should learn how to plan just like the people who build houses.”
Well…. That is just sooo not true.. building projects also go rogue. Mine does but others do as well.
Builders plan but the same way software people plan. So plenty of space for mistakes and “unknown”
In my case the architect designed my house with a CAD tool. Not a very advanced one, I am still waiting on a 3D view…, but that is how he did it. The guy is an artist and he draws beautiful houses. We were very enthusiastic about it and we even got the permission to build it from our community (Yes that is needed in the Netherlands)

There were a lot of prerequisites that we had to comply with, it had to fit in a certain part of our (own!!!) ground and it had to have a straw roof (To make it look like the other farms in the neighbourhood)
I did not want that, I wanted Tesla Tiles that create power, but hey…
So the architect draw the straw roof. The drawings of the architect then have to be enhanced by a constructor that knows how you build a house. Then the builder starts organising sub contractors to deliver parts.
It turned out when he ordered the roof that the angle was not steep enough. So the roofer would do it but with our guarantee.
So back to the drawing board and half a year delay (New permit, new calculations…)
So don’t tell me building houses goes better than building software…

So I asked myself: Would modelling have helped here?
I think so. The fact that a straw roof needs an angle of more than 45º is basic knowledge that should have been a design rule in the CAD program.
Moreover, I have not seen anybody work with a tool like Doors or Polarion to fix the house requirements. It is more advanced than the last time I built a house (1986) but it is with Mail, WhatsApp and Word that the house is built.

Back to Rhapsody

Vacation time is a good time to work on improving your Rhapsody models!
Sometimes customers ask me to do a review on a Rhapsody model. What do I do in a review?
It depends of course but for totally new models I do a couple of steps which I want to share with you:

1. Check how old the model is. You cannot see it all but you can ask (..) and check if the model has CGCompatibilityPreX.Y Settings. They tell you the conversion already performed on the model (And the fact that the creators did not know what to do with it)
2. Do a Check Model ( “Tools”, “Check Model”, “<name>” ) This should give you a lot of information about the model. Most common warnings are: “Default Names” and “Empty Description” but there are many more.
   The more warnings, the less precise the model is built
3. Use Metrics to determine the number of elements in the model. Check for requirements, sequence diagrams and classes. There should be a fair number of requirements and a lot of sequence diagrams. unfortunately IBM stopped using the Metrics in 8.2. There is a more complicated system to still do it.
4. Use the built-in document creator ( “Tools” “Report on model”, then select only “Include Overridden Properties” ) to look at the overridden properties. This should be limited to profiles.
5. Do a general check.
   1. How do the names look? Consistent?
   2. How many packages compared to classes?
   3. Are there requirements used?
   4. Are there any Sequence Diagrams?
   5. Little number of properties is OK but not much
   6. What is the number of elements on diagrams. Yes that can be more than the “normal” 7+-2 but they should be understandable
   7. Are comments used?
   8. How is the diagram navigation?
   9. How many level of state-chart are there? One level or at most one sub-state-chart is OK. Everything else must be documented and proved necessary.
   10. Are model elements described in comment?

This is something that you can check yourself…. Do it sometimes.

Happy Modeling with Rhapsody

Greetings from Motown!

Walter van der Heiden (wvdheiden@willert.de)