ArgoUML C++ – generator and modeling

The C++ code generator in the ArgoUML C++ module has been growing in its usage of Taggedvalues and it hasn't grown more because it hasn't received recent contributions. In a recent thread in the Using ArgoUML for modeling C++ topic of the ArgoUML's users forum, this started to become more clear for me. Here is my answer to Ulrich Thombansen's on the 24th of June:

Hi Ulrich,

> (...) on the “constructor”. What about taking this off the documentation at tigris?

I consider that the best solution. Given two ways to make something, I would go for the standard UML way, which even if taking a bit more of work by the user, it is more flexible because you have an actual operation that might be customized, e.g., by adding arguments. By being explicit we may in the future enable specific customization related to C++ constructor specificity.

Note to self: TODO: place this conclusion in the issue 21. Consider the possibility of some TagDefinitions in the «cppOperation» Stereotype being only applicable if the Operation to which the Stereotype is applied also has the «create» Stereotype applied.

> cppAttribute
> ==========
> applying «cppAttribute» to a variable “myAttrib” with the tag “pointer” set to different values leads to the following results:
> no) tag value -> result
> ----------------------------
> 1) “false” -> int myAttrib; /*{pointer=false}*/
> 2a) “true” -> int *myAttrib; /*{pointer=true}*/
> 2b) “xyz” -> int *myAttib; /*{pointer=xyz}*/
> 3) “” -> int *myAttib;
>
> Feature or fault?

IMO feature (I would call it a default behavior due to a present limitation in ArgoUML) and a nicely chosen one, although in the future when ArgoUML supports typed TaggedValues, I would model the “pointer” TagDefinition as a UML Boolean and therefore you would only have True or False. The rational behind letting the user model any “pointer” TaggedValue as being true but the actual String “false” is that if the user added the “pointer” TaggedValue in an Attribute, it is because he want the pointer to be present.

> cppAttribute
> ===========
> applying «cppAttribute» to a variable “myAttrib” with the tag “get” set to public leads to the implementation of the int get_myAttrib(); function.
>
> Is there a way to make this “virtual”? GeneratorCpp.java only creates “virtual” for (!leaf && !isConstructor && !static)||abstract. Which rule applies / can be influenced?

This is one of the reasons I dislike TaggedValues being used where the default UML suffices. By adding the “get” or “set” TaggedValues to represent an hint for the generator you put yourself in a position where you step out of the proper language for representation of the Operations. If there was a button for generating get and set operations for a given attribute at the model level you would have afterward the liberty to customize it as for any other operation. Since ArgoUML doesn't have this, we added “get” and “set” TagDefinitions to the «cppAttribute» Stereotype, but, given that these are simply TaggedValues we will be left with the modeling of all the particularities of operations as different values of the “get” and “set” TaggedValues. It isn't a fair deal. The overload isn't only for the implementation, but, also for the users...

I would model it the other way around, having a “get” and “set” TagDefinitions applicable to Operations to which the «cppOperation» is added and the values would have to match the name of the attribute which the operations are related to. A more powerful way would be an association between the Operations and the Attributes, but, I don't know if UML allows that, and I'm almost certain that ArgoUML doesn't.

One of the issues with all this is trying to guarantee symmetry between code generation and reverse engineering. Although it is a bit like utopia, we might be closer to it if we stick as much as possible within the UML proper when possible.

Note to self: TODO: create an issue of type enhancement proposing the deprecation of get and set TagDefinitions in «cppAttribute» and adding the these TagDefinitions to «cppOperation». Model it initially as a String that must match the corresponding Attribute name and afterward as an Association (if and when this is supported).