Comment savoir que les méthodes formelles fonctionnent?

Un objectif important des méthodes formelles est de prouver l'exactitude des systèmes, par des moyens automatisés ou dirigés par l'homme. Cependant, il semble que même si vous pouvez fournir une preuve d'exactitude, vous ne pourrez PAS garantir que le système n'échouera pas. Par exemple:

• La spécification peut ne pas modéliser correctement le système, ou un système de production peut être trop compliqué à modéliser, ou le système peut être intrinsèquement défectueux en raison d'exigences contradictoires. Quelles techniques sont connues pour tester si une spécification a un sens?
• Le processus de preuve peut aussi être défectueux! Qui sait que ces règles d'inférence sont correctes et légitimes? De plus, les preuves peuvent être très volumineuses, et comment savoir qu'elles ne contiennent pas d'erreurs? C'est le cœur de la critique de De Millo, Lipton et Perlis "Processus sociaux et preuves de théorèmes et programmes". Comment les chercheurs en méthodes formelles modernes répondent-ils à cette critique?
• Au moment de l'exécution, de nombreux événements et facteurs non déterministes peuvent sérieusement affecter le système. Par exemple, les rayons cosmiques peuvent altérer la RAM de manière imprévisible, et plus généralement nous n'avons aucune garantie que le matériel ne souffrira pas de défauts byzantins, contre lesquels Lamport a prouvé qu'il est très difficile de résister. Ainsi, l'exactitude du système statique ne garantit pas que le système n'échouera pas! Existe-t-il des techniques connues pour expliquer la faillibilité d'un matériel réel?
• À l'heure actuelle, les tests sont l'outil le plus important dont nous disposons pour établir que le logiciel fonctionne. Il semble que ce devrait être un outil complémentaire avec des méthodes formelles. Cependant, je vois surtout des recherches axées sur des méthodes formelles ou des tests. Que sait-on de la combinaison des deux?

Concernant 4: Il y a beaucoup de travail combinant des méthodes formelles et des tests. La recherche sur les «tests de méthodes formels» sur Google révèle une quantité considérable de travail. Bien qu'il existe de nombreux objectifs différents de ce travail, l'un des principaux objectifs est de générer des suites de tests plus efficaces. Cette conférence donne une belle introduction, basée sur la vérification du modèle.

En ce qui concerne également le problème de sécurité des logiciels , qui a été édité hors de la question: les méthodes formelles doivent travailler plus fort pour être efficaces dans ce domaine. Typiquement, on écrit une spécification pour un logiciel et vérifie que la spécification est satisfaite, c'est-à-dire que lorsque l'entrée satisfait à la condition préalable, la sortie satisfait à la postcondition. Pour garantir la sécurité du logiciel, il faut également vérifier que le logiciel se comporte de manière sensible pour les entrées qui ne remplissent pas la condition préalable. (Cela équivaut bien sûr à définir la condition préalable sur true pour toutes les entrées.) L'espace de toutes les entrées est généralement beaucoup plus grand qu'une simple entrée bien formée, mais c'est généralement un endroit où même un logiciel fonctionnellement correct peut être violé, simplement par violant ses hypothèses.

En ce qui concerne le point 3: certains travaux ont été effectués pour vérifier les systèmes dans des paramètres où les défauts sont explicitement modélisés, y compris Faulty Logic: Reasoning About Fault-tolérant programmes. Matthew Meola et David Walker. Symposium européen sur la programmation, 2010. Les travaux sur la vérification des modèles probabilistes et la vérification probabiliste abordent certainement tous les deux la question des défauts dans une certaine mesure.

Vos points dans l'ordre:

• La justesse de toutes les spécifications est finalement subjective: elles sont perçues comme résolvant un problème correctement selon leurs utilisateurs ou non. Il n'y a pas de solution à cela: le développement de logiciels, et aucune méthode n'a la solution miracle pour celui-ci.
• Beaucoup de travail est nécessaire pour prouver que le processus est correct par rapport à ses hypothèses. Habituellement, des experts disposent d'informations pour valider ces règles. Toute activité humaine est sujette à erreur, mais les systèmes très formalisés utilisant des approches bien étudiées sont beaucoup moins sujets à erreur que presque tous les autres processus humains.
• À un moment donné, tout système a un mode de défaillance hors de la portée de ce système. Vous feriez mieux d'éliminer toutes les sources d'erreur prévisibles , même si vous en oubliez certaines imprévisibles.
• Les tests et les tests peuvent facilement coexister. Le test est un processus moins spécifique, plus ad hoc , vous pouvez donc y trouver un travail moins formel. Mais vous pourriez être intéressé par un outil tel que QuickCheck qui complète avec des tests les preuves offertes par le système de type Haskell.

Il a déjà été démontré que les méthodes formelles fonctionnent à grande échelle. Sans eux, nous n'aurions pas réussi à faire face à la complexité de la conception de systèmes numériques modernes (microprocesseurs).

Pas de micro-navires sans que sa logique soit soumise à une vérification d'équivalence fonctionnelle; sans que son FPU ait été soumis à FV; sans que ses protocoles de cohérence de cache aient été soumis à FV (c'est le cas depuis 1995).

À l'exception des différences évidentes entre les logiciels et les systèmes physiques techniques (par exemple, les ponts, où l'on peut ajouter des facteurs de sécurité), ils jouent le rôle de l'ingénierie mathématique dans CS. Cependant, l'utilisation de FM dépend toujours du rapport bénéfice / coût. Les tests Fuzz sont payants dans des entreprises telles que Microsoft (Google SAGE dans une diapositive).

Même au sein d'un micro, il existe des sous-systèmes (par exemple, des pipelines de microprocesseurs), où FV n'a pas eu le même impact qu'ailleurs (par exemple, FPU, où les tests conventionnels n'ont pas été effectués du tout dans de nombreux cas où l'évaluation formelle de la trajectoire symbolique a prouvé l'absence de bogues : Kaivola et al CAV'09).

Des méthodes formelles sont également utilisées dans la synthèse d'artefacts (code, tests de haute qualité, calendriers de vidange optimale des bancs de batteries, ...). Bien sûr, tous les problèmes soulevés dans la question sont tout à fait valables et, comme dans toute autre utilisation de la technologie, les fausses annonces doivent être reconnues et évitées.

Concernant 2: si le système est formalisé dans un assistant de preuve (par exemple, Twelf ou Agda ou Coq) et que les propriétés de solidité et d'exhaustivité sont vérifiées, et que les preuves sont effectuées dans cet encodage, ce n'est pas un problème. Vous avez peut-être officialisé un système qui ne décrit pas ce que vous vouliez, mais au moins vous n'aurez pas de preuves incorrectes ou un système cassé dans lequel vous raisonnez.

Cependant, il semble que même si vous pouvez fournir une preuve d'exactitude, vous ne pourrez PAS garantir que le système n'échouera pas.

Oui, il n'y a peut-être aucune garantie . Les méthodes formelles visent à trouver et à éliminer les erreurs et à convaincre les humains.

Quelles techniques sont connues pour tester si une spécification a un sens?

Vous pourriez être intéressé par les outils de vérification de modèle pour les spécifications des systèmes formels .

Le processus de preuve peut aussi être défectueux! Qui sait que ces règles d'inférence sont correctes et légitimes?

Je pense (en raison du théorème d'incomplétude de Goedel) que le fait de montrer qu'un système de règles d'inférence est cohérent fait nécessairement appel à un ensemble encore plus puissant de règles d'inférence.

De plus, les preuves peuvent être très volumineuses, et comment savoir qu'elles ne contiennent pas d'erreurs?

Espérons que d'énormes épreuves soient vérifiées par un petit vérificateur qui peut être lu et compris par les humains dans un délai raisonnable. C'est ce qu'on appelle parfois le "critère de Bruijn". Si vous pensez que le vérificateur d'épreuves ne certifiera pas une preuve incorrecte, il vous suffit de vérifier le vérificateur.

Existe-t-il des techniques connues pour expliquer la faillibilité d'un matériel réel?

Que diriez-vous d' un langage d'assemblage typé tolérant aux pannes ?

Cependant, je vois surtout des recherches axées sur des méthodes formelles ou des tests. Que sait-on de la combinaison des deux?

"La conférence TAP est consacrée à la convergence des preuves et des tests" .

Une simple recherche sur Google pour "preuves et tests" a plusieurs bons résultats au-dessus du pli.

Quelles techniques sont connues pour tester si une spécification a un sens?

C'est définitivement un jugement. En génie logiciel, les gens ont conçu une méthodologie très stricte pour trouver / écrire / confirmer les spécifications. Cela se fait par de vrais humains et en utilisant un processus non formel (dans le sens non mathématique), donc il est toujours sujet à des incohérences, mais en fin de compte, cela correspond à ce que les gens veulent vérifier, ni plus ni moins.

Existe-t-il des techniques connues pour expliquer la faillibilité d'un matériel réel?

Bien sûr, il existe un domaine de vérification connu sous le nom de vérification à l' exécution , vous pouvez également utiliser la vérification de modèle basée sur l'exécution sur le système réel fonctionnant sur un environnement totalement virtuel soumis à un scénario spécifique (j'y ai contribué moi-même avec V-DS + APMC ). Cependant, il s'agit clairement d'un problème majeur pour ajouter l'interaction entre le système et l'environnement dans le processus de vérification.

Cependant, je vois surtout des recherches axées sur des méthodes formelles ou des tests. Que sait-on de la combinaison des deux?

Wow, aujourd'hui je serai totalement impudique et je me citerai à nouveau. Avec nos co-auteurs, nous travaillons sur la combinaison de la vérification et du test des modèles, vous pouvez consulter la liste des publications d'un ancien doctorant de notre groupe ou rechercher «vérification approximative du modèle probabiliste» ou «vérification statistique du modèle» dans tout bon moteur de recherche (travail effectué par Younes et al., Sen et al. Ou moi-même et al. Et bien d'autres).

Vous pourriez être très intéressé par les travaux de John Rushby , l'un des concepteurs du prouveur de théorème PVS, qui est génériquement intéressé par exactement les points que vous mentionnez. Vous aimerez peut-être lire ce rapport classique à la FAA sur l'utilisation des méthodes formelles et la certification des systèmes critiques (1993) , et ses écrits plus récents sur la constitution d'un dossier probabiliste et formel de sécurité à partir de divers moyens de preuve fournis (tests, preuves, analyses, etc.).