OK, so I've been using 7.5 for a while now. Lots of new features but I
don't know why they had to rearrange the menus. The real issue for me is
the fact that I can edit (RO) files and that is causing chaos in my
project. This release just hasn't been tested. I would advise people to
hold fire and wait for the MR1 version.

Luckily you can 'save as 7.4'.

Come on IBM, this is not good enough!

Anyone else used 7.5?

Hi Farquad,

i am also using the new version 7.5. I am just trying to check the new features out. Till now i am quite happy with the release because i have not found some new errors.
But i am a little afraid if it is really possible to edit read-only files that would make real problems here too. I will try it out also.

So thanks for your message

There are definite issues around components and configurations. For example you can change the scope in a component even when it's RO.

Well,
I'm currently upgrading to version 7.5 in a medium size project (6 developers, Linux Montavista, x86, gcc 3.4.6) and have run into some code generation problems resulting in compilation errors.
The problem appears for models containing qualified static associations (a static indexed map) where the 7.5 version insists to add a const after the accessor definitions i.e :
in the .h file:
static AFErrCodeEntryC* getItsAFErrCodeEntryC(ACE_UINT16 key) const;

in the .cpp file:
AFErrCodeEntryC* AFErrCodeTableC::getItsAFErrCodeEntryC(ACE_UINT16 key) const {
return itsAFErrCodeEntryC.getKey(key);
}

Are there any easy ways to prevent Rhap 7.5 from generating this const?

I've searched for all possible properties but cant find anything that is obvious....
Would it be best to upgrade to the lastest patch release emmediately?

Much greatful for any answers!

Yep, I came across that issue recently while reviewing someone's model. Definite bug. I reported it to support.

The bigger problem that I've come across in 7.5 is this new feature that tries to help you when you delete stuff that affects (RO) parts of the model. The feature is flawed as it appears to rely on the name string. Of course there are lots of matching names in a model that don't necessarily refer to the same model artefact. This is a bad one. Some crazy stuff happens and surpisingly it's not fixed in mr1.

I have yet to raise a problem report as I assumed the mr1 would fix it. I will raise one.

I am going to the IBM User Conference in a couple of weeks so I will quiz them about it then.

I see...
From my previous experience of code generation tools (including Rhapsody, Rational Rose Real-time/ObjecTime and some other custom built tools within the telecom-market) it should be pretty straight forward to perform full coverage regression tests before releasing a tool like this to the customer. ObjecTime already understood this in the mid 90:s when they used a conformance model, including all possible modelling artefacts/modelling language construction, as a regression test bench for the code generator. This "conformance model" was also a part of the new relase of the modelling tool (or could be handed out to the customer at request) in cases where customers decided to add new adaptations of the tool or simply port the code generator for in-house developed RTOS/HW-platforms.
Does anybody knows anything about the existance of a conformance model like this for Rhapsody?

In the late 90:s Rational incorporated ObjecTime and finally IBM incorporated Rational who now also owns the Rhapsody suit and I really cant understand what has happened with the release control that used to work so well 15 year s ago.

When I hear about these other dreadful problems that you mention Farquad (thank you BTW) I wonder how serious IBM/Rational really takes the Rhapsody product/customers?

I would be careful to generalise Rhapsody as a code generation tool. It is how most people with a software background approach it initially. Often they just want to use it to write the code they were already writing. There are loads of posts on this forum that suggest this.

If you use Rhapsody for a long period you will see how others use it. It's interesting to see how non-software people model and you may come to realise that Rhapsody is much more than what you initially thought. It is not a copy of any other individual tool rather it has the capabilities of many tools that were originally produced from a user perspective, some software gen, some not. For example Rose RT, Rose, TAU, Bridgepoint, Kennedy-Carter, Artisan etc have all fallen by the wayside because Rhapsody will give the rationalised mainstream benefits of all.

The upshot of this is that there are many user scenarios but ultimately a mainstream subset. If you discover issues that stop you in your tracks then the chances are that you're not mainstream. It's OK to not be mainstream as long as you are aware of what mainstream is. For example I see many complaints, not just on this forum, about Rhapsody not supporting templates well or not supporting smart pointers. It is hard to present an easily understandable example in words but, once modelled appropriately, the need to use smart pointers often disappears.

So, I would just like to say that, the problems I have mentioned are not 'dreadful'. IBM/Rational have no option other than to take their customers seriously because they have a very serious product. I'm well aware that many who are introduced to Rhapsody initially try and find reasons not to use it. Often these people are productive without it. To those people my comments will be added to their objection list. Ironically those people, if guided, become the most productive in Rhapsody and become champions of the tool.

If you can't understand why there isn't an open source equivalent of Rhapsody then you've just scratched the surface of its capabilities.

Are there any assembler coders under 50?

Ok,
I'm 41 myself (a half dinosaur but I will never become an assembler coder) and joined the OO modelling world a couple of years after my MSCS at a time when I was working in a consultant company that developed compilers and context languages (based on UML 1.01 or eq) for the telecom industry so I can tell you for sure that I've never ever considered Rhapsody as a ´pure code generator (btw my company was later incorporated by Rational ).
I was fluent in ROOM long before the UML standard was practical enough for adding code generation capabilities worth using for any tool manufactuar and if you study the ROOM concept in any of Bran Selics books (i.e. http://www.amazon.com/Real-Time-Object- ... 0471599174 ) you'll find find that some of the main concepts in UML2.xx has been around for quiet a while now (structures, links, ports by delegation, contracts etc etc).

I've been using the Rhapsody Developer C++ since 2003 (and worked with executable modelling since -97) for various projects and platforms in Germany, China and Sweden and find it to be extreme useful and I´m not critizing the concept it represents (as these are truly wonderful in a world still trying to reinvent the wheel every single time a new project begins).

There are some flaws in the code generator though and when you as a tool manufactuar release changes in the code generation part of a tool, then I think its fair that these changes should have been tested and any deviation at least have been documented in the release documentation (e.g.: do not use static maps in your model as these will cause the generated caude to fail compilation...).

Providing a conformance model would simplify this test both for the tool constructors and the customers....

Of course I agree that the flaws should be tested via a conformance model but I also think that the creation of that model is something we can all help with. Static maps are not that common. I certainly have never needed them and like yourself I've been using the Rhapsody Developer C++ for a long time, since 2000. I also worked for I-Logix for 3 years from 2004 so I've seen a lot of approaches to modeling. The problem is that many users don't send in error reports and front-end features are given high priority by the sales guys.

Managing a tool like Rhapsody is always going to be difficult for a company like IBM. I think we all know that. Rose RT was a great tool (in fact a trail-blazer) and I imagine you feel a bit let down by IBM for not being more proactive in the OMG and ensuring Rose-RT adapted to the agreed standard UML2. It would have been easy to do but not doing it made it easy for a tool like Rhapsody to pass it. IBM are not stupid. They understand what works. Rose-RT worked and so they bought it but when they realised Rhapsody worked better, they bought that. Obviously the market-place told them. The interesting thing is that many embedded developers have missed both technologies and some think that C++ templates are the Holy Grail. Data-driven design approaches are still in the majority out there but systems are getting bigger and people are starting to understand what SOA is so we will see a change.

The questions for me are what is likely to catch Rhapsody and when is that likely to happen? Does open-source have the answer? For example trac/SVN has left ClearQuest/ClearCase in its wake over the past year but IBM made its money for many years before that happened.

That is truly an interesting question!
Maybe http://staruml.sourceforge.net/en/ could develope to a competitor in the future (combined with http://www.cs.wustl.edu/~schmidt/ACE.html)?
We have been using TRAC/SVN in two of the projects (within defense) that I´m currently involved in and it has been working very well indeed and in small/mid-size projects this combination competes very well against the CQ/CC combination. CQ/CC has the edge though in large scale multi-site development projects with a more scalable development process defined (both tool chains requires a defined development process but maybe the IBM/Rational approach is more ready to run?) .

About holy grales: I dont ave any!
The first time I decided to use a static map was about 6 months ago when I had to designa model that needed to use a specific bus driver (widely used by avionic and military systems) which has a RTS of its own.
In short it is based on a call-back interface where you register an interrupt function which is executed within the same thread as the callee (which is within the driver RTS lib).
The call back function, triggered by a configured IRQ, reads tha messages in the last minor and should then write the messages that has been updated by the application model for the next minor, updates that has been made in another thread than the call-back executes in... So I decided to store these updates in a map which I then had to make static to avoid memory violation run time errors. The alternative would be to use shared memory but i found this as a less portable solution compared to using maps and I really like how easy it is to model maps in Rhapsody so ...

I agree that it's best not to have any Holy Grails but instead to understand as much as possible. At the same time it is important to understand the mindsets of the people who may have to maintain the systems we develop. C++ templates are perfect when they implement standard concepts like link lists and maps but often a standard concept agreed within a coherent team is less obvious to an outsider. All too often the standard concepts are only agreed by a single developer. Rhapsody integrates the standard concepts of list, vector and map and that's been sufficient for anything I've done. Occasionally I've thought, 'this is suitable for a template', but I've resisted. Interface based polymorphism is usually the best solution. I'm not suggesting a static map is inappropriate but it isn't common and therefore I can, just about, accept why it slipped through testing. We need to feed that back and I have.

On the subject of trac/svn, are you using Rhapsody? We use Tortoise Client and TamTam SVN SCC connects via a command line client called CollabNet to allow us to use Rhapsody via the SCC option. There is one issue with TamTam, it doesn't do a recursive fetch, and there is one issue with Rhapsody, it gets its RO/RW understanding out of sync when renaming items. Nevertheless there are workarounds for both issues and we are finding the integration very useful. trac is so configurable and easy to use.

Using interface polymporphism is the best way to go, I totally agree with you in this matter.
In my own model/design review work I've also seen several attempts to "templify" interfaces from self-spoken hardcore STL-gurus, and it has been difficult to make them adopt any other approach.
I'll make one more attempt to get around the problem with an interface class providing static accessor/mutator methods to the map instead...

Three years ago we tried out a commercial SCC-plugin together with Turtoise and Rhapsody (7.0 something) but as it didn't handle the syncronisation with the model elements very well, we stiopped using it.
Is TamTam whats working best with Rhapsody 7.5 right now?
Is there a document somewhere describing the workarounds you mentioned?

TamTam works OK. There's also PushOK that arguably works better in that it does a recursive fetch within the model. One of the key things that we had to do to make svn work well with Rhapsody was make sure that all .rpy, .sbs files etc were set to need lock. By default svn doesn't need the lock and sometimes when you check out into a sandbox the files can be RW. Rhapsody works best if files are RO until you check them out in Rhapsody. To set the appropriate flags when adding to the repository, just add these lines to your local svn config. (Also adds the Revision)

### Rhapsody files
*.sbs = svn:keywords=Revision;svn:needs-lock
*.rpy = svn:keywords=Revision;svn:needs-lock
*.omd = svn:keywords=Revision;svn:needs-lock
*.std = svn:keywords=Revision;svn:needs-lock
*.msc = svn:keywords=Revision;svn:needs-lock
*.cmp = svn:keywords=Revision;svn:needs-lock
*.ucd = svn:keywords=Revision;svn:needs-lock
*.cls = svn:keywords=Revision;svn:needs-lock
*.clb = svn:keywords=Revision;svn:needs-lock
*.ctd = svn:keywords=Revision;svn:needs-lock
*.dpd = svn:keywords=Revision;svn:needs-lock