UNIVERSITA' DEGLI STUDI DI ROMA
" LA SAPIENZA "
Facoltà di Scienze Matematiche Fisiche e Naturali
Corso di Laurea in Informatica
"E-CRM. Progetto e realizzazione di un ‘e-mall’
orientato al cliente.”
Relatore: Professor
Laureando:
Francesco Parisi Presicce
Luca Tiberia
A.A 2000-2001
1
Scopo della tesi .......................................................................................................................6
2
Metodologia usata ..................................................................................................................7
3
Generazione dei requisiti......................................................................................................10
4
3.1
Requisiti minimi .............................................................................................. 10
3.2
Requisiti ulteriori ............................................................................................. 10
3.3
Cosa non è richiesto ....................................................................................... 11
3.4
Prime considerazioni sul progetto................................................................... 11
Formulazione del problema .................................................................................................13
4.1
Ambito del problema....................................................................................... 13
4.1.1
Livelli di presenza .................................................................................... 13
4.1.2
Definizione Commercio Elettronico (CE) ................................................. 15
4.1.2.1
4.2
Cosa è necessario .......................................................................................... 15
4.2.1
Schema di una piattaforma di CE ............................................................ 15
4.2.1.1
Front end .......................................................................................... 16
4.2.1.2
Back end .......................................................................................... 17
4.2.2
4.3
Tipologie di commercio elettronico ................................................... 15
Conclusioni .............................................................................................. 21
Contesto dell’applicazione .............................................................................. 21
4.3.1
Business Intelligence............................................................................... 21
4.3.1.1
4.3.2
CRM ........................................................................................................ 23
4.3.2.1
4.3.3
CRM operazionale e analitico........................................................... 24
Datawarehouse ....................................................................................... 28
4.3.3.1
4.3.4
Utilizzo.............................................................................................. 22
I metadati.......................................................................................... 29
Data-mining ............................................................................................. 32
4.3.4.1
Usi .................................................................................................... 33
4.3.4.2
Possibili usi e benefici apportati: ...................................................... 33
4.3.4.3
Metodologie usate ............................................................................ 34
4.3.4.4
Obiettivi del modello ......................................................................... 34
4.3.4.5
Tecniche di modellazione ................................................................. 34
4.3.5
OLAP....................................................................................................... 35
4.3.5.1
Gli operatori...................................................................................... 36
2
4.3.5.2
Le dimensioni ................................................................................... 37
4.3.5.3
Olap Server ...................................................................................... 38
4.3.5.4
Olap e datamining ............................................................................ 39
4.3.6
4.4
5
Decision support e reporting tools ........................................................... 39
4.3.6.1
Tipologia d’uso ................................................................................. 39
4.3.6.2
Tipologia di utilizzatori ...................................................................... 40
Ipotesi ............................................................................................................. 41
4.4.1
Il server Web e il concetto di sessione .................................................... 41
4.4.2
Qualità del software................................................................................. 43
4.4.3
Compatibilità con i browser in circolazione .............................................. 44
4.4.4
Soluzioni non adatte ................................................................................ 45
Architetture e linguaggi .......................................................................................................48
5.1
Architetture a modelli ...................................................................................... 48
5.2
Architettura di un’applicazione Web ............................................................... 49
5.2.1
Sistemi HOST.......................................................................................... 49
5.2.2
Architettura a LAN ................................................................................... 50
5.2.3
Client/Server............................................................................................ 50
5.2.4
Multi-Tier ................................................................................................. 50
5.3
I linguaggi di programmazione........................................................................ 55
5.3.1
ASP ......................................................................................................... 55
5.3.1.1
Global.asa ........................................................................................ 56
5.3.1.2
Oggetti ASP più importanti ............................................................... 58
5.3.1.3
ADO ................................................................................................. 61
5.3.2
PHP ......................................................................................................... 62
5.3.3
Script CGI................................................................................................ 65
5.3.4
JSP e Java Servlet .................................................................................. 65
5.3.4.1
Le Servlet ......................................................................................... 66
5.3.4.2
Jsp.................................................................................................... 68
5.3.5
Confronto fra i vari linguaggi.................................................................... 71
5.3.5.1
ASP e CGI........................................................................................ 71
5.3.5.2
ASP e JSP........................................................................................ 71
5.3.5.3
ASP e PHP....................................................................................... 72
5.3.6
Programmazione a componenti............................................................... 73
3
5.4
5.3.6.1
Oggetti aziendali............................................................................... 74
5.3.6.2
COM e DCOM .................................................................................. 74
5.3.6.3
CORBA ............................................................................................ 76
UML(Unified Modeling Language) .................................................................. 77
5.4.1
6
Uml e la modellazione di una piattaforma di CE ...................................... 79
5.4.1.1
Uml e la modellazione delle basi dati relazionali .............................. 81
5.4.1.2
Rational Rose e la modellazione dei dati ......................................... 84
5.4.1.3
Uml e la modellazione delle applicazioni Web.................................. 86
Progettazione ........................................................................................................................89
6.1
Analisi sistema esistente ................................................................................ 89
6.1.1
Considerazioni e aspetti negativi ............................................................. 89
6.1.2
Conclusioni .............................................................................................. 91
6.2
Studio fattibilità/esigenze ................................................................................ 91
6.2.1
File di Logs: ............................................................................................. 92
6.2.2
Cookies: .................................................................................................. 92
6.2.3
Forms: ..................................................................................................... 92
6.2.3.1
6.3
Tipi di informazioni richieste con le form .......................................... 93
Scelte progettuali ............................................................................................ 93
6.3.1
Livello di presenza................................................................................... 93
6.3.2
Architettura .............................................................................................. 94
6.4
6.3.2.1
Impostazione livello presentazione................................................... 94
6.3.2.2
Impostazione livello aziendale.......................................................... 95
6.3.2.3
Impostazione livello fisico ................................................................. 95
6.3.2.4
Altre scelte........................................................................................ 96
Scelta degli strumenti ..................................................................................... 97
6.4.1
Alternative ............................................................................................... 97
6.4.2
Scelta effettuata....................................................................................... 99
6.4.3
Disposizione fisica dei server .................................................................. 99
6.4.4
Strumenti di sviluppo ............................................................................. 102
6.5
Indicatori per la progettazione del database ................................................. 102
6.6
Moduli base e diagrammi UML ..................................................................... 107
6.6.1
Front end ............................................................................................... 110
6.6.1.1
Sistema di gestione del catalogo.................................................... 110
4
6.6.1.2
Motore di visualizzazione ............................................................... 130
6.6.1.3
Motore di ricerca e categorizzazione.............................................. 160
6.6.2
6.7
Back end ............................................................................................... 164
6.6.2.1
Sistema di gestione degli ordini...................................................... 164
6.6.2.2
Sistema di gestione delle transazioni ............................................. 176
6.6.2.3
Catalogazione degli utenti .............................................................. 177
6.6.2.4
Sistemi di data-mining e datawarehousing ..................................... 206
Moduli Aggiuntivi .......................................................................................... 207
6.7.1
Punti Fidelity Program ........................................................................... 207
6.7.2
Partner Program .................................................................................... 212
6.8
Il file global.asa............................................................................................. 217
6.9
Ottimizzazioni ............................................................................................... 224
6.9.1
MTS....................................................................................................... 224
6.9.2
Inclusione Server-side ........................................................................... 225
6.9.3
Uso dei componenti piuttosto che degli script ....................................... 227
6.9.4
Le architetture che supportano la scalabilità ......................................... 227
6.9.5
Come migliorare il tempo di risposta dell’applicazione .......................... 228
7
Conclusioni.........................................................................................................................230
8
Bibliografia.........................................................................................................................234
9
Principali siti di riferimento...............................................................................................236
5
Scopo della tesi
1 Scopo della tesi
Lo scopo della tesi è di progettare e realizzare una piattaforma di e -commerce con una
forte componente di CRM 1 e quindi sulla struttura di un e-mall2 che fosse dinamico,
personalizzabile e interattivo ma allo stesso tempo leggero e possibilmente compatibile
con gli strumenti del maggior numero degli utenti (browser-so).
E’ richiesto inoltre di sviluppare un’infrastruttura capace, di popolare un Data Warehouse3 con i dati necessari per analisi di tipo statistico/data-mining4 su utenti,
vendite e costi del sito stesso. Infine è richiesta la massima scalabilità della
realizzazione e quindi facilità di aggiornamento dei vari componenti in vista di auspicate
e prevedibili ampliamenti del bacino di utenza.
1
CRM: Customer Relationship Management. Si definisce CRM una serie di processi o infrastrutture tecnologiche
attraverso le quali un’azienda massimizza le informazioni sui clienti per aumentare la fedeltà e diminuire eventuali
attriti.
2
E-mall: centro commerciale virtuale nel quale vengono allestite vetrine di più negozi.
3
Data-Warehouse: un magazzino in cui i dati estratti dalle diverse fonti, aggregati, omogeneamente e resi
consistenti vengono mantenuti in forma storica.
4
Data-Mining: E' un insieme di processi atti a scoprire correlazioni, relazioni e tendenze nuove e significative
setacciando grandi quantità di dati immagazzinati nei repository usando tecniche di riconoscimento delle relazioni e
tecniche statistiche e matematiche.
6
Metodologia usata
2 Metodologia usata
(*)5
Nello sviluppo del software si possono individuare, indipendentemente dall’area
d’impiego, dalle dimensione del progetto e dalla sua complessità, tre fasi comuni:
Definizione, Sviluppo e Manutenzione.
La fase di Definizione si concentra sull’identificazione dei requisiti, per comprendere
cosa dovrà essere realizzato; quindi stabilisce le informazioni ed i dati da gestire, le
funzionalità e le prestazioni desiderate. Le specifiche e i criteri di validazione vengono
riportati in un documento atto a verificarne la rispondenza finale.
Lo Sviluppo è la fase del come, in cui si descrivono le strutture dei dati e l’architettura
software da realizzare, ed inoltre, si definiscono i dettagli procedurali e le modalità di
traduzione del progetto in un linguaggio di programmazione.
All’interno della fase di Sviluppo dovranno essere considerati tre momenti specifici:
Progettazione del software, in cui i requisiti sono tradotti in un insieme di
rappresentazioni, grafiche, tabellari o linguistiche, che descrivono le strutture dati,
l’architettura e le procedure algoritmiche;
Codifica, in cui le rappresentazioni sono tradotte in un particolare linguaggio di
programmazione generando istruzioni eseguibili;
Testing, in cui i programmi eseguibili sono controllati per scoprire eventuali errori, di
natura logica o di realizzazione.
Infine la fase di Manutenzione riguarda le modifiche da apportare al sistema,
necessarie non solo a correggere eventuali errori riscontrati, ma anche a adattare il
software ai cambiamenti subiti dall’ambiente originario (CPU, Sistema Operativo, unità
periferiche, ...) o a migliorarlo ampliandolo con nuove funzionalità che potrebbero
apportare benefici all'applicazione.
Una metodologia consiste in un processo per lo sviluppo organizzato utilizzando una
serie di tecniche coordinate.
Per quanto riguarda la metodologia usata per l’applicazione si è cercato di seguire OMT
(dall’inglese Object Modeling Technique) e OOSE (Object Oriented Software
5
Vedi [12] della bibliografia e [2q] in ‘Principali Siti di riferimento ’
7
Metodologia usata
Engineering) che consistono, sebbene con qualche differenza, nel costruire un modello
del dominio dell’applicazione e nell’aggiungere solo successivamente i dettagli
implementativi.
La metodologia OMT è basata sullo sviluppo in tre parti del modello del sistema,
modello che viene poi raffinato e ottimizzato per costituire un progetto. Il modello a
oggetti individua gli oggetti del sistema e le loro relazioni. Il modello dinamico descrive
la reazione agli eventi di oggetti nel sistema e l’interazione tra oggetti. Il modello
funzionale specifica la trasformazione di valori degli oggetti e i vincoli su queste
trasformazioni.
Le fasi in cui tali metodologie si realizzano sono:
•
Analisi: riguarda la comprensione e il modello dell’applicazione e del dominio nel
quale essa opera. L’input è una presentazione che descrive il problema da
risolvere e l’output un modello che individua gli oggetti e le loro relazioni, il flusso
dinamico di controllo e la trasformazione funzionale dei dati.
•
Progetto di sistema: usando il modello a oggetti si organizza il sistema in
sottosistemi sfruttando anche la concorrenza di alcuni task. Si prendono delle
decisioni sugli archivi e l’implementazione del modello dinamico.
•
Progetto degli oggetti: i modelli dell’analisi sono elaborati, raffinati e ottimizzati.
L’apporto della metodologia OOSE è stato nel fatto che vengono enfatizzati gli Use
Case Diagram che rappresentano, di fatti, la struttura portante dell’intero processo, e da
essi derivano tutti gli altri diagrammi.
Un approccio orientato agli oggetti sposta molti degli sforzi per lo sviluppo nella fase di
analisi. L’enfasi è sulle strutture dati piuttosto che sulle funzioni.
8
Metodologia usata
Figura 1: Schema generale dei passi seguiti
Anche per quanto riguarda questo documento, si è volutamente enfatizzata la parte
riservata all’analisi, visualizzando sia parte dei diagrammi costruiti in questa fase sia
parte dei diagrammi creati nella fase del progetto di sistema e degli oggetti. In sostanza
si è voluto descrivere con molto dettaglio la parte dell’analisi e della formulazione del
problema, per poi passare al risultato finale del progetto in termini di strutture dati e
funzionalità usando la notazione formale offerta dai diagrammi UML. Le fasi intermedie
del progetto di sistema e degli oggetti, anche se sviluppate durante la realizzazione
dell’applicazione, non sono state inserite.
9
Generazione dei requisiti
3 Generazione dei requisiti
3.1 Requisiti minimi
La struttura dell’e-mall deve essere modulare, scalabile ma allo stesso tempo robusta e
veloce da scrivere. All’interno del centro commerciale devono essere presenti un
numero di negozi sempre espandibile e con caratteristiche grafiche e di layout 6
condivise in modo da implementare nuove funzionalità in modo rapido ed efficace su
tutti i negozi scrivendo il codice solo per uno di essi. Tale negozio potrà anche essere
un negozio di test.
Dei negozi che vi sono presenti non sappiamo cosa venderanno, né quanti prodotti
avranno, né le tipologie di promozioni applicabili, né le diverse forme di trasporto.
La struttura del centro commerciale prescinde da tutto questo ma deve allo stesso
tempo prevedere la massima espansibilità in termini di funzionalità e la massima
maneggevolezza in termini di aggiornamento.
3.2 Requisiti ulteriori
Il sito deve essere progettato tenendo in considerazione la possibilità di prelevare
durante la navigazione una serie di dati che sono la base per una analisi approfondita
attraverso strumenti di data-mining e statistici. Attraverso queste analisi vengono creati
dei feedback7 al fine di migliorare la risposta alle esigenze dell’utente con pagine
sempre più facili e veloci da navigare.
All’utente devono essere offerti dei servizi attraverso i quali può aumentare il rapporto
one-to-one e di conseguenza la probabilità che l’utente torni e faccia acquisti. Tali
servizi devono essere realizzati secondo un ottica di Customer Relationship
Management (CRM) attraverso la quale l’attenzione viene focalizzata sull’utente e non
sul prodotto. La sensazione che il cliente deve avere è quella di visitare un negozio
amichevole con commessi virtuali e non, a cui chiedere informazioni su prodotti e
promozioni, consigli e delucidazioni di modalità di acquisto e spedizione.
6
Layout: disposizione dei vari oggetti nelle pagine (bottoni, immagini, link)
7
Feedback: informazioni e dati di ritorno
10
Generazione dei requisiti
Deve essere creata quindi una comunità virtuale che rappresenta i visitatori frequenti
del sito che si scambiano opinioni su articoli del centro commerciale ma anche su altro.
Tali opinioni possono essere prese in considerazione per improntare politiche di
marketing personalizzate. La conoscenza delle abitudini del cliente, dei suoi pareri s u
determinati prodotti, della storia delle interazioni che egli ha avuto con il contact center 8
deve permettere di poter offrire sempre prodotti con alto indice di gradimento, servizi
nuovi e allettanti e promozioni mirate.
3.3 Cosa non è richiesto
Per la realizzazione di Virtualmarket non è esplicitamente richiesto, in quanto assegnato
a personale tecnico specifico di progettare e realizzare:
•
impostazione grafica (scelta font, colori, abbellimenti estetici, realizzazione
animazioni, ecc…)
•
elaborazione dei contenuti non strettamente legati al mall (pagine FAQ, HOW TO, descrizione e foto dei prodotti, reparti, negozi)
•
configurazione del sistema per quanto riguarda la sicurezza e il funzionamento
dei server
•
gestione contatti con fornitori, gestori negozi (livello acquisti9 e produzione10)
•
gestione finanziaria dell’attività legata al mall (livello Finance)
3.4 Prime considerazioni sul progetto
L’elaborazione del progetto richiede quindi:
•
una definizione accurata della terminologia e del dominio di interesse,
•
uno studio di fattibilità che coinvolga le tecnologie da usare e i tempi realizzativi,
•
una panoramica su datawarehousing/data mining e OLAP,
8
Contact center: strumenti di tipo comunicativo (email, posta tradizionale, chat, forum, numero verde)
9
acquisti: livello in cui si focalizzano le problematiche relative all’acquisto dei prodotti da parte dei ‘negozianti’
10
Produzione: livello in cui si focalizza la fase di produzione del bene
11
Generazione dei requisiti
•
la progettazione,
•
la realizzazione,
•
un feedback dei risultati.
12
Formulazione del problema
4 Formulazione del problema
4.1 Ambito del problema
4.1.1 Livelli di presenza
(*)11
In base al tipo di azienda è necessario definire quale scopo si vuole raggiungere dalla
presenza nel nuovo mercato scegliendo quindi uno dei 3 livelli di presenza:
•
Basso o promozionale: prevede la presentazione dell’azienda, evidenziando la
sua attività, i prodotti, i servizi e le soluzioni offerte. Ha esclusivamente uno
scopo pubblicitario e informativo. A questo livello non si prevede interazione tra
visitatore e azienda.
•
Intermedio: prevede una maggiore quantità di informazioni per il visitatore tra cui
anche un catalogo e un listino dei prodotti, eventuali offerte speciali, la possibilità
di scambio di informazioni con l’azienda tramite posta ma anche la possibilità di
acquistare dei prodotti, non usufruendo delle tecnologie legate ai servizi di
pagamento elettronico ma fornendo i propri dati tramite email e fax.
•
Alto o orientamento alla vendita, customer care 12, call center: prevede un
elevato coinvolgimento dei visitatori attraverso la presentazione di pagine
dinamiche ed interattive. Si prefigge inoltre: ottimizzazione del rapporto fiduciario
con i clienti, customer care, assistenza tecnica on-line, assistenza pre e post
vendita, gestione ordini e acquisti e pagamento elettronico tramite transazioni
sicure usando anche la carta di credito.
Definito
l’obiettivo
bisogna
pensare
alla
realizzazione
del
sito:
definizione
dell’interfaccia e dei contenuti (catalogo, listino, descrizione dei prodotti); in questo caso
è da valutare bene la leggerezza delle pagine prodotte in quanto la rete itali ana non
brilla molto in velocità. La tecnologia e gli strumenti da adottare sono vari e vanno
11
vedi [15] della bibliografia
12
Customer Care: Servizi per il cliente pre e post vendita
13
Formulazione del problema
dall’implementazione in azienda usando HTML, CGI, ASP e linguaggi di scripting, sino
alla realizzazione del sito in outsourcing 13.
Realizzate le pagine WEB bisogna stabilire quale provider scegliere e quale soluzione
adottare per renderle disponibili on-line tra:
•
Hosting: si utilizza un certo spazio su di un server preesistente presso un
provider,
•
Server presso azienda: questa soluzione prevede la presenza di un server
presso la sede dell’azienda e la connessione ad internet tramite linea dedicata,
•
Housing: consiste nell’installazione di un server aziendale dedicato presso un
provider .
Dopo aver realizzato e pubblicato il sito bisogna impegnarsi alla sua diffusione e
pubblicizzazione: una volta presenti sul web è necessario far conoscere a tutti il sito
attraverso strumenti di promozioni sul web:
•
registrazione sui motori di ricerca,
•
scambio banner,
•
pubblicità via email,
•
fax,
•
mailing list e newsgroup.
Infine viene realizzato il supporto clienti che comprende:
•
customer care pre e post vendita sui prodotti,
•
call center per reclami,
•
informazioni addizionali ecc…
Le potenzialità di Internet sono la dinamicità e l’interattività. Meglio verranno sfruttati
questi fattori, migliori saranno i risultati.
Occorre dunque: aggiornare continuamente il sito con offerte promozionali e concorsi a
premi, FAQ e altro. Tutto questo spinge il visitatore ad accedere periodicamente al sito
aumentandone il numero degli accessi, indice di valutazione del successo del sito.
13
Outsourcing: richiedere ad altre aziende di realizzare servizi, infrastrutture con costi/benefici minori rispetto ad
una soluzione ‘ fatta in casa ’
14
Formulazione del problema
4.1.2 Definizione Commercio Elettronico (CE)
Si definisce commercio elettronico un insieme di transazioni commerciali tra produttore
(offerta) e consumatore finale (domanda), realizzata con l’utilizzo di computer e r eti
telematiche, e finalizzate allo scambio di informazioni direttamente correlate alla vendita
di beni e servizi.
4.1.2.1Tipologie di commercio elettronico
(*)14
Ci sono 4 categorie che contraddistinguono il commercio elettronico:
•
business to business: identifica le transazioni tra aziende
•
business to consumer: identifica le transazioni commerciali realizzate tra
azienda e consumatore finale
•
business to admnistration: riguarda tutte le transazioni effettuabili tra azienda e
pubblica amministrazione
•
consumer to admnistration: riguarda le transazioni tra cittadini e pubblica
amministrazione.
4.2 Cosa è necessario
4.2.1 Schema di una piattaforma di CE
(*)15
Un'applicazione di e-Commerce è costituita, oltre che da tutto quanto è visibile sul sito,
anche da tutta una serie di moduli che rappresentano l'infrastruttura del sistema.
Insieme si presentano e interagiscono tra loro.
In maniera schematica una piattaforma di e-commerce può essere articolata in una
parte definita di FRONT END e in una parte definita di BACK END riassumibili così:
14
vedi [15] della bibliografia
15
vedi [14] e [13] della bibliografia
15
Formulazione del problema
front end
•
un sistema di gestione catalogo (CMS)
•
un motore di visualizzazione
•
un motore di ricerca
back end
•
un sistema di gestione degli ordini
•
un sistema di gestione dei pagamenti
•
un sistema di profilazione utenti
•
un sistema di hosting
•
un’applicazione di data-mining e data-warehousing
4.2.1.1Front end
Sistema di gestione del catalogo (CMS)
Esso consente la definizione della struttura dei contenuti (asset), del loro layout grafico,
la revisione e infine la pubblicazione (con o senza livelli intermedi di staging16). Il CMS
deve permettere ad una squadra di redattori di comporre e modificare in modo facile i
contenuti che appariranno poi sul sito.
Il primo fattore da considerare durante la sua progettazione è la scalabilità del
sistema. L’adozione di un sistema non pienamente scalabile pone seri vincoli alla
possibilità di espandere rapidamente la dimensione dell’offerta. La scalabilità di un
sistema di gestione delle offerte si concretizza nella capacità di ospitare un numero
crescente di offerte commerciali senza che si pregiudichino le prestazioni sia dal punto
di vista della presentazione delle offerte al cliente, sia dal punto di vista della loro
gestione.
Un secondo parametro per la valutazione del sistema di gestione del catalogo è legato
alla possibilità di gestire proposte commerciali caratterizzate da una crescente
complessità come la possibilità di realizzare soluzioni di pricing complesse (coupon,
16
staging: possibilità di avere macchine o siti dove è possibile vedere anteprime di come i contenuti verranno
pubblicati.
16
Formulazione del problema
sconti, cross promotion 17, bundle18 ecc…) realizzando così una personalizzazione
spinta dell’offerta.
Tale pacchetto o modulo di solito è preferibile realizzarlo in azienda piuttosto che
comprarlo.
Motore di visualizzazione
Se è importante poter disporre di un valido catalogo è altrettanto vero che occorre avere
a disposizione un sistema di presentazione in grado di valorizzare le proprie offerte
anche per renderle più attraenti attraverso parametri flessibili di descrizione dell’offerta:
uso di testo, immagini, video e suoni.
Attraverso questo motore si deve invogliare l’utente a spendere parte del s uo tempo
all’interno del proprio spazio espositivo ma anche aiutare a comprendere al meglio il
valore del suo possibile acquisto in termini di convenienza e prestazioni.
Motore di ricerca e categorizzazione
Se si amplia l’offerta o se i parametri con i quali questa viene indicizzata diventano più
complessi occorre avere un motore di ricerca affidabile che permetta l’utente di arrivare
con efficacia e velocità al prodotto desiderato. E’ opportuno che l’utente abbia a
disposizione un meccanismo di ricerca che vada oltre le semplici parole chiave ma che
sia in grado di contestualizzare la ricerca, confrontare le offerte commerciali alternative.
4.2.1.2Back end
Sistema di gestione degli ordini
Ci sono diverse tipologie di gestione degli ordini. Si passa da sistemi in grado di salvare
le richieste del cliente all’interno di database, a sistemi che i tempo reale si interfacciano
con applicativi di ERP19 verificando l’effettiva disponibilità del bene. Nelle soluzioni più
evolute possono determinare addirittura l’avvio del processo produttivo, gestire la
17
Cross promotion: promozioni valide abbinando prodotti diversi
18
bundle: sconto applicato su prodotto distinti acquistati assieme.
19
ERP: Enterprise Resource Planning: sistemi informativi che gestiscono i vari processi aziendali: dalla
acquisizione materie prime, alla produzione, allo stoccaggio.
17
Formulazione del problema
spedizione del prodotto, consentire all’acquirente il tracking del proprio ordine e offrire
funzionalità legate al customer care e all’assistenza post vendita.
La gestione delle transazioni
Questa è un componente molto delicato. Bisogna tenere in considerazione 3 parametri
di valutazione generali:
•
la sicurezza percepita,
•
la flessibilità dei sistemi di pagamento e
•
il collegamento con i servizi bancari.
Il primo parametro riguarda la tranquillità con cui l’utente effettua un pagamento nel sito
in questione. Per aumentare tale tranquillità si possono usare:
•
sistemi di riconoscimento hardware,
•
gateway di pagamento collocati in banche o istituzioni di fiducia (SSL 20 e SET21),
•
sistemi di riconoscimento e certificazione da parte di società sopra le parti.
Molto importanti sono le pagine dedicate alle informazioni nelle quali l’utente può
trovare una risposta alle sue preoccupazioni in termini di sicurezza.
Un secondo parametro è la flessibilità: sia per tipologia dei mezzi di pagamento
supportati (carta di credito, bonifico, contrassegno, carte prepagate) sia per la
complessità di gestione del pagamento (calcolo dell’imposizione fiscale, pagamenti in
più valute, pagamenti ad attori differenti).
Il terzo parametro è la possibilità di interfacciarsi in modo agevole al sistema bancario in
modo sicuro e trasparente.
Esistono almeno tre livelli di gestione delle transazioni:
•
Nessuno: ci si appoggia interamente ad un'applicazione esterna, di solito quella
di una banca.
20
SSL: protocollo, sviluppato da Netscape, operante nello strato d i trasporto, che consente, grazie a tecniche
crittografiche a 128 bit, il trasferimento dei dati tramite la rete in modo sicuro, senza cioè che possano essere
intercettati da non autorizzati.
21
SET: (Secure Electronic Transaction) è un protocollo standard creato per tutelare la sicurezza e la riservatezza
delle transazioni di e-commerce su Internet. E’ stato sviluppato, da VISA e MasterCard con la collaborazione di
grossi partners (HP, Verifone, Microsoft, IBM , NetScape)
18
Formulazione del problema
•
Mercato - cliente: si gestisce solo la transazione finanziaria col cliente (verifica
dell'esistenza e congelamento della somma sul conto del cliente)
•
Completa: oltre a quella di cui sopra, si gestisce la logistica dei beni scambiati, e
l'effettivo trasferimento della somma a scambio avvenuto.
In genere all'applicazione di e-Commerce è richiesta la sola verifica della solvibilità
finanziaria del cliente e non la transazione vera e propria. Di questa e di altri dettagli si
occupano di solito società che offrono i cosiddetti servizi di e-fulfillment22.
Catalogazione degli utenti
Per offrire un prodotto quanto mai flessibile e di impatto è necessario un sistema di
profilazione utenti.
Si possono personalizzare:
•
prodotti offerti,
•
informazioni disponibili,
•
banner pubblicitari visualizzati,
•
il prezzo,
•
la modalità di pagamento e di consegna e
•
la tipologia di servizi a valore aggiunto offerti.
Perché tutto questo sia efficace e conveniente occorre disporre di un profilo dell’utente
che vada aldilà dei semplici dati anagrafici (età, figli, indirizzo) ma che tenga conto della
sua personalità, dei suoi hobby, dei suoi interessi e della sua evoluzione come cliente.
Aggiornando in tempo reale tali dati è possibile avere diverse tipologie di profilo:
•
un profilo anagrafico, ottenuto mediante la consueta form di registrazione;
•
un profilo di navigazione, ottenuto mediante un approfondimento delle statistiche
offerte dal server web;
•
un profilo degli interessi ottenuto mediante l’analisi delle pagine prodotto visitate
e dal click-throught dei banner;
22
E-fulfillment: In genere venduti dalle maggiori società di consulenza, offrono in outsourcing tutte quelle
operazioni che partono dal momento in cui l'ordine è acquisito verso la transazione finale. Oltre infatti all'aspetto
economico (la somma in denaro congelata sul conto del cliente viene effettivamente spostata sul conto del
venditore), l'e-fulfillment si occupa anche della logistica (eventuale movimentazione fisica delle merci) e delle
eccezioni (tutte le procedure di mancata consegna, per esempio).
19
Formulazione del problema
•
un profilo delle idee ottenuto mediante l’adesione dell’utente a sondaggi e forum
di discussione;
•
un profilo post vendita derivato dall’analisi delle mail, fax, telefonate ecc.. che
l’utente fa in seguito ad un acquisto per segnalare delusione, problemi,
soddisfazione e commenti in genere del prodotto acquistato.
Sistema di data-mining e datawarehousing
Una volta creato un sistema di profilazione degli utenti è necessario creare un sistema
di data-mining in grado di generare rapporti aggregati sugli utenti. Incrociando i diversi
profili utente mediante tecniche OLAP 23 è possibile generare analisi statistiche
fondamentali per realizzare rapporti ONE to ONE 24 con i clienti ma anche ottimizzare la
gestione di eventuali magazzini e ridurre i costi per esempio legati alla spedizione.
L’interazione tra l’utente e il sistema costituiscono una serie di flussi informativi
denominati catena del valore virtuale (value supply chain25) che produce il vero bene
dell’economia digitale: l’informazione.
Conoscere il cliente, le sue abitudini e i suoi interessi per anticipare le sue necessità e
meravigliarlo con livelli di personalizzazione inaspettati determina la possibilità di
aumentare il proprio business.
Analizzando le abitudini di acquisto, un business man può aumentare le informazioni su
quali prodotti e servizi un consumatore può volere e a quale prezzo vorrebbe pagarli. E’
inutile inondare i consumatori con offerte irrilevanti via mail, telemarketing o mass
media. Attraverso una modellazione predittiva e quindi con la premessa che ciò che i
consumatori hanno fatto ieri probabilmente lo faranno domani si possono mantenere la
maggior parte degli utenti acquisiti.
Sistema di hosting (ASP)
Una volta che il progetto di e-Commerce è stato sviluppato e testato, è tempo che
venga installato e ospitato presso un Application Service Provider. Si tratta, anche in
questo caso, di servizi in outsourcing volti a pubblicare e mantenere in vita
l'applicazione. L'ASP tipicamente si occuperà delle problematiche siste mistiche (quali e
23
OLAP: On-line Analitycal Process vedi paragrafo dedicato 4.3.5
24
Rapporto One to One: rapporto azienda – utente caratterizzato da una forte personalizzazione dell’offerta.
25
Value Supply Chain: catena del valore virtuale
20
Formulazione del problema
quanti server, quali connessioni di rete), di manutenzione (assicurare che il servizio sia
sempre attivo e funzionante), report di business intelligence
26
(quante page view,
quante hit, da parte di chi, con che frequenza).
4.2.2 Conclusioni
Da questo scenario segue che un'applicazione di e-Commerce non deve essere basata
esclusivamente sui moduli software classici:
•
Logica transazionale
•
Interrogazione in tempo reale di un conto corrente o di una carta di credito
•
Verifica on-line delle disponibilità
•
Gestione delle eccezioni (merce esaurita, cliente inesistente…)
ma deve essere sempre più affiancata da moduli che eravamo abituati a vedere nei
portali generalisti classici orientati alla comunità virtuale:
•
User profiling27
•
Forum
•
Chat
•
Eventi on-line (es.: diretta in streaming di un avvenimento)
•
Merchandising e pubblicità
•
Supporto WAP / XHTML per i dispositivi palmari
4.3 Contesto dell’applicazione
4.3.1 Business Intelligence
(*)28
26
Business Intelligence : vedi paragrafo successivo 4.3.1.
27
User Profiling: creazione del profilo dell’utente in base ai dati da lui immessi direttamente o indirettamente.
28
Vedi [5] della bibliografia e [9a],[3c] dei ‘Principali siti di riferimento ’
21
Formulazione del problema
La Business Intelligence è la conoscenza necessaria per capire e trarre vantaggio
dall’ambiente in cui un determinato processo opera.
Fattori di BI29 esterni possono essere informazioni sulle prestazioni dei fornitori, sui
concorrenti, sui corrieri ma anche i bisogni e le necessità dei clienti.
Fattori interni invece possono essere informazioni sui costi e qualità dei servizi e dei
prodotti in genere, la produttività e il time to market 30.
4.3.1.1Utilizzo
Quindi un’applicazione di Business intelligence colleziona tutti questi dati affinché
possano essere analizzati e, da questi, possano essere tratte delle informazioni che
vengono distribuite nei modi e nei tempi e alle persone più indicate in modo che
possano essere trasformate, per esempio, in azioni di marketing. Quindi, attraverso gli
strumenti di BI, si trasformano i dati in conoscenza affinché possano essere prese le
giuste decisioni nel più breve tempo possibile. E’ fondamentale poter misurare,
attraverso degli indicatori31, le prestazioni di fornitori e spedizionieri, la frequenza e la
qualità di acquisto dei clienti e il costo di produzione dei propri prodotti, in ogni momento
e nel formato di memorizzazione più appropriato.
In una applicazione di Business Intelligence ci si potrebbe chiedere, per esempio:
sono più remunerativi i nuovi clienti o quelli acquisiti?
Quale è il valore economico dei clienti migliori?
I clienti sotto i 35 anni sono remunerativi?
Quali sono i clienti che hanno il prodotto A ma non il B?
Quali sono i clienti che rispondono con solerzia a particolari campagne di marketing?
Una volta scoperti i vari segmenti di mercato si passa alla realizzazione di campagne di
marketing mirate.
29
BI: Business Intelligence
30
Time to Market: necessità di dover produrre beni in tempi prestabiliti
31
indicatori: parametri registrati durante le singoli fasi di una transazione commerciale e memorizzate nel db. Vedi
6.5
22
Formulazione del problema
4.3.2 CRM
(*)32
La raccolta dei dati per la creazione dei profili degli utenti per la proposta di offerte
mirate, la realizzazione di percorsi personalizzati di navigazione sul sito, ecc… rientra
in ciò che in gergo tecnico viene chiamato CRM ovvero Customer Relationship
Management.
Gli obiettivi principali del CRM sono quindi:
•
costruire legami profondi e a lungo termine con clienti scelti
•
essere più vicino al cliente nei punti di contatto (call center, forum, ecc…)
CRM usa un approccio progressivo per prelevare dati, trasformarli in informazioni e
quindi in conoscenza e successivamente adottare politiche di marketing mirate.
Figura 2: Passi da effettuare in una soluzione Datamining-CRM
33
Il primo passo di questo approccio è quello dove i dati sono trasformati in informazione
attraverso diverse operazioni di pulizia e filtraggio. Poi c’è la fase in cui queste
informazioni, contenute in tabelle aggregate e sommarizzate, diventano conoscenza
per chi le analizza, il quale, a questo punto, può intraprendere in modo più o meno
automatico delle decisioni (azioni).
32
vedi [3a],[3e],[1d],[7a] dei ‘Principali siti di riferimento ’
33
vedi [7a] della sezione ‘Principali siti di riferimento ’
23
Formulazione del problema
In realtà sarebbe meglio rappresentare questi passi come un ciclo perché di tale si
tratta:
Figura 3: Ciclo di vita di un'applicazione CRM
34
4.3.2.1CRM operazionale e analitico
Premesso che la gestione del cliente gioco un ruolo fondamentale per il successo
dell’azienda, il CRM può suddividersi in 2 grandi sezioni:
•
CRM OPERAZIONALE che prevede l’implementazione automatica di processi di
business orizzontali e integrati attraverso numerosi e interconnessi punti di
contatto con il cliente.
•
CRM ANALITICO che prevede l’implementazione progressiva di strumenti per la
gestione e analisi avanzata dei dati.
Gli strumenti del CRM OPERAZIONALE 35 sono:
34
vedi [3b] della sezione ‘Principali siti di riferimento ’
35
vedi fig. 4
24
Formulazione del problema
•
Call centers
•
Campaign management (gestione campagne promozionali)
•
Sales force automation (gestione automatizzata delle vendite)
•
Enterprise Resource Planning (pianificazione delle risorse)
•
Customer service (servizi per i clienti)
•
E-commerce web
mentre quelli del CRM ANALITICO
•
monitoring (monitoraggio di tutte le attività)
•
call behaviour analysis (analisi degli interventi al call center)
•
campaign analysis (analisi delle campagne promozionali per valutarne l’efficacia)
•
customer valuation (valutazione del cliente in base al grado di proficuità)
•
segmentation and profiling (segmentazione e profilazione degli utenti)
•
risk analysis
•
profitability analysis (analisi della redditività di una determinata azione di
marketing)
•
needs analysis (analisi delle esigenze degli utenti)
•
sales analysis
•
web analysis (analisi dei files di log)
•
behavioural modelling (modellazione del comportamento degli utenti durante la
navigazione)
•
quality of services analysis
Le tecnologie che stanno dietro al CRM analitico sono:
•
data warehousing
•
data mining
•
online analytical processing (OLAP)
•
sistemi di decisione avanzati e strumenti per il reporting.
25
Formulazione del problema
Figura 4: Componenti di una soluzione di CRM
36
Il flusso di informazione all’interno di un processo di CRM analitico può essere
schematizzato in questo modo:
1. inizialmente un dato operazionale (derivato cioè dall’interazione cliente -azienda)
viene prelevato da uno dei numerosi punti di contatto che potrà essere la pagina
degli acquisti, un forum di discussione, un call center ecc…
2. questi dati operazionali, assieme ad altri, quali i dati anagrafici, i dati della
navigazione e i dati provenienti da fonti esterne, vengono inseriti in un
datawarehouse;
3. a questo punto, mediante operatori OLAP, e tecniche di data-mining si
estrapolano pattern37 rilevanti e inizialmente sconosciuti per sottoporli a
successive analisi da parte degli esperti;
36
vedi [3a] della sezione ‘Principali siti di riferimento ’
37
pattern: relazioni fra entità o modelli della realtà
26
Formulazione del problema
4. infine, usando sofisticate tecniche di reporting applicate a questi dati, anche
basate su tecnologie web 38, si può migliorare l’efficienza degli strumenti
operazionali di CRM nonché l’offerta di business.
Figura 5: Dettaglio dei componenti di una soluzione di CRM
38
39
basate su tecnologie web: i report possono essere costruiti mediante interrogazioni di db da parte di pagine server
e visualizzate su pagine html.
39
vedi [10] della sezione ‘Principali siti di riferimento ’
27
Formulazione del problema
Figura 6: Flusso dei dati di una soluzione di CRM
40
4.3.3 Datawarehouse
(*)41
I data-warehouse sono un potenziamento del sistema informativo aziendale; non
sostitutivo del precedente sistema operazionale, ma completamento dello stesso,
attraverso l'integrazione e la strutturazione apposita atta al supporto degli ambienti tipici
della scienza decisionale.
I data-warehouse risolvono i problemi utilizzando la tecnica dell' in-advance42 ossia
prevenendo le richieste dell'utente. Questa tecnica si sviluppa attraverso il prelievo dei
dati da più sorgenti distinte, integrandoli e immagazzinandoli in un unico deposito per
facilitarne l'accesso e l'interrogazione.
40
vedi [10] della sezione ‘Principali siti di riferimento ’
41
vedi [2],[3],[4] della bibliografia e [1i],[1l],[3f],[3c],[3f],[6a] dei ‘Principali siti di riferimento ’
42
In advance: tecnica generica di risoluzione dei problemi che necessitano di lunghi tempi di computazione. La
tecnica consiste nel pre computare tutta od una parte delle operazioni
28
Formulazione del problema
Tecniche specifiche del datawarehousing sono la denormalizzazione e l'indicizzazione
effettuata con indici ad hoc o cablati per le specifiche query. La denormalizzazione della
base dati è una pratica molto usata che porta dei vantaggi, evita dei costosi join e alcuni
svantaggi, aumenta lo spazio occupato dai dati (informazioni ripetute).
Il data-warehouse deve essere:
•
orientato al processo: i dati sono organizzati relativamente ad una particolare
funzione o processo aziendale.
•
Integrato: i dati estratti da varie sorgenti, vengono ripuliti, trasformati e modellati
in modo da consentirne una gestione semplice ed efficace (es: il fo rmato di un
campo data può essere diverso da db a db, da piattaforma a piattaforma).
•
Non volatile: gli accessi ai dati avvengono in sola lettura.
•
Time variant: i dati vengono organizzati in periodi di tempo, caratteristica
fondamentale che consente di farne un'analisi temporale.
Il DW si distingue dai sistemi operazionali transazionali per i seguenti motivi.
i sistemi operazionali sono:
•
usati per automatizzare routines;
•
caratterizzati da un gran quantità di piccole transazioni con un ambito limitato;
•
disegnati per prelevare dati.
Mentre i sistemi di Business intelligence come i DW appunto o i DSS (sistemi di
supporto alle decisioni) sono:
•
costruiti per abilitare l’esplorazione, l’analisi e la presentazione di informazione;
•
caratterizzate da poche query con un ampio raggio di azione;
•
disegnate per estrapolare informazioni.
4.3.3.1I metadati
(*)43
43
vedi [1g],[3a],[3f] della sezione ‘Principali siti di riferimento ’
29
Formulazione del problema
La pulizia dei dati è importante anche per la creazione di una vista integrata dei dati di
un particolare soggetto che altrimenti sarebbero non consistenti. E’ in questo frangente
che si rendono indispensabili i metadati o data about data. Questi soggetti infatti, di
solito inseriti all’interno di aree riservati del DW servono a descrivere i dati stessi, la loro
struttura, la loro provenienza, il formato di memorizzazione, la loro interpretazione, i
possibili legami con gli altri dati.
Figura 7: Posizionamento metadati
44
Ci sono 3 tipi di metadati:
•
metadati di tipo build time: ogni qualvolta si disegna e costruisce un warehouse
si generano build time metadata che collegano termini tecnici con termini legati al
business, descrivono la struttura tecnica dei dati, memorizzano le frequenze di
aggiornamento dei dati, ecc…. Sono i metadati più dettagliati e sono usati dai
progettisti e sviluppatori del DW e dagli amministratori.
•
Metadati da utilizzo: quando il DW è in produzione, gli usage metadata, derivati
da quelli build time, sono uno strumento indispensabile per gli utenti e gli
44
vedi [3a] della sezione ‘Principali siti di riferimento ’
30
Formulazione del problema
amministratori perché spiegano il significato di una certa variabile di analisi ad un
livello alto di astrazione.
•
Metadati di controllo: questo tipo di metadati sono usati dai db e dagli applicativi
che accedono al DW. Essi memorizzano, per esempio, le informazioni relative a
dove risiedono i dati di alimentazione e in che tipo di database, i controlli di
sicurezza e di accesso. Tale tipo di metadati viene usato solo dai programmatori
di sistema per facilitar loro la stesura di utility di accesso a tali DW.
Come ho detto in precedenza i DW sono chiamati anche sistemi di archi viazione
multidimensionale.
I databases multidimensionali memorizzano i dati in una struttura a matrice che fornisce
una risposta rapida a query multidimensionali come le vendite per regione, per canale e
per prodotto. I databases multidimensionali contengono dati sommarizzati e di alto
livello in modo che i tecnici di e-business45 possono guardare a questi dati sotto
innumerevoli punti di vista e sotto ogni combinazione.
Nel seguente diagramma [fig. 8] si possono notare le possibili dimensioni di un
database di un sito di e-commerce.
45
e-business: ramo del business collegate ad attività tipicamente Internet
31
Formulazione del problema
Figura 8: Esempio di dimensioni e di fatti
46
4.3.4 Data-mining
(*)47
Il Data-mining è uno dei componenti del processo di scoperta della conoscenza
(Knowledge Discovery), può essere definito come un insieme di tecniche che
consentono di effettuare l’esplorazione e l’analisi dei dati per scoprire regole o modelli
nascosti
all’interno
di
archivi
di
grandi
dimensioni
in
modo
automatico
o
semiautomatico. Esso è un approccio multidisciplinare che riunisce un insi eme di
tecniche quali la statistica, la visualizzazione, i sistemi basati sulla conoscenza e i
sistemi ad autoapprendimento che consentono di scoprire la conoscenza e di tradurla in
regole o modelli atti a risolvere i problemi di business.
46
vedi [8a] della sezione ‘Principali siti di riferimento ’
47
vedi [1],[2] della bibliografia e [1e],[1f],[7a],[3d],[3a],[3e] della sezione ‘Principali siti di riferimento ’
32
Formulazione del problema
4.3.4.1Usi
Le tecniche di Data-mining sono impiegate per analizzare età, aspetti demografici,
fasce economiche di appartenenza, interessi e hobbies per migliorare i processi
conoscitivi e ridurre l’incertezza legata all’assunzione di decisioni, per esempio, per
quanto riguarda l'interazione con il cliente. Suggeriscono quindi strategie, effettuano
una sintesi dei dati per produrre informazioni strategiche.
4.3.4.2Possibili usi e benefici apportati:
•
rendere efficiente la distribuzione delle risorse
•
individuare opportunità di crescita
•
ridurre rischi di frode e di insolvenza
•
aumentare produttività e vendita
•
fornire l’opportunità di vendite congiunte
•
scoprire opportunità di vendita aggiuntive
•
ridurre l'esposizione ai rischi di mancato pagamento
•
distribuire più efficacemente le risorse
•
realizzare la classificazione e la profilazione degli utenti
•
guidare l’analisi dei prezzi e delle promozioni
•
fornire modelli di risposta
•
effettuare analisi di marketing e pianificazione
•
supportare la progettazione di nuovi prodotti
•
effettuare un controllo qualità
Attraverso le suddette tecniche di data-mining si possono per esempio affrontare quindi
le seguenti problematiche:
•
attrito: quale utente probabilmente smette di comprare un prodotto o un servizio
del nostro sito?
•
valore nel tempo:qual’è il valore di un consumatore tenendo conto di tutta la
storia dei sui acquisti nel nostro sito?
•
rischio di credito: qual’ è il profilo di rischio di credito di un consumatore in
seguito all’uso di carte di credito, pagamenti rateizzati e forti sconti?
•
frodi: quali consumatori stanno applicando delle frodi al nostro sito?
33
Formulazione del problema
Per esempio, i clienti ad alto profitto, ad alto valore e a basso rischio sono quelli che
ogni azienda vorrebbe avere a disposizione. Tali utenti rappresentano il 10 -20% dei
clienti che creano il 50-80% dei profitti. I clienti a basso profitto, alto valore e a basso
rischio sono molto “attraenti” ma nei loro confronti, un’azienda dovrebbe impostare abili
iniziative di aumento della profittabilità come il cross selling (la vendita di nuovi prodotti)
e l’up-selling (vendere più di ciò che un utente vuole acquistare) per poter aumentare il
profitto. I software di Data Mining aiutano a classificare gli utenti e a scoprire il target
delle proprie offerte più remunerativo.
4.3.4.3Metodologie usate
Le metodologie usate per riconoscere relazioni fra i dati sono 2:
•
Deduzione: si basa sul principio che l’informazione che si vuol trovare è una
conseguenza logica dei dati presenti nel db. Per esempio un join applicato tra
impiegati e dipartimenti e un altro tra dipartimenti e manager ci dice che esiste
una relazione fra impiegati e manager.
•
Induzione: si basa sul principio per cui l’informazione che si vuol trovare non è
altro che una generalizzazione di ciò che è nel db. Per esempio se l’informazione
sugli impiegati include manager e dipartimenti allora ogni dipartimento ha un
manager.
4.3.4.4Obiettivi del modello
•
Predizione: determinare modelli o regole per predire valori continui o discreti di
variabili a partire da valori dati in input
•
Classificazione,
•
Esplorazione,
•
Affinità: scoprire la probabilità che un evento avvenga in congiunzione con un
altro
4.3.4.5Tecniche di modellazione
Alberi decisionali:
34
Formulazione del problema
individuano i gruppi che avranno molto probabilmente effetti diversi su una
variabile obiettivo. Per esempio si possono trovare le caratteristiche degli
individui che risponderanno con maggiore probabilità ad una campagna
promozionale via email.
Reti neurali:
sono modelli che simulano la struttura del cervello umano imitandone i
meccanismi di apprendimento. In base ai dati di input le reti neurali correggono i
parametri del modello per trovare relazioni tra i dati.
Analisi dei cluster:
tecnica di riduzione dei dati che raggruppa casi o variabili in base a misure di
similarità. Questa tecnica consente di identificare gruppi di clienti basati su
caratteristiche demografiche, informazioni finanziarie o comportamenti di
acquisto.
Analisi fattoriale:
tecnica di riduzione dei dati che costruisce un modello a partire dai dati grezzi.
L'analisi fattoriale ricava fattori riassuntivi detti anche variabili latenti che
concentrano le informazioni contenute in un numero elevato di variabili.
4.3.5 OLAP
(*)48
Gli strumenti OLAP permettono l'interazione diretta degli utenti sui dati del warehouse
mettendoli in condizione di realizzare sofisticate indagini a supporto dei propri processi
decisionali senza conoscere la struttura della base dati.
Essi consentono di:
•
supportare le complesse analisi di un processo decisionale
•
analizzare i dati da varie prospettive (dimensioni)
•
agire dinamicamente su enormi quantità di dati.
35
Formulazione del problema
4.3.5.1Gli operatori
Questi obiettivi sono in parte raggiunti attraverso l'uso di operatori che l'utente può
eseguire sui diversi oggetti rappresentanti i dati in suo possesso.
Operatori tipici sono Drill-Down (eseguito su un attributo di una vista aggregata mostra i
dati della vista stessa ad un maggiore dettaglio rispetto all'attributo prescelto), roll-up
(al contrario roll-up aggrega i dati rispetto all'attributo prescelto), pivot (risulta
necessario per poter cambiare punto di vista ovvero cambiare la dimensione in analisi),
TopN (restituisce i primi n elementi rispetto ad un attributo).
Figura 9: Possibili viste ottenibili mediante l’uso degli operatori OLAP
49
Esempio di analisi attraverso gli operatori OLAP:
48
vedi [1] della bibliografia e [6a],[7a],[3f],[3c] dei ‘Principali siti di riferimento ’
49
vedi [3c] della sezione ‘Principali siti di riferimento ’
36
Formulazione del problema
una catena di negozi a livello nazionale per decidere l'apertura di nuovi centri vendita, ricerca quali punti vendita sono
maggiormente redditizi (TopN), analizza quindi i dati sui fatturati rispetto alle regioni (drill down) quindi rispetto alle città
all'ubicazione nei centri abitati.
Ma è fondamentale non solo dove costruire ma cosa costruire quindi si può spostare l'attenzione (pivot) alla tipologia di
punto vendita o ancora al tipo di oggetti venduti.
L' analisi viene condotta navigando i dati. Le interrogazione poste dall' utente attraverso
gli operatori OLAP partizionano l'insieme dei dati creando opportune viste.
4.3.5.2Le dimensioni
Per supportare un sistema OLAP, i dati devono essere organizzati tramite modelli
multidimensionali che rappresentano una concettualizzazione dei dati più vicina al
modo in cui il manager percepisce la realtà aziendale 50.
In un modello multidimensionale, la dimensione rappresenta un elemento o una
gerarchia di elementi visualizzabile ortogonalmente generando i cosiddetti cubi
relazionali.
Figura 10: Differenza fra database relazionale e multidimensionale
50
51
I manager pensano multidimensionalmente vendite per quadrimestre, per venditore costo per linea di prodotto per
regione in quanto le informazioni da elaborare provengono dalle interazioni di molte variabili come clienti, prodotti,
venditori.
51
Vedi [1] della bibliografia
37
Formulazione del problema
Esempio di dimensione sono il prodotto, il tempo, l'area geografica, mentre una
gerarchia potrebbe essere quella relativa alla dimensione tempo contenente gli elementi
anno, quadrimestre, mese, settimana e giorno.
4.3.5.3Olap Server
(*)52
In effetti il ruolo degli OLAP Server è quello di un robusto motore di calcolo affinché la
trasformazione dei dati storici in dati “derivati e proiettati” sia veloce e facilmente
disponibile per i vari strumenti di analisi come:
•
analisi delle vendite,
•
analisi delle iniziative di marketing,
•
what-if analysis53,
•
analisi sui costi di produzione,
•
analisi sulla profittabilità dei clienti e dei prodotti,
•
previsioni di vendita.
Risulta quindi evidente che un OLAP server si pone al centro di 4 grandi aree:
•
l’analisi multidimensionale
•
l’analisi statistica
•
query e reporting
•
data-mining
L’uso di un OLAP Server permette di avere:
•
l’ abilità di elaborare grandi volumi di dati e grandi quantità di utenti concorrenti
•
tempi di risposta consistenti e rapidi alle query, che permettono un’analisi
iterativa dei dati istantanea
•
metadati integrati che collegano l’OLAP server con il DW
52
Vedi [1h],[3c],[6a] della sezione ‘Principali siti di riferimento ’
53
What if: nome generico di tecniche di previsione di dati futuri da serie di dati di partenza. Vengono usate tecniche
neurali o statistiche.
38
Formulazione del problema
•
l’abilità di effettuare calcoli complessi come aggregazioni, calcoli matriciali e di
tipo cross-dimensional.
4.3.5.4Olap e datamining
“La differenza sostanziale fra OLAP e Data-mining è che OLAP è user-driven: l’analista
genera un’ipotesi e usa gli strumenti OLAP per verificarla. Data-mining invece, essendo
data-driven, viene usato per generare un’ipotesi. In modo simile, quando un utente usa
gli strumenti OLAP per esplorare i dati, egli guida l’esplorazione, mentre quando gli
utenti usano gli strumenti tipici del data-mining è il software che esegue e guida
l’esplorazione.
Il data-mining consente agli utenti OLAP di andare oltre i report riassuntivi. Il data mining ci dice perché un fenomeno sta succedendo mentre l'OLAP ci dice solo cosa.” 54
4.3.6 Decision support e reporting tools
4.3.6.1Tipologia d’uso
(*)55
Una volta analizzato il dato, con strumenti più o meno sofisticati, capita spesso che il
l’esperto di marketing voglia prendere egli stesso delle decisioni legate a tale dato ma
ancor più spesso può capitare che difficilmente saprà adoperare gli stessi strumenti di
un programmatore. Ecco quindi la necessità di sviluppare e visualizzare l’informazione
appena scoperta in un modo chiaro e sintetico per il marketer 56. Si possono usare
grafici a barre espandibili, menu top down associati a tecniche OLAP di drill-down ecc…
ma sempre in modo che un non esperto di informatica possa lavorare con tranquillità.
In sostanza, gli strumenti per il reporting permettono di formulare query senza che tali
utenti conoscano il linguaggio SQL, avendo anche la possibilità di visualizzare il
risultato in diversi formati.
54
Vedi [1] della bibliografia
55
vedi [2] della bibliografia e [3a] nella sezione ‘Principali siti di riferimento ’
56
Marketer: esperto di marketing
39
Formulazione del problema
4.3.6.2Tipologia di utilizzatori
(*)57
L’uso di tali strumenti può essere però differenziato a seconda dell’utilizzatore. In
genere ci sono 3 tipi di utilizzatori:
•
Power user: rappresentano il 5-10% degli utenti e lavorano sui dati
giornalmente, trasformandoli in informazioni utili per loro o per l’impresa. Sono
quindi i responsabili della creazione della business information e spesso creano
anche nuovi modi di vedere e usare tali informazioni. Gli strumenti per tale
tipologia di utenti debbono permettere loro di scavare in profondità nei dati
presenti nei DW e permettere di risolvere problemi complessi di accesso e
trasformazione.
•
Independent users: rappresentano il 10-20% di tutti gli utenti e regolarmente
usano le informazione dettate dai power user per costruire report e fornire al
management informazioni più o meno dettagliate. Tale tipologia di utenti possono
usare sia strumenti di Business Intelligence usati anche dai power user (ma non
nella stessa intensità) che strumenti di tipo office, usati di norma negli uffici,
come fogli di calcolo, elaboratori di testi e sistemi di messaggistica.
•
Dependent users: costituiscono il 70-80% degli utenti di una organizzazione di
business e sono i principali utenti dell’informazione che i power e gli
indipendent user hanno generato. Usano abitualmente strumenti standard di
uso negli uffici come fogli di calcolo, elaboratori di testo. Molta di questa
informazione viene presentata in forma di report standard. Tali utenti
rappresentano quindi coloro che prendono le decisioni o le eseguono e
raramente sono interessati dagli aspetti tecnici di come alcuni dati sono stati
elaborati.
Quindi, in questa catena di produzione dell’informazione (information supply chain) i
metadati sono molto importanti in quanto, attraverso di essi, ciascun tipo di utente può
risalire a tutte le informazioni di interesse. Quindi i creatori di informazione devono
essere capaci di pubblicare tale informazione con un consistente set di metadati.
40
Formulazione del problema
4.4 Ipotesi
4.4.1 Il server Web e il concetto di sessione
Sul lato server si concentra la logica che gestisce la navigazione e fa da tramite tra
cliente e fornitore.
Le problematiche da affrontare sono:
•
gestione contestuale di sessione, dove per sessione si intende l’insieme ottenuto
da: intervallo di tempo durante il quale avviene la navigazione, dati che
progressivamente l’utente inserisce e risultati parziali ottenuti mediante il
percorso,
•
controllo del dialogo con l’utente, dove per dialogo si intende la sequenza di
navigazione eseguita, le azioni conseguenti alle varie scelte utente e i dati
associabili a ciascun passo compiuto,
•
interfaccia verso il venditore.
Nel caso dell’e-commerce il concetto di sessione è importante: si pensi per esempio al
fatto di dover vietare la possibilità che un utente acceda ad una pagina intermedia di
inserimento dati memorizzata precedentemente in un bookmark in quanto al di fuori di
un flusso coerente di dialogo (si associa il dialogo ad una sessione).
In passato la soluzione a questo problema era rappresentato dai co okies. Poiché la
popolazione dei navigatori è divisa fra chi non ha difficoltà ad ospitare tali cookies e chi
invece li evita, l’uso dei cookies è problematico. L’alternativa è quella di far circolare
l’identificativo di sessione in modo trasparente all’utente come una qualsiasi variabile di
pagina58. L’unico inconveniente di questa tecnica è che deve essere gestita in modo
che l’utente non modifichi tale valore in modo malizioso e ricavare, per esempio,
informazioni riservate.
In Virtualmarket il problema è stato risolto usando, in modo congiunto, delle variabili di
sessione59 e delle variabili di querystring60 e dai cookies, i cui valori vengono
memorizzati anche nel database. Se l’utente accettasse i cookies, si userebbero solo
57
vedi [1c],[1g] della sezione ‘principali siti di riferimento ’
58
Variabile di pagina: se si usa html puro si possono impostare dei valori per i campi nella querystring di ogni url
altrimenti si possono usare variabili di javascript o Vbscript.
59
Variabili di sessione: vedi paragrafo relativo al linguaggio ASP 5.3.1.
60
Variabili di querystring: sono variabili che si trovano nell’url separati da ? e &
41
Formulazione del problema
delle variabili di sessione i cui valori verrebbero memorizzati anche nei cookies per il
riconoscimento successivo. Se invece l’utente non accettasse i cookies, allora verrebbe
usata la variabile di querystring (nel progetto si chiama vmid), comparando il suo valore,
unito a quello dell’indirizzo IP e di una variabile, sessionid, generata dal web server e
unica, durante la stessa sessione, per ogni utente, con il rispettivo valore contenuto nel
db.
Se avvenisse un esito positivo della comparazione, allora l’utente verrebbe
riconosciuto come esistente e la variabile vmid rimarrebbe invariata altrimenti verrebbe
considerato nuovo utente e verrebbe generato un nuovo valore per la variabile 61.
Un altro problema è legato alla sequenza e coerenza dei dati inseriti da parte dell’utente
se questi appaiano in tempi distinti. Il fatto che durante tale navigazione egli possa
giocare con i tasti backward e forward del browser per revocare o inserire una scelta
non deve compromettere il corretto calcolo del prezzo finale.
Quando l’utente non naviga tramite hyperlink e/o bottoni in pagina non deve poter
alterare i dati senza che il sistema se ne accorga.
Le soluzioni a questo tipo di problema sono tre:
•
si riassume tutto il dialogo in una sola pagina, popolandola con una quantità
inverosimile di dati;
•
si cerca di disabilitare all’ingresso del sito i bottoni del browser dell’utente;
•
si gestisce architetturalmente e/o applicativamente sul server il transito
attraverso ciascuna pagina.
La soluzione applicata in Virtualmarket, anche se ne parlerà dopo, ne l capitolo della
progettazione, divide il dialogo in più pagine memorizzando i valori dei campi delle form
in variabili di pagina e nel database e disabilitando il caching delle pagine 62 ,
costringendo l’utente a reinserire i valori nel caso torni indietro con il tasto backward. Se
invece l’utente tornasse indietro attraverso opportuni link di pagina, lo stato della
transizione tornerebbe indietro di uno o più passi in modo corretto e pilotato e i valori
dei campi, nonché il contenuto del database, verrebbe ristabilito ai valori iniziali,
sfruttando le variabili di pagina.
61
vedi paragrafo ‘modulo profili utente ’ 6.6.2.3.1
62
Disabilitazione del caching delle pagine: si impedisce di visualizzare, attraverso il tasto back del browser, il
contenuto di una pagina già processato non memorizzandone i valori nella cache del browser.
42
Formulazione del problema
4.4.2 Qualità del software
Nella progettazione di un’applicazione Web, come in ogni altro prodotto, bisogna tener
presente che esso deve rispondere a determinate qualità.
Il primo fra tutti è la correttezza e cioè l’aderenza alle specifiche del problema.
Altri fattori importanti sono le prestazioni63 e la scalabilità.
I fattori che influenzano le prestazioni sono:
•
l’architettura generale del sistema che prevede l’utilizzo di più server,
•
la comunicazione fra i vari tipi di server e quindi l’infrastruttura di rete,
•
la presenza o meno di componenti efficienti,
•
la comunicazione fra i vari componenti,
•
elevato controllo sulla validità delle immissione dati,
•
gestione delle transazioni a livello di componenti e di database,
•
accesso a origini dati eterogenee.
Il concetto di scalabilità è strettamente legato a quello di prestazioni. La scalabilità è la
capacità di un’applicazione di supportare il numero di utenti necessario, sia che esso
sia ridotto o elevato. Maggiore è il numero di utenti che è in grado di supportare e
migliore sarà la scalabilità.
Le altre qualità che si è cercato di rispettare sono state:
1) modificabilità ovvero la facilità di adeguamento e trasformazione del
programma ottenibile dividendo sempre (fisicamente o solo logicamente) lo
strato di dati, dallo strato applicativo, dallo strato di presentazione e layout.
2) Flessibilità ovvero la capacità del programma di rispondere in maniera coerente
e rapida a nuove esigenze ottenibile preferendo soluzioni create in proprio
piuttosto che acquistare prodotti già confezionati.
3) Sicurezza sull’ Input/Output: ottenibile memorizzando i valori ad alto rischio
(contenuto del carrello, dati dell’utente) in un database piuttosto che in file di
testo come i cookies..
4) Leggibilità intesa come capacità di far comprendere in ogni momento al
progettista e a altre persone le scelte fatte, ottenibile suddividendo il più possibile
63
Prestazioni: in questo documento per prestazione si intende capacità di risposta dell’applicazione in termini di
tempo.
43
Formulazione del problema
il codice html dal codice del linguaggio scelto e usare linguaggi formali di
specifica come UML.
5) Parametricità intesa come grado di generalità che presenta il programma, in
grado di rispondere quindi ad una classe di problemi piuttosto che ad uno
specifico, ottenibile spostando tutta la logica del programma nei componenti 64 in
modo tale che, l’uso di opportuni parametri permetta di invocare i metodi in modo
corretto e popolando il database con i metadati che permettano di distinguere, i
singoli casi e, quindi, che aiutino ad invocare i metodi più opportuni.
6) Portabilità lato server intesa come possibilità di eseguire il programma in
ambienti di calcolo diversi da quello per cui inizialmente è stato progettato,
ottenibile usando una comunicazione standard (SQL, stored procedures) tra lo
strato applicativo e il db, evitando di usare strumenti proprietari del DBMS
adottato, sebbene rinunciando ad una maggiore velocità e limitare, per quanto
possibile, l’uso di proprietà tipiche del Web Server in uso.
7) Efficienza intesa come capacità a calcolare i risultati sfruttando poche risorse di
calcolo, ottenibile usando poche variabili di sessione e di applicazione 65 e evitare
di memorizzare grosse quantità di dati nelle variabili di output.
8) Portabilità lato client intesa come capacità di rendere visualizzabili in modo
corretto, in ogni tipo browser, le pagine dell’applicazione, ottenibile creando
pagine aderenti allo standard HTML 3.2 relegando l’uso di tecnologie troppo
recenti a funzionalità estetiche.
4.4.3 Compatibilità con i browser in circolazione
Per realizzare le pagine, e quindi il dialogo con l’utente, sono a disposizione strumenti
come le normali pagine HTML, le pagine ASP o PHP, gli script, le applet JAVA. La
scelta dipende principalmente da 2 fattori:
64
•
il livello di bellezza del sito (intesa sia come estetica che come performance),
•
la dimensione del gruppo di utenti che si accetta di escludere dal dialogo.
Componenti: oggetti COM distribuite sotto forma di librerie DLL che racchiudono funzionalità richiamabili
all’interno di programmi scritti anche in linguaggi diversi da quelli con i quali si è scritto e compilato il
componente. Vedi paragrafo ‘programmazione a componenti ’ 5.3.6
65
variabili di sessione e di applicazione: vedi paragrafo ‘linguaggio di programmazione ASP ’ 5.3.1
44
Formulazione del problema
Gli strumenti più sofisticati che consentono di rendere il dialogo più prestante e
divertente possono non essere supportati da tutti i browser in attualmente in
circolazione. Il primo errore da evitare è quello di presupporre che il profilo del possibile
compratore Internet coincida con un profilo che dispone delle ultime versioni di tutto.
Un altro aspetto fondamentale è la tecnica da adottare per le trasmissioni dei dati che
non possono circolare in chiaro sulla rete. Ad esempio, la protezione dei codici delle
carte di credito usate per gli acquisti in rete è più che strategica. Una scelta possibile è
quella della crittografia SSL.
Anche queste scelte influiscono sull’accessibilità del sito: non tutti i browser supportano
le varie versioni dell’ SSL e le ultimi versioni di SSL con più bit, non sono supportate
dalle versioni meno recenti dei browser in circolazione.
4.4.4 Soluzioni non adatte
La necessità di avere un e-mall dinamico ed espandibile mi obbliga ad escludere
diverse possibilità realizzative come lo sviluppo di un sito statico cioè basato su
linguaggi a contenuto statico (client-side)66 e su memorizzazione dei dati su flat-file.
L’eventualità, infatti, di poter prelevare dei dati come i dettagli dei prodotti e di
memorizzare i dati sulle vendite nonché dei profili degli utenti, mi impone di evitare l’uso
di pagine statiche (basate cioè su html puro) in quanto mi obbligherebbe a scrivere una
pagina descrittiva di prodotto per ogni prodotto per non parlare dei reparti e dei negozi.
Ricordo infatti che si tratta di un e-mall con una quantità di negozi, reparti e prodotti non
definita all’inizio e in continuo cambiamento anche in base a determinati periodi
dell’anno. Parte del materiale utilizzato, come ad esempio, foto o slogan pubblicitari,
potrà essere preesistente, ma il tempo necessario per comporre le varie pagine HTML
sarà molto lungo e costoso.
Poiché le caratteristiche di un prodotto, di un reparto o di un negozio variano nel tempo,
è necessario che le pagine WEB che compongono il sito, siano continuamente oggetto
di manutenzione. Anche l’operazione di modifica di un prezzo di un libro potrebbe
comportare la modifica di molte pagine. Quindi l’uso di pagine statiche (pagine che
riflettono in ogni momento la situazione esistente nell’istante in cui sono state create,
non quella in cui sono state lette) non è accettabile.
66
html, javascript, ecc…
45
Formulazione del problema
Si deve perciò usare una tecnica differente per la stesura delle pagine. Si è pensato di
usare la tecnologia delle pagine Server-side cioè elaborate direttamente sul server al
momento della richiesta e inviate al browser dell’utente mediante accessi a uno o più
databases. La possibilità di avere migliaia di prodotti, decine di promozioni legate ad
ogni singolo prodotto, migliaia di profili utente, rende praticamente inutilizzabile la
memorizzazione dei dati su file di testo. Ecco allora la necessità di avere uno o più
database relazionali che supportino centinaia di transazioni contemporaneamente e che
rendano quindi più scalabile e performante l’applicazione.
L’eventualità di usare un database orientato agli oggetti è stata scartata per diversi
motivi. Questa tipologia di database nasce per ottimizzare la memorizzazione di dati di
tipo multimediale (documenti pdf, immagini, video). Sebb ene il sito possieda questo tipo
di files il loro numero non è elevato e quindi la scelta di tale tipologia di DBMS non ci
avrebbe dato sostanziali vantaggi se non nella completa trasparenza nella loro gestione
(non ci sono problemi di coerenza dei link in caso di spostamento e ridenominazione
delle immagini in quanto integrate nel DBMS). Inoltre, memorizzare le descrizioni dei
prodotti sotto forma di file pdf o simili avrebbe reso più difficile la loro modifica da parte
dei gestori dei negozi, che ricordiamolo, possono intervenire in remoto per la gestione
del catalogo. La tecnologia a oggetti non è ancora abbastanza matura in termini di
performance e quindi ho pensato che
sia
auspicabile adottare una forma di
memorizzazione rapida da implementare 67, consolidata nel tempo (assenza di problemi
di gestione), con notevoli doti velocistiche nel recupero e memorizzazione dei dati a
tempo di esecuzione (quindi di tipo operazionale) e perfettamente integrata nel contesto
delle altre scelte architetturali 68 .
La scelta quindi è ricaduta su un database di tipo relazionale, ormai standard nell’uso,
nel quale gli oggetti multimediali sono stati trattati attraverso link alle posizioni nel File
System, memorizzando quindi la loro posizione e non l’oggetto stesso.
67
rapida da implementare: uno dei requisiti è rispettare i tempi stringenti di realizzazione e l’uso di un database non
comune come quelli a oggetti avrebbe comportato tempi di apprendimento e costi di gestione più alti.
68
vedi paragrafo ‘Scelte progettuali ’ 6.3
46
Formulazione del problema
Nasce quindi l’esigenza di progettare un sito web dinamico. Una pagina html dinamica è
una pagina che non esiste a priori ma che viene generata a partire da una richiesta
dell’utente e quindi essa rifletterà la situazione esistente nell’istante della richiesta
attraverso le informazioni memorizzate nel database.
47
Architetture e linguaggi
5 Architetture e linguaggi
5.1 Architetture a modelli
(*)69
Il modello di un’applicazione aziendale può essere una struttura costituita da sei
sottomodelli, ciascuno dei quali descrive un’area specifica dell’architettura e dei requisiti
di un’applicazione. I modelli sono:
•
il modello di sviluppo, che descrive le aree del processo di sviluppo inclusi i team
di sviluppo, processo di verifica, controllo del codice sorgente, punti di riferimento
e risultati di sviluppo. Si compone di 2 sottomodelli: il modello dei processi e
quello dei ruoli. Nel primo si affrontano i problemi legati alla pianificazione e alla
programmazione e nel secondo l’organizzazione del team di sviluppo.
•
Il modello aziendale, che descrive aspetti quali profitto del capitale investito,
vincoli del piano di lavoro.
•
Il modello utente, che descrive i requisiti dell’interfaccia utente, la quantità di
documentazione richiesta dall’applicazione, il livello di competenza richiesto
dall’utente.
•
Il modello logico, che descrive le entità, la struttura dell’applicazione, incluse
modellazione dei componenti e dei dati e definizioni dell’interfaccia.
•
Il modello tecnologico, che descrive le tecnologie utilizzate per implementare
l’applicazione, dalla piattaforma server agli strumenti di sviluppo.
•
Il modello fisico, che descrive la distribuzione fisica dell’applicazione, inclusi i
server utilizzati e la posizione dei componenti.
69
vedi [8] della bibliografia
48
Architetture e linguaggi
Figura 11: Architettura a modelli
70
5.2 Architettura di un’applicazione Web
(*)71
Le applicazioni Web includono un browser Web, script lato client e lato server, un
server WEB, componenti, un database che può contenere anche parte del codice sotto
forma di Stored Procedure 72.
La locazione di tali sistemi può avvenire su un unico computer o su computer diversi a
seconda delle dimensioni dell’intero sistema.
Ma vediamo di approfondire le varie tipologie di architetture con le quali possiamo
disporre le risorse in una rete.
5.2.1 Sistemi HOST
La prima architettura apparsa sullo scenario dell’elaborazione dati è quella basata su
sistemi HOST. Questa è un’architettura centralizzata dove tutto il carico elaborativo è
affidato all’HOST computer, macchina potente e spesso molto costosa. Sia la base date
che le applicazioni risiedono nell’HOST, gli utenti vi accedono medianti terminali stupidi.
Ancora oggi la maggior parte delle soluzioni è basata su questo tipo di architettura.
70
vedi [8] della bibliografia
71
Vedi [6],[8] della bibliografia
72
Stored Procedure: codice SQL memorizzato all’interno del DBMS che può essere eseguito senza compi lazione e
quindi con maggior velocità rispetto le query dinamiche.
49
Architetture e linguaggi
5.2.2 Architettura a LAN
Verso la fine degli anni ottanta iniziò a diffondersi l’architettura basata sulla LAN (reti
locali) che è l’antitesi dell’architettura centralizzata. Tutta la logica delle applicazioni
risiede su pc e grazie alla rete locale è possibile condividere risorse come database,
file, stampanti ecc… in un sistema informativo basato su LAN esistono n postazioni
intelligenti che accedono ad un server passivo contenitore di dati e risorse.
5.2.3 Client/Server
Con l’architettura client/server siamo in presenza di una divisione equa dei compiti tra
nodi client e nodi server. Nei client risiede tutta l’interfaccia utente, la logica per la
richiesta delle informazioni al server e la gestione dei risultati (front end del sistema
informativo). Il server si preoccupa di elaborare le richieste del client e fornire i risultati
(back end).
In questo modo front end e back end sono nettamente separati in termini di
progettazione, piattaforma e tecnologia hardware.
5.2.4 Multi-Tier
L’ultima novità è senza dubbio l’architettura Client/server a tre (o più) livelli (3-tier)73 e
tutto ciò che vi ruota intorno:middleware, componentwar e, oggetti distribuiti, broker74,
COM, DCOM e CORBA. Tale struttura consiste nel pensare ai livelli su cui
un’applicazione viene costruita. Si parla di applicazione su n livelli quando si cerca di
astrarre i servizi dell’applicazione in funzione del livello in cui essi operano.
73
Vedi [6],[8] della bibliografia [1l] della sezione ‘Principali siti di riferimento ’
74
broker: canale di comunicazione fra gli oggetti
50
Architetture e linguaggi
75
Figura 12: Esempio di architettura a 3 livelli
In genere si parla di applicazioni a 3 livelli dove i 3 livelli sono:
•
livello browser/client,
•
livello aziendale/business,
•
livello dati/fisico.
Livello client
Per quanto riguarda il livello client, le scelte da fare riguardano quali browser supportare
in termini di funzionalità/plug-in da essi supportati, come per esempio il supporto per
Javascript, Java, Flash ecc… Bisognerebbe sempre accantonare l’ipotes i per cui ogni
utente possa avere sempre l’ultima versione del browser più usato e con tutte le
funzionalità abilitate. Ci possono venire incontro le statistiche che ci possono dire che
fetta di utenti potremmo tagliar fuori se, per esempio, usassimo Javas cript nelle nostre
pagine. A questo punto, studiando in modo approfondito tali statistiche, possiamo
scegliere, in maniera ponderata e con rischi calcolati, quali funzionalità supportare.
Livello aziendale o server
75
vedi [1l] della sezione ‘Principali siti di riferimento ’
51
Architetture e linguaggi
A livello aziendale bisogna scegliere quali server usare e se usare script o componenti
per implementare la business logic e anche dove installarli. La scelta di usare script o
componenti riflette il fatto di dover scrivere applicazioni di piccolo o grande peso e di
dover nascondere tutta la logica che sta dietro ad un processo.
L’uso di componenti compilati anziché di script interpretati offre diversi vantaggi:
•
la velocità di esecuzione,
•
la possibilità di essere gestiti in maniera transazionale,
•
la possibilità di riutilizzo di tali componenti in ambienti diversi da quello per cui
sono stati scritti,
•
maggiore scalabilità,
•
più facilità nella gestione e nell’aggiornamento rispetto agli script
•
migliore incapsulamento delle informazioni e delle procedure.
D’altro canto c’è un maggior overhead in quanto ogni componente deve essere
istanziato e caricato, la scrittura dei componenti richiede la conoscenza dei fondamenti
della programmazione object oriented COM e l’abilità nell’uso degli ambienti Visual C o
VisualBasic. Diciamo che per piccole applicazioni l’uso degli script è senz’altro da
preferire per la velocità e semplicità con cui vengono scritte pagine con codice HTML e
Vbscript mescolati fra loro. Per le applicazioni di grandi dimensioni e con la necessità di
nascondere la business logic allora si passa ai componenti.
Livello dati/fisico
(*)76
A questo livello vengono scelti il DBMS e la tipologia di accesso ai dati (SQL, Stored
Procedure).
Per quanto riguarda la tipologia di accesso ai dati, posso affermare che i principali
modelli di API sono: ODBC, OLEDB e ADO.
ODBC è estremamente legato al mondo del relazionale. Il suo utilizzo è stato efficace
fino a poco tempo fa, quando la maggior parte dei dati era di tipo testuale. Oggi, la
notevole presenza di documenti multimediali come testi in pdf, imma gini, messaggi
email, video, pagine html rende il modello ODBC molto lento e poco efficiente nella
gestione di questo tipo di archivi.
76
vedi [6], [11], [19] della bibliografia
52
Architetture e linguaggi
Si è pensato, allora, sia di adottare database orientati agli oggetti oppure di modificare
le modalità di accesso ai db relazionali estendendoli alle nuove forme di dati. La
seconda soluzione sembra sia stata la vincente, in quanto, l’utilizzatore finale ha il solo
compito di modificare in minima parte i propri script di accesso ai dati, mentre i
progettisti dei DBMS debbono aggiornare i moduli che, in tali sistemi di database,
hanno il compito di interporsi tra i dati e il mondo esterno (driver di interconnessione),
lasciando quindi inalterato tutto il resto, compresi l’insieme degli strumenti a corredo dei
vari DBMS già noti agli utilizzatori. La scelta di usare un database Object Oriented
implica l’acquisto e l’apprendimento di uno strumento completamente nuovo che non
ripaga sempre, in termini di tempo di esecuzione query e di efficienza, gli sforzi
economici sostenuti.
Nel caso di un sito di e-commerce generico per esempio, la presenza di file multimediali
non è notevole come potrebbe esserlo per un archivio di dischi o video musicali e il
database deve integrarsi perfettamente con altre entità quali web server e la tecno logia
scelta per la creazione delle pagine web. Quindi è auspicabile, in questi casi, usare
strumenti più maturi e comunque standard de facto.
Una nuova modalità di accesso a database che rendesse più semplice e efficiente la
gestione del dati multimediali è stata OLEDB. ODBC non è stato eliminato ma
ridimensionato e usato nelle situazioni dove c'è il relazionale e dove le applicazioni non
supportano la modalità OLEDB. La differenza fra ODBC e OLEDB sta nel fatto che
mentre ODBC fornisce un insieme di API, OLEDB è costituito da una serie di interfacce
basate sul modello COM. ODBC è function oriented, mentre OLEDB è object oriented.
Implementare interfacce OLEDB significa realizzare OLEDB Provider. Gli applicativi
che accederanno mediante tali provider alle fonti dati si chiameranno OLEDB Dataconsumer. Con OLEDB sarà quindi possibile accedere a sorgenti di dati relazionali, file
di testo, messaggi email se per ognuno di essi ci sarà un provider.
Scrivere data-consumer che supportino OLEDB è molto difficile in quanto bisogna
conoscere le specifiche COM di tali interfacce e saper programmare in C o in
VisualBasic. Per evitare di conoscere in modo approfondito questi linguaggi e
velocizzare la realizzazione di applicativi con accesso a database che supportino
OLEDB viene progettato ADO 77, una libreria DLL basata su OLEDB e COM.
77
ADO vedi paragrafo ADO 5.3.1.3
53
Architetture e linguaggi
Figura 13: Architettura sistema OLE-DB
78
Per quanto riguarda le Stored Procedure bisogna dire che il loro uso aumenta
l’efficienza con cui vengono processate le query, in quanto, se si usasse l’SQL dinamico
all’interno di pagine server, il driver del database dovrebbe prima analizzare la query,
convertirla in un formato riconosciuto dal db e quindi eseguirla, aumentando, di fatto,
l’overhead del DBMS.
L’uso di SP, ovvero di blocchi precompilati di codice SQL, consente di passare i
parametri appropriati in maniera semplice e di accedere ai dati nel DB riducendo al
minimo la quantità di dati da trasferire attraverso la rete.
78
vedi [11] della bibliografia
54
Architetture e linguaggi
5.3 I linguaggi di programmazione
Facciamo una panoramica sui diversi tipi di linguaggio, di strumenti e tecnologie che
rendono possibile lo sviluppo di siti internet dinamici e connessi a database.
•
ASP,
•
PHP,
•
script CGI,
•
JSP,
•
programmazione a componenti.
Nei paragrafi seguenti verranno analizzati i vari linguaggi o tecnologie anche se per
Virtualmarket ne è stata usata essenzialmente una, ASP (PHP è stato usato ma
relegato al prelievo di dati memorizzati nel server Linux che gestisce la posta).
Verranno proposti degli esempi che, per quanto riguarda ASP, sono porzioni di codice
ripulito e abbreviato, del sistema sviluppato, mentre per quanto riguarda PHP e JSP
sono porzioni di codice che eseguono le stesse operazioni delle prime e sono stati
inseriti per confrontarne le differenze.
5.3.1 ASP
(*)79
Asp è l’acronimo di ACTIVE SERVER PAGES ed è una tecnologia legata all’ambiente
Microsoft Windows NT con Internet Information Server.
L’introduzione dei linguaggi di scripting client side avevano lo scopo di bilanciare il
carico di lavoro tra il browser e il server. Nella situazione delineata con ASP c’è un
ritorno ad un modello centrato sul server.
A differenza di ciò che avviene per i comuni documenti HTML che il server si limita a
rilasciare al cliente senza esaminarne il contenuto, le pagine ASP sono elaborate prima
della spedizione. Esse contengono delle istruzioni che sono interpretate dal server e
che producono un risultato codificato in html e aggiunto al normale contenuto della
pagina. Uno dei vantaggi offerti è per esempio che da uno stessa pagina ASP si
possono generare diversi documenti in base al risultato dei comandi ivi contenuti. Tali
79
vedi [6], [7], [8], [9] della bibliografia
55
Architetture e linguaggi
comandi sono codificati mediante un linguaggio di scripting, in genere VBSCRIPT
oppure JSCRIPT. Il codice viene limitato dai tag <% e %>.
Le istruzioni contenute nelle pagine ASP possono produrre vari effetti, che vanno dalla
formattazione automatica dei contenuti all’accesso ad informazioni remote quali i
database.
In questo modo, la richiesta di un utente di visualizzare il contenuto di una tabella si
traduce in una richiesta da parte di ASP verso il database di accedere alla tabella in
questione , rappresentarla internamente con un oggetto ADO 80 e tradurre il contenuto in
una tabella HTML. La possibilità di interagire con database ODBC rende ASP ideale per
lo sviluppo di applicazioni distribuite, indipendentemente dal database utilizzato.
5.3.1.1Global.asa
(*)81
Uno dei maggiori problemi che gli sviluppatori internet si trovano ad affrontare,
indipendentemente dalla tecnologia utilizzata, è la difficoltà di creare una vera
applicazione su Internet. L'interazione fra un browser e un server WEB è una
transazione che non ha alcuna informazione di stato, con cui il server trasmette una
pagina WEB al client e poi dimentica perfino la sua esistenza. Quando, in un secondo
tempo, il client richiede un'altra pagina Web, il server non ricorda la prima richiesta. In
una normale applicazione questo non avviene in quanto tra l'avvio del programma e la
sua chiusura i dati possono essere facilmente memorizzati in una variabile. Per un sito
internet questo schema non è valido. Come determinare l'avvio e la chiusura di una
applicazione? Se l'utente entra in un sito e visualizza una pagina si può dire che
l'applicazione è lanciata? ma cosa avviene se l'utente abbandona il sito e poi vi torna
dopo 5 minuti?
Questo problema della definizione dell'avvio e della chiusura di un'applicazione influisce
sulla possibilità di gestire correttamente le variabili e il flusso di lavoro. Una soluzione a
questo problema in parte è la definizione del protocollo HT TP1.1 comunque ancora non
pienamente supportato. Ancora migliore è la soluzione offerta da Microsoft per le sue
Active Server Pages e che hanno contribuito in buona parte alla scelta di tale tecnologia
piuttosto che PHP o JSP per la realizzazione di Virtualmarket.
80
Componente ActiveX responsabile della gestione delle connessioni al db all’interno di uno script ASP.
81
Vedi [9] della bibliografia
56
Architetture e linguaggi
La soluzione Microsoft è la presenza di un file denominato GLOBAL.ASA, che viene
usato per determinare l'avvio e la chiusura di un'applicazione e della sessione di ogni
singolo utente. GLOBAL.ASA rileva 4 eventi chiavi nel sito:
Application_OnStart, Application_OnEnd, Session_OnStart e Session_OnEnd.
Importanti sono i concetti di applicazione e sessione. Applicazione può fare riferimento
all'insieme di browser che accedono a tutte le pagine della stessa directory. Sessione si
riferisce a un singolo browser che accede a quelle pagine. Una sessione di un singolo
browser esiste finché l'utente continua a chiedere pagine. Se esiste un valore di 20
minuti per il Time-out e se l'utente non richiede pagine per più di 20 minuti la sessione
termina e viene generato l'evento Session_OnEnd. Quando tutte le sessioni utente
nella directory virtuale sono terminate viene generato l'evento Application_OnEnd.
Il file GLOBAL.ASA è fondamentale per una corretta nonché chiara gestione delle
sessioni web che avvengono sul sito dove esso è posto.
In realtà è una delle caratteristiche più utili, in quanto ci permette di intercettare alcuni
eventi. Gli eventi, essendo precisi, sono l'inizio e la chiusura dell'applicazione web e
della singola sessione.
Ecco un tipico esempio di global.asa:
<SCRIPT Language="VBScript" RUNAT="server">
Sub Application_onStart()
' qui la routine di partenza
' es: variabili con stringhe di connessione
' a data base, etc...
'Viene generato quando la prima pagina dell'applicazione
'viene eseguita per la prima volta da un utente
End sub
Sub Application_onEnd()
' in genere inutilizzato
' può essere utile però per monitorare i restart
' del server (tramite invio di e-mail o SMS)
'Viene generato alla chiusura del server
End sub
Sub Session_onStart()
' inizio della sessione
57
Architetture e linguaggi
' in genere viene utilizzata per contare
' le sessioni attive nell'applicazione
'Viene generato la prima volta che un utente esegue una pagina nell'applicazione
End sub
Sub Session_onEnd()
' fine della sessione (dopo il timeout)
' serve per liberare eventuali riferimenti
' creati per oggetti con scope session
'Viene generato quando l'utente chiude la session (session.abort) oppure quando abbandona l'applicazione (in 'questo caso dopo il
‘time-out impostato nel server)
End sub
</SCRIPT>
il GLOBAL.ASA contiene dei tag <SCRIPT> che racchiudono le sezioni script. Questi
tag contengono uno speciale attributo, denominato RUNAT=Server che specifica che il
VBScript deve essere eseguito sul server e non sul client.
Microsoft definisce applicazione Internet: una directory virtuale e tutte le sue pagine. Se
un utente richiede una pagina Web da una directory ‘mall2000’ viene avviata
l'applicazione mall2000 e viene eseguito il GLOBAL.ASA contenuto in tale directory. In
base a questa definizione, un'applicazione può essere usata da più browser
contemporaneamente. l'evento Application_OnStart viene generato una sola volta
quando il primo utente richiede la prima pagina. In seguito, quando gli altri utenti
richiedono pagine della stessa directory viene generato solo l'evento Session_OnStart.
5.3.1.2Oggetti ASP più importanti
Oggetto Application
L'oggetto Application consente di creare variabili di applicazione, disponibili per tutti gli
utenti di un'applicazione. Nel caso di Virtualmarket un esempio d’uso è mantenere in
una variabile application, denominata shopID, l'indice del record della tabella Shop
relativa al negozio corrente attraverso la sintassi:
mioindice=Application("shopID")
58
Architetture e linguaggi
Poiché la variabile è disponibile per più utenti contemporaneamente è necessario tener
presente la simultaneità: non si può essere certi che due utenti non tenteranno di
impostare la variabile su due valori diversi lo stesso momento.
Per far fronte a questa situazione esistono due metodi: LOCK e UNLOCK. Il metodo
Lock blocca tutto l'oggetto Application non solo la variabile che si sta modificando, per
cui è necessario sbloccarlo subito dopo aver modificato il valore di una variabile:
Application.Lock
Application("shopID")=3
Application.Unlock
I dati presenti nelle variabili d'applicazione vengono distrutti nel momento in cui viene
generato l'evento applicationOnEnd.
Oggetto Session
Se si vogliono mantenere informazioni riguardanti il singolo utente o la singola sessione
allora si deve far uso delle variabili di tipo Session.
Le variabili di tipo Session sono riservate a un singolo utente ed esistono per tutta la
durata di una sessione. Quindi dopo venti minuti, se tale è il valore di TimeOut
impostato nel server web, tali variabili vengono deallocate. E' possibile creare variabili
di sessione in qualunque pagina Web o in file GLOBAL.ASA e vi si può accedere da
qualunque pagina mediante la sintassi:
miavar=Session("nome_sess_var")
Un esempio di uso in VirtualMarket delle variabili di sessione è quello di mantenere
l'indice, denominato pclogid, del record nella tabella DM_PcLOG che si riferisce ai dati
di navigazione dell'utente corrente (referrer, querystring, data_iniziosessione, ecc...).
Un'alternativa alle variabili di sessione potrebbe essere quella di mettere nella
querystring di ogni link un riferimento a tale ID ma è possibile che un utente malizioso
possa modificare tale valore. Per evitare questo eventualità, viene usata, appunto, una
variabile di sessione il cui valore, sconosciuto all’utente, non può essere visualizzato
all’interno del codice HTML della pagina client generata e quindi non può essere
modificato. Inoltre in questo modo, usando cioè le variabili di sessione, i link sono più
59
Architetture e linguaggi
brevi e quindi più puliti, memorizzando in essi solo le informazioni necessarie come il
codice del prodotto o della categoria di cui si stanno visualizzando i dettagli.
Un appunto all'uso delle variabili session e dell'evento Session_OnStart è relativo alla
abilitazione dei cookies da parte del browser dell'utente. Se i cookies sono disabilitati
allora l'evento Session_OnStart viene eseguito ad ogni richiesta di pagina da parte
dell'utente e anche le vecchie variabili di sessione vengono perse. Questo perché le
variabili di sessione vengono memorizzate per ogni utente sul server ma indicizzati
tramite un Global Unique Identifier (GUID) che invece il server Web memorizza sul pc di
ogni utente tramite cookie di sessione. Dato che i cookie sono disabilitati ad ogni
richiesta il server genera un nuovo GUID e quindi le vecchie variabili non saranno più
raggiungibili
a meno che non vengano inizializzate solo nel metodo Session_OnStart. In questo
modo allora verranno reinizializzate in modo corretto se non si sono verificati nel
frattempo side effect.
Oggetto Response
L'oggetto Response gestisce i contenuti restituiti da ASP a un browser:
response.write("ciao mondo")
oppure
=("ciao mondo")
equivale a scrivere ‘ ciao mondo ’ sul browser.
In realtà l'oggetto Response è capace anche di scrivere nei cookies
response.cookies("nomecookie")(chiave) = value
E di redirezionare automaticamente l'utente ad un'altra pagina oppure di decidere dopo
quanto tempo una pagina viene cancellata dalla Ram (page expiration) e di specificare
il contenuto HTTP della risposta corrente.
Oggetto Request
Lo scambio dei dati tra client e server è fondamentale in un'applicazione WEB. Per
inviare dati al client il server confeziona delle pagine WEB. Viceversa il client invia dati
al server mediante trasmissioni di moduli creati mediante il tag <FORM>.
60
Architetture e linguaggi
Il processo di trasmissione di un modulo è controllato mediante due attributi del tag
FORM e cioè METHOD e ACTION. Il primo determina la modalità di invio dei dati al
server (POST e GET). Con il metodo POST, il browser impacchetta tutti i dati e li invia
al server, con il metodo GET li inserisce come parte integrante della URL nella sezione
querystring. In questo caso c'è un limite nella dimensione in bytes dei dati da mandare
tramite il metodo GET (255 bytes).
L'attributo ACTION specifica la pagina di destinazione dei dati trasmessi.
Da parte del server, questi dati possono essere nuovamente suddivisi in campi e valori
e utilizzati per qualunque scopo. L'oggetto Request analizza proprio i vari campi per
restituirne il valore.
esempio:
<%=Request.Form(email)%>
in questo caso viene visualizzato a video il valore del campo email del form.
L'oggetto Request analizza anche i campi di una querystring tramite la sintassi
<%=Request.querystring("email")%>
L'oggetto Request ha anche altri usi primo fra tutti quello di conoscere il contenuto di un
cookie.
<%=request.cookie("nomecookie")%>.
5.3.1.3ADO
(*)82
I componenti ASP non sono altro che Componenti ActiveX creati con diversi linguaggi:
Visual Basic, Visual C, Visual J++.
Uno dei più importanti è il componente Database ACCESS o ADO. Nella pubblicazione
di database su WEB si utilizza questo componente e gli oggetti in esso contenuti per
leggere e scrivere su fonti dati ODBC. Tramite l'oggetto Connection per esempio si può
aprire una connessione con qualsiasi fonte dati ODBC:
<%
'dichiaro variabile
'Dim objConnection
82
Vedi [6] della bibliografia
61
Architetture e linguaggi
'istanzio l'oggetto connection
Set Objconnection=Server.CreateObject("ADODB.Connection")
'apre la connessione
objConnection.OPEN "Sales","sa",""
%>
una volta aperta la connessione con la fonte dati è possibile usare un oggetto
Recordset per eseguire istruzioni SQL e restituire un insieme di record filtrati mediante
l'istruzione SQL.
<%
'dichiaro variabile
Dim objRecorset
'creo l'oggetto recordset
Set objrecordset=server.createObject("ADODB.recordset")
'esegue la query
objRecordSet.open "select * from miatabella", objconnection
%>
dopo aver recuperato i dati è possibile leggerli mediante i metodi MoveFirst, MoveLast,
MoveNext, MovePrevious.
Un esempio di pagina ASP:
<html>
<body>
ciao mondo. Sono le <%=Now()%>
</body>
</html>
che produce una pagina html con questo codice
<html>
<body>
ciao mondo. Sono le 5:06:14 PM 24/11/2000
</body>
</html>
Il server in questo caso provvede alla sostituzione del testo della funzione racchiusa fra
i simboli <% e %> con il risultato della sua valutazione, nella fattispecie la data e l’ora
correnti.
5.3.2 PHP
(*)83
83
Vedi [16],[21] della bibliografia e [11] dei ‘Principali siti di riferimento ’
62
Architetture e linguaggi
Fornire ad un database un interfaccia WEB sotto UNIX è sempre stato macchinoso:si è
ricorso a script CGI, solitamente scritti in PERL, che si preoccupano di interrogare il
database e fornire il risultato sotto forma di HTML. Tale metodo a volte è sconveniente,
a causa della complessità del PERL, e del fatto che il caricamento dell’interprete in
memoria ogni volta, potrebbe sovraccaricare la macchina. Inoltre chi si occupa
dell’aspetto estetico delle pagine, scritte in HTML, non è generalmente in grado di
modificare uno script in PERL.
Il PHP è un linguaggio di programmazione che può essere usato come filtro sui web
server (in genere APACHE) e che permette di includere i propri script direttamente
all’interno delle pagine html (come ASP). In pratica tutto ciò che sarà racchiuso tra <? e
?> sarà interpretato dal filtro, eseguendo le istruzioni contenute in tali tag. Il PHP è un
vero linguaggio di programmazione che contiene quindi variabili, vettori, funzioni, cicli,
operatori su file e db ecc…
Esempio di pagina PHP 84:
<html>
<body>
ciao mondo. Oggi è il <?=Date("d/m/Y")?>
</body>
</html>
che produce una pagina html con questo codice
<html>
<body>
ciao mondo. Oggi è il 24/11/2000
</body>
</html>
mentre per l’accesso al db (in questo caso Access) e stampa del contenuto di una
tabella ‘products’ si possono usare librerie apposite come ADODB:
(l’uso della libreria ADODB si rende necessario in quanto a differenza di ADO di ASP in PHP i motori
database sono interrogati usando funzioni diverse per ognuno di essi. Quindi se si debbono usare
database differenti si usano delle librerie di funzioni generiche, come in questo caso, che si preoccupano
di richiamare l’API adatta in base al database usato)
84
Gli esempi non sono presi dal progetto sviluppato, (realizzato in ASP) ma adattati per renderli confront abili con
quelli realizzati in ASP.
63
Architetture e linguaggi
<html>
<body>
<?
include('adodb.inc.php');
// carica la libreria ADODB
ADOLoadCode('access');
// carica il codice relativo alla gestione di Database Access
$conn = &ADONewConnection();
// crea una nuova connessione
$conn->PConnect('northwind'); // connessione al db MS-Access, northwind
$recordSet = &$conn->Execute('select * from products');
while (!$recordSet->EOF) {
print $recordSet->fields[0].' '.$recordSet->fields[1].'<BR>';
$recordSet->MoveNext();
}
$recordSet->Close(); // chiusura del recorset
$conn->Close(); // chiusura della connessione
?>
</body>
</html>
Nell’ultima versione di PHP (4) è stata introdotta la possibilità di gestire gli oggetti COM.
questo risulta importante quando si vuol sfruttare la potenza dell’oggetto ADO in
particolare che mette a disposizione tutto sommato una libreria ben fatta.
Esempio d’uso: apertura di una connessione a database access
<?
$dbc = new COM("ADODB.Connection");
$dbc->Provider = "MSDASQL";
$dbc->Open("nwind");
$rs = $dbc->Execute("select * from products");
$i = 0;
$fld0 = $rs->Fields(0);
$fld1 = $rs->Fields(1);
$fld2 = $rs->Fields(2);
while (!$rs->EOF) {
$i += 1;
print "$fld0->value $fld1->value $fld2->value<BR>";
$rs->MoveNext(); /*updates fld0, fld1, fld2 !*/
}
$rs->Close();
?>
apertura di word
<?
$word=new COM("word.application") or die("Cannot start MS Word");
64
Architetture e linguaggi
print "Loaded word version ($word->Version)\n";
$word->visible = 1 ;
$word->Documents->Add();
$word->Selection->Typetext("This is a test");
?>
Tra i pregi del php ci sono la velocità, la robustezza e il fatto che essendo Open
Software, si ha la visibilità sui sorgenti e la possibilità di correggere bug o apportare
migliorie. Tra i difetti debbo menzionare l’accesso al database attraverso API del DBMS
che rende difficili migrazioni per esempio da Oracle a Sybase.
5.3.3 Script CGI
“Un programma CGI è un comune eseguibile o uno script scritto in PERL per esempio,
in grado di prelevare i dati forniti dall’utente (dallo standard input o dalle variabili di
ambiente), elaborarli e stampare sullo standard output il risultato”. 85 Uno script CGI di
solito è invocato mediante una form attraverso il pulsante submit. Nel momento in cui
l’utente preme il submit il browser si connette al web server, mandandogli i dati inseriti e
la richiesta di esecuzione del CGI. Il server esegue il CGI richiesto, passandogli a sua
volta i parametri appena ricevuti. Il web server comunica con lo script attraverso i canali
di input/output. Tutto questo quando viene usato il metodo post. Si può usare anche il
metodo GET all’interno di una form. In questo caso il Server Web comunica i parametri
allo script CGI settando una variabile d’ambiente. Con i programmi CGI e’ possibile
anche l’accesso ai database. Per esempio, per il PERL ci sono delle librerie, chiamate
DBI, che permettono di accedere a archivi relazionali e a creare in maniera abbastanza
semplici dei siti web dinamici e quindi Data-Driven.
5.3.4 JSP e Java Servlet
(*)86
Java deve gran parte del suo iniziale successo alle applet, che insieme ai plugin/activeX
e al Javascript rappresenta la parte client-side del web programming. Tuttavia
sviluppare applicazioni per internet significa nella maggior parte dei casi dover gestire
sia la parte client (interfaccia) che la parte server (accesso a database e gestione
85
Vedi [16] della bibliografia
86
Vedi [18],[20] della bibliografia
65
Architetture e linguaggi
oggetti aziendali). Data la necessità di considerare entrambe le facce della medaglia è
naturale che molti sviluppatori desiderino usare un solo linguaggio per entrambe le
tipologie di applicazioni. Purtroppo chiunque abbia tentato di far server-side
programming con Java ha scoperto che scrivere CGI in Java è molto inefficiente. Oltre
all’overhead considerevole dovuto al bootstrap dell’interprete e al caricamento delle
librerie non usate per ogni richiesta java non consente l’accesso alle variabili
d’ambiente tipiche della programmazione CGI. E allora c’è bisogno di un wrapper 87 in C
che invoca l’interprete Java passando l’ambiente sulla riga di comando. Quindi alle
esigenze di rendere pratica la server side programming in Java la Sun ha introdotto le
servlet.
5.3.4.1Le Servlet
Le servlet usano una serie API che permettono al web server di interagire con
programmi in Java che lo estendono, rendendolo quindi capace di fornire nuovi servizi.
Sia servlet che applet girano in una virtual machine, la prima gira nel web server la
seconda nel browser.
Una servlet web gestisce le richieste inviate tramite URL oppure processa l’output
proveniente da moduli. Le servlet quindi svolgono la stessa funzione delle CGI, ma
rispetto a quest’ultime presentano numerosi vantaggi. Innanzitutto viene risolto il
problema dell’inefficienza. Una servlet viene caricata all’avvio del web server e rimane
in memoria a servire le richieste. L’overhead per la gestione di una richiesta è pari alla
chiamata di un metodo, non al bootstrap dell’interprete, quindi di gran lunga inferiore.
Una conseguenza di questa architettura è che le servlet possono mantenere uno stato
e quindi ricordare varie info come per esempio il numero di volte in cui è stata chiamata.
Le servlet possono comunicare fra loro e possono essere concatenate (una richiesta
può essere gestita da una pipeline di servlet). Essendo scritte in java si accede alle sue
numerose qualità come:
87
•
l’accesso al db usando un’ interfaccia standard (jdbc)
•
il multithreading
•
la security,
•
le api per il semplice uso dei protocolli di rete,
Wrapper: porzione di codice che racchiude un’altra porzione di codice scritto in un altro linguaggio e di solito ne
invoca solo l’esecuzione.
66
Architetture e linguaggi
•
ma soprattutto il fatto che le applicazioni scritte sono riutilizzabili senza modifiche
su qualunque piattaforma che disponga di java, un web server conforme al JDBC
e un database dotato di driver JDBC.
Indipendentemente dalla tecnologia che si utilizza per la creazione di contenuti
dinamici, si ha spesso il problema di far convivere coloro che si occupano della parte
logica da coloro che si occupano della pura visualizzazione. Per produrre contenuti
dinamici in Java, il primo approccio è stato quello di inserire codice HTML all’interno del
codice Java delle servlet. Questo porta alla scomoda conseguenza che se si ha la
necessità di modificare la parte HTML di un contenuto, bisogna necessariamente
modificare il codice Java e ricompilare il tutto. Inoltre coloro che programmano in Java
solitamente non sono gli stessi che programmano in HTML, soprattutto in un ambiente
di alta specializzazione. Ci si è accorti quindi della necessità di un meccanismo che
permetta di dividere il più possibile la produzione dei dati da visualizzare dal modo con
cui questi sono visualizzati.
Una Servlet è una classe che implementa l’interfaccia javax.servlet.Servlet che descrive
alcuni metodi, il più importante dei quali è il metodo service() che ha la seguente firma:
public void service(ServletRequest request, ServletResponse response) throws IOException,ServletException;
Il metodo service() contiene le logica che descrive come devono essere elaborate le
informazioni relative ad una richiesta incapsulate nell’oggetto request, per generare una
risposta utilizzando gli strumenti offerti dall’oggetto response.
Esempio di codice Java contenente una servlet 88:
import
javax.servlet.*;
import
javax.servlet.http.*;
public class Saluto extends HttpServlet {
private static final String NOME="NOME";
/**
* Contiene la logica che a partire dalle informazioni contenute nell'oggetto
* request produce una risposta usando gli strumenti offerti dall'oggetto
88
Questa porzione di codice non deriva dal progetto ma è stata inserita per facilitare il confronto con gli altri
linguaggi.
67
Architetture e linguaggi
* response
*/
public void service(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException,ServletException{
// Leggiamo il valore del parametro NOME
String nome=request.getParameter(NOME);
// Inizializziamo la Stringa di output
String output="NESSUNO";
// Se viene passato il parametro lo assegnamo come stringa di output
if (nome!=null)
output=nome;
// Creiamo l'output
// Impostiamo il Content-type
response.setContentType("text/html");
// Prendiamo lo stream di uscita
ServletOutputStream out= response.getOutputStream();
// Mandiamo l'output in formato html
out.println("<HTML>");
out.println("
<HEAD><TITLE>Saluto</TITLE></HEAD>");
out.println("
<BODY>");
out.println("
out.println("
<H1> Hello "+output+" </H1>");
</BODY>");
out.println("</HTML>");
}// fine
}// fine servlet
tale listato mostra una semplice servlet che legge il valore del parametro NOME e
produce un contenuto HTML dinamico con il classico ‘HELLO’. Nel caso in cui non si
fornisca un valore al parametro verrà salutato ‘NESSUNO’.
Tale servlet è molto semplice ma ha il difetto di contenere codice HTML. Se dovessimo
riutilizzare la servlet in pagine html diverse dovremmo modificare il codice e quindi
creare classi diverse. Riutilizzare la servlet descritta precedentemente significherebbe
fare un copia e incolla del codice, cambiando la parte html e cambiando nome alla
classe. Questa non è sicuramente la soluzione ottimale.
Una prima soluzione in versione Java a questo problema viene data dalle JSP.
5.3.4.2Jsp
La servlet precedente può essere simulato in JSP in questo modo:
<HTML>
<HEAD><TITLE>Saluto</TITLE></HEAD>
<BODY>
<%String chi = request.getParameter("NOME");
if (chi==null) chi="NESSUNO";
68
Architetture e linguaggi
%>
<H1> Hello <%= chi%> </H1>
</BODY>
</HTML>
tale codice descrive una pagina jsp (Java Server Pages) che ci permette di ottenere lo
stesso risultato della precedente servlet. In questo caso abbiamo, però, il vantaggio che
le eventuali modifiche nella parte HTML non implicano modifiche nella parte java con
conseguente compilazione del codice, o almeno non saremo noi a farla come descritto
nel prossimo paragrafo. Notiamo come con le pagine JSP si possa presentare una
situazione all’opposto di quello che accade nel precedente Servlet, cioè abbiamo codice
java all’interno di codice html.
Page Traslation e Compilation
Alla luce di quanto visto nel paragrafo precedente ci si potrebbe chiedere qual è la reale
differenza tra una servlet ed una pagina JSP. In realtà il risultato è lo stesso: quello che
viene eseguito ad ogni richiesta è un metodo service() di una servlet. La differenza è nel
modo con cui questa servlet viene creata. Nel primo caso programmiamo la servlet
direttamente, mentre nel secondo caso esiste un JspContainer (installato nel
WebServer) che esegue le operazioni di page translation e page compilation che
portano alla realizzazione, in modo automatico, delle servlet che eseguono il servizio
descritto dalle pagine JSP.
Jsp e JavaBean:
L’esempio di pagina jsp realizzato non ci permette ancora di risolvere il problema
relativo alla divisione tra codice java e codice html. Finora abbiamo semplicemente
portato il codice java all’interno del codice html. Fortunatamente le pagine JSP ci
permettono di accedere, con opportuni tag (e quindi non opportune istruzioni Java) ai
servizi offerti da alcuni componenti. È possibile accedere a questi servizi senza vederne
l’implementazione e quindi il codice Java che ci sta dietro.
package com.carli.jsp;
public class SalutoBean {
private
String
chi;
public SalutoBean(){}
public void setChi(String chi){
this.chi=chi;
}// fine
69
Architetture e linguaggi
public String getChi(){
return chi;
}// fine
public String getSaluto(){
return "Hello "+((chi==null)?"NESSUNO":chi);
}// fine
}// fine classe
Supponiamo di voler delegare il saluto della pagina precedente ad un B ean89 che si
chiama SalutaBean. Esso è molto semplice in quando dispone di una proprietà che si
chiama chi e permette di accedere, attraverso il metodo getSaluto(), al saluto da
visualizzare. La logica di creazione del saluto è incapsulata nel Bean. Notiamo anche
che la scrittura dei metodi di accesso alle proprietà seguono le regole descritte nelle
specifiche JavaBean e che prevedono la definizione dei metodi get/set associati alle
varie proprietà. Il seguente listato fornisce un piccolo esempio di utilizzo di un Bean
all’interno di una pagina JSP.
<HTML>
<HEAD>
<TITLE>Prova di una pagina JSP</TITLE>
</HEAD>
<BODY>
<jsp:useBean id="saluta" class="com.carli.jsp.SalutoBean" />
<jsp:setProperty name="saluta" property="chi" param="NOME"/>
<%= saluta.getSaluto()%>
</BODY>
</HTML>
A parte alcune considerazioni relative ai tag da utilizzare è bene sottolineare il fatto che
nella pagina jsp non sia presente codice java ma semplicemente l’utilizzo di alcuni tag
che permettono di accedere a servizi esposti da Bean che ne nascondono
l’implementazione.
Il mio esempio è volutamente semplice ma nulla vieta di creare dei Bean che
permettono di accedere, ad esempio, ad informazioni su un db, che si integrano con
sistemi legacy90 attraverso le librerie RMI o CORBA ecc..
89
bean: modulo java precompilato, i cui metodi e proprietà sono richiamabili all’interno di un file java dopo averne
importato il contenuto
70
Architetture e linguaggi
Aspetti negativi di JSP
•
Java e quindi le JSP mettono a disposizione degli strumenti abbastanza poveri
per lo sviluppo RAD di applicazioni.
•
L’esecuzione delle pagine JSP rispetto alla tecnologia ASP o addirittura alle
pagine PHP è molto più lenta.
•
JSP rende troppo facile mescolare i dettagli di presentazione con le regole di
business (business logic) a meno di usare i javabean. Comunque tale problema
è comune anche a ASP e PHP.
5.3.5 Confronto fra i vari linguaggi
5.3.5.1ASP e CGI
Quali vantaggi offre la tecnologia ASP rispetto alle applicazioni CGI? Un’applicazione
CGI non è altro che un programma scritto in un qualsiasi linguaggio di programmazione
che segue alcune regole per l’interazione con il web server ma è altamente inefficiente.
Innanzitutto c’è da considerare il fatto che il server ad ogni richiesta di esecuzione di
un’applicazione CGI avvia un nuovo processo causando una caduta nelle prestazione
del server. Inoltre la creazione di una nuova istanza di un’applicazione CGI impedisce la
condivisione di risorse e dati se non tramite l’uso di file condivisi o database con
conseguente perdita di prestazioni. Inoltre, poiché le applicazioni CGI sono esterne al
server WEB non vi è possibilità di interagire con esso in modo semplice.
ASP da parte sua non richiede la creazione di un nuovo processo e quindi rende
possibile anche la condivisione di informazioni a livello GLOBALE e a livello di singola
SESSIONE di utente mediante le variabili built-in Session e Application superando
l’assenza di stato tipica del protocollo HTTP.
5.3.5.2ASP e JSP
Gli aspetti da considerare sono molti anche se il principale è dato dal Web Server e
dalla piattaforma utilizzata. Le JSP sono realizzate in Java per cui portabili sotto ogni
piattaforma mentre le ASP sono integrate in un ambiente Mic rosoft (anche se c’è stato
90
Sistemi legacy: sistemi preesistenti strutturati in maniera magari non conforme agli standard attuali
71
Architetture e linguaggi
un tentativo di creare pagine ASP sotto Unix). Sun non ha rilasciato un prodotto ma ha
pubblicato delle specifiche (insieme di interfacce) che diversi produttori di software
possono implementare in modo differente. Le ASP sono in vece legate ad Internet
Information Server 91. Abbiamo visto che all’interno di una pagina JSP si possono
utilizzare i servizi offerti dai JavaBean. Anche le ASP permettono l’accesso a
componenti (ActiveX) la cui implementazione è però legata alla piattaform a Microsoft.
Possiamo quindi dire che le ASP possono essere utili nel caso in cui si utilizzi una
architettura completamente Microsoft. Per quello che riguarda le prestazioni possiamo
dire che le JSP hanno il vantaggio di essere compilate solamente al primo utilizzo
mentre le pagine ASP sono interpretate.
5.3.5.3ASP e PHP
ASP è costruito su un’architettura basata sul modello COM. Quando viene usato
Vbscript, in realtà si stanno usando oggetti del modello COM (le classi Server, Request,
Response, ecc… ne fanno parte). Quando si accede a database si usano oggetti COM
(classi delle librerie ADO: Connection, Recordset), Quando si accede ad un file, tramite
ASP, si sta usando un oggetto COM (classe FileObject). Tutti questi utilizzi di oggetti
COM rendono ASP più lento rispetto a PHP in quanto i vari oggetti debbono
comunicare attraverso l’infrastruttura di rete. Nei moduli PHP ogni cosa gira nello spazio
di memoria del motore PHP. Questo rende il codice più veloce in quanto non c’è
overhead di comunicazione tra oggetti differenti in processi differenti.
Questo però è anche uno svantaggio di PHP in quanto la struttura a componenti di ASP
lo rende più flessibile e scalabile e quindi gode di tutti i vantaggi della programmazione
distribuita. Non solo. Il fatto che giri tutto nello stesso spazio di memoria rende PHP più
vulnerabile, in quanto basta che un solo modulo interrompa improvvisamente
l’esecuzione che tutti gli altri possono saltare rendendo di fatto l’applicazione inusabile.
Il linguaggio usato per PHP ha una sintassi più vicina a Java e a C++ e quindi più facile
da imparare e più produttivo. Inoltre PHP ha un buon supporto per la programmazione
modulare in classi mentre in ASP (VBscript) il supporto per le classi è ancora immaturo.
ASP supporta l’inclusione dinamica di file ma non di tipo condizionale. Quello che
avviene cioè è che se ho uno script header.asp incluso in 20 files tale inclusione
avverrà sempre e comunque nella memoria del server in quanto l’inclusione avviene
91
IIS: server web della microsoft
72
Architetture e linguaggi
prima dell’interpretazione dello script ASP. In PHP, viceversa, esiste l’inclusione
condizionale e quindi è possibile includere solo il file che server quando realmente
serve.
Un punto a favore di ASP nei confronti di PHP è la gestione delle variabili Application
(variabili che hanno una vita e visibilità per tutta la durata del server) che in PHP non
hanno un equivalente.
E’ possibile testare script PHP sotto Linux, Solaris e Windows. D’altra parte ASP è
tecnologia proprietaria Microsoft. Gira solo su server Microsoft (e con molte limitazioni
su qualche altro server) e molti componenti sono a pagamento e di questi spesso non è
disponibile il codice e di conseguenza non è possibile risalire ad eventuali bugs e/o
back-door che possono essere presenti, in modo più o meno voluto, in tali componenti.
E’ anche vero però che disporre di componenti compilati permette una maggiore
sicurezza (se compilati in ‘casa’) in quanto in essi si può nascondere tutta la business
logic eseguendo il tutto anche a maggiore velocità.
5.3.6 Programmazione a componenti
(*)92
Rispetto ad un’architettura tradizionale client/server, nell’architettura 3 -tier, è presente
un livello intermedio che può essere identificato dal middleware93. Gli oggetti business,
cioè entità aziendali quali fatture, ordini e clienti, risiedono nel middleware del sistema
informativo. Il client accede agli oggetti business i quali sono gli unici autorizzati a
dialogare con la base dati.
I moduli client diventano quindi più leggeri, non hanno più l’onere di dialogare
direttamente con il server del database ma usano solo le interfacce esposte dagli
oggetti presenti nello strato intermedio.
I vantaggi di questa architettura sono che i moduli client sono indipendenti dal database
anzi ne ignorano la presenza e che, per il client, esiste solo il middleware.
Grazie a tecnologie come DCOM e CORBA è possibile distribuire gli oggetti,
implementarli con un linguaggio (C++ ad esempio) e richiamarli indifferentemente da
client scritti in java, C, C++, ecc…; i client possono essere, come nel mio caso, pagine
web attive ASP (DCOM), applet java (CORBA, DCOM) o componenti ActiveX (DCOM).
92
Vedi [6], [8], [17] della bibliografia e [4] della sezione ‘Principali siti di riferimento ’
93
Middleware: collezione di componenti interposti tra lo strato applicativo dell’interfaccia e i database
73
Architetture e linguaggi
5.3.6.1Oggetti aziendali
Un oggetto aziendale non è altro che un’entità che ruota intorno ad un’attività ben
definita all’interno di un sistema informativo. Per un’azienda, esempi di business object
possono essere: il cliente, la fattura, l’ordine o combinazioni di essi (effettuate
attraverso relazioni nel linguaggio dei db). I client richiedono, si connettono e usano
oggetti aziendali i quali incapsulano i dati presenti nel server di database. In sistemi così
concepiti raramente vedremo nei client espliciti riferimenti ad istruzioni SQL o ad oggetti
per accesso ai dati (tipo DAO, RDO, ADO, JDBC). Tutta la logica di accesso ai dati
risiederà nel middleware, cioè negli oggetti aziendali e quindi nei server DCOM o
CORBA.
5.3.6.2COM e DCOM
Il Component Object Model è una recente tecnologia Microsoft il cui scopo principale è
quello di consentire lo sviluppo di componenti software riutilizzabili a favore
dell’interoperabilità delle applicazioni magari scritte con linguaggi diversi.
Il Component Object Model è la base su cui poggiano tutte le tecnologie OLE e
ACTIVEX. COM definisce uno standard binario, indipendente da qualsiasi compilatore o
linguaggio di programmazione. Definire uno standard binario significa imporre delle
regole che governano non tanto il modo con cui il software viene scritto, quanto il modo
con cui il software viene compilato.
Un server COM si differenzia dalle normali applicazioni per il fatto che, dovendo
interagire con l’esterno, deve rendere note a priori le proprie funzionalità e come queste
debbano essere richiamate.
Un componente non è altro che un oggetto caratterizzato da dati ed interfacce. I dati
sono informazioni proprie dell’oggetto. Le interfacce sono funzioni che manipolano e
operano sui dati. Il concetto è molto simile alla definizione di oggetto nella OOP 94, nel
caso di COM però c’è distinzione tra interfaccia ed implementazione dell’interfaccia. Un’
interfaccia COM è un insieme di metodi che una classe COM può implementare ma non
rappresenta necessariamente tutti i metodi della classe.
94
OOP: Object Oriented Programming
74
Architetture e linguaggi
Un’ interfaccia è quindi una lista di funzioni, o più precisamente, una lista di puntatori a
funzione. Un oggetto COM è costituito semplicemente da una o più di queste liste di
puntatori, oltre ovviamente che dall’implementazione di queste funzioni.
Quindi un programma che voglia usare un oggetto COM non deve fare altro che
ottenere da quest’ultimo un puntatore ad una delle interfacce implementate e quindi
richiamare una delle funzioni accessibili da quell’interfaccia.
Come è possibile richiedere un puntatore ad un’interfaccia disponibile all’interno di un
altro programma? Ogni programma che vuole fornire delle funzionalità ad altri
programmi deve registrarsi. L’eseguibile in questo modo comunica al sistema che è in
grado di restituire, a richiesta, dei puntatori a queste interfacce. Ma come fa il
programma a conoscere quali siano queste interfacce? Semplice: lo chiede all’oggetto
stesso. Ogni oggetto infatti è obbligato ad implementare le funzioni definite da una
particolare interfaccia, IUnknown95. Una di queste funzioni è QueryInterface e permette
di richiedere all’oggetto se supporta ogni altra interfaccia ritornando così un puntatore
all’interfaccia corrispondente.
COM è indipendente dal linguaggio di programmazione, si possono creare server COM
in C++ e usarli contemporaneamente in client Java, Visual Basic, Visual C++, Delphi
ecc…
Il modo classico per scrivere un server COM è quello di definire gli oggetti e le
interfacce mediante un linguaggio indipendente dai linguaggi di programmazione: l’IDL.
Lo standard COM consente di modularizzare le applicazioni in componenti server
riutilizzabili e client che accedono a tali componenti. Ciò che è richiesto è che server e
client risiedano sulla stessa macchina. DCOM non ha questa limitazione: applicazioni
client possono attivare server DCOM che girano su macchine remote.
DCOM quindi eredita tutti i vantaggi delle soluzioni COM:
95
•
riutilizzo dei componenti,
•
modularizzazione del software,
•
approccio object oriented,
•
interfacce uniformi indipendenti dall’implementazione
IUnknow: nome di un’interfaccia di ogni classe COM che elenca tutte le funzioni implementabili.
75
Architetture e linguaggi
•
e inoltre può risultare più performante.
Infatti si potrebbe pensare di far girare i server più pesanti su macchine più potenti e di
conseguenza rendere più snelle le applicazioni client.
5.3.6.3CORBA
COM è legata al mondo Microsoft ed è ormai standard DE-FACTO. Da qualche tempo
esiste un’alternativa, in via di standardizzazione, CORBA 96, che appunto gestisce le
richieste provenienti da oggetti distribuiti su uno o più computer.
La
definizione
di
oggetto
CORBA
rientra
completamente
in
quella
della
programmazione ad oggetti: un oggetto CORBA è un’entità che supporta il
polimorfismo, l’ereditarietà e l’incapsulamento.
Anche in questo caso i vari oggetti possono essere scritti in uno qualunque dei
linguaggi previsti dallo standard (C, COBOL, C++, JAVA, SMALLTALK, ADA, DELPHI)
e possono risiedere su computer con sistemi operativi diversi. Sarà il CORBA ad
occuparsi dei dettagli come rintracciare l’oggetto di cui si sono richiesti i servizi o il byte
ordering (trasformando quando necessario la rappresentazione da big endian a little
endian e viceversa).
Un oggetto CORBA viene definito utilizzando un linguaggio specifico: IDL.
L’IDL viene usato per descrivere, tramite le interfacce, i servizi che gli oggetti server
offrono ai potenziali client. Una volta compilata l’interfaccia si può passare
all’implementazione
della
stessa
usando
uno
qualsiasi
dei
linguaggi
di
programmazione.
Oggetti diversi che si trovano sulla rete possono comunicare tra loro tramite l’ORB97
che è come un canale di trasmissione dei messaggi che i vari oggetti si scambiano.
Le funzionalità dell’ORB sono suddivise tra il client ed il server, sotto forma di librerie
che vengono aggiunte sia all’uno che all’altro: per far si che entrambi possano
interfacciarsi a queste librerie, il compilatore IDL genera due file, stub e skeleton: il
primo viene linkato al client e il secondo al server.
Lo Stub
96
CORBA: Common Object Request Broker Architecture.
97
ORB: Object Request Broker.
76
Architetture e linguaggi
Lo stub contiene una rappresentazione locale (chiamata oggetto proxy) dell’oggetto
server remoto: il client allora, anziché invocare i metodi dell’oggetto remoto, invoca
quelli dell’oggetto proxy che a sua volta comunicherà con l’oggetto remoto. Tutto ciò è
possibile in quanto il proxy è un oggetto che implementa l’interfaccia del server remoto
anche se i suoi metodi contengono solo una chiamata ad un metodo corrispondente
dello skeleton.
Lo Skeleton
Lo skeleton, da parte sua, compie un lavoro complementare a quello compiuto dal
proxy, perché, dopo aver ricevuto una chiamata da quest’ultimo, si preo ccupa di
invocare localmente il metodo del server richiesto dal client. Una volta che l’esecuzione
del metodo è completata, lo skeleton comunica al proxy l’eventuale risultato restituito
dal metodo: il proxy, a questo punto, presenterà al client il risultato ricevuto dallo
skeleton.
L’uso dell’ORB è giustificato rispetto alla presenza della tecnologia RPC 98 in quanto
sebbene entrambi permettono di invocare dei metodi remoti, ORB segue i principi della
programmazione ad oggetti mentre RPC quelli della programmazione procedurale.
5.4 UML(Unified Modeling Language)
(*)99
Lo Unified Modeling Language (UML) è un consistente linguaggio di specifiche che
permette la visualizzazione, costruzione e documentazione di sistemi software.
Attraverso la modellazione visuale, UML "risponde" ai seguenti requisiti:
•
Definizione formale di un comune metamodello per il progetto e l'analisi degli
oggetti. Tale metamodello include modelli statici, comportamentali, di uso e di
architettura.
•
Specifiche per meccanismi IDL per modellare lo scambio tra gli strumenti OA&D
100
.
98
RPC: Remote Procedure Calling.
99
Vedi [10],[12] della bibliografia e [2] della sezione ‘Principali siti di riferimento ’
100
OA&D: Object and Analysis Design.
77
Architetture e linguaggi
•
Una notazione per rappresentare modelli OA&D.
L'astrazione che permette di focalizzare i dettagli rilevanti e di ignorare gli altri è una
chiave di comprensione e comunicazione.
Questo perché:
1. I sistemi che si devono realizzare sono spesso complessi e non affrontabili da un
singolo punto di vista; cioè con un unico modello.
2. Tutti i modelli devono essere espressi a differenti livelli di astrazione.
In termini di viste di un modello l'UML definisce i seguenti diagrammi:
•
use case diagram: Rappresenta le modalità di utilizzo del sistema da parte degli
attori (persone, altri sistemi, ecc.) che interagiscono con esso; descrive
l’interazione tra attori e sistema ma non la logica interna e’ facilmente
comprensibile anche per i non “addetti ai lavori”; può essere definito a livelli di
astrazione diversi.
•
class diagram: rappresentano le classi che compongono il sistema ed i relativi
attributi ed operazioni mediante le associazioni specifica i vincoli tra le classi.
•
behavior diagram (descrivono il comportamento)
o statechart diagram: specificano il ciclo di vita degli oggetti; quando un
oggetto si trova in un determinato stato può essere coinvolto da
determinati eventi; gli oggetti coinvolti nell’interazione cambieranno i loro
stati interni secondo i messaggi che ad essi arriveranno dalle altre
componenti del sistema;
o activity diagram: servono a rappresentare la logica interna di un
processo; permettono di rappresentare processi paralleli e la loro
sincronizzazione.
•
interaction diagram (descrivono l’interazione fra le istanze delle varie classi)
o sequence diagram: specificano la sequenza dei messaggi che gli oggetti
si scambiano; evidenziano gli scenari che si possono creare per ogni
interazione; l’enfasi è sulla successione dei messaggi scambiati.
o collaboration diagram: specificano gli oggetti che collaborano in un dato
scenario; evidenziano i legami tra gli oggetti; l’enfasi è sugli oggetti e sul
loro modo di collaborare.
•
implementation diagram (descrivono il sistema finale)
78
Architetture e linguaggi
o component diagram: servono per mostrare la struttura del codice;
servono per evidenziare le dipendenze tra le varie componenti software
implementate;
al
loro
interno
un
modulo
software
può
essere
rappresentato come un componente stereotipato;
o deployment diagram: servono per mostrare la struttura del sistema a
tempo di esecuzione.
Di fronte all'incremento della complessità dei sistemi l'UML è lo "strumento" ben definito
e ormai da tutti accettato come risposta alle esigenze di modellazione, è, infatti, il
linguaggio visuale di modellazione più utilizzato per la costruzione di sistemi object oriented e component-based e qui viene usato come linguaggio di modellazione di
applicazioni web.
5.4.1 Uml e la modellazione di una piattaforma di CE
(*)101
Un sito di commercio elettronico è composto da un’infrastruttura server, da una parte
logica e dall’interfaccia utente. L’infrastruttura server: database server, server web,
componenti e la loro collocazione fisica
possono essere modellati attraverso dei
diagrammi UML ma tale modellazione non apporta reali benefici se non nella
comprensione di come e dove tali server debbano essere dislocati.
Ha molta importanza la descrizione del database inteso come schema.
Un sito di e-commerce è infatti sia una web application che un database application.
Una definizione di database application può essere quella di una applicazione
dominata da memorizzazione e recupero dei dati verso e da un database. In questo
senso ci viene aiuto l’UML attraverso l’estensione Uml Data Modeler che ci permette di
descrivere il database in tutti i suoi dettagli.
Un sito di e-commerce è anche una web application.
Per definizione, una web application si distingue da un sito web in quanto
un’applicazione modifica il suo stato mediante l’input dell’utente (attraverso l e FORM).
Molto semplicemente un’applicazione WEB si costituisce di un server web, una
connessione di rete e molti browser client. Il server web distribuisce pagine di
informazione formattata ai client che l’ hanno richiesta attraverso un rete.
101
Vedi [2] della sezione ‘Principali siti di riferimento ’
79
Architetture e linguaggi
Figura 14: Relazioni fra pagine server e pagine client
102
In alcune situazioni il contenuto di una pagina non è necessariamente contenuto in un
file. Esso può essere ‘assemblato’ a runtime a partire dalla combinazione di
informazioni contenute nel database e da quelle immesse dall’utente in quel momento e
dalle istruzioni di formattazione contenuto in una pagina chiamata Script.
Figura 15: Relazioni tra i diversi componenti di una web application
103
Per modellare le web application ho usato l’estensione a UML denominata WAE (Web
Application Extension).
102
Vedi [2i] della sezione ‘Principali siti di riferimento ’
103
Vedi [2i] della sezione ‘Principali siti di riferimento ’
80
Architetture e linguaggi
5.4.1.1Uml e la modellazione delle basi dati relazionali
La struttura relazionale del modello entità relazioni si avvicina molto a quella del
modello a oggetti tipico della notazione UML anzi possiamo dire che il modello UML è
solo un modello entità relazioni esteso.
Ci sono 2 aspetti per implementare i modelli UML sui database relazionali. Effettuare:
•
modellazione della struttura (definizione tabelle, chiavi e relazioni),
•
modellazione delle funzionalità (definizione delle query).
Modellazione delle tabelle
Le tabelle di un modello entità relazioni possono essere mappate in una classe del
modello UML dove gli attributi/colonne si trasformano in attributi della classe. I
trigger104/stored procedure associati
ad una tabella possono essere mappati con i
metodi della classe.
Definizione chiavi
Per la definizione delle chiavi primarie ci sono 2 approcci:
•
Existence-based identity: Si ottiene con l’aggiunta di un attributo di tipo
identificativo (di norma è un indice incrementale) che identifica ogni record. Il
vantaggio di questa scelta è che si tratta di un singolo attributo, piccolo e di
dimensione uniforme. Non ha problemi di performance ma non ha un significato
intrinseco rispetto alla tabella a cui si riferisce.
•
Value-based identity: e’ costituita da una combinazione reale di attributi della
tabella. Un primo vantaggio è che ha un significato intrinseco legato agli oggetti
memorizzati nella tabella quindi risulta più facile il debugging e la manutenzione
della tabella stessa. Al contrario ha lo svantaggio di essere difficile da cambiare
in quanto tale cambiamento può consistere in un cambiamento propagato per
tutte le foreign key che la referenziano. Inoltre in caso di chiave co n molti attributi
si possono ottenere tabelle con moltissime foreign key che possono dare
problemi di performance.
E’ buona norma usare il primo tipo di chiave per modelli con più di 30 classi.
104
trigger: porzione di codice SQL memorizzata all’interno del DBMS eseguita automaticamente in seguito ad un
inserimento, aggiornamento o cancellazione.
81
Architetture e linguaggi
La struttura di un modello entità relazioni prevede la prese nza di:
•
chiavi candidate (combinazioni minimale di uno o più attributi che identificano in
modo univoco i record in una tabella),
•
chiavi primarie (una chiave candidata scelta arbitrariamente),
•
chiavi secondarie (referenziano una chiave primaria di un’altra tabella).
Modellazione delle foreign key
Per quanto riguarda le foreign key e quindi le relazioni fra tabelle queste possono
tradursi facilmente in associazioni tra classi.
Modellazione della generalizzazione
Un’altra trasformazione tra modello ER 105 e modello OO106 è quello che riguarda la
generalizzazione.
Il modo più semplice di mappare le due situazioni è quello di associare alla superclasse
e alle sottoclassi una tabella ciascuno nelle quali viene condivisa la chiave primaria
della superclasse [vedi fig. 16].
105
Entità relazioni
106
Object Oriented
82
Architetture e linguaggi
Figura 16: Esempio di modellazione della generalizzazione (vedi 6.7.2)
Modellazione delle funzionalità
Per quanto riguarda il mapping delle funzionalità dobbiamo ricordare che esse
riguardano quali query possono essere create e come possono essere formulate. Come
si può mappare un codice SQL in un modello Uml? Attraverso la navigazione sul
modello stesso. E per descrivere tale navigazione si fa uso del linguaggio OCL. La
notazione dot (punto) ci permette di andare da oggetto a oggetto e da oggetto a
attributo; la notazione [] ci permette di aggiungere filtri su collezioni di oggetti; la
notazione : ci permette di usare la generalizzazione.
Esempio
Espressione OCL
ABasket.product
Significato
Dato un carrello mi restituisce il Select optionarticleid from articleincart
suo contenuto
Abasket.product.quantity
Codice SQL
where cartid= :ABasket;
Dato un carrello mi restituisce la Select quantity from articleincart where
83
Architetture e linguaggi
quantità dei prodotti ivi contenuti
cartid= :Abasket;
Abasket.product[quantity>aQuantity].S Dato un carrello, mi restituisce la Select ShortDescription from articleincart
descrizione breve dei prodotti ivi where cartid= :Abasket and quantity>
hortDescription
contenuti
la
cui
quantità
è :Aquantity
maggiore di aQuantity
Abasket.
Dato un carrello, mi restituisce i Select
product[quantity>aQuantity].Store[Stor
negozi che hanno i prodotti nel optionarticle where cartid= :Abasket and
eid==AStore]
carrello suddetto in una quantità articleincart.quantity>
superiore a d una data.
Storeid
from
articleincart,
:aQuantity
and
optionarticle.storeid= :Astore
Figura 17: Esempio di modellazione delle funzionalità
5.4.1.2Rational Rose e la modellazione dei dati
Il database è il sistema per archiviare e controllare l’accesso ai dati memorizzati. E’ il
più grande elemento che deve supportare il modello dei dati.
Lo stereotipo107 <<Database>>, quando usato per un componente UML, definisce un
database e viene descritto nella Component View essendo di fatto un componente
Fisico.
La descrizione completa del modello di dati che deve essere usata per leggere e
memorizzare i dati è a sua volta memorizzata in uno schema all’interno del database.
Lo schema è l’unità più grande con la quale si può lavorare in un dato momento. Un o
schema di database è rappresentato in un modello UML da un package con lo
stereotipo <<Schema>> e viene posto nella Logical View.
Una tabella è la struttura di modellazione di base per un database relazionale. Questa
rappresenta un insieme di record della stessa struttura, chiamati anche righe della
tabella. Una classe con stereotipo <<Table>> rappresenta una tabella relazionale in
uno schema di database e viene posta all’interno del package Schema prima definito.
Le chiavi sono usate per accedere ad una tabella. La chiave primaria, Primary Key,
identifica univocamente le righe di una tabella. Le chiavi secondarie, Foreign Key,
permettono di accedere ai dati di altre tabelle.
La chiave è rappresentata come un vincolo ed un tagged value della colonna: PK per le
primary key e FK per le foreign key. La foreign key A nella tabella ‘mytable’ viene
107
Uno stereotipo è un ornamento che ci permette di definire un nuovo significato semantico agli oggetti del
modello. Attraverso gli stereotipi si possono disegnare diagrammi contenenti classi con icone personalizzate che le
distinguono meglio da altri tipi di classi permettendo di inserire tipi di attributi e funzioni diversi da quelli standard.
84
Architetture e linguaggi
automaticamente generata nel momento che si crea un’associazione fra la tabella che
contiene la chiave primaria A e la tabella ‘mytable’.
Un indice è una struttura dati fisica che velocizza l’acceso ai dati. Un indice non cambia
la qualità dei dati che vado ad interrogare. Un indice non esiste nella vista logica ma
può essere rappresentato come uno stereotipo <<index>> di fronte all’operazione a cui
fa riferimento un indice.
Una dipendenza di qualsiasi tipo tra tabelle in un modello di dati è chiamata relazione.
Una relazione è data da un’associazione stereotipata e da un insieme di primary key e
foreign key.
Esistono 2 tipi di associazioni:
•
non-identifying che rappresenta una relazione tra 2 tabelle indipendenti in cui la
foreign key della tabella secondaria non contiene tutte le colonne della primary
key
•
identifying che rappresenta una relazione fra 2 tabelle dipendenti dove la tabella
secondaria non può esistere senza la tabella primaria. Tutte le primary key della
primaria diventano primary e foreign key della secondaria.
Possibili mapping:
1. Le associazioni 1:1 si possono mappare con relazioni non identifying.
2. Le associazioni 1:N si mappano con relazioni non identifyi ng.
3. Le associazioni M:N diventano 3 tabelle legate fra loro da relazioni
identifying.
4. Le aggregazioni by reference diventano relazioni non identifying.
5. Le aggregazioni by value diventano relazioni identifying.
6. La generalizzazione diventa relazione identifying.
Le colonne diventano attributi con tagged value.
Un constraint o vincolo è una regola applicata alla struttura del database (colonna o
tabella che sia) e viene definito come uno stereotipo <<constraint>>.
Un trigger è un’attività eseguita dal DBMS come effetto collaterale o al posto di una
modifica di un tabella per assicurarne la consistenza. Lo stereotipo <<Trigger>> su un
operazione rappresenta il trigger di una tabella.
Il vincolo <<valid value>> controlla che il valore di un dato sia conforme a una data
operazione e viene rappresentata da uno stereotipo <<Check>> (saldo>0)
85
Architetture e linguaggi
Il vincolo di unicità assicura che ogni riga contenga un valore differente di una data
colonna e viene rappresentato con lo stereotipo <<Unique>> applicato ad una colonna.
5.4.1.3Uml e la modellazione delle applicazioni Web
Un’applicazione WEB è composta da una business logic che implementa le regole e i
processi del business e da una presentation logic che include: menu, link, immagini e
tutto ciò che contribuisce al look and feel di un’applicazione.
Per quanto riguarda la business logic essa è può essere implementata sia a livello si
server scripting e/o componenti che a livello di client scripting seppur con molte
limitazioni in quanto gli script lato client (Java applets, ActiveX control, Javascript) non
possono accedere alle risorse server (databases, files, componenti middle -tier, ecc…)
ma soltanto agli oggetti definiti da DOM Document Object Model e quindi cookies, form,
link, querystring, immagini ecc… e quindi il loro compito si riduce a validazione di campi
richiesti, date valide ecc…
Per quanto riguarda la presentation logic essa riguarda come e dove vengono utilizzati:
immagini, link, frames, form e tabelle nonché applet Java e animazioni Flash.
Modellare le pagine, i link fra esse, e tutto il contenuto dinamico che contribuisce alla
visualizzazione delle pagine sul browser dell’utente è molto importante.
La Web Application Extension (WAE) è un tentativo di definire un meccanismo che ci
permette, come disegnatori e architetti WEB, di esprimere, attraverso UML, i modelli di
design che contengono elementi HTML.
In questo modo abbiamo:
•
un modello di analisi e disegno per tutta l’applicazione
•
la capacità di esprimere il disegno di specifici componenti WEB ad un
appropriato livello di astrazione.
Tale estensione è definita mediante un insieme di stereotipi, tagged values 108 e vincoli.
I vincoli possono essere espressi con OCL.
Per quanto riguarda la modellazione vera e propria dobbiamo iniziare a dire che le
pagine web ( <<web pages>> è il primo stereotipo che incontriamo) vengono mappate
one to one con ciò che in UML viene chiamato componente. Un componente è una
108
I tagged values sono coppie di valori chiave che possono essere associati a elementi del modello che ci
permettono di definirli meglio.
86
Architetture e linguaggi
parte fisica del sistema. La component e l’implementation view descrivono proprio i
componenti e le relazioni del sistema. In sostanza una component view è la mappa di
un sito.
Figura 18: Esempio di diagramma WAE
Una pagina WEB è quindi una classe UML nel modello logico che è in relazione con le
altre pagine web con i link che in UML sono rappresentati con le associazioni
stereotipate <<link>> tra classi. Ma abbiamo detto che le pagine web si distinguono in
pagine web server e client. Per distinguerle UML fa uso degli stereotipi <<server
pages>> e <<client page>>. L’associazione stereotipata <<build>> tra queste 2 classi
ci permette di definire il fatto che il web server crea una pagina client a partire da una o
più pagine server.
I tagged values ‘’parameters’’ sono usati per definire i parametri che sono passati
attraverso i link.
Le operazioni di una <<server page>> classe diventano le funzioni di uno script server
side e gli attributi variabili globali di una pagina. Le operazioni e gli attributi di una classe
<<client page>> sono le funzioni e le variabili visibili sul browser-client.
Le form sono definite in UML come una classe con lo stereotipo <<form>>. Tale classe
non ha operazioni. Se bisogna definire funzioni che validano l’input allora bisogna
inserirle nella classe che contiene tale form (nella classe che modella la pagina client).
87
Architetture e linguaggi
Gli attributi di tale form sono i campi del modulo steso stereotipato con <<text>>,
<<password>>, <<submit>>. Una form può avere relazioni con applet e controlli
activeX che agiscono come controllori dell’input. Ogni form ha una relazione
stereotipata con <<submit>> con una pagina server che processa la submission del
form.
Figura 19: Modellazione del form di ricerca di VirtualMarket
Infine bisogna descrivere i frames. In HTML un frame permette che più pagine appaiano
contemporaneamente in una singola pagina html sul browser dell’utente. Per modellare
tale situazione in UML si usano 2 stereotipi, frameset e target e un’associazione
stereotipata <<targeted link>>. Una classe di tipo frameset rappresenta un contenitore
che contiene pagine client e targets. Una classe target è un frame che è referenziato da
un’altra pagina client. Un’associazione di tipo <<targeted link>> è un link ad un’altra
pagina ma che è renderizzata in un target specifico.
88
Progettazione
6 Progettazione
6.1 Analisi sistema esistente
Il primo passo da fare dopo aver analizzato i requisiti e studiato l’ambito del problema è
effettuare alcune considerazioni su ciò che è stato trovato all’interno dell’azienda.
L’azienda in questione dispone di un’infrastruttura di e-commerce basata su piattaforma
Microsoft NT4 e IIS4, database MS-ACCESS e sito strutturato con pagine html e
javascript (linguaggio client side) e alcune pagine ASP per l’accesso al db.
Il negozio (di tipo singolo, contenente cioè la vetrina di un sono negozio contrariamente
a come viene strutturato un mall) è costruito in massima parte usando un applicativo di
terze parti (‘Shop-Factory’) che a partire dal catalogo dei prodotti costruisce una vetrina,
il carrello e imposta le pagine per la gestione dei pagamenti. Nel database sono
presenti i prodotti completi di foto e descrizioni e prezzi. Vi sono anche le tabelle relative
alla gestione delle chiavi di Banca Sella per il protocollo SSL e un minimo di
informazioni sui corrieri.
6.1.1 Considerazioni e aspetti negativi
Risulta evidente quindi la scarsa propensione alla scalabilità, efficienza e flessibilità di
tale negozio in quanto:
•
il database ACCESS è limitato nel numero di accessi contemporanei a dieci
utenze, non supporta i trigger 109, le transazioni, quindi per un uso intensivo e più
performante è necessario usare un DBMS professionale;
•
l’uso di javascript per la gestione del carrello oltre che per la validazione
dell’input rende il sito troppo legato alla tecnologia dei browser utilizzati dagli
utenti. Infatti sia la presenza di diverse versioni di Javascript, sia la possibilità
che diversi utenti possano disabilitarne l’uso, sia la presenza (esigua) di browser
che non lo supportano affatto, rendono indispensabile o, non usare per nulla tale
linguaggio e rinunciare alle sue caratteristiche, o scrivere due versioni del sito:
109
Trigger: una Stored Procedure, ovvero una porzione di codice SQL, che viene eseguito automaticamente in
seguito ad un inserimento, modifica o cancellazione di record.
89
Progettazione
una per i possessori di browser con Javascript abilitato e una per coloro che
avessero rinunciato a tale tecnologia;
•
l’uso dei cookies110 per la memorizzazione del carrello rende il sito esposto a
pericolosi quanto facili attacchi da parte di utenti maliziosi in quanto è possibile
invalidare e/o modificare i valori contenuti nel cookie. Inoltre se tale file viene
manipolato o addirittura cancellato dopo la transazione, l’autenticazione
automatica dell’utente e l’attribuzione allo stesso dell’ultimo carrello salvato non
può avvenire o avviene in forma sbagliata. Inoltre non tutti i browser supportano i
cookies e non tutti gli utenti abilitano i loro ‘browser’ a tale tecnologia rendendo di
fatto inutilizzabile tutta la gestione delle transazioni;
•
l’uso dei frames rende di fatto difficile l’indicizzazione del sito in esame da parte
dei motori di ricerca che hanno difficoltà a analizzare e a memorizzare i siti che
usano tale tecnologia. Inoltre non tutti i browser la supportano e quindi obbligano
lo sviluppatore a dover scrivere una doppia versione del sito stesso: una con
frames e una senza.
Inoltre sono presenti anche altre caratteristiche negative:
110
•
poca dinamicità nella creazione delle pagine,
•
gestione del profilo del consumatore molto povera,
•
nessuna analisi dei dati provenienti dai moduli HTML 111 per l’inserimento dati,
•
nessuna analisi della navigazione dei visitatori,
•
database povero e poco flessibile nelle funzionalità gestibili
•
gestione delle cross promotions 112 inesistente,
•
memorizzazione dei dati provenienti dal contact center 113 inesistente.
Cookies: piccoli files di testo generati durante la navigazione su Internet usati per lo più per il riconoscimento
utente.
111
Moduli HTML: tecnicamente si chiamano Form.
112
Cross promotion: promozione incrociata fra prodotti diversi valida solo se venduti assieme.
113
Contact Center: infrastruttura di comunicazione capace di dialogare attraverso molteplici strumenti (chat, posta,
email, forum, telefono)
90
Progettazione
6.1.2 Conclusioni
Concludendo, il requisito per cui il sito debba essere visibile senza problemi dalla
maggior parte degli utenti, l’assoluta sicurezza che non possano avvenire frodi da parte
di utenti maliziosi, la certezza che il sito possa essere indicizzato in maniera corretta da
parte dei motori di ricerca, la disponibilità ad avere una gestione dei profili utente
avanzata e la necessità di avere un sito scalabile, modulare e perfor mante e facilmente
espandibile mi obbliga a pensare che tale soluzione sia assolutamente insufficiente per
i nostri scopi.
La necessità di realizzare una piattaforma di Customer Relationship Management;
l’esigenza di creare un sito completamente dinamico ma leggero e veloce con
riconoscimento automatico dell’utente con proposizione automatica di offerte mirate e
personalizzate, il bisogno di raccogliere e analizzare i dati provenienti dai form compilati
dagli utenti, i dati provenienti dalla navigazione e dagli acquisti fatti, l’ importanza di
avere a disposizione alcuni indici di qualità che riguardano le prestazioni dei corrieri,
nonché dei fornitori, nonché degli utenti stessi mi porta alla conclusione che, molte
sarebbero le modifiche e aggiunte assolutamente da fare e che, quindi, progettarne e
realizzarne uno completamente nuovo sarebbe la soluzione migliore.
6.2 Studio fattibilità/esigenze
(*)114
Il web fornisce alle aziende una immensa opportunità di analizzare il comportamento e
le preferenze degli utenti. Ogni visita ad un sito web genera dati importanti sul
comportamento degli utenti indipendentemente dall’eventualità che egli faccia un
acquisto. Nasce quindi l’esigenza di strutturare il sito in modo tale da acquisire nella
maniera più opportuna tali dati. Il processo di “scavare” i dati web è complicato a causa
della diversità dei dati raccolti. Una singola visita ad un sito può essere catturata non
solo nei file di log del server ma anche nei cookies generati alla pressione di un banner
o nei databases creati da script cgi in seguito alla compilazione di form di registrazione
o di acquisto. Una delle sfide iniziali quindi è stata quella di organizzare in una forma
coesa e coerente tutti questi dati per creare quindi profili dei nostri consumatori.
La prima forma di acquisizione di tali dati è rappresentata dai
114
Vedi [1a] della sezione ‘Principali siti di riferimento ’
91
Progettazione
•
file di log,
•
cookies,
•
Form.
6.2.1 File di Logs:
i server log file forniscono i tipi di dominio, il tempo di accesso, le parole chiave e i
motori di ricerca usati dai visitatori. La sezione referrer di un tipico file di log include la
provenienza di questi visitatori e da qui quindi tutta una serie di informazioni sui motori
di ricerca che indicizzano il nostro sito, le parole chiave che vengono usate dai visitatori,
il numero di banner in cui il nostro sito è presente, la lunghezza della navigazione ecc...
6.2.2 Cookies:
i cookies scritti dal server, in cui il web è presente, possono tracciare le visite di un
determinato browser, le pagine viste e quindi anche il numero di volte che un visitatore
accede alle nostre pagine e quali sezioni del nostro sito egli preferisce. I cookies sono
delle particolari intestazioni http che il server passa al browser e che vengono
memorizzati in piccoli file di testo nell’ hard disk del browser.
Tipici momenti in cui un cookie viene scritto sono:
•
la prima volta che un visitatore accede ad una particolare sezione del sito,
•
all’atto del submit da parte del visitatore di una form per scoprirne le preferenze,
•
all’atto della registrazione dello stesso per associare un cookie ad un ID del
database degli utenti.
6.2.3 Forms:
uno dei primi e validi metodi per carpire dati sui clienti è quello dei form di registrazione
e di acquisto.
La sottomissione di un modulo può lanciare un programma CGI che ritorna una risposta
al visitatore che può essere una semplice pagina html oppure una mail. Le forms sono
dei semplici meccanismi browser-to-server attraverso i quali l’interazione web-cliente
può essere registrata e analizzata.
Quanto più si interagisce con i clienti quanto più un numero sempre c rescente di
informazioni sui loro interessi, bisogni e scelte vengono catalogate nei db. Il pericolo
però è che le domande che vengono poste all’utente siano lunghe e noiose e che quindi
rendano falsificato il sondaggio. A nessuno piace scrivere la stessa informazione più di
92
Progettazione
una volta e quindi bisogna stare attenti a porre solo le domande essenziali e mai più di
una volta. Per esempio il form di registrazione può servire ad evitare che l’utente ad
ogni acquisto inserisca tutti i dati di interesse. Infatti al momento del pagamento basterà
chiedere uno username e una password e automaticamente verranno trovati nel db tutti
gli altri dati.
6.2.3.1Tipi di informazioni richieste con le form
Delle tre sorgenti di acquisizione dati: log, cookies e form quest’ultimi rappresentano la
via più ‘facile’ per aggiungere dati più importanti ai nostri db dei clienti.
Tali dati possono essere per esempio: il reddito, l’automobile, il numero dei figli.
La conoscenza del codice di avviamento postale ci può permettere di inviargli via posta
per esempio tutta una serie di servizi come notizie locali, il meteo, coupons per sconti
su locali vicini la sua residenza in modo da catturare sempre più la sua attenzione.
La possibilità che l’utente abbia un telefono mobile ci permette di offrirgli ulteriori servizi
via SMS come oroscopi, ricetta del giorno, risultati delle partite di calcio della squadra
del cuore.
Tutte queste notizie ci permettono di arricchire il suo profilo permettendoci per esempio
di fargli un offerta personalizzata su un biglietto di una partita importante della sua
squadra del cuore o di ricordargli via sms che il giorno successivo è l’anniversario di
matrimonio e proporgli dei regali per la moglie/marito. La conoscenza del tipo di
automobile, l’età dell’abitazione ci permette di ricordargli delle scadenze relative a
tasse, obblighi ma anche di fornirgli offerte per la manutenzione della casa e della
automobile. Insomma l’utente deve avere l’impressione di ricevere un servizio
gradevole ma mai invadente e indesiderato.
6.3 Scelte progettuali
6.3.1 Livello di presenza
Il livello di presenza scelto per Virtualmarket è alto orientato alla vendita B2C115, con
un forte customer care 116. Ci si prefigge quindi: massimizzare la fiducia nel rapporto con
115
B2C: Business to Consumer
93
Progettazione
i clienti, customer care, assistenza tecnica on-line, assistenza pre e post vendita,
gestione ordini e acquisti e pagamento elettronico tramite transazioni sicure usando
carta di credito, contrassegno, bonifico.
6.3.2 Architettura
Ho scelto l’architettura 3-tier suddividendo quindi l’applicazione in 3 livelli: livello di
presentazione, livello aziendale e livello fisico.
6.3.2.1Impostazione livello presentazione
La mia scelta è quella di limitare al massimo le funzionalità dell’applicazione dipendenti
dal browser, relegandole solo all’implementazione di particolari estetici (animazioni
Flash, banner javascript) che non pregiudicano il corretto e completo funzionamento
delle singole transazioni. Sono evitati tutti i controlli lato client per la validazione dei
campi delle form; l’uso dei cookies e delle variabili di sessione è completo ma ci sono
controlli per assicurarne il funzionamento solo nei browser che li supportano. Per gli altri
browser sono stati adottati meccanismi alternativi come la presenza di una variabile di
querystring (vmid) che permette, nel passaggio da una pagina all’altra, di mantenere
uno stato sopperendo di fatto alla mancanza delle variabili di sessione. Tale strategia è
però pericolosa e onerosa in termini di risorse in quanto per evitare che l’utente cambi
tale valore, vengono effettuati controlli incrociati con valori posti all’interno del database,
valori che legano vmid, all’indirizzo ip dell’utente, al suo browser, al suo sistema
operativo, seguendo il principio per cui è impossibile che ci sono 2 vmid uguali che
riguardano utenti con ip diversi, browser e so diversi. Per quanto riguarda la mancanza
dei cookies, si rinuncia al riconoscimento utente.
La maggior parte del calcolo, compreso quello del layout delle pagine è demandato al
server, il quale, costruisce l’output prelevando i dati direttamente dal db. Questa scelta
implica una notevole mole di lavoro da parte del server ma riduce spiacevoli
inconvenienti da parte di coloro che usano, per esempio, Mosaic per Linux come
browser (ben pochi ma ci sono). La pagina prodotta dal Web server è conforme alle
specifiche HTML 3.2 con alcune concessioni sui fogli di stile e HTML dinamico per
quanto riguarda funzionalità accessorie.
116
Customer Care: rientra in questa definizione tutto ciò che riguarda l’assistenza pre e post vendita verso i clienti
riguardo acquisto di prodotti e servizi.
94
Progettazione
L’impostazione delle pagine principali prevede la presenza di molti file comuni da
includere, in modo da suddividere le varie problematiche da affrontare in file distinti
inclusi poi in uno stesso file server. In questo modo è possibile abilitare le diverse
funzionalità agendo solo su tali file senza intaccare il resto.
Es: esiste un file gestione_pagamenti_euro.asp che può essere incluso da tutti quei file orderdtl.asp dei negozi che prevedono il
pagamento in euro. Eventuali modifiche alla gestione di tale pagamento verrà eseguito solo su un file e non su tutti gli orderdtl.asp
dei negozi riducendo i tempi e la complessità della manutenzione del sito anche se a discapito della velocità di risposta del server
web. (il server prima include i file, poi li interpreta e infine li spedisce al browser dell’utente che li aveva richiesti).
6.3.2.2Impostazione livello aziendale
Ho scelto una soluzione ibrida che, da un lato, preferisce la scrittura di script ASP per la
presentation logic, senz’altro più rapida e immediata e, dall’altro, l’uso di componenti
COM per l’accesso al db, la gestione del carrello e quella dei punti fidelity117. Quasi
sempre si è fatto uso di componenti scritti da terzi parti. In qualche caso sono stati scritti
componenti personalizzati. I componenti sono stati registrati e quindi posizionati nello
stesso server WEB, in quanto si è pensato, almeno per le fasi iniziali, dove c’è poco
carico elaborativo, di sfruttare le migliori performance di componenti eseguiti nella
stessa area di elaborazione del server WEB. La registrazione di tali componenti in
server diversi da quello di IIS richiede l’uso di DCOM che ovviamente rende più lenta
l’esecuzione, a causa della comunicazione tra i processi.
6.3.2.3Impostazione livello fisico
Ho scelto di usare sia le Stored Procedure che l’SQL dinamico 118 con una netta
preponderanza della seconda possibilità rispetto alla prima.
Le Stored Procedures realizzate riguardano una serie di query molto complesse (insert,
update) che, se implementate in modo dinamico, avrebbero appesantito l’elaborazione
del server in quanto trattasi di join multipli e tutte quelle query che debbono rilasciare
una chiave ‘incrementale’ della tabella. In questa seconda situazione, purtroppo, non ho
117
Vedi paragrafi ‘punti fidelity program ’ 6.7.1 e ‘il carrello ’ 6.6.2.1.2
118
Sql dinamico: è un metodo mediante il quale un’istruzione SQL da eseguire viene presentata al sistema di
gestione del database in modo che l’istruzione non debba essere nota prima che il programma (in questo caso pagine
server), dalla quale viene eseguita, sia lanciato. In altre parole l’istruzione viene costruita durante l’esecuzione del
programma.
95
Progettazione
potuto evitare di usare le SP 119 in quanto, con l’SQL Dinamico nelle pagine server, non
si riesce a calcolare l’indice della tabella in cui si è appena inserito un nu ovo record.
Tutte le altre query sono state scritte nelle pagine ASP e rese quindi dinamiche.
Qualsiasi query SQL che necessita di un parametro, nell’architettura ASP,
automaticamente diventa dinamica.
Es: sqlstr=”select * from ”&nometabella&” where campo=’”&valorecampo&”’
‘Dove nometabella e nomecampo sono le variabili.
Il motivo principale di tale scelta è l’esigenza di avere un sistema indipendente dal
DBMS usato anche rinunciando ad una maggior velocità. In questo modo infatti
cambiando il database gli script rimangono inalterati mentre se si fossero usate le SP si
sarebbero dovute riscrivere nel nuovo DBMS.
Ho scelto di impostare un database unico anche in virtù della presenza di più negozi a
carrello distinto, per questioni pratiche. Infatti sebbene i negozi siano separati, molti
servizi e prodotti possono essere condivisi (tipologia di spedizione e pagamento,
promozioni cross120). Il database finale comunque è reso distribuito/replicato seguendo
la logica per cui vengono separati, in archivi differenti, i dati delle vendite, dai dati degli
utenti, dai dati del catalogo, dai dati dei corrieri.
6.3.2.4Altre scelte
Ho ritenuto di impostare il sistema in modo che l’utente (sarebbe più corretto dire: il pc)
sia riconosciuto tramite cookie ma che tale riconoscimento non associ alcun profilo o
carrello salvato all’utente corrente in virtù del fatto che, sebbene il pc sia lo stesso,
questo può trovarsi in un Internet Point o in una casa, dove i diversi componenti
possono
usarlo
in
tempi
distinti.
L’associazione
pc-cookie
rende
possibile
l’aggiornamento del database dei profili per quanto riguarda le pagine viste, i prodotti
selezionati ecc… ma tutto ciò che riguarda la transazione vera e propria richiede il login
esplicito dell’utente.
Inoltre, se dall’analisi dei profili risultasse che, da uno stesso pc, si collegasse sempre
la stessa persona, si potrebbe allora ritenere attendibile il riconoscimento tramite cookie
119
SP: stored procedure
120
Promozioni Cross o incrociate: promozioni che riguardano l’acquisto combinato di prodotti diversi.
96
Progettazione
e quindi si potrebbe personalizzare il sito in maniera più azzardata attraverso l’analisi
del profilo utente. Queste considerazioni possono essere fatte solo con un profilo ormai
consolidato nel tempo e validato da una serie di questionari in cui viene chiesto
esplicitamente da dove ci si collega e se il pc viene usato solo dalla stessa persona.
6.4 Scelta degli strumenti
Fatte quindi tutte le precedenti considerazioni non risulta altro che decidere quali
strumenti adottare:
•
architettura
•
sistema operativo
•
database
•
web server
•
ambiente di sviluppo
•
descrizione del sistema
Le scelte sui vari punti sono influenzate dall’uso che se ne deve fare, dai tempi di
apprendimento dello strumento, dalla possibilità di avere un valido supporto da parte
della casa produttrice del software, dalla facilità con cui tali strumenti possono essere
usati, da una migliore gestione della concorrenza delle transazioni, bilanciamento del
carico, le repliche delle tabelle, uso di stored procedures e trigger da parte del DBMS, la
facilità con cui si possono implementare promozioni, profili utente, la possibilità di avere
un ambiente distribuito e/o transazionale.
6.4.1 Alternative
La scelta è stata quindi tra:
1) piattaforma Windows NT + IIS4 121 + SQL SERVER7122 + ASP + Site Server 3123
COMMERCE EDITION + architettura COM 3-tier attraverso MTS124
121
IIS: Integrazione con i servizi di elenchi in linea e di protezione di windows NT server, modello di oggetti ASP,
Servizi FTP, News, SMTP e WEB incorporato, supporto per il debug delle applicazioni, messaggi di errore http
personalizzati
97
Progettazione
2) piattaforma Windows NT + Lotus Domino GO + DB2 + IBM Net Commerce125 +
architettura CORBA 3-tier
3) piattaforma Windows NT + Java web server + (sybase, db2, oracle) + (Jsp,
servlet) + architettura CORBA 3-tier
4) piattaforma Linux + apache + (oracle, db2, interbase, postgres) + (php4, Jsp)
Tutte le alternative hanno dei pro e dei contro:
la soluzione 1 ha come
1. pro: la forte interoperabilità e coesione e integrazione dei vari strumenti offerti, la
presenza di un ambiente distribuito (COM + MTS) e la programmazione a
componenti di ASP.
2. contro: la nota instabilità e scarsa scalabilità del sistema operativo nonché la
scarsità degli strumenti messi a disposizione dall’applicativo ‘SITE SERVER’ e la
inferiorità del DBMS rispetto ai concorrenti.
la soluzione 2 ha come
1. pro: la potenza di un DBMS come ‘DB2’ della IBM pienamente integrato con il
web server Go della lotus e con l’applicativo ‘NET COMMERCE’, completo nelle
caratteristiche supportate è già implementate (carrello, gestione pagamenti,
gestione corrieri, profilo dell’utenza), realizzato in modo modulare e pienamente
espandibile e configurabile usando linguaggi proprietari (NET-DATA) e non
(C++,Java).
2. contro: elevate richieste HW per il server di riferimento e una elevato tempo di
apprendimento per Net Commerce;
la soluzione 3 ha come
122
SQL Server: Perfettamente integrato con IIS e visual interdev oltre che con ODBC, ADO permette di usare
trigger, Stored Procedures, indici nonché offre un supporto per le transazioni e la capacità di gestire in diverse
modalità le repliche di database distribuiti.
123
Site server è una piattaforma Microsoft per lo sviluppo di siti di commercio elettronico.
124
MTS: Gestisce i componenti di connessione al db e la loro transazionalità effettuando un pooling dei componenti
in base alle risorse dell’intero sistema rendendo di fatto scalabile l’intero sistema.
125
Net Commerce è la proposta IBM per lo sviluppo completo di siti di commercio elettronico.
98
Progettazione
1. pro: l’elevata qualità in termini di prestazione e scalabilità dei DBMS e la
intrinseca modularità e efficienza di JSP.
2. contro: la lentezza di Java e quindi l’elevata richiesta in termini di potenza di
calcolo, nonché la scarsa coesione tra i DB e l’ambiente JAVA, la scarsa
produttività della programmazione JSP e l’instabilità del SO NT;
la quarta soluzione ha come
1. pro: l’elevata affidabilità dell’ambiente LINUX, l’estrema semplicità e velocità del
linguaggio PHP4.
2. contro: ha una scarsa integrazione fra DB e PHP nonché la difficoltà di creare
un ambiente distribuito che avrebbe reso la piattaforma e commerce più
scalabile.
6.4.2 Scelta effettuata
La scelta finale è ricaduta sulla 1 opzione in quanto:
•
le richieste HW non sono esose,
•
c’è già una sufficiente conoscenza di tutti gli strumenti HW e SW riducendo di
fatto i tempi di realizzazione,
•
c’è la possibilità di avere un ambiente distribuito grazie a COM + MTS e quindi di
scegliere senza problemi l’architettura 3-tier di COM.
La profonda integrazione tra gli strumenti ci ha convinto che una attenta progettazione e
programmazione delle varie parti ci avrebbe evitato di imbatterci nei problemi di
instabilità di windows NT anche perché l’imminente uscita di Windows2000 ci avrebbe
risolto molti dei nostri problemi.
6.4.3 Disposizione fisica dei server
La disposizione dei vari server è la seguente:
•
1 server web IIS 4,
•
1 server dei componenti (MTS) locato nella stessa macchina del server web,
•
1 server Database SQL Server 7 posto in una macchina distinta,
99
Progettazione
•
1 server di staging126 dotato del server web, di MTS e del DBMS e delle repliche
di tutti i negozi
Figura 20: Disposizione dei server
Figura 21: Architettura 3-tier dell'applicazione VirtualMarket
126
Server di staging: usato per i test delle funzionalità appena sviluppate
100
Progettazione
Figura 22: Server Component
Figura 23: Presentation Logic
101
Progettazione
Figura 24: Business Logic
6.4.4 Strumenti di sviluppo
•
Frontpage per l’impostazione iniziale della pagine
•
Visual InterDev per lo sviluppo delle pagine ASP e dei componenti CO M. Tale
strumento permette l’integrazione completa tra SQL server e MTS,
•
Site Server come infrastruttura tecnologica che fornisce sia componenti, sia
interfacce per la gestione delle pipeline, un modulo per il carrello e per le
transazioni,
•
Rational Rose per la modellazione dell’intero sistema.
6.5 Indicatori per la progettazione del database
(*)127
Affinché si possa spostare l'attenzione da un'analisi delle iniziative di marketing basata
sul prodotto ad una con maggior enfasi sul cliente e sul profitto è neces sario poter
disporre di una serie di indicatori, parametri chiave, da inserire, come campi, nelle
127
Vedi [5] della bibliografia
102
Progettazione
tabelle del database e che possano riflettere l'andamento più o meno negativo di una
serie di eventi. La presenza di questi indicatori, trattati come dimensio ni all’interno di un
Data-WareHouse,
permetterà,
in
seguito 128,
di
facilitare
la
'navigazione
multidimensionale' tra i dati utilizzando gli operatori OLAP descritti nel paragrafo
‘OLAP’.
In sostanza, tramite le interviste fatte con il management dell’azienda e tramite le
ricerche effettuate sul web, è possibile stabilire quali siano i valori chiave, le dimensioni
appunto, che un esperto di marketing voglia poter usare, per esempio, nell’analisi dei
dati sulle vendite della propria attività.
Con tali esperti, si prefiggono gli obiettivi da raggiungere (analisi delle vendite, analisi
dei profitti, degli utenti, analisi delle strategie di marketing da adottare in base ai risultati
di quelle in corso, analisi delle performance dei corrieri, ecc…) e quindi si cerca di
individuare quali possano essere le dimensioni che possano aiutarlo a pensare in
maniera ‘multidimensionale’ (ad es. analizzare le performance dei corrieri nel 1999 in
Italia tendendo conto degli articoli trasportati).
Le dimensioni più importanti sono:
•
Quando (indicatori: trimestre, mese, giorno, anno)
•
Chi (indicatori: quale divisione di vendita, produzione, quale cliente, quale
fornitore)
•
Cosa (indicatori: prodotto, unità di produzione, marca, id del prodotto, linea di
prodotto)
•
Dove (indicatori: canale di vendita)
•
Risultato (indicatori: guadagno, costi, margine)
Per quanto riguarda l'obiettivo da raggiungere bisogna considerare ben 7 aree su cui
concentrarsi:
128
•
Finance,
•
Sales (Vendite),
•
Marketing,
•
Purchasing (Acquisti),
in seguito in quanto per questo progetto non è stato implementato un datawarehouse. Vedi paragrafo 6.6.2.4.
103
Progettazione
•
Production (Produzione),
•
Distribution (Distribuzione),
•
Customer Service (Assistenza clienti)
Per il management di Virtualmarket le aree Production e Purchasing sono di poco conto
anche se sono molto importanti per i singoli gestori dei negozi, in quanto, quest’ultimi,
possono avere il problema della produzione e dell'acquisto dei materiali. Anche l'area
Finance non è stata considerata per il progetto in quanto esiste già un software adatto.
Comunque di tutte le aree esporrò gli obiettivi mentre per le altre esporrò anche le
dimensioni e quindi gli indicatori rilevati:
Finance:
Obiettivi
•
Conto profitti e perdite multidimensionale
•
Analisi drill-down del profitto
•
Bilancio multidimensionale
•
Rapporti sui punti chiave dell’investimento finanziario
•
Analisi del cash flow
Vendite:
Obiettivi
•
Analisi delle vendite
•
Analisi delle profittabilità dell’utente
•
Previsioni e piano di vendita
•
Strutturazione delle vendite
Dimensioni
•
tener conto di dati per anno, quadrimestri, mesi e possibilità di navigazione anno
per anno, mese per mese etc...
•
tener
conto
delle
vendite
di
ogni
singolo
negozio,
di
ogni
singolo
reparto/categoria di prodotto,
•
tener conto per ogni prodotto della linea di prodotto, della marca, dello SKU
•
tener conto per i clienti del range di acquisto, della posizione in classifica dei
migliori acquirenti,
104
Progettazione
•
tener conto del tipo di vendita, nuovo, saldi, fondi di magazzino
•
tener conto della probabilità di vendita di un prodotto in un certo periodo
Indicatori rilevati da inserire nel database
unità ordinate, ordini cambiati, unità vendute, incasso, sconti, percentuali degli sconti,
prezzo medio di vendita, percentuale dei reclami, percentuale delle spedizioni.
Marketing:
Obiettivi
•
Analisi di marketing strategico
•
Analisi di marketing tattico
Dimensioni
•
tener conto di dati per anno, quadrimestri, mesi e possibilità di navigazione anno
per anno, mese per mese ecc...
•
tener conto della linea di prodotto, della marca, dello SKU,
•
tener conto del numero di clienti,
•
tener conto della profittabilità dei segmenti dei clienti,
•
tener conto della tipologia e caratteristiche del prodotto: colore, taglia, materiale,
•
tener conto del tipo di campagna di marketing adottata e verso chi,
•
tener conto dei messaggi inviati ai clienti,
•
tener conto del territorio di vendita, gruppi demografici,
Indicatori
costo del marketing, numero di esposizioni, risposta alle esposizioni, percentuale di
successo delle iniziative di marketing.
Acquisti materiali:
Obiettivi
•
analisi dei punti di riordino,
•
tabella performance fornitori
Produzione
Obiettivi
•
capacity Management,
•
costi standard e qualità dei prodotti
105
Progettazione
•
motivi di scarsa qualità
Distribuzione:
Obiettivi
•
Tabella performance dei corrieri
Dimensioni
•
suddivisione dei dati per anno, quadrimestri, mesi
•
suddivisione per tipo di spedizione (truck, treno, aereo, nave)
•
suddivisione per destinazioni (regioni, territori e città)
•
suddivisione per clienti o segmenti di clienti
•
suddivisione per fattori di distanza
•
suddivisione per tipo di cliente: just in time o buy and hold
Indicatori
numero di viaggi, peso trasportato, distanza, costo per km, costo per kg percentuale di
viaggi in tempo.
Assistenza clienti:
Obiettivi
•
Consegne nei tempi prestabiliti
•
Reclami, richieste e restituzioni
•
Costi del servizio clienti
Dimensioni
•
suddividere i dati per anno, quadrimestre e mese
•
tener conto di linee di prodotto, marche e SKU
•
memorizzare le locazioni in cui avvengono le transazioni,
•
avere riferimenti a clienti e segmenti di clienti,
•
memorizzare i tempi di consegna suddividendoli in fasce di tempo
•
memorizzare lo stato di un ordine
•
memorizzare il motivo per cui un pacco è stato rifiutato,
•
memorizzare i difetti riscontrati
Indicatori
106
Progettazione
numero pacchi accettati, percentuale pacchi accettato, percentuale spedizioni
completato, numero di reclami, numero di pacchi rimandati indietro, numero di offerte
speciali, numero di cambi d'ordine
6.6 Moduli base e diagrammi UML
Attraverso l’analisi dello Use Case [fig. 25] che mostra le possibili attività che un utente
può fare sul mall possiamo dedurre quali siano i moduli che compongono l’applicazione.
Figura 25: Use Case Diagram: user profiling
E’ facile individuare la necessità di un modulo per la gestione dei negozi, uno per la
memorizzazione e visualizzazione del catalogo, uno per la gestione del carrello, uno per
la gestione delle spedizioni e dei pagamenti, uno per il controllo del Contact Center, uno
107
Progettazione
per lo user profiling. Saranno descritti, in seguito 129, anche se non indicati dallo Use
Case Diagram, altri moduli come la gestione dei partner e la gestione dei punti Fidelity
che possono considerarsi aggiuntivi all’insieme di funzionalità base che un mall deve
poter offrire.
Per la descrizione dei vari moduli che compongono l’applicazione Virtualmarket bisogna
dapprima
introdurre le varie tipologie di utenza che possono interagire con
l’applicazione, in quanto in ognuno dei moduli, saranno presenti, e quindi descritte,
scenari tipici fra l’applicazione e il mondo esterno.
Di ogni utente dobbiamo gestirne l’attività principale, il profilo e la storia dell’interazioni
con il mall [fig. 26].
Figura 26: Use Case Diagram: utente
Gli utenti possono essere semplici utenti web che si collegano e visitano il sito. Per
questi viene progettato e realizzato appositamente un modulo per la memorizzazione e
analisi dei dati scaturiti dalla navigazione e dalle transazioni effettuate sul mall.
Altra tipologia di utenza è quella dei manager dei negozi o del mall che possono
intervenire, se dispongono degli opportuni privilegi, sul layout o sulle funzionalità del
sito, usufruendo di appositi script.
129
Vedi paragrafo ‘moduli aggiuntivi ’ 6.7
108
Progettazione
Ultima tipologia di utenza è quella dei partner che, procurando nuovi negozi o
convogliando traffico sul mall mediante banner, usufruiscono di commissioni sul
venduto.
In seguito, in questo documento, verranno approfondite le singole tipologie di utenza
mediante opportuni diagrammi.
Tutti gli utenti appena accennati possono essere modellati con il diagramma degli
oggetti successivo [fig. 27].
Figura 27: Tipologia di utenza
109
Progettazione
Come si può notare la classe Virtualmarketuser descrive l’utente generico registrato di
cui possiamo conoscere il nome, la data di nascita e la data della prima visita. Poi ci
sono le classi che lo specializzano: abbiamo così la classe dei partner PartnerSpec a
sua volta divisa in classe dei partnerB2B e partnerB2C che si differenziano per il fatto
che un partnerB2C non può avere subpartner dai quali maturare commissioni. Poi
abbiamo la classe di manager suddivisa in manager di negozio e manager dell’intero
mall e infine la classe che descrive l’utente web generico ma registrato.
Il successivo diagramma degli stati [fig. 28] mostra come possano essere modellati gli
stati delle istanze della classe Virtualmarketuser.
Figura 28: StateChart Diagram: VirtualMarketUser
6.6.1 Front end
6.6.1.1Sistema di gestione del catalogo
Dalla specifica dei requisiti emerge che bisogna soddisfare una serie di esigenze:
•
inserimento e modifica di n gestori negozi,
•
inserimento e modifica di n partner commerciali,
•
inserimento e modifica di n negozi associati ai gestori,
•
inserimento e modifica di n categorie e sottocategorie,
•
possibilità di nascondere le categorie se gli articoli in esse contenuti non sono
disponibili per l’acquisto,
110
Progettazione
•
possibilità di visualizzare i contenuti in diverse lingue,
•
inserimento e modifica di n prodotti,
•
possibilità di non visualizzare i prodotti non disponibili per l’acquisto,
•
possibilità di visualizzare ma di non rendere ordinabili determinati prodotti,
•
indicazione delle quantità minime per l’acquisto,
•
indicazione per l’Iva specifica per ogni prodotto,
•
gestione opzioni dei prodotti,
•
gestione magazzino,
•
gestione promozioni.
Queste esigenze vengono soddisfatte in fase di progetto ma è stato richiesto che
possano essere soddisfatte anche a run-time attraverso l’intervento da remoto da parte
dei manager del mall e dei singoli negozi. I dettagli di questa sezione saranno
approfonditi nel paragrafo sulle tipologie di manager.
Per quanto riguarda il catalogo ho pensato di affrontare il problema concentrandomi
sulla parametricità del database. Dato che bisogna permettere di gestire un numero
variabile di negozi, categorie, prodotti, promozioni non posso creare un db che
necessita di continui aggiornamenti.
Possiamo quindi rappresentare con un diagramma delle classi [fig. 29], creato nella
fase di analisi, le entità coinvolte. Tale diagramma, con le regole esposte nel paragrafo ‘
UML e la modellazione delle basi dati relazionali ’ verrà trasformato in un diagramma ad
oggetti ‘Data Modeling ‘ [vedi fig. 41] dal quale sarà facile derivare il diagramma entità
relazioni del database finale.
111
Progettazione
Figura 29: Diagramma delle classi iniziale sui prodotti e i negozi
In questo diagramma le entità fondamentali sono: negozi e prodotti e le loro opzioni.
Si può vedere come i dipartimenti sono distribuiti ad albero attraverso il campo
‘categoria padre ’. Si può notare la presenza delle tabelle ‘parole chiave ’ e ‘marche ’
che specificano meglio il prodotto. Nella tabella delle parole chiave esiste un campo
‘priorità ’ che attribuisce un ordine e, quindi, un’importanza, ai vari articoli in modo da
pilotare l’output del motore di ricerca interno. In sostanza tale attributo definisce una
sorta di ranking, utile quando si vuole promuovere un prodotto anche con il semplice
fatto di posizionarlo meglio, rispetto agli altri, nell’output di una ricerca.
112
Progettazione
Sono state inserite anche una tabella ‘commenti ’ e una tabella ‘web promotion’. La
prima memorizza le opinioni degli utenti sui i vari prodotti e la seconda i dettagli sulle
forme di applicazione delle promozioni dei prodotti stessi. In sostanza in questa tabella
si conosce come, dove, quando e a chi un determinato prodotto viene posto in
promozione ‘visiva ’ ovvero viene messo in un banner, in una finestra a pop up, viene
posto ai primi posti del motore di ricerca o viene visualizzato nelle vetrine della home
page.
Infine le tabelle ‘virtualmarketuser ’ e ‘partnerspec ‘ rappresentano il legame fra prodotti,
negozi e alcune tipologie di utenza descritte in seguito (manager, partner, utenti).
I negozi
Secondo le specifiche del committente, il sistema deve poter gestire un numero
indefinito di negozi che devono appartenere ad un unico proprietario ma che possono
avere più di un partner commerciale 130. Un proprietario può avere anche più negozi.
Come appare dal diagramma [fig. 30], nella tabella dei negozi (Stores) appaiono diverse
informazioni come il nome del negozio, la partita Iva del negozio, l’email associata a
quel negozio, un codice valido ai fini fiscali per quel negozio, l’indirizzo web del negozio,
il logo ma soprattutto i riferimenti tramite chiavi esterne:
•
allo stato di un negozio (attivo, disattivo, in costruzione etc…), (tabella Status)
•
il riferimento al proprietario del negozio che può anche averne degli altri (notare
la cardinalità della relazione 1 a molti) (tabella StoreOwner)
•
il riferimento alla valuta di default che il negozio accetta per le transazioni
economiche ma anche a tutte le altre valute che può accettare (tabella ROE).
Inoltre è descritta anche una tabella Shops che rappresenta tutti i dati tecnici relativi a
quel negozio come il nome della directory all’interno del server, il percorso ODBC dei
negozi da dare al motore ASP. In questo modo, ci si prepara a rendere distribuito il
database in quanto ogni negozio è raggiungibile via ODBC in maniera distinta dagli altri.
130
Partner: figura che procura a VirtualMarket visite e negozi in cambio di un compenso. La gestione dei partner
non viene sviluppata in questo modulo ma in uno diverso per motivi legati alle performance e alla omogeneità dei
dati. Ho pensato infatti che porre in questo database i dati relativi ai compensi dei partner sarebbe stato pericoloso
per la sicurezza dei dati e comunque poco consono rispetto al dominio dei dati di negozi e articoli e promozioni.
113
Progettazione
Figura 30: Class Diagram Data Modeler: negozi
Ci sono 2 livelli per i manager dei negozi.
•
manager dell’intero mall: può intervenire sui diritti che i singoli utenti compresi i
gestori dei negozi possono avere su Virtualmarket.
•
manager del singolo store: è in grado, attraverso degli opportuni script, di poter
aggiornare il proprio negozio aggiungendo reparti e prodotti o modificando quelli
esistenti.
Tra i compiti più importanti del manager del mall posso elencare:
•
attribuire ad un determinato negozio il tema grafico,
•
scegliere le tipologie di pagamento e di spedizione consentite,
•
vietare o permettere che un determinato gestore di negozio possa cambiare il
layout della vetrina,
•
vietare o permettere che possa gestire le promozioni,
114
Progettazione
•
vietare ad un particolare utente di fare acquisti in un determinato negozio,
•
vietare di usarvi la carta di credito e permettendogli invece di usare il
contrassegno.
La figura 31 mostra, attraverso uno Use Case diagram, tutte le possibili attività di un
manager del mall.
Figura 31: Use Case Diagram: Mall Manager
Con la premessa che un manager dello store può eseguire determinate operazioni solo
se gli è stato consentito dal manager del mall, posso elencare le operazioni più
importanti che può eseguire su un negozio:
•
impostare e modificare promozioni e sconti sui prodotti del suo negozio,
•
modificare il layout della vetrina,
•
impedire il pagamento con carta di credito a determin ati utenti,
•
aggiungere il supporto per nuove valute,
115
Progettazione
•
gestire metodi di spedizione ecc…
Figura 32: Use Case Diagram: Store Manager
Il mall manager è anche uno store manager in quanto può intervenire sui singoli negozi;
In
tal
caso
viene
descritto
come
attore
che
restringe
e
specializza
le
proprietà/funzionalità del mall manager.
Per ogni negozio sono quindi disponibili e attivabili le seguenti features:
131
•
più modalità di spedizione,
•
più modalità di pagamento,
•
più listini,
•
diverse tipologie di vetrina (random 131 o dinamica132),
Random: I prodotti per la vetrina vengono scelti in modo casuale.
116
Progettazione
•
diversi tipi di promozioni,
•
diversi tipi di interazione con i clienti (chat, forum, numero verde, posta),
•
gestione del magazzino,
•
gestione partner,
•
gestione del traffico,
•
gestione della visibilità di un prodotto sulla vetrina.
Tali caratteristiche sono implementate prendendo in considerazione la struttura del
database e delle pagine ASP. E’ necessario, quindi, di un insieme di tabelle che
memorizzino, negozio per negozio e utente per utente, quali features siano applicabili e
tabelle che memorizzino i livelli di autorizzazione con cui, determinati utenti, in questo
caso manager, possono accedere a determinate risorse [vedi fig. 33].
Figura 33: Class Diagram Data Modeler: utenti e autorizzazioni
132
Dinamica: I prodotti per la vetrina vengono selezionati o in base al profilo dell’utente corrente o in base alle
promozioni in corso.
117
Progettazione
Per quanto riguarda le autorizzazioni bisogna dire che la tabella T_KindOfUser
memorizza i tipi di utenza che possono navigare su Virtualmarket: partner, manager,
simpleuser, operator, ecc… La tabella T_Authoritation raccoglie i vari tipi di
autorizzazioni: lettura, scrittura, inserimento prodotti, inserimento categorie, gestione
template, gestione utenti, ecc…. La tabella T_UserAuth realizza l’associazione molti a
molti tra gli utenti e le autorizzazioni memorizzando: l’utente, il tipo di autori zzazione, il
negozio su cui può agire, il manager che gli ha concesso l’autorizzazione e la data di
autorizzazione.
Per le features come: gestione magazzino, gestione template, visualizzazione
intelligente dei prodotti, servizio cortesia su sms ecc.. basta prevedere una tabella
T_Features che le memorizza e legarla molti a molti con la tabella dei Negozi T_Shops
memorizzando in un campo value un valore che viene scritto nei files di configurazione
delle features e che in genere è ‘enabled’ [vedi fig.34].
Figura 34: Class Diagram Data Modeler: memorizzazione delle features
Per la gestione dei pagamenti e delle spedizioni [vedi fig. 35] il discorso è simile. Nelle
tabelle ShippingMethod e PaymentMethod ci sono tutti i tipi permessi di spedizione e
pagamento (corriere, posta ordinaria, carta di credito, contrassegno, ecc…). Basta
legare tali tabelle con quella dei negozi (relazione molti a molti) e ottenere
118
Progettazione
T_Stores&Shipping e T_Stores&Payment. In tali tabelle viene memorizzato anche la
data in cui tale associazione è stata effettuata, da quale manager e per quali utenti è
disponibile.
Figura 35: Class Diagram Data Modeler: attribuzione dei sistemi di pagamento e spedizione
Grazie alla presenza di tabelle che memorizzano le features attivabili, i negozi, i gestori
dei negozi, i vari utenti registrati e le relazioni che li legano, si possono realizzare
facilmente degli script lato-manager che accedono a tali tabelle; in questo modo si
accede a dei valori che indicano se, per un determinato negozio, una determinata
tipologia di spedizione è attivata o meno oppure se per un determinato utente la
possibilità di pagare in un certo negozio con carta di credito è attivata o meno.
Le figure successive [36-39] mostrano dei prototipi di ‘pagine lato-manager ‘ che
permettono al manager di modificare il setup di uno o più negozi.
119
Progettazione
Figura 36:Pagina lato manager per la modifica dei dati di un negozio
Figura 37: Pagina lato manager per l'aggiunta di un corriere
120
Progettazione
Figura 38: Pagina lato manager per la modifica dei dati di un prodotto
121
Progettazione
Figura 39: Pagina lato manager per la modifica dei privilegi/autorizzazioni degli utenti
Il contenuto delle tabelle modificate da questi script, viene letto all’interno del
global.asa133 e dei vari files che implementano fisicamente l’attivazione o meno di una
determinata caratteristica; files che riguardano l’elencazione delle categorie di un
negozio, la visualizzazione delle caratteristiche dei prodotti ivi presenti, la gestione del
carrello, la gestione delle transazioni ecc…
I prodotti e le categorie
Il database dei prodotti e dei negozi è l’archivio più delicato in quanto la mole di dati che
deve poter contenere è considerevole 134.
Ogni prodotto deve essere identificato in modo univoco all’interno di tutto il database;
può essere collocato in reparti di nome diverso all’interno dei singoli negozi e all’interno
133
Global.asa vedi paragrafo ‘il file global.asa ’ 6.8
134
Il mall deve contenere un numero indefinito di negozi, reparti e prodotti.
122
Progettazione
di un negozio può apparire in reparti diversi. Ogni articolo può avere diverse opzioni
ognuna con un prezzo e disponibilità diverse. Il prodotto base, per semplicità, viene
considerato comunque un prodotto con una particolare opzione. Ogni articolo avrà uno
stato attraverso la cui lettura si potrà decidere di metterlo in vetrina, oppure di non
venderlo più, oppure di scrivere che ci sono nuovi arrivi ecc…
Figura 40: Class Diagram Data Modeler: prodotti e le categorie
Nella figura 40 si può notare come la tabella Articles contenga le informazioni
necessarie per l’identificazione del prodotto quali il nome, un codice di chi lo ha
123
Progettazione
prodotto, una breve e una lunga descrizione, uno stato, l’URL delle immagini, un indice
alla marca e un indice alla tabelle che contiene le varie dimensioni.
La tabella delle marche (Brands) è stata inserita per convenienza in quanto può essere
utile nei motori di ricerca ricercare tutti i prodotti di una certa marca. L’attributo
manufacterID si riferisce al produttore dell’articolo (es: Barilla per Mulino Bianco).
La tabella Department si occupa di memorizzare i nomi di tutti i dipartimenti. La
relazione tra negozi e dipartimenti è stata realizzata con la tabella StoresAndArticles
che fa in modo che ogni prodotto sia associato al negozio che lo vende e alla categoria
che lo contiene. Risulta chiaro dalla struttura della tabella che uno stesso prodotto può
essere venduto da negozi diversi in categorie diverse e dallo stesso negozio in
categorie diverse. Il campo DeptFatherID serve a risalire alla struttura dell’albero delle
categorie. Se infatti un prodotto può appartenere a più categorie, dalle specifiche
appare che la struttura dei reparti deve apparire come un albero e non come un grafo.
La tabella RelatedProduct e la tabella TypeOfRelationBetweenProduct servono a
modellare l’esigenza di avere dei prodotti legati fra loro indipendentemente dal fatto di
appartenere alla stesa categoria o di avere delle parole chiave in comune. Per esempio
se un prodotto è un accessorio di un altro, o un suo pezzo di ricambio, tali tabelle
memorizzano questa forma di relazione.
La gestione delle opzioni è abbastanza complessa in quanto bisogna permettere che
ogni prodotto abbia un numero indefinito di opzioni e che ognuna di esse possa essere
disponibile135 e rappresentabile con una foto.
Tali caratteristiche sono state implementate attraverso la tabella OptionArticles che
memorizza l’id del prodotto, del negozio, della valuta, il prezzo, la quantità disponibile,
la quantità ordinata e l’indirizzo della foto. Inoltre viene memorizzato, tramite chiave
esterna, un riferimento alla tabella OptionsValueList che contiene, per ogni opzione
(colore, tipovernice, numero porte, capacità), i suoi valori (giallo, metallizzata, 5, 10
giga) e una descrizione.
La gestione degli sconti prevede che si possano gestire diversi tipi di offerte
promozionali:
•
135
sconto generalizzato verso uno o più prodotti;
indicando anche la quantità in magazzino e l’eventuale quantità in ordine e quindi in arrivo
124
Progettazione
•
sconto su uno o più prodotti se acquistato in una certa misura;
•
sconto su uno o più prodotti se acquistato in combinaz ione con altri prodotti;
•
sconto su uno o più prodotti se prenotato in un certo numero di elementi entro
una certa data;
•
sconto su uno o più prodotti se si acquistano in combinazione con altri in un
intervallo limitato nel tempo;
•
la possibilità di offrire in sconto un prodotto o un servizio se si effettua una spesa
superiore ad una certa cifra.
Si dovrà tenere traccia di tutte le promozioni, in modo da giustificare e valorizzare le
varie iniziative di marketing in base al loro successo ottenuto.
Figura 41: Class Diagram Data Modeler: Gestione promozioni, sconti, richiesta informazioni,
suggerimento prodotti e commenti
125
Progettazione
Nella figura 41 viene visualizzato il class diagram relativo a promozioni, sconti e
commenti. La tabella Discounts per esempio memorizza l’id del negozio e dell’articolo in
promozione, le date di inizio e fine promozione, l’intervallo di tempo che intercorre
dall’acquisto di un certo prodotto e quello in promozione, un valore che indica il tetto
minimo di prenotazione grazie al quale si potrà beneficiare di uno sconto, la quantità di
prodotto da ordinare per beneficiare dello sconto, il valore minimo da spendere, l’entità
dello sconto e l’id del negozio e del prodotto associato ad esso per lo sconto nonché la
quantità del prodotto scontato da ordinare per beneficiare dello sconto.
Facciamo un esempio:
se un consumatore acquista almeno un prodotto A e 2 prodotti B allora ha diritto ad uno sconto del 30% se acquista il prodotto C e il
prodotto D entro 10 giorni. Offerta valida dal 1 gennaio e 30 gennaio.
Nel record della tabella ci sarà
un ID per la promozione,
0 per il limite della prenotazione (in quanto non c’è questa opzione),
1 per la quantità minima,
1/1/2001 per la data di inizio,
30/1/2001 per la data di fine,
10 giorni per la durata,
30 per lo sconto,
1 per la quantità del prodotto scontato C,
storeID,
l’id per il prodotto A,
storeID,
l’id per il prodotto C;
poi ci sarà un altro record con
lo stesso ID per la promozione
0 per il limite della prenotazione (in quanto non c’è questa opzione)
1 per la quantità minima
1/1/2001 per la data di inizio
30/1/2001 per la data di fine
10 giorni per la durata
30 per lo sconto
1 per la quantità del prodotto scontato
storeID
l’id per il prodotto B
storeID
l’id per il prodotto D
In sostanza, l’unione dei prodotti scontati mi da l’insieme dei prodotti da dare in offerta
mentre l’unione dei prodotti in promozione mi da l’insieme dei prodotti grazie ai quali si
126
Progettazione
può ottenere un beneficio. Ovviamente quello da me rappresentato è un esempio limite.
Difficilmente si avrà nella realtà una tale situazione ma in un mall dinamico e altamente
personalizzato bisogna studiare ogni singola possibilità.
Molto semplice l’estensione ai servizi, che possono essere considerati come ‘ prodotti in
offerta ’. Se volessimo rendere gratuita, la spedizione di un certo prodotto, solo se si
effettuano acquisti per più di 100000 lire basterà specificare 100000 nella colonna
cifra_minima, non indicare niente per i campi relativi al prodotto in promozione e al
negozio di appartenenza e specificare un id per il ‘prodotto’ spedizione appartenente ad
un negozio che per convenienza chiamiamo vm136.
Viene descritta in questa sezione una forma di promozione molto comune nei siti web e
quindi anche in Virtualmarket che è quella dell’esposizione più o meno calcolata di un
determinato prodotto (Web Promotions) [fig. 42]; tale esposizione o impression può
avvenire via banner, attraverso finestre pop up, oppure pilotando l’output del motore di
ricerca, attraverso direct mailing137 o attraverso la vetrina dei prodotti del giorno. In
questo modo, avendo più visibilità, un prodotto ha più probabilità di essere venduto. Tali
dati vengono memorizzati nella tabella PromotedArticles, in cui vengono specificati: la
data di inizio e fine promozione, il prodotto e il tipo di campagna promozionale (banner,
direct mailing, ecc…).
Figura 42: PromotedArticles
La gestione dei commenti degli utenti è stata inserita in questo database per il semplice
fatto che ciò che i vari visitatori esprimono sui prodotti messi in vetrina è parte
136
vm: Si è adottata la convenzione per cui tutto ciò che non appartiene specificatamente a nessun negozio ma che è
incluso in tutti in un modo o nell’altro, appartiene ad un negozio fittizio chiamato appunto vm.
137
Direct mailing: forma di promozione diretta che prevede di spedire cataloghi pubblicitari contenenti offerte
personalizzate solo a destinatari con alta probabilità di acquisto/interesse.
127
Progettazione
integrante della vetrina stessa. La possibilità di poter leggere i commenti espressi da
altri sul prodotto che suscita interesse in una persona, fa aumentare, per l’utente, la
sensazione che il prodotto possa essere di proprio gradimento. Inoltre sulla pagina è
possibile spedire i commenti a degli amici e scriverne degli altri. E’ considerato un
commento anche una valutazione numerica del prodotto espresso per esempio
mediante simboli opportuni. La media di tale valore sarà indicata sulla pagine descrittiva
del prodotto per offrire un servizio di valore aggiunto al consumatore.
Figura 43: Commenti
La gestione dei commenti è molto semplice in quanto è stata realizzata una tabella
(Comments) [vedi fig. 43] che memorizza la data, il prodotto (e il negozio di
appartenenza), un identificativo di chi ha lasciato il commento che può essere più o
meno registrato, il tipo di commento (CommentType) che può essere un commento
testuale, una valutazione numerica o altro e la data in cui tale commento è stato inviato.
Mediante l’id all’articolo si può risalire al prodotto e quindi al negozio e quindi scrivere in
esso in una sezione opportuna tutte le recensioni relative ad esso. Si può esprimere
una votazione sintetica del prodotto la cui media verrà visualizzata a fianco della
descrizione del prodotto.
Ogni prodotto può essere suggerito ad un amico tramite opportuno form, presente in
ogni pagina di descrizione del prodotto, nel quale viene richiesto di inserire un
commento, e l’email o il numero di cellulare al quale mandare il commento. Tali
128
Progettazione
suggerimenti con tutti i dettagli ad essi relativi vengono memorizzati nella tabella
SuggestedProduct [vedi fig. 44].
Figura 44: Suggested Product
Durante la navigazione sul sito ci si può imbattere in prodotti estremamente interessanti
di cui vogliamo conoscere più informazioni o semplicemente sapere quando verranno
proposte iniziative promozionali, ad essi relativi. In questo caso l’utente potrà effettuare
richieste di ulteriori informazioni, attraverso un semplice form e i dati che immetterà
verranno memorizzati nella tabella ProductInfoRequest [vedi fig. 45].
Figura 45: ProductInfoRequest
Riepiloghiamo, attraverso un diagramma degli stati della classe Articles, quali possano
essere gli stati di un’istanza di tale classe durante una transazione [vedi fig.46].
129
Progettazione
Figura 46: StateChart Diagram: istanza classe Articles
6.6.1.2Motore di visualizzazione
Gli obiettivi che vanno raggiunti, per quanto riguarda la struttura delle pagine, sono
essenzialmente:
•
Presentazione dell’azienda
1. Informazione sull’attività
2. Contatti
3. Credenziali e informazioni aggiuntive
•
Personalizzazione del sito
•
Selezione del modello grafico più consono all’esercente
•
Selezione del font con cui si presenta il sito
•
Selezione del colore dei testi
130
Progettazione
•
Selezione degli sfondi delle pagine
•
Selezione delle immagini per loghi, prodotti e categorie
Scopo della tesi non è quello di definire uno standard per il layout delle pagine di
Virtualmarket, scegliendo font, colori ecc… ma tentare di definire la struttura delle
pagine più importanti attraverso la modellazione UML e l’estensione WAE.
Per meglio modellare le pagine in questione c’è bisogno di sapere cosa si aspetta di
trovare un utente su un sito di commercio elettronico.
Figura 47: Use Case Diagram: Comportamento utente
Le pagine più importanti risultano essere quindi quelle che permettono di scegliere i vari
negozi che compongono il mall, di selezionarne facilmente i reparti e di visualizzarne i
prodotti in essi contenuti. Dovrà essere poi accessibile: una sezione ai servizi, una per
le FAQ e aiuti vari e poi una per la memorizzazione e modifica del proprio profilo.
131
Progettazione
Vediamo come si comporta un utente, in una tipica interazione con le pagine del mall,
descrivendo il tutto con sequence e collaboration diagram.
Figura 48: Sequence Diagram: Interazione semplice
Come si può vedere dal diagramma [fig. 48], l’utente interagisce con il mall a diversi
livelli, scegliendo dapprima un negozio, poi una categoria e infine un prodotto.
Nel prossimo diagramma [fig. 49] di collaborazione si può invece vedere meglio
l’interazione fra i vari componenti ovvero il dialogo fra l’utente e le varie pagine.
132
Progettazione
Figura 49: Collaboration Diagram: interazione semplice
Un secondo sequence diagram [fig. 50] ci può mostrare un percorso alternativo nel
quale l’utente sceglie più negozi, più categorie e più prodotti, in qualsiasi punto esso si
trovi. L’applicazione quindi dovrà permettere all’utente di poter scegliere nuovi negozi,
categorie e prodotti in qualsiasi pagina stia visitando.
Questo diagramma ci permette di vedere come le tipologie di pagine necessarie a
soddisfare la navigazione appena modellata possono essere 3: una pagina index dalla
quale è possibile agevolmente scegliere i negozi, leggendone magari una descrizione,
una pagina che contiene i prodotti di una determinata categoria e la pagina descrizione
di un prodotto.
133
Progettazione
Figura 50: Sequence Diagram: Interazione alternativa
Il seguente collaboration diagram [vedi fig. 51] ci conferma visivamente questo scenario
mostrandoci con più chiarezza le scelte effettuate dall’utente, anche mediante la
notazione 5a e 5b che esprime la possibile alternativa tra 2 eventi. Nel sequence
diagram, come implementato da Rose, questa possibilità è descritta mediante due
frecce allo stesso livello che vanno in direzioni differenti.
134
Progettazione
Figura 51: Collaboration diagram: Interazione alternativa
Il diagramma degli stati, posto nella figura 52, ci mostra quali possono essere gli stati di
un oggetto pagina, qualunque esso sia (index, categorypage, productdetail),
evidenziando anche i passi che il server web compie dalla richiesta alla visualizzazione
di una pagina server.
Figura 52: StateChart Diagram per un oggetto di tipo ‘server page’
135
Progettazione
La struttura delle pagine
Per quanto riguarda la struttura delle pagine, debbo ricordare, che il motore che le ‘
costruisce ’ è fortemente dinamico, in quanto, i principi per i quali i prodotti saranno
visualizzati sono essenzialmente 2:
•
necessità di esposizione del prodotto che deve essere assolutamente messo in
promozione,
•
stretto legame del prodotto con il profilo dell’utente.
La combinazione di questi 2 fattori permette di visualizzare i prodotti che molto
probabilmente attireranno l’attenzione dell’utente che quindi probabilmente acquisterà.
E’ chiaro che se l’utente non ha un profilo avanzato viene usato solo il grado di ‘
promozionalità ’ associato ai prodotti mostrando quindi gli articoli da pubblicizzare.
Il layout grafico di Virtualmarket rispecchia in pieno i requisiti in quanto:
•
in ogni pagina è possibile risalire ai negozi presenti nel mall,
•
ovunque ci si trovi è possibile conoscere il reparto corrente e navigare tra tutte le
categorie presenti privilegiando dapprima quelle del negozio corrente e poi le
altre,
•
in ogni pagina ci sono link ai servizi legati al prodotto/categoria che si sta
visitando (inserisci commento, segnala ad un amico ecc…) e
•
ai servizi aggiuntivi più importanti (partecipa forum, usa la chat ecc…)
La organizzazione dei reparti è essenzialmente ad albero e permette all’utente di
trovarsi in un ambiente simile a quello di un normale supermercato dove i prodotti
omogenei si trovano nello stesso reparto e reparti simili o affini si trovano vicini tra loro.
La presenza di richiami ad altri reparti sotto forma di link permette comunque di saltare
da una categoria all’altra con pochissimi click.
La struttura delle pagine, intesa come codice ASP, permette di implementare, in modo
agevole, le features dei negozi. Ricordo infatti che ogni negozio è gestito in remoto dai
propri manager mediante degli script opportuni. Attraverso questi script si possono
scegliere i prodotti/categorie da visualizzare, i metodi di spedizione/pagamento da
elencare, ma anche il tema grafico da applicare.
Questo requisito è stato soddisfatto mediante l’uso del server side include di ASP.
Infatti all’interno del file sarà presente un codice del tipo:
<%
136
Progettazione
<!--#include(caratteristica1.inc)-->
<!--#include(caratteristica2.inc)-->
‘resto del codice
<!--#include(caratteristica3.inc)-->
%>
All’interno
di
tali
files
ci
sarà
un
controllo
sul
valore
delle
variabili
di
applicazione/sessione che determinano l’abilitazione o meno di una caratteristica e con
l’aiuto del db verranno permesse determinate operazioni.
Quindi possiamo dire che in genere aggiungere nuove features significa aggiungere
nuove inclusioni di files in punti opportuni.
Vediamo come tale idea può essere schematizzata:
Figura 53: Server side include e la gestione delle features
137
Progettazione
L’operazione può essere semplificata se i file dove includerli sono relativamente pochi.
Questo è stato semplice da risolvere in quanto si è pensato di inserire tali file inclusione
all’interno dei files dei temi grafici138. Infatti, dato che tali temi sono in numero molto
minore dei negozi, attualmente i temi sono 5 e i negozi 35, basta modificare tali files per
implementare una ‘feature ’. Nel global.asa139 di ogni negozio avviene l’attribuzione, per
quel negozio, di un determinato tema, attraverso l’inclusione di alcuni file e quindi non
sarà necessario fare altro.
La tipologia delle pagine dell’applicazione VirtualMarket si può descrivere riferendosi
alle seguenti 7 categorie:
1. Home page
2. Pagina reparto intermedia
3. Pagina reparto finale
4. Pagina prodotto
5. Pagina gestione carrello
6. Pagina gestione transazione
7. Pagina gestione ordini
Home Page
Nella pagina principale (index) vengono presentati:
•
un prodotto posto al centro della pagina, scelto tra quelli legati maggiormente al
profilo utente o che il negoziante vuole assolutamente promuovere,
•
alcuni prodotti con un grado di appetibilità minore. Tali prodotti saranno
visualizzati a destra in un frame separato,
•
una lista di categorie/negozi che contengono prodotti selezionati in quanto:
1. trattasi di prodotti già acquistati,
2. oppure di accessori di prodotti acquistati,
3. oppure di prodotti collegati a eventi di nota per l’utente corrente
(anniversari, feste particolari),
4. oppure di prodotti selezionati in base alle risposte date nei form o tratte
dalla navigazione nel sito.
138
Tema grafico: insieme di immagini, font, e layout che caratterizzano un negozio rispetto ad un altro.
139
global.asa: vedi [5.3.1.1] e [6.8]
138
Progettazione
Oltre ai prodotti sono previste particolari finestre nelle quali l’utente potrà conoscere:
•
una selezione di prodotti scontati
•
una serie di servizi del sito che si vuole comunque promuovere
•
selezione di siti preparati per lui in base al suo profilo
•
notizie che possono interessarlo dei più disparati argomenti (economia, sport,
cronaca)
Dopo aver elencato quali possano essere i servizi e le informazioni da elencare nella
pagina, è risultato utile schematizzare la pagina principale attraverso un prototipo [fig.
54].
Figura 54: Prototipo dell' home page
Tale schema di pagina può essere modellata con molta efficacia e semplicità attraverso
l’UML e i diagrammi WAE.
139
Progettazione
In tutti i diagrammi che descriverò, verranno inseriti oltre che le pagine server complete
delle funzionalità e proprietà più importanti, anche delle pagine client che verranno
generate nonché dei componenti aziendali che vengono richiamati.
Purtroppo a questo livello vengono usati anche alcuni elementi del database degli utenti
che verrà descritto solo più avanti.
La maggior parte dei diagrammi descritti in questa sezione è stata inserita nel package
Presentation Logic in quanto descrivono elementi tipici delle interfacce grafiche: link,
immagini, frame, finestre, tabelle. Altri diagrammi invece sono stati posto nel package
Business Logic in quanto descrivono le entità (quasi sempre componenti COM
aziendali) che, facendo da tramite tra il DB e lo strato esterno, trasmettono i dati
formattati in maniera opportuna alle pagine ASP dell’interfaccia, le quali, si
preoccuperanno solo di visualizzarle nella maniera più opportuna. Insomma tale tipo di
struttura: strato server, strato logico e strato esterno è tipico dell’architettura 3-tier che
ho cercato di rispettare ogni qualvolta se ne fosse presentata l’occasione. Tutto ciò che
riguarda il layout della pagina è parte della Presentation Logic, tutto ciò che è
elaborazione dati o trasferimento degli stessi dal DB all’ interfaccia è Business Logic, il
resto è Server Component e quindi DB e file di configurazione del web server. In ogni
caso, in qualche diagramma si fa riferimento esplicito al componente che si preoccupa
di prelevare i dati e di elaborarli; il più importante tra questi è senza dubbio ICustomer,
descritto in seguito [vedi fig. 58]. Molte volte nei diagrammi non appare esplicitamente
nessun componente in quanto viene fatto uso dei componenti ADO connection e
recordset che si connettono e prelevano dati dal DB. Tali componenti non vengono
quasi mai citati per non appesantire i diagrammi.
In questo e nei successivi diagrammi viene descritta la pagina server che costruirà la
pagina client ma vengono anche accennate, le pagine server ivi incluse attraverso
un’associazione stereotipata con i packages che le racchiudono. Si trat ta della pagina
che disegna l’header, della pagina che visualizza l’elenco dei negozi e delle categorie,
la pagina che mostra il form per il motore di ricerca, la pagina che elenca una serie di
offerte più o meno personalizzate e della pagina che disegna il footer. La struttura
modulare della pagina rende possibile il riuso del codice (l’header è lo stesso per tutte
le pagine e quindi basta includere lo stesso codice in ognuna di esse) e semplifica il
lavoro in team in quanto si può lavorare contemporaneame nte su diversi codici senza
problema.
140
Progettazione
Tutte questi moduli sono stati inseriti in appositi packages che verranno descritti in
seguito. Descriverò in questa sezione, con dei diagrammi UML, il modulo che costruisce
l’header e quello che si preoccupa del recupero dal DB e della visualizzazione della lista
dei negozi e delle categorie.
Figura 55: Class Diagram WAE: Pagina Index
I metodi presenti all’interno della pagina server Index [vedi fig. 55] permettono di
invocare metodi presenti nei moduli esterni come quelli che riguardano il prelievo dei
dati sui negozi, dei prodotti e dei dipartimenti nonché la realizzazione del layout
dell’header e del footer. Questo è necessario in quanto dal diagramma non emergono le
funzionalità offerte dalle pagine presenti nei packages esterni.
La pagina client è composta essenzialmente da una vetrina (una tabella HTML) che
contiene la descrizione, una foto e il prezzo di un prodotto da promuovere. Ovviamente
141
Progettazione
ciò che vedrà l’utente sarà molto di più in quanto tutti i packages prima accennati
contengono pagina server che produrranno del codice html che per semplicità e
chiarezza ho lasciato e descritto all’interno dei packages stessi. Ovviamente, al termine
dell’elaborazione di questa pagine server (index.asp + i file inclusi) verrà prodotta una
sola pagina client composta dal codice html scritto da ciascuna di queste pagine.
All’interno del diagramma, sulle linee di relazione che legano le pagine con i packages,
sono stati inseriti i parametri che vengono passati da un package all’altro. Nella realtà
tali valori sono condivisi comunque in quanto trattasi di variabili session e application o
di valori presenti nella querystring della URL. Tale rappresentazione è stata necessaria,
oltre a quella di specificare lo stereotipo della relazione <<include>> per evidenziare su
quali valori tali moduli lavoreranno. Anche la presenza, all’interno della pagina
index.asp, delle proprietà di pagina: vmid, shopid e deptid, si è resa utile per
evidenziare su che tipo di variabili lavorano i metodi ivi descritti. In ogni modo, ho
dovuto legare tale oggetto con gli oggetti application, session e request per specificare
che tali valori di variabili derivano dai valori delle variabili application, session e request
del linguaggio ASP.
Il diagramma successivo [fig. 56] riguarda i file che compongono il package header.
142
Progettazione
Figura 56: Class Diagram WAE: package HEADER
Si può notare come in tale diagramma siano presenti le pagine che si occupano di
disegnare l’intestazione vera e propria compresi i menù di navigazione e i servizi one to
one ma ci sono anche riferimenti a package che contengono file da includere. Tali files
si occupano della gestione del partner intesa come rilevamento del valore del partnerID
contenuto all’interno della querystring (vedi paragrafo gestione partner 6.7.2) e della
gestione del profilo utente intesa come memorizzazione delle pagine che l’utente
corrente sta visitando.
Il diagramma successivo [fig.57] riguarda il package Shop&Department
143
Progettazione
Figura 57: Class Diagram WAE: package Shop&Department
Il diagramma [fig. 57] si riferisce alle classi del package Shop&Department che si
occupano di prelevare dal database l’elenco dei negozi, delle categorie e di
visualizzarlo, in questo caso, nella parte sinistra della pagina. Le pagine descritte che
adempiono a questo compito sono ShopList, CategoryList che prelevano dal DB, tutti i
negozi e tutte le categorie ma che possono eventualmente filtrare tale lista usando il
profilo dell’utente (verranno visualizzate solo le categorie/negozi più interessanti),
oppure usando le informazioni sulle promozioni (verranno visualizzate solo le
categorie/negozi con promozioni in corso) oppure una combinazione delle due.
Ovviamente c’è la possibilità di conoscere anche i prodotti appartenenti ad una
determinata categoria (ProductInCategory) e filtrarli in base al profilo utente o alle
144
Progettazione
promozioni. Come si può vedere, nel diagramma sono state inserite, per completezza,
anche le pagine index e i vari package coinvolti. In questo modo è possibile conoscere i
legami, attraverso link, tra le varie pagine. La classe colorata in blu rappresenta
un’interfaccia ovvero una parte del componente COM ‘Customer ’ usato per descrivere
in ogni forma il cliente mantenendo a run-time tutte le informazioni che su di esso
abbiamo. In questo modo, chiamando i metodi di tale interfaccia, è possibile risalire a
tutta una serie di informazioni che ci permettono di disegnare nel migliore dei modi le
pagine del sito.
La figura successiva [fig. 58] mostra il diagramma che descrive le entità coinvolte
dall’interfaccia ICustomer nel prelievo dei dati.
Figura 58: Class Diagram WAE: ICustomer Interface
Questo diagramma è stato inserito nel package Business Logic in quanto prelevando i
dato dal DB permette allo strato esterno della Presentation Logic di avere in maniera
‘formattata ’ i giusti dati.
Si può vedere come tra i metodi più importanti di questa interfaccia ci sono quelli che
permettono di visualizzare e modificare un profilo utente, quelli che permettono di
145
Progettazione
trovare un cliente all’interno del DB, quelli che permettono di visualizzare e modificare i
dati provenienti dai file di log, quelli di analizzare gli acquisti fatti, quelli di analizzare le
interazioni con il contact center, quelli di visualizzare il conto per i punti fidelity [vedi
6.7.1] e per finire quelli per visualizzare una serie di dati come le stringhe inserite nel
motore di ricerca, i prodotti suggeriti agli amici, i prodotti sui quali vuole essere
informato ecc…
In questo diagramma è possibile vedere come tale componente faccia uso dei
componenti ADO Connection e Recordset che permettono di accedere a DB e eseguire
query sulle sue tabelle. Sono state inserite per completezza anche gli schemi delle
tabelle coinvolte. In seguito verranno disegnate tutte le tabelle.
Come per il cliente, anche per i negozi e le categorie esistono dei componenti ad -hoc
utili per il recupero veloce dei dati. Tali componenti sono stati realizzati soprattutto per il
modulo di Shop&Departement nel quale vengono prelevate descrizioni di negozi e le
categorie ivi presenti, praticamente ogni qualvolta viene richiesta una determinata
pagina.
Come si può vedere dalla figura [fig. 59] sono presenti metodi tipici per il prelievo, dal
database, di questo tipo di dati come l’elenco dei sotto reparti di un reparto, oppure
visualizzare la descrizione di un negozio e il suo proprietario o visualizzare tutte le
categorie di un determinato negozio oppure tutti i negozi che hanno quella categoria di
prodotto come reparto.
Sono state visualizzate anche le tabelle coinvolte per facilitare la comprensione dei
meccanismi di data-retrieving.
146
Progettazione
Figura 59: Class Diagram: componenti IShop e IDepartment
Nella figura successiva [fig. 60] viene mostrato il diagramma che descrive il package
Productuseroffer
che
permette
la
visualizzazione
delle
offerte
più
o
meno
personalizzate (dipende dal grado di precisione del profilo utente) poste sulla part e
destra della pagina. La struttura della pagina è simile a quella che preleva i prodotti
all’interno delle varie categorie (ProductInCategory) con la differenza che in questa
sezione si è svincolati dal reparto che l’utente sta visitando. In sostanza, non ostante
abbia disegnato 2 diagrammi con 2 pagine server diverse, buona parte del codice ivi
presente è lo stesso. Viene cambiato il codice della query e la disposizione grafica del
risultato.
Ovviamente se l’utente si trova in una pagina descrittiva del prodotto le ‘vetrine
promozionali’ sul lato destro avranno un’importanza minore per non distogliere troppo
l’attenzione dell’utente. Saranno presenti solo piccoli richiami ai lati della pagina.
147
Progettazione
Figura 60: Class Diagram WAE: ProductUserPackage
Pagina Reparto
Rappresenta il contenuto di un determinato reparto che può consistere in prodotti ma
anche sotto-reparti.
Nel caso in cui non ci siano più sottoreparti da mostrare, non viene visualizzata la lista
delle categorie ma solo i prodotti ivi contenuti. Lo schema di questa tipologia di pagina
riflette quello precedente con la differenza che mancano, come è ovvio, le sotto
categorie. C’è una maggiore enfasi per i prodotti ivi contenuti e si cerca di non
distogliere l’utente da eccessivi richiami esterni ed estranei alla navigazione. Se l’utente
è arrivato fin qui probabilmente è molto interessato a ciò che sta leggendo e quindi si è
cercato di non inserire troppi elementi di disturbo.
Di seguito viene mostrato [fig. 61] il prototipo di una pagina reparto e la sua
modellazione in UML [fig. 62].
148
Progettazione
Figura 61: Prototipo Pagina Reparto
Figura 62: Class Diagram WAE: Pagina Reparto
149
Progettazione
In questo diagramma possiamo vedere come i metodi
RetrieveSubDept() e
RetrieveProduct() servano a prelevare tutte le eventuali sotto-categorie della categoria
selezionata , tutti i prodotti ivi presenti, o una selezione di essi se di numero elevato.
Per quanto riguarda la pagina html creata, essa è essenzialmente composta da una
vetrina che contiene 6 prodotti comprensivi di nome, descrizione, fotografia, prezzo e un
link alla pagina con la descrizione completa.
Pagina Prodotto
Nella pagina descrittiva di ogni prodotto vengono ridotti all’osso tutti gli elementi di
disturbo e si enfatizzano le informazioni sul prodotto che possono spingerlo ad
acquistarlo.
Tali informazioni possono essere sia descrittive del prodotto che legati a servizi utili ad
aiutarlo nella scelta.
Le descrizioni del prodotto ne dettagliano le caratteristiche ma riguardano anche il
prezzo, eventuali sconti, promozioni e la disponibilità.
I servizi invece riguardano:
•
lettura dei commenti che altri utenti hanno lasciato sul prodotto
•
lettura di commenti scritti da terze parti (gestori del negozio, commenti editoriali,
altro)
•
scrittura dei propri commenti
•
visualizzazione di una valutazione sintetica del prodotto
•
possibilità di suggerire il prodotto via email o sms ad un amico
•
visualizzazione dei prodotti simili o legati a quello corrente
•
visualizzazione dei prodotti che gli utenti hanno acquistato assieme a quello
corrente
Insomma le possibilità di personalizzazione del sito sono notevoli e mai invasive nel
senso che in una pagina i punti di interesse principale non sono più di un paio, mentre
gli altri riferimenti che possono attirare l’attenzione del visitatore non sono mai più di 5.
Il modo in cui tali finestre sono state disposte esula dagli scopi della tesi.
150
Progettazione
La figura successiva [fig. 63] mostra lo schema di una tipica pagina prodotto.
Figura 63: Schema Pagina Prodotto
La figura successiva [fig. 64] mostra il diagramma UML che descrive una pagina
prodotto e i suoi componenti.
151
Progettazione
Figura 64: Class Diagram WAE: Pagina Prodotto
Si può notare come siano presenti, oltre ai package già descritti alcune nuove entità.
La pagina server ProductDetailPage serve semplicemente a prelevare tutti i dettagli del
prodotto prescelto, comprese le opzioni e a mostrarli a video. Questo prelievo viene
effettuato mediante l’interfaccia IProduct descritta nel paragrafo successivo [fig. 65].
Il metodo UpdatePrice() serve a aggiornare il prezzo qualora l’utente scelga il prodotto
con un’opzione con sovrapprezzo. Tale metodo viene invocato automaticamente
quando viene scelta una nuova opzione.
Viene così costruita la pagina ClientProductDetail costruita essenzialmente da un form
con il quale si può scegliere di acquistare, di richiedere informazioni ulteriori e un form
152
Progettazione
per la scelta delle opzioni. Queste 2 eventualità sono state descritte dalle pagine Basket
e RequestProductInfo. Per meglio comprendere tale diagramma sono state inserite
alcune delle tabelle SQL coinvolte.
Abbiamo visto come importante siano state in precedenza le interfacce dei componenti
Customer, Dept e Shop. Adesso descrivo brevemente l’interfaccia IProduct in quanto è
stata introdotta esplicitamente per la prima volta in questo paragrafo.
Figura 65: Class Diagram: Interfaccia IProduct
Si può notare come attraverso il componente IProduct si possono prelevare
informazioni essenziali oltre alla semplice descrizione del prodotto. Riguardo un
prodotto si possono gestire dati riguardanti:
153
Progettazione
•
tutti gli utenti che lo hanno acquistato,
•
tutti i commenti su di esso ,
•
tutti gli sconti ad esso relativi,
•
tutti gli utenti che ne hanno richiesto informazioni,
•
tutti gli utenti che ne hanno visitato la pagina,
•
tutte le promozioni e le impression mediante banner o mediante le icone del
Punti Fidelity Program,
•
tutte le parole chiave,
•
tutti i carrelli che lo contengono,
•
tutte gli interventi al contact center che ne parlano.
Riepilogando, possiamo racchiudere nel prossimo diagramma delle attività, i passi e
quindi le attività che un utente compie sul mall visitando le varie pagine.
Figura 66: Activity Diagram: Interazione uomo-mall
154
Progettazione
Pagina gestione transazione (carrello, scelta spedizione e pagamento)
Per spiegare meglio cosa si aspetta di trovare un utente durante la fase di acquisto del
prodotto che ha selezionato dal catalogo, possiamo descrivere un elenco di funzionalità
da realizzare, per metterlo in condizione di terminare la transazione. Quello che si può
dire è che serve un supporto per la scelta delle quantità di prodotto da acquistare, la
scelta delle opzioni disponibili con conseguente aggiornamento del prezzo espresso in
diverse valute, la scelta di un metodo di spedizione e di pagamento e infine un supporto
che permetta l’utente di inserire in modo sicuro gli estremi della carta di credito [fig. 67].
Figura 67: Use Case Diagram: transazione commerciale
155
Progettazione
Pagina gestione carrello
Per spiegare adeguatamente come deve essere realizzata una pagina di gestione del
carrello bisogna dapprima descrivere uno scenario tipico in cui l’utente dopo aver
visitato alcune pagine sul sito, inserisce uno o più prodotti nel carrello, ne modifica la
quantità e ne salva il contenuto. Bisogna prevedere anche che il carrello possa essere
prelevato in seguito e che quindi i prodotti ivi contenuti possano essere eliminati
dall’utente e che, in caso di mancata disponibilità del prodotto, venga visualizzato un
messaggio in cui si avverte che un determinato articolo non può restare nel carrello in
quanto non è più disponibile.
Figura 68: Sequence Diagram: gestione carrello
Come si può osservare dal sequence diagram appena visualizzato, un utente, nel
momento che decide di acquistare il contenuto del carrello, termina di gestirlo e passa
156
Progettazione
alla scelta del metodo di spedizione e del metodo di pagamento, i quali, verranno
descritti in seguito.
La successiva immagine descrive il diagramma a oggetti relativo alla pagina di gestione
dei carrelli.
Figura 69: Class Diagram WAE: gestione del carrello
Come si può osservare dal diagramma a oggetti, attraverso la pagina server Basket si
possono invocare i metodi di eliminazioni prodotto, modifica quantità, cambio valuta
ecc…
157
Progettazione
Tale pagina server costruirà una pagina client costruita essenzialmente da un form per
l’inserimento della quantità, visualizzazione dettaglio del prodotto ecc… ma anche dalla
lista delle possibili valute e dai bottoni di salvataggio e caricamento dei precedenti
carrelli.
La struttura del database dei carrelli verrà descritta in seguito [fig. 82] ma posso
visualizzare il diagramma delle attività relativo all’interazione che l’utente ha con il
carrello.
Figura 70: Activity Diagram: Gestione del carrello
Si può notare come il passo successivo sia quello della scelta del metodo di spedizione.
Pagina scelta metodo di spedizione e pagamento
158
Progettazione
Sia la pagina della scelta del metodo di spedizione che il metodo di pagamento
possono essere descritti con un solo diagramma a oggetti in quanto sono molto simili
[fig. 71].
Figura 71: Class Diagram WAE: scelta metodo di pagamento
Quello che si può affermare è che, in entrambi i casi, prima di visualizzare la lista dei
possibili metodi di pagamento o di spedizione, viene analizzato il profilo utente e
mediante il metodo RetrievePaymentMethod() e RetrieveShippingMethod(), che ha
come parametro l’ID utente, si può stabilire con certezza quali metodi sono applicabili
all’utente corrente. Abbiamo già descritto infatti che ogni utente può avere una
personalizzazione anche nei modi in cui può pagare un bene o come può farselo
spedire in base al suo grado di affidabilità. La presenza di tabelle come
Stores&Payment e Stores&Shipping permette di sapere in ogni negozio e per ogni
utente i tipi di spedizione e pagamento amme ssi e quindi di visualizzare solo questi.
159
Progettazione
Nel diagramma [fig. 71] è stata anche descritta la pagina che viene visualizzata dopo
l’immissione dei dati della carta di credito, in quanto, prima di accettare un pagamento
via carta di credito, i dati inseriti dall’utente (nome, scadenza e numero carta) vengono
validati in SSL da un gateway di pagamento esterno al mall. L’avvenuta autenticazione
viene resa visibile con una pagina di risposta la quale memorizza anche gli estremi del
pagamento nella tabella opportuna che verrà descritta meglio nel paragrafo delle
vendite.
Figura 72 Activity Diagram: Scelta tipo spedizione e pagamento
6.6.1.3Motore di ricerca e categorizzazione
Per quanto riguarda il motore di ricerca interno è stato deciso di puntare molto sul
ranking dei prodotti, ranking che può essere stabilito in base a delle parole chiave, alle
promozioni in atto, al grado di interesse espresso dagli utenti verso quel prodotto.
160
Progettazione
Figura 73: Class Diagram Data Modeler: Motore di ricerca
Nel diagramma appena visualizzato si possono notare tutte le tabelle coinvolte per la
categorizzazione dei prodotti. La tabella degli sconti (Discounts) e delle promozioni
(PromotedArticles140) ci permettono di mostrare nei primi posti di un tipica lista di output
del motore di ricerca, i prodotti che ci interessa vendere in maggior quantità. La tabella
ProductInfoRequest (memorizza i prodotti dei quali determinati utenti desiderano
conoscere particolari e iniziative promozionali a loro legati), la tabelle Comments e
SuggestedProduct (memorizzano i commenti degli utenti e i prodotti suggeriti mediante
sms o email ad amici/parenti) esprimono il grado di interesse di determinati articoli e
quindi, sfruttando tale valore, li si può spingere in alto in tale lista. Infine la tabella
Key_and_Product permette di associare ad ogni prodotto una o più parole chiave in
140
Ricordo che tale tabella memorizza i prodotti che sono in promozione.
161
Progettazione
modo da categorizzare 141 meglio il prodotto stesso e quindi rendere più efficace il lavoro
del motore di ricerca.
La gestione del motore di ricerca interno richiede, quindi, la presenza di una serie di
parole chiave da associare ai singoli articoli ma anche la possibilità di ‘pilotare’ l’output
del motore usando delle priorità.
Supponiamo infatti di elencare delle keyword come colore, dimensione e walkman.
Queste keyword saranno associate ad articolo di un certo negozio e se si volesse
privilegiare durante la visualizzazione dell’output un articolo piuttosto che un altro si
userà una priorità per quel record. In questo modo se un ‘negoziante’ vorrà far apparire
il suo prodotto in alto, nella lista, basterà usare questo valore per stabilire l’ordine di
visualizzazione.
Per quanto riguarda la gestione del motore di ricerca il discorso si semplifica in quanto
esiste una sola tabella che racchiude sia i prodotti che le keywords unite ad un valore
intero che specifica la priorità da attribuire ad una tripla: negozio, articolo, parola chiave.
Il lavoro di ricerca viene svolto da un componente descritto in seguito 142,
SearchEngineComponent che pone in una tabella T_SearchEngineWords le parole
inserite nel form di ricerca al fine di conoscere i prodotti più cercati dagli utenti. Si è
pensato di tenere traccia di tutte le ricerche in termini di parole inserite nel form,
aggiungendo un riferimento alla tabella degli utenti (T_PcLog) che ci potesse aiutare
per l’identificazione dell’utente, la data in cui tale ricerca è stata effettuata e il riferimento
del negozio dal quale tale ricerca è partita.
141
una forma di categorizzazione è data anche dall’appartenenza del prodotto ad una o più categorie/reparti
142
vedi [fig. 74], [fig. 75]
162
Progettazione
Figura 74: Class Diagram: Componente SearchEngine
Per quanto riguarda la descrizione del form di ricerca e come questo interagisca con il
componente appena descritto basta leggere il diagramma posto in seguito.
163
Progettazione
Figura 75: Class Diagram WAE: Search Engine Script
6.6.2 Back end
6.6.2.1Sistema di gestione degli ordini
I requisiti su ciò che va memorizzato nel database, in seguito ad una transazione
commerciale, sono molto vincolanti, basandosi molto sui dati che una normale attività
commerciale può richiedere per analizzare successivamente l’andamento delle vendite.
Attraverso tali informazioni si deve poter permettere al manager di poter seguire
l’andamento delle vendite e all’utente di poter controllare lo stato del proprio ordine in
maniera semplice e chiara.
Gli ordini e le spedizioni
Per quanto riguarda i dati degli ordini da memorizzare posso anticipare che, attraverso
questi dati, sia il manager che l’utente, deve poter conoscere con esattezza i dettagli dei
164
Progettazione
propri acquisti in termini di prodotti, estremi pagamento, tipologia di spedizione nonché
stato dell’ordine come visualizzato in [fig. 76].
Figura 76: Use Case Diagram: Visualizzazione stato ordini
Ciò che serve è un numero d’ordine unico tramite il quale sia possibile risalire al
dettaglio della vendita in termini di quantità e descrizione dei vari articoli, prezzo al netto
di tasse e sconti, prezzo complessivo, l’indirizzo di spedizione e i dettagli del
pagamento. Tutti questi dati devono restare nel db anche in seguito a eliminazione di
prodotti dalla vetrina o dal catalogo, cancellazioni dei clienti o degli spedizionieri. Si
deve trovare quindi un modo per denormalizzare la base di dati portandoci dietro i
dettagli dei prodotti. In questo modo, sebbene sia possibile risalire all’entità degli sconti
e delle caratteristiche dei prodotti non più a catalogo usando le relazioni e le chiavi
esterne (per scelta progettuale i record non vengono mai cancellati ma viene settato lo
stato di quelli che si devono eliminare con il valore ‘ cancellato ’) si è pensato di
velocizzare il processo di recupero dati con il mantenimento di queste informazioni in un
altro database, quello delle vendite appunto, che rappresenta quindi un archivio di
informazioni storicizzate e statiche. Una volta che un prodotto è stato venduto a
165
Progettazione
determinate condizioni, tutti i dettagli ad esso relativi vengono memorizzati nel
database.
I valori da memorizzare possono essere facilmente descritti nel seguente diagramma
delle classi derivato dalla fase di analisi [fig. 77].
Figura 77: Class Diagram iniziale vendite
Il diagramma [fig. 77] ci dice come le varie entità sono collegate. In realtà le
trasformazioni da modello a oggetti a modello entità-relazioni e i successivi affinamenti
mi permettono di descrivere il database delle vendite definitivo nel seguente
diagramma.
166
Progettazione
Figura 78: Class Diagram Data Modeler: Vendite
Si può notare in questo diagramma come vengono gestiti gli ordini e le spedizioni: da
una parte c’è una tabella Order che memorizza semplicemente l’id del cliente, la data
dell’ordine e lo stato dell’ordine (evaso, nuovo, in evasione, annullato ecc…) e un id
dell’ordine che viene creato in modo univoco dal gestore degli ordini. Tale tabella viene
collegata mediante chiavi esterne alla tabella dei dettagli degli ordini OrderDtl e
OrderDtlOther, create semplicemente per snellire le operazioni di recupero dei dati
separando le informazioni più importanti e di frequente accesso da quelle che
167
Progettazione
aggiungono solo dettagli. In tali tabelle vengono memorizzate informazioni sugli sconti
praticati, sui punti acquisiti dal cliente in seguito all’acquisto, sulla data di spedizione e
di consegna del prodotto, sulla data del pagamento nonché sui dettagli del pagamento,
il tipo e il numero del corriere e infine le righe d’ordine, cioè i dettagli sul prezzo, le
quantità e le descrizioni degli oggetti acquistati.
La molteplice e differenziata presenza dei dati relativi agli sconti è utile in quanto,
prevedendo un’alta quantità di offerte mirate e personalizzate, si è ritenuto necessario
memorizzare quante più informazioni possibile su tali iniziative, per analizzare, in
seguito, l’influenza della presenza di uno sconto sull’andamento delle vendite.
Sono state inserite in questo diagramma le tabelle delle spedizioni e dei pagamenti
(Shipping e Payment). Per quanto riguarda le spedizioni possiamo dire che una tabella
memorizza l’indirizzo presso il quale sarà inviata la merce che necessariamente non
deve essere l’indirizzo del compratore, il quale, può considerare l’articolo acquistato, un
regalo e quindi farlo recapitare ad una diversa destinazione.
La tabella Shipping riepiloga i dati della spedizione (può verificarsi anche l’eventualità
che un ordine composto da più righe d’ordine venga evaso in tempi diversi). La chiave
primaria è rappresentata dalla coppia Shippingnumber e OrderDtlID in quanto per un
ordine è possibile avere più spedizioni. Vengono memorizzate anche le date di
spedizione e la data prevista e quella effettiva di arrivo. La presenza di un valore atteso
e quello effettivo rende possibile una stima dell’affidabilità di un corriere piuttosto che di
un altro in base al rispetto dei tempi di consegna. Vi è poi un riferimento sulla tariffa
applicata per la spedizione in quanto ogni corriere può avere tariffe differenziate e su
una tabella descritta nel diagramma dei corriere vi saranno tutte le tariffe applicate.
Con i due diagrammi successivi mostro l’avanzamento dello stato di un ordine durante
tutta la sua ‘vita’ [fig. 79] e le attività da seguire durante la visione dei dettagli di un
ordine [fig. 80].
168
Progettazione
Figura 79: StateChart Diagram: istanza della classe Order
169
Progettazione
Figura 80: Activity Diagram: Visualizzazione Ordine
Il carrello
Riguardo i requisiti della gestione dei carrelli viene richiesto che l’utente possa salvare il
contenuto del suo carrello per poi caricarlo e modificarlo a suo piacimento in tempi
successivi. L’eventualità che un utente possa salvare un ca rrello e riaprirlo a distanza di
mesi mi obbliga a dotare questo database di meccanismi attraverso i quali fosse
possibile risalire a tutta la storia datata di uno shopping-cart in termini di operazioni
effettuate su di esso (‘nuovo’, ‘inserisci prodotto’, ‘salva’, ‘carica’, ‘modifica contenuto’,
‘cancella’, ‘acquista’) e del suo contenuto che nel tempo avrebbe potuto dare dei
problemi. Cosa fare infatti qualora l’utente aprisse un carrello salvato mesi prima e il
suo contenuto fosse non più disponibile perché ormai fuori catalogo? In termini
progettuali è sconsigliabile l’ipotesi di legare tale carrello, via chiavi esterne, al database
dei prodotti proprio perché in caso di modifica delle caratteristiche di uno di essi
170
Progettazione
(prezzo, offerte promozionali) la base dati non sarebbe più coerente. Si è pensato così
di inserire tutti i dettagli dei prodotti scelti così come l’utente li seleziona dal sito
soddisfacendo anche il requisito dell’efficienza (non c’è bisogno di effettuare join
laboriosi con le tabelle dei prodotti).
Il diagramma mostrato in [fig. 81], derivato dalla fase di analisi mostra le varie tabelle
coinvolte e le loro relazioni.
Figura 81: Class Diagram iniziale: Carts
Il diagramma in [fig. 82] mostra il diagramma delle classi finale, dopo tutti gli affinamenti
eseguiti nel progetto di sistema e degli oggetti.
171
Progettazione
Figura 82: Class Diagram Data Modeler: Carts
Il diagramma mette in luce la presenza di una tabella di tutti gli articoli comprensivi di
descrizione, prezzo, e sconti ad esso applicati ArticlesinCart.
La solita tabella degli stati Status provvede a mantenere tutti i possibili stati che un
carrello può avere.
La tabella CartHistory con chiavi primarie CartID, ActionID e OptionarticleID serve a
tracciare la storia di un carrello dalla creazione alla sua distruzione in termini di
operazioni datete, eseguite su un determinato carrello, riguardo determinati prodotti. Il
campo action, proveniente dalla tabella TypeOfAction, descrive l’azione che l’utente ha
intrapreso sul carrello in un determinato momento (salva, carica, elimina, modifica
quantità, cancella). Risulta evidente quanto importante possa essere l’analisi dei vari
carrelli a fini di esplorazione delle attività degli utenti per carpirne i desideri ed
172
Progettazione
invogliarne l’acquisto se talli carrelli restano non venduti tramite iniziative di marketing
riservate ai prodotti presenti nel carrello.
Infine c’è la tabella Carts che memorizza l’utente che ha creato il carrello, la password
richiesta ogni volta che vorrà ricaricare il carrello, lo stato del carrello e lo sconto che
l’utente aveva nel momento in cui il carrello è stato salvato l’ultima volta.
Il diagramma succesivo [fig. 83] mostra gli stati possibili di un’istanza della classe Carts
durante l’interazione con il cliente.
Figura 83: StateChart Diagram: istanza della classe Carts
I corrieri
Per quanto riguarda i corrieri, le specifiche richiedono che si debba mantenere un
database di tutti i listini dei vari corrieri che ovviamente possono fornire prezzi
diversificati in base al costo del prodotto, le dimensioni e la destinazione. Un’ulteriore
complicazione deriva dal fatto che è difficile mantenere un database di tutte le possibili
173
Progettazione
destinazioni. Se per esempio un corriere ha un listino per le spedizioni all’interno della
regione, un altro per le destinazioni nazionali, un altro per quelle all’interno dello stesso
continente è chiaro che risulta difficile calcolare la spesa per una spedizione
direttamente dalla pagina web ma è altresì chiaro che questo requisito deve essere
soddisfatto dal cliente per una maggiore chiarezza nei rapporti: venditore -consumatore.
Figura 84: Class Diagram iniziale: Courier
La soluzione implementata vedi [fig. 85] è quella di creare diverse tabelle con tutte le
destinazioni previste dai corrieri: Continent, Country (Italy, Usa), State (Virginia, Lazio),
e City. Qualora un cliente inserisca nel form riguardante i dettagli della spedizione, una
città non presente nella tabella city, il sistema cerca, nella tabella State, un riferimento
alla regione indicata dall’utente. Se anche questa ricerca
desse esito negativo si
passerebbe alla nazione e così via. Il motivo di questa scelta è dovuto alla provenienza
italiana dei prodotti venduti. In questo modo, considerando l’alta percentuale di clientela
italiana, si adottano e privilegiano corrieri con tariffe particolareggiate per l’Italia
(vengono memorizzate anche le regioni nella tabella State) scegliendo una scala di
dettaglio continente-nazione-regione-città, mentre per le nazioni estere, il livello di
dettaglio va da continente-nazione-città. Quindi per le destinazioni italiane e europee in
genere, nella tabella State ci saranno le regioni (in Country ci sarà il nome dello Stato),
per le destinazioni americane ci saranno i nomi dei singoli Stati (in Country ci sarà
‘USA’), mentre per tutte le altre destinazioni si passerà dal nome dello stato contenuto
in Country al nome della città contenuto in City.
174
Progettazione
Attraverso 2 campi, ProductCostMin e ProductCostMax, si gestisce l’eventualità che un
corriere abbia una stessa tariffa, sia se il prodotto sia costato 5000 che 10000 lire. Più
importante è la distinzione fra i vari tipi di peso. Riguardo ciò è stata fatta una tabella
CostbyDimension
che
tramite
2
chiavi
secondarie
in
FareCodeName,
DimensionRangeIDMin e DimensionRangeIDMax, aiuta a distinguere le tariffe in base
alla dimensione minima e massima che un articolo può assumere. Una tabella
riepilogativa dei corrieri, Courier, in relazione molti a molti con la tabella di tutte le tariffe
crea una nuova tabella FareCodeName che contiene corriere per corriere tutte le tariffe
da esso applicate. In questo modo sarà molto semplice offrire al cliente la migliore
tariffa disponibile al momento in base ai dati del prodotto da lui acquistato (dimensione
e prezzo) e ai dati circa la destinazione.
Figura 85: Class Diagram Data Modeler: Courier
175
Progettazione
6.6.2.2Sistema di gestione delle transazioni
Per ciò che riguarda le transazioni economiche bisogna dire che la mia scelta è stata
quella di supportare il pagamento con contrassegno, bonifico e carta di credito. Mentre
per i primi due sistemi di pagamento non ci sono particolari problemi per il terzo bisogna
scegliere se ospitare fisicamente, all’interno del mall, un gateway di pagamento che
autenticasse e validasse i dati dei possessori di carta di credito o facesse riferimento ad
un gateway esterno presso un ente certificato. La mia scelta è ricaduta sulla seconda
opzione in quanto ciò ci solleva dalle enormi responsabilità di progettare, realizzare e
testare un sistema di autenticazione che comunque non rientra nel core business
dell’azienda. Tutto questo implica che nel momento in cui un utente decide di pagare
con carta di credito attraverso SSL o SET (dipende dal circuito scelto) viene direzionato
presso un gateway esterno situato all’interno dei sistemi informativi di una banca che
provvede a validare i dati immessi (nome titolare, data scadenza e numero carta di
credito). Se i dati corrispondono la transazione va a buon fine altrimenti viene
visualizzata una pagina di errore.
Un’ultima menzione va fatta per i modi e i tempi con i quali un utente effettua un
pagamento. I pagamenti possono avvenire anche in tempi diversi (pag amenti rateali) e
con metodologie diverse (carta di credito, bonifico, contrassegno etc…). Serve un
meccanismo che tenga conto di tutte queste eventualità e che tracci nel tempo tutte le
transazioni economiche. Dato che il sistema non deve supportare un ga teway di
autenticazione delle transazioni economiche interno ma appoggiarsi alle varie banche
affiliate al nostro sito le uniche cose che si devono tracciare sono:
•
un codice di autenticazione della transazione speditoci dalla banca,
•
la data del pagamento (chiave primaria),
•
l’id dell’ordine (chiave primaria),
•
il mezzo con cui si è pagato,
•
il valore,
•
la valuta.
176
Progettazione
Figura 86: Class Diagram: particolare tabella pagamenti
6.6.2.3Catalogazione degli utenti
Modulo Profili utente
La modellazione dei profili utenti prevede che ogni utente (sarebbe meglio dire ogni pc)
venga riconosciuto attraverso un cookie e che tale riconoscimento venga validato nel
momento in cui tale utente si identifica. Tutte le informazioni prelevate in questa fase
sono fondamentali per poter creare e modificare nel tempo un profilo di comportamento
dei nostri utenti.
Attraverso una parte manager di tale sezione si possono conoscere utente per utente
vedi [fig. 87]:
•
le pagine visitate,
•
la durata della visita,
•
la frequenza,
•
le pagine di ingresso,
•
le pagine di uscita,
•
l’indirizzo di provenienza,
•
la parole ricercate sul motore di ricerca interno,
•
i prodotti scelti,
•
quelli acquistati,
•
i carrelli salvati,
•
i suggerimenti dati agli amici,
•
i commenti lasciati sui prodotti/servizi,
•
le richieste di informazione su prodotti/servizi,
177
Progettazione
•
la partecipazione a chat e forum,
•
la partecipazione a giochi/iniziative promosse dal mall,
•
le risposte ai test,
•
i prodotti resi o oggetto di lamentela
Figura 87: UseCase Diagram: User data analysis
Da questo Use Case diagram emerge quali siano le entità da trattare al fine di
realizzare un’analisi completa. Ma per poter trattare questi dati, bisogna dapprima saper
riconoscere l’utente all’atto di una sua nuova visita, aggiungendo quindi nuove
informazioni al profilo già memorizzato. Possiamo quindi affermare che le fasi di una
profilazione utente sono essenzialmente 3:
•
registrazione,
•
riconoscimento,
•
analisi dati.
178
Progettazione
Per quanto riguarda la registrazione, le informazioni importanti da richiedergli sono,
oltre a quelle demografiche e anagrafiche, informazioni su hobbies e interessi,
composizione del nucleo familiare e in che modo è venuto a conoscenza del sito.
La gestione degli utenti deve permettere un alto grado di interattività c on essi grazie ad
una elevata conoscenza delle loro abitudini, nonché dei loro hobbies e delle trascorse
interazioni sul sito. Bisogna quindi prevedere degli archivi per i dati anagrafici, archivi
per i dati riguardanti le visite e gli archivi che mantengano le risposte ai vari quesiti che
vengono posti loro abitualmente. Bisogna gestire anche l’archiviazione di tutti i contatti
che avvengono tra il mall e l’utente stesso.
Può essere interessante anche offrir loro, una serie di servizi come la possibilità d i
registrarsi a delle mailing-list (si possono capire i reali interessi), offrire la possibilità di
usare chat e forum per dialogare con il servizio clienti o con gli altri utenti, nonché
proporre delle iniziative promozionali di benvenuto.
La specifica dei requisiti richiede che ci sia un’attenzione particolare per i dati che ogni
navigatore può fornire in modo diretto o indiretto durante la navigazione: pagine,
prodotti visitati, tempo di permanenza in una pagina, pagina di ingresso e pagina di
uscita, frequenza di visita. Inoltre bisogna evitare che siano tracciati gli accessi da parte
dei motori di ricerca che avrebbero sfalsato questo tipo di reporting. Per accentuare la
validità dei risultati è richiesto di porre un cookie nel browser del visitatore in modo che i
dati aggregati delle varie visite possano accrescere la mole di informazioni. Bisogna
porre un’attenzione particolare alla sicurezza e alla coerenza dei dati stessi in quanto
un determinato navigatore può spacciarsi per un altro.
Una prima soluzione è quella di poter creare degli agenti che analizzino i log del server
web (allo stato attuale delle cose è IIS4) ma la possibilità che i server web possano
essere cambiati nel tempo e quindi anche il formato dei log con conseguente riscrittura
dell’agente ci ha convinto di inserire del codice all’interno di ogni singola pagina web
che scrive nelle tabelle opportune solo le informazioni che desideriamo.
179
Progettazione
Figura 88: Class Diagram iniziale: Database Utenti
All’atto della registrazione viene scritto, posto che sia possibile, un cookie sulla
macchina dell’utente i cui valori vengono memorizzati nella tabella T_ PcLog, mentre le
pagine visitate vengono memorizzate nella tabella T_PagineLog vedi [fig. 92].
180
Progettazione
Figura 89 Class Diagram Data Modeler: database utenti
I dati della tabella T_Member saranno quindi: email e password, una domanda con
risposta per il recupero della password, lo sconto utente, il tipo di utente (utente
semplice, manager, partner, ecc…), il nome della compagnia di cui fa parte. Nella
tabella T_Interests verranno memorizzati, all’atto della registrazione, gli interessi e
hobbies dell’utente. Nella tabella T_MailingList verranno inserite le mailing list a cui
l’utente è iscritto ma anche la data di iscrizione, di cancellazione e il motivo della
cancellazione. Nella tabella T_MoreaboutMember ci saranno i dati riguardanti l’indirizzo
e il telefono mentre in T_AdditionalAddress un’eventuale recapito alternativo. In
T_Demographics ci saranno dati come il sesso, il numero di componenti familiari, l’età e
181
Progettazione
la professione. In T_VMCStore ci saranno i giudizi che del sito, l’utente da all’atto della
registrazione più un’indicazione di come vi è venuto a conoscenza.
Una volta registrato, l’utente è libero di navigare nel sito e di ritornarvi senza dover
rispondere nuovamente a domande sulla propria età o sul proprio nucleo familiare. Se il
browser dell’utente ha i cookie abilitati, egli verrà riconosciuto (quantomeno viene
riconosciuto il pc con il quale l’utente si è collegato), e quindi si possono aggiornare una
serie di tabelle sapendo che si tratta di un vecchio utente. Dato che la certezza che si
tratti proprio di lui non si può avere, (si può trattare di un pc in un Internet Cafè e quindi
usato da gente molto diversa tra loro) viene chiesto di identificarsi al momento
dell’inserimento del primo prodotto nel carrello. Come viene gestito il riconoscimento
dell’utente e quali sono le tabelle coinvolte?
Dai prossimi diagrammi [fig. 90], [fig. 91] si può vedere come, prima di leggere il
contenuto di una pagina, l’utente sia stato già riconosciuto tramite dei metodi invocati
all’interno del file global.asa e che i dettagli della pagina visitata siano inseriti in
un’opportuna tabella (T_PagineLog). Dopo tutto questo vengono invocati i metodi per il
recupero dei dati sui negozi, sulle categorie e sui prodotti e quindi per la visualizzazione
completa della pagina.
182
Progettazione
Figura 90: Sequence Diagram: Interazione lato server
Figura 91: Collaboration Diagram: Interazione lato server
183
Progettazione
La classificazione degli utenti ha seguito il principio per cui ogni utente registrato
dapprima è un utente normale cioè di cui non disponiamo di un profilo certo, del quale
possiamo tracciarne l’attività tramite cookies e l’analisi dei log. In effetti, nel momento in
cui l’utente visita per la prima volta il nostro sito riceve dal sistema un cookie che fa si
che, nelle visite successive, egli stesso (per la precisione il pc) venga riconosciuto. Tutti
i dati della navigazione vengono posti nel database utenti il cui schema è descritto nel
successivo diagramma delle classi di [fig. 92].
Figura 92: Class Diagram Data Modeler: database utenti
La scelta effettuata prevede la realizzazione di ben 4 tabelle che consentono al sistema
di memorizzare sia la provenienza in termini di indirizzo web e dello user-agent del
visitatore, nonché il negozio e le pagine in esso contenute che il cliente visita.
La tabella T_PcLog, in particolare, memorizza nel campo browser la stringa user-agent
che identifica il navigatore usato, nel campo ip_address l’indirizzo web del visitatore
mentre in sessionid si memorizza una stringa generata dal server web che ha la
proprietà di essere unica in quel momento per tutti i visitatori del sito. Attenzione
particolare merita il campo pcid che assume lo stesso valore di pclogid quando l’utente
non è stato riconosciuto correttamente mediante cookie altrimenti assume il valore
trovato nel cookie. In sostanza la prima volta che un utente visita una pagina del sito gli
viene inviato un cookie nel quale è memorizzato il valore pclogid del record che
184
Progettazione
descrive tale visita. Successivamente, in una sessione distinta, viene letto tale valore
dal cookie e quindi se risulta valido viene scritto nel campo pcid del nuovo record della
tabella T_PcLog che descrive appunto questa nuova visita. Ho parlato di validità del
valore contenuto del cookie. In realtà è stata posta particolare attenzione al fatto che
l’utente possa cambiare manualmente e intenzionalmente tale valore. Per evitare ciò,
nel cookie viene inserita una coppia di valori, un indice della tabella T_SessionTbl e un
valore di tipo uniqueidentifier143 chiamato guid memorizzati assieme al pcid
nella
tabella T_SessionTbl. In tal modo non appena l’utente visita la prima pagina sul nostro
sito, viene letta questa coppia di valori dal cookie e se corrisponde ad una coppia valida
in tale tabella allora l’utente non avrà manomesso alcunché e si procederà al prelievo
del valore pcid che sarà poi inserito nel nuovo record in T_PcLog appena immesso 144.
Figura 93: StateChart Diagram: stati di uno scenario tipico utente-mall
143
una variabile di tipo uniqueidentifier è un valore a 32 bit generato partendo dal valore di MAC ADDRESS della
scheda di rete ed è unico per tutti gli utenti connessi ad Internet.
144
vedi paragrafo [5.3.1.1] e [6.8] e [fig. 92] e [fig. 93].
185
Progettazione
Il campo shopid serve per identificare il negozio visitato in modo da rendere più veloce
l’analisi dei log.
La tabella T_PagineLog contiene tutti i nomi delle pagine visitate, i tempi di visita,
nonché i referrer e le querystring di una sessione-utente. Dall’analisi di questi dati è
possibile risalire ai prodotti che interessano più l’utente o intere categorie e quali sono le
pagine visitate più di frequente. Tali analisi sono molto più importanti delle risposte che
l’utente stesso può dare nei form in quanto le sue risposte possono sempre essere
falsate. In questo modo possiamo sapere quasi con certezza quali articoli o categorie di
prodotto interessano più l’utente anche se non effettua nessun acquisto. In questo
modo è possibile proporgli delle offerte mirate e personalizzate solo per quel prodotto
con la certezza che sarà cosa a lui gradita, sperando in un suo consequenziale
acquisto.
La presenza della tabella T_BlackList è giustificata dal fatto che ci sono dei motori di
ricerca interni o esterni, dei siti facenti parte della intranet o dei siti particolari che non
necessitano di essere tracciati o perché di scarso interesse o perché falserebbero le
analisi. In tale tabella verranno elencati manualmente e in taluni casi automaticamente
gli indirizzi da escludere da tale analisi. In questo caso la visita del sito da parte di un
motore di ricerca non comporterà nessun aggiunta di record né nella tabella
T_SessionTbl, né nella tabella T_PcLog né nella tabella T_PagineLog.
186
Progettazione
Figura 94: Activity Diagram: riconoscimento utente tramite cookie e global.asa
Il ruolo principale dell’analisi dei dati è quella di creare profili 145 le cui, diverse tipologie
ricordo che sono:
•
un profilo anagrafico, ottenuto mediante la consueta form di registrazione;
•
un profilo di navigazione, ottenuto mediante un approfond imento delle statistiche
offerte dal server web;
•
un profilo degli interessi ottenuto mediante l’analisi delle pagine prodotto visitate
e dal click-throught dei banner;
•
il profilo delle idee ottenuto mediante l’adesione dell’utente a sondaggi e forum di
discussione;
145
vedi 4.2.1.2
187
Progettazione
•
il profilo post vendita derivato dall’analisi delle mail, fax, telefonate ecc.. che
l’utente fa in seguito ad un acquisto per segnalare delusione, problemi,
soddisfazione e commenti in genere del prodotto acquistato.
Tutto ciò che può essere importante per l’analisi del profilo utente è riassunto nel
prossimo use case [fig. 95].
Figura 95: Use Case Diagram: User Profiling
Conoscendo meglio il cliente, è possibile calcolare la probabilità che un abbia un certo
comportamento e quindi derivare la propensione all’acquisto di un determinato prodotto.
188
Progettazione
Lo scoring146 è un metodo molto usato dagli esperti di marketing in quanto attraverso di
esso è possibile prevedere per esempio l’efficacia di una certa campagna di marketing
stimando a priori il relativo successo e quindi ottimizzando i costi proponendo l’offerta
solo a coloro che ne saranno interessati.
Per calcolare questo valore si possono anche proporre dei test e assegnare dei
punteggi ai percorsi e alle azioni che gli utenti compiono sul mall durante la
navigazione.
La possibilità di impostare dei questionari su argomenti apparentemente generici
oppure su prodotti e servizi del mall oppure semplicemente sulle necessità e abitudini
del cliente ci permette di conoscerlo meglio e più rapidamente.
Una stessa domanda può essere posta anche più volte nel tempo in modo da poter
analizzare la variazione delle risposte date.
Le domande potranno essere associate alle categorie e ai prodotti in modo che, se
l’utente stia navigando in una determinata categoria o leggendo le caratteristiche di un
certo prodotto e che sia tempo di rispondere ad una particolare domanda, questa gli
venga posta.
Figura 96: Class Diagram Data Modeler: dettaglio sui questionari
146
scoring: tecnica di marketing che prevede l’assegnazione di punteggi a eventi particolari, con cui stimare
comportamenti futuri del soggetto in esame.
189
Progettazione
Quello che si è fatto è stato semplicemente impostare una serie di domande associate
ad un tempo che indica l’intervallo dopo il quale la stessa domanda può essere
riproposta e inserire questi dati nella tabella T_Test. Poi si sono associati questi test ai
prodotti reparti o negozi sui quali desideriamo conoscere un’opinione includendo anche
una data, a partire dalla quale, tale test (suggerito via mail o via web) viene proposto e
un intervallo grazie al quale si può sapere ogni quanto tempo richiedere all’utente di
fornire una risposta (T_TestTarget). Infine, la tabella T_AnswerTest contiene tutte le
risposte comprensive di data a questi questionari.
Molto importante è anche l’analisi dei percorsi e delle azioni compiute da un
determinato utente, sul sito, assegnando a tali eventi un punteggio.
Ecco le possibili azioni nel dettaglio:
•
visitare la home page,
•
visitare pagina prodotto,
•
visitare pagina informazioni su spedizione, garanzia,
•
riempire il carrello,
•
svuotare il carrello,
•
effettuare l’acquisto,
•
scegliere lo spedizioniere,
•
effettuare il pagamento,
•
parole cercate nel motore,
•
richiesta info su un prodotto,
•
partecipazione chat/numero verde,
•
acquisti precedenti,
•
resi precedenti,
•
lamentele.
Attraverso il diagramma delle attività di [fig. 97] relativo ad un oggetto di tipo
Virtualmarketuser si possono notare quali possano essere gli eventi scaturiti sul sistema
dall’attività dell’utente e derivare le azioni più importanti a cui assegnare un punteggio.
190
Progettazione
Figura 97: Activity Diagram: istanza classe T_Member
Per quanto riguarda le pagine visitate e quindi i prodotti interessanti, nonché le
frequenza di visita ho già parlato. Resta da spiegare come possono influenzare l’analisi
le altre tipologie di dati che possiamo avere a disposizione.
191
Progettazione
Figura 98: Possibili sorgenti di dati
Tramite il diagramma appena esposto è possibile vedere come i vari moduli del
progetto possano contribuire in maniera rilevante alla creazione del profilo utente. In
particolare vengono mostrati il modulo che raccoglie negozi, prodotti e dipartimenti, il
modulo che descrive le vendite e quello che descrive gli utenti. Viene fatto riferimento
anche agli indici di tabelle che vengono usati come parametri nelle funzioni: vmid,
memberid. Mentre il primo è l’indice della tabella T_SessionTbl che maschera in un
certo modo i valori indice pcid della tabella T_PcLog, il secondo è l’indice della tabella
T_Member. Con il primo indice possiamo tracciare l’attività di un utente anche quando
non siamo sicuri della sua vera identità usando i cookie e le querystring. Con il secondo
indice, invece, calcolato in seguito all’identificazione dell’utente mediante email e
password possiamo con certezza attribuirgli determinate azioni e quindi migliorare il
profilo.
192
Progettazione
Figura 99: Class Diagram: differenze fra vmid,pclogid e memberid
Con il diagramma successivo mostro nel dettaglio tutte le tabelle coinvolte nel processo
di analisi dei dati.
193
Progettazione
Figura 100: Class Diagram Data Modeler: profilo avanzato utente
Questo diagramma e i seguenti, nel dettaglio, esprimono i legami tra le varie entità
necessarie per estrapolare i dati utili allo user profiling. Si può notare come le tabelle
OptionArticles, T_PcLog e T_Member siano quelle più ricche di tali informazioni.
Vediamo nel dettaglio le singole tabelle e quali indicazioni ci possono dare.
Il primo gruppo di tabelle che vado a descrivere è quello relativo al package
Stores&Articles.
194
Progettazione
Figura 101: Class Diagram Data Modeler: User Profiling Store&articles
Con le tabelle del diagramma [fig. 101] possiamo ricavare:
•
gli articoli nei carrelli e i loro proprietari,
•
i commenti espressi dagli utenti e su quale prodotto,
•
gli articoli, oggetto di suggerimento da parte degli utenti,
•
gli articoli sui quali gli utenti hanno espresso la necessità di conoscerne i dettagli
e nuove promozioni.
In questo modo conosciamo sia i prodotti più interessanti che gli utenti più attivi e più
recettivi in termini di risposta a sollecitazioni all’acquisto.
Il prossimo diagramma [fig. 102] descrive le tabelle del package Sales che sono
interessanti per il profiling avanzato.
In questo diagramma possiamo vedere come l’analisi della tabella dei dettagli di
ciascun ordine ci possa dire i prodotti realmente acquistati e da chi e in quale periodo,
mentre l’analisi della tabella dei pagamenti ci può dire come paga ciascun utente.
195
Progettazione
Figura 102: Class Diagram Data Modeler: User Profiling Sales
Figura 103: Class Diagram Data Modeler: User Profiling User
196
Progettazione
Il diagramma appena mostrato [fig. 103] ci dice come le tabelle dello schema S_ User
possano influenzare in maniera notevole lo user profiling. Ho già spiegato che la tabella
T_PcLog e T_PagineLog contengano i dati della navigazione di ciascun utente con la
possibilità di riconoscimento tramite cookie o, nella peggiore delle ipotesi, tramite
identificazione con email e password. La tabella T_SearchEngineWords ci dice le
parole e quindi gli argomenti che ciascun utente si aspetta di trovare sul mall e quindi
l’analisi di questi dati ci può spingere a mostrare meglio prodotti esistenti che vengono
cercati e non trovati o a mettere in vetrina articoli che vengono cercati ma che non sono
disponibili. La tabella T_Campaign ci dice quale tipo di campagne promozionali, verso
chi e quando sono state applicate per valutarne l’effetto sulle vendite. La tabella T_Calls
ci informa sul tipo di dialogo e sui contenuti di tutte le interazioni utente - mall in modo
da conoscere, nel tempo, il grado di soddisfazione degli utenti in base a ciò che è stato
detto al contact center. Possono essere utili anche informazioni riguardanti come, dove
e quando un utente abbia partecipato a forum e chat. Ciò può esprimere un gradimento
o un certo interesse verso articoli del mall. La tabella T_Interest raccoglie i prodotti di
cui gli utenti hanno espresso interesse mediante form. La tabella T_ MailingList ci può
dire a quali mailing list un utente è iscritto. Tale dato è utile in quanto esprime un
interesse diretto verso una o più tematiche precise. La tabella T_ AnswerTest ci dice a
quali test un utente a fornito una risposta, che tipo di risposta e la data.
Grazie alla modellazione WAE, si possono descrivere [fig. 104 e 105] le pagine server e
i componenti, in termini di metodi, proprietà e interazione con il database, che
gestiscono il flusso dei dati da e verso le tabelle appena descritte. Le classi che
modellano sia le pagine server che i componenti COM, fanno parte del package
business logic.
197
Progettazione
Figura 104: Class Diagram WAE: BusinessLogic 1
198
Progettazione
Figura 105: Class Diagram WAE: Business Logic 2
La gestione del contact-center
I requisiti del sistema richiedono una particolare attenzione al rapporto con i clienti e al
supporto che bisogna offrire loro pre e post vendita. Si è pensato che un maggior
199
Progettazione
dialogo con gli utenti che li guidi o meno all’acquisto sia fondamentale per rendere one
to one il rapporto tra negozio e clienti - acquirenti.
Per fare ciò c’è bisogno di un sistema che dialoghi con il cliente nei modi più disparati e
simpatici:
•
call center tradizionali,
•
email,
•
chat testuali e video,
•
forum di discussione,
•
commesso virtuale (e-clerk)
La cosa importante è però che tutti i dialoghi avvenuti in quello che abbiamo definito un
contact center (per la moltitudine di forme in cui il dialogo avviene) siano memorizzati in
un database in modo da usare le passate interazioni per rafforzare il dettaglio del
profilo.
L’idea che mi è venuta in mente è stata quella di realizzare un sistema di
comunicazione quanto mai multi-modale nel senso che prevedesse diverse forme e
mezzi di interazione tra il cliente e l’assistenza. Posso tralasciare la descrizione del call
center inteso in modo tradizionale in quanto non ha nulla di innovativo se non la
completa registrazione di tutte le comunicazioni utente-mall; posso tralasciare anche la
descrizione delle comunicazioni via posta per lo stesso motivo; la vera novità è la
possibilità di interagire attraverso una chat e un forum di discussione interni a
VirtualMarket. In questo modo viene creata una virtual community degli utenti del mall, i
quali possono ritrovarsi per scambiare chiacchiere non collegate all’attività del centro
commerciale e pareri sulle attività del centro. In sostanza anche il solo fatto che si
possa usare la chat per chiacchierare del più o del meno è positivo in quanto, data
l’integrazione della chat con le pagine del mall, è molto semplice visualizzare banner
pubblicitari, durante il chatting, che renderanno probabile l’interessamento di alcuni
chatters147 a prodotti del sito.
La gestione dei banner sarà tanto più efficace se verranno esposti prodotti affini a quelli
del reparto del quale i clienti stanno usando gli strumenti di chat e di forum di
discussione.
147
nel gergo i chatters sono coloro che usano sistemi di chat
200
Progettazione
L’idea è venuta un anno fa quando nessun sito aveva queste caratteristiche
implementate ma adesso non è difficile trovarne in giro di più o meno avanzate.
L’idea che sta alla base di questi due moduli è quindi cercare di far sentire l’utente
come se fosse nel negozio sotto casa con la libertà di acquistare ciò che vuole, quando
vuole chiedendo, se lo ritiene necessario, consiglio al negoziante o a coloro che in quel
momento si trovano insieme a lui nel negozio o addirittura a coloro che in un tempo
passato hanno acquistato nello stesso negozio o in un altro quello stesso prodotto.
Figura 106: Class Diagram Data Modeler: Contact Center
Il diagramma appena visualizzato mostra le diverse parti del database che riguarda il
Contact Center. Il nucleo fondamentale è rappresentato dalla tabella T_Calls che
memorizza il tipo di contatto avuto (chat, forum, numero verde, mail ecc…), il soggetto
201
Progettazione
del
contatto
(protesta,
apprezzamento,
consigli),
il
prodotto
oggetto
della
comunicazione, la data, l’operatore del contact center e ovviamente un riferimento
all’utente.
Inoltre sono rappresentati in questo schema anche le tabelle che memorizzano tutte i
dettagli riguardanti le campagne promozionali verso gli utenti intese come direct
mailing, tele marketing, banner pubblicitari ecc… in sostanza la tabella T_Campaign
memorizza chi riceve l’iniziativa di marketing, la data, il tipo di iniziativa e il prodotto che
si intende promuovere. Lo storico che se ne deriva dalla tabella in questione ci permette
di fare considerazioni precise sull’effettiva validità di una campagna piuttosto che di
un’altra.
La possibilità di chiedere, in modo istantaneo e con risposta immediata, un consiglio al
negoziante o ad altri utenti in quel momento presenti nel mall è stata la spinta che mi ha
fatto pensare ad una chat più o meno testuale. La presenza di una chat a stanze148, con
la possibilità di dialogare in privato con uno o più persone, crea nel mall una vera e
propria comunità virtuale nella quale il cliente si trova libero di esprimere le proprie
opinioni.
L’idea che sta dietro la chat è quella di creare un ambiente familiare (i sistemi di chat
sono ormai usati da moltissimi navigatori) con cui l’utente possa dialogare con
l’assistenza (commesso virtuale) e con gli altri utenti che in quel momento si trovano nel
centro commerciale. La chat è, quindi, una chat multistanza in quanto si può scegliere
di dialogare con tutti gli utenti del centro, oppure quelli di un singolo reparto per
chiedere informazioni e consigli sui prodotti esposti. Si cerca di ricreare l’ambiente di un
normale negozio dove davanti allo scaffale ci viene naturale chiedere a chi ci sta
accanto se quel prodotto è buono o meno o se ne ha provati di altri . Ci può venire
spontaneo anche di chiederlo ad un commesso che, in questo caso, diventa virtuale (e clerk) e la comunicazione con esso si fa privata nel senso che gli altri non possono
sapere cosa viene detto. Insomma la chat, realizzata in ASP, prevede u na
comunicazione pubblica e privata tra utenti disposti su più stanze che comunque sono
liberi di non partecipare alla discussione che viene aperta solo su richiesta dei singoli.
L’unica figura che è sempre presente e disponibile alla chat è il commesso vi rtuale che
148
si definisce chat a stanze, una chat con la possibilità di filtrare la lista delle persone con cui si vuol parlare
riducendola a membri di una stanza appunto, che nel nostro caso può essere un reparto.
202
Progettazione
deve rispondere alle domande degli utenti. Il commesso virtuale non è altro che un
esperto dei prodotti del mall che può essere sia dipendente del singolo negozio che
dipendente dell’intero mall.
Figura 107: Use Case Diagram: Chat
Dallo Use Case Diagram di [fig. 107] emerge quali siano le funzionalità da
implementare nella chat che sono tra l’altro quelle tipiche di un sistema di
comunicazione basato sull’instant messaging.
Le pagine server che implementano tale chat possono essere modellate attraverso il
seguente diagramma [fig. 108].
203
Progettazione
Figura 108: Class Diagram WAE: Chat
Ogni utente può partecipare alla chat semplicemente cliccando su un link presente in
ogni pagina del mall. Tale link però è realizzato in modo che a seconda della pagina in
cui viene cliccato la chat visualizza per default gli utenti collegati che si trovano in quella
determinata sezione. Ad esempio se l’utente inizia una chat mentre visita il reparto dei
casalinghi allora la chat visualizza gli utenti collegati che si trovano nel medesimo
reparto.
Per quanto riguarda il forum, devo dire che l’idea di fondo è la necessità di creare uno
spazio in cui l’utente potesse lasciare le proprie opinioni su prodotti/servizi e leggere
quelle degli altri ‘ off-line ‘. A differenza della chat nella quale l’interazione è immediata e
simmetrica (la domanda e la risposta avvengono immediatamente e ognuno sa con chi
sta parlando) nel forum di discussione, ognuno interviene essendo consapevol e che il
suo post può essere letto da chiunque in un tempo qualsiasi, non necessariamente in
quel momento stesso. In questo modo il dialogo si fa più pacato e riflessivo in quanto
non c’è la fretta di rispondere a determinate domande e inoltre con tutta tr anquillità si
può decidere di non rispondere. L’altro vantaggio è che, mentre per la chat si deve
sperare che ci sia qualcuno (che può anche non esserci) in quel momento capace di
rispondere alla propria domanda, con il forum si ha la certezza che più pers one, nel
tempo, possono leggere la propria domanda e porre quindi una risposta.
204
Progettazione
Figura 109: Use Case Diagram: Forum
Ogni utente nel momento che partecipa al forum di discussione ha la possibilità di
scegliere l’argomento principale che nel nostro caso è rappresentato dalle categorie del
mall. Una volta scelto l’argomento, può leggere tutto ciò che è stato detto sui prodotti
appartenenti a quella categoria. Ovviamente ci sono argomenti speciali come: i servizi
del mall, l’assistenza post vendita e ognuno è libero di proporre un nuovo argomento al
moderatore che, in caso positivo, lo inserirà nella lista.
Dall’analisi dei dialoghi degli utenti si possono ricavare utili informazioni sull’effettiva
qualità di un prodotto e sulla sua vendibilità.
Il successivo diagramma [fig. 110] mostra la modellazione delle pagine server che
implementamo il forum.
205
Progettazione
Figura 110: Class Diagram WAE: Forum
La pagina client del forum è composta da un modulo in cui si possono scrivere i post
(ForumForm), uno dove si possono scegliere i subject presenti o proporne di nuovi
(ForumSubjectList) e uno in cui si possono scegliere e leggere i post scritti da altri
(ForumPostList) selezionandoli per data, subject.
6.6.2.4Sistemi di data-mining e datawarehousing
Per quanto riguarda i sistemi di data-mining e datawarehousing devo dire che gran
parte del lavoro svolto è incentrato sulla memorizzazione quanto più completa di dati
tipici di un negozio virtuale con un’attenzione particolare ai dati che possono creare
servizi a valore aggiunto e la profilazione degli utenti. Una volta che Virtualmarket
raggiungerà le dimensioni aspettate allora parte dei dati verranno immessi in un
datawarehouse. A tali dati verranno applicati algoritmi di data min ing appropriati per
analisi di tipo predittivo-statistico. Il motivo per cui non è stato realizzato un sistema
siffatto ma solo ‘preparato’ (i dati che vi verranno inseriti ci sono tutti e già nella forma
più consona e opportuna) è che ci sono pochi dati e tale scarsità (pochi negozi, pochi
visitatori, pochi articoli) rende inapplicabili e quindi poco attendibili i risultati degli
algoritmi di Data-Mining. Nel momento in cui si avranno a disposizione alcuni giga di
dati allora, molto semplicemente, tali dati verranno spostati su un Data-Warehouse la
206
Progettazione
cui struttura, in termini di entità da memorizzare, rifletterà buona parte del database
esistente. Servirà solo una attenzione particolare alla realizzazione delle dimensioni e
quindi dei cubi relazionali al fine di avere un DataWarehouse più performante e quindi
analizzabile più efficacemente con tecniche OLAP.
6.7 Moduli Aggiuntivi
6.7.1 Punti Fidelity Program
Il modulo dei punti fidelity è stato pensato per aumentare il numero di visite al sito sia in
termini di registrazione di nuovi utenti che in termini di traffico.
L’analisi delle visite del sito mi ha portato alla conclusione che, nonostante il sito si
presenti con centinaia di prodotti molto vari tra loro e ben categorizzati, ben pochi
visitatori si registrano e ancor meno si identificano prima della navigazione. Pur
rimanendo di grande interesse la notevole quantità di dati scaturiti da queste
navigazioni ‘ anonime ’ mi è sembrato più opportuno sapere con esattezza chi visita
cosa e quando. La conoscenza esatta dell’utente che in quel momento sceglie un
prodotto piuttosto che un altro o che ponga determinate domande nel forum o sulla chat
risulta quindi fondamentale per la creazione di profili utente sempre più dettagliati e
spinti.
Allo stato attuale delle cose solo chi vuole gestire il carrello è obbligato ad identificarsi,
riducendo, di fatto, il numero di navigatori riconoscibili in modo sicuro. Si è fatta una
stima che solo il 5% dei navigatori effettua il log-in mentre i navigatori abituali sono solo
il 10%. Serve qualcosa che stimoli sempre nuovi clienti ma che soprattutto invogli i
vecchi clienti a tornare e ad identificarsi prima di visitare il sito.
Perché un utente dovrebbe trovare comodo registrarsi in un sito? Perché dovrebbe
tornare spesso in un sito? Perché dovrebbe sfogliare le pagine del sito in questione
manifestando la propria identità?
Le risposte potrebbero essere 149:
149
dati derivati da un questionario posto agli utenti del sito
207
Progettazione
•
perché il sito offre contenuti stimolanti, sempre nuovi e interessanti,
•
se si tratta di un sito di e-commerce, perché offre prezzi e condizioni vantaggiose
sui prodotti che vende,
•
perché ci sono continue promozioni,
•
perché ci sono dei giochi che lo divertono,
•
perché si può trovare una comunità di persone che lo attira,
•
perché la visita è ricambiata in qualche modo.
Tutte queste situazioni sono state studiate e realizzate in modo da rendere attraente la
navigazione in Virtualmarket ma evidentemente, data la giovane età del sito, serve
qualcosa di nuovo che attiri, con il passaparola, nuovi e vecchi utenti.
L’idea è quella di offrire dei punti convertibili in sconti sui prodotti o servizi a tutti coloro
che si registrano e a tutti coloro che rinuncino all’anonimato durante le successive
navigazioni. Ma come spingere gli utenti a visitare alcune pagine piuttosto che altre in
modo da aumentare la visibilità di un prodotto e di conseguenza la probabilità di essere
venduto? Ogni utente registrato ed iscritto al PF-Program ha a disposizione una serie di
punti giornalieri da acquisire in seguito al ritrovamento di diverse icone sparse qua e la
nel sito nelle pagine di descrizione dei prodotti. L’utente conosce quanti punti può
raccogliere in quel giorno (i punti possono cambiare giorno per giorno e utente per
utente in base al profitto che un certo utente ha), sa che per ottenere tali punti deve
cliccare su opportune icone disposte nelle pagine del sito ma non sa dove esse sono
disposte.
Il sistema dispone tali icone in modo casuale se:
•
non esiste nessun prodotto da promuovere,
•
l’utente non ha un profilo sufficiente per determinare una tipol ogia di prodotto per
lui interessante.
Il sistema dispone le icone in modo intelligente se:
•
esistono determinati prodotti da promuovere,
•
in base all’analisi degli acquisti fatti dall’utente, degli interventi nei contact-center,
delle precedenti navigazioni ci sono dei prodotti che con alta probabilità risultano
appetibili all’utente.
In questo modo il sito risulta essere altamente personalizzato anche se l’utente non se
ne accorge.
208
Progettazione
Figura 111: Use Case Diagram: Punti Fidelity
Come vengono gestiti i punti maturati? L’utente all’atto dell’accettazione delle condizioni
conosce che tali punti equivalgono a sconti su prodotti e servizi che il sito gli offre. Ogni
giorno l’utente può conoscere i punti maturati e i prodotti/servizi che può ottenere a
prezzo scontato previo uso dei punti accumulati. L’entità dello sconto è stabilito dalla
società caso per caso ma ogni utente conosce sin dall’inizio quali sono questi prodotti.
La società si riserva la possibilità di modificare in meglio per il singolo utente l’entità di
tali sconti comunicando ciò mediante comunicazione privata.
209
Progettazione
Figura 112: Class Diagram Data Modeler: Punti Fidelity
Il database del PF-Programme prevede una tabella-estensione (PF_User_Account) di
quella degli utenti, (T_Member) vista in precedenza, che aggiunge dei campi per
l’annovero dei punti che spettano giornalmente ad un certo utente, i punti già acquisiti
(questi 2 campi sono in realtà campi calcolabili da query eseguite sulla tabella
PF_Point_Product_User che memorizza i dettagli dei punti ma per motivi di prestazioni
sono stati inseriti in questa aggiornati volta per volta),e la data di accettazione del
regolamento del concorso. L’entità più importante è PF_Point_Product_User in quanto
in essa vengono trattati i dati dei prodotti che devono contenere l’icona clicca-punti, la
data in cui tale icona appare, la data in cui tale icona viene trovata e cliccata e la data in
210
Progettazione
cui i punti ad essa associati vengono consumati. L’inserimento dei dati in questa tabella
permette di ottenere il mapping più o meno intelligente tra l’utente -visitatore e il prodotto
nella cui pagina descrittiva è situata l’icona. Le altre entità descritte sono
PF_Promotions e PF_Promo_Discount_Products e PF_Promo_Discount_Services. La
prima di queste tabelle memorizza la promozione a cui si ha diritto, la durata di validità
della promozione sia in termini assoluti che in termini relativi. Dato che la promozione
poteva essere sia in termini di sconto su prodotti che su servizi di qualunque genere si è
pensato di usare 2 tabelle distinte (le altre due) che potessero descrivere sia i prodotti
che i servizi offerti (esempio di servizio: la consegna gratuita). Di ogni promozione
acquisita l’utente può disporre sia della fruizione dello sconto così come viene fornito
sia della conversione di tale sconto in punti (campo convertedtopoint) da accumulare
con gli altri per usufruirne in seguito.
Con l’Activity Diagram successivo si possono vedere quali siano le attività da svolgere
durante la navigazione di un utente su un negozio con il programma dei Punti Fidelity
attivato.
211
Progettazione
Figura 113: Activity Diagram: Punti fidelity
6.7.2 Partner Program
Le specifiche del Partner Program richiedono che possano essere gestite le figure di
partner appunto che hanno un ruolo fondamentale ai fini di acquisizione nuovi negozi e
incremento delle visite.
Vengono definiti 2 partner:
1. partner b2b: sono figure che procurano negozi per il mall e che percepiscono una
commissione sul venduto di quel negozio
212
Progettazione
2. partner b2c: sono utenti web che, previa registrazione, possono acquisire denaro
sulle vendite effettuate da utenti che hanno raggiunto Virtualmarket mediante un
banner opportunamente configurato e posto nel loro sito.
Per il Partner Program viene richiesto di sviluppare 2 moduli:
•
sviluppo delle pagine web che:
1. debbono riconoscere, mediante analisi della querystring, il partner
b2c, dal cui sito, il visitatore proviene
2. debbono attribuire una determinata commissione, legata al
partner b2c e b2b (se il negozio in questione ne è provvisto)
•
sviluppo script di gestione che devono permettere ai partner di poter
consultare il proprio credito accumulato, il profilo, la situazione dei subpartner e la situazione delle liquidazioni.
Un’ulteriore complicazione è data dall’eventualità che i partner b2b possano avere a
loro volta dei sotto-partner a cui dare una parte della loro commissione.
Es. il partner A registrato presso il mall come partner e unico referente porta tramite i suoi partner B e C 2 negozi (rispettivamente B
porta il negozio 1 e C il negozio 2). Il partner deve poter scegliere quale parte della sua commissione può dare ai suoi agenti in
base alle vendite dei singoli negozi.
Viene così realizzata una struttura ad albero, alla cui radice, è posto un riferimento alla
società committente del sito 150, e nei sotto-alberi di primo livello sono disposti i
riferimenti ai partner di primo livello. Man mano che si scende, si hanno i vari subpartner
che hanno come unico referente il partner di livello superiore del proprio circuito.
150
può essere considerato un partner in quanto percepisce commissioni ‘virtuali’ sul venduto e apporta partner
(quelli di primo livello)
213
Progettazione
Figura 114: Use Case Diagram: Partner Program
La lettura dello use case diagram ci permette di dedurre quali siano le informazioni da
dover memorizzare. Bisogna tener conto di una serie di dati del partner (numero CC
bancario, elenco negozi affiliati, indirizzo di posta elettronica), degli ordini e delle
commissioni maturate attraverso di essi e delle liquidazioni effettuate.
Figura 115: Class Diagram Data Modeler: Partner Program
Ovviamente tutti questi dati debbono essere visualizzati dai partner in modo da
controllare crediti maturati, dettagli del proprio profilo e dei vari subpartner. Il
diagramma sottostante spiega come le varie pagine server interagiscono in modo tale
da proporre, nella maniera più chiara e immediata, le informazioni richieste.
214
Progettazione
Figura 116: Class Diagram WAE: Partner Program
Per semplificare il lavoro degli script lato server è stato progettato un componente
(IPartner) la cui interfaccia è descritta nel diagramma sottostante. Tale componente
provvede, come tutti i componenti del middleware a dialogare con il database
sottostante e a porre i risultati allo strato superiore. Si può ben vedere come siano
presenti i metodi per aggiungere e modificare un profilo partner, gestire i negozi ad esso
associati, leggere le commissioni maturate e quelle già liquidate.
215
Progettazione
Figura 117: Class Diagram WAE: Partner Program BusinessLogic
216
Progettazione
Figura 118: Moduli dell’applicazione Virtualmarket
6.8 Il file global.asa
I moduli appena descritti sono stati implementati mediante la realizzazione di script e
componenti che vengono richiamati all’interno delle pagine server che costituiscono il
sito. Buona parte del lavoro viene svolto all’interno di un file esterno, che ho pensato di
inserire tra i componenti server dell’applicazione. Tale file è il global.asa151 che, ricordo,
trattasi di un file, unico per ogni directory virtuale (ogni applicazione web), la cui
esecuzione avviene prima dell’interpretazione della prima pagina server richiesta.
151
vedi 5.3.1.1
217
Progettazione
Figura 119: Global.asa
Il campo shopID del Global.asa memorizza l’indice della tabella shop relativa al negozio
corrente, il campo odbcstring memorizza la stringa odbc di connessione al database
corrente, il campo vroot memorizza il nome della directory virtuale del negozio corrente,
mentre il campo query è un array che contiene le query più utilizzate in tutta
l’applicazione.
Ricordo brevemente che i metodi ApplicationOnStart() (eseguito all’inizio della prima
sessione utente), ApplicationOnEnd() (eseguito al timeout dell’ultima sessione utente),
SessionOnStart() (eseguito all’inizio di ogni sessione utente) e SessionOnEnd()
(eseguito alla fine di ogni sessione utente) sono metodi standard, previsti
dall’architettura Asp. Tutti gli altri metodi sono stati inseriti per gestire i vari moduli.
SettaPartnerB2C() legge la querystring della referred url dell’utente corrente verificando
se proviene da un banner del ‘Partner Program’ impostando in tal modo le variabili di
sessioni PartnerB2CID e PartnerB2CCommissionID.
SettaPartnerB2B() preleva dal database, usando la tabella PP_PartnerShop, il valore
del partner B2B relativa al negozio corrente e la sua commissione impostando così le
relative variabili di applicazione.
GestioneCookie() legge il cookie dell’utente corrente per verificare se si tratta di un
nuovo o vecchio utente, appoggiandosi alla tabella T_SessionTbl. In ogni caso il cookie
verrà scritto con un nuovo valore indice di T_SessionTbl e un guid creato
218
Progettazione
appositamente se trattasi di un nuovo utente altrimenti verrà scritta solo la data
dell’ultima visita.
Figura 120: Cookie
SettaNomeNegozio() imposta le variabili di applicazione relative a vroot, shopid e
odbcstring.
SettaVariabiliApplication() imposta le variabili di applicazione relative alle features più o
meno attivi per il negozio corrente. Per esempio nel global.asa di un negozio tipico di
virtualmarket c’è il seguente codice:
Sub setta_application
Application("pf_programme")="no"
Application("magazzino")="no"
Application("ppartner")="yes"
Application("dm_analisys")="yes"
end sub
che dice che è attiva la feature ‘Punti Fidelity program ‘, la gestione avanzata del
magazzino, il ‘Partner Program ’ e il log per l’analisi avanzata dei dati utente.
ImpostaQuery() setta l’array delle query.
219
Progettazione
Figura 121: Use Case Diagram: Global.asa
Nel diagramma degli Use Case di [fig. 121] si è visto come vengono invocati ed
eseguiti i metodi presenti all’interno del global.asa. Abbiamo anche il relativo
Collaboration Diagram.
220
Progettazione
Figura 122: Collaboration Diagram: Global.asa
Nel dettaglio, nel Collaboration Diagram successivo, possiamo vedere cosa avviene
nel global.asa, durante il metodo SessionOnStart().
221
Progettazione
Figura 123: Collaboration Diagram: Riconoscimento Utente tramite cookie
Nel diagramma [fig. 124] vengono mostrati gli stati in cui si trova un’ istanza della classe
Cookie durante una sessione utente.
222
Progettazione
Figura 124: StateChart Diagram: istanza classe Cookie
Per capire meglio quali possano essere gli stati del sistema durante l’esecuzione del
global.asa viene mostrato il diagramma [fig. 125].
223
Progettazione
Figura 125: Activity Diagram: Esecuzione completa global.asa
6.9 Ottimizzazioni
6.9.1 MTS
Per migliorare la scalabilità è stato necessario intervenire su MTS. 152 Ho notato infatti
che i componenti COM scritti per MTS risultano essere migliori se si utilizza il pool di
connessioni di Transaction Server per le connessioni ODBC. Se un componente COM
gestito da MTS richiede una connessione al database, ne verrà fornita una del pool
gestito da MTS. Al termine della connessione, essa verrà restituita al pool. Il pool di
connessioni riduce i costi derivanti dalla creazione di connessione al database e la
necessità di gestire una connessione aperta per tutta la durata dell’applicazione. In
sostanza, se un’applicazione richiede che il sistema crei un’istanza relativa ad un
152
Vedi [8] della bibliografia
224
Progettazione
componente gestito da MTS, MTS intercetterà la chiamata e se è già in esecuzione
un’istanza del componente e se tale istanza è inattiva, verrà assegnato al processo in
corso altrimenti se ne creerà una nuova.
In sostanza, la chiamata viene intercettata quando un client chiama CreateObject. Al
posto del riferimento dell’oggetto del componente previsto, MTS trasmette al client un
riferimento a un oggetto del contesto creato. L’oggetto del contesto agisce come proxy
per l’oggetto effettivo, consentendo al client di accedere alle proprietà e ai metodi
dell’oggetto, permettendo comunque a MTS di mantenere il controllo dell’oggetto
effettivo. In questo modo MTS può verificare il momento in cui un client utilizza l’oggetto
e condividere lo stesso oggetto con altri client quando esso non è in uso. Ciò si traduce
nell’usare un numero inferiore di istanze del componente. Context è un oggetto COM
che implementa l’interfaccia IObjectCOntext che consente ai componenti di comunicare
a MTS quando l’operazione che stanno eseguendo è terminata con esito positivo o
negativo. I metodi con i quali MTS consente ai componenti di usare le risorse del server
sono 2: attivazione ‘just in time’ e disattivazione ‘as soon as p ossibile’.
6.9.2 Inclusione Server-side
Un modo ulteriore di diminuire il carico dei server è quello di limitare il numero di
inclusioni di file lato server. I file di inclusione consentono di riutilizzare il codice in ASP
caricando il codice dell’in-lining del file di inclusione con la pagina ASP prima che venga
eseguita. Se è necessario che tutte le pagine del sito abbiano la stessa intestazione è
sufficiente includere in esse lo stesso file header.asp. Un vantaggio importante di
questo metodo è che per aggiornare l’intestazione è sufficiente modificare il codice in
un solo punto anziché in ogni pagina. Un altro vantaggio è quello della facilità di
suddividere i compiti senza creare problemi di condivisione file. Se vengono inseriti in
file da includere caratteristiche omogenee e se solo queste danno problema, lo
sviluppatore può concentrarsi su queste lasciando che gli altri membri del team lavorino
su altre parti della pagina.
Es:
<%
<!--#include(“header.asp”)-->
<!--#include(“gestione_partner.asp”)-->
<!--#include(“gestione_banner.asp”)-->
<!--#include(“visualizza_vetrina.asp”)-->
<!--#include(“footer.asp”)-->
%>
225
Progettazione
Un altro vantaggio, se non altro in prospettiva di uso di una struttura a componenti è nel
fatto che, identificate le funzionalità da offrire e disposte in file distinti, questi stessi file
possono tradursi in componenti COM e quindi lasciare che eseguono loro il compito
dapprima dato allo script.
Es:
<%
banner=server.createobject(“banner.dll”)
banner.visualizza
partner=server.createobject(“partner.dll”)
partner.settaCommissione
vetrina=server.createobject(“vetrina.dll”)
vetrina.caricaprodotti(partner)
vetrina.visualizza
%>
purtroppo bisogna limitare il numero di file da includere per 2 motivi:
•
prima di eseguire il codice di una pagina ASP creata dinamicamente, il server
deve effettuare l’inclusione dei vari file. Questo comporta un notevole overhead e
comunque un ritardo della visualizzazione delle pagine. Inoltre ASP non supporta
l’inclusione condizionale in quanto le istruzioni condizionali scritte in VBScript
verranno comunque eseguite dopo l’inclusione e quindi non serviranno a nulla
(PHP non soffre di questo problema);
•
se i file da includere contengono codice comunque non utilizzato essi diventano
di dimensioni considerevoli senza apportare reali benefici, anzi aumentano il
tempo di interpretazione (il file è più lungo) e quindi quello di visualizzazione sul
browser.
Ho scelto comunque di usare i file di inclusione cercando di inserire in essi solo le
istruzioni necessarie. La possibilità di creare pagine in modo dinamico mi ha permesso
di realizzare negozi in tempi brevissimi in quanto bastava cambiare solo il file da
includere e il nuovo negozio che rispetto al vecchio aveva di diverso solo il tema grafico
era pronto.
226
Progettazione
6.9.3 Uso dei componenti piuttosto che degli script
(*)153
Un ulteriore modo di velocizzare il processing dell’applicazione se questa è di grandi
dimensioni è quello di trasferire il codice ASP ai componenti COM. ASP permette di
scrivere pagine dinamiche molto facilmente e velocemente imme rgendo in una pagina
con codice VBSCRIPT del codice HTML puro, ma il fatto stesso che il codice ASP
debba essere caricato e interpretato in fase di esecuzione può incidere negativamente
sulla scalabilità dell’applicazione. Poiché i componenti sono precompi lati risultano più
veloci, anche se viene aggiunto un certo overhead dovuto alla comunicazione fra i vari
componenti che con lo script non c’è. Un altro vantaggio dei componenti COM è che
essi offrono una maggiore protezione generale, la protezione della logica aziendale
proprietaria e la capacità di astrarre l’accesso ai dati e la logica aziendale
dell’interfaccia utente. Questa astrazione può offrire ulteriori benefici, inclusa la capacità
di
aggiornare
in
modo
selettivo
e/o
sostituire
singoli
componenti
o
livelli
dell’applicazione, senza influire sul resto dell’applicazione, nonché viene facilitato il
riutilizzo di tale componente.
6.9.4 Le architetture che supportano la scalabilità
(*)154
La gestione di componenti e database in un ambiente distribuito implica l’uso delle
transazioni. Il database utilizzato, MS SQL Server offre il supporto a tale tipo di
transazione e un’abile uso delle istruzioni SQL all’interno delle Stored Procedure ci
permette di ottenere script transazionali. Ma cosa succede se, una variabile di sessione,
all’interno di uno script ASP, assumesse il valore di un campo in una tabella modificato
all’interno di un update, ma che tale query, subendo un errore, venisse annullata tramite
un abort? La soluzione è rendere transazionali anche le pagin e ASP.
Per rendere transazionali le pagine ASP basta scrivere nella prima riga della pagina:
<%@TRANSACTION = transParam% >
dove transParam può essere Requires_New, Required, Supported, Not_Supported.
Sebbene lo script non possa determinare il risultato di una transazione del database, è
possibile creare gli eventi che verranno chiamati quando la transazione verrà
153
Vedi [6], [7], [8] della bibliografia
154
Vedi [6], [7], [8], [9] della bibliografia
227
Progettazione
completata o se si interromperà analizzando così il codice di errore che SQL Server
mette a disposizione. Tali eventi sono gestiti dalle procedure: OnTransactionCommit() e
OnTransactionAbort()
Ricordo i 4 attributi principali per cui, se supportati,
un’elaborazione si definisce
transazionale (ACID Test).
Atomicità:garantisce che l’insieme delle operazioni venga confermata o annullato
come fosse un’unità singola.
Coerenza: garantisce che l’operazione eseguita sia legale, conforme alle regole
aziendali o di coerenza del database che si sta utilizzando.
Isolamento: garantisce che le transazioni eseguite contemporaneamente restino
indipendenti l’una dall’altra.
Resistenza: garantisce che le transazioni non confermate non vengano danneggiate
dagli errori di sistema.
6.9.5 Come migliorare il tempo di risposta dell’applicazione
(*)155
Un tempo di risposta lento può dipendere da:
•
query non ottimizzate,
•
conflitto di risorse,
•
implementazione dei componenti insufficiente,
•
elementi hardware.
Per quanto riguarda le query non ottimizzate bisogna individuare dove, nel database,
vengono eseguite le query più onerose. Si dovranno inserire degli indici, ridurre i join,
spostare gli operatori più lenti in basso cercando di eseguire prima operatori di
sfoltimento come select e usare condizioni WHERE.
Un’altra fonte di lentezza che rientra nelle query non ottimizzate è quello relativo all’uso
di stringhe SQL generate in modo dinamico. Sebbene sia più facile scrivere query
all’interno delle pagine ASP in base ai parametri dettati dall’utente attraverso FORM per
poi passare tutta la stringa al db per l’esecuzione è più efficiente usare delle Stored
Procedure.
228
Progettazione
Per quanto riguarda il conflitto di risorse questi possono suddividersi in:
•
problemi di blocco (blocchi di condivisione, di aggiornamento, esclusivi): 2 utenti
accedono a una stessa riga bloccata da una query,
•
connessioni al database: è stato raggiunto il numero massimo di connessioni al
database,
•
utilizzo della memoria: è stata raggiunta la quantità massima di memoria
allocabile,
•
tempo di attività del processore.
I blocchi di condivisione sono relativi a operazioni che non aggiornano dati. Questi
blocchi permettono di leggere le righe interessate ma non di modificarle. In SQL Server
7 il blocco minimo è a livello di riga mentre nella versione 6.5 era a livello di pagina.
I blocchi di aggiornamento sono usati sulle righe che si desidera modificare durante una
query. Prima che avvenga effettivamente la modifica il blocco diventa esclusivo. In
pratica si impedisce di impostare ulteriori blocchi di aggiornamento nonché quelli
esclusivi mentre possono essere impostati blocchi di condivisione. Un blocco di
aggiornamento non può diventare esclusivo se non stati rilasciati prima i blocchi di
condivisione.
I blocchi esclusivi impediscono di richiedere un qualsiasi tipo di blocco.
Per quanto riguarda le connessioni al database bisogna sapere che ciascuna
connessione occupa memoria (40 kbytes per SQL Server e 2 mega per Oracle) e quindi
impostare un numero massimo di connessioni disponibili. Inoltre è utile usare un pool di
connessioni ODBC che riduce il numero di connessioni necessarie creando solo quelle
connessioni che hanno caratteristiche diverse (ID utente, password, server) da quelle
già in memoria.
155
Vedi [8] della bibliografia
229
Conclusioni
7 Conclusioni
Lo scopo della tesi era quello di pianificare e sviluppare un’infrastruttura di e-commerce
fortemente orientata all’utente in grado di espandere le proprie funzionalità in modo
semplice e rapido.
Date le dimensioni dell’applicazione e dati i tempi ristretti a disposizione per lo sviluppo,
si richiedeva di usare, sia per la fase di analisi, che per la fase della progettazione e
possibilmente anche nella fase di sviluppo una metodologia capace di spiegare con
chiarezza e immediatezza tutte le caratteristiche dell’applicazione e le problematiche
affrontate. La scelta è ricaduta su una metodologia Object Oriented che si è rivelata
vincente in quanto, in poco tempo, si sono specificati requisiti, analizzate le
caratteristiche principali e disegnato un prototipo funzionante del sistema.
Con tale approccio si costruisce un modello per un sistema che risponde in modo
chiaro, semplice e veloce, alle esigenze degli utenti.
La metodologia a oggetti si è adattata molto bene alle nostre esigenze anche nella
suddivisione e descrizione dei molti sottosistemi di cui Virtualmarket è composta, e nella
specifica delle molteplici entità in relazione fra loro, entità assimilabili a oggetti come
tabelle di database, pagine server e componenti.
L’uso di Rational Rose, associato a tale metodologia, ci ha permesso di lavorare in
modo iterativo su tutte le parti del progetto, partendo dalla specifica dei requisiti fino alla
codifica vera e propria, fornendo un supporto anche per la documentazione finale grazie
alle estensioni UML per la modellazione dei database (Rose Data Modeler) e per la
modellazione delle pagine web (Web Application Extension). Nei passi intermedi, i
modelli si sono via via affinati arrivando a mostrare con estrema semplicità sia
diagrammi UML molto simili a diagrammi entità relazioni, sia diagrammi UML molto più
espressivi di qualsiasi notazione per la descrizione di pagine web complesse sia server
che client.
Attraverso Rational Rose, si poteva ‘realizzare’, con un solo click, l’intero database, se
quest’ultimo fosse stato di tipo Oracle. Dato che la scelta è ricaduta su un altro DBMS
questo non è potuto accadere.
Quello che è mancato è stato un supporto per la creazione, seppur p arziale, delle
pagine web. La presenza infatti, di una notazione che potesse esprimere con
completezza: variabili, procedure, relazioni con db, presenza di link, form,
230
Conclusioni
immagini,ecc… da una parte ci ha permesso di spiegare con naturalezza sia pagine
server che pagine client ma dall’altra non ci ha permesso di costruirle in modo
automatico.
I vantaggi di un approccio come quello che prevede la progettazione di un sistema
attraverso un linguaggio di modellazione a oggetti sono i seguenti:
•
offre una documentazione chiara e completa del sistema,
•
offre una facilità di riuso di tutta la documentazione emersa nella fase di
progettazione (specifiche, diagrammi, prototipi) adeguandola a progetti simili in
poco tempo,
•
semplifica e velocizza la soluzioni a problemi complessi e di vaste dimensioni
attraverso la suddivisione in sottomoduli,
•
la presenza di strumenti adeguati permette di tradurre il lavoro svolto di analisi e
progettazione in sistemi più che prototipali dai quali partire per sviluppare l’intero
sistema.
Riepilogando le diverse fasi dell’intero progetto, queste sono state:
•
specifica dei requisiti attraverso la notazione degli use case in grado di mostrare
le funzionalità da sviluppare anche a personale non informatico,
•
compilazione di alcuni sequence e collaboration diagram per sottolineare le
situazioni più importanti o delicate dell’intero sistemo con particolare attenzione
all’interazione utente – mall,
•
disegno dei class diagram che ci desse una panoramica delle classi a cui
appartengono gli oggetti del sistema. Tali diagrammi riguardano sia il database
che le pagine vere e proprie,
•
affinamento dei sequence e collaboration diagram tenendo conto delle classi
costruite,
•
disegno degli statechart diagram e degli activity diagram per la modellazione dei
vari stati in cui i vari oggetti del sistema possono trovarsi e delle attività svolte,
•
suddivisione del sistema in sottosistemi,
•
scelta dell’architettura,
•
ulteriore affinamento dei diagrammi fino all’inizio dello sviluppo vero e proprio,
•
codifica e testing,
•
stesura della documentazione finale (questo documento)
231
Conclusioni
Nella metodologia usata, il modello a oggetti della fase di analisi è stato usato per la
fase di progetto e di implementazione, affinandolo a livelli sempre più dettagliati. In
questo documento vengono mostrati solo i modelli della fase di analisi, sia quelli della
fase di sviluppo, tralasciando tutti gli altri. Il processo è stato iterativo piuttosto che
lineare, aggiungendo o chiarificando caratteristiche anziché modificare il lavoro fatto.
Il progetto descritto in questa tesi e' stato realizzato in un contesto commerciale sotto il
nome Virtualmarket (www.virtualmarket.it) comprendente, ad oggi:
•
35 negozi,
•
350 articoli suddivisi in circa 20 categorie,
•
2000 pagine tra manager, negozi e portale,
•
5 temi grafici,
•
supporto SSL,
•
pop telepay per pagamento con CC,
•
possibilità di gestire il negozio, i suoi reparti e i suoi articoli e gli sconti ad esso
connessi direttamente on-line da parte dei negozianti.
Virtualmarket adesso è un mall con spiccate doti da sito di nicchia in quanto i prodotti
che offre provengono dall’artigianato italiano o comunque da realtà produttive regionali
che rendono il marchio ‘Made in Italy’ conosciuto e apprezzato in tutto il mondo.
232
Conclusioni
Figura 126: Home page attuale di Virtualmarket
233
Bibliografia
8 Bibliografia
[1] Micheal J. A. Berry, Gordon Linoff – Data Mining Techniques. For Marketing,
Sales and Customer Support – Wiley Computer Publishing, 1997
[2] Federico Rajola – L’organizzazione dei sistemi di business intelligence nel settore
Finanziario. Il Datawarehouse e il Data Mining – Franco Angeli, 2000
[3] Harry Singh – Data Warehousing, Concepts, Technologies, Implementations, and
Management – Prentice Hall PTR, 1997
[4] Ralph Kimball – The Data Warehouse Toolkit – John Wiley & sons, inc., 1996
[5] R. Connelly, R. Mosimann – The Multidimensional Organization – Cognos, 1999
[6] Web Technology Soluzioni per il commercio elettronico – Mondadori Informatica,
1999
[7] Sviluppo di soluzioni eCommerce Business to Consumer – Mondatori Informatica,
1999
[8] G. Andrew Duthie – Microsoft Visual InterDev 6.0, Enterprise Developer’s
Workshop – Mondadori Informatica, 1999
[9] Scot Hillier, Daniel Mezick – Programming Active Server Pages – Mondadori
Informatica, 1997
[10] Terry Quatrani – Visual Modeling with Rational Rose and UML – Addison Wesley,
1998
[11] Giuseppe Naccarato – Visual Basic la programmazione dei database – Apogeo,
1999
234
Bibliografia
[12] J. Rambaugh, M. Blama – Modelli e Progetti Object Oriented – Jackson Libri,
1995
[13] Sergio Beneduce – Prodotti per una strategia di e-commerce – E-Business News
(febbraio 2000 – n° 1)
[14] A. Saltarin – Portali & e-Commerce: a che stadio siamo? – Computer
Programming (marzo 2001 – n° 100)
[15] R. Palumbo – Commercio Elettronico: la nuova frontiera del business – Computer
Programming (gennaio 1999 – n° 76)
[16] Database & Web – DEV (ottobre 98 – n° 54)
[17] Applicazioni Distribuite – Computer Programming (ottobre 97 – n° 62)
[18] M. Sciabarrà – Java: Server-side Programming – Computer Programming
(febbraio 1998 – n° 66)
[19] N. Fino – Architettura di OLEDB: verso l’accesso unificato ai dati – Computer
Programming (febbraio 1998 – n° 66)
[20] M. Carli – Java Server Pages – Computer Programming (ottobre 2000 - n° 95-100)
[21] L. Morettoni – PHP – Computer Programming (dicembre 2000 - n° 97-101)
235
Principali siti di riferimento
9 Principali siti di riferimento
[1] www.ibm.com
in particolare
[1a] Jesus Mena - Mining E-Customer Behavior
[1b] Gary Saarenvirta - Data Mining for Direct Mail: A Lesson in Predictive Modeling
[1c] Barry Devlin - Toward the Information Supply Chain
[1d] Gary Saarenvirta - Mining Customer Data
[1e] Herb Edelstein - Data Mining – Let’s Get Pratical
[1f] Herb Edelstein – Data Mining: Exploiting the Hidden Trends in Your Data
[1g] Barry Devlin – Metadata: The Warehouse Atlas
[1h] Michael L. Gonzales – Getting Set for OLAP
[1i] Elizabeth A. Geiger - ERP and Data Warehousing
[1l] Colin White – Warehouses Webicum
[2] www.rational.com
in particolare
[2a] Rational Rose Guide To Team Development
[2b] Rational Rose 2000e. Using Rose
[2c] Mapping Object to Data Models with UML
[2d] The UML and Data Modeling
[2e] Database Modeling and Design Using Rational Rose 2000e
[2f] M. Blaha, W. Premerlani – Implementing UML Models with Relational Databases
[2g] M. Blaha, W. Premerlani - Object-Oriented Design of Database Applications
[2h] M. Blaha, W. Premerlani – Using UML to Design Database Applications
[2i] Jim Conallen - Modeling Web Clients with UML and Rose
[2l] Jim Conallen - UML Extension for Web Applications 0.91
[2m] Jim Conallen – Modeling Web Application Architectures with UML
[2n] Jim Conallen - Modeling Web Application Design with UML
[2o] Building Web solutions with the Rational Unified Process
[2p] John Hsia - Using COM in Your Rose Extensibility Solution
[2q] OMG Unified Modeling Language Specification
236
Principali siti di riferimento
[3] www.sas.com
in particolare:
[3a] Implementing the Customer Relationship Management Foundatio n – Analytical
CRM
[3b] Data Mining and the case for Sampling
[3c] A Formula for OLAP success
[3d] Using Data Mining Techniques for Fraud Detection
[3e] Implementing a CRM – based Campaign Management Strategy
[3f] The Quality Data Warehouse
[4] www.msdn.microsoft.com
[5] www.cognos.com
[6] www.hyperion.com
in particolare
[6a] The Role of the OLAP Server in a Data Warehousing Solu tion
[7] www.techguide.com
in particolare
[7a] Leveraging Visual and Analitycal Data Mining
[8] www.dbmsmag.com
in particolare
[8a] Ralph Kimball - A dimensional Modeling Manifesto
[9] www.dmreview.com
in particolare
[9a] J. Davis, R. Winter – The IBM Teraplex Integration Center
[10] www.1to1.com
[11] www.php.net
237
