UML 2.2 RTF Avatar
  1. OMG Issue

UML22 — UML. Clarify relationship of Substitution and InterfaceRealization

  • Key: UML22-465
  • Legacy Issue Number: 13164
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The specification of ClassifierTemplateParameter has a flag allowSubstitutable. The definition of ClassifierTemplateParameter::constrainingClassifier says “If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted”. What does “compatible” mean? If we look in Templates::Classifier we find this:

    Semantic Variation Points If template parameter constraints apply, then the actual classifier is constrained as follows. If the classifier template parameter:

    • has a generalization, then an actual classifier must have generalization with the same general classifier.

    • has a substitution, then an actual classifier must have a substitution with the same contract.

    • has neither a generalization nor a substitution, then an actual classifier can be any classifier.

    If template parameter constraints do not apply, then an actual classifier can be any classifier.

    Firstly, the spec for classifier template parameters needs to clarify what compatible means; and this clarification must surely include the possibility that the relationship between the constrainingClassifier and the template parameter can be an InterfaceRealization as well as a Substitution.

    Secondly, this text for Semantic Variation Points is weird. Presumably it means that the constraints on substitutability of ClassifierTemplateParameter are a SVP. If so it should say so, and the SVP text should be under ClassifierTemplateParameter.

    Finally, it appears that given the existence of Substitution, InterfaceRealization is completely redundant. A good simplification would be to eliminate InterfaceRealization altogether; failing that to make it a subclass of Substitution to clarify that it has contract compatibility semantics.

  • Reported: UML 2.1.2 — Wed, 17 Dec 2008 05:00 GMT
  • Disposition: Resolved — UML 2.2
  • Disposition Summary:

    Most of this issue is obsolete: these semantic variation points have been clarified in the text. Changing the metamodel
    as suggested in the final point would be too disruptive.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT