1 Introduction au LED
Figure 1.1, p.
Figura 1.2, p.
Figure, p.
Figure, p.
2 Le LDS de base
Montage
Montage
Montage
Figure, p. 29 (E)
Figure, p. 30 (E)
Figura 6, p.
Figura 7, p.
Figura 8, p.
Figura 9, p.
Figura 10, p.
Figura 1, p. 50 (E)

delim @@

| 5i'

1 Introduction au LED

1.1 Introduction

Le but poursuivi, en recommandant l'utilisation du LDS (langage de description et de specification´

fonctionnelles), est

qu'il doit | tre possible de les analyser et de les interpreter´ sans ambiguit¨ e.´

Remarque -- Etant donne´ qu'il n'est pas fait de distinction entre l'utilisation du LDS pour la specification´ et son

comportement souhaite´ et le comportement reel.´

Une specification´ du systeme, au sens large, est la specification´

a la fois du comportement et d'un ensemble de

l'aide de techniques differentes.´

1.1.1 Objectifs

Les objectifs gen´ eraux´ qui ont et´ e´ pris en compte lors de la definition´ du LDS sont de fournir un langage:

b) permettant l'elaboration´ de specifications´ depourvues´ d'ambiguit¨ e´ pour faciliter la soumission des offres et le partage des commandes;

c) extensible pour permettre un developpement´ ulterieur;´

d) permettant l'application de plusieurs methodologies´ de

de specification´

et de conception de systeme,

sans supposer a priori l'une quelconque de ces methodologies.´

1.1.2 Domaine d'application

certains de leurs aspects. Ces applications comprennent:

a) le traitement des appels (par exemple: ecoulement,´

signalisation tel´ ephonique,´

comptage aux fins de

modification et d'extension, etc.);

d) les fonctions d'exploitation et de maintenance, la gestion

e) les protocoles de communication de donnees.´

des reseaux;´

au moyen de messages discrets.

Le LDS est un langage particulierement riche qui peut | te utilise´ a la fois pour des specifications´

de haut niveau

detaill´ ees.´ L'utilisateur doit choisir les parties appropriees´ du LDS en fonction du niveau de communication souhaite´ et de l'environnement dans lequel le langage sera utilise.´ Selon l'environnement dans lequel une specification´ est utilisee,´

explicites.´

Ainsi, le LDS peut | tre utilise´ pour:

a) etablir´ les

b) etablir´

les specifications´ d'une

les specifications´

d'une installation,

d'un systeme,

c) etablir´

d) etablir´ des

des Recommandations du CCITT,

des specifications´ de conception d'un systeme,

e) etablir´ des specifications´ detaill´ ees,´

.bp

1.1.3 Specification´

d'un systeme

1.2 Grammaires du LDS

graphique (LDS/GR) et une representation´ textuelle (LDS/PR). Comme ces formes sont toutes les deux des

correspondants.

Un sous-ensemble du LDS/PR est commun avec le LDS/GR. Ce sous-ensemble est appele´ grammaire textuelle commune.

grammaire abstraite.

.rs

Figure 1.1, p.

avec la grammaire abstraite. Cette methode´
LDS/GR.

permet egalement´

d'assurer l'equivalence´

entre le LDS/PR et le

1.3 Definitions´ fondamentales

La presente´ Recommandation fait appel a des conventions et a des concepts gen´ eraux´

dont les definitions´

sont

1.3.1 Type, definition´ et instance

Dans la presente´ Recommandation, les concepts de type, d'instance de type et les relations qui existent entre elles,

.bp

Figura 1.2, p.

definies´

pour ce type.

Ce schema´ s'applique a plusieurs concepts du LDS, c'est-a-dire qu'il existe des definitions´

de systeme et des

Le type de donnees´ constitue une categorie´ speciale´ de type (voir les § 2.3 et 5).

Remarque -- Pour eviter´ d'alourdir le texte, on peut s'abstenir d'utiliser le terme instance. Ainsi, pour exprimer

1.3.2 Environnement

Les systemes qui sont specifi´ es´

en LDS reagissent´ d'apres les stimuli qu'ils recoivent¸ du monde exterieur.´

Ce monde

On suppose qu'il y a une ou plusieurs instances de processus dans l'environnement et, par consequent,´ les

1.3.3 Erreurs

Une specification´

de systeme est une specification´ de systeme correcte en LDS seulement si elle repond´

aux regles

syntaxiques et aux conditions statiques du LDS.

Lorsqu'une specification´ LDS correcte est interpret´ ee´ et qu'une condition dynamique se trouve violee,´ une

1.4 Presentation´

1.4.1 Structuration du texte

eventuellement´ par une introduction: ces intitules´ sont les suivants:

a) Grammaire abstraite -- decrite´ par une syntaxe abstraite et des conditions statiques pour definitions´
bien formees.´

pour le LDS/PR et le LDS/GR et la grammaire uniquement utilisee´ pour le LDS/PR. Cette grammaire est decrite´ au

textuelle, et de la relation de la syntaxe textuelle avec la syntaxe abstraite.

de definitions´ bien formees´ concernant la syntaxe graphique, la relation de cette syntaxe avec la syntaxe abstraite et

.bp

Semantique´ -- donnant une signification a un type, confere les propriet´ es´ de ce type, la facon¸

avec

laquelle une instance de ce type est interpret´ ee´ et toutes conditions dynamiques qui doivent | tre remplies par l'instance

de ce type pour avoir un comportement correct au sens du LDS.

f) Exemples .

1.4.2 Intitules´

L'introduction qui precede´

eventuellement´ les intitules,´ est uniquement destinee´ a faciliter la comprehension´

du texte

S'il n'existe pas de texte pour un intitule,´ tout l'intitule´ est omis.

La suite de la presente´ section decrit´ les autres formalismes particuliers utilises´ dans chaque intitule´ et les titres utilises.´ Elle peut egalement´ | tre consider´ ee´ comme un exemple de presentation´ typographique du premier niveau des

Grammaire abstraite

La notation en syntaxe abstraite est definie´ au § 1.5.1.

L'absence de l'intitule´ grammaire abstraite indique qu'il n'existe pas d'autres syntaxes abstraites pour le sujet

tre satisfaites par une definition´ LDS bien formee´ et qui peuvent | tre verifi´ ees´ sans interpretation´ d'une instance. Les

langage.

de la syntaxe definie´ au § 2.1 de la Recommandation Z.200 (voir egalement´ le § 1.5.2).

La syntaxe textuelle est suivie par des paragraphes definissant´ les conditions statiques qui doivent | tre satisfaites dans un texte bien forme´ et qui peuvent | tre verifi´ ees´ sans interpretation´ d'une instance. Cela s'applique egalement´
aux conditions statiques, si elles existent, pour la grammaire abstraite.

dans la description du langage et est souvent omis. Dans ce contexte, le cas est ignore´ mais les sous-categories´
semantiques´ soulignees´ sont significatives.

au § 1.5.3.

La syntaxe graphique est suivie par des paragraphes definissant´ les conditions statiques qui doivent | tre satisfaites dans une LDS/GR bien formee´ et qui peuvent | tre verifi´ ees´ sans interpretation´ d'une instance. Cela s'applique egalement´ aux conditions statiques, si elles existent, pour la grammaire abstraite.

par le mot

(§ 4.2) et les mises en correspondance de litteraux´ (§ 5.4.1.15) etc., doit | tre examinee´ avant la mise en

Semantique´

Un exemple de propriet´ e´ est l'ensemble des identificateurs de signaux d'entree´ valides d'un processus. Cette propriet´ e´
est utilisee´ dans la condition statique <<pour chaque noeud-d'etat,´ tous les identificateurs de signaux d'entree´ (dans l'ensemble des signaux d'entree´ valides) apparaissent soit dans un ensemble de signaux mis en reserve´ ou dans un noeud d'entree´ >>.

inhabituelle, cette propriet´ e´ d'identite´ est determin´ ee´ comme etant´ definie´ par la section gen´ erale´ traitant des identites´
au § 2. Par consequent,´ cela n'est pas habituellement mentionne´ comme etant´ une propriet´ e´ d'identite.´ Il n'est egalement´ pas necessaire´ d'indiquer les sous-composantes d'une definition´ contenues par la definition´ etant´ donne´ que

qu'une definition´ de bloc <<a>> englobe´ des
sous-structure de bloc.

definitions´ de processus et

eventuellement´ une definition´

Les propriet´ es´ sont statiques, si elles peuvent | tre determin´ ees´ sans l'interpretation´ d'une specification´ de

Les conditions dynamiques sont des conditions qui doivent | tre satisfaites durant l'interpretation´ et qui ne peuvent

etat.´

immensement´ grande (eventuellement´ infinie). Neanmoins,´ la semantique´ d'une telle specification´ peut | tre determin´ ee.´

Exemples L'intitule´ exemples contient des exemples. 1.5 Metalangages´ Pour la definition´ des propriet´ es´ et des syntaxes	du LDS, differents´ metalangages´ ont et´ e´ utilises´ en fonction des
besoins particuliers.

1.5.1 Le Meta´ IV

Le sous-ensemble suivant du Meta´ IV est utilise´ pour decrire´ la syntaxe abstraite du LDS.

Une definition´ dans la syntaxe abstraite peut | tre consider´ ee´ comme etant´ un objet composite nomme´ (une arborescence) definissant´ un ensemble de sous-composantes.

Par exemple, la syntaxe abstraite pour la definition´ d'une variable est

Definition-de-variable´

qui definit´ le domaine de

:: Nom-de-variable Identificateur-de-ref´ erence-de-sorte´

le domaine de l'objet composite (arborescence) appele´ definition-de-variable´

. Cet objet comporte

La definition´ en Meta´ IV

Identificateur-de-ref´ erence-de-sorte´

= Identificateur

indique qu'un identificateur-de-ref´ erence-de-sorte´ est un identificateur et ne peut par consequent´ | tre syntaxiquement distingue´ des autres identificateurs.

.bp Certains objets peuvent egalement´		\| tre constitues´		par certains domaines el´ ementaires´		(non composites). Dans le cas
du LDS, ces objets sont: a) Des objets entiers Exemple:

Nombre-d'instances :: entier entier

Le terme nombre-d'instances designe´

un domaine composite contenant deux des valeurs entieres (entier )

indiquant le nombre initial et le nombre maximal d'instances.

b) Mots cles´

		Exemple: Processus-de-destination = Identificateur-de-processus \| ENVIRONNEMENT Le processus-de-destination est soit un identificateur-de-processus soit l'environnement qui est design´	e´
par le mot c)		cle´ ENVIRONNEMENT . Marques Le terme Token designe´ le domaine des marques. Ce domaine peut \| tre consider´ e´ comme etant´ compose	e´

d'un ensemble potentiellement infini d'objets atomiques distincts pour lesquels aucune representation´ n'est requise. Exemple: Nom :: Token Un nom est un objet atomique tel que tout nom peut \| tre distingue´ de tout autre nom. d) Objets non specifi´ es´ Un objet non specifi´ e´ designe´ des domaines qui peuvent avoir une certaine representation,´		n'est requise. mais pour
lesquels la representation´ n'interesse´ pas la presente´ Recommandation.

Exemple:

Texte-informel :: ...

Texte-informel contient un objet qui n'est pas interpret´ e.´

abstraite: <<*>> pour designer´ une liste pouvant | tre vide; <<+>> pour designer´ une liste non vide; < | > pour representer´ une alternative, et <<[<< >>]>> pour indiquer une option.

Enfin, la syntaxe abstraite utilise un autre operateur´ de ordonnee´ d'objets distincts). Exemple: graphe-de-processus :: noeud-de-depart-de-processus´				de suffixe <<-set >> produisant un ensemble (collection non noeud-d'etat´ -set
Un graphe-de-processus est constitue´ par noeud-de-processus . 1.5.2 Backus-Naur Form		un		noeud-de-depart-de-processus´ et d'un ensemble de

Dans la Backus-Naur Form (BNF), un symbole terminal est soit celui qui n'est pas mis entre crochets angulaires

Les crochets angulaires et le(s) mot(s) sont soit un symbole non-terminal ou l'un des deux terminaux <cha| ne de

<expression de visibilite>´ ::=

VIEW (<identificateur de variable >, <expression>)

symbole ::= et, sur la partie droite une ou plusieurs constructions constituees´ par un ou plusieurs symbole(s) non-terminaux et eventuellement´ un ou plusieurs symbole(s) terminaux. Par exemple <expression de visibilite>,´
<identificateur de variable > et <expression> dans l'exemple ci-dessus sont des symboles non-terminaux; VIEW, les

.bp

Parfois, le symbole inclut une partie soulignee.´ Cette partie soulignee´

met en relief un aspect semantique´

de ce

semantique,´ il specifie´ que l'identificateur doit \| tre un identificateur de variable. A la partie droite du symbole ::=, il existe plusieurs possibilites´ de production de symboles non-terminaux, separ´ es		es´		par
des barres verticales \| . Par exemple: <zone de bloc> ::= <ref´ erence´ de bloc graphique>

| <diagramme de bloc>

indique qu'une <zone de bloc> est soit une <ref´ erence´ de bloc graphique> ou un <diagramme de bloc>.

Les el´ ements´ syntaxiques peuvent | tre regroupes´ au moyen d'accolades

plusieurs barres verticales, indiquant des el´ ements´ syntaxiques possibles. Par exemple:

<zone { zone La r		<zone d'interaction de bloc> ::= { zone de bloc> \| <zone de definition´ de canal } La rep´ etition´ de groupes entre accolades est indiquee´ au moyen	au moyen d'un asterisque´ (*) ou du signe plus (+). Un
asterisque´		indique que le groupe est facultatif et peut ulterieurement´	\| tre rep´ et´ e´ un nombre quelconque de fois; un

signe plus indique que le groupe doit | tre present´ et peut | tre rep´ et´ e´ par la suite un nombre quelconque de fois. L'exemple ci-dessus indique qu'une <zone d'interaction de bloc> contient au moins une <zone de bloc> ou une <zone de definition´ de canal> et peut contenir plusieurs autres <zones de bloc> et <zones de definition´ de canal>.

Si les el´ ements´ syntaxiques sont regroupes´ en utilisant des crochets ([ | t | ), cela indique que le groupe est facultatif. Par exemple:

<en-t| te de processus> ::=

En ce qui concerne la grammaire graphique, le metalangage´
suivants:

a) contains

b) is associated with

c) is followed by

d) is connected to

e) set

decrit´

au § 1.5.2 est complet´ e´ avec les metasymboles´

groupe quelconque d'el´ ements´

Exemple:

syntaxiques, auquel cas, il faut le developper´

avant d'appliquer le metasymbole´

set .

<diagramme de macro> et une <zone d'interation de blocs>.

Tous les autres metasymboles´ sont des operateurs´ infixes, ayant un symbole graphique non-terminal comme argument

comme premier el´ ement´ et contient un ou plusieurs de ces operateurs´ infixes, le symbole graphique non-terminal est alors l'argument de gauche de chacun de ces operateurs´ infixes. Un symbole graphique non-terminal est un nom

terminal ayant le mot <<symbole>> place´ immediatement´ avant le signe <.

<ref´ erence´ de bloc graphique> ::=

<symbole de bloc> contains <nom de bloc >

<symbole de bloc> ::=

.rs

Figure, p.

signifie

.rs

Figure, p.

Le metasymbole´ is associated with indique que son argument de droite est logiquement associe´ avec son argument de gauche (comme s'il etait´ <<contenu>> dans cet argument, l'association depourvue´ d'ambiguit¨ e´ est obtenue par des

Le metasymbole´ is followed by signifie que son argument de droite suit (tant sur le plan logique que dans le dessin) son argument de gauche.

Le metasymbole´ is connected to signifie que son argument de droite est relie´ (tant sur le plan logique que dans le

.rs

2 Le LDS de base

2.1 Introduction

canaux. A l'interieur´ de chacun des blocs il y a un ou plusieurs processus. Ces processus communiquent entre eux par

Le § 2 a et´ e´ subdivise´ en huit principaux sujets:

textes, les symboles de texte.

b) Concepts de base concernant les donnees´

Les concepts de base concernant les donnees´

c) Structure des systemes

en LDS telles les valeurs, les variables, les expressions.

Contient les concepts du LDS relatifs aux principes gen´ eraux´ de structuration du langage. Il s'agit des

d) Communication

Decrit´ les mecanismes´ de communication utilises´ dans le LDS tels le canal, l'acheminement du signal, le signal.

e) Comportement

processus ou graphe de procedure,´ definition´ de variable, depart,´ etat,´ entree,´ mise en reserve,´

f) Action

etiquette,´

transition.

			Constructions actives tels les t\| ches, la creation´ de processus, l'appel de procedure,´ g) Temporisateurs Definition´ des temporisateurs et primitives des temporisateurs.		la sortie, la decision.´
	h)		Exemples Il s'agit d'exemples concernant les autres points.

<unite´ lexicale> ::=

<nom>

<special>´

<special´ composite>

<note>

<mot cle>´

composite>

<nom> ::=

<mot> { | souligne>´ <mot> }

<mot> ::=

{ alphanumerique>´ | <point }

<alphanumerique>´

{ alphanumerique>´ | <point> }

<alphanumerique>´ ::=

| <lettre>

| <chiffre decimal>´

| <national>

<lettre> ::=

A | B | C | D | E | F | G | H | I | J | K | L | M

| N | O |

| a | b | c

| n | o | p

.bp

<chiffre decimal>´

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

::=

0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<national> ::=

Montage

Montage

Montage

| <ligne verticale>

| <accolade droite>

| <tilde>

<crochet gauche> ::=

[

<crochet droit> ::=

]

<accolade gauche> ::=

{

<ligne verticale> ::=

<accolade droite> ::=

}

<tilde> ::=

.^~

Montage

	<point> ::= . <souligne>´	::=
	--

<apostrophe> { alphanumerique>´

| <special>´

| <point>

| <souligne>´

| <espace>

| <apostrophe> <apostrophe } <apostrophe> <texte> ::=

{ alphanumerique>´

<special>´

<point>

<souligne>´

<apostrophe }

<apostrophe> ::=

? | & | %

<sp + \| - .bp		<special>´ ::= + \| - \| ! \| / \| > \| * \| ( \| ) \| " \| , \| ; \| < \| = \| : .bp
<special´ == \| \| \| \| \| \| \| \| \| \|		composite> ::= == \| ==> \| /= \| <= \| >= \| // \| := \| => \| -> \| (. \| .)

<note> ::=

/* <texte> */

<mot cle>´ ::=

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

FOR

FPAR

FROM

GENERATOR

IMPORT

IMPORTED

INHERITS

INPUT

JOIN

LITERAL

LITERALS

MACRO

MACRODEFINITION

MACROID

MAP

MOD

NAMECLASS

NEWTYPE

NEXTSTATE

NOT

NOW

OFFSPRING

OPERATOR

OPERATORS

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

TYPE

VIA

VIEW

VIEWED

WITH

XOR

ref´ erence´ de l'Alphabet no 5 du CCITT (Recommandation T.50). La responsabilite´ de la definition des

.bp

de <souligne>´ permet de repartir´ des <unite´ lexicale> sur plus d'une ligne.

donc:

les <souligne>´ dans le <nom> dans un <el´ ement´ de trajet> doivent | tre specifi´ es´ explicitement;

lorsqu'un ou plusieurs <nom> ou <identificateur> peuvent | tre suivis directement par une <sorte>

(par exemple, <definition´ de variable>, <definition´ de vue>), les <souligne>´ dans ces <nom> ou <identificateur> doivent | tre specifi´ es´ explicitement;

3) lorsqu'une <definition´ de donnees>´ contient des <instantiations de gen´ erateur>,´ les <souligne>´
<nom de sorte> suivant le mot cle´ NEWTYPE doivent | tre specifi´ es´ explicitement.

signification qu'un espace.

Le caractere / immediatement´ suivi par le caractere * marque toujours le debut´

d'une <note>. Le caractere *

Grammaire abstraite

Identificateur :: Qualificatif-Nom

Qualificatif = Element-de-chemin´ +

Qualificatif-de-bloc |

Qualificatif-de-sous-structure-de-bloc |

Qualificatif-de-signal |

Qualificatif-de-processus |

Qualificatif-de-procedure´ |

Qualificatif-de-sorte |

Qualificatif-de-bloc :: Nom-de-bloc

Qualificatif-de-sous-structure-de-bloc :: Nom-de-sous-structure-de-bloc

	Qualificatif-de-processus Qualificatif-de-procedure´ Qualificatif-de-signal ::		::		:: ::		Nom-de-processus Nom-de-procedure´ Nom-de-signal
	Qualificatif-de-sorte Nom :: Token		::				Nom-de-sorte

<identificateur> ::= [<qualificatif>] <nom> <qualificatif> ::= <el´ ement´ de chemin> { <el´	<el´ ement´ de chemin }
<el´ ement´ de chemin> ::= <classe d'unite´ de portee>´	<nom>
.bp <classe d'unite´ de portee>´ ::=

SYSTEM

BLOCK

SUBSTRUCTURE

SIGNAL

PROCESS

PROCEDURE

TYPE

SERVICE

Il n'y a pas de syntaxe abstraite correspondante pour la <classe d'unite´ de portee>´ indiquee´ par service. Les <nom> et <identificateur> d'entites´ definies´ dans une <definition´ de service> sont transformes´ en <nom> uniques ou en <identificateur> uniques definis´ dans la <definition´ de processus> contenant la <definition´ de service>.

§ 2.4.1) ou bien tout le <qualificatif>. Lorsque tout le <qualificatif> est omis et que le <nom> designe´ une entite´ de la

l'association du <nom> avec une definition´ doit pouvoir | tre resolue´ par le contexte reel.´ Dans d'autres cas,

complet designant´ cette unite´ de portee.´ Si l'<identificateur> ne contient pas de <qualificatif>, la necessit´ e´ de mise en correspondance des <qualificatif> est omise.

porte le m| me <nom>.

La resolution´ par contexte est possible dans les cas suivants:

a) l'unite´ de portee´ dans laquelle le <nom> est utilise´ n'est pas une <definition´ partielle de type> et

b) l'unite´ de portee´ dans laquelle le <nom> est utilise´ ne contient pas de definition´ ayant ce <nom> ou

propriet´ es´ statiques (compatibilite´ de sorte, etc.) de la construction dans laquelle le <nom> appara| t. Le <nom> sera

Semantique´

Les unites´ de portee´ sont definies´ par le schema´ suivant:

<definition´ de bloc> <diagramme de bloc>

<definition´ de processus> <diagramme de processus>

<definition´		de proc		de procedure>´ <diagramme de procedure>´
		<definition´ <definition´ <definition´ <definition´		de sous-structure de bloc> <diagramme de sous-structure de bloc> de sous-structure de canal> <diagramme de sous-structure de canal> de service> <diagramme de service> partielle de type>

.bp

Une liste de definitions´ est associee´ a une unite´ de portee.´ Chaque definition´ definit´

une entite´ appartenant a une

certaine classe d'entite´ et ayant un nom associe.´ Pour une <definition´ partielle de type>, la liste de definitions´ associee´
comprend les <signature d'operateur>,´ les <signature de litteral>´ et toutes <signature d'operateur>´ et <signature de litteral>´ provenant d'une sorte parente, d'un gen´ erateur´ d'instance ou impose´ par l'utilisation d'abreviations´ tel le mot cle´ ORDERING (voir le § 5.4.1.8). Il faut remarquer qu'une <definition´ de visibilite>´ ne definit´ pas une entite.´

propre notation syntaxique, ils sont en realit´ e´ des <nom>, ils sont represent´ es´ dans la syntaxe abstraite represent´ ee´
par un nom suit, ils sont etudi´ es´ comme s'ils etaient´ (syntaxiquement aussi) des <nom>. Toutefois, les <nom d'etat´ >, les <nom de connecteur >, les <nom formel de gen´ erateur´ >, les <identificateur de valeur > dans les equations,´ les

Chaque entite´ est dite avoir son contexte de definition´ dans l'unite´ de portee´ qui la definit.´ Les entites´ sont ref´ erenc´ ees´ au moyen d'<identificateur>.

Le <qualificatif> dans un <identificateur> specifie´ uniquement le contexte de definition´ du <nom>.

Les classes d'entites´ sont les suivantes:

e) f)

blocs

canal, acheminement de signaux

signaux, temporisateurs

processus

procedures´

sortes

gen´ erateurs´

entites´ importees´

listes de signaux

services

sous-structures de bloc, sous-structures de canal

	Un <identificateur> est dit \| tre visible dans une unite´ de portee´ a) si la partie nom de l'<identificateur> a son contexte de definition´ dans cette unite´ de portee,´ ou b) s'il est visible dans l'unite´ de portee´ qui definit´ cette unite´ de portee,´ ou c) si l'unite´ de portee´ contient une <definition´ partielle de type> dans laquelle l'<identificateur> est defini,´	ou
	d) si l'unite´ de portee´ contient une <definition´ de signal> dans laquelle l'<identificateur> se trouve defini.´

le m| me <nom>. Il existe cependant une exception: les definitions´ de <signature d'operateur>´ et de <signature de litteral>´ dans la m| me <definition´ partielle de type> (voir le § 5.2.2): plusieurs operateurs´ et litteraux´ peuvent avoir le m| me <nom> avec differentes´ <sorte d'argument> ou differentes´ sortes de <resultat>.´

On notera une autre exception: les entites´ importees.´ Pour cette classe, les paires de (<nom d'import>, <sorte>) dans <definition´ d'import> dans l'unite´ de portee´ doivent | tre distinctes.

terminaison (ENDSYSTEM, ENDBLOCK, etc.) doit | tre syntaxiquement le m| me que le nom ou l'identificateur qui suit le mot cle´ commencant¸ correspondant (respectivement: SYSTEM, BLOCK, etc.).

.bp

2.2.3 Texte informel

Grammaire abstraite

Texte informel :: ...

<texte informel> ::=

Semantique´

Lorsqu'un texte informel est utilise´ dans une specification´

LDS de systeme, il signifie que le texte n'est pas en LDS

d'autres moyens.

La taille des symboles graphiques est choisie par l'utilisateur.

ligne>, le <symbole de ligne de flot>, le <symbole d'association continu> et le <symbole d'association pointille>,´
peuvent se couper. Il n'existe pas d'association logique entre les symboles qui se coupent.

Le metasymbole´ is followed by implique un <symbole de ligne de flot>.

Les symboles de ligne peuvent | tre constitues´ par un ou plusieurs segments de droite en trait plein.

qui

de flot>, dans un <symbole de connecteur de sortie> ou dans un <symbole d'etat´ suivant>. Dans d'autres cas, ces

verticaux.

On peut utiliser des images symetriques´ verticales des <symbole d'entree>,´ des <symbole de sortie>, des <symbole de commentaire> et des <symbole d'extension de texte>.

L'argument de la partie droite du metasymbole´ is associated with doit | tre plus proche de l'argument de gauche que tout autre symbole graphique. Les el´ ements´ syntaxiques de l'argument de droite doivent pouvoir | tre distingues´
les uns des autres.

2.2.5 Subdivision des diagrammes

neanmoins,´ <page> <symbole { zone		on utilise le m\| me metalangage.´ <page> ::= <symbole de cadre> contains { zone d'en-t\| te> <zone de numero´ de page>	de page>
		{ unite´ syntaxique } } <zone d'en-t\| te> ::= <symbole implicite de texte> contains	<en-t\| te>

<zone de numero´ de page> ::=

<symbole implicite de texte> contains [<numero´

<numero´ de page> ::=

<nombre de pages> ::=

.bp

de page> [(<nombre de pages>)] |

diagramme peut | tre subdivise´ en un nombre de <page>, auquel cas le <symbole de cadre> delimitant´ le diagramme et l'<en-t| te> du diagramme est remplace´ par un <symbole de cadre> et un <en-t| te> pour chaque <page>.

L'utilisateur du LDS peut choisir les <symbole de cadre> imposes´ par la limite du support sur lequel les diagrammes sont reproduits.

Afin d'avoir une separation´ nette entre la <zone d'en-t| te> et la <zone de numero´ de page>, le <symbole de texte implicite> n'est pas materialis´ e,´ il est sous-entendu. La <zone d'en-t| te> est placee´ au coin superieur´ gauche du <symbole de cadre>, la <zone de numero´ de page> est situee´ au coin superieur´ droit du <symbole de cadre>. L'<en-t| te> et l'<unite´ syntaxique> dependent´ du type de diagramme.

2.2.6 Commentaire

Un commentaire est une notation qui represente´ des commentaires associes´ avec des symboles ou du texte.

definie´ au § 2.2.1.

Des exemples sont donnes´ aux figures 2.9.1 et 2.9.3.

<fin> ::=

[<commentaire>];

<commentaire> ::=

<zone de commentaire> ::=

<symbole de commentaire> contains <texte>

is connected to <symbole d'association pointille>´

<symbole de commentaire> ::=

.rs

Figure, p. 29 (E)

<symbole d'association pointille>´ ::=

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

Une des extremit´ es´ du <symbole d'association pointille>´ doit | tre reliee´ au milieu du segment vertical du <symbole de commentaire>.

pointille>.´ Le <symbole de commentaire> est consider´ e´ comme etant´ un symbole ferme´ en completant´ (par la pensee)´
le rectangle afin d'entourer le texte. Il contient le texte du commentaire se rapportant au symbole graphique.

2.2.7 Extension de texte

<zone d'extension de texte> ::=

<symbole d'extension de texte> contains <texte>

is connected to <symbole d'association continu>

<symbole d'extension de texte> ::=

<symbole d'association continu> ::=

Une des extremit´ es´ du <symbole d'association continu> doit | tre reliee´ au milieu du segment vertical du <symbole d'extension de texte>.

continu>. Le <symbole d'extension de texte> est consider´ e´ comme etant´ un symbole ferme´ en completant´ (par la pensee)´ le rectangle.

Le texte contenu dans le symbole d'extension de texte> est la suite du texte dans le symbole graphique et est consider´ e´ comme etant´ contenu dans ce symbole.

2.2.8 Symbole de texte Le <symbole de texte> est utilise´ dans tout <diagramme>. Le contenu depend´		du diagramme.
<symbole de texte> ::= .rs

Figure, p. 30 (E)

2.3 Concepts de base concernant les donnees´

Le concept de donnees´ dans le LDS est expose´ dans le detail´ au § 5; plus precis´ ement´ en ce qui concerne la

concernant les donnees´ pred´ efinies.´ Les donnees´ apparaissent dans les definitions´ du type de donnees,´ les expressions, l'application d'operateurs,´				les
variables, les valeurs et les litteraux.´ 2.3.1 Definitions´ des types de donnees´ Les donnees´ dans le LDS sont principalement abordees´ sous l'aspect type de donnees.´ Un type de donnees´		definit´		un

algebriques´ (equations)´ qui definissent´ le comportement de ces operateurs´ lorsqu'ils sont appliques´ aux valeurs. Les

propriet´ es´ sont definies´ par les Le LDS permet la definition´	par les definitions´ de types de donnees.´ de tout type de donnees´ qui est necessaire,´	y	y compris les mecanismes´	de	de composition
(type composite) avec	pour seule contrainte qu'une telle definition´	puisse	\| tre specifi´ ee´	de maniere	formelle. En

revanche, pour les langages de programmation, il y a des considerations´ de mise en oeuvre qui necessitent´ que

limites´ (tableau, structure, etc.).

2.3.2 Variables

variable, on renvoie la valeur associee.´

2.3.3 Valeurs et litteraux´

Un ensemble de valeurs avec certaines caracteristiques´ est appele´ sorte. Les operateurs´ sont definis´

a partir et vers

.bp

n'ont jamais de valeurs en commun.

Pour la plupart des sortes, il y a des formes litterales´ qui decrivent´ les valeurs de la sorte (par exemple, pour les

Certaines sortes peuvent ne pas avoir de litteraux;´ par exemple, une valeur composite n'a souvent pas de litteraux´ en
propre mais a des valeurs qui sont definies´ par des operations´ de composition sur les valeurs de ses composantes.

2.3.4 Expressions

Une expression decrit´ une valeur. Si une expression ne contient pas de variable, par exemple, si elle est un litteral´

d'une sorte donnee,´ chaque occurrence de l'expression decrira´ toujours la m| me valeur. Une expression qui contient

associee´ aux variables.

2.4.1 Definitions´ differ´ ees´

Une <definition´ differ´ ee>´ est une definition´ qui a et´ e´ supprimee´ de son contexte de definition´ pour accro| tre la visibilite.´

une definition´ de macro (voir le § 4.2), mais elle est <<appelee>>´ d'un seul endroit exactement (le contexte de definition)´ en utilisant une ref´ erence.´

<definition´ differ´ ee>´ ::=

	{ definition´ diff <definition>´ <definition´ de \| <definition´		differ´ ee ::= de bloc> <definition´		differ´ ee´ } ::= de bloc> de processus>
	\|		<definition´		de procedure>´

<definition´

de sous-structure de bloc>

de sous-structure de canal>

de service>

de macro>

<diagramme> ::=

Pour

<diagramme de procedure>´

chaque <definition´ differ´ ee>,´ sauf pour des

<definition´ de macro> et des <diagramme de macro>, on doit

Pour chaque ref´ erence´ on doit avoir une <definition´ differ´ ee>´ correspondante.

cet <identificateur>, le <qualificatif> doit | tre soit complet, soit omis. Si le <qualificatif> est omis, le <nom> doit | tre

Semantique´

<definition´ differ´ ee>´ correspondante. Dans cette substitution, l'<identificateur> de la <definition´ differ´ ee>´ est remplace´ par le <nom> dans la ref´ erence.´

.bp

Grammaire abstraite

Definition-de-systeme´ ::

Nom-de-systeme

Definition-de-bloc´ -set Definition-de-canal´ -set Definition-de-signal´ -set Definition-de-type-de-donn´ ees´		-set -set -set	ees´
Definition-de-type-de-synonyme´			-set

Les definitions´ de tous les signaux, canaux, types de donnees,´ types de synonymes utilises´ dans l'interface avec

{ definition´				de bloc>
		\| \| \| \| \| \| \|		<ref´ erence´ <definition´ de <definition´ de <definition´ de <definition´ de <definition´ de <definition´ de		textuelle de bloc> de canal> de signal> de liste de signaux> de selection>´ de macro> de donnees´ } \|

<ref´ erence´ BLOCK		<ref´ erence´ textuelle de bloc> ::= BLOCK <nom de bloc > REFERENCED <fin>
<definition´ <definition´		de selection>´ est definie´ au § 4.3.3, <definition´ de bloc> au § 2.4.3, <definition´ de canal> au § 2.5.1,	de macro> au § 4.2, <definition´ de donnees>´ au § 5.5.1, au § 2.5.1, <definition´ de signal> au § 2.5.4, <definition´ de liste de

signaux> au § 2.5.5.

<symbole de cadre> contains

{ diagramme de macro }

{ <zone interaction de bloc } set }

<symbole de cadre> ::=

Figura 6, p.

<symbole de texte> contains

{ definition´ de signal>

| <definition´ de liste de signaux>

| <definition´ de donnees>´

| <definition´ de macro>

| <definition´ de selection´ } |

} |

<zone interaction de bloc> ::=

{ zone de bloc>

| <zone de definition´ de canal }

<zone de bloc> ::=

<ref´ erence´ de bloc graphique>

| <diagramme de bloc>

<ref´ erence´ de bloc graphique> ::=

<symbole de bloc> contains <nom de bloc >

<symbole de bloc> ::=

Figura 7, p.

<definition´ de selection>´ est definie´ au § 4.3.3, <definition´ de macro> au § 4.2, <diagramme de macro> au § 4.2, <definition´ de donnees>´ au § 5.5.1, <diagramme de bloc> au § 2.4.3, <zone de definition´ de canal> au § 2.5.1, <definition´ de signal> au § 2.5.4, <definition´ de liste de signaux> au § 2.5.5.

La definition-de-bloc´ -set dans la grammaire abstraite correspond aux <zone de bloc>, la definition-de-canal-´

Semantique´

Une definition-de-systeme´

est la representation´

en LDS d'une specification´

ou de la description d'un systeme.

b) interpreter´ les blocs et les canaux qui leur sont relies´
subdivision coherent´ choisi.

2.4.3 Bloc

Grammaire abstraite

Definition-de-bloc´ :: Nom-de-bloc

Definition-de-processus´ -set

et qui sont contenus dans le sous-ensemble de

Definition-de-signal´ -set

Connexion-de-canal-vers-acheminement -set

Definition-d'acheminement-de-signal´ -set

Definition-de-type-de-donn´ ees´

Definition-de-type-de-synonyme´ -set

[Definition-de-sous-structure-de-bloc´ ]

Nom-de-bloc = Nom

A moins qu'une definition-de-bloc´

Nom

ne contienne une definition-de-sous-structure-de-bloc´

, on doit avoir au

Il est possible de subdiviser les blocs en specifiant´ la definition-de-sous-structure-de-bloc´ ; cet aspect du langage est etudi´ e´ au § 3.2.2.

.bp

<definition´ de bloc> ::=

BLOCK { nom de bloc \| identificateur de bloc } fin> { definition´ de signal> \| <definition´ de liste de signaux> \| <definition´ de processus> \| <ref´ erence´ textuelle de processus>	processus>
\| <definition´ d'acheminement \| <definition´ de macro> \| <definition´ de donnees>´ \| <definition´ de selection>´ \| <connexion de canal vers acheminement	de signal> acheminement }
[<definition´ de sous-structure de ENDBLOCK [<nom de bloc \| identificateur de bloc >] <fin> <ref´ erence´ textuelle de processus>	de bloc \| ref´ erence´ textuelle de sous-structure de bloc>] ::=

PROCESS <nom de processus >[<nombre d'instances>] REFERENCED <fin>

<definition´ de signal> est definie´ au § 2.5.4, <definition´ de liste de signaux> au § 2.5.5, <definition´ de processus> au § 2.4.4, <definition´ d'acheminement de signal> au § 2.5.2, <connexion de canal vers acheminement> au § 2.5.3, <definition´ de sous-structure de bloc> au § 3.2.2, <ref´ erence´ de sous-structure de bloc textuelle> au § 3.2.2, <definition´ de macro> au § 4.2.2, <definition´ de donnees>´ au § 5.5.1.

<diagramme de bloc> ::=

contains { en-t| te de bloc>

{ { zone texte de bloc } { diagramme de macro }

[<zone d'interaction de processus>] [<zone de sous-structure de bloc> } set }

is associated with { identificateur de canal

}

de cadre>. Si le <diagramme de bloc> ne contient pas une <zone d'interaction de processus>, il doit alors contenir une <zone de sous-structure de bloc>.

<en-t| te de bloc> ::=

BLOCK { nom de bloc
| identificateur de bloc
}

<zone texte de bloc> ::=

<zone d'interaction de processus> ::=

{ zone de processus>

| <zone de ligne de creation>´

| <zone de definition´ d'acheminement de signal }

<zone de processus> ::=

<ref´ erence´ graphique de processus | diagramme de processus>

<ref´ erence´ graphique de processus> ::=

<symbole de processus> contains { nom de processus >[<nombre d'instances> }

<symbole de processus> ::=

Figura 8, p.

Le terme <nombre d'instances> est defini´ au § 2.4.4.

<zone de ligne de creation>´ ::=

<symbole de ligne de creation>´

is connected to { zone de processus> <zone de processus }

<symbole de ligne de creation>´ ::=

--------------ñ

processus de creation´ a lieu.

Le <diagramme de processus> est defini´ au § 2.4.4, la <zone de definition´ d'acheminement de signal> au § 2.5.2, la <zone de sous-structure de bloc> au § 3.2.2, le <diagramme de macro> au § 4.2.2.

Semantique´

Une definition´ de bloc contient une ou plusieurs definitions´

d'un systeme et eventuellement´

une sous-structure de

bloc. La definition´ de bloc permet de regrouper les processus qui tous ensemble assurent une certaine fonction, soit directement soit par l'intermediaire´ d'une sous-structure de bloc.

Une definition´ de bloc assure une interface statique de communication par laquelle les processus peuvent communiquer avec d'autres processus. De plus, elle donne la portee´ pour les definitions´ de processus.

2.4.4 Processus Grammaire abstraite Definition-de-processus´ ::	Nom-de-processus
Nombre-d'instances

Definition-de-proc´ edure-´ set Definition-de-signal-´ set		edure-´ set set		set		set
Definition-de-type-de-signal´ Definition-de-type-de-synonyme-´ set							set

Definition-de-variable-´ set Definition-de-visibilit´ e-´ set Definition-de-temporisateur-´		set e-´ set	set
Graphe-de-processus

Nombre-d'instances Nom-de-processus = Graphe-de-processus		:: Nom ::		Entier Entier Noeud-de-depart-de-processus´
Noeud-d'etat-´ set

Identificateur-de-ref´ erence-de-sorte´

<definition´ de processus> ::=

PROCESS { identificateur de processus
| nom de processus
}

[<nombre d'instances>] <fin>

{ definition´ de signal>

<definition´ de

<ref´ erence´

<definition´ de

<definition´ d'import>

<definition´ de

de liste de signaux>

de procedure>´

textuelle de procedure>´

de macro>

de donnees>´

de variable>

de visibilite>´

de selection>´

d'import>

de temporisateur } |

{ corps de processus>

| <decomposition´ de service }

ENDPROCESS [<nom de processus
| identificateur de processus >] <fin>

<ref´ erence´ textuelle de procedure>´ ::=

PROCEDURE <nom de procedure´ > REFERENCED <fin>

<ensemble de signaux d'entree´ valides> ::=

SIGNALSET [<liste de signauxs>] <fin>

<corps de processus> ::=

<depart´ { etat´ } |

.bp

FPAR <nom de variable
{ <nom de variable
} | <sorte>

{ <nom de variable
{ <nom de variable
} <sorte }

<nombre d'instances> ::=

([<nombre initial>], [<nombre maximal>])

<nombre initial> ::=

<nombre maximal> ::=

Le nombre initial d'instances et le nombre maximal d'intances contenus dans le nombre-d'instances sont tires´ du <nombre d'instances>. Si le <nombre initial> est omis, le <nombre initial> est 1. Si le <nombre maximal> est omis, le <nombre maximal> n'est pas limite.´

Le <nombre d'instances> utilise´ dans la derivation´ est le suivant:

a) s'il n'y a pas de <ref´ erence´ textuelle de processus> pour le processus, le <nombre d'instances> dans la <definition´ de processus> est utilise.´ S'il ne contient pas un <nombre d'instances>, on utilise le <nombre

<nombre initial> et le <nombre maximal>;

c) si soit le <nombre d'instances> dans la <definition´ de processus> soit le <nombre d'instances> dans une <ref´ erence´ textuelle de processus> est omis, le <nombre d'instances> est celui qui est present;´

une <ref´ erence´ textuelle de processus> sont specifi´ es,´ les deux <nombre d'instances> doivent | tre egaux´ lexicalement et ce <nombre d'instances> est utilise.´

Une relation analogue s'applique au <nombre d'instances> specifi´ e´ dans le <diagramme de processus> et dans la <ref´ erence´ textuelle de processus> definis´ ci-dessous.

<definition´ de signal> est definie´ au § 2.5.4, <definition´ de liste de signaux> au § 2.5.5, <definition´ de visibilite>´ au § 2.6.1.2, <definition´ de variable> au § 2.6.1.1, <definition´ de procedure>´ au § 2.4.5, <definition´ de temporisateur> au § 2.8, <definition´ de macro> au § 4.2.2, <definition´ d'import> au § 4.1.3, <definition´ de selection>´ au § 4.3.3, <expression simple> au § 4.3.2, <decomposition´ de service> au § 4.10.1, <definition´ de donnees>´ au § 5.5.1.

Le <nombre initial> d'instances doit | tre inferieur´ ou egal´ au <nombre maximal> et le <nombre maximal> doit |

<diagramme de processus> ::=

contains { en-t| te de processus>

{ zone de texte de processus }

{ zone de processus }

{ diagramme de macro }

{ zone graphique de processus | zone d'interaction de service } set }

[is associated with { identificateur d' acheminement de signal

} ]

signal au <symbole de cadre>.

<zone de texte de processus> ::= <symbole de texte> contains { [<ensemble des signaux d'entree´	valides>]
{ definition´ de signal>

<definition´

de liste de signaux>

de variable>

de visibilite>´

d'import>

de donnees>´

de macro>

de temporisateur>

de selection´ } }

<en-t| te de processus> ::=

PROCESS { nom de processus
| identificateur de processus
}

[<nombre d'instances> [<fin>] ]

<zone graphique de processus> ::=

<zone de depart´ { zone d'etat´ | zone de connecteur d'entree´ }

<definition´ de signal> est definie´ au § 2.5.4, <definition´ de liste de signaux> au § 2.5.5, <definition´ de visibilite>´ au § 2.6.1.2, <definition´ de variable> au § 2.6.1.1, <zone de procedure>´ au § 2.4.5, <definition´ de temporisateur> au § 2.8, <definition´ de macro> et <diagramme de macro> au § 4.2.2, <definition´ d'import> au § 4.1.3, <definition´ de selection>´ au § 4.3.3, <definition´ de donnees>´ au § 5.5.1, <zone de depart>´ au § 2.6.2, <zone d'etat>´ au § 2.6.3, <zone de connecteur d'entree>´ au § 2.6.6 et <zone d'interaction de service> au § 4.10.1.

Semantique´

dynamique.

different´ de l'etat´ d'origine.

ces processus initiaux sont initialises´ avec une valeur non definie.´

l'action de depart´ est interpret´ ee;´ des actions d'arr| t peuvent arr| ter leur existence.

Les signaux recus¸ par les instances de processus sont appeles´ signaux d'entree,´ et les signaux envoyes´ aux instances de processus sont appeles´ signaux de sortie.

Les signaux peuvent | tre traites´ par une instance de processus seulement lorsque celle-ci se trouve dans un certain etat.´ L'ensemble complet de signaux d'entree´ valides est l'union de l'ensemble des signaux se trouvant dans tous les trajets des signaux conduisant au processus, de l'<ensemble de signaux d'entree´ valides>, des signaux implicites et des signaux de temporisation.

.bp

Le processus peut | tre soit mis en attente, en occupant un etat,´ soit en activite,´ en effectuant une transition. Pour chaque etat,´ il existe un ensemble de signaux de mise en reserve´ (voir egalement´ le § 2.6.5). Dans le cas d'attente dans un etat,´ le premier signal entrant dont l'identificateur ne figure pas dans l'ensemble des signaux de mise en reserve´ est extrait de la file d'attente, et traite´ par le processus.

dans une file d'attente pour le processus. L'ensemble des signaux retenus est ordonne´ dans la file d'attente, selon l'ordre d'arrivee.´ Si deux ou plusieurs signaux arrivent simultanement,´ ils sont ordonnes´ arbitrairement.

auxquelles on affecte des valeurs.

dynamiquement cre´ ee.´

Pour toutes les instances de processus, on peut utiliser quatre expressions produisant un PId (voir le § 5.6.10): SELF, PARENT, OFFSPRING et SENDER. Elles donnent un resultat´ pour:

a) l'instance de processus (SELF);

b) l'instance du processus createur´

(PARENT);

c) l'instance de processus la plus recente´ cre´ ee´ par le processus (OFFSPRING);

d) l'instance de processus en provenance de laquelle le dernier signal entrant a et´ e´ utilise´ (SENDER) (voir egalement´ le § 2.6.4).

Ces expressions sont expliquees´ dans le detail´ au § 5.5.4.3.

de processus.

l'expression pred´ efinie´ PARENT presente´ toujours la valeur NULL.

Pour toutes les instances de processus nouvellement cre´ ees,´ les expressions pred´ efinies´ SENDER et OFFSPRING ont la valeur NULL.

2.4.5 Procedure´

Les procedures´ sont definies´

au moyen de definitions´ de procedure.´ On fait appel a une procedure´

au moyen d'un

d'une procedure.´

Grammaire abstraite

Definition-de-proc´ edure´ :: Nom-de-procedure´

Definition-de-proc´ edure-´ set Definition-de-type-de-donn´ ees´ Definition-de-type-de-synonyme-´ set		edure-´ set		set ees´	set
Definition-de-variable-´ set Graphe-de-procedure´				set

Nom-de-procedure´ = Nom

Identificateur-de-ref´ erence-de-sorte´

Identificateur-de-ref´ erence-de-sorte´ Graphe-de-procedure´ ::		::		Noeud-de-depart-de-proc´ edure		edure´
Noeud-d'etat-´ set Noeud-de-depart-de-proc´ edure		edure´		:: Transition

<definition´ de procedure>´ ::=

PROCEDURE { identificateur de procedure´
| nom de procedure´
} <fin>

{ definition´ de donnees>´

<definition´ de

<ref´ erence´

<definition´ de

de variable>

textuelle de procedure>´

de procedure>´

de selection>´

de macro }

<corps de procedure>´

ENDPROCEDURE [<nom de procedure´
| identificateur de procedure´ >] <fin>

[IN/OUT

| IN]

<corps de procedure>´

::=

<definition´ de variable> est definie´ au § 2.6.1.1, <ref´ erence´ textuelle de procedure>´ au § 2.4.4, <definition´ de macro> au § 4.2, <definition´ de selection>´ au § 4.3.3, <definition´ de donnees>´ au § 5.5.1, <sorte> au § 5.2.2.

Dans une <definition´ de procedure>,´ la <definition´ de variable> ne peut contenir les expressions REVAELED, EXPORTED, REVAELED EXPORTED, EXPORTED REVEALED <nom de variable > (voir le § 2.6.1). Un exemple

<diagramme de procedure>´ ::=

<symbole de cadre> contains { en-t| te de procedure>´

{ zone de texte de procedure>´

| <zone de procedure>´

| <diagramme de macro }

<zone de graphe de procedure´ } set }

<zone de procedure>´ ::=

<ref´ erence´ graphique de procedure>´

	\| <diagramme de procedure>´ <zone de texte de procedure>´ ::=		::=
	<symbole de texte> contains { definition´ de variable> \| <definition´ de donnees>´ \| <definition´ de selection>´ \| <definition´ de macro }

<ref´ erence´ graphique de procedure>´ ::=

<symbole de procedure>´ contains <nom de procedure´ >

<symbole de procedure>´ ::=

Figura 9, p.

<en-t| te de procedure>´ ::=

PROCEDURE { nom de procedure´
| identificateur de procedure´
}

	<zone de graphe de procedure>´ ::= <zone de depart´ de procedure>´ { zone de d'etat´ \| zone de connecteur d'entree>´	}
	<zone de depart´ de procedure>´ ::= <symbole de depart´ de procedure>´ is followed	by <zone de transition>
	<symbole de depart´ de procedure>´ ::= .rs

Figura 10, p.

<definition´ de variable> est definie´ au § 2.6.1.1, <zone de transition> au § 2.6.7.1, <zone d'etat>´ au § 2.6.3, <zone de connecteur d'entree>´ au § 2.6.6, <definition´ de macro> et <diagramme de macro> au § 4.2, <definition´ de selection>´
au § 4.3.3, <definition´ de donnees>´ au § 5.5.1.

Semantique´

choisi et elles limitent la portee´ du nom des variables definies´ dans la procedure.´

exportee´ ou | tre importee.´ Elle est cre´ e´ lors de l'interpretation´ du noeud de depart´ de procedure´ et cesse d'exister lors de l'interpretation´ du noeud de retour du graphe de procedure.´

Lorsqu'une definition´ de procedure´ est interpret´ ee,´ son graphe de procedure´ est egalement´ interpret´ e.´

Une definition´ de procedure´ est interpret´ ee´ seulement lorsqu'une instance de processus l'appelle, et l'interpretation´ est faite par l'instance de processus.

L'interpretation´ d'une definition´ de procedure´ provoque la creation´ d'une instance de procedure´ et

pas definie;´

.bp

d) une variable locale est cre´ ee´

pour chaque definition-de-variable´

dans la definition-de-proc´ edure´

ayant

le nom et la sorte de la definition-de-variable´ ;

variable;

2.5

la transition contenu dans le noeud-de-depart-de-proc´ edure´

Communication

est interpret´ ee.´

2.5.1 Canal Grammaire abstraite Definition-de-canal´	:: Nom-de-canal
Chemin-de-canal [Chemin-de-canal ]

Chemin-de-canal :: Bloc-d'origine

Bloc-destinataire Identificateur-de-signal-set Bloc-d'origine =	Identificateur-de-bloc \|
ENVIRONMENT

Bloc-destinataire = Identificateur-de-bloc |

ENVIRONMENT Identificateur-de-bloc =		Identificateur
Identificateur-de-signal = Nom-de-canal = Nom		Identificateur

L'identificateur-de-signal-set doit contenir la liste de tous les signaux qui peuvent | tre achemines´
chemins-de-canal definis´ par le canal.

Une extremit´ e´ du canal doit au moins | tre un bloc.

Si les deux points extr| mes sont des blocs, ceux-ci doivent | tre differents.´

sur le ou les

canal.

<definition´ de canal> ::=

CHANNEL <nom de canal >

[<trajet de canal>]

[<definition´ de sous-structure de canal>

| <ref´ erence´ textuelle de sous-structure de canal>]

ENDCHANNEL [<nom de canal >] <fin>

<trajet de canal> ::=

}

{

FROM <identificateur de bloc > TO <identificateur de bloc >

FROM <identificateur de bloc > TO ENV

FROM ENV TO <identificateur de bloc

WITH <liste de signaux> <fin>

<liste de signaux> est definie´ au § 2.5.5, <definition´ de sous-structure de canal> et <ref´ erence´ textuelle de sous-structure de canal> au § 3.2.3.

Lorsque deux <trajet de canal> sont definis,´ le sens de l'un doit | tre oppose´ par rapport au sens de l'autre.

.bp

<zone de definition´ de canal>::=

is associated with { nom de canal >

{ { identificateur de canal
| identificateur de bloc

	}
			<zone de liste de signaux>[<zone de liste de signaux> } set } is connected to { zone de bloc { zone de bloc \| symbole de cadre } [<zone d'association de sous-structure de canal> } set L'<identificateur de canal > identifie un canal externe relie´ au <diagramme de sous-structure de bloc> delimit´ e	e´

MONTAGE

<symbole de canal 2> ::=

MONTAGE

<symbole de canal 3> ::=

<sp + \| - .bp		<special>´ ::= + \| - \| ! \| / \| > \| * \| ( \| ) \| " \| , \| ; \| < \| = \| : .bp
<special´ == \| \| \| \| \| \| \| \| \| \|		composite> ::= == \| ==> \| /= \| <= \| >= \| // \| := \| => \| -> \| (. \| .)

BLOCK { nom de bloc \| identificateur de bloc } fin> { definition´ de signal> \| <definition´ de liste de signaux> \| <definition´ de processus> \| <ref´ erence´ textuelle de processus>	processus>
\| <definition´ d'acheminement \| <definition´ de macro> \| <definition´ de donnees>´ \| <definition´ de selection>´ \| <connexion de canal vers acheminement	de signal> acheminement }
[<definition´ de sous-structure de ENDBLOCK [<nom de bloc \| identificateur de bloc >] <fin> <ref´ erence´ textuelle de processus>	de bloc \| ref´ erence´ textuelle de sous-structure de bloc>] ::=

trouvent connectes´ au canal. Plusieurs canaux peuvent exister entre deux points d'extremit´ es.		es.´		Le m\| me type de signal peut \| tre achemine´ sur
des canaux differents.´ 2.5.2 Acheminement du signal Grammaire abstraite

Processus-d'origine = Identificateur-de-processus ENVIRONMENT Processus-destinataire =		=		Identificateur-de-processus \| Identificateur-de-processus \|
ENVIRONMENT Nom-d'acheminement-de-signal				= Nom

Identificateur-d'acheminement-de-signal- set Identificateur-d'acheminement-de-signal		=		Identificateur
D'autres constructions sont donnees´ au § 3. Chaque identificateur-de-canal relie´ au		bloc		englobant doit	\| tre mentionne´ dans une seule

Semantique´ Un canal est un moyen de transport pour les signaux. Un canal peut \| tre consider´ e´ comme etant´		un ou deux
trajets de canal unidirectionnels independants´ entre deux blocs ou entre un bloc et son environnement. Les signaux achemines´ par les canaux sont vehicul´ es´ jusqu'au point extr\| me de destination.

Trajet-d'acheminement-du-signal [Trajet-d'acheminement-du-signal ] Trajet-d'acheminement-du-signal	:: Processus-d'origine
Processus-destinataire Identificateur-de-signal- set