The text of the proposal follows:
OCL Tools
I. Introduction
OCL Tools is a proposed open source component
in the Model Development Tools (MDT) Project to support the editing, refactoring, code generation, execution, and interactive debugging of the OCL constraints given for some underlying (Ecore or UML2) class model, building upon the infrastructure provided by the MDT OCL component.
eclipse.modeling.mdt newsgroup.
II. Background
The Eclipse infrastructure for modeling is based on EMF and UML2, with support
for OCL 2.0 (Object Constraint Language) provided by the Model Development Tools (MDT) project. The expressive power of OCL allows capturing a sizable amount of development
requirements in a declarative manner:
- (a.1) data modeling aspects can be expressed as an (Ecore or UML2) data
schema further constrained by OCL invariants; - (a.2) a number of functional requirements can be specified as
operation pre- and postconditions, together with - (a.3) side-effects-free queries (defining the values of instance
fields and operations)
- (b.1) its textual representation into its Abstract Syntax Tree (AST)
representation, - (b.2) invoking an EvaluationVisitor (also provided by MDT OCL)
on the AST representation. Evaluation takes place in the context of an
object population.
- (c.1) for Ecore, in an Eclipse Technical Article by Christian W. Damus
("Implementing Model Integrity in EMF with EMFT OCL") [3],
with an exemplary realization (custom JET templates). The user is expected to adapt such techniques (for example, in case a text file contains the OCL constraints as
opposed to being available as annotations to an Ecore-based model). - (c.2) for UML2, at
http://wiki.eclipse.org/index.php/MDT_1.0_New_and_Noteworthy#OCL_Integration
at the very least an OCL compiler is necessary, building upon (Ecore,UML2) ->
Java code generation and weaving (a.1) through (a.3) into the
resulting Java code. In particular, the generated code can then be
directly used as the Model component in an MVC architecture (for
example, as part of a graphical editor generated with Eclipse GMF).
Additionally, the compiled OCL expressions execute faster (twice on
average) than their interpreted counterparts. In order to compare the performance of alternative compilation algorithms, a benchmark suite of OCL expressions would be desirable.
For OCL specifications to be seamlessly integrated in an MDSD toolchain, besides batch compilation, other tools are necessary: custom text editor, source-level debugging support, i.e. IDE capability.
III. Scope
The objectives of the OCL Tools component are to:
- (d.1) provide a working implementation of a compilation algorithm
targeting both EMF and UML2. That algorithm (in its EMF specialization)
has been described in a position paper [2] submitted to the Modeling Symposium
at Eclipse Summit Europe 2007 and has been implemented in the code contribution mentioned below. A related Eclipse Technical Article ("How to Process OCL Abstract Syntax Trees") [4] has been contributed by one of the authors of
this proposal, simplifying the learning curve for future contributors. - (d.2) provide sample (Ecore and UML2) + OCL models to speed up the adoption by
first-time users of OCL Tools. Initially, two non-trivial models are to be made available:- (d.2.a) Royal & Loyal, described in the book on OCL by Warmer and Kleppe; and
- (d.2.b) a metamodel of the JPQL language (Java Persistence Query Language) which encodes as OCL invariants all the well-formedness rules ("static semantics")
stated as English sentences in JSR-220 (described in this paper)
- (d.2.a) Royal & Loyal, described in the book on OCL by Warmer and Kleppe; and
- (d.3) solicit contributions to adapt the compilation algorithm
embedded in our implementation to other domains: - (d.3.a) first and foremost, to accept UML2 class models as input,
- (d.3.b) targeting object models other than Java
(for example, by translating OCL constraints into the
query language of Java Persistence API, the Object-Relational Mapping
technology standardized by JSR-220). - (d.4) provide IDE capability:
- (d.4.a) a text editor supporting usability features such as syntax-directed completion, markers for violations of well-formedness, use-defs navigation, folding, and structural views (e.g., OCLASTView [4])
- (d.4.b) refactoring support
- (d.4.c) source-level, interactive debugging
IV. Description
This section focuses on the functionality available in the code contribution.
Pointers to related work are included in the next section ("Relationship with other Eclipse-based projects").
An OCL compiler is available, which follows the classical software architecture of a
batch compiler [1]:
- (e.1) a front-end component, shared among all
"target architectures" (EMF and UML2). During the front-end phase,
textual input is parsed into Concrete Syntax Trees
(CSTs), which once validated are used to build the ASTs
that compilation proper takes as input. These two activities involve a
number of sub-steps, such as resolving mutual forward-references and
collecting error markers. These sub-steps are realized with
building blocks provided by MDT OCL, while bookkeeping and glue code
has been added to hold everything together. - (e.2) the in-memory copy of the input model (our compiler does not
modify the actual input) is decorated with EAnnotations that are
taken later by EMF CodeGen (and in the future by UML2 CodeGen)
as the source of method bodies and
additional declarations: helper methods, helper types (e.g.
those resulting from OCL tuples), and helper utilities (e.g. those to
track all instances in a ResourceSet, realizing OCL's allInstances())
comprehensive exposition can be found in [2]):
- (f.1) OCL preconditions and postconditions are translated into Java
assert statements - (f.2) OCL define and derive statements are translated into getters
(for properties) and into method bodies (for operations) - (f.3) OCL invariants are translated into dedicated Java methods. It is
the responsibility of the user to invoke them at times deemed
appropriate.
The OCL Compiler is packaged as an Eclipse plugin with a basic UI (an
action for an IFile to start compilation, a preferences page to
choose compilation options). The input (as of now) is assumed
to be a single .ecore file accompanied by an .ocl file with the same name.
V. Relationship with Other Eclipse-based Projects
The SAFARI project aims at generating an IDE out of the description of an object oriented, imperative programming language, in principle covering the whole spectrum from structured editing to interactive debugging.
Other efforts have focused on the structured editing and AST-building phases,
with an emphasis on using as internal representation of ASTs
an instantiation of an Ecore + OCL language metamodel ("eat your own dog food").
Refactoring of OCL expressions is the goal of the tool http://www.roclet.org
As resources such as the above on IDE-related issues become available,
their application in the context of this component will be considered.
VI. Organization
VI.a) Initial committers
The initial committers will focus on evolving and hardening the OCL
compiler, as input models are contributed by the community. The
initial committers are also willing to provide know-how to the
community on OCL tooling in general (e.g, for those developing
translations from OCL into other languages, such as JPQL). Our agile
development process will follow eclipse.org's standards for openness
and transparency. The initial committers are:
- Miguel Garcia (Technische Universitaet Hamburg-Harburg,
Germany), http://www.sts.tu-harburg.de/~mi.garcia/ - A. Jibran Shidqie (Technische Universitaet Hamburg-Harburg, Germany)
VI.b) Code contributions
The OCL Compiler for EMF described by its authors in [2].
VI.c) Interested parties
The team of initial committers will explore statements of interest
from persons experienced in OCL processing or willing to gain such
experience.
VI.d) Developer community
We expect the initial set of committers to grow, as the intial contribution
establishes a platform which automates the front-end phases of
OCL processing (a common need for most, if not all, OCL processing tasks).
There is an active OCL community, with participants from industry and
academia attending (among others) the OCL workshop series at the
MoDELS conference (http://st.inf.tu-dresden.de/Ocl4All2007/). The
techniques advanced by this community can naturally build upon and extend the
tooling proposed here.
Similarly, members of the growing QVT community usually have a
background in OCL processing, and would be willing to have OCL play a
bigger role in their techniques provided the proposed infrastructure is
available.
VI.e) User community
Feedback from a large user community of commercial developers is
critical to harvesting real-world and complete OCL
specifications. Actually, harvesting such specifications reveals an
egg-and-chicken problem: those specifying a system have a reduced
incentive to invest effort in preparing OCL specs if they are to
remain paper-only and thus not automatically enforceable. On the other
hand, the developers of OCL tooling are reluctant to target a small
audience. The OCL compiler component is good positioned to break this
cycle, providing immediate benefit to the authors of OCL
specifications in the form of a portable and efficient implementation
of the (Ecore,UML2) + OCL spec given as input.
The availability of OCL tooling will also expand the user base
of directly related projects/components (OCL, EMF, UML2) thus
accelerating the synergies of the Eclipse ecosystem.
VII. Tentative Plan
- 2007-07 v0.1: internal release for study in the EMF, UML2 and MDT OCL teams
- 2007-08 v0.2: public release for community study
[1] A. W. Appel and J. Palsberg.
Modern Compiler Implementation in Java. Cambridge University Press, New York, NY, USA, 2003. http://www.cs.princeton.edu/~appel/modern/java/
- [2] OCL Compiler for EMF.
Garcia, M. and Shidqie, A. J. Submission to Modeling Symposium at Eclipse Summit Europe 2007.
Christian W. Damus, Eclipse Technical Article,
- [4] How to process OCL Abstract Syntax TreesMiguel Garcia, Eclipse Technical Article,
