2022x compatibility about exec-cameo-mdk

[dlamoris]

overview of changes:
https://docs.nomagic.com/display/MD2021x/2021x+News+for+Developers
https://docs.nomagic.com/display/MD2021x/Working+with+stereotypes+and+tagged+values

Main summary:
In 19.x, stereotypes and tagged values on elements manifested as follows:

• stereotyped element (any element)
• • stereotype instance (InstanceSpecification)
• • • slot (Slot)

In 2021x:

• stereotyped element (any element)
• • tagged value (BooleanTaggedValue, StringTaggedValue, RealTaggedValue, IntegerTaggedValue or ElementTaggedValue, all specializing TaggedValue)

attribute 'appliedStereotypeIds' is now part of the standard export (we have been adding in '_appliedStereotypeIds' separately)

(InstanceSpecification and Slot outside of the stereotype use case remain the same as before)

MDK

In 19.x mdk, an id spoofing for export/import was utilized in order to preserve the history and identity of slot values (in the model, if a slot value is deleted and re added, its id would change, this breaks history for the slot element).

The id spoofing was done as follows for a slot:

• owningInstanceId-slot-definingFeatureId
  where the owningInstanceId is
• stereotypedElementId_asi
  if the instance is for the purpose of the stereotype.

In 2021x, the stereotype instance disappears, and 'tagged value' is owned directly by the stereotyped element. The new metatype has similar attributes to a Slot but they're named differently.

owningInstance -> taggedValueOwner
definingFeature -> tagDefinition
value (list of value specifications) -> value (list of primitives or elements)

In order to preserve the continuity of mms elements and history going from 19.x to 2021x, the id spoofing for 2021x would apply the same way for TaggedValue elements, as follows:

• taggedValueOwnerId_asi-slot-tagDefinitionId
  since there should be no element whose id ends in _asi anymore, the presence of _asi-slot- would indicate the element is a TaggedValue

For 'value' attribute, the schema for Slot have it as a list of ValueSpecification, which we embed as an object.

For TaggedValue, the export would follow the same pattern of [{value: value}, {value: value2}] instead of [ value, value2 ] to prevent indexing failure in mms elasticsearch and to keep a similar structure to slot

Various places where StereotypesHelper are used would need to be changed to use TagsHelper or similar to fix removed or deprecated apis.

DocGen actions that deal with properties or stereotyped values would need to be updated to handle TaggedValue

Any docgen ocl expression that used to get stereotyped slot values will most likely need to be updated also by the user.

MMS

A migration would need to be applied to mms elements:

• delete all existing elements with id ending in _asi
• for existing slots with '_asi-slot-' in its id:
  • change the owner to the stereotyped element (grandparent)
  • change the element attributes to match TaggedValues
  • migrate the 'value' list of value specification objects to just objects with a single 'value' or 'elementId' attribute

Any special handling that considers _asi would need to be updated, as well as type inference based on stereotype ids

VE

• update any code that handles slot values to also handle tagged value (for editing values) (currently ve inspects the type of the value specification of the slot 'value' list, to handle tagged values it would need to inspect the type of the tagged valued element instead of the value objects)
• any code that creates elements with stereotypes or checks for certain stereotypes would need to be updated accordingly