Progetto

Architettura del sistema

L'architettura logica del sistema e' rappresentata dal Collaboration Diagram UML in figura:

 

I blocchi logici del diagramma rappresentano i componenti principali del sistema con relativi messaggi.

Gui:

Questo oggetto costituisce l'interfaccia (di tipo grafico) tra sistema e utente, e' responsabile della creazione di tutti gli oggetti grafici (finestre, pulsanti) e della gestione dei relativi eventi. Invoca il metodo analyze dell'oggetto Coordinator passando come parametro la configurazione stabilita dall'utente (nome applicazione, attore, place da analizzare).

Coordinator:

E' un agente S.O.M.A. stazionario, costituisce l'entry point nel sistema (metodo run). Crea e attiva l'oggetto Gui. Fornisce il servizio del sistema attraverso il metodo analyze. Analyze crea un agente per ogni dominio soggetto ad analisi consegnandogli una propria configurazione che comprende un codice di identificazione della applicazione, la lista dei place da visitare, un' istanza dell'attore (la cui classe viene caricata dinamicamente) e un riferimento al coordinatore (per inviare i messaggi). Coordinator riceve i messaggi da parte degli agenti di tutte le applicazioni attivate (il sistema supporta la concorrenza delle applicazioni) secondo il protocollo descritto in seguito.

LocalCoordinator:

E' l'agente mobile responsabile della analisi di un dominio. Riceve una lista dei place da visitare nel dominio di sua competenza. All'arrivo su un place, crea un oggetto Service e lo inizializza, poi invoca un metodo dell'attore passando come parametro l'oggetto Service appena creato. Il metodo invocato e' mainMethod per ogni place dal primo all'ultimo escluso, endMethod sull'ultimo place. La stringa restituita da endMethod (risultato della computazione) viene inviato a Coordinator da LocalCoordinator tramite un messaggio. Coordinator provvede a visualizzare (tramite Gui) il risultato nella finestra della applicazione proprietaria dell'agente. Nel caso l'agente non riesca a raggiungere un place, segnala il fatto e cerca di proseguire.

Service:

Questo oggetto costituisce l'interfaccia tra il componente definito dall'utente (Attore) e il resto del sistema. I servizi offerti sono: valutazione di una interrogazione da parte del motore inferenziale, invio di un messaggio (viene visualizzato sulla finestra della relativa applicazione), indicazione della posizione corrente. Service provvede anche (durante l'inizializzazione) a realizzare l'astrazione di motore inferenziale mobile, ripristinando lo stato della base di conoscenza in base alla storia delle interazioni effettuate precedentemente. La base di conoscenza viene inoltre inizializzata con il contenuto del file globalkb.pro (base di conoscenza globale) e con la conoscenza locale (ovvero conoscenza associata al place in fase di configurazione iniziale della applicazione). La scelta di rendere i servizi disponibili mediante un oggetto intermedio e' giustificata dalla esigenza di rendere le applicazioni indipendenti dal motore inferenziale utilizzato.

Actor:

L'oggetto attore e' un'istanza della classe fornita dall'utente in fase di creazione della applicazione. Deve essere sottoclasse della classe astratta Actor fornita dal sistema. Questa classe comprende quattro metodi (tre astratti e uno concreto eventualmente ridefinibile). I metodi sono: setParam (passaggio del parametro, viene invocato dall'agente prima di partire), mainMethod (viene invocato in ogni nodo raggiunto tranne l'ultimo), endMethod (viene invocato sull'ultimo place e restituisce una stringa che viene visualizzata sulla finestra della applicazione come risultato), endOnErr (questo metodo e' ridefinibile facoltativamente, viene invocato nel caso l'agente non riesca a raggiungere l'ultimo place per permettere all'attore di restituire eventualmente il risultato della elaborazione parziale).

Engine:

E' il motore inferenziale base offerto dal framework, ovvero un'interprete Prolog. La scelta dell'interprete e' caduta su kernel prolog, un'interprete open source in Java. Il motivo della scelta risiede nel linguaggio utilizzato per la sua implementazione che, essendo lo stesso impiegato per S.O.M.A. e D.I.A.Log.A., lo rende facilmente integrabile. Inoltre, non trattandosi di un prodotto commerciale, e' liberamente utilizzabile.

KB-File e Metainterpreter:

Sono i due file che contengono, rispettivamente, la base di conoscenza globale e il motore inferenziale (interprete di livello meta) definibili facoltativamente dall'utente.

Info-Source:

Questo oggetto indica genericamente la sorgente di informazione che si vuole analizzare. Puo' trattarsi di una base di dati come di uno o piu' file ....

Scambio di messaggi

La comunicazione tra coordinatore ed agenti mobili avviene utilizzando il meccanismo a scambio di messaggi (senza affidabilita') fornito da S.O.M.A. Si tratta di una comunicazione monodirezionale (dagli agenti verso il coordinatore) che riguarda unicamente il coordinatore ed ogni singolo agente (non sono previste comunicazioni inter-agente)

I messaggi inviati da LocalCoordinator sono di due tipi:

1)Messaggi "di terminazione": ovvero il messaggio che contiene il risultato della elaborazione (stringa restiruita dai metodi endMethod oppure endOnErr dell'Attore). Dopo l'invio di questo messaggio, l'agente, che ha terminato lo scopo della sua esistenza, muore. In questo caso Coordinator visualizza il contenuto nella apposita finestra indicando il dominio da cui proviene. Aggiorna inoltre il contatore degli agenti in attivita' per quella applicazione.

2)Messaggi "non di terminazione". Appartengono a questa categoria sia i messaggi che l'agente invia se non riesce a raggiungere un place ed e' costretto a saltarlo, sia i messaggi inviati dall'attore attraverso il metodo sendPostCard dell'oggetto Service. In questo caso Coordinator si limita a visualizzare il messaggio.