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 d'avoir un langage permettant de specifier et de decrire sans ambiguite le comportement des systemes de telecommunication. Les specifications et les descriptions faites a l'aide du LDS doivent | tre formelles dans ce sens qu'il doit | tre possible de les analyser et de les interpreter sans ambiguite. Les termes specification et description sont utilises dans le sens ci-apres: a) la specification d'un systeme est la description du comportement souhaite de celui-ci, et b) la description d'un systeme est la description du comportement reel de celui-ci. Remarque - Etant donne qu'il n'est pas fait de distinction entre l'utilisation du LDS pour la specification et son utilisation pour la description, le terme specification dans le texte qui suit est utilise pour designer a la fois le comportement souhaite et le com- portement reel. Une specification du systeme, au sens large, est la specification a la fois du comportement et d'un ensemble de parametres generaux du systeme. Toutefois, le LDS ne vise qu'a decrire les aspects relatifs au comportement d'un systeme; les parametres generaux concernant des proprietes telles que la capacite et le poids doivent | tre decrits a l'aide de techniques differentes. 1.1.1 Objectifs Les objectifs generaux qui ont ete pris en compte lors de la definition du LDS sont de fournir un langage: a) facile a apprendre, a utiliser et a interpreter; b) permettant l'elaboration de specifications depourvues d'ambiguite 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 specification et de conception de systeme, sans supposer a priori l'une quelconque de ces methodologies. 1.1.2 Domaine d'application Le domaine d'application principal du LDS est la description du comportement des systemes en temps reel dans certains de leurs aspects. Ces applications comprennent: a) le traitement des appels (par exemple: ecoule- ment, signalisation telephonique, comptage aux fins de taxation, etc.) dans les systemes de commutation; b) la maintenance et la releve des derangements (par exemple: alarme, releve automatique des derangements, essais periodiques, etc.) dans les systemes generaux de telecommunication; c) la commande du systeme (par exemple: protection contre les surcharges, procedures de modification et d'extension, etc.); d) les fonctions d'exploitation et de maintenance, la gestion des reseaux; e) les protocoles de communication de donnees. Il va de soi que le LDS peut aussi servir a la specification fonctionnelle du comportement d'un objet lorsque celui-ci peut | tre specifie au moyen d'un modele discret, c'est-a-dire un objet communiquant avec son environnement 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 informelles (et/ou formellement incompletes), des specifications partiellement for- melles et des specifications detaillees. L'utilisateur doit choisir les parties appropriees du LDS en fonction du niveau de communica- tion souhaite et de l'environnement dans lequel le langage sera utilise. Selon l'environnement dans lequel une specification est utilisee, certains elements qui relevent du simple bon sens pour l'emetteur et le destinataire de la specification, ne seront pas explicites. Ainsi, le LDS peut | tre utilise pour: a) etablir les specifications d'une instal- lation, b) etablir les specifications d'un systeme, c) etablir des Recommandations du CCITT, d) etablir des specifications de conception d'un systeme, e) etablir des specifications detaillees, f) concevoir un systeme (a la fois globalement et dans le detail), g) effectuer des essais d'un systeme, l'organisation a laquelle appartient l'utilisateur pouvant choisir le niveau d'application du LDS qui convient. .bp 1.1.3 Specification d'un systeme Le LDS decrit le comportement d'un systeme sous la forme de stimulus/reaction, etant admis que les stimuli aussi bien que les reactions sont des entites discretes et contiennent de l'information. En particulier, la specification d'un systeme est vue comme etant la sequence de reactions associee a une sequence de stimuli. Le modele de specification d'un systeme est fonde sur la notion de machine a etats finis etendue. Le LDS fait appel a des concepts structurels qui facilitent la specification des grands systemes et des systemes complexes. Il est ainsi possible de subdiviser la specification d'un systeme en unites faciles a gerer qui peuvent | tre traitees et comprises de maniere independante. La subdivision peut s'operer en plusieurs etapes qui permettent d'obtenir une structure hierarchique d'unites definissant le systeme a differents niveaux. 1.2 Grammaires du LDS Le LDS offre le choix entre deux formes syntaxiques differentes pour representer un systeme: une representation graphique (LDS/GR) et une representation textuelle (LDS/PR). Comme ces formes sont toutes les deux des representations concretes de la m | me semantique du LDS, elles sont equivalentes du point de vue semantique. En particulier, elles sont toutes les deux equivalentes a une grammaire abstraite en ce qui concerne les concepts correspondants. Un sous-ensemble du LDS/PR est commun avec le LDS/GR. Ce sous-ensemble est appele grammaire textuelle commune. La figure 1.1 montre les relations qui existent entre le LDS/PR, le LDS/GR, les grammaires concretes et la grammaire abstraite. .rs Figure 1.1, p. A chaque grammaire concrete, est associee sa propre syntaxe et les rapports qu'elle a avec la grammaire abstraite (c'est-a-dire la maniere de la transformer en syntaxe abstraite). Avec cette methode, la definition de la semantique du LDS est unique; chacune des grammaires concretes heritera de la semantique par l'intermediaire de ses relations avec la grammaire abstraite. Cette methode permet egalement d'assurer l'equivalence entre le LDS/PR et le LDS/GR. On dispose egalement d'une definition formelle du LDS qui definit la maniere de transformer la specification d'un systeme dans la syntaxe abstraite et comment interpreter une specification, donnee en termes de syntaxe abstraite. 1.3 Definitions fondamentales La presente Recommandation fait appel a des conventions et a des concepts generaux dont les definitions sont donnees ci-apres: 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, jouent un r | le fondamental. Le schema et la terminologie utilises sont explicites ci-apres et illustres par la figure 1.2. .bp Figura 1.2, p. Un type se definit par des definitions, lesquelles definissent toutes les proprietes associees a ce type. Un type peut | tre decompose en un nombre quelconque d'instances. Toute instance d'un type particulier possede toutes les proprietes 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 instances de systeme, des definitions de processus et des instances de processus. Le type de donnees constitue une categorie speciale de type (voir les S 2.3 et 5). Remarque - Pour eviter d'alourdir le texte, on peut s'abstenir d'utiliser le terme instance. Ainsi, pour exprimer qu'une instance du systeme est interpretee, on ecrira <. 1.3.2 Environnement Les systemes qui sont specifies en LDS reagissent d'apres les stimuli qu'ils recoivent du monde exterieur. Ce monde exterieur est appele environnement du systeme en cours de specification. On suppose qu'il y a une ou plusieurs instances de pro- cessus dans l'environnement et, par consequent, les signaux circu- lant de l'environnement en direction du systeme ont des identites associees a ces instances de processus. Ces processus ont des valeurs PId differentes des autres valeurs PId du systeme (voir S 5.6.10). Bien que le comportement du systeme soit non deterministe, il doit obeir aux contraintes imposees par la specification du systeme. 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 interpretee et qu'une condition dynamique se trouve violee, une erreur appara | t. Une interpretation d'une specification de systeme qui conduit a une erreur indique que le comportement du systeme ne peut pas | tre determine a partir de la specification. 1.4 Presentation 1.4.1 Structuration du texte Les S 2, 3, 4 et 5 de la presente Recommandation sont structures par themes, ils comportent des intitules precedes 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. b) Grammaire textuelle concrete - qui concerne a la fois la grammaire textuelle courante utilisee pour le LDS/PR et le LDS/GR et la grammaire uniquement utilisee pour le LDS/PR. Cette grammaire est decrite au moyen d'une syntaxe tex- tuelle, de conditions statiques et de regles de definitions bien formees, concernant la syntaxe textuelle, et de la relation de la syntaxe textuelle avec la syntaxe abstraite. c) Grammaire graphique concrete - decrite par la syntaxe graphique, les conditions statiques et les regles de definitions bien formees concernant la syntaxe graphique, la rela- tion de cette syntaxe avec la syntaxe abstraite et quelques regles de dessin qui viennent en supplement (a celles indiquees au S 2.2.4). .bp d) Semantique - donnant une signification a un type, confere les proprietes de ce type, la facon avec laquelle une instance de ce type est interpretee et toutes conditions dynamiques qui doivent | tre remplies par l'instance de ce type pour avoir un comportement correct au sens du LDS. e) Modele - donne la correspondance avec les abreviations exprimees en termes de constructions en syntaxe concrete stricte precedemment definies. f) Exemples . 1.4.2 Intitules L'introduction qui precede eventuellement les intitules, est uniquement destinee a faciliter la comprehension du texte et a ce titre doit | tre consideree comme etant une partie officieuse de la Recommandation. 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 par- ticuliers utilises dans chaque intitule et les titres utilises. Elle peut egalement | tre consideree comme un exemple de presentation typographique du premier niveau des intitules definis ci-dessus, ce texte appartenant a l'introduction. Grammaire abstraite La notation en syntaxe abstraite est definie au S 1.5.1. L'absence de l'intitule grammaire abstraite indique qu'il n'existe pas d'autres syntaxes abstraites pour le sujet traite et que la syntaxe concrete correspond a la syntaxe abstraite definie par une autre section de texte numerotee. On peut se referer a une des regles dans la syntaxe abstraite a partir de tout intitule en maintenant le nom de la regle en italique. Les regles dans la notation formelle peuvent | tre suivies par des paragraphes qui definissent les conditions qui doivent | tre satisfaites par une definition LDS bien formee et qui peuvent | tre verifiees sans interpretation d'une instance. Les conditions statiques a ce niveau se referent uniquement a la syntaxe abstraite. Les conditions statiques qui ne concernent seulement que la syntaxe concrete sont definies posterieurement a la syntaxe concrete. La syntaxe abstraite, associee aux conditions statiques applicables a la syntaxe abstraite, definit la grammaire abstraite du langage. Grammaire textuelle concrete La syntaxe textuelle concrete est specifiee au moyen de la Backus-Naur Form (BNF) etendue de la description de la syntaxe definie au S 2.1 de la Recommandation Z.200 (voir egalement le S 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 verifiees sans interpretation d'une instance. Cela s'applique egalement aux condi- tions statiques, si elles existent, pour la grammaire abstraite. Dans de nombreux cas, il y a une simple relation entre la syntaxe concrete et la syntaxe abstraite etant donne qu'une regle de la syntaxe concrete est simplement representee par une seule regle dans la syntaxe abstraite. Lorsque le m | me nom est utilise dans la syntaxe abstraite et dans la syntaxe concrete, afin d'indiquer qu'il represente le m | me concept, le texte precisant que << dans la syntaxe concrete represente X dans la syntaxe abstraite>> est implicite dans la description du langage et est souvent omis. Dans ce contexte, le cas est ignore mais les sous-categories semantiques soulignees sont significatives. La syntaxe textuelle concrete qui ne constitue pas une forme abregee (syntaxe derivee modelisee par d'autres constructions LDS) est une syntaxe textuelle concrete stricte. La relation entre la syntaxe textuelle concrete et la syntaxe abstraite est seulement definie pour la syntaxe textuelle concrete stricte. La relation entre la syntaxe textuelle concrete et la syn- taxe abstraite est omise si le sujet en cours de definition est une forme abregee qui est modelisee par d'autres constructions LDS (voir le paragraphe modele ci-apres). Grammaire graphique concrete La syntaxe graphique concrete est specifiee dans la forme BNF elargie de la description de la syntaxe definie au S 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 verifiees sans interpretation d'une instance. Cela s'applique egalement aux condi- tions statiques, si elles existent, pour la grammaire abstraite. La relation entre la syntaxe graphique concrete et la syn- taxe abstraite est omise si le sujet en cours de definition est une forme abregee qui est modelisee par d'autres constructions LDS (voir le paragraphe modele ci-apres). Dans de nombreux cas, il existe une simple relation entre les diagrammes de la grammaire graphique concrete et les definitions de la syntaxe abstraite. Lorsque le nom d'un non-terminal commence dans la grammaire concrete par le mot <> et qu'il y a un nom dans la grammaire abstraite qui en differe seulement parce qu'il commence par le mot definition , les deux regles representent la m | me notion. Par exemple, dans la grammaire concrete correspond a la Definition-de-systeme dans la grammaire abstraite. L'expansion dans la syntaxe concrete provenant de constructions telles les definitions differees (S 2.4.1), les macros (S 4.2) et les mises en correspondance de litteraux (S 5.4.1.15) etc., doit | tre examinee avant la mise en correspondance entre la syntaxe concrete et la syntaxe abstraite. Semantique Des proprietes sont utilisees dans les regles de bonne formation qui font intervenir soit le type soit d'autres types qui se referent a ce type. Un exemple de propriete est l'ensemble des identificateurs de sig- naux d'entree valides d'un processus. Cette propriete est utilisee dans la condition statique <>. Toutes les instances ont une propriete d'identite mais a moins que celle-ci soit formee d'une facon quelque peu inhabituelle, cette propriete d'identite est determinee comme etant definie par la sec- tion generale traitant des identites au S 2. Par consequent, cela n'est pas habituellement mentionne comme etant une propriete d'identite. Il n'est egalement pas necessaire d'indiquer les sous-composantes d'une definition contenues par la definition etant donne que l'appartenance de telles sous-composantes est evidente a partir de la syntaxe abstraite. Par exemple, il est evident qu'une definition de bloc <> englobe des definitions de processus et eventuellement une definition de sous-structure de bloc. Les proprietes sont statiques, si elles peuvent | tre determinees sans l'interpretation d'une specification de systeme en LDS et sont dynamiques si l'interpretation de ce systeme est necessaire pour determiner la propriete. L'interpretation est decrite de maniere operationnelle. Lorsqu'il y a une liste dans la syntaxe abstraite, cette liste est interpretee dans l'ordre donne. C'est-a-dire la Recommandation decrit comment les instances sont creees a partir de la definition du systeme et comment celles-ci sont interpretees dans une <>. Les conditions dynamiques sont des conditions qui doivent | tre satisfaites durant l'interpretation et qui ne peuvent | tre verifiees sans interpretation. Les conditions dynamiques peuvent conduire a des erreurs (voir le S 1.3.3). Modele Certaines constructions sont considerees comme etant une <> (ou une abreviation) pour d'autres constructions equivalentes en syntaxe concrete. Par exemple, l'omission d'une entree pour un signal est une syntaxe concrete derivee pour une entree pour ce signal suivi par une transition nulle avec retour vers le m | me etat. Dans certains cas, une telle <>, si elle est etendue, donnera lieu a une representation immensement grande (eventuellement infinie). Neanmoins, la semantique d'une telle specification peut | tre determinee. Exemples L'intitule exemples contient des exemples. 1.5 Metalangages Pour la definition des proprietes et des syntaxes du LDS, differents metalangages ont ete utilises en fonction des besoins particuliers. Dans ce qui suit, on trouvera une introduction aux metalangages; des references renvoyant a des livres ou a des publi- cations particulieres de l'UIT seront donnees au besoin. 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 consideree 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 :: Nom-de-variable Identificateur-de-reference-de-sorte qui definit le domaine de l'objet composite (arborescence) appele definition-de-variable . Cet objet comporte deux sous-composantes qui a leur tour peuvent | tre des arborescences. La definition en Meta IV Identificateur-de-reference-de-sorte = Identificateur indique qu'un identificateur-de-reference-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 elementaires (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 com- posite contenant deux des valeurs entieres (entier ) indiquant le nombre initial et le nombre maximal d'instances. b) Mots cles Les mots cles sont representes par une sequence en caracteres gras de majuscules et de chiffres. Exemple: Processus-de-destination = Identificateur-de-processus | ENVIRONNEMENT Le processus-de-destination est soit un identificateur-de-processus soit l'environnement qui est designe par le mot cle ENVIRONNEMENT . c) Marques Le terme Token designe le domaine des marques. Ce domaine peut | tre considere comme etant compose 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 specifies Un objet non specifie designe des domaines qui peu- vent avoir une certaine representation, mais pour lesquels la representation n'interesse pas la presente Recommandation. Exemple: Texte-informel :: ... Texte-informel contient un objet qui n'est pas interprete. Les operateurs ci-apres (constructeurs) dans la forme BNF (voir le S 1.5.2) sont egalement utilises dans la syntaxe abstraite: <<*>> pour designer une liste pouvant | tre vide; <<+>> pour designer une liste non vide; < | > pour representer une alternative, et <<[<< >>]>> pour indiquer une option. Les parentheses sont utilisees pour regrouper les domaines qui presentent un rapport logique. Enfin, la syntaxe abstraite utilise un autre operateur de suffixe <<-set >> produisant un ensemble (collection non ordonnee d'objets distincts). Exemple: graphe-de-processus :: noeud-de-depart-de-processus noeud-d'etat -set Un graphe-de-processus est constitue par un noeud-de-depart-de-processus et d'un ensemble de noeud-de-processus . 1.5.2 Backus-Naur Form Dans la Backus-Naur Form (BNF), un symbole terminal est soit celui qui n'est pas mis entre crochets angulaires (c'est-a-dire le signe inferieur a ou le signe superieur a, ) ou est l'une des deux representations et . Notons que les deux terminaux speciaux et peuvent avoir egalement une semantique telle que celle qui est definie ci-apres. Les crochets angulaires et le(s) mot(s) sont soit un sym- bole non-terminal ou l'un des deux terminaux ou . Les categories syntaxiques sont les non-terminaux indiques par un ou plusieurs mots compris entre des crochets angulaires. Pour chaque symbole non-terminal, une regle de production est donnee soit en grammaire textuelle concrete soit en grammaire graphique. Par exemple: ::= VIEW (, ) Une regle de production d'un symbole non-terminal consiste a placer le symbole non-terminal sur la partie gauche du 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 , et dans l'exemple ci-dessus sont des symboles non-terminaux; VIEW, les parentheses et le point sont des symboles terminaux. .bp Parfois, le symbole inclut une partie soulignee. Cette partie soulignee met en relief un aspect semantique de ce symbole. Par exemple est syntaxiquement identique a , mais sur le plan 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, separes par des barres verticales | . Par exemple: ::= | indique qu'une est soit une ou un . Les elements syntaxiques peuvent | tre regroupes au moyen d'accolades { | t } , analogues aux parentheses du Meta IV (voir le S 1.5.1). Un groupe entre accolades peut contenir une ou plusieurs barres verticales, indiquant des elements syntaxiques possibles. Par exem- ple: ::= { zone de bloc> | contient au moins une ou une et peut contenir plusieurs autres et . Si les elements syntaxiques sont regroupes en utilisant des crochets ([ | t | ), cela indique que le groupe est facultatif. Par exemple: ::= PROCESS [] indique qu'un peut, mais pas necessairement, contenir des . 1.5.3 Metalangage applicable a la grammaire graphique En ce qui concerne la grammaire graphique, le metalangage decrit au S 1.5.2 est complete avec les metasymboles suivants: a) contains b) is associated with c) is followed by d) is connected to e) set Le metasymbole set est un operateur postfixe agissant sur les elements syntaxiques places a l'interieur d'accolades et qui le precedent immediatement, il designe un ensemble (non ordonne) d'elements. Chaque element peut | tre un groupe quelconque d'elements syntaxiques, auquel cas, il faut le developper avant d'appliquer le metasymbole set . Exemple: { zone de texte de systeme } { diagramme de macro } ; de zero, d'un ou plusieurs et une . Tous les autres metasymboles sont des operateurs infixes, ayant un symbole graphique non-terminal comme argument de gauche. L'argument de droite est soit un groupe d'elements syntaxiques situes a l'interieur d'accolades ou un seul element syntaxique. Si le membre de droite d'une regle de production comporte un symbole graphique non-terminal comme premier element 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 sym- bole graphique non-terminal est un nom terminal ayant le mot <> place immediatement avant le signe <. Le metasymbole contains indique que son argument de droite doit | tre place a l'interieur de son argument de gauche et, le cas echeant, a l'interieur du associe. Par exemple: ::= contains ::= .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 <> dans cet argument, l'association depourvue d'ambiguite est obtenue par des regles appropriees applicables aux dessins). Le metasymbole is followed by signifie que son argument de droite suit (tant sur le plan logique que dans le dessin) son argu- ment de gauche. Le metasymbole is connected to signifie que son argument de droite est relie (tant sur le plan logique que dans le dessin) a son argument de gauche. .rs 2 Le LDS de base 2.1 Introduction Un systeme LDS possede un ensemble de blocs. Les blocs sont connectes entre eux et a l'environnement par des canaux. A l'interieur de chacun des blocs il y a un ou plusieurs processus. Ces processus communiquent entre eux par des signaux et sont supposes s'executer en parallele. Le S 2 a ete subdivise en huit principaux sujets: a) Regles generales Les concepts de base du LDS tels les regles lexi- cales et les identificateurs, les regles de visibilite, les textes informels, la subdivision des diagrammes, les regles applicables aux dessins, les commentaires, les extensions de textes, les sym- boles de texte. b) Concepts de base concernant les donnees Les concepts de base concernant les donnees en LDS telles les valeurs, les variables, les expressions. c) Structure des systemes Contient les concepts du LDS relatifs aux principes generaux de structuration du langage. Il s'agit des concepts de systeme, de bloc, de processus, de procedure. d) Communication Decrit les mecanismes de communication utilises dans le LDS tels le canal, l'acheminement du signal, le signal. e) Comportement Les constructions qui concernent le comportement d'un processus: regles de connectivite generales d'un processus ou graphe de procedure, definition de variable, depart, etat, entree, mise en reserve, etiquette, transition. f) Action Constructions actives tels les t | ches, la creation de processus, l'appel de procedure, la sortie, la decision. g) Temporisateurs Definition des temporisateurs et primitives des temporisateurs. h) Exemples Il s'agit d'exemples concernant les autres points. 2.2 Regles generales 2.2.1 Regles lexicales Les regles lexicales definissent des unites lexicales. Les unites lexicales sont les symboles terminaux de la syntaxe textuelle concrete. ::= | | | | | ::= { | souligne> } ::= { alphanumerique> | { alphanumerique> | } ::= | | | ::= 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 .bp ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ::= ## | .` Montage | O Montage | Montage | | Montage | | | | | | ::= [ ::= ] ::= { ::= | ::= } ::= .~ Montage ::= .^ Montage ::= . ::= - ::= { alphanumerique> | | | | | | ::= { alphanumerique> | | | | | | ::= ` ::= ? | & | % ::= + | - | ! | / | > | * | ( | ) | " | , | ; | < | = | : .bp ::= == | ==> | /= | <= | >= | // | := | => | -> | (. | .) ::= /* */ ::= | 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 represente le caractere espace de l'Alphabet no 5 du CCITT. Les caracteres sont representes ci-dessus de la m | me facon que la version internationale de reference de l'Alphabet no 5 du CCITT (Recommandation T.50). La responsabilite de la definition des representations nationales de ces caracteres releve des organismes nationaux de normalisation. .bp Toutes les sont toujours traitees comme des majuscules sauf celles qui sont a l'interieur d'une . (Le traitement des peut | tre defini par les organismes nationaux de normalisation.) Une se termine par le premier caractere qui ne peut pas faire partie de l' conformement a la syntaxe specifiee ci-dessus. Lorsqu'un caractere est suivi d'un ou plusieurs caracteres de commande (les caracteres de commande sont definis comme dans la Recommandation T.50) ou espaces, tous ces caracteres (y compris le ) sont ignores, par exemple A _B correspond au m | me que AB. Cet emploi de permet de repartir des sur plus d'une ligne. Lorsqu'un caractere est suivi d'un dans un , il est autorise a specifier un ou plusieurs caracteres de commande ou espaces, au lieu du caractere , pour autant que l'un des englobant le caractere ne forme pas un , par exemple A B designe le m | me que A _B. Toutefois, dans certains cas, l'absence de dans les est ambigue. Les regles suivantes s'appliquent donc: 1) les dans le dans un doivent | tre specifies explicitement; 2) lorsqu'un ou plusieurs ou peuvent | tre suivis directement par une (par exemple, , ), les dans ces ou doivent | tre specifies explicitement; 3) lorsqu'une con- tient des , les du suivant le mot cle NEWTYPE doivent | tre specifies expli- citement. Un caractere de commande a la m | me signification qu'un espace. Les caracteres de commande et les espaces peuvent appara | tre un nombre quelconque de fois entre deux . Un nombre quelconque de caracteres de contr | le et d'espaces entre deux ont la m | me signification qu'un espace. Le caractere / immediatement suivi par le caractere * marque toujours le debut d'une . Le caractere * immediatement suivi par le caractere / dans une marque toujours la fin d'une . Une peut | tre inseree avant ou apres toute . Des regles lexicales particulieres s'appliquent dans un (voir le S 4.2.1). 2.2.2 Regles de visibilite et identificateurs Grammaire abstraite Identificateur :: Qualificatif-Nom Qualificatif = Element-de-chemin + Element-de-chemin = Qualificatif-de-systeme | Qualificatif-de-bloc | Qualificatif-de-sous-structure-de-bloc | Qualificatif-de-signal | Qualificatif-de-processus | Qualificatif-de-procedure | Qualificatif-de-sorte | Qualificatif-de-systeme :: Nom-de-systeme Qualificatif-de-bloc :: Nom-de-bloc Qualificatif-de-sous-structure-de-bloc :: Nom-de-sous-structure-de-bloc Qualificatif-de-processus :: Nom-de-processus Qualificatif-de-procedure :: Nom-de-procedure Qualificatif-de-signal :: Nom-de-signal Qualificatif-de-sorte :: Nom-de-sorte Nom :: Token Grammaire textuelle concrete ::= [] ::= { ::= .bp ::= | SYSTEM | BLOCK | SUBSTRUCTURE | SIGNAL | PROCESS | PROCEDURE | TYPE | SERVICE Il n'y a pas de syntaxe abstraite correspondante pour la indiquee par service. Les et d'entites definies dans une sont transformes en uniques ou en uniques definis dans la contenant la . Le reflete la structure hierarchique a par- tir du niveau du systeme vers le contexte de definition, et de maniere telle que le niveau du systeme est la partie textuelle la plus a gauche. Toutefois, on peut omettre certains les plus a gauche, lorsque le premier res- tant le plus a gauche dans le est unique a l'interieur de toute la . Il est permis d'omettre certains les plus a gauche (sauf pour les , voir le S 2.4.1) ou bien tout le . Lorsque tout le est omis et que le designe une entite de la classe d'entite con- tenant des variables, des synonymes, des litteraux et des operateurs (voir la semantique ci-apres), l'association du avec une definition doit pouvoir | tre resolue par le contexte reel. Dans d'autres cas, l' est associe a une entite qui a son contexte de definition dans l'unite de portee englobante la plus proche dans laquelle le de l' est le m | me que la partie la plus a droite du complet designant cette unite de portee. Si l' ne contient pas de , la necessite de mise en correspondance des est omise. Un sous-signal doit | tre qualifie par ses signaux parents, a moins qu'aucun autre signal visible n'existe a cet endroit qui porte le m | me . La resolution par contexte est possible dans les cas suivants: a) l'unite de portee dans laquelle le est utilise n'est pas une et con- tient une definition ayant ce . Le sera lie a cette definition; b) l'unite de portee dans laquelle le est utilise ne contient pas de definition ayant ce ou l'unite de portee est une , et dans toute la il existe exactement une definition visible d'une entite qui a le m | me et a laquelle le peut | tre lie sans violer aucune des proprietes sta- tiques (compatibilite de sorte, etc.) de la construction dans laquelle le appara | t. Le sera lie a cette definition. Seuls les identificateurs visibles peuvent | tre utilises, a l'exception de l' dans une et de l' utilise a la place d'un dans une definition referencee (c'est-a-dire une definition extraite de la ). Semantique Les unites de portee sont definies par le schema suivant: Grammaire textuelle concrete Grammaire graphique concrete .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 , la liste de definitions associee comprend les , les et toutes et provenant d'une sorte parente, d'un generateur d'instance ou impose par l'utilisation d'abreviations tel le mot cle ORDERING (voir le S 5.4.1.8). Il faut remarquer qu'une ne definit pas une entite. Bien que les , les avec un point d'exclamation et les aient leur propre notation syntaxique, ils sont en realite des , ils sont representes dans la syntaxe abstraite representee par un nom suit, ils sont etudies comme s'ils etaient (syntaxiquement aussi) des . Toutefois, les , les , les , les dans les equations, les et les ont des regles de visibilite particulieres et ne peuvent par consequent | tre qualifies. Leurs regles de visibilite sont expliquees dans les sections concernees. Chaque entite est dite avoir son contexte de definition dans l'unite de portee qui la definit. Les entites sont referencees au moyen d'. Le dans un specifie uniquement le contexte de definition du . Les classes d'entites sont les suivantes: a) systeme b) blocs c) canal, acheminement de signaux d) signaux, temporisateurs e) processus f) procedures g) variables (y compris les parametres formels), synonymes, litteraux, operateurs h) sortes i) generateurs j) entites importees k) listes de signaux l) services m) sous-structures de bloc, sous-structures de canal Un est dit | tre visible dans une unite de portee a) si la partie nom de l' 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 dans laquelle l' est defini, ou d) si l'unite de portee contient une dans laquelle l' se trouve defini. On ne peut avoir deux definitions dans la m | me unite de portee et appartenant a la m | me classe d'entites portant le m | me . Il existe cependant une exception: les definitions de et de dans la m | me (voir le S 5.2.2): plusieurs operateurs et litteraux peuvent avoir le m | me avec differentes ou differentes sortes de . On notera une autre exception: les entites importees. Pour cette classe, les paires de (, ) dans dans l'unite de portee doivent | tre dis- tinctes. Dans la grammaire textuelle concrete, le nom ou l'identificateur optionnel dans une definition apres le mot cle de 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 :: ... Grammaire textuelle concrete ::= Semantique Lorsqu'un texte informel est utilise dans une specification LDS de systeme, il signifie que le texte n'est pas en LDS formel, c'est-a-dire que le LDS ne donne pas de semantique. La semantique du texte informel peut | tre definie par d'autres moyens. 2.2.4 Regles applicables aux dessins La taille des symboles graphiques est choisie par l'utilisateur. Les frontieres des symboles ne doivent ni se superposer, ni se couper. Font exception a cette regle les symboles de ligne, c'est-a-dire le , le , le , le , le et le , qui peuvent se couper. Il n'existe pas d'association logique entre les symboles qui se coupent. Le metasymbole is followed by implique un . Les symboles de ligne peuvent | tre constitues par un ou plusieurs segments de droite en trait plein. Les fleches sont necessaires chaque fois qu'un entre dans un autre , dans un ou dans un . Dans d'autres cas, ces fleches sont facultatives sur les . Les sont horizontaux ou verticaux. On peut utiliser des images symetriques verticales des , des , des et des . 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 elements syntaxiques de l'argument de droite doivent pouvoir | tre distingues les uns des autres. Le texte situe a l'interieur d'un symbole graphique doit | tre lu de la gauche vers la droite, en partant du coin superieur gauche. La limite droite du symbole est interpretee comme un caractere de nouvelle ligne, indiquant le cas echeant que la lecture doit continuer au point le plus a gauche de la ligne suivante. 2.2.5 Subdivision des diagrammes La definition qui suit concernant la division des diagrammes ne fait pas partie de la grammaire graphique concrete , neanmoins, on utilise le m | me metalangage. ::= contains { zone d'en-t | te> { unite syntaxique } } ::= contains ::= contains [ [()] | ::= ::= .bp La est un non-terminal de depart, par consequent, il n'est associe a aucune regle de production. Un diagramme peut | tre subdivise en un nombre de , auquel cas le delimitant le diagramme et l' du diagramme est remplace par un et un pour chaque . L'utilisateur du LDS peut choisir les imposes par la limite du support sur lequel les diagrammes sont reproduits. Afin d'avoir une separation nette entre la et la , le n'est pas materialise, il est sous-entendu. La est placee au coin superieur gauche du , la est situee au coin superieur droit du . L' et l' 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. Dans la grammaire textuelle concrete , on utilise deux formes de commentaires. La premiere forme est la definie au S 2.2.1. Des exemples sont donnes aux figures 2.9.1 et 2.9.3. La syntaxe concrete de la deuxieme forme est: ::= []; ::= COMMENT Un exemple est donne a la figure 2.9.2. Dans la grammaire graphique concrete , la syntaxe suivante est utilisee: ::= contains is connected to ::= .rs Figure, p. 29 (E) ::= ------------ Une des extremites du doit | tre reliee au milieu du segment vertical du . Un peut | tre relie a tout sym- bole graphique au moyen d'un . Le est considere 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. Un exemple est donne a la figure 2.9.4 dans le S 2.9. 2.2.7 Extension de texte ::= contains is connected to ::= ::= Une des extremites du doit | tre reliee au milieu du segment vertical du . Un peut | tre relie a tout symbole graphique au moyen d'un . Le est considere 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 considere comme etant contenu dans ce symbole. 2.2.8 Symbole de texte Le est utilise dans tout . Le contenu depend du diagramme. ::= .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 S 5; plus precisement en ce qui concerne la terminologie du LDS pour ce qui est des donnees et la facilite a definir des nouveaux types de donnees et les facilites concernant les donnees predefinies. Les donnees apparaissent dans les definitions du type de donnees, les expressions, l'application d'operateurs, les vari- ables, 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 ensemble de valeurs, un ensemble d'operateurs qui peut | tre applique a ces valeurs, et un ensemble de regles algebriques (equations) qui definissent le comportement de ces operateurs lorsqu'ils sont appliques aux valeurs. Les valeurs, les operateurs et les regles algebriques definissent tous ensemble les proprietes du type de donnees. Ces proprietes sont definies par les definitions de types de donnees. Le LDS permet la definition de tout type de donnees qui est necessaire, y compris les mecanismes de composition (type compo- site) avec pour seule contrainte qu'une telle definition puisse | tre specifiee de maniere formelle. En revanche, pour les langages de programmation, il y a des considerations de mise en oeuvre qui necessitent que l'ensemble des types de donnees disponibles et, en particulier, les mecanismes de composition mis a disposition soient limites (tableau, structure, etc.). 2.3.2 Variables Les variables sont des objets qui peuvent | tre associes a une valeur par une affectation. Quand on accede a la variable, on ren- voie 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 les valeurs des sortes. Par exemple, l'application de l'operateur somme (<<+>>) a partir et vers les valeurs de la sorte entiere est valable, tandis que la somme de la sorte booleenne ne l'est pas. .bp Toutes les sortes ont au moins une valeur. Chaque valeur appartient a une sorte unique, c'est-a-dire que les sortes 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 entiers <<2>> est utilise de preference a <<1+1>>). Il peut y avoir plusieurs litteraux qui decrivent la m | me valeur (par exemple, 12 et 012 peuvent | tre utilises pour decrire la m | me valeur entiere). La m | me description litterale peut | tre utilisee pour plus d'une sorte; par exemple, `A` est a la fois un caractere et une cha | ne de caracteres de longueur 1. 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 des variables peut | tre interpretee comme differentes valeurs durant l'interpretation d'un systeme LDS selon la valeur associee aux variables. 2.4 Structure du systeme 2.4.1 Definitions differees Une est une definition qui a ete supprimee de son contexte de definition pour accro | tre la visibilite. Elle est analogue a une definition de macro (voir le S 4.2), mais elle est <> d'un seul endroit exactement (le contexte de definition) en util- isant une reference. Grammaire concrete ::= | ::= { definition textuelle de systeme> | ::= | | | | | | ::= | | | | | | Pour chaque , sauf pour des et des , on doit avoir une reference dans la , le , ou une autre . Pour chaque reference on doit avoir une correspondante. Dans chaque , on doit avoir un place immediatement apres le mot cle initial. Dans cet , le doit | tre soit complet, soit omis. Si le est omis, le doit | tre unique dans la definition de systeme, a l'interieur de la classe d'entite pour la . On ne peut pas specifier un qualifi- catif dans l' apres le mot cle initial pour les definitions qui ne sont pas des (c'est-a-dire qu'un doit | tre specifie pour les definitions normales). Semantique Avant de pouvoir analyser une , chaque reference doit | tre remplacee par la correspondante. Dans cette substitution, l' de la est remplace par le dans la reference. .bp 2.4.2 Systeme Grammaire abstraite Definition-de-systeme :: Nom-de-systeme Definition-de-bloc -set Definition-de-canal -set Definition-de-signal -set Definition-de-type-de-donnees Definition-de-type-de-synonyme -set Nom-de-systeme = Nom Une definition-de-systeme a un nom qui peut | tre utilise dans les qualificatifs. La definition-de-systeme doit au moins contenir une definition-de-bloc . Les definitions de tous les signaux, canaux, types de donnees, types de synonymes utilises dans l'interface avec l'environnement et entre les blocs du systeme sont contenues dans la definition-de-systeme donnees predefinies sont considerees comme etant definies au niveau du systeme. Grammaire textuelle concrete ::= SYSTEM { definition de bloc> | | | | | | | ] ::= BLOCK REFERENCED est definie au S 4.3.3, au S 4.2, au S 5.5.1, au S 2.4.3, au S 2.5.1, au S 2.5.4, au S 2.5.5. Un exemple de est donne a la fig- ure 2.9.5 du S 2.9. Grammaire graphique concrete ::= contains { en-t | te de systeme> { { zone texte de systeme } | { diagramme de macro } { ::= Figura 6, p. ::= SYSTEM ::= contains { definition de signal> | | | | ::= { zone de bloc> | ::= | ::= contains ::= Figura 7, p. est definie au S 4.3.3, au S 4.2, au S 4.2, au S 5.5.1, au S 2.4.3, au S 2.5.1, au S 2.5.4, au S 2.5.5. La definition-de-bloc -set dans la grammaire abstraite correspond aux , la definition-de-canal- set a la . Un exemple d'un est donne a la fig- ure 2.9.6. Semantique Une definition-de-systeme est la representation en LDS d'une specification ou de la description d'un systeme. Un systeme est separe de son environnement par une frontiere de systeme et contient un ensemble de blocs. La communication entre le systeme et l'environnement, ou entre les blocs interieurs au systeme ne peut se faire qu'au moyen de signaux. A l'interieur d'un systeme, ces signaux sont vehicules dans des canaux. Les canaux relient les blocs entre eux ou a la frontiere du systeme. Avant d'interpreter une definition-de-systeme , on choisit un sous-ensemble coherent (voir le S 3.2.1). Ce sous-ensemble est appele une instance de la definition-de-systeme . Une instance de systeme est une instanciation d'un type de systeme defini par une definition-de-systeme L'interpretation d'une instance d'une definition-de- systeme est realisee par une machine abstraite LDS qui en consequence donne la semantique aux concepts du LDS. Pour interpreter une instance d'une definition-de-systeme , il faut: a) initialiser le temps du systeme, b) interpreter les blocs et les canaux qui leur sont relies et qui sont contenus dans le sous-ensemble de subdivi- sion coherent choisi. 2.4.3 Bloc Grammaire abstraite Definition-de-bloc :: Nom-de-bloc Definition-de-processus -set Definition-de-signal -set Connexion-de-canal-vers-acheminement -set Definition-d'acheminement-de-signal -set Definition-de-type-de-donnees Definition-de-type-de-synonyme -set [Definition-de-sous-structure-de-bloc ] Nom-de-bloc = Nom A moins qu'une definition-de-bloc ne contienne une definition-de-sous-structure-de-bloc , on doit avoir au moins une definition-de-processus et une definition-d'acheminement-de-signal a l'interieur du bloc. Il est possible de subdiviser les blocs en specifiant la definition-de-sous-structure-de-bloc ; cet aspect du langage est etudie au S 3.2.2. .bp Grammaire textuelle concrete ::= BLOCK { nom de bloc | identificateur de bloc } fin> { definition de signal> | | | | | | | | ] ENDBLOCK [] ::= PROCESS [] REFER- ENCED est definie au S 2.5.4, au S 2.5.5, au S 2.4.4, au S 2.5.2, au S 2.5.3, au S 3.2.2, au S 3.2.2, au S 4.2.2, au S 5.5.1. Un exemple de est montre a la figure 2.9.7 au S 2.9. Grammaire graphique concrete ::= contains { en-t | te de bloc> { { zone texte de bloc } { diagramme de macro } [] [ } set } is associated with { identificateur de canal } L' identifie un canal relie a un achem- inement de signaux dans le . Il se trouve place a l'exterieur du , a proximite de l'extremite du trajet du signal arrivant au . Si le ne contient pas une , il doit alors contenir une . ::= BLOCK { nom de bloc | identificateur de bloc } ::= ::= { zone de processus> | | ::= ::= contains { nom de processus >[ } ::= Figura 8, p. Le terme est defini au S 2.4.4. ::= is connected to { zone de processus> ::= -------------- La t | te de fleche placee sur le indique la sur laquelle le processus de creation a lieu. Le est defini au S 2.4.4, la au S 2.5.2, la au S 3.2.2, le au S 4.2.2. Un exemple de est donne a la figure 2.9.8 au S 2.9. 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. Interpreter un bloc consiste a creer les processus ini- tiaux dans le bloc. 2.4.4 Processus Grammaire abstraite Definition-de-processus :: Nom-de-processus Nombre-d'instances Parametre-formel-de-processus | Definition-de-procedure-set Definition-de-signal-set Definition-de-type-de-signal Definition-de-type-de-synonyme-set Definition-de-variable-set Definition-de-visibilite-set Definition-de-temporisateur- set Graphe-de-processus Nombre-d'instances :: Entier Entier Nom-de-processus = Nom Graphe-de-processus :: Noeud-de-depart-de-processus Noeud-d'etat- set Parametre-formel-de-processus :: Nom-de-variable Identificateur-de-reference-de-sorte Grammaire textuelle concrete ::= PROCESS { identificateur de processus | nom de processus } [] [ ] [] { definition de signal> | | | | | | | | | | | ] ::= PROCEDURE REFERENCED ::= SIGNALSET [] ::= ::= FPAR { ::= ([], []) ::= ::= Le nombre initial d'instances et le nombre maximal d'intances con- tenus dans le nombre-d'instances sont tires du . Si le est omis, le est 1. Si le est omis, le n'est pas limite. Le utilise dans la derivation est le suivant: a) s'il n'y a pas de pour le processus, le dans la est utilise. S'il ne contient pas un , on utilise le ou le et le sont omis; b) si a la fois le dans la et le dans une sont omis, on utilise le ou sont omis a la fois le et le ; c) si soit le dans la soit le dans une est omis, le est celui qui est present; d) si a la fois le dans la et le dans une sont specifies, les deux doivent | tre egaux lexicalement et ce est utilise. Une relation analogue s'applique au specifie dans le et dans la definis ci-dessous. est definie au S 2.5.4, au S 2.5.5, au S 2.6.1.2, au S 2.6.1.1, au S 2.4.5, au S 2.8, au S 4.2.2, au S 4.1.3, au S 4.3.3, au S 4.3.2, au S 4.10.1, au S 5.5.1. Le d'instances doit | tre inferieur ou egal au et le doit | tre superieur a zero. L'utilisation du terme est precisee au S 2.5.2, modele . Un exemple de est donne a la figure 2.9.9 du S 2.9. Grammaire graphique concrete ::= 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 } ] L' identifie le trajet externe d'un signal relie a un trajet de signal dans le . Il est place a l'exterieur du a proximite de l'extremite du trajet du signal au . ::= contains { [] { definition de signal> | | | | | | | | ::= PROCESS { nom de processus | identificateur de processus } [ [] ] [] ::= est definie au S 2.5.4, au S 2.5.5, au S 2.6.1.2, au S 2.6.1.1, au S 2.4.5, au S 2.8, et au S 4.2.2, au S 4.1.3, au S 4.3.3, au S 5.5.1, au S 2.6.2, au S 2.6.3, au S 2.6.6 et au S 4.10.1. Un exemple de est donne a la fig- ure 2.9.10 du S 2.9. Semantique Une definition de processus introduit le type d'un pro- cessus qui est destine a representer un comportement dynamique. Dans le nombre-d'instances, la premiere valeur represente le nombre-d'instances du processus qui existe a la creation du systeme, la deuxieme valeur represente le nombre maximal d'instances simultanees du type de processus. Une instance de processus est une machine a etats finis etendue communicante qui assure un certain nombre d'actions, appelees transitions, suite a la reception d'un signal donne, chaque fois qu'elle se trouve dans un certain etat. La realisation de la transition aboutit a l'attente du processus dans un autre etat, qui n'est pas necessairement different de l'etat d'origine. Le concept de machine a etats finis a ete etendu en ce sens que l'etat resultant d'une transition, a c | te du signal provoquant la transition, peut | tre affecte par des decisions prises a partir de variables connues du processus. Plusieurs instances du m | me type de processus peuvent exister au m | me instant et s'executer de maniere asynchrone et en parallele les unes aux autres, et avec d'autres instances de differents types de processus dans le systeme. Lorsqu'un systeme est cree, les processus initiaux sont crees dans un ordre aleatoire. La communication des signaux entre les pro- cessus ne commence que lorsque tous les processus initiaux ont ete crees. Les parametres formels de ces processus initiaux sont initialises avec une valeur non definie. Les instances de processus existent a partir du moment ou un systeme est cree ou peuvent | tre creees par une des actions de demande de creation qui lance les processus a interpreter; leur interpretation commence lorsque l'action de depart est interpretee; 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 sig- naux conduisant au processus, de l', des signaux implicites et des signaux de temporisation. .bp Un acces d'entree unique est associe a chaque instance de pro- cessus. Lorsqu'un signal d'entree parvient au processus, il est applique a l'acces d'entree de l'instance de processus. 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 S 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. L'acces d'entree peut retenir un nombre quelconque de sig- naux, de sorte que plusieurs signaux entrants sont mis 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. Lorsqu'un processus est cree, on lui attribue un acces d'entree vide, et il y a alors creation de variables locales aux- quelles on affecte des valeurs. Les parameres formels sont des variables qui sont creees soit lorsque le systeme est cree (mais aucun parametre reel ne lui est transmis et par consequent ces parametres ne sont pas initialises), soit lorsque l'instance de processus est dynamiquement creee. Pour toutes les instances de processus, on peut utiliser quatre expressions produisant un PId (voir le S 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 creee par le processus (OFFSPRING); d) l'instance de processus en provenance de laquelle le dernier signal entrant a ete utilise (SENDER) (voir egalement le S 2.6.4). Ces expressions sont expliquees dans le detail au S 5.5.4.3. SELF, PARENT, OFFSPRING et SENDER peuvent | tre utilises dans des expressions a l'interieur des instances de processus. Pour toutes les instances de processus qui se trouvent presentes au moment de l'initialisation du systeme, l'expression predefinie PARENT presente toujours la valeur NULL. Pour toutes les instances de processus nouvellement creees, les expressions predefinies 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 appel de procedure faisant reference a la definition de procedure. Des parametres sont associes a un appel de procedure: on les emploie a la fois pour fournir les valeurs et pour limiter la portee des variables pour l'execution de la procedure. C'est du mecanisme de transfert des parametres que dependent les variables affectees par l'interpretation d'une procedure. Grammaire abstraite Definition-de-procedure :: Nom-de-procedure Parametre-formel-de-procedure | Definition-de-procedure-set Definition-de-type-de-donnees Definition-de-type-de-synonyme-set Definition-de-variable-set Graphe-de-procedure Nom-de-procedure = Nom Parametre-formel-de-procedure = Parametre-d'entree | Parametre-d'entree-et-de-sortie Parametre-d'entree :: Nom-de-variable Identificateur-de-reference-de-sorte Parametre-d'entree-et-de-sortie :: Nom-de-variable Identificateur-de-reference-de-sorte Graphe-de-procedure :: Noeud-de-depart-de-procedure Noeud-d'etat-set Noeud-de-depart-de-procedure :: Transition Grammaire textuelle concrete ::= PROCEDURE { identificateur de procedure | nom de procedure } [ ] { definition de donnees> | | | | | ENDPROCEDURE [] ::= FPAR { ::= [IN/OUT | IN] ::= est definie au S 2.6.1.1, au S 2.4.4, au S 4.2, au S 4.3.3, au S 5.5.1, au S 5.2.2. Dans une , la ne peut contenir les expressions REVAELED, EXPORTED, REVAELED EXPORTED, EXPORTED REVEALED (voir le S 2.6.1). Un exemple de est donne a la figure 2.9.11. Grammaire graphique concrete ::= contains { en-t | te de procedure> { zone de texte de procedure> | | ::= | ::= contains { definition de variable> | | | ::= contains ::= Figura 9, p. ::= PROCEDURE { nom de procedure | identificateur de procedure } [] ::= { zone de d'etat | zone de connecteur d'entree> } ::= is followed by ::= .rs Figura 10, p. est definie au S 2.6.1.1, au S 2.6.7.1, au S 2.6.3, au S 2.6.6, et au S 4.2, au S 4.3.3, au S 5.5.1. Un exemple de est montre a la figure 2.9.12 au S 2.9. Semantique Une procedure est un moyen de donner un nom a un assem- blage d'objets et de le representer par une reference unique. Les regles relatives aux procedures imposent une discipline sur la maniere dont l'assemblage d'objets est choisi et elles limitent la portee du nom des variables definies dans la procedure. Une variable de procedure est une variable locale a la procedure qui ne peut appara | tre, | tre visible, | tre exportee ou | tre importee. Elle est cree 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 interpretee, son graphe de procedure est egalement interprete. Une definition de procedure est interpretee 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 l'interpretation commence de la maniere suivante: a) une variable locale est creee pour tout parametre-d'entree , ayant le nom et la sorte du parametre-d'entree parametre effectif correspondant, qui peut ne pas | tre defini; b) lorsqu'un parametre effectif est vide, la valeur attribuee au parametre formel correspondant n'est pas definie; c) un parametre formel n'ayant pas d'attribut explicite, a un attribut IN implicite; .bp d) une variable locale est creee pour chaque definition-de-variable dans la definition-de-procedure ayant le nom et la sorte de la definition-de-variable ; e) chaque parametre-d'entree-sortie decrit un nom de synonyme pour la variable qui est donnee dans l'expression des parametres effectifs. Ce nom de synonyme est utilise tout au long de l'interpretation du graphe-de-procedure lorsqu'on se refere a la valeur de la variable ou lorsque l'on affecte une nouvelle valeur a la variable; f) la transition contenu dans le noeud-de-depart-de-procedure est interpretee. 2.5 Communication 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 = Identificateur Nom-de-canal = Nom L'identificateur-de-signal-set doit contenir la liste de tous les signaux qui peuvent | tre achemines sur le ou les chemins-de-canal definis par le canal. Une extremite du canal doit au moins | tre un bloc. Si les deux points extr | mes sont des blocs, ceux-ci doivent | tre differents. La ou les extremite(s) des blocs doivent | tre definies dans la m | me unite de portee que celles ou est defini le canal. Grammaire textuelle concrete ::= CHANNEL [] [ | ] ENDCHANNEL [] ::= { FROM TO | FROM TO ENV | FROM ENV TO est definie au S 2.5.5, et au S 3.2.3. Lorsque deux sont definis, le sens de l'un doit | tre oppose par rapport au sens de l'autre. .bp Grammaire graphique concrete ::= is associated with { nom de canal > { { identificateur de canal | identificateur de bloc } [ } set } is connected to { zone de bloc { zone de bloc | symbole de cadre } [ } set L' identifie un canal externe relie au delimite par le . L' identifie un bloc externe comme etant une extremite de canal pour le delimite par le . ::= | | ::= MONTAGE ::= MONTAGE ::= MONTAGE est definie au S 2.5.5, et au S 2.4.1 et au S 3.2.3. Pour chaque fleche placee sur le , il doit y avoir une . Une doit | tre suffisamment proche de la fleche a laquelle elle est associee pour eviter toute ambiguite. Semantique Un canal est un moyen de transport pour les signaux. Un canal peut | tre considere 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 vehicules jusqu'au point extr | me de destination. Au point extr | me de destination d'un canal, les signaux se presentent dans le m | me ordre que celui des signaux au point d'origine. Si deux ou plusieurs signaux arrivent simultanement sur le canal, ils sont ordonnes arbitrairement. Un canal peut retarder l'acheminement des signaux sur le canal. Cela signifie qu'une file d'attente du type premier-entre-premier-sorti (FIFO) se trouve associee a chaque direction dans un canal. Quand un signal se presente sur le canal, il est place dans la file d'attente. Apres un intervalle de temps non determine et non constant, la premiere instance de signal dans la file d'attente est liberee et appliquee a l'un des canaux ou l'un des trajets de signaux qui se trouvent connectes au canal. Plusieurs canaux peuvent exister entre deux points d'extremites. Le m | me type de signal peut | tre achemine sur des canaux differents. 2.5.2 Acheminement du signal Grammaire abstraite Definition-d'acheminement-de-signal :: Nom-d'acheminement-de-signal Trajet-d'acheminement-du-signal [Trajet-d'acheminement-du-signal ] Trajet-d'acheminement-du-signal :: Processus-d'origine Processus-destinataire Identificateur-de-signal- set Processus-d'origine = Identificateur-de-processus | ENVIRONMENT Processus-destinataire = Identificateur-de-processus | ENVIRONMENT Nom-d'acheminement-de-signal = Nom Un des points extr | mes au moins du trajet-d'acheminement-du-signal doit | tre un processus. Si les deux points extr | mes sont des processus, les identificateur-de-processus doivent | tre differents. Le ou les point(s) extr | me(s) du processus doivent | tre definis dans la m | me unite de portee que celle de l'acheminement du signal. Grammaire textuelle concrete ::= SIGNALROUTE [] ::= { FROM TO | FROM TO ENV | FROM ENV TO } WITH La est definie au S 2.5.5. Lorsque deux sont definis, l'un doit | tre en sens oppose a l'autre. Grammaire graphique concrete ::= is associated with { nom d' acheminement de signal > { ] [ } set } is connected to { zone de processus> { zone de processus> | ::= | ::= MONTAGE ::= MONTAGE Un symbole d'acheminement de signal comprend une t | te de fleche a une extremite (une direction) ou une t | te de fleche a chaque extremite (deux directions) pour montrer la direction du flot des signaux. Pour chaque fleche situee sur le , il doit exister une . Une doit | tre suffisamment proche de la fleche a laquelle elle est associee afin d'eviter toute ambiguite. Lorsque le est relie au , l' identifie un canal auquel l'acheminement de signal est relie. Semantique Un acheminement de signal est un moyen de transport pour les signaux. Un acheminement de signal peut | tre considere comme etant un ou deux trajets d'acheminement de signal unidirectionnels et independants entre deux processus ou entre un processus et son environnement. Les signaux achemines par des acheminements de signaux sont delivres au point extr | me de destination. Un acheminement de signaux n'apporte aucun retard dans le transport des signaux. Aucun acheminement de signal ne peut relier des instances de processus du m | me type. Si tel est le cas, l'interpretation du noeud-de-sortie a pour consequence implicite que le signal est applique directement a l'acces d'entree du processus de destina- tion. Plusieurs trajets de signaux peuvent exister entre deux points extr | mes. Le m | me type de signal peut | tre achemine sur differents acheminements de signaux. Modele Un contient les sig- naux que le processus est autorise a recevoir. Un ne doit toutefois pas contenir de signaux de temporisateur. Si une contient des , l', s'il y en a un, n'a pas besoin de contenir des signaux dans des acheminements de signaux conduisant au processus. Si une ne contient aucune , toutes les dans cette doivent contenir un . Dans ce cas, les et les sont tirees de l', des et des canaux qui se terminent a la frontiere des blocs. Les signaux correspondant a une direction donnee entre deux processus dans l'acheminement de signal implicite constituent l'intersection des signaux specifies dans l' du processus de destination et les signaux mentionnes dans une sortie du processus d'origine. Si l'un des points extr | mes est l'environnement, l'ensemble d'entree/ensemble de sortie est constitue par les signaux achemines par le canal dans la direction donnee. .bp 2.5.3 Connexion Grammaire abstraite Connexion-de-canal-a-acheminement :: Identificateur-de-canal Identificateur-d'acheminement-de-signal- set Identificateur-d'acheminement-de-signal = Identificateur D'autres constructions sont donnees au S 3. Chaque identificateur-de-canal relie au bloc englobant doit | tre mentionne dans une seule connexion-de-canal-a-acheminement L'identificateur-de-canal dans une connexion-de-canal-a-acheminement doit denoter un canal connecte au bloc entre crochets. Chaque identificateur-d'acheminement-de-signal dans une connexion-de-canal-a-acheminement doit | tre defini dans le m | me bloc ou la connexion-de-canal-a-acheminement se trouve definie et doit avoir la frontiere de ce bloc situee a l'un de ses points extr | mes. Chaque identificateur-d'acheminement-de-signal defini dans le bloc qui l'entoure et qui a son environnement comme etant l'un de ses points extr | mes, doit | tre mentionne dans une seule et unique connexion-de-canal-a-acheminement . Pour une direction donnee, l'union des ensembles d'identificateur de signal dans les acheminements de signaux dans une connexion-de-canal-a-acheminement doit | tre egale aux signaux achemines par l'identificateur-de-canal dans la m | me connexion-de-canal-a-acheminement et correspondant a la m | me direction. Grammaire textuelle concrete ::= CONNECT AND { On ne peut mentionner deux fois un . Grammaire graphique concrete Sur le plan graphique, l'element connexion est represente par l' associe au trajet de signal et contenu dans la (voir le S 2.5.2 grammaire graphique concrete ). 2.5.4 Signal Grammaire abstraite Definition-de-signal :: Nom-de-signal Identificateur-de-reference-de-sorte | [Affinage-de-signal ] Nom-de-signal :: Nom L'identificateur-de-reference-de-sorte est defini au S 5.2.2. Grammaire textuelle concrete ::= SIGNAL { nom de signal > [] [ } { [] [ } ::= ( { est defini au S 3.3, la au S 5.2.2. Semantique Une instance de signal est un flot d'informations entre des pro- cessus; c'est une instanciation d'un type de signal defini par une definition de signal. Une instance de signal peut | tre envoyee par l'environnement ou par un processus, elle se dirige toujours vers un processus ou vers l'environnement. On associe a chaque instance de signal deux valeurs de PId (voir le S 5.6.10) indiquant les processus de depart et de destina- tion, l' specifie dans la sortie correspondante et les autres valeurs, dont les sortes sont definies dans la definition d'un signal. .bp 2.5.5 Definition de liste de signaux Un peut | tre utilise dans une , une , une , un et comme moyen abrege pour enumerer les identificateurs de signaux et les signaux de temporisation. Grammaire textuelle concrete ::= SIGNALLIST = ::= { ::= | () | La qui est etablie en remplacant tous les dans la liste par les qu'ils decrivent, correspond a un identificateur-de-signal- set dans la grammaire abstraite. Dans chaque ainsi etablie, chaque doit | tre distinct. Grammaire graphique concrete ::= contains ::= .rs Figura 1, p. 50 (E)