Dependability-oriented model-driven requirements engineering for reactive systems
Notice bibliographique
Résumé
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.
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,005 | 0,009 |
| Méta-épidémiologie (sens strict) | 0,001 | 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,001 |
| Communication savante | 0,003 | 0,002 |
| Science ouverte | 0,003 | 0,002 |
| Intégrité de la recherche | 0,002 | 0,002 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,003 | 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 ».