Competição Robustez x Correção [fechado]

Lendo "Código Completo 2" em um parágrafo de Qualidade dos Requisitos , encontrei o seguinte:

As trocas aceitáveis ​​entre atributos concorrentes são especificadas - por exemplo, entre robustez e correção?

(isso acima é um ponto de uma grande lista de caixas de seleção para verificar a qualidade dos requisitos)

Então, encontrei muitas definições de robustez e correção, na web, livros acadêmicos, etc.

por exemplo :

No livro "Construção de software orientada a objetos, 2ª edição, Bertrand Meyer, Prentice-Hall, 1997":

• Correção: o grau em que um sistema está livre de [defeitos] em sua especificação, design e implementação.
• Robustez: o grau em que um sistema continua funcionando na presença de entradas inválidas ou condições ambientais estressantes.

Apesar disso, não está claro por que e em que situações esses dois podem estar em conflito.

Minha pergunta é: por que esses dois atributos estão em competição ?

Existem muitas situações em que esses dois podem estar em conflito. Por exemplo, a robustez pode envolver resiliência sob carga pesada. Se uma resposta aproximada (ou seja, incorreta) a uma solicitação puder ser calculada muito mais rapidamente que uma resposta exata (correta), é importante saber se o sistema deve fornecer um resultado aproximado ou falhar na entrega.

Estes dois são apenas exemplos, como você disse. De fato, todos os requisitos não funcionais desse tipo podem potencialmente entrar em conflito. No livro "Construindo arquiteturas evolucionárias", há uma tabela de aproximadamente cem dessas "habilidades" (como também são frequentemente chamadas).

É uma espécie de exercício para arquitetos de software considerar o possível conflito entre dois deles. Basicamente, você pode decidir quais são importantes para seus projetos e acompanhar esses conflitos.

Para voltar ao seu exemplo preciso e dar uma olhada na definição do termo robustnessna Wikipedia:

Na ciência da computação, robustez é a capacidade de um sistema de computador lidar com erros durante a execução [1] [2] e lidar com informações erradas.

Como você pode ver na definição, a robustez envolve erros . Por outro lado, você deseja ter correção, o que basicamente significa a ausência de erros.

Para tornar o conflito mais aparente, vamos considerar um campo de entrada simples. A partir do requisito de correção, é mais fácil rejeitar qualquer entrada incorreta feita pelo usuário. Mas a robustez exige que você possa trabalhar com essa entrada, o que pode não estar totalmente correto.

Para trazer tudo ao seu livro: qual é o compromisso aceitável agora? Digamos que você escreva um aplicativo científico no qual o usuário possa inserir uma quantidade de tensão, incluindo a magnitude. Portanto, entradas corretas seriam algo como "10 kV" ou "200 mV". Os trade-offs aceitáveis ​​podem incluir a permissão de entradas como "10kV", "10kVolt" ou mesmo apenas "10" e, para fins de correção, mapeie-as para um valor de tensão válido. Observe que isso ainda é uma troca e não uma coisa dos "melhores dos dois mundos". Considere letras maiúsculas e minúsculas: "10 kV" e "10 KV" podem estar bem, mas "10 mV" e "10 MV" podem não estar. A correção se torna questionável, pois você não tem certeza se agora é mil ou mega,

Um exemplo prático é XHTML vs. HTML .

• Os navegadores (no modo estrito) rejeitam XHTML que possui erros de sintaxe. Isso garante que resultados incorretos não sejam exibidos ao usuário e ajuda a encontrar os erros.
• Os navegadores tentam continuar analisando o código HTML, mesmo que ele tenha problemas muito óbvios. Isso geralmente permite que o usuário visualize a página, mesmo que o conteúdo seja um pouco confuso.

Assim, o XHTML busca a correção, enquanto o HTML busca a robustez. Atualmente, o HTML parece mais popular, mas ambos os lados têm bons argumentos.