download tesi - MobiLab - Università degli Studi di Napoli Federico II

UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
TESI DI LAUREA
Un approccio basato su ontologie per l’integrazione di sistemi
per la gestione del traffico aereo
RELATORE
Ch.mo Prof. Domenico Cotroneo
CORRELATORE
Ing. Giancarlo Cinque
ANNO ACCADEMICO 2007-08
CANDIDATO
Adalberto Scognamiglio
matr. 41/2855

…a mia nonna
…alla mia famiglia
…ed a tutte le persone che mi vogliono bene
ii

« È la mancanza di fede che rende le persone paurose di accettare una
sfida, e io ho sempre avuto fede: infatti, credo in me »
(Muhammad Ali)
iii

Ringraziamenti
...meglio tardi che mai……e si!! anche io finalmente sono giunto dopo tanti
anni e tanta fatica al momento dei ringraziamenti,...e di persone che devo
ringraziare, ah no che mi devono ringraziare, ah no…sono un po’
confuso…c'è ne son tante……lo so, non vi sembra vero, ma anche a me non
sembra vero quante persone ho dovuto sopportare!!
adesso però devo iniziare, ed allora iniziamo dagli addetti ai lavori…
La prima che devo ringraziare è la sedia della mia scrivania, poverina,
nessuno può negarle lo sforzo prodotto in tutti questi anni!! Abbiamo legato
molto, come si dice…sedere e camicia…
per non parlare del mio libretto che ha visto la luce un paio di volte
l'anno……sapete com'è…per non fargli prendere freddo…
ma diventiamo seri come siamo sempre stati!!!
…il primo che mi deve ringraziare è giancarlo, il guru, gli ho fatto capire
cosa sono le ontologie, che SWIM è nu 'mbrogliooo ma soprattutto gli ho
fatto capire che significa lavorare in una certa maniera…'a pariààààà!!
grazie gianky…
…il secondo che mi deve ringraziare è domenico. gli ho fatto capire come si
gioca a tennis ma soprattutto gli ho fatto capire che il suo colpo più potente
è il dritto dritto negli spogliatoi…vabè non prendertela almeno sei forte a
tavola panzarò…!! grazie dome…tvb!!
poi c'è quel chiattone di christian…che da quando mi ha conosciuto capisce
solo i makkeroni…magna, però è nu brav uaglion…
…un grosso ringraziamento me lo deve il mio "strano" zio meglio
conosciuto come antonio nazionale, uno che in questo periodo invece di una
mano è sempre pronto a dare un dito, a fare un colloquio a tutti od a
chiedere un passaggio…e vabè se lo merita anche lui…
…un ringraziamento me lo deve dario di crescenzo, almeno ha avuto un
altro portatile con cui giocare…
…non posso dimenticare nutella, grazie a lui mi sono sentito zeus in
persona…
…e poi c'è il pecchione, il super pecchione sempre pronto a scappare da
un’altra parte quando gli devi kiedere qualcosa…solo le femmine sanno
come immobilizzarlo!!!grazie per le cofecchie su google talk…
…passiamo adesso agli addetti alla perdita di tempo, perchè di studiare
veramente non se n'è mai parlato…mi piace partire da lontano…
c'era una volta tanto tempo fà un ragazzo con tanti capelli…per gli amici
alfredo per me fofò…è bene si, è tutta colpa sua, se non mi avesse mai fatto
copiare quella prova di inglese…io adesso sarei qualcuno ed invece…
stamm nguaiat!! …pantani o eiffel65…mi hai insegnato che con la volontà
si può arrivare ovunque e prima degli altri!!! forza fofò…sei il più forte!!!
…poi vennero rino, mimmo e felice…mi hanno sperduto…chissà adesso
dove stanno… ci fu poi stanislao ed il mio primo trenta…e si…non ci
crederete ma ho trenta trenta!! ma non li ho fatti registrare sul
libretto…anzi non li ho fatti registrare proprio!!
e fin qui son stato uno studente…poi è iniziato il lavoro e le cattive
amicizie…
iv

…un nome su tutti…caccavale…il mio super eroe…quante risate…l'unico a
cui ho permesso sempre di copiare…o lo ami o lo odi…per me un amiko
sincero…ed ankora rocco, emanuele, claudio, mauro………
…arriviamo ai giorni nostri....
…tutto iniziò quando un tipo con capelli strani, un pò bruttino, ma che
sembrava simpatico mi telefonò chiedendomi se volevo fare il doppio con
lu…io risposi guarda che già sono doppio da solo, ma insieme possiamo
vincere…e per me veramente fu una grande conquista…non giocava male
anche se dovevo spiegargli cosa fare in campo in ogni momento, ma la sua
grande qualità fu quella di farmi conoscere tante persone con cui adesso
passo gran parte dei miei giorni…….e allora fu Michele…ed io finalmente,
qualcuno peggio di me!! da quel giorno non mi ha lasciato più, ho provato
ad abbandonarlo per strada, in un canile, in una discarica ma niente…son
costretto a portarlo con me anche in vacanza!! ma adesso mi sono fatto
furbo, gli ho regalato il giocattolino…la farfallina rossa che gli ha
muzzicato o muss…adesso deve stare attento a quello che fa…grazie
carmen………e gabriellina…sport4life…se non ci fosse lei ad organizzare
le partire ed a sbucciarmi le mele…sei forte gabry!!!
…un grazie al rosso, conosciuto da poko ma con cui ho subito legato…ed
un grazie a peppe trincia…almeno non sarò l'ultimo del vecchio
ordinamento!!! ……… e mo il difficile…
padre gigi…il mio bombolo preferito…mi ha insegnato il poker ma
soprattutto mi ha insegnato che vuol dire aiutare gli altri…tvb!!…e donna
mena…come farei senza di lei e le sue crepes…il sikkazzo…pronto sempre
ad offrirmi una pizza… hhhhuuuuulllllldddddd…grosso grasso e
bambinone…troppo buono!!!
ed ankora…nino,salvatore,rosalia,la signora anna, luca, antonio pirozzi,
maria, marcoragno, peppone, mimmo, debora, picardi, danilo, angelo,
luigi, alessandro, iole, attilio, marilena, paola, ivan, enrico, luca, elda,
fabio, viola, gianmaria, stefania, valentina la pinguina, silvio, nazzareno,
enzo pirone, giovanna, marinella, nello, antonio, alessandro e filippo,
salvatore, marianna, valeria, nicola, marianna...
un ringraziamento particolare al sig. dott. Eugenio Esposito, che con la sua
stima e i suoi consigli non mi ha mai fatto perdere di vista il mio vero
obiettivo……
ed ora è il momento delle persone a me più care…non scriverò tante parole
perchè spero di riuscire, ogni giorno, a far capire loro quanto sono
importanti per me....
Ringrazio ogni giorno mia nonna Ersilia, che è stata e continuerà ad essere
il mio spirito…
Ringrazio mio padre, per me esempio di onestà e dignità…
Ringrazio mia madre… la mia guida e più cara consigliera…
Ringrazio i miei fratelli, i miei complici più fedeli…
Ringrazio sara, che è la mia forza di ogni giorno…
Ringrazio tutti gli zii ed i cugini che giorno dopo giorno mi hanno incitato a
non mollare...
Ringrazio i genitori e le zie di sara per la stima che hanno in me…
ma passiamo sul serio alle persone serie!!!
Ringrazio il DIS ed il Mobilab nelle persone del prof Russo, marcello,
generoso e lelio.
v

Ringrazio il Cini che mi ha coccolato per lungo tempo, grazie ad imma,
pietrantuono, carlo sanghez, stanislao, nicola, massimo ficco e salvatore
d'antonio.
Ringrazio il Sesm nelle persone di massimo, sara, alfonso ed i tanti amici
che ho conosciuto li...frank&frank,ivano&ivana,ezio,peppe,enzo e daniele..
Spero di non aver dimenticato nessuno, ma qualora fosse successo, sarò
contento di ringraziarlo di persona perchè il solo fatto che abbia letto
queste righe significa che a lui non sono uno sconosciuto.
vi

Indice
INTRODUZIONE 1
CAPITOLO 1 4
INTEGRAZIONE DI SISTEMI GEOGRAFICAMENTE 4
ESTESI PER L’AIR TRAFFIC MANAGEMENT 4
1.1 – Introduzione 4
1.2 – Ultra Large Scale System 6
1.3 – Air Traffic Management 11
1.3.1 – Contesto 11
1.3.2 – Gestione di un volo 11
1.3.3 – Limiti attuali della gestione del traffico aereo 14
1.3.4 – Il futuro Sistema ATM Europeo: SESAR 16
1.4 – SWIM - System Wide Information Management 18
1.4.1 – Overview 18
1.4.2 – Definizione 20
1.4.3 – SWIM-SUIT 21
1.4.3.1 – Architettura stratificata 22
1.4.3.2 – SWIM ATM Information Model 24
1.4.3.3 – Caratteristiche Generali e Sfide Aperte 26
CAPITOLO 2 35
GESTIONE SEMANTICA DEI DATI: LE ONTOLOGIE. 35
2.1 – Introduzione 35
2.2 – Definizioni 36
2.3 – Esigenze che spingono a modellare semanticamente un dato dominio 39
2.4 – Vantaggi nell’uso di Ontologie 41
2.5 – Tipi di ontologie 43
2.6 – Costruzione di un’ontologia 44
2.7 – Web Semantico come esempio di impiego di ontologie 50
2.7.1 – Contesto 50
2.7.2 – Architettura del Web Semantico 53
2.8 – Linguaggi per la definizione di ontologie 56
2.8.1 – URI : Uniform Resource Identifiers 56
2.8.2 – XML : Extensible Markup Language 58
2.8.3 – RDF : Resource Description Framework 64
2.8.3.1 – RDF Data Model 65
2.8.3.2 – RDF Schema 69
2.8.4 – OWL : Ontology Web Language 73
2.8.4.1 – I tre linguaggi di OWL 76
2.8.4.2 – I costrutti principali di OWL 78
2.9 – Reasoning 80
2.10 – Tools per la definizione e l’utilizzo di Ontologie 84
2.10.1 – PROTÉGÉ : Editor per Ontologie 85
2.10.2 – SPARQL : Query Language 86
2.10.3 – PELLET : Un Reasoner per OWL 88
2.10.4 – JENA 90
vii

CAPITOLO 3 94
DEFINIZIONE DI UN SEMANTIC MESSAGE ORIENTED MIDDLEWARE A SUPPORTO
DEI SISTEMI ATM 94
3.1 – Introduzione 94
3.2 – Pattern Cooperativi per l’ATM 95
3.3 – Java Message Service 101
3.3.1 – MOM : Modello Orientato ai Messaggi 101
3.3.2 – JMS 105
3.4 – Definizione di un Information Model per l’ATM 112
CAPITOLO 4 121
DEFINIZIONE DI UN INFORMATION MODEL BASATO SU ONTOLOGIA PER IL
SISTEMA SWIM 121
4.1 – Introduzione 121
4.2 – Scenari Considerati 122
4.2.1 – Calcolo della lista di distribuzione dei dati di volo 122
4.2.2 – Definizione dei Ruoli a partire dai dati 128
4.2.3 – Correlazioni tra i cluster dei dati di volo 130
4.3 – Information Model 132
4.3 – Applicazione 141
4.3.1 – Architettura 141
4.3.2 – Presentazione dei Risultati 143
CONCLUSIONI E SVILUPPI FUTURI 148
RIFERIMENTI 150
viii

Indice delle figure
FIGURA 1.1 - MIDDLEWARE .....................................................................................10
FIGURA 1.2 - FASI DI UN VOLO.................................................................................12
FIGURA 1.3 - EATMS (VISIONE GENERALE) ............................................................19
FIGURA 1.4 - ARCHITETTURA STRATIFICATA DI SWIM............................................22
FIGURA 1.5 - CONNESSIONE SISTEMA ATM-SWIM .................................................23
FIGURA 1.6 - SESAR ATM INFORMATION MODEL..................................................25
FIGURA 1.7 - ESTENSIONE GEOGRAFICA ..................................................................27
FIGURA 1.8 - GLOBAL DATA SPACE.........................................................................30
FIGURA 1.9 - DECENTRALIZZAZIONE........................................................................31
FIGURA 1.10 - ETEROGENEITÀ DEI DATI...................................................................32
__________________________________________________________________
FIGURA 2.1 - INDIPENDENZA DAL VOCABOLARIO ....................................................37
FIGURA 2.2 - ESEMPIO SCHEMA ONTOLOGIA ...........................................................38
FIGURA 2.3 - ARCHITETTURA DEL WEB SEMANTICO ...............................................55
FIGURA 2.4 - ESEMPIO DI COSTRUZIONE DI UNA RICETTA IN XML ..........................59
FIGURA 2.5 - ESEMPIO DI BIBLIOGRAFIA..................................................................60
FIGURA 2.6 - ESEMPIO DI RICETTA CON BIBLIOGRAFIA............................................60
FIGURA 2.7 - ESEMPIO DI DEFINIZIONE DI UN NAMESPACE........................................61
FIGURA 2.8 - SOLUZIONE DELL’AMBIGUITÀ CON I NAMESPACE................................62
FIGURA 2.9 - IDENTIFICATORE (URI) PER NAMESPACE.............................................63
FIGURA 2.10 - PREFISSI E NAMESPACE......................................................................63
FIGURA 2.11 - XML STRUTTURA AD ALBERO...........................................................64
FIGURA 2.12 - DATA MODEL RDF, SOGGETTO, PREDICATO E OGGETTO.................66
FIGURA 2.13 – RDF - STRUTTURA A GRAFO.............................................................67
FIGURA 2.14 - SERIALIZZAZIONE RDF DOCUMENT .................................................68
FIGURA 2.15 - GLI STRATI RDF E RDFS .................................................................72
FIGURA 2.16 - GENESI DI OWL................................................................................74
FIGURA 2.17 - OWL VS RDF/RDFS ........................................................................75
FIGURA 2.18 - STACK OWL ONTOLOGY..................................................................76
FIGURA 2.19 - LIVELLI LINGUAGGI OWL.................................................................77
FIGURA 2.20 - ESEMPIO OWL HEADER ...................................................................78
FIGURA 2.21 - COSTRUTTI OWL PER LA DEFINIZIONE DI CLASSI..............................79
FIGURA 2.22 - COSTRUTTI OWL PER LA DEFINIZIONE DI PROPRIETÀ .......................79
FIGURA 2.23 - FINESTRA PROTÈGÈ...........................................................................85
FIGURA 2.24 - SEMPLICE ESEMPIO DI QUERY SPARQL...........................................88
FIGURA 2.25 - PELLET SYSTEM ARCHITECTURE[23]................................................90
FIGURA 2.26 - LINGUAGGI PER ONTOLOGIE E RELATIVE URI ..................................92
__________________________________________________________________
FIGURA 3.1 - DEFINIZIONE DEI RUOLI ......................................................................96
FIGURA 3.3 - COMUNICAZIONE DI TIPO REQUEST-RESPONSE ....................................98
FIGURA 3.4 - SCHEMA GENERALE D’INTERAZIONE ..................................................99
FIGURA 3.5 - GLOBAL DATA SPACE.......................................................................100
FIGURA 3.6 - MOM COMUNICAZIONE TRAMITE CODE DI MESSAGGI ......................102
FIGURA 3.7 - PUBLISH-SUBSCRIBE MESSAGING.....................................................104
FIGURA 3.8 - POINT-TO-POINT MESSAGING.............................................................108
ix

FIGURA 3.9 - PUBLISH-SUBSCRIBE MESSAGING .......................................................109
FIGURA 3.10 - JMS API PROGRAMMING MODEL ....................................................112
FIGURA 3.11 - ICOG : DISTRIBUTION CLUSTER.......................................................113
FIGURA 3.12 - SCRIPT CLASS DIAGRAM...................................................................114
FIGURA 3.13 - FLIGHTIDENTIFICATION CLASS DIAGRAM.........................................115
FIGURA 3.14 - TRAJECTORY CLASS DIAGRAM .........................................................116
FIGURA 3.15 - FLIGHTKEY CLASS DIAGRAM ...........................................................117
FIGURA 3.16 - FLIGHTPLANDATA CLASS DIAGRAM................................................118
__________________________________________________________________
FIGURA 4.1 - TRAJECTORY.....................................................................................123
FIGURA 4.2 - AREE ASSOCIATE AI SISTEMI .............................................................123
FIGURA 4.3 - ILLUSTRAZIONE DELLE AREE ............................................................124
FIGURA 4.4 - CORRISPONDENZA SISTEMI - AREE ...................................................126
FIGURA 4.5 - TRAJECTORY BOUNDARY POINT ..........................................................126
FIGURA 4.6 - ESTRATTO ONTOLOGIA OWL ...........................................................133
FIGURA 4.7 - TASSONOMIA INFORMATION MODEL..................................................134
FIGURA 4.8 - TASSONOMIA DATATYPE PROPERTIES................................................137
FIGURA 4.9 - DIZIONARIO DATATYPE PROPERTIES..................................................138
FIGURA 4.10 - TASSONOMIA OBJECT PROPERTIES..................................................138
FIGURA 4.11 - DIZIONARIO OBJECT PROPERTIES....................................................140
FIGURA 4.12 - COMPONENT AND DEPLOYMENT VIEW ..............................................141
FIGURA 4.13 - ARCHITETTURA A LIVELLI DELL’APPLICAZIONE..............................142
FIGURA 4.11 - SCENARIO OPERATIVO 2 .................................................................144
FIGURA 4.12 - OUTPUT SCENARIO 1.......................................................................145
FIGURA 4.13 - SCENARIO OPERATIVO 2 .................................................................146
FIGURA 4.14 - OUTPUT SCENARIO 2.......................................................................147
x

Introduzione
Negli ultimi anni, l’attenzione della comunità informatica si è rivolta verso i
cosiddetti “Enterprise Architecture Systems”. Con questo termine s’intende
un ampia classe di sistemi eterogenei, con proprietari diversi, che svolgono
funzioni diverse, messi insieme al fine di realizzare processi complessi in
maniera interoperabile. Nonostante decenni di sviluppo delle tecnologie
informatiche, i requisiti imposti da questi sistemi moderni rendono
difficoltoso se non impossibile la realizzazione ex-novo di una soluzione
software con tali caratteristiche. In tempi recenti, l’ingegneria del software
ha quindi puntato l’attenzione su approcci di sviluppo, processi e strumenti
che appoggiano l’idea di estendere la vita di soluzioni esistenti realizzando
soluzioni che supportano la visione secondo cui grossi sistemi software
possono essere assemblati a partire da altri sistemi o applicazioni
indipendenti, riusabili ma soprattutto eterogenee.
In un contesto così esteso, al quale normalmente ci si riferisce parlando di
“System of Systems”, l’esigenza che emerge fortemente è quella di realizzare
l’interoperabilità tra piattaforme hardware e software fortemente eterogenee,
spesso incompatibili tra di loro che prevedono l’integrazione di sistemi di
1

tipo legacy o comunque realizzati in periodi in cui requisiti come
l’interoperabilità non erano sentiti come invece lo sono adesso.
Ed allora un modo di concepire sistemi di tipo Enterprise è quello di
considerarli come composti da un insieme di tanti sistemi indipendenti che
si integrano e collaborano realizzando funzionalità complesse attraverso la
composizione dei servizi offerti da ciascuno di essi ma soprattutto attraverso
un efficiente meccanismo di condivisione delle informazioni.
Un esempio di “system of systems” sarà il sistema di nuova generazione per
la gestione delle informazioni del traffico aereo. Fino ad oggi i sistemi per
l’ATM, per lo più sistemi di tipo legacy, sono stati sviluppati
indipendentemente l’uno dall’altro con la conseguenza che risultano poco
integrabili fino al punto da non consentire la disponibilità nel modo e nel
momento giusto delle informazioni pertinenti. In questo contesto si cala il
progetto SWIM, un progetto della Comunità Europea, che intende, definire
l’infrastruttura di un sistema che favorendo l’interoperabilità nel mondo
ATM costruisca mediante l’utilizzo di tecnologie moderne, affidabili e
sicure un ‘Global European System’ basato su un modello delle
informazioni condiviso. Pertanto, in un sistema con queste caratteristiche e
questi propositi tanto ambiziosi, devono essere presenti meccanismi
flessibili per la gestione dei vari sistemi, che permettano l’integrazione ed il
coordinamento di questi ma che contemporaneamente minimizzino le
relative interdipendenze e non ne compromettano le prestazioni .
Centrando, quindi, l’attenzione sull’interoperabilità dei sistemi soprattutto
per quanto riguarda i dati, questa proprietà può essere ottenuta rilassando le
dipendenze tra i vari sistemi che devono comunicare, in particolare,
minimizzando le connessioni di tipo end-to-end che necessitano che i
2

sistemi coinvolti si siano preventivamente accordati su formati e protocolli e
rilasciando nuove funzionalità che forniscano valore aggiunto al patrimonio
dei dati, in tempi rapidi ed a costi contenuti. La realizzazione di un Global
Data Space, è un requisito fondamentale per un sistema con tali
caratteristiche.
In tempi moderni, elemento centrale per l’interconnessione e l’integrazione
dei sistemi è l’utilizzo di un’infrastruttura middleware per l’accesso ai dati
(Data Access Middleware) in modalità asincrona.
Nell’ottica sempre di facilitare l’interoperabilità tra sistemi ed applicazioni
distribuite in rete, particolare interesse rivestono allora anche gli aspetti di
modellazione delle informazioni. Come auspicato dall’inventore del Web,
Tim Berners Lee, problemi di interoperabilità tra i sistemi e di gestione delle
relative risorse, saranno risolti nel momento in cui i dati non avranno
soltanto una struttura (sintassi) chiaramente definita ma anche un significato
(semantica) condiviso dalla comunità che li utilizza. In questo contesto non
è più sufficiente unicamente strutturare i dati, ma si necessita di un ulteriore
livello di modellazione delle informazioni che attraverso l’utilizzo di
linguaggi formali permetta di ottenere una conoscenza sempre più machine-
processable dei dati che si vanno a trattare a supporto di tutte le possibili
attività decisionali e governative che si devono intraprendere.
3

1.1 – Introduzione
Capitolo 1
Integrazione di sistemi geograficamente
estesi per l’Air Traffic Management
Alla fine degli anni ’80, la diffusione delle reti di calcolatori e dei sistemi
distribuiti ha fatto emergere una nuova dimensione nell’industria del
software: la prospettiva dello sviluppo di sistemi su larga scala attraverso
l’integrazione di sistemi. Con il termine Enterprise Architecture Systems si
intendono proprio sistemi eterogenei, con proprietari diversi, che svolgono
funzioni diverse, messi insieme al fine di realizzare processi complessi in
maniera interoperabile.
Lo sviluppo delle reti ha fatto crescere per aziende ed organizzazioni
complesse l’esigenza di un nuovo approccio allo sviluppo dei propri sistemi,
per adeguarsi alla diversità ed ai cambiamenti delle tecnologie hardware,
software e di rete. Un approccio basato non più soltanto sulla progettazione
ex-novo dei sistemi, ma che estende la vita di soluzioni già esistenti
definendo nuove funzionalità nei sistemi pre-esistenti ed integrando sistemi
legacy che non devono essere esclusi.
4

Nell’era delle reti di telecomunicazione, l’eterogeneità delle tecnologie
hardware e software e la distribuzione geografica sono da considerarsi la
norma, non più l’eccezione, e ciò anche all’interno di una stessa
organizzazione, pubblica o privata che sia. Di conseguenza, in uno scenario
simile, non si può prescindere da requisiti quali indipendenza tecnologica ed
interoperabilità sia a livello di dati che a livello applicativo. In Particolare
nel contesto della gestione del traffico aereo, in cui i sistemi legacy ed i
sistemi di nuova generazione devono continuamente collaborare, requisiti
come quelli sopra elencati, richiedono meccanismi sempre più evoluti per la
condivisione delle informazioni. Il focus diventa, quindi, quello di realizzare
sistemi ed applicazioni fortemente orientate ai dati, in cui ogni informazione
abbia un significato preciso e condiviso tra i vari attori che quindi sanno
come gestirla e manipolarla.
Il capitolo inizia con un ampia panoramica su cosa s’intende per sistemi su
larga scala, quali sono le caratteristiche e le sfide che presentano.
Si procede poi con un’introduzione al mondo ATM, si definiscono gli
attori, le procedure che tali attori devono espletare e soprattutto i vincoli
istituzionali e tecnologici che tali sistemi devo affrontare e che
inevitabilmente ne influenzano i comportamenti nonché le prestazioni.
In tale contesto interviene SESAR, un progetto della Comunità Europea per
la realizzazione di un sistema su larga scala, di nuova generazione, per la
gestione del traffico aereo in grado di superare le limitazioni attuali. Ed in
tale ambito vanno inseriti a loro volta i progetti SWIM e SWIM-SUIT. Il
primo ha come obiettivo la realizzazione di un infrastruttura per
l’integrazione dei sistemi ATM legacy andando a costruire un pool virtuale
per la condivisione delle informazioni tra tali sistemi; il secondo, invece,
5

cerca di realizzare un prototipo come risultato di uno studio di fattibilità del
più ampio SWIM.
1.2 – Ultra Large Scale System
Oggi giorno, vista la crescente complessità dei sistemi, l’ingegneria del
software pone attenzione su approcci di sviluppo, processi e strumenti alla
cui base c’è l’idea che i sistemi software di grandi dimensioni possano
essere assemblati a partire da collezioni di sistemi e funzionalità
indipendenti e riusabili. Alcuni di questi elementi possono essere già
esistenti o acquisiti da terze parti o possono essere sviluppati ex-novo. In
ogni caso l’intero sistema deve essere progettato in modo da far coesistere
tutti questi elementi in un unico e coerente ambiente. Con l’avvento delle
reti di calcolatori e dei sistemi distribuiti, lo scenario di cui sopra si estende
allo sviluppo di sistemi su larga scala. I sistemi software caratterizzati da
un’ ampia estensione geografica, in inglese Ultra-Large-Scale systems,
rappresentano quindi la nuova frontiera dei sistemi distribuiti complessi[1].
In un ambiente fortemente distribuito, diversi fattori legati alla distribuzione
e all’eterogeneità rendono complessa l’attività di sviluppo di software di
qualità. La componente software di un sistema ULS che in genere è
complessa e caratterizzata da codice di grandi dimensioni, realizza attività di
business articolate, che coinvolgono sistemi ed utenti di natura eterogenea.
Suddetti sistemi avranno certamente caratteristiche differenti quali hardware
e sistemi operativi diversi e spesso non interoperanti. Ed ancora sistemi ed
utenti richiedono di condividere una grande quantità di dati che saranno
distribuiti su più nodi di elaborazione, memorizzati in archivi e con sistemi
di gestione di basi di dati (DBMS) diversi. L’ estensione geografica, insieme
6

agli aspetti di cui sopra, sono alcune delle principali caratteristiche dei
sistemi ULS, ma per comprendere bene la loro natura è necessario
approfondire alcuni degli aspetti che sono invece trascurabili per i sistemi di
medie e piccole dimensioni. Pertanto le caratteristiche principali di un
sistema ULS sono:
• Indipendenza funzionale dei sottosistemi: ogni sistema
componente è indipendentemente utilizzabile.
• Indipendenza gestionale degli elementi: ciascun sottosistema può
essere gestito in maniera indipendente rispetto agli altri e all’intero
sistema ULS.
• Sviluppo Evolutivo: sistemi complessi funzionanti non vengono
sviluppati integralmente ex-novo. Tipicamente essi evolvono a
partire da sistemi già esistenti e funzionanti in maniera graduale ed
incrementale anche durante il loro funzionamento.
• Distribuzione Geografica: i vari componenti sono dislocati
geograficamente e pertanto la loro interazione richiede un massiccio
scambio di informazioni.
• Decentralizzazione: data la loro estensione geografica, la gestione
gerarchica o centralizzata dei dati, dello sviluppo, dell’evoluzione e
del controllo funzionale è praticamente impossibile.
• Evoluzione continuativa: gli ULS systems avendo un lungo ciclo di
vita, necessitano dell’integrazione continua di nuove funzionalità e
della rimozione di quelle obsolete non più utilizzate, senza
compromettere la funzionalità complessiva del sistema.
• Eterogeneità: dei suoi componenti hardware, software e delle
procedure. Tale eterogeneità è dovuta allo sviluppo di parti del
7

sistema con linguaggi di programmazione e tecniche differenti, su
diverse piattaforme hardware/software, secondo differenti paradigmi
e metodologie di progettazione. Inoltre in molti casi, parte degli
elementi sono legacy systems realizzati precedentemente.
• Inconsistenza: dato il vasto numero di teams che creano e
modificano le sue differenti parti, un ULS system presenta
necessariamente differenti versioni dello stesso sottosistema,
generando quindi possibili inconsistenze sia nella fase di
progettazione, sia nella fase di implementazione che di messa in
esercizio.
• Separazione utenti-sistemi: definire i confini si un sistema ULS è
difficile. Gli utenti spesso sono un vero e proprio elemento del
sistema e contribuiscono al complessivo processo di business.
• Regolarità dei fallimenti: i fallimenti hardware e software sono la
normalità e non delle eccezioni[1].
Tali caratteristiche determinano l’inadeguatezza delle attuali metodologie di
sviluppo dei sistemi software e pongono le basi per la definizione di nuove
metodologie che tengano fortemente conto di taluni aspetti che di seguito
saranno analizzati.
L’interoperabilità tra sistemi informativi sviluppati in tempi diversi, con
linguaggi e tecniche differenti, ed operanti su piattaforme eterogenee è
diventata un problema centrale. L’interoperabilità riguarda vari aspetti: dalla
possibilità di scambiare dati tra i sistemi alla cooperazione applicativa, che
prevede l’integrazione delle funzionalità delle diverse tipologie di
applicazioni. In tale scenario, l’obiettivo comunemente riconosciuto è quello
di facilitare l’interazione tra sistemi differenti e non omogenei.
8

Considerando che progetti su grande scala richiedono tempi, oltre che costi
elevati, che si misurano in mesi e più di frequente in anni e considerando la
rapidità con cui evolvono, in tali lassi di tempo, le piattaforme hardware, i
sistemi operativi, il software di base, i linguaggi, assume grande importanza
la capacità di essere predisposti ai cambiamenti e di gestire, se non
addirittura anticipare, l’evoluzione delle tecnologie.
Data la natura indipendente di ogni sottosistema di un ULS system, ciascuno
di essi lavora cercando di massimizzare i risultati delle sua elaborazione
locale. Pertanto, controllare ed orchestrare le attività di ciascun sistema al
fine di realizzare un’armoniosa collaborazione che garantisca il
soddisfacimento degli obiettivi, sia locali, sia globali, è un esigenza dei
sistemi ULS.
Le attività di progettazione, sviluppo evolutivo e orchestrazione vanno poi
monitorate e valutate al fine di apportare le giuste modifiche correttive e
migliorative. Dunque, la definizione di appropriati indicatori, probabilmente
di tipo statistico, permetterebbe di produrre report sullo stato complessivo
delle attività, nonché una visione sintetica del sistema ULS nel suo
complesso. Infine, in letteratura si utilizzano espressioni come Enterprise
Architecture ed System of Systems, e pertanto un “sistema di sistemi” è una
“enterprise” piuttosto che una tradizionale struttura gerarchica, ossia si
passa da un sistema di comando e controllo rigidamente gerarchico ad
un’organizzazione dove il processo di decisione e responsabilizzazione è
fortemente decentralizzato. Uno dei principali obiettivi è di consentire il
rilascio di nuove funzionalità, o di fornire valore aggiunto al patrimonio dei
dati e delle applicazioni, in tempi rapidi, a costi contenuti ed in maniera
9

affidabile, attraverso l’opportuna interconnessione di sistemi eterogenei in
ambiente distribuito. Elemento centrale delle moderne tecnologie per
l’integrazione è la presenza di un infrastruttura software di interconnessione,
ormai comunemente indicata con il termine middleware, termine inglese
con il quale si vuole evidenziare la sua caratteristica di trovarsi sopra il
livello delle apparecchiature hardware e dei sistemi operativi, e di fornire
servizi di cooperazione applicativa o per trasferimento di dati tra le varie
tipologie di applicazioni.
Figura 1.1 - Middleware
In questa prospettiva, la realizzazione di moduli software è, ancor meno che
in passato, una fase critica in termini di risorse e competenze tecnologiche
richieste. Assume invece maggiore importanza la capacità di integrare ed
adattare sistemi esistenti e non originariamente pensati per interoperare [2].
10

1.3 – Air Traffic Management
1.3.1 – Contesto
Va riconosciuto che la politica dell’Unione Europea nel settore
dell’aviazione è una “success story”. Le mutate esigenze della nostra
società in termini di mezzi di trasporto sicuri a prezzi accessibili, l’aumento
della domanda di traffico in cielo, la crescente sensibilizzazione della
comunità verso le politiche ambientali, hanno posto l’aviazione nella
condizione di dover migliorare ulteriormente la qualità del servizio offerto.
In questo contesto, un’industria dei trasporti competitiva e sostenibile esige
un sistema di gestione del traffico aereo di efficienza elevata.
La gestione del traffico aereo ( ATM – Air Traffic Management nella
terminologia anglosassone ), costituisce, insieme agli aeroporti,
l’infrastruttura fondamentale della navigazione aerea. In base alle previsioni
e all’analisi dell’Unione Europea, l’ATM Europeo dovrà essere capace di
affrontare un incremento del flusso aereo, a partire da oggi fino al 2020, pari
a tre volte quello attuale. L’obsolescenza dei sistemi costituisce un vincolo
forte alla crescita del flusso aereo e rappresenta inevitabilmente, un supporto
inadeguato a tale sviluppo.
Pertanto, l’ATM Europeo necessita di aggiornare le tecnologie degli attuali
sistemi nonché di compiere un decisivo salto tecnologico per lo sviluppo di
un’infrastruttura a supporto dei sistemi di prossima generazione[3].
1.3.2 – Gestione di un volo
Chiunque voglia attraversare lo spazio aereo, si tratti di compagnie aeree o
di privati, deve sottoporre in anticipo all'attenzione di ENAV il proprio
11

piano di volo, che raccoglie tutte le informazioni essenziali (dati
identificativi del velivolo e del pilota, orario e data di decollo, aeroporto di
partenza e di destinazione, traiettoria etc….).
Una volta approvato, il volo è autorizzato a partire.
Figura 1.2 - Fasi di un Volo
Il pilota entra quindi nella fase del volo detta di Controllo di Aeroporto: è
in contatto con la Torre di Controllo (TWR) che lo autorizza a mettere in
moto il velivolo e a spostarsi dal parcheggio verso le piste di rullaggio.
Finita questa fase di movimenti al suolo, il pilota viene autorizzato dalla
Torre di Controllo al decollo solo quando sarà garantita la distanza di
sicurezza da tutti gli altri aeromobili. Una volta decollato, il velivolo,
sempre in contatto con la Torre di Controllo, passa attraverso la fase di
Controllo di Avvicinamento che ne garantisce un sicuro instradamento
verso la fase di rotta per l'inserimento nell'aerovia che gli è stata assegnata.
12

Una volta inserito nell'aerovia, l'aeromobile viene preso in consegna dal
Centro di Controllo d'Area (ACC) che ne gestirà il Controllo di Rotta. Al
velivolo viene assegnato un livello di volo e indicata la traiettoria da
seguire, in modo che rimanga sempre alla distanza di sicurezza (detta
"separazione") sia verticale che orizzontale, dagli altri velivoli. Una volta in
prossimità dell'aeroporto di destinazione, il velivolo viene inserito
nuovamente nella fase di Controllo di Avvicinamento, che stabilisce la
corretta sequenza degli aeromobili quando lasciano le aerovie, per guidarlo
nella discesa fino all'allineamento con la pista.
Quando il velivolo e' stabilizzato sul sentiero di atterraggio ed in vista
dell'aeroporto, la gestione viene affidata di nuovo alla Torre di Controllo
dell'aeroporto di destinazione, che guida l'aereo fino al parcheggio. Quando
gli aeromobili entrano o escono dallo spazio aereo italiano, i Controllori del
Traffico Aereo, e i sistemi informatici di cui questi si servono, dialogano
costantemente con gli enti omologhi stranieri dei paesi limitrofi inviando e
ricevendo notizie sui voli.
Pertanto, le fasi del Controllo del Traffico Aereo sono:
• Controllo di Aeroporto (TWR - Aerodrome Control Service) E'
gestito dalle Torri di Controllo e consiste nella gestione del traffico
aereo generato dagli aeromobili nella fase di movimentazione al
suolo degli aeromobili nell'area di parcheggio, sulle piste e nella fase
di decollo e atterraggio.
• Controllo di Avvicinamento (APP - Approach Control) Tale
servizio può essere reso direttamente dalle Torri di Controllo o
anche dai Centri di Controllo d'Area (ACC); consiste nella gestione
del traffico aereo nella fase del volo subito precedente l'atterraggio e
13

subito precedente l'ingresso nella fase di rotta (di norma entro un
raggio di 20 miglia dall'aerodromo).
• Controllo di rotta (ACC - Area Control Center) E' gestito dai Centri
di Controllo d'Area e consiste nella gestione del traffico aereo nella
fase della rotta. Ovviamente usufruiscono di questo servizio anche i
voli interessati al solo sorvolo dello spazio aereo nazionale, quindi
che originano e terminano fuori dall'Italia.
Per garantire ai velivoli di decollare, attraversare lo spazio aereo e atterrare
in sicurezza, i Controllori del Traffico Aereo, dalle Torri di Controllo e dai
Centri di Controllo d'Area curano la gestione di un volo nelle diverse fasi
secondo procedure complesse e utilizzando sistemi tecnologici
all'avanguardia[4].
1.3.3 – Limiti attuali della gestione del traffico aereo
Già oggi assistiamo a ritardi dei voli, inconvenienti che, alla luce di quanto
detto nel paragrafo precedente, creano perturbazioni a catena in tutto il
sistema del trasporto aereo in Europa mettendo in luce le strettissime
connessioni tra le dinamiche di tutti i voli in un lasso di tempo medio-lungo.
È chiaro che solo la gestione del traffico aereo può garantire, in qualsiasi
momento, la separazione sicura tra le traiettorie di aeromobili che
attraversano lo spazio a grande velocità. Il controllore aereo conosce le
strozzature e gli incroci pericolosi dello spazio aereo come pure le
procedure necessarie per diminuire i rischi inerenti ad una rete di
collegamenti così complessa. Il settore ATM rappresenta, proprio per
questo, un monopolio naturale.
14

Il trasporto aereo si è sviluppato impetuosamente intorno agli anni ’50 e ’60
in un ambiente controllato esclusivamente dagli Stati nazionali. A partire
dagli anni ’70 gli Stati hanno cominciato a trasferire funzioni non
governative agli operatori privati del settore, mantenendo però le strutture
normative della gestione del traffico aereo soggette ad accordi
intergovernativi. Con una dotazione finanziaria equivalente a quella dell'UE
il sistema americano di controllo del traffico aereo riesce a gestire un
volume di traffico doppio rispetto a quello europeo a partire da soli 20 centri
di controllo[5]. Invece la frammentazione del sistema europeo è il risultato
di una particolare situazione storica nella quale il controllo del traffico aereo
era inteso come attributo della sovranità e, di conseguenza, circoscritto ai
soli confini nazionali. Anche la ripartizione delle responsabilità fra gli Stati,
le singole autorità, le compagnie aeree e i prestatori di servizi di navigazione
aerea era molto frammentata e non è affatto chiara.[3].
La gestione del traffico aereo in Europa è quindi caratterizzata da un elevata
frammentazione che si traduce in notevoli conseguenze tra cui una di quelle
più importanti riguarda la mancanza di sincronia nell'adeguamento al
progresso tecnologico. Senza troppo sforzo, si comprende che nel sistema
continuano a sussistere inutili duplicazioni di sistemi non standardizzati che
svolgono funzioni simili ma che sono realizzati in maniera
tecnologicamente diversa, o ancora sistemi che svolgono funzioni diverse,
che magari devono cooperare strettamente, ma che non sono interoperabili,
ed ancora sistemi che devono continuamente comunicare e quindi la
necessità di stabilire un numero corposo di collegamenti end-to-end. Tutto
questo si traduce in notevoli costi supplementari per gli utenti dello spazio
aereo, in un allungamento inutile dei tempi di volo, in una più lenta
15

introduzione di nuove tecnologie e di nuove procedure ed in un limitato
ricorso a sistemi più efficienti. L’attuale organizzazione impedisce inoltre al
settore della gestione del traffico aereo di realizzare economie di scala e ciò
comporta inutili costi di gestione e manutenzione.
Dunque, nonostante il generale progresso tecnologico del settore
dell’aviazione, il controllo del traffico aereo continua ad essere, in sostanza,
un lavoro con caratteristiche artigianali. Mentre le cabine di pilotaggio si
sono automatizzate, i sistemi ATC non sono cambiati ed i metodi di lavoro
dei controllori di volo rimangono fondamentalmente gli stessi.
1.3.4 – Il futuro Sistema ATM Europeo: SESAR
Dall’analisi svolta nei precedenti paragrafi emerge che l’industria del
trasporto aereo deve prepararsi a far fronte alla crescita di traffico che si
prevede possa addirittura triplicare entro il 2020. La frammentazione attuale
del sistema ATM , le attuali infrastrutture, la lentezza e l’inefficienza di un
processo decisionale intergovernativo non possono rispondere a questo forte
aumento del traffico. Il previsto sviluppo del traffico impone, quindi, una
modernizzazione strutturale e tecnologica. Di qui nasce la necessità per la
Comunità Europea di intervenire con decisione con il lancio di studi e
progetti che intendono ridefinire lo scenario futuro dell’ATM.
In questo scenario si inserisce SESAR ( Single European Sky ATM
Research), un progetto fortemente voluto dalla Commissione Europea per la
realizzazione di un nuovo sistema di gestione del traffico aereo
interoperabile, che nel 2020 garantirà all’Europa di far fronte ai livelli di
traffico previsti in sicurezza ed economicità. L'intera comunità aeronautica
ha riconosciuto infatti in questo progetto le potenzialità politiche,
16

istituzionali ed operative per poter convogliare tutti gli investimenti del
settore ed ottenere i risultati attesi in campo operativo dall'implementazione
della normativa del “Cielo Unico Europeo”. É un progetto congiunto a cui
hanno aderito gli operatori più importanti del settore del trasporto aereo:
scopo delle attività sarà quello di realizzare un sistema ATM di nuova
generazione in grado di rispondere efficientemente all'evoluzione della
Gestione del Traffico Aereo prevista in Europa. Permetterà di uniformare il
livello degli impianti esistenti nei diversi paesi dell'Unione, e al tempo
stesso realizzerà una nuova infrastruttura aeronautica con il sostegno ed il
consenso di tutti gli attori della catena ATM. Il progetto SESAR
costituisce quindi la componente tecnologica del cielo unico europeo.
Grazie a SESAR la gestione del traffico non è più definita in funzione delle
frontiere ma delle esigenze effettive[4].
Per concludere, la realizzazione di SESAR richiede il completamento di
diverse fasi.
• una fase di definizione (2005-2007), che permette di realizzare il
piano di modernizzazione della gestione del traffico.
• una fase di sviluppo (2008-2013), che permetterà di sviluppare le
tecnologie di base che costituiranno le fondamenta della nuova
generazione di sistemi;
• una fase di spiegamento (2014-2020), in cui avverrà l'installazione
su grande scala dei nuovi sistemi e l'attuazione generalizzata delle
funzionalità connesse.
17

1.4 – SWIM - System Wide Information Management
1.4.1 – Overview
Fino ad oggi, i diversi sistemi per la gestione delle informazioni del traffico
aereo europeo sono stati sviluppati indipendentemente l’uno dall’altro con la
conseguenza che gli attuali organismi per l’ATM sono difficilmente
integrabili e presentano barriere anche organizzative ed istituzionali oltre
che strutturali da non consentire la disponibilità nel modo e nel momento
giusto delle informazioni pertinenti. L’ATM necessita del cambiamento
dell’attuale rete di sistemi distribuiti e indipendenti in una rete efficiente di
sistemi cooperanti ed integrati, capaci di accrescere l’efficienza e
l’operatività del traffico aereo.
In questo contesto si pone il progetto SWIM che intende, invece, definire
l’infrastruttura di un sistema che favorendo l’interoperabilità nel mondo
ATM costruisca mediante l’utilizzo di tecnologie moderne, affidabili e
sicure un ‘Global European System’ basato su un modello delle
informazioni condiviso. Tale infrastruttura dovrà prevedere la distribuzione
dei dati in modo rapido e sicuro, favorendo il cosiddetto processo di
‘Collaborative Decision Making’ il cui output sarà la decisione che
scaturisce da un accordo tra più attori-processi.
In particolare attraverso il sistema SWIM diventerà possibile:
• Elaborare dinamicamente i piani di volo;
• Utilizzare in modo flessibile e dinamico lo spazio aereo;
• Integrare l’Air Traffic Control nella gestione del flusso aereo;
18

Figura 1.3 - EATMS (visione generale)
Il sistema mostrato in figura 1.3 può essere definito come un sistema
composto a sua volta da altri sistemi ( System of Systems nel dominio
dell’ATM ) e richiede che lo scambio di messaggi non avvenga attraverso
connessioni punto-punto, ma attraverso la condivisione delle informazioni
in uno spazio globale dei dati. Al di sopra di questo buffer virtuale e
condiviso, vi saranno le applicazioni che permetteranno il Collaborative
Decision Making – CDM..
I sistemi che verranno interconnessi sono i seguenti:
• Sistemi ATC civili e militari;
• Sistemi utenti dello spazio aereo civili e militari;
• Aeroporti;
• Aeromobili.
• Etc…
19

Le informazioni che saranno condivise all’interno della rete SWIM sono le
seguenti :
• Dati di volo;
• Dati di sorveglianza;
• Dati aeronautici;
• Dati meteo;
• Etc…
1.4.2 – Definizione
SWIM è l’acronimo di System Wide Information Management e viene così
definito dall’International Civil Aviation Organisation, ICAO:
“ SWIM rappresenta un sistema ULS per la gestione dei dati e prevede di
definire un infrastruttura di rete che permetta l’integrazione di diversi
sistemi per l’ATM geograficamente dispersi su ampia scala. È previsto che
tale processo debba intendersi non solo come semplice integrazione di
sistemi ma come capacità di detti sistemi di condividere le informazioni loro
necessarie”[6].
Per tale scopo diventa quindi necessario migrare dall’attuale paradigma di
distribuzione dei dati basato su connessioni di tipo “punto-punto” verso un
modello di rete globale per la condivisione dei dati tra tutti i protagonisti
della gestione del traffico aereo basato su connessioni di tipo “molti-a-
molti”.
Anche il Dipartimento per la Difesa degli USA, in accordo con la visione di
ICAO, chiarisce che l’utilizzo di tecnologie d’avanguardia permetterà di
progettare sistemi, non più secondo paradigmi di tipo application-centric
ma di tipo data-centric, che permettendo agli utenti l’abilità di accedere a
20

dati e servizi mediante il web, realizza un ambiente interoperabile di
elaborazione e comunicazione dei dati.
Secondo SESAR in SWIM l’attenzione è sulle informazioni e sull’accesso
alle stesse piuttosto che su chi le produce. Nella rete ATM ogni partecipante
è produttore e consumatore di dati allo stesso tempo. Sapere chi avrà
bisogno di cosa, da chi e quando non è un aspetto rilevante. Secondo questa
visione diventa importante il disaccoppiamento tra produttori e consumatori
dei dati, rendendo così possibile il cambiamento in numero e tipologia di chi
consuma e di chi produce dati[6].
Per il raggiungimento di tale scopo, i partecipanti, nel contesto degli scenari
definiti da SWIM, devono condividere:
• Un modello di riferimento di dati e servizi;
• Una serie di patterns di collaborazione ( regole, ruoli e
responsabilità );
• Una classe di servizi di supporto all’interazione tra i sistemi;
• L’accesso alla rete fisica di SWIM.
In breve, SWIM deve fornire meccanismi per la gestione di Regole, Ruoli e
Responsabilità (3R’s) per la condivisione delle informazioni. Ciò determina
quali tipi di informazioni sono condivise da chi, con chi, dove, quando,
perché, come, quanto spesso, a che livello di qualità, etc…
1.4.3 – SWIM-SUIT
Il progetto SWIM-SUIT ( System Wide Information Management Supported
by Innovative Technologies ) ha lo scopo di effettuare uno studio di
fattibilità dello sviluppo di una piattaforma middleware in grado di gestire,
in ambito europeo, una rete globale per la condivisione dei dati fra tutti i
21

protagonisti della gestione del traffico aereo, come enti di assistenza al volo,
compagnie aeree, centri meteorologici e strutture aeroportuali. Il nuovo
sistema permetterà di superare le attuali barriere fra gli operatori del settore,
creando le necessarie infrastrutture per l’integrazione di tutte le
informazioni. Lo sviluppo di un prototipo è alla base della valutazione delle
tecnologie adottate. Per il raggiungimento di tale obiettivo, si separeranno le
parti applicative specifiche di ognuno dei diversi domini ATM
dall’infrastruttura del middleware, definendo a diversi livelli sia i servizi
generici sia l’accesso ai dati; per quest’ultimo aspetto ci sarà il
disaccoppiamento tra chi fornisce e tra chi richiede servizi e dati[6].
1.4.3.1 – Architettura stratificata
SWIM ATM Added-value Services
SWIM ATM Data Access Services
SWIM Technical Services
SWIM Network
Figura 1.4 - Architettura stratificata di SWIM
La figura sopra mostra una visione concettuale dell’architettura del
prototipo. Al livello più basso vi è l’infrastruttura di rete ( SWIM Network )
che SWIM impiegherà per le interconnessioni tra sistemi. Immediatamente
sopra il livello “rete”, vanno collocati i servizi core ( SWIM Technical
Services ) che saranno resi disponibili a tutti i sistemi connessi. Tali servizi
22

dovranno utilizzare il più possibile tecnologie standard. Lo strato SWIM
ATM Data Access è in pratica la virtualizzazione dello spazio globale dei
dati; esso permette l’accesso al modello standard dei dati mediante
opportuni servizi che sono definiti in ciascun dominio (accesso per i dati
meteo, accesso ai dati di volo…). Infine, al livello più alto c’è lo strato
SWIM ATM Added-value services che fornisce ulteriori servizi che sono
specifici del dominio e che favoriscono la cooperazione tra sistemi ATM per
il raggiungimento di una decisione comune tra i diversi stakeholders
coinvolti. In generale i livelli arancioni rappresentano l’infrastruttura SWIM
comune a tutti i domini ATM mentre al di sopra di essi vi sono i layers che
permettono l’implementazione delle funzionalità specifiche di un dominio.
L’infrastruttura potrà essere distribuita sui diversi sistemi ATM legacy che
compongono l’EATMS. Ciascun sistema ATM è tipicamente composto da
diversi sottosistemi che implementano le funzionalità specifiche del
dominio e da un sottosistema SWIM ( sottosistema SWIM / IOP
Management ) che contiene parte dell’infrastruttura SWIM, connette i
sistemi fornitori di servizi, traduce le strutture dati standard di SWIM nel
formato specifico del sistema legacy.
(Legacy) ATM System A (Legacy) ATM System B
SWIM /
IOP Mgt
SWIM /
IOP Mgt
SWIM Network
Figura 1.5 - connessione sistema ATM-SWIM
23

Tale visione dell’EATMS richiede ovviamente di chiarire il confine tra
l’infrastruttura del middleware ed i domini ATM.
1.4.3.2 – SWIM ATM Information Model
Come già accennato uno dei temi caldi di SWIM riguarda la gestione delle
informazioni e l’accessibilità alle stesse da parte dei vari stakeholders del
Sistema definiti precedentemente.
Tipicamente l’ambiente SWIM può essere visto come suddiviso in differenti
domini interconnessi logicamente tra di loro. Ciascun dominio è
caratterizzato dalle informazioni che lo riguardano. Tra i principali domini
ci sono:
• Aeronautical Data Domain che include dati relativi ad aerodromi,
eliporti, spazio aereo, suolo, eventuali ostacoli di ogni tipo, e velivoli
di ogni tipo.
• Surveillance Data Domain che include dati come la posizione di un
velivolo in un certo istante, informazioni storiche, velocità ed
identificativo del velivolo, dati relativi a sensori e radar ed
informazioni riguardo la loro posizione.
• Flight Data Domain è uno dei domini più importanti, in particolare
quello a cui siamo interessati. In esso sono contenuti dati relativi ai
piani di volo come la traiettoria, data e orario di partenza e arrivo,
aeroporto di partenza e di arrivo, identificativo e tipo del velivolo ed
altri ancora.
• Meteo Data Domain include dati che riguardano le condizioni
atmosferiche di zone delicate come quelle che nelle quali risiedono
24

gli aeroporti. Tali dati provengono da svariate sorgenti radar al
suolo, satelliti ma anche gli stessi velivoli.
Figura 1.6 - SESAR ATM Information Model
Dividere l’ intero dominio ATM in sotto domini ha il vantaggio di rendere
più gestibile in problema in termini di grandezza e complessità, permettendo
a requisiti quali performance e integrità di raggiungere i livelli richiesti. La
suddetta divisione in domini nasce proprio per la natura estesa e complessa
dell’Air Traffic Management, che ha causato nel corso degli anni la nascita
di sistemi di natura diversa in ciascuno dei domini ATM, che pur svolgendo
funzionalità diverse, necessitano di condividere parte dei dati dell’intero
dominio. In uno scenario così eterogeneo, ciascun dominio potrebbe essere
descritto da uno o più modelli che definiscono sia la struttura sia la
semantica dei dati. Alcuni progetti di ricerca stanno già cercando di definire
uno standard per la struttura dei dati di alcuni dei domini sopra elencati,
come ad esempio ICOG[7] per il Flight Data Domain. Tuttavia definire uno
standard per la struttura dei dati risolve solo parte dei problemi relativi
all’interoperabilità quali evitare formati diversi per dati dello stesso tipo,
modelli dei dati differenti per lo stesso dominio. Per favorire l’
interoperabilità tra i sistemi coinvolti nell’ ATM è necessario definire la
25

semantica dei dati ed evidenziarne i legami con le informazioni appartenenti
a domini diversi.
Per i problemi sopra elencati, per ogni dominio si rende necessario definire
sia la struttura delle informazioni sia le relazioni tra i dati; l’unione di questi
due aspetti permette di definire i concetti e le relazioni dell’ intero dominio
che diventano necessari per la definizione modellare degli scenari previsti
dall’ ATM. In pratica occorre definire dal punto di vista semantico l’ intero
dominio dell’ ATM. In questo contesto viene ad assumere un ruolo
rilevante la realizzazione di un più generale ATM Information Reference
Model che definisce la semantica delle informazioni che vengono scambiate
attraverso l’infrastruttura definita da SWIM-SUIT. Questo modello, che
possiamo porre ad un livello di astrazione superiore, sarà di riferimento per
tutti i modelli strutturali di più basso livello, come ad esempio quello
definito da ICOG per i dati di volo, a supporto dell’interoperabilità e della
condivisione di dati tra sistemi sia all’interno di uno stesso dominio sia tra
domini diversi.
Essendo un modello indipendente dalle varie piattaforme, è un elemento
chiave nella progettazione dei sistemi ATM in quanto è da esso che gli
specifici formati di scambio delle informazioni possono essere definiti.
1.4.3.3 – Caratteristiche Generali e Sfide Aperte
Dalla panoramica fatta sinora è chiaro che il sistema SWIM può essere
definito come un sistema di sistemi. Tipicamente, i sistemi di sistemi
mostrano caratteristiche di sistemi complessi come quelle già viste in un
paragrafo precedente, quali estensione e distribuzione geografica, continuità
del servizio a lungo termine, distribuzione dei dati, decentralizzazione ed
26

eterogeneità dei dati. Ognuno di questi aspetti introduce delle problematiche
che richiedono l’ausilio di nuovi approcci al fine di rispettare i requisiti
richiesti da un sistema complesso come SWIM. Di seguito verranno
enfatizzate, per ognuno di tali aspetti, le problematiche imposte dal dominio
ed alcuni dei requisiti che l’infrastruttura intende rispettare.
Estensione e Distribuzione Geografica
L’infrastruttura che SWIM intende definire, rappresenta un sistema software
complesso caratterizzato dall’interconnessione di un numero molto elevato
di sistemi ATM attraverso una rete di dimensioni geografiche senza forti
garanzie del servizio.
In uno scenario simile è evidente che a SWIM sono richiesti requisiti quali
Scalabilità e Fault-Tolerance.
Figura 1.7 - Estensione Geografica
27

Fault-Tolerance è la capacità di un sistema sotto stress di svolgere
ugualmente le proprie funzionalità anche in presenza di situazioni anomale
o guasti generati o dalla struttura interna o dell’ambiente esterno al sistema
stesso[6]. Nella fattispecie al sistema SWIM è richiesto che la consegna dei
dati e la funzionalità dei sistemi non deve essere compromessa da fault di
rete da cui l’adozione di politiche di Qualità del Servizio (QoS) nella
distribuzione dei dati.
La Scalabilità è una proprietà secondo cui le prestazioni di un sistema non
devono essere compromesse al crescere o al decrescere della quantità di
carico di lavoro[6]. In particolare al sistema SWIM è richiesto che le sue
prestazioni non devono essere compromesse dal numero crescente di entità
coinvolte nella comunicazione. In altri termini l’introduzione di nuovi attori
deve avere un impatto veramente limitato sul sistema; La Scalabilità può
essere ottenuta mediante disaccoppiamento tra le entità coinvolte riuscendo
quindi a limitare al minimo le interdipendenze tra moduli e/o componenti.
Continuità del Servizio a lungo termine
SWIM è concepito per essere in esercizio per un lungo periodo e necessita
pertanto dell’integrazione di nuove funzionalità senza che la continuità
funzionale del sistema complessivo sia compromessa. Il sistema nella sua
totalità deve essere quindi estendibile, evolutivo e flessibile.
L’ Estendibilità è la proprietà che permette ad un sistema di subire future
estensioni sia per quanto riguarda i servizi sia per quanto riguarda i dati col
minimo sforzo e senza interromperne il normale funzionamento[6].
28

Evolutività è la proprietà del sistema secondo cui la messa a punto dello
stesso avviene in maniera incrementale durante il suo funzionamento[6].
Flessibilità è l’abilità del sistema di adattarsi, mentre è in esercizio, ad
eventuali cambiamenti che occorrono nell’ambiente esterno, in particolare
in termini di gestione ed accesso a nuove informazioni e servizi[6].
Nel presente lavoro di tesi, tali proprietà saranno trattate soprattutto dal
punto di vista della gestione dei dati, mentre gli aspetti legati ai servizi
saranno tralasciati a sviluppi futuri.
Per garantire l’estendibilità, l’evolutività e la flessibilità dei dati diventa
necessario definire una struttura standard e una semantica delle
informazioni.
Distribuzione dei Dati
Come è già stato detto in precedenza, i vari stakeholders definiti nel
contesto del sistema SWIM, si scambieranno informazioni attraverso la
realizzazione di un Global Data Space, che ne permette il
disaccoppiamento. In particolare al sistema SWIM è richiesto di supportare
più pattern di comunicazione non solo tipo tradizionale ma anche evoluti.
Per meccanismi tradizionali si fa riferimento a semplici connessioni di tipo
punto-punto o multi-punto.
Per meccanismi più evoluti s’intende la possibilità di inviare o ricevere
informazioni esprimendo la tipologia di informazioni che si sta
considerando. Più in particolare è necessario poter disporre di più criteri di
classificazione delle informazioni; partendo dal più semplice che può essere
quello di etichettare le informazioni con delle labels significative per i dati
considerati, altri criteri possono prevedere la consegna degli stessi dati in
29

funzione del loro contenuto informativo, in funzione del particolare stato del
contesto all’interno del quale i dati vengono trasferiti o ancora i dati devono
essere trasferiti a nodi di un certo tipo, o dello stesso tipo del mittente o
ancora a nodi che si trovano nelle “vicinanze” o in una certa zona. In questo
scenario si può parlare di sottoscrizioni espressive facendo riferimento
sottoscrizioni di tipo “topic-based”, “content-based”, “concept-based”,
“context-based” e “proximity-based”.
Decentralizzazione
Figura 1.8 - Global Data Space
Il sistema SWIM per come è stato concepito, è un sistema fortemente
decentralizzato dal punto di vista della gestione, essendo presenti sistemi
legacy da interconnettere.
SWIM deve allora garantire un certo grado di interoperabilità sia funzionale
sia per quanto riguarda i dati da scambiare. Tale interoperabilità può essere
ottenuta modellando dal punto di vista semantico i dati da trattare, ed
impiegando dei traduttori tra middleware e sistemi legacy (wrapper).
30

Eterogeneità dei dati
Figura 1.9 - Decentralizzazione
I dati scambiati all’interno del sistema SWIM vengono generati da diverse
sorgenti che tra di loro sono molto probabilmente eterogenee. Di
conseguenza, tali dati possono essere soggetti a forti differenze nei modi di
rappresentazione ( ad esempio i tipi utilizzati o strutture di
rappresentazione), ma soprattutto possono appartenere a differenti domini
semantici ( Flight Data Plan, Meteo Data, Surveillance Data, etc….).
Possono sorgere allora problemi riguardo eventuali correlazioni tra i modelli
di ogni dominio, che più precisamente possono tradursi in eventuali
duplicazioni di una stessa informazione anche in più domini. Inoltre
informazioni riguardanti domini ATM diversi, probabilmente, non sono
completamente indipendenti nel senso che possono esistere vincoli
31

temporali di vario genere ed ancora sistemi operanti in certi domini, per
svolgere le loro funzioni di business, possono avere la necessità di disporre
e quindi di dover interpretare informazioni generate nel contesto di altri
domini. Non è da escludere poi l’esistenza di dipendenze anche tra dati
appartenenti allo stesso dominio, come possono essere ancora duplicazioni
di alcune informazioni o relazioni d’uso come la possibilità di ottenere dati
più complessi per composizione di dati elementari.
Sorgono dunque problemi di interoperabilità tra sistemi diversi che
gestiscono dati di uno stesso dominio, ma anche tra sistemi che gestiscono
dati appartenenti a domini differenti. Problemi riguardo la necessità di dover
garantire la consistenza dei dati intra-dominio ed inter-dominio ed ancora
problemi riguardo la necessità di tenere traccia di legami tra dati differenti
al fine di ottenere, una chiara ed esaustiva visione di come i dati sono
semanticamente organizzati.
Figura 1.10 - Eterogeneità dei dati
32

In presenza di questo tipo di correlazioni e dipendenze, c’è la necessità di
modellare ulteriormente i dati accompagnandoli con opportuni meta-dati.
Un Meta-Dato ( dal greco meta- "oltre, dopo" e dal latino datum
"informazione" - plurale: data), letteralmente "dato su un (altro) dato", è
l'informazione che descrive un insieme di dati allo scopo di definirne una
semantica più precisa e semplificarne la gestione. Un esempio tipico di
meta-dati è costituito dalla scheda del catalogo di una biblioteca, la quale
contiene informazioni circa il contenuto e la posizione di un libro, cioè dati
riguardanti i dati che si riferiscono al libro. Un altro contenuto tipico dei
meta-dati può essere la fonte o l'autore dell'insieme di dati descritto oppure
le modalità d'accesso, con le eventuali limitazioni. La funzione principale di
un sistema di meta-dati è quella di consentire il raggiungimento dei seguenti
obiettivi:
• Ricerca, che consiste nell’individuare l’esistenza di un dato;
• Localizzazione, ovvero rintracciare una particolare occorrenza del
dato;
• Selezione, realizzabile analizzando, valutando e filtrando una serie
di informazioni;
• Interoperabilità semantica, che consiste nel permettere la ricerca e
l’interpretazione di dati appartenenti ad ambiti diversi grazie a una
serie di equivalenze.
• Gestione delle informazioni, ossia gestire le raccolte di dati grazie
all’intermediazione di banche dati e cataloghi;
• Disponibilità, ovvero ottenere informazioni sull’effettiva
disponibilità del dato.
33

I sistemi di meta-dati hanno quindi come scopo ultimo, il migliorare la
visibilità e la comprensione delle informazioni che accompagnano. Proprio
per questo motivo, vengono strutturati in modo gerarchico e sono più
propriamente noti come schemi od ontologie[8].
Il lavoro di tesi presentato intende partire proprio da tale analisi, per poi nel
prosieguo del lavoro andare a proporre una soluzione per ognuno degli
aspetti individuati e definire un ATM Information Model. I vantaggi che
scaturiscono da una modellazione di questo genere, saranno evidenziati
attraverso alcuni degli scenari della gestione del traffico aereo.
34

2.1 – Introduzione
Capitolo 2
Gestione Semantica dei Dati: le Ontologie.
Le conoscenza, intesa come comprensione di fatti, verità o informazioni,
permette d’interpretare la realtà, agire razionalmente per modificarla e
prevederne l’evoluzione. Questo insieme di fattori, centrali ai fini della
risoluzione di problemi, ha fatto sì che sin dal 1965 l’Intelligenza Artificiale
si occupasse della “rappresentazione della conoscenza”, i cui metodi erano,
e sono tutt’ora, basati su un approccio simbolico, in cui le conoscenze
vengono rappresentate tramite strutture dati contenenti simboli (es. le
formule della logica). Particolare interesse rivestono i problemi quali
interoperabilità tra sistemi ed applicazioni distribuite in rete e la gestione
delle relative risorse che, come auspicato dall’inventore del Web, Tim
Berners Lee, saranno risolti nel momento in cui i dati non avranno soltanto
una struttura ( sintassi ) chiaramente definita ma anche un significato
(semantica ) condiviso dalla comunità che li utilizza; sarà proprio questo
passo in avanti che permetterà la loro elaborazione automatica laddove oggi
è richiesta l’interpretazione umana.
35

In questo contesto, un’ontologia non è altro che il tentativo di rappresentare
in modo rigoroso la conoscenza nell’ambito di un determinato dominio. La
rigorosità richiesta consiste in una descrizione formale (logica) della
conoscenza, necessaria per tendere ad una conoscenza sempre più machine-
processable e quindi permettere ad un ragionatore automatico ( reasoner )
di fare inferenza su di essa. Ontologie e ragionatori automatici sono ormai
riconosciuti dall’intera comunità scientifica come tecnologie cardine.
2.2 – Definizioni
L'Ontologia, "lo studio dell'essere in quanto essere a prescindere dalle
percezioni sensoriali" come diceva Aristotele, era una disciplina
strettamente filosofica, lontana dal mondo della tecnologia. Eppure, negli
ultimi anni, l'esplosione delle comunicazioni in rete ha favorito un
fenomeno che sarebbe stato difficile immaginare: gli aspetti ontologici
dell’informazione acquistano un valore strategico. Tali aspetti sono
intrinsecamente indipendenti dalle forme di codifica dell'informazione
stessa, che può quindi essere isolata, recuperata, organizzata, integrata in
base a ciò che più conta: il suo contenuto. La standardizzazione di tali
contenuti risulta oggi cruciale nella prospettiva delle aziende integrate e del
commercio elettronico ed è indispensabile per semplificare i processi di
comunicazione e di business.
Inizialmente le Ontologie sono state sviluppate nel settore dell'intelligenza
artificiale per facilitare la condivisione e il riuso della conoscenza; esse
costituiscono un tema di interesse in diverse comunità di ricerca: ingegneria
della conoscenza, elaborazione del linguaggio naturale, sistemi informativi
cooperativi, gestione delle conoscenze. In particolare, in Informatica, sta ad
36

indicare il tentativo di formulare uno schema concettuale esaustivo e
rigoroso nell’ambito di un determinato dominio d’interesse.
In letteratura un’ontologia è formalmente definita così: “An ontology is an
explicit and formal specification of sharable conceptualization” [ T.R.
Gruber,1993]. Una specifica formale (la descrizione è codificata in un
linguaggio precisamente definito, le cui proprietà sono ben note e comprese,
in genere questo si traduce in una descrizione basata su logica, così come
per i linguaggi adottati nell’Intelligenza Artificiale) ed esplicita ( i costrutti
usati nella specifica devono avere un significato esplicitamente condiviso e
gli utenti dell’ontologia, che condividono le informazioni d’interesse
dell’ontologia stessa, devono accordarsi su di essi ) di una
concettualizzazione ( rappresentazione astratta di un qualche aspetto del
mondo reale, d’interesse per gli utenti dell’ontologia ) condivisa (un
ontologia cattura conoscenze consensuali, non private, tra persone,
applicazioni, comunità ed organizzazioni ). Descrive la realtà
indipendentemente dal Vocabolario utilizzato e dall’occorrenza di
specifiche situazioni.
Figura 2.1 - Indipendenza dal Vocabolario
37

Si tratta generalmente di una struttura dati gerarchica contenente tutte le
entità rilevanti, le relazioni esistenti tra di esse, le regole, gli assiomi ed i
vincoli del dominio.
Figura 2.2 - Esempio Schema Ontologia
In particolare si compone di una lista finita di termini e di relazioni tra
questi termini. Un termine denota un concetto, una classe di oggetti, nel
dominio di interesse. Le possibili relazioni tra classi sono: Gerarchie,
Proprietà, Restrizioni di valori, Disgiunzioni, Relazioni logiche tra oggetti.
Un “ragionatore automatico” non è altro che un software in grado di
svolgere ragionamenti su delle basi di conoscenza adeguatamente
formalizzate (quali le ontologie), dove per ragionamenti (automatici)
s’intendono le capacità di elaborare una base di conoscenza secondo alcune
regole in modo da validarla ed analizzarla.
38

2.3 – Esigenze che spingono a modellare semanticamente un
dato dominio
Un’ontologia, descrivibile per mezzo di specifici linguaggi formali, è
innanzitutto uno schema logico, e come tale ha quindi lo scopo di
rappresentare ed organizzare una determinata realtà d’interesse
descrivendola in modo da agevolare una maggiore interpretabilità del
contenuto da parte delle persone, ma soprattutto delle macchine, delle
applicazioni e degli agenti intelligenti.
Le ontologie possono rivelarsi estremamente utili come modo di strutturare,
definire e standardizzare il significato dei termini dei meta-dati che vengono
utilizzati e collezionati in un certo ambiente. Possono essere d’aiuto nei
processi di business di comunità ristrette, ma diventano molto utili in
ambienti fortemente estesi. Usando le ontologie, le applicazioni del domani
potranno essere “intelligenti”, nel senso che esse potranno lavorare più
accuratamente al livello concettuale dell’uomo.
Le ontologie sono critiche per applicazioni che vogliono integrare
informazioni tra diversi contesti. Ciò che si vuole evitare è che uno stesso
termine possa essere usato con diversi significati in contesti diversi, o che
termini differenti possano avere un identico significato. Le ontologie, con la
loro semantica, garantiscono l’interoperabilità tra schemi di
rappresentazione sviluppati autonomamente da agenti diversi e sono dunque
l’ideale per progetti di grandi dimensioni e che coinvolgono numerosi
gruppi di lavoro.
Queste descrizioni strutturate o “modelli dei fatti noti” ( known facts
models) sono più efficaci quando le separazioni semantiche, che per le
menti degli uomini sono naturali, sono cruciali nell’ambito dell’applicazione
39

da realizzare. Ciò include la capacità di riuscire a comprendere ciò che è
“nascosto” in un estratto di un certo dominio.
In generale, le ontologie possono essere utili in tutte le fasi del ciclo di
sviluppo del software partendo dall’analisi dei requisiti, passando per la
progettazione e l’implementazione, fino a giungere a run-time[9]. Un
ontologia può essere usata per realizzare la specifica dei requisiti in
alternativa all’uso del linguaggio naturale. Ciò permette di ottenere un
documento chiaro e formale adatto anche alla raccolta dei requisiti secondo
un approccio incrementale. Un ontologia può essere utile per descrivere
semanticamente un certo componente software rappresentando in maniera
formale quelle che sono le sue funzionalità. Un ontologia può essere
utilizzata nella fase di passaggio dal modello progettuale
all’implementazione. In particolare può essere utile a supporto del
linguaggio di modellazione UML al fine di risolvere le ambiguità che
possono presentarsi, e permettendo validazione e controllo di consistenza
del modello considerato. Un ontologia può essere utilizzata per realizzare un
modello ad oggetti del dominio al fine di ridurre la complessità del dominio
stesso. In tal senso l’accesso all’ontologia, a livello di codice, può essere
realizzato mediante la generazione di API, per esempio incapsulando
concetti attivi dell’ontologia in classi del particolare linguaggio utilizzato.
Ed ancora un ontologia può essere utilizzata per la realizzazione di un
Semantic Middleware, cioè per conferire al middleware una certa
conoscenza del dominio aumentandone quindi le funzionalità, l’efficienza e
la qualità del servizio. Infine si può pensare di utilizzare ontologie anche per
politiche di testing, manutenzione del software ed ancora nell’ambito dei
web Services,
40

2.4 – Vantaggi nell’uso di Ontologie
Modellare e definire un’ontologia costituisce un lavoro fortemente tedioso e
costoso. Pertanto, è importante dimostrare i vantaggi che possono essere
ottenuti dall’utilizzo di ontologie.
Un primo vantaggio è la “Condivisione della conoscenza”. Quando sistemi
software eterogenei e persone devono collaborare per raggiungere un
obiettivo sufficientemente complesso, questi hanno necessità di condividere
una conoscenza comune dei dati da trattare. Un modello ontologico
condiviso tra i vari partecipanti, permette allora una conoscenza chiara e
condivisa della realtà di interesse. In questo scenario, le ontologie sono
particolarmente adatte a funzionalità di Composizione ed Integrazione
automatica dei dati. Più in particolare, data la loro grande flessibilità, i
modelli ontologici possono supportare tutte le strutture dati attualmente
usate. Questa proprietà permette ai sistemi di integrare dati
“orizzontalmente” e quindi di realizzare applicazioni più potenti.
Estensibilità e Flessibilità. Ogni ontologia racchiude le informazioni
relative ad un certo dominio in maniera autonoma e coerente con la realtà,
almeno fino a quando il dominio originale rimane immutato. Essendo, in un
ontologia, ogni concetto attivo nella realtà un nodo o una classe della
gerarchia, ciò significa che un eventuale nuovo concetto può aggiungersi
molto facilmente come specializzazione di un concetto già presente.
Riuso. Quando un sistema software è interessato ad un nuovo dominio, un
modello per tale dominio risulta necessario. È inefficiente e soggetto a errori
sviluppare sempre il modello ex-novo. È ovviamente maggiormente
conveniente sviluppare questi modelli riutilizzando le più piccole
componenti già ben definite. Un ontologia può riutilizzare i concetti e le
41

definizioni del caso da ontologie pre-esistenti. I progettisti possono
sviluppare così le proprie ontologie approfittando di quelle predefinite,
opportunamente catalogate in un biblioteca, senza dovere sviluppare
manualmente il modello di fondo. La possibilità di riutilizzare questi
modelli riduce il costo di sviluppo ed aumenta la qualità dei modelli
risultanti.
La struttura semantica realizzata dalle ontologie si differenzia dalla
superficiale composizione e disposizione delle informazioni ( i dati ) che i
database relazionali permettono. Con i database, virtualmente, tutto il
contenuto semantico deve essere “catturato” nella logica della applicazione.
Le ontologie, invece, sono spesso in grado di fornire una specifica oggettiva
delle informazioni del dominio, ponendosi come un modello comune di
rappresentazione dei concetti e delle relazioni caratterizzanti il modo in cui
la conoscenza è espressa in quello specifico dominio. Questa specifica può
essere il primo passo nella costruzione di sistemi di informazione
semantically-aware ( forniti di semantica ) per supportare attività personali,
governative e d’impresa. Ed ancora, un cambiamento all’interno del
dominio può condurre alla necessità di aggiungere o eliminare alcuni
concetti. Mentre in un database relazionale questa cosa si traduce magari
nella rigenerazione delle varie tabelle e relazioni, la stessa cosa in un
modello ontologico si realizza banalmente aggiungendo o rimuovendo classi
o specializzandone di già esistenti senza grande impatto ne sul modello ne
sulle applicazioni che fanno uso di quel modello.
42

2.5 – Tipi di ontologie
Esistono vari modi di classificare le ontologie e vari tipi di ontologie.
Le ontologie possono variare non solo nel contenuto, ma anche nella loro
struttura ed implementazione.
Linguaggi
Seguendo le indicazioni di Uschold (1996) possiamo individuare quattro tipi
di ontologie in base al linguaggio con cui sono espresse:
• altamente informali se scritte nel linguaggio naturale;
• semi-informali se espresse in una forma strutturata e ristretta del
linguaggio naturale, in modo da aumentarne la chiarezza e ridurne
l’ambiguità;
• semi-formali se sono definite in un linguaggio artificiale e
formalmente definito, quale Ontolingua;
• altamente formali se sono espresse in un linguaggio con una
semantica formale, teoremi e verifiche di proprietà quali la
completezza.
Scopo concettuale
Le ontologie differiscono anche rispetto allo scopo e all’ambito del loro
contenuto.
• Top-level Ontologies, includono un vocabolario relativo a cose,
eventi, tempo, spazio, causalità, comportamento, funzioni. Sono
dette anche Meta-ontologie perchè possono essere riusate da una
parte all’altra nei domini. Esse descrivono concetti molto generali
quali spazio, tempo, materia, oggetto, evento, azione, …. che sono
43

indipendenti da un particolare problema o dominio (un esempio è
Cyc ).
• Ontologie di dominio, che possono essere riusate in un dato
dominio. Forniscono dei vocabolari sui concetti presenti in un
dominio, delle relazioni presenti nel dominio e sulle teorie e principi
che governano il dominio.
• Ontologie di scopo ( task level ontology ) che rappresentano la
Istanzazione
struttura dei processi, descrivendo i concetti di base e le relazioni
esistenti tra essi sulla base delle informazioni sul dominio.
Tutte le ontologie hanno una componente che storicamente è stata chiamata
la componente terminologica ( the terminologic component ). Questa
componente è praticamente analoga a uno schema per un database
relazionale o un documento XML. Essa definisce i termini e la struttura
dell’ontologia dell’area di interesse. La seconda componente, quella
asserzionale, popola l’ontologia con delle istanze che manifestano la
definizione terminologica. La linea di separazione tra trattare un’entità come
un concetto e trattarlo come un’istanza è solitamente una decisione specifica
dell’ontologia.
2.6 – Costruzione di un’ontologia
I passi principali per costruire un’ontologia sono semplici e lineari. Esistono
varie metodologie per guidare l’approccio alle ontologie e sono disponibili
numerosi tool che supportano il processo di costruzione di un’ontologia. Il
problema è che queste procedure non sono converse in stili o protocolli di
44

sviluppo standard, e i tool non hanno ancora raggiunto in questo campo il
livello di maturità che invece essi dimostrano in altre applicazioni software.
Un’ontologia è tipicamente costruita seguendo più o meno i seguenti passi:
Conoscenza del dominio
Acquisire il maggior numero di informazioni possibili sul dominio di
interesse, raccogliendo i termini usati per descriverne le entità, in
collaborazione con gli esperti del dominio. Queste definizioni devono poi
essere collezionate per poter essere poi espresse nel linguaggio formale
scelto per la definizione dell’ontologia. Le domande da porsi sono le
seguenti: 1) quale realtà dovrà essere rappresentata dall’ontologia? 2) a
quale scopo? 3) Quali domande dovranno trovare risposta nell’ontologia che
si realizzerà? Risulta evidente che non tutte le risposte sono note a priori.
Organizzazione dell’ontologia
La prima questione da affrontare è quella dell'individuazione della struttura
del dominio che si sta analizzando andando ad individuare gli oggetti che lo
costituiscono. Una volta individuati i concetti-chiave, si devono individuare
tutte le caratteristiche e le proprietà che sono rilevanti per descriverli: ad
esempio, i dati anagrafici per le persone o i dettagli di fabbricazione per un
prodotto in vendita. A seconda poi del linguaggio che si utilizzerà e delle
scelte del progettista, in seguito, questi attributi saranno trasformati in
proprietà o relazioni.. Questa operazione semplifica l’identificazione dei
principali concetti del dominio e delle loro proprietà, identificando le
relazioni tra i concetti, creando concetti astratti, identificando quali di questi
hanno delle istanze etc….È importante che la tassonomia rispecchi i legami
45

eali e che metta in luce gli aspetti di classificazione che si riscontrano nella
realtà.
Le domande da porsi in questa fase sono: 1) quali sono i concetti
importanti? 2) quali sono le proprietà di questi concetti e tra questi
concetti? Si procede poi popolando i tre glossari. Il primo flat glossary, che
consiste nel documentare ciascun concetto con un termine che lo individua e
con una definizione in linguaggio naturale ( e fornire esempi dove
appropriato) in cui i nomi diventano oggetti o attori, e i verbi si trasformano
in relazioni o processi. Il secondo, structured glossary, che consiste nella
decomposizione e/o specializzazione dei termini al fine di ottenere un
tassonomia dei concetti e nell’individuazione degli attributi di un concetto.
Il terzo ed ultimo identifica tutte le relazioni concettuali fra gli oggetti.
Poiché il dominio può non essere l'unico di quel tipo, rappresentato
mediante un'ontologia, è possibile che ci siano ontologie pre-esistenti che
definiscano, tutti o in parte, i concetti appena trovati. L'individuazione di
queste ontologie è molto importante: in primo luogo, i concetti già definiti
possono essere riutilizzati, così come le proprietà e le relazioni, in modo che
non siano specificati più volte; i concetti nuovi, invece, sono dichiarati e
memorizzati nella nuova ontologia, che diventa un'estensione di quella
precedente, così da avere una gerarchia, e i nuovi elementi siano disponibili
per essere a loro volta estesi, per raggiungere nuovi scopi.
Popolamento dell’ontologia
Aggiungere concetti, relazioni, ed entità fino a raggiungere il livello di
dettaglio necessario a soddisfare gli obiettivi dell’ontologia. Per individuare
nuovi concetti è possibile adottare tre tipi di approcci: 1) top-down, che
46

prevede l’identificazione dei concetti generali e attraverso un raffinamento
successivo si procede verso i concetti particolari ( per esempio da persona a
padre ), 2) bottom-up, che procede per livelli di astrazione, partendo dalle
entità particolari del dominio per astrarre i concetti generali che racchiudono
o fanno uso di quelli particolari (per esempio da padre a persona) e
3) middle-out ( o combinato ) che prevede di individuare prima i concetti
salienti per poi generalizzarli e specializzarli; i concetti “nel mezzo”
tendono ad essere i più descrittivi del dominio. I concetti da soli non
forniscono informazioni sufficienti; è importante definire anche le relazioni
tra gli oggetti del dominio procedendo analogamente a quanto detto prima.
Inoltre è consigliabile imporre dei vincoli sulle relazioni, quali la cardinalità
( ad esempio un computer ha [1,n] processori ) sul dominio e sul codominio
della relazione, sul tipo di valore ( un indirizzo ha un CAP il cui codominio
è di tipo stringa , una bottiglia ha un’etichetta con un codominio di tipo
istanza , un’idea coinvolge concetti con un codominio di tipo concetto).
Validazione dell’artefatto realizzato
Risolvere inconsistenze sintattiche, logiche e semantiche tra gli elementi
dell’ontologia. I controlli di consistenza possono anche favorire una
classificazione automatica che definisce nuovi concetti sulla base delle
proprietà delle entità e delle relazioni tra le classi.
Consegna
Al termine dello sviluppo di un’ontologia, così come per qualunque altro
sviluppo software, è necessaria una verifica da parte degli esperti del
47

dominio e la seguente consegna del prodotto, assieme a tutti i documenti
relativi.
Ricapitolando, la modellazione di ontologie procede per classi. Il
meccanismo dell’ereditarietà consente di definire un’unica volta gli attributi
che le classi ad uno stesso livello ereditano da una classe padre. La
possibilità di definire come valore di un attributo un’altra classe consente di
stabilire qualsiasi tipo di relazione tra classi. Non sempre però risulta
immediato capire cosa dobbiamo definire come attributo, cosa come classe,
cosa come attributo che richiama una classe. Possiamo definire alcune
regole generali che possono aiutare ad ottenere una buona modellazione.
Può essere buona norma non dare alle classi nomi al volte al plurale, a volte
al singolare. La classe rappresenta una categoria, uno schema. Spesso si può
essere portati ad assegnare nomi al plurale alle classi pensando ad esse
come a dei contenitori di individui, ma questa è una cattiva interpretazione
della funzione della classe nell’ontologia. Un’altra cosa da tener presente è
il fatto che l’albero dell’ontologia deve essere bilanciato nella granularità. In
pratica potrebbe accadere che ci si verrebbe a trovare con concetti collegati
fra loro, ma uno su un ramo molto più profondo dell’altro. Questo indica un
“buco” nella definizione dei concetti e suggerisce che si debba colmare
questo gap semantico inserendo nuovi concetti sul ramo. Un ragionamento
analogo si può fare nel caso in cui ci si trovasse con una classe con un
numero molto alto di figli. Questa situazione, se non è chiaramente
giustificata, è indice di un deficit di definizione. Quello che bisogna fare è
quindi ricercare proprietà comuni alle varie classi figlie in modo da
raggrupparle con l’aggiunta di nuove classi. All’opposto, è una scelta non
48

soddisfacente modellare una classe con un unico figlio. Suddividere una
classe significa stabilire che alcune proprietà e caratteristiche devono
riferirsi ad oggetti diversi. Dunque suddividere con un’unica classe pare una
scelta ingiustificata[10].
Una buona ontologia deve possedere quindi le seguenti caratteristiche:
• Prevede tutte le distinzioni chiave;
• Non fare assunzioni implicite;
• Essere chiara e concisa: ciascun concetto è rilevante e non ci sono
duplicati;
• Essere coerente: permettere la presenza di tutte e sole le inferenze
che sono consistenti con le definizioni dei concetti;
• Essere frutto di scelte progettuali motivate;
• Essere facilmente modificabile;
• Essere riusabile.
La modellazione è un processo incrementale ed iterativo. Inoltre non c’è un
solo modo corretto di modellare un dominio, ma la soluzione dipende
dall’applicazione e dalle estensioni previste.
Importanti risultano anche le convenzioni di nomenclatura ( naming
conventions ), cioè l’operazione di definire una convenzione per concetti,
istanze e relazioni a cui aderire. Alcune semplici regole guidano questo
processo. Bisogna evitare sovrapposizioni, cioè non assegnare uno stesso
nome per un concetto e per una relazione, aggiungere delimitatori, utilizzare
prefissi e suffissi per le relazioni ( haproduttore, produttoredi ), distinguere
gli oggetti dai processi (prenotazione, fatturazione vs. prenotare, fatturare),
49

non usare abbreviazioni (Cod. Avv. Post. per Codice Avviamento Postale,
Doc. per Documento ecc.).
Risulta allora chiaro che è soprattutto l’esperienza che aiuta nel processo di
costruzione di un’ontologia, ma è ugualmente evidente che documentare
ogni passo dello sviluppo, annotare i problemi riscontrati e le eventuali
soluzioni, può aiutare gli utilizzatori e gli stessi progettisti in vista di
successivi cambiamenti.
Il lavoro della modellazione non è insomma facile. Può essere utile farsi
aiutare da un tool che viene in soccorso allo sviluppatore sostanzialmente in
due modi: 1) fornisce una visualizzazione grafica dell’ontologia, e quindi
avere una visione d’insieme delle relazioni fra le classi e 2) evita di scrivere
il codice a mano, riducendo gli errori involontari.
2.7 – Web Semantico come esempio di impiego di ontologie
2.7.1 – Contesto
Nel 1989, anno in cui Tim Berners-Lee inventò il World Wide Web, inizia
una nuova era tecnologica, economica e sociale. Le università cominciano a
condividere un sempre maggior numero di informazioni, favorendo lo
sviluppo della ricerca, le aziende trovano una “vetrina”, un biglietto da
visita che gli consente di farsi conoscere meglio nel mondo, nascono nuove
società di servizi, l’e-commerce, l’e-government, le aste on-line, i blog. Le
informazioni diventano un bene sempre più prezioso e numeroso, aumenta
la necessità di condividerle e soprattutto di catalogarle. I servizi stessi sono
sempre più sofisticati: spesso un semplice click di mouse racchiude una
transazione molto complessa tra diversi agenti software, basti pensare al
trading on-line o ai servizi bancari e finanziari. Ebbene, tutta questa serie di
50

cambiamenti è avvenuta nell’arco di pochi anni, probabilmente non finirà
mai, ma Berners-Lee, neanche dieci anni dopo la nascita del WWW, ha
ritenuto che questo strumento potesse essere inadeguato per gli sviluppi che
ha avuto. In particolare, egli propose di rendere i documenti presenti nel
Web, fino ad allora ad uso e consumo degli esseri umani, interpretabili
anche dai computer stessi ( machine-processable )[11].
Ancora oggi lo scenario del World Wide Web è quello di un enorme insieme
di testi collegati in qualche modo tra loro. I testi sono creati ad uso e
consumo dei soli utenti umani, gli unici allo stato attuale in grado di
comprendere i contenuti delle pagine che stanno visitando. Un caratteristica
essenziale del WWW è che "qualunque cosa può essere collegata a
qualunque altra cosa da chiunque" grazie ai potenti link ipertestuali.
Gli utenti umani si orientano nel Web grazie alla loro esperienza di
navigazione e alla capacità di evocazione che possono avere parole o
espressioni chiave. L'esperienza è un aspetto molto importante di cui tutti ci
serviamo: impariamo che determinati contenuti si possono reperire sotto
determinati portali, che l'aspetto di un sito può dirci qualche cosa sul genere
( formale o informale ) delle informazioni. Essa si costruisce nel tempo ma
non è molto legata ad aspetti tecnici, al codice e alle applicazioni che
costituiscono un sito. L'altro aspetto, quello delle parole chiave, è più legato
al codice. Queste caratteristiche non appartengono invece a nessuna
applicazione, che in definitiva non è in grado ( tranne qualche eccezione
limitata e molto complessa, quindi non significativa ) di interpretare il
contenuto delle pagine, che quindi restano per una macchina una sequenza
di caratteri..
51

Un ulteriore problema del Web odierno è l’integrazione delle informazioni.
Spesso l’informazione desiderata non proviene da un singolo sito, ma è
ottenibile da diverse fonti. Ad esempio, se si è interessati alla prenotazione
di un hotel in una certa città, sarebbe auspicabile sapere, con una sola
ricerca, i prezzi e le disponibilità di tutti gli hotel di quella città a
prescindere dall’esistenza o meno di uno o più siti sito che offrano un
sistema di prenotazione comune.
Infine, il Web tradizionale non permette di risolvere problemi complessi
attraverso la cooperazione di differenti applicazioni ed utenti umani. Sono
pochi, infatti, i siti Web progettati per fornire servizi ad altri servizi, la
maggior parte gioca ancora un ruolo di contenitore di informazioni che
possono essere estratte a richiesta. Il Web Semantico rappresenta una
soluzione alle limitazioni imposte dal Web odierno. Il progetto è basato su
un piano molto preciso: ridefinire e ristrutturare le risorse sul Web in modo
che il loro significato sia accessibile non solo a utenti umani, ma anche, e
soprattutto, ad applicazioni software. In questo modo, le macchine potranno
accedere ad un insieme strutturato di informazioni e ad un insieme di regole
da utilizzare per il ragionamento automatico, e quindi potranno manipolare,
integrare e rendere disponibili tali risorse per applicazioni software oltre che
per gli utenti. La definizione data proprio da Tim Berners-Lee è "Il Web
Semantico è un'estensione del Web corrente in cui le informazioni hanno un
ben preciso significato e in cui computer e utenti lavorano in
cooperazione"[12].
Le possibilità offerte dal Web Semantico sono tante e tali che non si sono
ancora approfondite le sue potenzialità. Per questo, più che di tecnologia, si
parla di visione del Web Semantico.
52

Il Web Semantico poggia le proprie basi su tre strumenti:
• agenti software intelligenti: programmi che sappiano interpretare
correttamente le informazioni circa la semantica delle risorse;
• annotazioni semantiche: dati che descrivono le risorse facendo uso di
linguaggi di rappresentazione della conoscenza;
• ontologie: schemi concettuali esaustivi e univocamente interpretabili
che definiscono rigorosamente un dato dominio.
Gli agenti software del Web Semantico hanno il compito di assistere in
maniera intelligente l’essere umano nella fase di ricerca, interpretando
correttamente la semantica dei documenti trovati, visualizzando solo quelli
desiderati e scambiandosi i risultati con altri programmi. La conoscenza
dovrebbe rendere gli agenti software capaci di ragionare in modo complesso
ed in piena autonomia sulle informazioni cui hanno accesso. Tali programmi
devono almeno essere in grado di riconoscere e rappresentare gli obiettivi di
un certo utente, di mettere in atto una sequenza di azioni che possa
soddisfare tali obiettivi ed eventualmente di cooperare con altri agenti per
ottenere tale risultato.
2.7.2 – Architettura del Web Semantico
Scrivere del codice in grado di compiere operazioni semantiche dipende
dallo schema utilizzato per archiviare le informazioni. L'idea del Web
Semantico nasce estendendo l'idea di utilizzare schemi per descrivere
domini di informazione. I meta-dati ( sono le informazioni comprensibili da
una macchina e relativi ad una risorsa Web o qualche altra cosa, che
possono essere estratti da una risorsa o possono essere trasferiti con il
documento ) devono mappare i dati rispetto a classi, o concetti, di questo
53

schema di dominio. In questo modo si hanno strutture in grado di descrivere
e automatizzare i collegamenti esistenti fra i dati. Il Web Semantico è, come
l'XML, un ambiente dichiarativo, in cui si specifica il significato dei dati, e
non il modo in cui si intende utilizzarli. La semantica dei dati consiste nel
dare alla macchina delle informazioni utili in modo che essa possa utilizzare
i dati nel modo corretto, convertendoli eventualmente.
Riassumendo, il Web Semantico si compone di tre livelli fondamentali:
• i dati
• i meta-dati riportano questi dati ai concetti di uno schema
• nello schema si esprimono le relazioni fra concetti, che diventano
classi di dati
I linguaggi di rappresentazione della conoscenza del Web Semantico
condividono lo stesso data model - come si vedrà in seguito un grafo
orientato ed etichettato e si differenziano per il livello crescente di
espressività semantica che possono fornire. La sintassi di ciascun linguaggio
è definita in XML, poiché è facilmente estendibile ed altamente
interoperabile. Grazie all’uso di namespace e di URI, è possibile in maniera
efficace identificare le risorse ed i vocabolari che descrivono i linguaggi
presenti all’interno dei documenti descritti.
L’architettura è stratificata, ed ogni linguaggio di un livello superiore
estende i linguaggi sottostanti. All’aumentare di livello aumenta il potere
espressivo e di conseguenza la complessità e la decidibilità stessa del
reasoning. Utilizzeremo il termine KB ( che sta per knowledge base ) per
indicare una base di conoscenza, che può essere, ad esempio, un’ontologia
OWL oppure un documento RDF.
54

Figura 2.3 - Architettura del Web Semantico
Il Web Semantico ha quindi una architettura a livelli, che però non è stata
ancora sviluppata completamente. Ciò avverrà nei prossimi anni.
Vediamo ora il diagramma più in dettaglio:
• il Web Semantico si basa sullo standard [13] URI (Uniform Resource
Identifiers), per la definizione univoca di indirizzi Internet;
• al livello superiore si trova XML (eXtensible Markup Language),
che gioca un ruolo di base con i namespace e gli XML Schema. Con
XML è possibile modellare secondo le proprie esigenze, e senza
troppi vincoli, la realtà che si considera: per questo è un linguaggio
che porta con sé alcune informazioni sulla semantica degli oggetti.
Questa libertà lo rende poco adatto, però, a definire completamente
55

la struttura e l'interscambio di informazioni tra diverse realtà, quindi
è stata favorita la creazione di un nuovo linguaggio;
• RDF (Resource Description Framework) e RDF Schema, che
costituiscono il linguaggio per descrivere le risorse e i loro tipi.
Derivano da XML;
• al livello superiore si pone il livello ontologico. Una ontologia
permette di descrivere le relazioni tra i tipi di elementi (per es.
"questa è una proprietà transitiva") senza però fornire informazioni
su come utilizzare queste relazioni dal punto di vista
computazionale;
• la firma digitale è di significativa importanza in diversi strati nel
modello astratto del Web Semantico;
• l livello logico è il livello immediatamente superiore. A questo
livello le asserzioni esistenti sul Web possono essere utilizzate per
derivare nuova conoscenza.
2.8 – Linguaggi per la definizione di ontologie
2.8.1 – URI : Uniform Resource Identifiers
Dall’esempio fatto sul Web Semantico, si evince che una aspetto dal quale
non si può prescindere è la necessità di identificare una generica risorsa
altrimenti non potremo riferirci ad essa. Una risorsa può essere detta un
“documento”, per evidenziarne la leggibilità per gli esseri umani ( human-
understandable ), oppure può essere detta “oggetto” per evidenziare il fatto
che è comprensibile dalle macchine ( machine-understandable ). Ad
esempio sono risorse gli autori, i libri, gli editori, le persone, gli hotel, le
56

stanze, un indirizzo Web, un’immagine, un file, un servizio, un indirizzo di
posta elettronica, etc…
Ogni risorsa ha un URI che può essere una stringa o qualsiasi altro tipo di
identificatore. Gli URI rendono disponibili le risorse secondo una varietà di
protocolli quali HTTP, FTP, etc... Un URI può essere classificato come
URL ( Uniform Resource Locator ) o come URN ( Uniform Resource
Name). Un URL è un URI che, oltre a identificare una risorsa, fornisce
mezzi per agire su di essa o per ottenere una sua rappresentazione
descrivendo il suo meccanismo di accesso primario o la sua ubicazione o
location in una rete. Per esempio, l'URL
http://www.sesm.it/alberto
è un URI che identifica una risorsa e lascia intendere che una
rappresentazione di tale risorsa è ottenibile via HTTP da un host di rete
chiamato www.sesm.it/alberto. Un URN è ancora un URI che identifica una
risorsa mediante un nome in un particolare dominio di nomi ( namespace ).
Un URN può essere usato per parlare di una risorsa senza lasciar intendere
la sua ubicazione o come ottenerne una rappresentazione.
È certamente da notare il fatto che il meccanismo di creazione degli URI è
decentralizzato nel senso che non è possibile l’esistenza di nessuna persona
od organizzazione che sia in grado di controllare chi li produce o cosa ne fa.
Questa caratteristica rende gli URI molto potenti poiché chiunque può
crearne, tuttavia ha una limitazione nel fatto che inevitabilmente ci saranno
URI differenti che puntano ad una stessa risorsa ed allo stesso tempo non
c’è nemmeno modo per capire se effettivamente due URI puntano alla stessa
risorsa.
57

In conclusione un URI non fa niente di più che fornire un identificatore per
una certa risorsa, e quindi usando gli URI si possono:
• creare dati e meta-dati su una risorsa;
• annotare una stessa risorsa con altri termini in altre differenti risorse;
• aggiungere semantica alle risorse;
• collegare dati ad altri dati.
2.8.2 – XML : Extensible Markup Language
XML ( Extensible Markup Language ) è un meta-linguaggio, cioè un
linguaggio per la definizione di altri linguaggi di markup. L’obiettivo di
XML è quello di determinare specifiche per consentire la creazione di
documenti la cui struttura possa essere interpretata e gestita da un
calcolatore via Web. Un documento XML è un insieme correttamente
annidato di tag aperti e chiusi, che costituiscono un elemento, il quale può
contenere un numero arbitrario di coppie attributo-valore che lo
caratterizzano. La sua struttura logica può essere rappresentata attraverso un
albero la cui radice, cioè il documento stesso, punta ad un elemento
principale; i nodi dell’albero sono a loro volta elementi che possono avere,
tra di loro, riferimenti incrociati, mentre le foglie sono coppie attributo-
valore o valori semplici, come per esempio stringhe, date e numeri.
Ad esempio se voglio creare un mio linguaggio di markup per definire, ad
esempio, “ricette da cucina”, non ho da fare altro che definire la struttura
che voglio dare alle ricette ed i tag da utilizzare. Supponiamo di aver deciso
di definire una ricetta nel nostro linguaggio, chiamiamolo XMLRicette, e che
il seguente sia un esempio di ricetta:
58

Pasta, aglio olio e peperoncino
Anonimo
200 gr. di spaghetti
uno spicchio di aglio
olio
un pizzico di peperoncino
sale
Far bollire dell'acqua in una pentola...
Figura 2.4 - Esempio di costruzione di una Ricetta in XML
La struttura sembra ragionevole, la scelta dei tag pure. Siamo soddisfatti del
nostro nuovo linguaggio.
Gli schemi XML sono documenti utilizzati per definire e convalidare il
contenuto e la struttura dei dati XML, nello stesso modo in cui uno schema
di database definisce e convalida le tabelle, le colonne e i tipi di dati da cui è
costituito un database. Gli elementi degli schemi XML, ovvero elementi,
attributi, tipi e gruppi, vengono utilizzati per definire una struttura valida, un
contenuto dei dati valido e le relazioni di determinati tipi di dati XML. Gli
schemi XML possono inoltre fornire valori predefiniti per attributi ed
elementi.
Riprendendo l’esempio precedente, supponiamo ora di voler arricchire il
nostro linguaggio con la possibilità di inserire una bibliografia in fondo a
ciascuna ricetta. Abbiamo sentito parlare di un linguaggio basato su XML
che consente di definire bibliografie: XMLBiblio.
Non sarebbe male utilizzarlo per integrare il nostro XMLRicette. Avremmo
il vantaggio di utilizzare un linguaggio noto e ci eviteremmo di doverci
59

e-inventare quello che altri hanno già definito. Diamo allora un'occhiata ad
un esempio di bibliografia descritta con XMLBiblio:
Hermann Hesse
Narciso e Boccadoro
Mondadori Editore
1933
Figura 2.5 - Esempio di Bibliografia
Niente di complicato. Potremmo utilizzare questo linguaggio per inserire
note bibliografiche in fondo ad una ricetta descritta con XMLRicette, come
nel seguente esempio:
Pasta, aglio olio e peperoncino
Anonimo
200 gr. di spaghetti
uno spicchio di aglio
olio
un pizzico di peperoncino
sale
Far bollire dell'acqua in una pentola...
Mario Rossi
Della pasta e di altre delizie
Chef Editore
2002
Figura 2.6 - Esempio di Ricetta con Bibliografia
60

Osservando per bene l'esempio, salta all'occhio un piccolo problema: come
il linguaggio XMLRicette, anche XMLBiblio utilizza i tag “” e
“”, naturalmente per un contesto diverso. Ma come farà il parser a
distinguere il tag “” di XMLBiblio dal tag “” di
XMLRicette? Come possiamo risolvere il problema dei tag omonimi?
Il problema delle ambiguità che possono creare oggetti omonimi non è
nuovo nell'informatica. Per fare qualche esempio, è lo stesso problema che
si pone nell'estrazione di dati da due tabelle di un database che hanno campi
con lo stesso nome. Se ci pensiamo bene, in fondo, non è soltanto un
problema dell'informatica. I nomi propri di persona hanno lo stesso
potenziale problema. Se in un gruppo di persone ci sono due Andrea, come
faccio ad individuarne uno per parlare di lui con un mio amico? Semplice,
basta citare anche il cognome! In termini tecnico-informatici il cognome è
rappresentato dal namespace. Possiamo definire un namespace come un
raggruppamento di nomi sotto un unico identificatore.
In un documento XML si fa riferimento ad un namespace utilizzando
l’attributo speciale “xmlns”, associato al root element, come nel seguente
esempio:
Figura 2.7 - Esempio di definizione di un Namespace
Questo indica che l’elemento ricetta ed i suoi sottoelementi utilizzano i
nomi definiti nel namespace identificato dall’identificatore
“namespaceRicetta”. È possibile inoltre combinare più namespace facendo
61

in modo che ciascun elemento utilizzato faccia riferimento al proprio
namespace. Occorre tener presente che quando si fa riferimento ad un
namespace, questo riferimento vale per l’elemento corrente e per tutti gli
elementi contenuti, a meno che non venga specificato un diverso
namespace. Il nostro problema di ambiguità può essere risolto, pertanto nel
seguente modo:
Pasta, aglio olio e peperoncino
Anonimo
...
Mario Rossi
Della pasta e di altre delizie
Chef Editore
2002
Figura 2.8 - Soluzione dell’ambiguità con i namespace
Anche se in teoria sarebbe possibile utilizzare qualsiasi identificatore per un
namespace, è opportuno utilizzare nomi univoci che evitino a loro volta
omonimie tra namespace. Per questo motivo i namespace vengono
identificati anch’essi tramite URI; in particolare, è prassi comune utilizzare
un URL come identificatore di un namespace, in modo che ci sia una
corrispondenza biunivoca tra chi definisce un namespace ed il rispettivo
nome a dominio. Ad esempio, un possibile identificatore per il nostro
linguaggio potrebbe essere:
62

Figura 2.9 - Identificatore (URI) per Namespace
È inoltre opportuno utilizzare dei prefissi come abbreviazione degli
identificatori di namespace. Ad esempio, potremmo utilizzare la seguente
abbreviazione nel nostro esempio:
Pasta, aglio olio e peperoncino
Anonimo
...
Mario Rossi
Della pasta e di altre delizie
Chef Editore
2002
Figura 2.10 - Prefissi e Namespace
Con questo meccanismo ciascun elemento del documento è associato senza
ambiguità al rispettivo namespace.
Per concludere, data la struttura ad albero, il linguaggio si rivela
insufficiente per i nostri scopi, poiché siamo interessati ad avere come
Information-model un grafo, in quanto ci offre un potere di rappresentazione
più elevato. Inoltre, XML consente di esprimersi secondo una sintassi
63

personalizzata, definendo a piacere i propri tag, ma non viene fornita una
semantica per essi.
Figura 2.11 - XML struttura ad albero
Infatti, dalla figura… si nota come, nel classificare le informazioni secondo
una struttura ad albero, siano state implicitamente inserite relazioni del tipo
is-a oppure is-part-of , semanticamente dedotte secondo la logica umana, in
funzione dei nomi dei tag e del livello di annodamento degli elementi.
Ed ancora i tag di un utente non sono compatibili con quelli definiti da un
altro, nel senso che l’interpretazione degli stessi deve essere nota a priori ad
entrambe. XML permette, quindi, di rendere interoperabili i documenti, ma
non interpretabili dalle macchine.
2.8.3 – RDF : Resource Description Framework
RDF è uno standard [15] proposto da W3C ( World Wide Web Consortium )
[14] che è un consorzio di aziende del settore informatico che si occupa di
64

stabilire standard di riferimento per il Web. Questo consorzio, in altri
termini, studia i sistemi ed i linguaggi per la trasmissione di dati attraverso il
Web e ne ufficializza l'utilizzo attraverso raccomandazioni definitive. Al
W3C si devono gli standard di HTML, XML, SMIL, CSS e altri ancora.
In particolare RDF, è lo strumento base per descrizione delle risorse in
termini di proprietà, attributi e relazioni con altre risorse del dominio
considerato. In altri termini permette la codifica, lo scambio ed il riutilizzo
di meta-dati strutturati e consente l’interoperabilità tra applicazioni che si
scambiano informazioni machine-understandable. La sintassi è basata su
XML mentre si usano URI per specificare entità, concetti, proprietà e
relazioni. RDF, quindi, non descrive la semantica, ma fornisce una base
comune per poterla esprimere, permettendo di definire la semantica dei tag
XML.
RDF è costituito da:
• RDF Model and Syntax: definisce il data model RDF e la sua
codifica XML;
• RDF Schema: consente la definizione di vocabolari per i meta-dati.
Cioè da una parte avremo i dati, dall’altra uno schema che definisce come i
dati si strutturano e come sono in relazione tra loro.
2.8.3.1 – RDF Data Model
RDF data model è basato su tre tipi di oggetti:
• Risorse: Una risorsa è un oggetto, una cosa di cui vogliamo parlare,
un qualsiasi elemento che possa essere identificato mediante un URI.
• Proprietà: Una proprietà è una specifica caratteristica o un attributo
di una risorsa. Può descrivere relazioni tra risorse come ad esempio
65

"scritto da" oppure "età". Anche le proprietà sono identificate da un
URI e quindi rappresentano un tipo speciale di risorse. Si noti allora
che usiamo URI sia per indicare risorse che associazioni tra risorse.
• Statement ( tripla o asserzione ): permette di asserire proprietà tra
risorse. È costituito da una tripla avente la forma
. La Risorsa o soggetto, è l’oggetto
che vogliamo descrivere. La proprietà o predicato è la specifica
proprietà della risorsa, o la relazione tra risorse su cui vogliamo
predicare. Con Valore s’intende appunto il valore assunto dalla
particolare proprietà o l’oggetto con cui viene messa in relazione la
risorsa su cui stiamo predicando. Un valore può quindi essere un
oggetto od un “literals”.
Figura 2.12 - Data Model RDF, Soggetto, Predicato e Oggetto
66

Graficamente, un documento RDF è un grafo etichettato ed orientato. I nodi
sono i soggetti e gli oggetti di ciascuno statement, mentre gli archi
rappresentano i predicati e assumono il verso dal soggetto all’oggetto e
l’etichetta uguale al nome della proprietà del soggetto.
Figura 2.13 – RDF - Struttura a grafo
Dunque la descrizione di una risorsa consiste nell’esprimere l’insieme delle
proprietà che la caratterizzano. Talvolta, è necessario far riferimento a più di
una risorsa, per esempio per esprimere il fatto che un libro è stato scritto da
più autori. RDF definisce la primitiva Container, che serve proprio a questo
scopo. I Container sono di tre tipi:
• Bag: lista non ordinata di risorse o costanti, ammette duplicati;
• Sequence: lista ordinata di risorse o costanti, ammette duplicati;
• Alternative: lista di risorse o costanti che rappresentano
un’alternativa per il valore (singolo) di una proprietà.
67

In RDF è ancora possibile effettuare la reificazione di statements, ovvero
costruire Statements about statements.
Per concludere presentiamo un breve esempio di documento RDF che
specifica alcune informazioni personali
Adalberto Scognamiglio
Sig.
Figura 2.14 - Serializzazione RDF Document
Il tag è l'elemento root del documento RDF,
indentifica una risorsa con l'attributo about che definisce la risorsa descritta.
Altri attributi importanti RDF sono , e
.
Volendo fare un’analogia didattica tra la rappresentazione dei dati in RDF e
l’Entity-Relationship dei database relazionali, si può dire che : una riga di
una tabella corrisponde ad un insieme di statement (asserzioni) RDF relative
alla stessa Risorsa, il nome di ciascun campo ( cioè di ciascuna colonna
della tabella ) è il nome di una proprietà RDF ed il valore del campo è il
valore della proprietà RDF ( cioè l’oggetto della proprietà ).
68

2.8.3.2 – RDF Schema
L’ RDF data-model visto sinora serve unicamente per descrivere modelli
dei dati e può esprimere semplici affermazioni come “il nome del mio
correlatore è Giancarlo”, “il mio professore preferito è Cotroneo”, “un
cane è un animale”, “il cane bobby è un Pastore Tedesco”. RDF pur
definendo proprietà e relazioni tra risorse non ha nessun tipo di
concettualizzazione e quindi in nessun modo si riesce a definire concetti in
maniera univoca. Tuttavia, quando si usa RDF per descrivere gli oggetti di
un qualsiasi dominio ( il mondo birrario ad esempio ) è indispensabile
tener conto della natura stessa del dominio. In pratica l’ambito interessato
va considerato in termini di categorie ( classi di oggetti appartenenti al
dominio), relazioni possibili tra gli oggetti e regole che governano tali
relazioni al fine di renderle “valide”.
RDF Schema affianca RDF fornendo informazioni utili alla interpretazione
ed alla validazione del documento RDF. RDFS è quindi una estensione di
RDF; ed in particolare è ancora scritto in RDF.
I concetti messi a disposizione da RDF Schema sono quelli di:
• Classe e Sottoclasse;
• Proprietà e Sottoproprietà;
• Dominio e Condominio di un proprietà;
• Commenti, etichette ed informazioni addizionali.
Le risorse vengono suddivise in gruppi chiamati classi. Gli individui
appartenenti a ciascuna classe sono conosciuti come istanze della classe.
Le classi, che sono a loro volta delle risorse, sono identificate ancora da
URI e possono essere descritte tramite proprietà RDF. La proprietà rdf:type
69

( che abbiamo introdotto nel paragrafo precedente ) può essere utilizzata per
affermare che una risorsa è una istanza di una classe ( “istanzaA rdf:type
classeA” ). RDF distingue tra una classe ed un insieme di istanze. Associata
ad ogni classe c’è un insieme, chiamato il class extension di una classe, che
è l’insieme delle istanze della classe. Due classi possono avere lo stesso
insieme di istanze ma essere classi diverse. Una classe può essere un
membro della sua class extension e quindi essere un’istanza di se stessa. Un
gruppo di risorse che rappresentano classi RDFS è esso stesso una classe
chiamata rdfs:Class.
Vediamo i principali tipi di classi RDFS:
• rdfs:Resource: tutte le classi sono sottoclassi di rdfs:Resource. E’
un’istanza di rdfs:Class;
• rdfs:Class: la classe di risorse che sono classi RDF. Istanza di
rdfs:Class cioè di de stessa;
• rdf:Property: la classe delle proprietà RDF. Istanza di rdfs:Class.
• rdfs:Literal: la classe dei valori letterali come stringhe e interi.
Possono essere semplici o tipate, in questo caso hanno un
riferimento all’URI che definisce il tipo di dato;
• rdfs:Datatype: la classe dei tipi di dato. Ogni istanza di questa classe
è una sottoclasse di rdfs:Literal;
• rdf:XMLLiteral: la classe dei valori letterali XML. Istanza di
rdfs:Datatype e sottoclasse di rdfs:Literal;
RDF Schema permette poi di organizzare sia le classi che le proprietà
secondo schemi gerarchici attraverso il meccanismo dell’ereditarietà.
Tali relazioni di tipo I-SA possono essere definite per classi e proprietà
70

ispettivamente attraverso i costrutti rdfs:subClassOf e rdfs:subPropertyOf.
Il primo dei due afferma che se “Class1 rdfs:subClassOf Class2”, allora
Class1 è una sotto-classe di Class2, e quindi tutte le istanze di Class1
saranno anche istanze di Class2. Analogo discorso vale anche per le
proprietà. Questi due costrutti godono, come è logico che sia, della proprietà
transitiva.
In RDFS è, inoltre, possibile esprimere vincoli attraverso le proprietà
rdfs:range e rdfs:domain. Queste si applicano ad altre proprietà e devono
avere come valori delle classi. Sono utilizzate per restringere l’insieme di
applicabilità delle proprietà indicando a quali risorse può essere applicata
quella data proprietà ( il domain della proprietà ) e l’insieme dei valori
validi per quella proprietà ( il suo range ). La tripla “P rdfs:range C“
afferma che P è una istanza della classe rdf:Property, C è una istanza della
classe rdfs:Class e le risorse che appaiono come oggetti delle triple i cui
predicati sono P, sono istanze della classe C. Quando P ha più di una
proprietà rdfs:range, allora le risorse che rappresentano gli oggetti delle
triple con predicato P sono istanze di tutte le classi indicate dalla proprietà
rdfs:range. Una tripla della forma “P rdfs:domain C” afferma che P è
un’istanza della classe rdf:Property, C è un’istanza della classe rdfs:Class e
le risorse che rappresentano i soggetti delle triple i cui predicati sono P sono
istanze della classe C. Quando P ha più di una proprietà rdfs:domain, allora
le risorse che rappresentano i soggetti delle triple con predicato P sono
istanze di tutte le classi indicate dalla proprietà rdfs: domain.
RDFS definisce, inoltre, altre proprietà come rdfs:comment e rdfs:label che
servono per introdurre rispettivamente una descrizione o una classificazione
comprensibile agli esseri umani.
71

Dunque le classi RDFS più che contenitori sono dei descrittori ( di concetti
e proprietà ) in relazione semantica tra loro. La definizione di vocabolari
semantici, l’ereditarietà, le proprietà e tutti gli altri aspetti descritti
permettono agli agenti software intelligenti di realizzare un servizio
minimale di reasoning basato su regole di inferenza[16].
Figura 2.15 - Gli Strati RDF e RDFS
Volendo fare un’analogia didattica tra la rappresentazione RDFS e la
programmazione OOP si può dire che: nell’OO le classi rappresentano la
descrizione di una categoria di oggetti individuati mediante comportamenti
e caratteristiche simili; i relativi comportamenti vengono definiti “metodi”
mentre le caratteristiche sono dette “proprietà”. Le classi possono poi essere
72

estese per ereditarietà di dati e comportamenti e gli oggetti sono istanze
delle classi. RDFS prevede anch’esso la creazione di classi ed il
meccanismo dell’ereditarietà ma non prevede la definizione di metodi visto
che è orientato alla modellazione dei dati e non dei comportamenti di
quest’ultimi. È inoltre importante evidenziare che in RDF le descrizioni
delle proprietà sono indipendenti dalla definizione delle classi (al contrario
del OOP in cui una proprietà è legata alla classe) ed in tal senso si può
definire il sistema di tipizzazione RDFS come modello “Property-
Oriented”.
Per concludere RDFS è un primitivo linguaggio per la definizione di
Ontologie.
2.8.4 – OWL : Ontology Web Language
Il Web Ontology Language ( OWL ) è un linguaggio di markup per
rappresentare esplicitamente significato e semantica di termini con
vocabolari e relazioni tra i termini. Definisce quindi ontologie strutturate
basate sul Web che permettono una integrazione ed una interoperabilità
maggiore di dati tra comunità che descrivono il loro dominio di conoscenza.
Nonostante RDF(S) sia un linguaggio molto diffuso per la rappresentazione
della conoscenza, ha un potere espressivo limitato. In tale linguaggio,
infatti, non è possibile esprimere:
• la disgiunzione tra classi: in RDF(S) non si può dire che due classi
sono disgiunte;
• la combinazione di classi tramite gli operatori booleani di unione,
intersezione e complemento;
• i vincoli di cardinalità sulle proprietà;
73

• le caratteristiche speciali delle proprietà, come la transitività o
l’inversa di una proprietà;
• etc…
L’esigenza di avere un linguaggio più ricco in grado di esprimere tutti gli
aspetti appena esaminati, ha portato allo sviluppo di DAML+OIL, e OWL,
due linguaggi per ontologie.
• DAML+OIL è il risultato dell’unione di due linguaggi, DAML-ONT
( sviluppato dal DARPA ) e OIL ( sviluppato da ricercatori Europei )
• OWL è il linguaggio per ontologie proposto dal W3C e deriva
direttamente dalla struttura di DAML+OIL
Figura 2.16 - Genesi di OWL
Dunque OWL si basa sul modello “RDF e RDF Schema” ma va ad
estenderlo aggiungendo un vocabolario più ampio per descrivere proprietà
e classi; questo comprende:
74

• relazioni tra classi (ad esempio disgiunzione);
• cardinalità (ad esempio "esattamente uno");
• uguaglianza;
• tipizzazione più ricca delle proprietà;
• caratteristiche di proprietà (ad esempio simmetria);
• classi enumerate.
RDFS è un linguaggio per ontologie
“debole”.
• Permette di costruire una
semplice gerarchia di
concetti e una gerarchia di
proprietà
• Con RDFS possiamo dire
che la nostra ontologia ha 5
classi, che Animale è una
sottoclasse di Essere
Vivente
• Possiamo attribuire proprietà
( zampe, numero di organi
sensitivi, colore ecc...)
• Non possiamo dire che un
animale non può essere una
pianta
• Non possiamo definire
relazioni tra classi di livello
diverso dalla gerarchia
OWL ci permette di dire tutto quello
che si può affermare in RDFS con in
più
• Possiamo affermare che
Animali e Vegetali sono classi
disgiunte (un individuo non
può essere
contemporaneamente vegetale
e animale…)
• La
classe pesci d’acqua salata
può essere definita come
intersezione della classe
ovipari e della classe
organismi marini
OWL vs RDF/RDFS
Figura 2.17 - OWL vs RDF/RDFS
75

Figura 2.18 - Stack OWL Ontology
Dunque con OWL le proprietà diventano più raffinate. Ci possono essere
proprietà di tipo: Transitivo, Simmetrico, Funzionale.
Tutto questo ha un prezzo : Complessità e Pesantezza sintattica[17].
2.8.4.1 – I tre linguaggi di OWL
Come abbiamo anticipato nel descrivere l’architettura del Web Semantico,
all’aumentare della ricchezza ( e quindi della complessità ) del linguaggio di
rappresentazione della conoscenza, aumentano le potenzialità ma anche la
complessità computazionale del reasoning. Nell’adottare un linguaggio di
definizione di ontologie bisogna dunque trovare un compromesso tra
l’espressività del linguaggio e la capacità di reasoning che si desidera
ottenere. Per questo il W3C ha definito OWL attraverso tre diversi sotto-
linguaggi: OWL Lite, OWL DL e OWL Full, di cui i primi due garantiscono
la decidibilità del reasoning, ovvero la piena applicabilità delle regole
d’inferenza.
76

Figura 2.19 - Livelli linguaggi OWL
OWL Full utilizza tutte le primitive del linguaggio OWL e permette di
combinarle in modo arbitrario con RDF(S). Consente di cambiare il
significato delle primitive RDF predefinite applicando tra loro le primitive
del linguaggio. Per esempio in OWL Full si possono imporre vincoli di
cardinalità al costrutto rdfs:Class, limitando così il numero delle classi in un
ontologia. Il vantaggio di OWL Full è quello di avere piena compatibilità
con RDF, sia sintatticamente che semanticamente: ogni documento legale in
RDF è un documento legale anche in OWL Full ed ogni deduzione ottenuta
con RDF(S) è anche una valida deduzione in OWL Full. Lo svantaggio di
OWL Full è che il linguaggio è talmente potente da essere indecidibile,
eliminando ogni speranza di un completo supporto di reasoning.
OWL DL si pone come obiettivo quello di guadagnare in efficienza
computazionale, limitando il modo in cui i costruttori di OWL e RDF
possono essere usati: ciò garantisce al linguaggio di poter essere mappato su
77

una logica descrittiva. Da qui deriva il termine DL, che sta per Description
Logics. Il vantaggio di questo sottolinguaggio è che permette un supporto
completo di reasoning; lo svantaggio è la perdita di compatibilità con RDF:
un documento RDF deve essere esteso sotto certi aspetti e ristretto sotto altri
per essere un documento valido in OWL DL. Viceversa ogni documento
legale in OWL DL è ancora un documento legale in RDF.
OWL Lite limita il proprio insieme di costrutti ad un sottoinsieme di quelli
di OWL DL. Il vantaggio è quello di avere un linguaggio più semplice (per
gli utenti) e più facile da utilizzare (per i costruttori di ontologie). Lo
svantaggio è un’espressività molto ristretta. Un’ontologia è valida in OWL
Lite se lo è anche in OWL DL.
2.8.4.2 – I costrutti principali di OWL
Innanzitutto OWL essendo costruito su RDF e su RDFS usa una sintassi
XML-based. Un documento OWL è chiamato anche Ontologia OWL ed un
esempio di header di un Ontologia OWL è il seguente:
Figura 2.20 - Esempio OWL Header
Come si vede l’elemento root è sempre , dopo il quale vengono
specificati i vari namespaces. Successivamente, possono poi esserci una
serie di asserzioni, come ad esempio dei commenti, la versione e l’eventuale
inclusione di altre ontologie. Per definire una classe si usa il costrutto
owl:Class. Il costrutto rdfs:subClassOf permette di disegnare la gerarchia di
78

classi. Si può affermare, prendendo spunto da un esempio fatto in
precedenza, che la classe Animale sia sottoclasse della classe EssereVivente.
Ancora è possibile affermare che la classe Animale sia disgiunta dalla classe
Vegetale usando il costrutto owl:disjointWith[18].
Di seguito si elencano brevemente gli altri costruttori importanti di OWL:
owl:intersectionOf Intersezioni tra Classi
Owl:unionOf Unione tra Classi
Owl:complementOf Complementazioni tra Classi
Owl:oneOf Classe Enumerata
Owl:equivalentClass Classe Equivalente
Owl:cardinality Cardinalità Esatta
Owl:minCardinality Cardinalità Minima
Owl:maxCardinality Cardinalità Massima
Owl:someValueFrom Quantificatore Esistenziale
Owl:allValueFrom Quantificatore Universale
…..
Figura 2.21 - Costrutti OWL per la definizione di classi
Owl:equivalentProperty Proprietà Equivalente
Owl:inverseOf Proprietà Inversa
Owl:ObjectProperty Proprietà verso Oggetti
Owl:DatatypeProperty Proprietà verso Letterali
Owl:FunctionalProperty Proprietà Funzionali
Owl:SymmetricProperty Proprietà Simmetrica
Owl:TransitiveProperty Proprietà Transitiva
…..
Figura 2.22 - Costrutti OWL per la definizione di proprietà
79

2.9 – Reasoning
Finora abbiamo più volte parlato di Reasoning cioè di quella tecnica
mediante la quale ottenere nuova conoscenza ( conoscenza inferita ) a
partire da un certo numero di informazioni che si hanno a disposizione
(conoscenza asserita ), applicando opportune regole di inferenza.
I reasoner ( che possono essere definiti anche ragionatori, motori
inferenziali o classificatori ) sono programmi che offrono i servizi per
ragionare ( fare inferenza come in intelligenza artificiale ) sulle basi di
conoscenza ( KB ). Esistono diverse tipologie di reasoner. Ogni tipologia è
compatibile con un determinato formalismo di rappresentazione della
conoscenza, e ciò è dovuto al fatto che ogni particolare linguaggio utilizzato
per rappresentare la base di conoscenza prevede un set di regole di inferenza
che però possono essere integrate da altre.
Una regola è costituita di una pre-condizione e di conseguenze; quando le
condizioni iniziali sono soddisfatte allora si scatenano le azioni conseguenti
che semplicemente si traducono in nuovi fatti, nuova conoscenza che va ad
aggiungersi alla KB iniziale.
I risultati ottenuti da una query su una KB dipendono fortemente dal
reasoning, nel senso che senza un adeguato ragionamento ( processo di
inferenza ), molte conoscenze o relazioni contenute implicitamente nella KB
iniziale rimarrebbero in essa nascoste, e quindi le risposte ottenute da un
query engine ( motore di query ) potrebbero essere incomplete. Ad esempio,
se definiamo un concetto con determinate proprietà ed alcune sottoclassi
dello stesso concetto con altre proprietà aggiuntive, senza il reasoning sui
dati, la richiesta delle proprietà di una delle sottoclassi non restituisce quelle
80

ereditate dalla classe padre. E’ necessario, pertanto, un processamento dei
dati da parte di un reasoner per rendere esplicite tali proprietà.
Ma un reasoner non aiuta semplicemente l’esecuzione di query, bensì
prevede anche servizi di inferenza di base, che vedremo più avanti, che
possono essere di aiuto anche nelle altre fasi del ciclo di vita di una base di
conoscenza
Il requisito che si richiede ad un reasoner è di essere sound and complete,
ovvero corretto e completo. La correttezza deve esserci rispetto alla
semantica definita dai concetti, la completezza deve riguardare la procedura
di decisione rispetto a tale semantica. Purtroppo, al momento i reasoner
sviluppati hanno ancora delle lacune e un tempo di esecuzione con
complessità esponenziale nel caso peggiore.
Le principali funzionalità di un reasoner sono:
• Consistency check: detta anche Soddisfacibilità, è l’abilità di trovare
i concetti di una KB definiti in modo contraddittorio; in altri termini
una classe all’interno dell’ontologia è detta “consistente” se possono
esistere individui appartenenti ad essa. Se un ontologia ha delle
classi inconsistenti vuol dire che è stato fatto qualche errore in fase
di modellazione e che è opportuno correggere prima di distribuire o
utilizzare l’ontologia in contesti applicativi.
• Classify Tassonomy: consiste nella costruzione della gerarchia
imposta dalle relazioni di sottoclasse. In altri termini la
classificazione dell’ontologia permette di ottenere la gerarchia
desunta delle classi dell’ontologia che può essere diversa da quella
dichiarata dal designer dell’ontologia. Questo strumento insieme a
quello precedente sono un validissimo strumento d’aiuto nella
81

costruzione di un ontologia in quanto permettono una descrizione
dettagliata dei fatti ma non ridondante.
• Datatype Reasoning: consiste nella capacità di gestire i semplici
datatype di XML Schema. Tali datatype sono tipi numerici, stringhe,
date, ma esistono anche meccanismi, standard o inusuali, per la
definizione di nuovi tipi a partire da questi.
• Entailment: detta anche Sussunzione è la capacità di determinare
tutte le implicazioni derivanti dalla semantica; in altri termini il
concetto di sussunzione è alla base del reasoning in quanto consente
di individuare la gerarchia, indotta dalla relazione di sottoclasse, tra i
concetti presenti in una KB.
• Conjunctive queries: è l’abilità di effettuare query sulle istanze di
una KB;
• Instance Checking: detta anche Realizzazione è la capacità di un
reasoner di trovare le classi specifiche a cui appartiene un certo
individuo o una certa istanza.
In funzione delle caratteristiche dei linguaggi per la definizione della
conoscenza che abbiamo introdotto precedentemente soprattutto
relativamente a le tre versioni di OWL, ed ancora poiché in generale si è
interessati ad avere processi di reasoning non lunghi ma soprattutto
terminanti, i reasoner attualmente più diffusi utilizzano principalmente le
Description Logics (DL) e le First Order Logics (FOL). Le prime possono
essere viste, in generale, come il sottoinsieme decidibile delle seconde.
Queste, a loro volta, hanno agenti risolutori che potenzialmente potrebbero
82

essere utilizzati per fornire servizi di reasoning più avanzati per i quali però
ancora non sono stati sviluppati algoritmi specifici.
Una caratteristica generale delle DL è che la base di conoscenza è costituita
da due componenti: la Tbox e l’Abox.
• Terminological Box o Tbox ( parte intenzionale ), costituita dalla
conoscenza definita ed immutabile sul dominio rappresentato, a
livello concettuale e strutturale;
• Assertional Box o Abox ( parte estensionale ), costituita dalla
conoscenza relativa al problema attuale.
In un’ontologia possiamo affermare che la Tbox è costituita dai concetti che
vi sono definiti, mentre l’Abox dalle istanze di tali concetti. Le procedure
d’inferenza che caratterizzano i due diversi tipi di conoscenza sono
profondamente distinte e con differente complessità computazionale o
performance. La Tbox è costituita da una serie di definizioni di concetti,
descritte mediante altri concetti e costruttori. Le definizioni presenti in una
Tbox devono soddisfare alcuni vincoli per poterne garantire univocità ed
aciclicità:
• un concetto è definito in modo univoco;
• nella parte sinistra della dichiarazione può essere presente solo un
nome di un concetto, inteso come entità atomica;
• nessun concetto può essere definito in funzione di se stesso;
• un concetto non può essere definito nei termini di un secondo
concetto che sussume, perché questo non può ancora essere stato
definito nella KB.
Si possono riassumere gli ultimi due vincoli affermando che non sono
permesse definizioni cicliche oppure che si riferiscono a sé stesse. In questo
83

modo ciascun concetto non primitivo presente in una descrizione è sostituito
dalla propria descrizione, dando luogo ad una gerarchia che rispetta la
sussunzione tra concetti. Procedendo dai concetti superiori a quelli inferiori,
le definizioni si fanno sempre più complesse.
L’ABox contiene asserzioni che specificano gli individui attuali nel dominio
di interesse, ovvero le istanze nel caso di un’ontologia. Le asserzioni
possono essere di due tipi fondamentali: concettuali o di ruolo.
Generalmente la specifica delle asserzioni nella KB avviene in due fasi:
prima si dichiarano gli individui del dominio e poi le rispettive relazioni. I
servizi d’inferenza sull’ABox coinvolgono necessariamente anche la Tbox,
in quanto le istanze presenti nella prima appartengono a concetti definiti
nella seconda.
2.10 – Tools per la definizione e l’utilizzo di Ontologie
Negli ultimi anni, con la crescente attenzione verso la rappresentazione della
conoscenza e con lo sviluppo del Web Semantico, sta crescendo anche il
numero di tools sviluppati per la creazione, manipolazione ed uso di
ontologie. Quando si vuole costruire un’ontologia sorgono numerose
domande per scegliere quale tool utilizzare: quale tool darà maggiore
supporto al processo di sviluppo di un’ontologia? In che modo vengono
memorizzate le ontologie ( database o XML )? Il tool possiede o supporta
un motore di inferenza ( inference engine )? Quali linguaggi per la
definizione di Ontologie sono supportati? E’ corredato di traduttori di
linguaggi di ontologie? Come possono le applicazioni interoperare con i
server di ontologie?, etc... In questo paragrafo si vanno ad introdurre i vari
tool utilizzati nelle successive fasi di sviluppo.
84

2.10.1 – PROTÉGÉ : Editor per Ontologie
Protégé[19] è uno dei tool sviluppati dall’Università di Stanford per
l’acquisizione delle informazioni, ha migliaia di utilizzatori in tutto il
mondo per la realizzazione di progetti che coprono vari domini
Protégé [19] è un editor di ontologie free ed open-source, quindi scaricabile
gratuitamente, nonchè un framework per basi di conoscenza che supporta
gli utenti nella realizzazione di applicazioni che facciano uso di ontologie.
Figura 2.23 - Finestra Protègè
Protégé fornisce un ambiente grafico e interattivo per la progettazione delle
ontologie e un ambiente di sviluppo concettuale. Tra le principali
funzionalità consente:
• la creazione, la manipolazione e la visualizzazione di ontologie;
85

• l’import / export delle ontologie in vari formati (OWL, RDF
Schema, XML Schema, ecc...);
• l’esecuzione di ragionatori automatici;.
• la personalizzazione delle varie funzionalità.
I suoi principali vantaggi sono l’architettura basata su Java plug-in che lo
rende facilmente estendibile; si presenta infatti come una collezione di
plug-ins singolarmente o interamente sostituibili per modificarne il
comportamento e l’interfaccia. Altro vantaggio è la vasta community che
contribuisce a renderlo aggiornato.
Le APIs fornite sono essenzialmente di due tipi:
• Protégé-Core and Protégé-Frames APIs permettono l’accesso alle
funzionalità base e alle KB basate su frames;
• Protégé-OWL permette di estendere le Protégé-Core APIs per
accedere alle Ontologie OWL.
La versione utilizzata è quella stabile cioè la Protègè3.3.1 , ma sono
disponibili anche le versioni Beta Protègè3.4 e Protègè4.0.
2.10.2 – SPARQL : Query Language
Per utilizzare una base di conoscenza formalizzata mediante il linguaggio
OWL è necessario un linguaggio di interrogazione. Esistono diversi
linguaggi di interrogazione funzionalmente equivalenti come SPARQL,
RDQL, RQ e per finire OWL-QL.
Prima di definire i requisiti di un linguaggio di query per ontologie è
opportuno capire però quali sono le problematiche derivanti dall’uso di basi
86

di conoscenza piuttosto che di basi di dati. Una prima differenza molto
importante è che le Query sulle basi di dati sono eseguite sulle istanze e cioè
sul livello estensionale. Inoltre le proprietà ACID di cui godono le istanze di
una base di dati garantiscono che l’esecuzione di una query restituisca
sempre un risultato corretto, magari anche l’insieme vuoto, ma soprattutto in
un tempo finito. Nel caso delle basi di conoscenza, invece,
un’interrogazione viene eseguita coinvolgendo direttamente il livello
intensionale, oltre che quello estensionale, si tratta cioè di un tipo di query
strutturale. Nel processo di esecuzione della query possono essere impiegate
tecniche di reasoning che permettono di dedurre fatti non esplicitamente
asseriti nella KB di partenza oltre il fatto che lo stesso risultato può differire
da reasoner a reasoner. Inoltre, nel caso di ontologie sufficientemente grandi
e complesse, il tempo di esecuzione può diventare molto elevato ed al limite
infinito.
Come per i linguaggi di rappresentazione della conoscenza, per i quali
esistono diversi standard quali RDF e OWL, attualmente il W3C propone
come standard per l’interrogazione di basi di rappresentazione della
conoscenza RDF lo SPARQL[20], che consiste in un linguaggio e in un
protocollo per l’esecuzione di query remote.
SPARQL, così come gli altri buoni linguaggi di query per ontologie ha le
seguenti proprietà, alcune delle quali sono specificate dal W3C e quindi
necessarie per l’accesso ai dati presenti nei documenti RDF:
• effettua il “graph pattern triple matching”, ovvero ricerca una o più
triple della forma “soggetto – predicato – oggetto”, in cui il soggetto
e/o l’oggetto sono espresse come variabili. Tali interrogazioni
possono essere fatte specificando eventualmente l’unione o
87

l’intersezione di pattern. Si parla infatti di conjunctive e disjunctive
query;
• restituisce i risultati sottoforma di triple RDF/OWL o documenti
XML, formattando il risultato esattamente come il sottografo del
documento interrogato che soddisfa la query;
• supporta i namespace:
• permette l’esecuzione di query in locale ed in remoto;
• considera il modello astratto indipendentemente dalle sue possibili
serializzazioni;
• supporta i datatype di XML;
• supporta un eventuale richiesta di un numero massimo di risultati;
• possibilità di esprimere pattern opzionali;
• etc…
Concludiamo il paragrafo con un esempio di query.
PREFIX rdf:
PREFIX owl:
PREFIX rdfs:
SELECT ?subject ?object
WHERE {?subject ?property ?object };
Figura 2.24 - Semplice esempio di Query SPARQL
2.10.3 – PELLET : Un Reasoner per OWL
Pellet è un ragionatore ( motore inferenziale ) scritto in Java, free ed
open-source[21]. In particolare si tratta di un pratico e popolare tool per
88

lavorare con OWL. È stato il primo reasoner a supportare completamente la
piena espressività di OWL-DL (SHOIN(D)), incluso il ragionamento sui
nominali ( classi enumerate ) che è ancora estremamente arduo, ed oltre alle
numerose ottimizzazioni , di recente è stato esteso per supportare OWL 1.1.
Quest’ultimo va ad estendere OWL-DL con vincoli sulla cardinalità, con un
più complesso meccanismo per la definizione di sottoproprietà, ed ancora
con ulteriori caratteristiche per le proprietà come riflessività ed irriflessività,
simmetria e antisimmetria, proprietà di disgiunzione, etc…
Il meccanismo decisionale di Pellet si basa su un algoritmo di tipo tableaux,
inoltre offre un insieme di caratteristiche includendo conjunctive query,
supporto per la definizione di regole , E-Connection Reasoning ed altre
capacità ancora.
Per facilitare l’accesso alle capacità del reasoner da parte delle applicazioni
e degli utenti del ragionatore, Pellet supporta varie interfacce tra cui una
command-line interface, un’implementazione come DIG server ed ancora
l’accesso programmatico mediante delle APIs richiamabili da RDF/OWL
toolkits JENA e Manchester OWL-API.
Le principali funzionalità di Pellet sono[22]:
• analisi, validazione, debbugging e riparazione di ontologie;
• reasoning sui datatype di XML Schema e su quelli definiti
dall’utente;
• entailment ovvero la sussunzione tra concetti che permette di
definire la gerarchia;
• Conjunctive ABox Query;
• integrazione con regole formali;
89

• Multi-Ontology reasoning usando le E-Connction che sono
formalismi logici per collegare le informazioni presenti in più
ontologie.
• etc…
Per concludere si mostra l’architettura del reasoner Pellet.
Figura 2.25 - Pellet System Architecture[23]
Nella figura precedentemente mostrata, in blu sono denotati gli elementi
propri del componente, mentre in verde le applicazioni esterne che utilizza o
che sono supportate.
2.10.4 – JENA
Jena è un framework open source sviluppato dal Semantic Web Research
Group di HP Labs[24] per lo sviluppo di applicazioni Java Ontology-Based.
Nato inizialmente per realizzare applicazioni che supportassero RDF ed
RDFS, Jena è stato successivamente esteso ai linguaggi per la definizione di
90

ontologie tra cui DAML+OIL ed OWL[25]. Jena è scaricabile gratuitamente
da Sourceforge[26].
Jena pur supportando diversi linguaggi per l’espressione di ontologie,
fornisce un’unica API neutrale rispetto al linguaggio. Ciò significa poter
lavorare con le ontologie in maniera indipendente dal linguaggio con cui
queste sono state definite.
Jena permette la modellazione e la manipolazione di basi di conoscenza,
permette l’integrazione nelle applicazioni di alcuni Reasoner tra i più
potenti e supporta anche un query engine incapsulato nel modulo ARQ
( A SPARQL Processor for Jena ) che è un componente che supporta
differenti linguaggi di query tra cui RDQL e SPARQL.
Il framework è costituito di un certo numero di librerie ( package ), tra cui
qui di seguito si enunciano le principali:
• com.hp.hpl.jena.graph che rappresenta un grafo RDF;
• com.hp.hpl.jena.rdf.model RDF API: introduce l’interfaccia Model,
che rappresenta un modello RDF. Prevede metodi per la creazione e
la gestione di risorse, proprietà, letterali e statement. Contiene
l’estensione InfModel per gestire le informazioni inferite da un
reasoner;
• com.hp.hpl.jena.reasoner Inference API: permette di associare un
reasoner ad un modello ontologico;
• com.hp.hpl.jena.ontology Ontology API: introduce le opportune
estensioni per il supporto dei linguaggi RDFS, OWL; Prevedi inoltre
l’interfaccia OntModel indipendente dal linguaggio di
rappresentazione e metodi per la creazione e la gestione di classi,
proprietà, individui, gerarchie di classi e proprietà;
91

• com.hp.hpl.jena.reasoner.dig DIG API: prevede
un’implementazione DIGReasoner per utilizzare un reasoner DIG;
• com.hp.hpl.jena.db permette l’eventuale gestione persistente dei dati.
La gestione delle ontologie in Jena si realizza mendiante l’interfaccia
OntModel introdotta già precedentemente. È possibile creare un’ontologia e
contemporaneamente specificare quale linguaggio ontologico adottare
passando al relativo metodo l’URI corrispondente come mostrato nella
tabella che segue.
Figura 2.26 - Linguaggi per Ontologie e relative URI
Sono offerti metodi per creare classi, proprietà ed individui, ed ancora è
possibile importare delle ontologie pre-esistenti ( eventualmente create con
Protègè ) o salvarle in file. Mediante opportuni metodi è ovviamente
possibile esplorare o navigare tali ontologie.
92

L’interfaccia OntModel mantiene tutte le informazioni contenute
nell’ontologia come statement RDF. Se quindi si prova ad accedere ad una
certa informazione, bisogna accedere allo statement che la rappresenta. Allo
stesso modo quando si vanno ad aggiungere nuove informazioni, nuovi
statement vengono inseriti nel modello.
Qualora l’ontologia prevedesse l’uso di un reasoner, eventuali nuove
informazioni ottenute per inferenza sarebbero mantenute nel modello ancora
agganciando nuovi statement così come per quelli che rappresentano le
cosiddette informazioni esplicite.
Per quanto riguarda i reasoner, Jena prevede dei reasoner “interni” le cui
possibilità sono però limitate. Ed allora sono previsti meccanismi per il
collegamento di reasoner esterni come Racer, Fact ma soprattutto Pellet,
sia attraverso l’utilizzo dell’interfaccia Standard DIG ma anche mediante
collegamento diretto importando le relative librerie ( soluzione questa che
tra l’altro è più performante ).
93

3.1 – Introduzione
Capitolo 3
Definizione di un Semantic Message Oriented
Middleware a supporto dei sistemi ATM
La maggior parte degli attuali sistemi distribuiti su larga scala necessita di
connettere un numero elevato di sistemi a loro volta distribuiti
geograficamente, che sono eterogenei, fortemente decentralizzati e soggetti
a differenti cambiamenti durante il loro ciclo di vita.
Tali caratteristiche motivano non poco la necessità di utilizzare un
middleware che permetta di disaccoppiare il più possibile i sistemi e di far
evolvere nel tempo ogni componente del sistema complessivo in maniera
indipendentemente.
Tra i diversi pattern di comunicazione, il MOM ( Message Oriented
Middleware ) sembra essere quello più adatto alla realizzazione di una
piattaforma middleware versatile, capace di integrare in accoppiamento
lasco i sistemi distribuiti. Inoltre tra i due paradigmi di comunicazione
previsti dal modello MOM , il publish-subscribe è meglio accreditato
94

ispetto al message-queuing in quanto permette un paradigma di
comunicazione di tipo “many-to-many” .
Nel contesto di un sistema il cui focus principale è lo scambio di
informazioni tra i vari sistemi ATM, assumono grande rilevanza
caratteristiche quali espressività ed efficienza dei meccanismi di
distribuzione dei dati. In questo capitolo si vanno ad introdurre i possibili
vantaggi che si possono ottenere mediante l’integrazione di un modello
semantico come un’ontologia nel contesto di un middleware basato sul
modello publish-subscribe.
3.2 – Pattern Cooperativi per l’ATM
Come già anticipato nel primo capitolo, lo scopo principale di SWIM
consiste nel realizzare un prototipo di una piattaforma middleware per
l’interoperabilità e lo scambio di dati e servizi tra i vari sistemi ATM sia
quelli attuali che di prossima generazione.
In questo contesto e per quanto detto nel primo capitolo risulta necessario ed
opportuno che i diversi stakeholders dell’ATM vengano tra loro
interconnessi in accoppiamento lasco attraverso un sistema la cui
architettura sia basata sugli eventi. Ed allora un’infrastruttura basata sul
paradigma di comunicazione di tipo publish-subscribe soddisfa in modo
efficiente molti dei requisiti descritti nel progetto SESAR SWIM.
In generale, il servizio di messaging prevede un insieme di nodi distribuiti
sulla rete. Ciascun client del sistema di messaging può essere o publisher, il
cui compito è quello di produrre ed inviare informazioni, o subscriber, ed in
tal caso il suo compito è quello di sottoscriversi per ricevere i particolari tipi
di informazioni a cui è interessato per poi consumare i dati ricevuti. I clients
95

non comunicano direttamente tra loro, ma la loro interazione può avvenire
solo attraverso il servizio di notifica. In questo modo la sincronizzazione tra
produttori e consumatori viene gestita dal servizio stesso.
Inoltre, nel contesto di SWIM, la cooperazione tra i diversi attori della
gestione del traffico aereo avviene secondo diversi ruoli, regole e
responsabilità. Se da un lato si prevede di disaccoppiare i consumatori dei
dati dai restanti attori del sistema così che possano variare nel tempo in
numero e tipologia, questa visione non è ugualmente valida per i produttori
di dati. Infatti, nell’ottica di produrre dei dati in uno stato consistente e
valido, diventa necessaria la cooperazione dei diversi attori che
contribuiscono alla produzione di tali dati ( contributors ). Nella figura che
segue vengono definiti i ruoli che sono stati individuati nel contesto di
SWIM.
Ruolo Definizione
- Riceve dal Manager dati coerenti
PUBLISHER
- Distribuisce dati agli altri attori
- Raccoglie i dati dei Contributors per
MANAGER
produrre dati consistenti
- Fornisce dati consistenti al Publisher
- Si sottoscrive ad un dato o a parte di
USER
esso
- Riceve gli aggiornamenti dei dati
- Imposta il valore di parte delle
informazioni (topic)
che costituiscono il dato.
CONTRIBUTOR
- Invia il nuovo topic del dato al
Manager (contributo
parziale).
Figura 3.1 - Definizione dei Ruoli
96

Il middleware dovrà quindi prevedere funzionalità per la gestione dei ruoli
quali:
• definire ruoli differenti per dati differenti;
• definire ruoli differenti per lo stesso dato;
• modificare il ruolo in base al dato.
In base a quanto detto ed all’architettura stratificata del sistema SWIM, si
evince che lo strato SWIM ATM Data Access deve permettere di accedere ai
dati ATM di SWIM e di definire i meccanismi per la gestione dei dati
(accesso, aggiornamento e sottoscrizione ).
Nella seguente figura viene illustrato lo scenario in cui diversi sistemi ATM
peer-to-peer comunicano mediante il paradigma publish-subscribe. Infatti,
l’interazione tra i sistemi avviene mediante il Global Data Space che ne
permette il disaccoppiamento.
System I
System IV
1. publish A 2. consume A
4. consume B
5. get X
6. publish C
SWIM Information Pool
2. consume A
3. publish B
7. consume C
System II
System III
Figura 3.2 - Comunicazione di tipo Publish-Subscribe
97

I servizi dello strato SWIM ATM Added-Value invece offrono funzionalità di
livello più alto rispetto al semplice accesso allo Spazio Globale dei Dati e
permettono di rendere disponibili i servizi ATM attraverso la rete SWIM,
mettendo a disposizione meccanismi di comunicazione one-to-one tra i
sistemi client ( service consumer ) ed i sistemi legacy che offrono il
servizio.
Nella seguente figura viene illustrato lo scenario in cui un client ATM
comunica con più legacy system mediante un paradigma di comunicazione
di tipo Request-Response. Questo meccanismo chiarisce la possibilità di
orchestrare ed utilizzare servizi da parte dei client.
Client
Application
1. request
2. response
3. request
4. response
S1
S2
(Legacy)
System I
(Legacy)
System II
Figura 3.3 - Comunicazione di tipo Request-Response
In conclusione di quanto detto sinora, SWIM dovrà permettere sia di
realizzare gli scenari visti sopra e, laddove l’uso di un semplice pattern di
comunicazione non sia sufficiente, di combinare i diversi pattern.
Si possono quindi avere sistemi che:
• utilizzano il solo meccanismo di comunicazione Publish-Subscribe;
• utilizzano il solo meccanismo di comunicazione Request-Response;
98

• combinano entrambi i meccanismi di comunicazione
Request-Response (sincrono) e Publish-Subscribe (asincrono).
In particolare quest’ultimo scenario definisce il principale schema di
interazione tra i sistemi ATM, che prevede prima una fase sincrona con
comunicazione di tipo Request-Response seguita poi da una fase asincrona
di tipo Publish-Subscribe così come evidenziato nel seguente Sequence-
Diagram. Infatti sono diversi gli scenari ATM prevedono la pubblicazione
di dati aggiornati o nuovi, in seguito alla chiamata sincrona di un particolare
servizio.
sd ATM Systems
System A System B Another System
do_operation(a_param)
«Response»
Publish(some_data)
«Publication»
Publish(some_data)
«Publication»
Figura 3.4 - Schema Generale d’Interazione
Secondo la definizione dei Ruoli vista precedentemente, un generico
sistema ATM_A richiede attraverso una chiamata sincrona un’operazione
99

ad un secondo sistema ATM_B che eseguirà l’operazione il cui effetto sarà
la modifica di uno o più dati che verranno di seguito pubblicati e quindi
inoltrati ad un certo numero di sistemi che si erano precedentemente
sottoscritti a quel tipo di dato.
Nei documenti di SWIM che analizzano le tecnologie oggi disponibili, per
l’interconnessione e lo scambio di informazioni tra i vari sistemi ATM si fa
esplicito riferimento a tecnologie quali Data Distribution Service ( DDS ) e
Java Message Service ( JMS ).
Entrambe le tecnologie hanno l’obiettivo di definire un meccanismo di
condivisione dei dati tra sistemi distribuiti che consenta la comunicazione
tra sistemi eterogenei in modo efficiente e flessibile. Questa proprietà è resa
possibile dall’adozione del modello di comunicazione di tipo data-centric, il
cui esempio tipico è la memoria distribuita condivisa che può essere
paragonata al nostro Spazio Globale dei Dati.
P
P
Publishers
Global Data Space
T 1
T 3
T 2
Figura 3.5 - Global Data Space
S
S
S
S
Subscribers
Piuttosto che configurare i nodi client oppure definire metodi che
permettono di accedere a dati od a oggetti remoti, il paradigma data-centric
comporta che lo sviluppatore controlli direttamente lo scambio di
100

informazioni. Compito degli sviluppatori diventa quindi definire un
“dizionario dei dati” che modelli il sistema come un insieme di attori che
necessitano di accedere a determinate informazioni ( chi ha bisogno di
cosa).
Il DDS rappresenta uno standard maturo ampiamente utilizzato in diversi
domini applicativi e che ben si adatta allo sviluppo di un prototipo
middleware per la gestione del traffico aereo[6]. In particolare si adatta bene
ai sistemi distribuiti real-time in quanto permette la configurazione di
opportune politiche di QoS.
Per lo sviluppo di un’applicazione test nell’ambito del presente lavoro di
tesi, si è scelto di utilizzare il Framework JMS in ambiente jBoss, le cui
caratteristiche saranno discusse nel prossimo paragrafo.
3.3 – Java Message Service
3.3.1 – MOM : Modello Orientato ai Messaggi
MOM è una delle tecnologie chiave per la costruzione di sistemi su larga
scala e di tipo Enterprise. Rappresenta una sorta di collante per mettere
insieme più applicazioni o sistemi autonomi ed indipendenti in un singolo
sistema integrato e coerente.
Nel modello MOM, la comunicazione tra i processi è di tipo peer-to-peer
cioè tra pari, di tipo produttore-consumatore e prevalentemente asincrona,
sebbene alcune implementazioni consentano anche uno scambio di
messaggi di tipo sincrono.
Un sistema di Messaging può essere realizzato piazzando semplicemente
una coda tra sistemi sender e receiver realizzando così un’astrazione di un
canale di comunicazione tra processi interoperanti. Il Sender può inviare un
101

messaggio ad un Receiver senza sapere se il messaggio è stato consegnato
per cui dopo aver consegnato il messaggio al middleware MOM
incaricandolo della consegna dello stesso, può continuare liberamente il suo
lavoro. Il sender quindi non ha modo e necessità di conoscere quali processi
riceveranno il messaggio inviato.
Figura 3.6 - MOM Comunicazione tramite code di messaggi
MOM è spesso implementato come un server che può gestire i messaggi di
più client eseguiti concorrentemente. I senders piazzano i messaggi nella
coda mentre i receivers li rimuovono. Un server di tipo MOM può creare e
gestire più code di messaggi e su ogni coda più sistemi possono inviare i
propri messaggi e più receivers possono prelevari. Ogni coda ha un nome
che sia i sender che i receiver devono specificare quando eseguono le
proprie operazioni di invio e prelievo.
Un server di tipo MOM quando accetta un messaggio da una certo sistema,
deve inviare un acknowledgement per indicare che il messaggio è stato
correttamente ricevuto. Successivamente, il server deve memorizzare il
messaggio nella particolare coda che il sender ha specificato. Inoltre un
102

sender può inviare parecchi messaggi su una coda prima che un qualsiasi
receiver inizi a prelevarne, per cui un server MOM deve prevedere la
possibilità di dover memorizzare in una coda, parecchi messaggi per un
lungo periodo di tempo. I messaggi vengono poi consegnati ai receivers
secondo una politica First-In-First-Out ( FIFO ) cioè secondo il loro ordine
di arrivo. Quando un receivers richiede un messaggio, il messaggio in testa
alla coda gli viene consegnato, e solo successivamente il messaggio viene
rimosso dalla coda.
Da quanto abbiamo detto è evidente che un MOM realizza una sorta di
comunicazione di tipo one-to-one in quanto un singolo sender invia un
singolo messaggio ad una singola coda ed un receiver recupera quel
messaggio dalla coda e lo consuma. Evidentemente questo meccanismo
abbastanza limitato non consente di risolvere tutti i tipi di problemi.
Ed allora è possibile estendere MOM con il paradigma di comunicazione di
tipo Publish-Subscribe.
Il Publish-Subscribe estende il semplice MOM introducendo meccanismi
per la comunicazione di tipo 1-to-many, many-to-many, many-to-1. Un
publisher invia un singolo messaggio su un certo Topic. Un Topic è un
nome logico rappresentativo di un certo tipo di informazioni, che a livello di
MOM si mappa con una coda. I sistemi interessati a quel tipo di
informazioni, devono allora sottoscriversi preventivamente a quel Topic al
fine di poter ricevere i relativi messaggi. Ed allora un subscriber dopo
essersi sottoscritto, si mette in ascolto su quel Topic in attesa che qualche
sistema pubblichi un messaggio. Il Server ha il compito poi di distribuire
ogni messaggio inviato a tutti i subscriber che sono in ascolto sul Topic
specificato nel Messaggio.
103

Figura 3.7 - Publish-Subscribe Messaging
Il meccanismo Publish-Subscribe ha una serie di proprietà: Senders e
Receivers sono disaccoppiati ed ognuno di essi non ha conoscenza di quale
sistema ha inviato il messaggio o di chi lo riceverà. Ogni Topic può aveve
più di un sistema Publisher e ciascuno può apparire e sparire dinamicamente
conferendo al sistema una grossa flessibilità. Allo stesso modo, i
subscribers possono sottoscriversi e cancellarsi da un Topic in qualsiasi
momento ed in maniera trasparente agli altri sistemi.
Il Messaging Server ha poi la responsabilità di gestire i Topic, di tenere
traccia di quali subscribers sono in ascolto su ogni Topic, ed ha la
responsabilità di consegnare i messaggi a tutti i subscriber attivi. I Topic
possono essere persistenti o meno intendendo con ciò la possibilità di
consegnare i messaggi in maniera affidabile.
104

3.3.2 – JMS
Java Message Service è l’insieme di API Java che consentono lo scambio di
messaggi tra applicazioni Java distribuite sulla rete. La prima specifica JMS
è stata rilasciata nel 1998, mentre l’ultima versione delle API è la 1.1
pubblicata nel 2002. La specifica è scaricabile gratuitamente dal sito della
sun [1].
In ambito JMS, un messaggio è un oggetto contenente un raggruppamento
di dati che viene inviato da un sistema ad un altro. I dati sono solitamente
utilizzati per notificare eventi e sono pensati per essere utilizzati da un
programma su una macchina e non direttamente da un utente umano.
In un scenario distribuito un messaging service può essere pensato come un
sistema distribuito di notifica di eventi. In particolare con il termine
messaging ci si riferisce ad un meccanismo che consente la comunicazione
asincrona tra client remoti:
• Un client invia un messaggio ad un ricevente ( o ad un gruppo di
riceventi );
• Il destinatario riceve il messaggio ed esegue le operazioni
corrispondenti in un secondo momento.
E’ basato su paradigma peer-to-peer: un client può ricevere e spedire
messaggi a qualsiasi altro client attraverso un messaging provider ( server ).
Permette quindi una comunicazione distribuita ad accoppiamento lasco nel
senso che tutto ciò che un sender ed un receiver devono conoscere sono il
formato ( message format ) e la destinazione ( destination ) del messaggio.
Il messaging server provvederà a consegnare il messaggio in maniera
105

asincrona ed affidabile, cioè la consegna del messaggio sarà fatta una sola
volta e senza alcun rischio di perdere informazioni.
Per quanto riguarda l’architettura di JMS-API, si possono identificare i
seguenti oggetti:
1. JMS Client: sono le applicazioni JAVA che producono o consumano
messaggi;
2. Message: sono gli oggetti che incapsulano le informazioni che i
client vogliono scambiare.
3. JMS Provider: è il messaging system, cioè quello che implementa
JMS e realizza la funzionalità di controllo della
comunicazione;
4. Administered Object: sono oggetti preconfigurati, creati da un
amministratore ad uso dei client. Incapsulano la logica specifica del
JMS Provider nascondendola ai client garantendo così maggiore
portabilità al sistema complessivo.
Figura 3.8 - JMS API Architecture
106

Sostanzialmente ci sono 2 tipi di Administerd Object:
• Una Connection Factory è un oggetto utilizzato da un client per
realizzare la connessione con il messaging provider ( entry point al
messaging service ).
• Una Destination ( Queue/Topic ): oggetto utilizzato da un client per
specificare la destinazione del messaggio che invia o l’origine del
messaggio che riceve.
La creazione di ConnectionFactory e di Destination non è gestita da
programma, ma bensì è compito dell’amministratore JMS che mediante un
opportuno Administrative Tool deve inserirli all’interno di un contesto
JNDI in un opportuno namespace in modo che possano essere recuperati da
qualsiasi client mediante le normali API JNDI ( servizio di lookup ).
Per inviare messaggi ( sender o publisher ) o per riceverli (receiver o
subscriber ), un’applicazione JMS client utilizza i servizi JNDI per ottenere
un oggetto di tipo ConnectionFactory e uno o più oggetti di tipo Destination
( Queue o Topic ).
Per quanto riguarda i modelli di messaging ( i cosiddetti Domini ), sono
previsti due diversi meccanismi:
1. Point-To-Point:
• Più client JMS possono condividere la stessa
destination(Queue);
• Un messaggio può essere consumato da un solo destinatario;
• Permette una comunicazione one-to-one.
107

2. Publish/Subscribe:
• Un messaggio inserito nella destination ( Topic ) può essere
inviato a tutti i destinatari ( subscriber ) che si sono dichiarati
interessati a riceverlo;
• Consente una comunicazione 1-to-many e many-to-many.
Il modello di messaggistica PtP o P2P si basa sui concetti di coda, mittente
( Sender o Producer ) e destinatario ( Receiver o Consumer ).
Figura 3.8 - Point-to-Point Messaging
Ogni Client JMS spedisce e riceve messaggi sia in modalità sincrona che
asincrona attraverso dei canali virtuali che sono code. Il modello PtP ha le
seguenti caratteristiche:
i. Più produttori e più consumatori possono condividere la stessa coda,
ma….
ii. Ogni messaggio ha solamente un “consumer”, ovvero ogni
messaggio può essere letto da un solo client.
108

iii. Sender e Receveir non hanno nessuna dipendenza temporale. Il
Receiver può prelevare il messaggio anche se non era attivo quando
il Sender l’ha inviato.
iv. Il Receiver notifica l’avvenuta ricezione e processamento del
messaggio (acknowledge).
v. Sono previsti meccanismi che gestiscono la priorità dei messaggi.
In conclusione PtP è utile quando è necessario garantire che un messaggio
sia processato con successo da un solo Consumer.
Il modello di messaggistica PtP o P2P si basa sui concetti di Topic, mittente
( Sender o Producer ) , destinatario ( Receiver o Consumer ) e
Sottoscrizione.
Figura 3.9 - Publish-Subscribe Messaging
Nel modello Pub/Sub il Producer può inviare un messaggio a molti
Consumer ( one-to-many ), attraverso un canale virtuale chiamato Topic. Il
modello Publish-Subscribe ha le seguenti caratteristiche:
109

i. Uno stesso Topic può essere condiviso da più consumer ed utilizzato
ii. Per ricevere i messaggi
i Consumer devono sottoscriversi ad un
iii. Qualsiasi messaggio inviato su quel Topic viene consegnato a tutti i
iv. Non c’è dipendenza tra Producer e Consumer; è il JMS Provider che
v.
da più publisher.
Topic. I Consumer ( Subscriber ) manifestano in questo modo il loro
interesse per quel tipo di messaggi.
consumer sottoscritti.
realizza l’operazione di dispatching dei messaggi a tutti i subscriber.
Publisher e Subscriber generalmente restano anonimi così che
entrambi possono dinamicamente aggiungersi o eliminarsi.
vi. I Publisher ed i Subscriber hanno però una dipendenza temporale:
• Un receiver che si sottoscrive ad un Topic può consumare
solamente messaggi pubblicati dopo la sua sottoscrizione.
• Il subscriber può continuare a consumare messaggi solo nel
periodo in cui rimane attivo. Durante il periodo di inattività i
messaggi che dovesse ricevere andrebbero persi. Per ovviare
a questo problema il Client JMS può usare una
sottoscrizione “durevole”, che gli consente di disconnettersi e
riconnettersi in un secondo momento consumando messaggi
pubblicati durante il periodo di assenza.
vii. Un Subscriber ha due modi per specificare i messaggi che è
interessato a ricevere:
• Topic-Based:
le informazioni vengono suddivise in
argomenti (Topic); le sottoscrizioni e le pubblicazioni
vengono fatte identificando il Topic a cui il messaggio è
110

viii.
associato. Il Topic quindi rappresenta il canale logico che
connette i publisher ai subscriber.
• Content-Based: si utilizzano dei filtri che attraverso delle
• SINCRONA: il subscriber preleva direttamente il messaggio
• ASINCRONA: il client si registra
presso un message listener
Per
concludere si mostra nella seguente figura il modello programmatico di
ii.
• Connection Factory;
v. Message Producer;
condizioni booleane sui parametri del messaggio permettono
una selezione più accurata delle informazioni da ricevere.
Un messagio JMS può essere consumato secondo due modalità:
dalla coda ( operazione di fetch del messaggio ), tramite
l’invocazione del metodo receive(). Il metodo è bloccante, il
client rimane bloccato finchè non arriva il mesaggio o fino
allo scadere di un timeout.
attraverso un oggetto consumer. Se un messaggio arriva alla
destinazione, il JMS provider consegna il messaggio
chiamando il metodo onMessage() del listener.
JMS-API. Gli oggetti coinvolti sono :
i. Administered Odject;
• Destination;
Connection;
iii. Session;
iv. Message;
vi. Message Consumer;
111

Figura 3.10 - JMS API Programming Model
Per
ulteriori approfondimenti e per gli aspetti tecnici si rimanda al
Capitolo31 del Tutorial ufficiale [28].
3.4
– Definizione di un Information Model per l’ATM
Per quanto detto nei capitoli precedenti, il mondo ATM necessita
di un
infrastruttura che permetta di scambiare informazioni ai molti sistemi
coinvolti. Così come per tutti i sistemi realizzati su larga scala, anche per il
dominio ATM la gestione dei dati diventa molto complessa. In uno scenario
così eterogeneo, caratterizzato da svariati stakeholders autonomi ed
operativi in differenti sottodomini dello stesso dominio, lo scambio di dati
in maniera efficiente che disaccoppi tali sistemi al fine di renderli
interoperabili, rappresenta una delle principali caratteristiche
112

dell’infrastruttura di integrazione. A tale scopo è necessario che le
informazioni dei diversi domini vengano modellate sia strutturalmente sia
semanticamente, definendo una unica e condivisa visione dei dati .
Per alcuni dei Data Domain che caratterizzano l’ATM nella sua totalità, da
alcuni anni a questa parte si sta cercando di definire uno standard per la
struttura dei dati. Ad esempio, per il dominio dei piani di volo ( Flight
Plan Data Domain – FDD ) la struttura standard è stata definita da
ICOG[29].
Arrival
arrival_data : Arrival
Departure
departure_data : DepartureData
DepartureClearance
departure_clearance : DepartureClearance
ATSUsDistributionList
distribution_list : DistributionList
FlightPlanInfo
(from Indra Distribution Clust...
flight_plan : FlightPlan
Coordination
coordination_and_transfer_data : CoordinationAndTransfer
FlightPlanData
flight_plan : FlightPlan
DistributionCluster
release_id : ReleaseID
FOIPS_checksum : Integer
Aircraft
aircraft : Aircraft
FlightKey
flight_key : OperationalIdentifier
Figura 3.11 - ICOG : Distribution Cluster
Script
flight_script : FlightScript
SSR
assigned_SSR_code_and_mode : SSRCode
next_SSR_code_an_mode : SSRCode
next_SSR_code_status : NextSSRCodeState
FlightIdentification
flight_identification : FlightIdent
fo_release_id : FOReleaseID
environment_release_id : ReleaseID
Trajectory
trajectory : Trajectory
IOPInformation
iop_specific_data : FlightIOPInformation
Come
si vede dalla figura di cui sopra con ICOG l’insieme di tutte le
informazioni sono raccolte all’interno di un oggetto, il Flight Object ( FO )
113

che costituisce la principale informazione del dominio . In altri termini tale
Flight Object contiene tutti i dati di un piano di volo. All’interno di tale
Flight Object le informazioni vengono ulteriormente suddivise in
raggruppamenti di dati fortemente coesi, detti Cluster. Qui di seguito si
elencano i vari Cluster e le relative informazioni in essi contenute:
• Aircraft: tale cluster contiene tutti i dati relativi ad un velivolo, come
il suo identificativo ( arcid ), il tipo ed i dati relativi ad eventuali
situazioni di emergenza;
• Script: contiene l’insieme delle informazioni di base per la gestione
della traiettoria, quali condizioni meteo, velocità, aerodromo di
partenza( adep ) ed aerodromo di arrivo ( ades );
Figura 3.12 - Script Class Diagram
114

•
FlightIdentification: contiene informazioni utili per l’identificazione
del volo. In particolare questo cluster opzionalmente può identificare
il volo prelevando ed elaborando informazioni contenute in altri
cluster come per esempio adep, ades, arcid etc… ;
Figura 3.13 - FlightIdentification Class Diagram
115

• Trajectory: contiene informazioni circa la traiettoria del volo; in
questo contesto la traiettoria è vista come una sequenza di punti. Tra
questi ci sono alcuni punti più significativi, i cosi detti boundary
point che stanno a rappresentare i punti di confine tra le zone ( in
ICOG Volumi ) che sono attraversate dalla traiettoria. Più avanti
caratterizzeremo maggiormente la suddivisone dello spazio aereo in
volumi.
Figura 3.14 - Trajectory Class Diagram
• IOPInformation: contiene informazioni specifiche
per
l’interoperabilità dei sistemi;
116

• FlightKey: contiene le informazioni relative alla chiave del Volo
•
come ad esempio adep, ades, arcid etc… ;
Figura 3.15 - FlightKey Class Diagram
Departure: contiene informazioni relative alla partenza;
• Arrival: contiene informazioni relative all’arrivo;
• DepartureClearance: contiene le informazioni
riguardanti le
autorizzazioni alla partenza del volo;
117

• FlightPlanData: contiene informazioni generali relative al piano di
volo come ad esempio adep, ades, arcid, aircrafttype,etc…;
Figura 3.16 - FlightPlanData Class Diagram
• DistributionList: contiene informazioni circa i sistemi che sono
interessati a conoscere il FO;
Tali Cluster possono comunemente essere
anche detti Distribution Cluster
proprio
per evidenziare che ciascuno di essi rappresenta l’unità minima di
trasferimento di porzioni di Flight Object tra i sistemi interessati a
118

condividere informazioni per la gestione di un determinato volo. In
particolare ciascun Flight Object può essere costituito di al più di tredici
Cluster nel senso che, non necessariamente in ogni Fight Object devono
essere contenuti tutti i cluster che si sono definiti.
Dall’analisi attenta dei Class Diagram di ogni cluster si evince che le
informazioni incapsulate in ciascun cluster sono spesso correlate a dati
contenuti in altri cluster. In particolare si evidenziano dipendenze
tipicamente semantiche del tipo che uno stesso concetto di dominio è
presente, magari in forma diversa, in più cluster. Ancora, alcune
informazioni contenute in alcuni cluster sono ottenute mediante fusione,
integrazione o elaborazione di informazioni contenute in altri cluster. Questi
aspetti appena evidenziati non vengono esplicitamente modellati in ICOG.
In pratica molte informazioni sono deducibili solo da un elaborazione sui
dati. Secondo la visione ATM di ICOG, tale elaborazione risiede nei sistemi
legacy che opportunamente operano sui dati di domino per astrarre
conoscenza a partire dai dati. Sebbene la definizione di una struttura
standard dei dati del dominio FDD, ed in generale di ogni dominio ATM, è
fondamentale per il progetto SWIM-SUIT, emergono tuttavia ulteriori
concetti che è opportuno includere nei modelli dei dati, al fine di creare un
infrastruttura a supporto degli scenari operativi del mondo ATM.
Dall’analisi del dominio emerge, infatti, anche la necessità di definire Ruoli,
Regole e Responsabilità per la gestione consistente del Flight Object, alla
stregua di come se ne è discusso nel primo paragrafo di questo capitolo.
Questi aspetti, che sono di rilevante importanza, ancora non sono
formalizzati in alcun modo.
119

Altro gap semantico che bisogna colmare riguarda i meccanismi che
regolano la distribuzione dei dati. All’interno di ICOG e soprattutto nel
contesto di SWIM manca la conoscenza necessaria per realizzare il
dispaching dei dati che quindi è una responsabilità che viene demandata ai
sistemi utenti esterni a SWIM.
In conclusione, questo primo passo di standardizzazione per quanto
importante sia non è sufficiente
per affrontare, nel contesto del sistema
SWIM, problematiche quali la definizione di ruoli, un efficiente
disseminazione dei dati ed il mantenimento della consistenza del Flight
Object. Ed allora, al fine di realizzare la piena integrazione di sistemi che
generano e che devono condividere informazioni fortemente eterogenee ma
intrinsecamente non completamente indipendenti, risulta necessario
modellare ulteriormente i dati accompagnandoli con dei meta-dati. Tali
meta-dati vanno a definire uno schema concettuale ( l’information model )
il cui obiettivo è quello di accompagnare la struttura dei dati definita in
ICOG con una chiara definizione semantica degli stessi, delle loro eventuali
correlazioni, e degli aspetti che possono agevolarne la gestione, la
manipolazione e la distribuzione.
Il presente lavoro di tesi, come
vedremo dettagliatamente nell’ultimo
capitolo,
cerca di modellare non solo strutturalmente ma soprattutto
semanticamente il dominio dei piani di volo, definendo un’ontologia OWL
che intrinsecamente racchiuda quella conoscenza in più sul dominio
necessaria ai sistemi ATM per poter interoperare pienamente e
correttamente.
120

Capitolo 4
Definizione di un Information Model basato su
4.1 – Introduzione
Ontologia per il sistema SWIM
In questo quarto capitolo verranno definiti gli scenari dei casi d’uso che si
intende affrontare. In particolare ad ogni volo è associato un Flight Object e
tale Flight Object deve essere condiviso tra tutti gli stakeholders ad esso
interessati. Il primo scenario riguarda la creazione della distributionList per
quella particolare istanza di Flight Object ossia della lista di tutti gli
stakeholders del sistema SWIM interessati a ricevere informazioni su quel
volo. Il secondo scenario riguarda invece il Mapping dei Ruoli per
quell’istanza di Flight Object, cioè l’attribuzione ad ogni stakeholder
presente nella distributionList di un ruolo: ogni stakeholder in base al ruolo
può svolgere determinate operazioni su un determinato Flight Object. Il
terzo ed ultimo scenario riguarda invece l’individuazione della presenza di
alcune delle correlazioni tra i cluster che compongono un Flight Object.
121

Da un’analisi di questi scenari e dallo studio del modello di ICOG che
definisce la struttura dei dati di volo, si procede alla presentazione del
processo che porta alla definizione di uno schema ontologico
che racchiude
la conoscenza necessaria per la risoluzione degli scenari proposti. In
conclusione si presenta l’applicazione che implementa gli scenari facendo
uso del modello
ontologico e si discuteranno i risultati ottenuti.
4.2 – Scenari Considerati
4.2.1 – Calcolo della lista di distribuzione dei dati di volo
In base alla definizione degli scenari operativi di SESAR, la traiettoria di
business ( business trajectory – BT ) è la principale informazione a cui tutti
gli attori coinvolti nell’ATM devono fare riferimento durante tutte le fasi del
loro ciclo di vita. La traiettoria
di business rappresenta una sintesi dei dati
che possono favorire od ostacolare lo svolgimento normale del volo. In
particolare l’approccio trajectory-based richiede la condivisione sistematica
delle traiettorie degli aeromobili tra i vari partecipanti al processo di
gestione del traffico aereo al fine di garantire che tutti i partner abbiano una
visione comune di un volo e possano accedere agli aggiornamenti
disponibili per svolgere in maniera affidale i loro compiti. SESAR assume,
pertanto, l’esistenza di un meccanismo in grado di permettere la
condivisione della traiettoria tra i vari sistemi ATSU o ACC che ne sono
interessati così come mostrato nella seguente figura.
.
122

Figura 4.1 - Trajectory
Dalla figura 4.1 emerge che a ciascun sistema ASTU o ACC è associata una
certa regione dello spazio aereo. Ed allora il sistema in questione è
interessato a ricevere le informazioni riguardo tutti i voli le cui traiettorie
attraversano l’area ad essi associata.
Figura 4.2 - Aree associate ai sistemi
123

La figura 4.2 evidenzia nuovamente che lo spazio aereo è partizionato in un
certo numero di aree o volumi, e ciascuna di esse rappresenta l’insieme di
voli ed in particolare dei dati di quei voli che il corrispondente sistema è
interessato a ricevere. In questo scenario è evidenziato allora anche quello
che è il ruolo del sistema SWIM, che quindi rappresenta il collante tra i vari
sistemi, cioè l’infrastruttura mediante la quale i sistemi condividono le
informazioni.
Per capire meglio come è gestita la traiettoria andiamo a vedere come lo
spazio aereo viene suddiviso.
Figura 4.3 - Illustrazione delle Aree
Vengono definite un certo numero di aree che governano la distribuzione
del Flight Object e come vedremo nel paragrafo successivo, regolano anche
l’attribuzione dei ruoli. In particolare si definiscono:
• Area di Responsabilità – AoR (in blu): è il volume di spazio aereo in
cui i voli che lo attraversano si trovano sotto il controllo del
124

corrispondente sistema Acc. In particolare l’insieme di tutte le AoR
risulta essere un partizionamento dell’intera IOP Area.
• Area di Interesse – AoI (in verde): è il volume di spazio aereo per il
quale il corrispondente sistema Acc ha necessità di avere
informazioni riguardo tutti voli che lo attraversano. Come è evidente
nella figura, ciascun AoI associata ad un sistema, contiene
interamente l’AoR associata allo stesso sistema.
• IOP Area (in rosa): è il volume di spazio aereo in cui il Flight Object
è usato per la distribuzione
dei dati di volo tra i partecipanti. In
particolare la IOP Area risulta essere la somma di tutte le AoR.
Nel contesto di ICOG, ogni porzione di spazio aereo, per quanto grande essa
sia, viene genericamente definita “ATCVolume”. Dunque secondo questa
definizione, tutte le aree appena introdotte sono dei Volumi. Esistono però
anche altri tipi di Volumi, i cosiddetti “Sector” che sono un ulteriore diverso
partizionamento della IOP Area. Proprietà importante che caratterizza tali
Sector è che ognuno di essi è completamente contenuto in AoR, e cioè, per
essere più precisi, un Sector non può intersecare due AoR. Discorso
contrario vale invece riguardo le AoI, nel senso che un Sector può
intersecare più AoI. Per finire va specificato che nel contesto
dell’ATM i
volumi
definiti sono fissi, cioè i loro limiti, la loro posizione nella IOP Area
e le loro estensioni geografiche sono stati fissati a priori, ed ancora bisogna
specificare che tra un sistema Acc e la corrispondente AoR, e di
conseguenza la AoI, vi è un rapporto di “uno-a-uno”.
125

Figura 4.4 - Corrispondenza Sistemi - Aree
Riprendendo a questo punto la definizione di trajectory fatta in ICOG nel
capitolo precedente, alla luce del particolare partizionamento dello spazio
aereo appena descritto, in un oggetto trajectory, i “boundary point” sono i
punti della traiettoria che cadono sul confine tra due Sector.
Figura 4.5 - Trajectory Boundary Point
126

Nel contesto appena descritto, lo scenario d’uso che andiamo a considerare
si articola nei seguenti passi:
1. Ciascun sistema Acc sì è sottoscritto ad una certa AoR e di
conseguenza alla corrispondente AoI;
2. ci troviamo a Creation Time, cioè il Flight Object è stato appena
creato dal Manager;
3. c’è l’esigenza di condividere tale Flight Object al fine di permettere
a tutti i sistemi ad esso interessati di svolgere le loro normali
funzioni;
4. il Manager per poter distribuire il Flight Object necessita
di
conoscere la distributionList associata a quel FlightObject.
5. Ottenuta la distributionList, il manager procede all’invio del Flight
Object attraverso l’operazione di pubblicazione.
Dunque
il problema da risolvere è ottenere la distributionList.
Pe r quanto detto riguardo il dominio dei piani di volo la distributionList
associata ad una certa istanza di FlightObject sarà la lista di tutti i sistemi
Acc la cui corrispondente AoI è attraversata dalla particolare traiettoria
prevista per il volo ( per esempio nella figura 4.5 i sistemi interessati al volo
sono il sistemi 1, 2, 4 ).
Gli scenari operativi attuali prevedono che tale distributionList venga
incapsulata nel Flight Object, e quindi passata al Manager, da un sistema
legacy direttamente connesso al Manager. Nello scenario che
andremo a
modellare, invece, porteremo parte della conoscenza del dominio
all’interno dell’ infrastruttura SWIM-SUIT, al fine di realizzare il calcolo
della distributionList in maniera automatica.
127

4.2.2 – Definizione dei Ruoli a partire dai dati
Come è stato già detto in precedenza, in ICOG al fine di garantire una
gestione
consistente dei dati e quindi del Flight Object , sono stati definiti
un certo numero di ruoli che governano le responsabilità
di ciascun sistema
rispetto
ai Flight Object.
Per ogni Flight Object, i possibili
ruoli individuati sono:
1. Publisher: responsabile della distribuzione del Flight Object ai
sistemi interessati a condividere le informazioni in esso contenute, e
che vi sono
state inserite dal Manager.
2. Manager: responsabile della consistenza del particolare Flight
Object. Esso riceve le richieste di aggiornamento
dai vari
Contributors e realizza i necessari processi per il mantenimento della
coerenza e della consistenza delle informazioni contenute
nel Flight
Object di cui è responsabile.
3. Contributor: la sua responsabilità è quella di settare le informazioni
e renderle disponibili al Manager affinché questi le consolidi
all’interno del Flight Object.
4. User: si sottoscrive ad una partizione dell’intero insieme di Flight
Object e riceve gli aggiornamenti pubblicati dal publisher.
Successivamente, i ruoli di manager e publisher sono stati fusi, per cui nel
prosieguo della trattazione parleremo sempre e solo di manager.
Come già anticipato brevemente nel paragrafo precedente, il meccanismo di
attribuzione dei ruoli dipende dalla traiettoria e da come questa si va a
mappare sui volumi corrispondenti ai vari sistemi.
128

Ed allora nello stesso contesto descritto nel paragrafo precedente, lo
scenario d’uso che andiamo a considerare si articola nei seguenti passi:
2. Ci troviamo a Creation
Time, cioè l’istanza di Flight Object in
Dunque il problema da risolvere è calcolare
la contributorList e la userList.
Per
1. Ciascun sistema Acc sì è sottoscritto ad una certa AoR e di
conseguenza alla corrispondente AoI;
questione è stata appena creata dal Manager;
3. Il Manager, in possesso della distributionList, ha la necessità di
attribuire a ciascun sistema interessato, un ruolo che ne regoli le
responsabilità.
4. Ottenuta la contributorList e la userList, rispettivamente la lista dei
sistemi contributor e dei sistemi user per il Flight Object, il manager
provvede a comunicarlo ai sistemi direttamente interessati.
quanto detto riguardo il dominio dei piani di volo, la contributorList
associata
ad una certa istanza di FlightObject sarà la lista di tutti i sistemi
Acc la cui corrispondente AoR è attraversata dalla traiettoria prevista per il
volo
( per esempio nella figura 4.5 i sistemi contributor per il Flight Object
associato a quel volo sono i sistemi 1, 2 ). Per quanto riguarda invece la
userList associata allo stesso Flight Object, questa sarà la lista di tutti i
sistemi Acc per i quali è attraversata dalla traiettoria unicamente la AoI. In
termini
matematici, la userList è il complemento della contributorList
rispetto alla distributionList ( per esempio nella figura 4.5 il sistema user
per il Flight Object associato a quel volo è il sistema 4 ).
Gli scenari operativi attuali prevedono che la gestione
dei ruoli venga
eseguita dagli stessi sistemi legacy , ossia ogni sistema legacy è autorizzato
129

a registrarsi secondo un determinato ruolo Nello scenario che andremo a
modellare, invece, porteremo la gestione dei ruoli all’interno di SWIM-
SUIT, e quindi il calcolo sia dellla contributorList, sia della userList verrà
eseguito in maniera automatica in base alla natura
stessa dei sistemi ACC.
4.2.3 – Correlazioni tra i cluster dei dati di volo
Come descritto nell’ultimo paragrafo del capitolo precedente, in ICOG i dati
riguardanti i piani di volo, sono organizzati in Cluster ciascuno dei quali
rappresenta l’unita minima
di trasferimento dei dati in SWIM-SUIT.
Dall’analisi
attenta dei Class Diagram di ogni cluster si evince che le
informazioni
incapsulate in alcuni cluster possono dipendere o essere
correlate ad informazioni contenute in altri cluster. In particolare
si
evidenziano
dipendenze tipicamente semantiche del tipo che uno stesso
concetto è contenuto in più cluster o ancora che alcune informazioni
rappresentate in alcuni cluster sono ottenute mediante fusione, integrazione
o elaborazione di informazioni contenute in altri cluster. Questi aspetti non
essendo modellati in maniera esplicita, anche se risultano chiari ad un
umano, non sono altrettanto deducibili da una macchina.
In questo contesto, lo scenario d’uso che andiamo a considerare si articola
nei seguenti passi:
1. un sistema manager di un Flight Object, riceve una versione
aggiornata di uno dei cluster che compongono un dato Flight Object;
2. il manager, allo scopo di tenere consistente lo stato dell’intero Flight
Object, deve ottenere un lista di quelle che sono le correlazioni di
ogni tipo di quel cluster con i rimanenti cluster che compongono il
Flight Object;
130

3. ottenuta la lista di queste correlazioni o dipendenze, deve quindi
provvedere al riallineamento delle informazioni contenute nei vari
cluster;
4. il manager procede nuovamente all’invio del Flight Object
attraverso l’operazione di pubblicazione così da aggiornare anche le
copie del Flight Object degli altri sistemi.
Dunque, in seguito all’aggiornamento ed alla ripubblicazione dei dati
appartenenti ad un dato cluster, risulta necessario aggiornare e quindi
ripubblicare ulteriori cluster. Per quanto detto nella parte che riguarda
ICOG, queste relazioni non sono esplicitamente modellate e quindi la lista
delle dipendenze può essere ottenuta solo attraverso un’attenta analisi
semantica delle informazioni contenute nei cluster.
In conclusione ad oggi i sistemi legacy conoscono quali sono le porzioni di
dato che gestiscono e quali sono i legami con altre informazioni, che magari
possono appartenere anche a domini diversi. Tale conoscenza resta però
proprietaria dei diversi sistemi legacy e pertanto non rappresenta una
conoscenza condivisa. Esplicitare i legami semantici tra i diversi cluster del
Flight Object quali duplicazioni di uno stesso dato
in più cluster o
addirittura in domini differenti, o ancora relazioni d’uso tra cluster nel senso
che alcuni dati complessi
contenuti in un dato cluster sono ottenuti per
fusione
o elaborazione di dati più semplici contenuti in altri cluster,
rappresenta
un valore aggiunto al modello dei dati di ICOG e permette
all’ infrastruttura SWIM-SUIT di gestire la consistenza delle porzioni di dato
del piano
di volo.
131

4.3 – Information Model
Lo studio
del documento di SWIM “Information Content and Service
Requirements” ed in particolare un’attenta analisi degli obiettivi e degli
scenari ufficiali contenuti in tale documento, alcuni dei quali evidenziati nel
paragrafo
precedente, hanno permesso di comprendere ed di modellare gli
aspetti importanti e l’organizzazione delle informazioni
che caratterizzano il
dominio dei piani di Volo.
Il risultato di questa lunga fase di studio ha condotto alla realizzazione
dell’ontologia OWL serializzata nel file “FDDdemoDraft2.owl”.
Nella figura sotto sono mostrate poche righe della parte iniziale
dell’Ontologia OWL definita. Ci si limita a visualizzarne una piccola parte
perché, il particolare formalismo risulta non facilmente comprensibile ad un
umano e quindi non restituisce nessuna informazione in più.
1
132

1
……….
Figura 4.6 - Estratto
Ontologia OWL
133

Una più chiara ed intuitiva interpretazione dell’ontologia realizzata si può
ottenere andando a mostrare l’output
del tool Protègè. Tale tool semplifica
le cose in quanto permette di lavorare
in ambiente grafico e non
con i
fo rmalismi del linguaggio owl, che essendo comprensibili dalle macchine,
no n lo sono altrettanto per gli umani.
Figura 4.7 - Tassonomia Information Model
134

Il modello mostrato nella figura di cui sopra visualizza la gerarchia dei
concetti attivi individuati nel dominio dei piani di volo. In particolare come
pre-annunciato si tratta di uno schema che riprende le scelte fatte in ICOG,
cioè contiene i concetti presenti nel modello di ICOG, andandoli ad
integrare con meta-dati che evidenziano per bene la natura delle
informazioni,
ne chiariscono il significato e quindi ne semplificano la
comprensione agli umani ed alle macchine.
Più nel dettaglio, tutte le classi figlie della classe padre ”owl:thing” sono i
concetti del dominio che hanno natura autonoma ed indipendente.
Un Dizionario dei Concetti del dominio presenti nell’Information Model è il
seguente :
• Velivolo;
• Piano di Volo;
• Volume ATC. Tale concetto come approfondito nel paragrafo sugli
scenari, necessita di essere ulteriormente specializzato nei seguenti
concetti:
• Area di Interesse – AoI;
• Area di Responsabilità – AoR;
• Sector;
• Distribution List;
• FligthIdent,
• Aerodromo;
• Flight Object;
• Boundary Point;
• Partenza;
135

• Arrivo;
• Chiave del Volo;
• Flight Script;
• StakeHolder;
• Trajectory;
• Cluster. Come approfondito precedentemente nel paragrafo che
definisce ICOG, un Flight Object è costituito di un sottoinsieme di
tutti i cluster definiti, ognuno contenente informazioni diverse. Di
conseguenza, tale concetto necessita di essere specializzato
ulteriormente nei concetti seguenti:
• ArrivalCluster;
• AircraftCluster;
• FlightPlanDataCluster;
• ScriptCluster;
• DistributionCluster;
E’ chiaro che scendendo nella gerarchia, si procede verso una
specializzazione dei concetti
individuati.
La definizione dei concetti
è accompagnata dalla definizione delle relative
proprietà. Grazie al tool Protègè
mostriamo nelle figure seguenti le proprietà
che sono modellate.
• FlightIdentificationCluster;
• FlightKeyCluster;
• DepartureCluster
• TrajectoryCluster;
136

In dettaglio, le proprietà sono di due tipologie:
• Datatype Properties:
le proprietà di questo tipo sono utilizzate per
modellare gli attributi
associati ai concetti;
• Object Properties:
le proprietà di questo tipo sono utilizzate per
modellare i collegamenti
logici o semantici tra i concetti.
In particolare, così come nel caso dei concetti, si riprendono le scelte fatte in
ICOG, andandole ad integrare con meta-dati che evidenziano per bene la
natura delle proprietà, ne chiariscono il significato e quindi ne semplificano
la comprensione.
Il modello mostrato nella figura
seguente visualizza la gerarchia delle
proprietà di tipo Datatype individuate.
Figura 4.8 - Tassonomia DataType Properties
Un Dizionario delle proprietà di tipo Datatype presenti nell’Information
Model è il seguente :
137

Proprietà Descrizione Concetti Coinvolti
AircraftType Associa al velivolo la Aircraft
sua tipologia
IOPIdentifier Associa ad un volo il suo FlightIdent
identificatore
ID Associa ad un oggetto il Areodrome
suo identificativo nel Flight Object
contesto SWIM – SUIT Aircraft
Cluster
StakeHolder
AtcVolume
Figura 4.9 - Dizionario DataType Properties
La tabella 4.9 contiene la lista delle proprietà (attributi) definite, una
descrizione del significato di ciascuna proprietà ed i concetti ai quali le
proprietà
si riferiscono.
Il modello mostrato nella figura seguente visualizza invece la gerarchia
delle proprietà di tipo Oggetto.
Figura 4.10 - Tassonomia Object Properties
138

Un Dizionario delle proprietà di tipo Oggetto presenti nell’Information
Model è il seguente :
Proprietà Descrizione Domain Range
hasArea Associa al
sistema ACC
le sue aree di
responsabilità
ed interesse
hasDCluster Associa al
Flight Object i
cluster di cui è
costituito
Uses Associa ad un
dato un altro il
dato da cui
viene calcolato
AoRisincludedAoI Associa ad un
AoR la
corrispondente
AoI in cui è
inclusa
includeSector Associa ad un
AoR un settore
in essa incluso
hasBoundaryPoint Associa alla
traiettoria un
BoundaryPoint
di cui è
costituita
Downstream Associa ad
ogni
BoundaryPoint
il settore di
provenienza
Upstream Associa ad
ogni
BoundaryPoint
il settore verso
cui si procede
ades Associa ad un
oggetto
l’aeroporto di
partenza del
StakeHolder AoI
AoR
ATCVolume\
Flight Object FlightKeyCluster
FlightIdentificationCluster
DistributionCluster
TrajectoryCluster
ScriptCluster
AircraftCluster
FlightIdent FlightKey
AoR AoI
AoR Sector
Trajectory BoundaryPoint
BoundaryPoint Sector
BoundaryPoint Sector
FlightKey Aerodrome
FlightPlanData
Script
139

volo
Adep Associa ad un
oggetto
l’aeroporto di
arrivo del volo
Arcid Associa ad un
oggetto il
velivolo
u tilizzato per il
volo
FlightKey Aerodrome
FlightPlanData
Script
Aircraft Aircraft
FlightKey
FlightPlanData
Figura 4.11 - Dizionario
Object Properties
La tabella 4.11 contiene la lista delle proprietà ( relazioni ) definite, una
descrizione del significato di ciascuna proprietà ed i concetti che le relazioni
va nno a collegare attraverso la definizione di dominio e condominio.
La successiva fase di modellazione prevede di assegnare le proprietà ai
rispettivi concetti dell’ontologia,
classi, e stabilendo il conseguente insieme di individui che possono
appartenere a ciascuna classe.
A questo punto del procedimento di modellazione si popolano le classi
dell’ontologia, istanziandone i relativi
individui. Pertanto, per il nostro
dominio di interesse, saranno istanziati
i diversi tipi di volumi quali AoR,
AoI e Sector, i Flight Object e le relative
Trajectory e tutti i restanti
concetti
precedentemente illustrati. Nel successivo
paragrafo, illustrando in dettaglio
lo scenario di interesse all’ applicazione sviluppata nel presente lavoro di
tesi, saranno mostrate tutte le istanze dell’ Information Model appena
sopra
descritto.
definendo quindi delle restrizioni sulle
140

4.3 – Applicazione
4.3.1 – Architettura
Il risulta to finale del lavoro di tesi è stato
lo sviluppo
di un’applicazione che
grazie all’integrazione delle varie tecnologie proposte,
realizzasse gli
scenari operativi proposti.
Nella figura 4.12 è mostrata la Component
and Deployment View
dell’applicazione, in cui si evincono gli elementi costituenti l’architettura
e
come
questi elementi sono dislocati in rete.
Figura 4.12 - Component and Deployment View
141

C’è un unico sistema Manager di due Flight Object che come abbiamo più
volte detto ricopre anche il ruolo di unico publisher per i due Flight Object e
ci sono quattro sistemi ACC che ricoprono il ruolo di subscriber per i due
FlightObject. Tali sistemi sono tutti disaccoppiati mediante l’infrastruttura
middleware realizzata dal servizio
JMS installato su JBoss . Inoltre vi è un
modulo che contiene l’ontologia ed il relativo Query Engine.
Nella figura 4.13 è mostrata anche l’architettura a livelli degli strati software
che compongono l’applicazione.
Figura 4.13 - Architettura a livelli dell’applicazione
142

Nella figura di cui sopra è evidenziato lo strato di trasferimento dei dati,
cioè il componente JMS. Si evince poi l’esistenza di uno strato semantico
indipendente dagli altri elementi dell’applicazione. A tale strato semantico
si accede dalle applicazioni esterne mediante un livello di API che
permettono la gestione, la manipolazione e l’interrogazione dell’ontologia.
La separazione evidenziata permette di capire che è stata realizzata un
suddivisione della complessità dell’intera applicazione, nel senso che
eventuali cambiamenti nel dominio
comportano altrettanti cambiamenti del
modello
ontologico, e tutto ciò può essere realizzato lasciando inalterata la
logica dell’applicazione. In particolare possono si possono prevedere
cmabiamenti
• che, introducendo concetti nuovi nel modello ontologico, richiedono
di modificare le operazioni effettuate dal query-engine ma che
tuttavia non impattano sul livello di API definito.
• che modificano sia l’ontologia sia il livello di API proprio per
estendere le funzionalità che il middleware offre alle applicazioni.
4.3.2 – Presentazione dei Risultati
L’applicazione realizza gli scenari operativi che sono stati introdotti nei
paragrafi precedenti.
La prima parte della demo realizza i primi due scenari, cioè calcolo delle
distributionList, contributorList ed userList e pubblicazione del Flight
Object nelle particolari condizioni mostrate nella figura 4.11.
143

Figura 4.11 - Scenario Operativo 2
Ci sono
quattro sistemi a ciascuno dei quali sono associate un area di
interesse ed un area di responsabilità. Ci sono poi due voli,
i cui dati sono
tenuti nei
corrispondenti Flight Object. Siamo a Creatione Time, il Manager
dopo aver costruito l’oggetto Flight Object ha sia la necessità di distribuirlo
ai
sistemi interessati, sia la necessità di determinare per quel Flight Object i
ruoli che possono essere assunti
sono mostrati sinteticamente
nella seguente figura.
dai diversi sistemi. Le fasi di
funzionamento della demo e il relativo output in riferimento al solo volo 2
144

Figura 4.12 - Output Scenario 1
Il sistema manager accede al cluster TrajectoryCluster del Flight Object in
questione per prelevarne il dato Trajectory. Utilizzando le API definite per
il calcolo della distributionList e della contributorList messe a disposizione
dallo strato semantico, richiama le funzionalità del Query Engine al quale
passa come parametro il dato Trajectory. Il risultato delle varie interazioni
mostrate in figura è appunto l’ottenimento della lista dei sistemi interessati
al Flight Object e l’attribuzione di uno specifico ruolo ad ogni sistema in
essa contenuto.
La
seconda parte della demo realizza il terzo scenario, cioè l’individuazione
della lista dei cluster correlati, la realizzazione delle modifiche conseguenti
e la ri-pubblicazione del Flight Object.
145

Figura 4.13 - Scenario Operativo 2
Come evidenziato nel paragrafo su ICOG, le informazioni contenute nei
Cluster possono essere correlate in varia maniera. Nella figura 4.13, è
mostrato il caso di una particolare istanza di Flight Object ( Flight Object
con id “foid1” ) in cui sono presenti duplicazioni di dati. In particolare tali
duplicazioni riguardano:
• arcid: tale dato è duplicato sia in AirCraftCluster, sia in
FlightKeyCluster
che FlightPlanDataCluster;
• adep: tale dato è duplicato sia in FlightKeyCluster, sia in
FlightPlanDataCluster che in ScriptCluster;
• ades: tale dato è duplicato sia in FlightKeyCluster, sia in
FlightPlanDataCluster che in ScriptCluster;
All’interno di tale Flight Object è presente anche un altro tipo di
dipendenza, in particolare è presente una relazione “uses” tra
146

FlightIdentificationCluster e FlightKeyCluster, che come abbiamo spiegato
nel paragrafo precedente sta a rappresentare la dipendenza semantica
secondo cui i dati contenuti in FlightIdentificationCluster sono ottenuti per
fusione od elaborazione dei dati contenuti in FlightKeyCluster.
Le fasi di funzionamento della demo ed il relativo output sono mostrati
sinteticamente nella seguente figura.
Figura 4.14 - Output Scenario 2
L’even to che si verifica è l’arrivo di un oggetto aggiornato di tipo
FlightKeyCluster ( FlightKeyCluster con id “flightkeyclusterid1” ). Il
sistema manager utilizzando le opportune API messe
a disposizione dallo
strato
semantico, richiama le funzionalità del Query Engine al quale passa
come parametro il FlightKeyCluster in oggetto. Il
risultato delle varie
interazioni mostrate in figura è appunto l’ottenimento della lista dei Cluster
appartenenti allo stesso Flight Object che risultano essere correlati.
147

Conclusioni e Sviluppi Futuri
Il presente lavoro di tesi ha dimostrato che l’ integrazione di uno schema
concettuale dei dati, nel nostro caso un’ontologia OWL, all’interno di un
sistema ULS come SWIM-SUIT, in particolare all’interno di uno dei suoi
domini come quello piani di volo, permette di ottenere vantaggi per quanto
riguarda l’organizzazione e l’interpretazione delle informazioni e di
estendere le funzionalità del sistema in termini di gestione e manipolazione
automatica delle informazioni, trasferimento dei dati e classificazione delle
responsabilità di ogni sistema in base non alle funzionalità che il sistema
svolge, ma piuttosto, al contenuto semantico proprio delle informazioni che
il sistema si trova a dover gestire.
In particolare il focus dell’intero lavoro è stato quello di trattare dal punto di
vista semantico, unicamente informazioni che riguardano i piani di volo
come la traiettoria, il partizionamento dello spazio aereo, informazioni
riguardanti gli aerodromi e i velivoli. In questo contesto, uno dei possibili
sviluppi
futuri di questo lavoro potrebbe essere di modellare semantico di
altri aspetti che caratterizzano la gestione dei piani di volo come ad esempio
aspetti istituzionali o aspetti che riguardano la sicurezza. Altro aspetto
sicuramente molto interessante, che potrebbe essere affrontato in futuro,
sarebbe quello di estendere il trattamento semantico delle informazioni
anche agli altri domini dell’ATM. In tal senso ci si troverebbe ad affrontare
problemi di interoperabilità di sistemi che sono nati per gestire dati
strutturalmente e semanticamente differenti, problemi di duplicazioni
di dati
e quindi problematiche di consistenza e coerenza ed ancora molto
148

probabilmente problematiche
riguardo l’integrazione e la fusione di
informazioni eterogenee.
149

Riferimenti
[1] Ultra Large Scale System. The software challenge on the future.
[2] Introduzione a Corba. Stefano Russo, Carlo Savy, Domenico
Cotroneo, Antonio Sergio.
[3] Prima relazione sull’applicazione della normativa sul Cielo
unico europeo: bilancio e prospettive. Bruxelles, 20.12.2007
[4] www.enav.it
[5] Cielo unico europeo II: verso un trasporto aereo più sostenibile
ed efficiente. Bruxelles, 25.6.2008
[6] Information Content and Service Requiriments. Delivery n°
D1.5.1
[7] ICOG IOP Interface Specification– Final Report
[8] Wikipedia
[9] Applications of Ontoilogies in Software Engineering
[10] Introduzione al Semantic Web. Antonella Dorati e Stefania
Costantini
[11] www.mokabyte.it
[12] Semantic Web - Scientific American, Maggio 2001. T. Berners-
Lee, J. Hendler, O. Lassila
[13] AA. VV. Uniform Resource Identifiers (URI): Generic Syntax
W3C: URL: http://www.ietf.org/rfc/rfc2396.txt
[14] http://www.w3c.org
[15] Resource Description Framework (RDF), Model and Syntax
Specification W3C Recommendation; O. Lassila, R. R. Swick,
150

W3C: URL: http://www.w3.org/TR/REC-rdf-syntax/
[16] RDF Schema 16 Aprile 2007. Antonio Picariello
[17] OWL Ontology Web Language. Antonio Picariello
[18] http://www.w3c.org/2004/OWL - sezione del sito W3C dedicata
ad OWL
[19] http://protege.stanford.edu/
[20] http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
[21] http://pellet.owldl.com
[22] Pellet: An OWL DL Reasoner. Bijan Parsia and Evren Sirin
[23] Pellet: A Pratical OWL DL Reasoner. Evren Sirin, Bijan Parsia,
Bernardo Cuenca Grau, Aditja Kalyanpur, Yarden Katz.
[24] http://www.hpl.hp.com/semweb/ – home page del Semantic Web
Research Group di HP Labs
[25] Ontologie OWL. Nicola Capuano
[26] http://jena.sourceforge.net/ – il sito di riferimento di Jena
ospitato da SourceForge
[27] http://java.sun.com/products/jms/
[28] Java EE 5 Tutorial
[29] ICOG IOP Interface Specification– Final Report
151