Follows on from last night's SysML RTF telecon 09 Apr 2008. Elaborates on an original, quite super idea from Rick Steiner for indicating two types of values (class-level and context-specific) in one IBD compartment.
At first the idea was to use the whole values compartment for EITHER context-specific OR class-level values, with an indicator to show which mode the compartment is in. Then I suggested instead using an indicator per-property, so that only those values which have been explicitly assigned in the values context are set, with the class-level values "showing through" to the part with an indicator. We discussed an appropriate notation to indicate which values are specific to a part and which are "inherited" from the underlying type.
Am using a BDD in the diagram below to mimic an IBD so can illustrate this "translucency" effect, (which Rick compared with "inheriting" some values while redefining others). The part:Type shown below would be a part Property in an IBD in a particular value context.
If no value is given for a value property v1 for part:Type typed here by the block Type then the primitive "static (class-level)" Property.defaultValue (in this case 2.1) shows through. To indicate that the value is in this sense "static" it is underlined (in the values compartment of the part in an IBD).
If a value is explicitly set for another value property v2
(only) for part:Type typed here by the block Type then that particular value (in this case v2=3.2) is shown in the values compartment for the part, and it is not underlined, since "instance-like". Note that in this case the context specific value (v2=3.2) overrides the "static" Property.defaultValue 0.5 (which v2 had in the Type).
This would solve a heap of implementation problems and would help resolve confusion about the meaning of a values comparment on a part in an IBD. As an educator I really like this underline notation and hybrid compartment idea. It blends very well with other conventions for UML and for programming.