5i' D.3.8.2.1 Determination des etats requis L'auteur d'un diagramme LDS dispose generalement d'une cer- taine latitude pour definir les etats d'un processus. Il peut avoir besoin d'une strategie qui lui permette d'identifier les etats du processus et cette strategie peut | tre informelle ou formelle. Un jugement s | r (que seule une longue experience permet d'acquerir) est necessaire si l'on veut etablir des diagrammes LDS tels que l'identification d'un trop grand nombre d'etats ne les complique pas inutilement ou qu'un nombre artificiellement reduit d'etats ne les emp | che d'exploiter les avantages qu'offre le LDS. Avant que l'auteur ne commence a etablir le diagramme, certaines etapes preliminaires (etudiees au S D.3.2) doivent | tre achevees, par exemple: - la structuration du systeme en blocs fonction- nels; - la representation d'un ou plusieurs processus LDS par bloc; - le choix des signaux d'entree et de sortie; - l'utilisation des donnees dans le processus. Tous les facteurs ci-dessus exercent un effet important dans la determination des etats de chaque processus. L'effet qu'exerce le choix des signaux d'entree sur le nombre d'etats d'un diagramme LDS est illustre par les deux exemples de la figure D-3.8.11. Figure D-3.8.11, p. 1 D.3.8.2.2 Reduction du nombre des etats Ayant applique une strategie pour l'identification des etats d'un processus, l'auteur d'un diagramme LDS estimera peut- | tre qu'un trop grand nombre d'etats ont ete utilises. Le nombre des etats est important car la dimension et la complexite d'un diagramme LDS sont souvent etroitement liees a ce nombre. Il existe certes des moyens qui permettent de reduire le nombre des etats mais le fait qu'un diagramme LDS soit complexe n'est pas, en soi, une raison justifiant sa modification; en effet, la complexite du diagramme peut | tre simplement due a la complexite inherente au processus defini. Le choix de l'ensemble d'etats doit generalement offrir le plus de clarte possible a la sequence d'interactions entre le pro- cessus et son environnement. Ce n'est d'ordinaire pas en minimisant le nombre d'etats que l'on obtient cette clarte. Le nombre de sequences independantes traitees par un processus exerce un effet multiplicateur sur le nombre d'etats. Il est donc souhaitable que les sequences independantes des processus separes soient traitees de facon a reduire le nombre d'etats et a obtenir une plus grande clarte. On peut reduire le nombre des etats en effectuant la separation des fonctions communes ou la fusion des etats ou encore en recourant au concept de service. Certaines structures de donnees peuvent egalement conduire a une reduction du nombre des etats. Pour d'autres representations, l'emploi des macros peut | tre avantageux. D.3.8.2.3 Separation des fonctions communes Lors de la mise en place d'un diagramme LDS, on peut constater que la definition d'un aspect particulier et repetitif d'un pro- cessus necessite la representation d'etats repetitifs. La figure D-3.8.12 represente une partie d'un diagramme LDS definissant un processus de signalisation de ligne et illustrant la condition selon laquelle une tonalite de signalisation de ligne doit | tre presente pendant une certaine duree avant que l'on considere que le signal de ligne a ete detecte. Pour specifier cet aspect, il convient d'inserer un etat intermediaire entre les etats aucun _signal _de _ ligne _n'est _detecte et conversation. Supposons que, dans un diagramme com- plet, une telle fonction commune doit | tre repetee a chaque point ou le signal est detecte. Une autre solution consiste a definir un processus separe qui est responsable du contr | le de la tonalite de signalisation de ligne et de la detection des signaux sur la base du temps de reconnaissance specifie. L'existence de ce nouveau processus permettrait de representer le diagramme de la figure D-3.8.12 de la maniere indiquee dans la figure D-3.8.13. (Dans un contexte donne, les figures peuvent | tre rendues equivalentes moyennant l'introduction d'un nouveau signal signal _de _ligne _valide.) Il convient de noter la legere difference entre le processus de la figure D-3.8.12 et les deux processus de la figure D-3.8.13. Le processus de la figure D-3.8.12 commence a compter des reception de T1 alors que le processus de traitement des appels [processus b) de la figure D-3.8.13] commence a compter des reception de signal _de _ ligne _valide qui est engendre et emis a la reception de T1 par le processus a) de la figure D-3.8.13. Il s'ensuit que, dans le second cas, le comptage demarre apres T1 + temps de generation, d'emission et de reception du signal. En outre, d'autres signaux peuvent avoir ete mis dans la file d'attente pendant le temps necessaire a la generation et a l'emission de signal _de _ligne _valide. Une seconde particularite est que cette separation d'une sous-fonction ne serait pas possible si le signal que doit recevoir la sous-fonction devait | tre recu egalement par la fonction principale, un signal etant toujours achemine vers un seul pro- cessus. Si, dans l'exemple, le m | me signal S _off devait | tre recu dans un autre etat ou il n'est pas besoin de le valider pour le temps T1, il n'aurait pas ete possible de separer la sous-fonction de validation en un autre processus. Les solutions qui font appel a des processus distincts sont generalement utiles lorsque les signaux doivent | tre traites independamment des etats dans le processus principal. Dans ce cas, les operations qui precedent et qui suivent les processus peuvent traiter les sequences detaillees et decharger un processus princi- pal de tous les details. Ceci engendre souvent une modularite utile permettant, par exemple, d'isoler les caracteristiques particulieres des systemes de signalisation, du processus principal plus axe sur le service. Une autre maniere de traiter le probleme consiste a appliquer le concept de service, explique au S D.5.3. Une solution differente du probleme consisterait a employer la notation MACRO, comme indique a la figure D-3.3.1. Dans ce cas, on obtient pour le diagramme la compacite voulue sans modifier en rien la semantique du diagramme original. Il est en outre possible d'appeler la MACRO a partir de plusieurs etats si la logique du processus l'exige. Figure D-3.8.12, p. 2 Figure D-3.8.13, p. 3 D.3.8.2.4 Fusion des etats Si, dans un diagramme LDS, la destination future de deux etats est la m | me, on peut, independamment de leur evolution anterieure, effectuer la fusion de ces deux etats en un seul, sans affecter la logique du diagramme. La figure D-3.8.14 represente une partie d'un diagramme LDS comportant deux etats dont le <> est different mais dont le <> est identique. Dans la figure D-3.8.15, les deux etats ont ete combines en un seul. Il s'agit la d'un exemple relativement simple dans lequel la reduction de la complexite est peu impor- tante, mais cette m | me technique peut | tre utilisee pour obtenir une plus grande simplification. La semantique du LDS ne prevoit pas une decision consecutive a un etat pour determiner le <> du processus anterieurement a cet etat (c'est-a-dire de determiner, pour cet exemple, si A6 ou B4 a ete emis), a moins que cette information n'ait ete explicitement stockee avant l'entree dans l'etat. A noter, que l'attribution d'un nom aux donnees d'une entree a pour effet de mettre la valeur en memoire. Un etat doit representer une situation logique du processus et il n'est donc pas souhaitable d'effectuer la fusion de situations logiques differentes en un seul etat. Des precautions sont a prendre si un diagramme fusionne doit | tre modifie ulterieurement. L'usager devrait rechercher si la modification envisagee a ou non le m | me effet sur les diverses branches initiales. Figures D-3.8.14 et D-3.8.15, C | TE-`-C | TE, p. 4 D.3.8.3 Entrees Le present S D.3.8.3 a pour objet d'expliquer la notion d'entree ainsi que l'utilisation des entrees dans des diagrammes LDS ne faisant pas appel a la notion de mise en reserve. La notion de mise en reserve et l'utilisation de cette notion en m | me temps que la notion d'entree font l'objet du S D.3.8.4. D.3.8.3.1 Considerations generales Un symbole d'entree attache a un etat signifie que, si le sig- nal dont le nom figure dans le symbole d'entree arrive pendant que le processus est dans cet etat, il faut interpreter la transition qui suit le symbole d'entree. Lorsqu'un signal a declenche l'interpretation d'une transition, ce signal n'existe plus et on dit qu'il a ete absorbe. Un signal peut | tre accompagne de donnees associees. Par exemple, un signal portant le nom <> sert non seulement a declencher l'execution d'une transition par le processus de reception mais encore a vehiculer la valeur du chiffre (0 a 9), ces donnees pouvant | tre utilisees par le processus recepteur. En LDS/PR, l'instruction INPUT contient une liste d'identificateurs de signaux. Les valeurs contenues dans les sig- naux sont indiquees a l'aide d'identificateurs de variables. Les identificateurs de variables doivent | tre du type indique dans la definition de signal, de sorte que leur position est tres importante. Ces identificateurs de variables sont places entre parentheses et separes par des virgules (voir la figure D-3.8.16). Si une ou plusieurs valeurs de signal sont rejetees, les variables correspondantes font defaut, ce qui est indique par deux ou plusieurs virgules consecutives (figure D-3.8.17). Figure D-3.8.16 [T13.100] (a traiter comme tableau MEP), p. 6 Figure D-3.8.17 [T14.100] (a traiter comme tableau MEP), p. 7 En LDS/GR, une entree est representee a l'aide d'un symbole d'entree contenant la liste d'identificateurs de signaux et les identificateurs de variables correspondants pour les valeurs acheminees. Pour pouvoir | tre communiquees au processus, ces valeurs doivent | tre designees nommement dans les symboles d'entree, entre parentheses. On trouvera des exemples de reception de valeurs des entrees dans les figures D-3.8.18, D-3.8.19 et D-3.8.20. Les donnees auxquelles un nom est assigne peuvent | tre utilisees par le processus recepteur quand l'entree est interpretee. La figure D-3.8.18 montre la reception du signal <>. Le signal <> est accompagne de donnees associees (numero _de _l'abonne) avec pour valeur 9269. Le signal peut | tre recu de trois manieres, comme indique en a) et c) de la figure. La figure D-3.8.19 montre comment envoyer et recevoir plusieurs valeurs en un seul signal. Chaque element doit | tre separe du suivant par une virgule. La figure D-3.8.20 c) montre comment ignorer les valeurs indesirables en laissant un blanc dans la liste de sortes. A noter que, dans le signal de sortie, il est impossible d'ecrire des expressions pour E1, E2 ou E3, alors que dans le sig- nal d'entree, il faut employer des variables pour recevoir les valeurs emises. Dans le LDS, il n'est pas necessaire de dessiner des symboles d'entree pour representer les signaux dont l'arrivee necessiterait une transition nulle (c'est-a-dire une transition qui ne contient aucune action et qui ramene au m | me etat). La convention admise est la suivante: pour tout signal qui n'est pas represente dans un symbole d'entree explicite a un etat donne, il existe, dans cet etat, un symbole d'entree implicite et une transition nulle. Conformement a cette convention, les deux diagrammes representes dans la figure D-3.8.21 sont logiquement equivalents et peuvent | tre indistinctement utilises. Figure D-3.8.18, p. 8 Figure D-3.8.19, p. 9 Figure D-3.8.20, p. 10 Figure D-3.8.21, p. 11 Lorsqu'un certain nombre d'entrees aboutissent a la m | me transition, tous les identificateurs de signaux qui s'y rapportent peuvent | tre places dans un m | me symbole d'entree. Le LDS prevoit une notation abregee pour representer une entree de tous les signaux (valable pour ce processus) non explicitement mentionnes dans cet etat. La figure D-3.8.22 illustre cet aspect et les diagrammes qui y sont representes sont logiquement equivalents. Si tous les iden- tificateurs de signaux sont mentionnes, il faut les separer par des virgules. D.3.8.3.2 Mecanisme implicite de mise en file d'attente Un ou plusieurs signaux peuvent | tre en attente d'absorption lorsqu'un processus parvient a un nouvel etat. Cela signifie que les signaux doivent | tre mis en attente d'une certaine maniere si l'on veut eviter qu'ils soient perdus. Lorsqu'un signal parvient au bloc de destination, il est place dans la file d'attente d'entree du processus de reception. La semantique du LDS definit pour chaque processus un mecanisme theorique de mise en file d'attente selon lequel le mode de selection des signaux pour l'absorption par le processus est fonde sur l'ordre d'arrivee des signaux dans ce pro- cessus. Lorsque le processus parvient a un etat, il recoit un seul signal en provenance de la file d'attente. Ceci signifie que si la file d'attente n'est pas vide, le processus absorbe le premier sig- nal qui vient de la file d'attente en question. Si cette derniere est vide, le processus demeure en attente dans l'etat jusqu'a l'arrivee a la file d'attente d'un signal qui est ensuite absorbe par le processus. La figure D-3.8.23 utilise le concept de file d'attente pour expliquer le fonctionnement d'un processus LDS dans lequel les temps de transition sont differents de zero. Il convient de noter les elements suivants: - le concept de mise en reserve n'est pas applique et les signaux sont absorbes dans l'ordre de leur arrivee; - l'ordre de succession de l'arrivee des signaux est important. Si <> etait arrive avant <> dans la transition entre l'etat 1 et l'etat 2, la sequence des etats aurait ete 1, 2, 3 au lieu de 1, 2, 4; Figure D-3.8.22, p. 12 - la file d'attente n'etant pas vide lorsque le processus arrive aux etats 2 et 4, ce processus ne doit attendre ni dans l'un ni dans l'autre de ces etats; - il n'est pas possible d'attribuer la priorite a un signal. Un mecanisme special est prevu pour les communications entre services, afin que les signaux echanges entre service soient traites avant les autres signaux (S D.5.3). Si les temps de transition sont nuls, chaque signal sera absorbe au moment de son arrivee dans un processus, sauf si l'on a recours a la mise en reserve (voir le S D.3.8.4). D.3.8.3.3 Reception des signaux qui ne se presentent pas normalement Dans chacun des etats, tous les signaux possibles doivent | tre indiques implicitement ou explicitement. Des exceptions (sig- naux inattendus mais theoriquement possibles, signaux non definis ou logiquement faux a un endroit donne, etc.) peuvent se presenter dans presque tous les etats. Normalement, l'auteur n'indique pas ces possibilites; il s'ensuit qu'un tel signal sera elimine s'il se presente. Si toutefois l'auteur tient a faire figurer les excep- tions dans son diagramme, il doit prevoir pour tous les etats une entree supplementaire. Une autre possibilite consiste a profiter des apparitions mul- tiples d'un etat portant le symbole <> (*). Par exemple, si le signal A _RACCROCH' peut | tre recu dans tous les etats et si les actions posterieures sont identiques, on peut recourir a la methode indiquee a la figure D-3.8.24. D.3.8.3.4 Arrivee simultanee de signaux La Recommandation Z.100 (S 2) prevoit que les signaux peuvent parvenir simultanement a un processus et precise qu'ils seront places dans un ordre arbitraire. Si un usager met au point un processus capable de recevoir des signaux simultanes, il doit veiller a ce que l'ordre d'arrivee ne bouleverse pas le fonctionnement escompte du processus. Le LDS ne preconise pas de priorite parmi les signaux; ainsi, en cas d'arrivee simultanee de signaux, l'un d'eux est choisi arbi- trairement. A noter cependant que les signaux pour communications entre services sont toujours traites les premiers (S D.5.3). Si plusieurs signaux sont disponibles au moment de l'entree du processus dans un etat, un seul signal est presente au processus puis reconnu comme une entree. Selon la semantique du LDS, les autres signaux sont en fait retenus. Figure D-3.8.23, p. 13 Figure D-3.8.24, p. 14 D.3.8.3.5 Identification de l'emetteur Chaque signal est porteur de la valeur d'instance du processus (PId) du processus emetteur. Lorsqu'un signal est absorbe, la valeur PId du processus emetteur peut | tre obtenue au moyen de l'expression SENDER. On trouvera dans la figure D-3.8.25 un exemple d'emploi de cette variable. Figure D-3.8.25, p. 15 D.3.8.4 Mises en reserve Le concept de mise en reserve permet de differer l'absorption d'un signal jusqu'a ce qu'un ou plusieurs signaux ulterieurs aient ete absorbes. Comme l'indique le S D.3.8.3, les signaux sont absorbes dans l'ordre dans lequel ils se presentent, sauf en cas d'emploi du concept de mise en reserve. L'on peut faire appel au concept de mise en reserve afin de simplifier les processus lorsque l'ordre relatif d'arrivee de cer- tains signaux n'a pas d'importance et que leur ordre effectif d'arrivee est indetermine. Dans chaque etat, chaque signal est traite comme suit: - il est represente comme un symbole d'entree ou, - il est represente comme un symbole de mise en reserve ou, - il est, par convention, couvert par une entree implicite aboutissant a une transition nulle implicite. Le fonctionnement du mecanisme implicite de mise en file d'attente decrit dans le S D.3.8.3 s'applique egalement au concept de mise en reserve. A leur arrivee, les signaux sont places dans la file d'attente et lorsque le processus atteint un etat donne, les signaux qui se trouvent dans la file d'attente sont examines un a un dans l'ordre de leur arrivee. Un signal couvert par un symbole d'entree explicite ou implicite est absorbe et la transition qui s'y rapporte est executee. Un signal represente dans un symbole de mise en reserve n'est pas absorbe et reste dans la file d'attente dans la m | me position sequentielle; le signal suivant de la file d'attente est considere. Aucune transition ne suit un symbole de mise en reserve. En LDS/PR, la construction de mise en reserve est exprimee a l'aide du mot-cle SAVE suivi d'une liste d'identificateurs de sig- naux. On trouvera un exemple simple d'enonces de MISE EN R'SERVE dans la figure D-3.8.26. Figure D-3.8.26 [T15.100] (a traiter comme tableau MEP), p. 16 En LDS/GR, le concept de mise en reserve est represente a l'aide du symbole de mise en reserve contenant les identificateurs de signaux. Comme dans le cas des entrees, une <> peut servir a representer la mise en reserve de tous les signaux (valides pour ce processus) qui ne sont pas explicite- ment mentionnes dans cet etat. La figure D-3.8.27 represente un exemple d'un processus LDS qui comporte un symbole de mise en reserve. Il convient de noter que les signaux S et R sont consommes dans l'ordre R, S, c'est-a-dire dans l'ordre inverse de leur reception. Un symbole de mise en reserve unique peut servir a mettre un signal en reserve tant que le processus se trouve dans l'etat dans lequel le symbole appara | t; ce signal est mis en reserve pour la duree de la tran- sition vers le prochain etat. Dans le prochain etat, le signal sera absorbe par l'intermediaire d'une entree explicite ou implicite (voir la figure D-3.8.27) sauf dans les cas suivants: lorsque le symbole de mise en reserve comportant le nom du signal est repete ou lorsque dans la file d'attente implicite, il existe avant lui, un autre signal de sauvegarde disponible pour absorption (voir la figure D-3.8.28). Figure D-3.8.27, p. 17 Figure D-3.8.28, p. 18 Un signal mis en reserve n'est mis a disposition d'un pro- cessus que par l'intermediaire d'un symbole d'entree correspondant (explicite ou implicite). Aucune question relative a un signal mis en reserve ne peut | tre posee dans une decision avant la recon- naissance de ce signal comme une entree; de m | me les donnees qui lui sont associees ne sont pas disponibles. Dans un etat ou plusieurs signaux doivent | tre mis en reserve, on peut attribuer un symbole de mise en reserve a chaque signal ou on peut les representer tous a l'interieur du m | me sym- bole de mise en reserve. Si plusieurs signaux doivent | tre mis en reserve, la semantique du symbole de mise en reserve exige que l'ordre de leur arrivee soit preserve. Un troisieme exemple de l'utilisation de la notion de mise en reserve est donne dans la figure D-3.8.29 et la figure D-3.8.30 decrit le fonctionnement du mecanisme de formation de la file d'attente. L'utilisation du symbole de mise en reserve peut simplifier les diagrammes. Ainsi, en mettant un signal en reserve, l'on peut eviter de le recevoir et de devoir mettre en memoire ses donnees associees jusqu'a l'etat suivant. Bien que le symbole de mise en reserve puisse | tre utilise a chaque niveau de description, il y aurait peut- | tre lieu, au niveau inferieur, de decrire le mecanisme effectif qui permet cette mise en reserve. Sans un minimum de precautions dans l'emploi de la mise en reserve, la file d'attente des signaux mis en reserve peut aug- menter considerablement ou garder des signaux en memoire trop longtemps, de sorte qu'un signal ancien peut | tre absorbe lorsqu'un signal recent est demande. Le LDS ne prevoit pas de limite a la longueur de la file d'attente, ce qui peut poser des problemes de mise en oeuvre. Figure D-3.8.29, p. 19 Figure D-3.8.30, p. 20 D.3.8.5 Condition de validation et signaux continus Les conditions de validation permettent une reception condi- tionnelle de signaux fondee sur la condition de validation specifiee. Le signal est recu et la transition interpretee si la condition est vraie. En cas de condition fausse, le signal est mis en reserve et le processus ne change pas d'etat jusqu'a ce qu'un autre signal arrive ou que la condition devienne vraie. L'exemple de la figure D-3.8.31 illustre ceci. Lorsque P1 passe a l'etat S1, la condition (c'est-a-dire de savoir si IMPORT (X,P2) est egal a 10) est evaluee. Si elle est vraie, le signal B peut | tre recu. Sinon, le signal B est mis en reserve. Dans cet exemple, A arrive et provoque une transition vers S2. Pendant la transition, X passe a la valeur 11 et P2 exporte sa nouvelle valeur; alors, la condi- tion liee au signal B dans l'etat S2 est vraie. Etant donne que B est le premier signal de la file d'attente, la transition qui suit est executee et le processus prend fin a l'etat S3. Certaines caracteristiques des conditions de validation sont importantes: 1) la condition de validation est testee lorsque le processus arrive a un etat; il est alors continuellement contr | le tandis que le processus reste dans cet etat. Ainsi, si la valeur exportee de X avait passe de 9 a 11 puis a 12 pendant la transition qui faisait suite a la reception de A, le processus serait reste a S2; 2) les conditions de validation peuvent | tre fondees sur des variables locales et/ou toute construction de lan- gage qui peut | tre comprise dans une expression (par exemple, IMPORT (IMPORTATION), VIEW (VUE), NOW (MAINTENANT)); 3) alors qu'il est possible d'employer plus d'une condition par etat, l'emploi de plus d'une condition de validation pour le m | me signal n'est pas autorise. Ainsi, la condition indiquee dans la figure D-3.8.32 n'est pas autorisee. Si un signal donne exige des conditions multiples, il est possible de les com- biner en une expression booleenne ainsi que le montre la figure D-3.8.33. On peut evaluer les conditions de validation plusieurs fois et dans un ordre quelconque, de sorte que l'usager doit | tre vigi- lant si les expressions ont des effets secondaires reciproques (par exemple IMPORT et SENDER combines). Il faut noter en outre que le signal specifie dans la condi- tion de validation ne peut influencer la valeur booleenne de la condition car ses valeurs transportees ne sont pas affectees avant l'absorption du signal. A titre d'exemple, les enonces: INPUT x(A) PROVIDED (A=5);... INPUT y PROVIDED(SENDER)=pid1); pr | tent a confusion car les valeurs de A et de SENDER dans les conditions correspondent a la situation telle qu'elle etait avant l'absorption du signal. Les signaux continus ont les m | mes proprietes fondamentales que la condition de validation, excepte le fait qu'ils ne sont accompagnes d'aucun signal. Ainsi, en l'absence de signaux dans la file d'attente susceptibles de provoquer une transition a leur entree dans l'etat, les signaux continus sont contr | les; si l'un d'entre eux est vrai, la transition qui le suit est executee. L'exemple de la figure D-3.8.34 en donne l'illustration. A l'origine, le processus se trouve a l'etat S1 et la valeur exportee de X est 9. En arrivant, le signal A provoque la transition vers l'etat S2. Pendant la transition, X prend la valeur 11. Vu qu'aucun autre signal ne se trouve dans la file d'attente, la tran- sition vers l'etat S3 s'accomplit. L'on trouvera ci-dessous certaines caracteristiques impor- tantes des signaux continus: 1) de m | me que pour les conditions de valida- tion, la valeur de la condition n'est contr | lee qu'a l'arrivee a un etat; 2) les signaux continus multiples sont autorises pour chaque etat. Lorsque plusieurs signaux continus sont lies a un etat, le signal continu ayant le rang de priorite le plus eleve (le numero le plus bas) sera traite le premier. Deux signaux continus ne peuvent avoir le m | me rang de priorite. Le signal continu est toujours moins prioritaire que tout autre signal. Ceci est de nouveau d | au systeme sous-jacent du LDS: toutefois, la representation a l'aide de modeles des signaux continus en LDS (emploi des signaux emis pendant l'exportation de variables), per- met le recours a des priorites pour les signaux continus: ceci est d'ailleurs necessaire afin d'eviter toute ambiguite en cas de presence de plusieurs signaux continus. La figure D-3.8.35 en donne une illustration. Le processus commence a l'etat S1 et ses vari- ables locales X et Y ont respectivement les valeurs 10 et 11. Etant donne que les deux signaux continus sont vrais, celui qui a la plus haute priorite (rang de priorite le plus bas) est choisi et la transition vers l'etat S2 s'accomplit. En S2, la condition de Y n'est plus vraie, et bien que la priorite du signal continu de X soit inferieure a celle de Y, la transition qui le suit est executee et le processus parvient a l'etat S3; 3) lorsque la transition d'un signal continu a une suite, l'expression SENDER ('METTEUR) retourne la m | me valeur de SELF. Figure D-3.8.31, p. 21 Figure D-3.8.32, p. 22 Figure D-3.8.33, p. 23 Figure D-3.8.34, p. 24 Figure D-3.8.35, p. 25 D.3.8.6 Sorties Une sortie est l'emission d'un signal d'un processus vers un autre ou vers lui-m | me. Etant donne que le contr | le de la reception et de l'absorption du signal est associe au processus de reception (voir le S D.3.8.3), les regles semantiques se rapportant directement aux symboles de sorties sont relativement simples. Du point de vue du processus d'emission, une sortie peut souvent | tre consideree comme une action instantanee qui, une fois achevee, n'a aucun autre effet direct sur le processus d'emission, lequel ne sera pas directement conscient du sort du signal. Une action de sortie represente l'emission d'un signal et l'association de valeurs s'il en existe. Il est possible d'associer des valeurs a un signal de sortie en les placant entre parentheses ou en mettant des expressions ayant des valeurs entre parentheses (voir la figure D-3.8.37). En LDS/PR, une action de sortie est representee a l'aide du mot-cle OUTPUT (sortie) suivi d'une liste d'identificateurs de sig- naux. Une liste de parametres reels mis entre parentheses peut | tre associee a chaque identificateur de signal. S'il n'existe pas en fait de parametre reel dans la sortie correspondant a une sorte dans la definition du signal, la variable correspondante dans l'entree de reception aura la valeur <>. L'instance de processus de destination doit | tre exprimee dans l'instruction de sortie par le mot-cle TO (vers) suivi d'une expression d'instance de processus. Si l'instance de processus de destination peut | tre determinee uniquement par le contexte, la clause TO peut | tre omise. Une condition d'adressage supplementaire peut | tre fournie dans l'enonce de sortie a l'aide du mot-cle VIA suivi d'une liste d'acheminement de signaux et d'identificateurs de canaux. La figure D-3.8.36 donne quelques exemples valables d'enonces de sortie. Figure D-3.8.36 [T16.100] (a traiter comme tableau MEP), p. 26 En LDS/GR, une sortie est representee a l'aide d'un symbole de sortie contenant la specification de signaux, de parametres reels et, en option, de destination et/ou de construction VIA. Chaque sortie doit | tre dirigee vers une instance de pro- cessus donnee. Etant donne qu'il est generalement impossible de conna | tre l'instance de processus de tout processus au moment de l'elaboration d'une specification, la methode normale pour diriger les signaux consiste a employer une variable ou une expression dans le mot-cle TO (VERS). On trouvera dans les figures D-3.8.38, D-3.8.39 et D-3.8.40 des exemples. Dans la figure D-3.8.38, le parametre de processus <> prend la valeur d'une instance de processus lors de la creation du processus. Le r | le de <> au sein du processus est d'assurer la liaison entre le pro- cessus en question et le processus auquel il est connecte. Il con- vient de veiller lors de la conception du systeme, a ce que le type de processus indique par <> puisse recevoir les signaux qui sont emis. Dans la figure D-3.8.39, l'expression predefinie SENDER sert a renvoyer un signal au processus qui a emis le signal recu peu avant. Dans la figure D-3.8.40, le signal est envoye vers le descendant le plus recent du processus. Figure D-3.8.37, p. 27 Figure D-3.8.38 [T17.100] (a traiter comme tableau MEP), p. 28 Figure D-3.8.39, p. 29 Figure D-3.8.40, p. 30 D.3.8.7 T | che Dans une transition, une t | che sert a representer a l'aide d'un texte informel des operations sur des variables ou une operation speciale. En LDS/PR, une t | che est representee par le mot-cle TASK (T | CHE) suivi d'une liste d'instructions ou de textes informels separes par des virgules et se terminant par un point-virgule. Une instruction d'une t | che peut consister simplement en une affecta- tion. Un texte informel consiste en une phrase delimitee par des apostrophes. On trouvera dans la figure D-3.8.41 des exemples de t | ches valables en LDS/PR. Figure D-3.8.41 [T18.100] (a traiter comme tableau MEP), p. 31 En LDS/GR, une t | che se compose d'un symbole de t | che con- tenant la liste des instructions ou des textes informels. Les usagers du LDS peuvent parfois eprouver de la difficulte a decider si un aspect du systeme defini doit | tre represente par une t | che ou un processus distinct. Considerons l'exemple du pro- cessus represente dans la figure D-3.8.42: l'action <> doit-elle | tre representee par une t | che ou par un processus distinct? Si l'on n'a pas identifie un processus distinct de commande de trajet de commuta- tion, il serait indique d'utiliser le symbole t | che [voir la figure D-3.8.42 a)]. Si on a identifie un processus distinct de commande de trajet de commutation, on doit utiliser les signaux qui communiquent avec le processus de commande [voir la figure D-3.8.42 b)]. Figure D-3.8.42, p. 32 D.3.8.8 Decisions Une decision est une action qui se produit au cours d'une transition et qui correspond a une question concernant la valeur d'une expression au moment de l'execution de l'action; le processus a le choix entre deux ou plusieurs trajets, ce choix etant determine par la reponse consecutive a la decision. Les auteurs des diagrammes LDS doivent veiller a ce que les processus soient definis de maniere qu'ils ne puissent tenter d'executer des decisions pour lesquelles des reponses (ou les donnees) ne sont pas disponibles; de telles decisions rendraient le diagramme tout a fait incorrect et entra | neraient une confusion considerable. La question a laquelle correspond une decision peut | tre une expression ou un texte informel. Les reponses apportees par une decision sont representees par une ou plusieurs valeurs possibles obtenues par l'evaluation de l'expression de la question ou par un ou plusieurs textes informels. Si la question ou l'une des reponses est informelle, toute la decision est informelle. Des reponses differentes sont separees par des virgules. Les valeurs sont representees par des expressions constantes, par des expressions constantes ayant un operateur comme prefixe ou par des gammes dont les limites superieures et inferieures sont des expressions con- stantes. Les valeurs de reponse doivent | tre du m | me type que l'expression contenue dans la question. Il est possible d'indiquer explicitement certaines reponses et de grouper toutes les autres reponses possibles en employant le mot-cle ELSE (AUTRE). En LDS/PR, la decision est representee par le mot-cle D'CISION suivi par la specification de la question et la liste des reponses possibles, chacune etant associee a la transition correspondante. Les reponses sont indiquees entre parentheses. L'ensemble des tran- sitions sortantes est delimite par le mot-cle ENDDECISION (FIN DE D'CISION) place a la fin (voir la figure D-3.8.43). Figure D-3.8.43 [T19.100] (a traiter comme tableau MEP), p. 33 On trouvera certains exemples de decisions dans la figure D-3.8.44. Figure D-3.8.44 [T20.100] (a traiter comme tableau MEP), p. 34 Toutes les transitions se terminent par le mot-cle ENDECISION (FIN DE D'CISION). Les decisions qui ne se terminent pas par un enonce terminal (c'est-a-dire jonction, etat suivant, arr | t) con- tinuent dans l'enonce qui suit le mot ENDECISION, comme indique dans les deux branches equivalentes de la figure D-3.8.45. Figure D-3.8.45, p. 35 L'instruction de decision peut en outre servir a former la structure IF-THEN (SI-ALORS), la structure DO-WHILE (FAIRE-PENDANT) et la structure LOOP-UNTIL (BOUCLE-JUSQU'`) comme en programmation structuree. En LDS/GR, une decision est representee a l'aide d'un symbole de decision contenant le texte de la question. Le symbole doit avoir deux branches ou plus associees aux reponses correspondantes. Chaque reponse doit | tre placee a la droite ou au sommet de la branche correspondante ou au-dessus de la branche qui interrompt la ligne de liaison. En LDS/GR, les parentheses servant a delimiter les reponses sont facultatives mais il est suggere de les utiliser pour eviter tout malentendu. On trouvera certains exemples de decisions en LDS/GR dans la figure D-3.8.46. Figure D-3.8.46, p. 36 Si une reponse ramene a la decision de la m | me transition, il convient d'executer certaines actions qui influencent la ques- tion ayant trait a la decision. Toutefois, m | me si cette regle est appliquee, des boucles infinies peuvent appara | tre, comme indique dans la figure D-3.8.47. Il faut donc toujours faire atten- tion lorsque des reponses se referent a une decision de la m | me transition. Figure D-3.8.47, p. 37 Des decisions peuvent | tre prises a l'aide de toute valeur existant dans le processus et notamment: - des valeurs recues par une entree; - des valeurs transmises en tant que parametres effectifs au moment de la creation du processus; - des valeurs partagees. L'expression qui figure dans la question peut comprendre des constantes de l'un quelconque des types de valeurs susmentionnes. D.3.8.9 Branchements et connecteurs Les branchements permettent de transferer la commande d'un point a un autre d'un corps de processus (ainsi qu'a l'interieur d'un corps de procedure ou d'un corps de service). En LDS/PR, les branchements sont equivalents a des enonces <>. Des etiquettes sont utilisees comme points d'introduction associes aux instructions, comme indique dans la figure D-3.8.48. A l'interieur d'un corps de processus (ou d'un corps de procedure), il est impossible de transferer la commande (et par consequent les etiquettes associees) au type instructions indique dans la figure D-3.8.49. Les etiquettes demeurent toujours localisees dans un processus; il est donc impossible de transferer la commande d'un processus a un autre a l'aide d'un branchement. Figure D-3.8.48, p. 38 Figure D-3.8.49 [T21.100] (a traiter comme tableau MEP), p. 39 En LDS/GR, les branchements correspondent aux connecteurs (de sortie et d'entree). Elles peuvent | tre utilisees pour subdiviser les programmes, en cas de manque de place, ou pour eviter le croisement de lignes de liaison qui enleverait de leur clarte aux diagrammes. En outre, il est generalement preferable, lorsque l'on trace un diagramme en LDS, que la liaison se dirige du haut au bas de la page. En GR, toute ligne de liaison peut | tre interrompue par une paire de connecteurs associes; on admet alors que la liaison se dirige du connecteur de sortie au connecteur d'entree. Chaque sym- bole de connecteur contient un nom, associe aux connecteurs portant le m | me nom. Il existe un seul connecteur d'entree pour chaque nom mais il peut y avoir un ou plusieurs connecteurs de sortie. En GR, il est souhaitable que la page de reference se rappor- tant au connecteur d'entree approprie soit specifiee pour le con- necteur de sortie et que la ou les references de pages relatives aux connecteurs de sortie appropries devraient | tre donnees pour le connecteur d'entree (voir l'exemple de la figure D-3.8.50). Figure D-3.8.50, p. 40 D.3.9 Procedures En LDS, les procedures sont similaires aux procedures du CHILL et d'autres langages de programmation. Elles visent a: a) permettre de structurer un processus en plusieurs niveaux de precision; b) conserver la compacite des specifications en permettant de representer comme un seul element un assemblage com- plexe d'elements qui peuvent | tre consideres isolement; c) permettre de definir et d'utiliser a plusieurs reprises les assemblages d'elements utilises. Une definition de procedure ne peut exister que dans une definition de processus, dans une definition de service ou une definition de procedure et, par consequent, une procedure n'est visible que pour le processus ou la procedure dans lesquels elle est definie. Une definition de procedure se compose des elements suivants (dont certains sont facultatifs): - nom de la procedure; - parametres formels de procedure: liste de noms de variables associees a leur sorte. Ces parametres servent a transferer l'information de la procedure ou a partir de celle-ci au moment de l'appel. Les parametres de procedure peuvent | tre passes par valeur (parametre IN) ou par reference (parametre IN/OUT). Si un parametre est passe par valeur, la specification du parametre formel definit une variable locale a la procedure; s'il est passe par reference, la specification definit un synonyme pour la variable; - definitions de procedure: procedures qui peuvent | tre appelees tout comme la procedure proprement dite; - definitions de donnees: specification de types de donnees locales a la procedure; - definitions de variables: variables locales a la procedure; - corps de procedure: specification du comporte- ment effectif de la procedure pour ce qui est des etats et des actions (comme pour le corps de processus). On trouvera dans la figure D-3.9.1 un exemple partiel de definition de procedure en LDS/PR (les mots-cles du langage sont ecrits en majuscules). A noter que les parametres formels sans attribut explicite ont un attribut implicite IN (var5 dans la fig- ure). Figure D-3.9.1 [T22.100] (a traiter comme tableau MEP), p. 41 D.3.9.1 Corps de procedure Le corps de procedure presente de grandes similitudes avec le corps de processus; toutefois les differences sont les suivantes: - la procedure termine son interpretation avec une indication <> au lieu d'une indication <>. En LDS/PR, l'enonce de retour est represente par le mot-cle RETURN; - en LDS/GR, le symbole de debut de procedure est legerement different du symbole de debut de processus. Les symboles de debut et de retour de procedure sont indiques dans le resume du LDS/GR. Une procedure peut utiliser la construction avec branchements mais seulement pour se referer a une etiquette interne. Un branche- ment peut ne pas | tre utilise ou | tre utilise pour acceder a une procedure de l'exterieur ou quitter celle-ci. En LDS/GR, une definition de procedure est representee par un diagramme de procedure tres similaire au diagramme de processus. Le diagramme de procedure comprend les elements suivants: - un symbole de cadre facultatif: symbole de forme rectangulaire contenant tous les autres symboles; - l'en-t | te de procedure: le mot-cle PROC'DURE suivi du nom de la procedure et de la specification des parametres formels de procedure. Generalement, l'en-t | te de procedure est place dans l'angle superieur gauche du cadre ou, s'il n'y a pas de cadre, dans l'angle superieur gauche du support sur lequel le diagramme est trace; - une numerotation de pages facultatives (a placer dans l'angle superieur droit); - des symboles de texte: dans le cas d'un diagramme de procedure, un symbole de texte peut | tre utilise pour contenir la specification de definition de parametres formels, de donnees et de variables; - references de procedure: symboles de procedure, contenant chacun un nom de procedure representant une procedure locale definie separement; - des diagrammes de procedure: permettant de definir directement les procedures locales; - la zone graphique de procedure: specification du comportement de la procedure pour ce qui est du debut, des etats, des entrees, des sorties, des t | ches... et des arcs orientes. Dans la figure D-3.9.2, on trouvera un exemple de definition de procedure en LDS/GR. La procedure portant la reference <> dans l'exemple est locale a la procedure d'appel. Comme indique dans le cas des diagrammes de procedure (S D.3.8), si une seule page ne suffit pas a contenir un diagramme de procedure, celui-ci peut | tre represente sur plusieurs pages, avec repetition du symbole de cadre a la suite de l'en-t | te et du numero de page. Figure D-3.9.2, p. 42 D.3.9.2 Appel de procedure Les appels de procedure peuvent se produire chaque fois qu'une t | che et autorisee dans un graphe de processus ou de procedure. En un sens, une procedure peut | tre interpretee comme une t | che, avec les exceptions suivantes: 1) une procedure peut contenir des etats et, si tel est le cas, recevoir des signaux; 2) une procedure peut emettre des signaux. L'instance de processus d'origine est celle qui a appele la procedure. Lorsqu'une procedure est appelee, son environnement est cree et l'interpretation de la procedure commence. Elle se poursuit jusqu'a ce que l'on ait atteint l'indication RETURN (retour). Pen- dant l'interpretation de la procedure, tous les signaux adresses au processus sont soit mis en reserve implicitement soit traites explicitement par la procedure. La procedure n'a pas sa propre file d'attente mais utilise celle du processus qui l'a appelee. En LDS/PR, un appel de procedure est represente par le mot-cle CALL suivi de l'identificateur de procedure et de la liste de parametres reels mise entre parentheses. Si un parametre n'est pas donne, il convient de l'indiquer par deux virgules consecutives. Dans ce cas, le parametre formel correspondant a la valeur <>. A noter aussi que la declaration de IN ou IN/OUT est faite dans la definition de procedure, de sorte qu'elle ne doit pas | tre repetee par l'enonce d'appel. On trouvera certains exemples d'appel en LDS/PR dans la figure D-3.9.3. Figure D-3.9.3 [T23.100] (a traiter comme tableau MEP), p. 43 En LDS/GR, un appel de procedure est represente a l'aide d'un symbole d'appel de procedure contenant le nom de procedure et la liste des parametres reels mise entre parantheses. On trouvera un exemple d'appel en LDS/GR dans la figure D-3.9.2. Blanc