.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP D.3.10 \fITraitement des donn\*'ees\fR .sp 1P .RT .sp 1P .LP D.3.10.1 \fID\*'eclarations de variables\fR .EF '% Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D'' .OF '''Fascicule\ X.2\ \(em\ Rec.\ Z.100\ \(em\ Annexe\ D %' .sp 9p .RT .PP 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 propri\*'etaire peut modifier la valeur des variables. .PP Les variables d\*'eclar\*'ees dans la figure\ D\(hy3.10.1 sont locales \*`a chaque instance de processus\ P; elles ne peuvent dont \* | tre atteintes et modifi\*'ees que par chaque instance de processus\ P (chaque instance de processus peut avoir acc\*`es \*`a sa propre copie de variables ou modifier celle\(hyci). .RT .LP .rs .sp 16P .ad r \fBFigure D\(hy3.10.1 [T24.100] \ \ (\*`a traiter comme tableau MEP), p. 1\fR .sp 1P .RT .ad b .RT .PP .sp 1 Une variable peut \* | tre initialis\*'ee imm\*'ediatement apr\*`es la d\*'eclaration, comme indiqu\*'e dans la figure\ D\(hy3.10.2. .LP .rs .sp 6P .ad r \fBFigure D\(hy3.10.2 [T25.100] \ \ (\*`a traiter comme tableau MEP), p. 2\fR .sp 1P .RT .ad b .RT .PP .sp 1 Le LDS permet deux mani\*`eres d'initialiser des variables. Il est possible de d\*'eclarer une valeur initiale pour toutes les variables d'une certaine sorte en utilisant l'instruction DEFAULT dans la d\*'efinition de type de donn\*'ees (voir le \(sc\ D.6.4.5). Dans ce cas, l'initialisation est valable pour toutes les variables de cette sorte. .PP Par ailleurs, il est possible d'initialiser chaque variable d'une certaine sorte par une valeur comme indiqu\*'e dans la figure\ D\(hy3.10.2. S'il existe \*`a la fois un \*'enonc\*'e DEFAULT et une initialisation lors de la d\*'eclaration, c'est cette derni\*`ere qui pr\*'evaut. Si une variable n'est pas initialis\*'ee, sa valeur initiale est consid\*'er\*'ee comme <> dans le syst\*`eme. .bp .PP Naturellement, la notation abr\*'eg\*'ee de l'initialisation de variables indiqu\*'ee dans la figure\ D\(hy3.10.2 n'est utilisable que pour des variables simples ou pour des types de donn\*'ees permettant une notation concr\*`ete compacte pour les variables (on trouvera un autre exemple dans la figure\ D\(hy3.10.3). .RT .LP .sp 1 .rs .sp 12P .ad r \fBFigure D\(hy3.10.3 [T26.100] \ \ (\*`a traiter comme tableau MEP), p. 3\fR .sp 1P .RT .ad b .RT .PP .sp 2 La figure D\(hy3.10.3 montre que la sorte Struct a une notation concr\*`ete abr\*'eg\*'ee indiquant une valeur de structure. Dans le cas d'un g\*'en\*'erateur de tableaux, il est sugg\*'er\*'e d'initialiser explicitement les variables en simulant une expression <> dans la cha\* | ne de transition initiale du processus (voir la figure\ D\(hy3.10.4). .LP .sp 1 .rs .sp 19P .ad r \fBFigure D\(hy3.10.4 [T27.100] \ \ (\*`a traiter comme tableau MEP), p. 4\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP D.3.10.2 \fIVariables r\*'ev\*'el\*'ees/visualis\*'ees\fR .sp 9p .RT .PP Deux processus peuvent \*'echanger des informations par d'autres moyens que des signaux. Un processus peut avoir acc\*`es \*`a la valeur d'une variable poss\*'ed\*'ee par un autre processus gr\* | ce \*`a l'op\*'eration VIEW (visualiser). Il existe cependant plusieurs r\*`egles \*`a appliquer: .RT .LP \(em les deux processus doivent appartenir au m\* | me bloc; .LP \(em le processus ex\*'ecutant l'op\*'eration VIEW doit sp\*'ecifier l'identificateur de la variable visualis\*'ee dans la d\*'efinition de visibilit\*'e; .LP \(em le processus r\*'ev\*'elant la variable doit la d\*'eclarer avec l'attribut REVEALED (r\*'ev\*'el\*'e); .LP \(em l'identificateur de sorte (ou identificateur de syntype) de la d\*'eclaration de variables et de la d\*'efinition de visibilit\*'e doivent \* | tre les m\* | mes. .PP La valeur que le processus de visualisation obtient par l'op\*'eration VIEW est la m\* | me que celle qu'obtient le processus de r\*'ev\*'elation par un acc\*`es ordinaire. .PP Etant donn\*'e que le processus de visualisation ne poss\*`ede pas la variable visualis\*'ee, il ne peut en modifier la valeur. Naturellement, la valeur visualis\*'ee peut \* | tre affect\*'ee \*`a une variable que poss\*`ede lui\(hym\* | me le processus effectuant les visualisations. .PP L'utilisateur du LDS peut trouver que la d\*'efinition des variables r\*'ev\*'el\*'ees/visualis\*'ees offre une mani\*`ere facile de sp\*'ecifier la communication entre deux processus. Cependant, plusieurs probl\*`emes peuvent se poser dans la mise en oeuvre des syst\*`emes ainsi sp\*'ecifi\*'es et la pr\*'esente section a pout but d'aider les utilisateurs \*`a \*'eviter ou \*`a surmonter de tels probl\*`emes. D\*'ecrire des syst\*`emes du LDS qui ont mis en oeuvre une valeur r\*'ev\*'el\*'ee/visualis\*'ee est moins difficile, car les probl\*`emes auront \*'et\*'e surmont\*'es dans la mise en oeuvre de sorte et qu'il sera possible de mettre en concordance la solution choisie avec le LDS. .PP Dans le reste de la pr\*'esente section, on admet que le processus\ R (R\*'ev\*'elateur) poss\*`ede et r\*'ev\*`ele des variables et que le processus\ V (Visualisateur) se rapporte \*`a ses variables dans sa d\*'efinition de visualisation. .PP Une tentative de visualiser des variables du processus\ V avant la cr\*'eation du processus\ R aboutit en LDS \*`a une erreur. L'utilisateur peut \*'eviter ce probl\*`eme de deux mani\*`eres: .RT .LP \(em soit en s'assurant que l'instance de procesus r\*'ev\*'elatrice\ R est cr\*'e\*'ee et a initialis\*'e les variables pertinentes avant l'instance de processus de visualisation\ V; .LP \(em soit en s'assurant que V ne passe pas dans des transitions utilisant des variables r\*'ev\*'el\*'ees/visualis\*'ees avant que\ R ait \*'et\*'e cr\*'e\*'e et ait initialis\*'e les variables pertinentes. .PP Dans le premier cas, une mani\*`ere simple d'y parvenir consiste \*`a faire de\ R l'ascendant (ou anc\* | tre) de\ V (comme dans l'exemple de la figure\ D\(hy3.10.5), ou d'admettre que\ R soit cr\*'e\*'e en m\* | me temps que le syst\*`eme (cr\*'eation implicite). Dans le second cas, on peut obtenir que la transition pertinente en\ V ne puisse \* | tre d\*'eclench\*'ee que par un signal de\ R. .PP Les variables de R ne peuvent \* | tre visualis\*'ees apr\*`es l'arr\* | t de\ R. Toute tentative de visualiser des donn\*'ees serait alors une erreur en LDS. L'utilisateur peut \*'eviter ce probl\*`eme de deux mani\*`eres: .RT .LP \(em soit en n'utilisant en aucun cas l'arr\* | t de R; .LP \(em 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 donn\*'ees pertinentes. .PP La premi\*`ere solution pr\*'esente l'inconv\*'enient pour l'auteur de la mise en oeuvre que\ R n'a pas lib\*'er\*'e les donn\*'ees stock\*'ees qu'elle utilisait. .PP On trouvera dans la figure D\(hy3.10.5 un exemple de variables r\*'ev\*'el\*'ees/visualis\*'ees. .RT .sp 1P .LP D.3.10.3 \fIValeurs export\*'ees/import\*'ees\fR .sp 9p .RT .PP Un processus peut d\*'eclarer <> 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 d\*'eclarer la variable dans sa d\*'efinition d'importation. .PP Lorsque le processus exportateur effectue une exportation, la valeur de la variable est copi\*'ee 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 diff\*'erer de la valeur obtenue gr\* | ce \*`a l'acc\*`es ordinaire par le propri\*'etaire, m\* | me si ces deux op\*'erations sont effectu\*'ees au m\* | me moment. .bp .PP On trouvera un exemple dans la figure D\(hy3.10.5. .RT .LP .rs .sp 45P .ad r \fBFigure D\(hy3.10.5, p. 5\fR .sp 1P .RT .ad b .RT .PP Dans la figure D\(hy3.10.5, le processus P1 est cens\*'e \* | tre l'ascendant des processus\ P2 et\ P3; en cons\*'equence, l'identificateur d'instance de processus des expressions IMPORT et VIEW est indiqu\*'e par l'attribut PARENT. .bp .sp 1P .LP D.3.10.4 \fIExpressions\fR .sp 9p .RT .PP Des expressions d'un processus en LDS peuvent servir de texte formel pour des d\*'ecisions, options, s\*'elections, t\* | ches, signaux continus, conditions de validation et construction d'initialisation. Des expressions sont \*'egalement utilis\*'ees comme param\*`etres r\*'eels de la sortie, de l'appel de proc\*'edure, de la construction de cr\*'eation. Des expressions PId sont utilis\*'ees dans la partie\ TO de la construction de sortie. Les expressions des constructions d'options et de s\*'elections (\*'evalu\*'ees statistiquement) devraient \* | tre des sortes de donn\*'ees pr\*'ed\*'efinies. Dans une expression, il peut y avoir des termes fondamentaux (c'est\(hy\*`a\(hydire des termes ne contenant que des repr\*'esentations de valeurs constantes) et des termes comportant des variables. .PP Le LDS a un ensemble pr\*'ed\*'efini d'op\*'erateurs infixes. Ces op\*'erateurs peuvent \* | tre utilis\*'es pour n'importe quel type de donn\*'ees et ils sont les seuls op\*'erateurs infixes autoris\*'es. Pour ces op\*'erateurs, les r\*`egles de priorit\*'e sont d\*'efinies et ne peuvent \* | tre modifi\*'ees. Les op\*'erateurs infixes pr\*'ed\*'efinis sont les suivants: .RT .LP =>, OR, XOR, AND, IN, /=, =, >, <, <=, >=, +, \(em, //, *, /, MOD, REM .PP Le LDS offre en outre les op\*'erateurs pr\*'ed\*'efinis: .LP \(em, NOT .LP qui sont des op\*'erateurs pr\*'ed\*'efinis unaires. .PP Lorsque l'on utilise des op\*'erateurs pr\*'ed\*'efinis, il faut veiller \*`a appliquer les r\*`egles de priorit\*'e car ces op\*'erateurs, \*'etant pr\*'ed\*'efinis ind\*'ependamment du domaine d'application, pourraient donner lieu \*`a des confusions. .PP A titre d'exemple, admettons le newtype et l'expression de la figure\ D\(hy3.10.6. Compte tenu des r\*`egles de priorit\*'e de multiplication et d'addition, on \*'evalue l'expression comme A\ =\ >((B*C)\ +\ D). Mais cela est diff\*'erent de la priorit\*'e 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 incoh\*'erents et rendre non valable la sp\*'ecification du LDS. .RT .LP .rs .sp 10P .ad r \fBFigure D\(hy3.10.6 [T28.100] \ \ (\*`a traiter comme tableau MEP), p. 6\fR .sp 1P .RT .ad b .RT .PP Tous les autres op\*'erateurs d\*'efinis par l'utilisateur sont des fonctions qui doivent \* | tre utilis\*'ees dans la notation pr\*'efixe. .PP Les deux op\*'erateurs VIEW et IMPORT ont une s\*'emantique particuli\*`ere, expliqu\*'ee dans les paragraphes pr\*'ec\*'edents. En tout cas, ils renvoient une valeur d'une certaine sorte, qui peut \* | tre un autre op\*'erande dans une expression. .RT .sp 1P .LP D.3.11 \fIExpresssion du temps en LDS\fR .sp 9p .RT .PP La n\*'ecessit\*'e de mesurer le temps et de demander une temporisation dans un syst\*`eme est satisfaite par des temporisateurs et un ensemble d'op\*'erations ex\*'ecut\*'ees sur ceux\(hyci. .PP Dans le mod\*`ele LDS, les temporisateurs (<>) sont des m\*'etaprocessus capables d'\*'emettre des signaux vers le processus sur demande. L'utilisation de temporisateurs doit \* | tre d\*'eclar\*'ee dans leur d\*'efinition, dans le cadre des d\*'efinitions de processus. Les op\*'erations <> et <> servent \*`a activer les temporisateurs. L'op\*'eration SET implique qu'une temporisation doit se produire \*`a un moment sp\*'ecifi\*'e et l'op\*'eration RESET annule la temporisation sp\*'ecifi\*'ee. (A noter qu'une op\*'eration SET comporte implicitement une op\*'eration RESET pour toute temporisation provenant de ce temporisateur qui n'aurait pas expir\*'e.) .PP La construction <> contient l'expression temporelle du d\*'elai requis, le nom du temporisateur dont il s'agit et, en option, une liste d'expressions. Cette liste sp\*'ecifie des valeurs qui seront comprises dans le signal du temporisateur de m\* | me ordre. .bp .PP Les listes d'expressions peuvent \* | tre sp\*'ecifi\*'ees dans la construction <> pour permettre de r\*'einitialiser une instance particuli\*`ere de l'instance de temporisateur ayant les m\* | mes valeurs. .PP La d\*'efinition du temporisateur doit comprendre la liste des identificateurs de r\*'ef\*'erence de sortes correspondant aux sortes utilis\*'ees dans les expressions de set/reset. .PP On trouvera un exemple d'instruction <> dans la figure\ D\(hy3.11.1. .PP Dans la construction set, il faut sp\*'ecifier un temps absolu. Le temps relatif est transform\*'e en valeur de temps absolue par l'adjonction de la fonction primitive <>, qui repr\*'esente le moment actuel. L'expression du d\*'elai demand\*'e devrait \* | tre une expression temporelle. Le temps est une sorte pr\*'ed\*'efinie, <> de la sorte <>. .PP La possibilit\*'e de recevoir une temporisation est sp\*'ecifi\*'ee \*`a l'aide du nom de temporisateur dans une entr\*'ee, comme indiqu\*'e dans la figure\ D\(hy3.11.1. .RT .LP .rs .sp 17P .ad r \fBFigure D\(hy3.11.1, p. 7\fR .sp 1P .RT .ad b .RT .PP Il est possible de d\*'efinir des synonymes pour indiquer les dur\*'ees souhait\*'ees. Apr\*`es avoir choisi les unit\*'es de temps et de dur\*'ee, l'utilisateur peut d\*'efinir les synonymes n\*'ecessaires pour repr\*'esenter les dur\*'ees, comme indiqu\*'e dans la figure\ D\(hy3.11.2. .LP .rs .sp 17P .ad r \fBFigure D\(hy3.11.2 [T29.100] \ \ (\*`a traiter comme tableau MEP), p. 8\fR .sp 1P .RT .ad b .RT .LP .bp .PP Dans la Recommandation, il est indiqu\*'e que l'armement d'un temporisateur sur un moment d\*'ej\*`a <<\*'ecoul\*'e>> est autoris\*'e. Cette d\*'ecision a \*'et\*'e prise afin de faciliter la simulation de syst\*`emes; toutefois, une op\*'eration de ce genre pourrait donner une sp\*'ecification manquant de clart\*'e et devrait donc \* | tre \*'evit\*'e. .sp 1P .LP D.3.12 \fIEmploi de qualificatifs\fR .sp 9p .RT .PP En LDS, des qualificatifs sont utilis\*'es pour faire r\*'ef\*'erence \*`a des points d'une sp\*'ecification, lorsque le nom ne d\*'etermine pas uniquement un point donn\*'e. Naturellement, pour les d\*'efinitions d'un point, seul le nom doit \* | tre sp\*'ecifi\*'e mais lorsque l'on se r\*'ef\*`ere \*`a ce point en dehors de l'occurrence qui le d\*'efinit, il peut \* | te n\*'ecessaire de disposer d'un identificateur compos\*'e d'un qualificatif et de ce nom. .PP Cela est valable \*'egalement pour l'utilisation de d\*'efinitions diff\*'er\*'ees: l'occurrence d\*'efinissante utilise le nom pour rep\*'erer la d\*'efinition; la d\*'efinition diff\*'er\*'ee utilise un nom qualifi\*'e pour sp\*'ecifier son contexte. .PP Dans la figure D\(hy3.12.1, on trouvera un exemple d'emploi de qualificatifs pour un processus qui peut recevoir deux signaux diff\*'erents ayant m\* | me nom mais des identificateurs diff\*'erents. La premi\*`ere entr\*'ee se rapporte \*`a un type de signal d\*'efini au niveau du bloc; la seconde entr\*'ee se r\*'ef\*`ere \*`a un type de signal d\*'efini dans la d\*'efinition de processus. Dans la seconde entr\*'ee, la qualification pourrait \* | tre omise car lorsque des identificateurs ne sont pas qualifi\*'es, il faut se r\*'ef\*'erer \*`a la d\*'efinition la plus interne. .RT .LP .sp 1 .rs .sp 20P .ad r \fBFigure D\(hy3.12.1 [T30.100] \ \ (\*`a traiter comme tableau MEP), p. 9\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 2 D.3.13 \fISyntaxe de noms\fR .sp 9p .RT .PP En LDS, des noms peuvent consister soit en un mot unique soit en une liste de mots s\*'epar\*'es par des d\*'elimiteurs (espaces ou caract\*`eres de contr\* | le). Cette seconde possibilit\*'e permet d'obtenir une sp\*'ecification plus lisible lorsque l'on utilise des noms d'une certaine longueur, particuli\*`erement en LDS/GR, car les symboles graphiques ont une taille limit\*'ee. On trouvera dans la figure\ D\(hy3.13.1 certains exemples de noms compos\*'es de plusieurs mots. .bp .RT .LP .rs .sp 25P .ad r \fBFigure D\(hy3.13.1, p. 10\fR .sp 1P .RT .ad b .RT .PP Chaque fois que l'emploi de plusieurs mots dans un nom donne lieu \*`a une ambigu\*:it\*'e (voir les exemples de la figure\ D.3.13.2), les d\*'elimiteurs entre deux mots doivent \* | tre remplac\*'es par un caract\*`ere de soulignement (<< \(ul>>). La cha\* | ne de caract\*`eres obtenue par la transformation de d\*'elimiteurs en soulignements d\*'esigne toujours le m\* | me nom; ainsi, par exemple, BUSY SUB d\*'esigne le m\* | me nom que BUSY \(ulSUB. On trouvera dans la figure\ D\(hy3.13.3 certains exemples d'emploi sans ambigu\*:it\*'e de noms. .LP .sp 4 .rs .sp 8P .ad r \fBFigure D\(hy3.13.2 [T31.100] \ \ (\*`a traiter comme tableau MEP), p. 11\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 12P .ad r \fBFigure D\(hy3.13.3 [T32.100] \ \ (\*`a traiter comme tableau MEP), p. 12\fR .sp 1P .RT .ad b .RT .PP .sp 5 Il importe de noter que le caract\*`ere de soulignement peut aussi \* | tre employ\*'e dans des noms comme caract\*`ere de continuation, pour permettre de r\*'epartir des noms sur plus d'une ligne. Dans ce cas, on peut aussi d\*'esigner un nom contenant un caract\*`ere de soulignement suivi par un ou plusieurs d\*'elimiteurs en \*'eliminant le soulignement et les d\*'elimiteurs. .PP On trouvera dans la figure D\(hy3.13.4 des exemples de d\*'esignations diff\*'erentes pour le m\* | me nom. .RT .LP .sp 3 .rs .sp 17P .ad r \fBFigure D\(hy3.13.4 [T33.100] \ \ (\*`a traiter comme tableau MEP), p. 13\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP D.4 \fIStructuration et affinage de syst\*`emes LDS\fR .sp 1P .RT .sp 1P .LP D.4.1 \fIConsid\*'erations g\*'en\*'erales\fR .sp 9p .RT .PP Le pr\*'esent chapitre traite de certaines techniques et de constructions du LDS qui permettent une sp\*'ecification descendante des syst\*`emes de grande taille. En g\*'en\*'eral, les termes <> et <> sont appliqu\*'es \*`a ces techniques avec les significations suivantes: .RT .LP \(em subdivision: il s'agit de diviser une partie du syst\*`eme en parties plus petites dont le comportement global est \*'equivalent \*`a la partie non subdivis\*'ee. Ce terme peut s'appliquer \*`a des blocs (structur\*'es en nouveaux sous\(hyblocs, canaux et sous\(hycanaux), \*`a des canaux (structur\*'es en blocs, nouveaux canaux et sous\(hycanaux) et \*`a des processus (structur\*'es en service); .LP \(em affinage: adjonction de nouveaux d\*'etails aux fonctions d'un syst\*`eme. Consid\*'er\*'e \*`a partir de l'environnement, l'affinage d'un syst\*`eme a pour r\*'esultat un enrichissement de son comportement car plusieurs types de signaux et d'informations peuvent \* | tre trait\*'es. .PP On notera que la structure interne d'une partie d'un syst\*`eme renseigne plus pr\*'ecis\*'ement sur la structure, mais pas n\*'ecessairement sur le comportement du syst\*`eme. Il est th\*'eoriquement possible de distinguer l'aspect d'une repr\*'esentation plus d\*'etaill\*'ee du comportement (par exemple, le traitement d'un nouveau signal) de l'aspect d'une structure plus d\*'etaill\*'ee (couvrant, par exemple, \*`a la fois la structure des parties et celle du comportement du syst\*`eme), mais dans la pratique ces deux aspects sont g\*'en\*'eralement confondus: ainsi, des d\*'etails suppl\*'ementaires sur la structure du syst\*`eme en \*'eclairent \*'egalement le comportement. .PP La structure minimale d'un syst\*`eme en LDS est d\*'ecrite dans le chapitre\ 2 de la Recommandation: un syst\*`eme consiste en un ensemble de blocs reli\*'es par des canaux et ces blocs contiennent des processus. .PP Les concepts applicables \*`a la subdivision en plusieurs niveaux de d\*'etails et d'affinage signaux sont trait\*'es dans le chapitre\ 3 de la Recommandation. Ces concepts ne sont pas n\*'ecessaires dans le cas de syst\*`emes qui n'ont pas \*`a \* | tre affin\*'es. .RT .sp 1P .LP D.4.2 \fICrit\*`eres de subdivision\fR .sp 9p .RT .PP On nomme subdivision la technique qui consiste \*`a fragmenter une repr\*'esentation d'un syst\*`eme d'un niveau de d\*'etail \*'el\*'ev\*'e en \*'el\*'ements d'un maniement facile. Le processus de subdivision ajoute une structure \*`a un syst\*`eme. .PP Parmi les crit\*`eres qui entra\* | nent la subdivision de repr\*'esentation d'un syst\*`eme, on peut citer les suivants: .RT .LP a) d\*'efinir des blocs ou des processus qui, par leurs dimensions, facilitent la compr\*'ehension du syst\*`eme; .LP b) \*'etablir une certaine correspondance avec les divisions effectives du logiciel et/ou du mat\*'eriel; .LP c) utiliser les subdivisions fonctionnelles naturelles; .LP d) r\*'eduire au minimum l'interaction entre les blocs; .LP e) r\*'eutiliser des repr\*'esentations pr\*'eexistantes (par exemple un syst\*`eme de signalisation). .PP Les crit\*`eres qui seront effectivement adopt\*'es d\*'ependront de plusieurs facteurs et notamment du degr\*'e de pr\*'ecision requis. .PP Etant donn\*'e que la relation entre les niveaux d\*'epend des crit\*`eres de subdivision choisis, il importe de sp\*'ecifier clairement ces crit\*`eres afin de faciliter la compr\*'ehension de la repr\*'esentation. L'usager d\*'ecide des crit\*`eres de subdivision mais certaines restrictions s'appliquent afin de garantir une repr\*'esentation correcte en LDS. Les paragraphes qui suivent traitent de ces restrictions. .RT .sp 1P .LP D.4.3 \fISubdivision des blocs\fR .sp 9p .RT .PP On peut subdiviser un bloc en un ensemble de blocs et de canaux pratiquement de la m\* | me fa\*,con qu'on subdivise un syst\*`eme en blocs et en canaux. En LDS/GR, cela est repr\*'esent\*'e \*`a l'aide d'un diagramme de sous\(hystructure de bloc. On en trouvera dans la figure\ D\(hy4.3.1. Dans le premier diagramme de cette figure, le diagramme du bloc\ B1 contient une r\*'ef\*'erence \*`a sa sous\(hystructure. Dans le second diagramme, il existe un diagramme de sous\(hystructure pour le bloc\ B1. Le symbole de bloc rattach\*'e au canal\ C2 par une ligne en taits discontinus, dans le premier diagramme, repr\*'esente une r\*'ef\*'erence \*`a la sous\(hystructure de canal\ C2 (voir le \(sc\ D.4.5). .RT .PP En LDS/PR, la subdivision d'un bloc est repr\*'esent\*'ee par un ensemble de d\*'efinitions comprises entre les mots\(hycl\*'es SUBSTRUCTURE et ENDSUBSTRUCTURE \*`a l'int\*'erieur de la d\*'efinition du bloc. Les d\*'efinitions d'une sous\(hystructure de bloc sont les m\* | mes que celles de la d\*'efinition de syst\*`eme; de plus, la sp\*'ecification des connexions entre canaux et sous\(hycanaux doit \* | tre effectu\*'ee comme indiqu\*'e dans la figure\ D\(hy4.3.2. .bp .LP .rs .sp 47P .ad r \fBFigure D\(hy4.3.1, p. 14\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 35P .ad r \fBFigure D\(hy4.3.2 [T34.100] \ \ (\*`a traiter comme tableau MEP), p. 15\fR .sp 1P .RT .ad b .RT .PP La sp\*'ecification des processus et celle d'une sous\(hystructure de bloc peuvent coexister \*`a l'int\*'erieur d'une d\*'efinition de bloc. Dans ce cas, les processus du bloc repr\*'esentent le comportement de ce bloc pour un niveau de pr\*'ecision donn\*'e; d'autres processus internes des d\*'efinitions des sous\(hyblocs repr\*'esenteront d'une mani\*`ere plus d\*'etaill\*'ee le m\* | me comportement. On trouvera au \(sc\ D.4.7 (figure\ D\(hy4.7.1) un exemple de bloc d\*'ecrit tant en fonction de processus que de sous\(hystructures. .PP S'il n'existe pas de processus \*`a l'int\*'erieur d'un bloc mais seulement une sous\(hystructure de bloc et que celle\(hyci ne fait pas l'objet d'un rep\*'erage, il existe en LDS/GR une notation abr\*'eg\*'ee permettant de simplifier le diagramme. Cette notation permet d'embo\* | ter des blocs en consid\*'erant le cadre du bloc ext\*'erieur comme impliquant le cadre de sous\(hystructure. Gr\* | ce \*`a cette notation, l'exemple de la figure\ D\(hy4.3.1 peut \* | tre trac\*'e comme dans la figure\ D\(hy4.3.3. .bp .RT .LP .rs .sp 47P .ad r \fBFigure D\(hy4.3.3, p. 16\fR .sp 1P .RT .ad b .RT .LP .bp .PP Chaque bloc provenant de la subdivision d'un bloc peut \* | tre lui\(hym\* | me subdivis\*'e, ce qui donne une structure arborescente hi\*'erarchique de blocs et de leurs sous\(hyblocs. Un diagramme auxiliaire appel\*'e <> repr\*'esentant cette structure g\*'en\*'erale est d\*'ecrit au \(sc\ D.4.4. .PP A moins qu'il ne s'agisse de l'affinage de signaux, les r\*`egles suivantes doivent \* | tre observ\*'ees dans le processus de subdivision. .RT .LP 1) les listes de signaux des sous\(hycanaux reli\*'es \*`a un canal d'entr\*'ee 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\(hy4.3.1, C2.1 et\ C2.2 transportent sur les trajets d'entr\*'ee tous les signaux de\ L2. En outre, aucun des signaux transport\*'es par\ C2.1 ne peut appara\* | tre sur le trajet d'entr\*'ee de\ C2.2; .LP 2) les listes de signaux des sous\(hycanaux (par exemple C1.1 et\ C1.2) reli\*'es \*`a une voie de sortie (par 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; .LP 3) si le bloc original contient des processus, il existe deux options. Tout d'abord, une copie de chaque processus peut \* | tre red\*'efinie dans l'un ou l'autre des nouveaux sous\(hyblocs. Deuxi\*`emement, de nouveaux processus peuvent \* | tre d\*'efinis dans les sous\(hyblocs de telle mani\*`ere que l'interface reste sans changement; .LP 4) des d\*'efinitions de donn\*'ees du bloc ascendant se trouvent dans ses sous\(hyblocs, de sorte que chacun de ceux\(hyci peut utiliser un type de donn\*'ees d\*'efini dans le bloc ascendant sans avoir \*`a le red\*'efinir; .LP 5) si un type de donn\*'ees d\*'efini dans le bloc ascendant est red\*'efini avec le m\* | me nom dans un sous\(hybloc, la nouvelle d\*'efinition s'applique au sous\(hybloc d\*'efinissant tandis que l'ancienne d\*'efinition reste valable pour les autres sous\(hyblocs. Il faut \*'eviter une red\*'efinition servant uniquement \*`a caract\*'eriser un sous\(hybloc car un lecteur peut la n\*'egliger, supposant que l'ancienne d\*'efinition est valable. Dans certains cas cependant, il convient de proc\*'eder \*`a une telle red\*'efinition, notamment lorsqu'il s'agit d'un affinage du comportement. Il faut veiller \*`a souligner cette red\*'efinition par une annotation appropri\*'ee. .sp 1P .LP D.4.4 \fIDiagramme d'arbre de blocs\fR .sp 9p .RT .PP Le diagramme d'arbre de blocs repr\*'esente la structure d'un syst\*`eme en fonction de ces blocs et sous\(hyblocs. Ce diagramme vise \*`a donner au lecteur un aper\*,cu de la structure totale d'un sous\(hysyst\*`eme. .PP Le diagramme est un arbre hi\*'erarchique de symboles de blocs et de lignes de subdivision comme indiqu\*'e dans la figure\ D\(hy4.4.1. .RT .LP .rs .sp 20P .ad r \fBFigure D\(hy4.4.1, p. 17\fR .sp 1P .RT .ad b .RT .LP .bp .PP Il est pr\*'ef\*'erable que le diagramme soit trac\*'e de telle mani\*`ere 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 divis\*'e en diagrammes d'arbre de blocs <> comme indiqu\*'e dans la figure\ D\(hy4.4.2. .PP Il est souvent utile de subdiviser un diagramme d'arbre de blocs en diagrammes partiels. .PP La division en plusieurs diagrammes partiels s'effectue de telle sorte que le premier diagramme, ayant pour racine le syst\*`eme, soit coup\*'e de mani\*`ere que les blocs encore subdivis\*'es apparaissent comme non subdivis\*'es. Les blocs, l\*`a o\*`u le diagramme original a \*'et\*'e coup\*'e, apparaissent comme des racines dans les diagrammes indiquant la subdivision. .RT .LP .rs .sp 25P .ad r \fBFigure D\(hy4.4.2, p. 18\fR .sp 1P .RT .ad b .RT .PP Si des diagrammes partiels sont utilis\*'es et qu'il n'est pas \*'evident de savoir si un bloc est subdivis\*'e ailleurs et de trouver o\*`u continuent les diagrammes, il convient d'ins\*'erer des r\*'ef\*'erences en utilisant le symbole commentaire. .sp 1P .LP D.4.5 \fISubdivision des canaux\fR .sp 9p .RT .PP Un canal peut \* | tre subdivis\*'e ind\*'ependamment des blocs qu'il relie. Cela permet la repr\*'esentation du comportement du canal en question lorsqu'il achemine des signaux. Il est parfois n\*'ecessaire de repr\*'esenter le comportement du canal afin d'obtenir une repr\*'esentation exacte du parcours d'un signal. .PP Pour ce faire, on examine le canal en tant qu'\*'el\*'ement ind\*'ependant dont l'environnement se compose des deux blocs qu'il relie. Consid\*'erant le canal de cette mani\*`ere, on peut exprimer sa structure au moyen de blocs, de canaux et de processus. .PP En LDS/GR, la subdivision de canaux est repr\*'esent\*'ee \*`a l'aide de diagrammes de sous\(hystructure de canaux, comme indiqu\*'e dans la figure\ D\(hy4.5.1. (l'exemple repr\*'esente la sous\(hystructure du canal\ C2 de la figure\ D\(hy4.3.1). .PP Un diagramme de sous\(hystructure de canaux montre comment un canal est subdivis\*'e en sous\(hycomposants. Ce diagramme ressemble au diagramme de syst\*`eme (sauf en ce qui concerne la connexion des blocs). Toutes les directives donn\*'ees au \(sc\ D.4.3 sont valables pour le diagramme de sous\(hystructure de canaux. .bp .PP Dans le diagramme d'interaction de blocs o\*`u apparaissent les canaux subdivis\*'es, il faut faire r\*'ef\*'erence au diagramme de sous\(hystructure de canaux d\*'ecrivant la subdivision. .RT .LP .rs .sp 22P .ad r \fBFigure D\(hy4.5.1, p. 19\fR .sp 1P .RT .ad b .RT .PP En LDS/PR, la forme est semblable \*`a celle de la d\*'efinition de sous\(hystructure de blocs; la seule diff\*'erence est que, dans l'instruction CONNECT, les sous\(hycanaux d'extr\*'emit\*'e sont raccord\*'es \*`a des blocs ext\*'erieurs (B1 et\ B2 dans la figure\ D\(hy4.5.2) et non \*`a des canaux ext\*'erieurs. .PP L'import/export des valeurs est autoris\*'e entre un bloc et une sous\(hystructure de canaux. Cela permet une repr\*'esentation directe du mod\*`ele OSI dans laquelle les communications de couches homologues sont mod\*'elis\*'ees par l'\*'echange de signaux et les communications de couches contigu\*:es par des valeurs partag\*'ees. .sp 1P .LP D.4.6 \fIRepr\*'esentation du syst\*`eme en cas de\fR \fIsubdivision\fR .sp 9p .RT .PP Lorsqu'un syst\*`eme est repr\*'esent\*'e sous la forme d'un ensemble de blocs interconnect\*'es par des canaux et que l'on exprime le comportement de chaque bloc au moyen d'un ou de plusieur processus, nous nous trouvons en pr\*'esence d'une repr\*'esentation sur un seul niveau. Ceci revient \*`a dire que nous pouvons voir tous les \*'el\*'ements de la repr\*'esentation au m\* | me niveau. Nous .PP introduisons, avec la subdivision une relation hi\*'erarchique entre les diff\*'erents documents. Le document qui en r\*'esulte repr\*'esente la structure du syst\*`eme lorsque le syst\*`eme se compose de n\ blocs. .PP Un autre document peut pr\*'esenter le syst\*`eme compos\*'e d'un ensemble diff\*'erent de blocs, dont certains proviennent des blocs du document pr\*'ec\*'edent (certains blocs du document pr\*'ec\*'edent ont \*'et\*'e remplac\*'es par les sous\(hyblocs r\*'esultant de la subdivision des blocs). Ce nouveau document doit \* | tre rapport\*'e au pr\*'ec\*'edent document. .PP Mais pour obtenir une repr\*'esentation compl\*`ete du syst\*`eme, il ne suffit pas d'\*'etablir des rapports entre les documents, il faut \*'egalement les organiser de telle sorte qu'il soit possible d'acc\*'eder \*`a la repr\*'esentation du syst\*`eme par niveaux, en commen\*,cant par une vue d'ensemble g\*'en\*'erale pour passer ensuite \*`a des repr\*'esentations de plus en plus d\*'etaill\*'ees. Ceci exige le regroupement des diff\*'erents documents afin de repr\*'esenter le syst\*`eme \*`a diff\*'erents niveaux. .PP On ne devrait pas trouver les m\* | mes \*'el\*'ements \*`a tous les niveaux. La repr\*'esentation du syst\*`eme au premier niveau peut se composer de repr\*'esentations des blocs et des canaux, \*`a l'exclusion des processus qui d\*'ecrivent le comportement de chaque bloc. A un niveau inf\*'erieur, on peut .PP souhaiter inclure la repr\*'esentation du comportement de certains blocs, mais pas de celui d'autres blocs. Le niveau de repr\*'esentation le plus bas (c'est\(hy\*`a\(hydire la repr\*'esentation la plus d\*'etaill\*'ee) devrait repr\*'esenter int\*'egralement les comportements de tous les blocs, c'est\(hy\*`a\(hydire l'ensemble complet des processus qui expriment ce comportement. .bp .RT .LP .rs .sp 35P .ad r \fBFigure D\(hy4.5.2 [T35.100] \ \ (\*`a traiter comme tableau MEP), p. 20\fR .sp 1P .RT .ad b .RT .PP L'observation de l'arborescence de blocs soul\*`eve plusieurs r\*'eflexions. .PP En premier lieu, l'arborescence a toujours une et seulement une racine, qui est le syst\*`eme. Il en est ainsi de m\* | me lorsque le syst\*`eme repr\*'esent\*'e se compose de plusieurs blocs depuis le d\*'ebut. Dans l'arborescence, ces blocs sont repr\*'esent\*'es au niveau\ 1. Le nom du syst\*`eme peut suffire pour constituer le bloc qui sert de racine. On peut appliquer les d\*'efinitions des canaux aux blocs bien que cela ne soit pas exig\*'e, sauf si les blocs ont des processus associ\*'es. .PP 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 in\*'egal de subdivisions sur les blocs de l'arborescence. Le nombre de subdivisions d\*'epend de plusieurs facteurs, dont la plupart rel\*`event de l'appr\*'eciation subjective de la personne charg\*'ee d'\*'elaborer les sp\*'ecifications, et du concepteur. .PP Pour que des blocs feuille ne soient pas subdivis\*'es de nouveau, le LDS n'exige qu'une chose, \*`a savoir que leur comportement soit enti\*`erement sp\*'ecifi\*'e (c'est\(hy\*`a\(hydire que son attitude puisse \* | tre repr\*'esent\*'ee par les d\*'efinitions des processus). Par cons\*'equent, un bloc feuille doit contenir au moins un processus associ\*'e. .bp .PP Lorsqu'un syst\*`eme est repr\*'esent\*'e \*`a plusieurs niveaux d'abstraction, nous pouvons repr\*'esenter le syst\*`eme au niveau de notre choix. Le choix d'un niveau donn\*'e exige que les blocs soient examin\*'es \*`a ce m\* | me niveau, que leurs processus associ\*'es et tous les blocs feuille soient examin\*'es \*`a des niveaux sup\*'erieurs avec leurs processus associ\*'es (voir la figure\ D\(hy4.6.1). .PP Il est souvent pratique de choisir diff\*'erents niveaux \*`a diff\*'erentes fins, par exemple un niveau <> pour la pr\*'esentation et un niveau plus d\*'etaill\*'e pour la mise en oeuvre. .RT .LP .rs .sp 25P .ad r \fBFigure D\(hy4.6.1, p. 21\fR .sp 1P .RT .ad b .RT .PP La repr\*'esentation d'un syst\*`eme \*`a un certain niveau peut \* | tre incompl\*`ete dans la mesure o\*`u certains des blocs de ce niveau n'ont pas de processus associ\*'es. .PP On parle de niveaux de repr\*'esentation et de s\*'election d'un certain niveau de repr\*'esentation pour les raisons suivantes: .RT .LP \(em il se peut que notre repr\*'esentation ait atteint un certain <> de pr\*'ecision, repr\*'esent\*'e par ce niveau de repr\*'esentation (dans ce cas, les blocs de ce niveau sont des blocs feuille; ils ne sont pas complets car ils demandent un suppl\*'ement de travail!); .LP \(em nous voulons consid\*'erer la repr\*'esentation du syst\*`eme \*`a un certain niveau de pr\*'ecision; nous choisissons donc le niveau de repr\*'esentation qui correspond au mieux aux abstractions que nous cherchons. On notera que dans certains cas un niveau donn\*'e de repr\*'esentation peut \* | tre constitu\*'e de documents \*`a diff\*'erents niveaux d'abstraction. La repr\*'esentation d'une partie du syst\*`eme au niveau\ 2 peut \* | tre tr\*`es d\*'etaill\*'ee, tandis que celle d'une autre partie au niveau\ 4 peut demeurer abstraite. Cela signifie qu'en choisissant une repr\*'esentation au niveau\ 3, l'on peut obtenir une repr\*'esentation tr\*`es d\*'etaill\*'ee de certaines parties et une simple vue d'ensemble d'autres parties; .LP \(em la m\*'ethodologie de repr\*'esentation et conception peut permettre \*`a chaque niveau d'avoir une signification pr\*'ecise. Ainsi le niveau\ 1 correspond \*`a la sp\*'ecification, le niveau\ 2 fournit la structure g\*'en\*'erale du syst\*`eme, le niveau\ 3 la structure des modules (<>, fonctions de logiciel), le niveau\ 4 donne la structure d\*'etaill\*'ee (planches imprim\*'ees, proc\*'edures, modules de logiciel). Dans ce cas, le lecteur choisit un niveau donn\*'e en fonction de son propre besoin, et l'on notera que la m\*'ethode permet d'\*'eviter les diff\*'erences entre les niveaux de pr\*'ecision des parties qui constituent un niveau donn\*'e de repr\*'esentation. .bp .sp 1P .LP D.4.6.1 \fISous\(hyensemble de subdivision coh\*'erent\fR .sp 9p .RT .PP En plus de la sp\*'ecification totale du syst\*`eme et de celle qui est donn\*'ee par niveaux, le LDS comporte une notion de <>. Celle\(hyci peut \* | tre consid\*'er\*'ee comme une sp\*'ecification de niveau unique dans laquelle tous les blocs peuvent \* | tre pris d'un niveau quelconque de la structure d'un syst\*`eme, \*'etant entendu: .RT .LP \(em qu'un bloc peut \* | tre choisi pour faire partie de la repr\*'esentation coh\*'erente du syst\*`eme s'il peut e\*^tre consid\*'er\*'e comme un bloc feuille (ou bien il est un bloc feuille ou bien tous les processus n\*'ecessaires \*`a la repr\*'esentation de son comportement lui sont associ\*'es); .LP \(em 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; .LP \(em que tous les documents d\*'efinissant les signaux passant dans le canal qui relie un bloc de la repr\*'esentation doivent \* | tre fournis. Selon la strat\*'egie 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 d\*'efinissant les donn\*'ees et les signaux. .PP Dans les cas o\*`u certains canaux ont \*'et\*'e subdivis\*'es, chacun \*'etant consid\*'er\*'e comme un syst\*`eme, il faut fournir la sp\*'ecification de chacun de ces <>. Leur sp\*'ecification consiste en documents du m\* | me type que ceux de la repr\*'esentation de syst\*`emes usuels. Il convient d'ajouter des notations r\*'ef\*'erant ces syst\*`emes \*`a la sp\*'ecification du syst\*`eme principal auquel ils appartiennent. Ainsi, en un sens, on peut consid\*'erer ces canaux subdivis\*'es .LP comme des syst\*`emes internes. Chacun de ces syst\*`emes peut avoir plusieurs niveaux de repr\*'esentation et comportera en outre des syst\*`emes internes si certains des canaux contenus sont subdivis\*'es plus avant. .sp 1P .LP D.4.7 \fIAffinage\fR .sp 9p .RT .PP Le m\*'ecanisme d'affinage a \*'et\*'e introduit dans le LDS pour <> les signaux de niveau inf\*'erieur au niveau sup\*'erieur d'abstraction et permettre la sp\*'ecification descendante du comportement du syst\*`eme. .PP L'affinage permet \*`a l'utilisateur de subdiviser des signaux en sous\(hysignaux, ce qui donne une structure hi\*'erarchique comme dans le cas des blocs et des sous\(hyblocs. Cela signifie qu'\*`a l'int\*'erieur d'une d\*'efinition de signal, il est possible de d\*'efinir un ensemble de nouveaux signaux qui sont appel\*'es signaux affin\*'es, ou sous\(hysignaux du signal d\*'efini. De m\* | me que l'arbre de bloc pour une d\*'efinition de bloc, on peut tracer, pour plus de clart\*'e, un <> de signaux pour une d\*'efinition de signal. .PP L'affinage est \*'etroitement li\*'e \*`a la subdivision de bloc car seuls les signaux transport\*'es par un canal reli\*'e \*`a un bloc subdivis\*'e peuvent \* | tre affin\*'es. Cela signifie qu'un signal figurant dans la liste d'un canal peut \* | tre remplac\*'e par ses sous\(hysignaux lors de la subdivision du bloc qui y est connect\*'e. Les sous\(hycanaux correspondants g\*'en\*'er\*'es par la subdivision du bloc devront sp\*'ecifier des sous\(hysignaux dans leurs listes de signaux. .PP Lorsqu'un signal est d\*'efini comme devant \* | tre achemin\*'e par un canal, le canal transportera automatiquement tous les sous\(hysignaux de ce signal, m\* | me si certains des sous\(hysignaux se dirigent dans le sens oppos\*'e (dans ce cas, le canal est consid\*'er\*'e comme implicitement bidirectionnel). On trouvera dans la figure\ D\(hy4.7.1 un exemple d'affinage. Cet exemple repr\*'esente un syst\*`eme 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 \*'elev\*'e, on obtient ceci par l'\*'emission de signaux qui repr\*'esentent chacun un fichier de textes (signal\ sf). Au niveau d'affinage inf\*'erieur, on peut sp\*'ecifier que le fichier de textes se compose d'un certain nombre d'enregistrements \*'emis par un signal (signal\ sr) et que le r\*'ecepteur doit r\*'epondre (signal\ nr) apr\*`es absorption de chaque enregistrement. L'\*'emetteur enverra un signal fin de fichier \*`a la fin de l'op\*'eration. Dans cet exemple, au niveau d'affinage le plus \*'elev\*'e, les processus de\ B1 et de\ B2 communiquent en utilisant le signal\ sf; au niveau imm\*'ediatement inf\*'erieur, les processus de\ B11 et de\ B21 communiquent en utilisant les signaux\ sr, nr et\ eof. .RT .PP Voici certains cas r\*'eels dans lesquels la notion d'affichage peut s'appliquer: .LP \(em transformation de nom: un signal affin\*'e devient un autre signal portant un nom diff\*'erent. C'est une transformation d'\*'el\*'ement \*`a \*'el\*'ement dans laquelle seul le nom du signal change. Cette possibilit\*'e est g\*'en\*'eralement impliqu\*'ee lorsque l'on veut que chaque niveau soit enti\*`erement compr\*'ehensible en soi\(hym\* | me. (Il peut \* | tre commode d'adapter le nom d'un signal \*`a son contexte.); .LP \(em transformation par division: il s'agit d'une transformation d'un signal en plusieurs autres, dans laquelle un signal est divis\*'e en plusieurs signaux par souci de pr\*'ecision. A titre d'exemple, un signal g\*'en\*'erique <> est divis\*'e en <>, <> et <>; .LP \(em transformation avec algorithme: le signal originel est transform\*'e en un ensemble de signaux qui d\*'eclenchent un algorithme afin de fournir l'information originelle. .bp .LP .rs .sp 36P .ad r \fBFigure D\(hy4.7.1, p. 22\fR .sp 1P .RT .ad b .RT .sp 1P .LP D.4.7.1 \fISous\(hyensemble d'affinage coh\*'erent\fR .sp 9p .RT .PP Lorsque l'affinage est appliqu\*'e \*`a une sp\*'ecification de syst\*`eme, la notion de sous\(hyensemble de subdivision coh\*'erent est limit\*'ee de mani\*`ere \*`a \*'eviter des communications avec diff\*'erents signaux entre diff\*'erents niveaux d'affinage. Dans ce cas, on dit que la d\*'efinition de syst\*`eme contient plusieurs sous\(hyensembles d'affinage coh\*'erents. Si un sous\(hyensemble d'affinage coh\*'erent contient un processus communiquant avec des sous\(hysignaux, ce processus ne peut communiquer avec le signal ascendant et l'autre extr\*'emit\*'e de la liaison de communication doit communiquer avec les m\* | mes sous\(hysignaux. .RT .sp 1P .LP D.4.7.2 \fITransformation entre signaux et sous\(hysignaux\fR .sp 9p .RT .PP L'utilisateur peut avoir besoin de d\*'ecrire la transformation entre diff\*'erents niveaux d'affichage \*`a des fins de simulation ou pour contr\* | ler le comportement du syst\*`eme indiff\*'erent au niveau de pr\*'ecision. Il peut le faire de mani\*`ere informelle \*`a l'aide de processus LDS suppl\*'ementaire d\*'ecrivant la transformation dynamique d'un signal en ses sous\(hysignaux ou vice versa. .PP Dans la figure D\(hy4.7.2, deux processus sont introduits pour d\*'ecrire la transformation appliqu\*'ee dans la figure\ D\(hy4.7.1. Un processus d'affinage d\*'efinit la mani\*`ere dont le signal de niveau \*'elev\*'e est <> en un ensemble de signaux au niveau inf\*'erieur suivant. Un processus d'extraction d\*'ecrit la transformation inverse. .bp .RT .LP .rs .sp 47P .ad r \fBFigure D\(hy4.7.2, p. 23\fR .sp 1P .RT .ad b .RT .LP .bp .sp 2P .LP D.5 \fIConcepts suppl\*'ementaires\fR .sp 1P .RT .sp 1P .LP D.5.1 \fIMacros\fR .sp 9p .RT .PP La construction macro permet de traiter les r\*'ep\*'etitions et/ou de structurer une description. Elle comprend une d\*'efinition de macro contenant une partie de sp\*'ecification\ LDS qui peut \* | tre r\*'ef\*'erenc\*'ee (appel de macro) en d'autres endroits d'une sp\*'ecification de syst\*`eme. .PP La d\*'efinition de macro peut \* | tre donn\*'ee en tous les endroits o\*`u des d\*'efinitions de donn\*'ees sont autoris\*'ees. Cependant, le nom de macro n'a pas de port\*'ee. Ainsi, une macro d\*'efinie dans un bloc peut \* | tre r\*'ef\*'erenc\*'ee en dehors de celui\(hyci. .PP En LDS/PR, il est possible d'employer une d\*'efinition de macro pour remplacer toute s\*'equence d'unit\*'es lexicales. Cette possibilit\*'e diff\*`ere des d\*'efinitions de macro en\ LDS/GR qui ne peuvent remplacer que des collections d'unit\*'es syntaxiques. .PP Pour mettre en concordance des documents en LDS/GR et en LDS/PR contenant des macros, il faut appliquer les restrictions ci\(hyapr\*`es \*`a l'utilisation de macros\ LDS/PR: .RT .LP 1) Une macro ne peut remplacer qu'une ou plusieurs des constructions syntaxiques suivantes (qui correspondent \*`a des symboles\ LDS/GR): .LP d\*'epart .LP \*'etat .LP entr\*'ee .LP condition de validation .LP signal continu .LP mise en r\*'eserve .LP instruction d'action .LP instruction de terminaison .LP 2) Des param\*`etres formels de macros ne peuvent pas \* | tre utilis\*'es en des endroits d\*'eterminant le type de la construction en\ LDS/PR. Cela signifie qu'ils ne peuvent \* | tre utilis\*'es l\*`a o\*`u sont employ\*'es les mots cl\*'es du\ LDS/PR. De m\* | me, des param\*`etres r\*'eels ne devraient pas contenir de mot cl\*'e correspondant \*`a des symboles du\ LDS/GR: START, STATE, PROCEDURE, INPUT, TASK, OUTPUT, DECISION, CREATE, STOP, PROVIDED, CALL, COMMENT, JOIN, RETURN, SAVE ou OPTION. .LP 3) Chaque \*'enonc\*'e de la d\*'efinition de macro doit pouvoir \* | tre atteint \*`a partir d'au moins un acc\*`es d'entr\*'ee de macro. .PP En LDS/PR, la macro a toujours au plus un acc\*`es d'entr\*'ee et un acc\*`es de sortie, de sorte qu'il est n\*'ecessaire d'employer des \*'etiquettes et des liaisons pour repr\*'esenter en LDS/PR une macro\ LDS/GR ayant plus d'un acc\*`es d'entr\*'ee ou de sortie. Si la macro doit \* | tre appel\*'ee en plus d'un endroit, les \*'etiquettes devront \* | tre communiqu\*'ees sous la forme de param\*`etres. .PP En LDS/GR, il y a deux moyens diff\*'erents de repr\*'esenter les acc\*`es d'entr\*'ee et de sortie d'une d\*'efinition de macro. L'utilisateur peut soit tracer un cadre pour la macro et relier \*`a celui\(hyci les acc\*`es d'entr\*'ee et de sortie, soit utiliser explicitement des symboles d'acc\*`es d'entr\*'ee et d'acc\*`es de sortie (le cadre de macro \*'etant facultatif). .PP L'exemple de la figure D\(hy5.1.1 illustre en LDS/GR et en LDS/PR une macro ayant deux acc\*`es d'entr\*'ee et deux acc\*`es de sortie. (Dans cet exemple, les acc\*`es d'entr\*'ee et de sortie sont reli\*'es au cadre de macro.) .RT .PP Cela signifie que dans la sp\*'ecification principale en LDS/PR (figure\ D\(hy5.1.2), existent les branchements et les \*'etiquettes correspondants. A noter que l'\*'etiquette sera probablement diff\*'erente pour chaque appel de macro. .PP La figure D\(hy5.1.3 illustre deux d\*'efinitions de macro qui d\*'efinissent un m\*'ecanisme de synchronisation. A noter l'emploi du param\*`etre pseudo\(hyformel\ MACROID, qui sert \*`a rendre uniques des noms d'\*'etat. Le m\* | me exemple est repris dans la figure\ D\(hy5.1.4 en ce qui concerne l'emploi de symboles d'acc\*`es d'entr\*'ee et d'acc\*`es de sortie. .PP Dans le cas de macros embo\* | t\*'ees, c'est\(hy\*`a\(hydire lorsqu'il existe un ou plusieurs appels de macros \*`a l'int\*'erieur d'une d\*'efinition de macro, il convient de noter que l'expansion des macros ext\*'erieures n'affecte pas celle des macros int\*'erieures. Plus pr\*'ecis\*'ement, l'expansion de macros embo\* | t\*'ees doit \* | tre consid\*'er\*'ee comme si l'expansion d'une macro devrait \* | tre termin\*'ee avant le d\*'ebut de l'expansion d'appels \*'eventuels de macros int\*'erieures. .bp .LP .rs .sp 19P .ad r \fBFigure D\(hy5.1.1, p. 24\fR .sp 1P .RT .ad b .RT .LP .rs .sp 23P .ad r \fBFigure D\(hy5.1.2, p. 25\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 22P .ad r \fBFigure D\(hy5.1.3, p. 26\fR .sp 1P .RT .ad b .RT .LP .rs .sp 21P .ad r \fBFigure D\(hy5.1.4, p. 27\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP D.5.2 \fISyst\*`emes g\*'en\*'eriques\fR .sp 9p .RT .PP En LDS, ilest possible de d\*'efinir diff\*'erents syst\*`emes dans une seule sp\*'ecification \*`a l'aide des param\*`etres de syst\*`emes. Ceux\(hyci ont une valeur ind\*'efinie qui peut \* | tre donn\*'ee ext\*'erieurement pour obtenir une d\*'efinition de syst\*`eme sp\*'ecifique correspondant aux besoins des utilisateurs. .PP En fait, les param\*`etres de syst\*`eme sont des synonymes externes et peuvent \* | tre utilis\*'es \*`a tout endroit o\*`u un synonyme peut l'\* | tre. Naturellement, avant d'interpr\*'eter un syst\*`eme, il faut affecter une valeur \*`a tous les synonymes externes. La figure\ D\(hy5.2.1 donne quelques exemples valables de l'utilisation de synonymes externes. .RT .LP .sp 2 .rs .sp 15P .ad r \fBFigure D\(hy5.2.1 [T36.100] \ \ (\*`a traiter comme tableau MEP), p. 28\fR .sp 1P .RT .ad b .RT .LP .sp 3 .PP Le LDS offre deux constructions compl\*'ementaires qui permettent des choix plus puissants conditionn\*'es par des synonymes externes: .LP \(em construction SELECT: s\*'election conditionnelle d'une partie de sp\*'ecification. La condition est sp\*'ecifi\*'ee par une expression bool\*'eenne que l'on doit pouvoir \*'evaluer statiquement, avant l'interpr\*'etation du syst\*`eme. Elle est choisie lorsque l'expression est\ VRAIE; .LP \(em construction ALTERNATIVE: permet la s\*'election conditionnelle d'une partie de sp\*'ecification, entre deux options ou davantage. Elle ne peut \* | tre utilis\*'ee que pour choisir diff\*'erentes transitions dans le corps de processus, de proc\*'edures ou de services. .sp 2P .LP D.5.3 \fIServices\fR .sp 1P .RT .sp 1P .LP D.5.3.1 \fIConsid\*'erations g\*'en\*'erales\fR .sp 9p .RT .PP La notion de service vise \*`a offrir la possibilit\*'e de subdiviser une d\*'efinition de processus sans introduire de parall\*'elisme. Chaque service peut \* | tre consid\*'er\*'e comme une <> offerte par le processus. C'est une d\*'efinition de processus partielle repr\*'esentant un <> du processus. Ce <> constitue un \*'el\*'ement du comportement du processus global. En cons\*'equence, l'emploi du concept de service est une mani\*`ere de structurer un processus. .PP Il y a de nombreuses raisons de structurer un processus, par exemple en vue de g\*'erer la complexit\*'e et d'am\*'eliorer la lisibilit\*'e. Mais la subdivision constitue aussi un moyen d'isoler certaines parties d'un processus et de les d\*'ecrire s\*'epar\*'ement. Ces parties peuvent \* | tre des <> d'une fonction offerte par le syst\*`eme. Ainsi, gr\* | ce au concept de service, on peut isoler une fonction de syst\*`eme en d\*'ecrivant un ensemble de services subordonn\*'es dans un ou plusieurs processus. .bp .RT .LP .rs .sp 18P .ad r \fB\fR \fBFigure D\(hy5.3.1, p. 29\fR .sp 1P .RT .ad b .RT .PP A noter que le langage LDS ne poss\*`ede pas de facilit\*'es permettant de composer une fonction de syst\*`eme en choisissant des services de plusieurs processus. C'est \*`a l'utilisateur qu'il appartient de proc\*'eder \*`a cette composition, enti\*`erement en dehors du langage. .PP Un service, \*'etant isol\*'e d'autres services et d\*'ecrit comme une machine \*`a \*'etat fini dans son propre espace d'\*'etat, peut \* | tre d\*'evelopp\*'e et modifi\*'e sans que cela n'affecte d'autres services. Toutefois, il convient de relever que les services d'un processus ont souvent des donn\*'ees communes, ce qui signifie qu'ils peuvent influer les uns sur les autres par suite de manipulations de donn\*'ees. .PP Le comportement d'un processus n'\*'etat pas modifi\*'e lorsqu'il est subdivis\*'e en services, les services repr\*'esentent seulement une autre description du m\* | me comportement. On peut naturellement d\*'ecider au moment de la conception, de mod\*'eliser le comportement en plusieurs processus au lieu d'un seul. Toutefois, cela donnerait un comportement diff\*'erent car plusieurs processus fonctionnent en parall\*`ele et ne peuvent partager (lire et \*'ecrire) des donn\*'ees sans un \*'echange de signaux compliqu\*'e. .PP Il convient de noter que la structuration d'un processus en services ne signifie pas que ce processus dispara\* | tra enti\*`erement. Cela signifie seulement que le corps de processus, d\*'ecrivant le comportement du processus, a \*'et\*'e enti\*`erement remplac\*'e par plusieurs corps de service. Il restera au niveau du processus les param\*`etres formels, des d\*'eclarations et des d\*'efinitions formelles. En plus de ceux\(hyci, certaines d\*'efinitions et d\*'eclarations locales peuvent \* | tre reprises dans les d\*'efinitions de service. .PP Une d\*'efinition de service se compose des \*'el\*'ements suivants, dont certains sont facultatifs: .RT .LP \(em nom de service; .LP \(em ensemble de signaux d'entr\*'ee valides: liste d'identificateurs de signaux d\*'efinissant des signaux qui peuvent \* | tre re\*,cus par le service; .LP \(em d\*'efinitions de proc\*'edure: sp\*'ecification des proc\*'edures qui sont locales au service. On peut aussi utiliser une r\*'ef\*'erence de proc\*'edure; .LP \(em d\*'efinitions de donn\*'ees: sp\*'ecification de newtypes, syntypes et g\*'en\*'erateurs d\*'efinis par l'utilisateur et locaux au service; .LP \(em d\*'efinitions variables: d\*'eclaration de variables, locales au service. Ces variabls ne peuvent \* | tre r\*'ev\*'el\*'ees ou export\*'ees vers d'autres processus (les mots cl\*'es\ REVEALED et EXPORTED ne sont pas admis). Pour chaque variable d\*'eclar\*'ee, il faut sp\*'ecifier l'identificateur de sa sorte. Une valeur initiale peut \* | tre sp\*'ecifi\*'ee en option; .LP \(em d\*'efinitions de visibilit\*'e: d\*'eclaration des identificateurs de variables qui peuvent servir \*`a obtenir les valeurs des variables appartenant \*`a d'autres processus. Pour chaque identificateur de variables, la sorte de variable doit \* | tre sp\*'ecifi\*'ee; .LP \(em d\*'efinitions d'import: sp\*'ecification d'identificateurs de variables appartenant \*`a d'autres processus, que le service d\*'esire importer. Pour chaque identificateur, la sorte de variable doit \* | tre sp\*'ecifi\*'ee; .bp .LP \(em d\*'efinitions de temporisateur: voir le \(sc\ D.3.11; .LP \(em d\*'efinitions de macro: voir le \(sc\ D.5.1; .LP \(em corps de service: sp\*'ecification du comportement r\*'eel du service en ce qui concerne les \*'etats, les entr\*'ees, ls sorties, les t\* | ches, etc. Compar\*'e \*`a un corps de processus, un corps de service peut aussi contenir l'\*'emission et la r\*'eception de signaux prioritaires (\(sc\ D.5.3.2). .PP En LDS/GR, une d\*'efinition de service est repr\*'esent\*'ee \*`a l'aide d'un diagramme de service. Celui\(hyci comprend les \*'el\*'ements suivants: .LP \(em un symbole de cadre facultatif: symbole de forme rectangulaire qui contient tous les autres symboles; .LP \(em l'en\(hyt\* | te de service: le mot cl\*'e SERVICE suivi par l'identificateur de service. L'en\(hyt\* | te de service est plac\*'e dans l'angle sup\*'erieur gauche du cadre; .LP \(em une num\*'erotation de page facultative (plac\*'ee dans l'angle sup\*'erieur droit); .LP \(em des symboles de texte: un symbole de texte est utilis\*'e pour contenir des d\*'efinitions de donn\*'ees, de variables, de visibilit\*'e, d'import et de temporisateur qui sont locales au service; .LP \(em r\*'ef\*'erences de proc\*'edure: symbole de proc\*'edure contenant un nom de proc\*'edure repr\*'esentant une proc\*'edure, locale au service et d\*'efinie s\*'epar\*'ement; .LP \(em diagramme de macro: voir les directives du \(sc\ D.5.1; .LP \(em graphe de service: sp\*'ecification du comportement r\*'eel du service en ce qui concerne les \*'etats, les entr\*'ees, les sorties, les t\* | ches, etc. Compar\*'e au graphe de processus, un graphe de service peut aussi contenir l'\*'emission et la r\*'eception de signaux prioritaires (\(sc\ D.5.3.2). .PP Un exemple de concept de service est donn\*'e dans la figure\ D\(hy5.3.2 pour le processus simple <> (Timer). Ce processus est structur\*'e en deux services qui sont rep\*'er\*'es et d\*'efinis en deux diagrammes de service (voir la figure\ D\(hy5.3.3). .LP .rs .sp 30P .ad r \fBFigure D\(hy5.3.2, p. 30\fR .sp 1P .RT .ad b .RT .LP .bp .PP L'acheminement du signal <> transportant un signal prioritaire (\(sc\ D.5.3.2) constitue une interface interne entre les deux services. .LP .rs .sp 43P .ad r \fBFigure D\(hy5.3.3, p. 31\fR .sp 1P .RT .ad b .RT .PP Il convient de noter que, les actions (sorties) \*'etant comrpises dans la transition de d\*'epart dans le premier service, aucune action n'est autoris\*'ee dans la transition de d\*'epart du second service. .PP On trouvera un autre exemple du concept de service au \(sc\ D.10. .bp .RT .sp 1P .LP D.5.3.2 \fISignaux prioritaires\fR .sp 9p .RT .PP Un signal prioritaire est employ\*'e pour la communication entre deux transitions dans des services diff\*'erents d'un processus lorsqu'aucun signal ext\*'erieur (provenant d'autres processus) ne peut \* | tre absorb\*'e dans le laps de temps entre les transitions. Ainsi, les transitions sont <>. .PP La figure D\(hy5.3.4 est une illustration de la concat\*'enation des transitions lorsque des signaux prioritaires sont utilis\*'es. .RT .LP .rs .sp 40P .ad r \fBFigure D\(hy5.3.4, p. 32\fR .sp 1P .RT .ad b .RT .PP La construction permettant d'obtenir des signaux prioritaires utilisant la file d'atente d'entr\*'ee ordinaire est d\*'ecrite dans la Recommandation. Les signaux prioritaires, \*'emis vers un \*'etat pr\*'eliminaire, peuvent \* | tre trait\*'es comme des signaux ordinaires et provoquent des transitions vers l'\*'etat principal (voir aussi le \(sc\ D.5.3.3.1). .bp .PP L'exemple suivant est une illustration des cons\*'equences de l'emploi de signaux prioritaires. L'exemple est expliqu\*'e sans l'emploi du mod\*`ele <<\*'etat pr\*'eliminaire principal>>. .PP Le diagramme de s\*'equencement (voir la figure\ D\(hy5.3.5) est obtenu de l'interaction entre les services du processus <> d\*'ecrit au \(sc\ D.10.2. .RT .LP .rs .sp 35P .ad r \fBFigure D\(hy5.3.5 et l\*'egende, p. 33\fR .sp 1P .RT .ad b .RT .PP Le tableau contient \*`a la fois les signaux en provenance ou \*`a destination de l'environnement du processus et les signaux prioritaires entre les services. Les fl\*`eches de signaux (de haut en bas) indique comment les signaux sont plac\*'es dans la file d'attente. Les lignes verticales en traits \*'epais indiquent comment l'ex\*'ecution des transitions s'ordonne dans le temps. .PP La s\*'equence d\*'ebute avec le signal <> en provenance du registre, ce qui signifie que l'appel doit \* | tre rejet\*'e. Cela signifie aussi le rejet imm\*'ediat de l'appel suivant. .PP La figure montre qu'une transition, activ\*'ee par un signal prioritaire, par exemple <>, commence avant l'activation d'une transition par un signal ordinaire, par exemple <>, malgr\*'e l'ordre inverse de celui de sa mise en file d'attente. La transition activ\*'ee par le signal <> d\*'econnecte la ligne d'abonn\*'e, ce qui signifie que l'appel suivant (signal <>) sera imm\*'ediatement rejet\*'e. .bp .PP Dans le diagramme de s\*'equencement ci\(hyapr\*`es, nous avons la m\* | me situation mais le diagramme n'utilise pas de signaux prioritaires. Il y a interfonctionnement entre les services et les signaux ordinaires. .RT .LP .rs .sp 33P .ad r \fBFigure D\(hy5.3.6 et l\*'egende, p. 34\fR .sp 1P .RT .ad b .RT .PP Nous pouvons voir que l'ordre des transitions a \*'et\*'e modifi\*'e par rapport \*`a la figure\ D\(hy5.3.5. L'appel suivant arrive avant la d\*'econnexion de la ligne d'abonn\*'e, ce qui signifie que l'appel ne sera pas imm\*'ediatement rejet\*'e. .sp 1P .LP D.5.3.3 \fITransformation\fR .sp 9p .RT .PP Le service et le signal prioritaire sont des notions compl\*'ementaires car ils sont compos\*'es (mod\*'elis\*'es) \*`a partir de notions plus fondamentales du\ LDS, comme le processus et le signal. Pour pouvoir interpr\*'eter s\*'emantiquement le service et le signal de priorit\*'e, ils doivent se transformer \*`a nouveau en ces notions de base. Normalement, cette transformation ne doit pas \* | tre ex\*'ecut\*'ee par l'utilisateur, tout au moins manuellement, mais celui\(hyci doit naturellement en \* | tre conscient. Dans un outil de contr\* | le s\*'emantique du service, la transformation pourrait s'effectuer automatiquement. .PP Apr\*`es la transformation, les services ont disparu et sont remplac\*'es par une d\*'efinition de processus \*'etendue qui peut \* | tre interpr\*'et\*'ee s\*'emantiquement. La transformation a d\*'efini le comportement. .bp .RT .sp 1P .LP D.5.3.3.1 \fITransformation d'\*'etats\fR .sp 9p .RT .PP La Recommandation donne des r\*`egles sp\*'ecifiques pour la transformation d'\*'etats. Le r\*'esultat de ces r\*`egles est que le nombre d'\*'etats du processus est le produit du nombre d'\*'etats qui se trouvent dans les services. .PP En outre, l'emploi de signaux prioritaires doublera ce produit car chaque \*'etat transform\*'e est divis\*'e en un \*'etat pr\*'eliminaire et un \*'etat principal. .PP Ce doublement du nombre des \*'etats est d\* | aux signaux prioritaires qui ne sont pas trait\*'es dans l'exemple suivant de transformation d'\*'etats. .PP Dans bien des cas, de nombreux \*'etats du processus <> ne sont pas pertinents et l'espace d'\*'etat peut \* | tre r\*'eduit. Cela est trait\*'e dans l'exemple suivant, tir\*'e du \(sc\ D.10.2. .PP Dans le processus <>, nous avons 4 services: <>, <>, <> et <>. Le nombre d'\*'etats est de\ 10, 5,\ 3 et\ 2, c'est\(hy\*`a\(hydire 20\ au total. .PP Appliquant \*`a ces services les r\*`egles 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 arrang\*'ees selon la figure\ D\(hy5.3.7. .RT .LP .rs .sp 14P .ad r \fBFigure D\(hy5.3.7, p. 35\fR .sp 1P .RT .ad b .RT .PP Tous les noms d'\*'etat possibles dans les diff\*'erentes positions donnent 300\ combinaisons. .LP Ex. .LP .LP .LP . | | | .LP .LP .LP .LP . | | | .LP .LP . | | | .LP . | | | .LP .PP Beaucoup de ces combinaisons ne sont pas pertinentes car une ligne d'abonn\*'e ne pourra jamais \* | tre utilis\*'ee \*`a la fois pour l'abonn\*'e\ A et l'abonn\*'e\ B au cours du m\* | me appel. Cela signifie que les 10\ \*'etats des `A \(ulsubscriber actions` ne peuvent \* | tre combin\*'es qu'avec un seul \*'etat des `B \(ulsubscriber actions` c'est\(hy\*`a\(hydire `B \(ulIDLE`. Cela signifie en outre que les 5\ \*'etats de `B \(ulsubscriber actions` ne peuvent \* | tre combin\*'es qu'avec un seul \*'etat de `A \(ulsubscriber actions` (A \(ulIDLE). Le nombre d'\*'etats pertinents est donc de (10*1*3*2)\ +\ (1*5*3*2)\ =\ 90. .bp .PP Une r\*'eduction de l'espace d'\*'etat, comme dans l'exemple ci\(hydessus, d\*'epend du cas dont il s'agit et ne peut faire l'objet de r\*`egles g\*'en\*'erales formelles, applicables en vue d'une transformation automatique. Cependant, si la transformation est ex\*'ecut\*'ee manuellement, il est probable que l'espace d'\*'etat peut \* | tre r\*'eduit. Ainsi, lorsque l'on compare la complexit\*'e d'un processus con\*,cu sans services \*`a celle du m\* | me processus subdivis\*'e en services, il convient d'utiliser le processus \*`a espace d'\*'etat r\*'eduit pour obtenir une bonne base de comparaison. Dans la plupart des cas, le recours aux services permettra de r\*'eduire consid\*'erablement le nombre des \*'etats. .RT .sp 1P .LP D.5.3.3.2 \fITransformation de transitions\fR .sp 9p .RT .PP La Recommandation contient des r\*`egles sp\*'ecifiques applicables \*`a la transformation de transitions. L'exemple qui suit illustre les modalit\*'es de transformation. Le processus de cet exemple est une sp\*'ecification d'un protocole simple. Le processus est subdivis\*'e en deux services, \*'emission (send) et r\*'eception (receive). .RT .LP .rs .sp 41P .ad r \fBFigure D\(hy5.3.8 et l\*'egende, p. 36\fR .sp 1P .RT .ad b .RT .LP .bp .PP La figure D\(hy5.3.9 est un diagramme synoptique d'\*'etat pour les deux services. Les transitions sont num\*'erot\*'ees de\ 1 \*`a\ 7. .LP .rs .sp 19P .ad r \fBFigure D\(hy5.3.9, p. 37\fR .sp 1P .RT .ad b .RT .PP Si l'on applique les r\*`egles formelles de transformation d'\*'etats et de transitions, on obtient pour le processus le diagramme synoptique d'\*'etat ci\(hyapr\*`es. Aucun signal prioritaire n'est utilis\*'e, de sorte qu'il n'est pas n\*'ecessaire de diviser plus avant les \*'etats en \*'etats pr\*'eliminaires et \*'etats principaux et cela n'est donc pas indiqu\*'e. .LP .rs .sp 17P .ad r \fBFigure D\(hy5.3.10, p. 38\fR .sp 1P .RT .ad b .RT .PP Le nombre d'\*'etats ne peut \* | tre r\*'eduit et le graphe de processus est repr\*'esent\*'e dans la figure\ D\(hy5.3.11. Les noms d'\*'etats du graphe de processus correspondent aux multiplets de noms de la figure\ D\(hy5.3.10. .PP \fIExemple\fR \ \(em\ IS.IR correspond \*`a IDLE \(ulS.IDLE \(ulR. .bp .RT .LP .rs .sp 47P .ad r \fBFigure D\(hy5.3.11 et l\*'egende, p.\fR .sp 1P .RT .ad b .RT .LP .bp