Welcome
Mission statement
Writing OCL expressions made easy!
Content of this web page
With this mission in mind we want to promote usage of OCL among practitioners. To realise our goal we started to integrate concepts and techniques known and used for years in writing source code into development of OCL expressions (OCLLib, OCLUnit, OCLDoc). This resulted in design of the OCL libraries and implementation of the advanced OCL editor (project management is hosted at Google Code).
The page is under construction.
More information will be added soon...
Please visit us again. :-D
Papers and presentations
Presentations
-
OCL Workshop 2008 (2008-09-30)
Tool demonstration at the tool demo session of the OCL Workshop associated with MoDELS'2008.
Papers
Hopefully it will be something to put in this section soon... ;-)
Funding
The work presented on this web page is partially conducted within the competence network Softnet Austria and funded by the Austrian Federal Ministry of Economics (bm:wa), the province of Styria, the Steirische Wirtschaftsfoerderungsgesellschaft GmbH. (SFG), and the city of Vienna in terms of the center for innovation and technology (ZIT).
The work is partially a partially conducted within Telling TestStories (TTS) project funded by TransIT and softmethod. Read more on the TTS project's TTS official web page.
Library concept
Why libraries are needed?
The wide usage of Unified Modelling Language (UML) models causes increased need for model constraints and queries. There is an agreement among academics that the Object Constraint Language (OCL) is suitable for this task. However practitioners find it difficult to define OCL expressions. Thus simplification mechanisms are desirable to promote usage of OCL within practical applications.How libraries can be useful?
We propose OCL libraries for model queries, which simplify the definition of OCL expressions by hiding definition details from an end user. Moreover, the libraries enable a high reuse factor, are configurable and testable. The libraries can be checked against their syntax correctness and can be tested against a desired semantics.Abstract syntax
Click on the images to enlarge them.
The complete abstract syntax is depicted in the diagram above with white elements from the original OCL and UML specifications. In the following all elements are described step by step.
Library Structure
The starting concept is library. It has an attribute called name (of type libraryName), is specific to a given metamodel, can import other libraries and consists of some non-empty content.
The metamodel specifies the scope of application of the library, which can be used for models which are instances of the metamodel. It is recommended to use the most general metamodel suitable for a particular application. For example, if the library was written for a UML Profile, but consists only of elements from the UML definition, then UML should be selected as the used metamodel. In general, it is recommended to split libraries into parts specific to different metamodels and use the import mechanism, to enable higher reusability.
The import mechanism enables the usage of definitions from other libraries. The visibility of imported expressions depends on the visibility of the LibraryContent in which the expressions are defined.
The visibility of the library content is specified by VisibilityKind defined in the UML 2.0 Superstructure. There are four visibility kinds defined: private, protected, package, and public. The interpretation of the public and private elements is the same as in the UML Specification, where the namespace is equal to the library. The interpretation of protected elements is modified, and the package visibility is currently not used as superfluous in the context of libraries. A private expression is only visible inside the library that owns it. A public or protected expression is visible in other libraries that import the one that owns it. Moreover a public expression is visible in tools that use the library. The scope of subexpressions should be wider than or equal to the scope of the including expressions, otherwise visibility conflicts can occur.
Library Content Classification
There exist three different types of library contents: definitions, queries, and tests.
The Definitions are a collection of OCL definition expressions, the Queries are a collection of queries over models, and the Tests are a collection of tests for the definitions and over models. The definitions, queries and tests can include definitions visible in their scope.
Definitions
The Definitions are OCL method or attribute definitions to be used by other OCL expressions in the same or another library. This element consists of at least one definition block, which at least consists of one definition expression.
The definition block collects OCL definition expressions for the same context. The context is defined as an extended context declaration (extContextDeclaration), which extends the original OCL context declaration (contextDeclaration). The defExpression is used according to its original definition in the OCL 2.0 Specification. The elements from the original OCL 2.0 Specification are denoted with OCLSpec stereoptype in all subsequent diagrams.
Queries
The Queries are methods dedicated to the usage for model querying in a modeling or an analysis tool. This element, similar to definitions, consists of at least one query block with at least one query.
The query block collects queries for the same context. The query is related to standard OCL elements. It has a name attribute of type simpleName, a severity level and optionally a trigger, both of type OclExpression, and one or more evaluations of type LetExp.
The severity level determines how critical a given query is. In the library specification the severity levels are unlimited and can be given by an OCL expression. It is recommended to use natural numbers to denote the levels. We assume that 0 stands for an information, i.e. informative query to give some statistics. Non-zero levels stand for warnings and errors. During project phases, a threshold between warning and error, which depends on the development stage of models, can be set. The general definition of severity levels enables the definition of any classification, e.g. a critical error can be introduced and interpreted in a tool using the libraries.
The trigger should be a boolean expression. It has the following interpretation: true triggers displaying a message, false and undefined cause nothing. The default value is true, i.e., if a trigger is omitted a message is always displayed.
Evaluations are intended to provide auxiliary local variables that can be used in a trigger or in a~message. The variables are visible below their definitions in the scope of the current query block. To define variables visible in the scope of the current library definitions should be specified or imported.
The message defines text for a user friendly presentation of query result.
Tests
The Tests are dedicated to test the OCL expressions, in particular definitions. For tests a concrete user model can be selected and at least one test unit has to be specified.
If the Model is selected it must be an instance of the metamodel. Moreover, the metamodel specified in the testing library must be the same as in the corresponding tested library (with definitions to be tested). Additionally, the model must be provided together with the library, otherwise the tests can not be evaluated.
The Test Unit has an optional name, at least one evaluation and one expected value. In a test unit the result of an OCL expression (evaluation), preferably with a definition, is compared with the expected value.
We specify no additional message for a test unit, as we assume that tests are used by library developers familiar with the OCL and thus a standard error message should be enough informative for them.
OCL Editor
The advanced OCL editor supports libraries and core OCL editing (the project management is hosted at Google Code).Features
Supported core features
- Syntax checking
increases correctness of the expressions and user satisfaction. It is necessary to check the syntax in context of OCL and an underlying metamodel.
- Testability support
increases correctness of OCL expressions. It ensures correctness in incremental development of OCL expressions/libraries, if an efficient number of tests is provided. The tests are similar to unit tests, that are provided for many programming languages. Testability enables OCL expression checking at the semantic level.
-
Syntax completion
causes increasing of user satisfaction, efficiency and correctness of OCL expressions. The editor supports OCL and a metamodel specific grammar and in case of libraries also the extension of OCL.
- Syntax and error highlighting
is important for efficiency and user satisfaction. It enables better readability and faster error correction.
- Templates
support increases user satisfaction and effectiveness. defined for typical OCL expressions (e.g. for patterns) and for concepts related to OCL libraries (our extension).
- Code formatter
enables better readability and exchange of OCL expressions/libraries.
- Comments support
required for in-line explanation and comments for documentation generation. This feature is important for sharing OCL expressions/libraries and for easier understanding and reusability.
Integrated plug-ins
- SVN plug-in
OCL library projects can be imported from a subversion repository.
Features under development
- Arbitrary metamodel
could be used in the OCL editor. The restriction is that the metamodel must be MOF based. There are two options profiles and new languages to be considered.
- Dedicated perspective
for OCL Library projects.
Planned and requested features
- Debugging
possibility of in-editor context instantiation and evaluation of complete or partial OCL expressions.
- Constraints support
focus on other constructs of OCL, such as, inv, body, pre, post. Now only defs are supported.
- Integration with other UML/OCL tools
to support user friendly OCL edition in existing software, such as Dresden OCL Toolkit, A UML-based Specification Environment, Model Development Tools.
Architecture
Click on the image to enlarge it.
OCLEvaluator is based on EclipseOCL, which is an open source OCL interpreter provided by Eclipse. EclipseOCL is not used directly but via an interface.
We designed the IEvaluator interface to enable exchange of the underlying OCL interpreter and to add additional functionality. Another interface is IEvaluatorListner, to which observers of a particular kind (IKind) of OCL expression evaluations can register. In the below diagramm two observers, UMLTool and OCLEditor are registered to IEvaluatorListner. Additionally two interfaces, IDefine and IQuery, are designed to hide internal representation of definitions and queries, respectively.
GeneralLibrary provides an extension point which enables definition of different types of libraries. A library is specified by implementation of the ILibrary interface which provides methods to get all defined queries and definitions. A library include a LibraryDescription with information about the library. A DocumentLibrary is an implementation of GeneralLibrary used in the OCLEditor and implementing both interfaces. Observers of OCL expressions, such as UMLTool, use the ILibrary interface, which hides the concrete implementation.
OCLEditor consists of DocumentLibrary and ISyntaxCompletion. DocumentLibrary, as mentioned above, implements GeneralLibrary. ISyntaxCompletion is the interface to OCL and UML syntax completion partially based on EclipseOCL.
Concrete syntax
The concrete syntax is defined as an ANTLR grammar in ANTLRWorks (download the grammar file).Examples
A small illustrative example project (zip) with 4 libraries, one model and the corresponding generated documentation. A flash demo presenting creation of the project can be found in the demonstration section. The project was presented at OCL Workshop 2008.An example project (zip) collecting OCL definitions used in our study on OCL Eclipse interpreter performance. The project consists of 2 libraries, 2 models and the corresponding generated documentation.
More examples will be provided soon...
Library Interpretation process
Click on the image to enlarge it.
In the library interpretation process, depicted in above, two parts are considered. The first one is related to the library concept and is in the scope of the OCLEditor functionality. The second one is related to the interpretation of standard OCL and is in the scope of the OCLEvaluator functionality. As mentioned in the previous section, the OCLEvaluator uses EclipseOCL. For the sake of simplicity this fact is neglected in the below description.
The interpretation process starts with two input files used in the OCLEditor. The first one is the grammar file with the definition of the libraries' concrete syntax. The second one is a library file with a library to be interpreted. The input library is parsed based on the grammar and an appropriate parse tree (tokens) is obtained. Tokens related to standard OCL are sent to the OCLEvaluator together with model instances. In the OCLEvaluator OCL-expression-parsing and -interpretation take place, and the results are sent back to the OCLEditor. In the OCLEditor the results from the OCLEvaluator are used to obtain the complete interpretation of the input library.
Demonstration
Screenshot
On the left the below screen shot shows the project explorer with UML models and OCL libraries. In the middle the OCL editing window with a library file, and below the errors are listed. On the right the structure of the library is shown in an outline view.Click on the image to enlarge it.
Flash demo
A flash demo of a small illustrative example presented at OCL Workshop 2008. Libraries and models from this example can be found in the concrete syntax section.Download
The alpha version of the OCL editor is available, to install it please follow the instructions below:-
install the required Eclipse Ganymede,
recommended JEE, - install the required EMF incubation package,
- install OCL Editor: unpack the zip file or use the update site http://squam.info/ocleditor/update/,
-
extend memory settings in eclipse.ini
--launcher.XXMaxPermSize 512m -vmargs -Xms256m -Xmx512m
- Enjoy using the OCL editor. You may try example libraries available in the Concrete syntax section.
- Please report bugs you will find to our bug-tracking system hosted at the Google Code.