Si vous avez appris des méthodes formelles pour les logiciels, dans quelle mesure les avez-vous trouvés utiles?

Si vous avez été formé à l'utilisation des méthodes formelles (FM) pour la programmation:

• Dans quelle mesure l'avez-vous trouvé?
• En quoi consistait votre formation FM (par exemple un cours, un livre)?
• Quels outils FM utilisez-vous?
• Quels avantages en termes de vitesse / qualité cela vous a-t-il donné par rapport à ne pas utiliser la FM?
• Quel type de logiciel créez-vous avec FM?
• Et si vous n'utilisez pas directement la FM maintenant, cela valait-il au moins la peine d'être appris ??

Je suis curieux d'entendre autant d'expériences / d'opinions sur la FM que l'on peut trouver dans cette communauté; Je commence à le lire et je veux en savoir plus.

Contexte

La programmation et le développement / l'ingénierie de logiciels sont parmi les compétences / professions humaines les plus récentes sur Terre, donc sans surprise, le domaine est immature - cela apparaît dans la sortie principale de notre domaine, comme un code généralement en retard et sujet aux erreurs. L'immaturité de l'industrie est également illustrée par la large marge (au moins 10: 1) de productivité entre les codeurs moyens et supérieurs. De tels faits lamentables sont bien couverts dans la littérature et introduits par des livres comme Code Complete de Steve McConnell .

L'utilisation de méthodes formelles (FM) a été proposée par de grandes figures du logiciel / CS (par exemple feu E. Dijkstra ) pour s'attaquer à (l'une des) causes profondes des erreurs: le manque de rigueur mathématique dans la programmation. Dijkstra, par exemple, a plaidé pour que les étudiants développent ensemble un programme et sa preuve .

La FM semble être beaucoup plus répandue dans les programmes de CS en Europe par rapport aux États-Unis. Mais ces dernières années, de nouvelles approches et outils FM «légers» comme Alloy ont attiré l'attention. Pourtant, la FM est loin d'être une utilisation courante dans l'industrie, et j'espère avoir des commentaires ici sur pourquoi.

Mise à jour

À ce jour (14/10/2010), sur les 6 réponses ci-dessous, personne n'a clairement plaidé pour l'utilisation de la FM dans le travail "réel". Je suis vraiment curieux de savoir si quelqu'un peut et veut; ou peut-être que la FM illustre vraiment le fossé entre le monde universitaire (la FM est l'avenir!) et l'industrie (la FM est pour la plupart inutile).

Absolument inutile pour rien de non trivial.

J'avais un cours appelé, à juste titre, "Méthodes formelles" qui se concentrait sur l'alliage - je ne vois pas comment utiliser ça n'importe où. Avait une autre classe qui se concentrait sur la modélisation de concurrence avec LTSA - également inutile.

Le problème est que la plupart des bogues et problèmes dans les logiciels (du moins d'après mon expérience) proviennent de la complexité qui se produit en dessous du niveau d'abstraction de ces outils.

J'ai une formation en CSP (Communicating Sequential Processes). Pour ne pas trotter moi-même, j'ai écrit ma thèse de maîtrise sur Timed CSP, en particulier pour "compiler" des spécifications écrites dans des méthodes formelles en C ++ exécutable. Je peux dire que j'ai une certaine expérience des méthodes formelles. Après avoir obtenu mon diplôme et obtenu un emploi dans l'industrie, je n'ai pas du tout utilisé de méthodes formelles. Les méthodes formelles sont encore trop théoriques pour être appliquées dans l'industrie. Les méthodes formelles ont trouvé une application pratique dans le domaine des systèmes embarqués. Par exemple, la NASA utilise des méthodes formelles dans ses projets. Je suppose que les méthodes formelles sont très loin d'être largement adoptées dans l'industrie. Cela n'a tout simplement pas de sens d'écrire des spécifications logicielles dans des méthodes formelles et de les "interpréter par l'homme" dans le cadre de votre choix. Un anglais simple et des diagrammes fonctionnent mieux pour cela, tandis que les tests unitaires et d'intégration ont fait un assez bon travail de "vérification" de l'exactitude du code. je penseles méthodes formelles resteront dans le monde universitaire pendant un certain temps .

Les diagrammes d'état et les réseaux de Petri sont utiles pour modéliser et analyser des protocoles et des systèmes en temps réel. Ils aident d'abord à concevoir une solution. Deuxièmement, ils aident à trouver des cas de test pour des logiciels passionnants dans des situations très spécifiques.

J'ai lu quelques livres sur les méthodes formelles et j'en ai appliqué quelques-uns. Ma réaction immédiate a été, "Gee, ces livres me disent comment être un bon programmeur, tant que je suis un mathématicien parfait." Une autre faiblesse est que vous ne pouvez prouver l'équivalence qu'avec une autre description formelle. Écrire une spécification formelle pour un programme équivaut à écrire un programme dans un langage de niveau supérieur, et il n'y a aucun moyen que vous puissiez éviter d'introduire des bogues dans une spécification raisonnablement grande.

Je n'ai jamais fait travailler des méthodes formelles à grande échelle. Ils peuvent être utiles pour obtenir quelque chose de petit et correct, et pour me convaincre qu'ils sont corrects. De cette façon, je peux travailler avec des blocs de construction légèrement plus grands et parfois faire un peu plus.

Une chose que j'ai prise qui est plus généralement utile est le concept d'un invariant, une déclaration sur un programme et son état qui est toujours vrai. Tout ce que vous pouvez raisonner est bon.

Comme mentionné ci-dessus, je ne suis pas un mathématicien parfait, et donc mes preuves contiennent parfois des erreurs. Cependant, d'après mon expérience, il s'agit généralement de grosses erreurs stupides qui sont faciles à détecter et à corriger.

J'ai suivi un cours d'études supérieures en analyse de programme formelle, où nous nous sommes concentrés sur la sémantique opérationnelle. J'ai fait mon dernier document sur l'effort seL4, en passant en revue les méthodes formelles utilisées. Mon principal point de vue pratique est que sa valeur est marginale. Non seulement vous devez écrire le programme, vous devez aussi en écrire la preuve. Sensationnel. Deux sources de bugs. Pas seulement un. En outre, il y avait une énorme quantité de restrictions imposées au code réel. Il est très difficile de décrire formellement un ordinateur physique, y compris les E / S.

Autodidacte TLA + l'année dernière, je l'utilise depuis. C'est l'un des premiers outils que j'atteins chaque fois que je démarre un projet. L'erreur que la plupart des gens font est qu'ils supposent que les méthodes formelles sont tout ou rien: soit vous n'utilisez pas de méthodes formelles, soit vous avez une vérification complète. Cependant, il y a quelque chose entre eux: la spécification formelle , où vous vérifiez qu'une spécification abstraite de votre projet ne casse pas vos invariants. Contrairement à la vérification, la spécification est suffisamment pratique pour être utilisée dans l'industrie.

Les langages de spécification sont plus expressifs que les langages de programmation. Par exemple, voici une spécification PlusCal (très) simple pour un magasin de données distribué:

process node \in 1..5 \* Nodes
variables online = TRUE,
          stored \in SUBSET data; \* Some set
begin 
  Transfer:
    either
      with node \in Nodes, datum \in stored do
        node.stored := node.stored \union {datum};
      end
    or \* crash
      online := FALSE;
    end either;
end process;

Cet extrait spécifie cinq nœuds s'exécutant simultanément, exécutant les transferts dans un ordre arbitraire, où chaque transfert est une donnée arbitraire vers un nœud arbitraire. De plus, nous avons spécifié que tout transfert donné peut échouer et entraîner la panne du nœud. Et nous pouvons simuler tous ces comportements dans le vérificateur de modèle TLA +! De cette façon, nous pouvons tester que, quels que soient l'ordre, les taux d'échec, etc., nos exigences restent valables. En parlant de cela, ajoutons quelques exigences. Tout d'abord, que nous ne transférons jamais de données vers un nœud hors ligne:

[][\A node \in Nodes: ~online => UNCHANGED node.stored]_vars

Dans notre version simplifiée, le vérificateur de modèle trouvera un état d'échec. Nous pouvons également spécifier "n'importe quelle donnée donnée se trouve dans au moins un nœud en ligne":

\A d \in data: \E n \in Nodes: n.online /\ d \in n.stored

Ce qui échouera également. Bonne chance pour les vérifier avec un test unitaire!

La principale limitation de la spécification est qu'elle existe indépendamment de votre code réel. Il ne peut que vous dire que votre conception est correcte, et non que vous l'avez mise en œuvre correctement. Mais il est plus rapide de spécifier que de vérifier et il détecte des bogues trop subtils pour les tests, donc je trouve que ça vaut la peine. À peu près tout code impliquant la concurrence ou plusieurs systèmes est un bon endroit pour une spécification formelle.

Avant, je travaillais dans un département d'ICL avant qu'ils ne soient rachetés par Fujitsu. Ils avaient de gros contrats de type gouvernemental qui exigeaient la preuve que le logiciel fonctionnait comme annoncé, alors ils ont construit une machine qui prendrait les spécifications formelles écrites en Z et validerait le code en cours d'exécution, avec un gros voyant vert ou rouge pour passer / échouer.

C'était une chose incroyable, mais, comme le fait remarquer le estimé @FishToaster , cela n'a servi à rien de non trivial.

1. " Dans quelle mesure l'avez-vous trouvé? "

L'application de Petri Nets à la programmation informatique est très utile. J'ai créé «Net Elements and Annotations», une méthode basée sur Petri Nets (Chionglo, 2014). J'applique la méthode depuis 2014 pour écrire des programmes JavaScript qui utilisent l'API Acrobat / JavaScript pour les applications de formulaire PDF.

2. «En quoi consistait votre formation FM (par exemple un cours, un livre)? "

Je me suis «entraîné» sur les réseaux de Petri grâce à l'autoformation. J'ai lu les chapitres sur les réseaux de Petri du manuel «Réseaux de Petri et Grafcet: outils de modélisation des systèmes d'événements discrets» (David et Alla, 1992). J'ai également lu des articles de recherche sur les réseaux de Petri. Après avoir créé et documenté «Éléments nets et annotations», j'ai pratiqué l'application de la méthode pendant plusieurs semaines.

3. « Quels outils FM utilisez-vous? "

Je dessine des diagrammes de Petri Net en utilisant PowerPoint. Je crée la vue formulaire des annotations en utilisant Word. Je crée des jeux de jetons en tant qu'applications de formulaire PDF à l'aide d'Acrobat et du Bloc-notes. Après avoir ajouté les entrées dans le formulaire, la traduction de ces entrées en code JavaScript est systématique. Il devrait donc être possible d'automatiser la traduction. Si les «entrées» ont été ajoutées aux objets graphiques dans PowerPoint, il devrait également être possible de les traduire systématiquement en code JavaScript et d'automatiser également cette traduction. J'utilise également un ensemble d'outils de travail en cours qui effectue ces traductions et pour créer des ressources supplémentaires pour la création d'applications de formulaire PDF (Chionglo, 2018; 2017).

4. « Quels avantages en termes de vitesse / qualité cela vous a-t-il apporté par rapport à ne pas utiliser la FM? "

Je peux écrire des programmes JavaScript en utilisant "Net Elements and Annotations" plus rapidement que je peux écrire un programme JavaScript sans utiliser "Net Elements and Annotations". Et pour les grands programmes, je peux arrêter de coder et revenir au codage plus tard (ou bien plus tard) sans me demander où continuer (Chionglo, 2019). Dans certains cas, je peux écrire des programmes JavaScript en utilisant «Net Elements and Annotations» mais je ne peux pas écrire les programmes JavaScript sans utiliser «Net Elements and Annotations». Par exemple, je n'aurais pas pu créer des implémentations non récursives de fonctions récursives sans utiliser «Net Elements and Annotations» (Chionglo, 2019b; 2018b; 2016). Cela est vrai avec ou sans les outils de travail en cours.

5. " Quel type de logiciel créez-vous avec FM? "

J'utilise «Net Elements and Annotations» pour créer des programmes JavaScript qui utilisent l'API Acrobat / JavaScript pour les applications de formulaire PDF. Je peux également appliquer la méthode pour créer des programmes JavaScript pour des documents HTML et pour créer des croquis Arduino (Chionglo, 2019c; 2019d).

6. « Et si vous n'utilisez pas directement la FM maintenant, cela valait-il au moins la peine d'être appris? » Sans objet.

Les références

Chionglo, JF (2019b). Calcul du nième terme d'une relation récursive: utilisation d'une fonction non récursive - une réponse à une question lors de l'échange de pile de mathématiques. < https://www.academia.edu/38496025/Computing_the_N-th_Term_of_a_Recursive_Relation_Using_a_Non-Recursive_Function_A_Rply_to_a_Question_at_Mathematics_Stack_Exchange >.

Chionglo, JF (2019c). Flame Effect Control Logic, Simulation and Sketch: A Answer to a Request at Arduino Community Forum. https://www.academia.edu/40342956/Flame_Effect_Control_Logic_Simulation_and_Sketch_A_Rply_to_a_Request_at_the_Arduino_Community_Forum .

Chionglo, JF (2019). Comment continuer à coder une application après une longue pause? Répondre à "Comment savez-vous où vous vous êtes arrêté dans vos codes après une pause de 2 semaines?" - Software Engineering Stack Exchange. https://www.academia.edu/39705042/How_I_Continue_Coding_an_Application_after_a_Long_Break_Rhness_to_How_do_you_know_where_you_stopped_in_your_codes_after_a_2-week_break_Software_Engine .

Chionglo, JF (2019d). Afficher et masquer la logique de contrôle: inspiré d'une question lors du débordement de la pile. < https://www.academia.edu/40283015/Show-and-Hide_Control_Logic_Inspired_by_a_Question_at_Stack_Overflow >.

Chionglo, JF (2018b). Un modèle de Petri Net pour la factorielle d'un nombre: et une fonction JavaScript non récursive pour le calculer. <>.

Chionglo, JF (2018). Créer Hyper Form ™ - Un workflow en cours: mise à jour sur la recherche en programmation Internet. https://www.academia.edu/37697498/Create_Hyper_Form_-A_Workflow_in_Progress_Update_on_the_Net_Programming_Research .

Chionglo, JF (2017). Net Programming: A Research Research: For Developing PDF Form Applications with PowerPoint and Acrobat. https://www.academia.edu/33374809/Net_Programming_A_Research_Proposal_For_Developing_PDF_Form_Applications_with_PowerPoint_and_Acrobat..

Chionglo, JF (2016). Un modèle de Petri Net pour calculer le nombre de Fibonacci. https://www.academia.edu/31748108/A_Petri_Net_Model_for_Computing_the_Fibonacci_Number.

Chionglo, JF (2014). Éléments nets et annotations pour la programmation informatique: calculs et interactions en PDF. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

David, R. et H. Alla. (1992). Filets de Petri et Grafcet: outils de modélisation de systèmes à événements discrets. Upper Saddle, NJ: Prentice Hall.