As many of you know, we have developed our own modelling methodology which is defined in a model-based profile from which we generate an MDG. We have standardised much of the rendering and name processing so that we can (on a per diagram basis) specify which shape and which name the item is to render. Our users really like it!
The new model-based generation technology (
real MDG at last!
), make this pretty simple and convenient! It's a REALLY POWERFUL TOOL for methodology specification and management!
We've started to incorporate some of the more generative technologies within EA into our methodology. Our first attempt was to include the DB reverse engineering items into our technology and add the standardised rendering we use with other items. Within certain limits, we have found this is possible and most of the DB related stuff still works! (see:
v15.2 - DB Builder to allow EAUML::<component> as non-primary stereotype).
Buoyed up by that experience, we then tried to incorporate BPMN. Unfortunately, we found that unlike the DB related processes, adding an additional stereotype to the BPMN2.0::BusinessProcess item will stop the BPMN processing dead! (It generates a
SIMULATION ERROR: No elements to simulate error)
At first, we thought that we were in a similar situation to what we found in the link above. But as the advert says:
"But wait, there's more!!!"It would appear that the BPMN process is NOT hard-coded to BPMN2.0::<BMPNComponentName> stereotypes (thus requiring that the extended stereotype (t_xref.Description) FQName have the value BPMN2.0::<BMPNComponentName>) but merely requires that the t_object stereotype = <BMPNComponentName> (e.g. "BusinessProcess"),
but wait, there's more! Not only must the main stereotype be <BMPNComponentName>,
but there must be NO other additional stereotype defined! In fact the t_xref.Description field can be NULL! Not only that, if you do define value in t_xref.Description, the only value allowed is @STEREO;Name=
BusinessProcess;FQName=MyMDG::BsnssPrcss;@ENDSTEREO;
As can be seen in the example, the FQNAME can be anything you like! If I hadn't seen it with my own eyes, I'd never have believed it! (Well, like qwerty, yes I would
)
I would think from a risk point of view, now that this has been demonstrated, the
risk of name clashes with other profiles is now high. As an architect, I would expect that the BPMN processor would require that the FQName
must be BPMN2.0::<BMPNComponentName>; but to provide the maximum flexibility, now that we have
constrained the item to have the BPMN2.0 stereotype, it NEED NOT be the primary!
To be clear, we have NO "beef" with the BPMN processing looking for hard-coded BPMN2.0::<component> stereotypes (should it be rectified from what it doesn't do now). We'd just like the processing to merely check for the existence of the BPMN2.0::<component> in the extended stereotype list, not require only that the t_object.Stereotype= <BMPNComponentName>
AND not allow any other stereotype! We feel that this is a self-inconsistent requirement! Especially since EA allows multiple stereotypes from multiple profiles! The positioning of stereotypes from a generated MDG can be problematic (as has been described in other posts). Please rectify!
We believe that making this architectural change to the way EA uses extended stereotypes will allow EA to get a significant lead on its competitors by providing SIGNIFICANT flexibility without sacrificing rigour!
Thoughts?
Reported,
Paolo
