When using an existing Companion Specification often questions pop up about what will happen if the Companion Specification is changing. The good news is, that based on the rules in section 3 the backward compatibility is given and therefore no real harm can happen.

What might happen, is, that the used Companion Specification is adding helpful features by creating subtypes. If the model using the Companion Specification has also created subtypes of the same type, it is not easily possible to use the new features as well.

Therefore, it is recommended, rather to use composition than subtyping when using concepts of another Companion Specification, if possible. An example, illustrating this, is given in Figure 9 and Figure 10.

In Figure 9, subtyping is used. The “ReusedType” has a feature 1, and in another model a subtype “MyObjectType” is created. When, in a new version of the Companion Specification, the “ReusedType” is extended by a subtype “ReusedSubType” adding a mandatory feature 2, “MyObjectType” is still derived from “ReusedType” and cannot use the new feature.

Figure 9 – Reusing extended Companion Specifications by inheritance

In Figure 10, composition is used. The “ReusedType” is added as component to “MyObjectType”. This allows, that any instance of “MyObjectType” can use the new created “ReusedSubType” and therefore the new feature 2, even without changing the model. Not shown in the figure, it is of course also possible (but not required) to create a subtype of “MyObjectType” changing the component to “ReusedSubType” and thereby requiring feature 2.

Note that composition does not always work perfectly, for example when the “ReusedType” is used in other places of the Companion Specification and the “my feature 1” of the new model should be made available at that place as well. In this case, the composition would require inverse browsing to the instance of “MyObjectType”.

Figure 10 – Reusing extended Companion Specifications by composition