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 |
|
| © 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 |
|
Support |
Issues: Problem Reports |
Amendment Record
| Issue | Details | Raiser | Completed |
|---|---|---|---|
LANG Release 1.1.0 (unreleased) |
|||
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 |
||
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, |
03 Nov 2017 |
2.2.1 |
Rename |
C Nanjo, |
02 Mar 2017 |
2.2.0 |
Rename |
T Beale |
20 Jun 2016 |
Add missing inheritance from |
T Beale |
18 Apr 2016 |
|
2.1.0 |
Initial writing based on ADL Workbench implementation. |
T Beale |
08 Feb 2016 |
Acknowledgements
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 withP_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.
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.
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.
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.
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.
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.
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.
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
List of directories where all the schemas loaded here are found. |
|
0..1 |
all_schemas: |
All schemas found and loaded from |
0..1 |
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 ( |
Initialise with a specific schema load list, usually a sub-set of schemas that will be found in the directories |
1..1 |
initialise_all (): |
Initialise with all schemas found in the schema directories. |
1..1 |
reload_schemas (): |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
p_schema: |
Persistent form of model. |
0..1 |
schema: |
Computable form of model. |
1..1 |
schema_id: |
Schema id, formed from meta_data model_publisher '' schema_name '' model_release, e.g. openehr_rm_1.0.3. |
1..1 |
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 |
Schema_ids of schemas included by this schema. |
|
Functions |
Signature |
Meaning |
1..1 |
is_top_level (): |
True if this is a top-level schema, i.e. not included by some other schema. |
1..1 |
is_bmm_compatible (): |
True if the BMM version found in the schema (or assumed, if none) is compatible with that in this software. |
1..1 |
load (): |
Load schema into in-memory form. |
1..1 |
validate (): |
Validate entire schema. |
1..1 |
Validate includes list for this schema, to see if each mentioned schema exists in read schemas. |
|
1..1 |
create_schema (): |
Create |
5. 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 asList<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.
ELEMENTfrom the typeList<ELEMENT>), and the root type from a generic type (e.g.IntervalfromInterval<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,Uetc; -
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 asList<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.
The next screenshot shows the descendants view of one of the ancestor classes of the same class.
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.
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: |
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: |
Delimiter used to separate schema id from package path in a fully qualified path. |
1..1 |
Package_name_delimiter: |
Delimiter used to separate package names in a package path. |
1..1 |
Bmm_schema_file_extension: |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
documentation: |
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: |
Publisher of model expressed in the schema. Persisted attribute. |
1..1 |
rm_release: |
Release of model expressed in the schema as a 3-part numeric, e.g. "3.1.0". Persisted attribute. |
1..1 |
schema_name: |
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: |
Revision of schema. Persisted attribute. |
1..1 |
schema_lifecycle_state: |
Persisted attribute. |
1..1 |
schema_author: |
Primary author of schema. Persisted attribute. |
1..1 |
schema_description: |
Description of schema. Persisted attribute. |
0..1 |
Contributing authors of schema. Persisted attribute. |
|
0..1 |
archetype_parent_class: |
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: |
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 |
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: |
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 (): |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
All classes in this schema. |
|
Functions |
Signature |
Meaning |
0..1 |
List of keys in `class_definitions' of items marked as primitive types, as defined in input schema. |
|
0..1 |
List of keys in `class_definitions' of items that are enumeration types, as defined in input schema. |
|
1..1 |
Retrieve the class definition corresponding to `a_type_name' (which may contain a generic part). |
|
1..1 |
enumeration_definition ( |
Retrieve the enumeration definition corresponding to `a_type_name'. |
1..1 |
property_definition (): |
Retrieve the property definition for `a_prop_name' in flattened class corresponding to `a_type_name'. |
1..1 |
ms_conformant_property_type ( |
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 (): |
Retrieve the property definition for `a_property_path' in flattened class corresponding to `a_type_name'. |
0..1 |
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 ( |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
packages: |
Child packages; keys all in upper case for guaranteed matching. |
Functions |
Signature |
Meaning |
1..1 |
package_at_path ( |
Package at the path `a_path'. |
1..1 |
do_recursive_packages ( |
Recursively execute `action', which is a procedure taking a BMM_PACKAGE argument, on all members of packages. |
1..1 |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
Name of this package. This name may be qualified if it is a top-level package. |
0..1 |
Classes listed as being in this package. |
|
Functions |
Signature |
Meaning |
0..1 |
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 (): |
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 |
||
Functions |
Signature |
Meaning |
1..1 |
type_name (): |
Formal string form of the type as per UML. |
1..1 |
type_category (): |
Generate a type category of main target type from Type_category_xx values. |
1..1 |
type_signature (): |
Signature form of the type, which for generics includes generic parameter constrainer types e.g. Interval<T:Ordered>. |
1..1 |
base_class (): |
Main design class for this type, from which properties etc can be extracted. |
0..1 |
Completely flattened list of type names, flattening out all generic parameters. |
|
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 |
||
Functions |
Signature |
Meaning |
1..1 |
has_type_substitutions (): |
Determine if there are any type substitutions. |
0..1 |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
Name of this class. Note that unlike UML, names of classes are just the root name, even if the class is generic. |
0..1 |
List of immediate inheritance parents. |
|
1..1 |
package: |
Package this class belongs to. |
0..1 |
properties: |
List of attributes defined in this class. |
1..1 |
source_schema_id: |
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 |
List of immediate inheritance descendants. |
|
1..1 |
is_abstract: |
True if this class is abstract in its model. |
1..1 |
is_primitive_type: |
True if this class is designated a primitive type within the overall type system of the schema. |
1..1 |
is_override: |
True if this definition overrides a class of the same name in an included schema. |
Functions |
Signature |
Meaning |
0..1 |
List of all inheritance parent class names, recursively. |
|
0..1 |
Compute all descendants by following immediate_descendants. |
|
0..1 |
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 |
Same as `suppliers' minus primitive types, as defined in input schema. |
|
0..1 |
List of names of all classes in full supplier closure, including concrete generic parameters. This list includes primitive types. |
|
1..1 |
base_class (): |
Main design class for this type, from which properties etc can be extracted. |
1..1 |
package_path (): |
Fully qualified package name, of form: 'package.package'. |
1..1 |
class_path (): |
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 of all properties due to current and ancestor classes, keyed by property name. |
1..1 |
type_name (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
Name of this property in the model. |
0..1 |
is_mandatory: |
True if this property is mandatory in its class. |
0..1 |
is_computed: |
True if this property is computed rather than stored in objects of this class. |
1..1 |
type: |
Formal type of this property. |
0..1 |
is_im_runtime: |
True if this property is marked with info model |
0..1 |
is_im_infrastructure: |
True if this property was marked with info model |
Functions |
Signature |
Meaning |
1..1 |
existence (): |
Interval form of |
1..1 |
display_name (): |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
cardinality: |
Cardinality of this container. |
1..1 |
type: |
Redefined to BMM_CONTAINER_TYPE. |
Functions |
Signature |
Meaning |
1..1 |
display_name (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
base_class: |
The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE. |
Functions |
Signature |
Meaning |
1..1 |
type_name (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
generic_constraint: |
The generic constraint, which will be 'Any' if nothing set in original model. |
Functions |
Signature |
Meaning |
1..1 |
conformance_type_name (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
container_type: |
The type of the container. This converts to the root_type in BMM_GENERIC_TYPE. |
1..1 |
base_type: |
The target type; this converts to the first parameter in generic_parameters in BMM_GENERIC_TYPE. |
Functions |
Signature |
Meaning |
1..1 |
type_name (): |
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 |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
index_type: |
The key (index) type of the container, e.g. |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
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: |
The base class of this type. |
Functions |
Signature |
Meaning |
1..1 |
type_name (): |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
name: |
Name of the parameter, e.g. 'T' etc. The name is limited to 1 character and upper-case. |
0..1 |
conforms_to_type: |
Optional conformance constraint that must be another valid class name. |
0..1 |
inheritance_precursor: |
If set, is the corresponding generic parameter definition in an ancestor class. |
Functions |
Signature |
Meaning |
1..1 |
flattened_conforms_to_type (): |
Get any ultimate type conformance constraint on this generic parameter due to inheritance. |
1..1 |
effective_conforms_to_type (): |
Generate ultimate conformance type, which is either from `conforms_to_type' or if not set, 'Any'. |
1..1 |
type_signature (): |
Signature form of the open type, including constrainer type if there is one, e.g. 'T:Ordered'. |
Invariants |
Inv_generic_name: |
|
5.3.19. BMM_GENERIC_CLASS Class
Class |
BMM_GENERIC_CLASS |
|
|---|---|---|
Description |
Definition of a generic class in an object model. |
|
Inherit |
||
Attributes |
Signature |
Meaning |
1..1 |
generic_parameters: |
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 |
Add suppliers from generic parameters. |
|
1..1 |
type_signature (): |
Signature form of the type, which for generics includes generic parameter constrainer types e.g. Interval<T:Ordered>. |
1..1 |
type_name (): |
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 |
||
Attributes |
Signature |
Meaning |
0..1 |
The list of names of the enumeration. If no values are supplied, the integer values 0, 1, 2, … are assumed. |
|
0..1 |
item_values: |
Optional list of specific values. Must be 1:1 with `item_names' list. |
1..1 |
underlying_type_name: |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
underlying_type_name: |
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 |
||
Attributes |
Signature |
Meaning |
1..1 |
underlying_type_name: |
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.
