A capsule A that inherits from another capsule B typically has references to elements located in B. For example, the state machine of A may contain redefined states that reference inherited states of B's state machine, and transition triggers may reference inherited ports.
If you make changes to the inheritance so that A no longer inherits from B (neither directly nor indirectly) then these references will become unbound. To prevent this from happening a dialog will appear when you delete or redirect a generalization relationship. The dialog shows the references that will be affected by the inheritance rearrangement and proposes actions to take for preventing the references from becoming unbound.
Note that this dialog will only appear if at least one reference is affected by the inheritance rearrangement. In other cases a simpler version of the dialog will appear:
The two checkboxes are present in both versions of the dialog and work like this:
Absorb all current superclass properties is applicable when a generalization is deleted or redirected. If marked, elements located in the super capsule that are referenced from within the subcapsule will be copied to the subcapsule. By copying (a.k.a absorbing) those elements the references can be bound to the local copies instead of becoming broken after the inheritance rearrangement.
Exclude new superclass properties is applicable when a generalization is added or redirected. If marked, elements located in the new super capsule will be excluded in the subcapsule. Excluding an inherited element means that it will not be present in the subcapsule, and you can use this option to prevent inheriting "too much" from the super capsule. However, it's uncommon to leave all elements excluded, since that would defeat the purpose of the newly introduced generalization, so you can afterwards select some of the excluded elements and invoke the Project Explorer context menu command Reinherit to make them inherited again.
Let's return to the version of the Inheritance Rearrangement dialog that appears when at least one reference is affected by the inheritance rearrangement. For each reference the dialog proposes a default action to take. The default action is chosen to prevent information from being lost. This typically means that referenced elements from the super capsule will be absorbed into the subcapsule so that references can be bound to those local copies instead. The alternative is to delete the referencing element, but since this would mean losing all information stored in the redefining element, this is not the default action.
To decide which action to take for a reference it often helps to navigate to show the referencing element in the model. Double-click on a reference to show it in the Project Explorer, and use the context menu for other navigation options:
If you want to apply a non-default action for a reference, use the menu that appears in the Action column. Note that in some cases only the default action is available. Non-default actions are shown in bold font, and you can press the Set defaults button to go back to use the default actions.
Finally, let's look at a common inheritance refactoring, that involves two consecutive inheritance rearrangements: introducing another capsule into an existing inheritance hierarchy. The best way to perform this refactoring is to first add a generalization from the new capsule to the existing super capsule, and then redirect the existing generalization to let the new capsule become the new super capsule. See the picture below:
If you instead would perform this refactoring in the opposite order, the redirection of the generalization from A to B would cause all references in C that refers to elements in A to become broken (since they are not visible from B). Model RealTime cannot know that those references only are temporarily broken since you next intend to create a new generalization from B to A.
Always keep in mind when you delete or redirect a generalization that references may become broken. You can use the Inheritance Rearrangement dialog to fix such broken references, but the best is of course to work in a way that avoids references to become broken in the first place.