Ecore Abstract Syntax supports the use of OCL embedded within EAnnotations.
The OCLinEcore language provides a textual Concrete Syntax that makes both Ecore and OCL accessible to users. Examples may be found in OCLinEcore Library Metamodel and OCLinEcore Helpers.
The OCLinEcore tooling provides a rich editing environment based on Xtext with strong semantic checking.
OCLinEcore is more than just an editor for OCL in Ecore, it is useful for
-
providing a coherent textual view of an Ecore meta-model
-
providing syntax sugar for some Ecore conventions
-
editing and validating OCL
-
integrating OCL into Ecore
It is planned to take the syntactic sugar further and provide full support for all class-related UML concepts. The language therefore uses UML as its point of reference wherever possible.
The OCLinEcore tooling may be used directly on *.ecore files, or on their *.oclinecore textual counterparts.
Please follow the OCLinEcore tutorial for an introduction to the language and its tooling.
The OCLinEcore syntax has a consistent structure influenced by the informal definitions in OMG specifications and by the Ecore hierarchy. Most Ecore concepts are represented by a syntax of the form:
-
optional primary adjectives
-
mandatory keyword
-
mandatory name facet
-
further facets
-
an optional braced clause of secondary adjectives
-
an optional braced clause of elements
-
composed elements
-
annotations
-
constraints
-
Thus in:
abstract class Example extends Base { interface } { ... }
-
abstractis a primary adjective -
classis a keyword -
Exampleis the name facet -
extends Baseis a further facet -
{ interface }supports the secondary interface adjective. -
{ ... }provides a nested context for class content.
The grammar used by the Xtext editors may be found at:
/src/org/eclipse/ocl/examples/xtext/oclinecore/OCLinEcore.xtext
in the org.eclipse.ocl.xtext.oclinecore plugin. The OCLinEcore grammar extends the Essential OCL grammar.
The Module syntax supports the overall structure of an Ecore file
The definition of the module comprises
-
optional module declaration
-
optional specification of the OCL Standard libraries
-
optional import of referenced Ecore or UML or OCLinEcore resources
-
a hierarchy of Packages
Zero or more external libraries may be imported so that their definitions are merged to form a composite library of basic and extended evaluation capability.
The implicit import of the default OCL Standard Library is suppressed, if any library is imported. The default library may be extended by specifying it as the first library import.
library ocl : 'http://www.eclipse.org/ocl/3.1.0/OCL.oclstdlib'
The namespace URI of the first library package defines the namespace URI of the composite library. The namespace URI of subsequent library imports may not conflict, but may be null.
Zero or more external metamodels may be imported.
The Package syntax supports a nested hierarchy of packages and classifiers
A Package has a name and optionally a namespace prefix and namespace URI.
The content of a Package may comprise Packages, Classifiers and Annotations.
The Classifier syntax supports the definition of types within a Package.
A Classifier may be
-
a Class
-
a DataType
-
an Enumeration with associated EnumerationLiterals
The DataType syntax supports the definition of an EDataType.
A DataType has a name and optionally template parameters and an instance class name.
A DataType may be serializable; by default it is not.
The content of a DataType may comprise invariants and Annotations.
The Enumeration syntax supports the definition of an EEnum.
An Enumeration has a name and optionally template parameters and an instance class name.
An Enumeration may be serializable; by default it is not.
The content of an Enumeration may comprise enumeration literals, invariants and Annotations.
The EnumerationLiteral syntax supports the definition of an EEnumLiteral.
An EnumerationLiteral has a name and optionally a value.
The content of an EnumerationLiteral may comprise Annotations.
The Class syntax supports the definition of an EClass.
-
optional abstract prefix
-
optional extension of other classifiers
-
optional invariants, annotations, features and operations
A Class may be abstract has a name and optionally template parameters.
(NB, the ‘abstract’ prefix is optional, even though the figure indicates that it is mandatory.)
A Class may extend one or more other Classes that may be specialized using the template parameters.
A Class may have an instance class name, and may also be declared to be an interface.
The content of a Class may comprise Annotations, Operations, StructuralFeatures and invariants.
The StructuralFeature syntax supports the definition of the StructuralFeatures.
A StructuralFeature may be
The Attribute syntax supports the definition of an EAttribute; a Property with a DataType value.
An Attribute may be static and has a name.
The
static qualifier supports declaration of static properties which are supported by UML and OCL. Note that Ecore does not support static properties.
The
definition qualifier is an obsolete experimental syntax for Complete OCL definitions.
An Attribute may may have a Type and multiplicity.
An Attribute may a simple initializer and a variety of qualifiers:
-
derivedspecifies a derived attribute (default!derived) -
idspecifies that the attribute provides the identifier if its class (default!id) -
orderedspecifies that the attribute elements are ordered (default!ordered) -
readonlyspecifies that the attribute elements are readonly (not changeable) (default!readonly) -
transientspecifies that the attribute elements are computed on the fly (default!transient) -
uniquespecifies that there are no duplicate attribute elements (defaultunique) -
unsettablespecifies that attribute element may have no value (default!unsettable) -
volatilespecifies that the attribute elements are not persisted (default!volatile)
The content of an Attribute may comprise Annotations, initial and derived constraints.
A simple constant value may be defined using the initializer. A computed value requires the use of a constraint. If both initial and derived constraints are present, the initial constraint is ignored.
The defaults for multiplicity lower and upper bound and for
ordered and
unique follow the UML specification and so corresponds to a single element Set that is
[1] {unique,!ordered}.
Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
[?] {ordered,unique}.
The Reference syntax supports the definition of an EReference; a Property with a Class value.
An Reference may be static and has a name and optionally an opposite name.
The
static qualifier supports declaration of static properties which are supported by UML and OCL. Note that Ecore does not support static properties.
The
definition qualifier is an obsolete experimental syntax for Complete OCL definitions.
A Reference may may have a Type and multiplicity.
A Reference may a simple initializer and a variety of qualifiers:
-
composesspecifies a composed (containing) reference (default!composes) -
derivedspecifies a derived reference (default!derived) -
orderedspecifies that the reference elements are ordered (default!ordered) -
readonlyspecifies that the reference elements are readonly (not changeable) (default!readonly) -
resolvespecifies that the reference elements proxies may need resolution (default!resolve) -
transientspecifies that the reference elements are computed on the fly (default!transient) -
uniquespecifies that there are no duplicate reference elements (defaultunique) -
unsettablespecifies that reference element may have no value (default!unsettable) -
volatilespecifies that the reference elements are not persisted (default!volatile)
The content of a Reference may comprise keys, Annotations, initial and derived constraints.
A simple constant value may be defined using the initializer. A computed value requires the use of a constraint. If both initial and derived constraints are present, the initial constraint is ignored.
The defaults for multiplicity lower and upper bound and for
ordered and
unique follow the UML specification and so corresponds to a single element Set that is
[1] {unique,!ordered}.
Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
[?] {ordered,unique}.
The Operation syntax supports the definition of an EOperation.
An Operation may be static and has a name and optionally template parameters.
The
static qualifier supports declaration of static operations which are supported by UML and OCL. Note that Ecore does not support static operations.
The
definition qualifier is an obsolete experimental syntax for Complete OCL definitions.
An Operation has zero of more Parameters.
An Operation may have a return Type and multiplicity.
An Operation may declare zero or more throw Exceptions.
An Operation may have a variety of qualifiers:
-
derivedspecifies a derived operation (default!derived) -
orderedspecifies that the returned elements are ordered (default!ordered) -
uniquespecifies that there are no duplicate returned elements (defaultunique)
The content of an Operation may comprise Annotations, precondition, postcondition and body constraints.
The
static qualifier supports declaration of static operations which are supported by UML and OCL. Note that Ecore does not support static operations.
The
definition qualifier is an obsolete experimental syntax for Complete OCL definitions.
The defaults for multiplicity lower and upper bound and for
ordered and
unique follow the UML specification and so corresponds to a single element Set that is
[1] {unique,!ordered}.
Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
[?] {ordered,unique}.
The Parameter syntax supports the definition of an EParameter.
A Parameter has a name, optional "Type:#OCLinEcore-TypeRef and multiplicity
A Parameter may have a variety of qualifiers:
-
orderedspecifies that the returned elements are ordered (default!ordered) -
uniquespecifies that there are no duplicate returned elements (defaultunique)
The content of a Parameter may comprise Annotations.
The defaults for multiplicity lower and upper bound and for
ordered and
unique follow the UML specification and so corresponds to a single element Set that is
[1] {unique,!ordered}.
Note that UML defaults differ from the Ecore defaults which correspond to an optional element OrderedSet, that is
[?] {ordered,unique}.
The Type syntax supports the definition of EType and EGenericType in conjunction with an ETypedElement. The syntax is very similar to Java.
PrimitiveTypeRefCS provides access to the built-in OCL types and their corrersponding Ecore counterparts
| OCL type | Ecore type |
|---|---|
| Boolean | EBoolean |
| Integer | EBigInteger |
| Real | EBigDecimal |
| String | EString |
| UnlimitedNatural | EBigInteger |
TypedTypeRefCS provides for user defined types and their template parameterisation.
The AnnotationElement syntax supports the definition of an EAnnotation hierarchy with details, references and contents.
An AnnotationElement may be Annotation or Documentation.
The Annotation syntax supports the definition of an EAnnotation hierarchy with details, references and contents.
An Annotation has a source URI, which may be specified without quotes if the URI is just a name.
An Annotation may have Details.
The content of an Annotation may comprise
-
content elements
-
names that reference other elements
The Detail syntax supports the definition of a detail of an EAnnotation.
A detail comprises a detail key and optional value.
The Documentation syntax is an experimental syntactic sugar for a genmodel annotation.
It is likely to be replaced by a Javadoc-style comment that will be persisted in Ecore.
The Constraints syntax supports the embedding of OCL expressions as invariants for classes, as preconditions, postconditions or bodies for operations and initial or derived values for properties.
The integration occurs through the SpecificationCS rule that invokes an ExpCS. (The alternative UnquotedString is an implementation detail that supports the import from Ecore where the OCL is in unparsed textual form rather than an analyzed syntax tree.)
A class invariant may be
callable to specify that the Ecore representation is to use the EOperation rather than EAnnotation representation.
A class invariant optionally supports a second OCL expression as a parenthesis on the invariant name. This parenthesized expression is invoked when an invariant fails in order to provide a user-defined failure message. Whether this message is an error or a warning is determined by the evaluation of the invariant:
The OCLinEcore grammar extens the Esstial OCL grammar which should be consulted for definition of INT, and ExpCS.
An Unrestricted name is any name other than the OCL reserved keywords. See UnrestrictedName.
An Unreserved name is any name other than the OCL reserved keywords above or the OCL reserved types. See UnreservedName.
If you need to use any of these names or non-alphanumeric names, you must use the escaped string syntax for a name: e.g.
_'true'. The usual Java backslash escapes, with the exception of octal are supported:
_'new-lines\n\x0a\u000a'
OCLinEcore supports the full capabilities of Ecore, however the support for upper and lower bounds on generic types has not been adequately tested.
OCLinEcore provides primary syntaxes for some Ecore conventions such as genmodel annotations and constraints; much more support is needed for feature maps.