La Programmazione Strutturata Uno stile di programmazione per la costruzione di programmi complessi...
-
Upload
giampaolo-cirillo -
Category
Documents
-
view
215 -
download
1
Transcript of La Programmazione Strutturata Uno stile di programmazione per la costruzione di programmi complessi...
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 GilletteNaur
Randell
Gries
1969 - Roma
Dijkstra Brinch Hansen Hoare
LampsonWirth
Randell
Perlis
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%
50%
Produzione
Manutenzione
Distribuzione dei costi del Software - 2
15%20%
40%
25% Analisi eProgettazione
Programmazione
Documentazione
Testing
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
Il modulo entra nel software con
il concetto di sottoprogramma
A B 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
• Sequenza– A– B
• Selezione– If (P) then
• A
– Else• B
• Ripetizione– While (P) A
A
B
P
P A
A B
Vero Falso
Vero
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