Difference between revisions of "MDT-OCLTools"

From Eclipsepedia

Jump to: navigation, search
m (OCLTools moved to MDT-OCLTools)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== What's inside ==
+
'''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  
Line 99: Line 99:
  
 
[[Image:OCLTools_oclcompiler04.PNG|<b>Figure 1(d)</b> End result]]
 
[[Image:OCLTools_oclcompiler04.PNG|<b>Figure 1(d)</b> End result]]
 +
 +
 +
=== How to install ===
 +
 +
OCL Tools is known to apply to the following versions:
 +
 +
<ul>
 +
 +
<li>
 +
  [http://download.eclipse.org/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php Eclipse Classic 3.3]
 +
</li>
 +
 +
<li>
 +
  [http://archive.eclipse.org/modeling/emf/emf/downloads/drops/2.3.1/R200709252135/ EMF SDK 2.3.1]
 +
</li>
 +
 +
<li>
 +
  [http://archive.eclipse.org/modeling/mdt/ocl/downloads/drops/1.1.1/R200709121604/ OCL SDK 1.1.1]
 +
</li>
 +
</ul>
 +
 +
 +
== 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 :-)
 +
 +
<table align="center" border="1" cellpadding="2">
 +
 +
<tr>
 +
<td>Fernando Silva Parreiras
 +
</td>
 +
<td>[http://www.fernando.parreiras.nom.br/ http://www.fernando.parreiras.nom.br/]
 +
</td>
 +
</tr>
 +
 +
<tr>
 +
<td>Abdelouahed Gherbi
 +
</td>
 +
<td>[http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/g/Gherbi:Abdelouahed.html http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/g/Gherbi:Abdelouahed.html]
 +
</td>
 +
</tr>
 +
 +
</table>
 +
 +
 +
== Best Practices ==
 +
 +
<ul>
 +
 +
<li>Improving the Interoperability of Automotive Tools by Raising the Abstraction from Legacy XML Formats to Standardized Metamodels
 +
<br/>
 +
[http://www.springerlink.com/index/l7005436w7j5v14q.pdf http://www.springerlink.com/index/l7005436w7j5v14q.pdf]
 +
</li>
 +
 +
<li>&Uuml;berpr&uuml;fung Syntaktischer Robustheit von Statecharts auf der Basis von OCL
 +
<br/>
 +
[http://rtsys.informatik.uni-kiel.de/~biblio/downloads/theses/kbe-dt.pdf http://rtsys.informatik.uni-kiel.de/~biblio/downloads/theses/kbe-dt.pdf]
 +
</li>
 +
 +
</ul>
 +
 +
== FAQ: Frequently Anticipated Questions ==
 +
 +
<b>I invoke the compiler but no code gets generated. What can I do?</b>
 +
 +
The OCL compiler should generate code when invoked with both
 +
 +
<pre>
 +
    <yourFileName>.ecore
 +
    <yourFileName>.ocl
 +
</pre>
 +
 +
on the same folder. Moreover, the .ocl file should be of the form
 +
 +
<pre>
 +
    package <packageName>
 +
   
 +
    context <myClass>
 +
    ...
 +
   
 +
    endpackage
 +
</pre>
 +
 +
There is guidance about that in the exampled co-delivered with the source code, in plugin
 +
<pre>de.tuhh.sts.ocl.example.royalandloyal</pre>
 +
 +
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
 +
 +
<pre>
 +
    public void compile(IFile ecoreFile, IProgressMonitor monitor)
 +
</pre>
 +
 +
in class <code>OCLCompiler</code> in plugin <code>de.tuhh.sts.ocl.compiler.emf.compiler</code>
 +
 +
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 http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01379.html]
  
 
== OCL Text Editor ==  
 
== OCL Text Editor ==  
Line 147: Line 246:
 
[[Image:OCLTools_oclASTView.png]]
 
[[Image:OCLTools_oclASTView.png]]
  
 +
== Related Links ==
 +
 +
* [http://www.eclipse.org/modeling Modeling Project] [http://wiki.eclipse.org/index.php/Category:Modeling Category] [[Modeling_Project|Wiki]]
 +
** [http://www.eclipse.org/modeling/mdt Model Development Tools] [http://wiki.eclipse.org/index.php/Category:MDT Category] [[MDT|Wiki]]
 +
 +
[[Category:Modeling]]
 
[[Category:MDT]]
 
[[Category:MDT]]

Latest revision as of 08:46, 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

[edit] OCL Compiler

[edit] 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



[edit] 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


[edit] How to install

OCL Tools is known to apply to the following versions:


[edit] 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


[edit] Best Practices

[edit] 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

[edit] OCL Text Editor

The big picture of the editor is:

OCLTools oclEditor screenshots.png

[edit] Features supported

Among others, it supports the following:

[edit] Syntax highlighting

[edit] AutoEdit 1

Auto-completion of closing brace

[edit] 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.

[edit] Bracket matching

[edit] Content Assist

OCLTools content assist.png

[edit] Current line highlighting and Show range indicator

[edit] Text Folding

[edit] Templates, customizable through Preference pages

File:OCLTools editor preference page.png


[edit] Problem and Warning markers, "red squigglies"

OCLTools problem markers.png


[edit] Outline view

[edit] OCL AST View

OCLTools oclASTView.png

[edit] Related Links