Upload
maiko
View
258
Download
2
Embed Size (px)
Citation preview
Universita degli Studi di Trieste
Dipartimento di Ingegneria e ArchitetturaCorso di Laurea Magistrale in Ingegneria Informatica
Progetto e sviluppodi un’applicazione mobile
multipiattaformaper il supporto alle decisioni
collaborative
Candidato: Relatore:Michele Sinigoi Chiar.mo Prof. Alberto Bartoli
Correlatore:Ing. Paolo Vercesi
Anno Accademico 2012-13 - Sessione straordinaria
.
Ai miei genitori Mariagrazia e Aldoad Alice
alla mia famiglia eai miei amici.
Introduzione
Questo lavoro di tesi si occupera della progettazione e dello sviluppo di un’ap-
plicazione mobile multipiattaforma, che permetta agli utenti di classificare e
commentare i risultati delle simulazioni prodotte da un’applicazione web per
l’ottimizzazione multidisciplinare.
L’applicazione mobile dovra fungere da supporto ai processi decisionali gia in
atto all’interno di un’azienda, introducendo l’aspetto collaborativo, in grado
di migliorare sensibilmente la qualita delle decisioni prese dagli utenti. Il
progetto finale si comporra quindi delle seguenti parti:
• L’applicazione mobile multipiattaforma per il supporto alle decisioni
collaborative, in grado di presentare le informazioni principali dei pro-
getti su cui l’utente sta lavorando e di fungere da strumento utile al
processo decisionale collaborativo.
• La logica funzionale per la comunicazione tra l’applicazione mobile e
l’applicazione web su cui si trovano i dati dei design prodotti dalle
sessioni di ottimizzazione.
La realizzazione del progetto e dettata da una parte dalla necessita di fornire
uno strumento agli utenti per coordinare il proprio lavoro e di conseguenza
migliorare la qualita delle decisioni prese; dall’altra dallo studio della tecno-
logia per lo sviluppo di applicazioni mobile multipiattaforma, incentivato dal
continuo miglioramento delle prestazioni dei dispositivi.
Per la realizzazione del progetto sono stati affrontati i seguenti punti:
II
• Studio delle tecnologie disponibili per lo sviluppo di applicazioni mobili
multipiattaforma.
• Progettazione e realizzazione dell’applicazione mobile e della parte di
logica funzionale.
• Valutazione sperimentale delle prestazioni con diverse distribuzioni di
carico.
Per la realizzazione del progetto e stato richiesto l’utilizzo della tecnologia
JavaEE (Java Enterprise Edition) per la logica funzionale sul lato server,
mentre per il lato client ovvero l’applicazione mobile e stato possibile sceglie-
re autonomamente l’ambiente di sviluppo da utilizzare.
Nel capitolo 1 si valutano il contesto in cui si svolge la tesi, gli obiettivi, le cri-
ticita e gli strumenti utilizzati. Nel capitolo 2 vengono illustrate l’ideazione
e la progettazione del sistema. Nel capitolo 3 viene spiegato come utilizzare
l’applicazione mobile e come i vari moduli funzionano e sono stati implemen-
tati. Nel capitolo 4 si analizzano i risultati ottenuti nei test prestazionali
svolti sull’applicazione mobile e sulla parte di logica funzionale le presta-
zioni ottenute nelle fasi di classificazione dei design. Infine si presentano le
valutazioni complessive nel capitolo 5.
Indice
1 Analisi 1
1.1 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Collaborative decision making . . . . . . . . . . . . . . 1
1.1.2 Design optimization . . . . . . . . . . . . . . . . . . . 2
1.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Criticita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Strumenti di sviluppo mobile multipiattaforma . . . . . 6
1.4.2 Strumenti per simulation process and data management 8
1.4.3 Logica funzionale . . . . . . . . . . . . . . . . . . . . . 13
1.4.4 Algoritmo per il ranking dei design . . . . . . . . . . . 14
2 Progetto 17
2.1 Caso d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Progetti . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.2 Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3 Fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Applicazione mobile . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Invio e ricezione dei dati . . . . . . . . . . . . . . . . . 22
2.2.3 Classificazione dei design . . . . . . . . . . . . . . . . . 22
2.2.4 Visualizzazione dei risultati . . . . . . . . . . . . . . . 24
INDICE IV
2.2.5 Collaborazione tra utenti . . . . . . . . . . . . . . . . . 24
2.3 Logica funzionale . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Comunicazione con l’applicazione mobile . . . . . . . . 27
2.3.2 Interazione con SOMO . . . . . . . . . . . . . . . . . . 27
2.3.3 Creazione delle classifiche . . . . . . . . . . . . . . . . 27
2.3.4 Persistenza dei dati . . . . . . . . . . . . . . . . . . . . 28
3 Realizzazione 30
3.1 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.2 Selezione workspace . . . . . . . . . . . . . . . . . . . . 31
3.1.3 Selezione progetto . . . . . . . . . . . . . . . . . . . . . 31
3.1.4 Gestione del singolo progetto . . . . . . . . . . . . . . 31
3.1.5 Classificazione manuale dei design . . . . . . . . . . . . 33
3.1.6 Operazioni eseguibili sulle classfiche . . . . . . . . . . . 34
3.1.7 Visualizzazione dei design migliori . . . . . . . . . . . . 37
3.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Trasmissione di informazioni . . . . . . . . . . . . . . . 39
3.2.2 Classificazione dei design . . . . . . . . . . . . . . . . . 42
3.2.3 Persistenza . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Conclusioni 46
A Valutazione sperimentale delle prestazioni per un eventuale
sviluppo futuro 48
A.1 Setup dell’esperimento . . . . . . . . . . . . . . . . . . . . . . 49
A.2 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.3 Commento dei risultati . . . . . . . . . . . . . . . . . . . . . . 53
Bibliografia 54
Elenco delle figure
1.1 Esempio di dipendenze tra MDO e SDO . . . . . . . . . . . . 3
1.2 Diagramma Processo MDO . . . . . . . . . . . . . . . . . . . 4
1.3 Diagramma del funzionamento di Codename One . . . . . . . 8
1.4 Struttura di SOMO . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Dashboard di SOMO . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 L’interfaccia utente di modeFRONTIER. . . . . . . . . . . . . 13
1.7 Interazione tra livelli . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Progetto MDO considerato nel caso d’uso . . . . . . . . . . . . 18
2.2 Progetti SDO considerati nel caso d’uso . . . . . . . . . . . . . 19
2.3 Struttura dell’applicazione mobile . . . . . . . . . . . . . . . . 22
2.4 Suggerimento dei pesi di un MDO . . . . . . . . . . . . . . . . 25
2.5 Diagramma concettuale E/R . . . . . . . . . . . . . . . . . . . 29
3.1 Pagina di login. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Pagina per la selezione del workspace. . . . . . . . . . . . . . . 31
3.3 Progetti disponibili all’interno del workspace. . . . . . . . . . 32
3.4 Pagina con le ultime attivita. . . . . . . . . . . . . . . . . . . 32
3.5 Pagina principale di un progetto. . . . . . . . . . . . . . . . . 32
3.6 Sessioni di ottimizzazione tra cui poter scegliere. . . . . . . . . 34
3.7 Slider per decidere i pesi da assegnare. . . . . . . . . . . . . . 34
3.8 Suggerimenti in un progetto MDO. . . . . . . . . . . . . . . . 35
3.9 Messaggio di errore. . . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 Inserimento di un nuovo commento. . . . . . . . . . . . . . . . 36
3.12 Lettura dei commenti gia inseriti. . . . . . . . . . . . . . . . . 36
3.10 Pagina di gestione delle classificaizoni. . . . . . . . . . . . . . 36
3.13 Pagina con i cinque migliori design. . . . . . . . . . . . . . . . 37
3.14 Singolo design . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.15 Confronto diretto dei valori tra i design. . . . . . . . . . . . . 38
3.16 Grafico di confronto tra i design. . . . . . . . . . . . . . . . . 38
3.17 Login dell’utente su SOMO . . . . . . . . . . . . . . . . . . . 40
3.18 Strutture JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.1 Struttura di rete dell’esperimento . . . . . . . . . . . . . . . . 50
A.2 Tempo medio di classificaizone . . . . . . . . . . . . . . . . . . 51
A.3 Tempo medio di invio dei dati . . . . . . . . . . . . . . . . . . 51
A.4 Distribuzione dei dati rilevati . . . . . . . . . . . . . . . . . . 52
Elenco delle tabelle
2.1 Significato dei pesi attribuibili . . . . . . . . . . . . . . . . . . 23
A.1 Caratteristiche tecniche dei dispositivi utilizzati . . . . . . . . 49
A.2 Dati ricavati dalle misurazioni . . . . . . . . . . . . . . . . . . 50
A.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Capitolo 1
Analisi
1.1 Contesto
1.1.1 Collaborative decision making
Una decisione presa da un gruppo di persone, non piu come individui sin-
goli, ma come un’unita coesa, si dice collaborativa (in inglese: Collaborative
Decision Making o Group Decision Making).
Ciascuna persona all’interno del gruppo sfruttera le informazioni contenute
nella business intelligence [1], per esprimere la propria preferenza [2].
Risulta quindi necessario sviluppare degli strumenti, in grado di aiutare gli
utenti partecipanti ad un progetto a prendere nel miglior modo possibile le
decisioni operative. Le ricerche Gartner [3] considerano gli elementi di una
decisione collaborativa i seguenti:
• Persone
• Rete sociale
• Collaborazione
• Strumenti decisionali
• Informazioni
1.1 Contesto 2
Le persone coinvolte all’interno delle decisioni devono essere selezionate ac-
curatamente, vanno incorporati esperti, con opinioni diverse cosı da minimiz-
zare i pregiudizi sull’argomento. Vanno supportati da una rete sociale che
esamini le relazioni esistenti tra i decisori, e che controlli il flusso di infor-
mazioni, cosı da fornire ulteriori dati utili per produrre una decisione finale.
Per collaborazione si intende lo spazio condiviso dalle persone coinvolte, sia
fisico (uffici o sale conferenza), che virtuale, sotto forma di strumenti per la
comunicazione quali chat, email, videoconferenza e telefono. Gli strumen-
ti decisionali sono riassumibili in simulazioni, ottimizzazioni, pianificatori di
scenario, di analisi e di mercato, risultano essere sempre piu importanti nello
sviluppo della decisione finale, basandosi su dati concreti, ovvero le informa-
zioni contenute negli strumenti di business intelligence, in grado di eliminare
quasi del tutto le ambiguita che altrimenti si verrebbero a creare. Bisogna
quindi riuscire a presentare le informazioni nel modo piu chiaro possibile
e aumentare la quantita delle operazioni eseguibili sui dati in possesso del
gruppo decisore.
Vedremo nella Sezione 1.2, quali sono gli obiettivi di questo progetto di laurea
e come si integrano in un ambiente collaborativo.
1.1.2 Design optimization
Il processo di design optimization e la ricerca sistematica e automatizzata di
una soluzione nello spazio dei design, formato da tutte le possibili configura-
zioni delle variabili di input e output, dai vincoli e dalle funzioni obiettivo.
Per la creazione e l’ottimizzazione dei progetti considerati, sono stati utilizza-
ti modeFRONTIER e SOMO, sviluppati da ESTECO SpA1, entrambi i pro-
grammi verranno descritti in maniera piu approfondita nella Sezione 1.4.2.
Le sessioni di ottimizzazione genereranno dei design, i quali verranno resi
disponibili, per la consultazione e l’ordinamento, agli utenti attraverso l’ap-
plicazione mobile.
1http://www.esteco.com/
1.1 Contesto 3
I progetti a cui ci riferiremo e, ai quali il caso d’uso sara ispirato, saranno
del tipo multidisciplinare (in inglese: Multidisciplinary Design Optimization
o MDO), ovvero sara necessaria un’analisi di piu discipline caratterizzate da
diverse funzioni obiettivo. I singoli progetti saranno creati da diversi esper-
ti in maniera iterativa, distribuiti geograficamente, in possesso di strumenti
differenti per l’analisi e l’ottimizzazione [4].
Il nostro caso d’uso prevedera proprio l’utilizzo di un MDO, suddiviso in piu
sottoprogetti, che potranno essere a loro volta dei progetti multidisciplinari o
a disciplina singola (SDO), l’esempio in Figura 1.1 rappresenta graficamente
questa possibilita. Numerose aziende produttrici di complessi sistemi inge-
gneristici, studiano l’evoluzione dell’ottimizzazione multidisciplinare e la sua
integrazione con sistemi software in grado di fornire un aiuto concreto dal
punto di vista decisionale e organizzativo [5]. I vantaggi derivanti dall’otti-
mizzazione coinvolgono soprattutto le performance, il costo di produzione e
le tempistiche per lanciare sul mercato il prodotto finito. Ci si trova quindi
nella situazione di dover integrare piu strumenti e piu persone nel sistema
all’interno del processo di ottimizzazione come illustrato in Figura 1.2.
Figura 1.1: Esempio di dipendenze tra MDO e SDO
1.2 Obiettivi 4
Figura 1.2: Il diagramma riassume un processo MDO dalla suacreazione fino alla decisione finale. Possiamo vedere come i progetti
settoriali vadano a formare la base di uno multipiattaforma, che vieneutilizzato dall’utente finale per l’analisi e le decisioni finali.
1.2 Obiettivi
L’obiettivo principale di questa tesi e quello di sviluppare uno strumento
in grado di facilitare le decisioni collaborative all’interno di un gruppo di
persone, sia al lavoro su uno stesso progetto, che su progetti diversi, ma
riconducibili ad uno schema di ottimizzazione multidisciplinare, in cui si in-
tegrano MDO ed SDO. Un aspetto caratterizzante del progetto sara quello
di sviluppare lo strumento collaborativo per l’utilizzo su dispositivi mobili,
siano essi smartphone o tablet. Bisognera percio avere un quadro chiaro degli
strumenti di sviluppo disponibili sul mercato e sulle loro funzionalita, oltre
ad analizzare l’ambiente in cui ci si trova. Nella Sezione 1.4.1 verra illustrato
il processo di selezione della piattaforma di sviluppo.
1.3 Criticita
Avendo definito gli obiettivi del progetto, si vede immediatamente che le
criticita da affrontare saranno molteplici e di diversa natura. Possono essere
suddivise nelle seguenti categorie:
1.4 Strumenti 5
• La progettazione dello strumento collaborativo richiede un’attenta ana-
lisi dell’ambiente. Va infatti studiato approfonditamente per individua-
re i punti in cui, attraverso l’applicazione, poter offrire un miglioramen-
to, dal punto di vista decisionale per gli utenti, sfruttando quanto gia
presente e utilizzandolo come base per lo sviluppo.
• Scelta di una piattaforma di sviluppo, che permetta di realizzare un’ap-
plicazione, utilizzabile da piu utenti possibili, ed avendo optato per
lo sviluppo in ambiente mobile, dovra necessariamente essere multi-
piattaforma, data la frammentazione del mercato dei sistemi operativi
mobili.
• Studio della presentazione delle informazioni provenienti dagli strumen-
ti di ottimizzazione multidisciplinare (SOMO e modeFRONTIER), per
renderle fruibili alle persone coinvolte nel processo decisionale.
• Studio delle API2 degli strumenti utilizzati, in particolare quelle di
SOMO, sia per la progettazione, che per la scelta della piattaforma da
utilizzare.
1.4 Strumenti
Gli strumenti necessari per la realizzazione del progetto, si divideranno tra:
• Sviluppo software (mobile e server).
• Creazione e gestione dei progetti.
• Persistenza dei dati.
• Strumenti matematici per l’ordinamento di design secondo determinati
criteri.
2Application Programming Interface
1.4 Strumenti 6
Andremo ora ad elencarli ed analizzarli, tenendo conto delle criticita espresse
nella Sezione 1.3.
1.4.1 Strumenti di sviluppo mobile multipiattaforma
Come abbiamo visto nelle sezioni precedenti, si vuole dare la possibilita a piu
utenti di utilizzare l’applicazione, per poter esprimere le proprie preferenze,
relativamente ai risultati delle simulazioni e partecipare al processo decisio-
nale. Per fare questo, si e cercato un sistema di sviluppo multipiattaforma, in
grado cioe, a fronte di un’unica scrittura del codice, di generare applicazioni
per diversi sistemi operativi mobile contemporaneamente.
Individuiamo quindi le seguenti caratteristiche fondamentali della ricerca:
• Supporto per il maggior numero possibile di sistemi operativi per di-
spositivi mobili, fondamentale soprattutto per Android, iOS, Windows-
Phone e RIM.
• Linguaggio di programmazione quanto piu possibile inserito nel conte-
sto aziendale di ESTECO.
• L’applicazione prodotta deve avvicinarsi, a livello prestazionale, ad
una applicazione nativa, cioe sviluppata espressamente per un sistema
operativo specifico e non per piu d’uno come indicato negli obiettivi.
• Disponibilita di un SDK3, con simulatore integrato, utile nella fase di
sviluppo per evitare i tempi morti dovuti alla prova su dispositivo fisico.
Codename One
Da una ricerca effettuata in precedenza nel contesto aziendale e stato indivi-
duato un sistema di sviluppo che soddisfa le richieste del punto precedente:
Codename One4. Illustriamo ora le principali caratteristiche, che ci hanno
3Software Development Kit4http://www.codenameone.com/
1.4 Strumenti 7
portato a sceglierlo per lo sviluppo della nostra applicazione.
L’ambiente e multipiattaforma, vengono infatti supportati i principali sistemi
operativi mobili: Android, iOS, WindowsPhone, RIM, JavaME, coprendo la
quasi totalita del mercato. La compilazione del progetto avviene online, at-
traverso un build server, il quale produrra l’applicazione in codice nativo per
il sistema operativo selezionato (Figura 1.3); si potra quindi installarla sul
proprio dispositivo, o inviarla ad uno degli store pubblici5 rendendola cosı
disponibile per altri utenti. Le prestazioni dell’applicazione cosı realizzata
verranno ad essere comparabili a quelle scritte in codice nativo, sviluppate
cioe specificatamente per un unico sistema operativo mobile.
Il linguaggio di programmazione utilizzato in Codename One e Java [6], lin-
guaggio gia noto all’autore della tesi e gia utilizzato all’interno dell’azienda,
le API utilizzate saranno quelle di Java, tranne per alcune classi, adattate
per funzionare su dispositivi mobili [7]. Codename One viene distribuito co-
me plugin per i seguenti ambienti di sviluppo: NetBeans, Eclipse e IntelliJ
IDEA. Risultera pertanto un vantaggio poter utilizzare un ambiente gia co-
nosciuto e in grado di essere utilizzato anche nello sviluppo di altre parti del
progetto. Viene messo a disposizione un simulatore, che permette di prova-
re immediatamente l’applicazione in fase di realizzazione, evitando i tempi
morti dovuti alla compilazione online e al download sul dispositivo.
5Ad esempio Google Play Store, Apple Store, Windows Store
1.4 Strumenti 8
Figura 1.3: Codename One offre la possibilita di utilizzare unsimulatore per provare le applicazioni in fase di scrittura, senza dovereseguire il download sul dispositivo. Per poter generare applicazioni a
livello nativo si ha a disposizione un build server, che compila il codiceinviato direttamente dall’ambiente di sviluppo utilizzato, e dal quale e
poi possibile ottenere l’applicazione e provarla.
1.4.2 Strumenti per simulation process and data ma-
nagement
Come descritto in precedenza, i risultati delle simulazioni presentati agli uten-
ti sono generati da strumenti per il simulation process e data management
come SOMO e modeFRONTIER, che illustreremo di seguito.
1.4 Strumenti 9
SOMO
SOMO6 e un’applicazione enterprise, che crea un ambiente collaborativo e
distribuito, anche geograficamente, mirato a gestire le complessita derivan-
ti dall’esecuzione di progetti di ottimizzazione multidisciplinare. Riesce ad
integrare utenti, processi e dati all’interno del processo di progettazione,
soprattutto nelle fasi di simulazione ed ottimizzazione dello sviluppo del pro-
dotto.
Vediamo ora quali sono le possibilita offerte piu dettagliatamente:
• Collaborazione. SOMO e un ambiente multiutente e multiruolo, do-
ve persone con ruoli diversi, non necessariamente in un ambiente fi-
sico comune, concorrono simultaneamente alla risoluzione degli stessi
problemi di progettazione, condividendo modelli, progetti, simulazioni,
ottimizzazioni e risultati nello stesso momento.
• Accesso web. Viene offerto ovunque in qualsiasi momento, attraver-
so un browser, che permette di avviare simulazioni ed ottimizzazioni e
controllarne i risultati direttamente online. Si mantiene inoltre un con-
trollo sull’accesso, le dipendenze tra i progetti facenti parte dell’MDO,
i permessi e le versioni dei progetti.
• Versioning dei progetti. Grazie al controllo della consistenza dei
repository e al versionamento delle informazioni e possibile editare in
maniera concorrente i modelli, i processi e i risultati.
• DOE7 multipli e strategie di ottimizzazione. Possono essere crea-
te da utenti esperti e messi a punto a seconda delle esigenze [10, 11].
Altri utenti potranno poi riutilizzarle per i loro progetti.
• Esecuzione distribuita. Il sistema indirizza le esecuzioni su diver-
se code di valutazione, grazie a questo e possibile distribuire il carico
6http://www.esteco.com/somo7Design of Experiment
1.4 Strumenti 10
sulle risorse disponibili e controllare lo stato delle risorse computazio-
nali ancora a disposizione, bilanciare esecuzioni simultanee, controllare
esecuzioni remote, inoltre si possono far eseguire le valutazioni sia in
ambienti cloud, che HPC8.
• Analisi dei risultati e report. Attraverso le librerie messe a disposi-
zione nella fase di analisi dei dati, che facilitano il processo di decisione
finale.
Per gli scopi di questa tesi, poiche l’applicazione realizzata dovra interfac-
ciarsi con SOMO, sara molto importante la conoscenza approfondita del-
l’architettura di SOMO e delle funzioni offerte attraverso l’API. SOMO e
suddiviso in Workspaces, a cui ogni utente puo venire assegnato, garantendo
eventualmente privilegi diversi a seconda del ruolo ricoperto. All’interno di
ogni workspace troviamo i Projects, sui quali possiamo eseguire le sessioni
di ottimizzazione o Sessions. La sessione se eseguita su un progetto MDO,
verra simultaneamente eseguita anche sugli SDO, essendone ciascuno parte
integrante. I design ottenuti verranno poi resi disponibili per essere clas-
sificati dall’applicazione oggetto della tesi, in base alle preferenze espresse
dai soggetti partecipanti al processo decisionale. Nella Figura 1.4 vediamo
un esempio della struttura di SOMO, mentre in Figura 1.5 la dashboard di
SOMO cosı come viene presentata all’utente sul suo web browser, distinguen-
do le informazioni relative a workspace, progetti e sessioni. In SOMO non
e ancora disponibile una funzionalita di supporto alle decisioni collaborative
come quella sviluppata in questo progetto.
modeFRONTIER
modeFRONTIER9 e una piattaforma desktop di integrazione per ottimizza-
zioni multiobiettivo e multidisciplinari, permette l’automazione della simu-
lazione progettuale e facilita il processo decisionale analitico.
8High Performance Computing9http://www.esteco.com/modefrontier
1.4 Strumenti 11
Figura 1.4: SOMO permette di assegnare i progetti all’interno diworkspace, un progetto puo essere presente in piu workspace, le sessioni
di ottimizzazione producono i design dai quali si ricaveranno leinformazioni necessarie. Su ogni progetto possono venir eseguite piu
sessioni di ottimizzazione, utilizzando le opzioni rese disponibiliall’interno del programma.
Figura 1.5: La dashboard presenta le varie sezioni consultabiliall’utente, raggiungibili sia dalla barra del menu in alto, che dai widget
nei quali sono visualizzate le informazioni in maniera completa edimmediatamente accessibile.
1.4 Strumenti 12
I problemi multiobiettivo vengono risolti attraverso l’utilizzo di algoritmi di
ottimizzazione, che identificano un insieme di design di Pareto [12]. Tale
insieme caratterizza i problemi di ottimizzazione che presentano obiettivi
contrastanti, in tale situazione l’individuazione di un design ottimo non e
univoca. L’utente puo scegliere la strategia di ottimizzazione in base al tipo
e al numero di variabili, vincoli e obiettivi; robustezza e affidabilita richiesta
e risorse computazionali disponibili. L’integrazione con altri software auto-
matizza questo processo, permettendo un approccio multidisciplinare, che
generera un insieme di soluzioni globalmente ottime, invece di una per ogni
disciplina sequenzialmente.
Sono tre gli ambienti in cui e suddiviso modeFRONTIER:
• Workflow, permette di definire le variabili di input e output, i vincoli
e gli obiettivi, nonche le strategie di ottimizzazione. Integrando il pro-
cesso tra i vari software in uso, estraendo, aggiornando e trasferendo i
dati.
• Esecuzione dell’analisi, avviene in maniera dinamica e modulare, e
infatti possibile monitorare l’avanzamento del processo di ottimizzazio-
ne.
• Spazio di progettazione e dove si analizzano i risultati delle sessioni
di ottimizzazione, attraverso la visualizzazione di grafici e tabelle, che
aiutano nel complesso processo decisionale.
Nel nostro progetto utilizzeremo solo alcune delle funzionalita offerte, ovvero
la creazione dei progetti, in Figura 1.6, per ottenere un caso d’uso su cui
eseguire delle sessioni di ottimizzazione, sessioni che verrrano pero svolte
in SOMO, in quanto sara fondamentale poter accedere ai dati generati da
qualsiasi locazione geografica, disponendo di una connessione ad internet sul
proprio dispositivo mobile, come illustrato negli obiettivi iniziali.
1.4 Strumenti 13
Figura 1.6: L’interfaccia utente di modeFRONTIER.
1.4.3 Logica funzionale
Per poter rendere possibile alcune operazioni, quali, ad esempio, l’auten-
ticazione o la richiesta di dati, tra l’applicazione mobile e SOMO, e stato
necessario implementare una struttura intermedia, ovvero un livello di logi-
ca funzionale o business layer [8], capace di adempire a questo compito in
maniera modulare, come illustrato in Figura 1.7. L’utilizzo di un livello in-
termedio, in un’architettura multi-tier, permette di implementare le API o al
livello del client (la nostra applicazione mobile) o nel business layer, a secon-
da delle possibilita offerte dagli ambienti di sviluppo scelti. Per lo sviluppo
della logica funzionale utilizzeremo Java EE10 [9], la piattaforma di sviluppo
enterprise per il linguaggio Java.
10Java Platform, Enterprise Edition
1.4 Strumenti 14
Figura 1.7: Il business layer funge da tramite tra l’applicazionemobile e SOMO.
GlassFish
L’application server scelto per l’implementazione della logica funzionale e
GlassFish11, versione 3.1.2.2 [13, 14], che per evitare problemi di compati-
bilita e la stessa utilizzata per SOMO. Utilizzeremo le seguenti funzionalita
messe a disposizione da GlassFish:
• Enterprise Java Bean, che implementano la logica di business da par-
te del server, in particolare garantiscono la persistenza e la transazio-
nalita, oltre al controllo della concorrenza.
• Java Persistence API, utilizzate per la persistenza dei dati su un
DBMS12 relazionale.
• Java DataBase Connectivity, per il collegamento ad un DBMS,
utilizzeremo quello incluso in GlassFish, ovvero Java DB.
1.4.4 Algoritmo per il ranking dei design
Per poter ordinare, classificandoli (ranking), i design di Pareto di un progetto
ottenuti da una sessione di ottimizzazione, avremo bisogno di un algoritmo
in grado di calcolare, in base alle preferenze espresse dall’utente sulle singole
variabili, una classifica, che sia poi accessibile per successive consultazioni e
valutazioni. In un primo momento l’utente assegna, ad ogni variabile utiliz-
zata durante l’ottimizzazione, un peso e la posizione in classifica del design
risulta essere la somma pesata del prodotto tra il peso normalizzato e il valore
11https://glassfish.java.net/index.html12DataBase Management System
1.4 Strumenti 15
che il design assume per la variabile in considerazione, ovvero:
U(ai) =n∑
j=1
wj · aij (1.1)
dove ai e il design i-esimo, wj e il peso per la variabile j-esima e aij e il
valore che il design i-esimo assume per la variabile j-esima. Si passa quindi
all’algoritmo di selezione.
L’Analytic Hierarchy Process (AHP) utilizzato e uno dei piu famosi nell’am-
biente del decision making [15, 16], in quanto combina l’aspetto soggettivo e
oggettivo delle opinioni, e integra le priorita del gruppo dei decisori con quelle
individuali. Utilizzare l’AHP in processi decisionali necessita di aggregare i
giudizi individuali in un unico, collettivo, e dalle singole preferenze ottenerne
una per l’intero gruppo [17].
Per funzionare l’algoritmo avra bisogno di un insieme di criteri (i pesi asse-
gnati alle variabili, ai vincoli e agli obiettivi, nel nostro caso) e di uno con le
opzioni da valutare (i design prodotti dalle sessioni di ottimizzazione). Ad
ogni criterio viene assegnato un peso relativo alla sua importanza rispetto
agli altri, poi per ogni criterio si esegue un confronto a coppie tra i design
sul criterio considerato, dove piu alto sara il valore ottenuto, migliore sara il
design in quel determinato ambito di valutazione. Infine si combinano i pesi,
assegnati ai criteri, ai risultati ottenuti sui design e si produce la classifica
finale, il risultato ottenuto dal singolo design e la somma pesata dei risultati
ottenuti, tenendo conto dei pesi di tutti i criteri [18]. Vediamo ora quanto
appena espresso con un maggior grado di dettaglio.
Viene creata una matrice, per il confronto a coppie dei criteri da valutare, di
dimensione n x n. Ogni elemento della matrice ajk rappresenta l’importanza
del criterio j-esimo, rispetto al k-esimo, utilizzando una scala da 1 a 9. Se
ajk > 1 allora il j-esimo e il piu importante dei due, viceversa se ajk < 1 sara
il k-esimo ad esserlo, nel caso in cui ajk = 1 allora avranno la stessa impor-
tanza. Gli elementi nelle posizioni ajk e akj dovranno soddisfare il seguente
1.4 Strumenti 16
vincolo:
ajk · akj = 1 (1.2)
mentre akk = 1,∀k.
Si diagonalizza quindi la matrice contenente le valutazioni e si tiene in consi-
derazione solamente l’autovettore normalizzato corrispondente all’autovalore
massimo λmax; l’autovettore normalizzato rappresentera il vettore dei pesi di
ciascuno criterio. Il processo appena descritto si applica anche alle matrici
costruite con le valutazioni confrontando coppie di design per un determina-
to criterio. Supponendo quindi di avere n design e k criteri, l’AHP funziona
nella seguente maniera:
• Vettore dei pesi. si diagonalizza una matrice k x k; corrispondente
all’autovalore massimo, normalizzo l’autovettore ottenendo il vettore
dei pesi w;
• Matrice degli autovettori. si costruiscono k matrici, una per ogni
criterio, n x n in cui si confrontano a coppie i designs. Le matrici ven-
gono poi utilizzate nella medesima maniera seguita per calcolare il vet-
tore dei pesi. La matrice contenente tutti gli autovettori normalizzati
la indichiamo con A;
• Ranking. La matrice ranking R sara uguale a:
R = A ·w (1.3)
Il ranking finale si otterra quindi ordinando in ordine decrescente il
vettore R.
Capitolo 2
Progetto
Definiamo il caso d’uso in cui opereremo, introducendo lo scenario e gli attori,
che vi interagiscono. Descriviamo inoltre i passi necessari per la progettazione
dell’applicazione mobile e della logica funzionale, che fungera da tramite
interrogando SOMO, per ricavare le informazioni necessarie all’utente.
2.1 Caso d’uso
2.1.1 Progetti
L’ambiente in cui ci si trova e caratterizzato da progetti MDO ed SDO,
il nostro caso d’uso prevedera l’utilizzo di un progetto multidisciplinare, e
due sottoprogetti o SDO. Vediamo uno schematico del progetto MDO in
Figura 2.1 e dei due sottoprogetti in Figura 2.2.
2.1 Caso d’uso 18
Figura 2.1: Nel progetto MDO considerato nel caso d’uso vediamocome le variabili siano le stesse utilizzate nei due sottoprogetti (SDO1 eSDO2). Le variabili di output sono anch’esse derivate dagli SDO. Una
sessione di ottimizzazione eseguita sul progetto MDO, creera unasessione con le stesse caratteristiche anche per ciascuno dei
sottoprogetti coinvolti.
2.1 Caso d’uso 19
(a) SDO1
(b) SDO2
Figura 2.2: Si osserva come gia i due progetti SDO abbiano duevariabili in comune tra di loro, i pesi assegnati dagli utenti andranno
poi valutati dal decisore finale, in caso di conflitto.
Possiamo notare come gli obiettivi del progetto multidisciplinare siano quelli
dei due SDO, i quali hanno a loro volta hanno due variabili in comune.
2.1 Caso d’uso 20
2.1.2 Utenti
Avremo due tipologie differenti di progetto (MDO ed SDO), su ciascuno dei
quali lavorera una tipologia di utenti. Entrambe le categorie saranno in grado
di eseguire una classificazione (ranking) dei design ottenuti da una sessione di
ottimizzazione, che verra eseguita sul progetto MDO, e contemporaneamente
sui due sottoprogetti. La classificazione avverra assegnando dei pesi alle
variabili, ai vincoli e agli obiettivi dei design da parte dell’utente, e restituira
i migliori cinque design. Verranno analizzati solo cinque design, per poter
rendere piu facilmente consultabili le informazioni anche su un dispositivo
mobile. Gli utenti si differenzieranno per le seguenti caratteristiche:
• Utenti del progetto multidisciplinare, il cui compito sara quello di se-
lezionare il design migliore, tra quelli ottenuti. Hanno inoltre la pos-
sibilita di eseguire un ranking senza attribuire i pesi, ma basandosi
esclusivamente sulle classificazioni eseguite dagli utenti dei sottopro-
getti.
• Utenti dei sottoprogetti, che dovranno suggerire agli utenti del progetto
multidisciplinare, in base alle loro valutazioni, i pesi da attribuire alle
variabili in comune tra il progetto SDO su cui stanno lavorando ed il
progetto multidisciplinare.
2.1.3 Fasi
Distinguiamo le seguenti fasi nel caso d’uso studiato, atte a selezionare il
design migliore per il progetto multidisciplinare:
• Sessione di ottimizzazione eseguita sul progetto MDO.
• Classificazione dei design migliori nei sottoprogetti.
• Analisi dei design migliori e confronto tra gli utenti di ciascun sotto-
progetto, per scegliere i pesi da suggerire al progetto multidisciplinare.
2.2 Applicazione mobile 21
• L’utente dell’MDO utilizzando o meno i suggerimenti degli utenti, ese-
gue la classificazione sul progetto.
• Analisi dei design migliori e confronto tra gli utenti del progetto mul-
tidisciplinare.
• Scelta del design migliore da parte del decisore finale (utente MDO).
2.2 Applicazione mobile
L’applicazione mobile dovra essere in grado di ottenere le informazioni riguar-
danti i design prodotti dalle sessioni di ottimizzazione, eseguite con SOMO, e
presentarle agli utenti. Si dovranno pertanto sviluppare dei moduli in grado
di inviare e ricevere le informazioni via via necessarie, per ottenere i dati
voluti. All’utente sara permessa la navigazione tra i workspace, i progetti
e le sessioni a cui e abilitato, potra inoltre classificare le varie sessioni di
ottimizzazione per ottenere da ognuna i cinque migliori design e successiva-
mente, nel caso si lavori all’interno di un progetto multidisciplinare (MDO),
scegliere una di queste come la favorita da suggerire agli utenti dell’MDO.
L’applicazione sara una piattaforma collaborativa, fornira infatti gli stru-
menti necessari alla comunicazione tra gli utenti, sotto forma di commenti
alle varie sessioni classificate, rendendo possibile l’analisi del lavoro svolto e
quindi la pianificazione di quello successivo, riclassificando i design.
Vediamo ora come si struttura l’applicazione (uno schema e visibile in Fi-
gura 2.3), descrivendo le singole parti coinvolte e la loro interazione con le
altre.
2.2.1 Autenticazione
L’utente dovra autenticarsi per poter accedere ai dati, da lui visualizzabili,
presenti su SOMO. L’applicazione quindi presentera una pagina per il login
dell’utente, che inserira il nome utente e la password del suo account di
2.2 Applicazione mobile 22
Figura 2.3: La struttura dell’applicazione mobile, l’utente potranavigarvi al suo interno attraverso il proprio dispositivo, infatti ogni
elemento della figura sara una pagina.
SOMO e rimarra autenticato per tutto il tempo necessario, fino alla chiusura
dell’applicazione.
2.2.2 Invio e ricezione dei dati
Vi sara la necessita di inviare e ricevere i dati da parte dell’applicazione
mobile, dovra pertanto essere utilizzato un sistema per la trasmissione dei
dati, viste le caratteristiche tipiche di una situazone client (applicazione mo-
bile) server (business layer) si usera il protocollo di trasferimento HTTP1 con
chiamate di tipo REST[19].
2.2.3 Classificazione dei design
L’applicazione mobile oltre alla navigazione nella struttura di SOMO, per-
mettera all’utente, di assegnare i pesi a ciascuna variabile, vincolo e obiettivo.
Con l’assegnamento dei pesi si intende attribuire un valore da 0 a 5, in cui 0
1Hypertext Transfer Protocol
2.2 Applicazione mobile 23
rappresenta il non interesse verso quella particolare variabile, mentre 5 indi-
chera l’interesse massimo, come indicato nella Tabella 2.1. L’intervallo [0-5]
e stato scelto in accordo con le specifiche fornite dall’azienda.
Peso Significato
5 Massima importanza
4 Grande importanza
3 Media importanza
2 Bassa importanza
1 Minima importanza
0 Nessuna importanza (non inserita nella valutazione)
Tabella 2.1: Significato dei pesi attribuibili a variabili di input eoutput, vincoli e funzioni obiettivo.
Una volta assegnati i pesi l’algoritmo AHP opportunamente modificato, si
occupera di stilare una classifica dei design ottenuti dalla sessione di ot-
timizzazione precedentemente effettuata in SOMO. Vengono quindi salvati
all’interno di un’apposita tabella del database i migliori cinque design tro-
vati, cosı da poterli poi visualizzare nell’apposita pagina, qualora uno degli
utenti desiderasse controllarne le caratteristiche.
Nel processo di assegnazione dei pesi viene fornito al decisore finale un sug-
gerimento sui valori da assegnare alle variabili, infatti vengono visualizzati
i pesi, della classificazione scelta come preferita, assegnati dagli utenti dei
sottoprogetti. Risulta fondamentale la possibilita di aggiungere i commenti
per poter comunicare la decisione su quale sia il ranking migliore, sia all’in-
terno del sottoprogetto, che tra utenti MDO ed SDO contemporaneamente,
l’arogmento verra approfondito nella Sezione 2.2.5.
Nel caso in cui un utente del progetto multidisciplinare non abbia conoscen-
za del significato delle variabili, oppure pensi che le valutazioni svolte dagli
utenti degli SDO siano gia ottime, si aggiunge la possibilita di eseguire un’o-
perazione di ranking automatica, basandosi sulle classificazioni preferite dei
2.2 Applicazione mobile 24
sottoprogetti. In questo caso si utilizzera una media pesata, per ottenere la
classifica finale dei design, e presentare all’utente i migliori cinque.
2.2.4 Visualizzazione dei risultati
Per poter consentire agli utenti di valutare se la classificazione ha prodotto
un risultato soddisfacente, si metteranno a disposizione delle pagine riassun-
tive e comparative per i design, anche con l’ausilio di un grafico. Verranno
presentati i singoli valori delle variabili, dei vincoli e degli obiettivi dei cinque
migliori design, anche tutti nella stessa schermata per poterne confrontare i
valori direttamente. L’ambiente di sviluppo mette inoltre a disposizione la
possibilita di generare alcune tipologie di grafico (torta, barre, dispersione) a
partire da un insieme di dati, che sara utilizzato per produrre un confronto
visivo tra i design migliori.
2.2.5 Collaborazione tra utenti
L’applicazione deve fornire un supporto alle decisioni collaborative. Gli uten-
ti potranno commentare le classificazioni eseguite sulle sessioni di ottimizza-
zione, esprimendo cosı le loro opinioni prenderanno parte attivamente alla
scelta dei design migliori sia dei sottoprogetti che del progetto multidisci-
plinare. Inoltre si rende disponibile una message board, nella quale vengono
automaticamente registrati gli eventi all’interno di ogni workspace. In en-
trambi i casi per garantire la persistenza delle informazioni relative alle scelte
effettuate ci si affidera ad un DBMS.
Suggerimento dei valori
La collaborazione tra i diversi livelli di un progetto multidisciplinare si realiz-
za dando la possibilita agli utenti, che lavorano sullo stesso sottoprogetto, di
selezionare, tra le classificazioni gia eseguite, quella che ha prodotto i cinque
migliori design. Questa dovra quindi ad essere segnalata, all’interno della
2.2 Applicazione mobile 25
Figura 2.4: Nel primo esempio ogni sottoprogetto attribuisce un pesoalla variabile a, l’SDO1 attribuira 2, quindi poca importanza, l’SDO2
invece 5, la massima possibile. Andra pertanto stabilito un nuovovalore, e dovra essere l’utente impegnato nella classificazione a farlo.
Nel secondo esempio invece, poiche per l’SDO1 la variabile a ha peso 0,quindi non interesse, verra utilizzato solo il suggerimento proveniente
dall’SDO2, evitando cosı il conflitto visto in precedenza.
tabella del database che la contiene.
Gli utenti operanti sull’MDO, troveranno segnalati i valori utilizzati all’in-
terno delle classificazioni favorite, se presenti, di ciascun sottoprogetto, co-
noscendo pertanto da quale disciplina proviene il suggerimento (come si vede
in Figura 2.4), potranno valutare al meglio la classificazione da eseguire sul
progetto completo.
Commenti
La comunicazione risulta fondamentale, sia tra utenti che lavorano sullo stes-
so progetto (o sottoprogetto), sia che lavorino su livelli diversi. Decidere quali
siano le classificazioni favorite per ogni sessione di ottimizzazione come un’u-
nita coesa migliora la qualita della decisione finale. Si introdurra quindi un
sistema per commentare le singole classificazioni, o semplicemente leggere i
commenti degli altri utenti.
Il sistema salvera in una tabella del database i singoli commenti, dalla stessa
verranno recuperati quando richiesto e visualizzati per essere consultati dagli
utenti, siano essi del sottoprogetto o dell’MDO a cui quest’ultimo appartiene.
2.3 Logica funzionale 26
Cronologia Eventi
Un’ulteriore supporto fornito agli utenti e la cronologia degli eventi del
workspace, in cui sara possibile trovare le principali attivita svolte, tra cui:
• Nuova classificazione eseguita
• Nuova classificazione preferita selezionata
• Nuova sessione di ottimizzazione eseguita
• Eliminazione di una classificazione
• Nuovo commento riguardante una classificazione aggiunto
L’utente avra cosı a disposizione la pagina in cui vedere immediatamente
quali sono le attivita piu recenti, i messaggi rimangono disponibili una setti-
mana poi vengono cancellati, per non rendere troppo esoso il carico di dati
inviati e ricevuti tra servlet e applicazione mobile.
Anche in questo caso dovranno essere salvati all’interno di un database per
rendere persistenti le informazioni riguardanti gli ultimi eventi.
2.3 Logica funzionale
Il livello di logica funzionale dovra fungere da tramite tra l’applicazione mobi-
le e SOMO, ovvero ricevere le richieste da parte degli utenti inviate attraverso
l’applicazione mobile e inoltrarle a SOMO. Le risposte andranno poi fornite
all’utente nel formato piu adatto alla consultazione. Inoltre dovra occuparsi
della persistenza dei dati, sia quelli riguardanti i design migliori, che quelli
riguardanti i commenti alle classificazioni, fondamentali dal punto di vista
collaborativo. Un altro compito sara quello di classificare i design attraverso
l’utilizzo dell’algoritmo AHP.
Nelle prossime sezioni vedremo come e stato progettato il livello per adempire
a questi compiti.
2.3 Logica funzionale 27
2.3.1 Comunicazione con l’applicazione mobile
Come abbiamo visto nelle Sezioni 2.2.1 e 2.2.2 le richieste verranno ricevu-
te attraverso il protocollo HTTP, quindi processate all’interno del business
layer a seconda della richiesta, che potra ad esempio richiedere informazioni
direttamente a SOMO, o eseguire l’algoritmo AHP per la generazione di una
classifica di design.
2.3.2 Interazione con SOMO
Poiche l’ambiente di sviluppo mobile Codename One non permette una facile
integrazione di API esterne, come sono quelle messe a disposizione da SO-
MO, sara la logica funzionale ad utilizzarle una volta arrivate le richieste. Le
API vengono fornite per il linguaggio di programmazione Java, lo stesso uti-
lizzato dall’application server (GlassFish) e da Codename One, integrandosi
perfettamente nell’ambiente. I dati ottenuti da SOMO verranno poi inviati
all’applicazione mobile.
2.3.3 Creazione delle classifiche
Quando sara richiesto, da parte dell’utente, di produrre una classifica dei
design, ottenuti da una sessione di ottimizzazione, la logica funzionale si oc-
cupera dell’ordinamento. Sara necessario realizzare due implementazioni dif-
ferenti, in una si utilizzera l’algoritmo AHP modificato, poiche i pesi verranno
assegnati manualmente dall’utente, nel caso della classificazione automatica
invece, si utilizzeranno le classifiche gia realizzate per i sottoprogetti.
• Classificazione con assegnazione dei pesi manuale. All’utente
verra presentata la possibilita di dare un peso, che rifletta l’importan-
za nel contesto del progetto di ciascuna variabile e di ciascun vincolo.
Come abbiamo visto nella Sezione 2.2.5 nel caso si valuti un progetto
multidisciplinare verranno visualizzate le scelte effettuate dagli uten-
ti nei sottoprogetti. Pertanto i pesi necessari all’algoritmo AHP per
2.3 Logica funzionale 28
funzionare verranno forniti dall’utente stesso. Una volta ottenuta la
classifica dei design, si salveranno i cinque migliori design su un’appo-
sita tabella del database, cosı da essere consultabili e commentabili da
parte degli utenti in futuro.
• Classificazione automatica. Questo tipo di opzione viene fornito so-
lo agli utenti di un MDO i cui SDO hanno un ranking favorito gia deciso.
Le classifiche dei sottoprogetti saranno utilizzate dall’algoritmo per cal-
colare i pesi da assegnare alle singole variabili. In questo caso non sara
necessario salvare il risultato su di una tabella del database, la pagina
contenente i design migliori verra proposta immediatamente all’utente,
poiche quest’ultimo non ha espresso una valutazione, assegnando i pesi,
non risulta interessante dal punto di vista collaborativo.
2.3.4 Persistenza dei dati
L’applicazione avra bisogno di salvare determinate informazioni su di un da-
tabase, in particolare utilizzeremo quattro tabelle per garantire la persistenza
dei dati.
• Evaluation. In questa tabella salveremo le classificazioni effettuate
dagli utenti, saranno poi identificabili tramite la sequenza dei pesi as-
segnati a variabili, vincoli e funzioni obiettivo. Verra inoltre salvata la
classifica prodotta dall’algoritmo AHP, servira infatti nell’operazione
di classificazione automatica disponibile per i progetti multidisciplina-
ri. Infine viene indicato se la classificazione e stata scelta come favorita
dagli utenti.
• Best. Vengono inoltre salvati al suo interno i cinque design migliori
generati da ogni operazione di classificazione.
2.3 Logica funzionale 29
• Comment. Tabella dedicata ai commenti degli utenti relativi alle
classificazioni effettuate, la data ed il nome utente verranno salvati per
poter risalire all’utente e filtrare vecchi commenti.
• Events. Simile ai commenti, ma in questo caso il salvataggio avviene
in maniera automatica al verificarsi di determinati eventi (gia illustrati
nella Sezione 2.2.5).
Vediamo infine il diagramma concettuale E/R in figura 2.5.
Figura 2.5: Nel diagramma vediamo le tabelle presenti all’interno deldatabase e le relazioni che intercorrono tra queste.
Capitolo 3
Realizzazione
3.1 Interfaccia
In questa sezione mostreremo un esempio di funzionamento dell’applicazione
mobile, dal login, alla navigazione all’interno dei menu, fino alle operazioni
di classificazione dei design prodotti dalle sessioni di ottimizzazione.
L’applicazione va ovviamente installata sul dispositivo mobile, utilizzando il
pacchetto di installazione per il sistema operativo in uso. Una volta fatto cio
il programma non necessita di ulteriori configurazioni ed e pronto all’uso.
Le figure che seguono provengono dal simulatore di Codename One presente
in NetBeans, l’interfaccia e quella base del sistema operativo mobile iOS,
utilizzandone un altra, tra quelle disponibili nel simulatore, la resa grafi-
ca sarebbe differente, cosı come quella su un dispositivo fisico con sistema
operativo diverso.
3.1.1 Login
La prima pagina visualizzata dall’utente, dopo l’avvio dell’applicazione, pre-
senta un form per l’inserimento di username e password, che autenticheranno
l’utente con SOMO, dovranno infatti essere inserite le credenziali valide per
quest’ultimo. Vediamo un esempio della pagina di login in Figura 3.1.
3.1 Interfaccia 31
Figura 3.1: Pagina di login. Figura 3.2: Pagina per laselezione del workspace.
3.1.2 Selezione workspace
L’utente, una volta autenticato, potra selezionare in quale workspace lavo-
rare, ognuno potra contenere progetti differenti, facenti riferimento a diver-
si gruppi di lavoro. Sara inoltre possibile cambiare utente, ritornando alla
pagina di login. Possiamo vederlo in Figura 3.2.
3.1.3 Selezione progetto
All’interno della pagina del workspace scelto si visualizzeranno i progetti
accessibili all’utente (Figura 3.3) , sara inoltre possibile controllare la message
board relativa al workspace in cui ci si trova, premendo il tasto in fondo alla
pagina, come vediamo in Figura 3.4.
3.1.4 Gestione del singolo progetto
Scelto il progetto su cui lavorare, l’utente avra a disposizione diverse opzioni
all’interno del menu, come possiamo vedere in Figura 3.5.
3.1 Interfaccia 32
Figura 3.3: Progetti disponibiliall’interno del workspace.
Figura 3.4: Pagina con leultime attivita.
Figura 3.5: Pagina principale di un progetto.
Di seguito ne elenchiamo le caratteristiche:
• View. Dopo aver scelto la sessione di ottimizzazione, si accede al menu
contenente le classificazioni gia effettuate e il tasto per l’esecuzione della
classificazione automatica.
3.1 Interfaccia 33
• Rank. Anche in questo caso si seleziona la sessione di ottimizzazione,
tra quelle disponibili (completate) e si puo quindi passare all’operazione
di classificazione dei design, assegnando prima i pesi alle variabili, ai
vincoli e alle funzioni obiettivo.
• SDO. Alla pressione del tasto si verifica se il progetto e un MDO, e
quindi si accede al menu di selezione dei sottoprogetti, uguale a quello
visto nella Sezione 3.1.3, oppure viene visualizzato un messaggio di
avvertimento nel caso in cui il progetto non sia multidisciplinare.
• Info. Fornisce informazioni generiche sul progetto come creatore, data
di creazione e altro.
3.1.5 Classificazione manuale dei design
L’utente una volta selezionato il progetto, puo accedere, attraverso la pres-
sione del tasto Rank, al menu per la selezione delle sessioni di ottimizzazione,
e, dopo averne scelta una, alla schermata che gli permettera di attribuire i
pesi. Si utilizzano dei cursori per selezionare il valore e una volta finito si
preme il tasto Evaluate, nel caso in cui sia gia stata svolta una valutazione
con gli stessi pesi, verra segnalato all’utente.
Vediamo in Figura 3.6 la pagina per la selezione della sessione, in cui sono
presenti anche sessioni abortite o ancora in esecuzione, che ovviamente non
saranno selezionabili. Nella Figura 3.7 si vedono gli cursori per l’attrivuzione
dei pesi e il tasto Evaluate per far partire le operazioni di ranking.
In Figura 3.8 vediamo come in un progetto multidisciplinare si ottengono i
suggerimenti sui pesi da assegnare, in base ai valori utilizzati nei sottopro-
getti. Se il suggerimento arriva solo da uno di questi, lo slider verra gia
impostato sul valore suggerito, nel caso in cui ci siano piu suggerimenti, si
segnala di prestare attenzione e si lascia all’utente il compito di scegliere
quale peso vada attribuito, non sara ovviamente possibile interagire con lo
slider che visualizza il suggerimento. Vediamo inoltre in Figura 3.9 il mes-
3.1 Interfaccia 34
Figura 3.6: Sessioni diottimizzazione tra cui poter
scegliere.
Figura 3.7: Slider per decidere ipesi da assegnare.
saggio di errore causato dall’invio di una classificazione con i valori dei pesi
gia utilizzati in precedenza.
3.1.6 Operazioni eseguibili sulle classfiche
Alla pressione del tasto View l’utente dovra scegliere prima la sessione di otti-
mizzazione, quindi per ogni classificazione effettuata, avra a sua disposizione
le seguenti opzioni:
• Post/Read Comment. Per aggiungere un nuovo commento, o leggere
quelli presenti.
• Show Best. Mostrera un nuova pagina del menu da cui poter visua-
lizzare le informazioni sui cinque design migliori.
• Set Favorite. Imposta la classificazione come favorita, e quindi in caso
di SDO, diventera quella da suggerire al progetto multidisciplinare.
• Delete Rank. Cancella la classificazione.
3.1 Interfaccia 35
Figura 3.8: Suggerimenti in unprogetto MDO.
Figura 3.9: Messaggio dierrore.
In caso il progetto sia un MDO, sara inoltre possibile eseguire una classifica-
zione automatica premendo il tasto Auto Rank, l’utente verra poi immedia-
tamente portato alla pagina contenente i design migliori.
Come possiamo vedere in Figura 3.10 la schermata principale si compone del
tasto per la classificazione automatica, e i vari ranking gia eseguiti, con le
opzioni descritte poco fa, il nome del ranking sara formato dai pesi attribuiti
alle singole variabili, ai vincoli e agli obiettivi.
3.1 Interfaccia 36
Figura 3.11: Inserimento di unnuovo commento.
Figura 3.12: Lettura deicommenti gia inseriti.
Figura 3.10: Pagina di gestione delle classificaizoni.
Vediamo inoltre nelle Figure 3.11 e 3.12 le pagine per l’inserimento e la lettura
dei commenti degli utenti.
3.1 Interfaccia 37
Figura 3.13: Pagina con icinque migliori design.
Figura 3.14: Valori dellevariabili, dei vincoli e degliobiettivi del singolo design.
3.1.7 Visualizzazione dei design migliori
La pagina, in Figura 3.13, permettera di visualizzare singolarmente i valori
delle variabili di input, output, dei vincoli e degli obiettivi, di ciascuno dei
cinque migliori design trovati, come si vede in Figura 3.14.
Quindi sara possibile visualizzare i valori di tutti e cinque i design simulta-
neamente (Figura 3.15), cosı da ottenere un confronto diretto.
3.1 Interfaccia 38
Figura 3.15: Confronto diretto dei valori tra i design.
Il grafico comparativo in Figura 3.16 e stato pensato soprattutto per l’utilizzo
su tablet, le ridotte dimensioni dello schermo sugli smartphone infatti non
permettono di apprezzare al meglio le differenze tra i vari design.
Figura 3.16: Grafico di confronto tra i design.
3.2 Implementazione 39
3.2 Implementazione
Nelle sezioni seguenti verra illustrato il funzionamento dei moduli sviluppati
per eseguire alcune delle operazioni descritte in precedenza. Ci soffermeremo
in particolar modo sulle operazioni principali eseguibili dal sistema completo,
quali il passaggio dei dati e l’aspetto decisionale e collaborativo.
3.2.1 Trasmissione di informazioni
Come abbiamo visto nella Sezione 2.2.2 il protocollo utilizzato per la tra-
smissione delle informazioni e l’HTTP, lo strumento mobile su cui e installata
l’applicazione dovra essere collegato sulla stessa rete su cui e implementata la
logica funzionale, la quale ricevera le richieste, con metodi POST e GET [20].
Analizzando i parametri all’interno dell’URI1 potremo indirizzare ogni richie-
sta al metodo della logica funzionale, che la processera in maniera corretta,
eseguendo quanto richiesto dall’utente, ad esempio richiedendo delle infor-
mazioni a SOMO o eseguendo l’algoritmo AHP per la generazione di una
classifica di design.
Autenticazione
L’applicazione inviera una richiesta HTTP di tipo POST al business layer, il
quale utilizzera le API messe a disposizione dagli sviluppatori di SOMO per
ottenere una risposta, che, se positiva (l’utente possiede un account attivo)
conterra un token valido per la sessione di utilizzo dell’applicazione, come
possiamo vedere in Figura 3.17. Il token verra inserito in ogni richiesta inviata
per confermare l’identita e poter fornire nelle risposte i dati effettivamente
consultabili dall’utente.
1Uniform Resource Identifier
3.2 Implementazione 40
Figura 3.17: L’utente inserendo username e password, del suoaccount SOMO, nella pagina iniziale dell’applicazione mobile invierauna richiesta verso il business layer, il quale richiedera a sua volta aSOMO un token utilizzabile per la sessione dell’utente. Il token verra
poi utilizzato in tutte le successive richieste dell’utente.
L’applicazione utilizzera il metodo ConnectionRequest fornito da Codename
One, all’interno del quale si preparera l’URL a cui inviare la richiesta, e
si attendera la risposta. Vediamo un esempio del codice nel Listato 3.1, e
interessante poiche tutte le richieste dall’applicazione mobile al business layer
utilizzeranno questo metodo, si differenzieranno nella lettura della risposta,
all’interno di readResponse, a seconda del tipo di quest’ultima, in questo
caso sara una String, ovvero il nostro token, da utilizzare in tutte le request
future.
,
1 ConnectionRequest request = new ConnectionRequest() {
2 protected void readResponse(InputStream input) throws IOException {
3 String token = Util.readToString(input);
4 }
5 };
6 request.setUrl(AppTesi.servletURL + "?username=" + username + "&password=" + password);
7 NetworkManager.getInstance().addToQueue(request);
Listato 3.1: Connection Request per l’autenticazione dell’utente
3.2 Implementazione 41
(a) JSON Object
(b) JSON Array
Figura 3.18: Utilizzeremo un array di oggetti JSON a rappresentare ilsingolo design, avendo pero necessita di inviare e ricevere diversi designcontemporaneamente riuniremo tutti i design in un unico array, cosı daevitare invii multipli e quindi un overhead di informazioni ridondanti.
Passaggio dei dati
Una volta effettuata l’autenticazione, l’utente avra accesso alle pagine, che gli
permetteranno di navigare tra workspace, progetti e sessioni. Le informazioni
necessarie per il passaggio tra una pagina e l’altra, si ottengono attraverso
richieste HTTP di tipo GET o POST, simili a quella descritta nel Listato 3.1,
a seconda che l’applicazione debba o meno inviare altri dati, come ad esempio
nel processo di classificazione dei design, in cui si invieranno i pesi assegnati
dall’utente ad ogni variabile, in formato JSON [21]. Il formato JSON e
stato scelto perche gia utilizzato all’interno di SOMO per il passaggio dei
dati dei singoli design in un unico file, da cui estrarre poi le informazioni
necessarie. Piu nello specifico un design sara composto dai nomi e i valori
delle variabili, dei vincoli e degli obiettivi, che andranno quindi a formare
un array di oggetti. Vediamo in Figura 3.18 una parte della grammatica
JSON che descrive come si definisce un oggetto e un array. Vedremo nella
Sezione 3.2.2 cosa effettivamente conterranno i file JSON forniti da SOMO,
mentre nel Listato 3.2 vediamo come avviene effettivamente l’invio.
3.2 Implementazione 42
,
1 protected void buildRequestBody(OutputStream os) throws IOException {
2 os.write(payloadMetadataVars.getBytes("UTF-8"));
3 }
4 request.setPost(true);
5 request.setContentType("application/json");
Listato 3.2: Connection Request di tipo POST per l’invio di file
Il metodo buildRequestBody si occupera di scrivere sull’OutputStream il
file, che sara di tipo JSON come specificato alla riga 5. Il codice non incluso
sara il medesimo di quello visto in precedenza nel Listato 3.1.
Generazione delle pagine
Per la generazione delle pagine, che permetteranno agli utenti di accedere a
workspace, progetti e tutte le altre funzioni dell’applicazione si useranno le
classi Form e Container di Codename One, che risultano essere molto simili
alla classe Swing di Java [22]. Le informazioni necessarie, come ad esempio
i nomi dei workspace o dei progetti, verranno anche in questo caso fornite
tramite Connection Request.
3.2.2 Classificazione dei design
Le operazioni di classificazione delle sessioni di ottimizzazione, che produr-
ranno i design tra cui scegliere, richiedono diversi passaggi per essere rese
disponibili all’utente, risultano differenti se si sta eseguendo la classificazione
in maniera manuale o automatica.
Classificazione manuale
Di seguito le operazioni svolte sull’applicazione mobile:
• Si parte dall’assegnazione dei pesi alle singole variabili, ai vincoli e agli
obiettivi da parte dell’utente nell’apposita pagina (Figure 3.7 e 3.8).
L’assegnazione avviene tramite degli slider. Gli eventuali suggerimenti
3.2 Implementazione 43
vengono comunicati dal business layer all’apertura della pagina e quindi
visualizzati anch’essi come slider, con cui non e pero possibile interagire.
• Una volta scelti i pesi, si preme il tasto per far partire la valutazione.
Vengono pertanto assegnati a ciascuna variabile, vincolo e obiettivo, il
peso corrispondente, e da questi creato un oggetto JSON, che li contiene
tutti, nel modo indicato nel Listato 3.3. Nel ciclo for alla riga 4, si
riempira una Hashtable con i dati, quindi verra trasformata nel file
JSON vero e proprio alla riga 10.
• Viene inviata la richiesta al business layer, contenente il file JSON
creato al punto precedente.
,
1 Hashtable h = new Hashtable();
2 Vector v = new Vector();
3 h.put("var",v);
4 for(MetadataVar metadataVar : MetadataVarsList) {
5 Hashtable singleMetadataVar = new Hashtable();
6 singleMetadataVar.put("varName", metadataVar.getVarName());
7 singleMetadataVar.put("varWeight", metadataVar.getVarWeight());
8 v.addElement(singleMetadataVar);
9 }
10 String payloadMetadataVars = Result.fromContent(h).toString();
Listato 3.3: Creazione del file JSON
L’utente rimarra ora in attesa della risposta, di avvenuta valutazione, da
parte del business layer, che eseguira le seguenti operazioni:
• Si controlla che la valutazione non sia gia stata eseguita, interrogando
il database. In caso si trovi una classificazione, per la stessa sessione,
con gli stessi pesi lo si segnala all’utente e si interrompe la procedura.
• Si esegue quindi la classificazione utilizzando l’algoritmo AHP oppor-
tunamente modificato, il quale produrra un array ordinato di design.
3.2 Implementazione 44
• Dalla classifica si selezioneranno i primi cinque design, che verranno
salvati nel database, in formato binario.
• Verra infine generato l’evento di avvenuta classificazione, salvato an-
ch’esso sul database, pronto per essere visualizzato nella Message Board
del workspace.
Classificazione automatica
Rispetto alla classificazione manuale appena illustrata, manchera completa-
mente la parte di attribuzione dei pesi da parte dell’utente, che si limitera
ad avviarla premendo il tasto opportuno.
Il business layer dovra pertanto seguire il procedimento indicato quı di se-
guito:
• Si invia una richiesta al database per ottenere i rank indicati come
preferiti dai sottoprogetti.
• Le classifiche cosı ottenute vengono confrontate e a ciascuna viene as-
segnato un peso. Da questo viene generata la classifica dei design
dell’MDO.
• Vengono quindi selezionati i primi cinque design e inviati all’applica-
zione mobile per essere visualizzati.
Come abbiamo visto l’utente verra portato alla pagina per la visualizzazio-
ne dei risultati, non sara necessario il salvataggio nel database, in quanto
l’operazione di auto ranking, non richiedendo l’interazione dell’utente nella
definizione dei pesi, non rappresenta un caso significativo dal punto di vista
collaborativo, aspetto che viene spostato al livello dei sottoprogetti.
3.2.3 Persistenza
La persistenza dei dati si realizza non solo per le operazioni di classificazio-
ne, nello specifico per il salvataggio dei design migliori, ma viene utilizzata
3.2 Implementazione 45
anche per la comunicazione tra utenti, come nel salvataggio dei commenti,
relativi alle operazioni di ranking o per gli ultimi eventi avvenuti all’interno
del workspace.
Si utilizzera anche in questo caso il database, in quanto una soluzione con
JMS2 non permetteva di garantire il tipo di persistenza richiesto da questa
applicazione.
2Java Message Server
Capitolo 4
Conclusioni
Gli obiettivi posti sono stati raggiunti, infatti si e realizzata un’applicazio-
ne multipiattaforma per dispositivi mobile in grado di fungere da supporto
per le decisioni collaborative. Supporto che viene realizzato attraverso la
possibilita di classificare i design prodotti dalle sessioni di ottimizzazione e
commentarli, coinvolgendo gli utenti nel processo decisionale.
Eventuali sviluppi futuri riguardano soprattutto una ancora maggior integra-
zione con SOMO, potendo gestire le sessioni di ottimizzazione direttamente
da un dispositivo mobile. Si potrebbero altresı implementare alcune delle
funzionalita dell’applicazione, come la classificazione dei design, o la possibi-
lita di commentare le sessioni in SOMO stesso, ampliando cosı le funzionalita
offerte. Come si vedra nell’esperimento effettuato in Appendice A inoltre, ri-
sultera interessante poter suddividere il carico di lavoro tra il livello di logica
funzionale e l’applicazione mobile in maniera dinamica durante l’esecuzione.
Il lavoro, svolto in un arco temporale di cinque mesi, attraverso il quale sono
stati realizzati sia l’applicazione mobile che il livello di logica funzionale, si
puo quantificare in cinquemila righe di codice Java, suddivise tra quasi un
centinaio di classi.
Considero l’esperienza fatta durante la realizzazione di questo progetto sicu-
ramente positiva, sia per le nuove tecnologie utilizzate (software per il design
47
optimization e software di sviluppo mobile) in ambito collaborativo, che per
il lato progettuale di un sistema complesso e strutturato su piu livelli che mi
hanno permesso di accrescere le mie capacita sia dal punto di vista formativo,
che personale e ampliare la visione sugli argomenti trattai.
Al momento il progetto e un prototipo funzionante nella totalita delle sue
parti sviluppate, ma non e prevista l’uscita sul mercato del sistema nella sua
interezza.
Appendice A
Valutazione sperimentale delle
prestazioni per un eventuale
sviluppo futuro
Una volta completato il progetto, si e pensato ad un possibile sviluppo futu-
ro, ovvero la possibilita di classificare i design direttamente sull’applicazione
mobile, togliendo parte del carico dalla macchina ospitante il livello di logica
funzionale (lato server). Data la differenza prestazionale tra dispositivo mo-
bile e server, andremo a valutare le condizioni da rispettare per poter rendere
conveniente questa operazione.
Verranno misurati i tempi necessari al completamento delle operazioni di
classificazione, per un numero crescente di design, sia sul dispositivo mo-
bile (trankApp) che sulla macchina ospitante il livello di logica funzionale o
server (trankServer). Dovranno quindi essere valutati anche i tempi necessari
al trasferimento del file JSON contenente i design (tsend). Si suppone che
eseguire una singola classificazione sul dispositivo mobile non risultera mai
conveniente, poiche bisognera aggiungere al tempo necessario al ranking quel-
lo per l’invio dei dati da parte del server e la comunicazione dei risultati a
A.1 Setup dell’esperimento 49
quest’ultimo. Possiamo riassumere il concetto nel modo seguente:
trankApp + tsend > trankServer + trequest (A.1)
Dove trequest e il tempo impiegato dalla richiesta a raggiungere il server, per
l’avvio della classificazione.
Nel seguente esperimento andremo quindi a valutare in quali casi diventa
conveniente eseguire la classificazione sul dispositivo mobile; ovvero quando
l’utente compensera tsend con esecuzioni consecutive dell’operazione di classi-
ficazione. Il file contenente i dati dei design verra inviato alla prima richiesta
di classificazione da parte dell’applicazione e salvato sul dispositivo mobi-
le. Dovremmo trovare n, ovvero il numero di classificazioni consecutive che
risolve la seguente disequazione:
(n · trankApp) + tsend < n · (trankServer + trequest) (A.2)
A.1 Setup dell’esperimento
L’esperimento e stato svolto utilizzando i dispositivi, le cui caratteristiche
tecniche verranno riassunte nella Tabella A.1. Altri dispositivi porterebbero
certamente risultati diversi, variando la potenza di calcolo disponibile.
Dispositivo CPU RAM Sistema operativoSamsung Galaxy Nexus TI OMAP 4460
ARM Cortex-A9dual-core 1.20 GHz
1 GB Android 4.3
Dell OptiPlex 760 Intel Core2 DuoE7400 2.80 GHz
4 GB Ubuntu 12.04
Tabella A.1: Caratteristiche tecniche dei dispositivi utilizzati perl’esperimento, ovvero il dispositivo mobile, in questo caso uno
smartphone e il PC su cui e installata la logica funzionale.
La rete su cui e stato svolto l’esperimento e quella di ESTECO, in Figu-
A.2 Risultati ottenuti 50
ra A.1 ne vediamo la struttura. Le caratteristiche dei componenti di rete
non vengono riportati su richiesta dell’azienda.
Figura A.1: La struttura della rete utilizzata per l’esperimento, lalinea tratteggiata indica una connessione WiFi.
A.2 Risultati ottenuti
Di seguito, in Tabella A.2, i risultati misurati durante l’esperimento ottenuti
in diversi momenti della giornata, quindi con un carico della rete variabile,
come sono variabili le condizioni del dispositivo mobile e del server ospitante
la logica funzionale. Tutte le medie sono espresse in millisecondi.
Design tsend σsend trankApp σrankApp trankServer σrankServer1000 35,49 12,12 8,00 3,30 0,75 1,322000 50,70 34,63 19,58 33,95 1,26 1,783000 58,56 48,01 23,66 23,53 2.10 3,074000 65,07 58,97 41,73 57,76 2,73 3,775000 72,02 51,99 97,45 114,39 3,11 3,88
Tabella A.2: Tempi medi (t) e deviazioni standard (σ) misuratidurante l’esperimento al variare del numero di design.
Il tempo medio di invio delle richieste di classificazione e: trequest = 28, 21ms.
A.2 Risultati ottenuti 51
Per una maggiore chiarezza presentiamo i grafici comparativi relativi ai tem-
pi di esecuzione delle classificazioni in Figura A.2 e i tempi di invio dei file
contenenti i design in Figura A.3. Infine nella Figura A.4 vediamo le distri-
buzioni dei valori misurati nel caso vengano valutati 3000 design.
1000 2000 3000 4000 50000
20
40
60
80
100
Numero di design
Tem
po
inms
trankServertrankApp
1
Figura A.2: Comparazione tra i tempi medi necesari all’operazione diclassificazione sul dispositivo mobile e sul server.
1000 2000 3000 4000 50000
20
40
60
trequest
Numero di design
Tem
po
inms
tsend
1
Figura A.3: Tempi medi di invio dei file, contenenti i design, aldispositivo mobile durante l’esperimento. La retta trequest indica il tempo
medio impiegato dalla richiesta senza l’invio del file.
A.2 Risultati ottenuti 52
[0–30)
[30–60)
[60–90)
[90–120)
[120
–150)
[150
–180)
[180
–210)
[210
–240)
[240
–270)
0
10
20
30
40
50
Intervalli di tempo in ms
Occorrenze
1
(a) tsend
[0–27)
[27–54)
[54–81)
[81–108)
[108
–135)
[135
–162)
[162
–189)
[189
–216)
[216
–243)
[243
–270)
0
20
40
60
80
100
Intervalli di tempo in ms
Occorrenze
1
(b) trankApp
[0–2.4)
[2.4–4.8)
[4.8–7.2)
[7.2–9.6)
[9.6–12)
[12–14.4)
[14.4–16.8)
[16.8–19.2)
[19.2–21.6)
[21.6–24)
0
20
40
60
80
100
120
Intervalli di tempo in ms
Occorrenze
1
(c) trankServer
Figura A.4: Gli istogrammi rappresentano le distribuzioni dei datimisurati in determinati intervalli di tempo. In Figura A.4a vediamo le
rilevazioni riguardanti il tempo di invio dei file tsend, in Figura A.4babbiamo il tempo di calcolo sul dispositivo mobile trankApp ed infine in
Figura A.4c il tempo di calcolo sul server trankServer. Il numero didesign per ottenere le misure e 3000 in tutti e tre gli istogrammi.
Presentiamo in Tabella A.3 i risultati relativi al numero di classificazioni da
dover eseguire sul dispositivo mobile per rendere conveniente l’esecuzione sul
dispositivo stesso e non sul server. Utilizzando la Formula A.2 e i valori medi
in Tabella A.2.
A.3 Commento dei risultati 53
Design Classificazioni1000 22000 63000 94000 -5000 -
Tabella A.3: Numero di classificazioni consecutive da far eseguire suldispositivo mobile, che rendano conveniente l’operazione. Per 4000 e5000 design non e piu conveniente dati gli eccessivi tempi di calcolo
necessari al dispositivo mobile utilizzato nell’esperimento.
A.3 Commento dei risultati
I risultati ottenuti indicano che fino ad un certo numero di design sara possi-
bile eseguire la classificazione anche sul dispositivo mobile diminuendo i tempi
di attesa per l’utente, purche se ne esegua il numero indicato in Tabella A.3,
superato quel limite non sara mai conveniente, in quanto la computazione
risulta essere troppo esosa, in termini di tempo, per il dispostivo mobile uti-
lizzato durante l’esperimento. Si stima che un dispositivo piu potente (un
tablet ad esempio), renderebbe piu convenienti le valutazioni, diminuendo i
tempi di calcolo.
Un interessante sviluppo futuro sara quello di riuscire a misurare istanta-
neamente le tempistiche necessarie al trasferimento dei dati (monitorando la
rete) e all’esecuzione del ranking, distribuendo il carico di lavoro al variare
di queste ultime, cosı da poter fornire all’utente la miglior esperienza d’uso
possibile, in base alle caratteristiche dei dispositivi in uso[23].
Bibliografia
[1] Hans Peter Luhn, Keyword-in-Context Index for Technical Literature
(KWIC Index). IBM, ASDD, Yorktown Heights, N. Y., Report RC-127,
1959.
[2] Kurt Schlegel, Rita L. Sallam, Tom Austin, Carol Rozwell, The rise of
Collaborative Decision Making. Gartner, 2009.
[3] Carol Rozwell, Nigel Rayner, Collaborative Decision Making: We Are
Smarter Than Me. Gartner, 2013.
[4] Jihong Liu, Liansheng Li, A web services-based framework for Multidisci-
plinary Design Optimization. Enterp. Inf. Syst., Taylor & Francis, Inc.,
2012.
[5] Timothy W. Simpson, Joaquim R. R. A. Martins, Multidisciplinary
Design Optimization for Complex Engineered Systems: Report from a
National Science Foundation Workshop. Journal of Mechanical Design,
133(10):101002+, 2011.
[6] Oracle Corporation, Java Platform, Standard Edition 7 API Specification.
http://docs.oracle.com/javase/7/docs/api/, 2013.
[7] Codename One, Codename One API. https://codenameone.
googlecode.com/svn/trunk/CodenameOne/javadoc/index.html,
2013.
BIBLIOGRAFIA 55
[8] Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Web
Services Concepts, Architectures and Applications, Springer, 2004.
[9] Oracle Corporation, Java Platform, Enterprise Edition 6 API
Specification. http://docs.oracle.com/javaee/6/api/, 2011.
[10] Thomas J. Santner, Brian J. Williams, and William I. Notz, The Design
and Analysis of Computer Experiments. Springer Verlag, New York, 2003.
[11] NIST/SEMATECH, e-Handbook of Statistical Methods. http://www.
itl.nist.gov/div898/handbook/, 2012.
[12] Kaisa Miettinen, Nonlinear Multiobjective Optimization. Kluwer
Academic Publishers, Boston, 1999.
[13] David Heffelfinger, Java EE 6 with GlassFish 3 Application Server.
Packt Publishing, 2010.
[14] Antonio Goncalves, Beginning Java EE 6 Platform with GlassFish 3:
From Novice to Progessional. Apress, 2009.
[15] Saaty T.L., The Analytic Hierarchy Process, Planning, Piority Setting,
Resource Allocation. McGraw-Hill, New York, 1980.
[16] Saaty T.L., Decision making with the analytic hierarchy process.
International Journal of Services Sciences, 2008.
[17] Denis Ssebuggwawo, Stijn Hoppenbrouwers, Erik Proper, Group Deci-
sion Making in Collaborative Modeling, Aggregating Individual Preferen-
ces with AHP. In Digital Proceedings of the 4th SIKS conference in En-
terprise Information Systems (EIS 2009), Ravenstein, The Netherlands,
2009.
[18] Domenico Falcone, Fabio De Felice, Thomas L. Saaty, Il decision making
e i sistemi decisionali multicriterio. Le metodologie AHP e ANP. Hoepli
Editore, 2009.
BIBLIOGRAFIA 56
[19] Fielding, Roy T. and Taylor, Richard N., Principled Design of the Mo-
dern Web Architecture. ACM Trans. Internet Technol, New York, NY,
USA, 2002.
[20] R. Fielding et al, Hypertext transfer protocol – http/1.1. RFC 2616.
http://tools.ietf.org/html/rfc2616, 1999.
[21] ECMA International, The JSON Data Interchange Format.
http://www.ecma-international.org/publications/files/
ECMA-ST/ECMA-404.pdf 2013.
[22] Codename One, Codename One For Swing/Java Developers. http://
www.codenameone.com/swing.html, 2013.
[23] Ioana Giugiu, Oriana Riva, Gustavo Alonso, Dynamic Softare
Deployment from Clouds to Mobile Devices. Middleware, 2012