Corso di Laurea in Informatica
Universit` a degli Studi di Padova
Imperial, un’interfaccia grafica utente per il lancio di produzione
Tesi di laurea triennale
Anno Accademico 2017-2018
Laureando
Bile E. Christian Prince Carlos
Relatore
Dott. Armir Bujari
Sommario
Il presente documento descrive il lavoro svolto nel periodo di stage della durata di trecentoventi ore, presso l’azienda SOGEA S.R.L di Treviso. Lo scopo dello stage `e stato lo studio della tecnologia QtQuick tramite l’implementazione di un applicativo che permetta ad un’azienda del settore Fast Fashion, di pianificare la produzione di capi di abbigliamento su dispositivi touch di grandi dimensioni.
Tesi di laurea triennale Pagina I di VIII
Ringraziamenti
Desidero innanzitutto ringraziare il Dott. Bujari Armir, relatore della mia tesi, per l’aiuto attento e preciso che `e riuscito a darmi durante la sua stesura (nonch´e per la pazienza dimostrata nell’insegnarmi a scrivere una tesi accurata). `E sempre bello trovare dei professori che amano la loro materia tanto da riuscire a trasmettere la passione anche agli studenti, sono perci`o molto contento di aver lavorato con Lei.
Ringrazio tutte le persone con cui sono venuto a contatto durante lo stage presso SOGEA S.R.L. Grazie in particolare al mio tutor aziendale Ronchin Simone, che mi ha seguito per tutta la durata dello stage ed aiutato a scrivere la tesi. Grazie per avermi coinvolto fin da subito nella definizione del progetto a cui avrei lavorato, permettendomi in questo modo di svolgere un lavoro che `e stato anche per me di grande interesse.
Un grazie di cuore va a tutta la mia famiglia e in particolare a mio fratello e sua moglie, per tutto il sostegno che mi hanno dato in questi anni di universit`a.
Ringrazio i miei compagni di universit`a diventati amici a cui ora non potrei mai rinun- ciare. Questi anni sarebbero stati molto diversi senza di voi. Grazie per le risate, il sostegno, e per aver sopportato le mie strane trasformazioni in persona noiosa e antipatica prima degli esami. Lucas, Singh, Elvis, Vincenzo, Andrea, Damien, Beatrice, Valentina, Eleonora, Matteo, Emanuele, Fabio, sono grato di aver conosciuto persone speciali come voi.
Grazie di cuore.
“Lo studio `e come la luce che illumina la tenebra dell’ignoranza, e la conoscenza che ne risulta `e il supremo possesso, perch´e non potr`a esserci tolto neanche dal pi`u abile dei ladri. Lo studio `e l’arma che elimina quel nemico che `e l’ignoranza. `E anche il miglior amico che ci guida attraverso tutti i nostri momenti difficili.”
–Dalai Lama.
Indice
1 Introduzione 1
1.1 Motivazione . . . 1
1.2 Azienda . . . 1
2 Il Progetto 2 2.1 Dominio applicativo . . . 2
2.2 Descrizione del progetto . . . 4
2.3 Prodotto finale . . . 4
2.4 Utente finale . . . 5
2.5 Obiettivi . . . 5
2.6 Vincoli metodologici . . . 7
2.7 Vincoli temporali . . . 7
2.8 Vincoli tecnologici . . . 7
2.9 Rischi e complessit`a del progetto . . . 7
2.10 Pianificazione . . . 8
2.11 Analisi preventiva dei rischi . . . 9
2.12 Qualit`a . . . 11
2.12.1 Qualit`a di prodotto . . . 11
2.12.2 Qualit`a di processo . . . 12
3 Ambiente di lavoro 13 3.1 Versionamento . . . 13
3.2 Altri strumenti per la gestione di progetto . . . 13
3.3 Documentazione . . . 13
3.3.1 QDoc . . . 13
3.3.2 TeXstudio . . . 13
3.3.3 StarUML . . . 14
3.4 Ambiente di sviluppo . . . 14
3.4.1 IDE . . . 14
3.4.2 Sistemi operativi . . . 14
4 Analisi dei requisiti 15 4.1 Casi d’uso . . . 15
4.2 Attori . . . 15
4.2.1 Attori primari . . . 15
4.2.2 Attori secondari . . . 15
4.3 Diagrammi dei casi d’uso generali . . . 16
4.3.1 Operatore non autenticato . . . 16
4.3.2 Operatore autenticato . . . 17
4.4 Altri diagrammi d’uso . . . 18
4.4.1 UC3: Ricerca modello . . . 19
4.4.2 UC9: Lancio produzione . . . 20
4.5 Requisiti . . . 22
4.5.1 Requisiti funzionali . . . 22
4.5.2 Requisiti di qualit`a . . . 25
4.5.3 Requisiti di Vincolo . . . 26
4.6 Riepilogo . . . 26
5 Studio delle tecnologie 27 5.1 QML . . . 27
5.2 QtQuick . . . 27
5.3 Alternative tecnologiche cross-platform . . . 28
6 Progettazione 29 6.1 Progettazione architetturale dell’applicativo . . . 29
6.2 Altre librerie usate . . . 30
6.2.1 SortFilterProxyModel . . . 30
6.2.2 Quick Promise . . . 30
6.3 Progettazione di dettaglio . . . 30
6.3.1 Model . . . 31
6.3.2 ViewModel . . . 34
6.3.3 View . . . 39
6.3.4 Design patterns . . . 49
6.3.5 Diagrammi di sequenza . . . 49
6.4 Progettazione interfaccia grafica utente . . . 52
6.4.1 Layout . . . 52
6.4.2 Responsiveness . . . 54
6.4.3 Lingua . . . 54
6.5 Riepilogo . . . 54
7 Codifica 55 8 Verifica e Validazione 56 8.1 Verifica . . . 56
8.1.1 Verifica Robustezza . . . 56
8.1.2 Verifica Modificabilt`a . . . 57
8.1.3 Verifica efficienza nel tempo . . . 58
8.1.4 Verifica Accuratezza . . . 60
8.1.5 Verifica Usabilit`a . . . 60
8.2 Validazione . . . 60
8.2.1 Soddisfazione . . . 60
9 Conclusioni 61
9.1 Raggiungimento degli obiettivi . . . 61
9.2 Resoconto dell’analisi dei rischi . . . 62
9.3 Consuntivo finale . . . 64
9.3.1 Qualit`a del processo . . . 66
9.4 Valutazione personale e conoscenze acquisite . . . 66
10 Bibliografia 68
Glossario 69
Elenco delle figure
1 Fasi principali di produzione di una maglietta . . . 3
2 Diagramma Work Breakdown Structure delle attivit`a di sviluppo . . . 9
3 Attenzione da portare ad un rischio . . . 10
4 Rappresentazione degli attori primari nei diagrammi dei casi d’uso . . . . 15
5 Rappresentazione degli attori secondari nei diagrammi dei casi d’uso . . . 16
6 Diagramma dei casi d’uso generali operatore non autenticato . . . 16
7 Diagramma dei casi d’uso generali operatore autenticato . . . 17
8 UC3: Ricerca modello . . . 19
9 UC9: Lancio produzione . . . 20
10 UC9.1: Inserimento quantit`a per taglia . . . 21
11 UC9.2: Inserimento automatico da curva . . . 21
12 Architettura Model–View–ViewModel (MVVM) . . . 29
13 Progettazione architettura dell’applicativo . . . 30
14 Diagramma delle classi Model 1/3 . . . 31
15 Diagramma delle classi Model 2/3 . . . 32
16 Diagramma delle classi Model 3/3 . . . 33
17 Diagramma delle classi ViewModel 1/5 . . . 34
18 Diagramma delle classi ViewModel 2/5 . . . 35
19 Diagramma delle classi ViewModel 3/5 . . . 36
20 Diagramma delle classi ViewModel 4/5 . . . 37
21 Diagramma delle classi ViewModel 5/5 . . . 38
22 Diagramma delle classi View 1/10 . . . 39
23 Diagramma delle classi View 2/10 . . . 40
24 Diagramma delle classi View 3/10 . . . 41
25 Diagramma delle classi View 4/10 . . . 42
26 Diagramma delle classi View 5/10 . . . 43
27 Diagramma delle classi View 6/10 . . . 44
28 Diagramma delle classi View 7/10 . . . 45
29 Diagramma delle classi View 8/10 . . . 46
30 Diagramma delle classi View 9/10 . . . 47
31 Diagramma delle classi View 10/10 . . . 48
32 Diagramma di sequenza: Inserimento tramite curva delle quantit`a per il lancio . . . 50
33 Diagramma di sequenza: Salvo lancio . . . 51
34 Diagramma di sequenza: Ricerca modelli . . . 52
35 Layout dell’applicativo . . . 53
Elenco delle tabelle
1 Obiettivi del progetto . . . 5
2 Valutazione della complessit`a . . . 7
3 Priorit`a degli obiettivi . . . 9
4 Rischi identificati . . . 10
5 Alcuni requisiti funzionali . . . 23
6 Tabella dei requisiti di qualit`a . . . 25
7 Tabella dei requisiti di vincolo . . . 26
8 Totale dei requisiti . . . 26
9 Classi Model 1/3 . . . 31
10 Classi Model 2/3 . . . 32
11 Classi Model 3/3 . . . 33
12 Classi ViewModel 1/5 . . . 34
13 Classi ViewModel 2/5 . . . 35
14 Classi ViewModel 3/5 . . . 36
15 Classi ViewModel 4/5 . . . 37
16 Classi ViewModel 5/5 . . . 38
17 Classi View 1/10 . . . 39
18 Classi View 2/10 . . . 40
19 Classi View 3/10 . . . 41
20 Classi View 4/10 . . . 42
21 Classi View 5/10 . . . 43
22 Classi View 6/10 . . . 44
23 Classi View 7/10 . . . 45
24 Classi View 8/10 . . . 46
25 Classi View 9/10 . . . 47
26 Classi View 10/10 . . . 48
27 Totale classi . . . 54
28 SFOUT e LCOM4 delle componenti architetturali . . . 58
29 Instabilit`a delle componenti architetturali . . . 58
30 Alcuni risultati di benchmark . . . 58
31 Complessit`a asintotiche . . . 59
32 Esiti della verifica di usabilit`a . . . 60
33 Requisiti soddisfatti . . . 61
34 Obiettivi raggiunti . . . 61
35 Attualizzazione dei rischi . . . 62
36 Differenza ore consuntivo-preventivo . . . 64
Capitolo 1
Introduzione
In questo capitolo vengono brevemente descritti l’azienda SOGEA S.R.L, presso la quale ho svolto lo stage, e i motivi per i quali ho scelto di fare questo progetto.
1.1 Motivazione
I motivi per i quali ho scelto di fare lo stage presso la SOGEA s.r.l sono due:
1. Sede: La sede dell’azienda si trova a poco meno di quattro chilometri dalla mia residenza, ed `e raggiungibile in poco pi`u di un quarto d’ora in bici. Grazie a questa vicinanza ho potuto evitare i costi di trasporto e i ritardi dei mezzi pubblici;
2. Il progetto: Il progetto in s´e mi `e sembrato interessante per il contesto e per le tecnologie da usare. Il mondo della produzione di abbigliamento mi era com- pletamento estraneo, ho pensato che avere delle conoscenze al riguardo potranno aiutarmi ad affrontare progetti simili per la sua parte gestionale, in un lavoro futuro.
Anche la tecnologia QtQuick[5] mi era nuova, conoscevo Qt Widgets[26], in quanto posto come vincolo tecnologico per il progetto nel corso di Programmazione ad Oggetti al secondo anno di universit`a, ma non QtQuick. Perci`o anche in questo caso sapere una tecnologia in pi`u mi sar`a utile in futuro.
1.2 Azienda
SOGEA nasce nel 1980 con una precisa filosofia: accompagnare il continuo miglioramento dei suoi clienti nel loro sviluppo tecnologico-organizzativo e nella loro crescita dimensio- nale. In oltre 35 anni di attivit`a il tratto distintivo di SOGEA `e diventato un valore condiviso da migliaia di aziende in Italia e all’estero che hanno fatto di SOGEA il loro partner ICT (Information and Communications Technology).
SOGEA sviluppa e realizza soluzioni software dedicate alle diverse e complesse esigen- ze delle PMI(Piccole Medie Imprese), coinvolgendo tutti gli aspetti strategici del loro business, come per esempio l’area amministrativa-finanziaria, il controllo di gestione, la produzione, la logistica e la sicurezza. Il metodo di sviluppo scelto `e AgileG, simile al metodoScrumG, in cui viene fatta un’analisi preliminare dei requisiti, seguita da sviluppi incrementali fino al prodotto finale. Nelle fasi di sviluppo c’`e una forte collaborazione tra i membri del team e tra il team e il cliente. Una volta il prodotto consegnato, il cliente viene assistito nell’utilizzo e negli eventuali problemi software che possono emergere del prodotto.
Il core business `e il sistema ERP (Pianificazione delle risorse d’impresa) che offre funzio- nalit`a di logistica, di gestione e controllo delle produzioni, di configurazione di prodotto e documenti. Attualmente la SOGEA `e impegnata nell’Industry 4.0G con l’automa- zione e l’SMM (Smart Manufacturing Manager) che consente di evolvere le aziende manufatturiere, e di condurle con mano a quella evoluzione industriale.
Capitolo 2
Il Progetto
Questo capitolo specifica il progetto svolto contestualizzandolo nel dominio applicativo, definendo gli obiettivi da raggiungere, la pianificazione iniziale, la qualit`a da raggiungere, e i probabili rischi che potevano perturbare le attivit`a di progetto.
2.1 Dominio applicativo
Il Fast Fashion[3] `e il settore dell’industria dell’abbigliamento che produce collezioni ispirate all’alta moda ma messe in vendita a prezzi contenuti e rinnovate in tempi brevissimi. Le aziende di questo settore utilizzano una strategia di produzione nata negli anni 80 negli Stati Uniti, denominata ”Metodo di risposta rapida”, basato sulla massimizzazione del guadagno tramite la massimizzazione dell’efficienza produttiva.
Infatti, l’efficienza produttiva permette la creazione di nuovi prodotti in tempi rapidi, che invogliano i consumatori a visitare pi`u spesso i negozi di abbigliamento.
Per questo motivo le attivit`a di produzione dei capi di abbigliamento in questo settore, devono essere il pi`u possibile automatizzate con mezzi rigorosamente efficienti ed efficaci.
Il processo atto alla gestione dell’intero ciclo di vita del prodotto, viene chiamato PLM[4](product lifecycle management ). Esso enfatizza l’automazione di molte fasi del ciclo di vita per ridurre significativamente i tempi di produzione, ad esempio l’uso di software ad hoc per il disegno del modello. Le fasi principali di produzione di un capo di abbigliamento sono:
1. Ideazione: fase maggiormente creativa, essa si suddivide nelle seguenti sottofasi:
(a) Design del modello: tenendo conto delle tendenze di moda, delle variazioni nel gusto e nel comportamento del consumatore;
(b) Modellistica: In questa fase vengono decisi ladistinta baseG, come produrre il capo e le varianti (articoli).
2. Prototipo: questa fase consiste nel creare un prototipo a fini di approvazione del modello;
3. Approvazione del modello: Il capo di abbigliamento viene approvato dall’organo aziendale incaricato, il quale approva valutando i costi di produzione, i tempi di produzione, e il guadagno dalla sua vendita (caratteristiche del modello capaci di suscitare il cliente a comprare);
4. Avvio in produzione: UnarticoloG deciso in fase di modellistica e approvato, `e lanciato in produzione;
5. Articolo prodotto: L’articolo `e stato prodotto nelle taglie e quantit`a specificate ed `e pronto ad essere distribuito nei negozi per la vendita.
Articolo 1
Descrizione: Maglietta SUPREME Base Codice tessuto: IEKL90
Taglie: M Colori:
Articolo 2
Descrizione: Maglietta SUPREME con taschino Codice tessuto: IEKL90
Codice tessuto tasca: JKLO78 Taglie: M
Colore maglietta + colore tasca:
+
Maglietta SUPREME
Prototipo Prototipo
Disegno del modello
Modellistica Modellistica
Lancio in produzione di 3000 capi di taglia M con il colore:
+
Approvato
Distribuzione del prodotto finito Produzione
terminata
Figura 1: Fasi principali di produzione di una maglietta
2.2 Descrizione del progetto
Il progetto mira alla creazione di un’applicazione su dispositivi touch di grandi dimensioni, che permetta la pianificazione della produzione di capi di abbigliamento. Il cliente richiedente del prodotto software `e una delle prime aziende ad implementare il processo produttivo Fast Fashion[3] in Italia, per questo viene richiesto un prodotto altrettanto rapido, intuitivo e che permetta di avere uno sguardo di insieme sulla situazione della produzione in tempo reale, e inoltre permetta di attivare nuove collezioni o produzioni.
Per pianificare una produzione, l’utente deve innanzitutto accedere all’applicazione con le sue credenziali di accesso. Una volta autenticato, l’utente potr`a:
Cercare un modello: Filtrare e visionare tutti gli articoli in base allo stato del prodotto finito nel PLM[4] o in base a parole chiavi su determinate caratteristiche di quest’ultimi. Alla selezione dell’articoloG, verr`a visualizzato il modello con il suo tessuto principale, i colori con i quali pu`o essere prodotto e tutti i tessuti che potrebbero sostituire quello principale.
Cercare un tessuto: Il programma consentir`a di filtrare e visionare tutti i tessuti giacenti in magazzino. Alla selezione del tessuto verranno visualizzati tutti gli articoli che richiedono il tessuto in questione.
Per lanciare una produzione l’utente dovr`a selezionare una coppia di articolo e tessuto, arriver`a poi nella schermata unica di lancio dove potr`a:
Richiedere la creazione di un nuovo articolo in quanto la combinazione selezionata non `e ancora esistente. Alla conferma verr`a comunicato aLectraG la richiesta di creazione del nuovo articolo. All’interno dell’applicativo vi sar`a una sezione dove si potr`a vedere tutte le richieste effettuate e lo stato di ognuna.
Lanciare una nuova quantit`a in produzione nel momento in cui la combina- zione selezionata sia approvata. Per la conferma del lancio verranno richiesti il codice colore e la quantit`a da produrre, precisa per taglia oppure attraverso una curva di distribuzione che spalmer`a la quantit`a totale sulle singole taglie. Alla conferma del lancio verr`a generata una stampa con la specifica dei dati specificati.
2.3 Prodotto finale
Il prodotto finale da rilasciare al cliente richiedente `e molto pi`u complesso e non pu`o essere sviluppato interamente nelle attivt`a di stage. Per questo motivo l’applicativo sviluppato durante le attivit`a di stage, rappresenter`a un prototipo da presentare entro fine anno al cliente, e verr`a successivamente ampliato con nuove funzionalit`a fino ad ottenere il prodotto finale da rilasciare. L’applicazione comunicher`a con un server gi`a sviluppato, tramite chiamateRESTG.
2.4 Utente finale
L’utente finale dell’applicazione `e un operatore dell’azienda che possiede un’esperienza nel settore e un’ottima conoscenza del mercato. `E in grado di individuare i prodotti che potrebbero rendere al meglio al momento tra quelli offerti e individuare nuove proposte.
Tuttavia egli possiede competenze informatiche basse, per questo motivo `e richiesta un’interfaccia touch intuitiva, pi`u user-friendlyG possibile.
2.5 Obiettivi
Sono riportati nella Tabella sottostante gli obiettivi fissati per lo stage con rispettivo identificativo, importanza e breve descrizione.
L’identificativo(Id) `e la stringa che identifica univocamente ogni obiettivo e rispetta la notazione [Importanza][Identificativo], dove l’importanza `e la sigla tra Ob, De e Fa, a seconda che l’obiettivo sia obbligatorio, desiderabile o facoltativo; l’identificativo `e un numero progressivo.
Un obiettivo `e classificato, secondo la sua utilit`a strategica, come:
Obbligatorio: gli obiettivi rientranti in questa categoria, sono irrinunciabili all’azienda e dovranno necessariamente essere soddisfatti;
Facoltativo: `e l’importanza attribuita agli obiettivi il cui soddisfacimento `e del tutto facoltativo, ma utili in quanto renderebbero il progetto pi`u completo;
Desiderabile: Non strettamente necessario soddifarlo, ma a valore aggiunto riconoscibile;
Tabella 1: Obiettivi del progetto Id Importanza Descrizione
Ob01 Obbligatorio Integrazione di dati provenienti da applicativi esterni in un’unica base dati centralizzata Ob02 Obbligatorio Configurazione di pi`u postazioni client che
condividono gli stessi dati
Ob03 Obbligatorio Sincronizzazione e consistenza dei dati tra le postazioni client e la postazione server centralizzata
Ob04 Obbligatorio Interfaccia utente orientata al touch screen senza l’utilizzo di mouse e tastiera
Ob05 Obbligatorio Interfaccia utente intuitiva, in quanto gli end user non hanno particolare confidenza con dispositivi tecnologici
Ob06 Obbligatorio Visualizzazione di immagini ad alta definizione Ob07 Obbligatorio Ricerca di modelli
Ob08 Obbligatorio Permettere di esplorare i dettagli dei modelli proposti
Ob09 Obbligatorio Lancio di una nuova produzione di abbigliamenti a partire da un modello
Ob10 Obbligatorio Suggerimento di potenziali tessuti abbinabili ad un certo modello
Ob11 Obbligatorio Ordine di un tessuto suggerito per un modello Ob12 Obbligatorio Ricerca di tessuti
Ob13 Obbligatorio Permettere di esplorare i dettagli dei tessuti Ob14 Obbligatorio Lancio di una nuova produzione di abbigliamenti
a partire dal tessuto
Ob15 Obbligatorio Visualizzazione della giacenzaG dei tessuti Ob16 Obbligatorio L’applicazione deve essere fluida nell’utilizzo Ob17 Obbligatorio Redigere una documentazione del lavoro svolto
Fa01 Facoltativo Interfaccia utente personalizzabile direttamente dall’end user in termini di carattere
Fa02 Facoltativo Interfaccia utente personalizzabile direttamente dall’end user in termini di colori
De01 Desiderabile Gestione multilingua, visto la possibilit`a di installazione in paesi esteri
De02 Desiderabile Gestione permessi associati ai profili utente per limitare alcune operativit`a in base al profilo end user
De03 Desiderabile Gestione permessi associati ai profili utente per configurare i dati accessibili in base al profilo end user
2.6 Vincoli metodologici
E stato concordato con SOGEA S.R.L che lo stage fosse svolto presso la sede operativa` della stessa, a Treviso, affinch´e io potessi essere inserito nel contesto aziendale ed avere la possibilit`a di confrontarmi col resto del team di esperti, oltre che a preservare la massima riservatezza sui dati personali dell’azienda e dei suoi clienti. Non `e stato posto nessun vincolo sui processi di qualit`a e di sviluppo da adottare, almeno di essere giustificati con prodotti documentali a fine stage.
2.7 Vincoli temporali
Lo stage prevede un totale ore lavorative di 320 ripartite in 8 settimane, 8 ore giornaliere dal Luned`ı al Venerd`ı, dalle 8.30 alle 18.00 con un’ora e mezza di pausa pranzo dalle 12.30 alle 14.00. Mi era permesso di avere dei giorni di indisposizione o di indisponibilit`a per impegni universitari, potevo recuperare le ore perse facendo giorni in pi`u di quelli previsti.
2.8 Vincoli tecnologici
L’azienda ha richiesto che lo sviluppo dell’applicativo avvenga nel linguaggio di program- mazione C++, e utilizzando il framework QtQuick[5] di cui l’azienda vuole valutare i pregi e difetti per un eventuale inserimento nelle sue attivit`a di sviluppo di interfacce utenti. Inoltre mi `e stato chiesto di identificare eventuali alternative tecnologiche a QtQuick, migliori in qualche aspetto.
2.9 Rischi e complessit`a del progetto
Dopo una valutazione qualitativa basata sulle mie conoscenze e competenze a risolvere problemi simili agli obiettivi di progetto da raggiungere, sono giunto a totalizzare 7 obiettivi di complessit`a bassa, 8 di complessit`a alta e 7 di complessit`a media. La complessit`a alta, si verifica maggiormente nello sviluppo dell’interfaccia grafica utente, ad esempio gli obiettivi Ob04, Ob05, Fa01. La tabella sottostante riassume gli obiettivi funzionali e di qualit`a da raggiungere, con le valutazioni qualitative di complessit`a a raggiungerli:
Tabella 2: Valutazione della complessit`a
Obiettivi Complessit`a
Ob01, Ob02, Ob03, Ob07, Ob12, Ob09, Ob14 Media Ob04, Ob05, Ob10, Ob16, Fa01, De01, De02, De03 Alta Ob06, Ob08, Ob11, Ob13, Ob15, Ob17, Fa02 Bassa
2.10 Pianificazione
Il progetto `e stato diviso in 6 periodi, ciascuno con una durata valutata preventivamente in ore di formazione, di sviluppo effettivo del prodotto, e di ricerca di soluzioni alternative tecnologiche o di sviluppo:
Periodo 1 (40 ore) ∼ Spiegazione del contesto dell’applicativo, spiegazione dell’ambiente QtQuick[5] e analisi dei requisiti:
– Con il supporto del tutor aziendale comprendere il problema, la tecnologia di sviluppo dell’interfaccia, il contesto di lavoro, e i requisiti.
Periodo 2 (40 ore): Utilizzo diRESTG service in modalit`a sincrona e asinrona, e gestione dei dati nel framework QT:
Periodo 3 (120 ore): Sviluppo dell’applicativo secondo specifiche
Periodo 4 (40 ore): Trovare eventuali soluzioni alternative per realizzare l’appli- cativo con la stessa tecnologia o con tecnologie alternative, valutando i vantaggi e svantaggi di queste.
Periodo 5 (40 ore): Test dell’applicativo e delle soluzioni alternative
Periodo 6 (40 ore): Valutazione del lavoro: Redigere una relazione del lavoro svolto valutando le tecnologie utilizzate, la qualit`a del lavoro svolto, eventuali soluzioni alternative.
Il periodo relativo alle attivit`a di sviluppo e il periodo relativo alle attivit`a di verifica e validazione sono stati accorpati per formare un solo periodo che `e stato suddiviso in 3 periodi, suddivisi a loro volta in altri 3 periodi, i quali mirano rispettivamente allo sviluppo per soddisfare gli obiettivi in base alla loro importanza e alla loro priorit`a. Si definiscono le seguenti priorit`a:
Alta: Obiettivo da raggiungere nei primi incrementi;
Media: Obiettivo da raggiungere dopo aver raggiunto gli obiettivi di priorit`a alta;
Bassa: Obiettivo da raggiungere per ultimo.
Figura 2: Diagramma Work Breakdown Structure delle attivit`a di sviluppo La tabella sottostante `e stata concordata con il tutor aziendale, e riordina gli obiettivi in ordine di priorit`a e utilit`a decrescenti.
Tabella 3: Priorit`a degli obiettivi
Obiettivi Importanza Priorit`a
Ob01, Ob02, Ob03, Ob04, Ob07, Ob09, Ob12, Ob14, Ob15, Ob16
Obbligatorio Alta
Ob05, Ob08, Ob13, Ob17 Obbligatorio Media
Ob06, Ob10, Ob11, Obbligatorio Bassa
Fa01 Facoltativo Media
Fa02 Facoltativo Bassa
De02, De03 Desiderabile Alta
De01 Desiderabile Bassa
2.11 Analisi preventiva dei rischi
Prima di iniziare il progetto, ho identificato i rischi che potrebbero portare il progetto a sforare le ore pianificate, ho poi valutato per ciascun rischio, la probabilit`a di accadimento
nel corso del progetto e il grado di impatto. Pi`u precisamente, un rischio ha:
Probabilit`a alta: se si verificher`a quasi sicuramente;
Probabilit`a media: c’`e una possibilit`a concreta che si verifchi;
Probabilit`a bassa: si verificher`a raramente;
Impatto alto: provoca uno sforamento significativamente le ore pianificate, difficilmente risolvibile o irrisolvibile;
Impatto medio: provoca uno sforamento significativo delle ore pianificate, ma risolvibile;
Impatto basso: provoca sforamenti trascurabili (al massimo 8 ore di lavoro in pi`u).
La figura sottostante mostra l’attenzione, tramite azioni preventive ed eventualmente correttive, da portare ad ogni rischio identificato.
Trascurabile in parte
Inaccettabile.
Attenzione moderata
Inaccettabile.
Maggiore attenzione
Completamente trascurabile
Completamente trascurabile
Accettabile.
Attenzione moderata
Trascurabile in parte
Accettabile.
Maggiore attenzione
Accettabile.
Minore attenzione
Probabilità
Bassa Media Alta
Impatto
AltoMedioBassoFigura 3: Attenzione da portare ad un rischio La tabella sottostante elenca i rischi identificati.
Tabella 4: Rischi identificati
Id Descrizione Probabilit`a Impatto
Rsk01 Poca familiarit`a con il dominio applicativo. Alta Medio
Rsk02 Poca familiarit`a con la tecnologia QtQuick[5].
Alta Medio
Rsk03 Poca familiarit`a con il linguaggio QML. Alta Medio Rsk04 Complessit`a alta dell’obiettivo Ob04. Alta Medio Rsk05 Complessit`a alta dell’obiettivo Ob05. Alta Alto Rsk06 Complessit`a alta dell’obiettivo Ob10. Alta Medio Rsk07 Complessit`a alta dell’obiettivo Ob16. Alta Alta Rsk08 Complessit`a alta dell’obiettivo Fa01. Media Alto Rsk09 Complessit`a alta dell’obiettivo De01. Bassa Alto Rsk10 Complessit`a alta dell’obiettivo De02. Bassa Medio Rsk11 Complessit`a alta dell’obiettivo De03. Bassa Medio Rsk12 Un obiettivo di progetto `e incorretto. Bassa Alto Rsk13 Inadattabilit`a delle tecnologie allo sviluppo
di applicazioni veloci.
Media Medio
2.12 Qualit`a
In questa sottosezione, illustro i piani e le strategie adottate per garantire la qualit`a di prodotto e di processo. Il piano prevedeva un sistema di misurazione e verifica continua nelle attivit`a di progetto per rilevare e correggere tempestivamente eventuali anomalie per massimizzare l’economicit`a.
2.12.1 Qualit`a di prodotto
Gli obiettivi di qualit`a del prodotto richiesti, e quelli impliciti derivanti dal dominio applicativo, portavano al monitoraggio delle seguenti qualit`a di prodotto:
Qualit`a esterne
Accuratezza: Grado di accuratezza della capacit`a del prodotto a soddisfare i bisogni sotto specifiche condizioni. Verificabilit`a con metodi di analisi statica e dinamica, con indicatori invece di metriche. Valore accettabile: x ≥ 80%.
Robustezza: Capacit`a del prodotto a sopportare ingressi diversi (giusti, sbagliati, tanti, pochi) dall’utente e dall’ambiente. Verificabile con metodi di analisi
dinamica e misurabile con la seguente metrica (personalizzazione della metrica Sensitivity usata in statistica per valutare i classificatori binari):
Robustezza: X = d+ed d: Il numero di output corretti.
e: Il numero di fallimenti osservati.
Il valore accettabile: X ≥ 90% per ogni unit`a.
Efficienza nel tempo: Capacit`a del prodotto ad essere computazionalmente veloce. Verificabile con benchmarkG, e misura in millisecondi. Valore inaccettabile:
x ≥ 3000ms di risposta di un’unit`a.
Usabilit`a: L’essere comprensibile, apprendibile e attraente del prodotto.
Verificabile sottoponendo il prodotto in esecuzione, a valutazioni qualitative del tutor aziendale;
Qualit`a interne:
Modificabilit`a: L’essere modificabile ed estendibile con nuove funzionalit`a del prodotto. Verificabile con metodi di analisi statica e metrica di instabilit`a definita come segue:
Instabilit`a: I = AC A: Indice di accoppiamento.
C: Indice di coesione.
Il valore accettabile: I < 1 per ogni unit`a.
Qualit`a in uso:
Soddisfazione: Indice di soddisfazione del cliente. Da verificare mostrando ogni incremento al tutor aziendale, che grazie alla sua esperienza di sviluppo software in quel ambito, esprimer`a una soddisfazione che sar`a una buona approssimazione della soddisfazione del cliente.
2.12.2 Qualit`a di processo
Il tempo `e la risorsa limitata su cui potevano contare le attivit`a del progetto di stage, era quindi necessario monitorare le attivit`a di progetto per non superare le ore pianificate e garantire una copertura totale degli obiettivi. Ho quindi deciso di usare la metrica Cost Variance[14] adattando la sua definizione alle mie esigenze nel modo seguente:
Cost Variance (CV): CV = EV − AC EV (Earned Value)= Totale obiettivi raggiunti
Totale obiettivi × Totale ore;
AC (Actual Cost) `e il totale delle ore impiegate per raggiungere gli obiettivi.
Un valore di CV maggiore di 0 indica che il progetto evolve con maggior efficienza rispetto a quanto pianificato, mentre un valore minore di 0 indica che evolve con minor efficienza.
Capitolo 3
Ambiente di lavoro
In questo capitolo vengono presentati gli strumenti utillizati per svolgere correttamente le attivit`a di progetto.
3.1 Versionamento
Per quanto riguarda il versionamento, lo strumento utilizzato `e TortoiseSVN[15]. Questo strumento `e basato sul Subversion di Apache (SVN), e prevede un’interfaccia grafica facile da usare, infatti bastano due clic per il commit e il pull. Scritto per girare come un’estensione di Microsoft Windows, `e un programma gratuito e utilizzato dall’azienda come strumento di controllo versione nella gestione di configurazione dei suoi prodotti.
3.2 Altri strumenti per la gestione di progetto
Google Drive: per la condivisione veloce di file come guide, documentazioni, riferimenti utili e documenti informali.
Google Calendar: per la gestione degli eventi ed impegni.
3.3 Documentazione
Per quanto riguarda la produzione del manuale sviluppatore lo strumento utilizzato dall’azienda `e QDoc. Mentre per la redazione di documenti come ad esempio la relazione di lavoro svolto richiesta, l’azienda usa solitamente i pacchetti Microsoft Office, ma mi ha delegato la scelta del software da utilizzare per la loro produzione.
3.3.1 QDoc
QDoc[16] `e uno strumento per la generazione automatica di documentazione a partire dal codice commentato di classi C++ e/o QML. Genera documentazione sia in HTML che in WEBXML, senza generare i diagrammi delle classi. `E uno strumento semplice da usare ed `e installato insieme a Qt Creator[17]. Questo strumento `e sempre stato utilizzato dall’azienda in quanto strumento offerto da Qt Framework, il framework su cui si appoggiano quasi tutte le produzioni software dell’azienda.
3.3.2 TeXstudio
TeXstudio `e un editore di file scritti nel linguaggio di markup LATEX, linguaggio usato per la produzione di documenti basato sul programma di composizione tipografica TEX.
E distribuito con una licenza di software libero ed `` e disponibile per praticamente tutti i sistemi operativi, tra cui Microsoft Windows, macOS e le varie distribuzioni Linux.
Ho scelto questo strumento perch´e l’ho utilizzato pi`u volte per la redazione di relazioni
di progetti universitari e altri documenti, quindi ho pi`u pratica con questo strumento rispetto ai pacchetti Microsoft Office che ho utilizzato pochissimo tanti anni fa.
3.3.3 StarUML
Per la modellazione concettuale del sistema e la progettazione, `e stato necessario modellare con UML, la mia scelta `e ricaduta su StarUML disponibile in versione gratuita di prova.
L’ho identificato come il software pi`u completo e di facile utilizzo fra quelli dedicati (ad esempio, GNU Dia), oltre ad averlo usato nel progetto didattico di ingegneria del software. StarUML supporta sia i costrutti di UML 1.x che di UML 2.x e permette di modellare casi d’uso, i diagrammi delle classi, degli oggetti, delle attivit`a e di sequenza;
produce inoltre diagrammi di aspetto semplice ed essenziale adatti ad essere inseriti in relazioni formali.
3.4 Ambiente di sviluppo 3.4.1 IDE
L’applicazione richiesta doveva essere sviluppata con QtQuick[5] di Qt Framework. L’IDE utilizzato `e stato Qt Creator[17] in quanto unico IDE sul mercato che permetta lo sviluppo di applicazioni in Qt Framework. Questo IDE `e lo strumento di sviluppo dell’azienda da tanti anni, ed ha il vantaggio di aumentare la produttivit`a grazie alle sue numerose semplificazioni nella scrittura di codice.
3.4.2 Sistemi operativi
Il sistema operativo scelto dall’azienda per le sue attivit`a di progetto `e Microsoft Windows, in quanto cliente di molti prodotti Microsoft Windows come Microsoft Office. Bench´e questo sistema operativo abbia il difetto, che ho appreso durante un progetto universitario, di fare molte ottimizzazioni grafiche indesiderate che fanno credere che la codifica di un certo elemento grafico sia apparentemente corretta, non `e stato possibile cambiarlo in quanto imposto.
Capitolo 4
Analisi dei requisiti
Questo capitolo presenta l’analisi dei requisiti svolta per il progetto, approfondita con alcuni diagrammi dei casi d’uso e tabelle dei requisiti.
4.1 Casi d’uso
I diagrammi dei casi d’uso sono diagrammi UML che servono a descrivere le interazioni fra il sistema e gli utenti, esponendo cos`ı l’insieme delle funzionalit`a del sistema dal punto di vista dell’ utente. Ogni caso d’uso `e classificato secondo la seguente convenzione:
UC[Codice padre]*.[Codice identificativo]
Codice padre: il codice identificativo del caso d’uso generico che ha generato il caso d’uso in esame. Se il caso d’uso non `e stato generato da altri, va tralasciato;
Codice identificativo: Identifica univocamente il caso d’uso. `E un codice composto da sole cifre.
4.2 Attori
4.2.1 Attori primari
Un attore primario `e un utente che interagisce con il sistema per raggiungere un obiettivo.
Sono stati definiti i seguenti attori primari:
Operatore non autenticato: Un operatore dell’azienda cliente, come descritto nellasottosezione 2.4, che non ha ancora effetuato l’autenticazione presso il sistema;
Operatore autenticato: Un operatore dell’azienda cliente, come descritto nella sottosezione 2.4, che `e stato autenticato presso il sistema.
Figura 4: Rappresentazione degli attori primari nei diagrammi dei casi d’uso 4.2.2 Attori secondari
Un attore secondario `e un utente che interagisce con il sistema per aiutarlo a raggiungere gli obiettivi dell’attore primario. Vengono definiti i seguenti attori secondari:
LectraG: sistema esterno che fornisce tutti i dati relativi al PLM[4].
Figura 5: Rappresentazione degli attori secondari nei diagrammi dei casi d’uso 4.3 Diagrammi dei casi d’uso generali
4.3.1 Operatore non autenticato
Figura 6: Diagramma dei casi d’uso generali operatore non autenticato
Attori primari: Operatore non autenticato;
Descrizione: L’operatore non autenticato vuole accedere alle funzionalit`a del sistema;
Precondizione: Il sistema offre solo la funzionalit`a di autenticazione all’operatore non autenticato.
Postcondizione: Il sistema ha autenticato l’operatore;
Scenario principale:
– L’operatore non autenticato si autentica presso il sistema (UC1).
Estensioni:
– Se l’operatore non autenticato inserisce erroneamente le credenziali di accesso, viene ritornato un messaggio di errore (UC2).
4.3.2 Operatore autenticato
Figura 7: Diagramma dei casi d’uso generali operatore autenticato
Attori primari: Operatore autenticato;
Descrizione: L’operatore autenticato accede alle funzionalit`a del sistema;
Precondizione: Il sistema offre le seguenti funzionalit`a all’operatore autenticato:
– Ricerca di modelli (UC3);
– Ricerca di tessuti (UC8);
– Visualizzazione di una lista di modelli (UC4);
– Visualizzazione di un modello (UC5);
– Visualizzazione di una lista di tessuti (UC7);
– Visualizzazione di un tessuto (UC6);
– Lancio produzione (UC10);
– Richiesta nuova abbinazione modello e tessuto (UC12);
– Personalizzazione dell’interfaccia grafica (UC13);
– Visualizzazione delle richieste di lancio effetuate (UC14);
– Confermare un lancio di produzione sospeso (UC15).
Postcondizione: Il sistema ha offerto le funzionalit`a riservate all’operatore autenticato;
Scenario principale:
– L’operatore autenticato apre l’interfaccia grafica per accedere alle funzionalit`a.
Estensioni:
– Se l’operatore autenticato non inserisce una quantit`a di produzione nella fase di lancio, viene ritornato un messaggio di errore (UC10);
– Se l’operatore autenticato inserisce una quantit`a di produzione maggiore della giacenzaG del tessuto, in fase di lancio produzione, viene ritornato un messaggio di errore (UC11);
4.4 Altri diagrammi d’uso
In questa sezione presento, con un ulteriore livello di dettaglio, alcuni diagrammi d’uso presenti in Figura 7.
4.4.1 UC3: Ricerca modello
Figura 8: UC3: Ricerca modello
Attori primari: Operatore autenticato
Descrizione: L’operatore autenticato effettua una ricerca di modelli che possiedono certe caratteristiche;
Precondizione: Il sistema permette all’operatore autenticato di effettuare una ricerca di modelli in base al loro stato o ad una parola chiave;
Postcondizione: Il sistema ha ricevuto i dati di filtro ed ha ritornato all’utente, una lista di modelli che possiedono le caratteristiche richieste;
Scenario principale:
– L’operatore autenticato inserisce una parola chiave (UC3.1);
– L’operatore autenticato seleziona uno stato del ciclo di vita dell’articoloG: UC3.3, UC3.4, UC3.5, UC3.6, UC3.7, UC3.8.
4.4.2 UC9: Lancio produzione
Figura 9: UC9: Lancio produzione
Attori primari: Operatore autenticato;
Descrizione: L’operatore autenticato lancia la produzione di un modello;
Precondizione: L’utente ha selezionato un modello, un tessuto e un colore del modello. Il sistema gli permette di inserire una quantit`a di produzione per le taglie in cui l’articoloG verr`a prodotto;
Postcondizione: La richiesta di lancio produzione `e stata validata da sistema ed aggiunta alla lista delle richieste di lanci produzione;
Scenario principale:
– L’operatore autenticato seleziona un modello;
– L’operatore autenticato seleziona un tessuto del modello;
– L’operatore autenticato seleziona un colore del modello;
– L’operatore autenticato seleziona inserisce una quantit`a da produrre per ogni taglia.
UC9.1: Inserimento quantit`a per taglie
Figura 10: UC9.1: Inserimento quantit`a per taglia
Attori primari: Operatore autenticato;
Descrizione: L’operatore autenticato inserisce una quantit`a per una taglia di produzione dell’articoloG;
Precondizione: Il sistema permette all’utente di inserire una quantit`a di produ- zione per ogni taglia disponibile dell’articolo;
Postcondizione: Il sistema ha validato le quantit`a inserite;
Scenario principale:
– L’operatore autenticato inserisce una quantit`a da produrre per ogni taglia (UC9.1.1).
UC9.2: Inserimento automatico da curva
Figura 11: UC9.2: Inserimento automatico da curva
Attori primari: Operatore autenticato;
Descrizione: L’operatore autenticato sceglie di inserire in modo automatico le quantit`a di produzione per ogni taglia;
Precondizione: Il sistema permette all’utente di inserire in modo automatico una quantit`a di produzione per ogni taglia, inserendo un totale e scegliendo una curva di distribuzione;
Postcondizione: Il sistema ha validato le quantit`a inserite;
Scenario principale:
– L’operatore autenticato seleziona l’inserimento automatico delle quantit`a da produrre per ogni taglia;
– L’operatore autenticato inserisce il totale di vestiti da produrre indipendente- mente dalle taglie (UC9.2.1);
– L’operatore autenticato seleziona la curva di ripartizione del totale nelle diverse taglie (UC9.2.2).
4.5 Requisiti
Sono riportati di seguito i requisiti individuati per il progetto con rispettivo codice identificativo, importanza e breve descrizione. Il codice identificativo `e la sigla che identifica ogni requisito e rispetta la seguente notazione:
R[Tipo][Importanza][Identificativo]
Tipo:
– F: requisito funzionale;
– V: requisito di vincolo;
– Q: requisito di qualit`a.
Importanza:
– O: requisito obbligatorio;
– D: requisito desiderabile;
– F: requisito facoltativo.
Identificativo: codice che identifica in modo univoco un requisito. Viene rap- presentato con la notazione decimale puntata per rendere pi`u intuibile la forma gerarchica.
4.5.1 Requisiti funzionali
Al termine dell’ attivit`a di analisi dei requisiti, sono stati identificati e consolidati 76 requisiti funzionali. La tabella che segue presenta alcuni di questi requisiti.
Tabella 5: Alcuni requisiti funzionali Id Importanza Descrizione
RFO01 Obbligatorio Un operatore non autenticato deve potersi autenti- care.
RFO01.1 Obbligatorio Per autenticarsi, un operatore non autenticato deve poter inserire il suo nome utente.
RFO01.2 Obbligatorio Per autenticarsi, un operatore non autenticato deve poter inserire la sua password.
RFO02 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di modelli.
RFO02.1 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di un modello preciso inserendo il codice modello.
RFO02.2 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di un modello preciso inserendo il codice del suo tessuto principale.
RFO02.5 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di modelli che sono in stato distinta baseG. RFO02.9 Obbligatorio Un operatore autenticato deve poter effettuare una
ricerca di modelli che sono in stato lanciato.
RFO02.10 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di modelli che sono in stato in produzione.
RFO03 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di tessuti.
RFO03.1 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di un tessuto preciso inserendo il codice tessuto.
RFO03.2 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di tessuti che contengono una certa caratteristica specificata nel campo breve descrizione.
RFO03.3 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di tessuti che contengono una cer- ta caratteristica specificata nel campo descrizione estesa.
RFO03.4 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di tessuti inserendo un limite inferiore di giacenzaG.
RFO03.5 Obbligatorio Un operatore autenticato deve poter effettuare una ricerca di tessuti inserendo un limite superiore di giacenzaG.
RFO06 Obbligatorio Un operatore autenticato deve poter lanciare una produzione di abbigliamento.
RFO06.1 Obbligatorio Per lanciare una produzione, l’operatore autenti- cato deve poter selezionare un modello e un tes- suto associato con giacenzaG aggiornata all’ultimo minuto.
RFO06.2 Obbligatorio Per lanciare una produzione, l’operatore autenticato deve in alternativa poter selezionare un tessuto con giacenzaG aggiornata all’ultimo minuto e un modello associato.
RFO06.3 Obbligatorio Per lanciare una produzione, l’operatore autenticato deve poter selezionare un colore di produzione.
RFO06.4 Obbligatorio Per lanciare una produzione, l’operatore autenticato deve poter inserire manualmente la quantit`a.
RFO06.4.1 Obbligatorio Per inserire manualmente la quantit`a, l’operatore autenticato deve poter inserire una quantit`a per una taglia del modello.
RFO06.5 Obbligatorio Per lanciare una produzione, l’operatore autenticato deve poter inserire in automatico la quantit`a.
RFO06.5.1 Obbligatorio Per inserire in automatico la quantit`a, l’operatore autenticato deve poter inserire il totale.
RFO06.5.2 Obbligatorio Per inserire in automatico la quantit`a, l’operato- re autenticato deve poter selezionare una curva di ripartizione.
RFO06.6 Obbligatorio Se l’operatore autenticato non inserisce nessuna quan- tit`a, l’applicazione deve dare un messaggio di errore di quantit`a non specificata.
RFO06.7 Obbligatorio Se l’operatore autenticato inserisce una quantit`a mag- giore della giacenzaG del tessuto, l’applicazione deve dare un messaggio di errore di tessuto insufficiente per la quantit`a specificata.
RFF01 Facoltativo Un operatore autenticato deve poter modificare l’aspetto dell’interfaccia grafica.
RFF01.1 Facoltativo Un operatore autenticato deve poter aumentare la dimensione dei caratteri fino 200%.
RFF01.3 Facoltativo Un operatore autenticato deve poter selezionare un nuovo colore per lo sfondo dell’applicazione.
RFD01 Desiderabile Un operatore autenticato dovrebbe poter cambiare la lingua dell’applicazione.
RFD01.1 Desiderabile Un operatore autenticato dovrebbe poter cambiare la lingua dell’applicazione in inglese.
RFD02 Desiderabile Un operatore autenticato dovrebbe aver accesso so- lo ai modelli della collezione di cui `e autorizzato a consultare.
4.5.2 Requisiti di qualit`a
Tabella 6: Tabella dei requisiti di qualit`a Id Importanza Descrizione
RQO01 Obbligatorio L’interfaccia grafica deve essere veloce nel cambio finestra.
RQO02 Obbligatorio L’interfaccia grafica deve essere veloce nel caricamento di una lista di modelli.
RQO03 Obbligatorio L’interfaccia grafica deve essere veloce nel caricamento di una lista di tessuti.
RQO04 Obbligatorio L’interfaccia grafica deve essere intuitiva.
4.5.3 Requisiti di Vincolo
Tabella 7: Tabella dei requisiti di vincolo Id Importanza Descrizione
RVO01 Obbligatorio L’interfaccia grafica deve essere sviluppata con il framework QtQuick 2.x .
RVO02 Obbligatorio L’interfaccia grafica deve essere compatibile con schermi di risoluzione di almeno 1920x1080.
RVO03 Obbligatorio L’interfaccia grafica deve essere compatibile con dispositivi touch screen senza l’uso di mouse.
RVO04 Obbligatorio L’interfaccia grafica deve essere compatibile con dispositivi touch screen senza l’uso di tastiera.
RVO05 Obbligatorio L’interfaccia grafica deve essere compatibile con schermi di risoluzione di almeno 10 pollici.
RVO06 Obbligatorio Deve essere fornita una relazione del lavoro svolto.
RVO06.1 Obbligatorio La relazione deve riassumere il processo di sviluppo adottato.
RVO06.2 Obbligatorio La relazione deve riassumere i pregi e difetti di QtQuick.
RVF01 Obbligatorio Devono essere fornite alternative a QtQuick.
4.6 Riepilogo
Tabella 8: Totale dei requisiti
Tipo Obbligatori Desiderabili Facoltativi
Funzionale 65 5 6
Vincolo 8 0 2
Qualit`a 4 0 0
Capitolo 5
Studio delle tecnologie
Questo capitolo presenta brevemente le tecnologie richieste per lo sviluppo dell’applicazione, QtQuick e QML, e le alternative a quest’ultime.
5.1 QML
QML[6] (Qt Meta Language o Qt Modelling Language) `e un linguaggio dichiarativo che consente di descrivere le interfacce utente in termini di componenti visive e in che modo interagiscono e si relazionano tra loro. Offre una sintassi dichiarativa, molto leggibile, simile a JSON con supporto per espressioni JavaScript. Viene principalmente usato per lo sviluppo di applicazioni per dispositivi mobile: Ubuntu Touch, SailfishOS, Android, iOS, Windows Phone oltre che su Linux, Windows, OSX.
Un documento QML definisce una gerarchia di oggetti con un layout strutturato altamente leggibile, viene caricato ed eseguito dal runtime QML. I tipi e le funzionalit`a pi`u comuni alle interfacce utente sono forniti nell’importazione di QtQuick[8].
5.2 QtQuick
QtQuick[5] `e una tecnologia per interfacce grafiche utente che separa la progettazione dichiarativa dell’interfaccia dalla logica di businessG. Invece delle tradizionali APIG C++ di Qt, l’interfaccia grafica utente dell’applicazione `e scritta in QML, al quale QtQuick fornisce sia un’API[7] QML (tipi QML per la creazione di interfacce utente con il linguaggio QML), sia un’API[8] C++ per estendere applicazioniQMLcon codice C++.
Le applicazioni sviluppate con questa tecnologia seguono una progettazione top-down partendo da un design architetturale Model-View o Model–View–ViewModel[18].
Vantaggi
Applicazionecross-platformG, sia desktop che mobile, con un’interfaccia utente fluida e dinamica;
Componenti grafici non nativi, cio`e indipendenti dal sistema operativo. Ad esempio un bottoneQML non cambia la sua apparenza se `e visualizzato su un dispositivo Android piuttosto che su dispositivo ios;
Documentazione fornita molto ricca;
Svantaggi
Peggioramento delle performance di caricamento di una finestra composta di tanti elementi grafici personalizzati;
Il caricamento asincrono di componenti grafici si limita ad un sottoinsieme molto ristretto di tipi QML, e nel caso di un’esecuzione asincrona di una funzione Java- Script, i tipi dei parametri permessi sono: boolean, number, string, object, array e ListModel;
Alcuni servizi nativi non disponibili, ad esempio l’uso della fotocamera, del microfono ecc...;
Tecnologia ancora molto giovane, il primo rilascio `e avvenuto nel 2010 e il rilascio della versione stabile `e stato nel mese di giugno 2018. La community di sviluppatori che usano questa tecnologia `e quindi piccola, questo rende difficile ottenere un aiuto esterno in caso di difficolt`a;
5.3 Alternative tecnologiche cross-platform
Quando si vuole sviluppare un’applicazionecross-platformG, la prima scelta di linguaggio di programmazione che si fa `e Java. Negli ultimi 5 anni sono nate molte tecnologie open source o a pagamento, basate sul linguaggio di scripting ad oggetti ed eventi JavaScript, per lo sviluppo di applicazioni cross-platform. In modo da aiutare le aziende, che non riuscivano a permettersi diversi team per lo sviluppo di applicazioni cross-platform, ad usare un codice condiviso scritto con HTML, CSS e JavaScript. Alcune di queste tecnologie sono: NativeScript, Electron, Ionic Framework, React Native.
Vantaggi principali delle tecnologie JavaScript cross-platform:
Veloce da imparare per chi ha familiarit`a con le tecnologie web;
Sviluppo pi`u veloce delle applicazioni;
Interfacce grafiche pi`u belle con tanti effetti grafici;
Componenti grafici (pulsanti, input ecc..) nativi;
Alta affidabilt`a e robustezza delle applicazioni;
Svantaggi principali delle tecnologie JavaScript cross-platform:
Come QtQuick, alcune di queste tecnologie richiedono la scrittura di codice nativo per le dipendenze verso servizi nativi;
Problemi di sicurezza in quanto JavaScript `e conosciuto per questo suo difetto;
Esistono altre tecnologie basate su altri linguaggi di programmazione per lo sviluppo di applicazioni cross platform come Xamarin nel linguaggio C#, mentre Qt rimane il migliore per lo sviluppo di applicazioni cross-platform nel linguaggio C++.
Capitolo 6
Progettazione
In questo capitolo illustro le attivit`a di progettazione svolte (progettazione architettu- rale, progettazione di dettaglio e progettazione dell’interfaccia grafica), approfondite di diagrammi delle classi, diagrammi di sequenza, tabelle delle classi e librerie utilizzate.
6.1 Progettazione architetturale dell’applicativo
La fase di progettazione architetturale `e stata pi`u veloce del previsto in quanto ho deciso di usare l’architettura che era stata scelta in passato per sviluppare il primo prototipo del prodotto. Questa architettura non `e altro che un’istanza del design architetturale Model–View–ViewModel[18] (MVVM).
Figura 12: Architettura Model–View–ViewModel (MVVM) Il MVVM ha le seguenti qualit`a:
Netta separazione dei componenti architetturali, aumentando cos`ı la riusabilit`a, la modularit`a e la testabilit`a dell’applicazione;
Incapsulazione che aumenta la manutenibilit`a e l’estendibilit`a.
In QtQuick[5], l’architettura MVVM dell’applicazione `e progettata nel seguente modo:
Model: Namespace di classi C++ che rappresentano la logica di businessG dell’applicazione: il modello, il tessuto, una curva di ripartizione ecc...;
ViewModel: Namespace di classi C++ che estendono le classi QObject, QSort- FilterProxyModel e QAbstractItemModel. In questo namespace ho aggiunto il sottonamespace,ViewsSettings, di classi che hanno il compito di fornire alle views tutti i dati relativi alle impostazioni di stile e di layout;
View: Namespace di tipi classici QML e tipi QML personalizzati. Inoltre in questo ho aggiunto il sottonamespace, FFPViewsComponents, di tipi QML personalizzati usati frequentemente dalle views, ad esempio bottoni, labels ecc... .
Figura 13: Progettazione architettura dell’applicativo 6.2 Altre librerie usate
6.2.1 SortFilterProxyModel
Questa libreria `e stata suggerita dal tutor aziendale in quanto usata per sviluppare il primo prototipo dell’applicativo. Essa riduce i tempi di codifica offrendo una classe prefabbricata(SortFilterProxyModel[19]) che permette di filtrare una lista di oggetti generici, in base a diversi parametri. Ho usato questa libreria per implementare le funzionalit`a di ricerca.
6.2.2 Quick Promise
Quick Promise[20] `e una libreria che sfrutta il tipo Timer di QML per simulare l’oggetto Promise[21], tanto conosciuto dagli sviluppatori di applicazioni in JavaScript, per le chiamate asincrone in QtQuick, evitando cos`ı l’uso della programmazione concorrente che avrebbe allungato i tempi di sviluppo dovuto a tutti i problemi legati alla concorrenza tra thread.
6.3 Progettazione di dettaglio
Per avere una progettazione di dettaglio basata sul framework QtQuick, nei diagrammi delle classi sottostanti, ho usato le seguenti convenzioni:
Lo stereotipo <<invokable>> `e stato applicato ai metodi e funzioni statiche delle classi del namespace ViewModel, e significa che questa funzione pu`o essere invocata dalle views;
Lo stereotipo <<QMLTYPE>> `e stato applicato alle classi del namespace View, e significa che questa classe `e in realt`a un tipo QML personalizzato;
Gli stereotipi <<QPROPERTY>> e <<readonly>> sono stati applicati a campi dati di alcune classi ViewModel, e significano che questi campi dati sono utilizzabili dalle views tramite metodi get e set appropriati, e costanti se sono readonly;
6.3.1 Model
Figura 14: Diagramma delle classi Model 1/3
Tabella 9: Classi Model 1/3 Classe Descrizione
Servizi Questa classe `e un insieme di funzioni statiche per effetuare determinate chiamateRESTG.
LogProgram le istanze di questa classe permettono di registrare uno storico, detto anche log, dell’applicazione.
Shop classe che rappresenta un negozio di abbigliamento.
ShopLinea classe che rappresenta una linea di abbigliamento.
ShopStagione rappresenta una stagione di abbigliamento.
Figura 15: Diagramma delle classi Model 2/3
Tabella 10: Classi Model 2/3 Classe Descrizione
Articolo Rappresenta un articoloG.
Lancio Classe che rappresenta un lancio di produzione.
LancioDettaglio Classe di oggetti che sono dettagli di lanci di produzione.
Diba Rappresenta la distinta baseG di un articolo.
Colore Classe la cui istanza rappresenta il colore di un articolo.
Filtro Classe le cui istanze rappresentano clausole di una query.
Figura 16: Diagramma delle classi Model 3/3
Tabella 11: Classi Model 3/3 Classe Descrizione
SAIFFPLibrary Insieme di funzioni statiche per le connessioni al server.
Materiale Rappresenta un materiale in magazzino, necessario alla produzione di abbigliamenti.
Taglia Rappresenta una taglia di produzione di un abbigliamento.
Menu Classe delle funzionalit`a principali visualizzate in prima finestra.
ProdottoFinito Rappresenta un prodotto finito, e contiene informazioni sul modello e il tessuto principale.
6.3.2 ViewModel
Figura 17: Diagramma delle classi ViewModel 1/5
Tabella 12: Classi ViewModel 1/5 Classe Descrizione
Colori Il singleton di questa classse contiene i parametri statici, modificabili, sul colore di diversi componenti grafici.
Layout Il singleton di questa classe contiene i parametri, modificabili, del layout dell’applicativo.
Figura 18: Diagramma delle classi ViewModel 2/5
Tabella 13: Classi ViewModel 2/5 Classe Descrizione
Appoggio Questa classe rappresenta un middleware per le operazioni di login, logout, salva lancio e salva richiesta.
ElencoFiltri Tipo lista di oggetti di tipo Model::Filtro.
ListModello Generalizzazione di alcune classi del ViewModel che rappresentano una lista di oggetti.
SAIFFPGeneral Classe di costanti di operazioni permesse in una query al lato server.
Figura 19: Diagramma delle classi ViewModel 3/5
Tabella 14: Classi ViewModel 3/5 Classe Descrizione
CurveModel Lista di curve statistiche.
Curve Curva statistica sulle taglie, cio`e una statistica di utilizzo di determinate taglie.
TagliaCurve Classe che deriva da QObject. Rappresenta una taglia oggetto di una curva di statistica.
Figura 20: Diagramma delle classi ViewModel 4/5
Tabella 15: Classi ViewModel 4/5 Classe Descrizione
ColoreModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Colore.
DibaModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Diba.
LancioModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Lancio.
MenuModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Menu.
ArticoloModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Articolo.
MaterialeModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Materiale.
Figura 21: Diagramma delle classi ViewModel 5/5
Tabella 16: Classi ViewModel 5/5 Classe Descrizione
TagliaModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Taglia.
ProdottoFinitoModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::ProdottoFinito.
ShopModel Classe concreta che deriva da ListModello. Rappresenta una lista di oggetti Model::Shop.
6.3.3 View
Figura 22: Diagramma delle classi View 1/10
Tabella 17: Classi View 1/10 Classe Descrizione
FFPLancio Tipo QML personalizzato per visualizzare tutte le informazioni su un lancio.
FFPTaglia Tipo QML personalizzato per visualizzare tutte le informazioni su una taglia in fase di lancio produzione.
FFPColore Tipo QML personalizzato per visualizzare tutte le informazioni su un colore di unarticoloG.
Figura 23: Diagramma delle classi View 2/10
Tabella 18: Classi View 2/10 Classe Descrizione
FFMateriale Tipo QML personalizzato per visualizzare tutte le informazioni di un materiale.
FFPArticolo Tipo QML personalizzato per visualizzare tutte le informazioni di un articolo.
FFPModello Tipo QML personalizzato per visualizzare tutte le informazioni di un modello.
FFPDibaMat Tipo QML personalizzato per visualizzare tutte le informazioni di una distinta baseG.
Figura 24: Diagramma delle classi View 3/10
Tabella 19: Classi View 3/10 Classe Descrizione
FFPButton Tipo Button di QML personalizzato.
FFPCheckBox Tipo CheckBox di QML personalizzato.
FFPField Tipo TextField di QML personalizzato.
FFPRangeSlider Tipo RangeSlider di QML personalizzato.
FFPSwitch Tipo Switch di QML personalizzato.
FFPText Tipo Text di QML personalizzato.
FFPLabel Tipo Label di QML personalizzato.
FFPProgressBar Tipo ProgressBar di QML personalizzato.
FFPRadioButton Tipo RadioButton di QML personalizzato.
Figura 25: Diagramma delle classi View 4/10
Tabella 20: Classi View 4/10 Classe Descrizione
main Tipo QML punto di ingresso del programma
MainForm Tipo QML personalizzato che rappresenta il layout principale dell’applicazione, dove verranno visualizzati tutti gli elementi visivi. Si divide in intestazione(Banner) e Body(StackView).
Banner Tipo QML personalizzato che rappresenta l’intestazione fissa dell’applicazione.
StackView Tipo QML, rappresenta il body, e grazie a questo tipo `e saltare da una view all’altra in modo fluido e veloce.
FFPSuccessMessage Tipo Popup di QML personalizzato per visualizzare un messaggio di successo di un’operazione.
FFPErrorMessage Tipo Popup di QML personalizzato per visualizzare un messaggio di errore.
Figura 26: Diagramma delle classi View 5/10
Tabella 21: Classi View 5/10 Classe Descrizione
ArticoloFiltro Tipo QML personalizzato che rappresenta la finestra per la ricerca e la visualizzazione di articoli.
ArticoloSelez Tipo QML personalizzato per visualizzare informazioni su un articoloG selezionato.
Filtro Tipo QML personalizzato per visualizzare le opzioni di ricerca di un articolo.
Figura 27: Diagramma delle classi View 6/10
Tabella 22: Classi View 6/10 Classe Descrizione
Login Tipo QML personalizzato che rappresenta la finestra di login.
MenuPage Tipo QML personalizzato che rappresenta la finestra di selezione di una delle varie funzionalit`a principali dell’applicazione.
MenuShop Tipo QML personalizzato che rappresenta la finestra di selezione di un negozio di abbigliamento.
RiepilogoLanci Tipo QML personalizzato che rappresenta la finestra di visualizzazione dei lanci sospesi.
Figura 28: Diagramma delle classi View 7/10
Tabella 23: Classi View 7/10 Classe Descrizione
MaterialeFiltro Tipo QML personalizzato che rappresenta la finestra per la ricerca e la visualizzazione di materiali.
MaterialeSelez Tipo QML personalizzato per visualizzare informazioni su un materiale selezionato.
FiltroMat Tipo QML personalizzato per visualizzare le opzioni di ricerca di un materiale.
Figura 29: Diagramma delle classi View 8/10
Tabella 24: Classi View 8/10 Classe Descrizione
Setting Tipo QML personalizzato che rappresenta la finestra per l’impostazione dei colori e del layout dell’applicazione.
SettingColor Tipo QML personalizzato per l’impostazione di un colore.
SettingOpGrad Tipo QML personalizzato per l’impostazione dell’opacit`a e del gradiente.
Figura 30: Diagramma delle classi View 9/10
Tabella 25: Classi View 9/10 Classe Descrizione
Lancio Tipo QML personalizzato che rappresenta la finestra per lanciare delle produzioni.
LancioTag Tipo QML personalizzato per l’inserimento dei dati per un lancio di produzione.
LancioSel Tipo QML personalizzato per visualizzare le informazioni sull’articoloG selezionato per il lancio produzione.
Curves Tipo QML personalizzato per visualizzare le varie curve di inserimento.
TagliaQty Tipo QML personalizzato per l’inserimento e la visualizzazione della quantit`a di produzione di una taglia.
TotaleField Tipo QML personalizzato per l’inserimento e la visualizzazione del totale di articoli da produrre.
Figura 31: Diagramma delle classi View 10/10
Tabella 26: Classi View 10/10 Classe Descrizione
SostituzioneMat Tipo QML personalizzato che rappresenta la finestra per sostituire il materiale di un articolo
6.3.4 Design patterns Template Method
Nel diagramma delle classi inFigura 18, la classe ListModello `e stata progettata secondo il design pattern Template Method. I suoi metodi template sono fillList, getPath e size, hanno un comportamento che cambia a seconda della sottoclasse concreta. I metodi getPath e fillList vengono usati dentro al metodo createModel per rispettivamente ottenere il nome del servizio per effettuare una richesta al server, e successivamente creare la lista a partire dai dati ricevuti. La codifica del metodo createModel si presenterebbe quindi nel seguente modo:
b o o l L i s t M o d e l l o :: c r e a t e M o d e l (c o n s t Q S t r i n g & token , E l e n c o F i l t r i * f ) { /* P r e p a r o la v a r i a b i l e j s o n _ i n p u t */
Q J s o n O b j e c t j s o n _ o u t p u t ;
// c h i a m a t a p o l i m o r f a su g e t P a t h ()
b o o l r i s u l t a t o = S e r v i z i :: e f f e t t u a R i c h i e s t a ( g e t P a t h () , j s o n _ i n p u t ,
& j s o n _ o u t p u t );
/* S v o l g o d i v e r s e o p e r a z i o n i di c o n t r o l l o di e s i t o p o s i t i v o */
r e t u r n f i l l L i s t ( j s o n _ o u t p u t );// c h i a m a t a p o l i m o r f a }
Il metodo size restituisce la size della lista sottoclasse.
Observer
Nel diagramma delle classi inFigura 30, i tipi QML LancioTag, TotaleField, TagliaQty, Curves e FFPTaglia, sono stati progettati seguendo il pattern Observer. LancioTag osserva Curves, TotaleField e TagliaQty, mentre Curves osserva FFPTaglia. Pi`u precisa- mente TotaleField e TagliaQty notificano a LancioTag un cambiamento di valore ogni volta che l’utente inserisce un nuovo valore, FFPTaglia notifica Curves che l’utente ha scelto la sua curva, e Curves notifica questo cambiamento a LancioTag. In questo modo LancioTag riesce ad aggiornare i valori del modello in tempo reale per un salvataggio e una visualizzazione veloce dei dati del lancio. Sempre guardando laFigura 30, si nota che esiste delle associazioni cicliche a causa dei tipi astratti che non esistono nel linguaggio QML, ma non `e un problema in quanto la creazione degli oggetti `e sequenziale e i campi dati vengono inizializzati per dependency injection.
6.3.5 Diagrammi di sequenza
In questa sezione vengono mostrati alcuni diagrammi di sequenza per una maggiore comprensione delle interazioni tra gli oggetti.
