Sviluppare il modello: piattaforme software

Lo sviluppo informatico di un ABM si può ormai rivolgere ad un’ampia offerta di strumenti di programmazione che sono stati messi a punto negli anni all’inter-

no della comunità dei modellisti.

Le soluzioni disponibili, sebbene si differenzino per sintassi e linguaggi cui si appoggiano, condividono il riferimento al paradigma OOP (box 2) la cui logica si allinea perfettamente con quella dei modelli ABM. E tutti possono trovare in UML un efficace riferimento per rappresentare e guidare il processo di sviluppo.

Box 2 – I costrutti fondamentali dei linguaggi OOP

La programmazione ad oggetti è rivolta allo sviluppo di software secondo una logica di riorganizzazione del codice in blocchi riferiti ad alcune entità fondamentali ( gli oggetti ) e non alla scrittura di istruzioni da ese- guire in successione (tipica della programmazione procedurale). Un programma OOP può essere visto come un ‘mondo virtuale’ costituito di oggetti (informatici) di diverso tipo. L’oggetto è l’elemento fondamentale cui si attribuiscono, in analogia con l’esperienza nel mondo reale, proprietà e comportamenti (definiti come metodi). Tra questi oggetti si stabiliscono relazioni di vario genere, uni e bi-direzionali e da queste relazioni, come dai comportamenti, si ottengono dei risultati (ouput) a partire da informazioni che hanno consentito di creare gli oggetti e orientare le loro attività (input).

Scendendo un po’ più nel dettaglio, i linguaggi OOP si fondano su alcuni elementi:

a) Classe. È il costrutto fondamentale del linguaggio e consente la definizione dei ‘tipi’ di variabili informa- tiche7 _{che faranno parte del programma. Va inteso come la ‘matrice’ di generazione degli oggetti. A livello}

di classe si stabiliscono le proprietà e i comportamenti che vengono ereditati dagli oggetti che ad essa si ri- feriscono. Un paragone improprio può essere fatto con gli insiemi della matematica. Essi rappresentano una parte di realtà (es. gli animali) definita in base a determinate proprietà comuni (tipo cellulare) e contengono le ‘variabili’ dell’insieme distinte in base a diversi valori delle proprietà che li descrivono (le diverse specie distin- te in base a ambiente, modalità di riproduzione...). Il paragone è improprio in quanto se gli insiemi, come le Classi , sono caratterizzati da omogeneità degli elementi che li compongono, essi sono anche esaustivi ovvero contengono tutti gli elementi di quel tipo, mentre le classi ne generano di infiniti. Le classi quindi definiscono le caratteristiche dei propri membri-figli-oggetti ovvero:

- proprietà o attributi, che descrivono le caratteristiche degli elementi creati (es. numero di zampe) - metodi o procedure, che definiscono i ‘comportamenti’ che i membri della classe possono tenere operando sulle proprietà (cammina, nuota, vola..)

b) Oggetti. Sono cosiddette istanze (o esemplari) della classe ovvero sono variabili informatiche caratteriz- zate da identiche proprietà e metodi (la cui specificazione varia da oggetto a oggetto definendone l’individua- lità). È proprio attraverso l’oggetto che le proprietà assumono valore e i metodi vengono eseguiti (invocati). attraverso lo scambio di messaggi tra oggetti.

c) Ereditarietà. È il principio per il quale tutti gli oggetti di una classe hanno le stesse proprietà e metodi ereditate dalla classe.

Ad una classe si possono anche riferire delle sottoclassi che, al pari degli oggetti, ereditano dalla classe madre metodi e proprietà. In questo caso però le classi ‘figlie’, diversamente dagli oggetti, possono poi riformulare sia proprietà che metodi attraverso un processo denominato overriding.

d) Polimorfismo, è una caratteristica di ‘customizzazione’ dei metodi rispetto all’oggetto che li deve appli- care. Se due oggetti sono istanze di due classi ‘figlie’ di una stessa classe madre e a livello della classe madre è stato definito un certo metodo, questo metodo può essere ridefinito nelle classi figlie e applicato sull’oggetto in base alla classe di appartenenza, senza dover duplicare i metodi. Ad esempio se si creano due sottoclassi ‘Uccelli’ e ‘Pesci’ della classe animale, è evidente che il metodo ‘spostarsi’ definito a livello di classe ‘Animali’ dovrà essere diverso se a spostarsi sarà un uccello o un pesce.

Tutti questi strumenti software consentono quindi di implementare adeguata- 7 È bene sottolineare la fondamentale diversità del concetto di variabile applicato all’am- bito informatico e statistico-matematico. La variabile informatica è una locazione di memoria che può assumere differenti valori in diversi momenti e può essere modificata dal programma/utente; la variabile statistica, rilevata su unità di osservazione, è una caratteristica che definisce aspetti di interesse di un fenomeno. In comune hanno il fatto che, appunto, possono variare.

mente e in ogni sua parte il modello per come è stato progettato e formalizzato la scelta del modellista deve essere guidata in considerazione di tre aspetti: - il grado di difficoltà del linguaggio che comporta un diverso ammontare di tempo da investire nell’apprendimento per raggiungere un livello adeguato di competenze. Su questo punto incide anche la quantità e qualità della documen- tazione di supporto;

- le prestazioni in termini computazionali, che per modelli con un elevato numero di agenti diventano una condizione imprescindibile per poter eseguire le simulazioni;

- la ‘naturale’ predisposizione alla rappresentazione degli agenti.

La scelta del modellista quindi dovrà essere operata sulla ponderazione delle proprie competenze in materia di programmazione e delle specifiche ca- ratteristiche del modello in termini di complessità della sua struttura (tipologie di agenti e regole di comportamento) e dimensioni (numerosità degli agenti). La maggior parte delle piattaforme ABM segue il paradigma “framework and library”. Adottano cioè un framework, ovvero un set di concetti standard che ri-

producono la logica di un ABM e quindi aiutano nella sua progettazione e de- scrizione e forniscono tutte le librerie di software necessarie per la sua imple- mentazione, accompagnate da una serie variabile di strumenti di supporto alla simulazione (Railsback et al. 2006).

Qui di seguito, si fornisce una breve descrizione delle principali caratteristiche, punti di forza e debolezza, dei software disponibili:

A. MASON (http://cs.gmu.edu/~eclab/projects/mason/)

Sviluppato in Java nel 2003 alla Goerge Mason University, è un’ottima soluzione per programmatori esperti che devono sviluppare modelli ad alta intensità com- putazionale determinata dall’elevata numerosità degli agenti o dalla lunghezza del periodo di simulazione. Mason offre pochi strumenti per la modellizzazione ma è molto efficiente in quanto consente la ripartizione del carico computazionale tra più macchine. Prevede anche efficaci strumenti per la visualizzazione dei risultati della simulazione, non fruibili attraverso interfaccia grafica ma solo via codice. Nel complesso è uno strumento performante che però non è accessibile se non si possiedono buone basi di programmazione ed è particolarmente ostile alla modellizzazione di ABM con una logica complessa.

B. SWARM (http://www.swarm.org/wiki/Main_Page)

Il capostipite degli strumenti software per la modellizzazione ad agenti. E’ stato sviluppato negli anni ’90 dai ricercatori del Santa Fe Institute e per anni è stato continuamente aggiornato e supportato dalla comunità raccolta intorno allo Swarm Development Group. Esiste in due versioni, Objective-c (l’originale) e Java, che ne rappresenta l’adattamento a uno dei linguaggi di

programmazione più diffuso. Le principali caratteristiche sono:

- un toolkit che comprende classi software per la pianificazione e la modelliz- zazione, un’interfaccia grafica per gestire le operazioni base, strumenti statistici e grafici per l’analisi visuale dei risultati anche in tempo reale;

- i modelli possono essere utilizzati sia in batch mode, ovvero in modalità ‘silen-

ziosa’ salvando i risultati su un file separato (guadagnando così in prestazioni) sia in modalità grafica, dove è possibile accedere intuitivamente (point and click) ai singoli agenti della simulazione e modificarne i parametri;

- è molto facile integrare strumenti esterni quali pacchetti statistici o grafici o software per il calcolo distribuito in rete.

Al netto di alcuni problemi legati alla gestione degli errori e all’incompatibi- lità di alcune librerie della versione Java con il progenitore Objective-c, il problema più rilevante di SWARM è che dopo essere stato uno standard diffuso nell’ambiente modellistico è stato progressivamente abbandonato in termini di aggiornamenti per il suo utilizzo sui nuovi sistemi operativi. Come per MASON, è necessario un buon background di programmazione per poter ottenere in tempi ragionevoli risultati significativi.

C. REPAST (http://repast.sourceforge.net/)

Sviluppato alla Chicago University, è certamente la piattaforma Java più com- pleta. Oltre alle caratteristiche di Swarm, Repast ha integrato la semplicità di esecuzione delle simulazioni aggiungendo la possibilità di interrompere e riavviare direttamente da interfaccia e un gestore di esperimenti multiple-run. Ha

una buona velocità di esecuzione e include classi per la gestione di ambienti geografici e di rete.

I limiti di Repast stanno nella difficoltà di accesso per chi non ha adeguate competenze informatiche, difficoltà dovute in massima parte a imperfezioni nella progettazione del software. In particolare: non ci sono metodi primitivi per l’esecuzione casuale di operazioni da parte di liste di agenti, che è una prassi diffusa per simulare l’esecuzione concorrente; non è prevista la possibilità di calcolare le più comuni statistiche; come per Mason e Swarm, anche Repast ha una documentazione piuttosto incompleta e una barriera all’accesso piuttosto elevata.

D. NETLOGO (http://ccl.northwestern.edu/netlogo/)

È stato sviluppato sulla base del linguaggio Logo, creato per l’insegnamento dell’informatica ai bambini. Per questa sua discendenza dal campo educativo si distingue per la facilità di uso e l’abbondante documentazione disponibile. NetLogo è un’ottima soluzione per modelli non eccessivamente complessi che sono caratterizzati da evoluzioni sul breve termine, interazioni locali e riferite

a un ambiente rappresentabile come una griglia. Non ha una velocità di esecuzione elevatissima, ma questo nella maggior parte dei casi non costituisce un problema soprattutto se rapportato all’ingente quantità di tempo risparmiata in sede di sviluppo.

La necessità di mantenere il codice all’interno dello stesso file può portare a un certo margine di disorganizzazione nello sviluppo di modelli di elevata comples- sità. NetLogo consente il controllo della correttezza sintattica del codice nel mo- mento dello sviluppo (alla stregua di un correttore ortografico) ma non dispone di strumenti efficaci di debugging, ovvero della possibilità di esecuzione parziale

del codice.

Pur avendo impliciti limiti nella capacità di elaborazione dei dati, Netlogo si sta imponendo come ‘standard’ nella modellizzazione, principalmente perché essen- do espresso in linguaggio semi-naturale è relativamente semplice da imparare per chi non possiede pregresse competenze di programmazione ed è facile da leggere per chi non ne possiede alcuna.

In termini di standardizzazione, che per i motivi introdotti sopra è un requisito fondamentale di un’attività di ricerca che pretenda di essere scientifica, la diffu- sione di NetLogo si accompagna alla diffusione del protocollo ODD . Quest’ul- timo è infatti stato pensato anche in funzione dell’implementazione informatica attraverso l’uso di NetLogo, per cui le sezioni del protocollo hanno in buona mi- sura una corrispondenza negli elementi di base del linguaggio NetLogo (Grimm 2012).

Questi linguaggi, come spesso accade nel campo della programmazione infor- matica, evidenziano un certo trade-off tra la semplicità di sviluppo e prestazioni.

In considerazione del fatto che il modello di mobilità sistematica che si presenterà nel capitolo 5 è un modello teorico e pertanto può fare a meno di integrare grandi

capacità computazionali, la scelta del linguaggio è caduta su Netlogo. In parte per il minore investimento richiesto per l’acquisizione di una competenza minima ma necessaria per lo sviluppo, in parte perché, come detto sopra, è ormai diventato uno standard diffuso nella comunità modellistica. Il che facilita lo sviluppo del modello grazie all’ampia documentazione disponibile e alle numerose risorse di supporto online e consente, in prospettiva, di avere un vasto pubblico di lettori critici, utili al miglioramento dell’implementazione. Nulla vieta, ma ci si tornerà, di ricorrere a linguaggi dalle migliori prestazioni computazionali se le successive integrazioni del modello andranno nella direzione di sviluppare un modello espli- cativo orientato cioè a rappresentare e spiegare realtà empiricamente osservate.

Capitolo 5

Un caso applicativo: un modello ABM della