Sviluppare software robusto e performante e dormire sonni tranquilli

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 -