Contents
MEnSA, Methodologies for the Engineering of complex Software systems: Agent-based approach
MEnSA was a research project financed by the Italian Ministery for Education, University, and Research (Ministero dell'Università e della Ricerca), and the project acronym stands for "Methodologies for the Engineering of complex Software systems: Agent-based approach".
The main objective has been the creation of agent-oriented software engineering methodologies that support the development of complex software systems. In general, methodologies will assist the whole development process, from the requirements analysis to the actual implementation of the systems. The result are some contributes in filling the existing gap between agent-oriented methodologies and multi-agent systems.
MEnSA has been a joint project (years 2007-2008)among
- Alma Mater Studiorum - Università di Bologna (Cesena branch),
- Università degli Studi di Modena e Reggio Emilia,
- Università degli Studi di Trento.
Involved people
For the University of Modena and Reggio Emilia, the people that mainly worked on this project was:
Overview (In Italian)
Questa ricerca è stata portata avanti all'interno del Progetto “Metodologie per l’ingegneria dei sistemi software complessi: approccio ad agenti”, cofinanziamento MUR PRIN 2006, con il titolo specifico del programma dell’UR di Modena: “Metodologie orientate agli agenti: ingegnerizzazione delle interazioni e rapporto con le infrastrutture”), anni 2007-2008.
Nell'ambito del progetto MEnSA, l'Unità di Ricerca di Modena e Reggio Emilia ha focalizzato le sue attività nel workpackage dedicato alle metodologie per lo sviluppo di applicazioni ad agenti, connesse alle infrastrutture (WP2), ed ha attivamente collaborato con le altre unità di ricerca per portare a termine le attività degli altri workpackage. I prodotti della ricerca (principalmente deliverable e pubblicazioni scientifiche) sono stati messi a disposizione delle altre unità di ricerca e della comunità scientifica attraverso il sito web del progetto: http://www.mensa-project.org. L'attività di ricerca è partita dalla considerazione che nel campo dell'ingegneria del software orientata agli agenti esiste un gap tra le metodologie di analisi e progetto da una parte e le infrastrutture per l'implementazione dall'altra. Questo gap può portare a utilizzare concetti e strumenti diversi e potenzialmente incoerenti nelle diverse fasi di sviluppo del software ad agenti. Partendo da queste considerazioni, l'attività di ricerca ha avuto come obiettivo la proposta di una metodologia innovativa che tenesse conto degli scenari e dalle esigenze esistenti e fornisse un valido supporto durante tutto il ciclo di vita del software. Le attività di ricerca svolte sono riportate nel seguito, suddivise per macro argomenti.
Studio dello stato dell'arte nel campo delle metodologie ad agenti
La prima attività ha riguardato lo studio dello stato dell'arte nel campo delle metodologie per lo sviluppo di applicazioni ad agenti. Questo studio non solo è stato utile per inquadrare meglio le caratteristiche delle metodologie esistenti, ma ha anche posto le basi per la composizione di metodologie sfruttando i frammenti di quelle esistenti, come dettagliato meglio più avanti. Esistendo diverse metodologie ad agenti, si è scelto di valutare quelle più diffuse, più general-purpose, e fornite di un buon supporto. In specifico, le metodologie valutate sono state: ADELFE, Gaia, MaSE (Multiagent Systems Engineering), PASSI (Process for Agent Societies Specification and Implementation), Prometheus, SODA (Societies in Open and Distributed Agent spaces) e Tropos. Data la varietà delle caratteristiche delle metodologie esistenti, abbiamo inizialmente definito alcuni criteri per valutare le metodologie. Tali criteri sono stati scelti in base agli obiettivi del progetto, e in particolare in connessione con le infrastrutture. I due macro criteri scelti sono stati l'attinenza ai servizi e il supporto alla definizione di società di agenti.
Attinenza ai servizi
Relativamente ai servizi, la nostra esperienza ha suggerito che essi svolgono un ruolo fondamentale nelle infrastrutture, e che anzi la maggior parte di esse è stata concepita per fornire servizi agli agenti o per supportare gli agenti che mettono a disposizione servizi. Abbiamo quindi considerato le caratteristiche chiave del Service Oriented Computing (SOC), che sono: - neutralità implementativa: un approccio basato sui servizi non può essere legato a una specifica piattaforma o linguaggio, e dovrebbe garantire interoperabilità tra le applicazioni; è quindi importante l'uso di linguaggi standard e diffusi, come ad esempio XML e UML; - configurazione flessibile: nelle varie fasi dello sviluppo la configurazione dovrebbe essere flessibile per adattarsi a eventuali cambiamenti facilitando anche la manutenzione; - granularità: avere viste dello sviluppo con diversi livelli di granularità permette di tenere sotto controllo lo stato globale senza tralasciare i particolari; - orientamento all'obiettivo: i servizi messi a disposizione definiscono una funzionalità ben precisa, sono quindi molto orientati a raggiungere un obiettivo specifico. Queste caratteristiche ci hanno portato a definire i criteri con cui analizzare le metodologie: - uso di linguaggi standard per supportare lo sviluppatore nella definizione di entità, che permette una parte dello sviluppo indipendente dalla successiva implementazione; - uso di diagrammi, che permette sia di definire configurazioni flessibili sia di avere diversi gradi di granularità; - grado di orientamento all'obiettivo di una metodologia, che si collega direttamente alla quarta caratteristica di SOC. Il risultato del nostro studio è stato che nessuna metodologia soddisfa in pieno i tre criteri proposti, come ci si poteva aspettare. In generale, tutte le metodologie hanno un orientamento all'obiettivo, anche se con gradi diversi. Riguardo agli altri criteri, PASSI è quella che più utilizza linguaggi standard per la definizione di entità, mentre ADELFE è quella che più si appoggia a diagrammi.
Società di agenti
Per quanto riguarda le società ad agenti, le infrastrutture abilitano l'interazione fra gli agenti e la definizione di politiche di interazione; tali politiche possono essere ingegnerizzate sfruttando il concetto di società. Anche in questo caso siamo partiti dalle caratteristiche delle società per estrapolare dei criteri di analisi; le due caratteristiche principali emerse sono: - la struttura organizzativa della società, principalmente basata sui ruoli che gli agenti possono giocare all'interno della società, sulle norme e regole che specificano i vincoli di comportamento degli agenti all'interno della società, e sugli obiettivi della società stessa; - le interazioni tra gli agenti partecipanti, che permettono agli agenti di raggiungere i propri obiettivi e quelli della società. Quindi, i criteri di analisi delle metodologie si basano fondamentalmente sul supporto alla definizione e gestione delle caratteristiche emerse, eventualmente sfruttando un appropriato formalismo e/o appoggiandosi a un tool; in particolare sono stati considerati i seguenti criteri: - supporto per la definizione e la gestione dei ruoli, che sono le entità principali nella determinazione delle strutture organizzative; - supporto per specificare e gestire le regole, i vincoli e le norme che descrivono il comportamento atteso dagli agenti, con le relative sanzioni in caso di violazione; - supporto per la definizione di obiettivi, che sono entità di primaria importanza nelle società; - disponibilità di un framework di interazione tra gli agenti, che può comprendere ontologie, linguaggi di comunicazione e linguaggi di rappresentazione. Un risultato interessante di questa analisi è che tutte le metodologie considerate forniscono un qualche protocollo di interazione. Invece, poche metodologie supportano l'identificazione degli obiettivi e ancora meno la definizione di regole; questo può essere spiegato dal fatto che le metodologie sono state pensate principalmente sui Multi Agent Systems, dove gli obiettivi sono individuali e le interazioni non sono soggette a regole dettate dall'ambiente.
SPEM
Infine, è stato svolto uno studio del linguaggio di modellazione dei processi SPEM, definito dall'OMG. SPEM è un meta-modello per definire i processi e i loro componenti ed è usato per descrivere un concreto processo di sviluppo software. Le specifiche di SPEM sono strutturate come un profilo UML e forniscono un meta-modello completo basato su MOF (Meta Object Facility). SPEM è stato sfruttato per la definizione di frammenti di processi di metodologie e per la loro ricomposizione secondo gli obiettivi del progetto, seguendo il paradigma SME (Situational Method Engeneering). Questo approccio permette di utilizzare porzioni esistenti di processi (frammenti), per costruire un SEP (Software Process Engineering) ad hoc. Per questo motivo le metodologie scelte dal progetto MEnSA sono state analizzate e decomposte in pezzi di processo, chiamati frammenti. Questi frammenti sono poi stati utilizzati per la composizione delle metodologie.
Definizione di metodologie connesse alle infrastrutture
Dopo lo studio dello stato dell'arte, abbiamo fatto alcuni esperimenti per mappare metodologie ad agenti su infrastrutture ad agenti. In particolare, come esempio concreto, abbiamo considerato la metodologia PASSI e l'infrastruttura RoleX. A partire dai loro meta-modelli, abbiamo valutato quali fossero le entità comuni, che potessero quindi essere usate come collegamento tra metodologia e infrastruttura, e che potessero essere utili per trovare una qualche connessione anche tra le altre entità. Questo approccio è stato utilizzato anche dall'Unità di Bologna. Un altro esperimento è consistito nel valutare come una specifica entità (il ruolo) viene gestita dalle diverse metodologie e infrastrutture. La lezione imparata da questi esperimenti è stata che un mapping diretto (una entità della metodologia con una entità dell'infrastruttura) è molto difficile da ottenere, ed è necessario un approccio più globale. Questo è dovuto anche alla varietà di metodologie e infrastrutture, per cui un mapping punto-punto è complesso e non è detto che sia utile. Si è quindi passati alla definizione di nuove metodologie che fossero connesse alle infrastrutture. Sono state sviluppate due metodologie, seguendo sue filosofie diverse. La prima, MAR&A, è stata sviluppata partendo dalle entità delle infrastrutture, mentre la seconda è stata sviluppata partendo dal meta-modello del progetto. In realtà, le metodologie definite non sono completamente nuove, perché in entrambi i casi si è deciso di non partire da zero, ma di riutilizzare frammenti di metodologie esistenti. Questa modalità permette di usare parti di processo che sono già state utilizzate e testate. Successivamente, è stata svolta una attività di ricerca per studiare le metodologie nel campo dei sistemi self-organizing, con l'obiettivo di evidenziare eventuali connessioni con le metodologie ad agenti.
Metodologia MAR&A
La definizione di MAR&A prende spunto dagli esperimenti descritti in precedenza. Abbiamo analizzato diverse infrastrutture ed estrapolato le entità comuni. Queste entità sono state il punto di partenza per costruire la metodologia; infatti, sono stati scelti quei frammenti di altre metodologie che considerassero esplicitamente le entità estrapolate. Il nome della metodologia, MAR&A (Methodology for Agents: Roles & Actions), vuole evidenziare i punti focali della metodologia, che partono appunto da entità estratte dalle infrastrutture studiate, e comuni ad esse. Le infrastrutture di partenza sono state: CArtAgo, MARS, RoleX, TOTA e TuCSon. Le entità emerse come comuni sono state: agente, ruolo, evento e azione. L'obiettivo di questa metodologia è quello di poter progettare applicazioni basate su agenti, ma soprattutto di tenere conto degli approcci basati su infrastrutture per supportare l'implementazione e l'esecuzione di tali applicazioni. Come accennato, questa metodologia ha come peculiarità quella di essere una metodologia composta, cioè il risultato di una riprogettazione di frammenti di metodologie esistenti. Questi frammenti sono stati estratti dalla descrizione di alcune metodologie esistenti, come ad esempio ADELFE, Gaia, MaSE, PASSI, Prometheus, SODA e Tropos. I frammenti, estratti dal repository creato dal FIPA Methodology Technical Committee, sono stati descritti tramite SPEM (Software Process Engineering Meta-Model). Dopo l'analisi delle metodologie come descritto nello studio dello stato dell'arte, sono state analizzate le infrastrutture e ne sono stati presi in considerazione i meta-modelli per evidenziare le entità principali e comuni (quando possibile) o simili a tutte le infrastrutture. Partendo da questi presupposti la progettazione di MAR&A si è basata sulle seguenti attività: - studio dei meta-modelli delle metodologie esistenti alla luce delle entità estratte nel dominio minimo comune alle infrastrutture analizzate in precedenza; - estrazione, dai suddetti meta-modelli, di frammenti significativi; - composizione dei frammenti e conseguente creazione della metodologia. Inizialmente è stata creata una tabella riassumente gli step di ogni metodologia, per vedere come vengono trattati i concetti di agente, ruolo, evento e azione. Alla luce degli studi effettuati sulla struttura delle metodologie, la metodologia MAR&A è stata suddivisa in quattro fasi: Raccolta dei requisiti, Analisi, Design e Implementazione. La fase di Implementazione risulta ancora in via di sviluppo. La metodologia così composta definisce chiaramente le entità principali utilizzate dalle infrastrutture e il sistema sviluppato con la metodologia risulta perciò più coerente con le entità disponibili nelle infrastrutture studiate. In particolare si è potuto osservare come, durante l'applicazione di MAR&A ad un caso di studio, quale il "Conference Management System", siano emerse numerose informazioni utili per poi implementare i concetti di Role ed Action. Ad esempio, tali informazioni sono i prodotti del Roles Model, del Roles Identification Diagram e del Task Specification Diagram; queste informazioni, risultano particolarmente importanti in quanto derivanti da un flusso logico di operazioni nato dallo studio congiunto di metodologie ed infrastrutture, aspetto innovativo di MAR&A.
Metodologia MEnSA
La seconda metodologia è invece nata sulla base del meta-modello definito all'interno del progetto. Per la costruzione della metodologia si è partiti dai requisiti necessari per sviluppare un sistema software complesso, analizzati e raccolti dall'Unità di Ricerca di Trento in un meta-modello preliminare. Partendo da questo meta-modello, anche in questo caso si è cercato di costruire una metodologia che avesse forti connessioni con le infrastrutture, riutilizzando metodologie esistenti, o almeno parti di esse, seguendo l'approccio del paradigma SME per la costruzione di un nuovo processo software. I frammenti software, descritti tramite SPEM sono stati estratti dal repository creato dal FIPA Methodology Technical Committee. Quelli necessari ma non esistenti nel repository, come alcuni di quelli che provengono dalla metodologia Gaia, sono stati creati ad hoc. In letteratura sono stati proposti diversi approcci al SME, tutti basati sul concetto di riutilizzo, e su tre fasi principali: l'analisi dei requisiti di processo, la selezione dei frammenti e l'assemblaggio dei frammenti. Tutti questi approcci però sono legati alla mancanza di tecniche ben definite e alla dipendenza dall'esperienza degli sviluppatori. Per provare a risolvere questi problemi è stato utilizzato l'approccio proposto da PRoDe (PRocess for Design of Design PRocesses). Questo approccio utilizza utilizza il meta-modello come elemento centrale per la selezione e l'assemblaggio dei frammenti. Dopo aver creato il meta-modello del nuovo processo, questo approccio utilizza un algoritmo per l'estrazione e la composizione del frammenti, chiamato algoritmo di Prioritizzazione. Innanzitutto sono stati selezionati separatamente i domini del meta-modello; sono state composte tre liste per ogni dominio (poi unite per formarne solo tre per tutti i domini - una tipologia di lista comprendente i vari domini). Nella prima lista sono stati elencati tutti gli elementi che sono stati estratti da frammenti già esistenti; nella seconda lista sono stati elencati gli elementi i cui frammenti non esistono e sono stati successivamente creati ad hoc; nella terza lista sono stati elencati gli elementi non presenti nel meta-modello, ma che nel processo risultano utili. Le liste sono state create man mano che si è proceduto nell'elaborazione dei frammenti; infatti, ogni frammento oltre a descrivere le entità necessarie per il nuovo processo, ne può definire altre che possono essere o inutili (quindi successivamente cancellate) o utili ma non presenti (quindi successivamente da aggiungere). Per creare le liste, partendo dal meta-modello, è stato assegnato un livello di priorità a ogni entità, contando le relazioni che l'entità presenta nel meta-modello. Le entità sono poi state inserite nelle liste partendo da quelle con priorità più bassa. Utilizzando le liste, i frammenti sono stati selezionati e ordinati per comporre un Component Diagram. Il Component Diagram definisce la sequenza tramite la quale i frammenti creano il nuovo processo software evidenziando i vari input e output. Partendo da questo diagramma, i frammenti sono stati analizzati e modificati (quando necessario) per essere collegati l'uno con l'altro per adattarsi al meta-modello di partenza e soddisfare i requisiti per lo sviluppo di un sistema ad agenti software complesso. I nuovi frammenti così formati creano una "nuova" metodologia composta seguendo i requisiti del progetto. Per supportare l'utilizzo da parte degli sviluppatori della metodologia proposta, è stato approntato un prototipo di tool. Anche in questo caso si è seguita la direzione del riutilizzo, ed in particolare è stato preso in considerazione l'ambiente integrato Eclipse, ed in particolare l'Eclipse Modeling Framework (EMF), uno strumento per costruire tool e applicazioni basati su un modello strutturato di dati. Per lo sviluppo dell'interfaccia grafica sono stati sfruttati i framework Graphical Modeling Framework (GMF) e Graphical Editing Framework (GEF).
Approcci self-organizing
Successivamente sono state studiate metodologie per lo sviluppo di sistemi self-organising (detti anche semplicemente "self-org"). Dopo uno studio preliminare dei requisiti che caratterizzano questo tipo di sistemi, dei vantaggi del loro sviluppo tramite sistemi multi-agente e della mancanza di metodologie ben definite per il loro sviluppo, si è notato come l'utilizzo dell'approccio basato sui frammenti potesse essere utile. La self-organisation è il meccanismo o il processo che consente a un sistema di cambiare la sua organizzazione durante il tempo di esecuzione, senza un esplicito comando esterno. Oggigiorno non esistono metodologie utilizzabili appieno per costruire un sistema self-org, molte di quelle analizzate sono solo approcci che si basano sulla simulazione. Gli approcci e le metodologie analizzate sono: Adelfe, "The customized unified process", "A generic framework", "A general methodology", "A simulation driven approach". Studiando queste metodologie e questi approcci tramite alcuni casi di studio ne sono stati evidenziati le debolezze, i punti focali e gli aspetti che sviluppano le caratteristiche dei sistemi self-org. Successivamente le metodologie/approcci sono stati decomposti estraendo i frammenti ritenuti importanti per lo sviluppo di un sistema self-org. I vari frammenti sono stati poi ordinati nelle varie fasi in cui generalmente può essere scomposto un sistema, per facilitare la scelta agli sviluppatori. Allo stato attuale, i frammenti evidenziati non sono sufficienti a costruire una metodologia completa, ma possono essere integrati all'interno di una metodologia conosciuta dallo sviluppatore.
Ulteriori attività scientifiche
Nel periodo di svolgimento del progetto, l'unità di ricerca ha portato avanti altre linee di ricerca che hanno dimostrato delle connessioni con le attività di ricerca di MEnSA, e gli sforzi di integrazione hanno portato interessanti risultati scientifici.
In particolare, sono stati fatti studi nel campo dell'e-health, la medicina supportata da tecnologie informatiche; più in dettaglio, gli agenti sono stati sfruttati per la gestione degli apparati medicali, per l'interazione tra attori di tipo diverso e per prendere decisioni adattative in base a diversi parametri. Inoltre, i dispositivi mobili utilizzati ad esempio nelle situazioni di emergenza sono stati considerati come agenti.
Un altro campo collegato è stato quello della gestione dinamica dei servizi e del loro sfruttamento.