Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Possible problems with implicit properties of Stereotypes
Possible problems with implicit properties of Stereotypes [message #1759300] Mon, 10 April 2017 11:33 Go to next message
Alexander Kraas is currently offline Alexander KraasFriend
Messages: 9
Registered: March 2015
Junior Member
Hello OCL community,

I have encountered some problems with implicit properties ('extension_'Stereotype_name' and 'base_'metaclass_name') of Stereotypes for navigating from a UML element instance to a Stereotype instance. I have created a simple test Profile and a tiny UML model to reproduce the encountered proplems. Maybe, someone could give me feedback, if the below mentioned issues are problems of the Pivot-OCL implementation of Eclipse.

Many thanks in advance,
Alexander

The Package 'Package' in My.uml contains a Class named 'TClass' and an Interface named 'TInterface'. Both elements have the <<Test>> Stereotype of the 'TestProfile' profile applied. Since this stereotype extends the UML metaclasses 'Class' as well as 'Interface'. When an instance of UML Class is extended, the implicit properties 'extension_Test' and 'base_Class' shall be present in OCL to navigate from the Class instance to the <<Test>> instance and vice versa. In contrast, for an Interface instance, the implicit properties 'extension_Test' and 'base_Interface' shall be present. However, when I try to use this implicit properties in the Xtext OCL console, I have encountered the following issues:
1. Open the file My.uml file with the default UML tree-style editor
2. Open the Xtext OCL console
3. Select the UML Class "TClass" in My.uml and enter the following OCL expressions in the OCL console:
Evaluating:
self.extension_Test.base_Class
Results:
Package::TClass [OK!]

Evaluating:
self.extension_Test.base_Interface
Results:
Package::TClass [Expected: null]
4. Select the UML Interface "TInterface" in My.uml and enter the following OCL expression in the OCL console:
Evaluating:
self.extension_Test.base_Interface
Results:
Parsing failure

1: Ambiguous resolution:
Property : UML::Interface::extension_Test # TestProfile::Test::base_Interface
Property : UML::Class::extension_Test # TestProfile::Test::base_Class

Report message to a moderator

Re: Possible problems with implicit properties of Stereotypes [message #1759312 is a reply to message #1759300] Mon, 10 April 2017 13:08 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Thanks for the repro. I see the same in my workspace and agree with your expectations.

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

Regards

Ed Willink

Report message to a moderator

Re: Possible problems with implicit properties of Stereotypes [message #1759319 is a reply to message #1759312] Mon, 10 April 2017 14:02 Go to previous messageGo to next message
Alexander Kraas is currently offline Alexander KraasFriend
Messages: 9
Registered: March 2015
Junior Member
Hi Ed,

I have taken a look to the bug created by you. In my point of view, the heading of the bug is too restrictive, because the raised issue does not only concern the UML Class and Interface metaclasses that are extended by the same Stereotype, because you could also extend another UML metaclass, e.g., DataType, and the same issues as reported by me araise.

Regards,
Alexander

Report message to a moderator

Re: Possible problems with implicit properties of Stereotypes [message #1763610 is a reply to message #1759319] Wed, 17 May 2017 18:58 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

This proves to be a remarkably troublesome issue demonstrating that when a profile adds a Property to a Class at M2, it should not be adding a Property to a Class at M1 or M3. A probably 99.9% workaround fix is to ignore an ambiguity with a base_Class opposite. The correct fix requires maintenance of independent M1, M2, M3 type systems, which will be good in the long run, but a painful ripple probably with nasty API consequences. Therefore not an option to do now for Oxygen.

The workaround fix is available at http://www.eclipse.org/modeling/download.php?file=/modeling/mdt/ocl/downloads/drops/6.3.0/N201705160733/mdt-ocl-Update-N201705160733.zip

Regards

Ed Willink

Report message to a moderator

Previous Topic:IllegalStateException on plain vanilla install of OCL
Next Topic:Negation of OCL expressions
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Apr 26 01:27:25 GMT 2024

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly