14. OCL in Ecore #

We are going to extend our Ecore model with OCL constraints.

Hint: You may start from this project (steps 1-8).

14.1 Installation #

Install OCL support for Ecore models via the Help > Install New Software…​ menu entry in Eclipse. Filter for “ocl” and select the OCL Classic SDK: Ecore/UML Parsers… and the OCL Examples and Editors SDK.

These packages do not come with Eclipse Modeling Tools and need to be installed manually.

14.2 OCLinEcore Editor #

So far we have seen a graphical view of Ecore models (in the class diagram editor) and a tree-like view of Ecore models in the *.ecore and *.genmodel files. We will now see a textual view of the same Ecore model. We use a new editor called OCLinEcore.

Right click on the file webpage.ecore and select ** **.

This might ask you whether you want to convert the project to an OCL project and you should click [Yes].

The new editor shows classes in the Ecore model in textual format. You can edit elements here, if you want.

14.3 Adding OCL Invariants #

We will add a new OCL invariant. To add it in the context of class Web we place it into the body of the class (this is slightly different from OMG OCL where we would declare the context using keyword context). Add the invariant text

invariant atLeastOnePage: pages->size() > 1;

This creates an invariant with name atLeastOnePage in the context of class Web. It already demonstrates navigation (along the composition to class Webpage via rolename pages), aggregation using OCL operation size(), and comparison operators “<”.

We can add a further invariant uniqueNames in the same class with navigation, access to attributes and comparison:

class Web
{
    attribute keywords : String[?];
    attribute description : String[?];
    attribute name : String[?];
    attribute title : String[?];
    property pages : Webpage[*|1] { ordered composes };
    
    invariant atLeastOnePage: pages->size() > 1;
    invariant uniqueNames: pages.name->asSet()->size() = pages->size();
}

WARNING: After adding any OCL invariants, changes in the Class Diagram editor might lead to exceptions. In these cases, either comment out the OCL or do the CD changes in the OCLinEcore editor (the syntax is simple and your CD will be updated automatically).

14.4 Dynamic Instances and Validation #

We have written OCL invariants to check the validity of instances (i.e., object diagrams). One way of creating instances is using the generated editor from Sect. 5. Another way that does not require us to start a second Eclipse is to use the Dynamic Instance Editor of EMF.

From the OCLinEcore editor you can click on a class, right click and select Create Dynamic Instance…

This will let you save the file as XMI and show an editor similar to the one in Sect. 5.4. You can create instances of the classes and set their attributes. The editor will show you the OCL constraints as markers in the editor.

We can validate the instance by right clicking and selecting Validate:

This will show validation results. Currently above the OCL invariant atLeastOnePage is violated.

After adding two children of type Webpage we get a different violation:

We did not set the names of the Webpage objects to be unique. We can do that and validate again:

Now all invariants are satisfied, and we can save the instance.

Markers of constraint violations will remain until you validate manually.

WARNING: “name” appears to have a meaning in OCLinEcore and comparing attributes with name “name” leads to strange error messages. Avoid these attribute names (we have them in all classes…).