Vérification des patrons temporels d’utilisation d’API sans exécution du code : une approche et un outil
Bibliographic record
Abstract
La réutilisation est une pratique courante lors du développement de logiciel. Bien souvent, cette réutilisation se fait à travers l’utilisation des librairies. Cette dernière met ses fonctionnalités à disposition des développeurs en utilisant les Interfaces de Programmation d’Application (API). En théorie, les développeurs qui utilisent les API n’ont pas forcément besoin de se préoccuper de comment les éléments internes de cette API fonctionnent. En effet, les API mettent leurs fonctionnalités à disposition des développeurs sans forcément dévoiler ce qui se passe à l’interne. Cependant, pour utiliser correctement une API il est nécessaire de respecter des contraintes d’utilisation qui sont à la fois implicites et explicites ainsi que des modèles d’utilisation. L’usage des librairies et des API est très commun dans le domaine du développement de logiciel. Cela permet aux développeurs d’utiliser les fonctionnalités proposées par l’API et ainsi de se concentrer directement sur la tâche qu’ils doivent effectuer. Toutefois, apprendre et se familiariser avec les contraintes d’usage des API sont des tâches ardues et exigent un effort cognitif considérable de la part du développeur. Les chercheurs ont tenté de corriger ce problème en étudiant les modèles d’utilisation et en analysant les traces d’utilisation de code client pour s’assurer de leurs conformités. Néanmoins, les analyses dynamiques ne sont pas possibles pendant les phases précoces de développement du logiciel, car cela requiert une implémentation minimum et l’exécution du code. Nous proposons l’outil Temporal Usage PAttern Checker (Tupac). Une approche basée sur l’analyse statique interprocédural pour vérifier la conformité du code client aux modèles d’utilisation pendant la phase de développement. Tupac peut être déployé dans un envi- ronnement de développement (IDE) et ainsi fournir des informations relatives à l’utilisation des API plus tôt pendant la phase de développement du logiciel. Nous avons évalué notre approche sur quatre projets Java avec quatre API. Les résultats ont démontré que Tupac a une bonne précision et un taux de rappel intéressant. De plus, nous avons pu conclure qu’en moyenne cela prend une demi-seconde pour vérifier la confor- mité d’un patron pour un projet tout entier. Cela démontre que Tupac peut être déployé dans un rythme de codage régulier.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.009 | 0.034 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.003 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.001 | 0.003 |
| Scholarly communication | 0.006 | 0.006 |
| Open science | 0.004 | 0.004 |
| Research integrity | 0.003 | 0.003 |
| Insufficient payload (model declined to judge) | 0.008 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".