Brevet FR2786003A1 — publié le 20000519

PROCEDE DE GENERATION DU CODE SOURCE D'UN PROGRAMME POUR UN EQUIPEMENT INFORMATIQUE La présente invention concerne un procédé de génération du code source d'un programme pour un équipement informatique. Elle se rapporte au domaine du génie logiciel, c'est-à-dire l'ensemble des méthodes de production de programmes nécessaires au fonctionnement d'équipements informatiques. Par équipement informatique, on entend dans le présent exposé, au sens large, tout équipement comprenant des composants matériels et des composants logiciels coopérant en vue de l'obtention d'un résultat technique. Dans la suite, on considère l'exemple non limitatif d'un autocommutateur pour la gestion d'un réseau téléphonique privé (PABX). Le code source d'un programme est l'expression du programme sous forme non exécutable, dans un langage de programmation évolué tel que les langages C, ADA, Pascal, JAVA, etc., Pour convertir le code source en un programme exécutable par une machine, on doit réaliser une opération, dite opération d'assemblage, à I'aide d'un programme spécifique appelé assembleur. Les équipements informatiques complexes présentent en général un ensemble de fonctionnalités différentes. Par exemple, un autocommutateur peut comprendre les fonctionnalités : . la gestion d'une messagerie ; . la gestion d'un répertoire de numéros d'appel ; . le transfert d'appel ; . le parcage d'appel ; . le va-et-vient entres plusieurs appels ; . ta conférence à trois ; . I'interphonie, etc. Dans la pratique, un équipement est conçu pour fonctionner dans un environnement déterminé, impliquant une architecture matérielle déterminée, et pour tre piloté par un programme dont le code source est rédigé dans un langage de programmation déterminé (on parle de programme pilote). Par raccourci, on désignera dans la suite par "équipement de type déterminé", un équipement fonctionnant dans un environnement déterminé et étant pilote par un programme dont le code source est rédigé dans un langage déterminé. Des équipements de mme nature, par exemple des autocommutateurs, peuvent ainsi tre de types différents. En outre, un équipement de type déterminé fait en général l'objet d'une personnalisation des fonctionnalités qu'il présente, afin de correspondre aux besoins exprimés par l'utilisateur ou, d'une manière générale, de remplir les fonctions requises par l'application qui en est faite. Par exemple, le propriétaire d'un réseau téléphonique privé peut réclamer un autocommutateur présentant certaines seulement des fonctionnalités envisagées ci-dessus, et non les autres. Cette personnalisation implique principalement la conception d'un programme pilote adapté. II est souhaitable que cette conception puisse tre réalisée par le distributeur des équipements, car c'est lui qui définit avec le client les fonctionnalités finales de l'équipement. Cependant, les compétences de ce distributeur sont par essence plus commerciales que techniques. Un problème particulier provient du fait mentionné plus haut que des équipements de mme nature peuvent tre de types différents. Le distributeur n'étant pas un spécialiste de la programmation, il n'a pas de connaissances assez étendues pour concevoir un programme pilote pour les équipements de divers types qu'il propose à la vente. On sait déjà composer un programme en assemblant des modules logiciels prédéfinis, ce qui simplifie et accélère grandement la tâche. Néanmoins, cette opération demeure une opération techniquement délicate. II faut en pratique faire appel à un homme du métier ad hoc, en l'occurrence un spécialiste de la programmation ayant en plus une bonne connaissance des différents types d'équipements. Ceci augmente le coût et le délai de livraison de l'équipement. Le but de la présente invention est de simplifier la génération du code source d'un programme pour un équipement informatique, en faisant en sorte que cette génération soit à la portée d'un individu n'ayant pas de connaissances particulières de l'architecture matérielle des différents équipements, ni des différents langages de programmation. A cet effet, I'invention propose un procédé de génération du code source, exprimé dans un langage de programmation déterminé, d'un programme pour un équipement informatique devant fonctionner dans un environnement déterminé, qui comprend les étapes : a) sélection de l'environnement de fonctionnement et/ou du langage de programmation ; b) sélection d'au moins une fonctionnalité du programme ; c) production d'un jeu de règles d'agrégation spécifiques de l'environnement de fonctionnement et/ou du langage de programmation, avec une ou plusieurs règles pour chaque fonctionnalite du programme ; d) agrégation, en fonction des règles d'agrégation, de blocs de code source rédigés dans ledit langage de programmation et implémentant lesdites fonctionnalités du programme dans ledit environnement d'utilisation. Ainsi, l'utilisateur n'intervient que pour les étapes de sélection a) et b) qui peuvent tre réalisées à I'aide notamment d'une interface homme/machine adaptée. Une telle interface offre à l'utilisateur des représentations graphiques des fonctionnalités (en pratique des icônes sur un écran d'ordinateur). Elle comprend par exemple un écran d'ordinateur, un clavier et/ou une souris, et des moyens logiciels adaptés. Elle est facilement utilisable par un individu non-spécialiste de la programmation. Les étapes c) et d) sont réalisées respectivement par un premier et par un second programmes adaptés, appelés respectivement moteur de production de règles, et moteur d'agrégation. L'étape c) est réalisée en fonction du résultat des sélections opérées par l'utilisateur aux étapes a) et b). L'étape d) est réalisée en fonction des régies d'agrégation produites à l'étape c). De cette manière, l'agrégation de blocs de code de source n'est pas réalisée directement par l'utilisateur. Elle est réalisée par un programme ad hoc, en fonction d'un certain nombre de régies d'agrégation, elles-mme produites en fonction de la sélection d'un environnement d'utilisation et/ou d'un langage de programmation déterminés et de la sélection d'au moins une fonctionnalité du programme pilote opérées par l'utilisateur. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit tre lue au regard des dessins annexés sur lesquels, on a représenté : -à la figure 1 : un schéma du principe de génération de code source selon l'invention ; -à la figure 2 : un schéma d'un fichier contenant les régles d'agrégation ; -à la figure 3 et à la figure 4 : des schémas librairies contenant des blocs de code source ; -à la figure 5 et à la figure 6 : des schémas représentant des fichiers contenant du code source généré selon l'invention avec les règles d'agrégation de la figure 2. A la figure 1, on a représenté schématiquement l'unité centrale 10 d'un ordinateur, reliée à des périphériques classiques tels qu'un écran 20, un clavier 30 et une souris 40. Cet ordinateur convient pour la mise en oeuvre du procédé de génération de code source selon l'invention. II est piloté par un utilitaire (c'est-à-dire un logiciel) ad hoc, sous la commande d'un utilisateur. Celui-ci n'a pas besoin de connaissances particulières en informatique, du moins pas de connaissances allant au-delà de la simple capacité à utiliser des logiciels tels que ceux qui sont maintenant largement répandus dans la bureautique, professionnelle ou domestique. Un écran d'accueil (non représenté) de l'utilitaire comprend des barres de menu, et/ou des icônes et/ou toutes autres représentations graphiques de commandes qui peuvent tre sélectionnées à I'aide des touches du clavier 30 et/ou de la souris 40. Chaque commande permet la sélection, par l'utilisateur, d'une part des caractéristiques de l'équipement informatique du type considéré (c'est-à-dire son environnement de fonctionnement et le langage de son programme pilote), et d'autre part de ses fonctionnalités. Par exemple, des barres de menu permettent, en coopération avec le clavier ou la souris, de sélectionner l'environnement de fonctionnement de l'équipement, à savoir par exemple le type de l'installation téléphonique destinée à recevoir l'autocommutateur (à bus unique, à étoile de bus, etc...). Le cas échéant, d'autres barres de menu permettent, toujours en coopération avec le clavier ou la souris, de sélectionner le langage de programmation du programme pilote de l'équipement. En outre, des icônes permettent, en coopération avec la souris, de sélectionner des fonctionnalités de J'équipement. Dit autrement, l'interface homme/machine comporte une représentation graphique des caractéristiques et des fonctionnalités du programme à générer, qui permet leur sélection par l'utilisateur d'une manière simple et intuitive, proche de la formulation en langage naturel. Un fichier RULES-FILE (dit fichier de règles produites) est chargé avec des règles d'agrégation Rl, R2, R3... lors d'une étape de production de ces régies. La fonction d'une règle d'agrégation est de définir l'origine et la destination d'un bloc de code source déterminé, qui est dupliqué et agrégé lors d'une étape d'agrégation, ainsi éventuellement que sa situation vis à vis d'un autre bloc au sein d'un fichier de destination. En effet, des blocs de code source prédéfinis sont contenus à l'origine dans une ou plusieurs librairies telles que Lib0ne et Lib-Two. En fonction des règles d'agrégation générées, des blocs déterminés sont dupliqués et agrégés dans un ou plusieurs fichier de destination tels que TARGETOne et Target-Two. Les règles d'agrégation sont en quelque sorte des instructions de copie comprenant des paramètres. Un exemple du contenu du fichier RULES-FILE est donné à la figure 2, sur laquelle des régies d'agrégation R1 à R9 sont écrites sous la : RULE (xxx, yyy, www, zzz) où les éléments xxx, yyy, www, et zzz sont les paramètres de la règle définissant respectivement les éléments : . le nom du bloc concerné par la règle ; . une indication du niveau de priorité associé au bloc lors de l'agrégation (qui détermine l'ordre d'exécution des règles d'agrégation, ainsi qu'on le verra plus loin) ; . le nom de la librairie d'origine ; . le nom du fichier de destination. Les deux premiers paramètres ci-dessus sont appelés paramètres d'identification du bloc (ou signature). Comme on I'aura compris, le fichier RULES-FILE doit contenir une règle d'agrégation psr bloc de code source à agréger. Comme on I'a dit ci-dessus, des blocs de code source prédéfinis, c'est-à-dire rédigés à I'avance, sont mémorisés dans une ou plusieurs librairies telles que Lib-One et Lib-Two (figure 1). On dira qu'une librairie "contient"des blocs de code source. Dans le domaine du génie logiciel, une librairie est un fichier contenant des blocs de code non forcément liés entre eux d'un point de vue fonctionnel ou logique. Au sein d'un mme bloc, le code source est rédigé dans un seul et unique langage de programmation. Le code source relatif à (c'est-à-dire implémentant) une fonctionnalité donnée est souvent divisé en blocs distincts. Ceci n'est pas absolument nécessaire mais permet de simplifier la conception et la maintenance (réalisation des corrections ou des mises à jour) du code source. II faut agréger un ou plusieurs blocs de code source rédigés dans le mme langage de programmation et relatifs à chaque fonctionnalité pour composer le code source du programme pilote d'un équipement ayant plusieurs fonctionnalités. Dans le présent exposé, le terme"agréger"est utilisé comme signifiant"réunir en un tout des parties distinctes". Néanmoins, dans un cas limite, un unique bloc de code source peut constituer à lui seul le code source d'un programme pilote, si celui-ci n'a qu'une fonctionnalité et si celle-ci est assez simple. Ce cas sera en réalité extrmement rare et n'est mentionné ici qu'afin de garantir toute sa généralité à la fonction d'agrégation selon l'invention. Pour une mme fonctionnalité, il existe des blocs de code source équivalents, pour chaque environnement de fonctionnement et/ou pour chaque langage de programmation. La logique du regroupement des blocs de code source au sein des librairies est choisie, notamment, de manière à faciliter la maintenance de l'ensemble. Dans un mode de réalisation, une mme librairie contient des blocs de code source rédigés dans un mme langage de programmation. Néanmoins ceci n'est pas obligatoire, et une librairie peut contenir des blocs de code source rédigés dans des langages de programmation différents. Dans un autre mode de réalisation, une librairie déterminée contient uniquement des blocs de code source relatifs à un et un seul environnement d'utilisation de l'équipement. Dans un autre mode de réalisation encore, une librairie déterminée contient uniquement des blocs de code source relatifs à une et une seule fonctionnalité du programme pilote. Ces modes de réalisations peuvent éventuellement se combiner. Dit autrement une librairie déterminée peut, par exemple contenir des blocs de code source qui sont à la fois relatifs à un environnement d'utilisation déterminé et rédigés dans un langage de programmation déterminé. A la figure 3 et à la figure 4, on a représenté, de façon schématique, le contenu des librairies Lib0ne et Lib-Two de la figure 1. Les blocs de code source sont schématiquement représentés par trois traits horizontaux. Dans une librairie, un bloc de code source est repéré par un marqueur de début de bloc et un marqueur de fin de bloc. Les marqueurs sont par exemple des mots ayant une valeur particulière et identifiable. Ils ont une première fonction qui est de repérer le début et la fin d'un bloc de code source dans une librairie. En outre les marqueurs peuvent tre de types différents. Par exemple, aux figures, on distingue des marqueurs de début de bloc différents, à savoir MARKER~1, MARKER~2 et MARKER3, auxquels correspondent les marqueurs de fins de bloc associés, respectivement ENDMARKER1, ENDMARKER2 et ENDMARKER3. A chacun de ces couples de marqueurs correspond un niveau de priorité associé au bloc repéré par les marqueurs. Ces niveaux de priorité associés aux blocs interviennent pour déterminer l'ordre dans lequel les blocs sont agrégés lors de l'étape d'agrégation, II est en effet courant que des parties de code source doivent se trouver avant d'autres au sein d'un fichier contenant le code source d'un programme, afin de respecter une certaine syntaxe dans la programmation. A titre d'illustration, on peut noter qu'un programme comprend classiquement, dans cet ordre, une partie de déclaration des variables utilisées, puis une partie de déclaration des fonctions utilisées, et enfin une partie correspondant au corps du programme proprement dit. C'est la deuxième fonction des marqueurs au sens de la présente invention, que d'indiquer le niveau de priorité associé au bloc. En pratique, le marqueur de début de bloc est fourni comme deuxième paramètre d'identification du bloc dans la règle d'agrégation. L'effet produit est une détermination de l'ordre dans lequel ! a régie d'agrégation correspondante sera exécutée par rapport aux autres règles d'agrégation. Le génération du code source d'un programme pilote s'effectue comme il va maintenant tre décrit. L'utilisateur sélectionne l'environnement de fonctionnement de l'équipement, ou le langage de programmation du programme pilote à générer, ou les deux (étape a)).)) sélectionne ensuite une fonctionnalité souhaitée du programme pilote (étape b)). Ces sélections sont réalisées par l'utilisateur par l'intermédiaire de l'interface homme/machine précitée. Le reste des opérations est réalisé de manière transparente vis à vis de l'utilisateur, c'est-à-dire que, en principe, il n'a pas besoin d'intervenir (sauf pour lancer l'exécution des autres étapes où pour interrompre leur exécution de toute manière appropriée). Lors de l'étape b), une commande associée à l'icône symbolisant la fonctionnalité sélectionnée est exécutée. Cette commande a pour effet de sélectionner (étape c)), parmi des régies prédéfinies, spécifiques de la fonctionnalité, celles et seulement celles qui concernent l'environnement de fonctionnement et le langage de programmation sélectionnés à l'étape a). Toutes les régies prédéfinies qui sont spécifiques de la fonctionnalité, sont mémorisées dans un fichier permanent (non représenté à la figure 1). Elles sont accessibles par l'intermédiaire de paramètres liés à l'environnement de fonctionnement de l'équipement et au langage de programmation. Les règles d'agrégation sélectionnées sont copiées dans le fichier de règles sélectionnées RULES~FILE (figure 1). L'étape b) est éventuellement répétée par l'utilisateur, en sorte de sélectionner plusieurs fonctionnalités consécutivement pour chaque fonctionnalité. Toutes les règles d'agrégation sélectionnées sont copiées dans le fichier RULES-FILE, qui est unique, à la suite les unes des autres. Dit autrement, l'étape c) est également répétée. Dans un mode de réalisation avantageux, après l'étape c) (i. e. la dernière itération de l'étape c)), mais avant l'étape d'agrégation (étape d)), les régies d'agrégation stockées dans le fichier de règles sélectionnées RULES-FILE sont filtrées pour éliminer les doublons. En effet, il peut arriver qu'un mme bloc de code source soit nécessaire à l'implémentation de deux fonctionnalités différentes. Dans le cas où ces deux fonctionnalités sont sélectionnées, la mme règle d'agrégation sera copiée deux fois dans le fichier RULES-FILE (deux régies sont considérées comme identiques si elles ont les mmes paramètres). Ceci est notamment le cas pour des blocs de code source correspondant par exemple à des parties de déclaration de variables ou de fonctions du programme. Or, il n'est pas nécessaire de dupliquer ces parties de code source dans le programme à générer. Avantageusement, ce sont les règles d'agrégation en double qui sont éliminées du fichier RULESFtLE et non les blocs de code source en double qui sont éliminés des fichiers de destination. De cette manière, la copie de blocs inutiles est évitée, en sorte que la génération du code source est plus rapide, et exempte d'erreur de programmation liée à la double déclaration de variables ou de fonctions. Ensuite, l'agrégation est réalisée par copie des blocs de code source, depuis leur librairie d'origine, par copie et concaténation dans au moins un fichier de destination (étape d)). Comme on I'a dit plus haut, cette agrégation s'effectue par exécution des règles d'agrégation. Chacune de celles-ci réalise la copie d'un bloc de code source déterminé en fonction de paramètres comprenant un ou plusieurs paramètres d'identification du bloc (en l'espèce son nom et le type des marqueurs de bloc), le nom de la librairie dans laquelle il est mémorisé, et le nom du fichier de destination dans lequel il doit tre copié. Et les règles d'agrégation sont exécutées dans l'ordre croissant des niveaux de priorité qui leur sont associés. De cette manière, les blocs de code source sont concaténés dans l'ordre déterminé par les niveaux de priorité associés à chaque bloc. Aux figures 5 et 6, on a représenté de façon schématique le contenu des fichiers de destination Target-One et Target Two après l'exécution de l'étape d'agrégation d), sur la base des librairies Lib-One et Lib-Two des figures 3 et 4, et en fonction des règles d'agrégation contenues dans le fichier RULES-FILE de la figure 2. Sur les figures 5 et 6, les blocs de code source représentés aux figures 3 et 4 sont représentés de la mme manière et désignés par l'une des appellations suivantes : First~Part, Middle~Part~1, Middle-Part-2, Middle-Part 3 et Last-Part. Bien entendu, l'ordre de ces blocs dans les fichiers de destination respecte l'ordre croissant des niveaux de priorité déterminés par les types de marqueurs respectivement MARKER-1, MARKER 2 et MARKER 3 (dans cet ordre). Le contenu des fichiers de destination représentés aux figures 5 et 6 parle de lui-mme et ne sera pas décrit plus en détail. Dans un mode de réalisation particulier, les blocs de code source sont modifiés avant d'tre concaténés. Notamment, la modification des blocs de code source peut consister en une suppression de parties inutiles du bloc de code source compte tenu de 1'environnement de fonctionnement et du langage de programmation sélectionnés. Cette modification est réalisée au moment de l'agrégation en fonction de paramètres supplémentaires des règles d'agrégation prévus à cet effet. REVENDICATIONS 1. Procédé de génération du code source, exprimé dans un langage de programmation déterminé, d'un programme pour un équipement informatique déterminé devant fonctionner dans un environnement déterminé, caractérisé en ce qu'il comprend les étapes suivantes : a) sélection de l'environnement de fonctionnement et/ou du langage de programmation ; b) sélection d'au moins une fonctionnalité du programme ; c) production automatique d'un jeu de règles d'agrégation spécifiques de l'environnement de fonctionnement et/ou du langage de programmation, avec une ou plusieurs règles pour chaque fonctionnalité du programme ; d) agrégation automatique, en fonction des règles d'agrégation, de blocs de code source rédigés dans ledit langage de programmation et implémentant lesdites fonctionnalités du programme dans ledit environnement d'utilisation. 2. Procédé selon la revendication 1, caractérisé en ce que, à l'étape a) et/ou à l'étape b), la sélection est réalisée par l'utilisateur à I'aide d'une interface homme/machine. 3. Procédé selon la revendication 1, caractérisé en ce que, à l'étape c), pour chaque fonctionnalité, les règles d'agrégation sont produites par sélection parmi des règles spécifiques de la fonctionnalité, de celles et seulement celles qui concernent ledit environnement d'utilisation et ledit langage de programmation. 4. Procédé selon la revendication 3, caractérisé en ce que les règles d'agrégation générées pour différentes fonctionnalités sélectionnées sont stockées dans un unique fichier de règles sélectionnées (RULES-FILE). 5. Procédé selon la revendication 4, caractérisé en ce que, entre !'étape c) et l'étape d), les règles d'agrégation stockées dans le fichier de règles sélectionnées sont filtrées pour éliminer les doublons. 6. Procédé selon la revendication 1, caractérisé en ce que, à l'étape d), !'agrégation est réalisée par copie des blocs de code source qui sont mémorisés dans au moins une librairie et par concaténation dans au moins un fichier de destination. 7. Procédé selon la revendication 6, caractérisé en ce que une règle d'agrégation réalise une copie d'un bloc de code source en fonction de paramètres comprenant un ou plusieurs paramètres d'identification du bloc, le nom de la librairie (Lib~One, Lib~Two) dans laquelle il est mémorisé, et le nom du fichier (Target~One, TargetTwo) dans lequel il doit tre copié. 8. Procédé selon la revendication 6 ou selon la revendication 7, caractérisé en ce que les blocs de code source sont concaténés dans un ordre déterminé, en fonction d'un niveau de priorité associé à chaque bloc. 9. Procédé selon la revendication 8 caractérisé en ce que le niveau de priorité est déterminé par un, respectivement un autre paramètre, des paramètres d'identification du bloc de code source. 10. Procédé selon l'une des revendications 6 à 9, caractérisé en ce que les blocs de code source sont modifiés avant d'tre concaténés. 11. Procédé selon la revendication 10, caractérisé en ce que la modification des blocs de code source consiste en une suppression de parties inutiles du bloc de code source compte tenu de l'environnement de fonctionnement et du langage de programmation sélectionnés. 12. Dispositif pour la mise en oeuvre d'un procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une interface homme/machine intuitive pour la sélection de l'environnement de fonctionnement et/ou du langage de programmation, et la sélection d'au moins une fonctionnalité du programme. 13. Dispositif selon la revendication 12, caractérisé en ce qu'il comporte au moins une librairie contenant des blocs de code source rédigés dans un mme langage de programmation différent. 14. Dispositif selon la revendication 12 ou selon la revendication 13, caractérisé en ce qu'il comporte au moins une librairie déterminée contenant uniquement des blocs de code source relatifs 6 un et un seul environnement d'utilisation de l'équipement. 15. Dispositif selon l'une des revendications 12 à 14, caractérisé en ce qu'il comporte au moins une librairie déterminée contenant uniquement des blocs de code source relatifs à une et une seule fonctionnalité du programme.