delim @@
| 5i'
D.3.10 Traitement des donnees´
D.3.10.1 Declarations´ de variables
seule instance de processus. Seule l'instance de processus proprietaire´ peut modifier la valeur des variables.
dont | tre atteintes et modifiees´ que par chaque instance de processus P (chaque instance de processus peut avoir
les variables d'une certaine sorte en utilisant l'instruction DEFAULT dans la definition´ de type de donnees´ (voir le § D.6.4.5). Dans ce cas, l'initialisation est valable pour toutes les variables de cette sorte.
Par ailleurs, il est possible d'initialiser chaque variable d'une certaine sorte par une valeur comme indique´ dans la
Fascicule X.2 -- Rec. Z.100 -- Annexe D 1
qui prevaut.´ Si une variable n'est pas initialisee,´ sa valeur initiale est consider´ ee´ comme <<indefinie>>´ dans le
2 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Naturellement, la notation abreg´ ee´ de l'initialisation de variables indiquee´ dans la figure D-3.10.2 n'est utilisable
variables (on trouvera un autre exemple dans la figure D-3.10.3).
Dans le cas d'un gen´ erateur´ de tableaux, il est sugger´ e´ d'initialiser explicitement les variables en simulant une expression <<While construct>> dans la cha| ne de transition initiale du processus (voir la figure D-3.10.4).
Fascicule X.2 -- Rec. Z.100 -- Annexe D 3
|
D.3.10.2 Variables rev´ el´ ees/visualis´ ees Deux processus peuvent echanger´ des |
ees´ des informations par d'autres moyens que des signaux. Un processus peut |
|
-- -- |
-- -- |
les deux processus doivent appartenir au m| me bloc; le processus executant´ l'operation´ VIEW doit specifier´ l'identificateur de la variable visualisee´ dans |
dans la |
|||
|
definition´ |
de visibilite;´ |
|||||
|
-- -- |
le processus rev´ elant´ la variable doit la declarer´ avec l'attribut REVEALED (rev´ el´ e);´ l'identificateur de sorte (ou identificateur de syntype) de la declaration´ de variables et de la definition´ |
de |
visibilite´ doivent | tre les m| mes.
La valeur que le processus de visualisation obtient par l'operation´ VIEW est la m| me que celle qu'obtient le
|
effectuant les visualisations. L'utilisateur du LDS peut trouver que la definition´ |
des variables rev´ el´ ees/visualis´ ees´ |
offre une maniere facile de |
concordance la solution choisie avec le LDS.
-- soit en s'assurant que l'instance de procesus rev´ elatrice´ R est cre´ ee´ et a initialise´ les variables pertinentes avant l'instance de processus de visualisation V;
|
-- soit en s'assurant que V ne passe pas dans des transitions utilisant des variables rev´ el´ ees/visualis´ ees´ |
avant |
implicite). Dans le second cas, on peut obtenir que la transition pertinente en V ne puisse | tre declench´ ee´ que par un signal de R.
-- soit en n'utilisant en aucun cas l'arr| t de R;
-- soit en s'assurant que V n'ignore pas que R doit s'arr| ter et ne fait pas d'autres tentatives de visualiser les donnees´ pertinentes.
stockees´ qu'elle utilisait.
|
On trouvera dans la figure D-3.10.5 un exemple de variables rev´ el´ ees/visualis´ ees. D.3.10.3 Valeurs exportees/import´ ees´ 4 Fascicule X.2 -- Rec. Z.100 -- Annexe D |
ees.´ |
Un processus peut declarer´ <<exportables>> une ou plusieurs de ses variables, ce qui a pour effet que tous les autres processus <<quel que soit le bloc auquel ils appartiennent>> peuvent importer une copie de la valeur de la variable sur demande. Le processus importateur doit declarer´ la variable dans sa definition´ d'importation.
Lorsque le processus exportateur effectue une exportation, la valeur de la variable est copiee´ dans une variable implicite. Un processus d'importation obtient, au moyen de l'expression d'importation, la valeur de cette copie. Ainsi,
proprietaire,´ m| me si ces deux operations´ sont effectuees´ au m| me moment.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 5
|
On trouvera un exemple dans la figure D-3.10.5. |
Figure D-3.10.5, p. 5 |
Dans la figure D-3.10.5, le processus P1 est cense´ | tre l'ascendant des processus P2 et P3; en consequence,´
l'identificateur d'instance de processus des expressions IMPORT et VIEW est indique´ par l'attribut PARENT.
6 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
D.3.10.4 Expressions Des expressions d'un processus en LDS peuvent servir de texte formel pour des decisions,´ |
options, selections,´ |
t| |
ches, signaux continus, conditions de validation et construction d'initialisation. Des expressions sont egalement´
PId sont utilisees´ dans la partie TO de la construction de sortie. Les expressions des constructions d'options et de selections´ (evalu´ ees´ statistiquement) devraient | tre des sortes de donnees´ pred´ efinies.´ Dans une expression, il peut y
et des termes comportant des variables.
Le LDS a un ensemble pred´ efini´ d'operateurs´ infixes. Ces operateurs´ peuvent | tre utilises´ pour n'importe quel
|
definies´ =>, Le --, |
et ne peuvent | tre modifiees.´ Les operateurs´ infixes pred´ efinis´ sont les suivants: =>, OR, XOR, AND, IN, /=, =, >, <, <=, >=, +, --, //, *, /, MOD, REM Le LDS offre en outre les operateurs´ pred´ efinis:´ --, NOT |
qui sont des operateurs´ pred´ efinis´ unaires.
de multiplication et d'addition, on evalue´ l'expression comme A = >((B*C) + D). Mais cela est different´ de la priorite´
des axiomes incoherents´ et rendre non valable la specification´ du LDS.
Tous les autres operateurs´ definis´ par l'utilisateur sont des fonctions qui doivent | tre utilisees´ dans la notation prefixe.´
prec´ edents.´ En tout cas, ils renvoient une valeur d'une certaine sorte, qui peut | tre un autre operande´ dans une expression.
D.3.11 Expresssion du temps en LDS
|
temporisateurs et un ensemble d'operations´ execut´ ees´ sur ceux-ci. Dans le modele LDS, les temporisateurs (<<Timers>>) sont des metaprocessus´ capables d'emettre´ |
des signaux |
vers le processus sur demande. L'utilisation de temporisateurs doit | tre declar´ ee´ dans leur definition,´ dans le cadre
temporisation specifi´ ee.´ (A noter qu'une operation´ SET comporte implicitement une operation´ RESET pour toute
Fascicule X.2 -- Rec. Z.100 -- Annexe D 7
temporisation provenant de ce temporisateur qui n'aurait pas expire.)´
La construction <<set>> contient l'expression temporelle du delai´ requis, le nom du temporisateur dont il s'agit et, en option, une liste d'expressions. Cette liste specifie´ des valeurs qui seront comprises dans le signal du temporisateur de m| me ordre.
8 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Les listes d'expressions peuvent | tre specifi´ ees´ dans la construction <<reset>> pour permettre de reinitialiser´
La definition´ du temporisateur doit comprendre la liste des identificateurs de ref´ erence´ de sortes correspondant aux sortes utilisees´ dans les expressions de set/reset.
On trouvera un exemple d'instruction <<set>> dans la figure D-3.11.1.
Dans la construction set, il faut specifier´ un temps absolu. Le temps relatif est transforme´ en valeur de temps absolue par l'adjonction de la fonction primitive <<NOW>>, qui represente´ le moment actuel. L'expression du delai´
demande´ devrait | tre une expression temporelle. Le temps est une sorte pred´ efinie,´ <<herit´ ee>>´ de la sorte <<reel>>.´
|
comme indique´ dans la figure D-3.11.1. |
Figure D-3.11.1, p. 7 |
|
temps et de duree,´ l'utilisateur peut definir´ |
les synonymes necessaires´ pour representer´ les durees,´ |
comme indique´ |
Fascicule X.2 -- Rec. Z.100 -- Annexe D 9
pourrait donner une specification´ manquant de clarte´ et devrait donc | tre evit´ e.´
|
D.3.12 Emploi de qualificatifs En LDS, des qualificatifs sont utilises´ pour faire ref´ erence´ |
a des points d'une specification,´ |
lorsque le nom ne |
determine´ pas uniquement un point donne.´ Naturellement, pour les definitions´ d'un point, seul le nom doit | tre specifi´ e´
identificateur compose´ d'un qualificatif et de ce nom.
|
Cela est valable egalement´ pour l'utilisation de definitions´ differ´ ees:´ l'occurrence |
l'occurrence definissante´ |
utilise le nom pour |
Dans la figure D-3.12.1, on trouvera un exemple d'emploi de qualificatifs pour un processus qui peut recevoir
Dans la seconde entree,´ la qualification pourrait | tre omise car lorsque des identificateurs ne sont pas qualifies,´ il faut
D.3.13 Syntaxe de noms
En LDS, des noms peuvent consister soit en un mot unique soit en une liste de mots separ´ es´ par des delimiteurs´
limitee.´ On trouvera dans la figure D-3.13.1 certains exemples de noms composes´ de plusieurs mots.
10 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Figure D-3.13.1, p. 10
nom; ainsi, par exemple, BUSY SUB designe´ le m| me nom que BUSY SUB. On trouvera dans la figure D-3.13.3
Fascicule X.2 -- Rec. Z.100 -- Annexe D 11
continuation, pour permettre de repartir´ des noms sur plus d'une ligne. Dans ce cas, on peut aussi designer´ un nom
|
delimiteurs.´ On trouvera |
On trouvera dans la figure D-3.13.4 des exemples de designations´ differentes´ |
pour le m| me nom. |
12 Fascicule X.2 -- Rec. Z.100 -- Annexe D
D.4.1 Considerations´ gen´ erales´
Le present´ chapitre traite de certaines techniques et de constructions du LDS qui permettent une specification´
ces techniques avec les significations suivantes:
(structures´ en service);
de signaux et d'informations peuvent | tre traites.´
representation´ plus detaill´ ee´ du comportement (par exemple, le traitement d'un nouveau signal) de l'aspect d'une
|
mais dans la pratique ces deux aspects sont gen´ eralement´ confondus: ainsi, des details´ |
supplementaires´ |
sur la |
consiste en un ensemble de blocs relies´ par des canaux et ces blocs contiennent des processus.
affines.´
b) etablir´ une certaine correspondance avec les divisions effectives du logiciel et/ou du materiel;´
c) utiliser les subdivisions fonctionnelles naturelles;
d) reduire´ au minimum l'interaction entre les blocs;
precision´ requis.
subdivision mais certaines restrictions s'appliquent afin de garantir une representation´ correcte en LDS. Les paragraphes qui suivent traitent de ces restrictions.
D.4.3 Subdivision des blocs
Fascicule X.2 -- Rec. Z.100 -- Annexe D 13
On peut subdiviser un bloc en un ensemble de blocs et de canaux pratiquement de la m| me facon¸ qu'on subdivise
On en trouvera dans la figure D-4.3.1. Dans le premier diagramme de cette figure, le diagramme du bloc B1 contient
bloc B1. Le symbole de bloc rattache´ au canal C2 par une ligne en taits discontinus, dans le premier diagramme,
En LDS/PR, la subdivision d'un bloc est represent´ ee´ par un ensemble de definitions´ comprises entre les mots-cles´
sous-canaux doit | tre effectuee´ comme indique´ dans la figure D-4.3.2.
14 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Figure D-4.3.1, p. 14 Fascicule X.2 -- Rec. Z.100 -- Annexe D 15
definition´ de bloc. Dans ce cas, les processus du bloc representent´ le comportement de ce bloc pour un niveau de
le m| me comportement. On trouvera au § D.4.7 (figure D-4.7.1) un exemple de bloc decrit´ tant en fonction de processus que de sous-structures.
fait pas l'objet d'un reperage,´ il existe en LDS/GR une notation abreg´ ee´ permettant de simplifier le diagramme. Cette notation permet d'embo| ter des blocs en considerant´ le cadre du bloc exterieur´ comme impliquant le cadre de
16 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Figure D-4.3.3, p. 16 Fascicule X.2 -- Rec. Z.100 -- Annexe D 17
Chaque bloc provenant de la subdivision d'un bloc peut | tre lui-m| me subdivise,´ ce qui donne une structure arborescente hierarchique´ de blocs et de leurs sous-blocs. Un diagramme auxiliaire appele´ <<diagramme d'arbre de bloc>> representant´ cette structure gen´ erale´ est decrit´ au § D.4.4.
de subdivision.
signaux; ces listes de signaux doivent comprendre tous les signaux de la liste du canal initial (pour les canaux bidirectionnels, il faut tenir compte de la liste des trajets entrants). Ainsi, dans l'exemple de la figure D-4.3.1, C2.1 et C2.2 transportent sur les trajets d'entree´ tous les signaux de L2. En outre, aucun des signaux transportes´ par C2.1 ne peut appara| tre sur le trajet d'entree´ de C2.2;
exemple C1) ne peuvent comporter de nouveaux noms de signaux; ces listes de signaux doivent comprendre tous les noms de signaux du canal initial. Ainsi, L1.1 et L1.2 contiennent tous les noms de signaux de L1. Les listes L1.1 et L1.2 peuvent contenir les m| mes identificateurs de signaux;
3) si le bloc original contient des processus, il existe deux options. Tout d'abord, une copie de chaque
4) des definitions´ de donnees´ du bloc ascendant se trouvent dans ses sous-blocs, de sorte que chacun de
5) si un type de donnees´ defini´ dans le bloc ascendant est redefini´ avec le m| me nom dans un sous-bloc, la nouvelle definition´ s'applique au sous-bloc definissant´ tandis que l'ancienne definition´ reste valable pour les autres
par une annotation appropriee.´
D.4.4 Diagramme d'arbre de blocs
|
Le diagramme est un arbre hierarchique´ 18 Fascicule X.2 -- Rec. Z.100 -- Annexe D |
D |
de symboles de blocs et de lignes de subdivision comme indique´ dans la |
Figure D-4.4.1, p. 17 Fascicule X.2 -- Rec. Z.100 -- Annexe D 19
diagramme. Si le diagramme est trop grand pour tenir sur une seule page, il doit | tre divise´ en diagrammes d'arbre de blocs <<partiels>> comme indique´ dans la figure D-4.4.2.
Il est souvent utile de subdiviser un diagramme d'arbre de blocs en diagrammes partiels.
La division en plusieurs diagrammes partiels s'effectue de telle sorte que le premier diagramme, ayant pour
subdivision.
Figure D-4.4.2, p. 18
Si des diagrammes partiels sont utilises´ et qu'il n'est pas evident´ de savoir si un bloc est subdivise´ ailleurs et de
|
D.4.5 Subdivision des canaux Un canal peut | tre subdivise´ |
independamment´ des blocs qu'il relie. |
Cela permet la representation´ |
du |
comportement du canal en question lorsqu'il achemine des signaux. Il est parfois necessaire´ de representer´ le comportement du canal afin d'obtenir une representation´ exacte du parcours d'un signal.
Pour ce faire, on examine le canal en tant qu'el´ ement´ independant´ dont l'environnement se compose des deux
de processus.
comme indique´ dans la figure D-4.5.1. (l'exemple represente´ la sous-structure du canal C2 de la figure D-4.3.1).
Un diagramme de sous-structure de canaux montre comment un canal est subdivise´ en sous-composants. Ce
directives donnees´ au § D.4.3 sont valables pour le diagramme de sous-structure de canaux.
20 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
diagramme de sous-structure de canaux decrivant´ |
la subdivision. |
Figure D-4.5.1, p. 19 |
L'import/export des valeurs est autorise´ entre un bloc et une sous-structure de canaux. Cela permet une
l'echange´ de signaux et les communications de couches contigues¨ par des valeurs partagees.´
l'on exprime le comportement de chaque bloc au moyen d'un ou de plusieur processus, nous nous trouvons en
|
representation´ au m| me niveau. Nous introduisons, avec la subdivision une relation hierarchique´ entre les differents´ |
documents. Le document qui en |
proviennent des blocs du document prec´ edent´ (certains blocs du document prec´ edent´ ont et´ e´ remplaces´ par les sous-blocs resultant´ de la subdivision des blocs). Ce nouveau document doit | tre rapporte´ au prec´ edent´ document.
comportement de chaque bloc. A un niveau inferieur,´ on peut
Fascicule X.2 -- Rec. Z.100 -- Annexe D 21
souhaiter inclure la representation´ du comportement de certains blocs, mais pas de celui d'autres blocs. Le
22 Fascicule X.2 -- Rec. Z.100 -- Annexe D
les definitions´ des canaux aux blocs bien que cela ne soit pas exige,´ sauf si les blocs ont des processus associes.´
L'observation des feuilles de cette arborescence inspire une seconde remarque: elles ne sont pas toutes au m| me
d'elaborer´ les specifications,´ et du concepteur.
processus). Par consequent,´ un bloc feuille doit contenir au moins un processus associe.´
Fascicule X.2 -- Rec. Z.100 -- Annexe D 23
(voir la figure D-4.6.1).
|
la presentation´ et un niveau plus detaill´ e |
e´ pour la mise en oeuvre. |
Figure D-4.6.1, p. 21 |
ce niveau n'ont pas de processus associes.´
|
On parle de niveaux de representation´ et de selection´ |
d'un certain niveau de representation´ |
pour les raisons |
-- il se peut que notre representation´ ait atteint un certain <<niveau>> de precision,´ represent´ e´ par ce niveau de representation´ (dans ce cas, les blocs de ce niveau sont des blocs feuille; ils ne sont pas complets car ils demandent un supplement´ de travail!);
donc le niveau de representation´ qui correspond au mieux aux abstractions que nous cherchons. On notera que dans
niveau 4 peut demeurer abstraite. Cela signifie qu'en choisissant une representation´ au niveau 3, l'on peut obtenir une
niveau 3 la structure des modules (<<racks>>, fonctions de logiciel), le niveau 4 donne la structure detaill´ ee´ (planches imprimees,´ procedures,´ modules de logiciel). Dans ce cas, le lecteur choisit un niveau donne´ en fonction de son propre besoin, et l'on notera que la methode´ permet d'eviter´ les differences´ entre les niveaux de precision´ des parties qui constituent un niveau donne´ de representation.´
24 Fascicule X.2 -- Rec. Z.100 -- Annexe D
D.4.6.1 Sous-ensemble de subdivision coherent´
de son comportement lui sont associes);´
-- que, si un bloc est choisi, tous les blocs obtenus par la subdivision de son bloc ascendant doivent | tre compris, soit directement soit par l'inclusion de leurs descendants;
-- que tous les documents definissant´ les signaux passant dans le canal qui relie un bloc de la representation´
doivent | tre fournis. Selon la strategie´ de subdivision choisie, cela peut impliquer qu'une fois qu'un bloc a et´ e´ pris, son ascendant doit aussi l'| tre, au moins en ce qui concerne les parties definissant´ les donnees´ et les signaux.
D.4.7 Affinage
Le mecanisme´ d'affinage a et´ e´ introduit dans le LDS pour <<cacher>> les signaux de niveau inferieur´ au niveau
est possible de definir´ un ensemble de nouveaux signaux qui sont appeles´ signaux affines,´ ou sous-signaux du signal defini.´ De m| me que l'arbre de bloc pour une definition´ de bloc, on peut tracer, pour plus de clarte,´ un <<arbre>> de signaux pour une definition´ de signal.
subdivise´ peuvent | tre affines.´ Cela signifie qu'un signal figurant dans la liste d'un canal peut | tre remplace´ par ses sous-signaux lors de la subdivision du bloc qui y est connecte.´ Les sous-canaux correspondants gen´ er´ es´ par la subdivision du bloc devront specifier´ des sous-signaux dans leurs listes de signaux.
Lorsqu'un signal est defini´ comme devant | tre achemine´ par un canal, le canal transportera automatiquement tous les sous-signaux de ce signal, m| me si certains des sous-signaux se dirigent dans le sens oppose´ (dans ce cas, le canal est consider´ e´ comme implicitement bidirectionnel). On trouvera dans la figure D-4.7.1 un exemple d'affinage.
d'un autre bloc. Au niveau d'affinage le plus elev´ e,´ on obtient ceci par l'emission´ de signaux qui representent´ chacun un fichier de textes (signal sf). Au niveau d'affinage inferieur,´ on peut specifier´ que le fichier de textes se compose d'un
exemple, au niveau d'affinage le plus elev´ e,´ les processus de B1 et de B2 communiquent en utilisant le signal sf; au niveau immediatement´ inferieur,´ les processus de B11 et de B21 communiquent en utilisant les signaux sr, nr et eof.
Voici certains cas reels´ dans lesquels la notion d'affichage peut s'appliquer:
-- transformation de nom: un signal affine´ devient un autre signal portant un nom different.´ C'est une
-- transformation par division: il s'agit d'une transformation d'un signal en plusieurs autres, dans laquelle un signal est divise´ en plusieurs signaux par souci de precision.´ A titre d'exemple, un signal gen´ erique´ <<Alarme>> est
Fascicule X.2 -- Rec. Z.100 -- Annexe D 25
divise´ en <<Register Alarm>>, <<Central Processor Alarm>> et <<Subscriber Alarm>>;
-- transformation avec algorithme: le signal originel est transforme´ en un ensemble de signaux qui declenchent´ un algorithme afin de fournir l'information originelle.
26 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
D.4.7.1 |
Sous-ensemble d'affinage coherent´ |
Figure D-4.7.1, p. 22 |
un sous-ensemble d'affinage coherent´ contient un processus communiquant avec des sous-signaux, ce processus ne peut communiquer avec le signal ascendant et l'autre extremit´ e´ de la liaison de communication doit communiquer avec les m| mes sous-signaux.
D.4.7.2 Transformation entre signaux et sous-signaux
sous-signaux ou vice versa.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 27
Dans la figure D-4.7.2, deux processus sont introduits pour decrire´ la transformation appliquee´ dans la
de signaux au niveau inferieur´ suivant. Un processus d'extraction decrit´ la transformation inverse.
28 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Figure D-4.7.2, p. 23 Fascicule X.2 -- Rec. Z.100 -- Annexe D 29
D.5 Concepts supplementaires´
D.5.1 Macros
La construction macro permet de traiter les rep´ etitions´ et/ou de structurer une description. Elle comprend une definition´ de macro contenant une partie de specification´ LDS qui peut | tre ref´ erenc´ ee´ (appel de macro) en d'autres
Cependant, le nom de macro n'a pas de portee.´ Ainsi, une macro definie´ dans un bloc peut | tre ref´ erenc´ ee´ en dehors de celui-ci.
En LDS/PR, il est possible d'employer une definition´ de macro pour remplacer toute sequence´ d'unites´ lexicales.
syntaxiques.
Pour mettre en concordance des documents en LDS/GR et en LDS/PR contenant des macros, il faut appliquer
1) Une macro ne peut remplacer qu'une ou plusieurs des constructions syntaxiques suivantes (qui
|
depart´ etat´ entree´ condition de validation signal continu mise en reserve´ instruction d'action instruction de terminaison |
STATE, PROCEDURE, INPUT, TASK, OUTPUT, DECISION, CREATE, STOP, PROVIDED, CALL, COMMENT, JOIN, RETURN, SAVE ou OPTION.
macro.
|
d'entree´ ou de sortie. Si la macro doit | tre appelee´ |
en plus d'un endroit, les etiquettes´ devront | tre communiquees´ |
sous |
Cela signifie que dans la specification´ principale en LDS/PR (figure D-5.1.2), existent les branchements et les etiquettes´ correspondants. A noter que l'etiquette´ sera probablement differente´ pour chaque appel de macro.
30 Fascicule X.2 -- Rec. Z.100 -- Annexe D
La figure D-5.1.3 illustre deux definitions´ de macro qui definissent´ un mecanisme´ de synchronisation. A noter
definition´ de macro, il convient de noter que l'expansion des macros exterieures´ n'affecte pas celle des macros interieures.´ Plus precis´ ement,´ l'expansion de macros embo| tees´ doit | tre consider´ ee´ comme si l'expansion d'une macro devrait | tre terminee´ avant le debut´ de l'expansion d'appels eventuels´ de macros interieures.´
Fascicule X.2 -- Rec. Z.100 -- Annexe D 31
|
Figure D-5.1.1, p. 24 Figure D-5.1.2, p. 25 |
32 Fascicule X.2 -- Rec. Z.100 -- Annexe D
|
Figure D-5.1.3, p. 26 Figure D-5.1.4, p. 27 |
Fascicule X.2 -- Rec. Z.100 -- Annexe D 33
specifique´ correspondant aux besoins des utilisateurs.
externes. La figure D-5.2.1 donne quelques exemples valables de l'utilisation de synonymes externes.
Le LDS offre deux constructions complementaires´ qui permettent des choix plus puissants conditionnes´ par des synonymes externes:
-- construction SELECT: selection´ conditionnelle d'une partie de specification.´ La condition est specifi´ ee´
|
choisie lorsque l'expression est VRAIE; -- construction ALTERNATIVE: permet la selection´ |
conditionnelle d'une partie de specification,´ |
entre |
deux options ou davantage. Elle ne peut | tre utilisee´ que pour choisir differentes´ transitions dans le corps de processus, de procedures´ ou de services.
D.5.3 Services
D.5.3.1 Considerations´ gen´ erales´
parallelisme.´ Chaque service peut | tre consider´ e´ comme une <<fonction>> offerte par le processus. C'est une definition´ de processus partielle representant´ un <<sous-comportement>> du processus. Ce <<sous-comportement>> constitue un el´ ement´ du comportement du processus global. En consequence,´ l'emploi du concept de service est une
34 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Il y a de nombreuses raisons de structurer un processus, par exemple en vue de gerer´ la complexite´ et d'ameliorer´ la lisibilite.´ Mais la subdivision constitue aussi un moyen d'isoler certaines parties d'un processus et de les
un ou plusieurs processus.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 35
Figure D-5.3.1, p. 29
peut | tre developp´ e´ et modifie´ sans que cela n'affecte d'autres services. Toutefois, il convient de relever que les services d'un processus ont souvent des donnees´ communes, ce qui signifie qu'ils peuvent influer les uns sur les autres par suite de manipulations de donnees.´
Le comportement d'un processus n'etat´ pas modifie´ lorsqu'il est subdivise´ en services, les services representent´
seulement une autre description du m| me comportement. On peut naturellement decider´ au moment de la conception, de modeliser´ le comportement en plusieurs processus au lieu d'un seul. Toutefois, cela donnerait un comportement
echange´ de signaux complique.´
Il convient de noter que la structuration d'un processus en services ne signifie pas que ce processus dispara| tra
|
declarations´ et des definitions´ formelles. En plus de ceux-ci, certaines definitions´ et declarations´ locales Une definition´ de service se compose des el´ ements´ suivants, dont certains sont facultatifs: -- nom de service; -- ensemble de signaux d'entree´ valides: liste d'identificateurs de signaux definissant´ |
locales peuvent | tre des signaux qui |
|
|
peuvent | tre recus¸ par le service; |
|
-- definitions´ de procedure:´ |
specification´ des procedures´ |
qui sont locales au service. On peut aussi utiliser |
-- definitions´ de donnees:´ specification´ de newtypes, syntypes et gen´ erateurs´ definis´ par l'utilisateur et locaux au service;
-- definitions´ variables: declaration´ de variables, locales au service. Ces variabls ne peuvent | tre rev´ el´ ees´
ou exportees´ vers d'autres processus (les mots cles´ REVEALED et EXPORTED ne sont pas admis). Pour chaque variable declar´ ee,´ il faut specifier´ l'identificateur de sa sorte. Une valeur initiale peut | tre specifi´ ee´ en option;
specifi´ ee;´
36 Fascicule X.2 -- Rec. Z.100 -- Annexe D
service desire´ importer. Pour chaque identificateur, la sorte de variable doit | tre specifi´ ee;´
Fascicule X.2 -- Rec. Z.100 -- Annexe D 37
-- definitions´ de temporisateur: voir le § D.3.11;
-- definitions´ de macro: voir le § D.5.1;
-- corps de service: specification´ du comportement reel´ du service en ce qui concerne les etats,´ les entrees,´
reception´ de signaux prioritaires (§ D.5.3.2).
el´ ements´ suivants:
-- un symbole de cadre facultatif: symbole de forme rectangulaire qui contient tous les autres symboles;
-- l'en-t| te de service: le mot cle´ SERVICE suivi par l'identificateur de service. L'en-t| te de service est place´ dans l'angle superieur´ gauche du cadre;
|
-- -- |
une numerotation´ de page facultative (placee´ dans l'angle superieur´ droit); des symboles de texte: un symbole de texte est utilise´ pour contenir des definitions´ de donnees,´ |
de |
variables, de visibilite,´ d'import et de temporisateur qui sont locales au service;
-- ref´ erences´ de procedure:´ symbole de procedure´ contenant un nom de procedure´ representant´ une procedure,´ locale au service et definie´ separ´ ement;´
-- diagramme de macro: voir les directives du § D.5.1;
-- graphe de service: specification´ du comportement reel´ du service en ce qui concerne les etats,´ les entrees,´ les sorties, les t| ches, etc. Compare´ au graphe de processus, un graphe de service peut aussi contenir l'emission´ et la reception´ de signaux prioritaires (§ D.5.3.2).
Un exemple de concept de service est donne´ dans la figure D-5.3.2 pour le processus simple <<temporisateur>> (Timer). Ce processus est structure´ en deux services qui sont reper´ es´ et definis´ en deux diagrammes de service (voir la figure D-5.3.3).
38 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Figure D-5.3.2, p. 30 Fascicule X.2 -- Rec. Z.100 -- Annexe D 39
L'acheminement du signal <<IR6>> transportant un signal prioritaire (§ D.5.3.2) constitue une interface interne entre les deux services.
Figure D-5.3.3, p. 31
Il convient de noter que, les actions (sorties) etant´ comrpises dans la transition de depart´ dans le premier service, aucune action n'est autorisee´ dans la transition de depart´ du second service.
On trouvera un autre exemple du concept de service au § D.10.
40 Fascicule X.2 -- Rec. Z.100 -- Annexe D
D.5.3.2 Signaux prioritaires
Un signal prioritaire est employe´ pour la communication entre deux transitions dans des services differents´ d'un processus lorsqu'aucun signal exterieur´ (provenant d'autres processus) ne peut | tre absorbe´ dans le laps de temps entre les transitions. Ainsi, les transitions sont <<concaten´ ees>>.´
La figure D-5.3.4 est une illustration de la concatenation´ des transitions lorsque des signaux prioritaires sont utilises.´
Figure D-5.3.4, p. 32
La construction permettant d'obtenir des signaux prioritaires utilisant la file d'atente d'entree´ ordinaire est decrite´
dans la Recommandation. Les signaux prioritaires, emis´ vers un etat´ preliminaire,´ peuvent | tre traites´ comme des signaux ordinaires et provoquent des transitions vers l'etat´ principal (voir aussi le § D.5.3.3.1).
Fascicule X.2 -- Rec. Z.100 -- Annexe D 41
L'exemple suivant est une illustration des consequences´ de l'emploi de signaux prioritaires. L'exemple est
Le diagramme de sequencement´ (voir la figure D-5.3.5) est obtenu de l'interaction entre les services du processus <<SUBSCRIBER LINE>> decrit´ au § D.10.2.
Figure D-5.3.5 et legende,´ p. 33
places´ dans la file d'attente. Les lignes verticales en traits epais´ indiquent comment l'execution´ des transitions s'ordonne dans le temps.
La sequence´ debute´ avec le signal <<CONGESTION>> en provenance du registre, ce qui signifie que l'appel doit | tre rejete.´ Cela signifie aussi le rejet immediat´ de l'appel suivant.
La figure montre qu'une transition, activee´ par un signal prioritaire, par exemple <<RESERVE FOR
42 Fascicule X.2 -- Rec. Z.100 -- Annexe D
signaux prioritaires. Il y a interfonctionnement entre les services et les signaux ordinaires.
Figure D-5.3.6 et legende,´ p. 34
|
avant la deconnexion´ D.5.3.3 Transformation |
de la ligne d'abonne,´ ce qui signifie que l'appel ne sera pas immediatement´ Transformation |
rejete.´ |
notions plus fondamentales du LDS, comme le processus et le signal. Pour pouvoir interpreter´ semantiquement´ le
transformation ne doit pas | tre execut´ ee´ par l'utilisateur, tout au moins manuellement, mais celui-ci doit naturellement en | tre conscient. Dans un outil de contr| le semantique´ du service, la transformation pourrait s'effectuer automatiquement.
peut | tre interpret´ ee´ semantiquement.´ La transformation a defini´ le comportement.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 43
|
D.5.3.3.1 Transformation d'etats´ La Recommandation donne des regles specifiques´ pour la transformation d'etats.´ Le resultat´ |
de ces regles est |
que le nombre d'etats´ du processus est le produit du nombre d'etats´ qui se trouvent dans les services.
En outre, l'emploi de signaux prioritaires doublera ce produit car chaque etat´ transforme´ est divise´ en un etat´
preliminaire´ et un etat´ principal.
Ce doublement du nombre des etats´ est d| aux signaux prioritaires qui ne sont pas traites´ dans l'exemple suivant de transformation d'etats.´
Dans bien des cas, de nombreux etats´ du processus <<transforme>>´ ne sont pas pertinents et l'espace d'etat´
peut | tre reduit.´ Cela est traite´ dans l'exemple suivant, tire´ du § D.10.2.
Dans le processus <<SUBSCRIBER LINE>>, nous avons 4 services: <<A subscriber actions>>, <<B
processus, ce qui signifie 300 multiplets de noms. La dimension du multiplet est de 4 (4 services). Les positions du multiplet sont arrangees´ selon la figure D-5.3.7.
Figure D-5.3.7, p. 35
Tous les noms d'etat´ possibles dans les differentes´ positions donnent 300 combinaisons.
Ex.<A IDLE, B IDLE, CONNECTED, NO ALARM>
<AWAIT CONN, B IDLE, CONNECTED, NO ALARM>
<AWAIT FIRST DIGIT, B IDLE, CONNECTED, NO ALARM>
. | | |
<AWAIT A ON HOOK 2, B IDLE, CONNECTED, NO ALARM>
<A IDLE, B RINGING, CONNECTED, NO ALARM>
<A IDLE, B CONVERSATION, CONNECTED, NO ALARM>
. | | |
<A IDLE, AWAIT B ON HOOK, CONNECTED, NO ALARM>
. | | |
. | | |
44 Fascicule X.2 -- Rec. Z.100 -- Annexe D
<AWAIT A ON HOOK 2, AWAIT B ON HOOK, SEIZED, ALARM>
fois pour l'abonne´ A et l'abonne´ B au cours du m| me appel. Cela signifie que les 10 etats´ des `A subscriber actions`
Fascicule X.2 -- Rec. Z.100 -- Annexe D 45
Une reduction´ de l'espace d'etat,´ comme dans l'exemple ci-dessus, depend´ du cas dont il s'agit et ne peut faire
transformation est execut´ ee´ manuellement, il est probable que l'espace d'etat´ peut | tre reduit.´ Ainsi, lorsque l'on
|
cas, le recours aux services permettra de reduire´ D.5.3.3.2 Transformation de transitions |
considerablement´ |
le nombre des etats.´ |
suit illustre les modalites´ de transformation. Le processus de cet exemple est une specification´ d'un protocole simple. Le processus est subdivise´ en deux services, emission´ (send) et reception´ (receive).
Figure D-5.3.8 et legende,´ p. 36 46 Fascicule X.2 -- Rec. Z.100 -- Annexe D
La figure D-5.3.9 est un diagramme synoptique d'etat´ pour les deux services. Les transitions sont numerot´ ees´
Figure D-5.3.9, p. 37
|
diviser plus avant les etats´ en etats´ |
preliminaires´ et etats´ principaux et cela n'est donc pas indique.´ Figure |
Figure D-5.3.10, p. 38 |
Le nombre d'etats´ ne peut | tre reduit´ et le graphe de processus est represent´ e´ dans la figure D-5.3.11. Les noms d'etats´ du graphe de processus correspondent aux multiplets de noms de la figure D-5.3.10.
Fascicule X.2 -- Rec. Z.100 -- Annexe D 47
Figure D-5.3.11 et legende,´ p. 48 Fascicule X.2 -- Rec. Z.100 -- Annexe D
Fascicule X.2 -- Rec. Z.100 -- Annexe D 49