Re: [mdt-ocl.dev] Pivot feature name spelling

[Adolfo Sanchez-Barbudo Herrera <adolfosbh@xxxxxxxxx>]

Hi Ed,

Interesting discussion. Please, correct me when appropriate.

In my opinion, I think that it's a matter of thinking about the 
roots/motivations of introducing such a Pivot metamodel and the Eclipse 
OCL project goals.

I agree that using singulars for multivalued properties is misguiding or 
less readable. On the other hand, it's a very common practice in OMG 
related specifications.

OCL is an OMG specification and Pivot metamodel comes from merging UML 
concepts and OCL ones and it was introduced to aim UML-OCL alignment.

So, introducing better names goes in somehow against that UML-OCL 
alignment and I think that it's not a point to be sorted out by the 
pivot metamodel. If there are better names, I don't think that it's a 
decision to be made by a particular OCL spec implementor. They should be 
corrected by UML and then by the Pivot. In other words, anticipating 
better names could probably go further pivot goals.

My point of view, is more OMG biased point of view and I also agree that 
it's a little bit controversial. In any case, I think that you  better 
have in mind the pros and cons of any deviation we could have from the 
spec, so simply take these comments as an additional point on the issue 
to think about.

Cheers,
Adolfo.
On 08/05/2013 10:12, Ed Willink wrote:
> Hi Adolfo
>
> The lack of UML alignment/incomplete auto-generation of the Pivot model
> is causing me more and more problems, so it is coming to the top of my
> list of things to think about (but not do till M1).
>
> *The easy problem.*
>
> e.g. NamedElement is realized by EMF as NamedElement and
> NamedElementImpl with EObject support.
>
> To support arbitrary models DomainNamedElement is manually implemented
> with 'the same' interface as NamedElement but without any of the EObject
> overheads. The extension of DomainNamedElement by NamedElement is a
> one-time manual edit.
>
> Auto-generation of DomainNamedElement is a relatively simple job for an
> Acceleo template.
>
> *The hard problem.*
>
> The manual edits of e.g. DomainNamedElement have introduced some
> different/better names. Usage of these different names causes type
> casting trouble for the CG. The differences must go, so what is better?
>
> Consider UML::Class::ownedAttribute.
>
> This is a singular name for a plural concept and so reads badly in OCL
> expressions. MDT/UML2's genmodel has an option to pluralize such names
> so that Java users get to call getOwnedAttributes(). [The singular only
> makes sense to XML readers; not an important community.]
>
> It is not an Attribute; UML 2.0 rationalized things as Property.
>
> "owned" is an implementation detail and in some contexts there is an
> implementation subtlety between "parameter" and "ownedParameter". So
> "owned" could be eliminated.
>
> giving OCL::Class::properties
>
> But sometimes the qualifying adjective is helpful. For instance, the
> opposite of ownedAttribute is Property::owningType, which is importantly
> distinct from Property::type.
>
> Requiring all names to have role adjectives would require Property::type
> to be renamed as selfType/elementType/myType/propertyType - all unpleasant.
>
> So perhaps better names are
>
> simple and pluralized for the primary use; type, properties
> qualified for secondary usages; owningType, referredProperty
>
> Also we need unambiguously scoped names
>
> Class::properties; all properties in this class and any classes merged
> into it
> Class::allProperties; all properties in this class and all its
> superclasses and any classes merged into them
> Class::localProperties; all properties in this class but not any classes
> merged into it
> Class::allLocalProperties; all properties in this class and all its
> superclasses but not any classes merged into them
>
> Class::superClasses; all immediate superclasses of this class and any
> classes merged into it
> Class::allProperSuperClasses; all superclasses of this class and any
> classes merged into it (excluding self)
> Class::allSuperClasses; all superclasses of this class and any classes
> merged into it (including self)
>
> *The hard decision.*
>
> I've been putting this off for too long and as a result there is a mix
> of UML and 'better' names.
>
> 1) As close to UML as possible
>
> e.g. Class::ownedAttribute
> + UML model comments can be reused by OCL specification auto-generation
> with minimal review
> + OCL reflection is familiar
>
> 2) A sensible minor rationalization of UML naming
>
> e.g. Class::properties
> + names can be pluralized
> + names can be more consistent
> + scoped names can be more consistent
> + UML naming is not imposed on implementers of the Domain interfaces
>
> The OCL specification has a couple of constraints that use reflection
> and UML names. These are currently illegal, so I don't see that the
> existing specifications restrict the design choice.
>
> Note that this only affects OCL/QVT users if they use reflection, so in
>
> umlObject.oclType().properties.type.allInstances().ownedAttribute
>
> oclType() goes reflective so that OCL::Class::properties is used to
> access the properties. Then allInstances() instantiates so that
> UML::Class::ownedAttribute is used to access properties in the user's
> UML model.
>
> This is a slightly perverse example, but highlights the question. Is it
> helpful for user's to be aware that reflection takes them into the
> tooling domain, or is it better to hide it?
>
> umlObject.oclType().ownedAttribute.type.allInstances().ownedAttribute
>
> leaves the user unaware that both OCL::Class::ownedAttribute and
> UML::Class::ownedAttribute are in use.
>
> I really can't decide between alignment and sensible. Do you have any
> strong views/insight?
>
>      Regards
>
>          Ed
>
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev