Home » Modeling » Papyrus » OCL - allInstances() on Stereotype
|
| Re: OCL - allInstances() on Stereotype [message #1719035 is a reply to message #1718919] |
Mon, 04 January 2016 15:40   |
 Klaas Gadeyne
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
Hi Kristof,
It seems you've hit a bug somewhere. IIRC, the (non-standard?) syntax I used in luna was st. like this (notice the double colon instead of the dot),
Train::allInstances()->one(t | t.name = self.name)}
but at least in the quick try I performed this syntax is now refused by the parser, although I'm unable to find anything in the Changelog mentioning this.
I also found this old forum post mentioning the use of the oclType() operation before the allInstances() operation, but that doesn't seem to help either (ie. the size of the resulting allInstances() Set remains zero as you describe).
I think the best way to proceed in this case seems to create a small demo project, and file a bug to the MDT/OCL bug tracker for this issue (unless EdW get's here first  )
(note: related bug? )
As a work-around, as Ed Mentions in the above post, a reformulation of your constraint as part of another ("containing") stereotype might avoid your usage of allInstances(). And as a side note, you probably want to use the isUnique(name) construct...
HTH,
Klaas
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719158 is a reply to message #1719035] |
Tue, 05 January 2016 16:55 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Once again I replied off-list by mistake.
Since it was fixed for Classic OCL it should work in Pivot OCL.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485225
-----
Unfortunately the OCL specification is incredibly thin when it comes to
advanced UML concepts so we have the three usual answers:
a) As a pedantic specification expert. There is nothing to say it should
work, so it doesn't.
b) As an overworked developer. I don't need more problems; no bug.
Nothing to do.
c) As an enthusiatic user. I have an overlooked use case. Let's think it
through...
In UML, a Stereotype is a Class but it has no instances, rather its
'instances' extend the stereotyped Class instance.
MyStereotype.allInstances() would therefore be a language extension.
The usage of UML by OCL is underspecified.
In the Pivot OCL, which prototypes a resolution to the UML to OCL
loading issues, an ElementExtension reifies the Stereotype instance and
anElement.extensions identifies all extensions, so you could perhaps do
Element.allInstances().extensions->selectByKind(MyStereotype).
Since a Stereotype should never be instantiated in its own right, it
seems reasonable that MyStereotype.allInstances() is just a shortform of
the above.
OMG issue raised: http://issues.omg.org/browse/OCL25-205
Regards
Ed Willink
On 04/01/2016 15:40, Klaas Gadeyne wrote:
> Hi Kristof,
>
> It seems you've hit a bug somewhere. IIRC, the (non-standard?) syntax
> I used in luna was st. like this (notice the double colon instead of
> the dot),
>
> Train::allInstances()->one(t | t.name = self.name)}
>
>
> but at least in the quick try I performed this syntax is now refused
> by the parser, although I'm unable to find anything in the Changelog
> mentioning this.
>
> I also found
> https://www.eclipse.org/forums/index.php?t=msg&th=321399&goto=834826&#msg_834826
> mentioning the use of the oclType() operation before the
> allInstances() operation, but that doesn't seem to help either (ie.
> the size of the resulting allInstances() Set remains zero as you
> describe).
>
> I think the best way to proceed in this case seems to create a small
> demo project, and file a bug to the MDT/OCL bug tracker for this issue
> (unless EdW get's here first ;) )
> (note: https://bugs.eclipse.org/bugs/show_bug.cgi?id=241148)
>
> As a work-around, as Ed Mentions in the above post, a reformulation of
> your constraint as part of another ("containing") stereotype might
> avoid your usage of allInstances(). And as a side note, you probably
> want to use the isUnique(name) construct...
>
> HTH,
>
> Klaas
|
|
| | | |
| Re: OCL - allInstances() on Stereotype [message #1719511 is a reply to message #1719337] |
Fri, 08 January 2016 14:02 |
Klaas Gadeyne
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
Kristof De Middelaer wrote on Thu, 07 January 2016 05:44
Your assumptions were correct. The Train stereotype indeed extends from the UML meta-class. The context of the constraint was also set to the Train stereotype.
self.base_Class.allInstances().extensions->selectbyKind(Train)
allInstances() is an unresolved operation when I try this.
I've created a small example that reproduces the problem. It can be found in the .tgz, can you open it like that?
I could, but it was not really in sync with the above description IIRC.
Nevertheless, It doesn't work either at my side, although I think it should (self.base_Class points to an instance of UML::Class (which inherits from UML::Classifier), and hence should have the allInstances() operation available). Maybe the problem is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=485225 and might be solved once Bug 485225 is solved.
AFAIC, from a theoretical POV it remains tricky since the Train stereotype, on the one side, is an instance (M1) of UML::Class (M2), but on the other side, you instantiate it further in the UML model in which you apply the stereotype, so from that point of view the stereotype is actually more an M2 primitive. Never fully understood how this 'works behind the screens'.
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719517 is a reply to message #1719511] |
Fri, 08 January 2016 14:50 |
|
Hi, Klaas,
I think you're mixing metalevels.
In the expression
self.base_Class.allInstances().extensions->selectbyKind(Train)
the allInstances() operation (if it were available; I'm not commenting
on that) would return all instances of the class in the user model that
has the Train stereotype applied. So, that would be (for example)
instances of a class <<train>> Foo. Unless the class Foo defines an
'extensions' property, then that expression won't compile. In any
case, it would be extensions of the Foos in the run-time system, which
probably aren't going to be Trains.
I don't know why Train.allInstances() (or Train::allInstances(); I'm
not current on the OCL syntax) shouldn't work. Stereotypes are
classes, so they have instances in the model. If allInstances()
applied to a stereotype doesn't work, I think it's an OCL bug.
Cheers,
Christian
On 2016-01-08 14:02:28 +0000, Klaas Gadeyne said:
> Kristof De Middelaer wrote on Thu, 07 January 2016 05:44
>> Your assumptions were correct. The Train stereotype indeed extends from
>> the UML meta-class. The context of the constraint was also set to the
>> Train stereotype.
>>
>> self.base_Class.allInstances().extensions->selectbyKind(Train)
>>
>> allInstances() is an unresolved operation when I try this.
>> I've created a small example that reproduces the problem. It can be
>> found in the .tgz, can you open it like that?
>
>
> I could, but it was not really in sync with the above description IIRC.
> Nevertheless, It doesn't work either at my side, although I think it
> should (self.base_Class points to an instance of UML::Class (which
> inherits from UML::Classifier), and hence should have the
> allInstances() operation available). Maybe the problem is related to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=485225 and might be
> solved once Bug 485225 is solved.
> AFAIC, from a theoretical POV it remains tricky since the Train
> stereotype, on the one side, is an instance (M1) of UML::Class (M2),
> but on the other side, you instantiate it further in the UML model in
> which you apply the stereotype, so from that point of view the
> stereotype is actually more an M2 primitive. Never fully understood
> how this 'works behind the screens'.
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719529 is a reply to message #1719517] |
Fri, 08 January 2016 16:09 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Train.allInstances() is
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485225 . Just fixed.
Downloadable from:
http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/6.0.2/N201601081008/mdt-ocl-Update-N201601081008.zip
Element::extensions was an experimental Pivot OCL 'extension' equivalent
to extension_* avoiding the need for the UML2 Java
getAppliedStereotypes() API. It has vanished since the name was too
hazardous. A coherent design of the stereotype API is one of a too large
number of things for me still to do.
Regards
Ed Willink
On 08/01/2016 14:50, Christian W. Damus wrote:
> Hi, Klaas,
>
> I think you're mixing metalevels.
>
> In the expression
>
> self.base_Class.allInstances().extensions->selectbyKind(Train)
>
> the allInstances() operation (if it were available; I'm not commenting
> on that) would return all instances of the class in the user model
> that has the Train stereotype applied. So, that would be (for
> example) instances of a class <<train>> Foo. Unless the class Foo
> defines an 'extensions' property, then that expression won't compile.
> In any case, it would be extensions of the Foos in the run-time
> system, which probably aren't going to be Trains.
>
> I don't know why Train.allInstances() (or Train::allInstances(); I'm
> not current on the OCL syntax) shouldn't work. Stereotypes are
> classes, so they have instances in the model. If allInstances()
> applied to a stereotype doesn't work, I think it's an OCL bug.
>
> Cheers,
>
> Christian
>
>
> On 2016-01-08 14:02:28 +0000, Klaas Gadeyne said:
>
>> Kristof De Middelaer wrote on Thu, 07 January 2016 05:44
>>> Your assumptions were correct. The Train stereotype indeed extends
>>> from the UML meta-class. The context of the constraint was also set
>>> to the Train stereotype.
>>>
>>> self.base_Class.allInstances().extensions->selectbyKind(Train)
>>>
>>> allInstances() is an unresolved operation when I try this.
>>> I've created a small example that reproduces the problem. It can be
>>> found in the .tgz, can you open it like that?
>>
>>
>> I could, but it was not really in sync with the above description IIRC.
>> Nevertheless, It doesn't work either at my side, although I think it
>> should (self.base_Class points to an instance of UML::Class (which
>> inherits from UML::Classifier), and hence should have the
>> allInstances() operation available). Maybe the problem is related
>> to https://bugs.eclipse.org/bugs/show_bug.cgi?id=485225 and might be
>> solved once Bug 485225 is solved.
>> AFAIC, from a theoretical POV it remains tricky since the Train
>> stereotype, on the one side, is an instance (M1) of UML::Class (M2),
>> but on the other side, you instantiate it further in the UML model in
>> which you apply the stereotype, so from that point of view the
>> stereotype is actually more an M2 primitive. Never fully understood
>> how this 'works behind the screens'.
>
>
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719569 is a reply to message #1719517] |
Fri, 08 January 2016 22:27 |
Klaas Gadeyne
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
Christian W. Damus wrote on Fri, 08 January 2016 09:50Hi, Klaas,
I think you're mixing metalevels.
All of the time 
Quote:
In the expression
self.base_Class.allInstances().extensions->selectbyKind(Train)
the allInstances() operation (if it were available; I'm not commenting
on that) would return all instances of the class in the user model that
has the Train stereotype applied. So, that would be (for example)
instances of a class <<train>> Foo. Unless the class Foo defines an
'extensions' property, then that expression won't compile. In any
case, it would be extensions of the Foos in the run-time system, which
probably aren't going to be Trains.
You are right! self.base_Class will return for instance "Train1", which is a(n instance of) UML::Class, and so the above is basically rubbish and can never work!
Yet I don't understand the spec very well. For instance, section 7.5.10 of the OCL2.4 spec describes the use of 'static features' (::). It states that the allInstances() method is an operation applicable to _instances_ of the Classifier metaclass. So If you have a(n instance of a) uml::class Person, one should use
context person
inv blabla : person.allInstances() ...
Now in https://www.eclipse.org/forums/index.php?t=msg&th=1073468&goto=1719158&#msg_1719158, Ed Suggested to use
Element.allInstances().extensions->selectByKind(MyStereotype).
I though at the time that Element referred to an element in the uml metamodel for instance uml::class
But if I'm reading the spec right, then I would think the above is not possible (ie. it should be Element::allInstances)?? Maybe Ed can clarify in which context he wrote the above statement...
Quote:
I don't know why Train.allInstances() (or Train::allInstances(); I'm
not current on the OCL syntax) shouldn't work. Stereotypes are
classes, so they have instances in the model.
The latter sentence is not so obvious to me (also remember our discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062  ).
Indeed, OTOH, Stereotypes are Classes, so you could say there is no difference between a Train class (defined in a UML model) and a Train stereotype (defined in a UML profile). Yet the instances of the former are (represented by) UML instancespecifications, and instances of the latter appear in UML models where they 'extend' other classes. So I'm not sure I understand what you mean with the last sentence.
Quote:If allInstances()
applied to a stereotype doesn't work, I think it's an OCL bug.
I do agree with Ed that at least the spec is very vague about all this...
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719579 is a reply to message #1719569] |
Sat, 09 January 2016 08:13 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
On 08/01/2016 22:27, Klaas Gadeyne wrote:
> Yet I don't understand the spec very well. For instance, section
> 7.5.10 of the OCL2.4 spec describes the use of 'static features'
> (::). It states that the allInstances() method is an operation
> applicable to _instances_ of the Classifier metaclass. So If you have
> a(n instance of a) uml::class Person, one should use
allInstnaces() was in OCL 2.0.
'static' was added to OCL 2.2 without any helpful accompanying text.
No consideration was given as to whether allInstances() should be a
static feature to align with "::" / "." navigation confusion. In the
Eclipse OCL 2.5 prototype library model, allInstances is a static
operation, but it is still overloadable! How can I justfy that?
X::allInstances() is a static navigation that chooses the most static
derivation. ...oclType().allInstances() must use a non-staic method, so
we must have both static and non-static declarations of allInstances()
if we use Java-like overload resolution.
>
> Quote:
>> If allInstances() applied to a stereotype doesn't work, I think it's
>> an OCL bug.
>
>
> I do agree with Ed that at least the spec is very vague about all this...
It depends on what you understand by an instance.
In the sense that any use of a class is an instantiation and so an
instance, then yes, stereotypes have instances.
In the sense that objects are partitioned by metalevel into classes and
instances, then no, since there is a single logical object corresponding
to a class instantiation and zero or more stereotype applications. But
this a metalevel confusion caused by the expectation that instances are
at M0 and classes are at M1. Stereotypes are at M2, so stereotype
instances are at M1. The logical class that defines an actual M0 object
is a merge of an M1 class and zero or more M1 stereotype-instances. Much
less confusing to call them stereotype-applications or element-extensions.
So MyStereotype::allInstances() returns the stereotype-applications. cf.
The redefinitions of OclElement::allInstances() for
MyEnumeration::allInstances() returns the enumeration-literals,
Boolean::allInstances() returns {true, false}.
If all stereotypes implicitly extend OclSterotype which extends OclType
which extends OclElement which extends OclAny, then
OclStereotype::allInstances() is the redefining overload of
OclElement::allInstances() that explains the functionality and provides
additional power to reason about all-stereotype-applications.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485471
Regards
Ed Willink
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719681 is a reply to message #1719569] |
Mon, 11 January 2016 12:48 |
|
On 2016-01-08 22:27:58 +0000, Klaas Gadeyne said:
> Yet I don't understand the spec very well. For instance, section
> 7.5.10 of the OCL2.4 spec describes the use of 'static features' (::).
> It states that the allInstances() method is an operation applicable to
> _instances_ of the Classifier metaclass. So If you have a(n instance
> of a) uml::class Person, one should use
>
> context person
> inv blabla : person.allInstances() ...
I may be going on old knowledge of the spec from earlier 2.x revisions
(I haven't really kept up), so this may be wishful thinking on my part.
The allInstances operation isn't really a static operation. It is an
operation of the OclType metaclass from OCL. The OCL expression
Person
is an expression that evaluates to an instance of OclType, which then makes
Person.allInstances()
a call to the non-static allInstances() operation of that OclType
instance. If the allInstances operation were static, it would have to
be (re)declared on every UML/OCL/whatever M1 type in the model. That
doesn't seem sensible to me.
In any case, it looks like the latest nightly builds of Eclipse OCL
should make Train.allInstances() work as expected (at least, as one
expects based on the EMF implementation of stereotypes). Thanks to Ed
for that.
|
|
| |
| Re: OCL - allInstances() on Stereotype [message #1719748 is a reply to message #1719692] |
Mon, 11 January 2016 19:09 |
|
Hi, Ed,
See some replies in-line, below.
Cheers,
Christian
On 2016-01-11 13:39:02 +0000, Ed Willink said:
> On 11/01/2016 12:48, Christian W. Damus wrote:
>> The allInstances operation isn't really a static operation. It is an
>> operation of the OclType metaclass from OCL. The OCL expression
>>
>> Person
>>
>> is an expression that evaluates to an instance of OclType, which then makes
>>
>> Person.allInstances()
>>
> How can this be anything other than static; there is no self at the
> same meta-level as the returns.
>
> In C++ this would be Person::allInstances()
>
> In Java, Person.class.allInstances().
The Java equivalent of your C++ example would be Person.allInstances(),
which is a static invocation. But, of course,
Person.class.allInstances() is more like what Issue 8937 is stating:
this is a non-static operation of Java's Class class.
> In the resolution of OMG Issue No: 8937, you will find:
>
> "Invocation of allInstances uses the '.' operator rather than '::'
> because it is not a static operation. It
> is an operation applicable to instances of the Classifier metaclass, of
> which Person is an example."
>
> I used to think this makes sense. I don't any longer. If you climb a
> meta-level any 'static' feature becomes non-static. The distinction is
> that static features can be declared at the 'wrong' meta-level.
Climbing a meta-level goes into a completely different type space. It
has nothing to do with static or instance scope of a feature.
Given a UML model containing a class Person with a static
"defaultEyeColor" operation, if we "climb a meta-level", then we have
an instance of the Class metaclass containing an instanceof of the
Operation metaclass that happens to be named "defaultEyeColor". In
what way could this possibly be interpreted from this perspective as a
non-static feature of anything? It certainly can't be invoked as a
non-static feature of the Class metaclass. This meta-level is
something quite different.
I think the intent in OCL is that a static operation of the Person
class would be referenced like so:
Person::defaultEyeColor()
which by using the '::' operator makes the 'Person' reference not an
OclType expression but just a namespace qualifier on the static
operation name, whereas in
Person.allInstances()
the '.' operator requires the 'Person' reference to be parsed as an
OclType expression returning an OclType/class/whatever that has an
allInstances() operation (that is non-static).
|
|
|
| Re: OCL - allInstances() on Stereotype [message #1719926 is a reply to message #1719748] |
Wed, 13 January 2016 09:48 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Christian
When climbing a meta-level takes you from Person to Class, you are
completely correct.
But if climbing takes you from Person to Class<Person>, then some trace
of Person remains at the metalevel and it is this trace that could
enable access to the static methods of Person.
The unstable specfication of oclType() has been chasing that lack of a
templated Class<T>, by evolving a magic T return from an open
enumeration, to a powerset. However a full templated Class<T> adds huge
power/complexity to support just two modeling requirements. More
narrowly supported by typeof(T) in the Library definition Concrete
Syntax, and in the underlying AST, where TypedElement.type may be the
true metatype: Class, and TypedElement.typeValue the trace of its
instantiated type.
The Eclpse OCL prototype Library declaration shows the usage and
corresponding type safety without magic words:
type OclAny : AnyType {
operation oclAsType(TT)(type : typeof(TT)) : TT[1] invalidating =>
'org.eclipse.ocl.pivot.library.oclany.OclAnyOclAsTypeOperation'
operation oclType() : typeof(OclSelf)[1] =>
'org.eclipse.ocl.pivot.library.oclany.OclAnyOclTypeOperation';
....
type Collection(T) : CollectionType conformsTo OclAny {
operation selectByKind(TT)(type : typeof(TT)) : Collection(TT[*|1])
=>
'org.eclipse.ocl.pivot.library.collection.CollectionSelectByKindOperation';
operation selectByType(TT)(type : typeof(TT)) : Collection(TT[*|1])
=>
'org.eclipse.ocl.pivot.library.collection.CollectionSelectByTypeOperation';
.....
aPerson.oclType() therefore returns typeof(Person) which is a Class that
has not forgotten about Person at compile-time as well as at run-time.
cf Java, where aPerson().getClass() returns Class<?> and must be cast
back to Class<Person> to continue using it effectively.
aPerson.oclType().allInstances() can return the same as
Person.allInstances(), not Class.allInstances().
allInstances() is static in that its 'self' should be a instance of the
class. "." navigation is appropriate since it is an overloadable
navigation from an instance. "::" is a static navigation in the
declaration hierarchy. (which solves my uncertainty as to whether to
refer to Person::name or Person.name; if Person inherits from
NamedElement then there is a NamedElement::name property whose value
might be "john", whereas NamedElement.name is a navigation of the class
instance whose value is "NamedElement". It is unfortunate that OCL does
not have a clear syntax for type access similar to Java's ".class").
Regards
Ed Willink
On 11/01/2016 19:09, Christian W. Damus wrote:
> Hi, Ed,
>
> See some replies in-line, below.
>
> Cheers,
>
> Christian
>
>
> On 2016-01-11 13:39:02 +0000, Ed Willink said:
>
>> On 11/01/2016 12:48, Christian W. Damus wrote:
>>> The allInstances operation isn't really a static operation. It is
>>> an operation of the OclType metaclass from OCL. The OCL expression
>>>
>>> Person
>>>
>>> is an expression that evaluates to an instance of OclType, which
>>> then makes
>>>
>>> Person.allInstances()
>>>
>> How can this be anything other than static; there is no self at the
>> same meta-level as the returns.
>>
>> In C++ this would be Person::allInstances()
>>
>> In Java, Person.class.allInstances().
>
> The Java equivalent of your C++ example would be
> Person.allInstances(), which is a static invocation. But, of course,
> Person.class.allInstances() is more like what Issue 8937 is stating:
> this is a non-static operation of Java's Class class.
>
>
>> In the resolution of OMG Issue No: 8937, you will find:
>>
>> "Invocation of allInstances uses the '.' operator rather than '::'
>> because it is not a static operation. It
>> is an operation applicable to instances of the Classifier metaclass,
>> of which Person is an example."
>>
>> I used to think this makes sense. I don't any longer. If you climb a
>> meta-level any 'static' feature becomes non-static. The distinction
>> is that static features can be declared at the 'wrong' meta-level.
>
> Climbing a meta-level goes into a completely different type space. It
> has nothing to do with static or instance scope of a feature.
>
> Given a UML model containing a class Person with a static
> "defaultEyeColor" operation, if we "climb a meta-level", then we have
> an instance of the Class metaclass containing an instanceof of the
> Operation metaclass that happens to be named "defaultEyeColor". In
> what way could this possibly be interpreted from this perspective as a
> non-static feature of anything? It certainly can't be invoked as a
> non-static feature of the Class metaclass. This meta-level is
> something quite different.
>
> I think the intent in OCL is that a static operation of the Person
> class would be referenced like so:
>
> Person::defaultEyeColor()
>
> which by using the '::' operator makes the 'Person' reference not an
> OclType expression but just a namespace qualifier on the static
> operation name, whereas in
>
> Person.allInstances()
>
> the '.' operator requires the 'Person' reference to be parsed as an
> OclType expression returning an OclType/class/whatever that has an
> allInstances() operation (that is non-static).
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 07:13:43 GMT 2024
Powered by FUDForum. Page generated in 0.02874 seconds |
] 
Search
Help
Register
Login
Home
