As an ArgoUML contributor I'm going to blog my activities here, so that they may draw interest by other developers or help other developers when doing tasks similar to what I've done. AND(!) the grand vision that makes an Argonaut what he is, TO THRIVE IN THE BIG DANGEROUS WORLD, TAKING THE Argo TO A GOOD SHORE ;-))

Monday, January 23, 2006

The C++ UML profile

The problem above was included in issue #3829 and I already provided patches and tests for this to Tom Morris (the developer to whom the issue is assigned). – Well, there is an exception which is Parameter model elements, that I'll try to fix in the context of 3829. I also think that we have other problems related to namespace, ownership and undocumented behavior of my proposed solution...

With this in place I am already capable of using tag definitions owned by stereotypes in the C++ UML profile in the model elements to which the stereotypes are applied. This should satisfy issue #3771 and the planned objective for C++ reveng, but, it falls short in the context to my previous ambitions: 2005-08-16 andModel C++ in UML according to guidelines accepted in common by the community. I also think that we are buying lots of manual synchronization work to be done in the near future, which should be avoided!!! Currently we have the readme file in the C++ module source, the ArgoUML manual and the source code. With issue #3771 I'm adding the UML profile for C++ which is an additional place where these things go into. So, this means that whenever something changes I have to update four places – to be more correct its more than four since the source code for generator and reveng should be counted as two at least.

Another thing that worries me is the fact that we could be moving into a island and a not invented here syndrome. The UML profile for C++ should be something developed outside of the ArgoUML umbrella, so that it is shared with other communities, creating more reuse opportunities and improving reviews. After finding that there is no effort in the world going into this direction, I will not start with this before having other things like 1446 ready, but, it is indeed important for the overall vision realization... A possible way to start with this is to make it a kickoff step in adding support to C++ to one of the existing open source MDA tools.


  • I must update the C++ reveng code to use the profile. The C++ reveng plan also needs an update.
  • The C++ module documentation must be updated to include this notion of using the UML profile for C++.
  • Make a review of non-working tags in the C++ generator, create an issue to handle this and coordinate things with Daniele.

Monday, January 09, 2006


I'm working on issue #3771: Add tag definitions for tags used by the cpp generator. The way to go for solving this is by defining a C++ profile that could be imported automatically by projects for which C++ code generation is intended. This C++ UML profile will be stored within the module jar and support for importing it will be added to the C++ module preferences dialog.

Now, there are some problems with ArgoUML support of tag definitions (TDs). It is not possible define the tagType of a tag definition. This is relevant for the C++ UML profile, where I want to restrict to Boolean the range of values accepted by some tag definitions.

Another problem I'm having is that if I define tag definitions associated with a stereotype (their owner), these don't show as options to be applied to model elements that have the stereotype. Lets say cppClass stereotype has TDs constructor, header_incl and source_incl. When I create a class and apply the cppClass stereotype to it, the tagged values defined in cppClass aren't available to be applied to the class. Well, this takes the value out of associating the TDs to stereotypes, but, this is also an obvious bug that I may easily fix...

To enable users not to polute their models with stereotypes, the C++ UML Profile will have TDs both nicely associated with stereotypes and at top level. This might cause problems when I fix the error I identified above, but, we should try to please the users. It is no problem if the stereotypes aren't applied to model elements, since this way only the tag definitions defined at top level are available. When the user applies the stereotypes he will get one defined at model level and the ones that come from the stereotype. We could define here some type of rule, so that ArgoUML filters the top level values...

Reader Shared items