FHIR Chat · UML Diagrams · methodology

Stream: methodology

Topic: UML Diagrams

Grahame Grieve (Dec 19 2019 at 04:17):

I've been working the UML sub-system over a fair bit. Concerning the UML diagrams we say:

The actual order of the elements in XML cannot be determined from the diagram

But I have no memory of why we say this, and I think it's only true for interfaces/patterns, not true of the UML diagrams themselves

Thoughts?

Grahame Grieve (Dec 19 2019 at 04:18):

When I've finished, the definitions will be more natural in UML... I don't know if we should revisit the discussion of whether there's a UML format worth generating?

Grahame Grieve (Dec 19 2019 at 04:18):

we considered XMI (unreliable) and eCore before. Who would use BMM (other than Tom)? Anything else we should talk about?

Grahame Grieve (Dec 19 2019 at 04:37):

ah - order - can't tell where the associations fit in

Lloyd McKenzie (Dec 19 2019 at 04:43):

right. attributes are fine, associations, not so much.

Thomas Beale (Dec 20 2019 at 17:24):

we considered XMI (unreliable) and eCore before. Who would use BMM (other than Tom)? Anything else we should talk about?

Not that I am really suggesting it, but BMM is used by CIMI (or at least was, unless replaced by something else recently), and also all the archetyping tools in openEHR (4 at last count, from 4 different orgs). It's probably going to be the de facto model representation standard for the openEHR and extended community, with a generator from the UML tool (MagicDraw), and downstream generators for JSON-schema, Java, and other languages. Someone is even using it to generate Kotlin. See specifications.openehr.org/releases/LANG/latest/bmm.html for the v3 spec. All the tools currently do BMMv2.

The reason you might consider it is the same reason we have it: XMI is a) terrible and b) doesn't do normal generics properly. Ecore (their lang is called Xcore - see https://wiki.eclipse.org/Xcore) is not too bad, but as far as I can tell not specified by anything more formal than that Eclipse wikipedia page. It also doesn't do generics properly last time I looked, and also has a bunch of C++-like junk such as 'protected', 'static' etc which you don't want in proper models.

I could not find any other good languages to use over the last 10 years. When we upgrade to BMMv3, we will make the syntax look more like Xcore and/or OMG IDL (they are fairly similar).

For now, everything is in BMM2, which doesn't do functional or procedural elements, but does all the data representation you want. FHIR in BMM2 is here (it's not 100% and only about 80% complete of DSTU4, but you will get the idea - and it computes in ADL Workbench) - https://github.com/openEHR/reference-models/tree/master/models/FHIR/DSTU/BMM

Thomas Beale (Dec 20 2019 at 17:28):

This version of BMM even includes a FHIR-ism that we added (also needed in openEHR) - vocabulary constraints - not yet the required|recommended|example thing in FHIR, but we will probably go that way as well. Example:

    ["relationship"] = (P_BMM_CONTAINER_PROPERTY) <
        name = <"relationship">
        type_def = <
            container_type = <"List">
            type_def = (P_BMM_SIMPLE_TYPE) <
                type = <"CodeableConcept">
                value_constraint = <"fhir::PatientRelationshipType">  -- ***** VOCAB constraint
            >
        >
        cardinality = <|>=0|>
    >

If you don't like ODIN syntax, you can get BMM in JSON - see e.g. the whole openEHR RM in BMM+JSON: https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/RM/Release-1.0.4/json/openehr_rm_ehr_1.0.4.bmm.json

Thomas Beale (Dec 20 2019 at 17:30):

At the end of the day, even though the generated UML is useful in FHIR, the faked up way you have been doing it is probably actually better than any official proper UML2-compliant version, for the basic reason that UML doesn't represent all the things you want to represent - generics; choice (of course), terminology constraints, and more. It has no meta-model for the latter.

Thomas Beale (Dec 20 2019 at 17:34):

The long term picture is that you will need a rock-solid model representation formalism, and UML 2.x is not it. Within OMG, it will be replaced by one or both of two new efforts - SysML2 (looks good, but a couple of years away), or a revamped UML (also a couple of years AFAIK). Xcore doesn't have proper generics or vocab constraints. OMG IDL3 is probably over-engineered in some aspects, and under on others. BMM3 is designed more like a strongly typed OO+FP meta-model, and knows about terminology, proper generics, inheritance with generics and various other tricks. Also, there is a modern and well-maintained Java lib for it - https://github.com/openEHR/archie

Thomas Beale (Dec 20 2019 at 17:37):

Note that choice[] is supported in none of these formalisms, for reasons discussed at length previously, and where you have choice[] or Reference() in FHIR today, you would see ?Type or something like 'Reference', with no constraints. All constraints are in the archetype layer. BTW I translated FHIR DSTU4 to BMM2 so as to show how to do constraining / profiling using a layer of archetypes over a properly-type model of FHIR. At some point I'll publish some examples.

Thomas Beale (Dec 20 2019 at 17:39):

All of those diags of FHIR I produced from our tools on my blog (Admin classes etc - https://wolandscat.net/category/fhir-2/) are from a modified version of the BMM2 representation of FHIR.

Grahame Grieve (Dec 20 2019 at 20:30):

where is BMM2 documented?

Thomas Beale (Dec 21 2019 at 13:26):

You can see that here: http://raw.githack.com/openEHR/specifications-BASE/c352f1bbff5c417d5bf8834a1c5c8b3565219d67/docs/bmm/bmm.html

Thomas Beale (Dec 21 2019 at 13:28):

'BMM2' mainly refers to the persistent (serial) form - documented here - https://specifications.openehr.org/releases/LANG/latest/bmm_persistence.html

Thomas Beale (Dec 21 2019 at 13:29):

The in memory form is the main 'BMM' spec. The modern form of that is https://specifications.openehr.org/releases/LANG/latest/bmm.html - if you ignore the functional and values sections, the rest is what the ADL workbench implements. The Archie library is a bit behind but catching up.

Thomas Beale (Dec 21 2019 at 13:30):

For the in-memory form, there is no real 'BMM2' or 'BMM3', its just an evolving model. But we have to keep the BMM2 and BMM3 (when it comes) persistent forms separate. Yes, I know, a bit confusing. It took off in the community without me realising, and we need to clean up some of the git versioning details.

Grahame Grieve (Dec 21 2019 at 19:23):

so I had a quick look at the abstract syntax. It's missing some pretty key features from my pov:

• invariants (it uses them itself, but doesn't allow them to be defined)
• interfaces
• stereotypes / any form of meta properties

given that, I don't really see any point in trying to generate BMM. And it's not surprising you have trouble if you try to see FHIR through the lens of BMM

Grahame Grieve (Dec 21 2019 at 20:01):

@Robert Lario do you have any comments about a usable UML format that is supported between tools?

Thomas Beale (Dec 23 2019 at 11:19):

Invariants & pre- and post-conditions (which we had in openEHR specs since 2003) are just going in now. Interfaces don't have a specific keyword or meta-type; currently they are just any type that consists only of methods and not data. Maybe we'll add something to make it a bit clearer. Stereotypes - we do have some, but they are a bit specific. I'm just adding the general capability now as it happens. What are your requirements - classifiers on classes and features? Something more?

Thomas Beale (Dec 23 2019 at 11:21):

The main thing BTW that has to be gotten right for invariants is the expression language, including functional elements (lambas), proper meaning of dot-notation and operator/function mapping. UML/OCL don't do this unfortunately (UML doesn't even recognise delayed function call, and ultimately doesn't distinguish type from class, which is the real killer).

Thomas Beale (Dec 23 2019 at 11:22):

If you find a supported formalism out there somewhere that does all this properly, I'll be very interested to hear about it.

Grahame Grieve (Dec 23 2019 at 19:40):

currently interfaces are just any type that consists only of methods and not data

this is a problem for me, since UML doesn't differentiate between attributes that represent data and attributes that represent interface. e.g. this class has a 'x' of type x that you can read or write vs this class actually stores an 'x' internally.

Methods that provide read access are actually something different. Classes with only methods may be concrete leaf descendants that flesh out a method, or they may interface-ish classes. So please make this explicit not implicit. I don't particularly care how.

What are your requirements - classifiers on classes and features?

well, not exactly sure what you mean by 'classifier'; I don't mind whether it's a series of stereotype values or a series of name = value pairs , though I prefer the latter - much more flexible and reliable. And yes, on both classes and features.

if you're adding stuff... allow an extension to drop a series of SVGs in...

The main thing BTW that has to be gotten right for invariants is the expression language

Well, we use FHIRPath (http://hl7.org/fhir/fhirpath), which I would recommend, actually. It certainly works just fine against openEHR classes, since it works fine against any UML class model. And I think it meets your criteria...

Thomas Beale (Dec 23 2019 at 22:31):

Interfaces: do you mean a type IX is a transactional interface to an x or type X (a proxy of some sort), versus a type X, which is a direct instance of an x:X?

Ah - you mean interfaces = pure interface def, i.e. without code. Got it. WHere's an example in FHIR?

On the meta-data, the default right now is a Hash list of keyed values; same for documentation. For SVGs: are you meaning to allow model diags or similar?

Grahame Grieve (Dec 24 2019 at 00:41):

you mean interfaces = pure interface def, i.e. without code.

... umm yes. well, kind of. Without storage. That's not quite the same as without code but I'm not defining code on the interfaces in FHIR

Got it. Where's an example in FHIR?

http://build.fhir.org/canonicalresource.html

Maybe one day it'll migrate to being a real resource, but not right now.

On the meta-data, the default right now is a Hash list of keyed values; same for documentation.

that works

For SVGs: are you meaning to allow model diags or similar?

sure. and you can tie the SVG elements to the underlying logical classes by id

Last updated: Apr 12 2022 at 19:14 UTC