openEHR logo

Basic Meta-Model (BMM)

Issuer: openEHR Specification Program

Release: LANG development

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: reflection, meta-model, UML, BMM

openEHR components
© 2016 - 2026 The openEHR Foundation

The openEHR Foundation is an independent, non-profit foundation, facilitating the sharing of health records by consumers and clinicians via open specifications, clinical models and open platform implementations.

Licence

image Creative Commons Attribution-NoDerivs 3.0 Unported. https://creativecommons.org/licenses/by-nd/3.0/

Support

Issues: Problem Reports
Web: specifications.openEHR.org

Amendment Record

Issue Details Raiser Completed

LANG Release 1.1.0 (unreleased)

2.2.4

SPECLANG-14. Formalise the BMM v2/v3 split: this specification is established as a separate, stable BMM document in the LANG component; the evolved meta-model is maintained in the separate BMM v3 specification.

S Iancu

31 May 2026

LANG Release 1.0.0

2.2.3

SPECLANG-2. Add Basic Meta-Model (BMM) spec to LANG component.

openEHR SEC

07 Nov 2017

2.2.2

Improve and update introductory text in the Overview section.

E Sundvall,
T Beale

03 Nov 2017

2.2.1

Rename P_BMM_SIMPLE_TYPE_OPEN to P_BMM_OPEN_TYPE;
Remove BMM_CLASSIFIER.conformance_type_name;
Rename P_BMM_GENERIC_PARAMETER.create_bmm_generic_parameter_definition to create_bmm_generic_parameter;
Remove inheritance from P_BMM_PACKAGE_CONTAINER to P_BMM_MODEL_ELEMENT;
Make P_BMM_MODEL_ELEMENT abstract;
Correct P_BMM_ENUMERATION.items_names cardinality to multiple;
Constrain BMM_GENERIC_PARAMETER.name and P_BMM_GENERIC_PARAMETER.name to one character and upper case.

C Nanjo,
T Beale

02 Mar 2017

2.2.0

Rename BMM_CLASSIFIER.as_type_string to type_name and as_conformance_type_string to conformance_type_name.
Move and rename BMM_TYPE.as_display_type_string to BMM_CLASSIFIER.type_signature. Add redefinitions in relevant descendant classes.
Rename BMM_SIMPLE_TYPE_OPEN to BMM_OPEN_TYPE.
Add new class BMM_TYPE_ELEMENT in preparation for BMM 3 refactoring.
Remove class P_BMM_CLASSIFIER.
Add missed inheritance from P_BMM_PROPERTY to P_BMM_MODEL_ELEMENT.
Rename BMM_SCHEMA to BMM_MODEL.

T Beale

20 Jun 2016

Add missing inheritance from P_BMM_SCHEMA to BMM_SCHEMA_CORE.
Correct naming of bmm_xxx_definition, create_bmm_xxx_definition in P_BMM_XXX classes to bmm_xxx, create_bmm_xxx etc.

T Beale

18 Apr 2016

2.1.0

Initial writing based on ADL Workbench implementation.

T Beale

08 Feb 2016

Acknowledgements

Primary Author

  • Thomas Beale, Ars Semantica; openEHR Foundation Management Board.

Contributors

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.

  • Patrick Langford, NeuronSong LLC, Utah, USA

  • Claude Nanjo MA African Studies., M Public Health, Cognitive Medical Systems Inc., California, USA

  • Harold Solbrig, Mayo Clinic, Rochester, USA

  • Erik Sundvall PhD, Linkoping University, Sweden

Trademarks

  • 'openEHR' is a registered trademark of the openEHR Foundation

  • 'Java' is a registered trademark of Oracle Corporation

  • 'C#' is a registered trademark of Microsoft Corporation

  • 'OMG' and 'UML' are registered trademarks of the Object Management Group

  • 'MagicDraw' is a registered trademark of NoMagic Inc

  • 'Rational Software Architect' is a registered trademark of IBM Corporation.

1. Preface

1.1. Purpose

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.

1.2. Status

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

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

TBD: (example To Be Determined paragraph)

1.3. Feedback

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.

1.4. History

The Basic Meta-Model originated in the openEHR BASE component, where it was published up to and including BASE Release 1.0.4. With the establishment of the openEHR LANG (Generic Languages) component, the BMM specification was migrated to LANG, which is now its normative home. This document describes the stable v2.x form of BMM, i.e. the form implemented by current openEHR tooling such as Archie.

Continued development of the meta-model, extending it with an expression and statement meta-model together with richer feature and signature metadata, is carried out separately and is documented in the BMM v3 specification. The v2.x form described here remains the normative, tool-implemented version.

The P_BMM persistence model, which defines the serialised schema form of a BMM model together with its ODIN syntax, is specified separately in the BMM Persistence specification.

2. Overview

2.1. Introduction

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:

  • MagicDraw 18.5 or higher UML/XMI;

  • Basic Meta-Model (BMM) format, i.e. the format of this specification.

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.

Note
Other than for working with particular tools designed to use BMM, BMM is not a required formalism for implementing openEHR, and other methods of accessing models computably may be used, including UML and software implementations of the openEHR Reference Model.

2.2. Current State of the Art

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:

  • the UML 2.x specifications are exceedingly complex (see OMG site for specifications; UML 2.1.2 'superstructure' = 738pp; UML 2.1.2 'infrastructure' = 224pp);

  • the XMI 2.x specification is correspondingly complex, which seems to have so far prevented reliable tool interoperability (recognised as a critical issue by OMG in 2015);

  • the Design By Contract (DbC) concept is supported via the use of OCL 2.0 constraints in class models, although there are semantic holes, e.g. proper semantics through inheritance;

  • for some, XML schema represents a way of expressing object models, but in fact is not semantically suitable for this purpose, primarily due to its different inheritance model. It can be and is used (including in openEHR) as a derivative serialisation representation, but from the point of view of specification, it is deficient in having non-object-oriented inheritance semantics, no generic classes, no representation of non-data members, and only marginal support for design by contract.

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

  • poor support for OCL and design by contract in most tools;

  • variable support for generic (i.e. template) classes; even those tools that properly implement the UML 2.5 specification are still very hard to use for defining generic classes because of problems in the specification that remain unaddressed;

  • problems with qualified attributes, which are used to represent identifier references to objects rather than direct references;

  • variable support for XSD generation across tools, where the results are wildly wrong in some tools;

  • in some tools, it is impossible to define an abstract formal model - the only option is to select a particular programming language profile such as Java or C# and thus get locked into the limitations of those languages (messy type systems, weak inheritance semantics, language-specific notion of types such as Array<T>, List<T>, etc.).

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.

Note
Other tools may well perform as well or better, and in any case, all tools change over time. No endorsement of a particular tool is intended here.

2.3. Design

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:

  • rm_access: the interface to most features including schema load/reload, generally used by an application as a reflection library;

  • core: the core BMM classes used for in-memory representation of an object model;

  • persistence: a simplified version of the core classes prefixed with P_BMM_, used for persistence and human authoring, which allow file (i.e. schema) inclusion and re-use.

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.

LANG bmm packages
Figure 1. Package Overview

The normal use of BMM is as follows:

  • create a P_BMM schema in the form of one or more files, using the P_BMM_ form of the model. This is easy to understand by copying existing examples;

  • locate these files in a suitable place for use with a tool such as the openEHR ADL Workbench and LinkEHR.

2.4. Schema Format

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.

2.5. A Note on Language

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:

feature (of a class)

any stored or computed element of a class, including constants, attributes (properties) and routines (methods);

property

a stored class feature; also known as 'attribute';

routine

a computed class feature that may be either value-returning (a function) or work-performing (a procedure);

function

a routine that computes and returns a value; typically causes no side-effects in the object;

procedure

a routine that performs a computation; typically has side-effects;

generic (class or type)

a kind of class or type that has parameters of other types; known as 'template' type in some programming languages.

3. BMM in Use

BMM schemas as used in the openEHR ADL Workbench (AWB) provide an illustration of their use and visualisation. The following screenshot shows the BMM schema configuration dialog in the AWB, including some meta-data, validation status etc, and also the schema nesting structure.

awb schemas config
Figure 2. BMM schema configuration

The screenshot below shows a number of BMMs loaded into the AWB, including some of the packages and classes for the 'openehr_ehr_extract_1.1.0' model.

awb loaded bmm schemas
Figure 3. BMM schemas loaded

The following shows a single class in the inheritance-flattened properties view, otherwise known as the 'flat view'. The structure of the class as properties, types, multiplicities, inheritance etc are all provided by the in-memory BMM classes.

awb class properties
Figure 4. BMM class - properties view

The following shows a class in a 'closure' view, which is a computed reachability graph of a fully inheritance-flattened class and all properties, including recursive references.

awb class closure
Figure 5. BMM class - closure view

One of the main uses of the BMM in the ADL Workbench and other similar tools is to provide a computable form of the information model ('reference model' in openEHR) for use with archetypes. The following shows an archetype for which each node has its RM class shown (in colour), and additionally, the inclusion of non-archetyped attributes from the classes of the archetype nodes.

archetype rm
Figure 6. ADL archetype with BMM class properties

4. RM Access Package

4.1. Overview

The rm_access package provides an interface for the application to load and access BMM schemas, and is shown below.

LANG bmm.rm access
Figure 7. bmm.rm_access Package

4.2. Class Definitions

4.2.1. REFERENCE_MODEL_ACCESS Class

Class

REFERENCE_MODEL_ACCESS

Description

Access to service interface to BMM object model.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

schema_directories: List<String>

List of directories where all the schemas loaded here are found.

0..1

all_schemas: Hash<String,SCHEMA_DESCRIPTOR>

All schemas found and loaded from schema_directories. Keyed by schema_id, i.e. model_publisher '' schema_name '' model_release, e.g. openehr_rm_1.0.3.

0..1

valid_models: Hash<String,BMM_MODEL>

Top-level (root) models in use. Keyed by logical schema_name, i.e. model_publisher '_' model_name, e.g. "openehr_rm".

Functions

Signature

Meaning

1..1

initialise_with_load_list (
a_schema_dirs: List<String>[1],
a_schema_load_list: List<String>
): void

Initialise with a specific schema load list, usually a sub-set of schemas that will be found in the directories a_schema_dirs.

1..1

initialise_all (): void

Initialise with all schemas found in the schema directories.

1..1

reload_schemas (): void

Reload all schemas.

4.2.2. SCHEMA_DESCRIPTOR Class

Class

SCHEMA_DESCRIPTOR

Description

Descriptor for a BMM schema. Contains a meta-data table of attributes obtained from a mini-ODIN parse of the schema file.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

p_schema: P_BMM_SCHEMA

Persistent form of model.

0..1

schema: BMM_MODEL

Computable form of model.

1..1

schema_id: String

Schema id, formed from meta_data model_publisher '' schema_name '' model_release, e.g. openehr_rm_1.0.3.

1..1

meta_data: Hash<String,String>

Table of \{key, value} pairs of schema meta-data (bmm_version, model_publisher, schema_name, model_release, schema_revision, schema_lifecycle_state, schema_description, schema_path).

0..1

includes: List<String>

Schema_ids of schemas included by this schema.

Functions

Signature

Meaning

1..1

is_top_level (): Boolean

True if this is a top-level schema, i.e. not included by some other schema.

1..1

is_bmm_compatible (): Boolean

True if the BMM version found in the schema (or assumed, if none) is compatible with that in this software.

1..1

load (): void

Load schema into in-memory form.

1..1

validate (): void

Validate entire schema.

1..1

validate_includes (
all_schemas_list: List<String>
): void

Validate includes list for this schema, to see if each mentioned schema exists in read schemas.

1..1

create_schema (): void

Create schema.

5. Core Package

5.1. Overview

The core package, shown below, defines the main BMM model.

LANG bmm.core
Figure 8. bmm.core Package

5.2. Semantics

5.2.1. Basics

Three top-level classes define basic abstract semantics for all other entities in the BMM: BMM_MODEL_ELEMENT, BMM_CLASSIFIER and BMM_TYPE. The first of these introduces features common to all elements of any BMM, such as documentation. The class BMM_CLASSIFIER is the abstract parent of anything that functions as the type of a property (viz: classes, types and generic parameters), while its descendant BMM_TYPE defines the semantics of types of instances, described below.

The BMM_CLASSIFIER class has a small number of important features that establish formally the meaning of various kinds of class names, type names etc, as follows:

  • type_name: the effective type of an entity; for simple classes, this will just be the class name (BMM_CLASS.name); for generic and container classes it will be generic name such as List<T>, Interval<T> etc; for feature types it will be the declared type, i.e. a simple name, an open type name (e.g. T) or a generic type name (e.g. Interval<Time>);

  • type_signature: a form of the type name that can be used as a fully-defined type signature, which for generic classes includes generic constrainer types, giving a signature such as Interval<T:Ordered>;

  • conformance_type_name: a reduced form of the type useful in some circumstances that is either a simple class name, the contained type for a container type (e.g. ELEMENT from the type List<ELEMENT>), and the root type from a generic type (e.g. Interval from Interval<T>).

In addition, concrete classes such as BMM_CLASS and BMM_PROPERTY have a simple name property, corresponding to the literal names of these entities.

5.2.2. Classes and Types

One of the foundational concepts in the BMM is a distinction between class and type, in common with the type systems of the modern forms of most object-oriented languages. Classes are definitional entities, while 'type' has two meanings: as the static (design time) type of a class feature (property or function result) and as the dynamic (run-time) type of the object referred to by or computed by that feature. At design time, the type of a property in a BMM model can be one of the following:

  • a BMM_SIMPLE_TYPE - corresponds to a simple class;

  • a BMM_OPEN_TYPE - corresponds to a generic parameter type from the class type definition, e.g. T, U etc;

  • a BMM_GENERIC_TYPE - a type generated by the use of a generic type with filled type parameters, e.g. Interval<Time>;

  • a BMM_CONTAINER_TYPE - a type generated by the use of a linear container type such as List<T>, Hash<T,U> with actual generic parameters.

In object-oriented type theory, the last two are really the same thing, but the BMM treats them slightly differently for reasons of clarity: a BMM_CONTAINER_TYPE can be thought of as a 1:N counterpart to a BMM_SIMPLE_TYPE, whereas BMM_GENERIC_TYPE is typically used for objects considered to be singular, but whose types are a product of a special container and one or more parameter types.

5.2.3. Inheritance

The BMM supports single and multiple inheritance, although it does not distinguish between different types of inheritance relation as some programming languages do. The evaluation of inheritance relations defined in a BMM schema results in an acyclic graph such that ancestors and descendants can be visualised for any class. The following screen shot shows the ancestors view of a class OBSERVATION.

awb class ancestors
Figure 9. BMM class - ancestors view

The next screenshot shows the descendants view of one of the ancestor classes of the same class.

awb class descendants
Figure 10. BMM class - descendants view

Multiple inheritance is typically used in the definition of classes that have a Liskov substitution inheritance relation as well as an implementation inheritance relation. The following shows a class DV_INTERVAL<T> multiply inheriting from Interval<T> and DATA_VALUE.

awb multiple inheritance
Figure 11. BMM class - descendants view

5.2.4. Classes and Properties

Class properties are defined using the generic class BMM_PROPERTY <T: BMM_TYPE>. This approach provides a direct way of expressing the semantics of property meta-types as listed above. The properties of a class can be understood in two forms. In an original model definition, each class definition states the features it introduces with respect to its inheritance parents. We can think of this list of properties as a differential set. In contrast, the effective set of properties for a class is the result of evaluating these lists of properties down the inheritance hierarchy to obtain the flat set of properties. The features properties and flat_properties defined on BMM_CLASS provide access to these two lists for any class.

5.3. Class Definitions

5.3.1. BMM_DEFINITIONS Class

Class

BMM_DEFINITIONS

Description

Definitions used by all BMM packages.

Constants

Signature

Meaning

1..1

Bmm_internal_version: String = 

Current internal version of BMM meta-model, used to determine if a given schema can be processed by a given implementation of the model.

1..1

Schema_name_delimiter: String = "::"

Delimiter used to separate schema id from package path in a fully qualified path.

1..1

Package_name_delimiter: String = "."

Delimiter used to separate package names in a package path.

1..1

Bmm_schema_file_extension: String = ".bmm"

Extension used for BMM files.

5.3.2. BMM_MODEL_ELEMENT Class

Class

BMM_MODEL_ELEMENT (abstract)

Description

Ancestor class of most BMM model elements.

Inherit

BMM_DEFINITIONS

Attributes

Signature

Meaning

0..1

documentation: String

Optional documentation of this element.

5.3.3. BMM_SCHEMA_CORE Class

Class

BMM_SCHEMA_CORE

Description

Core properties of BMM_SCHEMA.

Attributes

Signature

Meaning

1..1

rm_publisher: String

Publisher of model expressed in the schema. Persisted attribute.

1..1

rm_release: String

Release of model expressed in the schema as a 3-part numeric, e.g. "3.1.0". Persisted attribute.

1..1

schema_name: String

Name of model expressed in schema; a 'schema' usually contains all of the packages of one 'model' of a publisher. A publisher with more than one model can have multiple schemas. Persisted attribute.

1..1

schema_revision: String

Revision of schema. Persisted attribute.

1..1

schema_lifecycle_state: String

Persisted attribute.

1..1

schema_author: String

Primary author of schema. Persisted attribute.

1..1

schema_description: String

Description of schema. Persisted attribute.

0..1

schema_contributors: List<String>

Contributing authors of schema. Persisted attribute.

0..1

archetype_parent_class: String

Name of a parent class used within the schema to provide archetype capability, enabling filtering of classes in RM visualisation. If empty, 'Any' is assumed. Persisted attribute.

0..1

archetype_data_value_parent_class: String

Name of a parent class of logical 'data types' used within the schema to provide archetype capability, enabling filtering of classes in RM visualisation. If empty, 'Any' is assumed. Persisted attribute.

0..1

archetype_rm_closure_packages: List<String>

List of top-level package paths that provide the RM 'model' part in archetype identifiers, e.g. the path "org.openehr.ehr" gives "EHR" in "openEHR-EHR". Within this namespace, archetypes can be based on any class reachable from classes defined directly in these packages. Persisted attribute.

0..1

archetype_visualise_descendants_of: String

If archetype_parent_class is not set, designate a class whose descendants should be made visible in tree and grid renderings of the archetype definition. Persisted attribute.

Functions

Signature

Meaning

1..1

schema_id (): String

Derived name of schema, based on model publisher, model name, model release.

5.3.4. BMM_MODEL Class

Class

BMM_MODEL

Description

Model of a BMM schema (along with what is inherited from BMM_SCHEMA_CORE).

Inherit

BMM_SCHEMA_CORE, BMM_PACKAGE_CONTAINER

Attributes

Signature

Meaning

0..1

class_definitions: Hash<String,BMM_CLASS>

All classes in this schema.

Functions

Signature

Meaning

0..1

primitive_types (): List<String>

List of keys in `class_definitions' of items marked as primitive types, as defined in input schema.

0..1

enumeration_types (): List<String>

List of keys in `class_definitions' of items that are enumeration types, as defined in input schema.

1..1

class_definition (
a_name: String[1]
): BMM_CLASS

Retrieve the class definition corresponding to `a_type_name' (which may contain a generic part).

1..1

enumeration_definition (
a_name: String[1]
): BMM_ENUMERATION

Retrieve the enumeration definition corresponding to `a_type_name'.

1..1

property_definition (): BMM_PROPERTY

Retrieve the property definition for `a_prop_name' in flattened class corresponding to `a_type_name'.

1..1

ms_conformant_property_type (
a_bmm_type_name: String[1],
a_bmm_property_name: String[1],
a_ms_property_name: String[1]
): Boolean

True if `a_ms_property_type' is a valid 'MS' dynamic type for `a_property' in BMM type `a_bmm_type_name'. 'MS' conformance means 'model-semantic' conformance, which abstracts away container types like List<>, Set<> etc and compares the dynamic type with the relation target type in the UML sense, i.e. regardless of whether there is single or multiple containment.

1..1

property_definition_at_path (): BMM_PROPERTY

Retrieve the property definition for `a_property_path' in flattened class corresponding to `a_type_name'.

0..1

all_ancestor_classes (
a_class: String[1]
): List<String>

Return all ancestor types of `a_class_name' up to root class (usually 'ANY', 'Object' or something similar). Does not include current class. Returns empty list if none.

1..1

type_conforms_to (
a_desc_type: String[1],
an_anc_type: String[1]
): Boolean

Check conformance of `a_desc_type' to `an_anc_type'; the types may be generic, and may contain open generic parameters like 'T' etc. These are replaced with their appropriate constrainer types, or Any during the conformance testing process.

5.3.5. BMM_PACKAGE_CONTAINER Class

Class

BMM_PACKAGE_CONTAINER

Description

Abstraction of a BMM model component that contains packages and classes.

Inherit

BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

0..1

packages: Hash<String,BMM_PACKAGE>

Child packages; keys all in upper case for guaranteed matching.

Functions

Signature

Meaning

1..1

package_at_path (
a_path: String[1]
): BMM_PACKAGE

Package at the path `a_path'.

1..1

do_recursive_packages (
action: PROCEDURE[1]
): ``

Recursively execute `action', which is a procedure taking a BMM_PACKAGE argument, on all members of packages.

1..1

has_package_path (
a_path: String[1]
): Boolean

True if there is a package at the path `a_path'; paths are delimited with Package_name_delimiter.

5.3.6. BMM_PACKAGE Class

Class

BMM_PACKAGE

Description

Abstraction of a package as a tree structure whose nodes can contain other packages and classes.

Inherit

BMM_PACKAGE_CONTAINER

Attributes

Signature

Meaning

1..1

name: String

Name of this package. This name may be qualified if it is a top-level package.

0..1

classes: List<BMM_CLASS>

Classes listed as being in this package.

Functions

Signature

Meaning

0..1

root_classes (): List<BMM_CLASS>

Obtain the set of top-level classes in this package, either from this package itself or by recursing into the structure until classes are obtained from child packages. Recurse into each child only far enough to find the first level of classes.

1..1

path (): String

Full path of this package back to root package.

5.3.7. BMM_CLASSIFIER Class

Class

BMM_CLASSIFIER (abstract)

Description

Abstract idea of specifying a type either by definition or by reference.

Inherit

BMM_MODEL_ELEMENT

Functions

Signature

Meaning

1..1

type_name (): String

Formal string form of the type as per UML.

1..1

type_category (): String

Generate a type category of main target type from Type_category_xx values.

1..1

type_signature (): String

Signature form of the type, which for generics includes generic parameter constrainer types e.g. Interval<T:Ordered>.

1..1

base_class (): BMM_CLASS

Main design class for this type, from which properties etc can be extracted.

0..1

flattened_type_list (): List<String>

Completely flattened list of type names, flattening out all generic parameters.

5.3.8. BMM_TYPE_ELEMENT Class

Class

BMM_TYPE_ELEMENT (abstract)

Inherit

BMM_CLASSIFIER

5.3.9. BMM_TYPE Class

Class

BMM_TYPE (abstract)

Description

Abstract idea of specifying a type in some context. This is not the same as 'defining' a class. A type specification is essentially a reference of some kind, that defines the type of an attribute, or function result or argument. It may include generic parameters that might or might not be bound. See subtypes.

Inherit

BMM_TYPE_ELEMENT

Functions

Signature

Meaning

1..1

has_type_substitutions (): Boolean

Determine if there are any type substitutions.

0..1

type_substitutions (): List<String>

List of type substitutions if any available for this type within the current BMM model.

5.3.10. BMM_CLASS Class

Class

BMM_CLASS

Description

Definition of a class in an object model. A class is type that may be open or closed in terms of other types mentioned within.

Inherit

BMM_CLASSIFIER

Attributes

Signature

Meaning

1..1

name: String

Name of this class. Note that unlike UML, names of classes are just the root name, even if the class is generic.

0..1

ancestors: Hash<String,BMM_CLASS>

List of immediate inheritance parents.

1..1

package: BMM_PACKAGE

Package this class belongs to.

0..1

properties: Hash<String,BMM_PROPERTY>

List of attributes defined in this class.

1..1

source_schema_id: String

Reference to original source schema defining this class. Useful for UI tools to determine which original schema file to open for a given class for manual editing.

0..1

immediate_descendants: List<String>

List of immediate inheritance descendants.

1..1

is_abstract: Boolean

True if this class is abstract in its model.

1..1

is_primitive_type: Boolean

True if this class is designated a primitive type within the overall type system of the schema.

1..1

is_override: Boolean

True if this definition overrides a class of the same name in an included schema.

Functions

Signature

Meaning

0..1

all_ancestors (): List<String>

List of all inheritance parent class names, recursively.

0..1

all_descendants (): List<String>

Compute all descendants by following immediate_descendants.

0..1

suppliers (): List<String>

List of names of immediate supplier classes, including concrete generic parameters, concrete descendants of abstract statically defined types, and inherited suppliers. This list includes primitive types.

0..1

suppliers_non_primitive (): List<String>

Same as `suppliers' minus primitive types, as defined in input schema.

0..1

supplier_closure (): List<String>

List of names of all classes in full supplier closure, including concrete generic parameters. This list includes primitive types.

1..1
(redefined)

base_class (): BMM_CLASS

Main design class for this type, from which properties etc can be extracted.

1..1

package_path (): String

Fully qualified package name, of form: 'package.package'.

1..1

class_path (): String

Fully qualified class name, of form: 'package.package.CLASS' with package path in lower-case and class in original case.

0..1

flat_properties (): List<BMM_PROPERTY>

List of all properties due to current and ancestor classes, keyed by property name.

1..1
(redefined)

type_name (): String

Formal string form of the type as per UML.

5.3.11. BMM_PROPERTY Class

Class

BMM_PROPERTY<T>

Description

Model of a property definition within a class definition of an object model. Generic parameter takes care of variants.

Inherit

BMM_MODEL_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of this property in the model.

0..1

is_mandatory: Boolean

True if this property is mandatory in its class.

0..1

is_computed: Boolean

True if this property is computed rather than stored in objects of this class.

1..1

type: T

Formal type of this property.

0..1

is_im_runtime: Boolean
{default = false}

True if this property is marked with info model im_runtime property.

0..1

is_im_infrastructure: Boolean
{default = false}

True if this property was marked with info model im_infrastructure flag.

Functions

Signature

Meaning

1..1

existence (): Multiplicity_interval

Interval form of 0..1, 1..1 etc, generated from is_mandatory.

1..1

display_name (): String

Name of this attribute to display in UI.

5.3.12. BMM_CONTAINER_PROPERTY Class

Class

BMM_CONTAINER_PROPERTY

Description

Subtype of BMM_PROPERTY that represents a container type based on one of the inbuilt types List <>, Set <>, Array <>.

Inherit

BMM_PROPERTY

Attributes

Signature

Meaning

0..1

cardinality: Multiplicity_interval

Cardinality of this container.

1..1
(effected)

type: BMM_CONTAINER_TYPE

Redefined to BMM_CONTAINER_TYPE.

Functions

Signature

Meaning

1..1
(redefined)

display_name (): String

Name of this attribute to display in UI.

5.3.13. BMM_SIMPLE_TYPE Class

Class

BMM_SIMPLE_TYPE

Description

Type reference to a single type i.e. not generic or container type.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

base_class: BMM_CLASS

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE.

Functions

Signature

Meaning

1..1
(redefined)

type_name (): String

Return base_class.type_name.

5.3.14. BMM_OPEN_TYPE Class

Class

BMM_OPEN_TYPE

Description

Open type reference to a single type parameter, i.e. typically 'T', 'V', 'K' etc. The parameter must be in the type declaration of the owning BMM_CLASS.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

generic_constraint: BMM_GENERIC_PARAMETER

The generic constraint, which will be 'Any' if nothing set in original model.

Functions

Signature

Meaning

1..1

conformance_type_name (): String

Return generic_constraint.conformance_type_name.

5.3.15. BMM_CONTAINER_TYPE Class

Class

BMM_CONTAINER_TYPE

Description

Type reference that specifies containers with one generic parameter.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

container_type: BMM_CLASS

The type of the container. This converts to the root_type in BMM_GENERIC_TYPE.

1..1

base_type: BMM_TYPE

The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE.

Functions

Signature

Meaning

1..1
(redefined)

type_name (): String

Return full type name, e.g. 'List<ELEMENT>'.

5.3.16. BMM_INDEXED_CONTAINER_TYPE Class

Class

BMM_INDEXED_CONTAINER_TYPE

Description

Type reference that specifies an indexed container such as Hash<K,V>, i.e. a container whose members are accessed via a key (index) type.

Inherit

BMM_CONTAINER_TYPE

Attributes

Signature

Meaning

1..1

index_type: BMM_SIMPLE_TYPE

The key (index) type of the container, e.g. String in Hash<String,EVENT_ACTION>.

5.3.17. BMM_GENERIC_TYPE Class

Class

BMM_GENERIC_TYPE

Description

Type reference based on a generic class, e.g. 'HashTable <List <Packet>, String>'.

Inherit

BMM_TYPE

Attributes

Signature

Meaning

1..1

generic_parameters: List<BMM_TYPE>

Generic parameters of the root_type in this type specifier. The order must match the order of the owning class’s formal generic parameter declarations.

1..1

base_class: BMM_GENERIC_CLASS

The base class of this type.

Functions

Signature

Meaning

1..1
(redefined)

type_name (): String

Return the full name of the type including generic parameters, e.g. 'DV_INTERVAL<T>', 'TABLE<List<THING>,String>'.

5.3.18. BMM_GENERIC_PARAMETER Class

Class

BMM_GENERIC_PARAMETER

Description

Definition of a generic parameter in a class definition of a generic type.

Inherit

BMM_TYPE_ELEMENT

Attributes

Signature

Meaning

1..1

name: String

Name of the parameter, e.g. 'T' etc. The name is limited to 1 character and upper-case.

0..1

conforms_to_type: BMM_CLASS

Optional conformance constraint that must be another valid class name.

0..1

inheritance_precursor: BMM_GENERIC_PARAMETER

If set, is the corresponding generic parameter definition in an ancestor class.

Functions

Signature

Meaning

1..1

flattened_conforms_to_type (): String

Get any ultimate type conformance constraint on this generic parameter due to inheritance.

1..1

effective_conforms_to_type (): BMM_CLASS

Generate ultimate conformance type, which is either from `conforms_to_type' or if not set, 'Any'.

1..1
(redefined)

type_signature (): String

Signature form of the open type, including constrainer type if there is one, e.g. 'T:Ordered'.

Invariants

Inv_generic_name: name.count = 1 and name.is_upper

5.3.19. BMM_GENERIC_CLASS Class

Class

BMM_GENERIC_CLASS

Description

Definition of a generic class in an object model.

Inherit

BMM_CLASS

Attributes

Signature

Meaning

1..1

generic_parameters: Hash<String,BMM_GENERIC_PARAMETER>

List of generic parameter definitions, keyed by name of generic parameter; these are defined either directly on this class or by the addition of an ancestor class which is generic.

Functions

Signature

Meaning

0..1
(redefined)

suppliers (): List<String>

Add suppliers from generic parameters.

1..1
(redefined)

type_signature (): String

Signature form of the type, which for generics includes generic parameter constrainer types e.g. Interval<T:Ordered>.

1..1
(redefined)

type_name (): String

Formal string form of the type as per UML.

5.3.20. BMM_ENUMERATION Class

Class

BMM_ENUMERATION

Description

Definition of an enumeration type. In the BMM system, an 'enumeration' type is understood as an underlying basic type and a set of named constants of that type. It is designed so that the default type is Integer, and the default constants are numbered 0, 1, …​ Optional model elements can be specified to override the values and / or the type.

Inherit

BMM_CLASS

Attributes

Signature

Meaning

0..1

item_names: List<String>

The list of names of the enumeration. If no values are supplied, the integer values 0, 1, 2, …​ are assumed.

0..1

item_values: List<T>

Optional list of specific values. Must be 1:1 with `item_names' list.

1..1

underlying_type_name: String

Name of type any concrete BMM_ENUMERATION_* sub-type is based on, i.e. the name of type bound to 'T' in a declared use of this type.

5.3.21. BMM_ENUMERATION_STRING Class

Class

BMM_ENUMERATION_STRING

Description

String-based enumeration type.

Inherit

BMM_ENUMERATION

Attributes

Signature

Meaning

1..1
(redefined)

underlying_type_name: String
{default = "STRING"}

Name of type any concrete BMM_ENUMERATION_* sub-type is based on. Redefined to "STRING".

5.3.22. BMM_ENUMERATION_INTEGER Class

Class

BMM_ENUMERATION_INTEGER

Description

Integer-based enumeration type.

Inherit

BMM_ENUMERATION

Attributes

Signature

Meaning

1..1
(redefined)

underlying_type_name: String
{default = "INTEGER"}

Name of type any concrete BMM_ENUMERATION_* sub-type is based on. Redefined to "INTEGER".

6. Persistence

The persistence package defines a simplified form of the core BMM model, expressed as the P_BMM_* classes, suitable for serialising and human authoring of BMM schemas. Such a schema is typically saved as a .bmm file in the ODIN syntax, and supports file inclusion and re-use, so that a single logical model may be expressed as a number of schema files.

The P_BMM_* model, its class definitions and its serialised syntax are specified separately. See the BMM Persistence specification for full details.

References