What is your review process for Rhapsody development?

Question

My team is using the IBM's Rhapsody tool to do real-time embedded development. Unfortunately, we are unhappy with our current review process.

More specifically, we've had difficulty because:

• there is a lack of a good diff tool for diagram changes
• the Rhapsody diff tool doesn't generate reports that you can use in a review
• source file history is spotty because source files are products in MDD thus not configured in a VCS at a high granularity
• running diffs on source code sometimes pulls in unrelated changes made by other devs
• sometimes changing a property of a model element changes dozens of source files
• it's easy to change a source file through a property change and not know it

Does anyone have any tips for making peer reviews on Rhapsody development robust but low-hassle? Any best practices and lessons learned you would like to share? I'm not looking for a mature process write-up; tidbits I didn't know about would be great.

Cerys

Answer 1

We use Rhapsody for the same purpose at my workplace. Reviews of model changes are done with a script that opens diffmerge on two copies of our repository (one at the start of the changes, one at the latest). That shows all of the pertinent changes, without any of the internal cruft Rhapsody adds.

Our repo doesn't track the generated sources, but we see plenty of irrelevant changes in Rhapsody's sbs files frequently. We've started setting sbs files as read-only on the filesystem, and then changing them to read/write from the properties panel in Rhapsody. That doesn't stop the files you mark as read/write from having cruft inserted, but it prevents unrelated files from being modified.

I still haven't found a way to make Rhapsody stop inserting irrelevant changes (for example: it sometimes adds and removes filename fields between saves, despite minimal changes to the model). It creates a lot of merge conflicts, and I've personally started taking 5 or so minutes per commit to only add the changes that matter.

Muskmelon

Answer 2

It is also possible to prevent Rhapsody from writing timestamps to the sbs files by setting the property CG::General::IncrementalCodeGenAcrossSession to false. This can help reduce the amount of unnecessary data.

See this link

Niles

Answer 3

We have been using Rhapsody for development for the past 5 years. Our current process involves using the Rhapsody COM interface and the Microsoft Word COM interface to dump review packages to Word for design reviews. We also do this to generate the reference manual portion of our SUM.

For code we review the generated source.

We put the model into our version control system, and lock down model elements after they have been reviewed. If your version control tool makes things read only when they are checked in, it prevents you from accidentally changing a model element.

The COM interface is also good for dumping the model to make PowerPoint slides of diagrams if you want to present your design to a customer. You will have to tweak the slides after they are generated, as the pictures usually end up looking a little funny, but it gives a quick starting point.

Madelle

How do you lock down model elements, especially considering that properties for elements are frequently inherited from other elements? What about changes (maybe for a bug fix) to design and code? Do you regenerate and review the whole kit and caboodle every time? – Cerys

Our SCM locks down the items. We use Serena Dimensions which lets us put things to an approval state, which you then need a change document to check the item out again. Then we review all of the diffs of items attached to a change document. Diffing the new word doc, or the code, depending which changed. You do have to be careful of changing top level properties, but once we setup our model we rarely modify the top level defaults. – Madelle