.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