FR 2836252 A1 20030822 FR 0202316 A 20020220 La présente invention concerne un procédé pour créer une plate-forme logicielle comprenant au moins deux applications destinées à coopérer, chacune munie d'une interface d'entrée/sortie et d'une fonctionnalité qui lui est propre. Les plate-formes logicielles sont de plus en plus souvent utilisées dans de multiples industries, par exemple celle de la production de produits manufacturés. En effet, un avantage essentiel d'une telle plate-forme logicielle est son caractère modulable, permettant de la faire évoluer pour l'adapter aux tâches qu'elle doit accomplir en ajoutant ou enlevant des applications de l'ensemble formé par la plate- forme sans avoir à modifier les autres applications. Pour ce faire, il est cependant indispensable de s'assurer que l'interface d'entrée/sortie d'une nouvelle application que l'on souhaite ajouter à une plate-forme logicielle existante soit compatible avec au moins les interfaces d'entrée/sortie de celles des applications déjà incluses dans ladite plate-forme avec lesquelles la nouvelle application est appelée à interagir, sans quoi la nouvelle application ne pourra pas communiquer avec le reste de la plate-forme. Dans l'état actuel de la technique, ceci implique un examen approfondi des programmes formant chaque application en cause afin de déterminer si des compatibilités existent entre les définitions des interfaces d'entrée/sortie de ces applications, et, si tel n'est pas le cas, une ré-écriture partielle de ces programmes pour assurer de telles compatibilités. Ces opérations d'examen et de ré-écriture sont complexes et longues à exécuter, et rendent donc coûteuses les évolutions de la plate-forme logicielle. L'invention a pour but principal de remédier dans une large mesure à cet inconvénient, en proposant un procédé permettant de créer une plate-forme logicielle d'une façon intuitive, qui ne nécessite pas d'examen approfondi des programmes de chaque application destinée à former partie de la plate-forme afin de déterminer si des compatibilités existent entre les définitions des interfaces d'entrée/sortie desdites applications. En effet, selon l'invention, un procédé conforme au paragraphe introductif inclut une étape d'assemblage d'objets associés aux dites applications, et une étape de validation de l'assemblage ainsi obtenu, lesdits objets étant prélevés depuis une bibliothèque d'objets préalablement créée en recensant des applications pré-existantes et en associant à chacune de ces applications pré-existantes un objet présentant une caractéristique sensorielle représentative de l'interface de ladite application, un assemblage de différents objets n'étant validé que si ledit assemblage forme un ensemble sensoriellement cohérent. L'avantage essentiel offert par l'invention est lié au caractère intuitif, et donc hautement ergonomique, que revêt le contrôle de compatibilité entre les différentes interfaces d'entrée/sortie des applications destinées à former partie de la plate-forme logicielle. A chaque objet pourra être attribué une caractéristique de nature sonore, définie par un spectre d'ondes acoustiques prédéterminé, auquel cas la sélection d'un objet pourra déclencher une émission d'un signal sonore propre à cet objet, par exemple un son produit par un instrument à cordes, à vent ou à percussion. Chaque fois qu'un nouvel objet sera ajouté à l'assemblage, un signal sonore d'ensemble, composé d'un mélange de tous les signaux sonores propres aux objets assemblés sera émis. Une cohérence sera observée si ce signal sonore d'ensemble ne contient que des sons produits par des instruments d'un même groupe, c'est-à-dire à cordes, à vent ou à percussion pour reprendre l'exemple précédent. On pourra utiliser, pour représenter les interfaces d'entrée/sortie des applications à assembler entre elles, d'autres types de signaux sonores, dès lors qu'il est possible de les répartir en groupes intellectuellement distincts, comme des sons produits par des animaux, des machines ou des cordes vocales humaines qui sont intellectuellement incohérents entre eux. Dans des évolutions encore expérimentales d'équipements utilisés dans l'industrie de conception de logiciels, des interfaces homme-machine de nature tactile, olfactive, voire gustative sont envisagés pour mener à bien des échanges d'informations entre machines et êtres humains. L'invention concerne tout procédé de création de plate-formes logicielles dont la validation par vérification de cohérence met en oeuvre les ressources sensorielles offertes par ce genre d'interfaces. Dans une variante de l'invention, la caractéristique sensorielle est une caractéristique visuelle, un assemblage de différents objets n'étant validé que si ledit assemblage forme un ensemble visuellement cohérent. Cette variante est particulièrement adaptée au type de matériel actuellement utilisé dans l'industrie de conception de logiciels, dans laquelle les interfaces graphiques homme-machine sont omniprésentes. L'utilisation d'objets graphiques pour représenter les interfaces d'entrée/sortie des applications à assembler entre elles présente ainsi pour avantage de ne pas nécessiter la mise en oeuvre de ressources autres que des ressources déjà existantes, ce qui implique que le procédé selon l'invention pourra être utilisé dans cette industrie sans occasionner de dépenses d'équipement supplémentaires. Dans un mode de mise en oeuvre particulier de l'invention, la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par une forme de son objet associé. En fonction de la complexité des interactions entre applications, et de la multiplicité éventuelle des interfaces desdites applications, les formes des objets pourront être à deux ou trois dimensions. Ainsi, des applications compatibles entre elles pourront-elles former des groupes de cubes, de parallélépipèdes, de sphères, d'ellipsoïdes, etc.... Dans une variante de ce mode de mise en oeuvre particulier de l'invention, la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par la forme d'au moins une portion d'un contour délimitant une surface dudit objet. Cette variante permet d'assembler deux à deux des applications compatibles entre elles, mais aussi par exemple une première et une deuxième application, dont les interfaces d'entrée/sortie sont individuellement incompatibles l'une avec l'autre, mais compatibles avec des interfaces d'entrée/sortie d'une troisième application, dont l'objet associé présentera un contour muni d'au moins deux portions distinctes, chacune compatible avec au moins une portion du contour de l'objet associé à l'une des première et deuxième applications. Ces compatibilités pourront être rendues manifestes par une complémentarité des formes desdites portions de contour, auquel cas la cohérence visuelle de l'assemblage des objets associés aux première, deuxième et troisième applications est rendue apparente par le fait que ledit assemblage produit un objet plein et homogène. Dans une autre variante de ce mode de mise en oeuvre particulier de l'invention, la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par un mode de remplissage spécifique d'une surface délimitée par un contour de son objet associé. Un mode de remplissage spécifique pourra consister en l'attribution d'une couleur ou d'un hachurage particuliers. L'assemblage d'objets représentatifs d'applications destinées à former partie d'une même plate-forme logicielle peut être réalisé de diverses manières. Selon un mode de mise en oeuvre préféré de l'invention, en ce qu'il permet d'utiliser des ressources mises à disposition par les interfaces graphiques dont l'omniprésence et ses avantages ont été explicités plus haut, l'étape d'assemblage est réalisée par sélection et déplacement sur un écran de chaque objet vers une position d'assemblage au moyen d'une opération du type"cliquer-glisser". Lorsqu'une compatibilité entre interfaces d'entrée/sortie de différentes applications destinées à coopérer au sein d'une même plate-forme logicielle aura été établie de manière simple grâce à l'invention, la plate-forme logicielle résultante doit être effectivement générée, ce qui peut être réalisé par divers moyens. Dans un mode de mise en oeuvre particulièrement avantageux de l'invention, selon lequel un fichier contenant un programme exécutable est associé à chaque application, une validation d'un assemblage d'objets provoque une création d'un fichier associé à la plate-forme logicielle définie par ledit assemblage, lequel fichier contient une concaténation des programmes exécutables contenus dans chacun des fichiers associés aux applications associées aux objets formant partie dudit assemblage. L'invention concerne également, en tant que produit directement obtenu par sa mise en oeuvre, une plate-forme logicielle comprenant au moins deux applications, chacune munie d'une interface d'entrée/sortie et d'une fonctionnalité qui lui est propre, destinées à coopérer et assemblées au moyen d'un procédé tel que décrit plus haut. L'invention concerne en outre un dispositif de collecte et de traitement de données mettant en oeuvre une telle plate-forme logicielle. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : La Fig. 1 est un schéma fonctionnel qui représente un dispositif de collecte et de traitement de données permettant le contrôle d'une installation industrielle, La Fig. 2 est un schéma bloc qui représente une plate-forme logicielle incluse dans un tel dispositif, La Fig. 3 est une vue schématique d'une interface graphique permettant la mise en oeuvre d'un procédé de création d'une telle plate-forme logicielle conforme à l'invention, La Fig. 4 est un schéma de principe qui illustre les effets produits par la mise en oeuvre d'un tel procédé, La Fig. 5 est une vue schématique d'une interface graphique permettant la mise en oeuvre d'une variante de ce procédé de création d'une plate-forme logicielle, et La Fig. 6 est une vue schématique d'une interface graphique permettant la mise en oeuvre d'une autre variante de ce procédé de création d'une plate-forme logicielle. La Fig. 1 représente schématiquement un dispositif de collecte et de traitement de données DISP permettant, dans cet exemple, le contrôle d'un outil de production. Cet outil de production est destiné à transformer des produits d'entrée Pl, acheminés depuis un magasin MG vers une entrée d'une machine de traitement MT via un premier dispositif d'entraînement, ici un premier tapis roulant TRI, en des produits de sorties P2, acheminés depuis une sortie de la machine de traitement MT vers des moyens de conditionnement CM via un deuxième dispositif d'entraînement, ici un deuxième tapis roulant TR2. Un capteur SI opère une surveillance du fonctionnement du magasin MG. Un capteur S2 opère une surveillance du fonctionnement du premier tapis roulant TRI. Un capteur S3 opère une surveillance du fonctionnement de la machine de traitement MT, qui pourra par exemple être constituée par un four de cuisson ou une machine-outil. Un capteur S4 opère une surveillance du fonctionnement du deuxième tapis roulant TR2. Un capteur S5 opère une surveillance du fonctionnement des moyens de conditionnement CM. Les capteurs SI, S2... S5 sont destinés à communiquer, via une liaison câblée ou radio, avec un module de scrutation MS qui a pour fonction d'opérer une collecte centralisée de messages provenant des capteurs SI, S2... S5, et de retransmettre tout nouveau message vers une unité de compilation incluse dans un serveur SERV apte à communiquer par liaison câblée ou radio avec le module de scrutation MS. A cet effet, le serveur SERV héberge une plate-forme logicielle PLF destinée à piloter le module de scrutation MS pour en extraire en temps réel des messages d'information des capteurs SI, S2... S5, à compiler les informations contenues dans lesdits messages et à organiser un affichage des résultats d'une telle compilation, par exemple sur un écran ECR d'un poste de travail PT, dont une unité centrale UC pourra communiquer via une liaison réseau NETW avec ladite plate-forme logicielle PLF. Le dispositif de collecte et de traitement de données DISP permettra à un opérateur utilisant le poste de travail PT d'accéder en temps réel à toutes sortes d'informations relatives au fonctionnement de l'outil de production sus-décrit, comme par exemple un débit de sortie du magasin MG, un débit de transfert du tapis roulant TRI, des conditions de fonctionnement de la machine de traitement MT, comme sa température intérieure instantanée s'il s'agit d'un four de cuisson, etc. La Fig. 2 représente très schématiquement une plate-forme logicielle PLF mise en oeuvre dans un tel dispositif de collecte et de traitement de données, laquelle plateforme logicielle PLF inclut, dans l'exemple représenté ici, quatre applications distinctes et destinées à coopérer deux à deux, dont une application de scrutation SCRUT, destinée à contrôler la scrutation des capteurs opérée par le module de scrutation précédemment décrit, une application de collecte COLL destinée à contrôler la collecte de données opérée par le module de scrutation et le transfert desdites données vers une application de compilation COMP, qui est destinée à faire une synthèse desdites données en vue de leur affichage en un format intelligible sous contrôle d'une application d'affichage AFF. Cette plate-forme logicielle PLF sera avantageusement créée au moyen d'un procédé conforme à l'invention, qui permettra de ne pas avoir à examiner en détail des fichiers contenant sous forme codée des définitions d'interfaces d'entrée/sortie propres aux applications SCRUT, COLL, COMP ou AFF afin de s'assurer de leur compatibilité, qui est nécessaire à un bon fonctionnement de la plate-forme logicielle PLF puisque chaque interface d'entrée/sortie détermine le nombre et la nature des différentes données d'entrée et de sortie que chaque application correspondante est destinée à recevoir et à produire, ainsi qu'un format que devront revêtir lesdites données. La Fig. 3 représente une bibliothèque d'objets BIB qui contient des objets représentatifs de diverses applications pré-existantes, classées par types de fonctionnalité propres à ces applications. Une première catégorie contient des objets associés à des applications aptes à remplir les fonctions de l'application SCRUT. Une deuxième catégorie contient des objets associés à des applications aptes à remplir les fonctions de l'application COLL. Une troisième catégorie contient des objets associés à des applications aptes à remplir les fonctions de l'application COMP. Une quatrième catégorie contient des objets associés à des applications aptes à remplir les fonctions de l'application AFF. Les objets classés dans chaque catégorie présentent chacun une caractéristique visuelle représentative de l'interface de leur application associée, en l'occurrence une forme particulière, circulaire, triangulaire, elliptique, rectangulaire, etc. Afin de construire une plate-forme logicielle PLF telle celle décrite précédemment, des objets seront sélectionnés au sein de la bibliothèque BIB, puis assemblés, par exemple par sélection et déplacement sur un écran de chaque objet vers une position d'assemblage au moyen d'une opération du type"cliquer-glisser". Conformément à l'invention, un assemblage ne sera validé que s'il forme un ensemble visuellement cohérent. Dans l'exemple simplifié décrit ici, seule une sélection des objets Al, A2, A3 et A4 permet d'obtenir une telle cohérence visuelle, puisque ces quatre objets présentent tous une forme circulaire, contrairement aux autres objets de la bibliothèque BIB. Une telle cohérence visuelle témoigne d'une compatibilité des interfaces d'entrée/sortie des applications associées aux dits objets Al, A2, A3 et A4, ce qui assure que ces applications seront aptes à coopérer au sein de la plate-forme logicielle PLF. La Fig. 4 illustre des effets que pourra avantageusement produire une validation de l'assemblage décrit ci-dessus. Dans ce mode de mise en oeuvre particulier de l'invention, un fichier contenant un programme exécutable est associé à chaque application. Une validation VAL d'un assemblage d'objets Ai (pour i=l à 4) sélectionnés au sein de la bibliothèque provoque une création d'un fichier X (PLF) associé à la plate-forme logicielle PLF définie par ledit assemblage, lequel fichier contient une concaténation des programmes exécutables Xi (pour i==l à 4) contenus dans chacun des fichiers associés aux applications ainsi sélectionnées. La Fig. 5 représente une variante d'une bibliothèque d'objets BIB du type décrit plus haut, qui contient des objets présentant, en tant que caractéristique visuelle représentative de l'interface d'entrée/sortie de leur application associée, au moins une portion de contour spécifique. Cette variante permet d'assembler deux à deux des applications compatibles entre elles, par exemple celles associées aux objets Al et A2, mais aussi par exemple les applications associées aux objets A2 et A4, dont les interfaces d'entrée/sortie sont individuellement incompatibles l'une avec l'autre, mais compatibles avec des interfaces d'entrée/sortie d'une troisième application, dont l'objet associé A3 présentera un contour muni d'au moins deux portions distinctes, chacune compatible avec au moins une portion du contour de chaque objet A2 ou A4 associé à l'une des deux autres applications. Ces compatibilités sont ici signalées par une complémentarité des formes desdites portions de contour, c'est-à-dire que la cohérence visuelle de l'assemblage des objets Al, A2, A3 et A4 associés aux applications sélectionnées est manifestée par le fait que ledit assemblage produit un objet PLF plein et homogène. La Fig. 6 représente une autre variante d'une bibliothèque d'objets BIB du type décrit plus haut, qui contient des objets présentant, en tant que caractéristique visuelle représentative de l'interface de leur application associée, une surface ayant fait l'objet d'un remplissage spécifique. Ce remplissage pourra être effectué, par l'attribution d'une couleur particulière ou, comme c'est le cas ici, d'un hachurage particulier, auquel cas seront considérés comme cohérents entre eux des objets qui présenteront le même mode de hachurage. Dans le mode de mise en oeuvre de l'invention décrit par cette figure, différentes caractéristiques visuelles matérialisées par le contour et le mode de remplissage des objets de la bibliothèque BIB sont simultanément exploitées, ce qui autorise une plus grande variété de représentation des interfaces d'entrée/sortie des applications et de leurs éventuelles compatibilités ou incompatibilités. REVENDICATIONS 1) Procédé pour créer une plate-forme logicielle comprenant au moins deux applications destinées à coopérer, chacune munie d'une interface d'entrée/sortie et d'une fonctionnalité qui lui est propre, incluant une étape d'assemblage d'objets associés aux dites applications, et une étape de validation de l'assemblage ainsi obtenu, lesdits objets étant prélevés depuis une bibliothèque d'objets préalablement créée en recensant des applications pré-existantes et en associant à chacune de ces applications pré-existantes un objet présentant une caractéristique sensorielle représentative de l'interface de ladite application, un assemblage de différents objets n'étant validé que si ledit assemblage forme un ensemble sensoriellement cohérent. 2) Procédé selon la revendication 1, dans lequel la caractéristique sensorielle est une caractéristique visuelle, un assemblage de différents objets n'étant validé que si ledit assemblage forme un ensemble visuellement cohérent. 3) Procédé selon la revendication 2, dans lequel la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par une forme de son objet associé. 4) Procédé selon la revendication 3, dans lequel la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par la forme d'au moins une portion d'un contour délimitant une surface dudit objet. 5) Procédé selon la revendication 2, dans lequel la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par un mode de remplissage spécifique d'une surface délimitée par un contour de son objet associé. 6) Procédé selon la revendication 5, dans lequel la caractéristique visuelle représentative de l'interface de chaque application est matérialisée par la couleur de son objet associé. 7) Procédé selon la revendication 5, dans lequel le remplissage spécifique est matérialisé par un hachurage particulier. 8) Procédé selon l'une des revendications 1 à 7, dans lequel l'étape d'assemblage est réalisée par sélection et déplacement sur un écran de chaque objet vers une position d'assemblage au moyen d'une opération du type"cliquer-glisser". 9) Procédé selon l'une des revendications 1 à 8, dans lequel, un fichier contenant un programme exécutable étant associé à chaque application, une validation d'un assemblage d'objets provoque une création d'un fichier associé à la plate-forme logicielle définie par ledit assemblage, lequel fichier contient une concaténation des programmes exécutables contenus dans chacun des fichiers associés aux applications associées aux objets formant partie dudit assemblage. 10) Plate-forme logicielle comprenant au moins deux applications, chacune munie d'une interface d'entrée/sortie et d'une fonctionnalité qui lui est propre, destinées à coopérer et assemblées au moyen d'un procédé conforme à l'une des revendications 1 à 9. 11) Dispositif de collecte et de traitement de données mettant en oeuvre une plate-forme logicielle selon la revendication 10.