Where to find AOM2 BMM for the latest stable release (2.3.0)

Specifications ADL
1

OPT2 JSON files generated from Nedap’s VSCode extension are using the latest AOM2 release 2.3.0. This is a Stable release.

@pieterbos has generated an AOM2 BMM file for release 2.0.6 which I’m currently using (it is 5+ years old release).

It would be great to have all stable BMM files in the ITS-BMM repository. @thomas.beale offered to write the latest AOM2 BMM in another thread. I didn’t dare asking him to do it :flushed:

Since people are busy and don’t have time to keep everything in sync, I tried the route suggested by Pieter in another thread and went to the ITS-XML to generate AOM2 BMM from XML (or did he recommend OpenAPI?). No luck - the latest XML is for the release 2.0.6.

I found AOM2 release 2.2.0 in ITS-JSON.

However 2.2.0 doesn’t have the structure generated by the Nedap VSCode extension (additional attributes for “path” and “logical_path” in their “definition” nodes).

Example:

C_ATTRIBUTE has only optional “differential_path” property according to the specifications.

OPT2 JSON file has additional “logical_path” properties in C_ATTRIBUTE. This property is defined in ARCHETYPE.
“path” is in ARCHETYPE_CONSTRAINT.

Even ITS-REST is only up to AOM2 release 2.0.6.

Finally I found AM UML.

The “logical_path” is part of the ARCHETYPE in this file (I unzipped it and looked through the “com.nomagic.magicdraw.uml_model.shared_model” file) as it is in the AOM2 release 2.3.0. My eyes are :sob:

:arrow_right: Is this the file I’m looking for (and writing a novel about my journey to find it):question:

Has somebody already generated BMM files from the UML?

I’m willing to generate the missing BMM files myself (or use the alternative formats if this is the direction of openEHR).

I hope somebody with better knowledge and understanding of openEHR will direct me in the right direction of getting AOM2 release 2.3.0 BMM.

I thought that BMM files are the basis for everything in openEHR. I can’t understand how alternative formats (XML, JSON) are available for newer releases and BMMs are not.

This text enthused me about openEHR (https://openehr.org/about/what_is_openehr):

  • Tools that machine-convert domain models into technical forms that can be used to build:
    • applications (e.g. screen definitions);
    • interoperability components (message definitions) and
    • be consumed by platform implementations at runtime (data set definitions).
  • Interoperability is solved in a way commonplace outside of the healthcare domain, which is by machine-generation of schemas and software components from models, rather than by hand-building of point-to-point messages or document definitions, the historical approach in e-health. Where messages or documents are an integration requirement, a significant degree of automated openEHR model-based mapping is available.
  • In a similar way, the difficulty of application development is greatly reduced via machine-generation of application software and UI components. Using specialised tools, the building of some UI applications directly by clinical professionals is now possible.

@thomas.beale I hope I’ve proven my willingness to do this task without burdening somebody else before I ask for help. May I please ask you to write the offered AOM BMM release 2.3.0 :flushed:

1 Like
2

Yes, that’s a perfectly fair request indeed, and I’ll try to get onto it this week. We are still sorting our AM 2.2 and 2.3 releases (they show up as having been published on the website, but we are still retrospectively adjusting them a bit). So I’ll probably create the 2.0.6, 2.2.0 and 2.3.0 versions.

Efforts like yours are very useful to help us get some of the sand out of the wheels - so keep reporting problems, we’ll try to catch up as fast as we can.

BTW, BMMs should be generated out from the UML, but no-one has had the time to create the Java extractor for that; we already have a Java extractor that creates the specification class definitions (those blue tables you see in the main specs). Just a human resources question…

1 Like
3

That would be great!

I have programmed in Java since v1.0 but haven’t used it since 2010 (I still like it though). Otherwise I would start coding UML to BMM converter right now.

I have some experience getting data out of XMI files to generate a backend + frontend of a large web application. One day I’ll try to pay back and write a UML to BMM converter (now that I know how important that is).

1 Like
4

Now that I learned that UML is the primary source of BMM, I must ask:

Is everything needed to generate BMMs in UML or do you need to manually edit BMMs?

5

The UML is currently the ‘master expression’ of the openEHR models. However, UML has various problems to do with representing relationships, generics and so on. So the extractor does tricks to fix those problems, which results in nearly correct specifications. It can’t fix all the problems - UML’s biggest problem is that it doesn’t know what a ‘type’ is, only a class. It also knows nothing at all about functional concepts (lambdas etc). BMM knows about all of these things and does them properly (that’s why it was created in the first place), so theoretically, BMM should be the master model. It probably will be in the medium term. We will need to preserve the UML for some time, since that’s the industry standard diagramming approach.

For a list of BMM problems see my blog post on the topic.

In my ideal universe, we would make BMM the master expression, change its syntax over to something base on EL and generate out diagrams in something better than UML.

6

OK. I can then stop trying to download/buy MagicDraw and reading about its meta model and XMI.

I have tried it from all starting points in the past:

  1. Creating an E/R with Visual Paradigm using tags to annotate what was missing in the E/R to generate Node.js backend and Vue.js frontend application (440 tables). This approached worked well.

  2. Used annotated SQL DDL to generate everything from #1 plus E/R diagrams (using PlantUML): https://assistcentrum.com/builder

  3. Parsed source code of the Microsoft Dynamics ERP into E/R diagrams: https://bcentral.dev

I root for the BMMs. They served me well during my first month with openEHR. Until today.

I hope it is not too much work to prepare the missing AOM2 BMM file :crossed_fingers:

7

I will generate the latest one from Archie. Archie has an implementation of the 2.3.0 AOM, so the BMM will also be 2.3.0. there should be very little changes between the two versions.

8

I feel fortunate to be part of such a kind community.

Thank you @pieterbos for helping me continue working without longer delays.

Thank you @thomas.beale for your commitment to keep the BMMs up to date in the long term.

p.s.
I just went through every branch of Archie to check if they all have 2.0.6 (they do). I hoped that your “json_schema_v2” would have 2.3.0.

1 Like
9

Might be a totally stupid question. But could we make OpenAPI the master expression of the openEHR specs?
I see two main advantages: less complexity and maintenance to do mapping uml+custom code → BMM → OpenAPI.
And newcomers don’t have to learn the openEHR specific BMM.

10

Having a Domain Specific Language (DSL) like BMM is good for precisely expressing whatever is required by the project (e.g. openEHR). Using OpenAPI might be too generic. Similar to UML.

Having a BMM grammar in ANTLR4 enables generating a parser in a lot of languages (Java, C#, Python2|3, JavaScript, Go, C++, Swift, Dart, PHP).

Archie is using Java and provides a ready-made BMM parser and converter to RM. I picked Dart as my language and it took me 8 days to write a similar BMM parser and converter to RM.

I hope developers are not afraid of BMM/ANTLR4. It is easy enough. No need to read about the grammar in the ANTLR docs (that is what @thomas.beale needed to write one).

I’m willing to help if somebody needs help starting to use BMM parser.

11

I even found some app that does OpenAPI → UML for visualisation of models. And it does UML->OpenAPI to visually edit UML models and export as OpenAPI.

It doesn’t seem to be well maintained though: GitHub - opendata-for-all/wapiml: An OpenAPI round-trip tool that leverages model-driven techniques to create, visualize, manage, and generate OpenAPI definitions.

12

Many things look good at the demo level.

I prefer writing the specifications in a DSL like BMM and then generate diagrams from it. And not only diagrams but as much of the applications as possible as well.

Edit: Don’t forget about the new features like the Expression language. I don’t see how UML/OpenAPI would be used for that.

13

I started doing one manually - main difference from generated is that the manual one doesn’t include the included classes, whereas the generated one (at least the copy I took yesterday) contains defs of a lot of includes. This I assume is because the generator tries to build a standalone BMM file, which could make sense in some situations. But for the ITS-BMM, we can just re-use BMMs from other BMMs in the normal way.

The other difference is that there is no official BMM (or UML) meta-model of the expressions yet, so this would be a bit made up.

Anyway, I should have a working BMM for AOM 2.0.6 in a couple of days. Might be useful as a reference to the generated one - including the generator I will eventually write based on the current UML extractor.

14

That’s one of the many reasons BMM, including its most recent Expressions part was written :wink:

1 Like
15

That is also underway, here.

1 Like
16

I’d have to have a look at its semantics, but every similar formalism (including Eclipse Xcore) I have looked at except OMG IDL, is unable to represent generic types properly, generics through inheritance, and usually doesn’t distinguish types from classes properly. Lambdas are often not first class citizens either. However, Xcore syntax is the kind of syntax we should be aiming for I think. Another reference is SysML2, which is under construction.

1 Like
17

I managed to get my serialization working.

Here is one of the classes that gets generated from the AOM:

Screenshot 2021-10-31 at 18.03.50
Screenshot 2021-10-31 at 18.03.501782×966 114 KB

I cannot test this code since OPT2 are 2.3.0 and my AOM is 2.0.6, but two great persons offered to help me :crossed_fingers:

1 Like
18

There is now an AOM 2.0.6 BMM schema, and some needed includes in the specifications-ITS-BMM repo.

It compiles in ADL Workbench, but that doesn’t guarantee it is correct - there may be remaining errors.

I also have to create AM 2.1.0, 2.2.0, and 2.3.0 BMMs as well, which are incremental changes from this AOM 2.0.6.

But this should get you started.

AOM2.0.6
AOM2.0.61015×689 34.6 KB

2 Likes
19

@NeoEHR In the expression language, it’s very possible that Archie has different implementation classes than the standard - the ones in the standard were changed a couple of times after we had implemented it already. It is possible to make a (configurable) custom json mapping to match the standard in Archie, but that is not done. All the other things of the model should match 100%.
You may want to use the Archie generated BMM if you want to parse the expression language model expressed in JSON.

@thomas.beale The single BMM file is just because I did not want to spend any effort in writing the code to create several BMM files for just the AOM - it did not add anything for me.

1 Like
20

Indeed - I was thinking about the design of the UML → BMM extractor, and creating separated files is quite a lot of work, so perfectly comprehensible. BTW I found various errors, which you are probably already fixing, anyway, they’re typical things that occur in these kinds of converters as you work out the details. Specifically:

  • all (?) properties seem to have is_mandatory set on them
  • cardinality only needed when it is something other than 0..*
  • the old form of list <xxx, ...> used for ‘ancestors’ not needed, can just be <xxx>
  • Boolean properties have ‘is_’ missing in the name (see below ex.)
  • the converter currently outputs a complex type structure for ?all P_BMM_SINGLE_PROPERTYs

correct form:

            ["is_enumerated_type_constraint"] = (P_BMM_SINGLE_PROPERTY) <
                name = <"is_enumerated_type_constraint">
                type = <"Boolean">
            >

Currently generated:

            ["enumerated_type_constraint"] = (P_BMM_SINGLE_PROPERTY) <
                name = <"enumerated_type_constraint">
                type_def = <
                    type = <"BOOLEAN">
                >
                is_mandatory = <True>
            >

There might have been a couple more, but if the above are fixed, the generator will be 97% there.