Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » [Informative Message] Default naming strategies changes for Papyrus Oxygen.3
[Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781913] Wed, 14 February 2018 15:35 Go to next message
vincent lorenzo is currently offline vincent lorenzoFriend
Messages: 95
Registered: June 2010
Location: Paris Saclay, France
Member
Hello everybody,
this is an informative message. The calculus of the default name in Papyrus changed.

I pushed yesterday changes concerning the naming strategies (Photon and Oxygen). Now, 3 behaviors are available:
- quick index (no necessary unique) -> the new default strategy used in Papyrus (constant time execution)
- unique index (the previous behavior) (depends of the number of element in the owner)
- no index


The associated bug is this one : https://bugs.eclipse.org/bugs/show_bug.cgi?id=530155
The patch for Photon is here : https://git.eclipse.org/r/#/c/115844/
- it includes an update of the Junit tests when required
- the updated documentation
- a new preference page to configure the new behavior
- the patch itself


A video illustrating the changes is available on youtube:https://youtu.be/eeLGQPnMAyM.

This changes allows to increase the performance of the element's creation in Papyrus.


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 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 137
Registered: May 2015
Location: Germany
Senior Member
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 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 887
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 Go to previous messageGo to next message
Carsten Pitz is currently offline Carsten PitzFriend
Messages: 137
Registered: May 2015
Location: Germany
Senior Member
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 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 887
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
Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781980 is a reply to message #1781973] Thu, 15 February 2018 12:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

UML distinguishability rules are suspect for Constraint where it is common to have many unnamed constraints.

A simple element count doesn't work unless you do a total analysis of the input model where a previous manually named class might be "Class57" just waiting to clash with the 57th auto-generated class. No autogenerator can be sound without an old element collision detector. (ok in practice a UUID based allocator is sound enough.).

Considering the subtleties of ElementImport and PackageImport is not that useful, since just because you pedantically detect that a new "Class5" does not clash with an existing "Class5" you are ensuring that you will create an unpleasant debugging problem and a very confused user.

Just ensure that all new names are trivially distinctive.

In my code I maintain a per-name-allocation-space name-to-element map for all existing elements so that after using a heuristic (e.g. class plus count) to come up with a name hint, the name hint can be suffixed with a count until a non-collision is discovered. This is constant time provided the initial hint is not something incredibly stupid like "Name" for every possible named element.

Regards

Ed Willink
Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781981 is a reply to message #1781980] Thu, 15 February 2018 12:37 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 887
Registered: February 2011
Senior Member
Hi Ed,

Quote:
UML distinguishability rules are suspect for Constraint where it is common to have many unnamed constraints.


I believe UML specifies that unnamed elements are not expected to be distinguishable. The general rule is rather: "If the element has a name, then it should be unique" (With further consideration about what "unique" means)

Regards,
Camille


Camille Letavernier
Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781983 is a reply to message #1781981] Thu, 15 February 2018 13:18 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

Ignoring null-names could make sense but I see no sign of such blindness in the OCL bodies of getMembersForName or isDistinguishableFrom

Regards

Ed Willink
Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781988 is a reply to message #1781983] Thu, 15 February 2018 13:59 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 887
Registered: February 2011
Senior Member
Hi,

For isDistinguishableFrom:

Quote:
isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean
The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a
Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a
kind of the other or (b) they have different names.
body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies
ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty()


So an intersection with an empty set (Unnamed element) is necessarily empty, thus the member is always distinguishable

I don't see any "getMembersForName" operation in the UML Spec

Regards,
Camille


Camille Letavernier
Re: [Informative Message] Default naming strategies changes for Papyrus Oxygen.3 [message #1781993 is a reply to message #1781988] Thu, 15 February 2018 14:41 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
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
Previous Topic:SynchMessage from Sequence diagram does not appear in the class diagramm
Next Topic:New Papyrus Model Wizard Issue
Goto Forum:
  


Current Time: Mon Nov 19 08:53:57 GMT 2018

Powered by FUDForum. Page generated in 0.02678 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top