|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781933 is a reply to message #1781913] |
Wed, 14 February 2018 18:40   |
|
Hi Vincent,
many thanks for that information.
BTW, an approach to achieve unique naming in constant time is to maintain an element count for each UML meta class directly or indirectly derived from NamedElement. If the counters are organized as (perfect) hash in a hash table the time to read out the counters has the time complexity O[1], constant time.
The price to pay is
1. memory overhead for the counters and the hash table
2. compute overhead to increase the associated counter on element create
3. compute overhead to decrease the associated counter on element delete
The create and delete operations shall be multi-threading proof, which implies further memory and compute overhead.
To minimize memory overhead I would suggest to use one counter structure per Papyrus model (to distunguish from the UML meta class Model "12.4.4 Model [Class]"). As Papyrus stores each Papyrus model as a single UML file this translates to one counter structure per UML file.
Best regards
Carsten
EDIT: refined description
[Updated on: Wed, 14 February 2018 19:29] Report message to a moderator |
|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781963 is a reply to message #1781933] |
Thu, 15 February 2018 10:48 |
 Camille Letavernier
Messages: 952
Registered: February 2011 |
Senior Member |
|
|
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
Camille Letavernier
|
|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781967 is a reply to message #1781963] |
Thu, 15 February 2018 11:35 |
|
Hi Camille,
> the name has to be unique within a namespace
If the name is unique within a model it is unique within any namespace within the model
> PackageImport/ElementImport
PackageImport / ElementImport are indirectly derived from NamedElement and as such covered in my approach. As a result the counters exist. An import of an Element (incl. Package) is simply to be handled like a create operation. An Element (incl. Package) can happen directly or indirectly via owners. Both shall be treated the same.
Nevertheless I did a mistake, the delete must not decrease the count. Imagine you have for example three classes named class_1, class_2 and class_3. Consequently the class counter will be 3. Then you delete class_2. The class counter will be 2 after, if delete will decrease the counters. If you create a new class it will be named class_3. But class_3 is existing. Omitting the decease on delete it would be named class_4. Which is unique.
> Also, elements may be serialized in sub-resources (fragments)
You are right fragments (17.6 Fragments) are no UML meta classes. Nevertheless fragments could be handled the same as UML meta classes directly or indirectly derived from NamedElement.
What else is missing?
/pica
PS
> The default strategies are only useful for building a quick toy/demo/test model, where the performances don't matter anyway.
I work in domains that break IBM Rational Rhapsody ;-)
[Updated on: Thu, 15 February 2018 11:38] Report message to a moderator |
|
|
| Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781973 is a reply to message #1781967] |
Thu, 15 February 2018 12:09 |
Camille Letavernier
Messages: 952
Registered: February 2011 |
Senior Member |
|
|
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
Camille Letavernier
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03525 seconds
] 
Search
Help
Register
Login
Home
