Basic Meta-Model (BMM)

This specification has benefited from formal and informal input from the openEHR and wider health informatics community. The openEHR Foundation would like to recognise the following people for their contributions.

This document describes the Basic Meta-Model (BMM), a model of object models. It may be considered as an approximate replacement for the UML XMI. It is human-readable and writable, and supports generic types (open and closed), container types, and multiple inheritance.

This specification is in the TRIAL state. The development version of this document can be found at https://specifications.openehr.org/releases/LANG/Release-1.0.0/bmm.html.

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

Feedback may be provided on the openEHR languages specifications forum.

Issues may be raised on the specifications Problem Report tracker.

To see changes made due to previously reported issues, see the LANG component Change Request tracker.

Conformance of a data or software artifact to an openEHR specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal derivations from underlying models, ITS conformance indicates model conformance.

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

The openEHR Archie Library fully implements this specification in Java and may be used to build UI tools for compiling, viewing and editing BMM models.

The openEHR ADL Workbench (AWB) fully implements this specification, and provides a convenient way of illustrating BMM semantics. The screenshots used in this specification are all from the ADL Workbench. The tool is written in the Eiffel language, and is available as open source on Github. The BMM libraries can be found in the EOMF Github repository.

One of the key needs in any open computing environment is a computable representation of its own models. This is 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 and other archetype-based frameworks, 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, namely UML and BMM (i.e. the format described in this specification).

The primary use of the UML expression is for specification publishing. In this role, UML diagrams and static models are built, and then post-processed to correct signatures of class properties and functions. The post-processing corrects UML’s shortcomings and errors in non-singular relations, generic (template) types, and qualified attributes. The result can be used for publishing documentation with feature signatures that are formally correct and will be understood by developers in most programming languages. It can also be serialised and used computably, e.g. in other visualisation or modelling tools. UML’s own serial format, XMI is thus generally unsuitable for such uses, due to the formal errors, as well as its excessive complexity. XMI is also notoriously non-standard across UML tools.

As a result, openEHR introduced the Basic Meta-Model (BMM) in 2009 as a way of representing correct object-oriented semantics of information models for use in tools, along with a serial format by default expressed in the openEHR ODIN syntax.

The BMM provides a standalone alternative to UML/XMI which correctly represents all types, including open and closed generic types, inheritance of generic types, and various other problems with UML. As a meta-model it is adapted to the task, i.e. representing entity types that can appear in object models, rather than the over-generalised semantics of the UML meta-model. This reduced scope, and the fact that it contains no diagram semantics enables its serial form to be human-readable.

The Basic Meta-Model supports the representation of object models in the ISO RM/ODP information and computational points of view, i.e. in programming terms:

It is designed to enable both human authoring and machine processing, including e.g. extraction of BMM textual schemas from a UML tool or programming language classes. The semantics of the model are heavily influenced by the formal approach to object-orientation described by Bertrand Meyer in Object-oriented Software Construction (Meyer, 1997) and also the Eiffel language, which is significantly better basis for object modelling than the UML 2.x meta-model. The BMM consequently departs from UML in a number of significant ways, and also from the OOSC/Eiffel approach in some aspects (e.g. direct meta-type suport for container types). Its key features are as follows:

Functional elements are supported via the inclusion of meta-types representing signatures and tuples, enabling the construction of delayed agent calls, known here as agents, and function applications (i.e. function calls).

Note that there is no BMM entity for graphical diagramming semantics. Thus, there is no idea of 'association' distinct from an 'attribute', as per UML, which treats lines between class boxes as formal elements.

The BMM is specified as a structural model representing an abstract syntax tree (AST), which is the result of either in-memory construction (such as by a model authoring tool) or by parsing of a serialised representation of a BMM model. It does not specify an abstract syntax, and indeed, more than one concrete syntax could be parsed to a BMM instance.

This specification defines a BMM object model, i.e. the in-memory object structure of a BMM. The related BMM Persistence specification defines 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.

The BMM packages are as follows:

Related packages are:

These are illustrated below.

The org.openehr.lang.bmm.model_access package provides an interface for the application to load BMM schemas and convert them to BMM model form, and is shown below. In this model, a schema is the serial form of a model or part of a model (i.e. instances of a persistence model like the lang.bmm_persistence model P_XXX classes). One or more schema files are parsed, validated and then converted to create a single BMM_MODEL instance.

More than one format for representing serialised BMM models is possible, each having its load, validation and error-reporting logic. The common elements of the load, validate and convert logic are defined by the non format-specific classes in the package, with specific forms of the classes BMM_SCHEMA_DESCRIPTOR and BMM_SCHEMA required for each concrete format. The package above shows the relevant classes for the P_BMM version 2.x format, which is normally saved in .bmm files. Other formats may be saved in files with different extensions.

The singleton class BMM_MODEL_ACCESS acts as the entry point for client software to obtain access to loaded BMM models. Since the latter start as schema files which are typically nested according to an 'include' hierarchy, they must be parsed, validated and merged to create each 'top-level' model. The schemas are accessed via instances of the BMM_SCHEMA_DESCRIPTOR object, one for each schema file. The load() routine of this class loads a BMM schema file by direct deserialisation.

If the file is structurally correct (say ODIN, JSON etc), an in-memory schema instance will result (e.g. P_BMM_SCHEMA in the case of the P_BMM format), and its validate_created method called. If this succeeds, BMM_SCHEMA_DESCRIPTOR.bmm_schema will be set to this instance, of type BMM_SCHEMA. Subsequently, BMM_SCHEMA.merge() will be called repeatedly, which results in each bmm_schema instance being the merged result of its include children and itself. After merging, BMM_SCHEMA_DESCRIPTOR.validate_merged() will be called, and if successful, a call to create_model() will result in BMM_SCHEMA_DESCRIPTOR.model being populated.

Each successfully loaded model is thus instantiated as a BMM_MODEL, and retrievable by calling BMM_MODEL_ACCESS.bmm_model() with a model key, which is a model identifier with full, partial or no version part. In the latter cases, the most recent version model is retrieved for the key. For example, the keys "openEHR_EHR_1.0.4", "openEHR_EHR_1.0", "openEHR_EHR_1", and "openEHR_EHR" will all match the "openEHR_EHR_1.0.4" model, assuming it is the most recent version available. This is convenient for matching models to artefacts (e.g. archetypes) that only mention the model publisher and name, but no version.

The following screenshot shows the BMM schema configuration dialog in the openEHR ADL Workbench, including some meta-data, validation status etc, and also the schema nesting structure. A single hierarchy of schemas corresponds to a single instantiated BMM model.

The screenshot below shows a number of merged BMM models loaded into the AWB, including some of the packages and classes for the openehr_ehr_extract_1.0.4 model.

The core package defines the main BMM meta-model, within which the model sub-package defines the top-level structure of a model which is an instance of the BMM. The UML for this package is shown below.

In a BMM model, names typically appear in the common case-sensitive form used by the model users, and may therefore follow one of a number of common conventions, including 'camel case', 'snake-case' and so on. When used computationally within an instantiated BMM model, it is assumed that case-insensitive matching is used. This means that the class name "Hashable" refers to the same class as "HASHABLE". Note however that underscores are not removed during matching, so that the classes "HashMap" and "HASH_MAP" are understood as different classes.

In BMM, a model is understood as a set of package and module definitions that are developed and maintained as a unit, by some organisation, and usually having an associated hierarchical namespace. The abstract BMM_MODULE class is the ancestor for any kind of module, which is understood as a container for features of various kinds, including the usual properties, routines, and so on. A BMM model is structured in the same general way as a UML model, i.e. with a hierarchical package containment structure and a set of module definitions, where a commonly used type of module is the class. The following illustrates the structure of a typical 'class' or 'object' model.

The BMM_MODEL class defines the single instance of each distinct BMM model that may exist within a collection of models, such as shown in the model_access package above. It provides an interface that enables any class definition to be retrieved, as well as various accessor functions to interrogate the model. A BMM Model has a name (the inherited name attribute) that is used to identify the model as a whole within a system using multiple models. It contains a number of other meta-data attributes describing authorship etc, and otherwise contains a list of package and class definitions.

While a BMM model defines a model in terms of class declarations, it must always have a top class named Any from which all others inherit. Similar to the root class in a typical OOPL type systems (sometimes called 'Object'), the Any class defines semantics true for all objects such as equality (i.e. semantics for an '=' operator) and copying.

A BMM model may define its own Any class, but if it does not, the BMM_MODEL instance representing the model will produce a standard 'Any' class via the any_class_definition() method. This will create the following structure, including a default package structure, and an Any type.

The Any type defined by the model’s Any class, or else the default one above, will be used as the inheritance parent for every class in the model that doesn’t have any other inheritance parent. As a result, the inheritance graph will always have the Any type as its top node.

One of the foundational distinctions in the BMM is between class and type, in common with the type systems of the modern forms of most object-oriented languages, but in contrast to the UML meta-model. This division is reflected in the two top-level meta-classes BMM_CLASS and BMM_TYPE, and their respective descendants, as shown in the following UML diagram.

Classes are definitional entities, while types are understood in BMM as the formal generators of instances (where non-abstract), as the basis of static typing in a formal model, and dynamic conformance, i.e. at execution time, when polymorphic attachment is possible. Most types are specified via the definitions of classes and their constituent parts. Types are used for the following purposes in a BMM model:

A simple example of typing of properties is shown in the instance diagram below.

Most types are based on one or more defining class(es), which provide the formal definition for the type. The exceptions are formal generic parameters (e.g. the T in List<T>) and the special types for tuples and routine signatures, which are treated as built-in. The BMM meta-type BMM_TYPE and its descendants define the kinds of types available in a BMM model. The design of the types part of the BMM is based on a taxonomy that makes various distinctions convenient to a formalism intended for modelling rather than pure programming. This leads in particular to the top-level distinction between unitary and container meta-types. The taxonomy is illustrated below, including differentiae.

BMM_TYPE includes features common to all meta-types:

Below BMM_TYPE are the abstract meta-type BMM_UNITARY_TYPE and the concrete meta-type BMM_CONTAINER_TYPE and its specialisation BMM_INDEXED_CONTAINER_TYPE. BMM_UNITARY_TYPE is a meta-type for types whose instances are unitary i.e. singular, while the container meta-types correspond to collections of instances. The latter are further described below. This distinction is made to enable BMM to directly represent the notion of collections in the type system rather than treating them in the same way as any other type, which would force modellers (i.e. authors of actual BMM models) to state concrete containment types such as ArrayedList<Packet>, where ArrayedList would have to be defined in the model as well as Packet.

Unitary meta-types are further distinguished as formal generic parameters (BMM_PARAMETER TYPE) and effective types, i.e. concrete unitary types. The former meta-type is used to represent replaceable formal generic parameters (typically 'T', 'U' within types such as List<T> etc) within generic type declarations.

Effective types have as their meta-type BMM_EFFECTIVE_TYPE. Its subtypes are BMM_MODEL_TYPE, a meta-type for types defined by classes in the model (thus characterised by the property base_class: BMM_CLASS), BMM_TUPLE_TYPE, a meta-type for tuples (a list of objects of varying types), and BMM_SIGNATURE, a meta-type representing signatures of routines and typed model elements (properties, variables etc).

BMM_MODEL_TYPE divides into BMM_SIMPLE_TYPE and BMM_GENERIC_TYPE, corresponding to the standard notions of types familiar in modern programming languages. The class definitions of instances (i.e. BMM model class definitions) of these meta-types are available via the property base_class, of meta-type BMM_CLASS for a BMM simple type, and BMM_GENERIC_CLASS for BMM generic type.

These various concrete meta-types are described in more detail below.

A simple type is a type based only on a simple class, which is a class with no formal generic parameters. An instance of a simple type is fully described by the class on which it is based, with the only difference being the usual object-oriented possibility of polymorphic attachments of sub-objects whose dynamic types conform to their static type counterparts in the original simple type. Thus, for example, a class Organisation may have a property manager of static type Employee. An instance of the simple type Organisation might have its manager property attached to an instance of Manager, which is legal as long as Manager conforms to Employee, which it will do if Manager is defined as a subtype of Employee.

A generic type is a type based on a generic class, which has one or more formal type parameters that are substituted by actual types in its declaration. For example, the generic type Interval<Quantity> can be used in a model that contains the generic class Interval<T:Ordered> and Quantity. The general case is that the generic parameter substitution type (BMM_GENERIC_TYPE.generic_parameters) for any formal parameter (BMM_GENERIC_CLASS.generic_parameters) is of meta-type BMM_UNITARY_TYPE.

A typical programmatic usage of such a type, and its instantiated BMM model structure is shown below.

The parameters of a generic type may be:

Consequently, a generic type may be:

The first case is detected via the function is_closed defined on BMM_GENERIC_TYPE, while the function is_partially_closed distinguishes the latter two cases.

The following shows the BMM instance structure of a generic type that is open.

Since the meta-type of BMM_GENERIC_TYPE.generic_parameters in the BMM is BMM_UNITARY_TYPE, constructions such as MyGenericType<List<OtherType>> are prevented, due to the concrete parameter type List<OtherType> being an instance of BMM_CONTAINER_TYPE rather than of BMM_UNITARY_TYPE. Such constructions are nearly always wrong, and not needed in a model expressed in BMM, because containment can be expressed where the formal generic parameter is used, not where the concrete parameter is declared. The following diagram shows the BMM concrete model structure created for a generic type whose formal parameter type is used in this way, i.e. within a container type.

The meta-type BMM_TUPLE_TYPE enables the type of a tuple i.e. an array of objects each of which may be of any type, to be stated in terms of other types. This is mostly used to state the type of a set of arguments in the BMM_SIGNATURE class, but standalone tuple types may also be used in a model, providing roughly the effect of an anonymous class (or a struct in C/C++).The notional type Tuple defined by BMM_TUPLE_TYPE is treadted as a BMM built-in, and is therefore not stated in any BMM model.

Within any typed formalism, any entity declared as having a type also has a signature. In BMM, this is is the case for any kind of feature of a class, including constants, properties, and routines. The signature of a feature is a formal construct capturing the type structure of the feature. The simplest type of signature is that of properties and constants, which may be expressed formally in a typical abstract syntax as follows:

This indicates that both have a return type, being the type of the value they are attached to at execution time.

The general form of routine signatures is as follows:

In the above, the construction [Type, …​] represents a type-tuple.

Typical examples of function signatures are as follows:

Typical procedure signatures include the following:

In order to support functional semantics such as function-as-object, the notion of signature must exist as a first order type. Since signatures have a special structure and usage, they have their own meta-type in BMM, BMM_SIGNATURE. Instances of this meta-type represent any kind of signature, and consist of argument_types, whose meta-type is BMM_TUPLE_TYPE (See [Tuple Type]), and result_type, representing the result type.

The following signatures state the types 'any function' and 'any procedure':

As for the Tuple meta-type, the notional Signature meta-type is a BMM built-in, and is not itself defined in any BMM model.

In object-oriented type theory, 'container' types are generic types whose outer class happens to have the semantics of a container object, such as a list, set etc. Container types such as List<T>, Set<T> and Hash<K,V> are used ubiquitously in object models. In the BMM, containers and non-container generic types are distinguished via the meta-classes BMM_CONTAINER_TYPE and BMM_GENERIC_TYPE respectively. This allows the BMM to treat container types in a special way. A BMM_CONTAINER_TYPE can be thought of as a 1:N counterpart to a BMM_UNITARY_TYPE, such as the type List<Paragraph> with respect to Paragraph. BMM_GENERIC_TYPE is thus used for objects considered to be singular, but whose types are a product of the base class and one or more parameter types, e.g. Interval<Quantity>.

The explicit provision of BMM_CONTAINER_TYPE enables BMM models to mention logical linear container types such as List<T> and Set<T>, on the assumption of their standard semantics in computer science , without worrying about providing concrete types which may be numerous and also variable across programming languages, e.g. ArrayedList<T>, LinkedSet<T>, ArrayedStack<T> and so on.

List and Set semantics are achieved via the BMM_CONTAINER_TYPE attributes is_ordered and is_unique, used in the standard combinations i.e.:

The following diagram shows how the container type List<Paragraph>, declared as the type of an attribute paragraphs in a class Document, is represented in a BMM model.

The semantics of indexed containers, commonly known under the type names Hash<K,V>, HashMap<K,V>, HashTable<K,V>, Dictionary<K,V> and so on, are represented by the meta-type BMM_INDEXED_CONTAINER_TYPE, which inherits from BMM_CONTAINER_TYPE, and adds the property index_type. The latter type represents the key type, which must be such that hash values can be generated, and may be any type, but practically speaking, is almost always a String, Integer, or a Date/Time type.

The following diagram shows how the container type Hash<String, Person> is represented in a BMM model.

An algorithm to determine conformance of two type-names (e.g. to implement BMM_MODEL.type_conforms_to()) is as follows:

The above model produces a number of outcomes that are not necessarily immediately obvious or expected, including:

This section describes the semantics of the BMM_CLASS meta-class, its sub-types, constituent parts and relationships. The parts of a class are collectively known as features, and consist of functions, procedures, constants and properties, which appear in feature groups. The following UML illustrates classes and relationships to constituent feature meta-types. Features are described in detail in the following section.

Class definitions are the definitional basis of a BMM model, i.e. they are the means of defining the types that are statically used in the model, and the dynamic types generated at runtime. Types are thus derived entities.

The top meta-class BMM_CLASS defines two properties inherent in classes defined in a model, and derived in resulting types: is_abstract and is_primitive. The Boolean attribute is_abstract indicates a class that cannot be directly instantiated. The attribute is_primitive indicates that a class is considered to be part of a primitive type set (typically corresponding to primitive types in another type system). Primitive status has no effect on BMM model semantics, and is provided as a convenience for visualisation and type-system mapping.

BMM distinguishes between simple and generic class definitions via two descendants of BMM_CLASS, i.e. BMM_SIMPLE_CLASS and BMM_GENERIC_CLASS, with the first providing a concrete form of BMM_CLASS that applies to non-generic classes, and the latter defining the additional semantics of generic classes. The meta-type BMM_ENUMERATION is a specialisation of BMM_SIMPLE_CLASS used to represent enumeration classes in BMM models. The meta-types are further described below.

The simplest type of class definition in a model is an instance of the meta-type BMM_SIMPLE_CLASS, and has a 1:1 relationship with its type. Such classes might be specified in the following abstract syntax:

The generic class meta-type BMM_GENERIC_CLASS adds generic parameters to BMM_CLASS, enabling formal generic parameters to be represented. Each such parameter is expressed using an instance of BMM_PARAMETER_TYPE which names the parameter and optionally allows a type constraint to be associated with it, in the usual object-oriented fashion. In BMM, formal parameters have single-letter names, such as 'T', 'U' etc, following typical usage in programming languages. A generic class may also be primitive. Generic classes can be defined in a syntax similar to the following.

The following example shows a generic class Interval<T:Ordered>, which is a class Interval with one formal parameter T constrained to be of type Ordered or any descendant.

The value range of any defined type is by default open, meaning that its instances may take any value allowed by the type definition. For primitive types such as String and Integer, this means that any String or Integer value is a valid instance. For composed types, instances are composed of hierarchies of values which are similarly un-constrained with respect to their types.

A useful derived form of any concrete type definition (i.e. instance of BMM_EFFECTIVE_TYPE in a model) is one that constrains the legal values of its instances to a particular set of values. The Pascal language provided a well-known precedent, 'sub-range types' that could restrict primitive type value ranges. BMM supports two kinds of range constraint: enumeration and 'value sets'. The additional meta-classes are shown below.

The following sub-sections describe qualifiers that may be used on any class definition to achieve a specific status within the model system. BMM qualifiers are designed to map to typical features in programming languages.

A class defined within a model may include invariants, i.e. assertions relating to its state that hold true before and after all public routine calls. Assertions are instances of the class BMM_ASSERTION, which is a tagged Boolean-valued Expression.

The following shows classes with invariants.

Inheritance in BMM is a relation between a class and one or more types, rather than classes, as in many class-based formalisms. This is primarily to allow classes to be based on specific generic types, rather than just the 'open' type represented by the underlying classes. Multiple inheritance is permitted, with same-named features from different types being treated as clashes needing resolution. See Section 12.1 for a detailed description.

The class meta-model as defined here entails certain choices that have consequences, including:

Within the definition of each class in a BMM model are found the declarations of its features, consisting of routines, properties and constants. The overall meta-model of features, as well as the elements that occur within them, namely parameters and local variables is shown below, and described in this section.

The taxonomy of meta-types that classify the concrete meta-types representing features is somewhat complicated in an object-oriented approach by the presence of procedures, which are declared features (sometimes called commands or modifiers) that change internal object state, rather than returning a value as is the case with all other kinds of features. The consequence is that the cleanest approach to definition of meta-attributes is the use of two taxonomies, one corresponding to feature declarations (including procedures) and one to do with typed value-returning entities, which excludes procedures.

Constant features in a class are represented by the BMM meta-type BMM_CONSTANT, which is:

At runtime a constant has a value, which may be of any type, including complex types, and which is set using its generator expression (i.e. an instance of the meta-type EL_INSTANCE_REF). In the common degenerate case, generator consists simply of a literal value, but may also be a function call or other expression valid in the context of the scoping class. This latter capability is the means by which computed constants are supported.

The following abstract syntax illustrates how constants may be defined in a BMM model.