UML24 — Derived properties that are not marked read-only

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.

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.
Vertex::outgoing
Vertex::incoming
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)
MultiplicityElement::upper
MultiplicityElement::lower
EnumerationLiteral::classifier (Super fig 7.13)
EncapsulatedClassifier::ownedPort
Connector::kind (Super fig 8.3)
ConnectableElement::end (Super fig 8.3)
Classifier::general
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:
Property::opposite
Property::isComposite
Property::default
Parameter::default
Package::ownedType
Package::nestedPackage
MultiplicityElement::upper
MultiplicityElement::lower
Classifier::general
Class::superClass
We are allowed by the notation not to show

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.