UNIVERSITY
OF TRENTO
DEPARTMENT OF INFORMATION AND COMMUNICATION TECHNOLOGY
38050 Povo – Trento (Italy), Via Sommarive 14
http://www.dit.unitn.it
THE TROPOS MODELING LANGUAGE. A USER GUIDE
Fabrizio Sannicolo', Anna Perini, and Fausto Giunchiglia
February 2002
Premessa
Tropos `e una nuova metodologia basata sul paradigma dei sistemi multi-agente che supporta il progettista in tutto il processo di sviluppo del software, dall’analisi dei requisiti all’implementa-zione del sistema. Essa vuole offrire un approccio strutturato allo sviluppo del software, basato sulla costruzione di modelli concettuali definiti secondo un linguaggio di modellazione visuale, i cui elementi base sono concetti quali agente (attore), credenze, obiettivi, piani e intenzioni. Tropos si caratterizza per tre idee chiave: ı le nozioni di agente, goal, piani e altre nozioni mentalistiche
sono usate lungo tutte le fasi di sviluppo del software; ıı l’adozione di un approccio allo sviluppo
del software guidato dai requisiti anzich´e dai vincoli dettati dalla piattaforma di implementazione scelta; ııı la costruzione di modelli concettuali seguendo un approccio trasformazionale di tipo
incrementale. Questo lavoro si colloca all’interno di un progetto che coinvolge diverse universit`a e istituti di ricerca nel mondo, tra le quali l’Universit`a degli Studi di Trento e l’ITC - IRST. Obietti-vo di questo documento `e quello di fornire una guida all’uso della metodologia Tropos lungo tutte le fasi del processo di sviluppo del software con particolare enfasi al linguaggio di modellazione visuale. Il linguaggio utilizzato in Tropos `e un linguaggio di specifica semiformale caratterizzato da un’ontologia, un meta-modello, una notazione grafica e un insieme di regole. L’ontologia `e rappresentata da un insieme di concetti per la modellazione (attori, goal, piani) e di relazioni tra questi (dipendenze). Il meta-modello (descritto tramite diagrammi delle classi UML) `e necessa-rio per la specifica dei modelli Tropos. Ciascun concetto definito all’interno del meta-modello dispone della propria rappresentazione grafica che lo identifica lungo tutte le fasi del processo. Sono disponibili vari diagrammi che catturano aspetti statici e dinamici dei modelli da pi`u punti di vista. Ogni diagramma `e costruito seguendo un insieme di regole precise che guidano all’uso dei concetti durante le diverse fasi del processo di sviluppo del software.
Parole chiave
Indice
1 Introduzione 1
I La Metodologia Tropos e il Linguaggio di Modellazione 5
2 La metodologia 7
2.1 Fasi del processo di sviluppo . . . 8
2.2 I concetti chiave . . . 10
2.3 Attivit`a di modellazione . . . 12
2.4 Tropos a confronto con altre metodologie . . . 14
3 Il linguaggio di modellazione 15 3.1 Il meta-modello . . . 15
3.1.1 Il livello meta-metamodello . . . 17
3.1.2 Il livello meta-modello . . . 18
3.1.3 Il livello del dominio . . . 29
3.1.4 Il livello oggetto . . . 29
3.2 Concetti chiave . . . 30
3.3 Notazione grafica e diagrammi . . . 31
3.3.1 Il diagramma degli attori . . . 32
3.3.2 Il diagramma dei goal . . . 36
3.3.3 Il diagramma delle abilit`a . . . 39
3.3.4 Il diagramma dei piani . . . 40
3.3.5 Il diagramma delle interazioni tra agenti . . . 42
II Un esempio. Specifica di un sistema di supporto all’organizzazione di mee-ting 45 4 Il sistema per l’organizzazione di meeting 47 4.1 Definizione del problema . . . 47
4.2 Analisi e specifica dei requisiti . . . 48
4.2.1 Analisi dell’ambiente . . . 49
4.2.2 Analisi del sistema futuro . . . 55
4.3 Progettazione del sistema . . . 62
4.3.1 La fase architetturale globale . . . 62
4.3.2 La fase di dettaglio architetturale . . . 67
4.4 Implementazione del sistema . . . 69
Bibliografia 71 A Glossario e Trasformazioni 77 A.1 Glossario . . . 77
A.2 Trasformazioni . . . 79
Elenco delle tabelle
2.1 Fasi del processo di sviluppo di Tropos. La metodologia `e basata su cinque passi
(4 1). Accanto al nome della fase c’`e una breve descrizione schematica. . . 8
2.2 Mapping Tropos - JACK. . . 11
3.1 Architettura su quattro livelli. Accanto alla descrizione di ogni singolo livello sono riportati alcuni esempi di nozioni modellabili (colonna di destra). . . 16
4.1 Passo 2: processo di identificazione delle capability. . . . 66
4.2 Passo 3: processo di agentificazione. Si identificano gli agenti e poi si assegnano le capability individuate al passo 2. . . 67
A.1 Actor Transformations tratte da [6]. . . 79
A.2 Goal Transformations tratte da [6]. . . 80
A.3 SoftGoal Transformations tratte da [6]. . . 81
A.4 Trasformazioni primitive per i goal tratte da [6]. . . 82
A.5 Trasformazioni primitive per i softgoal tratte da [6]. . . 83
A.6 Actor Primitive Transformations tratte da [6]. . . 83
Elenco delle figure
2.1 Actor modeling attraverso le cinque fasi del processo di sviluppo. . . . 12 2.2 Attivit`a di modellazione attraverso le cinque fasi del processo di sviluppo. . . 12 2.3 Tropos a confronto con altre metodologie AO per lo sviluppo di sistemi software. 14 3.1 Diagramma delle classi UML che specifica interamente il meta-metamodello di
Tropos. . . 17 3.2 Diagramma delle classi UML che visualizza le relazioni che si possono istanziare
a livello di dominio. . . 18 3.3 Diagramma delle classi UML che mostra la relazione esistente fra alcuni elementi
del meta-metamodello e del meta-modello di Tropos. L’asterisco sull’arco etichet-tato fulfillment impone una restrizione al concetto Goal: solo l’Hardgoal pu`o avere delle T-L Formula. . . . 19 3.4 Diagramma delle classi UML che specifica il meta-modello di Tropos riferito al
concetto ontologico di Actor. . . . 21 3.5 Diagramma delle classi UML che specifica la porzione del meta-modello di
Tro-pos riferito al concetto ontologico di Goal. . . . 25 3.6 Diagramma delle classi UML che specifica il meta-modello di Tropos riferito al
concetto ontologico di Plan. . . . 28 3.7 Diagramma delle classi UML che specifica il livello del dominio di Tropos.
L’at-toreCitizenvuole l’hardgoalget cultural information. . . 29
3.8 Diagramma delle classi UML che specifica il livello del dominio di Tropos riferito al dominio applicativo dell’eCulture System. . . . 30 3.9 Diagramma delle classi UML che specifica il livello oggetto di Tropos riferito al
dominio applicativo dell’eCulture System. . . . 30 3.10 Diagramma degli attori estratto dal case study eCulture System. . . . 32 3.11 Relazione fra l’attore genericoCitizene agent, position, role. . . 33 3.12 Estensione del diagramma degli attori che analizza le dipendenze tra attori del
sistema e attori sociali per l’attribuzione delle capability. Il rettangolo tratteggiato racchiude i subactor ai qualiInfo Brokerdelega alcune competenze. . . 34 3.13 Un esempio tipico di diagramma degli attori estratto dal case study. . . 36
3.14 Rappresentazione grafica dei tipi di analisi ammesse nel diagramma dei goal di Tropos e condotte all’interno del balloon. . . 38 3.15 Diagramma delle abilit`a riferito alla capabilityquery result. . . 39 3.16 Diagramma dei piani riferito al pianoevaluate query results. . . 41 3.17 Esempio di diagramma delle interazioni tra agenti riferito alle interazioni possibili
tra gli agenti. I messaggi sono asincroni. . . 42 4.1 Diagramma degli attori che introduce i due attori sociali dell’ambiente (MIePP)
con i rispettivi goal. . . 49 4.2 Diagramma dei goal costruito dal punto di vista dell’attorePotential Participant
sul suo hardgoalattend a meeting. . . 50 4.3 Diagramma dei goal costruito dal punto di vista dell’attoreMeeting Initiator
parte prima. . . 52 4.4 Diagramma dei goal costruito dal punto di vista dell’attoreMeeting Initiator
parte seconda. . . 53
4.5 Diagramma degli attori riassuntivo traMeeting SchedulerePotential
Partici-pant. . . 54 4.6 Diagramma degli attori che visualizza le dipendenze fra l’attore di sistemaMeeting
Schedule Systeme gli attori socialiMIe PP. . . . 56
4.7 Diagramma dei goal costruito dal punto di vista delMeeting Schedule System
parte prima: sono analizzati l’hardgoalgenerate data meeting (cd,tp,l) e
il softgoaleffective organization. . . 58
4.8 Diagramma dei goal costruito dal punto di vista delMeeting Schedule System
parte seconda: sono analizzati tre dei cinque goal che partecipano al soddisfaci-mento del goal root. . . . 60
4.9 Diagramma dei goal costruito dal punto di vista delMeeting Schedule System
parte terza: sono analizzati i due goal rimanenti,handle several meeting request
in paralleleavailable info easy. . . 61
4.10 Diagramma degli attori riassuntivo uscente dagli early e late requirements: primo passo dell’architectural design. . . . 63 4.11 Chiusura del primo passo dell’architectural design: sono introdotti nuovi attori di
sistema con relative dipendenze. . . 64 4.12 Secondo passo dell’architectural design: identificazione delle capability attraverso
l’analisi delle dipendenze di ciascun subactor. . . . 65
4.13 Diagramma delle abilit`a diget query result:information(numero 1 a). . . 68
4.14 Diagramma dei piani riferito aevaluate query result. . . 69 4.15 Diagramma delle interazioni tra agenti fra alcuni agenti del sistema. . . 70
Capitolo 1
Introduzione
Con il diffondersi di applicazioni software nei settori dell’eBusiness e dei servizi (telecomunica-zioni, pubblica amministrazione) si assiste ad una sempre pi`u pressante richiesta di architetture aperte, che possano evolvere ed includere nuovi componenti software. Nel corso degli ultimi an-ni, il processo di progettazione di tali sistemi software `e diventato sempre pi`u complesso. La definizione di appropriati meccanismi di comunicazione, di negoziazione e di coordinamento tra i componenti software e gli attori umani motiva lo studio di tecniche e metodi che supportino il progettista attraverso tutto il processo di sviluppo del software, dall’analisi dei requisiti fino all’implementazione.
Una risposta a questo problema `e venuta dalla scienza dell’ingegneria del software, che ha fornito nel corso degli ultimi anni molte tecniche, metodi e metodologie che hanno permesso di trattare sistemi software sempre pi`u complessi. L’approccio sistematico all’analisi, alla proget-tazione, alla programmazione e manutenzione di sistemi software ha obbligato molte comunit`a scientifiche a darsi delle regole e linguaggi comuni per risolvere problemi di grossa complessit`a. Ecco allora la necessit`a di definire dei linguaggi capaci di conservare il rigore del formalismo matematico e, allo stesso tempo, conservare un certo grado di intuitivit`a nel descrivere i domini applicativi ed eventuali soluzioni al problema che si vuole affrontare.
Accanto agli strumenti offerti dall’ingegneria del software servono dei paradigmi che permet-tono di modellare le entit`a coinvolte e gli obiettivi perseguiti da tali entit`a. A tal fine pu`o essere utile adottare concetti definiti in comunit`a scientifiche diverse quali il concetto di agente, utiliz-zato in Intelligenza Artificiale e nell’ingegneria dei requisiti, seppur con significati leggermente diversi. L’agente possiede degli obiettivi da soddisfare, `e autonomo nelle sue decisioni e nei suoi comportamenti, percepisce i cambiamenti provenienti dall’ambiente in cui opera e coopera con altri agenti al raggiungimento dei suoi obiettivi e di quelli comuni. Un gruppo di agenti che co-municano tra loro si definisce sistema multi-agente. I sistemi multi-agente offrono una soluzione a sistemi aperti, distribuiti e complessi.
de-INTRODUZIONE
nominato Agent-Oriented Software Engineering (AOSE). In questo contesto si colloca la nuova metodologia Tropos1 per la costruzione orientata agli agenti di sistemi software. Tropos copre cinque fasi del processo di sviluppo del software: early requirements consente di analizzare e mo-dellare i requisiti del contesto laddove il sistema software verr`a calato, late requirements si rivolge invece allo studio dei requisiti del sistema software da realizzare, architectural design e detailed design con l’obiettivo di progettare l’architettura del sistema software e, infine, implementation dove si conclude con l’implementazione del codice.
Questo documento ha come scopo quello di fornire una guida all’uso della metodologia Tropos attraverso le cinque fasi del processo di sviluppo del software, fornendo in particolare la struttura del linguaggio di specifica. Tale linguaggio `e un linguaggio di modellazione visuale semiformale composto da:
un’ontologia – un insieme di concetti per la modellazione. L’ontologia definisce
informal-mente il significato di tali concetti, cio`e non fornisce uno strumento formale che permetta di controllare la semantica dei modelli costruiti. Gli elementi che fanno parte dell’ontologia Tropos sono i seguenti: attori, goal, piani, risorse, dipendenze, abilit`a e credenze.
meta-modello – definisce la sintassi del linguaggio. Il meta-modello fornisce uno
strumen-to per controllare che i modelli siano sintatticamente corretti. `E stato specificato con un insieme di diagrammi di classe UML.
notazione grafica e diagrammi – stabilisce come raffigurare graficamente gli elementi dei
modelli.
insieme di regole d’uso – guidano la costruzione di un modello concettuale nelle varie fasi
del processo.
Il meta-modello permette di costruire modelli del dominio applicativo sulla base delle infor-mazioni raccolte nella primissima fase di analisi dei requisiti per poi raffinarli incrementalmente fino ad ottenere delle specifiche facilmente implementabili con qualche linguaggio di program-mazione. Il meta-modello di Tropos `e descritto tramite diagrammi delle classi UML. La base di partenza `e stato il lavoro di Eric Yu dove si usano i concetti di attore, goal e dipendenze tra attori. L’attore `e visto come un’entit`a strategica e sorgente d’intenzionalit`a. Dall’analisi di tale entit`a e delle sue dipendenze con altri attori mediante tecniche quali means-ends analysis, contribution e AND-OR decomposition, `e possibile individuare gli agenti e le rispettive capability che andranno a comporre il sistema software che risolve il problema. Gran parte dei concetti definiti nel meta-modello vengono usati lungo tutte le fasi che compongono la metodologia Tropos. All’interno del modello definiamo pi`u viste sullo stesso attraverso la costruzione di diagrammi specifici i qua-li consentono di approfondire gqua-li aspetti statici e dinamici del modello. Per ciascun diagramma
INTRODUZIONE
proponiamo la rappresentazione grafica, le linee guida che ne consentono l’uso attraverso tutte le fasi del processo e definiamo esattamente l’ingresso e l’uscita per ognuno. Per verificare il meta-modello di Tropos lo abbiamo applicato al caso di studio di un sistema per l’organizzazione di un meeting (d’ora in avanti indicato come Meeting Scheduler System).
Il documento che stiamo per presentare `e ricavato da un lavoro di tesi [40] sviluppato all’IRST nell’ambito di un progetto che coinvolge numerose universit`a ed istituti di ricerca nel mondo: IR-ST, Universit`a degli Studi di Trento, Universit`a di Toronto, Universit`a di York, Universit`a Federale di Pernambuco e Universit`a di RWTH Aachen.
Questa guida all’uso `e cos`ı strutturata. Il capitolo 2 descrive la metodologia Tropos, capitolo 3 il linguaggio di modellazione visuale con i relativi diagrammi, infine il capitolo 4 applica quanto visto al caso di studio Meeting Scheduler System.
Parte I
La Metodologia Tropos e il Linguaggio
di Modellazione
Capitolo 2
La metodologia
Nel corso degli ultimi anni molti fattori hanno causato un aumento esponenziale della complessit`a dei sistemi software. Esempi di applicazioni dove `e accaduto sono commerce, business, e-services e mobil computing. Il software deve essere basato su architetture aperte ed evolvere nel tempo per integrare nuovi componenti hardware e rispondere alla necessit`a di nuovi requisiti; `e determinante il grado di autonomia e robustezza di un sistema software, sia esso residente su poche e limitate macchine, sia esso distribuito. Oltretutto deve servire gli utenti da pi`u piattaforme senza necessitare di essere ricompilato ed operare con poche conoscenze circa l’ambiente di esercizio e circa i suoi utenti.
L’aumento della complessit`a richiede lo sviluppo di nuove tecniche e tool per l’analisi, proget-tazione, programmazione e manutenzione di sistemi software. A nostro avviso, questa pressante richiesta `e soddisfatta analizzando non solo il cosa e il come di un sistema software, ma anche il perch´e noi lo usiamo. Questo pu`o essere fatto mediante l’uso della metodologia Tropos che fruisce dell’esperienza e potenzialit`a del linguaggio di Eric Yu, i [46, 48, 49].
Tropos `e una metodologia AOSE che si basa su tre idee chiave [35, 34]:
1. Le nozioni di agente e di tutte le nozioni mentalistiche ad esso associate come goal, plan, belief, sono usate nella modellazione concettuale lungo tutte le fasi dello sviluppo software, dalla primissima fase di raccolta dei requisiti fino all’implementazione.
2. L’adozione di un approccio allo sviluppo del software detto “requirement driven” [29], dove si utilizzano concetti adatti alla modellazione dei requisiti (come quelli proposti in goal oriented analysis [9] e NFR analysis [10, 11, 9]) e li si portano anche in fasi successive quali quelle relative alla progettazione del sistema.
3. Costruzione di modelli concettuali seguendo un approccio trasformazionale in cui si parte da un modello iniziale dell’ambiente e lo si raffina ed estende incrementalmente fino ad ottenere un artifact eseguibile.
LA METODOLOGIA
La metodologia Tropos copre cinque fasi del processo di sviluppo: early requirements, late requirements, architectural design, detailed design e implementation. Tale metodologia `e stata presentata in numerosi documenti con l’aiuto dei case study eCulture System [23, 24, 35] e Meeting Scheduler System [26, 40].
Il resto del capitolo `e cos`ı strutturato: la sezione 2.1 illustra le fasi di cui si articola la metodo-logia, 2.2 i concetti chiave, 2.3 le attivit`a di modellazione, infine in 2.4 confrontiamo Tropos con altre metodologie agent-oriented.
2.1
Fasi del processo di sviluppo
All’interno dell’ingegneria del software l’analisi dei requisiti rappresenta la fase iniziale di molte metodologie. In maniera del tutto analoga, l’obiettivo centrale dell’analisi dei requisiti in Tropos `e quello di catturare un insieme di requisiti funzionali e non-funzionali per caratterizzare l’ambiente (environment) e il sistema futuro (system-to-be).
Fasi Descrizione sintetica
Early requirements Studio dell’ambiente o dell’organizzazione. L’output `e un modello organizzativo che include gli attori ri-levanti con associati i goal e le rispettive dipendenze.
Late requirements Studio del system-to-be all’interno del suo ambiente operativo. Sono definiti i requisiti funzionali e non-funzionali.
Architectural design Studio dell’architettura globale del sistema. Si com-piono tre passi specifici: introduzione nuovi attori di sistema, identificazione capability e processo di agen-tificazione.
Detailed design Studio di ciascun componente architetturale. Specifica di ogni singolo agente con relative capability, goal, belief e plan. L’architettura di implementazione `e stata scelta (esempio, BDI).
Implementation Implementazione del sistema elaborato nella fase prece-dente, utilizzando ad esempio delle piattaforme di svi-luppo AOP (JACK).
Tabella 2.1: Fasi del processo di sviluppo di Tropos. La metodologia `e basata su cinque passi (4 1). Accanto al nome della fase c’`e una breve descrizione schematica.
Dalla tabella 2.1 `e possibile notare come in Tropos questa fase viene suddivisa in due fasi di-stinte denominate rispettivamente early requirements e late requirements [23, 24, 6, 35, 34, 25].
2.1 FASI DEL PROCESSO DI SVILUPPO
Entrambe condividono gli stessi concetti e l’approccio metodologico, pertanto molte idee intro-dotte nella prima fase vengono riproposte anche nella seconda. Pi`u precisamente, durante l’early requirements l’ingegnere identifica gli stakeholder1e li modella come attori sociali che dipendono fra loro per goal da soddisfare, piani da eseguire e risorse da fornire. Infatti, dall’identificazio-ne di queste dipendenze `e possibile capire perch´e alcudall’identificazio-ne funzionalit`a sono preferibili ad altre ed avere un banco di prova per verificare che l’implementazione finale risulti allineata alle aspetta-tive iniziali. Il risultato di questa fase `e un particolare modello incentrato su attori sociali e loro dipendenze.
Nella seconda fase, late requirements, il modello concettuale prodotto precedentemente viene esteso per includere nuovi attori che rappresentano il sistema e dipendenze fra questi ultimi e quelli dell’ambiente. Tali dipendenze definiscono completamente i requisiti funzionali e non-funzionali. Dopo aver catturato tutti i requisiti dell’ambiente e del sistema il passo successivo `e rappresen-tato dalla fase di progettazione del sistema software. Anche in questo caso, si hanno due momenti con obiettivi distinti: architectural design e detailed design. Entrambe si focalizzano sulle speci-fiche del sistema in accordo con i requisiti prodotti dai due passi precedenti. architectural design definisce l’architettura globale del sistema in termini di subsystem interconnessi attraverso dati e flussi di controllo. I subsystem sono rappresentati nel modello con attori di sistema, mentre le interconnessioni con dipendenze. Questa fase si articola in tre passi:
1. Viene definita l’architettura del sistema software. Sono introdotti nel sistema dei nuovi attori risultanti dall’analisi eseguita nelle fasi precedenti:
– i subgoal provenienti dall’analisi dei goal di sistema vengono delegati ai nuovi attori appena identificati;
– introduzione di nuovi attori in funzione di particolari scelte architetturali;
– introduzione di nuovi attori che contribuiscono positivamente al soddisfacimento dei requisiti non-funzionali;
– decomposizione degli attori in subactor. Il fine della decomposizione `e espandere in dettaglio ciascun attore in riferimento ai propri goal e piani.
Il risultato finale di questo passo `e l’estensione del modello, nel quale vengono aggiunti nuovi attori e le loro dipendenze.
2. Identificazione delle capability2necessarie agli attori per soddisfare i loro goal ed eseguire i piani. Le capability sono identificate analizzando il modello. In particolare ciascuna re-lazione di dipendenza pu`o dar luogo a una o pi`u capability attivate da eventi. Il risultato `e
1Attori, o pi`u in generale entit`a, che hanno interesse a partecipare in un sistema software si dicono anche stakeholder. 2La traduzione in italiano del termine capability `e difficoltosa. Per questo motivo intendiamo usare indistintamente
LA METODOLOGIA
una tabella in cui su un lato sono riportati gli attori e sull’altro le capability loro assegna-te. Ancora non si stanno assegnando vincoli fisici ma solamente logici; non `e sicuro che gli attori individuati e le rispettive capability siano quelle che poi verranno effettivamente implementate.
3. L’ultimo passo prevede l’assegnazione degli agenti e delle capability. Tale processo va sotto il nome di agentificazione poich´e si definiscono definitivamente quali sono gli attori che verranno implementati nella fase successiva sotto forma di agenti run-time. In generale l’agentificazione non `e unica e dipende dal progettista. Anche in questo caso si produce una tabella nella quale si elencano gli agenti e le capability assegnate attraverso la numerazione fatta al passo 2.
La fase successiva, detailed design, punta a specificare ciascun agente nel suo interno, le capability e le interazioni che lo coinvolgono. A questo punto, solitamente, la piattaforma di implementazione `e stata scelta (ad esempio BDI) e ogni agente viene specificato tenendo conto della corrispondenza tra l’ontologia Tropos e i costrutti del linguaggio implementativo scelto.
L’ultima fase prevede l’implementazione di quanto ottenuto al passo precedente. Una piatta-forma BDI classica `e JACK [7, 14, 13]. La tabella 2.2 riassume la corrispondenza esistente tra i costrutti JACK e l’ontologia Tropos.
2.2
I concetti chiave
I modelli in Tropos sono acquisiti come istanze di un meta-modello concettuale (capitolo 3) composto di concetti e di relazione fra i concetti sotto elencati:
Actor – modella un’entit`a che possiede obiettivi strategici e intenzionalit`a all’interno del
sistema o dell’organizzazione. Un attore pu`o rappresentare una persona fisica, un animale, una macchina, cos`ı come un componente software. Si distinguono tre specializzazioni del-l’attore: agent, role e position. L’agente `e caratterizzato da delle propriet`a come autonomia, reattivit`a, proattivit`a, abilit`a sociale nel contesto in cui opera [44, 12, 28, 32, 1]. Ruolo `e una caratterizzazione astratta del comportamento di un attore sociale all’interno di un conte-sto specifico del dominio applicativo, posizione rappresenta un insieme di ruoli tipicamente ricoperti da un singolo agente. Cos`ı un agente pu`o occupare una posizione, mentre una posizione copre un ruolo. Notare che la nozione di attore in Tropos `e una generalizzazione della definizione classica di agente software in Artificial Intelligence (AI). Una discussione di questa questione si trova in [47].
Goal – rappresenta l’interesse strategico dell’attore che partecipa ad un sistema o ad una
organizzazione. Distinguiamo fra hardgoal e softgoal per il fatto che per i primi sappiamo dire con certezza e precisione quando sono soddisfatti, mentre per i secondi questo risulta
2.2 ICONCETTI CHIAVE
Costrutti Descrizione
Agent E usato per definire il comportamento di un agente intelligente.` Questo include le capability che un agente possiede, i tipi di messaggi ed eventi ai quali risponde e i piani che usa per soddisfare un goal.
Capability Include piani, eventi, belief e altre capability. Ad un agente possono essere assegnate pi`u capability, una capability pu`o essere assegnata a pi`u agenti.
Belief Attualmente, in Tropos, questo concetto `e usato solo nella fase implementativa, ma stiamo considerando di spostarlo fino alla pri-ma fase. Un database descrive un insieme di belief che un agente pu`o avere.
Event Gli eventi interni ed esterni specificati nel detailed design sono mappati negli eventi JACK. In JACK un evento descrive una con-dizione che lancia uno o pi`u piani.
Plan I piani contenuti all’interno della capability risultanti dal detailed design sono mappati nei piani JACK. Un piano in JACK `e una se-quenza di istruzioni che l’agente esegue per provare a soddisfare i goal e gestire gli eventi.
Tabella 2.2: Mapping Tropos - JACK.
pi`u complicato. I softgoal sono utili per la modellazione delle qualit`a del software, come, ad esempio, la sicurezza, le prestazioni e l’affidabilit`a [11].
Plan – rappresenta un opportuno insieme di azioni che permettono di soddisfare un goal. Resource – `e un’entit`a fisica oppure un’informazione (insieme di dati).
Dependency – una dipendenza fra due attori indica che un attore dipende dall’altro per
sod-disfare un goal, eseguire un piano oppure fornire una risorsa. L’attore che delega un proprio obiettivo fra quelli appena citati si chiama depender, mentre colui che riceve la dipendenza `e il dependee. L’oggetto della dipendenza `e detto dependum. Il dependee ha libert`a di sce-gliere come risolvere il dependum; per questo fatto il depender diventa vulnerabile. Se il dependee fallisce nel consegnare il dependum il depender potrebbe risentirne negativamente e pregiudicare le sue abilit`a nel soddisfare i propri goal.
Capability – rappresenta l’abilit`a di un attore nel definire, scegliere ed eseguire uno o pi`u
piani per soddisfare un goal. La capability si attiva in presenza di un evento.
LA METODOLOGIA
Notare come le nozioni di belief, goal (o desire) e plan (o intention) sono i concetti chiave anche nel paradigma BDI presentato in [38, 1].
System component Social System−to−be Actor Agent Focus su Early
Requirements RequirementsLate Architectural Design DetailedDesign Implementation
Figura 2.1: Actor modeling attraverso le cinque fasi del processo di sviluppo.
Belief Actor Dependency Capability Interaction Goal Plan Attivita’ di modellazione Early
Requirements RequirementsLate Architectural Design DetailedDesign Implementation
Figura 2.2: Attivit`a di modellazione attraverso le cinque fasi del processo di sviluppo.
2.3
Attivit`a di modellazione
La costruzione di un modello Tropos dall’early requirements sino all’implementazione coinvol-ge molte attivit`a che contribuiscono al processo di acquisizione, raffinamento ed evoluzione del modello stesso. Esse sono:
Actor modeling – consiste nell’identificare e analizzare sia gli attori dell’ambiente sia quelli del sistema (compresi gli agenti di sistema). La figura 2.1 mostra quali tipologie di attori o agenti sono approfonditi in ciascuna fase della metodologia. A livello di early requirements l’attenzione viene posta sugli stakeholder del dominio, ovvero attori propri dell’ambien-te che possiedono dedell’ambien-terminati goal da raggiungere. Durandell’ambien-te i ladell’ambien-te requirements l’analisi `e condotta su system actor, cio`e su attori del sistema software che si dovr`a realizzare. L’ar-chitectural design focalizza sulla struttura dell’attore di sistema specifico del system-to-be in termini di subactor. L’ultima fase di progettazione volge a definire le specifiche interne di ciascun agente con tutte le nozioni necessarie per passare poi all’implementazione finale del sistema software.
2.3 ATTIVITA DI MODELLAZIONE`
Dependency modeling – consiste nell’identificazione degli attori che dipendono da altri per goal da soddisfare, piani da eseguire e risorse da fornire. Nella prima fase della metodologia, early requirements, si modellano le dipendenze fra gli attori sociali dell’organizzazione. So-no aggiunte nuove dipendenze in conseguenza dell’attivit`a di Goal modeling descritta sotto. Operativamente, nei late requirements si compie lo stesso lavoro fatto negli early require-ments tranne che ora si discutono gli attori del sistema futuro (system-to-be). Nella fase di architectural design i dati e flussi di controllo vengono modellati con delle dipendenze fornendo le basi per l’identificazione delle capability e la successiva agentificazione. Goal modeling – `e l’attivit`a di analisi dei goal dal punto di vista di un attore usando tre tec-niche: ends analysis, contribution e AND-OR decomposition. In particolare, means-ends analysis punta a identificare goal, piani e risorse che forniscono i mezzi necessari per soddisfare il goal. Contribution permette di trovare goal che contribuiscono positivamente o negativamente al soddisfacimento del goal radice (root). AND-OR decomposition consente di costruire grafi AND-OR (tecnica tipica della comunit`a AI) di subgoal per capire come sia possibile soddisfare la radice. L’attivit`a si esaurisce nell’architectural design quando si decompongono gli attori di sistema in subactor.
Plan modeling – pu`o essere considerata un’attivit`a simile alla quella condotta sul goal. Comprende le medesime tecniche di analisi condotte per`o sul piano anzich´e sul goal. Capability modeling – inizia verso la fine dell’Architectural design quando i subactor di sistemi sono stati specificati in termini dei loro goal e dipendenze con gli altri attori. Ciascun subactor introdotto in questa fase potrebbe essere capace di definire, scegliere ed eseguire un piano per soddisfare i suoi goal. Durante il detailed design ciascun agente `e ulteriormente specificato e codificato nell’ultima fase che prevede l’implementazione degli agenti e delle capability.
Belief modeling – consiste nel rappresentare le credenze (belief) di ogni agente in riferimento allo stato del mondo che lo circonda. I belief guidano la scelta dei piani da eseguire e degli agenti stessi da implementare. `E un’attivit`a tipica della fase di detailed design quando ciascun agente viene specificato a micro livello.
Interaction modeling – consiste nella specifica del protocollo comunicativo.
La figura 2.2 illustra qualitativamente il ruolo delle attivit`a di modellazione all’interno delle fasi del processo di sviluppo, assieme ai concetti intenzionali. La modellazione della nozione di attore avviene lungo tutto il processo poich´e si tratta di un concetto portante. Le altre attivit`a sono specifiche all’interno di qualche fase; per esempio, le attivit`a riguardanti le capability e le credenze sono rilevanti solo nella fase di detailed design e di implementazione.
LA METODOLOGIA
2.4
Tropos a confronto con altre metodologie
L’obiettivo di questa sezione `e confrontare Tropos con le altre metodologie e linguaggi di mo-dellazione che seguono un’approccio agent-oriented (AO) come i , KAOS, GAIA, AAII, MaSE e AUML. Una analisi pi`u approfondita di ognuna di queste si trova in [40].
La figura 2.3 mette a confronto le seguenti metodologie:
i*
Kaos
Early Late
Requirements Architectural Design DetailedDesign Requirements
Tropos
Gaia AAII AUML and MaseFigura 2.3: Tropos a confronto con altre metodologie AO per lo sviluppo di sistemi software. Come appare chiaro dalla figura 2.3, nessun altra metodologia che abbiamo preso in esame copre tutte e quattro le aree di sviluppo del processo produttivo relative all’analisi e progettazione del software.
Per le fasi di early e late requirements Tropos si avvantaggia del lavoro fatto dalle comunit`a RE, e in particolare dal linguaggio i di Eric Yu, il quale dispone di una struttura versatile ed intuitiva per modellare le dipendenze strategiche fra attori distribuiti. `E interessante notare che gran parte della metodologia Tropos pu`o essere combinata con approcci che non sono agent-oriented (ad esempio, object-oriented o imperativo). Per esempio, si potrebbe usare Tropos per la fase degli early requirements e poi usare UML per le successive [25]. Particolare attenzione merita anche KAOS, una metodologia rivolta principalmente alla fase in cui si analizzano gli attori di sistema.
I modelli che si costruiscono con Gaia trattano la parte di analisi e raccolta dei requisiti (system-to-be) e la parte architetturale globale. AAII `e invece rivolta alla sola progettazione cos`ı come AUML che eredita l’approccio di UML ottimo per la definizione di diagrammi progettuali ma lontano da ci`o che noi intendiamo quando parliamo di analisi e specifica dei requisiti di un sistema software. Tuttavia, per la fase di detailed design la nostra scelta `e rivolta alle tecniche e strumenti di AUML che si sono riconosciuti essere assai validi.
Capitolo 3
Il linguaggio di modellazione
L’attivit`a di modellazione concettuale tramite un linguaggio di specifica formale, semiformale o informale accompagna l’analista lungo tutte le fasi che conducono alla consegna di un software di qualit`a, dall’analisi dei requisiti alla specifica dei componenti software. In Tropos si inizia dagli early requirements ispirandosi a i e KAOS, per proseguire con i late requirements, architectu-ral design e detailed design dove si sfruttano alcune tecniche tipiche di AUML. Infine, si passa all’implementazione, ad esempio utilizzando una piattaforma ad agenti, quale JACK.
Il linguaggio di modellazione visuale utilizzato in Tropos `e un linguaggio di specifica semi-formale per il quale sono stati definiti:
un’ontologia – un insieme di concetti per la modellazione. L’ontologia definisce
informal-mente il significato di tali concetti, ma non fornisce uno strumento formale che permetta di controllare la semantica dei modelli costruiti. Gli elementi che fanno parte dell’ontologia Tropos sono i seguenti: actor, goal, plan, resource, dependency, capability e belief. Essi sono stati descritti in sezione 2.2,
meta-modello – definisce la sintassi del linguaggio. Il meta-modello fornisce uno
strumen-to per controllare che i modelli siano sintatticamente corretti. `E stato specificato con un insieme di diagrammi di classe UML. La descrizione `e data in dettaglio in sezione 3.1,
notazione grafica e diagrammi – stabilisce come raffigurare graficamente gli elementi dei
modelli. Notazione grafica e diagrammi sono descritti in dettaglio in sezione 3.3,
insieme di regole d’uso – che guidano la costruzione di un modello concettuale nelle varie
fasi del processo. Se ne d`a un esempio nell’illustrare l’uso dei diagrammi nelle varie fasi del processo di sviluppo in sezione 3.3 e nel caso di studio finale nel capitolo 4.
3.1
Il meta-modello
IL LINGUAGGIO DI MODELLAZIONE
1. avere una sintassi ben formata,
2. estendere in futuro il meta-modello senza doverlo stravolgere ogni qual volta sia necessario inserire nuovi elementi,
3. essere semplice ma espressivo,
4. non mescolare elementi pertinenti a livelli d’astrazione diversi. Viceversa si rischierebbe di perdere in precisione e in leggibilit`a del modello,
5. fornire un insieme di regole per la costruzione di modelli corretti; supportare strategie differenti per l’acquisizione del modello,
6. fornire tutti gli elementi concettuali necessari per specificare completamente i modelli degli early requirements cos`ı come quelli del detailed design,
7. uniformare il nostro linguaggio a molti altri che utilizzano un’architettura fondata su quattro livelli; in particolare UML (e dunque anche AUML), KAOS e, in parte, i ,
8. il meta-metamodello `e strategico nel processo di integrazione fra il nostro lavoro, che punta pi`u su aspetti informali e sulla definizione e correttezza della sintassi, e quello prodotto dal gruppo che sta lavorando su un sottoinsieme del linguaggio a semantica univoca, Formal Tropos [37, 22].
Il meta-modello del linguaggio di modellazione `e definito da una architettura composta di quattro livelli: il meta-metamodello, il meta-modello, il livello del dominio e il livello oggetto. La tabella 3.1 riassume i quattro livelli fornendo una breve descrizione correlata da un semplice esempio. Tali livelli sono stati specificati usando i diagrammi delle classi UML versione 1 3.
Livelli Descrizione Esempi
meta-metamodello Definisce il linguaggio per la Attribute,
specifica del meta-modello. Entity.
meta-modello Un’istanza del meta-metamodello. Actor, Goal, `
E il cuore del linguaggio. Dependency.
dominio Un’istanza del meta-modello. PAT, Citizen: Definisce un modello del dominio istanze di
applicativo. Actor.
oggetto Un’istanza di un’entit`a definita al Mary: istanza
livello del dominio. Citizen.
Tabella 3.1: Architettura su quattro livelli. Accanto alla descrizione di ogni singolo livello sono riportati
3.1 IL META-MODELLO
3.1.1 Il livello meta-metamodello
Il meta-metamodello di Tropos `e la struttura pi`u astratta dell’intero linguaggio; lo scopo primario `e definire gli elementi minimi del linguaggio necessari per la specifica del meta-modello. Costituisce le fondamenta sulle quali costruire il meta-modello che ne `e una particolare istanza.
Con il grigio (scuro per le classi base, chiaro per quelle ausiliarie) sono mostrati in figura 3.1 gli elementi caratteristici del meta-metamodello.
Entity
T-L Formula
Attribute
Basic
0..nN-ary Relationship
Constrainable Entity
invariant 0..n creation 0..nFigura 3.1: Diagramma delle classi UML che specifica interamente il meta-metamodello di Tropos.
La classe Entity1 `e usata in Tropos per rappresentare gli elementi intenzionali e non-intenzionali che esistono nell’ambiente o nell’organizzazione (environment o organizational set-ting). Ogni istanza della classe Entity2 `e definita dal nome e da un insieme di attributi modellati con la classe Attribute. Quest’ultima definisce degli attributi che possono essere Basic, e dunque ad esempio interi, stringhe, booleani, oppure una struttura pi`u complessa come un’entit`a. Un’i-stanza di Entity possiede 0 n istanze della classe Attribute che a sua volta pu`o essere specializzata in Basic oppure in Entity stessa.
Entity generalizza (`e la super classe di) Constrainable Entity: ogni sua istanza `e definita da un insieme di attributi e propriet`a (oltrech´e da un nome). I primi sono ereditati dalla super classe Entity, mentre le seconde sono modellate con la classe UML T-L Formula che sta per Temporal Logic Formula. Constrainable Entity pu`o avere 0 n istanze della classe T-L Formula. Le propriet`a fissano delle regole che l’istanza della classe Constrainable Entity deve soddisfare al momento della sua creazione e/o durante il suo ciclo di vita. Infatti, la classe T-L Formula ricopre due
1Questo ed altri termini si possono trovare nel glossario in appendice A.1.
2Per evitare di appesantire la descrizione del linguaggio useremo “un’istanza della classe del meta-modello”
IL LINGUAGGIO DI MODELLAZIONE
diversi ruoli, creation oppure invariant. La creation, come si pu`o facilmente intuire, descrive una condizione che deve essere ottenuta all’atto della creazione dell’istanza della classe. Invariant esprime una condizione di invarianza dell’entit`a, un qualcosa che non muta lungo tutto il suo ciclo di vita.
T-L Formula e Attribute sono delle formule scritte in logica temporale di primo ordine che si usano di solito a livello oggetto per descrivere particolari caratteristiche delle entit`a del dominio applicativo che si sta studiando. Il linguaggio che specifica tali attributi e propriet`a `e detto Formal Tropos3.
L’ultimo elemento che appare all’interno del meta-metamodello `e N-ary Relationship; rag-gruppa tutte le relazioni possibili che si possono definire sulle istanze di Entity a livello di domi-nio. La figura 3.2 mostra quali sono le relazioni che il linguaggio ammette (N-ary Relationship compare in 3.2 e anche nel diagramma di figura 3.1). Tali relazioni sono state colorate di bianco poich´e esse non fanno parte del meta-metamodello bens`ı del meta-modello. Tuttavia, `e utile in-trodurle gi`a da ora perch´e permettono di capire in quale maniera si passa da un livello a quello successivo.
N-ary Relationship
Contribution
AND-OR decomposition Means-Ends Analysis Dependency
Figura 3.2: Diagramma delle classi UML che visualizza le relazioni che si possono istanziare a livello di
dominio.
3.1.2 Il livello meta-modello
Il meta-modello di Tropos `e un livello logico (e non fisico o implementativo) che si focalizza sui concetti ontologici essenziali e indipendenti dal dominio applicativo.
Il meta-modello `e un’istanza del meta-metamodello e al suo interno troviamo le meta-classi che modellano gli elementi essenziali del linguaggio, ovvero Actor, Goal Plan, Resource, Dependency. La figura 3.3 mostra alcuni elementi del meta-modello (in grigio scuro) che estendono quelli del meta-metamodello (in bianco). Gli elementi intenzionali come Actor e Dependency assieme a Resource sono specializzazioni della classe Constrainable Entity che abbiamo incontrato al livello precedente; altri, come Goal e Plan, sono ottenuti specializzando la super classe Entity.
3La discussione del linguaggio Formal Tropos non `e pertinente con gli obiettivi di questa tesi, dunque non entreremo
3.1 IL META-MODELLO Actor Entity T-L Formula Plan Goal Attribute Basic Resource Dependency 0..n fulfillment Constrainable Entity fulfillment* invariant 0..n creation 0..n
Figura 3.3: Diagramma delle classi UML che mostra la relazione esistente fra alcuni elementi del
meta-metamodello e del meta-modello di Tropos. L’asterisco sull’arco etichettato fulfillment impone una restrizione al concetto Goal: solo l’Hardgoal pu`o avere delle T-L Formula.
Come gi`a spiegato la presenza di Constrainable Entity `e dovuta all’integrazione con il linguag-gio Formal Tropos secondo cui ci sono entit`a (Goal e Plan) che possiedono solo attributi ed entit`a che invece possiedono anche propriet`a di tipo invariant e creation (Dependency, Actor e Resour-ce). In aggiunta a tutto ci`o, sia la Dependency, sia Goal ricoprono il ruolo di fulfillment rispetto a T-L Formula (per la classe Goal questa associazione `e valida solamente se si parla di Hardgoal e non di Softgoal) cosicch´e `e possibile descrivere formalmente quando un goal `e soddisfatto o meno. Per poter affermare che un goal o una dipendenza di tipo hardgoal `e soddisfatta, abbiamo bisogno di esprimere delle condizioni tramite predicati precisi, corretti e ben formati.
Il meta-modello di Tropos estende la struttura offerta da i quali attore (agent, role e position), goal e dipendenze tra attori come concetti primitivi per modellare un applicazione durante tutte le fasi del processo di sviluppo, non solo nell’early requirements. Il meta-modello `e stato sviluppato intorno a questi concetti fondamentali e specificati attraverso diagrammi delle classi UML; sia i concetti, sia le relazioni fra gli stessi sono rappresentate attraverso delle classi.
IL LINGUAGGIO DI MODELLAZIONE
Sono molte le definizioni che si trovano nella letteratura riguardanti gli elementi appena citati e diversi sono pure i significati attribuiti; noi abbiamo preso spunto dalla comunit`a dell’Intelligenza Artificiale dove si usano pesantemente concetti come agent, belief, desire, intention. Per chi desidera approfondire consigliamo le letture [5, 41, 38].
Il concetto di attore
L’attore `e un’entit`a che possiede degli obiettivi strategici all’interno del sistema op-pure dell’organizzazione che ospita il sistema software stesso; inoltre `e sorgente di intenzionalit`a.
L’attore possiede degli obiettivi strategici, cio`e ha delle motivazioni precise che lo spingono a partecipare al sistema o all’ambiente. Nella figura 3.4, l’attore `e rappresentato per mezzo di una classe UML chiamata Actor; le associazioni mostrano le relazioni significative che coinvolgono la classe suddetta.
L’istanza della classe Actor pu`o avere 0 istanze della classe Goal la quale modella il concetto di obiettivo perseguito (wanted by) da un attore. Nel modello Tropos ogni attore che partecipa all’environment o al system-to-be possiede almeno un goal (anche sotto forma di dipendenza). Ci`o risulta in perfetta sintonia con la filosofia secondo cui l’attore, in quanto sorgente di intenzionalit`a, autonomo e capace di decisioni, partecipa ad un sistema o ad una organizzazione poich´e ha degli obiettivi che qualificano la sua presenza.
L’istanza della classe Goal `e associata a 0 istanze della classe Actor. Tropos, e lo discu-teremo meglio quando parleremo del diagramma degli attori, non ammette l’esistenza di un goal che non sia attribuito a qualche attore (implicitamente stiamo affermando che non ci possono es-sere system goal). Detto questo, al lettore potrebbe sorgere il dubbio legittimo che la cardinalit`a corretta sia 1 anzich´e 0 . Nell’ipotesi 1 non ci potrebbe essere nel modello Tropos un goal senza almeno un attore che se ne assuma la responsabilit`a; parimenti, almeno in via di principio, con 0 `e possibile introdurre nel modello un goal senza che necessariamente sia attribuito ad un attore. Cerchiamo di spiegare il motivo di questa scelta attraverso un semplice esempio. Consi-deriamo la situazione particolare in cui il goal, nella sua accezione pi`u generica, sia il frutto di una decomposizione in OR e che dunque non sia di propriet`a di qualche attore ma rappresenti una possibile alternativa al soddisfacimento del goal radice (goal sul quale si compie la GA).
Suppo-niamo che l’attore Citizendesideri decomporre il goalget cultural information. Usando
i mezzi tipici della Goal Analysis [9, 15] il processo di raffinamento produce un grafo in OR
di subgoal, rispettivamentevisit cultural institutionsevisit cultural web system.
Potrebbe accadere che il primo venga assegnato all’attore stesso, mentre per il secondo non ci sia volont`a di attribuzione. Essendo una decomposizione in OR, uno solo dei due sar`a percorso men-tre l’altro verr`a presumibilmente abbandonato e pertanto non assegnato. Con l’ausilio di questo
3.1 IL META-MODELLO
Dependency
Actor
dependee dependerBelief
dependumPlan
Resource
Mode
Maintain
Avoid
Achieve
Achieve&Maintain
Goal
{XOR} {XOR} dependum dependum why 0..1 why 0..1 why 0..1 wants 0..n has 1..n 0..n are believed wanted by 0..nFigura 3.4: Diagramma delle classi UML che specifica il meta-modello di Tropos riferito al concetto
IL LINGUAGGIO DI MODELLAZIONE
semplice e ricorrente esempio si spiega perch´e `e necessario fissare la molteplicit`a 0 fra la classe Goal e quella Actor.
Un attore pu`o avere 0 istanze della classe Belief; questa nozione, che `e tipica del paradigma BDI (belief-desire-intention), potr`a essere assai utile quando, in fase di detailed design, si sceglier`a uno specifico paradigma per rappresentare gli stati mentali dell’attore. Fino a quel momento per`o, nulla `e assunto per quanto riguarda l’architettura che modella gli stati interni. `E interessante notare la molteplicit`a della relazione inversa: la classe Belief `e associata ad 1 attori. Ci`o significa che se esiste, il belief deve essere assegnato ad almeno un attore.
Dependency E una relazione a quattro campi tra: due istanze della classe Actor, una fra Goal,` Plan e Resource e una opzionale ancora tra Goal, Plan e Resource.
L’attore che delega un qualche tipo di dipendenza ricopre il ruolo di depender, mentre quello che riceve l’incarico `e il dependee. Per specificare il tipo di dipendenza (dependum) si sceglie uno fra Goal, Plan e Resource adottando una tipica notazione UML che permette di porre in OR esclusivo tutte le classi raccordate dalla linea verticale tratteggiata con a fianco l’etichetta X OR (si veda figura 3.4). L’ultima associazione (why), che sappiamo essere opzionale, `e ottenuta anco-ra scegliendo tanco-ra Goal, Plan e Resource; la notazione `e la stessa usata precedentemente, solo che questa volta la molteplicit`a `e 0 1 sottolineando che si tratta di un campo non obbligatorio. Dun-que, una dipendenza fra due attori risulta essere una quaterna depender dependum dependee
why
(l’asterisco indica che `e un campo opzionale). Mettiamo in evidenza il fatto che la rela-zione `e da ritenersi ben formata nel momento in cui si hanno due istanze della classe Actor e una tra Goal, Plan e Resource che ricopre il ruolo di dependum; istanziare la quarta associazione `e del tutto arbitrario e a discrezione dell’analista. In quest’ultimo caso la conseguenza immediata `e ridurre la relazione quaternaria a ternaria.
Mentre il significato attribuito ai ruoli di depender, dependee e dependum `e abbastanza chia-ro (ricordiamo che servono per modellare le dipendenze strategiche tra gli attori), la presen-za del why pu`o sembrare fuorviante o addirittura inutile. Cos`ı non `e. Riprendiamo
l’esem-pio dell’eCulture System tornando alla decomposizione del goal get cultural information
da parte dell’attore Citizen. Nel compiere l’analisi l’attore ha prodotto, fra l’altro, il piano
visit eCulture System (figura 3.13). La sua decomposizione ha individuato altri due piani,
access interneteuse eCulture System. Successivamente sono stabilite tre nuove
dipenden-ze con laPAT,internet infrastructure availablescaturita daaccess internet,usable
eCulture SystemeeCulture System availabledause eCulture system. Il ruolo why `e
ricoperto dai due piani che danno luogo a queste nuove dipendenze: dunque, il quarto campo della relazione di dipendenza serve a tenere traccia delle motivazioni che spingono l’attore a consegnare una sua responsabilit`a ad un altro. `E sostanzialmente un documento storico che permette di risalire a posteriori al motivo che ha scaturito la dipendenza. Quindi, nel caso del planaccess internet
3.1 IL META-MODELLO
che d`a luogo al dependuminternet infrastructure available, la struttura completa della dipendenza `e Citizen internet in f rastructure available PAT access internet
.
Come appendice conclusiva, la figura 3.4 mostra l’associazione tra la classe Dependency e la classe Mode. In fase di analisi si dovr`a procedere a specificare, mediante specializzazione di Mode, il modo di raggiungimento della dipendenza stabilita con un altro attore. Le possibilit`a a disposizione sono quattro:
achieve – l’attore si prefigge di soddisfare il goal o la dipendenza una volta solamente,
oppure,
maintain – significa che l’obiettivo dovrebbe essere mantenuto nel tempo, oppure,
achieve&maintain – `e una combinazione dei precedenti, una volta raggiunto lo scopo,
questo deve perdurare nel tempo, oppure,
avoid – significa che l’obiettivo dovrebbe essere evitato.
Tropos dispone di tre specializzazioni della classe Actor:
agent – nel senso classico inteso dalla comunit`a AI e in sintonia con quanto affermato nel
capitolo 2: un attore con abilit`a nel contesto sociale in cui si trova ad operare, autonomo, reattivo e pro-attivo, oppure,
role – `e una caratterizzazione pi`u fine del comportamento di un attore nell’ambito di un
insieme di interazioni (dipendenze, eventi comunicativi, ecc.),
position – rappresenta un insieme di ruoli, tipicamente ricoperti da un agente. Un agente
pu`o occupare una posizione, mentre una posizione ricopre un ruolo.
La letteratura corrente riporta parecchie sfumature a proposito del concetto di ruolo: ad esem-pio in [8, 33], il ruolo `e inteso come un insieme di dipendenze e di protocolli comunicativi tra agenti, cio`e rappresentano delle situazioni ricorrenti che si schematizzano in strutture concettuali per poterle in un futuro riusare. Tali strutture sono comunemente dette patterns4. Empiricamente si verifica che per certe classi di domini applicativi si possono adottare degli schemi simili per determinare una strategia di soluzione; il ruolo dei patterns `e appunto quello di fornire delle so-luzioni per alcune classi di problemi. Nel campo dell’ingegneria dei requisiti sono molto diffusi questi patterns poich´e incarnano situazioni che un progettista si trova a dover affrontare continua-mente: infatti, in un’approccio diffuso e consolidato da anni come l’object-oriented (OO) l’uso dei patterns `e molto frequente. In AUML si parla di agent-role come un insieme di agenti che soddisfano alcune propriet`a, comportamenti particolari e forniscono servizi comuni. In maniera
4All’URL http://hillside.net/patterns/patterns.htm `e disponibile una guida completa dei patterns
IL LINGUAGGIO DI MODELLAZIONE
analoga anche in [18] si introduce il ruolo come una rappresentazione astratta delle funzioni e servizi di un agente.
La relazione di dipendenza `e stata introdotta da i in [46] e ripresa da Tropos; si dimostra utile per la rappresentazione delle dipendenze strategiche tra attori. Esistono, a riguardo, svariate teorie sulle dipendenze per i sistemi multi-agente. Una definizione classica tratta da [33], afferma che
la teoria delle dipendenze `e basata sull’idea che le interazioni fra gli attori pro-vengano dalla incompatibilit`a tra gli obiettivi dei singoli attori e le sue risorse e capacit`a.
Tipicamente, un attore non riesce a soddisfare tutti i suoi obiettivi e intenzioni; ci possono essere delle azioni, dei goal e dei comportamenti che in generale non sono raggiungibili senza il sostegno da parte di suoi simili, costringendolo ad interagire e stabilire appunto delle dipendenze di qualche genere. Tropos supporta questa teoria modellando le dipendenze strategiche fra attori mediante la relazione Dependency.
I tipi di dipendenza sono abbastanza intuitivi: pu`o essere un goal generico, un piano da esegui-re oppuesegui-re una risorsa. Una esegui-resource rappesegui-resenta un’entit`a fisica o un contenitoesegui-re di informazioni (ad esempio, il modello UNICO della dichiarazione dei redditi).
Il concetto di goal
Il goal modella gli obiettivi che un attore vuole raggiungere (il vero motivo per cui un attore partecipa ad un sistema).
Il diagramma delle classi di figura 3.5 rappresenta il concetto di goal generico in Tropos.
La classe Goal pu`o essere specializzata in Hardgoal, oppure in Softgoal. Hardgoal rappre-senta un obiettivo che l’attore pu`o potenzialmente e pienamente soddisfare eseguendo uno o pi`u piani, sostanzialmente si pu`o definire un criterio in base al quale stabilire se esso `e stato raggiunto o meno (magari avvalendosi anche delle T-L Formula che esprimono le condizioni di fulfillment per un hardgoal attraverso predicati precisi e ben formati). Cattura quelli che in ingegneria dei requisiti si chiamano requisiti funzionali. Diversamente, un softgoal `e un goal del quale non si rie-sce esattamente e con precisione ad affermare che `e stato pienamente soddisfatto: analogamente a quanto detto per gli hardgoal, i softgoal modellano i requisiti non-funzionali in ingegneria del software. Tali requisiti, spesso chiamati di qualit`a, non possono essere definiti precisamente e in modo oggettivo (ad esempiouser friendlyriferito ad un’interfaccia grafica). Per determinare un criterio di soddisfacimento sono necessari sforzi aggiuntivi da parte dell’analista e del cliente.
`
E auspicabile che vengano condotte ulteriori interviste con gli utenti del sistema software cos`ı da consentire un approfondimento delle caratteristiche di qualit`a che il prodotto finale dovr`a ave-re. Questa pratica produrr`a presumibilmente nuovi requisiti che verranno concretizzati in precise scelte progettuali e tecnologiche.
3.1 IL META-MODELLO Means-Ends analysis Mode Maintain Achieve Achieve&Maintain Goal {XOR} {XOR} mean Resource Plan mean mean AND-OR decomposition OR-decomposition AND-decomposition 0..n 0..n 1..n 1..n Hardgoal Softgoal root Avoid root Contribution contributes to contributed by Actor pointview end 1..n 1..n
Figura 3.5: Diagramma delle classi UML che specifica la porzione del meta-modello di Tropos riferito al
IL LINGUAGGIO DI MODELLAZIONE
I goal possono essere analizzati, dal punto di vista di un attore, mediante i processi di Means-Ends analysis, Contribution e AND-OR decomposition.
Means-Ends analysis E una relazione ternaria definita tra: un’istanza della classe Actor, il quale` fornisce il suo punto di vista, un Goal che funge da obiettivo da raggiungere (end), motivo per cui si istanzia la Means-Ends analysis, e uno tra Goal, Plan e Resource che ricopre il ruolo di mean.
Se analizziamo la figura 3.5, la classe Goal (notare che essa ricopre il ruolo di “end”, cio`e il fine da raggiungere) pu`o avere 1 istanze della classe Means-Ends analysis. Questo permette all’analista di condurre pi`u analisi sul medesimo goal per ottenere pi`u visione dello stesso obiet-tivo. La Means-Ends analysis `e condotta dal punto di vista di un solo attore e su un solo goal (molteplicit`a uguale a 1). L’associazione mancante per completare la relazione ternaria proviene dall’istanza di una delle entit`a poste in OR esclusivo. La cardinalit`a fra il ramo etichettato con X OR e la classe Means-Ends analysis `e 1 ; questo consente, ad esempio, allo stesso piano di essere coinvolto in altre analisi condotte su altri goal e quindi partecipare a pi`u means-ends analysis.
Means-Ends analysis `e un particolare tipo di analisi che permettere di capire cosa sia ne-cessario fare per soddisfare un goal (end) in termini di piani, risorse, hardgoal e softgoal (mean).
Contribution La Contribution `e una relazione ternaria tra: un’istanza della classe Actor, che fornisce il punto di vista di chi conduce l’analisi (pointview), un’istanza della classe Goal che riceve il contributo (contributed by) e una fra Goal, Plan e Resource (contributes to). L’idea `e di trovare quei goal che contribuiscono positivamente o negativamente al raggiungimento del goal che si sta esplorando; da notare che essa `e un caso particolare della Means-Ends analysis, dove il mezzo `e solamente il goal.
La Contribution `e adatta quando non si hanno informazioni sufficienti per poter individua-re una strategie certa per soddisfaindividua-re un goal; supponiamo il caso in cui la decomposizione del goal g1 porti ad individuare un goal g2. g2 per`o non fornisce garanzie sul pieno e completo sod-disfacimento di g1 e per questo motivo `e probabilmente opportuno utilizzare lo strumento dei contributi.
Esiste la possibilit`a di misurare con un’opportuna metrica il peso dei contributi. La scala di misurazione `e composta di cinque livelli,
. In particolare, se il goal g1contribuisce positivamente al goal g2 con la metrica , allora equivale a dire che g2 `e automaticamente soddisfatto nell’istante in cui lo `e g1; analogamente, se il piano p contribuisce positivamente al goal g con , allora p esegue g. Se il contributo fornito al goal g2dal piano p, dal goal g1o dalla risorsa r `e allora significa che questi contribuiscono solo parzialmente al soddisfacimento di g2. Viceversa, se la metrica `e
oppure
abbiamo delle situazioni duali rispetto alle precedenti. Il caso di contributi tra softgoal `e leggermente diverso; in questo caso l’idea `e valutare i
re-3.1 IL META-MODELLO
quisiti non-funzionali per tentare di capire quali situazioni sono favorite dalla presenza di con-tributi positivi, e quali invece vengono tralasciate poich´e i requisiti di qualit`a forniscono metri-ca negativa. Una trattazione pi`u ampia riguardo i requisiti funzionali e non-funzionali si trova in [9, 15, 2, 11, 10, 40].
AND-OR decomposition Nello spirito tipico dell’ingegneria del software che esorta alla de-composizione del problema in sotto problemi [27, 36], Tropos definisce la AND-OR decomposi-tion come relazione ternaria che associa il punto di vista dell’attore, il goal radice e un insieme di istanze di AND decomposition oppure OR decomposition. Per goal radice intendiamo quel goal che vogliamo esplorare con le tecniche usuali della goal analysis.
La classe Goal ricopre il ruolo di root con entrambi le specializzazioni della AND-OR decom-position (figura 3.5). Un’istanza di Goal pu`o avere 1 istanze della classe AND-decomposition (OR-decomposition). Analogamente a quanto fatto per le dipendenze, anche per la classe Hard-goal (e non per il softHard-goal) `e previsto l’attributo Mode che sar`a ulteriormente specializzato in
achieve, maintain, achieve&maintain e avoid.
Le due classi AND-decomposition e OR-decomposition specializzano la AND-OR decompo-sition ereditando la relazione che fornisce il punto di vista dell’attore (pointview). La AND-OR decomposition, a sua volta, `e un’aggregazione delle sue sotto classi; in particolare, un’istanza della classe AND-OR decomposition `e composta di una sola istanza della AND-decomposition (OR-decomposition), mentre l’istanza di AND-decomposition (OR-decomposition) potrebbe possedere
0 di AND-OR decomposition.
Applicare una AND-OR decomposition significa cercare dei goal che consentono di de-comporre la root in tanti subgoal via via pi`u semplici da risolvere. Se si tratta di una AND-decomposition allora per soddisfare il goal radice g `e necessario che tutti i suoi subgoal siano soddisfatti, se invece questi sono posti in OR-decomposition il goal g `e soddisfatto quando al-meno uno dei suoi subgoal lo `e. Un goal radice possiede alal-meno una decomposizione in AND oppure in OR; non solo, per avere una visione completa del problema, l’analista pu`o, a suo pia-cimento, condurre pi`u decomposizioni del medesimo goal (molteplicit`a 1 fra la root e AND oppure OR-decomposition). Cos`ı facendo, la scelta di quale strategia adottare per risolvere il goal radice ricade su un numero ampio di possibilit`a.
Una nota particolare: se il goal radice g1 risulta decomposto in un goal singolo g2, allora il grafo cos`ı ottenuto `e equivalente alla relazione ternaria Contribution con metrica fra i due goal g1e g2.
Il concetto di piano
Il piano modella cosa `e possibile fare per soddisfare un goal, una volta scelta l’opportuna strategia. Un attore `e capace di scegliere, definire ed eseguire dei piani. Il diagramma delle classi UML di figura 3.6 rappresenta il concetto di plan in Tropos.
IL LINGUAGGIO DI MODELLAZIONE Means-Ends analysis Plan {XOR} mean Resource mean AND-OR decomposition OR-decomposition AND-decomposition 0..n 0..n 1..n 1..n root root Actor pointview end 1..n 1..n 0..n Goal is capable of 0..n is fulfilled pointview 1..n
Figura 3.6: Diagramma delle classi UML che specifica il meta-modello di Tropos riferito al concetto
ontologico di Plan.
L’attore `e capace di definire, scegliere, eseguire 0 piani, mentre l’istanza di Plan pu`o avere 0 attori (lo zero `e incluso per lo stesso motivo discusso nel caso del Goal, pu`o rappresentare un’alternativa non eseguita nel caso di una decomposizione in OR su un piano). Il piano esegue un solo Goal, mentre un goal pu`o avere a disposizione da 1 a n piani che ne permettono il soddi-sfacimento. Esiste la possibilit`a che il piano contribuisca al soddisfacimento di un goal attraverso la relazione ternaria Contribution mediante opportune metriche (leggere sezione precedente).
Il meta-modello permette la costruzione di grafi AND-OR di piani come nel caso del goal. La AND-OR decomposition consente di decomporre il piano root in subplan; il processo pu`o termi-nare solo quando i subplan sono direttamente eseguibili dall’attore che ha svolto l’analisi, oppure quando si rende conto lui stesso di non essere in grado di eseguirli. La Means-Ends analysis, rispetto al caso del Goal, restringe le entit`a che possono ricoprire il ruolo di mean alla Resource oppure al Plan mantenendo la stessa molteplicit`a 1 .
All’interno di varie comunit`a (AI, Agents, software engineering) il concetto di plan `e spesso confuso con quello di task. Anche nel nostro caso la discussione si `e protratta a lungo poich´e ognuno portava ragioni fondate a favore di un termine piuttosto che per l’altro. Ad esempio il
3.1 IL META-MODELLO
plan nella comunit`a Agents `e visto come una sequenza di azioni run-time che permettono il sod-disfacimento di un goal. Diversamente il task `e un compito da eseguire e generalmente non viene neppure specificato come viene eseguito. Per questo `e pi`u vicino ad un’intenzione (intention del paradigma BDI), cio`e ad un obiettivo che un agente si impegna a raggiungere, piuttosto che ad una sequenza di azioni svolte a run-time.
Questa `e uno dei tanti modi di intendere task e plan. La nostra decisione finale prevede di considerare, almeno nella fase di raccolta e modellazione dei requisiti, i due concetti equivalenti, lasciando libert`a di scelta a chi usa la metodologia.
3.1.3 Il livello del dominio
Il livello del dominio di Tropos (domain level) `e un’istanza del meta-modello di-pendente dal dominio applicativo. Tutti i suoi elementi sono istanze di classi del meta-modello (un’oggetto `e un’istanza di una meta-classe, cos`ı come una relazione `e un’istanza di una meta-classe).
Actor
get cultural information Citizen
Hardgoal
wants wanted by
Figura 3.7: Diagramma delle classi UML che specifica il livello del dominio di Tropos. L’attoreCitizen
vuole l’hardgoalget cultural information.
Come suggerisce il nome, il livello del dominio si riferisce ad uno specifico dominio applicati-vo; se i precedenti livelli erano indipendenti dal dominio e il loro scopo era di fissare i componenti e le loro relazioni, ora si vuole porre attenzione su situazioni particolari. La figura 3.7 riporta il domain level nel caso dell’hardgoalget cultural informationassegnato all’attoreCitizen.
L’oggettoCitizen`e una specializzazione della classe Actor; esso eredita l’associazione uni-direzionale e il ruolo (wants). L’altro oggetto del dominio `eget cultural informationistanza della classe Hardgoal. Notare che a questo livello parliamo di oggetti e non di classi perch´e siamo in un contesto che dipende dal dominio in esame.
La figura 3.8 mostra un diagramma UML dove i due attori Citizen (depender) e PAT
(dependee) sono coinvolti nella dipendenza con dependumtaxes well spent.
3.1.4 Il livello oggetto
Il livello oggetto di Tropos (instance level) `e un’istanza del livello del dominio: lo scopo `e scendere ancora nel livello di astrazione e nei dettagli per raffinare il modello.
