5i' FASCICULE X.2 Annexe D a la Recommandation Z.100 DIRECTIVES POUR LES USAGERS DU LDS Blanc MONTAGE: PAGE 2 = PAGE BLANCHE ANNEXE D ` LA RECOMMANDATION Z.100 DIRECTIVES POUR LES USAGERS DU LDS TABLE DES MATI`RES Page D.1 Preface / D.2 Introduction / D.2.1 Apercu general du LDS / D.2.1.1 Le LDS fonde sur un modele de machine a etat finis etendue / D.2.2 Forme syntaxique du LDS / D.2.3 Applicabilite du LDS / D.3 Concepts de base du LDS / D.3.1 Systeme / D.3.2 Blocs / D.3.3 Canaux / D.3.4 Signaux / D.3.5 Acheminement des signaux / D.3.6 Diagrammes de systeme et de bloc / D.3.7 Commentaires et extension de texte / D.3.7.1 Commentaires / D.3.7.2 Extension de texte / D.3.8 Processus / D.3.8.1 Creation de processus / D.3.8.2 Etats / D.3.8.3 Entrees / D.3.8.4 Mises en reserve / D.3.8.5 Condition de validation et signaux continus / D.3.8.6 Sorties / D.3.8.7 T | ches / D.3.8.8 Decisions / D.3.8.9 Branchements et connecteurs / D.3.9 Procedures / D.3.9.1 Corps de procedure / D.3.9.2 Appel de procedure / D.3.10 Traitement des donnees / D.3.10.1 Declarations variables / D.3.10.2 Variables revelees/vues / D.3.10.3 Variables exportees/importees / D.3.10.4 Expressions / D.3.11 Expression du temps en LDS / D.3.12 Utilisation de qualificatifs / D.3.13 Syntaxe de noms / D.4 Structuration et affinage des systemes en LDS / D.4.1 Considerations generales / D.4.2 Criteres de subdivision / D.4.3 Subdivision des blocs / D.4.4 Diagramme d'arbre de blocs / D.4.5 Division des canaux / D.4.6 Representation du systeme en cas de subdivi- sion / D.4.6.1 Sous-ensemble de subdivision coherent / D.4.7 Affinage / D.4.7.1 Sous-ensemble d'affinage coherent / D.4.7.2 Transformation entre signaux et sous-signaux / D.5 Concepts supplementaires / D.5.1 Macros / D.5.2 Systemes generiques / D.5.3 Services / D.5.3.1 Considerations generales / D.5.3.2 Signaux prioritaires / D.5.3.3 Transformation / D.5.4 Directives applicables a la representation en fonction des etats et aux elements graphiques / D.5.4.1 Observations d'ordre general sur la representation en fonction des etats / D.5.4.2 Illustration d'etat et elements graphiques / D.5.5 Diagrams auxiliaires / D.5.5.1 Diagramme synoptique d'etat / D.5.5.2 Matrice etat/signal / D.5.5.3 Diagramme de sequencement / D.6 Definition de donnees en LDS / D.6.1 Directives applicables aux donnees en LDS / D.6.1.1 Introduction generale / D.6.1.2 Sortes / D.6.1.3 Operateurs, litteraux et termes / D.6.1.4 Equations et axiomes / D.6.1.5 Informations complementaires concernant les equations et les axiomes / D.6.2 Generateurs et heritage / D.6.2.1 Generateurs / D.6.2.2 Heritage / D.6.3 Observations relatives aux equations / D.6.3.1 Considerations generales / D.6.3.2 Application de fonctions aux constructeurs / D.6.3.3 Specification d'ensemble d'essai / D.6.4 Caracteristiques / D.6.4.1 Operateurs caches / D.6.4.2 Relation d'ordre / D.6.4.3 Sortes avec champs / D.6.4.4 Sortes indexees / D.6.4.5 Valeur par defaut de variables / D.6.4.6 Operateurs actifs / D.7 Directives supplementaires pour le dessin et l'ecriture / D.7.1 Directives pour le LDS/GR / D.7.1.1 Considerations generales / D.7.1.2 Points d'entree et de sortie / D.7.1.3 Symboles / D.7.1.4 Gabarit / D.7.2 Directives applicables au LDS/PR / D.8 Documentation / D.8.1 Introduction / D.8.2 Types de representation de systemes / D.8.3 Structure de documents / D.8.4 Mecanisme de reference / D.8.5 Classification des documents / D.8.6 Combinaison de LDS/GR et de LDS/PR / D.9 Mises en correspondance / D.9.1 Mise en correspondance du LDS et du CHILL / D.9.2 Mise en correspondance du LDS/GR et du LDS/PR / D.10 Exemples d'application / D.10.1 Introduction / D.10.2 Le concept de service / D.11 Outil pour le LDS / D.11.1 Introduction / D.11.2 Categories d'outils / D.11.3 Entree des documents / D.11.4 Verification des documents / D.11.5 Reproduction des documents / D.11.6 Production des documents / D.11.7 Modelisation et analyse du systeme / D.11.8 Generation de code / D.11.9 Formation / D.1 Preface Le langage de specification et de description du CCITT (LDS) a tout d'abord fait l'objet des Recommandations Z.101 a Z.103 (Tome VI.4 du Livre orange, 1976) puis, sous une forme developpee, des Recommandations Z.101 a Z.104 (Livre jaune, 1980) qui ont ete completees et regroupees en 1984 dans les Recommandations Z.100 a Z.104 (Livre rouge). Au cours de la periode d'etudes 1985-1988, le langage a ete encore developpe et harmonise; les Recommandations existantes ont ete fondues en une seule et une definition mathematique a ete ajoutee. Des directives sont indispensables aux utilisateurs pour faciliter l'utilisation du LDS dans ses applications a une large gamme de systemes de telecommunication. Ces directives ont pour but d'aider les utilisateurs a comprendre la Recommandation concernant le LDS et son application a differents secteurs. L'emploi du LDS est largement repandu au sein du CCITT et des organisations qui en sont membres; en outre, la gamme des applica- tions de ce langage ne cesse de se developper. Les presentes direc- tives sont etablies a l'intention de ceux qui envisagent d'utiliser ou utilisent deja le LDS; elles completent la Recommandation sur le LDS en y ajoutant des conseils judicieux et des exemples utiles. Il y aura certes quelques chevauchements entre les directives et la Recommandation; cela semble d'ailleurs souhaitable, si l'on veut que les directives soient autonomes et faciles a consulter. C'est neanmoins la Recommandation qui constitue le document de base. D.2 Introduction D.2.1 Apercu general du LDS Le LDS peut servir a specifier le fonctionnement que l'on attend d'un systeme et a decrire le fonctionnement effectif d'un systeme. Il a ete concu pour specifier et decrire le comportement des systemes de commutation qui interviennent dans les telecommunications, mais peut egalement | tre utilise dans une gamme d'applications plus large. De fait, le LDS convient particulierement bien a tous les systemes ou il est possible de representer correctement un comportement a l'aide de machines a etats finis etendues (S D.2.1.1) et ou l'on s'interesse specialement aux phenomenes d'interaction. Le LDS peut egalement servir de point de depart a des methodes de documentation permettant de representer integralement la specification ou la description d'un systeme. Dans ce contexte, la signification de la specification et de la description est liee a leur emploi dans le cycle de vie d'un systeme. Chacune decrit les proprietes fonctionnelles d'un systeme d'une facon abstraite. La description comprend generalement certains aspects lies a la con- ception (par exemple, traitement des erreurs); elle est generalement plus complete en ce qui concerne les details fonction- nels. Chacune doit concorder avec le modele concret du systeme. Elles servent donc toutes deux de specifications avant la mise en oeuvre du systeme, et de documentation (descriptions) apres cette m | me mise en oeuvre. Le LDS peut servir a representer a divers niveaux de detail les proprietes fonctionnelles d'un systeme, d'une fonction ou d'une facilite, qu'il s'agisse de leurs specifications ou de leurs descriptions. Les proprietes fonctionnelles designent certaines proprietes structurelles (diagramme d'interaction de blocs) ainsi que le comportement. Par <>, on entend la maniere dont un systeme reagit a des signaux recus (entrees), c'est-a-dire les actions qu'il execute, par exemple, envoi de signaux (sorties), formulation de questions (aux fins de decision) et execution de t | ches. Les specifications peuvent | tre tres generales quand une Administration souhaite etudier les possibilites de mise a jour d'un systeme en introduisant de nouvelles caracteristiques, de nouveaux services, de nouvelles techniques, etc., tout en laissant au fournisseur la possibilite d'offrir de tres nombreuses solutions pratiques. Des specifications de ce genre ne donneront generalement que peu de details. A l'autre extremite, il y a les specifications par lesquelles une Administration demande le remplacement ou l'extension d'un central existant. Dans ce cas, les details devront probablement | tre plus pousses, les specifications des interfaces devant | tre tres detaillees. Une specification et une description peuvent | tre iden- tiques. Il est toujours preferable de concevoir les nouvelles realisations a partir de la specification, afin d'en garantir le respect. D'une maniere generale, ce sont les fournisseurs qui redigent les descriptions pour donner suite a une specification (ou pour decrire des systemes que le fournisseur veut mettre sur le marche). Une description sera generalement plus detaillee que la specification puisqu'il s'agit de rendre compte du comportement detaille du systeme. Il est a noter egalement que le LDS permet de decrire un systeme de maniere plus ou moins formelle. Premierement, il est possible de decrire un systeme au moyen de constructions LDS associees au langage naturel. La description ainsi obtenue permet le transfert de l'information a un lecteur qui conna | t le contexte, mais pas a une machine. Les contr | les pouvant | tre effectues automatiquement sont tres limites. Deuxiemement, il est possible d'associer aux constructions LDS des enonces formels constitues d'elements de types definis et d'operateurs sur ces elements. Les proprietes de ces elements ne sont pas specifiees; exemple: <>, ou A et B sont du type abonne et <> est une operation autorisee pour ce type. La specification ainsi obtenue permet le transfert de l'information aux lecteurs qui connaissent la signification des operateurs utilises. Une machine peut comprendre la description jusqu'a un certain niveau et peut proceder a certains contr | les; elle ne peut pas effectuer des contr | les complets ni <> le systeme car les proprietes des operateurs sont incon- nues. Troisiemement, il est possible egalement d'indiquer toutes les proprietes de tous les operateurs. Dans ce cas, la description est entierement formelle; une machine peut effectuer tous les contr | les et, en principe, mettre en oeuvre les systemes decrits. Selon l'objectif vise, les descriptions peuvent | tre adaptees aux besoins des usagers au moyen de differents niveaux de formalisme. Naturellement, plus la description est formelle, plus un | tre humain aura de la difficulte a la lire. Dans le texte qui suit, le terme specification sera utilise a la fois pour la representation necessaire et pour celle des com- portements reels. D.2.2.1 Le LDS fonde sur un modele de machine a etats finis etendue En cas d'emploi du LDS, le systeme a specifier est represente par un certain nombre de machines abstraites interconnectees. Une specification complete comporte obligatoirement: 1) la definition de la structure du systeme en ce qui concerne les machines et leurs interconnexions, 2) le comportement dynamique de chaque machine, ses interactions avec les autres machines et avec l'environnement, et 3) les operations sur les donnees associees aux interactions. On decrit le comportement dynamique au moyen de modeles qui definissent les mecanismes de fonctionnement des machines abstraites ainsi que la communication entre les machines. La machine abstraite qu'emploie le LDS est une extension de la machine deterministe a etats finis (FSM). La FSM est dotee d'une memoire d'etats finis internes et fonctionne avec un ensemble discret et fini d'entrees et de sorties. Pour chaque combinaison d'une entree et d'un etat, la memoire definit une sortie ainsi que l'etat suivant. On considere habituellement que la duree de transition entre deux etats est nulle. L'une des limites de la FSM est la suivante: toutes les donnees a memoriser doivent | tre representees sous la forme d'etats explicites. Il est possible de representer la plupart des systemes de cette facon, mais ce n'est pas toujours pratique. On peut | tre appele a memoriser un grand nombre de valeurs impor- tantes pour le comportement futur mais qui ne contribuent pas beau- coup a la comprehension globale du systeme. Cette information ne doit pas faire partie de l'espace des etats explicites; en effet, ceci compliquerait la presentation. Il est possible pour ce genre d'applications d'etendre la FSM en la dotant d'une memoire auxi- liaire et d'une capacite de fonctionnement auxiliaire sur cette memoire. Cette memoire auxiliaire peut emmagasiner, par exemple, des informations concernant des adresses et des numeros d'ordre. Les Recommandations relatives au LDS definissent deux operations auxiliaires qu'il est possible d'inclure dans les tran- sitions de la machine a etats finis etendue (EFSM), a savoir les decisions et les t | ches. Les <> verifient des parametres associes aux entrees et aux donnees contenues dans la memoire auxiliaire lorsque ces donnees sont importantes pour le sequencement de la machine principale. Les <> executent des fonctions telles que le comptage, des operations sur la memoire auxiliaire et la manipulation de parametres d'entree et de sortie. En LDS, des signaux representent les interactions entre machines, c'est-a-dire que les EFSM recoivent des signaux comme entrees et produisent des signaux comme sorties. Les signaux se composent d'un seul identificateur de signal et facultativement d'un ensemble de parametres. Le LDS prevoit la possibilite d'un temps de transition different de zero, et definit un mecanisme theorique de mise en file d'attente <> pour les signaux qui parviennent a une machine en train d'executer une transition. Les signaux sont traites a tour de r | le, dans leur ordre d'arrivee. D.2.2 Formes syntaxiques du LDS Le LDS est un langage qui se presente sous deux formes differentes, fondees toutes deux sur le m | me modele semantique. L'une est appelee LDS/GR (LDS graphical representation) et repose sur un ensemble de symboles graphiques normalises. L'autre s'appelle LDS/PR (LDS textual phrase representation) et repose sur des instructions analogues a un langage de programmation. L'une et l'autre representent les m | mes concepts du LDS. Un langage graphique presente l'avantage de montrer clairement la structure d'un systeme et de permettre a des | tres humains de visualiser facilement le flux de contr | le. La representation tex- tuelle de phrases convient mieux a l'utilisation par des machines. En tant qu'outil de conception, le LDS devrait | tre presente sous une forme permettant a l'utilisateur d'exprimer ses idees clairement et avec concision. Le LDS/GR, qui permet de le faire, correspond davantage a la representation traditionnelle des machines a etats finis etendues. Le LDS/GR est la forme originale du LDS. Il a ete concu entre 1973 et 1976 a ete publie pour la premiere fois dans la version de 1976 des Recommandations de la serie Z.100. Le LDS/GR a ete etabli sur la base de langages graphiques elabores par differentes organisations pour leurs propres utilisa- tions. La representation textuelle de phrases du LDS, c'est-a-dire le LDS/PR, a ete concu pendant la periode d'etudes 1977-1980 mais il a fallu y apporter certaines ameliorations avant qu'elle puisse faire l'objet d'une Recommandation. Ces ameliorations ont ete faites au cours de la periode d'etudes suivante et, des 1984, le LDS/PR est devenu l'une des syntaxes concretes recommandees du LDS. Dans un premier temps, le LDS/PR devait | tre utilise comme un moyen aise d'introduire des documents en LDS dans une machine, ce qui etait trop difficile avec le GR (en effet, cela necessitait l'intervention d'equipements peripheriques graphiques). C'est pour cette raison que l'on a insiste sur une mise en matiere de ter- minaux graphiques (capacites accrues et reduction des co | ts) ont fait que le GR est desormais susceptible d' | tre introduit en machine. Cela ne diminue en rien l'importance et l'utilisation du PR car certains utilisateurs le trouvent plus a leur convenance, particulierement ceux qui travaillent avec des langages de program- mation. Du fait de cette evolution, la correlation entre le GR et le PR est moins etroite; cependant, il est encore possible de mettre en correspondance sans difficulte l'une de ces representations avec l'autre, bien que chacune d'elles ait ses propres particularites. A premiere vue, le PR ressemble fortement a un langage de programma- tion (voir la figure D-2.2.1). Figure D-2.2.1 [T1.100] (a traiter comme tableau MEP, p. En fait, tout depend de ce qui caracterise un texte du point de vue du langage de programmation. Si nous admettons qu'un programme est defini comme une <>, non seulement les PR mais aussi les GR sont des <>. Il existe cependant certaines differences entre une specification en LDS et un programme reel. Tout d'abord, il n'est pas indispensable qu'une specification en LDS puisse | tre executee par une machine (bien que cela ne soit pas interdit); ce qui est essentiel, c'est sa capacite d'acheminer des renseignements precis d'un | tre humain a un autre | tre humain. Si nous considerons une specification en LDS comme un pro- gramme, ce qui peut | tre tenu pour une <> (en raison d'un texte informel incomplet) pourrait | tre parfaitement valable si elle etait consideree comme une representation des caracteristiques fonctionnelles d'un systeme. Une autre difference reside dans le <