sealed abstract classMagicDrawTagPropertyProfileLifecycleDependentClassifierValue extends MagicDrawTagPropertyClassifierValue with TagPropertyProfileLifecycleDependentClassifierValue[MagicDrawUML]
MagicDraw profile mechanism does not support this capability.
However, it could be emulated with a MagicDraw-specific OTI profile
to annotate the use of MagicDraw UML instances owned by some element in the model
as if they were owned directly or indirectly by stereotype instances.
In principle, this is feasible but there are lots of tricky details.
This would require managing references to these MD-specific OTI-annotated instances
such that these OTI-annotated instances would emulate the intent of the lifecycle semantics
tied to applying/unapplying a profile even though such OTI-annotated instances would
be owned by UML elements and creating/deleting them would entail modifying the model
in contradiction to UML 2.5, section 12.3.3
Bottom line, it's non-trivial and full of complications.
This capability would be necessary if it is necessary to support advanced profile techniques
(e.g., see UML 2.5, Figure 12.32 and 12.33) by emulation on top of the MagicDraw 18 API.
Alternatively, NoMagic may decide to improve their support for Profiles so that it would
not be necessary to emulate UML 2.5.
For now, this is not implemented in the OTI/MagicDraw 18 adapter.
MagicDraw profile mechanism does not support this capability. However, it could be emulated with a MagicDraw-specific OTI profile to annotate the use of MagicDraw UML instances owned by some element in the model as if they were owned directly or indirectly by stereotype instances.
In principle, this is feasible but there are lots of tricky details. This would require managing references to these MD-specific OTI-annotated instances such that these OTI-annotated instances would emulate the intent of the lifecycle semantics tied to applying/unapplying a profile even though such OTI-annotated instances would be owned by UML elements and creating/deleting them would entail modifying the model in contradiction to UML 2.5, section 12.3.3
Bottom line, it's non-trivial and full of complications.
This capability would be necessary if it is necessary to support advanced profile techniques (e.g., see UML 2.5, Figure 12.32 and 12.33) by emulation on top of the MagicDraw 18 API. Alternatively, NoMagic may decide to improve their support for Profiles so that it would not be necessary to emulate UML 2.5.
For now, this is not implemented in the OTI/MagicDraw 18 adapter.