5i' D.3.10 Traitement des donnees D.3.10.1 Declarations de variables Les variables sont locales a une instance de processus, ce qui signifie que toutes les variables ont une et une seule instance de processus. Seule l'instance de processus proprietaire peut modifier la valeur des variables. Les variables declarees dans la figure D-3.10.1 sont locales a chaque instance de processus P; elles ne peuvent dont | tre atteintes et modifiees que par chaque instance de processus P (chaque instance de processus peut avoir acces a sa propre copie de variables ou modifier celle-ci). Figure D-3.10.1 [T24.100] (a traiter comme tableau MEP), p. 1 Une variable peut | tre initialisee immediatement apres la declaration, comme indique dans la figure D-3.10.2. Figure D-3.10.2 [T25.100] (a traiter comme tableau MEP), p. 2 Le LDS permet deux manieres d'initialiser des variables. Il est possible de declarer une valeur initiale pour toutes les vari- ables d'une certaine sorte en utilisant l'instruction DEFAULT dans la definition de type de donnees (voir le S 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 figure D-3.10.2. S'il existe a la fois un enonce DEFAULT et une initialisation lors de la declaration, c'est cette derniere qui prevaut. Si une variable n'est pas initialisee, sa valeur initiale est consideree comme <> dans le systeme. Naturellement, la notation abregee de l'initialisation de variables indiquee dans la figure D-3.10.2 n'est utilisable que pour des variables simples ou pour des types de donnees permettant une notation concrete compacte pour les variables (on trouvera un autre exemple dans la figure D-3.10.3). Figure D-3.10.3 [T26.100] (a traiter comme tableau MEP), p. 3 La figure D-3.10.3 montre que la sorte Struct a une notation concrete abregee indiquant une valeur de structure. Dans le cas d'un generateur de tableaux, il est suggere d'initialiser expli- citement les variables en simulant une expression <> dans la cha | ne de transition initiale du processus (voir la figure D-3.10.4). Figure D-3.10.4 [T27.100] (a traiter comme tableau MEP), p. 4 D.3.10.2 Variables revelees/visualisees Deux processus peuvent echanger des informations par d'autres moyens que des signaux. Un processus peut avoir acces a la valeur d'une variable possedee par un autre processus gr | ce a l'operation VIEW (visualiser). Il existe cependant plusieurs regles a appliquer: - les deux processus doivent appartenir au m | me bloc; - le processus executant l'operation VIEW doit specifier l'identificateur de la variable visualisee dans la definition de visibilite; - le processus revelant la variable doit la declarer avec l'attribut REVEALED (revele); - 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 processus de revelation par un acces ordinaire. Etant donne que le processus de visualisation ne possede pas la variable visualisee, il ne peut en modifier la valeur. Naturellement, la valeur visualisee peut | tre affectee a une variable que possede lui-m | me le processus effectuant les visual- isations. L'utilisateur du LDS peut trouver que la definition des vari- ables revelees/visualisees offre une maniere facile de specifier la communication entre deux processus. Cependant, plusieurs problemes peuvent se poser dans la mise en oeuvre des systemes ainsi specifies et la presente section a pout but d'aider les utilisa- teurs a eviter ou a surmonter de tels problemes. Decrire des systemes du LDS qui ont mis en oeuvre une valeur revelee/visualisee est moins difficile, car les problemes auront ete surmontes dans la mise en oeuvre de sorte et qu'il sera possible de mettre en concor- dance la solution choisie avec le LDS. Dans le reste de la presente section, on admet que le processus R (Revelateur) possede et revele des variables et que le processus V (Visualisateur) se rapporte a ses variables dans sa definition de visualisation. Une tentative de visualiser des variables du processus V avant la creation du processus R aboutit en LDS a une erreur. L'utilisateur peut eviter ce probleme de deux manieres: - soit en s'assurant que l'instance de procesus revelatrice R est creee 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 revelees/visualisees avant que R ait ete cree et ait initialise les variables pertinentes. Dans le premier cas, une maniere simple d'y parvenir consiste a faire de R l'ascendant (ou anc | tre) de V (comme dans l'exemple de la figure D-3.10.5), ou d'admettre que R soit cree en m | me temps que le systeme (creation implicite). Dans le second cas, on peut obtenir que la transition pertinente en V ne puisse | tre declenchee que par un signal de R. Les variables de R ne peuvent | tre visualisees apres l'arr | t de R. Toute tentative de visualiser des donnees serait alors une erreur en LDS. L'utilisateur peut eviter ce probleme de deux manieres: - 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. La premiere solution presente l'inconvenient pour l'auteur de la mise en oeuvre que R n'a pas libere les donnees stockees qu'elle utilisait. On trouvera dans la figure D-3.10.5 un exemple de variables revelees/visualisees. D.3.10.3 Valeurs exportees/importees Un processus peut declarer <> une ou plusieurs de ses variables, ce qui a pour effet que tous les autres processus <> 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, la valeur obtenue par l'expression d'importation peut differer de la valeur obtenue gr | ce a l'acces ordinaire par le proprietaire, m | me si ces deux operations sont effectuees au m | me moment. 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. 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 utilisees comme parametres reels de la sortie, de l'appel de procedure, de la con- struction de creation. Des expressions PId sont utilisees dans la partie TO de la construction de sortie. Les expressions des con- structions d'options et de selections (evaluees statistiquement) devraient | tre des sortes de donnees predefinies. Dans une expression, il peut y avoir des termes fondamentaux (c'est-a-dire des termes ne contenant que des representations de valeurs con- stantes) et des termes comportant des variables. Le LDS a un ensemble predefini d'operateurs infixes. Ces operateurs peuvent | tre utilises pour n'importe quel type de donnees et ils sont les seuls operateurs infixes autorises. Pour ces operateurs, les regles de priorite sont definies et ne peuvent | tre modifiees. Les operateurs infixes predefinis sont les suivants: =>, OR, XOR, AND, IN, /=, =, >, <, <=, >=, +, -, //, *, /, MOD, REM Le LDS offre en outre les operateurs predefinis: -, NOT qui sont des operateurs predefinis unaires. Lorsque l'on utilise des operateurs predefinis, il faut veiller a appliquer les regles de priorite car ces operateurs, etant predefinis independamment du domaine d'application, pour- raient donner lieu a des confusions. A titre d'exemple, admettons le newtype et l'expression de la figure D-3.10.6. Compte tenu des regles de priorite de multiplica- tion et d'addition, on evalue l'expression comme A = >((B*C) + D). Mais cela est different de la priorite de AND et OR et un tel changement peut | tre une cause de confusion. De plus, ce type de changement peut aboutir a des axiomes incoherents et rendre non valable la specification du LDS. Figure D-3.10.6 [T28.100] (a traiter comme tableau MEP), p. 6 Tous les autres operateurs definis par l'utilisateur sont des fonctions qui doivent | tre utilisees dans la notation prefixe. Les deux operateurs VIEW et IMPORT ont une semantique particuliere, expliquee dans les paragraphes precedents. 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 La necessite de mesurer le temps et de demander une temporisa- tion dans un systeme est satisfaite par des temporisateurs et un ensemble d'operations executees sur ceux-ci. Dans le modele LDS, les temporisateurs (<>) sont des metaprocessus capables d'emettre des signaux vers le processus sur demande. L'utilisation de temporisateurs doit | tre declaree dans leur definition, dans le cadre des definitions de processus. Les operations <> et <> servent a activer les temporisa- teurs. L'operation SET implique qu'une temporisation doit se pro- duire a un moment specifie et l'operation RESET annule la tempori- sation specifiee. (A noter qu'une operation SET comporte implicite- ment une operation RESET pour toute temporisation provenant de ce temporisateur qui n'aurait pas expire.) La construction <> 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. Les listes d'expressions peuvent | tre specifiees dans la construction <> pour permettre de reinitialiser une instance particuliere de l'instance de temporisateur ayant les m | mes valeurs. La definition du temporisateur doit comprendre la liste des identificateurs de reference de sortes correspondant aux sortes utilisees dans les expressions de set/reset. On trouvera un exemple d'instruction <> 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 <>, qui represente le moment actuel. L'expression du delai demande devrait | tre une expression temporelle. Le temps est une sorte predefinie, <> de la sorte <>. La possibilite de recevoir une temporisation est specifiee a l'aide du nom de temporisateur dans une entree, comme indique dans la figure D-3.11.1. Figure D-3.11.1, p. 7 Il est possible de definir des synonymes pour indiquer les durees souhaitees. Apres avoir choisi les unites de temps et de duree, l'utilisateur peut definir les synonymes necessaires pour representer les durees, comme indique dans la figure D-3.11.2. Figure D-3.11.2 [T29.100] (a traiter comme tableau MEP), p. 8 Dans la Recommandation, il est indique que l'armement d'un temporisateur sur un moment deja <> est autorise. Cette decision a ete prise afin de faciliter la simulation de systemes; toutefois, une operation de ce genre pourrait donner une specification manquant de clarte et devrait donc | tre evite. D.3.12 Emploi de qualificatifs En LDS, des qualificatifs sont utilises pour faire reference 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 specifie mais lorsque l'on se refere a ce point en dehors de l'occurrence qui le definit, il peut | te necessaire de disposer d'un identificateur compose d'un qualifica- tif et de ce nom. Cela est valable egalement pour l'utilisation de definitions differees: l'occurrence definissante utilise le nom pour reperer la definition; la definition differee utilise un nom qualifie pour specifier son contexte. Dans la figure D-3.12.1, on trouvera un exemple d'emploi de qualificatifs pour un processus qui peut recevoir deux signaux differents ayant m | me nom mais des identificateurs differents. La premiere entree se rapporte a un type de signal defini au niveau du bloc; la seconde entree se refere a un type de signal defini dans la definition de processus. Dans la seconde entree, la qualifica- tion pourrait | tre omise car lorsque des identificateurs ne sont pas qualifies, il faut se referer a la definition la plus interne. Figure D-3.12.1 [T30.100] (a traiter comme tableau MEP), p. 9 D.3.13 Syntaxe de noms En LDS, des noms peuvent consister soit en un mot unique soit en une liste de mots separes par des delimiteurs (espaces ou caracteres de contr | le). Cette seconde possibilite permet d'obtenir une specification plus lisible lorsque l'on utilise des noms d'une certaine longueur, particulierement en LDS/GR, car les symboles graphiques ont une taille limitee. On trouvera dans la figure D-3.13.1 certains exemples de noms composes de plusieurs mots. Figure D-3.13.1, p. 10 Chaque fois que l'emploi de plusieurs mots dans un nom donne lieu a une ambiguite (voir les exemples de la figure D.3.13.2), les delimiteurs entre deux mots doivent | tre remplaces par un caractere de soulignement (<< _>>). La cha | ne de caracteres obte- nue par la transformation de delimiteurs en soulignements designe toujours le m | me nom; ainsi, par exemple, BUSY SUB designe le m | me nom que BUSY _SUB. On trouvera dans la figure D-3.13.3 certains exemples d'emploi sans ambiguite de noms. Figure D-3.13.2 [T31.100] (a traiter comme tableau MEP), p. 11 Figure D-3.13.3 [T32.100] (a traiter comme tableau MEP), p. 12 Il importe de noter que le caractere de soulignement peut aussi | tre employe dans des noms comme caractere de continuation, pour permettre de repartir des noms sur plus d'une ligne. Dans ce cas, on peut aussi designer un nom contenant un caractere de soulignement suivi par un ou plusieurs delimiteurs en eliminant le soulignement et les delimiteurs. On trouvera dans la figure D-3.13.4 des exemples de designations differentes pour le m | me nom. Figure D-3.13.4 [T33.100] (a traiter comme tableau MEP), p. 13 D.4 Structuration et affinage de systemes LDS D.4.1 Considerations generales Le present chapitre traite de certaines techniques et de con- structions du LDS qui permettent une specification descendante des systemes de grande taille. En general, les termes <> et <> sont appliques a ces techniques avec les significa- tions suivantes: - subdivision: il s'agit de diviser une partie du systeme en parties plus petites dont le comportement global est equivalent a la partie non subdivisee. Ce terme peut s'appliquer a des blocs (structures en nouveaux sous-blocs, canaux et sous-canaux), a des canaux (structures en blocs, nouveaux canaux et sous-canaux) et a des processus (structures en service); - affinage: adjonction de nouveaux details aux fonctions d'un systeme. Considere a partir de l'environnement, l'affinage d'un systeme a pour resultat un enrichissement de son comportement car plusieurs types de signaux et d'informations peu- vent | tre traites. On notera que la structure interne d'une partie d'un systeme renseigne plus precisement sur la structure, mais pas necessairement sur le comportement du systeme. Il est theoriquement possible de distinguer l'aspect d'une representation plus detaillee du comportement (par exemple, le traitement d'un nouveau signal) de l'aspect d'une structure plus detaillee (couvrant, par exemple, a la fois la structure des parties et celle du comportement du systeme), mais dans la pratique ces deux aspects sont generalement confondus: ainsi, des details supplementaires sur la structure du systeme en eclairent egalement le comportement. La structure minimale d'un systeme en LDS est decrite dans le chapitre 2 de la Recommandation: un systeme consiste en un ensemble de blocs relies par des canaux et ces blocs contiennent des pro- cessus. Les concepts applicables a la subdivision en plusieurs niveaux de details et d'affinage signaux sont traites dans le chapitre 3 de la Recommandation. Ces concepts ne sont pas necessaires dans le cas de systemes qui n'ont pas a | tre affines. D.4.2 Criteres de subdivision On nomme subdivision la technique qui consiste a fragmenter une representation d'un systeme d'un niveau de detail eleve en elements d'un maniement facile. Le processus de subdivision ajoute une structure a un systeme. Parmi les criteres qui entra | nent la subdivision de representation d'un systeme, on peut citer les suivants: a) definir des blocs ou des processus qui, par leurs dimensions, facilitent la comprehension du systeme; 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; e) reutiliser des representations preexistantes (par exemple un systeme de signalisation). Les criteres qui seront effectivement adoptes dependront de plusieurs facteurs et notamment du degre de precision requis. Etant donne que la relation entre les niveaux depend des criteres de subdivision choisis, il importe de specifier clairement ces criteres afin de faciliter la comprehension de la representation. L'usager decide des criteres de 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 On peut subdiviser un bloc en un ensemble de blocs et de canaux pratiquement de la m | me facon qu'on subdivise un systeme en blocs et en canaux. En LDS/GR, cela est represente a l'aide d'un diagramme de sous-structure de bloc. On en trouvera dans la figure D-4.3.1. Dans le premier diagramme de cette figure, le diagramme du bloc B1 contient une reference a sa sous-structure. Dans le second diagramme, il existe un diagramme de sous-structure pour le bloc B1. Le symbole de bloc rattache au canal C2 par une ligne en taits discontinus, dans le premier diagramme, represente une reference a la sous-structure de canal C2 (voir le S D.4.5). En LDS/PR, la subdivision d'un bloc est representee par un ensemble de definitions comprises entre les mots-cles SUBSTRUCTURE et ENDSUBSTRUCTURE a l'interieur de la definition du bloc. Les definitions d'une sous-structure de bloc sont les m | mes que celles de la definition de systeme; de plus, la specification des connexions entre canaux et sous-canaux doit | tre effectuee comme indique dans la figure D-4.3.2. Figure D-4.3.1, p. 14 Figure D-4.3.2 [T34.100] (a traiter comme tableau MEP), p. 15 La specification des processus et celle d'une sous-structure de bloc peuvent coexister a l'interieur d'une definition de bloc. Dans ce cas, les processus du bloc representent le comportement de ce bloc pour un niveau de precision donne; d'autres processus internes des definitions des sous-blocs representeront d'une maniere plus detaillee le m | me comportement. On trouvera au S D.4.7 (figure D-4.7.1) un exemple de bloc decrit tant en fonction de processus que de sous-structures. S'il n'existe pas de processus a l'interieur d'un bloc mais seulement une sous-structure de bloc et que celle-ci ne fait pas l'objet d'un reperage, il existe en LDS/GR une notation abregee 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 sous-structure. Gr | ce a cette notation, l'exemple de la figure D-4.3.1 peut | tre trace comme dans la figure D-4.3.3. Figure D-4.3.3, p. 16 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 auxi- liaire appele <> representant cette structure generale est decrit au S D.4.4. A moins qu'il ne s'agisse de l'affinage de signaux, les regles suivantes doivent | tre observees dans le processus de subdivi- sion. 1) les listes de signaux des sous-canaux relies a un canal d'entree ne doivent pas comporter de nouveaux 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; 2) les listes de signaux des sous-canaux (par exem- ple C1.1 et C1.2) relies a une voie de sortie (par exemple C1) ne peuvent comporter de nouveaux noms de signaux; ces listes de sig- naux 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 processus peut | tre redefinie dans l'un ou l'autre des nouveaux sous-blocs. Deuxiemement, de nouveaux processus peuvent | tre definis dans les sous-blocs de telle maniere que l'interface reste sans changement; 4) des definitions de donnees du bloc ascendant se trouvent dans ses sous-blocs, de sorte que chacun de ceux-ci peut utiliser un type de donnees defini dans le bloc ascendant sans avoir a le redefinir; 5) si un type de donnees defini dans le bloc ascen- dant 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 sous-blocs. Il faut eviter une redefinition servant uniquement a caracteriser un sous-bloc car un lecteur peut la negliger, supposant que l'ancienne definition est valable. Dans certains cas cependant, il convient de proceder a une telle redefinition, notamment lorsqu'il s'agit d'un affinage du comportement. Il faut veiller a souligner cette redefinition par une annotation appropriee. D.4.4 Diagramme d'arbre de blocs Le diagramme d'arbre de blocs represente la structure d'un systeme en fonction de ces blocs et sous-blocs. Ce diagramme vise a donner au lecteur un apercu de la structure totale d'un sous-systeme. Le diagramme est un arbre hierarchique de symboles de blocs et de lignes de subdivision comme indique dans la figure D-4.4.1. Figure D-4.4.1, p. 17 Il est preferable que le diagramme soit trace de telle maniere que tous les symboles de blocs aient la m | me dimension. Ainsi, les blocs du m | me niveau de subdivision apparaissent comme a un niveau uniforme dans le diagramme. Si le diagramme est trop grand pour tenir sur une seule page, il doit | tre divise en diagrammes d'arbre de blocs <> 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 racine le systeme, soit coupe de maniere que les blocs encore subdivises apparaissent comme non subdivises. Les blocs, la ou le diagramme original a ete coupe, apparaissent comme des racines dans les diagrammes indiquant la 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 trouver ou continuent les diagrammes, il convient d'inserer des references en utilisant le symbole commentaire. 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'element independant dont l'environnement se compose des deux blocs qu'il relie. Considerant le canal de cette maniere, on peut exprimer sa structure au moyen de blocs, de canaux et de processus. En LDS/GR, la subdivision de canaux est representee a l'aide de diagrammes de sous-structure de canaux, 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 diagramme ressemble au diagramme de systeme (sauf en ce qui concerne la connexion des blocs). Toutes les directives donnees au S D.4.3 sont valables pour le diagramme de sous-structure de canaux. Dans le diagramme d'interaction de blocs ou apparaissent les canaux subdivises, il faut faire reference au diagramme de sous-structure de canaux decrivant la subdivision. Figure D-4.5.1, p. 19 En LDS/PR, la forme est semblable a celle de la definition de sous-structure de blocs; la seule difference est que, dans l'instruction CONNECT, les sous-canaux d'extremite sont raccordes a des blocs exterieurs (B1 et B2 dans la figure D-4.5.2) et non a des canaux exterieurs. L'import/export des valeurs est autorise entre un bloc et une sous-structure de canaux. Cela permet une representation directe du modele OSI dans laquelle les communications de couches homologues sont modelisees par l'echange de signaux et les communications de couches contigues par des valeurs partagees. D.4.6 Representation du systeme en cas de subdivision Lorsqu'un systeme est represente sous la forme d'un ensemble de blocs interconnectes par des canaux et que l'on exprime le com- portement de chaque bloc au moyen d'un ou de plusieur processus, nous nous trouvons en presence d'une representation sur un seul niveau. Ceci revient a dire que nous pouvons voir tous les elements de la representation au m | me niveau. Nous introduisons, avec la subdivision une relation hierarchique entre les differents documents. Le document qui en resulte represente la structure du systeme lorsque le systeme se compose de n blocs. Un autre document peut presenter le systeme compose d'un ensemble different de blocs, dont certains proviennent des blocs du document precedent (certains blocs du document precedent ont ete remplaces par les sous-blocs resultant de la subdivision des blocs). Ce nouveau document doit | tre rapporte au precedent docu- ment. Mais pour obtenir une representation complete du systeme, il ne suffit pas d'etablir des rapports entre les documents, il faut egalement les organiser de telle sorte qu'il soit possible d'acceder a la representation du systeme par niveaux, en commencant par une vue d'ensemble generale pour passer ensuite a des representations de plus en plus detaillees. Ceci exige le regroupe- ment des differents documents afin de representer le systeme a differents niveaux. On ne devrait pas trouver les m | mes elements a tous les niveaux. La representation du systeme au premier niveau peut se composer de representations des blocs et des canaux, a l'exclusion des processus qui decrivent le comportement de chaque bloc. A un niveau inferieur, on peut souhaiter inclure la representation du comportement de cer- tains blocs, mais pas de celui d'autres blocs. Le niveau de representation le plus bas (c'est-a-dire la representation la plus detaillee) devrait representer integralement les comportements de tous les blocs, c'est-a-dire l'ensemble complet des processus qui expriment ce comportement. Figure D-4.5.2 [T35.100] (a traiter comme tableau MEP), p. 20 L'observation de l'arborescence de blocs souleve plusieurs reflexions. En premier lieu, l'arborescence a toujours une et seulement une racine, qui est le systeme. Il en est ainsi de m | me lorsque le systeme represente se compose de plusieurs blocs depuis le debut. Dans l'arborescence, ces blocs sont representes au niveau 1. Le nom du systeme peut suffire pour constituer le bloc qui sert de racine. On peut appliquer 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 niveau. Ceci peut | tre d | a un nombre inegal de subdivisions sur les blocs de l'arborescence. Le nombre de subdivisions depend de plusieurs fac- teurs, dont la plupart relevent de l'appreciation subjective de la personne chargee d'elaborer les specifications, et du concepteur. Pour que des blocs feuille ne soient pas subdivises de nouveau, le LDS n'exige qu'une chose, a savoir que leur comporte- ment soit entierement specifie (c'est-a-dire que son attitude puisse | tre representee par les definitions des processus). Par consequent, un bloc feuille doit contenir au moins un processus associe. Lorsqu'un systeme est represente a plusieurs niveaux d'abstraction, nous pouvons representer le systeme au niveau de notre choix. Le choix d'un niveau donne exige que les blocs soient examines a ce m | me niveau, que leurs processus associes et tous les blocs feuille soient examines a des niveaux superieurs avec leurs processus associes (voir la figure D-4.6.1). Il est souvent pratique de choisir differents niveaux a differentes fins, par exemple un niveau <> pour la presentation et un niveau plus detaille pour la mise en oeuvre. Figure D-4.6.1, p. 21 La representation d'un systeme a un certain niveau peut | tre incomplete dans la mesure ou certains des blocs de 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 suivantes: - il se peut que notre representation ait atteint un certain <> de precision, represente 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!); - nous voulons considerer la representation du systeme a un certain niveau de precision; nous choisissons donc le niveau de representation qui correspond au mieux aux abstractions que nous cherchons. On notera que dans certains cas un niveau donne de representation peut | tre constitue de documents a differents niveaux d'abstraction. La representation d'une partie du systeme au niveau 2 peut | tre tres detaillee, tandis que celle d'une autre partie au niveau 4 peut demeurer abstraite. Cela signifie qu'en choisissant une representation au niveau 3, l'on peut obtenir une representation tres detaillee de certaines parties et une simple vue d'ensemble d'autres parties; - la methodologie de representation et conception peut permettre a chaque niveau d'avoir une signification precise. Ainsi le niveau 1 correspond a la specification, le niveau 2 four- nit la structure generale du systeme, le niveau 3 la structure des modules (<>, fonctions de logiciel), le niveau 4 donne la structure detaillee (planches imprimees, procedures, modules de logiciel). Dans ce cas, le lecteur choisit un niveau donne en fonc- tion 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. D.4.6.1 Sous-ensemble de subdivision coherent En plus de la specification totale du systeme et de celle qui est donnee par niveaux, le LDS comporte une notion de <>. Celle-ci peut | tre consideree comme une specification de niveau unique dans laquelle tous les blocs peuvent | tre pris d'un niveau quelconque de la structure d'un systeme, etant entendu: - qu'un bloc peut | tre choisi pour faire partie de la representation coherente du systeme s'il peut etre considere comme un bloc feuille (ou bien il est un bloc feuille ou bien tous les processus necessaires a la representation 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 descen- dants; - 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 ete pris, son ascen- dant doit aussi l' | tre, au moins en ce qui concerne les parties definissant les donnees et les signaux. Dans les cas ou certains canaux ont ete subdivises, chacun etant considere comme un systeme, il faut fournir la specification de chacun de ces <>. Leur specification consiste en docu- ments du m | me type que ceux de la representation de systemes usu- els. Il convient d'ajouter des notations referant ces systemes a la specification du systeme principal auquel ils appartiennent. Ainsi, en un sens, on peut considerer ces canaux subdivises comme des systemes internes. Chacun de ces systemes peut avoir plusieurs niveaux de representation et comportera en outre des systemes internes si certains des canaux contenus sont subdivises plus avant. D.4.7 Affinage Le mecanisme d'affinage a ete introduit dans le LDS pour <> les signaux de niveau inferieur au niveau superieur d'abstraction et permettre la specification descendante du com- portement du systeme. L'affinage permet a l'utilisateur de subdiviser des signaux en sous-signaux, ce qui donne une structure hierarchique comme dans le cas des blocs et des sous-blocs. Cela signifie qu'a l'interieur d'une definition de signal, il 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 <> de signaux pour une definition de signal. L'affinage est etroitement lie a la subdivision de bloc car seuls les signaux transportes par un canal relie a un bloc 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 generes 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 considere comme implicitement bidirectionnel). On trouvera dans la figure D-4.7.1 un exemple d'affinage. Cet exemple represente un systeme dans lequel un processus d'un bloc emet des fichiers de textes vers un processus d'un autre bloc. Au niveau d'affinage le plus eleve, 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 certain nombre d'enregistrements emis par un signal (signal sr) et que le recepteur doit repondre (signal nr) apres absorption de chaque enregistrement. L'emetteur enverra un signal fin de fichier a la fin de l'operation. Dans cet exemple, au niveau d'affinage le plus eleve, 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 d'element a element dans laquelle seul le nom du signal change. Cette possibilite est generalement impliquee lorsque l'on veut que chaque niveau soit entierement comprehensible en soi-m | me. (Il peut | tre commode d'adapter le nom d'un signal a son contexte.); - 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 generique <> est divise en <>, <> et <>; - transformation avec algorithme: le signal ori- ginel est transforme en un ensemble de signaux qui declenchent un algorithme afin de fournir l'information originelle. Figure D-4.7.1, p. 22 D.4.7.1 Sous-ensemble d'affinage coherent Lorsque l'affinage est applique a une specification de systeme, la notion de sous-ensemble de subdivision coherent est limitee de maniere a eviter des communications avec differents sig- naux entre differents niveaux d'affinage. Dans ce cas, on dit que la definition de systeme contient plusieurs sous-ensembles d'affinage coherents. Si un sous-ensemble d'affinage coherent con- tient un processus communiquant avec des sous-signaux, ce processus ne peut communiquer avec le signal ascendant et l'autre extremite de la liaison de communication doit communiquer avec les m | mes sous-signaux. D.4.7.2 Transformation entre signaux et sous-signaux L'utilisateur peut avoir besoin de decrire la transformation entre differents niveaux d'affichage a des fins de simulation ou pour contr | ler le comportement du systeme indifferent au niveau de precision. Il peut le faire de maniere informelle a l'aide de processus LDS supplementaire decrivant la transformation dynamique d'un signal en ses sous-signaux ou vice versa. Dans la figure D-4.7.2, deux processus sont introduits pour decrire la transformation appliquee dans la figure D-4.7.1. Un pro- cessus d'affinage definit la maniere dont le signal de niveau eleve est <> en un ensemble de signaux au niveau inferieur suivant. Un processus d'extraction decrit la transformation inverse. Figure D-4.7.2, p. 23 D.5 Concepts supplementaires D.5.1 Macros La construction macro permet de traiter les repetitions et/ou de structurer une description. Elle comprend une definition de macro contenant une partie de specification LDS qui peut | tre referencee (appel de macro) en d'autres endroits d'une specification de systeme. La definition de macro peut | tre donnee en tous les endroits ou des definitions de donnees sont autorisees. Cependant, le nom de macro n'a pas de portee. Ainsi, une macro definie dans un bloc peut | tre referencee en dehors de celui-ci. En LDS/PR, il est possible d'employer une definition de macro pour remplacer toute sequence d'unites lexicales. Cette possibilite differe des definitions de macro en LDS/GR qui ne peuvent remplacer que des collections d'unites syntaxiques. Pour mettre en concordance des documents en LDS/GR et en LDS/PR contenant des macros, il faut appliquer les restrictions ci-apres a l'utilisation de macros LDS/PR: 1) Une macro ne peut remplacer qu'une ou plusieurs des constructions syntaxiques suivantes (qui correspondent a des symboles LDS/GR): depart etat entree condition de validation signal continu mise en reserve instruction d'action instruction de terminaison 2) Des parametres formels de macros ne peuvent pas | tre utilises en des endroits determinant le type de la construc- tion en LDS/PR. Cela signifie qu'ils ne peuvent | tre utilises la ou sont employes les mots cles du LDS/PR. De m | me, des parametres reels ne devraient pas contenir de mot cle correspondant a des sym- boles du LDS/GR: START, STATE, PROCEDURE, INPUT, TASK, OUTPUT, DECISION, CREATE, STOP, PROVIDED, CALL, COMMENT, JOIN, RETURN, SAVE ou OPTION. 3) Chaque enonce de la definition de macro doit pouvoir | tre atteint a partir d'au moins un acces d'entree de macro. En LDS/PR, la macro a toujours au plus un acces d'entree et un acces de sortie, de sorte qu'il est necessaire d'employer des eti- quettes et des liaisons pour representer en LDS/PR une macro LDS/GR ayant plus d'un acces d'entree ou de sortie. Si la macro doit | tre appelee en plus d'un endroit, les etiquettes devront | tre communiquees sous la forme de parametres. En LDS/GR, il y a deux moyens differents de representer les acces d'entree et de sortie d'une definition de macro. L'utilisateur peut soit tracer un cadre pour la macro et relier a celui-ci les acces d'entree et de sortie, soit utiliser explicite- ment des symboles d'acces d'entree et d'acces de sortie (le cadre de macro etant facultatif). L'exemple de la figure D-5.1.1 illustre en LDS/GR et en LDS/PR une macro ayant deux acces d'entree et deux acces de sortie. (Dans cet exemple, les acces d'entree et de sortie sont relies au cadre de macro.) 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. La figure D-5.1.3 illustre deux definitions de macro qui definissent un mecanisme de synchronisation. A noter l'emploi du parametre pseudo-formel MACROID, qui sert a rendre uniques des noms d'etat. Le m | me exemple est repris dans la figure D-5.1.4 en ce qui concerne l'emploi de symboles d'acces d'entree et d'acces de sortie. Dans le cas de macros embo | tees, c'est-a-dire lorsqu'il existe un ou plusieurs appels de macros a l'interieur d'une definition de macro, il convient de noter que l'expansion des mac- ros exterieures n'affecte pas celle des macros interieures. Plus precisement, l'expansion de macros embo | tees doit | tre consideree comme si l'expansion d'une macro devrait | tre terminee avant le debut de l'expansion d'appels eventuels de macros interieures. Figure D-5.1.1, p. 24 Figure D-5.1.2, p. 25 Figure D-5.1.3, p. 26 Figure D-5.1.4, p. 27 D.5.2 Systemes generiques En LDS, ilest possible de definir differents systemes dans une seule specification a l'aide des parametres de systemes. Ceux-ci ont une valeur indefinie qui peut | tre donnee exterieurement pour obtenir une definition de systeme specifique correspondant aux besoins des utilisateurs. En fait, les parametres de systeme sont des synonymes externes et peuvent | tre utilises a tout endroit ou un synonyme peut l' | tre. Naturellement, avant d'interpreter un systeme, il faut affecter une valeur a tous les synonymes externes. La figure D-5.2.1 donne quelques exemples valables de l'utilisation de synonymes externes. Figure D-5.2.1 [T36.100] (a traiter comme tableau MEP), p. 28 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 specifiee par une expression booleenne que l'on doit pouvoir evaluer statiquement, avant l'interpretation du systeme. Elle est 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 generales La notion de service vise a offrir la possibilite de sub- diviser une definition de processus sans introduire de parallelisme. Chaque service peut | tre considere comme une <> offerte par le processus. C'est une definition de pro- cessus partielle representant un <> du pro- cessus. Ce <> constitue un element du comporte- ment du processus global. En consequence, l'emploi du concept de service est une maniere de structurer un processus. 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 decrire separement. Ces parties peuvent | tre des <> d'une fonction offerte par le systeme. Ainsi, gr | ce au concept de service, on peut isoler une fonction de systeme en decrivant un ensemble de services subordonnes dans un ou plusieurs processus. Figure D-5.3.1, p. 29 A noter que le langage LDS ne possede pas de facilites permet- tant de composer une fonction de systeme en choisissant des ser- vices de plusieurs processus. C'est a l'utilisateur qu'il appartient de proceder a cette composition, entierement en dehors du langage. Un service, etant isole d'autres services et decrit comme une machine a etat fini dans son propre espace d'etat, peut | tre developpe 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 different car plusieurs processus fonctionnent en parallele et ne peuvent partager (lire et ecrire) des donnees sans un echange de signaux complique. Il convient de noter que la structuration d'un processus en services ne signifie pas que ce processus dispara | tra entierement. Cela signifie seulement que le corps de processus, decrivant le comportement du processus, a ete entierement remplace par plusieurs corps de service. Il restera au niveau du processus les parametres formels, des declarations et des definitions for- melles. En plus de ceux-ci, certaines definitions et declarations locales peuvent | tre reprises dans les definitions de service. Une definition de service se compose des elements suivants, dont certains sont facultatifs: - nom de service; - ensemble de signaux d'entree valides: liste d'identificateurs de signaux definissant des signaux qui peuvent | tre recus par le service; - definitions de procedure: specification des procedures qui sont locales au service. On peut aussi utiliser une reference de procedure; - definitions de donnees: specification de newtypes, syntypes et generateurs definis par l'utilisateur et locaux au service; - definitions variables: declaration de variables, locales au service. Ces variabls ne peuvent | tre revelees ou exportees vers d'autres processus (les mots cles REVEALED et EXPORTED ne sont pas admis). Pour chaque variable declaree, il faut specifier l'identificateur de sa sorte. Une valeur initiale peut | tre specifiee en option; - definitions de visibilite: declaration des iden- tificateurs de variables qui peuvent servir a obtenir les valeurs des variables appartenant a d'autres processus. Pour chaque identi- ficateur de variables, la sorte de variable doit | tre specifiee; - definitions d'import: specification d'identificateurs de variables appartenant a d'autres processus, que le service desire importer. Pour chaque identificateur, la sorte de variable doit | tre specifiee; - definitions de temporisateur: voir le S D.3.11; - definitions de macro: voir le S D.5.1; - corps de service: specification du comportement reel du service en ce qui concerne les etats, les entrees, ls sor- ties, les t | ches, etc. Compare a un corps de processus, un corps de service peut aussi contenir l'emission et la reception de sig- naux prioritaires (S D.5.3.2). En LDS/GR, une definition de service est representee a l'aide d'un diagramme de service. Celui-ci comprend les elements 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 ser- vice; - references de procedure: symbole de procedure contenant un nom de procedure representant une procedure, locale au service et definie separement; - diagramme de macro: voir les directives du S D.5.1; - graphe de service: specification du comportement reel du service en ce qui concerne les etats, les entrees, les sor- ties, les t | ches, etc. Compare au graphe de processus, un graphe de service peut aussi contenir l'emission et la reception de sig- naux prioritaires (S D.5.3.2). Un exemple de concept de service est donne dans la figure D-5.3.2 pour le processus simple <> (Timer). Ce processus est structure en deux services qui sont reperes et definis en deux diagrammes de service (voir la figure D-5.3.3). Figure D-5.3.2, p. 30 L'acheminement du signal <> transportant un signal prioritaire (S 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 S D.10. 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 <>. 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 S D.5.3.3.1). L'exemple suivant est une illustration des consequences de l'emploi de signaux prioritaires. L'exemple est explique sans l'emploi du modele <>. Le diagramme de sequencement (voir la figure D-5.3.5) est obtenu de l'interaction entre les services du processus <> decrit au S D.10.2. Figure D-5.3.5 et legende, p. 33 Le tableau contient a la fois les signaux en provenance ou a destination de l'environnement du processus et les signaux priori- taires entre les services. Les fleches de signaux (de haut en bas) indique comment les signaux sont 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 <> 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 <>, commence avant l'activation d'une transition par un signal ordinaire, par exemple <>, malgre l'ordre inverse de celui de sa mise en file d'attente. La transition activee par le signal <> deconnecte la ligne d'abonne, ce qui signifie que l'appel suivant (signal <>) sera immediatement rejete. Dans le diagramme de sequencement ci-apres, nous avons la m | me situation mais le diagramme n'utilise pas de signaux priori- taires. Il y a interfonctionnement entre les services et les sig- naux ordinaires. Figure D-5.3.6 et legende, p. 34 Nous pouvons voir que l'ordre des transitions a ete modifie par rapport a la figure D-5.3.5. L'appel suivant arrive avant la deconnexion de la ligne d'abonne, ce qui signifie que l'appel ne sera pas immediatement rejete. D.5.3.3 Transformation Le service et le signal prioritaire sont des notions complementaires car ils sont composes (modelises) a partir de notions plus fondamentales du LDS, comme le processus et le signal. Pour pouvoir interpreter semantiquement le service et le signal de priorite, ils doivent se transformer a nouveau en ces notions de base. Normalement, cette transformation ne doit pas | tre executee 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. Apres la transformation, les services ont disparu et sont remplaces par une definition de processus etendue qui peut | tre interpretee semantiquement. La transformation a defini le comporte- ment. 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 priori- taires qui ne sont pas traites dans l'exemple suivant de transfor- mation d'etats. Dans bien des cas, de nombreux etats du processus <> ne sont pas pertinents et l'espace d'etat peut | tre reduit. Cela est traite dans l'exemple suivant, tire du S D.10.2. Dans le processus <>, nous avons 4 services: <>, <>, <> et <>. Le nombre d'etats est de 10, 5, 3 et 2, c'est-a-dire 20 au total. Appliquant a ces services les regles pour la transformation d'etats, nous avons 300 etats (10*5*3*2) dans le 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. . | | | . | | | . | | | . | | | Beaucoup de ces combinaisons ne sont pas pertinentes car une ligne d'abonne ne pourra jamais | tre utilisee a la 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` ne peuvent | tre combines qu'avec un seul etat des `B _subscriber actions` c'est-a-dire `B _IDLE`. Cela signifie en outre que les 5 etats de `B _subscriber actions` ne peuvent | tre combines qu'avec un seul etat de `A _subscriber actions` (A _IDLE). Le nombre d'etats per- tinents est donc de (10*1*3*2) + (1*5*3*2) = 90. Une reduction de l'espace d'etat, comme dans l'exemple ci-dessus, depend du cas dont il s'agit et ne peut faire l'objet de regles generales formelles, applicables en vue d'une transformation automatique. Cependant, si la transformation est executee manuelle- ment, il est probable que l'espace d'etat peut | tre reduit. Ainsi, lorsque l'on compare la complexite d'un processus concu sans services a celle du m | me processus subdivise en services, il con- vient d'utiliser le processus a espace d'etat reduit pour obtenir une bonne base de comparaison. Dans la plupart des cas, le recours aux services permettra de reduire considerablement le nombre des etats. D.5.3.3.2 Transformation de transitions La Recommandation contient des regles specifiques applicables a la transformation de transitions. L'exemple qui 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 La figure D-5.3.9 est un diagramme synoptique d'etat pour les deux services. Les transitions sont numerotees de 1 a 7. Figure D-5.3.9, p. 37 Si l'on applique les regles formelles de transformation d'etats et de transitions, on obtient pour le processus le diagramme synoptique d'etat ci-apres. Aucun signal prioritaire n'est utilise, de sorte qu'il n'est pas necessaire de diviser plus avant les etats en etats preliminaires et etats principaux et cela n'est donc pas indique. Figure D-5.3.10, p. 38 Le nombre d'etats ne peut | tre reduit et le graphe de pro- cessus est represente dans la figure D-5.3.11. Les noms d'etats du graphe de processus correspondent aux multiplets de noms de la fig- ure D-5.3.10. Exemple - IS.IR correspond a IDLE _S.IDLE _R. Figure D-5.3.11 et legende, p.