Design by contract: differenze tra le versioni

Versione delle 01:55, 18 nov 2008

Versione delle 17:55, 28 nov 2008

Riga 6:

Molti linguaggi forniscono la possibilità di fare asserzioni come queste.

Tuttavia, il DBC è innovativo nel riconoscere che questi contratti sono così cruciali per la correttezza del software cheda dovrebberodover far parte del processo di progettazione. In effetti, ilse DBCsi sostienevogliono usare le asserzioni come garanzia del fatto che l'implementazione svolta rispetta tutte le specifiche funzionali descritte in fase di analisi, tali asserzioni dovrebbero essere scritte prima del codice.

Il concetto di contratto si estende verso il basso fino al livello dei metodi/routine; il contratto per ogni metodo conterrà normalmente le seguenti informazioni:

Riga 19:

* (Raramente) Garanzie di prestazioni, cioè sul tempo e lo spazio utilizzati

Usando la metodologia DBC, in caso di codice scritto a malo modo, il codice stesso del programma presumibilmente non deve mai verificareverificherà le condizioni del contratto; illa codecodifica in dovrebbetal "fallirecaso malamente"fallirà, avendo la verifica del contratto come rete di sicurezza. (Questo si pone in netto contrasto con la metodologia della ''programmazione difensiva''.) La proprietà di "fallire malamente" del DBCQuesto facilita molto il debugging, perché il comportamento inteso di ogni routine viene specificato chiaramente.

[[Categoria:Metodologie di sviluppo]]