Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » OCL - allInstances() on Stereotype
OCL - allInstances() on Stereotype [message #1718919] Sat, 02 January 2016 12:37 Go to next message
Kristof De Middelaer is currently offline Kristof De MiddelaerFriend
Messages: 10
Registered: December 2015
Junior Member
Hello,

I've made a Train stereotype (of the Class metaclass) and wanted to check whether or not there are two Trains with the same name attribute.

I created an OCL constraint:
{{OCL} Train.allInstances()->one(t | t.name = self.name)}
which didn't work.

So I thought that maybe the allInstances() wasn't working the way I expected it.
So I tried to add this constraint:
{{OCL} Train.allInstances()->size()} = 3

After playing around with this, it turns out that Train.allInstances() has size 0.

Is it impossible to use allInstances on stereotypes?
Re: OCL - allInstances() on Stereotype [message #1719035 is a reply to message #1718919] Mon, 04 January 2016 15:40 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
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 Wink )
(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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6993
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 #1719293 is a reply to message #1719158] Wed, 06 January 2016 20:00 Go to previous messageGo to next message
Kristof De Middelaer is currently offline Kristof De MiddelaerFriend
Messages: 10
Registered: December 2015
Junior Member
Thank you both for your replies!

I had high hopes for Pivot OCL as in my preferences LPG OCL was selected.
Unfortunately, none of the suggested solutions seem to work.
I get a parser error on the "extensions" property with
Element.allInstances().extensions->selectByKind(MyStereotype)

and
self.oclType().allInstances()
from the other topic doesn't work either.

Too bad these won't work. My other constraints work just fine though. :/

Greetings,

Kristof
Re: OCL - allInstances() on Stereotype [message #1719324 is a reply to message #1719293] Thu, 07 January 2016 09:10 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Kristof,
Kristof De Middelaer wrote on Wed, 06 January 2016 15:00
Thank you both for your replies!

I had high hopes for Pivot OCL as in my preferences LPG OCL was selected.
Unfortunately, none of the suggested solutions seem to work.
I get a parser error on the "extensions" property with
Element.allInstances().extensions->selectByKind(MyStereotype)



You will need to provide more information (and preferably a small project that reproduces the problem) if you want to get help on this one.

Assuming you're inserting these constraints in a profile (ie. not using completeOCL), you cannot directly add a constraint to a UML meta-class, so you would have to add a constraint that has the Train stereotype as its context and to something like

self.base_Class.allInstances().extensions->selectbyKind(Train)


(note; this assumes that Train extends UML::Class)

But now I'm assuming too much (aka loosing my time Smile
Re: OCL - allInstances() on Stereotype [message #1719337 is a reply to message #1719324] Thu, 07 January 2016 10:44 Go to previous messageGo to next message
Kristof De Middelaer is currently offline Kristof De MiddelaerFriend
Messages: 10
Registered: December 2015
Junior Member
Klaas Gadeyne wrote on Thu, 07 January 2016 09:10
Hi Kristof,
Kristof De Middelaer wrote on Wed, 06 January 2016 15:00
Thank you both for your replies!

I had high hopes for Pivot OCL as in my preferences LPG OCL was selected.
Unfortunately, none of the suggested solutions seem to work.
I get a parser error on the "extensions" property with
Element.allInstances().extensions->selectByKind(MyStereotype)



You will need to provide more information (and preferably a small project that reproduces the problem) if you want to get help on this one.

Assuming you're inserting these constraints in a profile (ie. not using completeOCL), you cannot directly add a constraint to a UML meta-class, so you would have to add a constraint that has the Train stereotype as its context and to something like

self.base_Class.allInstances().extensions->selectbyKind(Train)


(note; this assumes that Train extends UML::Class)

But now I'm assuming too much (aka loosing my time Smile


I really appreciate your response Smile

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?

Kind regards,

Kristof
Re: OCL - allInstances() on Stereotype [message #1719511 is a reply to message #1719337] Fri, 08 January 2016 14:02 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
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 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1235
Registered: July 2009
Location: Canada
Senior Member

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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6993
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 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Christian,
Christian W. Damus wrote on Fri, 08 January 2016 09:50
Hi, Klaas,

I think you're mixing metalevels.


All of the time Sad

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 Smile ).
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6993
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 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1235
Registered: July 2009
Location: Canada
Senior Member

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 #1719692 is a reply to message #1719681] Mon, 11 January 2016 13:39 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6993
Registered: July 2009
Senior Member
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().

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.

---

The Eclipse OCL modeling is:

type OclElement conformsTo OclAny {
static operation allInstances() : Set(OclSelf[*|1]) =>
'org.eclipse.ocl.pivot.library.classifier.ClassifierAllInstancesOperation';
.....
}

OvlSelf is the statically known type of the source avoiding the loss of
type resolution without overloading in every class.
Regards

Ed
Re: OCL - allInstances() on Stereotype [message #1719748 is a reply to message #1719692] Mon, 11 January 2016 19:09 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1235
Registered: July 2009
Location: Canada
Senior Member

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 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6993
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).
>
Previous Topic:Sequence Diagram - Filter out signals which are not receivable
Next Topic:Diagram Frames
Goto Forum:
  


Current Time: Mon Jan 25 09:03:59 GMT 2021

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

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

Back to the top