Pretty much everybody here is a better Java developer than I’ll ever be, but I am currently working (in my favourite language) on Archie (under the stern supervision of @pieterbos 
and am currently thinking on these kinds of problems myself. So you may feel free to correct any egregious errors I may make below or generally on the topic …
My view on the UML is that it is better to keep it simple and indicate as purely as possible the design intention, including things like multiple inheritance and covariant redefinition. I would not like to rewrite the models for Java, when C#, although similar, is different (e.g. it has things like virtual properties etc, from memory), but more to the point, I have the feeling that we’ll all be using Kotlin instead of Java inside 5y, and Kotlin’s type rules are definitely not the same as Java’s.
However, the specs are light on implementation patterns in well-known languages. We used to have a ‘Java ITS’ kind of document, and we probably should remedy this situation.
For now, the pattern that I believe is the correct one to model such as BMM_DECISION_GROUP.branches as you see here in the BMM is ot use Java generics, e.g. you would define
class BmmDecisionGroup<T extends BmmDecisionBranch> extends BmmStatement {}
class BmmConditionChain extends BmmDecisionGroup<BmmConditionBranch> {}
class BmmCaseGroup extends BmmDecisionGroup<BmmCaseBranch> {}
Then various properties and routines defined in the first class become generic, like:
private List<T> branches;
public addBranches(List<T> branches);
and similar. I think this will achieve the effect of covariant redefinition that we need in this part of the model. It is what we are using / will use elsewhere.
Not sure if I have addressed the problem completely but it seems to me this gets part of the way.