Change sterotype does work for Elements, but not for Relationships

[Viking]

Hi,

I refer to https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_languages/applyingastereotype.html

Via the properties changing the stereotypes for Elements works fine. The shapescript changes the appearance of the element (e.g., changing an application Interface into an infrastructure interface).

When I change a stereotype of a Relationship (e.g., an ArchiMate3::ArchiMate_Composition into an ArchiMate3::ArchiMate_Serving or the other way round), the appearance does not change correctly. While changing different parameters, most often the shapes of composition and serving overlap, but I never get the correct one. Is this intended or is there something to be considered?

[Paolo F Cantoni]

Hi Viking,
You've tripped over one of EA's architectural failures. Connectors are second-class citizens. "Under the hood," they are specified and thus behave quite differently from Elements.

This is not only when changing stereotypes; even the same connector on different diagrams will be rendered differently!  It's a mess.  We get around this by directly manipulating the database with SQL!

If you search for my posts on the subjects, you'll see some issues.

Sorry, I can't solve your problem.

PAolo

[Viking]

Many thanks, Paolo

[Eve]

Via the properties changing the stereotypes for Elements works fine. The shapescript changes the appearance of the element (e.g., changing an application Interface into an infrastructure interface).

When I change a stereotype of a Relationship (e.g., an ArchiMate3::ArchiMate_Composition into an ArchiMate3::ArchiMate_Serving or the other way round), the appearance does not change correctly. While changing different parameters, most often the shapes of composition and serving overlap, but I never get the correct one. Is this intended or is there something to be considered?

I believe the problem is that the relationships that you are using are extending a different base type, while the elements are both extending the same base type.

Don't directly manipulate the database with SQL. You will break things.

[qwerty]

Don't directly manipulate the database with SQL. You will break things.

Incorrect. You might break things.

q.

[Eve]

Incorrect. You might break things.

I stand by my statement.

Even if you're confident with SQL and your understanding of the data model it's safest to assume you will break things.

[qwerty]

And so do I. I can't count how often I used SQL to manipulate the database. Either for performance reason (esp. when we had to migrate our profile versions) or because the API did not offer the tool for what was needed. I have never encountered an issue. Of course I always ran tests in a sandbox before going to production. And there we made a backup before it got serious.

q.