Rhapsody TechBlog

BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Page 16 of 16

Backups are for woozies

June 11, 2017 / / 0 Comments

I always use to say: Rhapsody is a program for real men.

Not that it is unsuitable for women… far from that. I’m jokingly trying to make clear that Rhapsody leaves a lot to the users attention.

Unlike most Windows versions Rhapsody will never warn you when an action can have consequences that might hurt. Hence the “real men”. Apparently they don’t cry in these situations. Unless they have the flu but that’s a different story.

Rhapsody comes in various flavours, C/C++/Java/ADA (C# was discontinued a while ago) and also some SysML and UML Versions. However, there is only one rhapsody.exe on your hard-drive (unless you have multiple versions installed, yeah, yeah)
The command line or rhapsody.ini combined with your license file determines which version is started. Rhapsody says in the menu bar which version you just started, this is where you should pay attention to prevent a lot of work afterwards.

Language

You can open a Rhapsody in ‘C’ model in Rhapsody in ‘C++’, in fact it will still be a Rhapsody in ‘C’ model and ‘C’ will be generated. The “last opened model” list will show you the last opened models regardless of the language. The trouble is when you inadvertently start with a ‘C++’ model and wanted a ‘C’ model. You can repair that but there will always be remains of the original language.

Rhapsody “Version”

I don’t mean 7.4 or 8.0. I mean Architect or Developer. Starting the wrong Rhapsody is not so bad, you will notice when you start using options that are not supported. The models are the same, Rhapsody cannot determine with which version they were made. So you’re OK there.

Version

Now i talk about 7.x or 8.x. That is different. Opening a “new” model with an older version of Rhapsody will not work, you get an error message. Opening an old model with a new Rhapsody works. Unfortunately…. no warning is issued, even not when you press save!

You notice the problem once you try to open the saved model with an older version of Rhapsody again…. no luck…

You can see that your model was older than the Rhapsody version, your model browser will show a “settings” folder that contains entries named CGCompatibilityPreXY. This indicates the model was made in an older version of Rhapsody.

I saved in a new version… what now…

Since 7.4 Rhapsody knows a “Save As” (One ’s’…) where you can select an older version to save to. Looks nice but remember: only 2 versions back… Luckily some newer versions of Rhapsody do not use a different format for the models so you always can go back 4 versions. But going from 8.2 to 7.4 is a lengthy process and involves 6 different Rhapsody versions…. The success is also limited, most versions of Rhapsody complain when doing “save As” that “information will get lost” but no indication is given to what might get lost…

What to do with CGCompatibilityPreXY?

Get rid of them ASAP. How? Easy! Before opening the model with a newer Rhapsody, generate code with the older version. Store that and then open with the new Rhapsody. First generate code and compare. If nothing has changed: lucky you! If there are changes: check if they interfere with your software. If yes either try to find out yourself what you can do about it or ask us: support@willert.de. We will help you as good as possible.
Now click on one of the CGCompatibilityPreXY’s, open the properties, switch to “Locally overridden” and check if this property might influence your model and/or code. If you don’t know: generate code and compare. If you need one of the properties: set it in your own profile, if you don’t need it: dump it. Go on until all properties are accounted for and then delete the CGCompatibilityPreXY file. repeat that for all files until you are done. Beware that there are properties in the CGCompatibilityPreXY files that are only for compatibility reasons. They will not appear in the standard property files! The only way to add them is to add them in the site.prp (or siteC.prp file) (I don’t like that as well but there is no other way)

Crash…

Rhapsody is a very stable program. The latest versions are suffering from some instability however. This is not al to blame on IBM. Most of the problems are caused by Microsoft and IT departments that treat software developers as all the other windows users in the company. Windows policies, lack of rights, incompetent system administrators, a deadly combination. As already said in <<>> link, installing is something to consider carefully.

But… what to do after a crash… or better before a crash. By default Rhapsody makes autosaves, every 10 minutes. So when a crash happened and you start Rhapsody again it will ask you (when opening the crashed model again) “Autosave exists, load autosave?” Be careful what you answer here… it is a one-time answer…. The one you choose will be selected, the other deleted. As I said before… Rhapsody is a program for real man. If in doubt: make a copy first. Or better: use config management.

There is General::Model::AutoSaveInterval, set that to a lower value to increase the saves.General::Model::BackUps can be set to One or Two to make backups of your model when you save. General::Model::SaveBeforeCodeGeneration can be set to TRUE so that code generation automatically saves your model.

 

Happy Modeling with Rapsody!

Walter van der Heiden (wvdheiden@willert.de)

Properties. Stairway to heaven, highway to hell….

June 8, 2017 / / 3 Comments

Where to change?

One of the cool features of Rhapsody is the large number of properties that allow you to configure many things to your needs.

One of the scariest features is the large number of properties that allow you to really make a mess of your model….

The truth here is somewhere in the middle. Properties are definitely very cool but should be used with care.

  1. Do not use Factory.prp or Factory<Lang>.prp to let Rhapsody use your properties. Not never…. Every installation uses its own Factory files and they can be changed so copying them from an old installation is not an option. It is called “Factory” for a reason.
  2. If you really have to change something globally, please use the “Include” statement in the prp files so that  your properties are stored independent of the Rhapsody installation.
  3. Using changes in Site or Factory are not really the best way of doing stuff. You have to install the same files on _every_ workstation in your organization otherwise it is possible that you are confronted with unwanted behavior.
  4. Properties belong in a profile so that you can load many settings in one go. You can store the profiles under the Rhapsody Share directory (Share\properties). When you create a txt file with the same base name as the property file you can add a description and the “New Project” Dialog will show your property file under “Settings”
  5. Not all properties can be set in a profile, model level properties for instance cannot be set on profile level.

Limit Roundtrip errors

A default setting in Rhapsody that really does not make any sense is the Roundtrip settings. Default Rhapsody lets you change whatever you want and hides the results for you. I’ve had crying man on the phone that were desperate while Rhapsody generated code that they could not understand. The default is OK for Rhapsody Experts, they know what to expect but for newbies it is just wrong.

So change:
Browser::Settings::ShowSourceArtifacts to TRUE and
C_Roundtrip::General::RoundtripScheme to Basic

That will limit your changes to what you can change anyway (Function contents and other stuff that is between  /*#[ …. */ and /*#]*/

Model Beautifier

Curves are nice but in different types of models. Not in UML models. For reasons beyond our understanding IBM has chosen curved as default. There are a lot of properties involved to cure  that. This is done best in a profile. In Subject “StatechartDiagram” you can find al the properties you need.
StatechartDiagram::Transition::line_style set to rectilinear (or rounded_rectilinear)
I think you can handle the rest of the properties yourself. Another that is useful is:
StatechartDiagram::Requirement::RequirementNotation set to Box_style if you want.
ObjectModelGe::Requirement::ShowAnnotationContents can be set to “Specification” because that is what you want to see.
As you see, all model elements have properties in different diagram types, yes… you have to change them all. A bit of work but very rewarding!

User defined Types

When using your own types you will notice that the PreDefinedTypes packages stay there (and cannot be deleted). You can however hide them with:Browser::Settings::ShowPredefinedPackage to False.
Then you can either create a package with your own types, or use a package with external types and include <stdint.h> to use C99 (or define C++ stdint types)
Change: General::Model::CommonTypes and add your own type packages (Use fully qualified names when using subpackages!, multiple packages can be separated by ‘,’) to have only your own types when selecting the type for attributes or arguments etc. In General::Model::DefaultType you can set the default (“TypePkg::Type”).

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Installing Rhapsody

May 30, 2017 / / 6 Comments

Starting with Rhapsody

The first thing you need to go through when you want to use Rhapsody is the installation procedure.

This used to be easy (Everything was better in the past…) in the Windows XP times. But since Microsoft was not capable of making Windows secure without going through 200 detours, from Windows 7 on, installing is a pain in the lower back.

Have I already told you that I hate windows?

Windows does not allow applications to change stuff in the c:\Program Files (In other languages this is named differently, i.e. in German it is c:\Programme)

I’ve heard a lot of people saying: No problem, I am administrator! Yes. You wish. Windows decides otherwise. Only install programs are allowed to write in the Program Directory, then Windows creates a rollback point and when a normal application writes your Windows can decide that said changes are not allowed and it will roll back to the previous situation.

Since Rhapsody has a very large data directory (/Share) that needs to be installed in another directory. This is where trouble starts….

Default is that the Rhapsody Program Files are installed in the windows Program Directory, the Rhapsody Data is installed in your user directory (c:\users\)

Now during installation, one menu offers you 2 ticks:
– Install everything in one directory
– Install for all users

The first is deadly when you use it to install everything under Windows Program Files. On the other hand, the same menu also offers you the possibility to change the install directory, This is how you can create a separate directory for your development tools which is HIGHLY RECOMMENDED! Windows will leave your tools alone and you have everything in one directory.

The second tick makes your situation even worse since your Rhapsody data will be installed in a (default) hidden directory c:\ProgramData. The advantage would be that you can use the same Rhapsody data for multiple users on your machine (as if…, technically it is not even allowed, you would need a floating license since standard license is an authorised user…)

Which version of Rhapsody should I install?

Easy answer: Developer. Always. It contains all you need even if you have a different license. Select the languages that you will really use (C, C++ or Java)

The advantage is that you have installed all you need. The drawback is that Rhapsody is now setup to automatically start the developer, which is less desirable when you do not have a license for that version.

But you can edit the rhapsody.ini file, two lines in there determine which rhapsody is started by default:
DefaultLanguage=c (or C++ or Java)
DefaultEdition=Developer (or Architect or Designer or SystemArchitect)

You can also override this options by using the command-line. -lang=C -dev_ed will start the developer. -architect, -designer -systemarchitect -lang=C++ -lang=Java will start what you want.

That’s all?

Nope… We have found out that Rhapsody install does not solve all dependencies correctly. The best way to use Rhapsody is to start it as Administrator once. Just right-klick and select “start as administrator”. Open a model, save it and leave Rhapsody. You should be OK now.

32-bits or 64-bits?

Unfortunately still 32-bits… the 64-bits versions lacks features that we love. IBM is working n it really hard and I hope we can soon give the advise to install 32-bits.
Also the Willert Embedded UML Studio is based on 32-bits, it is not _really_ installing well on 64-bits Rhapsody.
There is no _real_ disadvantage since Rhapsody can only load models that are 1.5GB max. That will still fit in a 32-bits environment.

Not Anymore…

Since Version 8.3 there are no more objections against the 64Bit Version! On the contrary, we recommend to install the 64Bit Version. Our Installer is adapted to it (Check out the DLP)

Happy modeling with Rhapsody! CU next time.

Walter van der Heiden (wvdheiden@willert.de)

AUTOSAR meets Fjällbacka

May 18, 2017 / / 0 Comments

The Willert AUTOSAR Team (Clemens Maas and me) regularly visit the AUTOSAR meetings. (See: AUTOSAR WebSite)

Since our succesful introduction of Rhapsody @ Marquardt (See: Referenzstudie (German) ) we do more and more Automotive. The increase of software in cars is helping us to more and more Automotive customers that are all struggling to create their software in time and without (greater) errors.

AUTOSAR is the Automotive worlds standard to improve software development. It is an organisation that is founded by the major (mostly German) Car manufacturers. You can become a member and in that way cooperate and contribute to the software standard.

What does this have to do with Rhapsody? Good question…. I’d say: everything. With Rhapsody (UML or SysML) yo can also improve your software quality, time to market, re-use and more. The combination of both worlds is, however, not really easy.

Many AUTOSAR artefacts look like UML or SysML artefacts but are different. Rhapsody is used to store everything in its own database (not a real database but it’s own file format) and not used to export stuff to cooperate with other tools like MatLab. This is something that is defined in AUTOSAR, the ARXML files that you exchange on all levels for information interchange between tools.

Rhapsody has an AUTOSAR profile that allows the import and export of ARXML files. When you want to use Rhapsody for Architecture you can then export your Rhapsody model as ARXML to do further work in other tools. The other way around is also possible, you can draw your architecture in a Vector or Elektrobit tool, export ARXML, import that in Rhapsody and then create RIMBOs to add behavioral elements.

Sounds complicated and… unfortunately…. it is. We at Willert have designed an “AUTOSAR light” solution that allows the use of Rhapsody on a much simpler level. We import ARXML but convert all items to standard UML items. You can add behavior in a normal Rhapsody way, generate code and… it works. in the current version you have to do some stuff by hand but we are working on automating that as well.

So….back to Fjällbacka… a very nice town, we can recommend a visit!

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Marquardt – Rhapsody unlocks doors

April 2, 2017 / / 1 Comment

Introduction

The software development division of the Marquardt company decided in 2012 to switch from structured programming using ANSI-C to a model driven development approach using UML including automatic code generation. The reason was to have a better position in the future to master the increasing complexity and requirements in the automotive supplier market easily.

THE PROJECT

The first project where MDD was used was the development of a wireless keyless-entry/keyless-go system for a well known German car manufacturer. The hardware platform was a 16 bit controller with 64 Kb ROM and 4 Kb RAM. The application to be developed had to cope with limitations as the very small footprint, the minimal processing power and still require very little resources at startup time.

These challenges provided the Marquardt Software Design team with at the trigger- after successful proof of concept – to do a future oriented switch and become an ‘Early Adopter’ in Model Driven Development (MDD).

AT THE START

The assumption that MDD could be of great use in software development was initially quite controversial in the software development team. Also the question if the keyless system would be a suitable candidate for a pilot project was doubted, especially due to its its stringent resource requirements and the short time to develop. However, in the end it became clear that the
traditional methods of structured programming could no longer be used for such high requirements and time constraints in future projects. And although this keyless system project was not an ideal candidate as pilot project, given the short Time-to-Market that is common in the Automotive market, Marquardt decided not to wait with their switch to MDD. Its customers would benefit enormous of the innovative approach. The risks were carefully calculated and Willert Software Tools GmbH offered Training and Coaching during the entire product development process and helped in the Switch and the changed process.

Inlay Bennie Mattes

DURING THE PROJECT

The project was carefully planned as pilot project to recognise the advantages of MDD during development. An investigation of tools to use was carried out, based on the requirements with respect to memory- and CPU resource usage and realtime behaviour, to determine how feasible the introduction of MDD would be with respect to memory usage, performance and real-time requirements.

The positive outcome of this investigation was convincing. The idea that restrictions due to software development in ANSI-C could be surpassed, was clearly valid. The development team of the pilot project defined the following goals:

The Tools: UML as modelling language, modelling in IBM Rhapsody in C extended with the Realtime eXecution Framework (RXF) by Willert Software Tools (see infobox) made it possible to meet the specific technical requirements and use code generation for the limited memory- and CPU resources.

  1. Realistic project conditions: It should be possible to realise the project without extra time or manpower. The use of trainer and coach from Willert Software Tools helped to meet these conditions.
  2. Focus Quality Management: The effects of the use of MDD should be measurable and reproducible. The first project phase included training and coaching which assured a successful start and use of the tools. Next, well-defined training and coaching during development were the base for reaching planned schedule in time and costs plus quality and support the motivation within development team. The success of the first development proved the approach and selected tools to be the right choice.
  3. During the project the restrictions with respect to footprint and CPU resources formed the technical boundaries. The methods and know-how of modelling were extended within the development team which helped greatly. In close cooperation with the Willert trainers and coaches and multiple workshops, even in close to final project phases, further optimisation in model and RXF were realised. In this pilot project all requirements regarding memory- and CPU resource usage and realtime behaviour were met.
  4. In parallel the testing was tuned: unit tests, software in the loop and software integration were adapted to the modelling process and even automated. This was an extra effect which was not accounted for at forehand.

THE GAIN

First and most of all: a successful project and satisfied customer. At a functional level the project had realised what probably also could have been realised in the originally used development methods. But using MDD the road into the future with increasing demanding requirements is now open. Moreover, the quality aspect of the software engineering shows improved ease of maintenance, modifications and robustness. Apart from the functional result of this

pilot project, Marquardt now is capable of meeting steep requirements and specifically in reacting flexible on changes in requirements desired by the customer during the project. In addition, the steps needed in changing the development process and tasks within the team were mastered successfully. These changes were supported by the Willert trainer and coach. This resulted in a highly motivated team and guaranteed progress even in difficult times.

Most importantly is that the new know-how within the team and the investments in the new tools offer Marquardt a highly efficient and motivated team, ready for the future. This switch used by Marquardt in this project was acknowledged as an improvement of the software development.

THE FUTURE

Future projects will use the investments of this pilot project being the software tools, not-productive man-hours and consultancy, needed to introduce the new technology.

Traceability and maintenance of existing applications is much easier at the model level. The development process and applications therefore have become more defined and predictable. This will in its turn have positive impact on quality and time plus costs.

For the team members of the development team the switch to MDD means increasing competence and knowledge of modern software engineering.

The successful pilot project confirmed positively the decision taken to start using a new development environment and helped the customer in its success-story. This project proved Marquardt being an innovative company having a competent software development team which can coop with the ever-increasing demands of the automotive industry, ready for the future.

Inlay Marquardt Project

ABOUT MARQUARDT

Marquardt is an independent international and successful family owned company and leading manufacturer of electro-mechanic and electronic switches and -systems. Marquardt products are widely used by multiple car manufacturers. Marquardt also manufactures devices used in houses or for industrial appliances and is worldwide market leader in these areas.
http://www.marquardt.com

ABOUT WILLERT SOFTWARE TOOLS

The Willert Software Tools company specialises since 1992 in tools for Software Engineering with respect to realtime embedded systems. Willert has set its goal to offer technologies to enable customers to successfully develop software and support them in adapting the required tools. For this, Willert offers methods and tools plus training and coaching based on thorough knowledge of realtime embedded systems. Its customers include the automotive industry, aerospace, medical devices, public transport manufacturers, telecommunications, energy and infrastructural environment. Willert Software Tools has helped with numerous product specification, -development and Quality Assurance, for example vehicle control devices, coffee machines, frequency inverters, satellites, hearing instruments, door controls, fire alarms, röntgen devices, positioning systems and robotics.

What is the Rhapsody Tech BLOG?

January 1, 2017 / / 0 Comments

Basically what is says… It is my BLOG about Rhapsody. I will, however, not only write about technical stuff but describe my life with Rhapsody in the widest form possible. What can be anything like:

– Support cases that are interesting for all users (anonymized off course)

– Travel experience

– What do others do with Rhapsody?

And much, much more! Please respond if you like (or don’t like) something.

Newer posts »

© 2025 Rhapsody TechBlog

Theme by Anders Noren — Up ↑