Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Problem using OCLType in stereotype invariant
Problem using OCLType in stereotype invariant [message #1279159] Fri, 28 March 2014 10:08 Go to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi,

The attachment to this post contains
- a UML profile with a stereotype (Stereotype1) that generalizes a virtual stereotype that extends UML::NamedElement. A constraint ensures that Stereotype1 can only be applied to UML Properties instead of all NamedElements
- a Simple UML model to which this profile is applied.

When validating MySubPropertyModel.uml from within the UML2 model editor, the validation (unfortunately) reports that constraint1 is violated.

However, when evaluating the following expression in the xtext console
self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid()


the expression returns false as expected.

Did I overlook something very obvious here?

Tooling info:
Luna M6, OCL from nightly build update site:

OCL Unified SDK: Parsers,Evaluator,Editors,Tools 3.4.0.v20140322-1654 org.eclipse.ocl.examples.unified.feature.group Eclipse Modeling Project

org.eclipse.ocl.examples.pivot 3.4.0.v20140310-1427


Re: Problem using OCLType in stereotype invariant [message #1280563 is a reply to message #1279159] Sun, 30 March 2014 14:55 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Amongst other problems, not all of the
http://www.eclipse.org/uml2/4.0.0/UML registrations have been upgraded
to support http://www.eclipse.org/uml2/5.0.0/UML as well.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=397508#c17.

You might get on a bit better by hand-editing the XML to
http://www.eclipse.org/uml2/4.0.0/UML.

Regards

Ed Willink

On 28/03/2014 10:08, Klaas Gadeyne wrote:
> Hi,
>
> The attachment to this post contains
> - a UML profile with a stereotype (Stereotype1) that generalizes a virtual stereotype that extends UML::NamedElement. A constraint ensures that Stereotype1 can only be applied to UML Properties instead of all NamedElements
> - a Simple UML model to which this profile is applied.
>
> When validating MySubPropertyModel.uml from within the UML2 model editor, the validation (unfortunately) reports that constraint1 is violated.
>
> However, when evaluating the following expression in the xtext console
>
> self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid()
>
>
> the expression returns false as expected.
>
> Did I overlook something very obvious here?
>
> Tooling info:
> Luna M6, OCL from nightly build update site:
>
> OCL Unified SDK: Parsers,Evaluator,Editors,Tools 3.4.0.v20140322-1654 org.eclipse.ocl.examples.unified.feature.group Eclipse Modeling Project
>
> org.eclipse.ocl.examples.pivot 3.4.0.v20140310-1427
>
>
>
Re: Problem using OCLType in stereotype invariant [message #1280660 is a reply to message #1280563] Sun, 30 March 2014 18:42 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hmm, it seems like things get a bit worse instead when I replace UML 5.0.0 with 4.0.0 Smile

I now run into an delegateException...

org.eclipse.ocl.ecore.delegate.OCLDelegateException: Unrecognized variable: (Property)
at org.eclipse.ocl.ecore.delegate.InvocationBehavior.getOperationBody(InvocationBehavior.java:125)
at org.eclipse.ocl.ecore.delegate.OCLValidationDelegate.validate(OCLValidationDelegate.java:96)
at org.eclipse.ocl.ecore.delegate.OCLValidationDelegateFactory.validate(OCLValidationDelegateFactory.java:87)
at org.eclipse.ocl.common.internal.delegate.OCLValidationDelegateMapping.validate(OCLValidationDelegateMapping.java:77)
at org.eclipse.emf.ecore.util.EObjectValidator.validate(EObjectValidator.java:194)
at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validateDelegatedInvariants(EObjectValidator.java:1371)
at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validate(EObjectValidator.java:1410)
at org.eclipse.emf.ecore.util.EObjectValidator.validate(EObjectValidator.java:333)
at org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:171)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:158)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.validate(UMLActionBarContributor.java:884)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.doValidateStereotypeApplications(UMLActionBarContributor.java:852)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.doValidateContents(UMLActionBarContributor.java:868)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.validate(UMLActionBarContributor.java:884)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:181)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.doValidateContents(UMLActionBarContributor.java:873)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction$1.validate(UMLActionBarContributor.java:884)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:108)
at org.eclipse.uml2.uml.editor.presentation.UMLActionBarContributor$UMLValidateAction.validate(UMLActionBarContributor.java:892)
at org.eclipse.emf.edit.ui.action.ValidateAction$1.run(ValidateAction.java:176)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Caused by: org.eclipse.ocl.SemanticException: Unrecognized variable: (Property)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:358)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:328)
at org.eclipse.ocl.internal.helper.HelperUtil.checkForErrors(HelperUtil.java:518)
at org.eclipse.ocl.internal.helper.HelperUtil.parseBodyCondition(HelperUtil.java:285)
at org.eclipse.ocl.internal.helper.OCLHelperImpl.createBodyCondition(OCLHelperImpl.java:261)
at org.eclipse.ocl.ecore.OCLHelperImpl.createBodyCondition(OCLHelperImpl.java:60)
at org.eclipse.ocl.ecore.OCLHelperImpl.createBodyCondition(OCLHelperImpl.java:1)
at org.eclipse.ocl.ecore.delegate.InvocationBehavior.getOperationBody(InvocationBehavior.java:123)
... 25 more
Re: Problem using OCLType in stereotype invariant [message #1281143 is a reply to message #1279159] Mon, 31 March 2014 12:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Your virtual stereotype has isRequired = false (ExtensionEnd.lower = 0)
and so the virtual stereotype is not automatically applied and so it
does not provide the required navigation.

See UML 2.5 p270 ProfileApplication para2, p285 /isRequired.

I will promote your example with and without fixes into a JUnit test.

While debugging I notice that UML2Pivot ignores ProfileApplication and
so even with isRequired=true, it probably won't work.

Thank you for your patience and interesting examples.

Regards

Ed Willink


On 28/03/2014 10:08, Klaas Gadeyne wrote:
> Hi,
>
> The attachment to this post contains
> - a UML profile with a stereotype (Stereotype1) that generalizes a virtual stereotype that extends UML::NamedElement. A constraint ensures that Stereotype1 can only be applied to UML Properties instead of all NamedElements
> - a Simple UML model to which this profile is applied.
>
> When validating MySubPropertyModel.uml from within the UML2 model editor, the validation (unfortunately) reports that constraint1 is violated.
>
> However, when evaluating the following expression in the xtext console
>
> self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid()
>
>
> the expression returns false as expected.
>
> Did I overlook something very obvious here?
>
> Tooling info:
> Luna M6, OCL from nightly build update site:
>
> OCL Unified SDK: Parsers,Evaluator,Editors,Tools 3.4.0.v20140322-1654 org.eclipse.ocl.examples.unified.feature.group Eclipse Modeling Project
>
> org.eclipse.ocl.examples.pivot 3.4.0.v20140310-1427
>
>
>
Re: Problem using OCLType in stereotype invariant [message #1281202 is a reply to message #1281143] Mon, 31 March 2014 14:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Watch

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

for progress on this example.

Regards

Ed Willink

On 31/03/2014 13:27, Ed Willink wrote:
> Hi
>
> Your virtual stereotype has isRequired = false (ExtensionEnd.lower =
> 0) and so the virtual stereotype is not automatically applied and so
> it does not provide the required navigation.
>
> See UML 2.5 p270 ProfileApplication para2, p285 /isRequired.
>
> I will promote your example with and without fixes into a JUnit test.
>
> While debugging I notice that UML2Pivot ignores ProfileApplication and
> so even with isRequired=true, it probably won't work.
>
> Thank you for your patience and interesting examples.
>
> Regards
>
> Ed Willink
>
>
> On 28/03/2014 10:08, Klaas Gadeyne wrote:
>> Hi,
>>
>> The attachment to this post contains
>> - a UML profile with a stereotype (Stereotype1) that generalizes a
>> virtual stereotype that extends UML::NamedElement. A constraint
>> ensures that Stereotype1 can only be applied to UML Properties
>> instead of all NamedElements
>> - a Simple UML model to which this profile is applied.
>>
>> When validating MySubPropertyModel.uml from within the UML2 model
>> editor, the validation (unfortunately) reports that constraint1 is
>> violated.
>>
>> However, when evaluating the following expression in the xtext console
>>
>> self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid()
>>
>>
>>
>> the expression returns false as expected.
>>
>> Did I overlook something very obvious here?
>>
>> Tooling info:
>> Luna M6, OCL from nightly build update site:
>>
>> OCL Unified SDK: Parsers,Evaluator,Editors,Tools
>> 3.4.0.v20140322-1654
>> org.eclipse.ocl.examples.unified.feature.group Eclipse Modeling
>> Project
>> org.eclipse.ocl.examples.pivot 3.4.0.v20140310-1427
>>
>>
>>
>
Re: Problem using OCLType in stereotype invariant [message #1281707 is a reply to message #1281143] Tue, 01 April 2014 08:36 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Ed,

Ed Willink wrote on Mon, 31 March 2014 08:27
Hi

Your virtual stereotype has isRequired = false (ExtensionEnd.lower = 0)
and so the virtual stereotype is not automatically applied


I was aware of this (and in this case, I declared isRequired to be false intentionally)

Quote:

and so it does not provide the required navigation.

See UML 2.5 p270 ProfileApplication para2, p285 /isRequired.


I don't understand this (consequence) though. Maybe I misunderstood what you mean with "navigation" in the above sentence. Rereading the UML spec, I also didn't find new insights regarding my understanding of isRequired.

If I look at the constraint in the profile (the one that, on the model level, does not evaluate as I expect)
self.base_NamedElement.oclAsType(Property).oclIsInvalid() = false

I would state that it navigates from the stereotype to the metaclass, and not the other way around, so the multiplicity of the extensionEnd doesn't even matter?

Of course, in the OCL expression in the OCL console (ie. evaluated on the model which has the profile applied)
self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid() 


I do navigate from the (instance of the) base class towards the stereotype, but this expression evaluates false as expected.

Regards,

Klaas
Re: Problem using OCLType in stereotype invariant [message #1281735 is a reply to message #1281707] Tue, 01 April 2014 09:27 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The Pivot OCL representation reifies the stereotype application in an
ElementExtension object.

Currently (Luna M6) UNML2Pivot creates one for each of the explicit
weird root XMI objects.

My reading of ExtensionEnd lowerBound > 0 is that this is an implicit
stereotype application and so an ElementExtension should be created for
these as well.

In your example this would ensure that vStereotype1 was applied to
NamedElement and would provide the Property and target for
self.base_NamedElement.

I'm adding this missing functionality (and transitive
ProfileApplications) right now.

----

not oclIsKindOf(Property) is simpler, clearer and quicker than
oclAsType(Property).oclIsInvalid()

perhaps even

self.extension->forAll(base.oclIsKindOf(Property))

Regards

Ed Willink

On 01/04/2014 09:36, Klaas Gadeyne wrote:
> Hi Ed,
>
> Ed Willink wrote on Mon, 31 March 2014 08:27
>> Hi
>>
>> Your virtual stereotype has isRequired = false (ExtensionEnd.lower =
>> 0) and so the virtual stereotype is not automatically applied
>
>
> I was aware of this (and in this case, I declared isRequired to be
> false intentionally)
>
> Quote:
>> and so it does not provide the required navigation.
>>
>> See UML 2.5 p270 ProfileApplication para2, p285 /isRequired.
>
>
> I don't understand this (consequence) though. Maybe I misunderstood
> what you mean with "navigation" in the above sentence. Rereading the
> UML spec, I also didn't find new insights regarding my understanding
> of isRequired.
>
> If I look at the constraint in the profile (the one that, on the model
> level, does not evaluate as I expect)
>
> self.base_NamedElement.oclAsType(Property).oclIsInvalid() = false
>
> I would state that it navigates from the stereotype to the metaclass,
> and not the other way around, so the multiplicity of the extensionEnd
> doesn't even matter?
>
> Of course, in the OCL expression in the OCL console (ie. evaluated on
> the model which has the profile applied)
>
> self.extension->asOrderedSet()->first().base.oclAsType(Property).oclIsInvalid()
>
>
> I do navigate from the (instance of the) base class towards the
> stereotype, but this expression evaluates false as expected.
>
> Regards,
>
> Klaas
Previous Topic:mdt/ocl or emf query/ocl?
Next Topic:mdt/ocl context-free ocl condition
Goto Forum:
  


Current Time: Fri Mar 29 14:23:40 GMT 2024

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

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

Back to the top