Nella scorsa lezione abbiamo visto che cosa è la programmazione e abbiamo notato che si può semplificare nella creazione di algoritmi.
L’astrazione da ogni linguaggio ci permette di dimenticarci per il momento le difficoltà implementative di ogni algoritmo e concentrarci solo sulla sua essenza.
Partiamo quindi dalla struttura di algoritmi veramente semplici.
Il più semplice tipo di algoritmo consiste in una semplice lista di istruzioni. Se per esempio vogliamo scrivere l’algoritmo per fare la pasta potremo scrivere:
- Metti l’acqua a bollire.
- Aspetta che l’acqua bolla.
- Mettere la pasta.
- Aspetta che sia cotta.
- Scola la pasta.
Questo è un algoritmo aciclico (ovvero privo di salti all’indietro, in poche parole di istruzioni ripetute più volte) e a flusso unico (ovvero tutte le istruzioni sono eseguite almeno una volta). E’ il modello di algoritmo più semplice.
Al lettore attento non sarà sfuggito però che ogni istruzione potrebbe considerarsi a sua volta come un algoritmo. Per esempio la (1) potrebbe diventare:
- Prendi la pentola.
- Riempila d’acqua.
- Accendi il fornello.
- Metti la pentola sul fornello.
E via dicendo. A sua volta anche “prendi la pentola” potrebbe essere scomposto.
Ma fino a che punto dobbiamo espandere le operazioni di un algoritmo?
La risposta in verità dipende dal linguaggio che si userà per realizzare l’algoritmo. Se vogliamo eseguirlo in assembly dovremmo espanderlo ai massimi livelli mentre se vogliamo farlo in Java avremo bisogno di un minore dettaglio.
E’ buona norma però, quando si scrivono algoritmi, partire sempre da un livello di dettaglio basso e scomporre via via i sotto-problemi risultanti in altri sotto-algoritmi. Un po come abbiamo fatto per l’esempio della pasta. Questa segnatela perché all’atto pratico è una delle cose più potenti che un programmatore possa fare: la modularizzazione (di cui parleremo in seguito)
L’istruzione (2) “Aspetta che l’acqua bolla.” scomposta rivela proprietà che non avevamo visto nell’algoritmo generale. Scomposto infatti assume questa forma:
- Guarda l’acqua nella pentola.
- Se bolle termina, altrimenti torna a (1).
Come si nota questo è un algoritmo ciclico (dei più semplici pergiunta) in quanto presenta una condizione che ci fa tornare indietro ad un istruzione precedente. Questo è quindi un ciclo.
Quindi il nostro algoritmo aciclico di partenza in realtà nasconde un sotto-algorimto ciclico.
Ora ci chiediamo qual’è il metodo più efficace per rappresentare un algoritmo? Il metodo forse più conosciuto è quello dei diagrammi di flusso (per approfondire vai qui)
Il diagramma di flusso è quindi una rappresentazione per via grafica molto evidente di quello che fa l’algoritmo. Lo svantaggio che lo rende inapplicabile in quasi tutti i casi pratici è che è inadatto per algoritmi vasti e complessi in quanto stare dietro a frecce e blocchi sparse per una superficie troppo vasta più che aiutare disorienta.
A questo punto ci viene in aiuto lo pseudo-codice.
Lo pseudo-codice in realtà non è molto dissimile dalla lista di istruzioni che ho usato per rappresentare l’algoritmo della pasta. In poche parole è un algoritmo espresso in linguaggio naturale impostato in modo tale da somigliare a un listato di codice.
Non c’è una tecnica universale per lo pseudo-codice, ognuno è libero di trovare il suo stile a patto che il risultato sia comprensibile e chiaro ai più. Per esempio (2) “Aspetta che l’acqua bolla.” diventerebbe una cosa del tipo:
algoritmo AspettaAcquaBolle() :
Finchè <l’acqua NON bolle> :
<Guarda L’acqua>
Mentre l’algoritmo del fattoriale diventerebbe:
algoritmo Fattoriale(Numero Intero N) :
Se N=0 :
restituisci 1
altrimenti :
restituisci N * Fattoriale(N-1)
Come vedete il risultato è facilmente interpretabile e la struttura permette una conversione piuttosto semplice in un linguaggio di programmazione vero e proprio. Si tratta cioè di tradurre riga per riga lo pseudo-codice in codice.
Nella prossima lezione parleremo ancora degli algoritmi introducendo concetti un po più complessi che per ora vedremo solo in modo superficiale ma che, volendo approfondirò più avanti.
Un buon articolo. 🙂