Property-specific initial values (a.k.a. Property-specific default values(*)) are specific to the usage of a Block as a part Property in a higher context (by a structured block or "assembly"), and if there are many part Properties of the same type, they may have different property-specific default values (i.e. they will be initialised differently). They are managed by the higher context structured block that owns the part Properties, which initialises or configures their (possibly different) values on instantiation. In our example an abstract Vehicle block will configure its tank:FuelTank part Property by initialising it with a new capacity value.
The property-specific initial values of a part Property are carried by the Slots of an InstanceSpecification of the same type. In the example below have stereotyped the InstanceSpecification tank:FuelTank with «initial values», however this is only for illustration. If you have many parts to configure you may also like to group them in a dedicated Model (I have used a Model named parts below, with a custom stereotype «initialisation»).
Next we will see how to assign these property-specific initial values carries by the Slots of the tank:FuelTank InstanceSpecification to override the static (class-level) default for the capacity ValueProperty in the part tank:FuelTank in the Internal Block Diagram (IBD) for Vehicle.
The Property-specific initial values (a.k.a. the Property-specific defaultValue vector) of a part Property can be assigned in MD SysML using Drag n' Drop of an InstanceSpecification (of the same type as the part Property) from the browser onto the part Property in an Internal Block Diagram (IBD), as illustrated below. (You don't have to have the InstanceSpecification on the IBD, nor
show the illustrative <<initialises>> Dependency.)
On instantiation a (concrete subclass of a) Vehicle will (by default) now initialise the capacity value of the tank:FuelTank to 46.0 L, overriding the static ("class-level") primitive default value of 40.0L that was defined in FuelTank. Note that it is the context block Vehicle - the owner of the part Property tank:FuelTank - which "manages" all of the property-specific initial values and the initialisation of each part Property.
The designer of the abstract Vehicle block, has assumed that this property-specific initial value of the capacity value will suit a wide range of vehicles, so we will next see how this value is inherited in a generic Car.
A concrete Car (with 4 wheels) that simply extends the abstract Vehicle will inherit the property-specific initial values of a Vehicle, i.e. when a :Car is instantiated it will initialise its tank:FuelTank Property to the same new capacity value (again overriding the static default value from FuelTank).
The capacity of the inherited property tank:FuelTank will be initialised to the same property-specific initial value 46.0L managed by Vehicle.
Next we'll see how to re-configure the capacity value of the tank:FuelTank Property in a new special context, a TouringCar.
Consider now a TouringCar that extends Car to add a RoofRack and to specify a larger tank:FuelTank (presumably for long trips). When a :TouringCar is instantiated it must now re-initialise its inherited tank:FuelTank with a larger capacity value (overriding the property-specific initial value of tank:FuelTank within Vehicle, which is inherited via Car). In order to this it must redefine the inherited tank:FuelTank Property of Vehicle.
The TouringCar will also override the static (class-level) default values for the length and width values of the RoofRack, by initialising its rack:RoofRack part with property-specific initial values.
Here we see the Internal Block Diagram (IBD) for the special TouringCar. The part Property tank:FuelTank has be re-initialised to configure it with a tank of larger capacity.
The use of an «InitialValues» stereotype as illustrated in this trail is completely optional. It is there to support education and illustration, and to indicate that a given InstanceSpecification is "reserved" for use as a Property.defaultValue of a Property of the same or compatible Type.
Users can choose to assign an «InitialValues» stereotype to an InstanceSpecification using the standard stereotype assignment mechanisms.
The Block of a Property that the «InitialValues» InstanceSpecification initialises will know the «InitialValues» InstanceSpecification simply as the Property.defaultValue of the owned Property (which can be achieved in MD SysML by dragging the InstanceSpecification onto the Property in an IBD, or via the Property specification box default value field).
It does not matter at all:
(*) It has been suggested that the SysML1.0 defaultValue compartment on a part in an IBD should be renamed initial values
This IBD shows how the same InstanceSpecification (optionally stereotyped as <<InitialValues>>) can be assigned to the Property.defaultValue of more than one Property, and to properties from different blocks.