Competizione di robustezza vs correttezza [chiuso]


17

Leggendo "Codice completo 2" nel paragrafo Qualità dei requisiti ho trovato questo:

Vengono specificati compromessi accettabili tra attributi concorrenti, ad esempio tra robustezza e correttezza?

(questo sopra è un punto di un ampio elenco di caselle di controllo al fine di verificare la qualità dei requisiti)

Quindi, ho trovato molte definizioni di robustezza e correttezza, nel web, nei libri accademici, ecc.

per esempio :

Nel libro "Object Oriented Software Construction, 2nd Edition, Bertrand Meyer, Prentice-Hall, 1997":

  • Correttezza: il grado in cui un sistema è privo di [difetti] nelle sue specifiche, progettazione e implementazione.
  • Robustezza: il grado in cui un sistema continua a funzionare in presenza di input non validi o condizioni ambientali stressanti.

Nonostante ciò, non è chiaro perché e in quali situazioni questi due potrebbero essere in conflitto.

La mia domanda è: perché questi due attributi sono in competizione ?


11
Libri diversi danno definizioni diverse a questi termini. (In genere, i libri scritti per programmatori ordinari non usano le stesse definizioni delle pubblicazioni accademiche.) Forse puoi dare un'occhiata a come questo libro li definisce, se mai. (A volte questi termini sono usati da libri senza alcuna definizione.)
rwong

Non sono a conoscenza di alcuna definizione di "robusto" diversa da "gestisce con grazia tutti i tipi di input imprevisti" (oltre agli input richiesti dal punto di vista funzionale).
Kaz

Ho modificato la mia domanda cercando di essere il più chiaro possibile in modo che possa essere riaperta.
superato il

Risposte:


36

Ci sono molte situazioni in cui questi due potrebbero essere in conflitto. Ad esempio, la robustezza può comportare la resilienza sotto carico pesante. Se una risposta approssimativa (cioè errata) a una richiesta può essere calcolata molto più velocemente di una risposta esatta (corretta), è importante sapere se il sistema dovrebbe fornire un risultato approssimativo o non riuscire a consegnare del tutto.


17

Questi due sono solo esempi come hai detto. In effetti, tutti i requisiti non funzionali di quel tipo possono potenzialmente entrare in conflitto tra loro. Nel libro "Costruire architetture evolutive" c'è una tabella di circa un centinaio di queste "abilità" (come spesso vengono anche chiamate).

È una specie di esercizio per gli architetti del software considerare il potenziale conflitto tra due di questi. Puoi sostanzialmente decidere quali di questi sono importanti per i tuoi progetti, quindi tenere traccia di questi conflitti.

Per tornare al tuo esempio preciso e dare un'occhiata alla definizione del termine robustnessin Wikipedia:

Nell'informatica, la robustezza è la capacità di un sistema informatico di far fronte agli errori durante l'esecuzione [1] [2] e far fronte a input errati.

Come puoi vedere dalla definizione, la robustezza comporta errori . D'altra parte, vuoi avere la correttezza, il che significa sostanzialmente l'assenza di errori.

Per rendere più evidente il conflitto, consideriamo un semplice campo di input. Dal requisito di correttezza è più semplice rifiutare qualsiasi input errato fatto dall'utente. Ma la robustezza richiede di essere in grado di lavorare con questo input, che potrebbe non essere del tutto corretto.

Per portare tutto intorno al tuo libro: qual è il compromesso accettabile ora? Supponiamo che tu scriva un'applicazione scientifica in cui l'utente può inserire una quantità di tensione, compresa l'entità. Quindi gli input corretti sarebbero qualcosa come "10 kV" o "200 mV". I compromessi accettabili possono includere l'abilitazione di input come "10kV", "10kVolt" o anche solo "10" e, per motivi di correttezza, mapparli su un valore di tensione valido. Nota che questo è ancora un compromesso e non una cosa "migliore di entrambi i mondi". Considera maiuscole e minuscole: "10 kV" e "10 KV" potrebbero andare bene, ma "10 mV" e "10 MV" potrebbero non esserlo. La correttezza diventa discutibile poiché non sei sicuro che sia milli o mega ora,


5

Un esempio pratico è XHTML vs. HTML .

  • I browser (in modalità rigorosa) rifiutano XHTML che presenta errori di sintassi. Ciò garantisce che i risultati errati non vengano visualizzati all'utente e aiuta a trovare gli errori.
  • I browser tentano di continuare ad analizzare il codice HTML anche se presenta problemi molto evidenti. Ciò consente spesso all'utente di visualizzare la pagina, anche se i contenuti sono leggermente alterati.

Pertanto XHTML punta alla correttezza, mentre HTML punta alla solidità. Attualmente l'HTML sembra più popolare, ma entrambe le parti hanno buoni argomenti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.