Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [UML profiles] Expressing constraints on abstract stereotypes
[UML profiles] Expressing constraints on abstract stereotypes [message #1346692] Sat, 10 May 2014 18:53 Go to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi,

In attach you can find a UML model + profile that consists of an abstract stereotype, 2 generalizations of the abstract stereotypes and another one specializing the UML::Realization meta-element.

In the profile, I try to express the constraint that, in the case of a ParentRealization relationship, the supplier should be part of the children property of the client.

However, I don't succeed in formulating the constraint, and validating the model results in two "invalid results"

Error	The 'ParentRealization::tmpConstraint' constraint result is invalid for 'Parent Realization -> <<ParentRealization>> <Realization> Realization1'
 - Attempt to navigate from null to 'abstractStereotype.profile.uml.oclas::Profile::Parent::children'	<<ParentRealization>> <Realization> Realization1	Model	EMF Problem


I interpreted this as
self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)

would result in null.

However, this seems somewhat contradictory with the fact that the "The client of the Realization should be stereotyped using ClassParent" invariant is validated successfully.

Also, when I select the stereotyped UML::Realization in the model and try to debug using the OCL xtext console, I get the following
Evaluating:
self.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent
Results:
Parsing failure

1: Ambiguous resolution:
	Property : UML::Classifier.extension_Parent
	Property : UML::Classifier.extension_Parent

Evaluating:
self.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)
Results:
Parsing failure

1: Ambiguous resolution:
	Property : UML::Classifier.extension_Parent
	Property : UML::Classifier.extension_Parent
1: Unresolved Property 'OclInvalid::ClassParent'


So I wonder, should I use other OCL constructs in order to formulate these invariants, or is there a problem with the tooling?

TIA,

Klaas

[tooling: M6 platform, M7 modeling features or better, ocl nightly build]
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1350236 is a reply to message #1346692] Mon, 12 May 2014 15:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Validation of the profile ensures that the OCL contained in the profile
is syntactically valid; it does not guarantee that it will be free from
run-time problems (i.e. that all M1 diagrams are unconditionally valid).

Therefore I think the message

Attempt to navigate from null to 'abstractStereotype.profile.uml.oclas::Profile::Parent::children'

is an accurate indication of an 'NPE' half way through

self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent).children->isEmpty()
= false

You must handle the possibility that

self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)

is null to avoid the 'NPE'. OCL 2.5 may introduce .? for you.

(The klunky "abstractStereotype.profile.uml.oclas::" prefix can be
improved.)

(Calling your top level models Profile and Model may be good for testing
scope resolution but it results in very confusing error messages.)

---

The ambiguous

Property : UML::Classifier.extension_Parent

is definitely wrong.

Originally UML2Pivot largely ignored UML Extension properties and
synthesized them itself. One of the changes last month was to use UML
much more as-is, so I suspect that UML-as-is and UML-synthesis have
produced a pair of results that are either different or not filtered as
duplicates.

---

Rather than

self.children->notEmpty() implies self.children->excludes(self)

you might prefer just

self.children->excludes(self)

or even the arbitrary depth check

self.children->closure(children)->excludes(self)

Regards

Ed Willink

On 10/05/2014 19:53, Klaas Gadeyne wrote:
> Hi,
>
> In attach you can find a UML model + profile that consists of an abstract stereotype, 2 generalizations of the abstract stereotypes and another one specializing the UML::Realization meta-element.
>
> In the profile, I try to express the constraint that, in the case of a ParentRealization relationship, the supplier should be part of the children property of the client.
>
> However, I don't succeed in formulating the constraint, and validating the model results in two "invalid results"
>
>
> Error The 'ParentRealization::tmpConstraint' constraint result is invalid for 'Parent Realization -> <<ParentRealization>> <Realization> Realization1'
> - Attempt to navigate from null to 'abstractStereotype.profile.uml.oclas::Profile::Parent::children' <<ParentRealization>> <Realization> Realization1 Model EMF Problem
>
>
> I interpreted this as
>
> self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)
>
> would result in null.
>
> However, this seems somewhat contradictory with the fact that the "The client of the Realization should be stereotyped using ClassParent" invariant is validated successfully.
>
> Also, when I select the stereotyped UML::Realization in the model and try to debug using the OCL xtext console, I get the following
>
> Evaluating:
> self.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent
> Results:
> Parsing failure
>
> 1: Ambiguous resolution:
> Property : UML::Classifier.extension_Parent
> Property : UML::Classifier.extension_Parent
>
> Evaluating:
> self.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)
> Results:
> Parsing failure
>
> 1: Ambiguous resolution:
> Property : UML::Classifier.extension_Parent
> Property : UML::Classifier.extension_Parent
> 1: Unresolved Property 'OclInvalid::ClassParent'
>
>
> So I wonder, should I use other OCL constructs in order to formulate these invariants, or is there a problem with the tooling?
>
> TIA,
>
> Klaas
>
> [tooling: M6 platform, M7 modeling features or better, ocl nightly build]
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1350567 is a reply to message #1350236] Mon, 12 May 2014 18:29 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, 12 May 2014 11:10
Hi

Validation of the profile ensures that the OCL contained in the profile
is syntactically valid; it does not guarantee that it will be free from
run-time problems (i.e. that all M1 diagrams are unconditionally valid).

Therefore I think the message

Attempt to navigate from null to 'abstractStereotype.profile.uml.oclas::Profile::Parent::children'

is an accurate indication of an 'NPE' half way through

self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent).children->isEmpty()
= false

You must handle the possibility that

self.base_Realization.client->asOrderedSet()->first().oclAsType(Classifier).extension_Parent.oclAsType(ClassParent)

is null to avoid the 'NPE'. OCL 2.5 may introduce .? for you.

(The klunky "abstractStereotype.profile.uml.oclas::" prefix can be
improved.)

(Calling your top level models Profile and Model may be good for testing
scope resolution but it results in very confusing error messages.)


Thx! I realised most of this, but I had forgotten that null.oclIsInvalid() is perfectly legal and just returns false Sad
As you can see in the "updated" version of the attachment, it is the call to extension_Parent on Class1 that returns null when validating.

Quote:

Warning The 'ParentRealization::Check if extension is set' constraint is violated for 'Parent Realization -> <<ParentRealization>> <Realization> Realization1' <<ParentRealization>> <Realization> Realization1 ParentModel EMF Problem


However, I get a different (=contradictory) result when typing the following in the xtext consoled (Class1 being selected)

Evaluating:
self.extension_Parent
Results:
Class1$ClassParent


Do I overlook something, or is this a bug?

Quote:

---

The ambiguous

Property : UML::Classifier.extension_Parent

is definitely wrong.

Originally UML2Pivot largely ignored UML Extension properties and
synthesized them itself. One of the changes last month was to use UML
much more as-is, so I suspect that UML-as-is and UML-synthesis have
produced a pair of results that are either different or not filtered as
duplicates.


Is that "wrong" as in "a bug"?

Thx,

Klaas
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1350626 is a reply to message #1350567] Mon, 12 May 2014 19:01 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
On 12/05/2014 19:29, Klaas Gadeyne wrote:
> Is that "wrong" as in "a bug"? Thx, Klaas
Yes.

I am very far from done with this example.

Regards

Ed
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1366364 is a reply to message #1350626] Mon, 19 May 2014 09:21 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi<br>
<br>
The extension_XXX navigation was totally broken.<br>
<br>
Recent changes have meant that M1 evaluation has migrated from a
Pivot representation of the UML model to the UML representation,
which has the major benefit that only the M2 model need incur the
UML to Pivot conversion cost. However Eclipse UML2 has no API to
reify the stereotype instance/element extension as an EObject.
I've remedied this with a new UMLElementExtension and your
examples now seem to work much better.<br>
<br>
You can see the fix now in:<br>
<br>
<a class="moz-txt-link-freetext" href="https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/lastSuccessfulBuild/artifact/MDT-OCL.downloads/mdt-ocl-Update-core-201405190446.zip">https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/lastSuccessfulBuild/artifact/MDT-OCL.downloads/mdt-ocl-Update-core-201405190446.zip</a><br>
<br>
or an N-build shortly, or RC1 this evening.<br>
<br>
(The attached *.UML has some more robust/elegant OCL.)<br>
<br>
<img src="//www.eclipse.org/forums/index.php?t=getfile&amp;id=18102" alt=""><br>
<br>
has a missing 'NPE' guard and uses any(true) rather than
asOrderedSet()-&gt;first()<br>
<br>
<br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink<br>
<br>
On 12/05/2014 20:01, Ed Willink wrote:<br>
</div>
<blockquote cite="mid:lkr5qc$snf$1@xxxxxxxxe.org" type="cite">On
12/05/2014 19:29, Klaas Gadeyne wrote:
<br>
<blockquote type="cite">Is that "wrong" as in "a bug"? Thx, Klaas
</blockquote>
Yes.
<br>
<br>
I am very far from done with this example.
<br>
<br>
&nbsp;&nbsp;&nbsp; Regards
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ed
<br>
</blockquote>
<br>
</body>
</html>
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1368699 is a reply to message #1366364] Tue, 20 May 2014 08:29 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Ed Willink wrote on Mon, 19 May 2014 05:21

The extension_XXX navigation was totally broken.

Recent changes have meant that M1 evaluation has migrated from a
Pivot representation of the UML model to the UML representation,
which has the major benefit that only the M2 model need incur the
UML to Pivot conversion cost. However Eclipse UML2 has no API to
reify the stereotype instance/element extension as an EObject.
I've remedied this with a new UMLElementExtension and your
examples now seem to work much better.

You can see the fix now in:

https://hudson.eclipse.org/ocl/job/buckminster-ocl-branch-tests/lastSuccessfulBuild/artifact/MDT-OCL.downloads/mdt-ocl-Update-core-201405190446.zip

or an N-build shortly, or RC1 this evening.

(The attached *.UML has some more robust/elegant OCL. Has a missing 'NPE' guard and uses any(true) rather than
asOrderedSet()->first()


Thx Ed! It has definitely improved! However, when validating the constraints against the original model, the 2 non-trivial constraints in the model are said to be violated.

For the "In case of a ParentRealization relationship, the supplier should be a child of the client" constraint, there was still an error in it, in the sense that the 'children' property of the Parent extension points to stereotype instances, and not base meta-model elements (see new version of the profile.uml file as attached to this post for a "fix").

However, even with this "fix", both constraints still report to be violated. When trying to debug this, I noticed that
* In the validity view I still get "invalid" results (one complaining about "unresolved properties", another about "uninitialized variables")
* In the xtext console, I still get the ambiguous resolution error (or even worse: unpredictable behaviour, but I cannot reproduce this consistently yet Sad

Did I now miss some OCL semantics and are these violations the intended behaviour (or are there still some problems left to be tackled? Smile

Thx,

Klaas
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1368847 is a reply to message #1368699] Tue, 20 May 2014 09:50 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

On 20/05/2014 09:30, Klaas Gadeyne wrote:
> Thx Ed! It has definitely improved! However, when validating the constraints against the original model, the 2 non-trivial constraints in the model are said to be violated.
Good, but we may not be quite there yet ... Another couple of weeks
still available for bugging fixing for Luna.
> For the "In case of a ParentRealization relationship, the supplier should be a child of the client" constraint, there was still an error in it, in the sense that the 'children' property of the Parent extension points to stereotype instances, and not base meta-model elements (see new version of the profile.uml file as attached to this post for a "fix").
I got some slightly inconsistent results, but eventually dismissed them
as due to confusion between various versions that you had supplied and
also some that I had improved.

I felt that the residual violations were real.
>
> However, even with this "fix", both constraints still report to be violated. When trying to debug this, I noticed that
In RC1, if you drill down to the constraint-modelElement (most easily in
the RH pane of the Validity View) you can then launch an OCL debugger
from the context menu!

(Or when practicing your OCL in the Xtext console, you can use the Debug
Toolbar icon)

If you start another debug session, close the previous *.ocl editor.

Regards

Ed
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1371783 is a reply to message #1368847] Wed, 21 May 2014 14:40 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Ed Willink wrote on Tue, 20 May 2014 05:50
Hi
I felt that the residual violations were real.

[snip]
Quote:

In RC1, if you drill down to the constraint-modelElement (most easily in
the RH pane of the Validity View) you can then launch an OCL debugger
from the context menu!

(Or when practicing your OCL in the Xtext console, you can use the Debug
Toolbar icon)

If you start another debug session, close the previous *.ocl editor.


Hmm, I wasn't to successful in using it. I could find how to check which extensions are set for a given class (the extension attribute is always empty??).

However, I think I might have discovered a problem (unless my OCL skills are still lacking Sad. Check the model and profile in attach

This is what I get in the xtext console when <<vStereotype2>> Class2 of the model file is selected

Evaluating:
self.extension_VirtualStereotype.oclIsKindOf(profile::vStereotype2)
Results:
false


Shouldn't this result in true?

[Updated on: Wed, 21 May 2014 14:50]

Report message to a moderator

Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1384973 is a reply to message #1371783] Tue, 03 June 2014 12:19 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
[quote title=Klaas Gadeyne wrote on Wed, 21 May 2014 10:40]Ed Willink wrote on Tue, 20 May 2014 05:50


[snip]

However, I think I might have discovered a problem (unless my OCL skills are still lacking Sad. Check the model and profile in attach

This is what I get in the xtext console when <<vStereotype2>> Class2 of the model file is selected

Evaluating:
self.extension_VirtualStereotype.oclIsKindOf(profile::vStereotype2)
Results:
false


Shouldn't this result in true?



This particular issue seems to be solved somehow using the latests nightly builds (sometimes weird stuff still happens, but when starting from a "fresh" xtext console" the results are now as expected)
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1384981 is a reply to message #1384973] Tue, 03 June 2014 13:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Good. I've certainly done work in this area with extra unit tests. I've
still got a backlog of old emails to revisit. Getting the OCL debugger
into Luna was a high priority. Now refreshing the documentation. Then
catching up ... rest ...

I doubt that anything that affects UML has changed since RC1. Certainly
there are very very unlikely to be any changes other than the
documentation now that RC3 is done.

Regards

Ed Willink


On 03/06/2014 13:19, Klaas Gadeyne wrote:
> [quote title=Klaas Gadeyne wrote on Wed, 21 May 2014 10:40]Ed Willink
> wrote on Tue, 20 May 2014 05:50
>> [snip]
>>
>> However, I think I might have discovered a problem (unless my OCL
>> skills are still lacking :(. Check the model and profile in attach
>>
>> This is what I get in the xtext console when <<vStereotype2>> Class2
>> of the model file is selected
>>
>>
>> Evaluating:
>> self.extension_VirtualStereotype.oclIsKindOf(profile::vStereotype2)
>> Results:
>> false
>>
>>
>> Shouldn't this result in true?
>
>
> This particular issue seems to be solved somehow using the latests
> nightly builds (sometimes weird stuff still happens, but when starting
> from a "fresh" xtext console" the results are now as expected)
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1387101 is a reply to message #1384981] Tue, 24 June 2014 06:45 Go to previous message
Klaas Gadeyne is currently offline Klaas GadeyneFriend
Messages: 165
Registered: July 2009
Senior Member
Hi Ed,

Now that 5.0.1 RC1 is out, this was time to debug a little bit further on this. Please consider the model and profile in attach.

When selecting Class1 in the model file and executing the following code in the xtext console I get

Evaluating:
self.extension_Parent
Results:
Class1$ClassParent

Evaluating:
self.extension_Parent.children->any(true)
Results:
«InterfaceParent»ParentModel::Interface1


To me, conceptually, both results are stereotype instances, so I had estimated that the result would be formatted in a similar way. Yet they are represented differently, so I guess they also _are_ inherently different.

What can/should I do to "convert" one result into the other?

[Background: I guess this is the root cause why the constraint "In case of a ParentRealization relationship, the supplier should be a child of the client" reports a violation.]
Previous Topic:OCLinEcoreTutorial - standalone
Next Topic:Announcing Eclipse OCL 5.0.0 and 5.0.1 for Luna
Goto Forum:
  


Current Time: Tue Mar 19 02:24:04 GMT 2024

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

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

Back to the top