Dresden OCL has been around for more than 10 years but has never been featured in this portal which is a shame. To fix this, I contacted Claas Wilke and Birgit Demuth and ask them to write a brief introduction to Dresden OCL for the portal readers. Hope you enjoy it and give DresdenOCL a try! (if necessary, read first why you should use OCL and learn the basics of the OCL language).

Enter Claas and Birgit.

Dresden OCL is an OCL tool developed at the Technische Universität Dresden and has its origins in the late 90s, when OCL was still in its early days. The first version of Dresden OCL released 1998 consisted of a simple OCL parser, an interpreter and a Java library that were designed for the integration into other modeling tools. An example is MagicDraw UML. An early version of Dresden OCL was integrated by NoMagic into its well-known UML tool and therewith is still “living” and using   as reported by Tricia Balfe.  Since then, Dresden OCL has been extended and completely revised multiple times changing from a simple parser/interpreter to an OCL tool suite, today consisting of an editor, interpreter and two code generators integrated into the Eclipse IDE.

We are proud to offer an OCL tool suite that is syntax and evaluation compliant to the OMG’s OCL 2.3 specification. In OCL’s early days, only OCL constraints (invariants as well as pre and post conditions) were supported. Later, OCL was extended to a constraint and query language. Today you can “query” models/model instances or define new model elements.  Although the term “OCL statement” is not explicitly defined by the OMG, we will speak in the following about OCL statements as a generic term for constraints and queries. Note that every OCL statement contains a possibly complex OCL expression.

Now let us have a short look at the different tools of Dresden OCL and show the latest progress on the path from simple OCL evaluation libraries towards an IDE for OCL as envisioned by Birgit Demuth, Joanna Chimiak-Opoka et al. in 2009 [1].

Editing and Maintenance of OCL Statements

The “pivotal” tool of Dresden OCL is the OCL Editor as shown in the figure below:

Statements edited in the editor are automatically parsed by and added to the model repository of Dresden OCL. A remarkable feature of Dresden OCL is the support of several types of models on which OCL statements can be defined, including UML class models, Java classes, EMF models, and XML Schemata. In Dresden OCL‘s model repository all these models are hidden behind well-defined interfaces (a.k.a. a pivot model [2]), which allow to reuse the same OCL tools for all of them.

For the maintenance of OCL code, the OCL editor provides features such as code completion and error highlighting. Warnings help to avoid OCL code smells and anti-patterns (e.g., implicit casts from single elements to collections). OCL refactorings allow the improvment of the constraints’ structure and of the readability (e.g., the extraction of variables and methods or renamings) [3].

Besides the editor, Dresden OCL provides an outline view (Figure 1, right) and a metrics view that provides some basic metrics on the edited OCL statements (e.g., the average number of nested expressions per statement, Figure 1, bottom).

OCL Interpretation

A user-friendly support for the specification of OCL statements is a first important step but what does it help when the execution of these statements are not possible?  Available OCL tools mainly differ in this issue.  Dresden OCL provides an OCL interpreter to evaluate OCL expressions. And, you can evaluate OCL expressions on instances of models that are defined in different technical spaces. That is, similar to the OCL parser, the interpreter can be reused for several types of model instances (e.g., a set of Java runtime objects as an instance of a UML class model or an XML file as an instance of an XML schema) [4].

As the interpretation of OCL expressions sometimes results in unexpected results where the reason for these results is hard to find, Dresden OCL provides an OCL tracer illustrating the interpretation of an OCL expression as a tree of nested OCL expressions and their respective results:

Code Generation

Besides interpretation, a typical usage scenario for OCL is its compilation to executable program code. During the life time of Dresden OCL we experimented with several code generation techniques that were applied in many and mostly research projects. The recent Dresden OCL release provides two code generators.

The OCL2Java code generator produces executable Java code from OCL expressions. In a second step, a Java application has to be instrumented by this generated code. Our recent OCL2Java tool generates AspectJ aspects to instrument a Java application.

The OCL2SQL code generator allows the generation of SQL code which can be used to check business rules specified in OCL on data that are stored in an SQL database. We developed a transformation technique which considers both the mapping of OCL and the underlying model to SQL code and schema [5].  The OCL2SQL scenario is primarily useful for tests of data quality in existing SQL databases. Such tests are executed on snapshots of an SQL database and are therewith transaction-independent. They do not stress the runtime of the SQL database application and get more and more acceptation in the context of legacy databases.

Summary

Starting from a single OCL library in 1998, today Dresden OCL has become a set of user-friendly, easy usable OCL tools for Eclipse, getting closer to the vision of an IDE for OCL [1]. Besides, Dresden OCL is still available as a Java library that can be integrated into other Java tools without the necessity of the Eclipse/SWT-based UI components.

Dresden OCL is publicly available under GPL and can be installed via the Eclipse Marketplace Client or downloaded from http://www.dresden-ocl.org/. Further information on its usage can be obtained from its manual available at http://www.dresden-ocl.org/update/manual.pdf.

Further Reading

[1] Joanna Chimiak-Opoka, Birgit Demuth, Darius Silingas, Nicolas F. Rouquette: Requirements Analysis for an Integrated OCL Development Environment. In: OCL 2009 Workshop – The Pragmatics of OCL and Other Textual Specification Languages, 2009.

[2] Matthias Bräuer, Birgit Demuth: Model-Level Integration of the OCL Standard Library Using a Pivot Model with Generics Support. In: Models in Software Engineering, LNCS 5002, 182-193, Springer Berlin / Heidelberg, 2007.

[3] Jan Reimann, Claas Wilke, Birgit Demuth, Michael Muck, Uwe Aßmann: Tool Supported OCL Refactoring Catalogue. In: 2012 Workshop on OCL and Textual Modelling (OCL 2012).

[4] Claas Wilke, Michael Thiele, Christian Wende: Extending Variability for OCL Interpretation. In: Model Driven Engineering Languages and Systems (MODELS 2010), LNCS 6394, 361-375, Springer, Berlin / Heidelberg, 2010.

[5] Florian Heidenreich, Christian Wende, Birgit Demuth: A Framework for Generating Query Language Code from OCL Invariants. In: 2007 OCL Workshop at the UML/MoDELS Conference