Difference between revisions of "MDT-OCLTools"

From Eclipsepedia

Jump to: navigation, search
Line 1: Line 1:
== The MDT-OCLTools Project has closed.  This page has been locked and is for Archival purposes only. ==
+
''''The MDT-OCLTools Project has closed.  This page has been locked and is for Archival purposes only.''''
  
 
OCL Tools is a recently added component to the  
 
OCL Tools is a recently added component to the  

Revision as of 08:45, 9 October 2008

'The MDT-OCLTools Project has closed. This page has been locked and is for Archival purposes only.'

OCL Tools is a recently added component to the Model Development Tools (MDT) Project aiming at providing first-class support to modelers working with specifications containing expressions written in OCL, the Object Constraint Language. Such support includes editing, refactoring, code generation, execution, and interactive debugging of the OCL constraints given for some underlying (Ecore or UML2) class model. The functionality of OCL Tools builds upon the MDT OCL component, and has been seeded with two initial contributions:

  • an OCL -> Java compiler, that as of now takes as input an .ecore and a textual file containing OCL constraints (handling UML2 is in the ToDo list). This compiler extends EMF code generation, producing Java 5 source code with side-effects-free methods for the given OCL invariants, pre- and postconditions, and derived attributes and operations.
  • an OCL text editor, supporting usability features such as AutoCompletion, navigation by means of hyperlinks, structured views (for the outline of a document and for the Abstract Syntax Tree of an OCL constraint), among others. Although MDT OCL itself is completely fluent in both Ecore and UML2, only the Ecore binding is supported by the OCL text editor at this time.

A longer intro to OCL Tools can be found in the draft article being reviewed for publication at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=204701


Contents

OCL Compiler

What it does

In a nutshell, the compiler translates expressions like that in Listing 1 into what is shown in Listing 2:

context LoyaltyAccount
	inv invariant_points :
		self . points > 0
		implies self.transactions->exists ( t | t.points > 0 )
Listing 1 An OCL Invariant
public boolean invariant_points () {
	Boolean implies1 = ( this . getPoints () > 0);
	if (!( implies1 )) {
		implies1 = Boolean . TRUE ;
	} else {
		Boolean exists2 = false ;
		for ( RandL . Transaction t :
		org.eclipse.ocl.util.CollectionUtil.asSet ( this . getTransactions ())) {
				if (!exists2 ) {
					exists2 = (t.getPoints () > 0);
				}
		}
		implies1 = exists2 ;
	}
	return implies1 ;
}
Listing 2 LoyaltyAccount's invariant_points translated into Java



How to use it

Step 1: Prepare an .ocl file

Figure 1(a) Start situation


Step 2: Invoke the compiler

Figure 1(b) Invoking the compiler by right-clicking on the .ecore file

The compiler works ...

Figure 1(c) The compiler works ...

Step 3: Java code is ready

Figure 1(d) End result


How to install

OCL Tools is known to apply to the following versions:


User Community

In order to foster the evolution of OCL Tools, user input is important. If you're using OCL Tools, please add yourself to this list, as a first step towards building a community. Literature reflecting best-practices is also welcome (and somewhat scarce as of now :-)

Fernando Silva Parreiras http://www.fernando.parreiras.nom.br/
Abdelouahed Gherbi http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/g/Gherbi:Abdelouahed.html


Best Practices

FAQ: Frequently Anticipated Questions

I invoke the compiler but no code gets generated. What can I do?

The OCL compiler should generate code when invoked with both

    <yourFileName>.ecore
    <yourFileName>.ocl

on the same folder. Moreover, the .ocl file should be of the form

    package <packageName>
    
    context <myClass>
    ...
    
    endpackage 

There is guidance about that in the exampled co-delivered with the source code, in plugin

de.tuhh.sts.ocl.example.royalandloyal

If all else fails, actually the shortest way to see why the compiled Java does not end up in .java files is to place a breakpoint at method

    public void compile(IFile ecoreFile, IProgressMonitor monitor)

in class OCLCompiler in plugin de.tuhh.sts.ocl.compiler.emf.compiler

Actually, that's where the action is. The rest is just glue code so that those generated methods bodies are woven as part of EMF code generation (which generates method signatures, class skeletons, etc.)

The JET templates co-delivered with the OCL compiler override some hooks in the JET templates of EMF CodeGen, and when those templates change the hooks might not be there any more. For a discussion of this and what to do about it, take a look at:

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01379.html

OCL Text Editor

The big picture of the editor is:

OCLTools oclEditor screenshots.png

Features supported

Among others, it supports the following:

Syntax highlighting

AutoEdit 1

Auto-completion of closing brace

AutoEdit 2

Upon typing a colon : and pressing Enter. A new indented line will be added, letting the cursor ready for typing the body of the OCL expression.

Bracket matching

Content Assist

OCLTools content assist.png

Current line highlighting and Show range indicator

Text Folding

Templates, customizable through Preference pages

File:OCLTools editor preference page.png


Problem and Warning markers, "red squigglies"

OCLTools problem markers.png


Outline view

OCL AST View

OCLTools oclASTView.png

Related Links