Compétition Robustesse vs Exactitude [fermé]

En lisant «Code Complete 2» dans un paragraphe sur la qualité des exigences, j'ai trouvé ceci:

Des compromis acceptables sont-ils spécifiés entre des attributs concurrents - par exemple, entre robustesse et exactitude?

(ce qui précède est un point d'une grande liste de cases à cocher afin de vérifier la qualité des exigences)

Donc, j'ai trouvé beaucoup de définitions de la robustesse et de l'exactitude, sur le Web, dans des livres universitaires, etc.

par exemple :

Dans le livre "Object Oriented Software Construction, 2nd Edition, Bertrand Meyer, Prentice-Hall, 1997":

• Exactitude: Le degré auquel un système est exempt de [défauts] dans sa spécification, sa conception et sa mise en œuvre.
• Robustesse: degré auquel un système continue de fonctionner en présence d'entrées invalides ou de conditions environnementales stressantes.

Malgré cela, il n'est pas clair pourquoi et dans quelles situations ces deux pourraient être en conflit.

Ma question est: pourquoi ces deux attributs sont-ils en compétition ?

Il existe de nombreuses situations dans lesquelles ces deux pourraient être en conflit. Par exemple, la robustesse peut impliquer la résilience sous une charge lourde. Si une réponse approximative (c.-à-d. Incorrecte) à une demande peut être calculée beaucoup plus rapidement qu'une réponse exacte (correcte), il est important de savoir si le système doit fournir un résultat approximatif, ou échouer complètement.

Ces deux ne sont que des exemples comme vous l'avez dit. En fait, toutes les exigences non fonctionnelles de ce type peuvent potentiellement entrer en conflit les unes avec les autres. Dans le livre "Construire des architectures évolutionnaires", il y a un tableau d'une centaine de ces "capacités" (comme on les appelle souvent).

C'est en quelque sorte un exercice pour les architectes logiciels de considérer le conflit potentiel entre deux d'entre eux. Vous pouvez essentiellement décider quels sont ceux qui sont importants pour vos projets, puis suivre ces conflits.

Pour revenir à votre exemple précis et jeter un œil à la définition du terme robustnessdans Wikipedia:

En informatique, la robustesse est la capacité d'un système informatique à faire face aux erreurs lors de l'exécution [1] [2] et à gérer les entrées erronées.

Comme vous pouvez le voir dans la définition, la robustesse implique des erreurs . D'un autre côté, vous voulez avoir l'exactitude, ce qui signifie essentiellement l'absence d'erreurs.

Pour rendre le conflit plus apparent, considérons un simple champ de saisie. À partir de l'exigence de correction, il est plus facile de rejeter toute entrée erronée faite par l'utilisateur. Mais la robustesse nécessite que vous puissiez travailler avec cette entrée, qui peut ne pas être entièrement correcte.

Pour mettre tout cela dans votre livre: quel est le compromis acceptable maintenant? Disons que vous écrivez une application scientifique dans laquelle l'utilisateur peut entrer une quantité de tension, y compris l'amplitude. Les entrées correctes seraient donc quelque chose comme "10 kV" ou "200 mV". Les compromis acceptables peuvent inclure l'autorisation d'entrées comme "10kV", "10kVolt", ou même juste "10" et pour des raisons d'exactitude, mappez-les à une valeur de tension valide. Notez que c'est toujours un compromis et non pas une chose "le meilleur des deux mondes". Considérez les majuscules par rapport aux minuscules: "10 kV" et "10 KV" peuvent convenir, mais "10 mV" et "10 MV" ne le sont pas. L'exactitude devient discutable car vous n'êtes pas sûr si c'est milli ou méga maintenant,

Un exemple pratique est XHTML vs HTML .

• Les navigateurs (en mode strict) rejettent le XHTML qui contient des erreurs de syntaxe. Cela garantit que les résultats incorrects ne sont pas affichés pour l'utilisateur et aide à rechercher les erreurs.
• Les navigateurs tentent de continuer à analyser le code HTML même s'il présente des problèmes très évidents. Cela permet souvent à l'utilisateur de visualiser la page, même si le contenu est un peu altéré.

Ainsi, XHTML vise la correction, tandis que HTML vise la robustesse. Actuellement, le HTML semble plus populaire, mais les deux parties ont de bons arguments.