6.3 Scelte progettuali
6.3.4 Astrazioni spaziali
Il survey sui linguaggi effettuato nel capitolo 3, aveva lo scopo di evidenziare le prerogative presenti nei linguaggi moderni in grado di affrontare tematiche spaziali: da questa rassegna prendiamo spunto per considerare alcune astrazioni che potrebbe essere utili introdurre nella nostra piattaforma. Analizziamo dunque alcuni aspetti e discutiamo sulle loro possibilità di inserimento nel nostro middleware in modo da arricchire quello che era stato definito livello di navigazione:
• avevamo esposto la possibilità di identificare gli agenti attraverso le loro coordinate posizionali in modo da poterne indirizzare una certa quantità in base a delle proprietà spaziali di nostro interesse. In Jade non è presente un meccanismo diretto che permetta di rinominare gli agenti cambiando il nome
CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU
MIDDLEWARE ESISTENTE 120
che gli è stato assegnato in fase di creazione; in alternativa possiamo pensare alle coordinate quali proprietà indispensabili dell’agente che vengono registra- te presso il DF come se fossero un servizio a disposizione, in tal modo chi ne richiedesse le informazioni potrebbe effettuare una sorta di selezione in merito. Questo meccanismo risulta essere abbastanza forzato e spostamenti continui porterebbero a una serie di deregistrazioni/riregistrazioni decisamente costose presso il DF: riteniamo quindi che questo stratagemma sia realizzabile solo in caso di movimenti saltuari o di aggiornamento della posizione ad intervalli non troppo ravvicinati.
• La presenza di un numero finito di agenti è discordante con l’idea di un’astrazione spaziale continua come quella di un mezzo amorfo in cui siano ovunque pre- senti delle ipotetiche entità computazionali: nel nostro caso le informazioni non scorrono tramite questo mezzo ma attraverso i canali specifici portatori di messaggi e sulla blackboard che funge da punto di raccolta. In questo mo- do riusciamo a presentare un abbozzo di semantica funzionale ma, per quan- to detto al punto precedente, difficilmente potremo rappresentare concetti di vicinanza o distanza specifica che vadano oltre la località definità dai container.
• Si era inoltre parlato di strutture gerarchiche e di grafi che gestissero l’or- ganizzazione degli agenti, in questo senso Jade non offre strutture specifiche ma consente la creazione innestata di agenti da parte di altri agenti. Questo meccanismo permette la creazione di legami fra gli agenti che possono essere interpretati generando una sorta di albero genealogico, ovviamente ogni agen- te padre ha i riferimenti a tutti gli agenti figli che ha creato quindi si possono comporre semplicemente dei grafi, anche se questo è abbastanza distante dal concetto originario a cui eravamo interessati.
• In un sistema multi-agente, va da sè che ci sia spesso la necessità di interagire con più di un agente per volta, e di conseguenza si presentino situazioni in cui si debbano selezionare i partecipanti all’azione. Nel nostro caso, si tratta per la gran parte delle occasioni di definire i destinatari di determinati messaggi, e quindi non precisamente di effettuare operazioni su insiemi di agenti, resta il fatto che in entrambi i casi le nostre possibilità si limitano alle funzionalità
CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU
MIDDLEWARE ESISTENTE 121
offerte dall’AMS e dal DF e non siano certo specifiche e spiccate come quelle viste in precedenza.
• Avevamo introdotto l’utilizzo del modello ambientale da parte degli agen- ti come una blackboard da cui leggere e su cui scrivere, essendo esso una risorsa in comune a disposizione di tutti gli agenti risultava senz’altro una pos- sibilità sfruttabile in diverse maniere. Nel nostro caso abbiamo dovuto intro- durre la blackboard proprio per consentire questo tipo di meccanismo senza limitare l’interazione a semplici messaggi. Così facendo l’ambiente viene in qualche modo rappresentato da un artefatto posizionato nel main container ma raggiungibile da tutti gli agenti della piattaforma.
• Essendo i sistemi complessi composti da più entità, si presenta l’occasione di riunire e processare dati aggregati, magari anche in seguito a una selezione su regole/predicati di natura diversa. Abbiamo provveduto a rendere possibile un meccanismo simile con l’introduzione della blackboard, la quale permette ad un agente esterno, che potremmo definire elaboratore, di selezionare le in- formazioni depositate dai worker e processarle secondo le proprie necessità. A seconda della natura e degli scopi del sistema, la struttura dati dovrà essere ov- viamente organizzata e predisposta in maniera diversa, dando la possibilità di scegliere con parametri vari e specifici quello a cui l’elaboratore è interessato.
• In alcuni casi, soprattutto in sistemi biologici, si faceva riferimento alla fusione di elementi inizialmente distinti, come potrebbe tra l’altro accadere in segui- to all’unione di due componenti differenti a favore di un’unica entità roboti- ca. Bisogna innanzitutto definire se i comportamenti dei singoli componenti rimangano immutati o se la connessione provochi mutamenti sostanziali:
nel primo caso, restando le sottoentità praticamente inalterate, non vi sono problemi di rappresentazione ma al massimo di indirizzamento uni- voco in quanto Jade continuerà a interpretarle come due entità distinte; nel secondo caso invece, non abbiamo nemmeno la possibilità di rappre-
sentazione, in quanto essa richiederebbe la costruzione a run-time di un agente con un comportamento non identificabile a priori. L’unica pos- sibilità che abbiamo a disposizione è quella di trasferire i dati in pos- sesso di una sottoentità e di fermare l’agente corrispondente, delegando
CAPITOLO 6. MAPPING ARCHITETTURA ASTRATTA SU
MIDDLEWARE ESISTENTE 122
al destinatario il compito di rappresentanza anche del mittente: questo metodo riesce a rappresentare degnamente solo situazioni in cui viene effettuata una inclusione a puro scopo informativo, in seguito alla quale la componente inclusa ha terminato il suo compito.