UML 2.4 RTF Avatar
  1. OMG Issue

UML24 — Derived properties that are not marked read-only

  • Key: UML24-97
  • Legacy Issue Number: 15568
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Although there is a case in general modeling that derived properties need not be read-only, we should apply a convention in the UML metamodel that derived properties are read-only. There are 24 exceptions to this convention.

  • Reported: UML 2.3 — Wed, 22 Sep 2010 04:00 GMT
  • Disposition: Resolved — UML 2.4
  • Disposition Summary:

    Here is the list of properties that are derived but not readonly. In the absence of compelling arguments why each should not be made readonly, we should make it readonly. This will make the metamodel more systematic and consistent.
    Stereotype::profile (Infra fig 12.2, Super fig 18.2)
    Property::opposite (Super fig 7.12)
    Property::isComposite (Super fig 7.12)
    Property::default (Super fig 7.12)
    Parameter::default (Super fig 7.11)
    Package::ownedType (Infra fig 11.26, Super fig 7.14)
    Package::ownedStereotype (Infra fig 12.2, Super fig 18.2)
    Package::nestedPackage (Infra fig 11.26, Super fig 7.14)
    Operation::upper (Super fig 7.11)
    Operation::type (Super fig 7.11)
    Operation::lower (Super fig 7.11)
    Operation::isUnique (Super fig 7.11)
    Operation::isOrdered (Super fig 7.11)
    EnumerationLiteral::classifier (Super fig 7.13)
    Connector::kind (Super fig 8.3)
    ConnectableElement::end (Super fig 8.3)
    Class::superClass (Super fig 7.12)
    ExtensionEnd::lower However we cannot make all of these properties read-only, because some of them are defined as non-derived in infrastructure. Because the merge rules are such that writeable overrides read-only, in order to make them read-only in the merged model, we.d have to make them read-only even when they are non-derived in Infrastructure, which would make no sense.
    Another reason not to make them all readonly is the following paragraph in Superstructure 2.3:
    ¡°Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.¡±
    This implies that properties writable at L0 should be writeable at L3.
    The properties affected by this are:
    We are allowed by the notation not to show

    {readOnly} on the diagrams. We will show {readOnly}

    on some diagrams because (a) we are changing these diagrams for other reasons and (b) the tool enforces an ¡°all or nothing¡± rule on which decorations we show for attributes. Our current convention is not to show readOnly in the specification text (with one exception), so we.ll carry on with the convention.

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