Relates to:
Issue 12128: Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute
Issue 12219: Section: 08 Blocks: suggest need Quantity stereotype and definition
'Unit and Dimension elements are defined using a rectangular box notation similar to a class, in which only the «unit» or «dimension» stereotype keyword, the name of the Unit or
Dimension, and optionally the “dimension” property value of a Unit may appear.'
MD SysML achieves this by NOT extending InstanceSpecification (see image below) !
The MD SysML <<Unit>> and <<Dimension>> both extend DataType
The resolution states:
the notation that SysML defines for Dimension and Unit differs the standard UML notation for InstanceSpecification
Which is just one reason not to choose Unit [InstanceSpecification] and Dimension [InstanceSpecification]..
OMG Issue Resolution
Unit and Dimension elements are defined using a rectangular box notation similar to a class
Which is one reason for indeed choosing the "Class-like" DataType as base for Unit and Dimension
(even though one then has to restrict Dimension to not be used as a type).
I would already reject the proposal resolution on the basis of this text:
OMG Issue Resolution
Even though the base metaclass of Unit and Dimension is InstanceSpecification
because I reject that metamodel.
In fact a Unit can only be sensibly modelled as "a special kind of Quantity", on in which values of quantities with a chosen unit may be stated. Unit must extend Quantity ! Please visit (and please view the metamodel images carefully):
Unit is (like ValueType) well modelled as a DimensionedType [DataType] (and can be used to type directly for the unitary case):
This leaves however Dimension open to have a different base metaclass from Unit, however then (given that the notation is supposed to be the same) this is hard for UML-based tool vendors.
The observation that the notation needs to be clarified is correct, however binding it to the specific metamodel is not necessary.
