In questo articolo racconteremo come stiamo progettando e realizzando un framework semantico che, a partire dalle esperienze derivanti da consulenze su progetti open source reali, permetta una catalogazione, una valutazione metrica e una organizzazione dei giudizi e delle considerazioni dei consulenti. Tutto ciò allo scopo di creare una “base di conoscenza” affidabile e che possa essere condivisa da tutti i componenti del gruppo di lavoro.

Introduzione

In questa miniserie di articoli vogliamo raccontare l’esperienza diretta che uno dei nostri gruppi di lavoro sta conducendo: la definizione di un framework semantico per la catalogazione, ricerca e valutazione dei prodotti opensource.

Il motivo che ha fatto partire questo progetto è legato a una precisa esigenza interna, derivante dal tipo di attività che i nostri consulenti svolgono regolarmente. Essi infatti devono condividere con i colleghi o con i clienti le esperienze di progetto o di consulenza relativamente a know how, skills tecnologici, semplici esperienze. Si provi a immaginare lo scenario in cui un architetto abbia lavorato a un progetto basato su SOA/ESB utilizzando diversi prodotti al fine di identificare quello migliore o quello che si adatta meglio alle richieste e specifiche del cliente: il bagaglio di informazioni raccolte al termine di questa attività sono preziosissime per i colleghi che non hanno partecipato al progetto. Ci troviamo quindi con nozioni ed esperienze che sono ben chiare a chi ha avuto modo di lavorarci direttamente ma il cui trasferimento non è affatto banale (o comunque ha un costo derivante dal bloccare il fornitore dell’informazione e il destinatario per il periodo dedicato allo skill transfer).

Condividere le conoscenze: una knowledge base

Il problema di far fluire informazioni all’iterno di un gruppo di lavoro non è la sola difficoltà che incontra un team esteso (e nel nostro caso è anche distribuito): vi è anche la problematica di classificare tutte le informazioni e i dati raccolti in un progetto: dal punto di vista di colui che ha svolto una attività su un progeto, le tecnologie e i prodotti sperimentati possono essere banalmente ordinati sotto il cappello “una consulenza su ESB”; ma gli stessi prodotti e le medesime tecnologie per chi non ha partecipato direttamente al progetto potrebbero essere inquadrati sotto una visione sostanzialmente differente. Anche senza saperlo infatti uno dei prodotti che sono stati catalogati come strumenti per fare consulenze su ESB, potrebbero con successo rispondere alla domanda su quali possano essere i prodotti JavaEE che rispettino determinati requisiti di qualità (p.e. funzionalità, robustezza, scalabilità, documentazione, etc.) per la realizzazione di un sistema di integrazione SOA in ambito bancario. Detto in maniera più semplice lo stesso oggetto potrebbe essere visto come prodotto da un lato e come soluzione architetturale dall’altro; potrebbero cambiare le visioni d’impiego, potrebbero cambiare le parole chiave per la ricerca; lo stesso strumento potrebbe essere due cose completamente differenti a seconda del punto vista, ovvero della classificazione. È quindi un problema di definire delle tassonomie, delle proprietà, e di effettuare delle classificazioni in base a delle regole ontologiche. In una parola è un problema semantico.

Dopo la fase di definizione della ontologia, il lavoro si concentrerà su una prima concretizzazione del progetto tramite la realizzazione di un tool per il servizio di OS Front Desk che faciliti l’operatore nella ricerca delle informazioni e valutazione delle caratteristiche in base alle richieste del cliente. A lungo termine l’obbiettivo del progetto (provvisoriamente definito internamente “help desk semantico”) sarà quello di arrivare alla definizione di una architettura semantica general purpose riapplicabile su domini verticali differenti (p.e.: governance, service-registry…). Per un preciso requisito di business, lo strumento che andremo a realizzare dovrà quindi permettere di ritrovare informazioni catalogate in maniera sensata e relativamente ai soli prodotti e progetti open source.

In prima istanza il framework prevede quindi un set di strumenti opportunamente integrati che permettano:

• consultazione dei prodotti e relative valutazioni
• ricerca di prodotti
• aggiunta di nuovi prodotti
• modifica/aggiornamento dei prodotti già esistenti

Il semantic help desk

Lo scopo del progetto in questione è stato quindi quello di realizzare un sistema che permettesse di raccogliere tutte queste informazioni e di classificarle secondo una opportuna ontologia che permettesse di realizzare la raccolta di schede progetto secondo vari criteri di classificazione. Come facilmente si deduce dal significato della parola “classificare”, questa operazione è in definitiva unbanael problema di assegnazione di un elemento a una determinata classe di appartenenza. Questa condivisibile e potremmo dire perfino pleonastica affermazione in realtà nasconde un paio di aspetti tutt’altro che banali: è necessario definire una classificazione e poter poi applicare una metrica di valutazione per poter dividere i progetti. Banalmente ci appare chiaro che quello che informalmente possiamo etichettare come un application server non maturo, non è altrettanto facile da giustificare con rigor di logica (o con un punteggio) che sia da inserire nella classe di prodotti non pronti per andare in produzione.

Prima di passare alla fase implementativa si è quindi dovuto lavorare approfonditamente (lavoro che al momento in cui si scrive questo articolo non è ancora giunto a termine) sul modello teorico del prodotto in modo da arrivare da un lato a definire una ontologia adatta a classificare progetti/prodotti open source, dall’altro ad avere uno strumento di valutazione. Nel nostro caso abbiamo deciso di approcciare il compito della valutazione tramite la definizione di un maturity model.

Il lavoro si è quindi diviso ed è stato portato avanti su due binari paralleli: definizione della ontologia e la ricerca e adozione di un maturity model utile allo scopo.

Per quanto concerne la realizzazione della ontologia si è deciso di partire da una esistente (DOAP), nata come strumento per la descrizione di progetti e di prendere il lavoro fatto per la definizione di alcuni maturity model già affermati, procedendo a modellare una estensione che permettesse di descrivere il livello di maturità di un prodotto Open Source: l’ontologia è stata per questo denominata OSS-DOAP. Su questa ontologia si sono poi specializzare le categorie dei vari prodotti.

Scelta dell’ontologia di base: DOAP

L’ontologia DOAP è stata scelta come modello da estendere in quanto definisce il modello generico di progetto software oltre ad alcune proprietà basilari che, sfruttando i concetti derivanti da FOAF e WordlNET, ne permettono una utile estensione. In figura 1 se ne riporta la tassonomia completa:

 

 

Figura 1 – Tassonomia completa di DOAP.

Nella figura 2, si mostra il class diagram relativo al modello base:

Figura 2 – Class Diagram UML di un progetto DOAP.

Le classi definite direttamente da DOAP sono:

Project (sottoclasse di foaf:Project e world Net:Project)

Repository

ArchRepository

SVNRepository

BKRepository

CVSRepository

Version

Project è specializzato a partire dalle proprietà di WordNet + FOAF con una serie di proprietà specifiche che sono riportate nella figura 3.

Figura 3 – Le proprietà specifiche definite dal modello DOAP.

La definizione del modello di maturità

La necessità e l’utilità dell’introduzione di una metodologia di misurazione dovrebbe essere a questo punto piuttosto evidente: come nel caso della ontologia, si è deciso di procedere partendo dal lavoro già fatto da altri per poter poi specializzare o estendere il maturity model.

Il gruppo di lavoro è per questo motivo partito dall’analisi di alcune metodologie di valutazione già affermate in ambito open source:

• OSMM – CapGemini (considera solo le caratteristiche tecniche)
• OSMM – Navica (considera solo le caratteristiche tecniche)
• OBRR (open source)
• QSOS (open source)

Per ragioni di spazio non entreremo dettagliatamente nella analisi di queste metodologie ma si cercherà invece di censirne le caratteristiche principali per poter poi scegliere quelle che rispondano ai requisiti di progetto; per la natura stessa del tipo di progetto (ovvero catalogare prodotti open source) di particolare interesse risultano le due metodologie open source, ossia OBRR e QSOS. Per chi desidera approfondire, comunque, nel PDF allegato (MetodologieValutazione.zip) è riportata una più estesa trattazione del tema. È possibile scaricarlo a partire dal menu in alto a sinistra.

Una architettura possibile per il framework semantico

Prima di passare alla progettazione specifica dell’ontologia, è necessario delineare bene l’architettura semantica che si intende definire. Cerchiamo quindi di capire quali ontologie definire e come esse dovranno essere organizzate fra loro e quali saranno i servizi e le applicazioni che completeranno il framework semantico.

Il modello adottato è quello a stack tipico delle architetture semantiche: al livello base si trovano il modelli (sempre più specializzati man mano che si sale), e poi le istanze, le regole e infine servizi e applicazioni. In figura 4 è riportato il diagramma architetturale del framework nel suo complesso: a partire da OSMMO sarà possibile creare le ontologie verticali specializzate per categoria di prodotto. In questo modo si viene a delineare una architettura semantica a layer costituita da:

• modello base per la descrizione dei progetti costituito da DOAP;
• modello esteso per la descrizione dei progetti OS costituito da OSMMO;
• modello specializzato costituito dalle n ontologie verticali di categoria di prodotto;
• un livello di regole semantiche;
• un livello di istanze inserite da Data Entry o eventualmente generate automaticamente a partire da fonti esterne;
• un livello di servizi per le ontologie e role-engine/reasoning;
• livello applicativo (portlet liferay per il data entry, Webapp specifiche, SWED etc.).

Figura 4 – Diagramma a livelli dell’architettura

 

Requisiti dell’ontologia OSMMO

L’ontologia che si vuole realizzare deve quindi specializzare le classi di DOAP o semplicemente estenderle tramite l’ausilio di nuove proprietà al fine di:

• fornire il modello per l’annotazione e valutazione interna dei prodotti OS;
• armonizzare insieme le principali caratteristiche e ranking di “maturità” individuate dai MM precedentemente descritti;
• arricchire la classe “Project” di DOAP con le proprietà specifiche per il MM e quelle di annotazione.

OSMMO non definisce nessuna caratteristica tecnica del prodotto e risulta ancora (come DOAP) totalmente orizzontale rispetto alle varie categorie di prodotti. Essa infatti dovrà conciliare le caratteristiche di ranking per la valutazione dei prodotti con proprietà più descrittive (che chiameremo “note”) utili ai consulenti per “annotare” nel tempo eventuali opinioni inerenti il prodotto open source. Ciò, essenzialmente, ha lo scopo di non ridurre tutta la valutazione ad una serie di score numerici (utili comunque per elaborazioni automatiche e/o come informazioni di carattere indicativo) ma al contrario di dare una connotazione più descrittiva e dinamica agli aspetti di maturità del prodotto.

Ai fini della progettazione sarà necessario decidere che linguaggio adottare. Ovviamente la possibile scelta cade su RDF o su OWL DL; a tal proposito il gruppo di lavoro si sta orientando sul secondo per la maggiore espressività e ricchezza di costrutti specifici per modellare le ontologie e per poter supportare facilmente l’uso in futuro di una serie di tecnologie e linguaggi che si basano su OWL e sulla possibilità di sfruttare la Description Logic per fare inferenza.

A questo proposito è convinzione che l’uso in futuro di Semantic Web Rules come SWRL per fare inferenza sui dati potrebbe essere un fattore assolutamente vincente per automatizzare il processo di assessment e selezione di un prodotto open source a partire da determinati requisiti.

OSMMO: classificazione delle proprietà

Le proprietà prese in considerazione al momento sono quelle riassunte nella Tabella 1.

Tabella 1 – La classificazione delle proprietà, con l’indicazione della metodologia valutativa da cui provengono.

Come si può vedere vi sono proprietà e sotto-proprietà che le specializzano. Questo tipo di classificazione verrà modellata in OSMMO tramite il meccanismo di subclassing delle relazioni di RDFS (subPropertyOf) che permette di raggruppare le proprietà usando delle super-property dalle quali ereditano dominio e range (opportunamente ristretto).

Figura 5 – Tassonomia delle proprietà.

Mantenendo questa tassonomia delle proprietà, sarà quindi possibile consultare e visualizzare solo certe categorie di proprietà e mantenere una strutturazione delle varie relazioni che di fatto costituisce una meta-informazione di modello. Le proprietà saranno principalmente di due tipi.

Ranking

Definiscono un punteggio rispetto ad un range predefinito che indica il livello di maturità rispetto a quella particolare caratteristica (documentazione, attività della community etc.). Sono tutti i ranking della tabella 1.

Notes

Sono annotazioni testuali libere che arricchiscono il ranking di una caratteristica con valutazioni soggettive dei consulenti.

Esiste anche una terza tipologia relativa a quelle proprietà che risultano già testuali come ad esempio “known problems” o “comments”.

Proprietà di Ranking

Le proprietà di ranking saranno principalmente DataType property con dominio un doap:Project e codominio il range di raking deciso (range di interi o enumerazioni di caratteri).

Figura 6 – Schema Domain-Range di esempio di proprietà di ranking.

Sia le super-property che le sub-property di ranking potranno essere valorizzate; ciò introduce il problema della valorizzaione indiretta di una super-property in relazione ai valori delle sue sub-property.

Supponiamo per esempio che docDeveloperCreated_ranking, docCommercialPublished_ranking e docWebPosting_ranking abbiano un valore “alto”: è presumibile che la proprietà madre documentation_ranking (categoria che raggruppa le tre proprietà) abbia anch’essa un valore “alto”.

Si dovrà quindi prevedere in che modo vengano valorizzate le super-property: se derivate dalle sub-property o se scollegate e indipendenti (con rischio di incoerenza di valori)

Tutte le proprietà di ranking sono sub_properties della super property maturity ranking che definisce dominio e codominio ereditato poi da tutte le sotto proprietà. La massima profondità di questa classificazione di proprietà è tre:

maturity_ranking

 

 

Per chiarezza si riporta un esempio (in RDF) dell’effettiva valorizzazione del ranking:

    Java
    
. . .
     B 
     A

Proprietà di Note

Come si è detto, nell’ottica di arricchire i ranking con valutazioni più descrittive e periodiche di certe caratteristiche di maturità, si è previsto di associare per ogni ranking una relativa proprietà di note con possibili valori multipli (a differenza del valore unico per il ranking).

Anche per queste proprietà si è deciso di mantenere una tassonomia che di fatto è speculare a quella dei ranking e ha come radice la super-property “hasNote”.

 

 

A differenza dei ranking però, nel caso delle note, è necessario fare affermazioni (meta-informazioni) sulla valorizzazione di una proprietà. In particolare si è deciso di tener traccia di alcune meta informazioni quali:

• autore della nota
• data di aggiunta della nota

Ciò comporta la creazione di una entità MaturityNote che una volta istanziata possa mantenere tali informazioni. Per questo motivo le proprietà di tipo hasNote non saranno DataType property (relazioni istanza – literal) bensì Object property, ossia relazioni fra istanze di Project e istanze di MaturityNote.

In figura 8 mostriamo lo schema di relazioni fra doap:Project, osmmo:MaturityNote e relative proprietà delle note:

 

 

Dallo schema si evince che un progetto DOAP può avere più MaturityNote (osmmo:hasNote) e che in ogni MaturityNote l’informazione Autore viene modellata come una Object property chiamata “hasAuthor” che fa riferimento a una foaf:Person, mentre l’infromazione della data viene modellata riutilizzando la DataType property doap:created definita su literal. Infine l’informazione principale, ossia il testo della nota, viene mappata riutilizzando la relazione (annotation) standard rdfs:comments.

Anche in questo caso riportiamo un esempio di RDF che utilizza le proprietà di note su un progetto e definisce una MaturityNote:

    Java
    
. . .
    
    . . .

. . .

    
        2009-06-08
        UNA NOTA SUL LIVELLO DI MATURITY DI STABILITA'

Considerazioni sulla ontologia OSMMO

Possiamo dire che OSMMO sia ancora in una versione alpha e quindi ancora soggetta a modifiche e miglioramenti. Si tenga presente che OSMMO è una ontologia di modello statica ossia un insieme di classi, proprietà e restrizioni che definiscono in maniera formale il dominio in cui si vuole operare con i vincoli individuati. Ciò fa si che il raggiungimento di uno stadio di maturità finale del progetto sia molto importante ai fini degli sviluppi futuri. Dal modello OSMMO infatti discenderanno le istanze dei progetti con relative note e ranking sul livello di maturità. È quindi indispensabile giungere a una versione stabile prima della effettiva generazione delle istanze per non dover poi effettuare complesse operazioni di refactoring.

Infine alcune considerazioni più tecniche sull’ontologia vanno fatte a proposito del modello definito. In particolare sulle proprietà di Note si è visto che la necessità di tener traccia di autore e data si traduce in meta-informazioni relative alla valorizzazione di proprietà. Poiche’ in OWL-DL non è possibile fare affermazioni sulla valorizzazione di proprietà (pratica conosciuta in RDF come “reificazione”) si è deciso di introdurre una classe apposita intermedia (MaturityNote) che tenga traccia di queste informazioni (hasAuthor e Date appunto).

Questa pratica è abbastanza comune in OWL e purtroppo tende a sporcare l’ontologia di strutture non realmente pertinenti col dominio che si vuole modellare. Per intenderci, autore e data di una nota di maturità non portano informazioni aggiuntive sul livello di maturità di un progetto.

Per ovviare a questo problema si sta prendendo in considerazione da tempo l’uso di un middleware semantico che, fra le altre cose, possa mantenere meta informazioni sugli statement come appunto utente che l’ha creato lo statement e la data. In questo modo queste informazioni non dovrebbero essere modellate all’interno dell’ontologia OSMMO che quindi potrebbe semplicemente definire una nota di maturità come una normale DataType Property testuale: Project -> hasNote -> xsd:String

Conclusioni

In questo primo articolo si è cercato di presentare i primi risultati di un progetto di studio che stiamo portando avanti all’interno del nostro gruppo di lavoro. Il percorso che ci porterà alla realizzazione di quello che per il momento è stato convenzionalmente definito “help desk semantico” parte dalla definizione teorica degli strumenti formali per poter realizzare un archivio semantico dei progetti open source: tale archivio passa dalla creazione di una ontologia per la classificazione di un progetto. Con tale ontologia possiamo dire che in base a un determinato punto di vista un progetto assume determinate caratteristiche: ad esempio nell’ottica di una classificazione architetturale, un determinato prodotto può assumere il ruolo di motore di integrazione, mentre se si parla di architettura JavaEE, lo stesso prodotto può essere visto come un semplice container.

Ma la classificazione non è tutto quello di cui abbiamo bisogno; serve anche un modo per valutare la bontà di un progetto. Se si rinconsidera l’esempio di prima, al termine di una certa attività di consulenza il nostro collega potrebbe desiderare condividere con i colleghi, ma anche con altri clienti se lo si ritiene utile, alcune valutazioni circa la bontà del prodotto in esame, il grado di maturità, il rispetto della aspettative. Serve quindi uno modello per poter definire una serie di punteggi relativamente a delle metriche prefissate e già condivise nel mondo opensource. In una parola serve un maturity model.