Pouvez-vous écrire une spécification sans ambiguïté dans une langue naturelle comme l'anglais?

Il me semble que vous ne pouvez pas écrire une spécification de logiciel en anglais qui soit complètement exempte d'ambiguïtés, simplement en raison de la nature informelle du langage naturel - et donc qu'une spécification vraiment sans ambiguïté doit inclure du code écrit dans une langue formellement spécifiée.

Est-ce un résultat connu ou manque-t-il quelque chose?

N'est-ce pas ce que les avocats ont toujours fait pour éviter les ambiguïtés?

Le résultat est qu'ils écrivent de la manière la plus artificielle, essayer de lire leurs papiers est plus difficile que jamais, et malgré cela il y a toujours des incohérences et des ambiguïtés.

Vous avez raison, vous ne pouvez pas écrire une spécification logicielle complètement exempte d'ambiguïtés, mais vous n'arriverez pas à le faire en implémentant un langage spécifié formel non plus.

C'est aussi pourquoi nous documentons notre code, car il est parfois difficile à lire pour nos esprits.

Inutile de documenter du code avec un autre code.

Impossible? Demandons d'abord si c'est souhaitable. Si nous convenons que c'est impossible, et qu'il y a encore beaucoup de logiciels utiles, alors l'objectif d'une spécification sans ambiguïté semble académique.

Je dirais qu'il est impossible de prouver que quelque chose est parfait et sans ambiguïté, à la fois pour la spécification et le logiciel.

Je pense que cela dépend de la taille du problème. Si le problème est assez petit, de nature mathématique, et peut-être d'autres critères qui me manquent, je dirais qu'il est possible d'écrire une spécification qui fonctionne.

Plus le problème est grand, plus le public est large, plus il est difficile à faire.

Mais l'avionique et d'autres problèmes complexes suggèrent qu'il est possible d'écrire des spécifications "assez bonnes" en anglais pour résoudre de gros problèmes.

bien .. une spécification complètement sans ambiguïté du problème est le code lui-même :)

Il s'agit d'un problème connu et pour les systèmes critiques pour les missions spéciales, il est obligatoire d'écrire des spécifications non ambiguës dans un langage formel (de programmation), puis de les transformer en un code qui fait vraisemblablement ce que dit la spécification. C'est un domaine très étroit, 99,999% des développeurs n'ont jamais à faire de telles tâches, mais j'ai déjà parlé à un gars qui l'a fait pour un système de contrôle du trafic / ferroviaire.

Je suis un adepte du W3C et j'ai tendance à écrire des articles en fonction de leurs spécifications. Mon expérience me dit que la lecture de toute spécification sans exemples de codes écrits, est tout simplement un casse-tête.

Je suis entièrement d'accord et je pense que la raison principale est que les développeurs ont tendance à mieux lire et comprendre le code. Imaginez simplement que vous obtenez un papier mathématique sans aucune formule.

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

ou:

result = (x + y) / b

Lequel est le plus court? Lequel est le plus lisible? Ce qui apporte plus de compréhension avec cela?

Il en va de même pour les spécifications. Plusieurs fois, lorsque vous arrivez aux parties techniques, l' écriture d'une ligne de code peut clarifier un long paragraphe d'explication.

Supposons qu'il existe un langage formel qui permet d'écrire des spécifications sans ambiguïté. Ensuite, je propose qu'il y ait une cartographie bijective à un sous-ensemble de l'anglais. Par conséquent, il devrait être possible d'écrire des spécifications sans ambiguïté si vous vous en tenez à ce sous-ensemble.

Mais tout langage formel suffisamment expressif pour faire quelque chose d'intéressant ne sera pas exempt d'incohérences (incomplétude de Gödel).

Les spécifications sont ambiguës et imprécises car les personnes sont ambiguës et imprécises. Trouvez une personne parfaite et vous obtiendrez peut-être une spécification parfaite.

L'anglais, le swahili, le sanskrit ou le babylonien ne fait aucune différence.

L'ambiguïté est en fait une force dans ce contexte.

Pour expliquer pourquoi, supposons un instant qu'il est possible d'utiliser la langue anglaise de manière totalement non ambiguë, de sorte que tout problème pouvant être résolu par programme puisse être exprimé de manière complète et non ambiguë. Si nous utilisons cette variante de l'anglais et que notre description décrit en effet le programme à écrire de manière complète et sans ambiguïté, il s'ensuit logiquement qu'il doit être possible d'effectuer une traduction automatique dans le langage de programmation cible - en d'autres termes, la variante de L'anglais que nous avons conçu est en fait un langage de programmation lui-même.

Les personnes qui lisent des documents de conception (en particulier des conceptions fonctionnelles) ne veulent pas vraiment ce niveau de détail - la lecture de la source d'un programme, que ce soit en C ++, Java ou en anglais sans ambiguïté, est bien au-dessus de la tête du non-programmeur moyen. C'est là qu'interviennent les langages naturels: ils permettent à l'auteur d'une spécification de glisser dans les deux sens sur l'échelle des détails, en déplaçant les détails d'implémentation non pertinents dans le sous-texte, ou en les laissant entièrement non spécifiés. Les langues naturelles regorgent de dispositifs pour transmettre un sens relativement clairement même si vous ne fournissez pas de définition exacte (ce qui rend les traductions automatisées si difficiles).

Donc, l'objectif n'est généralement pas une spécification complète, correcte et sans ambiguïté; l'objectif est d'écrire une spécification qui illustre clairement, aux humains, ce que vous êtes sur le point de construire.

Chaque fois que vous avez besoin de corrects et sans ambiguïté, et que les choses deviennent techniques de toute façon, le pseudocode est souvent plus précieux que les langages naturels ou les formels rigides - il peut toujours omettre des détails non pertinents (en appelant des fonctions / processus non spécifiés), mais la structure est sans ambiguïté .

Vous ne manquez rien, sauf que la documentation est écrite pour être lue par les humains. Une certaine ambiguïté est attendue, et même bienvenue, car le texte laconique est difficile à lire (= pas pour les humains).

Spécifier la documentation d'un langage formel dans un autre langage formel serait une sorte de problème de poule et d'oeuf.

Si vous avez vraiment besoin de spécifications formelles, il existe des moyens formels de vérifier les modèles . C'est un domaine de recherche actif et très intéressant, mais les "utilisateurs" finaux ici sont des machines, pas des humains.

(Certains de mes points ont déjà été évoqués par d'autres réponses, mais je pense que j'apporte une perspective suffisamment différente pour que cela mérite une réponse plutôt qu'un commentaire.)

Avant d'aborder la question de savoir si une spécification peut être vraiment et complètement sans ambiguïté, nous devons nous demander si elle doit être sans ambiguïté, au moins au niveau que vous demandez.

Permettez-moi d'aborder cela du point de vue d'un gestionnaire de programme travaillant sur un projet de petite à moyenne taille, ou sur une fonctionnalité dans le cadre d'un projet plus vaste. Il existe généralement deux types de spécifications différents qui seront rédigés pour un tel projet: une spécification fonctionnelle (ou PM) et une spécification de conception (ou de développement):

• La spécification fonctionnelle a pour tâche de décrire ce que le projet ou la fonction doit faire, souvent du point de vue du client. Il ne devrait pas, en général, décrire comment procéder. Selon le type de projet, le client peut se soucier de l'apparence de l'API externe, mais le client se soucie-t-il de savoir si la classe A hérite de la classe B ou implémente l'interface C? Il ne devrait pas. Et la spécification fonctionnelle non plus. Cela introduit déjà un niveau d'ambiguïté: celui de la conception technique.
• La spécification de conception a pour tâche de décrire comment les exigences fonctionnelles doivent être satisfaites, du point de vue de l'architecte ou du concepteur technique de l'élément ou du projet. Il vise à résoudre les ambiguïtés de haut niveau de la conception technique. Cela contiendra les détails que vous ne vouliez pas dans la spécification fonctionnelle, tels que l'architecture de la solution, y compris la structure de classe, l'héritage, peut-être même des fonctions et des méthodes individuelles, selon la portée et l'échelle du projet. L'architecte se soucie-t-il de ce que vous appelez vos variables temporaires ou si vous utilisez une liste ou un tableau pour un type de données interne? En supposant qu'elle fasse confiance à ses développeurs, elle ne devrait pas, et les spécifications de conception non plus. Cela introduit un deuxième niveau d'ambiguïté: celui de la mise en œuvre.

En général, ces détails au niveau de l'implémentation ne sont pas capturés dans un document formel, mais plutôt documentés, en soi , dans le code lui-même, y compris les commentaires. Ce niveau d'ambiguïté permet à un bon développeur d'utiliser ses propres compétences et de prendre les décisions techniques axées sur les détails qui sont la marque d'un bon développeur individuel. Pour cette raison, je n'hésiterai pas à dire que l'ambiguïté dans une spécification est, en fait, une bonne chose: elle permet aux développeurs de faire leur travail, et les élève au-dessus de simples "singes de code".

Cela ne veut pas dire, cependant, qu'il devrait y avoir une ambiguïté dans tout le document. À un niveau élevé, il ne devrait pas y avoir d'ambiguïté sur l'interface avec le client. Si la fonctionnalité possède une API accessible au public, elle doit être strictement définie. Si le système nécessite qu'une date soit transmise pour faire son travail, cette date doit-elle être dans le fuseau horaire local ou UTC? Quel format est nécessaire? Doit-elle être précise à la milliseconde près, ou la minute est-elle très bien?

Pour en revenir à la question de savoir si le langage naturel peut être utilisé pour créer des spécifications sans ambiguïté, il est vrai qu'il n'est pas très bon pour capturer ce niveau de clarté. Je l'ai vu faire dans certaines circonstances limitées, mais ce sont probablement des exceptions uniques que nous ne pouvons pas appliquer universellement. Le plus souvent, l'ambiguïté est résolue à l'aide d'un jargon technique, de diagrammes ou même d'un pseudocode. Une fois que vous commencez à demander l'aide de ces outils, le langage naturel cesse d'être le seul descripteur. Parce que ces outils peuvent rendre plus claire même une spécification fonctionnellement sans ambiguïté, j'ose dire qu'une telle entreprise ne devrait même pas être tentée.

Cela dit, comme le langage naturel est généralement complété par ces outils pour le rendre fonctionnellement non ambigu, mon opinion professionnelle est que non, le langage naturel seul n'est pas suffisant pour créer des spécifications sans ambiguïté dans tous les cas.

On peut rendre le langage naturel relativement non ambigu, mais seulement avec beaucoup de difficulté.

La profession juridique a désespérément besoin que la langue soit aussi claire que possible. Bien que la façon dont une loi est appliquée peut être sujette à interprétation, ce que ces mots signifient ne devrait pas l'être.

Ce besoin a conduit à l'invention du jargon juridique. Jusqu'où êtes-vous prêt à aller?

Il existe un certain nombre de spécifications par le groupe ouvert, l'ISO, l'IETF et l'UIT qui sont suffisamment claires pour que les entreprises hautement compétitives puissent interagir avec succès. Il existe un certain nombre de spécifications qui sont à la base de contrats ou de lois où des millions de dollars sont en jeu.

Les spécifications peuvent donc ne pas être "parfaites". Cependant, c'est parce que les humains ne sont pas parfaits. Par exemple, il est clair que HTTP doit utiliser un en-tête "Referer" - l'orthographe correcte est en fait "Referrer".

La langue anglaise est capable d'être sans ambiguïté, mais les humains sont capables de faire des erreurs - y compris l'ambiguïté.

De plus, il peut être utile d'être délibérément ambigu pour des détails qui n'ont pas été finalisés ou qui devront peut-être être mis à jour à l'avenir. Par exemple, une spécification peut spécifier un "hachage" plutôt que de spécifier spécifiquement md5, sha1, crc32 etc.

Je pense que la bonne réponse est négative. Il est nécessaire de distinguer les questions suivantes:

1. Est-il possible d'écrire une spécification logicielle dans un langage naturel qui ne contient pas d'ambiguïtés?
2. Est-il possible d'écrire des logiciels dans un langage naturel qui ne contient pas d'ambiguïtés?

La différence entre la première et la deuxième question concerne le niveau de détail impliqué, la quantité d'interprétation requise et les règles imposées à la construction de phrases en langage naturel aux fins de la rédaction du logiciel ou de la spécification du logiciel.

La réponse à la deuxième question est affirmative. Étant donné un sous-ensemble convenablement contraint d'un langage naturel avec des règles convenues pour la construction et la signification des phrases, le code peut être écrit en phrases grammaticales anglaises. Par exemple, le langage suivant permet sans ambiguïté d'écrire des instructions d'affectation:

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

Autrement dit, nous pouvons traduire systématiquement le code écrit dans les langages de programmation formels en langages naturels en décrivant chaque procédure. D'un autre côté, une spécification logicielle nécessite souvent une interprétation. Ainsi, si une spécification logicielle peut être donnée sans ambiguïté dépend du niveau de détail impliqué dans la spécification. Cependant, étant donné un domaine sélectionné sur lequel la spécification s'étend, avec des opérations particulières sur ce domaine sélectionnées, un processus de traduction similaire peut être effectué. Par exemple:

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

où les déclarations X, Y, Zne contiennent que les éléments mentionnés dans la préface de cahier des charges et sont écrits dans un convenablement formel et mutuellement accepté sous - ensemble d'un langage naturel. Les ambiguïtés concerneront alors la façon de mettre en œuvre la spécification - mais cela sera prévisible.

Non

Une spécification non ambiguë d'un calcul est un programme informatique.