home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-12-12 | 52.3 KB | 1,634 lines |
- .rs
- .\" Troff code generated by TPS Convert from ITU Original Files
- .\" Not Copyright ( c) 1991
- .\"
- .\" Assumes tbl, eqn, MS macros, and lots of luck.
- .TA 1c 2c 3c 4c 5c 6c 7c 8c
- .ds CH
- .ds CF
- .EQ
- delim @@
- .EN
- .nr LL 40.5P
- .nr ll 40.5P
- .nr HM 3P
- .nr FM 6P
- .nr PO 4P
- .nr PD 9p
- .po 4P
-
- .rs
- \v | 5i'
- .sp 1P
- .LP
- D.3.8.2.1
- \fID\*'etermination des \*'etats requis\fR
- .sp 9p
- .RT
- .PP
- L'auteur d'un diagramme LDS dispose g\*'en\*'eralement d'une certaine
- latitude pour d\*'efinir les \*'etats d'un processus. Il peut avoir besoin
- d'une
- strat\*'egie qui lui permette d'identifier les \*'etats du processus et cette
- strat\*'egie peut \* | tre informelle ou formelle. Un jugement s\* | r
- (que seule une
- longue exp\*'erience permet d'acqu\*'erir) est n\*'ecessaire 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 r\*'eduit
- 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 pr\*'eliminaires
- (\*'etudi\*'ees au \(sc\ D.3.2) doivent \* | tre achev\*'ees, par exemple:
- .EF '% Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D''
- .OF '''Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D %'
- .RT
- .LP
- \(em
- la structuration du syst\*`eme en blocs fonctionnels;
- .LP
- \(em
- la repr\*'esentation d'un ou plusieurs processus LDS par bloc;
- .LP
- \(em
- le choix des signaux d'entr\*'ee et de sortie;
- .LP
- \(em
- l'utilisation des donn\*'ees dans le processus.
- .PP
- Tous les facteurs ci\(hydessus exercent un effet important dans la
- d\*'etermination des \*'etats de chaque processus. L'effet qu'exerce le
- choix des
- signaux d'entr\*'ee sur le nombre d'\*'etats d'un diagramme LDS est illustr\*'e
- par les deux exemples de la figure\ D\(hy3.8.11.
- .LP
- .rs
- .sp 34P
- .ad r
- \fBFigure D\(hy3.8.11, p. 1\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- D.3.8.2.2
- \fIR\*'eduction du nombre des \*'etats\fR
- .sp 9p
- .RT
- .PP
- Ayant appliqu\*'e une strat\*'egie pour l'identification des \*'etats d'un
- processus, l'auteur d'un diagramme LDS estimera peut\(hy\* | tre qu'un
- trop grand
- nombre d'\*'etats ont \*'et\*'e utilis\*'es. Le nombre des \*'etats est
- important car la
- dimension et la complexit\*'e d'un diagramme LDS sont souvent \*'etroitement
- li\*'ees \*`a ce nombre. Il existe certes des moyens qui permettent de
- r\*'eduire 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 complexit\*'e du diagramme peut
- \* | tre simplement due \*`a la complexit\*'e inh\*'erente au processus
- d\*'efini. Le choix de l'ensemble d'\*'etats doit g\*'en\*'eralement offrir
- le plus de clart\*'e possible \*`a la s\*'equence d'interactions entre
- le processus et son environnement. Ce n'est
- d'ordinaire pas en minimisant le nombre d'\*'etats que l'on obtient cette
- clart\*'e. Le nombre de s\*'equences ind\*'ependantes trait\*'ees par un
- processus exerce un effet multiplicateur sur le nombre d'\*'etats. Il est
- donc souhaitable que les s\*'equences ind\*'ependantes des processus s\*'epar\*'es
- soient trait\*'ees de fa\*,con \*`a r\*'eduire le
- nombre d'\*'etats et \*`a obtenir une plus grande clart\*'e.
- .PP
- On peut r\*'eduire le nombre des \*'etats en effectuant la s\*'eparation des
- fonctions communes ou la fusion des \*'etats ou encore en recourant au
- concept de service. Certaines structures de donn\*'ees peuvent \*'egalement
- conduire \*`a une
- r\*'eduction du nombre des \*'etats. Pour d'autres repr\*'esentations,
- l'emploi des
- macros peut \* | tre avantageux.
- .RT
- .sp 1P
- .LP
- D.3.8.2.3
- \fIS\*'eparation des fonctions communes\fR
- .sp 9p
- .RT
- .PP
- Lors de la mise en place d'un diagramme LDS, on peut constater que la d\*'efinition
- d'un aspect particulier et r\*'ep\*'etitif d'un processus n\*'ecessite
- la repr\*'esentation d'\*'etats r\*'ep\*'etitifs. La figure\ D\(hy3.8.12
- repr\*'esente une partie
- d'un diagramme LDS d\*'efinissant un processus de signalisation de ligne et
- illustrant la condition selon laquelle une tonalit\*'e de signalisation
- de ligne doit \* | tre pr\*'esente pendant une certaine dur\*'ee avant
- que l'on consid\*`ere que le signal de ligne a \*'et\*'e d\*'etect\*'e.
- .PP
- Pour sp\*'ecifier cet aspect, il convient d'ins\*'erer un \*'etat interm\*'ediaire
- entre les \*'etats aucun
- \(ulsignal
- \(ulde
- \(ul
- ligne
- \(uln'est
- \(uld\*'etect\*'e et conversation. Supposons
- que, dans un diagramme complet, une telle fonction commune doit \* | tre
- r\*'ep\*'et\*'ee \*`a chaque point o\*`u le signal est d\*'etect\*'e. Une
- autre solution consiste \*`a
- d\*'efinir un processus s\*'epar\*'e qui est responsable du contr\* | le
- de la tonalit\*'e de signalisation de ligne et de la d\*'etection des signaux
- sur la base du temps de reconnaissance sp\*'ecifi\*'e. L'existence de ce
- nouveau processus permettrait de
- repr\*'esenter le diagramme de la figure D\(hy3.8.12 de la mani\*`ere indiqu\*'ee
- dans la figure\ D\(hy3.8.13. (Dans un contexte donn\*'e, les figures peuvent
- \* | tre rendues
- \*'equivalentes moyennant l'introduction d'un nouveau signal
- signal
- \(ulde
- \(ulligne
- \(ulvalide.)
- .RT
- .PP
- Il convient de noter la l\*'eg\*`ere diff\*'erence entre le processus de
- la figure\ D\(hy3.8.12 et les deux processus de la figure\ D\(hy3.8.13.
- .PP
- Le processus de la figure D\(hy3.8.12 commence \*`a compter d\*`es r\*'eception
- de\ T1 alors que le processus de traitement des appels [processus\ b) de
- la
- figure\ D\(hy3.8.13] commence \*`a compter d\*`es r\*'eception de
- signal
- \(ulde
- \(ul
- ligne
- \(ulvalide qui est engendr\*'e
- et \*'emis \*`a la r\*'eception de\ T1 par le processus\ a) de la figure\
- D\(hy3.8.13. Il
- s'ensuit que, dans le second cas, le comptage d\*'emarre apr\*`es T1\ +\
- temps de
- g\*'en\*'eration, d'\*'emission et de r\*'eception du signal. En outre,
- d'autres signaux
- peuvent avoir \*'et\*'e mis dans la file d'attente pendant le temps n\*'ecessaire
- \*`a la g\*'en\*'eration et \*`a l'\*'emission de signal
- \(ulde
- \(ulligne
- \(ulvalide.
- .PP
- Une seconde particularit\*'e est que cette s\*'eparation d'une sous\(hyfonction
- ne serait pas possible si le signal que doit recevoir la sous\(hyfonction
- devait \* | tre re\*,cu \*'egalement par la fonction principale, un signal
- \*'etant toujours
- achemin\*'e vers un seul processus. Si, dans l'exemple, le m\* | me signal
- S
- \(uloff devait \* | tre re\*,cu dans un autre \*'etat o\*`u il n'est pas
- besoin de
- le valider pour le temps\ T1, il n'aurait pas \*'et\*'e possible de s\*'eparer
- la
- sous\(hyfonction de validation en un autre processus.
- .PP
- Les solutions qui font appel \*`a des processus distincts sont
- g\*'en\*'eralement utiles lorsque les signaux doivent \* | tre trait\*'es
- ind\*'ependamment
- des \*'etats dans le processus principal. Dans ce cas, les op\*'erations qui
- pr\*'ec\*`edent et qui suivent les processus peuvent traiter les s\*'equences
- d\*'etaill\*'ees et d\*'echarger un processus principal de tous les d\*'etails.
- Ceci
- engendre souvent une modularit\*'e utile permettant, par exemple, d'isoler les
- caract\*'eristiques particuli\*`eres des syst\*`emes de signalisation,
- du processus
- principal plus ax\*'e sur le service.
- .PP
- Une autre mani\*`ere de traiter le probl\*`eme consiste \*`a appliquer le
- concept de service, expliqu\*'e au \(sc\ D.5.3.
- .PP
- Une solution diff\*'erente du probl\*`eme consisterait \*`a employer la
- notation MACRO, comme indiqu\*'e \*`a la figure\ D\(hy3.3.1. Dans ce cas,
- on obtient
- pour le diagramme la compacit\*'e voulue sans modifier en rien la s\*'emantique
- du
- diagramme original. Il est en outre possible d'appeler la MACRO \*`a partir de
- plusieurs \*'etats si la logique du processus l'exige.
- .bp
- .RT
- .LP
- .rs
- .sp 32P
- .ad r
- \fBFigure D\(hy3.8.12, p. 2\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 29P
- .ad r
- \fBFigure D\(hy3.8.13, p. 3\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.2.4
- \fIFusion des \*'etats\fR
- .sp 9p
- .RT
- .PP
- Si, dans un diagramme LDS, la destination future de deux \*'etats est la
- m\* | me, on peut, ind\*'ependamment de leur \*'evolution ant\*'erieure,
- effectuer la
- fusion de ces deux \*'etats en un seul, sans affecter la logique du
- diagramme.
- .PP
- La figure D\(hy3.8.14 repr\*'esente une partie d'un diagramme LDS comportant
- deux \*'etats dont le <<pass\*'e>> est diff\*'erent mais dont le <<futur>>
- est identique.
- Dans la figure\ D\(hy3.8.15, les deux \*'etats ont \*'et\*'e combin\*'es
- en un seul. Il s'agit l\*`a d'un exemple relativement simple dans lequel
- la r\*'eduction de la complexit\*'e est peu importante, mais cette m\* | me
- technique peut \* | tre utilis\*'ee pour obtenir une plus grande simplification.
- La s\*'emantique du LDS ne pr\*'evoit pas une
- d\*'ecision cons\*'ecutive \*`a un \*'etat pour d\*'eterminer le <<pass\*'e>>
- du processus
- ant\*'erieurement \*`a cet \*'etat (c'est\(hy\*`a\(hydire de d\*'eterminer,
- pour cet exemple,
- si\ A6 ou\ B4 a \*'et\*'e \*'emis), \*`a moins que cette information n'ait
- \*'et\*'e explicitement stock\*'ee avant l'entr\*'ee dans l'\*'etat. A
- noter, que l'attribution d'un nom aux
- donn\*'ees d'une entr\*'ee a pour effet de mettre la valeur en m\*'emoire.
- .PP
- Un \*'etat doit repr\*'esenter une situation logique du processus et il
- n'est donc pas souhaitable d'effectuer la fusion de situations logiques
- diff\*'erentes en un seul \*'etat.
- .PP
- Des pr\*'ecautions sont \*`a prendre si un diagramme fusionn\*'e doit \* | tre
- modifi\*'e ult\*'erieurement. L'usager devrait rechercher si la modification
- envisag\*'ee a ou non le m\* | me effet sur les diverses branches
- initiales.
- .bp
- .RT
- .LP
- .rs
- .sp 33P
- .ad r
- \fBFigures D\(hy3.8.14 et D\(hy3.8.15,\ \ \ C\* | TE\(hy\o"A\(ga"\(hyC\* | TE,
- p. 4\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.3
- \fIEntr\*'ees\fR
- .sp 9p
- .RT
- .PP
- Le pr\*'esent \(sc D.3.8.3 a pour objet d'expliquer la notion d'entr\*'ee
- ainsi que l'utilisation des entr\*'ees dans des diagrammes LDS ne faisant pas
- appel \*`a la notion de mise en r\*'eserve. La notion de mise en r\*'eserve et
- l'utilisation de cette notion en m\* | me temps que la notion d'entr\*'ee font
- l'objet du \(sc\ D.3.8.4.
- .RT
- .sp 1P
- .LP
- D.3.8.3.1
- \fIConsid\*'erations g\*'en\*'erales\fR
- .sp 9p
- .RT
- .PP
- Un symbole d'entr\*'ee attach\*'e \*`a un \*'etat signifie que, si le signal
- dont le nom figure dans le symbole d'entr\*'ee arrive pendant que le processus
- est dans cet \*'etat, il faut interpr\*'eter la transition qui suit le
- symbole d'entr\*'ee. Lorsqu'un signal a d\*'eclench\*'e l'interpr\*'etation
- d'une transition, ce signal
- n'existe plus et on dit qu'il a \*'et\*'e absorb\*'e.
- .PP
- Un signal peut \* | tre accompagn\*'e de donn\*'ees associ\*'ees. Par exemple,
- un signal portant le nom <<chiffre>> sert non seulement \*`a d\*'eclencher
- l'ex\*'ecution
- d'une transition par le processus de r\*'eception mais encore \*`a v\*'ehiculer
- la valeur du chiffre (0\ \*`a\ 9), ces donn\*'ees pouvant \* | tre utilis\*'ees
- par le
- processus r\*'ecepteur.
- .PP
- En LDS/PR, l'instruction INPUT contient une liste d'identificateurs de
- signaux. Les valeurs contenues dans les signaux sont indiqu\*'ees \*`a
- l'aide
- d'identificateurs de variables. Les identificateurs de variables doivent
- \* | tre du type indiqu\*'e dans la d\*'efinition de signal, de sorte que
- leur position est
- tr\*`es importante. Ces identificateurs de variables sont plac\*'es entre
- parenth\*`eses et s\*'epar\*'es par des virgules (voir la figure\ D\(hy3.8.16).
- Si une ou plusieurs valeurs de signal sont rejet\*'ees, les variables correspondantes
- font d\*'efaut, ce qui est indiqu\*'e par deux ou plusieurs virgules cons\*'ecutives
- (figure\ D\(hy3.8.17).
- .bp
- .RT
- .LP
- .rs
- .sp 15P
- .ad r
- \fBFigure D\(hy3.8.16 [T13.100] \ \
- (\*`a traiter comme tableau MEP), p. 6\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 7P
- .ad r
- \fBFigure D\(hy3.8.17 [T14.100] \ \
- (\*`a traiter comme tableau MEP), p. 7\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- En LDS/GR, une entr\*'ee est repr\*'esent\*'ee \*`a l'aide d'un symbole
- d'entr\*'ee contenant la liste d'identificateurs de signaux et les identificateurs
- de variables correspondants pour les valeurs achemin\*'ees. Pour pouvoir
- \* | tre
- communiqu\*'ees au processus, ces valeurs doivent \* | tre d\*'esign\*'ees
- nomm\*'ement dans les symboles d'entr\*'ee, entre parenth\*`eses.
- .PP
- On trouvera des exemples de r\*'eception de valeurs des entr\*'ees dans
- les figures\ D\(hy3.8.18, D\(hy3.8.19 et D\(hy3.8.20.
- .PP
- Les donn\*'ees auxquelles un nom est assign\*'e peuvent \* | tre utilis\*'ees
- par le processus r\*'ecepteur quand l'entr\*'ee est interpr\*'et\*'ee.
- .PP
- La figure D\(hy3.8.18 montre la r\*'eception du signal <<d\*'ecroch\*'e>>.
- Le signal <<d\*'ecroch\*'e>> est accompagn\*'e de donn\*'ees associ\*'ees
- (num\*'ero
- \(ulde
- \(ull'abonn\*'e) avec pour valeur\ 9269. Le signal
- peut \* | tre re\*,cu de trois mani\*`eres, comme indiqu\*'e en a) et\
- c) de la figure.
- .PP
- La figure D\(hy3.8.19 montre comment envoyer et recevoir plusieurs
- valeurs en un seul signal. Chaque \*'el\*'ement doit \* | tre s\*'epar\*'e
- du suivant par une virgule. La figure\ D\(hy3.8.20\ c) montre comment ignorer
- les valeurs ind\*'esirables en laissant un blanc dans la liste de sortes.
- .PP
- A noter que, dans le signal de sortie, il est impossible d'\*'ecrire des
- expressions pour\ E1, E2 ou\ E3, alors que dans le signal d'entr\*'ee,
- il faut
- employer des variables pour recevoir les valeurs \*'emises.
- .PP
- Dans le LDS, il n'est pas n\*'ecessaire de dessiner des symboles d'entr\*'ee
- pour repr\*'esenter les signaux dont l'arriv\*'ee n\*'ecessiterait une
- transition nulle (c'est\(hy\*`a\(hydire une transition qui ne contient
- aucune action et qui ram\*`ene au m\* | me \*'etat). La convention admise
- est la suivante: pour tout signal qui n'est pas repr\*'esent\*'e dans un
- symbole d'entr\*'ee explicite \*`a un \*'etat donn\*'e, il existe, dans
- cet \*'etat, un symbole d'entr\*'ee implicite et une transition nulle.
- Conform\*'ement \*`a cette convention, les deux diagrammes repr\*'esent\*'es
- dans la
- figure\ D\(hy3.8.21 sont logiquement \*'equivalents et peuvent \* | tre
- indistinctement utilis\*'es.
- .bp
- .RT
- .LP
- .rs
- .sp 25P
- .ad r
- \fBFigure D\(hy3.8.18, p. 8\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 32P
- .ad r
- \fBFigure D\(hy3.8.19, p. 9\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 29P
- .ad r
- \fBFigure D\(hy3.8.20, p. 10\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 30P
- .ad r
- \fBFigure D\(hy3.8.21, p. 11\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Lorsqu'un certain nombre d'entr\*'ees aboutissent \*`a la m\* | me
- transition, tous les identificateurs de signaux qui s'y rapportent peuvent
- \* | tre plac\*'es dans un m\* | me symbole d'entr\*'ee. Le LDS pr\*'evoit
- une notation
- abr\*'eg\*'ee pour repr\*'esenter une entr\*'ee de tous les signaux (valable
- pour ce
- processus) non explicitement mentionn\*'es dans cet \*'etat. La figure\
- D\(hy3.8.22
- illustre cet aspect et les diagrammes qui y sont repr\*'esent\*'es sont
- logiquement \*'equivalents. Si tous les identificateurs de signaux sont
- mentionn\*'es, il faut
- les s\*'eparer par des virgules.
- .sp 1P
- .LP
- D.3.8.3.2
- \fIM\*'ecanisme implicite de mise en file d'attente\fR
- .sp 9p
- .RT
- .PP
- 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 mani\*`ere si
- l'on veut \*'eviter qu'ils soient perdus. Lorsqu'un signal parvient au
- bloc de destination, il est plac\*'e dans la file d'attente d'entr\*'ee
- du processus de r\*'eception. La s\*'emantique du LDS d\*'efinit pour chaque
- processus un m\*'ecanisme th\*'eorique de mise en file d'attente selon
- lequel le mode de s\*'election des signaux pour l'absorption par le
- processus est fond\*'e sur l'ordre d'arriv\*'ee des signaux dans ce processus.
- Lorsque le processus parvient \*`a un \*'etat, il re\*,coit 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 signal qui vient de la
- file d'attente en question. Si cette derni\*`ere est vide, le processus
- demeure en attente dans l'\*'etat jusqu'\*`a l'arriv\*'ee \*`a la file
- d'attente d'un signal qui est ensuite
- absorb\*'e par le processus.
- .PP
- La figure D\(hy3.8.23 utilise le concept de file d'attente pour expliquer
- le fonctionnement d'un processus LDS dans lequel les temps de transition
- sont diff\*'erents de z\*'ero. Il convient de noter les \*'el\*'ements
- suivants:
- .RT
- .LP
- \(em
- le concept de mise en r\*'eserve n'est pas appliqu\*'e et les
- signaux sont absorb\*'es dans l'ordre de leur arriv\*'ee;
- .LP
- \(em
- l'ordre de succession de l'arriv\*'ee des signaux est important. Si <<C>>
- \*'etait arriv\*'e avant <<B>> dans la transition entre l'\*'etat\ 1 et
- l'\*'etat\ 2, la s\*'equence des \*'etats aurait \*'et\*'e\ 1, 2, 3 au
- lieu de\ 1, 2,\ 4;
- .bp
- .LP
- .rs
- .sp 24P
- .ad r
- \fBFigure D\(hy3.8.22, p. 12\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- \(em
- 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;
- .LP
- \(em
- il n'est pas possible d'attribuer la priorit\*'e \*`a un
- signal. Un m\*'ecanisme sp\*'ecial est pr\*'evu pour les communications
- entre services, afin que les signaux \*'echang\*'es entre service soient
- trait\*'es avant les autres
- signaux (\(sc\ D.5.3).
- .PP
- Si les temps de transition sont nuls, chaque signal sera absorb\*'e au
- moment de son arriv\*'ee dans un processus, sauf si l'on a recours \*`a
- la mise en r\*'eserve (voir le \(sc\ D.3.8.4).
- .sp 1P
- .LP
- D.3.8.3.3
- \fIR\*'eception des signaux qui ne se pr\*'esentent pas normalement\fR
- .sp 9p
- .RT
- .PP
- Dans chacun des \*'etats, tous les signaux possibles doivent \* | tre
- indiqu\*'es implicitement ou explicitement. Des exceptions (signaux inattendus
- mais th\*'eoriquement possibles, signaux non d\*'efinis ou logiquement
- faux \*`a un
- endroit donn\*'e,\ etc.) peuvent se pr\*'esenter dans presque tous les
- \*'etats.
- Normalement, l'auteur n'indique pas ces possibilit\*'es; il s'ensuit qu'un tel
- signal sera \*'elimin\*'e s'il se pr\*'esente. Si toutefois l'auteur tient
- \*`a faire
- figurer les exceptions dans son diagramme, il doit pr\*'evoir pour tous les
- \*'etats une entr\*'ee suppl\*'ementaire.
- .PP
- Une autre possibilit\*'e consiste \*`a profiter des apparitions multiples
- d'un \*'etat portant le symbole <<tous>>\ (*). Par exemple, si le signal
- A
- \(ulRACCROCH\o"E\(aa" peut \* | tre re\*,cu dans tous les \*'etats et si
- les actions
- post\*'erieures sont identiques, on peut recourir \*`a la m\*'ethode indiqu\*'ee
- \*`a la
- figure\ D\(hy3.8.24.
- .RT
- .sp 1P
- .LP
- D.3.8.3.4
- \fIArriv\*'ee simultan\*'ee de signaux\fR
- .sp 9p
- .RT
- .PP
- La Recommandation Z.100 (\(sc 2) pr\*'evoit que les signaux peuvent
- parvenir simultan\*'ement \*`a un processus et pr\*'ecise qu'ils seront
- plac\*'es dans un ordre arbitraire.
- .PP
- Si un usager met au point un processus capable de recevoir des signaux
- simultan\*'es, il doit veiller \*`a ce que l'ordre d'arriv\*'ee ne bouleverse
- pas le
- fonctionnement escompt\*'e du processus.
- .PP
- Le LDS ne pr\*'econise pas de priorit\*'e parmi les signaux; ainsi, en
- cas d'arriv\*'ee simultan\*'ee de signaux, l'un d'eux est choisi arbitrairement.
- A noter cependant que les signaux pour communications entre services sont
- toujours
- trait\*'es les premiers (\(sc\ D.5.3).
- .PP
- Si plusieurs signaux sont disponibles au moment de l'entr\*'ee du
- processus dans un \*'etat, un seul signal est pr\*'esent\*'e au processus
- puis reconnu comme une entr\*'ee. Selon la s\*'emantique du LDS, les autres
- signaux sont en fait retenus.
- .bp
- .RT
- .LP
- .rs
- .sp 33P
- .ad r
- \fBFigure D\(hy3.8.23, p. 13\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 17P
- .ad r
- \fBFigure D\(hy3.8.24, p. 14\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- D.3.8.3.5
- \fIIdentification de l'\*'emetteur\fR
- .sp 9p
- .RT
- .PP
- Chaque signal est porteur de la valeur d'instance du processus
- (PId) du processus \*'emetteur. Lorsqu'un signal est absorb\*'e, la valeur
- PId du
- processus \*'emetteur peut \* | tre obtenue au moyen de l'expression SENDER. On
- trouvera dans la figure\ D\(hy3.8.25 un exemple d'emploi de cette variable.
- .RT
- .LP
- .rs
- .sp 13P
- .ad r
- \fBFigure D\(hy3.8.25, p. 15\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.4
- \fIMises en r\*'eserve\fR
- .sp 9p
- .RT
- .PP
- Le concept de mise en r\*'eserve permet de diff\*'erer l'absorption d'un
- signal jusqu'\*`a ce qu'un ou plusieurs signaux ult\*'erieurs aient \*'et\*'e
- absorb\*'es.
- Comme l'indique le \(sc\ D.3.8.3, les signaux sont absorb\*'es dans l'ordre
- dans
- lequel ils se pr\*'esentent, sauf en cas d'emploi du concept de mise en
- r\*'eserve.
- .PP
- L'on peut faire appel au concept de mise en r\*'eserve afin de simplifier
- les processus lorsque l'ordre relatif d'arriv\*'ee de certains signaux
- n'a pas
- d'importance et que leur ordre effectif d'arriv\*'ee est ind\*'etermin\*'e.
- .PP
- Dans chaque \*'etat, chaque signal est trait\*'e comme suit:
- .RT
- .LP
- \(em
- il est repr\*'esent\*'e comme un symbole d'entr\*'ee ou,
- .LP
- \(em
- il est repr\*'esent\*'e comme un symbole de mise en r\*'eserve ou,
- .LP
- \(em
- il est, par convention, couvert par une entr\*'ee implicite
- aboutissant \*`a une transition nulle implicite.
- .PP
- Le fonctionnement du m\*'ecanisme implicite de mise en file d'attente d\*'ecrit
- dans le \(sc\ D.3.8.3 s'applique \*'egalement au concept de mise en r\*'eserve.
- A leur arriv\*'ee, les signaux sont plac\*'es dans la file d'attente et
- lorsque le
- processus atteint un \*'etat donn\*'e, les signaux qui se trouvent dans la file
- d'attente sont examin\*'es un \*`a un dans l'ordre de leur arriv\*'ee.
- Un signal
- couvert par un symbole d'entr\*'ee explicite ou implicite est absorb\*'e et la
- transition qui s'y rapporte est ex\*'ecut\*'ee. Un signal repr\*'esent\*'e
- dans un symbole de mise en r\*'eserve n'est pas absorb\*'e et reste dans
- la file d'attente dans la
- m\* | me position s\*'equentielle; le signal suivant de la file d'attente est
- consid\*'er\*'e. Aucune transition ne suit un symbole de mise en r\*'eserve.
- .PP
- En LDS/PR, la construction de mise en r\*'eserve est exprim\*'ee \*`a l'aide
- du mot\(hycl\*'e SAVE suivi d'une liste d'identificateurs de signaux. On
- trouvera un exemple simple d'\*'enonc\*'es de MISE EN R\o"E\(aa"SERVE dans
- la figure\ D\(hy3.8.26.
- .RT
- .LP
- .rs
- .sp 11P
- .ad r
- \fBFigure D\(hy3.8.26 [T15.100] \ \
- (\*`a traiter comme tableau MEP), p. 16\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- En LDS/GR, le concept de mise en r\*'eserve est repr\*'esent\*'e \*`a l'aide
- du symbole de mise en r\*'eserve contenant les identificateurs de signaux.
- .PP
- Comme dans le cas des entr\*'ees, une <<notation avec ast\*'erisque>> peut
- servir \*`a repr\*'esenter la mise en r\*'eserve de tous les signaux (valides
- pour ce processus) qui ne sont pas explicitement mentionn\*'es dans cet
- \*'etat.
- .PP
- La figure D\(hy3.8.27 repr\*'esente un exemple d'un processus LDS qui
- comporte un symbole de mise en r\*'eserve. Il convient de noter que les
- signaux\ S et\ R sont consomm\*'es dans l'ordre\ R, S, c'est\(hy\*`a\(hydire
- dans l'ordre inverse de
- leur r\*'eception. Un symbole de mise en r\*'eserve unique peut servir
- \*`a mettre un signal en r\*'eserve tant que le processus se trouve dans
- l'\*'etat dans lequel le
- symbole appara\* | t; ce signal est mis en r\*'eserve pour la dur\*'ee
- de la transition vers le prochain \*'etat. Dans le prochain \*'etat, le
- signal sera absorb\*'e par
- l'interm\*'ediaire d'une entr\*'ee explicite ou implicite (voir la figure\
- D\(hy3.8.27) sauf dans les cas suivants: lorsque le symbole de mise en
- r\*'eserve comportant le nom du signal est r\*'ep\*'et\*'e ou lorsque dans
- la file d'attente implicite, il existe avant lui, un autre signal de sauvegarde
- disponible pour absorption (voir la
- figure\ D\(hy3.8.28).
- .RT
- .LP
- .rs
- .sp 33P
- .ad r
- \fBFigure D\(hy3.8.27, p. 17\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 32P
- .ad r
- \fBFigure D\(hy3.8.28, p. 18\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Un signal mis en r\*'eserve n'est mis \*`a disposition d'un processus que
- par l'interm\*'ediaire d'un symbole d'entr\*'ee correspondant (explicite
- ou
- implicite). Aucune question relative \*`a un signal mis en r\*'eserve ne
- peut \* | tre pos\*'ee dans une d\*'ecision avant la reconnaissance de
- ce signal comme une entr\*'ee; de m\* | me les donn\*'ees qui lui sont
- associ\*'ees ne sont pas disponibles.
- .PP
- Dans un \*'etat o\*`u plusieurs signaux doivent \* | tre mis en r\*'eserve, on
- peut attribuer un symbole de mise en r\*'eserve \*`a chaque signal ou on
- peut les
- repr\*'esenter tous \*`a l'int\*'erieur du m\* | me symbole de mise en
- r\*'eserve. Si
- plusieurs signaux doivent \* | tre mis en r\*'eserve, la s\*'emantique
- du symbole de
- mise en r\*'eserve exige que l'ordre de leur arriv\*'ee soit pr\*'eserv\*'e.
- .PP
- Un troisi\*`eme exemple de l'utilisation de la notion de mise en r\*'eserve
- est donn\*'e dans la figure\ D\(hy3.8.29 et la figure\ D\(hy3.8.30 d\*'ecrit
- le
- fonctionnement du m\*'ecanisme de formation de la file d'attente.
- .PP
- L'utilisation du symbole de mise en r\*'eserve peut simplifier les
- diagrammes. Ainsi, en mettant un signal en r\*'eserve, l'on peut \*'eviter
- de le
- recevoir et de devoir mettre en m\*'emoire ses donn\*'ees associ\*'ees
- jusqu'\*`a l'\*'etat suivant.
- .PP
- Bien que le symbole de mise en r\*'eserve puisse \* | tre utilis\*'e \*`a
- chaque niveau de description, il y aurait peut\(hy\* | tre lieu, au niveau
- inf\*'erieur, de
- d\*'ecrire le m\*'ecanisme effectif qui permet cette mise en r\*'eserve.
- .PP
- Sans un minimum de pr\*'ecautions dans l'emploi de la mise en r\*'eserve,
- la file d'attente des signaux mis en r\*'eserve peut augmenter consid\*'erablement
- ou
- garder des signaux en m\*'emoire trop longtemps, de sorte qu'un signal ancien
- peut \* | tre absorb\*'e lorsqu'un signal r\*'ecent est demand\*'e.
- .PP
- Le LDS ne pr\*'evoit pas de limite \*`a la longueur de la file d'attente,
- ce qui peut poser des probl\*`emes de mise en oeuvre.
- .bp
- .RT
- .LP
- .rs
- .sp 29P
- .ad r
- \fBFigure D\(hy3.8.29, p. 19\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 27P
- .ad r
- \fBFigure D\(hy3.8.30, p. 20\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- D.3.8.5
- \fICondition de validation et signaux continus\fR
- .sp 9p
- .RT
- .PP
- Les conditions de validation permettent une r\*'eception
- conditionnelle de signaux fond\*'ee sur la condition de validation sp\*'ecifi\*'ee.
- Le signal est re\*,cu et la transition interpr\*'et\*'ee si la condition
- est vraie. En
- cas de condition fausse, le signal est mis en r\*'eserve 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\(hy3.8.31 illustre ceci. Lorsque P1
- passe \*`a l'\*'etat\ S1, la condition (c'est\(hy\*`a\(hydire de savoir
- si IMPORT (X,P2) est \*'egal \*`a\ 10) est \*'evalu\*'ee. Si elle est vraie,
- le signal\ B peut \* | tre re\*,cu.
- Sinon, le signal\ B est mis en r\*'eserve. 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 condition li\*'ee au signal\ B dans
- l'\*'etat\ S2 est vraie. Etant donn\*'e que\ B est le premier signal de
- la file d'attente, la
- transition qui suit est ex\*'ecut\*'ee et le processus prend fin \*`a l'\*'etat\
- S3.
- .PP
- Certaines caract\*'eristiques des conditions de validation
- sont importantes:
- .RT
- .LP
- 1)
- la condition de validation est test\*'ee lorsque le processus arrive
- \*`a un \*'etat; il est alors continuellement contr\* | l\*'e tandis que
- le
- processus reste dans cet \*'etat. Ainsi, si la valeur export\*'ee de\ X
- avait pass\*'e
- de\ 9 \*`a\ 11 puis \*`a\ 12 pendant la transition qui faisait suite \*`a
- la r\*'eception de\ A, le processus serait rest\*'e \*`a\ S2;
- .LP
- 2)
- les conditions de validation peuvent \* | tre fond\*'ees sur des variables
- locales et/ou toute construction de langage qui peut \* | tre comprise
- dans une expression (par exemple, IMPORT (IMPORTATION), VIEW (VUE), NOW
- (MAINTENANT));
- .LP
- 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 autoris\*'e. Ainsi, la condition indiqu\*'ee dans la figure\
- D\(hy3.8.32 n'est pas
- autoris\*'ee. Si un signal donn\*'e exige des conditions multiples, il
- est possible de les combiner en une expression bool\*'eenne ainsi que le
- montre la
- figure\ D\(hy3.8.33.
- .PP
- On peut \*'evaluer les conditions de validation plusieurs fois et
- dans un ordre quelconque, de sorte que l'usager doit \* | tre vigilant si les
- expressions ont des effets secondaires r\*'eciproques (par exemple IMPORT et
- SENDER combin\*'es).
- .PP
- Il faut noter en outre que le signal sp\*'ecifi\*'e dans la condition de
- validation ne peut influencer la valeur bool\*'eenne de la condition car ses
- valeurs transport\*'ees ne sont pas affect\*'ees avant l'absorption du
- signal. A
- titre d'exemple, les \*'enonc\*'es:
- .RT
- .LP
- INPUT\ x(A) PROVIDED (A=5);...
- INPUT\ y PROVIDED(SENDER)=pid1);
- .LP
- 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.
- .PP
- Les signaux continus ont les m\* | mes propri\*'et\*'es fondamentales que
- la condition de validation, except\*'e le fait qu'ils ne sont accompagn\*'es
- d'aucun signal. Ainsi, en l'absence de signaux dans la file d'attente susceptibles
- de provoquer une transition \*`a leur entr\*'ee dans l'\*'etat, les signaux
- continus sont contr\* | l\*'es; si l'un d'entre eux est vrai, la transition
- qui le suit est
- ex\*'ecut\*'ee. L'exemple de la figure\ D\(hy3.8.34 en donne l'illustration. A
- l'origine, le processus se trouve \*`a l'\*'etat\ S1 et la valeur export\*'ee
- 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 transition vers l'\*'etat\ S3 s'accomplit.
- .PP
- L'on trouvera ci\(hydessous certaines caract\*'eristiques importantes des
- signaux continus:
- .RT
- .LP
- 1)
- de m\* | me que pour les conditions de validation, la valeur de la condition
- n'est contr\* | l\*'ee qu'\*`a l'arriv\*'ee \*`a un \*'etat;
- .LP
- 2)
- les signaux continus multiples sont autoris\*'es pour chaque
- \*'etat. Lorsque plusieurs signaux continus sont li\*'es \*`a un \*'etat,
- le signal
- continu ayant le rang de priorit\*'e le plus \*'elev\*'e (le num\*'ero
- le plus bas) sera
- trait\*'e le premier. Deux signaux continus ne peuvent avoir le m\* | me
- rang de
- priorit\*'e. Le signal continu est toujours moins prioritaire que tout autre
- signal. Ceci est de nouveau d\* | au syst\*`eme sous\(hyjacent du LDS:
- toutefois, la repr\*'esentation \*`a l'aide de mod\*`eles des signaux continus
- en LDS (emploi des
- signaux \*'emis pendant l'exportation de variables), permet le recours \*`a des
- priorit\*'es pour les signaux continus: ceci est d'ailleurs n\*'ecessaire afin
- d'\*'eviter toute ambigu\*:it\*'e en cas de pr\*'esence de plusieurs signaux
- continus. La figure\ D\(hy3.8.35 en donne une illustration. Le processus
- commence \*`a l'\*'etat\ S1 et ses variables locales\ X et\ Y ont respectivement
- les valeurs\ 10 et\ 11. Etant donn\*'e que les deux signaux continus sont
- vrais, celui qui a la plus haute
- priorit\*'e (rang de priorit\*'e 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
- .LP
- la priorit\*'e du signal continu de\ X soit inf\*'erieure \*`a celle de\
- Y, la transition qui le suit est ex\*'ecut\*'ee et le processus parvient
- \*`a l'\*'etat\ S3;
- .LP
- 3)
- lorsque la transition d'un signal continu a une suite,
- l'expression SENDER (\o"E\(aa"METTEUR) retourne la m\* | me valeur de
- SELF.
- .bp
- .LP
- .rs
- .sp 27P
- .ad r
- \fBFigure D\(hy3.8.31, p. 21\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 17P
- .ad r
- \fBFigure D\(hy3.8.32, p. 22\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure D\(hy3.8.33, p. 23\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 23P
- .ad r
- \fBFigure D\(hy3.8.34, p. 24\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 23P
- .ad r
- \fBFigure D\(hy3.8.35, p. 25\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.6
- \fISorties\fR
- .sp 9p
- .RT
- .PP
- Une sortie est l'\*'emission d'un signal d'un processus vers un autre ou
- vers lui\(hym\* | me. Etant donn\*'e que le contr\* | le de la r\*'eception
- et de
- l'absorption du signal est associ\*'e au processus de r\*'eception (voir le
- \(sc\ D.3.8.3), les r\*`egles s\*'emantiques se rapportant directement
- aux symboles de sorties sont relativement simples. Du point de vue du processus
- d'\*'emission, une sortie peut souvent \* | tre consid\*'er\*'ee comme
- une action instantan\*'ee qui, une fois achev\*'ee, n'a aucun autre effet
- direct sur le processus d'\*'emission, lequel ne
- sera pas directement conscient du sort du signal.
- .PP
- Une action de sortie repr\*'esente 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 pla\*,cant entre parenth\*`eses
- ou en mettant des
- expressions ayant des valeurs entre parenth\*`eses (voir la figure\ D\(hy3.8.37).
- .PP
- En LDS/PR, une action de sortie est repr\*'esent\*'ee \*`a l'aide du mot\(hycl\*'e
- OUTPUT (sortie) suivi d'une liste d'identificateurs de signaux. Une liste
- de
- param\*`etres r\*'eels mis entre parenth\*`eses peut \* | tre associ\*'ee
- \*`a chaque
- identificateur de signal. S'il n'existe pas en fait de param\*`etre r\*'eel
- dans la sortie correspondant \*`a une sorte dans la d\*'efinition du signal,
- la variable
- correspondante dans l'entr\*'ee de r\*'eception aura la valeur <<ind\*'efinie>>.
- .PP
- L'instance de processus de destination doit \* | tre exprim\*'ee dans
- l'instruction de sortie par le mot\(hycl\*'e\ TO (vers) suivi d'une expression
- d'instance de processus. Si l'instance de processus de destination peut
- \* | tre d\*'etermin\*'ee uniquement par le contexte, la clause\ TO peut
- \* | tre omise. Une
- condition d'adressage suppl\*'ementaire peut \* | tre fournie dans l'\*'enonc\*'e
- de sortie \*`a l'aide du mot\(hycl\*'e\ VIA suivi d'une liste d'acheminement
- de signaux et
- d'identificateurs de canaux.
- .PP
- La figure D\(hy3.8.36 donne quelques exemples valables d'\*'enonc\*'es de
- sortie.
- .bp
- .RT
- .LP
- .rs
- .sp 10P
- .ad r
- \fBFigure D\(hy3.8.36 [T16.100] \ \
- (\*`a traiter comme tableau MEP), p. 26\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- En LDS/GR, une sortie est repr\*'esent\*'ee \*`a l'aide d'un symbole de
- sortie contenant la sp\*'ecification de signaux, de param\*`etres r\*'eels
- et, en
- option, de destination et/ou de construction\ VIA.
- .PP
- Chaque sortie doit \* | tre dirig\*'ee vers une instance de processus
- donn\*'ee. Etant donn\*'e qu'il est g\*'en\*'eralement impossible de conna\* | tre
- l'instance de processus de tout processus au moment de l'\*'elaboration
- d'une sp\*'ecification, la m\*'ethode normale pour diriger les signaux
- consiste \*`a employer une variable ou une expression dans le mot\(hycl\*'e\
- TO (VERS). On trouvera dans les
- figures\ D\(hy3.8.38, D\(hy3.8.39 et D\(hy3.8.40 des exemples. Dans la
- figure\ D\(hy3.8.38,
- le param\*`etre de processus <<out
- \(ulto>> prend la valeur d'une instance de
- processus
- lors de la cr\*'eation du processus. Le r\* | le de <<out
- \(ulto>> au sein du processus est
- d'assurer la liaison entre le processus en question et le processus auquel
- il est connect\*'e. Il convient de veiller lors de la conception du syst\*`eme,
- \*`a ce que le type de processus indiqu\*'e par <<out
- \(ulto>> puisse recevoir les signaux qui sont \*'emis. Dans la figure\
- D\(hy3.8.39, l'expression pr\*'ed\*'efinie SENDER sert \*`a
- renvoyer un signal au processus qui a \*'emis le signal re\*,cu peu avant.
- Dans la figure\ D\(hy3.8.40, le signal est envoy\*'e vers le descendant
- le plus r\*'ecent du
- processus.
- .RT
- .LP
- .rs
- .sp 31P
- .ad r
- \fBFigure D\(hy3.8.37, p. 27\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure D\(hy3.8.38 [T17.100] \ \
- (\*`a traiter comme tableau MEP), p. 28\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 7P
- .ad r
- \fBFigure D\(hy3.8.39, p. 29\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .rs
- .sp 7P
- .ad r
- \fBFigure D\(hy3.8.40, p. 30\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.7
- \fIT\* | che\fR
- .sp 9p
- .RT
- .PP
- Dans une transition, une t\* | che sert \*`a repr\*'esenter \*`a l'aide
- d'un texte informel des op\*'erations sur des variables ou une op\*'eration
- sp\*'eciale.
- .PP
- En LDS/PR, une t\* | che est repr\*'esent\*'ee par le mot\(hycl\*'e TASK
- (T\* | CHE)
- suivi d'une liste d'instructions ou de textes informels s\*'epar\*'es par des
- virgules et se terminant par un point\(hyvirgule. Une instruction d'une
- t\* | che
- peut consister simplement en une affectation. Un texte informel consiste
- en une phrase d\*'elimit\*'ee par des apostrophes. On trouvera dans la
- figure\ D\(hy3.8.41 des exemples de t\* | ches valables en LDS/PR.
- .RT
- .LP
- .rs
- .sp 10P
- .ad r
- \fBFigure D\(hy3.8.41 [T18.100] \ \
- (\*`a traiter comme tableau MEP), p. 31\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- En LDS/GR, une t\* | che se compose d'un symbole de t\* | che contenant
- la liste des instructions ou des textes informels.
- .PP
- Les usagers du LDS peuvent parfois \*'eprouver de la difficult\*'e \*`a
- d\*'ecider si un aspect du syst\*`eme d\*'efini doit \* | tre repr\*'esent\*'e
- par une t\* | che ou un processus distinct. Consid\*'erons l'exemple du
- processus repr\*'esent\*'e dans la
- figure\ D\(hy3.8.42: l'action <<connecter\(hytrajet\(hyde\(hycommutation>>
- doit\(hyelle \* | tre
- repr\*'esent\*'ee par une t\* | che ou par un processus distinct? Si l'on
- n'a pas
- identifi\*'e un processus distinct de commande de trajet de commutation,
- il serait indiqu\*'e d'utiliser le symbole t\* | che [voir la figure\ D\(hy3.8.42\
- a)]. Si on a
- identifi\*'e 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\(hy3.8.42\ b)].
- .RT
- .LP
- .rs
- .sp 26P
- .ad r
- \fBFigure D\(hy3.8.42, p. 32\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.8.8
- \fID\*'ecisions\fR
- .sp 9p
- .RT
- .PP
- Une d\*'ecision 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'ex\*'ecution de l'action; le processus a le choix
- entre deux ou plusieurs trajets, ce choix \*'etant d\*'etermin\*'e par
- la r\*'eponse cons\*'ecutive \*`a la d\*'ecision. Les auteurs des diagrammes
- LDS doivent veiller \*`a ce que les
- processus soient d\*'efinis de mani\*`ere qu'ils ne puissent tenter d'ex\*'ecuter
- des d\*'ecisions pour lesquelles des r\*'eponses (ou les donn\*'ees) ne
- sont pas
- disponibles; de telles d\*'ecisions rendraient le diagramme tout \*`a fait
- incorrect et entra\* | neraient une confusion consid\*'erable.
- .PP
- La question \*`a laquelle correspond une d\*'ecision peut \* | tre une
- expression ou un texte informel. Les r\*'eponses apport\*'ees par une d\*'ecision
- sont repr\*'esent\*'ees 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 r\*'eponses est informelle,
- toute la d\*'ecision est
- informelle. Des r\*'eponses diff\*'erentes sont s\*'epar\*'ees par des
- virgules. Les
- valeurs sont repr\*'esent\*'ees par des expressions constantes, par des
- expressions constantes ayant un op\*'erateur comme pr\*'efixe ou par des
- gammes dont les limites sup\*'erieures et inf\*'erieures sont des expressions
- constantes. Les valeurs de
- r\*'eponse doivent \* | tre du m\* | me type que l'expression contenue dans la
- question.
- .PP
- Il est possible d'indiquer explicitement certaines r\*'eponses et de
- grouper toutes les autres r\*'eponses possibles en employant le mot\(hycl\*'e
- ELSE
- (AUTRE).
- .bp
- .PP
- En LDS/PR, la d\*'ecision est repr\*'esent\*'ee par le mot\(hycl\*'e D\o"E\(aa"CISION
- suivi par la sp\*'ecification de la question et la liste des r\*'eponses
- possibles, chacune \*'etant associ\*'ee \*`a la transition correspondante.
- Les r\*'eponses sont indiqu\*'ees
- entre parenth\*`eses. L'ensemble des transitions sortantes est d\*'elimit\*'e
- par le
- mot\(hycl\*'e ENDDECISION (FIN DE D\o"E\(aa"CISION) plac\*'e \*`a la fin
- (voir la
- figure\ D\(hy3.8.43).
- .RT
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure D\(hy3.8.43 [T19.100] \ \
- (\*`a traiter comme tableau MEP), p. 33\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- On trouvera certains exemples de d\*'ecisions dans la
- figure\ D\(hy3.8.44.
- .LP
- .rs
- .sp 24P
- .ad r
- \fBFigure D\(hy3.8.44 [T20.100] \ \
- (\*`a traiter comme tableau MEP), p. 34\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Toutes les transitions se terminent par le mot\(hycl\*'e ENDECISION (FIN
- DE D\o"E\(aa"CISION). Les d\*'ecisions qui ne se terminent pas par un \*'enonc\*'e
- terminal
- (c'est\(hy\*`a\(hydire jonction, \*'etat suivant, arr\* | t) continuent
- dans l'\*'enonc\*'e qui
- suit le mot ENDECISION, comme indiqu\*'e dans les deux branches \*'equivalentes
- de la figure\ D\(hy3.8.45.
- .bp
- .LP
- .rs
- .sp 19P
- .ad r
- \fBFigure D\(hy3.8.45, p. 35\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- L'instruction de d\*'ecision peut en outre servir \*`a former la
- structure IF\(hyTHEN (SI\(hyALORS), la structure DO\(hyWHILE (FAIRE\(hyPENDANT)
- et la
- structure LOOP\(hyUNTIL (BOUCLE\(hyJUSQU'\o"A\(ga") comme en programmation
- structur\*'ee.
- .PP
- En LDS/GR, une d\*'ecision est repr\*'esent\*'ee \*`a l'aide d'un symbole de
- d\*'ecision contenant le texte de la question. Le symbole doit avoir deux
- branches ou plus associ\*'ees aux r\*'eponses correspondantes. Chaque r\*'eponse
- doit \* | tre
- plac\*'ee \*`a la droite ou au sommet de la branche correspondante ou au\(hydessus
- de la branche qui interrompt la ligne de liaison. En LDS/GR, les parenth\*`eses
- servant \*`a d\*'elimiter les r\*'eponses sont facultatives mais il est
- sugg\*'er\*'e de les utiliser pour \*'eviter tout malentendu.
- .PP
- On trouvera certains exemples de d\*'ecisions en LDS/GR dans la
- figure\ D\(hy3.8.46.
- .RT
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure D\(hy3.8.46, p. 36\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .PP
- Si une r\*'eponse ram\*`ene \*`a la d\*'ecision de la m\* | me transition,
- il convient d'ex\*'ecuter certaines actions qui influencent la question
- ayant trait \*`a la d\*'ecision. Toutefois, m\* | me si cette r\*`egle
- est appliqu\*'ee, des boucles
- infinies peuvent appara\* | tre, comme indiqu\*'e dans la figure\ D\(hy3.8.47.
- Il faut
- donc toujours faire attention lorsque des r\*'eponses se r\*'ef\*`erent
- \*`a une
- d\*'ecision de la m\* | me transition.
- .LP
- .rs
- .sp 15P
- .ad r
- \fBFigure D\(hy3.8.47, p. 37\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- Des d\*'ecisions peuvent \* | tre prises \*`a l'aide de toute valeur
- existant dans le processus et notamment:
- .LP
- \(em
- des valeurs re\*,cues par une entr\*'ee;
- .LP
- \(em
- des valeurs transmises en tant que param\*`etres effectifs au moment
- de la cr\*'eation du processus;
- .LP
- \(em
- des valeurs partag\*'ees.
- .PP
- L'expression qui figure dans la question peut comprendre des
- constantes de l'un quelconque des types de valeurs susmentionn\*'es.
- .sp 1P
- .LP
- D.3.8.9
- \fIBranchements et connecteurs\fR
- .sp 9p
- .RT
- .PP
- Les branchements permettent de transf\*'erer la commande d'un point \*`a
- un autre d'un corps de processus (ainsi qu'\*`a l'int\*'erieur d'un corps
- de
- proc\*'edure ou d'un corps de service).
- .PP
- En LDS/PR, les branchements sont \*'equivalents \*`a des \*'enonc\*'es
- <<GO TO>>. Des \*'etiquettes sont utilis\*'ees comme points d'introduction
- associ\*'es aux
- instructions, comme indiqu\*'e dans la figure\ D\(hy3.8.48. A l'int\*'erieur
- d'un corps de processus (ou d'un corps de proc\*'edure), il est impossible
- de transf\*'erer la commande (et par cons\*'equent les \*'etiquettes associ\*'ees)
- au type instructions
- indiqu\*'e dans la figure\ D\(hy3.8.49. Les \*'etiquettes demeurent toujours
- localis\*'ees dans un processus; il est donc impossible de transf\*'erer
- la commande d'un
- processus \*`a un autre \*`a l'aide d'un branchement.
- .RT
- .LP
- .rs
- .sp 11P
- .ad r
- \fBFigure D\(hy3.8.48, p. 38\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .LP
- .rs
- .sp 9P
- .ad r
- \fBFigure D\(hy3.8.49 [T21.100] \ \
- (\*`a traiter comme tableau MEP), p. 39\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .PP
- En LDS/GR, les branchements correspondent aux connecteurs (de
- sortie et d'entr\*'ee). Elles peuvent \* | tre utilis\*'ees pour subdiviser les
- programmes, en cas de manque de place, ou pour \*'eviter le croisement
- de lignes de liaison qui enl\*`everait de leur clart\*'e aux diagrammes.
- En outre, il est
- g\*'en\*'eralement pr\*'ef\*'erable, lorsque l'on trace un diagramme en
- LDS, que la liaison se dirige du haut au bas de la page.
- .PP
- En GR, toute ligne de liaison peut \* | tre interrompue par une paire de
- connecteurs associ\*'es; on admet alors que la liaison se dirige du connecteur
- de sortie au connecteur d'entr\*'ee. Chaque symbole de connecteur contient
- un nom,
- associ\*'e aux connecteurs portant le m\* | me nom. Il existe un seul connecteur
- d'entr\*'ee pour chaque nom mais il peut y avoir un ou plusieurs connecteurs de
- sortie.
- .PP
- En GR, il est souhaitable que la page de r\*'ef\*'erence se rapportant au
- connecteur d'entr\*'ee appropri\*'e soit sp\*'ecifi\*'ee pour le connecteur
- de sortie et
- que la ou les r\*'ef\*'erences de pages relatives aux connecteurs de sortie
- appropri\*'es devraient \* | tre donn\*'ees pour le connecteur d'entr\*'ee
- (voir l'exemple de la figure\ D\(hy3.8.50).
- .RT
- .LP
- .rs
- .sp 16P
- .ad r
- \fBFigure D\(hy3.8.50, p. 40\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.9
- \fIProc\*'edures\fR
- .sp 9p
- .RT
- .PP
- En LDS, les proc\*'edures sont similaires aux proc\*'edures du CHILL et
- d'autres langages de programmation. Elles visent \*`a:
- .RT
- .LP
- a)
- permettre de structurer un processus en plusieurs niveaux de pr\*'ecision;
- .LP
- b)
- conserver la compacit\*'e des sp\*'ecifications en permettant de repr\*'esenter
- comme un seul \*'el\*'ement un assemblage complexe d'\*'el\*'ements qui
- peuvent \* | tre consid\*'er\*'es isol\*'ement;
- .LP
- c)
- permettre de d\*'efinir et d'utiliser \*`a plusieurs reprises les assemblages
- d'\*'el\*'ements utilis\*'es.
- .PP
- Une d\*'efinition de proc\*'edure ne peut exister que dans une
- d\*'efinition de processus, dans une d\*'efinition de service ou une d\*'efinition
- de
- proc\*'edure et, par cons\*'equent, une proc\*'edure n'est visible que
- pour le processus ou la proc\*'edure dans lesquels elle est d\*'efinie.
- .bp
- .PP
- Une d\*'efinition de proc\*'edure se compose des \*'el\*'ements suivants (dont
- certains sont facultatifs):
- .RT
- .LP
- \(em
- nom de la proc\*'edure;
- .LP
- \(em
- param\*`etres formels de proc\*'edure: liste de noms de variables associ\*'ees
- \*`a leur sorte. Ces param\*`etres servent \*`a transf\*'erer l'information
- de la proc\*'edure ou \*`a partir de celle\(hyci au moment de l'appel.
- Les param\*`etres
- de proc\*'edure peuvent \* | tre pass\*'es par valeur (param\*`etre IN)
- ou par r\*'ef\*'erence (param\*`etre IN/OUT). Si un param\*`etre est pass\*'e
- par valeur, la sp\*'ecification du param\*`etre formel d\*'efinit une variable
- locale \*`a la proc\*'edure; s'il est pass\*'e par r\*'ef\*'erence, la
- sp\*'ecification d\*'efinit un synonyme pour la variable;
- .LP
- \(em
- d\*'efinitions de proc\*'edure: proc\*'edures qui peuvent \* | tre
- appel\*'ees tout comme la proc\*'edure proprement dite;
- .LP
- \(em
- d\*'efinitions de donn\*'ees: sp\*'ecification de types de donn\*'ees
- locales \*`a la proc\*'edure;
- .LP
- \(em
- d\*'efinitions de variables: variables locales \*`a la proc\*'edure;
- .LP
- \(em
- corps de proc\*'edure: sp\*'ecification du comportement effectif de la
- proc\*'edure pour ce qui est des \*'etats et des actions (comme pour le
- corps de processus).
- .PP
- On trouvera dans la figure D\(hy3.9.1 un exemple partiel de
- d\*'efinition de proc\*'edure en LDS/PR (les mots\(hycl\*'es du langage
- sont \*'ecrits en
- majuscules). A noter que les param\*`etres formels sans attribut explicite
- ont un attribut implicite IN (var5 dans la figure).
- .LP
- .rs
- .sp 14P
- .ad r
- \fBFigure D\(hy3.9.1 [T22.100] \ \
- (\*`a traiter comme tableau MEP), p. 41\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .sp 1P
- .LP
- D.3.9.1
- \fICorps de proc\*'edure\fR
- .sp 9p
- .RT
- .PP
- Le corps de proc\*'edure pr\*'esente de grandes similitudes avec le corps
- de processus; toutefois les diff\*'erences sont les suivantes:
- .RT
- .LP
- \(em
- la proc\*'edure termine son interpr\*'etation avec une indication <<retour>>
- au lieu d'une indication <<arr\* | t>>. En LDS/PR, l'\*'enonc\*'e de retour
- est repr\*'esent\*'e par le mot\(hycl\*'e RETURN;
- .LP
- \(em
- en LDS/GR, le symbole de d\*'ebut de proc\*'edure est l\*'eg\*`erement
- diff\*'erent du symbole de d\*'ebut de processus.
- .PP
- Les symboles de d\*'ebut et de retour de proc\*'edure sont indiqu\*'es
- dans le r\*'esum\*'e du LDS/GR.
- .PP
- Une proc\*'edure peut utiliser la construction avec branchements mais
- seulement pour se r\*'ef\*'erer \*`a une \*'etiquette interne. Un branchement
- peut ne pas \* | tre utilis\*'e ou \* | tre utilis\*'e pour acc\*'eder
- \*`a une proc\*'edure de l'ext\*'erieur ou quitter celle\(hyci.
- .PP
- En LDS/GR, une d\*'efinition de proc\*'edure est repr\*'esent\*'ee par un
- diagramme de proc\*'edure tr\*`es similaire au diagramme de processus.
- Le diagramme de proc\*'edure comprend les \*'el\*'ements suivants:
- .RT
- .LP
- \(em
- un symbole de cadre facultatif: symbole de forme
- rectangulaire contenant tous les autres symboles;
- .LP
- \(em
- l'en\(hyt\* | te de proc\*'edure: le mot\(hycl\*'e PROC\o"E\(aa"DURE
- suivi du nom de la proc\*'edure et de la sp\*'ecification des param\*`etres
- formels de proc\*'edure.
- G\*'en\*'eralement, l'en\(hyt\* | te de proc\*'edure est plac\*'e dans
- l'angle sup\*'erieur gauche du cadre ou, s'il n'y a pas de cadre, dans
- l'angle sup\*'erieur gauche du support sur lequel le diagramme est trac\*'e;
- .LP
- \(em
- une num\*'erotation de pages facultatives (\*`a placer dans
- l'angle sup\*'erieur droit);
- .LP
- \(em
- des symboles de texte: dans le cas d'un diagramme de
- proc\*'edure, un symbole de texte peut \* | tre utilis\*'e pour contenir la
- sp\*'ecification de d\*'efinition de param\*`etres formels, de donn\*'ees et de
- variables;
- .LP
- \(em
- r\*'ef\*'erences de proc\*'edure: symboles de proc\*'edure, contenant
- chacun un nom de proc\*'edure repr\*'esentant une proc\*'edure locale d\*'efinie
- s\*'epar\*'ement;
- .bp
- .LP
- \(em
- des diagrammes de proc\*'edure: permettant de d\*'efinir
- directement les proc\*'edures locales;
- .LP
- \(em
- la zone graphique de proc\*'edure: sp\*'ecification du comportement de
- la proc\*'edure pour ce qui est du d\*'ebut, des \*'etats, des entr\*'ees,
- des sorties, des t\* | ches... et des arcs orient\*'es.
- .PP
- Dans la figure D\(hy3.9.2, on trouvera un exemple de d\*'efinition de
- proc\*'edure en LDS/GR. La proc\*'edure portant la r\*'ef\*'erence <<TERM\d\\u(emP>>
- dans
- l'exemple est locale \*`a la proc\*'edure d'appel.
- .PP
- Comme indiqu\*'e dans le cas des diagrammes de proc\*'edure (\(sc\ D.3.8), si
- une seule page ne suffit pas \*`a contenir un diagramme de proc\*'edure,
- celui\(hyci
- peut \* | tre repr\*'esent\*'e sur plusieurs pages, avec r\*'ep\*'etition
- du symbole de cadre \*`a la suite de l'en\(hyt\* | te et du num\*'ero de
- page.
- .RT
- .LP
- .rs
- .sp 47P
- .ad r
- \fBFigure D\(hy3.9.2, p. 42\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .bp
- .sp 1P
- .LP
- D.3.9.2
- \fIAppel de proc\*'edure\fR
- .sp 9p
- .RT
- .PP
- Les appels de proc\*'edure peuvent se produire chaque fois qu'une
- t\* | che et autoris\*'ee dans un graphe de processus ou de proc\*'edure.
- En un sens,
- une proc\*'edure peut \* | tre interpr\*'et\*'ee comme une t\* | che, avec
- les exceptions
- suivantes:
- .RT
- .LP
- 1)
- une proc\*'edure peut contenir des \*'etats et, si tel est le cas, recevoir
- des signaux;
- .LP
- 2)
- une proc\*'edure peut \*'emettre des signaux. L'instance de
- processus d'origine est celle qui a appel\*'e la proc\*'edure.
- .PP
- Lorsqu'une proc\*'edure est appel\*'ee, son environnement est cr\*'e\*'e et
- l'interpr\*'etation de la proc\*'edure commence. Elle se poursuit jusqu'\*`a
- ce que
- l'on ait atteint l'indication RETURN (retour). Pendant l'interpr\*'etation
- de la proc\*'edure, tous les signaux adress\*'es au processus sont soit
- mis en r\*'eserve
- implicitement soit trait\*'es explicitement par la proc\*'edure. La proc\*'edure
- n'a pas sa propre file d'attente mais utilise celle du processus qui l'a
- appel\*'ee.
- .PP
- En LDS/PR, un appel de proc\*'edure est repr\*'esent\*'e par le mot\(hycl\*'e
- CALL
- suivi de l'identificateur de proc\*'edure et de la liste de param\*`etres
- r\*'eels mise entre parenth\*`eses. Si un param\*`etre n'est pas donn\*'e,
- il convient de l'indiquer par deux virgules cons\*'ecutives. Dans ce cas,
- le param\*`etre formel correspondant a la valeur <<ind\*'efinie>>. A noter
- aussi que la d\*'eclaration de IN ou IN/OUT est faite dans la d\*'efinition
- de proc\*'edure, de sorte qu'elle ne doit pas \* | tre
- r\*'ep\*'et\*'ee par l'\*'enonc\*'e d'appel. On trouvera certains exemples
- d'appel en LDS/PR dans la figure\ D\(hy3.9.3.
- .RT
- .LP
- .sp 2
- .rs
- .sp 8P
- .ad r
- \fBFigure D\(hy3.9.3 [T23.100] \ \
- (\*`a traiter comme tableau MEP), p. 43\fR
- .sp 1P
- .RT
- .ad b
- .RT
- .LP
- .sp 3
- .PP
- En LDS/GR, un appel de proc\*'edure est repr\*'esent\*'e \*`a l'aide d'un
- symbole d'appel de proc\*'edure contenant le nom de proc\*'edure et la
- liste des
- param\*`etres r\*'eels mise entre paranth\*`eses. On trouvera un exemple
- d'appel en
- LDS/GR dans la figure\ D\(hy3.9.2.
- .LP
- .rs
- .sp 13P
- .ad r
- Blanc
- .ad b
- .RT
- .LP
- .bp
-