|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781963 is a reply to message #1781933] |
Thu, 15 February 2018 05:48   |
Eclipse User |
|
|
|
Hi Carsten,
UML name uniqueness is slightly more complex than that: the name has to be unique within a namespace, which includes anything referenced via a PackageImport or ElementImport element. Also, elements may be serialized in sub-resources (fragments), while still belonging to the same namespace.
But more generally, the logic behind this is: element name is optional (Several unnamed elements may exist within the same namespace); and if name is meaningful, then the user will probably specify it anyway. So in most cases, there is no need for expensive and/or complex default naming algorithms. The default strategies are only useful for building a quick toy/demo/test model, where the performances don't matter anyway.
Cheers,
Camille
|
|
|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781973 is a reply to message #1781967] |
Thu, 15 February 2018 07:09 |
| Eclipse User |
|
|
|
Hi,
Quote:PackageImport / ElementImport are indirectly derived from NamedElement and as such covered in my approach.
Hmm, that's true for QualifiedNames, but not correct from a Namespace point of view. When validating the model, what we want is unique names within the Namespace. When you import elements in a Namespace via Element/Package Import, it is not the name of the Element/PackageImport that matters, but the name of the imported element(s).
So if Package1 contains a Class1, and imports Package2::Class1 via an ElementImport, Class1 is no longer a unique name within the Package1 namespace. However (And I didn't know that while writing my previous message), UML specifies that in that case, the imported element takes priority over the local one and that this isn't an issue (The model is still valid).
The general rules for name uniqueness (More precisely, "Distinguishability") are described in 7.4.3 (.1 -> .3), but this section also indicates that more specific rules may exist for some elements (With only one example: Operations are distinguished by signature). So if you wish to make sure all rules are taken into account, I'm afraid the only solution would be to (re)read the entire spec :) (Or take a shortcut and look at the validation rule(s) for distinguishability in Eclipse/UML2, assuming it is correct and complete)
Quote:You are right fragments (17.6 Fragments) are no UML meta classes
By fragment, I meant "sub-resources", i.e. when a single UML Model is split in several smaller files during serialization. So the contents of a single namespace (e.g. Package) may be split over several files/sub-resources. So, having one index strategy per file/resource wouldn't work in that case.
Anyway, the point of my message was simply to clarify what the intention was, i.e. improve performances and reduce the risk for invalid UML Models. But unless we take all the rules regarding distinguishability into account, it's unlikely that we can provide a 100% reliable algorithm for default naming. But that's, IMO, not required anyway.
Cheers,
Camille
|
|
|
|
|
|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781993 is a reply to message #1781988] |
Thu, 15 February 2018 09:41 |
| Eclipse User |
|
|
|
Hi
I meant Namespace::getNamesOfMember.
It looks like we have an interesting UML contradiction. I am informed that UML aspires to only null-free collections but Namespace::getNamesOfMember collects the null names regardless. OCL supports null in Collections so the UML body is broken wrt UML aspirational semantics.
As I wrote. "UML distinguishability rules are suspect".
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.07606 seconds
Home