Month: August 2017

What is it anyway?

Let me start by specifying what I mean when I say: reverse engineering, roundtrip engineering and forward engineering. All in the context of UML and Rhapsody of course.

• Reverse Engineering: Reading in existing source code and inserting it in a Rhapsody model in such a way that it continues to work.
• Roundtrip Engineering: Reading in source code that was generated by Rhapsody but was changed by the user. Note!: Please understand the difference between reverse and roundtrip! It is very different for Rhapsody to read in “strange” code then it is to read in “familiar” code.
• Forward Engineering: Something I invented myself (Or maybe it already exists then I just re-invented it…)  It is reverse engineering but the user will take the result and do the necessary steps to make a decent UML Model out of it.

So. As I already wrote in a previous post, I don’t like reverse engineering. Sometimes you need to do it but it is something that prevents good modeling IMHO.
Roundtrip Engineering is OK although Rhapsody knows 3 modes there: Basic, Advanced and Respect.

• Basic: Allows you to change code that is between the Rhapsody generated comments: /*#[ and #]*/ That is the code that you type in state-chart entry/exit/transition and in the implementation body of your operations. Nothing else, changes to other parts will be ignored when Rhapsody generates new code. Is not trivial since Rhapsody sometimes uses the same code twice and will then ignore your changes! (Of course without commenting it…. Rhapsody is a tool for real men…) ***Recommended Setting***
• Advanced: Same as Basic but also allows you to add attributes and operations. Is also OK if you know what you are doing but keep way from it until you know what the effects are of what you change.
• Respect: The “Evil Knievel” option. Or “Eddy the Eagle” if you prefer him. This allows you to change every line in the generated code. Rhapsody will try to keep it as long as it is syntactically OK. To make things worse, Rhapsody will store this information in “source artifacts” that are hidden by default. (I still wonder which sadistically inclined person designed that option….) ***Not Recommended at all Setting***. At least switch on “Show Source Artifacts” (“View”, “Browser Display Options”, “Show Source Artifacts”).

So you have to be careful using these options. This is all more valid for ‘C’ then it is for other languages like ‘C++’ and Java, these languages are much closer to the UML and ca therefor produce much better results when doing reverse or roundtrip engineering!

LCD Display on the Keil MCB1700 Board

We use that board for our trainings. We do this since years and we use the LCD display on that board using some ‘C’ files that Keil provides. GLCD.C and GLCD.H. Here are these files: GLCD so you can check yourself.

The .h file has function prototypes (Useful for checking which functions are “public”!) and the defines for the colors. Reverse engineering will show these as types.

The .c file contains a couple of defines that are reverse engineered just as the all the defines in the .h file. Then there are all the functions. After examining the functions we can see that there are “public” functions (GLCD_xxxx() ) and “private” functions (spi_)

In the training we include glcd.h via the “external file” mechanism and the dependency with “Usage” stereotype. Glcd.c is inserted via the Component file and a “text element”. This works fine (And is of course aimed at learning different methods to use legacy code)

Reverse engineering also works, I tried, you can call the functions if you have reverse engineered them.

But we want something else: we want Classes that are completely generated from Rhapsody! So first we will create a class GLCD. Since SPI works a little bit different we will use a Singleton Object there.

Then we move all the functions to the respective class/object. Nice side-effect: the “me-pointer” is added automatically! But unfortunately… not to the code. This is where you have to do some work, add me-> to all uses of the attributes. I have created attributes from a few variables like orientation, bbps and position. You can add them to the init function. That is something that also needs to be done by hand: The init function must be converted into a constructor (initializer)

The SPI functions are moved to the SPI object. No me pointer is needed there but I used the variables that determine the exact version of the LCD hardware to attributes, you have to add the spi.<attribute> yourself.

The colors must be converted to an enum type. A bit of work which cannot be done automatically but it is worth it! (Why this is not done in the original ‘C’-code??)

I added some fine-tuning like converting some variables to enumerations or at least types, always a good habit in programming: let the compiler check as much as possible!

The result is quite nice: RhpGLCD, see for yourself.

Happy modeling with Rhapsody and greetings from the Bavarian Forrest!

Walter van der Heiden (wvdheiden@willert.de)

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)