Universitá degli Studi di Napoli Federico II

Transcript

1 Universitá degli Studi di Napoli Federico II Facoltá di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Triennale in Informatica Sviluppo di un applicativo ad interfaccia grafica per la gestione di basi di dati SQLite Relatore: Candidato: Chiar.mo Prof. Aniello Murano Francesco Cervone Tutor aziendale: Matr. N86/18 Ing. Andrea Frullone Anno Accademico 2011/2012

2

3 Indice Ringraziamenti Introduzione v vi 1 Strumentazioni SQLite Confronto con altri DBMS Struttura interna API Livecode Introduzione al linguaggio Sintassi Struttura del linguaggio Lo scambio dei messaggi I tipi e le strutture dati Lo scope delle variabili L ambiente di sviluppo DataGrid Externals Analisi dei requisiti Prefazione Modello funzionale Funzionalità richieste Specifica dei requisiti ii

4 INDICE iii Diagrammi dei casi d uso Mockups Tabelle di Cockburn Modelli di dominio Diagrammi di sequenza Design del sistema Introduzione Architettura Struttura del file delle preferenze XML Diagramma delle classi Diagramma di stato Diagrammi di sequenza Implementazione Problematiche riscontrate Introduzione Parsing del codice SQL Generazione query tramite query-builder Gestione dei BLOB Creazione di una vista ad albero DataGrid Creazione delle tabelle Query builder Preferenze PRAGMA Visualizzazione dei dati BLOB Testing del sistema Verifica e validazione Testing Conclusioni Considerazioni su Livecode Sviluppi futuri

5 INDICE iv A Tabelle di cockburn 92 B Diagrammi di sequenza di analisi 102 C Diagrammi di sequenza di design 118 Elenco delle figure 132 Bibliografia 135

6 Ringraziamenti Desidero ringraziare innanzitutto gli Ingegneri Francesco Sacerdoti ed Andrea Frullone, i quali mi hanno seguito costantemente durante tutto l arco di tempo relativo all attività di tirocinio con grande professionalità e serietà. Il tirocinio è stato un ottima esperienza lavorativa grazie anche al contesto aziendale con il quale ho avuto la possibilità di collaborare e di accrescere le mie conoscenze informatiche. Un particolare ringraziamento va al Professore, nonché mio tutore universitario Aniello Murano, il quale ha monitorato l attività svolta presso l azienda, interessandosi delle difficoltà presentatesi. v

7 Introduzione La presente tesi tratta dell attività di tirocinio svolta presso l azienda e- voluzione s.r.l. che ha avuto come obiettivo la progettazione e lo sviluppo di un applicazione per la gestione di basi di dati SQLite[1], comprensiva del supporto al Backup & Restore dei databases. In particolare nel documento sarà presente lo studio e l analisi dei requisiti, il design del sistema, ed alcune problematiche riscontrate durante lo sviluppo di quest ultimo, dovute alle tecnologie utilizzate quali SQLite, il linguaggio di programmazione Livecode e l ambiente di sviluppo Xcode[4]. L obiettivo del software è di gestire generiche basi di dati SQLite permettendo operazioni come la creazione e modifica di tabelle, l inserimento, modifica e cancellazione di righe, la composizione ed esecuzione di query e così via nel modo più semplice possibile per l utente, grazie ad una GUI semplificata. I database ricoprono un ruolo molto importante nell ambito informatico. La necessità di memorizzare delle informazioni all interno di archivi digitali è nata sin dall inizio della storia dell informatica. L obiettivo dei Database Management System è quello di gestire nel modo più efficiente possibile le informazioni contenute all interno dei database, permettendo di organizzare, memorizzare e reperire i dati. In origine soltanto organizzazioni con l hardware necessario a mantenere grandi quantità di dati ospitavano i DBMS. A differenza di qualche anno fa, oggi esistono vari tipi di database e DBMS specifici a seconda delle esigenze degli utenti. I primi database erano detti navigazionali dato che l unico modo per effettuare una interrogazione, era visitare (quindi navigare) tutte le informazioni vi

8 INTRODUZIONE vii le quali erano organizzate in una sorta di struttura ad albero gerarchica o a rete. Edgar Codd diede vita ai database relazionali detti anche RDBMS (Relational Database Management Systems), i quali a differenza dei primi, avevano una organizzazione a tabelle e non a rete. La caratteristica principale di questo tipo di database era l esistenza di una chiave che identificava ogni record 1 delle tabelle del sistema. Sulla base dei database relazionali sono nate altre categorie più ampie come i database multidimensionali, i database ad oggetti (ODBMS) ed i database relazionali ad oggetti (ORDBMS). Gli Object DBMS gestiscono delle basi di dati con una struttura simile al paradigma Object-Oriented dei linguaggi di programmazione. L idea di questa tecnologia è di mappare direttamente gli oggetti all interno del database. La caratteristica principale che distingue gli ODBMS dai normali DBMS è che un oggetto al suo interno può avere degli altri oggetti definiti nel database. I Relational Object DBMS sono un misto tra i Relational DBMS e gli Object DBMS. Generalmente i DBMS hanno una architettura client/server. Il client interroga il database ed il server invece gestisce e recupera i record del database. L applicazione server è la parte più importante del DBMS poiché deve ottimizzare al massimo le operazioni di ricerca all interno del database minimizzando i tempi. Ogni DBMS fornisce almeno un client che permette di interrogare i database da riga di comando. Alcuni invece, offrono anche dei software ad interfaccia grafica per raggiungere questo obiettivo. Un esempio di RDBMS è Oracle[2]. La struttura interna del database Oracle è molto complessa, gestisce in modo efficiente e sicuro i dati memorizzati. Esistono alcune funzionalità che permettono di tenere traccia di tutte le transazioni eseguite nel database in modo da recuperare in qualunque momento i dati coerenti in caso ad esempio di crash di sistema o altri casi eccezionali. Oracle permette di definire al suo interno oltre le normali tabelle, viste e trigger, delle funzioni e procedure scritte in linguaggio PL/SQL 2. 1 Riga di una tabella 2 Procedural Language/Structured Query Language, linguaggio proprietario di Oracle

9 INTRODUZIONE viii All interno del database sono presenti delle tabelle di sistema che tengono traccia di ogni tipo di oggetto creato dall utente. Un altro importante DBMS è MySQL[3]. Esso a differenza di Oracle è open source e non è orientato agli oggetti ma è relazionale. MySQL è uno dei DBMS più utilizzati dagli sviluppatori di applicazioni dato che è gratuito, sicuro e molto efficiente. Esso è molto utilizzato in sistemi Unix, in particolare Linux, ma è anche disponibile per altri sistemi operativi come Windows e Mac. Esistono molti tipi di gestori di database MySQL. Tra i programmi più popolari citiamo phpmyadmin il quale richiede un server web HTTP ed il supporto al linguaggio PHP e può essere eseguito in un qualunque browser web. MySQL Workbench invece è fornito dallo stesso MySQL ed è un gestore ad interfaccia grafica che include strumenti di modellazione ed aggiornamento dei database. Così come Oracle, MySQL ha una architettura client/server. Uno dei Relational DBMS che sta avendo un enorme successo negli ultimi anni è SQLite. A differenza degli altri, SQLite non ha una architettura client/server poiché l intero database risiede all interno di un unico file e per questo motivo esso è definito un embedded database. Non esiste un programma server che gestisce il recupero e l aggiornamento dei record e le connessioni di client. SQLite è un ottimo DBMS per la gestione di piccole quantità di dati. Il Database Management System SQLite viene utilizzato da alcuni importanti software quali Mozilla Firefox, Mozilla Thunderbird, Skype, Dropbox e sistemi operativi come ios, Android, Symbian OS, webos e Blackberry OS. A causa dello sviluppo massiccio e rapido negli ultimi anni dei primi due sistemi operativi citati, anche la popolarità del DBMS SQLite sta crescendo velocemente. La crescita non è dovuta soltanto al fatto che esso è utilizzato dai sistemi operativi ormai più famosi nel mondo mobile, ma soprattutto per il suo semplice utilizzo, le sue dimensioni estremamente ridotte e le sue performance. Tutte queste caratteristiche lo favoriscono rispetto ad altri DBMS Corporation

10 INTRODUZIONE ix come MySQL, Oracle o SQL Server per lo sviluppo di applicazioni per sistemi embedded come gli smartphone. Dato che l itunes Store di ios ed il Google Play Store di Android contano insieme ormai circa centinaia di migliaia di applicazioni, nasce la naturale esigenza di utilizzare un manager grafico di database di questo tipo per migliorare e velocizzare lo sviluppo di software. Purtroppo però, il produttore del DBMS SQLite non ha ancora sviluppato un applicazione di questo tipo, mettendo a disposizione soltanto il software per la gestione dei databases da riga di comando. Per questo motivo sono nate alcune applicazioni con lo scopo di migliorare e semplificare l utilizzo di questo Database Management System attraverso l interfaccia grafica. Le applicazioni che hanno avuto maggiore successo fino a questo momento sono state: 1. SQLite Manager (estensione Firefox), tool gratuito utilizzabile come estensione di Firefox. Le uniche agevolazioni grafiche implementate sono per l inserimento di nuove righe. Offre comunque un buon supporto anche ai blob. Tutte le altre operazioni sono effettuate tramite un campo di testo dove viene immesso il codice SQL. La dipendenza dal browser può essere uno svantaggio perché rende non autonomo questo software, ma allo stesso tempo può essere visto come un vantaggio in quanto esso diventa multipiattaforma. 2. Navicat, applicazione compatibile con i sistemi operativi Windows, Mac OS X e Linux con un supporto completo ad SQLite. Semplifica di molto la gestione dei database grazie alle interfacce per creare nuove tabelle, inserire righe nelle tabelle, creare viste ed effettuare query. Rende quasi inutile l utilizzo della riga di comando. Il suo unico problema è il prezzo che è abbastanza elevato. 3. SQLite Maestro, come Navicat facilita molto l esperienza del gestore dei databases ma ha un prezzo molto alto.

11 INTRODUZIONE x 4. SQLite Manager, è un applicazione per Mac OS X e Windows e non è legata all omonima estensione di Firefox. É a pagamento ma non è completo. Le caratteristiche generali dei quattro software appena elencati si riflettono sulla maggior parte delle applicazioni di questo tipo. Quelle gratuite hanno funzionalità molto limitate che aiutano l utente soltanto in minima parte, mentre quelle con una migliore e più elaborata interfaccia grafica hanno prezzi molto alti. Non c è una soluzione alternativa che concilia entrambe le cose, ovvero offrire una ottima qualità con un prezzo medio o quasi nullo. Proprio per questo motivo, l azienda presso la quale ho svolto l attività di tirocinio, ha voluto creare una applicazione che avesse queste caratteristiche. L obiettivo del mio lavoro è stato di sviluppare questo software. Lo scopo principale del software da sviluppare è di ridurre al minimo le operazioni effettuate dall utente e semplificarle dando una visione d insieme degli oggetti contenuti nel database e della loro struttura interna. Dato che l azienda nella quale ho svolto l attività di tirocinio utilizza il linguaggio di programmazione Livecode per sviluppare alcuni software, si è deciso di usare lo stesso approccio anche in questo caso. Il motivo principale di questa scelta è dovuto alle caratteristiche intrinseche del linguaggio. Esso viene preferito ad altri linguaggi di programmazione perché permette di sviluppare applicazioni in tempi molto rapidi grazie alla sua sintassi di altissimo livello, perché è multipiattaforma, ovvero si può compilare simultaneamente per più sistemi operativi senza il bisogno di adattare il codice, e perché è un linguaggio innovativo e molto efficiente. Il presente lavoro di tesi è interamente incentrato sulla descrizione dei processi relativi alla progettazione, implementazione e collaudo del software. I diversi capitoli della tesi possono essere visti come il ciclo di vita del sistema. Capitolo 1: Strumentazioni : il seguente capitolo descrive nel dettaglio le tecnologie utilizzate durante lo sviluppo dell applicazione. In parti-

12 INTRODUZIONE xi colare viene spiegata la struttura del DBMS SQLite e del linguaggio di programmazione Livecode. Capitolo 2: Analisi dei requisiti : qui viene descritta la fase di raccolta e specifica dei requisiti del sistema sviluppato. Sono compresi alcuni diagrammi UML e le tabelle di Cockburn che descrivono nel dettaglio i vari Use Cases. Capitolo 3: Design del sistema : in questo capitolo si passa all effettiva progettazione del sistema, mostrando l architettura, la struttura degli oggetti dell interfaccia grafica e dei dati persistenti. Capitolo 4: Implementazione : il seguente capitolo ha lo scopo di chiarire alcuni aspetti implementativi e la soluzione di alcune problematiche riscontrate durante la progettazione ed implementazione del sistema. Capitolo 5: Testing del sistema : l ultimo capitolo è dedicato al piano di testing del software.

13 Capitolo 1 Strumentazioni Il seguente capitolo ha lo scopo di spiegare dettagliatamente le tecnologie utilizzate durante lo sviluppo del software. 1.1 SQLite Confronto con altri DBMS Come già detto, il sistema da me sviluppato ha lo scopo di gestire basi di dati SQLite. Figura 1.1: Logo di SQLite SQLite è una libreria scritta in C/C++ che implementa un DBMS (Database Management System) di tipo relazionale molto leggero e perfettamente adatto ad i sistemi embedded.[6] Le sue caratteristiche principali sono le seguenti: 1

14 CAPITOLO 1. STRUMENTAZIONI 2 Non è un programma con l usuale architettura client-server come quasi la maggior parte degli altri DBMS. Tutte le informazioni necessarie sono contenute all interno di un file che viene aperto, modificato e chiuso dalle librerie quando si vuole accedere al database. Non ha bisogno di alcun tipo di configurazione. E ACID 1 -compliant, ovvero ogni transazione effettuata sul database è atomica (non interrompibile prima della conclusione della stessa), il database si trova in uno stato coerente prima e dopo ogni operazione, ogni azione viene eseguita in modo isolato in modo che non condizioni altre ed ogni qualvolta si vuole scrivere nel database (dopo un commit) i cambiamenti non devono essere persi prima dell effettiva modifica.[10] E open source, il codice sorgente è di dominio pubblico. Naturalmente queste caratteristiche lo rendono un ottimo DMBS. Ha molti vantaggi ma allo stesso tempo anche molte limitazioni, infatti non offre un supporto completo allo standard SQL. Permette sicuramente le operazioni di base, come la creazione di tabelle, viste e triggers, esecuzione di query e così via, ma non supporta una serie di operazioni che elencherò a breve. I suoi vantaggi sono ben più importanti e significativi e incidono molto sulla scelta di questo DBMS rispetto ad altri. Possono essere evidenziati vantaggi e svantaggi di SQLite. Ne riassumo alcuni di seguito. Vantaggi: Tutti i dati sono contenuti all interno di un unico file che diventa parte integrante dell applicazione che ne fa utilizzo. Per la maggior parte dei DBMS il collo di bottiglia è sicuramente la connessione al server per recuperare e modificare i dati di un database. Nel caso di SQLite vengono abbattuti completamente questi tempi di attesa proprio per il fatto che bisogna semplicemente accedere ad un file in locale senza interrogare un programma server. 1 Atomicity, Consistency, Isolation, Durability

15 CAPITOLO 1. STRUMENTAZIONI 3 Non ha bisogno di alcuna configurazione o installazione come già detto in precedenza. Questo è sicuramente legato al punto precedente in quanto non esiste un processo server che accetta connessioni in entrata. Si ha un controllo diretto e libero sui database dato che il file può essere posizionato ovunque nel File System. Può essere copiato, spostato e cancellato, insomma si può effettuare qualunque tipo di operazione come tutto il resto dei files. SQLite è cross-platform, può essere eseguito su qualsiasi macchina, che sia Windows, Linux o Mac OS X. Il formato del file è supportato da qualsiasi sistema operativo. Le API 2 sono molto semplici da comprendere e utilizzare. Sono scritte in linguaggio C e quindi sono multipiattaforma. Come già detto è open source ed il codice è ben commentato e leggibile dagli sviluppatori. Inoltre le librerie sono molto compatte e leggere. La grandezza massima che il file del database può raggiungere è attualmente di 2 TB. Svantaggi: Non offre un supporto completo del comando di ALTER TABLE. E possibile soltanto modificare il nome di una tabella ed aggiungere un altro campo. Non è possibile aggiungere constraint di tabella, comprese chiavi esterne, vincoli di check, unique e primary key. Non si possono cancellare i campi e i vincoli di una tabella e né modificarli. L unico modo per effettuare queste operazioni è di creare una tabella identica a quella precedente, con l eventuale aggiunta o rimozione di campi o vincoli, e passare i dati dalla vecchia alla nuova. 2 Application Programming Interface

16 CAPITOLO 1. STRUMENTAZIONI 4 Non implementa RIGHT e FULL OUTER JOIN. A causa di questa limitazione non possono essere eseguite query molto complesse. La LEFT OUTER JOIN invece è utilizzabile come la semplice INNER JOIN. Non si possono inserire righe all interno delle viste. Anche altri DBMS non permettono questa operazione la quale, a mio avviso non è così fondamentale. Non supporta l istruzione FOR EACH STATEMENT all interno dei TRIGGER. Tutte le funzionalità delle chiavi esterne sono disabilitate di default. Il comando PRAGMA FOREIGN_KEYS=ON permette di attivarle, ma ha valenza soltanto durante la connessione che lo ha eseguito. Se per esempio nel vincolo di chiave esterna è indicata la proprietà ON DELETE CASCADE, viene cancellata una riga corrispondente alla chiave esterna e il comando precedente non è stato eseguito, allora tutte le righe che si riferivano a quella cancellata resteranno nelle loro tabelle. Non permette di creare funzioni e procedure. Il fatto che non esiste un processo server implica che non è implementata una vera e propria gestione della concorrenza. Questi tipi di controlli devono essere effettuati dal programma che accede al database. Non esistono categorie di utenti con permessi di accesso al database diversi. Le tabelle di sistema contengono pochissime informazioni riguardo tutta la struttura del database. Nonostante tutti questi svantaggi, come già detto in precedenza, SQLite viene preferito ad altri DBMS in moltissimi casi. Le operazioni di base del linguaggio SQL sono implementate, per il resto è richiesto un minimo sforzo in più da parte dello sviluppatore.

17 CAPITOLO 1. STRUMENTAZIONI Struttura interna Un altra caratteristica importante sono le proprietà PRAGMA. Il loro scopo è quello di definire una serie di preferenze oppure recuperare informazioni dal database. Una è stata citata in precedenza, PRAGMA FOREIGN_KEYS, che si occupa di attivare o disattivare le chiavi esterne. Così come quest ultima, tutte le altre che rappresentano una preferenza si resettano ad ogni connessione al database. Esempi di altre proprietà sono i seguenti: PRAGMA FOREIGN_KEY_LIST(table) elenca le chiavi esterne della tabella passata per parametro PRAGMA TABLE_INFO(table) elenca i campi con i rispettivi tipi della tabella passata per parametro PRAGMA CASE_SENSITIVE_LIKE = boolean indica se l operatore LIKE deve discriminare le lettere minuscole dalle lettere maiuscole Alcune di queste proprietà interrogano l unica tabella di sistema di SQ- Lite, denominata sqlite_master. All interno sono contenute informazioni riguardo le tabelle, le viste, i trigger e gli index. Gli unici campi di questa tabella sono: 1. type indica il tipo dell oggetto (table,view,index,trigger). 2. name è il nome dell oggetto. 3. tbl_name rappresenta il nome della tabella a cui fa riferimento l oggetto. 4. rootpage 5. sql è il codice SQL di creazione dell oggetto. Rispetto ad altri DBMS queste informazioni sono poche per capire bene la struttura interna del database. Non esistono tabelle che mostrano la struttura dettagliata delle tabelle, la lista delle colonne e le relative constraint (check, unique, default), la lista delle chiavi esterne e la lista delle constraint

18 CAPITOLO 1. STRUMENTAZIONI 6 di tabella. Per la lista delle colonne e delle chiavi esterne ci sono i rispettivi comandi PRAGMA, mentre per i vincoli di colonna e di tabella non c è una soluzione diretta. MySQL ad esempio, ha un database chiamato INFORMATION_SCHEMA che descrive tutta la struttura del database. Esiste una tabella per ogni tipo di oggetto, colonne, tabelle, constraints, triggers, viste e ed altri[7]. Anche Oracle ha tabelle simili a quelle di MySQL. L unico modo per ottenere tutte queste informazioni all interno di un database SQLite è di analizzare il campo sql della tabella sqlite_master. Questa è una grande limitazione soltanto per applicazioni come quella sviluppata da me che ha proprio il compito di gestire il database, mostrando all utente come è fatto all interno per aiutarlo in modo che compia il minor numero di operazioni possibili. Per altri tipi di software questo non è di certo un problema API Durante lo sviluppo dell attività di tirocinio è stato necessario utilizzare anche le API di SQLite per C/C++. I motivi saranno chiariti nei prossimi capitoli. Le prime versioni delle librerie SQLite erano molto semplici da comprendere dato che erano composte soltanto da 5 interfacce. La versione più recente invece comprende ben 185 API distinte, la cui maggior parte sono specifiche per determinate operazioni. Le API di base, fortunatamente, sono in numero ristretto e semplici da utilizzare. 3 Nel presente paragrafo saranno presentate le strutture dati e funzioni principali della libreria.[1] Le strutture dati più importanti sono: sqlite3 che rappresenta la connessione al database. sqlite3_stmt la quale viene creata per effettuare query all interno del database. Rappresenta l oggetto di base per costruire le prepared statement. 3 An Introduction To The SQLite C/C++ Interface

19 CAPITOLO 1. STRUMENTAZIONI 7 Tutto ruota intorno a questi due oggetti che vengono passati come parametri alla maggior parte delle funzioni delle API di SQLite. Ricordiamo alcune funzioni di seguito: int sqlite3_open(const char *filename, sqlite3 **ppdb) Questa funzione ha l obiettivo di aprire una connessione al database. Il primo parametro è una stringa che indica il percorso del file corrispondente al database. Il secondo parametro invece è un oggetto non ancora inizializzato di tipo sqlite3. int sqlite3_prepare(sqlite3 *db, const char *zsql, int nbyte, sqlite3_stmt **ppstmt, const char **pztail); La presente viene utilizzata quando si vuole effettuare una query nel database. La funzione di questa interfaccia è di creare uno statement che può essere preparato passando dei parametri alla stringa SQL. Il primo parametro db rappresenta un database aperto. Il parametro zsql è una stringa contenente il codice SQL. La variabile nbyte, invece, indica la lunghezza in bytes della stringa SQL e se ha un valore negativo, la stringa viene interpretata fino al terminatore. Il parametro di output ppstmt è un oggetto di tipo statement che viene inizializzato all interno della funzione. L ultimo parametro è un puntatore alla parte non utilizzata del parametro zsql e solitamente viene lasciato a NULL. int sqlite3_bind_*(sqlite3_stmt*, int,...); L obiettivo di questa interfaccia è di passare un parametro allo statement. Per rappresentare un parametro nella stringa SQL, bisogna inserire uno tra?,?nnn, $VVV dove NNN rappresenta un qualsiasi intero e VVV una qualsiasi stringa. L asterisco dopo sqlite3_bind_ indica che ci sono varie funzioni per ogni tipo supportato da SQLite. Le varianti di questa funzione sono le seguenti: sqlite3_bind_blob sqlite3_bind_double sqlite3_bind_int

20 CAPITOLO 1. STRUMENTAZIONI 8 sqlite3_bind_int64 sqlite3_bind_null sqlite3_bind_text sqlite3_bind_text16 Il primo parametro della funzione bind indica un oggetto statement precedentemente aperto. Il secondo invece, rappresenta l indice del parametro della funzione SQL: ad esempio se il codice SQL è insert into persona values (:par, 30), esso vale 1. Gli ulteriori argomenti della funzione bind dipendono dalla variante della funzione. Nel caso delle bind_text, bind_text16, bind_blob vengono passati 3 argomenti dove il primo rappresenta il dato (void* nel caso di blob, char* nel caso di text), il secondo la lunghezza in bytes dei dati, il terzo uno tra SQLITE_STATIC e SQLITE_TRANSIENT, i quali indicano se l oggetto passato è statico o dinamico. In tutti gli altri casi della funzione sqlite3_bind escludendo sqlite3_bind_null viene passato un terzo argomento del tipo corrispondente al parametro da passare allo statement SQL. int sqlite3_step(sqlite3_stmt*); Questa funzione viene utilizzata per valutare lo statement SQL. Dopo aver chiamato questa funzione si può capire se la modifica (in caso di insert, update, create,...) è andata a buon fine, oppure si possono cominciare a prelevare i valori della riga corrente risultante dalla query. Il secondo obiettivo dell interfaccia è di passare alla prossima riga in caso di query. sqlite3_column_*(sqlite3_stmt*, int icol); L API ha lo scopo di prelevare il valore di una colonna della riga corrente. L asterisco può essere sostituito da blob, text, int, double e tutti gli altri tipi visti prima nel caso della funzione bind. int sqlite3_reset(sqlite3_stmt *pstmt);

21 CAPITOLO 1. STRUMENTAZIONI 9 Questa interfaccia resetta lo statement allo stato iniziale per essere rieseguito. Se è stato effettuato il binding con dei parametri, allora essi vengono rilasciati. int sqlite3_finalize(sqlite3_stmt *pstmt); Rilascia completamente uno statement. int sqlite3_close(sqlite3 *); L obiettivo della funzione è di chiudere la connessione al database identificata dal parametro passato.

22 CAPITOLO 1. STRUMENTAZIONI Livecode Introduzione al linguaggio Il linguaggio di programmazione utilizzato per lo sviluppo del software è stato Livecode. Figura 1.2: Logo di Livecode Livecode è un linguaggio di tipo RAD, Rapid Application Development, ovvero per lo sviluppo rapido di applicazioni. Esso è stato sviluppato da RunRev, Runtime Revolution Ltd.. RunRev specifica nella descrizione del linguaggio: Write once, deploy anywhere Questo indica la caratteristica principale di Livecode, ovvero che la sintassi è uguale per ogni piattaforma supportata e non c è bisogno di scrivere codice adattato al sistema operativo sul quale dovrà essere eseguita l applicazione. É possibile sviluppare applicazioni per: Mac OS X Windows Linux ios Android Web Server

23 CAPITOLO 1. STRUMENTAZIONI Sintassi Livecode è definito da RunRev come un very-high-level language. La sintassi è molto semplice e potente, una sola istruzione può rappresentare varie righe di codice in altri linguaggi di programmazione. Ad esempio questo codice scritto in Java... FileInputStream fstream = new FileInputStream("textfile.txt"); DataInputStream in = new DataInputStream(fstream); BufferedReader br = new BufferedReader(new InputStreamReader(in)); String var; StringBuilder stringa; while ((var = br.readline())!= null) { stringa.append(var); } in.close();...si traduce in Livecode in questa singola istruzione: put url ( file:textfile.txt ) into tstringa Questo è soltanto un esempio, ma se ne potrebbero fare tanti che dimostrano l agilità e la semplicità di questo linguaggio. Come si può intuire dal codice precedente la sintassi è english-like e quindi diventa molto semplice imparare il linguaggio. A differenza degli altri linguaggi, in Livecode i blocchi di codice non sono racchiusi tra parentesi graffe ma sono identificati grazie all indentazione. In realtà l utente non deve preoccuparsi di questo problema perché è lo stesso ambiente di sviluppo che si occupa di gestire automaticamente l indentazione del codice. Lo sviluppatore può eventualmente forzare l indentazione premendo il tasto tab della tastiera Struttura del linguaggio Livecode non è un linguaggio di programmazione Object-Oriented. Esso ha comunque una struttura interna molto solida e gerarchica basata su alcuni

24 CAPITOLO 1. STRUMENTAZIONI 12 oggetti. Gli oggetti di cui sto parlando sono Stack, Card, Button, Field, Scrollbar, Group, Graphic, Player, Image. Gli Stack rappresentano le finestre, le Card invece sono una sorta di vista di queste ultime. Dire che uno stack è composto da più card significa che la stessa finestra in momenti diversi può essere formata da diversi componenti (pulsanti, campi, tabelle,...). I gruppi, come si intende dalla parola, servono a raggruppare vari oggetti tra di loro. Livecode è un linguaggio basato sugli eventi. Ciò vuol dire che qualunque tipo di operazione deve essere avviata da un evento scatenante da parte dell utente. Gli eventi possono essere ad esempio il click di un pulsante, l apertura di uno stack, l inserimento di caratteri all interno di un field. Ad ogni evento corrisponde l invio di un messaggio all oggetto denominato target. Se all interno dello script è definito un handler che cattura il messaggio, allora a quella azione, lo sviluppatore può far corrispondere altre operazioni. La struttura degli oggetti è gerarchica perché ogni messaggio che viene inviato deve seguire sempre un percorso stabilito dal linguaggio; questo percorso è denominato message path. Se ad esempio cliccassimo su un pulsante allora sarebbe inviato un messaggio di mouseup ad esso. Se qui non è catturato oppure è catturato ma passato al prossimo oggetto tramite l istruzione pass mouseup, sarebbe inviato automaticamente al suo gruppo di appartenenza se esiste, altrimenti direttamente alla card. Se la card a sua volta non cattura il messaggio o lo passa, allora arriva allo stack. Soltanto dopo lo stack arriva all engine. Il MainStack indicato all interno dell immagine 1.3 rappresenta lo stack principale del progetto in esecuzione. Ogni programma scritto in Livecode deve avere necessariamente un oggetto di questo tipo Lo scambio dei messaggi I messaggi causati dagli eventi dell interfaccia non sono l unico modo per far comunicare gli oggetti tra di loro. In generale si definiscono i seguenti tipi di handlers:

25 CAPITOLO 1. STRUMENTAZIONI 13 Figure 47 The Message Path Figura 1.3: Message path For example, suppose the user clicks a button in a main stack, causing LiveCode to send a mouseup message to the button. If the button's script does not contain a handler for the mouseup messages, message, sono the message inviati is passed direttamente along to the dall interfaccia, card the button is on. oppure If the card's chiamati script contains tramitea delle mouseup istruzioni handler, the handler is executed. But if the card does not handle the mouseup message, it is passed on to the card's stack. If the stack script contains a mouseup handler, the handler is executed. But if the stack does not handle the functions, hanno lo scopo di ritornare un valore al termine della loro mouseup message, it is passed on to the engine. esecuzione The engine is the end of the message path, and if a message reaches it, the engine takes any default setprop, action impostano (e.g. inserting una a character proprietà into a di field unor oggetto highlighting al a valore button), passato then per throws the message away. parametro. If a message corresponding to a custom command or a custom function call reaches the end of getprop, the message ritornano path without il valore finding a di handler, una proprietà instead of being di unthrown oggetto. away, it causes an execution error. Nell immagine 1.4 vengono riportati degli esempi di definizioni e chiamate di handlers. 128

26 CAPITOLO 1. STRUMENTAZIONI 14 Figura 1.4: Esempio di messaggio, funzione, setprop e getprop Esistono vari modi per inviare messaggi ad altri oggetti. mediante l utilizzo della parola chiave dispatch: Il primo è dispatch messaggio to field campo with parametro1, parametro2 Il comando send è molto simile al precedente. L unica differenza è che la vera è propria chiamata (comprensiva di parametri) è indicata come una stringa racchiusa tra doppi apici: send messaggio parametro1, parametro2 to field campo Sia la send che la dispatch alterano il message path. É come se si aggiungesse un altro percorso che parte dall oggetto che riceve il messaggio ed arriva all engine. Una volta completato torna all istruzione successiva al comando che invoca il messaggio.

27 CAPITOLO 1. STRUMENTAZIONI 15 Se invece, si vuole chiamare una funzione di un altro oggetto, esiste la funzione di sistema value. Il primo parametro rappresenta la chiamata, il secondo invece l oggetto di destinazione del messaggio. Di seguito si riporta un esempio: put value( funzione(parametro1, parametro2),field campo ) into var I tipi e le strutture dati Da questo punto di vista Livecode non è paragonabile ad un linguaggio di programmazione bensì ad un linguaggio di scripting. Esso adotta la tecnica del dynamic-typing, ovvero il tipo della variabile dipende dal valore contenuto in essa. Ovviamente, per questo motivo, non è possibile effettuare il casting esplicito. Ad esempio una variabile può assumere un intero, che può essere cambiato in una stringa per poi diventare un array. Gli array Gli array in Livecode sono sempre trattati come associativi. Le chiavi degli elementi sono rappresentati da stringhe. Anche se si utilizzano degli interi come chiavi, per ogni elemento viene calcolato un hash basato sulla chiave che lo inserisce in una posizione specifica. Esiste più di un metodo per leggere il contenuto degli array: 1. Si può scorrere a partire dalla lista delle chiavi tramite la proprietà the keys of array 2. Si può creare un ciclo per ogni elemento senza tenere conto delle chiavi (repeat for each element x in array) 3. Se siamo sicuri che le chiavi sono rappresentate da numeri interi da 1 a N allora possiamo usare la seguente istruzione: repeat with index=1 to N

28 CAPITOLO 1. STRUMENTAZIONI 16 Le stringhe La migliore parte del linguaggio è sicuramente quella dedicata alla gestione delle stringhe. Livecode rende facilissimo l utilizzo e la gestione di queste ultime mettendo a disposizione una serie di comandi che permettono di navigare all interno come se fossero delle vere e proprie strutture dati. Le stringhe possono essere organizzate in: items, elementi separati da virgole lines, il separatore di default è il return (la fine della riga) words, parole divise da qualunque tipo di spazio Sia nel caso degli items che delle lines, esistono delle proprietà di sistema ( itemdelimiter e linedelimiter ) che assumono come valori di default i caratteri indicati. Tuttavia possono essere modificati direttamente dall utente ed impostati a qualunque carattere o stringa. Grazie a questa funzionalità, il linguaggio permette di effettuare facilmente il parsing di testi formattati in qualunque modo. Livecode mette a disposizione una moltitudine di comandi simili a quelli degli array, per trattare le variabili strutturate in questo modo. Alcuni esempi di manipolazione delle stringhe possono essere i seguenti: put item 3 to 6 of var1 into var2 repeat for each line tline in var3 put char 1 to 5 of var4 into word 10 of var Lo scope delle variabili Le variabili hanno una loro validità a seconda di dove e come esse sono dichiarate. Esistono vari livelli di scope: local, in questo caso la variabile ha validità soltanto all interno dell handler in cui è dichiarato. La dichiarazione della variabile preceduta dalla parola chiave local è facoltativa.

29 CAPITOLO 1. STRUMENTAZIONI 17 script local, la variabile deve essere dichiarata al di fuori di ogni handler di uno script di un oggetto. Viene vista all interno di ogni messaggio o funzione dello script. global, la dichiarazione può avvenire sia all interno di un handler sia all esterno. Se si vuole utilizzare una variabile globale all interno di uno script, essa deve essere dichiarata accompagnata dalla parola chiave global. Se ad esempio il button p1 ed il button p2 usano la variabile gvar, in entrambi gli script associati deve essere presente la direttiva global gvar L ambiente di sviluppo L IDE distribuito da RunRev per programmare in Livecode ha una struttura molto intuitiva e user-friendly. Uno dei suoi obiettivi principali è di semplificare la creazione delle interfacce grafiche. Livecode è una via di mezzo tra i linguaggi di programmazione interpretati e quelli compilati. RunRev lo definisce (a mio parere erroneamente) un linguaggio compile-free. Ciò è in parte vero perché l ambiente di sviluppo permette di testare direttamente tutte le funzionalità del programma al quale si sta lavorando senza il bisogno di compilare passando dal cosiddetto edit mode all innovativo run mode. Con il primo si possono creare stack, aggiungere card, trascinare controlli (pulsanti, campi di testo, tabelle,...) sulle finestre, modificare le proprietà e gli script degli oggetti. Il secondo invece è una modalità che contraddistingue questo linguaggio di programmazione dagli altri. Il suo scopo è di permettere allo sviluppatore di testare gli elementi della GUI, stimolando direttamente i controlli dell interfaccia come se il programma fosse stato compilato per la distribuzione. Questo appena descritto rappresenta un vantaggio enorme rispetto ad altri linguaggi di programmazione in quanto abbatte completamente i tempi di compilazione dei software per analizzare il comportamento di essi. Sostengo che il linguaggio non può essere completamente definito compilefree perché ogni progetto per essere distribuito come eseguibile stand-alone

30 CAPITOLO 1. STRUMENTAZIONI 18 deve essere appunto compilato. Figura 1.5: Screenshot dell ambiente di sviluppo Nella figura 1.5 viene mostrata l interfaccia grafica dell ambiente di sviluppo. Sulla sinistra si può notare una piccola finestra con una serie di pulsanti. Ognuno di essi rappresenta un oggetto da posizionare tramite drag-and-drop su uno stack: si distinguono i pulsanti, checkbox, radio button, label, option button ed altri. I pulsanti posizionati immediatamente sotto la barra del titolo di questa finestra permettono di passare dall edit mode al run mode. La toolbar in alto contiene pulsanti per di raggruppare i vari controls, invocare il Message Box 4, bloccare lo scambio dei messaggi, visualizzare il Dictionary 5 ed altro. L Application Browser mostra la struttura del progetto in sviluppo organizzata in una vista ad albero. La radice è sempre il MainStack, gli elementi sotto di esso sono i substack. All interno di ogni stack è presente la lista delle 4 Tool dell ambiente di sviluppo Livecode che permette di eseguire istruzioni singole 5 Importante per visualizzare descrizioni per tutte le parole chiave, i messaggi e le funzioni di sistema

31 CAPITOLO 1. STRUMENTAZIONI 19 sue card. Quando si clicca su una di esse sulla destra viene visualizzata la lista di tutti gli oggetti contenuti in essa. Sotto l Application Browser è posizionato l editor degli script. Quest ultimo è organizzato in tab, ognuno dedicato ad un oggetto DataGrid Un elemento fondamentale e rivoluzionario di Livecode è il DataGrid. Esso rappresenta un oggetto dell interfaccia, in particolare una tabella. La caratteristica che differenzia i DataGrid dalle semplici tabelle è che possono contenere degli oggetti come pulsanti, combobox, checkbox, ed altri, all interno delle righe. Per fare si che questo accada, bisogna definire un template di riga o di colonna. Il column template definisce la struttura interna di ogni cella di una specifica colonna, mentre il row template la costituzione di una intera riga della tabella. Ogni qualvolta viene aggiunta una riga al DataGrid vengono creati gli oggetti definiti nel template. Inoltre può essere associato uno script ad ogni template di colonna chiamato column behavior, per effettuare delle operazioni quando, ad esempio, l utente modifica il contenuto delle celle corrispondenti. I DataGrid sono degli oggetti molto utili che vengono usati molto spesso nelle applicazioni Livecode perché semplificano il lavoro dello sviluppatore nella maggior parte dei casi. Quando si crea un nuovo DataGrid non esiste alcun row template o column template. Se l utente vuole associare un column template ad un campo, lo deve fare tramite il Property Inspector 6 del DataGrid stesso. Dopo averlo associato viene aperto uno stack dedicato ad i template di tutti i DataGrids del MainStack, e si posiziona su una card creata appositamente. A questo punto bisogna modificare il column template aggiungendo tutti gli oggetti che si desiderano. 6 Tool dell ambiente di sviluppo che serve a visualizzare ed eventualmente modificare le proprietà dell oggetto selezionato

32 CAPITOLO 1. STRUMENTAZIONI 20 Figura 1.6: Esempio di DataGrid Nel momento in cui si crea il column template viene creato automaticamente un column behavior di default. Tutte le funzioni presenti all interno di questo script sono riferiti ad una particolare colonna di una riga specifica. I messaggi presenti nello script sono i seguenti: FillinData, che viene chiamato quando viene modificato il valore di una cella in una particolare riga. LayoutControl, è inviato quando viene modificata la dimensione della cella. ResetData, eseguito quando viene inviato un messaggio di reset al DataGrid. EditValue, inviato quando l utente decide di modificare il contenuto della cella in questione. mousedoubleup, messaggio associato all azione di double-click da parte dell utente. Di default provoca l apertura di un field per permettere all utente di modificare il contenuto di una cella. Per rendere utile e funzionale il DataGrid, il compito dello sviluppatore è di modificare i column behavior per adattarli ad i particolari template.

33 CAPITOLO 1. STRUMENTAZIONI 21 Ad esempio se il column template viene modificato aggiungendo un option button, il metodo FillinData deve essere definito in modo tale che viene selezionata la riga corrispondente al testo passato come parametro, oppure nel caso di una checkbox se il parametro è true o false bisogna selezionare o deselezionare l oggetto Externals RunRev permette di usare linguaggi come C/C++ all interno dei progetti. Se si possiede una libreria scritta in un linguaggio di basso livello, si può creare una interfaccia grafica con Livecode ed un wrapper che la usa in modo molto semplice. Sul sito ufficiale è possibile scaricare uno stack file che crea un template di progetto per gli ambienti di sviluppo Xcode (per Mac OS X) e Visual C++ (per Windows). Nel primo caso una volta effettuata la compilazione, l output non è un file eseguibile bensì un file con estensione.bundle. Nel secondo caso, invece, viene creata una libreria dll. In questi progetti lo sviluppatore può definire sia funzioni che procedure (equivalente del messaggio in Livecode) con una signature specifica uguale per tutti. void nomefunzione(char *p_arguments[], int p_arguments_count, char **r_result, int *r_pass, int *r_err) Dove: p_arguments contiene il valore degli argomenti passati per parametro. p_arguments_count rappresenta il numero di parametri passati. r_result è la stringa di ritorno della funzione o della procedura. r_pass se viene impostato ad 1 nella funzione allora l handler viene passato al prossimo oggetto nel message path. r_err se viene impostato ad 1 significa che si è verificato un errore e si interrompe il flusso di istruzioni del chiamante.

34 CAPITOLO 1. STRUMENTAZIONI 22 All interno del file.c o.cpp a seconda dei casi, bisogna utilizzare delle macro che associano alla funzione o procedura scritta in C, la stringa da utilizzare se quest ultima vuole essere chiamata dal progetto Livecode. Le direttive sono le seguenti: EXTERNAL_DECLARE_FUNCTION(funzione, "funzione") EXTERNAL_DECLARE_COMMAND(comando, "comando") La prima dichiara una funzione chiamata funzione, la seconda invece una procedura (messaggio) chiamata comando. Ovviamente devono essere presenti anche le definizioni di entrambe le funzioni altrimenti la libreria non viene compilata [8]. La chiamata in Livecode avviene come in tutti gli altri casi. Una volta scritto e compilato questo codice, bisogna includere le librerie create nel progetto. Questa operazione può essere fatta in due modi: 1. Tramite il property inspector del MainStack, sotto la voce Externals, può essere aggiunto un file.bundle oppure.dll. 2. Tramite il comando set the externals of this stack to tpath, dove tpath indica il percorso della libreria. All interno delle funzioni definite possono essere usate una serie di API messe a disposizione dalle librerie degli externals incluse automaticamente nel progetto. Le più importanti a mio parere sono quelle per prelevare o modificare il valore dei parametri passati alla funzione o variabili locali. Per procedere all illustrazione di queste interfacce bisogna descrivere prima una struttura dati importante: la struttura ExternalString. Essa ha due campi, buffer e length. Il primo è un array di caratteri ed il secondo indica la lunghezza in bytes del primo. Anche questa struttura dati viene definita nelle librerie degli externals. Le funzioni di cui si parlava precedentemente sono: char *GetVariable(const char *p_variable_name, int *r_success) Questa funzione accetta come parametro il nome della variabile passata ed un intero, che assume un valore positivo se l operazione ha successo.

35 CAPITOLO 1. STRUMENTAZIONI 23 L operazione effettuata è il prelievo del valore di una variabile locale presente nel contesto del chiamante. void SetVariable(const char *p_variable, const char *p_value, int *r_success) Prende in ingresso il nome di una variabile, una stringa e l intero che indica se l operazione è andata a buon fine. L obiettivo della procedura è di modificare il valore di una variabile locale del chiamante della funzione external void GetVariableEx(const char *p_name, const char *p_key, ExternalString *r_value, int *r_success) Questa funzione ha lo stesso obiettivo della getvariable ma può anche prelevare un elemento di un array definito al di fuori dell external. Il primo parametro indica il nome della variabile, il secondo invece la chiave dell array associata all elemento che si vuole prelevare. L ultimo parametro è il solito parametro di controllo ed il terzo è un puntatore ad un oggetto della struttura dati ExternalString che viene modificato con il contenuto dell elemento dell array. void SetVariableEx(const char *p_name, const char *p_key, const ExternalString *p_value, int *r_success) I parametri di questa funzione sono gli stessi della precedente e l obiettivo è esattamente il contrario, ovvero modifica il valore di un elemento dell array passato come parametro. Le interfacce appena descritte sono state utilizzate ampiamente all interno dell external creato per l applicazione sviluppata. Nel caso del mio software ho dovuto creare un bundle per Mac OS X con l IDE Xcode a causa di una limitazione di Livecode. Le librerie di sistema dei database non supportano una gestione separata per i campi di tipo BLOB, i quali dovrebbero essere trattati diversamente da quelli di testo o numerici, e quindi se l utente vuole esportare il documento non può visualizzarlo correttamente. La mia libreria scritta in C utilizza le API di SQLite ed ha lo scopo di restituire il reale valore del campo.

36 Capitolo 2 Analisi dei requisiti 2.1 Prefazione In questa sezione del documento vengono trattate le fasi di raccolta ed analisi dei requisiti del software da sviluppare. 2.2 Modello funzionale Funzionalità richieste Il sistema avrà lo scopo di gestire basi di dati di tipo SQLite tramite un interfaccia grafica semplificata per l utente, che permetta di: Creare, modificare e cancellare tabelle Creare, modificare e cancellare viste Aggiungere, modificare e rimuovere righe all interno delle tabelle Comporre, eseguire e visualizzare il risultato di query Comporre query tramite un query builder 1 1 Tool grafico che mostra le tabelle come dei rettangoli con all interno la lista dei campi, associa le tabelle con delle linee che rappresentano le join ed aiuta l utente a comporre le clausole where, group by, order by 24

37 CAPITOLO 2. ANALISI DEI REQUISITI 25 Effettuare Backup e Restore dei database di cui si fa utilizzo Importare database esistenti Oltre a queste funzionalità il sistema dovrà fornire un metodo per mostrare il contenuto dei campi delle tabelle di tipo BLOB come immagini, oppure esportarlo all interno di un file definito dall utente Specifica dei requisiti Requisiti funzionali Dopo un attento studio dei requisiti del sistema si identificano i seguenti requisiti funzionali nel dettaglio: Gestione delle tabelle: l obiettivo del software è di minimizzare il numero di operazioni per visualizzare e modificare il database. Per questo motivo l utente deve poter avere un metodo alternativo da quello della riga di comando per creare, modificare ed eliminare tabelle. Per raggiungere tale obiettivo il sistema dovrà mostrare una interfaccia grafica che darà all utente una visione diretta e specifica della struttura interna della tabella, comprensiva della lista dei campi, dei vincoli di colonna e di tabella. Deve risultare semplice e trasparente all utente aggiungere proprietà, modificarle ed eventualmente eliminarle grazie a pulsanti e tabelle apposite. Gestione delle righe: anche in questo caso, come del resto in tutti gli altri, l utente deve ridurre al minimo le operazioni. Egli dovrà avere una visione d insieme sul contenuto delle tabelle, nello specifico le righe, per poterne aggiungere altre, visualizzare ed eventualmente modificare quelle già esistenti o eliminarle. Gestione delle viste: l utente deve, come nel caso delle tabelle, creare modificare e cancellare viste nel database in maniera semplificata. Gestione delle query: come detto nella precedente sezione, il sistema dovrà avere un query builder per costruire appunto delle query in modo

38 CAPITOLO 2. ANALISI DEI REQUISITI 26 molto semplice. Il software deve dare anche la possibilità di effettuare query direttamente come da riga di comando. Il query builder dovrà aiutare l utente ad avere una visualizzazione di tutte le tabelle del sistema per permettergli di selezionare i loro campi ed eventualmente usare le join. Anche per comporre ad esempio la clausola where, l utilizzatore del software deve visualizzare la lista dei campi delle tabelle selezionate per creare delle condizioni riducendo al minimo la possibilità di comporre query errate. Sono previste agevolazioni anche per i criteri di raggruppamento e di ordinamento. Inoltre l utente deve poter modificare a mano la query prima dell effettiva esecuzione della stessa. Gestione dei backup: l applicazione deve fornire un modo per effettuare backup dei database aggiungendo un commento mnemonico. Ovviamente l utente deve poter visualizzare la lista dei backup effettuati con la relativa data di creazione per poi decidere eventualmente di ripristinare la copia dell attuale database. Requisiti non funzionali Di seguito viene mostrata la lista dei requisiti non funzionali identificati: Importazione database: l utente deve poter importare database esistenti in due modi: 1. Il primo è indicando il percorso del file del database. 2. Il secondo è di importare il file tramite drag-n-drop nella finestra. Lista databases: il sistema deve mostrare una lista di tutti i database aperti fino a quel momento soltanto finché l utente non decide di eliminare completamente il riferimento ad esso. PRAGMA: l utente deve poter cambiare facilmente le proprietà PRAG- MA dei database che utilizza ed eventualmente salvare queste modifiche in modo tale che ogni volta che viene aperto lo stesso database, vengono caricate le stesse preferenze.

39 CAPITOLO 2. ANALISI DEI REQUISITI 27 Salvataggio query: un altro requisito non funzionale è quello di salvare le query in modo tale che l utente possa rieseguirle senza il bisogno di riscriverle. Anche il query builder deve prevedere una funzione che salva la sua struttura per poterla ripristinare in un secondo momento. Vista con query builder: durante la creazione o la modifica di una vista, l utente deve poter utilizzare il query builder per comporre la query associata e quindi per rendergli l operazione il più semplice possibile

40 CAPITOLO 2. ANALISI DEI REQUISITI Diagrammi dei casi d uso Casi d uso relativi alle operazioni principali

41 CAPITOLO 2. ANALISI DEI REQUISITI 29 Casi d uso sulle modifiche della struttura delle tabelle

42 CAPITOLO 2. ANALISI DEI REQUISITI 30 Restanti casi d uso

43 CAPITOLO 2. ANALISI DEI REQUISITI Mockups Prima di passare alla fase di progettazione del sistema, sono stati composti dei mockup per decidere nel miglior modo la composizione dell interfaccia grafica, e quindi delle finestre. Di seguito vengono mostrati soltanto alcuni scenari del software sviluppato. Figura 2.1: Mockup finestra principale L immagine 2.1 rappresenta la facciata principale del programma. Sulla sinistra viene mostrata la lista dei database e le relative tabelle e viste, in alto invece c è la toolbar ed al centro la drag area, dedicata al drag n drop dei database SQLite. La figura 2.2 invece, rappresenta la vista che permette all utente di aggiungere, modificare o rimuovere righe. L interfaccia del query builder viene descritta nei successivi quattro mockups. Il primo è la vista delle tabelle selezionate con le eventuali join. Il secondo invece rappresenta la finestra che si occupa di gestire la clausola

44 CAPITOLO 2. ANALISI DEI REQUISITI 32 Figura 2.2: Mockup modifica delle righe where. La terza figura serve all utente per utilizzare delle aggregate functions come MIN, MAX, COUNT, ed altre. L ultima è l interfaccia dedicata all eventuale clausola order by.

45 CAPITOLO 2. ANALISI DEI REQUISITI 33 Figura 2.3: Mockup selezione tabelle del query builder Figura 2.4: Mockup clausola where del query builder

46 CAPITOLO 2. ANALISI DEI REQUISITI 34 Figura 2.5: Mockup group by del query builder Figura 2.6: Mockup order by

47 CAPITOLO 2. ANALISI DEI REQUISITI Tabelle di Cockburn Di seguito vengono mostrate le tabelle di Cockburn degli use cases Crea nuovo database, Apri database e Connessione al database. Una lista completa di delle tabelle di Cockburn riguardo a tutti gli use cases si trova nell appendice A. Use Case Crea nuovo database Goal in context L utente vuole creare un nuovo database Scope & Level SuD, user goal Preconditions Success end L utente crea il database conditions Failed end L utente annulla la creazione conditions Primary Utente Actors Trigger L utente clicca su New Database Description Step Actor System 1 Clicca su New Database 2 Mostra la finestra di creazione 3 Inserisce il nome del database 4 Clicca sul pulsante di scelta della cartella 5 Mostra pannello di scelta della cartella 6 Sceglie la cartella e clicca su Create

48 CAPITOLO 2. ANALISI DEI REQUISITI 36 7 Chiude la finestra ed inserisce nella lista dei database quello appena creato Extensions Step Actor System <Annullamento *a Clicca sul pulsante operazione> Cancel Chiude la finestra di creazione Use Case Apri database Goal in context L utente vuole aprire un database esistente Scope & Level SuD, user goal Preconditions Success end L utente apre il database conditions Failed end L utente annulla la creazione, il formato del conditions database non è supportato Primary Utente Actors Trigger L utente clicca su Open Database Description Step Actor System 1 Clicca su Open database 2 Mostra la finestra di apertura database 3 Clicca sul pulsante di scelta del file 4 Mostra pannello di scelta del file 5 Sceglie il file

49 CAPITOLO 2. ANALISI DEI REQUISITI 37 6 Mostra il percorso nella casella di testo 7 Clicca su Open 8 Inserisce il database nella lista e chiude la finestra Extensions Step Actor System <Annullamento *a Clicca sul pulsante operazione> Cancel Chiude la finestra <Database non 8b Mostra errore Database valido> format is not valid 9b Chiude la finestra Subvariations Step Actor System <Drag & Drop> 1a Trascina il file nella finestra 2a Inserisce il database importato nella lista Use Case Goal in context Scope & Level Preconditions Success end conditions Failed end conditions Primary Actors Trigger Connessione al database L utente vuole aprire una connessione al database SuD, user goal Deve essere selezionato un database nella lista La connessione avviene con successo Errore durante la connessione Utente L utente clicca sul pulsante Connect

50 CAPITOLO 2. ANALISI DEI REQUISITI 38 Description Step Actor System 1 Clicca sul pulsante Connect 2 Preleva le informazioni sul database selezionato ed apre una connessione 3 Mostra nella vista ad albero il numero di tabelle e di viste Extensions Step Actor System <Errore di connessione> 3a Mostra un messaggio di errore Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro e seleziona Connect Database Torna al passo 2

51 CAPITOLO 2. ANALISI DEI REQUISITI Modelli di dominio Diagrammi di sequenza Nel seguente paragrafo verranno illustrati soltanto alcuni sequence diagrams per migliorare la leggibilità del presente documento. Per avere una visione completa dei diagrammi di sequenza di analisi si può consultare l appendice B. Figura 2.7: Sequence diagram - Apertura database esistente

52 CAPITOLO 2. ANALISI DEI REQUISITI 40 Figura 2.8: Sequence diagram - Creazione nuovo database

53 CAPITOLO 2. ANALISI DEI REQUISITI 41 Figura 2.9: Sequence diagram - Connessione al database

54 CAPITOLO 2. ANALISI DEI REQUISITI 42 Figura 2.10: Sequence diagram - Disconnessione del database

55 Capitolo 3 Design del sistema 3.1 Introduzione Come richiesto dalle specifiche del sistema, il linguaggio da utilizzare per lo sviluppo è Livecode, di conseguenza la progettazione è adattata a quest ultimo. 3.2 Architettura L analisi del software da sviluppare ha evidenziato una necessità di fare una suddivisione per livelli per una migliore organizzazione strutturata. In particolare, viene utilizzata l architettura a 3-tier 1 rappresentata nella figura 3.1. I tre livelli sono: 1. Presentation: rappresenta la GUI del sistema. Il suo obiettivo è di mostrare all utente la struttura interna del database, nonché il contenuto delle tabelle e viste. Inoltre deve dare la possibilità di comporre comandi di DDL 2 e DML 3 in modo semplificato. A causa degli scopi 1 Architettura a tre livelli 2 Data Definition Language, riguarda tutto ciò che modifica gli oggetti del database 3 Data Manipulation Language, riguarda le operazioni di gestione del contenuto degli oggetti (select, insert,...) 43

56 CAPITOLO 3. DESIGN DEL SISTEMA 44 Figura 3.1: Architettura del sistema principali dell applicazione è sicuramente il livello più importante dal punto di vista dell utente. 2. Business Logic: si occupa di tutta la parte gestionale, che si interfaccia al database ed alle strutture dati del software per restituire i dati necessari al livello superiore, o eseguire comandi del livello inferiore (DBMS, XML). Dal punto di vista dello sviluppatore è questo il livello più importante e corposo in quanto si esegue gran parte del lavoro.

57 CAPITOLO 3. DESIGN DEL SISTEMA Data Management: è il livello più basso. Rappresenta i database fisici 4 collegati con il sistema, sui quali si prelevano ed inseriscono i dati. Parte di questo sottosistema riguarda la gestione del file XML dove sono contenute una serie di informazioni e proprietà del software. Si parlerà ampiamente nei prossimi paragrafi dell argomento. La struttura appena presentata non è altro che una organizzazione logica dell applicazione. E stata scelta la seguente perché si concilia al meglio con i requisiti del sistema e semplifica lo sviluppo grazie alla divisione delle responsabilità tra i vari sottosistemi. Dato che ogni livello si occupa di una funzione specifica, risulta molto semplice effettuare una modifica nel codice sia per un espansione del sistema che per la localizzazione di un malfunzionamento. La strutturazione per livelli dell architettura è necessaria per lo sviluppo di un software di qualità dato che migliora la manutenibilità dello stesso. 3.3 Struttura del file delle preferenze XML In seguito allo studio approfondito dei requisiti del sistema da sviluppare si è reso necessario elaborare un metodo per memorizzare alcuni dati persistenti. Ricordiamo che questi sono: La lista dei databases aperti dall utente. La lista delle proprietà PRAGMA per ogni database. Le query salvate dall utente (sia quelle semplici che composte con il query builder). L elenco delle informazioni relative ai backup effettuati. Per realizzare questo scopo si è deciso di non creare un database, bensì di organizzare i dati all interno di un file XML 5, il quale è molto più adatto in questo caso. Lo scheletro principale è sicuramente dedicato alla lista dei 4 Nel caso dell applicazione in questione sono, nella maggior parte dei casi, più di uno 5 extensible Markup Language

58 CAPITOLO 3. DESIGN DEL SISTEMA 46 databases aperti dall utente, dato che tutto il resto delle informazioni sono legate proprio a quest ultima. Poi, per ogni elemento, saranno presenti i dati appena descritti. Di seguito troviamo la DTD 6 del file XML: <!DOCTYPE root SYSTEM [ <!ELEMENT root (database-list)> <!ELEMENT database-list (name,url,type,backup-list,pragma,query-list,query-builder-list)> <!ELEMENT name (#PCDATA)> <!ELEMENT url (#PCDATA)> <!ELEMENT type (#PCDATA)> <!ELEMENT backup-list (backup*)> <!ELEMENT backup (date,comment,file)> <!ELEMENT date (#PCDATA)> <!ELEMENT comment (#PCDATA)> <!ELEMENT file (#PCDATA)> <!ELEMENT pragma (#PCDATA)> <!ELEMENT query-list (name,sql)> <!ELEMENT name (#PCDATA)> <!ELEMENT sql (#PCDATA)> <!ELEMENT query-builder-list (query*)> <!ELEMENT query (name, tables, joins, distinct, where-list, where-condition, aggregate-field, aggregate-function, group-by-field, having, order-by-list)> <!ELEMENT name (#PCDATA)> <!ELEMENT tables (table+)> <!ELEMENT table (index,name,fields)> <!ELEMENT index (#PCDATA)> <!ELEMENT name (#PCDATA)> <!ELEMENT fields (field*)> <!ELEMENT field (name,value)> <!ELEMENT name (#PCDATA)> <!ELEMENT value (#PCDATA)> <!ELEMENT joins (join*)> <!ELEMENT join (from,to,condition,type)> <!ELEMENT from (#PCDATA)> <!ELEMENT to (#PCDATA)> <!ELEMENT condition (#PCDATA)> <!ELEMENT type (#PCDATA)> <!ELEMENT distinct (#PCDATA)> <!ELEMENT where-list (where*)> <!ELEMENT where (parentesi-aperta, field, operator, value, parentesi-chiusa, AND-OR) <!ELEMENT parentesi-aperta (#PCDATA)> <!ELEMENT field (#PCDATA)> <!ELEMENT operator (#PCDATA)> <!ELEMENT value (#PCDATA)> <!ELEMENT parentesi-chiusa (#PCDATA)> <!ELEMENT AND-OR (#PCDATA)> <!ELEMENT where-condition (#PCDATA)> <!ELEMENT aggregate-field (#PCDATA)> <!ELEMENT aggregate-function (#PCDATA)> <!ELEMENT group-by-field (#PCDATA)> <!ELEMENT having (#PCDATA)> <!ELEMENT order-by-list (order-by*)> <!ELEMENT order-by (field,type)> <!ELEMENT field (#PCDATA)> <!ELEMENT type (#PCDATA)> ]> 6 Document Type Definition: definisce una struttura per un documento XML

59 CAPITOLO 3. DESIGN DEL SISTEMA 47 Descriviamo nel dettaglio gli elementi del file XML: I campi name, url, type indicano rispettivamente il nome del database, il percorso dello stesso ed il tipo di database. Quest ultimo elemento si è voluto aggiungere per eventuali sviluppi futuri che conterranno il supporto ad altri DBMS come MySQL ed Oracle. L elemento backup-list contiene la lista di tutti i backup effettuati dall utente. In particolare vengono memorizzati un commento, il file corrispondente e la data di creazione. L elemento PRAGMA contiene, per ogni proprietà pragma il suo valore corrispondente, in modo tale che ad ogni apertura dello stesso database, viene eseguita la lista di tutti i comandi. Query-list come si può osservare contiene la lista delle query salvate dall utente. Query-builder-list a differenza del precedente mantiene le informazioni sulle query create e salvate dall utente tramite il query-builder. Quindi ogni singolo elemento contiene informazioni necessarie e specifiche dell interfaccia dedicata a questo scopo.

60 CAPITOLO 3. DESIGN DEL SISTEMA Diagramma delle classi Come già detto in precedenza, la progettazione è orientata al linguaggio di programmazione da utilizzare, Livecode. Per questo motivo gli oggetti sono in numero ristretto ed è più semplice ragionare in base alla struttura di base del linguaggio stesso. Il class diagram seguente descrive l organizzazione tra gli stacks e le cards del sistema. Naturalmente ogni card è composta da vari controls, come ad esempio buttons, fields e groups. Nel diagramma queste informazioni non sono state inserite per questioni di spazio e di comprensione dell immagine. Gli altri oggetti menzionati nei diagrammi di sequenza successivi sono: Field, Button, Group, DataGrid, Graphic, Image, FolderPanel, FilePanel. Ognuno di essi, nella maggior parte dei casi, è presente all interno di ogni card del sistema.

61 CAPITOLO 3. DESIGN DEL SISTEMA 49 Figura 3.2: Class Diagram - stacks e cards

62 CAPITOLO 3. DESIGN DEL SISTEMA Diagramma di stato Sulla base del diagramma delle classi appena mostrato, per rendere più comprensibili gli stati che il sistema assume, può essere utile uno schema che mostri i passaggi tra le cards del sistema. Figura 3.3: Diagramma di stato - Percorsi delle cards La figura 3.3 identifica gli stati del sistema. Gli stati più grandi rappresentano una prima divisione tra le funzionalità più importanti. Essi

63 CAPITOLO 3. DESIGN DEL SISTEMA 51 sono: MainCards, composto delle card di visualizzazione delle tabelle, viste, e l interfaccia principale dove può essere effettuato il drag & drop di un database SQLite. SQL rappresenta tutte le cards che si occupano di dare la possibilità all utente di effettuare query come da riga di comando. ManageTable, è lo stato nel quale si entra quando l utente vuole creare o modificare la struttura delle tabelle. QueryBuilder, è costituito dall insieme di cards che aiutano l utente a creare delle query. Tutti gli altri stati, sia gli inclusi in quelli appena elencati che quelli singoli, rappresentano le cards del sistema. Le frecce ovviamente sono le transizioni possibili da una card all altra etichettate dall azione che scatena il passaggio.

64 CAPITOLO 3. DESIGN DEL SISTEMA Diagrammi di sequenza In questa sezione sono presenti i sequence diagrams del backup e restore del database, inserimento di una riga in una tabella e creazione di una vista. I restanti sequence diagrams sono illustrati nell appendice C. Figura 3.4: Sequence diagram - Backup database Figura 3.5: Sequence diagram - Restore database

65 CAPITOLO 3. DESIGN DEL SISTEMA 53 Figura 3.6: Sequence diagram - Inserimento di una riga

66 CAPITOLO 3. DESIGN DEL SISTEMA 54 Figura 3.7: Sequence diagram - Creazione di una vista

67 Capitolo 4 Implementazione 4.1 Problematiche riscontrate Introduzione La seguente sezione ha lo scopo di elencare e spiegare nel dettaglio una serie di problemi sorti durante l implementazione del software per la gestione di basi di dati SQLite. L insieme di problematiche riscontrate sono dovute al fatto che il linguaggio di programmazione ed il Database Management System utilizzati hanno delle limitazioni. Durante la progettazione alcuni di questi limiti non si conoscevano e perciò non erano previsti. Gli altri problemi sono elencati a causa della difficoltà della risoluzione degli stessi. Di seguito ne elenco alcuni: Parsing tramite espressioni regolari del codice SQL di creazione delle tabelle al fine di visualizzare la struttura interna di una tabella e poterla modificare tramite una sorta di Alter Table. Algoritmo della generazione del codice SQL in seguito alla costruzione di una query tramite il query-builder. Gestione limitata delle colonne di tipo BLOB 1 da parte del linguaggio di programmazione Livecode. 1 Binary Large OBject, tipo di dato presente nella maggior parte dei DBMS 55

68 CAPITOLO 4. IMPLEMENTAZIONE 56 Inesistenza in Livecode di un control che rappresenta una vista ad albero e creazione di quest ultimo Parsing del codice SQL Tra le specifiche dei requisiti del sistema da sviluppare era presente anche il supporto alla modifica delle tabelle dei database. Dati gli obiettivi dell applicazione 2, la modifica di una tabella prevede innanzitutto la visualizzazione della struttura interna della stessa, per eventualmente modificare o rimuovere campi, chiavi primarie, chiavi esterne, vincoli unique o check, già presenti. Inoltre bisogna anche permettere di aggiungere gli oggetti appena elencati. Quasi tutti i DBMS contengono delle tabelle di sistema che tengono traccia di tutti gli oggetti del DDL come tabelle, campi, vincoli di colonna e di tabella, viste, trigger e così via. Oracle ad esempio ha un database specifico che contiene le tabelle di sistema per descrivere la struttura dei databases creati dall utente. Le tabelle che fanno al nostro caso sono: USER_TAB_COLUMNS che memorizza le colonne di tutte le tabelle dei databases, completi di informazioni come la tabella di appartenenza, l annullabilità, il tipo, il valore di default ed altro. USER_CONSTRAINTS che elenca vincoli di ogni tipo delle tabelle, come check, unique, foreign key e primary key. [2] Anche MySQL ha delle tabelle simili come COLUMNS per le colonne, TABLE_CONSTRAINTS per i vincoli di tabella e KEY_COLUMN_USAGE per i vincoli di colonna. Esse sono contenute all interno del database apposito denominato INFORMATION_SCHEMA. [7] Sfortunatamente SQLite ha una sola tabella di sistema chiamata SQ- LITE_MASTER che contiene pochissime informazioni come il nome della tabella ed il codice SQL di creazione della stessa. Per raggiungere gli obiettivi del software da sviluppare queste informazioni sono limitate in quanto 2 Fornire una interfaccia grafica semplificata per effettuare le operazioni più importanti all interno di databases SQLite

69 CAPITOLO 4. IMPLEMENTAZIONE 57 c è bisogno della lista delle colonne con i relativi vincoli e le constraints di tabella. SQLite fornisce il comando PRAGMA table_info(...) per prelevare la lista delle colonne con i tipi ed il valore di default (quindi senza vincoli) ed un altro comando (PRAGMA foreign_key_list(...)) per la lista delle chiavi esterne. Anche in questo caso le informazioni disponibili non permettono di raggiungere gli obiettivi perché mancano vincoli unique, check e chiavi primarie. Dopo un attento studio della situazione appena descritta e la valutazione delle varie soluzioni è stato deciso di utilizzare il campo sql della tabella di sistema SQLITE_MASTER per prelevare tutte queste informazioni sulle tabelle da modificare. Per raggiungere tale scopo si è deciso di dividere la stringa sql utilizzando una serie di espressioni regolari. Livecode supporta le espressioni regolari, in particolare le espressioni PERL-compatibili, utilizzando la sintassi PCRE 3. Le funzioni che utilizzano le espressioni regolari sono le seguenti: 1: matchtext(string, regularexpression[, varlist]) La funzione ha lo scopo di valutare una espressione all interno di una stringa: string rappresenta la stringa di origine sulla quale deve essere valutata l espressione. regularexpression è l espressione regolare. varlist è un parametro opzionale, può essere anche più di uno, rappresentano delle variabili nelle quali viene messo il contenuto delle parentesi presenti nell espressione regolare. Il numero di questi parametri deve essere uguale alle parentesi dell espressione. il valore di ritorno è un booleano che vale true se l espressione corrisponde, false altrimenti. 3 Dettagli sulla sintassi PCRE si possono ottenere al seguente sito:

70 CAPITOLO 4. IMPLEMENTAZIONE 58 Un esempio di utilizzo può essere il seguente. Si vuole prelevare una parola da una stringa compresa tra NOME e COGNOME e metterla all interno di una variabile chiamata tname. matchtext( NOME francesco COGNOME..., NOME[\s]+([\w]+)[\s]+COGNOME, tname) Il ritorno della chiamata a questa funzione sarà true ed il contenuto di tname francesco. 2: replacetext(stringtochange, regularexpression, replacementstring) La funzione ha lo scopo di sostituire ciò che corrisponde all espressione con un altra stringa passata per parametro: stringtochange rappresenta la stringa di origine sulla quale deve essere valutata l espressione. regularexpression è l espressione regolare. replacementstring è la stringa che deve sostituire la parte di testo che rispetta l espressione regolare passata per parametro. il valore di ritorno è un booleano che vale true se l espressione corrisponde, false altrimenti. [9] La funzione utilizzata nell applicazione sviluppata è la prima. L obiettivo del parser è di prelevare, tramite le espressioni regolari, del testo all interno dell sql di creazione della tabella per inserirlo in delle variabili specifiche. Ad esempio la prima espressione regolare serve a prelevare il nome della tabella: si utilizza la funzione matchtext per inserire il nome nella variabile tname. Per effettuare il parsing della CREATE TABLE ho fatto riferimento alla sintassi completa descritta sul sito ufficiale di SQLite, in particolare all indirizzo [6]

71 CAPITOLO 4. IMPLEMENTAZIONE 59 Il metodo che implementa questa funzionalità è presente all interno dello script della card ManageTablesFields. Il suo valore di ritorno è una struttura dati, formata tramite array innestati, che ha una costituzione simile ad un documento XML. La struttura è la seguente: 4 array name constraints index name type fieldspk conflictpk fieldsunique conflictunique check fieldsfk tablereffk updatefk deletefk matchfk notdeferrablefk initiallyfk fields index name type constraints index name type pk pkascdesc pkconflict pkautoincr notnull nullconflict unique uniqueconflict check 4 Quando si incontra index significa che c è una lista ed al posto suo ci sono gli indici degli elementi

72 CAPITOLO 4. IMPLEMENTAZIONE 60 default collate tablefk fieldfk deletefk updatefk matchfk notdeferrablefk initiallyfk L algoritmo svolge i seguenti passaggi: 1. Viene valutata l espressione regolare per recuperare il nome della tabella. L espressione mette il nome nella variabile tnometabella e tutto ciò che viene dopo la parentesi tonda aperta (colonne e vincoli di tabella) in tcorpo che verrà utilizzata nelle prossime espressioni. 2. La variabile tcorpo viene trasformata in un array utilizzando come carattere separatore degli elementi la virgola Per ogni elemento dell array tcorpo si controlla se è un campo o un vincolo di tabella: Nel primo caso si preleva tramite una espressione regolare il nome, il tipo ed i vincoli di colonna. Questi ultimi a loro volta vengono trattati con una ulteriore espressione che identifica il tipo di constraint ed i suoi dettagli specifici. Quest operazione si ripete finché sono presenti vincoli di colonna nella definizione. Nel secondo caso invece, si creano delle variabili che identificano il tipo di constraint, e per ogni tipo le sue specifiche (ad esempio per le chiavi esterne il campo, la tabella ed il campo referenziati, le clausole on delete ed on update). 4. In entrambi i casi si comincia a comporre l array descritto precedentemente che sarà restituito dalla funzione. 5 In questo modo viene creato un array in cui ogni elemento può essere la definizione di una colonna della tabella o di una constraint di tabella

73 CAPITOLO 4. IMPLEMENTAZIONE 61 Una volta terminata la funzione, all interno dell array restituito ci sono tutte le informazioni necessarie sulla tabella data in input. L unica cosa da fare è posizionare i valori nei rispettivi DataGrid delle card della preparazione dell alter table. Innanzitutto si preleva la lista di tutti i campi ed i loro vincoli per popolare il DataGrid della card ManageTableFields. Successivamente, per ogni constraint di tabella, si controlla il tipo (primary key, foreign key, check o unique), si recuperano le informazioni specifiche a seconda di esso e si riempiono i DataGrid delle card ManageTablePrimaryKeys, ManageTableForeignKeys, ManageTableUnique e ManageTableCheck. Dopo che l utente completa le modifiche, cancellazioni ed aggiunte di campi e vincoli può procedere alla convalida di esse. SQLite anche in questo caso presenta una limitazione: la sintassi del comando Alter table non supporta tutte le operazioni possibili, infatti le uniche sono la rinomina della tabella e l aggiunta di un nuovo campo. 6 Per questo motivo, quando l utente clicca sul pulsante di conferma, non viene effettuata realmente una alter table, bensì delle operazioni combinate che simulano la modifica della tabella. Esse sono le seguenti: 1. Viene creata una nuova tabella con tutte le informazioni prelevate tramite il parser ed inserite dall utente con il nome della vecchia tabella modificato. 2. Vengono passati tutti i dati dalla vecchia alla nuova tabella. 3. Vengono disattivate le chiavi esterne tramite il comando PRAGMA foreign_keys=off, per evitare che tutte le righe delle altre tabelle che hanno come chiave esterna i campi della seguente, vengano cancellate. 4. Si cancella la vecchia tabella. 5. Si aggiorna il nome della nuova tabella rendendolo uguale a quella vecchia SQLite - ALTER TABLE syntax

74 CAPITOLO 4. IMPLEMENTAZIONE 62 In questo modo l utente non si accorge minimamente di tutti questi passaggi e modifica la tabella in modo molto semplice e veloce.

75 CAPITOLO 4. IMPLEMENTAZIONE Generazione query tramite query-builder Un altro requisito importante è quello della presenza del query-builder, ovvero un sottosistema in grado di aiutare l utente a formulare delle query grazie all interfaccia grafica. Quando l utente decide di eseguire la query, il sistema deve controllare in ogni oggetto delle card in questione (QueryBuilderTables&Fields, QueryBuilderWhere, QueryBuilderAggregate, QueryBuilderOrderBy) le informazioni necessarie per comporla. La clausola where è molto semplice da calcolare in quanto il DataGrid dedicato ad essa la descrive nei minimi dettagli. Per quanto riguarda invece l utilizzo di una aggregate function 7, bisogna identificare il campo selezionato dall utente, il tipo di funzione, l eventuale campo da inserire nella clausola group by, e la condizione having. La order by è altrettanto semplice dato che il DataGrid contiene le informazioni necessarie per costituire la clausola. La parte più complessa è quella che riguarda la selezione delle tabelle e le eventuali join tra di loro. La difficoltà sta nel fatto che bisogna trovare un modo per non permettere all utente tramite l interfaccia operazioni fisicamente impossibili, ovvero che non possono essere convertite in sql. Inoltre bisogna calcolare la query in modo che le tabelle siano ordinate nel modo più corretto possibile. Nella figura 4.1 ci sono due left join, una che va da studente a esame, ed un altra che va da esame a corso. Come si vede dal log in basso la query costruita in questo modo è: SELECT * FROM studente LEFT JOIN esame ON... LEFT JOIN corso ON... A questo punto bisogna bloccare ogni tentativo da parte dell utente di aggiungere una left join che parte da corso e finisce in studente. E ovvio che in questo caso e probabilmente anche in altri non è sensata una operazione del 7 MIN, MAX, COUNT, SUM,...

76 CAPITOLO 4. IMPLEMENTAZIONE 64 Figura 4.1: Screenshot query builder genere, ma bisogna comunque prevenire ogni operazione errata dell utente. Il motivo di questo blocco è che non può essere costruita una join fatta in questo modo dato che la tabella studente è già presente alla sinistra di una left join. La query risultante da questo errore sarebbe: SELECT * FROM studente LEFT JOIN esame ON... LEFT JOIN corso ON... LEFT JOIN studente ON... É evidente che essa è scorretta a meno che non si inseriscano gli alias per distinguere le ripetute tabelle studente. Di conseguenza l utente per arrivare ad una soluzione simile può, tramite il programma, aggiungere semplicemente una nuova tabella studente, infatti il query-builder assegna di default un alias ad ogni tabella selezionata per evitare queste situazioni. Per questo

77 CAPITOLO 4. IMPLEMENTAZIONE 65 motivo il sistema vieta all utente di creare join di questo genere. Le operazioni principali dell algoritmo del calcolo della query si riassumono brevemente di seguito: 1. Si prelevano le tabelle selezionate dall utente e le join create. 2. Si separano le left join dalle semplici join inserendoli in due array. 3. Si preleva la tabella che sta alla sinistra di una left join e che non sta anche alla destra di un altra left join. 4. A partire da questa tabella si tenta di creare un percorso di left join fino a quando la tabella alla destra non compare alla sinistra di un altra left join. 5. Per ogni left join inserita si controlla se le tabelle sono associate tramite una join ad una tabella precedentemente inserita in modo tale da aggiungere soltanto una clausola all interno della condizione on della left join. 6. Al termine di tutte le left join si inseriscono tutte le join semplici o i prodotti cartesiani partendo da quelle che contengono una tabella già inserita nella query composta fino a quel momento. 7. Solo in ultima istanza si prelevano le eventuali tabelle isolate e si separano tramite la virgola 8. In questo modo viene creata la query, si passa alla card che si occupa dell esecuzione e si mostra il risultato all utente Gestione dei BLOB Durante lo sviluppo si è arrivati al punto di decidere in che modo gestire i campi di tipo BLOB dei database. Durante questa fase ci si è resi conto che Livecode non permette di prelevare ed inserire i dati binari nel modo giusto. 8 La virgola in una query si traduce in un prodotto cartesiano

78 CAPITOLO 4. IMPLEMENTAZIONE 66 Essi sono trattati come semplici stringhe, diversamente dal DBMS SQLite e tutti gli altri. Per questo motivo quando si prelevava ad esempio un immagine e si cercava di creare un file con il contenuto del BLOB, quest ultimo non veniva visualizzato correttamente. Il problema non si verifica soltanto con le librerie SQLite ma anche con altre come MySQL. Dopo un attento studio si è deciso che la migliore scelta era di utilizzare le librerie ufficiali di SQLite, le quali, ovviamente, trattano diversamente i campi di testo dai BLOB. Queste librerie sono distribuite soltanto per il linguaggio C e per questo motivo non potevano essere incluse direttamente all interno del progetto Livecode. Fortunatamente Livecode permette di creare Externals, ovvero codice esterno scritto proprio in C/C++ che viene compilato come una libreria (bundle per Mac e dll per Windows) ed importato per utilizzarlo nel progetto. Il sito di RunRev mette a disposizione delle pagine web 9 per far comprendere meglio agli sviluppatori i passi da seguire per raggiungere il presente obiettivo. Come primo passo bisogna scaricare uno stack file chiamato ExternalEnvironmentV3 il quale va aperto con Livecode ed ha lo scopo di creare un progetto Xcode o Visual C++. Una volta creato, il progetto Xcode è stato aperto ed adattato al nostro problema. Sono state incluse le librerie SQLite e create le funzioni necessarie. Esse sono: containsblob controlla se la query contiene dei campi di tipo BLOB. gettypes è una alternativa alla precedente e restituisce per ogni colonna il tipo associato. getblob preleva il contenuto intero di una query che contiene BLOB. update_insert_blob inserisce delle righe che contengono dati binari. L utilizzo della libreria è assolutamente trasparente, infatti le funzioni o comandi creati vengono chiamati come se fossero parte integrante del progetto e definiti nel MainStack o qualsiasi substack. Basta indicare nel progetto 9

79 CAPITOLO 4. IMPLEMENTAZIONE 67 Xcode in che modo Livecode può chiamare le funzioni scritte in C tramite le macro: EXTERNAL_DECLARE_FUNCTION EXTERNAL_DECLARE_COMMAND Nel nostro caso le dichiarazioni sono state le seguenti: EXTERNAL_DECLARE_FUNCTION(containsBlob, "containsblob") EXTERNAL_DECLARE_COMMAND(getTypes, "gettypes") EXTERNAL_DECLARE_COMMAND(getBlob, "getblob") EXTERNAL_DECLARE_COMMAND(update_insert_blob, "update_insert_blob") La prima funzione prende in ingresso due parametri, tdatabase che contiene il percorso del file del database e tsql che rappresenta la query da effettuare. Il valore ritornato è un booleano che vale true se è presente almeno un campo BLOB, false altrimenti. Il secondo comando, gettypes, prende in ingresso gli stessi due parametri della precendente insieme ad un altro parametro, tcolumntypes, che inizialmente è vuoto ma viene modificato all interno della funzione la quale crea un array con i tipi delle colonne della query. Dato che l External di Livecode permette di ritornare soltanto una stringa e la funzione appena descritta restituisce un array di stringhe, essa viene dichiarata come COMMAND. La terza funzione è getblob ed ha come parametri di input sempre tdatabase, tsql. I parametri di output invece sono tcolumncount che come si può comprendere contiene il numero delle colonne della query, e tarray che conterrà il le righe organizzate in un array e non una matrice come si può pensare. Per questo motivo viene restituito tcolumncount, variabile utile per capire, durante lo scorrimento dell array, quando si è passati alla seconda riga. Ad esempio se la query restituisce 2 righe di 3 colonne tcolumncount varrà 3 e l array restituito avrà 6 elementi. I primi 3 rappresentano la prima riga, gli ultimi 3 la seconda.

80 CAPITOLO 4. IMPLEMENTAZIONE 68 L ultima funzione si occupa di eseguire una update o una insert ed accetta i parametri tdatabase, tsql, tnparameters, tvalues, ttypes. Lo scopo dei primi due è già descritto precedentemente. A differenza degli altri la query in questo caso è parametrica ed in tvalues e ttypes sono indicati i valori ed i tipi dei parametri. tnparameters contiene il numero di parametri presenti nella query. Se ad esempio la query fosse questa: INSERT INTO PERSONA (NOME, ETA) VALUES (:A, :1) tvalues conterrebbe nel primo elemento il nome della persona e nel secondo la sua età. L array ttypes, invece, conterrebbe i tipi che corrispondono ai campi, ovvero STRING nel primo elemento ed INTE- GER nel secondo Creazione di una vista ad albero L ultimo problema (il primo in ordine temporale) riscontrato è stato quello dell inesistenza di una vista ad albero in Livecode. Nel caso dell applicazione da sviluppare un oggetto di questo tipo è fondamentale in quanto bisogna avere una visione diretta dell elenco dei database e del loro contenuto (viste e tabelle). Il problema è stato risolto molto semplicemente utilizzando un DataGrid combinato con codice HTML. Il DataGrid è formato da una sola colonna, ed ogni riga contiene i dati necessari per identificare il livello dell elemento ed altre informazioni. E stato creato un Row Template che accetta come parametro un array associativo le cui chiavi che in questo caso ci interessano sono level e name. La prima chiave identifica ovviamente il livello di profondità dell elemento nell albero (primo, secondo, terzo e cosi via), la seconda invece il testo che dovrà essere visualizzato. Questa struttura può essere generalizzata ed adattata a seconda dei casi. Nel mio caso il primo livello ad esempio corrisponde ad un database e quindi avrà innanzitutto una icona che lo contraddistingue e poi del testo che indica il nome del file.

81 CAPITOLO 4. IMPLEMENTAZIONE 69 Il secondo livello può avere due valori, Tables(..) e Views(..) 10. In questi due casi l icona è un triangolino che identifica il fatto che hanno degli elementi al loro interno. Il triangolino ha inizialmente la punta verso destra che indica che la cartella è chiusa, ovvero che il contenuto non è visualizzato. Nel momento in cui l utente clicca su di esso la punta si sposta verso il basso e vengono elencate tutte le tabelle o viste a seconda di quale riga viene selezionata (Tables(..) o Views(..)). Il terzo ed ultimo livello rappresenta le tabelle o le viste ed ha una icona specifica in entrambi i casi. Figura 4.2: Esempio di vista ad albero La figura 4.2 mostra un esempio di vista ad albero ed il contenuto corrispondente è il seguente: <p><img src=db.png/>prova.sqlite</p> <p> <img src=tri.png/>tables(5)</p> <p> <img src=tab.png/>tabella</p> <p> <img src=tab.png/>sqlite_sequence</p> <p> <img src=tab.png/>esame</p> <p> <img src=tab.png/>corso</p> <p> <img src=tab.png/>studente</p> <p> <img src=tri.png/>views(1)</p> <p> <img src=view.png/>vista</p> 10 Tra parentesi viene indicato il numero di tabelle o di viste a seconda dei casi

82 CAPITOLO 4. IMPLEMENTAZIONE DataGrid Questa sezione è dedicata alla rappresentazione e la descrizione dei DataGrid utilizzati all interno del software. In particolare vengono illustrati i Row template ed i Column template creati. Grazie alla loro versatilità descritta nel secondo capitolo del presente documento, sono stati ampiamente utilizzati durante lo sviluppo dell applicazione. Essi hanno semplificato la realizzazione di molti scenari nei quali l utente deve compilare una serie di form con molti campi come per l inserimento delle colonne di una tabella, l inserimento delle chiavi esterne o clausole where nel caso del query builder. La loro caratteristica principale, ovvero la definizione dei template di riga e quindi l utilizzo di vari pulsanti all interno di esse, permette allo sviluppatore di rendere molto più veloce l implementazione rispetto ad altri linguaggi di programmazione che non supportano una tecnologia simile Creazione delle tabelle Nella parte del sistema dedicata alla creazione delle tabelle, sono presenti ben quattro DataGrids. Ognuno di essi ha per ogni colonna uno specifico column template ed un column behavior associato. Inserimento di nuovi campi Figura 4.3: Datagrid delle colonne delle tabelle Il row template più complesso è quello per l inserimento delle colonne di una tabella. Ogni volta che l utente preme il tasto + per aggiungere una nuova colonna nella tabella del database viene aggiunta una riga nel DataGrid con gli oggetti mostrati nella figura 4.3. Di seguito vengono descritti i campi del DataGrid:

83 CAPITOLO 4. IMPLEMENTAZIONE 71 Name, contiene il nome della colonna. Non ha un particolare template associato. Type, rappresenta il tipo della colonna. Come si può notare dalla figura 4.3 il column template è costituito da un option button 11 che contiene una lista di tipi supportati da SQLite (INT, INTEGER, TEXT, BLOB, NUMBER, REAL, VARCHAR, DATE, DATETIME,...). In realtà SQLite supporta soltanto 5 tipi, i quali sono TEXT, NUMERIC, INTEGER, REAL, NONE. Ogniqualvolta SQLite incontra un tipo di dato lo trasforma in uno di questi 5 tramite un particolare algoritmo. Nullable, indica tramite una checkbox se al campo può essere associato un valore nullo o meno. Il column behavior attiva il campo successivo solo nel caso in cui la casella non è attivata, ovvero se il campo non è annullabile. Nullable conflict, indica l operazione da effettuare quando si assegna un valore nullo ad una colonna non annullabile. I valori contenuti nell option button sono ROLLBACK, ABORT, FAIL, IGNORE, RE- PLACE. Primary key, è una checkbox che può essere selezionata dall utente solo se la chiave primaria è costituita da una sola colonna. 12 selezionata il column behavior attiva i 3 campi successivi. Se viene ASC/DESC, rappresenta un option button con due soli valori, ASC e DESC. Il corrispondente column behavior non fa nulla di particolare. Autoincrement, è una checkbox, e come il campo precedente non effettua alcuna operazione speciale. PK Conflict, ha la stessa funzione e struttura del Nullable Conflict. L unica differenza è che viene valutato il conflitto sulla chiave primaria. 11 Conosciuto anche come combobox 12 Infatti la card ManageTablePrimaryKeys si occupa del caso in cui la chiave primaria è composta da più colonne

84 CAPITOLO 4. IMPLEMENTAZIONE 72 Unique, anche il column template di questo campo è composto da una checkbox. Se è selezionata viene attivato il campo successivo. Unique Conflict, è un option button che contiene i valori ROLLBACK, ABORT, FAIL, IGNORE, REPLACE. Default value, come il campo Name non ha un template associato. Collate, il suo template contiene una option button con i valori BINA- RY, NOCASE ed RTRIM. Check, non ha un template associato. Quando viene eseguita una Alter table e viene effettuato il parsing del codice sql della creazione della tabella in questione, il DataGrid appena descritto viene automaticamente completato con i dettagli dei campi prelevati. Come spiegato in precedenza, viene implementato un algoritmo descritto da SQLite per la determinazione del tipo di una variabile. Dato che viene accettata qualunque stringa da SQLite per identificare un tipo, all atto del popolamento del DataGrid, l applicazione controlla se è presente nella lista dell option button del row template del campo Type. In caso positivo si seleziona quel valore, altrimenti si utilizza l algoritmo appena citato. Esso funziona in questo modo 13 : 1. Se il tipo contiene la stringa INT allora diventa un INTEGER. 2. Se è presente una stringa tra CHAR, CLOB, TEXT il tipo viene trasformato in TEXT. 3. Se il tipo contiene la stringa BLOB l applicazione la lascia com è (mentre SQLite lo tratta come NONE). 4. Se la stringa è composta da uno tra FLOA, DOUB o REAL allora diventa REAL. 5. Altrimenti è di tipo NUMERIC. [6] 13 Si noti che le alternative sono ordinate ed esclusive. Maggiori dettagli al sito

85 CAPITOLO 4. IMPLEMENTAZIONE 73 L algoritmo appena descritto è presente all interno del column behavior del campo Type del DataGrid. Inserimento chiavi esterne L inserimento delle chiavi esterne ha un funzionamento leggermente più complesso rispetto all aggiunta di nuovi campi. L obiettivo è sempre di semplificare e minimizzare le operazioni dell utente e per questo motivo si è pensato di elencare i campi creati nella card specifica, le tabelle già presenti ed i loro relativi campi. Nel momento in cui l utente clicca sul pulsante + per aggiungere una nuova chiave esterna viene aperto uno stack dedicato rappresentato nella figura 4.4. Figura 4.4: Finestra di selezione campi per le chiavi esterne Il campo Field del DataGrid rappresenta i campi della tabella che si sta creando o modificando. La checkbox relativa al column template del campo Foreign key del DataGrid indica se la colonna deve essere presente nella definizione della chiave esterna. Quando viene selezionata, il corrispondente column behavior attiva l option button del campo Field Referenced. Quest ultimo rappresenta il campo referenziato. Tutte queste operazioni possono

86 CAPITOLO 4. IMPLEMENTAZIONE 74 essere fatte solo dopo aver selezionato la tabella referenziata tramite l option button in alto, posizionato sopra al DataGrid. Terminata la definizione della chiave esterna, l utente preme Ok e viene aggiunta una riga nel DataGrid delle chiavi esterne. Figura 4.5: DataGrid delle chiavi esterne Il primo campo, Name rappresenta il nome della constraint. I successivi tre campi vengono aggiornati automaticamente quando l utente preme Ok nello stack di creazione della chiave esterna. I campi On delete ed On update hanno lo stesso column template che è composto da un option button che mette a disposizione una scelta tra CASCADE, NO ACTION, RESTRICT, SET NULL, SET DEFAULT. Esse rappresentano l azione da eseguire quando viene eliminata o modificata una riga con un campo referenziato tramite una foreign key. Inserimento unique constraint L aggiunta di una unique constraint all interno di una tabella funziona in un modo molto simile all inserimento di una nuova chiave esterna. Anche in questo caso quando l utente preme sul tasto +, viene aperto uno stack, precisamente quello mostrato nella figura 4.6, dove l utente può selezionare i campi interessati ed inserire il nome del vincolo Quando l utente conferma l inserimento, viene aggiunta una riga al DataGrid della lista delle unique constraints. Il primo campo è il nome della constraint, il secondo viene settato automaticamente, il terzo invece indica l azione da eseguire quando si crea un conflitto unique. Il corrispondente column template è formato da un option button contenente ROLLBACK, ABORT, FAIL, IGNORE e REPLACE. Non è presente uno specifico column behavior.

87 CAPITOLO 4. IMPLEMENTAZIONE 75 Figura 4.6: Finestra di selezione campi per le unique constraints Figura 4.7: Datagrid delle unique constraints Query builder Nella sezione del sistema dedicata al query builder sono presenti due Data- Grid, uno per costruire la clausola where, ed un altro per la order by. Nei prossimi paragrafi essi sono spiegati nel dettaglio. Clausola where Il DataGrid per la definizione della where in una query è sicuramente uno dei più interessanti del sistema. Lo scopo dell utente è di costruire un predicato composto da più clausole. Si è pensato di mostrare una anteprima di quest ultimo ad ogni modifica da parte dell utente. Ciò significa che ogni column behavior del DataGrid contiene delle istruzioni che aggiornano un field posizionato in basso costruendo l intero predicato. Un esempio di where è la figura 4.8. Dalla figura si intuisce che il DataGrid permette di inserire ogni minimo particolare per la creazione del predicato. L option button del column

88 CAPITOLO 4. IMPLEMENTAZIONE 76 Figura 4.8: Modulo della costruzione della where template della colonna Field contiene la lista dei campi di tutte le tabelle selezionate nella card QueryBuilderTablesFields. La colonna Operator è composta ugualmente da un option button che ha al suo interno i seguenti operatori: =, <, >, <=, >=, LIKE, IN, IS NULL, IS NOT NULL. Se viene selezionato uno tra gli ultimi due, il column behavior disattiva la colonna successiva Value, dato che in questo caso la clausola non ammette nessun valore. Il campo Value è il valore con cui è confrontato il campo della tabella e non ha nessun column template. Il campo AND/OR serve ovviamente a collegare due clausole (righe del DataGrid) separate da un AND o un OR. Le uniche due colonne con le checkbox definite del row template hanno lo scopo di inserire le parentesi tonde per isolare le clausole del predicato della where. Per fare si che ad ogni modifica delle celle del DataGrid da parte dell utente bisogna aggiornare il campo dell anteprima, sono stati definiti ed

89 CAPITOLO 4. IMPLEMENTAZIONE 77 intercettati nei column behavior i messaggi di: mouseup per quanto riguarda le colonne che contengono le checkbox, inviato quando l utente clicca su di essa. menupick per i campi Field, Operator e AND/OR che sono composti da un option button, attivato quando viene selezionato un elemento dalla lista. textchanged per il campo Value che viene inviato quando l utente scrive qualcosa nella textfield. Clausola order by Il secondo DataGrid è quello che riguarda la definizione di una order by all interno della query creata tramite il query builder. Il seguente DataGrid è molto più semplice del precedente perché è formato soltanto da due colonne con due column template, entrambi composti da un option button. Figura 4.9: Datagrid della order by L option button della prima colonna contiene la lista delle le colonne di tutte le tabelle selezionate per la query. La seconda colonna invece indica il criterio di ordinamento dove ASC sta per ascendente (dal più piccolo al più grande) e DESC sta per discendente (dal più grande al più piccolo) Preferenze PRAGMA Durante la progettazione del sistema si è reso necessario sviluppare una parte dedicata alla modifiche delle proprietà PRAGMA di SQLite. L obiettivo è di semplificare all utente la configurazione del database, impostando una sola volta le proprietà che vuole che restino sempre attive, e caricandole ogni volta che viene aperta una connessione al database.

90 CAPITOLO 4. IMPLEMENTAZIONE 78 Per raggiungere tale obiettivo è stata creata una card apposita con un DataGrid particolare e leggermente diverso dagli altri descritti fino ad ora. Esso infatti è dinamico, ovvero il suo contenuto ed i suoi column template dipendono dal contenuto delle righe. Esistono sostanzialmente due tipi generici di proprietà PRAGMA: 1. Il primo è una proprietà che ammette un numero limitato di valori. Ad esempio la proprietà PRAGMA foreign_keys ammette soltanto i valori ON, OFF, 1, 0, TRUE, FALSE. In questo caso, nella colonna del DataGrid corrispondente al valore, viene visualizzata un option button con gli elementi appena elencati. Ovviamente ogni proprietà avrà i suoi valori specifici. 2. Il secondo invece è una proprietà che ammette una moltitudine di valori, solitamente numeri. In questo caso l option button viene nascosto ed al suo posto viene visualizzata un field che l utente può modificare a suo piacimento. Per semplificare il popolamento dinamico del DataGrid è stato creato un file contenente la lista di tutte le proprietà PRAGMA. Per ognuna viene elencata la lista dei valori accettati. All interno del column behavior, nella funzione che si occupa di piazzare il valore nella cella, si controlla se esiste la lista dei valori accettati: in caso positivo viene popolato l option button di quella particolare riga 14, altrimenti si rende invisibile il bottone. La figura 4.10 mostra la struttura del file delle proprietà PRAGMA. Ogni riga corrisponde ad una proprietà. Alla sinistra della virgola c è il nome della proprietà, alla destra invece i valori accettati. Come si può notare, in alcune righe a destra della virgola non c è nessun valore. In questo caso significa che l utente non deve inserire un numero ristretto di valori, ma ha un ampia scelta. Una volta modificati i valori delle proprietà PRAGMA, l utente deve cliccare sul pulsante Save. Quando clicca su di esso vengono eseguite le 14 Negli altri DataGrid ogni riga aveva gli stessi oggetti con lo stesso contenuto

91 CAPITOLO 4. IMPLEMENTAZIONE 79 Figura 4.10: File delle definizioni delle proprietà PRAGMA Figura 4.11: Finestra della modifica delle proprietà PRAGMA

92 CAPITOLO 4. IMPLEMENTAZIONE 80 istruzioni SQL per confermare le modifiche, e salvati i valori per ogni proprietà all interno del file XML delle preferenze illustrato nel capitolo della progettazione del presente documento Visualizzazione dei dati BLOB Il DBMS SQLite supporta anche i dati di tipo BLOB, per questo motivo l applicazione sviluppata deve discriminare questi casi particolari. Non ha senso mostrare il contenuto binario di una cella di tipo BLOB quando si effettua una query. In fase di progettazione è stato deciso di visualizzare un pulsante che, una volta cliccato, apre una finestra che mostra il contenuto del BLOB in vari formati: testo, binario, esadecimale ed immagine 15. Dato che la presenza di BLOB tra le righe del risultato di una query dipende proprio dalla query effettuata, bisognava trovare un modo per creare dinamicamente un column template per il pulsante specifico descritto prima. La soluzione a questo problema è la seguente: è stato creato un DataGrid in una card nascosta con un solo campo, il cui column template è composto da un pulsante. Il column behavior intercetta il messaggio mouseup che viene inviato quando l utente clicca sul pulsante. All interno del messaggio si preleva il contenuto della cella, si apre lo stack dedicato ai BLOB, e viene mostrato all utente il dato in formato immagine, testo, binario ed esadecimale. Nel momento in cui l utente effettua una query, si identificano i campi selezionati di tipo BLOB, e per ognuno viene utilizzato il column template del DataGrid posizionato nella card nascosta tramite il settaggio di una proprietà del DataGrid che mostra il risultato della query. Questa proprietà è la dgcolumntemplate[columnname]. A questo punto per ogni riga, le celle 15 Ovviamente viene visualizzata una immagine soltanto quando il dato ne rappresenta realmente una. Nel caso in cui il BLOB non è un immagine allora viene visualizzato un riquadro vuoto

93 CAPITOLO 4. IMPLEMENTAZIONE 81 corrispondenti ad un campo di tipo BLOB contengono il pulsante appena descritto. Figura 4.12: Esempio di query contenente colonne di tipo BLOB L esempio nella figura 4.12 rappresenta il risultato di una query, il cui campo fotografia contiene dei dati binari. Per questo motivo viene mostrato il pulsante per visualizzare la foto associata alla cella.

94 Capitolo 5 Testing del sistema 5.1 Verifica e validazione Un passaggio molto importante prima del rilascio di un software è la verifica e la validazione dello stesso. L obiettivo della validazione è di capire se il sistema rispetta le specifiche, quindi deve soddisfare i requisiti funzionali e non funzionali. La verifica del software invece, serve a controllare se il sistema funziona correttamente e non presenta errori.[5] La verifica e la validazione del software seppur essendo diverse, sono strettamente collegate, infatti non ha senso sviluppare un applicazione perfettamente funzionante ma che non rispetta affatto i requisiti definiti con il committente. La verifica del sistema si concretizza in più fasi e modalità. Essa si divide in due categorie, la verifica statica e quella dinamica. Alcune tecniche della verifica statica sono le review e l ispezione. Entrambe vengono effettuate sulla forma, struttura e contenuto del sistema, senza eseguire in nessun caso il codice. La verifica dinamica si basa proprio sullo studio del comportamento del software in varie situazioni di stress causate dallo sviluppatore. Le più importanti tecniche di questo tipo di verifica sono il testing ed il debugging. Il testing è sicuramente la tecnica più interessante per verificare un software. Esso può essere effettuato a vari livelli: Unit testing: è il testing dell unità, vengono verificate le parti più 82

95 CAPITOLO 5. TESTING DEL SISTEMA 83 piccole del sistema (funzioni e procedure). Integration testing: ha l obiettivo di testare varie unità messe insieme. Functional testing: verifica se il sistema rispetta i requisiti funzionali. System testing: si occupa di controllare se il software rispetta i requisiti non funzionali. 5.2 Testing La maggior parte dei linguaggi di programmazione offrono dei framework di base per permettere di effettuare lo unit testing sui software sviluppati. Java ad esempio fornisce JUnit, una libreria che mette a disposizione una serie di API per effettuare il testing di unità e di integrazione. Purtroppo Livecode non fornisce alcun modo per effettuare unit testing ed integration testing. L unico modo per raggiungere questo obiettivo è di creare un applicativo apposito che stressa il sistema da testare per verificare che funziona correttamente. L attività di tirocinio svolta da me non prevedeva il testing del sistema sviluppato dato che l obiettivo principale era l analisi, la progettazione e l implementazione dell intero software. Al termine dell implementazione dovrà essere effettuata la verifica del sistema e si è deciso di usare la strategia black box. La filosofia di questa strategia è di trattare l elemento da testare come una scatola nera, senza sapere come è costituito all interno, ma soltanto conoscendo la sua funzione e l output atteso. Innanzitutto dovrebbe essere creato, come già detto uno stack apposito con una serie di funzioni predefinite che azionano e stressano gli elementi dell interfaccia grafica allo scopo di verificare che effettuino le operazioni in modo corretto e senza errori. Ovviamente per fare ciò bisogna creare il test stub che si occupa di simulare l ambiente esterno da cui dipende l unità da testare, ed il test driver che inizializza le varie strutture ed avvia il vero e proprio testing.

96 CAPITOLO 5. TESTING DEL SISTEMA 84 Per utilizzare lo stack appena descritto, bisogna sviluppare un test plan per il sistema. Quando verrà effettuato il testing vero e proprio, bisognerà controllare la differenza tra il risultato atteso ed il risultato ottenuto, per mostrare se la verifica del sistema è andata a buon fine. Di seguito vengono illustrati alcuni test cases. Test ID 1 Test Name Importazione database Test Description Testing di verifica della corretta importazione dei databases Input Risultato desiderato Risultato ottenuto L utente trascina un database SQLite nel programma L applicazione accetta il file ed inserisce una nuova riga nella vista ad albero sulla sinistra L utente trascina un file che L applicazione mostra un non è un database SQLite messaggio di errore nel programma L utente clicca sul pulsante Open database e sceglie un database SQLite L applicazione accetta il file ed inserisce una nuova riga nella vista ad albero sulla sinistra L utente clicca sul pulsante L applicazione mostra un Open database e sce- messaggio di errore glie un file che non è un database SQLite Test ID 2 Test Name Proprietà PRAGMA Test Description Testing di verifica della corretta modifica delle proprietà PRAGMA

97 CAPITOLO 5. TESTING DEL SISTEMA 85 Input Risultato desiderato Risultato ottenuto L utente apre la card delle proprietà PRAGMA, imposta PRAGMA foreign_key = ON e clicca sul pulsante Il database fisico deve avere la proprietà PRAGMA foreign_key impostata al valore ON Save L utente apre la card delle proprietà PRAGMA, imposta Il file delle preferenze XML deve contenere la lista di PRAGMA foreign_key tutte le proprietà prag- = ON e clicca sul pulsante Save ma compresa la PRAGMA foreign_key impostata al valore ON L utente apre la card delle proprietà PRAGMA, imposta PRAGMA foreign_key Il database deve avere la proprietà PRAGMA foreign_key impostata ad ON = ON e clicca sul pulsante Save, chiude e riapre l applicazione Test ID 3 Test Name Salvataggio query Test Description Testing di verifica per il controllo del salvataggio delle query Input Risultato desiderato Risultato ottenuto L utente crea la query select Il file delle preferenze XML * from sqlite_master e deve avere un elemento clicca sul pulsante Save query il cui elemento figlio sql è uguale a select * from sqlite_master

98 CAPITOLO 5. TESTING DEL SISTEMA 86 L utente ha salvato la query select * from sqlite_master con il nome di prova. Clicca su Existing query e seleziona prova In precedenza è stato salvata una query con il nome prova. L utente salva una query e gli assegna nuovamente il nome prova Il sistema dovrà posizionarsi sulla card dedicata alle query ed il field sql dovrà contenere il testo select * from sqlite_master Il sistema mostra un messaggio di errore e non salva la query Test ID 4 Test Name Backup database Test Description Testing di verifica del backup di un database Input Risultato desiderato Risultato ottenuto L utente seleziona un database, clicca sul pulsante Backup, inserisce prova come commento e preme su Backup database Deve esistere un file nella cartella backups uguale al file del database selezionato. Il file XML deve contenere un elemento backup come figlio dell elemento backuplist con la data odierna, il commento prova ed il nome del file corrispondente al file appena creato. Test ID 5 Test Name Restore database Test Description Testing di verifica del restore di un database

99 CAPITOLO 5. TESTING DEL SISTEMA 87 Input Risultato desiderato Risultato ottenuto L utente ha effettuato un backup del database che ha Deve essere caricata la versione precedente ed il database la tabella persona. Successivamente deve contenere la elimina la tabella tabella chiamata persona. persona. Clicca su Re- store e recupera la versione appena salvata L utente ha effettuato un backup del database che ha Deve essere caricata la versione precedente ed il database la tabella persona vuota. deve contenere la ta- Successivamente inserisce bella persona completasante 10 righe. Clicca sul pulmente vuota Restore e recupera la versione appena salvata Test ID 6 Test Name Modifica delle righe di una tabella Test Description Testing sull inserimento, modifica e cancellazione di righe dalle tabelle Input Risultato desiderato Risultato ottenuto L utente apre la tabella Nella tabella persona del persona. Inserisce la riga database deve essere pre- (francesco, cervone, 22) sente la riga (francesco, e clicca sul pulsante di cervone, 22). salvataggio

100 CAPITOLO 5. TESTING DEL SISTEMA 88 Nella tabella persona è presente la riga (francesco, cervone, 22). L utente fa doppio click sulla cella del valore 22, inserisce il valore 23 e clicca sul pulsante di salvataggio. Nella tabella persona è presente la riga (francesco, cervone, 22). L utente clicca sulla riga e poi sul pulsante di eliminazione. Nella tabella persona del database deve essere presente la riga (francesco, cervone, 23) Nella tabella persona del database non deve essere più presente la riga (francesco, cervone, 22)

101 Capitolo 6 Conclusioni 6.1 Considerazioni su Livecode Dopo aver progettato e scritto questa applicazione in Livecode vanno fatte alcune considerazioni sul linguaggio. Come introdotto all inizio del presente documento, esso ha dei vantaggi e degli svantaggi. La cosa che sicuramente prevale su tutte le caratteristiche è la velocità con cui si sviluppa un applicazione (non a caso è un linguaggio per il rapid application development). I motivi principali di questo privilegio sono tanti tra cui distinguiamo la sintassi semplice da capire ed estremamente concentrata, che permette di sintetizzare operazioni molto complesse in una sola riga di codice. Un altra caratteristica importante che velocizza lo sviluppo è la semplicità con cui si creano le interfacce grafiche: la struttura degli oggetti di Livecode è basata proprio su questo e la prima cosa che deve essere fatta è la creazione di tutti gli stack e le card del programma. Per creare l interfaccia non c è bisogno di scrivere codice, poiché bisogna semplicemente usare i comandi dell ambiente di sviluppo e trascinare gli oggetti (field, button,...) dalla barra laterale agli stack. La creazione di GUI in Livecode è molto vicina a quella delle applicazioni per Mac OS X sviluppate con Xcode. Anche in questo caso si creano indipendentemente le finestre con pulsanti ed oggetti vari senza scrivere codice tramite il tool dell IDE Interface Builder. L altro vantaggio evidente è il fatto che l applicazione viene compilata per 89

102 CAPITOLO 6. CONCLUSIONI 90 Windows, Mac e Linux e lo sviluppatore non deve modificare nessuna parte del codice per adattarla. L ultimo, ma non in ordine di importanza, è la possibilità di testare le parti dell applicazione senza compilare il progetto. Questa a mio parere è la caratteristica più importante perché abbatte tutti i tempi del debug del software in fase di sviluppo. Se viene ad esempio creato un pulsante che deve fare delle operazioni specifiche e si vuole testarlo, basta passare in run mode e cliccare su di esso. Negli altri casi lo sviluppatore avrebbe dovuto compilare l intera applicazione per provare il singolo pulsante. L unica cosa negativa riscontrata in seguito all esperienza fatta in Livecode è l impossibilità di estendere la struttura principale del linguaggio. Non è possibile creare strutture dati (a parte array associativi), e questo non permette allo sviluppatore di organizzare al meglio i dati del sistema, soprattutto di separare le funzionalità e le responsabilità degli oggetti. Inoltre le parti di codice sono associate direttamente agli oggetti della GUI. Esiste un unico modo per scrivere del codice indipendente ed autonomo e cioè di creare uno stack vuoto che contiene le funzioni di cui si ha bisogno. Questa non è di certo una soluzione elegante ma è l unica di cui si dispone. Per tutte queste motivazioni Livecode è un ottimo linguaggio di programmazione ed ambiente di sviluppo, preferibile in moltissimi casi a quasi tutti gli altri linguaggi. I casi per i quali, secondo la mia opinione, non bisogna sceglierlo è per lo sviluppo di applicazioni di medie o grandi dimensioni. Al crescere del software aumenta sempre di più la disorganizzazione del codice. Dato che gli oggetti della GUI diventano tanti, risulta molto difficile identificare il punto del codice in cui viene generato un errore. 6.2 Sviluppi futuri L azienda in cui ho svolto l attività di tirocinio ha deciso di voler ampliare il progetto a cui ho partecipato. I principali obiettivi sono l espansione del sistema al supporto ad altri DBMS come MySQL, Oracle ed SQL Server. L integrazione di questi tipi di database richiederebbe uno sforzo non ecces-

103 CAPITOLO 6. CONCLUSIONI 91 sivo in quanto Livecode supporta tutti ugualmente proprio come SQLite. Le modifiche andrebbero fatte all applicazione dove le operazioni erano adattate e limitate alle funzionalità di SQLite, come ad esempio: L interfaccia per la creazione di tabelle, la quale si basa sulla sintassi della create table di SQLite che non supporta tutte le funzionalità degli altri DBMS. La parte che si occupa di eseguire le alter table, che attualmente fa il parsing del codice sql di creazione della tabella per prelevare le informazioni sulle colonne ed i vincoli. Nel caso degli altri tipi di database non c è bisogno di fare questa operazione perché tutto ciò è contenuto in tabelle di sistema specifiche. La card per la creazione delle viste che prevede soltanto un nome ed una query. In altri casi sono previsti anche gli alias per le colonne. Il query builder attualmente permette solo di eseguire query con left join, join e prodotti cartesiani. L utente non può effettuare una query includendo una right join o full join dato che SQLite non supporta nessuno dei due. Il backup, attualmente copia il file fisico del database. MySQL, Oracle ed SQL Server questo non è possibile. Nel caso di In ultima istanza, la card delle preferenze PRAGMA. Queste ultime sono proprietà specifiche del DBMS SQLite e dovrebbero essere visualizzate solo quando si gestisce un database di questo tipo. A causa della creazione dell external in C per la gestione dei BLOB, il programma può essere eseguito soltanto su Mac OS X, dato che la libreria è stata compilata in Xcode. Un altro obiettivo è quindi di creare le librerie esterne per poter eseguire l applicazione negli ambienti Windows e Linux.

104 Appendice A Tabelle di cockburn Use Case Backup del database Goal in context L utente vuole effettuare un backup del database Scope & Level SuD, user goal Preconditions Deve essere selezionato un database dalla lista Success end conditions Viene creata una copia di backup Failed end conditions Errore durante la creazione del file, l utente annulla l operazione Primary Actors Utente Trigger L utente clicca sul pulsante Backup Description Step Actor System 1 Clicca sul pulsante Backup 2 Visualizza la finestra di backup 3 Inserisce un commento 4 Clicca sul pulsante Save 5 Crea una copia di backup del database selezionato Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra <Errore durante la 5b Mostra messaggio di errore di creazione> creazione del file all utente Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro e seleziona Backup Database Torna al passo 2 Use Case Goal in context Scope & Level Preconditions Success end conditions Failed end conditions Primary Actors Trigger Restore del database L utente vuole recuperare una vecchia versione del database SuD, user goal L utente deve aver selezionato un database ed effettuato almeno un backup L utente ripristina il backup Errore durante il recupero del file, l utente annulla l operazione Utente L utente clicca sul pulsante Restore 92

105 APPENDICE A. TABELLE DI COCKBURN 93 Description Step Actor System 1 Clicca sul pulsante Restore 2 Recupera i nomi e le date dei backup e le mostra nella finestra apposita 3 Seleziona un backup 4 Clicca sul pulsante Restore della nuova finestra 5 Aggiorna il database alla vecchia versione e chiude la finestra Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra di restore <Errore durante il recupero 5b Mostra messaggio di errore del file> all utente Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro e seleziona Restore Database Torna al passo 2 Use Case Creazione tabella Goal in context L utente vuole creare una nuova tabella Scope & Level SuD, user goal Preconditions Deve essere aperta una connessione al database Success end conditions Viene creata una nuova tabella Failed end conditions L utente non ha inserito tutti i campi obbligatori, l utente annulla la creazione Primary Actors Utente Trigger L utente clicca sul pulsante Create new table Description Step Actor System 1 Clicca sul pulsante Create new table 2 Mostra la vista di creazione tabella 3 Inserisce il nome della tabella 4 Esegue use case inserimento campo 5 Clicca sul pulsante Create table 6 Recupera le informazioni immesse dall utente e crea la tabella nel database. Chiude la finestra di creazione Extensions Step Actor System <Inserimento campo> 5a Esegue use case inserimento campo <Rimozione campo> 5b Esegue use case rimozione campo 6b Torna al passo 4 <Gestione chiavi esterne> 5c Clicca sul pannello Foreign keys 6c Mostra pannello di gestione 7c Esegue use case Inserimento chiave esterna o Rimozione chiave esterna delle chiavi esterne

106 APPENDICE A. TABELLE DI COCKBURN 94 <Gestione unique> 5d Clicca sul pannello Unique 6d Mostra pannello di gestione delle unique 7d Esegue use case Inserimento unique constraint oppure Rimozione unique constraint <Gestione check> 5e Clicca sul pannello Check 6e Mostra pannello di gestione delle check 7e Esegue use case Inserimento check constraint oppure Rimozione check constraint <Gestione primary 5f Clicca sul pannello Primary key> keys 6f Mostra pannello di gestione delle chiavi primarie 7f Esegue use case Inserimento primary keys <Annullamento operazione> *g Clicca sul pulsante Cancel Chiude la finestra di creazione della tabella <Nome non inserito> 3h Clicca sul pulsante Create table 4h Mostra messaggio di errore causa nome non inserito <Campo non inserito> 4i Clicca sul pulsante Create table 5h Mostra messaggio di errore causa campo non inserito Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro e seleziona Create table Torna al passo 2 Use Case Inserimento campo Goal in context L utente vuole inserire un campo in una tabella Scope & Level SuD, subfunction Preconditions Ci si deve trovare nella finestra di creazione o modifica di una tabella Success end conditions L utente inserisce il campo Failed end conditions L utente annulla l operazione Primary Actors Utente Trigger L utente clicca sul pulsante + Description Step Actor System 1 Clicca sul pulsante + 2 Aggiunge una riga alla tabella dei campi 3 Inserisce nome, tipo ed altre proprietà del campo Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra di creazione o modifica della tabella

107 APPENDICE A. TABELLE DI COCKBURN 95 Use Case Goal in context Scope & Level Preconditions Inserimento chiave esterna L utente vuole inserire una chiave esterna in una tabella SuD, subfunction Ci si deve trovare nella finestra di creazione o modifica di una tabella, nel pannello di gestione delle chiavi esterne L utente inserisce la chiave esterna Success end conditions Failed end conditions L utente annulla l operazione Primary Actors Utente Trigger L utente clicca sul pulsante + Description Step Actor System 1 Clicca sul pulsante + 2 Aggiunge una riga alla tabella delle chiavi esterne 3 Inserisce nome, campo, tabella referenziata, campo referenziato ed altre proprietà Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra di creazione o modifica della tabella Use Case Goal in context Scope & Level Preconditions Inserimento unique constraint L utente vuole inserire una vincolo unique in una tabella SuD, subfunction Ci si deve trovare nella finestra di creazione o modifica di una tabella, nel pannello di gestione delle unique constraints L utente inserisce il vincolo unique Success end conditions Failed end conditions L utente annulla l operazione Primary Actors Utente Trigger L utente clicca sul pulsante + Description Step Actor System 1 Clicca sul pulsante + 2 Aggiunge una riga alla tabella delle unique constraints 3 Seleziona i campi da rendere unique ed inserisce il nome del vincolo Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra di creazione o modifica della tabella Use Case Goal in context Scope & Level Preconditions Success end conditions Failed end conditions Inserimento check constraint L utente vuole inserire una vincolo check in una tabella SuD, subfunction Ci si deve trovare nella finestra di creazione o modifica di una tabella, nel pannello di gestione delle check constraints L utente inserisce il vincolo check L utente annulla l operazione

108 APPENDICE A. TABELLE DI COCKBURN 96 Primary Actors Utente Trigger L utente clicca sul pulsante + Description Step Actor System 1 Clicca sul pulsante + 2 Aggiunge una riga alla tabella delle check constraints 3 Inserisce il nome del vincolo e la condizione della check Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Cancel Chiude la finestra di creazione o modifica della tabella Use Case Rinomina tabella Goal in context L utente vuole rinominare una tabella Scope & Level SuD, user goal Preconditions Deve essere aperta una connessione al database Success end conditions L utente rinomina la tabella Failed end conditions L utente annulla l operazione Primary Actors Utente Trigger L utente seleziona una tabella Description Step Actor System 1 Seleziona una tabella 2 Clicca sul pulsante Rename table 3 Mostra form inserimento nome 4 Inserisce il nome della tabella 5 Clicca su Ok 6 Rinomina la tabella Extensions Step Actor System <Annullamento operazione> 5a Clicca su Cancel Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro del mouse sulla tabella 2a Mostra menu contestuale 3a Seleziona Rename table Torna al passo 3 Use Case Inserimento riga Goal in context L utente vuole inserire una riga in una tabella Scope & Level SuD, user goal Preconditions Deve essere aperta una connessione al database Success end conditions L utente ha inserito la riga correttamente Failed end conditions Errore nell inserimento della riga, l utente annulla l inserimento Primary Actors Utente Trigger L utente seleziona una tabella Description Step Actor System 1 Seleziona una tabella dalla vista 2 Clicca su Update table rows 3 Mostra finestra di gestione delle righe delle tabelle

109 APPENDICE A. TABELLE DI COCKBURN 97 4 Clicca sul pulsante + 5 Inserisce una riga vuota nella tabella 6 Inserisce i valori dei campi 7 Clicca sul pulsante di salvataggio 8 Preleva le informazioni fornite ed effettua l inserimento nella tabella Extensions Step Actor System <Errore inserimento> 8a Mostra errore database 9a Torna al passo 6 <Annullamento inserimento> 7b Clicca sul pulsante di annullamento inserimento 8b Rimuove la riga da inserire Subvariations Step Actor System <Salvataggio cambiando riga> 7a Seleziona una riga diversa da quella da inserire Torna al passo 8 <Tasto destro> 1b Preme il tasto destro su una tabella e sceglie Update table rows Torna al passo 3 <Double click> 1b Clicca due volte su una tabella Torna al passo 3 Use Case Esecuzione query Goal in context L utente vuole eseguire una query Scope & Level SuD, user goal Preconditions Deve essere aperta una connessione al database Success end conditions L utente visualizza il risultato della query Failed end conditions La query immessa è errata Primary Actors Utente Trigger L utente clicca su Execute query Description Step Actor System 1 Clicca su Execute query 2 Mostra finestra di composizione query 3 Scrive la query all interno del campo apposito 4 Clicca su Execute 5 Mostra il risultato della query Extensions Step Actor System <Query errata> 5a Mostra errore database Subvariations Step Actor System <Tasto destro> 1a Preme il tasto destro e sceglie Execute query Torna al passo 2 Use Case Goal in context Scope & Level Preconditions Success end conditions Creazione vista L utente vuole creare una vista SuD, user goal Deve essere aperta una connessione al database L utente crea la vista

110 APPENDICE A. TABELLE DI COCKBURN 98 Failed end conditions L utente immette una query errata Primary Actors Utente Trigger L utente clicca su Create view Description Step Actor System 1 Clicca sul pulsante Create view 2 Mostra finestra di creazione vista 3 Inserisce il nome della vista e la query 4 Clicca su Create 5 Recupera le informazioni immesse e crea la vista Extensions Step Actor System <Query errata> 5a Mostra errore database Subvariations Step Actor System <Query builder> 3a Esegue use case Query builder per comporre la query Torna al passo 4 Use Case Query builder Goal in context L utente vuole creare una query tramite il query builder Scope & Level SuD, user goal Preconditions Deve essere aperta una connessione al database Success end conditions L utente effettua la query Failed end conditions La query ha una sintassi errata Primary Actors Utente Trigger L utente clicca su Query builder Description Step Actor System 1 Clicca su Query builder 2 Mostra finestra relativa al query builder 3 Seleziona una tabella dalla lista 4 Clicca sul pulsante di aggiunta tabelle 5 Inserisce la tabella nell apposito spazio 6 Clicca su Execute 7 Preleva le informazioni immesse dall utente, esegue la query e mostra il risultato nell apposita finestra Extensions Step Actor System <Annullamento operazione> *a Clicca sul pulsante Home Chiude la finestra del query builder Subvariations Step Actor System <Selezione campi> 6a Seleziona alcuni campi di una tabella inserita Torna al passo 6 <Inserimento tabella> 6b Seleziona una tabella dalla lista 7b Clicca sul pulsante di aggiunta tabelle

111 APPENDICE A. TABELLE DI COCKBURN 99 <Where, group by, order by> 8b 6c Torna al passo 6 Esegue uno dei seguenti use cases: Aggiunta di una join, Aggiunta clausola where, Selezione aggregate function, Scelta di un criterio di ordinamento Torna al passo 6 Inserisce la tabella nell apposito spazio Use Case Aggiunta di una join Goal in context L utente vuole aggiungere una join alla query Scope & Level SuD, subfunction Preconditions L utente deve trovarsi nella finestra del query builder Success end conditions L utente aggiunge la join Failed end conditions L utente annulla l inserimento Primary Actors Utente Trigger L utente usa il drag & drop su un campo Description Step Actor System 1 Trascina tramite drag & drop un campo di una tabella verso un campo di un altra tabella 2 Apre la finestra di selezione join ed inserimento della condizione on 3 Seleziona un tipo di join 4 Inserisce la condizione on 5 Clicca su Ok 6 Aggiunge la join alla query e crea una linea tra le due tabelle Extensions Step Actor System <Annullamento inserimento> 5a Clicca sul pulsante Cancel 6a Chiude la finestra Use Case Aggiunta clausola where Goal in context L utente vuole aggiungere la clausola where Scope & Level SuD, subfunction Preconditions L utente deve trovarsi nella finestra del query builder Success end conditions L utente inserisce la clausola where Failed end conditions L utente esce dal query builder Primary Actors Utente Trigger L utente si sposta sul pannello Where Description Step Actor System 1 L utente clicca sul pannello Where 2 Mostra il pannello Where 3 Clicca sul pulsante + 4 Aggiunge una riga vuota alla tabella delle clausole where 5 Seleziona il campo, l operatore, il valore ed altre proprietà

112 APPENDICE A. TABELLE DI COCKBURN Torna al passo 3 oppure termina lo use case Extensions Step Actor System <Eliminazione clausola> 6a Seleziona una riga nella lista delle clausole 7a Clicca sul pulsante - 8a 9a Torna al passo 6 Elimina la clausola dalla tabella Use Case Selezione aggregate function Goal in context L utente vuole selezionare una aggregate function Scope & Level SuD, subfunction Preconditions L utente deve trovarsi nella finestra del query builder Success end conditions L utente seleziona una aggregate function Failed end conditions Primary Actors Utente Trigger L utente clicca su Aggregate function Description Step Actor System 1 Clicca sul pannello Aggregate function 2 Mostra pannello di scelta aggregate function 3 Seleziona un campo dalla lista 4 Seleziona un tipo di aggregate function (MIN, MAX, COUNT,...) 5 Seleziona un campo della clausola GROUP BY 6 Inserisce una condizione HA- VING Use Case Scelta di un criterio di ordinamento Goal in context L utente vuole scegliere un criterio di ordinamento per la query Scope & Level SuD, subfunction Preconditions L utente deve trovarsi nella finestra del query builder Success end conditions L utente aggiunge un criterio di ordinamento Failed end conditions Primary Actors Utente Trigger L utente si sposta sul pannello Order by Description Step Actor System 1 Clicca sul pannello Order by 2 Mostra il pannello per la gestione dei criteri di ordinamento 3 Clicca sul pulsante + 4 Inserisce una riga vuota nella tabella apposita 5 Seleziona un campo ed un criterio (ASC/DESC) 6 Torna al passo 3 oppure termina lo use case Extensions Step Actor System

113 APPENDICE A. TABELLE DI COCKBURN 101 <Cancellazione di una riga> 6a Seleziona una riga della tabella 7a Clicca sul pulsante - 8a 9a Torna al passo 6 Rimuove la riga dalla tabella

114 Appendice B Diagrammi di sequenza di analisi Figura B.1: Sequence diagram - Backup database 102

115 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 103 Figura B.2: Sequence diagram - Restore database

116 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 104 Figura B.3: Sequence diagram - Creazione tabella (fields)

117 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 105 Figura B.4: Sequence diagram - Creazione tabella (foreign keys) Figura B.5: Sequence diagram - Creazione tabella (unique)

118 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 106 Figura B.6: Sequence diagram - Creazione tabella (check) Figura B.7: Sequence diagram - Inserimento campo

119 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 107 Figura B.8: Sequence diagram - Inserimento chiave esterna Figura B.9: Sequence diagram - Inserimento check constraint

120 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 108 Figura B.10: Sequence diagram - Inserimento unique constraint

121 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 109 Figura B.11: Sequence diagram - Creazione vista

122 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 110 Figura B.12: Sequence diagram - Inserimento riga Figura B.13: Sequence diagram - Rimozione riga

123 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 111 Figura B.14: Sequence diagram - Modifica riga

124 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 112 Figura B.15: Sequence diagram - SQL query Figura B.16: Sequence diagram - SQL update

125 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 113 Figura B.17: Sequence diagram - Query builder

126 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 114 Figura B.18: Sequence diagram - Query builder (join)

127 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 115 Figura B.19: Sequence diagram - Query builder (where) Figura B.20: Sequence diagram - Query builder (inserimento clausola where)

128 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 116 Figura B.21: Sequence diagram - Query builder (aggregate function)

129 APPENDICE B. DIAGRAMMI DI SEQUENZA DI ANALISI 117 Figura B.22: Sequence diagram - Query builder (order by) Figura B.23: Sequence diagram - Query builder (esecuzione)

130 Appendice C Diagrammi di sequenza di design Figura C.1: Sequence diagram - Cancellazione di una vista 118

131 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 119 Figura C.2: Sequence diagram - Creazione di una tabella

132 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 120 Figura C.3: Sequence diagram - Inserimento di un campo Figura C.4: Sequence diagram - Inserimento chiavi primarie

133 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 121 Figura C.5: Sequence diagram - Inserimento chiavi esterne

134 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 122 Figura C.6: Sequence diagram - Inserimento unique

135 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 123 Figura C.7: Sequence diagram - Inserimento check Figura C.8: Sequence diagram - Salvataggio query

136 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 124 Figura C.9: Sequence diagram - Query builder

137 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 125 Figura C.10: Sequence diagram - Inserimento tabella Figura C.11: Sequence diagram - Inserimento where

138 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 126 Figura C.12: Sequence diagram - Inserimento join

139 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 127 Figura C.13: Sequence diagram - Inserimento aggregate function Figura C.14: Sequence diagram - Inserimento order by

140 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 128 Figura C.15: Sequence diagram - Salvataggio query builder

141 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 129 Figura C.16: Sequence diagram - Apertura query esistente

142 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 130 Figura C.17: Sequence diagram - Apertura query builder esistente

143 APPENDICE C. DIAGRAMMI DI SEQUENZA DI DESIGN 131 Figura C.18: Sequence diagram - Modifica preferenze PRAGMA Figura C.19: Sequence diagram - Visualizzazione BLOB