synchronizing stereotypes and tagged values

[Palm]

Hi,

In the past I have developed a MDG with a toolbox of several stereotypes for classdiagrams.
Recently I modified this MDG with new tagged values for several stereotypes and gave the MDG another name.

When loading the new MDG in an EA that already has the old MDG installed. I first get a conflicting error about a duplicate profile ID.
This can be overcome by removing the old MDG. So far so good.
However I do not succeed in synchronizing the allready declared old stereotypes with the stereotypes from the new MDG. I mean stereotypes with the same name in the old and new profile but with newly added tagged values.

When I right click on the stereotypes in the Toolbox and select "synchronize stereotype" nothing happens.

Should not al elements with the same sterotype name automatically get synchronized? Or is there something hidden that I don't see.

I appreciate your help.
Paul

[Geert Bellekens]

Paul,

Stereotypes are defined by their qualified name: <Profile>::Stereotype

So imagine you have a stereotype called myStereoType in your MyProfileV1, then the fully qualified name of this stereotype is MyProfileV1::myStereoType

If you now change your profile to become MyProfileV2, then the newly created elements will have MyProfileV2::myStereoType as FQN

If you execute Synchronize stereotype from you toolbox you are asking EA to update all stereotypes with FQN MyProfileV2::myStereoType and it will happily ignore any element with stereotype MyProfileV1::myStereoType

It seems like you have two options here

1. you keep the name of the profile and stereotypes so you don't have a name mismatch
2. you execute an update SQL command on t_xref to update name of your profile from MyProfileV1 to MyProfileV2 (obviously by executing an SQL update command you can easily completely destroy your database. Use only if you "know what you are doing")

Geert

[Eve]

1. you keep the name of the profile and stereotypes so you don't have a name mismatch

When doing this you can set an alias on the profile to display what you want. Which is why SysML 1.5 stereotypes have an FQ name with SysML1.4::.

[qwerty]

When doing this you can set an alias on the profile to display what you want. Which is why SysML 1.5 stereotypes have an FQ name with SysML1.4::.

That sounds really strange. Why would SysML deceive users with the version number?

q.

[KP]

There was not a single change in SysML 1.5 that required us to change our technology (apart from version number, obv). We had three choices: Do nothing and have users ask why we don't support SysML 1.5; Change the name of the profile and force users to migrate their models for no gain; or alias the technology so users don't have to do anything. We started with option 1 but decided option 3 was best.

[qwerty]

Sounds reasonable. Somewhat of a bordercase too. Thanks for the clarifiction. Who knows when someone runs into that himself.

q.

[Palm]

Thanks all for your input.

What about exporting the model to XMI and then replacing old profile name with the new one?

This is what I did and it seems to work. Luckily the old name had a unique set of characters so replacing was straight forward and not causing any surprice replacements. After that, synchronizing with the new MDG worked.

A replace "oldname::" with "newname::" is probably more dedicated.

Or "FQName=Oldname" by "FQName=Newname"