Sviluppare softwarerobusto 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 (beneficio).

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 Invarianti (Raramente) Garanzie di prestazioni, cioè sul

tempo e lo spazio utilizzati

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 esempio 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 -

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