università degli studi di padova dipartimento di matematica corso di laurea in informatica
INTRODUZIONEDITECNOLOGIEPERIL SEMANTICWEBNELPROGETTOSPOCS
laureando: relatore: simone carriero dott. mauro conti
Anno Accademico 2011-2012
SOMMARIO
Il presente documento intende essere una relazione dell’attività di stage svolta presso l’azienda IKS srl, esperienza che mi ha permesso innanzitutto di essere inserito in una realtà aziendale ed apprendere da essa metodologie di lavoro e organizzazione. Durante lo stage mi sono occupato di introdurre tecnologie per il Semantic Web in SPOCS, un progetto supportato dalla Commissione Europea che ha l’obiettivo di rendere più semplice per i cittadini eu- ropei l’avvio di nuove attività imprenditoriali, specialmente in paesi diversi da quello di appartenenza. Ho iniziato dallo studio delle tecnologie correlate al Semantic Web e di un framework per l’utilizzo di tali tecnologie in ambiente Java, in cui il progetto SPOCS è sviluppato. Il passo successivo è stato la progettazione e la realizzazione di un’ontologia. Per raggiungere questo obiettivo è stato necessario af- frontare concetti ed utilizzare tecnologie che non avevo appreso du- rante il mio percorso di studi. A posteriori, posso dire di essere sod- disfatto delle conoscienze metodologiche fornitemi dall’università. Infine ho progettato e implementato un componente software che permettesse l’accesso alle informazioni rappresentate dall’ontologia e ho evoluto due applicazioni web in modo tale che lo utilizzassero. Ritengo sia stato interessante metter mano ad applicazioni svilup- pate in un ambiente professionale ed analizzarle in confronto ad applicazioni che ho sviluppato durante il mio percorso di studi.
iii
INDICE
1 contesto aziendale1 1.1 Aree di intervento 1 1.2 Organizzazione interna 1 1.3 Clienti 2 1.4 Il gruppo IKS 2 1.5 Processi aziendali 2 1.5.1 Processo di sviluppo 3 1.5.2 Processo di documentazione 3 1.5.3 Processo di manutenzione 3 1.6 Strumenti di supporto allo sviluppo 4 1.6.1 Sistema di versionamento 4 1.6.2 Sistema di ticketing 4 1.6.3 Ambiente di sviluppo 4 1.7 Tecnologie utilizzate 4 2 il progetto spocs7 2.1 Cos’è SPOCS 7 2.2 I Points of Single Contact 7 2.3 La nuova generazione di Points of Single Contact 8 2.4 Il Point Of Single Contact italiano 8 2.4.1 Applicazione web eServices 8 2.4.2 eDocuments 11 2.5 Spocs e le tecnologie semantiche 12 3 progetto di stage 13 3.1 Pianificazione 13 3.1.1 Obiettivi minimi 13 3.1.2 Obiettivi massimi 14 3.1.3 Scomposizione in fasi 14 3.2 Studio di concetti relativi al Semantic Web 19 3.2.1 RDF 19 3.2.2 OWL 20 3.2.3 SPARQL 20 3.3 Scelta del framework 20 3.3.1 Il framework Apache Jena 20 3.4 Analisi dei requisiti 25 3.4.1 Casi d’uso 26 3.4.2 Requisiti 28 3.5 Progettazione ontologia 31 3.5.1 Suddivisione architetturale 31 3.5.2 Considerazioni sul riuso 32 3.5.3 Dominio places 32 3.5.4 Dominio documents 34 3.5.5 Dominio spocs-italy 35
v vi indice
3.5.6 Design pattern utilizzati 38 3.5.7 Linked data 38 3.6 Progettazione componente SemDB 38 3.6.1 Gerarchia OntologyManager 40 3.6.2 Gerarchia SemDBDAO 41 3.6.3 Conseguenze delle variazioni dei requisiti 44 3.6.4 Il Point of Single Contact italiano dopo lo stage 45 4 visione retrospettiva 47 4.1 Bilancio rispetto alla pianificazione 47 4.1.1 Obiettivi minimi 47 4.1.2 Obiettivi massimi 48 4.2 Bilancio delle conoscenze 49 4.3 Divario tra università e mondo del lavoro 49
bibliografia 51 ELENCODELLEFIGURE
Figura 1 Organigramma aziendale IKS 2 Figura 2 Logo del progetto SPOCS 7 Figura 3 Rappresentazione del PSC italiano 8 Figura 4 Screenshot dell’applicazione web eServices 9 Figura 5 Diagramma delle componenti dell’applicazione web eServices 10 Figura 6 Screenshot dell’applicazione web eDocuments 11 Figura 7 Diagramma delle componenti dell’applicazione web eDocuments 12 Figura 8 Rappresentazione concetti da rappresentare in SemDB 13 Figura 9 Diagramma di Gantt che rappresenta la pianificazione iniziale 16 Figura 10 Diagramma di Gantt che rappresenta la pianificazione modificata 18 Figura 11 Parte dei Linked Data come rappresentati in http://linkeddata.org 19 Figura 12 Architettura del framework Apache Jena come rapp- resentata in http://jena.apache.org/about_jena/architecture.html 21 Figura 13 UC1: Funzionalità offerte all’utente alla visualiz- zazione della lista ordinata dei requisiti da soddis- fare per avviare l’attività 26 Figura 14 UC1.4: Funzionalità offerte all’utente alla visualiz- zazione della lista dei task da eseguire per soddisfare ciascun requisito 27 Figura 15 UC2: Funzionalità offerte all’utente alla verifica del contenuto di un OCD 28 Figura 16 Rappresentazione della suddivisione del dominio da rappresentare 32 Figura 17 Ontologia rappresentante il dominio “places” 33 Figura 18 Relazioni tra le proprietà dell’ontologia rappresen- tante il dominio “places” 33 Figura 19 Rappresentazione dei concetti dell’ontologia GeoN- ames utilizzati 34 Figura 20 Ontologia rappresentante il dominio “spocs-italy” 36 Figura 21 Rappresentazione della relazione n-aria tra Task e Requirement 37 Figura 22 Diagramma delle classi rappresentante il SemDB 39 Figura 23 Diagramma delle classi rappresentante la gerarchia OntologyManager 40 Figura 24 Diagramma delle classi rappresentante la gerarchia SemDBDAO 41
vii viii Elenco delle figure
Figura 25 Diagramma di sequenza che rappresenta le oper- azioni eseguite del metodo public void loadOntology(String path) della classe JenaSingleStorageDAO 42 Figura 26 Diagramma di sequenza che rappresenta le oper- azioni eseguite del metodo public void loadOntology(String path) della classe JenaDoubleStorageDAO 43 Figura 27 Diagramma delle componenti dell’applicazione web eServices dopo l’evoluzione 45 Figura 28 Diagramma delle componenti dell’applicazione web eServices dopo l’evoluzione 46 ELENCODELLETABELLE
Tabella 1 Principali requisiti funzionali 30 Tabella 2 Principali requisiti di vincolo 30
ix LISTINGS
Listing 1 Esempio di gestione di risorse 22 Listing 2 Esempio di creazione di risorse 22 Listing 3 Esempio di query 23 Listing 4 Esempio di importazione di un’ontologia da file 23 Listing 5 Esempio di ottenimento di un istanza di Model da SDB 24 Listing 6 Esempio di ottenimento di un istanza di Model da TDB 25
x CONTESTOAZIENDALE 1
In questo capitolo si presenta IKS (Information Knoledge Supply), l’azienda ospitante lo stage. In particolare: di che cosa si occupa, organizzazione e metodologie di lavoro adottate.
1.1 aree di intervento
Le aree di intervento in cui IKS si propone sono: sicurezza: garantire che le risorse e i servizi di un sistema infor- mativo siano sempre accessibili e fruibili. ottimizzazione dell’infrastruttura: offrire soluzioni legate all’infrastruttura ponendo attenzione alla semplificazione del- la stessa e alle tempistiche di provisioning dei sistemi, molto spesso utilizzando tecnologie di virtualizzazione. governance: analisi, riorganizzazione e verifica dei processi di gov- ernance al fine di gestire al meglio l’IT e rendendolo funzionale al business dell’azienda seguendo la filosofia ITIL (Information Technology Infrastructure Library). L’ITIL è un insieme di linee guida derivate dalle best practice nella gestione dei serviziIT. innovation & projects: progettare e sviluppare i prodotti soft- ware, vantando competenze sempre aggiornate grazie a contin- ue attività di ricerca e di prototipizzazione su temi innovativi.
1.2 organizzazione interna
Internamente, la funzione operativa aziendale è suddivisa in quat- tro Business Unit, come rappresentato in Figura 1, ognuna delle quali si occupa di una delle precedentemente elencate aree di intervento, rispettivamente: Security, Infrastructure, BSM (Business Service Manage- ment) e FIP (Factory Innovation & Projects).
1 2 contesto aziendale
Direzione
Finanza e Direzione Assicurazione Amministrazione Operation personale commerciale qualità
Pianificazione e controllo operativo
Security Infrastructure BSM FIP
Figura 1: Organigramma aziendale IKS
1.3 clienti
L’offerta di IKS incontra principalmente la domanda di aziende di grandi dimensioni grazie anche all’attività di consulenza esterna, ovvero alla collocazione di personale nel repartoIT del cliente. I mercati di riferimento sono infatti quello finanziario/assicurati- vo, dell’industria, delle telecomunicazioni e della pubblica amminis- trazione, dove vanta clienti del calibro di Allianz, Assicurazioni Gen- erali, Unicredit Servizi, Alitalia, Gruppo Despar, Fastweb, Telecom Italia, Regione Veneto, InfoCamere.
1.4 il gruppo iks
IKS è leader di un gruppo di aziende di cui fanno parte:
dadoquadro: acquisita nel 2006, si occupa prioritariamente di in- formatizzazione e dematerializzazione dei processi aziendali;
kima projects & services: acquisita nel 2008, si occupa priori- tariamente di security compliance;
iks tn: nata nel 2009, si occupa prioritariamente di ricerca e svilup- po;
kleis: nata nei primi anni 2000 come azienda specializzata nell’am- bito della sicurezza informatica, dal 2011 fa parte del Gruppo IKS. É un’azienda di riferimento in ambito nazionale per le tematiche delle frodi in ambito finanziario.
1.5 processi aziendali
Segue una breve descrizione dei più rilevanti processi adottati all’in- terno della Business Unit FIP. 1.5 processiaziendali 3
1.5.1 Processo di sviluppo
Le principali attività nel processo di sviluppo sono: attività di analisi: l’analista incaricato redige il documento di “Analisi dei requisiti” a partire dalle specifiche richieste dal committente. Si svolgono uno o in più incontri con quest’ultimo, che può richiedere modifiche del documento oppure approvar- lo. Quando si giunge ad un accordo si può procedere, passando alla fase di progettazione. attività di progettazione: durante la fase di progettazione viene tipicamente formato un piccolo gruppo di 3-4 persone, con a capo il responsabile. La progettazione architetturale e la proget- tazione di dettaglio non sono trattate come due fasi distinte, ma tale fase riveste il ruolo di entrambe. attività di codifica e verifica: essendo i progetti generalmente basati su Java, per la codifica si seguono le regole dettate dalla Java Code Convention ed è norma implementare test di unità e di integrazione significativi.
In FIP non esistiono risorse che si occupino unicamente di anal- isi, progettazione, codifica o verifica ma questi ruoli sono svolti da ognuna delle risorse.
1.5.2 Processo di documentazione
La documentazione viene redatta in modo snello e tipicamente ad alto livello. Ad esempio i documenti tecnici redatti a supporto del- la progettazione non sono abbastanza dettagliati da permettere al programmatore di non effettuare scelte. Fa eccezione il documento di Analisi dei requisiti poiché, essendo incluso nel contratto con il cliente, ha valore legale.
1.5.3 Processo di manutenzione
La manutenzione è gestita attraverso il sistema di ticketing aziendale. Dopo il rilascio di un prodotto, infatti, se il committente neccessita di un’intervento di manutenzione per l’evoluzione di una funzionalità o per la correzione di un bug deve aprire un ticket verso l’azienda. Il ticket viene preso in carico da una risorsa aziendale che lo gestisce, esegue i test di regressione per verificare di non aver introdotto errori, e procede con il rilascio. 4 contesto aziendale
1.6 strumenti di supporto allo sviluppo
Sono in seguito presentati i principali strumenti utilizzati in FIP a supporto dello sviluppo.
1.6.1 Sistema di versionamento
Attualmente il sistema di versionamento utilizzato è CVS, ma è in cor- so una migrazione a Git principalmente per interesse verso due sue caratteristiche, entrambe legate al fatto che sia un sistema distribuito:
• ogni sviluppatore possiede in locale l’intera storia del progetto;
• le operazioni di pubblicazioni e di creazione di un commit sono distinte ed è quindi possibile modificare parti committate ma non ancora pubblicate senza intaccare il lavoro degli altri svilup- patori.
1.6.2 Sistema di ticketing
Come accennato in Sezione 1.5.3 viene utilizzato un sistema di ticket- ing. Si tratta di OTRS, un prodotto open source che l’azienda propone anche ai suoi clienti nel contesto dell’area “Governance”.
1.6.3 Ambiente di sviluppo
L’ambiente di sviluppo utilizzato all’interno di FIP è Eclipse, che for- nisce una serie di facilitazioni per lo sviluppo di applicazioni Java in particolare grazie ai numerosi plugin esistenti. Ad esempio il plu- gin JBoss Tools permette la configurazione dell’application servere il deploy dell’applicazione direttamente dall’ambiente di sviluppo in modo molto semplice.
1.7 tecnologie utilizzate
Sono in seguito presentate le principali tecnologie utilizzate in FIP:
j2ee: piattaforma che fornisce delle API e un ambiente di esecuzione per lo sviluppo e l’esecuzione di applicazioni enterprise. Es- tendeJ 2SE (Java Platform, Standard Edition) fornendo API per ORM, architetture multi-tier e distribuite e web services.
spring framework: framework per la realizzazione di applicazioni che implementano il pattern architetturale MVC.
apache struts: framework per la realizzazione di applicazioni che implementano il pattern architetturale MVC. É principalmente 1.7 tecnologie utilizzate 5
utilizzato per la manutenzione di progetti che vivono da qualche anno, mentre per la realizzazione di nuovi progetti è preferito Spring. jboss: application server che implementa la piattaformaJ 2EE. apache tomcat: web server e servlet container. hibernate: ORM utilizzato per gestire la rappresentazione e il man- tenimento su database relazionale di un domain model orientato agli oggetti. liferay: portale open-source basato su Java. jqueryui: libreria JavaScript cross-browser che si propone come obi- ettivo la semplificazione dello scripting lato client. zkoss: framework che consente la creazione di GUI AJAX senza dover utilizzare JavaScript e utilizzando concetti simili a quelli usati da Swing.
ILPROGETTOSPOCS 2
In questo capitolo si descrive il progetto SPOCS, all’interno del quale si colloca l’attività di stage.
2.1 cos’è spocs
Il progetto SPOCS (Simple Procedures Online for Cross-border Ser- vices) è un progetto sperimentale che ha l’obiettivo di rendere più semplice per i cittadini europei l’avvio di nuove attività imprendi- toriali, specialmente in paesi diversi da quello di appartenenza. Per perseguire questo obiettivo SPOCS sta costruendo la nuova gener- azione dei già esistenti sportelli unici, chiamati anche PSC (Points of Single Contact).
SPOCS è supportato dalla Commissione Europea (Competitive- ness and Innovation Programme) e da quindici paesi europei: Austria, Francia, Germania, Grecia, Italia, Lituania, Lussemburgo, Malta, Pae- si Bassi, Polonia, Portogallo, Romania, Slovenia, Svezia, Regno Unito, Norvegia.
Figura 2: Logo del progetto SPOCS
2.2 i points of single contact
Dal dicembre 2009, come disposto dalla direttiva UE sui servizi, cias- cun paese dell’UE è tenuto ad avere uno sportello unico, ovvero un portale di e-government che ha l’obiettivo di semplificare le proce- dure per l’avvio di nuove attività imprenditoriali. Come? Mettendo a disposizione dell’imprenditore tutte le informazioni a lui necessarie riguardanti leggi, regolamenti e formalismi burocratici che dovrà in- contrare nel suo percorso, permettendogli inoltre di completare on- line le formalità amministrative (ad esempio la compilazione della modulistica e la presentazione della documentazione). I PSC attualmente in esercizio presso tutti i paesi europei, però, contengono informazioni riguardanti solamente il paese a cui fanno
7 8 ilprogettospocs
riferimento, e in un certo senso ignorano l’origine del futuro impren- ditore. Ad esempio, se un agente immobiliare tedesco desidera espandere il suo business a Padova, il PSC italiano gli comunica soltanto quali sono i documenti italiani di cui ha bisogno. Di conseguenza esso deve ricercare informazioni da altre fonti in merito alle procedure che un cittadino tedesco deve seguire per ottenere tali documenti italiani.
2.3 la nuova generazione di points of single contact
L’obiettivo del progetto SPOCS è dunque quello di creare una nuova generazione di PSC che siano, come dice il nome stesso, Cross-border, ovvero forniscano informazioni esaustive ad un cittadino della co- munità europea che voglia avviare un’attività in un paese europeo diverso da quello di appartenenza.
2.4 il point of single contact italiano
Il PSC italiano, che sarà raggiungibile da www.impresainungiorno. gov.it, sarà in sostanza un portale Liferay che esporrà le funzionalità di due applicazioni web distinte: eServices e eDocuments.
Figura 3: Rappresentazione del PSC italiano
2.4.1 Applicazione web eServices
L’applicazione fornisce ad un utente che vuole aprire un’attività, in funzione della suo paese di provenienza, della professione che vuole intraprendere e del comune italiano in cui vuole avviare la sua attiv- ità l’elenco dei servizi cui si dovrà rivolgere, specificando per ognuno di essi: cosa otterrà in output dopo averlo utilizzato, eventuali doc- umenti necessari, eventuali documenti richiesti e altre caratteristiche proprie del servizio. L’applicazione è ancora allo stato prototipale, ed è infatti evidente che la le informazioni fornite non sono sufficientemente significative da far sì che l’utente non abbia bisogno di ricercare informazioni da altre fonti per avviare la sua attività, cosa che va contro la definizione 2.4 il point of single contact italiano 9 di Single Point of Contact. Uno degli obiettivi della mia attività di stage era quello di evolvere l’applicazione in questa direzione, come verrà spiegato dettagliatamente in seguito.
Figura 4: Screenshot dell’applicazione web eServices
2.4.1.1 Dettagli tecnici L’applicazione eServices è realizzata in linguaggio Java all’interno del Framework Spring Web MVC, ed è suddivisa modularmente nei componenti illustrati in Figura 5, che sono di seguito brevemente illustrati. 10 il progetto spocs
<
<
SearchOM TransformationOM
<
Figura 5: Diagramma delle componenti dell’applicazione web eServices
midb (metainformation database) è il database contenente le informazioni condivise tra tutti i paesi. I principali concetti che sono rappresentati sono: documento, servizio e professione.
wp4 è un componente di SPOCS che permette ciascun paese di accedere alle informazioni contenute nel MIDB.
ejb-midb è una componente che offre dei metodi significativi per eseguire operazioni di lettura e scrittura sul MIDB. Si occupa di fare le query “a basso livello” utilizzando le interfaccie SearchOM e Trans- formationOM, rispettivamente per lettura e scrittura, e nel caso della lettura si occupa anche di “convertire” l’output in oggetti di dominio da ritornare al chiamante.
eservices-web è un componente al cui interno sono definiti con- troller e view dell’applicazione, ed utilizza il componente ejb-MIDB che rappresenta il model. Le view sono pagine JSP che utilizzano la libreria jQueryUI per la rappresentazione delle principali componenti grafiche.
Il framework Spring è spesso considerato un’alternativa al model- lo Enterprise JavaBeans (EJB) considerando, tra le altre cose, il ricco supporto che esso offre per la gestione di transazioni e per l’accesso JDBC.A volte però l’utilizzo di EJB è un vincolo, in questo caso det- tato da esigenze del cliente. É interessante notare che, a differenza di quanto si potrebbe pensare in una prima analisi, l’utilizzo di Spring 2.4 il point of single contact italiano 11 non pregiudica l’utilizzo di EJB, anzi rende più semplice l’accesso agli EJB e permette che l’implementazione degli stessi sia traspar- entemente cambiata tra EJB locali, EJB remoti o POJO, senza che il codice del client debba essere toccato [2].
2.4.2 eDocuments
Un OCD (Omnifarious Containers for eDocuments) rappresenta un pacchetto che contiene documenti elettronici e metadati a loro as- sociati. L’idea è quella di permettere lo scambio di documenti tra i vari paesi dell’unione europea garantendo che da ciascun paese possano essere compresi i documenti di ogni altro, grazie ai metata- di che descrivono i documenti indipendentemente dal loro paese di riferimento. L’applicazione permette ad un utente di fare l’upload di documenti, in qualsiasi formato essi siano, e lo guida alla definizione dei meta- dati. Permette inoltre di verificare la firma digitale, se presente, di un qualsiasi OCD o dei documenti in esso contenuti.
Figura 6: Screenshot dell’applicazione web eDocuments
2.4.2.1 Dettagli tecnici L’applicazione eDocuments è realizzata in linguaggio Java all’inter- no del Framework Spring Web MVC, ed è suddivisa modularmente nei componenti illustrati in Figura 7, che sono in seguito brevemente illustrati. 12 il progetto spocs
<
Processing Authentication Extraction
<
Figura 7: Diagramma delle componenti dell’applicazione web eDocuments
wp2 Offre, attraverso le interfaccie Processing, Authentication e Extraction, funzionalità per eseguire operazioni di creazione, verifi- ca ed estrazione sugli OCD.
edocuments-web è un componente al cui interno sono definiti controller e view dell’applicazione. Utilizza il componente WP2 per eseguire operazioni di creazione, verifica ed estrazione sugli OCD. Anche per questa applicazione, ovviamente, valgono le stesse con- siderazione in merito all’integrazione tra Spring ed EJB fatte in Sezione 2.4.1.1.
2.5 spocs e le tecnologie semantiche
Seguono le motivazioni che hanno portato all’idea di introdurre le tecnologie per il Semantic Web nel progetto SPOCS, come descritte in [8] Esiste generalmente un gap tra i servizi governativi offerti da un paese rispetto a quelli offerti da un altro tra cui, ad esempio, differen- ze linguistiche, culturali e giuridiche. I servizi cross-border richiedono che questo gap sia colmato e questo può essere fatto attraverso interoperabilità semantica, ovvero facendo sì che i servizi dei vari paesi condividano e si scambino tra loro infor- mazioni non ambigue. Il mittente deve essere in grado di trasmettere informazioni con la consapevolezza che il destinatario le interpreterà correttamente. Attraverso l’uso di tecnologie semantiche si intende definire “uno strato” di informazioni globale che comprenda le informazioni nec- essarie a ciascun componente di SPOCS. Attualmente non è cosi. Ad esempio, eServices utilizza il concetto di equivalenza tra documen- ti offerto dal componente WP4 ed eDocuments utilizza il concetto di metadati dei documenti offerto dal componente WP2, ma queste informazioni non sono tra loro in relazione. PROGETTODISTAGE 3
In questo capitolo viene illustrato il lavoro svolto durante lo stage, in particolare i problemi affrontati e le soluzioni proposte.
3.1 pianificazione
Il piano di lavoro iniziale è stato redatto dal tutor aziendale. La piani- ficazione ha previsto la definizione di obiettivi di stage e la scompo- sizione dell’attività di stage in fasi.
3.1.1 Obiettivi minimi progettazione e realizzazione semdb Progettare e realiz- zare un componente, denominato SemDB, all’interno del quale sia presente uno “strato” di informazioni costruito sopra i concetti di pro- fessione, documento e servizio già presenti nel MIDB. I nuovi concetti da rappresentare sono: • requisito: inteso come qualcosa da soddisfare al fine di avviare un’attività,
• task: inteso come una singola azione da eseguire al fine di sod- disfare un requisito. Il task si lega con le informazioni sottostan- ti, ovvero può richiedere o produrre documenti, essere eseguito attraverso servizi, valere per determinate professioni, ecc. Tale strato informativo deve essere rappresentato attraverso un’on- tologia.
Figura 8: Rappresentazione concetti da rappresentare in SemDB evoluzione applicazione web eservices Evolvere l’appli- cazione web eServices in modo tale che utilizzi il componente SemDB per fornire all’utente un’elenco di requisiti da soddisfare, e per og- nuno di essi l’elenco dei task da eseguire per portare a termine la sua soddisfazione.
13 14 progetto di stage
documentazione tecnica Produrre documentazione relativa alla progettazione dell’ontologia e alla progettazione del componente software SemDB.
3.1.2 Obiettivi massimi
documentazione strumenti e tecnologie Produrre docu- mentazione riguardante strumenti e tecnologie utilizzati durante l’at- tività di stage che non sono attualmente conosciuti dalle risorse azien- dali. Il fine è quello di “lasciare in azienda” le conoscenze acquisite durante la mia attività di stage e metterle a disposizione delle risorse aziendali che in futuro dovranno affrontare le stesse problematiche cho ho affrontato io.
evoluzione applicazione web edocuments Evolvere l’ap- plicazione web eDocuments in modo tale che permetta all’utente di verificare il contenuto di un OCD. Tale verifica consiste nel control- lare che un OCD creato al fine di soddisfare un requisito contenga tutti i documenti necessari per farlo effettivamente. Per farlo dovrà utilizzare le informazioni fornite dal SemDB.
configurazione apache maven Configurare Apache Maven per la gestione dei progetti eServices ed eDocuments.
3.1.3 Scomposizione in fasi
La pianificazione ha previsto la scomposizione dell’attività di stage nelle fasi in seguito presentate. Alla fine di ognuna di esse si trova una milestone, infatti l’output di ogni fase è oggetto di verifica da parte del tutor aziendale per il passaggio alla successiva.
fase 1: formazione
• Durata: 60 ore (7.5 giorni).
• Obiettivo: formazione su strumenti e tecnologie.
• Attività: – formazione suJ 2EE: Servlet, EJB, JSP, Spring Web MVC, JBoss Application Server – scelta e studio del framework per la memorizzazione e la gestione dell’ontologia, – formazione sull’ambiente di sviluppo, – studio del funzionamento delle componenti con cui ci si interfaccierà, – verifica competenze acquisite. 3.1 pianificazione 15
• Output: semplice web application di esempio che faccia uso di tutte le tecnologie indicate. fase 2: analisi e progettazione
• Durata: 40 ore (5 giorni).
• Attività: – analisi dei requisiti, – progettazione ontologia, – progettazione SemDB, – pianificazione della verifica, – produzione di documentazione.
• Output: – documento “Analisi dei requisiti”, – documento “Specifica tecnica”, – documento “Piano di qualifica”. fase 3: implementazione
• Durata: 140 ore (17.5 giorni).
• Attività: – realizzazione ontologia, – implementazione SemDB, – configurazione di Apache Maven, – produzione di documentazione.
• Output: prodotto finale. fase 4: verifica e validazione
• Durata: 80 ore (10 giorni).
• Attività: – implementazione di test di unità, – implementazione di test di integrazione, – verifica soddisfacimento dei requisiti (tracciamento), – eventuale correzione di bug, – validazione.
• Output: documento “Piano di qualifica” aggiornato con gli esiti dei test. 16 progetto di stage
Figura 9: Diagramma di Gantt che rappresenta la pianificazione iniziale 3.1 pianificazione 17 variazione della pianificazione Giunto alla terza settimana ho deciso di apportare delle modifiche alla pianificazione, al fine di riuscire ad ultimare la progettazione in tutti i suoi dettagli e produrre la relativa documentazione. Ho ritenuto che la durata della fase di implementazione potesse essere diminuita, trattandosi per la mag- gior parte di codifica “meccanica” di quanto progettato precedente- mente. Di conseguenza la pianificazione della durata delle fasi è stata modificata come segue:
• fase di analisi e progettazione: da 40 a 80 ore,
• fase di implementazione: da 140 a 100 ore.
A posteriori posso dire che tale scelta si sia rivelata esatta, in quanto la settimana aggiuntiva dedicata alla progettazione è stata sufficiente per la sua ultimazione ed anche la fase di implementazione è risul- tata essere sufficiente. In seguito è stato necessario apportare altre modifiche alla pianificazione, che hanno però causato solamente lo spostamento in avanti delle attività e non la riorganizzazione delle fasi:
• dal 23/07 al 29/07 il tutor aziendale ha usufruito di ferie, per- tanto abbiamo deciso di non svolgere attività di stage durante quella settimana;
• la chiusura estiva dell’azienda si è rivelata essere di tre setti- mane (dal 13/08 ad 02/09) anziché di due come considerato nella pianificazione inziale. 18 progetto di stage
Figura 10: Diagramma di Gantt che rappresenta la pianificazione modificata 3.2 studio di concetti relativi al semantic web 19
3.2 studio di concetti relativi al semantic web
Il W3C sta promuovendo una serie di standard al fine di conver- tire l’attuale web orientato ai documenti, dominato quindi da dati non strutturati e semistrutturati, in un web orientato ai dati, in cui questi giochino il ruolo centrale. L’idea è che siano disponibili pubbli- camente una grande quantità di dati espressi in un formato standard, in modo tale che possano essere processati da macchine attraverso gli standard forniti dal W3C e che questi siano messi in relazione tra loro al fine di creare una sorta di database globale, indicato talvolta con il nome di “Linked Data”.
A partire dai dati disponibili è possibile ricavarne altri. Si definisce inferenza quella procedura che genera nuovi dati a partire da dati esistenti secondo un insieme di regole. Ad esempio se viene asserito che “Flipper è un delfino” e viene espresso il fatto che “ogni delfino è anche un mammifero” può essere inferito il fatto che “Flipper è un mammifero”.
Figura 11: Parte dei Linked Data come rappresentati in http://linkeddata.org
Sono in seguito brevemente descritte alcune tecnologie delle tec- nologie promosse dal W3C in merito al Semantic Web [9].
3.2.1 RDF
RDF (Resource Description Framework) è una famiglia di specifiche W3C per la modellazione di informazioni. L’idea è quella di fare as- serzioni, chiamate anche statement o triple RDF nella forma soggetto 20 progetto di stage
predicato oggetto. Sia soggetto che predicato che oggetto sono risorse, ovvero rappresentano un concetto è sono identificate univocamente da un URI e il predicato esprime una relazione tra soggetto ed ogget- to. Ad esempio la nozione il cielo è del colore blu può essere rappre- sentata da una tripla RDF con soggetto che rappresenta il concetto di “cielo”, predicato che rappresenta il concetto di “essere del colore e oggetto che rappresenta il concetto di “blu”.
3.2.2 OWL
OWL (Web Ontology Language) è un linguaggio che consente di rap- presentare la conoscenza attraverso la creazione di ontologie. I prin- cipali costrutti permettono di rapprentare classi, relazioni tra classi (equivalenza, disgiunzione, ecc.), cardinalità, proprietà e caratteris- tiche delle proprietà (inverse, transitive, ecc.).
3.2.3 SPARQL
SPARQL (SPARQL Protocol and RDF Query Language) è un linguag- gio di interrogazione che permette di ottenere e manipolare dati rap- presentati in RDF.
3.3 scelta del framework
Per la memorizzazione e la gestione dell’ontologia è stato chiara- mente necessario l’utilizzo di un framework. Il vincolo per la scelta di tale framework era dettato dalle tecnologie utilizzate abitualmente dall’azienda, ovvero era necessario fosse basato su Java. I principali framework individuati sono stati Apache Jena e Sesame. Sesame è quello che offre prestazioni migliori [1], ma non supporta direttamente OWL, a differenza di Jena. La scelta è pertanto ricaduta su quest’ultimo.
3.3.1 Il framework Apache Jena
Jena è un framework Java open-source che fornisce:
• delle API attraverso le quali è possibile eseguire operazioni in lettura e scrittura su grafi RDF,
• un motore di inferenza che permette di effettuare ragionamenti su ontologie OWL e RDFS,
• il supporto di svariati meccanismi di persistenza per memo- rizzare triple RDF: database relazionali, RDF/XML, Notation 3 (N3), Turtle, N-Triples. 3.3 sceltadelframework 21
3.3.1.1 Componenti I componenti descritti in seguito costituiscono il framework Apache Jena come rappresentato in Figura 12:
Figura 12: Architettura del framework Apache Jena come rappresentata in http://jena.apache.org/about_jena/architecture.html rdf api permette di accedere a grafi, triple RDF e alle loro compo- nenti. É possibile inoltre importare grafi RDF da sorgenti esterne (file o URL), e serializzare un grafo in tutte le più comuni sintassi RDF. Le principali astrazioni sono fornite dalle classi:
• Resource: rappresenta una risorsa RDF. (risorsa spiegata in Con- cetti)
• Literal: rappresenta un letterale (numero, stringa, data, ...)
• Statement: rappresenta una tripla RDF.
• Model: rappresenta un grafo RDF. 22 progetto di stage
Listing 1: Esempio di gestione di risorse
1 /* list the statements in the Model */ StmtIterator iter = model.listStatements();
/* print out the predicate, subject and object of each statement */ while (iter.hasNext()) { 6 Statement stmt = iter.nextStatement(); // get next statement Resource subject = stmt.getSubject(); // get the subject Property predicate = stmt.getPredicate(); // get the predicate RDFNode object = stmt.getObject(); // get the object
11 System.out.print(subject.toString()); System.out.print(" " + predicate.toString() + " ");
/* * Since the object of a statement can be either a resource or a 16 * literal, the getObject() method returns an object typed as * RDFNode, which is a common superclass of both Resource and * Literal. The underlying object is of the appropriate type, so * the code uses instanceof to determine which and processes it * accordingly. 21 */
if (object instanceof Resource) { System.out.print(object.toString()); } else { 26 // object is a literal System.out.print(" \"" + object.toString() + "\""); }
System.out.println(" ."); 31 }
Listing 2: Esempio di creazione di risorse
Resource a = ResourceFactory.createResource("http://example.org/alice"); Resource b = ResourceFactory.createResource("http://example.org/bob");
4 model.add (a, RDF.type, FOAF.Person); model.add (a, FOAF.name, "Alice"); model.add (a, FOAF.mbox, ResourceFactory.createResource("mailto:[email protected]")); model.add (a, FOAF.knows, b);
inference api fornisce svariati ragionatori predefiniti per RDFS e OWL. Il ragionatore RDFS supporta quasi tutti i costrutti RDFS. Per quanto riguards OWL sono forniti tre ragionatori: OWLRea- soner che è quello di default e il più completo implementando quasi tutti i costrutti OWL Lite, OWLMini e OWLMicro ciascuno dei quali omette alcuni costrutti in modo offrire varie combinazioni completez- za/performance. Per la lista completa dei costrutti supportati/non supportati dai tre ragionatori si rimanda a [7]. 3.3 sceltadelframework 23
I ragionatori OWL forniscono supporto incompleto per la validazione. Viene testato:
• che non esistano valori per una proprietà a cui è applicata una restrizione maxCardinality(0),
• che due individui non siano definiti sia come sameAs che come differentFrom,
• che non venga inferito che la classe A è sottoclasse di B o che la classe B è sottoclasse di A se A e B sono dichiarate disjoint,
• che non esistano violazioni del Range o riguardanti la restrizione allValuesFrom per una proprietà di tipo DatatypeProperties,
• che non siano presenti più di N valori Literal per una proprietà a cui è applicata una restrizione maxCardinality(N).
Jena offre anche la possibilità di utilizzare ragionatori esternia, ad esempio Pellet che supporta OWL DL [7].
sparql api permette di interrogare e modificare un grafo RDF attraverso il linguaggio SPARQL.
Listing 3: Esempio di query
String queryString = 2 "PREFIX foaf:
ontology api fornisce funzionalità legate ai costrutti OWL e RDFS. Un banale esempio è il metodo String OntResource.getVersionInfo() che ritorna il valore della proprietà owl:versionInfo dell’ontologia rappresentata dall’istanza di OntResource.
Listing 4: Esempio di importazione di un’ontologia da file 24 progetto di stage
2 /* * creating a document manager to manage the loading of imported * ontology */ OntDocumentManager docManager = new OntDocumentManager(); 7 /* setting the paths to retrieve ontologies from filesystem */ docManager.addAltEntry(IMPORTED_ONTOLOGY_1_URI, IMPORTED_ONTOLOGY_1_PATH); docManager.addAltEntry(IMPORTED_ONTOLOGY_2_URI, 12 IMPORTED_ONTOLOGY_2_PATH); ... docManager.addAltEntry(IMPORTED_ONTOLOGY_N_URI, IMPORTED_ONTOLOGY_N_PATH);
17 /* * creating an empty ontology model which will use my document * manager */ 22 OntModelSpec spec = new OntModelSpec(OntModelSpec.OWL_MEM); spec.setDocumentManager(docManager); OntModel model = ModelFactory.createOntologyModel(spec);
/* 27 * adding RDF statements serialized in RDF/XML into the file passed * ad parameter */ model.read(fileInputStream, null);
store api fornisce meccanismi di persistenza. I principali sono due:
• SDB (SQL DataBase): gestisce la persistenza utilizzando un database relazionale;
• TDB (Triple DataBase): gestisce la persistenza in un triplestore, ovvero in un database la cui architettura è pensata apposita- mente per la memorizzazione e il recupero di triple. Un database TDB è memorizzato in una singola directory del filesystem.
Listing 5: Esempio di ottenimento di un istanza di Model da SDB
Context context = new InitialContext(); javax.sql.DataSource dataSource = (javax.sql.DataSource) context .lookup("java:" + DATASOURCE_JNDI_NAME); Connection jdbcConnection = dataSource.getConnection(); 5 StoreDesc storeDesc = new StoreDesc("layout2/hash", "MySQL");
Store store = SDBFactory.connectStore(jdbcConnection, STORE_DESC);
10 /* * creating the main tables and all indexes if the store is not well 3.4 analisideirequisiti 25
* formatted */ if (!StoreUtils.isFormatted(store)) { 15 store.getTableFormatter().create(); }
Model model = SDBFactory.connectNamedModel(store, modelName);
20 /* ... */
/* closing */ model.close(); store.close(); 25 jdbcConnection.close();
Listing 6: Esempio di ottenimento di un istanza di Model da TDB
/* obtaining the dataset */ Dataset dataset = TDBFactory.createDataset(storePath);
/* starting a write transaction */ 5 dataset.begin(ReadWrite.READ); try {
Model model = dataset.getNamedModel(modelName);
10 /* ... */
} catch (Exception e) { /* rolling back */ dataset.abort(); 15 } finally { /* ending the transaction */ dataset.end(); /* closing the dataset */ 20 dataset.close(); }
3.4 analisi dei requisiti
In questa sezione verranno presentati i principali casi d’uso e requisiti individuati durante l’analisi dei requisiti. Si noti che l’intenzione non è quella di presentare un elenco esaustivo ma quella di accompagnare il lettore alla comprensione del problema affrontato. 26 progetto di stage
3.4.1 Casi d’uso
3.4.1.1 UC1: Visualizzazione della lista ordinata dei requisiti da soddisfare per avviare l’attività
Services Directory
UC1.1: Visualizzazione della descrizione di ciascun requisito
UC1.2: Visualizzazione della lista dei servizi che l'utente dovrà utilizzare per il soddisfacimento di ciascun requisito
UC1.3: Visualizzazione della descrizione completa di Utente ciascuno dei servizi che l'utente dovrà utilizzare per il soddisfacimento di ciascun requisito
UC1.4: Visualizzazione della lista dei task da eseguire per soddisfare ciascun requisito
Figura 13: UC1: Funzionalità offerte all’utente alla visualizzazione della lista ordinata dei requisiti da soddisfare per avviare l’attività
• Attore primario: Utente.
• Precondizione: l’utente ha inserito i seguenti dati: paese di prove- nienza, professione che vuole intraprendere, tipologia di attività che vuole intraprendere e comune in cui vuole avviare l’attività.
• Scenario principale: 1. il sistema visualizza la descrizione testuale di ciascuno dei requisito, 2. il sistema visualizza la lista dei servizi che l’utente dovrà utilizzare per soddisfare ciascuno dei requisiti, 3. l’utente può visualizzare la descrizione completa di cias- cuno dei servizi, 4. il sistema visualizza la lista di task che l’utente deve es- eguire per soddisfare ciascuno dei requisiti.
• Postcondizione: il sistema ha visualizzato tutte le informazione di cui l’utente ha bisogno per poter avviare l’attività. 3.4 analisideirequisiti 27
3.4.1.2 UC1.4: Visualizzazione della lista di task da eseguire per soddisfare ciascun requisito
Services Directory
UC1.4.1: Visualizzazione della descrizione di ciascun task
UC1.4.2: Visualizzazione della lista dei documenti richiesti in input da ciascun task
UC1.4.3: Visualizzazione della descrizione completa di ciascuno dei documenti richiesti in input da ciascun task
Utente UC1.4.4: Visualizzazione della lista di documenti prodotti in output da ciascun task
UC1.4.5: Visualizzazione della descrizione completa di ciascuno dei documenti prodotti in output da ciascun task
Figura 14: UC1.4: Funzionalità offerte all’utente alla visualizzazione della lista dei task da eseguire per soddisfare ciascun requisito
• Attore primario: Utente.
• Precondizione: l’utente ha inserito i seguenti dati: paese di prove- nienza, professione che vuole intraprendere, tipologia di attività che vuole intraprendere e comune in cui vuole avviare l’attività.
• Scenario principale: 1. il sistema visualizza la descrizione testuale di ciascuno dei task, 2. il sistema visualizza, per ciascuno dei task, la lista dei doc- umenti che sono richiesti in input, 3. il sistema visualizza, per ciascuno dei task, la lista dei doc- umenti che sono prodotti in output, 4. l’utente può visualizzare la descrizione completa di cias- cuno dei documenti richiesti in input, 5. l’utente può visualizzare la descrizione completa di cias- cuno dei documenti prodotti in output.
• Postcondizione: il sistema ha visualizzato la lista di task da es- eguire per soddisfare ciascun requisito. 28 progetto di stage
3.4.1.3 UC2: Verifica contenuto OCD
OCD
UC2.1: Visualizzazione della lista dei documenti necessari per avviare l'attività che non sono presenti nell'OCD
Utente
Figura 15: UC2: Funzionalità offerte all’utente alla verifica del contenuto di un OCD
• Attore primario: Utente.
• Precondizione: l’utente ha effettuto l’upload dell’OCD ed ha in- serito i seguenti dati: paese di provenienza, professione che vuole intraprendere, tipologia di attività che vuole intrapren- dere, comune in cui vuole avviare l’attività e requisito che in- tende soddisfare con l’OCD caricato.
• Scenario principale: 1. il sistema visualizza la lista dei documenti necessari per avviare l’attività che non sono presenti nell’OCD.
• Postcondizione: il sistema ha visualizzato la lista dei documenti necessari per avviare l’attività non presenti nell’OCD.
3.4.2 Requisiti
I requisiti in seguito presentati sono tratti dal documento di “Analisi dei requisiti” redatto durante l’attività di stage. In tale documento è stata seguita la seguente norma: ciascun requisito è idenficato univo- camente da una chiave costituita da “Tipo” e “Codice“ separati dal carattere “-”. Un “Codice” è costituito da numeri separati dal carattere “.”. Se esiste un insieme di codici y1, y2, ..., yn che hanno per codice prefisso il codice x, x è soddisfatto se e solo se y1, y2, ..., yn sono soddisfatti. Il tipo individua le caratteristiche del requisito ed è una terna di caratteri in cui:
• il primo carattere indica la priorità di soddisfacimento del req- uisito. I possibili valori sono: – O: Obbligatorio, ovvero irrinunciabile per il proponente. – D: Desiderabile, ovvero non fondamentale per il propo- nente ma che aumenta il valore del prodotto. – P: oPzionale, cioè non necessario al proponente. 3.4 analisideirequisiti 29
• il secondo carattere indica la provenienza del requisito. I possi- bili valori sono: – E: Esterno, cioè requisito richiesto dal proponente. – I: Interno, cioè imposto da me per migliorare le funzional- ità del prodotto.
• il terzo carattere indica la tipologia del requisito. I possibili valori sono: – F: Funzionale, impone al prodotto di offrire certe funzion- alità. – P: Prestazionale, impone al prodotto di offrire le funzion- alità mantenendo entro certi limiti la quantità di risorse di sistema utilizzate e il tempo di computazione impiegato. – Q: di Qualità, impone al prodotto di avere determinate garanzie di sicurezza, usabilità ecc... – V: di Vincolo, ovvero che impone il rispetto di norme vi- genti, di particolari design sull’applicazione, di tecnologie usate per realizzare il prodotto, ecc...
In Tabella 1 sono presentati i principali requisiti funzionali, derivan- ti dai casi d’uso precedentemente presentati.
Chiave Descrizione OEF-1 eServices deve permettere all’utente di visualizzare la lista ordinata dei requisiti da soddisfare al fine di aprire un’attività OEF-1.1 per ogni requisito deve essere visualizzata la sua descrizione OEF-1.2 per ogni requisito deve essere visualizzata la lista dei servizi che l’utente dovrà utilizzare per il suo soddisfacimento OEF-1.3 per ogni requisito deve essere visualizzata la lista dei task che l’utente dovrà eseguire per il suo soddisfacimento OEF-1.3.1 per ogni task deve essere visualizzata la sua descrizione OEF-1.3.2 per ogni task deve essere visualizzata la lista dei documenti che esso richiede in input e produce in output OEF-2 eServices deve permettere all’amministratore di ef- fettuare l’upload di un file owl rappresentante l’ontologia OEF-2.1 l’autenticazione non deve essere gestita (è a carico del cliente) 30 progetto di stage
Chiave Descrizione DEF-1 eDocuments deve permettere all’utente di effettuare la verifica del contenuto di un OCD DEF-1.1 deve essere visualizzata la lista dei documenti necessari per avviare l’attività che non presenti nell’OCD
Tabella 1: Principali requisiti funzionali
In Tabella 2 sono presentati i principali requisiti di vincolo.
Chiave Descrizione OEV-1 per la persistenza deve essere utilizzato SDB OEV-2 il grafo RDF rappresentante l’ontologia asserita deve essere mantenuto in modo persistente OIV-1 il grafo rdf rappresentante l’ontologia inferita deve essere mantenuto in modo persistente OIV-2 le query devono essere eseguite sull’ontologia inferita
Tabella 2: Principali requisiti di vincolo
I requisiti OEV-1 e OEV-2 derivano da richieste esplicite del cliente. Il secondo ha il fine di permettere, in futuro, l’implementazione di una funzionalità che permetta all’amministratore l’inserimento e la modifica di dati nell’ontologia di origine (quella asserita). I requisiti OIV-1 e OIV-2 sono conseguenza della presa di coscenza che il processo di inferenza su un’ontologia persistente è oneroso [3]. Un’alternativa sarebbe stata quella di creare uno snapshot in RAM ma, visto che l’applicazione non modifica mai l’ontologia ed è quindi sufficiente calcolare l’inferanza al caricamento della stessa, la prima soluzione è stata considerata la più adatta.
3.4.2.1 Variazioni dei requisiti I requisiti individuati durante la fase di analisi, e approvati dal tutor aziendale, erano in parte diversi da quelli presentati. Durante le fasi successive infatti, in seguito ad un colloquio tra il tutor aziendale e l’azienda cliente, sono state imposte alcune variazioni:
• il requisito OEV-1 non era presente. Al suo posto c’era un req- uisito di vincolo interno che prevedeva l’utilizzo di TDB dato 3.5 progettazione ontologia 31
che il cliente non aveva posto alcun vincolo sul meccanismo di persistenza da adottare;
• il requisito OEV-2 non esisteva ed è stato introdotto;
• il requisito OEF-2 non esisteva. Al suo posto c’era un requisito di vincolo interno che prevedeva l’esistenza di un MBean per il caricamento dell’ontologia all’avvio dell’applicazione web. Le prime due variazioni non sono state particolarmente onerose grazie alla particolare attenzione che avevo dedicato all’estensi- bilità in fase di progettazione. In Sezione 3.6.3 sono presentati ulteriori dettagli a riguardo. La terza variazione è avvenuta dopo l’MBean era stato pro- gettato, quindi semplicemente non è stato implementato ed è stato necessario progettare un ulteriore controller e una vista dell’applicazione web eServices.
3.5 progettazione ontologia
Essendo abituato alla progettazione “ad oggetti”, prima di procedere alla progettazione dell’ontologia è stato necessario effettuare alcune letture ([10], [6]). La modalità con cui ho poi proceduto è ad alto livello la seguente:
1. analisi del dominio e dello scopo dell’ontologia,
2. considerazioni in merito al riuso di ontologie esistenti,
3. definizione delle classi e delle gerarchie,
4. definizione delle proprietà,
5. definizione delle caratteristiche delle proprietà (cardinalità, do- minio, codiminio, ecc.),
6. creazione delle istanze.
Per la rappresentazione delle ontologie ho utilizzato il profilo UML ODM.
3.5.1 Suddivisione architetturale
Analizzando il dominio da rappresentare, ho constatato che in realtà i domini da rappresentare erano tre:
• Dominio documents: rappresentante documenti e altri concetti “burocratici”.
• Dominio places: rappresentante luoghi geografici. 32 progetto di stage
• Dominio spocs-italy: rappresentante i requisiti da soddisfare per avviare un’attività imprenditoriale imprenditoriale, anche attraver- so concetti facenti parte dei due precedenti domini.
<
Figura 16: Rappresentazione della suddivisione del dominio da rappresentare
3.5.2 Considerazioni sul riuso
Per quanto riguarda documents e spocs-italy non ho trovato niente che mi potesse servire, mentre per quanto riguarda places ho utilizzato l’ontologia GeoNames (http://www.geonames.org/ontology).
3.5.3 Dominio places
Inizialmente avevo pensato di progettare un’ontologia per rappre- sentare luoghi geografici come rappresentato in Figura 17 e Figura 18. 3.5 progettazione ontologia 33
http://www.eu-spocs.eu/ontologies/spocs-places.owl
<
<
Figura 17: Ontologia rappresentante il dominio “places”
http://www.eu-spocs.eu/ontologies/spocs-places.owl
<
<
<
<
Figura 18: Relazioni tra le proprietà dell’ontologia rappresentante il dominio “places”
Un esempio di utilizzo è dato dalle seguenti asserzioni:
• “CittàDiPadova isPartOfProvince ProvinciaDiPadova”,
• “ProvinciaDiPadova isPartOfRegione RegioneVeneto”, 34 progetto di stage
dalle quali può essere inferito che:
• “CittàDiPadova isPartOf ProvinciaDiPadova” perché isPartOfProvince è una sottoproprietà di isPartOf,
• “ProvinciaDiPadova isPartOf RegioneVeneto” perché isPartOfRegion è una sottoproprietà di isPartOf,
• “CittàDiPadova isPartOf RegionVeneto” perché “CittàDiPadova isPartOf ProvinciaDiPadova”, “ProvinciaDiPadova isPartOf RegioneVeneto” e la proprietà isPartOf è transitiva.
In realtà poi ho ritenuto opportuno riusare GeoNames che mi ha fornito tutto quello di cui avevo bisogno attraverso i seguenti concetti, illustrati anche in Figura 19:
• classe Feature: rappresenta un generico luogo,
• proprietà parentFeature: rappresenta il concetto di “essere parte di”, ovvero “CittàDiPadova gn:parentFeature ProvinciaDiPadova” significa che CittàDiPadova è parte di ProvinciaDiPadova.
http://www.geonames.org/ontology
<
<
Figura 19: Rappresentazione dei concetti dell’ontologia GeoNames utilizzati
3.5.4 Dominio documents
Un ontologia rappresentante il dominio dei documenti doveva es- sere rilasciata e messa a disposizione di tutti i paesi partecipanti al progetto SPOCS prima dell’inizio dello stage, ma così non è avvenuto. 3.5 progettazione ontologia 35
La mia idea iniziale era quella di creare un’ontologia che rappresen- tasse il dominio dei documenti, mettendo in preventivo che in un sec- ondo momento si sarebbe dovuto fare un “mapping”, tra l’ontologia creata e quella rilasciata. Tuttavia, discutendo con il tutor aziendale, abbiamo deciso di non seguire questa via considerato che:
• non rientrava tra requisiti concordati tra iks e l’azienda cliente,
• a causa di una scarsa conoscenza del dominio (tipologie di doc- umenti, caratteristiche principali degli stessi, ecc) sia da parte mia che di iks, questo approcio avrebbe richiesto troppe risorse (tempo) rispetto a quelle a mia disposizione durante l’attività di stage.
L’approcio che ho dovuto quindi seguire è stato quello di creare le classi Document, Service, EService e Profession corrispondenti esat- tamente alle entità definite nel MIDB. L’unico concetto aggiuntivo che è stato definito con la classe DocumentCategory è quello di insieme di documenti equivalenti in un certo contesto. Anche nel MIDB è espres- sa l’equivalenza tra documenti, ma questa è valida sempre. Attraverso questo nuovo concetto è invece possibile rappresentare la situazione in cui per un certo task due documenti si equivalgono, mentre per un altro task no.
É evidente che l’approcio seguito è poco pulito innanzitutto dal punto di vista concettuale, visto che un’ontologia, in quanto rappre- sentazione di conoscenza, dovrebbe essere il più aderente possibile alla realtà. Inoltre una vera e propria ontologia mi avrebbe permesso molta più espressività. Ad esempio avrei ipoteticamente pututo dire che un determinato task richiede un documento di identità che abbia una foto, mentre con la soluzione adottata devo rendere esplicito che richiede un documento tra patente, carta di identità e passaporto. Ritengo quindi che ci sia molto margine di miglioramento, e che sia uno degli sviluppi futuri del progetto con maggior priorità.
3.5.5 Dominio spocs-italy
É stata progettata l’ontologia rappresentante requisiti e task rappre- sentata in Figura 20.
La classe Task è legata alle classi definite nell’ontologia http://www.eu- spocs.eu/ontologies/spocs-documents.owl attraverso le proprietà: producesDoc, requiresDoc, needService e needEService. 36 progetto di stage Document Profession <
Figura 20: Ontologia rappresentante il dominio “spocs-italy” 3.5 progettazione ontologia 37
Attraverso la proprietà isValidIn si definisce la validità di un Task in un certo luogo geografico. Concettualmente, un certo task può es- sere valido in un comune, in un’intera provincia, in un’intera regione o in tutta italia. Quando si devono estrarre tutti i task necessari a sod- disfare i requisiti per aprire un’attività in un determinato comune C, si terranno quindi in considerazione tutti i task T validi in C o in un altro luogo L tale che C geonames:parentFeature L. Ad esempio, con- cettualmente, se si devono estrarre tutti i task necessari a soddisfare i requisiti per aprire un’attività a Padova, devono essere considerati tutti i task validi nel comune di Padova, nella provincia di Padova, nella regione Veneto e in Italia.
Per quanto riguarda il rapporto tra Task e Requirement, inizial- mente si era pensato ad una relazione n-aria [4] come rappresentato in Figura 21. Il tutor aziendale ha però voluto fosse fatta la forte assun- zione, secondo me non del tutto realistica e non derivante da ciascun requisito, che un Task fosse relativo soltanto ad un Requirement ed è stata dunque definita la proprietà hasTarget come in Figura 20.
http://www.eu-spocs.eu/ontologies/spocs-italy.owl
<
<
Figura 21: Rappresentazione della relazione n-aria tra Task e Requirement 38 progetto di stage
3.5.6 Design pattern utilizzati
Per la progettazione delle ontologie sono stati usati alcuni design pattern reperiti in [5].
design pattern sequence Il design patter Sequence modella una sequenza definendo sia la nozione di precedenza che quella di precedenza diretta. Se A precede B e B precede C, allora A precede C. Se A precede direttamente B e B precede direttamente C, non si può dedurre che A preceda direttamente C. Questo design pattern è stato utilizzato per rappresentare sequenze di task e sequenze di requisiti.
design pattern set Il design pattern Set modella una collezione che non contiene elementi duplicati. È stato utilizzato per rappre- sentare una categoria di documenti.
design pattern partof Il design pattern PartOf modella la re- lazione esistente tra un’entità e le sue parti. Tale relazione è transitiva, ovvero se A è parte di B e B è parte di C, allora A è parte di C. Era stato utilizzato inizialmente per rappresentare le relazioni tra comuni, provincie, regioni e stati.
design pattern n-ary relation In OWL una proprietà è una relazione binaria: un’istanza di una proprietà rappresenta una re- lazione tra due istanze di classi. Il design pattern n-ary relation per- mette di rappresentare una situazione in cui si ha una relazione che interessa più di due istanze di classi.
3.5.7 Linked data
In accordo con l’idea dei “Linked Data” sarà opportuno, nel momento in cui l’ontologia dovesse essere resa pubblica, definire un “mapping” dei concetti rappresentati in tale ontologia con concetti equivalenti rappresentati in altre già esistenti. Questo non è stato fatto durante l’attività di stage perché non era tra i requisiti concordati tra IKS e l’azienda cliente.
3.6 progettazione componente semdb
Il componente SemDB si occupa di persistenza e offre funzionalità di accesso alle informazioni rappresentate dall’ontologia. I package significativi individuati sono:
• eu.spocs.italy.ejbsemdbclient: contiene tutto ciò che è nec- essario conoscere per poter usufruire delle funzionalità offerte dal SemDB; 3.6 progettazione componente semdb 39
• eu.spocs.italy.ejbsemdbclient.transferobjects: contiene clas- si di dominio che devono essere scambiate tra il SemDB e il client;
• eu.spocs.italy.ejbsemdb: contiene l’implementazione delle fun- zionalità di accesso al SemDB;
• eu.spocs.italy.ejbsemdb.jena: contiene l’implementazione delle funzionalità di accesso al SemDB attraverso il framework Apache Jena;
eu.spocs.italy.ejbsemdbclient
transferobjects
Requirement
TaskGroup Task
<
<
eu.spocs.italy.ejbsemdb
jena
JenaSingleStorageDAO JenaDoubleStorageDAO
<
<
Figura 22: Diagramma delle classi rappresentante il SemDB 40 progetto di stage
3.6.1 Gerarchia OntologyManager
eu.spocs.italy.ejbsemdb
<
jena
<
SDBOntologyManager TDBOntologyManager #getDatasetConnection() : DatasetConnection #getDatasetConnection() : DatasetConnection
Figura 23: Diagramma delle classi rappresentante la gerarchia OntologyManager
Interfaccia eu.spocs.italy.ejbsemdb.OntologyManager Interfaccia che rappresenta l’ontologia e offre quindi le funzionalità per l’estrazione di informazioni dalla stessa.
Classe astratta eu.spocs.italy.ejbsemdb.jena.JenaOntologyManager
Classe astratta che implementa l’interfaccia OntologyManager e rapp- resenta l’ontologia gestita attraverso il framework Apache Jena. Ques- ta classe è l’unica che ha una dipendenza verso la struttura dell’on- tologia, ovvero contiene tutta la logica necessaria all’estrazione/inser- imento di informazioni. Al fine di mantenere la logica di accesso all’ontologia ad un livello più alto rispetto al meccanismo di persistenza adottato per la stes- sa è stato implementato il design pattern Factory Method. Il metodo DatasetConnection getDatasetConnection() infatti ritorna un ogget- to di tipo DatasetConnection che rappresenta una generica connes- sione ad un dataset e le sottoclassi concrete della classe, che rap- presentano l’ontologia gestita attraverso un determinato meccanis- mo di persistenza, devono occuparsi solamente di implementare tale metodo in modo tale che ritorni la giusta connessione al dataset. 3.6 progettazione componente semdb 41
3.6.2 Gerarchia SemDBDAO
eu.spocs.italy.ejbsemdbclient
<
eu.spocs.italy.ejbsemdb.jena
JenaDoubleStorageDAO JenaSingleStorageDAO -assertedOntologyManager : JenaOntologyMana... -inferredOntologyManager : JenaOntologyManager -inferredOntologyManager : JenaOntologyManager
<
Figura 24: Diagramma delle classi rappresentante la gerarchia SemDBDAO
Interfaccia eu.spocs.italy.ejbsemdbclient.SemDBDAO Rappresenta il punto di accesso alle funzionalità offerte dal SemDB. Il metodo public void loadOntology(String path) è il metodo che espone la funzionalità di caricamento di un’ontologia ed è quel- lo che definisce la struttura dell’algoritmo di caricamento: Il metodo public List
• l’implementazione del metodo public List
• l’implementazione del metodo public void loadOntology(String path) contiene la logica legata al mecca- nismo di caricamento dell’ontologia, ma per ogni operazione sulle singole ontologie richiama metodi offerti dalla classe AbstractJenaOntologyManager come si può vedere in Figura 25 e Figura 26. 42 progetto di stage 1.2: : DocumentLoader 1.4: : ModelFactory inferredOntologyManager : inferredOntologyManager AbstractJenaOntologyManager 1.3: newInferredModel = 1.3: newInferredModel 1.1: newAssertedModel = 1.5: store(newInferredModel) : void 1.5: store(newInferredModel) readOntModel(path) : OntModel readOntModel(path) createInfModel(newAssertedModel) : InfModel createInfModel(newAssertedModel) [!this.assertedModel.isEqualTo(newAssertedModel)] {} alt : JenaSingleStorageDAO 1: loadOntology(path) : void client
Figura 25: Diagramma di sequenza che rappresenta le operazioni eseguite del metodo public void loadOntology(String path) della classe JenaSingleStorageDAO 3.6 progettazione componente semdb 43 1.2: : DocumentLoader 1.5: : ModelFactory inferredOntologyManager : inferredOntologyManager AbstractJenaOntologyManager assertedOntologyManager : AbstractJenaOntologyManager 1.4: newInferredModel = 1.4: newInferredModel 1.1: newAssertedModel = readOntModel(path) : OntModel readOntModel(path) 1.6: store(newInferredModel) : void 1.6: store(newInferredModel) 1.3: store(newAssertedModel) : void 1.3: store(newAssertedModel) createInfModel(newAssertedModel) : InfModel createInfModel(newAssertedModel) [!this.assertedModel.isEqualTo(newAssertedModel)] alt : JenaDoubleStorageDAO 1: loadOntology(path) : void client
Figura 26: Diagramma di sequenza che rappresenta le operazioni eseguite del metodo public void loadOntology(String path) della classe JenaDoubleStorageDAO 44 progetto di stage
Classe eu.spocs.italy.ejbsemdb.jena.JenaDoubleStorageDAO
Implementa l’interfaccia SemDBDAO e rappresenta il DAO in cui ven- gono salvati sia l’ontologia asserita che l’ontologia inferita. La classe ha due campi dati:
• AbstractJenaOntologyManager assertedOntologyManager rap- presentante il gestore dell’ontologia asserita;
• AbstractJenaOntologyManager inferredOntologyManager rap- presentante il gestore dell’ontologia inferita.
Il costruttore public JenaDoubleStorageDAO(AbstractJenaOntologyManager assertedOntologyManager, AbstractJenaOntologyManager inferredOntologyManager) permette di inizializzare tali campi dati con una qualsiasi implementazione della classe astratta AbstractJenaOntologyManager, mantenendo quindi la logica di ges- tione dei due storage totalmente disaccoppiata dal meccanismo di persistenza usato per gli stessi.
Classe eu.spocs.italy.ejbsemdb.jena.JenaSingleStorageDAO
Implementa l’interfaccia SemDBDAO e rappresenta il DAO in cui viene salvato solamente l’ontologia inferita. La classe ha un campo dati AbstractJenaOntologyManager ontologyManager rappresentante il ge- store dell’ontologia inferita. Il costruttore public JenaSingleStorageDAO(AbstractJenaOntologyManager ontologyManager) permette di inizializzare tale campo dati con una qualsiasi implementazione della classe astratta AbstractJenaOntologyManager, mantenendo quindi la logica di ges- tione dello storage totalmente disaccoppiata dal meccanismo di per- sistenza usato per lo stesso.
3.6.3 Conseguenze delle variazioni dei requisiti
Come discusso in Sezione 3.4.2.1 ci sono state della variazioni dei requisiti a progettazione avvenuta. Tali variazioni non hanno avuto un grave impatto sulla pianificazione, in quanto sono state gestite in tempi relativamente brevi grazie ad una progettazione modulare ed attenta a garantire estendibilita. La variazione in pratica ha imposto l’utilizzo di SDB al posto di TDB e che l’ontologia asserita fosse mantenuta in modo persistente. É stato sufficiente:
• creare la classe SDBOntologyManager, ovvero implementare l’u- nico metodo astratto getDatasetConnection();
• creare la classe JenaDoubleStorageDAO, ovvero: 3.6 progettazione componente semdb 45
– implementare il metodo che permette di ottenere i requisiti semplicemente con una redirezione di chiamata; – implementare il metodo che permette il caricamento del- l’ontologia in modo tale che salvi in modo persistente an- che l’ontologia asserita.
• modificare il file di configurazione xml di Spring in modo tale che venga iniettata un’istanza della classe SDBOntologyManag- er, anziché della classe TDBOntologyManager, alla creazione di istanze della classe JenaDoubleStorageDAO;
• modificare il file di configurazione xml di Spring in modo tale che alla creazione dell’ejb sia istanziata la classe JenaDoubleStor- ageDAO anziché la classe JenaSingleStorageDAO.
3.6.4 Il Point of Single Contact italiano dopo lo stage
In Figura 27 e Figura 28 sono rappresentati i diagrammi delle compo- nenti delle applicazioni eServices ed eDocuments, che evidenziando come queste sono state evolute durante l’attività di stage.
<
SemDBDAO
<
<
SearchOM TransformationOM
<
Figura 27: Diagramma delle componenti dell’applicazione web eServices dopo l’evoluzione 46 progetto di stage
<
Processing Authentication Extraction SemDBDAO
<
<
SearchOM TransformationOM
<
Figura 28: Diagramma delle componenti dell’applicazione web eServices dopo l’evoluzione VISIONERETROSPETTIVA 4
In questo capitolo sono riportate alcune considerazioni retrospettive, in particolare riguardo al valore prodotto dall’esperienza di stage e riguardo il divario tra il mondo accademico e il mondo del lavoro.
4.1 bilancio rispetto alla pianificazione
Seguono alcune considerazioni in merito al soddisfacimento degli obiettivi fissati in fase di pianificazione.
4.1.1 Obiettivi minimi
La totalità degli obiettivi minimi è stata raggiunta. progettazione e realizzazione semdb • Stato: raggiunto. • Considerazioni: ho studiato i concetti e le tecnologie alla base dell’idea di Semantic Web, poi ho progettato l’ontologia, che è stata poi realizzata attraverso il prodotto Protegé. Ho inoltre progettato e implementato il componente SemDB che, attraver- so il framework Apache Jena, si interfaccia con l’ontologia. evoluzione applicazione web eservices • Stato: raggiunto. • Considerazioni: ho evoluto l’applicazione eServices implemen- tando un nuovo controller e una nuova view in modo tale che si interfacci con il SemDB per l’ottenimento di informazioni, al fine di mostrarle all’utente. documentazione tecnica • Stato: raggiunto. • Considerazioni: ho prodotto documenti all’interno dei quali ho presentato i requisiti individuati, la progettazione dell’ontolo- gia, la progettazione del componente SemDB, considerazione sulle scelte progettuali effettuate sia per quanto riguarda l’on- tologia che per quanto riguarda il SemDB ed infine la pianifi- cazione ed i risultati della qualifica. Parti di tali documenti sono riprodotte in questa relazione. Inoltre tutto il codice prodotto è stato documentato con Javadoc.
47 48 visione retrospettiva
4.1.2 Obiettivi massimi
La quasi totalità degli obiettivi massimi è stata raggiunta, con la soddisfazione del tutor aziendale.
documentazione strumenti e tecnologie
• Stato: raggiunto.
• Considerazioni: ho prodotto documentazione utilizzabile come base di partenza dalle risorse aziendali che in futuro dovranno affrontare le stesse problematiche della mia attività di stage: – un documento sul framework Apache Jena comprensivo di una panoramica sull’architettura dello stesso, della de- scrizione dei vari componenti e di frammenti di codice di esempio che coprono tutte le funzionalità utilizzate, – un documento che spiega in dettaglio come utilizzare il prodotto Protegé per l’inserimento di dati all’interno del- l’ontologia.
evoluzione applicazione web edocuments
• Stato: raggiunto.
• Considerazioni: ho evoluto l’applicazione eDocuments, imple- mentando un nuovo controller e nuove view, in modo tale che si interfacci con il SemDB per poter effettuare il controllo di validità di un OCD.
configurazione apache maven
• Stato: non completamente raggiunto.
• Considerazioni: per l’applicazione eServices non era utilizza- to Apache Maven, mentre per l’applicazione eDocuments si. Nonostante non ci stato il tempo per uno studio approfondito di Apache Maven e l’introduzione del suo utilizzo in eServices, ho comunque comunque appreso il suo funzionamento di base modificando il Project Object Model del progetto eDocuments. 4.2 bilancio delle conoscenze 49
4.2 bilancio delle conoscenze
L’esperienza di stage non mi ha permesso soltanto di apprendere nuove tecnologie, ma ho potuto vedere come vengono utilizzati in un ambiente professionale concetti e tecnologie che avevo già incontrato durante il mio percorso di studi. É stato interessante metter mano ad applicazioni sviluppate professionalmente con il framework Spring Web MVC, notando come sia efficiente l’utilizzo di tale framework. In un progetto universitario infatti ho progettato un’applicazione, imple- mentando il pattern achitetturale MVC, senza l’utilizzo di un frame- work e mi sono scontrato con la necessità di creare un gran numero di classi, cosa che Spring Web MVC permette di evitare. Inoltre è stato interessante l’utilizzo, anche se minimo, dello strumento per la gestione di progetti Maven.
Il fatto che l’attività di stage si sia svolta in un contesto aziendale mi ha permesso di acquisire familiarietà con alcune nozioni quali organizzazione aziendale, procedure aziendali e ruoli, anche grazie ad un ambiente giovane ed informale. Particolarmente interessante è stato comprendere quali sono le aree di interesse in cui l’azienda si propone e di che cosa si occupano le Business Unit con cui non ho avuto contatto diretto.
Ritengo pertanto che questo primo inserimento nel mondo del la- voro sia stato molto utile, molto più rispetto all’apprendimento di tecnologie, che possono essere considerate un semplice mezzo per la risoluzione di problemi.
4.3 divario tra università e mondo del lavoro
Considerando il soddisfacimento della quasi totalità degli obiettivi nei tempi previsti posso dire di aver soddisfatto le aspettative del- l’azienda. Ne segue che i mezzi in mio possesso, appresi durante il percorso di studi, sono risultati adatti ad affrontare l’attività di stage.
Parlo di “mezzi” perché parto dal presupposto che l’università non debba fornire conoscenze tecnologiche, ma conoscenze metodologiche che permettano allo studente, tra l’altro, di acquisire conoscenze tec- nologiche autonomamente. Questo sia a causa della velocità con cui le tecnologie si evolvono, sia a causa dell’enorme numero di diverse aree specifiche che non sarebbe pensabile trattare all’interno di un corso di laurea.
BIBLIOGRAFIA
[1] Berlin SPARQL Benchmark Results. http://www4.wiwiss.fu- berlin.de/bizer/BerlinSPARQLBenchmark/results/index.html.
[2] Enterprise JavaBeans (EJB) integra- tion. Spring Framework Reference, http://static.springsource.org/spring/docs/current/spring- framework-reference/html/ejb.html.
[3] Jena Ontology API - Working with persistent ontologies. http://jena.apache.org/documentation/ontology/index.html#working- with-persistent-ontologies.
[4] Defining N-ary Relations on the Semantic Web.W3C, http://www.w3.org/TR/swbp-n-aryRelations.
[5] Ontology Design Patterns. http://ontologydesignpatterns.org.
[6] A Semantic Web Primer for Object-Oriented Software Developers. W3C, http://www.w3.org/TR/sw-oosd-primer.
[7] Reasoners and rule engines: Jena inference support. http://jena.apache.org/documentation/inference/index.html.
[8] SPOCS Deliverable D4.8: Concept for semantic technology and semantic interpretation.
[9] Grigoris Antoniou and Frank van Harmelen. A Semantic Web Primer. The MIT Press, 2nd edition, 2008.
[10] Natalya F. Noy and Deborah L. McGuinness. Ontology Development 101: A Guide to Creating Your First Ontology.
51
GLOSSARIO
AJAX Asynchronous Javascript And XML. 5 Apache Maven strumento software per la gestione e la build automation di progetti Java. 14, 15, 48 API Application Programming Interface. 4, 20 application server software che implementa l’infrastruttura per l’ese- cuzione di applicazioni fornendo servizi quali transazionalità, bilanciamento del carico e gestione di sistemi distribuiti. 4
CVS Concurrent Versions System. 4
deploy insieme delle attività che hanno il fine di rendere un’applicazione disponibile per l’uso. 4
GUI Graphical User Interface. 5
IT Information Technology. 1, 2
J2EE Java Platform, Enterprise Edition. 5, 14 J2SE Java Platform, Standard Edition. 4 Java Code Convention convenzioni per la produzione di codice in linguaggio Java. 3
MVC Model View Controller. iii, 4, 49
ODM Ontology Definition Metamodel. 31 ORM Object Relational Mapping. 4, 5
profilo UML estensione del linguaggio di modellazione a ogget- ti UML che risponde alle necessità di modellazione legate a particolari domini applicativi o tipologie di applicazioni. Il meccanismo di estensione del linguaggio UML è parte integrante dello standard del linguaggio stesso, e prevede la definizione e l’uso di una serie di appositi concetti, come ad esempio gli stereotipi. 31
53 54 bibliografia
Project Object Model configurazione di un progetto gestito attraverso Apache Maven comprendente il nome del proget- to, le dipendenze verso altri progetti, le varie fasi del processo di build, ecc. 48 Protegé strumento software open-source per la creazione e la modifica di ontologie. 48
sistema di ticketing software che permette da un lato al cliente di richiedere la correzione di un bug che ha riscon- trato o l’evoluzione di una funzionalità, e dall’al- tra permette il controllo delle avvitità che cias- cuna risorsa aziendale sta svolgendo in un dato momento. 3 sistema di versionamento sistema per la gestione dei cambiamenti del codice sorgente di un progetto software. 4