No notational indication for generalization scope?

[g.makulik]

From the  UML superstructure 2.2 [edit](7.3.55 VisibilityKind (from Kernel))[/edit]

• A protected element is visible to elements that have a generalization relationship to the namespace that owns it.

This concept isn't really supported in C++, IMHO. There's no visibility (scope) specifier attribute on level of a classes declaration. There's a weak visibility relation to the namespace owning the class, yes. But it doesn't hide anything from the public, just from other namespaces default scope. In C# (and I think in Java too), you can specify a classifiers visibility, but you can't specify visibility of the superclasses and interfaces you inherit.

In the same chapter UML 2.2. Superstructure also says:

Notation
The following visual presentation options are available for representing VisibilityKind enumeration literal values:

• ‘+’ public
• ‘-’ private
• ‘#’ protected
• ‘~’ package

But this isn't supported by EA as far I've seen (I guess this decoration should optionally prefix the element's name, right?).

About the 'has a'/'is a', 'composition' vs. 'inheritance' discussion:
Citing from the C++ light FAQ as a good, reliable and recommendable source, section 24.3 ... A legitimate, long-term use for private inheritance ..., better describes my designs situation. I'm pretty sure I wanna have an 'is a' here: I want to realize an interface, since I can't hide the interface itself in C++, as I would do in C# for example, I'm factoring out the implementation to another class, and replace the implementation by protected or private inheritance.
I mentioned that I was starting with a <<friend>> dependency, where the buddy class needed access to some of a classes protected/private operations. In fact, the buddy classes are the facades and I want to urge clients to use these instead of certain (hidden) interfaces.
Compared vs. composition, the inheritance may also have impact on the efficiency of the implementation. Using the CRTP (aka. static polymorphism) to realize the interface, you may end up with zero cost for footprint (data & code!) or performance (I'm working with embedded devices, you know).

I can live with the constraint. May be it's making it even more clear for the already cited average common-or-garden developer, than yet another subtle UML notational decoration (YASUND ?? ;D).

WBR & thanks for the vivid discussion so far,

Günther

[Geert Bellekens]

Günther,

It's not because it isn't directly supported by the programming language you target that you should not model the concepts in a UML way.

The way I see it is that you can model the fact that you don't want an exterior class to use some methods defined on one of your interfaces using the "package" visibilityKind.

The implementation in C++ might then require the concept of private inheritance.

I always try not to see the model as a 1:1 translation of the code.

Geert

[Makulik]

Hi Geert,

I always try not to see the model as a 1:1 translation of the code.

I totally agree with this, despite I sometimes have to ensure that code generation from the model does exactly what I want (there will be language specifics that appear in the model then, e.g. distinguishing between a types value, reference and pointer).

My point was, that I'm missing how to make this visible in a diagram, when it makes up a notable issue for the design. As far I see, even with the 'visibilityKind' attribute set on the element level, at least EA doesn't give you a visual clue. Dunno, may be other UML case tools will do.

WBR
Günther

[Geert Bellekens]

Günther,

If I make an operation "package" visible then it shows the tilde "~" sign before the operation as it should.

You are on the latest version aren't you?

Geert

[g.makulik]

Yes I am on the latest version. I was talking of using the classes or interfaces 'visibilityKind', this one's not visualized in EA (isn't the UML superstructure spec referring to 'Classifier' at 7.3.55?).

I'll check what C++ code generation will do, when placing it on operations ...

THX for the hint,

Günther