Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » oclIsTypeOf() does not work as expected
oclIsTypeOf() does not work as expected [message #1723148] Fri, 12 February 2016 07:49 Go to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi All,

I cannot get my head around this.

I have created a class Class1 and an InstanceSpecification InstanceSpecfication:Class1

I have also create the following constraint for Class1:
self.oclIsTypeOf(Class1)


I was expecting it to be always verified, but when I validate the model I get that the constraint is violated.

If I replace the above OCL constraint with the following
self.oclIsTypeOf(UML:InstanceSpecification)

the model get validated

Also, If I execute the xText OCL console on InstanceSpecification1 I get
Evaluating:
self.oclType()
Results:
UML::InstanceSpecification
Re: oclIsTypeOf() does not work as expected [message #1723168 is a reply to message #1723148] Fri, 12 February 2016 10:02 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

[It is very rarely appropriate to use oclIsTypeOf; oclIsKindOf is almost
always better.]

Your instructions are vague so I'm forced to guess a bit.

Eclipse UML2 supports only what is specified by the UML specification,
consequently extensions provided via OCL constraints do not constitute
part of the Eclipse UML2 validation. Eclipse OCL therefore adds an
OCL->Validate menu option for use within the UML2 Model Editor.

Papyrus tries to be more helpful, however the wide diversity of
Constraint sources has let to difficulties where some constraints get
validated twice and some not at all. A Recent Papyrus bug fix may solve
this, or may just move the problem around again. Anyway, try the
OCL->Validate menu option to see if it helps. You can also try the
OCL->Validity VIew to get a more fine-grained view of your constraints
successes and failures.

Alternatively, perverse refusal to validate obviously correct
constraints involving oclIsKindOf/oclIsTypeOf can be down to metamodel
schizophrenia; two different providers of e.g. "Class1" so that the
left-hand Class1 is not conformant to the right-hand Class1. Typically
one comes from a plugin model and another from a project model. The OCL
project is perhaps the only project to try to accommodate rather than
fail obscurely by considering the package URI rather than the file URI
as the distinguishing metamodel identity. However you may have managed
tio find a new mechanism for metamodel schizophrenia.

Regards

Ed Willink



On 12/02/2016 07:49, Roberto Saltini wrote:
> Hi All,
>
> I cannot get my head around this.
>
> I have created a class Class1 and an InstanceSpecification
> InstanceSpecfication:Class1
>
> I have also create the following constraint for Class1:
>
> self.oclIsTypeOf(Class1)
>
> I was expecting it to be always verified, but when I validate the
> model I get that the constraint is violated.
>
> If I replace the above OCL constraint with the following
> self.oclIsTypeOf(UML:InstanceSpecification)
> the model get validated
>
> Also, If I execute the xText OCL console on InstanceSpecification1 I get
> Evaluating:
> self.oclType()
> Results:
> UML::InstanceSpecification
Re: oclIsTypeOf() does not work as expected [message #1723170 is a reply to message #1723168] Fri, 12 February 2016 10:32 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Thank your for your reply.

Here is the model that fails the validation

index.php/fa/24968/0/


OLC->Validate works on the Constraint. However, when I validate the entire model, it fails.

Roberto.
Re: oclIsTypeOf() does not work as expected [message #1723182 is a reply to message #1723170] Fri, 12 February 2016 11:30 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Also, please note the output of the OCL console

index.php/fa/24971/0/
  • Attachment: oclTests.png
    (Size: 39.23KB, Downloaded 1188 times)
Re: oclIsTypeOf() does not work as expected [message #1723183 is a reply to message #1723182] Fri, 12 February 2016 11:39 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

It looks as if you have too many different things named Class1, but you
don't make it easy to help.

See https://wiki.eclipse.org/OCL/ForumNetiquette

Regards

Ed Willink


On 12/02/2016 11:30, Roberto Saltini wrote:
> Also, please note the output of the OCL console
>
>
Re: oclIsTypeOf() does not work as expected [message #1723200 is a reply to message #1723183] Fri, 12 February 2016 13:11 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Sorry for not having provided enough details.

Please fine attached a zip file with the example project.

The problem is observed when I try to validate the model through Validation->Validate Model.

The version of the org.eclipse.ocl.ecore plugin is 3.5.0v20150525/1653

Roberto
Re: oclIsTypeOf() does not work as expected [message #1723217 is a reply to message #1723200] Fri, 12 February 2016 14:25 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

https://bugs.eclipse.org/bugs/show_bug.cgi?id=487739 raised.

The problem is localized to the type-of an InstanceSpecification that is
different at M1 and M2. Try to avoid using the type-of. Probably
debugging of a real problem has caused you to fall into this confusing
trap.

Regards

Ed Willink


On 12/02/2016 13:11, Roberto Saltini wrote:
> Hi Ed,
>
> Sorry for not having provided enough details.
>
> Please fine attached a zip file with the example project.
>
> The problem is observed when I try to validate the model through Validation->Validate Model.
>
> The version of the org.eclipse.ocl.ecore plugin is 3.5.0v20150525/1653
>
> Roberto
Re: oclIsTypeOf() does not work as expected [message #1723269 is a reply to message #1723217] Sat, 13 February 2016 04:42 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Is there any workaround for this?
Is there any way to communicate to OCL that I am operating in M1 layer?

Thanks,
Roberto
Re: oclIsTypeOf() does not work as expected [message #1723278 is a reply to message #1723269] Sat, 13 February 2016 09:09 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Wthout knowing what your real problem is, it is very difficult to say.
With a bit of imagination, most things can be worked around. The problem
only affects InstanceSpecification and if really necessary you could
create your own set of isXXX() predicates to test for oclIsTypeOf(XXX).

Regards

Ed Willink


On 13/02/2016 04:42, Roberto Saltini wrote:
> Hi Ed,
>
> Is there any workaround for this?
> Is there any way to communicate to OCL that I am operating in M1 layer?
>
> Thanks,
> Roberto
Re: oclIsTypeOf() does not work as expected [message #1723302 is a reply to message #1723278] Sat, 13 February 2016 23:32 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Thanks for your reply.
I have come start using Papyrus because I needed an UML editor to produce some models for a software requirements specification that I am writing. So I have no experience with Eclipse MDT and OCL and I am trying to get my head around this stuff now.
I do not know any other confident way to work with OCL than creating a Constraint block in Papyrus.
Is there any tutorial that can help to work with OCL and Papyrus?
Especially, is there anyway to use the Interactive console to debug my OCL expression in M1?

Thanks,
Roberto.
Re: oclIsTypeOf() does not work as expected [message #1723305 is a reply to message #1723302] Sun, 14 February 2016 01:51 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Thanks for your reply.
Here is one of the problem that I am trying to solve.
Considering the following diagram:
index.php/fa/24987/0/


I want to use OCL to express that the type of the instance assigned to the attribute Block1.minPress has to be the same of the instance assigned to the attribute Block1.maxPress

However, the OCL constraint that I wrote always validates the model. Whereas it should not validate the model in the example given.

Please find the sample project attached as well.


Thanks,
Roberto.
  • Attachment: oclTests2.png
    (Size: 76.29KB, Downloaded 876 times)
  • Attachment: testOCL2.zip
    (Size: 5.60KB, Downloaded 125 times)

[Updated on: Sun, 14 February 2016 01:51]

Report message to a moderator

Re: oclIsTypeOf() does not work as expected [message #1723328 is a reply to message #1723305] Sun, 14 February 2016 12:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

I've taken a look at the oustanding bugs in this area and refreshed my
memory a bit. It is a very awkward area.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=400090
https://bugs.eclipse.org/bugs/show_bug.cgi?id=439222
https://bugs.eclipse.org/bugs/show_bug.cgi?id=458326
https://bugs.eclipse.org/bugs/show_bug.cgi?id=458394
https://bugs.eclipse.org/bugs/show_bug.cgi?id=458395

Your example helps me see what is going wrong.

----

OCL evaluation on an InstanceSpecification is troublesome. Should "self" be
- an instance of the UML InstanceSpecification as would be the case for
any other evaluation using a mouse selection in a UML model to identify
the context
- an instance of one or all of the InstanceSpecification::classifier
types to allow navigation in the instance world

The non-Xtext OCL console provided Ecore/UML M1/M2 behavioral options.
It seems that we need a user choice as to whether the selection's
OclType is to be computed from within the model (e.g. using
InstanceSpecification::classifier) or from the metamodel (e.g. using
EObject::eClass() or OclAny::oclType()).

A choice to use model-determined OclType could make the OCL console
useful, and extensible to other contexts in which types are no isolated
in different metamodel layers.

----

Back to your problem. I think you should be using compatibility of
InstanceSpecification::classifier to check for consistent usage.
Attempting to subvert oclType()/oclIsKindOf()/oclIsTypeOf() for this
purpose is unnecessary and dangerous.

----

The Help->Contents OCL documentation provides tutorials, with some
reference to Papyrus.

Once the OCL Console has a model-determined OclType, you will be able to
use the debug button with the OCL Console to debug your evaluations.

Regards

Ed Willink





On 14/02/2016 01:51, Roberto Saltini wrote:
> Hi Ed,
>
> Thanks for your reply.
> Here is one of the problem that I am trying to solve.
> Considering the following diagram:
>
>
>
> I want to use OCL to express that the type of the instance assigned to the attribute Block1.minPress has to be the same of the instance assigned to the attribute Block1.maxPress
>
> Howeve, the OCL constraint that I wrote always validate the model. Whereas it should not validate the model in the example given.
>
> Please find the sample project attached as well.
>
>
> Thanks,
> Roberto.
Re: oclIsTypeOf() does not work as expected [message #1723343 is a reply to message #1723328] Sun, 14 February 2016 21:38 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi,

Thanks for your help.

However, I have not been able to solve my issue.
I am not able to understand what you mean by
Quote:
I think you should be using compatibility of
InstanceSpecification::classifier to check for consistent usage.


Would you be able to provide me with the OCL constraint to use for the project testOCL2.zip described in my previous post?
In this way, I could use your solution to better understand how to use UML with Papyrus.


Ed Willink wrote on Sun, 14 February 2016 12:10


The Help->Contents OCL documentation provides tutorials, with some
reference to Papyrus.





Help->Contents OCL documentation describes just a some simple example which I am able to reproduce, but unfortunately it does not describe anything related to my problem.

Quote:
Once the OCL Console has a model-determined OclType, you will be able to
use the debug button with the OCL Console to debug your evaluations.


How can I provide OCL Console with a mode-determined OclType?

Thanks,
Roberto
Re: oclIsTypeOf() does not work as expected [message #1723395 is a reply to message #1723343] Mon, 15 February 2016 11:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Unfortunately your model uses SysML 1.4 that is not available in/from
current (milestone) Papyrus distributions, so cannot load your model.

Something like

thisInstance.classifier->union(thatInstance.classifier)->notEmpty()

might be what you want; but you have to decide what multi-classification
means for you.

---

OCL GIT branch ewillink/400090 adds support for a model/metamodel
determination of context type.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=400090

has some of my Eclipse thinking on this.

http://issues.omg.org/browse/OCL25-206

has my OMG thinking.

Note that there is no UML or OCL specification or even indication that
OCL navigation on the slots or classification of an
InstanceSpecification is possible; we are entirely in the domain of what
should 'obviously' work somehow. Consideration of oclAsType() behaviour
makes me think that we should merge the user-defined and
metamodel-defined typing as just a greater degree of
multi-classification. There is then no need for any M1/M2
model/metamodel variation in behaviour.

Regards

Ed Willink

On 14/02/2016 21:38, Roberto Saltini wrote:
> Hi,
>
> Thanks for your help.
>
> However, I have not been able to solve my issue.
> I am not able to understand what you mean by Quote:
>> I think you should be using compatibility of
>> InstanceSpecification::classifier to check for consistent usage.
>
>
> Would you be able to provide me with the OCL constraint to use for the
> project testOCL2.zip described in my previous post?
> In this way, I could use your solution to better understand how to use
> UML with Papyrus.
>
>
> Ed Willink wrote on Sun, 14 February 2016 12:10
>> The Help->Contents OCL documentation provides tutorials, with some
>> reference to Papyrus.
>
>
> Help->Contents OCL documentation describes just a some simple example
> which I am able to reproduce, but unfortunately it does not describe
> anything related to my problem.
>
> Quote:
>> Once the OCL Console has a model-determined OclType, you will be able
>> to use the debug button with the OCL Console to debug your evaluations.
>
>
> How can I provide OCL Console with a mode-determined OclType?
>
> Thanks,
> Roberto
Re: oclIsTypeOf() does not work as expected [message #1723475 is a reply to message #1723395] Mon, 15 February 2016 21:23 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Thanks for your answer.
I have tried your suggestion but I was not successful.
I think that I am missing something.
So I recreated the issue by using UML only and I have attached a new project that you should be able to open with your Papyrus.

There is one conceptual thing that I think I am missing. From my understanding, all of the OCL constraint defined for a specific class in UML will be tested against InstanceSpecifications of this class only. It is only when the class in instantiated ( and I think you can do this only through an InstanceSpecification ) that the OCL constraint can be tested.
Am I missing something?

Thanks,
Roberto.
  • Attachment: testOCL3.zip
    (Size: 3.89KB, Downloaded 137 times)
Re: oclIsTypeOf() does not work as expected [message #1723491 is a reply to message #1723475] Tue, 16 February 2016 07:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

With the benefit of the Bug 400090 enhancement I can play with the
console and see that

https://bugs.eclipse.org/bugs/show_bug.cgi?id=458394

left some InstanceValue support working with suggestions for more
testing. It seems that current functionality support the existence but
not use of the InstanceValue. Sorry.

-------

Yes. In principle InstanceSpecification gives you an ability to mix
Classes and Instances in a single diagram, and consequently OCL
associated with Classes can be exercised on the Instances. This
functionality is not defined by OMG and so an intuitive extrapolation is
evolving. Unfortunately there is no body of useful examples and creating
them in the UML Model Editor is not easy. Creating them within Papyrus
hits other limitations. In practice this boundary has been pushed by a
couple of sympathetic users. You are pushing a bit further and providing
the example that is needed to embarrass the developer(s). Thanks.

The only workaround I can see for you today exploits toString():

Evaluating:
self.Attribute1.toString()
Results:
'org.eclipse.uml2.uml.internal.impl.InstanceSpecificationImpl@608e34bf
(name: DeriveType1Instance, visibility: <unset>)'

You can extract the type string from between "(name: " and ", visibility".

let s1 = self.Attribute1.toString(),
s1b = s1.indexOf('(name: '),
s1e = s1.indexOf(', visibility'),
s1s = s1.substring(s1b+7,s1e-1),
s2 = self.Attribute2.toString(),
s2b = s2.indexOf('(name: '),
s2e = s2.indexOf(', visibility'),
s2s = s2.substring(s2b+7,s2e-1)
in s1s = s2s

(A helper function would make this less opaque, but that is not trivial
in Papyrus.)

Regards

Ed Willink


On 15/02/2016 21:23, Roberto Saltini wrote:
> Hi Ed,
>
> Thanks for your answer.
> I have tried your suggestion but I was not successful.
> I think that I am missing something.
> So I recreated the issue by using UML only and I have attached a new project that you should be able to open with your Papyrus.
>
> There is one conceptual thing that I think I am missing. From my understanding, all of the OCL constraint defined for a specific class in UML will be tested against InstanceSpecifications of this class only. It is only when the class in instantiated ( and I think you can do this only through an InstanceSpecification ) that the OCL constraint can be tested.
> Am I missing something?
>
> Thanks,
> Roberto.
Re: oclIsTypeOf() does not work as expected [message #1723511 is a reply to message #1723491] Tue, 16 February 2016 10:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

> The only workaround I can see for you today exploits toString():

Arguably we are looking at this the wrong way. Why are we trying to
evaluate a metamodel constraint at the model level?

If we stick to the metamodel level, the following works.

let a1 = self.slot->select(definingFeature.name =
'Attribute1').value->any(true).oclAsType(InstanceValue) in
let a2 = self.slot->select(definingFeature.name =
'Attribute2').value->any(true).oclAsType(InstanceValue) in
a1.instance.classifier = a2.instance.classifier

https://bugs.eclipse.org/bugs/show_bug.cgi?id=458394 suggests that if
model level evaluation is to be useful we may need a suitably overloaded
ValusSpecification::umlClassifiers() method to support use of UML's
model-level typing rater than oclType()/oclTypes() that accesses OCL's
metmodel-level typing.

Regards

Ed Willink


On 16/02/2016 07:41, Ed Willink wrote:
> Hi
>
> With the benefit of the Bug 400090 enhancement I can play with the
> console and see that
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=458394
>
> left some InstanceValue support working with suggestions for more
> testing. It seems that current functionality support the existence but
> not use of the InstanceValue. Sorry.
>
> -------
>
> Yes. In principle InstanceSpecification gives you an ability to mix
> Classes and Instances in a single diagram, and consequently OCL
> associated with Classes can be exercised on the Instances. This
> functionality is not defined by OMG and so an intuitive extrapolation
> is evolving. Unfortunately there is no body of useful examples and
> creating them in the UML Model Editor is not easy. Creating them
> within Papyrus hits other limitations. In practice this boundary has
> been pushed by a couple of sympathetic users. You are pushing a bit
> further and providing the example that is needed to embarrass the
> developer(s). Thanks.
>
> The only workaround I can see for you today exploits toString():
>
> Evaluating:
> self.Attribute1.toString()
> Results:
> 'org.eclipse.uml2.uml.internal.impl.InstanceSpecificationImpl@608e34bf
> (name: DeriveType1Instance, visibility: <unset>)'
>
> You can extract the type string from between "(name: " and ",
> visibility".
>
> let s1 = self.Attribute1.toString(),
> s1b = s1.indexOf('(name: '),
> s1e = s1.indexOf(', visibility'),
> s1s = s1.substring(s1b+7,s1e-1),
> s2 = self.Attribute2.toString(),
> s2b = s2.indexOf('(name: '),
> s2e = s2.indexOf(', visibility'),
> s2s = s2.substring(s2b+7,s2e-1)
> in s1s = s2s
>
> (A helper function would make this less opaque, but that is not
> trivial in Papyrus.)
>
> Regards
>
> Ed Willink
>
>
> On 15/02/2016 21:23, Roberto Saltini wrote:
>> Hi Ed,
>>
>> Thanks for your answer.
>> I have tried your suggestion but I was not successful.
>> I think that I am missing something.
>> So I recreated the issue by using UML only and I have attached a new
>> project that you should be able to open with your Papyrus.
>>
>> There is one conceptual thing that I think I am missing. From my
>> understanding, all of the OCL constraint defined for a specific class
>> in UML will be tested against InstanceSpecifications of this class
>> only. It is only when the class in instantiated ( and I think you can
>> do this only through an InstanceSpecification ) that the OCL
>> constraint can be tested.
>> Am I missing something?
>>
>> Thanks,
>> Roberto.
>
Re: oclIsTypeOf() does not work as expected [message #1723632 is a reply to message #1723511] Tue, 16 February 2016 21:48 Go to previous messageGo to next message
Roberto Saltini is currently offline Roberto SaltiniFriend
Messages: 24
Registered: February 2016
Junior Member
Hi Ed,

Thank you for your help.

Is OCL intended to be used to express meta-model constraints only? From my understanding, OCL can be used to express model constraints as well. Am I wrong?

Point 7.5,9 of the latest OCL spec, states that
Quote:
The operation is oclIsTypeOf results in true if the type of self and t are the same. For example:
context Person
inv: self.oclIsTypeOf( Person ) -- is true
inv: self.oclIsTypeOf( Company) -- is false


So it appears to me that OCL is intended to work with the model as well.

------------------------------

Regarding your help for my specific problem:
Quote:

If we stick to the metamodel level, the following works.
let a1 = self.slot->select(definingFeature.name =
'Attribute1').value->any(true).oclAsType(InstanceValue) in
let a2 = self.slot->select(definingFeature.name =
'Attribute2').value->any(true).oclAsType(InstanceValue) in
a1.instance.classifier = a2.instance.classifier


This works if I type it in the Xtext OCL Console, but it does not work if I use it in a Constraint block associated to a specific class.

I have attached the new project sample modified for you reference.

----

Thanks,
Roberto
  • Attachment: testOCL3.zip
    (Size: 4.01KB, Downloaded 135 times)
Re: oclIsTypeOf() does not work as expected [message #1723690 is a reply to message #1723632] Wed, 17 February 2016 09:21 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille LetavernierFriend
Messages: 952
Registered: February 2011
Senior Member
Hi Roberto,

Quote:
So it appears to me that OCL is intended to work with the model as well.


Yes, but an InstanceSpecification is not an Instance. It is at the same meta-level than the Class it is typed with.

The constraints defined in UML apply to both Class and InstanceSpecification
The constraints defined in UML Profiles apply to both Class and InstanceSpecification
The constraints defined in a specific UML Model, on a Class, apply to the instances of that Class. But UML doesn't define the instance level (It may typically be generated code)

The validation of Class' constraints on InstanceSpecifications is thus non-normative, and only a best-effort support is provided. There is a lot of confusion (and disagreement) about the notion of Instance/InstanceSpecification in UML 2

Regards,
Camille


Camille Letavernier
Re: oclIsTypeOf() does not work as expected [message #1723696 is a reply to message #1723632] Wed, 17 February 2016 09:36 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

OCL potentially works with any technology that provides classes with
properties and operations. The philosophy of the Pivot-based Eclipse OCL
is that the external technology is normalized by conversion to the
internal pivot model. OCL works at any level, so M2 definitions in UML
profiles can be evaluated for M1 instances, and M1 declarations can
define functionality for M0 run-time evaluation.

oclType() and related operations are defined for evaluation at M(n)
using the types defined at M(n+1).

The use of InstanceSpecification creates a confusion, since nominally M1
types describing M0 instances are instantiated in a nominally M1 diagram.

For InstanceSpecifications representing nominally M0 instances at M1 we
have a choice of two type systems, the normal M2 types or the modelled
M1 types available via InstanceSpecification::classifier.

Eclipse OCL has been bending over to try to be 'helpful' by selecting
the 'more useful' of the two type systems. The flip-side of 'helpful'
code is that it is usually inconsistent and confusing.

InstanceSpecification::classifier is actually a multi-classification
which presents another challenge for OCL for which there is only one
context type. Consideration of a similar problem for SMOF concluded that
the problem goes away by introducing oclTypes() to return all possible
classifications, and requiring oclAsType(XXX) to select a current
classification when there is an ambiguity.

A similar approach can solve the InstanceSpecification ambiguity. If a
new library operation OclElement::oclAsModelType(XXX) supports
conversion to a model-defined type XXX, which may be omitted if
unambiguous, we can write your constraint more compactly as:

let this = self.oclAsModelType() in this.Attribute1.oclType() =
this.Attribute2.oclType()

The default implementation of self.oclAsModelType() should return
invalid. For UML, an InstanceSpecification overload can select from the
modelled classifiers.

I don't think we need oclModelTypes(), oclIsModelKindOf() etc as
shortforms for oclAsModelType().oclType() etc.

If my solution metamodel constraint doesn't work, then that is yet
another demonstration of how 'helpful' code is not helpful at all. I'll
investigate.

Regards

Ed Willink


On 16/02/2016 21:48, Roberto Saltini wrote:
> Hi Ed,
>
> Thank you for your help.
>
> Is OCL intended to be used to express meta-model constraints only? From my understanding, OCL can be used to express model constraints as well. Am I wrong?
>
> Point 7.5,9 of the latest OCL spec, states that
> Quote:
>> The operation is oclIsTypeOf results in true if the type of self and t are the same. For example:
>> context Person
>> inv: self.oclIsTypeOf( Person ) -- is true
>> inv: self.oclIsTypeOf( Company) -- is false
>
> So it appears to me that OCL is intended to work with the model as well.
>
> ------------------------------
>
> Regarding your help for my specific problem:
> Quote:
>> If we stick to the metamodel level, the following works.
>> let a1 = self.slot->select(definingFeature.name =
>> 'Attribute1').value->any(true).oclAsType(InstanceValue) in
>> let a2 = self.slot->select(definingFeature.name =
>> 'Attribute2').value->any(true).oclAsType(InstanceValue) in
>> a1.instance.classifier = a2.instance.classifier
>
> This works if I type it in the Xtext OCL Console, but it does not work if I use it in a Constraint block associated to a specific class.
>
> I have attached the new project sample modified for you reference.
>
> ----
>
> Thanks,
> Roberto
Re: oclIsTypeOf() does not work as expected [message #1723701 is a reply to message #1723696] Wed, 17 February 2016 10:08 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

On 17/02/2016 09:36, Ed Willink wrote:
> we can write your constraint more compactly as:
>
> let this = self.oclAsModelType() in this.Attribute1.oclType() =
> this.Attribute2.oclType()
Not quite. We need more compile-time type information to correctly infer
the type of this.

let this = self.oclAsModelType(Class1) in this.Attribute1.oclType() =
this.Attribute2.oclType()

Regards

Ed Willink

On 17/02/2016 09:36, Ed Willink wrote:
> Hi
>
> OCL potentially works with any technology that provides classes with
> properties and operations. The philosophy of the Pivot-based Eclipse
> OCL is that the external technology is normalized by conversion to the
> internal pivot model. OCL works at any level, so M2 definitions in UML
> profiles can be evaluated for M1 instances, and M1 declarations can
> define functionality for M0 run-time evaluation.
>
> oclType() and related operations are defined for evaluation at M(n)
> using the types defined at M(n+1).
>
> The use of InstanceSpecification creates a confusion, since nominally
> M1 types describing M0 instances are instantiated in a nominally M1
> diagram.
>
> For InstanceSpecifications representing nominally M0 instances at M1
> we have a choice of two type systems, the normal M2 types or the
> modelled M1 types available via InstanceSpecification::classifier.
>
> Eclipse OCL has been bending over to try to be 'helpful' by selecting
> the 'more useful' of the two type systems. The flip-side of 'helpful'
> code is that it is usually inconsistent and confusing.
>
> InstanceSpecification::classifier is actually a multi-classification
> which presents another challenge for OCL for which there is only one
> context type. Consideration of a similar problem for SMOF concluded
> that the problem goes away by introducing oclTypes() to return all
> possible classifications, and requiring oclAsType(XXX) to select a
> current classification when there is an ambiguity.
>
> A similar approach can solve the InstanceSpecification ambiguity. If a
> new library operation OclElement::oclAsModelType(XXX) supports
> conversion to a model-defined type XXX, which may be omitted if
> unambiguous, we can write your constraint more compactly as:
>
> let this = self.oclAsModelType() in this.Attribute1.oclType() =
> this.Attribute2.oclType()
>
> The default implementation of self.oclAsModelType() should return
> invalid. For UML, an InstanceSpecification overload can select from
> the modelled classifiers.
>
> I don't think we need oclModelTypes(), oclIsModelKindOf() etc as
> shortforms for oclAsModelType().oclType() etc.
>
> If my solution metamodel constraint doesn't work, then that is yet
> another demonstration of how 'helpful' code is not helpful at all.
> I'll investigate.
>
> Regards
>
> Ed Willink
>
>
> On 16/02/2016 21:48, Roberto Saltini wrote:
>> Hi Ed,
>>
>> Thank you for your help.
>>
>> Is OCL intended to be used to express meta-model constraints only?
>> From my understanding, OCL can be used to express model constraints
>> as well. Am I wrong?
>>
>> Point 7.5,9 of the latest OCL spec, states that
>> Quote:
>>> The operation is oclIsTypeOf results in true if the type of self and
>>> t are the same. For example:
>>> context Person
>>> inv: self.oclIsTypeOf( Person ) -- is true
>>> inv: self.oclIsTypeOf( Company) -- is false
>>
>> So it appears to me that OCL is intended to work with the model as
>> well.
>>
>> ------------------------------
>>
>> Regarding your help for my specific problem:
>> Quote:
>>> If we stick to the metamodel level, the following works.
>>> let a1 = self.slot->select(definingFeature.name =
>>> 'Attribute1').value->any(true).oclAsType(InstanceValue) in
>>> let a2 = self.slot->select(definingFeature.name =
>>> 'Attribute2').value->any(true).oclAsType(InstanceValue) in
>>> a1.instance.classifier = a2.instance.classifier
>>
>> This works if I type it in the Xtext OCL Console, but it does not
>> work if I use it in a Constraint block associated to a specific class.
>>
>> I have attached the new project sample modified for you reference.
>>
>> ----
>>
>> Thanks,
>> Roberto
>
Re: oclIsTypeOf() does not work as expected [message #1723709 is a reply to message #1723696] Wed, 17 February 2016 10:39 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Roberto,

Interesting discussion you started Smile To make the problem/discussion more concrete from an end-user point-of-view (besides the interesting developers comments above), have a look at a variation of your 'original model' (see attached screenshot and example project.).

index.php/fa/25010/0/

You will probably notice that (with the "current" versions of the tooling), some things are hard to explain:
- The 'behavior' of Constraint2 and 3 probably makes sense to you (Constraint2 is reported to be violated, Constraint3 is not). This behaviour indeed 'makes sense' to everyone, but is not defined explicitly in the current specs.
- The behavior of Constraint1 didn't make sense to you (nor does it to me), and indeed it is not inline with the rest of the behaviour as currently implemented by the tooling. However, from a spec perspective, there is no problem since the spec is underdefined...

In case you have a lot of time, you might find the discussion at https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062 useful Smile

On a related matter, the mission of the just started Papyrus Industrial Consortium (https://polarsys.org/wiki/Papyrus_IC) states that

Quote:

The Papyrus IC is an open consortium that focuses on the development of a customizable and extensible industrial-grade open source model-based engineering tool suite based on the Papyrus/Eclipse platform, other key open source technologies, and leading industry standards (see Vision/Mission below).


I think your problem is a very concrete and useful example of where things go wrong on the last part of that sentence, and where users and developers should not put our heads into the sand and state: It's not in the spec, so we shouldn't implement this. (Shameless add: This said, you're welcome to join the consortium Smile ).

@Ed: Really appreciate the effort you put into this!


Re: oclIsTypeOf() does not work as expected [message #1723726 is a reply to message #1723709] Wed, 17 February 2016 11:20 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Klaas

I'm moderately confident that I now understand the problem and why what
Eclipse OCL offers for InstanceSpecification is so confusing.

I'm just adding the
OclElement::oclAsModelType/oclIsModelKindOf/oclModelType/oclModelTypes
library operations now.

They may not be the optimum spelling, but their arguments indicate that
the problem is not amenable to a simple solution such as a new "@"
navigation operator.

Do you have a feeling for how painful it would be to add oclAsModelType
to your existing usage? I'll try to support legacy stupidities with a
warning rather than failure, but preserving bad legacy is always hard.

Regards

Ed Willink


On 17/02/2016 10:39, Klaas Gadeyne wrote:
> Hi Roberto,
>
> Interesting discussion you started :) To make the problem/discussion more concrete from an end-user point-of-view (besides the interesting developers comments above), have a look at a variation of your 'original model' (see attached screenshot and example project.).
>
>
>
> You will probably notice that (with the "current" versions of the tooling), some things are hard to explain:
> - The 'behavior' of Constraint2 and 3 probably makes sense to you (Constraint2 is reported to be violated, Constraint3 is not). This behaviour indeed 'makes sense' to everyone, but is not defined explicitly in the current specs.
> - The behavior of Constraint1 didn't make sense to you (nor does it to me), and indeed it is not inline with the rest of the behaviour as currently implemented by the tooling. However, from a spec perspective, there is no problem since the spec is underdefined...
>
> In case you have a lot of time, you might find the discussion at https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062 useful :)
>
> On a related matter, the mission of the just started Papyrus Industrial Consortium (https://polarsys.org/wiki/Papyrus_IC) states that
>
> Quote:
>> The Papyrus IC is an open consortium that focuses on the development of a customizable and extensible industrial-grade open source model-based engineering tool suite based on the Papyrus/Eclipse platform, other key open source technologies, and leading industry standards (see Vision/Mission below).
>
> I think your problem is a very concrete and useful example of where things go wrong on the last part of that sentence, and where users and developers should not put our heads into the sand and state: It's not in the spec, so we shouldn't implement this. (Shameless add: This said, you're welcome to join the consortium :) ).
>
> @Ed: Really appreciate the effort you put into this!
>
>
>
Re: oclIsTypeOf() does not work as expected [message #1723746 is a reply to message #1723726] Wed, 17 February 2016 15:00 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

On 17/02/2016 11:20, Ed Willink wrote:
> Do you have a feeling for how painful it would be to add
> oclAsModelType to your existing usage? I'll try to support legacy
> stupidities with a warning rather than failure, but preserving bad
> legacy is always hard.
I don't think that there need to be any pain/bad legacy. The new
operations are all to support model-typed navigation from
InstanceSpecifications, most notably for InstanceSpecification
Constraints. This was probably totally unuseable before. Class
Constraints evaluated for InstanceSpecifications are unaffected.

Regards

Ed Willink


On 17/02/2016 11:20, Ed Willink wrote:
> Hi Klaas
>
> I'm moderately confident that I now understand the problem and why
> what Eclipse OCL offers for InstanceSpecification is so confusing.
>
> I'm just adding the
> OclElement::oclAsModelType/oclIsModelKindOf/oclModelType/oclModelTypes
> library operations now.
>
> They may not be the optimum spelling, but their arguments indicate
> that the problem is not amenable to a simple solution such as a new
> "@" navigation operator.
>
> Do you have a feeling for how painful it would be to add
> oclAsModelType to your existing usage? I'll try to support legacy
> stupidities with a warning rather than failure, but preserving bad
> legacy is always hard.
>
> Regards
>
> Ed Willink
>
>
> On 17/02/2016 10:39, Klaas Gadeyne wrote:
>> Hi Roberto,
>>
>> Interesting discussion you started :) To make the problem/discussion
>> more concrete from an end-user point-of-view (besides the interesting
>> developers comments above), have a look at a variation of your
>> 'original model' (see attached screenshot and example project.).
>>
>>
>>
>> You will probably notice that (with the "current" versions of the
>> tooling), some things are hard to explain:
>> - The 'behavior' of Constraint2 and 3 probably makes sense to you
>> (Constraint2 is reported to be violated, Constraint3 is not). This
>> behaviour indeed 'makes sense' to everyone, but is not defined
>> explicitly in the current specs.
>> - The behavior of Constraint1 didn't make sense to you (nor does it
>> to me), and indeed it is not inline with the rest of the behaviour as
>> currently implemented by the tooling. However, from a spec
>> perspective, there is no problem since the spec is underdefined...
>>
>> In case you have a lot of time, you might find the discussion at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=417062 useful :)
>>
>> On a related matter, the mission of the just started Papyrus
>> Industrial Consortium (https://polarsys.org/wiki/Papyrus_IC) states that
>>
>> Quote:
>>> The Papyrus IC is an open consortium that focuses on the development
>>> of a customizable and extensible industrial-grade open source
>>> model-based engineering tool suite based on the Papyrus/Eclipse
>>> platform, other key open source technologies, and leading industry
>>> standards (see Vision/Mission below).
>>
>> I think your problem is a very concrete and useful example of where
>> things go wrong on the last part of that sentence, and where users
>> and developers should not put our heads into the sand and state: It's
>> not in the spec, so we shouldn't implement this. (Shameless add:
>> This said, you're welcome to join the consortium :) ).
>>
>> @Ed: Really appreciate the effort you put into this!
>>
>>
>>
>
Re: oclIsTypeOf() does not work as expected [message #1723780 is a reply to message #1723746] Wed, 17 February 2016 21:10 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Ed,

(please only read on at a moment when you're well awake Wink )

Ed Willink wrote on Wed, 17 February 2016 10:00
Hi
On 17/02/2016 11:20, Ed Willink wrote:
> Do you have a feeling for how painful it would be to add
> oclAsModelType to your existing usage? I'll try to support legacy
> stupidities with a warning rather than failure, but preserving bad
> legacy is always hard.
I don't think that there need to be any pain/bad legacy. The new
operations are all to support model-typed navigation from
InstanceSpecifications, most notably for InstanceSpecification
Constraints. This was probably totally unuseable before. Class
Constraints evaluated for InstanceSpecifications are unaffected.
>


First, I have to specify that I never encountered this exact issue before myself, ie. I never came across a situation in which I added a constraint in a UML model in the context of a class, in which I used the oclIsTypeOf()/oclIsKindOf() operations. As such, I also had a closer look at the model from https://www.eclipse.org/forums/index.php?t=msg&th=1074705&goto=1723305&#msg_1723305

I found the constructs used in that model a bit 'unnatural': both cmH2O-PRESS and Pa-PRESS generalize PRESS, but in fact, they only differ in the sense that different stereotypes are applied to cmH2O-PRESS and Pa-PRESS. So I went to have a look at the SysML spec, but I didn't find a good answer in there (figure E.13 does specify the relationship between gram and kilogram, but only on a unit level, and I find no hints on what to do with the related Valuetypes in the spec [*].

However (now starts the interesting part), this particular annex of the SysML standard (QUDV) defines a model-library. As such, figure E.5 shows that the referenceUnit property points to the unit Class. As you could see in Roberto's original diagram, units in SysML models are (according to the spec) to be modeled as InstanceSpecifications. Now, have a look at constraint [1] on page 261. It states,

package QUDV
   context PrefixedUnit
   inv: not referenceUnit.oclIsTypeOf(PrefixedUnit)
   endpackage


If I interpret this correctly, this constraint does exactly the same as the one mentioned originally in this thread: i.e. it is defined in the context of a class, and it is meant to be evaluated on an instancespecification (a particular unit) . So, it seems like the spec at least implicitly acknowledges this particular form of constraint evaluation???. Moreover, looking at the rest of annex E, I wonder

  • who created the whole lot of OCL constraints present in annex E?
  • which tool he/she used to create/test these constraints (assuming it is impossible to do this without tool support)?


So, to summarize my thoughts:

  • From a modeling point of view, the person that specifies the OCL constraints, works in the context of a class, and hence the use of oclIsTypeOf() really makes sense, and the oclAsModelType() operation complicates matters. However, I repeat that I never encountered such a use case myself, so this might be only for specialists
  • From an evaluation perspective, I understand the difficulty tool builders face (and hence the reason for introducing a dedicated operation (oclAsModelType()), yet I wonder how other toolbuilders have solved this (if they did).


Do you also consider the oclAsModelType() operation as a 'workaround' until the OCL-evaluator is 'smart enough' to decide on the appropriate metalevel M1/M2 itself?

BR,

Klaas

[*] Note to self: yet another OMG issue to submit

Re: oclIsTypeOf() does not work as expected [message #1723838 is a reply to message #1723780] Thu, 18 February 2016 11:19 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Klaas

SysML QUDV was modeled by Nicolas Rouquette using OCLinEcore. He fired
some early attempts off to me, and

GIT\org.eclipse.ocl\tests\org.eclipse.ocl.examples.xtext.tests\model\SysML_ValueTypes_QUDV.ecore

is one of the Eclipse OCL regression test cases for Java code generation.

I don't how out of date the test case model is but we certainly got to a
no-problems state.

All this oclAsModelType stuff is need solely for the case of navigating
from an object of type InstanceSpecification where there is a
classification ambiguity. This is very rare; if I had realized how rare,
I would have kicked this problem off into the long grass, but since
we're nearly there, I'll finish it. NB Class constraints do not navigate
from an object of type InstanceSpecification; they navigate in the
disciplined world of Class instances and Properties.

The OCL parser will never be smart enough to distinguish M1/M2
automatically; certainly not for the pathological case of an
InstanceSpecification instantiating an InstanceSpecifcation. Some form
of explicit selection is needed. A Console menu option is bad since it
gets lost in alternative OCL contexts such as the debugger. An OCL
operation is good since it is there for all purposes. I see only
spelling to discuss.

The original problem is now solved by the Class invariant

self.Attribute1.oclModelTypes() = self.Attribute2.oclModelTypes()

which lifts the explicit solution for an InstanceSpecification

let a1 = self.slot->select(definingFeature.name =
'Attribute1').value->any(true).oclAsType(InstanceValue) in
let a2 = self.slot->select(definingFeature.name =
'Attribute2').value->any(true).oclAsType(InstanceValue) in
a1.instance.classifier = a2.instance.classifier

with all its Slots and InstanceValues into the abstract world of Class
instances with Properties.

Much confusion was caused on this thread by attempting to practice the
constraint in the OCL console with an InstanceSpecification of Class1
rather than an instance of Class1 as the prevailing selection. The
solution may be practised in the console by:

let this = self.oclAsModelType(Class) in
this.Attribute1.oclModelTypes() = this.Attribute2.oclModelTypes()

When validating the Class1 constraint the evaluator knows that it is
dealing with an instance of Class1. The console does not know this and
so needs to be told. There will be a suppressable popup information
message in the Console recommending the use of an "let this =
self.oclAsModelType" wrapper whenever the selection has non-null
oclModelTypes(). No mysterious menu pull-downs.

Regards

Ed Willink

On 17/02/2016 21:10, Klaas Gadeyne wrote:
> Hi Ed,
>
> (please only read on at a moment when you're well awake ;) )
>
> Ed Willink wrote on Wed, 17 February 2016 10:00
>> Hi
>> On 17/02/2016 11:20, Ed Willink wrote:
>> > Do you have a feeling for how painful it would be to add >
>> oclAsModelType to your existing usage? I'll try to support legacy >
>> stupidities with a warning rather than failure, but preserving bad >
>> legacy is always hard.
>> I don't think that there need to be any pain/bad legacy. The new
>> operations are all to support model-typed navigation from
>> InstanceSpecifications, most notably for InstanceSpecification
>> Constraints. This was probably totally unuseable before. Class
>> Constraints evaluated for InstanceSpecifications are unaffected.
>> >
>
>
> First, I have to specify that I never encountered this exact issue
> before myself, ie. I never came across a situation in which I added a
> constraint in a UML model in the context of a class, in which I used
> the oclIsTypeOf()/oclIsKindOf() operations. As such, I also had a
> closer look at the model from
> https://www.eclipse.org/forums/index.php?t=msg&th=1074705&goto=1723305&#msg_1723305
>
> I found the constructs used in that model a bit 'unnatural': both
> cmH2O-PRESS and Pa-PRESS generalize PRESS, but in fact, they only
> differ in the sense that different stereotypes are applied to
> cmH2O-PRESS and Pa-PRESS. So I went to have a look at the SysML spec,
> but I didn't find a good answer in there (figure E.13 does specify the
> relationship between gram and kilogram, but only on a unit level, and
> I find no hints on what to do with the related Valuetypes in the spec
> [*].
>
> However (now starts the interesting part), this particular annex of
> the SysML standard (QUDV) defines a model-library. As such, figure
> E.5 shows that the referenceUnit property points to the unit Class.
> As you could see in Roberto's original diagram, units in SysML models
> are (according to the spec) to be modeled as InstanceSpecifications.
> Now, have a look at constraint [1] on page 261. It states,
>
> package QUDV
> context PrefixedUnit
> inv: not referenceUnit.oclIsTypeOf(PrefixedUnit)
> endpackage
>
>
> If I interpret this correctly, this constraint does exactly the same
> as the one mentioned originally in this thread: i.e. it is defined in
> the context of a class, and it is meant to be evaluated on an
> instancespecification (a particular unit) . So, it seems like the
> spec at least implicitly acknowledges this particular form of
> constraint evaluation???. Moreover, looking at the rest of annex E, I
> wonder
>
> who created the whole lot of OCL constraints present in annex E?
> which tool he/she used to create/test these constraints (assuming it
> is impossible to do this without tool support)?
>
>
> So, to summarize my thoughts:
>
> From a modeling point of view, the person that specifies the OCL
> constraints, works in the context of a class, and hence the use of
> oclIsTypeOf() really makes sense, and the oclAsModelType() operation
> complicates matters. However, I repeat that I never encountered such
> a use case myself, so this might be only for specialists
> From an evaluation perspective, I understand the difficulty tool
> builders face (and hence the reason for introducing a dedicated
> operation (oclAsModelType()), yet I wonder how other toolbuilders have
> solved this (if they did).
>
>
> Do you also consider the oclAsModelType() operation as a 'workaround'
> until the OCL-evaluator is 'smart enough' to decide on the appropriate
> metalevel M1/M2 itself?
>
> BR,
>
> Klaas
>
> [*] Note to self: yet another OMG issue to submit
>
>
Previous Topic:How to customise the default appearance properties for graphical objects?
Next Topic:SVG presentation in diagrams
Goto Forum:
  


Current Time: Thu Mar 28 19:54:53 GMT 2024

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

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

Back to the top