v15.2β - Redefining EAUML::FK

[Paolo F Cantoni]

In our MDG, we have a redefinition of EAUML::FK thus:

Code: [Select]

<Stereotype name="DmnsnRfrnc" metatype="Dimension Reference" notes="" cx="200" cy="100" bgcolor="15658671" fontcolor="10061943" bordercolor="10061943" borderwidth="-1" hideicon="0" generalizes="EAUML::FK" baseStereotypes=""EAUML::FKArc" redefines="EAUML::FK">(Arc is our own stereotype)
We create an Association using the Database Modelling profile between two EAUML::table items.  We can then convert the Association to a DmnsnRfrnc stereotype and can even create the Foreign Keys, but we are left with an arc with stereotypes: "FK, DmnsnRfrnc" rather than just DmnsnRfrnc.  Is this because there's a LOT of hard coding in the DB modelling profile?

Paolo

[qwerty]

I just think that all that table stuff is hard coded in EA's stomach. I once had issues with that but found  way without using it. Good luck.

q.

[Eve]

Likely EA considers FK to be a keyword.

[Paolo F Cantoni]

Likely EA considers FK to be a keyword.

Hi Eve,

I don't mean in rendering, I mean in the Stereotype property in the Properties window (and, I presume, t_xref).

Paolo

[Paolo F Cantoni]

Likely EA considers FK to be a keyword.

Hi Eve,

I don't mean in rendering, I mean in the Stereotype property in the Properties window (and, I presume, t_xref).

Paolo

[BUMP]

Why are we seeing this?
We need to understand what's going on as it affects our strategy for modelling going forward.

Paolo

[Eve]

This is a hand coded profile isn't it. Tsk Tsk. I think you're causing your own problems.

Code: [Select]

<Stereotype name="DmnsnRfrnc" metatype="Dimension Reference" notes="" cx="200" cy="100" bgcolor="15658671" fontcolor="10061943" bordercolor="10061943" borderwidth="-1" hideicon="0" generalizes="EAUML::FK" baseStereotypes=""EAUML::FKArc" redefines="EAUML::FK">

The inheritance here is wrong.

generalizes always has one stereotype, which you have, but baseStereotypes needs to have both. I also see that you have incorrectly specified that FKArc comes from EAUML.

Code: [Select]

<Stereotype name="FK" notes="" generalizes="Arc" baseStereotypes="Arc EAUML::FK" redefines="EAUML::FK"/>
It wouldn't surprise me if you're confusing EA by not including the generalizes stereotype in the baseStereotypes and the result is that it ends up applying EAUML::FK explicitly in addition to your stereotype. That's not a guarantee though.

[Paolo F Cantoni]

This is a hand coded profile isn't it. Tsk Tsk. I think you're causing your own problems.

Code: [Select]

<Stereotype name="DmnsnRfrnc" metatype="Dimension Reference" notes="" cx="200" cy="100" bgcolor="15658671" fontcolor="10061943" bordercolor="10061943" borderwidth="-1" hideicon="0" generalizes="EAUML::FK" baseStereotypes=""EAUML::FKArc" redefines="EAUML::FK">

The inheritance here is wrong.

generalizes always has one stereotype, which you have, but baseStereotypes needs to have both. I also see that you have incorrectly specified that FKArc comes from EAUML.

Code: [Select]

<Stereotype name="FK" notes="" generalizes="Arc" baseStereotypes="Arc EAUML::FK" redefines="EAUML::FK"/>
It wouldn't surprise me if you're confusing EA by not including the generalizes stereotype in the baseStereotypes and the result is that it ends up applying EAUML::FK explicitly in addition to your stereotype. That's not a guarantee though.

Yes it was handcrafted, but FKArc was a typo in the [Code/] here not in the MDG itself.

I'll make the necessary changes to agree with your points and get back on this.

Paolo

[Edit:  So I set it up as you said.  The multiple stereotypes disappeared, BUT I didn't get what I was actually after...  The ability to add FK Constraints using the context menu (or even the dialog).

So I removed the Arc base stereotype so only EAUML::FK was involved but still no joy.  Is this another case of hard coding (implementation decision)?]

[Eve]

I did say that all of the datamodeling stereotype checks are explicit.

[Paolo F Cantoni]

I did say that all of the data modelling stereotype checks are explicit.

Does this also apply to table column stereotypes?  Thus to "enhance' the «column» stereotype, I'll need to create a supplemental stereotype?

Paolo

PS: I'm asking analogously to the PM's "Is it Done Done or just Done?"  i.e. "Is it ALL all, or just all (we did)"

[Paolo F Cantoni]

Further to my point in the previous post,  assuming I create a supplemental stereotype, the only thing I can (effectively) do with that is to add properties (tags) using that stereotype.

If I want to be able to surface those properties via a shape script, I'm "snookered" aren't I?  The supplemental shape script won't be invoked will it?
(I could try it but I don't have the bandwidth RIGHT NOW.  I also suspect I know the answer so I don't want to expend any extra energy with limited bandwidth)

Paolo

[Eve]

Yes, all db modeling stereotypes including column.

I don't think any of the element or connector stereotypes actually define a shape script though, so EA should still find your shape script.

[Paolo F Cantoni]

Yes, all db modeling stereotypes including column.

I don't think any of the element or connector stereotypes actually define a shape script though, so EA should still find your shape script.

To quote from that iconic US comedy show...  "Laugh-in"  "Verrrry Intereshtink!"

So you're saying that EA will execute the first shapescript it comes across?  Only the first or keep going until there are no more (which would be pretty cool and very useful!)?

Paolo

[Eve]

So you're saying that EA will execute the first shapescript it comes across?  Only the first or keep going until there are no more (which would be pretty cool and very useful!)?

It will only execute one. Most shape scripts will draw a filled shape of some sort, so executing both is a lot less useful than you might think.

The one script selected will be the first one, but it prioritizes stereotypes that specify a metatype.

[Paolo F Cantoni]

So you're saying that EA will execute the first shapescript it comes across?  Only the first or keep going until there are no more (which would be pretty cool and very useful!)?

It will only execute one. Most shape scripts will draw a filled shape of some sort, so executing both is a lot less useful than you might think.

The one script selected will be the first one, but it prioritizes stereotypes that specify a metatype.

Thanks, again, Eve,

ALL good to know!  It will help with planning how our modelling technology should best evolve.

Paolo