5.1 INTRODUZIONE
La fase di codifica è stata eseguita adottando la metodologia ad oggetti. Come ambiente di programmazione è stato utilizzato Microsoft Visual Basic 6. In tale ambiente è stata usata la libreria Microsoft ADO (ActiveX Data Objects) ver. 2.1 che consente al software Parser e QueryGenerator (clients) di accedere e gestire i dati presenti in un server di database di qualunque provider OLE DB desiderato. Inoltre per eseguire le interrogazioni è stato utilizzato il linguaggio SQL.
5.2 SCELTA DELL’AMBIENTE DI PROGRAMMAZIONE VISUAL BASIC
Microsoft Visual Basic è un linguaggio di programmazione che consente di sviluppare in modo estremamente semplice e veloce applicazioni per il sistema operativo Microsoft Windows®.
Visual Basic dispone di diverse librerie che forniscono, con tecnologie differenti, funzionalità di creazione e di accesso ai database. In particolare è stata utilizzata per questo progetto la libreria Microsoft ADO 2.1
Microsoft ADO (ActiveX Data Objects) è una libreria d’oggetti che consente di accedere e gestire i dati presenti in un server di database di qualunque provider OLE DB desiderato. OLE DB è un’interfaccia di basso livello che introduce un modello d’accesso ai dati "universale". OLE DB, infatti, consente di gestire qualsiasi tipo di dati indipendentemente dal formato o dal metodo di memorizzazione.
ADO è stata utilizzata nella classe DBInterface, utilizzata sia dal componente Parser che dal componente QueryGenerator. La classe DBInterface è descritta nei prossimi paragrafi.
Grazie all’utilizzo di ADO, sia il QueryGenerator che il Parser possono accedere indistintamente a diversi DBMS come Microsoft Access e come Microsoft SQL Server .
5.3 LINGUAGGIO SQL
Le funzionalità di interrogazione fornite dal QueryGenerator e di inserimento e modifica dati fornite dal Parser sono state implementate attraverso l’utilizzo del linguaggio SQL.
SQL. è un acronimo di Structured Query Language, un linguaggio d’interrogazione per le basi di dati relazionali. La sua ampissima diffusione è legata sostanzialmente all’intensa opera di standardizzazione che si è concentrata sul linguaggio, svolta da organismi internazionali quali ISO (International Standard Organization) e ANSI (American National Standard Istitute). SQL non è soltanto un linguaggio
di primitive per la definizione dello schema di una base di dati relazionale), sia funzionalità di un Data Manipulation Language (con un insieme di primitive per la modifica dell’istanza di una base di dati). SQL esprime le interrogazioni in modo dichiarativo, ovvero, si specifica l’obiettivo dell’interrogazione e non il modo in cui ottenerlo.
Un’ interrogazione SQL per essere eseguita deve essere “tradotta” in una equivalente espressione procedurale nel linguaggio interno al sistema di gestione di base di dati (DBMS). Tale linguaggio interno è nascosto all’utente del sistema DBMS. La traduzione viene eseguita da un interprete o compilatore interni al DBMS utilizzato. In altre parole un utente del DBMS o un programmatore che realizza applicazioni di accesso alla base di dati, possono trascurare gli aspetti di traduzione e di ottimizzazione delle interrogazioni nel linguaggio interno al DBMS.
5.4 TESTING
Il Testing è un processo d’esecuzione del software allo scopo di rilevarne i malfunzionamenti. Un malfunzionamento è l’incapacità del software di comportarsi secondo le attese e può essere rilevato soltanto mediante esecuzione. La tesi di Dijkstra afferma che il "Testing non può dimostrare l’assenza di difetti,
ma solo mostrarne la presenza".
Il processo di Testing è fondamentale per garantire la qualità del software e la sua applicazione richiede:
1. Valutazione dei risultati del test, ovvero la conoscenza precisa del comportamento atteso dal sistema, per poterlo confrontare con quello osservato.
2. Criterio di terminazione del testing, ovvero quando si può ritenere di aver testato il software a sufficienza.
3. Criteri di selezione dei casi di test, ovvero la specifica delle condizioni che vanno soddisfatte da un test.
Per il Testing del “Software di gestione del corpus linguistico AVIP” sono stati applicati i seguenti criteri: 1. Valutazione dei risultati: la valutazione dei risultati del Testing è stata eseguita sia in base all’esame
del comportamento atteso definito nelle specifiche e sia secondo giudizi logici.
2. Terminazione del Testing: la valutazione della terminazione del testing è stata effettuata applicando un criterio di copertura, legato ad un criterio di selezione dei casi di test.
Criterio di selezione dei Casi di Test: il criterio specifica le condizioni che devono essere soddisfatte da un test. Come classe di criterio è stata applicata una metodologia black box. Ciò significa che ci si è posto l’obiettivo di derivare insiemi di condizioni d’ingresso che esercitano completamente i requisiti funzionali
del software. Il dominio dei dati d’ingresso è stato suddiviso in classi di test in modo tale che, se il programma è risultato corretto per un caso di test lo si è potuto ragionevolmente considerare corretto per ogni test in quella classe. La definizione delle condizioni sulle variabili d’ingresso ha consentito la definizione delle cosiddette classi d’equivalenza. Una classe d’equivalenza rappresenta un insieme di stati validi o non validi per una condizione delle variabili d’ingresso. Ogni classe d’equivalenza poi è stata “coperta” da un caso di test. Il criterio di copertura applicato consiste nell’eseguire un caso di test per ogni classe non valida e casi di testo che comprendono il maggior numero di classi valide. Per il componenti Parser e QueryGenerator sono state individuate le classi d’equivalenza ed eseguiti i casi di test.
In particolare:
• Per il Parser sono state analizzate le condizioni sul formato dei files AVIP e le condizioni sulle relazioni dei Marker relativi alle Etichettature.
• Per il QueryGenerator sono state analizzate le condizioni riguardanti la sintassi di interrogazione.
Tutte le classi di equivalenza prodotte non faranno parte del presente documento ma saranno fornite agli eventuali richiedenti.
6 . C O N C L U S I O N I
Il lavoro qui proposto ha generato un fondamentale strumento di supporto alle attività realizzate nell’ambito del progetto di ricerca AVIP-API ed ha avuto come obiettivo la progettazione e la realizzazione di un sistema software per la gestione dei dati del corpus.
Il software realizzato è stato sottoposto a testing di accettazione presso il CIRASS ed è stato distribuito, corredato di manuali d’utente, ai centri di ricerca partecipanti al progetto AVIP dell’Università Federico II di Napoli del Politecnico di Bari, dell’Università Normale Superiore di Pisa, dell’Istituto Universitario Orientale di Napoli e dell’Università di Vercelli.
In fase finale di distribuzione pubblica, il presente documento, insieme con l’intero pacchetto software corredato da opportuna procedura di installazione, manuali d’uso e database in formato Windows Access, sarà incluso nel sistema di memorizzazione di massa prescelto (DVD).
Gli autori restano a disposizione per fornire ogni ulteriore dettaglio che possa essere eventualmente necessario per una migliore comprensione del programma, ivi inclusi tutti i listati sorgente che sono da ritenersi liberamente distribuibili sulla base dei convenzionali accordi sul software di tipo “open source”. Per ogni richiesta rivolgersi a Francesco Cutugno all’indirizzo e-mail cutugno@unina.it.
BIBLIOGRAFIA
[1] Savy R., Documento di specifiche per la rappresentazione, analisi e codifica dei dati. Trascrizione ed etichettatura dei livelli segmentali in questo volume.
[2] Refice M., Savino M., Altieri M., Galiano N., Manuale d’uso del software per la visualizzazione e l’ascolto dei dati del corpus API - SegWiev98, in questo volume.
[3] Atzeni P., Ceri S., Paraboschi S., Torlone R., Basi di Dati, Milano: McGraw-Hill 1996.
[4] Coad P., Yourdon E., OOA – Analisi dei sistemi orientati agli oggetti, Milano: Jackson Libri 2000. [5] Coad P., Yourdon E., OOD – Progettazione dei sistemi orientati agli oggetti, Milano: Jackson Libri 2000. [6] Savy C., Da C++ a UML Guida alla progettazione, Milano: McGraw-Hill 2000.