Home » Modeling » Papyrus » oclIsTypeOf() does not work as expected
|
Re: oclIsTypeOf() does not work as expected [message #1723168 is a reply to message #1723148] |
Fri, 12 February 2016 10:02 |
Ed Willink Messages: 7670 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 #1723395 is a reply to message #1723343] |
Mon, 15 February 2016 11:30 |
Ed Willink Messages: 7670 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 #1723491 is a reply to message #1723475] |
Tue, 16 February 2016 07:41 |
Ed Willink Messages: 7670 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 |
Ed Willink Messages: 7670 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 #1723696 is a reply to message #1723632] |
Wed, 17 February 2016 09:36 |
Ed Willink Messages: 7670 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 |
Ed Willink Messages: 7670 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 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
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 #1723726 is a reply to message #1723709] |
Wed, 17 February 2016 11:20 |
Ed Willink Messages: 7670 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 |
Ed Willink Messages: 7670 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 |
Klaas Gadeyne Messages: 165 Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
(please only read on at a moment when you're well awake )
Ed Willink wrote on Wed, 17 February 2016 10:00Hi
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 |
Ed Willink Messages: 7670 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
>
>
|
|
|
Goto Forum:
Current Time: Thu Sep 26 01:48:49 GMT 2024
Powered by FUDForum. Page generated in 0.07161 seconds
|