Università degli Studi di Trieste

Dipartimento di Ingegneria e Architettura
Corso di Laurea Triennale in Ingegneria dell’...
Indice
Introduzione .........................................................................................................
2.3. Progettazione logica ............................................................................................... ...
Introduzione
Il progetto consiste nel realizzare un’applicazione che aiuti l’organizzazione degli ambienti
di lavoro di un...
Si presenta un riassunto dei seguenti quattro capitoli.
Il primo espone le possibili strade da seguire per la realizzazion...
1. Analisi
Per poter realizzare un progetto di questo tipo, la prima scelta da effettuare è la tecnologia
su cui sviluppar...
1.1. Prime decisioni

Considerata la difficoltà, almeno in una fase di sviluppo iniziale, di dover scrivere la stessa
appl...
1.2. Obiettivi

L’obiettivo principale è quello di creare un database di supporto all’applicazione web. Esso
deve essere a...
Tra il “Visual Basic” e il “C#” si è preferito scegliere il secondo, poiché è il linguaggio
object-oriented che più somigl...
2. Documentazione del database

2.1. Raccolta dei requisiti

In questa fase, che precede la progettazione, è necessario el...
più company. Solo gli utenti registrati ad una company possono vedere le fotografie e
gli oggetti che le appartengono e so...
Si decide quindi di salvare i rapporti

e

.

sono

nell’angolo

superiore sinistro. Inoltre è previsto che più oggetti si...
2.1.3. Requisiti di carico
L’utente come prima operazione deve registrarsi al sito. Può poi cominciare a caricare
delle fo...
2.2. Progettazione concettuale

2.2.1. Glossario dei termini

TERMINE
Ambiente di lavoro
User

Fotografia
Oggetto

Company...
Frasi relative agli ambienti


Con l’espressione ambienti di lavoro si intente qualsiasi luogo che si desidera
organizzar...
Frasi relative agli oggetti


Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo
motivo p...
-

Le company si dividono in due categorie:
1. Private (caso tipico). La registrazione è su invito di un utente già iscrit...
2.2.3.1. Raffinamento entità user e company

USER
USER

ATTIVO
ATTIVO

COMPANY
COMPANY

NON
NON
ATTIVO
ATTIVO

APERTA
APER...
2.2.3.3. Ulteriori entità e associazioni

PROPRIETÀ
O-C

OGGETTO
OGGETTO

AGGIUNTA

VALORE
VALORE

COMPANY
COMPANY

PARAME...
2.2.5. Analisi delle entità
AMBIENTE
AmbienteID
Nome
Descrizione

Identificativo univoco assegnato ad ogni ambiente.*
Nome...
COMPANY
CompanyID
Nome
DataCreazione
Descrizione

Identificativo univoco assegnato ad ogni company.*
Nome della company.
D...
2.2.6. Analisi delle associazioni e delle cardinalità
OGGETTO – INSERIMENTO
Collega le entità oggetto e inserimento in mod...
COMPLETAMENTO
Collega le entità valore e parametro. Serve per associare i parametri ai relativi valori.
Cardinalità
Uno a ...
2.2.7. Regole di business

1. Un oggetto o una fotografia devono appartenere a un utente o (esclusivo) a una
company.
2. U...
2.2.8. Schema E – R finale con attributi e cardinalità

X

Y
1, 1

Posizione

Data
1, 1

INSERIMENTO
INSERIMENTO
1, N

I-U...
2.3. Progettazione logica

2.3.1. Tavola dei volumi
ENTITY
Ambiente
User

Attivo

Non attivo
Fotografia
Oggetto
Company
...
2.3.2. Tavola delle operazioni
OPERAZIONI

TIPO

Ricerca dell’ultima posizione di un oggetto
Ricerca delle posizioni prece...
X
Data
1, 1

AmbienteID Nome Descrizione
I-F

INSERIMENTO
INSERIMENTO
1, N

I-U

0, 1

0, N
PASSATO
PASSATO

(2)

1, 1

Co...
2.3.3.2. Operazione 2

Schema dell’operazione: inserimento di un oggetto. L’operazione si divide in:


Trova tutte le fot...
CONCETTO
Company
Proprietà C – F
Fotografia
Oggetto
Proprietà O – C
O–U
Ultimo inserimento
I–F
I–U

E
R
E
E
R
R
E
R
R

Agg...
N.B. L’associazione Completamento non crea nessuna ridondanza (essa infatti non
diventerà un vincolo di tipo chiave estern...
2.3.5. Eliminazione delle gerarchie

Inserimento:


Si decide di mantenere separate le entità ultimo inserimento e inseri...
2.3.7. Scelta degli identificatori primari

Si introducono dei codici per avere degli identificatori migliori sulle entità...
2.3.9. Schema E – R ristrutturato

Data

1, 1
0-U

Y

X

U-F

ULTIMO
ULTIMO
INSERIMENTO
INSERIMENTO

1, 1

0, N

U-U

0, 1...
2.3.10. Traduzione verso il relazionale – schema logico

tblUltimoInserimento
PK,FK1

oggettoID

FK2
FK3

data
x
y
fotogra...
2.4. Schema fisico

tblUltimoInserimento
oggettoID
data
x
y
fotografiaID
userID

tblInserimentoPassato
insPassatoID
data
x...
2.5. Documentazione aggiuntiva

2.5.1. Viste

Si espongono le viste dedicate atte a soddisfare le seguenti richieste:
1) U...
trgObjRemoved: Gli oggetti rimasti senza un ultimo inserimento vengono cancellati.
trgObjMoved: Un oggetto sportato deve a...
2.5.3. Sorgenti dei trigger e stored procedure
Vengono esposti e brevemente commentati i codici scritti in “T-SQL” per la ...
2.5.3.2. trgAdminIns

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
3...
2.5.3.3. trgParamValue

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

CREATE TRI...
2.5.3.4. wiliGetCompanies

1
2
3
4
5
6
7
8
9

Go
CREATE PROCEDURE dbo.wiliGetCompanies ( @userID BIGINT ) AS
SELECT vwUser...
3. Documentazione dell’applicazione

3.1. Interfaccia

Immagine 1

Questa è la pagina per la ricerca di un oggetto. In alt...
Immagine 2

Il risultato della ricerca compare sul lato destro della schermata. Qui sono visibili le
miniature della fotog...
Immagine 3

Si noti che il passaggio da una schermata all’altra non prevede il caricamento di una
nuova pagina web.
Si è s...
3.2. Implementazione

Il capitolo ha lo scopo di esporre il funzionamento interno del prototipo dell’applicazione.
Per sem...
Lo Script 1 cerca di ricevere tutte le company di cui l’utente fa parte con i relativi parametri
di ricerca aggiuntivi. Un...
La funzione “processRequest” si occupa di serializzare e inviare i dati del form all’URL
“GetObj.aspx”.
Successivamente si...
1 function fillNewSection(rowclicked) {
var divShadow = $('<div id="shadow" ></div>'),
2
divZoom = $('<div id="zoom" ></di...
3.2.1.4. Stile risposta

1 div#response {
width: 700px;
2
overflow-y: auto;
3
4 }
5
div#response > table {
6
border-collap...
3.2.2. Lato server
3.2.2.1. GetCompanies

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30...
Il codice riportato nella pagina precedente genera una risposta contenente le company di
un utente e i relativi parametri ...
Si noti che l’id della company è uguale a “-1” solo nel caso in cui nessuna company è stata
selezionata dall’utente ed egl...
4. Conclusioni
Entrambi gli obiettivi prefissati sono stati raggiunti.
1) Il database è stato completamente progettato e r...
Bibliografia
-

Pellegrino Principe, Apogeo, HTML5 CSS3 JavaScript (2012).

-

Atzeni Paolo, McGraw-Hill, Basi di dati Mod...
Upcoming SlideShare
Loading in …5
×

Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro

734 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
734
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro

  1. 1. Università degli Studi di Trieste Dipartimento di Ingegneria e Architettura Corso di Laurea Triennale in Ingegneria dell’Informazione Curriculum Informatica Progettazione e sviluppo di un applicativo web e della sua base di dati per l'organizzazione di ambienti di lavoro Relatore: Chiar.mo Prof. Maurizio Fermeglia Laureando: Stefano Dudine Anno accademico 2012/2013
  2. 2. Indice Introduzione ....................................................................................................................... 1 1. Analisi ............................................................................................................................. 3 1.1. Prime decisioni ......................................................................................................... 4 1.2. Obiettivi .................................................................................................................... 5 1.3. Tecnologie software utilizzate .................................................................................. 5 2. Documentazione del database ....................................................................................... 7 2.1. Raccolta dei requisiti ................................................................................................ 7 2.1.1. Descrizione.......................................................................................................................... 7 2.1.2. In dettaglio .......................................................................................................................... 9 2.1.3. Requisiti di carico .............................................................................................................. 10 2.2. Progettazione concettuale ...................................................................................... 11 2.2.1. Glossario dei termini......................................................................................................... 11 2.2.2. Strutturazione dei requisiti ............................................................................................... 11 2.2.3. Schema scheletro.............................................................................................................. 14 2.2.4. Schema E – R finale ........................................................................................................... 16 2.2.5. Analisi delle entità ............................................................................................................ 17 2.2.6. Analisi delle associazioni e delle cardinalità ..................................................................... 19 2.2.7. Regole di business............................................................................................................. 21 2.2.8. Schema E – R finale con attributi e cardinalità ................................................................. 22 I
  3. 3. 2.3. Progettazione logica ............................................................................................... 23 2.3.1. Tavola dei volumi .............................................................................................................. 23 2.3.2. Tavola delle operazioni ..................................................................................................... 24 2.3.3. Tavole degli accessi ........................................................................................................... 24 2.3.4. Analisi delle ridondanze.................................................................................................... 27 2.3.5. Eliminazione delle gerarchie ............................................................................................. 29 2.3.6. Partizionamento / accorpamento di concetti .................................................................. 29 2.3.7. Scelta degli identificatori primari ..................................................................................... 30 2.3.8. Normalizzazione................................................................................................................ 30 2.3.9. Schema E – R ristrutturato................................................................................................ 31 2.3.10. Traduzione verso il relazionale – schema logico ............................................................ 32 2.4. Schema fisico ......................................................................................................... 33 2.5. Documentazione aggiuntiva ................................................................................... 34 2.5.1. Viste .................................................................................................................................. 34 2.5.2. Trigger ............................................................................................................................... 34 2.5.3. Sorgenti dei trigger e stored procedure ........................................................................... 36 3. Documentazione dell’applicazione ................................................................................ 40 3.1. Interfaccia .............................................................................................................. 40 3.2. Implementazione .................................................................................................... 43 3.2.1. Lato client ......................................................................................................................... 43 3.2.2. Lato server ........................................................................................................................ 48 4. Conclusioni ................................................................................................................... 51 Bibliografia ....................................................................................................................... 52 II
  4. 4. Introduzione Il progetto consiste nel realizzare un’applicazione che aiuti l’organizzazione degli ambienti di lavoro di un’azienda. I magazzini e i punti vendita in genere sono colmi di oggetti sistemati su mensole e scaffali e cercare un oggetto in particolare, di cui si conoscono solo determinate caratteristiche, può risultare complicato sia per il personale che per i clienti. Sotto queste condizioni, l’applicazione ha lo scopo di velocizzare la ricerca. In un secondo momento si è pensato che tale applicazione potrebbe esser utile non solo ad un’azienda ma a qualsiasi organizzazione di persone che desideri condividere la posizione di oggetti di interesse comune, anche in ambito non lavorativo. È necessario che la persona che vuole registrare la posizione di un oggetto generico fotografi l’ambiente in cui si trova e indichi la posizione dell’oggetto all’interno della fotografia. Si potranno poi specificare delle caratteristiche che permetteranno di individuarlo in una successiva ricerca. L’applicazione dovrà quindi consentire un inserimento agevole di fotografie e oggetti e dovrà permettere la ricerca della loro posizione con l’immissione da parte dell’utente di alcune parole chiave. Si crede che un approccio di questo tipo al problema dell’organizzazione degli ambienti sia innovativo. Attualmente è comune trovare un’organizzazione gerarchica dei magazzini: si utilizza una sorta di schedario che indica in quale sezione si trova l’oggetto cercato (es. edificio C, magazzino 5, scaffale 6, mensola B, sezione 9/F). L’idea di introdurre delle fotografie per supportare la ricerca garantisce al personale un immediato impatto visivo, consentendogli di individuare immediatamente l’oggetto anche se ancora non si trova sul posto. Si mira quindi a sfruttare in maniera diversa la memoria sensoriale visiva a breve termine delle persone, consentendo la percezione dello spazio, delle posizioni e dei colori invece di una sequenza di numeri e lettere. Si consideri che l’applicazione è stata interamente ideata dal candidato e tutto il lavoro riguardante questo progetto è a suo carico. 1
  5. 5. Si presenta un riassunto dei seguenti quattro capitoli. Il primo espone le possibili strade da seguire per la realizzazione del progetto, tenendo in considerazione gli eventuali hardware a cui l’applicazione potrebbe esser destinata. Si effettuano e si giustificano le scelte fatte e vengono evidenziati gli obiettivi della tesi. Il capitolo si conclude con la rassegna delle tecnologie software utilizzate. Il secondo contiene l’intera documentazione relativa al database. Essa comprende tutte le fasi della progettazione. Nella parte finale del capitolo si trova la descrizione delle viste, di alcuni trigger e stored procedure che verranno esposte all’applicazione. La prima parte del terzo capitolo è dedicata alla presentazione dell’interfaccia grafica: vengono mostrate e commentate alcune schermate e si spiega come devono essere utilizzate dall’utente. La seconda parte è riservata all’implementazione dell’applicazione e all’esposizione di alcuni frammenti del codice sorgente. Il quarto e ultimo capitolo contiene la quantizzazione del lavoro svolto in termini di numero di righe di codice scritte seguite da alcune considerazioni finali sul progetto. 2
  6. 6. 1. Analisi Per poter realizzare un progetto di questo tipo, la prima scelta da effettuare è la tecnologia su cui sviluppare l’applicazione. Si pensa che la resa migliore si avrebbe utilizzando dispositivi mobili, quali tablet o smartphone, poiché la fase di inserimento sarebbe notevolmente agevolata. Si potrebbero infatti scattare fotografie agli ambienti direttamente dalla fotocamera del dispositivo (ancora meglio se in modalità panoramica) e aggiungere “al volo” un oggetto semplicemente toccando un punto del touchscreen. Tuttavia l’applicazione potrebbe essere fruibile anche da un computer qualsiasi, per l’inserimento si potrebbero usare fotografie scattate in precedenza. Non ci sarebbero invece grosse differenze per quanto riguarda la fase di ricerca. In entrambi i casi si devono digitare (o eventualmente pronunciare) i valori dei parametri di ricerca dell’oggetto voluto. Poiché si mira a divulgare l’applicazione il più possibile si deve tener conto della diffusione dei prodotti e dei sistemi operativi disponibili e quindi di quante volte il codice deve essere per la maggior parte riscritto. Un’altra scelta da effettuare immediatamente è dove memorizzare i dati delle fotografie, oggetti, ambienti etc., di cui l’applicazione ha bisogno per funzionare. Le alternative sono le seguenti: - Ogni versione dell’applicazione che viene distribuita deve essere accompagnata da una sua base di dati, la cui proprietà fisica è e rimane dell’organizzazione. In questo modo l’accesso ai dati potrebbe avvenire attraverso una rete interna privata. - I dati di tutte le organizzazioni sono conservati in un unico database centralizzato che viene acceduto attraverso Internet. 3
  7. 7. 1.1. Prime decisioni Considerata la difficoltà, almeno in una fase di sviluppo iniziale, di dover scrivere la stessa applicazione più di una volta per renderla compatibile con la maggior parte dei dispositivi, si decide di cominciare con un’applicazione web, accessibile e fruibile da tutti attraverso uno qualsiasi dei principali (più diffusi) browser web moderni. In un secondo momento si può pensare di sviluppare applicazioni indipendenti, dedicate ai singoli dispositivi. Per quanto riguarda la scelta di dove salvare i dati, si decide per un unico database centrale. Ciò comporta degli svantaggi, poiché bisognerà occuparsi di mantenere attiva una base di dati di notevoli dimensioni, con tutti gli oneri di gestione che ne comporta. Inoltre le organizzazioni che decidono di usufruire dell’applicazione devono fare un “atto di fede” nei confronti dell’amministrazione del database: dovranno infatti fidarsi che i loro dati e fotografie rimangano privati (se così desiderano) e in buone mani. Infine è richiesta una costante connessione ad Internet, ma questo ad oggi non è un problema che spaventa più di tanto. I vantaggi che si ottengono sono superiori. Si deve pensare che affiancare un database alla distribuzione dell’applicazione, e quindi la creazione di una rete interna, è quasi sempre un impegno indesiderato per l’organizzazione. L’utilizzo dell’applicazione sarebbe possibile solo quando si è sotto la copertura di tale rete e, cosa di gran lunga più importante, si rinuncerebbe completamente al lato “social” dell’applicazione, che sarebbe orientata solo all’azienda e non ad una persona qualsiasi. 4
  8. 8. 1.2. Obiettivi L’obiettivo principale è quello di creare un database di supporto all’applicazione web. Esso deve essere ampiamente documentato in tutte le fasi della sua progettazione. Poiché si vuole lasciare aperta la possibilità di creare applicazioni client ad hoc (una per ogni sistema operativo) che andranno ad interagire con lo stesso database, particolare importanza deve esser data alla conservazione dell’integrità dei dati. Si deve prevedere che il database possa crescere rapidamente di dimensioni dal momento che dovrà memorizzare i dati di tutte le organizzazioni. Si deve quindi eseguire un’attenta analisi dei costi sulla base di dati di carico ipotetici e giustificare le scelte fatte relativamente alla sua struttura. L’obiettivo secondario è realizzare un prototipo dell’applicazione: si deve simulare la fase di ricerca di un oggetto ad autenticazione del client già avvenuta. 1.3. Tecnologie software utilizzate Viste le competenze acquisite dal candidato nel corso di database, il modello dei dati scelto è quello relazionale, il motore database è “Microsoft SQL Server” e lo strumento di configurazione e gestione utilizzato è “SQL Management Studio” (versioni 2008 R2). L’accesso ai dati è previsto con “ADO.NET”, poiché fornisce un accesso ottimale quando si utilizza Microsoft SQL Server ed è progettato per accessi disconnessi. Ciò è appropriato perché il tipo di applicazione web che si vuole realizzare sarà di tipo “mordi e fuggi”, ovvero chiederà i dati di cui ha bisogno in quel momento, il browser li elaborerà e successivamente effettuerà una nuova richiesta asincrona. Mantenere aperta una connessione in questo tipo di configurazione implicherebbe un inutile consumo di risorse. L’ambiente di sviluppo utilizzato è “Microsoft Visual Studio 2012”. 5
  9. 9. Tra il “Visual Basic” e il “C#” si è preferito scegliere il secondo, poiché è il linguaggio object-oriented che più somiglia come sintassi a “JAVA”, studiato nel corso di programmazione. Per quanto riguarda l’interfaccia utente, essa è suddivisa in tre livelli (o layer): 1 Il layer strutturale Rappresenta lo scheletro della pagina web. I marcatori (o “tag”) che lo compongono stabiliscono delle regole sulla sua struttura e danno già un indizio su come questa verrà formattata e modificata a seguito di un azione dell’utente. Si decide di utilizzare l’”HTML5” poiché mette a disposizione dei nuovi elementi pratici per interagire con fotografie, mappe e geolocalizzazioni. L’HTML5 però è ancora lontano da essere uno standard e per gli scopi prefissati, si dovrà prestare attenzione a mantenere la compatibilità con tutti i browser di maggiore diffusione. 2 Il layer di presentazione È composto dai fogli di stile (CSS) della pagina web che sono lo strumento fondamentale per definire come un documento HTML deve essere visualizzato da un browser. Anche in questo caso si utilizzeranno solamente quelle proprietà che sono supportate dai browser in modo standard. 3 Il layer di interazione È composto da tutti gli script che permettono ad un utente di interagire con la pagina web. Si utilizza il linguaggio di scripting “JavaScript” e la libreria “jQuery” per la manipolazione del “DOM”, per la gestione degli eventi, e la generazione delle HTTP Request. Anche se si tratta di una tecnica per lo sviluppo di applicazioni web e non di una tecnologia, sembra opportuno specificare in questo capitolo che si vuole utilizzare “Ajax” per permettere una maggior interattività con l’utente. Per lo scambio dei dati, almeno in un primo momento, non si utilizzerà l’XML bensì la JSON poiché essa è concisa e conveniente per la programmazione orientata ad oggetti in JavaScript. Tuttavia la notazione presenta dei limiti: è un formato testuale minimale tramite il quale è possibile serializzare e deserializzare solo oggetti, stringhe, numeri, valori booleani e null; per questo motivo si pensa che in futuro si adopererà l’XML. 6
  10. 10. 2. Documentazione del database 2.1. Raccolta dei requisiti In questa fase, che precede la progettazione, è necessario elencare e descrivere in maniera approfondita i dati di interesse per l’applicativo. Si elencano in seguito le operazioni principali effettuate da un utente e si fanno delle stime sulla loro frequenza. 2.1.1. Descrizione Si vuole realizzare un database per un’applicazione web per l’organizzazione di ambienti di lavoro. Con l’espressione ambienti di lavoro si intente qualsiasi luogo che si desidera organizzare: un magazzino, un’officina, un ripiano etc. È previsto che l’utente di questa applicazione scatti delle fotografie agli ambienti, le carichi sul sito e registri delle informazioni sugli oggetti in esse contenuti (in particolare la posizione) e in un secondo momento li ricerchi. Non si spiega in questo capitolo come tali informazioni vengano inserite dall’utente (si veda il capitolo 3.1.). In fase di registrazione al sito, ogni user deve dichiarare nome, cognome, sesso, data di nascita, email e password di accesso. Tuttavia, per motivi di sicurezza, le password non sono salvate nel database. Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà della company e non più dell’utente. Un utente può quindi appartenere a nessuna, una o 7
  11. 11. più company. Solo gli utenti registrati ad una company possono vedere le fotografie e gli oggetti che le appartengono e soltanto alcuni tra loro (gli amministratori) sono autorizzati all’inserimento e alla modifica. Ogni company dovrà averne almeno un amministratore. Le company si dividono in due categorie: 1 2 Private (caso tipico). La registrazione è su invito di un utente già iscritto. Aperte. Tutti gli utenti possono registrarsi. Per ognuna di esse si devono conoscere gli utenti che ne fanno parte e i loro privilegi d’accesso, un nome, la data di creazione ed eventualmente una descrizione testuale. Per ogni fotografia caricata si desidera salvare la data di caricamento e il nome del posto preciso in cui è stata scattata (es. magazzino n.3), l’utente o la company a cui appartiene, gli oggetti che contiene, un’eventuale descrizione per permettere il salvataggio di informazioni aggiuntive, l’url relativo dei file immagine sul server (un’immagine sarà salvata sul server in più formati per accelerare i caricamenti delle pagine web). Uno stesso luogo preciso può avere diverse fotografie (un magazzino abbastanza grande o contenente più scaffali). Per futuri sviluppi dell’applicazione si desidera memorizzare le coordinate “geotag” dell’immagine. Per ogni oggetto si vogliono salvare le caratteristiche che serviranno a trovarlo. Obbligatoriamente si vuole conoscere il nome, l’utente o la company a cui appartiene, la foto in cui è e quelle in cui era inserito con relative date, posizioni e amministratori che hanno fatto lo spostamento. Opzionalmente potrebbe esser specificato il colore, il materiale, una descrizione e una classe di utilità. Futuri sviluppi dell’applicazione prevedono che l’amministrazione di una company possa definire nuovi parametri di ricerca (es. marca, modello, dimensioni etc.) e ogni parametro possa avere più di un valore associato (es. in un magazzino di pezzi di ricambio per automobili potrebbe esser utile specificare, per ogni pezzo, i modelli di automobile su cui si adatta). Per quanto riguarda la posizione non si possono salvare le coordinate dell’oggetto perché si avrebbe una dipendenza con le dimensioni dell’immagine. Per esigenze di spazio sul server, le immagini potrebbero esser ridimensionate e si renderebbe quindi necessario andare a modificare tutte le coordinate. 8
  12. 12. Si decide quindi di salvare i rapporti e . sono nell’angolo superiore sinistro. Inoltre è previsto che più oggetti si trovino molto vicini tra loro o nello stesso contenitore, in questi casi avranno la stessa posizione. 2.1.2. In dettaglio Un oggetto o una fotografia appartengono a un utente o (esclusivo) a una company. Un utente o una company che possiede una fotografia possiede anche gli oggetti inseriti al suo interno. È una ridondanza che verrà analizzata nelle pagine seguenti. Spostare un oggetto da una fotografia a un’altra e definire parametri di ricerca aggiuntivi sono operazioni riservate alle company. Se un utente o una company vengono cancellati, tutte le fotografie di loro proprietà vengono cancellate. Se una fotografia viene cancellata, tutti gli oggetti in essa contenuti devono essere cancellati. Se un oggetto viene cancellato tutti i suoi inserimenti vengono cancellati. Un utente può inserire un oggetto in una fotografia solo se è di sua proprietà o se è amministratore della company a cui essa appartiene. Quando un amministratore abbandona una company, i suoi inserimenti rimangono ma non sono più associabili a lui. Se una company viene abbandonata da tutti gli utenti, essa viene cancellata. Un utente che non effettua nessuna operazione da più di sei mesi è da considerarsi non attivo. 9
  13. 13. 2.1.3. Requisiti di carico L’utente come prima operazione deve registrarsi al sito. Può poi cominciare a caricare delle fotografie, inserire oggetti e creare delle company e fare delle ricerche. Poiché l’applicazione è ancora in fase di sviluppo non sono disponibili delle medie sul numero di operazioni effettuate al giorno da ogni utenza. Tuttavia si possono fare delle stime. Si considera dapprima una company di dimensioni ridotte (5 user), per esempio una piccola attività o una famiglia che desidera organizzare piccoli vani, scaffali o ripiani. Si pensa che nei primi giorni di utilizzo il numero di caricamenti sarà elevato: nel primo mese 8 fotografie e 20 oggetti per fotografia. Dopo il primo mese i caricamenti scendono: verranno modificati, cancellati o aggiunti al massimo 10 oggetti al mese e 1 foto ogni due. Lo stesso vale per una company di grandi dimensioni (20 user) che potrebbe occuparsi per esempio dell’organizzazione di un magazzino di pezzi di ricambio per automobili. Si crede che nei primi 3 mesi vengano caricate 50 fotografie e 1000+ oggetti e nei mesi successivi si effettuino modifiche a 4 foto e a 50 oggetti circa. Per quanto riguarda le ricerche di un oggetto si pensa che un utente di una piccola company effettui in media 6 ricerche al giorno mentre uno di una grande company ne faccia 20. Ottimisticamente per il primo anno di vita dell’applicazione, si supponga di dover gestire informazioni per 25 000 user, considerando che il 10% di questi non fa parte di nessuna company e che il 75% delle company siano di piccole dimensioni. 10
  14. 14. 2.2. Progettazione concettuale 2.2.1. Glossario dei termini TERMINE Ambiente di lavoro User Fotografia Oggetto Company DESCRIZIONE Luogo preciso in cui vengono scattate le fotografie Inteso come subject, persona ad un certo calcolatore provvista di credenziali d’accesso Scattata all’ambiente che si desidera organizzare Sono contenuti nelle fotografie, provvisti di caratteristiche che permettono di individuarli Formate da più utenti che desiderano condividere le fotografie SINONIMI Luogo COLLEGAMENTI Fotografia User Fotografia, Company, Oggetto Foto Ambiente, User, Company, Oggetto User, Fotografia User, Fotografia, Oggetto Tabella 1 2.2.2. Strutturazione dei requisiti Frasi di carattere generale  Si vuole realizzare un database per un’applicazione web per l’organizzazione di ambienti di lavoro.  È previsto che l’utente di questa applicazione scatti delle fotografie agli ambienti, le carichi sul sito e registri delle informazioni sugli oggetti in esse contenuti (in particolare la posizione) e in un secondo momento li ricerchi. 11
  15. 15. Frasi relative agli ambienti  Con l’espressione ambienti di lavoro si intente qualsiasi luogo che si desidera organizzare: un magazzino, un’officina, un ripiano etc.  Uno stesso luogo preciso può avere diverse fotografie (un magazzino abbastanza grande o contenente più scaffali). Frasi relative agli utenti  In fase di registrazione al sito, ogni user deve dichiarare nome, cognome, sesso, data di nascita, email e password di accesso. Tuttavia, per motivi di sicurezza, le password non sono salvate nel database (si veda il documento che descrive la gestione delle credenziali).  Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà della company e non più dell’utente. Un utente può quindi appartenere a nessuna, una o più company. Solo gli utenti registrati ad una company possono vedere le fotografie e gli oggetti che le appartengono e soltanto alcuni tra loro (gli amministratori) sono autorizzati all’inserimento e alla modifica. Frasi relative alle fotografie  Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà della company e non più dell’utente.  Per ogni fotografia caricata si desidera salvare la data di caricamento e il nome del posto preciso in cui è stata scattata (es. magazzino n.3), l’utente o la company a cui appartiene, gli oggetti che contiene, un’eventuale descrizione per permettere il salvataggio di informazioni aggiuntive, l’url relativo dei file immagine sul server (un’immagine sarà salvata sul server in più formati per accelerare i caricamenti delle pagine web). Uno stesso luogo preciso può avere diverse fotografie (un magazzino abbastanza grande o contenente più scaffali). Per futuri sviluppi dell’applicazione si desidera memorizzare le coordinate “geotag” dell’immagine. 12
  16. 16. Frasi relative agli oggetti  Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà della company e non più dell’utente.  Per ogni oggetto si vogliono salvare le caratteristiche che serviranno a trovarlo. Obbligatoriamente si vuole conoscere il nome, l’utente o la company a cui appartiene, la foto in cui è e quelle in cui era inserito con relative date, posizioni e amministratori che hanno fatto lo spostamento. Opzionalmente potrebbe esser specificato il colore, il materiale, una descrizione e una classe di utilità. Futuri sviluppi dell’applicazione prevedono che l’amministrazione di una company possa definire nuovi parametri di ricerca (es. marca, modello, dimensioni etc.) e ogni parametro possa avere più di un valore associato (es. in un magazzino di pezzi di ricambio per automobili potrebbe esser utile specificare, per ogni pezzo, i modelli di automobile su cui si adatta).  Per quanto riguarda la posizione non si possono salvare le coordinate dell’oggetto perché si avrebbe una dipendenza con le dimensioni dell’immagine. Per esigenze di spazio sul server, le immagini potrebbero esser ridimensionate e si renderebbe quindi necessario andare a modificare tutte le coordinate. Si decide quindi di salvare i rapporti  sono e . nell’angolo superiore sinistro. Inoltre è previsto che più oggetti si trovino molto vicini tra loro o nello stesso contenitore, in questi casi avranno la stessa posizione. Frasi relative alle company - Più utenti potrebbero voler condividere le stesse fotografie e oggetti, per questo motivo possono unirsi a formare delle company. Tali fotografie e oggetti diventano di proprietà della company e non più dell’utente. Un utente può quindi appartenere a nessuna, una o più company. Solo gli utenti registrati ad una company possono vedere le fotografie e gli oggetti che le appartengono e soltanto alcuni tra loro (gli amministratori) sono autorizzati all’inserimento e alla modifica. Ogni company dovrà averne almeno un amministratore. 13
  17. 17. - Le company si dividono in due categorie: 1. Private (caso tipico). La registrazione è su invito di un utente già iscritto. 2. Aperte. Tutti gli utenti possono registrarsi.  Per ognuna di esse si devono conoscere gli utenti che ne fanno parte e i loro privilegi d’accesso, un nome, la data di creazione ed eventualmente una descrizione testuale. 2.2.3. Schema scheletro INSERIMENTO AMBIENTE AMBIENTE OGGETTO OGGETTO PROPRIETÀ O-U PART - OF PROPRIETÀ O-C PROPRIETÀ U-F USER USER LOCALIZ FOTOGRAFIA FOTOGRAFIA ADMIN COMPANY COMPANY PROPRIETÀ F-C Figura 1 Si decide di utilizzare una strategia di progetto mista: si individuano i concetti principali, si realizza uno schema scheletro e, partendo da questo, si procede per raffinamenti. Tale strategia è simile all’inside-out, la differenza è che si parte da uno schema scheletro e non da un unico concetto. 14
  18. 18. 2.2.3.1. Raffinamento entità user e company USER USER ATTIVO ATTIVO COMPANY COMPANY NON NON ATTIVO ATTIVO APERTA APERTA PRIVATA PRIVATA Figura 2 Si individuano due generalizzazioni entrambe totali ed esclusive e ognuna con due specializzazioni. Gli utenti si dividono tra attivi e non, le company tra aperte e private. 2.2.3.2. Raffinamento associazione inserimento FOTOGRAFIA FOTOGRAFIA I-F INSERIMENTO INSERIMENTO 0-I I-U I-F OGGETTO OGGETTO 0-I INSERIMENTO INSERIMENTO 0-U ULTIMO ULTIMO PASSATO PASSATO FOTOGRAFIA FOTOGRAFIA I-U OGGETTO OGGETTO USER USER USER USER Figura 3 Si effettua la reificazione dell’associazione ternaria inserimento e la storicizzazione del concetto. Verrà analizzato più avanti se sia conveniente farlo. Anche qui si viene a creare una generalizzazione totale ed esclusiva con due specializzazioni: un inserimento può essere l’ultimo avvenuto oppure può esser seguito da uno più recente. Da notare che se esiste un inserimento passato deve necessariamente esistere un ultimo inserimento. 15
  19. 19. 2.2.3.3. Ulteriori entità e associazioni PROPRIETÀ O-C OGGETTO OGGETTO AGGIUNTA VALORE VALORE COMPANY COMPANY PARAMETRO PARAMETRO COMPL DEFINIZIONE Figura 4 Per dare la possibilità alle company di definire parametri di ricerca aggiuntivi per i propri oggetti si aggiungono le entità parametro e valore e le relative associazioni. 2.2.4. Schema E – R finale I-F INSERIMENTO INSERIMENTO 0-I I-U LOCALIZ 0-U ULTIMO ULTIMO PROPRIETÀ U-F PASSATO PASSATO AMBIENTE AMBIENTE PROPRIETÀ F-C FOTOGRAFIA FOTOGRAFIA ADMIN OGGETTO OGGETTO USER USER PROPRIETÀ O-U PART - OF NON NON ATTIVO ATTIVO ATTIVO ATTIVO PROPRIETÀ O-C COMPANY COMPANY DEFINIZIONE AGGIUNTA VALORE VALORE COMPL PARAMETRO PARAMETRO APERTA APERTA PRIVATA PRIVATA Figura 5 16
  20. 20. 2.2.5. Analisi delle entità AMBIENTE AmbienteID Nome Descrizione Identificativo univoco assegnato ad ogni ambiente.* Nome del luogo preciso in cui sono state scattate le foto. Informazioni aggiuntive sull’ambiente. Tabella 2 USER Email Nome Cognome Sesso DataNascita DataRegistrazione Un email dell’utente. Nome proprio dell’utente. Cognome. Sesso. Data di nascita. Data in cui l’utente ha effettuato la registrazione. Tabella 3 ATTIVO DataUltimaOperazione Indica quando un utente ha effettuato la sua ultima operazione di un utente. Tabella 4 NON ATTIVO Nessun attributo. Tabella 5 FOTOGRAFIA DataCaricamento Descrizione URL Geotag Num Data in cui la foto è stata caricata sul server. Descrizione per raccogliere informazioni aggiuntive sulla foto. Percorso dei file immagine sul server. Sono le coordinate GPS che indicano il punto dove la foto è stata scattata. Numera le foto scattate nello stesso ambiente. Tabella 6 OGGETTO OggettoID Nome Colore ClasseUtilità Materiale Descrizione Identificativo univoco assegnato ad ogni oggetto.* Nome dell’oggetto. Colore principale dell’oggetto.** Descrive in una parola l’utilità dell’oggetto.** Materiale principale dell’oggetto.** Informazioni sull’oggetto. Tabella 7 17
  21. 21. COMPANY CompanyID Nome DataCreazione Descrizione Identificativo univoco assegnato ad ogni company.* Nome della company. Data in cui è stata creata la company Informazioni sulla company. Tabella 8 APERTA Nessun attributo. Tabella 9 PRIVATA Nessun attributo. Tabella 10 INSERIMENTO Data Posizione Data con precisione sui secondi. Rappresenta quando è avvenuto l’inserimento. Rappresenta la posizione dell’oggetto nella fotografia. (Attributo composto). Tabella 11 ULTIMO Nessun attributo. Tabella 12 PASSATO Nessun attributo. Tabella 13 PARAMETRO Num Nome Descrizione NumMaxValori Numera i parametri di una stessa company. Nome del parametro. Informazioni aggiuntive. Numero massimo dei valori che possono esser associati a quel parametro. Tabella 14 VALORE Num Val Numera i valori associati ad uno stesso parametro. È una stringa che contiene il valore aggiunto all’oggetto. Tabella 15 * I codici sono introdotti subito quando gli attributi non sono sufficienti per l’identificazione di un’istanza dell’entità o sono opzionali. ** Potrebbero esser considerati attributi multivalore e quindi formare delle entità a sé stanti, tuttavia si preferisce, almeno per il momento, mantenere l’applicazione semplice e snellire la fase di caricamento di un oggetto comune. Se poi un’azienda desidera specificare più valori per un parametro può farlo utilizzando la gestione di parametri aggiuntivi. 18
  22. 22. 2.2.6. Analisi delle associazioni e delle cardinalità OGGETTO – INSERIMENTO Collega le entità oggetto e inserimento in modo da specificare quale sia l’oggetto inserito. Cardinalità Uno a molti: un oggetto può avere molti inserimenti nel corso del tempo ma un inserimento si riferisce a un solo oggetto. Tabella 16 OGGETTO – ULTIMO INSERIMENTO Collega le entità oggetto e ultimo inserimento in modo da specificare quale sia l’oggetto che deve essere inserito. Cardinalità Uno a uno: un oggetto deve avere un unico ultimo inserimento e un ultimo inserimento deve riferirsi a un solo oggetto. Tabella 17 INSERIMENTO – FOTOGRAFIA Collega le entità inserimento e fotografia per specificare dove un oggetto è stato inserito. Cardinalità Uno a molti: un inserimento deve riferirsi ad una sola fotografia mentre una fotografia può avere più inserimenti Tabella 18 INSERIMENTO – USER Collega le entità inserimento e user. Precisa chi sia l’utente che ha effettuato l’inserimento. Cardinalità Uno a molti: un inserimento può essere fatto da un utente solo, un utente può effettuare più inserimenti. Tabella 19 PROPRIETÀ OGGETTO – USER Collega le entità oggetto e user. Precisa chi sia l’utente proprietario dell’oggetto. Cardinalità Uno a molti: un oggetto può appartenere a un solo utente e un utente può essere proprietario di più oggetti. Tabella 20 PROPRIETÀ OGGETTO – COMPANY Collega le entità oggetto e company. Precisa chi sia la company proprietaria dell’oggetto. Cardinalità Uno a molti: un oggetto può appartenere a una sola company e una company può essere proprietaria di più oggetti. Tabella 21 AGGIUNTA Collega le entità oggetto e valore. Specifica quali siano i valori aggiuntivi degli oggetti. Cardinalità Uno a molti: ad un oggetto possono esser aggiunti molti valori ma un valore si riferisce ad un solo oggetto. Tabella 22 19
  23. 23. COMPLETAMENTO Collega le entità valore e parametro. Serve per associare i parametri ai relativi valori. Cardinalità Uno a molti: ad un parametro in generale possono esser associati diversi valori (numero massimo specificato dall’attributo NumMaxValori dell’entità parametro). Un valore invece corrisponde sempre ad un solo parametro. Tabella 23 DEFINIZIONE Collega le entità parametro e company. Specifica quale company abbia definito i parametri aggiuntivi di ricerca. Cardinalità Uno a molti: un parametro è definito da una sola company, una company può definire più parametri. Tabella 24 PROPRIETÀ USER – FOTOGRAFIA Collega le entità user e fotografia. Precisa chi sia l’utente proprietario della fotografia. Cardinalità Uno a molti: un utente può essere proprietario di più fotografie e una fotografia può appartenere ad un solo utente. Tabella 25 ADMIN Collega le entità user e company. Specifica chi siano gli utenti di una company con il permesso di modifica. Cardinalità Molti a molti: un utente può esser amministratore di molte company e una company può avere più di un amministratore. Tabella 26 PART – OF Collega le entità user e company. Specifica chi siano gli utenti di una company. Cardinalità Molti a molti: un utente può far parte di molte company e una company può esser composta da più utenti. Tabella 27 PROPRIETÀ FOTOGRAFIA – COMPANY Collega le entità fotografia e company. Precisa chi sia la company proprietaria della fotografia. Cardinalità Uno a molti: una fotografia può appartenere ad una sola company e un company può essere proprietaria di più fotografie. Tabella 28 LOCALIZZAZIONE Collega le entità fotografia e ambiente. Specifica in quale ambiente sia stata scattata la fotografia. Cardinalità Uno a molti: una fotografia può esser stata scattata solo in un posto mentre uno stesso ambiente può avere diverse fotografie. Tabella 29 20
  24. 24. 2.2.7. Regole di business 1. Un oggetto o una fotografia devono appartenere a un utente o (esclusivo) a una company. 2. Un utente o una company che possiede una fotografia deve possedere anche gli oggetti inseriti al suo interno. 3. Un oggetto reinserito (spostato) deve appartenere ad una company. 4. Se un utente o una company vengono cancellati, tutte le fotografie di loro proprietà devono essere cancellate. 5. Se una fotografia viene cancellata, tutti gli oggetti in essa contenuti devono essere cancellati. 6. Se un oggetto viene cancellato tutti i suoi inserimenti devono esser cancellati (cascade delete). 7. Un ambiente deve avere almeno una fotografia. 8. Un utente che inserisce un oggetto in una fotografia deve possederla oppure deve essere amministratore della company a cui essa appartiene. 9. Quando un amministratore abbandona una company, i suoi inserimenti rimangono ma non devono essere più associabili a lui. 10. Se una company viene abbandonata da tutti gli utenti deve esser cancellata. 11. La data di fine attività di un utente non attivo deve essere inferiore alla data del sistema – 6 mesi. 12. Il numero massimo di valori aggiunti ad un oggetto relativi ad un parametro non deve superare il numero specificato in NumMaxValori di quel parametro. 21
  25. 25. 2.2.8. Schema E – R finale con attributi e cardinalità X Y 1, 1 Posizione Data 1, 1 INSERIMENTO INSERIMENTO 1, N I-U 0, 1 0, N PASSATO PASSATO 1, 1 Cognome PROPRIETÀ U-F Sesso Nome 0, 1 Geotag 0, N Descrizione PART - OF 0, N DataUltimaOperazione PROPRIETÀ O-C 1, 1 VALORE VALORE COMPANY COMPANY DEFINIZIONE 1, 1 PARAMETRO PARAMETRO COMPL Num Descrizione 0, N DataCreazione 0, N NumMaxValori AGGIUNTA Nome 0, N NON NON ATTIVO ATTIVO ATTIVO ATTIVO 1, N 0, N DataCaricamento Materiale 0, 1 ClasseUtilità PROPRIETÀ F-C ADMIN 0, N Descrizione 0, 1 FOTOGRAFIA FOTOGRAFIA DataNascita DataRegistrazione USER USER Email PROPRIETÀ O-U OGGETTO OGGETTO 0, 1 URL Nome Colore OggettoID Num 1, N 1, N 0, N ULTIMO ULTIMO 0, N 1, 1 0-U AMBIENTE AMBIENTE LOCALIZ 1, 1 0-I AmbienteID Nome Descrizione I-F 0, N 1, 1 CompanyID Num Val Descrizione Nome APERTA APERTA PRIVATA PRIVATA Figura 6 22
  26. 26. 2.3. Progettazione logica 2.3.1. Tavola dei volumi ENTITY Ambiente User  Attivo  Non attivo Fotografia Oggetto Company  Aperta  Privata Inserimento  Ultimo  Passato Parametro Valore VOLUME 22 000 25 000 24 000 1 000 110 000 2 000 000 3 200 200 3 000 2 190 000 2 000 000 190 000 1 900 1 110 000 RELATIONSHIP Oggetto – Inserimento Oggetto – Ultimo Inserimento – Foto Inserimento – User Proprietà O – U Proprietà O – C Aggiunta Completamento Definizione Proprietà U – F Admin Part – of Proprietà F – C Localizzazione VOLUME 2 190 000 2 000 000 2 190 000 2 190 000 150 000 1 850 000 1 110 000 1 110 000 1 900 10 000 10 000 22 500 100 000 110 000 Tabella 30 I numeri della Tabella 30 sono relativi al primo anno di utilizzo dell’applicazione. Per ottenerli è stata fatta una media pesata tra company di piccole e grandi dimensioni considerando che le prime sono il 75% del totale. Si ottiene così che una company è composta in media da 7 utenti, ha 32 foto e 576 oggetti. Si pensa che ogni ambiente conterrà circa 5 foto, che il 10% degli oggetti delle company verrà spostato dalla posizione originale e che il 20% delle company aggiungerà 3 parametri di ricerca. Infine si considera che le company aperte e private saranno in rapporto 1 : 15. 23
  27. 27. 2.3.2. Tavola delle operazioni OPERAZIONI TIPO Ricerca dell’ultima posizione di un oggetto Ricerca delle posizioni precedenti di un oggetto Inserimento di un oggetto Inserimento di una fotografia Registrazione nuovo user Registrazione nuova company Trova gli utenti la cui data dell’ultima operazione risale a più di 6 mesi fa e considerali non attivi I I I I I I B FREQUENZA 3 / secondo 2 / minuto 4 / minuto 13 / ora 3 / ora 9 / giorno 1 / mese Tabella 31 2.3.3. Tavole degli accessi 2.3.3.1. Operazione 1 Schema dell’operazione più frequente: ricerca dell’ultima posizione di un oggetto. L’operazione interattiva si divide in più parti:  Richiesta: 1. Un utente che appartiene a una company specifica alcune caratteristiche dell’oggetto che vuole cercare.  Risposta: 1. Tra gli oggetti della company ne vengono identificati uno o più con le caratteristiche specificate. (1) 2. Si cercano le posizioni e le fotografie che contengono gli oggetti trovati. (2) 24
  28. 28. X Data 1, 1 AmbienteID Nome Descrizione I-F INSERIMENTO INSERIMENTO 1, N I-U 0, 1 0, N PASSATO PASSATO (2) 1, 1 Cognome URL Sesso ADMIN PART - OF 0, N NON NON ATTIVO ATTIVO 1, N ATTIVO ATTIVO (1) DataUltimaOperazione DataCreazione 0, N NumMaxValori 1, 1 VALORE VALORE Descrizione 0, N PROPRIETÀ O-C AGGIUNTA Nome 0, N Materiale 0, 1 0, N Descrizione DataNascita DataRegistrazione 0, N Descrizione PROPRIETÀ F-C DataCaricamento Geotag 0, N USER USER Email PROPRIETÀ O-U OGGETTO OGGETTO 0, 1 FOTOGRAFIA FOTOGRAFIA Nome 0, 1 ClasseUtilità 0, 1 PROPRIETÀ U-F Nome Colore OggettoID Num 1, N 1, N 0, N ULTIMO ULTIMO 0, N 1, 1 0-U AMBIENTE AMBIENTE LOCALIZ 1, 1 0-I (2) Y 1, 1 Posizione COMPANY COMPANY DEFINIZIONE 1, 1 PARAMETRO PARAMETRO COMPL Num 0, N 1, 1 CompanyID Num Val (1) Descrizione Nome APERTA APERTA PRIVATA PRIVATA Figura 7 L’operazione è analoga se l’oggetto appartiene ad un utente e non ad una company oppure se si ricercano lo posizioni precedenti di un oggetto. CONCETTO Oggetto Proprietà C – O Company O–U Ultimo inserimento I–F Fotografia Aggiunta Valore Completamento RICERCA DELL’ULTIMA POSIZIONE DI UN OGGETTO COSTRUTTO ACCESSI E 1 L R 1 L E 1 L R 1 L E 1 L R 1 L E 1 L R E R 1+ 1+ 1+ TIPO L L L Tabella 32 25
  29. 29. 2.3.3.2. Operazione 2 Schema dell’operazione: inserimento di un oggetto. L’operazione si divide in:  Trova tutte le fotografie della company e fanne scegliere una all’utente. (1)  Scrivi un nuovo oggetto (eventualmente con valori aggiuntivi). (2)  Scrivi un nuovo inserimento (eventualmente sposta l’inserimento precedente). (3) X Y 1, 1 Posizione Data 0-I 1, 1 AmbienteID Nome Descrizione I-F INSERIMENTO INSERIMENTO (3) I-U 1, N 0, 1 0, N (3) PASSATO PASSATO (3) 1, 1 Cognome PROPRIETÀ U-F Sesso Nome 0, 1 OGGETTO OGGETTO Descrizione (1) PART - OF Materiale NON NON ATTIVO ATTIVO 1, N ATTIVO ATTIVO DataUltimaOperazione PROPRIETÀ O-C (2) 1, 1 VALORE VALORE DataCreazione 0, N COMPANY COMPANY DEFINIZIONE 1, 1 PARAMETRO PARAMETRO COMPL Num Descrizione 0, N NumMaxValori AGGIUNTA Nome 0, N 0, 1 0, N Geotag 0, N 0, N (2) ClasseUtilità PROPRIETÀ F-C DataCaricamento ADMIN 0, N Descrizione 0, 1 FOTOGRAFIA FOTOGRAFIA DataNascita DataRegistrazione USER USER Email PROPRIETÀ O-U 0, 1 URL Nome Colore OggettoID Num 1, N 1, N 0, N ULTIMO ULTIMO 0, N 1, 1 0-U AMBIENTE AMBIENTE LOCALIZ 1, 1 (3) 0, N 1, 1 CompanyID Num Val Descrizione Nome APERTA APERTA PRIVATA PRIVATA Figura 8 L’operazione è analoga se per l’inserimento di un oggetto che appartiene ad un utente e non ad una company. 26
  30. 30. CONCETTO Company Proprietà C – F Fotografia Oggetto Proprietà O – C O–U Ultimo inserimento I–F I–U E R E E R R E R R Aggiunta Valore Completamento O–I Inserimento Passato INSERIMENTO DI UN OGGETTO COSTRUTTO ACCESSI 1 1 1 1 1 1 1 1 1 R E R R E 1+ 1+ 1+ 1 1 TIPO L L L S S S S S S S S S S S Tabella 33 Le frecce di colore blu sono state utilizzate per l’accesso in lettura e gli ovali rossi per l’accesso in scrittura, il tratteggio indica un accesso che potrebbe avvenire. Si noti che una qualsiasi di queste operazioni effettuate da un utente comporterà l’accesso in scrittura all’entità user per l’aggiornamento della DataUltimaOperazione. Per semplicità di trattazione tale accesso non è stato reiterato in ogni tabella. 2.3.4. Analisi delle ridondanze Attributo derivabile:  URL di una fotografia. Per un’organizzazione efficiente del file system del server, sarà composto da: “/Pictures/CompanyID(oppureUserID)/ AmbienteID/FotografiaID/*.jpg”. Associazioni derivabili dovute a cicli:  Un utente o una company che possiede una fotografia possiede anche gli oggetti inseriti al suo interno. 1. “Proprietà O – U” derivabile da “Proprietà U – F”. 2. “Proprietà O – C” derivabile da “Proprietà F – C”. 27
  31. 31. N.B. L’associazione Completamento non crea nessuna ridondanza (essa infatti non diventerà un vincolo di tipo chiave esterna bensì un’integrità referenziale gestita mediante l’utilizzo di un trigger). Si decide di mantenere la ridondanza di attributo come campo calcolato, ciò è giustificato dal fatto che l’attributo URL è richiesto ad ogni accesso all’entità fotografia. Per quanto riguarda invece le due associazioni derivabili si effettua un’analisi dei costi. 2.3.4.1. Analisi dei costi CONCETTO Oggetto O–U Ultimo inserimento I–F Fotografia Proprietà F – C Company Aggiunta Valore Completamento OPERAZIONE 1 IN ASSENZA DI RIDONDANZA COSTRUTTO ACCESSI E 1 R 1 E 1 R 1 E 1 R 1 E 1 R E R 1+ 1+ 1+ TIPO L L L L L L L L L L Tabella 34 Confrontando il numero degli accessi della Tabella 32 con quelli della Tabella 34 si vede che non cambiano. Si possono esaminare inoltre due file Access Database aggiuntivi: “presenzaridondanza.accdb” e “assenzaridondanza.accdb”. Essi contengono una simulazione di come sarebbe il database e la query per la ricerca di un oggetto rispettivamente con e senza la ridondanza. Infine osservando la Tabella 33 si nota che mantenendo la ridondanza l’inserimento di un nuovo oggetto comporterebbe la scrittura dell’associazione “Proprietà O – C” (o “Proprietà O – U” nel caso l’oggetto appartenga ad un utente e non ad una company) e ciò sarebbe un onere inutile. Per questi motivi si decide di eliminare le associazioni “Proprietà O – C” e “Proprietà O – U”. 28
  32. 32. 2.3.5. Eliminazione delle gerarchie Inserimento:  Si decide di mantenere separate le entità ultimo inserimento e inserimento passato. Questa scelta è giustificata dal fatto che si accede all’entità ultimo inserimento molto più frequentemente sia in lettura che in scrittura rispetto all’entità inserimento passato. Se queste due entità fossero accorpate le operazione principali verrebbero rallentate. User e Company:  Poiché le entità figlie non sono mai accedute separatamente si sceglie di eliminarle, gli attributi dell’utente attivo si aggregano all’entità user e ad entrambe le entità padri si aggiunge un attributo che specifica a quale delle vecchie entità figlie appartengano le loro occorrenze. Adottando questa soluzione si crea però una ridondanza di attributo derivabile nell’entità user: un utente non è attivo se la data dell’ultima operazione risale a più di 6 mesi prima. Si decide di eliminare la ridondanza perché, verificando la tavola delle operazioni (Tabella 31), si nota che viene coinvolta solo un’operazione batch non molto frequente. 2.3.6. Partizionamento / accorpamento di concetti Eliminazione di attributi composti: l’attributo composto Posizione delle entità ultimo inserimento e inserimento passato viene eliminato e i suoi attributi semplici (X e Y) vengono aggiunti direttamente alle entità. Accorpamento di associazioni: si decide di accorpare l’associazione admin, che collega le entità user e company, con l’associazione part – of. A quest’ultima viene aggiunto un attributo per specificare se l’utente, che fa parte della company, abbia o meno i permessi di amministratore. 29
  33. 33. 2.3.7. Scelta degli identificatori primari Si introducono dei codici per avere degli identificatori migliori sulle entità user, fotografia e inserimento passato. Tenendo conto delle precedenti analisi, tale scelta si giustifica osservando che queste entità sono accedute con frequenze molto elevate e hanno bisogno quindi di identificatori efficaci (in questi casi un identificatore interno è preferibile ad uno esterno che coinvolge più entità ed un identificatore numerico è preferibile ad uno di tipo stringa). L’identificatore dell’entità ultimo inserimento è lo stesso dell’entità oggetto. 2.3.8. Normalizzazione Tutte le tabelle sono in terza forma normale secondo Boyce – Codd tranne tre: user, fotografia e inserimento passato. L’introduzione di codici (e nel caso della fotografia anche il campo calcolato url) fa perdere loro la 3FN poiché le colonne non sono più indipendenti tra loro; rimangono quindi in 2FN. 30
  34. 34. 2.3.9. Schema E – R ristrutturato Data 1, 1 0-U Y X U-F ULTIMO ULTIMO INSERIMENTO INSERIMENTO 1, 1 0, N U-U 0, 1 Y X FotografiaID 1, 1 0-I 1, 1 0, N 1, 1 0, N 0, 1 I-F INSERIMENTO INSERIMENTO PASSATO PASSATO URL PROPRIETÀ U-F I-U InsPassatoID DataCaricamento 0, 1 FOTOGRAFIA FOTOGRAFIA PROPRIETÀ F-C 0, 1 1, 1 Data Geotag Descrizione OGGETTO OGGETTO 1, N Num 1, 1 AGGIUNTA UtenteID Nome VALORE VALORE 1, 1 Descrizione DataRegistrazione Sesso AMBIENTE AMBIENTE DataNascita Cognome OggettoID Nome Colore AmbienteID Email USER USER Descrizione 0, N 0, N Val 0, N ClasseUtilità 0, N Materiale 0, N LOCALIZ Nome DataUltimaOperazione 0, N Nome 0, N COMPL 1, N CompanyID Descrizione DataCreazione PART - OF Descrizione NumMaxValori Admin PARAMETRO PARAMETRO Num 1, 1 Aperta 0, N DEFINIZIONE Nome COMPANY COMPANY Figura 9 31
  35. 35. 2.3.10. Traduzione verso il relazionale – schema logico tblUltimoInserimento PK,FK1 oggettoID FK2 FK3 data x y fotografiaID userID tblFotografia tblInserimentoPassato PK FK1 FK2 FK3 tblOggetto PK oggettoID nome colore materiale utilità descrizione PK data x y oggettoID fotografiaID userID tblValore PK PK PK,FK1 numParametro numValore oggettoID valore fotografiaID FK1 FK2 FK3 insPassatoID dataCaricamento geotag descrizione url ambienteID userID companyID tblAmbiente PK nome descrizione tblCompany tblUser PK ambienteID PK userID companyID nome datacreazione descrizione aperta nome cognome dataNascita sesso email dataRegistrazione dataUltimaOperazione tblParametro PK PK,FK1 numParametro companyID nome numMaxValori descrizione tblPartOf PK,FK1 PK,FK2 userID companyID admin Figura 10 32
  36. 36. 2.4. Schema fisico tblUltimoInserimento oggettoID data x y fotografiaID userID tblInserimentoPassato insPassatoID data x y tblFotografia oggettoID tblAmbiente fotografiaID fotografiaID ambienteID userID dataCaricamento nome geotag descrizione descrizione url ambienteID userID companyID tblOggetto tblValore tblUser oggettoID oggettoID userID nome numParametro nome colore numValore cognome materiale valore dataNascita utilita tblParametro companyID nome descrizione numMaxValori aperta dataRegistrazione companyID dataCreazione email numParametro nome sesso descrizione tblCompany descrizione dataUltimaOperazione tblPartOf userID companyID admin Figura 11 33
  37. 37. 2.5. Documentazione aggiuntiva 2.5.1. Viste Si espongono le viste dedicate atte a soddisfare le seguenti richieste: 1) User registrati al sito (vwUsers) 2) Company degli utenti (vwUsersCompanies) 3) Foto degli utenti (vwUsersPhotos) 4) Foto delle company (vwCompanysPhotos) 5) Parametri di ricerca aggiunti agli oggetti delle company (vwCompanysParameters) 6) Oggetti nelle fotografie (vwPhotosObjects) 7) Ultima posizione degli oggetti tra le fotografie (vwLastPosizions) 8) Posizioni precedenti degli oggetti tra le fotografie (vwPastPositions) 9) Oggetti degli user (vwUsersObjects) 10) Oggetti delle company (vwCompanysObjects) 2.5.2. Trigger Si creano i seguenti trigger per evitare che si verifichino accidentalmente situazioni di incoerenza dei dati: trgAdminIns: Un utente che inserisce un oggetto in una fotografia deve possederla oppure deve essere amministratore della company a cui essa appartiene. trgByeAdmin: Si attiva quando un amministratore lascia una company. Se era l’ultimo amministratore rimasto la company viene cancellata altrimenti tutti gli inserimenti effettuati da lui non devono essere più associabili a lui. trgDeletePhoto: Cancella un ambiente quando non ha più fotografie. 34
  38. 38. trgObjRemoved: Gli oggetti rimasti senza un ultimo inserimento vengono cancellati. trgObjMoved: Un oggetto sportato deve appartenere ad una company. trgParamValue, trgDeleteParam: Fanno rispettare il vincolo d’integrità tra i valori aggiunti ad un oggetto di una company e i parametri di ricerca da essa definiti. trgDeleteUser, trgHasPhoto: Se una fotografie non è di proprietà né di un utente né di una company oppure sia di un utente che di una company allora viene cancellata. trgURL: Ad ogni inserimento di nuova una fotografia, genera il nome del file che viene salvato sul server. 2.5.2.1. Triggering graph trgURL trgURL trgAdminIns trgAdminIns trgObjRemoved trgObjRemoved trgDeleteUser trgDeleteUser trgByeAdmin trgByeAdmin trgHasPhoto trgHasPhoto trgDeletePhoto trgDeletePhoto trgDeleteParam trgDeleteParam trgParamValue trgParamValue trgObjMoved trgObjMoved Figura 12 Come si nota dalla Figura 11 il grafo è aciclico, quindi il sistema è sicuramente terminante. 35
  39. 39. 2.5.3. Sorgenti dei trigger e stored procedure Vengono esposti e brevemente commentati i codici scritti in “T-SQL” per la definizione delle stored procedure e dei trigger principali, tutti i codici restanti, compresi quelli per la generazione delle tabelle e delle viste, sono consultabili separatamente. 2.5.3.1. trgHasPhoto 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 CREATE TRIGGER trgHasPhoto ON tblFotografia AFTER INSERT, UPDATE AS DECLARE MyCursor6 CURSOR FOR SELECT fotografiaID, userID, companyID FROM inserted OPEN MyCursor6 DECLARE @FotoID bigint DECLARE @UID bigint DECLARE @CID bigint FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID WHILE @@FETCH_STATUS = 0 BEGIN IF (@UID IS NULL AND @CID IS NULL) OR (@UID IS NOT NULL AND @CID IS NOT NULL) DELETE FROM tblFotografia WHERE @FotoID = fotografiaID FETCH NEXT FROM MyCursor6 INTO @FotoID, @UID, @CID END CLOSE MyCursor6 Trigger 1 Il trigger 1 viene eseguito dopo che un insieme di fotografie viene inserito o modificato (riga 2 e 3). Si controlla che ogni fotografia (righe 13,15 e 23) abbia almeno un proprietario (riga 18) e che non sia di proprietà di una company e di uno user contemporaneamente (riga 19), creando un‘incoerenza dei dati. 36
  40. 40. 2.5.3.2. trgAdminIns 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 CREATE TRIGGER trgAdminIns ON tblUltimoInserimento AFTER INSERT, UPDATE AS DECLARE MyCursor CURSOR FOR SELECT oggettoID, fotografiaID, userID FROM inserted WHERE userID IS NOT NULL OPEN MyCursor DECLARE @OggettoID bigint DECLARE @FotoID bigint DECLARE @UID bigint FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID WHILE @@FETCH_STATUS = 0 BEGIN DECLARE @UserProprFoto bigint DECLARE @CompanyProprFoto bigint SELECT @UserProprFoto = tblFotografia.userID, @CompanyProprFoto = tblFotografia.companyID FROM tblFotografia WHERE @FotoID = tblFotografia.fotografiaID IF (@UserProprFoto IS NULL OR @UID <> @UserProprFoto) AND NOT EXISTS ( SELECT userID, companyID FROM tblPartOf WHERE @UID = userID AND @CompanyProprFoto = companyID AND tblPartOf.admin = 1 ) DELETE FROM tblUltimoInserimento WHERE @OggettoID = tblUltimoInserimento.oggettoID FETCH NEXT FROM MyCursor INTO @OggettoID, @FotoID, @UID END CLOSE MyCursor Trigger 2 La parte più rilevante è tra le righe 22 e 35. L’inserimento viene annullato se il proprietario della fotografia è diverso dall’utente che compie l’inserimento e se la company proprietaria della fotografia non ha l‘utente che compie l’inserimento come amministratore. Si noti che è necessario verificare in anticipo se l’utente proprietario della fotografia è NULL poiché si rischia di confrontare @UID con il valore NULL che darebbe come risultato UKNOWN invece di TRUE. 37
  41. 41. 2.5.3.3. trgParamValue 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 CREATE TRIGGER trgParamValue ON tblValore AFTER INSERT, UPDATE AS DECLARE MyCursor5 CURSOR FOR SELECT oggettoID, numParametro, numValore FROM inserted OPEN MyCursor5 DECLARE @OggID bigint DECLARE @Param int DECLARE @NumVal int FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal WHILE @@FETCH_STATUS = 0 BEGIN IF NOT EXISTS ( SELECT tblParametro.companyID, tblParametro.numParametro FROM tblParametro, tblFotografia, tblUltimoInserimento WHERE @OggID = tblUltimoInserimento.oggettoID AND tblFotografia.fotografiaID = tblUltimoInserimento.fotografiaID AND tblParametro.companyID = tblFotografia.companyID AND @Param = tblParametro.numParametro AND @NumVal <= tblParametro.numMaxValori ) DELETE FROM tblValore WHERE @OggID = oggettoID AND @Param = numParametro AND @NumVal = numValore FETCH NEXT FROM MyCursor5 INTO @OggID, @Param, @NumVal END CLOSE MyCursor5 Trigger 3 Questo trigger è molto importante perché contribuisce a far rispettare il vincolo d’integrità tra la tblValore e la tblParametro. Una volta inserito il nuovo valore, si controlla che il corrispondente parametro sia definito per la company proprietaria dell’oggetto (righe 18 – 24) e che il numero del valore assegnato sia inferiore o uguale al numero massimo di valori permessi per quel parametro (riga 25). In caso contrario, il valore appena inserito viene cancellato (righe 26 – 29). 38
  42. 42. 2.5.3.4. wiliGetCompanies 1 2 3 4 5 6 7 8 9 Go CREATE PROCEDURE dbo.wiliGetCompanies ( @userID BIGINT ) AS SELECT vwUsersCompanies.companyID, companyNome, numParametro, parametroNome, parametroDescrizione FROM vwUsersCompanies LEFT JOIN vwCompanysParameters ON ( vwUsersCompanies.companyID = vwCompanysParameters.companyID ) WHERE userID = @userID Go SP 1 La SP 1, utilizzando una selezione di tipo “outer join”, consente all’applicazione che la esegue di ricevere tutte le company di utente ed eventualmente i parametri di ricerca aggiuntivi definiti dalla stesse. 2.5.3.5. wiliGetObjects 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Go CREATE PROCEDURE dbo.wiliGetObjects ( @isCompany BIT, @ID BIGINT ) AS IF ( @isCompany = 1 ) SELECT nome, colore, materiale, utilita, oggettoID, numParametro, valore, oggettoDescrizione, x, y, url, fotografiaDescrizione FROM vwCompanysObjects WHERE companyID = @ID ELSE SELECT nome, colore, materiale, utilita, oggettoDescrizione, x, y, url, fotografiaDescrizione FROM vwUsersObjects WHERE userID = @ID Go SP 2 Il primo parametro 2 è un flag che serve a specificare se il parametro seguente è un identificativo di una company oppure di un utente. Nel primo caso vengono selezionati i valori (compresi quelli aggiuntivi) di tutti gli oggetti della company con relative posizioni e descrizione della fotografia in cui sono inseriti. Nel secondo caso viene fatta la stessa operazione di selezione stavolta sugli oggetti dell’ utente e quindi senza valori aggiuntivi. 39
  43. 43. 3. Documentazione dell’applicazione 3.1. Interfaccia Immagine 1 Questa è la pagina per la ricerca di un oggetto. In alto a sinistra è presente una tendina che consente all’utente di specificare in quale raccolta desidera effettuare la ricerca. Potrà scegliere una delle company a cui è iscritto oppure la sua raccolta personale. Dopo aver selezionato una company, compaiono (sotto le quattro già presenti) le textbox per inserire i valori dei parametri di ricerca specifici di quella company. A questo punto l’utente può inserire le caratteristiche dell’oggetto cercato, può digitare anche solo le prime lettere della parola e la ricerca comincerà automaticamente non appena avrà finito di scrivere. 40
  44. 44. Immagine 2 Il risultato della ricerca compare sul lato destro della schermata. Qui sono visibili le miniature della fotografie che contengono gli oggetti trovati e subito accanto sono elencate le loro caratteristiche principali assieme a una descrizione. È possibile scorrere i risultati ottenuti e cliccare su una riga in particolare. In questo modo si ottiene un ingrandimento dell’immagine e si visualizza l’esatta posizione dell’oggetto che viene indicata da uno spillo. Il risultato ottenuto è illustrato nell’Immagine 3. Naturalmente è possibile ingrandire ancora l’immagine usando il touchpad o facendo un pinch se si usa uno schermo touchscreen. Nella parte inferiore della schermata sono disponibili le informazioni aggiuntive riguardanti la fotografia e l’oggetto in questione. Per tornare alla schermata precedente basta cliccare sull’ombra che la oscura oppure cliccare sulla X in alto a destra. 41
  45. 45. Immagine 3 Si noti che il passaggio da una schermata all’altra non prevede il caricamento di una nuova pagina web. Si è scelto di usare questa tecnica in vista degli sviluppi futuri dell’applicazione. Infatti, dopo aver curato la parte relativa all’inserimento di nuovi oggetti e fotografie, è previsto che sia possibile interagire maggiormente con queste schermate, consentendo per esempio di modificare le caratteristiche di un oggetto al volo, di muovere un oggetto all’interno della stessa fotografia oppure di spostarlo in un’altra. Per effettuare questo tipo di operazioni risulta molto comodo per l’utente che la pagina rimanga la stessa. 42
  46. 46. 3.2. Implementazione Il capitolo ha lo scopo di esporre il funzionamento interno del prototipo dell’applicazione. Per semplicità di trattazione non verranno elencati tutti i sorgenti ma si è preferito soffermarsi sui moduli principali. Ciò detto, per la programmazione lato client sono descritte solamente alcune funzioni JavaScript e viene mostrata una parte del foglio di stile. Per il lato server viene presentato l’interfacciamento con le stored procedure mostrate nel capitolo 2.5. I codici completi sono presentati alla commissione di prelaurea separatamente da questo documento e sono disponibili nella cartella “/Source”. 3.2.1. Lato client 3.2.1.1. Caricamento della pagina function loadPage() { 1 $.post("GetCompanies.aspx", "userID=" + userID, 2 function (data, status, jqXHR) { 3 console.log(data); 4 var companySelection = $("select#company"); 5 companies = data; 6 for (var n = 0; n < data.length; n++) { 7 companySelection.append( 8 $('<option value="' + data[n].companyID + '">' 9 + data[n].companyName + '</option>')); 10 } 11 imgSmallLoading.remove(); 12 }); 13 loadResources(); 14 $("select#company").change(appendParameters); 15 $("input.mainForm").on("input", counter); 16 resize(); 17 18 } Script 1 43
  47. 47. Lo Script 1 cerca di ricevere tutte le company di cui l’utente fa parte con i relativi parametri di ricerca aggiuntivi. Una volta ottenute, la drop-down list viene popolata con i loro nomi che saranno visibili e selezionabili dall’utente. Il valore assunto dalla lista dopo la selezione corrisponde all’id della company (righe 3 – 11). All’evento di selezione viene poi associata la funzione che modifica il DOM inserendo le textbox che consentono all’utente di specificare le caratteristiche aggiuntive degli oggetti di quella company (riga 15). Infine all’evento input del form si associa la funzione che conta quanti millisecondi sono passati dalla digitazione dell’ultima lettera (riga 16). Se passa più di mezzo secondo si presuppone che l’utente abbia finito di scrivere e quindi viene processata la richiesta degli oggetti con le caratteristiche specificate. 3.2.1.2. Request – Response 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 function processRequest() { $.post("GetObj.aspx", "user=" + userID + "&" + $("#mainForm").serialize(), function (data, status, jqXHR) { console.log(data); objects = data; $("div#response > img#loading").remove(); if (data.length) viewResponse(); else { $("div#response").append(imgNotFound); } }); } function viewResponse() { $("div#response > table").replaceWith($("<table></table>")); var table = $("div#response > table"); for (var n = 0; n < objects.length; n++) { var tr = $('<tr data-rowNumber="' + n + '"><td><img src="' + objects[n].picture.imagePath + 'small.jpg" />' + '</td><td>' + generateDescription(n) + '</td></tr>'); tr.click(zoomImage); table.append(tr); } } Script 2 44
  48. 48. La funzione “processRequest” si occupa di serializzare e inviare i dati del form all’URL “GetObj.aspx”. Successivamente si assicura che la risposta contenga dei dati e in caso affermativo chiama la “viewResponse” (righe 7 e 8). Quest’ultima per prima cosa cancella il risultato di un’eventuale ricerca precedente (riga 16), riempie poi la tabella dei risultati con la descrizione dei nuovi oggetti ottenuti e con le miniature delle fotografia in cui essi si trovano (19 – 24). Inoltre all’evento click su una riga della tabella viene associato lo zoom dell’immagine corrispondente che viene portata in primo piano. 3.2.1.3. Sezione in primo piano La funzione “fillNewSection” genera una sezione in primo piano oscurando il resto della pagina. In alto a destra viene posizionata l’immagine di una X che se cliccata permette di chiudere la sezione e di tornare alla pagina sottostante. Lo stesso risultato si ottiene cliccando sull’ombra attorno alla sezione (righe 2 – 12). Viene poi creato un elemento canvas per ospitare la fotografia e l’immagine di uno spillo che serve ad indicare il punto in cui si trova l’oggetto cercato. Si ricorda che x e y sono dei rapporti e quindi per ottenere le coordinate è necessario moltiplicarli rispettivamente per la larghezza e l’altezza della fotografia (righe 21 – 22). Si ha l’accortezza di ruotare lo spillo se questo si trova vicino al bordo superiore o destro perché rischierebbe di uscire dalla parte visibile del canvas (riga 29). Infine si aggiungono le descrizioni della fotografia e dell’oggetto in questione (33 – 37). 45
  49. 49. 1 function fillNewSection(rowclicked) { var divShadow = $('<div id="shadow" ></div>'), 2 divZoom = $('<div id="zoom" ></div>'); 3 function removeSection() { 4 divZoom.remove(); 5 divShadow.remove(); 6 } 7 $("body").append(divShadow); 8 $("body").append(divZoom); 9 divZoom.append(imgEsc); 10 divShadow.click(removeSection); 11 imgEsc.click(removeSection); 12 imgZoom = new Image(); 13 imgZoom.src = objects[rowclicked].picture.imagePath + "big.jpg"; 14 15 var _C_ = { gc: null }, 16 canvas = $('<canvas id="cnv" width="' + imgZoom.width 17 + '" height="' + imgZoom.height + '"></canvas>'), 18 pinH = imgZoom.height / 7, 19 pinW = pinH * (imgPinpont.width / imgPinpont.height), 20 x = objects[rowclicked].x * imgZoom.width, 21 y = objects[rowclicked].y * imgZoom.height; 22 23 divZoom.append(canvas); 24 _C_.gc = $("canvas#cnv")[0].getContext('2d'); 25 imgZoom.addEventListener("load", function () { 26 _C_.gc.drawImage(this, 0, 0); 27 _C_.gc.translate(x, y); 28 _C_.gc.rotate(computeRotation(x, y, pinW, pinH, imgZoom.width, imgZoom.height)); 29 _C_.gc.drawImage(imgPinpont, 0, -pinH, pinW, pinH); 30 }, false); 31 32 divZoom.append('<table><tbody><tr><td><em>Dettagli fotografia:</em></td>' 33 + '<td><em>Dettagli oggetto:</em></td></tr>' 34 + '<tr><td>' + objects[rowclicked].picture.description 35 + '</td><td>' + objects[rowclicked].description 36 + '</td></tr></tbody></table>'); 37 resize(); 38 39 } Script 3 46
  50. 50. 3.2.1.4. Stile risposta 1 div#response { width: 700px; 2 overflow-y: auto; 3 4 } 5 div#response > table { 6 border-collapse: collapse; 7 cursor: pointer; 8 } 9 10 div#response td { 11 vertical-align: top; 12 width: 340px; 13 line-height: 30px; 14 } 15 16 div#response > table > tbody > tr > td { 17 border-bottom: 1px solid; 18 } 19 20 div#response > table > tbody > tr > td:nth-of-type(2n) { 21 width: 680px; 22 } 23 24 div#response > table > tbody > tr > td:nth-of-type(2n+1) { 25 width: 240px; 26 } 27 CSS 1 Viene riportata una parte del foglio di stile, in particolare le regole per la visualizzazione della tabella che conterrà i risultati di una ricerca. Si è scelto di non usare bordi per suddividere le celle (righe 6 – 9), si userà un solo bordo per dividere un risultato da quello successivo (righe 17 – 19). Le colonne dispari contengono le fotografie in miniatura e quelle pari i dettagli dell’oggetto, la loro larghezza deve quindi essere diversa (righe 21 – 27). 47
  51. 51. 3.2.2. Lato server 3.2.2.1. GetCompanies 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 DataTable companysParameters = new DataTable(); using (SqlConnection connection = new SqlConnection(connectionString)) using (SqlCommand sqlCmdCompanies = new SqlCommand("wiliGetCompanies", connection)) { sqlCmdCompanies.CommandType = CommandType.StoredProcedure; sqlCmdCompanies.Parameters.Add(new SqlParameter("@userID", SqlDbType.BigInt)); sqlCmdCompanies.Parameters["@userID"].Value = userID; SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdCompanies); sqlda.Fill(companysParameters); } List<Company> cList = new List<Company>(); Company lastCompany = null; List<Parameter> pList = new List<Parameter>(); foreach (DataRow row in companysParameters.Rows) { long aCompanyID = Convert.ToInt64(row["companyID"]); if (lastCompany == null || aCompanyID != lastCompany.companyID) { pList = new List<Parameter>(); lastCompany = new Company(aCompanyID, row["companyNome"].ToString(), pList); cList.Add(lastCompany); } try { Parameter aParam = new Parameter(Convert.ToInt32(row["numParametro"]), row["parametroNome"].ToString(), row["parametroDescrizione"].ToString()); pList.Add(aParam); } catch (InvalidCastException iexc) { } catch (FormatException fexc) { } catch (OverflowException oexc) { } } JavaScriptSerializer js = new JavaScriptSerializer(); String json = js.Serialize(cList); Response.Clear(); Response.ContentType = "application/json; charset=utf-8"; Response.Write(json); Response.End(); C# 1 48
  52. 52. Il codice riportato nella pagina precedente genera una risposta contenente le company di un utente e i relativi parametri per la ricerca di un oggetto. Inizialmente si apre una connessione con il database e si esegue la stored procedure “wiliGetCompanies” già analizzata in dettaglio al capitolo 2.5.3.4. (righe 1 – 10). Successivamente con i dati ottenuti, ora contenuti nella DataTable companysParameters, viene costruita una lista di oggetti Company, ognuno contenente una lista di oggetti Parameter (11 – 34). La lista di Company infine viene serializzata e restituita nella risposta (35 – 40). 3.2.2.2. GetObjects 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 NameValueCollection nameValueColl = Request.Form; DataTable objsTable = new DataTable(); using (SqlConnection connection = new SqlConnection(connectionString)) using (SqlCommand sqlCmdObj = new SqlCommand("wiliGetObjects", connection)) { sqlCmdObj.CommandType = CommandType.StoredProcedure; sqlCmdObj.Parameters.Add(new SqlParameter("@isCompany", SqlDbType.Bit)); sqlCmdObj.Parameters["@isCompany"].Value = !nameValueColl["company"].Equals("-1"); sqlCmdObj.Parameters.Add(new SqlParameter("@ID", SqlDbType.BigInt)); sqlCmdObj.Parameters["@ID"].Value = (nameValueColl["company"].Equals("-1")) ? nameValueColl["user"] : nameValueColl["company"]; SqlDataAdapter sqlda = new SqlDataAdapter(sqlCmdObj); sqlda.Fill(objsTable); } C# 2 Questo codice serve per interrogare il database e ottenere tutti gli oggetti di un utente oppure di una company specifica. A questo scopo viene aperta una connessione con il database e viene eseguita la stored procedure “wiliGetObjects” (righe 3 – 12). Per la descrizione di quest’ultima si veda il capitolo 2.5.3.5. 49
  53. 53. Si noti che l’id della company è uguale a “-1” solo nel caso in cui nessuna company è stata selezionata dall’utente ed egli desidera effettuare la ricerca tra le sue fotografie personali. In questo caso il numero passato come secondo parametro corrisponde all’user id. Viceversa, se l’utente sceglie di effettuare una ricerca tra gli oggetti di una company allora viene passato il company id (righe 11 – 12). Il risultato ottenuto grazie all’esecuzione della “wiliGetObjects” viene salvato per il momento nell’oggetto DataTabe objsTable. 1 foreach (String item in nameValueColl) 2 { if (nameValueColl[item].Length != 0 3 && !item.Equals("company") && !item.Equals("user")) 4 { 5 int i = 0; 6 if (!int.TryParse(item, out i)) 7 { 8 String filter = item + " LIKE '" + nameValueColl[item] + "%'"; 9 objsTable = objsTable.Select(filter).CopyToDataTable(); 10 } 11 else 12 { 13 String filter = "numParametro = " + i + " AND " 14 + "valore LIKE '" + nameValueColl[item] + "%'"; 15 objsTable = objsTable.Select("oggettoID IN (" 16 + objsIDs(objsTable.Select(filter)) + ")").CopyToDataTable(); 17 } 18 } 19 20 } C# 3 Nel codice qui riportato, viene creato un filtro utilizzando il contenuto del form compilato dall’utente. Per ogni parametro del form si verifica se esso è uno dei parametri principali (in questo caso è una stringa di lettere, es. “colore”) oppure uno dei parametri aggiuntivi della company (è una stringa contenente il numero del parametro, es. “2”). Nei due casi si genera una stringa SQL (filter) che utilizza l’informazione “parametro comincia con valore” per restringere il campo dei risultati (riga 10 e 16). 50
  54. 54. 4. Conclusioni Entrambi gli obiettivi prefissati sono stati raggiunti. 1) Il database è stato completamente progettato e realizzato e particolare attenzione è stata rivolta alla prevenzione di situazioni di incoerenza dei dati. 2) Un prototipo dell’applicazione web che si collega al database e consente la ricerca di un oggetto è pronto e funzionante. Per ottenere questo risultato, si è riusciti a rimanere entro le 1000 righe di codice, così suddivise (è stato escluso dal conteggio il codice generato automaticamente): - 340 righe di Transact-SQL per la creazione dei trigger e delle stored procedure. - 216 righe tra codice HTML e regole CSS. - 215 righe di codice JavaScript con 18 funzioni. - 228 righe di codice C# con 6 classi. Si è soddisfatti del lavoro svolto finora e delle competenze che il candidato ha dovuto acquisire per raggiungere gli obiettivi di questa tesi. In futuro si intende continuare lo sviluppo dell’applicazione web e portare a compimento l’intero progetto. 51
  55. 55. Bibliografia - Pellegrino Principe, Apogeo, HTML5 CSS3 JavaScript (2012). - Atzeni Paolo, McGraw-Hill, Basi di dati Modelli e linguaggi di interrogazione (2009). - Fermeglia Maurizio, dispense del corso di basi di dati (http://studenti.di3.units.it). 52

×