La Programmazione Strutturata
Uno stile di programmazione per la
costruzione di programmi complessi
Mario Capurso – http://info.bazarinfo.info
La Programmazione Strutturata
• E’ uno stile di programmazione …
• Introdotto da Edsger W. Dijkstra tra il 1968 e il
1969 (Università di Eindhoven-NL) …
• Durante le due Conferenze N.A.T.O. (1968, 1969)
sull’Ingegneria del Software …
• Per produrre programmi usando tecniche di
decomposizione simili a quelle usate in ingegneria
meccanica o elettronica
Per capirne di più - Un po’ di storia
• La storia dell’informatica moderna viene di solito
fatta iniziare dal 1950
• Diciotto anni dopo, nel 1968, i principali utenti di
tecnologia informatica, i comandi militari dei
paesi occidentali riuniti nella N.A.T.O. , decidono
di fare il punto della situazione
Le due Conferenze N.A.T.O.
• Vengono organizzate due Conferenze sulla
Ingegneria del Software nel 1968 a Garmisch(D) e
nel 1969 a Roma (I)
• I partecipanti rappresentano il mondo
dell’industria, della ricerca e degli utenti
• Sotto accusa sono costi e qualità del software
• L’obiettivo è di mettere a punto tecniche
ingegneristiche che migliorino costi e qualità
1968 - Garmisch
Dijkstra
Gillette
Naur
Randell
Gries
1969 - Roma
Randell
Dijkstra
Brinch Hansen
Hoare
Perlis
Lampson
Wirth
Ingegneria
• “Studio e realizzazione delle tecniche con
cui si applicano le enunciazioni teoriche e
le norme di funzionamento di una
disciplina, allo scopo di evitare uno
sviluppo casuale e frammentario”
(Vocabolario Zingarelli)
I Risultati
• Le due conferenze puntualizzano tendenze e
situazioni che richiedono un cambiamento
di indirizzo nella produzione del software
• Esse avranno un impatto fondamentale
nell’evoluzione dell’Informatica
L’andamento dei costi
• Gillette: “…The economics of software
development are such that the cost of maintenance
frequently exceeds that of the original
development…”
• Gillette: “…Gli aspetti economici dello sviluppo
del software sono tali che il costo della
manutenzione frequentemente supera quello dello
sviluppo originale…”
Distribuzione dei costi del
Software - 1
50%
Produzione
Manutenzione
50%
Distribuzione dei costi del
Software - 2
40%
25%
Analisi e
Progettazione
Programmazione
Documentazione
Testing
20%
15%
L’ Aumento della complessità del
software
• “…d’Agapeyeff: In 1958 a European general purpose
computer manufacturer often had less than 50 software
programmers, now they probably number 1,000-2,000
people; what will be needed in 1978?…”
• “…d’Agapeyeff: Nel 1958 un costruttore di computer
aveva spesso meno di 50 programmatori, oggi (1968)
probabilmente ne ha 1000 o 2000. Di quanti ne avrà
bisogno nel 1978 ?…”
Il peso della complessità – Troppi
fattori da considerare
Il peso della complessità – Troppi
livelli informatici da padroneggiare
Il peso della
complessità –
Troppe linee di
codice da
produrre
L’alto costo degli errori
• “…David and Fraser: Particularly alarming is the
seemingly unavoidable fallibility of large software, since a
malfunction in an advanced hardware-software system can
be a matter of life and death…”
• “…David and Fraser: Allarma in maniera particolare la
apparentemente inevitabile fallibilità di un software
enorme, poiché un malfunzionamento in un sistema
hardware e software avanzato può essere una questione di
vita o di morte…”
Il confronto con l’hardware
Legge di Moore e raddoppio dei
transistor a parità di costo
Il rapporto fra i costi di hardware
e software
La mancanza di metodo
• “…Graham: Today we tend to go on for years, with tremendous
investments to find that the system, which was not well understood to
start with, does not work as anticipated. We build systems like the
Wright brothers built airplanes— build the whole thing, push it off the
cliff, let it crash, and start over again…”
• “…Graham: Oggi tendiamo a continuare per anni con
tremendi investimenti fino a scoprire che il sistema, non
ben capito all’inizio, non funziona come previsto.
Costruiamo sistemi come i fratelli Wright facevano gli
aeroplani – li costruivano, li gettavano dalla collina, li
distruggevano e li ricostruivano…”
La Crisi del Software
• Difficolta’ di reggere il confronto con
l’hardware:
– Nella diminuzione dei prezzi
– Nella maturita’ come prodotto industriale
– Nella qualita’
• Necessita’ di metodi ingegneristici
paragonabili a quelli usati nello sviluppo
dell’hardware
L’Industria del Software ha da
imparare dall’Industria dell’Hardware
• Bisogna considerare il software come
prodotto industriale
• Bisogna definire un ciclo produttivo
ripetibile
• Bisogna definire il concetto di qualità
• Bisogna imparare a preventivare (e
rispettare) tempi e costi
Serve Ingegneria e Qualita’ nel
Software
• Qualita’ nel Prodotto
• Qualita’ nel Processo
• Qualita’ nel Progetto
Ingegneria e Qualita’ sono i segni di una
Disciplina che matura
Hardware e Software come
prodotti industriali
Hardware
• Costa produrlo
• E’ prodotto da aziende
• Ha un ciclo di vita
• E’ materiale
• Replicarlo costa
Software
• Costa produrlo
• E’ prodotto da aziende
• Ha un ciclo di vita
• E’ immateriale
• Replicarlo non costa
Suggerimento 1 – Programmare
per Moduli
• La produzione hardware usa il concetto di modulo
• Un modulo ha un nome, un obiettivo, inputs ed
outputs
• Il modulo viene progettato, costruito, ordinato,
venduto, comprato, riusato, sostituito
• Il modulo viene integrato per fare ulteriori moduli
Costruendo programmi integrando
moduli, la qualità ed i costi dovrebbero
migliorare
Modulo
• Un modulo nasconde la sua realizzazione
(Decision hiding)
• Un modulo si può impilare ed annidare
A
B
Il modulo entra nel software con
il concetto di sottoprogramma
A
B
Caratteristiche di un Modulo
•
•
•
•
•
•
Ha un obiettivo chiaro e semplice
E’ indipendente da altri moduli
Le interfaccia sono documentate
Non è più grande di una pagina
Nasconde i dettagli realizzativi
L’algoritmo usato è semplice e documentato
Suggerimento 2 – Definire la
Qualità del Software
• Lo Standard ISO 9126 sulla Qualità del
Software
–
–
–
–
–
–
Funzionalità
Affidabilità
Manutenibilità
Portabilità
Efficienza
Usabilità
Suggerimento 3 – Definire un Processo
produttivo
Il Ciclo di Sviluppo Waterfall
•
•
•
•
•
•
•
Analisi
Progettazione
Programmazione
Test (Ricerca e correzione degli errori)
Documentazione
Installazione
Manutenzione
Qualità del Processo e ISO
9001/2000
• Standard ISO (Internazionale)
• In grado di certificare la qualita’ di un
processo
• Definisce due stati (Certificato/Non
Certificato)
• Usato a livello internazionale
• Obbligatorio per chi lavora per enti che
richiedono qualità certificata
Le difficolta’ di fare Software
• Analizzare, Progettare, Testare il progetto
con l’utente: DIFFICILE
• Programmare: RELATIVAMENTE
FACILE
Facciamo ancora errori di sintasssi, ma sono
banali rispetto agli errori concettuali
(Fonte: Frederick Brooks – No Silver Bullett)
Le Proprieta’ della Essenza del
Software
•
•
•
•
Complessita’
Conformita’
Cambiabilita’
Invisibilita’
Complessita’
Le entita’ software sono complesse per:
• la dimensione
• la mancanza di oggetti ripetuti
• la quantita’ enorme di stati
• la mancanza di scalabilita’
La complessita’ fa parte della
essenza, e determina...
•
•
•
•
•
•
•
•
Difficolta’ di comunicazione in un team
Errori nei prodotti
Esplosione nei costi
Ritardi nelle consegne
Difficolta’ nell’uso
Difficolta’ di manutenzione
Difficolta’ di apprendimento
Difficolta’ nella sostituzione del personale
Conformita’
• Non ci sono principi unificanti
• Il Software deve conformarsi ai voleri di
molte istituzioni umane
• Il software deve interfacciarsi a molti
sistemi
• Deve conformarsi perche e’ l’ultimo
arrivato o e’ ritenuto il piu’ malleabile
Cambiabilita’ - 1
• Il Software e’ sotto continua pressione per il
cambiamento
• Anche i prodotti tangibili cambiano, ma
meno frequentemente
• Il Software incorpora la funzione, che e’
cio’ che risente di piu’ del cambiamento
• Il Software e’ pensiero puro, infinitamente
malleabile
Cambiabilita’ - 2
•
•
•
•
•
Il Software di successo viene cambiato
L’utente lo prova in nuovi casi
L’utente vuole nuove funzioni
Il Software sopravvive all’hardware
Il Software e’ inserito in una matrice
culturale di leggi, usi, utenti, macchine,
situazioni che cambiano in continuazione
Invisibilita’
• Il Software e’ invisibile
• Gli oggetti sono visualizzabili, il Software
puo’ essere rappresentato da una
molteplicita’ di grafi sovrapposti
• Il Software e’ non visualizzabile
• Questo rende difficile la comunicazione tra
menti differenti
Se il Software è cosi’…
• Va fatto in maniera da essere il più semplice
possibile (Usabilità)
• Va fatto in maniera da essere cambiato il più
facilmente possibile (Manutenibilità)
L’Hardware non è il Software, ma alcune
idee sono trasportabili
Programmazione Strutturata
• Dijkstra:”…I have grown to regard a program as an ordered set of
pearls, a “necklace”. The top pearl describes the program in its most
abstract form, in all lower pearls one or more concepts used above are
explained (refined)… The pearl seems to be a natural program
module.
• Dijkstra:”…Sono cresciuto guardando a un programma
come a un insieme ordinato di perle, una collana. La perla
superiore descrive il programma nella sua forma astratta,
mentre in tutte le perle inferiori uno o più concetti usati
sopra sono spiegati (raffinati)…La perla sembra un modulo
naturale
Un programma è fatto di Moduli
• La struttura del programma deve essere ad
albero
• I costrutti di collegamento usati
devono essere
• Sequenza
• Selezione
• Ripetizione
• Il programma deve essere costruito
top-down per raffinamenti successivi
Ad Albero perché…
•
•
•
•
•
•
•
•
•
•
La struttura è più semplice
Ci sono meno scelte (nn-1 invece che 2n*n)
Costruito top-down (prima il padre, poi i figli)
Testato top-down (prima il padre, poi i figli)
Compreso top-down
Posso parallelizzare lo sviluppo e il test dei figli
Il programma nasce modulare con moduli annidati
La struttura è più semplice (niente più programmi spaghetti)
Il modulo padre chiama i moduli figli passando i parametri
Al modulo padre non interessa l’interno del modulo figlio
(decision hiding: Parnas)
I costrutti devono essere solo tre
•
•
•
•
•
•
•
•
Più semplice da capire
Più semplice imparare a programmare
E’ possibile (Teorema di Bohem-Jacopini)
Un ingresso-una uscita
Impilabili e annidabili
Leggibili dall’alto in basso-da sinistra a destra
Esprimibili con pseudocodice
Il goto è pericoloso (Dijkstra)
I costrutti
A
• Sequenza
– A
– B
• Selezione
B
Vero
A
Falso
P
B
– If (P) then
• A
– Else
• B
• Ripetizione
– While (P) A
Vero
P
A
Programma e modulo
• Il programma nasce per raffinamenti successivi
(Wirth)
• Ogni modulo si concentra sulla realizzazione del
proprio obiettivo
• Ogni modulo ha precondizioni e post-condizioni
(come trova il mondo e come lascia il mondo)
• Si rimandano le decisioni dettagliate ai livelli
successivi di raffinamento