Dependability-oriented model-driven requirements engineering for reactive systems
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
Lorsque l'on développe des systèmes fiables, les erreurs ou oublis qui pourraient éventuellement se glisser dans la spécification du système peuvent avoir des conséquences néfastes, et pas seulement du point de vue monétaire. Il est par conséquent impératif de découvrir et d'analyser toute situation anormale ou comportement irrégulier d'un utilisateur du système qui pourrait interrompre le fonctionnement et les interactions habituelles du système. Une telle exception, qui n'aurait pas été découverte pendant la phase d'analyse des besoins, produirait une spécification de l'application à développer contenant des lacunes, ce qui, à la fin, causerait une implémentation de l'application à laquelle il manquerait des fonctionnalitées, ou qui se comporterait d'une manière peu fiable. Cette thèse présente un processus de développement orienté modèle qui mène le développeur à prêter une attention particulière à la sûreté et à la fiabilité du système en développement. Notre approche, nommée DREP, est constituée de cinq phases: la découverte des besoins, la spécification des besoins, l'évaluation de la fiabilité, le raffinement, et le résumé des besoins. Notre phase de découverte des besoins se base sur les cas d'utilisation. Elle mène le développeur à considérer des situations exceptionnelles qui pourraient surgir dans l'environnement et changer les buts des utilisateurs du système. Le développeur est également poussé à réfléchir aux situations qui pourrait empêcher le système de fournir un service avec succès. Dans ces cas, DREP demande au développeur de spécifier les démarches à suivre pour traiter cette situation, si possible en continuant à fournir le service demandé, ou à défaut, en fournissant un service diminué, ou simplement en s'assurent que le système s'arrête sans causer de dommage. DREP intègre également la notion de modes exceptionnels d'opération du système. DREP propose des extensions au diagrammes d'activités et de communication d'UML pour permettre au développeur d'exprimer la fiabilité dans les modèles de spécification du système. Une extension des diagrammes d'états intégrant les probabilités permet de modéliser les pannes qui pourraient surgir dans l'environnement. Un outil d'analyse permet ensuite de déterminer la sûreté et la fiabilité atteignable du système. On démontre que notre approche génère des spécifications de systèmes plus fiables avec trois cas d'études: un contrôleur d'ascenseur, un système de collecte de payage d'autoroute, et un système de gestion de crises.
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.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.005 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.000 | 0.002 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.000 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
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 it