Mapping of SysML Stereotypes to UML Metclasses

[wikitect]

https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_frameworks/create_toolbox_profiles_using_.html
In order to create a Toolbox Palette element (extending a ToolboxPage) the base metaclass needs to be correct. Sometimes there are slight variations in the name of the metclass used to toolbox elements vs that of the 'vanilla' UML metaclass element.

SysML doesn't have its own metaclasses only Stereotypes so somehow the user has to establish what base  UML Metaclass has been extended by the SysML element to be used for the toolbox element - https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_frameworks/non-uml_metatypes.html

There is a list of the UML Metclass names to be used for UML elements - https://sparxsystems.com/enterprise_architect_user_guide/16.1/modeling_frameworks/elements_used_in_toolboxes.html

Is there a similar mapping between SysML elements and UML Metaclasses? How is it possible to establish this? Surely I don't have to try and piece this together using the normative SysML profile from the OMG and keep my fingers crossed that the same names apply?

[Geert Bellekens]

The real info is stored in the SysML MDG file, but this query could also help

Code: [Select]

select distinct o.Object_Type, o.Stereotype
  from t_object o
 inner join t_xref x on x.Client = o.ea_guid
and x.Name = 'Stereotypes'
and x.Description like '%FQName=SysML1.4%'
Geert

[wikitect]

Thanks Geert - a lot more help that a reference to interrogating some weird API.

BTW where are the built-in MDGs kept? Might be worth me pointing my XML development tool at it to see what I can find ....

[Geert Bellekens]

Thanks Geert - a lot more help that a reference to interrogating some weird API.

BTW where are the built-in MDGs kept? Might be worth me pointing my XML development tool at it to see what I can find ....

Some of them are in %program files%\Sparx Systems\EA\MDGTechnologies and those you can actually read.
Some others are in  %program files%\Sparx Systems\EAInternalTechnologies . These are actually somehow binary encoded, and I haven't found a way to read them (yet)

SysML is in the latter case.

Geert

[wikitect]

Tried to do the same for connector elements using t_connector, Connector_Type , Type = 'connector property' but not working yet.

[Geert Bellekens]

Tried to do the same for connector elements using t_connector, Connector_Type , Type = 'connector property' but not working yet.

This should give you the same for connectors:

Code: [Select]

select distinct c.Connector_Type, c.Stereotype
  from t_connector c
 inner join t_xref x on x.Client = c.ea_guid
and x.Name = 'Stereotypes'
and x.Description like '%FQName=SysML1.4%'
Geert

[wikitect]

I'm missing SysML stereotypes in the list returned from the query vs what is offered by the Extend Metaclass dialogue > Stereotypes > SysML1.4

Missing in terms of Requirement are the following relationships:-

• SysML::deriveReqt
• SysML::satisfy
• SysML::verify

[li\SysML::conform[/li]
[/list]

[Geert Bellekens]

I'm missing SysML stereotypes in the list returned from the query vs what is offered by the Extend Metaclass dialogue > Stereotypes > SysML1.4

Missing in terms of Requirement are the following relationships:-

• SysML::deriveReqt
• SysML::satisfy
• SysML::verify

[li\SysML::conform[/li]
[/list]

The query can only return those that are actually used in this model.

So if you haven't used them they will not show up. If I run that query on my model it returns nothing at all (since I don't use SysML)

Geert

[wikitect]

The query can only return those that are actually used in this model.

So if you haven't used them they will not show up. If I run that query on my model it returns nothing at all (since I don't use SysML)

Geert

Understood. It's certainly causing me a lot of grief adding the SysML profile(s) so tomorrow morning there's going to be a long email to Sparx Support ....

[Geert Bellekens]

Another technique is to create the correct thing, and then remove the stereotype. That leaves you with the plain UML typed object.
That is what I usually do when doing profiles

Geert

[wikitect]

Thanks. Had forgotten that one. Struggling with SysML::trace which has a UML::Trace base (Toolbox uses TraceLink which creates a EAUML::trace not the SysML one defined).

[Geert Bellekens]

Thanks. Had forgotten that one. Struggling with SysML::trace which has a UML::Trace base (Toolbox uses TraceLink which creates a EAUML::trace not the SysML one defined).

Trace is a bit of a weird one as it is defined in EA as an abstraction (or sometimes a dependency) with stereotype «trace», so there's no "trace" connector type.

In terms of toolbox, I think you can go straight to the actual connectortype

So SysML1.4::trace(UML::Abstraction)

Could also be a dependency though, check the database to be sure.

Geert

[wikitect]

I've been around the (trace!) loop in the past - I use the Abstraction for TRAK::traces to  - connector.

A SysML::trace isn't a UML::Abstraction - it appears to be a UML::Trace.

Unfortunately toolbox definition does not allow UML::Trace - it only provides EAUML::TraceLink which and therefore you don't end up with a SysML::Trace element which is needed to get the behaviour on a SysML Block compartment visibility for the 'tracedTo', 'tracedFrom' compartments - https://sparxsystems.com/enterprise_architect_user_guide/14.0/model_domains/block_element_compartments.html