Contract by programming
- 1. Sviluppare software robusto e performante e... dormire sonni tranquilli
- 2. Nel tempo si sono affermati diversi modelli di sviluppo software: Il modello procedurale
- 3. Il modello procedurale I programmi utilizzano sottoprogrammi (sub-rutine e funzioni) . La sequenza delle chiamate alle sub-rutine pu嘆 essere modificata solo modificando il programma principale.
- 4. Il modello service oriented (soa)
- 5. Il modello service oriented (soa) I programmi forniscono il servizio elementare richiesto dal processo. L'ordine di chiamata dei servizi pu嘆 essere modificato senza toccare il singolo servizio (basta modificare il processo )
- 6. I nostri clienti ci chiedono di orientare lo sviluppo degli applicativi verso una Services Oriented Architecture. Questo implica che noi dobbiamo iniziare a concepire lo sviluppo del software in termini di moduli a se stanti che forniscono servizi il pi湛 possibile atomici. Ogni modulo potr far parte di uno o pi湛 processi aziendali e potr essere riutilizzabile.
- 7. Gli analisti funzionali attraverso un processo di decomposizione individueranno le funzioni atomiche da sviluppare.
- 8. Come debbono essere disegnate le funzioni elementari per essere riutilizzabili ? Cose giuste - Definire con precisione cosa fa la funzione (scopo) . - Definire con precisione i parametri di ingresso della funzione (non basta indicare il data-type, ma indicare il significato semantico dei dati in ingresso - Definire con precisione l'output Cose sbagliate - Non definire con precisione cosa fa la funzione (scopi molteplici in base ad esempio alla presenza o meno di certi parametri) - Parametri di ingresso molteplici ed opzionali (non 竪 definito chiaramente il significato semantico dei dati) - Output non definito
- 9. Il design by contract
- 10. L'idea centrale di Design by Contract 竪 una metafora su come elementi di un sistema software debbano collaborare tra loro, sulla base di reciproci obblighi e reciproci benefici. La metafora viene dalla vita , in cui un "cliente" e un "fornitore" si accordano con un "contratto" che stabilisce : - Il fornitore deve fornire un certo prodotto (obbligo) e ha il diritto di aspettarsi che il cliente abbia pagato il prezzo (beneficio). - Il cliente deve pagare il prezzo(obbligo) per avere diritto ad ottenere il prodotto
- 11. I moduli software hanno tra di loro una relazione cliente fornitore . Questa relazione pu嘆 essere formalizzata come un contratto tra cliente e fornitore . Formalizzare e far rispettare i contratti rafforza l'affidabilit del software .
- 12. Benefici del Contract by design Fiducia - Precondizioni permettono al modulo di fidarsi dei dati ricevuti in input - Postcondizioni permettono al cliente di fidarsi dei dati ricevuti in output Correttezza - I contratti espliciti richiedono attenta riflessione Dati attendibili + algoritmi corretti = codice affidabile Sicurezza - Il preservare ci嘆 che deve rimanere invariato minimizza il rischio di regressioni
- 13. Come funziona il Contract by design ? Immagine da Design by contract" di Fabuio da Wikipedia -
- 14. Gli elementi del Contratto 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
- 15. Gli elementi del Contratto Precondizioni - Tutto ci嘆 che deve essere vero quando il modulo viene chiamato - Obblighi del chiamante e benefici attesi dal modulo Post-Condizioni - Ci嘆 che deve essere vero dopo l'esecuzione del modulo - Obblighi del modulo e risultati attesi dal chiamante Condizioni erronee od eccezionali - Definizione scenari alternativi dovuti ad errori
- 16. Gli elementi del Contratto Input accettabili ed inaccettabili - Vincoli che devono rispettare le procedure chiamanti Valori resi - Ci嘆 che deve essere restituito alla procedura chiamante Garanzie di prestazioni - Tempi di esecuzione e spazio occupato (ad esempio dimensione massima output e tempi di risposta )
- 17. Un esempio di modulo
- 18. Il processo di definizione del contratto Creazione dello schema SIPOC - uno schema SIPOC (talvolta indicato come COPIS) 竪 uno strumento che permette di sintetizzare gli input e gli output di uno o pi湛 processi aziendali (software) in forma tabellare Supplier Input Process Output Customer
- 19. Il processo di definizione del contratto Compilazione dei form che descrivono gli use cases (vedi esempio nella pagina successiva ) oppure seguire la traccia di use cases template scaricabile dal sito http://www.technosolutions.com/Files/Use _Case_Template.doc.
- 21. Bibliografia software by Design : Shaping Technology and The Workplace: Technology Harold Salzman Director, Work and Organizations Program University of Louisville Center for Urban and Economic Research, Stephen R. Rosenthal Professor of Operations Management and Director of the Manufacturing Roundtable Boston University School of Management - 1993 - Anteprima Design by Contract, by Example Richard Mitchell, Jim McKim - 2002 - Using Aspect-Oriented Programming for Trustworthy Software ... Vladimir O. Safonov - 2008 - Studies of Software Design: ICSE'93 Workshop, Baltimore, ... David Alex Lamb - 1996 - The Secret Path to Contract Programming Riches: An Expert ... Michael Nigohosian - 2004 - Anteprima - Altre edizioni
- 22. Bibliografia Software by Design : Shaping Technology and The Workplace: Technology Harold Salzman Director, Work and Organizations Program University of Louisville Center for Urban and Economic Research, Stephen R. Rosenthal Professor of Operations Management and Director of the Manufacturing Roundtable Boston University School of Management - 1993 - Anteprima Design by Contract, by Example Richard Mitchell, Jim McKim - 2002 -