SlideShare a Scribd company logo
1 of 20
Sviluppare software 
robusto e performante 
e... dormire sonni tranquilli
Nel tempo si sono affermati diversi modelli di 
sviluppo software: 
Il modello procedurale
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.
Il modello “service oriented” (soa)
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 )
 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.
Gli analisti funzionali attraverso un processo di 
decomposizione individueranno le funzioni atomiche da 
sviluppare.
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
Il design by contract
 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
 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 .
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
Come funziona il Contract by design ? 
Immagine da Design by contract" di Fabuio da Wikipedia -
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
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
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 )
Un 
esempi 
o di 
modulo
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
Il processo di definizione del 
contratto 
Compilazione dei form che descrivono gli 
“use cases”.
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 -

More Related Content

Similar to Sviluppo software - Il contract design

Bpos Sales Presentation
Bpos Sales PresentationBpos Sales Presentation
Bpos Sales Presentation
marcotucci
 
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
ercolonese
 
UAT Toolkit: collaudo di sistemi software complessi
UAT Toolkit: collaudo di sistemi software complessiUAT Toolkit: collaudo di sistemi software complessi
UAT Toolkit: collaudo di sistemi software complessi
Niccolò Avico
 
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRRPMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
PMexpo
 
Software development nel mondo industriale
Software development nel mondo industrialeSoftware development nel mondo industriale
Software development nel mondo industriale
guesta554cd
 
D'anselmo
D'anselmoD'anselmo
D'anselmo
qyqing
 

Similar to Sviluppo software - Il contract design (20)

SoftInstigate - Modelli di ingaggio nello sviluppo software
SoftInstigate - Modelli di ingaggio nello sviluppo softwareSoftInstigate - Modelli di ingaggio nello sviluppo software
SoftInstigate - Modelli di ingaggio nello sviluppo software
 
Alm pills - Sessione community tour Dot Net Umbria 2011
Alm pills - Sessione community tour Dot Net Umbria 2011Alm pills - Sessione community tour Dot Net Umbria 2011
Alm pills - Sessione community tour Dot Net Umbria 2011
 
Hermes System & Service Design
Hermes System  & Service Design Hermes System  & Service Design
Hermes System & Service Design
 
Previsione della domanda e gestione scorte aggiornata gennaio 2015
Previsione della domanda e gestione scorte aggiornata gennaio 2015Previsione della domanda e gestione scorte aggiornata gennaio 2015
Previsione della domanda e gestione scorte aggiornata gennaio 2015
 
Software Testing Forum 2012 - Polarion e TRS SpA
Software Testing Forum 2012 - Polarion e TRS SpASoftware Testing Forum 2012 - Polarion e TRS SpA
Software Testing Forum 2012 - Polarion e TRS SpA
 
Iloveyou
IloveyouIloveyou
Iloveyou
 
Hermes - System & Service design
Hermes - System & Service designHermes - System & Service design
Hermes - System & Service design
 
Autostrade per l'Italia: come riutilizzare 500 applicazioni COBOL in ambiente...
Autostrade per l'Italia: come riutilizzare 500 applicazioni COBOL in ambiente...Autostrade per l'Italia: come riutilizzare 500 applicazioni COBOL in ambiente...
Autostrade per l'Italia: come riutilizzare 500 applicazioni COBOL in ambiente...
 
e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)e-SUAP - General software architecture (Italiano)
e-SUAP - General software architecture (Italiano)
 
Bpos Sales Presentation
Bpos Sales PresentationBpos Sales Presentation
Bpos Sales Presentation
 
.NET Microservices
.NET Microservices.NET Microservices
.NET Microservices
 
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
02_AICQ_QOL_N.1-2009_ModelloSERVQUAL
 
UAT Toolkit: collaudo di sistemi software complessi
UAT Toolkit: collaudo di sistemi software complessiUAT Toolkit: collaudo di sistemi software complessi
UAT Toolkit: collaudo di sistemi software complessi
 
Caso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro FocusCaso di successo: Gruppo Zucchetti e Micro Focus
Caso di successo: Gruppo Zucchetti e Micro Focus
 
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRRPMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
PMexpo 2022 | La valutazione di congruità dei progetti ICT del PNRR
 
Protocollo Informatico: studio preliminare
Protocollo Informatico: studio preliminareProtocollo Informatico: studio preliminare
Protocollo Informatico: studio preliminare
 
#LRIS2014 - MessageBus, Cluster communication and Caching on B2B
#LRIS2014 - MessageBus, Cluster communication and Caching on B2B#LRIS2014 - MessageBus, Cluster communication and Caching on B2B
#LRIS2014 - MessageBus, Cluster communication and Caching on B2B
 
Software development nel mondo industriale
Software development nel mondo industrialeSoftware development nel mondo industriale
Software development nel mondo industriale
 
Analisi di un protocollo per la negoziazione di SLA in ambienti SOA.
Analisi di un protocollo per la negoziazione di SLA in ambienti SOA.Analisi di un protocollo per la negoziazione di SLA in ambienti SOA.
Analisi di un protocollo per la negoziazione di SLA in ambienti SOA.
 
D'anselmo
D'anselmoD'anselmo
D'anselmo
 

Sviluppo software - Il contract design

  • 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 esempi o 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”.
  • 20. 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 -