Design by contract

Da Wikipedia, l'enciclopedia libera.

Design by contract or DBC (in italiano, progettazione per contratto) è una metodologia per progettare il software. Prescrive che i progettisti di software debbano definire specifiche precise e verificabili delle interfacce dei componenti software, basandosi sulla teoria dei tipi di dati astratti e sulla metafora di un contratto legale.

L'idea centrale del DBC è che le entità software hanno degli obblighi nei confronti di altre entità in base a regole formalizzate fra di essi. Una specifica funzionale, o 'contratto', viene creato per ogni modulo nel sistema prima che sia codificato. L'esecuzione del programma è quindi vista come l'interazione fra i vari moduli vincolati da questi contratti.

In generale, le routine hanno precondizioni esplicite che il chiamante deve soddisfare prima di chiamare la routine, e postcondizioni esplicite che descrivono le condizioni che la routine garantirà essere vere nel momento in cui la routine finisce. Così, un contratto assume la seguente forma generale: "Se tu, il chiamante, predisponi certe precondizioni, allora io stabilirò certi altri risultati quando ti avrò terminato. Se tu violi le precondizioni, allora non ti prometto niente." L'implementazione di ogni modulo può allora essere scritta assumendo la correttezza dei moduli che usa (i suoi subappaltatori), purché soddisfi le loro precondizioni.

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 che dovrebbero far parte del processo di progettazione. In effetti, il DBC sostiene che le 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:

• Input accettabili e inaccettabili
• Valori resi, e il loro significato
• Condizioni erronee o eccezionali che possono avvenire
• Effetti collaterali
• Precondizioni
• Postcondizioni
• Invarianti
• (Raramente) Garanzie di prestazioni, cioè sul tempo e lo spazio utilizzati

Usando la metodologia DBC, il codice stesso del programma non deve mai verificare le condizioni del contratto; il code dovrebbe "fallire malamente", 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 DBC facilita molto il debugging, perché il comportamento inteso di ogni routine viene specificato chiaramente.