How (where?) to model 'global' functions

[sl@sh]

Ok, got the namespace templates and they seem to work. Unfortunately one way only - so I would need to redefine the already existing operators within the model

After looking into existing templates I wonder however if I shouldn't put some work into the "package" operation and attribute scope - it could be used to move operations and attributes outside an actual class! Not sure how this would work on import though. I have the distinct feeling that these, as well, would fail to import :/

Another approach would be to define a new stereotype 'namespace' and then modify the existing class templates to treat 'namespace' in a similar way as it does 'union' or 'struct'. I got the impression that doing it this way maybe there is a chance EA could actually import a namespace and it's members. Or would it?

[sl@sh]

Solution!

I know I already posted three times in a row, but since I finally found a way to solve my problem in a most satisfactory and elegant way I thought this would be worth an extra post!

What I did is this (I started doing it in my editor, but since the code can be imported and (re-)generated again you could just as well design it in EA, so I'll add the appropriate steps to perform right within EA):
1. Define a class 'MyGlobals' within a seperate header file. (Or define a new class object 'MyGlobals' on your class diagram in EA)
2. Add dependencies (#include statements) to all the classes that your global operators or method need to work on (add the classes that your operators or methods work on to the class diagram and create dependencies from 'MyGlobals' to these classes)
3. Add operators or methods to your class and add the 'friend' qualifier to each of them! (define your operators and methods within 'MyGlobals' and set the stereotype of each operation to 'friend')
4. Import your newly created header to an EA class diagram (use the 'Generate Code' function on 'MyGlobals' to create the source files)

That's all!

The fact that the operators are defined inside an actual class means they're parsed and generated just fine*. Because they're declared 'friend' they don't technically belong into the scope of the new class, 'MyGlobal' - instead they are considered global scope! This means any class #including 'MyGobals.h' can freely use the operators declared therein.

Also, from an UML-modeler's point of view, I now have an actual object which represents the scope that my operand classes interact within.

*: there's one catch: when you define a friend function's behaviour and then generate it, the function is being generated with the scope tag associated (e. g. MyGlobals:: operator *(/*...*/) ). This means after initial generation of the implementation the scope tags need to be manually removed. This however means the next time you synchronise the model, the initial code section will be cleared! So no easy refactoring. :/

[Eve]

To stop EA from clearing your initial code uncheck Tools | Options | Source Code Engineering | Attribute/Operations | Include method bodies in model when reverse engineering.