In order to express concept specialization, a type may be defined as a specialization of another type (the supertype), yielding a new subtype. A subtype may have properties in addition to the properties of the supertype, and it may redefine virtual local types and transitions.
Specialization is in the specialized type definition specified by "inherits <type expression>",where <type expression> denotes the general type. The general type is said to be the supertype of the specialized type, and the specialized type is said to be a subtype of the general type. Any specialization of the subtype is a subtype of the general type.
Note that the whole <type expression> represents the supertype. Only if the <type expression> contains only <base type>, the supertype is named.
Virtual types can be given constraints, i.e. properties any redefinition of the virtual type must have. These properties are used to guarantee properties of any redefinition. Virtual types are defined in §6.3.2.
<specialization>::=
inherits <type expression> [adding]
If a type subT is derived from a (super)type T through specialization (either directly or indirectly), then
b) T must not be derived from subT,
c) definitions enclosed by T must not be derived from subT.
The resulting content of a specialized type definition with local definitions consists of the content of the supertype followed by the content of the specialized definition. This implies that the set of definitions of the specialized definition is the union of those given in the specialized definition itself and those of the supertype. The resulting set of definitions must obey the rules for distinct names as given in §2.2.2. However, three exceptions to this rule are:
1) a redefinition of a virtual type is a definition with the same name as that of the virtual type,
2) a gate of the supertype may be given an extended definition (in terms of signals conveyed and endpoint constraints) in a subtype - this is specified by a gate definition with the same name as that of the supertype,
3) if the <type expression> contains <actual context parameters> any occurrence of the <base type> of the <type expression> is replaced by the name of the subtype.
The <block substructure definition> given in a specialized block type definition is added to the substructure definition of the block supertype. If present, the name of the substructure of the subtype must be the same as the name of the substructure of the supertype.
The formal context parameters of a subtype are the unbound, formal context parameters of the supertype definition followed by the formal context parameters of the specialized type (see §6.2).
The formal parameters of a specialized process type or procedure are the formal parameters of the process supertype or procedure followed by the formal parameters added in the specialization.
The complete valid input signal set of a specialized process or service type is the union of the complete valid input signal set of the specialized process or service type and the complete valid input signal set of the process or service supertype respectively.
The resulting graph of a specialized process type, service type or procedure definition consists of the graph of its supertype definition followed by the graph of the specialized process type, service type or procedure definition.
The process graph of a given process type, service type or procedure definition may have at most one start transition.
All the <connector name>s defined in the combined <body> must be distinct. It is permissible to have a join from the <body> of the specialized process/procedure/service to a connector defined in the supertype.
A specialized signal definition may add (by appending) sorts to the sort list of the supertype.
A specialized partial type definition may add properties in terms of operators, literals, axioms, operator definitions and default assignment.
NOTE - When a gate in a subtype is an extension of an existing gate in a supertype, the <existing gate symbol> is used in SDL/GR.