Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

ATL Standard Library

< To: ATL

The ATL standard library consists of the types built into ATL and of their operations. It is based on the OCL 2.0 standard library as described in chapter 11 of the UML 2.0 OCL Final Adopted specification. However, some extensions have been made (see ATL_FAQ#How_close_is_ATL_navigation_language_from_the_OCL_2.0_standard.3F).

This page describes how the ATL standard library is implemented in the three ATL Virtual Machines (VMs) available from Eclipse.org.


EMF VM Implementation

In EMFVM, the ATL standard library is mostly implemented in the ExecEnv Java class. Most types are not wrapped, and Java objects are used directly in many cases.

Some EMF-specific operations (or operations that have an EMF-specific part) are implemented in EMFModelAdapter

EMFTVM Implementation

In EMFTVM, the ATL standard library is implemented in classes of the org.eclipse.m2m.atl.emftvm.util package.

Most operations on concrete collections are implemented in the corresponding Java classes: LazyBag, LazyList, LazyOrderedSet, and LazySet respectively for OCL collection types Bag, Sequence, OrderedSet, and Set. Other operations (e.g., operations on primitive types, operations on the Collection abstract type) are implemented in the OCLOperations Java class.

Regular VM Implementation

In the Regular VM, Java objects are wrapped by specific objects (instances of subclasses of ASMOclAny). In the description that follows, for each type T a CVS link is given to the Java class implementing T in the Regular ATL virtual machine. In each class, operations available from the ATL language (as opposed to implementation-specific methods) are represented as Java methods located below the following comment:

 // Native Operations Below

In some of these classes, there are two additional comments delimiting:

  • Operations specified by OCL 2.0:
 // OCL Operations
  • Operations added in ATL:
 // Additional Operations

All of these Java classes are located in the org.atl.engine.vm.nativelib package, except for the model-handler-specific classes linked to in the Model Elements section.

When the description given here is not complete enough, it is possible to go and read the Java implementation. This way, it is possible to know, for instance: the list of available operations and their semantics (e.g. operation String.regexReplaceAll(a : String, b : String) is implemented in ASMString using java.lang.String.replaceAll(String a, String b)).


Primitive Types

Boolean

The Boolean OCL type is implemented by the ASMBoolean (deprecated version) Java class. The underlying Java type is boolean.

Integer

The Integer OCL type is implemented by the ASMInteger (deprecated version) Java class. The underlying Java type is int.

Real

The Real OCL type is implemented by the ASMReal (deprecated version) Java class. The underlying Java type is double.

String

The String OCL type is implemented by the ASMString (deprecated version) Java class. The underlying Java type is java.lang.String.

Collection Types

Collection

The Collection OCL type is implemented by the ASMCollection (deprecated version) Java class. There is no underlying Java type for this abstract type. However, all concrete collection types are implemented by sub-classes of java.util.Collection.

Bag

The Bag OCL type is implemented by the ASMBag (deprecated version) Java class. The underlying Java type is java.util.ArrayList.

OrderedSet

The OrderedSet OCL type is implemented by the ASMOrderedSet (deprecated version) Java class. The underlying Java type is java.util.LinkedHashSet.

Sequence

The Sequence OCL type is implemented by the ASMSequence (deprecated version) Java class. The underlying Java type is java.util.ArrayList.

Set

The Set OCL type is implemented by the ASMSet (deprecated version) Java class. The underlying Java type is java.util.HashSet.

Model Elements

Model elements are handled as a special case in a model-handler-specific way.

EMF-specific

These operations are implemented in ASMEMFModelElement:

  • EClass.allInstances()
  • EClass.allInstancesFrom(String)
  • EClassifier.newInstance()
  • EClassifier.newInstanceIn(String)
  • EClassifier.getInstanceById(String, String)

Additionally, ATL will look for a called operation in the underlying EObject using Java reflection. This makes many operations (i.e., those for which type translation is implemented for arguments and returned value) from Ecore, as well as from a specific implementation of EObject available.

MDR-specific

These operations are implemented in ASMMDRModelElement:

  • Classifier.allInstances()
  • Classifier.allInstancesFrom(String)
  • Classifier.newInstance()
  • Classifier.getElementById(String, OclAny)
  • Classifier.getElementsById(String, OclAny)

In addition, a few MOF-specific operations are made available, but other operations are generally not available (there is no similar mechanism to what is supported in the EMF-specific version described above):

  • GeneralizableElement.findElementsByTypeExtended(ModelElement, Boolean)
  • GeneralizableElement.lookupElementExtended(String)
  • AssociationEnd.otherEnd()

Additional Types

The types described in this section are not part of the OCL 2.0 specification.

Map

The Map OCL type is implemented by the ASMMap (deprecated version) Java class. The underlying Java type is java.util.HashMap.

In the Bytecode Files (.asm)

Types are encoded using a scheme described in the Javadoc of class ASMInterpreter. This type encoding is also implemented at the beginning of the ATL compiler.

Back to the top