Università degli Studi di Padova - Sviluppo di una Timeline integrata in VideoMatch - DIPARTIMENTO DI MATEMATICA - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
D IPARTIMENTO DI M ATEMATICA
C ORSO DI L AUREA IN I NFORMATICA
Sviluppo di una Timeline integrata in
VideoMatch
Tesi di laurea triennale
Relatore Laureando
Prof. Gilberto Filè Federico Ziliotto
A NNO A CCADEMICO 2013-2014
Ringraziamenti
Un grazie particolare all’azienda SICS S.r.l. e al suo titolare, Michele Crestani, per
l’opportunità di vivere un’esperienza lavorativa importante che mi ha formato e da cui
ho imparato le sfide e i problemi che si vivono giornalmente nel mondo del lavoro.
Desidero ringraziare Carlo Gambirasio, per il supporto e l’aiuto ottenuto durante
l’esperienza di stage, per essere sempre stato disponibile nei miei confronti e per tutti i
consigli che mi ha dato per risolvere i problemi più difficili.
Vorrei esprimere la mia gratitudine a tutto il corpo docente del corso di Laurea in
Informatica e in particolare al Prof. Gilberto Filè, relatore della mia tesi, per il supporto
e l’aiuto che mi ha dato nel preparare la tesi.
Desidero ringraziare con affetto i miei genitori e la mia famiglia per il sostegno, il
grande aiuto e per essermi stati vicini in ogni momento durante gli anni di studio.
Infine voglio fare un ringraziamento a tutti i miei amici e conoscenti per tutti gli anni
passati insieme.
Padova, Ottobre 2014 Federico Ziliotto
iii
Indice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Descrizione dello stage 5
2.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 VideoMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Esportazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Requisiti e obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Matrice azioni . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Norme, Strumenti e tecnologie utilizzate 11
3.1 Ambiente di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.5 GUI Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.6 Tortoise SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Norme di Codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Analisi dei requisiti 15
4.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Tabella di tracciamento dei requisiti Funzionali . . . . . . . . 25
4.2.2 Tabella di tracciamento dei requisiti di Vincolo . . . . . . . . 27
5 Progettazione e codifica 29
5.1 Ambiente software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.2 Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.3 VideoMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
vvi INDICE
5.2.1 VideoMatch::design::timeline::timelinePanel . . . . . . . . . . 32
5.2.2 VideoMatch::design::timeline::timelineTable . . . . . . . . . . 37
5.2.3 VideoMatch::design::timeline::buttons . . . . . . . . . . . . . 39
5.3 Tabella di tracciamento requisiti-classi . . . . . . . . . . . . . . . . . 42
5.4 Design Pattern utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Verifica e validazione 49
6.1 Analisi Statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Analisi Dinamica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 Tabella di tracciamento test-requisiti . . . . . . . . . . . . . . . . . . 53
7 Conclusioni 55
7.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 55
7.2 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.3 Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bibliografia 57Elenco delle figure
2.1 Schermata di analisi di una partita in VideoMatch . . . . . . . . . . . 6
2.2 Visualizzazione delle azioni di gioco di una partita . . . . . . . . . . 8
2.3 Matrice che visualizza il numero di azioni per giocatore e per tipo . . 8
3.1 Logo del linguaggio java . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Logo dell’IDE Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Logo di Tortoise SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Use Case - UC0: Scenario principale . . . . . . . . . . . . . . . . . . 16
4.2 Use Case - UC1: Visualizzazione della timeline delle azioni per giocatore 17
4.3 Use Case - UC1.2: Visualizza informazione azioni . . . . . . . . . . . 18
4.4 Use Case - UC1.3: Selezione delle azioni . . . . . . . . . . . . . . . . 19
4.5 Use Case - UC1.4: Controllo della timeline . . . . . . . . . . . . . . . 21
4.6 Use Case - UC2: Visualizzazione del numero di azioni per tipo . . . . 23
5.1 Architettura generale, vista package . . . . . . . . . . . . . . . . . . 31
5.2 Struttura del package TimelinePanel . . . . . . . . . . . . . . . . . . 32
5.3 Selezione dei pannelli dei giocatori nella timeline . . . . . . . . . . . 34
5.4 Visualizzazione dello slider della Timeline . . . . . . . . . . . . . . . 36
5.5 Visualizzazione del package timelineTable . . . . . . . . . . . . . . . 38
5.6 Architettura del package buttons . . . . . . . . . . . . . . . . . . . . 40
5.7 Dettaglio della schermata di esportazione delle azioni, con la lista
delle azioni esportate tramite la il pulsante di esportazione . . . . . . 41
5.8 Diagramma descrittivo del design pattern MVC . . . . . . . . . . . . 43
5.9 Diagramma della struttura del pattern Adapter . . . . . . . . . . . . 44
5.10 Diagramma della struttura del pattern Façade . . . . . . . . . . . . . 45
5.11 Diagramma della struttura del pattern Observer . . . . . . . . . . . . 46
5.12 Diagramma della struttura del pattern Singleton . . . . . . . . . . . . 47
viiviii ELENCO DELLE TABELLE
Elenco delle tabelle
4.1 Tabella di tracciamento dei requisiti Funzionali . . . . . . . . . . . . 25
4.2 Tabella di tracciamento dei requisiti di Vincolo . . . . . . . . . . . . . 27
5.1 Tabella di tracciamento requisiti-classi . . . . . . . . . . . . . . . . . 42
6.1 Tabella di tracciamento test-requisiti . . . . . . . . . . . . . . . . . . 53Capitolo 1
Introduzione
Negli ultimi anni, il progresso delle tecnologie informatiche ha portato la loro ap-
plicazione in molti ambiti prima inesplorati. Uno di questi è lo sport professionistico,
che ha la possibilità, con le tecnologie oggi a disposizione, di ricavare dati di tipo
statistico sugli atleti in campo e di analizzarli.
Dato l’ammontare di dati che si possono ottenere (fisici, tattici, posizionali,
temporali) e la poca esperienza del personale tecnico con gli strumenti informatici
offerti, è necessario che i software prodotti allo scopo di lavorare su tali dati siano il
più facilmente utilizzabili anche dal personale meno esperto. L’obiettivo è quindi
quello di creare prodotti e servizi di elevata qualità tecnologica che aiutino gli staff
tecnici nel loro lavoro.
1.1 L’azienda
SICS S.r.l.è un’azienda specializzata nello sviluppo di applicazioni e servizi per lo
Sport.
Da anni progetta e realizza software con la collaborazione tecnica di alcuni dei
più preparati professionisti nel calcio sia per l’aspetto atletico che tecnico-tattico.
A partire dal 1995 ha lavorato a stretto contatto con le più importanti realtà spor-
tive nazionali e internazionali sviluppando e fornendo servizi e prodotti innovativi
che continuano a soddisfare le esigenze sempre più sofisticate degli staff tecnici e
dei club professionistici.
La Match Analysis, la Pianificazione e il Controllo degli allenamenti, la ricerca
delle soluzioni più semplici e efficienti da proporre ai nostri clienti sono gli obiettivi
primari di questa società. Le soluzioni software sono interamente progettate e
sviluppate in collaborazione con uno staff di sport-scientists che uniscono un altissimo
livello di esperienza e professionalità a una passione smodata per lo sport in genere
e il calcio in particolare.
1.2 L’idea
Il primo incontro con l’azienda è avvenuto durante l’evento STAGE-IT 2014 nel
quale, dopo una breve introduzione all’azienda, sono state esposte proposte di stage.
I progetti offerti sono stati:
12 CAPITOLO 1. INTRODUZIONE
• Timeline eventi: progetto che richiede la creazione di componenti grafiche
da inserire nel software di punta di SICS, ovvero VideoMatch;
• Jasper Report: consiste nella creazione di relazioni delle partite presenti in
VideoMatch tramite l’uso di grafici e diagrammi di rappresentazione dei dati;
• Motion Detection tramite OpenCV: progetto di ricerca che consiste nello
studiare le librerie OpenCV con lo scopo di applicarle al riconoscimento passivo
del movimento dei giocatori e della palla in una partita di calcio o di altri sport
di squadra;
• Editor video avanzato: progetto che consiste nell’integrazione in VideoMatch
di un editor video che permetta all’utente di tagliare, spostare e unire por-
zioni diverse di un video, con lo scopo di creare clip riassuntive delle azioni
importanti di una partita;
• Superschemi Mobile: progetto da sviluppare in ambiente mobile con l’utilizzo
di PhoneGap che consenta all’utente di creare schemi personalizzati per i
giocatori di una squadra di calcio.
I progetti sono stati presentati in ordine di priorità di svolgimento. Infatti, dato
che la nuova stagione calcistica era alle porte, era stata data priorità maggiore
ai progetti che potessero essere completati in tempo per il rilascio della versione
successiva del software VideoMatch.
La scelta del progetto Timeline è stata fatta sia per andare incontro alle necessità
dell’azienda, sia per la chiarezza dei requisiti esposti durante il colloquio. Un
altro progetto interessante riguardava l’utilizzo della libreria OpenCV per effettuare
motion detection sui giocatori durante una partita. Questo progetto di ricerca, per
quanto interessante, era caratterizzato da incertezza sia riguardo alla fattibilità che
ai possibili tempi di realizzazione, perciò era stato scartato.
In un successivo colloquio sono stati definiti maggiormente i requisiti obbligatori
e facoltativi del progetto, le funzionalità principali e sono stati inoltre presentati
i processi e gli strumenti di sviluppo. L’obiettivo del progetto è quello di fornire
all’utente di VideoMatch una nuova modalità di accesso alle informazioni sulle
azioni della partita e che in generale migliori l’esperienza e la facilità di utilizzo del
prodotto.
1.3 Organizzazione del testo
Il secondo capitolo introduce al progetto di stage vero e proprio, definendo i re-
quisiti di partenza, le funzionalità previste dal prodotto e gli strumenti e le
tecnologie atte allo sviluppo finale.
Il terzo capitolo introduce agli strumenti e alle tecnologie utilizzate per la realizza-
zione del progetto.
Il quarto capitolo approfondisce i requisiti individuati durante la fase di analisi dei
requisiti, che sono stati classificati. Vengono inoltre esposti i casi d’uso in cui
l’utente si trova normalmente ad utilizzare il software.1.3. ORGANIZZAZIONE DEL TESTO 3
Il quinto capitolo riguarda la progettazione e la codifica del prodotto finale, quali
design pattern sono stati utilizzati e la struttura delle classi finale.
Il sesto capitolo riguarda la fase di verifica e validazione del software, ovvero il
controllo della qualità del prodotto.
Nel settimo capitolo vengono tratte alcune conclusioni sull’andamento complessi-
vo dell’attività di stage.Capitolo 2
Descrizione dello stage
In questo capitolo viene descritto lo svolgimento dello stage e analizzato il pro-
getto da realizzare. Sono esposti i requisiti del progetto e il piano di lavoro seguito
durante lo stage per portarlo a compimento.
2.1 Introduzione al progetto
L’obiettivo dello stage è di sviluppare una timeline integrata nel software Video-
Match che consenta la visualizzazione di eventi delle partite di calcio o di altri sport
di squadra.
2.2 VideoMatch
VideoMatch è un software per la visualizzazione e l’analisi delle partite in tempo
reale. Le azioni che l’utente può compiere sono sincronizzate con il video della
partita tramite il quale si possono vedere l’azione in corso, i giocatori coinvolti e
tutte le altre caratteristiche dell’evento, come in figura 2.1.
L’utente che utilizza VideoMatch ha l’obiettivo di effettuare un’analisi approfondita
di una partita di calcio, individuando le azioni decisive, gli errori dei singoli giocatori
oppure studiando la disposizione in campo della propria squadra o degli avversari.
Per fare questo ha già alcuni strumenti importanti all’interno del software:
• Un pannello video dove è visibile in riproduzione il video della partita che
l’utente ha scelto dalla propria libreria personale;
• Un campo di gioco dove sono visibili i giocatori nelle rispettive posizioni;
• Una tabella delle azioni che contiene la lista degli eventi di gioco;
• Un pannello contenente i pulsanti per l’inserimento di nuove azioni per la
partita visualizzata.
Un’azione di gioco è un evento di una partita determinato da:
• Un determinato tempo di inizio e un determinato tempo di fine, che servono
per collocarlo nella linea temporale;
56 CAPITOLO 2. DESCRIZIONE DELLO STAGE
figura 2.1: Schermata di analisi di una partita in VideoMatch
• Una lista di giocatori associati all’azione, che hanno partecipato direttamente
o indirettamente a essa;
• Un tipo di evento, che rappresenta una categoria a cui appartiene l’azione (ad
esempio "Azione d’attacco", "Azione di difesa", "Tiro", "Cartellino Giallo" ecc...);
Queste informazioni sono presenti durante l’esecuzione e sono visualizzabili
tramite una tabella, che consente di effettuare filtri, ricerche e selezioni delle azioni
interessanti. In questo modo però l’utente è limitato ad una modalità di utilizzo alla
volta (vedere il video della partita oppure scorrere la lista delle azioni) e non può
tenere traccia facilmente delle azioni in corso mentre osserva il video. Inoltre, il
sistema di filtri della tabella (seppur molto potente in quanto permette di filtrare per
ogni caratteristica dell’azione) è poco intuitivo e poco facile da utilizzare per utenti
meno esperti.
Era richiesta dunque una modalità di visualizzazione nuova delle azioni che
consentisse all’utente di conoscere le azioni in corso semplicemente guardando il
video della partita. La soluzione che è stata pensata è di rappresentare le azioni
lungo una linea temporale per permettere all’utente di conoscere in ogni momento
di gioco le azioni in corso.
Molto spesso, inoltre, è stato richiesto dagli utenti di VideoMatch la possibilità
di selezionare velocemente solo le azioni di uno o più giocatori per analizzarle (ad
esempio l’allenatore in un certo momento può essere interessato solo alle azioni dei
giocatori di difesa).
2.2.1 Configurazione
La configurazione è un impostazione del programma che definisce quali sono
i tipi delle azioni che si devono considerare durante l’esecuzione. Ciò serve a
catalogare le azioni in base alla tipologia d’utente che sta utilizzando il software. La2.3. REQUISITI E OBIETTIVI 7
configurazione di default è "SICS 2015" ed è offerta e implementata dall’azienda.
Altre configurazioni sono possibili, in particolare nel caso l’utente sia un arbitro,
esiste una configurazione che permette di vedere le azioni di gioco che richiedono
l’intervento arbitrale, quali falli, cartelli ecc...
Data l’estensibilità e la possibilità di personalizzazione del programma, è inoltre
possibile per l’utente definire delle configurazioni ad-hoc in base alle esigenze
riscontrate.
2.2.2 Esportazione
Il software VideoMatch presenta una pagina da cui l’utente può esportare i filmati
delle singole azioni, estrapolati dal video della partita. La modalità di utilizzo
dell’esportazione non presenta però all’utente la possibilità di esportare direttamente
i video della partita che sta analizzando dalla sezione di analisi. Ciò aumenta i
tempi di interazione dell’utente con il software nel caso debba scegliere le azioni
manualmente dalla lista presentata nella pagina di esportazione.
Una funzionalità utile che è stata individuata è quella di spostare direttamente
le azioni selezionate dall’utente durante l’analisi nella pagina di esportazione. Da
questa l’utente potrà utilizzare le azioni esportate per la creazione di brevi filmati
video personalizzati.
2.3 Requisiti e obiettivi
L’obiettivo dello stage è la creazione di due componenti distinte ma correlate che
permettano all’utente di visualizzare le azioni di una partita di calcio in modi diversi.
Ciò permetterà all’utente di interagire con VideoMatch nel modo migliore possibile,
eseguendo l’analisi della partita con gli strumenti più adatti alle proprie necessità.
2.3.1 Timeline
Per la prima componente si è pensato a una linea temporale con la lista dei
giocatori che hanno partecipato alla partita e, per ogni giocatore, la serie di azioni a
cui ha preso parte.
Come si può vedere in figura 2.2, tramite la timeline l’utente ha la possibilità di
vedere la lista completa de giocatori che partecipano alla partita. La presenza di uno
slider permette all’utente di spostare il filmato (che è visibile su un altro pannello del
programma) per approfondire una parte di partita a lui interessante.
Lo slider offerto dalla timeline permette inoltre all’utente di scorrere con più
facilità il video della partita, dato che tramite l’utilizzo dello zoom, la porzione
di tempo visualizzata può essere aumentata oppure diminuita a piacimento. Così
l’utente può decidere di focalizzarsi sull’analisi di una sola fase di gioco della partita
e tramite la timeline avrà la possibilità di vedere solo le azioni per quella fase (si noti
che le se la porzione di tempo viene diminuita, la dimensione delle azioni mostrate
sulla timeline sarà maggiore).8 CAPITOLO 2. DESCRIZIONE DELLO STAGE
figura 2.2: Visualizzazione delle azioni di gioco di una partita
2.3.2 Matrice azioni
Una seconda modalità di visualizzazione degli stessi eventi prevista è quella
tramite una matrice con i giocatori e, per ogni giocatore, il numero di azioni a cui ha
partecipato in base al tipo delle azioni. In questo modo l’utente può avere facilmente
la possibilità di vedere statistiche interessanti sulla partita, ad esempio il numero di
tiri effettuati da un particolare giocatore. Da qui, l’utente ha anche la possibilità di
selezionare una qualunque cella della tabella e di vedere in riproduzione le azioni
selezionate (azioni di un particolare tipo per giocatore).
figura 2.3: Matrice che visualizza il numero di azioni per giocatore e per tipo
Le caratteristiche minime del prodotto fornito sono dunque le seguenti:
• Lettura dei giocatori e delle informazioni delle azioni dal database;2.4. ANALISI DEI RISCHI 9
• Rappresentazione grafica delle azioni presenti nel database;
• Funzionalità di zoom che consenta all’utente di vedere nello slider della timeli-
ne solo una porzione di tempo della partita, ma in modo ampliato, così che si
possano distinguere facilmente le azioni presenti;
• Possibilità di esportare una playlist delle azioni selezionate dall’utente;
• Calcolo del numero di eventi per tipo e per giocatore;
• Sincronizzazione della linea temporale con il video in esecuzione tramite la
libreria vlcj;
Un obiettivo primario del progetto è quello di rendere la componente creata il
più facilmente usabile da utenti meno esperti, dato il target degli utilizzatori finali.
Per questo, si è pensato inoltre di inserire qualunque tipo di aiuto all’utente, ad
esempio attraverso l’implementazione di scorciatoie tramite tastiera oppure con la
visualizzazione di tooltip su ogni pulsante disponibile, che consentano di conoscere
le funzionalità offerte.
2.4 Analisi dei rischi
Durante la fase di analisi iniziale sono stati individuati alcuni possibili rischi a cui
si potrà andare incontro. Si è quindi proceduto a elaborare delle possibili soluzioni
per far fronte a tali rischi.
1. Possibilità di riscontrare errori durante l’integrazione del software
Descrizione: Data la poca familiarità con il software VideoMatch, esiste la possibilità
di introdurre errori imprevisti e che vengono riscontrati solo durante l’integrazione
della nuova componente con il prodotto principale.
Soluzione: Si può prevenire il rischio tramite un attento controllo delle interfacce
di comunicazione tra la nuova componente e il software principale.
2. Modifica dei requisiti durante lo sviluppo del progetto
Descrizione: Dato che la componente software da creare presenta caratteristiche
di utilizzo nuove, inizialmente non sarà possibile essere sicuri di quali siano le
interazioni di cui l’utente ha bisogno. Infatti il rischio è di creare una componente
ridondante, che ha funzionalità simili ad altre ma che non viene utilizzata perché
non presenta vantaggi specifici all’utente.
Soluzione: La soluzione possibile è quella di comunicare con gli stakeholder quali
sono le funzionalità specifiche che desiderano dal progetto. Conoscere le interazioni
tipiche dell’utente è fondamentale per creare del software usabile. In particolare,
data la loro grande esperienza nel settore, discutere con il titolare dell’azienda SICS
e con il tutor interno, ha aiutato a minimizzare gli errori possibili durante l’analisi
dei requisiti.10 CAPITOLO 2. DESCRIZIONE DELLO STAGE Inoltre è stata prevista la creazione di prototipi con funzionalità limitate (oppu- re semplicemente per testare il funzionamento dell’interfaccia utente), per avere rapidamente un feedback da parte degli utilizzatori finali del software. 3. Mancato completamento del progetto nei tempi previsti Descrizione: Per qualunque progetto nuovo e per cui lo sviluppatore non ha un’espe- rienza precedente che lo aiuti con il lavoro, è necessario un tempo iniziale dedicato allo studio delle tecnologie utilizzate. A questo si aggiunge il periodo di tempo necessario all’inserimento in un nuovo ambiente lavorativo e ad assumere familiarità con gli strumenti e le procedure utilizzate dall’azienda. Questi tempi non sono prevedibili a priori e ciò mette a rischio la riuscita nei tempi del progetto. Soluzione: In questo caso è importante l’aiuto del tutor interno e dei colleghi di lavoro per rendere il passaggio al nuovo ambiente il più facile possibile. Inoltre è stato previsto nel piano di lavoro un periodo consistente (una settimana) di studio degli strumenti e delle tecnologie da utilizzare.
Capitolo 3
Norme, Strumenti e tecnologie
utilizzate
3.1 Ambiente di lavoro
L’ambiente di lavoro è costituito dall’insieme degli strumenti per la codifica, il test,
la manutenzione e il versionamento del codice prodotto. Molti di questi strumenti si
possono trovare all’interno di un’IDE(Integrated Development Environment), che può
essere utilizzato come editor di testo avanzato, compilatore e debugger del codice.
3.1.1 Java
Java è un linguaggio di programmazione nato nel 1995 e orientato agli oggetti,
specificatamente progettato per essere il più possibile indipendente dalla piattaforma
di esecuzione. Questo permette ai programmi scritti in Java di essere eseguiti nello
stesso modo in tutti i sistemi operativi dotati di una JVM (Java Virtual Machine), che
interpreta il codice Java e lo esegue in base alla piattaforma di destinazione.
figura 3.1: Logo del linguaggio java
Java è ad oggi uno dei linguaggi più diffusi data la sua versatilità e la sua natura
open-source. Proprio per questo, Java è stato scelto come il principale linguaggio
di sviluppo sia lato client che lato server di VideoMatch, in particolare per venire
incontro alle esigenze dei clienti (ovvero allenatori e staff tecnici), che soprattutto
negli ultimi anni hanno iniziato ad utilizzare sempre di più prodotto Apple.
1112 CAPITOLO 3. NORME, STRUMENTI E TECNOLOGIE UTILIZZATE
Un altro dei vantaggi di Java rispetto agli altri linguaggi è la presenza di una serie
di librerie standard che forniscono agli sviluppatori gli strumenti per scrivere codice
in modo rapido e sicuro. Tra queste librerie le più importanti e che sono utilizzate in
questo progetto sono:
• JCF - Java Collections framework: un’insieme di classi e interfacce che
permettono il riuso delle strutture dati più comuni nell’ambito informatico,
come liste, insiemi e alberi;
• AWT - Abstract Window Toolkit: fornisce componenti di interfaccia grafica
di basso livello;
• JavaFX: nuova libreria Java introdotta con Java 8 e che permette ai componenti
grafici creati di essere modificati tramite CSS (Cascading Style Sheets).
3.1.2 Swing
Swing è la libreria di riferimento di Java per la creazione di interfacce grafiche
e che viene utilizzata prevalentemente nel software VideoMatch. Uno dei vantaggi
di Swing rispetto alle altre librerie è che permette l’utilizzo di diversi Look & Feel
(come vengono visualizzate le componenti grafiche nei vari sistemi operativi). Ciò
permette alle applicazioni la cui interfaccia grafica è stata scritta in Swing di avere
lo stesso aspetto tra le varie piattaforme oppure di utilizzare l’aspetto classico del
sistema operativo sottostante.
Inoltre Swing utilizza al suo interno prevalentemente il pattern MVC (Model View
Controller) per separare i dati dalle componenti grafiche. In questo modo lo svilup-
patore ha la possibilità di scegliere se implementare un modello di rappresentazione
dei dati oppure di usarne uno di default messo a disposizione dal framework.
3.1.3 SVN
Apache Subversion (abbreviato come SVN) è un sistema di versionamento del
software e di controllo di versione distribuito con la licenza gratuita Apache.
Si differenzia da altri sistemi di versionamento perché le azioni di commit(ovvero
l’atto di inserire una nuova versione di un file) sono effettuate come operazioni
atomiche, ovvero non ci possono essere due azioni di commit che avvengono con-
temporaneamente sullo stesso file. Questo modo di procedere presenta vantaggi e
svantaggi. L’azienda SICS utilizza SVN perché permette di avere un quadro della
storia dei file più semplice e consistente, ed evita la maggioranza dei conflitti se i
programmatori stanno sviluppando su componenti del software separate.
3.1.4 Netbeans
Netbeans è uno IDE (Integrated Development Environment) per lo sviluppo di
software pensato primariamente per Java e i linguaggi che fanno uso della JVM, ma
può essere usato per lo sviluppo in qualunque altro linguaggio.
Lo strumento presenta caratteristiche interessanti, in particolare per quanto
riguarda la fase di debugging di un’applicazione. C’è infatti la possibilità di effettuare3.1. AMBIENTE DI LAVORO 13
figura 3.2: Logo dell’IDE Netbeans
modifiche al codice durante il debug di un software in esecuzione, che portano ad
una ricompilazione del codice oggetto per le classi modificate. Ciò permette la facile
risoluzione di bug minori.
Un altro aspetto caratteristico di Netbeans è la presenza di una suite per la
creazione di interfacce grafiche in Java. Questa è supportata dalla possibilità di
prendere degli snapshot dell’interfaccia di un’applicazione in esecuzione per vedere
le caratteristiche delle varie componenti grafiche, come layout, posizionamento,
dimensioni ecc. . .
Queste caratteristiche sono solo alcuni degli aspetti che rendono Netbeans uno
dei migliori IDE per lo sviluppo in Java disponibili al momento, ed è stato utilizzato
per tutta la durata del progetto. L’utilizzo di un IDE ha aiutato a migliorare in
generale la qualità del lavoro svolto, velocizzando di conseguenza tutto il processo
di sviluppo.
3.1.5 GUI Builder
Si tratta di uno strumento interno all’IDE Netbeans per la creazione di componenti
di interfaccia graficamente. Si possono creare le finestre e i pannelli base di cui è
costituito il software in modo facile e intuitivo. Altrettanto facile è la generazione del
layout da assegnare a ciascun pannello, senza dover scrivere il codice manualmente.
Infatti il codice generato, nel caso di Java e in particolare per la libreria Swing,
è molto spesso ridondante e poco leggibile. Tramite questo strumento è possibile
lasciare la generazione del codice al software sottostante ed è più facile concentrarsi
sulla struttura dell’interfaccia grafica voluta.
Un altro vantaggio dell’utilizzo del GUI Builder integrato in Netbeans è la possi-
bilità di effettuare l’attività di refactoring del codice in modo automatico. Inoltre
viene offerta la possibilità di inserire velocemente delle componenti standard della
libreria (slider, pulsanti, tabelle ecc...) tramite interfaccia grafica e di assegnare dei
comportamenti aggiuntivi in risposta agli eventi generati dall’interazione utente,
quali la pressione di un tasto oppure il movimento del mouse.
3.1.6 Tortoise SVN
Tortoise è un client gratuito e open source per l’utilizzo di vari sistemi di versiona-
mento, tra i quali Subversion. Fornisce un’interfaccia grafica semplice ed efficace
per effettuare tutte le operazioni di versionamento più comuni, tra le quali quelle di
commit e update. Inoltre presenta la possibilità di risolvere efficacemente conflitti
nei file locali tramite uno strumento di conflict solver interno.14 CAPITOLO 3. NORME, STRUMENTI E TECNOLOGIE UTILIZZATE
figura 3.3: Logo di Tortoise SVN
3.2 Norme di Codifica
Le norme di codifica sono state indicate dal responsabile del progetto e sono
seguite in tutti i progetti realizzati all’interno dell’azienda. Per quanto riguarda il
codice le norme principali che sono state seguite sono:
• il nome di metodi e variabili deve iniziare con la lettera minuscola e se composti
da più parole consecutive, le stesse devono iniziare con la lettera maiuscola
(modalità CamelCase);
• le variabili devono essere inizializzate al momento della loro dichiarazione;
• il nome delle classi deve iniziare con la lettera maiuscola e seguire il metodo
CamelCase per i nomi formati da più di una parola, mentre i nomi dei package
devono iniziare con la lettera minuscola;
• i nomi delle variabili e delle classi devono essere in lingua inglese;
• le variabili di iterazione devono avere scopo locale;
• i commenti relativi al codice devono avere la seguente struttura:
– i commenti per i campi dati devono essere posti nella riga precedente il
campo dato stesso e lasciare sotto quest’ultimo una riga vuota;
– commenti per i metodi devono essere posti nella riga precedente il metodo
stesso e contenere i commenti per i parametri di ingresso e quelli di
ritorno;
– i commenti TODO vanno adoperati come promemoria nel codice per
indicare attività da svolgere o prestare attenzione ad un determinato
punto.Capitolo 4
Analisi dei requisiti
Prima di effettuare lo sviluppo software, è stata svolta un’attività di analisi
dei requisiti, volta a individuare e classificare funzionalità e caratteristiche del
prodotto finale. Ciò è stato fatto a partire dal piano di lavoro iniziale e con la
partecipazione degli stakeholder (in questo caso l’azienda), per avere un quadro
completo e delineato del lavoro da svolgere.
4.1 Casi d’uso
I diagrammi dei casi d’uso dello standard UML sono stati utilizzati per effettuare
l’analisi. Si tratta di diagrammi che rappresentano gli scenari tipici nei quali l’utente
interagisce con il software. Attraverso i diagrammi è possibile individuare per ogni
scenario le funzionalità disponibili all’utente, con condizioni di ingresso e uscita e il
flusso di azioni con cui vengono eseguite.
Infine, sono stati individuati i requisiti (ovvero le caratteristiche che il prodotto
finale deve avere) e che saranno tracciati attraverso le altre attività per garantire il
loro soddisfacimento finale.
UC0: Scenario principale
Attori Principali: Utente
Precondizioni: L’utente ha avviato VideoMatch e ha aperto una partita da analizzare
Descrizione: Viene mostrata una timeline che consente all’utente di visualizzare gli
eventi della partita in corso raggruppati per giocatore
Postcondizioni: Il sistema è pronto l’interazione con l’utente
UC1: Visualizzazione della timeline delle azioni per giocatore
Attori Principali: Utente
Precondizioni: L’utente ha avviato una partita e ha aperto la timeline di visualizza-
zione delle azioni dei giocatori
Descrizione: Viene visualizzata una linea del tempo che mostra il tempo della
1516 CAPITOLO 4. ANALISI DEI REQUISITI
figura 4.1: Use Case - UC0: Scenario principale
partita. Per ogni giocatore l’utente può vedere le azioni nella posizione corretta
lungo la linea del tempo. L’utente può:
• Scegliere un’azione e vederla visualizzata a video;
• Vedere le informazioni di un’azione voluta;
• Selezionare una o più azioni (UC 1.3);
• Modificare la visualizzazione della timeline tramite i controlli (ad esempio per
aumentare lo zoom o modificare la posizione temporale, si veda UC1.4);
• Esportare le azioni selezionate ne pannello di esportazione dell’applicazione;
• Riprodurre come playlist le azioni selezionate: le azioni vengono riprodotte in
ordine sequenziale nella schermata video;
Postcondizioni: L’utente ha eseguito le operazioni volute
UC1.1: Visualizzazione video azione
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando le azioni di una partita
Descrizione: L’utente sceglie un’azione tra quelle presenti lungo la linea del tempo
e può visualizzare il video dell’azione. Se il video era in riproduzione, viene sincro-
nizzato con la posizione d’inizio dell’azione selezionate, altrimenti viene avviata la
riproduzione da quel punto.4.1. CASI D’USO 17 figura 4.2: Use Case - UC1: Visualizzazione della timeline delle azioni per giocatore Postcondizioni: Viene avviata la riproduzione, da parte del video player integrato, dell’azione scelta dall’utente UC1.2: Visualizza informazione azioni Attori Principali: Utente Precondizioni: L’utente sta visualizzando le azioni di una partita Descrizione: L’utente sceglie un’azione e può vederne le informazioni relative: • I giocatori che hanno partecipato all’azione; • Il tipo dell’azione; • Il minuto di inizio e quello di fine dell’azione; Postcondizioni: L’utente ha visualizzato le informazioni volute UC1.2.1: Visualizza giocatori coinvolti
18 CAPITOLO 4. ANALISI DEI REQUISITI
figura 4.3: Use Case - UC1.2: Visualizza informazione azioni
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando un’azione della partita
Descrizione: L’utente può conoscere quali sono i giocatori coinvolti nell’azione
desiderata
UC1.2.2: Visualizza tipo dell’azione
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando un’azione della partita
Descrizione: L’utente può conoscere il tipo dell’azione considerata. Questo può
essere composto anche da una combinazione di tipi basilari. Le azioni vengono
classificate in base ai tipi della configurazione attualmente in uso.
UC1.2.3: Visualizza del tempo di inizio e di fine di un’azione
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando un’azione della partita
Descrizione: Il tempo di inizio e di fine di un’azione vengono mostrati all’utente.
Questi vengono visualizzati nel seguente modo: {T}{M}{S}, dove:
T= : il tempo di gioco in cui è avvenuta l’azione (primo tempo, secondo tempo,
supplementari ecc...);
M= : il minuto di gioco riferito all’inizio del tempo in cui è avvenuta l’azione;
S= : il secondo di inizio/fine dell’azione.4.1. CASI D’USO 19
UC1.3: Selezione delle azioni
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando le azioni di una partita
Descrizione: L’utente può selezionare una o più azioni per poterne vedere le infor-
mazioni, riprodurle in sequenza o esportarle come clip video. La selezione avviene
tramite click del mouse, mentre la selezione multipla è attivata tramite un pulsan-
te dedicato all’attivazione di tale funzionalità oppure tramite il tasto del sistema
operativo dedito alla selezione multipla. Inoltre, una volta effettuata una selezione,
l’utente può decidere di deselezionare le azioni correnti.
Postcondizioni: Le azioni scelte dall’utente sono state selezionate/deselezionate
figura 4.4: Use Case - UC1.3: Selezione delle azioni
UC1.3.1: Selezione singola di un’azione
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando la timeline delle azioni
Descrizione: L’utente può selezionare un’azione tra quelle disponibili nel periodo di
tempo visualizzato dalla timeline
UC1.3.2: Visualizzazione video dell’azione selezionata
Attori Principali: Utente20 CAPITOLO 4. ANALISI DEI REQUISITI
Precondizioni: L’utente ha precedentemente selezionato un’azione tra quelle dispo-
nibili.
Descrizione: L’utente visualizza il filmato dell’azione che ha selezionato.
UC1.3.3: Selezione multipla delle azioni
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando la timeline delle azioni.
Descrizione: L’utente attivare la modalità di selezione multipla delle azioni e iniziare
a selezionarle.
Postcondizioni: Le azioni scelte dall’utente vengono selezionate.
UC1.3.4: Selezione di tutte le azioni di un giocatore
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando la timeline delle azioni
Descrizione: L’utente sceglie uno o più giocatori presenti e può selezionare tutte le
azioni di tali giocatori. Solo le azioni in cui compaiono i giocatori scelti dall’utente
saranno visibili.
Postcondizioni: Vengono visualizzate tutte e sole le azioni dei giocatori scelti
dall’utente
UC1.3.5: Deselezione di tutte le azioni
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando la timeline delle azioni e ha precedente-
mente selezionato una o più azioni.
Descrizione: L’utente può scegliere di deselezionare contemporaneamente tutte le
azioni precedentemente selezionate. in questo modo anche la selezione avvenuta
tramite la scelta di uno o più giocatori viene annullata e ripristinata alla visualizza-
zione completa della timeline con tutte le azioni.
Postcondizioni: Vengono deselezionate e visualizzate tutte le azioni lungo la
timeline.
UC1.4: Controllo della timeline
Attori Principali: Utente
Precondizioni: L’utente sta visualizzando le azioni di una partita
Descrizione: L’utente può scegliere di modificare la visualizzazione della timeline.
È possibile:
• Effettuare lo zoom in avanti e indietro della timeline. In questo modo l’inter-
vallo di tempo visualizzato si espande oppure diminuisce, di conseguenza le
azioni presenti nella linea del tempo saranno visivamente più o meno grandi.4.1. CASI D’USO 21
• Spostare il cursore del tempo della timeline ad una posizione prefissata. Il
video si sposterà sulla posizione indicata continuando la riproduzione da quel
punto.
• Nel caso in cui sia stato effettuato lo zoom, l’utente può spostare l’intervallo
di tempo visualizzato in avanti oppure indietro, mostrando le azioni che sono
avvenute successivamente oppure precedentemente alla posizione attuale della
riproduzione video.
Postcondizioni: La visualizzazione della timeline è stata modificata in base all’azio-
ne dell’utente
figura 4.5: Use Case - UC1.4: Controllo della timeline
UC1.4.1: Modifica dello zoom della timeline
Attori Principali: Utente
Precondizioni: L’utente vuole modificare la visualizzazione della timeline
Descrizione: L’utente può modificare lo zoom
Postcondizioni: Lo zoom è stato modificato per aumentare il dettaglio o diminuirlo
UC1.4.2: Spostamento del video alla posizione indicata22 CAPITOLO 4. ANALISI DEI REQUISITI Attori Principali: Utente Precondizioni: L’utente vuole modificare la visualizzazione della timeline. Descrizione: L’utente vuole spostare in avanti o indietro la riproduzione del video della partita. In questo caso la timeline rappresenterà la porzione di tempo conte- nente quella che si sta riproducendo, mantenendo il livello di zoom precedente. Postcondizioni: Il video ora riproduce dalla posizione indicata. UC1.4.3: Spostamento in avanti/indietro del lasso di tempo visualizzato Attori Principali: Utente Precondizioni: L’utente vuole modificare la visualizzazione della timeline, e sta visualizzando solo una parte del tempo totale di gioco. Descrizione: L’utente sposta in avanti oppure indietro la timeline in modo da vedere la porzione di tempo successiva o precedente. Postcondizioni: La visualizzazione della timeline è stata modificata. UC1.5: Esportazione delle azioni selezionate Attori Principali: Utente Precondizioni: L’utente sta visualizzando le azioni di una partita Descrizione: L’utente ha selezionato degli eventi e può esportarli come dei filmati video. Questo significa che le azioni che sono state selezionate saranno disponibili nella tabella di esportazione del software VideoMatch. Se non sono state selezionate azioni precedentemente da parte dell’utente, nessuna azione sarà esportata. Postcondizioni: All’utente viene visualizzata la tabella di esportazione dei filmati video, contenente le azioni precedentemente selezionate. UC1.5: Riproduzione della playlist delle azioni selezionate Attori Principali: Utente Precondizioni: L’utente sta visualizzando le azioni di una partita Descrizione: Le azioni selezionate dall’utente vengono filtrate nella tabella delle azioni e viene lanciata la riproduzione sequenziale delle azioni. Postcondizioni: Il player video integrato ha riprodotto le azioni selezionate dall’u- tente. UC2: Visualizzazione del numero di azioni per tipo Attori Principali: Utente Precondizioni: L’utente ha avviato VideoMatch e ha aperto una partita da analizzare. Descrizione: L’utente decide di aprire la visualizzazione della tabella contenente il
4.1. CASI D’USO 23
numero di azioni ordinate per giocatore e per tipo. Le azioni sono legate al video
della partita in corso e possono essere visualizzate come una playlist di azioni oppure
esportate come clip video.
figura 4.6: Use Case - UC2: Visualizzazione del numero di azioni per tipo
UC2.1: Selezione delle azioni di un giocatore per tipo
Attori Principali: Utente
Precondizioni: L’utente aperto la visualizzazione della tabella delle azioni ordinate
per tipo.
Descrizione: L’utente può scegliere delle azioni dalla tabella, ad esempio tutti i tiri
di un giocatore oppure tutte le parate del portiere.
Postcondizioni: Le azioni scelte dall’utente sono state selezionate.
UC2.2: Esportazione delle azioni selezionate
Attori Principali: Utente
Precondizioni: L’utente aperto la visualizzazione della tabella delle azioni ordinate
per tipo. Inoltre, dalla tabella sono state selezionate una o più azioni.
Descrizione: L’utente vuole esportare come filmati le azioni che ha precedentemente
selezionato. All’utente viene mostrata la schermata di VideoMatch che permette
l’esportazione dei filmati con inserite le azioni selezionate della tabella.
Postcondizioni: L’utente può procedere con l’esportazione delle azioni come clip
video.24 CAPITOLO 4. ANALISI DEI REQUISITI UC2.3: Visualizzazione della playlist delle azioni selezionate Attori Principali: Utente Precondizioni: L’utente aperto la visualizzazione della tabella delle azioni ordinate per tipo. Inoltre, dalla tabella sono state selezionate una o più azioni. Descrizione: La selezione effettuata dall’utente può essere visualizzata nel player video integrato in VideoMatch come una playlist di azioni. Postcondizioni: L‘utente ha visualizzato i video delle azioni selezionate in sequenza. 4.2 Tracciamento dei requisiti A partire dall’analisi degli scenari dei casi d’uso, sono stati individuati i requisiti del sistema, che sono stati denominati tramite un codice identificativo. Il codice dei requisiti è così strutturato R(F/Q/V)(O/D/F) dove: R = requisito F = funzionale Q = qualitativo V = di vincolo O = obbligatorio D = desiderabile F = facoltativo Nelle tabelle che seguono sono riassunti i requisiti e il loro tracciamento con gli use case delineati in fase di analisi.
4.2. TRACCIAMENTO DEI REQUISITI 25
4.2.1 Tabella di tracciamento dei requisiti Funzionali
tabella 4.1: Tabella di tracciamento dei requisiti Funzionali
Requisito Descrizione Use Case
Il software deve permettere la visua-
RFO-1 lizzazione delle azioni di una partita UC1
su un’asse temporale
L’utente deve poter visualizzare il
RFO-1.2 video di un’azione presente nella UC1.3.2
timeline
Delle azioni si possono visualizzare
RFO-2 UC 1.2
le informazioni relative
Deve essere possibile vedere i gio-
RFO-2.1 catori coinvolti in un’azione, il tipo UC1.2
dell’azione e i tempi di inizio e fine
Deve essere fornita la possibilità di
RFO-3 UC1.3
selezione multipla delle azioni
La selezione multipla deve poter es-
RFO-3.1 sere attivabile tramite scorciatoie UC 1.3.3
tastiera
Per il sistema operativo Windows, la
scorciatoia tastiera per la selezione
RFO-3.1.1 UC1.3.3
multipla è attivata tramite il tasto
Ctrl
Per il sistema operativo OSX, la
scorciatoia tastiera per la selezione
RFO-3.1.2 UC1.3.3
multipla è attivata tramite il tasto
Cmd
La selezione multipla delle azioni
deve filtrare le azioni nella tabella
RFO-3.2 UC1
relativa per mostrare solo le azioni
attualmente selezionate
L’utente può selezionare contempo-
RFO-4 raneamente tutte le azioni di un UC1.3.4
giocatore
La selezione di uno o più giocato-
RFO-4.1 ri, rende visibili solo le azioni in cui UC 1.3.4.1
hanno partecipato tali giocatori
L’utente deve poter modificare il
RFO-5 UC1.4.1
livello di zoom della timeline
La modifica dello zoom mantiene
RDO-5.1 la posizione del cursore del tempo UC1.4.1
nella stessa posizione26 CAPITOLO 4. ANALISI DEI REQUISITI
Deve essere possibile effettuare
RFO-5.2 lo zoom tramite gli eventi della UC1.4.1
rotellina del mouse
La modifica dello zoom cambia la
dimensione relativa delle azioni rap-
RFO-5.3 presentate lungo la timeline, in mo- UC1.4.1
do che siano proporzionali rispetto
al lasso di tempo rappresentato
L’utente può visualizzare il periodo
di tempo precedente o successivo
RFO-6 UC1.4.3
a quello attualmente rappresentato
nella timeline
L’utente può esportare le azioni
RFO-7 UC1.5
selezionate come filmati video
L’utente può visualizzare la play-
list delle azioni selezionate nel-
RFO-8 UC1.6
la schermata video del software
VideoMatch
L’utente deve poter visualizzare una
tabella contenente per ogni giocato-
RFO-8 re e per ogni tipo di azione, il nume- UC2
ro di azioni a cui tale giocatore ha
partecipato
Il tipo delle azioni rappresentate
deve essere quello della configura-
RFO-9 UC2
zione attuale caricata nel software
VideoMatch
La tabella delle azioni deve suppor-
tare le configurazioni:
• SICS 2014;
RFO-9.1 UC2
• SICS 2015;
• AIA;
La tabella delle azioni deve esse-
RFO-9.2 re compatibile con configurazione UC2
create dall’utente
L’utente deve aver la possibilità di se-
lezionare contemporaneamente tut-
RFO-10 UC2.1
te le azioni di un certo tipo per un
dato giocatore
L’utente deve avere la possibilità di
RDO-11 selezionare più celle della tabella di UC2.1
rappresentazione delle azioni4.2. TRACCIAMENTO DEI REQUISITI 27
Le azioni selezionate devono po-
RFO-12 ter essere visibili nella tabella delle UC2.1
azioni
L’utente può visualizzare nella scher-
RFO-13 mata video la playlist delle azioni UC2.3
che ha selezionato
L’utente ha la possibilità di esportare
RFO-14 UC2.2
le azioni selezionate
Una volta selezionata l’esportazione,
all’utente viene mostrata la scher-
RFO-14.1 UC 2.2
mata con le clip video che può
esportare
4.2.2 Tabella di tracciamento dei requisiti di Vincolo
tabella 4.2: Tabella di tracciamento dei requisiti di Vincolo
Requisito Descrizione Use Case
Il software deve essere integrato in
RVO-1 -
VideoMatch
Il software deve poter essere ese-
RVO-2 guito sia su ambiente Mac che su -
ambiente Windows
Devono essere utilizzati i controlli
RVO-2.1 standard del sistema operativo per -
le scorciatoie tramite tastiera
Tutte le parti testuali all’interno del
software devono essere codificate in
RVO-3 modo da permettere facilmente il -
cambio della lingua del programma
in esecuzione
Il testo usato all’interno del soft-
RVO-3.1 ware deve essere fornito sia in lingua -
italiana che in lingua ingleseCapitolo 5
Progettazione e codifica
5.1 Ambiente software
Data la natura del progetto e le sue caratteristiche, si è fatto ampio uso delle
librerie Swing disponibili. Prima di passare alla descrizione del progetto è quindi
indispensabile un’introduzione all’ambiente di sviluppo in cui il progetto è stato
realizzato e ad alcune caratteristiche del linguaggio Java.
5.1.1 Thread
I Thread sono flussi di esecuzione del programma che vengono eseguiti in parallelo
rispetto al Thread principale. Il parallelismo è in questo caso solo logico, perché
l’esecuzione delle varie operazioni viene poi organizzata dal sistema operativo in
base al numero di processori fisici disponibile.
La libreria Swing utilizza un thread proprio per l’esecuzione delle operazioni che
riguardano la visualizzazione delle componenti di interfaccia e per la gestione degli
eventi.
Nel progetto i thread sono stati principalmente utilizzati per effettuare operazioni
che avevano bisogno di essere ripetute a intervalli di tempo costanti. Un altro
ambiente di utilizzo è per la sincronizzazione delle componenti create con il video in
esecuzione in VideoMatch, che viene eseguito in un thread separato.
5.1.2 Eventi
In Java gli eventi sono oggetti che rappresentano azioni effettuate dall’utente
tramite le periferiche di input. Java si preoccupa di interpretare l’evento del sistema
operativo e permette allo sviluppatore di programmare la risposta a certi eventi.
In particolare le componenti di Swing che derivano da JComponent possono essere
abilitati ad ascoltare i seguenti eventi tramite la creazione di oggetti Listeners che
implementano i metodi che devono essere invocati alla ricezione del proprio evento.
Tra questi i più usati nel progetto sono:
• MouseListener: risponde agli eventi creati dal click, dalla pressione e dal
rilascio del mouse;
2930 CAPITOLO 5. PROGETTAZIONE E CODIFICA
• MouseWheelListener: ascolta gli eventi creati dalla rotazione della rotellina
del mouse all’interno della componente;
• KeyListener: ascolta la pressione dei tasti della tastiera, alla pressione e al
rilascio degli stessi e permette di identificare i tasti premuti;
• ComponentListener: risponde alle modifiche apportate alla visualizzazione
della componente sullo schermo, come la modifica della posizione o delle
dimensioni;
• FocusListener: il focus è una proprietà che permette ad una componente
di rispondere agli eventi della tastiera. Tramite questo Listener è possibile
conoscere quando una componente ha ottenuto o lasciato il focus della tastiera.
Gli eventi che riguardano le componenti di interfaccia grafica e in particolare
di Swing, vengono gestiti dalla JVM tramite un unico thread chiamato EDT (Event
Dispatch Thread). In questo modo si evitano problemi di sincronizzazione perché la
risoluzione degli eventi (ovvero la chiamata degli oggetti registrati ad un particolare
evento) viene effettuata in modo sequenziale. Tuttavia questa soluzione impedisce a
thread esterni di poter effettuare modifiche dirette all’interfaccia grafica, che vanno
dunque evitate.
5.1.3 VideoMatch
VideoMatch è un software esteso che contiene diversi package che sono stati
utilizzati durante il progetto. Le componenti grafiche sono contenute nel package
design dove sono state inserite le nuove componenti create durante il progetto. Tale
package contiene i moduli dedicati all’interfaccia grafica come i pannelli principali
che visualizza l’utente. Le altre componenti utilizzate durante il progetto sono:
• domain: contiene i tipi di dato principale che vengono utilizzati dal software
VideoMatch, ad esempio i tipi:
– Action: un’azione di gioco, rappresentata da tempi di inizio e fine, i
giocatori coinvolti, il tipo di azione;
– Player: rappresenta un giocatore, con tutte le informazioni relative come
nome, squadra e numero di maglia;
– MatchData: rappresenta i dati di una partita di calcio. Qui si possono
ricavare le informazioni relative all’inizio e alla fine dei tempi di gio-
co (primo tempo, secondo tempo e tempi supplementari), i nomi delle
squadre in campo, il risultato finale ecc...
• helper: package che contiene alcune componenti di utilità generale, ad esem-
pio per la gestione degli errori o per reperire informazioni sulle impostazioni
attuali;
• thread: package che contiene alcuni thread di supporto all’applicazione che
sono eseguiti in background;5.2. ARCHITETTURA 31
• video: package contenente i moduli di gestione dei player video integrati in
VideoMatch. Tramite questo package è possibile interfacciarsi con la libreria
vlcj che contiene le componenti adatte alla visualizzazione e alla riproduzione
di file video.
5.2 Architettura
La progettazione del software ha avuto inizio a seguito dell’analisi dei requisiti. Si
è iniziato a partire dall’architettura generale. Il pattern scelto per gestire contempora-
neamente le componenti create e fornire all’esterno un’unica interfaccia di accesso è
il pattern Façade, in cui un’unica classe permette di rappresentare la complessità del
sistema sottostante. In questo modo è stato possibile ridurre il numero di interventi
nelle altre parti dell’applicazione per effettuare l’integrazione del software.
figura 5.1: Architettura generale, vista package
VideoMatch::design::timeline
Il package timeline è quello generale del software sviluppato. Dato che la compo-
nente da creare era una componente nuova e indipendente, è stato scelto di inserirla
in un nuovo package con l’intento di diminuire l’accoppiamento tra questa e le altre
componenti della view. Il package timeline è stato inserito nel package design di
VideoMatch per la sua correlazione con le altre componenti di interfaccia presenti
nel software.Puoi anche leggere
