Los objetivos generales al definir el LED han sido los de proporcionar un lenguaje que:

a) sea fácil de aprender, utilizar e interpretar;

b) proporcione una especificación inequívoca, apropiada para pedidos y ofertas;

c) pueda ampliarse de modo que sea aplicable a nuevos desarrollos;

d) admita diversas metodologías de especificación y diseño de sistemas, sin presuponer la utilización de una de éstas.

El área principal de aplicación del LED es la especificación del comportamiento de aspectos de sistemas que funcionan en tiempo real. Entre estas aplicaciones están:

a) procesamiento de llamadas (por ejemplo tratamiento de llamadas, señalización telefónica, determinación del importe de las comunicaciones) en sistemas de conmutación;

b) mantenimiento y tratamiento de los fallos (por ejemplo, eliminación automática de fallos, pruebas de rutina) en sistemas generales de telecomunicaciones;

c) control de sistemas (por ejemplo control de sobrecarga, procedimientos de modificación y ampliación);

d) funciones de operación y mantenimiento, gestión de la red;

e) protocolos de comunicación de datos,

El LED puede utilizarse, desde luego, para la especificación funcional del comportamiento de cualquier objeto que pueda especificarse utilizando un modelo discreto, por lo que ha de entenderse que el objeto comunica con su entorno por mensajes discretos.

El LED es un lenguaje rico y puede utilizarse para especificaciones informales de alto nivel (y/o formalmente incompletas), para especificaciones semiformales, y para especificaciones detalladas. El usuario debe elegir las partes apropiadas del LED para el nivel deseado de comunicación y el entorno en que se utiliza el lenguaje. Según el entorno en que se utiliza una especificación, muchos aspectos pueden dejarse para que sean definidos de común acuerdo entre el origen y el destino de la especificación.

Así, el LED puede utilizarse para producir:

a) requisitos de facilidades,

b) especificaciones de sistemas,

c) Recomendaciones del CCITT

d) especificaciones de diseño de sistemas,

e) especificaciones detalladas

f) diseño de sistemas (tanto de alto nivel como detallado),

g) prueba de sistemas

y la organización usuaria puede elegir el nivel apropiado de aplicación del LED.

Una especificación LED define un comportamiento de sistema en forma de estímulo/respuesta, suponiendo que tanto los estímulos como las respuestas son discretos y dan información. En particular, una especificación de sistema se percibe como la secuencia de respuestas a cualquier secuencia dada de estímulos.

El modelo de especificación de sistema se basa en el concepto de máquinas de estados finitos ampliados, que comunican.

El LED proporciona también conceptos estructurales que facilitan la especificación de sistemas grandes y/o complejos. Estas construcciones permiten la partición de la especificación de sistema en unidades manejables que pueden ser tratadas y comprendidas independientemente. La partición puede efectuarse en cierto número de pasos como resultado de los cuales se obtiene una estructura jerárquica de unidades que definen el sistema a diferentes niveles.

Los sistemas especificados en LED se comportan según los estímulos recibidos del mundo exterior. Este mundo exterior se denomina entorno del sistema que se especifica.

Se supone que hay una o más instancias de proceso en el entorno y, por lo tanto, las señales que pasan del entorno al sistema tienen asociadas identidades de estas instancias de proceso. Estos procesos tienen valores PId diferentes de cualquier valor PId del sistema (véase el 5.6.10 ).

Aunque el comportamiento del entorno es no determinista, debe obedecer a las limitaciones impuestas por la especificación del sistema.

Una especificación de sistema es una especificación de sistema LED válida, únicamente si satisface las reglas sintácticas y las condiciones estáticas de LED.

Si al interpretar una especificación LED válida se viola una condición dinámica, ocurre un error. Una interpretación de una especificación de sistema que conduce a un error significa que el comportamiento posterior del sistema no puede ser derivado de la especificación.

En los 2, 3, 4, 5 la Recomendación está organizada por temas descritos en una introducción (opcional) seguida por ítems de enumeración titulados sobre:

a) Gramática abstracta - descrita por la sintaxis abstracta y las condiciones estáticas para la formación correcta.

b) Gramática textual concreta - tanto la gramática textual común, utilizada para LED/PR y LED/GR, como la gramática utilizada solamente para LED/PR. Esta gramática se describe por la sintaxis textual, las condiciones estáticas y las reglas de formación correcta para la sintaxis textual, y por la relación de la sintaxis textual con la sintaxis abstracta.

c) Gramática gráfica concreta - descrita por la sintaxis gráfica, las condiciones estáticas y las reglas de formación correcta para la sintaxis gráfica, la relación de esta sintaxis con la sintaxis abstracta, y algunas reglas de dibujo adicionales (a las indicadas en 2.2.4 ).

d) Semántica - da significado a un tipo, establece sus propiedades, la forma en que se interpreta una instancia de ese tipo y las eventuales condiciones dinámicas que deben cumplirse para que la instancia de ese tipo tenga un comportamiento correcto en el sentido LED.

e) Modelo - da la relación de correspondencia para notaciones taquigráficas expresadas en términos de construcciones de sintaxis concreta, estrictas, previamente definidas.

f) Ejemplos

Cuando un tema tiene una introducción seguida de un ítem de enumeración titulado, se considera que la introducción es una parte informal de la Recomendación, presentada solamente para facilitar la comprensión y no para completar la Recomendación.

Si un ítem de numeración titulado no tiene texto, se omite por completo.

La parte restante de esta sección describe los otros formalismos especiales utilizados en cada ítem de enumeración titulado y los títulos utilizados. Puede considerarse también como un ejemplo de la disposición tipográfica de los ítems de enumeración titulados del primer nivel, definidos más arriba, donde este texto formaría parte de una sección de introducción.

Gramática abstracta

La notación de sintaxis abstracta se define en 1.5.1 .

Si se omite el ítem de enumeración titulado gramática abstracta , no habrá entonces sintaxis abstracta adicional para el tema que se está presentando, y la sintaxis concreta corresponderá con la sintaxis abstracta definida por otra sección numerada de texto.

Se podrá hacer referencia a las reglas de la sintaxis abstracta a partir de cualesquiera ítems de enumeración titulados, utilizando el nombre de regla escrito en cursiva.

Las reglas en la notación formal pueden ir seguidas de párrafos que definen condiciones que deben ser satisfechas por una definición LED formada correctamente y que pueden ser verificadas sin interpretación de una instancia. Las condiciones estáticas en este punto se refieren solamente a la sintaxis abstracta. Las condiciones estáticas que sólo son importantes para la sintaxis concreta se definen después de la sintaxis concreta. Las condiciones estáticas de la sintaxis abstracta, junto con la sintaxis abstracta, definen la gramática abstracta del lenguaje.

Gramática textual concreta

La sintaxis textual concreta se especifica en la forma Backus-Naur ampliada de la descripción de sintaxis definida en la Recomendación Z.200, 2.1 (véase también 1.5.2 ).

La sintaxis textual va seguida de párrafos que definen las condiciones estáticas que deben ser satisfechas en un texto formado correctamente y que deben ser verificadas sin interpretación de una instancia. Son también aplicables las condiciones estáticas (si existen) de la gramática abstracta.

En muchos casos hay una relación simple entre la sintaxis concreta y la abstracta, pues una regla de sintaxis concreta se representa simplemente por una sola regla en la sintaxis abstracta. Cuando el mismo nombre se utiliza en la sintaxis abstracta y en la concreta para representar el mismo concepto, el texto `&lab;x> en la sintaxis concreta representa X en la sintaxis abstracta' está implícito en la descripción del lenguaje y suele omitirse. En este contexto, no se distingue entre mayúsculas y minúsculas pero las subcategorías semánticas subrayadas son significativas.

La sintaxis textual concreta que no es una forma taquigráfica (sintaxis derivada, modelada por otras construcciones LED) es sintaxis textual concreta estricta. La relación de una sintaxis textual concreta con una sintaxis abstracta está definida solamente para la sintaxis textual concreta estricta.

La relación entre sintaxis textual concreta y sintaxis abstracta se omite si el tema que se está definiendo es una forma taquigráfica que está modelada por otras construcciones LED (véase modelo , más adelante).

Gramática gráfica concreta

La sintaxis gráfica concreta se especifica en la forma Backus-Naur ampliada de descripción de sintaxis definida en 1.5.3 .

La sintaxis gráfica va seguida de párrafos que definen las condiciones estáticas que deben cumplirse en LED/GR formado correctamente y que pueden verificarse sin interpretación de una instancia. Son también aplicables las condiciones estáticas (si existen) de la gramática abstracta.

La relación entre sintaxis gráfica concreta y sintaxis abstracta se omite si el tema que se está definiendo es una forma taquigráfica que está modelada por otras construcciones LED (véase modelo , más adelante).

En muchos casos hay una relación simple entre diagramas de gramática gráfica concreta y definiciones de sintaxis abstracta. Cuando el nombre de un símbolo no terminal comienza en la gramática concreta por la palabra `diagrama' y hay un nombre en la gramática abstracta que sólo difiere en que comienza por la palabra definición , las dos reglas representan el mismo concepto. Por ejemplo, &lab;diagrama de sistema> en la gramática concreta y definición-de-sistema en la gramática abstracta son correspondientes.

La expansión en la sintaxis concreta, proveniente de facilidades tales como definiciones remotas ( 2.4.1 ), macros ( 4.2 ) y correspondencias de literales ( 5.4.1.15 ), etc., debe considerarse antes que la correspondencia entre la sintaxis concreta y la abstracta.

Semántica

Se utilizan propiedades en las reglas de formación correcta que implican bien el tipo, bien otros tipos que se refieren a ese tipo.

Un ejemplo de propiedad es el conjunto de identificadores de señal de entrada válida de un proceso. Esta propiedad se utiliza en la condición estática `Para cada nodo-de-estado , todos los identificadores-de-señal de entrada (en el conjunto de señales de entrada válidas) aparecen, bien en un conjunto-de-señales-de-conservación , bien en un nodo-de-entrada .' .

Todas las instancias tienen una propiedad de identidad pero, a menos que esté formada de alguna manera poco usual, esta propiedad se determina como se define en la sección general sobre identidades en el 2 . Por consiguiente, esto generalmente no se menciona como una propiedad de identidad. Además, no ha sido necesario mencionar subcomponentes de definiciones contenidos en la definición, pues la pertenencia de tales subcomponentes es evidente en la sintaxis abstracta. Por ejemplo, es evidente que una definición de bloque `tiene' encerradas definiciones de proceso y/o una definición de subestructura de bloque.

Una propiedad es estática si puede determinarse sin interpretación de una especificación de sistema LED, y es dinámica si se requiere una interpretación de la misma para determinarla.

La interpretación se describe de una manera operacional. Toda lista en la sintaxis abstracta deberá interpretarse en el orden dado. Esto es, la Recomendación describe cómo se crean las instancias a partir de la definición de sistema y cómo estas instancias se interpretan en una `máquina LED abstracta' .

Son condiciones dinámicas aquéllas que deben cumplirse durante la interpretación y no pueden verificarse sin interpretación. Las condiciones dinámicas pueden conducir a errores (véase 1.3.3 ).

Modelo

Se considera que algunas construcciones son `sintaxis concretas derivadas' (o notaciones taquigráficas) de otras construcciones de sintaxis concreta equivalentes. Por ejemplo, omitir una entrada de una señal es sintaxis concreta derivada de una entrada de esa señal seguida de una transición nula que retorna al mismo estado.

Algunas veces esta `sintaxis concreta derivada' , si fuese expandida, daría lugar a una representación extremadamente grande (quizá infinita). Sin embargo, la semántica de tal especificación puede ser determinada.

Ejemplos

El ítem de enumeración titulado Ejemplos contiene ejemplos.

Se utiliza el siguiente subconjunto de Meta IV para describir la sintaxis abstracta de LED.

Una definición en la sintaxis abstracta puede considerarse como un objeto compuesto (un árbol) denominado que define un conjunto de subcomponentes.

Por ejemplo, la sintaxis abstracta para definición de variable es

Definición-de-variable :: Nombre de variable Identificador-de-referencia-de-género

que define el dominio del objeto compuesto (árbol) denominado definición-de-variable . Este objeto consiste en dos subcomponentes, que a su vez podrían ser árboles.

La definición Meta IV

Identificador-de-referencia-de-género = Identificador

expresa que un identificador-de-referencia-de-género es un identificador , por lo que no puede distinguirse sintácticamente de otros identificadores.

Un objeto podría también pertenecer a algunos dominios elementales (no compuestos). En el contexto de LED, éstos son:

a) Objetos enteros

Ejemplo:

Número-de-instancias :: Ento Ento

Número-de-instancias denota un dominio compuesto que contiene dos valores enteros ( Ento ) que denotan el número inicial y el número máximo de instancias.

b) Objetos citación

Se representan por una secuencia cualquiera, en negrilla, de letras mayúsculas y dígitos.

Ejemplo:

Proceso-de-destino = Identificador-de-proceso | ENVIRONMENT

El proceso-de-destino es bien un identificador-de-proceso , bien el entorno que está denotado por la citación ENVIRONMENT .

c) Objetos testigo

Testigo denota el dominio de testigos. Puede considerarse que este dominio consiste en un conjunto potencialmente infinito de objetos atómicos distintos que no requieren una representación.

Ejemplo:

Nombre :: Testigo

Un nombre consiste en un objeto atómico tal que cualquier nombre puede distinguirse de cualquier otro nombre.

d) Objetos no especificados

Un objeto no especificado denota dominios que podrían tener alguna representación, pero esa representación no concierne a esta Recomendación.

Ejemplo:

Texto-informal :: ...

Texto-informal contiene un objeto que no es interpretado.

Los siguientes operadores (constructores) en FBN (véase 1.5.2 ) se utilizan también en la sintaxis abstracta: `*' para una lista que puede estar vacía, `+' para una lista no vacía, `|' para alternativa y `[' `]' para opcional.

Se utilizan paréntesis para la agrupación de dominios que están lógicamente relacionados.

Por último, la sintaxis abstracta utiliza otro operador postfijo ` -set ' que da un conjunto (colección no ordenada de objetos distintos).

Ejemplo:

Gráfico-de-proceso :: Nodo-de-arranque-de-proceso Nodo-de-estado -set

Un gráfico-de-proceso consiste en un nodo-de-arranque-de-proceso y un conjunto de nodos-de-estado .

En la forma Backus-Naur un símbolo terminal, bien se indica sin encerrarlo entre paréntesis angulares (es decir, el signo menor que y el signo mayor que, &lab;y>), o bien es una de las dos representaciones &lab;nombre> y &lab;cadena de caracteres>. Obsérvese que los dos terminales especiales &lab;nombre> y &lab;cadena de caracteres> pueden tener también semánticas resaltadas como se define más adelante.

Los paréntesis angulares y la palabra o palabras encerradas son, bien un símbolo no terminal, bien uno de los dos símbolos terminales &lab;cadena de caracteres> o &lab;nombre>. Categorías sintácticas son los no terminales indicados por una o más palabras encerradas entre paréntesis angulares. Para cada símbolo no terminal se da una regla de producción sea en gramática textual concreta, sea en gramática gráfica. Por ejemplo

&lab;expresión de visión> ::=

VIEW (&lab;identificador de variable >, &lab;expresión>)

Una regla de producción para un símbolo no terminal consiste en el símbolo no terminal a la izquierda del símbolo ::=, y una o más construcciones, que consisten en uno o más símbolos no terminales y/o terminales en el lado derecho. Por ejemplo &lab;expresión de visión>, &lab;identificador de variable > y &lab;expresión> en el ejemplo anterior son no terminales; VIEW, los paréntesis y la coma son símbolos terminales.

Algunas veces el símbolo incluye una parte subrayada. Esta parte subrayada resalta un aspecto semántico de ese símbolo. Por ejemplo &lab;identificador de variable > es sintácticamente idéntico a &lab;identificador>, pero semánticamente requiere que el identificador sea un identificador de variable.

En el lado derecho del símbolo ::= puede haber varias producciones alternativas para el no terminal, separadas por barras verticales (^|^). Por ejemplo:

&lab;área de bloque> ::=

&lab;referencia gráfica de bloque>

^| &lab;diagrama de bloque>

expresa que un <área de bloque> es, bien una &lab;referencia gráfica de bloque>, bien un &lab;diagrama de bloque>.

Los elementos sintácticos pueden agruparse utilizando llaves ({^y^}), similares a los paréntesis en Meta IV (véase 1.5.1 ). Un grupo encerrado entre llaves puede contener una o más barras verticales, que indican elementos sintácticos alternativos. Por ejemplo:

&lab;área de interacción de bloques> ::=

{<área de bloque> | <área de definición de canal>}+

La repetición de grupos encerrados en llaves se indica por un asterisco (*) o signo más (+). Un asterisco indica que el grupo es opcional y puede repetirse cualquier número de veces; un signo más indica que el grupo tiene que estar presente y puede repetirse cualquier número de veces. El ejemplo anterior expresa que un <área de interacción de bloques> contiene por lo menos un &lab;área de bloque> o <área de definición de canal> y puede contener más <área de bloque>s y <área de definición de canal>s.

Si se agrupan elementos sintácticos por medio de corchetes ([^y^]), el grupo es opcional. Por ejemplo:

&lab;encabezamiento de proceso> ::=

PROCESS &lab;identificador de proceso > [&lab;parámetros formales>]

expresa que un &lab;encabezamiento de proceso> puede, pero no tiene necesariamente que, contener &lab;parámetros formales>.

Para la gramática gráfica el metalenguaje descrito en 1.5.2 se amplía con los siguientes metasímbolos:

a) contains

b) is associated with

c) is followed by

d) is connected to

e) set

El metasímbolo set es un operador postfijo que actúa sobre los elementos sintácticos que le preceden inmediatamente, dentro de llaves, e indica un conjunto (no ordenado) de ítems. Cada ítem puede ser un grupo cualquiera de elementos sintácticos, en cuyo caso debe ser ampliado antes de aplicar el metasímbolo set .

Ejemplo:

{^{<área de texto de sistema>}* {&lab;diagrama de macro>}* &lab;área de interacción de bloques>} set

es un conjunto de cero o más <área de texto de sistema>s, cero o más &lab;diagrama de macro>s y un <área de interacción de bloques>.

Todos los demás metasímbolos son operadores infijos, que tienen un símbolo gráfico no terminal como argumento de la izquierda. El argumento de la derecha es, bien un grupo de elementos sintácticos encerrados por llaves, bien un elemento sintáctico único. Si el lado derecho de una regla de producción tiene un símbolo gráfico no terminal como primer elemento y contiene uno o más de estos operadores infijos, el símbolo gráfico no terminal es el argumento de la izquierda de cada uno de estos operadores infijos. Un símbolo gráfico no terminal es un no terminal que tiene la palabra `símbolo' inmediatamente después del signo <.

El metasímbolo contains indica que su argumento de la derecha debe situarse dentro de su argumento de la izquierda y del &lab;símbolo de ampliación de texto> asociado, si existe. Ejemplo:

&lab;referencia gráfica de bloque> ::=

&lab;símbolo de bloque> contains &lab;nombre de bloque >

&lab;símbolo de bloque> ::=

Figure omitted: 05 Figura Figura, p. significa lo siguiente

Figure omitted: 05 Figura Figura, p. El metasímbolo is associated with indica que su argumento de la derecha está lógicamente asociado a su argumento de la izquierda (como si estuviese `contenido' en ese argumento; la asociación inequívoca se asegura por reglas de dibujo adecuadas).

El metasímbolo is followed by significa que su argumento de la derecha sigue (tanto lógicamente como en el dibujo) a su argumento de la izquierda.

El metasímbolo is connected to significa que su argumento de la derecha está conectado (tanto lógicamente como en el dibujo) a su argumento de la izquierda.

Figure omitted: 20 blanc file.header.2

Las reglas léxicas definen unidades léxicas. Las unidades léxicas son los símbolos terminales de la sintaxis textual concreta .

&lab;unidad léxica> ::= &lab;nombre> | &lab;cadena de caracteres> | &lab;especial> | &lab;especial compuesto> | &lab;nota> | &lab;palabra clave>

&lab;nombre> ::= &lab;palabra> {^&lab;subrayado> &lab;palabra>^}*

&lab;palabra> ::= {&lab;alfanumérico> | &lab;punto>}* &lab;alfanumérico> {&lab;alfanumérico> | &lab;punto>}*

&lab;alfanumérico> ::= &lab;letra> | &lab;dígito decimal> | &lab;nacional>

&lab;letra> ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z

&lab;dígito decimal> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

&lab;nacional> ::= ## | ò [Tps.Non.Photo "Montage"] | ° [Tps.Non.Photo "Montage"] | @ [Tps.Non.Photo "Montage"] | &lab;corchete izquierdo> | \ [Tps.Non.Photo "Montage"] | &lab;corchete derecho> | &lab;llave izquierda> | &lab;línea vertical> | &lab;llave derecha> | &lab;tilde> | &lab;punta de flecha hacia arriba>

&lab;corchete izquierdo> ::= [

&lab;corchete derecho> ::= ]

&lab;llave izquierda> ::= {

&lab;línea vertical> ::= |

&lab;llave derecha> ::= }

&lab;tilde> ::= ñ Montage

&lab;punta de flecha hacia arriba> ::= Montage

&lab;punto> ::= .

&lab;subrayado> ::= -

&lab;cadena de caracteres> ::= &lab;apóstrofo> {&lab;alfanumérico> | &lab;otro carácter> | &lab;especial> | &lab;punto> | &lab;subrayado> | &lab;espacio> | &lab;apóstrofo> &lab;apóstrofo>}* &lab;apóstrofo>

&lab;texto> ::= {&lab;alfanumérico> | &lab;otro carácter> | &lab;especial> | &lab;punto> | &lab;subrayado> | &lab;espacio> | &lab;apóstrofo>}*

&lab;apóstrofo> ::= `

&lab;otro carácter> ::= ? | & | %

&lab;especial> ::= + | - | ! | / | > | * | ( | ) | " | , | ; | < | = | :

&lab;especial compuesto> ::= == | ==> | /= | <= | >= | // | := | => | -> | (. | .)

&lab;nota> ::= /* &lab;texto> */

&lab;palabra clave> ::= ACTIVE | ADDING | ALL | ALTERNATIVE | AND | AXIOMS | BLOCK | CALL | CHANNEL | COMMENT | CONNECT | CONSTANT | CONSTANTS | CREATE | DCL | DECISION | DEFAULT | ELSE | ENDALTERNATIVE | ENDBLOCK | ENDCHANNEL | ENDDECISION | ENDGENERATOR | ENDMACRO | ENDNEWTYPE | ENDPROCEDURE | ENDPROCESS | ENDREFINEMENT | ENDSELECT | ENDSERVICE | ENDSTATE | ENDSUBSTRUCTURE | ENDSYNTYPE | ENDSYSTEM | ENV | ERROR | EXPORT | EXPORTED | EXTERNAL | FI | FOR | FPAR | FROM | GENERATOR | IF | IMPORT | IMPORTED | IN | INHERITS | INPUT | JOIN | LITERAL | LITERALS | MACRO | MACRODEFINITION | MACROID | MAP | MOD | NAMECLASS | NEWTYPE | NEXTSTATE | NOT | NOW | OFFSPRING | OPERATOR | OPERATORS | OR | ORDERING | OUT | OUTPUT | PARENT | PRIORITY | PROCEDURE | PROCESS | PROVIDED | REFERENCED | REFINEMENT | REM | RESET | RETURN | REVEALED | REVERSE | SAVE | SELECT | SELF | SENDER | SERVICE | SET | SIGNAL | SIGNALLIST | SIGNALROUTE | SIGNALSET | SPELLING | START | STATE | STOP | STRUCT | SUBSTRUCTURE | SYNONYM | SYNTYPE | SYSTEM | TASK | THEN | TIMER | TO | TYPE | VIA | VIEW | VIEWED | WITH | XOR

&lab;espacio> representa el carácter del Alfabeto No. 5 del CCITT para espacio.

Los caracteres &lab;nacional> se han representado según figuran en la versión internacional de referencia del Alfabeto No. 5 del CCITT (Recomendación T.50). La responsabilidad de la definición de las representaciones nacionales de estos caracteres incumbe a los organismos nacionales de normalización.

Todas las &lab;letra>s se tratan siempre como si fuesen mayúsculas, a menos que se encuentren dentro de &lab;cadena de caracteres>. (El tratamiento de los &lab;nacional>s pueden definirlo los organismos nacionales de normalización.)

Una &lab;unidad léxica> es terminada por el primer carácter que no puede formar parte de la &lab;unidad léxica> de acuerdo con la sintaxis especificada anteriormente. Cuando un carácter &lab;subrayado> va seguido de uno o más caracteres de control (los caracteres de control se definen en la Recomendación T.50) o espacios, todos esos caracteres (incluido el &lab;subrayado>) se ignoran; por ejemplo, A$$-B denota el mismo &lab;nombre> que AB. Este uso de &lab;subrayado> permite dividir &lab;unidad léxica>s en más de una línea.

Cuando un carácter &lab;subrayado> va seguido por una &lab;palabra> en un &lab;nombre>, puede especificarse uno o más caracteres de control o espacios en lugar del carácter &lab;subrayado>, siempre y cuando una de las &lab;palabras>s que incluyen al carácter &lab;subrayado> no constituyan una &lab;palabra clave>; por ejemplo A B denota el mismo &lab;nombre> que A$$-B.

Sin embargo, en algunos casos la ausencia de &lab;subrayado> en &lab;nombre>s es ambigua, por lo que se aplican las reglas siguientes:

1. Los &lab;subrayado>s en un &lab;nombre> en un &lab;ítem de trayecto> deben especificarse explícitamente.

2. Cuando uno o más &lab;nombre>s o &lab;identificador>s pueden ir seguidos directamente por un &lab;género> (por ejemplo &lab;definición de variable>s, &lab;definición de visión>s), deben especificarse explícitamente los &lab;subrayado>s en esos &lab;nombre>s o &lab;identificador>s.

3. Cuando una &lab;definición de datos> contiene &lab;instanciaciones de generador>, los &lab;subrayado>s en el &lab;nombre de género> que siguen a la palabra clave NEWTYPE deben especificarse explícitamente.

Un carácter de control tiene el mismo significado que un espacio.

Los caracteres de control y espacios pueden aparecer cualquier número de veces entre dos &lab;unidad léxica>s. Cualquier número de caracteres de control y espacio entre dos &lab;unidad léxica>s tiene el mismo significado que un espacio.

El carácter / seguido inmediatamente del carácter * siempre comienza una &lab;nota>. El carácter * seguido inmediatamente por el carácter / en una &lab;nota> siempre termina la &lab;nota>. Una &lab;nota> puede insertarse antes o después de cualquier &lab;unidad léxica>.

Dentro de un &lab;cuerpo de macro> se aplican reglas léxicas especiales (véase 4.2.1 ).

Gramática abstracta

Identificador :: Nombre de calificador Calificador = Ítem-de-trayecto + Ítem-de-trayecto = Calificador-de-sistema | Calificador-de-bloque | Calificador-de-subestructura-de-bloque | Calificador-de-señal | Calificador-de-proceso | Calificador-de-procedimiento | Calificador-de-género |

Calificador-de-sistema :: Nombre-de-sistema

Calificador-de-bloque :: Nombre-de-bloque Calificador-de-subestructura-de-bloque :: Nombre-de-subestructura-de-bloque Calificador-de-proceso :: Nombre-de-proceso Calificador-de-procedimiento :: Nombre-de-procedimiento Calificador-de-señal :: Nombre-de-señal Calificador-de-género :: Nombre-de-género Nombre :: Testigo

Gramática textual concreta

&lab;identificador> ::= [&lab;calificador>] &lab;nombre>

&lab;calificador> ::= &lab;ítem de trayecto> {/<ítem de trayecto>}*

&lab;ítem de trayecto> ::= &lab;clase de unidad de ámbito> &lab;nombre>

&lab;clase de unidad de ámbito> ::= SYSTEM | BLOCK | SUBSTRUCTURE | SIGNAL | PROCESS | PROCEDURE | TYPE | SERVICE

No hay sintaxis abstracta correspondiente para la &lab;clase de unidad de ámbito> denotada por servicio. Los &lab;nombre>s e &lab;identificador>s de entidades definidos en una &lab;definición de servicio> son transformados en &lab;nombre>s respectivamente &lab;identificador>s únicos definidos en la &lab;definición de proceso> que contiene la &lab;definición de servicio>.

El &lab;calificador> refleja la estructura jerárquica desde el nivel de sistema hasta el contexto definidor, y de tal modo que el nivel de sistema es la parte textual más a la izquierda.

Se permite omitir algunos de los <ítem de trayecto>s más a la izquierda (excepto para &lab;definición remota>s, véase 2.4.1 ), o todo el &lab;calificador>. Cuando se omite todo el &lab;calificador> y el &lab;nombre> denota una entidad de la clase de entidad que contiene variables, sinónimos, literales y operadores (véase Semántica ^ más adelante), la vinculación del &lab;nombre> a una definición debe poder ser resuelta por el contexto efectivo. En otros casos el &lab;identificador> está vinculado a una entidad que tiene su contexto de definición en la unidad de ámbito circundante más cercana en que el &lab;calificador> del &lab;identificador> es el mismo que la parte más a la derecha del &lab;calificador> completo que denota esa unidad de ámbito. Si el &lab;identificador> no contiene un &lab;calificador>, se omite el requisito de concordancia de los &lab;calificador>s.

Una subseñal tiene que estar calificada por su señal progenitora a menos que no exista otra señal visible en ese lugar que tenga el mismo &lab;nombre>.

La resolución por el contexto es posible en los casos siguientes:

a) La unidad de ámbito en que se utiliza el &lab;nombre> no es una &lab;definición parcial de tipo> y contiene una definición que tiene ese &lab;nombre>. El &lab;nombre> estará vinculado a esa definición.

b) La unidad de ámbito en la cual se utiliza el &lab;nombre> no contiene ninguna definición que tenga ese &lab;nombre> o la unidad de ámbito es una &lab;definición parcial de tipo>, y en la totalidad de la &lab;definición de sistema> existe exactamente una definición visible de una entidad que tiene el mismo &lab;nombre> y a la cual se puede vincular el &lab;nombre> sin violar ninguna de las propiedades estáticas (compatibilidad de géneros, etc.) de la construcción en la que ocurre el &lab;nombre>. El &lab;nombre> estará vinculado a esa definición.

Sólo podrán utilizarse identificadores visibles, excepto el &lab;identificador de variable> en una &lab;definición de visión> y el &lab;identificador> utilizado en lugar de un &lab;nombre> en una definición referenciada (es decir, una definición tomada de la &lab;definición de sistema>).

Semántica

Las unidades de ámbito se definen por el siguiente esquema:

Gramática textual concreta Gramática gráfica concreta

&lab;definición de sistema> &lab;diagrama de sistema>

&lab;definición de bloque> &lab;diagrama de bloque>

&lab;definición de proceso> &lab;diagrama de proceso>

&lab;definición de procedimiento> &lab;diagrama de procedimiento>

&lab;definición de subestructura de bloque> &lab;diagrama de subestructura de bloque>

&lab;definición de subestructura de canal> &lab;diagrama de subestructura de canal>

&lab;definición de servicio> &lab;diagrama de servicio>

&lab;definición parcial de tipo>

&lab;refinamiento de señal>

Una unidad de ámbito tiene asociada una lista de definiciones. Cada una de las definiciones define una entidad que pertenece a cierta clase de entidad y tiene un nombre asociado. Para una &lab;definición parcial de tipo>, la lista asociada de definiciones consiste en las &lab;signatura de operador>s, las &lab;signatura de literal>s y cualesquiera &lab;signatura de operador>s y &lab;signatura de literal>s heredadas de un género progenitor, de una instancia de generador, o implicada por el uso de notaciones taquigráficas tales como la palabra clave ORDERING (véase 5.4.1.8 ). Obsérvese que una &lab;definición de visión> no define una entidad.

Aunque los &lab;operador infijo>s, &lab;operador>s con signo de admiración y &lab;cadena de caracteres>s tienen su notación sintáctica propia, son en efecto &lab;nombre>s, y se representan en sintaxis abstracta por un nombre . En lo sucesivo se tratarán como si fuesen (también sintácticamente) &lab;nombre>s. Sin embargo, los &lab;nombre de estado >s, &lab;nombre de conector >s, &lab;nombre formal de generador >s, &lab;identificador de valor >s en ecuaciones, &lab;nombre formal de macro >s y &lab;nombre de macro >s tienen reglas de visibilidad especiales y por lo tanto no pueden ser calificados. Los &lab;nombre de estado >s y &lab;nombre de conector >s no son visibles fuera de un &lab;cuerpo de proceso>, &lab;cuerpo de procedimiento> o &lab;cuerpo de servicio> respectivamente. En las secciones apropiadas se explican otras reglas de visibilidad.

Se dice que cada entidad tiene su contexto definidor en la unidad de ámbito que la define. Las entidades son referenciadas por medio de &lab;identificador>s.

El &lab;calificador> dentro de un &lab;identificador> especifica unívocamente el contexto definidor del &lab;nombre>.

Existen las siguientes clases de entidades:

a) sistema b) bloques c) canales, rutas de señales d) señales, temporizadores e) procesos f) procedimientos g) variables (incluidos parámetros formales), sinónimos, literales, operadores h) géneros i) generadores j) entidades importadas k) listas de señales l) servicios m) subestructuras de bloque, subestructuras de canal

Se dice que un identificador es visible en una unidad de ámbito

a) si la parte nombre del &lab;identificador> tiene su contexto definidor en esa unidad de ámbito, o b) si es visible en la unidad de ámbito que definió esa unidad de ámbito, o c) si la unidad de ámbito contiene una &lab;definición parcial de tipo> en la que se define el &lab;identificador>, o d) si la unidad de ámbito contiene una &lab;definición de señal> en la que se define el &lab;identificador>.

Dos definiciones en la misma unidad de ámbito y pertenecientes a la misma clase de entidad no pueden tener el mismo &lab;nombre>. Una excepción la constituyen las definiciones de &lab;signatura de operador> y &lab;signatura de literal> en la misma &lab;definición parcial de tipo> (véase 5.2.2 ): dos o más operadores y/o literales pueden tener el mismo &lab;nombre> con diferentes &lab;género de argumento>s o diferente género &lab;resultado>.

Otra excepción la constituyen las entidades importadas. Para esta clase de entidad los pares de (&lab;nombre de importación>, &lab;género>) en las &lab;definición de importación>s en la unidad de ámbito tienen que ser distintos.

En la gramática textual concreta, el nombre o identificador opcional en una definición después de la palabra clave de terminación (ENDSYSTEM, ENDBLOCK, etc.) debe ser sintácticamente el mismo que el nombre o identificador que sigue a la correspondiente palabra clave de comienzo (SYSTEM, BLOCK, etc., respectivamente).

Gramática abstracta

Texto-informal :: ...

Gramática textual concreta

&lab;texto informal> ::= &lab;cadena de caracteres>

Semántica

Si se utiliza texto informal en una especificación de sistema LED, debe tenerse presente que este texto no es LED formal, es decir, LED no le da ninguna semántica. La semántica del texto informal puede definirse por otros medios.

El usuario podrá elegir el tamaño de los símbolos gráficos.

Los símbolos no deben superponerse ni cruzarse unos con otros. Una excepción a esta regla la constituyen los símbolos formados por líneas, por ejemplo &lab;símbolo de canal>, &lab;símbolo de ruta de señales>, &lab;símbolo de línea de crear>, &lab;símbolo de línea de flujo>, &lab;símbolo de asociación de trazo continuo> y &lab;símbolo de asociación de trazo discontinuo>, que pueden cruzarse unos con otros. El cruce de un símbolo con otro no conlleva una asociación lógica.

El metasímbolo is followed by implica un &lab;símbolo de línea de flujo>.

Los símbolos formados por líneas pueden consistir en uno o más segmentos de recta.

Un &lab;símbolo de línea de flujo> debe tener una flecha cuando entra en otro &lab;símbolo de línea de flujo>, en un &lab;símbolo de conector de salida> o en un &lab;símbolo de estado siguiente>. En otros casos, las flechas son opcionales en los &lab;símbolo de línea de flujo>s. Los &lab;símbolo de línea de flujo>s son horizontales o verticales.

Se permiten imágenes especulares verticales de &lab;símbolo de entrada>, &lab;símbolo de salida>, &lab;símbolo de comentario> y &lab;símbolo de ampliación de texto>.

El argumento de la derecha del metasímbolo is associated with debe estar más cerca del argumento de la izquierda que de cualquier otro símbolo gráfico. Los elementos sintácticos del argumento de la derecha deben distinguirse unos de otros.

El texto dentro de un símbolo gráfico debe leerse de izquierda a derecha, comenzando por la esquina superior izquierda. El borde derecho del símbolo se interpreta como un carácter de nueva línea, indicativo de que la lectura debe continuar en el punto situado más a la izquierda de la línea siguiente (si existe).

La siguiente definición de partición de diagrama no forma parte de la gramática gráfica concreta , pero se utiliza el mismo metalenguaje.

&lab;página> ::= &lab;símbolo de casilla> contains {<área de encabezamiento> <área de número de página> {&lab;unidad sintáctica>} *}

&lab;área de encabezamiento> ::= &lab;símbolo de texto implícito> contains &lab;encabezamiento>

&lab;área de número de página> ::= &lab;símbolo de texto implícito> contains [&lab;número de página> [(&lab;número de páginas>)]]

&lab;número de página> ::= &lab;nombre de literal >

&lab;número de páginas> ::=

&lab;nombre de literal natural >

La &lab;página> es un no terminal de comienzo, por lo cual no se hace referencia al mismo en ninguna regla de producción. Un diagrama puede dividirse (particionarse) en varias &lab;página>s, en cuyo caso el &lab;símbolo de casilla> que delimita el diagrama y el &lab;encabezamiento> del diagrama se reemplazan por un &lab;símbolo de casilla> y un &lab;encabezamiento> para cada &lab;página>.

El usuario de LED puede decidir que el límite del medio en el que se reproducen los diagramas implique los &lab;símbolo de casilla>s.

El &lab;símbolo de texto implícito> no se muestra, pero está implícito para obtener una clara separación entre <área de encabezamiento> y &lab;área de número de página>. El <área de encabezamiento> se sitúa en la esquina superior izquierda del &lab;símbolo de casilla>. El <área de número de página> se coloca en la esquina superior derecha del &lab;símbolo de casilla>. El &lab;encabezamiento> y la &lab;unidad sintáctica> dependen del tipo de diagrama.

Un comentario es una notación para representar comentarios asociados con símbolos o texto.

En la gramática textual concreta se utilizan dos formas de comentarios. La primera es la &lab;nota>, definida en 2.2.1 .

En la figura 2.9.1 y en la figura 2.9.3 se muestran ejemplos.

La sintaxis concreta de la segunda forma es:

&lab;fin> ::= [&lab;comentario>];

&lab;comentario> ::= COMMENT &lab;cadena de caracteres>

En la figura 2.9.2 se muestra un ejemplo.

En la gramática gráfica concreta se utiliza la sintaxis siguiente:

&lab;área de comentario> ::= &lab;símbolo de comentario> contains &lab;texto> is connected to &lab;símbolo de asociación de trazo discontinuo>

&lab;símbolo de comentario> ::=

Figure omitted: 05 Figura Figura, p. &lab;símbolo de asociación de trazo discontinuo> ::=

------------

Un extremo del &lab;símbolo de asociación de trazo discontinuo> debe estar conectado al centro del segmento vertical del &lab;símbolo de comentario>.

Un &lab;símbolo de comentario> puede conectarse a cualquier símbolo gráfico por medio de un &lab;símbolo de asociación de trazo discontinuo>. El &lab;símbolo de comentario> se considera un símbolo cerrado completando (en la imaginación) el rectángulo para encerrar el texto. Contiene texto de comentario relacionado con el símbolo gráfico.

En la figura 2.9.4, en 2.9 , se muestra un ejemplo.

&lab;área de ampliación de texto> ::= &lab;símbolo de ampliación de texto> contains &lab;texto> is connected to &lab;símbolo de asociación de trazo continuo>

&lab;símbolo de ampliación de texto> ::= &lab;símbolo de comentario>

&lab;símbolo de asociación de trazo continuo> ::=

Un extremo del &lab;símbolo de asociación de trazo continuo> tiene que estar conectado con el centro del segmento vertical del &lab;símbolo de ampliación de texto>.

Un &lab;símbolo de ampliación de texto> puede conectarse con cualquier símbolo gráfico por medio de un &lab;símbolo de asociación de trazo continuo>. El &lab;símbolo de ampliación de texto> se considera un símbolo cerrado completando (en la imaginación) el rectángulo.

El texto contenido en el &lab;símbolo de ampliación de texto> es una continuación del texto dentro del símbolo gráfico y se considera contenido en ese símbolo.

&lab;símbolo de texto> se utiliza en cualquier diagrama. El contenido depende del diagrama.

&lab;símbolo de texto> ::=

Figure omitted: 05 Figura Figura, p.

Los datos en LED están principalmente relacionados con los tipos de datos. Un tipo de datos define conjuntos de valores, un conjunto de operadores que puede aplicarse a estos valores y un conjunto de reglas algebraicas (ecuaciones) que definen el comportamiento de estos operadores cuando son aplicados a los valores. Los valores, los operadores y las reglas algebraicas definen colectivamente las propiedades del tipo de datos. Estas propiedades son definidas por definiciones de tipo de datos.

LED permite la definición de cualquier tipo de datos que se necesite, incluidos mecanismos de composición (tipos compuestos), con la sola condición de que tal definición pueda especificarse formalmente. En cambio, a los efectos de lenguajes de programación hay consideraciones de implementación que requieren que el conjunto de tipos de datos disponible y, en particular, el mecanismo de composición proporcionado (matriz, estructura, etc.), estén limitados.

Variables son objetos a los cuales puede asociarse un valor por asignación. Cuando se accede a la variable, se obtiene el valor asociado.

Un conjunto de valores con ciertas características se denomina un género. Los operadores se definen para que actúen desde y hacia valores de géneros. Por ejemplo, la aplicación del operador de suma ( `+' ) desde y hacia valores del género entero es válida, en tanto que la suma de valores del género booleano no lo es.

Todos los géneros tienen por lo menos un valor. Todo valor pertenece a un género, y solamente a uno; es decir, los géneros no pueden tener valores en común.

La mayor parte de los géneros tienen formas literales para denotar valores del género (por ejemplo, para enteros se utiliza `2' más bien que `1 + 1' . Puede haber más de un literal para denotar el mismo valor (por ejemplo 12 y 012 pueden utilizarse para denotar el mismo valor entero). La misma denotación literal puede utilizarse para más de un género; por ejemplo 'A' es un carácter, pero es también una cadena de caracteres de longitud 1. Algunos géneros pueden no tener literales; por ejemplo, un valor compuesto a menudo no tiene literales propios pero sí valores definidos por operaciones de composición sobre valores de sus componentes.

Una expresión denota un valor. Si una expresión no contiene una variable, por ejemplo si es un literal de un género dado, toda ocurrencia de la expresión denotará siempre el mismo valor. Una expresión que contiene variables puede interpretarse como valores diferentes durante la interpretación de un sistema LED según el valor asociado a las variables.

Una &lab;definición remota> es una definición que ha sido sacada de su contexto definidor para obtener una mejor sinopsis. Es similar a una definición de macro (véase 4.2 ), pero es `llamada' únicamente desde un solo lugar (el contexto definidor) utilizando una referencia.

Gramática concreta

&lab;definición remota> ::= &lab;definición> | &lab;diagrama>

&lab;definición de sistema> ::= {&lab;definición textual de sistema> | &lab;diagrama de sistema>} {&lab;definición remota>}*

&lab;definición> ::= &lab;definición de bloque> | &lab;definición de proceso> | &lab;definición de procedimiento> | &lab;definición de subestructura de bloque> | &lab;definición de subestructura de canal> | &lab;definición de servicio> | &lab;definición de macro>

&lab;diagrama> ::= &lab;diagrama de bloque> | &lab;diagrama de proceso> | &lab;diagrama de procedimiento> | &lab;diagrama de subestructura de bloque> | &lab;diagrama de subestructura de canal> | &lab;diagrama de servicio> | &lab;diagrama de macro>

Para cada &lab;definición remota>, excepto &lab;definición de macro> y &lab;diagrama de macro>, tiene que haber una referencia en la &lab;definición de sistema>, el &lab;diagrama de sistema>, u otra &lab;definición remota>.

Para cada referencia tiene que haber una &lab;definición remota> correspondiente.

En cada &lab;definición remota> tiene que haber un &lab;identificador> inmediatamente después de la palabra clave inicial. El &lab;calificador> en este &lab;identificador> debe estar completo, o debe omitirse. Si se omite el calificador, el nombre tiene que ser único en la definición de sistema, dentro de la clase de entidad de la &lab;definición remota>. No está permitido especificar un &lab;calificador> en el &lab;identificador> después de la palabra clave inicial para definiciones que no son &lab;definición remota>s (es decir, un &lab;nombre> tiene que estar especificado para definiciones normales).

Semántica

Antes de que pueda analizarse una &lab;definición de sistema concreto>, hay que sustituir cada referencia por la &lab;definición remota> correspondiente. En esta sustitución, el &lab;identificador> de la &lab;definición remota> se sustituye por el &lab;nombre> en la referencia.

file.header.2

Gramática abstracta

Definición-de-sistema :: Nombre-de-sistema Definición-de-bloque - set Definición-de-canal - set Definición-de-señal - set Definición-de-tipo-de-datos Definición-de-tipo-de-sinónimo - set Nombre-de-sistema = Nombre

Una definición-de-sistema tiene un nombre que puede utilizarse en calificadores.

Una definición-de-sistema debe contener por lo menos una definición-de-bloque .

Las definiciones de todos los canales, señales, tipos de datos, sintipos utilizados en el interfaz con el entorno y entre bloques del sistema están contenidas en la definición-de-sistema . Todos los datos predefinidos se consideran definidos a nivel de sistema.

Gramática textual concreta

&lab;definición textual de sistema> ::= SYSTEM &lab;nombre de sistema > &lab;fin> {&lab;definición de bloque | &lab;referencia textual de bloque> | &lab;definición de canal> | &lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de seleccionar> | &lab;definición de macro> | &lab;definición de datos>^}^+ ENDSYSTEM [&lab;nombre de sistema >] &lab;fin>

&lab;referencia textual de bloque> ::= BLOCK &lab;nombre de bloque > REFERENCED &lab;fin>

&lab;definición de seleccionar> se define en 4.3.3 , &lab;definición de macro> en 4.2 , &lab;definición de datos> en 5.5.1 , &lab;definición de bloque> en 2.4.3 , &lab;definición de canal> en 2.5.1 , &lab;definición de señal> en 2.5.4 , &lab;definición de lista de señales> en 2.5.5 .

Un ejemplo de &lab;definición de sistema> se muestra en la figura 2.9.5, en 2.9 .

Gramática gráfica concreta

&lab;diagrama de sistema> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de sistema> { {<área de texto de sistema>}^* {&lab;diagrama de macro>}* {<área de interacción de bloques>}^ set }

&lab;símbolo de casilla> ::= Figure omitted: 04 Figura 6 Figura 6, p. &lab;encabezamiento de sistema> ::= SYSTEM &lab;nombre de sistema >

&lab;área de texto de sistema> ::= &lab;símbolo de texto> contains {&lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de datos> | &lab;definición de macro> | &lab;definición de seleccionar>}^*

&lab;área de interacción de bloque> ::= {<área de bloque> | <área de definición de canal>}+

&lab;área de bloque> ::= &lab;referencia gráfica de bloque> | &lab;diagrama de bloque>

&lab;referencia gráfica de bloque> ::= &lab;símbolo de bloque> contains &lab;nombre de bloque >

&lab;símbolo de bloque> ::= Figure omitted: 04 Figura 7 Figura 7, p. &lab;definición de seleccionar> se define en 4.3.3 , &lab;definición de macro> y &lab;diagrama de macro> en 4.2 , &lab;definición de datos> en 5.5.1 , &lab;diagrama de bloque> en 2.4.3 , <área de definición de canal> en 2.5.1 , &lab;definición de señal> en 2.5.4 , &lab;definición de lista de señales> en 2.5.5 .

Definición-de-bloque - set en la gramática abstracta corresponde a las <área de bloque>s, definición-de-canal- set corresponde al <área de definición de canal>.

En la figura 2.9.6 se muestra un ejemplo de un &lab;diagrama de sistema>.

Semántica

Una definición-de-sistema es la representación LED de una especificación o descripción de un sistema.

Un sistema está separado de su entorno por la frontera del sistema y contiene un conjunto de bloques. La comunicación entre el sistema y el entorno o entre bloques dentro del sistema sólo puede efectuarse mediante señales. Dentro de un sistema, estas señales son transportadas por canales. Los canales conectan bloques entre sí o con la frontera del sistema.

Antes de interpretar una definición-de-sistema se elige un subconjunto consistente (véase 3.2.1 ). Este subconjunto se denomina una instancia de la definición-de-sistema . Una instancia de un sistema es una instanciación de un tipo de sistema definido por una definición-de-sistema . La interpretación de una instancia de una definición-de-sistema es efectuada por una máquina LED abstracta que, al hacerlo, da semántica a los conceptos LED. Interpretar una instancia de una definición-de-sistema es:

a) iniciar el tiempo del sistema, b) interpretar los bloques y sus canales conectados que están contenidos en el subconjunto de partición consistente seleccionado.

Gramática abstracta

Definición-de-bloque :: Nombre-de-bloque Definición-de-proceso - set Definición-de-señal - set Conexión-de-canal-a-ruta - set Definición-de-ruta-de-señales - set Definición-de-tipo-de-datos Definición-de-tipo-de-sinónimo - set [ Definición-de-subestructura-de-bloque ] Nombre-de-bloque = Nombre

A menos que una definición-de-bloque contenga una definición-de-subestructura-de-bloque , debe haber por lo menos una definición-de-proceso y una definición-de-ruta-de-señales dentro del bloque.

Es posible efectuar actividades de partición sobre los bloques que especifican definición-de-subestructura-de-bloque ; esta característica del lenguaje se trata en 3.2.2 .

Gramática textual concreta

&lab;definición de bloque> ::=

BLOCK {&lab;nombre de bloque >|&lab;identificador de bloque >}&lab;fin> {&lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de proceso> | &lab;referencia textual de proceso> | &lab;definición de ruta de señales> | &lab;definición de macro> | &lab;definición de datos> | &lab;definición de seleccionar> | &lab;conexión de canal a ruta>}* [&lab;definición de subestructura de bloque>|&lab;referencia textual de subestructura de bloque>] ENDBLOCK [&lab;nombre de bloque >|&lab;identificador de bloque >] &lab;fin>

&lab;referencia textual de proceso> ::= PROCESS &lab;nombre de proceso >[&lab;número de instancias>] REFERENCED &lab;fin>

&lab;definición de señal> se define en 2.5.4 , &lab;definición de lista de señales> en 2.5.5 , &lab;definición de proceso> en 2.4.4 , &lab;definición de ruta de señales> en 2.5.2 , &lab;conexión de canal a ruta> en 2.5.3 , &lab;definición de subestructura de bloque> y &lab;referencia textual de subestructura de bloque> se definen en 3.2.2 , &lab;definición de macro> en 4.2.2 y &lab;definición de datos> en 5.5.1 .

En la figura 2.9.7, en 2.9 , se muestra un ejemplo de &lab;definición de bloque>.

Gramática gráfica concreta

&lab;diagrama de bloque> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de bloque> { {<área de texto de bloque>}*{&lab;diagrama de macro>}* [<área de interacción de procesos>] [<área de subestructura de bloque>]}^ set ^} is associated with {&lab;identificador de canal >}*

El &lab;identificador de canal > identifica un canal conectado a una ruta de señales en el &lab;diagrama de bloque>. Se coloca fuera del &lab;símbolo de casilla>, próximo al punto extremo de la ruta de señales en el &lab;símbolo de casilla>. Si el &lab;diagrama de bloque> no contiene un <área de interacción de procesos>, deberá contener un <área de subestructura de bloque>.

&lab;encabezamiento de bloque> ::= BLOCK {&lab;nombre de bloque >|&lab;identificador de bloque >}

&lab;área de texto de bloque> ::= &lab;área de texto de sistema>

&lab;área de interacción de procesos> ::= {<área de proceso> | <área de línea de crear> | <área de definición de ruta de señales>}+

&lab;área de proceso> ::= &lab;referencia gráfica de proceso>|&lab;diagrama de proceso>

&lab;referencia gráfica de proceso> ::= &lab;símbolo de proceso> contains &lab;nombre de proceso >[&lab;número de instancias>]^}

&lab;símbolo de proceso> ::= Figure omitted: 03 Figura 8 Figura 8, p. &lab;número de instancias> se define en 2.4.4 .

&lab;área de línea de crear> ::= &lab;símbolo de línea de crear> is connected to {<área de proceso> <área de proceso>}

&lab;símbolo de línea de crear> ::=

--------------

La punta de flecha en el &lab;símbolo de línea de crear> indica el &lab;área de proceso> sobre la cual se ejecuta la acción de crear.

&lab;diagrama de proceso> se define en 2.4.4 , <área de definición de ruta de señales> en 2.5.2 , <área de subestructura de bloque> en 3.2.2 , &lab;diagrama de macro> en 4.2.2 .

En la figura 2.9.8, en 2.9 , se muestra un ejemplo de &lab;diagrama de bloque>.

Semántica

Una definición de bloque es un contenedor para una o más definiciones de proceso de un sistema y/o una subestructura de bloque. La definición de bloque tiene por finalidad agrupar procesos que, como un todo, realizan cierta función, sea directamente, sea mediante una subestructura de bloque.

Una definición de bloque proporciona un interfaz de comunicación estático en virtud del cual sus procesos pueden comunicar con otros procesos. Además, establece el ámbito para definiciones de proceso.

Interpretar un bloque es crear los procesos iniciales en el bloque.

Gramática abstracta

Definición-de-proceso :: Nombre-de-proceso Número-de-instancias Parámetro-formal-de-proceso ^* Definición-de-procedimiento- set Definición-de-señal - set Definición-de-tipo-de-datos Definición-de-tipo-de-sinónimo - set Definición-de-variable- set Definición-de-visión- set Definición-de-temporizador- set Gráfico-de-proceso

Número-de-instancias :: Ento Ento

Nombre-de-proceso = Nombre

Gráfico-de-proceso :: Nodo-de-arranque-de-proceso Nodo-de-estado- set

Parámetro-formal-de-proceso :: Nombre-de-variable Identificador-de-referencia-de-género

Gramática textual concreta

&lab;definición de proceso> ::= PROCESS {&lab;identificador de proceso >|&lab;nombre de proceso >} [&lab;número de instancias>] &lab;fin> [&lab;parámetros formales> &lab;fin>] [&lab;conjunto de señales de entrada válidas>] {&lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de procedimiento> | &lab;referencia textual de procedimiento> | &lab;definición de macro> | &lab;definición de datos> | &lab;definición de variable> | &lab;definición de visión> | &lab;definición de seleccionar> | &lab;definición de importación> | &lab;definición de temporizador>}^* {&lab;cuerpo de proceso> | &lab;descomposición de servicio>} ENDPROCESS [&lab;nombre de proceso >|&lab;identificador de proceso >] &lab;fin>

&lab;referencia textual de procedimiento> ::= PROCEDURE &lab;nombre de procedimiento > REFERENCED &lab;fin>

&lab;conjunto de señales de entrada válidas> ::= SIGNALSET [&lab;lista de señales>] &lab;fin>

&lab;cuerpo de proceso> ::= &lab;arranque>{&lab;estado>}^*

&lab;parámetros formales> ::= FPAR &lab;nombre de variable >{,&lab;nombre de variable >}^*&lab;género> {,&lab;nombre de variable >{,&lab;nombre de variable >}*&lab;género>}*

&lab;número de instancias> ::= ([&lab;número inicial>], [&lab;número máximo>])

&lab;número inicial> ::= &lab;expresión simple natural >

&lab;número máximo> ::= &lab;expresión simple natural >

El número inicial de instancias y el número máximo de instancias contenidos en número-de-instancias se derivan de &lab;número de instancias>. Si &lab;número inicial> se omite, el &lab;número inicial> es 1. Si &lab;número máximo> se omite, entonces el &lab;número máximo> no está acotado.

El &lab;número de instancias> utilizado en la derivación es el siguiente:

a) Si no hay &lab;referencia textual de proceso> para el proceso, se utiliza el &lab;número de instancias> en la &lab;definición de proceso>. Si no contiene un &lab;número de instancias>, se utiliza el &lab;número de instancias> en que se omiten el &lab;número inicial> y el &lab;número máximo>.

b) Si se omite el &lab;número de instancias> en la &lab;definición de proceso> y en una &lab;referencia textual de proceso>, se utiliza el &lab;número de instancias> en que se omiten el &lab;número inicial> y el &lab;número máximo>.

c) Si se omite el &lab;número de instancias> en la &lab;definición de proceso> o en una &lab;referencia textual de proceso>, el &lab;número de instancias> es el que está presente.

d) Si se especifica el &lab;número de instancias> en la &lab;definición de proceso> y en una &lab;referencia textual de proceso>, los dos &lab;número de instancias> deben ser léxicamente iguales, y se utiliza ese &lab;número de instancias>.

Se aplica una relación similar para el &lab;número de instancias> especificado en el &lab;diagrama de proceso> y en la &lab;referencia gráfica de proceso>, como se define a continuación.

&lab;definición de señal> se define en 2.5.4 , &lab;definición de lista de señales> en 2.5.5 , &lab;definición de visión> en 2.6.1.2 , &lab;definición de variable> en 2.6.1.1 , &lab;definición de procedimiento> en 2.4.5 , &lab;definición de temporizador> en 2.8 , &lab;definición de macro> en 4.2.2 , &lab;definición de importación> en 4.1.3 , &lab;definición de seleccionar> en 4.3.3 , &lab;expresión simple> en 4.3.2 , &lab;descomposición de servicio> en 4.10.1 , &lab;definición de datos> en 5.5.1 .

El &lab;número inicial> de instancias tiene que ser inferior o igual al &lab;número máximo> y el &lab;número máximo> tiene que ser mayor que cero.

La utilización de &lab;conjunto de señales de entrada válidas> se define en 2.5.2 , modelo .

Un ejemplo de &lab;definición de proceso> se muestra en la figura 2.9.9, en 2.9 .

Gramática gráfica concreta

&lab;diagrama de proceso> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de proceso> {^{<área de texto de proceso>}* {<área de procedimiento>}* {&lab;diagrama de macro>}* {<área de gráfico de proceso>|<área de interacción de servicios>}^} set ^} [ is associated with {&lab;identificador ruta de señales >}+]

El &lab;identificador de ruta de señales > identifica una ruta externa de señales conectada a una ruta de señales en el &lab;diagrama de proceso>. Se coloca fuera del &lab;símbolo de casilla>, próximo al punto extremo de la ruta de señales en el &lab;símbolo de casilla>.

&lab;área de texto de proceso> ::= &lab;símbolo de texto> contains { [&lab;conjunto de señales de entrada válidas>] {&lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de variable> | &lab;definición de visión> | &lab;definición de importación> | &lab;definición de datos> | &lab;definición de macro> | &lab;definición de temporizador> | &lab;definición de seleccionar>^}*}

&lab;encabezamiento de proceso> ::= PROCESS {&lab;nombre de proceso >|&lab;identificador de proceso >} [&lab;número de instancias> [&lab;fin>] ] [&lab;parámetros formales>]

&lab;área de gráfico de proceso> ::= &lab;área de arranque>{<área de estado>|<área de conector de entrada> }*

&lab;definición de señal> se define en 2.5.4 , &lab;definición de lista de señales> en 2.5.5 , &lab;definición de visión> en 2.6.1.2 , &lab;definición de variable> en 2.6.1.1 , &lab;área de procedimiento> en 2.4.5 , &lab;definición de temporizador> en 2.8 , &lab;definición de macro> y &lab;diagrama de macro> en 4.2.2 , &lab;definición de importación> en 4.1.3 , &lab;definición de seleccionar> en 4.3.3 , &lab;definición de datos> en 5.5.1 , <área de arranque> en 2.6.2 , <área de estado> en 2.6.3 , <área de conector de entrada> en 2.6.6 y <área de interacción de servicios> en 4.10.1 .

Un ejemplo de &lab;diagrama de proceso> se muestra en la figura 2.9.10, en 2.9 .

Semántica

Una definición de proceso introduce el tipo de un proceso con que se desea representar un comportamiento dinámico.

En el número-de-instancias , el primer valor representa el número-de-instancias del proceso que existe cuando se crea el sistema, y el segundo valor representa el número máximo de instancias simultáneas del tipo de proceso.

Una instancia de proceso es una máquina de estados finitos ampliada, que comunica, y que realiza cierto conjunto de acciones, denominadas como transiciones, en función de la recepción de una señal determinada, cuando se encuentra en un estado. Después de efectuada una transición, el proceso se encontrará en espera en otro estado, que no tiene que ser necesariamente diferente del precedente.

El concepto de máquina de estados finitos se ha ampliado en el sentido de que el estado resultante después de una transición puede ser afectado, no sólo por la señal que causa la transición, sino también por decisiones tomadas sobre variables conocidas por el proceso.

Varias instancias del mismo tipo de proceso pueden existir al mismo tiempo y actuar asíncronamente y en paralelo, entre sí y con otras instancias de un tipo de proceso diferente en el sistema.

Cuando se crea un sistema, los procesos iniciales se crean en un orden aleatorio. La comunicación de señales entre los procesos sólo comienza después de que se hayan creado todos los procesos iniciales. Los parámetros formales de estos procesos iniciales se inicializan a un valor indefinido.

Las instancias de proceso existen desde el instante en que un sistema es creado o puede ser creado por acciones de petición de crear que arrancan los procesos que se están interpretando; la interpretación comienza cuando se interpreta la acción de arrancar; las instancias de proceso pueden dejar de existir ejecutando acciones de parada.

Las señales recibidas por instancias de proceso se denominan señales de entrada, y las señales enviadas a instancias de proceso se denominan señales de salida.

Las señales sólo pueden ser consumidas por una instancia de proceso cuando ésta se encuentra en un estado. El conjunto completo de señales de entrada válidas es la unión del conjunto de señales en todas las rutas de señales que conducen al proceso, el &lab;conjunto de señales de entrada válidas>, las señales implícitas y las señales de temporizador.

Un puerto de entrada, y sólo uno, está asociado a cada instancia de proceso. Cuando una señal de entrada llega al proceso, se aplica al puerto de entrada de la instancia de proceso.

El proceso está, bien en espera en un estado, bien efectuando una transición. Para cada estado hay un conjunto de señales de conservación (véase también 2.6.5 ). Cuando el proceso se encuentra en espera en un estado, la primera señal de entrada cuyo identificador no forme parte del conjunto de señales de conservación es extraída de la cola y consumida por el proceso.

El puerto de entrada puede retener cualquier número de señales de entrada, de modo que varias señales de entrada formen cola para la instancia de proceso. El conjunto de señales retenidas son ordenadas en la cola según el instante de llegada. Si dos o más señales llegan `simultáneamente' por trayectos diferentes, se ordenan arbitrariamente.

Cuando se crea el proceso, se le da un puerto de entrada vacío, y se crean variables locales a las cuales se asignan valores.

Los parámetros formales son variables creadas, bien cuando el sistema es creado (pero no se le han pasado parámetros efectivos, por lo cual aún no están inicializados), bien cuando la instancia del proceso es creada dinámicamente.

Para todas las instancias de proceso pueden utilizarse cuatro expresiones que dan un valor de PId (véase 5.6.10 ): SELF, PARENT, OFFSPRING y SENDER. Estas expresiones dan un resultado para:

a) la instancia de proceso (SELF);

b) la instancia del proceso creador (PARENT);

c) la última instancia de proceso creada por el proceso (OFFSPRING);

d) la instancia de proceso a partir de la cual se ha consumido la última señal de entrada (SENDER) (véase también 2.6.4 ).

Estas expresiones se explican con más detalle en 5.5.4.3 .

SELF (MISMO), PARENT (PROGENITOR), OFFSPRING (VÁSTAGO) y SENDER (EMISOR) pueden utilizarse en expresiones dentro de las instancias de proceso.

Para todas las instancias de proceso presentes en la inicialización del sistema, la expresión predefinida PARENT siempre tiene el valor NULL.

Para todas las instancias de proceso de nueva creación, las expresiones predefinidas SENDER y OFFSPRING tienen el valor NULL.

Los procedimientos se definen por medio de definiciones de procedimiento. El procedimiento es invocado mediante una llamada a procedimiento que hace referencia a la definición de procedimiento. Una llamada a procedimiento tiene asociados parámetros; éstos se utilizan para pasar valores y también para controlar el ámbito de las variables para la ejecución del procedimiento. El mecanismo de paso de los parámetros controla qué variables son afectadas por la interpretación de un procedimiento.

Gramática abstracta

Definición-de-procedimiento :: Nombre-de-procedimiento Parámetro-formal-de-procedimiento ^* Definición-de-procedimiento - set Definición-de-tipo-de-datos Definición-de-tipo-de-sinónimo - set Definición-de-variable - set Gráfico-de-procedimiento

Nombre-de-procedimiento = Nombre

Parámetro-formal-de-procedimiento = Parámetro-de-entrada ^| Parámetro-de-entrada-salida

Parámetro-de-entrada :: Nombre-de-variable Identificador-de-referencia-de-género

Parámetro-de-entrada-salida :: Nombre-de-variable Identificador-de-referencia-de-género

Gráfico-de-procedimiento :: Nodo-de-arranque-de-procedimiento Nodo-de-estado - set

Nodo-de-arranque-de-procedimiento :: Transición

Gramática textual concreta

&lab;definición de procedimiento> ::= PROCEDURE {&lab;identificador de procedimiento >|&lab;nombre de procedimiento > } &lab;fin> [parámetros formales de procedimiento> &lab;fin>] {&lab;definición de datos> | &lab;definición de variable> | &lab;referencia textual de procedimiento> | &lab;definición de procedimiento> | &lab;definición de seleccionar> | &lab;definición de macro> }* &lab;cuerpo de procedimiento> ENDPROCEDURE [&lab;nombre de procedimiento >|&lab;identificador de procedimiento >] &lab;fin>

&lab;parámetros formales de procedimiento> ::= FPAR &lab;parámetro formal de variable> {,&lab;parámetro formal de variable> }*

&lab;parámetro formal de variable>::= [IN/OUT | IN] &lab;nombre de variable >{,&lab;nombre de variable >}*&lab;género>

&lab;cuerpo de procedimiento> ::= &lab;cuerpo de proceso>

&lab;definición de variable> se define en 2.6.1.1 , &lab;referencia textual de procedimiento> en 2.4.4 , &lab;definición de macro> en 4.2 , &lab;definición de seleccionar> en 4.3.3 , &lab;definición de datos> en 5.5.1 , &lab;género> en 5.2.2 .

En una &lab;definición de procedimiento>, &lab;definición de variable> no puede contener &lab;nombre de variable >s REVEALED, EXPORTED, REVEALED EXPORTED, EXPORTED REVEALED (véase 2.6.1 ). La figura 2.9.11 muestra un ejemplo de &lab;definición de procedimiento>.

Gramática gráfica concreta

&lab;diagrama de procedimiento> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de procedimiento> { {<área de texto de procedimiento> | <área de procedimiento> | &lab;diagrama de macro>^}* &lab;área de gráfico de procedimiento>^}^ set ^}

&lab;área de procedimiento> ::= &lab;referencia gráfica de procedimiento> | &lab;diagrama de procedimiento>

&lab;área de texto de procedimiento> ::= &lab;símbolo de texto> contains {&lab;definición de variable> | &lab;definición de datos> | &lab;definición de seleccionar> | &lab;definición de macro>^}*

&lab;referencia gráfica de procedimiento> ::= &lab;símbolo de procedimiento> contains &lab;nombre de procedimiento >

&lab;símbolo de procedimiento> ::= Figure omitted: 04 Figura 9 Figura 9, p. &lab;encabezamiento de procedimiento> ::= PROCEDURE {&lab;nombre de procedimiento >|&lab;identificador de procedimiento >} [&lab;parámetros formales de procedimiento>]

&lab;área de gráfico de procedimiento> ::= &lab;área de arranque de procedimiento> {<área de arranque>|<área de conector de entrada> }*

&lab;área de arranque de procedimiento> ::= &lab;símbolo de arranque de procedimiento> is followed by &lab;área de transición>

&lab;símbolo de arranque de procedimiento> ::=

Figure omitted: 04 Figura 10 Figura 10, p. &lab;definición de variable> se define en 2.6.1.1 , <área de transición> en 2.6.7.1 , <área de estado> en 2.6.3 , <área de conector de entrada> en 2.6.6 , &lab;definición de macro> y &lab;diagrama de macro> en 4.2 , &lab;definición de seleccionar> en 4.3.3 y &lab;definición de datos> en 5.5.1 .

La figura 2.9.12, en 2.9 , muestra un ejemplo de &lab;diagrama de procedimiento>.

Semántica

Un procedimiento es un medio de dar un nombre a un grupo de ítems y representar este grupo por una sola referencia. Las reglas para los procedimientos prescriben la forma de elegir el grupo de ítems, y limitan el ámbito del nombre de variables definidas en el procedimiento.

Una variable de procedimiento es una variable local dentro del procedimiento, que no puede ser ni revelada, ni vista, ni exportada, ni importada. Se crea cuando se interpreta el nodo de arranque de procedimiento, y deja de existir cuando se interpreta el nodo de retorno del gráfico de procedimiento.

Cuando se interpreta una definición, se interpreta su gráfico de procedimiento.

Una definición de procedimiento sólo es interpretada cuando la llama una instancia de proceso, y es interpretada por esa instancia de proceso.

La interpretación de una definición de procedimiento causa la creación de una instancia de procedimiento y hace que la interpretación comience de la manera siguiente:

a) Para cada parámetro-de-entrada se crea una variable local que tiene el nombre y el género del parámetro-de-entrada . Se asigna a la variable el valor de la expresión dada por el parámetro efectivo correspondiente, que puede ser indefinido.

b) Si un parámetro efectivo está vacío, al parámetro formal correspondiente se le da el valor indefinido.

c) Un parámetro formal sin atributo explícito tiene el atributo IN implícito.

d) Para cada definición-de-variable en la definición-de- procedimiento se crea una variable local que tiene el mismo nombre y género de la definición-de-variable .

e) Cada parámetro-de-entrada-salida denota un nombre sinónimo para la variable que se da en la expresión del parámetro efectivo. Este nombre sinónimo se utiliza durante toda la interpretación del gráfico-de-procedimiento cuando se hace referencia al valor de la variable o cuando se asigna un nuevo valor a la variable.

f) La transición contenida en el nodo-de-arranque-de-procedimiento se interpreta.

Gramática abstracta

Definición-de-canal :: Nombre-canal Trayecto-de-canal [ Trayecto-de-canal ] Trayecto-de-canal :: Bloque-de-origen Bloque-de-destino Identificador-de-señal - set Bloque-de-origen = Identificador-de-bloque | ENVIRONMENT Bloque-de-destino = Identificador-de-bloque | ENVIRONMENT Identificador-de-bloque = Identificador Identificador-de-señal = Identificador Nombre-de-canal = Nombre

El identificador-de-señal - set debe contener la lista de todas las señales que pueden ser transportadas por el(los) trayecto(s) de canal definidos por el canal.

Por lo menos uno de los puntos extremos del canal tiene que ser un bloque.

Si los dos puntos extremos son bloques, éstos tienen que ser diferentes.

El(los) punto(s) extremo(s) de bloque deben estar definidos en la misma unidad de ámbito en que está definido el canal.

Gramática textual concreta

&lab;definición de canal> ::= CHANNEL &lab;nombre de canal > &lab;trayecto de canal> [&lab;trayecto de canal>] [&lab;definición de subestructura de canal> | &lab;referencia textual de subestructura de canal>] ENDCHANNEL [&lab;nombre de canal >] &lab;fin>

&lab;trayecto de canal> ::= { FROM &lab;identificador de bloque > TO &lab;identificador de bloque > | FROM &lab;identificador de bloque > TO ENV | FROM ENV TO &lab;identificador de bloque >} WITH &lab;lista de señales> &lab;fin>

&lab;lista de señales> se define en 2.5.5 , &lab;definición de subestructura de canal> y &lab;referencia textual de subestructura de canal> en 3.2.3 .

Cuando se definen dos &lab;trayecto de canal>s, debe ser de sentidos opuestos.

Gramática gráfica concreta

&lab;área de definición de canal>::= &lab;símbolo de canal> is associated with {&lab;nombre de canal > { [{&lab;identificador de canal >|&lab;identificador de bloque >}] &lab;área de lista de señales>[<área de lista de señales>] } set } is connected to {<área de bloque>{<área de bloque>|&lab;símbolo de casilla>} [<área de asociación de subestructura de canal>] } set

El &lab;identificador de canal > identifica un canal externo conectado al &lab;diagrama de subestructura de bloque> delimitado por el &lab;símbolo de casilla>. El &lab;identificador de bloque > identifica un bloque externo que es un punto extremo de canal para el &lab;diagrama de subestructura de canal> delimitado por el &lab;símbolo de casilla>.

&lab;símbolo de canal>::= &lab;símbolo de canal 1> | &lab;símbolo de canal 2> | &lab;símbolo de canal 3>

&lab;símbolo de canal 1> ::=

MONTAGE

&lab;símbolo de canal 2> ::= MONTAGE

&lab;símbolo de canal 3> ::= MONTAGE

&lab;área de lista de señales> se define en 2.5.5 , <área de bloque> y &lab;símbolo de casilla> en 2.4.1 y <área de asociación de subestructura de canal> en 3.2.3 .

Para cada flecha en el &lab;símbolo de canal> tiene que haber un &lab;área de lista de señales>. Un <área de lista de señales> tiene que estar suficientemente próxima a la flecha con el que está asociada para que tal asociación sea inequívoca.

Semántica

Un canal representa una ruta de transporte de señales. Un canal puede considerarse como uno o dos trayectos de canal unidireccionales e independientes entre dos bloques o entre un bloque y su entorno.

Las señales transportadas por canales se entregan al punto extremo de destino.

Las señales son presentadas en el punto extremo de destino de un canal en el mismo orden en que fueron presentadas en el punto de origen. Si dos o más señales son presentadas simultáneamente al canal, serán ordenadas arbitrariamente.

Un canal puede demorar las señales que transporta. Esto significa que hay una cola de espera de tipo primero-en-entrar-primero-en-salir FIFO ( `First-In-First-Out' ) asociada a cada sentido de transmisión de un canal. Una señal presentada al canal es introducida en la cola de espera. Tras un intervalo de tiempo indeterminado y no constante, la primera instancia de señal es liberada de la cola y aplicada a uno de los canales o a una de las rutas de señales que está conectado(a) al canal.

Pueden existir varios canales entre los dos mismos puntos extremos. Canales diferentes pueden transportar señales del mismo tipo.

Gramática abstracta

Definición-de-ruta-de-señales :: Nombre-de-ruta-de-señales Trayecto-de-ruta-de-señales [ Trayecto-de-ruta-de-señales ] Trayecto-de-ruta-de-señales :: Proceso-de-origen Proceso-de-destino Identificador-de-señal- set Proceso-de-origen = Identificador-de-proceso | ENVIRONMENT Proceso-de-destino = Identificador-de-proceso | ENVIRONMENT Nombre-de-ruta-de-señales = Nombre

Por lo menos uno de los puntos extremos del trayecto-de-ruta-de-señales tiene que ser un proceso.

Si los dos puntos extremos son procesos, los identificadores-de-proceso tienen que ser diferentes.

El(los) punto(s) extremo(s) de proceso tienen que estar definidos en la misma unidad de ámbito en que está definida la ruta de señales.

Gramática textual concreta

&lab;definición de ruta de señales>::= SIGNALROUTE &lab;nombre de ruta de señales > &lab;trayecto de ruta de señales> [&lab;trayecto de ruta de señales>]

&lab;trayecto de ruta de señales>::= { FROM &lab;identificador de proceso > TO &lab;identificador de proceso > | FROM &lab;identificador de proceso > TO ENV | FROM ENV TO &lab;identificador de proceso > } WITH &lab;lista de señales> &lab;fin>

La &lab;lista de señales> se define en 2.5.5 .

Cuando hay definidos dos &lab;trayecto de ruta de señales>s, deben ser de sentidos opuestos.

Gramática gráfica concreta

&lab;área de definición de ruta de señales> ::= &lab;símbolo de ruta de señales> is associated with {&lab;nombre de ruta de señales > {[&lab;identificador de canal >] <área de lista de señales> [<área de lista de señales>] } set } is connected to

{<área de proceso> {<área de proceso> | &lab;símbolo de casilla>} } set

&lab;símbolo de ruta de señales> ::= &lab;símbolo de ruta de señales 1> | &lab;símbolo de ruta de señales 2>

&lab;símbolo de ruta de señales 1> ::= MONTAGE

&lab;símbolo de ruta de señales 2> ::= MONTAGE

Un símbolo de ruta de señales incluye una punta de flecha en un extremo (un solo sentido) o una punta de flecha en cada extremo (ambos sentidos), que indica el sentido del flujo de las señales.

Para cada punta de flecha en el &lab;símbolo de ruta de señales> debe haber un <área de lista de señales>. Un <área de lista de señales> tiene que estar lo suficientemente próxima a la punta de flecha a que está asociada para que tal asociación sea inequívoca.

Cuando el &lab;símbolo de ruta de señales> está conectado al &lab;símbolo de casilla>, el &lab;identificador de canal > identifica un canal al cual está conectada la ruta de señales.

Semántica

Una ruta de señales representa una ruta de transporte de señales. Una ruta de señales puede considerarse como uno o dos trayectos unidireccionales independientes de ruta de señales entre dos procesos o entre un proceso y su entorno.

Las señales transportadas por rutas de señales se entregan a los puntos extremos de destino.

Una ruta de señales no introduce ningún retardo en el transporte de las señales.

Ninguna ruta de señales conecta instancias de proceso del mismo tipo. En este caso, la interpretación del nodo-de-salida implica que la señal se pone directamente en el puerto de entrada del proceso de destino.

Pueden existir varias rutas de señales entre los mismos dos puntos extremos. Diferentes rutas de señales pueden transportar señales del mismo tipo.

Modelo

Un &lab;conjunto de señales de entrada válidas> contiene señales que el proceso puede recibir. Sin embargo, un &lab;conjunto de señales de entrada válidas> no debe contener señales de temporizador. Si una &lab;definición de bloque> contiene &lab;definición de ruta de señales>s, el &lab;conjunto de señales de entrada válidas>, de haberlo, no necesita contener señales en las rutas de señales que conducen al proceso.

Si una &lab;definición de bloque> no contiene &lab;definición de ruta de señales>s, todas las &lab;definición de proceso>s en esa &lab;definición de bloque> deben contener un &lab;conjunto de señales de entrada válidas>. En ese caso, las &lab;definición de ruta de señales>s y las &lab;conexión de canal a ruta>s se derivan de los &lab;conjunto de señales de llamada válida>s, las &lab;salida>s y los canales que terminan en el límite de los bloques. Las señales que corresponden a un determinado sentido de flujo entre dos procesos en la ruta de señales implicada constituyen la intersección de las señales especificadas en el &lab;conjunto de señales de entrada válidas> del proceso de destino y las señales mencionadas en una salida del proceso de origen. Si uno de los puntos extremos es el entorno, el conjunto de entrada/conjunto de salida para ese punto extremo está constituido por las señales transportadas por el canal en el sentido dado.

Gramática abstracta

Conexión-de-canal-a-ruta :: Identificador-de-canal Identificador-de-ruta-de-señales- set

Identificador-de-ruta-de-señales = Identificador

En 3 figuran otras construcciones de conexión.

Cada identificador-de-canal conectado al bloque circundante debe ser mencionado exactamente en una conexión-de-canal-a-ruta . El identificador-de-canal en una conexión-de-canal-a-ruta debe denotar un canal conectado al bloque circundante.

Cada identificador-de-ruta-de-señales en una conexión-de-canal-a-ruta tiene que estar definido en el mismo bloque en que está definida la conexión-de-canal-a-ruta y tiene que tener la frontera de ese bloque como uno de sus puntos extremos. Cada identificador-de-ruta-de-señales definido en el bloque circundante y que tiene el entorno como uno de sus puntos extremos, debe mencionarse en una conexión-de-canal-a-ruta , y sólo en una.

Para un determinado sentido de flujo, la unión de los conjuntos identificador-de-señal en las rutas de señales en una conexión-de-canal-a-ruta tiene que ser igual al conjunto de las señales transportadas por el identificador-de-canal en la misma conexión-de-canal-a-ruta y correspondientes al mismo sentido de flujo.

Gramática textual concreta

&lab;conexión de canal a ruta> ::= CONNECT &lab;identificador de canal > AND &lab;identificador de ruta de señales > {,&lab;identificador de ruta de señales >}* &lab;fin>

Ningún &lab;identificador de ruta de señales > en una &lab;conexión de canal a ruta> puede ser mencionado dos veces.

Gramática gráfica concreta

Gráficamente, la construcción de conectar está representada por el &lab;identificador de canal > asociado a la ruta de señales y contenido en el <área de definición de ruta de señales> (véase 2.5.2 Gramática gráfica concreta ).

Gramática abstracta

Definición-de-señal :: Nombre-de-señal Identificador-de-referencia-de-género * [ Refinamiento-de-señal ]

Nombre-de-señal :: Nombre

El identificador-de-referencia-de-género se define en 5.2.2 .

Gramática textual concreta

&lab;definición de señal>::= SIGNAL {&lab;nombre de señal > [&lab;lista de géneros>]^[&lab;refinamiento de señal>] } {,&lab;nombre de señal > [&lab;lista de géneros>] [&lab;refinamiento de señal>]^}* &lab;fin>

&lab;lista de géneros>::= (&lab;género> {, &lab;género>}*)

&lab;refinamiento de señal> se define en 3.3 y &lab;género> en 5.2.2 .

Semántica

Una instancia de señal es un flujo de información entre procesos, siendo también una instanciación de un tipo de señal definido por una definición de señal. Una instancia de señal puede ser enviada, bien por el entorno, bien por un proceso, y siempre está dirigida, sea hacia un proceso, sea hacia el entorno.

Con cada instancia de señal están asociados dos valores PId (véase el 5.6.10 ) que denotan los procesos de origen y de destino, el &lab;identificador de señal > especificado en la salida correspondiente y otros valores, cuyos géneros se definen en la definición de señal.

Un &lab;identificador de lista de señales > puede utilizarse en &lab;definición de canal>, &lab;definición de ruta de señales>, &lab;definición de lista de señales>, &lab;conjunto de señales de entrada válidas> y &lab;lista de conservaciones> como una notación taquigráfica para enumerar identificadores de señal y señales de temporizador.

Gramática textual concreta

&lab;definición de lista de señales>::= SIGNALLIST &lab;nombre de lista de señales >=&lab;lista de señales>&lab;fin>

&lab;lista de señales>::= &lab;ítem de señal> {,<ítem de señal>}*

&lab;ítem de señal>::= &lab;identificador de señal > | &lab;identificador de señal prioritaria > (&lab;identificador de lista de señales >) | &lab;identificador de temporizador >

La &lab;lista de señales> que se construye reemplazando todos los &lab;identificador de lista de señales >s de la lista por los &lab;identificador de señal >s que éstos denotan, corresponde a un identificador-de-señal - set en la gramática abstracta . En toda &lab;lista de señales> así construida, cada &lab;identificador de señal > tiene que ser distinto.

Gramática gráfica concreta

&lab;área de lista de señales>::= &lab;símbolo de lista de señales> contains &lab;lista de señales>

&lab;símbolo de lista de señales>::=

Figure omitted: 03 Figura 1 Figura 1, p. 50 (E) Figure omitted: 28 blanc Montage: 2.6 A LA Fin de cette page

Gramática abstracta

Nodo-de-arranque-de-proceso :: Transición

Gramática textual concreta

&lab;arranque>::= START&lab;fin>&lab;transición>

Gramática gráfica concreta

&lab;área de arranque>::= &lab;símbolo de arranque> is followed by &lab;área de transición>

&lab;símbolo de arranque>::=

Figure omitted: 04 Figure du 2.6.2 Figure du 2.6.2 , (N), p. Semántica

La transición ^ del nodo-de-arranque-de-proceso ^ se interpreta.

Gramática abstracta

Nodo-de-estado :: Nombre-de-estado Conjunto-de-señales-de-conservación Nodo-de-entrada- set

Nombre-de-estado = Nombre

Dentro de un gráfico-de-proceso ^ o gráfico-de-procedimiento , los nodos-de-estado ^ tienen diferentes nombres-de-estado .

Para cada nodo-de-estado , todos los identificadores-de-señal ^(en el conjunto completo de señales de entrada válidas) aparecen, bien en un conjunto-de-señales-de-conservación , bien en un nodo-de-entrada.

El identificador-de-señal ^ en el nodo-de-entrada - set tienen que ser distintos.

Gramática textual concreta

&lab;estado>::= STATE &lab;lista de estados>&lab;fin> {&lab;parte entrada> | &lab;entrada prioritaria> | &lab;parte conservación> | &lab;señal continua>}* [ENDSTATE [&lab;nombre de estado >] &lab;fin>]

&lab;lista de estados>::= {&lab;nombre de estado > {, &lab;nombre de estado >}*} | &lab;lista de estados asterisco>

&lab;parte entrada> se define en 2.6.4 , &lab;parte conservación> en 2.6.5 , &lab;señal continua> en 4.11 , &lab;lista de estados asterisco> en 4.4 y &lab;entrada prioritaria> en 4.10.2 .

Cuando la &lab;lista de estados> contiene un solo &lab;nombre de estado >, el &lab;nombre de estado > representa un nodo-de-estado . Para cada nodo-de-estado , el conjunto-de-señales-de-conservación se representa por la &lab;parte conservación> y eventuales conservaciones implícitas de señales. Para cada nodo-de-estado , el nodo-de-entrada - set se representa por la &lab;parte entrada> y las eventuales señales de entrada implícitas.

El &lab;nombre de estado > opcional que termina un &lab;estado> sólo puede especificarse si la &lab;lista de estados> en el &lab;estado> consiste en un solo &lab;nombre de estado >, en cuyo caso éste debe ser el mismo &lab;nombre de estado > que el contenido en la &lab;lista de estados>.

Gramática gráfica concreta

&lab;área de estado>::= &lab;símbolo de estado> contains &lab;lista de estados> is associated with {<área de asociación de entrada> | <área de asociación de entrada prioritaria> | <área de asociación de señal continua> | <área de asociación de conservación>}^*

&lab;símbolo de estado>::=

Figure omitted: 04 Figure du 2.6.3 Figure du 2.6.3 , (N), p. &lab;área de asociación de entrada>::= &lab;símbolo de asociación de trazo continuo> is connected to &lab;área de entrada>

&lab;área de asociación de conservación>::= &lab;símbolo de asociación de trazo continuo> is connected to &lab;área de conservación>

&lab;área de entrada> se define en 2.6.4 &lab;área de conservación> en 2.6.5 , <área de asociación de señal continua> en 4.11 , <área de asociación de entrada prioritaria> en 4.10.2 .

Un <área de estado> representa uno o más nodos-de-estado .

Los &lab;símbolos de asociación de trazo continuo>s que tienen su origen en un &lab;símbolo de estado> pueden tener un trayecto de origen común.

Semántica

Un estado representa una condición particular en la cual una instancia de proceso puede consumir una instancia de señal, lo que causa una transición. Si no hay instancias de señal retenidas, el proceso espera en el estado hasta que se reciba una instancia de señal.

Modelo

Cuando la &lab;lista de estados> de cierto &lab;estado> contiene más de un &lab;nombre de estado >, se crea una copia del &lab;estado> para cada uno de estos &lab;nombre de estado >s. Entonces el &lab;estado> es reemplazado por estas copias.

Gramática abstracta

Nodo-de-entrada :: Identificador-de-señal [ Identificador-de-variable ]* Transición

Identificador-de-variable = Identificador

La longitud del [ identificador de variable ]* debe ser igual al número de identificadores-de-referencia-de-género de la definición-de-señal denotada por el identificador-de-señal .

Los géneros de las variables deben corresponder en posición a los géneros de los valores que pueden ser transportados por la señal.

No se permite especificar un número de variables, para ser recibidas, superior al número de valores transportados por la instancia de señal.

Gramática textual concreta

&lab;parte entrada>::= INPUT &lab;lista de entradas> &lab;fin> [&lab;condición habilitante>]&lab;transición>

&lab;lista de entradas>::= &lab;lista de entradas asterisco> | &lab;estímulo>{,&lab;estímulo>}*

&lab;estímulo>::= {&lab;identificador de señal > | &lab;identificador de temporizador >} [( [&lab;identificador de variable >] {,[&lab;identificador de variable >]}* )]

&lab;transición> se define en 2.6.7 , &lab;condición habilitante> en 4.12 , y &lab;lista de entradas asterisco> en 4.6 .

Cuando la &lab;lista de entradas> contiene un solo &lab;estímulo>, la &lab;parte entrada> representa un &lab;nodo de entrada>. En la gramática abstracta , las señales de temporizador (&lab;identificador de temporizador >) son también representadas por identificador-de-señal . Las señales de temporizador y las señales ordinarias sólo se distinguen cuando proceda, pues en muchos aspectos tienen propiedades similares. Las propiedades exactas de las señales de temporizador se definen en 2.8 .

Una &lab;transición> debe tener un terminador de transición, como se indica en 2.6.7.2 .

Gramática gráfica concreta

&lab;área de entrada>::= &lab;símbolo de entradas> contains &lab;lista de entradas> is followed by {[<área de condición habilitante>] <área de transición>}

&lab;símbolo de entrada>::=

Figure omitted: 04 Figure du 2.6.4 Figure du 2.6.4 , (N), p. &lab;área de transición> se define en 2.6.7 , <área de condición habilitante> en 4.12 .

Un <área de entrada> cuya &lab;lista de entradas> contiene un solo &lab;estímulo> corresponde a un nodo-de-entrada . Cada uno de los &lab;identificadores de señal > contenido en un &lab;símbolo de entrada> da el nombre de uno de los nodos-de-entrada que este &lab;símbolo de entrada> representa.

Semántica

Una entrada permite el consumo de la instancia de señal de entrada especificada. El consumo de la instancia de la señal de entrada pone a la disposición del proceso la información transportada por la señal. A las variables asociadas con la entrada se asignan valores transportados por la señal consumida. Si no hay variable asociada con la entrada para un género especificado en la señal, se descarta el valor de este género.

A la expresión SENDER del proceso consumidor se le da el valor PId de la instancia de proceso originadora, transportado por la instancia de señal.

Las instancias de señal que pasan del entorno a una instancia de proceso dentro del sistema tendrán siempre un valor PId diferente de cualquiera de los del sistema. El acceso se efectúa mediante la expresión SENDER.

Modelo

Cuando la lista de &lab;estímulo>s de cierta &lab;parte entrada> contiene más de un &lab;estímulo>, se crea una copia de la &lab;parte entrada> para cada uno de esos &lab;estímulos>s. La &lab;parte entrada> se reemplaza entonces por estas copias.

Una conservación especifica un conjunto de identificadores de señal cuyas instancias no son relevantes para el proceso en el estado al cual se ha asociado la conservación, y que debe conservarse para un procesamiento futuro.

Gramática abstracta

Conjunto-de-señales-de-conservación :: Identificador-de-señal - set

En cada nodo-de-estado , los identificadores-de-señal ^ contenidos en el conjunto-de-señales-de-conservación tienen que ser diferentes.

Gramática textual concreta

&lab;parte conservación> ::= SAVE &lab;lista de conservaciones>&lab;fin>

&lab;lista de conservación>::= {&lab;lista de señales> | &lab;lista de conservaciones asterisco>}

Una &lab;lista de conservaciones> representa el identificador-de-señal - set . La &lab;lista de conservaciones asterisco> es una notación taquigráfica que se explica en 4.8 .

Gramática gráfica concreta

&lab;área de conservación>::=

&lab;símbolo de conservación> contains &lab;lista de conservaciones>

&lab;símbolo de conservación>::=

Figure omitted: 04 Figure du 2.6.5 Figure du 2.6.5 , (N), p. Semántica

Las señales conservadas se retienen en el puerto de entrada en el orden de su llegada.

El efecto de la conservación es válido solamente para el estado al cual está asociada la conservación. En el estado siguiente, las instancias de señal que han sido `conservadas' se tratan como instancias de señal normales.

Gramática textual concreta

&lab;etiqueta>::= &lab;nombre de conector >:

Todos los &lab;nombre de conector >s definidos en un &lab;cuerpo de proceso> tienen que ser distintos.

Una etiqueta representa el punto de entrada de un `salto' desde las sentencias de unión correspondientes con los mismos &lab;nombre de conector >s en el mismo &lab;cuerpo de proceso>.

Sólo se permiten `saltos' a etiquetas dentro del mismo &lab;cuerpo de proceso>.

Gramática gráfica concreta

&lab;área de conector de entrada>::= &lab;símbolo de conector de entrada> contains &lab;nombre de conector > is followed by &lab;área de transición>

&lab;símbolo de conector de entrada>::=

Figure omitted: 03 Figure du 2.6.6 Figure du 2.6.6 , (N), p. &lab;área de transición> se define en 2.6.7.1 .

Un <área de conector de entrada> representa la continuación de un &lab;símbolo de línea de flujo> desde un <área de conector de salida> correspondiente, con el mismo &lab;nombre de conector >, en la misma <área de gráfico de proceso> o <área de gráfico de procedimiento>.

Gramática abstracta

Nodo-de-tarea :: Sentencia-de-asignación | Texto-informal

Gramática textual concreta

&lab;tarea> ::= TASK &lab;cuerpo de tarea>

&lab;cuerpo de tarea>::= {&lab;sentencia de asignación>{,&lab;sentencia de asignación>}*} | {&lab;texto informal>{,&lab;texto informal>}*}

&lab;sentencia de asignación> se define en 5.5.3 .

Gramática gráfica concreta

&lab;área de tarea>::= &lab;símbolo de tarea> contains &lab;cuerpo de tarea>

&lab;símbolo de tarea>::=

Figure omitted: 04 Figure du 2.7 Figure du 2.7 , (N), p. Semántica

La interpretación de un nodo-de-tarea ^ es la interpretación de la sentencia-de-asignación que se explica en 5.5.3 , o la interpretación del texto-informal que se explica en 2.2.3 .

Modelo

Una &lab;tarea> y un <área de tarea> pueden contener varias &lab;sentencia de asignación>s o &lab;texto informal>s. En ese caso es sintaxis derivada para especificar una secuencia de &lab;tarea>s, una para cada &lab;sentencia de asignación> o &lab;texto informal> de modo que se mantenga el orden original en que fueron especificados en el &lab;cuerpo de tarea>.

Esta notación taquigráfica se expande antes de expandir cualquier &lab;expresión de importación> (véase el 4.13 ).

Gramática abstracta

Nodo-de-petición-de-crear :: Identificador-de-proceso [ Expresión ]*

Identificador-de-proceso = Identificador

El número de expresiones ^ en la [ expresión ]* tiene que ser igual al número de parámetros-formales-de-proceso en la definición-de-proceso del identificador-de-proceso . Cada expresión tiene que tener el mismo género que el parámetro-formal-de-proceso que le corresponde en posición en la definición-de-proceso denotada por el identificador-de-proceso .

Gramática textual concreta

&lab;petición de crear>::= CREATE &lab;cuerpo de crear>

&lab;cuerpo de crear>::= &lab;identificador de proceso > [&lab;parámetros efectivos>]

&lab;parámetros efectivos>::= ( [ &lab;expresión> ] {,[&lab;expresión>]}*)

&lab;expresión> se define en 5 .

Gramática gráfica concreta

&lab;área de petición de crear>::= &lab;símbolo de petición de crear> contains &lab;cuerpo de crear>

&lab;símbolo de petición de crear>::=

Figure omitted: 04 Figure du 2.7.2 Figure du 2.7.2 , (N), p. Un <área de petición de crear> representa un nodo-de-petición-de-crear .

Semántica

Cuando se crea una instancia de proceso se le da un puerto de entrada vacío, se crean variables y las expresiones de parámetros efectivos se interpretan en el orden dado y se asignan (como se define en el 5.5.3 ) a los parámetros formales correspondientes. Si un parámetro efectivo está vacío, se da al parámetro formal correspondiente el valor indefinido. Seguidamente, el proceso arranca interpretando el nodo de arranque en el gráfico de proceso.

El proceso creado actúa entonces asíncronamente y en paralelo con otros procesos.

La acción crear causa la creación de una instancia de proceso en el mismo bloque. El PARENT del proceso creado tiene el mismo valor PId que el SELF del proceso creador. Las expresiones SELF del proceso creado y OFFSPRING del proceso creador tienen ambas el último valor de PId creado (véase el 5.6.10.1 ).

Si se intenta crear un número mayor de instancias de proceso que el especificado por el número máximo de instancias en la definición de proceso, no se crea ninguna nueva instancia, la expresión OFFSPRING del proceso creador tiene el valor NULL, y la interpretación continúa.

Gramática abstracta

Nodo-de-llamada :: Identificador-de-procedimiento [ Expresión ]*

Identificador-de-procedimiento = Identificador

La longitud de la [ expresión ]* tiene que ser igual al número de los parámetros-formales-de-procedimiento en la definición-de-procedimiento del identificador-de-procedimiento .

Cada expresión ^ correspondiente en posición a un parámetro-formal-de-proceso ^ IN tiene que tener el mismo género que el parámetro-formal-de-proceso .

Cada expresión ^ correspondiente a un parámetro-formal-de-proceso ^ IN/OUT tiene que ser un identificador-de-variable con el mismo identificador-de-referencia-de-género que el parámetro-formal-de-proceso .

Tiene que haber una expresión ^ para cada parámetro-formal-de-proceso ^ IN/OUT.

Gramática textual concreta

&lab;llamada a procedimiento>::= CALL &lab;cuerpo de llamada a procedimiento>

&lab;cuerpo de llamada a procedimiento>::= &lab;identificador de procedimiento > [&lab;parámetros efectivos>]

&lab;parámetros efectivos> se define en el 2.7.2 .

Un ejemplo de &lab;llamada a procedimiento> se muestra en la figura 2.9.13, en el 2.9 .

Gramática gráfica concreta

&lab;área de llamada a procedimiento>::= &lab;símbolo de llamada a procedimiento> contains &lab;cuerpo de llamada a procedimiento>

&lab;símbolo de llamada a procedimiento>::=

Figure omitted: 04 Figure du 2.7.3 Figure du 2.7.3 , (N), p. El <área de llamada a procedimiento> representa el nodo-de-llamada .

Un ejemplo de <área de llamada a procedimiento> se muestra en la figura 2.9.14, en el 2.9 .

Semántica

La interpretación de un nodo de llamada a procedimiento transfiere la interpretación a la definición de procedimiento referenciada en el nodo de llamada, y se interpreta ese gráfico de procedimiento. Los nodos del gráfico de procedimiento se interpretan de la misma manera que los nodos equivalentes de un gráfico de proceso.

La interpretación del proceso llamante se suspende hasta que haya terminado la interpretación del proceso llamado.

Las expresiones de parámetros efectivos se interpretan en el orden dado.

Se necesita una semántica especial en lo que respecta a la interpretación de datos y parámetros (véase la explicación en el 2.4.4 ).

Gramática abstracta

Nodo-de-salida :: Identificador-de-señal [ Expresión ]* [ Destino-de-señal ] Dirigir-vía

Destino-de-señal = Expresión

Dirigir-vía = Identificador-de-ruta-de-señales - set

La longitud de la [ expresión ]* tiene que ser igual al número de identificadores-de-referencia-de-género en la definición-de-señal denotada por el identificador-de-señal .

Cada expresión ^ tiene que tener el mismo género que la referencia-de-identificador-de-género correspondiente (por posición) en la definición-de-señal .

Para cada subconjunto consistente posible (véase el 3 ) tiene que existir por lo menos un trayecto de comunicación (ya sea implícito para el propio tipo de proceso, ya sea explícito vía rutas de señales y, posiblemente, canales) hacia el entorno o hacia un tipo de proceso que tenga identificador-de-señal en su conjunto de señales de entrada válidas y que se origine a partir del tipo de proceso en que se utilizó el nodo-de-salida .

Para cada identificador-de-ruta-de-señales ^ en dirigir-vía ^ debe cumplirse que el proceso-de-origen en (uno de) los trayecto-de-ruta-de-señales de la ruta de señales debe ser un proceso del mismo tipo que el del proceso que contiene el nodo-de-salida y que el trayecto-de-ruta-de-señales tiene que incluir el identificador-de-señal en su conjunto de identificadores-de-señal .

Si no se especifica ningún identificador-de-ruta-de-señales ^ en dirigir-vía , todo proceso para el cual existe un trayecto de comunicación puede recibir la señal.

Gramática textual concreta

&lab;salida> ::= OUTPUT &lab;cuerpo de salida>

&lab;cuerpo de salida>::= &lab;identificador de señal > [&lab;parámetros efectivos>]^{, &lab;identificador de señal > [&lab;parámetros efectivos>]^}* [TO &lab;expresión PId >] [VIA { &lab;identificador de ruta de señales >{,&lab;identificador de ruta de señales >}* | ^{&lab;identificador de canal >{,&lab;identificador de canal >}* } ]

Los &lab;parámetros efectivos> se definen en el 2.7.2 y &lab;expresión> en el 5.4.2.1 .

No se permite especificar un &lab;identificador de canal > en la construcción VIA si hay rutas de señales especificadas para el bloque.

Para cada &lab;identificador de canal > de una &lab;salida> debe existir un canal proveniente del bloque circundante, y que pueda transportar las señales denotadas por los &lab;identificador de señal >s contenidos en la &lab;salida>.

TO &lab;expresión PId > representa el destino-de-señal .

La construcción VIA representa el dirigir-vía .

Gramática gráfica concreta

&lab;área de salida> ::= &lab;símbolo de salida> contains &lab;cuerpo de salida>

&lab;símbolo de salida>::=

Figure omitted: 03 Figure du 2.7.4 Figure du 2.7.4 , (N), p. Semántica

La expresión PId de destino-de-señal ^ se interpreta después de otras expresiones en el nodo-de-salida .

Los valores transportados por la instancia de señal son los valores de los parámetros efectivos en la salida. Si no hay ningún parámetro efectivo en la salida para un género en la definición de señal, la señal transporta el valor indefinido.

El valor PId de origen transportado por la instancia de señal es el valor asociado con SELF (del proceso que ejecuta la acción de salida). El valor PId de destino transportado por la instancia de señal es el valor de la expresión PId de destino de señal contenido en la salida.

La instancia de señal se pasa entonces a un trayecto de comunicación capaz de transportarla a la instancia de proceso de destino especificada.

Si no está especificado ningún destino-de-señal , tendrá entonces que existir un receptor, y sólo uno, que pueda recibir la señal de acuerdo con las rutas de señales o canales especificados en dirigir-vía . El valor PId de destino implícitamente transportado por la instancia de señal es el valor PId de este receptor.

El entorno puede siempre recibir cualquier señal del conjunto de señales de un canal que conduzca al entorno.

Obsérvese que el hecho de que se especifique el mismo identificador-de-canal ^ o identificador-de-ruta-de-señales ^ en el dirigir-vía de dos nodos-de-salida no significa automáticamente que las señales forman cola en el puerto de entrada en el mismo orden que se interpretan los nodos-de-salida . Sin embargo este orden se mantiene si las dos señales son transportadas por canales idénticos que conectan el proceso-de-origen con el proceso-de-destino o si los procesos se definen en el mismo bloque.

Si se especifica un sintipo en la definición de señal y se especifica una expresión en la salida, se aplica a la expresión la verificación de intervalo definida en el 5.4.1.9.1 . Si la verificación de intervalo es equivalente a Falso, la salida está en error y el comportamiento futuro del sistema está indefinido.

Una salida enviada a una instancia de proceso inexistente (tanto si nunca ha existido como si ha dejado de existir) causa un error de interpretación. La evaluación sobre la existencia de una instancia de proceso se hace al mismo tiempo que se interpreta la salida. Una detención ulterior de la instancia del proceso receptor hace que se descarte la señal en el puerto de entrada y no se informa una condición de error.

Modelo

Si se especifican varios pares de (&lab;identificador de señal> &lab;parámetros efectivos>) en un &lab;cuerpo de salida>, esto es sintaxis derivada para especificar una secuencia de &lab;salida>s o <área de salida>s en el mismo orden especificado en el &lab;cuerpo de salida> inicial, cada uno de los cuales contiene un solo par de (&lab;identificador de señal> &lab;parámetros efectivos>). La cláusula TO y la cláusula VIA se repiten en cada una de las &lab;salida>s o <área de salida>s. Esta notación taquigráfica se expande antes de expandir las eventuales notaciones taquigráficas en las expresiones contenidas.

Gramática abstracta

Nodo-de-decisión :: Pregunta-de-decisión Respuesta-de-decisión - set [ Respuesta-de-otro-caso ]

Pregunta-de-decisión = Expresión | Texto-informal

Respuesta-de-decisión :: ( Condición-de-intervalo | Texto-informal ) Transición

Respuesta-de-otro-caso :: Transición

Las respuestas-de-decisión ^ tienen que ser mutuamente exclusivas.

Si la pregunta-de-decisión ^ es una expresión , la condición-de-intervalo ^ de las respuestas-de-decisión tiene que ser del mismo género que la pregunta-de-decisión .

Gramática textual concreta

&lab;decisión>::= DECISION &lab;pregunta> &lab;fin> &lab;cuerpo de decisión> ENDDECISION

&lab;cuerpo de decisión>::= {&lab;parte respuesta> &lab;parte otro caso>} | {&lab;parte respuesta> {&lab;parte respuesta>}+ [&lab;parte otro caso>] }

&lab;parte respuesta>::= (&lab;respuesta>) : [&lab;transición>]

&lab;respuesta>::= &lab;condición de intervalo> | &lab;texto informal>

&lab;parte otro caso>::= ELSE:[&lab;transición>]

&lab;pregunta>::= &lab;expresión de pregunta > | &lab;texto informal>

&lab;condición de intervalo> se define en el 5.4.1.9.1 , &lab;transición> en el 2.6.7.1 , &lab;texto informal> en el 2.2.3 .

Una &lab;decisión> u &lab;opción de transición> (definida en el 4.3.4 ) es de terminación si cada &lab;parte respuesta> y &lab;parte otro caso> en el &lab;cuerpo de decisión> contiene una &lab;transición> en que se especifica una &lab;sentencia de terminador>, o contiene una &lab;cadena de transición> cuya última &lab;sentencia de acción> contiene una decisión de terminación o una opción.

Gramática gráfica concreta

&lab;área de decisión>::= &lab;símbolo de decisión> contains &lab;pregunta> is followed by { {&lab;parte respuesta gráfica> &lab;parte otro caso gráfico>} set | {&lab;parte respuesta gráfica> {&lab;parte respuesta gráfica>}+ [parte otro caso gráfico> ] } set }

&lab;símbolo de decisión>::=

Figure omitted: 04 Figure du 2.7.5 Figure du 2.7.5 , (N), p. &lab;parte respuesta gráfica>::= &lab;símbolo de línea de flujo> is associated with &lab;respuesta gráfica> is followed by &lab;área de transición>

&lab;respuesta gráfica>::= &lab;respuesta> | (&lab;respuesta>)

&lab;parte otro caso gráfico>::= &lab;símbolo de línea de flujo> is associated with ELSE is followed by &lab;área de transición>

&lab;área de transición> se define en el 2.6.7.1 y &lab;símbolo de línea de flujo> en el 2.6.7.2.2 .

La &lab;respuesta gráfica> y ELSE pueden situarse a lo largo del &lab;símbolo de línea de flujo> asociado, o en el &lab;símbolo de línea de flujo> interrumpido.

Los &lab;símbolo de línea de flujo>s que se originan en un &lab;símbolo de decisión> pueden tener un trayecto de origen común.

Un <área de decisión> representa un nodo-de-decisión .

Semántica

Una decisión transfiere la interpretación al trayecto de salida cuya condición de intervalo contiene el valor dado por la interpretación de la pregunta. Se define un conjunto de respuestas posibles a la pregunta, cada una de las cuales especifica el conjunto de acciones a interpretar para esa elección de trayecto.

Una de las respuestas puede ser el complemento de las otras. Esto se consigue especificando la respuesta-de-otro-caso , que indica el conjunto de acciones a realizar cuando el valor de la expresión sobre la cual se plantea la pregunta no está cubierto por los valores o el conjunto de valores especificados en las otras respuestas.

En todos aquellos casos en que no se especifica la respuesta-de-otro-caso , el valor resultante de la evaluación de expresión de pregunta debe corresponder con una de las respuestas.

Hay una ambigüedad sintáctica entre &lab;texto informal> y &lab;cadena de caracteres> en &lab;pregunta> y &lab;respuesta>. Si la &lab;pregunta> y todas las &lab;respuesta>s son &lab;cadena de caracteres>, todas estas se interpretan como &lab;texto informal>. Si la &lab;pregunta> o alguna &lab;respuesta> es una &lab;cadena de caracteres> que no encaja en el contexto de la decisión , la &lab;cadena de caracteres> denota &lab;texto informal>. El contexto de la decisión (es decir, el généro) se determina sin tener en cuenta las &lab;respuesta>s que son &lab;cadena de caracteres>.

Modelo

Si una &lab;decisión> no es una decisión de terminación, es entonces sintaxis derivada para una &lab;decisión> en la cual todas las &lab;parte respuesta>s y la &lab;parte otro caso> han insertado en su &lab;transición> una &lab;unión> con la primera &lab;sentencia de acción> que sigue a la decisión o, si la decisión es la última &lab;sentencia de acción> en una &lab;cadena de transición>, con la siguiente &lab;sentencia de terminador>.

File.Header.2

Una definición de bloque puede ser fraccionada (o subdivida, o `particionada' ) en un conjunto de definiciones de subbloque, definiciones de canal y definiciones de subcanal. De manera similar, una definición de canal puede ser fraccionada en un conjunto de definiciones de bloque, definiciones de canal y definiciones de subcanal. Así, cada definición de bloque y definición de canal puede tener dos versiones: una versión no fraccionada y una versión fraccionada en las sintaxis concretas. Sin embargo, las estructuras de canal se transforman cuando se establece una relación de correspondencia con la sintaxis abstracta. Estas dos versiones tienen el mismo interfaz estático, pero su comportamiento puede diferir hasta cierto punto, porque el orden de las señales de salida puede no ser el mismo. Una definición de subbloque es una definición de bloque, y una definición de subcanal es una definición de canal.

En la definición de un sistema concreto, así como en la definición de un sistema abstracto, puede aparecer tanto la versión no fraccionada como la versión fraccionada de un bloque. En este caso, una definición de sistema concreto contiene varios subconjuntos de partición consistentes, correspondiendo cada subconjunto a una instancia de sistema. Un subconjunto de partición consistente es una selección de las definiciones de bloque en una definición de sistema de tal modo que:

a) si contiene una definición-de-bloque , tiene entonces que contener la definición de la unidad de ámbito circundante, si existe;

b) debe contener todas las definiciones-de-bloque ^ definidas al nivel del sistema y, si contiene una definición-de-subbloque de una definición-de-bloque , tendrá entonces que contener todas las otras definiciones-de-subbloque de esa definición-de-bloque ;

c) todas las definiciones-de-bloque ^ `constitutivo de hoja' en la estructura resultante contienen definiciones-de-proceso .

Figure omitted: 14 blanc Figure omitted: 22 Figure 3.2.1 Figure 3.2.1 , (N), p. En el momento de la interpretación del sistema, se interpreta un subconjunto de partición consistente.

Se interpretan los procesos en cada uno de los bloques constitutivos de hoja en el subconjunto de partición consistente. Si estos bloques constitutivos de hoja contienen también subestructuras, no producen efecto alguno. Las subestructuras en los bloques no constitutivos de hoja producen efecto sobre la visibilidad, y los procesos en estos bloques no se interpretan.

Gramática abstracta

Definición-de-subestructura-de-bloque :: Nombre-de-subestructura-de-bloque Definición-de-subbloque- set Conexión-de-canal- set Definición-de-canal- set Definición-se-señal- set Definición-de-tipo-de-datos Definición-de-sintipo- set

Nombre-de-subestructura-de-bloque = Nombre

Definición-de-subbloque = Definición-de-bloque

Conexión-de-canal :: Identificador-de-canal Identificador-de-subcanal- set

Identificador-de-subcanal = Identificador-de-canal

Identificador-de-canal = Identificador

La definición-de-subestructura-de-bloque ^ tiene que contener por lo menos una definición-de-subbloque . Queda entendido que, en lo sucesivo, un término de sintaxis abstracta está contenido en la definición-de-subestructura-de-bloque , si no se indica otra cosa.

Un identificador-de-bloque ^ contenido en una definición-de-canal ^ tiene que denotar una definición-de-subbloque . Una definición-de-canal que conecta una definición-de-subbloque a la frontera de la definición-de-subestructura-de-bloque se denomina definición de subcanal.

Para cada definición-de-canal ^ externa conectada a la definición-de-subestructura-de-bloque tiene que hacer exactamente una conexión-de-canal . El identificador-de-canal en la conexión-de-canal tiene que identificar esta definición-de-canal externa.

Para señales que salen de la definición-de-subestructura-de-bloque , la unión de los identificadores-de-señal asociados al identificador-de-subcanal - set contenido en una conexión-de-canal debe ser idéntica a los identificadores-de-señal asociados al identificador-de-canal contenido en la conexión-de-canal . La misma regla es válida para las señales que entran en la definición-de-subestructura-de-bloque . Sin embargo, esta regla se modifica en el caso de refinamiento de señal (véase 3.3 ).

Cada identificador-de-subcanal ^ tiene que aparecer en una, y sólo una, conexión-de-canal .

Puesto que una definición-de-subbloque ^ es una definición-de-bloque , puede ser fraccionada. Esta partición puede repetirse cualquier número de veces, de lo que resulta una estructura jerárquica en árbol de definiciones-de-bloque y sus definiciones-de-subbloque . Se dice que las definiciones-de-subbloque de una definición-de-bloque existen en el nivel inmediato inferior del árbol de bloques (véase también la figura que sigue).

Figure omitted: 19 Figure 1 3.2.2 Figure 1 3.2.2 , (N), p. El diagrama de árbol de bloques es un diagrama auxiliar.

Gramática textual concreta

&lab;definición de subestructura de bloque>::= SUBSTRUCTURE {^[&lab;nombre de subestructura de bloque > ] | &lab;identificador de subestructura de bloque > } &lab;fin> { &lab;definición de bloque> | &lab;referencia textual de bloque> | &lab;definición de canal> | &lab;conexión de canal> | &lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de datos> | &lab;definición de seleccionar> | &lab;definición de macro> }+ ENDSUBSTRUCTURE [^{&lab;nombre de subestructura de bloque > | &lab;identificador de subestructura de bloque >}^] &lab;fin>

El &lab;nombre de subestructura de bloque > después de la palabra clave SUBSTRUCTURE sólo puede omitirse si es igual al &lab;nombre de bloque > en la &lab;definición de bloque> circundante.

&lab;referencia textual de subestructura de bloque>::= SUBSTRUCTURE &lab;nombre de subestructura de bloque > REFERENCED &lab;fin>

&lab;conexión de canal>::= CONNECT &lab;identificador de canal > AND &lab;identificador de subcanal > {, &lab;identificador de subcanal >}* &lab;fin>

Gramática gráfica concreta

&lab;diagrama de subestructura de bloque>::= &lab;símbolo de casilla> contains {&lab;encabezamiento de subestructura de bloque> { {<área de texto de subestructura de bloque>}* {&lab;diagrama de macro>}* &lab;área de interacción de bloque> }^ set } is associated with {&lab;identificador de canal >}*

El &lab;identificador de canal > identifica un canal conectado a un subcanal en el &lab;diagrama de subestructura de bloque>. Se coloca fuera del &lab;símbolo de casilla> próximo al punto extremo del subcanal en el &lab;símbolo de casilla>

Un &lab;símbolo de canal> dentro del &lab;símbolo de casilla> y conectado a éste indica un subcanal.

&lab;encabezamiento de subestructura de bloque>::= SUBSTRUCTURE {&lab;nombre de subestructura de bloque > | &lab;identificador de subestructura de bloque >}

&lab;área de texto de subestructura de bloque>::= &lab;área de texto de sistema>

&lab;área de subestructura de bloque>::= &lab;referencia gráfica de subestructura de bloque> | &lab;diagrama de subestructura de bloque> | &lab;diagrama de subestructura de bloque abierto>

&lab;referencia gráfica de subestructura de bloque>::= &lab;símbolo de subestructura de bloque> contains &lab;nombre de subestructura de bloque >

&lab;símbolo de subestructura de bloque>::= &lab;símbolo de bloque>

&lab;diagrama de subestructura de bloque abierto>::= { {<área de texto de subestructura de bloque>}* {&lab;diagrama de macro>}* &lab;área de interacción de bloques>} set

Cuando un <área de subestructura de bloque> es un &lab;diagrama de subestructura de bloque abierto>, el &lab;diagrama de bloque> circundante no puede contener <área de texto de bloque>, &lab;diagrama de macro>, ni <área de interacción de procesos>.

Semántica

Véase 3.2.1 .

Modelo

Un &lab;diagrama de subestructura de bloque abierto> se transforma en un &lab;diagrama de subestructura de bloque> de tal manera que en el &lab;encabezamiento de subestructura de bloque> el &lab;nombre de subestructura de bloque > o el &lab;identificador de subestructura de bloque > es el mismo que el &lab;nombre de bloque > respectivamente &lab;identificador de bloque > en el &lab;diagrama de bloque> circundante.

Ejemplo

A continuación se presenta un ejemplo de una &lab;definición de subestructura de bloque>.

BLOCK A; SUBSTRUCTURE A; SIGNAL s5(nat), s6, s8, s9(min); BLOCK a1 REFERENCED; BLOCK a2 REFERENCED; BLOCK a3 REFERENCED; CHANNEL c1 FROM a2 TO ENV WITH s1, s2; ENDCHANNEL c1; CHANNEL c2 FROM ENV TO a1 WITH s3; FROM a1 TO ENV WITH s1; ENDCHANNEL c2; CHANNEL d1 FROM a2 TO ENV WITH s7; ENDCHANNEL d1; CHANNEL d2 FROM a3 TO ENV WITH s10; ENDCHANNEL d2; CHANNEL e1 FROM a1 TO a2 WITH s5, s6; ENDCHANNEL e1; CHANNEL e2 FROM a3 TO a1 WITH s8; ENDCHANNEL e2; CHANNEL e3 FROM a2 TO a3 WITH s9; ENDCHANNEL e3; CONNECT c AND c1, c2; CONNEXT d AND d1, d2; ENDSUBSTRUCTURE A; ENDBLOCK A;

El &lab;diagrama de subestructura de bloque> para el mismo ejemplo se presenta a continuación.

Figure omitted: 25 Figure 2/ 3.2.2 Figure 2/ 3.2.2 , (N), p.

Todas las condiciones estáticas se enuncian mediante una gramática textual concreta. Condiciones análogas se cumplen para la gramática gráfica concreta.

Gramática textual concreta

&lab;definición de subestructura de canal>::= SUBSTRUCTURE {^[&lab;nombre de subestructura de canal >] | &lab;identificador de subestructura de canal > } &lab;fin> { &lab;definición de bloque> | &lab;referencia textual de bloque> | &lab;definición de canal> | &lab;conexión de punto extremo de canal> | &lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de datos> | &lab;definición de seleccionar> | &lab;definición de macro> }+ ENDSUBSTRUCTURE [^{ &lab;nombre de subestructura de canal > | &lab;identificador de subestructura de canal >}^] &lab;fin>

El &lab;nombre de subestructura de canal > que sigue a la palabra clave SUBSTRUCTURE sólo puede omitirse si es el mismo que el &lab;nombre de canal > en la &lab;definición de canal> circundante.

&lab;referencia textual de subestructura de canal>::= SUBSTRUCTURE &lab;nombre de subestructura de canal > REFERENCED &lab;fin>

&lab;conexión de punto extremo de canal>::= CONNECT {&lab;identificador de bloque | ENV^} AND &lab;identificador de subcanal > {, &lab;identificador de subcanal >}* &lab;fin>

Para cada punto extremo de la &lab;definición de canal> fraccionada tiene que haber exactamente una &lab;conexión de punto extremo de canal>. El &lab;identificador de bloque > o ENVIRONMENT en una &lab;conexión de punto extremo de canal> tiene que identificar uno de los puntos extremos de la &lab;definición de canal> fraccionada.

Gramática gráfica concreta

&lab;diagrama de subestructura concreta>::= &lab;símbolo de casilla> contains {&lab;encabezamiento de subestructura de canal> { { <área de texto de subestructura de canal>}* {&lab;diagrama de macro>}* &lab;área de interacción de bloques> }^ set } is associated with {&lab;identificador de bloque > | ENV^}+

El &lab;identificador de bloque> o ENV identifica un punto extremo del canal fraccionado. El &lab;identificador de bloque > se coloca fuera del &lab;símbolo de casilla> próximo al punto extremo del subcanal asociado en el &lab;símbolo de casilla>. El &lab;símbolo de canal> dentro del &lab;símbolo de casilla> y conectado a éste indica un subcanal.

&lab;encabezamiento de subestructura de canal>::= SUBSTRUCTURE { &lab;nombre de subestructura de canal > | &lab;identificador de subestructura de canal >}

&lab;área de texto de subestructura de canal>::= &lab;área de texto de sistema>

&lab;área de asociación de subestructura de canal>::= &lab;símbolo de asociación de trazo discontinuo> is connected to &lab;área de subestructura de canal>

&lab;área de subestructura de canal>::= &lab;referencia gráfica de subestructura de canal> | &lab;diagrama de subestructura de canal>

&lab;referencia gráfica de subestructura de canal>::= &lab;símbolo de subestructura de canal> contains &lab;nombre de subestructura de canal >

&lab;símbolo de subestructura de canal>::= &lab;símbolo de bloque>

Modelo

Una &lab;definición de canal> que contiene una &lab;definición de subestructura de canal> se transforma en una &lab;definición de bloque> y dos &lab;definición de canal>s de tal modo que:

a) Cada una de las dos &lab;definición de canal>s está conectada al bloque y a un punto extremo del canal original. Las &lab;definición de canal>s tienen nombres nuevos distintos y toda referencia al canal original en las construcciones VIA se reemplaza por una referencia al nuevo canal apropiado.

b) La &lab;definición de bloque> tiene un nombre nuevo distinto y contiene solamente una &lab;definición de subestructura de bloque> que tiene el mismo nombre y contiene las mismas definiciones que la &lab;definición de subestructura de canal> original. Los calificadores en la nueva &lab;definición de bloque> se cambian para incluir el nombre de bloque. Las dos &lab;conexión de punto extremo de canal>s provenientes de la &lab;definición de subestructura de canal> original se representan por dos &lab;conexión de canal>s en las cuales el &lab;identificador de bloque> o ENV se reemplaza por el nuevo canal apropiado.

Esta transformación debe efectuarse inmediatamente después de las de un sistema genérico. Véase 4.3 .

Ejemplo

A continuación se presenta un ejemplo de una &lab;definición de subestructura de canal>.

CHANNEL C FROM A TO B WITH s1; FROM B TO A WITH s2;

SUBSTRUCTURE C;

SIGNAL s3(hel), s4(boo), s5;

BLOCK b1 REFERENCED; BLOCK b2 REFERENCED;

CHANNEL c1 FROM ENV TO b1 WITH s1; FROM b1 TO ENV WITH s2; ENDCHANNEL c1;

CHANNEL c2 FROM b2 TO ENV WITH s1; FROM ENV TO b2 WITH s2; ENDCHANNEL c2;

CHANNEL e1 FROM b1 TO b2 WITH s3; ENDCHANNEL e1; CHANNEL e2 FROM b2 TO b1 WITH s4, s5; ENDCHANNEL e2;

CONNECT A AND c1; CONNECT B AND c2;

ENDSUBSTRUCTURE C;

ENDCHANNEL C;

El &lab;diagrama de subestructura de canal> para el mismo ejemplo se presenta a continuación.

Figure omitted: 20 Figure 3.2.3 Figure 3.2.3 , (N), p.

&lab;nombre formal> ::= [&lab;nombre>^%] &lab;parámetro de macro> {^% &lab;nombre> %&lab;parámetro de macro> | %&lab;parámetro de macro> }* [%&lab;nombre>]

Gramática textual concreta

&lab;definición de macro> ::= MACRODEFINITION &lab;nombre de macro > [&lab;parámetros formales de macro>] &lab;fin> &lab;cuerpo de macro> ENDMACRO [&lab;nombre de macro >] &lab;fin>

&lab;parámetros formales de macro> ::= FPAR &lab;parámetros formales de macro> {, &lab;parámetro formal de macro>}*

&lab;parámetro formal de macro> ::= &lab;nombre>

&lab;cuerpo de macro> ::= {&lab;unidad léxica> | &lab;nombre formal>}*

&lab;parámetro de macro> ::= &lab;parámetro formal de macro> | MACROID

Los &lab;parámetro formal de macro>s tienen que ser distintos. Los &lab;parámetro efectivo de macro>s de una llamada a macro tienen que ser aplicados uno a uno con sus correspondientes &lab;parámetro formal de macro>s.

El &lab;cuerpo de macro> no podrá contener las palabras claves ENDMACRO y MACRODEFINITION.

Gramática gráfica concreta

&lab;diagrama de macro> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de macro> <área de cuerpo de macro>}

&lab;encabezamiento de macro> ::= MACRODEFINITION &lab;nombre de macro > [&lab;parámetros formales de macro>]

&lab;área de cuerpo de macro> ::= {tps.non.photo "|"}{ {&lab;cualquier área>}* {tps.non.photo "|{"} &lab;cualquier área> [^ is connected to &lab;cuerpo de macro puerto1>] }^ set |^{ &lab;cualquier área> is connected to &lab;cuerpo de macro puerto2> {tps.non.photo "|{"} &lab;cualquier área> is connected to &lab;cuerpo de macro puerto2> {tps.non.photo "|"}{ &lab;cualquier área> [ is connected to &lab;cuerpo de macro puerto2>]^}* }^ set

&lab;símbolo de acceso de entrada de macro> ::=

Figure omitted: 03 Figura 4.2.2 Figura 4.2.2 , (N), p. &lab;símbolo de acceso de salida de macro> ::=

Figure omitted: 03 Figura 4.2.2 Figura 4.2.2 , (N), p. &lab;cuerpo de macro puerto1> ::= &lab;símbolo de acceso de salida> is connected to {&lab;símbolo de casilla> [^ is associated with &lab;etiqueta de macro>] | &lab;símbolo de acceso de entrada de macro> [^{^ contains ^|^ is associated with } &lab;etiqueta de macro>] | &lab;símbolo de acceso de salida de macro> [^{^ contains ^|^ is associated with } &lab;etiqueta de macro>]^}

&lab;cuerpo de macro puerto 2> ::= &lab;símbolo de acceso de salida> is connected to {^&lab;símbolo de casilla> is associated with &lab;etiqueta de macro>] | &lab;símbolo de acceso de entrada de macro> {^ contains ^|^ is associated with } &lab;etiqueta de macro> | &lab;símbolo de acceso de salida de macro> {^ contains ^|^ is associated with } &lab;etiqueta de macro>}

&lab;etiqueta de macro> ::= &lab;nombre>

&lab;símbolo de acceso de salida> ::= &lab;símbolo de acceso de salida ficticio> | &lab;símbolo de línea de flujo> | &lab;símbolo de canal> | &lab;símbolo de ruta de señales> | &lab;símbolo de asociación de trazo continuo> | &lab;símbolo de asociación de trazo discontinuo> | &lab;símbolo de línea de crear>

&lab;símbolo de acceso de salida ficticio> ::= &lab;símbolo de asociación de trazo continuo>

&lab;cualquier área> ::= &lab;área de texto de sistema> | <área de interacción de bloques> | <área de lista de señales> | <área de bloque> | <área de texto de bloque> | <área de interacción de procesos> | &lab;referencia gráfica de procedimiento> | <área de texto de proceso> | <área de gráfico de proceso> | <área de fusión> | <área de cadena de transición> | <área de estado> | <área de entrada> | <área de conservación> | <área de inicialización> | <área de reinicialización> | <área de exportación> | <área de ampliación de texto> | <área de asociación de subestructura de canal> | <área de subestructura de canal> | <área de subestructura de bloque> | <área de entrada prioritaria> | <área de señal continua> | <área de conector de entrada> | <área de estado siguiente> | <área de proceso> | <área de definición de canal> | <área de línea de crear> | <área de definición de ruta de señales> | &lab;referencia gráfica de proceso> | &lab;diagrama de proceso> | <área de arranque> | <área de salida> | <área de salida prioritaria> | <área de tarea> | <área de petición de crear> | <área de llamada a procedimiento> | <área de procedimiento> | <área de decisión> | <área de conector de salida> | <área de texto de procedimiento> | <área de gráfico de procedimiento> | <área de arranque de procedimiento> | <área de texto de subestructura de bloque> | <área de interacción de bloques> | <área de servicio> | <área de definición de ruta de señales de servicio> | <área de texto de servicio> | <área de gráfico de servicio> | <área de arranque de servicio> | <área de comentario> | <área de llamada a macro> | <área de asociación de entrada> | <área de asociación de conservación> | <área de opción> | <área de texto de subestructura de canal> | <área de opción de transición> | <área de interacción de servicios> | <área de asociación de entrada prioritaria> | <área de asociación de señal continua> | <área de condición habilitante>

Un &lab;símbolo de acceso de salida ficticio> lo único que puede tener asociado es una &lab;etiqueta de macro>.

Para un &lab;símbolo de acceso de salida> que no sea un &lab;símbolo de acceso de salida ficticio>, el correspondiente &lab;símbolo de acceso de entrada> en la llamada a macro tiene que ser un &lab;símbolo de acceso de entrada ficticio>.

Un &lab;cuerpo de macro> puede aparecer en cualquier texto a que se hace referencia en &lab;cualquier área>.

Semántica

Una &lab;definición de macro> contiene unidades léxicas, mientras que un &lab;diagrama de macro> contiene unidades sintácticas. Así, la relación de correspondencia entre construcciones de macro en sintaxis textual y sintaxis gráfica generalmente no es posible. Por la misma razón se aplican reglas detalladas separadas para sintaxis textual y para sintaxis gráfica, aunque hay algunas reglas comunes.

El &lab;nombre de macro > es visible en la totalidad de la definición de sistema, cualquiera que sea la definición de macro que aparezca. Una llamada a macro puede aparecer antes de la definición de macro correspondiente.

Una definición de macro puede contener llamadas a macro, pero no podrá llamarse a sí misma directamente, ni tampoco indirectamente a través de llamadas a macro en otras definiciones de macro.

La palabra clave MACROID puede utilizarse como un pseudo parámetro formal de macro dentro de cada definición de macro. No se le podrá dar ningún &lab;parámetro efectivo de macro> y se remplaza por un &lab;nombre> único para cada expansión de una definición de macro (dentro de una expansión se utiliza el mismo &lab;nombre> para cada ocurrencia de MACROID).

Ejemplo

A continuación se presenta un ejemplo de una &lab;definición de macro>:

MACRODEFINITION Examen FPAR alfa, c, s, x; BLOCK alfa REFERENCED; CHANNEL c FROM x TO alfa WITH s; ENDCHANNEL c; ENDMACRO Examen;

El &lab;diagrama de macro> para el mismo ejemplo se presenta a continuación. Sin embargo, el &lab;parámetro formal de macro>, x, no se requiere en este caso.

Figure omitted: 11 Figura T1003150-88 Figura T1003150 (N), p.

Gramática textual concreta

&lab;llamada a macro> ::= MACRO &lab;nombre de macro > [&lab;cuerpo de llamada a macro>] &lab;fin>

&lab;cuerpo de llamada a macro> ::= (&lab;parámetro efectivo de macro> {, &lab;parámetro efectivo de macro>}*^)

&lab;parámetro efectivo de macro> ::= {&lab;unidad léxica>}*

La &lab;unidad léxica> no puede ser una coma `,' ni un paréntesis derecho `)' . Si uno cualquiera de estos caracteres debe ser utilizado en un &lab;parámetro efectivo de macro>, el &lab;parámetro efectivo de macro> tiene que ser una &lab;cadena de caracteres>. Si el &lab;parámetro efectivo de macro> es una &lab;cadena de caracteres>, el valor de la &lab;cadena de caracteres> se utiliza cuando el &lab;parámetro efectivo de macro> remplaza un &lab;parámetro formal de macro>.

Una &lab;llamada a macro> puede aparecer en cualquier lugar en que esté autorizada una &lab;unidad léxica>.

Gramática gráfica concreta

&lab;área de llamada a macro> ::= &lab;símbolo de llamada a macro> contains {&lab;nombre de macro > [&lab;cuerpo de llamada a macro>]^} [ is connected to {&lab;llamada a macro puerto1> | &lab;llamada a macro puerto2> {&lab;llamada a macro puerto2>} + }^]

&lab;símbolo de llamada a macro> ::=

Figure omitted: 04 Figura 4.2.3 Figura 4.2.3 , (N), p. &lab;llamada a macro puerto 1> ::= &lab;símbolo de acceso de entrada> [ is associated with &lab;etiqueta de macro>] is connected to &lab;cualquier área>

&lab;llamada a macro puerto 2> ::= &lab;símbolo de acceso de entrada> is associated with &lab;etiqueta de macro> is connected to &lab;cualquier área>

&lab;símbolo de acceso de entrada> ::= símbolo de acceso de entrada ficticio> | &lab;símbolo de línea de flujo> | &lab;símbolo de canal> | &lab;símbolo de ruta de señales> | &lab;símbolo de asociación de trazo continuo> | &lab;símbolo de asociación de trazo discontinuo> | &lab;símbolo de línea de crear>

&lab;símbolo de acceso de entrada ficticio> ::= &lab;símbolo de asociación de trazo continuo>

Un &lab;símbolo de acceso de entrada ficticio> lo único que puede tener asociado es &lab;etiqueta de macro>.

Para cada &lab;símbolo de acceso de entrada> tiene que haber un &lab;símbolo de acceso de salida> en el correspondiente &lab;diagrama de macro>, asociado con la misma &lab;etiqueta de macro>. Para un &lab;símbolo de acceso de entrada> que no sea un &lab;símbolo de acceso de entrada ficticio>, el &lab;símbolo de acceso de salida> correspondiente tiene que ser un &lab;símbolo de acceso de salida ficticio>.

Salvo en el caso de &lab;símbolo de acceso de entrada ficticio>s y &lab;símbolo de acceso de salida ficticio>s, es posible tener múltiples &lab;unidad léxica>s (textuales) asociadas con un &lab;símbolo de acceso de entrada> o &lab;símbolo de acceso de salida>. En este caso la &lab;unidad léxica> más próxima al &lab;símbolo de llamada a macro> o el &lab;símbolo de casilla> del &lab;diagrama de macro> se toma por la &lab;etiqueta de macro> asociada con el &lab;símbolo de acceso de entrada> o &lab;símbolo de acceso de salida>.

El <área de llamada a macro> puede aparecer en cualquier lugar en que esté autorizada un área. Sin embargo, se requiere cierto espacio entre el &lab;símbolo de llamada a macro> y cualquier otro símbolo gráfico cerrado. Si de acuerdo con las reglas sintácticas tal espacio no puede estar vacío, el &lab;símbolo de llamada a macro> se conecta al símbolo gráfico cerrado con un &lab;símbolo de acceso de entrada ficticio>.

Semántica

Una definición de sistema puede contener definiciones de macro y llamadas a macro. Antes de que puedan analizarse estas definiciones de sistema, todas las llamadas a macro deben ser expandidas. La expansión de una llamada a macro significa que una copia de la definición de macro que tiene el mismo &lab;nombre de macro > que el dado en la llamada a macro remplaza la llamada a macro.

Cuando se llama a una definición de macro, ésta es expandida. Esto significa que se crea una copia de la definición de macro y cada ocurrencia de los &lab;parámetro formal de macro>s de la copia es remplazada por los correspondientes &lab;parámetro efectivo de macro>s de la llamada a macro, después de lo cual las llamadas a macro en la copia, si existen, son expandidas. Cuando se remplazan los &lab;parámetro formal de macro>s por los &lab;parámetro efectivo de macro>s, se suprimen todos los caracteres `%' en los &lab;nombre formal>s.

Debería haber una correspondencia biunívoca entre &lab;parámetro formal de macro> y &lab;parámetro efectivo de macro>.

- Reglas para sintaxis gráfica

Para remplazar el <área de llamada a macro> por una copia del &lab;diagrama de macro> se procede de la siguiente manera. Todos los &lab;símbolo de acceso de entrada de macro>s y &lab;símbolo de acceso de salida de macro>s se suprimen. Un &lab;símbolo de acceso de salida ficticio> se remplaza por el &lab;símbolo de acceso de entrada> que tiene la misma &lab;etiqueta de macro>. Un &lab;símbolo de acceso de entrada ficticio> se remplaza por el &lab;símbolo de acceso de salida> que tiene la misma &lab;etiqueta de macro>. Después se suprimen las &lab;etiqueta de macro>s asociadas a &lab;símbolo de acceso de entrada>s y &lab;símbolo de acceso de salida>s. También se suprimen los &lab;cuerpo de macro puerto1> y &lab;cuerpo de macro puerto2> que no tienen &lab;llamada a macro puerto1> o &lab;llamada a macro puerto2> correspondientes.

Ejemplo

A continuación se presenta un ejemplo de una &lab;llamada a macro>, dentro de un fragmento de una &lab;definición de bloque>.

......... BLOCK A REFERENCED; MACRO Examen (B, C1, S1, A); BLOCK C REFERENCED; CHANNEL C2 FROM B TO C WITH S2; ENDCHANNEL C2; .........

La expansión de esta llamada a macro, utilizando el ejemplo del 4.2.2 , da el siguiente resultado:

............ BLOCK A REFERENCED; BLOCK B REFERENCED; CHANNEL C1 FROM A TO B WITH S1; ENDCHANNEL C1; BLOCK C REFERENCED; CHANNEL C2 FROM B TO C WITH S2; ENDCHANNEL C2; ............

Seguidamente se presenta el <área de llamada a macro> para el mismo ejemplo, dentro de un fragmento de un <área de interacción de bloques>.

Figure omitted: 08 Figura T1003160-88 Figura T1003160-88, (N), p. La expansión de esta llamada a macro da el siguiente resultado:

Figure omitted: 08 Figura T1003160-88 Figura T1003160-88, (N), p. Figure omitted: 41 blanc MONTAGE: 4.3 A LA FIN DE CETTE PAGE

Gramática textual concreta

&lab;definición de sinónimo externo> ::= SYNONYM &lab;nombre de sinónimo externo > &lab;género predefinido > = EXTERNAL

&lab;sinónimo externo> ::= &lab;identificador de sinónimo externo >

Una &lab;definición de sinónimo externo> puede aparecer en cualquier lugar en que se permita una &lab;definición de sinónimo> (véase 5.4.1.13 ). Un &lab;sinónimo externo> puede utilizarse en cualquier lugar en que se permita un &lab;sinónimo> (véase 5.4.2.3 ). Los géneros predefinidos son: boolean (booleano), character (carácter), charstring (cadena-de-caracteres), integer (entero), natural, real, PId, duration (duración) y time (tiempo).

Semántica

Un &lab;sinónimo externo> es un &lab;sinónimo> cuyo valor no está especificado en la definición de sistema. Esto se indica por la palabra clave EXTERNAL que se utiliza en lugar de una &lab;expresión simple>.

Una definición de sistema genérico es una definición de sistema que contiene &lab;sinónimo externo>s o &lab;texto informal> en una opción de transición (véase 4.3.4 ). Una definición de sistema específico se crea a partir de una definición de sistema genérico proporcionando valores para los &lab;sinónimo externo>s y transformando &lab;texto informal> en construcciones formales. La manera de efectuar esto, y la relación con la gramática abstracta, no forma parte de la definición del lenguaje.

Gramática textual concreta

&lab;expresión simple> ::= &lab;expresión fundamental>

Una &lab;expresión simple> contendrá solamente operadores, sinónimos y literales de los géneros predefinidos.

Semántica

Una expresión simple es una expresión-fundamental.

Gramática textual concreta

&lab;definición de seleccionar> ::= SELECT IF (&lab;expresión simple booleana >) &lab;fin> {&lab;definición de bloque> | &lab;referencia textual de bloque> | &lab;definición de canal> | &lab;definición de señal> | &lab;definición de lista de señales> | &lab;definición de datos> | &lab;definición de proceso> | &lab;referencia textual de proceso> | &lab;definición de temporizador> | &lab;definición de ruta de señales de servicio> | &lab;conexión de canal> | &lab;conexión de punto extremo de canal> | &lab;definición de variable> | &lab;definición de visión> | &lab;definición de importación> | &lab;definición de procedimiento> | &lab;referencia textual de procedimiento> | &lab;definición de servicio> | &lab;referencia textual de servicio> | &lab;definición de ruta de señales> | &lab;conexión de canal a ruta> | &lab;conexión de ruta de señales> | &lab;definición de seleccionar> | &lab;definición de macro>}+ ENDSELECT &lab;fin>

Una &lab;expresión simple booleana > no dependerá de ninguna definición dentro de la &lab;definición de seleccionar>. Una &lab;definición de seleccionar> sólo debe contener las definiciones que estén sintácticamente permitidas en ese lugar.

Gramática gráfica concreta

&lab;área de opción> ::= &lab;símbolo de opción> contains {SELECT IF (&lab;expresión simple booleana >) {tps.non.photo "{"}{<área de bloque> | <área de definición de canal> | <área de texto de sistema> | <área de texto de bloque> | <área de texto de proceso> | <área de texto de procedimiento> | <área de texto de subestructura de bloque> | <área de texto de subestructura de canal> | <área de texto de servicio> | &lab;diagrama de macro> | <área de proceso> | <área de definición de ruta de señales> | <área de línea de crear> | <área de procedimiento> | <área de opción> | <área de servicio> | <área de definición de ruta de señales de servicio> }+ }

El &lab;símbolo de opción> es un polígono de trazo discontinuo con esquinas de trazo continuo, por ejemplo:

Figure omitted: 04 Figure du 4.3.3 Figure du 4.3.3 , (N), p. Un &lab;símbolo de opción> contiene lógicamente la totalidad de cualquier símbolo gráfico unidimensional cortado por su frontera (es decir, con un punto extremo en su exterior).

La &lab;expresión simple booleana > no dependerá de ningún área o diagrama dentro del <área de opción>.

Un <área de opción> puede aparecer en cualquier lugar, salvo dentro de un <área de gráfico de proceso>, <área de gráfico de procedimiento> o <área de gráfico de servicio>. Un <área de opción> tiene que contener solamente las áreas y diagramas que están sintácticamente permitidos en ese lugar.

Semántica

Si el valor de la &lab;expresión simple booleana > es Falso, las construcciones contenidas en la &lab;definición de seleccionar> y en el &lab;símbolo de opción> no se seleccionan. En el otro caso se seleccionan las construcciones.

Modelo

En una transformación la &lab;definición de seleccionar> y el <área de opción> se remplazan por las construcciones seleccionadas contenidas, si existen.

Ejemplo

En el sistema Alfa hay tres bloques: B1, B2, y B3. El bloque B1 y los canales conectados a él son opcionales, y dependen de los valores de los sinónimos externos p y ampliación. En LED/PR, este ejemplo se representa como sigue.

SYSTEM Alfa; SYNONYM p Integer = EXTERNAL; SYNONYM ampliación Boolean = EXTERNAL; SIGNAL s1,s2,s3,s4,s5,s6,s7; SELECT IF (p = 3 AND ampliación); BLOCK B1 REFERENCED; CHANNEL C1 FROM ENV TO B1 WITH s1; ENDCHANNEL C1; CHANNEL C2 FROM B1 TO B2 WITH s2; ENDCHANNEL C2; CHANNEL C6 FROM B3 TO B1 WITH s6; ENDCHANNEL C6; ENDSELECT; CHANNEL C3 FROM B2 TO ENV WITH s3; ENDCHANNEL C3; CHANNEL C4 FROM B3 TO B2 WITH s4; ENDCHANNEL C4; CHANNEL C5 FROM B2 TO B3 WITH s5; ENDCHANNEL C5; CHANNEL C7 FROM ENV TO B3 WITH s7; ENDCHANNEL C7; BLOCK B2 REFERENCED; BLOCK B3 REFERENCED; ENDSYSTEM Alfa;

El mismo ejemplo en sintaxis LED/GR se representa como sigue.

Figure omitted: 26 Figure du 4.3.3 Figure du 4.3.3 , (N), p.

Gramática textual concreta

&lab;opción de transición> ::= ALTERNATIVE &lab;pregunta de alternativa> &lab;fin> {&lab;parte respuesta> &lab;parte otro caso> | &lab;parte respuesta> { &lab;parte respuesta> } + [ &lab;parte otro caso> ] } ENDALTERNATIVE

&lab;pregunta de alternativa> ::= &lab;expresión simple> | &lab;texto informal>

Toda &lab;expresión fundamental> en &lab;respuesta> tiene que ser una &lab;expresión simple>. Las &lab;respuesta>s en una &lab;opción de transición> tienen que ser mutuamente exclusivas. Si la &lab;pregunta de alternativa> es una &lab;expresión>, la condición-de-intervalo de las &lab;respuesta>s tienen que ser del mismo género que el de la &lab;pregunta de alternativa>.

Gramática gráfica concreta

&lab;área de opción de transición> ::= &lab;símbolo de opción de transición> contains {&lab;pregunta de alternativa>} is followed by {&lab;opción acceso de salida 1> {&lab;opción acceso de salida 1>|&lab;opción acceso de salida 2>} {&lab;opción de acceso de salida 1>}* } set

&lab;símbolo de opción de transición> ::=

Figure omitted: 04 Figure du 4.3.4 Figure du 4.3.4 , (N), p. &lab;opción acceso de salida 1> ::= &lab;símbolo de línea de flujo> is associated with &lab;respuesta gráfica> is followed by &lab;área de transición>

&lab;opción acceso de salida 2> ::= &lab;símbolo de línea de flujo> is associated with ELSE is followed by &lab;área de transición>

El &lab;símbolo de línea de flujo> en &lab;opción acceso de salida 1> y &lab;opción acceso de salida 2> está conectado a la parte inferior del &lab;símbolo de opción de transición>. Los &lab;símbolo de línea de flujo>s que salen de un &lab;símbolo de opción de transición> pueden tener un trayecto de origen común. La &lab;respuesta gráfica> y ELSE pueden colocarse a lo largo del &lab;símbolo de línea de flujo> asociado, o en el &lab;símbolo de línea de flujo> interrumpido.

Las &lab;respuesta gráfica>s en un <área de opción de transición> tienen que ser mutuamente exclusivas.

Semántica

Se seleccionan construcciones en una &lab;opción acceso de salida 1> si la &lab;respuesta> contiene el valor de la &lab;pregunta de alternativa>. Si ninguna de las &lab;respuesta>s contiene el valor de la &lab;pregunta de alternativa>, se seleccionan las construcciones en la &lab;opción acceso de salida 2>.

Si no existe una &lab;opción acceso de salida 2> y no se selecciona ninguno de los trayectos salientes, la selección es inválida.

Modelo

En una transformación, la &lab;opción de transición> y el <área de opción de transición> se remplazan por las construcciones seleccionadas contenidas.

Ejemplo

A continuación se presenta un fragmento de una &lab;definición de proceso> que contiene una &lab;opción de transición>. p y s son sinónimos.

............ ALTERNATIVE p + s; (>2) : TASK `Haga lo que quiera`; NEXTSTATE -; ELSE: TASK `No haga nada`; NEXTSTATE Hum; ENDALTERNATIVE; ............

Seguidamente se presenta el mismo ejemplo en sintaxis gráfica concreta.

Figure omitted: 19 Figure du 4.3.4 Figure du 4.3.4 , (N), p.

Gramática textual concreta

&lab;descomposición de servicio> ::= {&lab;definición de ruta de señales de servicio> | &lab;conexión de ruta de señales> | &lab;definición de servicio> | &lab;definición de seleccionar> | &lab;referencia textual de servicio>}+

&lab;definición de ruta de señales de servicio> ::= SIGNALROUTE &lab;nombre de ruta de señales de servicio > &lab;trayecto de ruta de señales de servicio> [&lab;trayecto de ruta de señales de servicio>]

&lab;trayecto de ruta de señales de servicio> ::= {FROM &lab;identificador de servicio > TO &lab;identificador de servicio > | FROM &lab;identificador de servicio > TO ENV | FROM ENV TO &lab;identificador de servicio >} WITH &lab;lista de señales> &lab;fin>

&lab;conexión de ruta de señales> ::= CONNECT &lab;identificador de ruta de señales> AND &lab;identificador de ruta de señales de servicio > {,&lab;identificador de ruta de señales de servicio >}* &lab;fin>

&lab;referencia textual de servicio> ::= SERVICE &lab;nombre de servicio > REFERENCED &lab;fin>

Cuando una &lab;definición de proceso> contiene una &lab;descomposición de servicio>, no podrá contener &lab;definición de temporizador>s fuera de la &lab;descomposición de servicio>.

Una &lab;descomposición de servicio> debe contener al menos una &lab;definición de servicio>.

Para &lab;ruta de señales de servicio> se aplican reglas de formación correcta similares a las de &lab;ruta de señales>.

Gramática gráfica concreta

&lab;área de interacción de servicios> ::= { <área de servicio> | <área de definición de ruta de señales de servicio> }+

&lab;área de servicio> ::= &lab;referencia gráfica de servicio> | &lab;diagrama de servicio>

&lab;referencia gráfica de servicio> ::= &lab;símbolo de servicio> contains &lab;nombre de servicio >

&lab;símbolo de servicio> ::=

Figure omitted: 04 Figure du 4.10.1 Figure du 4.10.1 , (N), p. &lab;área de definición de ruta de señales de servicio> ::= &lab;símbolo de ruta de señales> is associated with {&lab;nombre de ruta de señales de servicio > [&lab;identificador de ruta de señales >] {tps.non.photo "["}<área de lista de señales> [<área de lista de señales>] } set is connected to {<área de servicio> {<área de servicio> | &lab;símbolo de casilla>} } set

Cuando el &lab;símbolo de ruta de señales> se conecta al &lab;símbolo de casilla>, el &lab;identificador de ruta de señales > identifica una ruta de señales externa a la cual está conectada la ruta de señales.

Semántica

La &lab;descomposición de servicio> es una alternativa al &lab;cuerpo de proceso>, y expresa el mismo comportamiento.

Modelo

El concepto de servicio se modela transformando la &lab;descomposición de servicio> en conceptos primitivos. La transformación de &lab;definición de ruta de señales de servicio>s y &lab;conexión de ruta de señales>s no produce ningún resultado.

Gramática textual concreta

&lab;definición de servicio> ::= SERVICE {&lab;nombre de servicio > | &lab;identificador de servicio >} &lab;fin> [&lab;conjunto de señales de entrada válidas>] {&lab;definición de variable> | &lab;definición de datos> | &lab;definición de temporizador> | &lab;definición de visión> | &lab;definición de importación> | &lab;definición de seleccionar> | &lab;definición de macro> | &lab;definición de procedimiento> | &lab;referencia textual de procedimiento>}* &lab;cuerpo de servicio> ENDSERVICE [{&lab;nombre de servicio > | &lab;identificador de servicio >}] &lab;fin>

&lab;cuerpo de servicio> ::= &lab;cuerpo de proceso>

&lab;entrada prioritaria> ::= PRIORITY INPUT &lab;lista de entradas prioritarias> &lab;fin> &lab;transición>

&lab;lista de entradas prioritarias> ::= &lab;estímulo prioritario> {, &lab;estímulo prioritario>}*

&lab;estímulo prioritario> ::= &lab;identificador de señal prioritaria [ ( [&lab;identificador de variable >] {, [&lab;identificador de variable >] }* ) ]

&lab;salida prioritaria> ::= PRIORITY OUTPUT &lab;cuerpo de salida prioritaria>

&lab;cuerpo de salida prioritaria> ::= &lab;identificador de señal prioritaria > [&lab;parámetros efectivos>] {, &lab;identificador de señal prioritaria > [&lab;parámetros efectivos>]}*

Una señal es una señal de alta prioridad en un proceso únicamente si está mencionada en una &lab;entrada prioritaria> de una &lab;definición de servicio> en ese proceso.

Una &lab;definición de variable> en una &lab;definición de servicio> no podrá contener las palabras clave EXPORTED ni REVEALED.

Un &lab;identificador de señal prioritaria > en una &lab;salida prioritaria> no podrá estar contenido en una &lab;parte entrada> ni en una &lab;parte conservación>. Un &lab;identificador de señal prioritaria > en una &lab;entrada prioritaria> no podrá estar contenido en una &lab;salida>.

Se aplica la misma regla sobre conjunto de señales de entrada válidas y ruta de señales de servicio enunciada en 2.5.2 en relación con los procesos.

La &lab;descomposición de servicio> puede contener &lab;definición de ruta de señales de servicio>s sólo si la &lab;definición de bloque> envolvente contiene &lab;definición de ruta de señales>s.

Sólo una de las &lab;definición de servicio>s en una &lab;descomposición de servicio> está autorizada para tener un &lab;arranque> que contenga una &lab;cadena de transición>. Todos los demás &lab;arranque>s deben contener únicamente &lab;estado siguiente>.

Los conjuntos completos de señales de entrada válidas (siendo cada uno de dichos conjuntos la unión del &lab;conjunto de señales de entrada válidas> y del conjunto de señales transportadas en &lab;ruta de señal de servicio>s entrantes de una &lab;definición de servicio>) de las &lab;definición de servicio>s dentro de una &lab;definición de proceso> deben ser disjuntos.

Una &lab;definición de procedimiento> no debe tener &lab;estado>s cuando la &lab;definición de proceso> que la encierra contiene una &lab;definición de servicio>. Las &lab;definición de procedimiento>s visibles para más de un servicio no deben contener una construcción VIA.

El conjunto de prioridades asociadas a &lab;señal continua>s dentro de las diversas &lab;definición de servicio>s de una &lab;descomposición de servicio> no deben superponerse.

Reglas similares de formación correcta son aplicables a &lab;conexión de ruta de señales> y a &lab;conexión de canal a ruta>.

Si la &lab;descomposición de servicio> envolvente contiene algunas &lab;definición de ruta de señales de servicio>s, para cada &lab;identificador de ruta de señales > de una &lab;salida>, debe existir una ruta de señales de servicio procedente del servicio envolvente y conectada a la ruta de señales, que pueda transportar las señales denotadas mediante los &lab;identificador de señal >s contenidos en la &lab;salida>.

Si una &lab;salida> no incluye una construcción VIA, debe existir al menos un trayecto de comunicación [implícito en el propio servicio o vía rutas de señales de servicio (posiblemente implícitas), y posiblemente, rutas de señales y canales] procedente del servicio, que pueda transportar las señales denotadas mediante los &lab;identificador de señal >s contenidas en la &lab;salida>.

Para cada &lab;salida prioritaria> debe existir al menos un trayecto de comunicación [implícito en el propio servicio o vía [rutas de señales de servicio (posiblemente implícitas)] procedente del servicio, que pueda transportar las señales denotadas mediante los &lab;identificador de señal de prioridad >s contenidos en la &lab;salida prioritaria>.

&lab;entrada de prioritaria> sólo está permitida en un &lab;cuerpo de servicio>. &lab;salida prioritaria> sólo está permitida en un &lab;cuerpo de servicio> y en &lab;cuerpo de procedimiento>.

Gramática gráfica concreta

&lab;diagrama de servicio> ::= &lab;símbolo de casilla> contains {&lab;encabezamiento de servicio> {tps.non.photo "{"}{ {<área de texto de servicio> }* {&lab;referencia gráfica de procedimiento>}* {&lab;diagrama de procedimiento>}* {&lab;diagrama de macro>}* &lab;área de gráfico de servicio> } set }

&lab;encabezamiento de servicio> ::= SERVICE {&lab;nombre de servicio > | &lab;identificador de servicio >}

&lab;área de texto de servicio> ::= &lab;símbolo de texto> contains { &lab;definición de variable> | &lab;definición de datos> | &lab;definición de temporizador> | &lab;definición de visión> | &lab;definición de importación> | &lab;definición de seleccionar> | &lab;definición de macro> }*

&lab;área de gráfico de servicio> ::= &lab;área de gráfico de proceso>

&lab;área de asociación de entrada prioritaria> ::= &lab;símbolo de asociación de trazo continuo> is connected to &lab;área de entrada prioritaria>

&lab;área de entrada prioritaria> ::= &lab;símbolo de entrada prioritaria> contains &lab;lista de entradas prioritarias> is followed by &lab;área de transición>

&lab;símbolo de entrada prioritaria> ::=

Figure omitted: 03 Figure du 4.10.2 Figure du 4.10.2 , (N), p. &lab;área de salida prioritaria> ::= &lab;símbolo de salida prioritaria> contains &lab;cuerpo de salida prioritaria>

&lab;símbolo de salida prioritaria> ::=

Figure omitted: 04 Figure du 4.10.2 Figure du 4.10.2 , (N), p. Semántica

Las propiedades de un servicio se derivan de la exigencia de que la &lab;descomposición de servicio> que remplaza un &lab;cuerpo de proceso> exprese el mismo comportamiento que el &lab;cuerpo de proceso>.

Dentro de una instancia de proceso hay una instancia de servicio para cada &lab;definición de servicio> en la &lab;definición de proceso>. Las instancias de servicio son componentes de la instancia de proceso y no pueden ser manipuladas (creadas, direccionadas, ni abortadas) como objetos separados. Estas instancias de servicio comparten el puerto de entrada y las expresiones SELF, PARENT, OFFSPRING y SENDER de la instancia de proceso.

Una instancia de servicio es una máquina de estados finitos, pero no puede funcionar en paralelo con otras instancias de servicio de la instancia de proceso; es decir, dentro de una instancia de proceso sólo una instancia de servicio puede efectuar una transición en un instante dado.

En &lab;cuerpo de salida prioritaria>, la construcción TO SELF está implícita. Las señales prioritarias son una clase especial de señales que tienen una prioridad superior a la de las ordinarias. Estas señales sólo pueden enviarse entre instancias de servicio dentro de la misma instancia de proceso.

A la instancia de servicio que es capaz de recibir esa señal se le da una señal de entrada desde el puerto de entrada.

Modelo

a) Transformación de definiciones

Las definiciones locales dentro de una &lab;definición de servicio> se transforman al nivel de proceso remplazando cada ocurrencia de un nombre en el servicio por el mismo nombre nuevo distinto. Todas las referencias a servicios en calificadores desaparecen. Las definiciones de visión o las definiciones de importación que contienen la misma variable de visión o importación se fusionan en una sola definición de visión o importación.

b) Transformación de &lab;cuerpo de servicio>s

Un conjunto de &lab;cuerpo de servicio>s se transforma en un &lab;cuerpo de proceso>. Esto puede hacerse de varias maneras. Aquí se ha elegido una transformación simple, pues el objetivo principal es definir el concepto de servicio por una sintaxis concreta estricta. Por razones prácticas un &lab;cuerpo de servicio> y un &lab;cuerpo de proceso> se consideran como un gráfico compuesto de estados, cadenas de transición entre estados, cadenas de transición de parada y una cadena de transición de arranque. Una cadena de transición se define unívocamente por un estado de arranque, una entrada y un estado de fin.

1) Estados

Un estado en el gráfico de proceso resultante se identifica por una tupla de nombres. La dimensión de la tupla es el número de gráficos de servicio. Cada componente de una tupla se refiere unívocamente a uno de los gráficos de servicio originales, y el valor del componente de la tupla es uno de los nombres de estado del gráfico de servicio referido. Los nombres de estado del gráfico de proceso serán entonces el conjunto de tuplas que es posible construir utilizando estas reglas. Ejemplo:

Dado dos gráficos de servicio y sus estados

f1: &lab;a> &lab;b> f2: &lab;A> &lab;B> &lab;C>

el gráfico de proceso tiene los siguientes estados

&lab;a.A> &lab;a.B> &lab;a.C> &lab;b.A> &lab;b.B> &lab;b.C>

Normalmente, esta explosión de estados puede reducirse sustancialmente, pero esto no se trata aquí.

2) Cadenas de transición

Cada cadena de transición en un gráfico de servicio se copia en el gráfico de proceso en uno o más lugares. Esto se efectúa para conectar cada par de tuplas de estado que satisface las siguientes condiciones: - Un componente de la tupla de estado de arranque se refiere al estado de arranque de la cadena de transición - Un componente de la tupla de estado de fin se refiere al estado de fin de la cadena de transición - Los otros valores componentes deben ser iguales para las dos tuplas de estado

Ejemplo:

En el ejemplo precedente tenemos una cadena de transición en f2 entre &lab;B> y &lab;C>. En el gráfico de proceso resultante, esta cadena de transición conectará &lab;a.B> con &lab;a.C> y &lab;b.B> con &lab;b.C>. Esto puede expresarse de una manera concisa (utilizando la notación taquigráfica de la sintaxis concreta):

&lab;*.B> se transforma en <-.C>

3) Cadenas de transición de arranque

Si uno de los gráficos de servicio contiene una cadena de transición de arranque, esta cadena de transición se transforma en la cadena de transición de arranque del gráfico de proceso. La cadena de transición de arranque del gráfico de proceso conduce a la tupla de estado que tiene como componentes todos los nombres de estado inicial del gráfico de servicio.

4) Cadenas de transición de parada

Cada transición que conduce a una &lab;parada> es copiada en el gráfico de proceso y conectada a cada tupla de estado que tiene un componente que se refiere al estado de arranque de la transición.

5) Señales prioritarias

Las señales prioritarias se transforman como sigue.

Cada estado del gráfico de proceso resultante se divide en dos estados. Las entradas prioritarias en el estado original se conectan al primer estado, todas las otras entradas son conectadas al segundo estado y conservadas en el primer estado. La cadena de transición conducente al estado original conduce ahora al primer estado. A esta cadena de transición se añade la siguiente cadena de acción:

- se genera un valor de testigo único y se asigna a la variable implícita SAME$$-TOKEN - se envía a SELF la señal implícita X$$-CONT, que transporta el valor de testigo.

Una entrada para la señal implícita X$$-CONT se añade al primer estado, seguida de la siguiente cadena de transición: - Una decisión compara el valor de testigo recibido con el valor de SAME$$-TOKEN. Si los valores son iguales, se elige un trayecto que conduce al segundo estado; en el caso contrario, una parte que retorna al primer estado.

Ejemplo

A continuación se presenta un ejemplo de una &lab;definición de proceso> que contiene una &lab;descomposición de servicio>, así como las &lab;definición de servicio>s correspondientes. Este proceso tiene el mismo comportamiento que el indicado en la figura 2.9.9, en el 2.9 .

PROCESS Game; FPAR Player pid; SIGNAL Proberers (integer); DCL A integer;

SIGNALROUTE IR1 FROM Game$$-handler TO ENV WITH Score,Gameid; SIGNALROUTE IR2 FROM Game$$-handler TO ENV WITH Subscr,Endsubscr; SIGNALROUTE IR3 FROM ENV TO Game$$-handler WITH Result,Endgame; SIGNALROUTE IR4 FROM ENV TO Bump$$-handler WITH Probe; SIGNALROUTE IR5 FROM ENV TO Bump$$-handler WITH Bump; SIGNALROUTE IR6 FROM Bump$$-handler TO ENV WITH Lose,Win; SIGNALROUTE IR7 FROM Bump$$-handler TO Game$$-handler WITH proberers;

CONNECT R5 AND IR5; CONNECT R2 AND IR3,IR4; CONNECT R3 AND IR1,IR6; CONNECT R4 AND IR2;

SERVICE Game$$-handler REFERENCED; SERVICE Bump$$-handler REFERENCED;

ENDPROCESS Game;

Figure omitted: 10 blanc SERVICE Game$$-handler;

/*El servicio controla el desarrollo de un juego con acciones para comenzar un juego, terminar un juego, llevar la cuenta (score) y darla*/

DCL Count integer; /*Contador para llevar el score*/

START; OUTPUT Subscr; OUTPUT Gameid TO Player; TASK Count:=0; NEXTSTATE STARTED; STATE STARTED; PRIORITY INPUT Proberers(A); TASK Count:=Count+A; NEXTSTATE$$-; INPUT Result; OUTPUT Score(Count) TO Player; NEXTSTATE$$-; INPUT Endgame; OUTPUT Endsubscr; STOP; ENDSTATE STARTED; ENDSERVICE Game$$-handler;

SERVICE Bump$$-handler;

/*El servicio tiene acciones para registrar los "bumps" y para tratar sondas del jugador (player). El resultado de la sonda se comunica al jugador, y también al servicio `Game$$-handler` (controlador del juego)*/

START; NEXTSTATE EVEN; STATE EVEN; INPUT Probe; OUTPUT Lose TO Player; PRIORITY OUTPUT Proberers(-1); NEXTSTATE$$-; INPUT Bump; NEXTSTATE ODD; ENDSTATE EVEN; STATE ODD; INPUT Bump; NEXTSTATE EVEN; INPUT Probe; OUTPUT Win TO Player; PRIORITY OUTPUT Proberers(+1); NEXTSTATE$$-; ENDSTATE ODD; ENDSERVICE Bump$$-handler;

Figure omitted: 10 blanc En los diagramas siguientes se presenta el mismo ejemplo en LED/GR:

Figure omitted: 25 Figure 4.10.1 Figure 4.10.1, (N), p. Figure omitted: 20 blanc Figure omitted: 42 Figure 4.10.2 Figure 4.10.2, (N), p. Figure omitted: 3 blanc Figure omitted: 46 Figura 4.10.3 Figura 4.10.3, (N), p. Aplicando las reglas 1 a 4 de la transformación se obtiene el gráfico de proceso de la figura 4.10.4; este gráfico contiene señales prioritarias aún no transformadas. Simplificando de una manera obvia las transiciones que contienen señales prioritarias y usando el concepto de estado asterisco se puede obtener el mismo proceso de la figura 2.9.10 ( 2.9 ). (Obsérvese que los estados EVEN y ODD corresponden respectivamente a los estados STARTED.EVEN y STARTED.ODD.)

Figure omitted: 53 Figura 4.10.4 Figura 4.10.4, (N), p.

Todos los datos utilizados en LED se basan en tipos abstractos de datos que se definen en términos de sus propiedades abstractas más bien que en términos de alguna realización concreta. Ejemplos de definición de tipos abstractos de datos se presentan en 5.6 , que define las facilidades predefinidas de datos del lenguaje.

Aunque todos estos tipos de datos son abstractos, y las facilidades predefinidas de datos pueden ser contraordenadas por el usuario, LED intenta proporcionar un conjunto de facilidades predefinidas de datos que son familiares tanto en su comportamiento como en su sintaxis. Están predefinidos:

a) Booleano (Boolean)

b) Carácter (Character)

c) Cadena (String)

d) Cadena-de-caracteres (Charstring)

e) Entero (Integer)

f) Natural

g) Real

h) Matriz (Array)

i) Conjuntista (Powerset)

j) PId

k) Duración (Duration)

l) Tiempo (Time).

El concepto de género estructurado (STRUCT) puede utilizarse para formar objetos compuestos.

Los datos se modelan por un álgebra inicial. El álgebra tiene géneros designados y un conjunto de operadores que establecen relaciones de correspondencia entre los géneros. Cada género es la colección de todos los valores posibles que pueden ser generados por el conjunto conexo de operadores. Cada valor puede denotarse por al menos una expresión en el lenguaje que contiene solamente literales y operadores (salvo el caso especial de los valores de PId). Los literales constituyen un caso especial de operadores sin argumentos.

Los géneros y operadores, junto con el comportamiento (especificado por reglas algebraicas) del tipo de datos, forman las propiedades del tipo de datos. Un tipo de datos es introducido en cierto número de definiciones parciales de tipo, cada una de las cuales define un género y operadores, así como reglas algebraicas asociadas con ese género.

La palabra clave NEWTYPE introduce una definición parcial de tipo que define un género nuevo distinto. Se puede crear un género con propiedades heredadas de otro género, pero con identificadores diferentes para el género y los operadores.

La introducción de un sintipo nomina un subconjunto de los valores de un género ya existente.

Un generador es una descripción NEWTYPE incompleta: antes de que asuma la condición de género, debe ser instanciado proporcionando la información que falta.

Algunos operadores tienen una relación de correspondencia con el género, produciendo así valores (posiblemente nuevos) del género. Otros operadores dan significado al género mediante una relación de correspondencia con otros géneros definidos. Muchos operadores tienen una relación de correspondencia con el género booleano a partir de otros géneros, pero está estrictamente prohibido que estos operadores amplíen el género booleano.

En LED, una función es conocida como un operador pasivo y no puede producir efecto sobre los valores asociados con variables dadas como parámetros. LED define también la asignación, que puede cambiar los valores asociados con variables.

La terminología utilizada en 5 o el modelo de datos se eligen de modo que estén en armonía con los trabajos publicados sobre álgebras iniciales. En particular, `tipo de datos' , se utiliza para hacer referencia a una colección de géneros más una colección de operadores asociados con estos géneros y la definición de las propiedades de estos géneros y operadores por ecuaciones algebraicas. Un `género' es un conjunto de valores con características comunes. Un `operador' es una relación entre géneros. Una `ecuación' es una definición de equivalencia entre términos de un género. Un valor es un conjunto de términos equivalentes. Un `axioma' es una ecuación que define un valor booleano como equivalente a Verdadero. Sin embargo, `axiomas' se utiliza como un término que designa `axioma' (s) o `ecuación' (es), y una `ecuación' puede ser un `axioma' .

El modelo de álgebra inicial utilizado para datos en LED se describe en una forma que permite definir la mayor parte de los conceptos de datos en términos de un núcleo (kernel) de datos del lenguaje abstracto de datos LED.

El texto de 5 se divide en esta introducción ( 5.1 ), el lenguaje núcleo de datos ( 5.2 ), el modelo de álgebra inicial ( 5.3 ), el uso pasivo de datos ( 5.4 ), el uso activo de datos ( 5.5 ) y los datos predefinidos ( 5.6 ).

El lenguaje núcleo de datos define la parte de datos en LED que corresponde directamente con el método de álgebra inicial subyacente.

El texto sobre álgebra inicial da una introducción más detallada a la base matemática de este método. Una formulación matemática más precisa se presenta en apéndice I.

El uso pasivo de LED incluye las características implícitas y taquigráficas de datos LED que permiten su uso para la definición de tipos abstractos de datos. Incluye también la interpretación de expresiones que no contienen valores asignados a variables. Estas expresiones `pasivas' corresponden a un uso funcional del lenguaje.

El uso activo de datos amplía el lenguaje de modo que incluye asignación. Esto a su vez incluye asignación a, uso de, e inicialización de variables. Cuando LED se utiliza para asignar valores a variables o acceder a valores de variables, se dice que se utiliza activamente. La diferencia entre expresiones activas y pasivas es que el valor de una expresión pasiva es independiente del momento en que se efectúa su interpretación, en tanto que la interpretación de una expresión activa puede dar valores diferentes según los valores asociados con las variables o el estado del sistema en cada instante.

La sección final trata de los datos predefinidos.

En un punto cualquiera de una especificación LED hay una definición aplicable de tipo de datos. La definición de tipo de datos define la validez de expresiones y la relación entre expresiones. La definición introduce operadores y conjuntos de valores (géneros).

No hay una correspondencia simple entre la sintaxis concreta y la abstracta para definiciones de tipos de datos pues la sintaxis concreta introduce incrementalmente la definición de tipo de datos con énfasis en los géneros (véase también 5.3 ).

Las definiciones en la sintaxis concreta son a menudo independientes y no pueden dividirse en unidades de ámbito diferentes. Por ejemplo:

NEWTYPE even LITERALS 0; OPERATORS plusee : even, even -> even; plosoo : odd, odd -> even; AXIOMS plusee(a,0)) ==a; plusee(a,b) ==plusee(b,a); plusoo(a,b) ==plusoo(b,a); ENDNEWTYPE even COMMENT `"números" pares con plus-depende de impar`; NEWTYPE odd LITERALS 1; OPERATORS plusoe : odd, even -> odd; pluseo : even, odd -> odd; AXIOMS plusoe(a,0) ==a; pluseo(a,b) ==plusoe(b,a); ENDNEWTYPE odd; /* `números' impares con plus-depende de par*/

Cada definición de tipo de datos es una definición completa. No hay referencias a géneros u operadores que no estén incluidos en la definición de tipo de datos que se aplica en un punto dado. Asimismo, una definición de tipo de datos no podrá invalidar la semántica de una definición de tipo de datos en la unidad de ámbito inmediatamente circundante. Un tipo de datos en una unidad de ámbito encerrada sólo enriquece operadores de géneros definidos en la unidad de ámbito exterior. Un valor de un género definido en una unidad de ámbito puede utilizarse libremente y pasarse entre unidades de ámbito jerárquicamente inferiores o a partir de estas unidades. Puesto que los datos predefinidos están definidos a nivel de sistema, los géneros predefinidos (por ejemplo booleano y entero) pueden utilizarse libremente en todo el sistema.

Gramática abstracta

Definición-de-tipo-de-datos :: Nombre-de-tipo Unión-de-tipo Géneros Signatura - set Ecuaciones

Unión-de-tipo = Identificador-de-tipo - set

Identificador-de-tipo = Identificador

Géneros = Nombre-de-género - set

Nombre-de-tipo = Nombre

Nombre-de-género = Nombre

Ecuaciones = Ecuación - set

Dentro de una definición-de-tipo-de-datos , para cada género tiene que haber al menos una signatura con un resultado (véase 5.2.2 ) que es el mismo que el género .

Una definición-de-tipo-de-datos ^ no agregará nuevos valores a ningún género del tipo de datos identificado por la unión-de-tipo .

Si un término ^ (véase 5.2.3 ) es inequivalente a otro término ^ de acuerdo con el tipo de datos identificado por la unión-de-tipo de una definición-de-tipo-de-datos , estos términos no serán definidos como equivalentes por la definición-de-tipo-de-datos .

Además, los dos términos booleanos Verdadero y Falso no pueden estar definidos (directa ni indirectamente) como equivalentes (véase 5.4.3.1 ). Tampoco está permitido reducir el número de valores para el género predefinido PId.

Nota - La sintaxis abstracta permite más de una identidad de tipo para una unión-de-tipo , a fin de asegurar la armonía con la clase más general de álgebras utilizadas para el modelo subyacente - en LED sólo se hace referencia a un tipo, porque en la sintaxis concreta el tipo de datos visible etá implícitamente definido por la &lab;clase de unidad de ámbito> circundante; por tanto &lab;unión de tipo> sólo está referenciada en la sintaxis abstracta y es, bien el identificador-de-tipo de la unidad de ámbito circundante, bien, en el caso de una &lab;definición de sistema>, un conjunto vacío.

Gramática textual concreta

&lab;definición parcial de tipo>::= NEWTYPE &lab;nombre de género > [ &lab;propiedades ampliadas> ] &lab;expresión de propiedades>

ENDNEWTYPE [ &lab;nombre de género > ]

&lab;expresión de propiedades>::= &lab;operadores> [AXIOMS &lab;axiomas> ] [ &lab;correspondencia de literales> ] [ &lab;asignación por defecto> ]

Las &lab;propiedades ampliadas>, &lab;correspondencia de literales> y &lab;asignación por defecto> facultativas no forman parte del núcleo de datos y se definen en 5.4.1 , 5.4.1.15 y 5.5.3.3 respectivamente.

La definición-de-tipo-de-datos ^ se representa por la colección de todas las &lab;definición parcial de tipo>s en la &lab;clase de unidad de ámbito> vigente combinada con la definición-de-tipo-de-datos identificada por la unión-de-tipo de la &lab;clase de unidad de ámbito> circundante. El nombre de tipo de una &lab;definición de tipo de datos> es implícito y no tiene una representación en sintaxis concreta. El identificador-de-tipo de una unión-de-tipo es, implícitamente, la identidad de la definición-de-tipo-de-datos de la unidad de ámbito circundante.

Cada una de las siguientes &lab;clase de unidad de ámbito>s (véase 2.2.2 ) representa un ítem en la sintaxis abstracta que contiene una definición-de-tipo-de-datos : &lab;definición de sistema>, &lab;definición de bloque>, &lab;definición de proceso>, &lab;definición de procedimiento>, &lab;definición de subestructura de canal> o &lab;definición de subestructura de bloque> o los diagramas correspondientes en sintaxis gráfica. La &lab;definición parcial de tipo> en una &lab;definición de servicio> representa parte de la definición-de-tipo-de-datos en la &lab;definición de proceso> circundante de la &lab;definición de servicio> (véase 4.10 ).

Para una &lab;clase de unidad de ámbito>, los géneros ^ se representan por el conjunto de &lab;nombre de género>s introducido por el conjunto de &lab;definición parcial de tipo>s de la &lab;clase de unidad de ámbito>.

Para una &lab;clase de unidad de ámbito>, el conjunto signatura ^ y las ecuaciones ^ se representan por las &lab;expresión de propiedades>s de las &lab;definición parcial de tipo>s de la &lab;clase de unidad de ámbito>.

Los &lab;operadores> de una &lab;expresión de propiedades> representan parte del conjunto signatura ^ en la sintaxis abstracta. El conjunto signatura completo es la unión de los conjuntos signatura definidos por las &lab;definición parcial de tipo>s en la &lab;clase de unidad de ámbito>.

Los &lab;axiomas> de una &lab;expresión de propiedades> representan parte del conjunto ecuación ^ en la sintaxis abstracta. Las ecuaciones son la unión de los conjuntos ecuación definidos por las &lab;definición parcial de tipo>s en la &lab;clase de unidad de ámbito>.

Los géneros de datos predefinidos tienen sus &lab;definición parcial de tipo>s implícitas en el nivel de sistema.

Si un &lab;nombre de género > se da después de la palabra clave ENDNEWTYPE, debe ser el mismo que el &lab;nombre de género > dado después de la palabra clave NEWTYPE.

Semántica

La definición de tipo de datos define un tipo de datos. Un tipo de datos tiene un conjunto de propiedades de tipo, es decir: un conjunto de géneros, un conjunto de operadores y un conjunto de ecuaciones.

Las propiedades de tipos de datos se definen en la sintaxis concreta mediante definiciones parciales de tipo. Una definición parcial de tipo no introduce todas las propiedades de un tipo de datos sino, solamente, define parcialmente algunas de las propiedades relacionadas con el género introducido en la definición parcial de tipo. Las propiedades completas de un tipo de datos se hallan examinando la combinación de todas las definiciones parciales de tipo que se aplican dentro de la unidad de ámbito que contiene la definición de tipo de datos.

Un género es un conjunto de valores de datos. Dos géneros diferentes no tienen valores en común.

La definición de tipo de datos se forma a partir de la definición de tipo de datos de la unidad de ámbito que define la unidad de ámbito vigente tomada conjuntamente con los géneros, operadores y ecuaciones definidos en la unidad de ámbito vigente. La definición de sistema contiene la definición de los géneros de datos predefinidos.

Salvo dentro de una &lab;definición parcial de tipo>, un &lab;refinamiento de señal> o una &lab;definición de servicio>, la definición de tipo de datos que se aplica en cualquier punto es el tipo de datos definido para la unidad de ámbito que circunda inmediatamente ese punto. Dentro de una &lab;definición parcial de tipo> o un &lab;refinamiento de señal>, la definición de tipo de datos que se aplica es la definición de tipo de datos de la unidad de ámbito que circunda a la &lab;definición parcial de tipo> o &lab;refinamiento de señal> respectivamente. Dentro de una &lab;definición de servicio> es la definición-de-tipo-de-datos de la &lab;definición de proceso> circundante de la &lab;definición de servicio> la que se aplica (véase 4.10 ).

El conjunto de géneros de un tipo de datos es el conjunto de géneros introducido en la unidad de ámbito vigente más el conjunto de géneros del tipo de datos identificado por la unión de tipo. El conjunto de operadores de un tipo de datos es el conjunto de operadores introducidos en la unidad de ámbito vigente más el conjunto de operadores del tipo de datos identificado por la unión de tipo. El conjunto de ecuaciones de un tipo de datos es el conjunto de ecuaciones introducido en la unidad de ámbito vigente más el conjunto de ecuaciones del tipo de datos identificado por la unión de tipo.

Cada género introducido en una definición de tipo de datos tiene un identificador que es el nombre introducido por una definición parcial de tipo en la unidad de ámbito calificada por el identificador de la unidad de ámbito.

Un tipo de datos tiene un identificador que es el nombre de tipo único en la sintaxis abstracta calificado por la identidad de la unidad de ámbito. En la sintaxis concreta no hay nombre para un tipo de datos.

Ejemplo

NEWTYPE teléfono /*los operadores y la construcción de valores se definen en otro lugar*/ ENDNEWTYPE teléfono;

Gramática abstracta

Signatura = Signatura-de-literal | Signatura-de-operador

Signatura-de-literal :: Nombre-de-operador-literal Resultado

Signatura-de-operador :: Nombre-de-operador Lista-de-argumentos Resultado

Lista-de-argumentos = Identificador-de-referencia-de-género +

Resultado = Identificador-de-referencia-de-género

Identificador-de-referencia-de-género = Identificador-de-género | Identificador-de-sintipo

Nombre-de-operador-literal = Nombre

Nombre-de-operador = Nombre

Identificador-de-género = Identificador

Los sintipos e identificadores de sintipo no forman parte del núcleo (véase 5.4.1.9 ).

Gramática textual concreta

&lab;operadores>::= [ &lab;lista de literales> ] [ &lab;lista de operadores> ]

&lab;lista de literales>::= LITERALS &lab;signatura de literal> {, &lab;signatura de literal> }* [ &lab;fin> ]

&lab;signatura de literal>::= &lab;nombre de operador literal > | &lab;nombre literal ampliado>

&lab;lista de operadores>::= OPERATORS &lab;signatura de operador> { &lab;fin> &lab;signatura de operador> }* [ &lab;fin> ]

&lab;signatura de operador>::= &lab;nombre de operador> : &lab;lista de argumentos> -> &lab;resultado> | &lab;ordenación>

&lab;nombre de operador>::= &lab;nombre de operador > | &lab;nombre de operador ampliado>

&lab;lista de argumentos>::= &lab;género de argumento> {, &lab;género de argumento> }*

&lab;género de argumento>::= &lab;género ampliado>

&lab;resultado>::= &lab;género ampliado>

&lab;género ampliado>::= &lab;género> | &lab;género de generador>

&lab;género>::= &lab;identificador de género > | &lab;sintipo>

Las alternativas &lab;nombre de operador ampliado>, &lab;nombre de literal ampliado>, &lab;ordenación>, &lab;género de generador> y &lab;sintipo> no forman parte del núcleo de datos y se definen en 5.4.1 , 5.4.1 , 5.4.1.8 , 5.4.1.12.1 , 5.4.1.12.1 y 5.4.1.9 respectivamente.

Los literales se introducen mediante &lab;signatura de literal>s enumeradas después de la palabra clave LITERALS. El resultado de una signatura-de-literal es el género introducido por la &lab;definición parcial de tipo> que define el literal.

Cada &lab;signatura de operador> en la lista de &lab;signatura de operador>s después de la palabra clave OPERATORS representa una signatura-de-operador con un nombre-de-operador , una lista-de-argumentos y un resultado .

El &lab;nombre de operador> corresponde a un nombre-de-operador ^ en la sintaxis abstracta que es único dentro de la unidad de ámbito definidora, aunque el nombre puede no ser único en la sintaxis concreta.

El nombre-de-operador ^ o nombre-de-operador-literal ^ único en la sintaxis abstracta se deriva de:

a) el &lab;nombre de operador> (o &lab;nombre de operador literal >), más

b) la lista de identificadores de género de argumento, más

c) el identificador de género de resultado, más

d) el identificador de género de la definición parcial de tipo en que está definido el &lab;nombre de operador> (o &lab;nombre de operador literal >).

Siempre que se especifica un &lab;identificador de operador >, el nombre-de-operador ^ único en el identificador-de-operador se deriva de la misma manera con la lista de géneros de argumento y el género de resultado derivado del contexto. Dos operadores que tienen el mismo &lab;nombre> y que difieren en uno o más de los géneros de argumento o resultado, tienen nombres diferentes.

Cada &lab;género de argumento> en una &lab;lista de argumentos> representa un identificador-de-referencia-de-género en una lista-de-argumentos . Un &lab;resultado> representa el identificador-de-referencia-de-género de un resultado .

Dondequiera que un &lab;calificador> de un &lab;identificador de operador > (o &lab;identificador de operador literal >) contiene un <ítem de trayecto> con la palabra clave TYPE, el &lab;nombre de género > después de la palabra clave no forma parte del calificador del identificador-de-operador (o identificador-de-operador-literal ) pero se utiliza para derivar el nombre único del identificador . En este caso el calificador se forma a partir de la lista de <ítem de trayecto>s que precede a la palabra clave TYPE.

Semántica

Un operador es `total' , lo que significa que la aplicación del operador a cualquier lista de valores de los géneros de argumento denota un valor del género de resultado.

Una signatura de operador define cómo puede utilizarse el operador en expresiones. La signatura de operador es la identidad de operador más la lista de géneros de los argumentos y el género del resultado. La signatura de operador es la que determina si una expresión es una expresión válida en el lenguaje de acuerdo con las reglas requeridas para la comparación de los géneros de expresiones de argumento.

Un operador sin argumento se denomina un literal.

Un literal representa un valor fijo, perteneciente al género resultado del operador.

Un operador tiene un género resultado que es el género identificado por el resultado.

Nota - A título de directriz: una &lab;signatura de operador> debe mencionar el género introducido por la &lab;definición parcial de tipo> circundante bien como un &lab;argumento>, o como un &lab;resultado>.

Ejemplo 1

LITERALS libre, ocupado;

Ejemplo 2

OPERATORS estado buscar: Teléfono -> Disponibilidad;

Ejemplo 3

LITERALS lista$$-vacía OPERATORS añadir$$-a$$-la$$-lista : lista$$-de$$-teléfonos, teléfono -> lista$$-de$$-teléfonos; sublista : lista$$-de$$-teléfonos, teléfono -> lista$$-de$$-teléfonos

Los axiomas determinan qué términos representan el mismo valor. A partir de los axiomas de una definición de tipo de datos se determina la relación entre valores de argumento y valores de resultado de operadores, dando así significado a los operadores. Los axiomas se dan como axiomas booleanos o en forma de ecuaciones de equivalencia algebraica.

Gramática abstracta

Ecuación = Ecuación-incuantificada | Ecuaciones-cuantificadas | Ecuación-condicional | Texto-informal

Ecuación-incuantificada :: Término Término

Ecuaciones-cuantificadas :: Nombre-de-valor - set Identificador-de-género Ecuaciones

Nombre-de-valor = Nombre

Término = Término-fundamental | Término-compuesto | Término-de-error

Término-compuesto :: Identificador-de-valor | Término-de-identificador-de-operador + | Término-compuesto-condicional

Identificador-de-valor = Identificador

Identificador-de-operador = Identificador

Término-fundamental :: Identificador-de-operador-literal | Término-fundamental-de-identificador-de-operador + | Término-fundamental-condicional

Identificador-de-operador-literal = Identificador

Las alternativas término-compuesto-condicional ^ y término-fundamental-condicional ^ en las reglas término-compuesto y término-fundamental respectivamente no forman parte del núcleo de datos, aunque las ecuaciones que contienen estos términos pueden remplazarse por ecuaciones semánticamente equivalentes escritas en el lenguaje núcleo (véase 5.4.1.6 ). La alternativa término de error en la regla término no forma parte del núcleo de datos y se define en 5.4.1.7 .

Las definiciones de texto-informal ^ y ecuación-condicional ^ se dan en 2.2.3 y 5.2.4 respectivamente.

Cada término ^ (o término-fundamental ) en la lista de términos después de un identificador-de-operador debe tener el mismo género que el género correspondiente (por posición) en la lista-de-argumentos de la signatura-de-operador .

Los dos términos de una ecuación-incuantificada ^ tienen que ser del mismo género.

Gramática textual concreta

&lab;axiomas>::= &lab;ecuación> { &lab;fin> &lab;ecuación>}* [ &lab;fin> ]

&lab;ecuación>::= &lab;ecuación incuantificada> | &lab;ecuaciones cuantificadas> | &lab;ecuación condicional> | &lab;texto informal>

&lab;ecuaciones cuantificadas>::= &lab;cuantificación> ( &lab;axiomas> )

&lab;cuantificación>::= FOR ALL &lab;nombre de valor > {, &lab;nombre de valor > }* IN &lab;género ampliado>

&lab;ecuación incuantificada>::= &lab;término> == &lab;término> | &lab;axioma booleano>

&lab;término>::= &lab;término fundamental> | &lab;término compuesto> | &lab;término de error> | &lab;término de ortografía>

&lab;término compuesto>::= &lab;identificador de valor > | &lab;identificador de operador > ( &lab;lista de términos compuestos> ) | ( &lab;término compuesto> ) | &lab;término compuesto ampliado>

&lab;lista de términos compuestos>::= &lab;término compuesto> {, &lab;término> }* | &lab;término>, &lab;lista de términos compuestos>

&lab;término fundamental>::= &lab;identificador de literal> | &lab;identificador de operador > ( &lab;término fundamental> {, &lab;término fundamental> }*) | ( &lab;término fundamental> ) | &lab;término fundamental ampliado>

&lab;identificador de literal>::= &lab;identificador de operador literal > | &lab;identificador de literal ampliado>

Las alternativas &lab;axioma booleano> de la regla &lab;ecuación incuantificada>, &lab;término de error> y &lab;término de ortografía> de la regla &lab;término>, &lab;término compuesto ampliado> de la regla &lab;término compuesto>, &lab;término fundamental ampliado> de la regla &lab;término fundamental> e &lab;identificador de literal ampliado> de la regla &lab;identificador de literal> no forman parte del núcleo de datos y se definen en 5.4.1.5 , 5.4.1.7 , 5.4.1.15 , 5.4.1 , 5.4.1 y 5.4.1 respectivamente.

El &lab;género> en una &lab;cuantificación> representa el identificador-de-género ^ en ecuaciones-cuantificadas . Los &lab;nombre de valor >s en una &lab;cuantificación> representan el conjunto nombre-de-valor en ecuaciones-cuantificadas .

Una &lab;lista de términos compuestos> representa una lista de términos . Un identificador-de-operador seguido por una lista de términos es un término-compuesto solamente si la lista de términos contiene al menos un identificador-de-valor .

Un &lab;identificador> que es un nombre incalificado que aparece en un &lab;término> representa:

a) un identificador-de-operador ^ si precede a un paréntesis redondo de apertura (o es un &lab;nombre de operador> que es un &lab;nombre de operador ampliado> - véase 5.4.1 ); de no ser así,

b) un identificador-de-valor ^ si hay una definición de ese nombre en una &lab;cuantificación> de &lab;ecuaciones cuantificadas> que encierra el &lab;término> de un género adecuado para el contexto; de no ser así,

c) un identificador-de-operador-literal ^ si hay un literal visible con ese nombre de un género adecuado para el contexto; de no ser así,

d) un identificador-de-valor ^ que tiene una ecuación-cuantificada ^ implícita en la sintaxis abstracta para la &lab;ecuación incuantificada>.

Dos o más ocurrencias del mismo &lab;identificador de valor > no vinculado en una &lab;ecuación> implican una sola &lab;cuantificación>.

Un identificador-de-operador ^ se deriva del contexto, de modo que si el &lab;nombre de operador> está sobrecargado (es decir, si se utiliza el mismo &lab;nombre> para más de un operador), será el nombre-de-operador que identifica un operador visible con el mismo nombre y con géneros de argumento y género de resultado consistentes con la aplicación del operador. Si el &lab;nombre de operador> está sobrecargado, puede que sea necesario derivar los géneros de argumento a partir de los argumentos y el género de resultado a partir del contexto para determinar el nombre-de-operador .

Dentro de una &lab;ecuación incuantificada> tiene que haber exactamente un género para cada identificador de valor implícitamente cuantificado, que sea consistente con todos los usos.

Tiene que ser posible vincular cada &lab;identificador de operador > o &lab;identificador de operador literal > incalificado a exactamente un identificador-de-operador o identificador-de-operador-literal definido que satisfaga las condiciones en la construcción en la cual se utiliza el &lab;identificador>. Esto es: la vinculación tiene que ser única.

Nota - A título de directriz: un axioma debe ser relevante para el género de la definición parcial de tipo circundante al mencionar un operador o literal con un resultado de este género o un operador que tenga un argumento de este género; un axioma debe definirse sólo una vez.

Semántica

Cada ecuación es una sentencia sobre la equivalencia algebraica de términos. El término del lado izquierdo y el término del lado derecho se enuncian como equivalentes, de modo que cuando aparece un término puede ser sustituido por el otro. Cuando un identificador de valor aparece en una ecuación, puede ser sustituido simultáneamente en esa ecuación por el mismo término para cada ocurrencia del identificador de valor. Para esta sustitución, el término puede ser cualquier término fundamental del mismo género que el identificador de valor.

Se introducen identificadores de valor por los nombres de valor en ecuaciones cuantificadas. Un identificador de valor se utiliza para representar cualquier valor de datos que pertenezca al género de la cuantificación. Una ecuación queda satisfecha si el mismo valor remplaza simultáneamente cada ocurrencia del identificador de valor en la ecuación, independientemente del valor elegido para la sustitución.

Un término fundamental es un término que no contiene ningún identificador de valor. Un término fundamental representa un valor particular, conocido. Para cada valor en un género existe al menos un término fundamental que representa ese valor.

Si uno o más axiomas cualesquiera contienen texto informal, la interpretación de expresiones no está formalmente definida por LED pero puede ser determinada a partir del texto informal por el interpretador. Se parte del supuesto de que si se especifica texto informal, se sabe que el conjunto de ecuaciones está incompleto; por lo tanto, no se ha dado una especificación formal completa en LED.

Un nombre de valor es siempre introducido por ecuaciones cuantificadas en la sintaxis abstracta, y el valor correspondiente tiene un identificador de valor que es el nombre de valor calificado por el identificador de género de las ecuaciones cuantificadas circundantes. Por ejemplo:

FOR ALL z,z IN X ( FOR ALL z IN X ...))

introduce sólo un identificador denominado z de género X.

En la sintaxis concreta no está permitido especificar un calificador para identificadores de valor.

Cada identificador de valor introducido por ecuaciones cuantificadas tiene un género que es el identificado en las ecuaciones cuantificadas por el identificador-de-referencia-de-género . El género de las cuantificaciones implícitas es el género requerido por el contexto (o los contextos) de la ocurrencia del identificador no vinculado. Si los contextos de un identificador de valor que tiene una cuantificación implícita permiten géneros diferentes, el identificador está vinculado a un género que es consistente con todos sus usos en la ecuación.

Un término tiene un género que es el género del identificador de valor o el género resultado del operador (literal).

A menos que pueda deducirse de las ecuaciones que dos literales denotan el mismo valor, cada literal denotará un valor diferente.

Ejemplo 1

FOR ALL b IN logical (eq(b,b)==T)

Ejemplo 2

neq(T,F)==T; neq(T,T)==F;

neq(F,T)==; neq(F,F)==F;

Ejemplo 3

eq(b, b) ==T;

eq(F, eq(T,F)) ==T;

eq(eq(b,a),eq(a,b)) ==T;

Una ecuación condicional permite la especificación de ecuaciones que sólo son aplicables cuando se cumplen ciertas restricciones. Las restricciones se escriben en forma de ecuaciones simples.

Gramática abstracta

Ecuación-condicional :: Restricción - set Ecuación-restringida

Restricción = Ecuación-incuantificada

Ecuación-restringida = Ecuación-incuantificada

Gramática textual concreta

&lab;ecuación condicional>::= &lab;restricción> {, &lab;restricción> }* ==> &lab;ecuación restringida>

&lab;ecuación restringida>::= &lab;ecuación incuantificada>

&lab;restricción>::= &lab;ecuación incuantificada>

Semántica

Una ecuación restringida establece que unos términos denotan el mismo valor solamente cuando cualquier identificador de valor en las ecuaciones restringidas denota un valor con relación al cual se puede demostrar, mediante otras ecuaciones, que satisface la restricción. Un valor satisfará una restricción solamente si la restricción puede deducirse de otras ecuaciones para este valor.

La semántica de un conjunto de ecuaciones para un tipo de datos que incluye ecuaciones condicionales se deriva de la manera siguiente:

a) La cuantificación se suprime generando todas las ecuaciones de términos fundamentales que puedan derivarse de las ecuaciones cuantificadas. Como esto se aplica a la cuantificación explícita e implícita, se genera un conjunto de ecuaciones incuantificadas en términos fundamentales.

b) Se entiende por ecuación condicional comprobable una ecuación condicional para la que puede demostrarse que todas las restricciones (únicamente en términos fundamentales) se cumplen a partir de ecuaciones incuantificadas que no son ecuaciones restringidas. Si existe una ecuación condicional comprobable, se sustituye por la ecuación restringida de la ecuación condicional comprobable.

c) Si quedan ecuaciones condicionales en el conjunto de ecuaciones, y ninguna de esas ecuaciones condicionales es una ecuación condicional comprobable, se suprimen esas ecuaciones condicionales, y si no, se vuelve al paso (b).

d) El conjunto de ecuaciones incuantificadas restantes define la semántica del tipo de datos.

Ejemplo

z/=0==Verdadero==> (x/z)*z==x

El significado y la interpretación de datos basados en álgebra inicial se explica en tres etapas:

a) Signaturas

b) Términos

c) Valores

Asociados con cada género habrá uno o más operadores. Cada operador tiene una funcionalidad de operador; es decir, se define para relacionar uno o más géneros entrada con un género resultado.

Por ejemplo, se pueden añadir los siguientes operadores a los géneros definidos anteriormente:

.^.^. SORTS bool OPNS true : ->bool false : ->bool not :bool ->bool .^.^. SORTS int OPNS zero : ->int one : ->int plus : int,int ->int minus: int,int ->int .^.^. SORTS tree OPNS nil : ->tree tip : int ->tree isnil : tree ->bool istip : tree ->bool node: tree,tree ->tree sum : tree ->int .^.^.

La signatura del tipo que se aplica es el conjunto de géneros y el conjunto de operadores (tanto literales como operadores con parámetros) que son visibles.

Se dice que una signatura de un tipo está completa (cerrada) si, para cada operador de la signatura, los géneros de la funcionalidad del operador están incluidos en el conjunto de géneros del tipo.

El lenguaje de interés es el que admite expresiones que son variables, literales u operadores aplicados a expresiones. Una variable es un objeto datos que está asociado con una expresión. Una interpretación de la variable puede remplazarse por una interpretación de la expresión asociada a la variable. De esta forma pueden eliminarse variables, de modo que una interpretación de una expresión puede reducirse a la aplicación de diversos operadores a literales.

Así, al ser interpretada, una expresión abierta (una expresión que comprende variables) pasa a ser una expresión cerrada (una expresión sin variables), proporcionando a la expresión abierta argumentos efectivos (es decir, expresiones cerradas).

Una expresión cerrada corresponde a un término fundamental.

El conjunto de todos los términos fundamentales posibles de un género se denomina conjunto de términos fundamentales del género. Por ejemplo, para el género booleano, definido más arriba, el conjunto de términos fundamentales contendrá

{true, false, not(true), not(false), not(not(true)), .^.^.}

Puede verse que incluso para este género muy sencillo, el conjunto de términos fundamentales es infinito.

Cada término de un género representa un valor de ese género. De lo anterior puede verse que incluso un género simple como el booleano tiene un número infinito de términos y en consecuencia un número infinito de valores, a menos que se defina de algún modo la manera en que los términos son equivalentes (es decir, representan el mismo valor). Esta definición se da mediante ecuaciones definidas sobre términos. En ausencia de istip e isnil, el género booleano puede limitarse a dos valores mediante las ecuaciones

not(true) =false; not(false) =true

Estas ecuaciones definen términos como equivalentes y es entonces posible obtener las dos clases equivalentes de términos

{ true, not(false), not(not(true)), not(not(not(false))), .^.^.} { false, not(true ), not(not(false)), not(not(not(true ))), .^.^.}

Cada clase de equivalencia representa un valor y los miembros de la clase son representaciones diferentes del mismo valor.

Obsérvese que, a menos que se definan como equivalentes por ecuaciones, los términos son inequivalentes (es decir, no representan el mismo valor).

Un álgebra define el conjunto de términos que satisface la signatura del álgebra. Las ecuaciones del álgebra relacionan términos entre sí.

En general habrá más de una representación para cada valor de un género en un álgebra.

Un álgebra para una signatura determinada es un álgebra inicial únicamente si cualquier otra álgebra que dé las mismas propiedades para la signatura puede ser transformada sistemáticamente en el álgebra inicial. (Formalmente, tal transformación se conoce como homomorfismo.)

Si not, istip e isnil producen siempre valores en las clases de equivalencia de true (verdadero) y false (falso), un álgebra inicial para el género booleano es el par de literales

{true, false}

sin ecuaciones.

Una especificación algebraica consiste en una signatura y conjuntos de ecuaciones para cada género de la signatura. Estos conjuntos de ecuaciones inducen relaciones de equivalencia que definen el significado de la especificación.

El símbolo = denota una relación de equivalencia que satisface las propiedades reflexiva, simétrica y transitiva, así como la propiedad de sustitución.

Las ecuaciones dadas con un tipo permiten colocar términos en clases de equivalencia. Dos términos cualesquiera que pertenezcan a la misma clase de equivalencia se interpretan como que tienen el mismo valor. Este mecanismo puede utilizarse para identificar términos sintácticamente diferentes que tienen el mismo valor deseado.

Dos términos del mismo género, TERM1 y TERM2, pertenecen a la misma clase de equivalencia si

a) hay una ecuación TERM1=TERM2, o

b) una de las ecuaciones derivadas del conjunto dado de ecuaciones cuantificadas es TERM1=TERM2, o

c) i) TERM1 pertenece a una clase de equivalencia que contiene TERMA, y

ii) TERM2 pertenece a una clase de equivalencia que contiene TERMB, y

iii) hay una ecuación o una ecuación derivada del conjunto dado de ecuaciones cuantificadas, tal que TERMA=TERMB, o

d) sustituyendo un subtérmino de TERM1 por un término de la misma clase que el subtérmino que produce un término TERM1A es posible mostrar que TERM1A pertenece a la misma clase que TERM2.

Aplicando todas las ecuaciones, los términos de cada género son `particionados' en una o más clases de equivalencia. Hay tantos valores para el género como clases de equivalencia. Cada clase de equivalencia representa un valor y cada miembro de una clase representa el mismo valor.

Interpretar una expresión significa entonces en primer lugar derivar el término fundamental determinando el valor efectivo de las variables utilizadas en una expresión en el punto de interpretación, y después hallar la clase de equivalencia de este término fundamental. La clase de equivalencia de este término determina el valor de la expresión.

Así, se da significado a los operadores utilizados en expresiones, determinando el valor resultante dado a un conjunto de argumentos.

Es usual elegir un literal perteneciente a la clase de equivalencia para representar el valor de la clase. Por ejemplo, booleano (bool) sería representado por verdadero y falso y los números naturales por 0,1,2,3, etc. Cuando no hay literal se utiliza generalmente el término de menor complejidad posible (menor número de operadores). Por ejemplo, para enteros negativos la notación usual es -1, -2, -3, etc.

Figure omitted: 41 blanc MONTAGE: 5.4 A LA FIN DE CETTE PAGE

Las construcciones definidas en 5.2 son la base de formas más concisas explicadas más abajo.

Gramática abstracta

No hay una sintaxis abstracta adicional para la mayor parte de estas construcciones. En 5.4.1 y en todos los apartados de 5.4.1 la sintaxis abstracta pertinente es generalmente la descrita en 5.2 .

Gramática textual concreta

&lab;propiedades ampliadas> ::= &lab;regla de herencia> | &lab;instanciaciones de generador> | &lab;definición de estructura>

&lab;término compuesto ampliado> ::= &lab;identificador de operador ampliado> ( &lab;lista de términos compuestos> ) | &lab;término compuesto> &lab;operador infijo> &lab;término> | &lab;término> &lab;operador infijo> &lab;término compuesto> | &lab;operador monádico> &lab;término compuesto> | &lab;término compuesto condicional>

&lab;término fundamental ampliado> ::= &lab;identificador de operador ampliado> (&lab;término fundamental> {, &lab;término fundamental> }* ) | &lab;término fundamental> &lab;operador infijo> &lab;término fundamental> | &lab;operador monádico> &lab;término fundamental> | &lab;término fundamental condicional>

&lab;identificador de operador ampliado> ::= &lab;identificador de operador > &lab;admiración> | &lab;nombre formal de generador> | [ &lab;calificador> ] &lab;operador entre comillas>

&lab;nombre de operador ampliado> ::= &lab;nombre de operador > &lab;admiración> | &lab;nombre formal de generador> | &lab;operador entre comillas>

&lab;admiración> ::= !

&lab;nombre de literal ampliado> ::= &lab;literal cadena de caracteres> | &lab;nombre formal de generador> | &lab;literal clase de nombre>

&lab;identificador de literal ampliado> ::= &lab;identificador de literal cadena de caracteres> | &lab;nombre formal de generador>

Las reglas &lab;propiedades ampliadas>, &lab;término compuesto ampliado>, &lab;término fundamental ampliado>, &lab;nombre de operador ampliado>, &lab;nombre de literal ampliado> e &lab;identificador de literal ampliado> amplían las reglas para &lab;definición parcial de tipo> ( 5.2.1 ), &lab;término compuesto> ( 5.2.3 ), &lab;término fundamental> ( 5.2.3 ), &lab;nombre de operador> ( 5.2.2 ), &lab;literal> ( 5.2.2 ) e &lab;identificador de literal> ( 5.2.3 ) respectivamente en el núcleo de datos. Estas reglas son ampliadas aún más por las reglas &lab;regla de herencia> ( 5.4.1.11 ), &lab;instanciaciones de generador> ( 5.4.1.12.2 ), &lab;nombre formal de generador> ( 5.4.1.12.1 ), &lab;término compuesto condicional> ( 5.4.1.6 ), &lab;término fundamental condicional> ( 5.4.1.6 ), &lab;literal cadena de caracteres> e &lab;identificador de literal cadena de caracteres> ( 5.4.1.2 ) y &lab;literal clase de nombre> ( 5.4.1.14 ). Las reglas &lab;operador infijo>, &lab;operador monádico>, &lab;operador infijo entre comillas> y &lab;operador monádico entre comillas> se definen en 5.4.1.1 .

Alternativas con &lab;nombre formal de generador>s sólo son válidas en una &lab;expresión de propiedades> en un &lab;texto de generador> (véase 5.4.1.12 ) que tenga ese nombre definido como un parámetro formal.

Las alternativas de &lab;término compuesto ampliado> y &lab;término fundamental ampliado> con un &lab;nombre formal de generador> que precede un `(' sólo son válidas si el &lab;nombre formal de generador> se define de modo que sea de la clase OPERATOR (véase 5.4.1.12 ).

La alternativa de &lab;nombre de literal ampliado> con un &lab;nombre formal de generador> sólo es válida si el &lab;nombre formal de generador> está definido de modo que sea de la clase LITERAL (véase 5.4.1.12 ).

La alternativa de &lab;identificador de literal ampliado> con un &lab;nombre formal de generador> sólo es válida si el &lab;nombre formal de generador> está definido de modo que sea de la clase LITERAL o de la clase CONSTANT (véase 5.4.1.12 ).

Si un nombre de operador está definido con una &lab;admiración>, la &lab;admiración> forma semánticamente parte del nombre .

Las formas &lab;nombre de operador > &lab;admiración> o &lab;identificador de operador > &lab;admiración> representan nombre de operador ( 5.2.2 ) e identificador de operador ( 5.2.3 ) respectivamente.

Semántica

Un nombre de operador definido con una &lab;admiración> tiene la semántica normal de un operador, pero el nombre de operador sólo es visible en axiomas.

A continuación se define la manera de interpretar tipos de datos, géneros, literales, operadores y sinónimos en expresiones.

Gramática textual concreta

&lab;definición de datos> ::= { &lab;definición parcial de tipo> | &lab;definición de sintipo> | &lab;definición de generador> | &lab;definición de sinónimo> } &lab;fin>

Una definición de datos forma parte de una definición de tipo de datos si es una &lab;definición parcial de tipo> o &lab;definición de sintipo>, definidas en 5.2.1 y 5.4.1.9 respectivamente. Las reglas &lab;definición de generador> y &lab;definición de sinónimo> se definen en 5.4.1.12 y 5.4.1.13 respectivamente.

La sintaxis para introducir variables de proceso y para variables de parámetros de procedimiento se indica en 2.5.1.1 y 2.3.4 respectivamente. Una variable definida en un procedimiento no será revelada.

Semántica

Una definición de datos se utiliza sea para la definición de una parte de un tipo de datos, sea para la definición de un sinónimo para una expresión, tal como se define más detalladamente en 5.2.1 , 5.4.1.9 o 5.4.1.13 .

Una variable, cuando es creada, contiene un valor especial denominado indefinido, que es distinto de todo otro valor del género de esa variable.

A continuación se define la manera de interpretar una expresión que comprende variables.

Gramática abstracta

{Tps.Non.Photo "Gra"} Sentencia-de-asignación :: Identificador-de-variable Expresión

El género del identificador de variable y el género de la expresión deben ser iguales.

Si la variable está declarada con un sintipo y la expresión es una expresión fundamental , la verificación de intervalo definida en 5.4.1.9.1 aplicada a la expresión tiene que ser Verdadero.

Gramática textual concreta

&lab;sentencia de asignación> ::= &lab;variable> := &lab;expresión>

&lab;variable> ::= &lab;identificador de variable > | &lab;variable indizada> | &lab;variable de campo>

Si la &lab;variable> es un &lab;identificador de variable > la &lab;expresión> en la sintaxis concreta representa la &lab;expresión> en la sintaxis abstracta. Las otras formas de &lab;variable>, &lab;variable indizada> y &lab;variable de campo> son sintaxis derivada, y la &lab;expresión> en la sintaxis abstracta se halla a partir de la sintaxis concreta equivalente definida en 5.5.3.1 y 5.5.3.2 .

Semántica

La interpretación de una sentencia de asignación crea una asociación de la variable identificada en la sentencia de asignación con el valor de la expresión en la sentencia de asignación. La asociación anterior de la variable desaparece.

Si la variable está declarada con un sintipo y la expresión es una expresión activa, la verificación de intervalo definida en 5.4.1.9.1 se aplica a la expresión. Si esta verificación de intervalo es equivalente a Falso, la asignación es errónea y el comportamiento ulterior del sistema está indefinido.

Los operadores imperativos obtienen valores del estado del sistema subyacente.

Gramática abstracta

{Tps.Non.Photo "Gra"} Operador-imperativo = Expresión-ahora | Expresión-de-PId | Expresión-de-visión | Expresión-activa-de-temporizador

Gramática textual concreta

&lab;operador imperativo>::= &lab;expresión ahora> | &lab;expresión de importación> | &lab;expresión de PId> | &lab;expresión de visión> | &lab;expresión activa de temporizador>

La alternativa &lab;expresión de importación> se define en 4.13 .

Los operadores imperativos son expresiones para verificar si los temporizadores están activos, o para acceder al reloj de sistema, los valores PId asociados con un proceso, o variables importadas.

Sea ceq una ecuación condicional. El conjunto de axiomas generado por ceq, notación Ax(ceq), se define como sigue:

a) si ceq=&lab;V,Eq,e> con Eq{}, entonces Ax(ceq)={}; y

b) si ceq=&lab;V,{},e> entonces Ax(ceq) es el conjunto de todas las instancias fundamentales de e (véase Î I.2.1.3).

Sea ceq una ecuación condicional. El conjunto de reglas de inferencia generado por ceq, notación Inf(ceq), se define como sigue:

a) si ceq=&lab;V,{},e>, entonces Inf(ceq)={}, y

b) si ceq=&lab;V,{e1,...,en},e>con n>0, entonces Inf(ceq) contiene todas las reglas de la forma

$$Boe1`,...,en` $$Bue` $$Be

donde

e1`,...,en`,e` son instancias fundamentales de e1...,en,e respectivamente, que se obtienen remplazando, para cada variable x que ocurre en V, todas las ocurrencias de esa variable en e1,...,en,e, por el mismo término fundamental con género género (x) .

La interpretación semántica de una especificación algebraica SPEC=&lab;S,OP,E> es la siguiente álgebra multigénero Q=&lab;Dq,Oq>, denominada álgebra de término cociente , donde

a) Dq es el conjunto { Q(s) | s S } donde Q(s)= {[t] | t es término fundamental de género s} para cada s S; y

b) Oq es el conjunto de operaciones { op` | op OP } donde las op` están definidas por op`( [t1],...,[tn] ) = [ op(t1,...,tn) ].

MONTAGE: PAGE 162 = PAGE BLANCHE