Identification et localisation des preoccupations fonctionnelles dans du code legataire java
Notice bibliographique
Résumé
Object oriented applications integrate various functional aspects. These aspects can be scattered everywhere in the code. There are various types of aspects: • aspects which represent business functionalities; • aspects related to non functional requirements or to design concerns such as robustness, distribution, and security. The code representing such aspects can be located in different class hierarchies. Researchers have been interested in the problem of the modularisation of these aspects and many approaches were proposed: oriented programming subjects, oriented programming Aspects and oriented programming view. These approaches offer techniques and tools for designing object oriented applications based on the composition of slices of various aspects. The main benefit of the separation of aspects is supporting reuse and maintenance. Consequently, it is well worth identifying and extracting aspects of legacy object oriented applications. Our work mainly focuses on functional aspects. Assuming that the code of a functional aspect or a feature has a functional cohesion (dependencies between elements), we suggest methods for identifying such features from the code. The idea is to identify, in the absence of any aspect oriented paradigm, the techniques used for implementing a feature in the code. Our approach consists of: identifying techniques used by developers to integrate a feature in the absence of aspect oriented techniques; • characterizing the patterns of these techniques; • and developing tools to identify these patterns. We present two approaches for the identification of the existing features in the object oriented code. The first one identifies various design patterns which integrates these features in the code. The second approach uses the formal concept analysis to identify the recurring features in the code. We experiment our approaches to identify functional features in different open source object oriented applications. The results show the efficiency of our approaches in identifying various functional features in the legacy object oriented, and can some times suggest refactoring. Keywords: Features, reengineerings, legacy object oriented code, refactoring, Galois lattices, Java.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,013 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,003 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,002 |
| Communication savante | 0,004 | 0,003 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,002 | 0,002 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,002 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».