UNIVERSITÀ DEGLI STUDI DI PARMA - cs.unipr.it · In questo contesto si inserisce questa Tesi, il...

UNIVERSITÀ DEGLI STUDI DI PARMADipartimento di Matematica e Informatica

Corso di laurea in Informatica

Interfacce a Programmi Complessi inAmbito Web e Mobile

Interfaces to Complex Programs for Web and Mobile

Studente: Relatore:Petrone Veronica Destri Giulio

Anno Accademico 2015 - 2016

1

RingraziamentiNel 2012 ho intrapreso questo nuovo percorso di formazione e da allora sono passati 4 annidi duro e intenso lavoro, ma alla fine sono riuscita ad arrivare a questo magnifico traguardodella mia carriera. Sono uscita dalle superiori come perito informatico e ho continuato ilramo per perfezionare e migliorare la mia esperienza in maniera esponenziale in questocampo meraviglioso sempre pieno di sviluppi e sorprese. Ora vorrei poter ringraziare tutticoloro che mi sono stati accanto in tutti questi anni.Ringrazio i miei genitori Vincenzo e Rosaria perché mi hanno dato la possibilità direalizzare questo sogno moralmente, ma sopratutto economicamente.Un ringraziamento particolare al mio amore Alessandro che mi ha accompagnato dallesuperiori fino ad oggi dandomi sempre la forza di combattere e farmi alzare ogni volta chequalcosa mi abbatteva.Un grazie speciale a Lamine, la persona che che mi è stata maggiormente accanto inquesti ultimi 3 anni, condividendo momenti di felicità e difficoltà superati sempre insieme.Abbiamo sudato duramente ma allo stesso tempo si è creata un’amicizia splendida, unpilastro fondamentale che mi ha dato sempre tanta forza e sostegno migliorando il miomodo di pensare e lavorare.Vorrei anche ringraziare i miei amici che hanno dovuto subire i miei noiosi sfoghi universi-tari e mi hanno sempre aiutato in caso di bisogno: Sara, Poggi, Giuliana, Michela, Ilenia,Ilaria R. e tanti altri, troppi da poter essere elencati tutti.Ci sono delle persone che vorrei ringraziare con il cuore in mano perché sono davvero moltoimportanti per me, sono come parte della mia famiglia fin da quando sono nata e vorreiringraziarli per essermi stati vicini sempre nel bene e nel male sostenendomi in tutto e pertutto: Zia Pina, Annamaria, Grazia, Carlo, Ilaria C. e Francesca.È doveroso ringraziare chi mi ha spinto per arrivare a questo traguardo come Prof. DiNunzio, Prof. Lori e Prof.ssa Lando che mi hanno riempito la testa esaltando tutte le miequalità e facendomi capire che sarei potuta arrivare dove sono ora.Infine un doveroso grazie al Prof. Ing. Giulio Destri per avermi dato la possibilità dicollaborare e svolgere lo stage formativo presso l’azienda SiGrade SPA, potendo realizzarequesto progetto per arricchire il mio bagaglio culturale sulla realizzazione di un softwareben costruito e che si affacci al mondo responsiveness il quale oggi prende sempre più piede.Sicuramente questo traguardo non è una fine ma un’altra tappa della vita raggiunta chespero mi dia un grande inizio nel mondo del lavoro.

Indice

Struttura del testo 5

1 Introduzione 61.1 Il mondo del software bancario e dei servizi italiano . . . . . . . . . . . . . . 61.2 Il contesto multipiattaforma . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Le necessità per il futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 L’evoluzione verso il mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Il ciclo di vita del software 122.1 I modelli tradizionali dello sviluppo software e il suo ciclo di vita . . . . . . 12

2.1.1 I modelli tradizionali dello sviluppo software . . . . . . . . . . . . . . 122.1.2 Il suo ciclo di vita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 I limiti dei processi di sviluppo del software . . . . . . . . . . . . . . . . . . 182.3 La necessità di ridurre i tempi di sviluppo . . . . . . . . . . . . . . . . . . . 192.4 Automazione della produzione del software . . . . . . . . . . . . . . . . . . . 21

3 Il Framework di SiGrade 223.1 Lo sviluppo dipartimentale object-oriented . . . . . . . . . . . . . . . . . . . 233.2 SiTemplateMVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 ASP.NET MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Architettura SiTemplateMVC . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Integrazione con mondo mobile: front-end web responsive . . . . . . . . . . 26

4 Attività operativa 274.1 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Che cos’è AngularJS? . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 Le principali caratteristiche di AngularJS . . . . . . . . . . . . . . . 284.1.3 Comunicazione tra Client e Server . . . . . . . . . . . . . . . . . . . 34

4.2 Integrazione di AngularJS in SiTemplateMVC . . . . . . . . . . . . . . . . . 354.2.1 Nuova Architettura SiTemplateMVC . . . . . . . . . . . . . . . . . . 354.2.2 Struttura architetturale delle View . . . . . . . . . . . . . . . . . . . 354.2.3 Le View prima dell’integrazione di AngularJS . . . . . . . . . . . . . 364.2.4 Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.5 AngularJS e Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.5.1 Le nuove View dopo la loro integrazione . . . . . . . . . . . 404.2.5.1.1 Menu e Footer . . . . . . . . . . . . . . . . . . . . 454.2.5.1.2 Diagramma di Navigazione . . . . . . . . . . . . . 47

4.3 Generatore di codice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.1 Test su più device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Conclusioni e Sviluppi futuri 49

2015 - 2016 4 Veronica Petrone

Struttura del Testo

La tesi è suddivisa in 5 capitoli, ognuno dei quali è dedicato ad una tematica specifica.Nel primo capitolo viene descritto come il mondo del software bancario si è evoluto neglianni cercando di capire le sue necessità per il futuro per quanto riguarda il contesto multi-piattaforma e l’evoluzione verso il mobile.Nel secondo capitolo, applicando quanto visto nel primo, sono definiti i modelli fonda-mentali dei meccanismi per realizzare in modo ottimale la progettazione di un software.Inoltre viene anche descritto come velocizzare la produzione del software rispettando i tem-pi di sviluppo necessari per il cliente.Nel terzo capitolo viene spiegato il Framework SiTemplateMVC dell’azienda dove il tiro-cinio è stato svolto. L’attenzione è posta solo a descrivere brevemente l’architettura di taleFramework ed alcune delle tecnologie usate durante il suo sviluppo. In più viene precisatoper quale motivo è necessario avere un’applicazione che si integri nel mondo mobile con unfront-end web responsive.Nel quarto capitolo, partendo da quello precedente, ho esposto il mio contributo sul la-voro svolto durante lo stage. Ho preso il progetto già trasformato nella sua parte back-endcome descritto nella Tesi di Lamine Ndiaye e mi sono occupata di modificare la parte front-end usando AngularJS e Bootstrap in modo da avere un’applicazione con un’interfaccia aprogrammi complessi in ambito web e mobile. Ho accennato in breve le caratteristiche diAngularJS e spiegato come può essere incorporato in SiTemplateMVC, quindi ho fatto unadescrizione dettagliata per la trasformazione delle interfacce del sito in modo che possaadattarsi su qualsiasi tipo di device. Ho spiegato l’importanza del generatore di codiceusato durante il lavoro, marcando quali sono i suoi vantaggi e per quale motivo viene usa-to, e infine ho effettuato i vari test sui diversi dispositivi.Nel quinto capitolo, ho descritto come il lavoro svolto abbia arricchito il mio bagaglioculturale, i vantaggi che ho ottenuto, la lezione appresa durante lo svolgimento del tirocinioe i possibili sviluppi futuri per il miglioramento del progetto su cui ho lavorato.


1 Introduzione

Il mondo del software bancario ha attraversato una lunga evoluzione negli ultimi 50 anni,nonostante l’avvento di nuove tecnologie e linguaggi di programmazione, oltre il 90% degliistituti di credito europei si sono affidati e si affidano ancora tutt’ora al COBOL comelinguaggio di sviluppo delle loro principali procedure IT. Da questo punto di vista il CO-BOL non è da considerarsi in via di estinzione, anzi si potrebbe dire che nonostante la sualongevità sia il caposaldo del maggior numero di transazioni a livello mondiale. Quindigli istituti bancari non intendono allontanarsi da questo linguaggio perché il solo pensierodi dover elaborare nuove procedure bancarie, abbandonando così COBOL, spaventa tuttii principali manager bancari. Con il crescere esponenziale delle nuove tecnologie le ban-che sono costrette ad "abbandonare" l’idea di avere tutto basato sul COBOL, integrandonuovi linguaggi di programmazione per aggiungere le nuove funzionalità, migliorando nelcontempo la sicurezza e le infrastrutture IT. I servizi di ultima generazione forniti dagliistituti bancari italiani sono di vari tipi come l’Home Banking, il Mobile Banking, InternetBanking, Smart Web, ecc. Infatti secondo l’ultimo rapporto ISTAT "Cittadini e tecno-logie", l’utilizzo di tali servizi è aumentato molto tra il 2013 e il 2016, cioè la quota diutenti che ha utilizzato Internet per usufruire di servizi bancari online (37,4%) ha avutoun incremento di +4,5 punti percentuali. Ciò è spiegabile soprattutto con l’introduzionedi nuovi applicativi, che oltre ad interessare le banche già esistenti, hanno permesso lanascita di banche totalmente virtuali che permettono al cliente di operare direttamente sulproprio conto corrente 24 ore su 24, senza bisogno di figure intermediarie.

In questo contesto si inserisce questa Tesi, il cui obiettivo specifico è di trasformareun software bancario, orientato alla fruibilità attraverso web e realizzato a partire dalFramework Jquery, con uno dei migliori Framework di ultima generazione ed integrare talesoftware con il mondo mobile o web responsive. Per fare ciò il punto di partenza è stataun’analisi approfondita del software esistente, in modo da capire meglio come integrare ilnuovo Framework, per non cambiare o riscrivere completamente il progetto già realizzato.Una parte del progetto della Tesi è stata creata utilizzando un generatore di codice giàa disposizione, per velocizzare i tempi di sviluppo e permettere l’uso del codice per altrieventuali progetti futuri.

1.1 Il mondo del software bancario e dei servizi italiano

Banche e Assicurazioni si confermano i primi investitori in nuove tecnologie in Italia, rap-presentando circa un quarto della domanda ICT complessiva. Eppure, restano ancora dacogliere grandi opportunità di innovazione e miglioramento dell’efficienza. La chiave peruscirne può essere soltanto una sorta di alleanza tra: i responsabili ICT, il Business e ilsistema dei fornitori, chiamati ad una maggiore collaborazione.

L’attuale assetto del sistema bancario e finanziario italiano è frutto di un complessoprocesso che ne ha in pochi anni trasformato la struttura, con l’obiettivo di una maggioreintegrazione nel mercato europeo. Le tappe principali di questo percorso, iniziato nei primianni ’90, sono la riforma della normativa di settore, culminata con l’adozione dei due Testiunici della Banca e della Finanza, che stabiliscono le finalità dell’attività di vigilanza, le


privatizzazioni, avviate alla fine del 1993, con la trasformazione in società per azioni delleBanche pubbliche, un forte consolidamento e la progressiva apertura all’estero del sistema.Il settore Finance rappresenta da sempre una voce di spesa importante del mercato ICTitaliano, con le grandi Banche tra i primi investitori in nuove tecnologie nel nostro Paese.Nello specifico, il settore Finance ha rappresentato nel 2014 in Italia il 24% della spesaICT complessiva. Il sistema informativo della banca sta fronteggiando un impegnativoprocesso evolutivo dovuto ai nuovi servizi, alle nuove tendenze di mercato, all’avventodel cloud computing e delle altre tecnologie CAMS (cloud, analytics, mobile e social). Ilpanorama sta velocemente evolvendo verso l’interconnessione e l’esternalizzazione spintacon infrastrutture e architetture più performanti e flessibili. Il cloud computing rappresentail nuovo modello di utilizzo e di distribuzione delle risorse ICT e propone soluzioni concreteai problemi di flessibilità e complessità del sistema informativo. Il settore bancario stamuovendo i primi passi nell’adozione del cloud computing, capitalizzando anni di esperienzasu temi quali la virtualizzazione e la sicurezza. Le banche italiane investono molto sullatecnologia. Nonostante la crisi, la strategia è chiara: con l’ICT si possono generare nuoviprofitti e migliori economie di scala. L’ICT è il fattore abilitante per eccellenza [12], secondole banche è un importante elemento di cambiamento. Ed è la nuova leva demografica, che sista facendo strada, che ha un rapporto differente con la tecnologia: più profondo e ’nativo’,oltre che più ricco. Il mondo bancario italiano negli ultimi anni ha monitorato l’evoluzionedel canale Internet e Mobile e si è attivato rapidamente. Il software bancario ha subitouna lunga evoluzione negli ultimi 50 anni ed è ancora in evoluzione, sopratutto per tuttigli istituti di credito che da anni a questa parte offrono numerosi servizi web, ciò comportauna fase di reingegnerizzazione di tutti i processi di gestione. Ci si affida a dei softwarecreati da entità esterne, specializzate in ICT, in modo tale da avere maggior affidabilità esicurezza del software.

1.2 Il contesto multipiattaforma

Lo sviluppo multipiattaforma in ambito mobile consiste nella produzione di software pro-gettato per supportare dispositivi diversi sia per caratteristiche hardware che per sistemioperativi. Questo processo si avvale di tecnologie e strumenti specifici e consente di scri-vere programmi che si adattano automaticamente o con sforzo minimo al contesto in cuivengono eseguiti. L’esigenza di riuscire a sviluppare un applicativo di questo tipo è sentitaparticolarmente in ambito enterprise grazie ai potenziali vantaggi che si possono avere intermini di riduzione dei tempi e costi per realizzare e mantenere il prodotto. Infatti negliultimi anni la rapida evoluzione dei dispositivi mobili e la frammentazione del mercatomobile, sia per sistemi operativi sia per tipologie di terminali con caratteristiche hardwaredifferenti, ha portato alla crescita dei costi di sviluppo e, soprattutto, di mantenimentodelle applicazioni mobile che devono supportare diverse piattaforme.Le aziende che vogliono produrre un’applicazione di tipo business che possa supportarediversi tipi di terminali mobili devono gestire la frammentazione del mercato mobile, siaper dispositivi sia per sistemi operativi. In questo momento le principali piattaforme sulmercato sulle quali è possibile sviluppare applicazioni mobile enterprise sono iOS, Android,Windows Phone, Windows 7, Windows 8, Windows 10. Questo comporta il dover creare


una strategia per poter pianificare il modo con cui approcciarsi al multipiattaforma, inbase alle esigenze aziendali, relative ai dispositivi da supportare e ai requisiti dell’applica-zione, in modo tale da contenere i costi di sviluppo e manutenzione. Infatti sviluppare emantenere codice multiplo per diverse piattaforme è diventato complicato e costoso. I pos-sibili approcci che possono essere adottati sono numerosi ed eterogenei, ognuno con propriepeculiarità, e nessuno è finora diventato lo standard nello sviluppo multipiattaforma in am-bito mobile. La maturazione della standardizzazione di HTML5 ci permette di utilizzarequesto insieme di tecnologie open source per lo sviluppo web come punto di riferimentonella realizzazione di siti web e web application avanzate. Con il termine HTML5 si indicaun’evoluzione dello standard che fa parte della famiglia delle tecnologie web aperte. Essotramite un insieme di API (application programming interface) innovative ed un markuppotenziato permette di creare applicazioni sul web avanzate senza ricorrere a software diterze parti, usati tramite plugin nei browser (esempio Flash o JavaFx). Con esso si haavuto un’innovazione sull’aspetto grafico e sull’interazione con l’utente, in modo da otte-nere una user experience ricca, simile a quella fornita dalle applicazioni native. HTML5può essere utilizzato anche nello sviluppo multipiattaforma di applicazioni che risiedonointeramente sui dispositivi mobile e desktop. Questa possibilità è fornita dallo sviluppodi diverse funzionalità innovative in HTML5, che permettono di utilizzare nuove caratte-ristiche, come audio e video in maniera nativa, oppure l’accesso ai sensori dei dispositivimobile tramite Javascript. Nel mercato dello sviluppo multipiattaforma nel settore mobilesono stati realizzati vari tool di supporto allo sviluppo, ognuno dei quali offre caratteri-stiche adatte a determinati contesti ma non a tutti, e che quindi devono essere analizzateper poter scegliere il Framework che fornisce le performance migliori, in base all’ esigenzadell’applicazione da realizzare e le specifiche richieste aziendali.Attualmente gli approcci che permettono di sviluppare un software multipiattaforma so-no diversi, ognuno con determinate caratteristiche a livello architetturale, prestazionale,tipologia di processo di sviluppo adottato, strumenti a disposizione per la realizzazione elivello di usabilità raggiungibile.

I tipi di applicazione attualmente esistenti nello sviluppo mobile possono essere catego-rizzati 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 integrato estrumenti per debugging ed emulazione.

• Applicazioni web mobile: sono applicazioni server-side, costruite con una qualsia-si tecnologia lato server per la logica di business (PHP, ASP.NET, ecc..) e per crearela pagina di cui viene eseguito il rendering lato client sul browser. Queste applica-zioni possono fornire un aspetto più vicino a quello nativo tramite tool aggiuntivi(esempio Jquery Mobile, AngularJS) che si fondono con le tecnologie web (HTML5,CSS, BOOTSTRAP e JAVASCRIPT), per visualizzare i contenuti e gestire la logicaapplicativa lato client. In questo tipo di applicazioni possono esserci più contesti diutilizzo, in base alle tecnologie che possono essere integrate nello sviluppo.


• Applicazioni ibride: come le applicazioni native, vengono installate sul device evengono lanciate dal menu del sistema operativo, ma sono sviluppate con le tecnolo-gie web in aggiunta al codice nativo. Le applicazioni ibride girano in un contenitorenativo e vengono eseguite come applicazioni native dal sistema operativo. Le pagineweb che ne costituiscono l’interfaccia grafica sono renderizzate da un componentesoftware, denominato webkit, rendering engine che fornisce all’interfaccia anche icontrolli del browser, ma a differenza di quello fornito come applicazione nativa,questo viene eseguito all’interno dell’applicazione ibrida. Lo scopo del webkit è in-terpretare e visualizzare a video le pagine html e processare localmente il codicejavascript. Uno strato software intermedio che fa da bridge software permette diaccedere tramite invocazioni di funzioni javascript ai sensori del device, come adesempio l’accelerometro o il giroscopio, e alle funzionalità del sistema operativo altri-menti inaccessibili; questo accesso infatti al momento è molto limitato per motivi disicurezza nelle applicazioni web mobile che utilizzano solo HTML5 e JAVASCRIPT,che possono accedere solo a un limitato numero di sensori, ad esempio il GPS. Trami-te l’utilizzo del web kit e delle tecnologie HTML5 e JAVASCRIPT è possibile eseguirelo stesso codice creato durante lo sviluppo su diversi sistemi operativi, dovendo mo-dificare solo il contenitore. Ciò consiste nel produrre l’applicazione nativa eseguibileche conterrà le pagine html e il codice javascript, e sviluppare ad-hoc il softwareintermedio tra javascript e le funzioni native del sistema operativo o adottarne unogià sviluppato da terze parti.

• Custom Container: con queste tecnologie si possono creare applicazioni tramite unlinguaggio proprietario e inserirle in un contenitore customizzato che viene eseguitonel 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 in-stallato a parte sul dispositivo. Nel secondo caso per far funzionare l’applicazione èrichiesta l’installazione dell’interprete. In entrambe le casistiche l’interprete a tempodi esecuzione si occupa di convertire il linguaggio dell’applicazione in quello dellapiattaforma sottostante.

• Cross-Compilation: con queste tecnologie si producono applicazioni trasformandoil codice scritto con un linguaggio di programmazione specifico anche di altre piat-taforme in codice nativo per le piattaforme di riferimento che sono supportate dalconvertitore. Attraverso l’uso di funzioni sviluppate ad-hoc da richiamare viene map-pato il linguaggio di origine nel linguaggio di destinazione per la specifica piattaformaper la quale creare il codice nativo equivalente che fornisce le funzionalità richieste.

1.3 Le necessità per il futuro

Considerando quello che è successo negli ultimi venti anni a livello di tecnologia, pro-viamo ad immaginare quello che accadrà nei prossimi venti, non possiamo che pensaread un’accelerazione dell’evoluzione tecnologica, con impatti sempre più forti, forse ancheinimmaginabili, sul modo di lavorare. Proprio per questo, l’ICT si sta affermando sempre


più come leva strategica anche in ambito Bancario. Nelle Banche possiamo osservare chealcuni modelli di business sono costruiti attorno ad Internet, ai call-center e alle bancheonline. Naturalmente ciascuna banca ha il suo modello, ma in ogni caso ormai l’ICT èdiventata una leva strategica che permette di perseguire e superare i fattori critici di suc-cesso. La tecnologia è sempre più presente nell’attività operativa della banca; infatti, molteattività di interazione con il cliente sono ormai demandate a strumenti tecnologicamenteavanzati come ATM intelligenti, cash dispenser, Internet, ecc. A questo punto però c’èaddirittura da chiedersi se l’allineamento dell’ICT al business sia una strategia sufficienteper un mondo in continua evoluzione, in cui l’innovazione tecnologica è diventata semprepiù rapida e dirompente.La maggior parte di Istituti Bancari italiani ha ben chiaro quali sono i campi in cui investirein futuro:

• Digitalizzazione;

• Innovazione;

• Multicanalità integrata;

• Maggior efficienza delle infrastrutture.

Sono queste la priorità nei programmi d’investimento in tecnologia delle banche ita-liane, insieme al costante adeguamento alle normative nazionali ed europee e all’ulteriorepotenziamento dei sistemi di sicurezza. Le ottiche di investimenti per il futuro cambianoaspetti concreti della vita della banca di tutti i giorni grazie alla tecnologia: dallo sportello,mentre crescono sempre più i canali diretti come l’internet banking e i contact center, almobile banking e il ruolo dei social network anche su processi e operazioni. Quindi diventasempre più importante la gestione documentale senza carta e l’evoluzione di tutto il conte-sto attorno al quale ruota il funzionamento del back office delle banche. Infine, cambianoanche le attività di supporto, tra le quali la più classica è ovviamente l’organizzazione e ge-stione delle risorse umane, che con la tecnologia informatica vede una radicale evoluzione.Nuove competenze, nuove specializzazioni necessarie anche al funzionamento della nuovacultura innovativa delle banche.

1.4 L’evoluzione verso il mobile

La rapidissima evoluzione delle tecnologie dell’informazione e della comunicazione ha mo-dificato radicalmente le nostre abitudini determinando drastici cambiamenti del nostro stiledi vita. Attività che assorbivano molto del nostro tempo - oggi vera risorsa scarsa - sonodivenute ora semplici e rapide e la connessione perenne ci consente di svolgerle indipen-dentemente dal luogo nel quale ci troviamo. Svegliati dall’allarme impostato sul nostrocellulare, consultiamo le notizie della mattina dal nostro tablet. Durante il tragitto verso illavoro utilizziamo il nostro smartphone per accedere ai social network, comunicare con gliamici tramite instant messaging, consultare la nostra casella di posta o ascoltare musica. Ilnostro lavoro si svolge prevalentemente tramite strumenti informatici ed è stato facilitato


dall’avvento degli strumenti di comunicazione digitali che rendono immediato lo scambiodi informazioni annullando di fatto le distanze. Dal nostro dispositivo possiamo consultarela cartella sanitaria, la posizione pensionistica, la situazione dei nostri investimenti, il saldodi conto corrente e disporre bonifici, comunicare con enti pubblici, effettuare prenotazionie qualsiasi tipo di acquisto. I meriti dell’evoluzione o meglio della rivoluzione digitale nonsono limitati alla semplificazione della nostra vita ma consistono in una vera e propria otti-mizzazione dell’agenda quotidiana, nella diffusione dell’informazione che accresce le nostreconoscenze e capacità di valutazione e nella tempestività con la quale possiamo agire.Dopo un’iniziale diffidenza, negli ultimi anni gli investitori italiani hanno aderito semprepiù numerosi all’offerta di servizi di trading e banking online, determinando un cambia-mento radicale nelle abitudini in questo settore. In questo campo l’innovazione tecnologica,anzichè ridurre il livello di servizio rendendolo standardizzato ed impersonale, ha ridottoi tempi finora dedicati ad attività a basso valore aggiunto ed i conseguenti costi, consen-tendo di prestare sempre maggiore attenzione a questioni più rilevanti. La pervasivitàdell’evoluzione digitale non poteva pertanto che apportare benefici anche nel campo delprivate banking. La solida tradizione e l’elevato livello del servizio offerto dalle banche aiclienti privati trovano ora un supporto negli strumenti messi a disposizione dall’evoluzionedigitale, che hanno semplificato e reso più efficiente il rapporto tra la banca ed il cliente,cogliendo appieno le nuove opportunità tecnologiche, di semplificazione e di interazione chestanno profondamente rivoluzionando la nostra società. L’interazione con il proprio consu-lente è stata resa più fluida grazie all’utilizzo da parte del private banker di mobile deviceper l’illustrazione delle proposte di investimento, delle caratteristiche del portafoglio e del-l’andamento dei mercati. L’introduzione della Firma Digitale nell’ambito di un servizio diweb advisory consente di fruire in mobilità dei servizi di consulenza finanziaria avanzata:il Cliente ha piena libertà di tempi e luoghi per valutare le proposte di investimento edattivare - con pochi e semplici passaggi - l’eventuale fase implementativa delle decisionicondivise, anche in un momento successivo all’incontro con il proprio consulente. Anchela conservazione e consultazione della documentazione sottoscritta digitalmente sono age-volate dalla totale eliminazione dei supporti cartacei. Tutto il processo è caratterizzatoda elevati livelli di sicurezza, grazie alla Firma Digitale ed ai rigorosi protocolli in materiaadottati dalla banca.L’interazione umana resta insostituibile ma l’avvento del digitale ne aumenta il valore li-berando tempo di qualità dedicato all’analisi, alla comprensione e al confronto. Il mobilebanking rappresenterà un tassello fondamentale per il futuro della distribuzione di servi-zi bancari. La diffusione dell’utilizzo di internet in mobilità rappresenta, infatti, uno deitrend più importanti di questi anni, soprattutto in Italia, e una delle sfide strategiche peril futuro dell’industria bancaria, abilitando processi di vendita/gestione delle transazioniin concomitanza con il manifestarsi del bisogno del cliente. Il mobile banking sta rac-cogliendo un interesse crescente da parte della popolazione italiana: secondo i dati della"School of Management" del Politecnico di Milano, le app più scaricate dagli utenti mobilesono proprio quelle del settore bancario/finanziario, seguite dal settore viaggi/trasporti etelecomunicazioni. Secondo il "4◦Osservatorio sul mobile banking" dell’ABI, il 100% dellebanche intervistate (campione rappresentativo del 50% del totale attivo del settore) offre


oggi almeno un’app per smartphone e il 77% propone anche un’app per tablet. Proprio ilmobile banking è indicato come uno dei canali sui quali nel breve periodo saranno effettua-ti maggiori investimenti. Secondo il rapporto AbiLab del Politecnico di Milano "Mobilebanking: un’app per tutti" tra il 2014 e il 2015 il numero di clienti che accedono ai servizibancari tramite smartphone e tablet è cresciuto dell’82% in Italia, raggiungendo i 4,4milioni di clienti. Nel 2014 sono state scaricate in media 8.800 app bancarie al giorno, il17% in più rispetto al 2013. I giudizi degli utenti sulle app bancarie sono più che positivi,con un apprezzamento che raggiunge più di 4 stelle su 5 quindi la maggior parte dellebanche sta sviluppando applicazioni ad-hoc per specifici servizi, come i pagamenti trami-te smartphone, il portafoglio elettronico, l’operatività sui mercati, l’assistenza clienti, maanche per specifici segmenti di clientela.

2 Il ciclo di vita del software

Il software ha ormai decenni di vita. I primi calcolatori programmabili entrarono nel mer-cato negli anni ’50. Oggi il software è pervasivo, non solo nei sistemi informativi di aziendeed organizzazioni [12], ma anche entro le automobili (centraline), gli elettrodomestici, isistemi industriali, ecc; in generale nella maggior parte degli strumenti che determinano lanostra vita di ogni giorno. Ciò nonostante ancora oggi esistono tante problematiche legateallo sviluppo di software, che troppo spesso richiede tempi più ampi o costi maggiori diquanto preventivato. Inoltre il software non è un prodotto "statico" che, una volta com-pletato rimane costante ma, nella maggior parte dei casi, si deve evolvere nel tempo perchécambiano i presupposti che ne hanno richiesto la creazione[5].

2.1 I modelli tradizionali dello sviluppo software e il suo ciclo di vita

2.1.1 I modelli tradizionali dello sviluppo software

Nei modelli tradizionali, lo sviluppo software avviene attraverso una successione di fasidifferenti, l’output di ogni fase costituisce l’input della successiva. Si tratta di modelli ite-rativi che, solitamente, prevedono che una fase non possa iniziare se prima non è terminataquella che la precede. Il modello tradizionale per eccellenza è il modello a cascata (Wa-terfall) la cui prima formale descrizione è riportata in un articolo del 1970 di WinstonW. Royce. La prima definizione del modello a cascata appare invece in uno scritto del1976 di Thomas E. Bell e T.A. Thayer. Questo modello ha origine in industrie manifat-turiere ed edili, settori altamente strutturati nei quali modifiche in corsa al prodotto sonofattibili, ma a costi molto elevati. Ovvio pertanto che venga posto il massimo rigore sullefasi di analisi e progettazione. Dal momento che, agli albori dello sviluppo software, nonerano stati "pensati" modelli atti allo scopo, non si fece altro che mutuare questo modelloiterativo in uso nelle imprese manifatturiere ed implementarlo nello sviluppo software. Ilmodello prevede fasi successive: Raccolta ed analisi requisiti, Design, Implementazione,Integrazione, Test, Installazione e Manutenzione.


Figura 1: Grafico del modello a cascata

Le regole di implementazione del modello a cascata stabiliscono che una buona percen-tuale del tempo dedicato al progetto deve essere investito nelle fasi di raccolta ed analisidei requisiti. Tipicamente viene investito il 20-40% del tempo a disposizione nelle fasidi Raccolta ed Analisi dei requisiti ed in quella di design. Il 30-40% viene dedicato allafase di implementazione ed integrazione, il resto del tempo è dedicato a test ed instal-lazione. L’idea centrale è che il tempo investito precocemente per assicurare che tutti irequisiti vengano correttamente rispettati comporta notevoli benefici in seguito. In terminimonetari, prevenire un bug durante una delle fasi iniziali (Requisiti o Design) comportauno sforzo economico enormemente minore rispetto al risolverlo durante una fase avanzatacome ad esempio Implementazione o Test (dalle 50 alle 200 volte più oneroso). Pertantola metodologia rigorosa di sviluppo a cascata stabilisce che una fase non possa iniziare sequella che la precede non è completa al 100%. Sulla base del modello a cascata sono natialtri modelli che ne condividono le linee guida, seppur con variazioni più o meno leggere,quali, ad esempio, la possibilità di ritornare alla fase precedente o addirittura alla fase diDesign, qualora emergano criticità durante la fase in corso, tali da ostacolarne il progresso.


Figura 2: Modello modificato con possibilità ritorno a fase precedente

Nel suo waterfall final model, W. Royce illustrò che il feedback raccolto durante la fase diTest, potrebbe evidenziare problemi tali da raccomandare un ritorno alla fase di Designed, eventualmente, da questa alla Raccolta o all’Analisi dei requisiti, qualora sia necessariauna rivisitazione dei requisiti per risolvere questi problemi.

Figura 3: Modello modificato, con possibile ritorno alle fasi di Design ed Analisi dei requisiti


2.1.2 Il suo ciclo di vita

Con il termine "ciclo di vita" del software ci si riferisce alle fasi attraversate d a un progettosoftware durante la sua evoluzione, dall’idea iniziale alla manutenzione. Il risultato finaleè il prodotto software stesso, accompagnato da tutta la documentazione ad esso associata.Vengono elencate e descritte le fasi comprese nella struttura base di un progetto software:

• Raccolta dei requisiti

• Analisi

• Progettazione

• Implementazione

• Test

• Installazione in produzione

• Manutenzione (ordinaria ed evolutiva)

Raccolta dei requisiti ed analisiIl progetto inizia con la fase di raccolta dei requisiti. In questa fondamentale fase vengonoadottate e combinate tra loro diverse tecniche volte ad "estrarre dalla mente del clienteo del committente tutto ciò che il progetto software dovrà fare". Il "Manuale dell’Anali-sta" [14] definisce questa fase come requirement elicitation, che può essere svolta con unacombinazione di 12 metodi diversi quali ad esempio: Interviste, Osservazioni sul campo,Gruppi di Lavoro, ecc. Il termine elicitazione è mutuato dalla psicologia e significa "tirarefuori" informazioni, in questo caso, mediante domande o altri comportamenti stimolanti.Alla fase di raccolta requisiti segue quella di analisi. Fase estremamente importante, inquanto un errore commesso a questo punto può avere ripercussioni molto serie sul risultatofinale.A seconda delle dimensioni del progetto l’analisi può essere svolta in toto all’inizio, oppureiterativamente durante il processo. A seconda del modello di sviluppo che viene adottato,l’analisi può essere ripetuta o meno durante il ciclo di vita del software. L’obiettivo dellafase di analisi è la descrizione completa e formalizzata, con un livello di dettaglio adeguatodi tutto ciò che il sistema deve fare (requisiti funzionali), dell’ambiente in cui dovrà operare(requisiti non funzionali) e dei vincoli che dovrà rispettare. Notare che la descrizionespecifica cosa il sistema dovrà fare, non il come (modello a scatola nera). Queste descrizionivengono raccolte in documenti chiamati documenti di specifica, brevemente specifiche.

La fase di progettazione (Design)Partendo dall’output della fase di analisi, che deve essere preciso e privo di ambiguità,la fase di progettazione definisce le istruzioni operative per la realizzazione del progetto(dettagli implementativi). Le istruzioni devono avere il giusto livello di dettaglio ed essere


Figura 4: Impatto degli errori fatti in fase di raccolta delle specifiche sulle fasi successive.

raccolte in documenti opportunamente strutturati. Pertanto, la progettazione di un’ap-plicazione è composta dalle attività per individuare la soluzione implementativa migliorerispetto agli obiettivi funzionali, a quelli non funzionali ed ai vincoli. Queste attivitápossono essere di varia natura, possono essere svolte in tempi e modi diversi in base all’ap-proccio seguito, ma in generale aiutano progettisti e team di sviluppo a prendere decisioniimportanti, spesso di natura strutturale. Il risultato della progettazione è la definizionedell’architettura del sistema, intendendo con questo termine l’organizzazione strutturaledel sistema stesso, che comprende i suoi componenti software, le proprietà visibili ester-namente di ciascuno di essi (l’interfaccia dei componenti) e le relazioni fra le parti. Inanalisi, requisiti e struttura del sistema sono rappresentati in forma astratta e (teorica-mente) indipendente dalla tecnologia. La progettazione tiene conto anche di tutti i fattorirelativi all’utilizzo di una tecnologia concreta e quindi, a differenza dell’analisi, la proget-tazione non può essere svolta indipendentemente dalla tecnologia utilizzata. Durante laprogettazione devono anche essere definiti tutti gli aspetti necessari per una implemen-tazione non ambigua. Uno strumento molto usato nella progettazione è il diagramma diflusso, oppure la sua evoluzione UML activity diagram. Entrambi gli strumenti servono arealizzare la scomposizione delle attività da compiere in elementi sempre più piccoli chepossano essere facilmente implementati con opportuni insiemi di istruzioni del linguaggiodi programmazione scelto.

La fase di implementazione (Coding)La scrittura del codice sorgente può essere svolta con molti strumenti, il più semplice deiquali è l’editor di file ASCII di base (notepad, gedit, vi, emacs, ecc...). Per la complessitàche i moderni linguaggi ad oggetti richiedono però tale approccio è troppo poco produttivo.Dovendo infatti garantire il rispetto di tempi stretti, è necessario disporre di tutte le funzio-ni di facilitazione integrate entro un unico strumento per la scrittura del codice sorgente.Un Integrated Development Environment (IDE), è un software che aiuta i programma-tori nello sviluppo del codice. Normalmente consiste in un editor di codice sorgente, un


compilatore e/o un interprete, un tool di building automatico, e (solitamente) un debugger.

Ormai sempre più spesso è integrato con sistemi di controllo di versione (SVN o GitHub,ad esempio), con sistemi di gestione delle dipendenze da librerie esterne (Maven, ad esem-pio) e con uno o più tool per semplificare la costruzione di una GUI. Alcuni IDE, rivoltiallo sviluppo di software orientato agli oggetti, comprendono anche un navigatore di classi,un analizzatore di oggetti e un diagramma della gerarchia delle classi. Sebbene siano inuso alcuni IDE multi-linguaggio, come Eclipse, NetBeans e Visual Studio, generalmente gliIDE sono rivolti ad uno specifico linguaggio di programmazione. La scrittura del codicesorgente, per quanto spesso poco considerata, rimane comunque la fase fondamentale diogni progetto informatico. L’analisi e la progettazione possono essere state svolte al me-glio, ma, se il codice viene scritto male, l’applicazione risultante avrà problemi e funzioneràmale. Facendo un’analogia nell’ambito dell’ingegneria civile, è chiaro che anche il progettopiù bello, se i pilastri non sono fabbricati bene, se i mattoni non sono posati con accura-tezza o se i materiali impiegati sono di scarso pregio, darà origine ad un edificio di pessimaqualità. Anche per questo, metodologie di programmazione più moderne tendono a farediventare la fase di scrittura del codice quella principale in tutto il progetto informatico.Durante la stesura del codice ha luogo anche il primo debugging, ossia la rimozione deglierrori di sintassi e degli errori più evidenti, come la mancata inizializzazione di variabili,che possono compromettere la compilazione o il funzionamento del programma. Gli IDEpiù moderni hanno ottimi sistemi di live debug. Tendono ad evidenziare in tempo reale,oltre al codice che inevitabilmente porterà ad errori di compilazione, anche frammenti dicodice inutili, blocchi ripetuti, inizializzazioni di variabili non necessarie, ecc.

La fase di TestUna volta che il programma è stato completato o comunque può iniziare a funzionare,occorre verificare che il suo funzionamento sia conforme a tutte le specifiche che erano statestabilite nella fase di analisi. Questo è lo scopo fondamentale della fase di test. Gli erroriche portano al non rispetto delle specifiche sono di solito molto più insidiosi da scoprirerispetto a quelli che vengono trovati durante il debugging. Non sono errori di sintassi, maerrori logici e concettuali, come, per esempio, lo scrivere il segno ’+’ invece del segno ’-’entro un algoritmo che richieda la sottrazione e non la somma. La fase di test prevedequindi di verificare il comportamento effettivo del programma rispetto a quello previstoe di segnalare le differenze di comportamento ai programmatori che dovranno procederealla ricerca e all’eliminazione delle cause di tali differenze. I modelli di sviluppo softwarepiù moderni pongono l’accento sulla fase di test, anteponendola in alcuni casi alla fase disviluppo e prevedendo l’esistenza di suite di test eseguite automaticamente durante la builded il packaging del progetto, allo scopo di ridurre il più possibile il rischio di regressione.

La fase di avvio ed entrata in produzioneDopo il test, raggiunto un livello sufficiente di qualità, il programma può entrare in pro-duzione. Questo termine ha un significato diverso secondo il tipo di programmi in rea-lizzazione. Per i programmi destinati alla vendita presso il pubblico, o alla distribuzione


se gratuiti, questa fase rappresenta il rilascio sul mercato, fisico (negozio), virtuale (e-commerce, download) o mobile (PlayStore, AppStore) che sia. Per i programmi realizzatispecificatamente per un cliente (i cosiddetti "programmi custom"), questa fase rappresental’installazione ed il collaudo presso la sede del cliente che li ha richiesti. In ultimo, perle applicazioni web (siti di e-commerce, portali, gaming-on-line, ecc) rappresenta l’instal-lazione ed il collaudo su uno o più server web (Apache, Tomcat, IIS, ecc) ed il tuning diquesti ultimi. Al termine di questa fase i programmi iniziano la propria vita operativa,durante la quale svolgono il compito previsto nel contesto per cui sono stati progettati, chepuò proseguire anche per molti anni.La fase di ManutenzioneDurante la vita operativa possono verificarsi necessità di interventi correttivi o di aggiorna-mento sui programmi, che prevedono nuove fasi di progettazione, implementazione e test.Tali interventi correttivi sono raggruppabili in due distinte famiglie:

• Manutenzione ordinaria, l’insieme di interventi correttivi necessari per via dierrori sfuggiti ai test o dovuti al funzionamento del programma in condizioni nonpreviste durante la sua progettazione, come ad esempio il funzionamento su Windows8 di un programma nato per Windows XP;

• Manutenzione evolutiva, l’insieme di interventi di variazione od arricchimentodelle funzioni del programma per via di nuove necessità operative del programmastesso; un esempio è l’aggiornamento continuo dei programmi gestionali per stareaggiornati rispetto alle normative fiscali. In generale, comunque, ogni programmadurante la sua vita è soggetto a interventi evolutivi e correttivi. Solo una piccolapercentuale di programmi non viene più toccata dopo il rilascio.

2.2 I limiti dei processi di sviluppo del software

Gli attuali processi di sviluppo purtroppo hanno ancora dei limiti, i processi a Cascatariscontrano già problemi alle prime verifiche concrete al termine della fase di test. Ilprocesso evolutivo invece fornisce solo una soluzione parziale ai problemi del modello acascata per cui elimina gli errori nei requisiti ma non riduce la distanza temporale peril completamento del ciclo di sviluppo. La pianificazione dei progetti condotti in modoiterativo è più complessa. Il piano di un processo iterativo evolve durante tutta la duratadel progetto stesso, e richiede un controllo sistematico degli avanzamenti. Un punto crucialeper il successo di un progetto iterativo è la collaborazione sistematica tra committenti egruppi di progetto. Un processo di sviluppo software per eliminare i propri limiti devepossedere alcune caratteristiche fondamentali per il suo sviluppo, più precisamente unprocesso software deve essere:

� Comprensibile: capire perché si è scelto di seguire un modello di sviluppo piuttostoche un altro;

� Visibile: a che punto si è giunti nello sviluppo, seguendo i dati precedentementeriportati sulle documentazioni di ciascuna fase del ciclo di vita del software;


� Supportabile: il processo deve essere supportato dagli strumenti che si decide diutilizzare per lo sviluppo del software;

� Accettabile: da coloro i quali si accingono a realizzarlo;

� Robusto: al punto di essere flessibile ai cambiamenti che potrebbero influenzare losviluppo del software;

� Rapido: nel produrre il software desiderato, ma quest’ultima caratteristica potrebbescontrarsi con la visibilità stessa del processo software;

2.3 La necessità di ridurre i tempi di sviluppo

Esistono le "Metodologie Agili" con le quali i team di sviluppo software sono in gradodi ridurre sensibilmente il rischio di non rispetto dei tempi e/o di commettere errori diinterpretazione dei requisiti, organizzando il proprio lavoro in piccole iterazioni, chiamatesprint, della durata di poche settimane (tipicamente 2-3) che permettono il rilascio delsoftware in modo incrementale. Con il termine "Metodologie Agili" ci si riferisce ad unaserie di metodologie di sviluppo software, ispirate dal "Manifesto Agile", impiegate persuperare i limiti emersi dal modello tradizionale "a cascata". Quindi grazie a queste meto-dologie i progetti software di entità medio-grande possono essere suddivisi in tanti progettidi dimensioni più piccole, aventi ciclo di vita proprio, rilascio in produzione compreso,lavorabili nell’ambito di un singolo periodo-unità di lavoro (sprint). Agile non è, in se, unprocesso caratterizzato da regole, ma è un insieme di linee guida che vengono poi imple-mentate dalle diverse metodologie.Tra le più comuni citiamo:

X RAD - Sviluppo rapido d’applicazioneQuesto metodo detto in inglese Rapid Application Development (RAD), definito daJames Martin all’inizio degli anni ’80, consiste in un ciclo di sviluppo corto basatosu 3 fasi: Inquadramento, Design e Costruzione, in un tempo ideale di 90 e di 120giorni massimo.

X DSDMIl Dynamic Software Development Method (DSDM) è stato attuato basandosi sulmetodo RAD per riempire alcune sue lacune, soprattutto offrendo un canovaccio checonsideri l’insieme del ciclo di sviluppo. I principi sulla quale si basa tale metodosono:

– Un coinvolgimento degli utilizzatori– Uno sviluppo interattivo e crescente– Una frequenza di consegna elevata– L’integrazione dei test in ogni tappa– L’accettazione dei prodotti consegnati dipende direttamente dalla soddisfazione

dei bisogni


X UP - Unified ProcessIl metodo di Processo Unificato (UP) è un processo di sviluppo interattivo e crescente,il che significa che il progetto è diviso in fasi molto brevi alla fine di ognuna dellequali viene rilasciata una nuova versione migliorata. Si tratta di una procedurabasata sulla creazione di modelli UML per la descrizione dell’architettura software(funzionale, software e hardware) e l’elaborazione di casi d’utilizzo che permettanodi descrivere i bisogni e le esigenze degli utenti.

X XP - eXtreme ProgrammingIl metodo XP definisce alcune pratiche che permettono di sviluppare un software nellecondizioni ottimali mettendo il cliente al centro del processo di sviluppo, in strettarelazione con il cliente. L’eXtreme Programming è basato soprattutto sui seguenticoncetti:

– Le equipe di sviluppo lavorano direttamente con il cliente su dei cicli molto brevida una a due settimane massimo.

– Le consegne della versione del software arrivano molto presto e ad una frequenzaelevata per massimizzare l’impatto dei feedback utenti.

– L’equipe di sviluppo lavora in totale collaborazione, le persone intervengonoanche sul codice scritto da altri e, spesso, lavorano in coppia sullo stesso codice

– La codifica è provata e ripulita durante tutto il processo di sviluppo.

– Alcuni indicatori permettono di misurare l’avanzamento del progetto per l’ag-giornamento del piano di sviluppo.


In definitiva, queste sono le principali differenze tra sviluppo Tradizionale e Agile Program-ming:

Agile WaterfallArchitettura infomale ed incrementale Architettura molto documentata e com-

pletata prima dell’inizio del codingLa ownership del codice è condivisa tra glisviluppatori

Ogni sviluppatore è responsabile di unadeterminata area

Integrazione continua Integrazione fatta alla fine o a tappepredeterminate

Focalizzato sul completamento delle storie(funzionalità) in piccole iterazioni (sprint)

Focalizzato sul completamento di mo-duli (parti dell’architettura) a scadenzeprefissate

Ben ingegnerizzato (TDD, XP, designpatterns, ecc.)

Non necessariamente ingegnerizzato

Pochi processi e documentazione Molti processi e documentazioneSviluppatori cross-competenti, ben infor-mati su tutte le tecnologie impiegate

Pochi architetti/sviluppatori hanno la vi-sione di insieme, le altre figure professio-nali sono molto specializzate

Ruolo principale: sviluppatori Ruoli principali: Architetti e sviluppatoriOpen door policy: gli sviluppatori sono in-coraggiati a rivolgersi al business ed al ma-nagement in qualsiasi momento. Il puntodi vista di tutti deve essere considerato

Solo pochi sviluppatori ed alcuni architettipossono rivolgersi al business. E principal-mente prima dell’inizio dello sviluppo e/oalle scadenze prefissate (milestones)

2.4 Automazione della produzione del software

L’automazione del collaudo del software consiste nello sviluppo di apposito software cheinteragisce con il software da collaudare senza bisogno dell’intervento di un operatore uma-no, e fornisce all’utente un rapporto di qualità. Il risultato del processo di automazionedel collaudo è il "collaudo automatizzato". Se invece il collaudo del software consiste nel-l’utilizzo del prodotto quasi come se fosse la normale operatività di tale sistema software,si parla di "collaudo manuale". Tra questi due estremi si possono avere varie posizioniintermedie, in cui parte del lavoro è automatizzato, ma è sempre richiesta la presenza delcollaudatore. In tali casi, si parla di "collaudo parzialmente automatizzato" o di "collaudosemi-automatizzato".Nel collaudo manuale, tipico del software interattivo, il collaudatore utilizza il softwarecome farebbe l’utente, ma cercando di attivare il maggior numero possibile di funzioni e leconfigurazioni più variegate. Quando il collaudatore constata un comportamento inatteso,ne prende nota e prosegue a collaudare altre funzionalità.


Nel collaudo automatico, il collaudatore può usare due tecniche di base:

1. Scrive a mano del software di collaudo.

2. Esegue il software da collaudare in un ambiente di collaudo che registra le operazionidell’utente.

La prima tecnica richiede che il collaudatore sia un programmatore che conosca l’architet-tura interna del software da collaudare. Il software di collaudo, tipicamente scritto in unlinguaggio ad altissimo livello, può interagire con il software da collaudare in vari modi:

• chiamando direttamente le singole routine di tale software;

• chiamando le routine esportate (ossia pubblicate) da un modulo;

• inviando al programma da collaudare dei messaggi di comunicazione tra processi;

• lanciando il programma da collaudare in una modalità in cui riceve due file, uno dalquale legge i dati di input, e l’altro nel quale scrive i dati di output.

Qualunque sia la tecnica di comunicazione adottata, quando il software da collaudarerisponde, il programma di collaudo confronta le risposte ottenute con i risultati attesi.In caso di differenza, viene generato un resoconto. La tecnica della registrazione delleoperazioni dell’utente può essere attuata anche da un collaudatore che non sa programmareo che non conosce l’architettura interna del software da collaudare. Ha tuttavia due notevoliinconvenienti:

• C’è un’alta probabilità che, quando il software da collaudare viene modificato, leregistrazioni siano improprie, e quindi da rifare.

• L’ambiente di collaudo non fornisce strumenti automatici per determinare se il soft-ware ha il comportamento atteso.

Questa tecnica è indicata per collaudi solo parzialmente automatizzati, in quanto è semprenecessario che il collaudatore verifichi visivamente se il software si comporta come dovreb-be. Solitamente, l’automazione del collaudo viene effettuata dopo aver sviluppato unaprocedura di collaudo manuale. L’introduzione dell’automazione nelle prove di collaudoè un processo costoso ed è da considerarsi un’aggiunta e non una sostituzione del collau-do manuale. L’investimento può tuttavia fornire un ritorno economico nel lungo termine,sia in quanto consente di effettuare il collaudo di regressione a basso costo, sia in quantoconsente la tecnica di sviluppo software detta "sviluppo guidato dal collaudo" (Test Dri-ven Development). Un settore di ricerca attivo è quello sulle generazione automatica deirequisiti di prova (test cases).

3 Il Framework di SiGrade

Negli sviluppi delle soluzioni personalizzate, SiGrade ricerca l’eccellenza attraverso la co-noscenza e l’uso di architetture, sistemi, linguaggi e best practice, da un lato per facilitarela system integration ed al contempo abbattere l’utilizzo di potenza elaborativa, dall’altroper rendere le proprie applicazioni sempre più "orientate all’utenza".


3.1 Lo sviluppo dipartimentale object-oriented

SiGrade mette a disposizione le competenze dei propri esperti per lo sviluppo di soluzionisoftware tagliate su misura sulle esigenze dello specifico cliente, realizzate con tempi e costiparticolarmente competitivi. La complessità organizzativa di molte banche, così come delleimprese, richiede infatti applicazioni ad hoc integrate nel Sistema Informativo aziendale ela manutenzione evolutiva di queste soluzioni.Le competenze di SiGrade consentono di affrontare progetti di ogni dimensione, in terminisia di processi sia di utenze, e di realizzare soluzioni che si adattano alle specifiche struttureorganizzative e si integrano con le diverse architetture tecnologiche già in uso. SiGradeoffre per ogni progetto due tipi di garanzia:

Garanzia di assistenza : la condivisione degli ambienti di sviluppo e degli standard diprogrammazione permette un’ampia disponibilità di risorse per un’assistenza certa,rapida ed efficace;

Garanzia di evoluzione : la dimensione aziendale e la presenza consolidata sul merca-to costituiscono una garanzia in termini di evoluzione e manutenzione dei sistemirealizzati per tutti i clienti SiGrade;

I Vantaggi che offre SiGrade per i clienti sono:

• Robustezza del softwareIl software è testato nei moduli fondamentali presso importanti clienti. E’ basato sudecenni di esperienza di programmazione di SiGrade.

• Tempi di sviluppo ridottiGrazie all’adozione di piattaforme di Runtime per la gestione delle connessioni e dellerisorse è possibile ottenere una gestione automatica degli errori di programmazioneed un impiego ottimale delle risorse (es. basi dati). Con l’utilizzo di "LightFra-mework", piattaforma per lo sviluppo di applicazioni distribuite, orientata al web2.0, che estende il Framework .NET di Microsoft, SiGrade è in grado di ottenereapplicazioni flessibili e con alte prestazioni in termini di velocità, stabilità e ma-nutenibilità. La disponibilità di strumenti e metodi di programmazione completi estrutturati permette di concentrare il lavoro sulla stesura della logica di business.

• Costi contenutiI tempi ridotti di sviluppo permettono di contenere i costi per l’implementazione epersonalizzazione delle soluzioni SiGrade.

3.2 SiTemplateMVC

SiTemplateMVC è un template per siti web creato da SiGrade per i suoi clienti. La suafunzionalità è quella di dare un’architettura logica di supporto facilitando lo sviluppo daparte del programmatore ed è per questo che viene considerato come un "Framework".Esso è stato realizzato avvalendosi dell’ambiente di sviluppo Visual Studio insieme a dellebuone evoluzioni tecnologiche in ambito .NET e Web development che ora vedremo neldettaglio.


3.2.1 jQuery

Secondo jQuery.com, è una veloce e concisa libreria JavaScript, che semplifica la gestionedi eventi su pagine HTML, aggiungendo animazioni ed interazioni Ajax alle pagine web.JQuery cambia il modo in cui si scrive codice JavaScript, in parole povere, modifica edevolve il Javascript tradizionale riducendo di molto le righe di codice da scrivere. JQuerycombina un enorme gamma di funzioni con compatibilità multipiattaforma, mettendo adisposizione dei programmatori un robusto Framework estendibile, ma attenzione i suoivantaggi possano tramutarsi in svantaggi perché con un insieme così grande di plugin svi-luppati e risorse gratuite ci sono anche quelli non compatibili con tutti i browser, nonaggiornati da tempo immemore, scritti male o non ottimizzati nella gestione delle risorse,ecc. Ecco perché diventa determinante la figura del programmatore che deve essere an-che molto consapevole nell’utilizzo di questa tecnologia, scegliendo con attenzione tra lelibrerie/plugin scritte meglio e maggiormente supportate, intervenendo direttamente nellascrittura di codice JQuery/JavaScript.

3.2.2 ASP.NET MVC

ASP.NET MVC è stato realizzato da Microsoft nel 2009 e rappresenta una valida alternati-va al modello WebForms tradizionale, infatti è un Framework per lo sviluppo di applicazio-ni Web che combina l’efficacia del modello architetturale Model-View-Controller (MVC)con le tecniche proprie dello sviluppo "agile" e le principali funzionalità di ASP.NET 4.5.Prima di analizzare la struttura architetturale di SiTemplate MVC è bene capire cosa siintende con il pattern MVC.La necessità di gestire la complessità che si accompagnava ad uno sviluppo del tutto de-strutturato, caratterizzato per lo più da blocchi monolitici di codice poco specializzato,condusse alla ricerca di un approccio alternativo che garantisse una migliore organizza-zione del codice sorgente. Così nel corso degli anni ’80 fu introdotto MVC che facilita losviluppo di applicazioni composte da numerose interfacce utente, ciascuna caratterizzatada una sua logica di interazione e di trasformazione dei dati trattati. Questo grado di strut-turazione nelle applicazioni, in particolare nello strato di presentazione, individuando trecomponenti principali tra loro distinti a cui sono assegnate responsabilità complementari:Model, View e Controller.

Figura 5: Model-View-Controller


La View si occupa semplicemente della visualizzazione dell’interfaccia utente. È un compo-nente passivo, particolarmente semplice e (idealmente) privo di logica; per questo motivonon necessita di essere testato dato che il suo output è puramente visuale. Il Controller èil componente che ha lo scopo di eseguire le azioni richieste dall’utente e fornire di voltain volta la View per la visualizzazione del risultato. Esso comunica con il Model, ovverocon lo strato che fornisce i metodi per accedere ai dati utili dell’applicazione. Il Controllerrichiama oggetti e servizi del Model senza conoscere gli effetti che verranno prodotti sullaView. Sia il Controller che il Model presentano la necessità di dover essere testati dalmomento che la logica contenuta in essi non è minimale come nel caso della View.

3.3 Architettura SiTemplateMVC

Figura 6: Archittetura del Framework SiTemplateMVC

Il Framework di SiGrade separa in modo netto la componente web da quella di business.Quest’ultima comprende una serie di layers che interagiscono con la base dati e imple-mentano tutte le funzionalità applicative. Tali layers sono organizzati come uno stack incui ogni elemento collabora con quello successivo, variando le funzionalità implementateda più vicine al "dato fisico" (i più interni) a quelle più inerenti alla logica di business aservizi.


Ecco una breve descrizione di questi layers:

• Layer servizi WCF: Espone le funzionalità dell’applicazione come servizio verso lacomponente web (o altre applicazioni che necessitano delle funzionalità esposte);

• Layer di business: Implementa le funzionalità applicative vere e proprie utilizzandoi servizi messi a disposizione dal Layer Query ;

• Layer Query: Implementa le query sulla base dati utilizzate dal livello precedente,mediante gli oggetti e i metodi messi a disposizione dal Layer ORM ;

• Layer ORM: Il livello di Object Relational Mapping consta di una serie di oggettie metodi che dà una rappresentazione, appunto, a "oggetti" (dal punto di vista dellinguaggio di programmazione) delle entità e delle relazioni della base dati;

• Layer SQLBuilder: Questo livello è utilizzato dall’ORM per comporre le query nel"dialetto" del motore SQL utilizzato (questo livello rende l’applicazione indipendentedal DataBase dal punto di vista del linguaggio);

• Layer Driver: Questo livello è utilizzato da quello precedente per eseguire fisica-mente le interazioni con la base dati (rende l’applicazione indipendente dal DataBasedal punto di vista della connessione).

3.4 Integrazione con mondo mobile: front-end web responsive

Come prima cosa bisogna aver ben chiaro cosa si intende con front-end development, perpoterlo capire al meglio si potrebbe usare una metafora automobilistica: costruire una WebApp è come costruire una macchina, il front-end developer è chi si occupa di montare i sediliin pelle, le finiture in radica, il volante, i pedali ecc., poi c’è il back-end developer che è chi sioccupa di montare il motore, i freni, la trasmissione, ecc. Quindi il front-end developmentè tutta la parte di sviluppo che, una volta piazzati i componenti strutturali, si occupa direndere il prodotto davvero utilizzabile e più confortevole. Esso coinvolge principalmente 3tecnologie: HTML, CSS e JavaScript. Negli anni queste tecnologie hanno mostrato i lorodifetti: HTML e JavaScript sono vecchi e "brutti" e, anche se il CSS non è brutto di persé, è totalmente anti-DRY (Don’t Repeat Yourself!). Il web di oggi impone design ognigiorno più complessi e richiede la compatibilità non solo con tutti i possibili browser, maanche con un numero sempre maggiore di dispositivi hardware come smartphone, tablet,desktop, ecc. Per affrontare queste nuove sfide, il front-end design ha fatto grandi passiin avanti come pochi altri rami dell’informatica ed è nata una miriade di nuovi strumenti,come appunto i front-end framework.Oggi non si parla più solo di fogli di stile CSS "artigianali" e di qualche pezzo di codiceJavaScript qua e là, ma di veri e propri Framework per il design di user interface semprepiù accattivanti. Alcuni di questi Framework si limitano a fornire le fondamenta, comead esempio Skeleton, mentre altri arrivano a coprire ogni aspetto di un’interfaccia utentecome ad esempio Bootstrap. È anche vero che con essi si ha un forte rischio di design similifra loro, bisogna imparare e conoscere un codice non scritto da noi stessi e quindi si rischia


di aggiungere un nuovo livello di complessità e astrazione, ma ciò comporta anche designpiù veloci ed agili senza dover sempre ripartire da zero e soprattutto si ottiene una WebApp già pronta al mobile.

4 Attività operativa

Prima di poter toccare e migliorare SiTemplateMVC bisogna cercare tra le soluzioni attualidiffuse trovando quella più efficace ed efficiente per strutturare l’architettura della tecno-logia che metterà in moto l’intero progetto. Come esposto nella Tesi di Lamine Ndiaye lamiglior soluzione attuale è AngularJS. Il mio contributo per il miglioramento del templa-te riguarderà la parte di front-end web responsive, ossia tutto ciò che riguarda le paginevisualizzate all’utente realizzando un’interfaccia adattabile a qualsiasi tipo di device. Unavolta creata la struttura iniziale di base si può utilizzare un generatore di codice in mododa ottimizzare i tempi di sviluppo.

4.1 AngularJS

4.1.1 Che cos’è AngularJS?

AngularJS è un Framework, o meglio una infrastruttura per la creazione di applicazionicomposta da un insieme di funzionalità. Citando la documentazione ufficiale:

Angular è quello che HTML avrebbe dovuto essere se fosse stato progettato per sviluppareapplicazioni.

Per raggiungere questo obiettivo, AngularJS da un lato esalta e potenzia l’approccio dichia-rativo dell’HTML nella definizione dell’interfaccia grafica, dall’altro fornisce strumenti perla costruzione di un’architettura modulare e testabile della logica applicativa di un’applica-zione. Questi concetti, probabilmente ora un po’ astratti, dovranno essere tenuti presentiper comprendere appieno le potenzialità di AngularJS evitando di utilizzarlo (male) comeun’ennesima libreria JavaScript. AngularJS fornisce tutto quanto occorre per creare ap-plicazioni moderne che sfruttano le più recenti tecnologie, come ad esempio le Single PageApplication, cioè applicazioni le cui risorse vengono caricate dinamicamente su richiesta,senza necessità di ricaricare l’intera pagina. In parole povere significa che AngularJS è unquadro strutturale per le applicazioni web dinamiche. Esso consente di ampliare la sintassi


HTML per estendere i componenti della propria applicazione in modo chiaro e conciso.Associazione di dati in AngularJS e iniezione di dipendenze ci fanno eliminare grande par-te di codice da scrivere, risparmiando molto tempo e l’interpretazione del tutto avvieneall’interno del browser, che lo rende un partner ideale per qualsiasi tecnologia server uti-lizzata. Il principale obiettivo di questo Framework strutturale è di aumentare la capacitàMVC (Model View Controller) delle applicazioni web.

4.1.2 Le principali caratteristiche di AngularJS

A differenza di molti altri Framework, AngularJS nasce con una nuova idea di struttura-zione e ha alcune funzionalità di rilievo che sono utili non solo agli sviluppatori ma ancheai designers. Ecco di seguito alcune funzionalità interessanti di AngularJS che permettonodi sviluppare applicazioni web di ultima generazione.

1. MVC e AngularJSMVC Model View Controller, già descritto in precedenza, è un modello di progetta-zione molto popolare nel mondo web. Aiuta ad organizzare la nostra applicazione intre diversi strati e isolare la logica di business dalla sua presentazione.

Model - rappresentano lo stato dei dati dell’applicazione corrente.View - sono responsabili per visualizzare/mostrare i dati.Controller - gestiscono la relazione tra Model e View.

Ora cerchiamo di capire come operano questi tre componenti in AngularJS passodopo passo.Model - in AngularJS, è costituito da tutti i tipi di dati primitivi come integer,string, boolean e tipi complessi come gli oggetti. In parole semplici il model è soloun oggetto di tipo JavaScript e può essere costruito da qualsiasi database come SQLServer, MySQL o da un file JSON. Ecco di seguito un piccolo esempio dell’oggetto$scope dove viene aggiunta la variabile di nome customer.$scope.customer = {

’Name’ : ’Jimi’,’Address ’ : ’12 -13 -283/A1’,’Email’ : ’[email protected]’

}

View - è l’elemento DOM che viene utilizzato per visualizzare i dati. Per mostrare idati dal controller bisgona usare le espressioni nella View. Dal momento che Angula-rJS supporta il Two-Way-Binding, eventuali modifiche fatte nei dati del Model ven-gono aggiornate automaticamente nella View e viceversa. Esempio di visualizzazionedei dati del Model nella View:<P> {{ customer.Name}} </p><P> {{ customer.Address }} </p><P> {{ customer.Email}} </p>

Controller - fornisce grande controllo tra la View e il Model al fine di rendere idati secondo la richiesta e di visualizzarli nella View. La cosa più importante è che iModel risiedono all’interno del Controller. Esempio:


myApp.controller("myControllerName",function ($scope){$scope.customer = {

’Name’ : ’Jimi’,’Address ’ : ’12 -13 -283/A1’,’Email’ : ’[email protected]’

}});

2. Data-Binding BidirezionaleIl Data-Binding è la seconda funzionalità più potente di AngularJS. Permette dieliminare una buona parte di codice inutile che avreste bisogno di scrivere lato serverper la gestione dei template. Solitamente l’80% del codice di una web applicationè dedicato alla manipolazione, navigazione e all’ascolto degli eventi DOM. Il data-binding di AngularJS nasconde questo codice, permettendo di focalizzarsi sugli altriaspetti vitali della web application. Generalmente, in molti sistemi di templating, ildata-binding è presente solo in una sola direzione. Il sistema classico di templateunisce template e model nella view. Dopo questo merge, le modifiche avvenutenei componenti model e nelle altre sezioni della view non sono riportate nella viewautomaticamente. Qualsiasi alterazione fatta dall’utente nella view non sarannoriportate nel model. Questo significa, che se vogliamo mantenere sincronizzati modele view e viceversa, gli sviluppatori dovranno manipolare manualmente gli elementi egli attributi del DOM. Quando un utente fa qualsiasi modifica alla view, tale processodiventa sempre più arduo e complicato. Questo a causa del fatto che lo sviluppatoredeve interpretare le iterazioni dell’utente, facendo il merge nel model, e aggiornandoil model con qualsiasi cambiamento della view.

Figura 7: Differenza tra One-Way-Binding e Two-Way-Binding


Invece AngularJS funziona in modo differente e migliore perché sincronizza automa-ticamente i dati tra model e view e viceversa, facendo risparmiare tempo allo svilup-patore in quanto non dovrà più farlo manualmente. Questo è un piccolo esempio dibinding di un valore input al tag <h1>:<!doctype html><html ng-app="myAppName">

<head><script src="http: //code.angularjs.org/angular -1.0.0 rc10.min.js"></script >

</head><body ng-controller="myControllerName">

<div><label >Name:</label ><input type="text" ng -model="yourName" placeholder="Enter a name here"><hr><h1>Hello , {{ yourName }}!</h1>

</div></body>

</html>

3. TemplatesIn AngularJS i templates sono scritti in HTML, contengono componenti ed attributispecifici. AngularJS effettua il merge del template con le informazioni (dal model edal controller) da visualizzare nel browser con view dinamiche per l’utente.I tipi di attributi ed elementi che AngularJS utilizza sono:

Directive: Questo elemento o attributo potenzia un componente DOM esistente ovisualizza un elemento DOM riusabile.

Markup: Collega le espressioni agli elementi, utilizzando la doppia graffa {{ }}.

Form Controls: Consente di validare l’input utente.

Filter: Questo elemento formatta i dati da mostrare.

Questo è un piccolo esempio che visualizza un template con direttive e notazioni condoppia graffa.<html ng-app="myAppName">

<body ng-controller="MyControllerName">

<input ng -model="foo" value="bar"><button ng -click="changeFoo ()">{{ buttonText }}</button ><script src="angular.js"></script >

</body></html>

In una semplice web application, il template contiene direttive AngularJS, HTMLe CSS in un solo file HTML (tipo index.html). In applicazioni complesse si posso-no mostrare view differenti nella pagina principale utilizzando "partials" che sonosegmenti del template creati in file HTML differenti.

4. DirettiveLe direttive sono la funzionalità più unica, predominante e potente disponibile solo inAngularJS (almeno per ora). Permettono di creare componenti HTML personalizzatie riusabili, che possono essere utilizzati per nascondere la complessità della strutturaDOM e permettono di "decorare" alcuni elementi con comportamenti specifici. Con-sentono di estendere l’HTML permettendo di "inventare" nuove sintassi e istruendoAngularJS per incorporare le loro funzionalità nella pagina. Hanno il prefisso "ng-",saranno inserite come attributi HTML e funzionano come elementi standalone.

Queste sono le direttive più usate:

ng-app: dichiara un elemento come root dell’applicazione e tipicamente viene po-sizionata all’interno del tag <body> o <html>. Esempio <html ng-app> èsufficiente per dichiarare una pagina come applicazione AngularJS.

ng-bind: sostituisce il testo contenuto in un componente HTML con il contenuto diun’espressione, e l’aggiorna quando quest’ultima viene modificata. Può esseresostituito con la doppia graffa "{{ }}" come ad esempio:<p ng-bind="testo"></p> ≡ <p>{{testo}}</p>.

ng-controller: permette di definire una "classe" controller JavaScript per risolverele espressioni HTML.

ng-model: è simile a ng-bind, ad eccezione del fatto che è responsabile del data-binding bidirezionale tra lo scope definito nel model e nella view.

ng-repeat: permette di istanziare un template per item, con cui ciclare sulle variabilidi una collection.

ng-if: questa direttiva di if dichiarativa è usata per reinserire o eliminare un elementodal DOM, a seconda del valore true o false.

ng-hide e ng-show: consentono di mostrare o nascondere un elemento con il suocontenuto.

Di seguito un semplice esempio di direttiva, che prima si mette in ascolto di un eventoe quindi applica le modifiche richieste nel suo $scope.myModule.directive(’myComponent ’, function(mySharedService) {

return {restrict: ’E’,controller: function ($scope , $attrs , mySharedService) {

$scope.$on(’handleBroadcast ’, function () {$scope.message = ’Directive: ’ + mySharedService.message;

});},replace: true ,template: ’<input >’

};});

La si può usare in questo modo:<my-component ng-model="message"></my -component >


5. Dependency InjectionAngularJS dispone di un sistema di injection integrato che si occupa di creare com-ponenti, caricare dipendenze e di passare questi agli altri componenti se necessario.Il Dependency Injection in AngularJS permette agli sviluppatori di dichiarare comela web app è collegata. Utilizzando esso AngularJS porta i tradizionali servizi latoserver sul client. Questo alleggerisce il lavoro sul server di backend e permette diavere performance migliori. Per avere accesso ai servizi core di AngularJS, bisognasemplicemente aggiungere quel servizio come parametro. AngularJS rileverà auto-maticamente la richiesta di tale servizio e fornisce un’istanza.Ecco un piccolo esempio su come fare per utilizzare il Dependency Injection:function EditCtrl ($scope , $location , $routeParams) { //tutti i parametri dellafunzione sono delle dipendenze

// Write something here ...}

Inoltre, si possono anche definire servizi personalizzati ed usare l’injection per averlia disposizione.var myApp = angular.module(’MyAppName ’, []). //nelle [] vengono inserite leinjection di defaultmyApp.service(’serviceName ’, function () {

//Write something here ...});myApp.controller("controllerName", function ($scope , serviceName){

//Write something here ...});

6. RoutingLa maggior parte delle funzionalità di AngularJS viste fin qui sono adatte a siti Webcome ad applicazioni Web. Sebbene la differenza tra i due sia molto sottile, è ormaiconsolidata l’architettura per applicazioni Web che va sotto il nome di Single PageApplication. Una SPA viene eseguita all’interno di una singola pagina HTML: tuttele risorse necessarie alla sua esecuzione vengono caricate dinamicamente ed aggiun-te al DOM della pagina corrente. In altre parole, all’interno di una singola paginavengono caricate viste diverse in base all’interazione dell’utente con la pagina stes-sa. Questo approccio consente di creare applicazioni responsive che si avvicinano alfunzionamento delle applicazioni desktop. La transizione tra una vista e l’altra dàl’illusione all’utente di navigare tra pagine diverse dal momento che ciascuna vistaha un proprio URL, anche se in realtà tutto avviene in un’unica pagina HTML. Ilmeccanismo che consente di mappare un URL ad una vista è detto routing, in An-gularJS questo concetto avviene tramite l’oggetto di sistema $routeProvider.Il $routeProvider è configurato con l’aiuto delle funzioni when() e otherwise(). Lafunzione when() prende come parametri un percorso ed un oggetto javascript conte-nente il codice HTML della view e il relativo controller, mentre la funzione otherwise()consente di specificare il percorso a cui fa riferimento nel caso non sia stato specificatoun URL corretto.


module.config ([’$routeProvider ’,function ($ routeProvider) {

$routeProvider.when(’/path1 ’, {

templateUrl: ’angular -path1.html’,controller: ’PathController ’

}).when(’/path2 ’, {

templateUrl: ’angular -path2.html’,controller: ’PathController ’

}).otherwise ({

redirectTo: ’/defaultPath ’});

}]);

Vediamo un esempio banale per capire meglio il concetto di Single Page Application:

Supponendo di avere un’applicazione web come in figura con una barra di menu,una sidebar e un contenitore di template di pagine si ha che i primi due componentirimangono fissi, mentre l’ultimo cambia in base all’azione effettuata nella sidebarcaricando così la pagina richiesta dinamicamente. La navigazione tra le pagine quindiviene eseguita senza aggiornare sempre l’intera pagina, portando diversi vantaggi:

• Nessun ricaricamento della pagina: la SPA permette di caricare solo laparte della pagina che deve essere cambiata adattando i contenuti e la graficain maniera dinamica;

• Esperienza utente migliorata: la SPA si comporta come un’applicazionenativa, cioè veloce e reattiva;

• Capacità di lavorare offline: Se l’utente perde la connessione ad internetpuò ancora continuare il lavoro che sta facendo perché la SPA avrà già caricatotutte le pagine necessarie con i relativi componenti.


4.1.3 Comunicazione tra Client e Server

AngularJS aiuta lo sviluppatore a creare una pagina che risponda in modo efficace allerichieste del client. Supponiamo che l’utente abbia una pagina web sul proprio browsercon all’interno un link, nel momento in cui egli clicca sul link la pagina verrà caricatacompletamente visualizzando ciò che l’utente si aspetta. Questo è quello che vede l’utente,ma in realtà cosa accade dietro le quinte?Il browser fa una richiesta al web server per avere la pagina voluta, tramite URL, dal-l’utente. Il web server risponderà con un codice HTML contenente CSS e JavaScript. Ilbrowser, quindi, tradurrà i linguaggi per mostrare quello che c’è nella pagina, caricandolainteramente. A questo punto, l’utente potrebbe cliccare su un link all’interno della paginacaricata avendo così una nuova richiesta. Il web server risponderà allo stesso modo diprima senza tenere in considerazione la pagina che aveva caricato precedentemente.Ovviamente, una gestione simile non è né efficiente, né, tanto meno, responsive.Cosa accade se la pagina richiesta viene scritta tramite AngularJS?Quello che vedrà l’utente sarà un caricamento più rapido, o meglio il caricamento saràpressochè impercettibile. Quando l’utente effettua una prima richiesta per una pagina,vengono effettuate le stesse azioni viste in precedenza, cioè il browser inoltra la richiestaal web server che risponde con un insieme di codici HTML contenente CSS e JavaScript.Il browser caricherà l’intera pagina e la mostrerà. Ma quando l’utente poi clicca su unlink all’interno della pagina caricata, succede qualcosa di differente rispetto a prima: ilweb server risponderà con un file JSON che, anziché far ricaricare interamente la pagina,riprenderà il caricamento fatto precedentemente, in seguito alla prima richiesta. Quin-di grazie ad AngularJS abbiamo una specie di caching fatto automaticamente tramite ilcodice con cui la pagina web è stata creata.

Figura 8: Richiesta del browser, risposta del web server


4.2 Integrazione di AngularJS in SiTemplateMVC

Dopo l’accenno appena fatto su AngularJS vedremo come integrarla al progetto SiTempla-teMVC, in particolare si vedranno le View contenenti i dati manipolati dal Controller chepermettono all’utente di interagire con il programma. Quindi vedremo tutte le problema-tiche di "rendering" in modo appropriato alle caratteristiche specifiche di ogni device deicontenuti generati dal "model" in base ai comandi interpretati dal controller.

4.2.1 Nuova Architettura SiTemplateMVC

Figura 9: Nuova Archittetura SiTemplateMVC con AngularJS

La nuova architettura di SiTemplateMVC cambia di poco rispetto alla vecchia versionegià descritta nel paragrafo 3.3. Qui si nota l’aggiunta del Framework AngularJS tra laView ed il Controller, questo collegamento permette ad Angular di elaborare i dati cherichiederà al server tramite il suo Service passando dal Controller e di modellare tali datiin modo che si possano usare facilmente nella View. Sarà il Two-Way DataBinding che sioccuperà poi di gestire gli aggiornamenti in entrambe le direzione (tra View e AngularJS)prima che essi vengano trasformati in oggetti JSON e poi mandati al Server.

4.2.2 Struttura architetturale delle View

Nella cartella Views1sono state create delle sottocartelle, una per ogni voce del menu.All’interno di queste ultime vi sono presenti file con estensione .cshtml che rappresentanole View vere e proprie. Ci sono anche altre sottocartelle particolari come ad esempioshared che contiene pagine con la stessa estensione condivise per l’intero progetto. Lesottocartelle con nomi corrispondenti alle voci del menu hanno un Controller ASP.NETMVC che interagisce tra il Model e la View in modo da mappare ogni modello alla viewcorrispondente. La figura sottostante mostra la struttura della cartella Views:

1Cartella creata da Visual Studio all’inizio del progetto una volta scelta la modalità MVC.


Figura 10: Struttura della Cartella Views

4.2.3 Le View prima dell’integrazione di AngularJS

Prima di parlare dei cambiamenti avvenuti con AngularJS vediamo come le View eranostate create in modo da capirne le differenze e le problematiche legate alla responsiveness,ovvero alla compatibilità con ogni tipo di device.Le pagine che sono all’interno delle View corrispondenti ad ogni voce del menu si occupanodelle operazioni CRUD (Create Read Update Delete), infatti sono stati nominati in basealle azioni/operazioni che devono svolgere quando vengono visualizzate. Da questo puntoin poi si farà riferimento ad una sola voce del menu (Istituto) in quanto le altre sonogenerate tramite un generatore di codice sfruttando quest’ultima. Lo stesso generatoreviene usato per la nuova versione con AngularJS, ma verrà accennato più avanti. Oravediamo la struttura della View Istituto facendo una piccola analisi dei file al suo interno.

Figura 11: Struttura della Cartella Istituto


Ogni file è composto con una parte di HTML che visualizza la pagina stessa ed una diScript per maneggiare i suoi eventi. La prima parte è stata creata inserendo ogni compo-nente in una o più tabelle in modo da avere un certo ordine all’interno della pagina peradattarsi solamente alla risoluzione di un desktop, ma con questo metodo nascono diversiproblemi di responsiveness. A causa di questa modalità nel momento in cui si cambiadispositivo i componenti non riescono ad adeguarsi al device sulla quale devono essere vi-sualizzati.

Ad oggi ogni nuovo cliente richiede una versione multidevice del proprio sito web ebisogna essere sicuri che il contenuto sia adeguato a tutte le risoluzioni: così ci si ritrovaa realizzarne una versione per iPhone, una per iPad, una per Blackberry, un’altra perAndroid e così via. In questo modo si rischia di protrarre i lavori all’infinito per riuscire afar sì che le soluzioni sviluppate siano adatte ad un gran numero di piattaforme sul mercato.Inoltre per molti siti web, l’opzione di creare diversi layout tanti quanti sono i devices daiquali gli utenti potrebbero accedervi sarebbe impossibile o almeno poco pratico. Dunquecome si può fare a risolvere questa situazione? La risposta è: Responsive Web Design.

4.2.4 Responsive Web Design

Il Responsive Design, o Design Reattivo, è una tecnica molto diffusa ed utilizzata dalMaggio 2010 grazie ad Ethan Marcotte. Questo approccio alla progettazione dei siti webprevede una collaborazione tra design e sviluppo seguendo le abitudini degli utenti basatesu orientamento, misura dello schermo e piattaforma di utilizzo. Esso consiste in un mixdi layout ed immagini flessibili dati da un uso intelligente dei CSS. In questo modo il sitoweb avrà la capacità di adattarsi automaticamente alle diverse misure degli schermi deidevices dai quali l’utente effettuerà l’accesso.I fattori per far sì che il nostro sito web sia responsive sono principalmente quattro:

1. Metatag Viewport: viewport rappresenta la superficie su cui viene disegnata lapagina web, ciò non vuol dire che corrisponda alla risoluzione del display perché pertutti gli smartphone il suo valore è di circa 1000 pixel, in modo che la maggior partedei siti web esistenti non ancora responsive riescano ad essere visualizzati sull’interapagina senza dover scrollare orizzontalmente, anche se ovviamente si vedranno mol-to piccoli. Per rendere una pagina responsive come prima cosa dobbiamo scriverenell’head il seguente codice:


<head><meta name="viewport" content="width=device -width">

</head>

In questo modo assegneremo al viewport esattamente la larghezza del device sullaquale la pagina verrà visualizzata, però sarà il programmatore ad occuparsi di otti-mizzare i contenuti e non avrà bisogno di nessun adattamento come quello appenadescritto.

2. Griglia Layout Flessibile: consente una revisione completa in termini di propor-zioni, facendo sì che tutti gli elementi in un layout vengano ridimensionati in relazionel’uno con l’altro quando ci si sposta tra differenti devices assicurandosi che il nostrosito mantenga sempre un aspetto gradevole.

3. Media Queries: è una funzionalità dei CSS3 che permette di porre delle condizioniin base alle quali un blocco di regole CSS può essere applicato o meno in funzionedella larghezza delle dimensioni del viewport. In questo modo manteniamo inalteratoil codice HTML delle pagine e agiamo su fogli di stile per assegnare regole diverse inbase al dispositivo dal quale si sta navigando, ad esempio nascondendo un elementoche abbiamo deciso di non far visualizzare solo sugli smartphone. Tipicamente siprendono in considerazione tre versioni del layout: smartphone, tablet e desktop, diconseguenza avremo almeno due media query, supponendo che il desktop non abbiabisogno di CSS specifici. Ognuna di queste media query potrebbe poi essere sdoppiatain base all’orientamento portrait o landscape, i valori di larghezza da utilizzare nellequery sono più o meno standard anche se non mancano le eccezioni. Un piccoloesempio d’uso è il seguente:@media (min -device -width : 320px) and (max -device -width : 480px) {/* Smartphone */}

@media (min -device -width : 768px) and (max -device -width : 1024px) {/* Tablet */}

4. CSS: servono all’adattamento del layout. Solitamente si ragiona in termini per-centuali, adattando così il layout a qualunque risoluzione facendo in modo che glielementi si adattino di conseguenza. Questo concetto unito alle media queries rap-presenta quasi tutto ciò che occorre per partire con i nostri primi siti responsive. Sead esempio abbiamo una pagina che su desktop presenta tre colonne di contenuto,ognuna di esse avrà una larghezza del 33.333%, quando si passa su smartphone, conl’opportuna media query potremmo settare la dimensione di tutte e tre le colonne al100% in modo che occupino tutta la larghezza del device e si dispongano una sottol’altra.


Il Responsive Design quindi porta con sé una vera e propria rivoluzione per ciò cheriguarda la progettazione: da una parte toglie le problematiche relative alla creazionedi infinite versioni dei siti web, dall’altra invece fa sì che già in fase creativa si tenda adecidere quali siano gli elementi che possano far parte della pagina e quali invece possiamoe dobbiamo fare a meno perché tendenzialmente ridondanti e scomodi alla visualizzazione.

4.2.5 AngularJS e Bootstrap

AngularJS e Bootstrap rappresentano due delle soluzioni per il web più largamente diffuseal mondo oggigiorno. Il primo abbiamo già visto di cosa si tratta, mentre il secondo è unframework CSS che riesce a velocizzare di gran lunga lo sviluppo di interfacce. Spesso neiprogetti vengono usati insieme perché sono entrambi dei tools molto potenti che hannocambiato il modo in cui CSS e JavaScript lavorano in front-end, ma spesso suscitanoperplessità a causa della gestione delle dipendenze di cui hanno bisogno. Per questo nasceil progettoUI Bootstrap contenente un set di direttive native per AngularJS che mettonoa disposizione le funzionalità di Bootstrap. In questo modo non sono richieste dipendenzecome jQuery o i file Javascript di Bootstrap, ma solo il Framework AngularJS ed i foglidi stile di Bootstrap.Per usare UI Bootstrap nel proprio progetto bisogna inserirlo nel modulo di AngularJScosì:angular.module(’myModule ’, [’ui.bootstrap ’]);

Ora si possono utilizzare tutte le sue direttive integrando velocemente le nuove interfaccenelle applicazioni basate su AngularJS come vedremo successivamente nel progetto Si-TemplateMVC. Però prima è necessario dire due parole sulla Griglia Layout Fluibile diBoostrap3 perché sarà "l’impalcatura" fondamentale sulla quale si baserà la trasforma-zione del progetto e quindi sarebbe opportuno approfondire il suo funzionamento. Persfruttare questa griglia è bene tener presenti tre concetti:

• Essendo una griglia dobbiamo ragionare sul layout distribuendolo per colonne e righe;

• La griglia è composta da 12 colonne strutturali, per cui bisogna fare in modo che i varielementi del layout si distribuiscano su di esse in modo opportuno. Ogni elementopuò occupare una o più colonne della griglia. La somma totale delle colonne dellagriglia su cui si estendono in larghezza gli elementi del layout non può superare12. Se le colonne occupate dal layout sono meno di 12, viene lasciato dello spaziovuoto. Questo significa che, se desidero creare, ad esempio, un layout composto datre colonne tutte uguali e occupare tutto lo spazio disponibile in larghezza, ciascunadelle colonne del mio layout si dovrà estendere su 4 colonne della griglia (4x3=12).Ma se si vuole una colonna centrale più larga, si potrebbero espandere la prima e laterza colonna del layout su due colonne della griglia e quella centrale su otto colonne(2+8+2=12).

• Ogni riga può avere un numero di colonne diverso e un’estensione sulle colonne dellagriglia diverso.


Figura 12: Boostrap Grid System

Questo sistema ha 4 classi:

1. xs (extra-small) per le dimensioni degli smartphone

2. sm (small) per le dimensioni dei tablets

3. md (medium) per le dimensioni dei desktop

4. lg (large) per le dimensioni dei large desktop

Le classi vengono usate singolarmente o combinate e servono per creare layout più dinamicie flessibili.

4.2.5.1 Le nuove View dopo la loro integrazioneCome prima cosa bisogna prendere e modificare tutte le pagine dove vorremmo utilizzarei dati con AngularJS. In questo paragrafo si esaminano le opportunità che danno i com-ponenti Bootstrap in jQuery e AngularJS per ottenere gli stessi obbiettivi ed osservandobene le differenze tra loro.Come visto in Figura 11 vi erano presenti 5 file che creano la View, ma con l’integrazione diAngularJS diventeranno 4 perché il codice di Istituto_Inquiry_Overview verrà incorporatoall’interno di Istituto_Inquiry. Il resto della struttura rimane identica, ma ora vediamoogni singola pagina nel dettaglio.

Istituto_Inquiry Questa è la pagina principale che viene visualizzata al momento delclick sulla voce del menu. È composta da diverse parti, precisamente 3:

1. Query-Filter: l’utente può richiedere i dati secondo dei filtri specifici oppurerichiedere tutti i dati. Questa è l’unica parte che non è stata modificata secondoAngularJS.


2. Grid: viene usato l’oggetto ui-grid per creare una griglia di visualizzazione deidati. Per poterlo usare nella View bisogna incorporare il seguente codice:<div ui-grid="gridOptions" ui -grid -selection ui-grid -paginationexternal -scopes="$scope" class="ui -grid">

<div class="watermark" ng -show="!gridApi.grid.options.totalItems">Nessun datodisponibile </div></div>

ng-show ci permette di visualizzare un messaggio nel caso in cui non ci sianodati disponibili.Tramite il Controller legato alla View si possono settare i suoi parametri e darecosì un certo aspetto e sapere quali dati visualizzare. Al di sopra dalla griglia cisono: due bottoni, che servono per scaricare i dati visualizzati in formato PDFe Excel, un menu a tendina che serve per nascondere e rivisualizzare ciascunacolonna della Grid.

3. Overview: vengono visualizzati sole le informazioni principali una volta sele-zionato un elemento della Grid. In basso a sinistra vi è presente un bottone chepermetterà di aprire il tab "Dettagli".


Istituto_Detail Questa è la pagina che visualizzerà tutti i dati dell’elemento selezio-nato nella Grid della pagina precedente. Essi sono forniti tramite il Controller diAngularJS e vengono stampati come segue:<div class="row">

<div class="col -sm -6 col -xs -12"><p>Codice Ced: <b ng -bind="detailIstituto.CED"> </b> </p><p>Codice Abi: <b ng -bind="detailIstituto.ABI"> </b> </p><p>Codice Bic: <b ng -bind="detailIstituto.BIC"> </b> </p><p>Descrizione Ridotta: <b ng -bind="detailIstituto.DESCR_RIDOTTA"> </b>

</p><p>Descrizione Estesa: <b ng -bind="detailIstituto.DESCR_ESTESA"> </b> </p>

</div><div class="col -sm -6 col -xs -12">

<p>Flag Estinto: <b ng-bind="detailIstituto.ESTINTO_DECODED"> </b> </p><p>Rif. Inserimento: <b ng-bind="detailIstituto.INFO_INSERIMENTO"> </b>

</p><p>Rif. Aggiornamento: <b ng -bind="detailIstituto.INFO_AGGIORNAMENTO">

</b> </p></div>

</div>

Da come si vede in figura in basso alla pagina ci sono tre bottoni: il primo serve peraprire il tab "Modifica", il secondo per eliminare l’elemento visualizzato e il terzoper stampare gli stessi dati in formato PDF. Prima di cancellare completamente ildato, l’utente ha la possibilità di confermare l’azione che sta eseguendo tramite unmessaggio di alert in modo tale da evitare eventuali cancellazioni sbagliate.I bottoni sono stati gestiti in modo che cambiano in base al device utilizzato: nel casodel Desktop viene visualizzata una scritta che indica l’operazione, mentre per Smart-


phone e Tablet viene visualizzata un’icona appropriata (come nella figura mostrata).Per realizzare tutto ciò si sfrutta la variabile $scope.mobile presente nel Controller diAngularJS come nel codice seguente:<div class="row">

<div class="col -md -2" ng-if="!mobile">

<button class="btn btn -warning btn -lg" ng-click="updateIstituto ()">Modifica </button >

</div><div class="col -md -2" ng-if="!mobile">

<button class="btn btn -danger btn -lg" ng -click="deleteIstituto ()">Elimina </button >

</div><div class="col -md-offset -6 col -md -2" ng -if="!mobile">

<button class="btn btn -success btn -lg" ng-click="printIstituto ()">Stampa </button >

</div>

<div class="col -xs -4" ng-if="mobile"><button class="btn btn -warning btn -sm" ng-click="updateIstituto ()">

<span class="glyphicon glyphicon -edit"></span></button >

</div><div class="col -xs -4" ng-if="mobile">

<button class="btn btn -danger btn -sm" ng -click="deleteIstituto ()"><span class="glyphicon glyphicon -trash"></span>

</button ></div><div class="col -xs -4" ng-if="mobile">

<button class="btn btn -success btn -sm" ng-click="printIstituto ()"><span class="glyphicon glyphicon -print"></span>

</button ></div>

</div>

Istituto_Insert Questa è la pagina che permette di inserire un nuovo Istituto. Al suointerno vi sono presenti diversi campi input che tramite l’attributo ng-model di An-gularJS associa il Model con la View sfruttando la proprietà Two Way Data Biding.Questo significa che non dovremmo più usare l’attributo method del form di HTMLper inviare i dati al server. AngularJS poi ci offre anche la validazione dei form alato client controllando lo stato del form e dei campi input in modo da poter notifi-care all’utente in caso di errore. Ci sono diversi stati sia per il form che per l’input:$pristine, $dirty, $invalid, $valid per entrambi, in più il form ha $submitted el’input ha $untouched, $touched.

Istituto_Update La pagina di modifica è uguale a quella dell’inserimento a differenza delfatto che qui vengono settati i campi d’input con i dati della pagina Istituto_Detaildescritta precedentemente. Nel caso in cui l’utente sbagliasse le modifiche o cancel-lasse i dati nei campi ha la possibilità di ripristinarli tramite il tasto reset che setta icampi con i dati inizialmente visualizzati. Vengono effettuati anche qui gli stessi con-trolli di validazione della pagina Istituto_Insert soltanto per gli input modificabili.

Concludiamo questo paragrafo con una breve descrizione della pagina Autorizzazioneche sta sotto la voce del menu "Impostazioni". La sua struttura è diversa rispetto a quelledescritte precedentemente perché per ogni operazione svolta dall’utente i dati verrannovisualizzati nella pagina stessa e non tramite tab. Questa pagina permette di gestirel’accesso alle voci del menu per ogni utente che può accedere al sito. Tale gestione avvienetramite una lista di Entità che fanno riferimento alle voci del menu alle quali l’utente puòaccedervi. Per ogni Entità selezionata verranno visualizzate le Action ossia le azioni che


l’utente può compiere. Poi ci sono tre tipi di autorizzazione per ogni Action: abilitato,non abilitato o limitato e per quest’ultimo si può definire un numero preciso di giorni peril quale l’autorizzazione sarà valida.Gli inserimenti, le modifiche e le cancellazioni sia per le Entità che per le Action vengonofatti tramite dei popup in modo tale da non aprire diversi tab. È stata utilizzata lastessa logica di AngularJS e Bootstrap per la creazione della Grid, la visualizzazione deidati dell’Entità selezionata e il posizionamento dei componenti sfruttando le regole dellaresponsiveness.

4.2.5.1.1 Menu e FooterLa vecchia versione di SiTemplateMVC aveva un menu e un footer pieni di informazionisparse e ognuna di essi veniva posizionata attraverso diverse tabelle in cascata. Nel menuoltre al logo del sito vi sono presenti le voci del menu, un controllo delle sessioni aperte sottoforma di semaforo e le informazioni riguardanti l’operatore stesso e i dati dalla Banca dallaquale ha effettuato l’accesso, mentre nel footer ci sono le pagine aperte in base alle vocidel menu cliccate, il tool usato per la costruzione del sito e il logo di SiGrade. Tutti questielementi e il modo in cui sono stati posizionati rendevano ancora più difficile visualizzareil sito in altri dispositivi con risoluzioni diverse.Nella nuova versione il menu contiene sempre il logo del sito con le voci del menu, male altre informazioni sono state raggruppate in una nuova voce "Info" che al suo internoha due sottomenu: "Istituto" e "Utente" che permettono di visualizzare le informazionicorrispondenti attraverso un popup. A differenza del menu precedente la disposizionedelle informazioni cambia in base alla risoluzione del dispositivo, ad esempio nel casodello Smartphone tutte le voci del menu vengono raggruppate in un tasto sotto forma diuna lista dropdown. Il footer invece contiene sempre le pagine aperte ed il semaforo, mase la risoluzione del dispositivo supera una certa soglia le prime vengono racchiuse in unbottone in modo da visualizzarle attraverso un popover scorrevole. Ora mostriamo i diversicambiamenti appena descritti in base anche alla risoluzione dei dispositivi:


Figura 14: Confronto Menu e Footer tra vecchia e nuova versione2015 - 2016 46 Veronica Petrone

4.2.5.1.2 Diagramma di Navigazione

4.3 Generatore di codice

Come già accennato nei capitoli precedenti è stato utilizzato un generatore di codice percreare le Views di AngularJS sfruttando quello della pagina Istituto come modello "tem-plate". Con generatore di codice si intende il processo di "software che crea software" edè ideale per la creazione di codice in base a processi ripetibili. Ogni volta che si prendein considerazione questo tipo di processo bisogna guardare il motivo per cui viene fattae vedere se è possibile risolvere il problema con altri mezzi. Alcuni dei casi in cui si puòutilizzare la generazione di codice sono: la creazione di oggetti che rappresentano entitàe la loro persistenza in un repository (database CRUD) o la creazione di controlli dell’in-terfaccia utente orientata verso la manutenzione dei dati. Un classico esempio è l’accessoai dati: si potrebbero generare 250 classi, 1 per ogni tabella nello schema oppure costrui-re qualcosa di più simile ad un modello di dominio ed utilizzare un Object-RelationalMapping (ORM) per mappare un ricco modello di dominio sul database. Entrambe lesoluzioni sono effettivamente generatori di codice, ma la differenza sostanziale è quandoviene generato il codice. Con ORM è un passo implicito che accade in fase di esecuzione,mentre con la soluzione elaborata a mano è un passo esplicito che accade durante lo svi-luppo introducendo l’attrito nel processo portando spesso a codice che potrebbe violare ilDRY (Don’t Repeat Yourself). L’utilizzo del generatore di codice porta diversi vantaggi:


X Imporre norme / Convenzioni - viene rimosso il processo di sviluppo ripetibilea mano, ma il generatore comunque segue delle regole/convenzioni imposte daglisviluppatori;

X Velocità - permette di velocizzare il processo di sviluppo di un software;

X Riproducibilità - conveniente per sviluppi futuri di nuovi software senza doverricominciare da capo;

X Meno errori - se viene identificato un errore durante la fase di test per correggerlobasta solo modificare il "template" e rigenerare nuovamente tutte le altre paginein modo che la correzione si propaga in esse. Mentre se fosse stato fatto a manobisognerebbe andare a modificare una pagina alla volta e questo processo richiedepiù tempo e potrebbe causare altri errori;

X Risparmio di tempo - permette di non trascorrere ore/giorni/settimane sullacreazione di qualcosa che si può creare in pochi secondi/minuti;

Il generatore di codice usato in questo progetto è stato realizzato dall’azienda ed essen-do un prodotto con diritti di privacy non si può dare una spiegazione dettagliata, però vienefatto un breve accenno sulla sua funzionalità. Inizialmente legge lo schema del database egli attributi necessari tramite un file Excel creando il vero e proprio database. Successiva-mente ogni volta che si ha bisogno di aggiornare il modello di dominio o effettuare piccolemodifiche sugli attributi delle entità non bisogna toccare il database, ma solo il file Excelperché il generatore in automatico percepisce le modifiche avvenute nel file e le riporta neldatabase. Alla fine del processo l’output generato è composto da diverse cartelle tra cuile views, gli scripts, i model ed i controller. Per evitare di rigenerare tutte le cartelle ognivolta che si apportano modifiche su file specifici, come ad esempio le views riscritte conAngularJS in questo caso, basta aggiungere dei parametri al Main del generatore in mododa generare solo la parte in cui tale modifiche sono state effettuate.

4.3.1 Test su più device

Nel campo dello sviluppo software il testing o collaudo è un procedimento di verifica dellequalità di correttezza, completezza e affidabilità di un software. Esistono due tipologiedi test, l’Alfa testing e il Beta testing. Solitamente l’Alfa testing viene svolto interna-mente all’azienda che sviluppa il software e permette di ridurre il numero di bug presenti,mentre il Beta testing viene svolto direttamente dal committente del software o da uncampione rappresentativo dell’utenza che userà il software ed è la fase fondamentale perdefinire se il software è conforme alle esigenze richieste. Nel nostro caso l’Alfa testing èstata svolta tramite il simulatore di Google durante lo sviluppo del software in modo davedere la disposizione dei componenti delle Views su vari dispositivi (smartphone, tablet,desktop), mentre il Beta testing è stato svolto da alcuni dipendenti interni all’azienda suiloro dispositivi fisici dopo aver effettuato l’importazione del sito su un server dell’azienda.


5 Conclusioni e Sviluppi futuri

Concluso lo stage presso l’azienda SiGrade sono stati raggiunti gli obiettivi proposti, ovverola possibilità di trasformare un software bancario, realizzato con Jquery-based, con uno deimigliori Framework di ultima generazione ed integrare tale software con il mondo mobileo web responsive. Il lavoro svolto mi ha permesso di comprendere il mondo del software alivello bancario, ma ciò è solo una parte della lezione appresa perché quello che ha portatomaggior profitto ed interesse è stato comprendere i nuovi orizzonti di sviluppo software.Oggi ci troviamo in un momento in cui ogni giorno vengono sviluppati migliaia di software,ma quanti di questi possono essere ritenuti affidabili e di buona qualità? La risposta cambiada azienda ad azienda, ciò che al momento per loro conta di più è che vengano rispettati itempi prestabiliti di consegna, ma potrebbe comportare un grave danno se viene consegnatoun software obsoleto a causa del poco tempo a disposizione per l’analisi di sviluppo e test.Quindi i compiti principali di una Software House sono di:

• gestire al meglio i rapporti con i propri clienti;

• dare importanza alle proprie risorse;

• essere quanto più chiari e limpidi nella produzione, gestione e sviluppo di un nuovosoftware nei confronti del proprio cliente;

• poter intervenire per tempo a modifiche e miglioramenti evitando la consegna di unprodotto non idoneo.

Durante i mesi di stage mi sono occupata del front-end rendendolo soprattutto responsi-veness, ho utilizzato .NET che mi ha permesso di lavorare con l’accesso alle base di dati inmaniera molto semplice e a mio avviso ben pulita facilitando la fase di implementazionedel progetto con l’utilizzo del design pattern MVC. Ho imparato un nuovo linguaggio (C#)e ho acquisito una certa esperienza professionale e di qualità nello sviluppo di software digrandi dimensioni. Inoltre ho appreso che il generatore di codice è uno strumento moltopotente ed utile per chi vorrebbe velocizzare ed ottimizzare al meglio il proprio software ofuturi software simili.

Alcune delle possibili espansioni future possono essere:

1. Integrare il nuovo Boostrap 4 che uscirà a breve

2. Rendere il design più rivolto verso il mobile con l’utilizzo di angular-material

3. La possibilità di rendere il menu scorrevole nel caso vengano aggiunte nuove pagine


Riferimenti bibliografici

[1] ISTAT, "Cittadini e tecnologie"

[2] Politecnico di Milano, "School of Management"

[3] ABI, "4◦Osservatorio sul mobile banking"

[4] AbiLab del Politecnico di Milano, "Mobile banking: un’app per tutti"

[5] Dispense di Giulio Destri e Corrado Lombardi:http://www.slideshare.net/giuliodestri/d06-storia-svilupposoftwarehttp://www.slideshare.net/giuliodestri/i-processi-di-sviluppo-software-levoluzione-agile-ed-il-devops

[6] Wikipedia, "Automazione del collaudo del software"https://it.wikipedia.org/wiki/Automazione_del_collaudo_del_software

[7] HTML.it, "AngularJS è un framework, non una libreria!"http://www.html.it/pag/52588/angularjs-e-un-framework-non-una-libreria/

[8] Le principali caratteristiche di AngularJS:http://www.techstrikers.com/AngularJS/angularjs-routing.phphttp://www.html.it/pag/53894/single-page-application-e-routing-in-angularjs/http://www.powerpad.it/c/55835/6764/angularjs–guida-introduttiva.html

[9] Documentazione ufficiale AngularJS:https://angularjs.org/

[10] Nozioni jQuery: http://jquery.com/

[11] SiGrade: http://www.sigrade.it/

[12] Giulio Destri "Sistemi Informativi. Il pilastro digitale di servizi ed organizzazioni"Ed.FrancoAngeli, 2013

[13] IIBA "Business Analyst Body of Knowledge (BABoK)"

[14] Responsive Web Design:http://www.tlcws.com/blog/responsive-web-design-il-futuro-mobile-del-tuo-sito.htmlhttp://www.codelabstudio.it/come-rendere-responsive-un-sito-web/http://abstract.it/lab/articles/il-futuro-del-web-e-responsive


UNIVERSITÀ DEGLI STUDI DI PARMA - cs.unipr.it · In questo contesto si inserisce questa Tesi, il...

Documents

Transcript of UNIVERSITÀ DEGLI STUDI DI PARMA - cs.unipr.it · In questo contesto si inserisce questa Tesi, il...