THE UCL MDA TOOLS


The EMOFOCL2 module

UCL Logo
Home
Sourceforge project page
Download
UCL UML
Documentation
EMOFOCL2 API
UML 1.5 API

SourceForge.net Logo

EMOFOCL2 Project

The EMOFOCL2 module builds a collection of utilities for working with models expressed according to the EMOF model, and the OCL2 constraint language. EMOF is a language for describing data structures and interfaces for meta-data repositories. Normally expressions look just like UML class diagrams. However, these require a graphical editor that would have been hard to develop, so we've developed a textual syntax for EMOF/OCL. This can be converted to EMOF XMI.

Like UML class diagrams, EMOF models can contain embedded OCL expressions. This document describes the concrete syntax for EMOF/OCL models used in our editor.

The EMOF specification is part of the MOF specification, which is a more complex data structure specification language. However, much of the additional expressiveness of the MOF specification that is not included in the EMOF specification can be reproduced using OCL constraints in EMOF models.

MOF and OCL specifications are available from the OMG.

The EMOFOCL2 module relies on the GTL and UCL modules to build.

Parser and type checker

The utility HTMLEMOFToXMI (uk.ac.ucl.cs.emofocl.emofocltoxmi.EMOFOCLToXMI) will parse a specification of a language (a meta-model), report any syntax or type errors, and if none exist, output an EMOFOCL XMI version of the specification.

The concrete syntax for EMOF used in this code is as follows:

specification ::=
        "specification" <name> "{" (class | package) * "}"

package ::=
        "package" <name> "{" (type | package)* "}"

type ::= primitive | class | enumeration

primitive ::=
        "primitive" <name> 
        (
          ("OCL_INTEGER" | "OCL_STRING" | "OCL_BOOLEAN" | "OCL_REAL)
          ("IDENTICAL")?
        )?

enumeration ::=
        "enumeration" <name> "{" (<name>)+ "}"

class ::=
        "class" <name> ("extends" typePath (", " typePath)*)? "{"
          (attribute | operation | invariant)*
        "}"

attribute ::=
        ("component")? <name> ":" typePath (multiplicity)?
        ("opposite" <name>)?

operation ::=
        <name> "(" (parameter ("," parameter)*)? ")" 
        ":" typePath (multiplicity)? ("=" "{" expression "}")?

invariant ::=
        "invariant" "{" expression "}"

typePath ::=
        ("::")? <name>  ("::" <name>)*

multiplicity ::=
        "[" ("*" | <integer> ("," ("*" | <integer>))?) "]"

Names may be any combination of letters and numbers starting with a letter, or may be double quoted Java-style strings.

The expression production corresponds to any valid OCL2 expression. However, to modularise the parsers and maintain some independence between the EMOF and OCL syntices, any OCL expression must be surrounded by braces.

Comments may be included in C-style blocks (between '\*' and '*\'). Line comments begin with '--' following the OCL specification.

Documentation for types and features may be included in the meta-model using the special comment syntax `\[` and `]\`. Such comments are only valid singly, preceding the definition of a specification, type, attribute or operation, and pertain to the element immediately subsequent.

JMI repository generator

JMIGen (uk.ac.ucl.cs.emofocl.jmigen.extended.JMIGen) generates JMI repositories from EMOFOCL XMI files such as those produced by EMOFOCLToXMI. It's operation is shown schematically below:

To contrast the operation of the current version of JMIGen with obsolete generators included in other modules, see this comparison.

JMI repositories generated with JMIGen implement most of the JMI standard including:

  • Support for models with multiple inheritance (handled via delegation in the implementation classes).
  • Support for collection-typed features, implemented using live collections.
  • Access to the meta-model via the reflective interfaces.
  • Meta-model constraint checking of multiplicity constraints, via the reflective interfaces.
  • Meta-model constraint checking of OCL type invariant constraints, via the reflective interfaces.
  • Reflective getting and setting of attributes and references.

Known parts of the standard not yet implemented are:

  • Reflective invocation of operations (although this can be achieved using Java reflection instead).

JMI repositories generated with JMIGen implement a number of extended features including:

  • A JavaBeans-style pub/sub event model that may be used to track changes to model elements and package extents.
  • Deep and shallow copy operations for model elements, based on the composition hierarchy.
  • An OCL interpreter implements side-effect free operations when there is an OCL definition of the operation present in the meta-model.

The features may be accessed via extended reflective interfaces, defined in package uk.ac.ucl.cs.emofocl.jmi.reflect.extended.

Class proxies in the repository choose implementation types dynamically. Default choices can be overridden using system properties, allowing custom implementation classes to be substituted. In particular this can be used to implement operations in the meta-model with side effects, by extending the default implementation classes to implement the operations and then specifying the extended class in the properties. Implementation override properties have the format:

uk.ac.ucl.cs.emofocl.jmi.impl.<fully-qualified interface name> = <fully-qualified implementation type>

E.g.:

uk.ac.ucl.cs.emofocl.jmi.impl.uk.ac.ucl.cs.uml.jmi.ModelManagement.Model = uk.ac.ucl.cs.uml.jmi.impl.ModelManagement.Model_Impl

Finally, when generating the JMI repository, JMIGen automatically generates a small graphical application for editing models in the repository and persisting them as XMI files. A screenshot of this application for the UML meta-model is shown on the UCL MDA tools project homepage.

HTMLEMOFOCLDoc

The HTMLEMOFOCLDoc utility (uk.ac.ucl.cs.emofocl.emofdoc.html.HTMLEMOFDoc)generates HTML documentation for language specifications (documented meta-models) from their XMI, once they have survived parsing and type checking.

The best current example is the UML 1.5 specification

Back home