In MagicDraw/Cameo an assigned stereotype of a Classifier that types an instance-like element (such as a part Property) "shines through" unless it has an instance-level stereotype assigned. This is sometimes called a "secondary stereotype".

I just read everything in the UML-2.5.1 spec I could find on this, and it does not seem to cover in Annex C: Keywords what have become informally known as secondary stereotype keywords, which behave a bit like what used to be called the Translucency Pattern in Perl, where a magic getter that has not had any corresponding field value set yet returns instead an underlying static value (which "shines through").

Consider this case.

SysML-1.6: 'Stereotypes applied to behaviors may appear on the notation for CallBehaviorAction when invoking those behaviors, as shown in Figure 11-2.'

If a CallBehaviorAction has a Behavior applied, any underlying Stereotype applied to its Behavior "shines through" (but not the tagged values, which BTW confuses some users). Once an explicit Action-level Stereotype is applied to that CallBehaviorAction, it then masks any "underlying" Stereotype applied to it. When the keyword of a secondary stereotype appears on a symbol such as a CallBehaviorAction it is definitely NOT directly representing a stereotype of the element for the symbol on which it actually appears. It is NOT doing what UML-2.5.1 describes in Annex C above.

It turns out that there does appear to be at least one case of a description of the equivalent of secondary stereotype keywords in UML-2.5.1, p.186:

UML-2.5.1: 'If a role is typed by a classifier other than Class, the name compartment of the part box symbol contains the appropriate keyword (e.g., «component») above the name. For some kinds of Classifiers, optionally in the right hand corner an icon denoting the kind of Classifier can be displayed.'

There are some other cases in SysML-1.6:

SysML-1.6: 'Stereotypes applying to parameters can appear on object nodes in activity diagrams, as shown in Figure 11-7, when the object node notation is used as a shorthand for pins. The stereotype applies to all parameters corresponding to the pins notated by the object node.'

ActivityParameterNode symbol in Figure D.36.

If SysML is going to advocate display of such secondary stereotype keywords then there is a need for future SysML to do clearly what UML-2.5.1 did not, which is define a term ssecondary stereotype keyword, including the rule that any associated tagged values should not be displayed, and reference the existing examples.

Otherwise, the spec needs to remove the examples. I am not saying here yet what should be done, but something concrete needs to be done. It is currently completely inconsistent, and definitely confuses a lot of users.

Relates to

Figure D.17 - Internal Structure of Hybrid SUV

Figure D.24 - Defining Fuel Flow Constraints (Parametric Diagram)

Figure D.24 - Defining Fuel Flow Constraints (Parametric Diagram) [ANNOTATED]

Figure D.31 - Defining Measures of Effectiveness and Key Relationships (Parametric Diagram)

Figure D.36 - Behavior Model for “Accelerate” Function (Activity Diagram) {ELIDED PINS}

Figure 11-2: CallBehaviorAction notation with behavior stereotype

BDD: Header1 on an Arduino Mega2560R3

BDD: Header3 on an Arduino Mega2560R3

BDD: Header2 on an Arduino Mega2560R3

IBD: Arduino Mega2560R3 - headers with pins and logical ports

IBD: ATmega2560 with pin Ports in context of Arduino Mega2560R3