Conclusioni
Nel corso di questo studio, non solo abbiamo individuato un insieme di requisiti, ma abbiamo anche verificato se questi possono essere o sono già soddisfatti dal sistema KDDML. Sono stati inoltre forniti una serie di spunti sui quali riflettere prima di intraprendere l’implementazione vera e propria dell’interfaccia grafica per tale sistema.
In Figura 6.1 è rappresentata una possibile architettura ad alto livello di KDDML, basata sulle ipotesi e le osservazioni condotte nel corso del capitolo 5.
Bisogna innanzitutto evidenziare che tale architettura non è definitiva e rappresenta solo una possibile strutturazione del sistema, prevista con l’introduzione del livello GUI.
Figura 6.1 Architettura ad alto livello del sistema KDDML con l’introduzione del livello GUI.
Andiamo ad analizzare più in dettaglio tale architettura. Appare subito evidente la scelta di suddividere la GUI in due applicazioni distinte. Le uniche informazioni che le due applicazioni si scambiano riguardano il path che permette di localizzare l’oggetto fisico da visualizzare all’interno del repository. La freccia che unisce la GUI VISUALIZER al repository dei dati si riferisce al fatto che quest’ultima accede direttamente ai file contenuti in essa.
Per quel che riguarda la GUI DEVELOPER, essa deve interfacciarsi con tutti i livelli del sistema, per ottenere le informazioni necessarie al suo funzionamento.
Questo è necessario, poiché, come richiesto dal requisito R. 3.1, il livello GUI non deve essere modificato nel momento in cui si espande il sistema.
Le interazioni riguardano:
• Il livello repository, poiché il livello GUI deve accedere ad informazioni sui tipi implementati nel sistema, ed in particolare ai modelli supportati, per garantire estensioni future di KDDML.
• Il livello operators, per permettere al livello GUI di capire quali operatori sono presenti nel sistema, e quali sono i parametri necessari al loro funzionamento.
• Il livello interpreter, per fornire al livello GUI informazioni sull’esecuzione o meta-esecuzione della query, al fine di presentare eventuali errori o informare quando l’esecuzione della query è finita, etc.
Nel corso delle ultime pagine del capitolo 5, abbiamo inoltre fatto riferimento anche alla possibile introduzione di un compilatore e di un ottimizzatore. Per entrambi bisogna decidere a che livello dell’architettura inserirli, e se integrarli o meno con i livelli già esistenti. Ad esempio, il compilatore può essere integrato direttamente nella GUI DEVELOPER, sfruttando tutte le informazioni sul sistema
KDDML a cui quest’ultima può accedere, invece l’ottimizzatore può essere integrato all’interno del livello interpreter.
Un’altra possibile soluzione potrebbe essere quella di vedere il compilatore e/o l’ottimizzatore come un livello intermedio tra la GUI ed il sistema. Tuttavia bisogna evidenziare che, anche in questo caso, devono essere garantite, per questi nuovi moduli, caratteristiche già discusse per l’introduzione della GUI, come ad esempio la necessità di non doverli modificare ogniqualvolta si inserisca un nuovo elemento nel sistema. In Figura 6.1 le parti tratteggiate indicano come le varie componenti possono essere integrate tra loro. A nostro avviso la prima soluzione è sicuramente quella più facilmente implementabile, senza complicare ulteriormente la struttura del sistema
Nel nostro studio abbiamo presentato i vari argomenti, evitando volutamente di entrare troppo in dettaglio sulla struttura ed il codice sorgente di KDDML, poiché sarà compito di colui che implementerà l’interfaccia confrontarsi con le scelte di implementazione presenti nel sistema attuale, e con i problemi che tali scelte possono comportare nella stesura della GUI stessa.
Come potevamo aspettarci, gli interrogativi ancora aperti sono molti, e molti di essi troveranno risposta solo nel momento di effettiva implementazione dell’interfaccia.
Ci siamo comunque potuti rendere conto che i requisiti forniti non sono così ben distinti ed indipendenti, come potrebbe apparire dalla loro presentazione nel capitolo 4. In alcuni casi tali requisiti si intersecano, come nel caso di R. 2.0 e R. 8.0, mentre in altri appaiono in antitesi, come nel caso dei requisiti R. 3.0 e R. 3.1.
L’implementazione reale della GUI richiede quindi ulteriore studio, partendo da quanto espresso nel capitolo finale, per compiere scelte ben precise, in alcuni casi andando verso dei compromessi, in altri eliminando o ampliando il raggio di azione di requisiti ritenuti troppo restrittivi.
A nostro avviso, deve essere concepita una gerarchia di tali requisiti, che tenga in considerazione alcune proprietà ritenute importanti dal progettista, per esaltare al meglio sia caratteristiche della sola interfaccia sia dell’intero sistema. Attraverso questa gerarchia si possono fissare dei punti ritenuti fondamentali, e
successivamente si possono andare a manipolare gli altri, in modo da ottenere un buon compromesso tra tutti i requisiti ritenuti importanti.
Noi, seppur in maniera implicita, abbiamo comunque cercato di dare più importanza a taluni requisiti piuttosto che ad altri. Se in un primo tempo li abbiamo presentati tutti su uno stesso piano, poiché rappresentavano elementi importanti rilevati nell’analisi dei vari sistemi nel corso dei capitoli 3 e 4, dalle osservazioni condotte nel corso del capitolo 5, appare chiaro che esistono dei punti fermi nell’implementazione dell’interfaccia e nell’evoluzione di KDDML.
Sebbene uno studio di questo tipo non possa prescindere dall’intero elenco dei requisiti forniti, ve ne sono almeno 3 che garantirebbero a KDDML caratteristiche non riscontrate o riscontrate solo in parte nei software analizzati. Tali requisiti riguardano la suddivisione in fasi del processo, il livello GUI indipendente e per questo aggiornabile senza modifiche esplicite, e la meta-esecuzione. Il pieno supporto a tali richieste garantirebbe peculiarità che renderebbero KDDML un eccellente software, diversificandolo soprattutto da strumenti come WEKA e YALE, che rappresentano un punto di riferimento in ambito accademico.
Nello stilare la gerarchia dei requisiti, un compito importante del progettista risulta quindi quello di tenere in considerazione, e valorizzare soprattutto quei requisiti che permettano al software di diversificarsi, introducendo nuove funzionalità e strumenti non ancora previsti dagli altri, per presentare un lavoro che non sia solo una “copia” di software esistenti, ma che offra idee originali e rappresenti una strada autonoma nell’ambito del KDD.
Concludendo, possiamo affermare che l’implementazione di un linguaggio grafico su cui basare una GUI, o addirittura un intero sistema di KDD, è un passo molto complesso, che richiede notevole esperienza e sensibilità, poiché per rappresentare un processo non banale come l’estrazione di conoscenza si deve tenere conto di molteplici fattori, non solo rivolti all’estetica, ma anche alla semplicità d’uso, all’espressività ed agli strumenti di interazione che il sistema offre.
Il progettista deve quindi relazionarsi con concetti piuttosto complessi ed eterogenei, cercando di ottenere un amalgama di tutte le varie componenti descritte nel corso di questa tesi.
Ringraziamenti
Un sentito ringraziamento va a tutte le persone che mi sono state vicine nel corso di questo cammino, in particolare alla mia famiglia ed agli amici.
Desidero inoltre ringraziare il Prof. Franco Turini per l’attenzione, l’aiuto ed il tempo che mi ha dedicato, ed il Dott. Andrea Romei che è stato disponibile a discutere con me molti aspetti relativi a questo lavoro, fornendomi utili spunti di riflessione.
Un ringraziamento speciale va a Maria Ivana e lei sa perchè.
