Università degli studi di Padova

Facoltà di Scienze Matematiche, Fisiche e Naturali____________________________________________________

Corso di Laurea Triennale in Informatica

Reingegnerizzazione di un sito di

e-commerce

Relatore:

Prof.Paolo Baldan

C andidato:

Longato Alberton° matricola

507997

____________________________________________________Anno Accademico 2010/2011

1

2

3

4

IndiceIntroduzione..........................................................................................................................................7

1.1 Il prodotto da sviluppare............................................................................................................71.2 Principali problematiche............................................................................................................81.3 Specifiche e-commerce..............................................................................................................8

Tecnologie utilizzate ..........................................................................................................................112.1 PHP 5.......................................................................................................................................11

2.2.1 XHTML...........................................................................................................................122.3 CodeIgniter..............................................................................................................................13

2.3.1 CodeIgniter e paradigma MVC........................................................................................132.3.2 CMS Shoppingcart...........................................................................................................152.3.3 BackendPro......................................................................................................................152.4 MySQL................................................................................................................................16

2.5 Considerazioni.........................................................................................................................17Analisi dei requisiti ............................................................................................................................19

3.1 Contesto d’uso del prodotto.....................................................................................................193.1.1 Processi produttivi e modalità d’uso................................................................................193.1.2 Piattaforma d’esecuzione, funzioni del prodotto e interfacciamento con l’ambiente di installazione e uso....................................................................................................................20

3.2 Caratteristiche degli utenti.......................................................................................................203.3 Vincoli generali........................................................................................................................213.3 Use-Case..................................................................................................................................22

Progettazione .....................................................................................................................................274.1 Il database................................................................................................................................274.2 Struttura...................................................................................................................................28

4.2.1 ci_session........................................................................................................................294.2.2 omc_customer..................................................................................................................304.2.3 omc_product.....................................................................................................................314.2.4 omc_order........................................................................................................................33

Realizzazione e Testing......................................................................................................................355.1 Struttura...................................................................................................................................355.2 Controller.................................................................................................................................375.3 Model.......................................................................................................................................39

5.3.1 Function fetch..................................................................................................................395.3.2 Function Insert.................................................................................................................405.3.3 Function Update...............................................................................................................415.3.4 Function Delete................................................................................................................42

5.4 View ........................................................................................................................................435.4.1 Sviluppo STEP di acquisto...............................................................................................435.4.2 Layout..............................................................................................................................465.4.3 Validazione sito................................................................................................................47

Verifica e valutazione.........................................................................................................................496.1 Consuntivo...............................................................................................................................496.2 Possibili miglioramenti............................................................................................................516.3 Conclusioni..............................................................................................................................52

5

6

Capitolo 1

Introduzione

In questo capitolo verranno spiegate le funzionalità del prodotto sviluppato, e quali siano i concetti fondamentali legati a questo prodotto, al fine di comprendere appieno la sua utilità.

1.1 Il prodotto da sviluppare

L’azienda “Puliamo di Peruzzo Marco” è impegnata da diversi mesi in un progetto che vuole apportare benefici in termine di innovazione nell’ambito di visibilità e di gestione automatizzata dei propri prodotti affiancanti dall'introduzione della parte e-commerce all'interno del proprio sito web.

Il prodotto prevedeva l'introduzione e quindi l'organizzazione di un nuovo database per l'inserimento dei prodotti al fine di avere una gestione automatizzata e diretta introducendo nel proprio sito web la parte commerciale. Si tratta di creare un nuovo sito dal layout simile al vecchio che gestisca il listino dei prodotti e la loro vendita online. Il nuovo sito infatti deve essere dotato di un database, di un pannello di amministrazione per la gestione grafica degli utenti, clienti, prodotti, al fine di poter tener traccia di tutte le vendite e di essere in grado di poter creare offerte personali ad ogni singolo cliente.Il sito inoltre deve gestire la registrazione automatizzata degli utenti mandando una mail di avvenuta registrazione quando un utente si registra, e di ordine avvenuto quando un utente effettua un'ordinazione.Inoltre dato il grandissimo numero di prodotti gestiti dell'azienda, si auspicava di creare la tabella “prodotti” in maniera tale che fosse possibile l'inserimento automatico di un intera pagina di un foglio di calcolo dove ogni colonna corrispondesse a quella della tabella avendo

7

l'azienda i listini in formato “ods” (Estensione foglio di Calcolo OpenOffice).

1.2 Principali problematiche

Le principali problematiche riscontrate in fase di analisi son state quelle di trovare un framework che soddisfacesse sia lo stagista che l'azienda. Tale framework doveva garantire una facilità di implementazione e una buona sicurezza visto che il progetto prevede sia il trattamento dei dati personali di clienti sia il commercio online.Una volta individuato quello più appropriato si è ritenuto utile per questioni sia di tempo che di sicurezza utilizzare un CMS avente una parte e-commerce predefinita anche se molto scarna ma con un pannello di amministrazione sviluppato che faceva al caso dell'azienda.Lo studio di tale CMS è stato una delle problematiche principali data la scarsa documentazione dello stesso, e quindi molto tempo è stato utilizzato per la personalizzazione alle esigenze interne aziendali.

1.3 Specifiche e-commerce

La parte e-commerce del sito deve prevedere l'utilizzo di un database dove nella tabella che conterrà tutti i prodotti dell'azienda verranno inseriti i listini. Ogni prodotto dovrà essere dotato inoltre di un campo “visibile” in modo che se settato a “true” venga automaticamente pubblicato nel listino del sito ed essere quindi comprabile da subito.Si richiede che il trattamento dei dati sia fatto con liceità e correttezza nella piena tutela dei diritti dell'acquirente ed in particolare si richiede la loro riservatezza.Di fondamentale importanza è quindi il trattamento sicuro dei dati dell'utente, con criptazione della password in modo che non venga mai passata in chiaro e garantendo la massima tutela dei dati sensibili del cliente.Si richiede quindi anche la massima sicurezza nei vari metodi di

8

pagamento, soprattutto se effettuati con carte di credito o tramite Paypal.

9

10

Capitolo 2

Tecnologie utilizzate

In questo capitolo verranno elencate le scelte che sono state effettuate in ambito tecnologico dall’azienda e dal sottoscritto. La maggior parte dei linguaggi scelti sono stati condizionati dalle scelte tecnologiche adottate dall’azienda, come vedremo nel dettaglio in seguito.

2.1 PHP 5

PHP (acronimo ricorsivo di ‘PHP: Hypertext Preprocessor’, preprocessore di ipertesti) è un linguaggio di scripting interpretato, con licenza open source e libera (ma incompatibile con la GPL), originariamente concepito per la programmazione Web ovvero la realizzazione di pagine web dinamiche. Attualmente è utilizzato principalmente per sviluppare applicazioni web lato server ma può essere usato anche per scrivere script a linea di comando o applicazioni standalone con interfaccia grafica. PHP riprende per molti versi la sintassi del C, come peraltro fanno molti linguaggi moderni, e del Perl. è un linguaggio a tipizzazione debole e dalla versione 5 migliora il supporto al paradigma di programmazione ad oggetti. Certi costrutti derivati dal C, come gli operatori fra bit e la gestione di stringhe come array, permettono in alcuni casi di agire a basso livello; tuttavia è fondamentalmente un linguaggio di alto livello, caratteristica questa rafforzata dall’esistenza delle sue moltissime API, oltre 3000 funzioni del nucleo base. PHP è in grado di interfacciarsi a innumerevoli database (tra cui MySQL) e supporta numerose tecnologie (come XML).Fornisce un’API specifica per interagire con Apache, nonostante funzioni naturalmente con numerosi altri server web è anche ottimamente integrato con il database MySQL, per il quale possiede più di una API. Per questo motivo esiste un’enorme quantità di script e librerie in PHP,

11

disponibili liberamente su Internet. La versione 5, comunque, integra al suo interno un piccolo database embedded, SQLite. Dispone di un archivio chiamato PEAR che mette a disposizione un framework di librerie riusabili per lo sviluppo di applicazioni PHP e di PECL che raccoglie tutte le estensioni conosciute scritte in C.

2.2.1 XHTML

L’XHTML (acronimo di eXtensible HyperText Markup Language, Linguaggio di marcatura di ipertesti estensibile) è un linguaggio di marcatura che associa alcune proprietà dell’XML con le caratteristiche dell’HTML: un file XHTML è un pagina HTML scritta in conformità con lo standard XML. Il linguaggio prevede un uso più restrittivo dei tag HTML sia in termini di validazione che in termini di sintassi per descrivere solo la struttura logica della pagina, mentre il layout e la resa grafica sono imposti dai fogli di stile a cascata (Cascading Style Sheets, CSS).

12

2.3 CodeIgniter

CodeIgniter è un framework PHP che permette di usufruire di uno strumento leggero, semplice da utilizzare e adatto anche a chi non può permettersi di ospitare i propri progetti in costosi hosting di fascia alta.

Ho scelto Codeigniter poiché vi è una vasta, completa e dettagliata documentazione molto chiara e ben corredata di esempi; per un programmatore che conosce i linguaggi ad oggetti e php, basta un piccola letta per iniziare subito a sviluppare e creare in tempi brevi applicazioni molto potenti.

2.3.1 CodeIgniter e paradigma MVC

CodeIgniter è un framework rilasciato sotto licenza Open Source per lo sviluppo di applicazioni in linguaggio PHP, esso si basa sul paradigma MVC (Model-View-Controller, letteralmente Modello-Vista-Controllore), ciò vuol dire che utilizzandolo sarà possibile separare il core

dell'applicazione e il codice relativo all'elaborazione delle informazioni (Model e Controller) dalla parte relativa alla visualizzazione degli output (View).

Nel paradigma MVC, quindi anche nel funzionamento di CodeIgniter, troviamo tre elementi fondamentali:

• il Model: cioè la parte dell'applicazione che ha il compito di gestire il maggior numero di operazioni relative all'elaborazione dei dati, un esempio di questa funzionalità è dato classicamente dall'interazione dell'applicazione con le informazioni memorizzate all'interno delle tabelle di una base di dati.

• la View : determina le modalità con cui gli output prodotti dall'applicazione verranno mostrati all'utente, per esempio producendo delle pagine HTML, dei documenti (Pdf, XLS etc.), dei feed RSS o dei file XML.

• il Controller : presiede all'interazione tra gli utenti e i dati, la sua

13

funzione principale è quindi quella di controllare i dati provenienti dal Model passandoli alla View sulla base delle procedure previste dall'applicazione.

A differenza di altri framework più conosciuti e utilizzati, CodeIgniter gestisce il paradigma MVC in modo molto più semplice, esso si basa su una struttura per classi di tipo singleton in cui l'oggetto principale permette di caricare tutte le librerie ed i modelli richiesti per lo sviluppo di una applicazione.

Con il termine singleton si intende indicare infatti un cosiddetto design

pattern creazionale il cui scopo è quello di assicurare che per una classe esista una sola istanza e fornire, nello stesso tempo, un unico punto di accesso globale all'istanza stessa.

Figura 2.1: Applicazione Flow Chart

1. index.php funge da front controller, l'inizializzazione delle risorse di base necessarie

per eseguire CodeIgniter.

2. Il router esamina la richiesta HTTP per determinare cosa deve essere fatto.

3. Se esiste un file di cache, viene inviato direttamente al browser, bypassando il

normale svolgimento del sistema.

4. Protezione. Prima che il controller di applicazione venga caricato, la richiesta HTTP

che ogni utente ha presentato viene filtrata per avere la sicurezza nei dati.

5. Il Controller carica il model, librerie di base, plugin, helpers, e le altre risorse

necessarie per elaborare la richiesta specifica.

6. La versione definitiva della View viene poi inviata al browser per essere vista. Se il

caching è abilitato, la vista viene memorizzata nella cache in modo che le richieste

successive possano essere servite più velocemente.

14

2.3.2 CMS Shoppingcart

Questo carrello è costruito su Codeigniter. Viene utilizzato “BackendPro” per l'amministrazione e “Ajax file manager” per inviare dal pannello di amministrazione messaggi istantanei nella sezione “news” del sito.

2.3.3 BackendPro

BackendPro è un pannello di controllo per gli sviluppatori scritto in PHP per il

framework CodeIgniter.

Non è come un CMS che fornisce un sistema completo di lavoro, offre soltanto

delle funzionalità per fare tutti i compiti ripetitivi semplici come

l'autenticazione, le autorizzazioni e un look and feel di base per il pannello di

controllo di siti web.

Può compiere:

• Autenticazione utente con la registrazione e l'attivazione dell'account

• Autorizzazioni utente utilizzando Access Control Lists (ha accesso

all'area di controllo per gestire le autorizzazioni di accesso dei siti web)

• Preferenze del sito (memorizzati in un database con interfaccia utente

semplice da usare per aggiornare e modificare preferenze)

• Asset Library (attività sulle pagine è veloce e semplice, ha anche asset

cache per velocizzare il caricamento dei file delle attività)

• PHP alla conversione variabile javascript (modo facile per passare le

variabili in PHP script javascript)

• Test per determinare se l'utente sia un umano (e non un computer o, più

precisamente, un bot): CAPTCHA

• Messaggi di stato (Può visualizzare informazioni / successo / avviso /

15

messaggi di errore per l'utente)

Figura 2.2: BackendPro

2.4 MySQL

Il database MySQL è il database open source più conosciuto al mondo grazie a prestazioni veloci, elevata affidabilità e facilità d’uso. E' utilizzato in ogni continente, anche in Antartide, da singoli sviluppatori Web e da molte delle aziende più grandi e in più rapida espansione del mondo, tra cui leader di settore come Yahoo!, Google, Alcatel-Lucent, Nokia, YouTube e Zappos.com., per risparmiare tempo e denaro potenziando siti Web con volumi d’accesso elevatissimi, sistemi business-critical e pacchetti di soluzioni software. MySQL non è soltanto il database open source più famoso al mondo, è diventato anche il database utilizzato per una nuova generazione di

16

applicazioni basate sullo stack LAMP (Linux, Apache, MySQL, PHP / Perl / Python). MySQL può essere eseguito su più di 20 piattaforme, tra cui Linux, Windows, Mac OS, Solaris, HP-UX, IBM AIX, offrendo quella flessibilità che mette l’utente al comando.

2.5 Considerazioni

Le scelte tecnologiche per lo svolgimento di questo progetto sono state condizionate dall'uso del framework Codeigniter e del CMS Shoppingcart, completamente open source e sviluppato in PHP. Shoppingcart si appoggia ad un databse MySQL. Per lo sviluppo del progetto ho dovuto usare le stesse tecnologie gia presenti in Shoppingcart e ritengo che siano le migliori che potessero essere previste. Infatti le tecnologie usate sono tutte open source. Questo abbatte notevolmente i costi di produzione in quanto non occorre acquistare licenze particolari. La scarsa documentazione di tale CMS è ampiamente coperta dagli innumerevoli commenti all'interno del codice che han reso leggero lo studio dello stesso. Si son tuttavia create alcune imperfezioni (bug) nell'adattamento del CMS al progetto in essere, che il sottoscritto ha corretto nei limiti di tempo previsti per cercare di ottenere il miglior funzionamento del sito.La modifica del Layout di default in quello richiesto dall'azienda è stato un compito costoso in termini di ore lavorative.

17

18

Capitolo 3

Analisi dei requisiti

3.1 Contesto d’uso del prodotto

3.1.1 Processi produttivi e modalità d’uso

Il progetto si prefigge come requisiti obbligatori:

RO_01: Ottenere un sito Google Friendly.

RO_02: Creare un database dove vi sian i prodotti del magazzino e che tenga traccia degli utenti e delle ordinazioni effettuate.

RO_03: Avere un pannello di gestione utenti e prodotti.

RO_04: Ottenere il Layout del nuovo sito il più possibile identico a quello del vecchio sito statico.

RO_05: Creare 4 step nella sezione di conferma ordine per guidare il cliente passo a passo all'acquisto, creando un layout serio ed e facile da capire anche per un utente che non ha mai acquistato online.

RO_06: Ottenere la dinamicità del sito, dove, modificando alcuni parametri all'interno database i prodotti vengano automaticamente inseriti nell'apposita sezione e sia quindi possibile da subito il proprio acquisto.

RO_07: Mandare automaticamente la mail di avvenuta iscrizione al sito.

RO_08: Mandare automaticamente la mail di avvenuta ordinazione.

RO_09: Gestire in maniera sicura i dati sensibili dell'utente e i pagamenti.

19

Si richiedono inoltre come requisiti facoltativi:

RF_01: Trovare un modo automatico per caricare i listini nel database.

RF_02: Avere la possibilità di utilizzare un modulo CAPTCHA per assicurarsi che l'utente si umano e non un bot.

3.1.2 Piattaforma d’esecuzione, funzioni del prodotto e interfacciamento con l’ambiente di installazione e uso

Il prodotto verrà sviluppato come un modulo PHP e dovrà essere integrabile e rispettare gli standard di integrazione di CodeIgniter. Lavorando in ambiente web, accessibilità, chiarezza ed efficienza saranno i principali fattori del progetto, verranno di conseguenza adottate le specifiche tecnologie necessarie per raggiungere tali scopi. Per la realizzazione di tale prodotto verranno utilizzati prodotti open source.

3.2 Caratteristiche degli utenti

L'utente finale sarà una qualsiasi persona che voglia acquistare dei prodotti dell'azienda. All'utilizzatore finale non son richieste abilità o conoscenze tecniche particolari.

20

3.3 Vincoli generali

Il software dovrà:– permettere l'aggiunta di prodotti all'interno del database e automaticamente dovranno apparire nel sito nell'apposita sezione.– gestire i dati personali in maniera sicura.– permettere all'utente di ricerca un prodotto specifico.

– memorizzare le ordinazioni effettuate dai clienti.

21

3.3 Use-Case

Figura 3.1: Use Case 1: Funzionamento generale

• L'utente può effettuare il login o registrarsi, visionare il catalogo ed effettuare un ordine.

• L'amministratore gestisce il catalogo dei prodotti.

22

Specializzazione Use Case 3.1: visione Catalogo

Figura 3.2: Use Case 2: Catalogo Prodotti

Sommario: Gestione del catalogo

Attore Principale : Utente

Pre-condizioni: Nessuna

Des crizione : L'utente entra nella sezione Catalogo dove visiona i prodotti

Post-condizioni: Nessuna, anche se l'utente non è registrato potrà riempire il carrello

23

Specializzazione Use Case 3.2: Sezione Carrello

Figura 3.3: Use Case 3: Carrello

Sommario: Gestione Cassa virtuale

Attore Principale : Utente loggato

Pre-condizioni: Utente registrato e loggato

Des crizione :

1. l'utente entra nella sezione Cassa;2. l'utente può acquistare ciò che ha nel carrello, modificare gli articoli o eliminarli;3. l'utente può confermare l'ordinazione

Post-condizioni: l'ordinazione viene effettuata e il carrello si svuota

24

Specializzazione Use Case 3.3: Gestione Cassa

Figura 3.4: Use Case 4: Cassa

Sommario: Il cliente dovrà andare alla cassa dopo aver messo i prodotti nel carrello.

Attore Principale : Utente loggato

Pre-condizioni: Uno o più prodotti devono essere nel carrello.

Post-condizioni: La sessione del Cliente deve essere attiva (non scaduta)

25

Questo use case mostra come l'utente possa ordinare gli elementi inseriti nel carrello. Il sistema assicura in primo luogo che l'utente sia connesso, quindi cattura il loro indirizzo di consegna e la modalità di pagamento. Il sistema mostra al cliente un riepilogo dell'ordinazione e, prima di procedere definitivamente viene richiesta all'utente la conferma definitiva.

26

Capitolo 4

Progettazione

4.1 Il database

TABELLE:be_acl_actions be_acl_groups

be_acl_permissions be_acl_permission_actionsbe_acl_resources be_groups be_preferences be_resources be_users be_user_profiles ci_sessions eventcal omc_category omc_colors omc_customer omc_menu omc_messages omc_order omc_order_item omc_page omc_product omc_product_colors omc_product_sizes omc_shipping omc_sizes omc_subscribers shoutbox

Tabella 4.1: Composizione Database

27

4.2 Struttura

Descriveremo la struttura delle principali tabelle e il loro funzionamento

Figura 4.1: Struttura Database

28

4.2.1 ci_session

La Classe Session permette di conservare lo "stato" dell'utente e tracciare la sua attività mentre naviga nel sito. La Classe Session memorizza le informazioni della sessione come una lista di dati in un cookie. Per una maggiore sicurezza si è scelto di salvare i dati della sessione nella tabella “ci_session” del database, questo permette di confrontare l'ID di sessione presente nel cookie dell'utente con quello salvato nel Database.

L'inizializzazione di una s e s s ione

Le sessioni generalmente si attivano ogni qual volta una pagina viene caricata, quindi la Classe Session deve necessariamente essere inizializzata nel Controller.

Per la maggior parte la classe Session lavorerà in background così, semplicemente con l'inizializzazione della classe si potranno leggere, creare e aggiornare le sessioni.

Come funzionano le s e s sioni?

Quando una pagina viene caricata, la classe Session verificherà se esistono dati di sessione validi nei cookie. Se i dati non esistono (oppure se sono scaduti) verrà creata una nuova sessione e salvata in un cookie. Se una sessione esiste le informazioni che contiene verranno aggiornate così come il cookie. Ad ogni aggiornamento il session_id verrà rigenerato.

Una volta inizializzata, la classe di sessione viene eseguita automaticamente. Il processo di lettura, scrittura, e l'aggiornamento di una sessione è automatico.

Cos a sono i dati di s e s sione?

Una sessione, per quanto concerne CodeIgniter, è semplicemente un array contenente le seguenti informazioni:

29

• il Session ID dell'utente, univoco (è una stringa generata randomicamente,

criptata con MD5, che si rigenera(di default) ogni 5 minuti);

• l'indirizzo IP dell'utente;

• I dati relativi all'Agent dell'utente (una stringa composta dai primi 50

caratteri del browser)

• la data e ora dell'ultima attività

4.2.2 omc_customer

omc_customer

Campo Tipo Descrizionecustomer_id int(10) Autoincrementante, chiave

primaria che identifica il cliente

password varchar(50) Password crittata in md5

customer_first_name varchar(50) Nome del Cliente

customer_last_name varchar(50) Cognome del Cliente

phone_number varchar(20) Telefono del Cliente

email varchar(50) E-mail del Cliente

address varchar(50) Indirizzo del Cleinte

city varchar(50) Città del Cleinte

nation int(5) Nazione del Cleinte

post_code varchar(10) CAP

fiscal_code varchar(16) Codice fiscale del Cleinte

piva varchar(13) Parita iva del Cleinte

activation_code varchar(12) Codice di attivazione per attivare l'accuont

activated tinyint(4) 1 se del Cleinte è attivo, 0 altrimenti

Tabella 4.2: Struttura tabella “omc_customer”

30

Il campo activated viene settato di dafault a 1 quando un utente si registra poiché per scelta aziendale non si è voluto mandare via mail il codice di attivazione al cliente ma registrarlo direttamente. Tuttavia basta settare nel pannello di amministrazione che si vuole adottare un codice di attivazione. Password contiene la password criptata in md5, ciò significa che la password in chiaro non viene mai salvata ma direttamente criptata per motivi di sicurezza.

4.2.3 omc_product

omc_productCampo Tipo Descrizione

id varchar(11) Chiave primaria che identifica il prodotto

name varchar(255) Nome prodotto

shortdesc varchar(255) Descrizione corta del prodotto

longdesc text Descrizione completa del prodotto

conf varchar(11) Prodotti all'interno di una confezione

thumbnail varchar(255) Indirizzo immagine di anteprima

image varchar(255) Indirizzo immagine prodotto

product_order int(11) Quantità di prodotti ordinati e non spediti

class varchar(255) Classe appartenente al prodotto

grouping varchar(16) Marca del prodotto

status enum('active','inactive')

Se impostato su active il prodotto compare nel sito, altrimenti no

category_id int(11) Categoria nella quale il prodotto viene inserito nel sito

featured enum('none','front','webshop')

Per renderlo o meno visibile nell'hompage del sito

other_feature enum('none','most sold','new product')

Campo che da la possibilità al prodotto di essere inserito nelle categorie “piu costoso” e “nuovo prodotto”

pricelist float(7,2) Prezzo di listino

31

price float(7,2) Prezzo di listino scontato

Tabella 4.3: Struttura tabella “omc_product”

La tabella omc_product contiene tutti i prodotti che l'azienda può vendere. Ogni prodotto avrà un nome e una descrizione che saranno fondamentali per effettuare ricerche all'interno del sito, infatti esiste una funzione di ricerca che controlla se la parola cercata appare nel nome e nella descrizione di ogni singolo prodotto.Thumbnail contiene l'indirizzo dell'immagine in dimensioni ridotte (114px × 207px) dell'articolo, mentre image contiene l'indirizzo dell'immagine nella dimensione scelta (240px x 440px).Ogni prodotto appartiene ad un gruppo poiché l'azienda vende prodotti di molteplici marche e si è ritenuta necessaria questa suddivisione per velocizzare le ricerche. Status indica se il prodotto è visibile o meno all'utente, quando l'azienda finisce le scorte di magazzino o decide di togliere un prodotto dal mercato per un periodo di tempo basterà che setti a “inactive” il valore del campo.“Pricelist” contiene il prezzo di listino, mente “Price” contiene il prezzo di listino scontato.Si è voluto tener traccia di entrambi i prezzi poiché in caso di sconti si mostra al cliente il prezzo di listino barrato, e subito sotto il prezzo scontato.

32

4.2.4 omc_order

omc_orderCampo Tipo Descrizione

order_id int(10) Autoincrementante, chiave primaria che identifica l'ordine

customer_id int(10) Chiave secondaria che identifica il cliente

payment varchar(25) Pagamento sceltoinvoice varchar(3) Contiene “yes” se il

cliente vuole la fatture, no altrimenti

total decimal(10,2) Talale ordineorder_date datetime Data del'ordinazionedelivery_date datetime Data di spedizione, si

aggiornerà dal pannello amministrazione quando si marcherà la merce come spedita

payment_date datetime Data di pagamento

Tabella 4.4: Struttura tabella “omc_order”

La tabella omc_order tiene traccia delle ordinazioni dei clienti associando ad ogni ordinazione un numero auto-incrementativo e inserendo in customer_id l'id del cliente che ha eseguito l'ordine, viene registrata quindi la modalità di pagamento scelta, e i dati relativi all'acquisto.

33

34

Capitolo 5

Realizzazione e Testing

5.1 Struttura

Il Sito si struttura in tre cartelle principali:assets, modules e system.- Assets contiene i files di Layout e il relativo css

- Modules contiene i moduli messi a disposizione dal framework, qui è inserito il modulo “webshop” che si occupa della gestione dati relativa al commercio elettronico. Qui si trova infatti il controller del modulo webshop che è il cuore vero e proprio del programma. Ogni chiamata di una singola funzione del controller viene verificata, validata e quindi richiamato i files della vista relativo.

- System contiene tutti i files di sistema e le librerie messe a disposizione dal framework per la gestione controllata di ogni singolo elemento presente nel sito (invio automatico email, modulo di criptazione sicura della password, sessione utenti..)

35

Figura 5.1: Struttura Sito: cartella assets

Figura 5.2: Struttura Sito: cartella modules

36

Figura 5.3: Struttura Sito: cartella system

5.2 Controller

function Webshop(){ parent::Shop_Controller(); // load the validation library

$this->load->library('validation');$this->load->library('Paypal_Lib');

}

All'avvio del Controller vengono caricate le librerie che si intendono usare.

37

function index(){ // you need to change webshop_lang $lang['webshop_folder'] = 'webshop'; // according to your folder name. $webshop = $this->lang->line('webshop_folder');

$page = $this->MPages->getPagePath($webshop); $featureimages = $this -> MProducts -> getFrontFeature($webshop);

// load slideshow preference$this->bep_assets->load_asset_group($this->preference->item('webshop_slideshow'));

// slideshow images$catname = "Slideshow";$slideimages = $this -> MProducts -> getFeatureProducts($catname);$data['slides'] = $slideimages;$data['images'] = $featureimages;$data['title'] = $page['name'];$data['pagecontent'] = $page;$data['page'] = $this->config->item('backendpro_template_shop') . 'frontpage';$data['module'] = lang('webshop_folder');$this->load->view($this->_container,$data);

}

La funzione si occupa di caricare i dati relativi ad ogni singola pagina richiesta e di caricare quindi la vista con la pagina esatta.

38

5.3 Model

Imposta le funzioni base del model. Tutte le classi del model create dall'utente devono estendere tale classe per accedere alle funzioni del model che comunicano col database.class Base_model extends Model{

function Base_model(){

parent::Model();

// Create empty function array$this->_TABLES = array();

log_message('debug','BackendPro : Base_model class loaded');}

5.3.1 Function fetch

Per creare query, si utilizza l'apposita funzione fetch dove basta passare e parametri esatti. La funzione fatch è la seguente:

* access public* param string $name contiene il Nome della Tabella* param mixed $fields contiene la query da ricercare* param array $limit contiene le righe per limitare la ricerca* param mixed $where torna le righe che matchano* return Query Object

39

function fetch($name, $fields=null, $limit=null, $where=null){

$func = '_fetch_'.$name;if(method_exists($this,$func)){

// There is an overide functionreturn call_user_func_array(array($this,$func), array($fields,$limit,

$where));}else{

// No override function, procede with fetch($fields!=null) ? $this->db->select($fields) : '';($where!=null) ? $this->db->where($where) : '';($limit!=null) ? $this->db->limit($limit['rows'],$limit['offset']) : '';

return $this->db->get($this->_TABLES[$name]);}

}

5.3.2 Function Insert

Per inserire dati nella tabella $name si utilizza la seguente funzione:

* access public* param string $name contiene il Nome della Tabella* param array $data contiene i dati da inserire* return Query Object

function insert($name, $data){

$func = '_insert_' . $name;if(method_exists($this,$func)){

// There is an overide functionreturn call_user_func_array(array($this,$func), array($data));

}else{

// No override function, procede with insertreturn $this->db->insert($this->_TABLES[$name],$data);

}}

40

5.3.3 Function Update

Per aggiornare i dati della tabella $name di utilizza la seguente funzione:

* access public* param string $name contiene il Nome della Tabella* param array $values contiene i dati da aggiornare* param mixed $where contiene le righe da aggiornare* return Query Object

function update($name, $values, $where){

$func = '_update_' . $name;if(method_exists($this,$func)){

// There is an overide functionreturn call_user_func_array(array($this,$func), array($values,

$where));}else{

// No overside function, procede with general insert$this->db->where($where);return $this->db->update($this->_TABLES[$name],$values);

}}

41

5.3.4 Function Delete

Per eliminare righe dalla tabella $name si utilizza la seguente funzione:

* access public* param string $name contiene il Nome della Tabella* param mixed $where contiene le righe da cancellare* return Query Object

function delete($name, $where){

$func = '_delete_' . $name;if(method_exists($this, $func)){

// There is an overide functionreturn call_user_func_array(array($this,$func), array($where));

}else{

// No overside function, procede with general insert$this->db->where($where);return $this->db->delete($this->_TABLES[$name]);

}}

42

5.4 View

5.4.1 Sviluppo STEP di acquisto

Si è chiesto di sviluppare una modalità di acquisto dei prodotti come quattro steps che guidano l'acquirente passo a passo.

S T E P 1: Invio Informazioni

Per visualizzare questa pagina, è richiesto il login al sito.

Nella prima fase il cliente può modificare i campi che ha inserito in fase di registrazione

qualora ad esempio nel frattempo abbia cambiato email oppure residenza.

Figura 5.4: Step1 login non effettuato

43

Figura 5.5: Step1 carrello vuoto

Figura 5.6: Step1

44

S T E P 2: Metodo di pagamento

Per visualizzare questa pagina, è richiesta la presenza di almeno un prodotto all'interno del proprio carrello.Son settati visibili solo il metodo di pagamento Bonifico Bancario e Contrassegno ma tuttavia è stato sviluppati anche altri tipi di pagamento (PayPal, Visa,..).

Figura 5.7: Step2

S T E P 3: Conferma

Il metodo di pagamento scelto indirizza alla pagina di pagamento dedicata.

S T E P 4: Fine

Al caricamento della pagina di ordine avvenuto viene spedita automaticamente a cliente una mail col riassunto dei propri dati, dell'ordinazione e della modalità di pagamento scelta. Una copia viene spedita anche all'azienda che potrà così avere una notifica dell'ordinazione.

45

5.4.2 Layout

L'intero Layout del sito è composto dai files:

container.phpheader.phpleft.phpfooter.php

container è così composto:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title><?php echo $title ?></title>

...

<base href="<?php echo base_url(); ?>" />

<link href="<?php echo base_url();?>assets/css/webshop.css" rel="stylesheet" type="text/css" />

</head>

webshop.css è quindi il css che è stato modificato per essere riadattato alle esigenze aziendaliContainer quindi si occupa di chiamare in maniera dinamica le pagine richieste dalla View.

<body> <div id="container"> <?php $this->load->view($this->config->item('backendpro_template_shop') . 'header');?> </div><!--End of container --> <div id="wrapper">

<div class="inside"><div id="main">

<?php print displayStatus();?><?php print (isset($content)) ? $content : NULL; ?><?phpif( isset($page)){if( isset($module)){

$this->load->module_view($module,$page);} else {

46

$this->load->view($page);}}

?></div><!--End of main-->

<div id="left"><!--Start of leftcol --> <?php $this->load->view($this->config->item('backendpro_template_shop')

. 'left');?> </div><!--End of leftcol -->

</div><!--End of inside →…</body>

5.4.3 Validazione sito

Il Progetto è stato caricato in un sito web temporaneo per la validazione XHTML 1.0 TRANSITIONAL

Figura 5.8: W3C Validator

47

48

Capitolo 6

Verifica e valutazione

Il progetto e stato sviluppato in tutte le sue funzioni richieste, desiderate eopzionali.Il database è stato creato per la gestione ottimale di tutti i prodotti e son state create apposite tabelle per poter gestire l'intero sito dal pannello di amministrazione, potendo creare dinamicamente nuove sezioni.Il pannello di amministrazione rende possibile oltre i settaggi del sito, anche la gestione degli utenti e delle ordinazioni.

6.1 Consuntivo

49

Preventivo ConsuntivoStudio Framew ork 20 20Studio CMS 30 30Studio fattibilità e analisi dei requisiti 45 30Ricerca in internet e Progettazione 70 70Definizione prodotto 45 60Sviluppo codif ica 60 40Verif ica e integrazione 50 70TOTALE 320 320

Le ore dedicate allo studio del Framework, della sua architettura e quindi del linguaggio PHP son state perfettamente rispettate a quanto preventivato ad inizio stage.Lo studio di fattibilita e l'individuazione dei requisiti del progetto ha richiesto meno ore di quelle preventivate. Questo grazie all'analisi dei requisiti che si è rivelata piu “semplice” di quello che si pensava inizialmente, grazie anche al fatto che le idee ero ben chiare da parte dell'azienda e che le librerie all'interno framework da me scelto sono complete, sicure e ben documentate.La parte di ricerca in internet di situazioni simili e l'inizio di una progettazione ad alto livello ha richiesto il tempo preventivato, anche se la ricerca ha dato scarsi risultati in quanto il CMS adottato è molto giovane, tuttavia basandosi moltissimo sul pannello BackendPro si son potute trovare molte soluzioni e documentazioni per correggere errori dovuti all'adeguamento del CMS alle esigenze aziendali. Per quando riguarda la progettazione a basso livello e la definizione di prodotto, le ore impiegate sono state maggiori in quanto lo studio delle query e del database ha richiesto piu tempo di quanto inizialmente si pensasse.La fase di sviluppo fortunatamente ha richiesto qualche ora in meno del previsto in quanto si pensava che la scarsa conoscenza del linguaggio PHP (linguaggio mai affrontato prima) fosse di più arduo apprendimento. Per soddisfare l'unico requisito altamente desiderabile ma non obbligatorio si è

50

Studio Framew orkStudio CMS

Studio fattibilità e analisi dei requisitiRicerca in internet e Progettazione

Definizione prodottoSviluppo codif ica

Verif ica e integrazione

0

10

20

30

40

50

60

70

80

Preventivo Consuntivo

speso più tempo del previsto, ma fortunatamente il sottoscritto ha risparmiato un po' di ore nelle fasi precedenti rispetto al preventivo.Trovare un metodo automatico per l'importazione dei listini in formato “ods” (Estensione foglio di Calcolo OpenOffice) all'interno del nuovo database mysql ha richiesto diverse ore di prove e ricerche online di qualche soluzione esistente già adottata da qualcuno. La fase conclusiva di integrazione e verifica ha quindi richiesto tempo di quello preventivato.

6.2 Possibili miglioramenti

L'adottare il Framework Codeigniter in questo progetto ha reso molto sicuro e veloce la gestione di utenti e dati all'interno del sito web, tuttavia se ci fosse stato più tempo si sarebbe potuto soddisfare il requisito facoltativo RF_02, introducendo il modulo CAPTCHA quando l'utente si iscrive o manda una mail dal sito.La libreria viene correttamente caricata ma il passaggio del valore all'interno del box al controller risulta sempre vuota. Non si ha avuto tempo per correggere questo bug. Essendo un requisito opzionale si è scelto di dar la precedenza alla correzione di imperfezioni che avrebbero potuto compromettere il funzionamento dell'intero sistema e di soddisfare il requisito opzionale RF_01 ritenuto più importante da parte dell'azienda.La sezione e-commerce, la gestione dei diversi tipi di pagamento e il layout stesso hanno consumato molte ore, come del resto si era preventivato.

51

6.3 Conclusioni

Nel complesso valuto molto positivamente questa esperienza di stage. Mi ha permesso di entrare attivamente in una attività aziendale, facendomeneconoscere le regole, i ritmi, gli ambiti e le problematiche. Inoltre i ritmi di lavoro non erano mai frenetici e l'ambiente di lavoro era abbastanza sereno.Il progetto da realizzare durante il periodo di stage e stato svolto completamente in tutti i suoi requisiti obbligatori e in gran parte di quelli opzionali.Per lo svolgimento di questo stage ho dovuto apprendere nuove nozioni di programmazione, soprattutto legata al web, e ho potuto mettere in pratica altre nozioni che avevo appreso durante il mio percorso didattico. In questo lavoro ho anche potuto combinare diverse mie conoscenza tra loro, apprese in diversi corsi universitari o durante il primo periodo dello stage. Soprattutto ho avuto il riscontro con un'attività lavorativa.L'azienda ha apprezzato molto la soluzione da me sviluppata e le scelte effettuate in fase di progettazione. Questa esperienza e stata sicuramente positiva e mi aiuterà quando entrerò veramente a contatto con il mondo lavorativo.

52

Bibliografia[1] Paul DuBois. MySQL (4th Edition). Addison-Wesley Professional, 4 edition, 9 2008.

[2] Docmentazione Ufficiale Codeigniter. http://codeigniter.com/user_guide/

[3] Forum Ufficiale di Codeigniter. http://codeigniter.com/forums/

[4] CodeIgniter Wiki http://codeigniter.com/wiki/

[5]Codeigniter shopping cart . http://codeigniter.com/wiki/Codeigniter_shopping_cart/

53