Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: g.makulik on December 11, 2009, 11:06:47 am
-
Hi,
Is it really fact, that UML 2.2 doesn't specify a notational indication for generalization associations' scope?
Did anyone here come over the same problem? I've noticed that EA supports the specification of the scope in the generalization properties dialogue.
Currently I'm indicating this with a note in my diagrams :-(. It makes sometimes an important point in some of the C++ class designs I have created.
Günther
-
From memory it's worse than that. UML has no no concept of it at all. EA adds it for C++.
-
Günther,
Could you please explain what exactly you mean by generalization associations' scope
because I'm a bit like UML on this, I have no idea what you are talking about :-/
Geert
-
Thank you Geert, I was too embarrassed to ask. :-/
b
-
Hi Bruce & Geert,
Sorry, I'm afraid to be often too close to my programming language slang. With 'scope' I meant the visibility of the generalization's target end (i.e. the base class). There's a notational indication (+,#,- as usual) in the UML specification of other associations ends, but none for generalizations. I think most (OO) programming languages support to specify it, at least C++ does. In the mentioned designs, I had good reasons not to specify this on the base classes operations level, but to hide the whole base class from (direct) public access.
WBR
Günther
-
So if I understood making a generalization private would be the equivalent of a regular generalization, and then overwriting all operation, making them private and calling the parent operation?
No I don't remember anything like that in the UML specs either.
Besides, are you sure this is a good idea?
What happens when I have a variable of type "Superclass" and it happens to be filled with an object of type "Subclass"? Am I now not allowed to call any of the operations on my variable anymore since they've been made private by the "Subclass"?
Geert
-
So if I understood making a generalization private would be the equivalent of a regular generalization, and then overwriting all operation, making them private and calling the parent operation?
That is how it looks from outside, yes. But there are subtle differences.
Besides, are you sure this is a good idea?
What happens when I have a variable of type "Superclass" and it happens to be filled with an object of type "Subclass"? Am I now not allowed to call any of the operations on my variable anymore since they've been made private by the "Subclass"?
In my special cases I want to achieve exactly this. It's about how to design interfaces, that are solely internally visible. In fact a (public) client will not be able to have a variable of type superclass filled in. An internal client may receive a 'variable' (or better an interface ref) from the subclasses though.
We had a recent discussion about the deprecated <<friend>> dependency stereotype here. That's the way how I factored out such <<friend>> dependencies from internal clients.
When you design frameworks this is a pretty useful pattern, to make your APIs 'idiot proof' ;). You can prevent your clients from using interfaces, they shouldn't use (directly), already at compile time.
WBR
Günther
[edit]PS.:
1. Actually I'm using an <<invariant>> constraint with the value 'protected' on the generalization, instead of a note.
2. I've investigated further, and see that it seems to be a more C++ related concept. At least C# and Java don't support it that way, these have a concept for module internally visible classes though AFAIK.
[/edit]
-
Look at http://www.parashift.com/c++-faq-lite/private-inheritance.html for a how/why to do this in C++.
-
Look at http://www.parashift.com/c++-faq-lite/private-inheritance.html for a how/why to do this in C++.
Well, it DIDN'T get off to a good start...
private inheritance is a syntactic variant of composition (AKA aggregation and/or has-a).
NO IT'S NOT...
I'm not saying Public/Private Inheritance isn't a viable thing... It just NOT Composition!
People often ask me why I use such long/uncommon words like meronymy - the relationship between the part and the whole. It's because they are the right words...
"The reasons we can't build systems that work is that we can't unambiguously describe what we want to each other" [size=8]Jean Raymond Abrial (1970).[/size] Still true today...
If we think Inheritance is Composition, no wonder our systems don't work...
Paolo
-
It may not be strictly composition, but it is a useful analogy. In terms of modelling, the relationships between classes it would probably be more accurate to model it as composition than inheritance.
Do you have a better word for it? (One that that average C++ developer would understand.)
-
It may not be strictly composition, but it is a useful analogy. In terms of modelling, the relationships between classes it would probably be more accurate to model it as composition than inheritance.
Simon,
That's exactly my point... It's NOT inheritance, it's composition. The problem comes about because most programming languages' syntax is insufficient to express the concepts you're trying to model. You yourself, I think, recently pointed out that when reverse engineering new code, the model can't determine if an association is a simple association or a meronymy without additional information. That's because the language syntax doesn't distinguish between them.
In this case, under some circumstances, using the wrong syntax will appear to create the right result. But if you've created the wrong model in the first place, it really doesn't help.
Do you have a better word for it? (One that that average C++ developer would understand.)
Since they're two separate concepts, there isn't a better word. As I said before, I'm NOT arguing against scoping inheritance, I'm saying the example doesn't illustrate it - because a car ISN'T an engine (not notwithstanding dragsters... ;))
Paolo
-
I've gotta agree with the pope again here. A car isn't a type-of engine, no matter which way you put it. AND, yes we are talking about the example, not the concept.
However, getting back to the OP. I'm still not convinced that what I perceive as the goal cannot be achieved using a facade pattern. I really cant see the necessity(?) to confound the compiler when an exposed interface can be determined by a (or some) facade classes that will protect internals at very little expense. I do understand what Cline is saying but it really stinks of making the model comply with the language constraints, or in this case the language features.
AFAIC the jury is still out.
bruce
-
Can't we achieve the same goal with the package visibilityKind?
If the superClass and its methods have package visibility, and the subclass is public, that would mean that classes from outside the package would be able to see the subclass and its public features, but not the superClass and its methods.
In the example of a framework design that would be exactly what you intended with the scoping of the generalization.
It looks like that is the UML way of modelling a situation like that.
Geert
-
Geert,
Yes and no. Package, aka "protected" is in the main still language dependent. If, you really want to expose a specific set of aspects and really want to not expose a specific set of the internal workings of the component, then IME facades are the "best" way to go.
I mean, the damn things are usually so easy to specify. All internals are "package private" and those things that we wish to expose can be just, well, exposed. A bit like a 16yo in a shopping mall I guess, ya know that the scanty packaging is just a tease but any trying to open the package is "ILLEGAL".
(I'm probably going to get shot for that :-X )
bruce
-
Package, aka "protected"
Whoa bruce, you've missed the ball there completely I think.
Package and Protected are two concepts defined in UML that have a really different meaning.
From the UML superstructure 2.2
- A protected element is visible to elements that have a generalization relationship to the namespace that owns it.
- A package element is owned by a namespace that is not a package, and is visible to elements that are in the same
package as its owning namespace. Only named elements that are not owned by packages can be marked as having
package visibility. Any element marked as having package visibility is visible to all elements within the nearest
enclosing package (given that other owning elements have proper visibility). Outside the nearest enclosing package, an
element marked as having package visibility is not visible.[/list]
Having read this I must admit that missed the ball a bit as well, because you can't make the superClass package visible if it is owned by a package. (I really don't understand why they've added this restriction. Anyone know?)
You could make the operations package visible though, which would have the same effect.
Geert
-
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 ... (http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3), 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
-
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
-
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
-
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
-
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