In Magic Model Analyst® (Cameo Simulation Toolkit®) - at least as of version 2024x - using an extending Enumeration literal as a parameter argument value runs but a WARN is issued.
UML-2.5.1 supports use of Generalization with Enumerations:
In any case, Magic Model Analyst® (Cameo Simulation Toolkit®) issues a WARN if one tries to use a an EnumerationlLiteral from an extending Enumeration as an argument value for a Parameter that is typed by the Enumeration it extends. The warning appears to be just that, a mere warning, as it still runs.
The attached image shows some cases, not all of which are recommended in practice. Typical output (with some annotation of the cases) is:
00:00:00,000 : **** Activity EnumExtendRunsButWARNS is initialized. ****
00:00:00,000 : **** Activity EnumExtendRunsButWARNS is started! ****
[printEnum vs EnumA::fe]
00:00:01,994 WARN: Illegal value, '[fe]' is not AbstractEnum in Call Behavior Action.
Enum: fe
[printValue vs EnumA::fe]
00:00:03,080 WARN: Illegal value, '[fe]' is not AbstractValue in Call Behavior Action.
Value: fe
[UsePrintValue vs EnumA::fi]
00:00:04,122 WARN: Illegal value, '[fi]' is not AbstractEnum in Call Behavior Action.
00:00:05,441 WARN: Illegal value, '[fi]' is not AbstractEnum in Call Behavior Action.
Enum: fi
[printValue vs AbstractEnum::impracticalA]
Enum: impracticalA
[printValue vs SubValue extends AbstractValue (LiteralReal 1.1 given)]
Value: 1.1
00:00:06,015 : **** Activity EnumExtendRunsButWARNS execution is terminated. **** The main case explored is the EnumerationLiterals fe and fi of Enumeration EnumA, which extends AbstractEnum. The OpaqueBehavior printEnum and Activity UsePrintEnum each have a Parameter i of Type AbstractEnum. Feeding them with a literal from EnumA results in a WARN to the console (but the values still print fine via the Groovy script of printEnum).
The example shown includes some pathological cases merely for the sake of demonstration and testing:
Certainly having a superset of covering literals as shown in cyan for literals impracticalA impracticalB in Enumeration AbstractEnum is NOT recommended, even if it runs cleanly.
Whilst extending a SysMLv1 ValueType by a SysMLv1 Enumeration (which is both an Enumeration and a ValueType) is permitted (and validates) as shown in magenta it is also NOT recommended.
Why this "restriction" matters
Consider a system with 2 separate families of Signals, and you want console logging diagnostics for Signal sends/receives/effects etc. One way is to have two Enumerations corresponding to each (with each literal corresponding to a Signal type). It would be nice to be able have each extend an AbstractSignalKind Enumeration that can be used as the Type of Parameters for shared logging diagnostics Operations and Behaviors, as you don't want to repeat your logging diagnostics for each family of Signals.
The above strategy works (runs as expected), but you have to live with that WARN in the console. If you wish you can reduce the log level in the Cameo console down from WARN to ERROR mode to filter them out. Note that INFO mode is extremely verbose, and DEBUG mode even more so.
Learn SysML for MBSE with the Webel IT Australia Live Online web seminar or On-Site course!
