Overview of part and port redefinitions
When you create a Part or Port, you create that Part or Port in the context of a top-level Class, Data Type, Interface or Signal, and its contained Parts and Ports. If a Part or Port inherits Parts or Ports from its type (a Class, Data Type, Interface or Signal), the inherited Parts and Ports are used in a different context to that of the Class, Data Type, Interface or Signal. When a Part or Port is created in a different context, Modeler creates that Part or Port as a redefinition so that you can refine it independently of the item it redefines.
Redefinitions created through class, data type, interface or signal inheritance
The following example demonstrates how redefinitions can occur through Class, Data Type, Interface or Signal inheritance. Consider the following Class structure. The Mountain Bicycle and Racing Bicycle sub-classes each inherit the Wheel part through their super-Class (Bicycle).
On a Composite Structure Diagram and in the Parts pane the Classes and Parts appear as follows. In both cases, you can clearly see the different contexts of the Wheel part.
Because the Mountain Bicycle and Racing Bicycle classes use the inherited Wheel part in a different context, Modeler creates the 'Mountain Bicycle.wheel' and 'Racing Bicycle.wheel' parts as redefinitions so that they can be independently refined in context.
Redefinitions created through a type's parts and ports
The following example demonstrates how redefinitions can occur through use of a type (Class, Data Type, Interface or Signal) that contains Parts and Ports. Consider the following Class structure. The Front and Back parts use the Wheel class as their type. The Wheel class contains a Part named Tire.
On a Composite Structure Diagram and in the Parts pane the Classes and Parts appear as follows. You can see the different contexts of the Tire part.
The Front and Back parts inherit the Tire part through their type, that is, the Wheel class. Because the Back and Front parts use the Tire part in a different context, Modeler creates the Bicycle.front.tire and Bicycle.back.tire parts as redefinitions so that they can be independently refined in context.
Redefinition hierarchies
In the previous examples, redefinitions of an original part were created. It is also possible to create redefinitions of a redefinition, resulting in redefinition hierarchies. Consider the following Class structure.
On the Composite Structure Diagram and Parts pane you can see the three different contexts of the Valve part.
The Wheel class inherits the Valve part through its Tire part's type, that is, the Tire class. The inherited Valve part is a redefinition of the Tire.valve part.
The Bicycle class inherits the Valve part through its Wheel part's type, that is, the Wheel class. The inherited Valve part is a redefinition of the Wheel.tire.valve part, which in turn is a redefinition of the Tire.valve part.
Redefinition hierarchies are relevant when inheriting properties.
Refining redefinitions
When Modeler creates a Part or Port as a redefinition, you can refine that redefinition for the context in which it is being used.
The following example demonstrates how redefinitions inherit the Default property. Initially, the Default property of the Tire.valve part is set to Desc: the two redefinitions both inherit the Default property value.
We set the Default property of the Tire.valve part to Desc 1:
• The Wheel.tire.valve part inherits the new Default property value.
• The Bicycle.wheel.tire.valve part inherits the new Default property value from the Wheel.tire.valve part.
We now set the Default property of the Wheel.tire.valve part to Desc 2:
• The Bicycle.wheel.tire.valve part inherits the new Default property value from the Wheel.tire.valve part.
• The Tire.valve part Default property is unchanged.
We now set the Default property of the Tire.valve part to Desc 3:
• The Wheel.tire.valve part does not inherit the new Default property, because its Default property has been changed.
• The Bicycle.wheel.tire.valve part remains unchanged, because it inherits its Default property value from the Wheel.tire.valve part.
You can refine the following features of a redefinition in context:
• You can add Parts, Ports and Associations
A redefinition inherits Parts, Ports and Associations from the Part or Port it redefines. In the context of a redefinition you can add new Parts, Ports and Associations that apply only to that redefinition and any redefinitions of it.
• You can change its Default and Multiplicity properties
A redefinition inherits the Default and Multiplicity properties from the Part or Port it redefines, except if that property has been set on the redefinition. After setting a Default or Multiplicity property on a redefinition, that property no longer inherits its value and it can be set independently.
If the Part contains a Part that has had its Default Value changed in context, on a Composite Structure Diagram the type of the containing Part is shown in brackets. In the following example, the tire part in context has a Default Value that is different from the tire part on the type, that is, the Wheel Class.
The following example,
 | If a redefinition has a multiplicity that can only be greater than the multiplicity of the item it redefines, it will be reported as an error when you perform a consistency check. |
• You can change its tagged values and Text tab properties
At the time of creation, a redefinition inherits the tagged values and Text tab property values of the item it redefines. Thereafter, a redefinition does not inherit tagged values and Text tab property values. If you change a tagged value or Text tab property, the value you set applies only to that redefinition.
• You can change its type
At the time of creation, a redefinition uses the same type as the item it redefines. Thereafter, you can change a redefinition's type to a sub-type of the item's (which it redefines) type.
| | For composite Attribute redefinitions, you can change a redefinition's type to a valid sub-class of its type through its Data Type property. For aggregate Role redefinitions, you can change a redefinition's type to a valid sub-class of its type only by deleting the redefinition to make it virtual. |
• You can apply Stereotypes
At the time of creation, a redefinition inherits the Stereotypes of the item it redefines. Thereafter, how Stereotypes are inherited depends on their Overrideable property:
◦ If you apply a Stereotype that is not overrideable to a redefinition, that Stereotype applies to the underlying Part or Port and all its redefinitions.
◦ If you apply a Stereotype that is overrideable to a redefinition, that Stereotype applies only to that redefinition.
For more information about the Overrideable property, see Overrideable (property).
• You cannot change its Name, Access, Storage, Unique, Read Only and Port properties in isolation
If you change the preceding properties of a redefinition, Modeler changes the properties on the item it redefines.
Rolling up features
On a Composite Structure Diagram you can add the following features to a Part or Port: Parts, Ports, Associations and Dependencies to Interfaces. After creating these features in the context of a Part or Port, you may decide that you want to make those features available through the Part's or Port's type (a Class, Data Type, Interface or Signal): You do this by rolling up the features.
For more information about rolling up part and port features, see Overview of rolling up part and port features.
Virtual and real redefinitions
In a previous example, we created the following Classes on a Class Diagram.
The preceding Class structure results in the creation of two redefinitions. Modeler creates each redefinition as a virtual redefinition. At this point, Modeler has not created an object in the Model for either of the redefinitions.
If we now change the Default value of the Bicycle.back.tire part. Modeler changes the Bicycle.back.tire part to a real redefinition. At this point, Modeler creates an object in the Model for the Bicycle.back.tire part.
A virtual redefinition is effectively a pointer to the item it redefines. If you open the Property Pages of a virtual redefinition, you see the properties of the Part or Port the redefinition redefines. When you change a virtual redefinition (a change being changing a property, Text tab property or tagged value; adding a part or port; or applying a stereotype), Modeler creates an object in the Model and it becomes a real redefinition. As a real redefinition, changes made to the Part or Port in context can be recorded in the Model.
| | When you change a virtual redefinition, Modeler changes the virtual redefinition and any other virtual redefinitions above it in the redefinition hierarchy to real redefinitions. |
Modeler makes use of virtual redefinitions to minimize the database size and maximize Modeler performance.
You should note that because a virtual redefinition is a pointer to the item it redefines, and a real redefinition is an object in the Model, virtual redefinitions and real redefinitions appear to behave differently when a change is made to the item they redefine. The following table summarizes the differences:
Change to Item | Affect on Virtual Redefinition | Affect on Real Redefinition |
|---|---|---|
Change Default property | Change is shown | Inherits change unless the Default property of the redefinition has been changed |
Change Multiplicity property | Change is shown | Inherits unless the Multiplicity property of the redefinition has been changed |
Change standard property (not Default or Multiplicity) | Change is shown | Inherits change |
Add Part or Port | Change is shown | Inherits Part or Port |
Add Association | Association's Role is shown | Association's Role is shown |
Apply Stereotype | Change is shown | If Stereotype is overrideable, does not inherit Stereotype If Stereotype is not overrideable, change is shown |
Change tagged value or Text tab property | Change is shown | If Tag Definition is overrideable, does not inherit changed tagged value If Tag Definition is not overrideable, change is shown |
| | • You cannot delete a virtual redefinition; however, if you delete a Part or Port that has redefinitions, the Part or Port and all its redefinitions are deleted from the Model. • You can change a real redefinition back into a virtual redefinition by deleting it. When you delete a real definition, the redefinition and all its redefinitions are changed to virtual redefinitions. • If a Part or Port has an Association from it, redefinitions of that Part or Port will show the Association's role in the appropriate panes. If you delete the shown Role from a redefinition, the Association will be deleted from the Model. • In a pane, if you copy an Attribute Part or Port that has redefinitions, the redefinitions are not copied. • In a pane, if you move an Attribute Part or Port that has redefinitions, the redefinitions are deleted. |
 | • You can tell if a redefinition is virtual or real through its context menu: ◦ In the Parts pane, if the Delete command is available, the redefinition is a real redefinition; if the Delete command is not available, the redefinition is a virtual redefinition (assuming that you have write access to the redefinition). ◦ On a Composite Structure Diagram, if the Delete Redefinition from Model command is available, the redefinition is a real redefinition; if the Delete Redefinition from Model command is not available, the redefinition is a virtual redefinition. (assuming that you have write access to the redefinition). |
Deleting redefinitions
You cannot delete a virtual redefinition.
When you delete a real redefinition, the real redefinition becomes a virtual redefinition.
On a Composite Structure Diagram the following delete commands are available when you right-click a part or port:
• The Delete command deletes the part or port symbol from the diagram.
• The Delete Redefinition from Model command behaves differently depending on whether the part or port is contained by a Class, or a part or port:
◦ For a part or port contained part or port that is a virtual redefinition, the Delete Redefinition from Model command is not available.
◦ For a part or port contained part or port that is a real redefinition, the Delete Redefinition from Model command deletes that redefinition and any redefinitions of that redefinition. The part or port from which the redefinition was redefined is not deleted.
Note that when you delete a real redefinition of a part or port on a Composite Structure Diagram, the part or port becomes a virtual redefinition and can remain on the diagram.
• The Delete Top Level Definition from Model command deletes the top-level part or port and all its redefinitions from the Model. This command can be used from any redefinition of the top-level part or port.