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 |
Klaas Gadeyne 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 |
Ed Willink 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 #1368699 is a reply to message #1366364] |
Tue, 20 May 2014 08:29 |
Klaas Gadeyne 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
Did I now miss some OCL semantics and are these violations the intended behaviour (or are there still some problems left to be tackled?
Thx,
Klaas
|
|
|
Re: [UML profiles] Expressing constraints on abstract stereotypes [message #1368847 is a reply to message #1368699] |
Tue, 20 May 2014 09:50 |
Ed Willink 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
|
|
| | | | |
Goto Forum:
Current Time: Tue Mar 19 02:24:04 GMT 2024
Powered by FUDForum. Page generated in 0.02021 seconds
|