Dependability-oriented model-driven requirements engineering for reactive systems
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
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.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,005 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,000 | 0,002 |
| Science ouverte | 0,002 | 0,001 |
| Intégrité de la recherche | 0,000 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
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écoule