MIGLIORAMENTI NELLA GESTIONE DELLE ATTIVITÀ DI …

UNIVERSITÀ DEGLI STUDI DI PADOVA

FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALICorso di Laurea Triennale in Informatica

MIGLIORAMENTI NELLA GESTIONEDELLE ATTIVITÀ DI VISIONSQL

E LORO SINCRONIZZAZIONE CON I CALENDARI DI OUTLOOK

Tesi di Laurea in Informatica

Relatore: Presentata da:

Prof. Baldan Paolo Gallo Gian Marco

Anno accademico 2009/2010

Miglioramenti nella gestione delle attività di VisionSQL e loro sincronizzazione con i calendari di Outlook Gian Marco Gallo

1/111


2/111

Indice

Premesse al progetto di stage! 9

1.1 Scopo del progetto di stage! 9

1.2 VisionSQL! 10

1.3 Le attività! 10

1.4 Strumenti utilizzati per lo sviluppo del primo modulo! 11

1.4.1 Visual FoxPro! 11

1.4.2 FoxPro! 11

1.4.3 MS Sql management studio! 11

1.4.4 UML! 12

1.5 Strumenti utilizzati per lo sviluppo del secondo modulo! 12

1.5.1 OmniGraffle Professional! 12

1.5.2 C++! 12

1.5.3 Qt SDK! 12

1.5.4 UML! 13

Descrizione del prodotto realizzato ! 14

2.1 Descrizione generale! 14

2.2 Diagrammi Use-case! 16

2.2.1 Use-case A primo modulo: Generale! 16

2.2.2 Use-case B primo modulo: Impostazione scala temporale! 19

2.2.3 Use-case C primo modulo: Impostazione dettagli grafico! 20

2.2.4 Use-case D primo modulo: Esportazione grafico! 21

2.2.5 Use-case A secondo modulo: Generale! 23

2.3 Diagrammi delle attività! 25

2.3.1 Diagramma attività primo modulo: Generale! 25

2.3.2 Diagramma attività primo modulo: Visualizzazione grafico! 26

2.3.3 Diagramma attività primo modulo: Pubblicazione attività! 27


3/111

2.3.4 Diagramma attività secondo modulo: Generale! 28

2.3.5 Diagramma attività secondo modulo: Sincronizzazione! 29

2.4 Descrizione generale dei componenti! 30

2.4.1 Primo modulo: GestoreGrafici/Calendari! 30

2.4.2 Primo modulo: GestoreCalendari! 32

2.4.3 Primo modulo: GestoreGrafici! 33

2.4.4 Secondo modulo: Setup! 35

2.4.5 Secondo modulo: WinSetup! 36

2.4.6 Secondo modulo: SLFile! 37

2.4.7 Secondo modulo: BaseThread! 39

Tipo, obiettivo e funzione del componente! 39

2.4.8 Secondo modulo: OutlookManager! 41

2.4.9 Secondo modulo: Appointment! 42

2.4.10 Secondo modulo: DatabaseManager! 44

2.4.11 Secondo modulo: Activity! 45

2.5 Diagramma di comunicazione primo modulo! 46

2.6 Diagramma di comunicazione secondo modulo! 48

Scelte progettuali ed organizzative! 50

3.1 Patterns applicati! 50

3.1.1 Mediator pattern! 50

3.1.2 Façade pattern! 51

3.2 Standard di progetto! 51

3.2.1 Standard di progettazione architetturale! 51

3.2.2 Standard di documentazione del codice! 52

3.3 Visione generale delle strategie di verifica! 53

3.3.1 Risorse utilizzate! 53

3.3.2 Tecniche di verifica! 53


4/111

3.4 Gestione amministrativa delle risorse! 53

3.4.1 Pianificazione strategica e temporale e risultati! 54

Consuntivo delle attività ! 56

Valutazioni retrospettive ! 59

Bibliografia! 61

Appendice A! 62

Lista dei requisiti primo modulo ! 62

A.1 Requisiti funzionali! 62

A.1.1 Obbligatori! 62

A.2 Requisiti di qualità! 63


A.2.2 Desiderabili! 63

A.3 Requisiti di interfacciamento! 63


Lista dei requisiti secondo modulo! 64

A.4 Requisiti funzionali! 64


A.5 Requisiti di qualità! 65


A.5.2 Desiderabili! 65

A.6 Requisiti di interfacciamento! 65


Appendice B! 66

Specifica delle componenti primo modulo ! 66

B.1 Gestore Grafici/Calendari! 66

B.1.1 Descrizione della componente! 66

B.1.2 Campi dati! 67


5/111

B.1.3 Metodi! 68

B.2 GestoreCalendari! 69



B.2.3 Metodi! 70

B.3 GestoreGrafici! 71



B.3.3 Metodi! 73

Specifica delle componenti secondo modulo ! 74

B.4 Setup! 74



B.4.3 Metodi! 76

B.5 WinSetup! 77



B.5.3 Metodi! 79

B.6 SLFile! 81



B.6.3 Metodi! 82

B.7 BaseThread! 83



B.7.3 Metodi! 85

B.8 OutlookManager! 86


6/111



B.8.3 Metodi! 87

B.9 Appointment! 88



B.9.3 Metodi! 89

B.10 DatabaseManager! 91



B.10.3 Metodi! 92

B.11 Activity! 93



B.11.3 Metodi! 95

Appendice C! 96

Tracciamento della relazione componenti-requisiti! 96

Appendice D! 97

Resoconto delle attività di verifica ! 97

D.1 Tracciamento componenti-requisiti (Qualifica)! 97

D.1.1 Requisiti -> componenti! 97

D.1.2 Componenti->requisiti! 101

D.2 Dettaglio delle verifiche tramite analisi! 101

D.3 Dettaglio delle verifiche tramite prove (test)! 102

D.4 Dettaglio dellʼesito delle revisioni! 102

Appendice E! 105

Pianificazione ed esecuzione del collaudo ! 105


7/111

E.1 Specifica della campagna di validazione (collaudo incluso)! 105

E.1.1 Requisito -> Modalità! 105

E.1.2 Modalità -> Requisiti! 107

E.2 Dettaglio dellʼesito della campagna di validazione! 108

Appendice F! 109

Glossario ! 109


8/111

Capitolo 1

Premesse al progetto di stage

Al momento del primo incontro in azienda, il Dott. Turra, responsabile stage di “Vision Software House”, ha illustrato in linee generali i prodotti della ditta, le loro mancanze, il contesto nel quale si sarebbe inserito lo stage e le aspettative dell’azienda al termine dei lavori. Innanzitutto l’azienda sviluppa due software di tipo gestionale, “VisionERP” e “VisionSQL”: il secondo è l’evoluzione del primo non solo dal punto di vista dell’interfaccia grafica ma anche della velocità nell’utilizzo e nella consistenza dei dati trattati. In pratica “VisionSQL” (che verrà illustrato in dettaglio successivamente) ha le stesse funzionalità di “VisionERP” ma si basa su un database più nuovo, veloce e capace di contenere più dati, presenta nuove funzionalità e risolve molti bugs del predecessore. Tuttavia l’implementazione delle vecchie funzionalità nel nuovo programma non è ancora stata completata, anzi lo stato dei lavori è ancora parecchio indietro. In aggiunta, se l’implementazione è indietro, lo sviluppo di nuove funzionalità è ancora ai primordi. Di conseguenza la ditta ha deciso di affidare parte di questo lavoro ai vari stagisti per recuperare tempo prezioso e per concentrarsi contemporaneamente sullo sviluppo di più prodotti. Quindi lo stage presentatomi aveva due obbiettivi: l’implementazione in “VisionSQL” della funzionalità che consente di visualizzare le attività in un grafico temporale e lo sviluppo, sempre in “VisionSQL”, di una funzionalità che consente di collegare il software aziendale con i calendari di Microsoft Outlook.Per quanto riguarda la prima parte dello stage è stato allora pensato di sviluppare un modulo per soddisfare la richiesta dell’azienda, mentre per il secondo punto è stato innanzitutto pensato di cercare una soluzione già sviluppata da un’altra azienda e decidere se adottarla/comprarla o meno. L’esito della ricerca ha però, dopo due giorni di insuccessi, fatto cambiare i progetti dal momento che tutte le soluzioni trovate avrebbero comportato o spese eccessive per l’azienda o modifiche non gradite alle strutture del database utilizzato da “VisionSQL”. Di conseguenza è stato sviluppato ex novo un modulo per soddisfare la richiesta dell’azienda.

1.1 Scopo del progetto di stage

Il progetto consiste nella creazione di due moduli da integrare con il software aziendale “VisionSQL”. Il primo modulo può essere diviso concettualmente in due parti: la prima parte deve essere in grado di rappresentare graficamente le attività visualizzandole con un modello molto simile al diagramma di Gantt; la seconda parte deve essere in grado di pubblicare le attività di “VisionSQL” in un calendario di appuntamenti di


9/111

Microsoft Outlook prescelto dall’utente. Dopo averle pubblicate, il modulo deve essere anche in grado di modificarle, aggiornarle ed eliminarle.Il secondo modulo, che verrà denominato “VisionSync”, crasi di Vision e synchronizer, consente di effettuare il processo inverso, cioè di aggiornare eventuali modifiche degli appuntamenti di Outlook nelle attività di “VisionSQL”. Esso quindi lavora in background senza disturbare l’utente e ogni tot minuti richiede ad Outlook gli appuntamenti, richiede al database di “VisionSQL” le attività, verifica se deve essere fatta una sincronizzazione appuntamenti/attività e, in caso di esito positivo, la effettua.Il primo modulo sarà una componente interna del software aziendale, il secondo sarà un software esterno ed indipendente.

1.2 VisionSQL “VisionSQL” è un software gestionale creato da “Vision Software House” che consente di semplificare, informatizzare e velocizzare il controllo delle procedure aziendali. In esso sono inclusi componenti per la gestione della logistica, del magazzino, della produzione, della distribuzione, della forza vendite, delle relazioni con i clienti e i fornitori, dei cespiti, delle attività da svolgere, dei bilanci, dei rapporti finanziari...Esso è il successore di un altro software aziendale più antico, “VisionERP”, ma, pur offrendo le stesse caratteristiche, si basa su un database più potente e veloce e su miglioramenti e novità di non poco conto. Tuttavia il processo di migrazione di tutte le funzionalità da “VisionERP” a “VisionSQL” non è ancora terminato e, proprio per questo motivo, era completamente mancante la parte riguardante i miglioramenti della gestione delle attività e la loro esportazione.

1.3 Le attività

Contestualmente ad uno scenario di sviluppo di software gestionali, le attività possono essere descritte come particolari lavori a cui vengono associati persone e cose che interagiscono con l’ente utilizzatore del software. Ad esempio: in una realtà aziendale, il dato giorno la data macchina aziendale dovrà subire il dato intervento manutentivo, oppure il dato giorno il dato dipendente dovrà recarsi presso il dato cliente e così via...Queste attività possono quindi essere associate a dipendenti, a fornitori, ad acquirenti, a risorse materiali...e ne caratterizzano il calendario. Ovviamente esse possono essere create, eliminate, aggiornate e modificate in base alle esigenze dell’utente.

Ogni attività verrà presumibilmente salvata in una apposita tabella del database e sarà caratterizzata da campi dati che spiegheranno in dettaglio cosa deve essere fatto e da chi, come per esempio l’id dell’attività, il codice di


10/111

chi deve svolgere l’attività, la data e l’ora di inizio dell’attività, la data e l’ora di fine dell’ attività, un indicatore dell’importanza dell’attività, lo stato dell’evasione dell’attività o il codice di chi ha gestito l’attività.

1.4 Strumenti utilizzati per lo sviluppo del primo modulo

1.4.1 Visual FoxPro

! Per la realizzazione del primo modulo del prodotto oggetto dello stage è stato utilizzato Microsoft Visual FoxPro, un IDE (Integrated Development Environment, ambiente di sviluppo) in grado di operare con il linguaggio e con il tipo di database scelto dall’azienda per sviluppare “VisionSQL”. Il suo impiego inoltre fornisce diversi vantaggi:

• comporta un’immediata integrazione con il software aziendale;

• possiede un sistema di autocompletamento che rende molto più rapida la codifica;

• possiede un’efficace debugger, il che facilita la scrittura veloce e corretta del codice;

1.4.2 FoxPro FoxPro è stato scelto per la programmazione del primo modulo oggetto di stage per i seguenti motivi:

• comporta un’immediata integrazione con il software aziendale;

• è orientato agli oggetti, quindi possiede tutte le caratteristiche di progettabilità e riutilizzabilità del codice tipiche dei linguaggi di questo tipo;

• fornisce procedure e metodi di gestione di database relazionali;

• è case insensitive: questo lo rende facile e molto più veloce da scrivere.

1.4.3 MS Sql management studio

MS Sql Management studio è stato utilizzato per modificare le tabelle del database MS Sql utilizzato da “VisionSQL”. Esso è stato scelto perchè è lo strumento più adatto, veloce e potente per gestire i database di Microsoft.


11/111

1.4.4 UML

! Unified Modeling Language, linguaggio utilizzato per formalizzare l’analisi e la progettazione del modulo. L’UML offre una serie di formalismi grafici, come ad esempio i diagrammi use-case utili a rappresentare in modo visuale i dati ottenuti dalle fasi di sviluppo software, consentendo un accesso veloce a tali informazioni e una rapida comprensione dei meccanismi che le regolano. In particolare, una volta definita la progettazione, le classi sono state inserite in Visual Studio, che utilizza un formalismo analogo, in questo modo è stato possibile generare automaticamente parte del codice sorgente.

1.5 Strumenti utilizzati per lo sviluppo del secondo modulo

1.5.1 OmniGraffle Professional

OmniGraffle Professional è stato utilizzato per la progettazione del secondo modulo del prodotto oggetto dello stage. Esso offre un ambiente di disegno e progettazione delle classi molto intuitivo, di facile comprensione e di veloce utilizzo.

1.5.2 C++ C++ è stato scelto per la programmazione del secondo modulo del prodotto oggetto dello stage per i seguenti motivi:

• è orientato agli oggetti, quindi possiede tutte le caratteristiche di progettabilità e riutilizzabilità del codice tipiche dei linguaggi di questo tipo;

• risponde all’unico requisito imposto da “Vision Software House”, cioè l’utilizzo di un linguaggio di programmazione che fosse utilizzabile in Visual Studio, dal momento che l’azienda era partner di Microsoft.

1.5.3 Qt SDK

Per sopperire alle mancanze del linguaggio di programmazione sopra citato è stato deciso l’utilizzo della libreria multipiattaforma Qt. Essa infatti fornisce le seguenti componenti aggiuntive:

- possibilità di creare e gestire una interfaccia grafica;- possibilità di interfacciarsi con i prodotti del pacchetto Microsoft Office;- possibilità di creare, gestire ed eliminare i thread;- possibilità di creare, lanciare e terminare processi;- possibilità di interfacciarsi con un qualsiasi database.


12/111

1.5.4 UML

! Unified Modeling Language, linguaggio utilizzato per formalizzare l’analisi e la progettazione del modulo. L’UML offre una serie di formalismi grafici, come ad esempio i diagrammi use-case utili a rappresentare in modo visuale i dati ottenuti dalle fasi di sviluppo software, consentendo un accesso veloce a tali informazioni e una rapida comprensione dei meccanismi che le regolano.


13/111

Capitolo 2

Descrizione del prodotto realizzato Il diagramma sopra riportato rappresenta un primo livello di decomposizione architetturale e indica, anche se in maniera molto generica, l’approccio allo sviluppo dei due moduli. Il prodotto finale, diviso come detto in due moduli distinti, utilizza delle componenti preesistenti di “VisionSQL” e delle funzionalità di Outlook in modo tale da non dover creare da zero tutto il codice e in modo da renderlo integrabile facilmente con il resto del software aziendale. In particolar modo, esso utilizza due soli metodi di “Database manager” per poter salvare e caricare i dati nel/dal database; essi infatti sono gli unici due pubblici messi a disposizione dalla classe cosicchè chiunque debba utilizzare il database è costretto ad utilizzare sempre e solo questi due metodi. In questo modo le funzionalità per il salvataggio ed il caricamento sono semplici da capire e da utilizzare ed i dati contenuti nel database non rischiano di essere inconsistenti a causa di errori di programmazione. Il prodotto utilizza anche le API messe a disposizione dal team di sviluppo di Microsoft, in particolar modo quelle inserite in “Outlook manager”. Esse infatti consentono di ottenere i dati in esso contenuti, di modificarli, di aggiungerne di nuovi chiamando ed utilizzando dei semplici metodi. Tramite l’utilizzo di queste due componenti, quindi, è stato possibile passare i dati dal database a “VisionSQL”, da “VisionSQL” ad Outlook e viceversa senza dover complicare troppo il codice e rendendo l’intero progetto il più facilmente integrabile con il resto del software.

2.1 Descrizione generale

Contesto d’uso del prodotto: per quanto concerne il primo modulo, esso dovrà essere inserito nel programma aziendale “VisionSQL”, il quale si occuperà, al suo avvio, della creazione delle strutture dati, del caricamento delle configurazioni, dell’inserimento corretto dell’input e infine della gestione dell’output prodotto dal modulo. Per quanto invece concerne il secondo modulo, esso dovrà essere installato ed eseguito come programma indipendente da “VisionSQL”. Proprio per questo motivo ad esso competerà la creazione di tutte le strutture dati, il caricamento delle impostazioni scelte dall’utente, la richiesta dei dati al database e ad Outlook e la gestione della sincronizzazione.

Funzioni del prodotto: il prodotto dovrà aggiungere nuove funzionalità al software aziendale, funzionalità soprattutto riguardanti le attività e


14/111

la loro organizzazione. Ciò che si andrà a realizzare avrà quindi due utilizzi:

visualizzazione grafica delle attività: con cui si dà la possibilità all’utente di visualizzare le attività in una scala temporale, dando una chiara rappresentazione di eventuali lavori da svolgere in

parallelo e dello stato di evasione di esse.

esportazione/importazione calendari: con cui si dà la possibilità all’utente di esportare/modificare/aggiornare/eliminare le attività sotto forma di calendari di appuntamenti di MS Outlook e di aggiornare eventuali modifiche degli appuntamenti di Outlook nelle attività di “VisonSQL”.

Caratteristiche degli utenti: entrambi i moduli del progetto verranno utilizzati direttamente dall’utente. Esso sarà un qualsiasi utente finale del prodotto aziendale e non sono richieste particolare nozioni di informatica se non quelle di base. Ovviamente però l’utente dovrà conoscere la materia oggetto del software in modo da saper utilizzare al meglio le funzionalità introdotte dai due nuovi moduli.

Vincoli generali: il primo modulo è vincolato al funzionamento del software aziendale e quindi deve essere possibile una facile integrazione. Il secondo modulo, pur essendo il suo funzionamento indipendente, è vincolato all’esistenza del database di “VisionSQL” e alla presenza di MS Outlook.


15/111

Assunzioni e dipendenze: entrambi i moduli devono fornire un’interfaccia tramite la quale l’utente possa interagire con i moduli. Nel caso del primo modulo essa sarà una interfaccia da integrare con quella già esistente del software aziendale; nel caso del secondo modulo essa sarà completamente indipendente e dovrà essere sviluppata da zero.

2.2 Diagrammi Use-case

In questa sezione vengono presentati i diagrammi Use-case relativi ai due moduli. Tali diagrammi spiegano le principali interazioni tra diverse funzionalità del programma, e tra alcune funzionalità e gli “attori”, persone reali o virtuali che sono in qualche modo coinvolte con in funzionamento del software descritto. Queste raffigurazioni schematiche sono utili a rappresentare il funzionamento del programma in modo intuitivo ed immediato, e, per una loro maggiore comprensione, ne vengono di seguito elencate le principali caratteristiche.

2.2.1 Use-case A primo modulo: Generale


16/111

Questo diagramma rappresenta il modulo nella sua visione più superficiale e illustra le possibili interazioni percorribili dall’utente di “VisionSQL”. Ogni interazione comporterà una certa risposta da parte del modulo. Le principali caratteristiche di questa raffigurazione sono elencate come segue:

Attori coinvolti: L’utente finale di “VisionSQL” e “VisionSQL” stesso.

Scopo e definizione: Permettere all’utente finale di decidere se visualizzare il grafico temporale delle attività oppure pubblicare/eliminare le attività nel calendario di MS Outlook sotto forma di appuntamenti.

Precondizioni: L’utente finale necessita la visualizzazione del grafico temporale o la pubblicazione/eliminazione di una o più attività nel calendario di Outlook.

Flusso base di eventi:- l’utente finale richiede la visualizzazione del grafico temporale delle

attività;-l’utente f i n a l e richiede l a


17/111

pubblicazione di una attività in Outlook dopo aver deciso in quale calendario effettuare il salvataggio e in che formato. Altrimenti può chiederne la rimozione.

Flussi alternativi:- VisionSQL richiede i dati al database per visualizzare il grafico;- VisionSQL pubblica l’attività in Outlook sotto forma di appuntamento

oppure la rimuove.

Postcondizioni: VisionSQL ha visualizzato il grafico temporale delle attività oppure ha pubblicato l’attività nel calendario di Outlook oppure ha eliminato l’attività.


18/111

2.2.2 Use-case B primo modulo: Impostazione scala temporale

Questo diagramma rappresenta la parte del modulo che consente all’utente di scegliere la scala temporale del grafico. Le principali caratteristiche di questa raffigurazione sono elencate come segue:

Attori coinvolti: L’utente finale di “VisionSQL”.

Scopo e definizione: Permettere all’utente finale di scegliere con che scala temporale visualizzare il grafico delle attività in base alle sue esigenze lavorative.

Precondizioni: L’utente finale deve aver deciso di visualizzare il grafico temporale delle attività.

Flusso base di eventi:- L’utente finale sceglie di impostare la scala temporale sulla settimana

corrente;- L’utente finale sceglie di impostare la scala temporale sulla settimana

successiva;- L’utente finale sceglie di impostare la scala temporale sul mese

corrente;- L’utente finale sceglie di impostare la scala temporale sul mese

successivo;


19/111

- L’utente finale sceglie di impostare la scala temporale sull’anno corrente;

- L’utente finale sceglie di impostare la scala temporale sull’anno successivo.

Flussi alternativi:- L’utente finale sceglie di ripristinare la scala temporale a quella di

default (cioè la scala temporale parte dalla data di inizio dell’attività più vecchia e termina alla data di fine dell’attività più nuova).

Postcondizioni: “VisionSQL” modifica la scala temporale

2.2.3 Use-case C primo modulo: Impostazione dettagli grafico

Questo diagramma rappresenta la parte del modulo che consente all’utente di impostare i dettagli del grafico, consentendogli di configurarlo nella maniera più chiara e comprensibile per i suoi scopi lavorativi.


Scopo e definizioni: Permettere all’utente finale di scegliere le impostazioni e le configurazioni del grafico.


20/111

Precondizioni: L’utente finale deve aver deciso di visualizzare il grafico temporale delle attività.

Flussi base di eventi:- L’utente finale sceglie come impostare il modello del grafico;- L’utente finale sceglie come impostare la visualizzazione del grafico;- L’utente finale sceglie come impostare i dati del grafico;- L’utente finale sceglie come impostare la visualizzazione del grafico;- L’utente finale sceglie quali tools (esterni) eventualmente aggiungere;- L’utente finale sceglie il formato di default per esportare il grafico;- L’utente finale sceglie il formato di default di stampa del grafico;- L’utente finale sceglie di impostare l’immagine di sfondo del grafico.

Flussi alternativi: Non sono previsti flussi alternativi

Postcondizioni: “VisionSQL” modifica le impostazioni e le configurazioni del grafico.

2.2.4 Use-case D primo modulo: Esportazione grafico

Questo diagramma rappresenta la parte di modulo che consente all’utente finale di “VisionSQL” di esportare il grafico in un formato che potrà


21/111

utilizzare anche senza il software aziendale. Le principali caratteristiche di questa raffigurazione sono elencate come segue:


Scopo e definizioni: Permettere all’utente finale di esportare il grafico in maniera tale che egli possa utilizzarlo anche al di fuori del contesto di “VisionSQL”.

Precondizioni: L’utente finale deve aver deciso di esportare il grafico temporale delle attività.


22/111

Flussi base di eventi:- L’utente finale sceglie di esportare il grafico come immagine (e sceglie

anche il formato);- L’utente finale sceglie di esportare il grafico come formato nativo;- L’utente finale sceglie di esportare il grafico come formato dati.

Flussi alternativi: Non sono previsti flussi alternativi.

Postcondizioni: “VisionSQL” esporta il grafico temporale delle attività con il formato prescelto dall’utente.

2.2.5 Use-case A secondo modulo: Generale

Questo diagramma rappresenta il modulo, che verrà denominato come “VisionSync”, nella sua visione più superficiale e illustra le possibili interazioni percorribili dall’utente. Ogni interazione comporterà una certa risposta da parte del modulo. Le principali caratteristiche di questa raffigurazione sono elencate come segue:


23/111

Attori coinvolti: L’utente finale di “VisionSync”

Scopo e definizioni: Permettere all’utente finale (sia di base che amministratore di sistema) di impostare i parametri per la corretta sincronizzazione tra gli appuntamenti di MS Outlook e le attività di “VisionSQL”. Egli inoltre può chiedere di verificare la correttezza dei dati inseriti, salvare le impostazioni ed essere continuamente aggiornato sullo stato di avanzamento della sincronizzazione.

Precondizioni: “VisionSync” deve essere stato avviato, deve essere presente un database di “VisionSQL” e deve essere presente una installazione di MS Outlook.

Flusso base di eventi:- L’utente finale sceglie di chiedere la verifica dei dati immessi;- L’utente finale associa calendari a database (fino ad un massimo di tre

associazioni);- L’utente finale sceglie di configurare ogni quanti minuti effettuare una

eventuale sincronizzazione- L’utente finale sceglie di salvare eventuali cambiamenti nelle

impostazioni.

Flussi alternativi:- L’utente finale sceglie di chiudere il programma;

Postcondizioni: “VisionSync” effettua una verifica della corretta immissione dei dati, effettua una eventuale sincronizzazione di appuntamenti con attività, aggiorna l’utente riguardo allo stato del processo, segnala un eventuale errore.


24/111

2.3 Diagrammi delle attività

2.3.1 Diagramma attività primo modulo: Generale

In questo diagramma viene mostrata l’integrazione tra il modulo e l’utente finale. L’unico compito svolto da “VisionSQL” è all’inizio di tutte le operazioni e consiste nella creazione di tutte le strutture dati utilizzate dal modulo e nell’apertura della connessione con il database aziendale. Subito dopo il modulo si configura inizializzando i campi dati con i dati ottenuti dalle strutture di “VisionSQL” ed è pronto per essere utilizzato dall’utente. In base alla scelta di quest’ultimo il modulo prenderà due strade differenti: o visualizzerà il grafico temporale delle attività oppure pubblicherà (o rimuoverà) le attività in Outlook. Ogni strada presa viene quindi gestita da una classe apposita, visto che nessuna delle due ha operazioni in comune. Al termine dell’elaborazione i risultati vengono restituiti all’utente o sotto forma di grafico visibile oppure sotto forma di messaggio che lo avviserà dell’esito dell’operazione di salvataggio o eliminazione.


25/111

2.3.2 Diagramma attività primo modulo: Visualizzazione grafico

In questo diagramma viene mostrato come il modulo lavora quando viene richiesta la visualizzazione del grafico temporale delle attività. Come prima operazione il modulo richiede al database quelle da riportare nel grafico (o tutte o quelle ottenute dopo una operazione di filtraggio con criteri selezionati dall’utente). Una volta che i records vengono restituiti dal database, vengono salvati all’interno di una particolare struttura dati del modulo ed elaborati con la seguente procedura:

✤ vengono eliminate le attività che non hanno una data di inizio o una data di fine o nessuna delle due. Inoltre vengono controllate le ore di inizio e di fine se l’attività dura un solo giorno: se l’ora di fine è identica a quella di inizio, essa viene impostata alle 23.59 in modo tale da fare comparire una attività di un giorno intero;

✤ vengono corrette le date fasulle poichè, a causa di un bug di “VisionSQL”, ogni volta che il database non riceve una data ne inserisce una con il formato “1/1/1900”;


26/111

✤ vengono formattati i campi dati in maniera tale che nel grafico compaiano l’id di chi o cosa deve svolgere l’attività, le note dell’attività, la data e l’ora di inizio e la data e l’ora di fine;✤ vengono analizzate le date e gli stati delle attività per decidere lo stato di evasione. Ci possono essere cinque stati:

- non iniziata (l’attività verrà colorata di rosso nel grafico);- in attesa (l’attività verrà colorata di arancione nel grafico);- in corso (l’attività verrà colorata di blu nel grafico);- rinviata (l’attività verrà colorata di giallo nel grafico);- evasa (l’attività verrà colorata di verde nel grafico).

Terminata questa serie di operazioni le attività vengono disegnate nel grafico e vengono applicate le impostazioni volute dall’utente. Il modulo conclude il lavoro aprendo una finestra e visualizzando il grafico.

2.3.3 Diagramma attività primo modulo: Pubblicazione attività

In questo diagramma viene mostrato come il modulo lavora quando viene richiesta la pubblicazione o la rimozione di un appuntamento (legato ad


27/111

una attività) dal calendario di Outlook. Innanzitutto esso verifica, al momento del salvataggio dell’attività nel database) se l’attività deve avere (oppure ha avuto) un riferimento con un appuntamento nel calendario. In caso di esito negativo il modulo non effettua alcuna operazione; in caso di esito positivo testa se va fatta una pubblicazione sul calendario o una rimozione da esso. Se deve essere fatta una rimozione, il modulo cerca se tra gli appuntamenti di Outlook ce n’è uno con id uguale all’id dell’attività e lo rimuove dal calendario. Se deve essere fatta una pubblicazione il modulo stabilisce se deve essere fatta una creazione appuntamento o una modifica appuntamento. Se deve essere effettuata una creazione, il modulo utilizza le API di Outlook e pubblica un appuntamento composto dalle seguenti informazioni:‣ oggetto attività + id attività (univoco del database);‣ descrizione risorsa/dipendente che deve svolgere l’attività;‣ data e ora inizio attività;‣ data e ora fine attività;‣ note attività.Se invece deve essere effettuata una modifica, il modulo utilizza un trucco: prima cerca l’appuntamento con l’id dell’attività e lo rimuove e poi crea un nuovo appuntamento però con le informazioni modificate.Al termine di qualsiasi operazione di pubblicazione o rimozione il modulo restituisce un messaggio di avvenuto successo o insuccesso all’utente, mentre i risultati saranno visibili su Outlook, quindi esternamente da “VisionSQL”.

2.3.4 Diagramma attività secondo modulo: Generale


28/111

In questo modulo viene mostrata l’integrazione tra il modulo e l’utente finale. Dopo l’apertura del programma, vengono caricate tutte le impostazioni o di base o precedentemente salvate dall’utente. Fatto ciò, il modulo crea un thread per la s incronizzazione di appuntamenti con att iv i tà e contemporaneamente lascia all’utente la possibilità di (ri)configurare le impostazioni o di chiudere il programma. Se egli sceglie di modificare le impostazioni è inoltre libero di verificare soltanto il loro corretto inserimento oppure di salvarle e renderle effettive. Se invece egli decide di chiudere il programma, il modulo termina il thread di sincronizzazione (se non è in corso una operazione critica) e successivamente l’intero programma. Per quanto riguarda il thread di sincronizzazione, invece, esso è autonomo ed indipendente, non richiede l’attenzione dell’utente (salvo quando si verificano errori) e non interferisce con altri programmi quali Outlook o VisionSQL. Il suo funzionamento verrà spiegato approfonditamente nel paragrafo successivo.

2.3.5 Diagramma attività secondo modulo: Sincronizzazione

In questo diagramma viene mostrato come il modulo lavora quando deve essere svolta l’operazione di sincronizzazione tra Outlook ed il database.


29/111

Innanzitutto va precisato che la sincronizzazione non viene eseguita sempre ma viene eseguita dopo un periodo di tempo scelto dall’utente e salvato tra le impostazioni del programma. Trascorso questo tempo il modulo inizia a lavorare sulla vera e propria sincronizzazione e come primo passo richiede tutti gli appuntamenti tramite le API di Outlook e li salva in una apposita struttura dati. Successivamente richiede tutte le attività al database e le salva in un’altra apposita struttura dati. A questo punto il modulo confronta gli appuntamenti con le attività e scarta gli appuntamenti e le attività identici (quindi che non hanno subito alcuna modifica). Terminata l’operazione di filtraggio il modulo testa se sono rimasti degli appuntamenti da sincronizzare: in caso negativo il modulo termina il suo lavoro; in caso positivo esso converte gli appuntamenti nel formato delle attività accettato dal database, li salva nel database e termina il suo lavoro.

2.4 Descrizione generale dei componenti

2.4.1 Primo modulo: GestoreGrafici/Calendari

Tipo, obiettivo e funzione del componente La classe “GestoreGrafici/Calendari” funge da classe base per tutto il primo modulo e, in base alle scelte dell’utente, intraprende una azione diversa.


30/111

Essa infatti offre una aggiunta all’interfaccia grafica di “VisionSQL” che consente all’utente o di visualizzare il grafico temporale o di pubblicare/eliminare le attività da Outlook.

Relazione d’uso di altre componenti

La classe affida il disegno e la gestione dei grafici temporali alla classe “GestoreGrafici”. Inoltre affida la gestione delle attività/appuntamenti alla classe “GestoreCalendari”. Questa decisione è stata presa per semplificare il più possibile la classe base e per darle, così, nulla di più di una funzione di collegamento tra i due sottomoduli oltre che di aggiunta all’interfaccia grafica. Per gestire l’elenco delle attività essa utilizza un legame di aggregazione forte con la classe “Attività” e per gestire le varie connessioni al database, i vari caricamenti e i vari salvataggi usa una parte della classe “GestoreDB”.

Interfacce con e relazioni d’uso da altre componenti

La classe viene utilizzata dal software aziendale “VisionSQL” che ne crea una istanza ogni volta che l’utente chiede di avere una visualizzazione grafica delle attività. Ad ogni creazione di istanza il software provvede anche a creare le varie strutture dati utilizzate dalla classe.

Attività svolte e dati trattati

Dopo la creazione di una istanza di questa classe all’utente viene presentata una finestra grafica nella quale compaiono tutte le attività restituite dal database. A questo punto egli può decidere se richiedere la visualizzazione del grafico temporale delle attività, creare una nuova attività, modificarne una esistente e collegarle o scollegarle con il calendario di Outlook. In base alla decisione dell’utente la classe chiamerà dei metodi differenti che utilizzeranno le corrette classi per gestire la richiesta dell’utente.


31/111

2.4.2 Primo modulo: GestoreCalendari

Tipo, obiettivo e funzione del componente

La classe “GestoreCalendari” è la classe utilizzata per gestire una eventuale pubblicazione o rimozione di un appuntamento legato ad una attività dal calendario di Outlook. A questa classe competono tutti i collegamenti con Outlook, la richiesta dell’attività da salvare o eliminare, la conversione in formato accettato dal calendario e la pubblicazione/rimozione.


La classe “GestoreGrafici/Calendari” ha una relazione di aggregazione forte con la classe “Attività” dal momento che deve gestire l’attività da esportare nel calendario di Outlook. Inoltre “GestoreCalendari” usa una parte della classe “GestoreDB” per gestire le varie connessioni al database e i vari caricamenti e la classe “APIOutlook” per comunicare direttamente con Outlook.



32/111

Questa classe ha una relazione di aggregazione forte con la classe base “GestoreGrafici/Calendari” che la usa per scaricarle tutto il lavoro riguardante la pubblicazione/rimozione di appuntamenti dal calendario di Outlook.Attività svolte e dati trattati

Come primo passo alla classe viene passato l’id dell’attività che essa dovrà ottenere dal database di “VisionSQL”. Una volta ottenuta, la classe analizza l’attività per capire se deve essere fatta una rimozione o una pubblicazione. Se deve essere fatta una rimozione, cerca nel calendario di Outlook se esiste un appuntamento con lo stesso id dell’attività e in caso di esito positivo chiama le API per eliminarlo. Se deve essere fatta una pubblicazione, la classe innanzitutto converte data e ora di inizio e fine in un formato accettabile da Outlook e successivamente testa se deve essere fatta una creazione o soltanto una modifica: nel primo caso chiama le API per pubblicare l’appuntamento, nel secondo caso cerca un appuntamento con lo stesso id dell’attività, lo elimina e poi pubblica un nuovo appuntamento.

2.4.3 Primo modulo: GestoreGrafici


33/111


La classe “GestoreGrafici” è la classe utilizzata per disegnare e gestire il grafico temporale delle attività. A questa classe compete infatti la comunicazione con gli oggetti OLE per la gestione grafica del grafico temporale.


La classe “GestoreGrafici” ha una relazione di aggregazione forte con la classe “Attività” dal momento che deve gestire tutta la lista di attività da rappresentare nel grafico. Inoltre utilizza la classe “OLEObject” per gestire la grafica del grafico temporale.


Questa classe ha una relazione di aggregazione forte con la classe base “GestoreGrafici/Calendari” che la usa per per scaricarle tutto il lavoro riguardante la gestione del grafico temporale delle attività.


Come primo passo la classe salva in una apposita struttura dati tutte le attività che verranno riportate nel grafico e che sono state selezionate dall’utente. Successivamente vengono analizzate in modo tale da scartare quelle senza data e vengono corrette le date sbagliate. Prima di essere inserite nel grafico le attività vengono inoltre adeguate secondo il modello voluto dalla componente OLE e vengono associate ad un colore indicante lo stato di evasione di queste. Terminate tutte queste operazioni di elaborazione, le attività vengono inserite nel grafico, che viene infine configurato o con le impostazioni di default o con le impostazioni volute dall’utente e visualizzato su schermo.


34/111

2.4.4 Secondo modulo: Setup


La classe “Setup” funge da classe base per l’intero programma “VisionSync” e da base di collegamento tra la classe grafica, la classe dei file delle impostazioni e la classe che gestisce il thread di sincronizzazione.


La classe ha tre aggregazioni con altre classi dal momento che deve fare da collegamento tra la maggior parte delle classi vitali del sotfware. Ha una relazione di aggregazione debole con la classe “SLFile” poichè la utilizza per caricare le impostazioni dai file di configurazione o per salvare le impostazioni sui file. Ha una relazione di aggregazione debole con la classe “WinSetup” poichè la utilizza per inizializzare l’interfaccia grafica e per comunicarle eventuali informazioni che vogliono essere riportate all’utente (per esempio un aggiornamento sullo stato della sincronizzazione). Ha una relazione di aggregazione debole con la classe “BaseThread” poichè la utilizza per avviare il thread di sincronizzazione, per fermarlo o per comunicargli le informazioni vitali per il corretto funzionamento del processo di sincronizzazione.Inoltre la classe eredita dalla classe “QWidget”, nativa delle librerie Qt, per poter gestire con semplicità e velocità le relazioni tra le varie classi di “VisionSync”.


35/111


Dal momento che la classe deve ricevere anche informazioni o richieste dalle varie componenti e utilizzarle o inoltrarle, essa ha una relazione di aggregazione debole con le classi “WinSetup” e “BaseThread”. In particolare la prima informa la classe riguardo ad eventuali modifiche o richieste dell’utente e la seconda informa la classe riguardo allo stato del processo di sincronizzazione.Inoltre, come in tutti i programmi scritti con il linguaggio C++, la classe viene creata ed invocata da una particolare funzione chiamata “Main”.


Appena il programma si avvia, la classe ottiene le impostazioni tramite il loro caricamento da file effettuato dalla classe “SLFile”. Se il caricamento non è andato a buon fine la classe si limita soltanto ad avviare l’interfaccia grafica segnalando all’utente la presenza di un errore, altrimenti avvia il thread di sincronizzazione e avvia l’interfaccia grafica. La classe offre anche i metodi per testare se i dati immessi dall’utente sono validi, per salvare eventuali suoi cambiamenti, per aggiornare la grafica in base allo stato del processo di sincronizzazione e per chiudere l’intero programma.

2.4.5 Secondo modulo: WinSetup


36/111


La classe “WinSetup” è la classe che gestisce l’unica finestra grafica di tutto “VisionSync”. Ad essa quindi competono non solo l’aggiornamento visivo per l’utente dello stato di sincronizzazione ma anche la gestione di tutte le richieste e di tutti i cambiamenti che arrivano dall’utente.


La classe eredita dalla classe nativa della libreria Qt “QWidget” poichè deve gestire tutta la parte di disegno dell’interfaccia grafica e tutti i metodi principali delle Qt stesse.La classe ha anche una relazione di aggregazione debole con la classe “Setup” per poter comunicare a quest’ultima eventuali decisioni dell’utente riguardo a cambiamenti o test sulle impostazioni.


La classe ha una relazione di aggregazione debole con la classe “Setup” poichè da essa viene creata, da essa riceve aggiornamenti sullo stato della sincronizzazione e da essa viene chiusa.


Oltre alla creazione e alla visualizzazione dell’interfaccia grafica la classe non fa alcun altro lavoro salvo attendere un input dall’utente e comunicarlo alla classe “Setup” e ricevere informazioni sullo stato del processo di sincronizzazione e mostrarle all’utente.

2.4.6 Secondo modulo: SLFile


37/111


La classe “SLFile” è utilizzata per gestire il caricamento delle impostazioni dal file e i salvataggi delle impostazioni su file. Ad essa competono quindi tutti i collegamenti con i file presenti sull’hard disk e in caso di loro assenza la loro creazione.


La classe non utilizza altre componenti di “VisionSync”


La classe ha una relazione di aggregazione debole con la classe “Setup” dalla quale riceve le impostazioni da salvare su file o alla quale restituisce eventuali impostazioni caricate da file.


La classe viene invocata dalla classe “Setup” ogni volta che serve salvare o caricare i dati dai file presenti sull’hard disk. In particolare riceve le impostazioni da salvare sotto forma di lista di stringhe e un numerico oppure restituisce le impostazioni caricate sotto forma di lista di stringhe. Al termine delle operazioni chiude le connessioni con i file.


38/111

2.4.7 Secondo modulo: BaseThread


La classe “BaseThread” è la classe che gestisce tutto il processo di sincronizzazione tra il calendario di Outlook e il database di “VisionSQL”. Essa infatti è il thread che lavora indipendentemente dalle altre componenti del software e che funge da base tra la classe che si cura degli appuntamenti di Outlook e la classe che si cura delle attività del database. Proprio per questo motivo la classe è la seconda parte più importante del programma dopo la classe “Setup”.


Poichè il thread deve gestire una grande quantità di dati, deve metterli a confronto ed eventualmente sincronizzarli, si è pensato di alleggerire il lavoro della classe dividendolo con altre componenti del software. La classe ha quindi quattro relazioni di aggregazione debole con altre classi del software. Esse sono:- aggregazione debole con la classe “Setup” dal momento che deve informarla

riguardo allo stato del processo di sincronizzazione;- aggregazione debole con la classe “OutlookManager” dal momento che ogni

volta che il processo di sincronizzazione viene avviato il thread deve ottenere da Outlook la lista di tutti gli appuntamenti presenti nel calendario;

- aggregazione debole con la classe “DatabaseManager” dal momento che il thread deve ottenere dal database di “VisionSQL” le attività ed eventualmente aggiornarle;


39/111

- aggregazione debole con la classe “Appointment” dal momento che il thread deve gestire una lista di appuntamenti da inviare poi alla classe che confronta ed eventualmente sincronizza le attività.

Inoltre “BaseThread” eredita da “QThread” per poter usufruire di tutti i metodi e le strutture dati tipiche dei thread.


La classe ha una relazione di aggregazione debole con la classe “Setup” dal momento che è compito di quest’ultima creare il thread, fermarlo, modificare le impostazioni da esso utilizzate e metterlo in pausa.


Una volta avviato il thread, esso si comporta sempre seguendo lo stesso ciclo di azioni e cioè:- attesa per un certo periodo di tempo;- richiesta appuntamenti da Outlook;- richiesta attività dal database;- passaggio degli appuntamenti alla classe di competenza;- richiesta di effettuare il controllo per vedere se va effettuata la

sincronizzazione;- richiesta di sincronizzazione;- rimozione strutture dati di appuntamenti e di attività.Al termine di ognuna delle precedenti azioni il thread provvede ad emettere un segnale per aggiornare in tempo reale l’utente sullo stato di sincronizzazione.


40/111

2.4.8 Secondo modulo: OutlookManager


La classe “OutlookManager” è la classe utilizzata per richiedere ad Outlook gli appuntamenti presenti nei calendari. In sostanza chiama un altro file eseguibile che permette di creare un collegamento con le API di Outlook e creare dei file temporanei contenenti tutti gli appuntamenti di un dato calendario.


La classe ha una relazione di aggregazione debole con la classe “Appointment” poichè deve gestire una lista di appuntamenti caricati dai file temporanei.


La classe ha una relazione di aggregazione debole con la classe “BaseThread” dal momento che viene creata da quest’ultima e viene invocata ogni volta che devono essere ottenuti gli appuntamenti da Outlook.

Azioni svolte e dati trattati

Ogni volta che la classe viene invocata essa lancia il secondo file eseguibile e attende il suo completamento. Successivamente carica i dati dai file temporanei (creati dal secondo processo) e li organizza come appuntamenti


41/111

che poi ritornerà alla classe “BaseThread”. Al termine delle operazioni di caricamento la classe provvede anche alla eliminazione dei file temporanei.

2.4.9 Secondo modulo: Appointment


La classe “Appointment” funge da contenitore per tutti quei dati che costituiscono un vero e proprio appuntamento. Essi sono:- id dell’appuntamento (uguale a quello dell’attività presente nel database);- oggetto dell’appuntamento:- risorsa o dipendente che ha l’appuntamento;- note dell’appuntamento;- data di inizio dell’appuntamento;- ora di inizio dell’appuntamento;- data di fine dell’appuntamento;- ora di fine dell’appuntamento.

Inoltre la classe è provvista di metodi che consentono all’appuntamento di cambiare il formato per adattarlo ad un eventuale confronto con il formato di una attività


42/111


La classe non utilizza altre componenti di “VisionSync”.


La classe ha una relazione di aggregazione debole con la classe “OutlookManager” e con la classe “BaseThread” dal momento che queste due hanno bisogno di gestire liste di appuntamenti.


Non appena viene invocato il costruttore della classe esso ha il compito di ottenere l’id dell’appuntamento dall’oggetto. Questa operazione viene effettuata poichè il primo modulo salva l’id dell’attività dentro il campo oggetto dell’appuntamento. Successivamente vengono convertite le date e le ore in un formato comparabile con quello ritornato da un database di tipo MS SQL. Al termine delle azioni sopra descritte l’appuntamento è pronto per essere confrontato.


43/111

2.4.10 Secondo modulo: DatabaseManager


La classe “DatabaseManager” è la classe utilizzata per gestire tutti i collegamenti con il database di “VisionSQL”, la connessione, la richiesta di dati e l’eventuale salvataggio sicuro. Questa classe inoltre effettua il controllo tra attività ed appuntamenti per stabilire se le attività non sono aggiornate e in caso di esito positivo sincronizza il database.


La classe ha una relazione di aggregazione debole con la classe “Activity” dal momento che deve gestire una lista di attività da confrontare ed eventualmente sincronizzare.


La classe ha una relazione di aggregazione debole con la classe “BaseThread” poichè da quest’ultima viene creata, invocata e da quest’ultima arrivano tutte le richieste di nuove azioni nel processo di sincronizzazione.


44/111


Appena viene creata la classe riceve la lista degli appuntamenti che dovranno essere confrontati e chiede al database la lista di tutte le attività presenti in esso. A questo punto vengono rimosse dalla lista tutte quelle attività il cui id non è stato trovato nella lista degli appuntamenti, vengono confrontate le attività con gli appuntamenti e vengono eventualmente eliminate dalla lista tutte quelle attività che non devono essere modificate nel database. Se al termine di queste operazioni la lista delle attività ha ancora degli elementi, essi vengono aggiornati e salvati in modalità sicura nel database. La sincronizzazione è quindi stata effettuata.

2.4.11 Secondo modulo: Activity


La classe “Activity” funge da contenitore per tutti quei dati che costituiscono una vera e propria attività. Essi sono:- id dell’attività (univoco del database);- oggetto dell’attività;- soggetto di chi o cosa deve svolgere l’attività;- note dell’attività;- data di inizio dell’attività;- ora di inizio dell’attività;- data di fine dell’attività;- ora di fine dell’attività.


45/111

Inoltre la classe è provvista di un metodo che permette di ottenere una data completa in formato numerico.


La classe non utilizza altre componenti di “VisionSync”


La classe ha una relazione di aggregazione debole con la classe “DatabaseManager” poichè questa deve gestire una lista di attività da confrontare con una lista di appuntamenti.


Una volta eseguito il costruttore esso setta i campi dati dell’attività con i dati passatigli e converte la data in un formato numerico. L’attività è quindi pronta per essere elaborata.

2.5 Diagramma di comunicazione primo modulo


46/111

Il funzionamento del primo modulo è regolato principalmente dalle scelte dell’utente finale.

caricaAttività(): il modulo carica tutte le attività contenute nel database.

visualizzaAttività(): il modulo mostra tutte le attività all’utente.

impostaFiltri(): ogni volta che l’utente decide di applicare dei filtri il modulo pulisce le attività in base alle richieste e alle esigenze.

apriAttività(): ogni volta che l’utente fa doppio clic su una attività il modulo visualizza tutti i dettagli di questa.

annulla(): il modulo si chiude senza salvare eventuali modifiche apportate alle attività.

salvaAttività(): il modulo si chiude salvando eventuali modifiche apportate alle attività. Questo metodo effettua il salvataggio nel database e se tutto è andato a buon fine chiama la classe “GestoreCalendari” per vedere se devono essere pubblicati o rimossi degli appuntamenti.

ottieniAttività(): l’attività viene richiesta al database.

analizzaAttività(): l’attività viene analizzata per verificare se deve essere fatta una pubblicazione o una eliminazione.

convertiDataOra(): le date e le ore dell’attività vengono convertite in un formato accettabile da Outlook.

trovaAttività(): viene cercato nel calendario di Outlook un appuntamento con id uguale a quello dell’attività.

eliminaAttività(): l’appuntamento legato all’attività viene rimosso dal calendario.

pubblicaAttività(): l’appuntamento legato all’attività viene creato ex novo oppure modificato (dipende se l’attività viene creata o meno).

disegnaGrafico(): il metodo viene chiamato ogni volta che l’utente decide di voler visualizzare il grafico temporale delle attività.

impostaListaAttività(): salva la lista delle attività da rappresentare nel grafico all’interno della classe.

pulisciAttività(): vengono rimosse tutte le attività prive di data.

correggiDate(): vengono corrette tutte le attività con date sballate.


47/111

riformattaAttività(): l’attività viene formattata con un formato accettabile dalla componente che disegna il grafico e lo popola.

associaEvasione(): in base alle date dell’attività e alla data corrente del sistema l’attività viene colorata per stato di evasione.

inserisciNelGrafico(): le attività vengono inserite nel grafico.

configuraGrafico(): il grafico viene configurato secondo le richieste dell’utente finale.

visualizzaGrafico(): il grafico viene visualizzato all’utente.

2.6 Diagramma di comunicazione secondo modulo

Il diagramma delle comunicazioni sopra riportato mostra le principali comunicazioni tra le classi del software “VisionSync”.

loadSetup(): richiede il caricamento delle impostazioni.

loadFile(): carica le impostazioni dal file delle configurazioni.

launchWin(): richiede l’avvio dell’interfaccia grafica.

showWin(): mostra la finestra grafica all’utente.


48/111

slotVerButton(): richiede il test per vedere se i dati sono stati inseriti correttamente.slotSaveButton(): richiede il salvataggio dei cambiamenti delle impostazioni.

changeConfig(): cambia la configurazione dei dati che il thread deve utilizzare e ne richiede il salvataggio.

saveFile(): salva le impostazioni sul file delle configurazioni.

slotQuitButton(): richiede la chiusura del programma “VisionSync”.

updateProgress(): informa la grafica sullo stato di avanzamento del processo di sincronizzazione.

run(): esegue ciclicamente le operazioni del thread. Esse sono:

- checkAppointment(): ottiene da Outlook tutti gli appuntamenti all’interno di un calendario;

- removeFile(): rimuove i file temporanei;- setData(): passa alla classe del database l’elenco degli appuntamenti;- getDataFromDb(): ottiene dal database tutte le attività;- cleanDataFromDb(): rimuove le attività il cui appuntamento non è presente

nel calendario;- compareActApp(): controlla se l’appuntamento legato all’attività è stato

modificato;- writeInDb(): scrive in modalità sicura tutte le attività che sono state

modificate.


49/111

Capitolo 3

Scelte progettuali ed organizzative

3.1 Patterns applicati

In questa sezione sono illustrati i design patterns utilizzati nel progetto, cioè schemi progettuali che contribuiscono a dare semplicità e chiarezza alla progettazione del software. Per essere più precisi, nel progetto sono stati impiegati due patterns: il “Mediator” pattern e il “Façade” pattern. Il primo è associato alla classe “Setup” del secondo modulo e il secondo è associato alla classe “GestoreGrafici/Calendari”.

3.1.1 Mediator pattern

Il “Mediator” pattern è un pattern di tipo comportamentale che si interpone nelle comunicazioni tra oggetti in modo tale da aggiornare lo stato del sistema quando una delle sue componenti comunica un cambiamento del proprio stato. Proprio per questo motivo esso è stato associato alla classe “Setup” del secondo modulo, dal momento che questa classe svolge anche il ruolo di base di comunicazione tra le componenti più importanti del software, cioè tra il thread, l’interfaccia grafica e il gestore dei file su hard disk. Essa infatti sfrutta ed implementa una delle potenzialità delle librerie Qt, cioè la tecnica dei “SIGNALS/SLOTS” che consente ad una classe di segnalare cambiamenti di stato e ad un’altra di accorgersi delle notifiche.


50/111

3.1.2 Façade pattern

Il “Façade” pattern è un pattern di tipo strutturale che consente, attraverso una interfaccia più semplice, l’accesso a sottosistemi che espongono interfacce complesse e diverse tra loro. Proprio per questo motivo è stato associato alla classe “GestoreGrafici/Calendari” del primo modulo, dal momento che questa classe offre l’interfaccia di partenza che gestirà successivamente due strade completamente differenti: da una parte gestirà eventuali azioni sui calendari, dall’altra gestirà la visualizzazione dei grafici e il loro popolamento. La scelta della strada da percorrere varia in base all’input immesso dall’utente finale.

3.2 Standard di progetto

3.2.1 Standard di progettazione architetturale

Per realizzare la progettazione dei due moduli è stato adottato il linguaggio formale UML (unified modeling language). Per la precisione:

• le classi sono rappresentate da rettangoli divisi in tre sezioni, contenenti rispettivamente il nome della classe, i suoi campi dati e i suoi metodi;


51/111

• la relazione di aggregazione è indicata da un segmento che congiunge le due classi interessate specificandone la molteplicità e da un rombo pieno (aggregazione forte) o vuoto (aggregazione debole) sull’estremo del segmento unito alla classe contenitore . Laddove la molteplicità non è presente, essa corrisponde alla relazione “1 a 1”;

• la relazione di generalizzazione è indicata da una freccia con una punta a triangolo, indica una relazione tassonomica tra un elemento più generale e uno più specifico;

• la relazione di dipendenza è segnalata da una freccia tratteggiata, ed indica che la classe dalla quale parte la dipendenza necessita della classe indicata dalla freccia sebbene non ne possieda riferimenti e non ne sia una generalizzazione.

3.2.2 Standard di documentazione del codice

Non essendo stata comunicata o imposta una prassi aziendale riguardante la documentazione del codice, si è deciso di fare due tipi di commenti:

commenti “interni” al codice: per semplificare il lavoro di comprensione, verifica e modifica da parte di chi dovrà integrare i due moduli con il software aziendale, ogni riga del codice è stata commentata descrivendo minuziosamente che cosa sta avvenendo. In più come intestazione del file è stato aggiunto una sorta di diario delle modifiche, in modo tale da descrivere a grandi linee quali aggiunte o cambiamenti sono state apportati al codice e in quale giorno;

commenti “esterni” al codice: per quanto riguarda il primo modulo, il linguaggio FoxPro prevede di dotare metodi e classi con una sorta di introduzione che raccoglie un commento generico sul metodo stesso, sui suoi campi dati e sui suoi dati ritornati. Tali commenti diventeranno parte della documentazione interattiva del progetto, consultabile dal programmatore ogni volta che ne avrà bisogno. Inoltre l’ambiente di sviluppo Visual FoxPro permette, all’occorrenza, di pubblicare in una documentazione a parte questi commenti per renderli visibili anche al di fuori dell’ambiente di sviluppo stesso.


52/111

3.3 Visione generale delle strategie di verifica

3.3.1 Risorse utilizzate

Per testare entrambi i moduli sono stati utilizzati gli strumenti messi a disposizione dai rispettivi ambienti di sviluppo, quindi da Visual FoxPro per il primo modulo e da QtCreator per il secondo. Lo strumento più utilizzato è stato in entrambi i casi il debugger, il quale facilita la visione dei contenuti delle varie strutture dati a tempo di esecuzione ed evidenzia, sempre a tempo di esecuzione, quale errore è stato commesso, di che tipo e da cosa dipende. Le risorse temporali sono state diluite nel tempo, concentrandosi nel momento della conclusione della codifica delle varie componenti in modo tale da avere un immediata conferma o smentita riguardo al loro corretto funzionamento.

3.3.2 Tecniche di verifica

L’attività di verifica si divide in due fasi distinte:

Analisi statica: realizzata dagli ambienti di sviluppo Visual FoxPro e QtCreator durante la digitazione del codice: si accerta che non vengano commessi errori, che il flusso di controllo possa essere raggiunto in ogni sua parte e che i dati non assumano valori illegali o senza senso.

Analisi dinamica: sono stati effettuati test per ogni singola componente. Questi test sono stati concepiti in modo da riprodurre, per quanto possibile, tutte le eventuali situazioni in cui una componente si può trovare. Dal momento che entrambi i moduli devono lavorare in base alle scelte dell’utente, è stata posta inoltre una particolare attenzione nel testare le componenti in modo tale da evitare il più possibile eventuali errori provenienti dall’utente, più o meno esperto, quali immissione di dati inconsistenti, mancata immissione di dati importanti o chiusura del programma in una sua fase critica. Una tipica risorsa utilizzata in questa fase è il debugger, con cui viene passo passo analizzata ogni struttura dati.

3.4 Gestione amministrativa delle risorse

Gli errori riscontrati in fase di verifica sono stati classificati come anomalie o come discrepanze, a seconda della loro gravità. La loro distinzione è stata concepita come segue:

Anomalie: ogni errore che comprometta in maniera grave il funzionamento del modulo. Le anomalie sono state risolte con la massima sollecitudine possibile non solo perchè rappresentano un problema di medio grande


53/111

dimensione ma anche per poter procedere secondo i tempi prestabiliti. Ad ogni errore è, quindi, corrisposta una specifica risposta in ambito di codifica oppure, laddove necessario, in ambito progettuale.

Discrepanze: ogni errore che non comprometta seriamente il funzionamento del modulo. Nei casi in cui il problema sia stato di banale soluzione la correzione è stata immediata, in caso contrario la discrepanza è stata notificata e la sua correzione è avvenuta il prima possibile.

3.4.1 Pianificazione strategica e temporale e risultati

La campagna di verifica è stata divisa in settori, considerando le dipendenze esistenti tra le varie parti di ciascun modulo:

Strutture dati: all’inizio è stato verificato il corretto funzionamento delle strutture che contengono i dati configurati, attività che ha riguardato quasi esclusivamente la costruzione e i metodi di ritorno dei dati dalle varie classi. In questa fase quasi tutti i test hanno dato risultati positivi alla prima prova.

Lettura dei dati: oggetto di verifica è stata la corretta acquisizione dei dati da file o da database e il loro inserimento nelle strutture dati apposite. Questo settore ha dato risultati abbastanza positivi e gli errori riscontrati hanno riguardato sempre un caricamento dei record sbagliato a causa di una modifica da parte del database (nel caso del primo modulo) oppure una cattiva lettura dai file (nel caso del secondo modulo).

Funzionamento delle classi di base e collegamento: della parte vitale di ogni modulo è stato verificato il funzionamento generale p r i m a d i procedere alla verifica delle funzionalità peculiari. Questa fase di test ha rilevato soprattutto imprecisioni negli algoritmi, che sono state quindi prontamente risolte. I test finali quindi hanno dato risultati positivi.

Inserimento dei dati: è stato verificato il corretto inserimento dei dati in maniera tale che l’utente non fosse in grado di lasciare vuoti campi dati vitali o di scrivere dati sbagliati o di scambiare due campi dati tra di loro (per esempio data al posto dell’ora e viceversa). I test hanno quasi sempre dato esiti positivi salvo nel caso in cui nel primo modulo l’utente era in grado di mettere una data di fine antecedente a quella di inizio. Il modulo comunque continuava a funzionare senza dare errori o problemi, tuttavia non essendo la situazione coerente con la logica dell’attività si è pensato di risolvere prontamente la discrepanza.

Salvataggio sicuro nel database: siccome entrambi i moduli lavorano contemporaneamente c’è il rischio di race condition. Di conseguenza sono stati fatti dei test per accertarsi che, qualora entrambi i moduli


54/111

tentino di scrivere contemporaneamente sul database, uno di essi venga posticipato finchè l’altro non ha finito la scrittura. Per fare questi test è stato impiegato, oltre ai metodi già presenti nei linguaggi di programmazione, anche un piccolo software dell’azienda scritto appositamente per questo scopo.

Integrazione: una volta verificato il corretto funzionamento dei moduli è stata accertata la corretta integrazione con il software aziendale “VisionSQL”, con il database da esso utilizzato e con MS Outlook. Si è verificata solo una piccola discrepanza nel secondo modulo al momento del confronto tra attività ed appuntamenti. Tale discrepanza riguardava il diverso formato delle date ma è stata facilmente risolta e i test finali hanno dato esiti positivi.


55/111

Capitolo 4

Consuntivo delle attività

Questo capitolo mostra un resoconto delle attività svolte durante lo stage, prima con un diagramma di Gantt, che illustra la scansione temporale delle varie fasi di sviluppo, poi con un istogramma che evidenzia il quantitativo di ore impiegate per portare a termine il progetto confrontate con quelle preventivate.

La realizzazione del progetto è stata divisa in quattro fasi:

fase 1: studio e comprensione dell’ambiente aziendale, del software aziendale, delle politiche di programmazione e delle richieste/aspettative dell’azienda riguardo al progetto.

fase 2: progettazione e sviluppo del primo modulo da integrare con “VisionSQL”.

fase 3: ricerca di un software di terze parti per sopperire alle mancanze del primo modulo. Tale ricerca ha dato esito negativo poichè tutte le soluzioni trovate comportavano o una modifica del database di “VisionSQL” oppure una modifica del software stesso per essere adattato al database. La prima soluzione è stata scartata dall’azienda poichè uno dei requisiti imposti era di mantenere il database invariato e la seconda soluzione è stata scartata poichè avrebbe comportato una spesa di acquisto troppo onerosa.

fase 4: progettazione e sviluppo del secondo modulo per sopperire alle mancanze del primo e all’insuccesso della fase 3.


56/111

Ogni parte del progetto è stata formata da sottofasi di analisi, progettazione, sviluppo e verifica, trattando ogni fase come la realizzazione di un progetto a se stante e non dimenticando mai di favorire l’espandibilità e il riutilizzo del codice già scritto. Per ogni modulo sono stati creati o aggiornati i documenti relativi (in particolar modo manuale tecnico e manuale operativo) e sottoposti a sessioni di verifica per poi essere completati a stage concluso.

Il grafico mostra la differenza tra impegno orario in preventivo e in consuntivo, per ogni fase dello sviluppo del progetto:

Analisi: questa fase ha richiesto un impegno inferiore rispetto alle aspettative: data la sua natura più “superficiale” rispetto alla progettazione è stata dedicata più al progetto nella sua interezza che alle singole fasi. Inoltre, avendo il progetto dei requisiti semplici da analizzare, il lavoro di questa fase è stato inferiore e non ha riguardato in particolare gli algoritmi impiegati (che costituiranno successivamente la quasi totalità del progetto);

Progettazione: questa fase ha bene o male rispettato le aspettative. Il tempo impiegato in questa attività è stato impiegato soprattutto nella ricerca di strutture dati che non solo potessero facilmente essere integrate nel software aziendale ma che non richiedessero modifiche nello stesso e che permettessero una programmazione efficace degli algoritmi impiegati;

Sviluppo: questa fase ha richiesto un impiego di ore leggermente superiore a quello preventivato dal momento che alcuni algoritmi creati hanno portato ad uno sviluppo più lungo e anche un numero di bug superiore a quello previsto;


57/111

Validazione: questa fase è stata più lunga del previsto a causa di una forte esigenza di testare adeguatamente gli algoritmi, di testare tutti i possibili errori che un utente può commettere e di test conclusivi sull’integrazione del modulo più lunghi del previsto.

Complessivamente la realizzazione del modulo ha subito un ritardo di una settimana, con 60 ore di analisi, 100 di progettazione, 62 di sviluppo e 83 di verifica e validazione, per un impegno totale, quindi, di 305 ore lavorative.


58/111

Capitolo 5

Valutazioni retrospettive

Durante lo stage ho avuto modo di allargare le mie conoscenze teoriche riguardo agli applicativi gestionali e a tutte le problematiche ad essi legate quali i continui cambiamenti di parte del software per adattarlo ad eventuali nuove leggi o modifiche di leggi precedenti, la scelta del database più adatto, la strutturazione del database per renderlo il più possibile utile e prestante, i possibili errori che un utente può provocare, la multiutenza del software stesso, ecc.Inoltre lavorare in azienda mi ha fatto capire quanto sia importante una comunicazione costruttiva tra i diversi ruoli tipici dello sviluppo software, che permette di arrivare a nuove idee e quindi incrementare non solo il profitto di una azienda ma anche l’esperienza e resa personale.Sul lato pratico ho iniziato a fare i primi passi con il linguaggio FoxPro e con l’ambiente di sviluppo Visul FoxPro che, nonostante il suo sviluppo sia cessato nel 2004, è ancora molto usato nelle aziende o di videogames o di gestionali. In più Visual FoxPro è stato uno dei primi IDE ad essere utilizzati e, pur non essendo comodo come altri, mi ha fatto approfondire la conoscenza degli ambienti di sviluppo in generale. Questa conoscenza mi servirà sicuramente nel mondo del lavoro per uno sviluppo rapido, efficace e il più possibile privo di bug.Inoltre ho ampliato le conoscenze di C++ e soprattutto delle librerie Qt, le quali sono una potentissima aggiunta al linguaggio nativo e pongono una soluzione alle sue mancanze. Vista la sempre più crescente diffusione di queste librerie, il cui futuro pare essere molto roseo, spero di poterle riutilizzare anche nel mondo lavorativo contribuendo a dare semplicità e velocità a progetti futuri e diffondendo maggiormente il loro utilizzo.Nel complesso l’esperienza di stage è stata positiva, sia dal punto di vista umano, per il rapporto con i colleghi sempre disponibili e collaborativi, sia per l’argomento trattato, che ho sempre ritenuto interessante, sia per gran parte dell’organizzazione e funzionalità dell’ambiente di lavoro. Esso infatti di positivo mi ha lasciato la possibilità di sviluppare nuove conoscenze e approfondire quelle già ottenute ma, di contro, mi ha permesso di capire quali problemi e quali rischi comporti a volte una carente organizzazione progettuale.Per quanto riguarda la gestione personale del progetto di stage mi è stato particolarmente utile il corso di “Ingegneria del software”, che mi ha insegnato le metodologie necessarie per avere un approccio più ragionato, più strutturato, più critico e più consapevole allo sviluppo software. Utile è stato anche il corso di “Basi di dati 1” che mi ha insegnato tutte quelle problematiche inerenti lo sviluppo di una applicazione che lavora con un


59/111

database e a come tentare di risolverle in maniera veloce, efficace e precisa. Ho quindi potuto sperimentare come con le soluzioni di base insegnatemi si possano risolvere facilmente anche problemi molto complessi.Dal punto di vista aziendale e del lavoro svolto, lo sviluppo della prima parte del primo modulo può considerarsi ultimato poichè la ditta non desidera aggiungere altre funzionalità o peculiarità oltre a quelle già fornite dalla componente. Lo sviluppo della seconda parte del primo modulo, invece, non è finito perchè si ha in mente di estendere l’esportazione di dati importanti di “VisionSQL”. Per ora il componente sviluppato esporta soltanto le attività sotto forma di appuntamenti nei calendari di Outlook, ma si ha in mente di esportare anche le anagrafiche di tutti i contatti (dipendenti, rivenditori, acquirenti, clienti...). Tuttavia non è da escludere l’esportazione anche di altri dati in Outlook quali eventuali uscite dei tecnici sotto forma di appuntamenti, la possibilità di mandare e-mail a tutti i contatti all’interno di un certo gruppo, la possibilità di redigere veri e propri diari per ogni singolo contatto. Il primo modulo verrà inserito in una delle prossime release di “VisionSQL” visto che fin dal momento della presentazione è stato ritenuto molto utile, pronto per la pubblicazione e di facile integrazione con il resto del software.Il secondo modulo invece, seppur completamente funzionante, è stato considerato dall’azienda come un primo passo di un progetto ben più ampio che verrà piano piano ampliato dagli stessi dipendenti o da futuri stagisti. Infatti l’azienda ha innanzitutto in mente di estendere le funzionalità di “VisionSync” in modo da consentire anche la sincronizzazione da remoto e successivamente dare la possibilità all’utente di far funzionare il modulo anche con Microsoft Exchange. Esso per ora non verrà inserito immediatamente in una futura release di “VisionSQL” per vari motivi, fra tutti:- l’azienda deve innanzitutto capire se il progetto che ha in mente possa essere

effettivamente utile all’utente e se lo sviluppo del progetto sta andando nella direzione desiderata;

- essendo un software esterno ed indipendente, l’azienda deve decidere se venderlo separatamente, se venderlo con qualche altro software o se renderlo disponibile gratuitamente;

- l’azienda deve decidere se allo stato attuale il software possa già essere utilizzato dall’utente finale, se gli possa essere utile o se il software abbia bisogno di funzionalità aggiuntive per stimolare l’utente al suo utilizzo.


60/111

Bibliografia

(I) Nuovo corso di informatica: basi di dati e sistemi informativi di G. Callegarin, CEDAM, 2003

(II) Visual FoxPro http://msdn.microsoft.com/en-us/vfoxpro/default.aspx sito ufficiale di FoxPro

(III) Visual FoxPro http://www.foxitaly.com/ sito della community italiana di FoxPro

(IV) Qt4.5 by Nokia http://qt.nokia.com/ sito ufficiale delle librerie Qt

(V) Dispense del corso di Ingegneria del Software http://www.math.unipd.it/~tullio/IS-1/

(VI) Concepts in programming languages di J. Mitchell, Cambridge Univ. Press, 2003

(VII) Documentazione aziendale di “VisionSQL” di Vision Software House

(VIII) Unified Modeling language (UML) http://www.uml.org/ di OMG (Object Management Group)

(IX) Wikipedia http://www.wikipedia.org

(X) Documentazione relativa allo stage ---> Analisi dei requisiti, Specifica tecnica, Definizione del prodotto e Glossario


61/111

http://msdn.microsoft.com/en-us/vfoxpro/default.aspx




http://www.foxitaly.com

http://www.foxitaly.com

http://qt.nokia.com

http://qt.nokia.com

http://www.math.unipd.it/~tullio/IS-1/




http://www.uml.org

http://www.uml.org

http://www.uml.org

http://www.uml.org

http://www.wikipedia.org

http://www.wikipedia.org

Appendice A

Lista dei requisiti primo modulo

Elenco di abbreviazioni:

L ---> logica di funzionamento

G ---> grafica

O ---> obbligatorio

D ---> desiderabile

P ---> opzionale

F ---> funzionale

Q ---> di qualità

A ---> di ambiente

I ---> di interfacciamento

A.1 Requisiti funzionali

A.1.1 Obbligatori

• 01FO deve essere scritto un modulo che permetta di riportare le attività in un calendario temporale e che permetta di esportarle (pubblicare o rimuoverle) nei calendari di Microsoft Outlook (L+G);

• 02FO il modulo deve permettere di selezionare le attività da riportare nel grafico (L);

• 03FO il modulo deve visualizzare correttamente i dati sul grafico (G);

• 04FO il modulo deve dare le possibilità all’utente di inserire nell’anagrafiche dei contatti un riferimento ad un calendario di Outlook (L+G);


62/111

• 05FO il modulo deve dare la possibilità all’utente di decidere se una attività deve essere inserita o meno nel calendario (L+G).

A.2 Requisiti di qualità

A.2.1 Obbligatori

• 01QO il modulo, una volta integrato con il software aziendale, non deve presentare peggioramenti prestazionali (L);

• 02QO il modulo deve dare la possibilità all’utente di impostare il calendario nel quale verrà salvata l’attività (L+G);

•03QO il modulo deve dare la possibilità all’utente di decidere in che formato salvare l’attività (L).

A.2.2 Desiderabili

• 01QD il modulo deve presentare un miglioramento prestazionale quando ricava i dati dal database (L).

A.3 Requisiti di interfacciamento

A.3.1 Obbligatori

• 01IO il modulo deve essere integrabile con il software aziendale “VisionSQL”.


63/111

Lista dei requisiti secondo modulo

Elenco di abbreviazioni:

L ---> logica di funzionamento

G ---> grafica

O ---> obbligatorio

D ---> desiderabile

P ---> opzionale

F ---> funzionale

Q ---> di qualità

A ---> di ambiente

I ---> di interfacciamento

A.4 Requisiti funzionali

A.4.1 Obbligatori

• 01FO il modulo deve sopperire alle mancanze del primo, cioè deve fornire un servizio di sincronizzazione tra gli appuntamenti nei calendari di Outlook e le attività presenti nel database (L);

• 02FO il modulo deve dare la possibilità all’utente di configurare l’associazione tra calendario e database (L+G);

• 03FO il modulo deve dare la possibilità all’utente di configurare ogni quanti minuti egli vuole che la sincronizzazione sia effettuata (L+G);

• 04FO una volta configurato correttamente il modulo, esso non deve più disturbare l’utente o interferire con altri programmi (L);

• 05FO il modulo non deve terminare la sua esecuzione se sono in atto operazioni critiche quali la scrittura di dati nel database (L);


64/111

A.5 Requisiti di qualità

A.5.1 Obbligatori

• 01QO il modulo deve dare la possibilità all’utente di avere più di una associazione calendario/database (L+G);

• 02QO il modulo deve operare nel database di destinazione senza creare dati inconsistenti (L);

A.5.2 Desiderabili

• 01QD il modulo deve dare la possibilità all’utente di poter vedere in qualsiasi momento lo stato del processo di sincronizzazione;

• 02QD il modulo deve operare con un basso utilizzo di risorse e in tempi ragionevoli, in modo da non utilizzare risorse utili a programmi più pesanti, come “VisionSQL” (L).

A.6 Requisiti di interfacciamento

A.6.1 Obbligatori

• 01IO il modulo deve essere in grado di interfacciarsi sia con Microsoft Outlook nelle sue versioni più recenti sia con il programma aziendale “VisionSQL” (L).


65/111

Appendice B

Specifica delle componenti primo modulo

B.1 Gestore Grafici/Calendari

B.1.1 Descrizione della componente

Tipo, obiettivo e funzione della componente

La classe “GestoreGrafici/Calendari” funge da classe base per tutto il primo modulo e, in base alle scelte dell’utente, intraprende una azione diversa. Essa infatti offre una aggiunta all’interfaccia grafica di “VisionSQL” che consente all’utente o di visualizzare il grafico temporale o di pubblicare/ eliminare le attività da Outlook.


66/111

Relazioni d’uso di altre componenti

La classe affida il disegno e la gestione dei grafici temporali alla classe “GestoreGrafici”. Inoltre affida la gestione delle attività/appuntamenti alla classe “GestoreCalendari”. Questa decisione è stata presa per semplificare il più possibile la classe base e per darle, così, nulla di più di una funzione di collegamento tra i due sottomoduli oltre che di aggiunta all’interfaccia grafica. Per gestire l’elenco delle attività essa utilizza un legame di aggregazione forte con la classe “Attività” e per gestire le varie connessioni al database, i vari caricamenti e i vari salvataggi usa una parte della classe “GestoreDB”.


La classe viene utilizzata dal software aziendale “VisionSQL” che ne crea una istanza ogni volta che l’utente chiede di avere una visualizzazione grafica delle attività. Ad ogni creazione di istanza il software provvede anche a creare le varie strutture dati utilizzate dalla classe.


Dopo la creazione di una istanza di questa classe all’utente viene presentata una finestra grafica nella quale compaiono tutte le attività restituite dal database. A questo punto egli può decidere se richiedere la visualizzazione del grafico temporale delle attività, creare una nuova attività, modificarne una esistente e collegarle o scollegarle con il calendario di Outlook. In base alla decisione dell’utente la classe chiamerà dei metodi differenti che utilizzeranno le corrette classi per gestire la richiesta dell’utente.

B.1.2 Campi dati

bottone_grafico: il bottone che l’utente preme per richiedere al modulo il disegno del grafico delle attività correntemente visualizzate.

bottone_filtri: il bottone che l’utente preme per richiedere l’apertura della finestra nella quale configurare come filtrare le attività. In sostanza il bottone chiama una funzione nativa di “VisionSQL”.

bottone_apertura: il bottone che l’utente preme per richiedere l’apertura della finestra nella quale poter vedere, modificare, aggiungere o rimuovere i dati dettagliati dell’attività.


67/111

bottone_salva: il bottone che l’utente preme per salvare tutte le attività precedentemente modificate e per chiudere la finestra di visualizzazione delle attività.bottone_annulla: il bottone che l’utente preme per chiudere la finestra delle attività senza salvare eventuali modifiche.

elenco_attività: la struttura dati che contiene l’elenco delle attività restituite dal database e visualizzate all’utente.

gestore_cal: il riferimento alla classe “GestoreCalendari”.

gestore_graf: il riferimento alla classe “GestoreGrafici”.

B.1.3 Metodi

GestoreGrafici/Calendari(): il costruttore che viene inizializzato da “VisionSQL” e costruisce la classe base del modulo.

caricaAttività(List (of Attività)): il metodo che apre la connessione con il database e lo interroga per ottenere le attività in esso presenti. L’elenco delle attività viene quindi ritornato come parametro.

visualizzaAttività(): il metodo che popola la finestra inserendo le attività da visualizzare all’utente. Successivamente fa comparire la finestra all’utente.

salvaAttività(): il metodo che salva le eventuali modifiche alle attività nel database. Restituisce “true” se il salvataggio è andato a buon fine, “false” se ha riscontrato un errore. Se viene restituito “true” il costruttore provvede a chiudere la finestra delle attività e a controllare se devono essere fatte delle pubblicazioni/rimozioni in Outlook.

disegnaGrafico(): il metodo che chiama i metodi della classe “GestoreGrafici” per disegnare i grafici temporali delle attività.

impostaFiltri(): il metodo che apre la finestra nella quale l’utente può inserire i filtri per visualizzare le attività secondo le sue esigenze. Questo metodo si limita a chiamare dei metodi nativi di “VisionSQL”.

apriAttività(): il metodo che apre la finestra dei dettagli dell’attività. Esso chiama un metodo nativo di “VisionSQL”. Ogni attività eventualmente modificata rimane in sospeso finchè l’utente non preme il bottone di salvataggio.

annulla(): il metodo che chiude la finestra di visualizzazione delle attività senza salvare eventuali modifiche.


68/111

B.2 GestoreCalendari



La classe “GestoreCalendari” è la classe utilizzata per gestire una eventuale pubblicazione o rimozione di un appuntamento legato ad una attività dal calendario di Outlook. A questa classe competono tutti i collegamenti con Outlook, la richiesta dell’attività da salvare o eliminare, la conversione in formato accettato dal calendario e la pubblicazione/rimozione.


La classe “GestoreGrafici/Calendari” ha una relazione di aggregazione forte con la classe “Attività” dal momento che deve gestire l’attività da esportare nel calendario di Outlook. Inoltre “GestoreCalendari” usa una parte della classe “GestoreDB” per gestire le varie connessioni al database e i vari caricamenti e la classe “APIOutlook” per comunicare direttamente con Outlook.


69/111

Interfacce con e relazioni d’uso da altre componentiQuesta classe ha una relazione di aggregazione forte con la classe base “GestoreGrafici/Calendari” che la usa per scaricarle tutto il lavoro riguardante la pubblicazione/rimozione di appuntamenti dal calendario di Outlook.


Come primo passo alla classe viene passato l’id dell’attività che essa dovrà ottenere dal database di “VisionSQL”. Una volta ottenuta, la classe analizza l’attività per capire se deve essere fatta una rimozione o una pubblicazione. Se deve essere fatta una rimozione, cerca nel calendario di Outlook se esiste un appuntamento con lo stesso id dell’attività e in caso di esito positivo chiama le API per eliminarlo. Se deve essere fatta una pubblicazione, la classe innanzitutto converte data e ora di inizio e fine in un formato accettabile da Outlook e successivamente testa se deve essere fatta una creazione o soltanto una modifica: nel primo caso chiama le API per pubblicare l’appuntamento, nel secondo caso cerca un appuntamento con lo stesso id dell’attività, lo elimina e poi pubblica un nuovo appuntamento.

B.2.2 Campi dati

attiv: il riferimento all’attività che deve essere analizzata per stabilire se deve essere pubblicata/rimossa.

check_modifica: il booleano che permette di capire se l’attività viene creata da 0 o se viene solo modificata.

B.2.3 Metodi

GestoreCalendari(int): il costruttore che riceve un intero indicante l’id dell’attività nel database. Questo id servirà poi per ottenere l’attività dal database.

ottieniAttività(): il metodo che richiede l’attività al database e la restituisce al costruttore.

analizzaAttività(): il metodo che analizza l’attività per vedere se l’appuntamento deve essere rimosso dal calendario di Outlook oppure deve essere pubblicato. In quest’ultimo caso il metodo controlla se l’attività è stata creata ex novo o soltanto modificata. Esso restituisce “true” se va effettuata una pubblicazione, “false” altrimenti.


70/111

pubblicaAttività(): i l metodo che provvede al la pubblicazione dell’appuntamento associato all’attività in Outlook con l’utilizzo delle API di quest’ultimo. Esso restituisce “true” se la pubblicazione è andata a buon fine, “false” altrimenti.

eliminaAttività(): il metodo che provvede alla rimozione dell’appuntamento associato all’attività da Outlook con l’utilizzo delle API di quest’ultimo. Esso restituisce “true” se la rimozione è andata a buon fine, “false” altrimenti.

trovaAttività(): il metodo che permette di trovare in uno dei calendari di Outlook un appuntamento con l’id identico a quello dell’attività. Restituisce la stringa contenente il link al calendario nel quale è stata trovata l’attività.

convertiDataOra(): il metodo che converte le date e le ore dell’attività in un formato accettabile da Outlook.

B.3 GestoreGrafici


71/111



La classe “GestoreGrafici” è la classe utilizzata per disegnare e gestire il grafico temporale delle attività. A questa classe compete infatti la comunicazione con gli oggetti OLE per la gestione grafica del grafico temporale.


La classe “GestoreGrafici” ha una relazione di aggregazione forte con la classe “Attività” dal momento che deve gestire tutta la lista di attività da rappresentare nel grafico. Inoltre utilizza la classe “OLEObject” per gestire la grafica del grafico temporale.


Questa classe ha una relazione di aggregazione forte con la classe base “GestoreGrafici/Calendari” che la usa per per scaricarle tutto il lavoro riguardante la gestione del grafico temporale delle attività.


Come primo passo la classe salva in una apposita struttura dati tutte le attività che verranno riportate nel grafico e che sono state selezionate dall’utente. Successivamente vengono analizzate in modo tale da scartare quelle senza data e vengono corrette le date sbagliate. Prima di essere inserite nel grafico le attività vengono inoltre adeguate secondo il modello voluto dalla componente OLE e vengono associate ad un colore indicante lo stato di evasione di queste. Terminate tutte queste operazioni di elaborazione, le attività vengono inserite nel grafico, che viene infine configurato o con le impostazioni di default o con le impostazioni volute dall’utente e visualizzato su schermo.

B.3.2 Campi dati

attiv: la struttura dati che contiene tutte le attività che verranno riportate nel grafico temporale


72/111

B.3.3 Metodi

GestoreGrafici(): il costruttore della classe che inizializza la struttura dati.

impostaListaAttività(list (of Attività)): il metodo che riceve come parametro la lista delle attività da riportare e le salva nell’apposita struttura dati.

pulisciAttività(): il metodo che elimina dalla lista le attività che hanno date inconsistenti o che sono senza data di inizio o fine.

correggiDate(): il metodo che corregge le date che MS SQL salva in maniera errata. Per esempio ogni volta che l’utente salva una data sbagliata, il database la trasforma in data “1/1/1900”. Questo metodo decide quindi se eliminare l’attività o modificare la data sbagliata.

riformattaAttività(): il metodo che formatta l’attività per adattarla al modello accettato dall’oggetto OLE che disegna il grafico. In più esso seleziona i campi dati che compariranno poi sotto forma di informazione nel grafico.

associaEvasione(): il metodo che in base alle date riportate nell’attività e alla data corrente del sistema decide lo stato di evasione dell’attività. In base a questo il metodo decide quindi con che colore far comparire l’attività nel grafico.

inserisciNelGrafico(): il metodo che a sua volta chiama il metodo dell’oggetto OLE per popolare il grafico con le attività ripulite, corrette e formattate.

configuraGrafico(): il metodo che effettua la chiamata al metodo dell’oggetto OLE passandogli i settaggi (di default o voluti dall’utente) per disegnare il grafico.

visualizzaGrafico(): il metodo che chiama il metodo dell’oggetto OLE per visualizzare il grafico (con relativa finestra).


73/111

Specifica delle componenti secondo modulo

B.4 Setup



La classe “Setup” funge da classe base per l’intero programma “VisionSync” e da base di collegamento tra la classe grafica, la classe dei file delle impostazioni e la classe che gestisce il thread di sincronizzazione.


La classe ha tre aggregazioni con altre classi dal momento che deve fare da collegamento tra la maggior parte delle classi vitali del sotfware. Ha una relazione di aggregazione debole con la classe “SLFile” poichè la utilizza per caricare le impostazioni dai file di configurazione o per salvare le impostazioni sui file. Ha una relazione di aggregazione debole con la classe “WinSetup” poichè la utilizza per inizializzare l’interfaccia grafica e per comunicarle eventuali informazioni che vogliono essere riportate all’utente (per esempio un aggiornamento sullo stato della sincronizzazione). H a u n a r e l a z i o n e d i


74/111

aggregazione debole con la classe “BaseThread” poichè la utilizza per avviare il thread di sincronizzazione, per fermarlo o per comunicargli le informazioni vitali per il corretto funzionamento del processo di sincronizzazione. Inoltre la classe eredita dalla classe “QWidget”, nativa delle librerie Qt, per poter gestire con semplicità e velocità le relazioni tra le varie classi di “VisionSync”.


Dal momento che la classe deve ricevere anche informazioni o richieste dalle varie componenti e utilizzarle o inoltrarle, essa ha una relazione di aggregazione debole con le classi “WinSetup” e “BaseThread”. In particolare la prima informa la classe riguardo ad eventuali modifiche o richieste dell’utente e la seconda informa la classe riguardo allo stato del processo di sincronizzazione. Inoltre, come in tutti i programmi scritti con il linguaggio C++, la classe viene creata ed invocata da una particolare funzione chiamata “Main”.

Attività svolte e dati trattati Appena il programma si avvia, la classe ottiene le impostazioni tramite il loro caricamento da file effettuato dalla classe “SLFile”. Se il caricamento non è andato a buon fine la classe si limita soltanto ad avviare l’interfaccia grafica segnalando all’utente la presenza di un errore, altrimenti avvia il thread di sincronizzazione e avvia l’interfaccia grafica. La classe offre anche i metodi per testare se i dati immessi dall’utente sono validi, per salvare eventuali suoi cambiamenti, per aggiornare la grafica in base allo stato del processo di sincronizzazione e per chiudere l’intero programma.

B.4.2 Campi dati

poiWS: il puntatore alla classe “WinSetup”.

poiSLF: il puntatore alla classe “SLFile”.

poiBT: il puntatore alla classe “BaseThread”.

dataFile: la struttura dati contenente tutte le configurazioni caricate dai file delle impostazioni.

syncTime: la variabile numerica contenente il tempo di sincronizzazione, cioè ogni quanto avviare il processo di sincronizzazione.


75/111

B.4.3 Metodi

Setup(): il costruttore della classe che viene invocato direttamente dalla funzione main. Ad esso spetta il compito di chiamare i metodi della classe che permettano di caricare le configurazioni dai file, avviare l’interfaccia grafica e avviare il processo di sincronizzazione.

~Setup(): il distruttore della classe. Questo metodo è tipico del linguaggio C++ ed è utilizzato alla chiusura del programma per cancellare tutti gli oggetti puntatori della classe dalla memoria.

loadSetup(): il metodo che richiede alla classe “SLFile” il caricamento delle configurazioni dagli appositi file sull’hard disk.

launchWin(): il metodo che richiede alla classe “WinSetup” l’avvio dell’interfaccia grafica.

testConfig(list (of QString)): il metodo che riceve come parametro una lista di stringhe dalla classe “WinSetup” e che la inoltra alla classe “BaseThread” per testare se i dati inseriti dall’utente sono corretti o no. Riceve quindi una risposta dalla classe del thread e restituisce alla classe grafica “true” se i dati immessi sono corretti, “false” altrimenti.

changeConfig(list (of QString),float)): il metodo che riceve come parametri una lista di stringhe e una variabile numerica dalla classe “WinSetup” e che le inoltra alla classe “SLFile” per salvarle nei file delle impostazioni e alla classe “BaseThread” per fermare il processo di sincronizzazione e ricominciarlo con i nuovi dati scelti dall’utente. Questo metodo restituisce alla classe grafica “true” se il thread è ripartito correttamente e se i settaggi sono stati salvati correttamente, “false” altrimenti.

signalProgress(int,int): il signal che viene invocato ogni volta che la classe “BaseThread” deve comunicare un aggiornamento riguardo allo stato del processo di sincronizzazione. Esso riceve due variabili numeriche, una indicante la percentuale di avanzamento del processo e l’altra la criticità dell’operazione in corso.

stopProg(): il metodo che viene invocato dalla classe “WinSetup” e termina l’intero software. Prima di terminare il programma si occupa di terminare il thread di sincronizzazione: se il thread sta eseguendo operazioni critiche il metodo attende che esse siano completate, se il thread sta eseguendo operazioni non critiche il metodo non attende il loro completamento e termina il thread.


76/111

B.5 WinSetup



La classe “WinSetup” è la classe che gestisce l’unica finestra grafica di tutto “VisionSync”. Ad essa quindi competono non solo l’aggiornamento visivo per l’utente dello stato di sincronizzazione ma anche la gestione di tutte le richieste e di tutti i cambiamenti che arrivano dall’utente.


La classe eredita dalla classe nativa della libreria Qt “QWidget” poichè deve gestire tutta la parte di disegno dell’interfaccia grafica e tutti i metodi principali delle Qt stesse. La classe ha anche una relazione di aggregazione debole con la classe “Setup” per poter comunicare a quest’ultima eventuali decisioni dell’utente riguardo a cambiamenti o test sulle impostazioni.


77/111


La classe ha una relazione di aggregazione debole con la classe “Setup” poichè da essa viene creata, da essa riceve aggiornamenti sullo stato della sincronizzazione e da essa viene chiusa.


Oltre alla creazione e alla visualizzazione dell’interfaccia grafica la classe non fa alcun altro lavoro salvo attendere un input dall’utente e comunicarlo alla classe “Setup” e ricevere informazioni sullo stato del processo di sincronizzazione e mostrarle all’utente.

B.5.2 Campi dati

poiSetup: il puntatore alla classe “Setup”.

act: l’oggetto della classe “Action”.

poiBoxLink: il puntatore all’oggetto “QGroupBox”.

poiBoxDb: il puntatore all’oggetto “QGroupBox”.

poiBoxSleep: il puntatore all’oggetto “QGroupBox”.

poiBoxState: il puntatore all’oggetto “QGroupBox”.

frameOne: il puntatore all’oggetto “QFrame”.

frameTwo: il puntatore all’oggetto “QFrame”.

frameThree: il puntatore all’oggetto “QFrame”.

poiLinkOne: il puntatore all’oggetto “QLineEdit”.

poiDbOne: il puntatore all’oggetto “QLineEdit”.

poiLinkTwo: il puntatore all’oggetto “QLineEdit”.

poiDbTwo: il puntatore all’oggetto “QLineEdit”.

poiLinkThree: il puntatore all’oggetto “QLineEdit”.


78/111

poiDbThree: il puntatore all’oggetto “QLineEdit”.

poiSyncTime: il puntatore all’oggetto “QDoubleSpinBox”.

poiProgress: il puntatore all’oggetto “QProgressBar”.

poiTrafficLight: il puntatore all’oggetto “QFrame”.

poiVerifyButton: il puntatore all’oggetto “QPushButton”.

poiSaveButton: il puntatore all’oggetto “QPushButton”.

poiQuitButton: il puntatore all’oggetto “QPushButton”.

trayIcon: l’oggetto della classe “QSystemTrayIcon”.

restoreAction: l’oggetto della classe “Action”.

quitAction: l’oggetto della classe “Action”.

trayMenu: l’oggetto alla classe “QMenu”.

B.5.3 Metodi

WinSetup(QWidget): il costruttore della classe che viene invocato dalla classe “Setup” quando si deve visualizzare l’interfaccia grafica. Come parametro esso riceve un riferimento nullo, utilizzato dalle librerie Qt per avviare la parte grafica.

~WinSetup(): il distruttore della classe. Questo metodo è tipico del linguaggio C++ ed è utilizzato alla chiusura del programma per cancellare tutti gli oggetti puntatori della classe dalla memoria.

loadWin(Setup,list (of QString), float): il metodo utilizzato per creare la struttura dell’interfaccia grafica. Esso riceve come parametri un riferimento alla classe base “Setup” in modo poi da poterle inviare eventuali cambiamenti voluti dall’utente, la lista dei settaggi caricati dal file e la variabile numerica contenente il tempo di sincronizzazione.

updateState(int,int): il metodo che si preoccupa di aggiornare l’utente riguardo allo stato del processo di sincronizzazione. Esso riceve come parametro una variabile numerica indicante la percentuale di avanzamento del processo e una variabile numerica indicante la criticità dell’operazione in corso. Il metodo quindi utilizza la prima inserendola nella barra grafica del progresso


79/111

e la seconda per decidere il colore del semaforo grafico. In particolare, il semaforo ha 5 colori:- bianco: il processo di sincronizzazione è funzionante ma al momento non sta

effettuando nessuna operazione;- verde: il processo di sincronizzazione sta effettuando una operazione con

criticità bassa;- giallo: il processo di sincronizzazione sta effettuando una operazione con

criticità media (quindi si può chiudere il programma ma sarebbe sconsigliato farlo);

- rosso: il processo di sincronizzazione sta effettuando una operazione con criticità alta (quindi il programma non si chiuderà finchè questa operazione non è terminata);

- nero: il processo di sincronizzazione non è funzionante a causa di qualche errore.

showWin(): il metodo utilizzato per visualizzare la finestra grafica in modalità normale.

hideWin(): il metodo utilizzato per chiudere la finestra grafica e renderla icona nella system tray di Windows.

checkFields(): il metodo utilizzato per controllare che l’utente abbia inserito tutti i campi, quindi per esempio che non abbia collegato un database ad un calendario o viceversa. Questo metodo non controlla quindi la correttezza dei dati inseriti, controlla solo la disposizione dei dati inseriti nell’interfaccia grafica.

setAction(): il metodo utilizzato per stabilire se, all’apertura di “VisionSync” la finestra debba essere visualizzata normalmente o ridotta ad icona. Se i settaggi letti dai file sono corretti e il thread funziona correttamente, il software si avvia ridotto ad icona per non disturbare l’utente.

closeEvent(): il metodo utilizzato per chiudere l’icona ed aprire la finestra grafica in modalità normale.

slotVerButton(): lo slot utilizzato per gestire la pressione del tasto di verifica. Esso chiama un metodo della classe “Setup” passandogli i settaggi da verificare letti dai campi dati della grafica e successivamente mostra all’utente l’esito della sua richiesta.

slotSaveButton(): lo slot utilizzato per gestire la pressione del tasto di salvataggio. Esso chiama un metodo della classe “Setup” passandogli i settaggi da salvare letti dai campi dati della grafica e successivamente mostra all’utente l’esito della sua richiesta.


80/111

slotQuitButton(): lo slot utilizzato per gestire la pressione del tasto di uscita. Esso chiama un metodo della classe “Setup” che si occuperà della terminazione del thread e della chiusura del programma.

setIcon(): il metodo utilizzato per impostare il titolo e l’icona della finestra.

iconActivated(QSystemTrayIcon): il metodo che permette di gestire “VisionSync” una volta che esso è ridotto ad icona.

showMessage(): il metodo che gestisce il baloon dell’icona di “VisionSync”.

B.6 SLFile



La classe “SLFile” è utilizzata per gestire il caricamento delle impostazioni dal file e i salvataggi delle impostazioni su file. Ad essa competono quindi tutti i collegamenti con i file presenti sull’hard disk e in caso di loro assenza la loro creazione.





81/111

La classe ha una relazione di aggregazione debole con la classe “Setup” dalla quale riceve le impostazioni da salvare su file o alla quale restituisce eventuali impostazioni caricate da file.


La classe viene invocata dalla classe “Setup” ogni volta che serve salvare o caricare i dati dai file presenti sull’hard disk. In particolare riceve le impostazioni da salvare sotto forma di lista di stringhe e un numerico oppure restituisce le impostazioni caricate sotto forma di lista di stringhe. Al termine delle operazioni chiude le connessioni con i file.

B.6.2 Campi dati

dSeString: la variabile contenente il nome del file dei settaggi per la connessione al database.

paOuString: la variabile contenente il nome del file dei settaggi per la connessione al calendario di Outlook.

sTiString: la variabile contenente il nome del file dei settaggi per il tempo di sincronizzazione.

B.6.3 Metodi

SLFile(): il costruttore della classe, utilizzato per impostare i nomi dei file.

loadFile(): il metodo utilizzato per leggere i settaggi dai file di configurazione. Restituisce una lista di stringhe contenente i dati letti.

saveFile(list (of string), float): il metodo utilizzato per salvare i settaggi sui file di configurazione. Come parametri riceve una lista di stringhe con i dati inseriti dall’utente e una variabile numerica sempre inserita dall’utente.


82/111

B.7 BaseThread



La classe “BaseThread” è la classe che gestisce tutto il processo di sincronizzazione tra il calendario di Outlook e il database di “VisionSQL”. Essa infatti è il thread che lavora indipendentemente dalle altre componenti del software e che funge da base tra la classe che si cura degli appuntamenti di Outlook e la classe che si cura delle attività del database. Proprio per questo motivo la classe è la seconda parte più importante del programma dopo la classe “Setup”.


Poichè il thread deve gestire una grande quantità di dati, deve metterli a confronto ed eventualmente sincronizzarli, si è pensato di alleggerire il lavoro della classe dividendolo con altre componenti del software. La classe ha quindi quattro relazioni di aggregazione debole con altre classi del software. Esse sono: - aggregazione debole con la classe “Setup” dal momento che deve informarla riguardo allo stato del processo di sincronizzazione;

- aggregazione debole con la classe “OutlookManager” dal momento che ognivolta che il processo di sincronizzazione viene avviato il thread deve ottenereda Outlook la lista di tutti gli appuntamenti presenti nel calendario;


83/111

- aggregazione debole con la classe “DatabaseManager” dal momento che il thread deve ottenere dal database di “VisionSQL” le attività ed eventualmente aggiornarle; - aggregazione debole con la classe “Appointment” dal momento che il threaddeve gestire una lista di appuntamenti da inviare poi alla classe che confronta ed eventualmente sincronizza le attività.Inoltre “BaseThread” eredita da “QThread” per poter usufruire di tutti i metodi e le strutture dati tipiche dei thread.


La classe ha una relazione di aggregazione debole con la classe “Setup” dal momento che è compito di quest’ultima creare il thread, fermarlo, modificare le impostazioni da esso utilizzate e metterlo in pausa.


Una volta avviato il thread, esso si comporta sempre seguendo lo stesso ciclo di azioni e cioè:- attesa per un certo periodo di tempo; - richiesta appuntamenti da Outlook; - richiesta attività dal database;-passaggio degli appuntamenti alla classe di competenza; - richiesta di effettuare il controllo per vedere se va effettuata la sincronizzazione; - richiesta di sincronizzazione; - rimozione strutture dati di appuntamenti e di attività. Al termine di ognuna

delle precedenti azioni il thread provvede ad emettere un segnale per aggiornare in tempo reale l’utente sullo stato di sincronizzazione.

B.7.2 Campi dati

lock: la variabile booleana utilizzata per indicare che sono in corso operazioni critiche.

errorOccurred: la variabile booleana utilizzata per indicare che sono avvenuti degli errori durante il processo di sincronizzazione.

dataFile: la lista di stringhe contenenti i nomi dei database e i calendari da sincronizzare.

syncTime: la variabile numerica indicante per quanto tempo il thread deve rimanere inattivo.


84/111

rifOutMan: il puntatore alla classe “OutlookManager”.

rifDbMan: il puntatore alla classe “DatabaseManager”.

dataFromOutlook: la l ista degli appuntamenti che la classe “OutlookManager” trova nei calendari di Outlook.

B.7.3 Metodi

BaseThread(list (of string), float, Setup): il costruttore della classe, invocato dalla classe base “Setup”. Come parametri riceve la lista dei calendari e dei nomi dei database da sincronizzare, la variabile numerica del tempo di sincronizzazione e il riferimento alla classe “Setup” in modo da poterle comunicare i cambiamenti di stato del processo di sincronizzazione.

~BaseThread(): il distruttore della classe. Questo metodo è tipico del linguaggio C++ ed è utilizzato alla chiusura del programma per cancellare tutti gli oggetti puntatori della classe dalla memoria.

run(): il metodo ereditato dalla classe madre “QThread” è il cuore della classe, dal momento che permette di eseguire ciclicamente una serie di operazioni fino a che un dato evento non avviene (in questo caso la richiesta di chiusura di “VisionSync”) senza bloccare altre parti vitali del programma quali l’interfaccia grafica.

testDb(list (of string)): il metodo chiamato dalla classe base “Setup” per verificare se i dati riguardanti il database sono corretti. Come parametro riceve la lista dei nomi dei database da verificare.

updateProgress(int, int): il signal utilizzato per avvertire la classe base riguardo ad un avanzamento di stato del processo di sincronizzazione. Esso riceve come parametri una variabile numerica indicante la percentuale di avanzamento e una variabile numerica indicante la criticità dell’operazione in corso.


85/111

B.8 OutlookManager



La classe “OutlookManager” è la classe utilizzata per richiedere ad Outlook gli appuntamenti presenti nei calendari. In sostanza chiama un altro file eseguibile che permette di creare un collegamento con le API di Outlook e creare dei file temporanei contenenti tutti gli appuntamenti di un dato calendario.


La classe ha una relazione di aggregazione debole con la classe “Appointment” poichè deve gestire una lista di appuntamenti caricati dai file temporanei.


La classe ha una relazione di aggregazione debole con la classe “BaseThread” dal momento che viene creata da quest’ultima e viene invocata ogni volta che devono essere ottenuti gli appuntamenti da Outlook.


86/111


Ogni volta che la classe viene invocata essa lancia il secondo file eseguibile e attende il suo completamento. Successivamente carica i dati dai file temporanei (creati dal secondo processo) e li organizza come appuntamenti che poi ritornerà alla classe “BaseThread”. Al termine delle operazioni di caricamento la classe provvede anche alla eliminazione dei file temporanei.

B.8.2 Campi dati

fileNameOne: la variabile contenente il nome del file degli appuntamenti del primo calendario.

fileNameTwo: la variabile contenente il nome del file degli appuntamenti del secondo calendario.

fileNameThree: la variabile contenente il nome del file degli appuntamenti del terzo calendario.

B.8.3 Metodi

OutlookManager(): il costruttore della classe, utilizzato per impostare i nomi dei file.

checkAppointment(): il metodo che esegue il subprocesso per estrarre gli appuntamenti dai calendari di Outlook e metterli in file temporanei e che successivamente legge i dati dai file e li restituisce al metodo chiamante.

removeFile(): il metodo che cancella i file temporanei dopo che i dati in essi contenuti sono stati prelevati.


87/111

B.9 Appointment



La classe “Appointment” funge da contenitore per tutti quei dati che costituiscono un vero e proprio appuntamento. Essi sono: - id dell’appuntamento (uguale a quello dell’attività presente nel database);- oggetto dell’appuntamento: - risorsa o dipendente che ha l’appuntamento;- note dell’appuntamento; - data di inizio dell’appuntamento; - ora di inizio dell’appuntamento; - data di fine dell’appuntamento; - ora di fine dell’appuntamento.Inoltre la classe è provvista di metodi che consentono all’appuntamento di cambiare il formato per adattarlo ad un eventuale confronto con il formato di una attività.




88/111


La classe ha una relazione di aggregazione debole con la classe “OutlookManager” e con la classe “BaseThread” dal momento che queste due hanno bisogno di gestire liste di appuntamenti.


Non appena viene invocato il costruttore della classe esso ha il compito di ottenere l’id dell’appuntamento dall’oggetto. Questa operazione viene effettuata poichè il primo modulo salva l’id dell’attività dentro il campo oggetto dell’appuntamento. Successivamente vengono convertite le date e le ore in un formato comparabile con quello ritornato da un database di tipo MS SQL. Al termine delle azioni sopra descritte l’appuntamento è pronto per essere confrontato.

B.9.2 Campi dati

id: la variabile numerica contenente l’id dell’appuntamento.

object: la variabile stringa contenente l’oggetto dell’appuntamento.

location: la variabile stringa contenente il luogo dell’appuntamento. Tuttavia questo campo è stato utilizzato per memorizzare la risorsa o il dipendente che ha l’appuntamento.

notes: la variabile stringa contenente le note dell’appuntamento.

startTime: la variabile stringa contenente la data di inizio dell’appuntamento.

startHour: la variabile stringa contenente l’ora di inizio dell’appuntamento.

endTime: la variabile stringa contenente la data di fine dell’appuntamento.

endHour: la variabile stringa contenente l’ora di fine dell’appuntamento.

B.9.3 Metodi

Appointment(string,string,string,string,string): il costruttore della classe utilizzato per inizializzare i campi dati dell’appuntamento e per ottenere l’id e le ore. Riceve cinque parametri, in modo tale da impostare l’oggetto, il luogo, le note, la data di inizio (con ora) e la data di fine (con ora) dell’appuntamento.


89/111

getId(): dal momento che il campo id è privato (per mantenere l’information hiding), il metodo restituisce il valore dell’id.

getObject(): dal momento che il campo oggetto è privato (per mantenere l’information hiding), il metodo restituisce la stringa dell’oggetto.

getLocation(): dal momento che il campo luogo è privato (per mantenere l’information hiding), il metodo restituisce la stringa del luogo.

getNotes(): dal momento che il campo note è privato (per mantenere l’information hiding), il metodo restituisce la stringa delle note.

getStartTime(): dal momento che il campo data di inizio è privato (per mantenere l’information hiding), il metodo restituisce la stringa della data di inizio.

getStartHour(): dal momento che il campo ora di inizio è privato (per mantenere l’information hiding), il metodo restituisce la stringa dell’ora di inizio.

getEndTime(): dal momento che il campo data di fine è privato (per mantenere l’information hiding), il metodo restituisce la stringa della data di fine.

getEndHour(): dal momento che il campo ora di fine è privato (per mantenere l’information hiding), il metodo restituisce la stringa dell’ora di fine.

transformDateForSQL(): il metodo che trasforma la data dal formato Outlook (formato misto con numeri e parole) al formato di MS SQL (formato solo di numeri).

changeInSQLDateTime(): il metodo che dalla data dell’appuntamento di Outlook estrae data e ora. La data verrà salvata nello stesso campo, l’ora verrà salvata nel campo apposito per l’ora.

obtainMonth(): il metodo che converte il mese da formato testuale a formato numerico.

obtainId(): il metodo che ottiene l’id dell’appuntamento dal campo oggetto.


90/111

B.10 DatabaseManager



La classe “DatabaseManager” è la classe utilizzata per gestire tutti i collegamenti con il database di “VisionSQL”, la connessione, la richiesta di dati e l’eventuale salvataggio sicuro. Questa classe inoltre effettua il controllo tra attività ed appuntamenti per stabilire se le attività non sono aggiornate e in caso di esito positivo sincronizza il database.


La classe ha una relazione di aggregazione debole con la classe “Activity” dal momento che deve gestire una lista di attività da confrontare ed eventualmente sincronizzare.


La classe ha una relazione di aggregazione debole con la classe “BaseThread” poichè da quest’ultima viene creata, invocata e da quest’ultima arrivano tutte le richieste di nuove azioni nel processo di sincronizzazione.


91/111


Appena viene creata la classe riceve la lista degli appuntamenti che dovranno essere confrontati e chiede al database la lista di tutte le attività presenti in esso. A questo punto vengono rimosse dalla lista tutte quelle attività il cui id non è stato trovato nella lista degli appuntamenti, vengono confrontate le attività con gli appuntamenti e vengono eventualmente eliminate dalla lista tutte quelle attività che non devono essere modificate nel database. Se al termine di queste operazioni la lista delle attività ha ancora degli elementi, essi vengono aggiornati e salvati in modalità sicura nel database. La sincronizzazione è quindi stata effettuata.

B.10.2 Campi dati

port: la stringa contenente il numero di porta per connettersi al database.

server: la stringa contenente il nome del server per connettersi al database.

dbName: la stringa contenente il nome del database al quale connettersi.

vecApp: la lista degli appuntamenti provenienti da Outlook da confrontare con le attività.

vecActivit: la lista delle attività provenienti dal database da confrontare con gli appuntamenti.

queryReturn: la stringa contenente il comando SQL da inviare al database.

B.10.3 Metodi

DatabaseManager(): il costruttore della classe, utilizzato per inizializzare i campi dati più importanti, quali la porta e il nome del server.

checkDb(string): il metodo utilizzato per verificare se il database esiste o meno. Riceve come parametro il nome del database da testare e restituisce la stringa contenente l’esito.

setData(string,list (of Appointment)): il metodo che inizializza il nome del database e la lista degli appuntamenti provenienti da Outlook. Esso riceve questi due dati come parametri.

getDataFromDb(): il metodo che ottiene tutte le attività presenti nel database e le inserisce nella lista delle attività


92/111

cleanDataFromDb(): il metodo che pulisce la lista delle attività rimuovendo quelle il cui id non è presente nella lista degli appuntamenti.compareActApp(): il metodo che confronta gli appuntamenti con le attività per vedere quali hanno subito modifiche. Se un appuntamento non ha subito modifiche viene rimosso dalla lista.

transformApp(): una volta ottenuti soltanto gli appuntamenti da salvare nel database, il metodo li trasforma in un formato accettabile da SQL.

writeInDb(): il metodo che scrive gli appuntamenti/attività nel database risincronizzando, quindi, Outlook e il database stesso.

obtainRegKey(): il metodo che analizza il registro di sistema di Windows e ottiene la chiave di registro per collegarsi al server MS SQL.

B.11 Activity



La classe “Activity” funge da contenitore per tutti quei dati che costituiscono una vera e propria attività. Essi sono: - id dell’attività (univoco del database); - oggetto dell’attività; - soggetto di chi o cosa deve svolgere l’attività;


93/111

-note dell’attività; -data di inizio dell’attività; - ora di inizio dell’attività; -data di fine dell’attività; - ora di fine dell’attività.Inoltre la classe è provvista di un metodo che permette di ottenere una data completa in formato numerico.

Relazione d’uso di altre componenti La classe non utilizza altre componenti di “VisionSync”


La classe ha una relazione di aggregazione debole con la classe “DatabaseManager” poichè questa deve gestire una lista di attività da confrontare con una lista di appuntamenti.


Una volta eseguito il costruttore esso setta i campi dati dell’attività con i dati passatigli e converte la data in un formato numerico. L’attività è quindi pronta per essere elaborata.

B.11.2 Campi dati

id: la variabile numerica contenente l’id dell’attività (univoco del database).

object: la variabile stringa contenente l’oggetto dell’attività.

subject: la variabile stringa contenente la risorsa o il dipendente che deve svolgere l’attività.

notes: la variabile stringa contenente le note dell’attività.

startDate: la variabile stringa contenente la data di inizio dell’attività.

startTime: la variabile stringa contenente l’ora di inizio dell’attività.

endDate: la variabile stringa contenente la data di fine dell’attività.

endTime: la variabile stringa contenente l’ora di fine dell’attività.


94/111

B.11.3 Metodi

Activity(int,string,string,string,string,string,string,string): il costruttore della classe, utilizzato per inizializzare i campi dati dell’attività. Riceve sette parametri, in modo tale da impostare l’id, l’oggetto, il soggetto, le note, la data di inizio, l’ora di inizio, la data di fine e l’ora di fine dell’attività.

getId(): dal momento che il campo dati id è privato (per mantenere l’information hiding), il metodo restituisce la stringa dell’id dell’attività.

getObject(): dal momento che il campo dati oggetto è privato (per mantenere l’information hiding), il metodo restituisce la stringa dell’oggetto dell’attività.

getSubject(): dal momento che il campo dati soggetto è privato (per mantenere l’information hiding), il metodo restituisce la stringa del soggetto dell’attività.

getNotes(): dal momento che il campo dati note è privato (per mantenere l’information hiding), il metodo restituisce la stringa delle note dell’attività.

getStartDate(): dal momento che il campo dati data di inizio è privato (per mantenere l’information hiding), il metodo restituisce la stringa della data di inizio dell’attività.

getEndDate(): dal momento che il campo dati data di fine è privato (per mantenere l’information hiding), il metodo restituisce la stringa della data di fine dell’attività.

obtainCompleteDate(): il metodo che unisce la data e l’ora (di inizio o di fine) in un unico campo dati, così da poterlo facilmente confrontare con quello degli appuntamenti.


95/111

Appendice C

Tracciamento della relazione componenti-requisiti (Specifica Tecnica)

La seguente tabella indica, per ogni componente del primo modulo, i requisiti che concorre a soddisfare.

Componente Requisito

GestoreGrafici/Calendari 01FO, 02FO, 04FO, 05FO, 02QO, 01IO

GestoreGrafici 01FO, 03FO, 01QO, 03QO, 01IO

GestoreCalendari 01FO, 05FO, 01QO, 02QO, 01QD, 01IO

La seguente tabella indica invece, per ogni componente del secondo modulo, i requisiti che concorre a soddisfare.


Setup 01FO, 02FO, 03FO, 05FO, 02QD

WinSetup 02FO, 03FO, 01QO, 01QD, 02QD

SLFile 02FO, 03FO, 01QO, 01QD, 02QD

BaseThread 01FO, 04FO, 05FO, 01QD, 02QD, 01IO

OutlookManager 01FO, 02QD, 01IO

DatabaseManager 01FO, 05FO, 02QO, 02QD, 01IO

Appointment 01FO, 02QD, 01IO

Activity 01FO, 05FO, 02QD, 01IO


96/111

Appendice D

Resoconto delle attività di verifica

D.1 Tracciamento componenti-requisiti (Qualifica)

D.1.1 Requisiti -> componenti

Le seguenti tabelle indicano per ogni sigla di requisito la sua origine, i diagrammi use-case dell’ “Analisi dei Requisiti”, le classi della “Specifica tecnica“ e la modalità di verifica che si intende adottare. Per facilitare la lettura i dati sono stati divisi in quattro tabelle: le prime due si riferiscono al primo modulo, le seconde due si riferiscono al secondo modulo.

Sigla requisito Origine Analisi dei requisiti

01FO Da capitolato Use-case A, use-case C, use-case D

02FO Da analisi interna Use-case A

03FO Implicito Use-case A, use-case C

04FO Da capitolato Use-case A


01QO Da analisi interna Non tracciabile

02QO Da capitolato Use-case A

03QO Implicito Use-case A, use-case B, use-case C, use-case D

01QD Da analisi interna Non tracciabile

01IO Da capitolato Non tracciabile


97/111

Sigla requisito Specifica tecnica Modalità di verifica

01FO GestoreGrafici/CalendariGestoreGraficiGestoreCalendari

Prova dinamica: test sulla corretta visualizzazione del grafico e sulla corretta visualizzazione delle attività e test sulla corretta pubblicazione/rimozione di attività da Outlook

02FO GestoreGrafici/Calendari Prova dinamica: test sul corretto ottenimento dei dati dal database sia senza che con filtri dellʼutente

03FO GestoreGrafici Prova dinamica: test sulla corretta visualizzazione delle attività nel grafico

04FO GestoreGrafici/Calendari Prova statica: test sul corretto inserimento (e riconoscimento da parte del modulo) di un link al calendario

05FO GestoreGrafici/CalendariGestoreCalendari

Prova statica: test sulla corretta impostazione (e riconoscimento da parte del modulo) della checkbox per esportare lʼattività

01QO GestoreGrafici/CalendariGestoreGraficiGestoreCalendari

Prova dinamica: test sullʼutilizzo delle risorse sia tramite accorgimento visivo che tramite strumenti di Windows

02QO GestoreGrafici/Calendari Prova statica: test sulla corretta visualizzazione (e riconoscimento da parte del modulo) del nome di un calendario di Outlook

03QO GestoreGrafici Prova dinamica: test sulla corretta esportazione del grafico in formati scelti dallʼutente

01QD GestoreGrafici/CalendariGestoreCalendari

Prova dinamica: test tra componenti native di “VisionSQL” e componenti del modulo


98/111


01IO GestoreGrafici/CalendariGestoreGraficiGestoreCalendari

Prova statica: test sulla corretta integrazione tra modulo e “VisionSQL”

Sigla requisito Origine Analisi dei requisiti



03FO Da analisi interna Non tracciabile

04FO Da analisi interna Use-case A

05FO Implicito Non tracciabile

01QO Da analisi interna Non tracciabile

02QO Da analisi interna Use-case A



01IO Da capitolato Use-case A


01FO Setup, WinSetup, BaseThread, DatabaseManager, OutlookManager

Prova dinamica: test sulla corretta sincronizzazione tra Outlook e database (visibile tramite “VisionSQL”).

02FO Setup, WinSetup, SLFile Prova statica/dinamica: test sul corretto inserimento di link al calendario e nome database. Test sul corretto salvataggio e sul corretto caricamento.


99/111


03FO Setup, WinSetup, SLFile Prova statica/dinamica: test sul corretto inserimento dei minuti di sincronizzazione. Test sul corretto salvataggio e sul corretto caricamento.

04FO BaseThread, OutlookManager, DatabaseManager

Prova dinamica: test sulla corretta procedura del processo di sincronizzazione.

05FO Setup, BaseThread Prova dinamica: test sulla non riuscita della chiusura di “VisionSync” durante fasi critiche.

01QO WinSetup Prova statica: test sulla corretta visualizzazione di tre campi dati per inserire nomi dei database e tre campi dati per inserire link al calendario.

02QO DatabaseManager Prova statica: test sul corretto funzionamento del metodo che blocca la tabella del database inerente alle attività.

01QD WinSetup, Setup, BaseThread

Prova dinamica: test sulla corretta visualizzazione e sulla corretta progressione della barra di stato del processo e sulla corretta colorazione del semaforo di stato.

02QD BaseThread, OutlookManager, DatabaseManager

Prova dinamica: test sul rapido svolgimento del processo di sincronizzazione in presenza di un numero alto di attività/appuntamenti.

01IO DatabaseManager, OutlookManager

Prova dinamica: test sul corretto ottenimento di attività dal database e di appuntamenti da Outlook.


100/111

D.1.2 Componenti->requisiti

La seguente tabella indica, per ogni componente del primo modulo, i requisiti che concorre a soddisfare.


GestoreGrafici/Calendari 01FO, 02FO, 04FO, 05FO, 02QO, 01IO

GestoreGrafici 01FO, 03FO, 01QO, 03QO, 01IO

GestoreCalendari 01FO, 05FO, 01QO, 02QO, 01QD, 01IO

La seguente tabella indica invece, per ogni componente del secondo modulo, i requisiti che concorre a soddisfare.


Setup 01FO, 02FO, 03FO, 05FO, 02QD

WinSetup 02FO, 03FO, 01QO, 01QD, 02QD

SLFile 02FO, 03FO, 01QO, 01QD, 02QD

BaseThread 01FO, 04FO, 05FO, 01QD, 02QD, 01IO

OutlookManager 01FO, 02QD, 01IO

DatabaseManager 01FO, 05FO, 02QO, 02QD, 01IO

Appointment 01FO, 02QD, 01IO

Activity 01FO, 05FO, 02QD, 01IO

D.2 Dettaglio delle verifiche tramite analisi

L’analisi verrà effettuata prevalentemente tramite i due debugger (uno di VisualFoxPro e uno di QtCreator). Tali strumenti infatti consentono di verificare che il codice non contenga errori di sintassi, che tutte le parti del programma siano effettivamente raggiungibili, che non siano presenti salti condizionali inutili e che variabili allocate dinamicamente non contengano valori illegali (soprattutto nel linguaggio C++). Per quanto riguarda invece la struttura del database, le sue tabelle e i dati in esse contenuti, si utilizzerà SQL Server Management Studio Express. Questo strumento grafico e di facile utilizzo consente infatti non solo di configurare il database velocemente ed


101/111

intuitivamente ma anche di seguirne il lavoro, di verificare la presenza di errori o stati inconsistenti e di capire quali problemi si presentano.Eventuali fallimenti durante le prove di analisi statica verranno trattati come discrepanze e verranno risolti come descritto nella sezione apposita.

D.3 Dettaglio delle verifiche tramite prove (test)

I test riguarderanno tutti l’accertamento del corretto comportamento delle funzionalità offerte dalle varie componenti dei due moduli. Le prove vengono fatte tenendo conto dei vincoli di dipendenza tra le classi. In caso di fallimento l’errore verrà trattato come anomalia o discrepanza a seconda della gravità.

D.4 Dettaglio dell’esito delle revisioni

La seguente tabella riporta un resoconto delle prove effettuate sul primo modulo.

Nome componente

Tipo di test Esito atteso Esito ottenuto

GestoreGrafici/Calendari

Unità:test sul corretto ottenimento delle attività, sulla loro corretta visualizzazione, sul loro filtraggio.

Ricevimento delle giuste attività e loro visualizzazione. Funzionamento nellʼinserimento filtri e nellʼeliminazione filtri.

Ricevimento delle giuste attività e loro visualizzazione. Funzionamento nellʼinserimento filtri e nellʼeliminazione filtri.Successo.

GestoreGrafici

Unità:test sul corretto funzionamento del grafico, sulla sua corretta impostazione e visualizzazione.

Apertura finestra grafico, popolazione grafico corretta, impostazione configurazione corretta.

Apertura finestra grafico, popolazione grafico corretta, impostazione configurazione corretta.Successo.

GestoreCalendari

Unità:test sulla corretta pubblicazione delle attività in Outlook.

Corretta creazione dellʼappuntamento, corretta eliminazione dellʼappuntamento, corretta modifica dellʼappuntamento.

Corretta creazione dellʼappuntamento, corretta eliminazione dellʼappuntamento, corretta modifica dellʼappuntamento.Successo.


102/111

La seguente tabella riporta invece un resoconto delle prove effettuate sul secondo modulo.

Nome componente


SLFile Unità:test sul corretto salvataggio e caricamento dei file.

Lettura e scrittura da/su file corretta.

Lettura/scrittura da/su file corretta.Successo.

WinSetup Unità:test sulla corretta creazione dellʼinterfaccia grafica, sulla corretta popolazione dei campi dati, sul corretto funzionamento dei bottoni e sulla corretta visualizzazione della barra di progresso.

Campi dati popolati correttamente, campi dati modificabili, pulsanti funzionanti, barra del progresso e semaforo correttamente aggiornati.

Campi dati popolati correttamente, campi dati modificabili, pulsanti funzionanti, barra del progresso e semaforo correttamente aggiornati.Successo.

Setup Integrazione:test sulla corretta comunicazione tra le classi WinSetup,BaseThread e SLFile.

Corretto passaggio dei dati tra le varie classi.

Corretto passaggio dei dati tra le varie classi.Successo.

BaseThread Integrazione:test sulla corretta comunicazione tra le classi OutlookManager,DatabaseManager.

Corretta serie di chiamate prima alla classe OutlookManager e successivamente alla classe DatabaseManager.

Corretta serie di chiamate prima alla classe OutlookManager e successivamente alla classe DatabaseManager.Successo.

OutlookManager Unità:test sul corretto ottenimento da Outlook dei dati caratterizzanti gli appuntamenti.

Corretta connessione ad Outlook, corretto ottenimento dei dati, corretto inserimento dei dati nella classe Appointment.

Corretta connessione ad Outlook, corretto ottenimento dei dati, corretto inserimento dei dati nella classe Appuntamento.Successo.


103/111

Nome componente


DatabaseManager

Unità:test sul corretto ottenimento dal database dei dati caratterizanti le attività. Test sul corretto confronto tra attività ed appuntamenti. Test sulla eventuale sincronizzazione.

Corretta connessione al database, corretto ottenimento dei dati,corretto inserimento dei dati nella classe Activity, corretto confronto, corretta sincronizzazione.

Corretta connessione al database, corretto ottenimento dei dati,corretto inserimento dei dati nella classe Activity, corretto confronto, corretta sincronizzazione. Successo.

Appointment Unità:test sulla corretta configurazione dellʼappuntamento e sulla corretta popolazione dei campi dati.

Corretta riproduzione di un appuntamento.

Corretta riproduzione di un appuntamento.Successo.

Activity Unità:test sulla corretta configurazione dellʼappuntamento e sulla corretta popolazione dei campi dati.

Corretta riproduzione di una attività.

Corretta riproduzione di una attività.Successo.

Durante la campagna di verifica è emerso che il primo modulo presentava un errore nell’inserimento delle date delle attività, anomalia che è stata presa in esame nelle modalità espresse nella sezione apposita. Ciò ha comportato l’inserimento di metodi e funzioni con lo scopo di garantire sempre il corretto inserimento di date e ore, in modo tale da non avere attività la cui data di fine sia anteriore a quella di inizio. Dopo questa modifica il modulo è stato verificato nuovamente e l’esito è stato positivo.Per quanto riguarda il secondo modulo, invece, è emersa una carenza progettuale nell’ottenere gli appuntamenti da Outlook. Anche questa anomalia è stata presa in esame nelle modalità espresse nella sezione apposita. Dopo una lieve modifica progettuale, che ha portato alla creazione di un secondo eseguibile per risolvere il problema, si è proceduto alla codifica e alla successiva verifica delle parti modificate, che ha quindi mostrato l’esito positivo.


104/111

Appendice E

Pianificazione ed esecuzione del collaudo

Una volta completato, il prodotto verrà sottoposto ad una serie di test intensivi, volti ad accertarne il corretto funzionamento.

E.1 Specifica della campagna di validazione (collaudo incluso)

E.1.1 Requisito -> Modalità

Primo modulo

Requisito Modalità

01FO Test di validazione delle regole imposte dal capitolato

02FO Test di validazione della corretta selezione delle attività e del corretto utilizzo di esse

03FO Test di validazione della corretta visione del grafico

04FO Test di validazione del corretto inserimento di collegamenti ad un calendario e loro successivo salvataggio

05FO Test di validazione della corretta interpretazione del valore immesso dallʼutente per testare se inserire o meno lʼattività nel calendario

01QO Test diretto di integrazione con il sistema aziendale.

02QO Test di validazione sulla corretta scrittura/lettura nel database dei dati immessi dallʼutente

03QO Test di validazione sul corretto formato di esportazione dellʼattività


105/111

Requisito Modalità

01QD Test diretto di integrazione con il sistema aziendale.

01IO Test diretto di integrazione con il sistema aziendale.

Secondo modulo

Requisito Modalità

01FO Test di validazione delle regole imposte da capitolato

02FO Test di validazione sulla corretta associazione tra calendario e database

03FO Test di validazione sulla corretta attesa per un tempo deciso dallʼutente

04FO Test di validazione sul funzionamento autonomo del thread di sincronizzazione

05FO Test di validazione sullʼassenza di dati inconsistenti nel database

01QO Test di validazione sulla corretta associazione tra calendario e database

02QO Test di validazione sullʼassenza di dati inconsistenti nel database

01QD Test di validazione sulla visualizzazione dello stato del processo di sincronizzazione

02QD Test diretto di integrazione con il sistema operativo e con i programmi in esso avviati

01IO Test diretto di integrazione con il sistema operativo e con i programmi in esso avviati


106/111

E.1.2 Modalità -> Requisiti

Primo modulo

Modalità Requisito

Test di validazione delle regole imposte dal capitolato 01FO

Test di validazione della corretta selezione delle attività e del corretto utilizzo di esse

02FO

Test di validazione della corretta visione del grafico 03FO

Test di validazione del corretto inserimento di collegamenti ad un calendario e loro successivo salvataggio

04FO

Test di validazione della corretta interpretazione del valore immesso dallʼutente per testare se inserire o meno lʼattività nel calendario

05FO

Test diretto di integrazione con il sistema aziendale. 01QO, 01QD, 01IO

Test di validazione sulla corretta scrittura/lettura nel database dei dati immessi dallʼutente

02QO

Test di validazione sul corretto formato di esportazione dellʼattività

03QO

Secondo modulo

Modalità Requisito

Test di validazione delle regole imposte da capitolato 01FO

Test di validazione sulla corretta associazione tra calendario e database

02FO, 01QO

Test di validazione sulla corretta attesa per un tempo deciso dallʼutente

03FO

Test di validazione sul funzionamento autonomo del thread di sincronizzazione

04FO

Test di validazione sullʼassenza di dati inconsistenti nel database

05FO, 02QO

Test di validazione sulla visualizzazione dello stato del processo di sincronizzazione

01QD

Test diretto di integrazione con il sistema operativo e con i programmi in esso avviati

02QD, 01IO


107/111

E.2 Dettaglio dell’esito della campagna di validazione

La campagna di validazione ha dato esito positivo per tutti i requisiti. Di conseguenza il prodotto costituito dai due moduli è stato presentato all’azienda che lo ha ritenuto un buon punto di partenza per sviluppi futuri del loro software aziendale.


108/111

Appendice F

Glossario

Calendario di Outlook: Il calendario è simile ad un'agenda cartacea, con il giorno (o i giorni) selezionati suddivisi per 30 minuti (impostazione che può comunque subire personalizzazioni da parte dell'utente). Facendo doppio click si accede alla finestra di creazione di un nuovo appuntamento che parte (l'orario dell'appuntamento) dal punto dove si è iniziato il doppio click fino a 30 minuti dopo (anche questa impostazione è modificabile). La finestra contiene i campi:

■ Oggetto: mini spiegazione visualizzata nella pagina del giorno■ Luogo: luogo dove si ha l'appuntamento■ Data e Ora (d'inizio e di fine): rispettivamente la data e ora d'inizio e di

fine dell'appuntamento (oppure esiste l'impostazione "Giornata intera" per inserire un appuntamento che occupa una giornata)

■ Categoria: qui si può selezionare una o più categoria di appartenenza dell'appuntamento

■ Mostra periodo come: per visualizzare il periodo come occupato, provvisorio, fuori sede o disponibile

■ Promemoria: attiva un messaggio di avvertimento dell'inizio dell'appuntamento visualizzato 15 minuti prima (valore modificabile).

Classe: nella programmazione orientata agli oggetti una classe è un costrutto di un linguaggio di programmazione usato come modello per creare oggetti. Il modello comprende attributi e metodi che saranno condivisi da tutti gli oggetti creati. Una classe può rappresentare una persona, un luogo oppure una cosa, ed è quindi l'astrazione di un concetto implementata in un programma per computer. Fondamentalmente essa definisce al proprio interno lo stato ed il comportamento dell'entità di cui è rappresentazione. I dati che descrivono lo stato sono memorizzati nelle variabili membro, mentre il comportamento è descritto da blocchi di codice riutilizzabile chiamati metodi.

Costante: termine il cui valore non cambia nel corso dell’esecuzione di un codice. Nel contesto del modulo assume la forma di un valore scritto direttamente, come ad esempio “abcd”, stringa costante di valore “abcd” oppure 5, intero costante di valore “5”.


109/111

Database: un archivio strutturato in modo tale da consentire la gestione dei dat i ( l ' inserimento, la r icerca, la cancel lazione ed i l loro aggiornamento) da parte di applicazioni software. Il database è un insieme di informazioni, di dati che vengono suddivisi per argomenti in ordine logico (tabelle) e poi tali argomenti vengono suddivisi per categorie (campi). Informalmente e impropriamente, la parola "database" viene spesso usata come abbreviazione dell'espressione Database Management System(DBMS), che si riferisce a una vasta categoria di sistemi software che consentono la creazione e la manipolazione efficiente di database.

Metodo: in programmazione, un metodo di una particolare classe consiste in una procedura richiamabile da istanze di quella stessa classe o di una sua derivata. In genere, il metodo viene definito all'interno del corpo della classe di cui l'oggetto è istanza a run-time.

In genere la definizione di un metodo usa la stessa sintassi impiegata per le procedure (nei linguaggi object-oriented che le supportano), con alcuni indicatori aggiuntivi che consentono di ottenere l'incapsulamento delle informazioni. Molti linguaggi supportano le tecniche di overloading e/o overriding dei metodi.

Outlook: è un programma di Microsoft Corporation e fa parte della suite Microsoft Office. Il software funge da PIM e da client di posta. Più precisamente contiene:■ Un calendario■ Una agenda delle attività■ Le note■ Il diario■ Contatti (rubrica)■ Posta elettronica

Parola chiave: parola facente parte di un particolare linguaggio, indica la presenza di costrutti o operazioni, e non può essere utilizzata se non per la funzione per la quale è stata concepita. Ad esempio “if”, “then”, “else” ecc.

Path: nome che contiene in forma esplicita le informazioni relative alla collocazione di un file all’interno di un file system oppure la locazione di un calendario all’interno di Outlook. Tipicamente il path (o pathname) possiede una struttura gerarchica ad albero.

Pattern: nell'ingegneria del software, un design pattern (struttura di progettazione) può essere definito "una soluzione progettuale generale a un problema ricorrente". Esso non è una libreria o un componente di


110/111

software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software. La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software.

Sincronizzazione: nel contesto di questo modulo è il processo che permette di aggiornare il database di “VisionSQL” quando un appuntamento in Outlook viene modificato.

UML: acronimo di Unified Modeling Language. È un linguaggio di modellazione e specifica basato sul paradigma “Object-oriented”. UML è costituito da una collezione organizzata di diagrammi correlati, costruiti componendo elementi grafici ed elementi testuali, viene utilizzato, in questo contesto, per modellare classi, diagrammi di attività e casi d’uso.

Use-case: o casi d’uso, sono diagrammi dedicati alla descrizione delle funzioni o servizi che un dato sistema offre, così come sono percepiti dagli attori che interagiscono col sistema stesso. Tipicamente sono utilizzati per descrivere i requisiti funzionali di tale sistema.

Validazione: procedura che accerta, tramite un processo di identificazione seguito da un processo di parsing, se una stringa codificata è corretta sotto gli aspetti lessicale e sintattico.

Variabile: nel contesto del modulo è la parte di un codice espressa con una particolare sequenza di caratteri, che contiene un valore di un tipo definito tipicamente durante la sua dichiarazione.

VisionERP: software sviluppato da “Vision Software House” da vendere ad aziende o attività commerciali esterne. Esso è il predecessore di “VisionSQL”.

VisionSQL: software sviluppato da “Vision Software House” da vendere ad aziende o attività commerciali esterne. Esso è un software di gestione aziendale cioè in genere un pacchetto di moduli in grado di semplificare il controllo delle procedure aziendali. Sono inclusi componenti per la gestione della logistica, del magazzino, della produzione, della distribuzione, della forza vendite e delle relazioni con i clienti e i fornitori. Un numero sempre maggiore di piccole imprese adotta questo tipo di software per ottimizzare le proprie attività, dal momento che consente di gestire al meglio le potenzialità commerciali derivanti dall'espansione e dall'aumento della complessità dell'impresa.

VisionSync: nome utilizzato per chiamare il secondo modulo. E’ la crasi tra Vision e Synchronizer.


111/111

Documents

MIGLIORAMENTI NELLA GESTIONE DELLE ATTIVITÀ DI …