FR3115902A1

FR3115902A1 - Procédé de vérification de compatibilité des interfaces d’un applicatif logiciel

Info

Publication number: FR3115902A1
Application number: FR2011288A
Authority: FR
Inventors: Roman MORYC; Nicolas Romea
Original assignee: Vitesco Technologies
Current assignee: Vitesco Technologies
Priority date: 2020-11-04
Filing date: 2020-11-04
Publication date: 2022-05-06

Abstract

Procédé de vérification de compatibilité des interfaces d’un applicatif logiciel, comprenant les étapes suivantes :- compilation des fichiers sources pour produire des fichiers objets,- modification, dans les fichiers objets, des noms des objets logiciels, pour leur adjoindre un numéro de version,- édition des liens. Figure d’abrégé : Figure 2

Description

Procédé de vérification de compatibilité des interfaces d’un applicatif logiciel

L’invention concerne le domaine de la production d’applicatif logiciel et plus particulièrement un procédé de vérification de la cohérence des interfaces lors d’une telle production.

Il est connu pour produire un applicatif logiciel d’utiliser un langage de programmation, tel C ou C++. A l’aide de ce langage, l’applicatif logiciel est écrit dans un ou plusieurs fichiers sources, intelligibles pour un être humain. Au moyen d’un convertisseur nommé compilateur, spécifique du langage de programmation, chaque tel fichier source est converti en un fichier objet, apte à être exécuté par un processeur. Ensuite une édition de liens est réalisée au moyen d’un éditeur de lien ou « linker » qui permet de relier les différents fichiers objets en un unique applicatif logiciel, ou fichier exécutable.

Selon l’invention, il est ajouté une étape dans laquelle chaque objet logiciel, que ce soit une donnée ou une routine (fonction ou procédure) est documenté en lui adjoignant une version. Cette version est ajoutée dans la distribution logicielle en remplaçant le nom de chaque objet logiciel « X » par un nom et une version accolée.

L’invention a pour objet un procédé de vérification de compatibilité des interfaces d’un applicatif logiciel, comprenant les étapes suivantes :
- compilation des fichiers sources pour produire des fichiers objets,
- modification, dans les fichiers objets, des noms des objets logiciels, pour leur adjoindre un numéro de version,
- édition des liens.

Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison, sont :
- la modification des noms des objets logiciels, remplace un nom « X » par le même nom accolé d’un symbole de version « _V » et d’un numéro « n » de version, soit « X_Vn »,
- la modification des noms des objets logiciels est réalisée au moyen d’un outil de patch des fichiers objets, tel OBJCOPY,
- la modification des noms des objets logiciels est réalisée au moyen d’un fichier de commande.

L’invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d’exemple, et en référence aux figures en annexe dans lesquelles :

illustre un procédé de production d’un applicatif logiciel selon l’art antérieur,

illustre un procédé de production d’un applicatif logiciel modifié par l’invention,

illustre un problème d’interface non détecté selon l’art antérieur,

illustre la détection du problème d’interface par l’invention,

En référence à la , un logiciel applicatif se construit en connectant des modules logiciels entre eux. Un applicatif logiciel est compris dans n fichiers sources, ici numéroté de 1..n. La compilation produit autant de fichiers objets. Les modules d'un logiciel applicatif sont très souvent des modules génériques, développés dans I’optique de favoriser leur réutilisation sur de nombreux projets afin de limiter les coûts de développement des projets tout en garantissant un meilleur niveau de qualité et de robustesse.

Chaque module possède des interfaces d'entrée (interfaces produites par d'autres modules) et des interfaces de sorties (interfaces produites par ce module pour être utilisée par d'autres modules) lui permettant de communiquer avec les autres modules.

Deux méthodes de communication existent :
- Méthode de type < control-flow )): un module appelle une fonction d'un autre module. Une interface de type < control-flow >> est implémentée en définissant une fonction pouvant être appelée depuis plusieurs modules,
- Méthode de type < data-flow> : un module lit une donnée écrite par un autre module. Une interface de type < data-flow > est implémentée en définissant une donnée en mémoire globale partagée pouvant être lue et écrite par plusieurs modules.

Les développements de modules génériques sont effectués au sein de plates-formes logicielles définissant les interfaces standards ce qui facilite l'intégration des modules. Les interfaces sont généralement définies de manière centralisée, dans une base de données, telle qu’illustrée à la ou 4, dans laquelle chaque interface est décrite. Par exemple, une donnée possède un nom, un type et une unité.

Selon une caractéristique de l’invention, les interfaces sont versionnées afin de gérer les changements : à chaque modification d’une interface, sa version est modifiée.

A titre d’exemple, un objet tension batterie est présenté. Un tel objet logiciel, nommé VB est une sortie du module qui gère la tension batterie. Il constitue alors une entrée pour tous les modules qui lisent et/ou utilisent la tension batterie.

Il convient que l’interface d’un tel objet VB soit clairement définie de la même manière pour l’objet qui produit cette valeur et la met à disposition et pour tous les utilisateurs.

On suppose qu’une première version de l’interface de l’objet VB est de type linéaire 8-bit non-signé [0..25,8V] en Volt. Suite à une évolution, une deuxième version de l’interface de l’objet VB est définie de type linéaire 8-bit non-signé [0...28,8V] en Volt. Il peut être vu qu’une différence d’interface peut ici avoir des conséquences importantes. En effet si la valeur 0 correspond dans les deux versions à une valeur 0V, la valeur FF correspond à 25,8V pour la version 1 et à 28,8V pour la version 2, avec des variations plus ou moins sensibles pour toutes les autres valeurs. Aussi, il est de première importance qu’un module utilisateur de l’objet tension batterie VB utilise bien la version d’interface à laquelle il s’attend.

Selon l’art antérieur illustré à la , tous les objets tension batterie VB, portent le même nom VB et ne peuvent être distingués. Aussi, tel qu’illustré à la , qu’il s’agisse d’un VB de version 1 ou de version 2, l’éditeur de liens voit un seul et même nom VB dans les deux cas. Il n’est pas en mesure de détecter une incohérence d’interface.

Aussi, selon une étape importante de l’invention, plus particulièrement visible à la , il est ajouté une étape de documentation, en introduisant les numéros de version dans les fichiers objets. Pour cela, chaque fichier objet est modifié ou « patché ». Chaque fichier objet est remplacé par un fichier objet « patché » dans lequel tous les noms de tous les objets logiciels sont modifiés. Cette modification permet d’introduire une version associée à chaque objet logiciel. Tous les noms étant modifiés, la modification s’applique tant à un nom utilisé comme producteur que au même nom utilisé comme consommateur. Ceci permet alors de réaliser une vérification des versions des interfaces lors de l’édition de lien ultérieure.

C’est l’éditeur de liens, lors de sa tâche d’assemblage qui comporte une vérification de la cohérence des noms des objets logiciels qui réalise la vérification de cohérence des interfaces.

Ainsi, tel qu’illustré à la , l’objet tension batterie VB selon la version 1 est patché en VB_V1, tandis que l’objet tension batterie VB selon la version 2 est patché en VB_V2. Aussi, il apparaît deux noms différents, puisque correspondant à deux versions d’interfaces, et l’éditeur de liens est en mesure de détecter un problème de différence d’interface.

Aussi, le procédé de vérification de compatibilité des interfaces d’un applicatif logiciel, comprend les étapes suivantes :
- compilation des fichiers sources pour produire des fichiers objets,
- modification, dans les fichiers objets, des noms des objets logiciels, pour leur adjoindre un numéro de version,
- édition des liens.

Du fait du changement de nom, qui permet de renseigner la version de l’interface, de l’information est introduite dans les fichiers objets. Cette information supplémentaire permet à l’éditeur de liens de vérifier que deux objets logiciels liés présentent bien les bonnes interfaces pour que ce lien soit possible.

Selon une autre caractéristique, la modification des noms des objets logiciels, remplace un nom « X » par le même nom accolé d’un symbole de version. Le symbole de version peut être quelconque et par exemple « _V ». Ensuite, un numéro « n » de version peut encore être accolé. Le choix, et l’ordre des différents symboles retenus peuvent être variables. Selon un mode de réalisation, un objet « X » est renommé « X_Vn », avec n le numéro de version.

Selon une autre caractéristique, la modification des noms des objets logiciels ou « patch » est réalisée au moyen d’un outil de patch des fichiers objets. Un tel outil de patch existe généralement dans une distribution de développement logiciel.

Ce type d’outil est habituellement utilisé pour patcher des symboles dans un code objet dont le code source n’est pas disponible afin de résoudre des problèmes de conflit de nommage des données. Ainsi, par exemple, lorsque les codes objets de deux modules utilisent un même nom pour des données différentes, il faut alors pouvoir renommer le symbole de la donnée dans l’un au moins des modules afin d’éviter un conflit de nommage lors de l’édition de liens. Un tel outil est nommé OBJCOPY dans une distribution C.

L’outil de patch peut être utilisé à la main, objet logiciel par objet logiciel. Cependant pour un logiciel d’une certaine taille le procédé devient vite fastidieux et cause d’erreur. Aussi selon une autre caractéristique, un fichier de commande ou script permettant d’automatiser cette tâche est employé. Aussi, la modification des noms des objets logiciels est avantageusement réalisée au moyen d’un fichier de commande.

L’invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d’exemple et non comme limitant l’invention à cette seule description. De nombreuses variantes de réalisation sont possibles.

Claims

Procédé de vérification de compatibilité des interfaces d’un applicatif logiciel, caractérisé en ce qu’il comprend les étapes suivantes :
- compilation des fichiers sources pour produire des fichiers objets,
- modification, dans les fichiers objets, des noms des objets logiciels, pour leur adjoindre un numéro de version,
- édition des liens.
Procédé selon la revendication 1, où la modification des noms des objets logiciels, remplace un nom « X » par le même nom accolé d’un symbole de version « _V » et d’un numéro « n » de version, soit « X_Vn ».
Procédé selon l’une quelconque des revendications 1 à 2, où la modification des noms des objets logiciels est réalisée au moyen d’un outil de patch des fichiers objets, tel OBJCOPY.
Procédé selon l’une quelconque des revendications 1 à 2, où la modification des noms des objets logiciels est réalisée au moyen d’un fichier de commande.