details

Details

The Meta Model

The implementation of the OCL meta model orients itself strongly at NSUML and develops in large parts on it. NSUML is the version of the UML meta model implemented by Novosoft in Java. We tried as far as possible to take over the design decisions of the specification, that's why the description of the entire OCL meta model isn't given here. Information of the OCL meta model can be found in the specification. Like the abstract syntax, the OCL meta model is divided into two main packages - the types and the expressions package. The following information is given to the individual packages and the differences to the specification.

de.tuberlin.tfs.ocl.metamodel.types
corresponds to the types package, see part 3.2 in specification
There are no differences.
class diagram: OCLMetamodelTypes
de.tuberlin.tfs.ocl.metamodel.expressions
corresponds to the expressions package, see part 3.3 in specification
The MOclConstraint and MOclConstraintImpl are additional to the specification.
Each OclExpression is part of an OclExpression or it is part of an OclConstraint.
If you want to build a metamodel, you have to start with the OclConstraint and set an expression as its body. Then you have to choose an MOclConstraintKind. (DEF, INV, PRE, POST).
class diagrams: OCLMetamodelExpressionPackage, OCLMetamodelPropertyCallExp, OCLMetamodelMessageExp

Things it can do:

hold an OCL meta model in local memory
convert a complete OCL meta model in an OCL string

Things it cannot do but should do in the future:

Import/export of an OCL meta model from/to XMI

The Converter

According to the OCL meta model, we have written the converter in Java. With Java, we could use the capabilities of inheritance and polymorphy to build a simple and comprehensive code.
The conversion process starts with an object of class "OclConstraint" which contains the whole expression in an object tree. The OCL converter analyses the attributes of each found object and applies a method called "convert2OclString()" on them. These children of the current object have attributes by themselves that are processed and so on. Thus, a string is constructed which contains the original OCL constraint that hides within the object tree.
As described before, each OCL meta model element owns a method called "convert2OclString()", so we can use dynamic binding to apply this method on every model element without exactly knowing which of them has a reference with the current object.
Additionally, there exists a class OclConverter that cares about the administration during a conversion process. You can e.g. set a debug mode for additional message output. Besides, the OclConverter checks if the necessary attributes are present and throws an exception if not (this feature is maybe very useful for programmers who design OCL editors).
Please click here to view an UML class diagram of the OclConverter class.

Packages:

de.tuberlin.tfs.ocl.metamodel.converter
de.tuberlin.tfs.ocl.metamodel.dummys

Some specifications:

version: 1.0
language: Java (with English comments)
conversion methods by: Sven Tappeser

Tests

Additionally, we have made a package for the tests. These tests can be used as an example for the construction of an OCL meta model or the usage of the converter.

Packages:

de.tuberlin.tfs.ocl.metamodel.test