Tesi multipiattaforma

Transcript

Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea specialistica
Metodologie e tecnologie a supporto nello
sviluppo di applicazioni mobile di tipo
Enterprise
Anno Accademico 2012/2013
Relatore
Ch.mo prof. Marcello Cinque
correlatore
Ch.mo ing. Dennis Alessio Guidotti
candidato
Francesco Godino
matr. 885/000481
[Dedica]
Indice
Introduzione
6
Capitolo 1. titolo capitolo 1
1.1
1.2
1.2.1
1.2.2
1.2.3
1.3
1.3.1
12
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
15
23
25
32
35
36
38
Capitolo 2. titolo capitolo 2
2.1
2.1.1
2.2
2.2.1
2.2.2
2.2.3
2.3
2.3.1
Conclusioni
Sviluppi futuri
Bibliografia
42
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
titolo paragrafo
42
44
46
49
53
62
70
72
196
198
199
III
Metodologie e tecnologie a supporto nello sviluppo di applicazioni mobile di tipo enterprise
Introduzione
La continua evoluzione ed innovazione delle tecnologie connesse al web sta trasformando
profondamente il modo con cui gli utenti condividono le informazioni. I dati che vengono
scambiati vengono acceduti in misura sempre maggiore in mobilità indipendentemente dal
tempo e dal luogo; la mole di dati che viene prodotta e che viaggia nel web sta
aumentando, sia a livello di quantità che di complessità. Nuove tecnologie innovative
vengono lanciate sul mercato con cadenza sempre maggiore, andando ad ampliare i modi
con cui le informazioni vengono scambiate. Il volano delle recenti e delle future
innovazioni legate al web è rappresentato dal mobile computing, attraverso l'utilizzo in
costante aumento di smarphone e tablet. Queste 2 tipologie di dispositivi hanno creato, o
in alcuni contesti ampliato, servizi e tecniche a supporto degli utenti per la condivisione di
informazioni su scala globale. Grazie all'utilizzo di sensori sempre più complessi ma di
facile utilizzo e attraverso il paradigma orientato alle applicazioni, gli utenti riescono a
comunicare informazioni in tempo reale di diverso tipo. Ad esempio, utilizzando
un'applicazione di messaggistica istantanea, un utente può condividere su un social
network la sua posizione attraverso il sensore gps, collegandola a dati strutturati aggiuntivi
prodotti dall'applicazione, aumentando la semantica dell’informazione prodotta. L'insieme
di queste innovazioni che permettono un ruolo sempre più attivo degli utenti all'interno del
web sta portando al passaggio dal web 2.0 al 3.0. Il primo è un termine utilizzato per
indicare uno stato dell' evoluzione del World Wide Web, rispetto alla condizione
4
precedente in cui le pagine web erano statiche, cioè senza possibilità di interagire con esse
in maniera interattiva. Si indica come Web 2.0 l'insieme di tutte quelle applicazioni online
che permettono uno elevato livello di interazione tra il sito web e l'utente come i blog, i
forum, le chat, i wiki, le piattaforme di condivisione di media come Flickr, Youtube,
Vimeo, i social network come Facebook, Myspace, Twitter, Google+, Linkedin,
Foursquare, ecc. (Wikipedia). Questo livello di interazione tra utente e pagine web è
ottenuto attraverso l’utilizzo di tecnologie come AJAX, il cui acronimo è asynchronous
JAVASCRIPT and XML, HTML, CSS, e plugin creati ad hoc per aumentare il livello di
user experience delle applicazioni web, ad esempio JavaFX, Microsoft Silverlight o Adobe
Flex. Il Web 3.0 non ha una definizione univoca, perché con questo termine si tende ad
inglobare una serie di tecnologie, linguaggi, strumenti volti ad estendere il modo di
accedere e di ricercare informazioni e risorse del web. Principalmente la visione di questo
tipo di web è incentrata sulla strutturazione e semantica delle informazioni accessibili, sia
dagli utenti che dalle macchine. Attraverso una serie di linguaggi e tecnologie, come
XML, RDF, OWL, SPARQL si consente di utilizzare il web come archivio di dati
strutturati ai quali poter accedere da remoto. Avviene il passaggio da pagina web a risorsa
del web, con cui si intende qualsiasi dato strutturato accessibile, sia da utente che da
macchina. Il maggiore impatto di questa evoluzione consiste nell’ottenere un nuovo livello
di integrazione e di interoperabilità delle applicazioni, rendendo i dati disponibili
attraverso “link”, o attraverso API ( Application programming interface ) standardizzate;
inoltre attraverso questa ristrutturazione dell’accesso al web è possibile interrogare ed
accedere alle informazioni attraverso applicativi gestiti da intelligenza artificiale, al fine di
poter ottenere informazioni nascoste dalla elaborazione dei dati, attraverso algoritmi di
data mining. Queste trasformazioni del web e delle tecnologie ad esso connesse, è stato in
parte assimilato dalle realtà enterprise, ma può essere ampliato il loro utilizzo per favorire
la crescita di valore dell'azienda o aumentare l'efficienza dei processi interni. Il web e le
sue innovazioni può essere utilizzato in tutti i settori aziendali, principalmente per
relazionarsi a clienti, partner e propri dipendenti. Le tecnologie che sono in relazione
diretta con l’evoluzione del web che consentono grandi benefici se introdotte nelle attività
5
aziendali sono diverse; questa tesi è focalizzata sulle tecnologie mobile e lo sviluppo di
applicativi con un approccio multipiattaforma e multidevice. Le aziende che stanno
introducendo il mobile nel business aziendale devono relazionarsi con un contesto in
continua evoluzione, sia come tipologie di device, sia come sistemi operativi. Questa
condizione comporta un aumento dei costi di sviluppo e di manutenzione se si intendono
sviluppare applicazioni che devono essere eseguite su diversi sistemi operativi.
Nel capitolo 1 vengono presentate le tecnologie che possono apportare grossi benefici
qualora introdotte in azienda, soffermando l’attenzione sul contesto e le tecnologie mobile.
All’interno dell’insieme dei dispositivi mobile viene condotta un’analisi di mercato
incentrata sul tablet, il quale secondo le previsioni diverrà il punto di riferimento del
mercato mobile del futuro, sia in ottica consumer che business.
Nel capitolo 2 vengono analizzati i sistemi operativi mobile IOS, Android e Windows 8
(Windows RT), i 3 sistemi operativi che secondo le previsioni si divideranno il mercato
mobile in futuro.
Nel capitolo 3 vengono analizzati i diversi approcci e tecnologie per perseguire uno
sviluppo multipiattaforma e multidevice. Al fine di individuare la tecnologia da utilizzare
in base ad un contesto di utilizzo di riferimento, viene utilizzata una metodologia di scelta
multicriterio a supporto della decisione denominata Analytic Hierarchy Process.
Nel capitolo 4 viene mostrato il processo di sviluppo di un’applicazione commissionata da
Poste Italiane realizzata con la tecnologia di sviluppo ibrida. Vengono trattare le fasi di
analisi dei requisiti e di progettazione.
Nel capitolo 5 è trattata la fase di sviluppo del codice dell’applicativo per la piattaforma
Windows 8, scelta da Poste Italiane come piattaforma di riferimento da cui partire per lo
sviluppo.
Al
termine
della
realizzazione
dell’applicazione
viene
analizzato
quantitativamente il beneficio apportato dalla tecnologia ibrida per un successivo porting
su piattaforma Android.
Infine vengono presentate le conclusioni del lavoro svolto e gli sviluppi futuri, riguardanti
lo sviluppo multipiattaforma di applicazioni mobile di tipo Enterprise.
6
Capitolo 1
Web,mobile e lʼutilizzo in azienda
In questo capitolo verranno presentate le principali tecnologie connesse al web che
potenzialmente possono portare maggiori benefici se utilizzate in azienda, sia quelle già
introdotte sul mercato sia quelle che verranno lanciate a breve. Verrà focalizzata
l'attenzione sui device mobili, in particolare il tablet. Attraverso un'analisi del mercato
attuale e delle previsioni future di questo tipo di dispositivo verrà mostrato che il tablet
diventerà il dispositivo principale nel contesto del mobile computing, sia a livello
customer che business.
1.1. Le tecnologie del web: opportunità per le aziende
Il web è diventato uno dei mezzi di comunicazione preferito dalle aziende, inoltre
costituisce la prima scelta per clienti, business partners, investitori, e altri parti interessate.
Esso è diventato pervasivo nelle vite di tutte le persone, sia a livello professionale che
personale. Vengono proposte alcune interessanti caratteristiche del web odierno:
•
L’accesso ai contenuti da parte degli utenti viene realizzato in maniera contestuale,
utilizzando regole e meccanismi per ottenere informazioni sul comportamento e gusti,
selezionando dinamicamente quali dati presentare e come presentarli; esempi d’uso di
questa caratteristica sono portali come Youtube o Amazon, che in base all’interazione nel
tempo del singolo utente con il sistema riescono a fornire delle proposte che rispecchiano i
suoi gusti
7
•
Utilizzo crescente delle tecnologie mobile per accesso al web, attraverso l’utilizzo di
smartphone e tablet e delle relative applicazioni, le quali sono sviluppate con diversi
approcci. Alle tecnologie native si stanno affiancando HTML5 e ibride( html incapsulato
in un involucro nativo )
•
Esperienza utente avanzata offerta dalle applicazioni web, attraverso l’utilizzo di
HTML5, Cascading Style Sheets 3 (CSS3). L’evoluzione di questi standard permette di
non dover ricorrere a plug-in creati ad hoc per i web browser , come Flash o JavaFx, per
ottenere un’esperienza utente ricca, cioè con elementi grafici complessi ed avanzati e
l’interazione vicina a quella offerta dagli applicativi desktop
•
Sviluppo di un’ottica Cloud-centric per la fornitura di diversi tipi di servizi ICT, in
cui attraverso il web viene realizzato l’interfacciamento tra utenti e servizi, sia per la
fruizione che per la gestione
•
Sviluppo del social computing, cioè l’interazione tra utenti e condivisione di
informazioni avviene attraverso piattaforme social, creando la possibilità di generare
comunità su diversi tipi di tematiche
•
Introduzione di nuove features in tutti i web browser, che sta generando una
frammentazione del mercato, fin’ora dominato da Internet Explorer.(Dati 2012
frammentazione browser)
•
Aumento degli investimenti nel web delle aziende in termini di digital marketing
•
In molte regioni del mondo il web sta creando forti cambiamenti a governi,
economie e norme sociali; alcuni esempi sono la diffusione delle informazioni attraverso i
social network nelle guerre civili dei paesi arabi e l’utilizzo del web come uno dei
principali canali per la propaganda politica nelle elezioni presidenziali negli Stati Uniti
d’America
L’espansione e le continue innovazioni delle tecnologie connesse al web offrono alle
aziende nuove opportunità per introdurlo nelle attività connesse a tutti i livelli della
piramide di Antony (http://it.wikipedia.org/wiki/Piramide_di_Anthony). L’utilizzo del
web è inoltre orizzontale rispetto alle diverse categorie dei processi di business delle
8
aziende; può essere introdotto all’interno di processi legati al Custom Relationship
Management ( CRM ), ai processi produttivi e ai processi manageriali. Il web risulta già
essere perno delle strategie di molte aziende nei rapporti con i clienti. Le caratteristiche di
ubiquità e di incremento delle possibilità offerte grazie alle tecnologie innovative,
accrescono l’utilità del web e lo rendono lo strumento più appropriato per l’interazione
dell’azienda con i clienti, partners e dipendenti. Nonostante il web sia stato introdotto da
tempo nelle aziende per adempiere a specifici scopi, ad esempio il marketing, ci sono
diverse opportunità di utilizzo delle diverse tecnologie connesse ad esso; il loro utilizzo
può apportare un impatto considerevole in termini di miglioramento dei Key performance
indicator (KPI) di molti processi aziendali, fino a essere un attore importante nel
cambiamento strutturale dell’azienda, ad esempio attraverso l’estrazione e l’analisi dei
dati provenienti dal web un’azienda può decidere di modificare il proprio business o di
espanderlo verso nuovi mercati e nuovi prodotti. Particolarmente efficace può essere
l’utilizzo del web attraverso i dispositivi mobili, come smartphone e tablet, grazie alle
innovazioni apportate in termini di user experience e features fornite. Questi tipi di
dispositivi offrono l’accesso a una serie di servizi innovativi peculiari dei diversi sistemi
operativi mobile attraverso un’interazione con l’utente intuitiva; l’uso del paradigma
orientato alle applicazioni mobile, che consiste di avere a disposizione una serie di
applicazioni che forniscono pochi servizi verticali per rispondere a specifici requisiti,
connesso all’interazione con molti sensori specifici dei dispositivi mobili( GPS, compasso,
camera, accelerometro, altimetro), incrementa la loro importanza e utilità all’interno delle
attività aziendali. L’incremento nell’uso del paradigma orientato alle applicazioni mobile
deve portare le aziende a prendere in considerazione nelle proprie strategie di sviluppare
applicazioni da distribuire attraverso i market ufficiali delle diverse piattaforme e
attraverso altri meccanismi. L’insieme delle tecnologie connesse al web è ampio ed
eterogeneo, e grazie agli sforzi degli organismi che si occupano di standardizzarne l’uso e
l’accesso alla rete globale,( esempio W3C, world wide web consortium ), è possibile
costruire sistemi distribuiti complessi che riescono ad interoperare ed essere integrati.
Grazie alla standardizzazione e alla crescita costante dell’interesse da parte di utenti ed
9
aziende, sul mercato vengono proposte tecnologie innovative ogni giorno. Vengono
descritte alcune delle tecnologie connesse al web che possono offrire importanti benefici
se introdotte nelle aziende. Tra quelle proposte sono presenti alcune emergenti, altre
mature e altre che verranno lanciate sul mercato in futuro:
•
Social analitics: Con questo termine vengono individuate un insieme di applicazioni
che hanno lo scopo di misurare, analizzare e interpretare i dati provenienti
dall’acquisizione di informazioni relative alle interazioni delle persone con i social
networks, esempio Facebook e Google+. Queste attività si sono sviluppate come
specializzazione delle applicazioni relative al
web analitics. Quest’ultimo consiste
nell’analisi dei dati che vengono trasmessi attraverso il web finalizzata a ottenere
informazioni per migliorare l’esperienza utente dei canali online delle aziende e
ottimizzare gli investimenti in digital marketing. Le applicazioni di social analitics sono
meno mature di quelle del web analitics. I vendors di queste tecnologie forniscono la
possiblità alle aziende di analizzare e carpire il significato nascosto connesso ai dati che
transitano sui social networks. Dati di interesse possono essere informazioni personali
delle persone, gusti e comportamenti inerenti ai prodotti e al brand interessato. Il loro
volume e l’eterogeneità dei tipi di dati prodotti attraverso diversi meccanismi, ad esempio
cliccando su un “mi piace” o su un “+1”, unità alla rapida evoluzione di queste
piattaforme, rendono le analisi complesse da realizzare. Le opportunità per le aziende
nell’utilizzo di queste tecnologie consistono nella capacità di monitorare, scovare e
predire. Attraverso il monitoraggio dei dati che transitano sui social networks è possibile
ad esempio riuscire a capire la reputazione di un’azienda e dei suoi prodotti, oppure capire
le necessità delle persone per anticipare il mercato lanciando nuovi prodotti. Queste
applicazioni possono essere integrate con applicazioni di Business Intelligence o di
Marketing Automation.
•
Web Real-time Communications: questa tecnologia, il cui acronimo è WebRTC,
è in stato di draft nel processo di standardizzazione delle tecnologie web connesse ad
HTML5 realizzato dal W3C. Essa è un framework open-source che permetterà di
effettuare comunicazioni real-time attraverso i web browser. Questa tecnologia è stata
10
rilasciata nel Giugno 2011 dall’Ericsson Labs, ed è supportata da Google, Mozilla,
Firefox, Opera e Microsoft. Il gruppo di lavoro che sta continuando lo sviluppo di questa
tecnologia vuole definire un set di protocolli per facilitare le comunicazioni attraverso i
web browser. Le aziende possono utilizzare questa tecnologia, una volta matura, per
realizzare applicazioni web real-time scalabili e con poca latenza. Attraverso questa
tecnologia possono essere realizzate pagine web che vengono utilizzate come oggetti di
comunicazioni all’interno di processi di workflow, e-commerce e altri processi aziendali.
Altro utilizzo utile all’interno delle aziende legato al contesto delle videoconferenze è la
possibilità di creare nel browser una connessione video real-time con un altro device che
supporta WebRTC o un server WebRTC attraverso il procotollo RTP(acronimo e piccola
definizione ).
•
Public Web Apis: attraverso l’uso di queste semplici interfacce software si possono
esporre dati, interi processi di business e funzionalità applicative, basandosi sui principi
dell’architettura Web-oriented( WOA ). Le aziende fornendo queste Api
possono
espandere la loro offerta di servizi attraverso siti web di terze parti o applicazioni mobile,
e ottenere una connessione B2B facilitata, migliorando l’integrazione con i propri partners.
È possibile raggiungere un elevato numero di clienti grazie alla diffusione delle Api
attraverso il web, il mobile e le piattaforme social. I benefici per le aziende nell’ esporre
servizi attraverso queste interfacce sono la possibilità di aumentare l’interoperabilità e
l’integrazione dei processi e i servizi esposti con partner B2B attraverso il web.
•
Big data: I big data sono un insieme di dati di grandi dimensioni, che vengono
creati con frequenza elevata e sono eterogenei. Essi necessitano di essere gestiti in modo
efficiente, e attraverso forme innovative di elaborazione sfruttarne le informazioni che
sono contenute il cui accesso deve essere quanto più possibile disponibile in breve tempo.
La necessità di gestire grossi volumi di dati eterogenei ha fatto emergere un insieme di
soluzioni hardware e software innovative per l’accesso,la lettura, la presentazione e
l’analisi. Esempi di sorgenti di big data sono le tecnologie utilizzate dalle aziende a livello
operativo, il logging in internet, social media e sorgenti streaming. In termini di volume
11
invece, la crescita delle tecnologie mobile sta generando l’incremento della mole dei dati,
dovuta al fatto che l’accesso alla rete è consentito sempre più in mobilità, rispetto al
recente passato basato sull’accesso tramite desktop e laptop. L’approccio innovativo che si
sta cercando di perseguire è la gestione integrata di tutte le tipologie di dati, a differenza
della visione odierna che prevede l’integrazione solo di alcuni tipi di dati,a causa delle
limitazioni tecnologiche. Le tipologie dei dati da dover integrare ed analizzare vanno da
dati completamente destrutturati fino a documenti interamente strutturati. Si intende
sviluppare tecniche innovative che effettuino l’elaborazione dei big data in stream e non
solo attraverso processi batch, e che permettano di accedere ai dati in diverse maniere, ed
esempio non solo in modo tabulare o testuale. Le aziende che producono grossi volumi di
dati nei loro processi di business e hanno difficoltà nel gestire la memorizzazione e
l’accesso alle informazioni contenute, possono sfruttare le soluzioni proposte dai vendors
al fine di migliorare la qualità delle analisi di tutti i dati prodotti sia azienda che attraverso
il web, come ad esempio i dati provenienti dai social media e portali commerciali.
•
Mobile web application: Questo tipo di applicazioni client server possono essere
accedute da qualsiasi dispositivo mobile con un web browser. Attraverso l’uso di HTML e
AJAX ( Asinchrous javascript and xml ) , e sfruttando le features introdotte nel processo
di standardizzazione di HTML5, offrono un’usabilità ed una user experience molto vicine
a quelle ottenute attraverso l’uso di plug-in ad hoc creati per le RIA (rich internet
application), come Flex, Silverlight e JavaFx. Le aziende possono offrirle in parallelo o in
maniera esclusiva alle applicazioni mobile native, per essere accessibili da tutti i
dispositivi mobile. La necessità delle aziende di utilizzare le applicazioni web mobile è il
voler raggiungere il maggior numero possibile di clienti, indipendentemente dal sistema
mobile che essi adottano. L’uso delle mobile web application permette di gestire la
frammentazione del mercato mobile, composto da diversi sistemi operativi, che è in
continua evoluzione. L’unica problematica da gestire nello sviluppo di questo tipo di
applicazioni consiste nel diverso supporto fornito alle features di HTML5 da parte dei
browser. La diffusione del rendering engine web kit nei browser mobile permetterà di
minimizzare questa criticità nella portabilità completa delle mobile web application.
12
•
HTML5: è la nuova versione dello standard HTML in corso di standardizzazione da
parte del consorzio W3C. Attraverso questa nuova versione, insieme a javascript e CSS3,
si vuole fornire un insieme di caratteristiche innovative ai siti web. In questo modo si
possono ottenere usabilità e user experience avanzate senza dover ricorrere a software di
terze parti da installare nel browser, come nel caso delle RIA (Rich Internet Application).
HTML5 è un insieme di features, ognuna delle quali può essere utilizzata isolata o
connessa ad altre per ottenere dei benefici specifici nelle applicazioni web. Esempi di
utilizzo sono inserimento di audio e video tramite tag, uso di web sockets, web workers,
ecc… Essendo il processo di standardizzazione ancora in corso, le specifiche definite
possono subire cambiamenti, ma aspettare la maturazione completa dello standard
potrebbe essere un errore per le aziende che vogliono utilizzare HTML5 nelle proprie web
application. I browser stanno fornendo un supporto crescente allo standard, guidato dai
dispositivi mobile e a seguire le piattaforme desktop. I benefici dell’uso di HTML5 da
parte delle aziende consistono nel fornire applicazioni web, sia mobile che desktop, per
clienti partners o dipendenti che possono valersi delle nuove specifiche per incrementare
le caratteristiche da fornire, in termini di usabilità e user experience.
•
Semantic web: Il web semantico è una definizione creata per indicare l’accesso alle
risorse del web in maniera leggibile dalle macchine. Attraverso l’uso di diverse tecnologie
a supporto si vuole passare ad un web basato su documenti a un web basato su dati, che
possono essere ricercati ed acceduti tramite l’aggiunta di metadati che ne descrivono la
struttura e il contenuto. Le tecnologie utilizzate per aggiungere informazioni semantiche ai
dati del web permettono di definire proprietà e relazioni tra le informazioni prodotte.
Anche se standardizzare il processo e le tecnologie per creare il web semantico non è
facile, la diffusione dei social networks e dei social tagging utilizzati in face book,
Youtube, Twitter, e altri può portare ad una facilitazione e una velocizzazione della
creazione di questa nuova visione del web. Gli utenti del web aggiungono tags semantici
sia in maniera diretta che indiretta, aggiungendo links ad altre risorse e siti per qualsiasi
cosa vogliono comunicare, o aggiungendo commenti a topics o discussioni sui social
networks . I benefici per le aziende che il web semantico può portare sono diverse. Poter
13
condividere informazioni attraverso il web in maniera leggibile ed interpretabile dalle
macchine permette di aumentare l’interoperabilità della applicazioni e dei siti web,
potenziare la ricerca automatizzata di informazioni nella rete globale, effettuare ricerche
efficaci basate su contenuto. Attraverso l’uso del tagging dei dati basato su vocabolari, le
ontologie del web semantico permettono di creare concetti sofisticati, creare relazioni tra
sistemi sulla base di insiemi di dati che non sono esplicitamente definiti, migliorando la
qualità della gestione dei contenuti, l’accesso alle informazioni, l’interoperabilità tra i
sistemi e l’integrazione dei database.
•
Cloud computing: Esso consiste nel fornire come servizio l’accesso e l’utilizzo di
risorse IT scalabili e configurabili, che vengono distribuite attraverso tecnologie web. Le
aziende attraverso il modello di servizio del cloud possono aumentare “on the fly” capacità
e possibilità di utilizzo delle risorse IT, sia software che hardware in base al servizio
acquistato. Esistono diverse configurazioni di servizi basati sul cloud a cui le aziende
possono accedere in base alle esigenze del proprio business: software as a service,
infrastracture as a service e platform as a service.
•
Software as a service: con questo termine di indica un modello di distribuzione di
software applicativo basato sul cloud il cui vendor permette l’accesso tramite il web a un
numero elevato di clienti attraverso infrastrutture e tecnologie di back-end multiutente e
scalabili. Questo approccio permette ai clienti, che possono essere sia clienti customer che
aziende esterne, di poter usufruire dell’applicazione senza costi iniziali di acquisto di
hardware e licenze software; per i Vendor delle applicazioni gestite in cloud questa
struttura permette una gestione centralizzata dell’applicazione, diminuendo i costi di
manutenzione e supporto ai clienti.
•
Infrastructure as a service: con questo termine si indica l’accesso on-demand a
capacità di calcolo offerte come servizio da un service provider. Può essere utilizzato dalle
aziende per sostituire l’acquisto di server e data center propri con l’accesso in remoto
attraverso le tecnologie web o reti private alle risorse richieste. Le risorse risiedono in
remoto e sono accedute in maniera configurabile e condivisa. Alcuni scenari d’uso di
questo tipo di servizio sono: Web hosting, utilizzo di grosse risorse di calcolo necessari in
14
determinati software, utilizzo dell’infrastruttura per sviluppo e test. Gli scenari più maturi
in cui viene utilizzato questo tipo di servizio sono l’hosting di siti web o di applicazioni
web-based, e l’utilizzo dell’infrastruttura come back-end di applicazioni mobile. I
maggiori benefici nell’adozione di questo tipo di servizio sono la riduzione dei costi
nell’accesso a risorse IT, soprattutto per le piccole e medie aziende, sia per l’acquisto che
viene gestito in dipendenza con le proprie esigenze che per la manutenzione dei sistemi
che viene gestita dal service provider.
•
Platform as a service: Con questa definizione di servizio si intende l’offerta alle
aziende di capacità di calcolo e di un ampio range di applicazioni che forniscono alle
aziende
servizi di infrastruttura per sviluppare, testare, implementare e gestire le
applicazioni aziendali senza i costi e la complessità associati all'acquisto, la
configurazione, l'ottimizzazione e la gestione dell'hardware e del software di base. La
piattaforma viene distribuita tramite un approccio cloud-centric. I benefici per le aziende
nell’uso di questo servizio sono una maggiore interoperabilità e integrazione dei processi e
dei dati all’interno dell’azienda che vengono gestiti da applicazioni sviluppate sulla
piattaforma con l’ausilio di meccanismi di interazione e cooperazione; inoltre vengono
diminuiti i costi di manutenzione e gestione di hardware e software.
•
WOA: L’architettura orientata al web è un sottotipo dell’architettura orientata ai
servizi (SOA) che sfrutta ampiamente le tecnologie web. Essa enfatizza il concetto della
generalità delle interfacce attraverso l’uso di cinque costrutti: l’identificazione delle
risorse (ad esempio utilizzando uniform resource identifier [URI]), manipolazione delle
risorse attraverso una loro rappresentazione (esempio utilizzando metodi HTTP), uso di
messaggi auto-descrittivi (esempio uso dei tipi Multipurpose Internet Messaging
Extensions [MIME] ), hypermedia come motore per gestire lo stato delle applicazioni
(esempio links) e la neutralità dell’applicazione. Questo tipo di architettura viene spesso
riferita come rapresentational state transfer (REST). L’architettura WOA ha dominato le
implementazioni user-to-application (U2A) per anni. Essa è usata di frequente per
comunicazioni internet di tipo B2B, ed è stata utilizzata con successo in alcuni casi per
comunicazioni intraenterprise application-to-application (A2A). Alcune aziende hanno
15
scelto questo tipo di architettura in aggiunta o in sostituzione dei Web Services. I maggiori
benefici che le aziende possono ottenere dall’utilizzo di questo tipo di architettura sono un
significativo incremento della condivisione ed estendibilità dei servizi offerti dalle aziende
attraverso il web enfatizzando la neutralità rispetto alle applicazioni delle interfacce e
l’accesso orientato agli hypermedia; inoltre questo approccio permette di velocizzare
maggiormente l’integrazione tra le applicazioni, diminuire i costi e sforzi nelle modifiche
di applicazioni e sistemi ed aumenta la riusabilità dei servizi.
•
MADP: Mobile application development platforms sono delle piattaforme che
forniscono una serie di servizi integrati per gli sviluppatori di applicazioni mobile. Esse
forniscono servizi per progettazione, codifica, integrazione, testing, pubblicazione, e la
gestione delle applicazioni mobile di tipo business-to-consumer ( B2C ), business-tobusiness ( B2B ) e business-to-employee ( B2E ). I vendors di queste piattaforme
rilasciano di solito toolkit nativi, web e cross-platform. Questo tipo di piattaforme
rappresentano l’evoluzione e la convergenza di mobile consumer application platforms (
MCAP ) e mobile enterprise application platforms ( MEAP ). I benefici per le aziende
nello sviluppo di applicazioni con queste piattaforme sono la possibilità di incrementare la
produttività in caso di applicazioni per i dipendenti aziendali, o aprire l’azienda a nuove
opportunità di business sul canale mobile, sia in via di applicazioni web che applicazioni
native o ibride. In entrambi i casi il fattore determinante nella convenienza di utilizzare
queste piattaforme è legato alla rapida diffusione di smatphone e tablet nei prossimi anni.
All’interno di questo insieme di tecnologie che le aziende possono acquisire e inserire
nelle proprie attività e infrastrutture, si nota che molte di queste tecnologie sono
strettamente connesse al contesto mobile. Il suo sviluppo, in termini di dispositivi
acquistati e di innovazioni che vengono introdotte con elevata frequenza, lo rende uno tra i
maggiori settori su cui le aziende possono investire al fine di incrementare guadagni,
aumentare l’efficienza dei processi e far evolvere e sviluppare l’insieme di attività che
possono migliorare con l’approccio mobile. Il mobile odierno è incentrato sul paradigma
app-oriented, ossia sullo sviluppo di applicativi mobile per poter fornire servizi e
16
funzionalità in qualsiasi settore aziendale e in tutti i tipi di interazioni: B2B, B2C e B2E.
Un’azienda che vuole in questo momento investire nel mobile e nello sviluppo di
applicativi a supporto delle proprie attività , deve gestire la frammentazione del mercato
sia dei dispositivi che dei sistemi operativi. Questa duplice frammentazione comporta un
aumento dei costi di sviluppo e di manutenzione nel tempo delle applicazioni mobile
multipiattaforma, cioè se l’azienda vuole fornire applicativi che siano eseguibili su un
vasto numero di piattaforme, sia hardware che software. Un’azienda che intende realizzare
applicativi multipiattaforma deve quindi identificare i dispositivi hardware da utilizzare
come punto di riferimento nello sviluppo delle applicazioni , e identificare i sistemi
operativi che intende supportare. Di seguito viene proposta un’analisi di mercato
incentrata sul tablet, che secondo stime di settore diventerà in futuro il dispositivo più
utilizzato in ambito mobile, e un’analisi delle caratteristiche dei sistemi operativi mobile
IOS e ANDROID che attualmente detengono le fette più grandi del mercato dei sistemi
operativi mobile; in questa analisi viene descritto anche Windows 8, sistema operativo
della Microsoft che con un approccio innovativo cerca di integrare il contesto mobile e
quello desktop, fattore importante che permette un’integrazione del lavoro in mobilità e da
ufficio.
1.2. Il tablet
Il tablet è, in ordine cronologico, l’ultimo tipo di device introdotto nel mercato mobile
dopo il laptop, il netbook e lo smartphone. Esso è stato prodotto inizialmente dalla Apple
con sistema operativo IOS, ma in poco tempo questo dispositivo è stato proposto da
diversi vendors su diversi sistemi operativi. Le sue caratteristiche peculiari sono uno
schermo che varia tra i 7 e i 10 pollici di tipo touchscreen, attualmente quasi sempre
capacitivo, e una potenza di calcolo mediamente superiore a quella degli smartphone (ad
eccezione di smartphone di ultima generazione di fascia alta del mercato ); ulteriori
caratteristiche hardware che vengono aggiunte, come il gps o la fotocamera, variano in
base al modello e alla fascia di mercato. Secondo Gartner lo schermo di un tablet, per
essere definito tale,deve essere di almeno 7 pollici. Rispetto ai PC portatili i tablet
presentano migliori caratteristiche di portabilità anche grazie ad una maggiore durata della
17
batteria, d’altro canto,però, possono risultarne meno performanti in alcune specifiche
attività e mancare di qualche caratteristica. Per quanto riguarda la connettività si trovano
in commercio tablet dotati di sola connessione WiFi ed altri dotati di sim telefonica, che
ne consente la connessione 3G e, in taluni casi, anche la possibilità di effettuare/ricevere
telefonate ed SMS. La caratteristica principale del tablet è abbinare quindi una elevata
mobilità l’utilizzo del display e della esperienza touch nelle applicazioni, che usufruendo
delle dimensioni dello schermo sufficientemente grandi e dei sensori, permettono di
ottenere scenari di utilizzo innovativi. Il tablet quindi può essere utilizzato sia come
dispositivo multimediale e di consumo, sia come strumento di lavoro. In quest’ultimo
contesto si stanno introducendo delle features aggiuntive, come la docking station, che
permettono una migliore adattabilità del tablet in ambito
Figura lavorativo.
2: Tablet Audrey
1.2.1. Storia
Nonostante il tablet sia stato lanciato sul mercato con risultati vincenti nel 2010, la sua
concezione risale alla fine degli anni ottanta, quando la penna e lo schermo tattile, già
presenti nei calcolatori e pc fissi, riescono ad essere inseriti in dispositivi portatili grazie
all’evoluzione dei microprocessori e soprattutto delle batterie. Nel 1968, il ricercatore
Alan Kay dal centro Xerox PARC stava lavorando su un progetto che assomigliava molto
al tablet odierno: il Dynabook. Inizialmente questo era pensato come dispositivo per
bambini, ma non riuscì a conquistare il mercato. Nel 1994, 30 anni dopo il Dynabook, la
Fujitsu lancia il tablet Stylistic, il primo ad offrire Windows 95 come sistema operativo.
Figura 1: iPad
Verrà utilizzato dai presidenti del G7 all’incontro di
Halifax nel 1995.Negli stessi anni l’azienda DEC creò il
tablet Lectrice, dedicato a leggere i file di testo. Nel 2000
viene presentato il tablet dell’azienda 3Com con il
nome di Audrey (Figura 1). Questo dispositivo era
pensato per la navigazione su internet con antenna e
18
tastiera wireless. Il 7 novembre 2002 la Microsoft presenta ufficialmente i tablet pc e il
nuovo sistema operativo Windows XP Tablet Pc Edition, versione potenziata di Windows
XP Professional, che consente l’inserimento dei dati non solo da manoscritto ma anche
tramite voce. Nel 2003 Arrivano i tablet Intel Centrino; tutti i principali produttori di pc
hanno almeno un tablet a listino, mancano solo Dell e Sony; il prezzo medio è superiore ai
2000 euro, non sono esposti o in vendita in nessun negozio fisico, è quasi impossibile
vederli e testarli prima dell’acquisto. Il destino dei tablet è destinato a cambiare quando
nel 2010 Apple lancia l’iPad, il primo tablet ad aver ricevuto un successo incredibile,
superando tutte le previsioni, vendendo decine di milioni di pezzi (Figura 2). Il device di
Apple ha dato l’avvio alla moderna scalata al successo mondiale dei tablet.
1.3. Analisi di mercato
Il quadro generale del mercato , sia dektop che mobile, dal 2007 (data di produzione
dell’IPhone) ad oggi si è evoluto in maniera radicale. Nel periodo in cui venivano prodotti
i primi tipi di smartphone i Pc avevano la posizione di leader come device
nell’information tecnology, con Microsoft quasi monopolista nei sistemi operativi, Intel
leader nel mercato dei microprocessori e HP aveva acquisito da poco il ruolo di leader
nella vendita dei Pc sostituendo la Dell, venendo insidiato solo dai vendors asiatici nella
fascia bassa di mercato. L’apparizione dei primi tablet non aveva destato alcun interesse.
Apple, dopo il rischio di fallimento negli anni 90, stava crescendo, praticamente senza
concorrenti, con l’iPod e con il sistema software e commerciale iTunes costruito attorno
ad esso; stava inoltre recuperando terreno con il Mac nella fascia alta dei PC. Nokia
regnava incontrastata (con circa il 40% su scala mondiale) nel mercato dei cellulari e in
quello in fase di sviluppo degli Smartphone, ove RIM, con il suo Blackberry, si era
ritagliata una nicchia nel settore business. I social network erano apparsi da qualche anno
all’orizzonte, ma la loro popolarità non era ancora esplosa. Il cloud computing esisteva
ma, tranne poche eccezioni, si era ancora a livello di progetti di ricerca (ICT4Executive).
19
1.3.1. Analisi device mobili
Smartphone e tablet sono i protagonisti dell’attuale successo del mercato mobile: secondo
i dati forniti da Gartner, società multinazionale leader mondiale nella ricerca e analisi nel
campo dell’information tecnology, nel secondo trimestre del 2012 sono stati 153.9 milioni
gli smartphone venduti, in crescita del 42.1% rispetto ai 108.3 milioni di unità dello scorso
anno; per quanto riguarda i tablet, invece, sono state 388.950 le unità vendute, in crescita
del 90.5% rispetto alle 204.150 unità nello stesso trimestre dello scorso anno. Questi
ultimi dati sono stati resi noti da SIRMI, società di Consulenza, Ricerche e Analisi di
Mercato, specializzata nel settore della digital technology, che ha da poco pubblicato i
risultati sul monitoraggio dei dati relativi all’andamento del secondo trimestre del 2012:
come rappresentato nella Tabella 2, il mercato dei Client evidenzia, rispetto al
corrispondente trimestre del 2011, un incremento complessivo del 4% circa
(corrispondenti a circa 1.485.000 unità vendute) nonostante quasi tutte le tipologie di
prodotto registrino un trend negativo, con la peggiore performance a carico dei Netbook (68,3%). Registrano un incremento solo le vendite di tablet (+90%) e NoteBook
professionali (+6%)
Unità
consegnate
Q2.11
DT Consumer
109.000
DT professional 255.900
NB consumer
392.200
NB professional 287.000
Netbook
164.300
Tablet
204.150
Thin client
5.400
Totale PC Client 1.427.350
Unità
consegnate
Q2.12
92.550
242.810
390.250
304.100
52.100
388.950
5.290
1.485.120
Variazione %
Quote % Quote %
-15,10%
-5,10%
-0,50%
6,00%
-68,30%
90,50%
-2,00%
4,00%
Q2.11
7,60%
17,90%
27,50%
20,10%
11,50%
14,30%
0,40%
100,00%
Q2.12
6,20%
16,30%
26,30%
20,50%
3,50%
26,20%
0,40%
100,00%
Tabella 1: Analisi di mercato PC Client Q2.12 (SIRMI)
Stando alle previsioni Gartner (Figura 4), i tablet continueranno ad avere un ruolo
dominante, in termini di unità vendute e tassi di crescita, nel mercato client anche nel
futuro. Si stima infatti che nel 2016 questi device raggiungeranno a livello mondiale oltre
le 300 milioni di unità vendute, di poco inferiore a quelle dei mobile pc (327 milioni).
20
Figura 4: Gartner. Previsioni mercato client europeo
Mercato client 2016 (W.E.)
12%
50%
24%
Desk-‐based PC
Mobile PC
Ultramobile Notebook
Tablet
14%
Figura 5: Gartner. Quote di mercato dei dispositivi nel mercato europeo 2016
Lo sviluppo del mercato mobile, con la diffusione di smartphone e tablet, congiuntamente
allo sviluppo della banda larga e del wifi, contribuiranno alla crescita del traffico internet
mobile, che, stando alle previsione fornite da Cisco, crescerà entro il 2016 di ben 18 volte,
raggiungendo un volume dati annuale di 130 exabyte (1018 byte). Nel 2011, il 22% del
traffico IP è stato originato da dispositivi diversi da pc, ma entro il 2016 tale quota
crescerà fino al 31%. Nel 2011 solo il 6% del traffico internet consumer è stato originato
da dispositivi diversi da pc, ma entro il 2016 tale quota crescerà al 19% (con un CAGR del
21
26%). Il traffico proveniente da dispositivi wireless supererà il traffico proveniente da
dispositivi cablati entro il 2016, raggiungendo il 61% del traffico IP, in aumento rispetto al
45% del 2011.
2011
2016
MBs per month
MBs per month
Non Smartphone
M2M
Smartphone
E-‐Book Reader
Tablet
Laptop
4,3
108
71
266
150
2576
750
2880
517
4223
2131
6942
Figura 6: Global mobile data traffic (CISCO)
Exabytes per month
12
10,8
10
8
6,9
6
4,2
4
2
0,6
2,4
1,3
0
2011
2012
2013
2014
2015
2016
Exabytes per month
Figura 7: Previsioni traffico IP 2016 (CISCO)
1.3.2. Sistemi operativi mobile
Stando ai dati pubblicati da IDC, Tabella 3, sul monitoraggio del mercato Mobile1,,
Android e iOS dominano il mercato dei sistemi operativi mobile, detenendo
congiuntamente oltre l’80% del mercato. Leader di mercato è Android che detiene il 59%
del mercato con un venduto complessivo di 89.9 milioni di device, registrando una crescita
del 145% rispetto al primo trimestre di un anno fa. Segue iOS, con 35.1 milioni di unità
1 Worldwide Quarterly Mobile Phone Tracker di IDC 22
vendute, e in termini di share il sistema operativo di Apple cresce da 18.3% al 23%.
Symbian è il sistema operativo che ha marcato il declino più forte nell’ultimo anno
(risultato generato soprattutto dalla decisione di Nokia di passare da Symbian a Windows
phone); in calo anche la domanda dei dispositivi Blackberry. Linux continua a mantenere
in modo stabile la sua presenza limitata sul mercato, grazie soprattutto al supporto di
Samsung per Bada. Windows phone/Windows mobile non ha ancora trovato la sua strada
per emergere, ma il 2012 potrebbe essere l’anno della svolta, soprattutto grazie alla
collaborazione Nokia-Windows e al lancio di Windows 8.
Sistema
Operativo
Variazione
Unità consegnate Unità consegnate %
Quote % Quote %
Q1.11
Q1.12
Q1.11
Q1.12
Android
36,70
89,9
145,0%
36,1%
59,0%
iOS
18,60
35,1
88,7%
18,3%
23,0%
Symbian
26,40
10,4
-60,6%
26,0%
6,8%
BlackBerry OS
13,80
9,7
-29,7%
13,6%
6,4%
Linux
3,20
Windowd
phone7/
windows mobile 2,60
3,5
9,4%
3,1%
2,3%
3,3
26,9%
2,6%
2,2%
Other
0,30
0,4
33,3%
0,3%
0,3%
TOTAL
101,6
152,3
49,9%
100,0%
100,0%
Tabella 2: IDC.Analisi di mercato sistemi operativi mobile 2012
1.3.3. Mercato tablet
Il mercato dei tablet è caratterizzato da un tasso di crescita della domanda molto elevato, e
da una cadenza in termini di innovazione, modelli e specifiche hardware che vengono
prodotti altrettanto elevata. Dall’ultimo rapporto fornito dalla Gartner, emergono dati
interessanti sul mercato dei tablet e sulle prospettive di vendita negli anni a venire. Dal
grafico sottostante (Figura 8) si può notare come nel corso del 2011 il mercato abbia
subito un incremento del 341% rispetto all’anno precedente raggiungendo le 59.870 unità
vendute, dato quest’ultimo destinato quasi a raddoppiarsi nel 2012, stando alle previsioni,
23
con un’ulteriore incremento del 233%. Un mercato in continua espansione, con elevati
tassi di crescita, che si stima raggiunga le 306.584 unità di device venduti nel 2016.
Figura 8: Gartner. Previsioni di vendita dei tablet
4%
2% 0%
41%
2012
Android
iOS
Windows
QNX
53%
other
Figura9: Gartner. Quote di mercato sistemi operativi mobili 2012
Stando alle previsioni di Gartner il mercato è destinato a cambiare nel prossimo futuro:
com’è graficamente rappresentato in Figura 10, si stima che nel 2016 iOS sia destinato a
perdere la sua posizione dominante, leader di mercato diverrà Android, con il 51% dei
dispositivi venduti, in crescita le quote del sistema operativo Windows.
24
Figura 10: Gartner. previsioni quote di mercato sistemi operativi mobili 2016
Figura 3: Confronto quote di mercato sistemi operativi mobile 2012/2016
1.4. I tablet in azienda
In Italia cresce sempre di più il numero dei
lavoratori che, esercitando la loro attività lavorativa in mobilità,
necessità di accedere/produrre informazioni aggiornate attraverso l’utilizzo di dispositivi
mobili; le diverse categorie possono essere supportate da soluzioni specifiche di mobile
business. Le soluzioni mobile hanno un impatto pervasivo su tutta la catena del valore di
un’impresa, potenzialmente molte sono le attività migliorabili attraverso l’utilizzo di una
25
soluzione mobile. I benefici che queste soluzioni possono portare sono spesso
incredibilmente rilevanti; ne sono una significativa dimostrazione i valori degli indicatori
di redditività di questi investimenti: i tempi di ritorno molto brevi (spesso inferiori
all’anno) e indicatori di profittabilità molto alti. Tra i motivi per cui le aziende stanno
transitando verso il mobile ci sono la possibilità di ridurre i costi, il maggior controllo del
business, la riduzione dell’uso della documentazione cartacea nelle attività aziendali e un
aumento dell’efficacia e dell’efficienza delle forze lavoro sul campo. Cresce sempre più il
numero
delle
aziende
che
decide
di
introdurre
dispositivi
tablet
all’interno
dell’organizzazione. A confronto con i “tradizionali” device mobili (Notebook, Netbook,
e Smartphone) i tablet coniugano diverse caratteristiche fondamentali della mobility
applicata al business: elevata portabilità, buona capacità di visualizzazione e potenza di
calcolo. I tablet, inoltre, si differenziano dagli altri device mobili anche per alcune
peculiarità innovative in grado di influenzare la user experience: introducono una modalità
di fruizione radicalmente diversa, abilitata all’utilizzo di schermi moultitouch, che
stravolge le tradizionali interfacce uomo-macchina (basate su tastiere e mouse); sono
“always on”, sempre disponibili e con tempi di accensione pressoché istantanei. Anche in
Italia, come testimoniato dal più recente studio della School of Management del
Politecnico di Milano sul tema della mobility, i professionisti dell’Information Technology
sembrano apprezzare queste caratteristiche del tablet, scommettendo sempre di più sul loro
futuro in azienda. Questi i risultati dello studio condotto su 230 CIO delle principali
aziende italiane: come rappresentato dal grafico in Figura , ad oggi oltre la metà dei CIO
italiani ha già introdotto in azienda dispositivi tablet (56%) e se ne ritiene soddisfatto,
mentre tra i CIO che ancora non li hanno adottati la maggioranza si dimostra intenzionata
a farlo; tra le motivazioni che hanno portato i pochi CIO (7%) ad essere reticenti
all’introduzione dei dispositivi vi sono l’assenza di personale in mobilità da supportare o
la mancata necessità nel proprio business, o la recente conclusione di progetti che
prevedano l’introduzione di altri device.
26
I dispositivi tablet sono già stati introdotti nella sua azienda?
12%
56%
No, nessuna intenzione per ora
Verranno adottati nel medio lungo/periodo Verranno adottati nel breve periodo 25%
Già introdotto
7%
Figura 12: Tablet in azienda (School of Management del Politecnico di Milano)
Confrontando i risultati con quelli ottenuti dall’edizione 2011della ricerca (Figura 13) si
rileva che il numero dei CIO che ha introdotto in azienda un dispositivo tablet è cresciuto
dal 47% al 56%, e soprattutto che la dimensione di chi non ha intensione di adottarne si è
ridotta drasticamente. Se nel 2011 un CIO su quattro si era dichiarato “disinteressato
all’adozione”, a poco più di 6 mesi di distanza i disinteressati sono scesi a meno di 1 su
10. Tra coloro che lo scorso anno si dicevano intenzionati a introdurre “a breve” o “nel
medio periodo” un tablet in azienda, oltre la metà è già passata dalle parole ai fatti dotando
il personale aziendale di tali dispositivi.
27
47%
56%
10%
12%
15%
25%
28%
7%
2011
No, nessuna intenzione per ora
Verranno adottati nel breve periodo
2012
Verranno adottati nel medio/lungo periodo
Già introdotto
Figura 13: Confronto risultati indagine 2011/2012 (School of Management del Politecnico di
Milano)
E’ interessante notare, al fine di sottolineare la rapidità evolutiva di tale mercato, come le
esigenze, le opinioni, le scelte siano notevolmente cambiate: infatti, analizzando le nuove
risposte delle aziende che solo un anno fa si dichiaravano disinteressate all’acquisto dei
tablet, il 23% ha dichiarato di aver cambiato idea e di aver già adottato un dispositivo
tablet, il 45% ha rivisto le proprie scelte e si dichiara intenzionato all’acquisto , solo il
32% resta sulla sua posizione di scarsa utilità di tali dispositivi nella propria azienda (
Figura 14).
Figura 14: Risposte 2012 dei CIO che nel 2011 si erano mostrati disinteressati all'adozione
di tablet in azienda
28
Il settore enterprise sta affrontando la transizione verso il mobile business in un intervallo
di tempo inferiore a qualsiasi altra recente tecnologia comparsa sul mercato. Questa rapida
transizione comporta rischi dovuti all’acquisizione di tecnologia che può non essere
matura rispetto a problematiche come gestione tempi e costi di sviluppo, formazione del
personale IT, esigenze e caratteristiche dei dipendenti, regole per la gestione della privacy,
rischi sulla sicurezza dei dati aziendali. Nonostante queste incertezze gli investimenti fatti
dalle aziende nelle tecnologie mobile sono cresciuti e continueranno a crescere nei
prossimi anni. Come emerso nel report del 2011 dell’Osservatorio del Politecnico di
Milano le figure professionali in azienda maggiormente coinvolte in questo cambiamento
si confermano gli executive e i C-level, dal momento che il 65% già utilizza questi
dispositivi, mentre il 33% li utilizzerà in futuro. Percentuali più basse interessano le altre
tipologie professionali: il personale di vendita è in parte già equipaggiato (29% dei casi),
ma soprattutto è destinato a ricevere un pc/tablet in futuro (65%); ancora più basse le
percentuali dei manutentori, infatti un 13% è già fornito e un 40% in attesa di diventarlo
nel breve-medio periodo. Lo stesso studio ha cercato di rilevare eventuali fenomeni in atto
di sostituzione/cannibalizzazione tra i dispositivi mobili utilizzati in azienda. Quasi 9 CIO
su 10 (88%) ritengono che i tablet andranno ad affiancarsi a gli Smartphone, riducendo il
ruolo di questi ultimi a specifiche applicazioni mobili (2 CIO su 10 ritengono addirittura
che per l’accesso a queste specifiche applicazioni mobili i tablet ridurranno in modo
significativo il ruolo degli Smartphone).
29
Figura 15: Tablet vs Smartphone (School of Management del Politecnico di Milano)
Se nel caso degli Smartphone i CIO si aspettano un affiancamento con i tablet, nel caso di
Notebook emerge la previsione di un’effetto sostituzione; quasi il 90% dei CIO intervistati
ritiene che i tablet, con riferimento ad alcune tipologie di dipendenti, prenderanno il posto
dei pc portatili.
Figura 14: Tablet vs pc portatili (School of Management del Politecnico di Milano)
30
1.5. Bring your own device
La crescita del mercato mobile e la diffusione dei dispositivi mobile nel settore enterprise,
sta portando negli ultimi anni a device mobili dalla doppia veste: personali da una parte e
professionali dall’altra; un unico dispositivo, di proprietà del personale aziendale o
concesso loro in dotazione dalle aziende stesse, utilizzato sia per attività lavorative sia per
esigenze personali. Tale fenomeno, noto come BYOD (acronimo di Bring Your Own
Device) ha una notevole incidenza sulla sicurezza dei servizi informatici aziendali con il
rischio di mettere a repentaglio informazioni riservate. Il BYOD cambierà lo scenario
dell'enterprise mobility e i CIO sono chiamati a strutturare strategicamente le policy di
gestione di questi dispositivi per minimizzare i rischi legati ai problemi di sicurezza
derivanti dall'uso improprio degli stessi sulle reti e all'interno dei sistemi aziendali. Il
BYOD spinge quindi i responsabili IT a ricercare una possibilità di equilibro tra
abilitazione e flessibilità da un lato e necessità di controllo e sicurezza dall'altro. La
Symantec, azienda californiana nota per la produzione di software destinati alla protezione
dei pc da attacchi informatici, ha commissionato uno studio ad Astraricerche per cercare di
capire abitudini e intenzioni di oltre mille dipendenti e collaboratori di aziende italiane di
medie e grandi dimensioni (da 100 ad oltre 2500 addetti). E’ emerso come molte delle
aziende in esame non abbiano stilato delle policy per regolare l’utilizzo dei dispositivi
mobili da parte dei dipendenti; in alcuni casi, inoltre, si tenta di estendere le regole relative
ai dispositivi desktop anche a quelli mobili, senza tener conto delle necessità specifiche di
questo secondo ambito.
Questi i punti più significativi della ricerca(Figura 19):
•
Tra i 1.062 intervistati poco più della metà, il 54,2% ha ricevuto richiesta di
installare un software antivirus sul proprio dispositivo personale o su quello concesso in
dotazione, e solo nel 37,1% dei casi con l’obbligo di tenerlo aggiornato. Una parte di
coloro che sono lasciati liberi di decidere, sceglie di sua iniziativa di affidarsi ad un
antivirus, ma il 28,1% evita di scaricarlo o, se lo fa, dimentica di eseguire gli
aggiornamenti.
•
A poco più di un quarto dei lavoratori (25,9%) viene richiesta l’impostazione di una
31
password a salvaguardia dei dati in caso di furto o smarrimento, e il 15,2% del campione è
stato invitato a non consentire l’uso dei dispositivi ad altre persone
•
Nel 56,7% dei casi l’istallazione di app mobili è consentita senza alcun limite; solo
il 18.1% delle aziende vieta l’aggiunta di applicazioni al sistema rispetto a quelle
eventualmente preinstallate, mentre il 15% dei dispositivi viene configurato in modo da
impedirlo (Figura 21).
•
Per quanto riguarda l’istallazione di app circa un terzo degli intervistati (38% in
relazione a device di proprietà e 30,9% per quelli concessi in utilizzo dall’azienda) è solito
scaricare applicazioni anche dagli store non ufficiali e, rispettivamente nel 9% e 16% dei
casi, è disposto ad eseguire il jailbreak per rimuovere eventuali limitazioni del sistema e
installare l’elemento desiderato.
Figura 19: Regole e sistemi di protezione imposti dall'azienda nell'uso di dispositivi personali e
aziendali
32
Figura 5: Le applicazioni sui dispositive personali e aziendali utilizzati per accedere al sistema
informative aziendale
Symantec sottolinea come app store non ufficiali e il jailbreak sono tra le principali cause
di minacce e malware sui dispositivi mobili. Dalla stessa analisi emergono anche dati
relativi ai comportamenti del personale aziendale al manifestarsi di un guasto, di una
violazione, di furto o smarrimento del dispositivo (Figura 21); anche in questo caso le
reazioni dei singoli risentono dell’insufficienza di indicazioni precise da parte delle
aziende.
Figura 21: I comportamenti in caso di gravi rischi per la sicurezza dei dispositivi personali e
aziendali utilizzati per accedere al sistema informativo aziendale
33
Al manifestarsi di un problema che metta a rischio la sicurezza dei dati aziendali il 38.6%
degli intervistati cercherebbe supporto rivolgendosi al responsabile IT della propria
azienda. Dietro la tendenza a non chiedere aiuto al personale specializzato aziendale si
celano diversi motivi: il 32,7% dei lavoratori dichiara di non volersi sentire in difetto, il
20% pensa invece che al manifestarsi del danno potrebbe esser troppo tardi per poter
riparare; il 19,4% ammette di temere sanzioni disciplinari; seguono il 13,3% di coloro che
temono sanzioni economiche e la stessa percentuale di chi ritiene che la propria azienda
non abbia le competenze per risolvere il problema, infine si registra un 11,2% che si
dichiara preoccupato di un’invasione della privacy. Le aziende che praticano BYOD
devono disporre di policy per la sicurezza dinamiche e flessibili. Le policy per il mobile
devono essere costantemente aggiornate, in modo da poter affrontare e gestire nuove
problematiche emergenti e nuovi trend dovuti alla costante innovazione. Riportando
quanto dichiarato da Symantec, elemento fondamentale nell’elaborazione di policy
aziendali è la comunicazione ai dipendenti con aggiornamenti continui.
34
Capitolo 2
Analisi sistemi operativi mobile
Il mercato offre attualmente diverse alternative per quanto riguarda i sistemi operativi,
dall’analisi condotta su 162 CIO italiani risulta che meno di un CIO su 4 dichiara di aver
identificato un unico sistema operativo di riferimento per il futuro (Figura ) lasciando
quindi la porta aperta anche ad altri sistemi (e relativi dispositivi). Il 70% dei CIO afferma
di aver già identificato due (29%) o più (41%) sistemi operativi di riferimento, mentre solo
il 7% di non aver ancora scelto.
Figura 17: La scelta dei sistemi operativi mobile nel settore enterprise
35
Figura 6: I sistemi operativi mobile nel settore mobile
Anche nel mercato enterprise dei sistemi operativi mobili Apple iOS rappresenta, ad oggi,
la scelta decisamente più diffusa; tuttavia nel prossimo futuro questa situazione sembra
destinata a modificarsi. La natura evolutiva del mercato dei tablet, in cui sono entrati
ulteriori players, non potrà che portare a un’offerta sempre più diversificata, che
consentirà e richiederà di valutare con maggiore consapevolezza quale sia il tablet e il
sistema operativo più adatto per le specifiche esigenze dell’utente business da supportare e
per quelle dell’organizzazione. Inoltre i fenomeno del BYOD ( Bring Your Own Device)
potrebbe avere trend di crescita significativi, non compatibili con un approccio “chiuso” al
mondo dei sistemi operativi per tablet. In questo mercato oltre Google (con Android) e ad
Apple (con iOS), soprattutto in ambito business, nel futuro potranno giocare un ruolo
primario anche player come RIM (con QNX) e Microsoft (con Windows 8): il primo
facendo leva sulla penetrazione raggiunta nel mondo enterprise con altri dispositivi, e il
secondo perché vuole realizzare una crescente convergenza tra i dispositivi tradizionali
(notebook, e in generale desktop) e nuovi device mobili, in modo da poter, da una parte,
potenzialmente facilitare il porting di software tradizionali in ambiente mobile e,
dall’altra, incentivare la diffusione sul mercato facendo leva sulla user experience degli
utenti. Un tema sicuramente importante legato all’introduzione dei tablet in azienda è
quello della sicurezza dei dati presenti in questi device mobili. Infatti, l’elevata portabilità
36
dei tablet li espone al rischio di furti e/o smarrimenti più frequenti, rispetto a quanto
poteva accadere con i notebook. Per affrontare questo problema, più della meta dei CIO
intervistati intende orientarsi verso architetture web-based per applicazioni mobili,
evitando così di memorizzare in locale, sul dispositivo, dati aziendali sensibili che restano
così accessibili solo da remoto e tramite autenticazione. E’ essenziale per le aziende
dotarsi di una strategia di sicurezza solida, affiancata da un programma di
sensibilizzazione e informazione degli utenti. Uno studio2 condotto da Trend Micro in
collaborazione con Altimeter Group, Enterprise Mobility Foundation e Bloor Research
evidenzia i livelli di adeguatezza delle piattaforme mobili in fatto di utilizzo delle stesse in
ambito enterprise; valutandole sulla base di più fattori, fra cui la sicurezza integrativa,
sicurezza applicativa, autenticazione, cancellazione sicura dei dati, firewall del dispositivo,
virtualizzazione e altri ancora. Il sistema operatvo mobile più sicuro è risultato essere
Blackberry, seguono iOS e infine Windows phone e Android.
Dalle analisi effettuate emerge che il mercato dei tablet è in continua evoluzione e che
nelle aziende c’è incertezza se scegliere un unico sistema operativo di riferimento sul
quale sviluppare ed utilizzare le applicazioni aziendali o optare per un approccio
multipiattaforma. I tre sistemi operativi mobile per tablet sui quali verrà effettuata
un’analisi comparativa sono Android, Windows 8 e IOS, i quali nelle previsioni effettuate
da Gartner saranno in futuro i 3 sistemi operativi che si divideranno il mercato. Mentre
IOS e Android sono stati sviluppati principalmente per un uso in mobilità, Windows 8
vuole creare una rottura sulla divisione tra user experience e lavoro in mobilità e in
ufficio, fornendo un sistema operativo che permetta un utilizzo integrato e uniformato dei
due approcci. Questa caratteristica innovativa può permettere alla Microsoft di acquisire
fette consistenti di mercato nel settore business, di cui Apple è attualmente il leader di
mercato.
2 “Enterprise Readiness of Consumer Mobile Platforms” 37
2.1. Android
Il sistema operativo Android è stato ufficialmente presentato il 5 novembre 2007
dall’Open Handset Alliance, associazione istituita ufficialmente lo stesso anno.
Quest’ultima, capeggiata da Google, è formata da 35 membri (tra i quali operatori
telefonici, produttori di device, produttori di semiconduttori, compagnie di sviluppo
software e di commercializzazione) con lo scopo di creare standard open source per
dispositivi mobili. La piattaforma fa il suo ingresso nel mercato degli smarthphone
nell’ottobre del 2008, l’anno successivo del lancio dell’ Iphone, ma al contrario del suo
principale competitor lo scopo di Android è di abbracciare una gamma quanto più vasta di
terminali. Grazie alla sua natura open source e alla versatilità, oggi questo sistema
operativo è il più diffuso in ambito mobile, coprendo tutte le fasce di mercato di device
con caratteristiche eterogenee.
2.1.1. Caratteristiche tecniche
Android viene rilasciato con licenza Apache, una licenza di software libero scritta dalla
Apache Software Foundation (ASF) che ne consente l’utilizzo per ogni finalità. La
distribuzione, modifica e vendita sono consentite purché si specifichi con un’informativa
che si è utilizzato del software sotto questa licenza, preservando il diritto d'autore e
l’esclusione di responsabilità nelle versioni modificate. Il sistema operativo oltre alle
funzioni di base come la creazione e schedulazione dei processi, provvede a fornire tutte le
risorse del dispositivo, come la fotocamera, i dati GPS, le funzioni Bluetooth, funzioni di
telefonia e le connessioni di rete. L’architettura a livelli di Android permette di espandere
facilmente le funzionalità del sistema, in questo modo si riescono a supportare tecnologie
innovative come ad esempio l’NFC (Near Field Comunication), il riconoscimento
facciale, dell’impronta digitale e la firma biometrica. Le applicazioni che girano sul
sistema Android sono di diversi tipi; esistono una serie di applicazioni preinstallate tra cui
telefono, email, agenda, browser web, e contatti, accessibili sia direttamente come
applicazioni utente che indirettamente se richiamate dalle altre applicazioni. Le
applicazioni create dagli sviluppatori possono essere vendute tramite il market ufficiale, il
Google Play Store o distribuite attraverso siti di terze parti. Gli sviluppatori possono
38
contare su strumenti di sviluppo compatibili con la maggior parte dei sistemi operativi
desktop, comprendenti un framework SDK scritto in linguaggio Java, un simulatore di
dispositivo virtuale (ADT) e un editor visuale che utilizza XML per la creazione delle
interfacce grafiche. Grazie a questi tool in pochi anni il market ufficiale di Android si è
popolato di tantissime applicazioni e ad oggi è arrivato a contarne più di 600.000.
2.1.2. Versioni e compatibilità
Il 28 Giugno 2012 è stato presentato il dispositivo che supporta l’ultima versione del
sistema operativo Android 4.1, denominata Jelly Bean. Quest’ultima versione prosegue il
cammino intrapreso il 19 ottobre 2011, data in cui è stata presentato Android 4.0 Ice
Cream Sandwich, con il quale si è deciso di adottare un’unica versione di sistema
operativo sia per tablet che per smartphone. La versione di Android utilizzata per i tablet
era la 3.0 Honeycomb, tuttavia nel mercato sono presenti maggiormente dispositivi, sia
smartphone che tablet, che montano la versione precedente 2.3 Gingerbread. Il sito
ufficiale di Android riporta come sono distribuite le versioni di Android fra i dispositivi in
commercio e mostra che la versione 2.3 Gingerbread è diffusa con una percentuale che
sfiora il 60%, segue Ice Cream Sandwich, uscita nell’ottobre del 2011, con una
percentuale inferiore al 24%, mentre Jelly Bean conta appena l’1,8% dei dispositivi che lo
supportano (Dati raccolti durante la prima metà di ottobre 2012).
Figura 22: Distribuzione percentuale delle versioni della piattaforma Android
39
Uno dei fattori che porta le versioni più recenti a penetrare lentamente nel mercato è
dovuto al fatto che ciascun produttore di hardware deve aderire a delle specifiche di
compatibilità per rilasciare firmware corrispondenti a una versione specifica. Ogni
versione di Android e delle relative API viene corredata da un documento dove vengono
definite le specifiche di compatibilità, non opzionali, alle quali bisogna aderire. Questa
condizione garantisce il funzionamento del sistema operativo su dispositivi con
caratteristiche hardware molto diverse. Per effettuare un aggiornamento a una versione
successiva è necessario attendere il rilascio del firmware che supporti tutte le API
aggiornate e molto spesso succede che gli aggiornamenti Android avvengano in maniera
più rapida rispetto allo sviluppo dei firmware da parte delle case produttrici. Per quanto
riguarda le applicazioni, per esse è prevista una compatibilità definita “in avanti”, cioè
saranno compatibili con il 100% dei dispositivi che montano il sistema operativo target
dell’applicazione, e con tutte le versioni future; mentre la compatibilità con i dispositivi
che montano versioni precedenti di Android non è garantita. Quindi una volta aggiornato il
sistema, tutte le applicazioni installate continuano a funzionare, mentre non è detto che un’
applicazione sviluppata per versioni più recenti sia supportata da tutti i terminali in
circolazione.
2.1.3. Sicurezza
Mettere al sicuro da codice o utilizzo malevolo una piattaforma aperta richiede un robusto
impianto di sicurezza; esso è stato progettato su più strati per garantire un elevato livello di
flessibilità. La sicurezza del sistema operativo si basa sull’affidabilità fornita dal kernel
Linux, nucleo della piattaforma Android. Questo tipo di kernel è utilizzato principalmente
in contesti sensibili alla sicurezza, diventando riferimento di molte aziende e professionisti
che operano su questa tematica. Android ne estende le caratteristiche, implementando un
sistema operativo che disciplina in maniera stringente le comunicazioni tra le applicazioni;
le risorse associate ad ogni applicazione sono isolate, come ad esempio i file, la memoria,
il tempo di CPU e i dispositivi utilizzati, come fotocamera o bluetooth. Per realizzare
questo, la piattaforma si basa su un sistema di autorizzazioni, un meccanismo di
isolamento dei processi e l’abilità di rimuovere durante l’esecuzione i programmi
40
potenzialmente insicuri. Di default, le applicazioni non possono interagire tra loro e hanno
accesso limitato al sistema operativo. Oltre agli strumenti di protezione offerti dal kernel,
che identifica e isola le risorse di un’applicazione, esiste un ulteriore livello di sicurezza:
tutte le applicazioni, incluse quelle native, cioè quelle sviluppate con il sistema operativo,
girano in una Sandbox. Ciò vuol dire che vengono eseguite in un contesto protetto, con
una parte dedicata del filesystem, in cui possono scrivere i dati privati. Poiché la Sandbox è
gestita dal sistema operativo, tutti gli strati software oltre il kernel, vengono eseguiti
all'interno di questo contesto. Questo meccanismo rende il sistema intrinsecamente sicuro,
ma la filosofia di Google, che consiste nel dare massima autonomia all’utente rispetto alle
personalizzazioni sul dispositivo, impatta sulla sicurezza. Infatti il sistema espone
all’utente in maniera esplicita quali sono gli intenti delle applicazioni al momento
dell’installazione e l’utente ha la possibilità di accettare o meno le richieste relative alle
risorse che verranno utilizzate a tempo di esecuzione. In questo modo si presuppone che
l’utente sia perfettamente consapevole delle operazioni autorizzate, cosa non sempre vera
per tutte le tipologie di utilizzatori. Oltre a questa criticità ci sono fattori legati alla
distrazione e alla non sufficiente esperienza. Molte applicazioni possono provenire anche
da canali non ufficiali solitamente terreno fertile di software malevoli. Una delle cause dei
problemi di sicurezza di Android consiste proprio nell’esistenza di questi market non
controllati, anche se molti malware provengono proprio dal Google Play Store; infatti si è
manifestata la difficoltà nell’automatizzare i processi di verifica delle applicazioni. A
queste motivazioni si affianca anche il fatto che Android è open-source, ciò permette di
conoscere nel dettaglio la struttura interna del sistema operativo e delle eventuali falle e
ciò rende più semplice per gli aggressori mascherare le applicazioni. Altri fattori sono la
facilità con cui si può accedere al developer account del Market, per il basso costo di
iscrizione e i pochi controlli. Infine l’assenza di meccanismi pre-installati per la sicurezza
rende opportuna l’istallazione di software antivirus, ma ciò è completamente a discrezione
dell’utente.
2.1.3.1.
Problemi legati alla sicurezza
Nonostante la robustezza della piattaforma, nel corso del 2011 Android è risultato uno tra i
41
sistemi operativi mobile meno sicuri, sollevando diverse critiche sulle sue difese e sui
sistemi di prevenzione attuati. Il report trimestrale della Intel McAfee relativo al primo
trimestre 2012 mostra che l'interesse criminale nella piattaforma mobile ha subito un
significativo incremento e che circa l’87% sulla totalità dei malware mobile registrati nei
database erano relativi al sistema operativo Android. In particolare per questa piattaforma
si è assistito a un incremento del 1.650% di software nocivi presenti nei database,
passando da 400 malware memorizzati nel quarto trimestre 2011 a circa 7.000 nel primo
del 2012. Nel secondo trimestre del 2012 la piattaforma Android ha coperto la quasi la
totalità dei malware mobile rilevati e continua a registrare una forte crescita come si può
vedere in Figura 23.
Figura 23: Malware Android rilevati (andamento 2011/2012)
Tra i malware maggiormente diffusi troviamo quelli provenienti da mercati terzi, anche se
non mancano quelli provenienti dal mercato Android ufficiale. MacAfee tra le tipologie di
malware più diffuse menziona principalmente quelle legate all'adware mobile, che
consiste in finestre pubblicitarie che appaiono durante l’esecuzione di un programma.
Questo tipo di pubblicità, usata legalmente per sostenere i costi di giochi o applicazioni,
viene utilizzata in false versioni di applicazioni popolari normalmente a pagamento, che
vengono offerte gratuitamente con lo scopo di ingannare l’utente. Queste applicazioni,
spesso illegali, contengono questo tipo di advertising al loro interno al fine di dirottare gli
utenti su link a pagamento o pubblicitari. In questo modo non si riduce necessariamente la
42
sicurezza degli utenti, ma li si espone a messaggi aggressivi che possono essere veicolo di
ulteriori problemi. Un’altra tipologia di malware segnalati dalla società McAfee sono i
trojan backdoor, cioè applicazioni che utilizzano una escalation di privilegi per installare
ulteriori applicazioni dannose sul dispositivo o inviare messaggi a tariffa maggiorata. Tra i
trojan più pericolosi vengono menzionati quelli che riescono a ottenere i privilegi per
manipolare il sistema, alcuni esempi sono malware che saturano la memoria ROM del
dispositivo, che inviano informazioni personali ad un server centrale e che addirittura
istaurano delle vere e proprie botnet, cioè fanno si che il terminale sia controllato da
remoto da un’altra entità attraverso la rete. Nel secondo trimestre del 2012 sono stati
individuati dei pacchetti che hanno l’apparenza di aggiornamenti di sistema per i
dispositivi Android, scaricabili da siti di terze parti, ma che contengono software nocivo e
nuovi malware che sfruttano account di social network fittizi per controllare il dispositivo
infettato. Durante il rilascio di una nuova versione del proprio antivirus, anche la società
Sophos Mobile Security ha effettuato uno studio sui malware più diffusi sulla piattaforma
Android confermando la tendenza che vede tra i primi quelli che imitano applicazioni a
pagamento, con il 63,4% di presenze nel totale dei campioni rilevati, seguiti dai vari tipi di
trojan più o meno pericolosi. TrendMicro, azienda giapponese impegnata nello sviluppo di
software anti malware, segnala che sono sempre di più le applicazioni presenti nel Play
Store contenenti codice malevolo che potrebbe danneggiare la sicurezza del dispositivo e
quindi degli utenti che lo utilizzano. Secondo la casa del noto antivirus lo store di Google
sarebbe passato in soli sei mesi ad ospitare dalle 5.000 applicazioni potenzialmente
pericolose nel primo trimestre del 2012 alle 20.000 nel secondo trimestre del 2012. In
particolare sono stati individuati 17 software malevoli scaricati oltre 700.000 volte prima
di essere rimossi dal market ufficiale. Attualmente Google sta cercando di arginare il
fenomeno, incrementando i controlli e istituendo regolamentazioni più rigide per chi
pubblica la propria applicazione nel Google Play Store. Inoltre nel febbraio 2012 è stato
annunciata l'introduzione di Bouncer, un nuovo strumento per rendere più sicuro il market.
Il tool effettua una scansione dettagliata delle applicazioni per rilevarne malware, spyware
o trojan nascosti. Questo ulteriore livello di sicurezza è stato oggetto di analisi da parte
43
della Trustwave's SpiderLabs che ha presentato lo studio alla Black Hat information
security conference di Las Vegas. La società ha rilevato che la soglia tolleranza di
Bouncer è molto alta, costatando come il sistema sia facilmente aggirabile e come sia
possibile superare la barriera di controlli facendo penetrare comunque software malevolo.
Android 4.1 Jelly Bean, l’ultima versione di Android, presenta passi avanti sulla sicurezza
migliorando il sistema di crittografia. Si è introdotto il supporto per la tecnologia ASLR
(Address Space Layout Randomization), che rende casuale la memorizzazione delle
strutture dati in Android. Questa casualità elimina delle vulnerabilità, rendendo più
difficile l’accesso agli hackers, in quanto risulta più ostico insediare codici malevoli, visto
che non si può prevedere dove verranno memorizzati i dati. Tuttavia risulta indispensabile
per gli utenti prestare particolare attenzione alle misure di sicurezza consigliate, come
l’istallazione e l’aggiornamento di software di protezione antivirus, l’effettuare le security
patch e il consentire i download solo da fonti attendibili.
2.2. Windows 8
Windows 8, il nuovo sistema operativo di Microsoft è stato presentato al pubblico il 26
Ottobre 2012. Tale sistema supporta sia pc desktop che tablet; esso inoltre si integra con la
versione sviluppata per smartphone, in modo da abbracciare in un unico ecosistema tre
diverse piattaforme. Esso è disponibile in quattro edizioni: Windows 8, Windows 8 Pro,
Windows 8 Enterprise e Windows RT,quest’ultimo sviluppato per supportare i processori
ARM (Advanced RISC Machine). L’edizione di Windows Phone 8, nome in codice
Apollo, sarà riservata unicamente agli smartphone. Microsoft con questo nuovo sistema
operativo vuole intraprende la sfida di unificare l’esperienza utente per ogni tipologia di
dispositivo. Infatti, una delle novità più rilevanti è l’adozione dell’interfaccia Metro,
prerogativa fino a questo momento solo degli smarthphone con Windows Phone. che viene
adesso estesa agli altri dispostivi L’interfaccia è composta di live tiles, icone simili a
mattonelle che, oltre a eseguire un'applicazione con un clic o un tocco su di esse,
visualizzano al loro interno dati aggiornati in tempo reale, senza dover necessariamente
avviare l'applicazione. Le tiles possono essere personalizzate e ridimensionate per
caratterizzare la schermata rispetto alle esigenze dell’utente. Oltre alla grafica, Windows 8
44
e Windows Phone condividono lo Store, negozio virtuale per l’acquisto/download di
software compatibili, una piattaforma per lo scambio di messaggi tra utenti Windows, il
servizio SkyDrive, per memorizzare e sincronizzare file su cloud e
altre features
introdotte che permettono una maggiore integrazione ed interoperabilità tra piattaforma
desktop e mobile.
Windows è stato sviluppato per essere utilizzato su diversi tipi di architetture hardware;
diffuso su processori Intel e AMD (Advanced Micro Devices), tramite la versione 8
verranno supportati anche processori ARM, microprocessori diffusi nei dispositivi portatili
come tablet e smartphone, che permettono di ottimizzare l’uso della batteria
consentendone il risparmio energetico. Della nuova versione Windows 8, l’interfaccia
Metro costituisce l’aspetto più innovativo, perché cambia il modo con cui gli utenti
possono interagire col sistema, indipendentemente dal dispositivo. Viene supportata sia
l’interazione touchscreen che quella desktop con mouse e tastiera, mentre il classico menù
Start viene eliminato e sostituito dalla schermata Start. Quest’ultima è accessibile tramite
la nuova barra dei menù detta Charms che appare negli angoli dello schermo da qualunque
applicazione aperta in Windows. La barra Charms contiene una griglia scorrevole di tiles
che consentono di accedere alle applicazioni in stile Metro o ritornare al desktop
tradizionale dove vengono eseguite le applicazioni legacy, cioè sviluppate secondo
l’approccio già esistente su Windows. Nella schermata Start, inoltre, si possono
visualizzare tutte le applicazioni installate, sia Metro che classiche. Il passaggio tra
ambiente desktop e mobile è consentito solamente nei dispositivi che non dispongono dei
processori ARM, cioè i processori X86. Questa differenza è dovuta al fatto che con lo
sviluppo di Windows 8, si è creato un nuovo sistema operativo, Windows RT, più snello e
capace di supportare i device arm-based. Nei dispositivi in cui è presente Windows RT,
l’ambiente desktop non è presente e le applicazioni che vengono eseguite sono create
appositamente per l’architettura sottostante. Nei dispositivi con processore X86 come
desktop, laptop e tablet ibridi, ossia tablet con processore X86 che montano il sistema
operativo Windows 8 che permettono un utilizzo sia in mobilità che da desktop, per
45
ottenere l’integrazione tra i 2 ambienti, sia nell’interfaccia utente che nel tipo di
applicazioni che possono essere eseguite, si ricorre a un runtime denominato WinRT, da
non confondere con il sistema operativo Windows Rt. Questo strato software di
interfacciamento permette di eseguire applicazioni Metro su dispositivi X86. In Figura 24
è mostrata l’architettura software del sistema operativo Windows 8 per device X86:
Figura 24: Architettura software Windows 8 su device X86
Microsoft ha voluto creare questo nuovo sistema operativo per supportare i tablet e
inserirsi nel mercato in competizione con Google e Apple. Anche se ci sono tablet con
processori X86, come ad esempio il Samsung Slate 7, l’obiettivo di Microsoft con
Windows RT è supportare i device ARM con un sistema operativo mobile, come Android
e IOS, che riesca però a supportare l’utente con strumenti di lavoro peculiari di Windows,
come Office. Per questo pacchetto di software è stata rilasciata una versione per Windows
RT. Le applicazioni Metro che vengono eseguite sia su Windows RT che Windows 8
grazie alle api del runtime WinRT, a differenza delle applicazioni classiche eseguite
nell’ambiente desktop hanno per default un'unica finestra senza riquadri e barre degli
strumenti che riempiono lo schermo. Questo stile di user experience, detto immersive,
supporta diverse origini di input, come tocco, penna e mouse e tastiera; esso usa riquadri al
posto delle icone e include nuovi tipi di barre degli strumenti e di opzioni delle
applicazioni. Questa scelta grafica viene riprodotta in tutte le applicazioni Metro e nella
46
stessa interfaccia utente del sistema operativo. Le applicazioni Metro possono inoltre
condividere in maniera semplice i dati attraverso un nuovo protocollo di comunicazione
basato su un modello di contratti fra applicazioni che, oltre a facilitare lo scambio di
informazioni, inserisce un ulteriore livello di sicurezza da rispettare. I contratti fra le
applicazioni sono un nuovo strumento introdotto da Microsoft che semplifica e rende più
efficace la comunicazione fra le applicazioni in stile Metro. Esistono diversi tipi di
contratti per realizzare scenari di condivisione anche ampi e complessi fra due
applicazioni che abbiano implementato lo stesso contratto. Ad esempio i contratti di
condivisione consentono di scambiare dati e file in formati diversi e personalizzabili senza
conoscere nulla dell’applicazione di destinazione, i contratti di tipo ricerca consentono agli
utenti di eseguire ricerche nei contenuti di un'applicazione da qualsiasi posizione in
Windows e di visualizzarli all’interno dell’applicazione stessa. I contratti “selettore file”
permettono agli utenti di accedere al contenuto di un'applicazione da un'altra in
esecuzione, ciò consente ad esempio di sfogliare la galleria dei media all’interno di
un’altra applicazione. Le applicazioni Metro sono implementabili scegliendo tra più tipi di
linguaggi di programmazione supportati fra cui HTML5 e javascript, linguaggi
ampiamente utilizzati non solo nel mondo Microsoft ma anche in quello web e mobile. In
questo modo si incoraggiano gli sviluppatori a creare nuove applicazioni grazie all’utilizzo
di linguaggi web-based, permettendo a programmatori esperti in tecnologie web di poter
sviluppare applicazioni Metro riutilizzando quindi le loro conoscenze in un ambito
diverso.
Come riportato il sito dedicato a Windows 8 Release Preview, il sistema funziona con lo
stesso hardware su cui è possibile eseguire Windows 7, cioè necessita di un processore di
almeno un gigahertz (GHz), ram di 1 GB (32 bit) o 2 GB (64 bit),disco rigido di 16 GB
(32 bit) o 20 GB (64 bit) e scheda grafica Microsoft DirectX 9 con driver WDDM
(Windows Display Driver Model). Inoltre bisogna avere un tablet o un monitor che
supporta il multitouch per poter utilizzare le funzionalità touchscreen, una risoluzione
dello schermo di almeno 1024 x 768 pixel per eseguire le applicazione in stile metro e
47
accedere al Windows Store e per utilizzare la funzione di ancoraggio fra le app occorre
una risoluzione dello schermo di almeno 1366 x 768 pixel. Il sito riporta anche che la
compatibilità con le applicazioni istallate nelle precedenti versioni desktop di windows
dovrebbe essere garantita mentre le applicazioni Metro non sono retrocompatibili, cioè
possono essere eseguite solo da Windows 8. Sui processori ARM, l'edizione RT di
Windows 8 non supporta l'esecuzione, l'emulazione o la portabilità delle esistenti
applicazioni desktop x86/x64.
2.2.3. Sicurezza
Per quanto riguarda la sicurezza, con Windows 8 si introducono importanti novità. Ad
esempio con la nuova versione di Windows Defender, che era stato inizialmente creato per
proteggere il sistema Windows dagli spyware, si aggiungeranno anche funzionalità
antivirus. Gli spyware a differenza dei virus, che comprendono tutti i malware installabili
su un dispositivo, sono programmi creati esclusivamente per monitorare l’attività on-line
degli utenti e trasmettere le informazioni a una organizzazione che le utilizzerà per trarne
profitto senza consenso. Il programma, quindi, oltre a rilevare gli spyware, verificherà
anche la presenza di virus, monitorando lo stato dei software di protezione esistente e
intervenendo in caso di pericolo di sicurezza. Un'altra novità importante è Windows To
Go, una nuova funzionalità esclusiva dell'edizione Enterprise di Windows 8 che consente
di effettuare l'avvio del sistema operativo da dispositivi di memorizzazione di massa USB,
come unità flash e dischi fissi esterni, contenenti Windows 8, i programmi, le impostazioni
e i file dell'utente. Windows To Go è rivolto alle imprese: è infatti stato progettato per
consentire agli amministratori di fornire agli utenti una versione di Windows 8 su
immagine che rifletta il desktop aziendale, permettendo al personale contingente di
accedere all'infrastruttura informatica solo attraverso le impostazioni presenti nel
dispositivo di memorizzazione di massa e quindi diminuendo l’esposizione del sistema a
rischi di sicurezza. Secure Boot è una nuova funzione che i produttori di schede madri
dovranno integrare nei propri prodotti che montano Windows 8. Il suo funzionamento
consiste nell’impedire l’avvio di software non autorizzato, sia esso un malware che un
sistema operativo non certificato. Lo SmartScreen Filter è una ulteriore protezione per gli
48
utenti che consiste in un filtro per applicazioni non certificate, programmi malevoli o link
che portano a siti di phishing. Il filtro lavora con dei valori hash che il programma crea nel
filesystem locale per identificare le applicazioni. Questi valori vengono inviati a Microsoft
per controllare tramite un database che siano sicuri. E’ stato introdotto, inoltre, anche un
sistema di sandboxing, che permette di isolate tra di loro e dallo stesso Windows 8 tutte le
applicazioni Metro incrementandone la sicurezza. Le applicazioni Metro si possono
reperire dallo Store di Windows, concepito per contenere nel futuro tutte le applicazioni
ufficiali targate Microsoft. La procedura di pubblicazione di una applicazione per
Windows 8 consiste in una serie di passaggi per ottenere l’account da sviluppatore e la
certificazione da parte di Microsoft, ciò per garantire massima sicurezza e standard
qualitativi elevati. La compatibilità con le applicazioni desktop tradizionli però non
garantisce che i dispositivi non vengano infettati da malware progettati per le versioni
precedenti di Windows. Non esiste portabilità dei virus, invece, sui dispositivi ARM che
non consentono l’esecuzione delle applicazioni tradizionali su Windows 8.
2.3. IOS
IOS è un sistema operativo che supporta principalmente dispositivi mobile come
tablet,smartphone e lettori multimediali; è sviluppato e distribuito dalla Apple. La sua
prima versione è stata rilasciata sul mercato nel 2007. Il sistema operativo è progettato e
realizzato per supportare solo dispositivi prodotti dalla Apple, a differenza di altri sistemi
operativi come Windows 8, Windows RT e Android, quindi non è possibile l’installazione
su altri dispositivi mobile realizzati da altri vendors. IOS è stato sviluppato a partire dall’
OS X, sistema operativo Unix-based prodotto sempre dalla Apple per i propri sistemi
desktop. Con esso IOS condivide alla base il core sviluppato dalla Apple nel 2000,
denominato Darwin, un sistema operativo open source costruito a partire dal kernel XNU.
Grazie allo sviluppo di questo sistema operativo, prima sugli smartphone e poi sui tablet, e
del modello di business e di sviluppo delle applicazioni native, che il mobile si è evoluto
nello stato
in cui si trova attualmente. Il paradigma app-oriented, ossia sviluppare
un’applicazione che deve soddisfare pochi requisiti specifici ma che sia interattiva e con
una avanzata user experience, è stato lanciato sul mercato dalla Apple con l’ecosistema
49
costituito dal sistema operativo, Itunes, software di gestione e riproduzione di contenuti
multimediali, e lo store dal quale scaricare le applicazioni. A settembre 2012 lo store
ufficiale di IOS conta più di 700000 applicazioni. L’utente interagisce con le applicazioni
e il sistema operativo attraverso gesti delle dita come swiping, tapping, e pinching, i quali
grazie allo schermo capacitivo multitouch e l’utilizzo di sensori come accelerometro e
giroscopio permettono un’interazione con la piattaforma interattiva,dinamica e adattabile a
diversi scenari di utilizzo, sia in ambito consumer che enterprise.
L’architettura software di IOS costruita sopra il core Darwin è strutturata in 4 abstraction
layer:
1- Core OS Layer: contiene le caratteristiche di basso livello sulle quali si poggiano le
altre tecnologie; attraverso l’utilizzo di una serie di frameworks, come ad esempio
Accelerate, Core Bluetooth, External Accessory, Generic Security Services, Security e
System, vengono offerti agli strati superiori una serie di servizi, che di rado però
vengono acceduti direttamente dagli sviluppatori di applicazioni.
2- Core Services Layer: contiene i servizi fondamentali di sistema che vengono utilizzati
da tutte le applicazioni. Le tecnologie principali consistono in:
• Icloud Storage: introdotto in IOS 5, è un servizio che permette alle applicazioni di
creare dati e documenti in maniera ubiqua, cioè vengono salvati su una struttura
centralizzata e il loro accesso è consentito in maniera uniforme da tutti i dispositivi
Apple, sia desktop che mobile. Ciò permette agli utenti di poter vedere ed editare
dati senza utilizzare funzionalità di sincronizzazione o di trasferimento espliciti, e
di ottenere una copia remota dei dati in caso di perdita del dispositivo.
• Automatic Reference Counting: introdotto in IOS 5, è una features a livello di
compilazione che semplifica il processo della gestione del ciclo di vita degli
oggetti del linguaggio nativo Objective-C.
• Data Protection: introdotto in IOS 4, è un servizio che permette alle applicazioni di
lavorare con dati sensibili degli utenti sfruttando tecnologie di criptazione presenti
di determinati dispostivi. Una volta che un file è definito protetto viene salvato dal
50
sistema in un formato criptato. Se il dispositivo è bloccato il contenuto del file è
inaccessibile sia all’applicazione che lo ha creato sia ad eventuali intrusi. Viene
rilasciata una chiave per decriptare il file all’applicazione quando il dispositivo
viene sbloccato dall’utente.
• Grand Central Dispatch: introdotto in IOS 4, è una tecnologia a livello di sistema
operativo che permette di eseguire task all’interno di un’applicazione. Esso utilizza
una combinazione di features core con un modello di programmazione asincrono
per ottenere un’alternativa conveniente ed efficiente all’utilizzo dei thread.
• SQLite: è una libreria che permette l’utilizzo di un database leggero ed incluso
all’interno delle applicazioni senza dover ricorrere ad un processo server esterno.
3- Media Layer: questo livello contiene tecnologie per manipolare grafica, audio e video.
Il loro scopo è fornire servizi per permettere di sviluppare applicazioni ricche dal
punto di vista multimediale in maniera semplice.
4- Coca Touch Layer: questo livello contiene i frameworks fondamentali per costruire le
applicazioni IOS. Esso definisce l’infrastruttura base e fornisce il supporto per le
tecnologie chiave come multitasking, touch-based input, push notification, gesture
recognizers, peer-to-peer services,ed altri servizi di alto livello
Una delle features più importanti introdotte dalla versione 4 del sistema operativo è il
multitasking. Esso prima della versione 4 era limitato a un ristretto numero di applicazioni
già incluse al rilascio del sistema operativo. Il suo utilizzo è permesso tramite 7 API che
vengono utilizzate in backgound:
1 Background Audio: Un’applicazione che sta eseguendo contenuti audio o video può
continuare l’esecuzione dei contenuti multimediali in background
2 Voice over IP: Un’applicazione Voip può essere sospesa e viene associata ad un
servizio che monitora la socket, in modo che quando arriva una chiamata
l’applicazione viene ripristinata come attiva.
3 Background location: attraverso servizi che vengono eseguiti in background viene
monitorata la posizione dell’utente, utilizzata dalle applicazioni attive.
4 Push notifications: tecnologia che utilizza una connessione IP costantemente aperta per
51
inviare notifiche dal server al client in modo asincrono, senza utilizzare il polling dal
client
5 Local notifications: le applicazioni possono programmare notifiche locali in momenti
predeterminati
6 Task completion: l’applicazione può richiedere al sistema tempo extra per completare
un determinato task
7 Fast app switching: Un’applicazione che non esegue codice può essere rimossa dalla
memoria centrale in qualsiasi momento
Nella versione 5 di IOS sono state introdotte altre 3 API aggiuntive:
8 Newsstand: Le applicazioni possono scaricare dati dalla rete in background
9 External Accessory: ad intervalli regolari le applicazioni possono comunicare con
accessori esterni per scambiare dati
10 Bluetooth Accessory: ad intervalli regolari le applicazioni possono comunicare con
accessori Bluetooth per scambiare dati
La versione attuale di IOS è la sesta, lanciata sul mercato il 12 settembre 2012. Non tutti i
dispositivi hardware possono essere aggiornati da una versione alla successiva del sistema
operativo. IOS supporta diversi tipi di dispositivi i quali sono denominati IDevices. Essi
includono l’IPhone, unico dispositivo smartphone che viene supportato da IOS, IPod
Touch, simile all’IPhone ma senza modulo hardware per effettuare le chiamate, ed infine
l’IPAD tablet. Gli aggiornamenti alle versioni successive del sistema operativo avvengono
tramite ITunes, ed a partire dalla versione 5 attraverso firmware-over-the-air, cioè
attraverso la rete cellulare oppure Wifi. I passaggi da una versione alla successiva del
sistema operativo tendono ad essere rilasciate una volta l’anno. Gli aggiornamenti dei
device hardware avvengono periodicamente, lanciando sul mercato una nuova versione del
dispositivo con migliorie hardware, sia a livello di componentistica che di features.
Esistono 6 generazioni di IPhone, 5 di IPod Touch e 4 di IPad; a quest’ultimo
recentemente è stata affiancata una versione ridotta da 8 pollici. L’ultima versione di IOS
supporta diversi tipi di device, come IPhone 3GS, IPhone 4, 4s, IPad 2, 3 e IPod Touch 4.
52
Il livello di features supportate però non è omogeneo, e per poter utilizzare le ultime
caratteristiche introdotte da IOS 6, come Siri, FaceTime over 3g ed altre occorre avere le
ultime versioni hardware dei dispositivi. Questo continuo aggiornamento nella
caratteristiche sia hardware che software delle piattaforme Apple, porta ad avere problemi
di retro compatibilità delle applicazioni, le quali non garantiscono che se un’applicazione
viene sviluppata su una versione del sistema operativo possa essere eseguita su una
versione precedente. Gli sviluppatori quando sviluppano un’applicazioni possono scegliere
il sistema operativo target, ed utilizzare le api di quella versione.
2.3.3. Sicurezza
Come riportato dall’articolo prodotto dalla Symantec del 2011 A Window into mobile
device security, IOS basa la sua sicurezza su 5 livelli distinti:
1- Traditional Access Control: controllo dell’accesso basato su password per accedere al
sistema.
2- Application Provenance: è un approccio in cui un’applicazione viene associata
all’identità dell’autore attraverso una firma digitale. Gli sviluppatori di applicazioni
per device Apple, sia consumer che enterprise, devono registrarsi e pagare un
abbonamento annuale. In seguito alle applicazioni viene applicata la firma, e prima di
venir distribuita sullo store ufficiale o attraverso canali interni per le applicazioni
enterprise, viene effettuato un processo di certificazione. Per le applicazioni aziendali
orientate alla forza lavoro delle aziende, viene aggiunta una ulteriore misura di
sicurezza, un certificato specifico che viene installato sul dispositivo e senza il quale
l’applicazione non può funzionare. Se il certificato viene rimosso o scade
l’applicazione non può più funzionare.
3- Encryption: salvataggio dei dati in maniera criptata in modo da prevenire perdita di
dati dovuti a smarrimenti o furti del device. È utilizzato un sistema ibrido di
criptazione; viene prima utilizzata un sistema hardware AES-256 per criptare tutti i
dati salvati sulla memoria flash del device. Poi i dati più sensibili come email e dati
personali vengono criptati da un livello aggiuntivo.
4- Isolation: le applicazioni vengono limitate nell’accesso a dati sensibili o funzionalità di
53
sistema sul dispositivo. Le applicazioni sono isolate, non possono modificare
dati,logica,ecc… di altre applicazioni. Un’applicazione non può avere accesso al
kernel del sistema operativo e non può ottenere il root-level del dispositivo.
5- Permissions-based access control: Ogni applicazione deve esplicitamente dichiarare le
funzionalità e le risorse del sistema a cui vuole accedere e viene impossibilitata ad
allargare il proprio scope. Ogni volta che un’applicazione intende accedere a
determinate risorse di sistema viene richiesta l’esplicita approvazione dell’utente. Altre
invece vengono definite una volta e vengono accedute sempre.
54
Capitolo 3
Tecnologie a supporto per lo sviluppo multipiattaforma su
sistemi mobile tablet
Lo sviluppo multipiattaforma in ambito mobile consiste nella produzione di software
progettato per supportare dispositivi diversi sia per caratteristiche hardware che sistemi
operativi. Questo processo si avvale di tecnologie e strumenti specifici e consente di
scrivere programmi che si adattano automaticamente o con sforzo minimo al contesto in
cui vengono eseguiti. L’esigenza di riuscire a sviluppare un applicativo di questo tipo è
sentita particolarmente in ambito enterprise grazie ai potenziali vantaggi che si possono
avere in termini di riduzione dei tempi e costi per realizzare e mantenere il prodotto. Infatti
negli ultimi anni la rapida evoluzione dei dispositivi mobili e la frammentazione del
mercato mobile, sia per quanto riguarda sistemi operativi che tipologie di terminali con
caratteristiche differenti, ha portato alla crescita dei costi di sviluppo e di mantenimento
delle applicazioni mobile che devono supportare diverse piattaforme.
3.1. Caratteristiche dei framework di sviluppo ed esigenze aziendali
Le aziende che vogliono produrre un’applicazione di tipo business che possa supportare
diversi tipi di terminali mobili devono gestire la frammentazione del mercato mobile, sia
per dispositivi che per sistemi operativi. In questo momento le principali piattaforme sul
mercato sul quale è possibile sviluppare applicazioni mobile enterprise sono iOS, Android,
RIM, Windows Phone, Windows 8, Windows RT, Nokia. Questo comporta il dover creare
55
una strategia per poter pianificare il modo con cui approcciarsi al multipiattaforma, in base
alle esigenze aziendali, relative ai dispositivi da supportare e ai requisiti dell’applicazione,
in modo tale da contenere i costi di sviluppo e manutenzione . Infatti sviluppare e
mantenere codice multiplo per diverse piattaforme è diventato complicato e costoso. I
possibili approcci che possono essere adottati sono numerosi ed eterogenei,ognuno con
proprie peculiarità, e nessuno è finora diventato lo standard de facto nello sviluppo
multipiattaforma in ambito mobile. La maturazione della standardizzazione di HTML5 nei
prossimi anni permetterà di utilizzare questo insieme di tecnologie open source per lo
sviluppo web come punto di riferimento nella realizzazione di siti web e web application
avanzate. Con il termine HTML5 si indica un’evoluzione dello standard che fa parte della
famiglia delle tecnologie web aperte. Esso tramite un insieme di API (application
programming interface ) innovative ed un markup potenziato permette di creare
applicazioni sul web avanzate senza ricorrere a software di terze parti, usati tramite plugin nei browser (esempio Flash o JavaFx). L’innovazione che verrà portata riguarderà
l’aspetto grafico e l’ interazione con l’utente, al fine di ottenere una user experience ricca,
simile a quella fornita dalle applicazioni native. HTML5 potrà essere utilizzato anche nello
sviluppo multipiattaforma di applicazioni che risiedono interamente sui dispositivi mobile
e desktop. Questa possibilità è fornita dallo sviluppo di diverse specifiche innovative, che
permetteranno di utilizzare nuove features, come audio e video in maniera nativa, oppure
l’accesso ai sensori dei dispositivi mobile tramite Javascript. Nel mercato attuale dello
sviluppo multipiattaforma nel settore mobile sono stati realizzati vari tool di supporto allo
sviluppo, ognuno dei quali offre features adatte a determinati contesti ma non a tutti, e che
quindi devono essere analizzati per poter scegliere il framework che fornisce le
performance migliori, in base all’ esigenza dell’applicazione da realizzare e le specifiche
richieste aziendali.
Le caratteristiche che i diversi tool possono fornire sono:
56
1- Ambiente di sviluppo intergrato: poter seguire tutto il ciclo di sviluppo all’interno
dello stesso ambiente di sviluppo, dalla scrittura del codice fino alla distribuzione
2- Componenti grafici per creazione dell’interfaccia utente: vengono messi a diposizione
una serie di widget e aiuti per costruire l’interfaccia dell’applicazione e la logica di
business connessa
3- Librerie aggiuntive: vengono messe a disposizione librerie aggiuntive tramite le quali
facilitare lo sviluppo di alcune funzionalità (esempio librerie per invio dati a web
service tramite chiamate AJAX)
Nello sviluppo di applicazioni multipiattaforma, è necessario analizzare i vari benefici
offerti dai determinati framework di sviluppo, per permettere all’azienda di indirizzarsi
verso uno in particolare che maggiormente si allinea con le indicazioni dei requisiti dell’
applicativo e le esigenze aziendali:
1- Numero di piattaforme da supportare: se un’azienda non avesse bisogno di raggiungere
il maggior numero di utenti e quindi si volesse focalizzare nello sviluppo di un numero
ristretto di piattaforme, potrebbe scegliere di sviluppare l’applicazione in maniera
nativa effettuando un successivo porting. In alternativa, qualora vi fosse l’esigenza di
rendere disponibile il software su più sistemi operativi si potrebbe sviluppare un sito
web mobile raggiungibile da tutte le piattaforme
2- Ciclo di vita del software: se un’azienda volesse sviluppare un software con un ciclo di
vita lungo, dovrà scegliere se gestire i costi di manutenzione in base al cambiamento
dei device e dei sistemi operativi, o voler creare un ambiente che permetta
l’adattabilità del software con poco effort
3- Costi di sviluppo: sviluppare codice nativo è più costoso di sviluppare codice in
ambiente web, e gli sviluppatori su tecnologie web sono più reperibili con un minor
costo degli sviluppatori specializzati su una piattaforma specifica, esempio Android;
ciò è dovuto al fatto che le tecnologie web sono mature e conosciute da diversi anni e
meno verticali rispetto alle tecnologie native utilizzate su un determinato sistema
57
operativo mobile. Queste ultime sono specializzate sul particolare ambiente di
sviluppo e sono state create soltanto nell’ arco degli ultimi 5 anni quindi persone
specializzate sono minori in numero.
4- User experience: rendere un’applicazione uguale per ogni piattaforma può essere
difficoltoso se si vogliono ottenere determinati scenari di interazione
5- Qualità dell’interfaccia utente: in base alla tecnologia di sviluppo si possono ottenere
interfacce utente più o meno avanzate con elementi grafici complessi, bisogna quindi
capire quanto l’interfaccia utente sia importante nell’applicazione
6- Accesso alle risorse dei device: l’accesso ai sensori dei dispositivi mobili e alle relative
interfacce per il loro utilizzo è dipendente dalla tecnologia che viene utilizzata nello
sviluppo delle applicazioni; ci sono casi in cui l’ accesso è bloccato, altri in cui è
parzialmente concesso e altri in cui si può accedere senza limitazioni alle features
offerte dai sensori e dal sistema operativo.
7- Performance: l’accesso alla capacità elaborativa del processore del dispositivo mobile
può essere più o meno efficiente in base alla tecnologia scelta; infatti ci sono
tecnologie che accedendo alle risorse del device in maniera nativa sono più
performanti in scenari complessi rispetto alle altre, ad esempio casi in cui le interfacce
grafiche son ricche di elementi. Ciò è dovuto al fatto che nelle tecnologie non native si
utilizzano strati software intermedi, ad esempio per creare gli elementi grafici avanzati,
o in fase di esecuzione devono interpretare il codice prodotto convertendolo in codice
nativo, e ciò fa calare sensibilmente le prestazioni dell’ applicazione.
Molte di queste esigenze sono in contrasto tra loro, e quindi non esiste al momento una
tecnologia che permetta una soluzione ottima che massimizzi i benefici di tutte le
componenti, ma esistono diverse soluzioni “sub-ottime” tra cui poter scegliere.
3.2. Approcci allo sviluppo multipiattaforma
Attualmente gli approcci che permettono di sviluppare un software multipiattaforma sono
58
diversi, ognuno con determinate caratteristiche a livello architetturale, prestazionale,
tipologia di processo di sviluppo adottato, strumenti a disposizione per la realizzazione e
livello di usabilità raggiungibile.
I tipi di applicazione attualmente esistenti nello sviluppo mobile possono essere
categorizzati in 5 insiemi:
Applicazioni native: sono realizzate per una specifica piattaforma con un SDK, software
development kit, ossia un framework di sviluppo con un IDE (ambiente di sviluppo )
integrato e strumenti per debugging ed emulazione.
Applicazioni web mobile: sono applicazioni server-side, costruite con una qualsiasi
tecnologia lato server per la logica di business (PHP, ASP.NET, ecc..) e per creare la
pagina di cui viene eseguito il rendering lato client sul browser. Queste applicazioni
possono fornire un aspetto più vicino a quello nativo tramite tool aggiuntivi (esempio
Jquery Mobile) che si fondono con le tecnologie web (HTML5, CSS, e JAVASCRIPT),
per visualizzare i contenuti e gestire la logica applicativa lato client. In questo tipo di
applicazioni possono esserci più contesti di utilizzo, in base alle tecnologie che possono
essere integrate nello sviluppo.
Applicazioni ibride: come le applicazioni native, vengono installate sul device e vengono
lanciate dal menu del sistema operativo, ma sono sviluppate con le tecnologie web in
aggiunta al codice nativo. Le applicazioni ibride girano in un contenitore nativo e vengono
eseguite come applicazioni native dal sistema operativo. Le pagine web che ne
costituiscono l’ interfaccia grafica sono renderizzate da un componente software,
denominato webkit, rendering engine che fornisce all’interfaccia anche i controlli del
browser, ma a differenza di quello fornito come applicazione nativa, questo viene eseguito
all’interno dell’applicazione ibrida. Lo scopo del web kit è interpretare e visualizzare a
video le pagine html e processare localmente il codice javascript. Uno strato software
intermedio che fa da bridge software permette di accedere tramite invocazioni di funzioni
javascript ai sensori del device, come ad esempio l’accelerometro o il giroscopio, e alle
funzionalità del sistema operativo altrimenti inaccessibili; questo accesso infatti al
momento è molto limitato per motivi di sicurezza nelle applicazioni web mobile che
59
utilizzano solo HTML5 e javascript, che possono accedere solo a un limitato numero di
sensori, ad esempio il GPS. Tramite l’ utilizzo del web kit e delle tecnologie html5 e
javascript è possibile eseguire lo stesso codice creato durante lo sviluppo su diversi sistemi
operativi, dovendo modificare solo il contenitore. Ciò consiste nel produrre l’applicazione
nativa eseguibile che conterrà le pagine html e il codice javascript, e sviluppare ad-hoc il
software intermedio tra javascript e le funzioni native del sistema operativo o adottarne
uno già sviluppato da terze parti.
Custom Container: con queste tecnologie si possono creare applicazioni tramite un
linguaggio proprietario e inserirle in un contenitore customizzato che viene eseguito nel
dispositivo. Il codice prodotto deve essere interpretato a tempo di esecuzione, e
l’interprete che si occupa di farlo può essere inserito nel contenitore o essere installato a
parte sul dispositivo. Nel secondo caso per far funzionare l’applicazione è richiesta
l’installazione dell’interprete. In entrambe le casistiche l’interprete a tempo di esecuzione
si occupa di convertire il linguaggio dell’applicazione in quello della piattaforma
sottostante
Cross-Compilation: con queste tecnologie si producono applicazioni trasformando il
codice scritto con un linguaggio di programmazione di origine proprietario in codice
nativo per le piattaforme di riferimento che sono supportate. Attraverso l’uso di funzioni
sviluppate ad-hoc da richiamare viene mappato il linguaggio di origine nel linguaggio di
destinazione per la specifica piattaforma per la quale creare il codice nativo equivalente
che fornisce le funzionalità richieste.
Oltre a questo insieme di tecnologie di sviluppo sono presenti sul mercato diverse
soluzioni che permettono lo sviluppo e la gestione di applicazioni mobile di tipo business
attraverso una piattaforma integrata, che fornisce una serie di servizi aggiuntivi a
pagamento. Questo tipo di soluzioni vengono denominate MEAP (mobile enterprise
application platform ).
Alcune delle caratteristiche più importanti sono:
1- Prevedono la presenza nella piattaforma di un server che fornisce funzionalità di
60
aggiornamenti OTA (over the air) e di memorizzazione dei dati privati delle
applicazioni mobile ad esso connesse
2- Forniscono funzionalità di gestione e monitoraggio dei dispositivi
3- Forniscono funzionalità di connessione con sistemi di back-end, per facilitare l’accesso
ai dati di CRM, ERP e altri tipi
4- I vendors forniscono spesso applicazioni preconfezionate che si interfacciano con
soluzioni software enterprise note, esempio SAP ERP o Oracle Financials
5- Forniscono meccanismi di sincronizzazione tra i dispositivi mobile e i sistemi di backend
Il motivo principale della presenza di tante tecnologie e della frammentazione del mercato
per lo sviluppo multipiattaforma è rappresentato dall’attesa da parte delle aziende della
standardizzazione di HTML 5. Infatti, esso ha lo scopo principale di unificare e di
standardizzare tutte le tecnologie web-oriented, permettendo inoltre l’utilizzo delle risorse
hardware dei device attraverso invocazioni dirette, non passando attraverso bridge o
soluzioni alternative create ad-hoc. Il processo di standardizzazione è ancora in corso e la
data definita per la fine dei lavori dal W3C (World Wide Web Consortium), consorzio a
cui compete la standardizzazione di tecnologie in ambito web, è genericamente fissata per
il 2014. Le aziende leader del mercato web, come ad esempio Google, Facebook ed
Adobe, nell’attesa hanno virato verso lo sviluppo multipiattaforma acquisendo aziende (ad
esempio Adobe ha acquisito Nitobi) oppure utilizzando tool esistenti (ad esempio
Facebook ha utilizzato per una release della propria applicazione mobile una versione
modificata di Apache Cordova, engine per costruire applicazioni multipiattaforma).
3.3. Analisi tecnologie per lo sviluppo multipiattaforma
Per sviluppare applicazioni multipiattaforma è possibile percorrere più strade, ognuna con
caratteristiche e strumenti peculiari, che permettono di massimizzare determinati fattori a
61
discapito di altri, e che quindi devono essere analizzate per poter scegliere l’approccio da
utilizzare in base alle caratteristiche richieste dall’applicativo e dalle esigenze aziendali.
3.3.1. Tecnologie di sviluppo native
Lo sviluppo di un’applicazione con tecnologia nativa produce un’applicazione per
dispositivi mobili che fornisce una o più funzionalità per uno specifico sistema operativo e
uno specifico firmware del dispositivo, quindi non può essere eseguita su un altro sistema
operativo. Per poter eseguire l’applicazione sviluppata per una piattaforma su un altro
sistema operativo è necessario effettuare un porting, ossia un nuovo sviluppo completo
dell’applicazione, partendo dai requisiti. Un’applicazione nativa è un’immagine binaria
eseguibile che viene installata sul dispositivo attraverso 2 modi: tramite l’accesso allo
store ufficiale o piattaforme proprietarie in ambiente enterprise, oppure attraverso le
tecnologie dei device, mobili o cablate, per trasferire dati (wifi, internet, usb, bluetooth,
IRDA). Il processo di sviluppo di un’applicazione nativa è molto simile per tutte le
piattaforme, come viene mostrato in Figura 25:
Figura 25: Processo di sviluppo con tecnologia nativa
Il processo di produzione dell’ applicativo parte scrivendo il codice sorgente, al quale
vengono aggiunti i riferimenti alle risorse da utilizzare (es. immagini). Il codice prodotto
tramite un ambiente di sviluppo integrato viene compilato e collegato alle librerie
62
utilizzate già esistenti, producendo in uscita il codice binario eseguibile, che viene inserito
in un package insieme alle risorse che devono essere accedute in locale dall’applicazione.
Il package viene distribuito in un formato installabile su una delle piattaforme di
distribuzione esistenti per il sistema operativo di riferimento. Tutti i sistemi operativi
principali utilizzano strumenti integrati di sviluppo, con i quali vengono realizzate, testate,
e distribuite le applicazioni:
IOS: sviluppo tramite Objective-C; il codice viene prodotto attraverso l’ ambiente di
sviluppo Xcode; in uscita dal packager viene creato un file “.app” da distribuire sull’apple
store.
Android: sviluppo codice tramite Java, C, C++,C# (gli ultimi tre linguaggi sono però
sconsigliati perché hanno bisogno di strumenti a pagamento);il codice viene prodotto
tramite l’ android sdk, intergrato interamente nell’ IDE eclipse tramite plug-in ad-hoc; in
uscita dal packager viene creato un file “.apk” che viene distribuito nel market android.
Blackberry: sviluppo codice tramite Java, il codice è prodotto tramite sdk blackberry,
integrato interamente in eclipse tramite pluging ad-hoc; in uscita dal packager viene
prodotto un file “.cod” distribuito nell’ application store.
Windows Phone: sviluppo codice tramite c#,c++, vb.net; il codice viene prodotto tramite
sdk integrato in visual studio; in uscita dal packager viene prodotto un file “.xap” da
distribuire nello windows phone market.
Windows 8: sviluppo codice tramite 2 approcci distinti: Html5,Css3, e Javascript per
creare applicazioni Metro Style, particolari tipi di applicazioni che differiscono da quelle
desktop principalmente per aspetto grafico (esempio ampio utilizzo delle Tiles , widget
grafici introdotti da Windows Phone ) e tipo d’interazione con l’ utente (perché sono
indirizzate verso il mondo mobile dei tablet); seconda possibilità tramite C#, Visual Basic
63
e XAML, o C++ e XAML (XAML è un linguaggio di markup basato su XML) per
sviluppo di applicativi Metro, o tramite gli stessi linguaggi senza l’ utilizzo di XAML per
applicativi desktop. In entrambi gli approcci si utilizza come ambiente di sviluppo Visual
Studio. Una volta lanciato sul mercato il nuovo sistema operativo windows e la
controparte mobile, lo store verrà unificato, in modo tale che ogni device Microsoft possa
accederci senza differenze.
Nonostante il processo di sviluppo sia uguale, i framework utilizzati nello sviluppo
producono codice ed eseguibili differenti, richiedendo conoscenze da parte degli
sviluppatori molto specializzate e verticali dell’ sdk di riferimento col quale sviluppano il
codice. Questo fattore comporta un aumento dei costi per effettuare porting
dell’applicazione e per gestire la manutenzione delle diverse versioni sui diversi sistemi
operativi.
I principali benefici dati dalla scelta di sviluppare l’applicazione in maniera nativa e
supportare il multipiattaforma tramite porting sono:
1- l’applicazione viene sviluppata utilizzando librerie proprietarie fornite dal sistema
operativo producendo un file eseguibile che non utilizza strati software intermedi per l’
esecuzione ottenendo prestazioni migliori in scenari complessi, soprattutto quando l’
interfaccia grafica è ricca di elementi interattivi.
2- l’utilizzo delle librerie proprietarie per avere l’accesso completo a tutti i sensori offerti
dal dispositivo, permette di creare applicazioni molto complesse e che si adattano a
scenari d’uso particolari ed avanzati, un esempio l’autenticazione tramite
riconoscimento della retina di un essere umano tramite la fotocamera del dispositivo.
3- accesso ai servizi offerti dalle applicazioni built-in, che vengono prodotte e fornite
insieme al sistema operativo, che possono fare da tramite con le API di basso livello
per un utilizzo più immediato di gruppi di funzionalità di base , esempio l’ accesso alla
lista dei contatti memorizzati sul dispositivo.
4- usabilità e user experience peculiari in base al sistema operativo di riferimento, cioè l’
interazione con l’ applicazione viene progettata anche in base alle scelte del sistema
64
operativo e del dispositivo, esempio il numero di tasti fisici presenti, unico per IOS e
variabili per dispositivi Android.
Un aspetto importante tra quelli citati è l’interazione dell’ applicazione con le risorse
hardware del device, cioè l’ insieme dei sensori messi a disposizione dello sviluppatore ,
che permettono di creare applicazioni smart, complesse e creative. L’ interazione con le
API del sistema operativo avviene direttamente, come mostrato in Figura 26:
Figura 26: Accesso ai sensori applicazioni native
L’ insieme della API offerti da ogni sistema operativo mobile sono schematizzabili a strati
(Figura 27):
65
Figura 27: Integrazione sistema operativo applicazioni native
Le applicazioni native possono quindi accedere alle risorse del sistema operativo e
hardware del device attraverso l’ invocazione di 2 tipologie di API:
API di basso livello per accedere a funzionalità base del sistema operativo , come
l’accesso e il controllo dei sensori, che permettono di realizzare funzionalità più specifiche
e che richiedono una maggiore scrittura di codice applicativo da parte degli sviluppatori
API di alto livello che permettono l’ accesso più immediato a funzionalità di maggiore
livello di astrazione, invocabili anche tramite richiesta ad applicazioni Built-in
3.3.2. Applicazioni Web mobile
Le applicazioni web mobile, sono una categoria di applicazioni client server che vengono
accedute tramite utilizzo di un applicativo browser. Vengono sviluppate principalmente
tramite tecnologie web, utilizzando quindi lato client html, css, javascript, mentre lato
server possono essere utilizzati diversi tipi di linguaggi di programmazione per fornire la
logica di business e accesso ai servizi e ai dati di back-end aziendali. Le combinazioni che
si possono ottenere tra tecnologie web e l’accesso alle risorse dei dispositivi mobile hanno
generato una serie di scenari di utilizzo:
•
Websites: sono portali web raggiungibili da tutti i tipi di device, sia mobile che
66
desktop; permettono l’ identificazione del tipo di dispositivo mediante informazioni
reperibili dal browser, e che adattano l’ interfaccia utente per migliorare la fruibilità in
base alle caratteristiche del device. Per permettere questo i portali hanno una versione
desktop e una mobile raggiungibili attraverso la medesima URL, o attraverso URL
diverse tramite reindirizzamento alla versione mobile del sito.
•
Web apps che interagiscono con applicazioni built-in: questi tipi di applicazioni
permettono di accedere a informazioni del device tramite l’ interazione con le
applicazioni Built-in per permettere una migliore interattività ; un esempio di scenario
d’ uso è l’ utilizzo dell’ applicazione Qrcode per poter essere indirizzati alla pagina
web di descrizione di un prodotto
•
Web apps con interfaccia grafica avanzata: sono applicazioni web mobile che
tendono ad avere un aspetto grafico e un’ interazione con l’ utente abbastanza vicina a
quella fornita dalle applicazioni native, permettendo di installare sul device il
collegamento al server in modo da sembrare come un’applicazione installata sul
device; un esempio di applicazione web è quella realizzata per YouTube
•
Web apps interamente scritte con html 5 e javascript: esse permettono l’ accesso ad
alcune features del sistema operativo tramite API, esempio uso di librerie grafiche per
disegnare o l’accesso a informazioni del gps per la geolocalizzazione, e possono essere
eseguite in modalità offline, cioè possono essere utilizzabili anche senza essere
connessi al server tramite la rete, attraverso l’uso di nuovi strumenti di caching e di
memorizzazione persistente forniti dalle nuove specifiche di HTML5.
3.3.2.1.
Uso di HTML5 nelle Enterprise web application
Il settore enterprise può beneficiare dell’evoluzione di HMTL e delle altre tecnologie web
per creare web application di tipo business che possano supportare diversi tipi di
dispositivi e sistemi operativi. In ambito enterprise le applicazioni che vengono accedute
in mobilità devono poter supportare sia dispositivi desktop che mobile. Questo comporta
un problema di portabilità del software dovuto al differente supporto di HTML5 dei
diversi tipi di browser che vengono utilizzati in ambito aziendale, che tra desktop e mobile
sono numerosi. Il principale collo di bottiglia fino al primo quadrimestre del 2009 è stato
67
Internet Explorer 6, leader del mercato in ambito desktop per il settore enterprise, che
forniva un supporto quasi nullo a HTML5 (http://netmarketshare.com).
Nei successivi anni grazie allo sviluppo di HTML5 guidato dalla forte ascesa dai
dispositivi mobile, smartphone e tablet, il supporto dei diversi tipi di browser desktop è
migliorato e allo stato attuale il gap tra quelli più compatibili con lo standard e quelli meno
si è assottigliato. In Figura 28 è mostrato il supporto dei browser a HTML5 relativo al
periodo precedente al lancio di Internet Explorer 9 redatto da Gartner.
Figura 28: Compatibilità browser HTML5 4Q2009
Per poter essere sicuri che la propria applicazione sia eseguita allo stesso modo sui diversi
tipi di browser è consigliabile scegliere prima i target di riferimento e verificare che le
funzionalità che si vogliono utilizzare siano supportate. Per reperire dati aggiornati sul
supporto dei vari tipi di browser, sia desktop che mobile, ad HTML5 ci sono diversi siti in
68
rete che riportano statistiche aggiornate, esempio:
• http://www.html5test.com/
• http://html5accessibility.com/
• http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)
• http://findmebyip.com/litmus
Nonostante al momento il mondo desktop e mobile possano essere visti come un unico
insieme di applicativi che accedono alle web application enterprise, considerazioni
riportate nelle le analisi di mercato e sul BYOD svolte nei capitoli precedenti permettono
di vederli separati e scegliere di dare maggiore attenzione ai dispositivi come smatphone e
tablet come target degli applicativi. In questo modo è possibile ottenere comportamenti
maggiormente uniformi dalle web application grazie al maggiore supporto dei device
mobili ad HTML5.
La scelta di sviluppare applicativi tramite HTML5 deve essere fatta conoscendo i punti di
forza e le limitazioni che al momento lo standard possiede. Tutte le caratteristiche che
HTML5 fornisce e che verranno aggiunte durante il processo di standardizzazione, hanno
lo scopo di aggiungere features al web; questo significa offrire nuovi elementi e API che
permettano agli sviluppatori di creare applicazioni con un’ esperienza interattiva e
avanzata indipendentemente dalla piattaforma su cui vengono eseguite. Nel contesto
desktop RIA ( Rich Internet Application ) plug-in per browser permettono di creare
applicazioni web avanzate, ma che non possono raggiungere il mondo mobile, perché non
installabili. Le maggiori features di HMTL5 che possono essere usate dagli sviluppatori
sono:
• Messaggi cross-document: possibilità di far comunicare pagine tra loro attraverso
domini diversi
• Canvas: possibilità di generare elementi grafici 2D e 3D attraverso Javascript
(possibile uso disegnare la propria firma in una pagina web)
• Audio: possibilità di effettuare lo streaming di contenuti audio dalle web application
• Video: possibilità di effettuare lo streaming di contenuti video dalle web application
69
• Drag and drop: possibilità di spostare graficamente elementi all’ interno di una
pagina (funziona ampiamente usata nelle applicazioni desktop)
• Applicazioni web offline: consente di effettuare la memorizzazione tramite caching
dell’ applicazione, potendo continuare ad utilizzare l’applicazione anche se la
connessione non è disponibile
• Eventi Server-Sent: possibilità di ricevere notifiche di tipo push dal server, evitando
di effettuare il polling lato client tramite javascript; questo permette un minore
ritardo all’arrivo di aggiornamenti e minore traffico scambiato in rete
• Web Storage: definisce il modo di salvare in modo persistente dati strutturati in
locale lato client
• Forms Avanzate: definizione di nuovi tipi di input per le form e meccanismi per
facilitare la validazione dei campi
• Web Workers: possibilità di eseguire script in background che vengono eseguiti in
isolamento dalla schermata principale
• Geolocalizzazione: definisce come ottenere informazioni sulla geolocalizzazione
dell’utente nella pagina web, attraverso diverse fonti come ad esempio indirizzo IP,
connessione alla rete wireless, cella a cui il dispositivo è connesso o attraverso il
sensore GPS del dispositivo
• Web Sockets: defisce il modo con cui creare un meccanismo di comunicazione
bidirezionale tra client e server
• CSS3: definisce nuove features a supporto del Cascading Style Sheet, tecnica
utilizzata per aggiungere stili alle pagine web
Il sito http://html5demos.com/ fornisce un insieme di showcase sulle potenzialità di
HTML5, che in base al browser utilizzato possono essere supportate o meno. Le
limitazioni di HTML5 con cui le aziende devono al momento confrontarsi nello sviluppo
di applicazioni web di tipo business per dispositivi mobile sono:
1- Performance: Molte delle funzionalità innovative introdotte da HTML5 possono creare
problemi di performance nelle web application, soprattutto quando vengono utilizzati
70
elementi grafici avanzati e streaming video
2- Tempi lunghi per completare la standardizzazione: Il W3C ( World Wide Web
Consortium) impiegherà ancora diversi anni per completare la standardizzazione (al
momento sul sito viene indicato 2014 come data di completamento) e durante questo
lasso di tempo HTML5 potrebbe subire modifiche nelle sue specifiche. Questo fattore
può portare i vendors dei browser a non adottare HTML5 totalmente come standard,
creando possibili problemi allo sviluppo multipiattaforma da gestire in fase di sviluppo
delle web application enterprise
3- Accesso ai sensori dei dispositivi mobile: nonostante HTML5 permetta una migliore
user experience delle applicazioni web attraverso le sue features innovative, al
momento attuale della standardizzazione esso non può accedere alla maggior parte
delle caratteristiche hardware dei dispositivi mobili, mentre le applicazioni mobile di
tipo nativo hanno un accesso totale a queste risorse
Ron Perry, CIO di Worklight, progetto della IBM per lo sviluppo di applicazioni
enterprise mobile, riporta su un articolo in rete che le tecnologie ibride sono un passaggio
fondamentale nel processo che porterà HTML5 a poter accedere alle risorse dei dispositivi
mobili. In Figura 29 è mostrato come avviene l’ interazione di un’applicazione web
mobile basata su HTML5 con il sistema operativo:
71
Figura 29: Accesso ai sensori HTML5 web application
Questo tipo di applicazioni sono eseguite all’ interno di un rendering engine, denominato
webkit, che costruisce la pagina web sullo schermo del device, e si occupa di comunicare
col sistema operativo attraverso delle chiamate API. Come si vede in figura molte delle
caratteristiche hardware del device sono inaccessibili , di colore rosso, altre sono
parzialmente accessibili, di colore rosa, e quelle verdi sono totalmente accessibili. Grazie
al lavoro del W3C in futuro HTML completerà la sua standardizzazione, e potrà accedere
attraverso le API alle risorse del device mobile, qualunque esso sia, diminuendo
ulteriormente il gap con le applicazioni mobile di tipo nativo.
3.3.3. Applicazioni ibride
Definire ibrido un oggetto, vuol dire crearlo attraverso la fusione di risorse eterogenee o di
diverso tipo. Nel caso di applicazioni mobile ibride avviene la fusione tra tecnologie web e
tecnologie native del sistema operativo. Un’applicazione ibrida è realizzata attraverso lo
sviluppo di codice tramite tecnologie web, usate nei siti web e nelle loro implementazioni
mobile, che viene incapsulato all’interno di un container nativo sul device mobile. Quindi
è una fusione di tecnologie web e ambiente di esecuzione nativo. Le applicazioni ibride
72
sfruttano la capacità da parte dei dispositivi mobile di poter renderizzare a video contenuti
prodotti con le tecnologie Web.
Attraverso una webview control (componente software supportato dalla maggior parte dei
dispositivi mobili) vengono integrati contenuti Web all’interno delle applicazioni native.
L’interfaccia utente costruita con HTML viene mostrata a pieno schermo, usando per la
sua visualizzazione un rendering engine browser denominato WEBKIT.
Esso è utilizzato in tutti i sistemi operativi mobile, eccetto Windows phone 7 e la futura
versione di Windows che continuerà ad utilizzare l’engine Trident. Il codice HTML e
javascript vengono eseguiti all’interno di un involucro nativo. La caratteristica principale
delle applicazioni ibride è l’accesso alle risorse hardware del device mobile attraverso uno
strato software che si occupa di fare da bridge software tra le API javascript e le API
native che governano i vari sensori.
Questa caratteristica non è consentita alle applicazioni web mobile a causa di limitazioni
basate sulla sicurezza che possono essere superate solo grazie alla standardizzazione di
HTML5. Lo strato software può essere realizzato ad-hoc per ogni sistema operativo,ma
esistono attualmente tool che realizzano lo strato per diversi sistemi operativi, permettendo
di sviluppare l’applicazione in html ed eseguirla come applicazione nativa per diverse
piattaforme. In Figura 30 viene mostrato come avviene l’interazione tra applicazione
ibrida e le risorse del device sfruttando lo strato software che fa da ponte, che permette
l’accesso ad un insieme di features messe a disposizione dal sistema operativo:
73
Figura 30: Accesso ai sensori applicazioni ibride
Il funzionamento di un’applicazione ibrida avviene tramite l’interazione di 2 parti:
Parte nativa dell’applicazione, che ha libero accesso a tutte le API di basso livello del
sistema operativo e quelle di alto livello, potendo comunicare con le app built-in
Parte Web dell’ applicazione, eseguita dal rendering engine, incapsulata nella parte nativa
e non nel browser del device, che può accedere alle funzionalità offerte da html 5 e
javascript.
Il collegamento tra le 2 parti viene realizzato attraverso lo strato bridge software.
I principali benefici di questo approccio sono:
•
Accesso alle risorse del device
•
Scrittura di codice con tecnologie web
•
Scrittura del codice una volta e riutilizzarlo per sviluppare applicazioni
multipiattaforma che supportano gran parte delle piattaforme mobile
•
Possibilità di utilizzo in modalità completamente offline, senza uso di caching di
HTML5
•
Distribuzione attraverso i vari Stores delle piattaforme mobile
Le applicazioni ibride possono essere sviluppate in 3 modi:
1- Mettere i contenuti su un server e caricarli in base alle richieste dell’applicazione,
74
perdendo quindi la possibilità di avere l’applicazione offline e incrementando la
latenza per reperire i dati dal server
2- Inserire i contenuti all’interno dell’applicazione impacchettandoli insieme al codice
compilato e quindi accessibili in modalità offline, anche senza l’utilizzo del caching
HMTL5.
3- Un mix dei 2 modi, reperendo i dati dal server tramite chiamate AJAX , tecnologia
che riduce il traffico dati sulla rete nella comunicazione col server, andando a
recuperare solo il payload generato dall’ interazione dell’ utente con l’interfaccia
grafica e non i dati per generare le pagine
3.3.3.1.
Phonegap
Phonegap è una tecnologia applicativa che permette di creare un contenitore nativo nel
quale eseguire un’applicazione mobile sviluppata attraverso linguaggi web come HTML,
Javascript, CSS. Il core della tecnologia è open source. Esso è utilizzato come strumento
di sviluppo di client mobile da diverse piattaforme mobile di sviluppo come ViziApps,
Worklight, Convertigo e appMobi. Nel 2011 Adobe acquisisce Nitobi Software,
sviluppatore di Phonegap, e rende disponibile l’accesso al software dal suo ambiente di
sviluppo Dreamweaver. Attraverso l’utilizzo del componente software web view,
utilizzato anche dal sistema operativo per il browser built-in, è possibile creare
l’interfaccia grafica dell’applicazione e le interazioni con essa basandosi sulle tecnologie
web per renderizzare i contenuti html ed elaborare le richieste utente di tipo navigazione,
interazione, manipolazione dell’interfaccia utente attraverso javascript. Phonegap fornisce
un set di api javascript che permettono l’accesso a funzionalità del sistema operativo
sottostante e l’accesso ai sensori del dispositivo attraverso invocazione da codice
javascript. Le api fornite supportano un ampio numero di sistemi operativi
(http://phonegap.com/about/feature). Il funzionamento delle api consiste in 2 parti: una
parte javascript da invocare e una nativa che si occupa di eseguire la funzionalità richiesta.
Phonegap si occupa di gestire la comunicazione tra le 2 parti dell’invocazione. Una volta
prodotto il codice dell’applicazione, esso viene distribuito come un archivio applicativo
binario in base al sistema operativo target. Ad esempio per IOS viene creato un file .IPA,
75
per Android un .APK, per Windows phone un .XAP. Attraverso l’utilizzo di phonegap è
possibile riutilizzare il codice dell’applicativo per le piattaforme supportate, dovendo solo
sviluppare il contenitore nativo.
3.3.4. Custom Container
Sviluppare un’applicazione tramite le tecnologie denominate Custom Container permette
di creare applicazioni mobile native potendo usare sia tecnologie web che un linguaggio di
programmazione e strumenti proprietari; il codice prodotto viene inserito in un container
nativo customizzato. Questo container svolge la funzione di virtual machine, cioè mappa il
codice prodotto in fase di sviluppo sulla piattaforma del dispositivo sul quale viene
eseguito. Il custom container che fa da interprete è richiesto per ogni piattaforma mobile
supportata. Viene data la possibilità di creare un’applicazione sia con il runtime incluso
nel package dell’applicazione nativa, sia senza ed usare il runtime in maniera separata; in
questo caso esso deve essere già installato sulla piattaforma sulla quale eseguire
l’applicativo. In Figura 31 è presentato lo stack applicativo della tecnologia:
Figura 31: Stack applicativo custom container
I vantaggi offerti dallo sviluppo di applicazioni attraverso questo tipo di tecnologia
consistono in:
1- Accesso ai sensori del device e ai servizi del sistema operativo attraverso le api fornite
dal framework ed estensioni native
76
2- Il numero di piattaforme nelle quali un’applicazione può essere eseguita, dipende solo
da quante vengono supportate dal runtime
3- Qualità dell’ambiente di sviluppo e del container, che permettono in maniera integrata
di sviluppare e testare l’applicazione senza l’uso degli SDK (Software Development
Kit ) nativi
4- Il contenitore customizzato risiede sul dispositivo e può accettare aggiornamenti OTA
che bypassano il controllo degli stores, diminuendo i tempi di aggiornamento
5- Riuso di codice e strumenti per produrre applicazioni per diverse piattaforme
6- L’elevata qualità dei tool a supporto rendono la manutenzione meno onerosa
7- Possibilità di essere distribuite attraverso i vari Stores delle piattaforme mobile
3.3.4.1.
Adobe AIR
Adobe Air è un runtime che permette lo sviluppo di Rich Internet Application, attraverso
linguaggi web standard (HTML,Javascript,CSS ) e proprietari (actionscript), il cui codice
può essere riutilizzato incapsulandolo in applicazioni native per diverse piattaforme, sia
mobile che desktop. Le piattaforme mobile supportate sono: IOS, Android, RIM su device
tablet. Il runtime di Air fornisce una piattaforma e un framework per supportare diversi
sistemi operativi. Attraverso l’utilizzo del runtime è possibile sviluppare le applicazioni
multipiattaforma senza dover interessarsi del sistema operativo sottostante, visto che il
target del codice è il runtime che fa da interprete, ossia converte a tempo di esecuzione il
linguaggio prodotto nel processo di sviluppo in quello utilizzabile dal processore del
sistema operativo di riferimento. Attraverso l’uso di tecnologie web, sia open che
proprietarie (Flash o Flex), è possibile sviluppare applicazioni web come native senza
dover utilizzare il codice specifico per ogni sistema operativo mobile. In figura 32 è
riportato lo stack applicativo di Air:
77
Figura 32: Stack applicativo di Adobe Air
Per lo sviluppo di applicativi mobile, viene creato un file .air che contiene il codice
dell’applicazione, il quale viene eseguito dal componente runtime. Il runtime fornisce
meccanismi di bridging tra HTML/JS e Flash, inoltre permette di invocare servizi del
sistema operativo sottostante in maniera trasparente attraverso le api fornite. Le api builtin fornite permettono di utilizzare determinati servizi del sistema operativo e consentono
l’accesso a un subset di features di basso livello del dispositivo, come gps e accelerometro.
Qualora gli sviluppatori necessitino di ulteriori features e servizi è possibile sviluppare
delle api aggiuntive denominate native extensions. Queste sono librerie che contengono
codice nativo creato ad-hoc che viene wrappato in API actionscript. Un esempio di
utilizzo è quello di inserire la vibrazione del dispositivo. In figura 33 sono riportate le
interazioni tra le native extensions, l’Air runtime e il dispositivo.
78
Figura 33: architettura native extension
3.3.5. Cross-compilation
Attraverso l’uso delle tecnologie denominate Cross-compilation si può sviluppare
un’applicazione nativa scrivendo il codice in un linguaggio proprietario, che viene
convertito in fase di compilazione nel linguaggio nativo per la piattaforma target. È
richiesta una Cross-compilation per ogni piattaforma che si vuole supportare. Questo tipo
di tecnologie forniscono una serie di API indipendenti dalla piattaforma che invocano le
API native dello specifico sistema operativo. Le API fornite da queste tecnologie si
integrano in maniera profonda con le caratteristiche e le capacità native delle piattaforme
supportate. Questo comporta un accesso maggiore alle features del dispositivo ma una
espansione del framework su diverse piattaforme onerosa, perché devono essere sviluppate
un nuovo set di API per ogni piattaforma che si intende supportare. I maggiori benefici
dati dallo sviluppo con queste tecnologie sono:
1- Sviluppo del codice dell’applicativo con linguaggi familiari agli sviluppatori (esempio
Javascript, C#, Java)
2- Le API fornite permettono un maggiore accesso alle caratteristiche e ai sensori del
dispositivo, potendo fornire quindi una esperienza utente vicina alle applicazioni
native
79
3- Creazione e interazione con le interfacce utente attraverso controlli nativi migliorano
l’esperienza utente
4- Gli sviluppatori possono usare un unico linguaggio di programmazione nello sviluppo
e poter distribuire l’applicazione per più piattaforme
5- Le applicazioni sviluppate possono essere distribuite attraverso i vari Stores delle
piattaforme mobile
3.3.5.1.
Titanium appcelerator
Titanium è un framework open source utilizzato per poter sviluppare applicazioni native
per desktop e mobile usando tecnologie web come javascript, html, e css. Questo
framework utilizza in maniera combinata API javascript e codice nativo specifico della
piattaforma sulla quale viene eseguita l’applicazione. Esso permette un riutilizzo del
codice per la parte core dell’applicativo, e attraverso l’uso di codice specifico per una
piattaforma (attraverso invocazione delle API proprietarie) permette di ottenere
performance e user experience vicine a quelle native. Quindi esso non utilizza un
approccio “write once, run everywhere” ma uno del tipo “write once, adapt everywhere”,
soprattutto per la parte legata all’interfaccia utente che deve essere adattata in base alla
piattaforma target. Il funzionamento del framework è basato sulla combinazione del
codice javascript prodotto con le API proprietarie fornite che sfruttano il codice nativo per
ogni piattaforma supportata; durante la compilazione viene settata la piattaforma di
destinazione, viene analizzato e preprocessato il codice javascript e precompilato in un set
di simboli risolti in base all’utilizzo delle API di titanium. La mappatura dipende dalla
piattaforma target; ad esempio su IPhone avviene una mappatura tra le API titanium e un
file .o che è stato compilato per l’architettura ARM. Una volta eseguito il mapping viene
invocato il compilatore nativo fornito dall’SDK della piattaforma target che produce il
codice binario. Il codice javascript che si occupa dell’application logic e del codice
dinamico (esempio la modifica real time dell’interfaccia utente a seguito di un evento )
viene inserito all’interno del file binario dell’applicazione nativa e viene interpretato a
runtime dall’interprete basato sull’engine Webkit che viene invocato durante l’avvio
dell’applicazione. L’interprete si occupa di agganciare il codice javascript che viene
80
caricato come un oggetto inline con gli oggetti nativi della piattaforma sottostante. Il
mapping viene effettuato in maniera stringente uno ad uno. In questo modo le API
titanium permettono di fare da bridge per l’accesso diretto alle features native, tra cui gli
elementi nativi della UI, senza l’utilizzo del componente web view, e i sensori del
dispositivo. La comunicazione con le features native viene effettuata direttamente senza
conversione del codice javascript in codice proprietario della piattaforma, ad esempio
Object-C o Java. In figura 34 viene mostrata l’architettura del framework.
Figura 34: Stack applicativo di Titanium
Le Api titanium coprono molte delle features dei sistemi operativi supportati; ci sono però
altri servizi e caratteristiche che non sono direttamente supportate. Il framework offre la
possibilità di estendere le funzionalità attraverso moduli opzionali nativi ove ci sia la
necessità di supportare una specifica feature o ad esempio per riutilizzare una libreria
nativa già esistente. Il processo per sviluppare un modulo nativo su titanium prevede 4
passaggi:
1- Definizione della funzionalità da esporre e come essa viene invocata dal codice
javascript, quindi si definisce l’API del modulo
81
2- Creazione del progetto con gli strumenti dell’SDK nativo per realizzare il modulo
3- Implementazione dell’API
4- Build, test, debug
3.4. Confronto tecnologie di sviluppo multipiattaforma
Tutti i tipi di approcci allo sviluppo e le tecnologie utilizzabili per realizzare applicazioni
mobile multipiattaforma in ambiente enterprise hanno punti di forza e di debolezza. La
scelta della tecnologia da adottare può dipendere da diversi fattori, come le esigenze
aziendali e i requisiti dell’applicativo da realizzare. Possono essere applicati diversi criteri
e metodologie, ma la loro applicazione deve adattarsi al contesto di riferimento che può
richiedere una valutazione diversa o aggiuntiva. Viene presentata una metodologia di
supporto alla decisione denominata Analytic Hierarchy Process (AHP), utilizzata per
confrontare sotto diversi driver le tecnologie di riferimento scelte.
3.4.1. Analytic Hierarchy Process (AHP)
Per determinare quale tra le diverse tecnologie di sviluppo è più opportuno utilizzare viene
di seguito illustrato e applicato un modello di scelta multi criterio, non essendo possibile
utilizzare un metodo di ottimizzazione a causa della numerosità e diversità dei fattori che
influenzano la decisione. L’analisi multi criterio per scopo decisionale (MCDA multi
criteria decision analysis) è una disciplina orientata a supportare il decisore qualora si
trovi a operare con valutazioni numerose e conflittuali,consentendo di ottenere una
soluzione di compromesso in modo trasparente. I metodi di analisi multi criterio
supportano il decisore nella fase di organizzazione e sintesi di informazioni complesse e
spesso di natura eterogenea. Tali metodi, elaborando informazioni note e giudizi espressi
dal decisore, consentono di determinare una decisione di compromesso ( best compromise
solution/decision), permettendo dunque al decisore di selezionare l’alternativa più
coerente con la propria struttura di preferenza. In particolare, tra le diverse metodologie
MCDA, viene applicata l’ Analytic Hirarchy Process AHP.
L’AHP consente di assegnare una priorità ad una serie di alternative decisionali, mettendo
in relazione valutazioni di tipo qualitativo e quantitativo, altrimenti non direttamente
confrontabili , e combinando scale multidimensionali di misure in una singola scala di
82
priorità.(Saaty,1980:Figueira,2005)
L’AHP affronta il processo di valutazione attraverso tre fasi:
1- Scomposizione gerarchica del problema
2- Giudizi comparati attraverso confronti a coppie delle alternative ad ogni livello della
gerarchia
3- Ricomposizione gerarchica, sintesi delle priorità e verifica di consistenza
Nella prima fase, definito l’obiettivo generale, si individuano i driver (e possibili
sottocriteri che vanno a formare l’albero decisionale) che lo influenzano e le alternative tra
le quali scegliere quella che ottiene il miglior punteggio globale. Si struttura il problema
in una gerarchia.
Figura 33: Gerarchia piramidale dell'AHP, applicato per individuare la tecnologia di
sviluppo di un’applicazione di riferimento
L’albero decisionale mostra graficamente la struttura dell’applicazione del metodo che
consiste nel valutare l’importanza di ogni driver in relazione all’obiettivo e ogni
alternativa in relazione ai diversi driver.
Il passo successivo è quello di comparare i vari elementi di ogni livello della gerarchia
partendo dalle foglie dell’albero. Per stabilire le priorità tra i vari elementi di ciascun
livello della gerarchia rispetto al nodo superiore si utilizza la tecnica del confronto a
83
coppie. Da questo confronto si può stabilire il grado di importanza di un elemento rispetto
ad un altro, entrambi appartenenti allo stesso livello. I risultati dei confronti a coppie
vengono aggregati in forma matriciale. Si definisce quindi la matrice dei confronti a
coppie, in cui il generico elemento aij è una stima della dominanza del primo elemento (i)
rispetto al secondo (j). Le valutazioni possono essere sia di tipo qualitativo che
quantitativo. Per determinare i valori dei coefficienti aij occorre utilizzare la scala
semantica di Saaty (Tabella 5), che mette in relazione i primi nove numeri interi con
altrettanti giudizi che esprimono, in termini qualitativi, i possibili risultati del confronto. In
caso di misure quantitative vengono utilizzati i dati ricavati di ogni elemento per la fase
successiva di sintesi e ranking.
1 3 5 7 9 2,4,6,8 i ugualmente importante rispetto a j i leggermente più importante del criterio j i più importante rispetto a j i molto più importante rispetto a j i estremamente più importante di j giudizi intermedi o di compromesso Tab.5: Scala semantica di Saaty
I dati contenuti nelle matrici dei confronti a coppie sono utilizzati per derivare l’ordine
delle priorità tra gli elementi di ciascuna matrice, ovvero una scala di valori che esprime la
preferenza finale delle alternative confrontate rispetto al criterio di riferimento.
Per ottenere il ranking locale relativo allo i-esimo livello della gerarchia viene calcolato
l’autovettore della matrice effettuando l’elevamento a potenza della matrice e sommando
gli elementi di ogni riga. Il vettore risultante viene normalizzato in base alla somma di tutti
gli elementi dello stesso vettore. Ognuno di questi vettori delle priorità esprime le priorità
locali degli elementi rispetto all’elemento posto a livello superiore; per ottenere le priorità
globali, cioè per ottenere un ordinamento globale delle alternative rispetto all’obiettivo
finale, si procede per aggregazione e confronto dei criteri posti a livello superiore.
L’ordinamento globale si ottiene mediante la somma pesata dei vettori delle priorità locali
delle diverse alternative, in cui i pesi sono rappresentati dai pesi attribuiti a ciascun driver.
84
I pesi globali rappresentano il risultato finale della valutazione in quanto consentono di
effettuare un ranking di preferenza: un’alternativa sarà tanto più preferibile quanto
maggiore è il suo peso globale.
3.4.2. Applicazione del metodo
Le tecnologie che vengono messe a confronto su diversi criteri legati allo sviluppo di
applicazioni enterprise sono: nativa , web application, cross-compiled, custom container e
ibrida. I confronti che vengono effettuati tra le diverse tecnologie sono realizzati sui
seguenti driver:
•
Portabilità: il numero di piattaforme supportate da una determinata tecnologia.
Tecnologie con elevata portabilità favoriscono politiche aziendali di tipo BYOD e
impattano maggiormente sulla diminuzione dei costi di sviluppo quando il numero di
piattaforme aumenta.
•
Accesso ai sensori: la capacità di una tecnologia di accedere ai sensori del dispositivo
Le tecnologie che forniscono un alto livello di integrazione con le risorse hardware
delle diverse piattaforme supportate permettono di sviluppare applicazioni utilizzabili
in un vasto range di scenari di utilizzo, risultando maggiormente flessibili.
•
Integrazione Applicazioni: è la possibilità di un’applicazione sviluppata con una
determinata tecnologia di interagire con le altre eseguite sul sistema operativo,
attraverso l’uso di protocolli di comunicazione e servizi del sistema operativo. Le
tecnologie con un alto livello di integrazione si adattano meglio a scenari in cui sono
presenti diverse applicazioni che devono cooperare per realizzare una macro attività o
necessitano di particolari servizi del sistema operativo
•
Aggiornamento funzionalità: Le risorse necessarie in termini di tempi e costi per
aggiungere o modificare le funzionalità di un’applicazione multipiattaforma sviluppata
con una determinata tecnologia. Un’applicazione facile da aggiornare permette di
lavorare su un unico codice per le diverse versioni del software in un unico ambiente
di sviluppo integrato.
•
Performance: il comportamento dell’applicazione realizzata con una determinata
tecnologia a fronte di un uso intenso delle risorse di calcolo del dispositivo. Le
85
situazioni più critiche sono rappresentate dalla presenza nell’interfaccia utente di
elementi grafici avanzati o elaborazione di grafica 3D o algoritmi complessi; altro
fattore da considerare è come le prestazioni degradano rispetto ad eventi come tocco o
zoom.
Dopo aver definito i driver sui quali effettuare i confronti delle diverse tecnologie, in base
alle specifiche del contesto in cui deve essere sviluppata l’applicazione è necessario
definire le priorità. Viene presentato uno scenario sul quale applicare il metodo AHP:
un’azienda vuole realizzare un’applicazione a supporto di una figura professionale che
opera in mobilità con mansioni principalmente di sales force, coprendo diverse attività
nell’orario di lavoro. L’applicazione deve poter essere eseguita sul dispositivo dell’addetto
in maniera indipendente dalla piattaforma sottostante e deve poter eseguita sia se il
dispositivo è aziendale che privato. Il numero di piattaforme da supportare deve essere
elevato per permettere di perseguire una politica di BYOD. L’azienda ha comunque
individuato un sottoinsieme di piattaforme di riferimento per le fasi di sperimentazione del
progetto. Le diverse versioni delle applicazioni dovranno avere un elevato grado di
integrazione con il sistema operativo su cui vengono eseguite, dovendo interagire con le
altre applicazioni già risiedenti sul sistema. È richiesto inoltre la possibilità dell’accesso a
determinati servizi e sensori del sistema operativo, in particolare Gps, local storage, e il
funzionamento offline. L’azienda intende utilizzare in futuro caratteristiche specifiche di
determinati tipi di dispositivi, come la possibilità di sfruttare la firma biometrica nel
processo di dematerializzazione dei contratti.
Sulla base dello scenario descritto le priorità attribuite ai diversi driver sono state:
1°.Portabilità: la portabilità è il driver più importante per le esigenze del progetto, le
piattaforme da supportare devono essere numerose ed è richiesto la facilità di adattare
l’applicazione all’evoluzione delle piattaforme.
2°.Integrazione applicazioni: l’integrazione e la collaborazione tra le diverse applicazioni,i
servizi offerti dal sistema operativo e le applicazioni built-in è richiesta per poter eseguire
le macroattività in maniera agevole.
3°.Aggiornamento: L’applicazione deve essere facilmente aggiornabile e modificabile in
86
tutte le versioni per le diverse piattaforme supportate.
4°.Accesso ai sensori: L’accesso ai sensori e ai servizi del sistema operativo è richiesto
principalmente per l’accesso al gps, lettura di codice a barre e la memorizzazione locale
per il funzionamento offline. In futuro è richiesta la possibilità di supportare la firma
biometrica.
5°.Performance: L’interfaccia utente non deve essere particolarmente complessa, in modo
da aumentarne l’usabilità, garantendo una esperienza utente accettabile.
In base alle considerazioni fatte è possibile compilare la tabella sottostante come previsto
dal metodo AHP
Portabilità Accesso ai sensori Costi di Integrazione Performance aggiornamento applicazioni Portabilità 1,00 7,00 2,50 1,67 9,00 Accesso ai sensori 0,14 1,00 0,33 0,20 2,00 Costi di aggiornamento Integrazione applicazioni Performance 0,40 3,00 1,00 0,50 4,00 0,60 5,00 2,00 1,00 7,00 0,11 0,50 0,25 0,14 1,00 Tabella 6: Confronto a coppie dei driver
Per ogni driver scelto è necessario dare una valutazione qualitativa rispetto alle tecnologie
di sviluppo. In seguito viene presentata una valutazione dei pesi assegnati
ad ogni
tecnologia rispetto ai driver individuati. Per far questo sono state utilizzate informazioni
provenienti da documenti prodotti dalla Gartner, una società di analisi specializzata in
assessment tecnologico e di mercato del settore IT, articoli ricercati in rete e prove
effettuate su prototipi realizzati ad-hoc per testare i diversi driver. I diversi test sono stati
svolti realizzando come demo una rubrica che sia capace di interfacciarsi con i sensori del
dispositivo, in particolare vibrazione e gps, focalizzando le prove su aspetti legati alla
portabilità e facilità di aggiornamento. Per ogni famiglia di tecnologie si è scelta una
soluzione di riferimento che rappresentasse meglio gli aspetti rilevati dalla letteratura. Le
tecnologie scelte sono HTML5 per la web application, Phonegap e un bridge realizzato ad
87
hoc per l’ibrido, Adobe Air per il custom container e Titanium per il cross compiled. Le
piattaforme sulle quali sono state testate le diverse versioni della demo sono Windows 8 e
android 4.0; i dispositivi utilizzati sono stati tablet per il sistema android e un pc desktop
per windows 8, sul quale è stata sviluppata la demo come applicazione win32. Di seguito
vengono riportate le valutazioni finali emerse per ogni driver.
3.4.2.1.
•
Portabilità
Nativa: le applicazioni native non sono portabili, per ogni piattaforma che si vuole
supportare bisogna sviluppare un porting. Esso viene effettuato utilizzando strumenti
di sviluppo, tecnologie, e linguaggi specifici forniti dall’SDK della piattaforma target
•
Cross-compiled: La portabilità delle applicazioni cross-compiled dipende dal supporto
dei framework alle diverse piattaforme. Estendere la portabilità è oneroso a causa dello
sviluppo delle numerose api da realizzare. Lo sviluppo del software con questa
tecnologia permette il riuso quasi totale del codice per le varie piattaforme, dovendo
adattarlo nei casi in cui bisogna accedere a caratteristiche specifiche di una piattaforma
(esempio uso della firma biometrica). Oltre al riuso del codice si possono usare gli
stessi strumenti, tecnologie e linguaggi per le diverse piattaforme da supportare, ma
potrebbe essere necessario l’uso degli SDK nativi per le fasi di packaging, testing e
deploying dell’applicativo
•
Custom Container: le applicazioni Custom Container sono portabili in maniera simile
alle Cross-compiled, dipendono dal numero di piattaforme supportate dall’interprete
del custom container. Viene utilizzato lo stesso codice e gli stessi strumenti per lo
sviluppo dell’applicazione per le diverse piattaforme. Per supportare specifiche
features di una piattaforma in particolare è necessario adattare il codice, potendo però
contare su strumenti a supporto efficaci.
•
Ibrida: le applicazioni ibride offrono una buona portabilità. Può essere usato lo stesso
codice e strumenti per sviluppare le applicazioni multipiattaforma. In pratica vengono
supportate tutte le piattaforme che possono gestire i controlli e la presentazione con le
tecnologie web embedded, cioè integrate nell’applicazione nativa, attraverso i vari
SDK. Strumenti nativi possono essere necessari per le fasi di packaging, testing, e
88
distribuzione dell’applicazione.
•
Applicazioni web mobile: le applicazioni web mobile offrono la portabilità migliore di
tutte le tecnologie. Un’applicazione può supportare qualsiasi piattaforma che ha un
Web browser. Bisogna però in fase di sviluppo pensare a gestire la frammentazione dei
browser e il loro supporto alle tecnologie web, soprattutto HTML5 e CSS3. Non sono
necessarie le tecnologie native nello sviluppo, anche se strumenti nativi possono essere
necessari per la fase di testing (esempio uso di simulatori).
La sperimentazione ha permesso di costatare che il codice sviluppato tramite html, css e
javascript sia supportato da tutte le piattaforme utilizzate. L’applicazione realizzata con
questa tecnica ha però mostrato limitazioni per quanto riguarda la vibrazione che non è
realizzabile e l’utilizzo del GPS non supportato da tutti i browser. Per quanto riguarda le
tecnologie ibride è immediato riutilizzare il codice web prodotto e integrare la vibrazione e
il gps attraverso il bridge, sia creato ad-hoc che tramite Phonegap. Per quanto riguarda
Adobe air è stato possibile importare il codice web all’interno del un pacchetto air da far
eseguire dal contenitore ma questo approccio non permette l’accesso ai sensori per la
vibrazione e il GPS. Si è effettuato un porting verso la tecnologia Actionscript che
supporta il flex framework, nel quale è possibile utilizzare librerie aggiuntive per accedere
ai sensori del dispositivo. In questo modo è stato possibile realizzare l’applicazione
completa delle sue funzionalità. Il framework inoltre consente di esportare il pacchetto
nativo per i sistemi operativi mobile come Ios, Android e blackberry senza la necessità di
istallare il contenitore separatamente. Su piattaforme desktop come windows è necessario
installare l’air runtime separatamente. In base a queste considerazioni è stata fatta la
seguente valutazione.
89
Nativo Cross compiled Custom Container Ibrido Web application Nativo 1,00 0,17 0,17 0,13 0,11 Cross compiled 6,00 1,00 1,00 0,50 0,20 Custom Container 6,00 1,00 1,00 0,50 0,20 Ibrido 7,50 2,00 2,00 1,00 0,67 Web application 9,00 5,00 5,00 1,50 1,00 Tabella 77: Confronto a coppie delle diverse alternative in relazione al driver "Portabilità"
3.4.2.2.
•
Integrazione applicazioni
Web-application: le web application non hanno possibilità di interagire con le
applicazioni sviluppate con tecnologia nativa e non possono utilizzare servizi di
storage offerti dal sistema operativo.
•
Ibrido: le applicazioni ibride supportano parzialmente l’integrazione con le altre
applicazioni, ad esempio sono supportate alcune applicazioni built-in come il
calendario.
•
Cross-compiled: Attraverso le api offerte da questa tecnologia è permesso l’uso di
molte funzionalità del sistema operativo di riferimento. E’ consentito l’accesso e la
comunicazione con tutte le applicazioni built-in, ma la comunicazione fra applicazioni
non è supportata completamente. È possibile estendere le funzionalità attraverso i
moduli nativi.
•
Custom-container: le features accessibili sono quelle più comuni e condivise da tutti i
sistemi operativi quindi l’integrazione con le altre applicazioni non è offerto dalla
tecnologia se si utilizzano tecnologie web aperte. Attraverso l’uso del framework Flex
e il linguaggio actionscript è possibile utilizzare diverse api ed estensioni native per
accedere ai servizi del sistema operativo.
•
Nativo: l’integrazione con le altre applicazioni è supportata completamente attraverso
l’uso delle API fornite dalle diverse piattaforme.
Oltre a queste considerazioni sono emerse dai test effettuati le limitazioni delle tecnologie
di riferimento rispetto al nativo. Mentre la web application attraverso l’html 5 consente di
90
accedere solo al GPS, l’ibrido sia con phone gap che con un bridge customizzato
permettono sia la geolocalizzazione che l’accesso ai sensori come la vibrazione. Preclusa è
invece la possibilità di utilizzare il protocollo di comunicazione tra le applicazioni offerto
sia da Android che da Windows implementato dal sistema operativo. Per il bridge
customizzato è necessario scrivere del codice nativo che integri queste funzionalità
mancanti. Per adobe air valgono le stesse cosiderazioni, il toolset non offre la possibilità di
utilizzare questa caratteristica specifica del sistema operativo ma mette a disposizione
degli strumenti che consentono di implementare delle librerie aggiuntive utilizzando
codice nativo che si integrano con il flex framework. Anche Titanium preclude questa
possibilità ma consente di integrare in codice nativo all’interno dell’applicazione.
In base a queste considerazioni sono stati dai i seguenti pesi:
Nativo Cross compiled Custom Container Ibrido Web application Nativo 1,00 1,43 2,00 2,00 9,00 Cross compiled 0,70 1,00 1,67 1,67 7,00 Custom Container 0,50 0,60 1,00 1,00 5,00 Ibrido 0,50 0,60 1,00 1,00 5,00 Web application 0,11 0,14 0,20 0,20 1,00 Tabella 88: Confronto a coppie delle diverse alternative in relazione al driver
"Portabilità"
3.4.2.3.
•
Aggiornamento funzionalità
Nativa: Le applicazioni multipiattaforma sviluppate con tecnologia nativa forniscono
le peggiori prestazioni in termini di aggiornamento delle funzionalità. Supportare
diverse piattaforme comporta lo sviluppo di codice nativo unico per ognuna,
utilizzando quindi linguaggi, strumenti e tecnologie peculiari, il che comporta il riuso
di codice e strumenti poco attuabile. Aggiungere nuove funzionalità ad una
applicazione comporta lavorare a diverse versioni del codice.
•
Cross-compiled: sviluppare applicazioni multipiattaforma con le tecnologie crosscompiled permette il riuso del codice e degli strumenti di sviluppo, dovendo adattare
91
ed estendere il codice relativo all’interfaccia grafica e alle funzionalità del sistema
operativo che non vengono supportate dalle api built-in fornite dal framework.
•
Custom-container: sviluppare applicazioni multipiattaforma con le tecnologie custom
container comporta un buon risparmio in termini di costi e tempi di aggiornamento e
modifiche, potendo riutilizzare lo stesso codice e gli stessi strumenti per le diverse
versioni dell’applicazione. Per funzionalità del sistema operativo e sull’uso dei sensori
che non sono coperte dalle api fornite dal framework, è necessario sviluppare
l’estensioni native per ogni piattaforma da supportare.
•
Ibrida: Queste tecnologie permettono un buon risparmio in termini di costi di
aggiornamento, grazie al significativo riuso del codice e l’utilizzo di tecnologie
conosciute e mature, che permettono di abbassare i costi. Un fattore da tenere in
considerazione risulta essere l’utilizzo delle tecnologie native per le fasi di packaging,
testing e distribuzione.
•
Applicazioni web mobile: le applicazioni che vengono sviluppate tramite le tecnologie
web hanno il maggiore impatto sui costi di aggiornamento in ambito multipiattaforma.
Infatti avendo la maggiore portabilità e l’utilizzo di una singola versione del codice per
tutte le piattaforme, riescono ad abbassare i costi e i tempi per effettuare modifiche e
nuove funzionalità.
Per le tecnologie sperimentate è stato costatato come la web application e l’ibrido si
possono aggiornare ed estendere in maniera simile in quanto entrambe utilizzano
tecnologie web per la logica di business dell’applicativo e lo strato di presentazione.
Tecnologie come Adobe Air consentono di scrivere codice una volta per tutte le
piattaforme ed eventualmente importare librerie già sviluppate se si intende supportare
diversi sistemi operativi con una determinata funzionalità, come ad esempio la vibrazione.
Con il framework Titanium l’aggiornamento deve tenere conto delle specifiche api del
sistema operativo da supportare. Titanium offre una serie di api comuni a tutte le
piataforme supportate che coprono le funzionalità comuni, se è necessario accedere a una
libreria specifica bisogna riscrivere la porzione di codice che implementa tale funzione per
92
il sistema operativo scelto.
Le valutazioni effettuate sono le seguenti:
Nativo Cross compiled Custom Container Ibrido Web application Nativo 1,00 0,20 0,14 0,14 0,11 Cross compiled 5,00 1,00 0,33 0,33 0,20 Custom Container 7,00 3,00 1,00 1,00 0,33 Ibrido 7,00 3,00 1,00 1,00 1,00 Web application 9,00 5,00 3,00 1,00 1,00 Tabella 9: Confronti a coppie delle diverse alternative in riferimento al driver
“integrazione applicazioni”
3.4.2.4.
•
Accesso ai sensori
Nativo: con questo approccio si ha la massima integrazione con le caratteristiche
specifiche sia del sistema operativo che del device. Si ha l’accesso a tutti i sensori e/o
alle API di basso livello che ne consentono l’accesso.
•
Cross-compiled: questa tecnologia permette di sfruttare la maggior parte delle
funzionalità caratteristiche delle piattaforme supportate. Essendo l’integrazione nativa
molto profonda e specifica il supporto è limitato a due o tre piattaforme di riferimento.
Poiché la tecnologia sfrutta una serie di API per accedere alla piattaforma di
destinazione non tutte le funzionalità sono esposte, ad esempio se si vuole includere
l’utilizzo della firma biometrica. Il codice che accede ad una caratteristica specifica di
una piattaforma deve essere scritto per tutte le piattaforme da supportare, non potendo
riutilizzare il codice prodotto.
•
Custom-container: l’applicazione ha bisogno di un contenitore nativo per ogni
piattaforma supportata, i tool di sviluppo offrono degli strumenti che consentono di
accedere a determinate features, coprendo solo un sottoinsieme di capacità native,
quelle comuni fra le diverse piattaforme, ad esempio il gps. Per accedere ai sensori non
forniti dalle api built-in è necessario sviluppare le estensioni native per ogni
93
piattaforma supportata.
•
Ibrido: in questa tipologia di applicazioni il bridge fornisce ha un accesso limitato alle
specifiche funzionalità della piattaforma sottostante. Sono supportate le funzionalità
più comuni del dispositivo come il GPS o la fotocamera. Per aumentare il supporto ai
sensori è possibile creare estensioni native per il bridge di terze parti come quello
fornito da Phonegap, o sviluppare il codice per il bridge creato ad-hoc.
•
Web-Application: L’accesso ai sensori tramite HTML5 e javascript ai sensori e ad
alcune applicazioni built-in è limitato, soprattutto per ragioni di sicurezza.
La sperimentazione ha evidenziato come l’accesso ai sensori sia maggiormente supportato
dalla tecnologia cross compiled che implementa di default caratteristiche specifiche dei
device che montano i sistemi operativi di cui si forniscono le api. L’ibrido espone tutti i
sensori comuni ai vari device come mostra la documentazione di Phonegap; creando il
bridge ad-hoc è possibile accedere a tutti i sensori del dispositivo attraverso invocazioni
del codice nativo. Adobe air supporta quasi tutte le caratteristiche più comuni come il GPS
e la camera, mentre per la vibrazione è stato necessario importare una libreria esterna
fornita da Adobe specifica per il sistema Android.
Le valutazioni effettuate sono le seguenti:
Nativo Cross compiled Custom Container Ibrido Web application Nativo 1,00 1,25 2,00 1,67 9,00 Cross compiled 0,80 1,00 1,67 2,50 3,33 Custom Container 0,50 0,60 1,00 0,50 3,00 Ibrido 0,60 0,40 2,00 1,00 5,25 Web application 0,11 0,30 0,33 0,19 1,00 Tabella 10: Confronto a coppie tra le diverse alternative in relazione al driver
"Accesso ai sensori"
94
3.4.2.5.
•
Performance
Nativo: questo approccio fornisce le performance migliori in quanto consente sia di
utilizzare i controlli nativi dell’SDK per ogni piattaforma che di creare interfacce
molto complesse sfruttando le librerie grafiche native.
•
Cross-compiled: grazie alla profonda integrazione offerta dalle API dedicate ad ogni
specifica piattaforma si riescono a ottenere delle interfacce simili a quelle native e
buone performance.
•
Custom-container: i tool offerti dalle tecnologie custom permettono di creare
interfacce anche elaborate ma spesso lontane da quella che è la user experience che
l’utente si aspetta da una determinata piattaforma. L’interpretazione del codice a
runtime del contenitore può ridurre le performance dell’applicazione soprattutto
quando sono richieste interfacce grafiche avanzate.
•
Ibrido: In questa modalità l’interazione con l’utente è quella offerta dalle tecnologie
web che grazie a strumenti e framework integrabili riescono a dare un’esperienza
utente gradevole e vicina al nativo. L’overhead dovuto al motore grafico che
renderizza le pagine html all’interno dell’applicazione non garantisce buone
prestazioni quando si richiedono interfacce complesse.
•
Web-application: l’interazione è quella offerta dalle possibilità dell’html5 e delle
tecnologie web ed eventualmente dall’utilizzo di framework come jquery mobile per
una user experience più accattivante. Le prestazioni , come per l’ibrido, sono legate
alla complessità dell’interfaccia e alla velocità del browser.
In fase di sperimentazione l’interfaccia sviluppata con le tecnologie web è stata riutilizzata
nella versione ibrida e custom container. La stessa interfaccia è stata riportata
nell’applicazione Adobe Air ed è stata renderizzata dal contenitore. Per realizzare la stessa
interfaccia con il flex framework è stato necessario effettuare un porting dell’html nel
linguaggio di markup di Adobe, con prestazioni dell’interfaccia grafica identiche. I pesi
dati alle varie tecnologie sono i seguenti:
95
Nativo Cross compiled Custom Container Ibrido Web application Nativo 1,00 1,43 2,50 2,50 3,33 Cross compiled 0,70 1,00 1,43 2,50 3,33 Custom Container 0,40 0,70 1,00 2,00 2,50 Ibrido 0,40 0,40 0,50 1,00 1,00 Web application 0,30 0,30 0,40 1,00 1,00 Tabella 11: Confronto a coppie tra le diverse alternative in relazione al drive
"Performance"
Dopo aver effettuato tutti i confronti tra le diverse alternative per ogni driver e confrontato
i driver rispetto all’obiettivo, sono stati prodotti gli autovettori per ogni matrice.
Effettuando la sintesi dei dati locali attraverso somme pesate è stato possibile ottenere un
autovettore totale, il quale normalizzato permette di ricavare un ranking globale delle
diverse alternative in base ai pesi ottenuti dalle valutazioni locali. La tabella 12 mostra i
risultati complessivi:
Portabilità Peso Nativo Cross compiled Custom Container Ibrido Web application Accesso ai sensori Costi di Integrazione Performance Risultato della aggiornamento applicazioni somma pesata 42,9% 3% 13% 6,5% 33% 27% 16,8% 3% 10% 29,7% 35% 27% 4,1% 35% 27% 15,88%
13% 14% 22% 17% 19% 16,04%
25% 45% 20% 5% 27% 39% 17% 4% 11% 9% 22,28%
18,06%
27,74%
Tabella 12: Rankig globale delle alternative
Osservando la colonna dei risultati della somma pesata è possibile ottenere il ranking
globale in cui in ordine decrescente è consigliato l’utilizzo di web application, ibrido,
custom container, cross-compiled, nativo.
Conclusioni Le alternative nello sviluppo di applicazioni mobile multipiattaforma di tipo enterprise
96
sono numerose, ognuna offre servizi e strumenti per poter perseguire una politica di
sviluppo di applicazioni che possano supportare più piattaforme e più dispositivi; nessuna
di quelle individuate permette di massimizzare i benefici di tutti i driver individuati,
dovendo quindi ricorrere a valutazioni complessive che tengano conto dei diversi
comportamenti dei framework e delle tecnologie di sviluppo. È stato scelto l’AHP come
metodo di supporto alla decisione per individuare la tecnologia con cui realizzare
un’applicazione enterprise perché permette di utilizzare nel calcolo dei ranking locali
grandezze quantitative e qualitative e di poterle sintetizzare insieme; inoltre permette di
poter velocemente cambiare i valori assegnati nei confronti, in caso di modifiche fatte da
valutazioni aggiuntive o cambiamenti settati da attori esterni come committenti del
progetto software. Analizzando il ranking finale della tabella 12, la tecnologia di sviluppo
consigliata dalla metodologia è la web application. Nel capitolo successivo verranno
presentate considerazioni aggiuntive che non sono state incluse nella elaborazione dei dati
dell’AHP, che porteranno alla selezione della tecnologia per la realizzazione di un
applicativo software per un progetto reale commissionato da Poste Italiane.
97
Capitolo 4
Implementazione di unʼapplicazione con la tecnologia
individuata: Analisi e progettazione
Introduzione Nel capitolo 3 sono state analizzate e confrontate le diverse tecnologie individuate per
supportare lo sviluppo multipiattaforma di applicazioni mobile enterprise. Tutte le
tecnologie scelte forniscono servizi peculiari che tendono a massimizzare determinati
benefici, non fornendo prestazioni ottimali in altri. Per poter effettuare un’analisi
comparativa che tenga conto delle prestazioni globali delle diverse alternative proposte è
stato utilizzato il metodo AHP. Questo metodo, utilizzando confronti a coppie di tipo
qualitativo e analisi quantitative, permette di produrre un ranking globale delle alternative,
rispetto al problema di selezione della tecnologia da adottare per la realizzazione di un
software, le cui caratteristiche sono riportate nel capitolo 3. L’applicazione del metodo ha
prodotto un ranking in cui la tecnologia che fornisce le migliori prestazioni complessive
risulta essere la web application. Una volta determinata la scelta consigliata, verrà
analizzata sulla base di un progetto reale di consulenza commissionato da Poste Italiane;
questo progetto aggiunge determinati vincoli che non sono stati inseriti nelle valutazioni
del metodo AHP, per mantenere una maggiore astrazione sulle caratteristiche
dell’applicazione target. Una volta scelta la tecnologia di sviluppo che possa supportare
tutti i vincoli del progetto, verrà presentato lo sviluppo dell’applicazione. In questo
capitolo sono trattati l’analisi dei requisiti software e la progettazione.
98
4.1. Requisiti dell’applicazione
Per poter effettuare la scelta della tecnologia di sviluppo, viene contestualizzato il ranking
fornito dal metodo AHP con le richieste dell’applicazione denominata AGENDA ASI.
I requisiti di alto livello dell’applicazione sono i seguenti:
L’applicazione da realizzare fa parte del progetto del postino telematico. Attraverso questa
nuova figura denominata ASI (articolazione servizi innovativi) Poste Italiane intende
recapitare in itinere servizi già offerti e nuovi a valore aggiunto, presso il domicilio dei
clienti, sia customer che business. L’applicazione AGENDA ASI si colloca come
applicazione di tipo sales force automation; essa deve permettere all’asi di poter prendere
appuntamenti o di riceverli dal centro distribuzione a cui è assegnato; l’asi tramite
l’applicazione può accedere ai dati dell’appuntamento, del cliente, tra cui anagrafica e
storico degli incontri precedenti. Al termine dell’appuntamento l’asi effettua la chiusura
inviando i dati al server centrale del centro distribuzione per la memorizzazione. Il valore
aggiunto di questa applicazione consiste nel poter tenere traccia dei servizi offerti e
venduti al cliente utili per la loro analisi da parte di applicazioni di business intelligence e
analitiche lato back-end. Inoltre attraverso lo storico l’asi può tenere traccia degli incontri
passati col cliente al fine di prepararsi meglio per l’appuntamento successivo, in modo tale
da aumentare l’efficacia nella vendita e nella proposizione dei servizi offerti da Poste
Italiane.
L’applicazione deve poter essere eseguita su sistemi Windows 8 ed Android 4.0,
rispettivamente su tablet Samsung Slate 7 business ed Olipad Graphos. Il suo utilizzo in
mobilità è garantito dall’utilizzo di una sim Poste Mobile per il traffico dati da rete 3G. Per
l’accesso al server di back-end per invio e ricezione dei dati dell’applicazione deve essere
utilizzato un componente software che verrà fornito per funzionalità di Gateway per
l’accesso alla VPN di Poste Italiane, al fine di accedere al server di back-end. Al momento
il componente è sviluppato per Windows 8 per applicazioni Win32.
L’applicazione deve poter funzionare anche in casi di assenza di rete, memorizzando i dati
in locale, che verranno trasmessi una volta che il segnale viene ripristinato, sia in modo
sincrono che asincrono.
99
4.2. Scelta della tecnologia di sviluppo
Analizzando i requisiti di alto livello e i vincoli a cui sottostare nello sviluppo
dell’applicazione, è stato verificato se la web application, tecnologia consigliata
dall’applicazione del metodo AHP, soddisfi tutte le richieste del software. È emerso
dall’analisi che la web application non risulta aderente a tute le richieste e vincoli imposti
dai requisiti dell’applicazione. In particolare lo sviluppo di una web application non è
fattibile per i seguenti motivi:
1- Poste Italiane non fornisce un server web dal quale caricare al primo avvio i contenuti
web per la parte di presentazione e di logica dell’applicazione che vengono poi
memorizzati in cache; inoltre non potendo utilizzare il protocollo http per le richieste
delle pagine web non è possibile utilizzare feature di HTML5 per la memorizzazione
in locale come indexed DB e local storage.
2- È necessario utilizzare il componente nativo per effettuare l’accesso alla VPN di poste
italiane; da javascript non è possibile effettuare la comunicazione con essa senza
bridge software.
3- In ottica di BYOD l’applicazione da sviluppare deve essere fornita di meccanismi di
controllo dell’accesso dell’utente e dell’applicazione; Poste Italiane per ottenere questo
controllo non intende utilizzare web services per l’autenticazione, ma fornisce
attraverso una piattaforma enterprise di gestione delle applicazioni meccanismi per
installare le applicazioni e controllarne l’accesso, sia in termini di utenti che di
dispositivi. Per questo motivo la web application non può essere utilizzata perché non
installabile sul dispositivo.
Avendo riscontrato che la web application non può essere sviluppata è stata scelta come
tecnologia di sviluppo l’approccio ibrido, il quale risulta nel ranking globale al secondo
posto e riesce a soddisfare tutti i vincoli dell’applicazione. In particolare è stato scelto di
sviluppare un bridge ad hoc che comunichi con il sistema operativo sottostante,
utilizzando per la parte di presentazione e logica applicativa HTML5 e javascript, e
100
implementare nativamente le funzionalità per la comunicazione con il componente nativo
e la memorizzazione in locale dei dati dell’applicazione. Con questo approccio il codice di
presentazione e logica verrà riutilizzato per le 2 piattaforme, dovendo sviluppare per ogni
piattaforma il codice per creare il contenitore nativo e le funzionalità native.
4.3. Analisi dei requisiti funzionali e non funzionali del software
Partendo dalla specifica del progetto sono state realizzate una serie interviste e riunioni
presso la sede di Poste Italiane con i committenti e diversi stakeholders connessi al
progetto, al fine di poter ricavare i casi d’uso dell’applicazione. In figura 34 è riportato il
diagramma dei casi d’uso dell’applicazione:
Figura 34: Casi d’uso
Dall’analisi dei casi d’uso e attraverso feedback del committente, è stata prodotta la lista
dei requisiti funzionali e non funzionali dell’applicativo. Una volta raccolti i requisiti è
stato realizzato un documento di SRS (software requirements specification) del progetto
software Viene di seguito riportata la lista dei titoli dei requisiti funzionali:
1- Login
101
2- Visualizza appuntamenti in agenda
3- Creazione appuntamento
4- Creazione nuovo cliente con appuntamento
5- Mostra dettagli appuntamento
6- Visualizza storico cliente
7- Mostra dati cliente
8- Mostra anagrafica completa cliente
9- Sposta appuntamento
10- Chiusura appuntamento
11- Aggiorna agenda
12- Annulla appuntamento
Per ogni caso d’uso è stato utilizzato il modello proposto da Martin Fowler per modellare
le interazioni dell’utente con il sistema software. Di seguito sono riportati 2 casi d’uso
realizzati:
Visualizza agenda
Contesto: Il postino accede all’agenda odierna e visualizza tutti gli appuntamenti divisi per
fascia oraria. Qualora volesse, può visualizzare gli appuntamenti relativi ad un altro giorno
Attore primario: Postino ASI
Precondizioni: L’ASI ha effettuato il login in maniera corretta
1.
Il sistema presenta l’agenda con gli appuntamenti per la data attuale suddivisi per
fascia oraria. Gli appuntamenti da effettuare sono contrassegnati con il colore verde, quelli
conclusi con il colore grigio, mentre gli appuntamenti che devono essere approvati dalla
centrale operative sono di colore giallo
Se al passo 2 il postino vuole visualizzare un altro giorno:
1.a.
Il postino seleziona un giorno diverso da quello attuale
1.b. Il sistema presenta l’agenda con gli appuntamenti del giorno scelto
Postcondizioni: nessuna
Visualizza appuntamento
Contesto: Il postino visualizza le informazioni relative a un appuntamento selezionandolo
102
dall’agenda
Attore primario: Postino ASI
Precondizioni: E’ stato eseguito il caso d’uso Visualizza agenda
1.
Il postino seleziona l’appuntamento da visualizzare
2.
Il sistema presenta i dati relativi all’appuntamento: nome del cliente, luogo
dell’appuntamento, tipo di servizio, categoria di servizio, tipologia di cliente e le per
eventuali note
Postcondizioni: nessuna
Terminata la stesura dell’SRS è stato confrontato ed integrato con quello realizzato dai
committenti, al fine di validare la fase di analisi e raccogliere i requisiti del software.
4.4. Progettazione del software
Dopo aver ottenuto la validazione dell’SRS dal committente è stata effettuata la
progettazione del software attraverso diagrammi UML ( Unified Modeling Language ),
utilizzati per realizzare il diagramma delle classi e i diagrammi di sequenza. Il primo viene
utilizzato per creare un modello di alto livello di astrazione del dominio, al fine di
analizzare le entità logiche coinvolte all’interno dell’applicazione; il terzo per modellare il
comportamento dinamico delle entità ottenute dal diagramma delle classi.
Nel diagramma della classi il dominio è stato analizzato ed astratto in maniera statica
attraverso una sere di entità logiche; esse sono state modellate con il paradigma ad oggetti
attraverso la creazione di classi e relazioni tra esse. Di seguito è riportato il class diagram
realizzato:
103
Figura 35: Diagramma delle classi
Le classi individuate sono:
Agenda Asi: si occupa di gestire le richieste dell’utente andando a creare o modificare gli
oggetti Appuntamento, Cliente, Storico e Servizio. Interagisce con la classe comunicatore
per inviare le richieste al server e al database
Appuntamento: gestisce le informazioni del modello sugli appuntamenti che il postino
segna e riceve in agenda
Cliente: gestisce le informazioni del modello sui clienti con cui il postino prende gli
appuntamenti
Storico: gestisce le informazioni del modello sullo storico relativo agli incontri passati del
postino con i clienti
104
Servizio: gestisce le informazioni del modello sui servizi che il postino offre ai clienti
durante gli appuntamenti
Comunicatore: gestisce le comunicazioni tra l’agenda e il server e tra l’agenda e il
database.
Per modellare le interazioni dinamiche tra gli oggetti nell’esecuzione dei diversi requisiti
funzionali sono stati realizzati i diagrammi di sequenza. In seguito vengono riportati alcuni
di quelli realizzati per l’applicazione:
105
Figura 36: Diagramma di sequenza: Visualizza agenda
106
Figura 37: Diagramma di sequenza: Aggiorna Agenda
107
Figura 38: Diagramma di sequenza: Nuovo Appuntamento
Conclusioni In questo capitolo è stato analizzato il contesto e i requisiti software di un’applicazione
mobile multipiattaforma commissionata da Poste Italiane. Sulla base dei vincoli
dell’applicativo è stata scelta la tecnologia ibrida per realizzare l’applicazione, posta al
secondo posto nel ranking AHP ma che permette di soddisfare tutti i vincoli imposti dal
progetto. Sono stati presentati alcuni dei modelli realizzati in fase di progettazione del
software che verranno utilizzati in fase di realizzazione dell’applicazione, che verrà
trattata nel capitolo successivo.
108
Capitolo 5
Implementazione di unʼapplicazione con la tecnologia
individuata: Sviluppo codice e analisi a posteriori della
tecnologia utilizzata
Introduzione In questo capitolo verrà analizzato il processo di realizzazione del codice partendo dalla
progettazione del software. Il progetto da realizzare fa parte di uno più grande, che Poste
Italiane sta costruendo intorno alla figura del Postino Telematico. Esso consiste in una
serie di applicazioni da realizzare principalmente per piattaforma Windows 8, le quali
saranno sperimentate sul campo al fine di validarne l’efficacia e l’efficienza prima della
messa in esercizio a regime. Questo contesto va a particolarizzare il processo di codifica
dell’applicazione, collegandolo con le fasi di analisi dei requisiti e di progettazione. Infatti
le due fasi precedenti, riportate nel capitolo 4, non sono state effettuate con un processo di
sviluppo Waterfall; ciò significa che non sono state chiuse completamente prima di
passare alla fase di codifica e testing dell’applicazione, ma è stato adottato un approccio
agile allo sviluppo. Questo approccio di sviluppo è stato necessario in quanto essendo in
un progetto innovativo di sperimentazione, i requisiti non sono ben delineati fin dalla
partenza del progetto; ciò significa che partendo dall’SRS validato sono state apportate
modifiche minori ad esso, comportando un adeguamento del modello di progetto e della
struttura del codice in maniera dinamica.
5.1. Processo agile adottato
109
Essendo l’applicazione una parte di un progetto innovativo composto da numerosi
elementi, con requisiti che hanno subito modifiche nel corso dello sviluppo, il processo di
sviluppo adottato è stato di tipo agile. Questo processo consiste principalmente in una
serie di iterazioni complete da realizzare su un sottoinsieme di requisiti dell’applicazione,
al fine di realizzare l’applicativo software in maniera incrementale e iterativa. Ogni
iterazione prevede fasi di analisi dei requisiti, progettazione, codifica, testing e
validazione. Esistono diverse metodologie che fanno parte della famiglia dei processi agili,
ognuna con una implementazione propria dei principi su cui si fonda questo tipo di
processo di sviluppo. Per la realizzazione dell’applicazione AGENDA ASI non è stato
adottato in maniera ferrea nessuno dei processi definiti all’interno dell’insieme delle
metodologie agili. Le caratteristiche principali dello sviluppo adottato dell’applicazione
sono state:
1- Condivisione e collaborazione: il team che si è occupato dello sviluppo del codice è
composto da 2 persone, le quali si sono divise il lavoro per proseguire in parallelo lo
sviluppo, ma allo stesso tempo si sono confrontate ed supportate nello sviluppo
dell’intera applicazione. In questo modo tutto il team era a conoscenza del codice
prodotto, in modo da poter apportare all’occorrenza cambiamenti in maniera efficace
2- Feedback del committente: partendo dalle fasi e documenti prodotti di analisi e
progettazione, sono stati implementati in diverse iterazioni piccoli subset di requisiti,
ordinati temporalmente per importanza, i quali sono stati validati oppure modificati
con il committente , attraverso una serie di riunioni e contatti tramite mail, al fine di
massimizzare la sua soddisfazione
3- Iterazioni brevi: Per poter validare l’evoluzione dello sviluppo e rispondere in
maniera tempestiva a modifiche dei requisiti da parte del committente sono state
realizzate iterazioni brevi, fatte validare dal cliente, attraverso l’uso di mock-up per la
parte di interfaccia utente e test a livello utente, realizzati dal vivo presso il cliente.
Nelle figura seguenti vengono mostrati alcuni dei mock-up realizzati:
110
Figura 39:Mock-up: schermata Visualizza Agenda
Figura 40:Mock-up: schermata Anagrafica Completa
5.2. Implementazione codice dell’applicativo
111
Sulla base delle richieste del committente l’applicazione è stata realizzata prima per
piattaforma Windows 8, dalla quale fare il porting verso il sistema Android sfruttando il
riutilizzo del codice già implementato. L’involucro nativo nel quale inserire il codice
HTML5 e javascript è costituito da un’applicazione del tipo Windows forms realizzata con
linguaggio di programmazione C#. Attraverso questo tipo di applicazione è possibile
accedere alle api grafiche per la costruzione dell’interfaccia utente; queste api sono poste
sopra il framework .NET e hanno accesso alle api Win32 del sistema operativo. Per
“embeddare” il codice HTML con cui è stata realizzata l’interfaccia grafica si è utilizzato
un componente denominato WebBrowser, che permette di utilizzare il rendering engine
utilizzato da Internet Explorer; attraverso il suo utilizzo viene caricato il codice HTML e
Javascript salvato in locale e sono abilitati i controlli web che permettono di navigare
attraverso le pagine, elaborare il codice javascript per rendere dinamica l’interfaccia
grafica ed effettuare le richieste AJAX al server. Per poter implementare la progettazione
orientata agli oggetti sono stati utilizzati pattern architetturali per poter utilizzare il codice
Javascript con il modello orientato agli oggetti. Per poter gestire la complessità
dell’applicazione e favorire la parallelizzazione dello sviluppo del codice è stato
implementato un pattern Model-View-Controller. Questo tipo di pattern architetturale è
molto diffuso nello sviluppo in applicazioni event-driven con interfacce utente grafiche.
Esso si basa sulla separazione dei compiti delle diverse classi, che si dividono in:
1- Classi Model: permettono l’accesso ai dati utili dell’applicazione
2- Classi View: visualizzano i dati del model e si occupano dell’interazione con l’utente,
inviando richieste al controller
3- Classi Controller: si occupano di ricevere le richieste dell’utente provenienti dalle
View, invocare il model per accedere e modificare i dati dell’applicazione e invocare
le class View per modificare l’interfaccia utente a seguito di aggiornamenti ricevuti
dalle richieste fatte al model.
Per poter realizzare questo pattern è stata realizzata una struttura dei contenuti web
chiamata single-page application. Essa consiste nel realizzare tutta l’interfaccia grafica in
112
una singola pagina html caricata all’avvio dell’applicazione; questa pagina viene
modificata nel contenuto in seguito ad aventi generati dall’utente, attraverso metodi
Javascript che vanno dinamicamente a modificare il DOM della pagina html per poter
creare le diverse schermate dell’applicazione. I contenuti html e javascript che vengono
caricati dinamicamente sono recuperati attraverso chiamate ajax su risorse salvate in locale
sul dispositivo. Tutte le funzionalità di interazione con l’utente e di modifica degli
elementi html delle schermate sono state realizzate con l’ausilio della libreria Jquery e di
diversi plug-in gratuiti reperibili in rete. Per effettuare l’autenticazione dell’ASI ed il
collegamento alla VPN di Poste Italiane attraverso rete 3G, è stata utilizzata una dll
(Dynamic-link library) rilasciata da PosteMobile che viene invocata durante il login
nell’applicazione; la comunicazione tra codice Javascript e C# viene realizzata attraverso
un oggetto javascript denominato window.external che si occupa di effettuare
l’invocazione dei metodi C# dal javascript, di passare i parametri ai metodi invocati e di
memorizzare gli eventuali dati di ritorno negli oggetti javascript. Questo meccanismo è
stato utilizzato anche per le invocazioni a funzionalità di memorizzazione permanente dei
nel database locale dell’applicazione client. Il database utilizzato è Sqlite. Esso permette di
utilizzare un database di tipo ACID che può essere incorporato in applicazioni senza
necessità di configurazioni, installazioni e processi in background da attivare. Esso ha
diverse caratteristiche interessanti; nonostante presenti anche diversi limiti le
caratteristiche richieste dall’applicazione nella memorizzazione in locale dei dati ben si
prestano all’utilizzo di questo tipo di database. Per la comunicazione col il server di backend sono state realizzate delle invocazioni a web services remoti invocati attraverso il
protocollo http utilizzando l’architettura REST (Representational state transfer) del server.
Questo tipo di architettura permette di invocare funzionalità remote e servizi offerti da
server attraverso il protocollo http e i suoi metodi GET,POST,PUT,DELETE. Attraverso
le URL (Uniform Resource Locator) alle risorse sul server, utilizzando un determinato
metodo nell’header http è possibile accedere e modificare lo stato di tali risorse. Le
convenzioni dell’architettura REST indicano che i metodi connessi ad una risorsa da
utilizzare sono:
113
GET: per recuperare i dati della risorsa sul server
POST: per creare una risorsa sul server
PUT: modificare una risorsa sul server
DELETE: cancellare una risorsa sul server
Durante la fase di sviluppo del codice il server su cui invocare i servizi non era stato
implementato; attraverso una serie di riunioni è stato possibile strutturare insieme alla
società a cui è stato commissionato la realizzazione dei servizi un ICD (interface contract
definition ); attraverso la stesura di questo documento, che fornisce i dettagli sulla
composizione delle richieste e delle risposte REST, è stato possibile realizzare il server per
i test della comunicazione in locale, in attesa dello sviluppo del server da utilizzare in
esercizio. Il formato di interscambio dei dati scelto è stato Json (JavaScript Object
Notation).
5.3. Analisi a posteriori della tecnologia ibrida
Per quantificare il beneficio apportato dall’uso della tecnologia ibrida nella realizzazione
dell’applicazione AGENDA ASI in ottica multipiattaforma, si è analizzato il codice
realizzato, attraverso la metrica delle LOC (line of code), al fine di determinare l’effort
richiesto per effettuare l’adattamento su piattaforma Android; per il conteggio è stato
scelto di selezionare le EXLOC (istruzioni eseguibili) e le DDLOC (istruzioni
dichiarative). Il codice dell’applicazione è stato suddiviso in 2 parti, codice realizzato con
tecnologie web e codice nativo realizzato in C#. Il primo è stato utilizzato per creare
l’interfaccia grafica e la logica di business dell’applicazione, il secondo è stato utilizzato
per costruire l’involucro nativo e per realizzare le funzionalità native utilizzate dal codice
Javascript. In tabella XXX sono riportati i dati sulle linee di codice dei 2 insiemi:
N° di righe di codice HTML - JAVASCRIPT
3287
N° di righe di codice C#
568
Tabella 13: numero di righe di codice dell’applicazione Windows 8
Attraverso l’analisi di questi dati è possibile effettuare una previsione dell’effort
necessario per adattare l’applicazione realizzata per piattaforma Windows 8 su Android. Il
codice da riscrivere è la parte nativa dell’applicazione. Quindi per questa applicazione è
114
possibile riutilizzare l’85% del codice prodotto, costituito dalla parte realizzata con le
tecnologie web. Il numero di righe di codice da realizzare attraverso il linguaggio Java su
piattaforma Android è molto simile a quello del C#. Il codice da realizzare sulla
piattaforma Android consiste nel creare l’involucro, configurare il componente webview
che si occupa di renderizzare le pagine HTML, abilitare l’eleborazione del linguaggio
Javascript per poter modificare l’interfaccia grafica dinamicamente ed invocare le
funzionalità native. Per le funzionalità native di accesso al database e di gateway verso la
VPN di Poste Italiane, verranno utilizzati rispettivamente Sqlite, disponibile nativamente
sulla piattaforma Android, e un componente sviluppato ad-hoc. Allo stato attuale può
essere richiesto un effort aggiuntivo dovuto alla non completa compatibilità delle
specifiche HTML5 e alle librerie Jquery sui diversi rendering engine utilizzati dai sistemi
operativi mobile. Questo lavoro tenderà in futuro a diminuire con il crescere del supporto
ad HTML5 e con la possibile convergenza dei rendering engine verso il Webkit. Di
seguito sono mostrate 2 screenshot a scopo dimostrativo dell’interfaccia grafica
dell’applicazione su 2 diversi dispositivi e sistemi operativi, uno con Windows 8 e l’altro
con Android 4.2:
Figura 41: Interfaccia grafica applicazione su Samsung Slate 7 (Windows 8)
115
Figura 42: Interfaccia grafica applicazione su Nexus 7 (Android 4.2)
Per realizzare l’applicazione demo eseguibile su piattaforma Android è stato riutilizzato
interamente il codice HTML5 e Javascript, creando il contenitore nativo, al quale è stato
aggiunto un modulo fake per simulare le richieste sul database, al fine di testare la
compatibilità del codice web prodotto con il rendering engine Webkit.
Conclusioni In questo capitolo è stato mostrato la realizzazione del codice applicativo per
l’applicazione AGENDA ASI su piattaforma Windows 8. Terminato il lavoro sono stati
raccolti i dati per poter quantificare il beneficio ottenuto dalla scelta della tecnologia
ibrida, che consente il riutilizzo del codice intorno all’85%. In questo modo per poter
eseguire il porting su diverse piattaforme, ad esempio Android, IOS, Windows RT, RIM, è
necessario produrre il codice con il linguaggio di sviluppo nativo che copre il 15% del
codice complessivo, al quale aggiungere eventuale codice nella parte web per gestire la
non uniformità al supporto dello standard HTML5 e alle librerie Jquery utilizzate.
116
Conclusioni e sviluppi futuri
Il lavoro svolto in questa tesi si è focalizzato sulle tecnologie e le metodologie a supporto
nello sviluppo di applicazioni mobile multipiattaforma di tipo Enterprise. Nel mercato
mobile sia i customer che le aziende si stanno muovendo sempre più verso un ottica
mobile, guidata dalla continua innovazione di questo contesto. Inoltre la disponibilità dei
dati, delle comunicazioni, attraverso social network e applicazioni dedicate, delle
applicazioni in mobilità, sta trasformando il modo con cui vengono utilizzate le risorse IT
in azienda. All’interno di questa evoluzione i dispositivi che porteranno i maggiori
benefici del lavoro in mobilità saranno secondo le previsioni i tablet. Le aziende li stanno
introducendo in diversi settori e business process interni. Analizzando le previsioni di
mercato dei sistemi operativi mobile e le strategie aziendali sull’adozione di un
determinato sistema operativo di riferimento, è emerso che in futuro ci sarà
frammentazione e incertezza sul numero dei sistemi operativi da utilizzare per eseguire le
applicazioni da sviluppare a supporto delle attività aziendali; inoltre in grandi aziende
politiche di BYOD favoriscono la proliferazione di dispositivi e sistemi operativi diversi.
In questo contesto identificare una tecnologia a supporto dello sviluppo multipiattaforma e
multidevice permette di contenere i costi di produzione e di manutenzione delle
applicazioni mobile. Sono state identificate diverse soluzioni e tecnologie, ognuna con
determinati servizi che massimizzano i benefici su determinati driver, a discapito di altri.
Per poter selezionare la tecnologia da utilizzare bisogna analizzare il contesto di utilizzo,
basandosi sui requisiti dell’applicazione e sulle richieste dell’azienda committente. Per la
fase di selezione è stata utilizzata una metodologia di scelta multicriterio a supporto della
decisione. Sulla base dei risultati ottenuti e delle richieste aziendali relative ad
117
un’applicazione da sviluppare, è stata scelta la tecnologia ibrida. È stata quindi sviluppata
un’applicazione per Windows 8 con la tecnologia individuata. Sono stati analizzati i
benefici della scelta effettuata andando a quantificare il codice prodotto che può essere
riutilizzato per successive versioni dell’applicazione per altri sistemi operativi; l’85% del
codice prodotto può essere riutilizzato, andando a riscrivere il restante 15% con i linguaggi
nativi per ogni sistema operativo si intende supportare. A questo codice si deve aggiungere
un eventuale porzione di codice da adattare dovuta al non uniforme supporto verso
HTML5 e le librerie Jquery, fornito dai rendering engine delle diverse piattaforme
software. Questo intervento adattativo nel tempo si prevede tendi a diminuire grazie alla
standardizzazione delle specifiche di HTML5 e alla convergenza dei diversi sistemi
operativi verso il rendering engine Webkit.
Gli sviluppi futuri prevedono la realizzazione del porting su piattaforma Android
dell’applicazione utilizzando la tecnologia ibrida. Al termine dello sviluppo verranno
analizzati a posteriori i dati sul reale riutilizzo del codice e dell’effort richiesto per
effettuare l’adattamento dell’applicazione. Verranno inoltre monitorate le evoluzioni delle
diverse tecnologie a supporto dello sviluppo multipiattaforma al fine di ottenere dati
aggiornati per il confronto delle prestazioni offerte sui driver individuati. Ad esempio per
inizio 2013 sono previsti da parte dei framework Titanium Appcelerator e Adobe Air il
supporto alle piattaforme RIM e Windows 8, andando ad incrementare notevolmente la
portabilità di un’applicazione realizzata con queste tecnologie.
118
119
Bibliografia
[1]
[Autore] [anno] “[titolo]”
[2]
[3]
120

Tesi multipiattaforma

Transcript

Documenti analoghi

avviso di seminario

programma-codemotion2012

Cod. Articolo 59.123 INCOMEDIA WEBSITE X5

AVEPA diventa più moderna ed interattiva

Datasheet, PDF - Konica Minolta

pubcoder annuncia la nuova esportazione in html5 per gli utenti

PSG Consumer 3C12 HP Notebook Datasheet

Systems Management

TABLET ANDROID 4.2 "GAMEXP" CONSOLE/EMULATORE CPU

Datasheet, PDF - Konica Minolta