InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 10_2_04.txt < prev next >

Wrap

Text File | 1991-12-22 | 79.4 KB | 2,311 lines

5i' D.5.4 Directives applicables a la representation en fonc- tion des etats et aux elements graphiques Le present paragraphe decrit la representation en fonction des etats du LDS/GR et des elements graphiques utilises. Le S D.5.4.1 contient des observations d'ordre general sur la representation en fonction des etats: caracteristiques, applica- tions pertinentes et variantes. Le S D.5.4.2 explique la description d'etats au moyen d'elements graphiques. D.5.4.1 Observations d'ordre general sur la representation en fonction des etats Le LDS/GR offre trois versions differentes pour decrire un diagramme de processus. La premiere est appelee version du LDS/GR en fonction des transitions, dans laquelle les transitions sont decrites exclusive- ment par des symboles d'action explicites. La seconde est appelee version du LDS/GR orientee vers les etats ou extension graphique du LDS orientee vers les etats; les etats d'un processus y sont decrits a l'aide d'illustrations d'etats et les transitions ne sont donnees qu'implicitement, par les differences entre les etats de depart et d'arrivee. La derniere est appelee version mixte; il s'agit d'une com- binaison des deux versions precedentes. On trouvera des exemples de ces trois versions dans l'annexe E du present fascicule. La version orientee vers les transitions convient lorsque la sequence des actions presente plus d'importance que la description detaillee des etats. La version orientee vers les etats decrit en detail les etats par des enonces; elle convient donc au cas ou un etat de processus presente plus d'importance que la sequence des actions a l'interieur de chaque transition, alors que l'explication graphique intuitive est souhaitable et qu'il est interessant de conna | tre les ressources ainsi que leurs relations avec les etats. Les illustrations d'etat sont generalement exprimees par des elements graphiques indiquant les ressources pertinentes de l'etat en cours du processus. Cette version convient a des applications dans lesquelles sont definis des elements graphiques appropries; l'utilisateur peut donc employer cette representation pour n'importe quelle application en definissant des elements graphiques appropries selon les besoins. La version mixte convient lorsqu'il faut conna | tre a la fois la sequence des actions interieures a chaque transition et les descriptions detaillees des etats. D.5.4.2 Illustration d'etat et element graphique D.5.4.2.1 Element graphique et texte qualificatif Si l'on a choisi l'option illustration d'etat, celle-ci se compose d'elements graphiques et d'un texte qualificatif, comme indique dans la figure D-5.4.1 a) a D-5.4.1 d). Cette combinaison rend comprehensibles les illustrations d'etat. A titre d'exemple, la figure D-5.4.1 a) donne la significa- tion d'un recepteur a cadran manipule par le processus, l'exemple b) celle d'un emetteur de tonalite de numerotation emet- tant un signal permanent vers l'environnement. A noter que les signaux de sortie (signaux non permanents) et les ressources pertinentes ne sont pas decrits dans les illustra- tions d'etat; les signaux de sortie peuvent | tre decrits dans un diagramme de transition. L'exemple c) montre un temporisateur dont l'expiration est toujours representee par une entree. A noter que l'illustration graphique recommandee pour le temporisateur comporte le signal d'entree pertinent t1. Le dernier exemple, d), signifie qu'un enregistreur de mes- sages vocaux est en cours de fonctionnement. L'identite de la ressource peut | tre considerablement abregee et devrait, si possible, | tre placee a l'interieur de l'illustration graphique appropriee. Ainsi, les elements graphiques qui sont qualifies sont tout a fait evidents. D.5.4.2.2 Illustrations d'etat completes Chaque illustration d'etat doit comporter un nombre suffisant d'elements graphiques afin de montrer: a) quelles ressources le processus met en oeuvre au cours de l'etat represente. Exemples: trajets de commutation, recepteurs de signalisation, emetteurs de signaux permanents et modules de commutation; b) s'il y a en ce moment un ou plusieurs temporisa- teurs qui contr | lent le processus; c) dans le cas ou le processus concerne le traite- ment des appels, si la taxation est ou non actuellement en cours et quels abonnes sont taxes au cours de cette phase de l'appel; d) quels objets appartenant effectivement a un autre processus (environnement) sont consideres comme en relation avec des ressources du processus pendant l'etat en cours; e) les signaux permanents de sortie qui sont emis dans cet etat; f ) la relation entre les signaux et ressources existants dans l'etat; g) l'inventaire des ressources concernant l'etat en cours du processus. Figura D-5.4.1, (N), p. 1 D.5.4.2.3 Exemple A titre d'exemple d'application des principes exposes ci-dessus, considerons l'etat de la figure D-5.4.2. On peut voir que, dans cet etat: a) les ressources affectees aux processus sont: un recepteur de chiffres a cadran, un emetteur de tonalites de numerotation, un poste d'abonne appartenant a l'environnement et des trajets de communication reliant ces organes; b) un temporisateur t0 surveille le processus; c) aucune taxation n'est en cours; d) l'abonne est identifie comme l'abonne A mais aucune autre information de categorie n'est prise en consideration; e) les signaux d'entree suivants sont attendus: A _on _hook (A raccroche), digit (chiffre) (chiffre numerote) et t0 (le temporisateur de supervision t0 fonctionne); f ) le signal permanent de sortie DT (tonalite de numerotation) a ete mis avant cet etat et pendant celui-ci. Figure D-5.4.2, (N), p. 2 D.5.4.2.4 Verification de la coherence de diagrammes LDS avec elements graphiques On constate que l'illustration d'etat est plus compacte et que, d'une certaine maniere, elle offre au lecteur plus d'informations; cependant, l'identification de la serie exacte d'operations accomplies au cours de la transition exige un examen tres attentif des ressources. En outre, une simple observation de l'illustration d'etat ne permet pas de determiner l'ordre des actions dans la transition. Les elements graphiques representes a l'exterieur du bloc sont des elements qui ne sont pas directement commandes par le processus donne: ceux qui sont representes a l'interieur du symbole <<limites du bloc>> sont directement commandes par ce processus. Par exemple, le processus d'appel partiellement specifie dans la figure D-5.4.3 peut allouer ou liberer l'emetteur de tonalite d'appel, l'emetteur de sonnerie et les trajets de conversation; il peut egalement declencher ou arr | ter le temporisateur T4, mais il ne peut com- mander directement la condition du combine de l'abonne. En concevant la logique a partir d'une specification LDS avec elements graphiques, seuls les elements graphiques representes a l'interieur des limites du bloc ont une influence sur les actions executees pendant les sequences de la transition. Les elements gra- phiques complexes representes a l'interieur des limites de ce bloc sont normalement inlus dans une illustration d'etat: a) soit parce qu'ils indiquent les ressources et l'etat de l'environnement concernes par le signal d'entree du pro- cessus pendant l'etat donne; b) soit pour ameliorer l'intelligibilite du diagramme. D.5.4.2.5 Utilisation du symbole <<temporisateur>> Que l'on emploie ou non des elements graphiques, l'expiration d'un delai de temporisation est toujours representee par une entree. La presence d'un symbole de temporisateur dans une illustra- tion d'etat implique qu'un temporisateur fonctionne pendant cet etat. Figure D-5.4.3, (N), p. 3 Conformement au principe general expose dans les Recommanda- tions, le demarrage, l'arr | t, le redemarrage et l'expiration du temporisateur sont representes a l'aide d'elements graphiques de la maniere suivante: a) pour montrer qu'une temporisation commence au cours d'une transition donnee, le symbole temporisateur doit appara | tre sur l'illustration d'etat qui correspond a la fin de cette transition et non sur celle qui correspond a son debut; b) inversement, pour montrer qu'une temporisation s'arr | te au cours d'une transition, le symbole temporisateur doit appara | tre sur l'illustration d'etat qui correspond au debut de cette transition et non sur celle qui correspond a sa fin; c) pour montrer qu'une temporisation est relancee au cours d'une transition un symbole explicite de t | che doit | tre represente dans cette transition (on en voit deux exemples sur la figure D-5.4.4); d) l'expiration du delai d'une temporisation donnee est representee par un symbole d'entree associe a un etat dont l'illustration porte le symbole <<temporisateur>> correspondant. Il peut naturellement arriver que plusieurs temporisateurs surveillent a la fois le m | me processus (voir la figure D-5.4.5). Figure D-5.4.4, (N), p. 4 Figure D-5.4.5, (N), p. 5 D.5.5 Diagrammes auxiliaires Pour faciliter la lecture et la comprehension de diagrammes de processus de grande taille et/ou complexes, l'auteur peut y ajouter des diagrammes auxiliaires informels. De tels documents ont pour but de donner une description synoptique ou simplifiee du comporte- ment du processus (ou d'une partie de celui-ci). Les documents aux- iliaires ne remplacent pas les documents en LDS mais constituent une introduction a ceux-ci. On trouvera dans la presente section des exemples de certains diagrammes auxiliaires couramment utilises, notamment des diagrammes synoptiques d'etat, des matrices etat/signal, et des diagrammes de sequencement. (Le diagramme en arbre de bloc decrit au S D.4.4 est egalement un diagramme auxiliaire.) D.5.5.1 Diagramme synoptique d'etat Son objectif est de donner une vue d'ensemble des etats d'un processus, et d'indiquer quelles transitions sont possibles entre eux. Etant donne qu'il s'agit de donner un apercu, l'on peut negliger les etats ou les transitions de peu d'importance. Les diagrammes se composent de symboles d'etat, de fleches representant des transitions et, eventuellement, de symboles de debut et d'arr | t. Le symbole d'etat doit indiquer le nom de l'etat reference. Plusieurs noms d'etat peuvent | tre inscrits dans le symbole, et il est possible d'employer un asterisque (*) pour designer tous les etats. Chacune des fleches peut, de m | me que chacune des sorties possibles pendant la transition, | tre associee au nom du signal ou de l'ensemble de signaux qui declenchent la transition. On trouvera dans la figure D-5.5.1 un exemple de diagramme synoptique d'etat. Figure D-5.5.1, (MC), p. 6 Il est possible de repartir sur plusieurs diagrammes le diagramme synoptique d'etat d'un processus; chacun des diagrammes obtenus porte alors sur un aspect particulier, comme <<cas nor- mal>>, traitement en cas de defaillance, etc. Figure D-5.5.2, (N), p. 7 D.5.5.2 Matrice etat/signal La matrice etat/signal doit servir de document <<preliminaire>> a un diagramme de processus important. Elle indique les endroits ou existent des combinaisons entre un etat et un signal dans le diagramme. Le diagramme se compose d'une matrice bidimensionnelle; celle-ci presente sur un axe tous les etats d'un processus, et sur l'autre tous les signaux d'entree valides d'un processus. L'etat suivant est donne pour chaque element de matrice, de m | me que les sorties possibles au cours de la transition. Une reference peut | tre indiquee pour permettre de trouver la combinaison donnee par les indices, si elle existe. L'element correspondant a l'etat fictif ou <<START>> et au signal fictif <<CREATE>> sert a indiquer l'etat initial du pro- cessus. Figure D-5.5.3, (MC), p. 8 Il est possible de fractionner la matrice en sous-parties reparties sur plusieurs pages. Les references sont celles qu'emploie normalement l'usager dans la documentation. Les signaux et les etats doivent | tre de preference regroupes de facon que chaque partie de la matrice porte sur un aspect particulier du comportement du processus. D.5.5.3 Diagramme de sequencement Le diagramme de sequencement peut servir a montrer l'echange des sequences de signaux autorisees entre un ou plusieurs processus et leur environnement. Ce diagramme doit donner une vue d'ensemble de l'echange de signaux entre les parties du systeme. Ce diagramme peut representer l'ensemble ou une partie de l'echange de signaux, en fonction des aspects a mettre en evidence. Les colonnes du diagramme indiquent les entites en communica- tion (services, processus, blocs ou l'environnement). Leurs interactions sont illustrees par un ensemble de lignes flechees, dont chacune represente un signal ou un ensemble de sig- naux. Figure D-5.5.4, (N), p. 9 On peut annoter chaque sequence afin de faire appara | tre clairement l'ensemble d'informations echangees. Chaque ligne est accompagnee d'une annotation qui donne les renseignements requis (noms des signaux ou de procedures). On peut placer un symbole de decision dans les colonnes pour indiquer que la sequence suivante est valide si la condition indiquee est vraie. Dans ce cas, le symbole de decision appara | t generalement plusieurs fois; il indique les differentes sequences produites par chacune des valeurs de la condition. Ce diagramme peut representer la totalite ou seulement un sous-ensemble significatif des sequences de signaux echanges. La representation de l'interaction reciproque des services resultant de la subdivision d'un processus represente une applica- tion utile de ce type de diagramme. Les diagrammes de sequencement ne comprennent generalement pas toutes les sequences possibles; ils constituent souvent un prealable a la definition complete. D.6 Definition des donnees en LDS D.6.1 Directives applicables aux donnees en LDS On trouvera dans la presente section des renseignements complementaires sur les concepts definis au S 5 de la Recommanda- tion concernant le LDS. La principale difference entre la presente section et l'ancienne Recommandation Z.104 est que cette derniere a fait l'objet d'une revision a des fins de clarification et d'harmonisation avec l'ISO. Certains des mots cles ont ete modifies et des adjonctions ont ete faites mais la coherence de la semantique a ete assuree avec le Livre rouge. L'emploi des donnees decrites aux S 2, 3 et 4 de la nouvelle Recommandation (auparavant Z.101-Z.103) est reste tel quel. D.6.1.1 Introduction generale Les types de donnees du LDS sont fondes sur l'approche de <<types de donnees abstraits>>: on ne decrit pas la maniere dont un type doit | tre mis en oeuvre, mais on se borne a dire quel sera le resultat des operateurs applique aux valeurs. Lorsque l'on definit des donnees abstraites, chaque segment de la definition, appelee <<definition de type partielle>> est intro- duit par le mot-cle NEWTYPE. Chaque definition de type partielle a une incidence sur les autres, de sorte que toutes les definitions de type partielles au niveau du systeme constituent une definition de type de donnees unique. Si plusieurs definitions de type par- tielles sont introduites a un niveau inferieur (niveau de bloc, par exemple), leur ensemble constitue, avec les definitions de niveau superieur, une definition de type de donnees. Cela signifie qu'en un point quelconque de la specification, il n'existe qu'une seule definition de type de donnees. En substance, la definition de type de donnees comprend trois parties: a) definitions de sortes; b) definitions d'operateurs; c) equations. Chacune de ces parties fait l'objet d'explications dans les paragraphes qui suivent. La definition de type de donnees est structuree en definitions de type de donnees partielles, chacune introduisant une sorte. Les definitions d'operateurs et les equa- tions recouvrent les definitions de type de donnees partielles. D.6.1.2 Sortes Une sorte est un ensemble de valeurs qui peut avoir un nombre fini ou infini d'elements mais ne peut | tre vide. Exemples: a) l'ensemble de valeurs de la sorte booleenne est { rue (vrai), False (faux } b) l'ensemble de valeurs de la sorte Natural (naturel) est l'ensemble infini des nombres naturesls { , 1, 2, . | } c) l'ensemble de valeurs de la sorte Couleur _pri- maire est { ert, Rouge, Ble } Tous les elements d'une sorte ne doivent pas | tre directe- ment fournis par l'utilisateur (cela exigerait un temps infini dans le cas des nombres naturels), mais le nom de la sorte doit | tre indique. Dans la syntaxe concrete, le mot-cle NEWTYPE est directe- ment suivi par le nom de la sorte (certaines autres possibilites seront indiquees plus loin). Ce nom est surtout utilise dans les definitions d'operateurs, comme explique au S D.6.1.3, et dans les declarations de variables. D.6.1.3 Operateurs, litteraux et termes Les valeurs d'une sorte peuvent | tre definies de trois manieres: a) par une enumeration: les valeurs sont definies dans la section des litteraux; b) par des operateurs: les valeurs sont donnees comme les resultats d'<<applications>> d'operateurs; c) par une combinaison d'enumerations et d'operateurs. La combinaison de litteraux et d'operateurs donne des termes. Les relations entre les termes sont exprimees a l'aide d'equations. Les paragraphes qui suivent traitent des litteraux, des operateurs et des termes; le S D.6.1.4 traite des equations. D.6.1.3.1 Litteraux Les litteraux sont des valeurs enumerees d'une sorte. Une definition de type partiel ne doit pas necessairement comporter de litteraux: tous les elements de la sorte peuvent | tre definis au moyen d'operateurs. Les litteraux peuvent | tre consideres comme des operateurs depourvus d'arguments. Une relation entre les litteraux peut | tre exprimee dans des equations. Dans la syntaxe concrete, les litteraux sont introduits apres le mot-cle LITERALS. Exemples: a) La definition de la sorte booleenne contient deux litteraux, a savoir True (vrai) et False (faux). Ainsi, la definition du type booleen se presente comme suit: NEWTYPE Boolean LITERALS True, False . | | ENDNEWTYPE Boolean; b) la sorte naturelle peut | tre definie a l'aide d'un litteral, le zero. Les autres valeurs peuvent | tre generees au moyen de ce litteral et d'operateurs; c) les valeurs de la sorte couleur _primaire peu- vent | tre definies de la m | me maniere que les litteraux booleens; NEWTYPE Primary _colour LITERALS Red, Green, Blue . | | ENDNEWTYPE Primary _colour; d) au S D.6.1.3.2, le troisieme exemple c) presente une definition de type partielle sans litteraux. D.6.1.3.2 Operateurs Un operateur est une fonction mathematique qui met en concor- dance une ou plusieurs valeurs (eventuellement de sortes differentes) avec une valeur resultante. Les operateurs sont intro- duits apres le mot-cle OPERATORS, la ou les sortes de leur ou leurs arguments et la sorte de resultat sont egalement indiquees (on parle de signature des operateurs). Exemples: a) dans le type booleen, un operateur appele <<not>> peut | tre defini; il aura un argument de sorte booleen et egalement un resultat de sorte booleen. Dans la definition du type booleen, il se presente comme suit: NEWTYPE Boolean LITERALS True, False OPERATORS <<Not>>: Boolean->Boolean; . | | ENDNEWTYPE Boolean; b) l'operateur susmentionnne necessaire pour con- struire tous les nombres naturels est Next. Cet operateur prend un argument de sorte naturelle et donne une valeur naturelle (la valeur superieure suivante) en tant que resultat; c) il est possible de definir pour des couleurs un nouveau type qui n'a pas de litteraux mais utilise des litteraux de la sorte couleur primaire et certains operateurs: NEWTYPE Color OPERATORS Take: Primary _colour->Colour; Mix: Primary _colour, Colour->Colour; . | | ENDNEWTYPE Colour; Il s'agissait de prendre une couleur primaire et de la considerer comme une couleur puis de commencer a melanger plusieurs couleurs primaires afin d'obtenir d'autres couleurs. D.6.1.3.3 Termes A l'aide de litteraux et d'operateurs, il est possible de con- struire comme suit l'ensemble des termes: 1) Rassembler tous les litteraux dans un ensemble de la sorte dans laquelle ils sont definis - chaque litteral est un terme. 2) Un nouvel ensemble de termes est cree pour chaque operateur lorsque l'operateur est applique a toutes les com- binaisons possibles de termes de la sorte correcte crees precedemment: a) pour la sorte <<Boolean>>, l'ensemble de litteraux est { rue (vrai), False (faux } Le resultat de cette etape est { ot (True), Not (False } parce que nous avons seulement l'operateur Not (non); b) pour la sorte <<Natural>>, le resultat de cette etape est { ext(0 } c) pour la sorte <<Colour>> l'ensemble de litteraux est vide mais le resultat de cette etape est { ake(Red), Take(green), Take(Blue } 3) Les termes des ensembles crees au cours de l'etape precedente sont tous la sorte du resultat de l'operateur applique; par exemple, tous les resultats de l'operateur Not sont de la sorte booleenne. Alors, on reunit tous les ensembles de la m | me sorte, aussi bien des ensemble initiaux que les ensembles nouvellement crees: a) pour la sorte booleenne, on obtient l'ensemble { rue, False, Not(True), Not(False } b) pour les nombres naturels cette etape donne l'ensemble { , Next(0 } 4) Les deux dernieres etapes sont repetees a maintes reprises, et definissent en general un ensemble infini de termes: a) l'ensemble de termes booleens generes par les litteraux True et False et l'operateur Not est { rue, False, Not(True), Not(False), Not(Not(True)), Not(Not(False)), Not(Not(Not(True))), . | | } b) l'ensemble des termes naturels generes par le litteral 0 et l'operateur Next est { , Next(0), Next(Next(0)), Next(Next(Next(0))), . | | } c) l'ensemble des termes de couleur generes par les litteraux Red, Green et Blue de la sorte Primary _colour et les operateurs Take et Mix est { ake(Red), Take(Green), Take(Blue), Mix(Red, Take(Red)), Mix(Red, Take(Green)), Mix(Red, Take(Blue)), Mix(Green, Take(Red)), Mix(Green, Take(Green)), Mix(Green, Take(Blue)), Mix(Blue, Take(Red)), Mix(Blue, Take(Green)), Mix(Blue, Take(Blue)), . | | } D.6.1.4 Equations et axiomes D'une maniere generale, le nombre de termes generes au paragraphe precedent est superieur au nombre de valeurs de la sorte. A titre d'exemple, il existe deux valeurs booleennes mais l'ensemble de termes booleens a un nombre infini d'elements. Il existe cependant une possibilite d'etablir des regles specifiant quels sont les termes consideres comme designant la m | me valeur. Ces regles sont appelees equations et font l'objet du paragraphe suivant. Deux types particuliers d'equations, les axiomes et les equations conditionnelles, font l'objet des S D.6.1.4.2 et D.6.1.4.3. Les equations, les axiomes et les equations conditionnelles sont donnes, dans la syntaxe concrete apres le mot-cle AXIOMS. Ce mot-cle a ete conserve pour des raisons d'ordre historique. D.6.1.4.1 Equations Une equation indique quels sont les termes consideres comme designant la m | me valeur. Une equation relie deux termes separes par le symbole d'equivalence ==. Par exemple <<Not(True) == False>> indique que les termes Not(True) et False sont equivalents; chaque fois que l'on trouve Not(True), on peut le remplacer par False sans changement de sens et vice versa. Dans certaines equations, l'ensemble de termes est divise en sous-ensembles discontinus de termes qui designent la m | me valeur. Ces sous-ensembles sont appeles classes d'equivalence. Dans le langage courant, les classes d'equivalence sont identifiees aux valeurs. Exemples: a) L'ensemble de termes de la sorte booleenne est divise en deux classes d'equivalence de termes par les deux axiomes suivants: Not(True) == False; Not(False) == True; Les classes d'equivalence qui en resultent sont: { rue, Not(False), Not(Not(True)), Not(Not(Not(False))), Not(Not(Not(Not(True)))), Not(Not(Not(Not(Not(False))))), . | | } et { alse, Not(True), Not(Not(False)), Not(Not(Not(True))), Not(Not(Not(Not(False)))), Not(Not(Not(Not(Not(True))))) } . | | Ces deux classes d'equivalence sont identifiees aux valeurs True (Vrai) et False (Faux); b) Dans le cas de couleurs, on peut desirer specifier que le melange d'une couleur primaire avec une couleur qui contient cette couleur primaire ne fait pas de difference. De plus, l'ordre dans lequel les primaires sont melanges est sans importance. Cela peut | tre enonce dans les equations suivantes: Mix(Red, Take(Red)) == Take(Red); Mix(Red, Mix(Red, Take(Green))) == Mix(Red, Take(Green)); Mix(Red, Mix(Red, Take(Blue))) == Mix(Red Take(Blue)); Mix(Red, Mix(Green, Take(Red))) == Mix(Green, Take(Red)); Mix(Red, Mix(Blue, Take(Red))) == Mix(Blue, Take(Red)); etc. Cela demande beaucoup de travail car des equations simi- laires apparaissent pour toutes les permutations de Red, Green et Blue. C'est pourquoi le LDS comporte la construction FOR-ALL qui introduit les noms de valeur representant une classe d'equivalence arbitraire (ou la valeur associee a cette classe d'equivalence). Cela peut | tre tres utile dans la situation ci-dessus; toutes les equations susmentionnees et celles qui sont indiquees par etc. peu- vent | tre decrites en quelques lignes sous la forme suivante: FOR ALL p1, p2 IN Primary _colour /*1*/ Mix(p1, Take(p1)) == Take(p1); /*2*/ Mix(p1, Mix(p1, Take(p2))) == Mix(p1, Take(p2)); /*3*/ Mix(p1, Mix(p2, Take(p1))) == Mix(p2, Take(p1)); /*4*/ Mix(p1, Take(p2)) == Mix(p2, Take(p1)); /*4*/ FOR ALL c IN Colour /*5*/ ( Mix(p1, Mix(p2, c)) == Mix(p2, Mix(p1, c)); /*6*/ ( Mix(p1, Mix(p2, c)) == Mix(Mix(p1, Take(p2)) c)) /*4*/ ) Dans les equations ci-dessus, il y a chevauchement mais cela ne pose pas de problemes pour autant que les equations ne se contredisent pas mutuellement. Les equations susmentionnees creent 7 classes d'equivalence dans l'ensemble de termes de la sorte Colour, de sorte qu'avec ces equations, il y a sept valeurs de couleurs. Les termes suivants sont dans les classes d'equivalence differentes: Take(Red), Take(Green), Take(Blue), Take(Red, Take(Green)), Mix(Green, Take(Blue)), Mix(Blue, Take(Red)), Mix(Blue, Mix(Green, Take(Red))). Tous les autres termes de la sorte Colour sont equivalents a l'un des termes ci-dessus. Dans les exemples d'equations comportant la construction FOR-ALL, appelees equations explicitement quantifiees, l'information que p1 et p2 sont des identificateurs de valeur de sorte Primary _colour est redondante; l'argument de l'operateur Take et le premier argument de l'operateur Mix ne peuvent | tre de la sorte Primary _colour. En general, les equations explicitement quantifiees deviennent plus lisibles mais il est possible d'omettre la quantification si la sorte des identificateurs de valeur peut | tre deduite du contexte. Dans ce cas, on dit que l'equation est implicitement quantifiee. Exemple: Les equations 4 et 5 ci-dessus sont les m | mes que: Mix(p1, Take(p2)) , c)) == Mix(p2, Take(p1)); Mix(p1, Mix(p2, c)) == Mix(p2, Mix(p1, c)); D.6.1.4.2 Axiomes Les axiomes sont simplement des especes particulieres d'equation, introduites parce que dans des situations pratiques, de nombreuses equations se rapportent a des booleens. Dans ce cas, les equations tendent a prendre la forme . | | == True (vrai), c'est-a-dire qu'elles indiquent qu'un terme donne est equivalent a True. Exemple: Admettons qu'un operateur soit defini pour une couleur type: Contains: Colour, Primary _colour-> Boolean; ce qui doit donner la reponse True (vrai) si la couleur primaire est contenue dans la couleur et False (faux) dans le cas contraire. Voici un exemple des equations dont il s'agit: FOR ALL p IN Primary _colour ( Contains(Take(p), p) == True; FOR ALL c IN Colour ( Contains(Mix(p,c), p) == True) ) La partie <<== True>> de ces equations peut | tre omise et les resultats sont appeles axiomes. Des axiomes peuvent se reconna | tre a l'absence du symbole d'equivalence ==; ils designent des termes qui sont equivalents a la valeur True (vrai) de la sorte booleenne. La construction de la seconde equation peut para | tre quelque peu forcee. Une meilleure maniere d'ecrire ces equations est indiquee apres l'introduction de certaines constructions utiles. D.6.1.4.3 Equations conditionnelles Les equations conditionnelles constituent un moyen d'ecrire des equations qui ne sont valables que dans certaines conditions. Ces conditions sont designees par la m | me syntaxe que les equa- tions non conditionnelles et sont separees par un symbole ==> de l'equation qui est valable si la condition est remplie. Exemple: L'exemple type d'une equation conditionnelle est la definition de la division en type reel ou: FOR ALL x, z IN Real ( z/= 0 == True ==> (x/z) * z == x) indique que, si la condition <<z n'est pas egale a 0>> est valable, la division par z suivie de la multiplication par z donne la valeur originale. Cette equation conditionnelle n'indique rien quant a ce qui devrait arriver si une valeur de la sorte Real etait divisee par 0. Si l'on veut specifier ce qui se passe en cas de division par zero, il faudrait creer une equation conditionnelle de la forme suivante: FOR ALL x, z IN Real ( z = 0 == True ==> (x/z) * z == . | | ). En pareil cas, cependant, il est recommande de placer un <<terme conditionnel>> du c | te droit, pour faciliter la lecture. Dans le cas ci-dessus l'equation deviendrait: FOR ALL x, z IN Real ( (x/z) * z == IF z/=0 ( (x/z) * z == THEN x ( (x/z) * z == ELSE . | | ( (x/z) * z == FI ) D.6.1.5 Informations complementaires concernant les equa- tions et les axiomes Les deux sections qui suivent traitent de certaines difficultes que l'on peut rencontrer lorsque des operateurs donnent des resultats appartenant a une sorte deja definie. Le S D.6.1.5.3 explique la notion d'erreur en tant que terme d'une equation. D.6.1.5.1 Coherence de la hierarchie En un point quelconque d'une specification en LDS, il existe une seule et unique definition de type de donnees. Cette definition de type de donnees contient les sortes, operateurs et equations predefinis et l'ensemble des sortes, operateurs et equations definis par l'utilisateur dans les definitions de type partielles visibles en ce point. (C'est la raison pour laquelle un texte NEWTYPE . | | ENDNEWTYPE est appele definition de type partielle .) Il en resulte certaines consequences pour les definitions de type aux niveaux inferieurs. Cette influence sur le type pourrait | tre peu souhaitable. A titre d'exemple, on pourrait specifier de facon erronee que deux termes sont equivalents, les rendant ainsi equivalents alors qu'ils ne sont pas dans une portee englobante. Il n'est pas admis de donner des equations telles que: a) les valeurs d'une sorte qui sont differentes dans une portee a un niveau superieur soient rendues equivalentes; b) de nouvelles valeurs soient ajoutees a une sorte definie dans une portee de niveau superieur. Cela signifie par exemple que, dans un bloc au niveau du systeme, des definitions de type partielles specifiees par l'utilisateur contenant un operateur ayant un resultat predefini doivent rapporter tous les termes produits par cet operateur a des valeurs de cette sorte de resultat. Exemples: a) Si, pour une raison quelconque, on donne l'axiome: FOR ALL n, m IN Integer ( (Fact(n) = Fact(m)) => (n = m)) afin de specifier que si les resultats de l'operateur Fact sont les m | mes, les arguments sont alors les m | mes. (A noter que => est l'implication booleenne; cela a peu de relation avec le signe d'equation conditionnellle ==>). Ainsi, par accident, les valeurs sont unifiees. Des equations des exemples precedents on peut deduire que Fact(0) = Fact(1) et cette derniere equation indique que 0 et 1 sont des notations differentes de la m | me valeur. Sur la base de cette derniere equation, on peut prouver que les nombres d'elements de la sorte Integer sont reduits a un. Avec l'aide d'une equation conditionnelle, on peut indi- quer que, pourvu que n et m ne soient pas egaux a 0, le m | me resultat de l'operateur Fact sur n et m implique n = m. En Led: FOR ALL n, m IN Integer ( n/=0, m/=0 ==> (Fact(n) = Fact(m)) => (n = m)) A noter que cette derniere equation n'ajoute rien a la semantique des nombres entiers; c'est un theoreme qui peut | tre deduit des autres equations. Par ailleurs, l'adjonction d'une equa- tion prouvable ne presente pas d'inconvenient. b) Admettons que l'on decouvre la necessite d'un operateur pour les factorielles lors de la specification d'un type donne. Dans la definition de type partielle de ce type, l'operateur Fact est introduit: Fact: Integer -> Integer; et les equations suivantes sont donnees pour definir cet operateur: Fact(0) == 1; FOR ALL n IN Integer ( n > 0 ==> Fact(n) == n * Fact(n-1)) Ces equations ne definissent pas Fact(-1) et ainsi, c'est un terme de la sorte Integer qui n'a pas de relation avec d'autres termes de cette sorte. En consequence, Fact(-1) est une nouvelle valeur de la sorte entier (et il en va de m | me pour Fact(-2), Fact(-3), etc). Cela n'est pas admis. L'exemple b) du S D.6.1.5.3 donne une definition correcte de fact. D.6.1.5.2 Egalite et inegalite Dans chaque type, les operateurs d'egalite et d'inegalite sont implicites. Ainsi, si une definition de type partielle introduit une sorte S, il y a alors des definitions implicites d'operateur: "=": S, S -> Boolean; "/=": S, S -> Boolean; (Remarque - Les guillemets specifient que = et/= sont utilises comme operateurs infixes.) L'operateur d'egalite presente les proprietes previsibles: a = a, a = b => b = a, a = b AND b = c => a = c, a = b => a == b, a = b => op(a) = op(b) for all operators op. Ces proprietes ne sont pas ecrites en syntaxe LDS et ne doivent pas | tre enoncees dans des axiomes ou des equations car elles sont implicites. La valeur booleenne obtenue lorsque cet operateur est applique est True (vrai) si les termes de la partie gauche et de la partie droite sont de m | me classe d'equivalence; sinon la valeur obtenue est False (faux). S'il n'est pas explicitement specifie, que la valeur est True (vrai) ou False (faux), la specification est incomplete. Pour l'operateur d'inegalite, c'est par une equation en LDS que l'on peut le mieux expliquer la semantique: FOR ALL a, b IN S ( a/= b == Not(a = b)) Il n'y a pas de difference entre l'egalite et l'equivalence. Deux termes qui sont equivalents designent la m | me valeur et l'operateur d'egalite entre eux donne le resultat True (vrai). D.6.1.5.3 Erreur On a juge necessaire, pour les exemples qui precedent, de specifier que l'application de l'operateur a certaines valeurs est consideree comme une erreur. Le LDS a un moyen de le specifier for- mellement: l'element ERROR. L'erreur devrait servir a exprimer: <<l'application de cet operateur a cette valeur n'est pas admise et lorsqu'il se presente, le comportement futur est indefini>>. Dans la syntaxe concrete, cela est indique par le terme Error!, qui ne peut | tre utilise comme argument d'un operateur. Lorsque Error resulte de l'application d'un operateur et que cette application est un argument d'un autre operateur, l'application d'operateur exterieur porte egalement Error dans son resultat (propagation-d'erreurs). Dans un terme conditionnel, la partie THEN ou la partie ELSE est evaluee, de sorte que l'une d'elle peut | tre une erreur sans que celle-ci soit evaluee (etant donnee que l'autre partie de l'alternative est evaluee). Exemples: a) Dans l'exemple de division de valeurs de sorte Real, les poids peuvent | tre remplaces comme suit: FOR ALL x, z IN Real ( (x/z) * z == IF z/=0 ( (x/z) * z == THEN x ( (x/z) * z == ELSE Error! ( (x/z) * z == FI ) Pour plus de clarte, on pourrait ajouter: FOR ALL x IN Real ( x/0 == Error!) b) Dans l'exemple comportant l'operateur Fact, on pourrait specifier que l'application de cet operateur sur des entiers negatifs est consideree comme une erreur (Error). Cela per- met d'eviter que Fact(-1), Fact(-2), . | | ne deviennent de nouvelles valeurs de la sorte Integer (entier). Il conviendrait de definir l'operateur Fact comme suit: n < 0 ==> Fact(n) == Error!; Fact(0) == 1; n > 0 ==> Fact(n) == Fact(n-1) * n; Ces trois lignes sont beaucoup plus claires que l'equation du style programmation indiquee ci-apres. En general, le terme con- ditionnel devrait | tre utilise s'il y a deux cas complementaires; l'embo | tage de termes conditionnels rend l'equation illisible, comme on peut le voir ci-dessous: Fact(n) == IF n > 0 Fact(n) == THEN Fact(n-1) * n Fact(n) == ELSE IF n = 0 Fact(n) == ELSE THEN 1 Fact(n) == ELSE ELSE Error! Fact(n) == ELSE FI Fact(n) == FI D.6.2 Generateurs et heritage Le present paragraphe traite de deux constructions qui peuvent | tre utilisees pour specifier des types ayant des parties communes. Le generateur specifie non un type mais un schema, qui devient un type lorsque les sortes, operateurs, litteraux et con- stantes formels sont remplaces par des termes reels. L'heritage offre la possibilite de creer un nouveau type en partant d'un type deja existant. Les noms de litteraux et d'operateurs peuvent | tre renommes et il est possible de specifier des litteraux, des operateurs et des equations supplementaires. D.6.2.1 Generateurs Une definition de generateur definit un schema parametre par des noms formels de sortes, de litteraux, de constantes et d'operateurs. Les generateurs sont destines a des types qui representent des <<variations sur un theme>>, tels que des ensem- bles d'elements, des cha | nes d'elements, des fichiers d'enregistrement, des tables de consultation, des tableaux. On peut l'expliquer a l'aide d'un exemple pour lequel des variations peuvent | tre envisagees. Admettons qu'il soit necessaire qu'un type ressemble a la notion mathematique d'un ensemble d'entiers. La partie suivante du texte fait partie de la definition de type de cet ensemble d'entiers. Figure D.6.2.1 (comme tableau) [T37.100], p. 10 Toutes les equations ont une quantification implicite. La premiere equation indique que la suppression d'un element de l'ensemble vide donne l'ensemble vide pour resultat. La seconde equation indique que la suppression apres insertion du m | me element donne pour resultat l'ensemble tel qu'il etait avant l'insertion (a condition que l'ensemble ne contienne pas l'element); sinon l'ordre d'insertion et de suppression peut | tre interchangeable. La troisieme equation indique que l'element vide ne contient pas d'elements. La quatrieme equation indique qu'un element se trouve dans un ensemble s'il est le dernier element ajoute ou s'il se trouvait dans l'ensemble avant l'adjonction du dernier element. La derniere equation indique que l'ordre d'addition des elements ne fait aucune difference. Dans l'exemple de la figure D-6.2.1 Int _set (ensemble _d'entiers) n'est qu'un exemple d'un ensemble et si l'on a egale- ment besoin d'un PId _set, d'un Subscriber _set (ensemble _d'abonnes) et d'un Exchange _name _set (ensemble _de _noms _de _central) dans la specification, personne ne sera surpris qu'il contienne tous les operateurs Add (ajouter), Delete (supprimer) et Is _in (est _dans) et un litteral pour l'ensemble vide. Les equa- tions donnees pour ces operateurs facilitent la generalisation a d'autres ensembles. Tel est le cas ou la notion de generateur se revele utile; le texte commun peut | tre donne une fois et | tre utilise plusieurs fois. La figure D-6.2.2 presente le generateur. (A noter que les noms de sortes formels sont introduits par le mot cle TYPE, cela uniquement pour des raisons d'ordre historique.) Au lieu d'utiliser Integer (entier), on utilise le type formel Item et, pour pouvoir donner differents noms a l'ensemble entier vide et aux ensembles vides dans d'autres types, on fait egalement de ce litteral un parametre formel. Figure D.6.2.2 (comme tableau) [T38.100], p. 11 Avec ce generateur, le type Int _set peut | tre construit comme suit: NEWTYPE Int _set Set (Integer, empty _int _set) ENDNEWTYPE Int _set; Si l'on compare les figures D-6.2.1 et D-6.2.2, on constate que: a) GENERATOR et ENDGENERATOR sont remplaces par NEWTYPE et ENDNEWTYPE respectivement; b) les parametres formels de generateur (le texte entre parentheses apres le nom de generateur) sont supprimes; c) Set, Item et empty _set sont remplaces dans tout le generateur par Int _set, Integer et empty _int _set, respective- ment. Ainsi, il n'y a en fait aucune difference entre cet Int _set et celui de la figure D-6.2.1, mais . | | - si l'on a besoin d'un ensemble de valeurs Pid, on peut creer le type a l'aide de: NEWTYPE PId-set Set(PId, empty _pid _set) ENDNEWTYPE PId _set; - si l'on a besoin d'un ensemble d'abonnes, dans lequel les abonnes sont representes par un type introduisant la sorte Subscr, l'ensemble d'abonnes peut | tre cree a l'aide de: NEWTYPE Subscr _set Set(Subscr, empty _subscr _set) ENDNEWTYPE Subscr _set; Cela permet d'economiser du papier, de plus, le travail est facilite parce qu'il suffit de penser une fois aux ensembles et que ce travail peut | tre delegue a des specialistes qualifies sur les types de donnees abstraites. Exemple: Cet exemple montre un generateur utilisant une sorte, un operateur, un litteral et une constante formels. Il decrit une rangee d'elements ayant une longueur maximale max _length. La sorte comprend un litteral designant la rangee vide et les operateurs pour insertion et suppression d'elements dans une rangee ou de celle-ci, l'encha | nement de rangees, le choix d'une sous-rangee et la determination de la longueur d'une rangee. Ce dernier operateur est rendu formel ce qui permet de la nommer a nouveau. GENERATOR Row (TYPE Item, OPERATOR Length, LITERAL Empty, CONSTANT max _length) LITERALS Empty OPERATORS Length: Row -> Integer; Insert: Row, Item, Integer -> Row; Delete: Row, Integer, Integer -> Row; "//": Row, Row -> Row; Select: Row, Integer, Integer -> Row /* and other operators relevant for rows of items */ AXIOMS /* The equations for the operators above, among * / * which the following two (or equivalents) */ Length(r) = max _length ==> Insert(r, itm, int) == Error!; Length(r1) + Length(r2) > max _length ==> r1//r2 == Error! ENDGENERATOR Row; A noter que l'operateur formel Length (longueur) et le litteral Empty (vide) sont donnes une fois de plus dans le corps du generateur parce qu'ils sont renommes lors de leur instantiation. Dans le cas de l'operateur, les arguments et la sorte de resultat ne sont donnes que dans le corps. Le generateur Row (rangee) peut servir a faire des lignes, des pages et des livres, comme suit: NEWTYPE Line Row(Character, Width, Empty _line, 80) ENDNEWTYPE Line; NEWTYPE Page Row(Line, Length, Empty _page, 66) ENDNEWTYPE Page; NEWTYPE Book Row(Page, Nr _of _pages, Empty _book, 10000) ENDNEWTYPE Book; D.6.2.2 Heritage L'heritage constitue un moyen d'etablir toutes les valeurs de la sorte dite parente, certains ou tous les operateurs du type parent et toutes les equations du type parent. Pour les litteraux et les operateurs, il existe une possibilite de les nommer a nouveau. En general, c'est une methode satisfaisante parce que, dans ce cas, le lecteur peut deduire du contexte qu'il s'agit d'un autre type, m | me si les litteraux sont les m | mes. Si un operateur n'est pas herite, on lui attribue systematiquement un autre nom inaccessible a l'utilisateur. Le fait que les operateurs sont encore presents signifie que toutes les equations du type parent sont encore presentes (avec des operateurs portant un autre nom). Cela garantit que les valeurs parentes sont heritees. Avec la possibilite d'emp | cher l'utilisation d'un operateur (lorsqu'il n'est pas herite), on assure la possibilite d'ajouter de nouveaux operateurs. Apres le mot cle ADDING, on peut donner des litteraux, des operateurs et des equations comme dans un type ordi- naire. Toutefois, il faut faire attention aux nouveaux litteraux et aux confusions possibles entre operateurs herites et ajoutes. Lorsque les litteraux sont ajoutes, le resultat des operateurs herites, appliques a des nouveaux litteraux, doit | tre defini (par des equations). Lorsque des operateurs sont ajoutes, il ne faut pas oublier les operateurs nommes a nouveau de maniere invisi- ble et les equations associees. Les equations de definition des operateurs ajoutes devraient | tre compatibles avec les equations comportant des operateurs herites et non herites. Apres cette liste d'avertissements, prenons quelques exemples: a) Supposons que le newtype couleur est complet et disponible. Ce type est fonde sur le choix et le melange de fais- ceaux de lumiere de couleur primaire. Il faudrait de longues reflexions et un long texte et/ou copie pour definir quelque chose de semblable pour le choix et le melange de peinture. Une solution commode a ce probleme consiste a faire du newtype Colour (couleur) un generateur en effectuant uniquement deux remplacements: 1) la premiere ligne NEWTYPE Colour devient GENERATOR Colour (TYPE Primary _colour) 2) le mot-cle ENDNEWTYPE devient ENDGENERATOR. On peut maintenant nommer a nouveau le generateur lorsqu'il est instancie. Supposons que la sorte anterieure Primary _colour soit appelee Light _primary, et que la sorte Paint _pri- mary soit definie comme: NEWTYPE Paint _primary LITERALS Red, Yellow, Blue ENDNEWTYPE Paint _primary; Il est maintenant tres facile de definir deux types simi- laires, un pour la lumiere et un pour la peinture: NEWTYPE Light _colours Colour (Light _primary) ENDNEWTYPE; NEWTYPE Paint _colours Colour (Paint _primary) ENDNEWTYPE; Il n'y a pas de probleme jusqu'ici, mais comment peut-on voir la difference entre Take (Red) de Light _colour et celui de Paint _colour avec la m | me syntaxe? S'il est necessaire de distinguer entre ces deux termes, on peut avoir recours a l'heritage. Au lieu de Light _colours et Paint _colours, les types Light (lumiere) et Palette sont definis par heritage et le nom de l'operateur Take (prendre) est modifie: NEWTYPE Light INHERITS Light _colours OPERATORS (Beam=Take, Mix, Contains) ADDING LITERALS White AXIOMS White == Mix (Red, Mix (Yellow, Beam (Blue))) ENDNEWTYPE Light; Maintenant le newtype Light (lumiere) a les litteraux de Light _colours et le litteral White (blanc). Light _colours n'a pas de litteraux qui lui soient propres (car il utilise les litteraux de Light _primary), de sorte que White est le seul litteral de Light. Les operateurs et les equations de Light sont les m | mes que ceux de Light _colours, a l'exception du fait que le nom d'operateur Take est remplace par Beam (faisceau) et que l'equation pour White a ete ajoutee. L'axiome ajoute indique que ce litteral ajoute devient un element de l'ensemble de termes dans lequel les trois couleurs primaires sont melangees. Le newtype Palette a les litteraux de Paint _colours et l'operateur Take est remplace par Paint (peinture): NEWTYPE Palette INHERITS Paint _colours OPERATORS (Paint _Take, Mix, Contains) ENDNEWTYPE Palette; b) Admettons que l'on veuille etendre l'ensemble de types entiers (sorte Int _set), introduit dans la section precedente, par un operateur qui trouve le plus petit entier de l'ensemble. Tout d'abord, il faut se demander si cet operateur peut | tre introduit dans la definition de generateur pour le rendre disponible a tous les ensembles et autres choses. S'il est vrai que cela peut | tre fait, cela limiterait l'element a la definition de > et <. Cela ne convient pas a tous les elements (PId par exemple) et il peut | tre preferable de creer un newtype ayant la sorte New _int _set comportant un operateur Min. NEWTYPE New _int _set INHERITS Int _set OPERATORS ALL ADDING OPERATORS Min: New _int _set-> Integer AXIOMS Min(Empty _int _set) == Error!; Min(Add(Empty _int _set, x))==x; Min(Add(Add(nis,x),y))== IF y <Min(Add(nis,x)) THEN y ELSE Min(Add(nis,x)) FI ENDNEWTYPE New _int _set; Etant donne que l'adjonction apres une instantiation de generateur est relativement courante, le texte commencant par ADDING et se terminant juste avant le ENDNEWTYPE peut | tre donne a l'interieur de l'instantiation de generateur. On en trouvera un exemple au S 5.4.1.12 de la Recommandation. D.6.3 Observations relatives aux equations Lorsque l'on introduit un nouveau type de donnees, il est essentiel d'introduire suffisamment d'equations. Dans les paragraphes qui suivent, trois observations sont presentees concer- nant les equations qui en faciliteront l'etablissement. D.6.3.1 Conditions generales De quelque maniere que l'on construise les equations, il faut tenir compte des faits suivants: a) chaque operateur appara | t au moins une fois dans l'ensemble des equations (sauf pour les cas <<patholo- giques>>); b) tous les enonces vrais peuvent | tre tires des equations. Ils sont soit indiques comme des axiomes, soit deduits par substitution de termes equivalents dans les equations; c) aucune incoherence doit | tre decelee, c'est-a-dire que l'on ne peut deduire des equations que Vrai = Faux. Une procedure permettant de trouver des equations peut | tre exprimee en LDS informel, comme indique dans la figure D-6.3.1. D.6.3.2 Application de fonctions aux constructeurs D'une maniere generale, l'ensemble d'operateurs possede un sous-ensemble d'operateurs appeles <<constructeurs>> et <<fonc- tions>>. Les constructeurs peuvent servir a generer toutes les valeurs (classes d'equivalence) de la sorte. Dans cette approche, les litteraux sont consideres comme des operateurs sans argument. Exemples: a) le type booleen a ses litteraux pour construc- teurs; b) le type naturel a le litteral 0 et l'operateur Next comme constructeurs; un naturel quelconque peut | tre con- struit seulement avec 0 et Next; c) le generateur pour les ensembles a le litteral ensemble _vide et l'operateur _additif comme constructeurs; un ensemble quelconque ne peut | tre construit qu'en utilisant Empty _set (ensemble _vide) et Add (ajouter); d) le type entier peut | tre construit au moyen des litteraux 0 et 1, des operateurs + et moins unaires. Figura D-6.3.1, (N), p. 12 A noter qu'il y a parfois plusieurs choix possibles pour l'ensemble de constructeurs. Tout choix sera valable pour le reste de la presente section mais les petits ensembles sont generalement les meilleurs. Ensuite, les fonctions sont traitees une par une. Pour chaque argument d'une fonction, seuls sont enumeres tous les termes possi- bles composes de constructeurs. Pour eviter le probleme que posent les nombres infinis de termes, il faut appliquer la quantification. Exemples: a) Pour les nombres naturels, cette liste peut | tre reduite a: 0 Next (n) ou n est tout nombre naturel. b) Pour les ensembles, la liste eventuelle peut | tre: empty _set Add (s,i) ou s est tout ensemble et i tout element (item). Si, dans le terme de droite d'une equation ayant (s,i) du c | te gauche, il y a une difference entre s etant vide ou n'etant pas vide, on peut reecrire la liste comme suit: empty _set Add (empty _set,i) ou i est un element (item) quelconque, Add (Add (s,i),j) ou s est un ensemble quelconque et i, j, un element quelconque. Apres la creation de cette liste, on obtient les parties de gauche des equations en appliquant chaque fonction a une com- binaison d'arguments tires de la liste. Les identificateurs de valeurs de differents arguments recoivent des noms differents. La procedure indiquee ci-dessus pour les fonctions peut | tre appliquee aux constructeurs; dans ce cas, elle donne les relations entre des termes ou les constructeurs sont utilises dans differents ordres. Exemples: a) Pour l'operateur de multiplication de nombres naturels portant la signature <<*>>:Natural, Natural -> Natural Cette procedure donne la partie de gauche des equations (incompletes) suivantes. L'utilisateur devra ajouter la partie de droite. Next (n) 0*0 == . | | ; Next (n) 0*Next (n) == . | | ; Next (n)*0 == . | | ; Next (n)*Next (m) == . | | ; b) Pour les operateurs Is _in (est _dans) et Delete (supprimer, dans le generateur Set (voir le S D.6.2.1), cette approche est deja appliquee. c) Pour la sorte Colour, les constructeurs sont Take et Mix. Un operateur analogue a Contains dans le S D.6.1.4.2 doit | tre defini pour les arguments. Take(p) ou p est toute couleur primaire Mix(p,c) ou p est toute couleur primaire et c une couleur quelconque. Etant donne que l'on avait annonce au S D.6.1.4.2 que les equations completes seraient donnees pour cet operateur: Contains(Take(p),q) ==p=q; Contains(Mix(p,c),q) ==(p=q) OR Contains(c,q); Cette procedure de construction peut donner plus d'equations que cela n'est necessaire, mais elle est tres s | re. Dans l'exemple susmentionne de multiplication des nombres naturels, il est vraisemblable que la propriete de commutativite de la multipli- cation sera indiquee et qu'en consequence, seule la derniere (ou la seconde) equation des trois premieres sera necessaire. La procedure decrite dans cette section peut | tre appliquee en combinaison avec la procedure decrite dans la section precedente, ou elle est utile pour la t | che <<Penser _a _un _enonce>>. D.6.3.3 Specification d'ensemble d'essai On peut aussi considerer les equations du point de vue de la mise en oeuvre. Si les operateurs sont mis en oeuvre sous la forme de fonctions dans un langage de programmation, les equations mon- trent comment ces fonctions doivent | tre testees. Il convient d'evaluer les expressions correspondant a la par- tie de gauche d'une equation, de faire de m | me pour la partie droite de cette equation et de voir si elles sont equivalentes. C'est la construction FOR ALL qui pourrait poser certains problemes. Ceux-ci peuvent souvent | tre resolus de maniere pragmatique: Au lieu de tif de test peut utiliser FOR ALL i IN Integer le dispositif de test peut utiliser FOR ALL i IN { (em10,-1,0,1,1 } et proceder ainsi dans la plupart des cas. Considerer des equations comme necessaires a la mise en oeuvre peut | tre utile pour ce qui est de la t | che <<Penser _a _un _enonce>> dans la procedure du S D.6.3.1. D.6.4 Caracteristiques La presente section decrit certains dispositifs du LDS qui sont rarement necessaires dont on peut pratiquement se passer, mais qui rendent quelquefois la t | che plus facile. D.6.4.1 Operateurs caches Il arrive que l'ensemble des equations puisse | tre simplifie ou rendu plus lisible gr | ce a l'introduction d'un operateur supplementaire, mais cet operateur ne devrait pas | tre utilise dans les processus. Cela signifie que l'operateur est visible de l'interieur mais cache en dehors de la definition de type. On peut atteindre ce resultat en definissant un <<type cache>>, c'est-a-dire un type que l'utilisateur ne doit pas employer. A partir de ce type cache, l'utilisateur peut heriter de tous les operateurs auxquels il peut avoir acces; c'est le type herite qui doit | tre utilise. On peut s'assurer qu'il est correctement employe en examinant toutes les declarations de vari- ables (aucune variable de sorte introduite par le type cache ne doit appara | tre). Ce qui caracterise les operateurs caches, c'est qu'ils peuvent | tre atteints par une restriction de leur visibilite aux seules equations. On peut le faire en placant un point d'exclamation apres l'operateur. Exemple: La maniere courante de faire un ensemble d'un element a partir du generateur Set est la suivante: Add(empty _set,x) et c'est ainsi que doit le faire chaque utilisateur. Dans les equa- tions, le specificateur peut utiliser un operateur special, par exemple: Mk _set!:Item->Set; defini par l'equation: Mk _set!(itm) == Add(empty _set,itm); qui peut | tre utilise dans des definitions de type partiel mais non dans le corps de processus en LDS. D.6.4.2 Relations d'ordre Lorsqu'il faut specifier une relation d'ordre sur les elements d'une sorte, cela signifie en general qu'il faut definir quatre operateurs (<,<=,>,>=) et les proprietes mathematiques ordinaires (transitivite, etc.). S'il y a de nombreux litteraux, il faut egalement donner de nombreuses equations. Par exemple, le type de donnees predefinies Character est defini de cette maniere. Le LDS comporte une caracteristique qui permet d'abreger ces definitions de type longues, peu lisibles et ennuyeuses: c'est l'abreviation ORDERING (relation d'ordre). ORDERING est donne dans la liste d'operateurs, de preference au debut ou a la fin de celle-ci. Cela permet d'introduire des operateurs de relation d'ordre et les equations normales. Lorsque ORDERING est specifie, il faut donner les litteraux, s'il en existe, dans l'ordre ascendant. Exemple: NEWTYPE Even _decimal _digit LITERALS 0,2,4,6,8 OPERATORS ORDERING ENDNEWTYPE Even _decimal _digit; Maintenant, l'ordre 0<2<4<6<8 est implicite. Au S D.6.2.2 (Heritage), on soulignait qu'il fallait s'assurer que les litteraux etaient ajoutes a une sorte heritee. Il convient d'en indiquer ici la raison. Admettons que l'on desire l'extension suivante de la sorte Even _decimal _digit: NEWTYPE Decimal _digit INHERITS Even _decimal _digit OPERATORS ALL ADDING LITERALS 1,3,5,7,9 AXIOMS 0<1; 1<2; 2<3; 3<4; 4<5; 5<6; 6<7; 7<8; 8<9 ENDNEWTYPE Decimal _digit; Les axiomes donnes ici ne peuvent | tre omis. Sans ces axiomes, il ne peut y avoir qu'un ordre dit partiel: 0<2<4<6<8 et 1<3<5<7<9. Avec les axiomes ci-dessus, on obtient un ordre complet: 0<1<2<3<4<5<6<7<8<9 mais avec l'axiome <<9<0>> au lieu de l'ensemble d'axiomes ci-dessus, l'ordre complet serrait le suivant: 1<3<5<7<9<0<2<4<6<8. D.6.4.3 Sortes avec champs Comme indique au S 5.4.1.10 de la Recommandation, on peut definir une sorte structuree sans constructions speciales, mais les sortes structurees sont a la fois courantes et utiles, ce qui jus- tifie certaines constructions supplementaires dans le langage. Une sorte structuree devrait | tre utilisee lorsqu'une valeur d'objet est formee par l'association de valeurs de plusieurs sortes. Chaque valeur de cette association est caracterisee par un nom, appele nom de champ. La sorte d'un champ est fixe. Exemples: NEWTYPE Subscriber STRUCT numbers Number _key; name Name _key; admin Administrative; ENDNEWTYPE Subscriber; NEWTYPE Name _key STRUCT name, street Charstring; number Integer; city Charstring; ENDNEWTYPE Name _Key; Avec une sorte structuree, certains operateurs sont definis implicitement: a) l'operateur constructeur, <<(.<<avant, et>>.)>> apres les valeurs de champ; b) les operateurs de selection de champ, les vari- ables de la sorte structuree suivies par un ! et le nom de champ, ou suivies par le nom de champ entre parentheses. Il ne faut pas confondre la variable suivie d'un ! avec l'operateur cache (S D.6.4.1). On trouvera un exemple dans la figure D-6.4.1. Figure D.6.4.1 (comme tableau) [T39.100], p. 13 D.6.4.4 Sortes indexees Une sorte indexee est une sorte pour laquelle le type a pour nom d'operateur Extract! (extraction). Dans les types de donnees predefinies, le generateur Array est un tel type. Array est l'un des exemples les plus courants de type indexe. Pour l'operateur cache Extract!, il existe une syntaxe concrete speciale qui doit | tre appliquee en dehors des definitions de type. On peut penser que le type Index dans le generateur predefini Array doit | tre un type <<simple>> comme Integer, Natural ou Character. Toutefois, il n'y a pas de raison pour qu'une structure comme Name _key ne puisse pas | tre utilisee comme Index. Exemple: NEWTYPE Subsc _data _base Array (Name _key, Subscriber) ENDNEWTYPE Subsc _data _base; Les sortes Name _key et Subscriber sont celles qui ont ete definies dans la section precedente. Supposons qu'il existe une procedure Bill comportant un parametre de sorte Subscriber et que cette procedure soit definie dans un processus qui comporte aussi une variable Sub _db de la sorte Subsc _data _base. Dans ce pro- cessus, l'appel suivant pourrait appara | tre. CALL Bill (Sub _db) (. `P.M.`, `Downingstreet`10. `Lon- dres`.))); D.6.4.5 Valeur par defaut de variables Comme indique dans la section concernant la declaration de variables (S D.3.10.1), il est possible d'affecter des valeurs a une variable immediatement apres la declaration. Cependant, cer- tains types ont une valeur qui sera (presque) toujours la valeur initiale d'une variable. Il existe une caracteristique qui permet d'eviter d'ecrire la valeur initiale pour chaque declaration: la clause DEFAULT. A titre d'exemple, on peut considerer l'ensemble. Il est tres probable que presque toutes les variables, de tout ensemble ima- ginaire, seront initialisees avec empty _set. La notation: DEFAULT empty _set apres la liste d'equations indique que chaque variable de chaque instantiation de ce generateur sera initialisee a la valeur empty _set de cette instantiation, sauf s'il y a une initialisation explicite (voir le S D.3.10.1.) S'il n'est par s | r que la valeur initiale de toutes les variables d'une sorte soit la m | me, il ne faut pas utiliser la clause DEFAULT, sinon il est difficile d'eviter des surprises. D.6.4.6 Operateurs actifs Les utilisateurs qui connaissent la Recommandation Z.104 de 1984 concernant le LDS pourraient se demander ce qui est arrive aux operateurs dits actifs. En fait, cette caracteristique a ete supprimee, pour les raisons suivantes: a) elle n'est pas necessaire car les operateurs courants et les procedures et/ou macros offrent la m | me capacite d'expression; b) elle compromet la lisibilite des equations; c) de nombreux utilisateurs ont eu des difficultes a l'utiliser correctement; d) elle ne s'integre pas au modele de type de donnees abstrait fonde sur les algebres initiales qui constituent le modele choisi comme base mathematique de cette partie du LDS. MONTAGE: S D.7 SUR LE RESTE DE CETTE PAGE