Intégration d'un modèle d'adaptation dynamique et de sécurité d'objets avec vue
Bibliographic record
Abstract
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.
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.002 | 0.004 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.005 | 0.005 |
| Open science | 0.002 | 0.004 |
| Research integrity | 0.002 | 0.003 |
| Insufficient payload (model declined to judge) | 0.014 | 0.006 |
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".