un piano di prova in modalità passo-passo (Debug Test Plan), esecu- zione di un piano di prova in modalità normale (Run Test Plan), ar- resto dell’esecuzione (Stop Execution), abilitazione e disabilitazione della generazione del resoconto di esecuzione (Generate Report) e configurazione del comportamento in caso di fallimento di un passo di prova (On Fail . . . ). Sono presenti in questo caso i seguenti quat- tro pulsanti: per avviare l’esecuzione (Run), per mettere in pausa l’esecuzione (Pause), per fermare l’esecuzione (Stop) e per eseguire il piano di prova in modalità passo-passo (Debug). L’unica funzione offerta dal menù di contesto relativo a questo pannello è quella di rimuovere un’area selezionata nell’immagine caricata da memoria di massa (passo di prova Load Image) oppure acquisita dal modulo di scansione (passo di prova Capture Image).
Come già accennato, infine, è stata implementata per entrambe le modalità di utilizzo dell’interfaccia grafica un’area dedicata alla visualizzazione di messaggi di servizio per l’utente. Tale area si trova in basso a destra (in panelPlan nella modalità progettuale e in panelExecute nella modalità di esecuzione del collaudo) ed è stata realizzata tramite un controllo grafico di tipo TextBox (casella di testo) configurato in modalità multilinea.
Per rendere più facile l’utilizzo sono state programmate in mol- ti controlli grafici indicazioni d’uso per l’utente le quali vengono visualizzate al passaggio del dispositivo di puntamento sul controllo. Data la particolare importanza del ruolo rivestito dagli eventi nel funzionamento dell’interfaccia grafica, viene fornito un loro elenco esaustivo nell’Appendice B.
2.4
Sviluppo di un modello dei dati
Un modello dei dati è necessario per lo sviluppo del sistema soft- ware in quanto serve a fornire la definizione ed il formato dei dati; esso può servire anche a permettere lo scambio dei dati tra appli-
cazioni diverse. Il suo scopo è quello di catturare e descrivere un sottoinsieme delle informazioni reali significativo per l’applicazio- ne.
Il modello dei dati per questa applicazione consiste di due gruppi di strutture dati: un primo gruppo necessario per permettere un’a- gile presentazione e manipolazione dei dati ed un secondo gruppo necessario per ottenere la persistenza di tali dati ovvero per garan- tire la loro durevolezza nel tempo tramite l’ausilio di memorie di massa.
Mediante il primo gruppo di strutture dati l’utente può, tramite l’interfaccia grafica, accedere visivamente ai dati di collaudo, appor- tarvi modifiche ed utilizzarli per controllare l’esecuzione del collau- do. Mediante il secondo gruppo di strutture dati, invece, l’utente può leggere i dati dalla memoria di massa e trasferirli nella memoria centrale per l’elaborazione oppure scrivere sulla memoria di massa i dati presenti nella memoria centrale per poi recuperarli in un’altra sessione.
Il primo gruppo di strutture dati si ricava dall’analisi del dominio della applicazione ed individua:
• Classi
• Attributi (ovvero informazioni contenute negli oggetti della clas- se);
• Operazioni (ovvero servizi offerti dagli oggetti della classe); • Relazioni tra le classi (ad esempio ereditarietà, associazione,
dipendenza, etc.).
Nel caso in esame il dominio dell’applicazione è il collaudo di un prodotto industriale e pertanto gli elementi fondamentali sono le prove da effettuare su tale prodotto. Un collaudo completo è definito come l’esecuzione di un insieme di prove sul prodotto e può essere descritto tramite un piano di collaudo o piano di prova il quale costi- tuisce pertanto il secondo elemento fondamentale del dominio. Un
2.4. SVILUPPO DI UN MODELLO DEI DATI 47
terzo ed ultimo elemento fondamentale si trova osservando che le prove sono in realtà costituite da uno o più passi i quali, nel caso in oggetto, sono di uno dei 7 tipi già descritti nel paragrafo 2.2 e raffi- gurati nel diagramma della Figura 2.4 dal quale risulta evidente che la classe TestStep viene utilizzata come classe base da cui far deriva- re le 7 classi corrispondenti alle diverse tipologie di passi di prova. Gli elementi fondamentali così trovati definiscono le tre classi del modello dei dati che sono state già riportate in Figura 2.5: TestStep (passo di prova), TestCase (prova) e TestPlan (piano di prova).
Per ottenere la persistenza di tali dati si ricorre ad una conver- sione delle strutture dati non atomiche del primo gruppo in un’altra struttura dati denominata DataSet e progettata come astrazione di una base di dati relazionale. Una prima istanza di una struttura del tipo DataSet è utilizzata per contenere i dati relativi ad una deter- minata prova ed una seconda istanza di struttura del tipo DataSet è utilizzata per contenere i dati relativi ad un determinato piano di prova. La Figura 2.11 mostra il modello dei dati fin qui descritto.
La classe DataSet è fornita dal componente ADO.NET della Fra- mework Class Library: le classi ADO.NET sono contenute nel- la libreria System.Data.dll e sono integrate con le classi XML (si- gla di eXtensible Markup Language) contenute nella libreria Sy- stem.Xml.dll. ADO.NET fornisce difatti una stretta integrazione con XML: da un DataSet può venire scritto un documento XML su me- moria di massa e da un documento XML residente su memoria di massa può venire caricato un DataSet. Per riempire un DataSet con i dati provenienti da una sorgente XML viene utilizzato il metodo ReadXml, mentre per creare documenti XML si invoca il metodo WriteXml da un oggetto Dataset. Il Dataset è basato su una strut- tura relazionale dei dati, mentre il documento XML è basato su una struttura gerarchica degli stessi. Un oggetto DataSet rappresenta una cachein memoria dei dati recuperati da un’origine dati ed è costitui- to da un insieme di oggetti DataTable che contengono i dati. Oltre alla classe DataTable per le tabelle, sono disponibili anche le clas-
Figura 2.11: Diagramma delle classi per il modello dei dati.
si DataRow per le righe di tali tabelle e DataColumn per le colon- ne. Per gli scopi di questo progetto non è stato necessario utilizzare relazioni tra tabelle.
I documenti XML prodotti avranno tre livelli: • livello 0: elemento radice;
• livello 1: elementi figli dell’elemento radice; sono di tipo com- plesso e rappresentano le tabelle nella visione relazionale; non contengono né nodi testo né nodi attributi ma solamente al-