Overview

One of the key needs in any open computing environment is a computable representation of its own models, for a number of purposes, including reasoning about them, performing validation and consistency checking, building software and generating documentation. This is particularly true of openEHR, where a further need is to be able to validate archetypes and templates with respect to the reference model, and also to validate runtime instance data against operational templates and the reference model.

A number of computable representations of the openEHR published models have been available in the past. Currently models are represented in two computable forms:

The primary use of the UML expression is for specification publishing. In this role, the internal UML is processed to generate correct signatures for class properties and functions, and can be used computably for other purposes, as long as care is taken with template and qualified attributes.

The BMM provides a standalone alternative to UML/XMI which correctly represents all types, including open and closed template types, and is human-readable. It was originally developed in 2012, when the state of UML tools and particularly XMI was poor, and a reliable format was needed for openEHR modelling tools.

One would expect that the ICT industry would have fully computable representations of models and diagramming solved, but it is not yet the case. UML 2.x and its associated serialisation format XMI 2.x should in theory mean that complete, interoperable machine expressions of object models would be available in all tools. It will probably eventually come to pass, but a number of obstacles remain to date:

Experience with various UML tools (up till 2015) highlighted the following problems:

Since 2015, the quality of some UML tools has improved, and the XMI generated by some is more reliable. However, XMI generated by different tools is not the same for identical models, and some XMI importers offer numerous switches in order to process the XMI of another tool properly. XMI thus still needs to be processed with care.

Nevertheless, a small number of tools, including MagicDraw (currently used for representing openEHR models for the specifications) and Rational Software Architect (RSA), appear to implement UML 2.5 faithfully. This means that despite the limitations of UML 2.5 (as noted above), models expressed in it can be correctly interpreted and processed for purposes such as code generation.

The Basic Meta-Model supports the representation of object models in the data point of view. It is designed to enable both human authoring and machine extraction (e.g. from a UML tool or programming language classes) of textual schemas. This specification defines a BMM object model, i.e. the in-memory object structure of a BMM, and also an object model for a serialised schema form. The latter enables serialisation of a BMM into a concrete syntax such as ODIN, JSON or XML. In the future an abstract syntax serialisation may be developed in the style of OMG IDL (Interface Definition Language) or similar.

The BMM packages are as follows:

The P_BMM_* classes perform two functions. Firstly, they are a modified and simplified version of the BMM_* classes that enable for example symbolic referencing via class names, syntactical type names to be used etc, rather than the full explosion of fine-grained objects that would result from a direct serialisation of BMM_* classes. This is what enables the P_BMM file format to be easily readable and editable by human users.

The second is that P_BMM files function as schemas that support schema inclusion and therefore re-use, in a similar manner to the XML schema languages. Thus, a single logical BMM model can be expressed as a number of P_BMM schema files which are actually P_BMM_* object serialisations. A schema reading component has to resolve the schema inclusions and ultimately BMM_* object instantiations to obtain the in-memory form of the model.

We thus talk of the P_BMM_* classes as a model of 'BMM schemas' and the BMM_* classes as a model of 'BMM models', where the latter is understood as the fully computable in-memory object structure with all name references resolved to object references.

The packages are illustrated below.

The normal use of BMM is as follows:

BMM models are normally expressed as schema text files that support inclusion and re-use. The default file format has historically been openEHR ODIN syntax, and BMM tools to date support this format. However any common format that can express typed object models may be used, including JSON (with type markers), YAML, and XML. The examples shown in this specification are primarily in ODIN, but a tool implementing BMM may choose to serialise in and out of another preferred format.

The elements of meta-models are sometimes named confusingly in the literature and within various programming language technologies. In this specification, we have used the following terms: