Objects with multiple stereotypes - Visual presentation

[Pino]

So, say I import my DB  and I want to use my tables also as Archimate data object. Easy: just add the stereotype ArchiMate3::ArchiMate_DataObject so that the EAUML::Table object also has Archimate attributes. This way I can drop the table on my Archimate diagram and I see it correctly and I can use the proper connectors. But... the table is now showing as an Archimate Data Object also on the ERD  And I can't find a way to tell the diagram to present it as EAUML::Table, which is upsetting. What am I missing here?

[Geert Bellekens]

Don't do that. Messing with multiple stereotypes like that doesn't really work.
It's a messy workaround.

If I were you I would create my ArchiMate Data objects where needed, and relate them to the appropriate tables.
I can't imagine you want each and every table in your database to also be an ArchiMate data object. Lot's of table are not relevant at that level of abstraction (link tables for example)

Geert

[Pino]

Hi Geert, Well that is necessary for a few tables which appear in many diagrams. EA is meant to manage more than one stereotype per object, I've done that many times with other object types, but this visual issue is really bugging me

[Richard Freggi]

Don't do that. Messing with multiple stereotypes like that doesn't really work.
It's a messy workaround.

If I were you I would create my ArchiMate Data objects where needed, and relate them to the appropriate tables.
I can't imagine you want each and every table in your database to also be an ArchiMate data object. Lot's of table are not relevant at that level of abstraction (link tables for example)

Geert

I agree with Geert, I don't know ArchiMate so I can only make an example as UML: I would create new objects that are specializations ('children' using the Is-A connector) of the tables, so they will inherit all properties of the tables, and then add the new stereotype to the children.  Multiple inheritance is not best practice but I think it is tolerated in UML.  Hope this helps!

[Eve]

You can probably achieve the appearance you are after by disabling shape scripts on your data modeling diagram.

I will join the chorus suggesting caution with that approach though. Instead I would recommend using a separate object with a relationship between them. Personally, I would choose a UML Abstraction or Realization. ("An Abstraction is a Relationship that relates two Elements or sets of Elements that represent the same concept at different levels of abstraction or from different viewpoints." "Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).", ) If I wanted to make it clearer I would use a stereotype to clarify the meaning.  You could even add constraints to that connector so that it's offered in the quicklinker etc.