Introduzione all’Object Orientation nell’articolazione...

Università di BolognaTFA A.A. 2011/2012

Introduzione all’Object Orientation nell’articolazione Informatica

di un Istituto Tecnico Tecnologico

Progetto didattico diMarco Sbaraglia

2. Scenario e obiettivi

2.1 Classe, percorso didattico e OOPQuesto documento descrive la proposta di conduzione di un’unità di-dattica sull’Object Orientation. Il progetto è stato sviluppato nell’ambi-to del TFA 2011/2012 (Tirocinio Formativo Attivo [1]), svolto presso l’Università di Bologna per la classe di concorso di Informatica (A042).A partire da una premessa sull’istituto, sulla materia e sulla classe osservata, si mettono in luce gli elementi che suggeriscono la neces-sità di un approccio non tradizionale di tipo bottom-up. Quindi, definiti gli specifici obiettivi didattici, si propone una metodologia in tre fasi, progettata per permettere agli studenti di partecipare alla costruzione dei concetti attraverso lo studio e la realizzazione di un semplice vi-deogioco. Segue una parte relativa ai contenuti, dove l’unità didattica è suddivisa in moduli, per i quali si descrive più nel dettaglio il lavoro con il gruppo classe in termini di esempi ed esercitazioni. Il documen-to termina con la progettazione delle verifiche formative e sommative e delle attività di recupero e consolidamento.

2.2 Gli obiettivi operativi

Ho individuato un nucleo fondamentale di obiettivi operativi specifici che – declinati in conoscenze, abilità e competenze, secondo le indi-cazioni teoriche-metodologiche di riferimento per la didattica – faccia-no da guida per la conduzione di unità didattica sull’Object Oriented Programming.

Introduzione all’Object Orientation all’ITIS Tecnologico

2

CONOSCENZE

• i principi della programmazione ad oggetti• la sintassi della programmazione ad oggetti• il concetto di ereditarietà • le classi astratte • le interfacce• l'overriding e il binding dinamico

ABILITA’

• sviluppare semplici oggetti• estendere semplici classi• estendere classi di libreria per realizzare comportamenti specifici

COMPETENZE

• analizzare semplici problemi e progettarne una soluzione OO• valutare l’opportunità di ricorrere ad una soluzione OO • utilizzare il computer e gli strumenti opportuni per lo sviluppo di applicazioni

OO

Per la scelta dei contenuti, anche in relazione a modi, tempi, spazi e materiali, si rimanda alla sezione 3.3 e in particolare al capitolo 4. Fissati infatti gli obiettivi, sono il metodo e la progettazione del per-corso didattico a determinarne la trasformazione degli stessi in moduli e contenuti concreti.

3. Metodologia

3.1 L’idea

L'introduzione dell'Object Oriented Programming è uno dei passaggi più critici di tutto il percorso didattico di Informatica, come testimonia-no i risultati mai del tutto soddisfacenti (stando alle testimonianze dei

Marco Sbaraglia

3

vari docenti intervistati) e la richiesta di uno specifico sportello sull’ar-gomento.Ho deciso quindi di riconsiderare alla base l’approccio metodologico, ribaltando la prospettiva secondo cui questi concetti vengono introdot-ti nelle classi dell’istituto. Da un percorso top-down, che si sviluppa dalla teoria alla pratica e ha nel libro di testo il riferimento principale, ho optato per un approccio bottom-up. In particolare ho deciso di av-valermi di una didattica by example: a partire dall’esperienza di esempi significativi [4], l’insegnante guida gli studenti alla costruzione della conoscenza (apprendimento per costruzione [5]). Una delle chiavi di questa metodologia è rappresentata sicuramente da un’ocu-lata scelta degli esempi, vero e proprio momento di progettazione di-dattica. È necessario che essi siano di complessità graduale, adegua-ti alle conoscenze pregresse e alle potenzialità degli studenti, e do-vrebbero far riferimento il più possibile ai linguaggi e ai mondi dei ra-gazzi. Inoltre è fondamentale che non siano eccessivamente astratti, anzi è auspicabile che siano riconducibili, man mano che si avanza nel percorso, ad uno o pochissimi scenari operativi concreti. L’obietti-vo è costruire passo passo ed insieme con gli studenti un “esempio vivo”, che consenta loro di scoprire, capire e mettere in pratica le ca-ratteristiche fondamentali e le principali prassi dell'OOP, in un percor-so mai svincolato dalla pratica. Il ruolo dell’insegnante è quello dell'ingegnere ma anche del capo cantiere: deve saper progettare un sistema modulare che gli studenti possano osservare e capire, ma deve anche guidarli nella modifica ed estensione del sistema stesso.


4

3.2 Lo scenario di riferimento

Navigando la rete alla ricerca della giusta intuizione, ho rintracciato un’introduzione all’OOP [6] a mio parere molto valida. Da un lato è stata una conferma della validità dell’approccio bottom-up e di una di-dattica by example per affrontare l’Object Orientation, a tutti gli effetti un vero e proprio sistema di pensiero. Dall’altro suggerisce un ulterio-re miglioramento rispetto all’intuizione iniziale: il living example utiliz-zato in questa introduzione introduzione è un videogioco di tipo piat-taforma (come esempio di videogame platform si consideri il noto Su-per Mario Bros. [7]). Si cercava infatti uno scenario non astratto, in grado di restituire risultati tangibili e non estraneo al linguaggio e al mondo dei ragazzi. In particolare la costruzione delle fondamenta ar-chitetturali di un semplice videogioco platform sembra essere partico-larmente adatta a stimolare l’attenzione, la curiosità e i processi co-gnitivi degli studenti.Non si tratta solo di appeal ed efficacia. La modellazione di un mondo fittizio definito da semplici regole e popolato da entità con caratteristi-che misurabili, rappresenta infatti uno scenario ideale per l’utilizzo del paradigma ad oggetti. Se poi gli studenti hanno fin dall’inizio la possibilità di partecipare atti-vamente alla realizzazione di qualcosa di concreto, si hanno ottimi presupposti per un successo didattico.Ulteriori dettagli sull’esempio nelle sezioni 4.2, 4.3 e 4.4.

Marco Sbaraglia

5

3.3 Le fasi

Questo momento della progettazione è ancora di ampio respiro, pre-liminare ad una più specifica individuazione e suddivisione dei conte-nuti in moduli. In particolare si specificano modalità e strumenti didat-tici, in modo da esplicitare i rapporti tra l’insegnante, gli studenti e i contenuti.Idealmente ho individuato tre principali fasi dell’attività, caratterizzate da da differenti strategie didattiche, da intendersi come parte di un ciclo che si ripete di modulo in modulo. In particolare:1. Lezione dialogata: dagli esempi proposti ai concetti generali, trami-

te una co-costruzione guidata dall’insegnante.2. Lezione frontale con slide e altri esempi, per ricapitolare i concetti

e puntualizzare i passaggi fondamentali, approfondendo soprattutto l'aspetto teorico.

3. Esercitazioni in laboratorio, individuali e graduali, in modo da met-tere immediatamente alla prova i concetti appresi in un contesto operativo.

Le fasi 2 e 3 possono essere facilmente invertite valutando, a secon-da dei concetti trattati e della risposta del gruppo classe, se sia più opportuno anticipare il momento di riflessione teorica oppure dare agli studenti un immediato riscontro pratico.

Lo schema che segue illustra sinteticamente gli elementi salienti di ciascuna fase dell’attività didattica. Il numero di ore fa riferimento alla conduzione di un solo modulo. I moduli verranno definiti in modo da raccogliere uno o più concetti legati tra loro, ma anche per distribuire il carico di lavoro in cicli sostenibili per gli studenti. In particolare ri-tengo che siano necessarie almeno 7 ore, quindi più di una settimana di lavoro tra aula e laboratorio, per lo svolgimento di un modulo.


6

Fasi dell’atti-vità didattica

Cosa fa l’in-segnante

Cosa fanno gli alunni

Materiali e strumenti

Spazi Tempi

Lezione dia-logata a par-tire da esempi

L'insegnante guida gli studenti ne-gli esempi proposti

Partecipano alla discus-sione propo-sta dall'inse-gnante

Esempi, computer (docente) e proiettore

In laborato-rio o in aula (se presente la LIM).

2 ore

Lezione frontale

L'insegnante spiega se-guendo le slide (o il li-bro di testo)

Gli studenti seguono la spiegazione e prendono appunti

Slide (even-tualmente libro di testo) e proiettore

In aula 2 ore

Esercitazioni in laborato-rio

Dà assisten-za agli stu-denti, sia individualiz-zata sia al gruppo clas-se

Si cimenta-no indivi-dualmente nelle eserci-tazioni pro-poste

Esercitazioni (più appunti, slide o testo) e computer (studenti)

In laborato-rio

3 ore

3.3.1 Fase I: la costruzione guidataQuesta prima fase si svolge in laboratorio o in aula se è presente la LIM; l’insegnante discute ed implementa semplici esempi al computer, mostrandoli agli studenti con il proiettore o sulla LIM. Ovviamente non si tratta di un’attività estemporanea (gli esempi sono stati progettati precedentemente), ma è importante che l’implementazione avvenga “in diretta”.In questa fase l’insegnante, problematicizzando gli esempi, rivolge opportune domande al gruppo classe, cercando di attivare nei ragazzi specifici percorsi cognitivi a lui già noti. In altre parole stimola un ra-gionamento collettivo, una discussione della quale deve disciplinare modi e tempi, al fine di convergere verso gli specifici obiettivi didattici. In particolare si tratta di ricostruire i concetti dell'OOP a partire dal-l’applicazione dei relativi meccanismi.

Marco Sbaraglia

7

3.3.2 Fase II: la rielaborazioneRaccolti insieme al gruppo classe gli elementi chiave, a questo punto l’insegnante procede a ricapitolarli secondo un percorso più struttura-to e sequenziale. Servendosi del libro di testo, o di materiale proprio da condividere con gli studenti (su cui ovviamente può avere maggior controllo), il docente sottolinea i concetti fondamentali, ne mette in lu-ce motivazioni, fondamenti teorici e connessioni, e propone ulteriori esempi. L’obiettivo principale è aiutare gli studenti ad organizzare la conoscenza e a maturare una visione d’insieme. Questo momento rappresenta inoltre l’occasione per compattare il gruppo classe. Dopo la prima fase, in cui è assai probabile che siano stati i ragazzi più partecipativi e/o brillanti a collaborare di più alla co-costruzione della conoscenza, è necessario che a tutti venga data la possibilità di raggiungere gli obiettivi. Di conseguenza è opportuno ricorrere ad ulteriori esempi, più semplici e circoscritti, e ricercare il massimo della chiarezza espositiva in un percorso necessariamente sequenziale.Risulta quindi inevitabile la scelta di una didattica principalmente im-prontata alla lezione frontale, da svolgersi in aula; al contempo l’inse-gnante deve indagare i dubbi degli studenti e accoglierne favorevol-mente le domande.

3.3.3 Fase III: la praticaLa terza fase dell’attività didattica si svolge in laboratorio, poiché pre-vede che gli studenti si cimentino in esercitazioni al computer. La si-tuazione descritta, con particolare riferimento al disagio nella sintesi concreta dei concetti appresi, sottolinea ancora di più l’importanza capitale di questo ulteriore momento di rielaborazione. È infatti ne-cessario che ad una riflessione teorica eterodiretta, ne segua una a carico dei ragazzi. Essi sono chiamati a sperimentare in prima perso-na la valenza concreta dei concetti affrontati, in modo da guadagnare


8

progressivamente autonomia e di conseguenza fiducia nei propri mezzi. Ovviamente l’insegnante ha il compito di progettare opportunamente le attività da affidare agli studenti. Per aumentarne l’efficacia, ritengo opportuno che le esercitazioni proposte coincidano o al più richiedano la modifica o l’estensione degli esempi utilizzati nella prima fase. Nel caso specifico si tratta di coinvolgere gli studenti nello sviluppo del vi-deogame, invitandoli ad implementarne entità e logiche secondo i principi dell’OOP. È inoltre auspicabile prevedere qualche grado di li-bertà in termini di personalizzazione e creatività, in modo da stimolare maggiormente l’impegno dei ragazzi.Ritengo fondamentale che si tratti di momenti di lavoro individuali, co-sì da indurre, presto e sistematicamente, ciascuno studente a con-frontarsi con le proprie conoscenze e il relativo livello di comprensio-ne. In questo modo si cerca di responsabilizzare i ragazzi, affinché si attivino in loro quei meccanismi meta-cognitivi di rielaborazione della conoscenza alla base della conquista di autonomia e autostima. D’altra parte, sta all’insegnante la lettura di situazioni di difficoltà o di scarsa motivazione. Egli dà assistenza personalizzata a chi la richie-de, ma si attiva in particolare per rimuovere quegli ostacoli che impe-discono agli studenti più in difficoltà di cimentarsi nelle attività propo-ste, cercando soprattutto confronti individuali con i ragazzi. Può an-che, qualora emergano dubbi o misconcezioni diffuse, fornire chiari-menti e nuove spiegazioni a beneficio di tutto il gruppo classe.È infine importante che il docente fornisca strumenti e stabilisca rego-le affinché gli studenti documentino e conservino il loro lavoro, ren-dendolo così disponibile per le esercitazioni successive e per le cor-rezioni dell’insegnante (e.g., utilizzando cartelle riservate agli studenti in una rete interna d’istituto). In questo senso è fondamentale che i ragazzi possano facilmente prelevare il proprio codice, così da poterlo sviluppare anche a casa.

Marco Sbaraglia

9

3.4 Modelli pedagogici di riferimento

Nelle primissime fasi di progettazione di questo percorso, ho cercato di impostare l’attività didattica a partire dai più importanti pattern pe-dagogici utilizzati per l’insegnamento della Computer Science [8]. Ben presto, però, mi sono reso conto di quanto questo modo di procedere fosse troppo astratto, spingendomi ad adottare un’ottica più pragmati-ca.D’altra parte, una volta definiti approccio, didattica e fasi, è stato inte-ressante riconsiderare la mia proposta alla luce di questi modelli, an-che con l’obiettivo di dare maggior fondamento teorico a scelte detta-te principalmente da intuizione, competenza disciplinare e buon sen-so. Effettivamente ho riscontrato una coincidenza rassicurante tra le ispirazioni alla base di alcuni di quei modelli e la metodologia descrit-ta in questa proposta. Si riportano di seguito le corrispondenze più si-gnificative.Per quanto riguarda la prima fase, l’intenzione di guidare gli studenti alla costruzione dei concetti, consentendo loro di ragionare su esempi al di là della loro capacità di realizzarli, è supportata dai pattern Lay of the Land e Larger Than Life per cui:

Students are given some early experience in examining a large artifact, beyond their ability to produce, with the intent of showing

them the complexity of the field they are about to study. [8]

e ancora:

Students of Object-Oriented programming and design can and should examine and use computing artifacts much earlier than

they can design and build them themselves. [8]

Entrambi i modelli sono consigliati per trattazioni relative all’Object Orientation, in particolare Larger Than Life è addirittura specifico per questo argomento.


10

Il pattern Consistent Metaphor avvalora l’idea di fare riferimento al vi-deogame, scenario ideale per un’introduzione all’OOP e vicino al mondo dei ragazzi:

When teaching a complex topic outside student's normal expe-rience, find a complex and consistent metaphor for the topic being

taught. The basis of the metaphor needs to be known to the students. [8]

Anche questo modello è consigliato per l’Object Orientation ed insie-me con i precedenti due convalida la scelta di un approccio by example all’OOP.A proposito poi delle esercitazioni, dotare gli studenti di un set di componenti da estendere passo passo per realizzare l’architettura di base del videogioco, è la strategia proposta dal pattern Tool Box:

The intent is to let the students build a tool kit in early courses for use in later courses. If well thought out and implemented, it can

be a wonderful guide to reusable software. [8]

Ci sono poi altri modelli le cui idee e metodologie trovano riscontri più generali e trasversali nelle modalità di conduzione di questa unità di-dattica, come ad esempio il pattern Mistake per la costruzione guida-ta, o il pattern Spiral nel susseguirsi delle tre fasi. Ma al di là di ulteriori corrispondenze, è interessante sottolineare che l’insegnante può trovare in questi modelli pedagogici una sorta di va-demecum, un riferimento continuo per la sua attività di progettazione didattica. Per ogni pattern sono esplicitate le forze in gioco, le condi-zioni e i vincoli, gli esempi, le possibili realizzazioni, nonché le poten-ziali criticità [8]; si tratta di elementi preziosi per meglio interpretare le situazioni reali e scegliere caso per caso le strategie più opportune. In un settore non deterministico come quello delle scienze dell’educa-zione, è infatti necessario prevedere la possibilità di soluzioni alterna-tive, immaginando approcci diversi al variare del contesto o in caso di scarsi risultati.

Marco Sbaraglia

11

3.5 Variazione del curricolo

La riflessione sui modelli pedagogici per la Computer Science mi ha dato l’occasione di immaginare un possibile miglioramento: una pro-fonda variazione del curricolo, per cui il paradigma ad oggetti venga introdotto in terza, prima della programmazione strutturata. Fa riflette-re a riguardo il pattern Early Bird, per cui:

The course is organized so that the most important topics are taught first. Teach the most important material, the "big ideas," first (and often). When this seems impossible, teach the most im-portant material as early as possible. [8]

È infatti possibile che una delle cause delle frequenti difficoltà nell’as-similare l’OOP sia proprio l’insegnamento dei primi elementi di pro-grammazione e l’introduzione delle strutture dati nella sola prospetti-va della programmazione strutturata. L’alternativa potrebbe essere quella di rendere i ragazzi "nativi" rispetto all’Object Orientation, per poi inferire le caratteristiche della programmazione strutturata in un secondo momento.A fronte della stabilità necessaria per progettare il curricolo dell’intero triennio, o al limite raggiungendo un accordo collegiale con il diparti-mento dei docenti di Informatica, si potrebbero affrontare strutture condizionali, ricorsione, cicli e operazioni di input/output già in un’otti-ca Object Oriented. In particolare sarebbe necessario considerare ini-zialmente le strutture e i meccanismi di base dell’OOP come dati di fatto. D’altra parte l’insegnante coglierà sistematicamente le molte opportunità di introdurre i fondamenti teorici dell’Object Orientation a partire dalle prassi, ovvero sempre in relazione alle esperienze con-crete degli studenti impegnati ad acquisire i primi elementi di pro-grammazione. Declinati momentaneamente ad obiettivi divergenti (ri-spetto a quelli principali), i principi dell’OOP potranno essere organiz-zati in un progetto didattico (in contrapposizione a unità didattica, cfr. [5]), quindi distribuiti lungo un più ampio periodo di tempo, favorendo-


12

ne così l’assimilazione, anche grazie al clima disteso che crea l’as-senza di verifiche.In seguito, probabilmente in quarta, si dovrà prevedere un’unità didat-tica di stampo prettamente teorico, in cui mostrare i più semplici prin-cipi della programmazione strutturata, sottolineando l’evoluzione sto-rica dei diversi paradigmi (dalla programmazione sequenziale all’O-OP). Sarà l’occasione per consolidare i fondamenti dell’Object Orien-tation, avendo come ulteriore risorsa a disposizione il confronto vivo con la stessa programmazione strutturata.

Marco Sbaraglia

13

4. Contenuti

4.1 Premessa

Prendendo spunto dall’introduzione di Udacity [6], sono giunto alla suddivisione dell’unità didattica in almeno tre moduli. Si tratta di un’organizzazione ideale, eventualmente da riconsiderare di volta in volta, in base ai feedback ricevuti dai vari gruppi classe. La trattazione che segue è generale e indipendente dal linguaggio uti-lizzato, ovvero adatta ad un’introduzione all’OOP con tutti principali linguaggi moderni che supportino l’Object Orientation. Al livello di ap-profondimento adatto ad una scuola superiore, infatti, le differenze tra i vari linguaggi sono quasi esclusivamente sintattiche.Di ogni modulo si descrive in particolare la prima fase, riportando inol-tre indicazioni per le esercitazioni. Ritengo superfluo esplicitare i det-tagli delle fasi di rielaborazione teorica condotte dall’insegnante; si tratta infatti di seguire il libro di testo, eventualmente modificando l’ordine degli argomenti, oppure di individuare nella propria trattazione il livello di approfondimento più adeguato, variabile a seconda dei gruppi classe e dei contesti. Invece è importante sottolineare i poten-ziali ostacoli cognitivi di ogni modulo, in modo che le attività possano essere guidate dalla consapevolezza di tali criticità.


14

4.2 Modulo I

• Concetto di classe; campi e metodi• Information hiding e incapsulamento• Classi vs oggetti: i costruttori• Scope di campo e di metodo

Questo modulo affronta i concetti di base dell’OOP da un punto di vi-sta più sintattico che non ancora semantico. Non si intende veicolare sin da principio una visione d’insieme, ma solo i primi strumenti del-l’operatività OOP. È comunque fondamentale trasmettere grande chiarezza, in particolare rispetto agli ostacoli principali di questo mo-dulo. In particolare ritengo che i nodi più critici siano la differenza tra classe e istanza della classe (oggetto) e la comprensione degli scope di variabili e metodi, esterni o interni alle classi. Per le ragioni indicate, è necessario fare ricorso ad esempi molto semplici, essenziali, in modo da mostrare le caratteristiche di una classe e i costrutti (tipici del linguaggio utilizzato) per definirne varia-bili, costruttori e metodi, oltre che per istanziarne gli oggetti. L’inse-gnante mostra agli studenti (utilizzando il proiettore) l’implementazio-ne di semplici classi, sottolineando il meccanismo dell’incaplsulamen-to. Effettua poi accessi a variabili e chiamate a metodi che le manipo-lano o che stampano messaggi, chiedendo al gruppo classe di effet-tuare previsioni sui risultati di tali operazioni. Inoltre, per stimolare le opportune domande sugli scope, utilizza nomi e signature identici per variabili e metodi esterni o interni alle classi. L’obiettivo è fare emer-gere concretamente, attraverso questi casi particolari, differenze di comportamento in grado di esemplificare concetti ben più difficili da descrivere in astratto.

Le esercitazioni da assegnare agli studenti consistono nell’implemen-tazione di semplici varianti degli esempi usati per la costruzione gui-

Marco Sbaraglia

15

data; in particolare è opportuno insistere su situazioni che permettano di sottolineare l’esistenza di scope differenti.

4.3 Modulo II

• Ereditarietà• Classi astratte• Campi e metodi statici

A fronte dell’accresciuto livello di astrazione richiesto da questo mo-dulo, si inizia da qui a costruire il living example, ovvero un set orga-nico di esempi riconducibile ad un unico scenario operativo, il video-game, da utilizzare come riferimento concreto ed estendere fino al termine dell’unità didattica. In particolare si tratta di un videogame piattaforma, dove tutto, dal protagonista all’ambiente, può essere considerato un’estensione del concetto di entità. Il framework del videogame consente di ragionare prima sulle caratteristiche comuni dei personaggi, per poi cercare di ricondurre tutti gli elementi del gioco alle entità più essenziali. La concretezza degli esempi di questo modulo, insieme con la possi-bilità di modificarli, può aiutare i ragazzi a compiere quei salti d’astra-zione che appaiono naturali ad un esperto. A questo proposito ritengo che le maggiori criticità risiedano nella corretta identificazione delle entità da modellare. Prima però di ragionare con i ragazzi sul concetto di entità e sulla loro individuazione, penso sia opportuno considerare come dato di fatto quelle più evidenti, ovvero il protagonista del gioco e i suoi opponent (banalmente “mostri”) e mostrarne le relative implementazioni. Successivamente l’insegnante cerca di coinvolgere il gruppo classe in una discussione sulle qualità degli altri elementi del gioco (e.g., altri personaggi, elementi del paesaggio, etc.), procedendo insieme con


16

gli studenti ad ulteriori semplici implementazioni. L’obiettivo è rendere evidente l’opportunità di rappresentare mediante classi tutto ciò che è dotato di caratteristiche e comportamenti. Inoltre, magari prendendo a riferimento proprio gli opponent, tanti e uguali tra loro, il docente ha l’occasione di riprendere la differenza tra classe ed oggetti, secondo un tipico pattern a spirale, per consolidarla collocandola in un conte-sto più significativo.Successivamente l’insegnante guida il ragionamento sul riconosci-mento delle caratteristiche comuni trasversali ai diversi elementi del gioco. A partire da quelli di partenza realizzati come classi a se stanti, mostra l’implementazione degli stessi come estensioni di classi via via più generali, illustrando così anche l’utilizzo delle classi astratte. Durante questo percorso l’insegnante, grazie alle caratteristiche inva-rianti tipiche di alcuni dei personaggi del gioco (i.e., il livello massimo di punti vita e i metodi di attacco/difesa comuni a personaggi dello stesso tipo), può facilmente introdurre anche il concetto di proprietà e metodi statici.

Per quanto riguarda l’attività di laboratorio, le esercitazioni concorro-no allo sviluppo dell'architettura del videogioco, per sfruttare al mas-simo la continuità con il percorso della lezione dialogata. Entità da implementare per aggiungere nuovi elementi, classi da estendere o generalizzare per arricchire il set di comportamenti delle entità già implementate in aula o dall’insegnate, il tutto nell’ottica di realizzare un sistema di gioco dotato degli elementi necessari ad un funziona-mento di base.D’altra parte, può essere opportuno fornire anche qualche esercita-zione estranea allo scenario del videogame, in modo da verificare più specificatamente la capacità dei ragazzi di riconoscere e definire le entità, individuandone caratteristiche e comportamenti.

Marco Sbaraglia

17

4.4 Modulo III

• Interfacce• Overriding di metodi e costruttori• Binding dinamico o late binding

Chiedendo agli studenti di immaginare un’estensione al videogame, ad esempio un nuovo set di personaggi e artefatti, l’insegnante intro-duce le interfacce come strumento di progettazione, utilizzandole per fissare le specifiche che emergono dalla discussione con il gruppo classe. Cerca così di evitare agli studenti le frequenti perplessità cau-sate dall’astrazione del concetto di interfaccia (“a cosa servono?” è una domanda tipica), dimostrando concretamente l’esistenza delle fa-si di analisi e progettazione distinte dall’implementazione.Per quanto riguarda l’overriding si utilizzano le classi già definite, a partire dalle quali l’insegnante sviluppa entità ancor più specializzate (i.e. personaggi che modificano i loro comportamenti dopo il raggiun-gimento di un determinato livello di esperienza), i cui metodi imple-mentino estensioni o modifiche dei comportamenti definiti nelle classi da cui derivano. Successivamente, tramite esempi che utilizzano con-cretamente istanze delle classi implementate, l’insegnante simula semplici interazioni tra i personaggi a disposizione e chiede al gruppo classe di effettuare previsioni a riguardo. Quindi mostra ai ragazzi i diversi risultati effetto di chiamate agli stessi metodi sugli oggetti che appartengono alle classi più specializzate.Avendo cura di procedere gradualmente e senza saltare passaggi co-gnitivi, è possibile dimostrare sempre allo stesso modo il funziona-mento del binding dinamico.

Le esercitazioni proseguono nello sviluppo dell’architettura di gioco, secondo l’impostazione già adottata nel secondo modulo (cfr. sezione 4.3).


18

Più nello specifico, dato che si tratta del modulo conclusivo, l’inse-gnante cerca di progettare attività che richiedano agli studenti l’utiliz-zo integrato di tutti i meccanismi fondamentali dell’unità didattica, ov-viamente ponendo principale attenzione agli strumenti e anche ai concetti di questo modulo.È un momento cruciale nel percorso dell’unità didattica: più delle esperienze di laboratorio precedenti, maggiormente incentrate sul-l'acquisizione di contenuti e lo sviluppo di abilità, questa ulteriore rie-laborazione pratica può aiutare i ragazzi a sviluppare meta-compe-tenze di analisi e sintesi. Si tratta di apprendimenti, definiti ‘superiori’, che rappresentano un presupposto alla conquista di autonomia e quindi di autostima, realizzando un pieno raggiungimento degli obiet-tivi didattici [9].

5. Verifica, recupero e valutazione

5.1 Premessa

Ogni modulo non si esaurisce nelle sole tre fasi dettagliate sopra (la cui durata complessiva è di circa 7 ore), ma a ciascuno di essi do-vrebbero seguire una verifica formativa e una serie di attività di recu-pero e consolidamento, durante le quali i ragazzi si dividono in gruppi di lavoro a seconda dei risultati della verifica. Al termine di queste at-tività, infine, è prevista una verifica sommativa, prova finale sulla base della quale dare il voto a ciascuno studente.Questo modus operandi è considerato ottimale dalle scienze dell’edu-cazione ai fini di una necessaria individualizzazione della didattica [10]. Ha le sue origini nella metodologia del Mastery Learning e ha trovato nel corso degli anni numerosi riscontri positivi nelle sperimen-tazioni che ne sono seguite [9,10]. Non è opportuno approfondirne qui

Marco Sbaraglia

19

le ragioni teoriche, ma si riporta a beneficio del lettore una metafora sportiva per chiarire brevemente idea e obiettivi di questa metodolo-gia. Dopo un primo periodo di allenamento (le tre fasi di ogni modulo), l’atleta (lo studente) sostiene dei test o una simulazione della gara (verifica formativa). A seguito dei risultati ottenuti l’allenatore coinvol-ge l’atleta nella strategia di allenamento, che lui stende in base alle sue competenze, al fine di correggere eventuali errori e migliorare il rendimento dell’atleta (attività di recupero e consolidamento). Tutto ciò in vista della gara vera e propria, dove il risultato sarà definitivo e inappellabile (verifica sommativa). Le considerazioni e la progettazione che seguono si fondano in buon parte sui contributi di Vannini [10] e Domenici [11].

5.2 Verifiche formative

Al termine di ogni ciclo di tre fasi si dovrebbe effettuare la verifica formativa relativa a quel modulo, salvo poi procedere con frequenza inferiore in caso di valutazioni positive che derivino da un'attenta os-servazione degli studenti, in particolare dei risultati della loro attività in laboratorio. Si tratta di prove agili, di natura analitica, perciò strutturate in una se-rie di quesiti a risposta multipla e/o di piccoli frammenti di codice da completare (scegliendo da un set di proposte) o nei quali trovare l'er-rore. Si intende così verificare, ad un basso livello di approfondimen-to, conoscenze e abilità in modo integrato. Ogni quesito ha lo stesso peso degli altri (al massimo doppio, in que-sto caso sarà esplicitato) e il relativo risultato è binario: giusto o sba-gliato. Si stabilisce una soglia minima ed in base al numero dei quesi-ti positivi si definiscono gruppi di recupero e di consolidamento. Que-st'ultima decisione è certamente determinata dai risultati, ma in ultima


20

istanza è comunque affidata al docente. La sua sensibilità, infatti, può dirimere situazioni incerte, anche a seguito di colloqui informali con i singoli studenti. Inoltre le esercitazioni che gli studenti affrontano in laboratorio sono un ulteriore elemento utile ad orientare la lettura formativa dell'insegnante.

5.3 Attività di consolidamento e recupero

Una possibile strategia di recupero può essere seguire la trattazione top-down del libro, se il docente ha utilizzato il proprio materiale nella seconda fase, o viceversa. In ogni caso si tratta di un’attività che, al-meno all'inizio, deve necessariamente avvenire sotto la guida dell'in-segnante. Quest'ultimo rintraccia nel testo gli argomenti affrontati e ne mette in evidenza le relazioni con la trattazione precedente. Si tratta di un momento di recupero ma anche di consolidamento per chi ha già raggiunto gli obiettivi.La duplice valenza (recupero e consolidamento) di questa situazione può essere mantenuta dividendo il gruppo classe in piccoli gruppi di studio che, sotto la guida degli studenti più esperti, si cimentino nella comprensione del testo. In questo momento sarà possibile stimolare e responsabilizzare gli studenti, sia informalmente, sia con la promessa di un possibile voto positivo per gli studenti guida in caso di successo del recupero. Si tenga presente che questa modalità di collaborazione non sempre si rivela opportuna (e.g., troppi studenti in difficoltà oppu-re studenti non adatti alla collaborazione) e comunque non se ne de-ve mai abusare, in particolare se gli studenti tendono ad assumere sempre gli stessi ruoli. I ragazzi rischiano infatti di auto-identificarsi con i propri limiti, ma anche con il ruolo di guida, con effetti deleteri in entrambi i casi.In alternativa è possibile organizzare gruppi di recupero omogenei e proporre agli studenti più brillanti i primi concetti di ingegneria del

Marco Sbaraglia

21

software e i pattern fondamentali legati all’Object Orientation (e.g., il pattern Model-View-Control).Se invece le incertezze sono più legate alla pratica (in particolare quando e come ricorrere all’OOP) una più opportuna attività di recu-pero si svolge in laboratorio. A coppie o a piccoli gruppi eterogenei (studenti in difficoltà e non), i ragazzi affrontano semplici esercitazioni proposte dall'insegnante. Di nuovo si tratta di un'attività sia di recupe-ro sia di consolidamento, ma questa volta si rischia ancora di più di scoraggiare gli studenti in difficoltà e soprattutto di annoiare quelli che hanno già raggiunto gli obiettivi, anche a causa della necessaria semplicità di esercizi progettati per il recupero. Dunque può risultare più opportuno organizzare gruppi omogenei, dove gli studenti incerti devono necessariamente confrontarsi con i propri limiti, supportati dall'assistenza sempre attiva dell'insegnante. In questo caso la collaborazione tra i ragazzi (da evitarsi prima del feedback formativo, cfr. 3.3.3) è un elemento molto importante, sia come stimolo emotivo sia come risorsa operativa per superare gli ostacoli [12].In questo scenario una naturale attività di consolidamento, da svol-gersi sempre in laboratorio e in contemporanea, è rappresentata dalla proposta di esercizi avanzati per gli studenti più brillanti. Vere e pro-prie sfide di codifica da affrontare a gruppi o individualmente, che meglio di peer tutoring e approfondimenti teorici possono stimolare le potenzialità e dare fiducia. Nello specifico di questa proposta, gli stu-denti più preparati al termine del terzo modulo (cfr. sezione 4.4) po-trebbero collaborare per portare a termine un’architettura di base del videogioco e per legarla ad una interfaccia grafica triviale, gestendo un set essenziale di input da tastiera. In tal senso, i limiti di un even-tuale percorso di sviluppo verso un prima demo funzionante sono esclusivamente determinati dalla presenza di un numero sufficiente di eccellenze e dal tempo necessario al recupero svolto con il resto del-la classe.


22

In particolare, la durata di queste attività dipende strettamente dal successo del recupero, ma anche dall’importanza che l’insegnante at-tribuisce ai contenuti trattati. Ad esempio, può valere la pena soffer-marsi sul recupero di argomenti di fondamentale importanza anche per più di una settimana, rinunciando magari ad alcuni tra gli obiettivi più avanzati.In caso di riscontri persistentemente negativi l’insegnante deve saper variare le attività muovendosi con flessibilità tra le proposte sopra in-dicate, in modo da rispondere alle particolari caratteristiche ed esi-genze del gruppo classe.

5.4 Verifica sommativa

Data l'estensione e l'importanza dell'Object Orientation, la verifica sommativa si articola necessariamente in due prove: una teorica ed una pratica.Entrambe sono strutturate in due parti chiaramente distinguibili, o in generale oppure a livello delle singole domande/esercizi, a seconda delle esigenze. In questo modo con la prima parte, obbligatoria, è possibile raggiungere il massimo dei voti, così da non penalizzare né scoraggiare gli studenti che hanno difficoltà a raggiungere la suffi-cienza. Con la seconda parte, quella facoltativa, è possibile meritare un ulteriore voto solo se positivo, in modo da stimolare le eccellenze [10] (eventualmente verificando competenze nella prova teorica e co-noscenze in quella pratica).La verifica sommativa volta a verificare i concetti teorici e i principi dell'Object Orientation è strutturata in alcune domande a risposta sin-tetica (100-200 parole) da svolgersi preferibilmente al computer. Pos-sibile ricorrere a porzioni di codice da analizzare.La verifica sommativa pratica si svolge necessariamente in laborato-rio e consiste nell'estensione di classi, nell'implementazione di sem-

Marco Sbaraglia

23

plici oggetti e nell'analisi di problemi concreti, dei quali è chiesto di immaginare una modellazione/soluzione anche a partire da oggetti di libreria facilmente estensibili. In particolare quest'ultima, più avanzata possibilità sembra adatta come verifica sommativa di un'attività di consolidamento (ovvero come parte facoltativa per un ulteriore voto).Per quanto riguarda la correzione si intende procedere orizzontal-mente: una prova dopo l'altra si correggono tutte le prime domande/esercitazioni, per poi passare alle seconde, e così via. In questo modo si cercano maggior obiettività e imparzialità massima.A ogni domanda/esercitazione corrispondono cinque livelli di risultato, da 0 a 4. Ogni domanda ha lo stesso peso, mentre è possibile che i moduli della prova pratica abbiano pesi differenti tra loro; in ogni caso queste informazioni devono essere chiaramente esplicitate agli stu-denti.Il voto è determinato a partire da una tabella dove a tutti i possibili punteggi (il minimo è zero, il massimo è 4 moltiplicato per il numero di domande/esercitazioni, eventualmente rapportate ai rispettivi pesi) corrispondono voti differenti. Caratteristica fondamentale di questa tabella di conversione è la distribuzione non uniforme dei voti sulla scala dei punteggi. In particolare utilizzando in maggiore o minor mi-sura le frazioni di voto, è possibile addensare o meno i risultati intorno ai diversi livelli (e.g., la sufficienza, l'eccellenza). L'insegnante, calco-late la media dei punteggi e la relativa deviazione standard, può di volta in volta valutare diverse mappature della tabella, al fine di otte-nere un risultato generale il più equo possibile, così da evitare ecces-si di scoraggiamento o esaltazione nei ragazzi.


24

Bibliografia e sitografia

[1] ! Tirocinio formativo attivo - Wikipediahttp://it.wikipedia.org/wiki/Tirocinio_formativo_attivo

[2] ! POF - ITIS Blaise Pascalhttp://www.itis-cesena.it/download/POF_2012_2013.pdf

[3] ! Riforma Gelmini - Wikipediahttp://it.wikipedia.org/wiki/Riforma_Gelmini

[4] ! J. Dewey, Esperienza ed educazione (1938), La Nuova Italia, 1993

[5]! L. Guerra, Educazione e tecnologie: per un modello didattico problematico, in: Tecnologie dell'educazione e innovazione didattica (pp. 9 - 33), Edizioni Junior, 2010

[6] ! Introduction to Object-Oriented Programming - Udacityhttps://www.udacity.com/wiki/classes

[7]! Super Mario Bros. - Wikipedia! http://it.wikipedia.org/wiki/Super_Mario_Bros.

[8] ! Fourteen Pedagogical Patterns - Seidenberg School of Computer Sciencehttp://csis.pace.edu/~bergin/PedPat1.3.html

[9]! G. Arrigo, F. Frabboni, Programmare nella scuola elementare: dieci tassonomie disciplinari per la scuola elementare, Nicola Milano Editore, 1993.

[10]! I. Vannini, La qualità nella didattica, Erickson, 2009

[11] ! G. Domenici, Manuale della valutazione scolastica (2003), Laterza, 2007

[12]! S. C. Negri, Il lavoro di gruppo nella didattica, Carocci, 2005

Marco Sbaraglia

25

Introduzione all’Object Orientation nell’articolazione...

Documents

Transcript of Introduzione all’Object Orientation nell’articolazione...