Basic meta-model (BMM), Eiffel origins, uses.

[Thomas Beale]

This is a bit off topic, but I thought some people here might be interested. In our work in openEHR, we have undertaken (over nearly 20 years) a major effort of information systems and semantic engineering for the healthcare domain.

Like any large project, it has generated useful side-technologies and lessons. One of those has been to discover how bad UML is, and to have to replace it where possible. We still use UML for diagramming in our specifications (try clicking on almost any link on our specifications site), but we post-process the UML from the MagicDraw tool to fix its errors, in order to generate the formal definitions of classes in those specifications (this kind of thing).

Not only do we reprocess UML (painfully I might add - have a look at the 700+ page UML 2.5 spec to understand how bad it is), I built a replacement for XMI, called Basic Meta-Model or BMM, that we use to represent our OO models for tooling purposes (see here on Github for examples). Originally, this was so we could avoid using XMI to represent models because XMI is impossible to read, each tool has its own internal standard, and it's full of visual elements. But over the years of working with model representation and tool-building, we discovered a growing accumulation of core problems in UML, and in parallel, better ways to get things right in a meta-model.

The result is the BMM, now a formal spec in openEHR, and to my surprise, is increasingly being adopted by tool-builders in the e-health community. It's still not complete (more is needed on lambdas for example) but since it takes much of its semantics from Eiffel (with some departures as well), and is fully implemented in Eiffel and Java, I thought I would share it here.

Some of the features include:

• Concretely based on object-oriented class model concepts, rather than being a highly general model like the UML meta-model;
• Types and Classes are distinguished in the meta-model, unlike UML which has no formal concept of type;
• Types as a first-order entity allows generic types and inheritance from open, closed, or partially open generics to be properly represented, unlike in UML;
• Container types are treated as partially built-in, meaning that class features in a model are always typed to either 'unitary' or 'container' types;
• Eiffel aside: in about 98% of code that is not itself a data structure, we use ARRAYED_LIST[] and HASH_TABLE[]...
• The notion of 'range-constrained' classes is supported via enumerated types based on any model type as well as value-set constraints;
• There is no concept of an 'association' distinct from an 'attribute', as per UML, which treats lines between class boxes as formal elements.

You will see that the specification still uses UML diagrams, since there is no tool yet that does 'BMM diagramming', but I can now see how one should be built and what pitfalls it should avoid. As mentioned above, we use various tricks in the UML extractor to generate formal class specifications that fix most of its errors.

One small detail that might be of interest to Bertrand and others who have been talking for a long time about how to add enumerated types to Eiffel is the approach we took to enumerations, described here. Enumerated types are indeed more complex than they first appear, but we have useful lessons from the e-health arena that made a solution more obvious, specifically the notion of terminologies and other external 'value-sets'. Whether people think this could work for Eiffel is another matter, but at least it might be useful as an input to thinking about the problem.

One of the next improvements will be to upgrade the serial form to a proper language that will replace IDL, and of course will have more than a hint of Eiffel semantics.

There's no guarantee we got everything 'right' in BMM, but I think it is pretty good, in the sense that it has at least 3 independent implementations in use in various environments, and people seem to like using it (for one thing it is pretty easy to write a serial-form schema by hand). None of that would have been possible without Bertrand's OOSC2 and Eiffel. We can debate some details, but these works remain pretty much the standard lessons for how to think about OO properly.

- thomas beale

[Finnian Reilly]

Hi Thomas,

I was interested to read about your approach to enumerations but the link is not setup correctly.

Finnian

[Woland's Cat]

On 23/02/2019 16:11, Finnian Reilly wrote:

Hi Thomas,

I was interested to read about your approach to enumerations but the link is not setup correctly.

Weak copy-paste skills ;)

See here: specifications.openehr.org/releases/LANG/latest/bmm.html

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog | The Objective Stance