Intégration d'un modèle d'adaptation dynamique et de sécurité d'objets avec vue
Notice bibliographique
Résumé
La programmation orientée objet est une solution idéale pour une multitude de problèmes depuis plus de deux décennies. Des langages tels que le C++ et le Java ont largement contribué à l'expansion. Ce succès repose en partie sur une raison toute simple : il est plus naturel d'utiliser des objets qui se rapprochent de la réalité « humaine » que de travailler avec des fonctions séquentielles généralement associées à des processus informatiques. Il est relativement aisé d'identifier les caractéristiques et les comportements d'un objet et toute bonne analyse permet de gérer adéquatement les interrelations entre les objets dans un système. \n \nToutefois, on limite parfois notre réflexion à un stade d'abstraction insuffisant pour aller chercher un maximum d'avantages des objets. Les objets sont correctement développés, dans un système répondant à un nombre fini d'événements, mais on néglige le fait que ce même système est en contact avec un élément chaotique et imprévisible, l'humain. \n \nPrenons exemples des comportements dynamiques entre les objets, des divers patrons de conception déjà avancés, mais surtout de la question des comportements de ces objets (ayant des comportements figés) face aux besoins réels d'un utilisateur en constant changement. Après un certain temps, un système informatique peut évoluer dans ses comportements et ses rôles. De nouvelles fonctionnalités sont, à travers son cycle de vie, ajoutées, supprimées ou deviennent tout simplement non disponibles. Aussi, chacun des acteurs du système, autant les clients humains que les systèmes informatiques externes, a des besoins variables qui peuvent exiger un changement de vocation du système utilisé. Ce dernier doit être évolutif pour y répondre. À une échelle d'entreprise, on peut dire que plusieurs clients observent et utilisent des aspects distincts du même objet. Que faire si cet objet ne peut satisfaire aux différents intérêts du client? \n \nLa programmation par vue a pour mission de répondre à cette situation. Elle permet à différents usagers de percevoir et utiliser différents sous-ensembles des fonctionnalités présentes au sein de l'objet a un moment donné. Le client a un besoin un jour, la programmation par vue lui propose une interface adaptée, son besoin change le lendemain, les vues évoluent en conséquence. \n \nLa programmation par vue existe depuis quelques années, mais certains questionnements étaient demeurés sans réponse. Le sujet du présent mémoire sera de fournir quelques-unes des réponses à une série de problématiques entourant principalement i) la sécurisation de l'objet partagé selon les privilèges de chaque programme client, ii) la transparence et la gestion de changement de comportements de l'objet en question, et iii) l'intégration de mécanismes de partage des ressources. \n \nNous avons étendu le modèle de sécurité de Java afin de pouvoir gérer l'évolution des comportements. Java propose un modèle d'utilisation simple demandant une configuration minimale. Notre solution vise à garder une approche le plus transparente possible pour le client et aussi pour la classe de base (le système) que l'on désire faire évoluer. \n \nNotre recherche abordera la programmation par vue avec extension de sécurité à l'aide d'énoncés de problématiques. Le développement de notre outil sera accompli via une solution conceptuelle en UML et une implementation en 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,004 |
| Méta-épidémiologie (sens strict) | 0,002 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,002 |
| Bibliométrie | 0,001 | 0,001 |
| Études des sciences et des technologies | 0,001 | 0,002 |
| Communication savante | 0,005 | 0,005 |
| Science ouverte | 0,002 | 0,004 |
| Intégrité de la recherche | 0,002 | 0,003 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,014 | 0,006 |
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 ».