Migration d'interfaces de programmation

La migration d'interfaces de programmation (en anglais : Application Programming Interface - API) est une technique consistant à transformer le code d'une interface de programmation en une autre. Les raisons à cela peuvent être multiples : obsolescence d'interface de programmation, volonté de convertir le code d'un langage vers un autre, etc.

Jusqu'à récemment^[Quand ?], les développeurs étaient obligés d'effectuer cette tâche à la main. Néanmoins, des outils sont créés depuis peu^{[Depuis quand ?]} pour effectuer cela de manière automatique.

L'extraction de correspondance entre interfaces de programmation (en anglais : Mining API Mapping - MAM) est une technique pour trouver et effectuer automatiquement la correspondance entre interfaces de programmation de deux langages différents^[1].

Cette technique se base sur l'usage de le l'interface de programmation plutôt que sur son implémentation, et cela pour 3 raisons :

• Les interfaces de programmation sont souvent livrées sans leur code source.
• Les relations trouvées basées sur l'implémentation sont souvent moins précises que les relations basées sur l'usage des interfaces de programmation.
• La correspondance des relations des interfaces de programmation est souvent complexe et ne peut pas être construite à partir des informations disponibles sur l'implémentation des interface de programmation.

Ainsi, cette technique construit les relations entre deux interfaces de programmation de différents langages. Ces relations prennent la forme d'un graphe de transformation d'interface d'API (en anglais : API Transformation Graph - ATG) qui permet de faire la transformation voulue.

Cette technique fonctionne d'une interface de programmation en langage Java vers une interface de programmation en langage C#.

La première étape pour effectuer la transformation est de trouver des classes similaires par leur nom. L'extraction de correspondance entre interfaces de programmation se sert également des noms de paquets pour être plus précis dans la recherche.

Pour chaque classe des deux interfaces de programmation, cette technique essaie de créer les couples selon la formule suivante:

∀ c1 et c2 représentant des classes, ∃  un couple {c1, c2} si similarité{c1.nom, c2.nom} > SIM_THRESHOLD

SIM_THRESHOLD représente un seuil déterminé de manière astucieuse par l'algorithme.

Par la suite, pour chaque couple trouvé, l'algorithme essaie de trouver des attributs et des fonctions formant des couples selon les formules suivantes :

∀ a1 et a2 représentant des attributs, ∃  un couple {a1, a2} si similarité{a1.nom, a2.nom} > SIM_THRESHOLD

∀ f1 et f2 représentant des fonctions, ∃  un couple {f1, f2} si similarité{f1.nom, f2.nom} > SIM_THRESHOLD

Enfin, pour chaque fonction trouvée, l'algorithme essaie de trouver des variables locales et des paramètres formant des couples selon les formules suivantes :

∀ v1 et v2 représentant des variables locales, ∃  un couple {v1, v2} si similarité{v1.nom, v2.nom} > SIM_THRESHOLD

∀ p1 et p2 représentant des paramètres, ∃  un couple {p1, p2} si similarité{p1.nom, p2.nom} > SIM_THRESHOLD

Par exemple, cette technique forme un couple entre IndexFiles de Java et IndexFiles de C# puisque leur nom sont très similaires.

Par la suite, l'algorithme construit un graphe de transformation d'interfaces de programmation (en Anglais : API Transformation Graph - ATG) pour chaque méthode. Ce type de graphe décrit les entrées, sorties, noms des méthodes et dépendances entre les données des interfaces de programmation et aide à comparer les méthodes de plusieurs manières.

Ainsi, un graphe de transformation d'interface de programmation pour une méthode m est un graphe orienté G{N_data, N_m, E} :

• N_data est un ensemble des champs de la classe dans laquelle se trouve m, des variables et des paramètres de m.
• N_m est l'ensemble de toutes les méthodes appelé par m.
• E est un ensemble d'arcs qui représente les dépendances entre données, et entre appels de méthodes et valeurs de retours.

La construction de ces graphe et leur amélioration via les résultats des autres graphes précédemment construits permet de trouver la correspondance à appliquer entre les deux interfaces de programmation.

L'implémentation d'un outil, nommé Java2CSharp, a permis de conduire des premières évaluations sur cette nouvelle technique.

Le tableau ci-dessous présente les résultats d'évaluation. Il montre le nombre de classes et méthodes correctement transformées et la proportion correspondante.

Résultats de la transformation d'API

Projet	Classe		Méthode
	Nombre	Précision	Nombre	Précision
db4o	3155	83,3 %	10787	90,0 %
lucene	718	90,0 %	2725	90,0 %
logging	305	73,3 %	56	90,0 %

Ces résultats montrent une très grande précision de transformation grâce à cet outil.

Le jumelage^[2] (en anglais : twinning) est une méthode de migration d'interfaces de programmation qui oblige tout d'abord à décrire manuellement les correspondances entre deux interfaces de programmation A et B.

[ Enumeration (Vector v) { return v.elements(); }
  Iterator (ArrayList a) { return a.iterator(); } ]

Cette technique permet par la suite de faire 2 transformations :

• La première transformation est appelée l'adaptation superficielle (en anglais : shallow adaptation). Elle prend en entrée un programme P utilisant une interface de programmation A et une correspondance entre les interfaces de programmation A et B. Elle génère ainsi une variante du programme passé en entrée nommée P' qui utilise désormais l'interface de programmation B.

• La seconde transformation se nomme l'adaptation profonde (en anglais : deep adaptation). Elle prend également en entrée un programme P et une correspondance entre les deux interfaces de programmation A et B. Elle génère une interface I et un nouveau programme P' qui permet d'utiliser via l'interface I soit l'ancienne interface de programmation A, soit la nouvelle B.

L'adaptation superficielle génère un programme P' à partir d'un programme P et d'une correspondance entre les deux interfaces de programmation.

Cette transformation parcours l'arbre de syntaxe abstraite du programme et applique les changements spécifiés dans la correspondance entre les interfaces de programmation. Par exemple, avec la correspondances précédemment présentée, le code Enumeration elements = objects.elements(); devient Iterator elements = objects.iterator();

Cette technique fonctionne de manière séquentielle, c'est-à-dire qu'elle effectue les transformations par bloc. Les blocs peuvent représenter une ligne ou une suite de lignes délimitée par de accolades

L'adaptation profonde génère, à partir d'un programme P et d'une correspondance M d'une interface de programmation A vers une interface de programmation B les éléments suivants :

• T : une interface de programmation contenant un ensemble de classes abstraites et d'interfaces dont le but est d'abstraire les différences contenu dans la correspondance M.
• P' : une variante de P qui appelle l'interface de programmation T à tous les endroits où P contient du code du domaine de M.
• I₁, I₂ : implémentations de l'interface de programmation T. I₁ représente l'interface de programmation A utilisée dans le code de P et I₂ représente la nouvelle interface B voulue grâce à la correspondance M.

Cela a pour avantage de pouvoir utiliser n'importe laquelle des implémentations dans P', puisque l'implémentation utilisée peut être changée très facilement.

L'algorithme calcule tout d'abord l'ensemble des appels aux constructeurs et méthodes devant être remplacés. Ce nouvel ensemble ainsi calculé représente les constructeurs et méthodes devant figurer dans la nouvelle interface de programmation T.

L'algorithme de génération des implémentations EmitImpl(n, M) se sert de l'ensemble précédemment calculé. Il utilise un nombre n faisant office de sélecteur. Il permet par la suite de faire des traitements comme sel1(T, T') = T et sel2(T, T') = T'. Ainsi EmitImpl(1, M) génère l'implémentation de T en utilisant A et EmitImpl(2, M) génère l'ensemble d'implémentation en utilisant B.

La tâche suivante est de générer M' qui spécifie les correspondances entre l'interface de programmation initialement utilisée A et l'interface de programmation T permettant d'utiliser l'une des deux implémentations.

Enfin, il suffit de générer P' en laçant l'algorithme d'adaptation superficielle avec P et M'.

La création d'un prototype a permis de tester jumelage. Le prototype a été écrit en environ 2 500 lignes de code et se présente sous la forme d'une extension du framework de translation de code Cornell Polygot. Il a permis de mener 2 expériences :

• Adapter un ensemble de petits programmes utilisant l'analyseur XML Crimson pour leur faire utiliser l'interface de programmation Dom4J à la place.
• Transformer un code client Twitter pour utiliser l'interface de programmation Facebook à la place.

Le prototype permettait une approche interactive pour définir les correspondances :

• Identification d'un bloc de code devant être transformé.
• Ecriture des correspondances associées.
• Application des correspondances aux programmes.
• Tentative de compilation du programme obtenu.
• Récupération des erreurs de type pour identifier le prochain bloc de code à transformer.

L'approche statistique orientée données (en anglais : data-driven statistic approach), qui apprend statistiquement la correspondance entre les utilisations d'interfaces de programmation. Cela est fait depuis le corps des méthodes dans le code client des interfaces de programmation^[3].

Pour chacune des méthodes de l'interface de programmation, l'approche statistique construit un graphe qui permet d'extraire les dépendances entre données et structures de contrôle.

L'analyse de ce graphe permet d'aligner les méthodes et ainsi de trouver les correspondances entre l'interface de programmation.

Pour chacune des méthodes de l'interface de programmation devant être remplacée par une autre, l'algorithme construit une représentation sous forme de graphe de l'utilisation de l'interface de programmation.

Les nœuds représentent les appels de fonctions, accès aux attributs et les structures de contrôle. Les arcs représentent les dépendances de données et de contrôle entre les nœuds.

L'approche statistique orientée données extrait depuis le graphe précédant le sous graphe représentant les interactions de l'interface de programmation avec un ou plusieurs objets. Pour chacun de ces sous-graphes, l'algorithme extrait les noms des nœuds pour construire une séquence de symbole. Chacun de ces symboles est appelé un symbole d'usage.

Ensuite, les séquences de symbole de tous les sous groupes précédemment formés sont rassemblées pour former une séquence pour l'ensemble de la méthode. Une telle séquence est appelée une phrase.

Chacune des paires de phrases des méthodes correspondances en Java et C# sont alignées selon leurs symboles grâce à l'algorithme de maximisation d'attente^[4]. Les séquences alignées avec un score plus grand qu'un seuil donné représentent les correspondances entre interfaces de programmation.

Le développement d'un outil, nommé StaMiner, basé sur l'algorithme d'approche statistique orienté données a permis de mener des expériences et de comparer cet outil à d'autres. L'ensemble des librairies testées est similaires à celles testées dans la première partie (Extraction de correspondance entre interfaces de programmation).

L'évaluation ainsi menée a permis de montrer que StaMiner a correctement effectuer les transformations dans 87,1 % des cas. Comparé à Java2CSharp, StaMiner a transformé le code avec 4,2 % d'erreurs de compilation en moins et 6 % de code défectueux en moins.

Le principal avantage de cet algorithme par rapport à l'extraction de correspondances entre interfaces de programmation repose sur l'analyse du contenu des méthodes client. En effet, l'extraction de correspondances permet uniquement de détecter une similitude entre noms. Au contraire, l'approche statistique orienté données permet de détecter l'enchainement des dépendances entre données, appels de méthodes. Cela résulte en une plus grande compréhension du code client, et ainsi en une meilleure transformation.

La transformation d'eau est une technique permettant la migration de cadre logiciel (en anglais : framework) web.Les cadres logiciels web ont pour particularité d’entremêler plusieurs langages, notamment le HTML et le code interprété par le serveur^[5]. Cette technique n'est pas utile pour la migration des technologies n'utilisant que du code serveur (comme migrer une servlet JavaEE) qui peuvent être migrées via des techniques non spécifiques aux langages web.

Cette technique de migration répond à deux contraintes :

• conserver l'emplacement exact du code HTML afin de ne pas dégrader l'interface utilisateur ;
• conserver les commentaires au même emplacement pour s'assurer que le code produit est maintenable.

Cette technique est une extension des grammaires d'îles qui consistent à extraire le code défini comme étant intéressant - les îles - du reste du code - l'eau.
La migration d'un framework web avec la transformation d'eau peut être décomposée en quatre étapes principales :

• suppression des balises HTML et les commentaires ;
• traduction du langage source vers le langage cible ;
• remplacement des interfaces de programmation du langage source vers les interfaces correspondantes dans le langage cible ;
• réinsertion du code HTML et des commentaires supprimés lors de la première étape.

Les étapes deux et trois sont effectuées via l'une des nombreuses méthodes existantes dans la littérature scientifique.

Une grammaire d'île est une grammaire qui contient deux types de production :

• Des productions qui décrivent des constructions d’intérêt : les îles.
• Des productions ouvertes qui peuvent contenir toutes les sections inintéressantes restantes.

Formellement , on peut les définir comme suit :
Soit L G {\displaystyle L_{G}} un langage non contextuel , G {\displaystyle G} une grammaire non contextuelle tel que L ( G ) = L G {\displaystyle L(G)=L_{G}} et G = ( V , Σ , S , P ) {\displaystyle G=(V,\Sigma ,S,P)} , où :

• V {\displaystyle V} et Σ {\displaystyle \Sigma } sont des ensembles finis avec V ∩ Σ = ∅ {\displaystyle V\cap \Sigma =\emptyset }  ; V {\displaystyle V} est un ensemble de variables ou de symboles non terminaux et Σ {\displaystyle \Sigma } l'alphabet de symboles terminaux,
• S ∈ V {\displaystyle S\in V} le symbole de départ,
• P {\displaystyle P} est un ensemble fini de productions ou de règle de grammaire de la forme A → α {\displaystyle A\rightarrow \alpha } où A ∈ V {\displaystyle A\in V} et α ∈ ( V ∪ Σ ) ∗ {\displaystyle \alpha \in (V\cup \Sigma )*} .

Nous pouvons définir une grammaire d'île G 1 = ( V 1 , Σ 1 , S 1 , P 1 ) {\displaystyle G1=(V_{1},\Sigma _{1},S_{1},P_{1})} pour un ensemble de structures d’intérêt I ⊂ Σ ∗ {\displaystyle I\subset \Sigma *} tel que i ∈ I , S ⇒ ∗ s 1 i s 2 ∈ L G {\displaystyle i\in I,S\Rightarrow *s_{1}is_{2}\in L_{G}} .

Cette définition assure que la grammaire d'île est plus souple que la grammaire d'origine i.e. L ( G ) ⊂ L ( G 1 ) {\displaystyle L(G)\subset L(G1)} . Donc G 1 {\displaystyle G1} peut analyser correctement un texte qui n'est pas valide selon G {\displaystyle G} .

La migration d'un cadre logiciel web par transformation d'eau contient 4 étapes.

• Définition du langage d'île comme étant le langage interprété par le serveur
• Application des transformations d'eau qui transforme l'eau en îles, c'est-à-dire rendre valide le code n'étant pas du code serveur dans la syntaxe du code serveur. Le résultat est un fichier valide écrit dans le langage serveur.
• Transformation du code vers le langage cible via n'importe quel algorithme de migration d'interface de programmation.
• Remise à l'eau des îles, c'est-à-dire l'opération inverse de la transformation d'eau.

Formellement , on peut définir une transformation d'eau comme suit :
Soit T W {\displaystyle T_{W}} la transformation qui cartographie chaque ensemble de jetons consécutifs ( s i ) ∗ {\displaystyle (s_{i})*} du fichier d'entrée à A j {\displaystyle A_{j}} le langage d'île , où :

• ∀ i , ( s i ) ∗ ⊈ L ( G 1 ) {\displaystyle \forall i,(s_{i})*\nsubseteq L(G_{1})}
• ∀ j , A j ⊂ L ( G 1 ) {\displaystyle \forall j,A_{j}\subset L(G_{1})} et j ∈ 1 , . . . , n {\displaystyle j\in {1,...,n}} , où n {\displaystyle n} est le nombre de flux indépendants consécutifs de jetons ( s i ) ∗ {\displaystyle (s_{i})*} du fichier d'entrée.

Plus simplement, chaque élément qui n'est pas valide dans le langage d'îles ( s i ) ∗ ⊈ L ( G 1 ) {\displaystyle (s_{i})*\nsubseteq L(G_{1})} est transformé à A j {\displaystyle A_{j}} , qui est valide dans le langage d'île.

• Portail de la programmation informatique