Jug Marche

Introduzione al Design By Contract: SpringContracts

Introduzione
Personalmente ho provato sempre un pò di avversione nei confronti degli argomenti squisitamente accademici senza nessun contraltare pratico. Va però detto che oggi bisogna essere di mentalità aperta e ascoltare anche questi ambienti di libero pensiero.
Per molto tempo il Design by contract (DBC) è stato catalogato nella categoria degli argomenti accademici, nonostante sia un'idea molto semplice e geniale e nonostante il suo ideatore, monsieur Bertrand Meyer, si sia preso la bega di idearsi un linguaggio di programmazione ad hoc, l'Eiffel (Meyer è un francese purosangue...:-) ).
Eiffel ha avuto un discreto succeso ma non è mai diventato un linguaggio di massa, ragion per cui il metodo DBC è rimasto "accademico" per molto tempo.


Il Design By Contract
Ma che cos'è il DBC? Sostanzialmente è un'idea che ricalca in ambito informatico quello che il contratto ricalca nella vita di noi esseri umani. Prendiamo ad esempio un contratto di fornitura merce alimentare:

-il cliente si impegna a pagare a pagare la merce ricevuta.
-il fornitore si impegna a fornire puntualmente la merce.
-se la merce è avariata o di bassa qualità il cliente può non pagare il carico o addirittura recidere il contratto.

Bene, in informatica, o meglio nella programmazione orientata agli oggetti, chi fornisce il servizio è l'oggetto (la classe) o per meglio dire i metodi pubblici della classe, il cliente è colui che invoca un metodo della classe, le clausole del contratto sono le invarianti della classe, ossia condizioni che si devono ritenere sempre verificate sulla classe.Es:

La classe ContoCorrenteImp gestisce un conto corrente con le seguenti proprietà (mooolto semplificate):

- si possono fare dei prelievi
- si possono fare dei versamenti
- si può richiedere il saldo (credito residuo)
- il conto non può andare "in rosso" quindi i prelievi vanno a buon fine solo se l'importo non supera il credito residuo (invariante di classe: importo sempre >= 0)

Il versamento sarà effettuato dal metodo addVersamento(int importo) mentre il prelievo sarà effettuato dal metodo subPrelievo(int importo). Usiamo parametri int per semplicità.
Il metodo getSaldo() restituirà il credito residuo del conto corrente, anche'esso come valore intero.
Gli "impegni" assunti da cliente e fornitore nel modello DBC si chiamano precondizioni e postcondizioni di un metodo. Rimanendo nel nostro esempio concreto supponiamo che:

-entrambi i metodi addVersamento(int importo) e subPrelievo(int importo) si aspettino un parametro intero positivo in ingresso dal "cliente"
-il cliente si aspetti un valore di ritorno booleano da subPrelievo(int importo) , true se il prelievo è stato effettuato o false se non è stato effettuato (e allora la cifra richiesta supera il credito residuo)
-il valore del saldo dopo la chiamata ad addVersamento(int importo) sia pari al vecchio saldo più all'importo specificato nella chiamata
-il cliente si aspetti come valore di ritorno di getSaldo() un valore maggiore o uguale a 0.

In realtà Java per "stipulare" un contratto tra una classe e chi la utilizza dispone già di uno strumento semantico: le interfacce. Se un oggetto implementa un'interfaccia assicura al cliente di esporre i metodi pubblici specificati nell'interfaccia e che rappresentano altrettanti servizi implementati.
Non disponiamo però di strumenti di linguaggio per precondizioni, postcondizioni ed invarianti.

Implementiamo quindi l'interfaccia ContoCorrente come siamo abituati a fare:

//INVARIANTE: la classe che implementa l'interfaccia deve avere una variabile saldo >= 0 interface ContoCorrente{            public getSaldo();   //PRECONDIZIONE: variabile importo > 0   //POSTOCONDIZIONE: ritorna false se importo > saldo,  true se importo <= saldo   public bool subPrelievo(int importo);   //PRECONDIZIONE: variabile importo > 0   //POSTOCONDIZIONE: il saldo è uguale al vecchio saldo + importo   public void addVersamento(int importo); }

Dalla teoria alla pratica: SpringContracts
Spring e un suo sottoprogetto SpringContracts ci offrono oggi un valido strumento per passare dalla teoria alla pratica codificando nell'interfaccia invariante, precondizioni e postcondizioni.
Ovviamente per sfruttare questa tecnica occore avere familiarità con la configurazione del framework Spring e con i suoi eccanismi di Aspect Oriented Programming. In questa sede ci limiteremo a illustrare la notazione con cui "decriamo" la nostra interfaccia per applicare il modello DBC.

//INVARIANTE: variabile saldo >= 0 @Invariant( condition="this.saldo>= 0 " ) interface ContoCorrente{            public getSaldo();   //PRECONDIZIONE: variabile importo > 0   //POSTOCONDIZIONE: ritorna false se importo > saldo,  true se importo <= saldo      @Precondition( condition = "arg1 > 0")   @Postcondition(      condition = "(arg1 > this.saldo) ==> (return == false)         and (arg1 <= this.saldo) ==> (return == true)" )   public bool subPrelievo(int importo);   //PRECONDIZIONE: variabile importo > 0   //POSTOCONDIZIONE: il saldo è uguale al vecchio saldo + importo      @Precondition( condition = "arg1 > 0")   @Postcondition(      condition = "old:this.saldo + arg1 == this.saldo" )   public void addVersamento(int importo); }

Come si può vedere la tecnica fa uso delle annotazioni di Java 5 e superiori. Ho lasciato per maggior comprensione i commenti sulle invarianti, precondizioni e postcondizioni in modo da poterle confrontare con la loro "traduzione" in codice.
Da notare il costrutto old:this.saldo che identifica il saldo precedente l'ultima chiamata del metodo addVersamento. Con arg1 si intende il primo argomento del metodo per cui vale la precondizione.
Se le invarianti, precondizioni e postcondizioni risultassero violate in un qualche punto di un programma verà lanciata un'eccezione del tipo ContractViolationException.

Ora non rimane che creare una classe ContoCorrenteImp che implementi l'interfaccia così scritta. Il bello che la classe (o le classi) di implementazione non sa nulla dei contratti che abbiamo scritto nell'interfaccia!

public class ContoCorrenteImp implements ContoCorrente{   ... }

Riferimenti
Sito di Quickstart di SpringContracts: http://springcontracts.sourceforge.net
Quickstart di SpringContracts, davvero ben fatto: http://springcontracts.sourceforge.net/quickstart.pdf




Introduzione al Design By Contract: SpringContracts è menzionato in: Articoli