Progetto: Web Crawler File

Indice
1 Introduzione
1.1 Scopo RD . . . . . . . . . . . . . .
1.2 Scopo progetto . . . . . . . . . . .
1.3 Definizioni, acronimi, abbreviazioni
1.4 References . . . . . . . . . . . . . .
1.5 Overview . . . . . . . . . . . . . .
2 Descrizione generale
2.1 Visione del prodotto . . . .
2.2 Dati e funzioni del software
2.3 Caratteristiche degli utenti e
2.4 Assunzioni e dipendenze . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
scenari di utilizzo
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
. 5
. 7
. 10
. 11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Requisiti specifici
3.1 Requisiti interfaccia esterna . . . . . .
3.2 Requisiti funzionali . . . . . . . . . . .
3.2.1 Funzionalità . . . . . . . . . . .
3.2.2 Sottofunzionalità . . . . . . . .
3.3 Requisiti non funzionali . . . . . . . .
3.3.1 Requisiti di aggiornamento . . .
3.3.2 Requisiti di performance . . . .
3.3.3 Attributi di qualità del software
3.3.4 Altri requisiti . . . . . . . . . .
3.4 Diagrammi del sistema . . . . . . . . .
3.4.1 Diagramma di sequenza . . . .
3.4.2 Diagrammi di stato . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
20
22
22
23
23
24
25
25
26
1
1.1
Introduzione
Scopo RD
Scopo del documento - Lo scopo del seguente documento è la definizione
dei requisiti del progetto scelto.
Fonte delle informazioni - Nella fattispecie il nostro intento è realizzare un
crawler per il sito www.mymovies.it (in seguito anche “il sito” o “MyMovies”),
archivio contenente informazioni relative a tutti i film realizzati dal 1895 ad
oggi; questo progetto realizza il primo componente di un ipotetico e futuro
motore di ricerca (in seguito anche SE) sviluppato da terzi ed è demandato al
reperimento di tutti i dati necessari al SE per eseguire i propri task. L’idea
quindi è quella di realizzare un sistema che verrà poi distribuito gratuitamente
su internet in modo che possa essere utilizzato da chiunque lo necessiti.
Obiettivo del documento - In tale documento verranno illustrate le features
che il crawler (in seguito anche Neptune) dovrà avere e tutto quanto è utile
al fine d’avere una visione d’insieme del prodotto che si intende realizzare.
1.2
Scopo progetto
Scopo del sistema - Lo scopo di Neptune è quello di esplorare MyMovies
ricercando, estraendo ed organizzando tutte le informazioni di interesse relative
ad ogni film del sito. A fronte di questo, Neptune preleverà dal sito i dati
accessibili e reputati informativi per tutte le categorie d’utenza ipotizzabili
e ne manterrà un grado accettabile di aggiornamento. I dati raccolti da
Neptune dovranno teoricamente poter soddisfare le esigenze informative di
ogni categoria possibile di utenti, dagli appassionati cinefili alle persone comuni
che ricercano un film da guardare. Nel prosieguo del documento, precisamente
nella Sezione 2.2 - Dati e funzioni del software, si specificherà quali dati si
intende scaricare e il motivo per cui sono stati reputati rilevanti.
Target del sistema - Le operazioni di Neptune sono fatte nell’ottica di
creare e tenere aggiornato un datastore per un eventuale e futuro SE, in modo
che questo possa reperire con maggiore semplicità le informazioni desiderate.
Modalità di lavoro - La ricerca delle pagine contenenti informazioni sui
film è progettata per essere effettuata sia in modo automatico sfruttando
informazioni sul dominio, sia in funzione delle esigenze dello sviluppatore del
SE, che può scegliere manualmente dei criteri di aggiornamento, migliorando
l’efficienza del reperimento delle informazioni.
3
1.3
Definizioni, acronimi, abbreviazioni
Nel presente documento saranno utilizzate le seguenti espressioni:
• Archivio - si riferisce al sito www.mymovies.it, la fonte di informazioni
per il crawler.
• Buffer - una qualsiasi struttura di memoria temporanea, nel nostro
progetto è utilizzata per l’interscambio delle informazioni.
• Crawler - componente dei motori di ricerca che si occupa di reperire
i contenuti da un database. É il componente che verrà realizzato da
questo progetto col nome di Neptune (vedi definizione “Neptune”)
• Datastore - una qualsiasi struttura di memoria stabile, nel nostro
progetto è utilizzata per il salvataggio delle informazioni.
• MyMovies - vedi “Archivio”.
• Neptune - il nome del sistema che si intende progettare. Questo sarà
suddiviso in due blocchi funzionali: uno si occuperà del crawling vero
e proprio, in termini di reperimento delle URL da cui scaricare i dati,
l’altro si occuperà dello scaricamento delle informazioni da tale URL e
del salvataggio di queste in un’idonea struttura dati.
• NeptuneCrawler - il modulo di Neptune che si occuperà del reperimento delle URL.
• Parser - il modulo di Neptune che si occuperà dello scaricamento, del
salvataggio e dell’organizzazione delle informazioni.
• RD - Requirements Document. Si riferisce al presente documento.
• SE - Search Engine. L’ipotetico e futuro motore di ricerca a cui il lavoro
di recupero delle informazioni di Neptune è finalizzato.
• Sito - vedi “Archivio”.
1.4
References
Informazioni sulla fonte - La fonte d’informazione a cui accederà il nostro
crawler è il sito www.mymovies.it. Quest’ultimo, costantemente aggiornato,
è un grosso database online di opere cinematografiche contenente, per ogni
film prodotto dal 1895 fino ad oggi, informazioni quali Titolo, Regista, Attori,
Genere, Pubblico Target, Durata, Data di Uscita, Valutazione, Trama e
4
Trailer. Dal 2008, anno di apertura, fino ad oggi sono state visualizzate circa
35 milioni di pagine con 4 milioni di visitatori unici al mese il che rende
MyMovies il più consultato database italiano di cinema.
1.5
Overview
Contenuto del documento - Nel presente documento sarà presentato come
si intende organizzare e sviluppare tale progetto, quali saranno gli scenari e il
dominio d’applicazione, requisiti funzionali, requisiti non funzionali (in termini
di frequenza di aggiornamento, sicurezza del sistema...) input ed output di
ogni funzione realizzata, interfaccia e utenti che utilizzeranno l’applicazione.
Organizzazione del documento - Lo standard “IEEE 830-1998”, in base al
quale è organizzato il presente RD, prevede due sezioni relative alla definizione
dei requisiti: la Sezione 2 da una descrizione generale del prodotto, più precisamente nella Sezione 2.1 si ha una visione generale del prodotto, dell’ambito
in cui verrà collocato, delle sue evoluzioni future e verrà data un’anticipazione
della sua architettura. Successivamente nella Sezione 2.2 verrà presentato il
modello di dominio e verranno introdotte le funzioni principali del software,
specificando gli obiettivi funzionali di base. Nella Sezione 2.3 verranno introdotte le caratteristiche degli utenti del nostro sistema e nella Sezione 2.4
sarà introdotto il requisito di indipendenza dalla piattaforma. La Sezione 3
invece specifica più in dettaglio i vari requisiti funzionali e non: la Sezione 3.1
introduce i requisiti dell’interfaccia esterna, la Sezione 3.2 elenca i requisiti
funzionali e le loro sottofunzionalità, la Sezione 3.3 tratta i requisiti non
funzionali, tra i quali i requisiti di aggiornamento, i requisiti di performance,
gli attributi di qualità del software (availability e reliability) e altri requisiti
come manutenibilità, scalabilità e portabilità, la Sezione 3.4 infine riporta
alcuni diagrammi del sistema utili per meglio comprendere il funzionamento
di Neptune.
2
2.1
Descrizione generale
Visione del prodotto
Ambito del progetto - Neptune si colloca nell’ambito del reperimento dal
web di informazioni collegate al dominio cinematografico. Inoltre, in quanto
primo modulo di un SE si colloca in ambito buisness-to-buisness.Il sistema
non ha come obiettivo il miglioramento della ricerca all’interno del database di
MyMovies, ma intende essere uno strumento per il reperimento di informazioni
da destinare ad un ipotetico SE creato da terzi.Tale SE non si interfaccerà
5
Figura 1: Quadro generale del progetto
con il nostro sistema ma soltanto con il datastore. In questo contesto le
informazioni nel datastore verranno memorizzate secondo una formattazione
che permetta al maggior numero di SE di potersi interfacciare col database.
Tale formattazione è specificata nella Sezione 2.2 - Dati e funzioni del software.
Evoluzioni future - Attualmente si intende progettare Netptune in modo
che si interfacci esclusivamente con MyMovies, ma questa è solo una prima
fase dello sviluppo; si intende infatti realizzare uno strumento abbastanza
flessibile da poter essere in futuro adattato per poter accedere anche ad altre
fonti di informazione (IMDB, pagine personali degli attori su Wikipedia,... ).
In questo modo si minimizza la dipendenza da una fonte specifica, si possono
estrarre più dati e si possono eseguire analisi comparative ed aggregazioni
degli stessi in modo da fornire informazioni della massima qualità possibile al
futuro SE.
Ruolo di Neptune nel sistema finale - Neptune costituisce quindi un
componente di un sistema più grande e massiccio il cui obiettivo è di permettere
l’effettuazione di ricerche in ambito cinematografico. Questo sistema di fatto
sarà un SE specializzato ma, come tutti i SE esistenti, sarà strutturato in vari
moduli : il crawler, che recupera le pagine web, il motore di indicizzazione,
che si occupa di indicizzare i documenti raccolti, e un front end, che gestisce le
query degli utenti. Si assume che l’utilizzatore delle informazioni reperite dal
sistema sia tale SE. A fronte di questo possiamo strutturare le informazioni
reperite nel modo più consono per essere utilizzate da un software tralasciando
alcuni aspetti come, ad esempio, la leggibilità dell’output, questioni che
altrimenti sarebbero di focale importanza nel caso di un utilizzatore umano
ed, ipoteticamente, non particolarmente competente in ambito informatico.
Interfaccia con gli altri moduli del SE - Il nostro sistema quindi realizza
la prima componente del motore di ricerca, il crawler, che raccoglierà le
informazioni destinate alle altre componenti del SE. Neptune pertanto si
6
interfaccerà con il motore di indicizzazione fornendogli un datastore da cui
attingere i dati da indicizzare.
Architettura di Neptune - Il diagramma in Figura 1 mostra, ad alto
livello, come si intende interfacciare il nostro progetto con un SE. In tale
diagramma si anticipa che Neptune sarà suddiviso in due moduli, un crawler
(NeptuneCrawler) ed un parser (NeptuneParser). Per quanto questo aspetto,
prettamente architetturale, si dovrebbe affrontare in fase di progettazione e
non durante la stesura del RD, è necessario iniziare ad introdurlo perché è
utile per comprendere in questa fase il funzionamento del sistema e alcuni
requisiti non funzionali, ad esempio quelli legati alle performance. Inoltre tale
suddivisione è la soluzione standard adottata da tutti i sistemi di questo tipo
e non un aspetto innovativo proprio di Neptune. Pertanto, a fronte di questo,
si è deciso già nella presente fase di definizione dei requisiti di mantenere tale
architettura.
Motivazione scelta architettura modulare - É importante notare che il
reperimento delle URL e lo scaricamento/organizzazione delle informazioni
avvengano in due momenti diversi in quanto tali operazioni richiedono un
diverso quantitativo di tempo e di risorse. Per questo motivo prettamente
tecnico è stata mantenuta la suddivisione nelle due componenti canoniche
di questi sistemi: il crawler che si occupa del reperimento delle URL e il
parser, che si occupa dello scaricamento/organizzazione delle informazioni
nelle pagine. Questa suddivisione è necessaria per aumentare la velocità
dell’intero processo di reperimento delle informazioni, dando un contributo al
soddisfacimento del requisito non funzionale legato al grado di aggiornamento
dei dati (si veda Sezione 3.3 - Requisiti non funzionali )
2.2
Dati e funzioni del software
Modello di dominio - Per meglio comprendere le funzioni di Neptune è utile
osservare il modello di dominio in Figura 2. Il modello di dominio del nostro
sistema include tutti i dati reputati rilevanti per i film e le informazioni sul
provider che serviranno al corretto funzionamento di Neptune. Da notare che,
per gli scopi di questo progetto si considera un solo provider, MyMovies, ma
nel caso di sviluppi futuri le informazioni sui film potranno essere prelevate
da più provider.
Obiettivi funzionali di base - Le funzionalità basilari del sistema sono il
reperimento di specifiche URL, il download delle informazioni rilevanti nelle
pagine relative agli URL e la loro conseguente organizzazione in una struttura
dati. Questa sarà realizzata al fine di essere facilmente comprensibile ed
accessibile dal modulo di indicizzazione, appartenente all’ipotetico SE con cui
il nostro sistema dovrà interfacciarsi. Come già anticipato nella Sezione 1.2
7
Figura 2: Modello di dominio
- Scopo del progetto, Neptune preleverà dal sito i dati accessibili e reputati
informativi per tutte le categorie d’utenza ipotizzate per il SE.
Informazioni da prelevare - Sulla base di queste considerazioni sono state
reputate come “interessanti” le seguenti informazioni relative ai film:
• Titolo - si ipotizza che questo dato, oltre a costituire un attributo
fondamentale per ogni film, sia il criterio di ricerca più comunemente
utilizzato dagli utenti.
• Regista - si ipotizza che un determinato utente possa essere appassionato dei film di uno specifico regista (Ex. Tarantino) pertanto possa
voler eseguire ricerche mirate per reperire i suoi film. A fronte di questo
è stato reputato necessario estrarre le informazioni sul regista (o sui
registi) per ogni film.
• Attori - medesimo discorso fatto per il regista ma declinato sugli attori.
Sono classificati come attori sia le persone che recitano in un film sia i
doppiatori di un film.
• Genere - si ipotizza che un utente possa essere amante di uno specifico
genere di film e che pertanto possa voler eseguire ricerche specifiche su
film appartenenti ad esso.
• Pubblico Target - si ipotizza che un utente “padre di famiglia” possa
voler ricercare dei film adatti ad un pubblico infantile per una serata in
famiglia.
8
• Durata - si ipotizza che un utente possa essere interessato solo ai film
con un range particolare di durata.
• Anno di Uscita - si ipotizza che un utente possa essere interessato
solo a film recenti. Inoltre questo attributo è necessario per alcune
funzionalità di Neptune.
• Valutazione - si ipotizza che un utente “appassionato cinefilo” possa
essere interessato a visionare dei film con una precisa valutazione in
modo da poter comparare le sue impressioni a quelle dei critici.
• Trama - generalmente uno degli attributi più consultati per decidere
quale film guardare quando non si ha una precisa idea di quello che
interessa.
Qualora non fossero disponibili tutti i dati citati, il sistema semplicemente
si limiterà ad estrarre quelli disponibili. Nell’ipotesi che un dato sia mancante
(es: la durata di un film non ancora girato ma già presente nell’archivio), il
campo relativo ad esso verrà settato ad un valore di default atto ad indicare
l’assenza del dato stesso.
Data di ultimo aggiornamento film - Si è inoltre pensato di salvare per
ogni film anche la data in cui è avvenuto l’ultimo aggiornamento dei suoi dati
all’interno del datastore. In questo modo si può far si che negli accessi al sito
successivi al primo si possano scaricare solo le informazioni che sono cambiate
dall’ultima volta in cui Neptune lo ha analizzato. Tale scelta è stata fatta con
l’obiettivo di ridurre sia il traffico di rete causato da Neptune sia le risorse
necessarie al processo di crawling.
Per il reperimento dei dati sono state previste due modalità di funzionamento: un crawling di default e un crawling selettivo.
Crawling di default - Il crawling di default aggiorna ciclicamente i dati
scaricati dal sito. Con il crawling di default tutti i dati presenti nell’archivio
verranno scaricati secondo le tempistiche di aggiornamento definite nella
Sezione 3.3.1 - Requisiti di aggiornamento.
Queste policy di aggiornamento verranno definite in modo da permettere
un certo grado di libertà nella scelta delle tempistiche, che potranno anche
essere diverse da quelle automatiche previste nei criteri di aggiornamento.
In fase progettuale si provvederà a strutturare il sistema in modo che
nella sua modalità di default riesca a soddisfare questi requisiti anche su
infrastrutture non all’avanguardia.
Crawling selettivo - è prevista anche una funzione di crawling manuale
che, al contrario di quella automatica non è ciclica ma consiste in un unico
scaricamento di informazioni dal sito. Tale scaricamento sarà selettivo, cosı̀
9
da permettere di aggiornare solo determinate informazioni. Per i dettagli
sui criteri di scelta dei film da aggiornare si veda il Requisito funzionale 2:
Crawling selettivo nella Sezione 3.2 - Requisiti funzionali.
Memorizzazione dei dati - Dato che ad interfacciarsi col nostro datastore
saranno i motori di indicizzazione dei SE, i dati che verranno salvati dovranno
avere un formato da essi riconosciuto. A questo proposito però non sono state
trovate indicazioni riguardanti particolari standard di formattazione, quindi
si è deciso di salvare i dati nel modo più semplice possibile. Verrà salvato solo
il contenuto testuale riguardante i dati, rimuovendo i tag HTML della pagina.
Questa scelta fa si che anche i motori di indicizzazione che non gestiscono i
tag HTML possano interfacciarsi col nostro datastore.
2.3
Caratteristiche degli utenti e scenari di utilizzo
Utenti del sistema - L’utente del nostro sistema sarà uno degli utilizzatori
del SE che sfrutterà Neptune. A fronte di questo si suppone che abbia
conoscenze pregresse in ambito informatico. Si assume che il suo background
sia sufficiente per capire come configurare Neptune a seconda delle proprie
necessità ma, qualora non lo fosse, la lettura del presente documento fornirà
le conoscenze necessarie per configurare e utilizzare il sistema.
Scenari di utilizzo - Per meglio comprendere come l’utente interagisce con
le funzionalità offerte dal sistema, di seguito sono specificati due possibili
scenari di utilizzo. In ambedue gli scenari si suppone che un programmatore abbia preventivamente realizzato un SE che utilizza il sistema Neptune
per il reperimento delle informazioni e che, ovviamente, abbia interfacciato
correttamente tale sistema con il nostro.
SCENARIO 1:
Un tecnico decide di avviare il sistema Neptune nella modalità di default in
modo da recuperare tutte le pagine contenenti informazioni relative ai film e
salvarle in un datastore. Successivamente Neptune aggiornerà automaticamente il datastore, aggiornando la copia di ogni pagina con una frequenza che
dipende dalla data di uscita del film: più il film è recente più frequentemente
verranno aggiornate le informazioni ad esso relative (per maggiori dettagli si
veda la Sezione 3.3.1 - Requisiti di aggiornamento).
SCENARIO 2:
Un tecnico sta utilizzando Neptune nella modalità di default. Quando si
accorge che l’attore Johnny Depp ha vinto l’Oscar, sospende l’esecuzione di
default di Neptune e richiede al sistema di aggiornare subito le informazioni
relative alle pagine riguardanti i film dell’attore Johnny Depp. Questo perché,
dato che l’attore ha vinto l’Oscar, è molto probabile che la maggior parte delle
queries che giungeranno al SE saranno relative ai film dell’attore e il tecnico
10
del SE vuole che i risultati delle queries siano i più aggiornati possibile. Al
termine del crawling selettivo, il tecnico può riattivare il crawling di default.
2.4
Assunzioni e dipendenze
Indipendenza da piattaforma - L’idea alla base del progetto è quella
di creare un sistema, diffuso tramite internet, sfruttabile gratuitamente da
chiunque voglia progettare un SE dedicato all’ambito “cinema”. Come già
detto, Neptune realizzerà solamente il primo componente di tale ipotetico
SE, il crawler. Di conseguenza il sistema sarà ipoteticamente utilizzato da
una terza parte non meglio definita, pertanto a fronte di questo deve essere
indipendente da piattaforma, cioè deve poter funzionare su qualsiasi macchina
a prescindere dalla sua configurazione software/hardware, in modo da lasciare
ai progettisti del SE più spazio d’azione possibile.
Testing dell’indipendenza - Per testare la cosa si provvederà a lanciarne
l’esecuzione su piattaforma Windows, MacOS e Linux. Il funzionamento di
Neptune è ovviamente subordinato, per sua natura, alla disponibilità di un
collegamento ad internet.
Comunicazione fra i moduli - I moduli del sistema saranno fra di loro indipendenti: comunicheranno tramite il buffer secondo un formato prestabilito
di presentazione delle informazioni a loro noto. Inoltre, eventuali modifiche
di un modulo non impatteranno sull’altro, a patto di mantenere inalterato
l’output del NeptuneCrawler sul buffer.
3
3.1
Requisiti specifici
Requisiti interfaccia esterna
Le interfacce previste per il nostro sistema sono due, una testuale ed una
grafica. Ambedue avranno le stesse funzionalità e permetteranno di eseguire le
medesime operazioni presentate successivamente. Nonostante questo, saranno
implementate entrambe in modo che, nel caso in un malfunzionamento della
GUI, sarà sempre possibile interfacciarsi con il sistema tramite riga di comando.
Entrambe le interfacce permetteranno di visualizzare le informazioni in output,
ma la GUI le organizzerà meglio e permetterà di eseguire più semplicemente
delle operazioni di default. In maniera complementare, la riga di comando
rimane più semplice da sviluppare e modificare nell’ipotesi di evoluzioni future
oltre, ovviamente, a lasciare maggiore libertà d’azione all’utente.
Ambedue le interfacce comunque dovranno essere chiare e semplici da
utilizzare.
11
Funzionalità interfacce esterne - A seguire le funzionalità, esposte in
dettaglio, delle interfacce esterne. Queste dovranno permettere di:
• Settare le impostazioni funzionali di Neptune necessarie alla sua corretta
esecuzione :
◦ Numero moduli crawling (NeptuneCrawler).
◦ Numero moduli parsing (NeptuneParser).
◦ Tempistiche personalizzate di aggiornamento.
Nel caso in cui questi parametri non vengano inseriti, il sistema utilizzerà
quelli di default definiti nella Sezione 3.3 - Requisiti non funzionali.
• Permettere di lanciare/fermare il processo di crawling a piacimento.
• Avviare il processo di crawling selettivo impostando i criteri secondo
cui discriminare le pagine da aggiornare (si veda Requisito funzionale 2:
Crawling selettivo nella Sezione 3.2 - Requisiti funzionali.
• Informare un ipotetico osservatore sullo stato del crawling attuale (si veda Requisito funzionale 7: Monitora stato del crawling nella Sezione 3.2
- Requisiti funzionali).
• Informare l’utente riguardo ad eventuali dati statistici (si veda Requisito
funzionale 8: Mostra statistiche nella Sezione 3.2 - Requisiti funzionali).
• Cancellare il contenuto del datastore:
◦ Cancellazione URL invalidi (si veda Requisito funzionale 9: Rimuovi URL non più validi nella Sezione 3.2 - Requisiti funzionali ).
◦ Cancellazione totale del datastore (si veda Requisito funzionale 6:
Svuota datastore nella Sezione 3.2 - Requisiti funzionali ).
3.2
Requisiti funzionali
In Figura 3 viene mostrato il diagramma che rappresenta gli stati del sistema
a cui si può arrivare a fronte di un’azione del tecnico. É da notare che questo
grafico non ha l’obiettivo di specificare i passaggi di stato interni del crawler di
default che invece è Neptune a determinare. Nello specifico questi stati sono:
lo stato in cui sta estraendo le informazioni e lo stato in cui ha terminato
l’estrazione e attende lo scadere del delay prima della prossima esecuzione.
12
Figura 3: Stati del sistema dal punto di vista del tecnico
3.2.1
Funzionalità
Priorità dei requisiti - Le funzionalità offerte da Neptune, che sono accessibili sia tramite linea di comando sia attraverso una semplice interfaccia, sono
specificate qui di seguito. Ogni funzionalità avrà un diverso grado di priorità,
definito secondo il seguente criterio:
priorità ALTA - operazioni indispensabili al funzionamento del sistema.
13
priorità BASSA - operazioni utili al funzionamento del sistema ma non
indispensabili.
REQUISITO FUNZIONALE 1: Crawling di default
DESCRIZIONE: Il sistema avvia il crawling di default con un numero di
processi di crawling e di parsing e una certa tempistica di aggiornamento.
Tali parametri possono essere specificati dal tecnico, in alternativa verranno
usati quelli di default. Successivamente il sistema visita tutto il sito, scarica le
informazioni riguardanti ogni film e le salva nel datastore. Qualora il datastore
fosse vuoto viene riempito. Tale esecuzione verrà ripetuta ciclicamente. Dopo
la prima esecuzione, Neptune aggiorna le informazioni presenti nel datastore
per ogni film in base alle tempistiche di aggiornamento specificate.
INPUT:
- Numero di processi di crawling (facoltativo).
- Numero di processi di parsing (facoltativo).
- Tempistiche di aggiornamento (facoltativo).
PROVENIENZA: I parametri sono immessi dal tecnico da GUI o riga di
comando.
OUTPUT: Informazioni su tutte le pagine web del sito relative ai film.
DESTINAZIONE: Datastore.
PRE-CONDIZIONE: Il sistema non deve essere in esecuzione.
POST-CONDIZIONE: Nel datastore tutti i dati dei film presenti sul sito
al momento del crawling sono aggiornati, mentre quelli relativi ai film non
più presenti sul sito non sono aggiornati. Il sistema si mette in attesa della
prossima esecuzione.
PRIORITÁ : Alta.
FUNZIONE AUTOMATICA: No.
TEST DEL REQUISITO FUNZIONALE 1
INPUT DA INSERIRE: Parametri di crawling.
OUTPUT ATTESO: Verificare nel datastore che la data di aggiornamento di tutti i film presenti anche sul sito sia maggiore o uguale alla data di
inizio della procedura di crawling. Se il datastore precedentemente era vuoto,
verificare che sia stato riempito correttamente.
REQUISITO FUNZIONALE 2: Crawling selettivo
DESCRIZIONE: Il sistema avvia il crawling selettivo con un numero di
processi di crawling e di parsing. Tali parametri possono essere specificati
14
dal tecnico, in alternativa verranno usati quelli di default. Inoltre il tecnico
specifica dei criteri di aggiornamento in base ai quali il sistema decide se
aggiornare o no i dati di ogni specifico film. Il sistema quindi visita tutto il sito,
scarica le informazioni riguardanti ogni film che soddisfa i criteri specificati e
le salva nel datastore. Qualora il datastore fosse vuoto viene riempito.
Più in dettaglio, questa funzionalità permette di aggiornare:
• i film usciti in uno specifico anno o in uno specifico range di anni
• i film girati da specifici registi
• i film interpretati da specifici attori
• i film appartenenti a specifici generi
• i film destinati ad un pubblico specifico Qualora fosse specificato più
di un criterio alla volta, verranno estratti i film che soddisfano almeno
uno dei criteri (OR) e non tutti i criteri contemporaneamente (AND).
INPUT:
- Numero di processi di crawling(facoltativo).
- Numero di processi di parsing(facoltativo).
- Criteri di aggiornamento (obbligatorio):
• Attori
• Registi
• Anni d’Uscita
• Generi
• Pubblico Target
PROVENIENZA: Parametri immessi dal tecnico da GUI o riga di comando.
VINCOLI SULL’INPUT: Devono essere previste limitazioni relativamente a questo tipo di funzionamento del sistema. É stato quindi reputato
opportuno, per ottenere un buon compromesso tra flessibilità della ricerca e
potere discriminante, agire nel seguente modo :
• sarà possibile selezionare solo un massimo di 3 registi
• sarà possibile selezionare fino ad un massimo di 6 attori partecipanti ad
un film
15
• sarà possibile selezionare solo due generi di film
• sarà possibile selezionare solo uno specifico pubblico target.
Per quanto riguarda invece il range di anni è stato deciso di lasciare libertà totale di scelta all’utente che potrà scegliere un qualsiasi range di anni
compreso fra il 1895 e l’anno corrente.
OUTPUT: Informazioni sulle pagine web del sito relative ai film che soddisfano i criteri specificati.
DESTINAZIONE: Datastore.
PRE-CONDIZIONE: Non deve esserci in esecuzione nessun crawler, al
più può esserci il processo di crawling di default in pausa.
POST-CONDIZIONE: Nel datastore tutti i dati dei film che sono presenti
sul sito al momento del crawling e che soddisfano i criteri sono aggiornati.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: No.
TEST DEL REQUISITO FUNZIONALE 2
INPUT DA INSERIRE: Johnny Depp.
OUTPUT ATTESO: Verificare nel datastore che la data di crawling di
tutti i film di Johnny Depp presenti anche su MyMovies corrisponda alla data
odierna. Da notare che è ammissibile che nel datastore ci siano film di Johnny
Depp che non sono più presenti su MyMovies e che quindi non avranno la
data di crawling odierna.
REQUISITO FUNZIONALE 3: Pausa crawling
DESCRIZIONE: Sia in caso di crawling di default sia in caso di crawling
selettivo il sistema sospende i processi di crawling e parsing salvando lo stato
del sistema, cosı̀ da poter riprendere successivamente l’esecuzione, eventualmente modificando il numero di processi di crawling e di parsing. Lo stato
del sistema per entrambe le modalità di crawling comprende:
- Numero di processi di crawling.
- Numero di processi di parsing.
- Anni già analizzati
- Numero di film già analizzati per gli anni completamente analizzati (da
utilizzare nel requisito funzionale 7 nel caso di un’interruzione)
Nel particolare, per il crawling di default si aggiungono:
- Tempistiche di aggiornamento
Mentre, per il crawling selettivo si aggiungono:
- Criteri di aggiornamento:
16
• Attori
• Registi
• Anni d’Uscita
• Generi
• Pubblico Target
INPUT: Nessuno.
OUTPUT: Nessuno.
PRE-CONDIZIONE: NeptuneCrawler e neptuneParser devono essere in
funzione.
POST-CONDIZIONE: Nessun NeptuneCrawler/NeptuneParser è più in
funzione e lo stato del sistema è stato salvato nel datastore.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: No.
EFFETTI COLLATERALI:
Dopo la sospensione del crawling è garantito solo un aggiornamento parziale
dei dati. Inoltre quando verrà ripresa l’esecuzione non potranno essere mostrate le statistiche relative al tempo di esecuzione, ma solo quelle relative al
numero di film estratti.
REQUISITO FUNZIONALE 4: Riprendi crawling
DESCRIZIONE: Sia in caso di crawling di default che in caso di crawling
selettivo il sistema recupera lo stato precedentemente salvato nel datastore
riavviando i processi di crawling e parsing dando eventualmente la possibilità
di modificarne il numero.
INPUT:
- Numero di processi di crawling (facoltativo).
- Numero di processi di parsing (facoltativo).
PROVENIENZA: Parametri immessi dal tecnico da GUI o riga di comando.
OUTPUT: Nessuno.
PRE-CONDIZIONE: Entrambi i crawling possono essere riavviati se
prima erano in pausa e non ci sono crawling attivi. In particolare, il crawling
di default può essere riavviato solo se il crawling selettivo non è in pausa.
POST-CONDIZIONE: Il crawling selettivo o di default riprende la sua
esecuzione da dove era stato messo in pausa
PRIORITÁ : Bassa.
17
FUNZIONE AUTOMATICA: No.
REQUISITO FUNZIONALE 5: Interrompi crawling
DESCRIZIONE: Il sistema interrompe l’esecuzione del processo di default
o selettivo.
INPUT: Nessuno.
OUTPUT: Nessuno.
PRE-CONDIZIONE: Entrambi i crawling possono essere interrotti se
sono in funzione o in pausa. In particolare, il crawling di default in pausa può
essere interrotto solo se quello selettivo non è attivo o in pausa.
POST-CONDIZIONE: Nessun NeptuneCrawler/NeptuneParser del crawling interrotto è più in funzione.
PRIORITÁ : Alta.
FUNZIONE AUTOMATICA: No.
REQUISITO FUNZIONALE 6: Svuota datastore
DESCRIZIONE: Il sistema svuota il datastore eliminando tutti i dati
precedentemente raccolti dal sistema. Prima di procedere con l’operazione,
considerato l’effetto della stessa, verrà chiesta conferma all’utente avvertendolo
degli effetti di tale azione.
INPUT: Nessuno.
OUTPUT: Nessuno.
PRE-CONDIZIONE: Né il crawler di default né il crawler selettivo devono
essere attivi o in pausa.
POST-CONDIZIONE: Il datastore viene completamente svuotato.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: No.
TEST DEL REQUISITO FUNZIONALE 6
OUTPUT ATTESO: Datastore completamente vuoto.
REQUISITO FUNZIONALE 7: Monitora stato del crawling
DESCRIZIONE: Il sistema mostra costantemente le informazioni di interesse relative allo stato corrente del crawling. Le informazioni reputate di
interesse sono :
• anno/i attualmente in crawling
18
• numero totale di film estratti in ogni momento
• numero totale di film estratti nell’esecuzione precedente del sistema
• eventuali messaggi di errore
• titoli dei film estratti con l’anno di uscita
• stato del crawling in esecuzione:
– reperimento informazioni attivo
– in attesa della prossima esecuzione di reperimento (la durata
dell’attesa è data dal delay specificato all’avvio)
INPUT: Nessuno.
OUTPUT: Stato del crawling.
DESTINAZIONE: GUI o riga di comando.
PRE-CONDIZIONE: Nessuna.
POST-CONDIZIONE: Nessuna.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: Si.
Requisito funzionale 8: Mostra statistiche
DESCRIZIONE: Quando il crawler (di default o selettivo) termina un’esecuzione completa di estrazione di film vengono mostrate le statistiche
riguardanti tale esecuzione. Le statistiche reputate di interesse (e che quindi
verranno mostrate all’utente) sono:
• orari di inizio e di fine del processo di crawling/parsing
• tempo totale della procedura di estrazione
• tempo medio di crawling (tempo totale crawling/numero film reperiti)
• tempo medio di parsing (tempo totale parsing/numero film reperiti)
• numero totale di film estratti
INPUT: Nessuno.
OUTPUT: Statistiche reputate di interesse.
DESTINAZIONE: GUI o riga di comando.
PRE-CONDIZIONE: Un ciclo di esecuzione del crawling di default è
terminato oppure l’esecuzione del crawling selettivo è terminata.
19
POST-CONDIZIONE: Se il crawling era di default si mette in attesa della
prossima esecuzione. Se il crawling era selettivo termina la sua esecuzione.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: Si.
REQUISITO FUNZIONALE 9: Rimuovi URL non più validi
DESCRIZIONE: Il tecnico avvia una procedura di rimozione degli URL
invalidi dal datastore. Per fare ciò Neptune analizza il datastore ed elimina
da esso le informazioni e le URL relative alle pagine che sono state rimosse
dal sito di MyMovies. Un URL viene considerato invalido da Neptune quando
l’ultimo accesso con successo alla pagina corrispondente è avvenuto più di 5
mesi fa e sono stati fatti almeno 5 tentativi di accesso infruttuosi.
INPUT: Nessuno.
OUTPUT: Nessuno.
PRE-CONDIZIONE: Né il crawler di default né il crawler selettivo devono
essere in esecuzione o in pausa.
POST-CONDIZIONE: Il datastore contiene solo informazioni sui film
corrispondenti a URL validi.
PRIORITÁ : Bassa.
FUNZIONE AUTOMATICA: No.
3.2.2
Sottofunzionalità
Di seguito verranno specificate delle sottofunzionalità che il sistema deve
offrire per poter garantire le funzionalità elencate precedentemente:
SOTTOFUNZIONALITÁ 1: Cerca URL
DESCRIZIONE: Il NeptuneCrawler visita una pagina web, recupera gli
URL presenti nella pagina e li salva nel buffer.
INPUT: Pagina web.
PROVENIENZA: La pagina è scaricata dal sito www.mymovies.it.
OUTPUT: Insieme di URL.
DESTINAZIONE Buffer.
PRE-CONDIZIONE: Nessuna.
POST-CONDIZIONE: Nessuna.
PRIORITÁ : Alta.
FUNZIONE AUTOMATICA: Si.
20
TEST DELLA SOTTOFUNZIONALITÁ 1
INPUT DA INSERIRE: http://www.mymovies.it/film/2010/
OUTPUT ATTESO: Il buffer deve contenere tutte le URL delle pagine
di descrizione dei film che compaiono nella pagina in input.
SOTTOFUNZIONALITÁ 2: Estrai informazioni dalla pagina
DESCRIZIONE: Il NeptuneParser, dato un URL, recupera la corrispondente pagina web, la analizza, ne estrae informazioni utili sui film e le salva
nel datastore.
INPUT: URL di una pagina.
PROVENIENZA: Buffer.
OUTPUT: Dati del film.
DESTINAZIONE Datastore.
PRE-CONDIZIONE: Nessuna.
POST-CONDIZIONE: Il datastore contiene tutti i dati aggiornati riguardanti il film.
PRIORITÁ : Alta.
FUNZIONE AUTOMATICA: Si.
TEST DELLA SOTTOFUNZIONALITÁ 2
INPUT DA INSERIRE: http://www.mymovies.it/film/2000/ilgladiatore/
OUTPUT ATTESO:
Titolo: Il gladiatore.
Regista: Ridley Scott.
Attori: Russell Crowe, Joaquin Phoenix, Connie Nielsen, Richard Harris,
Oliver Reed, Djimon Hounsou, Derek Jacobi, Tomas Arana, John Shrapnel,
Sven Ole Thorsen, Giorgio Cantarini, Giannina Facio, Tommy Flanagan,
David Schofield, Spencer Treat Clark, Ralf Moeller, David Hemmings.
Genere: storico.
Pubblico target: —
Durata: 1550 min.
Anno di uscita: 2000.
Valutazione: 3, 91 stelle.
Trama: Eroiche peripezie di Maximus,...
Data ultimo aggiornamento film: data in cui è stato eseguito tale test.
21
3.3
Requisiti non funzionali
3.3.1
Requisiti di aggiornamento
Relativamente al requisito sulle tempistiche di aggiornamento dei dati durante
il crawling di default, risulta ragionevole mantenerne un diverso grado in base
alla data di uscita del film.
Quindi sono previsti i seguenti tre tipi di aggiornamento:
• i film usciti negli ultimi x1 anni verranno aggiornati una volta ogni y1
giorni
• i film usciti negli ultimi x2 anni verranno aggiornati una volta ogni y2
giorni
• tutti gli altri film verranno aggiornati una volta ogni y3 giorni
Quando tali parametri saranno specificati dal tecnico si provvederà a
testare che valgano le seguenti relazioni:
y1 < y2 < y3
x1 < x2 < (anno corrente − 1895)
Nel caso in cui il tecnico non specifichi i parametri si utilizzeranno i
seguenti valori di default:
• x1 = 2 e y 1 = 2
• x2 = 5 e y 2 = 7
• y3 = 20
Tali valori sono considerati ottimali ma sono stati definiti a riguardo anche
dei requisiti minimi che Neptune dovrà soddisfare a prescindere dall’infrastruttura hardware su cui verrà fatto funzionare. Più precisamente, se il tecnico
non specifica i parametri di aggiornamento, il nostro sistema deve garantire
che:
• i dati dei film usciti negli ultimi 2 anni debbano essere aggiornati almeno
1 volta ogni 7 giorni
• i dati dei film usciti negli ultimi 5 anni debbano essere aggiornati almeno
1 volta ogni 30 giorni
• i dati di tutti gli altri film debbano essere aggiornati almeno 1 volta
ogni 70 giorni
22
É da notare che al primo avvio del crawler il datastore è vuoto e quindi
verranno scaricati tutti i film presenti sull’archivio. Nelle successive esecuzioni
i film verranno scaricati dall’archivio in base alle tempistiche di aggiornamento
specificate sopra.
3.3.2
Requisiti di performance
Collo di bottiglia per la velocità - Considerata la natura del progetto
le performance sono estremamente variabili: dipendono dalla potenza della
macchina host e dalla velocità della rete utilizzata per l’accesso alla fonte di
informazioni. A fronte di questo non possono essere formulati requisiti precisi
sulle performance, ma si deve assicurare che una volta lanciato, Neptune
completi l’esplorazione del sito in un tempo finito. In ogni caso, va garantito
un tempo massimo di esecuzione per il processo di estrazione degli URL da
una singola pagina (crawling), che non deve durare più di qualche decimo
di secondo e va garantito un tempo massimo di esecuzione per il processo di
parsing di una singola pagina, che non deve durare più di qualche secondo.
Requisiti minimi di performance - Nonostante l’impossibilità di definire
requisiti precisi di performance sussistono comunque dei limiti minimi per
l’accettabilità nel livello di aggiornamento di un dato; questi sono espressi
nella Sezione 3.3.1 - Requisiti di aggiornamento
3.3.3
Attributi di qualità del software
Availability e Reliability - Durante lo sviluppo, contrariamente a come
generalmente accade nello sviluppo di sistemi software, si dovrà porre principalmente il focus non sulla reliability ma sulla availability del sistema. É
più tollerabile infatti che il SE restituisca dati errati/incompleti rispetto al
non rispondere a causa di un blocco del sistema. Nonostante ciò abbiamo
considerato delle soluzione per entrambe le problematiche.
Soluzione adottata per garantire avalability - La strutturazione a blocchi con NeptuneCrawler e NeptuneParser è stata reputata sufficiente per
garantire un adeguato livello di availability del sistema. Affinchè Neptune
fallisca infatti è necessario che tutti i moduli di crawling o tutti i moduli
di parsing riscontrino un’eccezione non gestibile; tale scenario appare però
improbabile, soprattutto all’aumentare del numero dei singoli moduli atti allo
svolgimento di tali funzioni.
Soluzione adottata per garantire reliability - Per garantire un adeguato
livello di reliability è stato previsto un semplice meccanismo di recovery che,
in caso di interruzione non prevista dell’esecuzione del sistema, permetta di
riprendere il procedimento dallo stato in cui il sistema si trovava prima del
23
blocco. Per maggiori dettagli riguardanti lo stato in questione consultare il
Requisito funzionale 3: Pausa crawling nella Sezione 3.2 - Requisiti funzionali
3.3.4
Altri requisiti
Manutenibilità e scalabilità - Requisiti invece importanti sono la manutenibilità e la scalabilità del sistema nell’ipotesi di sviluppi futuri. Questi si
intendono garantire strutturando Neptune in modo modulare.
Portabilità - Neptune deve essere portabile, ossia indipendente da ogni piattaforma hardware e software, come già definito nella Sezione 2.4 - Assunzioni
e dipendenze.
Il soddisfacimento di questo requisito dovrà essere garantito sia dal linguaggio di programmazione che verrà scelto per l’implementazione finale, sia
dalla possibilità di settare il numero di moduli di crawling e parsing in modo
da adattarlo alla potenza di calcolo della macchina host. A tal proposito,
nel caso in cui non vengano specificati il numero di moduli di crawling e di
parsing, i valori di default che verranno usati saranno i seguenti:
Numero moduli di crawling = 5
Numero moduli di parsing = 10
Tali numeri sono volutamente bassi per poter garantire un corretto funzionamento del sistema anche su macchine dotate di scarsa potenza di calcolo.
Inoltre viene mantenuto un numero di crawler più basso del numero di parser
in quanto il carico di lavoro dei primi è inferiore a quello dei secondi. In
questa fase non si possono definire valori di default più precisi in quanto ci si
dovrebbe basare su delle stime di tempo attualmente non fattibili in quanto
dipendono dagli ambienti e dalle tecnologie delle macchine su cui Neptune
sarà installato.
24
3.4
3.4.1
Diagrammi del sistema
Diagramma di sequenza
Figura 4: Diagramma di sequenza ad alto livello
25
3.4.2
Diagrammi di stato
Figura 5: Stati del crawler
Figura 6: Stati del parser
26
Figura 7: Satati del buffer
27