theses - Barbiana 2.0 - Università degli Studi Mediterranea

Transcript

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e dell’Energia Sostenibile
Corso di Laurea in Ingegneria dell’Informazione
Tesi di Laurea
Progettazione e implementazione di un’app iOS che
funga da front-end ad un sistema client-server per supportare il medico di base nelle diagnosi sulle anemie
1
Relatori
Candidato
Prof. Domenico Ursino
Prof. Pasquale Iacopino
Alfonso Martino
Anno Accademico 2013-2014
1
A tutti coloro che mi hanno supportato durante questo
percorso.
1
1
Progettazione e implementazione di un’app iOS che funga da front-end ad un ...
INTRODUZIONE
L’anemia (dal greco αναιμία, senza sangue) comporta, come effetto finale, la riduzione della massa eritrocitaria totale e/o del contenuto emoglobinico del sangue circolante, causa di sofferenza ipossica ai vari organi, che si manifesta con segni e sintomi di varia natura. La molteplicità dei fattori etiologici delle anemie implica una diagnostica mirata e un trattamento specifico, come la rimozione delle cause o l’apporto di fattori carenziali. Le anemie sono classificate in quattro macro gruppi:
1.
2.
3.
4.
ridotta eritroblastogenesi;
ridotta eritrogenesi; ridotta sintesi emoglobinica;
ridotta sopravvivenza eritrocitaria (emolisi).
Ciascuno di questi quattro gruppi presenta, a sua volta, delle sotto classificazioni. Le componenti interessate nella classificazione di uno stato anemico che devono essere prese in considerazione sono:
midollo osseo;
reticolociti;
eritrociti;
1
MCV;
emolisi.
L’esame che ci permette di quantificare parte di queste componenti è l’emocromo; con l'esecuzione dell'emocromo si quantifica il numero dei globuli rossi, e delle altre cellule del sangue (globuli bianchi e piastrine), l'ematocrito e la quantità dell'emoglobina totale. Altri test utili sono il dosaggio del ferro (sideremia), della transferrina e della ferritina. A causa della molteplicità dei fattori da considerare per la diagnostica delle anemie è nata l’idea di sviluppare un’applicazione, di supporto al medico di base, in grado di restituire Alfonso Mar no | 1
un risultato in base agli input, ovvero ai valori dell’emocromo, ricevuti in ingresso. Il risultato che verrà stampato sull’applicazione è ottenuto da un algoritmo creato secondo gli schemi forniti da ARUP Consult® che si basa sulla classificazione delle anemie e può essere di tre tipi:
1.
2.
3.
una diagnosi definitiva;
la prescrizione di un altro esame necessario per completare la diagnostica;
un suggerimento sulle possibile cause dell’anemia.
C’è da precisare che la corretta diagnosi dell’ anemia si integra con la valutazione di segni e sintomi e dell’esame obbiettivo del paziente. Inoltre la diagnostica avanzata prevede, come primo step, l’esame dello striscio periferico; e, in alcune forme è indicato un esame più invasivo, ovvero il puntato midollare. La presente applicazione vuole essere un supporto al medico di base nella diagnosi dell’anemia ed ha lo scopo di semplificare e velocizzare tutti i flussi di lavoro riguardanti la gestione del paziente, partendo dalla gestione dei suoi dati fino alla valutazione degli esami. Ad ogni modo, sarà sempre necessaria una valutazione clinica del paziente da parte del medico stesso.
Il sistema iOS alla base della nostra applicazione presenta due componenti fondamentali:
client;
server.
Il client è un sistema che, oltre ad accedere ai servizi offerti dal server, possiede una struttura stratificata; possiamo, dunque, immaginarlo come una serie di strati, uno sopra l'altro, che imple-‐
menteranno determinate funzioni. Dunque, ogni strato sarà delegato a g estire e d implementa-‐
re determinate funzionalità e, in sostanza, lo strato superiore beneficia dei servizi offerti dallo strato inferiore senza, però, saperne la logica implementativa.
In questo contesto si può, quindi, parlare di client riferendosi sia all'hardware che al software. Il client utilizzato assume molteplici forme in quanto l’applicazione sarà fruibile su due diverse 2 |Alfonso Mar
no Progettazione e implementazione di un’app iOS che funga da front-end ad un ...
piattaforme mobile Apple, ovvero:
1.
2.
IPad;
IPhone.
Il server è stato implementato per semplicità di utilizzo, qualità del codice e diffusio-‐
ne attraverso l’accoppiata PHP e MySQL .
PHP è conosciuto come Hypertext Preprocessor, ed è un linguaggio completo di scripting, sofisticato e flessibile, che può girare praticamente su qualsiasi server Web e su qualsiasi sistema operativo; esso prevede una stretta interazione con MySQL. In questo caso sono presenti dei Web Service implementati attraverso PHP 5 che svolgono due funzioni fon-‐
damentali:
1.
2.
1
elaborazione dei dati provenienti dall’applicazione ;
elaborazione dei dati presenti sul DBMS stesso.
Un aspetto fondamentale del sistema è rappresentato dalla comunicazione client-server.
La soluzione implementata per gestire lo scambio dei dati è il protocollo JSON. Tale protocollo viene utilizzato tramite JavaScript e permette di trasmettere dati dal client al server, e viceversa (operazione di parsing), attraverso una semplice chiamata ad una funzione. La tesi è strutturata come di seguito specificato:
Nel primo capitolo saranno descritte le tecnologie utilizzate per lo sviluppo dell’ap-‐
plicazione, ovvero HTML5 e Apache Cordova. Verranno, inoltre, illustrate le caratte-‐
ristiche principali, le funzionalità e l’implementazione.
Alfonso Mar no | 3
Il secondo capitolo si concentrerà sulle anemie, esponendone la classificazione e le possi-‐
bili cause. Verranno analizzate, inoltre, le modalità di diagnostica, le possibili complica-‐
zioni ed i trattamenti effettuabili.
Nel terzo capitolo verrà definita l’architettura del sistema complessivo e verrà svolta l’analisi dei requisiti. Verrà, quindi, individuata la migliore soluzione implementativa, descrivendo le interazioni tra i componenti presenti.
Nel quarto capitolo verrà trattata la progettazione dell’applicazione. Si delineeranno, quindi, la sua mappa, i mockup ed il workflow.
Nel quinto capitolo, il modello architetturale e l’approccio progettuale proposti verranno utilizzati per implementare l’applicazione (lato client e lato server); sarà, inoltre, realizza-‐
to un semplice manuale utente. Verrà, infine, implementata la connettività client-server con relativo scambio di dati.
Per ultimo, verranno tratte le conclusioni e saranno delineati alcuni possibili sviluppi futu-‐
ri.
4 |Alfonso Mar
1. Le tecnologie HTML5 e Apache Cordova per iOS
In questo capitolo verranno illustrate le tecnologie utilizzate per lo sviluppo dell’applicazione. In particolare, verrà effettuata un’ introduzione a tali strumenti, spiegandone il significato e il funzionamento che hanno assunto nell’ambito della programmazione.
1 HTML5
2 JavaScript
4
5
3
JSON
1
Apache Cordova per
iOS
Xcode
Alfonso Mar no | 5
1.1 HTML5
L'HTML5 è un linguaggio di markup per la strutturazione delle pagine Web, pubblicato come W3C Recommendation a partire da Ottobre 2014. Lo sviluppo venne avviato dal gruppo di lavoro Web Hypertext Application Technology Wor-‐
king Group (WHATWG) ,fondato nel 2004 da sviluppatori appartenenti ad Apple, Mozilla Foun-‐
dation e Opera Software. Questo gruppo si pose come obiettivo quello di progettare specifiche per lo sviluppo di applicazioni Web, focalizzandosi su miglioramenti e aggiunte ad HTML e alle tecnologie correlate. Inizialmente il WHATWG si pose in contrasto con il World Wide Web Consortium per le lungaggini nel processo di evoluzione dello standard HTML e per la decisione del W3C di orientare la standardizzazione verso l'XHTML 2, che non garantiva retro compatibi-‐
lità. Successivamente lo stesso W3C ha riconosciuto valide tali motivazioni, annunciando di creare un apposito gruppo per la standardizzazione dell'HTML5 e di abbandonare l'XHTML 2.0. Dal 2007 il WHATWG ha collaborato con il W3C in tale processo di standardizzazione, per poi decidere, nel 2012, di separarsi dal processo di standardizzazione del W3C, creando, di fatto, due versioni dell'HTML5: la versione del WHATWG viene definita, come "HTML Living Stan-‐
dard", e quindi in continua evoluzione, mentre quella del W3C sarà un’ unica versione corri-‐
spondente ad uno "snapshot" del Living Standard. La prima Candidate Recommendation è stata pubblicata dal W3C il 17 Dicembre 2012, e la prima versione dello standard è stata pubbli-‐
cata come Recommendation il 28 Ottobre 2014. Il World Wide Web Consortium ha annunciato che la successiva, l'HTML 5.1 lo sarà per il 2016.
Presentando i nuovi elementi e le nuove API definite nella specifica, è necessario spendere qualche momento per parlare delle regole sintattiche introdotte dall’HTML5, per larga misura ereditate e razionalizzate dalla precedente versione delle specifiche. In primo luogo familiariz-‐
ziamo con il concetto noto di tag. Esistono tre distinte versioni di questa particella; ognuna di esse si applica selettivamente solo ad alcuni elementi: Elementi normali: sono quelli che possono racchiudere dei contenuti sotto forma di testo, di commenti HTML, di altri elementi HTML, etc. Sono elementi normali e, dunque, i para-‐
grafi (<p>), le liste (<ul>), i titoli (<h1>), etc. Salvo specifici casi, gli elementi normali ven-‐
gono definiti attraverso un tag di apertura (<p>) e un tag di chiusura(</p>). Elementi vuoti: gli elementi vuoti sono quelli che non possono avere alcun contenuto. Per questi elementi si utilizza un tag “vuoto”. Essi sono: area, base, br, col, command, em-‐
bed, hr, img, input, keygen, link, meta, param, source, track, wbr.
Elementi provenienti da altri namespace: per questi elementi sono richiesti i tag “autochiu- denti”. Si tratta degli elementi adottati da specifiche esterne, come SVG e MathML. La sintassi HTML5 si caratterizza per una spiccata flessibilità e semplicità di implementazione. 6 |Alfonso Mar
Le osservazioni che abbiamo snocciolato sono chiaramente valide a patto di implementare la serializzazione HTML; ricordiamo, infatti, che le specifiche prevedono anche l’utilizzo di una sintassi XML. L’arrivo dei <div> fu una vera e propria rivelazione; finalmente un modello di costruzione del documento pensato per separare in modo chiaro i contenuti tipici di una pagina Web. Grazie alla commistione tra questo elemento e i CSS nacquero pagine con codici eleganti e leggibili.
Alfonso Mar
no |no
7| 7
Alfonso Mar
1.2 JAVASCRIPT
In informatica JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi, comunemente utilizzato nella pro-‐
grammazione Web lato client per la creazione, in siti Web e applicazioni Web, di effetti dinamici interattivi, tramite funzioni di script invocate da eventi innescati, a loro volta, in vari modi dall'utente sulla pagina Web in uso (mouse, tastiera, etc.). JavaScript fu originariamente sviluppato da Brendan Eich della Netscape Communications con il nome di Mocha e, successiva-‐
mente ,di LiveScript; in seguito è stato rinominato "JavaScript" ed è stato formalizzato con una sintassi più vicina a quella del linguaggio Java di Sun Microsystems (che nel 2010 è stata acquistata da Oracle). JavaScript è stato standardizzato per la prima volta tra il 1997 e il 1999 dalla ECMA con il nome ECMAScript. L'ultimo standard, di mar-‐
zo 2011, è ECMA-262 Edition 5.1. JavaScript è anche uno standard ISO. Le caratteristiche prin-‐
cipali sono:
è un linguaggio interpretato: il codice non viene compilato, ma interpretato (in JavaScript lato client, l'interprete è incluso nel browser che si sta utilizzando);
la sua sintassi è relativamente simile a quella del C, del C++ e del Java;
definisce le funzionalità tipiche dei linguaggi di programmazione ad alto livello (strutture di controllo, cicli, etc.) e consente l'utilizzo del paradigma object oriented;
è un linguaggio debolmente tipizzato;
è un linguaggio debolmente orientato agli oggetti. Il meccanismo dell'ereditarietà è più simile a quello del Self e del NewtonScript che a quello del linguaggio Java (che è un linguaggio fortemente orientato agli oggetti). Gli oggetti stessi ricordano più gli array associativi del Perl che gli oggetti di Java o del C++. In JavaScript lato client, il codice viene eseguito direttamente sul client e non sul server. Il vantaggio di questo approccio è che, anche con la presenza di script particolarmente complessi, il Web server non viene sovraccaricato a causa delle richieste dei client. Di contro, nel caso di script che presenti-‐
no un codice sorgente particolarmente grande, il tempo per lo scaricamento può diventare abbastanza lungo. Un altro svantaggio è il seguente: ogni informazione che presuppone un accesso a dati memorizzati in un database remoto deve essere rimandata ad un linguaggio che effettui esplicitamente la transazione, per poi restituire i risultati ad una o più variabili Java-‐
Script; operazioni del genere richiedono il caricamento della pagina stessa. Con l'avvento di AJAX tutti questi limiti sono stati superati.
8 |Alfonso Mar
Alcune funzionalità di JavaScript degne di nota sono le seguenti:
può usare Unicode;
può valutare le espressioni regolari (introdotte nella Versione 1.2; e supportata dai browser a partire da Netscape Navigator 4 e Internet Explorer 4);
le espressioni JavaScript contenute in una stringa possono essere valutate usando la funzione eval.
A differenza di altri linguaggi, quali il C o il C++, che permettono la scrittura di programmi completamente stand-alone, JavaScript viene utilizzato soprattutto in quanto linguaggio di scripting, integrato, quindi, all'interno di un altro programma.
L'idea di base è che il programma ospite (quello che ospita ed esegue lo script) fornisca allo script un'API per richiedere l'esecuzione di operazioni specifiche, non previste dai costrutti del linguaggio JavaScript in sé. In effetti, questo è esattamente lo stesso meccanismo che viene adottato anche in un linguaggio quale il C o il Java, nel quale il programma si affida a delle librerie, non previste dal linguaggio in sé, che permettono di effettuare operazioni quali l'I/O o l'esecuzione di chiamate a funzioni di sistema.
L'esempio tipico (e, forse, il più noto) di programma ospite per uno script JavaScript è quello del browser. Un browser tipicamente incorpora un interprete JavaScript; quando viene visita-‐
ta una pagina Web che contiene il codice di uno script JavaScript, quest'ultimo viene portato in memoria primaria ed eseguito dall'interprete contenuto nel browser.
Le interfacce che consentono a JavaScript di rapportarsi con un browser sono chiamate DOM (Document Object Model, in italiano Modello a Oggetti del Documento). Molti siti Web usa-‐
no la tecnologia JavaScript lato client per creare potenti applicazioni Web dinamiche.
Un uso principale del Javascript in ambito Web è la scrittura di piccole funzioni integrate nelle pagine HTML che interagiscono con il DOM del browser per compiere determinate azioni non possibili con il solo HTML statico; tra queste azioni citiamo il controllo dei valori nei cam-‐
pi di input, il mascheramento o la visualizzazione di determinati elementi, etc. Sfortunata-‐
mente, gli standard DOM imposti dal W3C non sempre vengono rispettati dai vari browser: browser diversi (anche a seconda del loro motore di rendering) espongono diversi oggetti o metodi allo script (Internet Explorer è solito aderire agli standard con piccole modifiche, e tratta, ad esempio, l'oggetto event come globale; Opera non supporta le funzioni alert() e confirm()); è, quindi, spesso necessario implementare controlli aggiuntivi ad una funzione JavaScript, per garantirne la compatibilità con ciascun browser.
Al di fuori del Web, interpreti JavaScript sono integrati in diverse applicazioni. Adobe Acrobat e Adobe Reader supportano JavaScript nei file PDF. La piattaforma Mozilla, che è alla base di molti diffusi browser Web, usa JavaScript per implementare l'interfaccia utente e la logica di transazione dei suoi vari prodotti.
Alfonso Mar no | 9
1.3 JSON
JSON, acronimo di JavaScript Object Notation, è un formato adatto per lo scambio dei dati in applicazioni client-server.
È basato sul linguaggio JavaScript Standard ECMA-262 3ª edizione dicembre 1999, ma ne è indipendente. Viene usato in AJAX come alternativa a XML/XSLT.
La semplicità di JSON ne ha decretato un rapido utilizzo specialmente nella programmazione in AJAX. Il suo uso tramite JavaScript è particolarmente semplice; infatti l'interprete è in grado di eseguirne il parsing tramite una semplice chiamata alla funzione eval(). Questo fatto lo ha reso velocemente molto popolare a causa della diffusione della programmazione in JavaScript nel mondo del Web.
I tipi di dati supportati da questo formato sono:
booleani (true e false);
interi, reali, virgola mobile;
stringhe racchiuse da doppi apici ( " );
array (sequenze ordinate di valori, separati da virgole e racchiusi in parentesi quadre [ ] );
10 |Alfonso Mar
array associativi (sequenze di coppie chiave-valore separate da virgole racchiuse in paren-‐
tesi graffe);
null.
La maggior parte dei linguaggi di programmazione possiede un typesystem molto simile a quello definito da JSON; per tale ragione sono nati molti progetti che permettono l'utilizzo di JSON con altri linguaggi quali, per esempio: ActionScript, C, C#, ColdFusion, Common Lisp, Delphi, E, Erlang, Java, JavaScript, Lua, ML, Objective CAML, Perl, PHP, Phyton, Rebol e Ruby.
Alfonso Mar no | 11
1.4 APACHE CORDOVA PER IOS
Le applicazioni mobile giocano un ruolo trainante nel panorama software attuale. Lo sviluppo software nel settore mobile sta assumendo un ruolo simile a quello che ha avuto il Web negli anni novanta. Basti pensare al numero di app presenti sui diversi marketplace, nonché alla varietà di piattaforme disponibili per categorie di dispositivi in continua evoluzione: da iOS ad Android, da Windows Phone a Blackberry OS, da Bada a Tizen. Difficile prevedere se in futuro si aggiungeranno nuove piattaforme o se ci sarà una selezione naturale, né quali delle piattaforme attuali avrà un ruolo predominante anche negli anni a venire. Al momento, chi vuole creare e pubblicare un’app ha di fronte almeno due possibilità:
imparare a sviluppare su una specifica piattaforma e rilasciare la propria app soltanto per essa;
imparare a lavorare su più piattaforme per garantirsi un pubblico più vasto. Per un singolo sviluppatore imparare a lavorare bene su più piattaforme è un impresa ardua, considerata anche la rapida evoluzione dei sistemi che costringe ad una formazione costante. D’altra parte, anche per un’azienda avere un team di sviluppatori specializzati nelle diverse piattaforme mobile può essere oneroso. Di fronte a questo dilemma può e ssere utile valutare una terza possibilità che consente di avere una visione unificata delle diverse piattaforme, una strada che passa per le tecnologie Web. 12 |Alfonso Mar
Allo stato attuale possiamo classificare le applicazioni per il mondo mobile in tre categorie sulla base delle tecnologie utilizzate. Più specificatamente, le tre categorie sono:
App native; sono le app scritte e compilate per una specifica piattaforma utilizzando uno dei linguaggi di programmazione supportati dal particolare sistema operativo.
Web app; sono pagine Web ottimizzate per dispositivi mobili sfruttando le tecnologie Web, in particolare HTML5, JavaScript e CSS3.
App ibride; sono le app che cercano di sfruttare il meglio delle due categorie precedenti: sono scritte con tecnologie Web ma vengono eseguite localmente all’interno di un’applicazio-‐
ne nativa.
Ogni tipologia ha aspetti positivi e negativi e la scelta deve essere fatta valutando attentamente le diverse condizioni ed il contesto in cui si andrà ad operare. Ad esempio, un’applicazione nativa ha dalla sua parte una maggiore velocità di esecuzione e una maggiore integrazione con il look and feel della piattaforma, ma non è direttamente portabile su altre piattaforme. Una Web app, invece, risulta indipendente dalla piattaforma ma richiede una connessione Internet attiva e non è in grado di accedere al file system o ad altre risorse hardware del dispositivo.
La tipologia di app ibrida, che impareremo a conoscere, co-‐
niuga i vantaggi delle Web app con quelle delle app native, consentendo di utilizzare le tecnologie Web per sviluppare l’applicazione senza necessità di una connessione Internet costante e avendo accesso alle risorse locali del dispositivo.
Anche in questo caso ci sono degli svantaggi da considerare; queste consistono in:
una minore efficienza nel rendering grafico;
la potenziale lentezza di esecuzione nell’accesso alle risorse locali;
un’aspetto dell’interfaccia grafica che, senza particolari accorgimenti, potrebbe non risultare abbastanza omogeneo con quello nativo della piattaforma.
In linea di massima le app ibride si pongono a metà strada tra le app native e le web app, rap-‐
presentando un buon compromesso per la creazione di applicazioni mobile multipiattaforma con un supporto nativo. Alfonso Mar no | 13
Apache Cordova nasce da un progetto di successo, PhoneGap, avviato da una azienda canade-‐
se, Nitobi Software, e venduto nel 2011 ad Abobe. Contestualmente alla trattativa con Adobe, Nitobi ha donato alla fondazione Apache il progetto che, in un primo tempo, aveva assunto il nome di Apache Callback e, successivamente, il nome attuale di Apache Cordova.
Si tratta, quindi, di un software Open Source distribuito con licenza Apache 2.0. Allo stato attuale il progetto PhoneGap portato avanti da Adobe non é altro che una distribuzione di Apache Cordova con la possibilità di usufruire di servizi aggiuntivi.
L’architettura di Apache Cordova si presenta come una sorta di contenitore di applicazione Web eseguita localmente. L’interfaccia grafica di un’applicazione Cordova è, infatti, costituita da una Web view che occupa l’intero schermo del dispositivo all’interno della quale viene visua-‐
lizzato l’HTML ed il CSS e viene eseguito il codice JavaScript. Tramite JavaScript è possibile accedere ad un ricco insieme di API che interfacciano l’applicazione Web con le funzionalità della piattaforma ospite.
Pertanto, Web view e API sono le componenti dell’applicazione che dipendono dalla specifica piattaforma mobile (in questa trattazione, iOS). Sono, appunto, queste componenti che il framework mette a disposizione dello sviluppatore, consentendogli di concentrarsi sul codice standard indipendente dalla piattaforma. Pertanto, Web view e API sono le componenti dell’applicazione che dipendono dalla specifica piattaforma mobile. Cordova, infatti, imple-‐
menta lo stesso insieme di API sulle diverse piattaforme mobile supportate creando un livello software standard a cui si possono interfacciare le nostre applicazioni. Per chiarire meglio il concetto, è come se Apache Cordova mettesse a disposizione dello sviluppatore delle app vuote, una per ciascuna piattaforma mobile, da riempire con codice HTML, CSS e JavaScript. 14 |Alfonso Mar
Una volta riempite avremo un’applicazione per ciascuna piattaforma che condividono la stessa base di codice HTML, CSS e JavaScript.
Allo stato attuale Apache Cordova supporta le seguenti piattaforme mobile: Android, iOS, Blackberry, Bada, Tizen e Windows Phone. Questo dà un’idea della platea di utilizzatori di cui potrebbe usufruire la nostra app e del lavoro che sta dietro al progetto.
Per sviluppare un’applicazione e compilarla per iOS si deve utilizzare un Mac. Per ciascuna piat-‐
taforma mobile di riferimento dobbiamo avere installato il relativo SDK di sviluppo. In più, per realizzare un’app iOS sul nostro Mac deve essere installato XCode. Alfonso Mar
Alfonso Marno no | 15
| 1
1.5 XCODE
Xcode è un ambiente di sviluppo integrato (Integrated Development Environment, IDE) , rea-‐
lizzato da Apple, per agevolare lo sviluppo di software per Mac OS X. Xcode lavora in congiun-‐
zione con Interface Builder, un tool grafico per realizzare interfacce grafiche. Include ,inoltre, GCC, che è in grado di compilare codice C, C++, O bjective C/C++ e Java. Supporta, ovviamente, i framework Cocoa e Carbon, oltre ad altri. Una delle caratteristiche tecnologicamente più avanzate di Xcode sta nel fatto che esso supporta la distribuzione in rete del lavoro di compila-‐
zione. Usando Bonjour e Xgrid:
permette di compilare un progetto su più computer riducendo i tempi; supporta la compilazione incrementale;
permette di compilare il codice mentre viene scritto, in modo da ridurre il tempo di com-‐
pilazione.
Il servizio Xcode ospita un repository (ambiente di un sistema informativo) di versioni software (Git), che controlla il codice sorgente e lavora all'integrazione di quest'ultimo come previsto. Nel servizio Xcode, questo set discreto di istruzioni automatizzate viene chiamato bot.
La maggior parte dell'interazione con i bot avviene in Xcode sebbene esista un front-end Web per scaricare i prodotti e i log delle build.
L'integrazione continua è una pratica di sviluppo software che testa ed esegue la build del software su una base continua, mantenendo la qualità del lavoro per ciascuna build. Periodica-‐
mente, oppure dopo ogni commit di codice, il servizio Xcode analizza, esegue un test ed ese-‐
gue la build del lavoro dello sviluppatore. Le integrazioni sono attività, come l'analisi statica, il testing e l'archivio, eseguite da Xcode. Un'integrazione può essere corretta (tutte le verifiche non rilevano nessun problema) o non corretta.
I bot del servizio Xcode eseguono queste integrazioni effettuando tre azioni di schema:
effettuare l'analisi statica (“Analizzare”);
eseguire il test di unità (“Test”);
archiviare il prodotto dello schema di build (“Archiviare”).
Xcode è lo strumento per sviluppare le applicazioni native per iPhone, iPad e iPod touch.
16 |Alfonso Mar
2. INTRODUZIONE ALLE ANEMIE
In questo capitolo tratteremo i vari tipi di anemia che comportano come effetto finale la riduzione della massa eritrocitaria totale e/o del contenuto emoglobinico del sangue circolante,
causa di sofferenza ipossica ai vari organi, che si manifestano con segni e sintomi di varia
natura. La molteplicità dei fattori etiologici delle anemie implica una diagnostica mirata e
un trattamento specifico, come la rimozione delle cause o l’apporto di fattori carenziali.
1 Tipi di anemie
2
4 Complicazioni
5 Trattamento
Cause dell’anemia
3 Diagnostica
1
Alfonso Mar no | 17
2.1 TIPI DI ANEMIE
L’anemia è una condizione in cui il numero dei globuli rossi (GR) o il contenuto di emoglo-‐
bina (Hb) diminuiscono a causa di perdita ematica, eritropoiesi insufficiente, emolisi ec-‐
cessiva o una combinazione di queste modificazioni.
Classificazione delle anemie:
1° GRUPPO: Ridotta eritroblastogenesi
Eritroblastopenia congenita
Eritroblastopenia acquisita
Anemia da insufficienza renale
2° GRUPPO: Ridotta eritrogenesi (eritropoiesi inefficace)
Carenza di vitamina B12 o di folati (anemie megaloblastiche)
Anemie diseritropoietiche congenite
Anemia saturnina
3° GRUPPO: Ridotta sintesi emoglobinica
Talassemie
Carenza di ferro
Anemia associata a flogosi
IV.
Carenza di vitamina B6
V.
Carenza proteica grave
4° GRUPPO: Ridotta sopravvivenza eritrocitaria (emolisi)
Alterazioni dell’eritrocita
Emolisi immune
Emolisi meccanica
18 |Alfonso Mar
Le componenti interessate nella classificazione di uno stato anemico che devono essere prese in considerazione sono:
midollo osseo;
reticolociti;
eritrociti;
MCV;
emolisi.
Pertanto, ogni gruppo di anemie è rappresentato dalla variazione dei suddetti parametri come mostrato nella seguente tabella:
MIDOLLO
(ERITRO
BLASTI)
RETICOLOCITI
ERITROCITI
MCV
EMOLISI
NORMALE
+ ± -
1 - 2 %
5 X 10⁶/µL
80-90µ³
//
I GRUPPO
- - -
ASSENTI
RIDOTTI
80-90
//
II GRUPPO
+ + +
RIDOTTI
RIDOTTI
> 100
±
III GRUPPO
+ + -
PRESENTI
Ridotti/ normali o
aumentati
<80
//
IV GRUPPO
+ + +
+ + +
RIDOTTI
90
+
Alfonso Mar no | 19
2.2 CAUSE DELL’ANEMIA
Una diminuzione della produzione dell'emoglobina può verificarsi nelle cellule del midollo osseo progenitrici dei globuli rossi circolanti, a causa di:
Un aumento del fabbisogno (accrescimento, gravidanza, allattamento, invecchia-‐
mento);
stati patologici (malattie genetiche, carenze di vitamina B12, di ferro o di acido folico, malattie croniche invalidanti, tumori).
L'anemia può essere conseguenza anche di una maggiore "fragilità" dei globuli rossi che li rende più velocemente eliminabili da parte dell'organismo (anemie emolitiche), per:
cause genetiche;
attivazione anomala del sistema immunitario.
Infine, può esservi un aumento della perdita di globuli rossi causato da:
un'emorragia acuta o cronica (perdite mestruali troppo abbondanti o troppo fre-‐
quenti, sanguinamenti occulti causati da una lesione dell'apparato digerente o geni-‐
to-urinario). In questi casi la perdita di ferro induce una riduzione dei depositi di questo minera-‐
le, essenziale per la sintesi dell'emoglobina. E’ evidente che una dieta che sia consistentemente povera di ferro e vitamine è a rischio di anemia. Il corpo umano, infatti, ha bisogno di ferro e vitamine per produrre un numero adeguato di globuli rossi. Malattie intestinali, come, ad esempio, la malattia di Chron o la celiachia, le quali ledono la capacità dell'intestino di assorbire i nutrimenti, possono au-‐
mentare il rischio di anemia. Operazioni chirurgiche sulle parti dell'intestino nelle quali vengono assorbiti i nutrimenti possono portare a deficienze nutrizionali e anemia.
In generale, le donne sono più a rischio di anemia degli uomini perché perdono sangue con il ciclo mestruale, e con esso ferro. Senza un supplemento di ferro si può verificare un'anemia da deficienza ferrosa virtualmente in tutte le donne incinte (anemia sidropeni-‐
ca), poiché le loro riserve di ferro vengono utilizzate sia a causa dell’aumento del volume di sangue della madre, sia per consentire al ferro di essere assorbito dal feto che, crescen-‐
do, svilupperà emoglobina.
Cancro, problemi ai reni o al fegato, o altre condizioni croniche possono essere fattori di rischio per l'anemia. Queste condizioni infatti possono portare ad un decremento del numero di globuli rossi. Anche una lenta e cronica perdita di sangue da un ulcera o da un'altra parte del corpo può svuotare le riserve di ferro del corpo, portando ad anemia da deficienza ferrosa. 20 |Alfonso Mar
Alcune infezioni, malattie del sangue e disordini autoimmuni, esposizione a materiali chimico-tossici e l'uso di certi tipi di medicazioni possono abbassare la produzione di globuli rossi, portando così all'anemia. Sarebbe opportuno richiedere una visita medica quando ci si sente affaticati senza nessun motivo apparente, soprattutto se si sa di essere a rischio anemia. Alcune anemie, soprattutto quella da deficienza di ferro, sono abba-‐
stanza comuni.
Nutritional Deficency or Blood Loss
Chronic Disease
Unexplained
Alfonso Mar no | 21
2.3 DIAGNOSTICA
Nella diagnosi delle anemie è importante quantificare i livelli di emoglobina al fine di effet-‐
tuare una terapia adeguata. Clinicamente si parla di anemia lieve, moderata o grave secondo i valori riportati nella seguente tabella:
L’emocromo è l’esame ematochimico principale per la rilevazione dell’anemia; si riporta, di seguito, copia di un esame emocromocitometrico che esprime la parte cellulare del sangue:
22 |Alfonso Mar
Con l'esecuzione dell'emocromo si quantifica il numero dei globuli rossi, quello di tutte le altre cellule del sangue (globuli bianchi e piastrine), l'ematocrito, la quantità dell'emoglobina totale. Altri test utili sono il dosaggio del ferro (sideremia), della transferrina e della ferritina. L'eventuale presenza di emorragie nel tratto gastrointestinale viene accer-‐
tata con la ricerca del sangue occulto nelle feci. L'insieme di queste indagini permette, generalmente, di individuare il tipo e la causa dell'Anemia. La corretta diagnosi di anemia si integra con la valutazione di segni e sintomi e dall’esa-‐
me obbiettivo del paziente. Il sintomo più evidente è il pallore della cute e delle mucose, dovute all'insufficiente apporto di ossigeno ai tessuti. Altri sintomi sono: debolezza e scarsa resistenza agli sforzi, tachicardia, mal di testa persistente, respiro accelerato, vertigini e senso di stordimento. Alcune forme di anemia sono associate ad ingrossamen-‐
to della milza. La diagnostica avanzata prevede come primo step l’esame dello striscio periferico su sangue venoso:
In alcune forme è indicato l’esame più invasivo rappresentato dal puntato midollare:
Alfonso Mar no | 23
2.4 COMPLICAZIONI
Quando l'anemia è grave, interferisce con le abitudini quotidiane del paziente. L'affatica-‐
mento potrebbe essere tale da impedire il normale lavoro o il gioco dei bambini. Anche se l'anemia è solitamente guaribile, potrebbero comunque essere necessari mesi per ristabi-‐
lire il giusto livello di globuli rossi nel sangue attraverso la terapia. Se non controllata, l'anemia potrebbe portare ad un battito cardiaco troppo rapido o irregolare (aritmia). Il cuore deve, infatti, pompare più sangue per ovviare alla scarsità di ossigeno presente nel sangue stesso. Anemie perniciose che non vengono curate possono causare danneggia-‐
mento dei nervi e, talvolta, demenza, dal momento che la vitamina B12 è importante non solo per globuli rossi sani, ma anche per funzioni ottimali di nervi e cervello.
Alcune anemie ereditarie possono essere così gravi da portare a complicazioni che metto-‐
no a rischio la vita (Talassemia major).
Perdere rapidamente una grande quantità di sangue può innescare un’anemia acuta (come lo shock emorragico) che può essere fatale.
Complicanze più gravi possono essere:
lo scompenso cardiaco;
l’infarto miocardico acuto;
l’angina pectoris;
l’alterazione ossea nella talassemia.
24 |Alfonso Mar
2.5 TRATTAMENTO
Instaurare un trattamento a base di ferro senza ricercare la causa dell'anemia è una pratica mediocre; il sito di sanguinamento deve essere ricercato anche in casi di anemia lieve.
Il ferro può essere somministrato mediante una varietà di sali di Fe (per esempio, come solfa-‐
to, gluconato, fumarato ferroso) o saccarato di Fe PO (per via orale) 30 min prima dei pasti (il cibo o gli antiacidi possono ridurne l'assorbimento). L'aggiunta di acido ascorbico (500 mg) aumenta l'assorbimento del ferro senza aumentare i problemi gastrici. Il ferro contenuto in capsule entero-protette non è ben assorbito e quindi non deve essere somministrato. Il ferro orale è più sicuro di quello parenterale, sebbene la risposta e il modello di ripristino dell'Hb sono gli stessi. La via parenterale deve essere riservata ai pazienti che non tollerano o non sono in grado di prendere il prodotto PO oppure nel caso di pazienti che perdono regolar-‐
mente grandi quantità di sangue a causa di malattie vascolari o capillari (per esempio, la teleangiectasia emorragica ereditaria).
A distanza di 7-10 giorni dall'inizio della terapia con ferro di solito si ha il massimo della rispo-‐
sta reticolocitaria. Il grado di reticolocitosi è meno elevato di quello raggiunto nelle anemie megaloblastiche in corso di trattamento con vitamina B 12 o acido folico. L'evidenziazione dell'aumentata policromatofilia sullo striscio di sangue permette una documentazione del processo di ripristino con minori sforzi e costi di quelli richiesti per una vera conta reticoloci-‐
taria. Nelle prime 2 sett. l'Hb aumenta poco, mentre successivamente l'incremento di regola è di 0,7-1 g/sett. Una risposta anomala può essere dovuta a emorragia ininterrotta, infezione o neoplasia concomitanti, insufficiente apporto di ferro o, molto raramente, a malassorbi-‐
mento del ferro PO. Quando l'Hb si avvicina alla normalità, il livello dell'incremento rallenta; l'anemia deve essere corretta entro 2 mesi. La terapia deve essere portata avanti per 6 mesi in modo che si reintegrino i depositi tissutali. Nel caso di anemia emolitica, visto il numero di possibili cause di questo tipo di anemia, sarà necessario scoprirne l’origine. Se l’anemia è dovuta a un farmaco, per esempio, sarà necessa-‐
rio interrompere l’assunzione del farmaco tossico. Poi, per supplire alla mancanza di globuli rossi, potrà essere effettuata una trasfusione. Le donne in gravidanza vengono sempre esaminate per individuare un’eventuale incompati-‐
bilità di Rh (eritroblastosi fetale). Le donne che presentano tale incompatibilità riceveranno un’iniezione di Rhophylac, farmaco che contiene immunoglobuline (lg). In casi di anemia acuta, è necessario ricorrere alle emotrasfusioni sul feto. Alfonso Mar no | 25
26 |Alfonso Mar
3. ARCHITETTURA DEL SISTEMA COMPLESSIVO E
ANALISI DEI REQUISITI
In questo capitolo tratteremo l’architettura del sistema realizzato, ovvero l’organizzazione basilare del sistema, rappresentato dalle sue componenti, dalle relazioni che esistono tra di esse e con l’ambiente circostante, e dai principi che governano la sua progettazione ed evolu-‐
zione. Inoltre eseguiremo l'analisi dei requisiti, che è un'attività preliminare allo sviluppo di un sistema software, il cui scopo è quello di definire le funzionalità che il prodotto deve offri-‐
re, ovvero i requisiti che devono essere soddisfatti dal software sviluppato. 1
Individuazione delle
componenti
2
Strutturazione dei
componenti
3
Individuazione dei
requisiti
1
Alfonso Mar no | 27
3.1 INDIVIDUAZIONE DELLE COMPONENTI
Quando si opera nel campo dell’informatica e ci si occupa di realizzare applicazioni, si affrontano discussioni inerenti tematiche legate alla progettazione del software. In questi frangenti emergono concetti come quello di architettura. La progettazione di un’applicazione rappresenta l’insieme delle attività mirate ad indivi-‐
duare la soluzione implementativa migliore allo scopo di centrare gli obiettivi funzionali (e quelli non funzionali) attesi dal committente e dall’utilizzatore finale. La progettazione condivide con la programmazione la tendenza ad astrarre la rappresentazione delle infor-‐
mazioni e le sequenze logiche di elaborazione, ma il livello di dettaglio nei due casi è differente. La progettazione costruisce una rappresentazione del software che riguarda diversi aspetti, si concentra sulla struttura del sistema e sulle relazioni esistenti fra le parti costituenti, identifica le operazioni logiche che devono essere svolte, individua le modali-‐
tà con cui il sistema può interagire con il mondo esterno.
Il risultato della progettazione è la definizione dell’architettura del sistema, intendendo con questo termine l’organizzazione strutturale dello stesso, che comprende i suoi compo-‐
nenti software, le proprietà di ciascuno di essi visibili esternamente (l’interfaccia dei com-‐
ponenti) e le relazioni fra le parti. Pensare all’architettura di un sistema software sempli-‐
cemente come alla sua struttura è estremamente riduttivo. Essa include le modalità con cui le diverse parti si integrano e interagiscono a formare un tutt’uno, considera gli aspetti legati all’interoperabilità con i sistemi circostanti, rappresenta il livello con cui l’applica-‐
zione soddisfa i requisiti funzionali, comprende le caratteristiche non direttamente legate ai casi di utilizzo, ma orientate a favorire l’evoluzione nel tempo del sistema a fronte dei suoi cambiamenti strutturali e in relazione all’ambiente in cui esso è inserito (scalabilità, performance, manutenibilità, sicurezza, affidabilità, etc.). 28 |Alfonso Mar
L’architettura, quindi, è una rappresentazione che permette all’architetto di analizzare l’effi-‐
cacia del progetto per rispondere ai requisiti stabiliti, di considerare e valutare le alternative strutturali in una fase in cui i cambiamenti abbiano ancora un impatto relativo sull’andamen-‐
to del progetto e sul risultato finale e di gestire in modo appropriato i rischi che sono collegati alla progettazione e alla realizzazione del software.
La definizione data di architettura richiama il concetto di “componente software” nella sua forma più generale. Con questo termine si intende qualsiasi entità facente parte di un siste-‐
ma, a diversi livelli di dettaglio e granularità, dal semplice modulo applicativo (per esempio, una classe in un’applicazione basata sul paradigma ad oggetti) al sottosistema complesso (per esempio, un DBMS o un server LDAP). Ciascun componente entra a far parte dell’archi-‐
tettura in funzione del ruolo che esso ricopre. Ogni componente presenta caratteristiche peculiari che influenzano il modo con cui ciascuna parte del sistema comunica e interagisce con le altre. L’architettura considera gli aspetti inerenti la comunicazione tra le parti, si foca-‐
lizza sulle modalità di interazione tralasciando i dettagli di funzionamento interni. Nei mo-‐
derni sistemi software (per esempio, quello che stiamo prendendo in considerazione) le parti interagiscono tra loro per mezzo di interfacce/contratti che suddividono in modo netto ciò che non è direttamente accessibile dall’esterno da ciò che è pubblico. Alfonso Mar no | 29
Il sistema correlato alla presente tesi presenta due componenti fondamentali:
client;
server.
Il client, in informatica, indica un componente che accede ai servizi o alle risorse di un altro componente detto server. In questo contesto si può, quindi, parlare di client riferendosi sia all'hardware che al software. Il client utilizzato assume molteplici forme in quanto l’applicazione sarà fruibile su due diverse piattaforme mobile Apple, ovvero:
1.
2.
IPad;
IPhone.
Il server, invece, indica genericamente un componente o sottosistema informatico di elaborazione che fornisce, a livello logico e fisico, un qualunque tipo di servizio ad altri componenti (chiamati, appunto, client) che ne fanno richiesta attraverso una rete di dispositivi, all'interno di un sistema informatico o direttamente in locale su un dispositivo. In questo caso sono presenti dei Web service implementati attraverso PHP 5 che svolgo-‐
no due funzioni fondamentali:
1.
2.
elaborazione dati provenienti dall’app;
elaborazione dati presenti sul DBMS stesso.
30 |Alfonso Mar
3.2 STRUTTURAZIONE DEI COMPONENTI
Una volta individuati i due componenti fondamentali che costituiscono il nostro sistema, procediamo con la loro analisi.
Il Client è un sistema che possiede una struttura stratificata; possiamo, dunque, immagi-‐
narlo come una serie di strati, uno sopra l'altro, che implementeranno determinate funzio-‐
ni. Dunque, ogni strato sarà delegato a gestire ed implementare determinate funzionalità e, in sostanza, lo strato superiore beneficia dei servizi offerti dallo strato inferiore senza, però, saperne la logica implementativa.
La struttura del sistema è mostrata nello schema sottostante:
Analizziamo i vari strati partendo dal basso: Core Os è lo strato che lavora più a basso livello ed è il cuore del sistema. Infatti, in que-‐
sto strato, vengono gestiti i file system, vengono implementate le funzioni per la sicurezza del dispositivo, vengono gestiti i certificati, e molto altro. Uno dei compiti principali di questo strato è quello di gestione della potenza, ovvero di gestire nel modo più efficace possibile l’energia messa a disposizione dalla batteria del dispositi-‐
vo, senza sprechi. Nei dispositivi come iPhone e iPad, dove la quantità di energia erogata è molto limitata, risulta di vitale importanza una gestione ottimale della stessa.
Core Service implementa le utility di sistema, come la gestione del networking, la lista dei contatti e le preferenze di sistema inserite dall'utente. Inoltre se utilizziamo, nelle nostre applicazioni, un database SQLite, quest'ultimo lavorerà proprio a questo livello e, dunque, l'accesso e le interrogazioni che verranno fatti al database saranno gestiti proprio da questo strato. Alfonso Mar no | 31
Media contiene tutte le funzionalità e le librerie per la gestione di video, audio, animazioni, e tanto altro ancora. In questo strato, infatti, sono ubicate le librerie OpenAL per la gestione e la manipolazione di flussi audio e le famose librerie OpenGL ES per produrre grafica 2D con animazioni anche complesse. Queste ultime sono le sorelle minori delle librerie OpenGL, che permettano anche di produrre grafica 3D di altissimo livello. Le OpenGL ES sono state strutturate per essere utilizzate in sistemi embedded come, appunto, i dispositivi telefonici; il suffisso ES rappresenta, appunto, l'acronimo di Embedded System. Oltre alle librerie sopra riportate, sono presenti, in questo strato, tutte le routine che permetto al sistema di visualizzare immagini in formato .jpeg, .png, .tiff e per la lettura di file PDF. Cocoa Touch lavora più ad alto livello. Si occupa della gestione e del riconoscimento del touch e del multi-touch dell’utente, ed è in grado di interpretare, in maniera corretta, le gesture compiute dall’utente. Per gesture si intendono movimenti, quali, ad esmpio lo zoom-in, lo zoom-out o la rotazione delle foto. Quando questo strato interpreta uno di questi movi-‐
menti, richiamerà una routine di gestione specifica per esso. Oltre a gestire il touch dell'u-‐
tente, questo strato si occupa di gestire funzionalità come l'accelerometro ed il giroscopio riuscendo, dunque, a capire in che modo è orientato il dispositivo rispetto ad un asse oriz-‐
zontale. Esso si occupa, inoltre, della gestione della gerarchia delle view, della fotocamera del dispositivo e delle alert.
Il server è stato implementato per semplicità di utilizzo, qualità del codice e diffusione attra-‐
verso l’accoppiata PHP e MySQL .
PHP è conosciuto come Hypertext Preprocessor, ed è un linguaggio completo di scripting, sofi-‐
sticato e flessibile, che può girare praticamente su qualsiasi server Web, su qualsiasi sistema operativo (Windows o Unix/Linux, Mac, AS/400, Novell, OS/2 e altri), e prevede una stretta interazione con MySQL.
32 |Alfonso Mar
In MySQL le funzioni definite dall’utente (in inglese, User-Defined Functions o UDF) sono dei programmi eseguibili che vengono archiviati all’interno del DBMS; possono essere utilizzati per operazioni di manipolazione dei dati che non sono previste nel Database server. Si tratta in pratica di un mix tra applicazioni esterne ed istruzioni SQL che possono essere integrate in MySQL e richiamate quando i soli comandi messi a disposizione dal linguaggio o le funzioni native non sono sufficienti.
Di seguito un immagine che mostra la struttura del database a supporto della nostra applica-‐
zione:
Una specificità fondamentale del progetto, che riguarda sempre la sua componente architettu-‐
rale, è rappresentata dalla comunicazione client-server.
La soluzione implementata per gestire lo scambio dei dati client-server è il protocollo JSON.
JSON viene utilizzato tramite JavaScript; è un interprete che permette di effettuare il parsing attraverso una semplice chiamata ad una funzione. Questo fatto lo ha reso velocemente molto popolare a causa della diffusione della programmazione in JavaScript. Alfonso Mar no | 33
Il trasferimento dei dati client-server può essere, quindi, schematizzato nel seguente modo:
34 |Alfonso Mar
3.3. INDIVIDUAZIONE DEI REQUISITI
La raccolta dei requisiti consiste nell’individuazione delle caratteristiche statiche (dei dati) e dinamiche (delle operazioni) dell'applicazione da realizzare. I requisiti vengono raccolti in specifiche, espresse in linguaggio naturale, e, per questo motivo, spesso ambigue e disorga-‐
nizzate. L'analisi dei requisiti consiste nel chiarimento e nell'organizzazione delle specifiche raccolte. I requisiti dell’applicazione provengono da diverse fonti, tra le quali: gli utenti dell’applicazione, la documentazione esistente attinente al problema in esame, eventuali realizzazioni preesistenti dell’applicazione.
Il coinvolgimento del cliente nel processo di sviluppo aumenta il suo livello di soddisfazione nei confronti del sistema che gli verrà consegnato e agevola il lavoro di raccolta dei requisiti da parte dei progettisti. Spesso i progettisti vengono inseriti direttamente nell'ambiente di lavoro in cui l'applicazione dovrà essere utilizzata (si parla di progettazione contestuale). E' prassi percorrere assieme al cliente il flusso di lavoro e gli scenari di esecuzione delle transa-‐
zioni del sistema proposto, oppure creare un prototipo dimostrativo dell'applicazione.
Alcune regole generali per ottenere una specifica precisa e priva di ambiguità sono le seguen-‐
ti:
Evitare termini troppo generici o troppo precisi.
Mantenere un livello di astrazione costante.
Evitare l’uso di sinonimi (termini diversi con il medesimo significato) e omonimi (termini uguali con differenti significati).
Riferirsi allo stesso concetto sempre nello stesso modo.
Usare frasi brevi e semplici possibilmente uniformandone la struttura.
Dividere il testo in paragrafi.
Dedicare ogni paragrafo alla descrizione di una specifica entità della realtà modellata.
Evidenziare l'entità descritta in ogni paragrafo.
E' fondamentale, fin da questa fase, differenziare le seguenti componenti del modello:
1.
2.
3.
Entità. Un’entità è un concetto complesso e di rilievo che descrive classi di oggetti con esistenza autonoma.
Attributi delle entità. Un attributo è un concetto che ha una struttura semplice e non pos-‐
siede proprietà rilevanti associate. Relazioni tra entità. Queste sono associazioni tra due o più entità. Per le relazioni occorre identificare anche le cardinalità con cui le entità vi partecipano. Alfonso Mar no | 35
E’ utile separare i requisiti funzionali da quelli non funzionali. Un requisito funzionale specifica cosa farà il sistema; invece, un requisito non funzionale è un vincolo imposto dal sistema. I requisiti non funzionali, inoltre, specificano o limitano come il sistema debba essere implementato.
I tipi specifici di requisiti da utilizzare dipendono dal tipo di software che si sta creando. Individuazione dei requisiti:
L’applicazione, oggetto della tesi, presenta una serie di funzionalità pensate per migliora-‐
re e semplificare l’esperienza lavorativa del medico. Il medico inizialmente dovrà accede-‐
re all’applicazione fornendo le proprie credenziali (username e password) ed effettuare il login, solo a questo punto potrà iniziare ad usufruire delle funzioni offerte dall’applicazione. Le funzioni principali offerte dall’applicazione sono le seguenti:
inserimento di un nuovo paziente;
modifica di un paziente;
ricerca dei pazienti;
eliminazione di un paziente;
modifica delle informazioni riguardanti il medico;
prescrizione di una visita medica ad uno specifico paziente ;
inserimento di un nuovo esame (data e tipo) associato ad uno specifico paziente;
visualizzazione dello storico degli esami associati ad uno specifico paziente;
visualizzazione (in maniera esclusiva) di uno dei tre possibili risultati, riguardanti uno specifico paziente, derivati dall’analisi degli esami a lui associati: 1.
2.
3.
diagnosi definitiva;
prescrizione di un altro esame necessario per completare la diagnostica;
suggerimento sulle possibili cause dell’anemia.
Una volta terminata la sessione di lavoro, il medico ha la possibilità di effettuare il log out, chiudendo, in questo modo, la sessione autenticata.
36 |Alfonso Mar
L’autenticazione avviene utilizzando un sistema di token che garantisce un elevato livello di sicurezza con cifratura sha256 e sha512.
La distinzione tra i medici che accedono al sistema è permessa dal database solo
nel caso in cui l’utente risulti memorizzato in esso. Nel database di supporto al sistema è presente la tabella che distingue i diversi medici.
Deve essere garantita la validazione dei campi di input.
Un medico, per questioni di privacy, può cercare solo i pazienti aggiunti da lui stesso.
Per ogni paziente aggiunto, verrà creata una tupla all’interno della tabella medicopaziente, che servirà ad associare il paziente al medico che l’ha aggiunto.
L’eliminazione di un paziente, comporta che vengano eliminate l’associazione medico
-paziente e gli esami sostenuti dal paziente stesso.
L’aggiunta o l’eliminazione di un medico è gestita dall’amministrazione attraverso l’uso del software phpMyAdmin.
La valutazione di un paziente, può avvenire, purché, ci sia almeno un esame associato a lui.
L’inserimento errato delle credenziali (username e password) per un numero di volte maggiore a tre comporta il blocco del relativo account per quindici minuti. E’ necessario effettuare il backup periodico del DBMS
Alfonso Mar no | 37
38 |Alfonso Mar
4. PROGETTAZIONE DELL’APPLICAZIONE
In questo capitolo analizzeremo l’attività di progettazione, in cui si definiscono le linee essenziali della struttura del prodotto software in funzione dei requisiti evidenziati dall'analisi. La proget-‐
tazione può essere scomposta in tre sotto attività, ovvero la definizione della mappa architettu-‐
rale, la progettazione dei mockup e la progettazione dei workflow. Si può dire che la progetta-‐
zione ha lo scopo di definire la soluzione del problema. In questa fase sarà sviluppato un docu-‐
mento che permetterà di avere una definizione della struttura di massima (architettura di alto livello).
1
Mappa dell’applicazione
2
Progettazione dei
Mockup
3
Progettazione dei
Workflow
1
Alfonso Mar no | 39
4.1 MAPPA DELL’APPLICAZIONE
La progettazione riguarda tutte quelle attività che permettono di passare dalla raccolta ed elaborazione dei requisiti di un sistema software alla sua effettiva realizzazione; rap-‐
presenta un ponte tra la fase di specifica e la fase di codifica. Durante la fase di progetta-‐
zione si decidono le modalità di passaggio da "che cosa" deve essere realizzato (specifica) a "come" la realizzazione deve avere luogo. La complessità della progettazione viene "ridotta" suddividendo il sistema complessivo in più sottosistemi. I vantaggi sono: una minore complessità delle singole parti rispetto alla complessità totale origina-‐
ria;
i sottosistemi ottenuti possono essere realizzati ed analizzati da gruppi diversi di programmatori in modo il più possibile indipendente.
Ci sono due esigenze contrastanti:
il progetto risultante deve essere sufficientemente astratto per poter essere agevol-‐
mente confrontato con le specifiche da cui viene derivato;
il progetto deve essere sufficientemente dettagliato in modo tale che la codifica possa avvenire senza ulteriori necessità di chiarire le operazioni che devono essere realizzate.
In fase di progettazione vengono fissate le direttive di sviluppo del software le quali costi-‐
tuiscono un riferimento che il più delle volte risulta particolarmente vincolante per le attività successive (scelte di progetto). Ad una stessa specifica possono corrispondere più progetti, ossia più soluzioni diverse. Le scelte di progetto devono poter cambiare in rispo-‐
sta a mutate esigenze di vario tipo senza che, per questo, tutto il progetto, e perciò tutto il software prodotto, debba essere modificato radicalmente. Devono essere compiute scelte progettuali tali che il progetto risulti trasparente, ossia sufficientemente indipen-‐
dente. Il progetto di un sistema software è, perciò, un'attività altamente creativa, che richiede un insieme di abilità a coloro che vi sono preposti.
Le competenze che un progettista deve avere sono:
una profonda conoscenza di tutto ciò che riguarda il processo di sviluppo del soft-‐
ware;
la capacità di saper anticipare i cambiamenti;
una notevole inventiva per riuscire a trovare una soluzione progettuale accettabile anche in mancanza di una metodologia che sia sufficientemente espressiva;
un buon grado di esperienza per poter individuare con maggiore rapidità e sicurezza le soluzioni più opportune.
40 |Alfonso Mar
Gli obbiettivi della progettazione sono quelli di produrre software con le caratteristiche di qualità che sono state dettagliate nella fase di analisi e specifica dei requisiti; in particolare, tali caratteristiche sono:
affidabilità;
modificabilità; comprensibilità; riusabilità.
Tali obiettivi si possono riassumere nella diminuzione dei costi e dei tempi di produzione e nell'aumento della qualità del software. I costi maggiori riguardano la fase di manutenzione del software. Di seguito l’analisi dei quattro obbiettivi:
Affidabilità
Durante la progettazione viene effettuata una verifica approfondita per verificare che le spe-‐
cifiche siano effettivamente dotate di tutte le necessarie caratteristiche di consistenza, com-‐
pletezza, etc.
Modificabilità
In questo caso si verifica se è possibile effettuare cambiamenti nel sistema di calcolo per cui il prodotto viene sviluppato.
Comprensibilità
Un progetto comprensibile, con un'adeguata documentazione, può essere rivisto ed utilizza-‐
to anche da persone che non hanno partecipato direttamente alla sua stesura. Ciò comporta anche un miglioramento delle caratteristiche di affidabilità e di modificabilità.
Riusabilità
Questa proprietà prevede di utilizzare un'applicazione oppure una sua parte all'interno di una nuova applicazione.
Designer e architetti dell’informazione utilizzano le mappe per rappresentare l’organizzazio-‐
ne dei contenuti di un’applicazione. La mappa è un tipo di documento antico, applicato agli ambiti più diversi, affinato nel tempo attraverso la tecnologia. La rappresentazione più cono-‐
sciuta della mappa di un’applicazione è lo schema gerarchico, ma oggi le mappe possono apparire molto diverse e innovative. Le architetture delle applicazioni sono cambiate e le mappe si sono trasformate in rappresentazioni complesse basate su interconnessioni sempre più sofisticate. Le mappe posso essere profonde o superficiali, larghe o piccole, ad albero, combinate, a stella o a tab, ma devono essere auto-esplicative.
Alfonso Mar no | 41
La mappa può spiegare l’intera struttura di un’applicazione o parte di essa, magari evi-‐
denziando in maniera diversa la natura dei contenuti. A tale proposito è possibile consi-‐
derare almeno le seguenti tre tassonomie:
1.
pagine statiche o pagine dinamiche;
2.
pagine di contenuto o form interattivi;
3.
pagine di contenuto o database.
Nella mappa possiamo, inoltre, specificare se si tratta di un contenuto già prodotto o da produrre, segnalare i responsabili del contenuto o i template di riferimento. Una mappa può partire con un livello base dove verrà evidenziato in maniera diversa un punto di partenza, ovvero il login, per poi sviluppare i vari livelli. La mappa indica un percorso approvato dal team di progetto; è il documento cardine che permette di passare allo step successivo: il m ockup. Di seguito la mappa dell’applicazione oggetto della tesi.
42 |Alfonso Mar
4.2 PROGETTAZIONE DEI MOCKUP
Un mockup rappresenta una riproduzione di un oggetto o modello in scala ridotta o mag-‐
giorata. In informatica si intende, con questo termine, la creazione di un modello di base, di un prototipo da cui partire per la realizzazione di un’applicazione. Creare un mockup è un’ope-‐
razione sempre più immediata, grazie ai molteplici software dedicati a questo genere di operazioni. Il software utilizzato per la realizzazione di mockup relativi all’applicazione oggetto della tesi è Balsamiq Mockup.
Completo di librerie e componenti, Balsamiq Mockup è un’applicazione desktop a paga-‐
mento tra le più utilizzate dai Web designer e webmaster, completa di un servizio in cloud chiamato MyBalsamiq. Attraverso il servizio esterno Napkee, inoltre, è possibile esportare al volo i propri file balsamiq m ockup.
Alfonso Mar no | 43
I mockup riguardanti l’applicazione da noi sviluppata sono i seguenti:
Login: questo mockup rappresenta la pagina attraverso la quale il medico può accedere alle funzionalità offerte dell’applicazione. Ricerca paziente: questo mockup rappresenta la pagina che permette al medico di ricercare i propri pazienti. 44 |Alfonso Mar
Aggiungi Paziente: questo mockup rappresen-‐
ta la pagina attraverso la quale il medico può aggiungere un paziente.
Info Paziente: questo mockup rappresenta la pagina attraverso la quale il sistema visualiz-‐
za al medico le informazioni riguardanti il paziente precedentemente cercato. Inoltre permette al medico di svolgere quattro azio-‐
ni riguardanti il suddetto paziente, ovvero:
prescrivere una visita medica;
inserire un nuovo esame;
visualizzare lo storico degli esami;
prendere una decisione sulla base degli esami svolti.
Alfonso Mar no | 45
Visita Medica: questo mockup rappresenta la pagina attraverso la quale il medico può inserire i sintomi di un paziente e la data in cui la vista è stata effettuata. Esso consente, inoltre di prescrivere un esame (vedi Inserisci Esame).
Inserisci Esame: questo mockup rappresenta la pagina attraverso la quale il medico può inse-‐
rire gli esami di un paziente (data, tipo e valori riguardanti il relativo esame). 46 |Alfonso Mar
Visualizza Esami: questo mockup rappresenta la pagina attraverso la quale il medico può visualizzare lo storico egli esami di un pazien-‐
te.
Valuta Decisione: questo mockup rappresenta la pagina attraverso la quale il medico può visua-‐
lizzare, in maniera esclusiva, in base agli esami effettuati dal paziente, i seguenti risultati:
diagnosi definitiva;
prescrizione di un altro esame necessario per completare la diagnostica;
suggerimento sulle possibili cause dell’a-‐
nemia.
Alfonso Mar no | 47
4.3 PROGETTAZIONE DEI WORKFLOW
Il process flow è un documento altamente dinamico che fissa la relazione tra utenti e applicazione attraverso il movimento e l’interazione. La differenza essenziale con la map-‐
pa dell’applicazione è negli step, che non sono strutturali, gerarchici o multidimensionali, ma possono essere solo sequenziali. Mentre le mappe possono escludere la user expe-‐
rience delle fasi di costruzione, nel process flow questo aspetto diventa dominante e accom-‐
pagna il processo dall’inizio alla fine. Il process flow racconta il funzionamento di un caso d’uso o, in altre parole, di un servizio molto specifico, come l’inserimento di un esame medico, la prescrizione di una visita medica o l’aggiunta di un nuovo paziente. I process flow descrivono come gli utenti (nel caso in oggetto, i medici) raggiungono l’obbiettivo attraverso un percorso dettagliato e ne dettano il funzionamento.
Ciascun utente agisce in maniera diversa e presenta motivazioni ed esperienze differenti. Compito dei process flow è normalizzare questo processo.
Quando lavoriamo su un process flow dobbiamo stabilire a priori:
uno scenario;
un utente tipo;
un obbiettivo.
Lo scenario è necessario per capire in quale ambito si sta muovendo il protagonista della nostra azione. Nel descrivere un processo interattivo ciò che dobbiamo assolutamente evitare è il prevalere dei modelli personali. Ci possono essere obiettivi primari e secondari all’interno dello stesso processo; inoltre, ci sono i trigger, ovvero motivazioni/obiettivi che scatenano un’azione all’interno del processo.
Il process flow deve avere un nome, un titolo chiaro, e semplice, che permette subito di capire cosa stiamo descrivendo. La rappresentazione visiva è derivata dalle mappe del visual vocabulary di James Garret. Essa prevede i seguenti componenti:
Ancore. Il punto di partenza e il punto di arrivo del percorso.
Step. Le azioni che l’utente compie per avanzare nelle caselle verso il risultato.
Path. Le linee che segnano il percorso; queste possono essere differenziate a seconda del tipo di scelta, ma la variazione va usata con parsimonia perché l'impatto visivo del process flow deve essere il più semplice possibile.
Decision point. Sono le variabili di scelta: l’utente si trova davanti a una scelta multi-‐
pla e sceglie come agire. Graficamente hanno la forma di un rombo che propone un collegamento a più possibilità.
48 |Alfonso Mar
Swim lane. Gli ambiti nei quali racchiudere l’azione. Se, per esempio, una parte dell’azio-‐
ne si svolge nell’area pubblica del sito e una parte nell’area riservata, collocheremo le due macro-aree su sfondi colorati diversamente. Lo stesso vale se sono diversi i prota-‐
gonisti dell’azione.
Trigger. La causa iniziale, che scatena l’azione. In alcuni casi è importante dire perché quell’utente si trova in quella situazione.
Il workflow correlato all’applicazione oggetto di questa tesi presenta:
un attore primario corrispondente al medico;
una serie di azioni che il medico può svolgere.
Analizziamo passo passo il workflow. Il medico, inizialmente, vuole compiere un’attività riguardante i suoi pazienti (evento trigger). Il primo punto decisionale (decision point) lo incontra in una delle tre possibili scelte:
aggiungere un nuovo paziente;
modificare le proprie informazioni;
cercare un paziente.
Scegliendo l’operazione di cercare un paziente, una volta selezionato il paziente desiderato, il medico potrà scegliere tra quattro possibilità:
visualizzare un esame;
prescrivere una visita medica;
effettuare una valutazione.
Scegliendo di effettuare una valutazione, il medico dovrà considerare gli esami associati al paziente in questione. In questo caso ci troviamo di fronte a due casi:
1.
2.
numero di esami sufficienti per la valutazione;
numero di esami insufficienti per la valutazione.
Nel primo caso il sistema potrà restituire, come risultato, una diagnosi definitiva oppure suggerire una possibile diagnosi. Nel secondo caso invece il sistema restituirà un messaggio in cui sarà ordinato di effettuare nuovi esami per poter giungere alla diagnosi finale.
Nella pagina seguente verrà illustrato lo schema del workflow
Alfonso Mar no | 49
50 |Alfonso Mar
5. IMPLEMENTAZIONE DELL’APPLICAZIONE E
MANUALE UTENTE
In questo capitolo sarà trattata inizialmente l’implementazione delle pagine HTML, ottenute con l’ausilio delle tecnologie JavaScript e CSS, con le quali è stato possibile realizzare tutte le funzionalità necessarie. Successivamente saranno analizzati il database di supporto all’applica-‐
zione, l’implementazione del server e la comunicazione dell’applicazione con quest’ultimo. Infine verrà mostrato un semplice manuale utente che supporterà il medico nell’utilizzo dell’ap-‐
plicazione.
1
Implementazione HTML,
JavaScript e CSS
2
Implementazione lato
server
3
Implementazione della
connettività
1
4
Manuale utente
Alfonso Mar no | 51
5.1 IMPLEMENTAZIONE HTML, JAVASCRIPT E CSS
L’implementazione dell’applicazione oggetto della presente tesi è avvenuta con l’utilizzo di Apache Cordova.
Apache Cordova consiste in un insieme di API che permette allo sviluppatore di applica-‐
zioni mobile di accedere alle funzioni native dei dispositivi, in questo caso IPhone e IPad, (per esempio, fotocamera, GPS o accelerometro) attraverso JavaScript. Cordova, combi-‐
nato con un UI framework, nel nostro caso Onsen, permette di sviluppare un’applicazio-‐
ne mobile con il solo utilizzo di HTML, JavaScript e CSS. Adottando le API di Cordova, l’applicazione può essere sviluppata senza utilizzare il codice nativo (Objective-C). Le API JavaScript sono uniformi su più piattaforme e sviluppate su standard Web; per questo motivo, l’applicazione è portabile sulle altre piattaforme con sforzi minimi. L’implemen-‐
tazione dell’applicazione attraverso Cordova, oltre ai benefici già trattati, ci permette di inserire l’applicazione sull’Apple Store, in maniera da essere globalmente fruibile.
Il framework utilizzato è Onsen UI, che supporta JavaScript e CSS per le applicazioni HTML5 e Cordova; esso presenta, inoltre, un’ampia selezione di componenti relativi all’interfaccia utente Web-based ed un layout responsive per smartphone e tablet.
Per approfondire le tematiche trattate, saranno mostrate due pagine HTML particolar-‐
mente rilevanti (Info Paziente e Inserisci Esame), in maniera tale da mostrare i punti di forza e le possibilità offerte dalle tecnologie utilizzate e sopra elencate.
La prima pagina considerata è “Info Paziente”. In questa pagina, il medico, visualizzerà le informazioni relative al paziente precedentemente cercato e potrà, inoltre, eseguire una serie di operazioni fondamentali riguardanti quel paziente; tra queste operazioni citiamo le seguenti:
prescrivere una vista medica;
inserire un esame;
visionare il risultato derivante dall’analisi degli esami;
modificare i dati del paziente;
eliminare i dati del paziente.
La grafica (colori, formattazione del testo, grandezza dei componenti, etc.) di questa pagina, ma in generale di tutte le pagine dell’applicazione, è gestita dai CSS forniti da Onsen, che garantiscono uno stile iOS-like. Tutte le componenti presenti all’interno della pagina (pulsanti, liste, menù, etc.) provengono dalle librerie di Onsen e la loro animazione è stata gestita attraverso degli script.
Le operazioni di modifica ed eliminazione del paziente, eseguibili attraverso i relativi pulsanti, vengono gestite attraverso JavaScript, che permette di effettuare due operazioni fondamentali:
bloccare e sbloccare i campi di input HTML;
mostrare e nascondere i pulsanti di conferma.
52 |Alfonso Mar
<script>
function getParameterByName(name) {
name = name.replace(/[\[]/, "\\[").replace(/[\]]/, "\\]");
var regex = new RegExp("[\\?&]" + name + "=([^&#]*)"),
results = regex.exec(location.search);
return results === null ? "" : decodeURIComponent(results[1].replace
(/\+/g, " "));
}
var id = getParameterByName('id');
window.onload=function(){
var result=oauth2DatiParametri("id="+id,"datiPaziente.php");
var paziente = new Paziente(result);
document.getElementById("nome").value=paziente.nome;
document.getElementById("cognome").value=paziente.cognome;
document.getElementById("email").value=paziente.email;
document.getElementById("cf").value=paziente.cf;
document.getElementById("data_nascita").value=paziente.data_nascita;
document.getElementById("indirizzo").value=paziente.indirizzo;
document.getElementById("telefono").value=paziente.telefono;
document.getElementById("cellulare").value=paziente.cellulare;
if(paziente.sesso== "M"){
document.getElementById("r1").checked = true;}
else{
document.getElementById("r2").checked = true;}
}
}
function modificaPaziente(){
document.getElementById(1).style.display = "block";
document.getElementById("nome").disabled = false;
document.getElementById("cognome").disabled = false;
document.getElementById("email").disabled = false;
document.getElementById("cf").disabled = false;
document.getElementById("data_nascita").disabled = false;
document.getElementById("indirizzo").disabled = false;
document.getElementById("telefono").disabled = false;
document.getElementById("cellulare").disabled = false;
document.getElementById("r1").disabled = false;
document.getElementById("r2").disabled = false;
}
In questa parte di codice sono presenti tre funzioni:
1.
2.
3.
getParameterByName() che, in automatico, riceve dall’URL l’id trasmesso da ricer-‐
caPaziente e lo passa alla funzione windows.onload;
window.onload() che, al caricamento della pagina, in base all’id del paziente ottenu-‐
to dalla ricerca grazie alla funzione getParameterByName(), stampa all’interno della pagina tutti suoi dati;
modificaPaziente() che, alla pressione del bottone “modifica”, sblocca tutti i campi di testo, precedentemente bloccati, e permette di modificare i dati relativi a quel paziente.
Alfonso Mar no | 53
Nella parte di codice analizzata di seguito sono presenti due funzioni:
1.
confermaModificaPaziente() che, alla pressione del pulsante “conferma” , trasmette al database i nuovi dati riguardanti il paziente;
2. eliminaPaziente() che, alla pressione del pulsante “elimina”, elimina dalle tabelle paziente, medico-paziente ed esami tutti i dati relativi al paziente.
Tutte le funzioni presenti nell’applicazione che devono scaricare dati dal database utiliz-‐
zano la funzione oauth2Dati; le funzioni che, invece, devono caricare dati nel databa-‐
se, e quindi devono prelevare parametri dalle pagine HTML, utilizzano la funzione oau-‐
th2datiParametri.
function confermaModificaPaziente(){
var nome=myForm.nome.value;
var cognome=myForm.cognome.value;
var data_nascita=myForm.data_nascita.value;
var cf=myForm.cf.value;
var indirizzo=myForm.indirizzo.value;
var email=myForm.email.value;
var telefono=myForm.telefono.value;
var cellulare=myForm.cellulare.value;
var sesso;
result=oauth2DatiParamettri
("id="+id+"&&nome="+nome+"&&cognome="+cognome+
"&&data_nascita="+data_nascita+"&&cf="+cf+"&&indirizzo="+indirizzo+"&&e
mail="+email+"&&telefono="+telefono+"&&cellulare="+cellulare+"&&sesso="
+sesso,"modificaPaziente.php");
if(esito=1){
alert("Il paziente è stato modificato con successo");
}
else {
alert("ERRORE");
}
window.location.reload()
}
function passaID2(){
var pagina = 'inserisciEsame.html?id='+id;
window.location.replace(pagina);
}
function eliminaPaziente(){
var result=oauth2DatiParametri ("id="+id,"eliminaPaziente.php");
alert("Il paziente è stato eliminato con successo");
window.location.replace("ricercaPazienteArray.html");
}
</script>
</head>
54 |Alfonso Mar
<section style="padding: 8px">
<input name="cellulare" id="cellulare" type="text" class="text-input" ngmodel="text7" placeholder="cellulare" disabled="true" style="display: block; width:
100%">
</section>
<div style="padding: 8px">
<div class="button-bar" style="width: 100%" id="genere">
<div class="button-bar__item">
<input type="radio" value="M" name="sesso" id="r1" checked="checked" disabled="true">
<button class="button-bar__button">Uomo</button>
</div>
<div class="button-bar__item">
<input type="radio" value="F" name="sesso" id="r2" disabled="true">
<button class="button-bar__button">Donna</button>
</div>
</div>
</div>
</form>
In questa parte di codice viene mostrato il codice HTML utilizzato per la stampa e l ’inserimen-‐
to di dati da tastiera. Questa implementazione, infatti, permette al medico di visualizzare sullo schermo del dispositivo tutti i dati del paziente e, alla pressione del pulsante “modifica” (analizzato in precedenza), di modificare i dati dello stesso; invece, alla pressione del pulsante “elimina”, cancella dal database tutti i dati relativi a quel paziente. Per tutti i moduli di input, compreso il radio button utilizzato per la selezione del sesso del paziente, sono stati utilizzati componenti appartenenti al framework Onsen. Di seguito, la relativa pagina testata su un IPhone:
Alfonso Mar no | 55
La seconda pagina considerata è Inserisci Esame. Attraverso questa pagina il medico potrà inserire uno o più esami riguardanti uno specifico paziente, indicando la tipologia e la data in cui gli esami sono stati svolti.
Per la realizzazione di questa pagina è stato necessario implementare un plugin di Cordova, ovvero datePicker, che permette di seleziona la data da una “tendina” fornita dal sistema iOS.
Un altro elemento che è stato necessario implementare è il checkbox variabile, ovvero un checkbox in cui ogni elemento della lista viene preso in maniera dinamica dal database. In questo caso il checkbox viene utilizzato per la selezione della tipologia dell’esame, quindi, nel caso in cui nel database vengano inserite ulteriori tipologie di esame rispetto a quelle attualmente esistenti, la lista di checkbox all’interno dell’applicazione si aggiorna in auto-‐
matico. La parte di codice che implementa tale funzionalità è la seguente:
window.onload=function(){
var result=oauth2Dati("tipologieEsame.php");
var index;
var text = "<ul class=\"list\">";
for (index = 0; index < result.length; index++) {
text += "<li class=\"list__item list__item--tappable\"><label
class=\"checkbox checkbox--list-item\" ><input type= \"checkbox\"
class=\"messageCheckbox\" value=\""+result[index].id+"\" name=\"tipologia[]\"><div class=\"checkbox__checkmark checkbox--listitem__checkmark\"></div>" + "
"+result[index].nome + "</label></
li>";
}
text += "</ul>";
document.getElementById("lista_tipologie_esami").innerHTML = text;
}
function aggiungiEsame(){
var data_esame=myForm.data_esame.value;
var id_paziente = getParameterByName('id');
var id_tipologia = "";
var objCBarray = document.getElementById('myForm')['tipologia[]'];
for (i = 0; i < objCBarray.length; i++) {
56 |Alfonso Mar
if (objCBarray[i].checked) {
id_tipologia = objCBarray[i].value;
var result=oauth2DatiParametri
("data_esame="+data_esame+"&&id_tipologia="+
id_tipologia+"&&id_paziente="+id_paziente,"aggiungiEsame.php");
}
}
alert("Esame aggiunto con successo");
if (strChoices.length > 0) {
var strMessage = "ID esami sceti:\n" + id_tipologia;
} else {
alert("Seleziona almeno una tipologia.");
}
}
In questa parte di codice sono presenti due funzioni:
1.
2.
window.onload() che, al caricamento della pagina, crea la checkbox in base alle tipologie degli esami presenti nel database;
aggiungiEsame() che, alla pressione del pulsante “conferma”, aggiunge gli esami (tipologia e data) nel database, al paziente selezionato in precedenza.
Di seguito la relativa pagina testata su un IPhone:
Alfonso Mar no | 57
5.2 IMPLEMENTAZIONE LATO SERVER
L’implementazione del database di supporto all’applicazione è avvenuta mediante MySQL. Le operazioni sul database sono state, invece, effettuate attraverso PHP.
MySQL:
è un database utilizzato sul web;
è un database implementato su un server;
è ideale sia per piccole che per grandi applicazioni;
è veloce, affidabile e facile da usare;
usa l’SQL standard.
I dati, nei database MySQL, sono immagazzinati in tabelle. Una tabella è una raccolta di dati distribuiti in righe e colonne. Per ottenere informazioni dal database, eseguiamo delle query. Una query è una domanda o una richiesta che ci permette, interrogando il database, di estrapolare informazioni specifiche d’interesse.
Nella nostra applicazione le query sono all’interno di pagine PHP, caricate sul server. Queste pagine vengono richiamate all’interno delle pagine HTML tramite funzioni da noi realizzate.
Di seguito verrà mostrata la struttura del database MySQL a supporto del nostro sistema: 58 |Alfonso Mar
Sotto, invece, verrà mostrata la pagina PHP InserisciEsame.php, che analizzeremo nel dettaglio.
<?php
require('controller.php');
if($accepted==true)
{
$data_esame = $_POST['data_esame'];
$id_tipologia =$_POST['id_tipologia'];
$id_paziente = $_POST['id_paziente'];
$query= "INSERT INTO esame (ìd`, ìd_paziente`, ìd_tipologia`,
`data_esame`) VALUES (NULL, '".$id_paziente."',
'".$id_tipologia."','".$data_esame."');";
$res = mysqli_query($connessione, $query);
$json='{"esito":"'.$res.'"}';
}
else
{
$json='""';
}
echo $result.$json.'}';
$connessione->close();
?>
Inizialmente viene testata la connessione attraverso la pagine controller.php; se questa operazione avviene con successo, viene restituita una variabile accepted==true.
In questo caso, la condizione dell’if è verificata; quindi verranno presi i dati necessari attra-‐
verso il comando PHP “POST”; tali dati sono passati dalla pagina HTML alla pagina PHP attraverso la funzione oauth2Dati. Una volta ottenuti questi dati, potrà essere eseguita la query d’inserimento del paziente, che restituirà un risultato che dipenderà, appunto, dalla query, ma anche dalla connessione. Per finire questo risultato verrà restituito all’applicazio-‐
ne.
Nel caso in cui, invece, la pagina controller.php restituisca una variabile accepted==false, la condizione dell’if non è più verificata; quindi, si entrerà all’interno dell’else; in questo caso non si avrà alcun risultato.
Alfonso Mar no | 59
5.3 IMPLEMENTAZIONE DELLA CONNETTIVITÀ
Nella realizzazione dell’applicazione, l’implementazione della connettività client-server ha rivestito un ruolo fondamentale in quanto permette al client di inviare dati al database, e viceversa. Questa funzionalità è stata realizzata utilizzando il protocollo JSON nel seguen-‐
te modo:
lato client sono state create pagine deputate alla traduzione dei dati provenienti dal server verso il client stesso;
function AggiungiPaziente(json){
this.nome = json.nome;
this.cognome = json.cognome;
this.data_nascita =
json.data_nascita;
this.cf = json.cf;
this.sesso= json.sesso;
this.indirizzo =
json.indirizzo;
this.email = json.email;
this.telefono =
json.telefono;
this.cellulare =
json.cellulare;
this.esito = json.esito;
lato server, all’interno delle pagine PHP, vengono generati degli array JSON riempiti con i dati estrapolati dalle query e, successivamente, inviati all’applicazione, dove, come precedentemente detto, vengono tradotti in maniera tale da poter essere utiliz-‐
zati dall’applicazione stessa.
$row = mysqli_fetch_array($res);
$json='{"id":"'.$row['id'].'","nome":"'.$row
['nome'].'","cognome":"'.$row['cognome'].'","email":"'.$row
['email'].'","cf":"'.$row['cf'].'","sesso":"'.$row
['sesso'].'","indirizzo":"'.$row
['indirizzo'].'","data_nascita":"'.$row
['data_nascita'].'","telefono":"'.$row
['telefono'].'","cellulare":"'.$row['cellulare'].'"}';
echo $result.$json.'}';
60 |Alfonso Mar
5.4 MANUALE UTENTE
Di seguito sarà presentato un manuale d’uso del sistema realizzato. In particolare, esso ha lo scopo di illustrare le modalità che gli utenti devono seguire per il suo corretto utilizzo; verran-‐
no, inoltre, descritti i servizi offerti e verranno analizzate le schermate che visualizzano l’in-‐
terfaccia con cui gli utenti stessi interagiscono.
La pagina principale dell’applicazione, denominata “Login”, `è la pagina di accesso dalla qua-‐
le, una volta eseguita l’autenticazione, si verrà reindirizzati alla home p age.
Una volta inseriti username e password, e una volta premuto il pulsante login, il medico verrà reindirizzato alla home page dell’applicazione. In questa pagina egli avrà a disposizione, premendo sull’icona rossa in alto a destra, un menù che gli permetterà di accedere alle fun-‐
zionalità dell’applicazione.
Alfonso Mar no | 61
Selezionando logout, il medico uscirà dall’applicazione e, al prossimo accesso, dovrà reinseri-‐
re le credenziali per poter accedere nuovamente ad essa.
Selezionando Info Medico, il medico visualizzerà le proprie informazioni e, se necessario, potrà modificarle.
Selezionando A ggiungi Paziente, il medico potrà aggiungere un nuovo paziente, compilando correttamente tutti i campi e premendo, infine, il pulsante conferma.
62 |Alfonso Mar
Selezionando Ricerca Paziente, il medico potrà cercare un paziente; a tal fine egli dovrà inserire il nome ed il cognome e, successivamente, premere il pulsante “Ricerca”.
Una volta selezionato il paziente, il medico visualizzerà tu e le informazioni rela ve al paziente stesso; egli potrà, inoltre, eliminare o modificare i suoi da ed effe uare qua ro operazioni fondamentali, ovvero:
eseguire una visita medica;
visualizzare il risultato o enuto dall’analisi degli esami.
Alfonso Mar no | 63
Analizziamo le quattro pagine relative alle possibili operazioni che possono essere ese-‐
guite sul paziente.
Selezionando Visita Medica, il medico potrà registrare una visita medica (data e sintomi), inoltre dalla stessa pagina potrà prescrivere uno o più esami (vedi Inserisci Esame).
Selezionando Inserisci Esame, il medico potrà registrare uno o più esami (data e tipologia).
64 |Alfonso Mar
Selezionando Visualizza e sami, il medico potrà visualizzare lo storico degli esami (data, tipologia ed eventuali note), relativi al paziente precedentemente selezionato.
Selezionando Valuta Decisione, il medico potrà visualizzare lo storico degli esami; in base all’analisi di quest’ultimi, il sistema stamperà nell’apposito riquadro, in maniera esclusiva, uno dei seguenti risultati:
una diagnosi definitiva;
la prescrizione di un altro esame necessario per completa-‐
re la diagnostica;
un suggerimento sulle possibili cause dell’anemia.
Alfonso Mar no | 65
66 |Alfonso Mar
CONCLUSIONI
In questa tesi sono state proposte la progettazione e l’implementazione di un’applicazio-‐
ne iOS per smarthphone e tablet che funge da front-end ad un sistema client-server per supportare il medico di base nelle diagnosi sulle anemie. Inizialmente sono state introdotte le tecnologie utilizzate per lo sviluppo dell’applicazio-‐
ne, ovvero HTML5 e Apache Cordova. Successivamente, è stato proposto un breve qua-‐
dro sulle anemie, utile per analizzare le dinamiche che stanno alla base di questa patolo-‐
gia. Per quanto riguarda l’architettura dell’applicazione, invece, è stata mostrata la solu-‐
zione implementativa scelta e sono stati identificati i requisiti. Nella fase successiva, ovvero, quella di progettazione, sono stati mostrati gli elementi cardine della progetta-‐
zione stessa, ovvero la mappa dell’applicazione, i Mockup e il Workflow. Infine, è stata trattata l’implementazione client-server dell’applicazione, con un breve sguardo alle principali funzioni create, ed è stato, inoltre, realizzato un breve manuale d’uso del siste-‐
ma, che ha lo scopo di illustrare le modalità che gli utenti devono seguire per il suo corret-‐
to utilizzo.
1
Per quanto riguarda i possibili sviluppi futuri di tale lavoro, ci si propone, in primo luogo, di definire un’esaustiva campagna sperimentale, dedicata a comprendere i punti di debo-‐
lezza e quelli di forza dell’approccio proposto, rispetto a quelli attualmente in uso per la diagnostica sulle anemie.
Inoltre, a fronte di una fase di sperimentazione positiva riguardo l ’attuale algoritmo deci-‐
sionale utilizzato per la diagnostica, è prevista l’implementazione di ulteriori algoritmi decisionali riguardanti altre patologie.
Alfonso Mar no | 67
1
68 |Alfonso Mar
BIBLIOGRAFIA
1
1.
Anemia. http://emedicine.medscape.com/article/198475-overview, 2014.
2.
Anemia. http://www.medicitalia.it/salute/anemia, 2014. 3.
Apache. Cordova http://cordova.apache.org/, 2014.
4.
Architettura del sistema iOS. http://www.mrwebmaster.it/mobile/panoramicaarchitettura-ios_10526.html, 2014.
5.
Architettura del sistema software. http://blog.aziendeitalia.com/
larchitettura-client-server-sul-web, 2014. 6.
Architettura del sistema software. http://msdn.microsoft.com/it-it/library/
cc185057.aspx, 2014.
7.
CSS. http://www.html.it/css/, 2014.
8.
CSS. http://www.w3schools.com/css/, 2014. 9.
Framewrok Onsen UI. http://onsen.io/, 2014.
10. HTML5. http://www.html.it/guide/guida-html5/, 2014. 11. HTML5. http://www.w3schools.com/html/html5_intro.asp, 2014.
12. Interazione tra i componenti software. http://it.kioskea.net/contents/136sistema-client-server, 2014.
13. JavaScript. http://getbootstrap.com/javascript/, 2014.
14. JavaScript. http://www.html.it/javascript/, 2014.
15. JavaScript. http://www.w3schools.com/js/, 2014.
16. JSON. http://www.json.org/, 2014.
17. JSON. http://www.w3schools.com/json/, 2014.
Alfonso Mar no | 69
18. Mockup. http://balsamiq.com/products/mockups/, 2014.
19. MySQL. http://www.html.it/guide/guida-mysql/, 2014.
20. MySQL. http://www.mysql.it/, 2014. 21. PHP. http://php.net/, 2014.
22. PHP. www.w3schools.com/php/, 2014. 23. Xcode. https://developer.apple.com/xcode/, 2014.
24. A. Bosi, V. De Stefano, F. Di Raimondo, G. La Nasa, Manuale di m alattie del sangue. Ema-‐
tologia, Elsevier Masson Italia, 2012.
25. A. Chiappella, A. D’Alessio, Percorsi clinici in in Ematologia, Elsevier Masson Italia, 2009.
26. G. Avvisati, F. Mandelli, Ematologia di M andelli, Piccin Editore, 2013.
27. G. Castoldi, Liso Vincenzo, Malattie del sangue e degli o rgani e matopoietici quinta e dizio-‐
ne, Milano, McGraw-Hill, 2007.
28. G. D’Onofrio, G. Zini, Morfologia delle m alattie del sangue terza e dizione, V erduci Edito-‐
re, 2013.
70 |Alfonso Mar
no

theses - Barbiana 2.0 - Università degli Studi Mediterranea

Transcript

Documenti analoghi

1- Scarica da i-Tunes o Google Play l`App

Web Developer Settore assicurativo e Prodotti Salute

Sistema ITS, da Fondazione ITS Angelo Rizzoli e Miur un`app per l

iMonzino premiata migliore app 2012

Il docente di canto è a disposizione di quegli allievi che vogliono

Nuova versione iOS e Android per Watsy: l`app VoIP gratuita che

Lezioni sul tablet e con il microfono Come imparare (tutte) le lingue

Scarica il programma dettagliato del Corso

DidUP su Google Play DidUP su iTunes Store