gate (Z.100)
Gates are defined in block, process or service types (as defined in §6.1.1) and represent connection points for channels and signal routes, connecting instances of these types (as defined in §6.1.3) with other instances of the same entity kind or with the enclosing frame symbol.
<graphical gate constraint> ::=
{ <gate symbol> | <existing gate symbol> }
is associated with
{<gate> [ <signal list area>[<signal list area>] ] }
is connected to
{ <frame symbol> [ <endpoint constraint> ] }
<endpoint constraint> ::=
{ <block symbol> | <process symbol> | <service symbol> }
contains
<textual endpoint constraint>
<gate symbol> ::= <signal route symbol>
<existing gate symbol> ::= <gate symbol 1> | <gate symbol 2>
The <graphical gate constraint> is outside the diagram frame.
The <signal list area> elements are associated with the directions of the signal route symbol.
The symbol in <endpoint constraint> must be the symbol for instance definition corresponding to the type definition in which the gate is defined, i.e. <block symbol>, <process symbol> or <service symbol>.
<signal list area>s and <endpoint constraint> associated with an <existing gate symbol> are regarded as additions to those of the gate definition in the supertype.
An <existing gate symbol> can only appear in a subtype definition, and it is then a representative for the gate with the same <gate name> specified in the supertype of the subtype definition.
For each arrowhead on the <gate symbol>, there must be a <signal list area>. A <signal list area> must be unambiguously close enough to the arrowhead to which it is associated. The arrowhead indicates whether the <signal list area> denotes an in or an out <gate constraint>.
The use of gates in type definitions corresponds to the use of communication paths in the enclosing scope in (set of) instance specifications.
For each instance of a type defining a <gate>, a <signal route to route connection>, a <channel to route connection> or a <channel connection> is derived:
a) For each instantiation of a process type, a <signal route to route connection> is derived in the resulting <process definition> where:
- The <external signal route identifiers> are those signal routes defined in the enclosing block which mention the process and the gate in a <signal route path>.
- The <signal route identifiers> are those signal routes defined inside the <process definition> which mention the keyword env and the gate in the <signal route path>.
b) For each instantiation of a block type, a <channel to route connection> in the resulting <block definition> is derived where:
- The <channel identifiers> are those channels defined in the scope unit enclosing the block which mention the block and the gate in a <channel path>.
- The <signal route identifiers> are those signal routes defined inside the <block definition> which mention the keyword env and the gate in the <channel path>.
c) For each instantiation of a block type containing a <block substructure definition>, a <channel connection> in the resulting scope of the block is derived where:
- The <channel identifiers> are those channels defined in the scope unit enclosing the surrounding block which mention the block and the gate in a <channel path>.
- The <subchannel identifiers> are those channels defined inside the <block substructure definition> which mention the keyword env and the gate in a <channel path>. Any rules for using signal refinement on type-based block instances is defined through the rules for the resulting <channel connection> (see §3.3).