64
Universit ` a degli Studi di Trieste Dipartimento di Ingegneria e Architettura Corso di Laurea Magistrale in Ingegneria Informatica Progetto e sviluppo di un’applicazione mobile multipiattaforma per il supporto alle decisioni collaborative Candidato: Relatore: Michele Sinigoi Chiar.mo Prof. Alberto Bartoli Correlatore: Ing. Paolo Vercesi Anno Accademico 2012-13 - Sessione straordinaria

Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

  • Upload
    maiko

  • View
    258

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 2: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

.

Ai miei genitori Mariagrazia e Aldoad Alice

alla mia famiglia eai miei amici.

Page 3: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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:

Page 4: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 5: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 6: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 7: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 8: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 9: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 10: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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/

Page 11: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 12: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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:

Page 13: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 14: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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/

Page 15: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 16: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 17: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 18: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 19: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 20: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 21: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 22: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 23: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 24: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 25: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 26: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 27: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 28: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 29: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 30: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 31: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 32: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 33: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 34: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 35: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 36: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 37: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 38: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 39: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 40: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 41: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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-

Page 42: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 43: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 44: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 45: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 46: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 47: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 48: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 49: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 50: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 51: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 52: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 53: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 54: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 55: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 56: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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

Page 57: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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-

Page 58: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 59: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 60: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 61: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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].

Page 62: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 63: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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.

Page 64: Progetto e sviluppo di un'applicazionemobile multipiattaforma per il supporto alledecisioni collaborative

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