Coding, pattern e pensiero computazionale

coding, pattern e pensiero
computazionale
Giuseppe Alessandri
PNSD – Tolentino
2017

indice
• Tecnologie
• Tecnologie e didattica
• Approcci imperativo e a eventi al coding e
– pattern monoagente-deliberativo
– pattern multiagente-deliberativo
– pattern monoagente-reattivo
– pattern multiagente-reattivo
• Scratch junior
• Pensiero computazionale e algoritmi
• Narrazione e Pensiero computazionale
• Approccio dichiarativo al coding: Prolog

una definizione (B. Arthur)
“La tecnologia è un mezzo per soddisfare uno scopo
umano. […] In quanto ‘mezzo’, la tecnologia può essere un
apparecchio fisico (un motore diesel, un frigorifero), un
processo (un processo di filtrazione nell’ingegneria chimica
o il processo risolutivo per una equazione di secondo grado,
eventualmente codificato in algoritmo), un metodo (il
metodo adottato per lo sviluppo di un algoritmo per il
riconoscimento vocale, la modalità di progettazione
didattica, ..). […]; può essere materiale […] oppure
immateriale […]. Comunque è sempre un mezzo creato per
soddisfare un fine umano”.
Cos’è la tecnologia
(Arthur)
Alessandri G., Tecnologie autonome nella didattica, verso la robotica educativa, Morlacchi, Perugia, 2013

Spesso le tre tipologie si integrano:
• un processo sviluppato con un determinato
metodo;
• un processo che ha bisogno di un apparecchio
per essere eseguito (un algoritmo);
• un processo, sviluppato con un certo metodo,
che si realizza con un determinato
apparecchio (ancora il caso di un algoritmo).
Cos’è la tecnologia
(Arthur)

Tecnologie e didattica
• Il senso del loro utilizzo oscilla in un continuo che va da forme
di sostegno alle varie discipline, facilitandone e migliorandone
l’apprendimento, ad approcci che accentuano il carattere di
autonomia delle stesse tecnologie

Tecnologie di sostegno possono suddividersi in tecnologie per
presentare e tecnologie per facilitare.
• La caratteristica fondamentale delle prime è la presenza di
un elemento essenziale quale il video, attraverso il quale
l’utente riceve informazioni, ma può anche presentarne; un
esempio è il web.
• Nel web di oggi possiamo individuare i siti vetrina (è
prevalente la presentazione) e siti officina (è prevalente la
discussione, la collaborazione, la costruzione). Esempi dei
primi sono i siti degli utenti e, fra questi, quelli di forte
concentrazione informativa come i portali. Esempi del
secondo caso sono i siti per le comunità (di aiuto, di
discussone, di pratica, …), siti per la formazione,
applicazioni del web 2.0.

• Tecnologie per facilitare. Sono tecnologie che si pongono fra lo
studente che apprende e l’oggetto di studio per facilitare il processo
di apprendimento introducendo delle rappresentazioni che possano
aiutare nella comprensione. Un esempio di tale tecnologia è la
simulazione che può essere considerata una ricostruzione di
qualche segmento della realtà rappresentandone un modello nella
forma e una riproduzione delle funzionalità. Il tentativo è quello di
far conoscere parti del mondo ricreandoli, in modo artificiale, e
dando all’utilizzatore la possibilità di interagire con gli aspetti che
sono riprodotti, e osservando le conseguenze delle azioni frutto
delle decisioni prese.
• Altri due esempi sono i DGS (Dynamic Geometry Software; es.
Geogebra) e i CAS (Computer Algebra System); entrambi si
riferiscono all’insegnamento della Matematica.

• Tecnologie autonome. Sono quelle che permettono di sviluppare
esperienze che altrimenti non sarebbe possibile svolgere. Il loro valore
non sta nel presentare, nel miglior modo possibile, la fruizione di
mondi fittizi che realizzino il reale attraverso il digitale, ma nel
costruire questi mondi che possono essere realizzati attraverso propri
linguaggi e regole di queste tecnologie. Esse disegnano percorsi di
apprendimento consapevole nei domini che sono loro tipici e
propongono metodologie di lavoro attive e autonome.
• Le pratiche didattiche che si possono realizzare mediante tali
tecnologie delineano:
– approcci maggiormente orientati alla soluzione di problemi;
– l’assimilazione di metodologie di lavoro in grado di migliorare la
significatività del processo di apprendimento (attraverso la
realizzazione di artefatti)

I tratti fondamentali dell’autonomia sono rintracciabili:
• in una maggiore sovranità rispetto alla lezione del
docente; non sono, cioè, al servizio di un itinerario già
tracciato; non sono pacchetti chiusi, o anche simulazioni
già fatte, ma sono strumenti che gli studenti possono
utilizzare per costruire conoscenze nei diversi settori
disciplinari; essi sperimentano e scoprono e formalizzano
leggi dai loro esperimenti;
• in un metodo di lavoro che privilegia l’azione;
• nella necessità di utilizzare un loro linguaggio.

Le tecnologie autonome si sostanziano nel
pensiero computazionale e nel coding
Come visto nella mappa del pensiero
computazionale, possiamo individuare diversi
approcci nella programmazione; in questo
contesto ci si riferisce a quello imperativo e a
quello a eventi e, successivamente, a quello
dichiarativo

• Approccio imperativo e a eventi

• In via prioritaria è bene conoscere il significato
di modello e, in particolare, i formalismi più
comuni per la sua rappresentazione (nel
nostro caso i linguaggi grafici e i linguaggi di
programmazione).

Si possono individuare quattro modalità di costruzione dei programmi:
monoagente, multiagente, deliberativa e reattiva:
• modalità monoagente: si riferisce a realizzazioni che si sviluppano con una
sola programmazione; l’applicazione risiede in un unico nodo elaborativo
che vive in un solo agente;
• modalità multiagente: le applicazioni risiedono su più nodi elaborativi
(elaborazione distribuita) e vivono in più agenti; si hanno, cioè, diverse
programmazioni che svolgono operazioni differenti nell’ambito di una
macro–applicazione;
• modalità deliberativa: indica la possibilità di sviluppare una applicazione
attraverso una programmazione predeterminata, rispettata passo dopo
passo, isolata rispetto all’ambiente circostante;
• modalità reattiva: in una applicazione è possibile interagire con
l’ambiente della stessa e con l’esterno; gli eventuali agenti possono
interagire fra di loro. Il suo sviluppo non è rigidamente predeterminato,
ma può tener conto delle interazioni che si sviluppano.

• Sistemando le quattro modalità sui vertici di un
diagramma si hanno quattro poli: deliberativo,
reattivo, monoagente, multiagente; di
conseguenza è possibile avere quattro
combinazioni che rappresentano quattro pattern
di riferimento per realizzare applicazioni:
monoagente-deliberativo (imperativo) (a),
multiagente-deliberativo (imperativo) (b),
monoagente-reattivo (a eventi) (d), multiagente-
reattivo (a eventi) (c) .

Coding, pattern e pensiero computazionale

• Nel quadrante a (pattern monoagente–deliberativo) si ha una unica
programmazione che impone all’unico agente dei comportamenti
prestabiliti e dettati dall’applicazione; questa non prevede
interazione con l’ambiente e con l’esterno;
• nel quadrante b (pattern multiagente–deliberativo) si individuano
applicazioni con più agenti guidati da programmazioni che non
permettono interazioni fra agenti, con l’ambiente e con il mondo
esterno.
• nel quadrante d (pattern monoagente–reattivo) le applicazioni sono
costruite intorno a un unico agente che può interagire con
l’ambiente e con il mondo esterno;
• nel quadrante c (pattern decentralizzato–reattivo) si hanno più
agenti; ciascuno, con la propria programmazione, può interagire
con gli altri, con l’ambiente e con l’esterno.

Molteplici sono gli ambienti per la composizione di programmi ed è
possibile individuare una distinzione:
• fra quelli che permettono la scrittura del codice in un ambiente
testuale
• e quelli che mettono a disposizione un ambiente dove inserire le
istruzioni del linguaggio (in genere prelevabili da elenchi già
predisposti) e vicino un ambiente grafico ove vivono gli agenti
dell’applicazione.
Oggi, generalmente, le applicazioni, sviluppate secondo i dettami di uno
qualunque dei pattern presentati in precedenza, vivono in ambienti del
secondo tipo. Nelle figure seguenti sono riportati quelli di Scratch e di
Snap!

Dall’analisi al programma
Dall’analisi al programma: percorso che porta dalla individuazione e formulazione di un
problema alla scrittura del programma relativo.
• Definiamo come programma un insieme di istruzioni e dati, finalizzato a dei compiti ben
precisi e delimitati. Il programma viene costruito dall’uomo e viene eseguito dal computer e,
perciò, deve essere scritto utilizzando un linguaggio che l’elaboratore comprende. Per
linguaggio di programmazione intendiamo un insieme di istruzioni e di regole che definiscono
le modalità con le quali le stesse istruzioni ed i dati possono essere inseriti in un programma.
• I passi fondamentale del percorso sono:
a) analisi:
-individuazione dei dati sui quali il programma deve “lavorare”;
-individuazione del procedimento risolutivo, che generalmente prevede un
frazionamento, per passi successivi, del programma in parti via via più semplici;
b) costruzione del programma e relativa codifica utilizzando un linguaggio di
programmazione;
c) prove del programma, individuazione degli errori;
d) feed back.

Nel prosieguo vengono presentati i quattro
pattern: monoagente-deliberativo,
multiagente-deliberativo, monoagente-
reattivo, multiagente-reattivo.
Nell’insieme rappresentano un percorso
che il docente potrebbe seguire nel proprio
itinerario di alfabetizzazione sul pens.
comp. e sul coding.

• Non vuole essere un itinerario da proporre
immediatamente in aula con gli studenti, in
special modo per quelli della primaria ma,
anche, della secondaria di primo grado.
• Per costoro è meglio iniziare con un approccio
più light che preveda direttamente un impatto
con il linguaggio (preferibilmente Scratch)
impostando semplici programmi e
procedendo per prove ed errori.

• Tuttavia il docente deve essere consapevole
che il suo punto di arrivo dovrà essere l’aver
“convinto” i propri studenti che occorra,
dapprima, analizzare il problema, sviluppare
un bozza di modello risolutivo (attraverso
opportuni diagrammi, come si vedrà),
individuare il pattern che pensa possa essere
idoneo e quindi passare alla stesura del
programma.

pattern
• pattern monoagente-deliberativo
• pattern multiagente-deliberativo
• pattern monoagente-reattivo
• pattern multiagente-reattivo

pattern monoagente–deliberativo
• Il primo passo del percorso è rappresentato
dall’analisi del problema che si sviluppa
attraverso l’individuazione dei dati con i quali
operare ed il relativo procedimento risolutivo. I
dati possono essere iniziali, cioè conosciuti e
consegnati in ingresso al programma, dati creati
dal procedimento e dati in uscita. Il procedimento
può consistere in una scomposizione del
problema in parti secondo il metodo top down. Il
problema viene suddiviso in sottoproblemi, i
quali possono anch’essi essere frazionati
ulteriormente in altri sottoproblemi;

• il procedimento avanza fino alla individuazione di parti
non più scomponibili. Queste sono i nuclei essenziali
dello sviluppo del programma; sono, in genere, chiamate
procedure. Si passa, quindi, allo sviluppo delle stesse
utilizzando opportuni formalismi, ad esempio pseudo–
codifica o diagramma a blocchi; successivamente si
assembla il tutto nel procedimento finale, lo si traduce
nel codice del linguaggio utilizzato, lo si esegue
all’elaboratore. Spesso si evita il passaggio della scrittura
in pseudo–codifica (o diagramma a blocchi) e si scrivono
le procedure direttamente nel linguaggio di
programmazione scelto.

• Quindi il procedimento si sviluppa, attraverso
raffinamenti successivi, da una struttura generale del
problema alla formulazione finale del programma che
verrà fatto eseguire dall’elaboratore. La progettazione
nasce da prime ipotesi risolutive e si sviluppa lungo
successivi momenti nei quali si progettano nuovi
itinerari. La progettazione termina alla fine della sua
attuazione.
• Il procedimento di analisi si articola attraverso le
strutture di sequenza, confronto, ripetizione.
• Esistono diversi strumenti per formalizzare il
procedimento di analisi; presentiamo qui i diagrammi
di Jackson.

sequenza
Si legge “x è una sequenza di a, b, c”

confronto
Si legge: “x è a se vale cond 1, x è c se vale cond
2”.

ripetizione
Si legge “x è una ripetizione di b, per n volte”

• Attraverso corrette combinazioni di tali strutture è possibile sviluppare
procedimenti risolutivi.
x è una sequenza
— di a, che è una sequenza di m e n,
— di b, che è una ripetizione di z per 5 volte,
— di c, che è w se vale c1, y se vale c2.

• Tale diagramma si legge dall’alto verso il basso e da sinistra
verso destra; m, n, z, w, y rappresentano procedure.
• Una volta giunti a questo livello di rappresentazione del
problema, si sviluppano le varie procedure nella forma di
una pseudo–codifica o di un diagramma a blocchi e, quindi,
si codificano le istruzioni secondo il linguaggio scelto; si
‘passa’ poi il programma codificato all’elaboratore che
provvederà a eseguirlo.
• Realizziamo ora due applicazioni seguendo il procedimento
sopra delineato:
• a) costruire una casa senza finestre (Esempio 1).
• b) costruire una casa con finestre (Esempio 2).

Esempio 1: costruire una casa senza finestre con il corpo di 100 punti di lato ed il tetto
di 120 punti.
Si disegni su carta il seguente schema:
Analizzando si può vedere che per rappresentare una casa occorre costruire una
facciata e un tetto; la facciata è un quadrato e il tetto un triangolo; quindi il problema
è scomponibile in due procedure:
facciata, tetto.
Con i diagrammi di Jackson:
A questo punto si realizzano le varie procedure scrivendo il relativo codice in pseudo–
codifica e quindi in Snap!, Scratch.

Esempio 2: costruire una casa con finestre.
Si disegni su carta il seguente schema:
Analizzando si può vedere che per rappresentare una casa si possono utilizzare un
quadrato ed un triangolo (che costituiscono, nell’insieme, la casa senza finestre), due
quadrati per le finestre ed un rettangolo come porta di ingresso. Ma la casa senza
finestre è stata già costruita e la relativa procedura è disponibile, quindi:

Possiamo scrivere una versione equivalente del diagramma precedente,
costruendo una procedura finestre, che contiene, al suo interno, le due
procedure finestra:

Come esempio di utilizzo di una pseudo–codifica e dei diagrammi a blocchi,
sviluppiamo la procedura quadrato, che rappresenta il corpo della casa.
inizio
avanti 100
destra 90
avanti 100
destra 90
avanti 100
destra 90
avanti 100
destra 90
fine

Ottimizzato
inizio
ripeti 4 volte
avanti 100
destra 90
fine
Fine
(struttura di ripetizione)
inizio
ripeti 4 volte
avanti 100
destra 90
fine

Esempio di struttura di
controllo; in base al valore di
un numero si costruisce una
casa con o senza finestre

Esempio di struttura di
ripetizione; si deve ripetere il
procedimento precedente
per dieci volte; per ogni ciclo,
in base al valore di un
numero, si costruisce una
casa con o senza finestre
ripeti
# 10 volte
acq. numero

Area SPRITE
STAGE
Area SCRIPT
Area
ISTRUZIONI
Snap!
(Sito ufficiale di Snap)
Snap! È la versione 4.0 di BYOD (Build Your Own Blocks).

• Per fare la prima conoscenza di Snap! Si
utilizza il programma per la realizzazione della
casa senza finestre; dapprima senza procedure
e poi con procedure.
• Manuale Snap!
• Negli esempi seguenti, per vedere il codice
Snap! occorre un click sul simbolo
in alto a destra

con procedure
Snap!
senza procedure
mono_deliberativo_1 mono_deliberativo_2

Snap!
con procedure
con parametri
mono_deliberativo_3
mono_deliberativo_4

pattern multiagente-deliberativo
• Si parla di pattern multiagente quando le applicazioni
risiedono su più nodi elaborativi (elaborazione
distribuita). Le programmazioni possono esplicitarsi
nelle azioni di agenti che agiscono in un apposito
ambiente e hanno, teoricamente, la possibilità di
interagire fra loro, con l’ambiente e con l’esterno;
tuttavia in questo caso (pattern multiagente-
deliberativo) tutto ciò è impedito in quanto sono
deliberatamente guidati nella loro vita “di comunità”. Il
deliberare i loro comportamenti significa che i loro
movimenti, le loro azioni sono etero-dirette dall’utente
attraverso le programmazioni che ha associato ad essi.

• Riprendendo l’esempio precedente (costruzione di una
casa), possiamo implementare la costruzione del portone e
demandarlo a un secondo sprite; è possibile ipotizzare una
distribuzione dei compiti fra diversi agenti, invece nella
situazione già analizzata esisteva un unico agente con
un’unica programmazione.
• Con una soluzione decentralizzata, è possibile impostare un
procedimento che preveda un agente che costruisce la
facciata ed il tetto della casa, un secondo che si interessa
della costruzione del portone (e, volendo, un terzo che
modella le finestre). È ovvio che si potrebbe operare in altri
modi, impegnando un numero diverso di agenti e
assegnando loro compiti diversi.

Snap!
1° sprite disegna la facciata e il tetto 2° sprite disegna il portone
multi_deliberativo_1

pattern monoagente-reattivo
• Il pattern monoagente-reattivo introduce al
modo di costruire applicazioni di coding
secondo una programmazione orientata agli
eventi. Si ha un unico nodo elaborativo,
tuttavia la programmazione si sviluppa in
interazione con l’ambiente circostante (interno
ed esterno). L’applicazione si esplicita nelle
azioni di un agente che non vive in una bolla
isolata, ma interagisce con l’ambiente interno
ed esterno.

• Un programma in Snap!, generalmente, si sviluppa
attraverso la vita di diversi agenti chiamati sprite, a
ciascuno dei quali è possibile associare più script (insieme
di istruzioni dedicato a compiti specifici). Per simulare il
pattern che stiamo analizzando, tuttavia, dobbiamo
limitarci alla gestione di un solo sprite che interagisce con
l’ambiente nel quale vive. Ciascuno script ha un hat block in
testa che stabilisce quando deve essere eseguito. L’hat
block dà l’avvio all’evento rappresentato dalla sequenza
delle successive istruzioni (blocchi). Generalmente il nome
di un hat block inizia con la parola “quando”. Nei precedenti
esempi abbiamo sorvolato sull’uso dell’hat block per non
introdurre elementi di “reattività” in contesti deliberativi; si
ricordi, comunque, che tale blocco è indispensabile.

• In genere uno script inizia con un blocco hat con la
parola quando (when) e l’azione che lo avvia, a indicare
quando deve andare in esecuzione. Fino ad ora
abbiamo utilizzato l’hat block
in questo caso quando si clicca sulla bandiera verde, in
alto a destra nell’interfaccia di Snap! si avviano gli
script che fanno iniziare ad agire gli sprite (nel caso
multiagente, altrimenti un solo sprite).

Nell’esempio seguente, abbiamo quattro script; quello con:
• hat block “quando si clicca su bandiera verde”, permette
l’avvio del programma e fa spostare lo sprite al punto di
coordinate 0,0;
• hat block “quando si preme il tasto spazio”, fa avanzare lo
sprite di dieci passi (punti) sullo schermo (tenendo premuto
la barra spazio, lo sprite si muove costantemente in avanti);
• hat block “quando si preme il tasto freccia su” lo sprite
ruota di 90 gradi verso sinistra;
• hat block “quando si preme il tasto freccia giù”, lo sprite
ruota di 90 gradi verso destra.

• Ovviamente i singoli script possono avere una
struttura più complessa; ad esempio
nell’evento collegato alla pressione della barra
spazio, nella figura seguente, si impone allo
sprite di tornare indietro di dieci passi (punti)
se si incontra il bordo della finestra dove si
sviluppa il programma.

Differenza fra pattern deliberativo e pattern reattivo nel caso di uno sprite che deve
attraversare il seguente labirinto

• Approccio deliberativo:
l’applicazione non sviluppa
alcuna interazione con
l’ambiente, escludendo quella
per l’avvio, e si sviluppa facendo
procedere allo sprite un
percorso predeterminato da
rilevazioni di distanze,
effettuate in fase di costruzione
dello script, e riversate nelle
istruzioni dello stesso.

Approccio reattivo
• L’applicazione (figura seguente), si sviluppa attraverso quattro script
che gestiscono quattro eventi che permettono:
• l’avvio con il posizionamento iniziale dello sprite;
• la pressione sulle frecce, a destra e a sinistra, per far ruotare lo
sprite, a destra o a sinistra, di cinque gradi (tenendo premuta la
freccia a lungo si potrà far ruotare lo sprite dell’angolo che si vuole);
• il movimento dello sprite lungo il percorso: quando lo sprite tocca il
colore nero, torna indietro di 20 passi, quindi l’utente dovrà farlo
ruotare in modo opportuno a destra o a sinistra; quando lo sprite
incontra il bordo (a fine itinerario) viene ricollocato nella posizione
iniziale.

Approccio reattivo
Snap!(mono_reattivo_3)
l’essere reattivo dello sprite è evidenziato nei momenti di contatto con il bordo
nero della pista e con il bordo dell’ambiente nel quale agisce e di risposta alle
azioni dell’utente.

modello per pattern
monoagente-reattivo

pattern multiagente-reattivo
• Diversamente dal precedente, il pattern decentralizzato-reattivo individua
animazioni nelle quali possono vivere più sprite/agenti e permette
interazioni fra loro e con gli ambienti esterno e interno.
• Tutto ciò permette, indifferentemente, un agire autonomo e indipendente
dall’azione degli altri sprite, oppure una collaborazione fra essi.

Snap!(multi_reattivo_1)
• Nella seguente applicazione (Figura 6.2) vivono due
sprite, chiamati “sprite1” e “sprite2”, che non
interagiscono fra loro, ma solo con l’ambiente interno
(il bordo).

• È possibile farli interagire fra loro e con l’ambiente
interno (il bordo).

• Altresì, è possibile far cooperare i due sprite sulla scena
del racconto di una storia, di un gioco, di una
simulazione. Uno sprite potrebbe invitare un altro a
eseguire delle azioni. In una storia potrebbero costruire
un dialogo, alternandosi in modo sincronizzato. È
possibile realizzare una sincronizzazione inserendo i
messaggi di uno sprite in una sequenza temporale e
quelli dell’altro in un’altra sequenza che non si
sovrapponga alla prima e, nell’insieme, le due
sequenze restituiscano un colloquio corretto fra i due
protagonisti. Tuttavia esiste una diversa modalità che
prevede che i due sprite si passino la parola (figura
seguente)

1
2
3
4

• L’esecuzione degli script avviene, secondo la numerazione visualizzata in figura 6.4, attraverso lo scambio
dei seguenti “ciao”, “come”, “dove”. In particolare:
• l’esecuzione si avvia con un click sulla bandiera verde che lancia lo script n.1 del primo sprite (sprite1), che
– visualizza, sul video “Ciao, io sono Michele, tu chi sei?”, per 3 secondi;
– quindi invia a tutti gli sprite il messaggio “ciao” tramite il blocco di broadcast “invia a tutti ciao e
attendi”;
• il messaggio viene ricevuto solo dal secondo sprite (sprite2) attraverso lo script n. 2, che
– visualizza sul video “Ciao io sono Anna; come stai, che fai?” , per 3 secondi;
– quindi invia a tutti il messaggio “come”;
• il messaggio viene ricevuto dal primo sprite attraverso lo script n. 3, che
– visualizzerà sul video “Io sto bene; sto andando a scuola, andiamo insieme?” , per 3 secondi;
– quindi invia a tutti gli sprite il messaggio “dove”;
• questo viene ricevuto dal secondo sprite attraverso lo script n. 4, che
– visualizzerà “va bene, andiamo”, per 2 secondi.
• Quindi l’esecuzione termina.
• In questa applicazione solamente uno sprite alla volta, alternativamente, ha uno script da eseguire quando
viene inviato un messaggio di broadcast.
• Le parole “ciao”, “come”, “dove”, sono arbitrarie e sono scelte da colui che costruisce l’applicazione.

anna
sente
messaggio
“ciao”
eseguire
Invia messaggio:
Ciao! io sono Anna, come stai, che fai?
anna
sente
messaggio
“andiamo”
eseguire
Invia messaggio:
Va bene, andiamo

Scratch Junior
(https://www.scratchjr.org/index.html)
• È un ambiente visuale ed è adatto per sviluppare
esperienze di coding con bambini dai cinque ai
sette anni. Ha una interfaccia semplificata
rispetto alle versioni di Scratch e di Snap!. Gli
sprite sono chiamati character. Mantiene la
struttura di questi ambienti di livello superiore in
merito alla creazione di sfondi e/o nuovi stage,
alla modifica del character, alla registrazione di
audio e, infine, al raggruppamento di comandi.
• Inizialmente disponibile solo su iPAD, ora anche
su sistemi Android.

Un percorso
Utilizzando Scratch Junior, un possibile itinerario può essere quello presentato in precedenza con
opportune modifiche:
• Nel pattern mono-deliberativo potranno essere trattati i seguenti argomenti:
– familiarizzazione con l’ambiente di Scratch Jr;
– uso dei comandi di movimento e di gestione del character ;
– composizione di sequenze di azioni e concetti di istruzione e programma ;
– azioni ripetitive .
• In quello multi-deliberativo, verranno inseriti più character, tuttavia non interagenti fra loro e
con l’ambiente per introdurre al significato di decentralizzazione.
• Infine nei pattern mono-reattivo e multi-reattivo, si introduce il concetto di evento e si
analizza come, attraverso questo, sia possibile gestire le interazioni di un character e di più
character fra loro e con l’ambiente

Una considerazione [1]
• In linea generale, senza cioè puntare l’attenzione sulla
costruzione di applicazioni, l’attrazione che i piccoli sentono
verso i dispositivi mobili è dovuta alla possibilità di una
interazione tattile sullo schermo.
• Gli oggetti sono presi, spostati, eliminati e tutto avviene
attraverso il tatto. Diversamente da altri dispositivi digitali,
quelli mobili eliminano gli strumenti di input che
permettono di trasformare le intenzioni degli utenti,
impartite con opportune combinazioni di tasti o inclinazioni
e orientamenti di un input dedicato, in possibili comandi da
impartire. Si elimina questo passaggio intermedio e le
azioni divengono immediate interazioni con ciò che avviene
sullo schermo; l’azione è collocata sullo sviluppo della
narrazione sul video.

Una considerazione [2]
• Se l’apprendimento è dettato dall’azione sugli oggetti, in questo
caso ciò si realizza attraverso l’eliminazione di strumenti di
intermediazione.
• Gli ambienti visuali, nel caso di costruzioni attraverso il coding,
riducendo al minimo la necessità di scrivere codice e dando la
possibilità di agire per mezzo del tatto sugli oggetti astratti, possono
facilitare la costruzione di applicazioni.
• In questo caso possiamo “proprio parlare di costruzione”: i mattoni
dell’artefatto programma sono spostati e portati agendo
manualmente fra depositi e stage.
• Le stesse istruzioni hanno, nella loro veste grafica, degli ancoraggi
che permettono loro di collegarsi l’una con l’altra, quasi a
materializzare il significato astratto di programma in una costruzione
fisico-grafica reale.

Pensiero computazionale e algoritmi
• Un algoritmo è un insieme di istruzioni finalizzato alla soluzione di un
compito. Si ricorre spesso all’esempio di una ricetta per chiarirne il
significato. Può essere utile, in quanto identifica da un lato un processo e
dall’altro una serie di valori che vengono utilizzati nel processo. L’esempio
è riferito ad una ricetta per fare biscotti:
• Tale esempio può far capire il significato di algoritmo come insieme di
azioni finalizzato a un certo scopo. Chiarisce anche che un programma
agisce su “qualcosa”, in questo caso gli ingredienti, senza i quali non è
possibile fare la torta. Introduce anche al significato di azione che si ripete:
l’istruzione 3 va ripetuta sei volte.

• Realizzare programmi senza costruire un
computational thinking significa fare coding
secondo un mechanic learning by doing piuttosto
che secondo un learning by making. Chi
costruisce programmi deve essere consapevole
di concetti quali azioni ripetitive, condizionali,
algoritmo, pattern, però deve essere in grado di
agirli globalmente e non localmente. Spesso un
learning by doing diviene un procedere per prove
ed errori che interviene in punti precisi del
programma tralasciando la logica globale.

• Occorre invece riuscire a generalizzare le proprie
soluzioni, a concepire pattern e a essere
consapevoli delle operazioni di astrazione che il
costruire programmi comporta. In definitiva non
si tratta di usare regole di coding ma si tratta di
costruire esperienze significativa attraverso il
coding. Costruire programmi deve significare
sviluppare attività autentiche e non solamente
imparare codice; significa usare le proprie
capacità nell’articolare e arricchire le abilità
logiche di pensiero possedute.

• Costruire programmi è una attività di pensiero
che porta a riflettere sul proprio modo di
pensare, di analizzare e risolvere problemi;
non è quindi fine a se stessa e solamente
orientata alle cosiddette “discipline
scientifiche”, ma investe un livello che sta
sopra i contenuti disciplinari, investe la
capacità di ciascuno di astrarre, di
generalizzare.

• Il docente dovrebbe invitare lo studente alla realizzazione
di modelli di progettazione che possano essere riutilizzati,
anche attraverso delle modifiche, in situazioni diverse.
• Un patrimonio di pattern da riutilizzare permette a chi li
costruisce di affinare le proprie capacità e a chi ne fruisce di
implementare quelle di riconoscimento di similarità, quindi
di generalizzazione. Significa vedere la propria soluzione
non come fatto a se stante, ma come appartenente a una
categoria che si riesce a cogliere nei suoi aspetti
significativi. Significa saper condurre azioni, su un piano
puramente cognitivo, di riconoscimento di modelli, di
controllo e di modifica, se necessario, per un proficuo
utilizzo nel contesto che si sta gestendo.

Narrazione e computational thinking
Bruner (1986) scrive che ci sono due tipi fondamentali di pensiero
umano che sono in corrispondenza con due tipi di comunicazione:
narrativo e paradigmatico.
• La modalità narrativa è utilizzata comunemente per descrivere le
situazioni di vita nella ricchezza del loro sviluppo in un contesto;
esplicita un pensiero e lo narra, racconta di situazioni umane;
• la modalità paradigmatica descrivere concetti e situazioni, cercando
di astrarre dal contesto.
Sono due modi di ordinare l’esperienza e di costruire la realtà; il primo
è un racconto, il secondo è una descrizione ben costruita di un
argomento. La verifica li differenzia: nel secondo attiene a «processi
che permettono di stabilire una prova formale e empirica»; nel primo
«si stabilisce la più vicina approssimazione alla verità. Gli argomenti
devono convincere per la loro verità» (Balbi J., Cimbolli P., 2009, pag.
241).

• Il pensiero paradigmatico è tipico del
ragionamento scientifico: il pensiero segue una
logica formale, che procede per inferenze; è
finalizzato alla categorizzazione ed opera per
astrazione.
• Quello narrativo viene impiegato
prevalentemente nell'ambito di discorsi e
ragionamenti quotidiani; è dentro ai contesti che
forniscono categorie di senso e permettono di
interpretare fatti. I suoi enunciati sono particolari,
locali, dipendono dall’orizzonte interpretativo.

• Il mondo paradigmatico è popolato da tentativi di
costruzione scientifica della realtà, da modelli che riescano
a spiegare e a verificare la veridicità delle stesse
spiegazioni. I suoi processi sono caratterizzati da passi logici
dove vige categorizzazione e generalizzazione espressi da
procedure formali.
• Il mondo narrativo persegue una costruzione narrativa,
appunto, della realtà; non esplicita bisogni di prove e
dimostrazioni. I suoi processi sono caratterizzati da
soggettività che si sviluppa in storie che si dilatano e si
comprimono nello spazio e nel tempo, seguendo bisogni di
focalizzazioni per esplicitare valori, emozioni, capaci di
risuonare nelle coscienze (Scaratti G., Grazzani Gavazzi I.,
1998, pp. 310, 311).

• Il mondo della scuola è un terreno fertile per il
pensiero narrativo e spesso si sviluppano esperienze
vissute su palcoscenici dove recitano gli studenti e che
prevedono la realizzazione di un video per memoria
storica, ma anche come forma elementare di
drammatizzazione filmica.
• Sarebbe possibile realizzare delle storie facendole
vivere nel mondo digitale. Ambienti software
opportuni permetterebbero di unire esperienze di
narrazione con quelle di computational thinking. La
narrazione con costruzione di una storia digitale
(digital story telling) può essere un ideale terreno per
esercitare il c.t.

• Uno sfondo interpretativo della convivenza fra pensiero
paradigmatico e pensiero narrativo di Bruner può essere un digital
tale.
• Lo sviluppo del codice può rappresentare un esempio di pensiero
del primo tipo e lo sviluppo della storia un esempio del secondo.
• Nel codice possiamo rintracciare le caratteristiche del pensiero
paradigmatico quali l’astrazione, il formalismo per sviluppare
modelli;
• nello sviluppo della storia tutte le caratteristiche dell’altro: i
significati ricostruiti e trasmessi dall’autore; tutte le focalizzazioni su
particolari temi e aspetti, attraverso opportune scelte degli spazi e
dei tempi. I due approcci convivono nello stesso ambito e il primo
spiega il secondo in modo formale.

• In particolare un ulteriore riferimento teorico di
lettura può essere il richiamare due aspetti
individuabili in una storia (Kermode F., 1981): la
fabula e il sjuzet; la fabula è il senso della storia e
lo sviluppo generale, il sjuzet e la sua
realizzazione. Il sjuzet si interfaccia con il coding
che rappresenta la trama che permette lo
sviluppo della storia che vive in una fabula. La
fabula esprime il tema fondamentale e i valori
che vivono nella scansione del racconto che si
sviluppa poi lungo le tappe del sjuzet.

La progettazione complessiva si sviluppa nelle seguenti fasi:
• individuazione della fabula (ovvero il mondo dei valori nel
quale si sviluppa la storia);
• individuazione del sjuzet: le modalità di interazione degli
attori in relazione ai temi della storia, nelle varie scene;
• progettazione del programma che permette lo sviluppo della
storia:
– realizzazione delle scene;
– realizzazione degli script da associare agli attori della
storia;
– prove e correzioni.

Nello sviluppo del sjuzet è possibile aiutarsi con uno schema
attori-scene, che potrà poi essere utilizzato durante la
digitalizzazione della storia.

• Gli attori sono gli sprite; la numerazione delle scene indica
la loro sequenza nello sjuzet qualora siamo in un pattern
decentralizzato-deliberativo invece, nel pattern
decentralizzato-reattivo, sono nomi assegnati alle scene ma
non identificano una sequenzialità che, appunto, in questo
pattern non esiste. Le diverse scene vanno descritte
testualmente, specificando le rispettive sceneggiature,
descrivendo gli attori e le azioni che svilupperanno e cosa le
attiveranno. Dettagliare questa fase di analisi in questa
maniera facilità la realizzazione del programma relativo, in
quanto contiene in fieri tutto ciò che occorrerà per lo
sviluppo della storia; descrivendo le azioni dei vari attori si
indicano, implicitamente, i diversi script che dovranno
essere associati agli sprite.

dichiarativo, prolog
• Obiettivo di questa sezione è quello di introdurre la
programmazione logica nel percorso del PNSD. La differenza
sostanziale tra gli approcci precedenti (imperativi, ad oggetti, a
eventi, ..) e l’approccio dichiarativo (e quindi linguaggi logici e non
solo) è che nel primo caso il programma è caratterizzato da un
insieme di istruzioni che esprimono “come” ottenere un
determinato risultato; nel secondo caso il programma è
caratterizzato da un insieme di affermazioni che descrivono uno
specifico “stato del mondo” e di regole che permettono di
elaborare queste affermazioni per ottenere delle risposte a
domande poste. In definitiva si specifica che cosa occorre calcolare,
piuttosto che come.
• I linguaggi logico-dichiarativi, rispetto ai linguaggi procedurali, sono
molto simili al linguaggio naturale.
Da: Un software didattico per imparare la programmazione logica a scuola;Pierpaolo Di Bitonto, Teresa Roselli, Veronica Rossano, Dipartimento di Informatica – Università degli Studi di Bari

dichiarativo, prolog
• Un esempio di linguaggio dichiarativo logico è il
PROLOG (PROgramming LOGic) che è stato
progettato ed implementato a Marsiglia da
Colmerauer e Roussel nel 1972. In un programma
Prolog si descrive la conoscenza relativa al
problema, rappresentata da fatti e regole fra
questi, e poi sarà compito del sistema gestire lo
sviluppo risolutivo a fronte di interrogazioni. Il
PROLOG possiede un motore (Controllo), cioè un
meccanismo interno che gli permette di collegare
l'interrogazione con la conoscenza costituita per
costruire una risposta.

esempio 1 di pgm Prolog
• Abbiamo un elenco di persone
con numero telefonico e un
secondo elenco delle stesse
persone con il relativo indirizzo; si
vuole gestire questi due elenchi
per realizzare un elenco di
abbonati al telefono;

esempio 1
(elenco_tel.pl)
Il programma potrà essere strutturato nel seguente modo:
• tel(giorgio,223344).
• tel(maria,233445).
• tel(andrea,12234).
• tel(giorgio,283749).
• tel(giuseppe,223344).
• tel(anna,256781).
• tel(enrico,455466).
• tel(gianni,887799).
• indirizzo(giorgio,roma).
• indirizzo(maria,milano).
• indirizzo(andrea,torino).
• indirizzo(giuseppe,garibaldi).
• indirizzo(anna,tasso).
• indirizzo(enrico,marconi).
• indirizzo(gianni, garibaldi).
(Casadei G.A., Teolis A.G.B.)
ciascun “fatto” è formato da un
predicato (“tel”, “indirizzo”) e da
2 argomenti ; sono delle costanti
e vanno scritte in lettera
minuscola e anche il predicato;
I fatti possono avere 1, 2, 3, ….
più argomenti.

esempio 1
Diverse sono le domande che possiamo porre al programma
Prolog, ad esempio:
1. sapere se un utente con un numero telefonico esiste
nell’elenco;
2. sapere se un utente con una via esiste nell’elenco;
3. il numero telefonico di un utente conosciuto,
4. a chi corrisponde un determinato numero telefonico,
5. l’indirizzo di un determinato utente,
6. chi abita in un certo indirizzo,
7. il numero telefonico e l’indirizzo di un determinato utente,
8. l’utente ed il suo indirizzo, conoscendo il numero
telefonico.

esempio 1
esistono due modalità di interrogazione:
• di controllo: per verificare se un fatto è
compreso nella base di conoscenza;
• di ricerca: per ottenere delle informazioni
dalla base di conoscenza.

domande di controllo
• Se si domanda:
?- tel(andrea,12234).
Prolog risponde: “true”
• Se si domanda :
?- tel(andrea,45234).
Prolog risponde: “false”

domande di ricerca
• il numero telefonico di un utente conosciuto:
?-tel(anna, X).
Prolog risponde: X:256781 (Prolog ricerca nei fatti
un fatto che abbia come primo argomento “anna”
e assegna a X il valore del secondo argomento; X
è una variabile; la prima lettera di una variabile
deve essere in maiuscolo)
• a chi corrisponde un determinato numero
telefonico:
?-Tel(X, 233445).
Prolog risponde: X: Maria.

domande
Prendiamo in considerazione la domanda 7. Per conoscere il numero
telefonico e l’indirizzo di anna dobbiamo dapprima chiedere:
• ?-tel(anna, Numero_tel).
Prolog risponderà:
Numero_tel=256781,
• quindi dobbiamo chiedere:
?-indirizzo(anna, Via).
Prolog risponderà:
Via=tasso
Possiamo formulare una richiesta complessa formata dalle due domande:
?-tel(anna, Numero_tel),indirizzo(anna, Via).
Prolog cerca di soddisfare dapprima la prima domanda e poi la seconda,
solo se entrambe sono soddisfatte, viene presentato il risultato, nel nostro
caso:
Numero_tel = 256781,
Via = tasso

domande
Volendo conoscere l’elenco degli abbonati di via roma
con il relativo numero di telefono, possiamo formulare
al programma la seguente domanda:
?-tel(X,Num),indirizzo(X,roma).
Prolog restituirà:
X=Giorgio
Num=223344
X=Giorgio
Num= 283749.
Giorgio abita in via roma e ha due numeri telefonici.

istanziazione, unificazione
Prendiamo in considerazione la domanda 8. Per conoscere quale utente ha un
certo numero di telefono e dove abita, la domanda da formulare è la
seguente:
• tel(Persona, 455466), indirizzo(Persona, Via).
Prolog ricerca fra i fatti del predicato tel, quello che ha numero telefonico
455466 e quando lo incontra assegna il valore enrico alla variabile Persona
(istanziazione); quindi cerca di soddisfare la seconda domanda con un
fatto del predicato indirizzo che abbia come primo argomento l’attuale
valore di Persona, cioè enrico, quando lo trova assegna alla variabile Via il
valore tasso:
Persona = enrico
Via = marconi
In Prolog assegnare un valore ad una variabile si dice istanziare la variabile e
‘operazione di trovare un fatto uguale a un altro si chiama unificazione.

regole
Il Prolog non permette solamente di costruire programmi con una serie di fatti, ma
esiste la possibilità di ‘combinare’ fatti per formare regole.
Aggiungendo al programma la regola seguente:
abbonato(X, Num, Via):-indirizzo(X,Via),tel(X,Num).
esso diventa:
tel(giorgio,223344).
tel(maria,233445).
……………………………..
indirizzo(giorgio,roma).
indirizzo(maria,milano).
indirizzo(andrea,torino).
……………………………………..
abbonato(X, Num, Via):-indirizzo(X,Via),tel(X,Num).
Nella regola, ‘abbonato(X,Num,Via)’ rappresenta la testa e ‘indirizzo(X,Via),tel(X,Num)’,
il corpo. Quindi una regola è formata da un termine, chiamato testa della regola, dal
simbolo ‘:-‘ e da uno o più termini che costituiscono il corpo della regola.

Esempio 2
Stanze di un
appartamento

Esempio 2
(labirinto_0.pl)
Fatti:
porta(a,b).
porta(b,c).
porta(c,d).
porta(c,e).
porta(e,f).
Domande:
?-porta(a,b).
true
?porta(b,a).
false

Esempio 2
(labirinto_1.pl)
Si introducono due regole:
porta(a,b).
porta(b,c)
porta(c,d).
porta(c,e).
porta(e,f).
da(X,Y):-porta(X,Y).
da(X,Y):-porta(Y,X).
Domande:
da(b,a).
true

Esempio 2
• Stanze vicine: quando nel passaggio da una
all’altra si attraversa una sola stanza.
porta(a,b).
porta(b,c)
porta(c,d).
porta(c,e).
porta(e,f).
da(X,Y):-porta(X,Y).
da(X,Y):-porta(Y,X).
vicine(X,Y):-da(X,Z),da(Z,Y).

esempio 3
• Esempio: costruire una tabella di calciatori
delle squadre del campionato di serie A e
interrogare questa tabella. Lavorare a gruppi;
ciascun gruppo crea una tabella per una
squadra scelta.
M. Famiglietti, Tecnologia. Ricerca sul curricolo e innovazione didattica, Ufficio scolastico regionale dell’Emilia Romagna

esempio 3
Inter, Marco Andreolli, Difensore
Inter, Cristian Ansaldi, Difensore
Inter, Danilo Ambrosio, Difensore
Inter, Joao Miranda de Souza Filho, Difensore
Inter, Jeison Murillo, Difensore
Inter, Yuto Nagatomo, Difensore
Inter, Trent Sainsbury, Difensore
Inter, Davide Santon, Difensore
Inter, Guy Yao, Difensore
Inter, Ever Banega, Centrocampista
Inter, Jonathan Biabiany, Centrocampista
Inter, Marcelo Brozovic, Centrocampista
Inter, Antonio Candreva, Centrocampista
Inter, Roberto Gagliardini, Centrocampista
Inter, Joao Mario, Centrocampista
Inter, Geoffrey Kondogbia, Centrocampista
Inter, Gary Medel, Centrocampista
Inter, Ivan Perisic, Centrocampista
Inter, Citadin Martins Éder, Attaccante
Inter, Gabriel Barbosa Almeida, Attaccante
Inter, Mauro Icardi, Attaccante
Inter, Rodrigo Sebastian Palacio, Attaccante
inter(andreolli, difensore)
inter (ansaldi, difensore)
inter (ambrosio, difensore)
inter (miranda, difensore)
inter(murillo, difensore)
inter(nagatomo, difensore)
inter(sainsbury, difensore )
inter (santon, difensore)
inter (yao, difensore)
inter(banega, centrocampista)
inter(biabiany, centrocampista)
inter(brozovic, centrocampista)
inter(candreva, centrocampista)
inter(gagliardini, centrocampista )
inter( joao_mario, centrocampista)
inter(kondogbia, centrocampista)
inter(medel, centrocampista)
inter(perisic, centrocampista)
inter(éder, attaccante)
inter(barbosa, attaccante)
inter(icardi, attaccante)
Inter(palacio, attaccante)
P
R
O
L
O
G
squadra, giocatore, ruolo

esempio 3
Sono possibili richieste:
• inter(X, portiere) – risposta: handanovic (di ricerca)
• inter(eder, attaccante) - risposta: si (di controllo)
Con queste basi di conoscenza separate non è possibile
rispondere a domande tipo: “Quali sono tutti i portieri
del campionato di serie A?”. Ciascun gruppo vede la
propria squadra e non si ha una base di conoscenza
totale. Occorre costruire un nuovo modello che
raggruppi tutte le squadre e permetta di identificare
l’appartenenza dei giocatori alla propria squadra.

esempio 3
inter(andreolli, difensore).
inter (ansaldi, difensore).
inter (ambrosio, difensore).
inter (miranda, difensore).
……………..
milan(lapadula, attaccante).
milan(donnarumma, portiere).
………..
torino(belotti, attaccante).
……………..
giocatore (inter, andreolli, difensore).
giocatore(inter, ansaldi, difensore).
giocatore(inter, ambrosio, difensore).
giocatore(inter, miranda, difensore).
……………..
giocatore(milan,lapadula, attaccante).
giocatore(milan,donnarumma, portiere).
……………………
giocatore(torino, belotti, attaccante).
……………..
Il nome della squadra da nome del predicato è divenuto argomento di un predicato più
generale.

esempio 3
domanda: quali sono i portieri di serie A?
• ?-campionato(Squadra, Nome, portiere).
Risposta:
Squadra: inter
Nome: handanovic
Squadra: milan
Nome: donnarumma
Squadra: torino
Nome: hart

un passo avanti
Analizzando meglio si nota che si possono individuare 3 insiemi (classi): giocatori,
squadre e ruoli; proviamo a scrivere la nostra conoscenza nel seguente modo:
giocatore(1,andreolli).
giocatore(2, ansaldi).
giocatore(3, ambrosio).
giocatore(4, miranda).
giocatore(5, lapadula).
giocatore(6, donnarumma).
giocatore(7, belotti).
squa(1,inter).
squa(2,milan).
squa(3,torino).
ruo(at, attaccante).
ruo(di, difensore).
ruo(ce, centrocampista).
ruo(po, portiere).
Ora però come si riesce a capire in quale squadra e con quale ruolo
gioca un calciatore?

un passo avanti
Possiamo creare un’altra serie di fatti che metta in relazione le tre classi
gio_squa_ruo(1, 1, di).
gio_squa_ruo(2, 5, at).
gio_squa_ruo(2, 6, po).
gio_squa_ruo(3, 7, at).
La prima riga indica:
squadra con codice 1 (inter),
giocatore con codice 1 (andreolli),
ruolo con codice di (difensore), in altri
termini: il difensore andreolli gioca
nell’inter

un passo avanti
(calcio_3.pl)
La regola:
• domanda(Squadra,Nome,Ruolo):-squa(X,Squadra),
giocatore(Y,Nome), ruo(Z,Ruolo), gio_squa_ruo(X,Y,Z).
• Permette di interrogare il pgm prolog per sapere:
– ruolo e squadra, dato il giocatore
– i giocatori con il rispettivo ruolo, data una squadra;
– i giocatori con la rispettiva squadra, dato un ruolo;
– l’elenco dei giocatori con squadra e ruolo
– …………………………….

un passo avanti
• Se si fa la seguente domanda:
?-domanda(Squadra, lapadula, Ruolo).
Prolog restituisce:
Squadra: milan
Ruolo: attaccante
Se si vuole sapere in quale squadra, e con quale ruolo, gioca miranda?

• Ulteriore materiale in http://www.didafor.com

Bibliografia
• Alessandri G., 2016, Didattica per il coding. Didattica, pensiero computazionale, corporeità, Aracne, Roma
• Alessandri G., 2014, Didattica e tecnologie: intersezioni. Complessità, coding, robotica educativa, Anicia,
Roma
• Alessandri G., 2013, Tecnologie autonome nella didattica. Verso la robotica educativa, Morlacchi, Perugia.
• Alessandri G., Paciaroni M., 2013, Appunti sull’uso ludico delle tecnologie, Morlacchi, Perugia.
• Alessandri G., 2008, Dal desktop a second life. Tecnologie nella didattica, Morlacchi, Perugia

Coding, pattern e pensiero computazionale

More Related Content

What's hot (20)

Similar to Coding, pattern e pensiero computazionale (20)

More from Alessandri Giuseppe (17)

Coding, pattern e pensiero computazionale