Quels sont les obstacles qui empêchent l'adoption généralisée de méthodes formelles? [fermé]


14

Les méthodes formelles peuvent être utilisées pour spécifier, prouver et générer du code pour une application. Ceci est moins sujet aux erreurs - donc principalement utilisé dans les programmes de sécurité / critiques.

Pourquoi ne l'utilisons-nous pas plus souvent pour la programmation de tous les jours, ou dans des applications web, etc ...?

Les références :


3
Nous pourrions construire des maisons avec des murs de 5 pieds d'épaisseur - comme des châteaux médiévaux. La plupart du temps, ce serait plus difficile que cela ne vaut.
Baldrickk

5
Vous pouvez essayer d'appliquer des méthodes formelles à un projet de développement Web et voir comment cela se passe. Vous remarquerez très probablement que vous consacrez beaucoup d'efforts à une activité de faible valeur. Comparez cela avec des tests de fumée rapides, qui captureront déjà de nombreux bugs. Fait intéressant, les systèmes de type statique sont un type simple de système de preuve, mais en particulier le développement Web évite ces langages (préférant plutôt les langages hautement dynamiques comme Ruby, PHP ou JavaScript). La corrélation n'implique pas la causalité, mais elle met en pause la pensée.
amon

1
Vous préférez donc spécifier dans un langage de spécification plutôt que de programmer dans un langage de programmation? Ok, vous pourrez prouver que cela fonctionne selon les spécifications. Mais comment allez-vous prouver que la spécification reflète le vrai problème?
Christophe

3
@toto la question est: faire les choses correctement (travailler selon les spécifications) ou faire les bonnes choses (avoir les bonnes spécifications). Alors qu'en théorie, la spécification est ce que nous voulons, dans la pratique, nous savons rarement avec certitude ce qui est vraiment nécessaire: beyssonmanagement.com/2012/10/29/…
Christophe

3
Pour ceux qui sont déçus de la fermeture, il y a maintenant un excellent article de blog: Pourquoi les gens n'utilisent-ils pas des méthodes formelles?
icc97

Réponses:


19

Un ingénieur est une personne qui peut faire avec un dollar ce que n'importe quel idiot peut faire avec 10.

Contraintes de ressources, contraintes budgétaires, contraintes de temps, elles sont toutes importantes.

Le développement de logiciels utilisant des méthodes formelles est généralement beaucoup plus cher et prend beaucoup plus de temps que sans. De plus, pour de nombreux projets, la partie la plus difficile est de comprendre les exigences commerciales. Tout ce que l'utilisation de méthodes formelles vous achète dans ce cas est la preuve que votre code correspond à 100% à votre compréhension incomplète et incorrecte des exigences commerciales.

Pour cette raison, l'utilisation de méthodes formelles, de preuves, de vérification de programme et de techniques similaires est généralement limitée aux "choses qui comptent", à savoir les logiciels avioniques, les systèmes de contrôle pour les équipements médicaux, les centrales électriques, etc.


1
J'ajouterais également que mettre des méthodes formelles dans le langage de programmation est un domaine de recherche active actuellement, c'est-à-dire qu'il n'est pas encore prêt pour le courant dominant
jk.

1
J'accepte cette réponse, mais je voulais aussi une approche sur la raison pour laquelle les méthodes formelles sont toujours considérées comme `` coûteuses '' et `` longues '', en particulier lorsque nous savons combien coûte la maintenance et le suivi / débogage de code sur les grands projets.
toto

1
TDD & BDD sont des approches construites sur les principes de la logique Hoare, fondement des approches formelles. Ils améliorent l'efficacité et n'en nuisent pas.
Martin Spamer

1
Les preuves @toto sont vraiment, vraiment difficiles. Beaucoup de choses que les mathématiciens tiennent pour acquises dans les épreuves ne s'appliquent pas aux programmes. Par exemple, en C ++, l' addition est non associative: (-1 + 1) + INT_MAX = INT_MAX, -1 + (1 + INT_MAX)est un comportement non défini.
Hovercouch

1
@toto: La raison pour laquelle ils sont considérés comme "coûteux" et "chronophages" est parce que nous pouvons examiner les projets qui sont développés à l'aide de méthodes formelles et vérifier empiriquement que ces projets prennent beaucoup plus de temps à se développer. Regardez le temps de développement de seL4 / L4.verified, par exemple, par rapport à toute autre implémentation de L4.
Jörg W Mittag

12

Programmer ou ne pas programmer?

Pour résoudre un problème avec un produit logiciel, après avoir une bonne compréhension des exigences, vous pouvez SOIT écrire un programme en utilisant les langages de programmation OU spécifier le programme à l' aide d' un langage formel des outils et la génération de code d'utilisation. Ce dernier ajoute juste un niveau d'abstraction.

Faire les choses correctement ou faire les bonnes choses?

L'approche formelle vous donne la preuve que votre logiciel fonctionne selon les spécifications. Votre produit fait donc les choses correctement. Mais fait-il les bonnes choses?

Les exigences sur lesquelles vous travaillez peuvent être incomplètes ou ambiguës. Ils pourraient même être bogués. Dans le pire des cas, les besoins réels ne sont même pas exprimés. Mais une image vaut mille mots, juste des images google pour "Ce que veut le client", par exemple de cet article :

entrez la description de l'image ici

Le coût de la formalité

Dans un monde parfait, vous auriez des exigences parfaitement détaillées et parfaites dès le départ. Vous pouvez alors spécifier entièrement votre logiciel. Si vous optez pour le formel, votre code serait généré automatiquement afin que vous soyez plus productif. Les gains de productivité compenseraient le coût des outils formels. Et tout le monde utiliserait désormais des méthodes formelles. Alors pourquoi pas?

En pratique, c'est rarement la réalité! C'est pourquoi tant de projets en cascade ont échoué, et pourquoi les méthodes de développement itératives (agile, RAD, etc.) ont pris les devants: elles peuvent gérer des exigences, des conceptions et des implémentations incomplètes et imparfaites et les affiner jusqu'à ce qu'elles soient fines.

Et voici le point. Avec les méthodes formelles, chaque itération nécessite d'avoir une spécification formelle complètement cohérente. Cela nécessite une réflexion approfondie et un travail supplémentaire, car la logique formelle ne pardonne pas et n'aime pas les pensées incomplètes. Les expériences simples à jeter deviennent coûteuses sous cette contrainte. Et il en va de même pour chaque itération qui entraînerait un retour en arrière (par exemple, une idée qui n'a pas fonctionné ou une exigence qui a été mal comprise).

En pratique

Lorsque vous n'êtes pas obligé d'utiliser des méthodes formelles pour des raisons juridiques ou contractuelles, vous pouvez également atteindre une très haute qualité sans systèmes formels, par exemple en utilisant une programmation basée sur des contrats et d'autres bonnes pratiques (par exemple, révision de code, TDD , etc.). Vous ne pourrez pas prouver que votre logiciel fonctionne, mais vos utilisateurs apprécieront le logiciel plus tôt.

Mise à jour: effort mesuré

Dans le numéro d'octobre 2018 de Communications of the ACM, il y a un article intéressant sur les logiciels officiellement vérifiés dans le monde réel avec quelques estimations de l'effort.

Fait intéressant (basé sur le développement de systèmes d'exploitation pour les équipements militaires), il semble que la production de logiciels officiellement éprouvés nécessite 3,3 fois plus d'efforts qu'avec les techniques d'ingénierie traditionnelles. C'est donc très coûteux.

D'un autre côté, cela nécessite 2,3 fois moins d'efforts pour obtenir des logiciels de haute sécurité de cette façon qu'avec les logiciels de conception traditionnelle si vous ajoutez l'effort de rendre ces logiciels certifiés à un niveau de sécurité élevé (EAL 7). Donc, si vous avez des exigences élevées en matière de fiabilité ou de sécurité, il y a définitivement un intérêt à devenir formel.

La conception et le développement du code seL4 ont pris deux années-personnes. L'addition de toutes les preuves sérospécifiques au fil des ans représente un total de 18 années-personnes pour 8 700 lignes de code C. En comparaison, L4Ka :: Pistachio, un autre micro-noyau de la famille L4, de taille comparable à seL4, a pris six années-personnes pour se développer et ne fournit aucun niveau d'assurance significatif. Cela signifie qu'il n'y a qu'un facteur 3,3 entre les logiciels vérifiés et les logiciels de conception traditionnelle. Selon la méthode d'estimation de Colbert et Boehm 8, une certification EAL7 selon les Critères communs traditionnels pour 8 700 lignes de code C prendrait plus de 45,9 années-personnes. Cela signifie que la vérification formelle de l'implémentation au niveau binaire est déjà plus d'un facteur de 2,3 moins coûteux que le niveau de certification le plus élevé des Critères communs, tout en offrant une assurance nettement plus solide.


La programmation basée sur les contrats utilise au moins des preuves informelles.
Frank Hileman

@FrankHileman oui! Et le simple fait de clarifier les conditions préalables, les postconditions et les invariants aide grandement à revoir le code efficacement, à réduire les erreurs et à systématiser les tests.
Christophe

Ce devrait être de loin la meilleure réponse.
Hashim

0

Chaque programme dans n'importe quelle langue peut être considéré comme une spécification formelle (équivalente à une machine à tourner). Toute «spécification formelle» de niveau supérieur à utiliser pour prouver l'exactitude formelle est également - juste un autre programme. Mais c'est (typiquement) un programme mauvais, incomplet, vague, insuffisamment réfléchi. Et ce n'est pas un hasard, généralement écrit par des personnes qui ne savent pas programmer (ce sont généralement des experts du domaine).

Et donc prouver qu'un programme est compatible (produit les mêmes réponses ou selon la façon dont vous le caractérisez) avec ses exigences formelles de niveau supérieur, invariable se résume à la façon dont vous résolvez les ambiguïtés dans la spécification formelle de niveau supérieur. Il n'y a pas de bonne manière générale de le faire.

Cette mise en correspondance des exigences de haut niveau avec les détails de niveau inférieur est l'essentiel de la véritable programmation. Il ne devrait pas être surprenant que le travail de base effectué par un programmeur lisant et interprétant des spécifications ne puisse pas être remplacé par un geste de la main et en disant `` maintenant, juste voir si cette spécification formelle de haut niveau est respectée par cet exemple de programme ''.

Même aux premiers jours de la programmation logique, où ce concept semblait à première vue si prometteur (car à la fois la spécification de haut niveau et les programmes sous-jacents réels pouvaient être écrits dans le même langage), ce problème central s'est avéré insoluble.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.