5i' MONTAGE: FIN DU S D.6.4.6 EN-T | TE DE CETTE PAGE D.7 Directives supplementaires pour le dessin et l'ecriture La Recommandation specifie la maniere de representer chacun des concepts du LDS. Par exemple, le concept de t | che est represente en LDS/GR au moyen d'un rectangle et du mot-cle TASK en LDS/PR. Les Directives pour les usagers completent la Recommandation en specifiant des regles de dessin et d'ecriture applicables a tous les concepts, afin de souligner ce qui peut | tre considere comme approprie, incorrect ou peu pratique. D.7.1 Directives pour le LDS/GR D.7.1.1 Considerations generales Les directives generales applicables a l'etablissement de diagrammes sont les suivantes: - la sequence de lecture doit se presenter de haut en bas et de gauche a droite; - les diagrammes ne doivent pas contenir trop d'informations au m | me niveau. Il est souvent souhaitable de sub- diviser de grands diagrammes en sous-diagrammes traitant des differentes parties ou aspects, par exemple en utilisant le mecanisme de reference. D.7.1.2 Points d'entree et de sortie Les points d'entree et de sortie vers ou d'un symbole doivent | tre traces verticalement (ce qui correspond a la lecture de haut en bas) et c'est seulement lorsque cela n'est pas pratique que l'on peut utiliser des points d'entree et de sortie horizontaux. Les exceptions a cette regle generale sont les suivants: - les decisions comportant deux ou trois points de sortie sont generalement representees avec deux points de sortie horizontaux (plus un point vertical); - les appels de macro utilisent des connexions hor- izontales et verticales. - les connecteurs d'entree et de sortie ont generalement des points d'entree et de sortie horizontaux. Des lignes diagonales ne devraient se presenter que dans des cas exceptionnels (par exemple pour des canaux et des acheminements de signaux). Les points d'entree et de sortie verticaux devraient diviser le symbole en deux parties ayant la m | me longueur horizontale. Figure D-7.1.1, p. 1 Figure D-7.1.2, p. 2 D.7.1.3 Symboles a) Les symboles devraient | tre traces de telle sorte que les axes vertical et horizontal coincident avec les deux axes du papier. b) La symetrie verticale des symboles est seule- ment autorisee pour les symboles d'entree, de sortie, d'extension de texte et de commentaire (voir la figure D-7.1.3). c) Le rapport general entre la hauteur et la longueur de tous les symboles dans les graphiques ainsi que pour les symboles de reference est de 1 | | . Figure D-7.1.3, p. 3 D.7.1.4 Gabarit On trouvera a l'interieur de la couverture arriere du present fascicule un gabarit permettant le trace graphique des symboles du LDS/GR. Une representation schematique de ce gabarit est donnee dans la figure D-7.1.4. Figure D.7.1.4, p. 4 Cette figure reproduit directement et en trois formats (20 x 40 mm, 20/ [ two formulas deleted ] suivants: Entree, Sortie, Decision, Option, Processus, Debut, T | che, Etat, Mise en reserve, Reference de service, Connecteur et Arr | t. Les cotes interieures des symboles de grand format sont indiquees. On peut realiser les symboles correspondant a l'Appel de Procedure, Macro et Creer a partir du symbole T | che en tracant la(les) ligne(s) horizontale(s) ou verticale(s) supplementaire(s) indiquee(s) dans la figure. Il est possible de construire le symbole de debut de procedure a partir du symbole de debut de processus en tracant les lignes verticales supplementaires indiquees. Le symbole de retour est une combinaison des symboles de con- necteur et d'arr | t. Les symboles de commentaire, d'extension de texte et de liste de signaux sont traces a l'aide du symbole T | che. Les symboles d'entree et de sortie prioritaires peuvent | tre construits a partir des symboles d'entree et de sortie avec l'adjonction de la ligne supplementaire indiquee. Le symbole de reference de procedure peut | tre construit a partir du symbole de reference de processus avec l'adjonction de deux traits verticaux supplementaires comme indique. Les symboles de condition de validation et de signal continu peuvent | tre traces a l'aide du symbole d'arr | t. Les canaux, les acheminements de signaux et les lignes vers le symbole d'extension de texte sont traces en traits pleins. La ligne vers un commentaire de symbole est tracee en trait discontinu avec un rapport 1 | | . Le symbole de texte est trace a l'aide du symbole de T | che, l'angle superieur droit etant plie comme indique. Tous les symboles recommandes sont definis dans la Recommanda- tion. On trouvera un apercu des symboles recommandes dans l'annexe C - Resume de la syntaxe graphique. Les trois dimensions indiquees sont a preferer. Si d'autres dimensions sont utilisees, le rapport devrait | tre le m | me (c'est-a-dire 1 | | ). Les tailles indiquees, c'est-a-dire une longueur de 40 mm, 28 mm et 20 mm permettent la reduction photographique du format A3 au format A4 avec des tailles de symbole compatibles (car 40 mm/ [ Formula deleted ] = 28 mm et 28 mm/ [ formula deleted ] = 20 mm). D.7.2 Directives applicables au LDS/PR Les directives generales applicables a l'ecriture de LDS tex- tuel sont les suivantes: - la sequence de lecture devrait se presenter de haut en bas et de gauche a droite; - le texte devrait | tre divise en parties traitant de differents aspects; - les commentaires sur le niveau des instructions devraient commencer dans la m | me colonne; - les lignes devraient | tre en retrait. L'indentation peut suivre la hierarchie courante des concepts du LDS comme indique dans l'exemple de la figure D-7.1.5. Figure D-7.1.5 [T40.100], p. 5 D.8 Documentation D.8.1 Introduction L'ISO definit un document comme etant <>. On peut donc le considerer comme une unite logique strictement delimitee. Les documents servent a vehiculer toutes les informations relatives a un systeme specifie ou decrit en LDS. Lorsque le papier sert de support physique au stockage d'un document, on applique souvent improprement le terme <> aux feuilles de papier plut | t qu'a leur contenu logique. L'emploi des supports de stockage magnetiques se repandant, ce terme retrouve petit a petit sa signification initiale. La presente section traite des aspects relatifs a la documen- tation. Elle aborde plut | t l'organisation logique des documents que leur organisation physique. Ce dernier point est laisse a la discretion de l'usager. Du fait de la ressemblance entre les condi- tions exigees par l'organisation logique et par l'organisation phy- sique des documents, les conseils contenus dans le texte ci-apres peuvent utilement aider un usager a mettre en place une organisa- tion physique de documents. En subdivisant l'information en un nombre approprie de docu- ments, on peut rendre le systeme plus lisible et d'un maniement plus commode. Le langage ne recommande pas certains documents ni des struc- tures de document. Toutefois, certaines propositions sont presentees afin d'aider l'utilisateur a traiter les documents. D.8.2 Types de representation de systeme Le resultat de la specification d'un systeme en LDS est un ensemble de definitions en LDS/GR et/ou LDS/PR. Ces definitions peuvent | tre embo | tees ou sequentielles, selon le type de representation de systeme, hierarchique ou a plat. Dans les figures D-8.2.1 et D-8.2.2, un systeme est decrit avec deux variantes de representation en LDS/GR. Les deux figures ne sont pas des specifications completes de systeme etant donne que, pour des raisons de simplicite, seules les entrees et les sorties sont indiquees et que les definitions eventuelles de signaux et de donnees ont ete omises. Naturellement, il est possible de recourir a une combinaison de presentation pour specifier un systeme. Lorsque les definitions sont sequentielles comme dans la figure D-8.2.1, elles sont <>, mecanisme possible pour les definitions aussi bien en LDS/PR qu'en LDS/GR. Si nous considerons la specification de systeme comme un ensemble de definitions, un document peut | tre considere comme contenant ces definitions. Si le systeme est petit et hierarchise comme dans la figure D-8.2.2, un seul document suffit. Si la representation a plat est utilisee comme dans la figure D-8.2.1 il faut utiliser plus d'un document, par exemple un document par definition. Lorsque l'on choisit le type de representation de systeme, il faut considerer le type de document souhaite. Pour avoir un docu- ment par definition, il faut une representation a plat. Si l'on desire disposer de l'ensemble de la specification de systeme sur un seul document, il faut une representation structuree. Le cas normal est probablement une combinaison de ces representations. Pour decider des proportions de cette combinaison, il faut appliquer les regles suivantes: 1) une definition ne doit pas | tre divisee en plusieurs documents; 2) si l'on veut faire figurer une definition dans un document separe, elle doit | tre referencee et non embo | tee (voir la figure D-8.2.3); 3) lorsque l'on applique le concept logique de page pour diviser un diagramme en plusieurs pages de diagrammes, celles-ci devraient coincider avec les pages reelles du document (voir la figure D-8.2.4); 4) si un diagramme a plus d'une page, il doit | tre reference et non embo | te. D.8.3 Structure des documents L'ensemble de documents traitant de toute la definition du systeme peut | tre structure. Une structure de documents, lorsque ceux-ci se referent a des sous-documents, peut | tre jointe a toute entite dans le systeme telle que sous-systeme, bloc ou pro- cessus (voir la figure D-8.3.1). Figure D-8.2.1a, p. 6 Figure D-8.2.1b, p. 7 Figure D-8.2.2, p. 8 Figure D-8.2.3, p. 9 Figure D-8.2.4, p. 10 Figure D-8.3.1, p. 11 D.8.4 Mecanisme de reference Le mecanisme de reference dans le langage, lorsque des noms de concept sont utilises pour reference entre les concepts, peut aussi | tre utilise pour des references entre documents. C'est une approche naturelle lorsque le document coincide avec une definition. D.8.5 Classification des documents Les documents peuvent | tre classes conformement aux types de definitions qu'ils contiennent. Dans cette classification, il convient de placer au moins dans des documents separes les definitions de processus ou de service decrivant le comportement dynamique du systeme. Ces documents peu- vent aussi comporter des definitions de variables. On trouvera dans la figure D-8.5.1 un exemple de structure de document pour un systeme. Dans cet exemple, les definitions de canal et d'acheminement de signal sont comprises dans le document pour les definitions de systeme, de bloc et de processus. Les definitions de systeme, les definitions de donnees et les definitions de listes de signaux sont placees dans des documents separes et il a ete admis que toutes les definitions de donnees se trouvent au niveau du systeme. Les definitions de procedures, les definitions de macros et les definitions de service forment des sous-documents du document de processus. Figure D-8.5.1, p. 12 Si differents services forment ensemble une fonction de systeme, ils peuvent | tre decrits dans un document commun. Les differentes definitions de service peuvent | tre placees l'une apres l'autre dans un document de service mais il est egale- ment possible de les placer l'une a c | te de l'autre sur la m | me page de document. Cette derniere presentation permet une comprehension satisfaisante de l'interaction entre les services. La figure D-8.5.2 constitue un exemple de page de document dans un document de service. Pour de grandes specifications de systemes, il convient de prevoir une <> pour le systeme afin d'indiquer ou l'on trouvera les etats, les entrees, les sorties, etc. De plus, la table des matieres devrait porter tous les concepts, c'est-a-dire indiquer l'emplacement des definitions et la maniere dont elles sont utilisees. Cela s'applique notamment au systeme, aux blocs, aux canaux, aux signaux, aux processus, aux services, aux macros et aux procedures. De telles tables des matieres de systeme peuvent constituer des documents separes. Figure D-8.5.2, p. 13 D.8.6 Combinaison de LDS/GR et de LDS/PR Il est possible d'utiliser ensemble le LDS/GR et le LDS/PR pour specifier un systeme. Les concepts de systeme, de bloc, de processus, de service, de procedure, de macro, de canal, etc. peuvent | tre specifies soit dans l'une, soit dans l'autre de ces versions du LDS. On passe du LDS/PR au LDS/GR ou vice versa en recourant au mecanisme de reference du langage. Un concept qui est reference en LDS/PR peut | tre specifie en LDS/GR et un concept reference en LDS/GR peut | tre specifie en LDS/PR. La figure D-8.6.1 est une specification de systeme <> utilisant une combinaison de LDS/PR et de LDS/GR. C'est le m | me systeme que dans les figures D-8.2.1 et D-8.2.2. Chaque definition de l'exemple peut | tre situee dans un document separe. Figure D-8.6.1a, p. 14 Figure D-8.6.1b, p. 15 D.9 Mise en correspondance La presente section decrit certains aspects de mise en correspondance du LDS et du CHILL (voir le S D.9.1), du LDS/GR et du LDS/PR (voir le S D.9.2). D.9.1 Mise en correspondance du LDS et du CHILL Les paragraphes qui suivent decrivent diverses possibilites de mise en correspondance du LDS et du CHILL. Ces solutions sont donnees succinctement et ne sont pas exhaustives; dans la pratique, rien ne s'oppose a ce qu'on ait recours a d'autres methodes. L'examen de la mise en concordance doit porter non seulement sur le compilateur CHILL disponible et sur la machine cible, mais aussi sur des considerations d'ordre plus general. La mise en con- cordance est une activite intellectuelle tres complexe et ce n'est que par l'experience que les concepteurs/programmeurs pourront decider de la structure de programme CHILL a utiliser pour mettre en oeuvre une representation en LDS donnee. Cela est valable egale- ment pour la representation des fonctions mises en oeuvre par un programme CHILL. Une correspondance d'element a element (si elle est realisable) n'est pas necessairement la meilleure maniere d'utiliser le LDS pour representer les fonctions mises en oeuvre par le CHILL. Sur la base de cette approche, la structure globale d'un pro- gramme CHILL tire d'un diagramme en LDS est presentee dans la figure D-9.1.1. Figure D-9.1.1 [T41.100], p. 16 Des exemples de schemas de mise en correspondance de construc- tions des deux langages sont illustres aux figures D-9.1.2 a D-9.1.5. Ils concernent les constructions LDS suivantes: - etat et reception ou mise en reserve des sig- naux; selection d'un etat suivant; - sortie; - branchement; - decision. Le module de declaration contient a la fois la definition et la declaration de tous les signaux employes dans le diagramme LDS qui sont transformes et de toutes les variables qui leur sont associees: toutes ces variables sont octroyees au module qui represente le bloc fonctionnel du diagramme LDS. Le module du bloc fonctionnel represente le comportement (par- tie procedurale) des processus du LDS. Dans ce schema de traduction, chaque processus du LDS est represente par une boucle infinie: une variable nommee <> indique l'etat a examiner et une variable nommee <> indique des points de branchement possibles qui determinent des ensembles communs d'instructions. On choisit au moyen de la construction CASE de CHILL, la valeur de l'etat suivant; chaque entree du CASE identifie un etat du LDS. Pour chaque entree, on choisit entre les signaux d'entree possibles. Chaque signal d'entree determine la serie d'actions a accomplir, (<>). Chaque chemin de transition se termine par une affectation soit de la variable <>, determinant ainsi directe- ment l'etat suivant a examiner, soit de la variable <>. Une autre boucle de selection sur la valeur actuelle de la variable <> permet a chaque transition de prendre fin, au sens du LDS, et a la fin, affecte une valeur a la variable etat _suivant. Figure D-9.1.2, p. 17 L'un des problemes principaux dans la relation entre LDS et CHILL reside dans la semantique differente de la reception des sig- naux: en fait, alors que le CHILL ne consomme pas (et par consequent ne detruit pas) les signaux a moins qu'ils ne soient recus (signaux persistants), le processus LDS consomme (et par consequent detruit) tous les signaux recus jusqu'a ce qu'il y ait concordance avec l'une des entrees enumerees pour cet etat. La difference de semantique a ete resolue en introduisant la fonction predefinie: GETOUT comme une alternative (chemin ELSE) dans la con- struction CHILL RECEIVE CASE, comme indique a la figure D-9.1.2. La fonction predefinie GETOUT du CHILL qui conna | t (par parametres) la liste des signaux d'entree et de mise en reserve, detruit les autres signaux disponibles au processus lorsque ce dernier est appele. Apres l'execution de la fonction GETOUT le selecteur d'etat est mis a 1 de facon a repeter la boucle pour cet etat jusqu'a ce qu'un signal d'entree valable soit selectionne (ou arrive, s'il n'est pas deja present). Figure D-9.1.3, p. 18 Par exemple, une fois que le signal de sortie SGA, a la figure D-9.1.3, a ete reconnu, l'instance appropriee du processus destinataire pour le signal SGB est choisie et le signal SGB est envoye. Avant d'envoyer le signal SGB, il peut | tre necessaire de remplir certains champs d'information qui doivent | tre achemines par le signal. Cela peut | tre fait immediatement avant ou, bien plus longtemps avant l'envoi du signal. Quand il existe un point de branchement dans le diagramme (voir la figure D-9.1.4), on affecte a la variable <> la valeur appropriee. Ainsi qu'il a ete explique dans la figure D-9.1.1, une boucle sur la variable liaison est executee pour determiner le prochain etat a examiner. Dans l'optique du langage de programmation, on peut considerer un point de branchement comme une construction <> (aller a); la collecte de tous les points de branchement afin qu'ils puissent | tre examines, permet d'ecrire entierement le squelette de programme sans faire intervenir de <>, ce qui en facilite la lecture. Figure D-9.1.4, p. 19 Une decision en LDS se traduit directement dans la construc- tion CASE de CHILL, comme indique a la figure D-9.1.5. Figure D-9.1.5, p. 20 D.9.2 Mise en correspondance de GR et PR Compte tenu des restrictions susmentionnees relatives aux mac- ros (S D.5.1), la version en GR peut toujours | tre mise en correspondance avec le PR et vice versa. On trouvera dans tout le present texte des specifications equivalentes exprimees sous ces deux formes. D.10 Exemples d'application D.10.1 Introduction Le S D.10 contient certains exemples d'utilisation du LDS. Les exemples sont tires de domaines d'application des telecommunications et mettent en oeuvre differents sous-ensembles du LDS. On s'est efforce de prendre des exemples pratiques et de traiter autant de concepts LDS que possible. Les exemples sont destines a illustrer l'utilisation du LDS mais ne constituent pas des specifications internationales. D.10.2 Le concept de service Le systeme presente ci-apres est une illustration du concept de service. Dans ce systeme, trois <> presentent un inter | t particulier dans cet exemple. Ce sont, une fonction d'ecoulement du trafic, une fonction de maintenance et une fonction d'alarme. La figure qui suit, D-10.2.1, illustre la maniere dont ces fonctions de systeme se composent de services subordonnes comportant cinq differents processus et cinq blocs. Figure D-10.2.1, p. 21 La fonction d'ecoulement du trafic comprend l'etablissement et la terminaison d'un appel telephonique. Cet exemple ne constitue pas une documentation complete des fonctions au niveau du systeme mais simplement une description des quatre services compris dans le processus <>. Les trois figures suivantes sont des diagrammes de systeme (figure D-10.2.2), le diagramme de bloc de <> (figure D-10.2.3) et le diagramme de processus de <> (figure D-10.2.4). Les canaux, acheminements de signaux et signaux necessaires sont representes dans ces diagrammes. Blanc Figure D-10.2.2 [T42.100], p. 22 Figure D-10.2.3, p. 24 Comme on peut le voir dans le diagramme de processus (figure D-10.2.4), il y a interfonctionnement des services avec les signaux prioritaires par les acheminements de signaux IR01, IR02, IR03 et IR04. Il y a egalement une interaction entre les services, qui influent les uns sur les autres, au moyen de la variable <> <> declaree dans le processus. Blanc Figure D-10.2.4 [T43.100], p. 25 Pour aider a mieux comprendre le r | le de ces services et l'interaction entre les blocs, on a ajoute dans cet exemple plusieurs diagrammes de sequencement. Les deux premiers diagrammes de sequencement illustrent le cas normal d'interaction entre les blocs au cours d'un appel. L'interaction en cas d'encombrement des enregistreurs est presentee dans le troisieme diagramme. Pour simplifier les diagrammes, on a admis qu'il n'y avait pas de delai entre l'emission et la reception d'un signal (voir les figures D-10.2.5 et D-10.2.6). Figure D-10.2.5, p. 27 Figure D-10.2.6, p. 28 L'interaction entre les services du processus <> est decrite dans les diagrammes de sequencement qui suivent (voir les figures D-10.2.7 et D-10.2.8). Figure D-10.2.7, p. 29 Figure D-10.2.8, p. 30 Le comportement de chaque service du processus <> est decrit dans les quatre diagrammes de service (voir les figures D-10.2.9 a D-10.2.1.5). Blanc Figure D-10.2.9, [T44.100], p. 31 Figure D-10.2.10, p. 33 Figure D-10.2.11, p. 34 Figure D-10.2.12 [T45.100], p. 35 Figure D-10.2.13, p. 37 Figure D-10.2.14 [T46.100], p. 38 Figure D-10.2.15 [T47.100], p. 40 D.11 Outils pour le LDS D.11.1 Introduction Ce paragraphe presente une serie d'outils de soutien pour le LDS. Ces outils peuvent aider a la production de documents, de diagrammes LDS (forme GR) ou de listes imprimees (forme PR), et/ou a la validation des representations LDS. Ces directives ne contiennent pas une liste exhaustive de tous les outils eventuels. Les outils necessaires dependent de la methode choisie par l'usager. En principe, le LDS peut | tre utilise sans outils. Toutefois, la complexite inherente des systemes modernes est telle que les representations LDS se revelent souvent compliquees. De ce fait, il est necessaire de disposer d'outils automatiques pour preparer la specification, la conception et la documentation de plusieurs systemes. Par exemple, la complexite et le co | t des traces manuels, et eventuellement, la mise a jour des documents graphiques d'un central de commutation seraient reduits de facon significative, gr | ce a l'utilisation d'aides appropriees. En raison des considerations ci-dessus, le LDS a ete concu de facon a integrer l'utilisation efficace d'outils de soutien. D.11.2 Categories d'outils Les outils LDS peuvent | tre classes en fonction des activites effectuees dans le cadre de la production de documents LDS, par exemple: - Outils pour l'entree: selon les formes syntax- iques, nous disposons d'aides d'entree pour les graphiques LDS, sous forme de phrases de texte ou d'illustrations. - Outils pour la verification syntaxique: ils comprennent notamment des analyseurs de syntaxe, pour chacune des deux syntaxes. - Outils pour la production de documents: une fois les documents LDS enregistres sur ordinateur, les outils peuvent y avoir acces et les reproduire, en utilisant eventuellement plusieurs peripheriques. Ces derniers peuvent utiliser une forme syntaxique differente de celle utilisee pour introduire le docu- ment. En outre, les outils peuvent produire des documents a partir de ceux initialement introduits. - Outils de modelisation et d'analyse des systemes: a partir des documents LDS representant un systeme, on peut tirer un modele du systeme. Des verifications peuvent | tre faites sur ce modele. Les outils peuvent rechercher les blocages, faire des comparaisons entre les divers modeles du m | me systeme (soit, par exemple, entre une specification et une description) ou executer une simulation du fonctionnement du systeme, etc. - Outils pour la generation de code: des representations LDS tres detaillees peuvent | tre utilisees aux fins d'elaboration du logiciel. Les outils peuvent | tre concus de facon a pouvoir executer de facon guidee et semi-automatique une sequence de code. Il existe egalement une categorie d'outils specifiques mais utiles: - Les outils de formation au LDS: ils peuvent | tre utilises soit seuls, soit integres a d'autres outils. Cette integration permet de les utiliser pour d'autres fonctions, si necessaire. Etant donne que le LDS est utilise pour plusieurs phases du cycle de vie des systemes, il est facile de voir l'utilisation qui peut | tre faite de tous les types d'outils dans un environnement integre de projet. D.11.3 Entree des documents Aucune specification particuliere n'est requise pour l'introduction de la forme textuelle de phrases du LDS, etant donne que la syntaxe PR equivaut, du point de vue de l'entree, a toute entree de cha | ne de caracteres. En consequence, on peut utiliser les m | mes outils (editeurs de textes). Les deux autres syntaxes supposent toutefois une possibilite de traitement graphique. C'est un fait qu'il est avantageux de disposer d'outils de soutien pour l'introduction du PR, mais il est indispensable d'avoir des outils de soutien pour l'introduction du GR/PE si nous prevoyons d'utiliser ces syntaxes comme moyens d'entree. Un editeur graphique est toujours necessaire pour des fonc- tions telles que la connexion de deux symboles, le deplacemnt d'une serie de symboles vers une autre partie de la page ou vers d'autres pages, et pour assurer l'encha | nement des suppressions (la suppression d'un symbole entra | ne la suppression de la connexion a ce symbole). Comme pour les outils PR, les outils d'entree GR/PE devront | tre concus sur le modele de la semantique/syntaxe LDS. En consequence, il devrait eliminer les connexions non valables et pousser les usagers a remplir toutes les parties non completes, etc. Lors de la conception des outils, on est confronte a plusieurs problemes dus aux contraintes physiques des appareils graphiques tels que la <>. Il est presque impossible de disposer d'un nombre suffisant de caracteres qui soient lisibles tout en permettant la visualisation d'un nombre raisonnable de symboles sur l'ecran. Il faudrait passer en revue les solutions telles que zoom sur fen | tre ou defilements, mais ces solutions ne sont pas totalement satisfaisantes. On peut estimer qu'il n'est pas necessaire d'avoir un haut niveau de resolution lorsque les diagrammes sont reproduits par l'usager, mais cela devient tres souhaitable si les diagrammes sont produits directement par l'usager. Pour la m | me raison (necessite d'un tableau synoptique offrant un certain nombre de details) un niveau eleve de resolution est souhaitable dans la visualisation des diagrammes. Les outils de soutien des unites d'entree du PR peuvent | tre utiles; ils peuvent presenter rapidement a l'usager les mots cles PR attendus. Ils peuvent proceder immediatement au <> du PR selon les mots-cles recus, inserer automatiquement des separateurs, et presenter a l'usager des cles de fonctions orientees vers le PR, etc. La mise en oeuvre de ces outils peut | tre basee sur des edi- teurs de texte deja existants qui peuvent | tre ensuite etendus de facon a inclure les elements mentionnes ci-dessus. D.11.4 Verification des documents Une fois que les documents sont enregistres en memoire, l'etape suivante consiste a les verifier. Ils doivent tout d'abord | tre verifies un a un, puis avec les diagrammes correspondants jusqu'a ce que le systeme total soit verifie. Si l'entree a ete faite au moyen d'un outil concu pour le LDS, il se pourrait qu'une bonne partie de la verification pour chaque document ait deja ete effectuee. Les erreurs dues a des operations <> (a savoir les entrees ou les mises en reserve precedees d'un quelconque element, a l'exception d'un etat) devront toutes | tre detectees et corrigees au cours de la phase d'entree. La detection de cer- taines erreurs n'est toutefois possible qu'a la fin de la phase d'entree, aussi bien sur un document unique que dans le cas d'incoherences pouvant exister entre des documents. Plusieurs regles LDS peuvent | tre automatiquement verifiees. Par exemple, la necessite pour toutes les sorties d'avoir une entree correspondante. Dans le cas d'une representation a plusieurs niveaux, la conformite entre les niveaux peut | tre verifiee, dans une cer- taine mesure. Le modele formel LDS peut | tre utilise comme base pour ela- borer une collection de procedures de verification. D.11.5 Reproduction des documents Les documents LDS mis en memoire doivent pouvoir | tre retrouves, visualises et reproduits. Il est necessaire de disposer d'outils pour toutes ces activites. Il peut s'averer utile de pouvoir trouver seulement une partie, ou un sous-ensemble, du docu- ment. La recherche peut | tre orientee vers LDS, par exemple: <> d'un signal donne, ou <> est executee une action donnee, etc. Les outils de visualisation des informations sont particulierement importants lorsque l'information doit | tre visualisee au moyen de la syntaxe graphique. Les m | mes observations que celles faites pour l'entree des documents dans les syntaxes GR/PE s'appliquent. La reproduction des documents depend du type de document a reproduire, de la facon dont ces docu- ments sont mis en memoire et des caracteristiques du peripherique de sortie. Elle peut egalement dependre de la facon dont ces docu- ments ont ete introduits. Les usagers peuvent desirer une sortie imprimee dans une syntaxe differente de celle utilisee au moment de l'introduction du document. La reproduction des documents est perturbee par les con- traintes pesant sur les peripheriques de sortie. Par exemple, un diagramme peut | tre trop large pour pouvoir | tre place sur un espace donne de papier, et de ce fait, il doit | tre decoupe en plusieurs parties. Il faut alors ajouter des connecteurs et des references. Il est quelquefois souhaitable de faire la distinction entre une <> faite par l'outil et les caracteristiques initiales d'entree. D'autres contraintes physiques peuvent emp | cher la sortie de toutes les informations disponibles, par exemple, une taille particuliere de symbole peut s'averer trop petite pour renfermer la totalite du texte correspondant. Plusieurs methodes peuvent | tre choisies, eventuellement sur decision de l'usager. On peut notamment allonger le symbole, decouper le texte, le decouper mais en ajoutant le texte complet en bas de page, placer le texte a c | te du symbole . | | On peut egalement souhaiter disposer d'outils permettant un plus grand choix de formats de sorties: ces elements comprennent notamment differentes tailles de symboles, differents formats de sortie, une presentation verticale ou horizontale, etc. Un document devrait toujours pouvoir | tre reproduit exacte- ment de la m | me facon qu'il a ete introduit. D.11.6 Production de documents Sur la base des documents LDS introduits par les usagers et enregistres en memoire, plusieurs autres documents peuvent | tre produits automatiquement notamment: - les listes de signaux, regroupes par processus, par bloc ou par systeme; - les diagrammes synoptiques d'etat representant les graphes de processus comme un ensemble d'etats relies par des arcs representant les transitions; - les tables de references croisees, fournies par processus, par bloc ou par systeme; - le diagramme d'arbre de blocs, montrant la struc- ture des blocs et les niveaux; - le fonctionnement du systeme, comme reponse aux sequences des actions de l'environnement; - des index: ces documents, une fois produits, dev- ront | tre reproduits et les m | mes considerations susmentionnees seront egalement valabes. Les docments LDS introduits sous une forme GR peuvent automa- tiquement | tre traduits dans la forme PR equivalente et vice versa. Les considerations suivantes s'appliquent: - la forme GR contient des informations visuelles qui ne peuvent | tre traduites dans la forme PR (ce genre d'information n'existe pas en PR). Par exemple, les coordonnees de symboles sont sans signification dans la forme PR; - les connecteurs reliant des lignes de liaison sur differentes pages peuvent | tre elimines. La traduction inverse, de PR vers GR, est toutefois plus com- plexe et il est probable qu'elle ne sera pas tout a fait satis- faisante pour tous les lecteurs eventuels. En raison de la representation sur deux dimensions de la forme GR, certaines etiquettes qui ont ete inserees afin de repondre a la structure sequentielle du PR, peuvent | tre supprimees, etant donne qu'une ligne de connexion est suffisante. Habituellement, la traduction produit un modele de diagramme GR. Ce modele comprend tous les renseignements necessaires pour pouvoir proceder au formatage et reproduire le diagramme sur une imprimante graphique. Il convient de noter que deux outils differents traduisant des PR en GR peuvent obtenir deux representations GR ayant des presentations differentes. Les representations GR ainsi obtenues sont toutes les deux correctes a condition qu'elles gardent la semantique exprimee dans la representation d'origine. D.11.7 Modelisation et analyse du systeme Les documents LDS, independamment de leurs fonctions de specification ou de description d'un systeme sont fondamentalement un modele de ce systeme. Ce modele, qui est tout d'abord destine au transfert de l'information d'une personne a une autre, peut egalement | tre interprete par des outils; ces derniers servent a verifier si le modele est conforme, complet (cet aspect peut eventuellement | tre laisse en suspens dans le cas des specifications destinees a ne specifier que certaines parties d'un systeme), s'il est correct et s'il repond aux regles du LDS (telles que decrites dans le paragraphe relatif a la verification des documents). En outre, les outils peuvent | tre concus de facon a utiliser le modele pour simuler le comportement fonctionnel des systemes. Le simulateur peut entrer en interaction avec l'environnement et on peut alors tirer les conclusions quant a l'adequation du modele par rapport aux besoins des usagers. Si l'on ajoute des renseignements supplementaires pour indi- quer le temps passe a executer chaque action, et pour evaluer les ressources disponibles, (files d'attente, instances, etc.), la simulation peut egalement etudier la capacite du systeme. Les outils doivent | tre elabores de facon a creer un modele de l'environnement, en commencant par le modele du systeme, afin d'etablir des sequences significatives pour contr | ler le systeme actuel. Une analyse de chemins peut permettre de detecter les blo- cages dans le modele. Le modele de systeme peut egalement | tre utilise comme docu- mentation directe. S'il existe des liaisons appropriees entre le systeme reel et la memoire de la documentation, on peut elaborer un outil charge d'imprimer les evenements en temps reel du systeme sur le modele. Pour cela, il faudrait etablir une correlation entre les evenements physiques tels que vus par le systeme et les evenements logiques traites dans la documentation LDS. Si la documentation est regroupee en plusieurs niveaux d'abstraction, l'usager peut choisir le niveau a tracer. Cet aspect peut | tre utile dans la mesure ou il permet aux usagers ayant des niveaux de formation et d'education differentes, d'inspecter les activites du systeme. Les outils destines a interpreter le modele LDS peuvent egale- ment | tre utilises pour faire ressortir les differences de comporte- ment des differents modeles du m | me systeme. Ils peuvent egale- ment | tre utilises pour comparer les differentes descriptions du systeme (systemes produits par differentes compagnies), ou pour comparer la specification du systeme avec sa description. De cette maniere, il est possible de verifier si une description du systeme est conforme a la specification originale. D.11.8 Generation de code Gr | ce a une syntaxe formellement definie et a une definition mathematique formelle du LDS, il est possible de concevoir des outils capables de faire correspondre la semantique des representations LDS et la semantique des langages de programmation. Ces outils sont peut- | tre incapables de fournir des programmes complets d'application, mais ils peuvent s'averer tres utiles pour fournir au moins le cadre general pour un programme reel. Le S D.9.1 de ces directives a l'intention des usagers, offre un exemple de la facon dont peut | tre obtenue la mise en correspondance des constructions LDS et CHILL. D.11.9 Formation Un cours complet de formation pour le LDS a ete realise. Il comprend environ 200 pages de texte et une collection de diaposi- tives (environ 200). Le cours couvre tous les aspects du langage et fournit des exemples et quelques propositions quant a l'utilisation du LDS. Le cours LDS peut | tre obtenu aupres de l'Union interna- tionale des telecommunications. Secretariat general - Section des ventes, Place des Nations, CH-1211 Geneve 20 (Suisse). Blanc MONTAGE: PAGE 158 = BLANCHE