Translate

Saturday, September 8, 2012

User Centered Design Economico (in Italiano)


User Centered Design Economico
Progettazione centrata sull’utente
con l'impiego minimo di risorse
di Vincenzo Dentamaro 27/07/2012
Prefazione:
Lo User Centered Design (UCD) è un modo per progettare e costruire prodotti di qualsiasi genere tenendo conto del punto di vista e delle esigenze dell’utente. Lo UCD è un processo composto di più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazione e verifica. In italiano questo processo è noto anche come “Progettazione Centrata sull’Utente”.
Il processo è stato definito e descritto da diversi autori e persino da alcune norme ISO, come l’ISO 13407, Human-centered design process, l’ISO 9241-110 Dialogue Principles (mod. 2006). Diverse fonti descrivono processi leggermente diversi, ma guidati dalla stessa filosofia: fondare il progetto sui reali bisogni degli utenti.
Secondo l’ISO 13407:
La progettazione centrata sull’essere umano (human-centred design) è un approccio allo sviluppo dei sistemi interattivi specificamente orientato alla creazione di sistemi usabili.  È un’attività multi-disciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia. L’applicazione dei fattori umani e dell’ergonomia alla progettazione dei sistemi interattivi ne potenzia l’efficacia e l’efficienza, migliora le condizioni del lavoro umano e contrasta i possibili effetti avversi dell’uso sulla salute, sulla sicurezza e sulle prestazioni. Applicare l’ergonomia alla progettazione dei sistemi richiede che si tenga conto delle capacità, delle abilità, delle limitazioni e delle necessità umane. I sistemi human-centred supportano gli utenti e li motivano a imparare. I benefici possono includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell’utente.
In questa tesi presenterò un modello di User Centred Design che permetterà di sviluppare prodotti e servizi tenendo presente non solo le reali esigenze degli utenti, ma anche le esigenze di economicità in fase di sviluppo di un prodotto (o servizio) da parte delle aziende.
Conoscere l’utente
Tutto si basa sul coinvolgimento attivo dell'utente e sulla chiara comprensione dei requisiti degli utenti e dei task (quello che l’utente deve fare).
Bisogna comprendere quello che l’utente fa, come lo fa e cosa si aspetta come output.
Analizzare gli utenti basandosi sui seguenti punti:
  1. Capacità e bisogni reali
  2. Contesto
  3. Lavoro
  4. Tasks
  5. Necessità di prodotti usabili
Golden rule del progetto di interfacce: Conoscere l’utente.
Per conoscere l’utente bisogna osservarlo mentre compie il suo lavoro (non ancora automatizzato e privo della nostra soluzione), cosa si aspetta in output e capire come tutto può essere automatizzato o semplificato mediante l’uso di una soluzione (prodotto o servizio) differente.
E’ conveniente descrivere uno scenario, cioè scrivere, in maniera semi-formale, una storia di come gli utenti usano la soluzione attuale per compiere i loro task.
Approfondendo aspetti caratteristici degli utenti come il loro background cognitivo (quanto conoscono di una certa cosa), le loro abilità motorie e mentali (se hanno deficit cognitivi o motori), l’età (un prodotto per bambini deve poter essere usato diversamente da come lo userebbe un adulto), l’ambiente in cui vive, la cultura, la propria storia.
Fondamentalmente dopo questa analisi vengono fuori due grandi categorie di utenti:
Gli utenti comuni e gli utenti speciali.
Gli utenti comuni sono quegli utenti che non hanno particolari deficit motori o cognitivi e che rappresentano la maggiorparte degli utenti del nostro prodotto.
Gli utenti speciali sono quegli utenti che per necessità d’uso o per deficit cognitivi o motori hanno bisogno di una qualche progettazione speciale per adattare il prodotto ancora da sviluppare alle loro esigenze.
Se si desidera creare un prodotto usabile (cioè il grado con cui un essere umano può utilizzarlo con il massimo profitto e il minimo sforzo) anche per gli utenti speciali, è sempre conveniente pensare alla soluzione prima di iniziare lo sviluppo:
Molte aziende creano un prodotto per l’utente comune e poi applica degli adattamenti per l’utente speciale (tipo plugin), questo rende il prodotto poco usabile per l’utente speciale.
Si dovrebbe quindi prevedere la progettazione orientata all’utente speciale sin dall’inizio.
La più recente ricerca sull’usabilità dimostra che la soluzione migliore per creare un sitema usabile per l’utente speciale è quella di progettare un sistema in grado di adattarsi alle caratteristiche dell’utente man mano che l’utente lo usa.
Quindi pensare a chi è destinato l’uso del prodotto da sviluppare.
Osservare l’utente mentre svolge il task
Continuare la descrizione dello scenario inserendo una descrizione abbastanza approfondita di quello che l’utente fa per arrivare al suo scopo, come lo fa, usando quali strumenti e se è soddisfatto o meno.
Questa analisi ci permetterà di capire il dominio applicativo del prodotto da sviluppare e addirittura di collocare il prodotto da sviluppare in uno preciso contesto lavorativo.
L’analisi deve produrre come output una lista strutturata di task che l’utente compie per raggiungere lo scopo. Poi il progettista annota ciascun task come necessario, non importante, importante, auspicabile ed ecc.
Ecco un esempio riguardo l’analisi dei task per un progetto sul financial forecasting:
F.S. è un responsabile del gruppo Emea di IBM Italia e desidera conoscere quando vendere le azioni di IBM in suo possesso da 10 anni.
Francesco, come qualsiasi altro dipendente di IBM, riceve annualmente come premio delle Stock Options, ovvero dei pacchetti di azioni dell’azienda presso cui presta servizio. Vuole sapere qual’è il momento migliore per vendere le proprie azioni e ricavare denaro fisico da investire per comprare una casa ad Ostia ai figli. Francesco conosce molto bene l’uso delle tecnologie informatiche ed è un curioso sperimentatore di nuovi strumenti software. Utilizza giornalmente Yahoo Finance! per vedere qual’è il valore corrente delle azioni di IBM Inc. ed inoltre usa altri siti di brokerage online (come www.interactivebrokers.com) per trovare dei compratori per le proprie azioni e realizzare la cifra di cui necessita per acquistare la casa al mare ai figli.
Nello specifico Francesco legge sulla sua pagina personale di IBM il numero di azioni da lui detenute e il valore corrente del titolo “IBM” e quindi il valore totale delle sue azioni.
Poi si reca su Yahoo! Finance, cerca e seleziona il titolo “IBM” e visualizza l’andamento storico del titolo “IBM” inerente ai mesi passati. L’andamento è presentato in maniera grafica mediante un diagramma. Una volta osservato il diagramma, se il grafico è in crescita o è stabile Francesco si reca su alcuni siti di brokerage online per vendere le proprie azioni.  
Vorrebbe conoscere l’andamento futuro del valore del titolo di IBM ma proprio non ha alcuna idea di come predire il futuro.
Nei siti di brokerage usa spesso lo strumento in modalità demo per simulare l’acquisto e la vendita di azioni. E’ diffidente nell’uso di strumenti di vendita di azioni online, perché consapevole dei rischi di frode che potrebbero esserci. Però non vuole neanche affidarsi a dei costosi e a volte poco onesti, brokers fisici (persone) che svolgono quel lavoro come professione. Per questo motivo rimanda sempre la vendita delle sue azioni sperando di non arrivare mai a raggiungere valori minimi di quotazione oppure raggiungere la scadenza delle stock options in suo possesso. Conoscere l’andamento futuro delle proprie azioni gli permetterebbe di capire qunado vendere le sue azioni e quanto guadagnerà o perderà continuando a tenersele senza venderle.
Francesco è un utente diretto del sistema, primario, perché quotidianamente valuterà l’andamento presente e futuro dei titoli ed è un utente esperto di tecnologie informatiche ma non esperto di finanza.
Francesco, rappresenta la categoria di utenti che usa frequentemente sistemi online per monitorare l’andamento delle azioni, però, a differenza della categoria precedente, lo fa per cogliere il momento giusto per venderle e guadagnare di più.
Sotto task individuati:
  1. Lettura del valore corrente del titolo
  1. Importante e Frequente
  2. Da includere assolutamente
  1. Lettura del valore totale delle stock options di cui si è in possesso
  1. Importante per Francesco
  2. Non frequente
  1. Recarsi su Yahoo! Finance
  1. Relativamente frequente
  2. Importante
  3. Non importante in un software che ha le stesse funzionalità di Yahoo! Finance.
  1. Ricerca dell’azienda
  1. Importante e Frequente
  2. Da includere assolutamente
  1. Selezione dell’azienda
  1. Da includere assolutamente
  2. Frequente e importante
  1. Selezione dell’intervallo (la data di inizio e la data di fine) in cui prelevare i valori giornalmente
  1. Molto importante e Frequente
  2. In futuro renderlo opzionale potrebbe diminuire la complessità del sistema
  1. Visualizzazione di un grafico dell’andamento dei valori storici
  1. Frequente ed importante
  2. Da includere assolutamente
  1. Vendita di azioni mediante strumenti online
  1. Frequente
  2. Possibile implementazione futura
  1. Simulazione di vendita online
  1. Non frequente
  2. Non importante
  1. Rinuncia alla vendita/acquisto
  1. Frequente
  2. Importante
  3. Possibile implementazione futura
Come potete notare non si accenna minimamente alla soluzione da progettare, queste analisi dei task hanno il solo scopo di individuare gli utenti, cosa fanno e come lo fanno.
Sta al progettista poi capire cosa includere e cosa non includere.
Analizzare più utenti significa avere un quadro completo di ciò che gli utenti desiderano dal prodotto.
Analisi dei requisiti
Un requisito (dal latino requisitus, richiesto) è una proprietà richiesta, oppure auspicabile, del prodotto.
Il documento dei requisiti ha allora lo scopo di raccogliere in forma organica una descrizione di tutte le proprietà desiderate. Dalla sua formulazione dovrebbe essere chiaro se un requisito esprime una proprietà obbligatoria, oppure soltanto suggerita o auspicabile.

I principali metodi di raccolta dei requisiti del progetto sono:
  1. Questionari: Rispondere a domande specifiche. Si possono raggiungere molte persone con poco  sforzo. Vanno progettati con grande accuratezza, in caso contrario le risposte potrebbero risultare poco informative. Il tasso di risposta può essere basso;
  2. Interviste individuali: Esplorare determinati aspetti del problema e determinati punti di vista. L’intervistatore può controllare il corso dell’intervista, orientandola verso quei temi sui quali l’intervistato è in grado di fornire i contributi più utili. Richiedono molto tempo. Gli intervistati potrebbero evitare di esprimersi con franchezza su alcuni aspetti delicati.
  3. Focus group: Mettere a fuoco un determinato argomento, sul quale possono esserci diversi punti di vista. Fanno emergere le aree di consenso e di conflitto. Possono far emergere soluzioni condivise dal gruppo.La loro conduzione richiede esperienza. Possono emergere figure dominanti che monopolizzano la discussione.
  4. Osservazioni sul campo: Comprendere il contesto delle attività dell’utente. Permettono di ottenere una consapevolezza sull’uso reale del prodotto che le altre tecniche non danno. Possono essere difficili da effettuare e richiedere molto tempo e risorse.
  5. Suggerimenti spontanei degli utenti: Individuare specifiche necessità di miglioramento di un prodotto. Hanno bassi costi di raccolta. Possono essere molto specifici. Hanno normalmente carattere episodico.
  6. Analisi della concorrenza e delle best practices: Individuare le soluzioni migliori adottate nel settore di interesse: evitare di “reinventare la ruota” e ottenere vantaggio competitivo L’analisi di solito è costosa(tempo e risorse)
Valutare quali sono i più economici per il prodotto che si intende sviluppare ed applicarli.
E' consigliato creare una tabella dei requisiti dove viene specificato, per ogni requisito, anche la proprietà se obbligatoria, suggerita o auspicabile.
Creazione dei prototipi: pensare all’interfaccia!
La fase di progettazione dei prototipi è molto importante per una buona progettazione user centered. E’ fortemente sconsigliato pensare alle funzionalità che il prodotto dovrà fornire in questa fase della progettazione. E’ invece consigliato pensare a come l’utente deve interagire con il prodotto.
A questo punto si consiglia di seguire le norme dello standard ISO 9241 per la progettazione di interfacce usabili.
Innanzitutto bisogna tenere presenti le difficoltà che l’utente può affrontare nell’uso del prodotto.
Una rappresentazione semplicistica di come funziona la mente umana è stata resa disponibile da Norman nel 1986:
                             
Il golfo della esecuzione è la differenza tra le intenzioni e le possibili azioni che si possono effettuare sul sistema.
Il golfo della valutazione è la quantità di sforzo necessaria ad interpretare lo stato fisico del sistema e determinare fino a che punti corrisponde alle aspettative.
Il nostro scopo è minimizzare i due golfi.
Secondo l’ISO 9241 l’usabilità di un prodotto è definita come il grado con cui può essere usato da specifici utenti per raggiungere specificati obiettivi con efficacia, efficienza e soddisfazione.
E’ quindi una definizione multidimensionale.
E’ necessario sviluppare un’interfaccia secondo i principi del dialogo dell’ISO 9241-110
  1. Adeguatezza al compito: Un dialogo è adeguato al compito nella misura in cui supporta l’utente nell’efficace ed efficiente completamento del compito: dialogo essenziale, passi adeguati al compito, informazione adeguata al compito, formati di input adeguati al compito ed ecc...
  2. Auto-Descrizione: Un dialogo è auto-descrittivo se agli utenti risulta evidente, in ogni momento, in che dialogo si trovano, a che punto si trovano all’interno del dialogo, quali azioni possono compiere e come queste possono essere eseguite.
    - Guida all’utente (inf. Operative, Inf. Su stato del sistema, feedback)
- Interazione evidente (legato all'effordance)
- Manualistica minima
- Stato visibile (attende input? Elabora? Ha finito?)
- Descrizione dell’input atteso (legato al vincolo d'uso)
- Formati descritti
  1. Conformità alle aspettative: Un dialogo è conforme alle aspettative se corrisponde alle necessità dell’utente, prevedibili in base al contesto e a convenzioni comunemente accettate.
Linguaggio familiare (molto importante: testo, icone,...)
Aderenza alle convenzioni (Dubai: lettura da destra a sinistra)
Organizzazione abituale
Dialogo consistente
Feedback conforme alle aspettative
Tempi di risposta conformi alle aspettative
Messaggi adeguati al contesto
Messaggi in posizione adeguata
Input in posizione attesa
Stile coerente dei messaggi
  1. Adeguatezza all’apprendimento: Un dialogo è adeguato all’apprendimento se supporta e guida l’utente nell’apprendimento del sistema.
Bassa soglia di apprendimento
Aiuto alla familiarizzazione
Aiuto online
Feedback intermedio
Modello concettuale evidente (quale logica?)
Spermentazione sicura (undo nei sistemi)
Riapprendimento facilitato
  1. Controllabilità: Un dialogo è controllabile se l’utente è in grado di iniziare e tenere sotto controllo la direzione e i tempi dell’interazione fino al raggiungimento dell’obiettivo.
Tempi di interazione controllati dall'utente (no time-out se non
necessari)
Proseguimento del dialogo controllato dall'utente
Punto di ripartenza controllato dall'utente
Reversibilità delle operazioni (undo)
Modalità di visualizzazione dei dati controllata dall'utente
Dispositivo di interazione scelto dall'utente
Personalizzazione dei valori di default
Disponibilità dei dati originali
  1. Tolleranza verso l’errore: Un dialogo tollera gli errori se, nonostante evidenti errori negli input, i risultati desiderati possono essere ottenuti senza o con minime azioni correttive. La tolleranza per gli errori si ottiene attraverso
a) prevenzione;
b) segnalazione e
c)- azioni correttive automatiche
Assistenza all'utente
Verifica e convalida dei dati
Prevenzione di azioni non valide
Richieste di conferma
Spiegazione dell'errore
Spiegazione aggiuntiva
Assistenza per il recupero
Minimo sforzo di correzione
Correzione differibile
Correzione automatica modificabile
  1. Adeguatezza all’individualizzazione: Un dialogo è adeguato all’individualizzazione se l’utente può modificare l’interazione e la presentazione dell’informazione per adattarle alle proprie necessità e capacità individuali.
Scelta di rappresentazioni alternative
Scelta del formato dei dati di input e output
Vocabolario personalizzabile
Scelta del livello delle spiegazioni
Personalizzazione dei tempi di risposta
Scelta del metodo di interazione
Personalizzazione del dialogo
Ripristinabilità dei valori precedenti
Ora bisogna pensare all’interfaccia tenendo presenti le precedenti norme per il corretto sviluppo di sistemi usabili.
Consiglio di sviluppare i prototipi dell’interfaccia in maniera low fidelity su carta, come degli schizzi di ogni interfaccia. Senza svilupparli nel dettaglio (cioè compresi di funzionalità), ma dare una struttura generale che consenta di simulare un minimo di interazione con il sistema.
Pianificazione e conduzione del test di usabilità con l’utente, applicazione dei test formativi        
Qui si prepara il documento per la valutazione dell’usabilità delle interfaccie implementate sui prototipi.
Pianificazione:
        1 – quali parti del sistema devono essere valutate?
        2 – come devono essere valutate?
        3 – quali prototipi saranno realizzati?
        4 – come deve essere eseguita la valutazione? Con quali risorse?
        5 – quali dovranno essere le interazioni con gli utenti?
        6 – come dovrà essere condotta l'analisi dei risultati?
Istruzioni per lo svolgimento del test
L’utente inizia il test con le interfacce dei prototipi precedentemente sviluppati. Il progettista mostra le varie interfacce progettate a seconda di come interagisce l’utente con il sistema: cioè alla pressione di un tasto, mostra l’interfaccia collegata.
Viene chiesto ad ogni utente, in modo separato, di spiegare cosa vede nell’interfaccia; chiedere secondo loro cosa faccia ogni controllo e cosa ci farebbero loro con quel controllo. Da questo tiriamo fuori un modello concettuale per ogni utente, formato sulla propria esperienza pregressa e sulla sua interpretazione dei controlli che vede. In questo modo iniziamo a capire i punti errati e/o non sviluppati del sistema. Finita questa parte, si procede col prendere in considerazione il primo utente (da solo) e lo si sottopone agli esempi di task tipici, spiegando come sarà svolto il test vero e proprio, e chiedendo di pensare a voce alta, eseguendo i vari passi che sta facendo a voce alta e ragionando a voce alta (metodo del tink aloud) l’osservatore deve annotare tutto, ricordando, se l’utente non lo fa, di parlare e dire cosa fa o cosa pensa. Finita questa fase, si prende in considerazione anche l’utente 2 e insieme all’utente 1, lo si sottopone al terzo esempio di task (esempio di task numero 3), In questo caso si utilizza il metodo dell’interazione costruttiva, cioè il secondo utente testa in prima persona il sistema, affiancato dall’utente che l’ha testato precedentemente, eseguendo il task ricevuto. Durante i test i progettisti devono prendere appunti, e compileranno anche la modulistica relativa al raccoglimento delle varie misure. I valutatori non devono intervenire se non per ricordare agli utenti che devono pensare e ragionare a voce alta e per tranquillizzarli, così da diminuire la normale tensione da esame che potrebbe non far proseguire in modo corretto il test.
Si potrebbe anche far usare l’interfaccia un utente per volta, l’importante è videoregistrare cosa dice l’utente, cosa fa e come lo fa e quali difficoltà incontra.
Le misure da rilevare sono: il success rate (ovvero la percentuale di compiti risolti senza problemi) e il tempo impiegato per svolgere ogni compito impartito.
Queste misure ci danno una buona idea sulla reale usabilità del sistema da sviluppare.
Questi test, anche chiamati test formativi, servono a dare forma al progetto: infatti i progettisti capiscono i probabili difetti di interazione, modificano l’interfaccia (on the fly) del prototipo su carta anche facendosi aiutare dagli utenti stessi e poi continuano con la valutazione.
Durante il test con l’utente modificare l’interfaccia (test formativi):
I test formativi sono utilizzati durante il ciclo iterativo di progettazione, per sottoporre i vari prototipi a prove d’uso con gli utenti, allo scopo di identificarne i difetti e migliorarne l’usabilità. Si chiamano formativi perché, appunto, contribuiscono a “dare forma” al prodotto: il loro scopo è individuare il maggior numero possibile di problemi. Essi sono particolarmente utili nelle fasi iniziali della progettazione, quando il design concept è appena abbozzato.
Completare il test con un questionario da sottoporre agli utenti. Ecco alcune possibili domande:
  1. Quale parte del sistema o quale caratteristica e/o funzionalità ritieni meno soddisfacenti? Perchè?
  2. Quale parte del sito e/o funzionalità avrebbe bisogno di miglioramenti?
  3. Cosa hai trovato confuso o frustrante con le opzioni di interfaccia utente?
  4. Aggiungeresi qualche opzione o funzionalità? Se si, quale?        
  5. Che cosa potremmo fare per migliorare il prodotto?
Il rapporto di valutazione derivante dall’analisi dei documenti e delle registrazioni ci daranno un quadro completo di come modificare l’interfaccia.
Sviluppo del prodotto o servizio
Questa è la fase in cui il prodotto deve essere sviluppato il più fedelmente possibile con i prototipi modificati.
In questa fase si può pensare alle funzionalità ma MAI MODIFICARE LE INTERFACCE PER ADATTARLE ALLE FUNZIONALITA’ DEL PRODOTTO: sono le funzionalità che devono adattarsi alle interfacce e non viceversa.
Questa è la vera differenza tra la progettazione classica e la progettazione user centered.
Valutazione euristica e test sommativi
Jakob Nielsen
Per valutazione basata su euristiche si denota un procedimento non rigoroso che consente di prevedere o rendere plausibile un determinato risultato, che in un secondo tempo dovrà essere controllato e convalidato con metodi rigorosi. Nell’ingegneria dell’usabilità, si chiamano euristiche quelle valutazioni di usabilità effettuate da esperti, analizzando sistematicamente il comportamento di un sistema e verificandone la conformità a specifiche “regole d’oro” (chiamate, appunto, euristiche), derivanti da principi o linee guida generalmente accettati. In pratica, per eseguire una valutazione euristica, l’esperto di usabilità dovrebbe considerare una regola euristica alla volta, ed esaminare dettagliatamente le funzioni del sistema, per verificarne la conformità.
La valutazione euristica ha il vantaggio di essere relativamente poco costosa. Tuttavia fornisce risultati piuttosto soggettivi. Quanto più le euristiche sono generali, tanto più il risultato della valutazione dipenderà dall’esperienza, dalla sensibilità e, a volte, dalle preferenze personali del valutatore.
Un'euristica e' quindi una linea guida o un principio generale che puo' guidare l'attivita' di design o puo' essere usata per analizzare una scelta gia' fatta. La valutazione euristica, sviluppata da Nielsen e Molich, si avvale di un insieme di semplici e generali euristiche per valutare un sistema. L'idea generale e' che piu' valutatori analizzano indipendentemente il sistema, piu' problemi di usabilita' vengono individuati. Nielsen afferma che un numero ragionevole di valutatori e' tra 3 e 5 con un risultato finale del 75 % degli errori di usabilita' riconosciuti.
Nielsen raccomanda le seguenti 10 caratteristiche (Le 10 Euristiche di Nielsen oppure Il Decalogo di Nielsen):
  1. Visibilità dello stato del sistema Il sistema dovrebbe sempre informare gli utenti su ciò che sta accadendo, mediante feedback appropriati in un tempo ragionevole.
  2. Corrispondenza fra il mondo reale e il sistema. Il sistema dovrebbe parlare il linguaggio dell’utente, con parole, frasi e concetti familiari all’utente, piuttosto che termini orientati al sistema. Seguire le convenzioni del mondo reale, facendo apparire le informazioni secondo un ordine logico e naturale.
  3. Libertà e controllo da parte degli utenti Gli utenti spesso selezionano delle funzioni del sistema per errore e hanno bisogno di una “uscita di emergenza” segnalat con chiarezza per uscire da uno stato non desiderato senza dover passare attraverso un lungo dialogo. Fornire all’utente le funzioni di undo e redo
  4. Consistenza e standard Gli utenti non dovrebbero aver bisogno di chiedersi se parole, situazioni o azioni differenti hanno lo stesso significato. Seguire l convenzioni della piattaforma di calcolo utilizzata.
  5. Prevenzione degli errori Ancora meglio di buoni messaggi di errore è un’attenta progettazione che eviti innanzitutto l’insorgere del problema. Eliminare le situazioni che possono provocare errori da parte dell’utente, e chiedergli conferma prima di eseguire le azioni richieste.
  6. Riconoscere piuttosto che ricordare Minimizzare il ricorso alla memoria dell’utente, rendendo visibili gli oggetti, le azioni e le opzioni. L’utente non dovrebbe aver bisogno di ricordare delle informazioni, nel passare da una fase del dialogo a un’altra. Le istruzioni per l’uso del sistema dovrebbero essere visibili o facilmente recuperabili quando servono.
  7. Flessibilità ed efficienza d’uso Acceleratori – invisibili all’utente novizio – posson spesso rendere veloce l’interazione dell’utente esperto, in modo che il sistema possa soddisfare sia l’utente esperto sia quello inesperto. Permettere all’utente di personalizzare le azioni frequenti.
  8. Design minimalista ed estetico I dialoghi non dovrebbero contenere informazioni irrilevanti o necessarie solo di rado. Ogni informazione aggiuntiva in un dialogo compete con le unità di informazione rilevanti e diminuisce la loro visibilità relativa.
  9. Aiutare gli utenti a riconoscere gli errori, diagnosticarli e correggerli. I messaggi di errore dovrebbero essere espressi in linguaggio semplice (senza codici), indicare il problema con precisione e suggerire una soluzione in modo costruttivo.
  10. Guida e documentazione Anche se è preferibile che il sistema sia utilizzabile senza documentazione, può essere necessario fornire aiuto e documentazione. Ogni tale informazione dovrebbe essere facilmente raggiungibile, focalizzata sul compito dell’utente, e dovrebbe elencare i passi concreti da fare, senza essere troppo ampia.
Uso dei test sommativi:
I test sommativi indicano una valutazione più complessiva del prodotto, al di fuori – o al termine – del processo di progettazione e sviluppo. Sono test più completi di quelli formativi, che non hanno lo scopo di fornire indicazioni ai progettisti, ma di valutare in modo sistematico pregi e difetti del prodotto, o sue particolari caratteristiche. Sono di solito condotti quando il sistema è completamente funzionante, per esempio per indicarne i punti deboli e valutare l’opportunità di un redesign migliorativo. Oppure per confrontarne le caratteristiche con quelle di sistemi concorrenti.
Per effettuare un test sommativo, si analizza il sistema dal punto di vista della conformità agli standard ISO 9241 o ISO 13407 e si analizza il sistema analizzando la conformità alle euristiche precedentemente descritte.
I livelli di maturità di un prodotto sono:
  1. 1° livello: il prodotto funziona (fattibilità), risolve problemi di natura tecnologica; si ha un sistema rudimentale con funzioni base.
  2. 2° livello: il prodotto fornisce le funzionalità necessarie(fattibilità, prestazioni, flessibilità e alcune indagini di usabilità); livello del task-centered design, completezza e qualità delle funzioni.
  3. 3° livello: il prodotto è facile da usare (livello dell’user centered design)
  4. 4° livello: il prodotto è invisibile durante l’uso (funziona, è usabile e si integra perfettamente nelle attività dell’utente).

Conclusioni
L’user centred design è una tecnica che ha permesso di sviluppare sistemi usabili di grande successo come le interfacce utente degli iPhone, iPad (interessante visitare il sito http://www.andreapicchi.it/) oppure come quasi tutti i servizi Google infatti la stessa Google in un’intervista (questa) dice: “Key point stressed several times: User-centered design ; User-centered design means building products that people really want and start with users needs and desires for designing products and services.”
Google Search è infatti un’ottimo esempio di UCD invece Yahoo! Search lo è meno:
Anche prodotti Microsoft come Windows Phone sono il risultato di un notevole studio sull’user centered design.
questo indirizzo c’è una guida (per i Manager) dal titolo “Selling the value of user centered design” che dimostra sia mediante percentuali (si parla di ROI return on investment) che di qualità del prodotto , il perché dell’importanza dell’uso dei processi di UCD durante le fasi di progettazione.
Buon UCD!
Domande frequenti
In che senso la progettazione human-centred è diversa dalla progettazione intesa in senso tradizionale (progettazione centrata sul sistema)?
La progettazione centrata sull’essere umano (human-centred design) è un approccio allo sviluppo dei sistemi interattivi specificamente orientato alla creazione di sistemi usabili.  È un’attività multi-disciplinare che incorpora la conoscenza e le tecniche dei fattori umani e dell’ergonomia. L’applicazione dei fattori umani e dell’ergonomia alla progettazione dei sistemi interattivi ne potenzia l’efficacia e l’efficienza, migliora le condizioni del lavoro umano e contrasta i possibili effetti avversi dell’uso sulla salute, sulla sicurezza e sulle prestazioni. Applicare l’ergonomia alla progettazione dei sistemi richiede che si tenga conto delle capacità, delle abilità, delle limitazioni e delle necessità umane. I sistemi human-centred supportano gli utenti e li motivano a imparare. I benefici possono includere una maggiore produttività, una migliore qualità del lavoro, riduzione dei costi di supporto e di addestramento e una migliore soddisfazione dell’utente. Mentre la progettazione centrata sul sistema l’oggetto principale dell’attenzione è il sistema da progettare. Il processo di progettazione parte dalla definizione dei suoi requisiti funzionali, cioè dall’identificazione delle funzionalità (o delle funzioni) che esso deve fornire al suo utente, che vengono descritte in dettaglio in un documento di specifiche funzionali, a partire dal quale il sistema viene progettato e quindi realizzato. In questo approccio, l’utente del sistema ha un ruolo, tutto sommato, abbastanza marginale: il progettista concentra la sua attenzione sulle funzionalità, e sugli aspetti tecnici connessi alla loro realizzazione, per arrivare a soddisfare le specifiche con un rapporto costo/qualità accettabile.
Che cosa si intende per design pattern?
Si intende una soluzione generale a un problema di progettazione che si ripropone in molte situazioni, anche diverse fra loro. Non una soluzione “finita”, ma piuttosto un modello, un template da adattare allo specifico contesto.
Quali sono i principali standard prodotti dal Technical Committee 159/SC 4 dell’ISO?
I principali standard prodotti dal Technical Committee 159/SC4 dell’ISO sono:
-              ISO 13407 (Human-centred design processes for interactive systems);
-              ISO 9241 (Human-computer interaction), suddiviso in otto serie tematiche:
  1. Serie 100: software ergonomics;
  2. Serie 200: Human system interaction processes;
  3. Serie 300: Displays and display related hardware;
  4. Serie 400: Physical input devices - ergonomics principles;
  5. Serie 500: Workplace ergonomics;
  6. Serie 600: Environment ergonomics;
  7. Serie 700: Application domains - Control rooms;
  8. Serie 900: Tactile and haptic interactions.
-              ISO 14915 (Software ergonomics for multimedia user-interfaces), composto da tre documenti:
  1. Part 1: Design principles and framework;
  2. Part 2: Multimedia navigation and control;
  3. Part 3: Media selection and combination.
Oltre agli International Standard, l’ISO può  produrre altri tipi di documenti, con un livello di consenso inferiore: ISO Technical Specification (ISO/TS), ISO Public Available Specification (ISO/PAS) e ISO Technical Report (ISO/TR).  In particolare, il TC/159 SC 4 ha prodotto questi documenti aggiuntivi:
-              ISO/TR 16982: Ergonomics of human-systems interaction – Usability methods supporting human-centred design;
-              ISO/PAS 18152: Ergonomics of human-systems interaction – Specification for the process assessment of human-system issues;
-              ISO/TR 18529: Human-centred lifecycle process descriptions.
Vincenzo Dentamaro
Software Engineer

Wednesday, November 9, 2011

MeCloud progetto Cloud computing


MeCloud
Brings me to the cloud!


Introduzione
MeCloud è un'architettura Cloud SaaS (Software as a Service) che permette agli utenti di effettuare l'upload di documenti testuali nei formati txt, rtf e htm, permette di leggere ed editarli direttamente “online” ed inoltre permette di effettuare l'upload di immagini, di visualizzare le immagini caricate e di condividere con altri utenti di MeCloud le immagini e i documenti caricati.
Il servizio è totalmente gratuito e prevede altre features come la cerazione e la gestione di nuove applicazioni e l'inserimento di inserzioni pubblicitarie e script per il SEO (Search Engine Optimization) però queste funzioni (seppur previste nel Web Service) non sono state realizzate nel sito di testing come caso di studio per l'esame di Web.

Architettura per l'implementazione reale (business):
                                                                  
Questa soluzione prevede un server contenente apache e il sito in php, N server (virtuali) in cloud sparsi per il mondo ospitanti ognuno un Web Service MeCloud e X server SQL in replica tra loro (tutti contengono gli stessi dati) con X << N .
Il database di MeCloud prevede una soluzione che permette di gestire utenti diversi su diversi Web Service e addirittura documenti (file degli utenti) diversi su Web Services diversi.
Cioè se l'utente n1 effettua l'upload del file “xyz” tale file sarà caricato su un WebService scelto mediante una politica di random o performance. Così più file di ogni utente vengono caricati su diversi WebServices sparsi per il globo terrestre (the cloud).
Inoltre se altri utenti sono abilitati ad accedere a tali file, perché esplicitamente condivisi, questi potranno accederci senza problemi usando tutti i diversi Web Services necessari, tutto questo a totale insaputa dell'utente finale.  In questo modo si realizza la relazione molti a molti (un grafo) tipica di un social network.... però di files e applicazioni online!
Questa architettura viene chiamata “Cloud Balancing” e solo poche aziende al mondo la possiedono (Google App Engine, Amazon EC2).

MeCloud Web Service
Il Web Service di MeCloud si divide in 2 sotto servizi:

  • Web Service SOAP per l'autenticazione e l'interscambio di informazioni da e verso il sito o un'applicazione esterna.
  • Web Service HTTP Request per la creazione di path virtuali verso i file e lo streaming del contenuto dei file attraverso HTTP.

Per evitare di dare l'accesso diretto (la full path) del file presente sul server al client, il Web Service, mediante il secondo sotto servizio, ad ogni richiesta crea una path virtuale verso il file e lo trasferisce al client mediante http. Tale path virtuale è data dal passaggio di parametri queli l'ID del file richiesto e il TokenID (cifrato con RSA a 1024 bit e codificato in base64) della sessione.
Per maggiori informazioni riguardo il sistema di cifratura usato fare riferimento alla sezione Sicurezza in MeCloud del presente documento.
La path virtuale verso un documento (o immagine) quindi sarà così modellata:
http://mecloud.us:8081/file?id=”idDelFile”&tk=”idCifratoEcodificatoDellaSessione”
Il parametro tk è il TokenID della sessione: ogni utente dopo aver effettuato il login ha un tokenid, tale stringa di 32 caratteri rappresenta l'utente all'interno del sistema. La stringa viene rigenerata a random ad ogni login ed è diversa per ogni utente.
Ho implementato un algoritmo di “collision prevent” per la generazione automatica di stringhe a 32 caratteri (vedere  funzione RandomString di MeCloudService.asmx.cs).


Il web service soap MeCloudService utilizza il protocollo di comunicazione SOAP (Simple Object Access Protocol) versione 1.1 e 1.2 che si attiene alle specifiche REST dove:
Lo stato dell'applicazione e le funzionalità sono divisi in Risorse WEB
§  Ogni risorsa è unica e indirizzabile usando sintassi universale per uso nei link ipertestuali
§  Tutte le risorse sono condivise come interfaccia uniforme per il trasferimento di stato tra client e risorse, questo consiste in:
§  un insieme vincolato di operazioni ben definite
§  un insieme vincolato di contenuti, opzionalmente supportato da codice on demand
§  un protocollo che è:
§  Client-Server
§  Stateless
§  Cachable
§  A livelli

Il Web Service nonostante sia implementato in C# .NET gira su Linux Ubuntu 11.04 grazie al framework open source Mono che ne garantisce anche la portabilità su piattaforme Windows e Unix Like a 32 o 64 bit senza bisogno di ricompilare il tutto per la specifica architettura.
Lista dei metodi implementati in MeCloudService Web Service:








Operation / Method Name
SOAPAction*
Input Message
Output Message
Login
http://mecloud.us/Login
LostPassword
http://mecloud.us/LostPassword
ShareItem
http://mecloud.us/ShareItem
SendInvitations
http://mecloud.us/SendInvitations
DeleteItem
http://mecloud.us/DeleteItem
GetLinearizedListOfItems
http://mecloud.us/GetLinearizedListOfItems
Register
http://mecloud.us/Register
UploadFile
http://mecloud.us/UploadFile
AddApp
http://mecloud.us/AddApp
ShareApp
http://mecloud.us/ShareApp
RemoveAppAssociation
http://mecloud.us/RemoveAppAssociation
GetAppList
http://mecloud.us/GetAppList
StoreSettings
http://mecloud.us/StoreSettings
GetSettings
http://mecloud.us/GetSettings
GetUserInfo
http://mecloud.us/GetUserInfo

  • Il Metodo Login :  Il Metodo di Login accetta 3 parametri in input:



     Input Parameters

encryptedBase64Mail
string
encryptedBas64Password
string
encryptedBase64APIKey
string


     Output Parameters

LoginResult
string

Tale metodo permette di autenticarsi nel sistema MeCloud.
Il sito invia i parametri (mail, password e API Key) cifrati con la chiave pubblica del sistema e codificati in base64. Il WS dopo aver decodificato da base64 a UTF-8 la stringa e dopo aver decriptato la stessa, effettua una query sul db per vedere se la API Key è presente, se il risultato è affermativo allora la procedura continua, altrimenti il WS ritorna un errore di “bad API Key”. Dopodiché si verifica la presenza della mail nel db e in caso affermativo si estrae la password e la si confronta con la password passata in input dal sito. Le password sono “case sensitive”. Se le password coincidono, il WS ritornerà in output il TokenID (generato automaticamente in questo istante e che ha la durata dell’intera sessione per poi essere rigenerato) della sessione ma non cifrato, in caso contrario un errore di “bad password”.

  • Il Metodo LostPassword: Accetta in input un solo parametro:

Input Parameters
encryptedBase64Mail
string

Questo metodo server a rinviare la password in caso di smarrimento.
Se la Mail cifrata e codificata è presente nel database, allora verrà estratta la relativa password e quest’ultima verrà inviata mediante una mail alla mailbox relativa. Se la password non è presente, nulla verrà inviato. Il metodo non restituisce alcun parametro (void).

  • Il Metodo ShareItem: Accetta 4 parametri in ingresso:
Input Parameters
base64EncryptedAPIKey
string
base64EncryptedToken
string
base64EncryptedOtherUserMail
string
ItemID
string

        • Output Parameters
ShareItemResult
string


            Questo metodo permette di condividere un oggetto (immagine o documento) con più utenti.
            Il metodo accetta in input 3 parametri cifrati e l’ItemID non cifrato.
Il sistema dopo aver decriptato e decodificato tutti i parametri in ingresso controlla la     presenza dell’API Key, estrae l’ID dell’utente (colui che condivide il documento) dal TokenID della sessione e l’id del secondo utente, colui che subirà la condivisione dal parametro otherUserMail. Dopodiché associa nella tabella del database USERSTOITEM lo stesso item a più utenti (nel esempio solo 2), l’utente che ha subìto la condivisione dell’item riceverà una mail che lo informa dell’avvenuta condivisione.

  • Il Metodo SendInvitations: accetta un solo parametro in ingresso, cioè la mail di colui che riceverà l’invito. Esso serve per inviare inviti ad usare MeCloud a persone non ancora registrate. Non effettuerà alcun controllo.
  • Il Metodo DeleteItem: Serve a cancellare un item. Verrà cancellata sia la presenza fisica del file sul sistema di storage che tutte le referenze relative nel database.
Tale metodo accetta 3 parametri in input:
Input Parameters
base64EncryptedAPIKey
string
base64EncryptedToken
string
ItemID
string


Output Parameters

DeleteItemResult
string
Dopo aver decodificato e decriptato i dati in input (tranne ItemID il quale non è cifrato) viene controllata la presenza dell’API Key nel DB, viene estratto l’user id relativo al TokenID passato e viene verificata l’esistenza dell’associazione userid -> itemid nella tabella USERSTOITEM del database. In caso affermativo, l’eliminazione può avere atto:
viene cancellato l’item dalla tabella ITEM e dalla tabella USERSTOITEM e dopo viene cancellato il relativo file fisico dal sistema di storage.

§  Il Metodo GetLinearizedListOfItems: ha il compito di ritornare una lista linearizzata contenente gli items di ogni utente. Tale lista è una stringa dove ogni item diverso è separato dall’altro item mediante il simbolo “pipe” |. La stringa in output sarà così formattata: FileName1,MimeType1,ServerAddress1,ItemID1|FileName2,MimeType2,ServerAddress2,ItemName2|

Ho deciso di usare una lista linearizzata perché non è sempre vero che tutti i linguaggi di programmazione gestiscono array di stringhe serializzate su XML. Quindi, per compatibilità, ho deciso di linearizzare il tutto. Il quale verrà poi splittato in array di stringhe da chi invoca il WS.
Input Parameters
base64EncryptedAPIKey
string
base64EncryptedToken
string


Output Parameters

GetLinearizedListOfItemsResult
string



§  Il Metodo Register : permette di restrarsi al sistema
I parametri sono :
Input Parameters
encryptedBase64Mail
string
encryptedBas64Password
string
encryptedBase64RealName
string
encryptedBase64LastName
string


Output Parameters

RegisterResult
string
I parametri in input sono 4 però RealName e LastName sono facoltativi, infatti non vengono usati da MeCloud (sito) in PHP.
Il sistema restituisce una stringa contenente “ok” se la registrazione ha avuto successo, altrimenti riporta il tipo di errore (ad esempio “Already Registered”).

§  Il Metodo UploadFile: permette di caricare file sul cloud. I file devono avere dimensione inferiore a 25 MBytes e possono essere soltanto del tipo accettato dal web service, infatti esso controlla il MimeType del file prima della memorizzazione. I tipi supportati dal WS sono: PDF, JPG,PNG,GIF,TIFF,MP3,DOC,DOCX,TXT,RTF,PPT,XLS.


Input Parameters

encryptedBase64Token
string
encryptedBase64APIKey
string
data
base64Binary
encryptedBase64MimeType
string
encryptedBase64FileNameWithoutPath
string


Output Parameters

UploadFileResult
string
Tutti i parametri tranne l’array di bytes da trasferire sono codificati e criptati con RSA.
Una volta che i dati sono arrivati al WebService mediante SOAP, quest’ultimo controlla la dimensione dei bytes, i quali devono essere < 25Mbytes. Poi controlla la correttezza dell’API Key, recupera le informazioni riguardo l’utente mediante il TokenID, analizza il tipo mime ed è pronto per scrivere il file sullo storage.
Se ci sono alcuni problemi durante la scrittura, un’eccezione verrà sollevata e il file non verrà salvato e la procedura verrà chiusa automaticamente.
Se il file viene scritto senza problemi, verranno create dei reference all’interno delle tabelle ITEMS e USERSTOITEM, dove la tabella ITEMS conterrà tutte le informazioni riguardanti il file caricato, la tabella USERSTOITEM invece conterrà la relazione itemid -> userid.



§  Il Metodo GetUserInfo: è importante per l’integrazione API e l’interazione con altre applicazioni le quali vogliono recuperare informazioni riguardo l’utente. Per esempio Facebook o Google mettono a disposizione degli strumenti simili per “tirar fuori” informazioni riguardo l’utente. In questo caso MeCloud ritorna solo l’user id e la mail dell’utente. La password non uscirà mai dal sitema, potrà soltanto essere reinviata alla mail del associata per il recupero della stessa.




Input Parameters

encryptedBase64Token
string
encryptedBase64APIKey
string


Output Parameters

GetUserInfoResult
string

§  I Metodi AddApp, ShareApp, RemoveAppAssociation, GetAppList, StoreSettings, GetSettings sono REALMENTE implementati all’interno di Mecloud Service WS ma non sono stati implementati nel sito in php a causa della scarsità di tempo a disposizione.
Tali metodi permettono agli utenti di memorizzare delle proprie applicazioni (RIA) e linkarle all’interno del sistema MeCloud, dando l’opportunità all’utente di creare il proprio contenuto.
Sicurezza in MeCloud

In un Web Service di uso pubblico la sicurezza delle informazioni memorizzate è fondamentale.
Dalla letteratura informatica si evince che al momento gli algoritmi di cifratura più sicuri (il che significa non sicuri al 100%) sono gli algoritmi a chiave pubblica OTP (one time pad).
A causa dell'overhead causato dal continuo generare di chiavi per ogni richiesta scambiata tra il sito ed il Web Service (multi-tier architecture), non è consigliabile usare un sistema (per quanto matematicamente dimostrato come il più sicuro) one time pad. Per MeCloud ho deciso di cifrare con l'algoritmo RSA  a 1024 bit solo alcune informazioni scambiate tra il Web Service e il sito in PHP. Per mantenere la compatibilità tra i due sistemi ho usato uno strumento di generazione chiavi molto conosciuto ed ultra testato : OpenSSL.
Con OpenSSL ho generato la chiave pubblica, privata, modulo e il certificato.
Tali file risiedono sia nella directory “certificates” del sito in php che nella directory “certificates” del web service MeCloud Service.
Come precendentemente descritto  molti metodi del web service accettano in ingresso dei parametri cifrati, di solito sono l'API Key e il Token ID.
Abbiamo già parlato del TokenID, ma non dell' API Key. Ogni Web Service che si rispetti ha un APIKey (Google Map, Youtube, Facebook Web Service ed ecc...), questo ApiKey identifica l'applicazione che sta effettuando la chiamata al web service e quest'ultimo può applicare delle policy di sicurezza diverse per ogni applicazione che si interfaccia verso di esso: ad esempio l'API Key di un'applicazione per smartphone (Android ad esempio) sarà certamente diversa da quella del sito MeCloud o da un'applicazione desktop di MeCloud.
Per quanto riguarda la sicurezza, possono accedere a Mecloud Service WS solo gli API Key prememorizzati nel database, cioè solo le applicazioni autorizzate.
Questi parametri (API Key e TokenID) vengono cifrati (mediante la chiave pubblica) e codificati in base64 dal sito in php e poi inviati via SOAP al web service MeCloud Service, il quale provvederà a decodificarli e decriptarli mediante il binomio chiave pubblica e privata tipico di un sistema di cifratura asimmetrico .
Anche il Web Service HTTP (il secondo web service integrato in MeCloud) usa il sistema di decifraggio RSA per decriptare il TokenID dell'utente e creare la path virtuale verso il file, il quale viene inviato in streaming.
I dati binari trasferiti  tra l'utente e il sito e tra il sito e il web service non sono cifrati. Cifrare tutti i dati “costerebbe” significativamente sulle performance fino a rendere il servizio inutilizzabile.
D'altro canto non è possibile tirar fuori i dati dal WS manualmente poiché il TokenID della sessione è sempre trasferito cifrato.
Ecco la funzione (php) di cifratura :

function encryptAndEncodeToBase64($data){
         $server_public_key = openssl_pkey_get_public(file_get_contents("certificates/publickey.pem"));
         openssl_public_encrypt($data, $encrypted, $server_public_key);
         return base64_encode($encrypted);

}

Ecco la funzione di decriptaggio in c#:

Carico le chiavi e creo l'oggetto RSA che mi permetterà di effettuare il decriptaggio
if(myCert2 == null || rsa == null){
                                               myCert2 = new X509Certificate2(certificatesPath+"mecloudprivatekey.pfx",privatePassw,X509KeyStorageFlags.MachineKeySet);
                                                   rsa = (RSACryptoServiceProvider)myCert2.PrivateKey;
                                                               }
 e per decriptare :
                                               byte[]  decrpyted = rsa.Decrypt(Convert.FromBase64String(encryptedBas64Password), false);
                                               String  loginPwd = System.Text.Encoding.UTF8.GetString(decrpyted);
                                              
                                                               decrpyted = rsa.Decrypt(Convert.FromBase64String(encryptedBase64APIKey), false);
                                               String  ApiKey = System.Text.Encoding.UTF8.GetString(decrpyted);
                                              

Il database MySQL interno a MeCloud è protetto da password e non accetta connessioni in ingresso da host non autorizzati. In questo caso ho opportunamente modificato il file /etc/hosts facendo in modo che l'unico host autorizzato sia il loop back device, ovvero localhost (127.0.01).
MeCloud usa un sistema di passaggio di TokenID su url e mediante l’uso di cookie contenente il TokenID. Quando l’utente effettua il logout, il cookie relativo alla sessione viene cancellato (si imposta la scadenza ad un numero molto precedente) e l'utente è costretto ad effettuare nuovamente il login.


Interfacciamento tra PHP e MeCloudService Web Service
Invece di utilizzare direttamente la classe SoapClient messa a disposizione dagli sviluppatori di PHP, ho deciso di generarmi in automatico una classe wrapper chiamata MeCloudService.php che si occupa di invocare i metodi tramite SoapClient e ritornare i valori ricevuti dal web service.
Il tool usato si chiama WSDLInterpreter e genera in automatico la classe PHP mediante l'analisi del WSDL di Mecloud Web Service.
Il protocollo usato per l'interscambio di informazioni è SOAP. Soap permette di trasferire “buste” XML contenenti dati serializzati. XML è anche usato in altri protocolli come XML-RPC ed ecc...
Avrei potuto usare Json invece di XML risparmiando banda e tempo di trasferimento dei dati, ma a discapito della compatibilità.
In futuro MeCloud sarà implementato mediante chiamate asincrone (tipo Ajax) e scambi di dati tra il broswer, il lato server del sito e il Web Service.
A titolo informativo, sono in corso alcune polemiche riguardo l'uso di Ajax browser side... si pensa che l'uso abbondante di questa tecnologia nelle pagine dinamiche sia fonte di exploit (fondamentalmente Cross Site Scripting e Denial Of Service) andando contro la sicurezza degli utenti, dei loro dati e del servizio offerto. Per questo motivo si stanno implementando nuovi protocolli come WebSocket. Sto quindi pensando di implementare MeCloud con chiamate SOAP asincrone lato server per poi portare in “superficie” solo il risultato senza invocare il Web Service esterno direttamente da javascript (browser side).
Cioè login e password vengono inviate “Server side” e ciò che il Web Service ritorna viene prima elaborato dal lato server del sito e poi portato in superficie rendendolo disponibile ai controlli in javascript.

Esempio di invocazione del Web Service MeCloudService con PHP

Per l’invocazione del WS di MeCloud via PHP ho generato la classe MeCloudService.php.
L’uso è il seguente:
Innanzitutto bisogna includere tale classe nel sorgente con questa istruzione:
require_once("MeCloudService.php");

Qui di seguito ci sono le istruzioni per invocare il web service. Nell’esempio recupererò l’userid e la mail dell’utente invocando il metodo GetUserInfo del web service.

$mecloud = new MeCloudService();

$parameters = new GetUserInfo();

$parameters->encryptedBase64Token = encryptAndEncodeToBase64($TokenID);

$parameters->encryptedBase64APIKey = encryptAndEncodeToBase64("FLJQPZTXOEXWOJGLXZLMDPSEQPOQWYXO");

$response = $mecloud->GetUserInfo($parameters)->GetUserInfoResult;



//la variabile $response contiene il valore: userid,mail

//ora divido (split) la stringa in 2 paramtri userid e mail

$temp = explode(",",$response);



$userid = $temp[0];

$mail = $temp[1];





Il Database di MeCloud


Per migliorare le performance ho ridotto al minimo l'uso di join e ogni selezione è fatta basandosi unicamente dagli ID dei vari elementi. Addirittura la tabella con più elementi è la tabella USERSTO ITEM la quale ha solo due campi rappresentati dagli ID. Le performance, nonostante le basse capacità della macchina virtuale, sono abbastanza soddisfacenti.

Il progetto è scaricabile da qui: MeCloud.zip - 1.2 MB       

Il software è rilasciato gratuitamente per l'utilizzo, ma non può essere modificato ne integralmente ne in parte. Dal software in questione non possono essere copiati pezzi di codice o risorse varie.
Scaricando il software si accettano le suddette condizioni d'uso.

MyFreeCopyright.com Registered & Protected  (c) 2011 by Vincenzo Dentamaro