Possible Problem in BMM class-scheme

Specifications BMM/Expressions
1

Hi,

I think there is a problem in the class-scheme of BMM, latest version.

It is about BMM_MODULE, it is not yet defined in the class-descriptions, but it found its way in some UML-drawings in the documents. Especially the one in paragraph 4.1 and 7.1

In these drawings is BMM_MODULE just between BMM_CLASS and BMM-DECLARATION, and BMM_DECLARATION is derived from BMM_DEFINITIONS.

There is also another route from BMM_DEFINITIONS to BMM_CLASS, that is over BMM_ENTITY that, according the class-description also is derived from BMM_DEFINITIONS, but it isn’t in the drawing. Maybe it is a left-over, which needs to be removed.

Because:
If BMM_ENTITY is derived from BMM_DEFINITIONS, I think this is an error, because then there are two routes from BMM_CLASS to BMM_DEFINITIONS, in one route BMM_CLASS is also derived from BMM_DECLARATION, and in the other it isn’t.

It is a Diamond-confusion. A compiler needs to guess what is happening, and good compilers do not guess.

I am not sure, but it could be that the problem is solved when BMM_ENTITY is stopped being derived from BMM_DEFINITIONS. Another solution would be the removal of BMM_MODULE, but then BMM_CLASS would not anymore derive from BMM_DECLARAT|IONS and that would give problems in properties which assume this derivation.

I am interested in your comments

Best regards

Bert Verhees

2

Hi Bert,
yes, you have correctly understood the class structure, and yes there is a ‘diamond’, but it’s not a problematic one in principle since there will be no redefinition of the methods or constants in a ‘Definitions’ class in the inheriting children.

However, it is a nuisance for languages like Java and C# and others that can’t handle MI, and it would probably be better if we changed it to a pattern such that:

  • there is no inheritance of any XXX_DEFINITIONS class
  • access is via client/supplier, represented in syntax as e.g. {BMM_DEFINITIONS}.Generic_left_delimiter in the specs. Most modern languages have a way of doing static access by just mentioning the class name (same way you use enum literals in those languages).

This would be an easy enough change to make in the specs and doesn’t change anything semantically. I’d be interested to know the opinions of implementers on this.

3

There is a redefinition.

In the BmmDeclaration is the Scope-property which is of type BmmDeclaration.
There is also a scope-property in the BmmClass-derivations which are derived over the BmmEntity-route, they are of type BmmClass (or derivations). But these derivations are not allowed following the side of the diamond route where they occur. The compiler makes an ambiguous decision at this moment. It recognizes scope as being derived from BmmDeclaration (following one route) but does not recognize the derivation-connection (following the other route)

In the classical diamond problem there is an ambiguity of to sides of the diamond have a equal named property/function.
This is a special diamond problem because in this situation one route is deriving the type of the scope-property which in the other route is not possible.

I have heard there is a solution for this problem in Java 8 and higher, but I need to investigate that. But a change in the model would be welcomed very much. Makes life easier for many persons.

4

image
image616×634 35.7 KB

I hope the image comes through, it is the hierarchy as IntelliJ sees it. I created interfaces from the abstract classes to make multiple inheritance possible. In case the image is not clear, BmmDeclaration and BmmEntity are the parallel diamond routes with each other derivation-routes, the problem occurs in the BmmType derivations, which are in the BmmEntity branch and have the scope - property

5

I think you may have misread the model on that point. BmmEntity doesn’t inherit from BmmDeclaration. The inheritance tree (evaluated in MagicDraw 19) is as follows:
BMM_DECLARATION-inh

I’m aware of the issue of MI in the features package, for which I aim to provide some technical guidance for Java etc.

Ideally, I’d like us to have one open source implementation of BMM, which would most obviously be an extension to the Archie project, which already has BMM up to ‘BMM 2’ level…

6

Sorry, I have read and implemented it well, but apparently explained it wrongly. My email with image explains it better. Please show your schema generated by Magic Draw from BmmDefinitions, I am interested in the difference it sees.

By the way, does Magic Draw also reads Eiffel? Or did you use something else as notation?

7

I agree, there is diamond inheritance from BMM_DEFINITIONS, but there are no redefinitions of anything in BMM_DEFINITIONS in any other class. Regardless, I agree it is a nuisance and it is easy to get rid of. I’d like some feedback from other implementers before doing that, but since you are already coding, I’d recommend you do as I suggested above (i.e. remove the inheritance and just use static member access).

The MagicDraw model is currently the primary expression of the specification model, and the BMM models are independently created and maintained. I am slowly working to fix that such that BMM is generated from the UML extractor (the ideal would be BMM3 -> UML/XMI2 but that would be painful to implement, and would not preserve diagram visual relationships or settings).

8

Thanks for your suggestion to make it usable for my situation. It is not a big serious project I am coding, it is in fact a kind of hobby-project for fun and to train my mind in moments of spare-time.

If I were an artist, I would say, it is just sketching.

Best regards
Bert

9

All is good. But even if playing, I’d still say, start with Archie. It’s an excellent project. I intend to get onto coding latest BMM changes in it when I get past some current workload.

10

I’ve now implemented a clean-up on the current BMM spec; I’ve removed the inheritance from BMM_DEFINITIONS, added some missing features it should have. So this should help a bit.

I think it’s a good approach for the whole of openEHR, but we’ll need input from SEC for the RM etc.

11

Thanks Thomas, quick action.

BTW, I looked at the archie project, but the BMM-part of the project seems a bit abandoned, but maybe, as you said, that is going to change. Let’s hope so.

But besides that, good news you changed it, I am glad to follow well thought specs instead of on the quick deriving something from it.

Software must mature, like good Cabernet Sauvignon, and these specs have the nature of having matured after being in the public domain and being thought of for so long. Software writing is a slow thing.

12

Specs have to mature as well, and all eagle-eyed review that finds errors or issues is helping constantly to evolve them, so thanks for the feedback!

13

No problem, you are welcome.

I have a few remarks, which is one reason why I do not use the archie-Bmm. It is a good thing to keep the Bmm clean.

There are convenience methods defined in the classes, like the property: immediate_descendants.
I would not bring them as property, but as method and in a class outside the Bmm. How a developer implements this is his profession. He can chose to have these method in the Bmm-class or in a special technical layer, or API-driven.

And there are functions which mention directories as if they refer to a file-system, I would not implement them either in the Bmm-classes. The code assumes too much.

And the third remark is about the P-classes, persistence can be solved in many ways, it is not up to the Bmm to have this defined. I, for example, could do it with Java-annotations without needing a special class.

As is the case now, there is a Bmm -pojo model, which is not very pure. (convenience methods, and load-methods are in it), And around it are the P-classes, to persist.

I would do it the other way around, having a purified Bmm-pojo-model, and, eventually, if needed, a Convenience schema around it, with persistence-methods, loading schema’s from files or databases or API, having convenient maps and lists to read and handle the information quickly.

So, this would be two separate modules, there could be a third module, which is able to validate archetypes against a in Bmm created Reference Model.

This is, regarding the Bmm, the architecture I wish for and the reason why I am building my own, but as said before, it is a hobby project, I am not in a hurry, and it never needs to be ready. There is no deadline, even no goal to get it ready ever.

14

I don’t completely disagree. You could re-compute immediate descendants every time. But since it’s unchanging during a model load session, and it’s also a typically useful query, e.g. for displaying things about a model, it’s in the model. As you can see it is derived in the UML (see the ‘/’ in the diagram. This means it is an attribute created on load, not a persistent data item.

So it’s an attempt to be a useful guide to implementers. The alternative would be to have it as a function as you say, and leave the implementer to cache the value or not. In a way, the ‘derived’ UML setting implies this.

I assume you mean the Schema classes in section 3. The idea is that this provides one model of how to get a BMM schema from a file into memory. As it states at the top, it is informative, and you can certainly do something else.

Right - again, this provides one way that is tested and known to work for persisting BMM models. In the future, the intention is to move to a syntax approach more like OMG IDL or Ecore / Xcore syntax. But again, this will just be a default representation - you should always feel free to persist as (say) a JSON dump (aka BMM POJO) or whatever. Probably we could put such a thing into a future version of the spec as well.

All implementation experience is useful, and your feedback will certainly help improve the spec over time. Feel free to suggest changes; they might not come instantly, but I’ll be very happy to see how they can be added over time.

15

I will publish my code, in a few weeks, depending on how workload goes. I make a notification here.