3
Progetto e sviluppo
3.1 Fasi progettuali
Ansaldobreda ha scelto di gestire il finanziamento riservato allo sviluppo di EPC desti-nandone una parte per lo sviluppo immediato sulle commesse per le quali il catalogo elet-tronico rappresentava richiesta esplicita del cliente in modo da mantenere l'allineamento ai Capitolati, ed un'altra finalizzata alle attività di R&D (Research & Development), rap-presentando EPC un prodotto innovativo il cui sviluppo va ad impattare direttamente sulle future commesse.
Il finanziamento è stato quindi suddiviso nel seguente modo:
• Costi diretti del valore complessivo di 800 ore caricate sulle commesse di Madrid, Goteborg, Danimarca ed Olanda-Belgio;
• Costi indiretti del valore complessivo di 800 ore caricate su una commessa interna di Ricerca e Sviluppo (RASI - Richiesta Apertura Sviluppo Interno).
Le fasi del progetto e dello sviluppo sono state le seguenti:
1. Studio delle soluzioni esistenti: fase precedentemente svolta ad inizio attività, durante la quale si erano tenuti incontri con fornitori e clienti al fine di conoscere e valutare lo stato delle applicazioni catalogo esistenti;
2. Stesura della specifica tecnica di EPC: volta a raccogliere l’elenco esaustivo delle funzioni da implementare in EPC (approfondimento in § 3.2);
3. Stesura delle specifiche per i fornitori: volta a definire le regole per il fornitori, per la produzione della lista parti e delle tavole illustrate (approfondimento in § 3.3); 4. Scelta della tecnologia e dei linguaggi di programmazione: include la scelta dei
linguaggi e degli strumenti informatici utilizzati per sviluppare la logica dell’applica-zione (approfondimento in § 3.4);
5. Progetto della base di dati: oltre alla scelta della base di dati, include uno schema ed una descrizione delle tabelle e degli attributi utilizzati (approfondimento in § 3.5); 6. Progettazione dell’architettura software: comprende, oltre all’organizzazione degli
script e delle cartelle, la descrizione di come sono stati affrontate e risolte le principali questioni di programmazione (approfondimento in § 3.6);
7. Criteri di usabilità: riguardano l'interfaccia dell'applicazione con l'utente, motivo per cui è stato fondamentale prendere in considerazione queste tematiche prima di ini-ziare lo sviluppo della grafica dell'applicazione (approfondimento in § 3.7);
8. Creazione del layout grafico: l’interfaccia grafica con l’utente è stata studiata in modo da rispondere ai criteri di usabilità precedentemente introdotti (approfondi-mento in § 3.8).
A queste fasi progettuali è seguito il caricamento dei dati ed il test dell’applicazione, l’installazione presso il cliente e lo svolgimento dei primi test di usabilità con utenti.
3.2 Specifica tecnica di EPC
Dall'analisi delle soluzioni esistenti di fornitori e clienti è stato tracciato un elenco delle funzioni e delle caratteristiche che l'applicazione doveva includere, dal quale è stata suc-cessivamente redatta la specifica tecnica di EPC.
La specifica tecnica si è evoluta nel tempo nonché attraverso le versioni di EPC, tuttavia il core delle funzioni non è mutato nel passaggio da EPC v1 a EPC v2.
Riassumendo il contenuto della specifica, otteniemo requisiti per sviluppare le seguenti pagine Web:
• pagina di accesso (login): permette l’accesso ad EPC ai soli utenti accreditati;
• pagina Struttura: costituisce la pagina principale e permette la navigazione attra-verso i nodi della struttura ad albero propria del catalogo, visualizzandone ad ogni livello la lista dei componenti e di una o più illustrazioni;
• pagina Dettagli: mostra le informazioni di dettaglio relative al componente selezion-ato. Inoltre se si tratta di parte di ricambio permette la sua aggiunta al carrello della spesa;
• pagina Ricerca: consente di effettuare ricerche per disegno o per parte, inserendo uno a più attributi di ricerca. I risultati di ricerca contengono collegamenti diretti ai nodi della pagina Struttura;
• pagina Stampa: permette all'utente di stampare il contenuto di ogni pagina, sia essa il risultato di una ricerca, la lista degli utenti accreditati oppure la struttura del veicolo stessa (liste parti e disegni correlati);
• pagina Acquisto: contiene le “liste della spesa” che ogni utente può creare e gestire; • pagina Modifica (disponibile soltanto in EPC v1): consente di effettuare modifiche
di caratteristiche su singoli componenti;
modi-• pagina Cataloghi: consente di importare nuovi cataloghi in EPC oppure di esportare i cataloghi presenti in formato di lista Excel;
• pagina Aziende (disponibile a partire da EPC v2): l’utente può inserire, modificare o cancellare aziende fornitore o aziende cliente;
La specifica contiene inoltre dettagli sulla gestione delle lingue, elemento fondamentale in considerazione del fatto che la maggior parte dei clienti di AnsaldoBreda sono di pro-venienza internazionale.
La preparazione della lista parti e delle tavole illustrate relative ai cataloghi da importare in EPC sono molto spesso affidate a risorse decentrate, per cui nella specifica si richia-mano come allegati i seguenti documenti, più comunemente noti in gergo aziendale come "specifiche per i fornitori":
• Allegato 1 - Specifica lista parti per catalogo illustrato; • Allegato 2 - Specifica tavole per catalogo illustrato. I contenuti di tali allegati sono descritti in § 3.3.
Infine sono riportate informazioni sulle tecnologie utilizzate per l'esercizio di EPC, quali la tipologia di Server, di Base di dati e di linguaggi di programmazione utilizzati. Tali informazioni sono "anomale" per una specifica tecnica, in quanto dovrebbe essere indi-pendenti dalla tecnologia, tuttavia gli strumenti scelti corrispondono a standard di suc-cesso su scala mondiale, per cui si assume che saranno disponibili per molto tempo e si fa implicitamente riferimento alle versioni citate o superiori degli stessi.
Copia della specifica tecnica di EPC v2 è riportata in “Appendice A - Specifica di EPC”.
3.3 Specifiche per i fornitori
Le specifiche per i fornitori contengono regole pratiche molto dettagliate per compilare la lista parti in modo da essere importata correttamente nel Data Base di EPC e per ottenere tavole illustrate con le caratteristiche di formato, di contenuto e di qualità adeguate alle richieste dei clienti di AnsaldoBreda.
In analogia alle evoluzioni subite dall'applicazione EPC, queste specifiche hanno subito anch'esse un'evoluzione nel tempo, con il duplice obiettivo di agevolare il lavoro del
for-Siamo quindi passati da una specifica di tipo "A", denominata "absolute" per la presenza di riferimenti assoluti alla struttura del veicolo, ad una specifica di tipo "B", denominata "relative" per l'approccio organizzato a gruppi di parti (o tecnicamente "assiemi") alla struttura del veicolo.
3.3.1 Specifica di tipo absolute
La specifica per la compilazione del foglio in formato Excel contenente la lista parti descrive in primo luogo i campi e le regole per il suo corretto riempimento.
Al fine di comprendere il significato dei campi è necessario introdurre il concetto "strut-tura ad albero" di un veicolo. L'albero è composto da "nodi" e ogni nodo rappresenta una parte del veicolo. Posizionandosi su un nodo, come indicato in Figura 3-1 (nodo corrente), questo in generale rappresenta una parte che può essere suddivisa in più componenti, identificati come i nodi “figli” ed appartenenti al livello inferiore (NLA - next lower assembly). Allo stesso modo la parte associata al nodo corrente sarà essa stessa compo-nente, assieme ad altre parti (nodi “fratelli”), di una parte definita nodo “padre” posizio-nata sul livello superiore (NHA - next higher assembly).
Iterando la cellula descritta sopra si ottiene tutta la struttura ad albero. Due tipologie di nodi speciali sono il nodo “radice”, che rappresenta la parte di livello più alto (ovvero il veicolo stesso), e i nodi “foglia”, che rappresentano i componenti non ulteriormente scomponibili (componenti elementari), noti nell’ambito dell’ingegneria logistica come
LRU (Last Replaceable Unit).
Figura 3-1. Struttura ad albero - nomenclatura
padre
nodo fratello LIVELLO CORRENTE LIVELLO SUPERIORE (NHA)
La specifica quindi descrive i seguenti elementi del foglio Excel:
• Riga di intestazione: (prima riga del foglio Excel) contiene i titoli (invarianti) dei campi della lista parti;
• Righe: ogni riga rappresenta un nodo della struttura ad albero del veicolo. Le righe sono generalmente (ma non necessariamente) organizzate in modo top-down ovvero dal generale al particolare.
• Colonne: ogni colonna contiene dati appartenenti alla stessa categoria, che è specifi-cata nella rispettiva cella della prima riga. I campi da riempire sono i seguenti:
- FBS (testuale): contiene un identificativo funzionale che identifica la posizione del nodo nella struttura ad albero (functional breakdown structure);
- DEL (0/1): flag che identifica le righe non più valide (deleted);
- Ref (intero): riferimento numerico della parte associata al nodo corrente, visualiz-zato sulla relativa tavola illustrata;
- PN (testuale): codice principale con cui si identifica la parte associata al nodo cor-rente (part number);
- CPN (testuale): part number del cliente relativo alla parte associata al nodo cor-rente (customer part number);
- Description (testuale): nome o descrizione della parte associata al nodo corrente; - Qty (numerico decimale): quantità della parte associata al nodo corrente;
- mu (testuale): eventuale unità di misura legata alla quantità (es° l=litri, m=metri, Kg=chilogrammi);
- SPN (testuale): part number del fornitore della parte (supplier part number); - Supplier (testuale): nome del fornitore della parte, sta in coppia con il campo SPN; - Spare (0/1): flag che identifica se la parte è una parte di ricambio (1) o meno (0); - Rep (enumerato): lettera che identifica se la parte è riparabile (R) o discardable
(D);
- DWG (testuale): codice della tavola illustrata relativa al nodo corrente; - Title (testuale): titolo della tavolo illustrata;
- Sheet (intero): numero di foglio della tavola illustrata; - Rev (testuale): indice di revisione della tavola illustrata;
- Filename (testuale): indica il nome completo del file della tavola illustrata senza percorso;
- Insertion: data di inserimento del nodo corrente. Serve per tenere traccia delle modifiche apportate alla lista;
Il campo FBS permette di identificare univocamente la posizione del nodo nella
strut-tura ad albero del veicolo. Per una migliore comprensione di questo concetto si osservi
l’esempio riportato in Figura 3-2, nella quale sono visualizzati i seguenti nodi: Figura 3-2. Struttura ad albero - esempio
• FBS = 1: veicolo (nodo radice - livello 0);
• FBS = 1.1: cassa (apparato “figlio” del veicolo - livello 1); • FBS = 1.2: carrello (apparato “figlio” del veicolo - livello 1); • FBS = 1.3: trazione (apparato “figlio” del veicolo - livello 1);
• FBS = 1.4: comunicazione (apparato “figlio” del veicolo - livello 1);
• FBS = 1.2.1: carrello motore (sotto-apparato “figlio” del carrello - livello 2); • FBS = 1.2.2: carrello portante (sotto-apparato “figlio” del carrello - livello 2); • FBS = 1.2.1.1: sospensione primaria (assieme “figlio” del carrello - livello 3); • FBS = 1.2.1.2: sospensione secondaria (assieme “figlio” del carrello - livello 3); • FBS = 1.2.1.3: montaggio freni (assieme “figlio” del carrello - livello 3);
• FBS = 1.2.1.3: montaggio freni (assieme “figlio” del carrello - livello 3);
1.1 1.2 1.2.1 1.2.2 1 1.3 1.2.1.1 1.2.1.2 1.2.1.3 VEICOLO CASSA CARRELLO TRAZIONE CARRELLO PORTANTE CARRELLO MOTORE SOSPENSIONE PRIMARIA SOSPENSIONE SECONDARIA MONTAGGIO FRENI 1.4 COMUNICAZIONE 1.2.1.3.1 1.2.1.3.2 1.2.1.3.3 PASTIGLIA FRENO SX PASTIGLIA FRENO DX VITE M6x8 1.2.1.3.4 1.2.1.3.5 DADO M6 PINZA FRENO radice foglie
• FBS = 1.2.1.3.1: pastiglia freno sx (componente “figlio” del montaggio freni - livello 4);
• FBS = 1.2.1.3.2: pastiglia freno dx (componente “figlio” del montaggio freni - livello 4);
• FBS = 1.2.1.3.3: vite M6x8 (componente “figlio” del montaggio freni - livello 4); • FBS = 1.2.1.3.4: dado M6 (componente “figlio” del montaggio freni - livello 4); • FBS = 1.2.1.3.5: pinza freno (componente “figlio” del montaggio freni - livello 4). Quindi la regola è che i "figli" di un nodo hanno codice che si ottiene da quello del nodo “padre” seguito da un punto "." e da un indice numerico progressivo a partire da “1”. Sempre secondo la specifica le “parti” sono identificate da una delle seguenti combina-zioni:
• (PN): è presente il part number principale AnsaldoBreda;
• (SPN, Supplier): è presente il supplier part number ed il fornitore associato; • (PN, SPN, Supplier): rappresenta il caso di doppia codifica;
• (CPN): opzionalmente è presente il customer part number, ma deve essere accompa-gnato da una delle precedenti combinazioni.
Va sottolineato che una stessa parte può essere associata a nodi diversi in posizioni anche molto distanti nella struttura ad albero, quindi in generale il data base sarà popolato da un numero totale di nodi superiore al numero totale di parti distinte.
Per quanto riguarda i “disegni” è necessario fare una premessa. Dovendo rappresentare sistemi anche molto complessi, accade spesso che le dimensioni di una singolo foglio non sono sufficienti per rappresentare un blocco funzionale. In questi casi quindi si utilizzano tavole multi-foglio, caratterizzate da un unico codice e più fogli distinti. Ogni foglio cor-risponde ad una figura diversa, quindi sono necessari i seguenti campi per descrivere tutte le possibili situazioni:
• (Filename): identifica univocamente una figura nella cartella dove sono collocate tutte le illustrazioni del veicolo;
• (DWG, Sheet): indica il codice della tavola ed il foglio preso in considerazione. Nel caso di singolo foglio ci sarà un’unica figura corrispondente, nel caso di multi-foglio ci saranno tante figure quanti sono i fogli associati allo stesso codice
Riguardo al campo riferimento “Ref” è importante sottolineare che è un numero che lega il nodo (e non la parte associata) al disegno in cui tale nodo è visualizzato, quindi ad ogni nodo sarà sempre associato un disegno di assieme superiore.
La specifica per la lista parti contiene altri dettagli, oltre alle istruzioni per trattare i casi particolari, i quali possono essere omessi ai fini della presente trattazione.
La specifica per la creazione delle tavole include le seguenti tipologie di requisiti:
• requisiti di formato: identifica i formati vettoriali, quando disponibili, da preferire ai formati flat (immagine piatta) alla consegna delle tavole;
• requisiti di contenuto: indica che le immagini devono essere realizzate in vista asso-nometrica esplosa (exploded view), la quale è globalmente riconosciuta come la tec-nica più efficace per mostrare la scomposizione di una parte nei suoi componenti. Inoltre sono richiesti riferimenti (campo Ref) sulle tavole ad incremento a decadi ed ordinati secondo la sequenza di smontaggio;
• requisiti di qualità: riguardano principalmente le tavole consegnate come immagini: - risoluzione: la risoluzione consigliata è di 150 dpi per le immagini in bianco/nero
e 300 dpi per le immagini in colore. Risoluzioni superiori sono ammesse solo se si rispetta il requisito di dimensione;
- forma: la forma delle immagini deve favorire la dimensione orizzontale (imma-gine “larga”) in un rapporto da 1.20:1 a 1.40:1 con la dimensione verticale;
- dimensione: la dimensione delle tavole deve essere contenuta entro i 2 MB;
- nitidezza: immagini contenenti sfondi “sporchi” o punteggiati come ad esempio risultato di acquisizione da scanner sono vietate;
- definizione: le immagini devono avere contorni ben definiti fino ad ingrandimenti del 400%, in modo da permettere una chiara lettura;
- orientamento: immagini leggermente ruotate come ad esempio risultato di acqui-sizione da scanner sono vietate;
• requisiti di consegna: le tavole devono essere consegnate in un’unica cartella non sotto-strutturata.
3.3.2 Specifica di tipo relative
La specifica di tipo “relative” è comparsa con EPC v2 e rappresenta un’evoluzione nel modo di rappresentare i nodi nella struttura ad albero.
La specifica quindi descrive i seguenti elementi del foglio Excel:
• Righe: ogni riga rappresenta un nodo della struttura ad albero del veicolo. Le righe sono necessariamente organizzate in modo top-down;
• Colonne: ogni colonna contiene dati appartenenti alla stessa categoria, che è specifi-cata nella rispettiva cella della prima riga. I campi da riempire sono i seguenti:
- SEQ (R/A/numerico): contiene un identificativo funzionale che identifica la strut-tura ad albero veicolo;
- DEL (0/1): flag che identifica le righe non più valide (deleted);
- Ref (intero): riferimento numerico della parte associata al nodo corrente, visualiz-zato sulla relativa tavola illustrata;
- PN (testuale): codice principale con cui si identifica la parte associata al nodo cor-rente (part number);
- CPN (testuale): part number del cliente relativo alla parte associata al nodo cor-rente (customer part number);
- Description (testuale): nome o descrizione della parte associata al nodo corrente; - Qty (numerico decimale): quantità della parte associata al nodo corrente;
- mu (testuale): eventuale unità di misura legata alla quantità (es° l=litri, m=metri, Kg=chilogrammi);
- SPN (testuale): part number del fornitore della parte (supplier part number); - Supplier (testuale): nome del fornitore della parte, sta in coppia con il campo SPN; - Spare (0/1): flag che identifica se la parte è una parte di ricambio (1) o meno (0); - Rep (enumerato): lettera che identifica se la parte è riparabile (R) o discardable
(D);
- DWG (testuale): codice della tavola illustrata relativa al nodo corrente; - Title (testuale): titolo della tavolo illustrata;
- Sheets (intero): numero totale di fogli della tavola illustrata; - Rev (testuale): indice di revisione della tavola illustrata;
- Filename (testuale): indica il nome completo del file della tavola illustrata senza percorso;
- Insertion: data di inserimento del nodo corrente. Serve per tenere traccia delle modifiche apportate alla lista.
Come si può notare il campo FBS è stato rimpiazzato dal campo SEQ (sequential), che attraverso il proprio valore identifica la struttura ad albero del veicolo nel seguente modo: • “A” (assembly): indica che la riga rappresenta un nodo assieme, ovvero un nodo
padre, i cui figli sono espressi dai SEQ numerici delle righe precedenti a partire dal valore “1”;
• “R” (root): indica che la riga rappresenta il nodo assieme “radice” di tutto il veicolo. Per il resto si comporta come il caso precedente;
• “1”, “2”, “3”, ... (numerico progressivo): indica che il nodo è un nodo “figlio”. Il suo nodo “padre” si trova nella prima riga successiva che porta il valore SEQ = “A” oppure SEQ = “R”.
In questo caso è mandatario che le righe siano organizzate in modo top-down, ed in par-ticolare che a parte la riga radice (“R”), ogni altro assieme deve essere istanziato come figlio in una riga precedente a quella in cui è dichiarato come riga assieme (“A”). Se non si rispetta la condizione si ottiene un “ramo” disconnesso dal resto dell’albero, in quanto il nodo “padre” non risulta comparire tra i figli di nessun altro nodo precedente.
Le righe “assieme” (con SEQ=”R” o SEQ=”A”) rappresentano soltanto una relazione di parentela, sono pertanto dei nodi fittizi per i quali non deve essere specificato né riferi-mento sulla figura (Ref), né quantità (Qty) e unità di misura (mu).
Il campo “sheet” (numero di foglio della tavola) è stato sostituito dal campo “sheets” (numero totale di fogli della tavola), per il motivo che segue. Le tavole illustrate sono associate soltanto alle righe “assieme”, le quali sono uniche, pertanto è possibile associare soltanto un filename ad ogni nodo. Quindi nel caso di tavola multi-foglio si inserisce sol-tanto il filename dell’ultimo foglio, mentre tutti gli altri filename vengono dedotti dalla tupla (DWG, Sheets, Rev, Filename). Infatti questa specifica richiede che i filename siano scritti nel seguente modo:
<nome_disegno>_Txxx_Ryy.<estensione> dove:
Txxx = numero di foglio, sempre di tre cifre a partire da 001 Ryy = revisione del foglio, sempre di due cifre a partire da 00
Oltre alle differenze sopra descritte, la specifica "relative" non ne presenta altre con la specifica "absolute".
La specifica "relative" è stata benevolmente accolta con da parte dei fornitori, i quali non sono più costretti ad inserire un FBS unico per ogni nodo dell'albero anche nei casi in cui un'assieme (e tutti i suoi discendenti) era ripetuto identico in una posizione diversa dell'albero, oppure nei casi in cui un intero assieme doveva essere spostato altrove.
Inoltre le ripetizioni di interi blocchi introducevano inevitabilmente errori per cui questa nuova specifica ha portato anche ad un sensibile incremento della qualità.
3.4 Tecnologia e linguaggi di programmazione usati
3.4.1 Programmazione lato Server
EPC consiste in una serie di pagine Web dinamiche, il cui sviluppo lato Server è stato pen-sato fino dalla sua origine in linguagio PHP, scartando gli altri candidati ASP, JSP, Perl e Python.
Figura 3-3. PHP logo
Una breve descrizione reperita sul Web è la seguente:
PHP is an open-source, HTML-embedded server-side scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of unique PHP-specific featu-res thrown in. The goal of the language is to allow web developers to write dynamically generated web pages qui-ckly.
“PHP è un linguaggio di libero utilizzo, lato Server, per realizzare script HTML annidati. Grossa parte della sua sintassi è presa dal linguaggio C, Java e Perl, con l’aggiunta di alcune caratteristiche specifiche. Il risultato del linguaggio è quello di permettere agli Svi-luppatori Web di scrivere rapidamente pagine Web dinamiche”.
ASP (Active Server Page) è stato immediatamente scartato in quanto è proprietario
Microsoft, per cui funziona esclusivamente su Server IIS e su sistemi operativi Windows.
JSP (Java Server Pages) è conosciuto come un linguaggio adatto a prodotti di alto livello,
come ad esempio strutture di home-banking o e-commerce a livello internazionale. Non ha senso il suo utilizzo per i livelli medio-bassi in quanto ha una curva di apprendimento piuttosto ripida, oltre a costi quasi improponibili per l'hosting.
PERL (Pratical Extraction and Report Language) è comunemente ritenuto un linguaggio
interpretato, dove ogni istruzione viene decodificata e implementata al momento dell’ese-cuzione. In realtà, la prima cosa che fa l’interprete è trasformare il codice sorgente in un formato intermedio (bytecode) che può essere ottimizzato. Questo approccio permette di limitare la lentezza instita nella natura dei linguaggi interpretati. Se da un lato viene apprezzato per la possibilità che esso offre di scrivere programmi, dall’altro viene giudi-cato negativamente per il fatto che esso permette la scrittura di programmi difficili da leg-gere e quindi rende complicata la loro manutenzione.
Python secondo la comunità dei programmatori è un linguaggio intuitivo, elegante e
pra-tico, tutte qualità che favoriscono la manutenzione del codice. Non è stato scelto per questo progetto solo perchè sarebbe stato necessario un apprendimento dalle basi, mentre il PHP già assicurava garanzie precise su un suo efficace ed immediato utilizzo.
3.4.2 Programmazione lato Client
Per la programmazione lato Client è stato fatto largo uso di JavaScript v1.2. Nel dettaglio è stato impiegato per le funzioni di:
• submit realizzati con pulsanti ed ancore (in pratica tutti eccetto quelli del menu); • visualizzazione delle immagini nella finestra principale;
• cambio dell’immagine visualizzata sull’evento onChange della dropdown list • ridimensionamento delle immagini (al variare della dimensione della finestra); • toggle di visualizzazione del pannello di stampa catalogo;
• stampa delle liste nelle pagine “ricerca”, “acquisto”, “utenti” e “aziende”; • riga evidenziata sulle tabelle con gli eventi onMouseOver e onMouseOut.
In pratica senza il JavaScript attivato è impossibile compiere qualsiasi operazione, inclusa quella di accesso ad EPC stesso. Per tale motivo, nel caso l’utente non dovesse avere JavaScript attivo, è stato predisposto un tag <noscript> nella pagina di login:
This application works only with JavaScript enabled!
Questa clausola, che negli anni ‘90 sarebbe stata fatale per molti utenti, è oggi pratica-mente trascurabile, in quanto i casi di JavaScript non abilitato sono divenuti ormai dav-vero rari.
3.4.3 Web Server
La scelta del Web Server è ricaduta su Apache v2.2, un programma open source larga-mente diffuso e gratuito anche per usi commerciali.
Figura 3-4. Apache logo
Le impostazioni di Apache possono essere modificate attraverso il file di configurazione httpd.conf come ad esempio l’host e la porta di ascolto, oppure la cartella dove si trovano tutti i documenti dell’applicazione Web (DocumentRoot).
Sempre tramite il file di configurazione è possibile attivare innumerevoli moduli di per-sonalizzazione al fine di adattare Apache alle esigenze di qualunque servizio, come ad esempio il modulo per il supporto di PHP:
LoadModule php5_module "${path}/php/php5apache2_2.dll"
La scelta di Apache tuttavia, pur essendo la soluzione più comoda e “raccomandata”, avrebbe incontrato la resistenza di alcuni clienti, i quali dispongono di un Server aziendale alternativo, già comunemente utilizzato quale supporto le altre applicazioni aziendali (come intranet, data base di progetto e di produzione), ed hanno posto quindi il veto sull’introduzione di un ulteriore Web Server, peraltro non gestito dai loro Sistemi Infor-mativi.
Questo è il caso del cliente spagnolo (Metro Madrid) e di quello svedese (Sirio Goteborg), i quali dispongono del pacchetto Internet Information Service (IIS) v6, incluso nel sistema operativo Microsoft Windows Server 2003. In questo caso i clienti hanno fatto pressioni affinché l’applicazione EPC potesse essere installata su Server IIS, anziché su Server Apache. Pertanto la specifica di EPC è stata arricchita di questa alternativa, è stata approntata una procedura di installazione su IIS e sono state eseguite le verifiche e le con-figurazioni necessarie, come descritto in § 4.2.1.
3.5 Base di dati
database più popolari, open source e prodotti commerciali simili, come mostrato nella seguente tabella:
Nota: FF = Flat file, R = Relazionale, O-R = Relazionale ad oggetti, C = Commerciale, OS = Open source; Sh = Shareware, Win = MS Windows
Alcuni database commerciali molto popolari, come Filemaker Pro e Microsoft Access, non sono stati progettati per essere utilizzati come back end di un sito Web di produzione. Nonostante abbiano un livello di supporto ODBC abbastanza elevato, e di conseguenza PHP può in teoria ottenere i dati da essi, sono stati progettati principalmente per la facilità di utilizzo più che per la velocità. Infine, questi database di solito non dispongono dei thread, dei blocchi e di altre caratteristiche di produzione.
Riguardo alla connessione esistono due API generiche standard di accesso al database: Open Database Connectivity (ODBC) e Java Database Connectivity (JDBC). ODBC è strettamente collegata a Microsoft e JDBC è ancora più saldamente legata a Sun Micro-systems. ODBC e JDBC sono più o meno mutuamente esclusive.
Tabella 3-1. DataBase supportati da PHP
DataBase Tipo Supporto Piattaforma Licenza Commento
Adabas D R ODBC (dis) Unix,Win C Tedesco, disponibile con la
distribuzione SuSe Linux
DBA/DBM FF Unix OS/C Sleepycat, GNU dbm, cdb
dBase R solo importaz. Win C No SQL
Empress R ODBC/JDBC Unix, Win C Aziendale
FileMaker Pro R solo importaz. Unix, Win C Non per la produzione
IBM DB2 R ODBC/JDBC Unix, Win C Aziendale
Informix R nativo Unix, Win C Aziendale
Interbase R nativo/JDBC Unix, Win C Aziendale
MS Access R ODBC Win C Non per la produzione
MS SQL Server R nativo Win C Aziendale
mSQL R nativo Unix Sh molto piccolo
MySQL R nativo Unix, Win OS/C
Oracle R nativo Unix, Win C Aziendale
Oracle8 R nativo Unix, Win C Aziendale, integrazione di Java
PostreSQL O-R nativo Unix OS/C
Solid R ODBC dis. Unix, Win C
Ci sono anche database a cui possono accedere i Client attraverso le loro API invece che sfruttando ODBC o JDBC. Questa operazione è sicuramente più veloce poiché ci sono meno livelli nello stack. La maggior parte dei database open source rientra in questa cate-goria. Alcuni di questi per una maggiore flessibilità dispongono anche dei anche i driver ODBC o JDBC.
I thread e i blocchi impediscono che due chiamate al database interferiscano l’una con l'altra, fornendo il controllo editoriale solo a una singola transazione alla volta. Il database ha bisogno di alcuni modi per riconoscere le richieste uniche e permettere che solo un utente (o thread) esegua le modifiche in un qualsiasi momento stabilito, mentre gli altri vengono bloccati finché non è stata completata la prima transazione. A questo proposito il paradigma transazionale conta su assegnazioni e rollback. Le transazioni concluse con successo verranno assegnate al database. Quelle che non hanno avuto successo non ver-ranno salvate, o il database verrà riportato alla sua condizione precedente.
Gli indici rappresentano un modo per velocizzare le ricerche di grandi set di dati. Se si tengono milioni di parti sarà estremamente lento per un database trovarne una in base al codice, perché il programma dovrà esaminare ciascuna voce presente nel campo del codice e confrontarlo con la stringa che si sta cercando. Un indice posizionato su quella colonna permetterà al database di eseguire la ricerca solo in una parte del set di dati, e questo porterà ad una sensibile riduzione dei tempi della ricerca.
Per EPC è stato scelto MySQL v5, in quanto veloce, open source (distribuito sotto licenza GPLv2), facile da usare ed affidabile, inoltre possiede la maggior parte delle funzioni necessarie come transazioni, indici ed una GUI Web facile da utilizzare come PHPMyAd-min.
Figura 3-5. MySQL logo
La base di dati progettata per EPC si basa su tre entità principali:
pertanto è in relazione “uno ad uno” con la tabella Parts. Ogni nodo può comparire su più di un disegno, ed egualmente un disegno può illustrare la posizione di molti nodi, per cui i nodi sono posti in relazione “molti a molti” con la tabella Drawings tramite la tabella Presence, che indica appunto la presenza di un nodo su un disegno;
• Parts: contiene l’elenco non strutturato di tutte le parti (distinte) disponibili; • Drawings: contiene l’elenco non strutturato di tutte le tavole illustrate disponibili. Mentre con EPC v1 le precedenti entità venivano popolate con altrettante scansioni com-plete della lista parti (Excel), con EPC v2 sono state introdotte due tabelle per ridurre i tempi di importazione effettuando un’unica lettura dalla lista parti:
• Imports: utilizzata esclusivamente con la specifica di tipo “absolute” come conteni-tore dove vengono riversati tutti i dati della lista parti prima di essere smistati nelle opportune tabelle;
• Partlists: utilizzata esclusivamente con la specifica di tipo “relative” come conteni-tore dove vengono riversati tutti i dati della lista parti prima di essere smistati nelle opportune tabelle;
Figura 3-6. Schema di importazione nel DB
Anche la tabella Companies è stata introdotta a partire da EPC v2 per gestire la coesi-stenza dei cataloghi di più clienti diversi operando la necessaria separazione dei rispettivi dati.
L’elenco completo delle tabelle con i relativi attributi è riportato in seguito e tutte le rela-zioni tra tabelle sono mostrate in Figura 3-7.
IMPORTS Data Base core PARTLISTS LISTA PARTI EXCEL specifica “absolute” LISTA PARTI EXCEL specifica “relative”
Figura 3-7. Base di Dati di EPC v2
• ACCOUNTS (iduser, username, password, level, lang, idcomp); • BASKETS (idbasket, pn, qty);
• CATALOGUES (idcat, idcomp, catname, catcode, impfile, mode); • COMPANIES (idcomp, compname, compcode, type, coun); • COUNTRIES (coun, name, lang, language);
• CUSTOMS (pn, cpn, idcomp);
• DRAWINGS (iddwg, dwgnum, sheet, title, rev, filename); • NODES (idnode, idcat, idparent, fbs, pn, ref, qty, mu, line); • PARTS (pn, partname, spare, rep);
• PRESENCE (idnode, iddwg);
accounts PK iduser username password level FK2 lang FK1 idcomp baskets PK,FK2 idbasket PK,FK1 pn qty catalogues PK idcat FK1 idcomp catname catcode impfile mode companies PK idcomp compname compcode type FK1 coun countries PK coun name lang language customs PK,FK2 pn PK cpn PK,FK1 idcomp drawings PK iddwg dwgnum sheet title rev filename imports PK idimports line idcat del fbs parent ref pn cpn description qty mu spn supplier spare rep dwgnum title rev sheet filename insertion nodes PK idnode FK2 idcat FK3 idparent fbs FK1 pn ref qty mu line partlists PK idpartlists line idcat del seq assy ref pn cpn description qty mu spn supplier spare rep dwgnum title rev sheets filename insertion parts PK pn partname spare rep presence PK,FK1 idnode PK,FK2 iddwg shoplists PK idshop name description FK1 owner supplies PK,FK1 pn PK spn PK,FK2 idcomp
• SUPPLIES (pn, spn, idcomp);
• IMPORTS (idimports, line, idcat, del, fbs, parent, ref, pn, cpn, description, qty, mu, spn, supplier, spare, rep, dwgnum, title, rev, sheet, filename, insertion);
• PARTLISTS (idpartlists, line, idcat, del, seq, assy, ref, pn, cpn, description, qty, mu, spn, supplier, spare, rep, dwgnum, title, rev, sheet, filename, insertion)
3.6 Architettura software
La struttura di EPC v1 ed EPC v2 ha un livello di frammentazione medio-basso. Le pagine Web, realizzate in PHP, si trovano tutte sulla root e contengono HTML e PHP mischiati, oltre ad alcune funzioni sviluppate in Javascript. Allo stesso livello si trovano anche i fogli di stile (file .css).
Le cartelle sono strutturate in modo da separare le informazioni per tipologia, come segue: • drawings: cartella che contiene le figure di ogni catalogo, a loro volta strutturate in
cartelle nominate secondo il codice catalogo;
• export: cartella di default in cui esportare i cataloghi inseriti (file Excel .xls);
• images: cartella che contiene le immagini e le icone utilizzate nello stile delle pagine; • import: cartella di default in cui si conservano i file Excel .xls dei cataloghi importati; • info: contiene una serie di script di fondamentale importanza, tra i quali:
- engine.php: script di collegamento al Data Base, dove sono raccolte le query; - start.php: script di configurazione, login, avvio sessioni, connessione al DB, etc; - init.php: script di protezione dall’accesso di utenti non autorizzati;
- menu.php: contiene il menu (bottoni) localizzato in alto nella pagina; - flags.php: script di impostazione dei files di lingua;
• lang: cartella che contiene i files di lingua (con relative icone);
• log: cartella che contiene i log di importazione dei cataloghi. Tiene traccia di qualsiasi anomalia riscontrata durante l’importazione;
Figura 3-8. EPC2 - Struttura dei files
3.6.1 Protezione degli accessi
Fin dalla prima versione EPC implementa un sistema di protezione “incrementale”, che ha come obiettivo da un lato quello di evitare l’intrusione di utenti non autorizzati e dall’altro di assegnare agli utenti registrati un livello di accesso, che consente loro soltanto le funzionalità previste per tale livello.I livelli sono strutturati come segue:
Tabella 3-2. EPC v1 - livelli di accesso
Livello
indice dettaglio
* la pagina “modifica”, originariamente introdotta per modificare attributi di parti e disegni è stata in seguito eliminata
EPC v2 aggiunge una nuova tipologia di utenti che permette quindi la distinzione tra utenti AnsaldoBreda ed utenti del cliente. Questo perchè EPC viene pensato per un'instal-lazione centralizzata, usufruibile contemporaneamente dai diversi clienti tramite accesso remoto. A tal fine i dati devono essere correttamente separati in modo da evitare spiace-voli situazioni in cui ad esempio un cliente si trovi ad aver accesso a cataloghi di un altro cliente.
Tabella 3-3. EPC v2 - livelli di accesso
Nota: con il termine limitata si intende che gli utenti del cliente hanno visibilità e possibilità di manovra solo entro i dati relativi ad i propri cataloghi e riguardo agli utenti relativi alla propria azienda. Utenti AnsaldoBreda (AB) invece non sono soggetti a tale restrizione
2 Consulente Sì Sì No No No No No 3 Tecnico Sì Sì Sì No No No No 4 Gestore Sì Sì Sì Sì No No No 5 Sviluppatore Sì Sì Sì Sì Sì No No 6 Amministratore Sì Sì Sì Sì Sì Sì Sì 7 Webmaster Sì Sì Sì Sì Sì Sì Sì Livello Tipo indice dettaglio
ricerca stampa acquisto utenti import. aziende
1 Visitatore cliente limitata No No No No No
1 Visitatore AB Sì No No No No No
2 Consulente cliente limitata limitata No No No No
2 Consulente AB Sì Sì No No No No
3 Gestore cliente limitata limitata limitata Sì No No
3 Gestore AB Sì Sì Sì Sì No No
4 Amministratore cliente limitata limitata limitata limitata limitata No
4 Amministratore AB Sì Sì Sì Sì Sì No
5 Specialista cliente limitata limitata limitata limitata limitata limitata
5 Specialista AB Sì Sì Sì Sì Sì Sì
6 Webmaster - Sì Sì Sì Sì Sì Sì
Livello
indice dettaglio
3.6.2 Soluzione per le lingue
AnsaldoBreda vanta una clientela internazionale, per cui si è resa necessaria la traduzione di tutte le etichette del sistema, ovvero i menù, i bottoni, i titoli ed i messaggi (eventi ed errori).
In particolare tra le lingue attualmente disponibili ci sono, oltre ovviamente all’italiano e all’inglese, anche il francese, lo spagnolo e lo svedese. Inoltre è stata fatta distinzione tra l’inglese (English) e l’americano (US English), in quanto alcuni termini tecnici differi-scono sensibilmente.
A livello di codice la soluzione adottata, comune a tutte le versioni di EPC, è quella di utilizzare un array bidimensionale (matrice), identificato come segue:
$LANG[‘<gruppo>’][‘<identificatore>’]
dove:
$LANG è il nome della variabile;
<gruppo>: area comune ad un certo numero di stringhe (ad esempio utenti, aziende); <identificatore>: termine o insieme di termini significativo che identifica la stringa tradotta.
I “file di lingua” sono identificati da un codice letterale a due caratteri, seguito ovviamente dall’estensione “.php”, che identifica il tipo di file:
• it.php: italiano;
• en.php: inglese (Regno Unito); • es.php: spagnolo;
• fr.php: francese; • sv.php: svedese; • us.php: inglese (USA);
I “file di lingua” sono strutturalmene identici, contengono infatti tutti quanti le stesse variabili “$LANG” nella parte sinistra. A destra degli assegnamenti invece la traduzione è chiaramente differente per ciascuno dei file.
Questa scelta consente una facile traduzione, in quanto viene inviato il file con la lingua sorgente e viene richiesto al traduttore di operare soltanto sulle stringhe tra doppi apici nella parte destra del file.
dise-gono in larga maggioranza parole tecniche della terminologia ferroviaria, e più in generale della meccanica, dell'elettrica e dell'elettronica. Per questo per tale operazione Ansaldo-Breda si avvale della collaborazione di un fornitore di servizi, che realizza le traduzioni ad hoc, utilizzando personale qualificato e dizionari tecnici specifici. Inoltre per tali tra-duzioni viene adoperato un applicativo che importa ed estende un dizionario specifico del cliente, in modo che gli stessi termini vengano tradotti sempre in maniera analoga.
3.6.3 Nucleo dell’applicazione: il caricamento dei dati
Il caricamento di un catalogo costituisce senza dubbio l’operazione più lunga e delicata disponibile su EPC. Attraverso tale operazione il contenuto di un file in formato Excel, preparato secondo la specifica della lista parti, viene importato nel Data Base, strutturato nelle tabelle predisposte.
Anche in questo caso il passaggio alle versioni successive di EPC ha apportato migliora-menti sensibili alla tecnica di importazione, i quali si riflettono nei seguenti vantaggi: • diminuzione del tempo di importazione;
• miglioramento della robustezza della procedura; • generazione di un registro eventi;
• introduzione di indicatori di processo.
EPC v1 importa i cataloghi nel Data Base con diversi passaggi in lettura del file Excel, attraverso ognuno dei quali vengono popolate la tabelle delle parti (“parts”), dei disegni (“drawings”), dei nodi della struttura ad albero (“nodes”) e delle corrispondenze tra nodi e disegni (“presence”).
EPC v2 importa i cataloghi nel Data Base attraverso un’unica lettura del file Excel, memorizzandone i dati in una nuova tabella (“imports”), i cui attributi sono identici ai titoli delle colonne stesse del file Excel. Quindi il file Excel viene chiuso e la successiva fase, in cui vengono popolate le altre tabelle, consiste di soli passaggi interni al Data Base. Questo comporta un minore utilizzo delle risorse dinamiche del Server e soprattutto un tempo inferiore per l’importazione stessa.
3.7 Criteri di usabilità
3.7.1 Definizione
L'usabilità è la misura della qualità dell'esperienza dell'utente quando interagisce con un prodotto o sistema, che potrebbe essere un sito Web, una applicazione eseguibile, tecno-logia mobile od ogni altro strumento con cui l'utente interagisce.
L'usabilità è una combinazione di fattori, di seguito elencati, che influiscono sull'espe-rienza che un utente acquisisce interagendo con prodotti o sistemi a sua disposizione: • Facilità di apprendimento: indica quanto velocemente un utente riesce ad
appren-dere le funzionalità dell'interfaccia, svolgendo agevolmente le operazioni di base, senza averla mai vista precedentemente;
• Efficienza d'uso: indica quanto velocemente puo' un utente compiere le operazioni sul sistema una volta compresi i suoi meccanismi di utilizzo;
• Memorizzazione: esprime la probabilità di memorizzazione dei meccanismi di uti-lizzo e dell'interfaccia da parte dell'utente in seguito al primo utiuti-lizzo;
• Frequenza di errore e gravità dell'errore: indica la frequenza con la quale un utente compie errori nell'uso del sistema, la gravità degli errori e le modalità con le quali l'utente riesce a rimediarvi;
• Soddisfazione soggettiva: indica quanto risulta piacevole all'utente l'uso del sistema. Le ricerche di User Interface Engineering, Inc., mostrano che nel 60% dei casi le persone non riescono a trovare l'informazione che stanno cercando in un sito Web. Questo deter-mina perdita di tempo, riduzione di produttività, aumento di senso di frustrazione, perdita di visitatori che non ritornano più al sito Web e conseguentemente una riduzione di pro-fitto [13].
Nel caso di EPC il rischio maggiore è quello che l'applicazione non risulti di facile appren-dimento, efficiente e di soddisfacente utilizzo da parte dell'utente finale. Questo porte-rebbe ad una conseguente resistenza all'introduzione in azienda ed al suo utilizzo effettivo. Una situazione come questa sarebbe disastrosa motivo per cui deve essere evi-tata ad ogni costo. Questo spiega il ruolo chiave che l'usabilità riveste in questo progetto. Al contrario se invece adottiamo un approccio UCD (User Centered Design) alla proget-tazione di EPC e riusciamo ad ottenere un prodotto che funziona per l'utente, la soddisfa-zione ed il desiderio di utilizzo saranno di aiuto per un’immediata e capillare distribusoddisfa-zione
3.7.2 Compatibilità con i Browsers
Gli utenti di EPC hanno a disposizione mezzi molto differenti per composizione hardware ed architettura software (sistema operativo), per cui il sito è stato testato su diverse piat-taforme.
La grafica delle pagine Web è stata progettata in modo da essere visualizzata corretta-mente con i Web Browsers associati ai sistemi operativi maggiorcorretta-mente diffusi (Windows,
Unix/Linux, MacOS). A tal fine il sito è stato testato con i seguenti Browsers:
• Internet Explorer v6.0 o superiore; • Firefox v2.0 o superiore;
• Opera v7.0 o superiore; • Netscape v4.0 o superiore; • Safari v2.0 o superiore.
Per implementare le diverse parti del sito Web è stata utilizzata la seguente combinazione di linguaggi standard :
• HTML v.4 transitional: struttura delle pagine; • CSS v.2: fogli di stile;
• JavaScript v.1.2: programmazione lato Client;
In particolare per quanto riguarda il JavaScript per EPC v1 e EPC v2 sono state utilizzate funzioni semplici e generalmente ben supportate, quali il “getElementById” e gli eventi del mouse, evitando quelle funzioni che non vengono interpretate da alcuni Web Brow-sers.
Riguardo all'utilizzo del CSS particolare attenzione è stata rivolta alla scelta degli attributi da utilizzare ed in particolar modo per quelli da evitare attentamente. Ad esempio è stato evitato l’uso dell’attributo “z-index” e del “position: static”, in quanto non supportati da uno o più Browsers. A causa di queste limitazioni il Web Designer è costretto a ingegne-rizzare lo stile del sito Web con un set di parametri ridotto, richiedendo in alcuni casi di dover limitare gli effetti grafici realizzati.
L’introduzione del CSS v.3 dovrebbe dotare il Web Designer di strumenti più efficaci per la propria creazione grafica. Allo stesso tempo la progressiva scomparsa delle versioni più
data con i diversi Browsers. Ad esempio Internet Explorer v.8.0 e Mozilla Firefox v.3.0 prevedono l’autoscaling delle immagini, effetto che con le precedenti versioni deve essere invece programmato in Javascript.
3.7.3 Supporto alle diverse prestazioni di connessione
La fruizione dell'applicazione EPC da parte del cliente può avvenire in due modi:
1. Attraverso una intranet aziendale nel caso in cui si provveda ad un’installazione locale presso il cliente;
2. Attraverso una connessione remota nel caso in cui l’applicazione resti in hosting presso AnsaldoBreda.
Mentre nel primo caso solitamente la banda disponibile è molto elevata e quindi la navi-gazione solitamente è ottimale, nel caso di hosting remoto, a parte la qualità della connes-sione tra la rete del cliente e quella di AnsaldoBreda, l’applicazione EPC deve avere contenuti tali da richiedere la minore quantità di banda possibile. Questo è stato realizzato attraverso i seguenti accorgimenti:
• Unica immagine per pagina: nella pagina “struttura” viene mostrata sempre e comunque una sola immagine per volta, e nel caso di multi-foglio è presente una dropdown list per selezionare i diversi fogli;
• Immagini di dimensioni non superiori a 2 MB: il formato prescelto per le immagini è il .png (Portable Network Graphics), un formato che a differenza del .jpg adotta una compressione senza perdite, quindi mantiene la qualità delle tavole mantenendo dimensioni contenute.
Purtroppo per ragioni di risoluzione di pronfodità di colore non è possibile ridurre ulte-riormente la dimensione massima consentita per le immagini, altrimenti ne sarebbe pena-lizzata la qualità, che è invece richiesta dalla specifica per le tavole illustrate.
3.7.4 Adattabilità alle diverse risoluzioni dello schermo
EPC v1 ed EPC v2 sono stati impaginati con l’ormai superato stile delle tabelle, grazie alle quali è stato possibile progettare un “layout liquido”, che si adatta cioè alla risolu-zione del monitor dell’utente.
La risoluzione dello schermo minima pienamente supportata è 800 x 600 pixel, al di sotto della quale i menù risultano compressi ed i contenuti tagliati. Tutte le risoluzioni superiori sono pienamente supportate e soprattutto, grazie al modello liquido, viene sempre
utiliz-3.7.5 Navigabilità ed accessibilità
La navigabilità di un’applicazione Web viene valutata in base alla capacità per l’utente medio di trovare quello che cerca nel posto in cui lo avrebbe posizionato lui stesso. Questo concetto in EPC si realizza attraverso i seguenti punti:
• All’utente è chiaro se ha effettuato o no il login, poiché nel caso non lo abbia effet-tuato resta nella pagina di accesso ed ha un messaggio di errore come feedback; • Tutte le pagine a cui l’utente ha diritto di accesso sono raggiungibili attraverso un
col-legamento ipertestuale (tutto a distanza di un click). • La homepage è raggiungibile da tutte le pagine;
• L’utente loggato visualizza il proprio livello di accesso in basso a sinistra; • Il login viene richiesto una sola volta per tutta la durata della sessione;
• L’utente viene tenuto informato sulla sua posizione all’interno delle pagine di EPC attraverso il titolo della pagina stessa, visualizzato in alto in ogni pagina;
• L’utente loggato in ogni pagina ha a disposizione un link per uscire dall’area riservata verso la pagina di accesso (questo comporta il termine della sessione corrente);
• L’utente deve poter visualizzare il menù principale sempre nella stessa posizione nella pagina e con la stessa disposizione dei pulsanti.
L’accessibilità di un’applicazione Web facilita l'accesso ad individui con ogni tipo di sof-tware, hardware e disabilità.
Del software e dell’hardware si è già discusso, mentre riguardo all’accessibilità di EPC ad utenti diversamente abili sono stati adottati i seguenti accorgimenti:
• uso di un codice semanticamente corretto, logico e validato secondo i parametri del W3C;
• disposizione di un testo alternativo per ogni tipo di contenuto multimediale; • scelta di titoli e link che siano sensati anche al di fuori del loro contesto; • disposizione coerente e lineare dei contenuti e dell'interfaccia grafica.
Purtroppo il layout come tabelle delle pagine di EPC v1 ed EPC v2 è un elemento di inac-cessibilità in quanto uno screen reader non le reindirizza bene poiche legge le pagine come tabelle di contenuti, mentre sono tabelle di grafica e contenuti combinati insieme.
3.7.6 Carico cognitivo per l’utente
Uno degli elementi fondamentali per realizzare applicazioni usabili è quello di evitare il sovraccarico di informazioni per l'utente finale. Le informazioni devono essere esposte in modo semplice ed ordinato, senza accumulare troppi dati in una stessa pagina.
In EPC v1 ed EPC v2 la struttura delle pagine è sempre la stessa, in modo che la naviga-zione sia intuitiva e l'aspetto della finestra sia da subito familiare. Ad esempio il titolo della pagina si trova sempre nella stessa posizione in alto e gli strumenti di navigazione, come ad esempio il menu, si trovano sempre localizzati in alto,immediatamente sotto al titolo.
La scelta di aver predisposto una pagina per ogni gruppo di funzioni, a cui si accede tra-mite i pulsanti del menu (come ad esempio "Struttura", "Ricerca", "Stampa", "Importa"), risulta di facile apprendimento e di comodo utilizzo, soprattutto per gli utenti che hanno un minimo background sui Cataloghi Illustrati.
Lo spazio nella pagina è completamente utilizzato ed ottimizzato in modo che non siano necessarie le barre di scrolling, e che quindi l'utente abbia tutto quello che serve davanti agli occhi. Solo in casi particolari, come ad esempio nei casi in cui la lista parti o la lista dei risultati di una ricerca si allungano, compare una barra di scrolling verticale interna all'elemento, la quale permette di scorrere l'intera lista senza che gli altri elementi della pagina ne siano coinvolti.
Inoltre sono presenti una serie di ulteriori accorgimenti:
• Suggerimenti al passaggio del mouse (tooltip) sui campi da riempire e sui pulsanti di comando, i quali guidano l’utente nello svolgimento delle proprie operazioni; • Feedback sugli errori: quando viene inviato un comando che causa il fallimento
dell’operazione si ha un messaggio di errore opportunamente dettagliato;
• Mantenimento della sessione: l’utente accreditato è mantenuto loggato finchè non esegue specificamente il logout (o chiude la pagina), ma soprattutto l’ultima pagina di struttura visualizzata ed i risultati dell’ultima ricerca eseguita sono mantenuti in memoria anche quando l’utente cambia pagina.
3.7.7 Sicurezza del sistema
Un’applicazione Web deve garantire sicurezza verso eventuali attacchi esterni provenienti da malintenzionati e nel nostro caso in modo specifico è assolutamente importante la tematica della sicurezza poiché si tratta di un’applicazione Web che archivia e gestisce documentazione
proget-A questo proposito EPC è accessibile solo ad utenti accreditati. Il processo di registra-zione è svolto dagli Amministratori del sistema, i quali inseriscono gli utenti attraverso una tupla di informazioni:
• Nome utente; • Password; • Livello; • Lingua.
Le password degli utenti sono memorizzate applicando un algoritmo di hashing (non reversibile), ed in particolare si usa l’algoritmo MD5 che memorizza le password con 32 bit criptati.
Altra possibile fonte di attacchi volontari o involontari è rappresentata dal fenomeno della
SQL Injection. Questo avviene quando il contenuto degli input dei form oppure i valori
di una lista parti vengono utilizzati direttamente in una query sul database se tra i caratteri passati sono contenuti i caratteri speciali quali:
• apice (‘);
• doppio apice (“); • meno meno (--); • backslash (\).
Nel caso di attacco volontario un malintenzionato potrebbe abortire l’esecuzione della query in programma ed eseguirne una propria, ad esempio potrebbe inserire la stringa: “;drop database;-- che ha come effetto quello di chiudere la query precedente, cancellare il database e commentare tutto quello che segue.
Il caso di attacco involontario è accaduto casualmente mentre si testava il caricamento dati da una lista parti Excel. L'effetto riscontrato era che alcuni record non venivano cor-rettamente salvati nel DB, in seguito è stato compreso che il campo “description” di tali record conteneva apici nel testo e provocava il termine della query di inserimento, che quindi falliva.
zione di caratteri di escape) prima della loro iniezione nelle richieste. Questo è stato rea-lizzato attivando la direttiva
magic_quotes_gpc = On
sul file di configurazione php.ini. La direttiva attiva i caratteri di escape alle richieste di tipo get, post ed ai cookie di PHP.
Esiste anche una seconda forma di SQL Injection, ovvero quella interna che avviene a causa di stringhe “pericolose” che si trovano già memorizzate nel DB. In questo caso il rischi è quello di andare ad “attivare” tali valori con possibili conseguenze disastrose. Rischi come questi si disinnescano adottando le seguenti precauzioni:
• uso di tabelle con chiave numerica (“id”) e nelle query di selezione applicare il pro-dotto cartesiano o la join solo su tali chiavi numeriche (e non su campi stringa); • escludere di query di selezione su risultati memorizzati in variabili PHP ed ottenuti
attraverso precedenti query di selezione;
Infine un ultimo rischio è quello di lasciare la direttiva error_reporting(ALL), comune-mente utilizzata in fase di sviluppo software, anche quando l'applicazione Web va online per gli utenti finali.
Utenti malintenzionati possono in questo caso andare ad utilizzare i form per interrogare il sistema ed esplorare le reazione a particolari valori inseriti. In questo modo è possibile, attraverso una sapiente lettura degli errori che il sistema ritorna, capire dettagli sull'archi-tettura del sistema che possono essere utilizzati a fini dannosi.
Per evitare questa insidia è previsto di mascherare tutte le notifiche di errore non appena l'applicazione viene messa in produzione, attraverso la direttiva:
error_reporting(0)
3.8 Creazione del layout grafico
EPC v1 ed EPC v2 non differiscono a livello grafico ed utilizzano entrambi le tabelle, le quali, grazie alle loro molteplici e multiformi caratteristiche, si sono rivelate uno stru-mento efficace non solo per impaginare i dati ma soprattutto per visualizzare i layout gra-fici. Grazie alle tabelle è infatti possibile costruire delle griglie in cui inserire i vari contenuti di un sito e, per mezzo degli sfondi, del padding e dei margini, è stato possibile
Pur costituendo una pietra miliare del Web, l’impaginazione a tabelle è ormai diventata obsoleta in quanto:
• la visualizzazione dei dati si confonde con i dati stessi, per cui è difficile da gestire; • rappresenta elemento di non accessibilità.
In attesa del CSS3 e della progressiva scomparsa dei Browsers più vecchi, ad oggi siamo in un periodo di transizione in cui un oculato utilizzo dei tag “<div>” unitamente ai fogli di stile CSS2 con particolare riferimento agli attributi “float”, “width” e “clear”, e ancora degli attributi “position: relative”, “position: absolute” e “z-index” permette di ottenere un layout altrettanto funzionale e preciso, senza dover ricorrere alle tabelle. Questo è il caso di EPC v3, il quale è stato sviluppato con un layout grafico completamente nuovo. Per EPC v1 ed EPC v2 è stato innanzi tutto elaborato un mock-up come quello mostrato in Figura 3-9.
Figura 3-9. EPC v1 ed EPC v2 - Mock up
TITOLO
MENU
LOGO
riga bianca di separazione
INSTESTAZIONE SUPERIORE SINISTRA INSTESTAZIONE CENTRALE
CORPO CENTRALE CORPO SUPERIORE SINISTRO
INSTESTAZIONE INFERIORE SINISTRA
CORPO INFERIORE SINISTRO
LIVELLO UTENTE SUPPORTO MULTILINGUA
• TITOLO: collocato in alto, si aggiorna ad ogni cambio di pagina per informare gli utenti circa la pagina corrente;
• LOGO: collocato a destra, contiene il logo AnsaldoBreda, che costituisce anche un link alla homepage;
• MENU: collocato in orizzontale sotto il titolo, contiene i bottoni per navigare attra-verso le varie pagine di EPC;
• INTESTAZIONE SUPERIORE SINISTRA: contiene il titolo della finestra sotto-stante, per cui ha contenuti diversi a seconda della pagina visualizzata:
- Struttura: contiene il titolo dell’assieme di livello superiore (nodo padre); - Dettagli: contiene il codice ed il nome della parte visualizzata;
- Ricerca: contiene il titolo della ricerca per disegno;
- Acquisto: contiene il titolo dei comandi per salvare un carrello della spesa; - Utenti: contiene il titolo dei comandi per creare un nuovo utente;
- Importa: contiene il titolo dei comandi per importare un nuovo catalogo; - Azienda: contiene il titolo dei comandi per creare un nuova azienda;
• CORPO SUPERIORE SINISTRO: ha contenuti diversi a seconda della pagina visual-izzata:
- Struttura: contiene una tabella con il codice e il nome della parte di livello supe-riore (nodo padre);
- Dettagli: contiene una tabella con elencati i dettagli della parte visualizzata e se la parte è anche un ricambio segue il form per inviare al carrello;
- Ricerca: contiene il form per effettuare la ricerca per disegno;
- Acquisto: contiene il form per creare/modificare un carrello della spesa; - Utenti: contiene il form per creare un nuovo utente;
- Importa: contiene il form per importare un nuovo catalogo; - Azienda: contiene il form per creare un nuova azienda;
• INTESTAZIONE INFERIORE SINISTRA: contiene il titolo della finestra sotto-stante, per cui ha contenuti diversi a seconda della pagina visualizzata:
- Struttura: contiene il titolo degli assiemi di livello inferiore (nodi figli); - Dettagli: non utilizzata;
- Ricerca: contiene il titolo della ricerca per parte;
- Acquisto: contiene il titolo dei comandi per caricare/cancellare un carrello della spesa;
- Utenti: contiene il titolo dei comandi per cancellare un utente; - Importa: contiene il titolo dei comandi per cancellare un catalogo;
• CORPO INFERIORE SINISTRO: ha contenuti diversi a seconda della pagina visual-izzata:
- Struttura: contiene una tabella con i riferimenti sul disegno, i codici, i nomi e le quantità delle parti di livello inferiore (nodi figli);
- Dettagli: non utilizzata;
- Ricerca: contiene il form per effettuare la ricerca per parte;
- Acquisto: contiene il form per caricare/cancellare un carrello della spesa; - Utenti: contiene il form per cancellare un utente;
- Importa: contiene il form per cancellare un catalogo; - Azienda: contiene il form per cancellare un’azienda;
• INTESTAZIONE CENTRALE: contiene il titolo della finestra sottostante, per cui ha contenuti diversi a seconda della pagina visualizzata:
- Struttura: contiene il codice, il titolo e il foglio del disegno visualizzato; - Dettagli: contiene il codice, il titolo e il foglio del disegno visualizzato; - Ricerca: contiene il titolo dei risultati della ricerca;
- Acquisto: contiene il nome del carrello della spesa attivo; - Utenti: contiene il titolo della lista utenti accreditati; - Importa: contiene il titolo dei cataloghi presenti; - Azienda: contiene il titolo della lista aziende registrate;
• CORPO CENTRALE: ha contenuti diversi a seconda della pagina visualizzata: - Struttura: visualizza il disegno corrente;
- Dettagli: visualizza il disegno corrente;
- Ricerca: contiene una tabella con i risultati dell’ultima ricerca effettuata;
- Acquisto: contiene una tabella con l’elenco degli articoli presenti nel carrello attivo;
- Utenti: contiene una tabella con l’elenco degli utenti accreditati; - Importa: contiene una tabella con l’elenco dei cataloghi presenti; - Azienda: contiene una tabella con la l’elenco delle aziende registrate; • LIVELLO UTENTE: mostra il livello numerico e testuale dell’utente loggato; • SUPPORTO MULTILINGUA: mostra le bandiere relative alle lingue disponibili. Un ulteriore passo verso la forma finale è stato quello di scegliere i colori, i cui risultati sono mostrati in Figura 3-10:
Figura 3-10. EPC v1 ed EPC v2 - Mock up (dettagliato con colori)
Per il titolo, i pulsanti del menu e tutte le intestazioni è stato scelto un colore blu scuro (#0A46C6), impreziosito da un gradiente lineare verso un blu più chiaro, con testo in bianco. Per lo sfondo del menu, del corpo superiore ed inferiore sinistro e della barra pie-dipagina è stato scelto un colore azzurro (#87CEFA) con testo in nero. Lo sfondo del corpo centrale è dato dalla ripetizione di un motivo di colore grigio chiaro che ricorda una serie di binari intrecciati, tema in linea con l’ambiente ferroviario in cui si colloca EPC. Le tabelle interne, che contengolo gli elenchi di informazioni relative alle varie pagine, hanno intestazione in verde (#00FF99), righe dispari in grigio chiaro (#EEEEEE), righe pari in grigio scuro (#CCCCCC) e piedipagina in giallo (#CCFF33).
I form sono realizzati in bianco, che risulta ben evidente nello sfondo azzurro e i pulsanti di tipo submit e reset hanno lo stesso stile dei pulsanti del menu.
Quindi in definitiva riportiamo le schermate delle varie pagine.
TITOLO
… MENU .
LOGO
riga bianca di separazione
INSTESTAZIONE SUPERIORE SINISTRA INSTESTAZIONE CENTRALE
CORPO SUPERIORE SINISTRO
INSTESTAZIONE INFERIORE SINISTRA
CORPO INFERIORE SINISTRO
LIVELLO UTENTE SUPPORTO MULTILINGUA
riga bianca di separazione
CORPO CENTRALE
PAGINA 1 PAGINA 2 PAGINA 3 PAGINA 4 PAGINA 5 PAGINA 6 PAGINA 7
INTESTAZIONE TABELLA RIGA DISPARI
RIGA PARI PIEDIPAGINA TABELLA
Figura 3-11. Pagina “Login”
Figura 3-13. Pagina “Dettagli”
Figura 3-15. Pagina “Acquisto”
Figura 3-17. Pagina “Importa”
