Bio-inspired Design Patterns in MAS

Pietro Brunetti  •  Angelo Croatti  •  Francesca Marchi
sommario

Analizzare i patterns Gossip, Gradient, e Digital Pheromones, studiandone le possibili applicazioni nel contesto MAS e contestualizzandole tramite le tecnologie JADE / TuCSoN.

Indice

Self-Organization nei Sistemi Multi-Agente

Analizzando lo stato dell’arte delle insfrastrutture software odierne e rivolgendosi con un pizzico di lungimiranza a quelle che probabilmente si andranno ad affermare nelle prossime generazioni software, è immediato osservare che la complessità in esse sta inesorabilmente aumentando, raggiungendo livelli troppo alti per le astrazioni tradizionalmente utilizzate nell’ingegneria dei sistemi software e più in generale nelle scienze informatiche. Tale scenario è caratterizzato da sistemi computazionali che possono essere considerati in molti casi ubiqui, costantemente attivi e con un livello di connettività che permette di garantire pervasività nelle interconnessioni; ciò si verifica in special modo per i sistemi su larga scala, a causa dell’emergenza di nuove tecnologie, le quali mettono a disposizione un numero sempre maggiore di dispositivi orientati alla comunicazione mobile.E’ risaputo che l’avanzamento tecnologico renda teoricamente possibile il raggiungimento di obiettivi sempre più Importanti, ma ciò introduce un innegabile livello di difficoltà, a causa dell’aumento dei requisiti imposti, come la scalabilità (in relazione al numero di utenti coinvolti, alla dislocazione geografica e del numero di risorse coinvolte), la reattività (particolarmente importante per sistemi real-time), oppure la failure tolerance.Inoltre, seguendo il trend attuale, si può supporre con buona probabilità che tutti i sistemi informatici classificati come “della generazione successiva”, denominati Complessi, saranno caratterizzati da:
  • natura intrinsecamente dinamica, dove gli aspetti computazioni sono strettamente legati all’ambiente esterno che li circonda, non permettendo più di considerarli separatamente;
  • vincoli legati alle risorse utilizzate, con l’obiettivo di ridurre i consumi e dimensioni delle parti fisiche;
  • architetture eterogenee;
  • assenza o impossibilità di un’infrastruttura e controllo centralizzati, attribuendo un peso crescente ai concetti di controllo e interazioni locali fra component.
Il contesto risultante, nel quale l’applicazione evolve e muta, appare imprevedibile rendendo molto difficile qualsiasi forma di supervisione.Per fronteggiare tali situazioni e problematiche, una nuova tendenza nella modellazione dei sistemi software complessi, è di corredare le diverse entità con un certo grado di autonomia e proattività al fine di permettere uno spontaneo incremento delle interazioni fra di esse. L’Auto-Organizzazione, così chiamato tale approccio innovativo, si profila come la tecnica "richiesta" per superare i correnti limiti tecnici; essa consente in primo luogo di decentralizzare responsabilità e carico computazionale, suddividendoli fra le varie entità (seguendo opportune regole che governano gli aspetti dinamici del sistema), rendendo possibile la progettazione di sistemi software che possono contare su una migliore scalabilità e robustezza, riducendo i requisiti computazionali necessariamente attribuiti alla singola entità che entra in gioco nell’applicativo considerato.Il termine Auto-Organizzazione si riferisce essenzialmente ad un processo di (ri)organizzazione spontaneo e prodotto a livello dinamico, che evolve con il sistema ed allo stesso tempo ne determina il comportamento in casi in cui si osservi un mutamento dell’ambiente esterno; per la prima volta stabilito formalmente negli anni 70’ dal premio Nobel Ilya Prigogine ed i suoi colleghi, tramite studio sulla termodinamica, è oggi utilizzato mediante molteplici meccanismi, i quali tipicamente coinvolgono concetti come:
  • Decentralizzazione (intesa come l’assenza di un’entità centrale che coordina e la riorganizzazione delle rimanenti parti)
  • Località (le vari entità individuali mantengono informazioni relativamente ai propri “vicini” definiti in modo relativistico come “locali”)
evitando di operare con in informazioni a livello Globale, perché troppo costoso in termini computazionali mantenerle costantemente aggiornate, disponibil e allo stesso tempo consistenti rispetto alla rappresentazioni interna (parziale) dello stato dell’ambiente esterno, per ogni servizio/entità che ne faccia richiesta.Mediante le definizioni riportate è possibile aggiungere un altro elemento alla trattazione, affermando che i sistemi multi-agente (derivanti dall’applicazione del omonimo meta-modello MAS), risultano essere un modo effettivo per progettare sistemi denominati Complessi, se correttamente coordinati tramite meccanismi risultanti dai concetti di auto-organizzazione e comportamento emergente, (il vero valore aggiunto del prodotto ottenuto), proprio perché, essendo costituiti da una molteplicità di entità chiamate Agenti, coloro che agiscono, autonomi, proattiviti ed orientati al raggiungimento di un obiettivo tramite l’esecuzione di uno specifico task, rendono possibile la risoluzione delle problematiche legate all’impossibilità di specificare o determinare l’ingegnerizzazione dei sistemi complessi e di una loro ontologia ben definità, a design-time.I sistemi MAS che si denotano auto-organizzanti sono particolarmente robusti, grazie all’intriseca adattabilità ai cambiamenti, riuscendo in questo modo ad assicurare la loro sopravvivenza; inoltre le computazioni che avvengono al micro-livello (come può essere per esempio il livello delle entità individuali) comportano l’esecuzione di semplici regole o comandi, comparate con la complessità che tali computazioni raggiungono quando si considera il macro-livello; in questo senso, il concetto di auto-organizzazione risulta, in alcuni casi, accoppiato con il comportamento emergente che il sistema software presenta, nel senso che sebbene i componenti individuali portino a termine un task relativemente semplice, nel suo insieme sono in grado di portare a compimento tasks caratterizzati da una maggior complessità (proprio perché non appaiono come il semplice risultato della somma delle parti), in modalità coerenti con le interazioni locali fra i componenti.

Modello Bio-Inspired

Se i Sistemi Auto-Organizzanti risultano essere facilmente modellabili attraverso i cosiddetti Sistemi Multi-Agente (MAS), appare spontaneo chiedersi quindi come progettare i vari agenti (e le interazioni fra essi) al fine di garantire l’auto-organizzazione del sistema. Una risposta a tale quesito può essere ricercata facendo riferimento ad un modello ispirato alle scienze naturali e, in particolare, alla biologia.In natura, è facile osservare come i vari organismi autonomi siano in grado di ottemperare alle proprie funzioni e, in questo modo, di collaborare al cosiddetto processo biologico. Oltre gli organismi, un ruolo fondamentale in natura è svolto dall’ambiente stesso, il quale costituisce lo spazio fisico in cui gli organismi risiedono e contestualmente fornisce risorse che possono essere utilizzate, consumate o modificate. Inoltre, nell’ambiente possono generarsi (in modo completamente autonomo o semi-­controllato) eventi capaci di produrre cambiamenti sull’ambiente stesso ed osservabili dagli organismi, i quali in funzione degli eventi possono attuare cambiamenti o mutazioni al proprio comportamento. La figura che segue rappresenta in maniera formale i componenti chiave del modello biologico.ByologicalModel.pngLe risorse fornite dall’ambiente possono essere modificate sia dall’ambiente stesso sia dagli organismi. Questi ultimi infatti, utilizzano le risorse dell’ambiente attraverso un proprio processo interno che termina con la restituzione all’ambiente della risorsa modificata (in parte o completamente). Gli eventi, infine, oltre ad essere naturalmente osservabili dagli organismi e portati a modificare l’ambiente, possono anche subire alterazioni provenienti dall’ambiente stesso, il quale, generalmente attraverso altri eventi semi­spontanei, può indurre al cambiamento uno specifico evento.Strutturalmente, le caratteristiche di un organismo naturale sono evidenziabili in tre aspetti:
  • Autonomia, nell’agire e reagire;
  • Proattività, nel attuare decisioni;
  • Parziale conoscenza del mondo circostante.
Le principali caratteristiche dell’ambiente sono, invece, essenzialmente due:
  • Forte dinamicità;
  • Capacità di agire su organismi e risorse.
Osservando la natura, si evince che ciò che porta i componenti chiave (organismi e ambiente) a comporre un vero e proprio sistema e a non rimanere tra loro collegati unicamente da azioni, è rappresentato dai meccanismi di comunicazione che si sono sviluppati.Per ogni organismo, oltre a compiere azioni sull’ambiente e sulle risorse, risulta fondamentale ottenere informazioni dall’ambiente stesso. Inoltre, risulta altrettanto fondamentale comunicare fortemente con molti tra gli altri organismi.La comunicazione tra organismo e ambiente avviene semplicemente osservando l’ambiente e traendo da esso le informazioni necessarie. L’ambiente non è in grado di fornire autonomamente informazioni agli organismi, sono questi ultimi a “leggere”, in base alla loro capacità, le informazioni dall’ambiente, aumentando in questo modo la propria personale conoscenza del mondo.La comunicazione più interessante invece, ovvero quella che avviene tra due o più organismi, può essere di due tipi: diretta o indiretta. Comunicare direttamente con un organismo significa fargli pervenire esplicita richiesta di informazioni ed attendere da esso (in tempi non necessariamente sincroni) una risposta coerente alla richiesta. La comunicazione indiretta, invece, si attua tra due organismi appoggiandosi all’ambiente. Un organismo deposita sull’ambiente alcune informazioni, le quali possono essere assorbite in un secondo momento da uno o più organismi interessati. Infine, va sottolineato come appaia evidente che specifiche interazioni tra i vari componenti (organismi, ambiente, risorse, eventi, ...) possano essere ottenute semplicemente attraverso conoscenze locali e parziali e, in secondo luogo, grazie (principalmente, ma non solo) alla proattività degli organismi stessi.In definitiva, quindi, il modello biologico, che per la sua natura evolutiva risulta intrinsecamente auto­organizzante, appare essere il miglior candidato dal quale trarre ispirazione per progettare le specifiche architetturali di un sistema tecnologico orientato all’auto­organizzazione.

Modello Computazionale

I modelli computazionali stanno alla base della progettazione di un qualunque sistema artificiale. Essi mostrano quali sono le entità che entrano in gioco nel sistema e illustrano i comportamenti e le interazioni che tali entità mettono in atto. Dopo aver preso in considerazione il modello Bio-Inspired, dove si è visto che le entità che entrano in gioco sono gli organismi e il relativo ambiente dove tali organismi “vivono”, emerge la necessità di applicare tali conoscenze ai sistemi artificiale. Per tale ragione si è cercato di realizzare un modello chiaramente ispirato alla biologia ma orientato al mondo dei sistemi artificiali. Il paradigma dei Sistemi Multi-Agente (MASs) è generalmente riconosciuto come il miglior paradigma per la modellazione di sistemi naturali e per lo sviluppo di sistemi artificiali Self-Organizing.Il passaggio da un modello Bio-Inspired, sintetizzabile nei due livelli denominati Organisms ed Environment, a un modello computazionali per i sistemi artificiali, non può essere applicato direttamente.BioInspiredModel.pngLe entità che interagiscono con l’ambiente, chiaramente, non sono più gli organismi naturali, ma entrano in gioco gli agenti software, entità autonome situate in un ambiente che possono precepire e influenzare. Allo stesso tempo, anche l’ambiente ha la capacità di poter influenzare gli agenti stessi.Se nel modello Bio-Inspired sono presenti gli organismi naturali che possiedono una propria collocazione intrinsica nell’ambiente con il quale interagiscono, nel modello computazionale non è così banale. Nell’ingegneria dei sistemi software, gli agenti necessitano di dispositivi che abbiano una propria capacità computazionale su cui risiedere. Tali dispositivi permettono agli agenti e all’ambiente di interagire fra di loro.Come conseguenza delle affermazioni fatte in precedenza, nel modello computazionale è stato introdotto un nuovo strato, detto Infrastructure Layer, livello indispensabile per gli agenti che vogliono interagire con l’ambiente (cioè rilevano l’ambiente attraverso i sensori o lo influenzano atttraverso gli attuatori) e comunicare con altri agenti presenti nel sistema. Oltre che per gli agenti, l’Infrastructure Layer è indispensabile per poter attuare tutti quei comportamenti dell’ambiente che vanno ad influenzare gli stessi agenti.Le entità che entrano in gioco nel modello computazionale sono:
  • Agenti (Agents), entità software autonome pro-active;
  • Infrastruttura (Infrastructure), composta da un insieme di Host e Infrastructural Agents;
  • Ambiente (Environment), spazio nella realtà in cui si manifestano gli eventi di interesse e dove si trovano tutte le infrastrutture prese in considerazione.
Ogni Agent necessita di un Host, presente nell'Infrastructure, su cui essere eseguito, per comunicare con gli altri Agents e per percepire gli eventi dell’ambiente o agire su di esso. Ogni evento, infatti, è un fenomeno di interesse che appare nell’ambiente e può essere percepito dagli Agents attraverso l’uso dei dispositivi forniti dagli Hosts.L’Infrastructure fornisce agli Agents tutti gli strumenti necessari per simulare in maniera fedele il comportamento degli organismi, e lo spazio comune dove le informazioni possono essere immagazzinate e lette da tutti gli altri Agents.Nella maggior parte dei processi biologici, l’ambiente svolge un ruolo di fondamentale importanza, dovuto alla sua naturale capacità di agire sulle entità presenti nel sistema, come per esempio, la diffusione e la rimozione di segnali chimici nell’ambiente. Per simulare anche questa capacità, il modello computazionale ha fornito ogni Hosts dell’infrastruttura di un software incorporato chiamato Infrastructural Agent (IA). Ogni IA rappresenta un entità autonoma pro-attiva che agisce sul sistema a livello infrastrutturale. Ad essa può essere attribuito l’incarico di mettere in atto tutti quei comportamenti naturali presenti negli ambienti in natura che influenzano le entità presenti, come per esempio i meccanismi di diffusione, evaporazione, aggregazione, che verranno affrontati nel corso della trattazione.Sia l’ambiente degli Agents che quello degli IAs devono essere progettati in modo tale da rispettare modelli di Self-Organization. Inoltre, gli Infrastructural Agents svolgono diversi ruoli di importanza nel sistema. Per esempio, sono fondamentale nel momento in cui gli Agents possano muoversi liberamente sui vari Hosts del sistema, oppure responsabili della gestione delle informazioni depositate o diffuse sugli Hosts.Dopo aver descritto le caratteristiche delle entità che compongono il modello computazionale, si osserva come tali entità interagiscano fra loro. Il livello più alto è rappresentato dall'entità chiamate Agents che si trovano nel sistema. Esse utilizzano il livello Infrastrutturale per farsi ospitare, comunicare con le altre entità simili, percepire, influenzare l’ambiente e per depositare informazioni nell'ambiente a disposizione di altri Agents. Il modello computazionale appena mostrato, presenta due varianti:
  • Agents liberi di muoversi sugli Hosts (in questo caso denominati più propriamente Mobile Agents);
  • Agents strettamente accoppiati agli Hosts (mobilità limitata).
La separazione fra il livello degli agenti e il livello Infrastrutturale permette di coprire una più ampia varietà di scenari. Da una parte, i primi possono essere mobili o possono essere accoppiati agli Hosts, d’altra parte, anche l'infrastrutturale stessa può essere fissa o mobile.

Analisi dell'Architettura dell'Host

Nel modello computazionale considerato si viene a delineare un’entità chiamata host, parte del livello infrastrutturale, la quale rappresenta genericamente un esecutore automatico, con capacità computazionali, situato fisicamente all’interno dell’ambiente. Il modello di seguito proposto rappresenta la struttura del singolo host, per mettere in luce la relativa composizione interna, le risorse che mette a disposizione (quindi le possibili funzioni svolte) e quali relazioni intercorrono fra quest’ultimo e gli agenti che popolano il sistema. Le principali caratteristiche di un host sono riportate di seguito.
  • spazio di memorizzazione dedicato con dimensione variabile a seconda delle caratteristiche tecniche hardware;
  • interfacce di comunicazione con le risorse dell’ambiente esterno (sensori, attuatori).
HostModel.pngOgni host può “ospitare” (in termini tecnici si tratta più precisamente di esecuzione all’interno di un contesto applicativo) un numero variabile di Agenti Software, ognuno dei quali rappresenta la parte prettamente “mentale” e “pensante” del singolo organismo; in questo senso l’host è stato introdotto per riuscire a rappresentare il “lato” fisico e concreto degli organismi biologici in natura.La relazione che sussiste fra tali agenti e l’host permette di modellare il concetto di conoscenza esclusivamente locale di ogni agente software rispetto all’ambiente che lo circonda, il quale si esplica nella consapevolezza diretta o immediata di ciò ché accade ed è contenuto all’interno dello spazio di memorizzazione, a cui ogni agente può accedere e modificarne i valori delle informazioni introdotte. Da ciò si può dedurre che il concetto di ambiente, in termini spaziali, è modellato tramite la presenza di un numero variabile di spazi di memorizzazione locali e dislocati geograficamente in posizioni differenti all’interno dell’infrastruttura, evitando in questo modo di utilizzarne uno ipotetico che sia però globale e condiviso da tutte le entità autonome del sistema, impossibile da realizzare dati i requisiti e la natura dei sistemi software considerati, definiti su larga scala.Ogni Agente Software è in grado di utilizzare, inoltre, le funzionalità messe a disposizione dall’host per interagire e percepire l’ambiente fisico esterno, per esempio nel caso in cui necessiti di ottenere informazioni, oppure voglia inferire su di esso, servendosi delle interfacce di comunicazione. Nel caso in cui più agenti siano ospitati in un medesimo host, essi avranno consapevolezza della sussistenza di tutti gli altri in modo diretto, ma non dei loro “simili” presenti su host differenti.Mentre i cosiddetti Agenti Software non sono considerati parte dell’infrastruttura, in essa si ritrova un ulteriore tipo di entità autonoma e pro­-attiva, l’Infrastractural Agent (IA), introdotta per svolgere un ruolo che risulta trasparente rispetto agli organismi che emergono dal middleware così costituito; infatti tali specifici agenti sono utilizzati per simulare alcuni comportamenti che in natura sono intrinsecamente individuabili nell’ambiente, con lo scopo di agire sugli organismi o sulle risorse stesse per coordinare e talvolta sincronizzare l’intero sistema; fondamentalmente in tali casi si operano una o più manipolazioni delle informazioni presenti in esso (in questo caso mantenute negli spazi di memorizzazione locali).\ Per svolgere tale attività, ogni host è equipaggiato con un IA, il quale, come precedentemente affermato, è stato introdotto a livello infrastrutturale, data la necessità di garantire la completa auto­organizzazione del sistema ed una spatial situatedness dell’ambiente rispetto ai singoli agenti software, questi ultimi caratterizzati, per definizione, da una conoscenza parziale del mondo che li circonda.Avendo definito le relazioni che intercorrono fra host ed agenti (siano essi IA o software agents), è possibile concludere tale fase introducendo alcuni ulteriori dettagli. In primo luogo la necessità da parte di ogni host di contenere uno ed un solo IA è sottolineata dalla relazione di Aggregazione fra i due, con una precisa semantica associata; inoltre vi sono casi contemplati nei quali ad uno specifico host non sia associato alcun Software Agent, a causa dell’ipotesi sulla mobilità di tali entità autonome (presente nella panoramica generale sul modello computazionale del sistema), utilizzando l’host solamente come entità di appoggio necessaria per contenere informazioni locali e poter prendere parte ai soli processi presi in carico dall’ambiente.

Analisi dell'Architettura del Sistema

Si propone di seguito un ulteriore modello dei componenti presenti nel sistema multi-agente, già descritto in precedenza, con l’obbiettivo di specificare le principali relazioni che intercorrono fra le tre parti fondamentali del sistema individuate, ovvero:
  • agenti software
  • infrastruttura
  • ambiente reale
Si ritiene necessario introdurre ulteriori dettagli strutturali, rispetto allo schema di base presente nella sezione principale del modello computazionale del sistema, in primo luogo per poter affrontare in modo ottimale le successive analisi, relative ad ipotetici meccanismi costruiti e modellati proprio a partire da tale rappresentazione del sistema; in secondo luogo, le successive osservazioni costituiscono la soluzione al problema affrontato in questa prima fase di analisi e progettazione: come modellare e analizzare un sistema complesso, per il quale si è utilizzato il paradigma MAS, in cui la naturale compenetrazione che sussiste fra le parti che lo compongono non è completamente definita. Nei paragrafi successivi si cercherà di dare una risposta a tale quesito.SystemModel.pngConsiderando inizialmente la suddivisione in macro-areee introdotta, si può notare che esse si differenziano in base alla posizione che assumono all’interno del sistema, nei modi seguenti.
  • Real Environment
    • come più volte menzionato rappresenta l’ambiente reale che circonda il sistema nel quale quest’ultimo è immerso;
    • consente di dare forma alle risorse considerate e poter esprimere i concetti di località, distanza;
    • la delimitazione fisica dell’ambiente dipende dallo specifico contesto di applicazione, cercando sempre di ottenere il giusto compromesso fra un buon grado di corrispondenza con la realtà e la semplificazione operata, necessaria nella fase di modellazione, effettuando scelte sulla base degli specifici scenari che si prospettano;
  • Infrastructure
    • anche in questo caso la propria delimitazione non può essere fissata a priori, data la medesima natura dell’ambiente;
    • si è voluto mettere in luce tale riquadro per la singolare caratteristica di non essere compreso integralmente nell’ambiente, infatti i vari IA non risultano in alcun modo mappabili direttamente in entità fisiche presenti nell’ambiente; tale parte software, inclusa nel middleware del MAS con funzionalità e caratteristiche “built-in”, è il risultato di un processo adattativo incrementale volto alla completa modellazione in special modo di quelle capacità che sono insite nell’ambiente in natura;
    • i sensori ed attuatori, considerando la loro parte prettamente hardware, sono situati nel modello al di fuori dello spazio logico dell’infrastruttura; essi rappresentano gli unici accessi effettivi all’ambiente esterno, mentre le loro interfacce di accesso (il controllo associato ad essi) costituiscono una parte di rilievo per il livello infrastrutturale;
    • ogni host è dislocato nello spazio fisico, ma anche all’interno dell’infrastruttura, costituendo una specifica topologia dinamica, dato che è possibile introdurre cambiamenti a seconda di quale host sia inserito o non sia più considerato dal sistema; si ipotizza inoltre che sia possibile una qualche forma di comunicazione (tipicamente basata su protocolli di rete) fra uno o più host, resa possibile grazie ad un medium di comunicazione, che agisce in modo trasperente rispetto al sistema stesso considerato e pressoché ubiquio (si suppone sia la stessa rete Internet che supporti tale requisito);
  • Infrastructural Agents & Software Agents
    • introducendo una separazione netta di questi due riquadri rispetto alle altre entità che entrano in gioco, emergono le rispettive posizioni (software/infrastractural), entrambi rappresentanti di entità autonome che “guidano” il sistema, ma che sono da quest’ultimo anche supportate.

Design Pattern per la modellazione di fenomeni naturali

In natura, molti sono i fenomeni che svolgono un importante ruolo per la comunicazione tra gli organismi e non solo. Definendo un modello computazionale che trae ispirazione dal modello biologico, è evidente come sia necessario modellare unitamente ai concetti base, come ad esempio organismi o ambiente, anche tutti quei meccanismi o fenomeni che genericamente permettono la gestione e la trasmissione di tutte le informazioni.In termini tecnici, modellare meccanismi significa necessariamente definire design patterns che possano poi essere implementati sull’una o sull’altra tecnologia.Analizzando il modello biologico, i meccanismi che possono essere isolati sono essenzialmente suddivisibili in due livelli di astrazione: il livello base e il livello composto.A livello base sono evidenziabili i meccanismi di Diffusione, Evaporazione e Aggregazione delle informazioni. Componendo tra loro i meccanismi di base, si ottengono i meccanismi di livello composto che ne rappresentano un evoluzione. In particolare, a tale livello si evidenziano i cosiddetti meccanismi di Feromoni Digitali, Gradiente e Gossip. La figura che segue illustra le relazioni che coesistono tra i vari meccanismi. patternlayers.pngPer completezza, va aggiunto che è possibile isolare anche altri meccanismi ad un livello ancora più alto di quello dei composti che tuttavia non è oggetto del presente lavoro di progetto.

Patterns Basici

Spreading Pattern

La diffusione (spreading) delle informazioni costituisce un fenomeno che in natura è guidato dall’ambiente. In un sistema computazionale multi-agente orientato all’auto-organizzazione, è necessario modellare tale fenomeno per permettere ai vari agenti di inviare progressivamente informazioni al fine di incrementare la conoscenza globale del sistema.Poichè nel modello computazionale descritto ogni agente è in grado di sostenere unicamente interazioni locali, il problema che si pone nella modellazione del pattern per lo spreading è dato dalla necessità di colmare la mancanza di conoscenza globale del sistema da parte di ogni agente. Un tale ostacolo, tuttavia, può essere superato definendo il concetto di agente vicino (neighbour agent). Ad ogni agente, infatti, deve essere possibile associare una lista di agenti vicini con i quali l’agente può comunicare direttamente e ai quali può inviare informazioni.Formalmente, il processo di spreading può essere descritto in termini matematici dalla seguente regola di transizione.
SPREADING: {{{<}}} L,C {{{>}}} &rarr; {{{<}}} L<sub>1</sub>,C<sub>1</sub> {{{>}}}, ..., {{{<}}} L<sub>n</sub>,C<sub>n</sub> {{{>}}}
where {L<sub>1</sub>, ..., L<sub>n</sub>} = &nu;(L) and {C<sub>1</sub>, ..., C<sub>n</sub>} = &sigma;(C,L)
La regola di transizione stabilisce che l’informazione C presente sull’host L può essere trasmessa a tutti e soli gli host identificati dalla funzione ν(L), in quanto tale funzione restituisce la lista di host vicini ad L. E’ bene sottolineare che il risultato della funzione ν(L) non può essere una lista vuota né tantomeno una lista composta dal solo elemento L; essa deve infatti contenere almeno un host vicino ad L ed, eventualmente, anche l’host L stesso. Inoltre, è contemplata anche l’ipotesi che l’informazione C da diffondere cambi durante il processo di spreading: questo possibile cambiamento è descritto dalla funzione σ(C,L).Dal punto di vista progettuale, le entità coinvolte nel processo di spreading sono essenzialmente tre per ogni nodo: un agent, l’host e l’infrastructural agent dell’host stesso. L’avvio del processo avviene quando un agente del sistema, generalmente osservando il verificarsi di un evento, notifica una nuova informazione all’host in cui risiede, tramite lo spazio delle informazioni condivise. Così facendo, oltre a rendere disponibile l’informazione ad eventuali altri agenti presenti sul medesimo host, esso permette all’infrastructural agent dell’host stesso di reagire e di diffondere quindi a tutti gli host vicini la stessa informazione. Il meccanismo di diffusione verso gli host vicini è realizzato dall’infrastructural agent dell’host iniziale mediante l’algoritmo di broadcast, che permette di raggiungere tutti gli host vicini e depositare nel loro spazio di memoria condivisa la nuova informazione. La presenza di una nuova informazione nei vari host vicini, tuttavia, innesca un fenomeno a catena, risvegliando cioè i relativi infrastructural agents, i quali a loro volta diffonderanno l’informazione ai loro vicini ricorsivamente fino a raggiungere tutti gli host del sistema.Va precisato che, poiché tra l’elenco degli host vicini relativo ad uno specifico host può comparire anche l’host stesso, quando ad un host arriva una nuova informazione, il relativo infrastructural agent effettua necessariamente un controllo sull’informazione ricevuta per evitare di innescare la non terminazione del fenomeno di diffusione. Il modello che segue rappresenta in maniera più formale il meccanismo di diffusione.SpreadingPattern.pngPer quanto il pattern di spreading possa essere efficiente, è fondamentale precisare come l’uso frequente di tale tecnica possa sovraccaricare in modo pericoloso il sistema. Effettivamente, se il numero di agenti che contemporaneamente vogliono diffondere informazioni è elevato, il numero di comunicazioni tra host innescate è decisamente alto e cresce esponenzialmente in funzione del numero di host del sistema.

Aggregation Pattern

Il continuo diffondersi di informazioni nel sistema porta inevitabilmente ad un suo sovraccarico. Spesso, tuttavia, molte informazioni possono essere unite tra loro in quanto rappresentano un unico contesto informativo. Per ridurre il carico del sistema e, in secondo luogo, per riorganizzare le informazioni, ispirandosi sempre al contesto naturale, viene introdotto il pattern Aggregation. Formalmente, il meccanismo di aggregazione è descritto dalla seguente regola di transizione.
  AGGREGATION: {{{<}}} L,C<sub>1</sub> {{{>}}}, ..., {{{<}}} L,C<sub>n</sub> {{{>}}} &rarr; {{{<}}} L,C'<sub>1</sub> {{{>}}}, ..., {{{<}}} L,C'<sub>m</sub> {{{>}}} \
where {C'<sub>1</sub>,...,C'<sub>m</sub>} = &fnof;({C<sub>1</sub>,...,C<sub>n</sub>}) and (m &laquo; n)
Viene definito infatti come la trasformazione di una serie di informazioni {C1,...,Cn} interne ad uno specifico host L, in una nuova serie di informazioni {C'1,...,C'm} con una cardinalità generalmente inferiore a quella della serie di partenza, mediante la funzione ƒ(). In particolare, si noti che la nuova serie di informazioni aggregate rappresenta per il sistema un contenuto informativo diverso da quello in input al processo di aggregazione stesso. Quindi, qualora tale processo venga utilizzato unitamente al meccanismo di diffusione, la presenza di un nuovo contenuto informativo innesca intrinsecamente la sua stessa diffusione.Risulta possibile aggregare sia informazioni ricevute per effetto del meccanismo di diffusione, sia informazioni relative a misure effettuate sull’ambiente attraverso sensori. Inoltre è possibile aggregare anche informazioni specifiche prima che queste vengano diffuse agli altri host. Il modello che segue rappresenta in maniera più formale il meccanismo di aggregazione.AggregationPattern.pngL’aggregazione di informazione avviene applicando alle informazioni stesse specifici operatori, classificabili in quattro gruppi:
  1. Filtri, che selezionano un sottoinsieme specifico di informazioni;
  2. Trasformatori, che modificano specifiche informazioni;
  3. Miscelatori, che uniformano uno specifico gruppo di informazioni restituendo un’unica informazione compatta;
  4. Aggregatori, che applicano specifiche funzioni (matematiche e statistiche) ad un insieme di informazioni.
Mediante tali operatori, perciò, il processo di aggregazione riduce notevolmente il carico di informazioni di uno specifico host e, poichè presumibilmente ogni host attua il meccanismo, dell’intero sistema.Sebbene possa essere ovvio che il processo di aggregazione venga effettuato da un agente software come risultato di una propria scelta, risulta teoricamente possibile che anche l’infrastructural agent di uno specifico host possa aggregare informazioni presenti sullo spazio locale secondo proprie politiche di gestione della conoscenza. Allo stato attuale si è preferito inibire quest’ultima possibilità, pur mantenendo massima la generalità nei contenuti. Infine, il pattern aggregator costituisce una valida soluzione per la riduzione dei problemi di sovraccarico del sistema dovuti al meccanismo di diffusione. Aggregare informazioni infatti può portare a drastiche e positive riduzioni del numero di messaggi inviati nel sistema col meccanismo di diffusione, aumentandone quindi le performance.

Evaporation Pattern

Nel modello biologico si evince chiaramente che molte informazioni, col trascorrere del tempo, diventano obsolete e quindi non più utili ai fini del sistema. Per questo motivo, l’ambiente e gli organismi attuano fenomeni specifici affinchè sia possibile eliminare tali informazioni. Per tradurre questo fenomeno nel modello computazionale è necessario introdurre il pattern evaporation, formalmente definito dalla seguente regola di transizione.
EVAPORATION: {{{<}}} L,C {{{>}}} &rarr; {{{<}}} L,C' {{{>}}} \
where C' = &epsilon;(C,E<sub>&fnof;</sub>)
Per attuare il meccanismo di evaporazione, ad ogni informazione del sistema è associato un valore detto di rilevanza, calcolato dalla funzione ε() attraverso un prefissato fattore di evaporazione Eƒ. Periodicamente, la funzione ε() aggiorna i valori di rilevanza Relc di ciascuna informazione C all’interno dello specifico host L riducendo tale valore in base al fattore di evaporazione secondo la formula
Rel<sub>c'</sub> = Rel<sub>c</sub>*E<sub>&fnof;</sub> \
 where E<sub>&fnof;</sub> &isin; {{{[0, ..., 1]}}}
Relativamente al modello computazionale, il meccanismo di evaporazione viene eseguito da qualunque agente abbia necessità di modificare la rilevanza di una o più informazioni presenti nell’host. Inoltre, è incarico specifico dell’infrastructural agent relativo ad un host di modificare periodicamente, secondo politiche prestabilite (generalmente in termini temporali ovvero per obsolescenza delle informazioni), la rilevanza delle informazioni e di eliminare poi tutte quelle la cui rilevanza raggiunge quota zero. Il modello che segue descrive tale meccanismo.EvaporationPattern-SWA.pngEvaporationPattern-IA.pngE’ ovvio osservare che il corretto dimensionamento del fattore di evaporazione ad ogni esecuzione del meccanismo è ciò che garantisce efficienza e consistenza a tutto il pattern. E’ fondamentale infatti che il fattore diminuisca, tuttavia la diversa rapidità di dimuinuzione può portare serie conseguenze al sistema. Da un lato, infatti, una forte riduzione del fattore di evaporazione porta ad eliminare velocemente le informazioni obsolete garantendo al sistema grande adattabilità ai cambiamenti ma anche a rischiare di eliminare informazioni che non siano ancora propriamente obsolete. Dall’altro lato, una lenta riduzione del fattore di evaporazione rischia di rallentare il sistema per via del carico delle informazioni inutili ma consente di valutare in modo appropriato e graduale l’effettiva utilità o inutilità delle diverse informazioni.Infine, l’uso del pattern evaporation garantisce robustezza al sistema in quanto consente di aumentare la tolleranza al “rumore” introdotto potenzialmente da informazioni errate o inconsistenti, le quali potendo essere eliminate per evaporazione (eventualmente anche velocemente, nel caso si capisca in tempi rapidi che tali informazioni risultino essere corrotte) non comportano danni consistenti all’evolvere del sistema.

Patterns Composti

Gradient Pattern

Il gradiente costituisce un pattern composto, il quale utilizza necessariamente i meccanismi elementari di diffusione ed aggregazione, descritti precedentemente, per poter propagare ed eventualmente manipolare informazioni caratterizzate da una maggior ricchezza nei contenuti; in particolare introduce i concetti di distanza e direzione, entrambi utili per incrementare la consapevolezza delle entità autonome coinvolte riguardo alla posizione assunta dalla sorgente di invio dell’informazione, nei casi in cui essa si trovi al di fuori del raggio di comunicazione.In ambienti caratterizzati da un alto grado di dinamicità dovuto a rempentini o frequenti modifiche a livello di topologia del sistema, tale pattern introdotto è in grado di mettere a disposizione un ulteriore meccanismo (evaporazione) per rendere possibile, con un determinato grado di libertà, l’adattamento ai cambienti topologici verificatisi nell’infrastruttura di rete che rende possibile il transito delle informazioni. In particolare, l’informazione diffusa, così strutturata, può essere soggetta ad evaporazione, riducendo la sua rilevanza nel tempo, e quindi rappresentativa del periodo temporale di attività dell’host da cui si è diffusa. Questa’ultima variazione possibile attribuisce al pattern il nominativo di Active Gradient.Il pattern Gradients è descritto dalle seguenti regole di transizione.
GRADIENT(spreading): {{{<}}} L, {{{[}}} D,DIR,C {{{]}}} {{{>}}} &rarr; {{{<}}} L<sub>1</sub>, {{{[}}} D<sub>1</sub>&plusmn;&Delta;D,DIR',C<sub>1</sub> {{{]}}} {{{>}}}, ..., {{{<}}} L<sub>n</sub>, {{{[}}} D<sub>n</sub>&plusmn;&Delta;D,DIR',C<sub>n</sub> {{{]}}} {{{>}}} \
where {L<sub>1</sub>, ..., L<sub>n</sub>} = &nu;(L) and {C<sub>1</sub>, ..., C<sub>n</sub>} = &sigma;( C,L )
Il mecanismo di diffusione (spreading) utilizzato rappresenta il contenuto informativo come una tripletta, rispettivamente composta dal valore della distanza D della sorgente, la direzione DIR in cui si sta diffondendo l’informazione ed infine il vero e proprio contenuto informativo.La distanza è calcolata ad ogni passaggio tramite un’operazione di somma/sottrazione rispetto all’incremento/decremento osservato (la cui semantica attribuita si ritiene debba rimane del tutto generale dato il livello di astrazione considerato); il valore della direzione rimane invariato nei passaggi che si susseguono.L’ipotesi che l’informazione C da diffondere cambi durante il processo di spreading è descritta dalla funzione σ(C,L), precedentemente affrontata nella definizione delle regole di transizione per il pattern spreading; ciò mette in luce la flessibilità dei comportamenti contemplati, infatti è possibile diffondere le informazioni “originali” (senza manipolarle tramite aggregazione), oppure eseguire su di esse un’operazione di filtraggio o selezione.Per quanto riguarda il meccanismo opzionale di evaporazione, la funzione ε applicata per la manipolazione del contenuto informativo fa riferimento al paragrafo relativo all’omonimo pattern basico.
GRADIENT(ContentAggregation): {{{<}}} L, {{{[}}} D,DIR,C<sub>1</sub> {{{]}}} {{{>}}}, ..., {{{<}}} L, {{{[}}} D,DIR,C<sub>n</sub> {{{]}}} {{{>}}} &rarr; {{{<}}} L, {{{[}}} D,DIR,C'<sub>1</sub> {{{]}}} {{{>}}}, ..., {{{<}}} L, {{{[}}} D,DIR,C'<sub>m</sub> {{{]}}} {{{>}}} \
where {C'<sub>1</sub>, ..., C'<sub>m</sub>} = &fnof;( {C<sub>1</sub>, ..., C<sub>n</sub>} ) and (m &laquo; n)
GRADIENT(DistanceAggragation): {{{<}}} L, {{{[}}}D<sub>1</sub>,DIR,C {{{]}}} {{{>}}}, ..., {{{<}}} L, {{{[}}} D<sub>n</sub>,DIR,C {{{]}}} {{{>}}} &rarr; {{{<}}} L, {{{[}}} D',DIR,C {{{]}}} {{{>}}} \
where D' = min/max( {D<sub>1</sub>, ..., D<sub>n</sub>} )
GRADIENT(DirectionAggregation): {{{<}}} L, {{{[}}} D,DIR<sub>1</sub>,C{{{]}}} {{{>}}}, ..., {{{<}}} L, {{{[}}} D,DIR<sub>n</sub>,C{{{]}}} {{{>}}} &rarr; {{{<}}} L, {{{[}}} D,DIR',C{{{]}}} {{{>}}} \
where DIR' =(DIR<sub>1</sub> × DIR<sub>2</sub> × ... DIR<sub>n</sub>)
Dato che il contesto informativo che identifica un gradiente è costituito da un valore che ne indica la distanza, uno per specificare la direzione ed uno ulteriore che ne rappresenta il contenuto informativo, è possibile applicare tre differenti tipologie di aggregazione (le quali rappresentano le unità costitutive utilizzate anche in aggregazioni composte), nel caso in cui siano presenti localmente una molteplicità di gradienti; la logica e lo scopo generale vigenti per il meccanismo di aggregazione rimangono invariate rispetto a quanto riportato nella relativa sezione dei pattern basici.L’aggregazione per contenuto (ContentAggregation) rispecchia il meccanismo standard di aggregazione già affrontato, applicabile quando sono presenti più gradienti aventi le medesime direzioni e distanze dalle sorgenti (anche differenti); l’operazione di aggregazione per distanza (DistanceAggregation) può essere applicata quando i diversi gradienti fanno riferimento al medesimo contenuto informativo e valore della direzione (stessa informazione di base che ha seguito cammini differenti), effettuando sempre un’operazione di filtraggio che consiste, per esempio, nella selezione dei valori di D, riportando solamento il valore minimo o massimo, a seconda delle esigenze e della logica aplicativa. Concludendo, l’aggregazione per direzione (DirectionAggregation) risulta applicabile qualora i diversi gradienti facciano riferimento ai medesimi valori di C e D (stessa informazione di base che ha seguito cammini differenti), applicando sempre un’operazione di filtraggio che restituisce, in questo caso specifico, la direzione risultante calcolata come prodotto vettoriale dell’insieme considerato.
GRADIENT(evaporation): {{{<}}} L,C {{{>}}} &rarr; {{{<}}} L,C' {{{>}}} \
where C' = &epsilon;(C,E<sub>&fnof;</sub>)
L’intero meccanismo opzionale di evaporazione sopra riportato, è descritto nel relativo paragrafo introdotto per l’omonimo pattern basico, nel quale si esplica la semantica attribuita alla funziona ε applicata per la manipolazione del contenuto informativo. Dal punto di vista dei ruoli svolti dalle entità del sistema, si osserva che sono anch’essi il risultato di una composizione di quelli individuati all’interno dei patterns basici ed il gradient pattern non impone particolari limiti a questi, quindi non si riportano sostanziali variazioni nella progettazione comportamentale. Si ritiene comunque necessario rappresentare in maniera più formale il comportamento del sistema nel suo complesso per la gestione dei gradienti, tramite i seguenti modelli.GradientInit.pngTale modello rappresenta il comportamento del sistema all’atto della del gradiente; il comportomaneto riportato si suddivide in due stadi, in relazione all’enità del sistema che entra in gioco; nel primo il Software Agent calcola la direzione da attribuire al gradiente, ne specifica la natura del gradiente (scegliendo se introdurre nel sistema un gradiente con un coefficiente di evaporazione associato), in base alle esigenze derivanti dallo scopo da perseguire ed in fine crea effettivamente il gradiente, tramite il metodo createGradient, il quale si ipotizza utilizzabile in due distinte modalità. All’interno di tale metodo si è prevista l’impostazione della distanza al valore iniziale 0, mentre il coeficiente di evaporazone (se si tratta di un Active Gradient) è settato al valore unitario 100, espresso in percentuale. Il secondo stadio è volto alla diffusione dell’informazione prodotta, dopo averla resa disposinibile all’interno dello spazio di memorizzazione locale ed aver effettuato la selezione del sottoinsieme di hosts (partendo dal considerare la lista di quelli identificati come “vicini”, rappresentata dal parametro nbList) che costituirà l’insieme dei riceventi, sempre in relazione alla direzione desiderata.GradientSend-Receive.pngNella generica fase di ricezione, gestione e successiva diffusione di un gradiente, ogni qualvolta si rileva la presenza di un nuovo gradiente, l’Infrastractural Agent reagisce ad essa, dando inizio al processo di aggiornamento e diffusione del gradient corrente.Per prima cosa aggiorna l’informazione relativa alla distanza che lo separa dalla sorgente ed eventualmente esegue i controlli necessari sul valore di evaporazione, tramite l’esecuzione del metodo editGradient; in secondo luogo tale agente può decidere quale azione effettuare, in particolare se continuare nella naturale catena di eventi per giungere linearmente alla diffusione del gradiente ad altri hosts, oppure introdurre una fase intermedia costituita da un’operazione di aggregare su un eventuale insieme di gradienti distinti (si veda il concetto di contesto informativo del gradiente per maggior chiarimenti) nelle modalità riportate nel modello. In quest’ultimo caso, non si è specificato quale tipologia di agente effettui l’operazione di aggregazione, perché, proprio a causa delle caratteristiche dello stesso pattern, l’entità specificata varia a seconda delle specifiche politiche introdotte.Si sottolinea come in entrambi i modelli comportamentali non si sia volutamente specificata la modalità di calcolo della direzione, né il principio in base al quale si riesca ad ottenere la lista dei possibili riceventi, perché tali concetti fanno riferimento alle specifiche tecnologie con le quali si sono strutturate e composte le architetture utilizzate nella successiva fase di sperimentazione. Inoltre si può osservare come, in generale, l’informazione relativa alla direzione sia impostata solamente all’atto dell’inizializzazione di creazione del gradiente; ciò significa che i successivi host saranno selezionati se questi rientrano nel range che risulta congruente con la direzione iniziale/aggregata, anche nella fasi intermedie del processo di diffusione a catena.

Digital Pheromones Pattern

Tale pattern è stato introdotto come soluzione a problematiche di coordinazione relative a comunicazioni che avvengono in modo indiretto, molto comuni in sistemi auto-organizzanti; traendo ispirazione dall’ambiente naturale, il feromone digitale costituisce una impronta, marca digitale, depositata dal Sw Agents nell’ambiente (l’host sul quale risiede), per fungere da segnale, evento utilizzabile per riuscire a strutturare un metodo di comunicazione prettamente indiretto con gli altri organismi (entità autonome) del sistema. Dato che è introdotto nell’ambiente e potenzialmente può pervenire ad ogni entità del sistema, è importante che il contenuto informativo sia corredato da informazioni che ne specifichino la distanza dalla sorgente che l’ha generata, la direzione di propagazione e, non meno importante, un riferimento temporale indicante la freschezza dell’informazione, in modo tale da emulare il caratteristico livello di concentrazione dei feromoni in natura. Mediante questa prima descrizione, si può ora definire il Digital Pheromone pattern come un pattern composto che utilizza i pattern Gradient ed Evaporation; conseguentemente i feromoni non sono altro che gradienti diffusi in modo esaustivo all’interno del sistema, con un determinato intervallo di attività, necessario per incrementare l’attualizzazione delle informazioni e, quindi, adeguarsi ai rapidi cambiamenti che si osservano in ambienti fortemente dinamici. Dal punto di vista strutturale, il meccanismo dei feromoni digitali è essenzialmente costituito dagli stessi elementi che compongono l’Active Gradient pattern, come si è potuto notare dai requisiti necessari elencati per i feromoni; ciò che differenzia questi due pattern compositi è da ricercare nella semantica attribuita alla definizione di comunicazione indiretta, infatti mediante il meccanismo dei feromoni digitali è responsabilità unica degli Agenti Software rendere accessibili le informazioni sotto-forma di traccia, sparse indefinitamente nella porzione di ambiente con il quale riescono ad interagire/inferire, mentre i meccanismi di diffusione, evaporazione e soprattutto di aggregazione risultano completamente trasparenti agli occhi delle prime entità autonome citate, perché, in questo caso, tali azioni sono attribuite al comportamento, che in natura è proprio dell’ambiente stesso, degli IA.

Gossip Pattern

Il pattern denominato Gossip trae ispirazione dall’omonimo comportamento tipicamente umano di diffondere informazioni basandosi esclusivamente sulla conoscenza, limitata e parziale, di altri individui, dando vita al fenomeno conosciuto a livello internazionale come rumor.A differenza dei primi due pattern compositi, quest’ultimo si discosta dall’ambiente prettamente naturale; esso rappresenta nel modo migliore il concetto di condivisione di informazioni comuni, incrementalmente “assimilate” con lo scopo di aumentare la conoscenza individuale e rappresentarne pienamente la rapidità di diffusione.Considerando il livello del modello computazionale, il Gossip pattern è costituito dalla composizione dei pattern basici Aggregation e Spreading, utilizzati in un meccanismo concettualmente differente in relazione ai patterns Gradient e Digital Phermones, perché in esso si diffondono le medesime informazioni ricevute se non ne è presente alcuna di originale, individuabile solamente a livello locale; negli altri casi è necessario effettuare sulla totalità delle informazioni contenute nello spazio di memorizzazione locale un’operazione di aggregazione, con lo scopo di introdurre un nuovo contenuto informativo, caratteristica essenziale per poter terminare il processo mediante diffusione. \ Tale comportamento consente di incrementare rapidamente la conoscenza locale che ogni agente ha del sistema, eseguendo un’operazione di diffusione solamente se vi sono aggiornamenti considerevoli per il livello di conoscenza raggiunto.Il pattern Gossip è descritto dalle seguenti regole di transizione.
GOSSIP(Aggregation): {{{<}}} L,C<sub>1</sub> {{{>}}}, ..., {{{<}}} L,C<sub>m</sub> {{{>}}}, {{{<}}} L, {{{[}}} Rcd,C<sub>m+1</sub>  {{{]}}} {{{>}}}, ..., {{{<}}} L, {{{[}}} Rcd,C<sub>n</sub> {{{]}}} {{{>}}} &rarr; {{{<}}} L,C'<sub>1</sub> {{{>}}}, ..., {{{<}}} L,C'<sub>k</sub> {{{>}}} \
where {C'<sub>1</sub>, ..., C'<sub>k</sub>} = &alpha;( {C<sub>1</sub>, ..., C<sub>n</sub>} ) and (k &laquo; n)
Nell’operazione di aggregagazione, realizzata nella formula sovrastante dalla funzione α, si considerano come operandi i contenuti di tutte le informazioni che rappresentano un gossip all’interno dell’host corrente, i quali possono essere presenti solamente a livello locale (es. < L,C1 >), oppure essere il risultato della precedente ricezione di un gossip (es. < L, [ Rcd, Cm+1 ]>); in quest’ultimo caso si osserva la presenza dell’attributo Rcd (Received), utilizzato per specificare la natura del vero e proprio contenuto informativo (in questo caso Cm+1). Ad ogni modo, dopo l’aggregazione si ottengono nuove informazioni locali, strutturate come gossip, indipendente dalla natura di quelle di origine.
GOSSIP(BridgeSpreading): {{{<}}} L,C' {{{>}}} &rarr; {{{<}}} L<sub>1</sub>, {{{[}}} Rcd,C' {{{]}}} {{{>}}}, ..., {{{<}}} L<sub>n</sub>, {{{[}}} Rcd,C' {{{]}}} {{{>}}}
GOSSIP(IncSpreading): {{{<}}} L,C'' {{{>}}} &rarr; {{{<}}} L<sub>1</sub>, {{{[}}} Rcd,C'' {{{]}}} {{{>}}}, ..., {{{<}}} L<sub>n</sub>,{{{[}}} Rcd,C'' {{{]}}} {{{>}}}
where {L<sub>1</sub>, ..., L<sub>n</sub>} = &nu;(L) and C' = ( C &or; {{{[}}} Rcd,C {{{]}}} )  and C'' = &alpha;( {C<sub>1</sub>, ..., {{{[}}} Rcd,C<sub>n</sub> {{{]}}}} )
Il processo di diffusione considerato si discosta dal classico meccanismo descritto dal pattern Spreading, perché in esso si aggiunge l’attributo Rcd come marcatore al contenuto informativo; si è ritenuto necessario introdurre due varianti della regola di transizione originale per modellare compiutamente il processo di diffusione, dove la prima, BridgeSpreading, rappresenta la diffusione nei casi in cui non si debbano eseguire operazioni di aggregazione, in particolare all’atto di inizializzazione del gossip (C’ = C), o in mancanza di altre gossip-informazioni utilizzabili (C’ = [ Rcd,C ]).La casistica contemplata dalla regola di transizione denominata IncSpreading fa riferimento alla situazione in cui il contenuto informativo (C’’) sia il risultato dell’aggregazione di tutte le informazioni classificate come gossip.Focalizzando ora l’attenzione sui ruoli assunti dalle entità nel sistema, il Software Agent continua ad essere responsabile della creazione del gossip, ovvero della sua inizializzazione; invariata rimane la situazione riguardante i meccanismi di aggregazione e spreading, anche se in linea generale il comportamento attribuito ad esse deve soddisfare tre requisiti fondamentali:
  1. aggregazione necessariamente eseguita in presenza di un numero di gossip maggiore di uno ed portata a termine dal Sw Agent (quando presente), per garantire l’invio delle sole informazioni aggiornate;
  2. gestione del gossip da parte del IA, se non è presente alcun Sw Agent nell’host considerato, agendo da “ponte” all’interno del processo di diffusione;
  3. aggiunta dell’attributo Rcd all’atto dell’invio del gossip nel sistema.
Mediante il seguente modello si mettono in luce i passaggi che permettono di classificare tali meccanismi all’interno del gossip pattern.GossipPattern.png

Ciclo di vita dell'Infrastructural Agent

Per come è stato descritto il modello computazionale, un ruolo centrale e di primaria importanza è certamente svolto dai vari Infrastructural Agent presenti ed associati ai diversi host del sistema. Simulando il comportamento dell’ambiente reale, infatti, sono loro a svolgere la maggior parte delle attività associate alla gestione/diffusione delle informazioni all’interno del sistema. Per questo motivo, risulta necessario analizzare dettagliatamente come, una volta inizializzato, ogni Infrastructural Agent operi in autonomia.Viceversa, non è interessante analizzare il comportamento di ogni agente software del sistema, essenzialmente per due motivi. Primo, ogni agente ha un proprio scopo computazionale che potrebbe anche essere unico all’interno del sistema; secondo, gli agenti software hanno in comune tra loro solamente il fatto di risiedere sul sistema e di comunicare con un host che non necessariamente risulta essere lo stesso durante l’intero tempo di vita dell’agente (mobilità degli agenti software). Perciò, le specifiche relative ad ogni agente software sono proprie dell’agente stesso e devono unicamente rispettare l’interfaccia di comunicazione prescelta affinché sia possibile per loro interagire col sistema. La figura che segue, illustra il cosiddetto Lifecycle per ogni Infrastructural Agent ed, essenzialmente, si compone di due macro fasi: la prima in cui l’infrastructural Agent viene inizializzato (contestualmente all’aggiunta di un nuovo host nel sistema) e la seconda, subordinata alla prima, in cui l’Infrastructural Agent risulta in uno stato proattivo e può quindi operare. IALifecycle.png

Fase di Inizializzazione

In questa fase, l’IA viene inizializzato con tutte le informazioni a lui necessarie per poter operare. Quando un nuovo host interviene nel sistema, infatti, il proprio IA ha come unica esigenza quella di riempire la cosiddetta lista dei vicini, ovvero esso ha la necessità di sapere chi sono gli host a lui vicini. Per ottenere tale lista, l’IA interessato crea un opportuno messaggio ad hoc (Initialization Message) che invia in broadcast sul sistema e quindi si pone in attesa di risposte specifiche. Tale attesa è subordinata in termini di tempo alla capacità di reazione degli IA relativi agli host vicini, ma in ogni caso non può essere infinita. Una possibile politica di gestione dell’attesa potrebbe essere basata sul concetto di timeout. In particolare, l’IA resta in attesa di risposte per un tempo prefissato, dopo il quale assume di non avere vicini all’interno del sistema in quel momento e inizializza, pertanto, la propria lista di vicini con una lista vuota, procedendo quindi con la fase successiva. Viceversa, se entro il timeout riceve almeno una risposta, aggiunge il mittente di ogni risposta alla propria lista di vicini e, scaduto il timeout, procede comunque alla fase successiva.

Fase Proattiva

Dopo essere stato inizializzato, ogni Infrastructural Agent si pone in una situazione di idle in cui rimane in attesa di ricevere messaggi. A fronte della ricezione di un messaggio, l’IA reagisce attivamente a seconda della tipologia del messaggio ricevuto e, in particolare, discrimina se il messaggio è un messaggio di inizializzazione oppure no. Infatti, se il messaggio ricevuto è di inizializzazione (ovvero inviato da un’altro IA che si trova nella fase precedente) l’IA che lo riceve deve gestirlo, costruendo l’opportuna risposta da inviare e modificando la propria lista di vicini, includendo cioè l’host di quest’ultimo IA.Al di la di questo, il comportamento più interessante lo si osserva quando l’IA, nella situazione di idle, riceve un  messaggio che non sia di inizializzazione. In questo caso infatti si tratta di un "vero" messaggio del sistema che l’IA deve gestire per simulare quel comportamento che nel sistema biologico è svolto dall’ambiente.A fronte di tale ricezione, l’Infrastructural Agent reagisce avviando due flussi d’esecuzione concorrenti (sulla quale natura non si fanno ipotesi aggiuntive, per non diminuire il grado di generalità delle ipotesi), ognuno dei quali deputato ad un diverso compito: uno per la gestione del meccanismo di aggregazione e l’altro per la diffusione del messaggio ricevuto.Relativamente al primo flusso, il messaggio ricevuto viene analizzato per tentare di applicare il meccanismo di aggregazione al fine di creare un nuovo messaggio composto da quello appena ricevuto e da altri eventuali precedentemente ricevuti, presenti nello spazio locale dell’host in questione. Qualora il meccanismo di aggregazione sia attuabile, in funzione delle politiche predefinite, viene creato un nuovo messaggio che viene quindi inviato dall’IA a se stesso al fine di innescare il meccanismo di diffusione anche per questo nuovo messaggio frutto dell’aggregazione. Il secondo flusso è invece più articolato. Dal messaggio viene innanzi tutto estratto il coefficiente di evaporazione relativo, che, qualora risulti pari a zero, ovvero identifichi la situazione in cui si impone l’evaporazione dell’informazione, porta all’attivazione del meccanismo di evaporazione opportunamente gestito secondo quanto specificato nei paragrafi precedenti.Qualora tale coefficiente abbia un valore diverso da zero, si procede alla vera fase di diffusione del messaggio che inizia con la creazione della lista di destinatari per il messaggio, ottenuta da quella dei vicini dell’host relativo all’IA corrente; procedendo in questo senso si esclude sicuramente il mittente del messaggio da diffondere (che evidentemente è uno dei vicini) ed eventualmente altri vicini in relazione ad eventuali specifiche politiche di ottimizzazione. Quindi, viene valutato il tipo di messaggi, ovvero quale meccanismo di diffusione deve essere applicato (Spreading, Gradient, Digital Pherormone, Gossip) e in relazione a ciò viene avviato il processo di gestione del meccanismo scelto. In conclusione, gestito il messaggio, l’Infrastructural Agent torna nella fase di idle nella quale resta in attesa per nuovi messaggi da processare.

Struttura dei Messaggi

Dopo aver descritto dettagliatamente il funzionamento del generico Infrastructural Agent del sistema e aver evidenziato come il relativo lifecycle sia in gran parte subordinato ai messaggi scambiati all’interno del sistema, sarà ora discussa la struttura che tali messaggi devono avere per garantire il trasporto dell’informazione e dei parametri per la gestione dei meccanismi di diffusione. Il modello che segue rappresenta una possibile struttura per i messaggi.MessageStructure.pngOgni messaggio è composto da sei elementi:
  1. tipo, che rappresenta il meccanismo di diffusione mediante il quale il messaggio viene trasmesso sul sistema.
  2. corpo, che rappresenta il contenuto informativo del messaggio.
  3. coefficiente di evaporazione, che permette di attuare politiche di evaporazione secondo il meccanismo relativo.
  4. distanza, per identificare la distanza dall’host dal quale è partito inizialmente il messaggio.
  5. direzione, per identificare la direzione del gradiente.
  6. flag di avvenuta ricezione, per indicare che il contenuto del relativo gossip è frutto di una precedente ricezione.
Inoltre, per garantire maggiore efficienza al sistema, deve essere possibile attuare meccanismi di serializzazione di ciascun messaggio per poter inviare messaggi meno densi strutturalmente sul sistema in cui, ogni IA sia tuttavia capace di deserializzare il messaggio in fase di lettura per poterne comprendere il contenuto.Relativamente ai messaggi di inizializzazione, essendo questi ultimi fortemente dipendenti dall’architettura del sistema e dalla sua infrastruttura fisica, si lascia la definizione di una loro struttura alle successive fasi progettuali ed implementative.

Progettazione platform-dependent

Definiti i modelli necessari per descrivere compiutamente i pattern previsti negli obiettivi di progetto all’interno di un’ipotetica infrastruttura platform-independent, ci si appresta ad iniziare la fase di progettazione, basata sulle tecnologie scelte per portare a termine anche l’ultima fase di progetto, analisi e sperimentazione.L’intento finale si può riassumere nella realizzazione di una serie di librerie rappresentanti i pattern analizzati precedentemente, utilizzabili all’interno di un’opportuna infrastruttura ad-hoc, frutto di un’azione di mapping o correlazione più o meno accentuata fra le entità concettuali introdotte e le caratterisitiche/funzionalità principali delle due tecnologie Java utilizzate :
  • Jade - piattaforma software con l’obiettivo di fornire le necessarie funzionalità basiche per semplificare la realizzazione di applicazioni in campo distribuito, sfruttando ed utilizzando l’astrazione basata su Agenti;
  • Tucson - modello per la coordinazione dei sistemi distribuiti basati sul meta-modello MAS, nato dall’esigenza di introdurre strumenti per la coordinazione in ambienti caratterizzati da una moltitudine di agenti;
Si è scelto di realizzare un’infrastruttura Bio-Inspired based, utilizzando interamente la struttura centrale messa a disposizione dal pacchetto Jade, sfruttando le seguenti caratteristiche di:
  • proattività e autonomia attribute agli agenti, unico tipo di entità utilizzabile all’interno di tale architettura;
  • completa natura distribuita del sistema;
  • semplicità nella gestione del ciclo di vita del singolo agente;
  • supporto alla mobilità di tali entità;
  • modellazione dello spazio di interazione degli agenti in modalità congruenti con gli obiettivi prefissati.
Inoltre, Tucson è stato introdotto all’interno della piattaforma Jade come servizio di coordinazione, necessario per lo scambio e la fruizione di informazioni, in questo caso sfruttando caratteristiche, quali:
  • presenza di un media di coordinazione come concetto che si sviluppa in una dimensione trasverale rispetto all’ambiente dove “vivono” le entità, definite in tale modello come i coordinabili;
  • fusione dei modelli identificati come “information-driven” ed action-driven, in modo tale da rendere possibile l’osservabilità degli eventi, ma anche la possibilità di reagire ad essi;
  • generalità del modello stesso, sempre più utilizzato in sistemi caratterizzati da un elevato livello di “apertura”;
  • intrinseca distribuibilità dei sistemi basati su scambio di informazioni, costruiti partendo da esso;
  • modellazione delle entità coordinabili, immerse nel sistema descritto, come agenti definiti mobili.

Livello Infrastrutturale Bio-Inspired (System View)

Il modello proposto di seguito fornisce un quadro complessivo circa la composizione dell’infrastruttura ibrida venutasi necesariamente a creare dopo la scelta effettuata sulle tecnologie da impiegare.InfrastracturalSystemView.pngLa presenza di due differenti livelli concettuali, (“Base Infrastracture” e “Bio-Inspired Infrastracture”) è resa necessaria per identificare la struttura dei servizi fondamentali utilizzati (in questo caso presenti come commistione di elementi appartenenti agli ambienti Jade e Tucson, tema riconsiderato meglio nei paragrafi successivi) e, allo stesso tempo, per evidenziare l’introduzione di un ulteriore livello infrastrutturale mediano, appositamente ideato per realizzare, come già accennato nell’introduzione alle tecnologie, l’opera di mapping fra i concetti di entità che entrano in gioco nella tipologia di sistemi presi in esame, e quello di Agente autonomo, proattivo, relativo ad una specifica tecnologia, tipicamente "general-purpose", come risulta essere vero per Jade.Si può notare come l’integrazione delle due tecnologie considerate sia stata introdotta in entrambi i livelli infrastrutturali, subordinando gli elementi e servizi offerti dalla piattaforma Tucson ai componenti Jade-based, mostrando in che modo il modello di coordinazione basato sulla diffusione di Centri di Tuple sia introdotto come servizio, mentre è responsabilità dell’originaria piattaforma Jade gestire il cilco di vita ed ambiente di esecuzione di ogni agente.Per completare la descrizione del modello infrastrutturale che rappresenta il sistema in esame, è necessario specificare ulteriormente alcuni aspetti, di seguito elencati.
  • L’intero ambiente software, inteso qui come lo spazio virtuale in cui la totalità degli agenti risiede, è realizzato su un’unica Piattaforma Jade; tale scelta progettuale non vincola, in ipotetici sviluppi futuri, di estendere l’infrastruttura al fine di realizzare un’interazione inter-piattafroma, anche se solo mediante l’utilizzo di opportuni plug-in ed accorgimenti circa il concetto di “space-awarness”.
  • Ogni Container Jade rappresenta concettualmente una porzione dello spazio fisico di interesse, riuscendo in questo modo a mappare l’esigenza di riproporre la presenza di un “ambiente” circostante, mediante tale astrazione; come si può notare dal modello sovrastante, ad ogni container è associato un Nodo Tucson, utilizzato per mantenere dati in forma locale rispetto all’attuale container (per esempio informazioni riguardanti la relazione di vicinanza con altri “spazi” virtuali); data la natura ad Agenti della piattaforma Jade ed i vincoli strutturali invariati, ogni container è in grado di permettere l’individuazione e il successivo aggancio di una pluralità di Agenti Jade.
  • L’entità che è stata definita in precedenza come Host non è introdotta in tale modello dei componenti, perché, avendola definita come priva di della caratteristica autonomia e proattivà, proprie degli Agenti Bio-Inspired, si è ritenuto progettualmente non corretto introdurla all’interno dell’ambiente di visibilità di Jade, ovvero rapprasentando l’host come Agente. Ad ogni modo, si considera un host, ai fini della modellazione strutturale della nuova infrastruttura Bio-Inspired, l’insieme costituito dall’Infrastructural Agent ed il relativo Nodo Tucson.
  • Si è scelto di associare il Nodo Tucson all’Infrastractural Agent, in modo tale da rappresentare compiutamente il concetto astratto di host (in particolare il nodo ha un ciclo di vita corrispondente a quello dell’IA); sempre tale agente, in virtù delle funzionalità inizialmente definite, è in grado di accedere al centro di tuple che rappresenta lo spazio locale (nel modello, “LTC”), ma anche agli altri eventuali centri di tuple secondari (nel modello “OTC”), utilizzati per mantenere traccia di eventuali dati locali relativi a configurazioni specifiche dell’host, oppure per realizzare una politica di gestione degli accessi.
  • Ogni Software Agent può essere associato ad un unico host per volta, vincolo modellato tramite un apposito protocollo di connessione/disconnessione, trattato nel paragrafo successivo; si ricorda solamente che tali agenti sono in grado di percepire ed interagire solamente con il Nodo Tucson dell’host sul quale vivono; inoltre lo scope di attività è ridotto all’attuale spazio di memorizzazione locale (LTC).
  • Il problema relativo alla rappresentazione del concetto di "vicinanza" trova soluzione in questa fase progettuale, perché in precedenza identificato come problematica secondaria, fortemente dipendente dalla tecnologia utilizzata. Sempre mediante l'ausilio della piattaforma Jade, si considerano vicini tutti gli host (di cui si ha solamente una rappresentazione logica), presenti ed attivi all'interno del medesimo Container Jade; la relazione di vicinanza si riflette, inoltre, anche a livello di questi ultimi, mantenendo le informazioni necessarie all'interno di appositi Centri di Tuple Tucson, definite staticamente all'attivazione della piattaforma, per esempio sfruttando specifici algoritmi di ordinamento.

Livello Infrastrutturale Bio-Inspired (Entity View)

Il seguente modello strutturale mostra come le entità analizzate in precedenza vengano mappate sulla base delle scelte tecnologie effettuate.InfrastracturalEntitiesView.pngCongruentemente con quanto stabilito in precedenza, le principali tipologie di entità a cui si fa riferimento sono:
  • InfrastracturalAgent
  • SoftwareAgent
Entrambe afferiscono alla classe che rappresenta il concetto di entità, caratterizzata da un certo grado di autonomia (“AutonomousEntity”) e modellata come agente Jade; tale scelta progettuale è data dal fatto che questa piattaforma supporti nativamente diverse forme di mobilità e consenta di gestire in autonomia le politiche interne di esecuzione dei comportamenti di ogni agente, espressi tramite il concetto di “Behaviour”. Queste due entità devono avere la capacità e le possibilità di interagire con l’infrastruttura Tucson, la quale fornisce lo spazio locale di memorizzazione utilizzato sia dall’InfrastructuralAgent che dai SoftwareAgent; si è scelto, perciò, di dotare le due entità autonome citate di un’interfaccia di comunicazione con l’ambiente Tucson, ovvero di un Agent Communication Context (ACC), che caratterizzata il contesto di azione dell’agente e di un identificativo univoco (TucsonAgentId), utilizzato per eseguire le operazioni sui Centri di Tuple. Entrambe le entità sono caratterizzate da un determinato grado di mobilità, sia essa di natura siftware o hardware, aspetto catturato dalla presenza dell’interfaccia IMovable. Ogni Software Agent ha la possibilità di connettersi ad un solo Infrastructural Agent, allo stesso modo però possiede la capacità di spostarsi su Infrastructural Agent diversi.Più complessa risulta la mobilità associata all’Infrastructural Agent, il quale ha la capacità di spostarsi da un container all’altro, a seconda della dislocazione fisica del dispositivo hardware a cui è associato. Nel momento in cui si osserva tale movimento, tutti i Software Agenti ad esso collegato si dovranno spostare con esso; invece, per quanto riguarda il Nodo Tucson locale, si considera anch’esso mobile, dal punto di vista logico, perché è necessario che segua il corrispondente Infrastractural Agent. La composizione di Infrastructural Agent, Nodo Tucson, attuatori e sensori, permette di modellare il concetto di Host che, a livello di infrastruttura del sistema, si è deciso di rappresentare come un’aggragazione di componenti. L’associazione uno-a-uno tra il concetto di host ed InfrastructuralAgent ha portato alla definizione della funzionalità “getContainerTucsonNodeID”; essa permette di ottenere e memorizzare il riferimento al Nodo Tucson associato al container a cui è momentaneamente collegato l’InfrastructuralAgent; tale riferimento risulta essere indispensabile per poter accedere allo spazio di memorizzazione, ed in particolare, al Centro di Tuple contenente l’elenco degli Infrastructural Agent associati attualmente al container.Ogni volta che l’Infrastructural Agent si sposta fra containers, dovrà farsi carico di riottenere il nuovo riferimento al Nodo Tucson associato. Tale funzionalità è stata pensata anche per poter ottenere iterativamente i riferimenti ai Nodi Tucson dei container vicini, in modo tale da poter calcolare l’insieme degli Infrastructural Agent a cui dovranno giungere le informazioni.Ogni Infrastructural Agent può ospitare presso di sé uno o più Software Agent; quest’ultimo, per potersi associare e ottenere conseguentemente il referimento al NodoTucson locale dell’Infrastructural Agent, deve utilizzare la funzionalità di “connectToHost”; dualmente l’Infrastructural Agent registra, tramite la “registerSoftwareAgent”, la presenza del Software Agent all’interno dello spazio locale.Le funzionalità “disconnectSoftwareAgent” e “leaveHost”, rispettivamente dell’Insfrastructural Agent e del Software Agent, vengono utilizzate qual’ora un SoftwareAgent lasci l’attuale Infrastructural Agent per connettersi eventualmente ad un’altro host.Infine, per mettere in luce l’utilizzo delle tecnologie nei metodi di comunicazione considerati all’interno del sistema, si è introdotto il seguente modello che ne rappresenta un esempio.AgentCommunicationTypes.pngL’entità Software Agent, dopo aver effettuato la registrazione all’InfrastructuralAgent e aver ottenuto il riferimento al Nodo Tucson dello spazio locale, può utilizzare delle “Tucson Interaction” per accedere solamente allo spazio di memorizzazione locale dell’host a cui è connesso.L’infrastructuralAgent, se da un lato può accedere solamente al proprio spazio locale di memorizzazione, dall’altro ha la possibilità di comunicare con qualsiasi altro pari, facendo uso della tecnica propria di Jade, basata sullo scambio di messaggi. La comunicazioni fra host, perciò, avviene solamente tramite lo scambio di messaggi fra InfrastructuralAgent. Lo scambio di messaggi può verificarsi anche fra InfrastructuralAgent e SoftwareAgent, tale interazione, nel momento in cui quest’ultimo ha effettuato la connessione, può aver luogo solo fra entità che fanno riferimento allo stesso host; l’invio di messaggi extra-host da parte di un SoftwareAgent è permessa sono in caso di mobilità di quest’ultimo.

Progettazione e sviluppo dei Bio-Inspired Patterns

Descritta l’infrastruttura considerando le tecnologie prescelte, si pone ora il problema di stabilire come iniettare le funzionalità dei pattern bio-inspired nei vari agenti del sistema. In particolare, è necessario definire come realizzare il comportamento di ciascun infrastructural agent che, come è noto, possiede il compito di maggiore rilevanza. Il lifecycle di un infrastructural agent è stato descritto in termini generali come una macchina a stati e in Jade un tale comportamento è modellabile, ed associabile agli agenti, attraverso il concetto di Behaviour.In Jade un behaviour rappresenta un task che un agente può eseguire e che deve essere aggiuto all’agente specifico secondo specifiche politiche. Ogni behaviour è eseguito da un agente secondo uno scheduler cooperativo, non pre-emptive, che impone di fatto l’impossibilità di eseguire più behaviour contemporaneamente. Una volta avviato un behaviour, un agente può eseguirne un altro solo dopo che quello attivo abbia segnalato la sua completa terminazione.In definitiva, perciò, nel caso specifico dell’infrastructural agent, che prevede un comportamento ciclico che si interrompe unicamente in corrispondenza alla dismissione dell’agente, solo un behaviour può essere associato ed eseguito.Tuttavia, affinché sia possibile attuare una corretta separazione dei contenuti, la tecnologia Jade consente di associare uno o più sotto behaviuors ad un behaviour principale, quando quest’ultimo sia definito, tra le varie possibilità, come una macchina a stati.La figura che segue, riassume relativamente all’infrastructural agent la mappatura del suo behaviour sulla tecnologia ad agenti Jade e dei relativi sotto behaviours.Behaviourstructure.pngIn particolare, il macro comportamento è definito mediante un jade FSMBehaviour in cui gli stati figli corrispondono agli specifici behaviour relativi ai diversi pattern, associati al behaviour principale, definiti mediante l’uso della classe OneShotBehaviour che identifica un comportamento che dopo aver svolto il proprio compito termina rilasciando il controllo, o nello specifico caso in cui vengono utilizzati (ovvero come figli di un behaviour FSM) scatenando una transizione verso un altro stato.Volutamente, si è deciso di tralasciare eventuali altri behaviour “di servizio” in cui inserire altre sotto aprti del lifecycle dell’infrastructural agent; in quanto, tali parti possono essere anche specificate nella definizione iniziale dell’IABehaviour.Relativamente alle specifiche progettuali/implementative dei pattern bio-inspired si è scelto di non realizzare specifici modelli in quanto le uniche operazioni da compiere, identificate ed ampiamente discusse nelle sezioni di analisi, dovranno unicamente essere tradotte in codice operativo da inserire nella ridefinizione dei metodi (onStart(), action() e onEnd()) dei relativi behaviour.

Conclusioni

Dopo aver analizzato dettagliatamente la realtà di riferimento relativa ai modelli ispirati alla biologia e agli specifici pattern, la progettazione effettuata risulta completa e dettagliata tale da rendere la successiva fase implementativa non necessaria al fine di aggiungere un ulteriore livello di dettaglio. In definitiva perciò, il progetto risulta concluso in tutte le sue parti ed introduce inoltre un valore aggiunto rispetto all'attuale stato dell'arte nell'ambito della ricerca sui modelli software ispirati alla biologia.

Riferimenti