Disaster days and how to handle them.

We all know them…. disaster days. Mostly they are already starting bad. Like cars that don’t start, public transportation that strikes. Rain that pours, people shouting at you for no obvious reason. That is a day where you should not have ignored the signs and have stayed at home in your bed. Sometimes this just happen “out-of-the-blue” sometimes it is self-inflicted while you suffer from an overdose of “cool party last night”

But no, we are tough. We persist and fight our way through the day. But the real surprise comes next day when everything is working OK until you check last days work….. This is the point where you start thinking about Configuration Management Systems or at least Source Code Control…. Too late, you should have done that before…;-)

Yeah Right….

Making a zip file from your working directory every day is a solution, (and definitely better then nothing) but there are better solutions, certainly if you are not alone in your company.

Source Code Control is very old, on Unix Systems this is been used since there are Unix Systems. In the personal computer area this is a bit newer but also used a long time. The last 10 years or so, many people use Subversion (SVN) or Git, sometimes still CVS. All these are open source systems, you can just download them and use them. Since millions of people have, these systems are good, very good.

Of course there are still commercial systems that cost money, sometimes a lot of money. That does not make them better than SVN just different and they have a phone number that you can call when things don’t work.

More then a backup

Config Management does so much more than just saving you from bad days, it helps you preserve versions and releases, it helps you cooperate with colleagues and prevent changing the same stuff twice (the first one in is out….)
Modern systems use automatic difference/merge tools that are pretty intelligent and can merge files that are edited by 2 persons. As long as not the exact same things are changed, these tools do a good job.

What does this has to do with Rhapsody?

Everything…. If you develop with Rhapsody you also want to preserve stuff, cooperate with co-workers and much more.
And… no…. you don’t just take the source code and put that in CM, the model contains much more information then just the generated source code. In fact, the code can be generated from the model ALWAYS. (In fact it is Object code…) so don’t bother checking that in. (Only if you don’t trust Rhapsody…. or if you want to speed things up.)
Yes! You put the model under CM’s control. Now how is that done?
Rhapsody does not have a CM System built-in, it uses either the good old command-line or the a bit better and a bit less old SCC, the Microsoft Source Code Control. The latter is a registered DLL that is called by Windows. Works faster (although hardly noticeable on modern computers) but much nicer then command-line.
Unfortunately neither CVS, nor SVN nor GIT know SCC… there have been tools to create an SCC Interface, PushOK and TamTam but both have been discontinued for years (and PushOK is Russian, used to be a problem in the US but that might have changed….)
Luckily we have created a profile for the use of SVN via command-line. It is included in all Willert adapters but if you want it: send me a mail, i will send it to you.

What do we CM then?

Units. What are units? That are files that Rhapsody uses to store its models. A Rhapsody model is not just one file, per default the base model file (.rpy), all packages (.sbs) and Components (.cmp) are stored in files. Since all CM systems are filed base, this is the only thing they can process in CM.
You can use properties to tell Rhapsody to store diagrams in units and you can even tell Rhapsody that a Class is a Unit (right click, create Unit) but I do not recommend that. It is a sign of bad design if you need Classes to be units.

How is the Workflow?

There are 2 possible workflows

• Old-fashioned lock and free
  Once checked in CM the model is read-only until you check-out your “unit”. This is then locked for all others until you check it in again.
  In that way nobody can accidentally overwrite stuff that others have made.
• Work and Merge
  All members of the team have a copy of the model, they all work on it until happy, then use the (included) DiffMerge Tool to merge the changes in the base version. There is more risk that people are changing the same model elements but many of these changes can be automerged back.

Which is the best workflow? As usually: that depends. On how you work, with how many people and more. Also on how you have built-up your model, do you have one large model? Or do have divided into multiple models? In one of the next BLOG entries I will write more about methods to split the model up in smaller models.

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Why a Framework?

Actually quite easy. When you generate code from UML you need a lot more then ‘C’ or ‘C++’ can offer you. Java is different, it has a VM that does most of the things you need. But ‘C’… how do you start a thread in ‘C’? Or how do you start a timer in ‘C++’?

Right. You can’t. At least not in the base language, you need an external library for that.
The “extra” functionality in the UML is all RTOS based functionality. So it seems logical to use an RTOS for that. To make the use of any RTOS easier it is smart to implement this in a framework that does the translation to your RTOS. in that way, the only thing you need to do is adapt the Framework to your current environment and your UML model should be runnable in that environment.

In an embedded environment this is only part of the story, many hardware and even compiler dependant parts exist. Modeling certainly helps you but you should take extra care to separate your hardware dependant parts in your model.

Also the framework adaptation is not always straight-forward but the reward is high when you stick to the standard: you can be independent of the environment you use.

We have done a model conversion from one environment to another environment twice, both times it went with minimal effort. As close as you can get to the holy grail of embedded software development: platform independent programming. But I will be honest… we are a long way from reaching that in the embedded world.

What Framework?

There are quite a few Frameworks for Rhapsody. Out of the Box there are already a few. Are they any good? As always, the answer is: that depends….

On what? On what you want to achieve with it. Creating a PC application, Linux or Windows? Real-Time does not bother you, nor do you care about memory usage?
Than the standard OXF is your friend! It is the default in Rhapsody, you don’t have to do anything. If you are lucky enough to own a developer edition, animation, panel diagrams and webify are there to support you.

What Frameworks are there to choose from:

• OXF, standard Framework
  Is not small, is not fast, is not deterministic, blocks interrupts for unknown time, uses an RTOS.
• MXF, MicroC (Automotive) Framework, uses OSEK as RTOS
  in combination with the AUTOSAR import/export
• SMXF, reduced MicroC Framework
  Targetted for use in Certification projects
• RXF, Willert Framework
  Small, fast, C and C++, UML Target Debugger for back-annotation, enhanced Workflow, available as Cert with documentation.
• IDF – Interrupt Drive Framework
  Single threaded. Started as a demo for “how the framework works”, is available and adaptable. Was designed to be small
• SXF – Simplified C++ eXecution Framework
  C++ for Safety critical. Is also only static
• synchronous Framework
  For very small environments, discards a lot of UML functionality, programming only with triggered operations.
• NOF, No Framework
  For the real die-hard…..
• ?? Did I forget one?

So here we have a few criteria that you can use to support your framework decision:

• Code size, use an RTOS or just a main loop?
• Language, C, C++ or else?
• (Real-) Time behavior, are interrupts disabled? If yes for how long?
• Safety viewpoint, MISRA? Is there documentation about safety?
• Animation and Back-annotation, UML debugging available?
• Simulation, on PC?
• Hardware abstraction / Portability, fast switch to other environments?
• Memory Management, static or “half”-dynamic?
• Workflow, build in Rhapsody or elsewhere?
• Limitations, Ports, Container Classes, Dynamic, etc

Check the criteria before you make a decision. As you can see, the Willert Frameworks (RXF and RXF-Cert) have excellent notes on all items.

PEPS

We use a model to test framework speed, the speed unit we have is PEPS (Processed Events Per Second) We have invented that ourselves since there was no other measurement available.
The model is there for use in other environments, it is pretty standard so it must be easy adaptable to other environments. Ask me if you want to have it!

Happy Modeling with Rhapsody

Walter van der Heiden (Email: wvdheiden@willert.de)

Yes who?

Everybody of course. Don’t be daft. I know software developers hate writing documentation. Why do i know that? I am a software developer myself… takes one to know one.

But when using Model Driven Software development, documentation is not that hard anymore. In fact, you are writing documentation while you are developing, almost without noticing it.

Oh, don’t get me wrong here, it is not done fully automatically, you have to do the right things, like putting effort in the way you build up your model. When you don’t, the same happens when you write source code without documentation.

It is fully possible to create a working (meaning: the code you generate will do what is expected) UML model from Rhapsody without a chance to understand what is happening by reading the model. Or as we used to say: you can mess up things pretty bad but to really screw things up requires a computer…

So. Let’s assume we modelled the right way. Now what? The boss wants to see what we did and I have to present the model for him/her on paper. How do we do that?

Well: Rhapsody offers multiple ways to document your models and make the information available to others.

1. Use Rhapsody. Sounds a bit awkward but the best way to look at Rhapsody models is with…. Rhapsody. Don’t start with: But that is too expensive… there is an Architect Version that suffices for viewing the model for about € 600,- But a tiny bit of knowledge about models is required so that might not be the 100% solution.
2. Use Reporter. It’s free. And it does documentation! So where’s the drawback? Well… it does documentation but that;s about it. There’s no formatting, you can only decide on a high level what will be in and what not, it’s just in RTF, no other formats and you can edit the documents but they will be overwritten when you regenerate them. So…. only limited use.
3. Reporter Plus, is the version that costs. I’m not sure what the price is but since you ony need one, normally, that should not be a problem. This can write Word, PowerPoint, RTF and even HTML (with javaScript). The last format is pretty cool, it can build a web version of the model where you can click your way through as if you are using Rhapsody. The creating of the documentation template is a lot of work but not really complicated. Can document what and how you want.
4. Publishing Engine is the successor to the Reporter Plus. Can document data from multiple tools, that can be quite handy when you also use Doors or other IBM Tools. Must also be purchased , but again, mostly only one license is needed. Is also not too complicated but a lot of work to make perfect documentation.
5. Another method is often overlooked. But is sometimes the best way to do stuff. The Rhapsody Java API! It can access the model, it is built-in, (for free!) and is not too complicated. You are free to create any doc you like.

So. I hope this helps you in deciding how to document! If you have any questions, don’t hesitate to ask!

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

OK… Stuttgart again. I’m there so often that people think I live there… “Neigeschmeckt” they call it … (Something like “Tastes new” but ask a Schwabe if you want to be sure…..) To make it halfway bearable I’m with a different customer again. And I’m not alone, Joachim is joins me for the training part and on Wednesday for support with our AUTOMOTIVE Rhapsody Model and later Andreas will join us on Wednesday for the MDSE part.

Yes correct, I’m with an Automotive customer again (what are the odds…) so a lot of extra constraints that are less important at non-automotive sites. They always use AUTOSAR, they never buy chips that have enough memory or enough power to do the job, often they have a very cheap CPU but there is only a CPU manufactured compiler (horrible, sometimes these don’t even fulfill ANSI-‘C’….) And they have time constraints that make all other projects look relaxed.

But this customer might use a bit different approach. At least a decent (although very expensive) compiler: Tasking and a decent (although complicated) CPU: Infineon TriCore. But they are determined to use MDSE and willing to put in the necessary effort.

It was a very nice week with very productive sessions. So I’m sure I will see a lot more of Stuttgart in the next months….

Back to Rhapsody. We had a new case, a customer from…. Stuttgart…., with a question I heard before. But that was a long time ago so i decided not to do a copy/paste solution but to dive into it and see if there were better solutions now. And there was…

The problem, or actually the question, was “How do I use Doxygen within Rhapsody”. Simple question. For those who do not know Doxygen: this is a system (Open source) to document C or C++ (amongst many others but these are the interesting for us)  source code. ( www.doxygen.org ) Of course it is Dutch, what else, and many developers use it.

You can document your source code with certain special comments, Doxygen will look for that and generate either an HTML or a LaTeX file. It can do stuff like generate call trees, looks pretty neat.

My first reaction, years ago, to this question was: why do you need to document your source code? It is generated, who cares? But that is too black and white. A lot of source code inside Rhapsody models can be documented and a Rhapsody model is, of course, way better as documentation but not everybody has Rhapsody! (We are working on that one…) So there is an actual use case for generating documentation from your partly generated source code. We even use Doxygen to document our RXF Framework!

But how do you do that? Simple way is to just use the “Description” field in Rhapsody, it will appear in the generated source code. But there are ways to make this more comfortable.

The “old” solution was to add some properties to your site.prp (sitec, sitecpp) But in modern time we can use profiles for that. So i decided to put the stuff into 2 profiles, one for C and one for C++.

A very nice feature of Rhapsody is that it has profiles. In these profiles you can do a lot of stuff that, once the profile is loaded in a model, has great influence on that model. You can set properties, define stereotypes and define tags. You can also define model elements that will be copied (and adapted!!) to your model and much more, I will write about that in a later Blog entry.

When you define tags in a profile and you assign these tags to a specific model element then (It’s magic!) the tags appear in all that elements in your complete model.

Another nice feature is that Rhapsody has a “Description Template” property for many model elements. In that property you can define what comment you want with that model element. You can use tags there ($TagName), the content of that tag will appear in the description. Quite cool eh?

So if you predefine some tags with Doxygen Standard Comments and you make a clever description template you can generate your source with the correct Doxygen Comments. The nice thing? I already did that for you, just download the model (8.1.5, if you need an older one: just ask, I’ll generate it for you, but you will owe me a beer…)

Download at: DoxyGen815

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

I do a lot of traveling. A whole lot of traveling. Mostly Germany but sometimes outside or way outside. But the city I travel to most is Stuttgart. Not because my car was made there but because we have lots and lots of customers here.

Stuttgart and the surrounding cities are not bad, just the traffic is really murdering. They even beat Munich in traffic jams. Part of it is caused by the geography, Stuttgart is a whole between some hills, there is no way you can build decent roads, what is there must be used, no room for more roads.

The other cause is the so-called “Stuttgart 21” plan. This involves railway only but it will take the complete main station and move it underground. If you look where the station used to be it looks like a nuclear bomb just went of…. Big hole with lots of machines. This has its influences on railway traffic but also on everything that goes through the city.

This week is Rhapsody Training at a customer. 5 days! A long time ago a 5 day Rhapsody Training was normal, unfortunately this is no longer the case. It went to 3 days, often only 2 days and there are companions that estimate their employers to be able to learn UML and Rhapsody in 1 day.

This is, of course, total rubbish. Learning UML and Rhapsody takes just as long as learning ‘C’ and compiler/debugger. If by now you think: “Learning ‘C’ goes quick” then please dig your memory for the truth…,. Before you are an experienced ‘C’ programmer, years go by!

The UML is not more difficult or easy to learn, it is just different. And… you have to know ‘C’’ (or ‘C++’) before. This is what Rhapsody generates.

What is difficult about UML/Modeling? Well.. the way you do it is very different from traditional source code programming. I think that is the most difficult part for most “converted programmers”. Modeling is an art, you learn it by doing a real good training (like ours… 😉 ) and by doing it! You need to practice, read a lot, try a lot.

I see many people using Rhapsody The way they use their IDE, try until the code generator produces the desired output. This is wrong! Follow the paths that people like Bruce Powel Douglas and others have described in books, modeling is a lot of work. In the end you will save because the number of errors and changes will be way lower than with traditional programming.

It pays of to invest in a good process (which diagram should I use when?, what information is where?)  and in making your model so that it is actually your documentation. Modeling takes time but it is time you have to take anyway to give your brain the time to understand what you are doing.

I always say: a model behaves just like your car. If you car is dirty, it does not drive “good”. As soon as you wash and vacuum it, you will sense that it drives “better”. Subconsciously, admitted but true. A model behaves the same. If you make it nicer, with straight lines and with elements that have the same size and are outlined you will notice that it makes more fun to use the model. Some think that the drawing part is wasted time: trust me, it’s not!

So beautify your mode, insert navigation information so that other can also find their way in your model, use enough diagrams, (every diagram should answer a question) use requirements that you connect to model elements to show traceability. Use stereotypes, profiles and tags to store information in your model. After a while you will do that automatically and the quality of your modeling will increase dramatically. Also re-use will be much easier then it was.

Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

On Tuesday June 27 we had our yearly RUGS&DUGS. That is the Doors and Rhapsody User Group Summit. Actually the correct abbreviation would be DRUGS. Is fine with me (i’m Dutch) but my German colleagues were against that name. Well OK… but acronyms ending in UGS are all problematic… well except Hugs I guess 😉 Check out RUGS/DUGS in google…

But the conference was successful despite the name, a lot of users were there. This year we were in München, not exactly my favourite city. Or to be precise: i hate Munich. Traffic is hell, public transportation sucks, hotel cost a fortune unless there is a fair then hotels cost more than a house in north Germany, the local soccer team are a bunch of tax criminals.

Enough about bad stuff, onto the good stuff. On our User Group Meetings (and also the MESConf we held the day before) we use something called “Open Space”. This is something that was invented by Harrison Owen and David Belisle. These guys organised conferences and in their evaluations they found out that most people liked the conversations they had during the breaks best. So they figured out a way to extend the conversations during breaks: cut the presentations and formalize the breaks.

There is a time/place plan that allows for multiple conversations to take place, participants determine the topics themselves, put them on a board on a specific time and place and others can, with a look on the board, determine what is interesting to go to.

Works like a charm, i’ve witnessed an Open Space conference a dozen times now and all were great. You can learn a lot in a short time.

More Info

This is one of the methods we use to spread our knowledge about MDSE/Rhapsody/Doors/etc. Other methods are:

this BLOG!

FaceBook

Twitter

IBM DeveloperWorks (Recommended!!!)

Rhapsody4You (please use Developerworks from now on!)

UMLforum (use Developerworks please!)

Andy’s Page

Training & Coaching

Download Portal

Support

You see, enough possibilities to extend your knowledge and become an MDSE Pro real fast! About the forums: In close cooperation with IBM (Thanks Johan Adelgaard!!) we decided to concentrate all Rhapsody knowledge on the IBM site. You will need an IBM ID to login but that is totally free and takes 1 minute to set up.

The next UML Trainings are:

• 19. – 21.09.2017 in Stuttgart
• 14. – 16.11.2017 in Bückeburg

Happy Modeling with Rhapsody!

Walter van der Heiden, wvdheiden@willert.de