Eclipse Community Forums: OCL » Custom static operation

Help

Home

Home » Modeling » OCL » Custom static operation

Show: Today's Messages :: Show Polls :: Message Navigator

Custom static operation [message #1754757]

Wed, 22 February 2017 05:39

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

Hi

Here is the sample model:

<?xml version="1.0" encoding="UTF-8"?>
<uml:Model xmi:version="20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xmi:id="_yBv74N48EeaBrOB63Eenfw" name="test">
  <packageImport xmi:id="_yBv74t48EeaBrOB63Eenfw">
    <importedPackage xmi:type="uml:Model" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/>
  </packageImport>
  <packagedElement xmi:type="uml:Class" xmi:id="_0BeX8N48EeaBrOB63Eenfw" name="Person">
    <ownedRule xmi:id="_Ze9tIN49EeaBrOB63Eenfw" name="rule1" constrainedElement="_0BeX8N48EeaBrOB63Eenfw">
      <specification xmi:type="uml:OpaqueExpression" xmi:id="_Ze-7QN49EeaBrOB63Eenfw">
        <language>OCL</language>
        <body>Person.isFound('John')</body>
      </specification>
    </ownedRule>
    <ownedOperation xmi:id="_6vP3gN48EeaBrOB63Eenfw" name="isFound" isStatic="true" isQuery="true">
      <ownedParameter xmi:id="_EJpVYN49EeaBrOB63Eenfw" name="name">
        <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>
      </ownedParameter>
      <ownedParameter xmi:id="_EMM6IN49EeaBrOB63Eenfw" name="result" direction="return">
        <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Boolean"/>
      </ownedParameter>
    </ownedOperation>
  </packagedElement>
</uml:Model>

The class Person has static operation isFound. I open Xtext OCL console and write the following expressions:

Evaluating:
test::Person.isFound('John')
Results:
Parsing failure

1: Unresolved Static Operation 'test::Person::isFound('John')'

Why is the operation unresolved?

Evaluating:
test::Person::isFound('John')
Results:
Failed to evaluate 'test::Person::isFound(String[1]) : Boolean[1]' for 'Person' and 'self.isFound('John')'
java.lang.UnsupportedOperationException

The operation isn't implemented so I get the exception. But why is the operation interpreted as non-static 'self.isFound('John')'?

Report message to a moderator

Re: Custom static operation [message #1754758 is a reply to message #1754757]

Wed, 22 February 2017 05:43

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

I don't need to execute the operation. I need only to parse the expression and to get OCL AST. So I don't implement the operation.

Report message to a moderator

Re: Custom static operation [message #1754775 is a reply to message #1754758]

Wed, 22 February 2017 09:49

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

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

Regards

Ed Willink

Report message to a moderator

Re: Custom static operation [message #1756455 is a reply to message #1754775]

Fri, 17 March 2017 07:54

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

Hi

Thanks! It is works!

I can refer to a static operation:

Evaluating:
test::Person.isFound('John')
Results:
Failed to evaluate 'test::Person::isFound(String[1]) : Boolean[1]' for 'Person' and 'test::Person.isFound('John')'
java.lang.UnsupportedOperationException

Note, that I use a dot symbol between 'Person' and 'isFound'. Can I use a double colon instead? OCL interpreter tells me: "Failed to evaluate 'test::Person::isFound..." It uses a double colon before operation name.

But when I use a double colon, I get the error:

Evaluating:
test::Person::isFound('John')
Results:
Parsing failure

1: Unresolved Operation '::isFound('John')'

Also I have to specify a package name explicitly. Otherwise I get the error:

Evaluating:
Person.isFound('John')
Results:
Parsing failure

1: Unresolved Property '::Person'

Are the two latter cases prohibited?

Report message to a moderator

Re: Custom static operation [message #1756456 is a reply to message #1756455]

Fri, 17 March 2017 07:59

Denis Nikiforov

Messages: 344
Registered: August 2013

Senior Member

I guess according to the section 7.5.10 of the OCL specification I must use a double colon symbol for static operations instead of a dot.

Report message to a moderator

Re: Custom static operation [message #1756460 is a reply to message #1756456]

Fri, 17 March 2017 09:21

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

7.5.10 is where most of the resolution of Issue 8937 was incorporated. Unfortunately the OCL 2.1/2.2 RTF report is not available to non-OMG members, so the text is appended below.

The specific issue of "::" and "." is clear. "::" means locate a name statically in a namespace, "." means navigate to the value of a name in an object, perhaps using a dynamic run-time mechanism.

I think what you observe is consistent with this.

(I do not find the application to allInstances() convincing, since either allInstances() must be both a static and a non-static operation to allow aPerson.allInstances() as well as Person.allInstances(), unless there is a magic reification of Person by a class object. In /org.eclipse.ocl.pivot/model/OCL-2.5.oclstdlib, allInstances is modelled as a static operation. In similar fashion to Java, static features of objects can be accessed dynamically.)

Regards

Ed Willink

Disposition: Resolved
OMG Issue No: 8937
Title: Notation for accessing class operations is
inconsistent
Source:
International Business Machines (Dr. Tracy Gardner, <<email redacted>>)
Summary:
The OCL 2.0 spec is inconsistent on whether class operations, including
predefined operations, should be accessed using '.' or '::' notation.
E.g. should it be Person.allInstances() or Person::allInstances()
The spec uses Person.allInstances() in the text, but the concrete
syntax specifies '::'.
It seems that most tools have adopted the '.' notation used in the
examples which is also backwards compatible with previous versions of
OCL.
There has also been some adoption of the '::' notation, for example in
Warmer and Kleppe's OCL book, see:
http://www.klasse.nl/english/boeken/ocl-book-errata.pdf
Note: This issue was originally pointed out by Anthony Shuttleworth of
Paranor.
Proposed solution:
The '.' notation is widely used and backwards compatible with previous
versions of OCL. It should not be made invalid in OCL 2.0.
It may be appropriate to also support the '::' notation if this has
been widely adopted.
Discussion:
Accessing static features using '::' is unambiguously an invocation of a static property and not a property of
the Classifier metaclass. OCL's TypeExp is, effectively, a Classifier literal expression, so that the '.'
operator should invoke features of the Classifier metaclass. An example of this is allInstances(), which is
inherited from OclAny (which Classifier implicitly specializes) or allFeatures() (from UML).
The OCL text is updated to clarify that allInstances() is not a static operation
Revised Text:
Update Section 7.5.10 "Features on Classes Themselves" to provide an example of a static operation on
Employee and to clarify that allInstances() is not a static operation:
All properties discussed until now in OCL are properties on instances of classes. The types are
either predefined in OCL or defined in the class model. In OCL, it is also possible to use static
features, applicable to the types/classes themselves rather than to their instances. For example, the
Employee class may define a static operation "uniqueID" that computes a unique ID to use in the
initialization of the employee ID attribute:
context Employee::id : String init:
Employee::uniqueID()
Static features are invoked using the '::' operator and are distinct from the features of the Classifier
metaclass, which include the allInstances operation pre-defined by OCL. If we want to make sure
that all instances of Person have unique names, we can write:
context Person inv:
Person.allInstances()->forAll(p1, p2 |
p1 <> p2 implies p1.name <> p2.name)
Invocation of allInstances uses the '.' operator rather than '::' because it is not a static operation. It
is an operation applicable to instances of the Classifier metaclass, of which Person is an example.
Disposition: Resolved

Report message to a moderator