Design by contract: differenze tra le versioni

Versione delle 01:24, 11 ott 2010

Versione attuale delle 19:16, 9 gen 2018

(18 versioni intermedie di 13 utenti non mostrate)

Riga 1:

{{F|ingegneria del software|febbraio 2013}}

'''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 [[tipo di dato astratto|tipi di dati astratti]] e sulla metafora di un [[contratto]] legale.

[[File:Design by contract.svg|miniatura|destra|Uno schema che rappresenta le informazioni delle specifiche funzionali o del contratto]]

'''Design by contract''' or(in sigla: '''DBC''' (in) italiano,o '''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 [[tipo di dato astratto|tipi di dati astratti]] e sulla metafora di un [[contratto]] legale.

==Descrizione==

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.

Riga 6 ⟶ 9:

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 da dover far parte del processo di progettazione. In effetti, se si vogliono usare le asserzioni come garanzia del fatto che l'implementazione svolta rispettarispetti 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 14 ⟶ 17:

* Condizioni erronee o eccezionali che possono avvenire

* Effetti collaterali

* [[Precondizione|Precondizioni]]

* [[Postcondizione|Postcondizioni]]

* [[Invariante (informatica)|Invarianti]]

* (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 verificherà le condizioni del contratto; la codifica in tal caso fallirà, avendo la verifica del contratto come rete di sicurezza. (Questo si pone in netto contrasto con la metodologia della ''programmazione difensiva''.) Questo facilita molto il debugging, perché il comportamento inteso di ogni routine viene specificato chiaramente.

== Voci correlate ==

{{Portale|informatica}}

*[[Invariante (informatica)]]

*[[Invariante di classe]]

*[[Asserzione (informatica)]]

{{Portale|informatica}}

[[Categoria:Metodologie di sviluppo]]

[[Categoria:MetodologieMetodi di sviluppo software]]

[[da:Kontraktbaseret programmering]]

[[Categoria:Progettazione del software]]

[[de:Design by contract]]

[[en:Design by contract]]

[[eo:Perkontrakta programado]]

[[es:Diseño por contrato]]

[[fi:Sopimuspohjainen ohjelmointi]]

[[fr:Programmation par contrat]]

[[ja:契約プログラミング]]

[[pl:Programowanie kontraktowe]]

[[pt:Programação por contrato]]

[[ru:Контрактное программирование]]

[[sk:Design by contract]]

[[zh:契约式设计]]