delim @@
|
| 5i' |
FASCICULE X.2 |
DIRECTIVES POUR LES USAGERS DU LDS Blanc
MONTAGE: PAGE 2 = PAGE BLANCHE
2 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
DIRECTIVES POUR LES USAGERS DU LDS TABLE DES MATIERES |
|
Page D.1 Preface´ / D.2 Introduction / |
D.2.1 Apercu¸ gen´ eral´ du LDS /
D.2.2 Forme syntaxique du LDS /
|
D.2.3 |
Applicabilite´ du LDS / |
Concepts de base du LDS / |
|
D.3.2 |
Blocs / |
|
D.3.7 |
Commentaires et extension de texte / |
D.4.1 Considerations´ gen´ erales´ /
D.4.3 Subdivision des blocs /
D.4.4 Diagramme d'arbre de blocs /
D.4.5 Division des canaux /
D.4.6.1 Sous-ensemble de subdivision coherent´ /
D.4.7 Affinage /
D.4.7.1 Sous-ensemble d'affinage coherent´ /
D.4.7.2 Transformation entre signaux et sous-signaux /
Fascicule X.2 -- Rec. Z.100 -- Annexe D 3
|
D.5.1 |
D.5 Macros / |
Concepts supplementaires´ |
/ |
D.5.3 Services /
D.5.3.1 Considerations´ gen´ erales´ /
D.5.3.2 Signaux prioritaires /
|
D.5.3.3 |
Transformation / |
graphiques / |
|
D.5.4.1 |
Observations d'ordre gen´ eral´ sur |
sur la representation´ / |
en fonction des etats´ |
/ |
/ |
|||||||
|
D.5.5.2 |
Matrice etat/signal´ / |
/ |
||||||||||
|
D.6 |
Definition´ |
de donnees´ en LDS / |
D.6.1 Directives applicables aux donnees´ en LDS /
D.6.1.1 Introduction gen´ erale´ /
D.6.1.2 Sortes /
|
D.6.1.3 |
Operateurs,´ litteraux´ et termes / |
equations´ et les axiomes / |
||
|
D.6.2 |
Gen´ erateurs´ et heritage´ / |
Directives supplementaires´ pour le dessin et l'ecriture´ / |
||
|
D.7.1 |
Directives pour le LDS/GR / |
|||
|
D.8 Documentation / |
||||
|
D.8.1 |
Introduction / |
D.8.3 Structure de documents /
|
D.8.4 |
Mecanisme´ |
Mecanisme´ de ref´ erence´ / |
||
|
D.9 Mises en correspondance / |
||||
|
D.9.1 |
Mise |
Mise en correspondance du LDS et du CHILL / |
||
|
D.10 Exemples d'application / |
||||
|
4 |
D.10.1 Fascicule |
Introduction X.2 |
Introduction / -- Rec. Z.100 -- Annexe D |
|
D.11.1 |
Introduction / |
D.11 |
Outil pour le LDS / |
D.11.8 Gen´ eration´ de code /
D.11.9 Formation /
Fascicule X.2 -- Rec. Z.100 -- Annexe D 5
|
D.1 Preface´ Le langage de |
specification´ et de description du CCITT (LDS) a tout d'abord fait l'objet |
des |
developp´ e´ et harmonise;´ les Recommandations existantes ont et´ e´ fondues en une seule et une definition´ mathematique´
a et´ e´ ajoutee.´
L'emploi du LDS est largement repandu´ au sein du CCITT et des organisations qui en sont membres; en outre, la
des conseils judicieux et des exemples utiles. Il y aura certes quelques chevauchements entre les directives et la
consulter. C'est neanmoins´ la Recommandation qui constitue le document de base.
D.2 Introduction
D.2.1 Apercu¸ gen´ eral´ du LDS
interviennent dans les tel´ ecommunications,´ mais peut egalement´ | tre utilise´ dans une gamme d'applications plus large.
fonction ou d'une facilite,´ qu'il s'agisse de leurs specifications´ ou de leurs descriptions. Les propriet´ es´ fonctionnelles designent´ certaines propriet´ es´ structurelles (diagramme d'interaction de blocs) ainsi que le comportement. Par
actions qu'il execute,´ par exemple, envoi de signaux (sorties), formulation de questions (aux fins de decision)´ et execution´ de t| ches.
genre ne donneront gen´ eralement´ que peu de details.´ A l'autre extremit´ e,´ il y a les specifications´ par lesquelles une Administration demande le remplacement ou l'extension d'un central existant. Dans ce cas, les details´ devront
Une specification´ et une description peuvent | tre identiques. Il est toujours pref´ erable´ de concevoir les nouvelles
6 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
gen´ eralement´ plus detaill´ ee´ |
que la specification´ puisqu'il s'agit de rendre compte du comportement detaill´ e |
e´ du |
types definis´ et d'operateurs´ sur ces el´ ements.´ Les propriet´ es´ de ces el´ ements´ ne sont pas specifi´ ees;´ exemple:
specification´ ainsi obtenue permet le transfert de l'information aux lecteurs qui connaissent la signification des
|
operateurs´ Troisiemement, |
sont inconnues. Troisiemement, il est possible egalement´ d'indiquer toutes les propriet´ es´ |
de tous les operateurs.´ |
Dans ce cas, la |
Selon l'objectif vise,´ les descriptions peuvent | tre adaptees´ aux besoins des usagers au moyen de differents´
|
lire. |
Dans le texte qui suit, le terme specification´ |
sera utilise´ a la fois pour la representation´ |
necessaire´ |
et pour celle |
des comportements reels.´
2) le comportement dynamique de chaque machine, ses interactions avec les autres machines et avec l'environnement, et
|
3) les On decrit´ |
les operations´ sur les donnees´ associees´ aux interactions. le comportement dynamique au moyen de modeles qui definissent´ |
les mecanismes´ |
de fonctionnement |
des machines abstraites ainsi que la communication entre les machines. La machine abstraite qu'emploie le LDS est
fonctionne avec un ensemble discret et fini d'entrees´ et de sorties. Pour chaque combinaison d'une entree´ et d'un etat,´
|
etats´ est nulle. L'une des limites de la FSM est la suivante: toutes les donnees´ |
a memoriser´ doivent | tre represent´ ees´ |
sous la |
partie de l'espace des etats´ explicites; en effet, ceci compliquerait la presentation.´ Il est possible pour ce genre d'applications d'etendre´ la FSM en la dotant d'une memoire´ auxiliaire et d'une capacite´ de fonctionnement auxiliaire sur cette memoire.´ Cette memoire´ auxiliaire peut emmagasiner, par exemple, des informations concernant des adresses et des numeros´ d'ordre.
Les Recommandations relatives au LDS definissent´ deux operations´ auxiliaires qu'il est possible d'inclure dans
donnees´ sont importantes pour le sequencement´ de la machine principale. Les <<t| ches>> executent´ des fonctions
Fascicule X.2 -- Rec. Z.100 -- Annexe D 7
signaux comme entrees´ et produisent des signaux comme sorties. Les signaux se composent d'un seul identificateur
different´ de zero,´ et definit´ un mecanisme´ theorique´ de mise en file d'attente <<premier entre,´ premier sorti>> pour les
leur ordre d'arrivee.´
D.2.2 Formes syntaxiques du LDS
semantique.´ L'une est appelee´ LDS/GR (LDS graphical representation) et repose sur un ensemble de symboles graphiques normalises.´ L'autre s'appelle LDS/PR (LDS textual phrase representation) et repose sur des instructions
l'utilisation par des machines.
dans la version de 1976 des Recommandations de la serie´ Z.100.
Le LDS/GR a et´ e´ etabli´ sur la base de langages graphiques elabor´ es´ par differentes´ organisations pour leurs propres utilisations.
1977-1980 mais il a fallu y apporter certaines ameliorations´ avant qu'elle puisse faire l'objet d'une Recommandation.
Dans un premier temps, le LDS/PR devait | tre utilise´ comme un moyen aise´ d'introduire des documents en LDS dans une machine, ce qui etait´ trop difficile avec le GR (en effet, cela necessitait´ l'intervention d'equipements´
(capacites´ accrues et reduction´ des co| ts) ont fait que le GR est desormais´ susceptible d'| tre introduit en machine.
Du fait de cette evolution,´ la correlation´ entre le GR et le PR est moins etroite;´ cependant, il est encore possible de mettre en correspondance sans difficulte´ l'une de ces representations´ avec l'autre, bien que chacune d'elles ait ses
figure D-2.2.1).
En fait, tout depend´ de ce qui caracterise´ un texte du point de vue du langage de programmation.
Si nous admettons qu'un programme est defini´ comme une <<information interpretable´ par une machine>>, non seulement les PR mais aussi les GR sont des <<programmes>>.
Il existe cependant certaines differences´ entre une specification´ en LDS et un programme reel.´ Tout d'abord, il n'est pas indispensable qu'une specification´ en LDS puisse | tre execut´ ee´ par une machine (bien que cela ne soit pas
|
humain. Si nous considerons´ |
une specification´ |
en LDS comme un programme, ce qui peut | tre tenu pour une |
<<specification´ en LDS erronee>>´ (en raison d'un texte informel incomplet) pourrait | tre parfaitement valable si elle 8 Fascicule X.2 -- Rec. Z.100 -- Annexe D
usuelle d'un programme.
Le LDS ayant pour but de faciliter la communication entre | tres humains, on s'est efforce´ de preserver´ la
aspects consider´ es´ comme plus importants que d'autres. Cela est naturellement sans importance pour un programme, qui est cense´ | tre interpret´ e´ par une machine. La machine n'insiste pas sur un quelconque aspect particulier du
programme.
Etant donne´ ses similitudes avec un programme, le PR a la pref´ erence´ de certains programmeurs qui utiliseront probablement aussi le CHILL pour la mise en oeuvre des besoins. On serait donc probablement tente´ de rechercher une correspondance point par point entre le PR et le CHILL, afin que les besoins exprimes´ en PR puissent | tre automatiquement transformes´ en code CHILL. L'inverse est egalement´ interessant´ car cela permettrait la derivation´
On trouvera au § D.9 des exemples de possibilites´ de mettre en correspondance le LDS avec le CHILL.
D.2.3 Applicabilite´ du LDS
de commutation pour les tel´ ecommunications.´
Dans cette figure, les rectangles representent´ des groupes fonctionnels typiques, dont les noms precis,´ qui
un groupe fonctionnel et un autre; le LDS peut alors | tre employe´ en tant que partie de chacune de ces series´ de
donnees´ et interfaces d'usagers (LHM).
protection contre les surcharges), et les interfaces homme-machine. Le § D.10 donne des exemples d'application du LDS.
D.3 Concepts de base du LDS
des parties d'un grand nombre de centraux tel´ ephoniques´ (par exemple, les dispositifs de contr| le de circuit aux deux
Fascicule X.2 -- Rec. Z.100 -- Annexe D 9
|
LDS. Des canaux relient le systeme a l'environnement. Theoriquement,´ |
il suffit d'un seul canal bidirectionnel pour |
logique avec l'environnement.
independant´ de tous les autres. Chaque bloc peut contenir un ou plusieurs processus decrivant´ le comportement du bloc. Seule l'emission´ de signaux dans les canaux permet la communication entre des processus places´ dans deux
parties d'une dimension facilitant la comprehension,´ creer´ une correspondance avec la division effective entre le logiciel et le materiel,´ suivre les subdivisions fonctionnelles naturelles, reduire´ au minimum les interactions, etc.
|
constructions sont decrites´ au § D.4. Au premier niveau de precision,´ |
la specification´ en LDS d'un systeme decrit´ |
la structure du systeme et comprend |
les points suivants, expliques´ dans les paragraphes qui suivent:
|
blocs et l'environnement. Cela comprend la specification´ des types de valeurs achemines´ |
par les signaux (liste de |
-- definitions´ de listes de signaux: specification´ des identificateurs groupant plusieurs signaux et/ou autres
|
claire; -- |
definitions´ |
de canaux: specification´ |
des canaux reliant les blocs du systeme les uns aux autres et a |
|
l'environnement. Une definition´ de canal comprend la specification´ des identificateurs des signaux achemines´ par -- definitions´ de donnees:´ specification´ de nouveaux types de syntypes et de gen´ erateurs´ definis´ |
par ce par |
|
|
l'utilisateur et visibles dans tous les blocs; |
-- definitions´ de macros: des directives concernant l'utilisation des macros sont donnees´ au § D.5.1.
Selon la Recommandation concernant le LDS, il existe des types de donnees´ pred´ efinis´ qui peuvent | tre utilises´
On trouvera des explications complementaires´ sur l'utilisation des types de donnees´ aux § D.3.10 et D.6.
termine par l'instruction <<ENDSYSTEM nom;>>. Le nom de l'instruction terminale est facultatif mais s'il est donne,´
l'instruction terminale, car cela ameliore´ la lisibilite´ du document.
10 Fascicule X.2 -- Rec. Z.100 -- Annexe D
de bloc proprement dite peut | tre donnee´ separ´ ement´ (voir la figure D-3.1.2).
doivent tenir sur une seule page et que la place manque souvent pour des specifications´ graphiques embo| tees.´
D.3.2 Blocs
partagees.´ Ainsi le bloc ne constitue pas seulement un mecanisme´ pratique pour le regroupement de processus, mais
appeles´ acheminement de signaux.
La definition´ de la structure d'un bloc peut comporter les points suivants:
|
-- -- |
nom de bloc; definitions´ de signaux: specification´ des types de signaux echang´ es´ a l'interieur´ |
du bloc. Cela comprend la |
specification´ des types de valeurs achemines´ par les signaux (liste de sortes);
pour economiser´ de l'espace et obtenir une specification´ plus claire;
-- definitions´ d'acheminement de signaux: specifications´ des trajets de communication reliant les processus
|
specification´ |
des identificateurs de signaux transportes´ sur cet acheminement de signaux; |
|||
|
-- |
-- |
connexions de canaux vers des acheminements: specifications´ des connexions entre les canaux |
||
|
exterieurs´ |
au bloc et les acheminements de signaux internes du bloc; |
|||
|
-- |
definitions´ de processus: specification´ des types de processus decrivant´ le comportement du bloc. Si le |
|
l'interieur´ du bloc. Pour la definition´ |
du processus, un mecanisme´ de ref´ erence´ |
est fourni comme cela est indique,´ dans |
-- definitions´ des donnees:´ specification´ de newtypes, de syntypes et de gen´ erateurrs´ definis´ par l'usager et visibles dans tous les processus definis´ du bloc et/ou dans la structure-structure du bloc;
-- definitions´ de macros: des directives pour l'utilisation de macros sont donnees´ au § D.5.1.
les explications concernant la structure).
Fascicule X.2 -- Rec. Z.100 -- Annexe D 11
|
Les types suivants sont visibles dans un bloc: -- des types de donnees´ pred´ efinis;´ -- des types de donnees´ definis´ par l'usager, |
definis´ dans le bloc proprement dit; |
|
|
-- des types de donnees´ definis´ par l'usager |
visibles dans le bloc ascendant (en cas de subdivision des blocs). |
des exemples du LDS/GR pour une definition´ de bloc au § D.3.6.
D.3.3 Canaux
unidirectionnel) ou dans les deux directions (canal bidirectionnel). Normalement, un canal est une entite´ fonctionnelle qui peut | tre utilisee´ pour designer´ des chemins de communication specifiques.´ En fait, par la subdivision des canaux (decrite´ au § D.4.5), il est possible de specifier´ formellement le comportement de chaque canal.
Pour chaque direction indiquee´ ou chaque chemin de communication, la specification´ 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
de la specification´ d'interface pour chaque bloc. Dans de grands projets interessant´ de nombreuses personnes, un
que deux processus ne pourront communiquer l'un avec l'autre comme prevu.´
La definition´ d'un canal comporte les el´ ements´ suivants:
-- nom du canal;
-- un ou deux chemins de communication: un chemin de communication specifie´ l'origine et la destination d'une liste de signaux. Des identificateurs de bloc ou le mot cle´ <<ENV>> (environnement) peuvent | tre utilises´ dans ce contexte;
-- une ou deux listes de signaux: une liste des signaux transportes´ dans cette direction doit | tre specifi´ ee´ pour chaque chemin de communication. Cette liste peut comporter des identificateurs de signaux ainsi que des identificateurs d'autres listes;
§ D.4.5.
Dans le LDS/PR, une definition´ de canal est comprise entre les deux mots cles´ CHANNEL et ENDCHANNEL.
On trouvera dans la figure D-3.3.1 un exemple de definition´ de canal en LDS/PR.
dans la communication. Le nom du canal doit | tre plus proche de la ligne que tout autre symbole. Les trajets sont
ne doivent pas | tre placees´ en l'un des deux points terminaux de la ligne (voir le § D.3.5).
correspondante.
12 Fascicule X.2 -- Rec. Z.100 -- Annexe D
D.3.4 Signaux
|
que possible. Les signaux definis´ dans le cadre d'une definition´ de processus peuvent | tre echang´ es´ La definition´ d'un signal comprend les points suivants: -- nom du signal; -- liste de sortes (facultative): represente´ la liste des types de valeurs acheminees´ par ce signal; -- affinage du signal (facultatif): voir le § D.4.7. |
entre des |
En LDS/PR, une definition´ de signal est specifi´ ee´ par le mot cle´ SIGNAL. Plusieurs signaux (n'ayant pas fait
types. Des exemples de definitions´ de signaux en LDS/PR sont donnes´ dans la figure D-3.4.1.
En LDS/GR, on specifie´ une definition´ de signal en inserant´ des enonc´ es´ lineaires´ dans un symbole de texte comme indique´ dans la figure D-3.4.2.
D.3.5 Acheminements de signaux
peuvent | tre unidirectionnels ou bidirectionnels mais ils ne peuvent | tre subdivises.´
Au niveau des blocs, ils representent´ un moyen de communication entre les processus d'un bloc ou entre les
Au niveau du processus, les acheminements de signaux peuvent | tre utilises´ lorsque le processus est subdivise´
en services (voir le § D.5.3). Dans ce cas, ils relient les services les uns aux autres ou avec les acheminements de signaux du processus.
acheminements de signaux, ce signal est place´ dans l'acheminement de signaux qui est capable de la transferer.´
En LDS/PR, la definition´ d'un acheminement de signal commence par le mot cle´ SIGNALROUTE. La syntaxe des chemins de communication et la liste des signaux sont les m| mes que dans le cas des canaux.
En LDS/GR, la seule difference´ entre un acheminement de signaux et un canal est que, pour les acheminements
liste de signaux appropries.´ On trouvera des exemples d'acheminements de signaux dans les figures D-3.6.3 et D-3.6.5 des paragraphes qui suivent.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 13
-- le symbole de cadre: symbole de forme rectangulaire contenant tous les autres symboles. Il represente´ la
|
-- une numerotation´ de page facultative (placee´ dans l'angle superieur´ droit -- des symboles de texte: un tel symbole peut contenir des enonc´ es |
droit du cadre); es´ lineaires.´ Il sert gen´ eralement´ |
a |
presenter´ dans le diagramme des definitions´ de signaux, des listes de signaux et les donnees;´
de signaux achemines´ par les canaux;
-- des diagrammes de macros: les directives concernant l'utilisation des macros sont donnees´ au § D.5.1.
-- une ref´ erence´ de bloc: symbole de bloc contenant uniquement le nom de bloc;
-- un diagramme de bloc: cadre contenant la specification´ de la structure de bloc en fonction de ses
diagrammes de bloc. En ce qui concerne les definitions´ de symboles, il convient de se ref´ erer´ au § D.7.1.4.
Pour les blocs B1 et B2, on ne donne dans cet exemple qu'une ref´ erence.´ Des explications complementaires´ sur les canaux et les symboles de listes de signaux sont donnes´ dans les paragraphes qui suivent:
Le m| me exemple en LDS/PR est represent´ e´ dans la figure D-3.6.2.
La structure d'un bloc en ce qui concerne les processus et les acheminements de signaux est represent´ ee´ en
Le diagramme de bloc se compose des el´ ements´ suivants:
-- le symbole cadre: symbole de forme rectangulaire contenant tous les autres symboles. Il represente´ les
|
-- l'en-t| -- une -- des |
pour |
l'en-t| te du bloc: le mot cle´ BLOCK suivi du nom de bloc (place´ dans l'angle superieur´ gauche du cadre); une numerotation´ de page facultative (placee´ dans l'angle superieur´ droit du cadre); des symboles de texte: ces symboles peuvent englober des enonc´ es´ lineaires.´ Ils sont gen´ eralement´ |
|||
|
-- la |
la zone d'interaction de processus: cette zone comprend la specification´ des processus du bloc et |
Dans cette zone, il est egalement´ possible de representer´ les processus qui creent´ d'autres processus; cette caracteristique´ est decrite´ au § D.3.8.1;
-- des identificateurs de canaux: si le diagramme fait appara| tre des acheminements de signaux aboutissant
doivent | tre specifi´ es´ en dehors du cadre, de facon¸ correspondante aux lignes des acheminements de signaux;
14 Fascicule X.2 -- Rec. Z.100 -- Annexe D
-- des diagrammes de macros: on trouvera au § D.5.1 des directives sur l'utilisation des macros.
Dans le diagramme de bloc, la specification´ d'un processus peut | tre:
specification´ d'instances de processus. Une telle specification´ comprend deux couples de nombres entiers separ´ es´ par
-- soit un diagramme de processus: cadre contenant un graphique de symboles relies´ decrivant´ le comportement du processus en ce qui concerne les etats,´ les entrees,´ les sorties, les actions, etc. (voir le § D.3.8). Si le processus est subdivise´ en services, le diagramme de processus contient la zone d'interaction de service (§ D.5.3).
Dans la figure D-3.6.3, on trouvera un exemple de diagramme de bloc pour le bloc <<B1>> present´ e´ dans l'exemple de la figure D-3.6.1. Ce bloc B1 est decrit´ du point de vue des deux processus P1 et P2, relies´ par les
dans cet exemple. Les identificateurs de canaux C1, C2 et C3 sont egalement´ specifi´ es´ en dehors du cadre.
Le m| me exemple est present´ e´ en LDS/PR dans la figure D-3.6.4.
Une recommandation gen´ 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.
D.3.7 Commentaires et extension de texte
|
D.3.7.1 Commentaires Il est possible d'ajouter des commentaires a une specification´ en LDS pour aider le lecteur et preciser´ |
certains |
points. Deux types de commentaires adaptes´ au LDS/PR et au LDS/GR ont et´ e´ introduits dans le LDS.
speciale´ <<*/>>.
lineaires.´
On trouvera dans les figures D-3.7.1 et D-3.7.2 certains exemples de cette forme de commentaire, respectivement en LDS/PR et en LDS/GR.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 15
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.
texte du commentaire. Le symbole de commentaire est un symbole de forme rectangulaires auquel le c| te´ gauche ou
faut employer une ligne en traits discontinus. Si l'association entre le texte du commmentaire et le symbole du commentaire ne presente´ pas d'ambiguit¨ e,´ le symbole de commentaire peut se presenter´ simplement sous la forme de crochets.
Dans les figures D-3.7.3 et D-3.7.4, on trouvera certains exemples de cette forme de commentaire, respectivement en LDS/PR et en LDS/GR.
D.3.7.2 Extension de texte
de texte rattache´ au symbole associe.´ Le symbole d'extension de texte est similaire au symbole de commentaire; la seule difference´ est que la ligne le reliant est en trait continu et non en trait discontinu (voir la figure D-3.7.5).
On trouvera au § D.3.13 des directives plus detaill´ ees´ sur la syntaxe des noms.
D.3.8 Processus
processus contiennent de nombreux etats´ qui leur permettent d'accomplir differentes´ actions en cas de reception´ d'un
creation´ emise´ par un autre processus. En outre, les processus peuvent durer indefiniment´ ou s'arr| ter du fait du declenchement´ d'une action d'arr| t.
Une definition´ de processus represente´ la specification´ d'un type de processus; plusieurs instances du m| me type de processus peuvent | tre cre´ ees´ et exister simultanement;´ elles peuvent fonctionner independamment´ et concurremment. Une definition´ de processus comprend les points suivants (dont certains sont facultatifs):
-- nom de processus;
-- une paire de nombre entiers. Le premier de ces nombres entiers specifie´ le nombre d'instances de
le nombre maximal d'instances de processus simultanees;´ s'il est omis, la valeur par defaut´ maximale est illimitee;´
16 Fascicule X.2 -- Rec. Z.100 -- Annexe D
transmettre l'information au processus au moment de la creation.´ Dans la demande de creation´ de processus, une liste
-- ensemble de signaux d'entree´ valides: liste d'identificateurs de signaux definissant´ les signaux que le processus peut recevoir;
-- definitions´ de signaux: specification´ des signaux qui peuvent | tre echang´ es´ entre instances du m| me processus ou entre services de ce processus (§ D.5.3);
-- definitions´ de procedures:´ specification´ des procedures´ qui peuvent | tre appelees´ par le processus. Une ref´ erence´ de procedure´ peut | tre utilisee´ dans ce contexte (les procedures´ font l'objet du § D.3.9);
|
-- definition´ de donnees:´ |
specifications´ des nouveaux types, syntypes et gen´ erateurs´ definis´ |
par l'usager et |
-- definition´ de variables: declarations´ des variables du processus. A titre facultatif, on peut indiquer qu'une variable peut | tre partagee´ avec plusieurs autres processus du m| me bloc (variable REVEALED) ou exportee´ vers d'autres processus ainsi que vers d'autres blocs (variable EXPORTED). Pour chaque variable declar´ ee,´ il faut specifier´ l'identificateur de sa sorte. Une variable initiale peut facultativement | tre specifi´ ee;´
|
variable doit | tre specifi´ ee; -- definitions´ d'import: |
ee;´ d'import: specification´ |
d'identificateurs de variables appartenant a d'autres processus et que le |
processus veut importer. Pour chaque identificateur, il convient de specifier´ la sorte de la variable;
-- definition´ de temporisateur (timer): fait l'objet du § D.3.11;
-- definitions´ de macros: on trouvera des directives sur l'utilisation des macros au § D.5.1;
sorties, t| ches, etc. Si le processus est divise´ en sous-parties (services), la definition´ du processus comporte une
§ D.5.3.
|
Des exemples et des explications concernant les donnees,´ |
les variables, les definitions´ |
de visibilite´ et les |
On trouvera dans la figure D-3.8.1 un exemple partiel de definition´ de processus en LDS/PR (les mots cles´ du langage sont ecrits´ en lettres majuscules).
d'instructions ordonnees´ en LDS/PR et, en LDS/GR, c'est une sequence´ de symboles relies´ par des arcs orientes´
creation´ de cette instance de processus.
|
Les actions qui peuvent | tre execut´ ees´ dans une transition sont les suivantes: -- t| che: affectation de variable (ou texte informel); -- exportation: exportation de variable; -- initialisation (set): demande d'activation d'un temporisateur; -- reinitialisation´ (reset): reinitialisation´ d'un temporisateur; -- sortie: emission´ d'un signal en direction d'un autre processus; Fascicule X.2 -- Rec. Z.100 |
Z.100 -- Annexe D 17 |
-- demande de creation:´ creation´ d'une instance d'un type de processus specifi´ e;´
-- decision:´ selection´ d'un ensemble d'actions dependant´ d'une question;
-- appel de procedure:´ demande d'interpretation´ d'un ensemble d'actions separ´ e´ autonome (m| me usage que dans des langages de de programmation);
|
-- branchement (join): specification´ d'un <<saut>> vers un autre ensemble d'actions. Une transition peut se terminer par l'une des actions suivantes: -- nexstate (etat´ suivant): specification´ de l'etat´ dans lequel se trouvera l'instance de processus; -- arr| t: arr| t immediat´ de l'instance de processus. |
|
comprend les definitions´ de tous ses etats´ possibles. Chaque definitin´ d'etat´ commence par la specification´ -- entrees:´ signaux qui peuvent | tre recus;¸ -- mises en reserve:´ signaux qui doivent | tre mis en reserve´ pour traitement ulterieur;´ -- conditions de validation: decrites´ au § D.3.8.5; -- signaux continus: decrits´ au § D.3.8.5. |
des stimuli |
Une transition doit | tre specifi´ ee´ en correspondance avec chaque stimulus sauf en ce qui concerne les mises en reserve.´ De telles transitions representent´ la sequence´ d'actions que le processus executera´ si le stimulus appara| t.
Si un processus execute´ une action d'arr| t et que des signaux emis´ mais non encore recus¸ se trouvent en suspens, ces signaux sont mis au rebut.
processus se compose des el´ ements´ suivants:
-- un symbole de cadre: symbole de forme rectangulaire contenant tous les autres symboles. Si aucun acheminement du signal n'est rattache´ au symbole de cadre, celui-ci peut | tre omis;
-- l'en-t| te du processus: le mot cle´ PROCESSUS suivi de l'identificateur de processus, puis eventuellement´
-- une numerotation´ de page facultative (placee´ dans l'angle superieur´ droit);
-- des symboles de texte: dans le cas d'un diagramme de processus, un symbole de texte peut | tre utilise´
pour contenir des definitions´ de signal, de variable, de visibilite,´ d'importation, de donnees´ et de temporisateur (timer);
|
-- ref´ erences´ de procedure:´ symbole de procedure´ contenant un nom de procedure´ |
representant´ |
une |
-- diagrammes de procedure:´ un pour chaque procedure´ locale du processus qui n'est pas ref´ erenci´ ee;´
-- la zone de graphe de processus: specification´ du comportement du processus en termes de depart,´
d'etats,´ d'entrees,´ de sorties, de t| ches, . | | et d'arcs orientes.´ Si le processus est structure´ en services, la zone du graphe de processus contient la specification´ des services ou leurs ref´ erences´ (voir le § D.5.3). Les symboles en GR utilises´ pour le corps du processus sont indiques´ dans le resum´ e´ du LDS/GR;
-- diagrammes de macro: on trouvera au § D.5.1 des directives sur l'utilisation des macros.
La figure D-3.8.2 donne un exemple de definition´ de processus en LDS/GR; on trouvera des explications et des exemples complementaires´ sur les graphes de processus dans les paragraphes qui suivent.
18 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Si un graphe de processus ne tient pas sur une seule page, le diagramme peut | tre present´ e´ sur plusieurs pages; il faut noter:
-- qu'une numerotation´ de page contenant le numero´ de la page et le nombre total de pages devrait | tre
-- que le symbole de brachement (join) ou le symbole d'etat´ suivant (nextstate) peut | tre utilise´ pour representer´ des connexions entre differentes´ parties du graphe du processus.
d'etat´ sur chaque page. Si une definition´ d'etat´ ne tient pas sur une seule page, il est possible d'utiliser le symbole de branchement pour representer´ des connexions avec une partie du graphe qui se trouve sur une autre page.
D.3.8.1 Creation´ de processus
La demande explicite de creation´ ne peut | tre formulee´ que par un autre processus du m| me bloc que le
instance cre´ ee.´ La figure D-3.8.3 donne un exemple de creation´ en PR et en GR.
Si une ou plusieurs instances de processus d'un type de processus donne´ sont cre´ ees´ au moment de la creation´
la figure D-3.8.4).
expressions pred´ efinies´ suivantes:
SELF: renvoie la valeur PId de l'instance de processus proprement dite,
(SENDER) E´ METTEUR: renvoie la valeur PId du processus emettant´ le dernier signal utilise.´
PId; les expressions OFFSPRING et PARENT donnent la valeur NULL.
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 ambiguit¨ e´ les signaux aux instances. En fait, comme
moins que celle-ci ne puisse | tre determin´ ee´ sans ambiguit¨ e.´
avec les autres. Pour y parvenir, il faut souvent prevoir´ certains types de processus d'initialisation. Ces processus,
Il convient de noter d'autres points importants concernant la creation´ de processus:
Fascicule X.2 -- Rec. Z.100 -- Annexe D 19
bloc;
|
operations´ exterieures´ d'elimination´ de processus en employant un signal special´ |
d'elimination.´ A la reception´ |
du signal |
La relation entre les processus createurs´ et les processus cre´ es´ peut et^re represent´ ee´ dans un diagramme de
D.3.8.2 Etats
fait sortir le processus de l'etat´ et lui fait accomplir une succession donnee´ d'actions. Un signal qui est arrive´ et a entra| ne´ une transition a et´ e´ <<absorbe>>´ et cesse d'exister.
En LDS/PR, un etat´ est represent´ e´ par le mot cle´ STATE suivi du nom de l'etat.´ La specification´ de l'etat´ se
abreg´ ee´ indiquant que les entrees´ pour les mises en reserve´ suivantes et les transitions correspondantes doivent | tre interpret´ ees´ pour chaque etat.´
|
Le mot cle´ NEXTSTATE (E´ TAT SUIVANT), suivi du nom de l'etat,´ est utilise´ pour indiquer l'etat´ La figure D-3.8.6 donne un exemple partiel en LDS/PR. |
qui suit. On |
|
suivant. Par commodite,´ pour simplifier le dessin ou faciliter la comprehension,´ le m| me etat´ |
peut appara| tre plusieurs fois |
qui resulterait,´ de la fusion de toutes les apparitions multiples du m| me etat.´ Les figures D-3.8.7 et D-3.8.8 donnent des exemples de cette situation. Dans la figure D-3.8.7 b), on utilise un symbole d'etat´ comme lien avec l'etat´ principal portant le m| me nom, lorsqu'il est mentionne´ dans le symbole d'etat´ suivant. Dans la figure D-3.8.8 un etat´ est represent´ e´ par des symboles multiples n'ayant chacun qu'un sous-ensemble des entrees´ (ou des mises en reserve).´
Les diagrammes a) et b) de la figure D-3.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'entrees´ (et de mises en reserve)´ associes´ sont indiques.´
transition), il est indique´ comme un etat´ sans entree´ ni mise en reserve´ associee.´ Un commentaire du symbole d'etat´
suivant se ref´ erant´ au symbole d'etat´ ameliorera´ la clarte,´ notamment lorsqu'ils apparaissent sur des pages differentes.´
La figure D-3.8.8 utilise les apparitions multiples d'un etat´ pour constituer l'ensemble total d'entrees´ (et de mises en reserve).´ Chaque apparition de l'etat´ est indiquee´ uniquement avec un sous-ensemble de ces entrees.´
20 Fascicule X.2 -- Rec. Z.100 -- Annexe D
conscient de l'existence d'occurrences multiples. Pour eviter´ ce malentendu, les etats´ n'indiquant qu'un
|
d'autres etats´ avec leurs entrees´ et mises en reserve´ associ Des apparitions multiples peuvent | tre utilisees´ |
associees,´ comme indique´ dans la figure D-3.8.8. pour attirer l'attention du lecteur sur certains aspects (par |
Au cours d'une transition un processus ne sait pas explicitement quel signal d'entree´ a occasionne´ la transition.
signal donne).´ Dans la figure D-3.8.9, la t| che T1 ne s'accomplit qu'en cas de reception´ de I1. Toutefois, la t| che T2 s'accomplit en cas de reception´ de I2 ou de I3. S'il importe que T2 sache quel signal d'entree´ a et´ e´ recu,¸ il est souhaitable de concevoir le processus comme l'illustre la figure D-3.8.10.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 21
22 Fascicule X.2 -- Rec. Z.100 -- Annexe D