.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
.ce 1000
\v'12P'
\s12FASCICULE\ X.2
\v'4P'
.RT
.ce 0
.sp 1P
.ce 1000
\fBAnnexe\ D\ \*`a\ la\ Recommandation\ Z.100\fR \v'2P'
.ce 0
.sp 1P
.ce 1000
\fBDIRECTIVES\ POUR\ LES\ USAGERS\ DU\ LDS\fR 
.ce 0
.sp 1P
.LP
.rs
.sp 27P
.LP
Blanc
.bp
.LP
\fBMONTAGE:\ \fR PAGE 2 = PAGE BLANCHE
.sp 1P
.RT
.LP
.EF '%	Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D''
.OF '''Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D	%'
.LP
.bp
.sp 1P
.ce 1000
ANNEXE\ D\ \o"A\(ga"\ LA\ RECOMMANDATION\ Z.100
.RT
.sp 2P
.ce 0
.sp 1P
.ce 1000
\fBDIRECTIVES\ POUR\ LES\ USAGERS\ DU\ LDS\fR \v'3P'
.ce 0
.sp 1P
.ce 1000
\fBTABLE\ DES\ MATI\o"E\(ga"RES\fR 
.ce 0
.sp 1P
.ad r
\s8Page
\s9D.1
	Pr\*'eface
/
.sp 1P
.RT
.sp 1P
.RT
.ad b
.RT
.ad r
D.2
	Introduction
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.2.1
	Aper\*,cu g\*'en\*'eral du LDS
/
.ad b
.RT
.ad r
	D.2.1.1
	Le LDS fond\*'e sur un mod\*`ele de machine
\*`a \*'etat finis \*'etendue
/
.ad b
.RT
.ad r
	D.2.2
	Forme syntaxique du LDS
/
.ad b
.RT
.ad r
	D.2.3
	Applicabilit\*'e du LDS
/
.ad b
.RT
.ad r
D.3
	Concepts de base du LDS
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.3.1
	Syst\*`eme
/
.ad b
.RT
.ad r
	D.3.2
	Blocs
/
.ad b
.RT
.ad r
	D.3.3
	Canaux
/
.ad b
.RT
.ad r
	D.3.4
	Signaux
/
.ad b
.RT
.ad r
	D.3.5
	Acheminement des signaux
/
.ad b
.RT
.ad r
	D.3.6
	Diagrammes de syst\*`eme et de bloc
/
.ad b
.RT
.ad r
	D.3.7
	Commentaires et extension de texte
/
.ad b
.RT
.ad r
	D.3.7.1
	Commentaires
/
.ad b
.RT
.ad r
	D.3.7.2
	Extension de texte
/
.ad b
.RT
.ad r
	D.3.8
	Processus
/
.ad b
.RT
.ad r
	D.3.8.1
	Cr\*'eation de processus
/
.ad b
.RT
.ad r
	D.3.8.2
	Etats
/
.ad b
.RT
.ad r
	D.3.8.3
	Entr\*'ees
/
.ad b
.RT
.ad r
	D.3.8.4
	Mises en r\*'eserve
/
.ad b
.RT
.ad r
	D.3.8.5
	Condition de validation et signaux
continus
/
.ad b
.RT
.ad r
	D.3.8.6
	Sorties
/
.ad b
.RT
.ad r
	D.3.8.7
	T\* | ches
/
.ad b
.RT
.ad r
	D.3.8.8
	D\*'ecisions
/
.ad b
.RT
.ad r
	D.3.8.9
	Branchements et connecteurs
/
.ad b
.RT
.ad r
	D.3.9
	Proc\*'edures
/
.ad b
.RT
.ad r
	D.3.9.1
	Corps de proc\*'edure
/
.ad b
.RT
.ad r
	D.3.9.2
	Appel de proc\*'edure
/
.ad b
.RT
.ad r
	D.3.10
	Traitement des donn\*'ees
/
.ad b
.RT
.ad r
	D.3.10.1
	D\*'eclarations variables
/
.ad b
.RT
.ad r
	D.3.10.2
	Variables r\*'ev\*'el\*'ees/vues
/
.ad b
.RT
.ad r
	D.3.10.3
	Variables
export\*'ees/import\*'ees
/
.ad b
.RT
.ad r
	D.3.10.4
	Expressions
/
.ad b
.RT
.ad r
	D.3.11
	Expression du temps en LDS
/
.ad b
.RT
.ad r
	D.3.12
	Utilisation de qualificatifs
/
.ad b
.RT
.ad r
	D.3.13
	Syntaxe de noms
/
.ad b
.RT
.ad r
D.4
	Structuration et affinage des syst\*`emes en LDS
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.4.1
	Consid\*'erations g\*'en\*'erales
/
.ad b
.RT
.ad r
	D.4.2
	Crit\*`eres de subdivision
/
.ad b
.RT
.ad r
	D.4.3
	Subdivision des blocs
/
.ad b
.RT
.ad r
	D.4.4
	Diagramme d'arbre de blocs
/
.ad b
.RT
.ad r
	D.4.5
	Division des canaux
/
.ad b
.RT
.ad r
	D.4.6
	Repr\*'esentation du syst\*`eme en cas de
subdivision
/
.ad b
.RT
.ad r
	D.4.6.1
	Sous\(hyensemble de subdivision
coh\*'erent
/
.ad b
.RT
.ad r
	D.4.7
	Affinage
/
.ad b
.RT
.ad r
	D.4.7.1
	Sous\(hyensemble d'affinage
coh\*'erent
/
.ad b
.RT
.ad r
	D.4.7.2
	Transformation entre signaux et
sous\(hysignaux
/
.ad b
.RT
.ad r
D.5
	Concepts suppl\*'ementaires
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.5.1
	Macros
/
.ad b
.RT
.ad r
	D.5.2
	Syst\*`emes g\*'en\*'eriques
/
.ad b
.RT
.ad r
	D.5.3
	Services
/
.ad b
.RT
.ad r
	D.5.3.1
	Consid\*'erations g\*'en\*'erales
/
.ad b
.RT
.ad r
	D.5.3.2
	Signaux prioritaires
/
.ad b
.RT
.ad r
	D.5.3.3
	Transformation
/
.ad b
.RT
.ad r
	D.5.4
	Directives applicables \*`a la repr\*'esentation en
fonction des \*'etats et aux \*'el\*'ements graphiques
/
.ad b
.RT
.ad r
	D.5.4.1
	Observations d'ordre g\*'en\*'eral sur la
repr\*'esentation en fonction des \*'etats
/
.ad b
.RT
.ad r
	D.5.4.2
	Illustration d'\*'etat et \*'el\*'ements
graphiques
/
.ad b
.RT
.ad r
	D.5.5
	Diagrams auxiliaires
/
.ad b
.RT
.ad r
	D.5.5.1
	Diagramme synoptique d'\*'etat
/
.ad b
.RT
.ad r
	D.5.5.2
	Matrice \*'etat/signal
/
.ad b
.RT
.ad r
	D.5.5.3
	Diagramme de s\*'equencement
/
.ad b
.RT
.ad r
D.6
	D\*'efinition de donn\*'ees en LDS
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.6.1
	Directives applicables aux donn\*'ees en LDS
/
.ad b
.RT
.ad r
	D.6.1.1
	Introduction g\*'en\*'erale
/
.ad b
.RT
.ad r
	D.6.1.2
	Sortes
/
.ad b
.RT
.ad r
	D.6.1.3
	Op\*'erateurs, litt\*'eraux et
termes
/
.ad b
.RT
.ad r
	D.6.1.4
	Equations et axiomes
/
.ad b
.RT
.ad r
	D.6.1.5
	Informations compl\*'ementaires
concernant les \*'equations et les axiomes
/
.ad b
.RT
.ad r
	D.6.2
	G\*'en\*'erateurs et h\*'eritage
/
.ad b
.RT
.ad r
	D.6.2.1
	G\*'en\*'erateurs
/
.ad b
.RT
.ad r
	D.6.2.2
	H\*'eritage
/
.ad b
.RT
.ad r
	D.6.3
	Observations relatives aux \*'equations
/
.ad b
.RT
.ad r
	D.6.3.1
	Consid\*'erations g\*'en\*'erales
/
.ad b
.RT
.ad r
	D.6.3.2
	Application de fonctions aux
constructeurs
/
.ad b
.RT
.ad r
	D.6.3.3
	Sp\*'ecification d'ensemble
d'essai
/
.ad b
.RT
.ad r
	D.6.4
	Caract\*'eristiques
/
.ad b
.RT
.ad r
	D.6.4.1
	Op\*'erateurs cach\*'es
/
.ad b
.RT
.ad r
	D.6.4.2
	Relation d'ordre
/
.ad b
.RT
.ad r
	D.6.4.3
	Sortes avec champs
/
.ad b
.RT
.ad r
	D.6.4.4
	Sortes index\*'ees
/
.ad b
.RT
.ad r
	D.6.4.5
	Valeur par d\*'efaut de
variables
/
.ad b
.RT
.ad r
	D.6.4.6
	Op\*'erateurs actifs
/
.ad b
.RT
.ad r
D.7
	Directives suppl\*'ementaires pour le dessin et
l'\*'ecriture
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.7.1
	Directives pour le LDS/GR
/
.ad b
.RT
.ad r
	D.7.1.1
	Consid\*'erations g\*'en\*'erales
/
.ad b
.RT
.ad r
	D.7.1.2
	Points d'entr\*'ee et de
sortie
/
.ad b
.RT
.ad r
	D.7.1.3
	Symboles
/
.ad b
.RT
.ad r
	D.7.1.4
	Gabarit
/
.ad b
.RT
.ad r
	D.7.2
	Directives applicables au LDS/PR
/
.ad b
.RT
.ad r
D.8
	Documentation
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.8.1
	Introduction
/
.ad b
.RT
.ad r
	D.8.2
	Types de repr\*'esentation de syst\*`emes
/
.ad b
.RT
.ad r
	D.8.3
	Structure de documents
/
.ad b
.RT
.ad r
	D.8.4
	M\*'ecanisme de r\*'ef\*'erence
/
.ad b
.RT
.ad r
	D.8.5
	Classification des documents
/
.ad b
.RT
.ad r
	D.8.6
	Combinaison de LDS/GR et de LDS/PR
/
.ad b
.RT
.ad r
D.9
	Mises en correspondance
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.9.1
	Mise en correspondance du LDS et du CHILL
/
.ad b
.RT
.ad r
	D.9.2
	Mise en correspondance du LDS/GR et du
LDS/PR
/
.ad b
.RT
.ad r
D.10
	Exemples d'application
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.10.1
	Introduction
/
.ad b
.RT
.ad r
	D.10.2
	Le concept de service
/
.ad b
.RT
.ad r
D.11
	Outil pour le LDS
/
.sp 9p
.RT
.ad b
.RT
.ad r
	D.11.1
	Introduction
/
.ad b
.RT
.ad r
	D.11.2
	Cat\*'egories d'outils
/
.ad b
.RT
.ad r
	D.11.3
	Entr\*'ee des documents
/
.ad b
.RT
.ad r
	D.11.4
	V\*'erification des documents
/
.ad b
.RT
.ad r
	D.11.5
	Reproduction des documents
/
.ad b
.RT
.ad r
	D.11.6
	Production des documents
/
.ad b
.RT
.ad r
	D.11.7
	Mod\*'elisation et analyse du syst\*`eme
/
.ad b
.RT
.ad r
	D.11.8
	G\*'en\*'eration de code
/
.ad b
.RT
.ad r
	D.11.9
	Formation
/
.ad b
.RT
.LP
.bp
.LP
D.1
	\fIPr\*'eface\fR 
.sp 1P
.RT
.PP
Le langage de sp\*'ecification et de description du CCITT (LDS) a tout 
d'abord fait l'objet des Recommandations\ Z.101 \*`a\ Z.103 (Tome\ VI.4 
du Livre 
orange,\ 1976) puis, sous une forme d\*'evelopp\*'ee, des Recommandations\ 
Z.101 
\*`a\ Z.104 (Livre jaune,\ 1980) qui ont \*'et\*'e compl\*'et\*'ees et 
regroup\*'ees en\ 1984 dans les Recommandations\ Z.100 \*`a Z.104 (Livre 
rouge). Au cours de la p\*'eriode 
d'\*'etudes 1985\(hy1988, le langage a \*'et\*'e encore d\*'evelopp\*'e 
et harmonis\*'e; les 
Recommandations existantes ont \*'et\*'e fondues en une seule et une d\*'efinition 
math\*'ematique a \*'et\*'e ajout\*'ee.
.PP
Des directives sont indispensables aux utilisateurs pour faciliter
l'utilisation du LDS dans ses applications \*`a une large gamme de syst\*`emes 
de t\*'el\*'ecommunication. Ces directives ont pour but d'aider les utilisateurs 
\*`a 
comprendre la Recommandation concernant le LDS et son application \*`a 
diff\*'erents secteurs. 
.PP
L'emploi du LDS est largement r\*'epandu au sein du CCITT et des
organisations qui en sont membres; en outre, la gamme des applications de ce
langage ne cesse de se d\*'evelopper. Les pr\*'esentes directives sont 
\*'etablies \*`a 
l'intention de ceux qui envisagent d'utiliser ou utilisent d\*'ej\*`a le 
LDS; elles compl\*`etent la Recommandation sur le LDS en y ajoutant des 
conseils judicieux et des exemples utiles. Il y aura certes quelques chevauchements 
entre les 
directives et la Recommandation; cela semble d'ailleurs souhaitable, si
l'on veut que les directives soient autonomes et faciles \*`a consulter. C'est
n\*'eanmoins la Recommandation qui constitue le document de base.
.RT
.sp 2P
.LP
D.2
	\fIIntroduction\fR 
.sp 1P
.RT
.sp 1P
.LP
D.2.1
	\fIAper\*,cu g\*'en\*'eral du LDS\fR 
.sp 9p
.RT
.PP
Le LDS peut servir \*`a sp\*'ecifier le fonctionnement que l'on attend 
d'un syst\*`eme et \*`a d\*'ecrire le fonctionnement effectif d'un syst\*`eme. 
Il a 
\*'et\*'e con\*,cu pour sp\*'ecifier et d\*'ecrire le comportement des
syst\*`emes de commutation qui interviennent dans les t\*'el\*'ecommunications, 
mais 
peut \*'egalement \* | tre utilis\*'e dans une gamme d'applications plus 
large. De fait, le LDS convient particuli\*`erement bien \*`a tous les 
syst\*`emes o\*`u il est 
possible de repr\*'esenter correctement un comportement \*`a l'aide de 
machines \*`a \*'etats finis \*'etendues (\(sc\ D.2.1.1) et o\*`u l'on 
s'int\*'eresse sp\*'ecialement aux 
ph\*'enom\*`enes d'interaction.
.PP
Le LDS peut \*'egalement servir de point de d\*'epart \*`a des m\*'ethodes de
documentation permettant de repr\*'esenter int\*'egralement la sp\*'ecification 
ou la 
description d'un syst\*`eme. Dans ce contexte, la signification de la
sp\*'ecification et de la description est li\*'ee \*`a leur emploi dans 
le cycle de vie d'un syst\*`eme. Chacune d\*'ecrit les propri\*'et\*'es 
fonctionnelles d'un syst\*`eme d'une fa\*,con abstraite. La description 
comprend g\*'en\*'eralement certains aspects li\*'es \*`a la conception 
(par exemple, traitement des erreurs); elle est g\*'en\*'eralement plus 
compl\*`ete en ce qui concerne les d\*'etails fonctionnels. Chacune doit 
concorder avec le mod\*`ele concret du syst\*`eme. Elles servent donc toutes 
deux de 
sp\*'ecifications avant la mise en oeuvre du syst\*`eme, et de documentation
(descriptions) apr\*`es cette m\* | me mise en oeuvre.
.PP
Le LDS peut servir \*`a repr\*'esenter \*`a divers niveaux de d\*'etail les
propri\*'et\*'es fonctionnelles d'un syst\*`eme, d'une fonction ou d'une 
facilit\*'e, 
qu'il s'agisse de leurs sp\*'ecifications ou de leurs descriptions. Les 
propri\*'et\*'es fonctionnelles d\*'esignent certaines propri\*'et\*'es 
structurelles (diagramme 
d'interaction de blocs) ainsi que le comportement. Par <<comportement>>, on
entend la mani\*`ere dont un syst\*`eme r\*'eagit \*`a des signaux re\*,cus 
(entr\*'ees), 
c'est\(hy\*`a\(hydire les actions qu'il ex\*'ecute, par exemple, envoi 
de signaux 
(sorties), formulation de questions (aux fins de d\*'ecision) et ex\*'ecution 
de 
t\* | ches.
.PP
Les sp\*'ecifications peuvent \* | tre tr\*`es g\*'en\*'erales quand une
Administration souhaite \*'etudier les possibilit\*'es de mise \*`a jour 
d'un syst\*`eme en introduisant de nouvelles caract\*'eristiques, de nouveaux 
services, de 
nouvelles techniques,\ etc., tout en laissant au fournisseur la possibilit\*'e
d'offrir de tr\*`es nombreuses solutions pratiques. Des sp\*'ecifications de ce
genre ne donneront g\*'en\*'eralement que peu de d\*'etails. A l'autre 
extr\*'emit\*'e, il y a les sp\*'ecifications par lesquelles une Administration 
demande le remplacement ou l'extension d'un central existant. Dans ce cas, 
les d\*'etails devront 
probablement \* | tre plus pouss\*'es, les sp\*'ecifications des interfaces 
devant \* | tre tr\*`es d\*'etaill\*'ees. 
.PP
Une sp\*'ecification et une description peuvent \* | tre identiques. Il 
est toujours pr\*'ef\*'erable de concevoir les nouvelles r\*'ealisations 
\*`a partir de la 
sp\*'ecification, afin d'en garantir le respect.
.PP
D'une mani\*`ere g\*'en\*'erale, ce sont les fournisseurs qui r\*'edigent les
descriptions pour donner suite \*`a une sp\*'ecification (ou pour d\*'ecrire 
des 
syst\*`emes que le fournisseur veut mettre sur le march\*'e). Une description 
sera g\*'en\*'eralement plus d\*'etaill\*'ee que la sp\*'ecification puisqu'il 
s'agit de rendre 
compte du comportement d\*'etaill\*'e du syst\*`eme.
.PP
Il est \*`a noter \*'egalement que le LDS permet de d\*'ecrire un syst\*`eme 
de mani\*`ere plus ou moins formelle. 
.PP
Premi\*`erement, il est possible de d\*'ecrire un syst\*`eme au moyen de
constructions LDS associ\*'ees au langage naturel. La description ainsi obtenue
permet le transfert de l'information \*`a un lecteur qui conna\* | t le 
contexte, 
mais pas \*`a une machine. Les contr\* | les pouvant \* | tre effectu\*'es 
automatiquement sont tr\*`es limit\*'es. 
.PP
Deuxi\*`emement, il est possible d'associer aux constructions LDS des
\*'enonc\*'es formels constitu\*'es d'\*'el\*'ements de types d\*'efinis 
et d'op\*'erateurs sur ces \*'el\*'ements. Les propri\*'et\*'es de ces 
\*'el\*'ements ne sont pas sp\*'ecifi\*'ees; exemple: 
<<Connecter\ A\(hyB>>, o\*`u\ A et\ B sont du type abonn\*'e et <<Connecter>> 
est une 
op\*'eration autoris\*'ee pour ce type. La sp\*'ecification ainsi obtenue 
permet le 
transfert de l'information aux lecteurs qui connaissent la signification des
op\*'erateurs utilis\*'es. Une machine peut comprendre la description jusqu'\*`a 
un 
certain niveau et peut proc\*'eder \*`a certains contr\* | les; elle ne 
peut pas 
effectuer des contr\* | les complets ni <<mettre en oeuvre>> le syst\*`eme 
car les 
propri\*'et\*'es des op\*'erateurs sont inconnues.
.PP
Troisi\*`emement, il est possible \*'egalement d'indiquer toutes les
propri\*'et\*'es de tous les op\*'erateurs. Dans ce cas, la description 
est enti\*`erement formelle; une machine peut effectuer tous les contr\* | les 
et, en principe, 
mettre en oeuvre les syst\*`emes d\*'ecrits.
.PP
Selon l'objectif vis\*'e, les descriptions peuvent \* | tre adapt\*'ees aux
besoins des usagers au moyen de diff\*'erents niveaux de formalisme.
Naturellement, plus la description est formelle, plus un \* | tre humain 
aura de la difficult\*'e \*`a la lire. 
.PP
Dans le texte qui suit, le terme sp\*'ecification sera utilis\*'e \*`a 
la fois pour la repr\*'esentation n\*'ecessaire et pour celle des comportements 
r\*'eels. 
.RT
.sp 1P
.LP
D.2.2.1
	\fILe LDS fond\*'e sur un \fR \fImod\*`ele de machine \*`a \*'etats finis\fR 
\fI\*'etendue\fR 
.sp 9p
.RT
.PP
En cas d'emploi du LDS, le syst\*`eme \*`a sp\*'ecifier est repr\*'esent\*'e 
par un certain nombre de machines abstraites interconnect\*'ees. Une sp\*'ecification 
compl\*`ete comporte obligatoirement:
.RT
.LP
	1)
	 la d\*'efinition de la structure du syst\*`eme en ce qui concerne les 
machines et leurs interconnexions, 
.LP
	2)
	le comportement dynamique de chaque machine, ses
interactions avec les autres machines et avec l'environnement,
et
.LP
	3)
	les op\*'erations sur les donn\*'ees associ\*'ees aux
interactions.
.PP
On d\*'ecrit le comportement dynamique au moyen de mod\*`eles qui
d\*'efinissent les m\*'ecanismes de fonctionnement des machines abstraites 
ainsi que la communication entre les machines. La machine abstraite qu'emploie 
le LDS est une extension de la machine d\*'eterministe \*`a \*'etats finis 
(FSM). La FSM est 
dot\*'ee d'une m\*'emoire d'\*'etats finis internes et fonctionne avec 
un ensemble 
discret et fini d'entr\*'ees et de sorties. Pour chaque combinaison d'une 
entr\*'ee et d'un \*'etat, la m\*'emoire d\*'efinit une sortie ainsi que 
l'\*'etat suivant. On 
consid\*`ere habituellement que la dur\*'ee de transition entre deux \*'etats 
est 
nulle.
.PP
L'une des limites de la FSM est la suivante: toutes les donn\*'ees \*`a
m\*'emoriser doivent \* | tre repr\*'esent\*'ees sous la forme d'\*'etats 
explicites. Il est possible de repr\*'esenter la plupart des syst\*`emes 
de cette fa\*,con, mais ce n'est pas toujours pratique. On peut \* | tre 
appel\*'e \*`a m\*'emoriser un grand nombre de 
valeurs importantes pour le comportement futur mais qui ne contribuent pas
beaucoup \*`a la compr\*'ehension globale du syst\*`eme. Cette information 
ne doit pas faire partie de l'espace des \*'etats explicites; en effet, 
ceci compliquerait la pr\*'esentation. Il est possible pour ce genre d'applications 
d'\*'etendre la FSM en la dotant d'une m\*'emoire auxiliaire et d'une capacit\*'e 
de fonctionnement 
auxiliaire sur cette m\*'emoire. Cette m\*'emoire auxiliaire peut emmagasiner, 
par 
exemple, des informations concernant des adresses et des num\*'eros d'ordre.
.PP
Les Recommandations relatives au LDS d\*'efinissent deux op\*'erations
auxiliaires qu'il est possible d'inclure dans les transitions de la machine 
\*`a \*'etats finis \*'etendue (EFSM), \*`a savoir les d\*'ecisions et 
les t\* | ches. Les 
<<d\*'ecisions>> v\*'erifient des param\*`etres associ\*'es aux entr\*'ees 
et aux donn\*'ees 
contenues dans la m\*'emoire auxiliaire lorsque ces donn\*'ees sont importantes 
pour le s\*'equencement de la machine principale. Les <<t\* | ches>> ex\*'ecutent 
des fonctions telles que le comptage, des op\*'erations sur la m\*'emoire 
auxiliaire et la 
manipulation de param\*`etres d'entr\*'ee et de sortie.
.PP
En LDS, des signaux repr\*'esentent les interactions entre machines,
c'est\(hy\*`a\(hydire que les EFSM re\*,coivent des signaux comme entr\*'ees 
et produisent des signaux comme sorties. Les signaux se composent d'un 
seul identificateur de signal et facultativement d'un ensemble de param\*`etres. 
Le LDS pr\*'evoit la 
possibilit\*'e d'un temps de transition diff\*'erent de z\*'ero, et d\*'efinit 
un m\*'ecanisme th\*'eorique de mise en file d'attente <<premier entr\*'e, 
premier sorti>> pour les 
signaux qui parviennent \*`a une machine en train d'ex\*'ecuter une transition. 
Les signaux sont trait\*'es \*`a tour de r\* | le, dans leur ordre d'arriv\*'ee. 
.RT
.sp 1P
.LP
D.2.2
	\fIFormes syntaxiques du LDS\fR 
.sp 9p
.RT
.PP
Le LDS est un langage qui se pr\*'esente sous deux formes diff\*'erentes, 
fond\*'ees toutes deux sur le m\* | me mod\*`ele s\*'emantique. L'une est 
appel\*'ee LDS/GR (LDS graphical representation) et repose sur un ensemble 
de symboles graphiques normalis\*'es. L'autre s'appelle LDS/PR (LDS textual 
phrase representation) et 
repose sur des instructions analogues \*`a un langage de programmation. 
L'une et l'autre repr\*'esentent les m\* | mes concepts du LDS. 
.PP
Un langage graphique pr\*'esente l'avantage de montrer clairement la
structure d'un syst\*`eme et de permettre \*`a des \* | tres humains de 
visualiser 
facilement le flux de contr\* | le. La repr\*'esentation textuelle de phrases
convient mieux \*`a l'utilisation par des machines.
.PP
En tant qu'outil de conception, le LDS devrait \* | tre pr\*'esent\*'e 
sous une forme permettant \*`a l'utilisateur d'exprimer ses id\*'ees clairement 
et avec 
concision. Le LDS/GR, qui permet de le faire, correspond davantage \*`a la
repr\*'esentation traditionnelle des machines \*`a \*'etats finis \*'etendues.
.PP
Le LDS/GR est la forme originale du LDS. Il a \*'et\*'e con\*,cu entre 
1973 et 1976 a \*'et\*'e publi\*'e pour la premi\*`ere fois dans la version 
de 1976 des 
Recommandations de la s\*'erie\ Z.100.
.PP
Le LDS/GR a \*'et\*'e \*'etabli sur la base de langages graphiques \*'elabor\*'es 
par diff\*'erentes organisations pour leurs propres utilisations. 
.PP
La repr\*'esentation textuelle de phrases du LDS, c'est\(hy\*`a\(hydire le
LDS/PR, a \*'et\*'e con\*,cu pendant la p\*'eriode d'\*'etudes 1977\(hy1980 
mais il a fallu y 
apporter certaines am\*'eliorations avant qu'elle puisse faire l'objet d'une
Recommandation. Ces am\*'eliorations ont \*'et\*'e faites au cours de la 
p\*'eriode 
d'\*'etudes suivante et, d\*`es 1984, le LDS/PR est devenu l'une des syntaxes
concr\*`etes recommand\*'ees du LDS.
.PP
Dans un premier temps, le LDS/PR devait \* | tre utilis\*'e comme un moyen 
ais\*'e d'introduire des documents en LDS dans une machine, ce qui \*'etait 
trop 
difficile avec le GR (en effet, cela n\*'ecessitait l'intervention d'\*'equipements 
p\*'eriph\*'eriques graphiques). C'est pour cette raison que l'on a insist\*'e 
sur une mise en mati\*`ere de terminaux graphiques (capacit\*'es accrues 
et r\*'eduction des 
co\* | ts) ont fait que le GR est d\*'esormais susceptible d'\* | tre introduit 
en 
machine. Cela ne diminue en rien l'importance et l'utilisation du PR car
certains utilisateurs le trouvent plus \*`a leur convenance, particuli\*`erement 
ceux qui travaillent avec des langages de programmation.
.PP
Du fait de cette \*'evolution, la corr\*'elation entre le GR et le PR est
moins \*'etroite; cependant, il est encore possible de mettre en correspondance
sans difficult\*'e l'une de ces repr\*'esentations avec l'autre, bien que 
chacune 
d'elles ait ses propres particularit\*'es. A premi\*`ere vue, le PR ressemble
fortement \*`a un langage de programmation (voir la figure\ D\(hy2.2.1).
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy2.2.1 [T1.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
En fait, tout d\*'epend de ce qui caract\*'erise un texte du point de
vue du langage de programmation.
.PP
Si nous admettons qu'un programme est d\*'efini comme une <<information
interpr\*'etable par une machine>>, non seulement les PR mais aussi les 
GR sont des <<programmes>>. 
.PP
Il existe cependant certaines diff\*'erences entre une sp\*'ecification 
en LDS et un programme r\*'eel. Tout d'abord, il n'est pas indispensable 
qu'une 
sp\*'ecification en LDS puisse \* | tre ex\*'ecut\*'ee par une machine 
(bien que cela ne 
soit pas interdit); ce qui est essentiel, c'est sa capacit\*'e d'acheminer des
renseignements pr\*'ecis d'un \* | tre humain \*`a un autre \* | tre humain.
.PP
Si nous consid\*'erons une sp\*'ecification en LDS comme un programme, ce
qui peut \* | tre tenu pour une <<sp\*'ecification en LDS erron\*'ee>> 
(en raison d'un 
texte informel incomplet) pourrait \* | tre parfaitement valable si elle 
\*'etait 
consid\*'er\*'ee comme une repr\*'esentation des caract\*'eristiques fonctionnelles 
d'un 
syst\*`eme.
.PP
Une autre diff\*'erence r\*'eside dans le <<style>> d'une sp\*'ecification en
LDS, si on la compare \*`a la repr\*'esentation usuelle d'un programme.
.PP
Le LDS ayant pour but de faciliter la communication entre \* | tres
humains, on s'est efforc\*'e de pr\*'eserver la possibilit\*'e de diff\*'erentes 
pr\*'esentations, afin que la pr\*'esentation en LDS puisse servir \*`a 
orienter le 
lecteur vers certains aspects consid\*'er\*'es comme plus importants que 
d'autres. 
Cela est naturellement sans importance pour un programme, qui est cens\*'e 
\* | tre interpr\*'et\*'e par une machine. La machine n'insiste pas sur 
un quelconque aspect particulier du programme, mais doit traiter de la 
m\* | me mani\*`ere son ensemble; en outre, elle n'essaie pas de <<comprendre>> 
le programme. 
.PP
Etant donn\*'e ses similitudes avec un programme, le PR a la pr\*'ef\*'erence 
de certains programmeurs qui utiliseront probablement aussi le CHILL pour 
la 
mise en oeuvre des besoins. On serait donc probablement tent\*'e de rechercher 
une correspondance point par point entre le PR et le CHILL, afin que les 
besoins 
exprim\*'es en PR puissent \* | tre automatiquement transform\*'es en code 
CHILL. 
L'inverse est \*'egalement int\*'eressant car cela permettrait la d\*'erivation 
d'une 
sp\*'ecification en PR \*`a partir d'un programme en CHILL.
.PP
On trouvera au \(sc D.9 des exemples de possibilit\*'es de mettre en
correspondance le LDS avec le CHILL.
.RT
.sp 1P
.LP
D.2.3
	\fIApplicabilit\*'e du LDS\fR 
.sp 9p
.RT
.PP
La figure D\(hy2.3.1 donne un \*'eventail de possibilit\*'es d'emploi du 
LDS aux fins d'achat ou de founiture de syst\*`emes de commutation pour 
les 
t\*'el\*'ecommunications.
.PP
Dans cette figure, les rectangles repr\*'esentent des groupes
fonctionnels typiques, dont les noms pr\*'ecis, qui peuvent varier d'une
organisation \*`a l'autre, ayant des activit\*'es repr\*'esentatives de 
plusieurs 
Administrations ou de plusieurs fabricants. Chacune des fl\*`eches (lignes de
liaison) repr\*'esente la circulation d'une s\*'erie de documents entre 
un groupe 
fonctionnel et un autre; le LDS peut alors \* | tre employ\*'e en tant 
que partie de chacune de ces s\*'eries de documents. La figure, donn\*'ee 
seulement \*`a titre 
d'illustration, n'est ni d\*'efinitive ni compl\*`ete.
.PP
Les domaines d'application sont ceux effectivement mod\*'elis\*'es par 
des machines \*`a \*'etats finis \*'etendues, communiquant entre elles, 
par exemple: 
commutation t\*'el\*'ephonique t\*'elex ou de donn\*'ees, syst\*`emes de 
signalisation (par exemple, syst\*`eme de signalisation\ n\uo\d\ 7), interfonctionnement 
des syst\*`emes de signalisation, protocoles pour donn\*'ees et interfaces 
d'usagers (LHM). 
.PP
Si l'on consid\*`ere plus sp\*'ecialement les syst\*`emes de commutation 
SPC, on peut citer comme exemple de fonctions pouvant \* | tre sp\*'ecifi\*'ees 
ou d\*'ecrites \*`a l'aide du LDS: le traitement des appels (acheminement, 
signalisation, 
comptage,\ etc.), la maintenance, le traitement des d\*'erangements (par 
exemple, alarmes, rel\*`eve automatique des d\*'erangements, configuration 
des syst\*`emes, 
essais p\*'eriodiques,\ etc.), la commande des syst\*`emes (par exemple, 
protection contre les surcharges), et les interfaces homme\(hymachine. 
Le \(sc\ D.10 donne 
des exemples d'application du LDS.
.PP
La sp\*'ecification des protocoles o\*`u intervient le LDS fait l'objet 
des Recommandations de la s\*'erie\ X du CCITT. 
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy2.3.1, p.\fR 
.ad b
.RT
.sp 2P
.LP
D.3
	\fIConcepts de base du LDS\fR 
.sp 1P
.RT
.sp 1P
.LP
D.3.1
	\fISyst\*`eme\fR 
.sp 9p
.RT
.PP
Comme on a pu le voir plus haut, le LDS repr\*'esente des syst\*`emes \*`a 
l'aide de mod\*`eles. Ainsi ce qui est d\*'efini par une sp\*'ecification 
ou une 
description en LDS constitue le syst\*`eme. Un syst\*`eme LDS peut donc 
repr\*'esenter \*`a l'aide de mod\*`eles une partie d'un syst\*`eme (ou 
d'un central) t\*'el\*'ephonique, ou un r\*'eseau complet de syst\*`emes 
t\*'el\*'ephoniques ou des parties d'un grand 
nombre de centraux t\*'el\*'ephoniques (par exemple, les dispositifs de 
contr\* | le de circuit aux deux extr\*'emit\*'es d'un circuit). Il importe 
de souligner que le 
syst\*`eme LDS contient, d'un point de vue LDS, tout ce que la sp\*'ecification 
ou la description tente de d\*'efinir. L'environnement ne rel\*`eve pas 
de la 
sp\*'ecification et n'est pas d\*'efini en LDS.
.PP
Des canaux relient le syst\*`eme \*`a l'environnement. Th\*'eoriquement, 
il suffit d'un seul canal bidirectionnel pour connecter le syst\*`eme \*`a 
l'environnement. Dans la pratique, on d\*'efinit g\*'en\*'eralement des 
canaux pour 
chaque jonction logique avec l'environnement.
.PP
Chaque syst\*`eme se compose d'un certain nombre de blocs reli\*'es par 
des canaux. Chaque bloc du syst\*`eme est ind\*'ependant de tous les autres. 
Chaque bloc peut contenir un ou plusieurs processus d\*'ecrivant le comportement 
du bloc. 
Seule l'\*'emission de signaux dans les canaux permet la communication 
entre des processus plac\*'es dans deux blocs diff\*'erents. Pour subdiviser 
le syst\*`eme en 
blocs, on peut prendre des crit\*`eres tels que les suivants: d\*'efinir 
des parties d'une dimension facilitant la compr\*'ehension, cr\*'eer une 
correspondance avec la division effective entre le logiciel et le mat\*'eriel, 
suivre les subdivisions 
fonctionnelles naturelles, r\*'eduire au minimum les interactions, etc.
.PP
Pour de grands syst\*`emes LDS, il existe certaines constructions en LDS 
qui permettent de sp\*'ecifier les sous\(hystructures des parties d'un 
syst\*`eme, de sorte qu'en partant d'un aper\*,cu g\*'en\*'eral du syst\*`eme, 
on peut donner toujours plus de d\*'etails. Dans ce cas, on peut dire que 
le syst\*`eme est repr\*'esent\*'e \*`a 
diff\*'erents niveaux de d\*'etail. Ces constructions sont d\*'ecrites 
au \(sc\ D.4. 
.PP
Au premier niveau de pr\*'ecision, la sp\*'ecification en LDS d'un syst\*`eme 
d\*'ecrit la structure du syst\*`eme et comprend les points suivants, expliqu\*'es 
dans les paragraphes qui suivent: 
.RT
.LP
	\(em
	nom du syst\*`eme;
.LP
	\(em
	d\*'efinitions de signaux: sp\*'ecification des types de signaux
\*'echang\*'es entre les blocs du syst\*`eme ou entre les blocs et l'environnement. 
Cela comprend la sp\*'ecification des types de valeurs achemin\*'es par 
les signaux (liste de sortes); 
.LP
	\(em
	d\*'efinitions de listes de signaux: sp\*'ecification des
identificateurs groupant plusieurs signaux et/ou autres listes de signaux. 
De tels identificateurs peuvent servir \*`a \*'economiser de l'espace et 
\*`a donner une sp\*'ecification plus claire; 
.LP
	\(em
	 d\*'efinitions de canaux: sp\*'ecification des canaux reliant les blocs 
du syst\*`eme les uns aux autres et \*`a l'environnement. Une d\*'efinition 
de canal comprend la sp\*'ecification des identificateurs des signaux achemin\*'es 
par ce canal; 
.LP
	\(em
	d\*'efinitions de donn\*'ees: sp\*'ecification de nouveaux types de
syntypes et de g\*'en\*'erateurs d\*'efinis par l'utilisateur et visibles 
dans tous les blocs; 
.LP
	\(em
	 d\*'efinitions de blocs: sp\*'ecification des blocs dans lesquels le 
syst\*`eme est subdivis\*'e; 
.LP
	\(em
	d\*'efinitions de macros: des directives concernant
l'utilisation des macros sont donn\*'ees au \(sc\ D.5.1.
.PP
Selon la Recommandation concernant le LDS, il existe des types de donn\*'ees 
pr\*'ed\*'efinis qui peuvent \* | tre utilis\*'es par chaque syst\*`eme. 
Ils ne 
n\*'ecessitent pas de d\*'efinition et peuvent \* | tre utilis\*'es au 
moyen de leurs noms pr\*'ed\*'efinis, c'est\(hy\*`a\(hydire: INTEGER, REAL, 
CHARACTER, STRING, CHARSTRING, 
BOOLEAN, PID, TIME, DURATION. Les types de donn\*'ees pr\*'ed\*'efinis 
sont visibles \*`a tous les niveaux de la d\*'efinition du syst\*`eme; 
ils peuvent \* | tre consid\*'er\*'es 
comme d\*'efinis implicitement dans une <<biblioth\*`eque>> de syst\*`eme 
accessible en tout point de la sp\*'ecification. 
.PP
Les noms de sorte utilis\*'es dans les d\*'efinitions de signaux au niveau 
de syst\*`eme doivent \* | tre introduits par des d\*'efinitions de type 
partielles 
visibles au niveau du syst\*`eme, c'est\(hy\*`a\(hydire des types de donn\*'ees 
pr\*'ed\*'efinis ou des newtypes d\*'efinis par l'utilisateur ou encore 
des syntypes d\*'efinis \*`a ce niveau. 
.PP
On trouvera des explications compl\*'ementaires sur l'utilisation des
types de donn\*'ees aux \(sc\ D.3.10 et\ D.6.
.PP
Le LDS/PR utilis\*'e pour une d\*'efinition de syst\*`eme consiste en un
ensemble d'instructions se terminant par <<;>> (point\(hyvirgule). La d\*'efinition 
d'une structure de syst\*`eme commence par l'instruction <<SYSTEM nom;>> et se
termine par l'instruction <<ENDSYSTEM nom;>>. Le nom de l'instruction terminale 
est facultatif mais s'il est donn\*'e, il doit \* | tre le m\* | me que 
le nom donn\*'e 
apr\*`es le mot cl\*'e SYSTEM. Il est sugg\*'er\*'e de placer toujours 
le nom dans 
l'instruction terminale, car cela am\*'eliore la lisibilit\*'e du document.
.PP
Le sch\*'ema du LDS/PR d'une d\*'efinition de structure de syst\*`eme est
repr\*'esent\*'e dans la figure\ D\(hy3.1.1.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.1.1 [T2.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
Pour permettre d'obtenir une repr\*'esentation plus claire et plus
simple de la structure du syst\*`eme ou permettre une sp\*'ecification 
descendante de syst\*`eme, le LDS contient un m\*'ecanisme g\*'en\*'eral 
de r\*'ef\*'erence. A ce niveau, le m\*'ecanisme de r\*'ef\*'erence peut 
\* | tre appliqu\*'e aux d\*'efinitions de bloc. Cette 
caract\*'eristique du langage permet \*`a l'utilisateur de sp\*'ecifier 
pr\*'ecis\*'ement le nom de bloc \*`a l'int\*'erieur de la d\*'efinition 
de la structure de syst\*`eme; la 
d\*'efinition de bloc proprement dite peut \* | tre donn\*'ee s\*'epar\*'ement 
(voir la 
figure\ D\(hy3.1.2).
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.1.2 [T3.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
Le m\*'ecanisme de r\*'ef\*'erence est particuli\*`erement utilis\*'e dans le
LDS/GR parce que la plupart des diagrammes doivent tenir sur une seule 
page et que la place manque souvent pour des sp\*'ecifications graphiques 
embo\* | t\*'ees. 
.PP
On trouvera des exemples de LDS/GR pour une d\*'efinition de syst\*`eme 
au \(sc\ D.3.6. 
.RT
.sp 1P
.LP
D.3.2
	\fIBlocs\fR 
.sp 9p
.RT
.PP
Les processus peuvent communiquer entre eux \*`a l'int\*'erieur d'un
bloc, au moyen de signaux, de valeurs partag\*'ees. Ainsi le bloc ne constitue 
pas seulement un m\*'ecanisme pratique pour le regroupement de processus, 
mais encore une limite \*`a la visibilit\*'e des donn\*'ees. C'est pourquoi 
il convient, lors de la d\*'efinition de blocs, de s'assurer du caract\*`ere 
raisonnable et fonctionnel du regroupement de processus au sein d'un bloc. 
Dans la plupart des cas, il est 
utile de fractionner dans un premier temps le syst\*`eme (ou le bloc) en 
unit\*'es fonctionnelles, puis de d\*'efinir les processus \*`a int\*'egrer 
dans le bloc. 
.PP
A l'int\*'erieur d'un bloc, il est possible (\*`a titre d'option) de
d\*'efinir les trajets de communication entre les processus ou enter ceux\(hyci 
et 
l'environnement du bloc (c'est\(hy\*`a\(hydire la fronti\*`ere du bloc). 
Ces trajets de communications sont appel\*'es acheminement de signaux. 
.PP
Pour un syst\*`eme LDS de grandes dimensions, il est possible de d\*'ecrire 
la sous\(hystructure d'un bloc en fonction d'autres blocs et de canaux, 
comme si le bloc \*'etait un syst\*`eme en soi. Ce m\*'ecanisme est expliqu\*'e 
au \(sc\ D.4. 
.PP
La d\*'efinition de la structure d'un bloc peut comporter les points
suivants:
.RT
.LP
	\(em
	nom de bloc;
.LP
	\(em
	d\*'efinitions de signaux: sp\*'ecification des types de signaux
\*'echang\*'es \*`a l'int\*'erieur du bloc. Cela comprend la sp\*'ecification 
des types de 
valeurs achemin\*'es par les signaux (liste de sortes);
.LP
	\(em
	d\*'efinitions de listes de signaux: sp\*'ecifications ou
identificateurs correspondant \*`a des listes de signaux et/ou \*`a d'autres
identificateurs de listes de signaux. Ces identificateurs, groupant plusieurs 
signaux, peuvent \* | tre utilis\*'es pour \*'economiser de l'espace et 
obtenir une 
sp\*'ecification plus claire;
.LP
	\(em
	d\*'efinitions d'acheminement de signaux: sp\*'ecifications des
trajets de communication reliant les processus du bloc les uns aux autres 
et \*`a l'environnement du bloc. Une d\*'efinition d'acheminement de signaux 
comprend la sp\*'ecification des identificateurs de signaux transport\*'es 
sur cet acheminement de signaux; 
.LP
	\(em
	 connexions de canaux vers des acheminements: sp\*'ecifications des connexions 
entre les canaux ext\*'erieurs au bloc et les acheminements de 
signaux internes du bloc;
.LP
	\(em
	d\*'efinitions de processus: sp\*'ecification des types de
processus d\*'ecrivant le comportement du bloc. Si le bloc n'est pas d\*'ecrit 
en 
fonction de sa sous\(hystructure, il faut qu'il y ait au moins une d\*'efinition 
de type de processus \*`a l'int\*'erieur du bloc. Pour la d\*'efinition 
du processus, un m\*'ecanisme de r\*'ef\*'erence est fourni comme cela 
est indiqu\*'e, dans le cas des 
blocs, au \(sc\ D.3.1;
.LP
	\(em
	d\*'efinitions des donn\*'ees: sp\*'ecification de newtypes, de
syntypes et de g\*'en\*'erateurrs d\*'efinis par l'usager et visibles dans 
tous les 
processus d\*'efinis du bloc et/ou dans la structure\(hystructure du bloc;
.LP
	\(em
	 d\*'efinitions de macros: des directives pour l'utilisation de macros 
sont donn\*'ees au \(sc\ D.5.1. 
.PP
S'il existe une sous\(hystructure \*`a l'int\*'erieur du bloc, certains
des points ci\(hydessus sont facultatifs (voir le \(sc\ D.4 pour les explications 
concernant la structure).
.PP
Les types suivants sont visibles dans un bloc:
.RT
.LP
	\(em
	des types de donn\*'ees pr\*'ed\*'efinis;
.LP
	\(em
	des types de donn\*'ees d\*'efinis par l'usager, d\*'efinis dans le
bloc proprement dit;
.LP
	\(em
	des types de donn\*'ees d\*'efinis par l'usager visibles dans le
bloc ascendant (en cas de subdivision des blocs).
.PP
Dans le LDS/PR, les mots cl\*'e BLOCK et ENDBLOCK servent \*`a
circonscrire une d\*'efinition de bloc. On trouvera des exemples du LDS/GR pour
une d\*'efinition de bloc au \(sc\ D.3.6.
.sp 1P
.LP
D.3.3
	\fICanaux\fR 
.sp 9p
.RT
.PP
Les canaux sont les moyens de communication entre diff\*'erents blocs du 
syst\*`eme ou entre des blocs et leur environnement. Un canal peut relier 
un bloc \*`a un autre ou un bloc \*`a l'environnement dans une direction 
(canal 
unidirectionnel) ou dans les deux directions (canal bidirectionnel).
Normalement, un canal est une entit\*'e fonctionnelle qui peut \* | tre 
utilis\*'ee pour d\*'esigner des chemins de communication sp\*'ecifiques. 
En fait, par la subdivision des canaux (d\*'ecrite au \(sc\ D.4.5), il 
est possible de sp\*'ecifier formellement le comportement de chaque canal. 
.PP
Pour chaque direction indiqu\*'ee ou chaque chemin de communication, la 
sp\*'ecification du canal contient une liste de tous les identificateurs 
de 
signaux que le canal peut acheminer dans cette direction. Cette liste de
signaux offre le moyen de garantir que chaque signal envoy\*'e par un processus 
\*`a une extr\*'emit\*'e du canal puisse \* | tre re\*,cu par le processus 
du bloc qui se 
trouve \*`a l'autre extr\*'emit\*'e du canal. Ainsi, la sp\*'ecification 
de canal devient partie int\*'egrante de la sp\*'ecification d'interface 
pour chaque bloc. Dans de 
grands projets int\*'eressant de nombreuses personnes, un accord d\*`es 
l'origine 
sur les signaux d'un canal et sur la sp\*'ecification de ces signaux r\*'eduit
sensiblement la probabilit\*'e que deux processus ne pourront communiquer l'un
avec l'autre comme pr\*'evu.
.PP
La d\*'efinition d'un canal comporte les \*'el\*'ements suivants:
.RT
.LP
	\(em
	nom du canal;
.LP
	\(em
	un ou deux chemins de communication: un chemin de
communication sp\*'ecifie l'origine et la destination d'une liste de signaux. 
Des identificateurs de bloc ou le mot cl\*'e <<ENV>> (environnement) peuvent 
\* | tre 
utilis\*'es dans ce contexte;
.LP
	\(em
	une ou deux listes de signaux: une liste des signaux
transport\*'es dans cette direction doit \* | tre sp\*'ecifi\*'ee pour 
chaque chemin de 
communication. Cette liste peut comporter des identificateurs de signaux 
ainsi que des identificateurs d'autres listes; 
.LP
	\(em
	 une d\*'efinition facultative de sous\(hystructure de canal (ou une r\*'ef\*'erence 
\*`a une telle d\*'efinition): voir le \(sc\ D.4.5. 
.PP
Dans le LDS/PR, une d\*'efinition de canal est comprise entre les
deux mots cl\*'es CHANNEL et ENDCHANNEL. Les mots cl\*'es FROM et TO servent 
\*`a 
d\*'esigner les chemins de communication et le mot cl\*'e WITH les listes 
de signaux. On trouvera dans la figure\ D\(hy3.3.1 un exemple de d\*'efinition 
de canal en 
LDS/PR.
.PP
Dans le LDS/GR, une d\*'efinition de canal est repr\*'esent\*'ee \*`a l'aide
d'une ligne reliant les deux parties mises en jeu dans la communication. Le
nom du canal doit \* | tre plus proche de la ligne que tout autre symbole. Les
trajets sont repr\*'esent\*'es au moyen de fl\*`eches et les listes de 
signaux doivent \* | tre plac\*'es entre crochets, comme indiqu\*'e dans 
les exemples de la 
figure\ D\(hy3.3.2. Pour \*'eviter une confusion entre les canaux et les 
acheminements de signaux, les fl\*`eches ne doivent pas \* | tre plac\*'ees 
en l'un des deux points terminaux de la ligne (voir le \(sc\ D.3.5). 
.PP
Dans un canal bidirectionnel, chacune des deux listes de signaux doit \* | tre 
aussi proche que possible de la fl\*`eche correspondante. 
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.3.1 [T4.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.3.2, p.\fR 
.ad b
.RT
.sp 1P
.LP
D.3.4
	\fISignaux\fR 
.sp 9p
.RT
.PP
Les signaux peuvent \* | tre d\*'efinis au niveau du syst\*`eme, au niveau 
du bloc ou dans la partie interne de la d\*'efinition de processus. Les 
signaux 
d\*'efinis \*`a un certain niveau peuvent \* | tre utilis\*'es \*`a ce 
niveau ou \*'egalement aux niveaux inf\*'erieurs; cependant, pour simplifier 
chaque niveau, il est 
sugg\*'er\*'e de d\*'efinir les signaux de mani\*`ere aussi circonscrite 
que possible. Les signaux d\*'efinis dans le cadre d'une d\*'efinition 
de processus peuvent \* | tre 
\*'echang\*'es entre des instances de m\* | me type de processus (\(sc\ 
D.3.8) ou entre 
services d'un processus (\(sc\ D.5.3).
.PP
La d\*'efinition d'un signal comprend les points suivants:
.RT
.LP
	\(em
	nom du signal;
.LP
	\(em
	 liste de sortes (facultative): repr\*'esente la liste des types de valeurs 
achemin\*'ees par ce signal; 
.LP
	\(em
	affinage du signal (facultatif): voir le \(sc D.4.7.
.PP
En LDS/PR, une d\*'efinition de signal est sp\*'ecifi\*'ee par le mot cl\*'e 
SIGNAL. Plusieurs signaux (n'ayant pas fait l'objet d'un affinage) peuvent 
\* | tre d\*'efinis \*`a l'int\*'erieur de la construction, donnant ainsi 
le nom du signal et la liste de types. Des exemples de d\*'efinitions de 
signaux en LDS/PR sont 
donn\*'es dans la figure\ D\(hy3.4.1.
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.4.1 [T5.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
En LDS/GR, on sp\*'ecifie une d\*'efinition de signal en ins\*'erant des
\*'enonc\*'es lin\*'eaires dans un symbole de texte comme indiqu\*'e dans la
figure\ D\(hy3.4.2.
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.4.2, p.\fR 
.ad b
.RT
.sp 1P
.LP
D.3.5
	\fIAcheminements de signaux\fR 
.sp 9p
.RT
.PP
Des acheminements de signaux servent \*`a repr\*'esenter des chemins de 
communication similaires aux canaux. Ils peuvent \* | tre utilis\*'es au 
niveau des blocs et \*`a celui des processus. Comme les canaux, les acheminements 
de signaux peuvent \* | tre unidirectionnels ou bidirectionnels mais ils 
ne peuvent \* | tre 
subdivis\*'es.
.PP
Au niveau des blocs, ils repr\*'esentent un moyen de communication entre 
les processus d'un bloc ou entre les processus et l'environnement de ce 
bloc, c'est\(hy\*`a\(hydire un canal menant \*`a ce bloc ou venant de celui\(hyci. 
.PP
Au niveau du processus, les acheminements de signaux peuvent \* | tre
utilis\*'es lorsque le processus est subdivis\*'e en services (voir le 
\(sc\ D.5.3). Dans ce cas, ils relient les services les uns aux autres 
ou avec les acheminements de signaux du processus. 
.PP
Si un signal est remis \*`a un acheminement de signaux aboutissant \*`a
une fronti\*`ere de bloc, il passe dans le canal reli\*'e \*`a l'acheminement 
de 
signaux. Lorsqu'un signal parvient au bloc, \*`a partir d'un canal reli\*'e 
\*`a un ou plusieurs acheminements de signaux, ce signal est plac\*'e dans 
l'acheminement de signaux qui est capable de la transf\*'erer. 
.PP
En LDS/PR, la d\*'efinition d'un acheminement de signal commence par le 
mot cl\*'e SIGNALROUTE. La syntaxe des chemins de communication et la liste 
des 
signaux sont les m\* | mes que dans le cas des canaux.
.PP
En LDS/GR, la seule diff\*'erence entre un acheminement de signaux et un 
canal est que, pour les acheminements de signaux, des fl\*`eches doivent 
\* | tre 
plac\*'ees aux points terminaux des lignes; pr\*`es de chaque fl\*`eche, 
doit se 
trouver une liste de signaux appropri\*'es. On trouvera des exemples
d'acheminements de signaux dans les figures\ D\(hy3.6.3 et\ D\(hy3.6.5 
des paragraphes qui suivent. 
.RT
.sp 1P
.LP
D.3.6
	\fIDiagrammes de syst\*`eme et de bloc\fR 
.sp 9p
.RT
.PP
En LDS/GR, une d\*'efinition de syst\*`eme est repr\*'esent\*'ee au moyen 
d'un ensemble de diagrammes. La structure d'un syst\*`eme en canaux et 
en blocs, est repr\*'esent\*'ee \*`a l'aide d'un diagramme de syst\*`eme. 
.PP
Le diagramme de syst\*`eme se compose des \*'el\*'ements suivants:
.RT
.LP
	\(em
	 le symbole de cadre: symbole de forme rectangulaire contenant tous les 
autres symboles. Il repr\*'esente la fronti\*`ere du syst\*`eme; 
l'environnement du syst\*`eme se trouve en dehors de ce cadre;
.LP
	\(em
	l'en\(hyt\* | te du syst\*`eme: mot cl\*'e SYSTEM suivi du nom du
syst\*`eme (plac\*'e dans l'angle sup\*'erieur gauche);
.LP
	\(em
	une num\*'erotation de page facultative (plac\*'ee dans l'angle
sup\*'erieur droit du cadre);
.LP
	\(em
	des symboles de texte: un tel symbole peut contenir des
\*'enonc\*'es lin\*'eaires. Il sert g\*'en\*'eralement \*`a pr\*'esenter 
dans le diagramme des 
d\*'efinitions de signaux, des listes de signaux et les donn\*'ees;
.LP
	\(em
	 la zone d'interaction de blocs qui comprend la sp\*'ecification des blocs 
du syst\*`eme, les canaux et les listes de signaux achemin\*'es par les 
canaux;
.LP
	\(em
	des diagrammes de macros: les directives concernant
l'utilisation des macros sont donn\*'ees au \(sc\ D.5.1.
.PP
Dans le diagramme de syst\*`eme, la sp\*'ecification d'un bloc peut
\* | tre l'un des deux points suivants:
.LP
	\(em
	 une r\*'ef\*'erence de bloc: symbole de bloc contenant uniquement le 
nom de bloc; 
.LP
	\(em
	 un diagramme de bloc: cadre contenant la sp\*'ecification de la structure 
de bloc en fonction de ses processus et interactions. Si un bloc est subdivis\*'e 
en sous\(hyblocs, la sp\*'ecification de la sous\(hystructure ou la r\*'ef\*'erence 
\*`a celle\(hyci doit \* | tre plac\*'ee \*`a l'int\*'erieur du cadre de 
bloc (\(sc\ D.4.3). 
.PP
On trouvera dans le r\*'esum\*'e concernant le LDS/GR la forme des
symboles utilis\*'es dans le syst\*`eme et celle des diagrammes de bloc. 
En ce qui concerne les d\*'efinitions de symboles, il convient de se r\*'ef\*'erer 
au \(sc\ D.7.1.4. 
.PP
La figure D\(hy3.6.1 donne un exemple d'un diagramme de syst\*`eme pour 
le syst\*`eme <<s>>. Dans cet exemple, le syst\*`eme s'est divis\*'e en 
deux blocs B1 et B2 reli\*'es l'un \*`a l'autre et \*`a l'environnement 
par les canaux C1, C2, C3 et\ C4. Pour les blocs\ B1 et\ B2, on ne donne 
dans cet exemple qu'une r\*'ef\*'erence. Des 
explications compl\*'ementaires sur les canaux et les symboles de listes de
signaux sont donn\*'es dans les paragraphes qui suivent:
.PP
Le m\* | me exemple en LDS/PR est repr\*'esent\*'e dans la figure D\(hy3.6.2.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.6.1, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.6.2 [T6.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
La structure d'un bloc en ce qui concerne les processus et les
acheminements de signaux est repr\*'esent\*'ee en LDS/GR \*`a l'aide d'un 
diagramme de bloc. 
.PP
Le diagramme de bloc se compose des \*'el\*'ements suivants:
.RT
.LP
	\(em
	le symbole cadre: symbole de forme rectangulaire contenant
tous les autres symboles. Il repr\*'esente les fronti\*`eres du bloc: au\(hydel\*`a 
du 
cadre commence l'environnement du bloc;
.LP
	\(em
	l'en\(hyt\* | te du bloc: le mot cl\*'e BLOCK suivi du nom de bloc
(plac\*'e dans l'angle sup\*'erieur gauche du cadre);
.LP
	\(em
	une num\*'erotation de page facultative (plac\*'ee dans l'angle
sup\*'erieur droit du cadre);
.LP
	\(em
	des symboles de texte: ces symboles peuvent englober des
\*'enonc\*'es lin\*'eaires. Ils sont g\*'en\*'eralement utilis\*'es pour 
pr\*'esenter les 
d\*'efinitions de signaux, de listes de signaux et de donn\*'ees;
.LP
	\(em
	la zone d'interaction de processus: cette zone comprend la
sp\*'ecification des processus du bloc et \*'eventuellement des acheminements 
de 
signaux et des listes de signaux transport\*'es par les acheminements de 
signaux. Dans cette zone, il est \*'egalement possible de repr\*'esenter 
les processus qui 
cr\*'eent d'autres processus; cette caract\*'eristique est d\*'ecrite au 
\(sc\ D.3.8.1; 
.LP
	\(em
	des identificateurs de canaux: si le diagramme fait
appara\* | tre des acheminements de signaux aboutissant \*`a l'environnement 
du bloc ou venant de celui\(hyci, les identificateurs des canaux reli\*'es 
\*`a ces 
acheminements de signaux doivent \* | tre sp\*'ecifi\*'es en dehors du 
cadre, de fa\*,con correspondante aux lignes des acheminements de signaux; 
.LP
	\(em
	des diagrammes de macros: on trouvera au \(sc\ D.5.1 des
directives sur l'utilisation des macros.
.PP
Dans le diagramme de bloc, la sp\*'ecification d'un processus peut
\* | tre:
.LP
	\(em
	soit une r\*'ef\*'erence \*`a un processus: symbole de processus
contenant le nom de processus et, en option, la sp\*'ecification d'instances de
processus. Une telle sp\*'ecification comprend deux couples de nombres entiers
s\*'epar\*'es par une virgule et plac\*'es entre parenth\*`eses (voir le 
\(sc\ D.3.8); 
.LP
	\(em
	 soit un diagramme de processus: cadre contenant un graphique de symboles 
reli\*'es d\*'ecrivant le comportement du processus en ce qui concerne 
les \*'etats, les entr\*'ees, les sorties, les actions, etc. (voir le \(sc\ 
D.3.8). Si le processus est subdivis\*'e en services, le diagramme de processus 
contient la zone d'interaction de service (\(sc\ D.5.3). 
.PP
Dans la figure D\(hy3.6.3, on trouvera un exemple de diagramme de
bloc pour le bloc <<B1>> pr\*'esent\*'e dans l'exemple de la figure\ D\(hy3.6.1. 
Ce bloc\ B1 est d\*'ecrit du point de vue des deux processus\ P1 et\ P2, 
reli\*'es par les 
acheminements de signaux R1, R2, R3, R4 et\ R5. Pour les processus\ P1 
et\ P2, on se borne \*`a donner des r\*'ef\*'erences dans cet exemple. 
Les identificateurs de 
canaux\ C1, C2 et\ C3 sont \*'egalement sp\*'ecifi\*'es en dehors du cadre.
.PP
Le m\* | me exemple est pr\*'esent\*'e en LDS/PR dans la figure D\(hy3.6.4.
.PP
Comme cela a d\*'ej\*`a \*'et\*'e indiqu\*'e pr\*'ec\*'edemment, des diagrammes 
de bloc 
peuvent \* | tre compris dans les diagrammes de syst\*`eme, en lieu et place de
r\*'ef\*'erences. Dans la figure\ D\(hy3.6.5 par exemple, les diagrammes des
figures\ D\(hy3.6.1 et\ D\(hy3.6.3 sont r\*'eunis en un seul diagramme 
de syst\*`eme. 
.PP
Une recommandation g\*'en\*'erale concernant l'\*'etablissement de diagrammes 
de ce genre, est qu'ils ne doivent pas \* | tre trop complexes afin de 
rester 
lisibles et qu'ils doivent tenir sur une seule page.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.6.3, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.6.4 [T7.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.6.5, p.\fR 
.ad b
.RT
.sp 2P
.LP
D.3.7
	\fICommentaires\fR 
\fIet extension de texte\fR 
.sp 1P
.RT
.sp 1P
.LP
D.3.7.1
	\fICommentaires\fR 
.sp 9p
.RT
.PP
Il est possible d'ajouter des commentaires \*`a une sp\*'ecification en 
LDS pour aider le lecteur et pr\*'eciser certains points. Deux types de 
commentaires adapt\*'es au LDS/PR et au LDS/GR ont \*'et\*'e introduits 
dans le LDS. 
.PP
Le premier type, appel\*'e <<note>> et utilis\*'e particuli\*`erement en 
LDS/PR. Il est d\*'elimit\*'e par <</*>> au d\*'ebut et par <<*/>> \*`ala 
fin. 
.PP
En LDS/PR, un tel commentaire peut s'ins\*'erer partout o\*`u se trouve 
un espace. Il ne doit pas contenir la s\*'equence sp\*'eciale <<*/>>. 
.PP
En LDS/GR, un tel commentaire peut se pr\*'esenter partout o\*`u il existe 
un espace \*`a l'int\*'erieur des instructions lin\*'eaires. 
.PP
On trouvera dans les figures D\(hy3.7.1 et D\(hy3.7.2 certains exemples 
de cette forme de commentaire, respectivement en LDS/PR et en LDS/GR. 
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.7.1 [T8.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.7.2, p.\fR 
.ad b
.RT
.PP
La seconde forme de commentaire permet une mise en correspondance \*'el\*'ement 
par \*'el\*'ement entre le LDS/PR et le LDS/GR; elle convient mieux aux 
applications comportant des traductions automatiques.
.PP
En LDS/PR, un tel commentaire se compose du mot cl\*'e COMMENT suivi
d'une cha\* | ne de caract\*`eres; il peut e\*^tre ins\*'er\*'e comme 
une instruction 
(c'est\(hy\*`a\(hydire suivi de <<;>>) partout o\*`u une instruction de 
t\* | che peut \* | tre ins\*'er\*'ee. De plus, il peut \* | tre ins\*'er\*'e 
avant le symbole <<;>>\ (;) \*`a la fin de 
toute instruction.
.PP
En LDS/GR, cette forme de commentaire est repr\*'esent\*'ee \*`a l'aide 
d'un symbole de commentaire contenant le texte du commentaire. Le symbole 
de 
commentaire est un symbole de forme rectangulaires auquel le c\* | t\*'e 
gauche ou 
droit fait d\*'efait. Ce symoble doit \* | tre \*'etendu aussi bien horizontalement 
que verticalement, de mani\*`ere \*`a contenir tout le texte. Il peut \* | tre 
reli\*'e \*`a un symbole quelconque en LDS/GR ou \*`a une ligne de liaison. 
Pour indiquer la 
connexion il faut employer une ligne en traits discontinus. Si l'association
entre le texte du commmentaire et le symbole du commentaire ne pr\*'esente pas
d'ambigu\*:it\*'e, le symbole de commentaire peut se pr\*'esenter simplement 
sous la 
forme de crochets.
.PP
Dans les figures D\(hy3.7.3 et D\(hy3.7.4, on trouvera certains exemples 
de cette forme de commentaire, respectivement en LDS/PR et en LDS/GR. 
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.7.3 [T9.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.7.4, p.\fR 
.ad b
.RT
.sp 1P
.LP
D.3.7.2
	\fIExtension de texte\fR 
.sp 9p
.RT
.PP
Normalement, le texte associ\*'e \*`a un symbole graphique devrait \* | tre 
plac\*'e \*`a l'int\*'erieur de ce symbole. Cependant, cela n'est pas toujours 
possible ou pratique. Une autre solution consiste \*`a placer le texte 
dans un symbole 
d'extension de texte rattach\*'e au symbole associ\*'e. Le symbole d'extension 
de 
texte est similaire au symbole de commentaire; la seule diff\*'erence est 
que la ligne le reliant est en trait continu et non en trait discontinu 
(voir la 
figure\ D\(hy3.7.5).
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.7.5, p.\fR 
.ad b
.RT
.PP
Un caract\*`ere de soulignement (<<
\(ul>> peut \* | tre utilis\*'e \*`a la fin d'une ligne de texte comme 
caract\*`ere de continuation. Dans ce cas, les 
espaces restant sur la m\* | me ligne ne sont pas consid\*'er\*'es comme 
faisant 
partie du texte. On trouvera au \(sc\ D.3.13 des directives plus d\*'etaill\*'ees 
sur 
la syntaxe des noms.
.sp 1P
.LP
\fI\fR D.3.8
	\fIProcessus\fR 
.sp 9p
.RT
.PP
Un processus est une machine \*`a \*'etats finis \*'etendue qui d\*'efinit 
le comportement dynamique d'un syst\*`eme. Les processus sont fonci\*`erement 
dans un \*'etat d'attente des signaux. A la r\*'eception d'un signal, le 
processus r\*'epond en accomplissant les actions pr\*'ecises qui correspondent 
\*`a chaque type de signal pouvant \* | tre re\*,cu par le processus. Les 
processus contiennent de nombreux 
\*'etats qui leur permettent d'accomplir diff\*'erentes actions en cas 
de r\*'eception d'un signal. Ces \*'etats m\*'emorisent les actions pr\*'ec\*'edemment 
accomplies. Apr\*`es l'accomplissement de toutes les actions li\*'ees \*`a 
la r\*'eception d'un signal 
donn\*'e, un nouvel \*'etat est atteint et le processus se met en attente 
d'un autre signal. 
.PP
Les processus peuvent soit exister au moment de la cr\*'eation du
syst\*`eme, soit \* | tre cr\*'e\*'es suite \*`a une demande de cr\*'eation 
\*'emise par un autre processus. En outre, les processus peuvent durer 
ind\*'efiniment ou s'arr\* | ter du fait du d\*'eclenchement d'une action 
d'arr\* | t. 
.PP
Une d\*'efinition de processus repr\*'esente la sp\*'ecification d'un type 
de processus; plusieurs instances du m\* | me type de processus peuvent 
\* | tre cr\*'e\*'ees et exister simultan\*'ement; elles peuvent fonctionner 
ind\*'ependamment et 
concurremment. Une d\*'efinition de processus comprend les points suivants 
(dont certains sont facultatifs): 
.RT
.LP
	\(em
	nom de processus;
.LP
	\(em
	une paire de nombre entiers. Le premier de ces nombres
entiers sp\*'ecifie le nombre d'instances de processus cr\*'e\*'ees lors
de la cr\*'eation du syst\*`eme; s'il est omis, il a une valeur par
d\*'efaut de\ 1: le second entier sp\*'ecifie le nombre maximal
d'instances de processus simultan\*'ees; s'il est omis, la valeur
par d\*'efaut maximale est illimit\*'ee;
.LP
	\(em
	param\*`etres formels: liste d'identificateurs de variables
associ\*'es \*`a leurs types qui est utilis\*'ee pour transmettre
l'information au processus au moment de la cr\*'eation. Dans la
demande de cr\*'eation de processus, une liste de param\*`etres r\*'eels
peut \* | tre donn\*'ee \*`a cet effet. Les valeurs des param\*`etres
formels de processus cr\*'e\*'es au moment de la cr\*'eation du syst\*`eme
sont ind\*'efinies;
.LP
	\(em
	ensemble de signaux d'entr\*'ee valides: liste d'identificateurs
de signaux d\*'efinissant les signaux que le processus peut
recevoir;
.LP
	\(em
	d\*'efinitions de signaux: sp\*'ecification des signaux qui peuvent
\* | tre \*'echang\*'es entre instances du m\* | me processus ou entre
services de ce processus (\(sc\ D.5.3);
.LP
	\(em
	d\*'efinitions de proc\*'edures: sp\*'ecification des proc\*'edures qui
peuvent \* | tre appel\*'ees par le processus. Une r\*'ef\*'erence de
proc\*'edure peut \* | tre utilis\*'ee dans ce contexte (les proc\*'edures
font l'objet du \(sc\ D.3.9);
.LP
	\(em
	d\*'efinition de donn\*'ees: sp\*'ecifications des nouveaux types,
syntypes et g\*'en\*'erateurs d\*'efinis par l'usager et localis\*'es dans le
processus;
.LP
	\(em
	d\*'efinition de variables: d\*'eclarations des variables du
processus. A titre facultatif, on peut indiquer qu'une variable
peut \* | tre partag\*'ee avec plusieurs autres processus du m\* | me bloc
(variable  REVEALED) ou export\*'ee vers d'autres processus ainsi
que vers d'autres blocs (variable EXPORTED). Pour chaque variable
d\*'eclar\*'ee, il faut sp\*'ecifier l'identificateur de sa sorte. Une
variable initiale peut facultativement \* | tre sp\*'ecifi\*'ee;
.LP
	\(em
	d\*'efinitions de visibilit\*'e: d\*'eclarations d'identificateurs de
variable qui peuvent servir \*`a l'obtention des valeurs de
variables appartenant \*`a d'autres instances de processus. Pour
chaque identificateur de variable, la sorte de variable doit
\* | tre sp\*'ecifi\*'ee;
.LP
	\(em
	d\*'efinitions d'import: sp\*'ecification d'identificateurs de
variables appartenant \*`a d'autres processus et que le processus veut 
importer. Pour chaque identificateur, il convient de sp\*'ecifier la sorte 
de la variable; 
.LP
	\(em
	d\*'efinition de temporisateur (timer): fait l'objet du
\(sc\ D.3.11;
.LP
	\(em
	d\*'efinitions de macros: on trouvera des directives sur
l'utilisation des macros au \(sc\ D.5.1;
.LP
	\(em
	corps de processus: sp\*'ecification du comportement r\*'eel du
processus exprim\*'e \*`a l'aide d'\*'etats, entr\*'ees, sorties, t\* | ches,\ 
etc. Si le 
processus est divis\*'e en sous\(hyparties (services), la d\*'efinition 
du processus 
comporte une section de d\*'ecomposition en services en lieu et place du 
corps du processus. On trouvera des directives \*`a ce sujet au \(sc\ D.5.3. 
.PP
Des exemples et des explications concernant les donn\*'ees, les
variables, les d\*'efinitions de visibilit\*'e et les d\*'efinitions d'import 
sont 
donn\*'es au \(sc\ D.3.10.
.PP
On trouvera dans la figure\ D\(hy3.8.1 un exemple partiel de d\*'efinition 
de processus en LDS/PR (les mots cl\*'es du langage sont \*'ecrits en lettres 
majuscules).
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.1 [T10.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
Le corps de processus repr\*'esente le graphe r\*'eel de la machine \*`a 
\*'etats finis. Il consiste en une s\*'equence d'instructions ordonn\*'ees 
en LDS/PR et, en LDS/GR, c'est une s\*'equence de symboles reli\*'es par 
des arcs orient\*'es 
(similaires \*`a un organigramme). La sp\*'ecification du corps de processus 
doit 
toujours commencer par l'indication START suivi d'un ensemble d'actions
(transition). L'interpr\*'etation d'une instance de processus commence \*`a la
cr\*'eation de cette instance de processus.
.PP
Les actions qui peuvent \* | tre ex\*'ecut\*'ees dans une transition sont 
les suivantes: 
.RT
.LP
	\(em
	t\* | che: affectation de variable (ou texte informel);
.LP
	\(em
	exportation: exportation de variable;
.LP
	\(em
	initialisation (set): demande d'activation d'un
temporisateur;
.LP
	\(em
	r\*'einitialisation (reset): r\*'einitialisation d'un
temporisateur;
.LP
	\(em
	sortie: \*'emission d'un signal en direction d'un autre
processus;
.LP
	\(em
	demande de cr\*'eation: cr\*'eation d'une instance d'un type de
processus sp\*'ecifi\*'e;
.LP
	\(em
	d\*'ecision: s\*'election d'un ensemble d'actions d\*'ependant d'une
question;
.LP
	\(em
	appel de proc\*'edure: demande d'interpr\*'etation d'un ensemble
d'actions s\*'epar\*'e autonome (m\* | me usage que dans des langages de de
programmation);
.LP
	\(em
	branchement (join): sp\*'ecification d'un <<saut>> vers un autre
ensemble d'actions.
.PP
Une transition peut se terminer par l'une des actions
suivantes:
.LP
	\(em
	nexstate (\*'etat suivant): sp\*'ecification de l'\*'etat dans lequel
se trouvera l'instance de processus;
.LP
	\(em
	arr\* | t: arr\* | t imm\*'ediat de l'instance de processus.
.PP
Apr\*`es la sp\*'ecification de l'action de d\*'epart et de la transition 
de d\*'epart facultative, le corps du processus comprend les d\*'efinitions 
de tous ses \*'etats possibles. Chaque d\*'efinitin d'\*'etat commence 
par la sp\*'ecification des stimuli possibles, attendus par le processus 
dans cet \*'etat. Les stimuli 
possibles sont les suivants:
.LP
	\(em
	entr\*'ees: signaux qui peuvent \* | tre re\*,cus;
.LP
	\(em
	mises en r\*'eserve: signaux qui doivent \* | tre mis en r\*'eserve
pour traitement ult\*'erieur;
.LP
	\(em
	conditions de validation: d\*'ecrites au \(sc\ D.3.8.5;
.LP
	\(em
	signaux continus: d\*'ecrits au \(sc\ D.3.8.5.
.PP
Une transition doit \* | tre sp\*'ecifi\*'ee en correspondance avec chaque 
stimulus sauf en ce qui concerne les mises en r\*'eserve. De telles transitions 
repr\*'esentent la s\*'equence d'actions que le processus ex\*'ecutera 
si le stimulus 
appara\* | t.
.PP
Si un processus ex\*'ecute une action d'arr\* | t et que des signaux \*'emis
mais non encore re\*,cus se trouvent en suspens, ces signaux sont mis au rebut.
.PP
En LDS/GR, une d\*'efinition de processus est repr\*'esent\*'ee \*`a l'aide du
diagramme de processus. Un diagramme de processus se compose des \*'el\*'ements
suivants:
.RT
.LP
	\(em
	un symbole de cadre: symbole de forme rectangulaire contenant
tous les autres symboles. Si aucun acheminement du signal n'est
rattach\*'e au symbole de cadre, celui\(hyci peut \* | tre omis;
.LP
	\(em
	l'en\(hyt\* | te du processus: le mot cl\*'e PROCESSUS suivi de
l'identificateur de processus, puis \*'eventuellement de la
sp\*'ecification des param\*`etres formels. L'en\(hyt\* | te de processus
est plac\*'e dans l'angle sup\*'erieur gauche du cadre;
.LP
	\(em
	une num\*'erotation de page facultative (plac\*'ee dans l'angle
sup\*'erieur droit);
.LP
	\(em
	des symboles de texte: dans le cas d'un diagramme de
processus, un symbole de texte peut \* | tre utilis\*'e pour contenir
des d\*'efinitions de signal, de variable, de visibilit\*'e,
d'importation, de donn\*'ees et de temporisateur (timer);
.LP
	\(em
	r\*'ef\*'erences de proc\*'edure: symbole de proc\*'edure contenant un
nom de proc\*'edure repr\*'esentant une proc\*'edure du processus qui est
d\*'efinie s\*'epar\*'ement;
.LP
	\(em
	diagrammes de proc\*'edure: un pour chaque proc\*'edure locale du
processus qui n'est pas r\*'ef\*'erenci\*'ee;
.LP
	\(em
	la zone de graphe de processus: sp\*'ecification du comportement
du processus en termes de d\*'epart, d'\*'etats, d'entr\*'ees, de sorties,
de t\* | ches, . |  |  et d'arcs orient\*'es. Si le processus est
structur\*'e en services, la zone du graphe de processus contient la
sp\*'ecification des services ou leurs r\*'ef\*'erences (voir le \(sc\ D.5.3).
Les symboles en GR utilis\*'es pour le corps du processus sont
indiqu\*'es dans le r\*'esum\*'e du LDS/GR;
.LP
	\(em
	diagrammes de macro: on trouvera au \(sc\ D.5.1 des directives
sur l'utilisation des macros.
.PP
La figure D\(hy3.8.2 donne un exemple de d\*'efinition de processus en 
LDS/GR; on trouvera des explications et des exemples compl\*'ementaires 
sur les 
graphes de processus dans les paragraphes qui suivent.
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.2, p.\fR 
.ad b
.RT
.PP
Si un graphe de processus ne tient pas sur une seule page, le
diagramme peut \* | tre pr\*'esent\*'e sur plusieurs pages; il faut noter:
.LP
	\(em
	qu'une num\*'erotation de page contenant le num\*'ero de la page et
le nombre total de pages devrait \* | tre fournis,
c'est\(hy\*`a\(hydire:\ 1\ (9);
.LP
	\(em
	que le symbole de brachement (join) ou le symbole d'\*'etat
suivant (nextstate) peut \* | tre utilis\*'e pour repr\*'esenter des
connexions entre diff\*'erentes parties du graphe du
processus.
.PP
Un bon crit\*`ere pour diviser un graphe de processus en plusieurs parties 
consiste \*`a repr\*'esenter une d\*'efinition d'\*'etat sur chaque page. 
Si une d\*'efinition d'\*'etat ne tient pas sur une seule page, il est 
possible d'utiliser le symbole de branchement pour repr\*'esenter des connexions 
avec une partie du 
graphe qui se trouve sur une autre page.
.sp 1P
.LP
D.3.8.1
	\fICr\*'eation de processus\fR 
.sp 9p
.RT
.PP
Comme indiqu\*'e au paragraphe pr\*'ec\*'edent, des processus (c'est\(hy\*`a\(hydire 
des instances de processus) peuvent \* | tre cr\*'e\*'es \*`a la suite 
d'une demande 
explicite ou lors de la cr\*'eation du syst\*`eme.
.PP
La demande explicite de cr\*'eation ne peut \* | tre formul\*'ee que par un
autre processus du m\* | me bloc que le processus \*`a cr\*'eer; elle permet la
sp\*'ecification de param\*`etres r\*'eels pour le transfert de l'information 
vers la nouvelle instance cr\*'e\*'ee. La figure\ D\(hy3.8.3 donne un exemple 
de cr\*'eation en PR et en GR. 
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.3, p.\fR 
.ad b
.RT
.PP
Si une ou plusieurs instances de processus d'un type de processus donn\*'e 
sont cr\*'e\*'ees au moment de la cr\*'eation du syst\*`eme, la d\*'efinition 
de ce (ou ces) processus ne doit pas avoir acc\*`es aux param\*`etres formels 
car ils seront ind\*'efinis. En cons\*'equence, chaque d\*'efinition de 
processus ayant des param\*`etres formels doit \*'egalement faire le n\*'ecessaire 
pour interdire l'acc\*`es \*`a ses 
param\*`etres formels avant que ceux\(hyci aient re\*,cu une valeur ou qu'ils
comportent explicitement la sp\*'ecification d'aucune instance de processus au
moment de la cr\*'eation du syst\*`eme (voir la figure\ D\(hy3.8.4).
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.1 [T11.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
Lors de la cr\*'eation d'un processus, il est possible de d\*'eterminer 
des valeurs d'instance de processus \*`a l'aide des expressions pr\*'ed\*'efinies 
suivantes:
.LP
	(OFFSPRING) DESCENDANT: renvoie la valeur PId de la derni\*`ere
instance cr\*'e\*'ee,
.LP
	SELF: renvoie la valeur PId de l'instance de processus proprement
dite,
.LP
	(PARENT) ASCENDANT: renvoie la valeur PId de l'instance qui
proc\*`ede \*`a la cr\*'eation
.LP
	(SENDER) \o"E\(aa"METTEUR: renvoie la valeur PId du processus \*'emettant le
dernier signal utilis\*'e.
.PP
Lorsqu'un processus est cr\*'e\*'e par suite de la cr\*'eation du syst\*`eme, 
seule l'expression SELF renvoie une valeur PId; les expressions OFFSPRING 
et 
PARENT donnent la valeur NULL.
.PP
De telles valeurs rev\* | tent une grande importance lorsqu'il existe
plusieurs instances de processus du m\* | me type de processus car elles
constituent le seul moyen d'adresser sans ambigu\*:it\*'e les signaux aux 
instances. En fait, comme cela est mieux expliqu\*'e au \(sc\ D.3.8.6, 
lorsqu'un processus \*'emet un signal, il doit sp\*'ecifier l'instance 
de destination, \*`a moins que celle\(hyci ne puisse \* | tre d\*'etermin\*'ee 
sans ambigu\*:it\*'e. 
.PP
L'utilisateur doit veiller \*`a ce que les instances de processus cr\*'e\*'ees 
puissent, au besoin, communiquer les unes avec les autres. Pour y parvenir, 
il faut souvent pr\*'evoir certains types de processus d'initialisation. 
Ces 
processus, cr\*'e\*'es en m\* | me temps que le syst\*`eme, devront cr\*'eer 
les autres 
processus et \*'eventuellement communiquer les valeurs PId appropri\*'ees 
\*`a tous les processus auxquels elles seront n\*'ecessaires. 
.PP
Il convient de noter d'autres points importants concernant la cr\*'eation 
de processus: 
.RT
.LP
	1)
	apr\*`es la cr\*'eation du syst\*`eme, les processus ne peuvent
\* | tre cr\*'e\*'es que par un autre processus du m\* | me bloc. Une
possibilit\*'e de cr\*'eation d'un processus dans d'autres blocs
consiste \*`a avoir un processus sp\*'ecial dans chaque bloc; ce
processus provoque la cr\*'eation d'un processus \*`a la r\*'eception
d'un signal provenant d'un processus d'un autre bloc;
.LP
	2)
	apr\*`es leur cr\*'eation, les processus ont une dur\*'ee de vie qui
leur est propre. Ils ne cessent d'exister que lorsqu'ils
accomplissent une action d'arr\* | t pendant une transition. On
peut construire des syst\*`emes qui autorisent les op\*'erations
ext\*'erieures d'\*'elimination de processus en employant un signal
sp\*'ecial d'\*'elimination. A la r\*'eception du signal d'\*'elimination,
le processus accomplit une action d'arr\* | t.
.PP
La relation entre les processus cr\*'eateurs et les processus cr\*'e\*'es 
peut et\*^re repr\*'esent\*'ee dans un diagramme de bloc \*`a l'aide de 
symboles de 
lignes de cr\*'eation, comme indiqu\*'e dans la figure\ D\(hy3.8.5.
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.5, p.\fR 
.ad b
.RT
.sp 1P
.LP
D.3.8.2
	\fIEtats\fR 
.sp 9p
.RT
.PP
Un \*'etat est une \*'etape du processus pendant laquelle aucune action 
ne s'accomplit, mais o\*`u la file d'entr\*'ee contr\* | le l'arriv\*'ee 
des signaux 
entrants. Gr\* | ce \*`a l'identificateur de signaux que contient le signal
d'entr\*'ee, l'arriv\*'ee du signal fait sortir le processus de l'\*'etat 
et lui fait 
accomplir une succession donn\*'ee d'actions. Un signal qui est arriv\*'e et a
entra\* | n\*'e une transition a \*'et\*'e <<absorb\*'e>> et cesse d'exister.
.PP
En LDS/PR, un \*'etat est repr\*'esent\*'e par le mot cl\*'e STATE suivi 
du nom de l'\*'etat. La sp\*'ecification de l'\*'etat se termine soit \*`a 
l'\*'enonc\*'e d'\*'etat suivant soit \*`a la fin du processus ou au moyen 
du mot cl\*'e explicite ENDSTATE (FIN 
D'\o"E\(aa"TAT). On peut utiliser un ast\*'eristique dans l'\*'enonc\*'e 
d'\*'etat au lieu du nom de l'\*'etat; il s'agit l\*`a d'une notation abr\*'eg\*'ee 
indiquant que les entr\*'ees pour les mises en r\*'eserve suivantes et 
les transitions correspondantes doivent \* | tre interpr\*'et\*'ees pour 
chaque \*'etat. 
.PP
Le mot cl\*'e NEXTSTATE (\o"E\(aa"TAT SUIVANT), suivi du nom de l'\*'etat, est
utilis\*'e pour indiquer l'\*'etat qui suit. On peut employer un tiret 
dans l'\*'enonc\*'e d'\*'etat suivant au lieu du nom de l'\*'etat pour 
indiquer que l'\*'etat suivant est 
pr\*'ecis\*'ement l'\*'etat dont la transition actuelle tire son origine.
.PP
La figure D\(hy3.8.6 donne un exemple partiel en LDS/PR.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.6 [T12.100] \ \ 
(\*`a traiter comme tableau MEP, p.\fR 
.ad b
.RT
.PP
En LDS/GR, un \*'etat est repr\*'esent\*'e \*`a l'aide d'un symbole d'\*'etat
contenant le nom d'\*'etat et est reli\*'e aux symboles d'entr\*'ee ou 
de mises en 
r\*'eserve. Le m\* | me symbole d'\*'etat, avec une fl\*`eche d'arriv\*'ee, 
sert \*`a 
repr\*'esenter l'\*'enonc\*'e \*'etat suivant.
.PP
Par commodit\*'e, pour simplifier le dessin ou faciliter la
compr\*'ehension, le m\* | me \*'etat peut appara\* | tre plusieurs fois 
dans un diagrmme en LDS. Si tel est le cas, le diagramme est consid\*'er\*'e 
comme enti\*`erement 
\*'equivalent au diagramme qui r\*'esulterait, de la fusion de toutes les 
apparitions multiples du m\* | me \*'etat. Les figures\ D\(hy3.8.7 et\ 
D\(hy3.8.8 donnent des exemples de cette situation. Dans la figure\ D\(hy3.8.7\ 
b), on utilise un symbole d'\*'etat comme lien avec l'\*'etat principal 
portant le m\* | me nom, lorsqu'il est mentionn\*'e dans le symbole d'\*'etat 
suivant. Dans la figure\ D\(hy3.8.8 un \*'etat est repr\*'esent\*'e par 
des symboles multiples n'ayant chacun qu'un sous\(hyensemble des entr\*'ees 
(ou des mises en r\*'eserve). 
.PP
Les diagrammes a) et b) de la figure D\(hy3.8.7 sont logiquement
\*'equivalents. Le diagramme\ a) contient une seule apparition de chaque 
\*'etat 
tandis que le diagramme\ b) utilise des apparitions multiples. Dans le
diagramme\ b), l'\*'etat a une apparition principale, dans laquelle tous ses
symboles d'entr\*'ees (et de mises en r\*'eserve) associ\*'es sont indiqu\*'es. 
Lorsque cet \*'etat peut \* | tre atteint \*`a partir d'autres points du 
diagramme (par exemple le point de terminaison d'une transition), il est 
indiqu\*'e comme un \*'etat sans 
entr\*'ee ni mise en r\*'eserve associ\*'ee. Un commentaire du symbole 
d'\*'etat suivant se r\*'ef\*'erant au symbole d'\*'etat am\*'eliorera 
la clart\*'e, notamment lorsqu'ils 
apparaissent sur des pages diff\*'erentes.
.PP
La figure D\(hy3.8.8 utilise les apparitions multiples d'un \*'etat pour
constituer l'ensemble total d'entr\*'ees (et de mises en r\*'eserve). Chaque
apparition de l'\*'etat est indiqu\*'ee uniquement avec un sous\(hyensemble 
de ces 
entr\*'ees.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.7 a, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.7 b, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.8, p.\fR 
.ad b
.RT
.PP
Cette approche a \*'et\*'e appliqu\*'ee avec succ\*`es lorsque des \*'etats
avaient un nombre relativement grand d'entr\*'ees ou de mises en r\*'eserve 
mais 
pr\*'esentaient le risque que le lecteur interpr\*`ete de fa\*,con erron\*'ee 
le 
diagramme s'il n'\*'etait pas conscient de l'existence d'occurrences multiples.
Pour \*'eviter ce malentendu, les \*'etats n'indiquant qu'un sous\(hyensemble
d'entr\*'ees/mises en r\*'eserve devraient \* | tre accompagn\*'es d'un 
commentaire 
indiquant une r\*'ef\*'erence \*`a d'autres \*'etats avec leurs entr\*'ees 
et mises en 
r\*'eserve associ\*'ees, comme indiqu\*'e dans la figure\ D\(hy3.8.8.
.PP
Des apparitions multiples peuvent \* | tre utilis\*'ees pour attirer
l'attention du lecteur sur certains aspects (par exemple la s\*'equence normale
des signaux trait\*'es), laissant d'autres aspects pour d'autres pages (par
exemple le traitement de situations d'alarme).
.PP
Au cours d'une transition un processus ne sait pas explicitement quel signal 
d'entr\*'ee a occasionn\*'e la transition. Seul le contexte permet de le 
d\*'eduire (c'est\(hy\*`a\(hydire que cette transition ne peut se produire 
qu'en cas de 
r\*'eception d'un signal donn\*'e). Dans la figure\ D\(hy3.8.9, la t\* | che\ 
T1 ne 
s'accomplit qu'en cas de r\*'eception de\ I1. Toutefois, la t\* | che\ 
T2 s'accomplit en cas de r\*'eception de\ I2 ou de\ I3. S'il importe que\ 
T2 sache quel signal 
d'entr\*'ee a \*'et\*'e re\*,cu, il est souhaitable de concevoir le processus 
comme 
l'illustre la figure\ D\(hy3.8.10.
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.9, p.\fR 
.ad b
.RT
.LP
.rs
.sp 01P
.ad r
\fBFigure D\(hy3.8.10, p.\fR 
.ad b
.RT
.LP
.bp