Successfully reported this slideshow.
UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI MATEMATICA E GEOSCIENZE
Corso di Laurea Magistrale in Informatica
curric...
Ai miei genitori
iv
Indice
INTRODUZIONE.......................................................................................................
v
2.2 Progettazione logica ..................................................................................................
vi
1
Introduzione
“In un'azienda, il controllo di gestione è quell’insieme di attività volte a guidare la gestione verso il
c...
2
 ASP.NET (linguaggio C#) nello sviluppo della parte back-end, e come Framework di
riferimento;
 MVC come pattern archi...
3
1 Analisi dei requisiti
1.1 Introduzione
Il capitolo “Analisi dei requisiti” presenta una precisa analisi del sistema in...
4
piano di vendita o di promozione di un determinato prodotto. Assiste inoltre la raccolta degli
ordini dei clienti evitan...
5
 l'utente accede all'applicativo attraverso un web browser installato su sistema operativo
Microsoft Windows, ma l’uten...
6
tracciare una nuova opportunità, il Manager assegna una percentuale di fiducia alla stessa; tale
parametro, detto Confid...
7
ovvero, i documenti sopracitati vengono costruiti effettuando una serie di operazioni di copia/incolla
su fogli di calco...
8
FIGURA 2 - SCENARIO ATTUALE
9
FIGURA 3 - ADOZIONE DEL SISTEMA IN ESAME
10
FIGURA 4 - CONFRONTO TRA I DUE SCENARI
Dopo una prima analisi si evince che le macro funzionalità che si richiedono all...
11
1.7 Requisiti funzionali
1.7.1 [UR_DOC] Documentazione di processo
1.7.1.1 [UR_DOC_01] Acquisizione della documentazion...
12
1.7.3 [UR_ROLE] Ruoli ed attori di processo
L'applicativo deve essere in grado di distinguere differenti ruoli utente s...
13
1.7.4 [UR_REP] Report
1.7.4.1 [UR_REP_01] Visualizzazione report allineamento
L'applicativo deve fornire all'utente un ...
14
In ogni diagramma che verrà esplicitato nei prossimi paragrafi si assumono le seguenti associazioni di
specializzazione...
15
1.8.3.2 Sottosistema INSERIMENTO
FIGURA 4 – SOTTOSISTEMA INSERIMENTO
1.8.3.3 Sottosistema GESTIONE FORECAST
FIGURA 5 – ...
16
1.8.3.4 Sottosistema CONSULTAZIONE
FIGURA 5 – SOTTOSISTEMA CONSULTAZIONE
1.8.4 Specifica dei casi d’uso
UC-01 Richiede ...
17
01 a partire dal punto 6.
Postconditions
Extensions Vedi Extensions UC-01.
UC-03 Inserimento dati SFA
Description Caric...
18
UC-06 Consulta Forecast Report
Description Consultazione del report Forecast Report.
L’attivazione dell’operazione avvi...
19
1.8.5.1 Diagramma 1 – Accesso al sistema
20
1.8.5.2 Diagramma 2 – Apertura Forecast
21
1.8.5.3 Diagramma 3 – Inserimento documentazione
22
1.8.5.4 Diagramma 4 – Consultazione report
1.9 Altri requisiti (non funzionali)
1.9.1 [UR_SUP] Supportabilità
L'applica...
23
L'applicativo deve presentare un'interfaccia utente semplice ed intuitiva, che permetta ad un utente
con conoscenze inf...
24
25
2 Progettazione
2.1 Progettazione concettuale
Una volta che tutti i requisiti sono stati raccolti e analizzati, il pass...
26
FIGURA 7 - SCHEMA INIZIALE DELLA BASE DI DATI
2.1.1 Analisi delle entità: attributi e chiavi primarie
BU
Nome
Nome che ...
27
Chiuso Stringa che indica se il Forecast è stato chiuso o meno.
SFA
Id
Identificativo di un determinato foglio di calco...
28
appartiene
Descrizione Associa ciascun utente alla propria BU.
Rapporto di cardinalità
1:N Ogni utente appartiene ad un...
29
partecipa
Descrizione
Associa i documenti SFA e CoGe ai clienti che compaiono nelle
commesse.
Rapporto di cardinalità
M...
30
Rimozione degli attributi composti
Lo schema non prevede attributi composti.
Rimozione degli attributi multivalore
L’un...
31
2.
3.
32
4.
5.
33
6.
7.
34
8.
9.
35
10.
36
Di seguito si presenta lo schema logico relazionale ottenuto.
FIGURA 9 - SCHEMA LOGICO RELAZIONALE DELLA BASE DI DATI
37
2.3 Architettura del software
2.3.1 Introduzione: architetture a tre livelli
Nella progettazione ed implementazione di ...
38
In particolare, ASP.NET MVC rapprenta un modello di programmazione all’interno del Framework di
sviluppo web ASP.NET ch...
39
FIGURA 11 - ARCHITETTURA DEL SISTEMA
Ogni livello (e quindi ogni progetto) rappresenta una porzione significativa del p...
40
1. Allineamento SFA-CoGe, documentazione non inserita
FIGURA 12 - ALLINEAMENTO SFA-COGE (DOCUMENTAZIONE NON INSERITA)
2...
41
3. Allineamento SFA-CoGe, foglio Confronto
FIGURA 14 - ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO
42
4. Allineamento SFA-CoGe, foglio Componenti offerta
FIGURA 15 - ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA
43
5. Forecast report
FIGURA 16 - FORECAST REPORT
44
6. Chiusura Forecast
FIGURA 17 - CHIUSURA FORECAST
2.5 Valutazione del template grafico
In questa fase l’azienda ha ric...
45
3 Implementazione
Segue la descrizione dei moduli principali che compongono il sistema. Tutti i moduli che verranno
pre...
46
informazioni memorizzate in un directory service su una connessione TCP, tipicamente attraverso la
porta 389. I dettagl...
47
FIGURA 20 - ACTIVE DIRECTORY SEARCHES INTERFACES
In questa circostanza si è scelto di avvalersi delle interfacce ADSI f...
48
Una volta stabilita la connessione e istanziata la classe DirectorySearcher è possibile impostare un
filtro sulla ricer...
49
3.2.2 SpreadsheetML
Un documento SpreadsheetML è composto di una sezione centrale detta workbook e di più sezioni
separ...
50
FIGURA 24 - ESEMPIO DI FORMULA
La memorizzazione di stringhe segue invece una procedura di ottimizzazione che prende il...
51
FIGURA 26 - ESEMPIO DI INDICIZZAZIONE DELLE STRINGHE
Come si può notare dalla Figura 26, gli elementi riga e cella sono...
52
 utilizzare lo stesso metodo per la lettura di entrambi i documenti (SFA e CoGe);
 riuscire a far fronte a piccole va...
53
Segue quindi la creazione di una DataTable il cui numero di righe e colonne corrisponda esattamente
alle dimensioni del...
54
3.3 Report mediante le librerie Kendo UI
Telerik Kendo UI è una libreria basata su HTML 5 e jQuery che agevola lo svilu...
55
FRAMMENTO DI CODICE 7 - AUTOCOMPLETE KENDO UI WRAPPER
Tale codice, inserito all’interno di una pagina .cshtml16
, defin...
56
3.3.4 Grid widget
In più sezioni dell’applicativo sono stati inseriti dei report che si avvalgono del widget Grid. Tale...
57
FRAMMENTO DI CODICE 10 - GRID WRAPPER CHE REALIZZA IL REPORT COMPONENTI OFFERTA
Particolare importanza riveste l’utima ...
58
 il titolo di ogni colonna deve essere esposto in grasseto e al centro della colonna stessa;
 ogni titolo deve essere...
59
Anche in questo caso si segnala l’ultima riga del wrapper, che determina il tipo di data-binding
utilizzato. A differen...
60
1. Report Allineamento SFA-CoGe, foglio Confronto
FIGURA 32 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO
Lo screens...
61
Cliccando su uno dei Forecast della lista verranno presentati i report relativi a tale Forecast per la BU
selezionata. ...
62
La sezione in oggetto permette la chiusura del Forecast corrente. E’ possibile selezionare una data di
chiusura diversa...
63
7. Apertura nuovo Forecast
FIGURA 38 - APERTURA NUOVO FORECAST
Aprendo la sezione dedicata a tale scopo è possibile apr...
64
9. Inserimento documentazione (operazione avvenuta)
FIGURA 40 - INSERIMENTO DOCUMENTAZIONE (OPERAZIONE AVVENUTA)
Alla p...
65
FIGURA 42 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA (DIMENSIONI OTTIMALI)
Se ritenuto opportuno, è poss...
66
11. Inserimento documentazione (sovrascrittura)
FIGURA 44 - INSERIMENTO DOCUMENTAZIONE (SOVRASCRITTURA)
Nell’ipotesi in...
67
Si rileva dalla figura sottostante che spostando il cursore del mouse sopra una colonna si può
osservare la cifra rappr...
68
1. Test su dispositivo iPad mini(768x1024 px)
FIGURA 48 – REPORT CONFRONTO SU IPAD MINI (768X1024 PX)
Come si evince da...
69
FIGURA 49 - INSERIMENTO DOCUMENTAZIONE SU IPAD MINI (768X1024 PX)
70
FIGURA 50 - REPORT COMPONENTI OFFERTA SU IPAD MINI (1024X768 PX)
Ruotando il dispositivo la sidebar ricompare in quanto...
71
1. Test su dispositivo Nokia Lumia(480x800 px)
FIGURA 51 - APERTURA FORECAST SU NOKIA LUMIA (480X800 PX)
72
FIGURA 52 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX)
FIGURA 53 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX)
73
4 Conclusioni
4.1 Obiettivi
L’obiettivo del progetto di tesi prevedeva la progettazione e realizzazione di un’applicazi...
74
Si ipotizza che altri possibili sviluppi potranno derivare dall’introduzione di alcune variazioni sul
processo di monit...
75
5 Bibliografia
Allen Scott, 2012. Pluralsight - Building Applications with ASP.NET MVC 4. [Online course]
Available at:...
76
Vugt, W. v., 2007. Open XML The markup explained. [Online]
Available at: http://openxmldeveloper.org/cfs-filesystemfile...
Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo...
Upcoming SlideShare
Loading in …5
×

Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione

779 views

Published on

Il lavoro di tesi si colloca nell’ ambito del web development; l’obiettivo è la progettazione e realizzazione di un’applicativo web da inserirsi nel processo di controllo di gestione aziendale. Le funzionalità svolte attengono al caricamento di dati aziendali su una struttura dati di supporto e alla conseguente consultazione di specifici report (in formato grafico e tabellare), regolando al tempo stesso l’accesso e le funzionalità messe a disposizione degli utenti finali. Il progetto è stato sviluppato nel contesto di un tirocinio aziendale durante il quale è stata rilevata l’esigenza di uno strumento software che realizzi le funzionalità sopracitate. Le motivazioni che hanno spinto ad intraprendere questo lavoro si riscontrano nel fatto che l’azienda in oggetto non dispone di alcun sistema che svolga i compiti sopraelencati, risulterebbe quindi utile sperimentarne l’adozione. L’applicativo è stato realizzato all’ interno del Framework Microsoft .NET avvalendosi del pattern architetturale ASP.NET MVC. La gestione della base di dati avviene attraverso il DBMS SQL Server, gli utenti vengono autenticati su Active Directory; sono state utilizzate, inoltre, le librerie di supporto OpenXML SDK, Bootstrap e Kendo UI.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione

  1. 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE DIPARTIMENTO DI MATEMATICA E GEOSCIENZE Corso di Laurea Magistrale in Informatica curriculum Ingegneria Informatica Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione Anno Accademico 2012/2013 LAUREANDO Francesco Polita RELATORE Prof. Alberto Bartoli CORRELATORE Dott. Dario Sottana
  2. 2. Ai miei genitori
  3. 3. iv Indice INTRODUZIONE................................................................................................................. 1 1 ANALISI DEI REQUISITI ............................................................................................... 3 1.1 Introduzione........................................................................................................................................3 1.2 Descrizione generale del sistema.........................................................................................................3 1.3 Definizioni ...........................................................................................................................................3 1.4 Vincoli e prerequisiti............................................................................................................................4 1.4.1 Vincoli di progetto ................................................................................................................................. 4 1.4.2 Prerequisiti ............................................................................................................................................ 5 1.5 Contesto..............................................................................................................................................5 1.5.1 Scenario di riferimento.......................................................................................................................... 5 1.5.2 Monitoraggio dell’allineamento............................................................................................................ 6 1.5.3 Collocamento del software.................................................................................................................... 6 1.6 Criticità/Rischi ................................................................................................................................... 10 1.7 Requisiti funzionali ............................................................................................................................ 11 1.7.1 [UR_DOC] Documentazione di processo ............................................................................................. 11 1.7.2 [UR_FC] Gestione Forecast.................................................................................................................. 11 1.7.3 [UR_ROLE] Ruoli ed attori di processo ................................................................................................ 12 1.7.4 [UR_REP] Report.................................................................................................................................. 13 1.8 Modello dei casi d’uso ....................................................................................................................... 13 1.8.1 Premessa ............................................................................................................................................. 13 1.8.2 Attori.................................................................................................................................................... 13 1.8.3 Diagrammi dei casi d’uso..................................................................................................................... 13 1.8.4 Specifica dei casi d’uso ........................................................................................................................ 16 1.8.5 Diagrammi delle attività ...................................................................................................................... 18 1.9 Altri requisiti (non funzionali)............................................................................................................ 22 1.9.1 [UR_SUP] Supportabilità...................................................................................................................... 22 1.9.2 [UR_USA] Usabilità .............................................................................................................................. 22 1.9.3 [UR_AFF] Affidabilità ........................................................................................................................... 23 1.10 Requisiti della base di dati................................................................................................................. 23 2 PROGETTAZIONE...................................................................................................... 25 2.1 Progettazione concettuale................................................................................................................. 25 2.1.1 Analisi delle entità: attributi e chiavi primarie .................................................................................... 26 2.1.2 Analisi delle associazioni: descrizione, rapporto di cardinalità e attributi .......................................... 27
  4. 4. v 2.2 Progettazione logica .......................................................................................................................... 29 2.2.1 Ristrutturazione dello schema E-R....................................................................................................... 29 2.2.2 Schema logico relazionale ................................................................................................................... 30 2.3 Architettura del software .................................................................................................................. 37 2.3.1 Introduzione: architetture a tre livelli ................................................................................................. 37 2.3.2 ASP.NET MVC....................................................................................................................................... 37 2.3.3 Composizione delle architetture ......................................................................................................... 38 2.4 Progettazione interfaccia grafica ....................................................................................................... 39 2.5 Valutazione del template grafico....................................................................................................... 44 3 IMPLEMENTAZIONE ................................................................................................. 45 3.1 Autenticazione e recupero di informazioni su Active Directory ......................................................... 45 3.1.1 Architettura delle ricerche su Active Directory ................................................................................... 46 3.1.2 Modulo sviluppato............................................................................................................................... 47 3.2 Estrazione di dati da fogli di calcolo con OpenXML............................................................................ 48 3.2.1 Office Open XML.................................................................................................................................. 48 3.2.2 SpreadsheetML.................................................................................................................................... 49 3.2.3 OpenXML SDK...................................................................................................................................... 51 3.2.4 Modulo sviluppato............................................................................................................................... 51 3.3 Report mediante le librerie Kendo UI ................................................................................................ 54 3.3.1 Esempio: AutoComplete widget.......................................................................................................... 54 3.3.2 Modulo sviluppato............................................................................................................................... 55 3.3.3 Premessa ............................................................................................................................................. 55 3.3.4 Grid widget .......................................................................................................................................... 56 3.3.5 Chart widget ........................................................................................................................................ 58 3.4 Considerazioni................................................................................................................................... 59 3.5 Interfaccia prodotto finale................................................................................................................. 59 3.5.1 Presentazione user interface attraverso un caso di utilizzo................................................................ 59 3.5.2 Funzionalità non disponibili................................................................................................................. 67 3.5.3 Valutazione responsività ..................................................................................................................... 67 4 CONCLUSIONI .......................................................................................................... 73 4.1 Obiettivi ............................................................................................................................................ 73 4.2 Sviluppi futuri.................................................................................................................................... 73 4.3 Opinioni personali ............................................................................................................................. 74 4.4 Stato attuale...................................................................................................................................... 74 5 BIBLIOGRAFIA.......................................................................................................... 75
  5. 5. vi
  6. 6. 1 Introduzione “In un'azienda, il controllo di gestione è quell’insieme di attività volte a guidare la gestione verso il conseguimento degli obiettivi stabiliti in sede di pianificazione operativa, rilevando lo scostamento tra obiettivi pianificati e risultati conseguiti e informando di tali scostamenti gli organi responsabili, affinché possano attuare le opportune azioni correttive.”1 Il monitoraggio dell’andamento economico finanziario di un’azienda ha cadenza tipicamente mensile e si esplica in elaborati detti report. Si tratta di collezioni di dati, generalmente esposti in formato tabellare, in cui vengono messi a confronto dati economici, patrimoniali e finanziari a preventivo e a consuntivo. Il problema analizzato durante il lavoro di tesi concerne la metodologia adottata nell’elaborazione dei report e la sequenza di attività che compongono il processo di monitoraggio presso l’azienda in cui è stato sviluppato il progetto. In particolare, sono stati riscontrati i seguenti punti deboli.  L’attività di raccolta ed elaborazione di dati aziendali viene svolta manualmente, attraverso una sequenza di operazioni copia/incolla su fogli di calcolo.  Non sussiste alcuna forma di archiviazione strutturata delle informazioni.  L’intero processo richiede la trasmissione di una considerevole quantità di messaggi di posta elettronica contenenti dati sensibili. L’obiettivo di questo lavoro è progettare e realizzare un prototipo software che gestisca l’inserimento dei dati raccolti al fine di trasformarli in informazioni utili all’azienda:  classificando tali dati secondo specifici orizzonti temporali e divisioni aziendali;  rendendo persistenti tali dati con l’ausilio di un DBMS;  elaborando e presentando report utili ai fini del processo di monitoraggio. L’esigenza di creare tale prototipo è nata dal fatto che al momento l’azienda non dispone di uno strumento software che realizzi le funzionalità sopra indicate; risulterebbe quindi utile sperimentarne l’adozione. Infatti, oltre agli evidenti benefici che si trarrebbero evitando l’elaborazione manuale dei fogli di calcolo, l’introduzione di un applicativo accessibile via web favorirebbe la centralizzazione dell’intero processo, strutturando e rendendo maggiormente efficiente lo scenario attuale. Tali miglioramenti deriverebbero dalla riduzione del numero di operazioni che compongono il processo, dall’abbandono della trasmissione di dati aziendali via posta elettronica e dall’archiviazione strutturata e sistematica dei dati registrati. Il lavoro di tesi è stato svolto presso Cluster Reply S.r.l., società del gruppo Reply S.p.A., nelle sedi di Silea e di Trieste. La realizzazione del prototipo in oggetto ha previsto lo studio e l’utilizzo di diverse tecnologie legate allo sviluppo web, si citano le più rilevanti:  HTML5, CSS3 e javaScript nello sviluppo della parte front-end; 1 http://it.wikipedia.org/wiki/Controllo_di_gestione
  7. 7. 2  ASP.NET (linguaggio C#) nello sviluppo della parte back-end, e come Framework di riferimento;  MVC come pattern architetturale;  Active Directory nell’autenticazione degli utenti;  SQL Server nella gestione della base di dati;  alcune librerie di supporto tra cui OpenXML SDK, Bootstrap e Kendo UI. Si riporta di seguito una breve descrizione dei capitoli in cui è articolata la tesi. Il primo capitolo contiene l’analisi dei requisiti del sistema. Offre una prima descrizione dello strumento in questione, menzionando i vincoli di progetto ai quali ci si è attenuti, per poi addentrarsi nell’illustrazione del contesto di collocamento del software. Infine, viene presentata la lista dei requisiti raccolti, focalizzando l’attenzione sul modello dei casi d’uso. Il secondo capitolo descrive la fase di progettazione del sistema. In primis, viene riportata la progettazione della base di dati che si conclude con la presentazione dello schema logico relazionale ottenuto. Viene quindi trattata l’architettura del software e la progettazione dell’interfaccia grafica. Il terzo capitolo riporta l’implementazione dei principali moduli che compongono il sistema finale e a seguire l’esposizione dell’interfaccia utente. Nel quarto capitolo, infine, si delineano le conclusioni del lavoro svolto, valutando quanto realizzato sulla base degli obiettivi di progetto.
  8. 8. 3 1 Analisi dei requisiti 1.1 Introduzione Il capitolo “Analisi dei requisiti” presenta una precisa analisi del sistema in oggetto. Tale analisi è funzionale a stabilire che cosa il sistema deve fare e quali servizi deve fornire sulla base dei bisogni espressi dal committente. Le decisioni sul come deve realizzare tutto ciò, sono rimandate al capitolo di progettazione del sistema. La raccolta dei requisiti ha avuto luogo tramite una serie di interviste rivolte al mio tutor aziendale e al personale amministrativo di Cluster Reply i quali, rappresentando i destinatari del sistema, svolgono il ruolo di committente. Il capitolo si apre con una generica descrizione del sistema e del contesto in cui si troverà ad operare scendendo poi nel dettaglio dell’analisi dei requisiti che il prodotto finale deve soddisfare. Si consideri che l’approccio seguito per lo sviluppo del software è di tipo prototipale, quindi nuovi requisiti potranno essere introdotti successivamente, oltre a tutti i vincoli che fino a questo momento non sono ancora stati individuati. 1.2 Descrizione generale del sistema Il sistema, indicato nel seguito come software o applicativo, prevede mediante il suo uso, l’inserimento e la consultazione di dati aziendali via web. Tali dati, verranno resi persistenti con l’ausilio di una base di dati e, prima di essere presentati all’utente, saranno oggetto di elaborazioni matematiche indicate dal committente. L’utente accederà al sistema attraverso un qualsiasi dispositivo che disponga di un browser web e che sia connesso alla rete Internet. Effettuato l’accesso, potrà avvalersi delle funzionalità messe a disposizione dall’applicativo semplicemente muovendo il cursore del mouse e “cliccando” nelle apposite aree2 . In prima approsimazione, le funzionalità messe a disposizione dell’utente riguardano:  l’inserimento di dati aziendali;  la consultazione di report derivanti dall’elaborazione dei dati inseriti;  il filtraggio delle informazioni visualizzate in base a specifici criteri. 1.3 Definizioni  Utente (User): la persona, o le persone, che operano o interagiscono direttamente con l’applicativo.  Committente (Customer): la persona, o le persone, che acquistano il prodotto e di solito (ma non necessariamente) decidono i requisiti. Nel contesto di questa prassi raccomandata il committente e il fornitore possono essere membri della stessa organizzazione.  SFA (Sales Force Automation): l'acronimo SFA fa riferimento ad un software aziendale di supporto alle vendite. Il sistema SFA provvede alla comunicazione tra venditore e centrale operativa, programma e controlla l’azione dei venditori, li assiste nella messa a punto di un 2 Ovviamente se il dispositivo in questione è un dispositivo mobile il click del mouse (o del trackpad/touchpad) sarà sostituito dal tap del dito sullo schermo.
  9. 9. 4 piano di vendita o di promozione di un determinato prodotto. Assiste inoltre la raccolta degli ordini dei clienti evitando movimentazione cartacea, riducendo la possibilità d'errore umano e velocizzando l'arrivo dei dati relativi agli ordini nella sede centrale.  Budget: Strumento contabile di tipo preventivo; lo scopo del budget è quello di confrontare i dati preventivi con i dati consuntivi. Il budget si struttura su base annuale, ma viene diviso su periodi di tempo più brevi, nel caso in questione, viene monitorato e aggiornato mensilmente. Alla fine del mese si confronta il dato di budget con il risultato effettivo, se si riscontrano scostamenti possono essere adottate contromisure volte al miglioramento delle condizioni.  GeCo (Gestione Commesse): è un applicativo per la gestione e il controllo delle commesse. Lo scopo principale di GeCo è fornire un ambiente formale per la gestione e il controllo delle singole attività legate alla realizzazione di progetti o di consulenza. Consente ai capi progetto e a tutte le risorse aziendali coinvolte di monitorare e avere sotto controllo tutte le fasi di avanzamento e sviluppo delle commesse, l’evoluzione dei progetti, con relativi calcoli e consuntivi rispetto alle specifiche iniziali, dei gruppi di lavoro e della produzione. 1.4 Vincoli e prerequisiti 1.4.1 Vincoli di progetto 1.4.1.1 Tecnologie software Per quanto concerne l’ambiente di sviluppo l’azienda ha posto i seguenti vincoli:  ambiente Microsoft .NET Framework (versione 4), avvalendosi del design pattern Model- View-Controller (MVC) e del linguaggio di programmazione C Sharp (C#);  DBMS di supporto alla base di dati Microsoft SQL Server 2008 R2. Mentre per quel che riguarda l’ambiente di lavoro:  sistema operativo Microsoft Windows Server 2008 R2 virtualizzato;  IDE 3 Microsoft Visual Studio 2012 Professional. 1.4.1.2 Autenticazione Si assume come vincolo di progetto che il parco di utenze che possono essere abilitate all'accesso siano quelle disponibili all'interno del directory service Microsoft Active Directory e precisamente appartenenti al dominio REPLYNET. Ciò significa che un utente che non può essere autenticato su tale servizio non potrà accedere all’applicativo. In particolare, gli scenari che possono presentarsi sono tre:  l'utente accede all'applicativo attraverso un web browser installato su sistema operativo Microsoft Windows nel quale ha già ha effettuato il log-in con le proprie credenziali di dominio;  l'utente accede all'applicativo attraverso un web browser installato su sistema operativo diverso da Microsoft Windows; 3 Si tratta di un software di supporto ai programmatori in fase di sviluppo del codice sorgente di un programma. Per maggiori informazioni visitare http://en.wikipedia.org/wiki/Integrated_development_environment.
  10. 10. 5  l'utente accede all'applicativo attraverso un web browser installato su sistema operativo Microsoft Windows, ma l’utenza con la quale ha effettuato l’accesso non corrisponde ad un utenza nel domino REPLYNET. Nel primo caso, l'applicativo verificherà, in background, che le credenziali inserite nel dispositivo in uso identifichino l'utente su Active Directory, effettuerà quindi l’operazione che prende il nome di Windows Authentication. Nei restanti casi, il browser restituirà all’utente un form nel quale inserire le proprie credenziali. Tali credenziali, verranno poi verificate su Active Directory con la stesso protocollo previsto dalla Windows Authentication (NTLM o Kerberos). 1.4.1.3 Autorizzazione L’autenticazione dell’utente dovrà essere seguita dalla fase di autorizzazione. Ciò consentirà al sistema di determinare quali funzionalità e quali informazioni rendere disponibili all’utente. 1.4.1.4 Raggiungibilità L'applicativo deve essere raggiungibile via web. 1.4.2 Prerequisiti 1.4.2.1 Fruibilità L'applicativo deve essere fruibile con i più comuni browser di ultima generazione (Internet Explorer dalla versione 8.0 in poi), compresi i browser mobile. 1.5 Contesto 1.5.1 Scenario di riferimento Cluster Reply è una S.r.l. suddivisa in più Business Unit (BU), in ogni BU vi è un reparto Management all'interno del quale compaiono diversi profili di Manager organizzati secondo una scala gerarchica che parte dal "Senior Consultant" e raggiunge l'apice con il "Partner". Ogni Manager ha il compito di individuare nuovi clienti, offrire soluzioni, censire nuove opportunità di business, cercando di allinearsi con gli obiettivi di budget fissati a inizio anno. FIGURA 1 – SCHEMA STRUTTURA CLUSTER REPLY Ogni trattativa viene inizialmente delineata con l'ausilio del sistema informatico SFA, ciò permette di tener traccia di tutte le opportunità procurate da un Manager in un determinato periodo. Nel
  11. 11. 6 tracciare una nuova opportunità, il Manager assegna una percentuale di fiducia alla stessa; tale parametro, detto Confidence, indica la probabilità di accettazione della trattativa in corso da parte del cliente. Quando una commessa viene confermata dal cliente, la trattativa viene portata nel sistema GeCo, dove vengono raccolte informazioni più dettagliate riguardo a commessa e cliente. I dati registrati nel sistema GeCo vengono verificati e validati ogni mese in sede di Controllo di Gestione dal management di Cluster Reply. Nel foglio di calcolo (denominato CoGe) aggiornato mensilmente dall'amministrazione centrale (o da un Partner) vengono affiancate le commesse confermate e le opportunità aperte, pesate con il proprio grado di fiducia. Dall'unione dei dati contenuti in CoGe e SFA emerge un nuovo foglio di calcolo (denominato Allineamento SFA-CoGe) con finalità reportistica, utilizzato per misurare i risultati ottenuti e rilevare se gli obiettivi parziali4 assegnati siano stati effettivamente raggiunti da ogni BU. Mappando tali report su tutte le BU si ottiene un documento, che prende il nome di Forecast Report, il cui scopo è fornire una visione globale sull’andamento dell’azienda. Tale documento, permette di fare un confronto sull’allineamento tra i dati tracciati da entrambi i sistemi, SFA e CoGe. I dati raccolti durante questo processo, che prende il nome di “allineamento SFA CoGe”, vengono analizzati per evidenziare il trend sulle trattative economiche per ogni BU al fine di assicurare la coerenza con gli obiettivi di budget. 1.5.2 Monitoraggio dell’allineamento Lo scenario appena descritto richiede un monitoraggio periodico di quanto contenuto nel foglio di calcolo “allineamento SFA CoGe”, al fine di verificare che quanto tracciato nei sistemi SFA sia in linea con quanto dichiarato nel documento CoGe. I manager di ogni BU, allo scadere di ogni forecast5 , si preoccuperanno di aggiornare correttamente le opportunità tracciate nei sistemi SFA. Tale aggiornamento può riguardare diversi fattori, per citarne alcuni:  le percentuali di fiducia associate alle opportunità;  le date di chiusura delle trattative;  il valore economico associato alle trattative;  il ritardo sul tracciamento di una nuova opportunità. A modifiche avvenute, viene prodotto un nuovo foglio CoGe, che verrà utilizzato nell’elaborazione dei “Forecast report”. 1.5.3 Collocamento del software In questo contesto, il software da sviluppare si propone di rilevare e confrontare i dati provenienti da CoGe e SFA per realizzare quella funzionalità di reportistica attualmente ricoperta dai documenti Allineamento SFA-CoGe e Forecast report. Ad oggi, tale operazione viene svolta manualmente, 4 Con obiettivi parziali si vuole fare riferimento alla ripartizione su scala mensile degli obiettivi fissati a inizio anno. 5 Sono i forecast infatti a scandire l’attività di controllo e, sebbene la durata di ogni Forecast sia tipicamente di un mese, non è detto che il forecast coincida con inizio e fine del mese in corso.
  12. 12. 7 ovvero, i documenti sopracitati vengono costruiti effettuando una serie di operazioni di copia/incolla su fogli di calcolo, per poi essere inviati via posta elettronica ai Manager di ogni BU. Lo scopo finale del progetto è quindi strutturare e rendere maggiormente efficiente il processo di monitoraggio descritto attraverso l’introduzione dello strumento in oggetto. Risulta evidente che, strutturando e centralizzando il caricamento dei dati e l’elaborazione dei report, si evitano una discreta quantità di operazioni perlopiù ripetitive e i risultati vengono prodotti in modo istantaneo. Allo stesso tempo, si assolve al problema del mantenimento di uno storico relativo ai Forecast precedenti, cosa che oggi non avviene in modo strutturato. Si riportano di seguito le rappresentazioni grafiche che descrivono lo scenario odierno e l’ipotetico scenario che si verrebbe a presentare a seguito dell’adozione dell’applicativo.
  13. 13. 8 FIGURA 2 - SCENARIO ATTUALE
  14. 14. 9 FIGURA 3 - ADOZIONE DEL SISTEMA IN ESAME
  15. 15. 10 FIGURA 4 - CONFRONTO TRA I DUE SCENARI Dopo una prima analisi si evince che le macro funzionalità che si richiedono all’applicativo si possono riassumere nei punti che seguono.  Possibilità di importare i file contenenti i dati da analizzare.  Possibilità di visualizzare opportuni report ricavati dall’elaborazione dei dati caricati.  Mantenimento di uno storico relativo ai documenti precedentemente caricati e ai report ottenuti. In prima approsimazione gli utenti destinati all'uso del sistema sono i seguenti:  Amministratore di sistema  Gestore di sistema  Utente generico, che comprende:  Partner  Senior Manager  Manager  Senior Consultant 1.6 Criticità/Rischi Per ragioni di sicurezza il software non interagirà direttamente con i sistemi SFA, ma acquisirà i dati da fogli di calcolo (in formato .xls) contenenti i dati di interesse per il processo delineato.
  16. 16. 11 1.7 Requisiti funzionali 1.7.1 [UR_DOC] Documentazione di processo 1.7.1.1 [UR_DOC_01] Acquisizione della documentazione Per ogni Forecast aperto l’applicativo deve consentire l’inserimento della documentazione di processo. 1.7.1.1.1 [UR_DOC_001] Acquisizione foglio di calcolo SFA Per ogni BU, l’applicativo deve permettere l’upload di un foglio di calcolo in formato .xls contenente i dati provenienti dai sistemi SFA. 1.7.1.1.2 [UR_DOC_002] Acquisizione foglio di calcolo CoGe Per ogni BU, l’applicativo deve permettere l’upload del foglio di calcolo CoGe (formato .xls). 1.7.1.1.3 [UR_DOC_003] Sovrascrittura della documentazione Si richiede, inoltre, la possibilità di sovrascrivere documenti precedentemente caricati. La sovrascrittura della documentazione deve essere inibita nel caso in cui il Forecast di riferimento sia stato chiuso (vedi paragrafo 1.7.2.2). 1.7.1.2 [UR_DOC_02] Persistenza della documentazione Ogni volta che un documento viene caricato nel sistema i dati in esso contenuti devono essere estratti e trascritti nella base di dati di riferimento. 1.7.1.3 [UR_DOC_03] Denominazioni multiple cliente Si richiede la possibilità di attribuire una denominazione unica a clienti che su trattative differenti compaiono con differenti denominazioni. Se, ad esempio, su SFA comparissero le tre voci “Generali_Doc”, “Generali_Prod”, “TeamGenerali”, l’applicativo dovrà fornire la possibilità di mappare tali voci nella più generica “GENERALI”. 1.7.2 [UR_FC] Gestione Forecast 1.7.2.1 [UR_FC_01] Apertura nuovo Forecast L’applicativo deve permettere l’apertura di un nuovo Forecast; la data di apertura deve poter essere impostata dall’utente. Tale operazione non è concessa nei seguenti casi:  il forecast precedente non è stato chiuso;  la data di apertura precede la data di chiusura del forecast precedente. 1.7.2.2 [UR_FC_02] Chiusura Forecast L’applicativo deve permettere la chiusura del Forecast corrente; la data di chiusura deve poter essere impostata dall’utente. La chiusura non è concessa nei seguenti casi:  non sono presenti Forecast aperti;  la data di chiusura precede la data di apertura del forecast corrente.
  17. 17. 12 1.7.3 [UR_ROLE] Ruoli ed attori di processo L'applicativo deve essere in grado di distinguere differenti ruoli utente sulla base delle credenziali fornite durante il log-in. Le informazioni e le funzionalità esposte dipenderanno proprio dal ruolo dell’utente nell’ambito del sistema. 1.7.3.1 [UR_ROLE_01] BU User Identifica l’utente base del sistema. Fanno riferimento a questo ruolo i tre profili aziendali: “Senior Manager”, “Manager” e “Senior Consultant”. 1.7.3.2 [UR_ROLE_02] Operator Identifica l’operatore a livello business del sistema; fa riferimento alla figura aziendale che si occupa dell’inserimento della documentazione nel sistema, quindi, in prima approsimazione al Partner. 1.7.3.3 [UR_ROLE_03] Administrator Identifica l’amministratore di sistema. Le funzionalità che lo riguardano sono:  la gestione dei Forecast (apertura e chiusura)  la gestione delle utenze (creazione, aggiornamento, cancellazione e blocco);  la gestione dei ruoli e della relativa mappatura sulle utenze;  la gestione delle funzionalità e della relativa mappatura su ruoli e utenze;  la gestione delle denominazioni multiple dei clienti. La seguente tabella presenta l’associazione Ruoli - Profili aziendali che deve essere adottata di default dal sistema. Ruoli Profili aziendali BU User Operator Administrator Ammistratore di sistema X Gestore di sistema X X Partner X X Senior Manager X Manager X Senior Consultant X TABELLA 1 - ASSOCIAZIONE PROFILI AZIENDALI-RUOLI 1.7.3.4 [UR_ROLE_04] Provenienza L'applicativo deve poter risalire alla BU di provenienza dell’utente sulla base delle credenziali fornite durante l’accesso all’applicativo.
  18. 18. 13 1.7.4 [UR_REP] Report 1.7.4.1 [UR_REP_01] Visualizzazione report allineamento L'applicativo deve fornire all'utente un report che corrisponda all'attuale documento Allineamento SFA-CoGe. 1.7.4.2 [UR_REP_02] Visualizzazione report forecast L'applicativo deve fornire all'utente un report che corrisponda all'attuale documento Forecast report. 1.7.4.3 [UR_REP_03] Report tramite grafici L'applicativo dovrebbe presentare un grafico a barre che metta a confronto i valori di CoGe e Budget per ogni BU. Altri requisiti su eventuli grafici verranno introdotti in futuro. 1.8 Modello dei casi d’uso 1.8.1 Premessa Si potrà constatare, nei paragrafi seguenti, che non tutti i requisiti funzionali sono coperti dagli Use Cases, questa scelta è stata dettata dalla volontà di selezionare un sottoinsieme di requiti minini sui quali concentrarsi per la realizzazione di un prototipo. Ciò ha permesso di ottenere un prototipo funzionante in minor tempo e consentirà di raffinare i requisiti già definiti sulla base di test operativi eseguiti dagli utenti che realmente usufruiranno dell’applicativo. 1.8.2 Attori Viene presentata di seguito la lista degli attori che interagiranno con il sistema.  BU User  Administrator  Operator  Active Directory  Browser 1.8.3 Diagrammi dei casi d’uso Nello schema sotto riportato si mostra la struttura del sistema in questione. I vari sottosistemi interagiscono tra loro per fornire le funzionalità complessive dello stesso. FIGURA 5 - STRUTTURA DEL SISTEMA
  19. 19. 14 In ogni diagramma che verrà esplicitato nei prossimi paragrafi si assumono le seguenti associazioni di specializzazione tra attori: FIGURA 6 - SPECIALIZZAZIONE DEGLI ATTORI 1.8.3.1 Sottosistema ACCESSO AL SISTEMA FIGURA 3 – SOTTOSISTEMA LOG-IN
  20. 20. 15 1.8.3.2 Sottosistema INSERIMENTO FIGURA 4 – SOTTOSISTEMA INSERIMENTO 1.8.3.3 Sottosistema GESTIONE FORECAST FIGURA 5 – SOTTOSISTEMA GESTIONE FORECAST
  21. 21. 16 1.8.3.4 Sottosistema CONSULTAZIONE FIGURA 5 – SOTTOSISTEMA CONSULTAZIONE 1.8.4 Specifica dei casi d’uso UC-01 Richiede accesso al sistema Description Operazione di richiesta d’accesso al sistema. L’attivazione avviene digitando l’indirizzo dell’applicativo sul Browser e premendo il tasto invio. Preconditions 1. Il Browser utilizzato supporta la Windows Authentication. Actors Utente generico, Browser, Active Directory Normal Sequence 1. L’Utente immette nel Browser l’indirizzo dell’applicativo e preme invio. 2. Il Browser invia la richiesta al server. 3. Il server avverte il Browser che è richiesta Windows Authentication (inserisce nella risposta HTTP i due header WWW-Authenticate Negotiate, WWW-Authenticate NTML). 4. Il Browser contratta l’autenticazione dell’ Utente seguendo uno dei due protocolli: NTLM o Kerberos. 5. Le credenziali vengono verificate su Active Directory. 6. Se le credenziali identificano un Utente su Active Directory la fase di autententicazione termina con esito positivo. 7. Se anche la fase di autorizzazione termina con esito positivo, il Browser esegue il rendering dell’home page dell’applicativo (altrimenti, vedi 6a). Postconditions Extensions 6a. Viceversa, il server inoltra al Browser una risposta HTTP avente come status code 401 Unauthorized e contenente gli header WWW- Authenticate Negotiate, WWW-Authenticate NTML). 7a. Il Browser presenta all’Utente un form per l’inserimento delle credenziali. UC-02 Compila browser form Description Compilazione del form presentato dal Browser. Preconditions L’autenticazione o l’autorizzazione hanno avuto esito negativo. Actors Utente generico, Browser Normal Sequence 1. L’Utente compila il form fornito dal Browser e preme invio. 2. Si ripete la stessa sequenza di operazioni descritte nello Use case UC-
  22. 22. 17 01 a partire dal punto 6. Postconditions Extensions Vedi Extensions UC-01. UC-03 Inserimento dati SFA Description Caricaricamento del foglio di calcolo contenente i dati provenienti dal sistema SFA. L’attivazione dell’operazione avviene cliccando l’apposito pulsante che permette di selezionare un file. Preconditions Il documento in questione deve essere un foglio di calcolo in formato .xls. Actors Operator, Browser Normal Sequence 1. L’Operator individua il documento sul proprio disco locale attraverso l’apposita finestra di navigazione fornita dal Browser e preme invia. 2. Se nel Forecast corrente e nella BU di riferimento non è stato caricato precedentemente un foglio relativo a SFA, il Browser invia il file al server. Postconditions La base di dati di supporto contiene le informazioni presenti nel documento caricato. Extensions 2a. Viceversa, viene mostrata la richiesta di conferma per sovrascrivere i dati precedentemente caricati. UC-04 Inserimento dati CoGe Description Caricaricamento del foglio di calcolo CoGe. L’attivazione dell’operazione avviene cliccando l’apposito pulsante che permette di selezionare un file. Preconditions Il documento in questione deve essere un foglio di calcolo in formato .xls. Actors Operator, Browser Normal Sequence 1. L’Operator individua il documento sul proprio disco locale attraverso l’apposita finestra fornita dal Browser e preme invia. 2. Se nel Forecast corrente e nella BU di riferimento non è stato caricato precedentemente un foglio CoGe, il Browser invia il file al server. Postconditions La base di dati di supporto contiene i dati presenti nel documento caricato. Extensions 2a. Viceversa, viene mostrata la richiesta di conferma per sovrascrivere i dati precedentemente caricati. UC-05 Consulta Allineamento SFA-CoGe Description Consultazione del report Allineamento SFA-CoGe. L’attivazione dell’operazione avviene cliccando l’apposito pulsante. Preconditions Actors Utente generico, Browser Normal Sequence 1. L’Utente preme il pulsante per la consultazione del report in questione. 2. Il Browser inoltra la richiesta al sistema. 3. Il sistema elabora i dati richiesti e li restituisce al Browser. 4. Il Browser effettua il rendering della pagina richiesta. Postconditions Extensions
  23. 23. 18 UC-06 Consulta Forecast Report Description Consultazione del report Forecast Report. L’attivazione dell’operazione avviene cliccando l’apposito pulsante. Preconditions Actors Utente generico, Browser Normal Sequence 1. L’Utente preme il pulsante per la consultazione del report in questione. 2. Il Browser inoltra la richiesta al sistema. 3. Il sistema elabora i dati richiesti e li restituisce al Browser. 4. Il Browser effettua il rendering della pagina richiesta. Postconditions Extensions UC-07 Apertura Forecast Description Apertura di un nuovo Forecast. L’attivazione dell’operazione avviene cliccando l’apposito pulsante. Preconditions Actors Administrator, Browser Normal Sequence 1. L’Administrator imposta una data di apertura e preme il pulsante per inviare il comando. 2. Se il Forecast corrente è stato chiuso, viene verificata la correttezza della data impostata. 3. Se la data di apertura è antecedente alla data di chiusura del Forecast precedente, l’operazione termina con esito positivo. Postconditions La base di dati di supporto è stata aggiornata. Il Forecast corrente risulta essere il Forecast appena aperto. Extensions 2a. Altrimenti, viene segnalato l’errore con un apposito messaggio. 3a. Altrimenti, viene segnalato l’errore con un apposito messaggio. UC-08 Chiusura Forecast Description Chiusura del Forecast corrente. L’attivazione dell’operazione avviene cliccando l’apposito pulsante. Preconditions Actors Administrator, Browser Normal Sequence 1. L’Administrator imposta una data di chiusura e preme il pulsante per inviare il comando. 2. Se il Forecast corrente è aperto, viene verificata la correttezza della data impostata. 3. Se la data di chiusura è antecedente alla data di apertura del Forecast corrente, l’operazione termina con esito positivo. Postconditions La base di dati di supporto è stata aggiornata. Il Forecast corrente risulta essere il Forecast appena aperto. Extensions 2a. Altrimenti, viene segnalato l’errore con un apposito messaggio. 3a. Altrimenti, viene segnalato l’errore con un apposito messaggio. 1.8.5 Diagrammi delle attività Si presentano di seguito i diagrammi delle principali attività.
  24. 24. 19 1.8.5.1 Diagramma 1 – Accesso al sistema
  25. 25. 20 1.8.5.2 Diagramma 2 – Apertura Forecast
  26. 26. 21 1.8.5.3 Diagramma 3 – Inserimento documentazione
  27. 27. 22 1.8.5.4 Diagramma 4 – Consultazione report 1.9 Altri requisiti (non funzionali) 1.9.1 [UR_SUP] Supportabilità L'applicativo deve presentare un'interfaccia utente responsiva, ovvero, qualora sia utilizzato attraverso browser mobile, deve presentare un'interfaccia che si adatti completamente alle dimensioni dello schermo del dispositivo in uso. 1.9.2 [UR_USA] Usabilità L'applicativo deve assistere l'utente in tutte le operazioni che possono presentare criticità o interpretazioni differenti.
  28. 28. 23 L'applicativo deve presentare un'interfaccia utente semplice ed intuitiva, che permetta ad un utente con conoscenze informatiche medie di sfruttarlo a pieno fin dal primo utilizzo. 1.9.3 [UR_AFF] Affidabilità L'applicativo deve prevenire le principali vulnerabilità riscontrate nelle applicazioni web attuali, sarà quindi compito del fornitore sviluppare opportuni test per accertare la sicurezza dello stesso. 1.10Requisiti della base di dati  L’azienda Cluster Reply è composta da diverse BU, ciascuna delle quali possiede un nome univoco e una sede.  Per ogni BU si vorrà tenere traccia del personale che compone il reparto Management (si tratta degli utenti che saranno abilitati all’uso dell’applicativo).  Per ciascun utente verrà memorizzato il nome, il cognome, l’indirizzo email, il profilo aziendale e i ruoli ricoperti (ai fini dell’applicativo).  Sarà di interesse mantenere uno storico relativo alle precedenti proiezioni (Forecast) relative a ciascuna BU.  Un Forecast sarà associato ad una data di apertura e ad una data di chiusura. Ad ogni Forecast sarà associato un attributo che indica se lo stesso è ancora aperto oppure se è stato chiuso.  Dato che l’elaborazione dei report verrà effettuata ad ogni richiesta di consultazione dell’utente (elaborazione on-demand) si vorrà mantenere una copia del contenuto dei documenti SFA e CoGe (definitivi6 ) relativi ad ogni Forecast.  Ogni funzionalità dell’applicativo sarà fruibile da un sottoinsieme (non vuoto) di ruoli utente, si vorrà quindi mantenere l’insieme delle associazioni funzionalità, ruoli utente associati.  Poichè ad alcuni utenti sarà dato accesso alle informazioni relative a più BU, risulterà necessario tenere traccia della visibilità (in termini di BU) associata a ciascun utente.  Al fine di gestire in modo efficace le denominazioni multiple di un cliente si richiede di poter tenere traccia di un cliente e di tutte le diverse denominazioni ad esso associato. 6 L’ultima versione inserita.
  29. 29. 24
  30. 30. 25 2 Progettazione 2.1 Progettazione concettuale Una volta che tutti i requisiti sono stati raccolti e analizzati, il passo successivo consiste nel creare uno schema concettuale per la base di dati, usando un modello dei dati concettuali di alto livello. Questa fase è detta progettazione concettuale. In una prima analisi lo schema architetturale individuato si compone dalle seguenti entità:  BU  UTENTE  FORECAST  COGE  SFA  FUNZIONALITA  CUSTOMER  RUOLO Le relazioni che intercorrono tra le entità, in un primo stadio di raffinamento, sono:  appartiene : relazione tra BU e UTENTE.  relativo : relazione tra BU e FORECAST.  compone(s) : relazione tra FORECAST e SFA.  compone(c) : relazione tra FORECAST e COGE.  partecipa : relazione tra SFA, COGE e CUSTOMER.  fruibile: relazione tra RUOLO e FUNZIONALITA.  ricopre: relazione tra UTENTE e RUOLO.  visibilita: relazione tra BU e UTENTE.
  31. 31. 26 FIGURA 7 - SCHEMA INIZIALE DELLA BASE DI DATI 2.1.1 Analisi delle entità: attributi e chiavi primarie BU Nome Nome che identifica univocamente una Business Unit. Chiave primaria Sede Nome della sede in cui risiede la BU. UTENTE Email Email aziendale che identifica univocamente un utente. Chiave primaria Nome Nome dell’utente. Cognome Cognome dell’utente. FORECAST Id Identificativo di un determinato Forecast. Chiave primaria Data apertura Data in cui il Forecast è stato aperto. Data chiusura Data in cui il Forecast è stato chiuso (se è stato chiuso).
  32. 32. 27 Chiuso Stringa che indica se il Forecast è stato chiuso o meno. SFA Id Identificativo di un determinato foglio di calcolo contenente i dati provenienti dai sistemi SFA. Chiave primaria Data estrazione Data nella quale i dati vengono estratti dal foglio di calcolo e salvati nella base di dati. BU Nome della BU alla quale i dati estratti fanno riferimento. Campi SFA Segue la lista dei campi componenti il foglio di calcolo SFA. Si è scelto di ometterli in quanto non rilevanti ai fini della progettazione della base di dati. COGE Id Identificativo di un determinato documento CoGe. Chiave primaria Data estrazione Data nella quale i dati vengono estratti dal foglio di calcolo e salvati nella base di dati. BU Nome della BU alla quale i dati estratti fanno riferimento. Campi Coge Segue la lista dei campi componenti il foglio di calcolo CoGe. Si è scelto di ometterli in quanto non rilevanti ai fini della progettazione della base di dati. FUNZIONALITA Id Identificativo di una determinata funzionalità. Chiave primaria Descrizione Descrizione testuale della funzionalità in questione. CUSTOMER Nome Nome che identifica in modo univoco un cliente. Chiave primaria Denominazioni Lista delle dominazioni da associare al cliente. RUOLO Nome Nome che identifica in modo univoco un ruolo. Chiave primaria 2.1.2 Analisi delle associazioni: descrizione, rapporto di cardinalità e attributi
  33. 33. 28 appartiene Descrizione Associa ciascun utente alla propria BU. Rapporto di cardinalità 1:N Ogni utente appartiene ad una BU. Una BU contiene uno o più utenti. relativo Descrizione Mette in relazione un Forecast con la BU a cui fa riferimento. Rapporto di cardinalità 1:N Ogni Forecast è associato ad una BU. Ad una BU sono associati 0 o più Forecast. compone (s) Descrizione Mette in relazione un documento SFA con il Forecast di riferimento. Rapporto di cardinalità 1:1 Ogni documento SFA compone un solo Forecast. Ogni Forecast è associato ad al più un solo documento SFA. compone (c) Descrizione Mette in relazione un documento CoGe con il Forecast di riferimento. Rapporto di cardinalità 1:1 Ogni documento CoGe compone un solo Forecast. Ogni Forecast è associato ad al più un solo documento CoGe. fruibile Descrizione Associa un ruolo alle funzionalità delle quali può fruire. Rapporto di cardinalità M:N Ogni ruolo può fruire di una o più funzionalità. Una funzionalità è fruibile da uno o più ruoli. ricopre Descrizione Associa un utente al/i ruolo/i che ricopre. Rapporto di cardinalità M:N Ogni utente può ricoprire uno o più ruoli. Ogni ruolo può essere ricoperto da più utenti. visibilita Descrizione Associa un utente alle BU da esso visibili. Rapporto di cardinalità M:N Ogni utente può avere visibilità di una o più BU. Ogni BU può essere visibile da uno o più utenti.
  34. 34. 29 partecipa Descrizione Associa i documenti SFA e CoGe ai clienti che compaiono nelle commesse. Rapporto di cardinalità M:N Ogni documento contiene una lista di uno o più clienti. Ogni cliente può essere contenuto in nessuno o più documenti. Terminata la fase di progettazione concettuale, è emersa l’esigenza di introdurre un ulteriore vincolo sui requisti. E’ stato richiesto, infatti, che le funzionalità messe a disposizione fossero in qualche modo legate ai singoli utenti oltre che ai ruoli. Ciò consentirebbe di gestire casi eccezionali in cui, ad esempio, vi sia la necessità di permettere ad un utente di usufruire di una determinata funzionalità sebbene il ruolo ad esso assegnato glielo impedisca. In una situazione di questo tipo, sarebbe inopportuno modificare il ruolo dell’utente in quanto lo stesso verrebbe abilitato a tutte le funzionalità messe a disposizione di tale ruolo. L’introduzione del vincolo appena descritto ha comportato l’inserimento dell’associazione “dispone” tra le entità UTENTE e FUNZIONALITA. FIGURA 8 - SCHEMA CONCETTUALE FINALE DELLA BASE DI DATI 2.2 Progettazione logica 2.2.1 Ristrutturazione dello schema E-R Rimozione delle gerarchie Lo schema non presenta gerarchie di generalizzazione / specializzazione. Rimozione delle entità deboli Lo schema non presenta entità deboli da rimuovere.
  35. 35. 30 Rimozione degli attributi composti Lo schema non prevede attributi composti. Rimozione degli attributi multivalore L’unico attributo multivalore presente nello schema è l’attributo Denominazioni che compare nell’entità CUSTOMER. La rimozione di tale attributo richiede l’introduzione della nuova entità DENOMINAZIONE e dell’associazione “designato_come”. 2.2.2 Schema logico relazionale Segue la traduzione dello schema concettuale ristrutturato in un equivalente schema logico relazionale. Ciascuna entità dello schema E-R ristrutturato viene mappata in un equivalente schema relazionale, il quale prevede la segnalazione della relativa chiave primaria (sottolineandola) e dei vincoli di integrità referenziali tra chiavi esterne e chiavi (indicati da una freccia che punta alla chiave riferita). 1.
  36. 36. 31 2. 3.
  37. 37. 32 4. 5.
  38. 38. 33 6. 7.
  39. 39. 34 8. 9.
  40. 40. 35 10.
  41. 41. 36 Di seguito si presenta lo schema logico relazionale ottenuto. FIGURA 9 - SCHEMA LOGICO RELAZIONALE DELLA BASE DI DATI
  42. 42. 37 2.3 Architettura del software 2.3.1 Introduzione: architetture a tre livelli Nella progettazione ed implementazione di applicazioni data-centric, ovvero applicazioni che sfruttano una sorgente dati (nel caso più comune, un database relazionale) per persistere le informazioni trattate, l'approccio più diffuso è quello di scomporre il sistema in diversi strati applicativi (layer), ciascuno dei quali caratterizzato da una forte focalizzazione e specializzazione funzionale. Ogni layer esegue compiti ben definiti ed è in grado di comunicare con gli altri strati, demandando ad essi le eventuali azioni non di propria pertinenza. Pertanto, secondo questo approccio architetturale, le funzionalità più complesse vengono ottenute dalla collaborazione di più elementi specializzati, dislocati nei diversi layer applicativi secondo un ordine di invocazione gerarchico ben preciso. Ciascun layer si compone di classi che svolgono compiti simili e omogenei, ma che agiscono su dati e scenari diversi. Questa omogeneità funzionale rappresenta la caratteristica principale di ogni strato applicativo. Per quanto riguarda le applicazioni web si individuano in genere tre livelli logici; perciò, quando si fa riferimento a questo tipo di applicazioni, si parla spesso di architetture a tre livelli. I layer in questione sono i seguenti  Presentation Layer: ha lo scopo di gestire l’interazione del sistema con il mondo esterno, in particolare con gli utenti. Include le maschere per la visualizzazione e l’inserimento dei dati, i controlli e i meccanismi per intercettare e trattare opportunamente gli eventi che sono scatenati in funzione delle azioni svolte dagli utenti.  Business Logic Layer: comprende l’insieme delle regole di business che regolano il funzionamento dell’applicazione, intercetta le richieste provenienti dallo strato di presentazione e le gestisce nel modo più appropriato.  Data Access Layer: si occupa di persistere le informazioni trattate dall’applicazione e conosce le modalità per leggerle e salvarle in una sorgente dati di qualche tipo. Se da un lato un numero maggiore di moduli implica un maggiore sforzo in termini di programmazione, dall'altro la scomposizione dell'applicazione in oggetti raggruppati in modo omogeneo a formare i diversi layer comporta una migliore organizzazione e strutturazione logica del codice, con vantaggi enormi in termini di manutenibilità e scalabilità. Basti pensare che se si presentasse la necessità di cambiare sistema di database, sarebbe sufficiente modificare uno solo dei livelli dell’applicazione. 2.3.2 ASP.NET MVC Nel caso in questione, uno dei requisiti di progetto ha fortemente vincolato la struttura dell’architettura del sistema, che si è dovuta attenere alle linee guida del design pattern ASP.NET MVC. Il Model-View-Controller (MVC) è un pattern architetturale molto diffuso nello sviluppo di sistemi software che si propone di separare la logica di presentazione dei dati dalla logica di business.
  43. 43. 38 In particolare, ASP.NET MVC rapprenta un modello di programmazione all’interno del Framework di sviluppo web ASP.NET che aderisce al pattern MVC. Tale pattern prevede la separazione della logica dell’applicazione in tre livelli:  il Model fornisce la logica per l’accesso ai dati utili all'applicazione, contiene inoltre la definizione delle entità coinvolte;  il View si occupa di mostrare i dati contenuti nel Model;  il Controller riceve i comandi dell'utente (in genere attraverso il view) e li attua modificando lo stato degli altri due componenti. FIGURA 10 - SCHEMA PATTERN MVC 2.3.3 Composizione delle architetture In fase di progettazione si è profilato un ulteriore vincolo progettuale che ha posto il problema di integrare il design pattern ASP.NET MVC nell’architettura a tre livelli sopra descritta. Nel dettaglio, l’azienda ha richiesto di strutturare il sistema nei tre livelli descritti sopra (PL,BLL,DAL) creando un differente progetto di Visual Studio per ogni livello. Si è quindi studiata una soluzione che permettesse di inglobare nella three level architecture la separazione logica prevista da MVC 7 senza snaturarne il significato. Il risultato è rappresentato nello schema che segue. 7 La separazione tra Model, View e Controller in ASP.NET prevede l’utilizzo di tre folder differenti, uno per ogni componente logica.
  44. 44. 39 FIGURA 11 - ARCHITETTURA DEL SISTEMA Ogni livello (e quindi ogni progetto) rappresenta una porzione significativa del problema generale da risolvere, perciò è organizzato in più folder, ognuno dei quali raccoglie oggetti simili per funzionalità svolte. Come si può notare è stato introdotto un ulteriore livello adiacente a tutti gli altri. Esso rappresenta un modello del dominio dell’applicazione, ovvero un insieme di classi che servono a rappresentare le entità coinvolte. Includerà quindi la definizione di tutte le entità il cui contesto, ai fini dello sviluppo, non può essere confinato ad un unico livello. Il Presentation Layer contiene i folder relativi a View e Controller del pattern MVC, mentre il Model è stato distributo tra i restanti livelli. Ciò comporta che il livello di presentazione svolga ambedue i compiti:  fornire al client le pagine web sulla base delle elaborazioni svolte;  ricevere dal server web le richieste HTTP provenienti dal client sotto forma di URL e trasferire allo strato sottostante le informazioni acquisite. Per quanto riguarda le funzioni svolte dai livelli Business Logic e Data Access si rimanda al paragrafo 2.3.1. 2.4 Progettazione interfaccia grafica Mockup Nell’ambito dello sviluppo web un mockup non è altro che una rappresentazione statica e approsimativa di come apparirà il prodotto finale. Permette agli sviluppatori di mostrare una sorta di “preview” delle pagine che comporranno il sistema all’utente finale. Nel caso in esame, i mockup presentati sono stati sottoposti al responsabile del progetto per una valutazione prima di cominciare la fase di sviluppo.
  45. 45. 40 1. Allineamento SFA-CoGe, documentazione non inserita FIGURA 12 - ALLINEAMENTO SFA-COGE (DOCUMENTAZIONE NON INSERITA) 2. Inserimento documentazione FIGURA 13 - INSERIMENTO DOCUMENTAZIONE
  46. 46. 41 3. Allineamento SFA-CoGe, foglio Confronto FIGURA 14 - ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO
  47. 47. 42 4. Allineamento SFA-CoGe, foglio Componenti offerta FIGURA 15 - ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA
  48. 48. 43 5. Forecast report FIGURA 16 - FORECAST REPORT
  49. 49. 44 6. Chiusura Forecast FIGURA 17 - CHIUSURA FORECAST 2.5 Valutazione del template grafico In questa fase l’azienda ha richiesto la valutazione del template grafico da utilizzare nello sviluppo della user interface dell’applicativo. In particolare è stato chiesto di fornire un campione, composto da un massimo di 5 alternative, di template Twitter Bootstrap. Twitter bootstrap è un framework grafico rilasciato dal team di sviluppo di Twitter, che permette di avvalersi di una serie di componenti grafici (pulsanti,form, tabelle ecc.) forniti con i relativi fogli di stile8 (CSS). La fase di ricerca del template è stata preceduta dalla definizione dei parametri sui quali basare la valutazione. Dopo un confronto con il responsabile di progetto, i parametri emersi sono:  compatibilità con browser e sistemi operativi più diffusi;  versione di Bootstrap utilizzata;  qualità della documentazione fornita;  struttura e responsività del layout;  attinenza con il logo dell’azienda;  eventuali malfunzionamenti riscontrati nelle versioni demo. Presentato il campione, la scelta del responsabile di progetto è ricaduta sul template “Metronic” sviluppato dal team Keenthemes9 all’interno del framework Bootstrap 3.1.0. 8 Per maggiorni informazioni visitare il sito http://getbootstrap.com/
  50. 50. 45 3 Implementazione Segue la descrizione dei moduli principali che compongono il sistema. Tutti i moduli che verranno presentati sono stati sviluppati dall’autore. Ove, in caso contrario, si faccia riferimento a librerie esterne verrà opportunamente indicato. 3.1 Autenticazione e recupero di informazioni su Active Directory Come indicato nei vincoli di progetto l’autenticazione dell’utente avviene avvalendosi della Windows authentication sul sistema di directory service Microsoft Active Directory. Active Directory è un insieme di servizi di rete meglio noti come directory service adottati dalla maggior parte dei sistemi operativi Microsoft Windows Server. Un directory service è un sistema software che memorizza, organizza e fornisce l'accesso alle informazioni contenute in una directory. Nell’ingegneria del software, una directory è un’associazione di nomi e valori che consente la ricerca di valori dato un nome. L’integrazione della Windows authentication in un’ applicazione ASP.NET risulta molto semplice, in quanto è sufficiente dichiarare, nelle proprietà del progetto, l’intenzione di adottare la Windows authentication disabilitando al tempo stesso l’Anonymous authentication. FIGURA 18 - MASCHERA PROPRIETÀ PROGETTO IN VISUAL STUDIO 2012 Il sistema provvederà automaticamente ad intercettare le richieste degli utenti e ad identificarli su Active Directory prima di fornire accesso all’applicativo. Più complesso si è rivelato il recupero di informazioni relative agli utenti sul directory service in esame. Una delle tecniche che permette di eseguire tale operazione si avvale dell’utilizzo delle API LDAP. Tali API forniscono accesso al procollo LDAP, che costituisce una via per l’interazione con i sistemi di directory service, come Active Directory. LDAP (Lightweight Directory Access Protocol) è un protocollo che permette di accedere ai servizi di directory basati sul modello x.50010 . Permette di interrogare, creare, aggiornare e cancellare 9 http://themeforest.net/item/metronic-responsive-admin-dashboard-template/4021469 10 Il modello X.500 è uno standard per la realizzazione di un servizio di directory globale e distribuito.
  51. 51. 46 informazioni memorizzate in un directory service su una connessione TCP, tipicamente attraverso la porta 389. I dettagli del protocollo e dell’implementazione sono definiti nel RFC2251: “The Lightweight Directory Access Protocol (v3)” e su altri documenti come, ad esempio, le specifiche tecniche nel RFC3377. 3.1.1 Architettura delle ricerche su Active Directory L’architettura delle ricerche su Active Directory include componenti sia client che server. Relativamente al lato client, l’applicazione costruisce le richieste LDAP da inviare al server. A seconda di come l’applicativo è stato scritto, una delle tre APIs che verranno nel seguito presentate viene utilizzata per inviare le richieste. Le LDAP request ricevute vengono quindi elaborate dal Directory System Agent (DSA). Si riporta di seguito lo schema riepilogativo dell’architettura descritta fornito nella documentazione Microsoft. FIGURA 19 - ACTIVE DIRECTORY SEARCHES ARCHITECTURE Le tre LDAP APIs che possono essere utilizzate lato client sono qui descritte.  System.DirectoryServices (ADSI for .NET Framework): si tratta di un namespace del .NET Framework che fornisce un semplice accesso alle LDAP directories. Richiede l’installazione del .NET Framework.  Active Directory Service Interfaces (ADSI) (Ads*.dll): costituisce un set di interfacce aperte che astraggono i dettagli delle comunicazioni LDAP.  Native LDAP API (Wldap32.dll): fornisce una serie di funzioni che permettono di cercare e recuperare informazioni da un LDAP directory service.
  52. 52. 47 FIGURA 20 - ACTIVE DIRECTORY SEARCHES INTERFACES In questa circostanza si è scelto di avvalersi delle interfacce ADSI fornite con il namespace System.DirectoryServices. Il valore aggiunto introdotto dall’utilizzo di tali interfacce rispetto alle altre, è dato dal fatto che:  si tratta di APIs a livello più alto;  sono più semplici da utilizzare. 3.1.2 Modulo sviluppato Ai fini dell’applicativo, risulta di interesse recuperare la mail di un utente la cui identità è già stata verificata su Active Directory. Nello specifico, dato lo username dell’utente nel dominio REPLYNET si vuole recuperare l’indirizzo email aziendale ad esso associato. Il modulo sviluppato prevede la ricezione di uno username e di una lista di proprietà11 e la conseguente restituzione della lista di valori associati a tali proprietà nell’ordine in cui sono stati richiesti. FIGURA 21 - SCHEMA MODULO ACTIVE DIRECTORY SEARCHES Risulta evidente che si è cercato di sviluppare il modulo nel modo più generico possibile, in modo tale che se in futuro dovesse sorgere l’esigenza di recuperare altre informazioni non sia necessario modificare o addirittura riscrivere l’intero modulo. Le due classi principali nel namespace System.DirectoryServices sono DirectoryEntry e DirectorySearcher. La prima viene utilizzata per stabilire una connessione con il directory service, la seconda fornisce i metodi per effettuare la ricerca. 11 Con proprietà si fa riferimento agli attributi associati ad ogni User su Active Directory (ad esempio “mail”, ”givenName”, “department” ecc.).
  53. 53. 48 Una volta stabilita la connessione e istanziata la classe DirectorySearcher è possibile impostare un filtro sulla ricerca che si sta per effettuare. Nel modulo sviluppato è stato utilizzato il seguente filtro: FRAMMENTO DI CODICE 1 - FILTRO UTILIZZATO NELLA RICERCA Viene quindi verificato che l’oggetto che si sta cercando sia istanza della classe “user” e che il “sAMAccountName”12 corrisponda a userName. Il passo successivo consiste nel definire le proprietà che si vogliono recuperare nell’oggetto DirectorySearcher: FRAMMENTO DI CODICE 2 - INSERIMENTO DELLE PROPRIETÀ NELL'OGGETTO DIRECTORYSEARCHER Infine si esegue la ricerca, in questo caso verrà prodotto un unico risultato dato che sAMAccountName identifica in modo univoco un utente. FRAMMENTO DI CODICE 3 - AVVIO DELLA RICERCA Se la ricerca ha avuto esito positivo all’interno dell’oggetto SearchResult saranno contenute le proprietà richieste, che possono essere estratte con operazioni del tipo: FRAMMENTO DI CODICE 4 - ESTRAZIONE DELLE PROPRIETÀ RICHIESTE 3.2 Estrazione di dati da fogli di calcolo con OpenXML In questo paragrafo verrà trattato il processo di estrazione dei dati di interesse da fogli di calcolo in formato .xls, avvalendosi delle librerie OpenXML. 3.2.1 Office Open XML Office Open XML (chiamato anche OOXML o OpenXML) è un formato di file, basato sul linguaggio XML, per la rappresentazione di documenti informatici, come documenti di testo, fogli di calcolo, presentazioni e grafici. Sviluppato inizialmente da Microsoft, come formato per la rappresentazione dei prodotti Microsoft Office, è stato successivamente standardizzato da ECMA (ECMA-376) e poi da ISO e IEC (ISO/IEC 29500). Lo standard prevede tre principali linguaggi di markup: WordprocessingML,SpreadsheetML e PresentationML. Come è facile intuire, ai fini del progetto di tesi, il linguaggio analizzato è lo SpreadsheetML, ovvero il linguaggio di markup con lo scopo di rappresentare fogli di calcolo. 12 sAMAccountName rappresenta il logon name di uno user su Active Directory.
  54. 54. 49 3.2.2 SpreadsheetML Un documento SpreadsheetML è composto di una sezione centrale detta workbook e di più sezioni separate (dette worksheet) per ogni foglio di lavoro. Affinchè un documento SpreadsheetML possa ritenersi valido deve contenere la sezione workbook e almeno una sezione worksheet. 3.2.2.1 Sezione workbook Il primo e più importante compito della sezione workbook è di tenere traccia dei fogli di lavoro. Ad ogni foglio sono associati un nome, un ID utilizzato nell’ordinamento dei fogli e un rID (relationship ID) che punta alla sezione del workbook nella quale il foglio è memorizzato. FIGURA 22 - ESEMPIO DI WORKBOOK MINIMO 3.2.2.2 Sezione worksheet La prima parte della sezione riguarda le proprietà del worksheet; quindi, seguono i dati contenuti nell’elemento sheetData. All’interno di tale elemento saranno definite le righe e le celle che compongono il foglio di calcolo. Una nuova riga viene definita mediante l’elemento row, mentre una nuova cella viene definita mediante l’elemento c. Il valore contenuto nella cella viene incluso all’interno di un elemento v, se si tratta di un valore numerico (vedi fig. 22). FIGURA 23 - WORKSHEET CONTENENTE UN UNICO DATO Nel caso in cui il valore contenuto in una cella sia ottenuto attraverso una formula verrà utilizzato l’elemento f per dichiarare la formula e l’elemento v conterrà il risultato dell’elaborazione. Tale valore fa riferimento all’ultima occorrenza in cui la formula è stata calcolata.
  55. 55. 50 FIGURA 24 - ESEMPIO DI FORMULA La memorizzazione di stringhe segue invece una procedura di ottimizzazione che prende il nome di shared strings. Questa tecnica permette di ottimizzare lo spazio richiesto quando il foglio di calcolo contiene molteplici istanze della stessa stringa. Prevede, infatti, di memorizzare in una tabella (shared string table) la stringa in questione e di referenziare la stessa attraverso un indice. In questo modo, si evita l’inclusione della stringa nel campo value dell’elemento cella. La shared string table compare come una sezione separata all’interno del workbook e viene definita attraverso l’elemento sst. Mentre un nuovo item viene aggiunto attraverso l’elemento si (string item). FIGURA 25 - ESEMPIO DI SHARED STRING TABLE Per indicare che il valore contenuto in una cella è di tipo stringa si usa la dichiarazione “t=s” tra gli attributi dell’elemento cella. L’elemento v incluso nella cella viene utilizzato per indicare l’indice della shared string table.
  56. 56. 51 FIGURA 26 - ESEMPIO DI INDICIZZAZIONE DELLE STRINGHE Come si può notare dalla Figura 26, gli elementi riga e cella sono tipicamente accompagnati da un identificatore di posizione. Altri elementi possono comparire nella definizione di un documento SpreadsheetML, vengono però omessi in quanto non rilevanti ai fini del progetto. 3.2.3 OpenXML SDK OpenXML SDK è una libreria aperta che fornisce un insieme di classi .NET che permettono di manipolare file che aderiscono alle specifiche dello standard Office Open XML. Integra al suo interno la tecnologia LINQ (Language Integrated Query), un componente del .NET Framework che aggiunge ai linguaggi .NET la capacità di effettuare interrogazioni su oggetti utilizzando una sintassi simile a SQL13 . 3.2.4 Modulo sviluppato Il modulo in questione è stato progettato tenendo conto del fatto che la struttura dei fogli di calcolo è sempre la stessa, sia per quanto riguarda i fogli CoGe che per i fogli SFA. Ciò ha permesso di individuare dei punti cardine sui quali basare la lettura del documento; le seguenti assunzioni valgono per entrambi i documenti:  il nome del foglio di calcolo contenente i dati da leggere rimane immutato nel tempo;  i dati vengono esposti a partire da una determinata riga;  tra due entry della tabella non compare mai una riga interamente vuota;  esiste una colonna le cui celle non sono mai vuote qualora la riga corrispondente contenga una entry della tabella. In altre parole, se una cella appartenente a tale colonna è vuota significa che l’intera riga è vuota. Si è cercato di implementare il metodo che realizza il modulo in oggetto nel modo più generale e flessibile possibile, in modo tale da: 13 Per maggiori informazioni si rimanda al sito http://msdn.microsoft.com/it-it/library/bb397926.aspx.
  57. 57. 52  utilizzare lo stesso metodo per la lettura di entrambi i documenti (SFA e CoGe);  riuscire a far fronte a piccole variazioni strutturali dei documenti senza dover riscrivere parti di codice. Il metodo riceve i seguenti parametri:  path del file, corrisponde al path in cui il server ha temporaneamente salvato il file;  nome del foglio di calcolo, nome del foglio nel quale si leggono i dati;  indice inizio lettura, numero di riga corrispondente ai titoli dei campi della tabella;  colonna di riferimento, colonna usata come riferimento nel calcolo del numero di righe da analizzare. Se l’elaborazione va a buon fine viene restituito un oggetto di tipo DataTable14 contenente i dati estratti dal documento. FIGURA 27 - SCHEMA MODULO SPREADSHEETML EXTRACTION Si riportano di seguito le righe di codice ritenute più significative ai fini del processo. FRAMMENTO DI CODICE 5 Disponendo del riferimento alla sezione worksheet è possibile calcolare l’indice dell’ultima riga da leggere, semplicemente individuando la prima cella non “manipolata” della colonna di riferimento. 14 Rappresenta una tabella di dati in memoria.
  58. 58. 53 Segue quindi la creazione di una DataTable il cui numero di righe e colonne corrisponda esattamente alle dimensioni della tabella di dati contenuta nel foglio di calcolo. Il passo successivo consiste nella lettura, riga per riga, del contenuto delle celle che includono i dati. Tale operazione richiede la verifica del tipo di dato che si sta andando a leggere:  se si tratta di un dato numerico o di un tipo Boolean è sufficiente leggere il contenuto dell’elemento value incluso nella cella;  nel caso di una stringa il contenuto viene estratto dalla shared string table. FRAMMENTO DI CODICE 6 - LETTURA, RIGA PER RIGA, DEL CONTENUTO DELLE CELLE. Il dato letto ad ogni ciclo verrà quindi inserito nella DataTable che verrà infine restituita al chiamante.
  59. 59. 54 3.3 Report mediante le librerie Kendo UI Telerik Kendo UI è una libreria basata su HTML 5 e jQuery che agevola lo sviluppo di componenti grafici evoluti, sia per il web che per il mobile. Sfrutta HTML5, CSS3 e jQuery per fornire una serie di widget legati alle tre categorie: web, mobile e data visualization. In particolare, nello sviluppo del progetto, sono state utilizzate le librerie Telerik UI for ASP.NET, un set di server-side wrappers che permettono l’utilizzo dei widget di Kendo UI tramite codice C# o VB.NET. FIGURA 28 - KENDO UI FRAMEWORK I wrappers evitano allo sviluppatore la scrittura di codice JavaScript. Infatti, nella pratica, lo sviluppatore definisce i componenti attraverso codice C# (nel dettaglio avvalendosi della Razor Syntax15 ), poi saranno i wrappers ad occuparsi della produzione del codice JavaScript necessario all’inizializzazione dei widget lato client. 3.3.1 Esempio: AutoComplete widget Per illustrare lo scenario appena descritto si presenta di seguito un semplice esempio il cui scopo è quello di fornire all’utente un Autocomplete widget. 15 La Razor Syntax è una particolare sintassi usata nella programmazione ASP.NET per creare pagine web dinamiche. In sostanza, consente di incorporare codice server-based (C# o Visual Basic) in pagine web.
  60. 60. 55 FRAMMENTO DI CODICE 7 - AUTOCOMPLETE KENDO UI WRAPPER Tale codice, inserito all’interno di una pagina .cshtml16 , definisce un AutoComplete Kendo UI wrapper attraverso la sintassi Razor. A run-time viene prodotto il seguente codice JavaScript lato client: FRAMMENTO DI CODICE 8 - AUTOCOMPLETE KENDO UI WIDGET Come si può notare il widget viene collocato esattamente sopra il div, laddove era stato definito mediante il wrapper. Dal punto di vista grafico il risultato prodotto è il seguente. 3.3.2 Modulo sviluppato Le librerie in questione sono state utilizzate all’interno di più moduli nel progetto, come la definizione di report in formato tabellare e nella produzione di un grafico a barre. 3.3.3 Premessa La struttura dei report implementati ricalca esattamente quanto contenuto nei fogli di calcolo attualmente in uso. Per ovvi motivi i dati che verranno mostrati sono puramente inventati. 16 Si tratta dell’estensione delle View del pattern MVC.
  61. 61. 56 3.3.4 Grid widget In più sezioni dell’applicativo sono stati inseriti dei report che si avvalgono del widget Grid. Tale widget permette di rappresentare i dati attraverso tabelle, fornendo al tempo stesso supporto per l’interazione con i dati (ad esempio paginazione, ordinamento, raggruppamento ecc.). 3.3.4.1 Esempio di utilizzo: report Componenti offerta Il report componenti offerta rappresenta uno dei fogli di calcolo che compongono il documento Allineamento SFA-CoGe. Si tratta di una tabella composta da undici campi di differenti tipi (testuali, numerici e date). Il wrapper, inserito nella View “Componenti”, espone dati che vengono elaborati on-demand, ogni volta che l’utente seleziona la voce corrispondente. Se i documenti SFA e CoGe non sono stati inseriti per la BU e il Forecast selezionati, verrà prodotta una tabella vuota. La dinamica con la quale i dati vengono passati alla View (e quindi al wrapper) si può articolare in sei passaggi. 1. L’utente invia la richiesta per visualizzare la View Componenti sottoforma di url. 2. La richiesta viene raccolta dal server, che invoca il metodo Componenti contenuto nel Controller specificato nella richiesta. 3. All’interno del metodo vengono richiesti i dati al layer sottostante. 4. Terminate le elaborazioni i dati vengono restituiti al metodo chiamante. 5. Il metodo invoca la View Componenti passando come parametro una lista di oggetti ComponentiOfferta. 6. La View riceve la lista e la rende disponibile ai componenti contenuti nella pagina. La seguente riga di codice realizza il punto 6: la View dichiara che il model ricevuto è un IEnumerable di oggetti ComponentiOfferta. E’ quindi possibile accedere al model in questione attraverso la Razor syntax @Model. FRAMMENTO DI CODICE 9 - DICHIARAZIONE E INIZIALIZZAZIONE MODEL Si riporta quindi il codice che realizza il wrapper in oggetto. Come si può notare, nella prima riga di codice viene passato il Model al wrapper Grid.
  62. 62. 57 FRAMMENTO DI CODICE 10 - GRID WRAPPER CHE REALIZZA IL REPORT COMPONENTI OFFERTA Particolare importanza riveste l’utima riga di codice, che determina la modalità con la quale la griglia richiede i dati al server nelle operazioni di paginazione, ordinamento e filtraggio. Nel caso in questione è stato utilizzato il cosiddetto server-binding, ciò implica che il wrapper esegua delle richieste HTTP-GET al server per portare a termine le operazioni sopracitate. Il risultato prodotto sul client è la tabella che segue. FIGURA 29 - GRID WIDGET CHE RAPPRESENTA IL REPORT COMPONENTI OFFERTA 3.3.4.2 Grid Layout I widget grid che sono stati presentati sono il risultato di un’analisi volta al miglioramento della leggibilità dei dati presentati. Si è scelto infatti di intervenire nel template standard delle griglie fornite da Kendo UI per adattarsi alle seguenti esigenze:
  63. 63. 58  il titolo di ogni colonna deve essere esposto in grasseto e al centro della colonna stessa;  ogni titolo deve essere completamente leggibile (perlomeno nei dispositivi desktop);  la larghezza della tabella deve adattarsi alle dimensioni della finestra del browser;  la larghezza delle colonne deve porter essere modificata dall’utente;  se, il ridimensionamento di una o più colonne, determinasse un aumento della larghezza della tabella dovrebbe comparire una barra di scrolling orizzontale che permetta all’utente di visualizzare le colonne non più visibili. 3.3.5 Chart widget Come suggerisce il nome, i widget Char sono dei componenti forniti da Kendo UI che permettono di costruire grafici sui dati che gli vengono passati. Il rendering avviene direttamente sul client attraverso la tecnologia SVG oppure sfruttando l’elemento Canvas incluso nell’HTML5. 3.3.5.1 Esempio di utilizzo: Forecast report Il Forecast report rappresenta il report comprensivo di tutte le BU che viene inoltrato dall’amministrazione centrale a tutti i gli attori del controllo di gestione alla chiusura di ogni Forecast. Si compone di una tabella e di un grafico a barre; verrà di seguito presentato il wrapper utilizzato nella definizione del grafico a barre. FIGURA 30 - CHART WRAPPER UTILIZZATO FORECAST REPORT
  64. 64. 59 Anche in questo caso si segnala l’ultima riga del wrapper, che determina il tipo di data-binding utilizzato. A differenza di quanto illustrato precedentemente, in questa situazione si fa utilizzo dell’ajax-binding, il che comporta l’utilizzo di richieste ajax nella popolazione delle barre. In particolare, viene inviata una ajax request al metodo CoGeBudgetComparison contenuto nel Controller Reports. Elaborate le informazioni richieste i dati verranno restituiti dal server in formato JSON17 . Il risultato prodotto sul client è il seguente grafico. FIGURA 31 - CONFRONTO COGE BUDGET 3.4 Considerazioni Come il lettore potrà intuire molti altri sono i moduli software che compongono il prodotto finale, si è scelto però di concentrarsi sui processi ritenuti più caratterizzanti e meno frequenti nell’ambito dello sviluppo di applicativi web. 3.5 Interfaccia prodotto finale Si è deciso di presentare l’interfaccia utente del prototipo attraverso un caso reale di utilizzo. 3.5.1 Presentazione user interface attraverso un caso di utilizzo Ipotesi iniziali:  l’utente in questione è un amministratore di sistema abilitato a tutte le funzionalità offerte;  il Forecast corrente è il secondo (su una scala che va da 1 a 12);  sono già stati caricati i documenti SFA e CoGe per la BU di provenienza dell’utente nel Forecast corrente. 17 JSON, acronimo di JavaScript Object Notation, è un formato adatto per lo scambio dei dati in applicazioni client-server.
  65. 65. 60 1. Report Allineamento SFA-CoGe, foglio Confronto FIGURA 32 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO Lo screenshot rappresenta l’Home Page dell’applicativo. I valori in alto a destra dello schermo stanno ad indicare che sono stati aperti due Forecast e che l’utente può visualizzare i report relativi a quattro BU. L’utente può avvalersi delle funzionalità messe a disposizione dall’applicativo utilizzando la sidebar sulla sinistra dello schermo. 2. Report Allineamento SFA-CoGe, espansione lista Forecast FIGURA 33 - REPORT ALLINEAMENTO SFA-COGE, ESPANSIONE LISTA FORECAST Espandendo la lista corrispondente all’icona di sinistra (nella notification list) si può notare che viene mostrata la lista dei Forecast che sono stati aperti. Se presente, il Forecast aperto viene indicato con un lucchetto aperto.
  66. 66. 61 Cliccando su uno dei Forecast della lista verranno presentati i report relativi a tale Forecast per la BU selezionata. Il Forecast selezionato di default è quello corrente (aperto o chiuso). 3. Report Allineamento SFA-CoGe, espansione lista BU FIGURA 34 - REPORT ALLINEAMENTO SFA-COGE, ESPANSIONE LISTA BU Similmente al caso precedente, espandendo la lista corrispondente all’icona di destra (nella notification list) verrà mostrata la lista di BU visibili dall’utente corrente. Selezionando una delle BU presenti nella lista verrano mostrati i report relativi a tale BU. La BU selezionata di default è la BU di provenienza dell’utente corrente. 4. Chiusura di un Forecast FIGURA 35 - CHIUSURA DI UN FORECAST
  67. 67. 62 La sezione in oggetto permette la chiusura del Forecast corrente. E’ possibile selezionare una data di chiusura diversa da quella corrente attraverso il widget Calendar. 5. Chiusura di un Forecast (nessun Forecast da chiudere) FIGURA 36 - CHIUSURA DI UN FORECAST (NESSUN FORECAST DA CHIUDERE) Dopo aver chiuso il Forecast corrente il sistema segnala che non sono più presenti Forecast da chiudere. Come si evince dalla figura, la chiusura del Forecast viene segnalata anche attraverso la chiusura del lucchetto nella lista dei Forecast disponibili. 6. Inserimento documentazione (nessun Forecast aperto) FIGURA 37 - INSERIMENTO DOCUMENTAZIONE (NESSUN FORECAST APERTO) Entrando nella sezione relativa all’inserimento della documentazione, verrà visualizzato un messaggio che segnala l’impossibilità di procedere con l’operazione, data l’assenza di un Forecast aperto.
  68. 68. 63 7. Apertura nuovo Forecast FIGURA 38 - APERTURA NUOVO FORECAST Aprendo la sezione dedicata a tale scopo è possibile aprire un nuovo Forecast. La data di apertura è selezionabile attraverso l’apposito widget; di default viene selezionata la data corrente. 8. Inserimento documentazione FIGURA 39 - INSERIMENTO DOCUMENTAZIONE Arrivati a questo punto è possibile inserire la documentazione nel sistema. L’utente potrà scegliere se navigare sul proprio file system attraverso l’apposita finestra fornita dal browser, oppure trascinare il file da caricare nell’area corrispondente (drag and drop).
  69. 69. 64 9. Inserimento documentazione (operazione avvenuta) FIGURA 40 - INSERIMENTO DOCUMENTAZIONE (OPERAZIONE AVVENUTA) Alla pressione del tasto Upload File, viene fornito un messaggio che descrive l’esito dell’operazione. 10. Report Allineamento SFA-CoGe, foglio Componenti offerta FIGURA 41 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA E’ possibile consultare il foglio Componenti offerta relativo al report Allineamento SFA-CoGe per i dati appena inseriti. Cliccando il pulsante in alto a sinistra nella sidebar (a lato del logo Reply) è possibile ridurre le dimensioni della sidebar stessa, rendendo più comoda la consultazione del report in questione (vedi figura).
  70. 70. 65 FIGURA 42 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA (DIMENSIONI OTTIMALI) Se ritenuto opportuno, è possibile modificare la larghezza delle colonne per migliorare la leggibilità dei dati. FIGURA 43 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA (MODIFICA LARGHEZZA COLONNE)
  71. 71. 66 11. Inserimento documentazione (sovrascrittura) FIGURA 44 - INSERIMENTO DOCUMENTAZIONE (SOVRASCRITTURA) Nell’ipotesi in cui l’utente decida di sovrascrivere i dati precedentemente inseriti, il sistema segnala le conseguenze che l’operzazione comporta. 12. Forecast report FIGURA 45 - FORECAST REPORT Entrando nell’apposita sezione si possono consultare i Forecast report. Si è supposto che nel frattempo anche le altre BU abbiano inserito la documentazione di processo che le riguarda.
  72. 72. 67 Si rileva dalla figura sottostante che spostando il cursore del mouse sopra una colonna si può osservare la cifra rappresentata dalla stessa. FIGURA 46 - FORECAST REPORT (DETTAGLIO GRAFICO) 3.5.2 Funzionalità non disponibili Nel caso in cui l’utente corrente non disponga dei diritti necessari per fruire di tutte le funzionalità offerte, viene presentata un’interfaccia utente privata di alcune componenti. Ad esempio, si supponga che l’utente non sia abilitato all’inserimento dei documenti e alla gestione dei Forecast; l’interfaccia che gli sarà presentata viene mostrata nella figura sottostante. FIGURA 47 - ESEMPIO FUNZIONALITA' LIMITATE Come si può notare, la sidebar non include più le voci “Documentazione” e “Forecast”. 3.5.3 Valutazione responsività Si presentano alcuni screenshots con lo scopo di illustrare come l’interfaccia utente si adatti al cambio di risoluzione su differenti dispositivi mobile.
  73. 73. 68 1. Test su dispositivo iPad mini(768x1024 px) FIGURA 48 – REPORT CONFRONTO SU IPAD MINI (768X1024 PX) Come si evince dalla Figura 48, la sidebar viene eliminata e il menu per la navigazione dell’applicazione viene collocato in alto, nella notification bar. Per espanderlo è sufficiente premere il pulsante in alto a destra (vedi Figura 49).
  74. 74. 69 FIGURA 49 - INSERIMENTO DOCUMENTAZIONE SU IPAD MINI (768X1024 PX)
  75. 75. 70 FIGURA 50 - REPORT COMPONENTI OFFERTA SU IPAD MINI (1024X768 PX) Ruotando il dispositivo la sidebar ricompare in quanto la larghezza dello schermo è sufficientemente grande da consentire l’utilizzo dell’applicativo in questa modalità. Tale caratteristica è insita nel template grafico utilizzato e si avvale delle cosiddette Media Queries18 . 18 Le Media Queries sono dei moduli CSS3 che consentono alla pagina web che li include di usare diversi stili CSS sulla base di alcune caratteristiche del device che effettua la richiesta (per la pagina medesima).
  76. 76. 71 1. Test su dispositivo Nokia Lumia(480x800 px) FIGURA 51 - APERTURA FORECAST SU NOKIA LUMIA (480X800 PX)
  77. 77. 72 FIGURA 52 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX) FIGURA 53 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX)
  78. 78. 73 4 Conclusioni 4.1 Obiettivi L’obiettivo del progetto di tesi prevedeva la progettazione e realizzazione di un’applicazione web che consentisse il caricamento di dati aziendali su una struttura dati di supporto e la conseguente consultazione di specifici report; regolando al tempo stesso l’accesso e le funzionalità messe a disposizione degli utenti finali. Gli obiettivi prefissati possono considerarsi complessivamente raggiunti, sebbene non tutti i requisiti emersi durante la fase di analisi siano stati soddisfatti. Si tenga presente che, già in fase di progettazione, si è valutato insieme al responsabile di progetto di trascurare alcuni dei requisiti registrati per tenerne eventualmente conto in una seconda versione del prototipo. Le funzionalità che si possono riscontrare nell’applicativo realizzato si possono riassumere nell’elenco che segue.  Upload (ed eventuale sovrascrittura) dei fogli di calcolo SFA e CoGe con conseguente archiviazione dei dati in una base di dati relazionale.  Consultazione dei report relativi al processo di Allineamento SFA-CoGe e di chiusura del Forecast corrente, con possibilità di filtraggio in base a BU e Forecast (solo per l’anno corrente).  Gestione di apertura e chiusura Forecast.  Autenticazione dell’utente su Active Directory.  Discriminazione delle informazioni e delle funzionalità rese disponibili all’utente in base a specifici criteri di visibilità. Mentre, i requisiti non soddisfatti comprendono:  [UR_DOC_04]: non è stata implementata la gestione delle denominazioni multiple di un cliente;  [UR_SUP_01]: sebbene il software sia stato realizzato in un ottica di responsività non tutti i contenuti risultano completamente fruibili da un dispositivo mobile. Esempio di ciò sono le scrolling list che permettono di selezionare BU e Forecast.  [UR_USA_01]: il requisito di usabilità è stato soddisfatto solo in parte, poichè in taluni casi l’applicativo non assiste adeguatamente l’utente durante l’utilizzo. Ad esempio, al verificarsi di problemi legati all’upload dei fogli di calcolo anzichè fornire un errore generico il sistema dovrebbe indicare all’utente la precisa causa del problema o, perlomeno, fornire un’ipotesi.  [UR_AFF]: non essendo stata effettuata alcuna analisi relativa alla sicurezza del sistema il requisito può ritenersi non soddisfatto. 4.2 Sviluppi futuri In futuro, in un’ottica maggiormente orientata al “mobile” si potrà pensare all’introduzione di componenti grafici progettati esclusivamente per agevolare la fruizione di contenuti attraverso dispositivi mobili. Componenti peraltro forniti anche con le librerie di Kendo UI.
  79. 79. 74 Si ipotizza che altri possibili sviluppi potranno derivare dall’introduzione di alcune variazioni sul processo di monitoraggio sopra delineato; infatti, a parere dell’autore, si potrebbe trarre beneficio (in termini di numero di operazioni da svolgere) dalle seguenti considerazioni.  I dati potrebbero venire letti direttamente dai sistemi di supporto al management attraverso un meccanismo di importazione automatica.  L’applicativo potrebbe consentire la visualizzazione e l’aggiornamento dei documenti SFA e CoGe rendendo superflua la sovrascrittura dei documenti e mantenendo al tempo stesso uno storico delle versioni precedenti alle modifiche. Infine, relativamente all’amministrazione del sistema, risulta quasi indispensabile un pannello di controllo per la gestione delle utenze, dei ruoli e delle funzionalità, cosa che al momento avverrebbe attraverso il DBMS in uso. Si sottointende che tra i possibili sviluppi futuri sia compreso l’adempimento dei sopracitati requisiti non soddisfatti. 4.3 Opinioni personali La progettazione e lo sviluppo dell’applicativo in oggetto hanno permesso di scontrarsi con alcune problematiche abbastanza frequenti nell’ambito del web development, quali:  l’autenticazione dell’ utente e l’interazione con un un sistema di directory service;  l’integrazione di un template grafico sviluppato da terzi e la successiva modifica di alcune regole CSS di cui si compone;  l’incompatibilità tra plugin sviluppati da fornitori differenti;  la ricerca, l’analisi e l’utilizzo di librerie che consentissero la lettura di documenti esterni al sistema. Inoltre, uno degli aspetti più importanti del lavoro effettuato, attiene la sperimentazione e implementazione di nuove tecnologie prima sconosciute o note in modo solo superficiale all’autore. Compiti quali l’individuazione, lo studio e l’utilizzo di queste tecnologie, sono stati svolti in completa autonomia, pur confrontandosi periodicamente con il tutor aziendale. Infine, il confronto con un progetto di dimensioni considerevoli ha permesso altresì di studiare e applicare metodologie di progettazione conosciute solo a livello teorico, come ad esempio gli Use cases diagrams, gli Activity diagrams e i Mockup. Da non tralasciare l’importanza derivante dall’esperienza cumulata praticando un tirocinio in un contesto aziendale reale. 4.4 Stato attuale L’applicativo è in fase di collaudo, una volta eseguiti i test necessari e operati gli opportuni accorgimenti verrà sottoposto all’amministrazione centrale di Cluster Reply per una valutazione operativa, a cui seguirà l’eventuale messa in produzione.
  80. 80. 75 5 Bibliografia Allen Scott, 2012. Pluralsight - Building Applications with ASP.NET MVC 4. [Online course] Available at: http://pluralsight.com/training/Courses/TableOfContents/mvc4-building Allen Scott, 2013. Pluralsight - ASP.NET MVC 4 Fundamentals. [Online course] Available at: http://www.pluralsight.com/training/Courses/TableOfContents/mvc4 Allen Scott, 2013. Pluralsigth - Introduction to Bootstrap. [Online course] Available at: http://www.pluralsight.com/training/Courses/TableOfContents/bootstrap-introduction Bochicchio D., Mostarda S., Civera C., Golia R., 2010. ASP.NET 4.0 in C# e VB. Guida completa per lo sviluppatore. Hoepli Editore. KeenThemes, 2013. Metronic - Admin Dashboard Template, Documentation For Version 1.5.3. [Online] Available at: http://themeforest.net/item/metronic-responsive-admin-dashboard-template/4021469 Liberty Jesse, 2013. Pluralsight - Kendo and MVC From Scratch. [Online course] Available at: http://www.pluralsight.com/training/Courses/TableOfContents/kendo-mvc-from- scratch Library, Microsoft MSDN, s.d. ASP.NET Session State Overview. [Online] Available at: http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx Library, Microsoft MSDN, s.d. Directory Services Technical Articles. [Online] Available at: http://msdn.microsoft.com/en-us/library/hh703253(v=vs.85).aspx Library, Microsoft MSDN, s.d. Open XML SDK 2.5. [Online] Available at: http://msdn.microsoft.com/en-us/library/office/bb448854.aspx Library, Microsoft MSDN, s.d. Using System.DirectoryServices to Search the Active Directory. [Online] Available at: http://msdn.microsoft.com/en-us/library/ms973834.aspx#dotnetadsearch_topic1 Library, Microsoft TechNet, 2010. Active Directory Searches Technical Reference. [Online] Available at: http://technet.microsoft.com/en-us/library/cc728370(v=ws.10).aspx Microsoft MSDN, Data Developer Center, s.d. Code First Data Annotations. [Online] Available at: http://msdn.microsoft.com/en-us/data/jj591583.aspx Ramez A. Elmasri, S. B. N., 2007. Sistemi di basi di dati. Fondamenti. Quinta edizione, a cura di: Pearson Editore. Rolando Guay Paz Josè, 2013. Beginning ASP.NET MVC 4, a cura di: Apress Editore. Telerik, s.d. Complete Kendo UI Documentation. [Online] Available at: http://docs.telerik.com/kendo-ui/
  81. 81. 76 Vugt, W. v., 2007. Open XML The markup explained. [Online] Available at: http://openxmldeveloper.org/cfs-filesystemfile.ashx/__key/communityserver- components-postattachments/00-00-00-19-70/Open-XML-Explained.pdf

×