v15.2β - Redefining EAUML::table and relationship definition

[Paolo F Cantoni]

In our MDG, we have a redefinition of EAUML::table

Code: [Select]

<Stereotype name="DBTbl" metatype="DB Table (OurMDG)" notes="" cx="151" cy="80" bgcolor="15658671" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0" generalizes="EAUML::Table" baseStereotypes="EAUML::Table ClssVrtx AggrgtVrtx" redefines="EAUML::Table">
(ClssVrtx & AggrgtVrtx are our own stereotypes)
We create an Association using the Database Modelling profile between two DBTbl items.  When we try to activate the Foreign Keys... dialog, we get the message that "Both source and target elements must be Tables"

What are we doing wrong?

TIA,
Paolo

[Eve]

What are we doing wrong?

In our MDG, we have a redefinition of EAUML::table

There's the problem. It won't work if you redefine extend it.

[Paolo F Cantoni]

What are we doing wrong?

In our MDG, we have a redefinition of EAUML::table

There's the problem. It won't work if you redefine extend it.

So you're saying we can't have our own version of EAUML::table?

Otherwise, I'm confused.

Paolo

[qwerty]

I tried

Code: [Select]

<Tag name="EAUML::Trace(UML::Abstraction)" type="" description="" unit="" values="" default="Trace"/>which I took from EA's stomach but it did not work. Instead I had to use UML::TraceLink. I guess that EAUML is an off limits MDG.

q.

[Eve]

Yes, that's what I'm saying.

[Paolo F Cantoni]

Yes, that's what I'm saying.

To be clear...  We cannot create our own derivations for EAUML::table (for example to have a shapescript react to additional properties etc.).

Which begs the question:  "Why?"

What happened to:
"Redefine Stereotypes in Another Profile
If you want to redefine a stereotype in another profile, adding new tags and removing or modifying existing tags, while the stereotype behaves in all other ways as if it is the original stereotype, you can use a redefines Generalization as described here."?

Paolo

[Eve]

Because an implementation decision was made that means nearly all datamodeling behavior checks explicitly for the exact stereotype.

Any specialization for any reason WILL prevent it from working. If you implement it as a secondary stereotype it will still work. I know you don't want to do that, but if you want a shape script or extra properties that's what you will need to do in this case.

[Paolo F Cantoni]

Because an implementation decision was made that means nearly all datamodeling behavior checks explicitly for the exact stereotype.

Any specialization for any reason WILL prevent it from working. If you implement it as a secondary stereotype it will still work. I know you don't want to do that, but if you want a shape script or extra properties that's what you will need to do in this case.

Thanks,
At least we now understand why.  I was already considering a secondary stereotype.

Paolo