v16.1 - Extending BPMN2.0::Activity metatype

[Paolo F Cantoni]

Has anybody successfully extended a BPMN2.0::Activity Metatype in an MDG profile to (for example, allow the display of Notes property in Rectangular mode)?  We've been able to extend various other built-in or hard-coded metatypes to do similar, usually by using patterns that attach our additional stereotype with shape script to the pre-existing Sparx metatype (for example EAUML::table, becomes  <ourProfile>::DBTbl;EAUML::table).  When this is added to the toolbox and dragged onto the diagram, it acts as a normal table (thus responding to the creation of FKs etc.) but uses the shapescript from our profile.

Nothing we seem to try with BPMN2.0::Activity seems to work! We've tried using patterns and without patterns.  Even creating the simplest stereotype:

Code: [Select]

         <Stereotype name="ActvtyB" metatype="ActivityB" notes="This is the definition of an activity (used for BPMN extension)" cx="0" cy="0" bgcolor="10092543"
         fontcolor="8421376" bordercolor="9470064" borderwidth="1" hideicon="0">
            <AppliesTo>
               <Apply type="BPMN2.0::Activity">
                  <Property name="isReadOnly" value="false"/>
                  <Property name="isSingleExecution" value=""/>
                  <Property name="parameterName" value=""/>
                  <Property name="postcondition" value=""/>
                  <Property name="precondition" value=""/>
               </Apply>
            </AppliesTo>
         </Stereotype>
with the toolbox definition:
<Tag name="<ourProfile>::ActvtyB(BPMN2.0::Activity)" type="" description="" unit="" values="" default="Activity(B)"/>
generates the error:
"Missing base type: 'ActvtyB' does not extend 'BPMN2.0::Activity'

Command: <ourProfile::ActvtyB(BPMN2.0::Activity)
When, from the definition, it clearly does...
Any pointers are gratefully accepted.

Paolo
[Edit: we note user ea0921 had similar lack of success in 2023]

[Geert Bellekens]

Paolo,

Have you tried

<Tag name="<ourProfile>::ActvtyB(UML::Activity)" type="" description="" unit="" values="" default="Activity(B)"/>

I think I always add the UML basetype in toolbox definitions when extending existing stereotypes.

Geert

[Eve]

Create Stereotypes Extending non-UML Objects

In short. It's related with a Generalization, not an extension.

[Paolo F Cantoni]

Create Stereotypes Extending non-UML Objects

In short. It's related with a Generalization, not an extension.

Thanks, Eve,
We thought we'd tried this, and it didn't work.  But carefully going over it again, we found a "hidden" extension relationship (i.e. in the model, but not on the diagram).  Oh well... 

Having removed that, we now get an ActvtyB with all the properties of a BPMN2.0::Activity, but apparently NONE of the relationships!  Is this to be expected?  We expected that (like user ea0921) we'd be able to connect our ActvtyB to another ActvtyB or another BPMN2.0::Activity and the QuickLinker would provide Sequence Flow to/from & Message Flow to/from.  But we get none of that.  What are we missing, please?  ^[2]

So, we thought we'd add stereotyped relationships to "manually" add the ability for the QuickLinker.  So we added them for BPMN::MessageFlow and BPMN::SequenceFlow from ActivityB to ActvityB (self-reference) and to BPMN2.0::Activity.  When we rebuilt the MDG, we found we could indeed get MessageFlow and SequenceFlow (not to/from since we can't specify that in a stereotyped relationship, can we?).  But, in a very curious twist, BPMN2.0::Activity would no longer QuickLink to BPMN2.0::Activity!  ^[1]

What's going on?  Do we need to look for some more inadvertent errors in our definition?

Again, any help is appreciated.
Paolo

^[2] [Edit2: by manually editing the emitted MDG, we have now got ALL the relationships working.  We are now trying to understand the forces not allowing the emitted MDG to function.]

^[1] [Edit1: (NOTE: Edit2 has overturned this statement - removing the Stereotyped Relationships segment fixed it) manually removing ";BPMN2.0::Activity" from the generated code below will restore the BPMN2.0::Activity QuickLinker functionality

Code: [Select]

            <stereotypedrelationships>
               <stereotypedrelationship stereotype="BPMN2.0::MessageFlow" constraint="<ourProfile>::ActvtyB;BPMN2.0::Activity"/>
               <stereotypedrelationship stereotype="BPMN2.0::SequenceFlow" constraint="<ourProfile>::ActvtyB;BPMN2.0::Activity"/>
            </stereotypedrelationships>
, go figure...  (by which I mean, the explanation will be very useful to understand)]

[Eve]

The BPMN 2 technology hasn't been upgraded to use stereotyped relationships etc for its relationships. The quicklinker is still defined using the table, and your stereotype doesn't match its filters.

When you defined a rule, that resulted in overriding the table relationships for that connector type. A behavior that's in place so that a profile author can progressively implement rules.

[Paolo F Cantoni]

The BPMN 2 technology hasn't been upgraded to use stereotyped relationships etc for its relationships. The quicklinker is still defined using the table, and your stereotype doesn't match its filters.

When you defined a rule, that resulted in overriding the table relationships for that connector type. A behavior that's in place so that a profile author can progressively implement rules.

Thanks, Eve,
we guessed as such and have now removed the stereotyped relationships.  However, the next post will reveal a different issue that is reproducible and severely impacts our work.

Paolo

[Paolo F Cantoni]

Hi Eve,
I think we've now tracked down the cause of the problem!  Firstly, some background...
We wanted to "extend" (by Generalization, we now realise) BPMN2.0::Actvity to use our shapescript (and additional properties to drive it) (for this example, the metatype "ActvtyB").  We have a standardised way of setting up our profile metatypes so that they behave (i.e. their shapescripts behave) in a manner that is as consistent^[1] as possible.  We do this by taking advantage of the Generalization mechanism, which allows decorations to be inherited.  Consequently, those metatypes of our own have the Extension to the appropriate metaclass and then a series of Generalizations to various intermediate metatypes that define decorations required to be surfaced by the metatype.

We have now found that this doesn't work out for our metatype ActvtyB.
If the emitted ActvtyB is defined as:

Code: [Select]

<Stereotype name="ActvtyB" metatype="ActivityB" notes="This is the definition of an activity (used for BPMN extension)" cx="0" cy="0" bgcolor="10092543"
fontcolor="8421376" bordercolor="9470064" borderwidth="1" hideicon="0" generalizes="BPMN2.0::Activity" baseStereotypes="BPMN2.0::Activity">Then, "Alles ist in Ordnung" - It works (Well, NOT to the extent we need, but we get an element with BPMN2.0::Activity properties and working BPMN2.0::Activity QuickLinker - including to/from)
However, if we now try to add one of our decorator metatypes (in this case, "StndrdItm¯D" - for Standard Item Decorator) so that the emitted definition is:

Code: [Select]

<Stereotype name="ActvtyB" metatype="ActivityB" notes="This is the definition of an activity (used for BPMN extension)" cx="0" cy="0" bgcolor="10092543"
fontcolor="8421376" bordercolor="9470064" borderwidth="1" hideicon="0" generalizes="BPMN2.0::Activity" baseStereotypes="BPMN2.0::Activity StndrdItm¯D">Everything "goes to Sh*T"!  (Well, not completely, we still get the element, but the QuickLinker breaks and NO BPMN2.0 related menu items appear for BOTH metatypes BPMN2.0::Activity and <ourProfile>::ActvtyB!  Remove the "StndrdItm¯D" Generalization and the QuickLinker returns.

This smells like a defect to us, but explaining why it SHOULD work this way would be enlightening and help drive our future planning.

Thoughts?
Paolo

^[1]  Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}

[Eve]

Just to check my understanding:
When you create a new stereotype specializing BPMN2.0::Activity and another stereotype, it appears that EA no longer recognises that as a BPMN2.0::Activity.

If that's a correct interpretation. My initial reaction is that it sounds like something is going wrong. I can't take the time to try to debug it right now, the first step would be determining if it's something particular to StndrdItm¯D, or if you get the same problem with an empty stereotype.

[Paolo F Cantoni]

Just to check my understanding:
When you create a new stereotype specializing BPMN2.0::Activity and another stereotype, it appears that EA no longer recognises that as a BPMN2.0::Activity.

If that's a correct interpretation. My initial reaction is that it sounds like something is going wrong. I can't take the time to try to debug it right now, the first step would be determining if it's something particular to StndrdItm¯D or if you get the same problem with an empty stereotype.

Thanks for taking a look.  Yes, your understanding is correct. I don't think it's just StndrdItm¯D, as we tried some available others.  What do you mean by "empty stereotype"?  It would be easy for me to check now that I know how to generate the issue.

Paolo

[Eve]

What do you mean by "empty stereotype"?

Create a new stereotype, don't change anything except perhaps the name/abstract.

[Paolo F Cantoni]

What do you mean by "empty stereotype"?

Create a new stereotype, don't change anything except perhaps the name/abstract.

OK, Eve,
I believe I have found the root defect (and it's a previously acknowledged (by Sparx) one).

Added an empty Stereotype ("Empty") for ActvtyB to inherit from.   No Problem!
OK, So I added one of the StndrdItm¯D decorations. Again, No Problem!  (although the decorations were NOT inherited???)  {Resolved in next post!}
I then added ALL of the StndrdItm¯D decorations (so Empty is now a shapescript clone of StndrdItm¯D). Again, No Problem!  (although the decorations were NOT inherited???  WHY?)  {Resolved in next post!}
Next, I re-inherited from StndrdItm¯D (instead of Empty) - decorations NOW inherited BUT Problem with BPMN relationships!!! - who writes this code?

So what's going on?  Investigation reveals that StndrdItm¯D itself inherits from CmmnItm¯D  (Common Item Decorator).  So ! remove that inheritance!
Re-inheriting from StndrdItm¯D (but no further inheritances) - decorations NOW inherited AND No Problem with BPMN relationships!
Replacing the inheritance on StndrdItm¯D (from CmmnItm¯D) restores the issue!  Culprit found!

Sparx has already admitted that decoration inheritance will not work for more than one level!^[1]  Knowing this, although we placed the inheritance in the model so that it would correctly show the conceptualisation,  we manually placed the inherited decorations in StndrdItm¯D  to get around the bug! This CmmnItm¯D inheritance obviously did NOT affect our normal metatypes, which are mainly inherited from StndrdItm¯D!

So, it looks as though this defective inheritance is also causing this problem!  Why do the decorations work when we inherit from StndrdItm¯D but not from Empty?  I'll leave that as an exercise for the reader.  {Resolved in next post!}

Paolo
PS: Thanks again for your help, Eve.  I couldn't have isolated the issue without the pointers you provided!

^[1]  Someone didn't think things though I'd submit.

[Paolo F Cantoni]

In the previous post, I asked: WHY were the decorations NOT inherited???

The decorations don't apply because an empty stereotype on its own is NOT enough...  You need to extend the metaclass to which you want it to apply!
So when we added:

Code: [Select]


      <AppliesTo>
         <Apply type="Activity"/>
         <Apply type="Class"/>
         <Apply type="Component"/>
         <Apply type="Interface"/>
         <Apply type="Package"/>
         <Apply type="State"/>
      </AppliesTo>
So that it would apply to the same metaclasses as StndrdItm¯D, BINGO!

I've amended the previous post accordingly!

Paolo

[Eve]

Not entirely sure about your conclusions.

It could be the second level of inheritance interfering with the BPMN quicklinker, but it could just be something particular about CmmnItm¯D itself. In either case, the information you've shared doesn't support that it's related to decorations.

Yes, decorations need an extension before EA will use them.

[Paolo F Cantoni]

Not entirely sure about your conclusions.

It could be the second level of inheritance interfering with the BPMN quicklinker, but it could just be something particular about CmmnItm¯D itself. In either case, the information you've shared doesn't support that it's related to decorations.

Yes, decorations need an extension before EA will use them.

Hi Eve,
I don't believe I implied it was the decorations themselves, merely that the inheritance process is defective.  In any case, I now believe I have found the root cause, and while you have already acknowledged it, it still caught us a bit by surprise!
Again, though, some more background.  As previously mentioned, we've tried to standardise the properties and behaviours of our shapes and lines by extensively using the new model-driven generating process and taking advantage of the (still somewhat flawed) inheritance mechanisms.  We've tried to build an inheritance hierarchy that allows us to keep things the same where required and different where required.  It's currently about 5 levels deep.

The root cause turned out to be "literally" the root, an abstract stereotype "Root¯R", wherein all common stereotyped relationships between an item that inherits from Root¯R can make with related abstract (or concrete metatypes).  Removing the <stereotyperelationships> segment exposed the culprit!  In a previous post, you acknowledged that "The BPMN 2 technology hasn't been upgraded to use stereotyped relationships etc. for its relationships. The quicklinker is still defined using the table, and your stereotype doesn't match its filters.".
We had encountered issues, as we noted when we tried to add local <stereotyperelationships> to our ActvtyB, but since they involved BPMN2.0::Activity, that seemed reasonable.  What surprised us was that ANY <stereotyperelationships> defined in Root¯R would break the QuickLinker!

Is this a behaviour that should be expected, or is this a defect (notwithstanding that the BPMN 2 technology hasn't been updated to use stereotyped relationships)?  We think it is a defect.  Your thoughts?

Paolo

[Eve]

I don't believe I implied it was the decorations themselves, merely that the inheritance process is defective.

I've confirmed that the issue preventing decorations (which is the one I believe you were referencing as being previously acknowledged) from being inherited from two levels of ancestry only impacts decorations. If there are other issues with inheritance then they are unrelated.

What surprised us was that ANY <stereotyperelationships> defined in Root¯R would break the QuickLinker!

Is this a behaviour that should be expected, or is this a defect (notwithstanding that the BPMN 2 technology hasn't been updated to use stereotyped relationships)?  We think it is a defect.  Your thoughts?

It's been a little while since I was actively working with the metamodel specified relationships. My gut reaction is that the behavior you're describing is at least a little surprising. I also know that the way the two methods interact is complex and where they are in conflict the metamodel should take priority. From the information available to me right now I wouldn't say it's a defect despite surprising me.