Living World Builder: Costruttore e Simulatore di Mondi Artificiali

Eleonora Bilotta, Pietro Pantano

Centro Interdipartimentale della Comunicazione, Università della Calabria

Arcavacata di Rende

87036-Rende (CS)

ABSTRACT

Nel presente lavoro viene descritto un prototipo che incorpora ed estende le funzionalità di alcuni fra i più notevoli ambienti educativi attualmente disponibili. Scopo principale dell'ambiente è facilitare la comprensione dei modelli sottostanti ai vari ambienti e rendere più semplice il passaggio dall'uno all'altro. Il lavoro è strutturato nel seguente modo: nella sezione 2 presentiamo le caratteristiche e i concetti sottostanti dei software che abbiamo scelto, in quanto emblematici di approcci scientifici, settori di ricerca ed innovazione tecnologica; nella sezione 3 vengono presentati i concetti principali del micromondo e della simulazione; nella sezione 4 sono illustrate le caratteristiche del nostro sistema; nella sezione 5 sono fornite indicazioni su come utilizzare il sistema, a seconda dei diversi ambienti che l'utente sceglie; la sezione 6 chiude con alcune considerazioni su ulteriori sviluppi del nostro ambiente

1. Introduzione

Le ricerche sullo Human Computer Interaction, i nuovi linguaggi di programmazione e l'ingresso o la rivisitazione di nuovi paradigmi scientifici da una parte, la rivoluzione tecnologica resa possibile dalla multimedialità e dalle tecnologie dell'informazione dall'altra, hanno dato vita ad una nuova generazione di software educativi. Il panorama presenta una grande varietà di approcci e di possibilità didattiche. Dal Logo, per esempio, si è passati a Microworlds, che mantenendo alcune caratteristiche di base del vecchio programma, fornisce agli utenti (sia insegnanti che studenti) la possibilità di sfruttare e di realizzare approcci costruttivi nuovi attraverso un uso integrato della multimedialità. Ognuno di questi software presenta tecnologie, approcci scientifici, caratteristiche ed interfacce differenti e il loro uso combinato, pur se auspicabile, diventa difficilmente applicabile in un contesto scolastico, soprattutto se gli insegnanti non hanno una specifica formazione (Bilotta, 1999a).

In questo lavoro presentiamo un ambiente di sviluppo denominato Living World Builder (d'ora in poi LWB), che incorpora alcune tra le funzionalità dei software che riteniamo più importanti, con l'uso di un’interfaccia comune che consente, quindi, un facile passaggio da un contesto all’altro. Scopo principale di tale lavoro è quello di facilitare la comprensione dei diversi modelli scientifici utilizzati nei vari software attualmente presenti (vita artificiale, agenti autonomi, apprendimento per dimostrazione), con l'impiego di modalità di interazione desunte dalle ricerche sullo Human Computer Interaction (Manipolazione diretta ed interfaccia WYSIWYG) e dai linguaggi di programmazione visiva, che permettono all'utente di programmare in modo diverso e senza avere una specifica formazione di base. Questo sistema permette la costruzione di numerosi ambienti per l'insegnamento/apprendimento: ambienti di gioco, di simulazione, micromondi, ambienti dedicati alle storie, realizzazione di mondi virtuali dove vivono agenti o robot, produzione di multimedia o di documenti di rete.

Nel costruire Living World Builder abbiamo pensato di cogliere gli aspetti comuni e didatticamente interessanti di vari programmi educativi odierni, lasciando all'utente la possibilità di costruire autonomamente il proprio mondo, all'interno del quale stabilire un processo di comunicazione/istruzione o semplicemente per divertirsi o poter vedere e sperimentare oggetti, eventi e situazioni da diverse angolazioni. Tre sono le innovazioni che permette LWB:

a) costruzione di simulazioni e micromondi in un unico ambiente;

b) analisi approfondita dei diversi programmi su cui si basa, come strumento per fare didattica comparata;

c) aiuti e supporti per l'utente finale (docenti e alunni) sia per quanto riguarda l'acquisizione dei rudimenti della programmazione sia per la progettazione di sistemi intelligenti modulari.

2. Alcuni programmi educativi che presentano importanti innovazioni

La prima generazione di programmi educativi è sicuramente riferibile al Logo (Papert, 1980), ed alla famiglia di programmi da esso derivata. Un software significativo, tra questi programmi è Microworlds, che ha incorporato all’interno della classica struttura del Logo, nuove funzionalità legate alla multimedialità. L’ambiente che questo software mette a disposizione di insegnanti e studenti è molto interessante, anche se aver mantenuto un’interfaccia del tipo Command Line Language, tipica del Logo, non ne facilita l’uso. Il principale ambiente che usa il Logo è il Micromondo.

Quasi contemporaneo al Logo, un altro software didattico, Karel the Robot (Pattis et al., 1994) propone un micromondo in cui un robot (Karel) deve eseguire alcuni compiti e risolvere un problema. Obiettivo di tale ambiente è quello di fornire i primi rudimenti del linguaggio di programmazione C e del C++. Il software Karel the Robot è un ambiente di programmazione nel quale l'utente scrive un programma per animare il robot. Il robot vive in un mondo bidimensionale (una griglia) piena di strade, dentro il quale deve evitare di andare contro le pareti e prendere piccoli oggetti per poi portarli in altri posti. L'utente crea un programma che Karel esegue, usando un menu dinamico che contiene sempre la lista delle possibili opzioni per costruire il codice del programma di uno specifico contesto. In tal modo, l'utente evita il problema di scrivere o ricordare i nomi dei comandi ed è capace di focalizzarsi su cosa è importante, ovvero lo sviluppo di un programma per far eseguire a Karel il compito che gli è stato assegnato. Il sistema inoltre, offre una panoramica sui problemi che riguardano i processi di progettazione e migliora la comprensione di alcuni concetti fondamentali della programmazione.

Dall'approccio o dalla filosofia Logo hanno preso vita due nuovi progetti, ambedue di enorme interesse per la didattica: Mindstorm e StarLogo.

Mindstorm nasce da una collaborazione tra il MediaLab del MIT e la Lego. L’obiettivo è di aggiungere al gioco LegoTechnics dei mattoncini programmabili. L’idea su cui si basa il sistema Mindstorm è molto semplice: dopo aver costruito una macchina con motori, sensori e ingranaggi, è possibile dotare questa macchina di intelligenza tramite un chip programmabile ed incorporato in un mattoncino, un po’ più grande degli altri. Mindstorm utilizza una programmazione di tipo visivo per la costruzione del programma e tramite un sistema di comunicazione è possibile incorporare tali programmi in macchine che si muovono nella realtà fisica (Martin, 1994). Infatti, con tale sistema sono costruiti robot fisici che attuano compiti reali come ad esempio evitamento di ostacoli e spostamento di oggetti, sperimentando didatticamente alcuni problemi che appartengono al settore disciplinare della Robotica (Papert, 1993).

StarLogo, che nasce sempre in seno al MIT, prende in considerazione alcuni problemi del settore scientifico denominato Vita Artificiale, attraverso l'esplorazione dei fenomeni della complessità, decentralizzazione, auto-organizzazione, adattività e riproduzione sia dei sistemi biologici (virus, popolazioni, specie) sia artificiali (traffico, costruzione e crescita di città). Lo StarLogo è stato messo a punto da Resnik (1994).

Cocoa (anche detto StageCast) è l’evoluzione di un filone di ricerca dello HCI, nato negli anni settanta e noto come interfacce per dimostrazione (Cypher, 1993). L'idea di base delle interfacce per dimostrazione (o programmazione per dimostrazione, o PBD) è che il computer impari dalle azioni che l'utente compie durante l'interazione, in modo che il sistema possa registrare in scripts, ed eseguire in seguito su nuovi dati , le preferenze e le scelte che fa l'utente quando interagisce con un software particolare. I sistemi PBD aumentano la capacità di programmazione dell'utente finale. Cocoa include anche altre due idee molto feconde: la programmazione visiva e la rappresentazione analogica. Le regole visive, utilizzate in Cocoa, ricordano agli utenti cosa gli scripts producono, e sono una versione visiva delle regole If-then, usate anche in altri programmi (Repenning, 1995). Attraverso le regole visive, gli utenti specificano il comportamento dei caratteri e nel fare questo, specificano anche la semantica delle regole, ovvero orientano il comportamento degli oggetti secondo i loro desideri. Questo tipo di azioni è detto programmazione analogica: le azioni eseguite dagli utenti sono analoghe agli effetti desiderati. Infatti, il programma Cocoa prevede che in una simulazione intervengano una serie di caratteri il cui comportamento è definibile dall’utente: operando con il mouse, attraverso meccanismi di manipolazione diretta, l'utente mostra al carattere cosa deve fare, ovvero l’utente definisce che, se si verificano certe condizioni, il carattere compia una certa azione come muoversi, cambiare forma, ecc. Il sistema è basato su una simulazione di un motore di calcolo parallelo. Ogni carattere si evolve contemporaneamente agli altri. Le simulazioni sono consultabili in rete tramite un plug-in, all'indirizzo www.stagecast.com.

Agentsheets è il più complesso e il più ricco dei vari ambienti di programmazione educativa, in quanto raccoglie l'eredità e le filosofie educative di numerosi software che lo hanno preceduto, utilizzando l'approccio degli agenti intelligenti, e quello della possibilità di progettare simulazioni, pur senza saper programmare. Anche questo programma è basato sulla simulazione di un motore di calcolo parallelo e su un sistema di agenti il cui comportamento è regolato dal verificarsi di una serie di condizioni che generano una serie di azioni. Il comportamento degli agenti viene realizzato tramite un linguaggio visivo denominato Visual Agent Talk. Le simulazioni risultanti sono molto più complesse di quelle ottenibili in Cocoa, anche se l'approccio teorico multiplo che il software utilizza è di difficile comprensione. Nonostante ciò, numerose sono le facilitazioni che un utente ha nell'utilizzare tale sistema. Il software permette infatti un utilizzo multiplo della simulazione: come semplice fruitore, guardando la simulazione e vedendo cosa succede; intervenendo nella simulazione, con l'inserimento di agenti o di altri caratteri, legati al contesto rappresentato (teatro partecipativo); come progettista della simulazione stessa, utilizzando il linguaggio di programmazione visiva. Il sistema consente di esportare le simulazioni in Java e le rende quindi disponibili tramite Internet. Una notevole funzionalità del sistema è legata al behaviour exchange, che è una repository su Internet dove sono contenuti tutti gli agenti programmati finora con questo sistema. Ogni utente può importare i caratteri ed il relativo comportamento ed utilizzarli all’interno della sua simulazione. L'approccio utilizzato va nella direzione della Economia degli Oggetti Educativi (Educational Objects Economy o EOE) (Spohrer et al., 1998, Roschelle et al., 1999) che prevede la possibilità di riutilizzo di pezzi di software, disponibili e acquisibili via rete.

ToonTalk è un programma educativo basato su grafica tridimensionale in cui il soggetto impara a programmare attraverso la ricerca e l'esplorazione di un ambiente virtuale, con l'aiuto di un aiutante che viene da un altro pianeta (Kahn, 1998). ToonTalk fornisce quattro modi differenti di apprendere: gioco libero, durante il quale il soggetto può esplorare l'ambiente; un problema da risolvere, attraverso il quale vengono introdotti gli elementi e le tecniche del software, per permettere ai bambini di costruire programmi; istruzioni visive, ovvero sequenze di immagini che mostrano come costruire il programma; e dimostrazioni, visualizzazioni che mostrano i vari elementi delle tecniche di costruzione del programma (Kahn, 1999).

L’utente costruisce i suoi programmi tramite degli strumenti particolari che stanno in un contenitore e attraverso una serie di oggetti animati che svolgono funzioni quali cancella e ripristina (un aspirapolvere), copia (una bacchetta magica), incolla (un topo con un martello). In tale ambiente, il soggetto, personificato da una serie di personaggi (un maschio ed una femmina), sbarca in un mondo virtuale e deve compiere una serie di operazioni, aiutato da Marty, il marziano, tra le quali addestrare un robot a ripetere alcune azioni. Il programma, presenta molti spunti interessanti quali l'apprendimento attraverso la scoperta e la ricerca di informazioni nell'ambiente.

Vash (Visual Agent Scripting Helper), è un software educativo realizzato presso il Centro Interdipartimentale della Comunicazione dell’Università della Calabria, già utilizzato per alcune applicazioni pratiche della didattica (Pantano, 1999). E' un sistema basato sulle tecnologie di Microsoft Agent. Tali tecnologie utilizzano dei caratteri con i quali l’utente può interagire in modo multimodale, sfruttando le possibilità del dialogo, come forma di comunicazione didattica. Vash è un sistema visivo che consente di scrivere gli script che pilotano i caratteri in modo molto semplice, utilizzando un linguaggio visivo. Questi script possono poi essere inclusi nelle presentazioni o nelle unità didattiche degli utenti o possono essere utilizzati per implementare agenti pedagogici (Bilotta, 1999b).

Per cui si può dire che i software educativi presentati appartengano a cinque categorie non esclusive:

a. basati su modelli scientifici (Agenti Intelligenti, Intelligenza Artificiale, Vita Artificiale);

b. basati sull'interazione (visivi, manipolativi, virtuali, fisici);

c. basati sulle esigenze dell'utente finale (end user programming, visual programming languages);

d. basati su alcune modalità di apprendimento (dimostrazione, ricerca, invenzione, gioco);

e. software costruito per bambini e con bambini (nuovo paradigma, vedi A. Druin, 1999).

3. Simulazione o Micromondo?

Prima di presentare il sistema implementato, ci preme sottolineare i concetti di micromondo e di simulazione, già precedentemente citati, per chiarire come tali due ambienti in qualche modo si fondano nel LWB.

Papert (1980) sostiene che un micromondo modella un sistema o un dominio per l'utente.

Gli obiettivi di un micromondo sono:

1. rappresentazione di un dominio di conoscenze;

2. esempio concreto di analisi di un determinato ambiente;

3. comprensione delle variazioni che sono presenti nell'ambiente e le loro funzioni;

4. conoscenza multidimensionale del problema.

Il micromondo rappresenta il caso più semplice del dominio anche se fornisce al soggetto che lo fruisce la possibilità di riformulare l'ambiente, per esplorare idee che vanno dal semplice al complesso, in modo incrementale (Bilotta, 1997). Il micromondo deve adeguarsi con lo stato affettivo e cognitivo del soggetto. Generalmente, gli utenti sanno cosa fare nel micromondo; infatti, poco o nessun training è necessario per usarlo. Il micromondo va incontro alle necessità del soggetto. Al contrario, la simulazione è determinata dal contenuto del dominio che rappresenta. Diverse caratteristiche della simulazione sono rilevanti per la progettazione di micromondi. Per prima cosa, nel micromondo il soggetto si aspetta di autoregolare la propria attività, sia di gioco che di apprendimento: il soggetto è responsabile delle proprie azioni e costruisce la conoscenza, assicurandosi attraverso modalità proprie che l'apprendimento avvenga attraverso processi manipolatori, sia di eventi che di oggetti. Il micromondo è altamente motivante per i soggetti. In esso, ogni utente è attivo, ovvero ha capacità di pianificazione, ha obiettivi da perseguire, ha capacità di monitorare e valutare il proprio operato. Inoltre, il soggetto struttura l'ambiente del micromondo secondo le proprie esigenze e motivazioni in modo tale che l'ambiente stesso risponda a tali esigenze e l'obiettivo stabilito venga perseguito.

Una simulazione è il tentativo di mimare un ambiente o un sistema reale o immaginario (Alessi e Trollip, 1991; Reigeluth e Scharztz, 1989), di mimare i comportamenti che all'interno di tali sistemi sono attivati e di vedere i cambiamenti di tale sistema nel tempo. Di solito, le simulazioni vivono nei computer e sono uno strumento per studiare i sistemi del mondo reale per quel particolare dominio, in una grande varietà di situazioni. La simulazione potrebbe essere paragonata ad un laboratorio computerizzato. La simulazione permette:

a. di predire il corso e i risultati di alcune azioni;

b. di comprendere perché gli eventi osservati succedono;

c. di identificare le aree, le variabili di un problema, prima di svilupparlo;

d. di esplorare gli effetti delle modifiche;

e. di confermare che tutte le variabili sono conosciute;

f. di valutare le idee ed identificare l'inefficienza del sistema;

g. di costruire previsioni e stimolare il pensiero creativo;

h. di comunicare la giustezza e flessibilità dei piani che il soggetto ha in mente.

Gli obiettivi della simulazione sono di tipo scientifico, quando si simula un fenomeno complesso, ad alti costi, nell'impossibilità di fare una esperienza diretta. Di tipo educativo, quando si progettano per insegnare ai soggetti gli elementi fondamentali di un sistema, osservando i risultati delle azioni o delle decisioni, attraverso un processo di feed-back generato dalla simulazione che può eseguire il fenomeno o in tempo reale, o in tempo rallentato, o in tempo accelerato. Attraverso la simulazione si possono anche progettare micromondi che però devono essere costruiti rappresentando il caso più semplice del sistema.

4. Le caratteristiche di LWB

Il software LWB è organizzato su diversi livelli (vedi Fig.1). Il primo livello riguarda l'interazione dell'utente con il mondo costruito e si struttura nel seguente modo:

a. esecuzione della simulazione o avvio della rappresentazione del micromondo;

b. possibilità di interazione durante la simulazione.

Il secondo livello permette all'utente la costruzione vera e propria del mondo attraverso i seguenti sottolivelli:

1. costruzione del mondo, dei caratteri e dei comportamenti dei caratteri;

2. programmazione attraverso un linguaggio visivo;

3. ridefinizione e riprogettazione del sistema, attraverso una programmazione di tipo esperto.

Nel terzo livello, l'utente sceglie il tipo di mondo da realizzare, sul modello dei vari software presentati (con tutti i problemi legati alla progettazione di ambienti legati all'esecuzione di procedure, micromondi, o al calcolo parallelo, simulazioni).

Figura 1. I diversi livelli del software LWB

Nel processo di costruzione del mondo, e passando dal primo al terzo livello livello, l'utente dovrebbe essere in grado di arrivare a dominare sia alcuni elementi fondamentali di progettazione dell'intero sistema sia alcuni concetti di base di programmazione vera e propria. Inoltre, data la possibilità di progettare mondi, sul modello di altri software esistenti, l'utente dovrebbe acquisire conoscenza sulle caratteristiche e modalità di progettazione che in tali ambienti sono possibili, migliorando la sua capacità di progettazione attraverso uno sviluppo modulare del sistema che ha in mente di realizzare.

Di seguito, presenteremo una panoramica del sistema. Una griglia di dimensione variabile, definibile dall’utente, è il primo oggetto da costruire nel LWB. In questa griglia vivono dei caratteri sintetici che si muovono in modo autonomo o effettuano delle azioni definite a priori dall’utente. Anche il passo della griglia è definibile dall’utente ed è legato alla dimensione del carattere.

Man mano che un carattere si sposta o compie delle altre azioni, occupa una posizione variabile nella griglia.

In alcuni casi, il carattere può lasciare dei segni o può cancellarli.

Negli ambienti in cui è prevista una simulazione, l’utente può interagire secondo la metafora del teatro partecipatorio (Repenning, 1993).

LWB ha tre componenti principali: il mondo dove avviene la simulazione, la galleria degli agenti (vedi Fig.2) e una componente in cui viene definito il comportamento degli agenti (o ambiente dedicato alla programmazione).

Al mondo possono essere attribuite varie caratteristiche: le sue dimensioni fisiche, un passo per la griglia, ed un passo temporale. Nella galleria degli agenti vengono definiti i caratteri e diverse possibili loro varianti iconiche. I comportamenti sono definiti attraverso un linguaggio di programmazione visiva, in cui, una determinata funzione che si vuole far compiere al carattere, viene indicata da una icona.

Figura 2: Galleria di agenti, varianti di un agente ed ambienti che è possibile realizzare

5. Gli ambienti che è possibile realizzare in LWB

In tutti gli ambienti alcune caratteristiche di base si ripetono:

a. l'utente crea la sua galleria di caratteri;

b. trascina i caratteri nel mondo ed assegna dei comportamenti;

c. i comportamenti sono realizzati attraverso un linguaggio di programmazione visiva, costruito secondo le funzionalità tipiche dell'ambiente cui si riferiscono.

5.1 Ambienti simili al Logo

Quando l'utente sceglie di costruire un ambiente simile ai micromondi Logo, in LWB si apre un pannello dove sono riportati i caratteri. Tramite un meccanismo di drag and drop, l’utente può trascinare uno o più caratteri nel mondo che sta realizzando e fargli compiere direttamente delle azioni di spostamento semplicemente cliccando sulle frecce. L’utente può o no far lasciare un segno dal carattere scelto, secondo le normali funzionalità del Logo. In questo caso, ad un’azione diretta dell’utente corrisponde uno spostamento del carattere sulla griglia.

Più complessa è l’operazione che consente al carattere di compiere sequenze di azioni o procedure. In questo caso l’utente deve prima definirle. Nei vari programmi basati sul Logo, come ad esempio Microworlds, le procedure (che possiamo considerare come la scrittura di frasi, dato un linguaggio) devono essere scritte direttamente dall'utente nella finestra dei comandi. Per fare questo, l'utente deve conoscere il linguaggio di programmazione Logo.

In LWB, l’utente può definire un proprio linguaggio di programmazione visiva, associando alle procedure delle icone e definendo, nelle fasi successive, procedure di procedure.

Come si vede nella Figura 3, le procedure di base si definiscono attraverso operazioni di drag and drop: l’utente trascina un’icona che servirà ad identificare una procedura. Per esempio, si vuole che un carattere camminando sulla griglia e lasciando una traccia, costruisca un quadrato. Successivamente, dal pannello principale l'utente trascinerà prima il carattere e le azioni di spostamento che il carattere deve compiere, per costruire il quadrato. Infine con le icone delle procedure di base, definirà procedure di procedure: per esempio, la costruzione di un quadrato. L’utente potrà eseguire le singole procedure o il loro insieme, secondo i propri desideri.

Figura 3. Il Centro Comandi di LWB e come avviene il processo di definizione delle procedure

5.2 Ambienti simili a Karel the Robot

Pur mantenendo, per questo ambiente, lo stile Logo per l’interfaccia grafica, la parte di programmazione risulta diversa. Anche il centro di comandi dell'ambiente simile a Karel è visivo e consente all’utente di definire le procedure. Due nuove funzioni rispetto al Logo sono state introdotte, quella di tirare e quella di spingere, visto che tali comportamenti possono essere compiti da assegnare al robot. L'utente può definire tutte le funzioni che vuole, a seconda delle funzioni e del comportamento che l'agente deve compiere.

5.3 Ambienti simili a MindStorm

Diversi problemi legati alla robotica possono essere affrontati, dal punto di vista didattico, nell'ambiente simile a Karel the robot. In questo caso, si tratta di dotare il robot Karel di sensori ed attuatori ed eventualmente di uno stato interno. Il contesto Karel, integrato con gli ambienti simili a MindStorm, consentono di affrontare la programmazione di robot sia virtuali che reali.

Come in MindStorm, in LWB occorre prima individuare i sensori e gli attuatori del robot e poi tararli in modo opportuno. Il resto della programmazione avviene sempre tramite un linguaggio di programmazione visiva. Nel nostro ambiente ogni motore viene pilotato tramite una finestra di costruzione, nella quale viene definita la sequenza di comandi. Man mano che ogni singolo comando viene ad essere predisposto, le finestre di configurazione si aprono automaticamente. In LWB è possibile pilotare un robot virtuale di tipo Karel e un robot reale, pilotato ad esempio da una piattaforma del tipo Handy-Board. In questo caso, occorre che il programma sia scaricato dentro la scheda, in un opportuno codice che la scheda stessa è in grado di riconoscere.

5.4 Ambienti simili a Cocoa ed a Starlogo

Il software StarLogo è particolarmente adatto dal punto di vista didattico allo studio dei problemi che riguardano l'autorganizzazione e la riproduzione, con i relativi problemi di adattività e selezione naturale in quanto si riallaccia ai problemi di Vita Artificiale e in modo particolare agli automi cellulari. Un ambiente di automi cellulari è rappresentato da una griglia, costituita da singole celle/automi, che modificano il loro stato nel corso del tempo (Toffoli e Margolus, 1987). Gli stati degli automi sono molto semplici, al limite zero/uno. Il sistema dinamico costituito da questi automi ha alcune considerevoli proprietà:

a) l’evoluzione dell’automa dipende dal proprio stato e da quello dei vicini e si evolve in base a semplici regole;

b) tutti gli automi si evolvono in parallelo, cioè ogni automa valuta il proprio stato e quello dei vicini, e si evolve contemporaneamente a tutti gli altri automi. In questo senso tali sistemi computazionali possono essere considerati come sistemi massicciamente paralleli.

Gli automi cellulari pur possedendo una varietà limitata di stati, possono esibire configurazioni collettive estremamente complesse e di notevole interesse.

Il modo in cui abbiamo realizzato l’ambiente simile a Cocoa richiama fortemente, anche a livello di programmazione, il contesto degli automi cellulari.

Lo stato degli automi/celle o processori è determinato dallo stato delle celle vicine. Gli automi possiedono uno stato rappresentato da una tra tutte le possibili immagini degli agenti presenti nella galleria. Il passaggio da uno stato all’altro avviene in funzione degli automi vicini. L’automa si evolve in base a quattro regole il cui vicinato è stato definito dall’utente:

a) l’automa ha due vicini oltre se stesso;

b) l’automa ha solo se stesso come vicino;

c) l’automa ha quattro vicini oltre se stesso (insieme di von Neumann);

d) l’automa ha otto vicini oltre se stesso (insieme di Moore).

L’evoluzione dei caratteri avviene pertanto come in Cocoa per dimostrazione, cioè l’utente mostra al carattere come si deve evolvere a seconda del suo stato e di quello dei vicini. Ovviamente l’utente configura queste regole in modo puramente visivo.

L’aver accostato l’ambiente Cocoa agli automi cellulari ci consente di cambiare le scale spaziali della simulazione e mettere in rilievo caratteristiche tipiche della vita artificiale come complessità ed autorganizazione.

In questo tipo di ambiente di LWB è possibile anche indagare i comportamenti degli automi su una scala spaziale più ampia. Infatti, abbiamo creato una corrispondenza tra gli automi e i caratteri; lo spazio dei caratteri può essere visualizzato tramite una griglia limitata che può essere sovrapposta allo spazio degli automi (vedi Fig. 4).

Abbiamo creato due ambienti di automi: nel primo le regole di evoluzione sono di tipo generale come ad esempio in Life (Langton, 1989), nel secondo sono di tipo particolare come in Cocoa. La differenza tra le due regole consiste nel fatto che le regole particolari devono prevedere la situazione specifica, lo stato esatto in ogni casella dell’intorno, mentre le regole generali tengono conto di situazioni più generali relative all’intorno. Ad esempio in Life, affinché lo stato dell'automa sia acceso basta che almeno due automi dell’intorno siano accesi, indipendentemente dalla casella a cui fanno riferimento.

Le regole di tipo generale, pur essendo meno intuitive e meno accettabili come regole di evoluzione per dimostrazione, consentono di ottenere più facilmente strutture auto-organizzanti, mentre per ottenere lo stesso risultato con regole particolari dovremmo poter fornire al sistema una grandissima quantità di queste regole.

L’ambiente che stiamo costruendo ci servirà per creare un collegamento con altri concetti che sono alla base del software Star Logo.

Figura 4. Lo spazio degli automi cellulari e la griglia che consente il trasferimento

della simulazione in un ambiente di tipo visivo

5.5 Ambienti simili ad AgentSheets

L’ultimo ambiente in LWB è basato sul concetto di agente automo e richiama il software Agentsheets. Un agente autonomo vive in un mondo reale o virtuale, è dotato di sensori per percepire lo stato dell’ambiente nel quale opera ed è dotato di effettori per modificare lo stesso ambiente. Può inoltre essere dotato di uno stato interno, possedere una base di conoscenza, avere obiettivi, essere capace di apprendere e di adattarsi all’ambiente, ecc.

Come in AgentSheets, in LWB è possibile definire un agente nella galleria ed assegnargli una gamma di immagini relative (in questa prima versione quattro variazioni dell’immagine di base). Successivamente occorre dotare l’agente di una serie di sensori e di effettori (vedi figura 5).

Figura 5. Il menu per assegnare condizioni e azioni ad un agente in LWB

In questa prima versione del programma, possiamo dotare l’agente di tre tipi di sensori: vista, udito e tatto; e gli è permesso di fare una serie di azioni relative a muoversi, spingere, tirare, mangiare, cambiare forma, generare un nuovo agente, muoversi o mangiare a caso, parlare e comunicare. Il comportamento è definito in una finestra specifica che contiene tre aree, una dove può trovare posto l’agente al quale è attribuito il comportamento, un’altra delle condizioni realizzabili dall'utente ed infine la terza dove è possibile determinare l’azione che l'agente deve eseguire (vedi figura 6).

L’agente implementato attraverso queste tecniche è un agente di tipo reattivo: il sistema valuta il verificarsi di una condizione tramite l’analisi del dato sensoriale; se una regola è associata al verificarsi di tale condizione, l’agente effettua un’azione.

In questo tipo di implementazione non c’è alcuna gerarchia tra le regole, mentre in Agentsheets esiste una gerarchia per le regole associate allo stesso tipo di agente: la successiva viene verificata se la precedente non è verificata.

Figura 6. Comportamento per l'agente asino: se vedi il leone di fronte torna indietro.

Come in Agentsheets o in Cocoa l’agente può essere dotato di uno stato interno tramite una funzione, il cui valore cambia a seconda che la simulazione procede e può, a sua volta, intervenire nelle regole comportamentali. Il risultato è però una struttura estremamente rigida senza nessun meccanismo di azione-selezione.

6. Ulteriori sviluppi

Per l'ambiente simile al LOGO, poiché nella fase di implementazione abbiamo ravvisato che la scelta di operare in una griglia non è molto funzionale quando i caratteri devono effettuare dei disegni, abbiamo pensato di realizzare un nuovo prototipo all'interno del quale il carattere è in grado di muoversi in modo continuo, nell’ambiente di simulazione.

Oltre al linguaggio visivo che l’utente autonomamente costruisce, una funzionalità che pensiamo di attivare riguarda la possibilità di scambiare procedure in rete, costruendo una banca dati, analoga al behaviour exchange, nella quale gli utenti possono scaricare o inviare le procedure da loro costruite.

Per l'ambiente simile a Karel pensiamo di implementare tutte le funzionalità del problem-solving, introducendo un agente pedagogico che supporti l’utente nella soluzione del problema, tramite suggerimenti e controllo dell’attività di programmazione svolta. Pensiamo inoltre di integrare l'agente pedagogico Noè, dedicato all’insegnamento/ apprendimento della Matematica per bambini della scuola elementare (Bilotta, Pantano, Talarico, 1998) in questo nuovo e più esteso contesto. Per l'ambiente simile a MindStorm, in futuro realizzeremo un software indipendente dalla piattaforma hardware.

Per l'ambiente simile ad Agentsheets, pensiamo di dotare gli agenti di maggiore intelligenza, fornendo loro uno stato interno più ricco, basato su un modello del mondo ed implementando sistemi di reti neurali ed algoritmi genetici. Uno dei problemi che stiamo affrontando è la parte di interfaccia, se il software ottenuto deve continuare ad avere una valenza didattica.

Bibliografia

Alessi S. M. e Trollip S. R. (1991) Computer-based instruction: Methods and development, (2nd ed.), Prentice-Hall, Englewood Cliffs, NJ.

Bilotta E. (1997) Il gioco nell'etologia e nell'Intelligenza Artificiale. Quaderni del Dipartimento di Scienze dell'Educazione, Unical, Cosenza.

Bilotta E., Pantano P. e Talarico V. (1998) Learning Math Concepts by a Visual sensorially robot. Quaderni del Centro Interdipartimentale della Comunicazione, 6, 1998, UNICAL, Cosenza.

Bilotta E. (a cura di) (1999a) I nuovi saperi. BCM, Roma.

Bilotta E. (1999b) The Illusionist, an environment for building pedagogical agents. In corso di redazione.

Cypher A. (Ed.) (1993) Watch What I Do. Programming By Demonstration, MIT Press, Cambridge MA.

Druin A. (Ed.) (1999) The Design of Children Technology. Morgan Kaufmann, CA.

Kahn K. (1998) Toon Talk home page. www.toontalk.com

Kahn K. (1999) Helping children learn hard things: Computer programming with familiar objects and actions. In A. Druin (Ed.) The Design of Children Technology. Morgan Kaufmann, CA.

Langton C. G. (1989) Artificial Life. In C. G. Langton (Ed.), Artificial Life, Volume VI of SFI Studies in the Sciences of Complexity, 1-47, Addison-Wesley, Redwood City, CA.

Martin F. (1994) Circuits to control: Learning engineering by design LEGO robots. Ph.D dissertation, MIT Media Laboratory.

Pantano P. (1999) Use of Agents for Physics Learning, in ICTE - International Conference on Technology and Education, Tampa, Florida, USA.

Papert S. (1980) Mindstorm. Basic Books, New York.

Papert S. (1993) The children's machine. Basic Books, New York.

Pattis, R. E., Roberts J. e Stehlik M. (1994) Karel the Robot: A Gentle Introduction to the Art of Programming,

Second Edition , John Wiley & Sons; NY.

Reigeluth C. e Schwartz E. (1989) An instructional theory for the design of computer-based simulations. Journal of Computer-Based Instruction, vol. 16, n° 1, 1-10.

Repenning A. (1993) Agentsheets: A Tool for Building Domain-Oriented Dynamic, Visual Environments, University of Colorado at Boulder, Ph.D. dissertation, Dept. of Department of Computer Science.

Repenning A. (1995) Bending the rules: Steps toward semantically enriched graphical rewrite rules. In Proceedings of Visual Languages, 226-233.

Resnik M. (1994) Turtles, termites and traffic jams. MIT Press, Cambridge, Ma.

Roschelle, J., DiGiano C., Koutlis M., Repenning A., Phillips J., Jackiw N., Suthers D. (1999) Developing Educational Software Components, IEEE Computer, Vol. 32, pp. 50-58.

Spohrer, J. C., Repenning A., and Dev P. (1998) Educational Object Economy: Authoring Tools for Simulations and On-Line Communities, Virtual Worlds and Simulation Conference (VWSIM '98) Simulation Series, San Diego, CA, pp. 115-116.

Toffoli, T., Margolus N. (1987), Cellular Automata Machines: a new environment for modeling, MIT Press, Cambridge, USA