Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
Relatore
Luigi De Giovanni
Laureando Daniele Penazzo Mat: 1007651
Anno Accademico 2017/2018
Alla mia famiglia
Ai miei amici, nazionali e non A coloro che non si arrendono mai
Indice
1 Introduzione 6
1.1 L’azienda . . . 6
1.2 L’idea . . . 6
1.3 Organizzazione del testo . . . 6
1.4 Introduzione al progetto . . . 7
2 Pianificazione delle attività 8 2.1 Obiettivi fissati . . . 8
2.2 Pianificazione temporale . . . 9
3 Analisi preventiva 10 3.1 Analisi preventiva dei rischi . . . 10
3.2 Piano di contingenza . . . 11
3.3 Analisi dell’architettura esistente . . . 12
3.4 Analisi dei siti internet esplorati dal sistema . . . 13
3.4.1 Criticità rilevate . . . 13
3.4.2 Estrazione dei loghi . . . 14
3.4.3 Estrazione delle informazioni testuali . . . 14
4 Analisi dei requisiti 17 4.1 Casi d’uso . . . 17
4.2 Tracciamento dei requisiti . . . 20
4.2.1 Requisiti Funzionali . . . 20
4.2.2 Requisiti di Qualità . . . 24
4.2.3 Requisiti di Vincolo . . . 25
4.2.4 Riepilogo Requisiti . . . 26
5 Progettazione 27 5.1 Tecnologie e strumenti . . . 27
5.1.1 Python 3 . . . 27
5.1.2 Flake8 . . . 27
5.1.3 Django . . . 27
5.1.4 DjangoREST . . . 28
5.1.5 Celery . . . 28
5.1.6 Swagger . . . 28
5.1.7 Vagrant . . . 28
5.1.8 VirtualBox . . . 29
5.1.9 BeautifulSoup4 . . . 29
5.1.10 PostgreSQL . . . 29
5.1.11 Selenium . . . 29
5.1.12 Requests . . . 30
5.1.13 NeoVIM . . . 30
5.1.14 JavaScript . . . 30
5.1.15 ESLint . . . 31
5.1.16 ReactJS . . . 31
5.1.17 Redux . . . 31
5.1.18 Bundle-js . . . 31
5.1.19 Scrapy . . . 32
5.2 Ciclo di vita del software . . . 32
5.3 Design Pattern utilizzati . . . 33
5.3.1 Chain of Responsibility Design Pattern . . . 33
5.3.2 Pipeline design pattern . . . 33
5.4 Altre scelte di design . . . 34
5.4.1 Interfacce fluide per la costruzione della pipeline . . . 34
5.5 Progettazione dell’architettura . . . 34
5.5.1 Classi e moduli . . . 35
5.6 Punti di estensione dell’architettura . . . 38
6 Codifica 39 6.1 Norme di codifica seguite . . . 39
6.1.1 Python . . . 39
6.1.2 JavaScript . . . 39
6.2 Gestione del repository Git . . . 39
6.3 Implementazione della pipeline di web scraping . . . 40
6.4 Creazione della pagina di amministrazione Django . . . 40
6.5 Implementazione della pipeline di scraping del catasto . . . 42
6.6 Implementazione front-end Django per lo scraping dal catasto . . . 42
6.7 Implementazione delle chiamate REST per gli scraper . . . 43
6.8 Implementazione del front-end React . . . 43
7 Verifica e Validazione 45 7.1 Analisi Statica . . . 45
7.2 Analisi Dinamica . . . 45
7.3 Specifica dei test . . . 45
7.4 Validazione . . . 51
8 Conclusioni 52 8.1 Consuntivo dei rischi . . . 52
8.2 Raggiungimento degli obiettivi . . . 52
8.3 Conoscenze acquisite . . . 53
8.4 Valutazione personale . . . 54
8.4.1 Valutazione del progetto di stage . . . 54
8.4.2 Valutazione dello stage e del progetto RiskApp . . . 54
8.4.3 Valutazione finale . . . 54
Glossario 56
Elenco delle tabelle
1 Obiettivi fissati nel piano di lavoro . . . 8
2 Pianificazione del lavoro . . . 9
4 Descrizione dei rischi, con probabilità ed incidenza. . . 10
5 Piano di contingenza dei rischi. . . 11
6 Tabella di tracciamento dei requisiti funzionali . . . 20
7 Tabella di tracciamento dei requisiti di qualità . . . 24
8 Tabella di tracciamento dei requisiti di vincolo . . . 25
9 Riepilogo dei requisiti . . . 26
10 Specifica dei test automatici implementati . . . 45
11 Consuntivo dei rischi rilevati . . . 52
12 Raggiungimento degli obiettivi di progetto . . . 52
Elenco delle figure
1 Diagramma dei casi d’uso per la componente WebScraper . . . 172 Diagramma dei casi d’uso per la componente LRScraper . . . 18
3 Schema del ciclo di vita incrementale . . . 32
4 Esempio di lavagna Kanban . . . 32
5 Esempio di chain of responsiblity pattern . . . 33
6 Struttura del pipeline pattern . . . 33
7 Schema esemplificativo del funzionamento dell’architettura . . . 35
8 Schema di gestione del repository Git [31] . . . 40
9 I nuovi modelli nella pagine di amministrazione Django . . . 41
10 Ricerca nel pannello amministrativo Django . . . 41
11 Modifica di un dato dal pannello amministrativo . . . 41
12 Schermata di ricerca dello scraper del catasto . . . 42
13 Scelta dell’omonimo catastale . . . 42
14 Avvio di un nuovo scraping da front-end . . . 43
15 Visualizzazione risultati o riavvio di uno scraping . . . 43
16 Visualizzazione dello stato dello scraping . . . 43
17 Visualizzazione dei risultati dello scraping . . . 44
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata di 312 ore, dal laureando Daniele Penazzo presso l’azienda RiskApp S.r.l.
Gli obiettivi da raggiungere erano molteplici.
In primo luogo era richiesto lo sviluppo di una componente di web scraping da integrare alla piattaforma esistente, tale componente doveva effettuare ricerche ed esplorare siti internet alla ricerca di informazioni che possano ritenersi interessanti a fini assicurativi. Tale componente inoltre doveva avere determinate caratteristiche di modularità, estensibilità ed autonomia.
In secondo luogo era richiesto lo sviluppo di una componente di scraping specifica per il catasto, da integrare ancora una volta sulla stessa piattaforma, allo scopo di ricavare ulteriori informazioni di interesse dal catasto nazionale, eventualmente richiedendo una visura catastale.
Successivamente è stato richiesto di implementare delle componenti di front-end, degli endpoint REST per l’applicazione web ed una suite di test che garantisse una buona copertura del codice scritto. Oltre a ciò è stata richiesta l’integrazione delle componenti esposte nella piattaforma RiskApp.
Ringraziamenti
As we express our gratitude, we must never forget that the highest appreciation is not to utter words but to live by them.
John F. Kennedy Vorrei ringraziare il Prof. Luigi De Giovanni, relatore della mia tesi, per l’aiuto datomi durante la stesura del
lavoro.
Desidero inoltre ringraziare i miei genitori per il sostegno e pazienza portati in questi anni.
Ho desiderio di ringraziare i miei amici più vicini per il sostegno morale e l’aiuto offerti oltre alla loro vicinanza nei momenti più duri.
Padova, Settembre 2018 Daniele Penazzo
1 Introduzione
1.1 L’azienda
RiskApp S.r.l. è una start-up che si occupa dello sviluppo di un sistema all-in-one di gestione e valutazione dei rischi per l’industria assicurativa.
Tale sistema offre supporto ai player assicurativi e bancari che desiderano offrire soluzioni per la copertura delle piccole e medie imprese, sviluppando modelli di calcolo per l’analisi dei rischi che un’eventuale compagnia assicurativa vuole coprire.
Il prodotto offre inoltre strumenti per stimare eventi negativi, valutare rischi, aiutare le assicurazioni ad effettuare decisioni informate e ricevere un rapporto dettagliato e chiaro dei rischi, così da mitigarli o assicurarli.
1.2 L’idea
Internet è un luogo ricco di informazioni e notizie che possono risultare utili per arricchire il profilo di un’azienda ed aumentare la precisione di un’eventuale valutazione dei rischi. Tali informazioni e notizie si presentano nella forma di “dati non strutturati” che dovranno essere elaborati per poter essere utilizzati in modo proficuo all’interno di un sistema informatico.
L’idea è creare un’architettura che permetta di estrarre, in forma maggiormente strutturata e con minimo intervento da parte dell’utente finale, tali dati in modo da arricchire lo screening informativo delle aziende analizzate.
1.3 Organizzazione del testo
Il testo è organizzato in sezioni tematiche, nel seguente modo:
• Introduzione: contenente le informazioni riguardanti l’azienda ospitante, l’idea, l’organizzazione del testo ed una breve introduzione al progetto di stage;
• Pianificazione: dove sono inseriti gli obiettivi accordati con l’azienda e l’organizzazione del lavoro;
• Analisi Preventiva: per acquisire maggiore conoscenza del dominio di applicazione e dell’architettura esistente, esponendo eventuali criticità che possono rendere difficoltoso lo svolgersi del progetto;
• Analisi dei requisiti: contenente i compiti svolti durante l’attività di analisi dei requisiti;
• Progettazione: in cui sono presenti tutti i dettagli dell’attività di progettazione dell’architettura;
• Codifica: contenente le norme di codifica, la gestione del repository[g] GIT ed una visuale retrospettiva dell’attività di codifica;
• Verifica e validazione: in cui sono presenti i dettagli concernenti i test, le attività di verifica e validazione finale;
• Conclusioni: a chiusura del testo.
Per quanto concerne la stesura del testo, sono state le seguenti convenzioni tipografiche:
• acronimi, abbreviazioni e termini di uso non comune o ambigui vengono definiti nel glossario, situato in appendice al presente documento;
• la prima occorrenza dei termini riportati nel glossario saranno evidenziati nel seguente modo: parola[g];
• i termini in lingua straniera o facenti parte del gergo tecnico sono evidenziati con carattere corsivo.
1.4 Introduzione al progetto
RiskApp è un software mirato alla gestione e valutazione dei rischi per l’industria assicurativa, una parte importante del processo di valutazione di un cliente è l’estrazione di dati, la loro trasformazione e successiva- mente il loro caricamento sulla piattaforma (procedura detta ETL[g]). Tale procedura sta alla base di un processo chiamato data enrichment[g], nel quale questo progetto di stage si inserisce.
Lo scopo del progetto di stage è creare un’architettura in grado di estrarre autonomamente (o con intervento dell’utente estremamente limitato) dati non strutturati[g]e semi-strutturati[g] da diverse fonti sul web, tra cui:
• Google Places;
• Google StreetView;
• Siti internet aziendali;
• Siti web appartenenti a testate giornalistiche;
• Il registro dei dati catastali.
L’architettura da costruire deve essere inoltre in grado di superare eventuali ostacoli che solitamente derivano da una costruzione dei siti web non corretta oppure portata a compimento tramite uso di tecniche obsolete.
Avvenuto il processo di estrazione, l’architettura deve salvare i dati in modo strutturato, facendo eventualmente uso di campi semi-strutturati come JSON[g]e visualizzarli in una componente front-end creata ad-hoc.
L’architettura deve offrire garanzie di solidità agli errori esterni, così da poter operare in autonomia, e di alta estensibilità e flessibilità così da poter aggiungere, togliere o riorganizzare stadi di scraping[g] in maniera semplice e veloce con minime modifiche al codice esistente.
2 Pianificazione delle attività
2.1 Obiettivi fissati
Nel piano di lavoro sono state pianificati alcuni obiettivi di massima che l’architettura prodotto dell’esperienza di stage dovrà andare a soddisfare con diverse priorità. Si farà riferimento a tali obiettivi secondo le seguenti notazioni:
• OB#: Obiettivo obbligatorio, vincolante in quanto obiettivo primario richiesto dal committente;
• D#: Obiettivo desiderabile, non vincolante o strettamente necessario, ma dal riconoscibile valore aggiunto;
• OP#: Obiettivo opzionale, rappresentante un valore aggiunto non strettamente competitivo.
Si riporta qui la tabella degli obiettivi posti nel piano di lavoro:
Tabella 1: Obiettivi fissati nel piano di lavoro Codice Descrizione
OB1 Progettazione ed implementazione di una componente di scraping di dati anagrafici testuali da Google Places
OB2 Progettazione ed implementazione di una componente per lo scraping di dati anagrafici testuali dato un URL[g]aziendale
OB3 Progettazione ed implementazione di una componente di scraping per il recupero di loghi di aziende
OB4 Progettazione ed implementazione di chiamate REST per l’uso da parte del sistema della nuova componente
OB5 Progettazione ed implementazione della componente di Front-end
OB6 Implementazione dei test automatici di unità per le componenti di scraping da Google Places e dai siti web aziendali
D1 Implementazione dello scraping di dati dal catasto D2 Conoscenza dell’impianto esistente
D3 Implementazione di un sistema per l’acquisizione di screenshot della home page dei siti web aziendali
OP1 Implementazione di test di unità delle componenti non testate in OB6 OP2 Implementazione di test di integrazione
OP3 Integrazione dei test nella suite esistente
2.2 Pianificazione temporale
Per quanto riguarda la pianificazione temporale si è deciso di dedicare il seguente ammontare di ore ad ogni attività svolta:
Tabella 2: Pianificazione del lavoro Durata Attività
72 Ore
Formazione
• Apprendimento di Python avanzato
• Apprendimento di Scrapy
• Apprendimento di Django
• Apprendimento di Swagger
8 Ore
Analisi ed apprendimento delle tecnologie usate per la gestione del sistema preesistente
• Analisi del sistema preesistente
• Creazione della macchina virtuale a supporto dello sviluppo della componente
• Creazione dell’ambiente virtuale ed installazione delle dipendenze necessarie allo sviluppo
25 Ore
Attività di analisi
• Analisi dei requisiti
◦ Analisi della natura dei dati da raccogliere tramite *scraping*
◦ Analisi delle tecnologie alternative (Google APIs for Python)
30 Ore
Progettazione della componente:
• Strutturazione delle chiamate *REST*
• Strutturazione delle modalità di *scraping*
• Strutturazione della componente di front-end
147 Ore
Implementazione della componente:
• Implementazione della componente di *scraping* di dati testuali
• Implementazione della componente di *scraping* di dati grafici
• Implementazione delle chiamate *REST*
• Implementazione della componente di front-end
• Implementazione dello *scraping* di dati del catasto 30 Ore Implementazione dei test
312 Ore Totale ore pianificate
3 Analisi preventiva
A good programmer is someone who looks both ways before crossing a one-way street.
Doug Linder
3.1 Analisi preventiva dei rischi
Per assicurare uno svolgersi del progetto quanto più possibile privo di inconvenienti, ho provveduto ad analizzare i rischi che possono verificarsi durante lo svolgersi dello stage.
I rischi sono classificati in forma tabellare, evidenziando:
• Un codice identificativo univoco;
• La denominazione del rischio, la quale fornisce un’idea di base del rischio stesso;
• Una descrizione estesa del rischio;
• La probabilità di occorrenza;
• L’ incidenza del rischio sullo svolgersi del progetto.
I rischi si suddividono in quattro categorie principali:
• RT: Rischi legati alle tecnologie usate;
• RP: Rischi personali;
• RS: Rischi strumentali;
• RR: Rischi riguardanti i requisiti.
Tabella 4: Descrizione dei rischi, con probabilità ed incidenza.
Codice Denominazione Descrizione Probabilità Incidenza
RT1 Inesperienza
Tecnologica Alcune tecnologie adottate potrebbero non
essere conosciute o di difficile comprensione. Media Alta
RT2 Problemi
Hardware e Software
La strumentazione può essere soggetta a malfunzionamenti ed il software può avere problemi di compatibilità, con possibili perdite di dati e difficoltà nell’avanzamento del progetto
Bassa Bassa
RP1 Problemi
personali In un progetto su che ha lunga durata, possono verificarsi problemi personali che costringono a rallentare o sospendere temporaneamente il progetto di stage
Bassa Bassa
RS1 Regressioni nel
codice È possibile che alcune correzioni apportate in itinere al codice creato possano far sorgere bachi nel software
Bassa Media
RR1 Errata
comprensione dei requisiti
Durante l’analisi è possibile che si possano avere fraintendimenti sulla natura dei requisiti da coprire e tali requisiti possono essere a loro volta studiati in modo erroneo o incompleto
Media Alta
Codice Denominazione Descrizione Probabilità Incidenza
RR2 Variazioni dei
requisiti Vi è la possibilità che i requisiti subiscano variazioni nel tempo a causa di idee proposte, novità nel dominio di
applicazione o cattiva organizzazione da parte del proponente del progetto
Media Alta
3.2 Piano di contingenza
È stato quindi posto in essere un piano di contingenza proponente soluzioni che permettano di annullare o mitigare quanto più possibile le conseguenze collegate ai rischi analizzati.
Il piano di contingenza è descritto in forma tabellare e riporta:
• Il codice del rischio considerato;
• La strategia di rilevazione di tale rischio;
• Una serie di contromisure suggerite per la mitigazione di tale rischio.
Tabella 5: Piano di contingenza dei rischi.
Codice Strategia di Rilevazione Contromisure suggerite o attuate RT1 Stilare un elenco delle tecnologie usate e da
usare ed effettuare una valutazione sul livello di conoscenza di tali tecnologie
In caso di conoscenza scarsa o assente di una determinata tecnologia, sarà necessario procedere ad una documentazione al riguardo, facendo uso di risorse gratuite disponibili on-line e comunicando strettamente con il capo programmatore del progetto.
RT2 Verificare periodicamente lo stato di
manutenzione degli strumenti di lavoro e porre un’adeguata cura nei confronti degli stessi
Prima di ogni spostamento o chiusura dello strumento di lavoro, si dovrà effettuare una push[g] sul repository GitHub messo a disposizione dall’azienda. Inoltre in caso di malfunzionamento della postazione di lavoro personale, l’azienda mette a disposizione una postazione di lavoro alternativa da cui è possibile proseguire il progetto di stage.
RP1 Si dovrà avvisare il personale aziendale con
congruo anticipo in caso di problemi personali. Successivamente al verificarsi del rischio, sarà necessario pianificare nuovamente il lavoro così da poter recuperare il tempo perso ed
eventualmente avvisare l’Ufficio Stage della variazione. Nei documenti ufficiali è già stato posto un periodo di slack[g] di sette giorni.
RS1 Per rilevare possibili regressioni nel codice si farà uso di un sistema di continuous
integration[g]
Ogniqualvolta si verifica un bug, si andrà a creare un nuovo test in grado di evitare che tale bug sorga nuovamente senza essere notato.
Codice Strategia di Rilevazione Contromisure suggerite o attuate RR1 Per tutta la durata dello stage si manterrà
contatto con i proponenti del progetto di stage In caso di divergenza tra requisiti rilevati e quanto richiesto dai proponenti dello stage, si dovranno effettuare correzioni all’analisi e si discuteranno con il proponente stesso le strategie di mitigazione più consone.
RR2 Per tutta la durata dello stage si manterrà
contatto con i proponenti del progetto di stage Si dovrà analizzare quali requisiti portano maggior valore aggiunto al progetto esistente ed in caso di variazioni si dovrà prontamente discutere con il proponente per mediare una soluzione ideale.
3.3 Analisi dell’architettura esistente
L’architettura esistente si presenta suddivisa in due parti principali, distribuite su due macchine separate:
• Ayako: che si occupa dei calcoli e degli algoritmi;
• Noriko: che si occupa della persistenza dei dati.
Il progetto oggetto dello stage sarà contenuto nella sua integrità all’interno di Ayako, quindi quest’ultima parte sarà oggetto dell’analisi.
L’analisi è stata effettuata studiando il codice esistente, ponendo domande sull’architettura stessa e sulle motivazioni delle decisioni intraprese oltre all’analisi ed esecuzione della suite di test per poter verificare lo stato di copertura del codice.
Dall’analisi sono emerse alcune criticità che elenco qui sotto:
• Debito tecnologico: Nonostante il software sia ancora nella forma di progetto pilota[g], è possibile notare che viene fatto uso di una versione obsoleta di Django, che presenta falle di sicurezza conosciute;
questo è dovuto a due fattori principali:
– Uso di campi deprecati: “MoneyField”, usato in alcuni punti del progetto è un campo che non fa parte dei campi offerti da Django e nemmeno tra i campi mantenuti dalla comunità. Questo rende complessa la manutenzione e gli aggiornamenti riguardanti il modulo che offre tale campo non sono garantiti;
– Uso di EAV: Il progetto correntemente fa uso di un fork[g] di Django-EAV per il supporto al modello di conservazione dati di tipo Entity-Value-Attributeˆ[g], oltre tutto si è inserito come dipendenza una precisa commit[g]di tale fork, bloccandone così gli aggiornamenti.
• Coverage[g]falsata: Il file di configurazione di coverage era impostato in modo tale da includere file che a mia modesta opinione vanno a falsare la copertura del codice, tali files includono:
– Migrazioni: che sono usate per propagare le modifiche fatte sui modelli verso lo schema di database, solitamente queste sono eseguite ad ogni avvio dei test, comportando una loro copertura del 100%;
– File di configurazione: L’unico file di configurazione usato durante i test è settings_test.py, mentre gli altri file di configurazione (configurazione in produzione, per lo sviluppo su macchina virtuale, . . . ) riporteranno una copertura dello 0%;
– I test stessi: Dato che sono eseguiti integralmente, questi files riporteranno una copertura del 100%, falsando la metrica.
• Copertura dei test bassa: Dopo una riconfigurazione dell’analizzatore di copertura dei test, la coverage si è abbassata di 20 punti percentuali, attestandosi poco sopra il 40%, una percentuale molto bassa per un sistema così ampio. Ciò dimostra come piccole differenze nella configurazione di una componente facente parte del cruscotto informativo di un progetto possano eventualmente arrivare a falsare le prospettive di solidità di un sistema software;
• Test di unità: Sembra che la maggior parte dei test vada a coprire gruppi di funzionalità, mentre i test di unità veri e propri sembrano essere veramente esigui;
• Doppio front-end: Il sistema, nonostante sia in fase di progetto pilota, sembra stia già subendo una migrazione da un front-end basato su template[g] e view[g] Django ad un front-end basato su React, questo comporta la presenza di una possibilmente grande quantità di codice legacy[g] che riduce la manutenibilità dell’architettura;
• Comunicazione front-end e back-end basata su polling[g]: La comunicazione tra il front-end ed il back-end è basata su un polling periodico del database ogni 5 secondi, questa forma di comunicazione può provocare rallentamenti del sistema, appesantimento del codice, difficoltà di lettura del codice stesso e difficoltà nel testing. Nel caso di una re-ingegnerizzazione del sistema, un’alternativa più moderna potrebbe essere una comunicazione basata su websockets;
• Cattiva gestione del polling: Il front-end inizia la propria procedura di polling al caricamento delle componenti React e non quando strettamente necessario (ad esempio quando si è in attesa del completamento di un’operazione asincrona), questo provoca la creazione di traffico non necessario sulla rete e carico sul client a causa delle funzioni in esecuzione ad intervalli regolari. Inoltre il polling provoca un aggiornamento di molte componenti alla volta, a causa di Redux, appesantendo ulteriormente la web-app;
• Architettura “database-centric”: Come conseguenza dell’uso di polling, è necessario fare uso di un sistema che consenta di memorizzare lo stato delle eventuali elaborazioni in corso; nell’architettura corrente il database fornisce tale funzionalità. Questo ha come conseguenza un appesantimento delle strutture dati, con l’aggiunta di campi che memorizzino lo stato delle elaborazioni, così da evitare di leggere dati parziali. Inoltre il database potrebbe essere un collo di bottiglia, limitando le prestazioni del sistema. Usare il database in questo modo costringe inoltre a far ricorso a test fixture[g] aggiuntive rendendo difficoltosa la lettura del codice. A tutto questo si aggiunge la necessità di gestire la scrittura su database ad ogni passaggio, aumentando gli assi di cambiamento delle componenti sviluppate, a discapito del principio di Single Responsibility[g];
• Front-end privo di documentazione: Il front-end è stato appaltato ad un’azienda esterna, il codice JavaScript risulta completamente privo di commenti, estremamente complesso e senza alcun tipo di documentazione. Questo lo rende difficilmente ispezionabile e non è possibile fare affidamento sul team che ha proposto lo stage per eventuali chiarimenti su di esso;
• Uso di metodi obsoleti nel front-end: Il front-end fa uso di una serie di metodi che sono dichiarati come obsoleti in fase di build[g], questo limita la manutenibilità del front-end stesso, dato che un aggiornamento potrebbe portare con sé la rimozione dei metodi obsoleti usati;
• Ciclo di build del front-end troppo lungo: Il front-end subisce una procedura di build tramite uno script apposito, ma ogni build richiede circa 15 minuti, a causa della gestione di tutti i file statici, reinstallazione tutte le dipendenze, build dei progetti collegati e costruzione di un bundle (cioè un unico file JavaScript contenente l’intero front-end), anche quando non necessario. Questo tempo è troppo lungo per uno sviluppo efficiente, soprattutto dato che il front-end non è molto esteso;
• Uso di bundle-js: L’uso di bundle.js forza la creazione di un unico file JavaScript minificato[g]a cui tutto il progetto fa riferimento, questo rende il debugging estremamente complesso.
3.4 Analisi dei siti internet esplorati dal sistema
3.4.1 Criticità rilevate
Durante l’analisi dei siti web sono stati rilevate alcune criticità che potrebbero mettere in crisi un motore di scraping automatizzato come quello oggetto del progetto di stage:
1. Redirect[g] HTTP: Alcuni URL potrebbero portare ad una risposta del server con codici 301 (permanentemente spostato) o 302 (ridirezione temporanea);
2. Redirect creati con script JavaScript: alcuni siti, invece di far uso dei redirect interni al server web, inseriscono una pagina contenente un solo script che forza il browser a cambiare pagina, verso un dominio diverso;
3. Frame HTML [g]: contenenti componenti derivanti da un altro dominio o pagina, che potrebbero rendere difficoltosa l’ispezione del codice;
4. Link diversi da ancore HTML standard: Alcuni siti fanno uso di immagini di sfondo e tag <area href='...'> per la costruzione di siti web, questi link potrebbero sfuggire ai motori più semplici.
Queste criticità sono state gestite nel corso del progetto, come si vedrà in seguito.
3.4.2 Estrazione dei loghi
L’idea alla base della funzionalità di estrazione dei loghi è l’uso di diverse metodologie euristiche[g], basate sui siti messi a disposizione dall’azienda proponente e sulla mia esperienza personale nell’uso, studio, creazione di siti internet ed interesse nelle metodologie SEO[g].
Qui di seguito riporto una lista ordinata delle metodologie euristiche implementate nell’architettura, ordinate per quella che ritengo essere la loro affidabilità nel restituire un logo aziendale:
1. Analisi dei microdata[g]Ld+Json [1, 2]
2. Analisi delle Twitter Cards [3] e dei meta tag collegati;
3. Analisi dei tag Facebook/OpenGraph [4], anche se oramai sono considerati obsoleti;
4. Analisi dell’attributo id dei tag <img ...>: molte aziende usano l’id “logo” (o che comunque contengono la parola “logo”) per identificare il proprio logo aziendale in un sito internet;
5. Analisi dell’attributo class dei tag <img ...>: molte aziende fanno uso della class “logo” (o che comunque contengono la parola “logo”) per identificare il proprio logo aziendale all’interno del sito;
6. Analisi dei fogli stile CSS del sito: alcune aziende usano attributi id e class contenenti la parola “logo”
all’interno di contenitori come <div> per poi fare uso delle proprietà background-image di CSS per visualizzare il logo;
7. Analisi dell’attributo src dei tag <img ...>: molte aziende semplicemente danno al file contenente il logo aziendale il nome “logo”;
8. Analisi dell’attributo alt dei tag <img ...>: alcune aziende, più raramente, inseriscono “logo” come descrizione testuale all’immagine del proprio logo aziendale;
9. Analisi dell’attributo alt dei tag <img ...>: alcune aziende, seppur molto raramente, inseriscono la ragione sociale all’interno dell’attributo alt del proprio logo aziendale;
10. Analisi dei tag <link rel='icon' ...>: questo però potrebbe restituire buone immagini (soprattutto con i siti più moderni che supportano loghi fino a 192x192 pixel[g]) oppure immagini di qualità molto scarsa (le prime favicon[g] erano grandi 16x16 pixel).
3.4.3 Estrazione delle informazioni testuali
Nonostante siano espresse in linguaggio naturale, le informazioni testuali da ricavare hanno comunque una struttura piuttosto definita e possono essere ricavate in modo sufficientemente preciso tramite ricerca con regular expression[g]o tramite altre metodologie euristiche, senza dover necessariamente ricorrere a strumenti di elaborazione del linguaggio naturale, i quali possono risultare pesanti in termini di prestazioni e di difficile apprendimento, comprensione e manutenzione.
3.4.3.1 Indirizzi Email
Gli indirizzi email sono ricavabili tramite due metodologie:
• Ricerca dei link html con prefisso mailto: Usati per richiamare da browser il software usato per la gestione della propria casella di posta e comporre una nuova email con destinatario precompilato [5];
• Ricerca tramite regular expression: Avendo una struttura ben definita, gli indirizzi email si prestano bene alla ricerca tramite espressioni regolari.
3.4.3.2 Link ai social media
Analizzando i siti web proposti, ho potuto ricavare quattro diverse metodologie per estrarre link ai social media dai siti aziendali:
• Analisi degli attributi class dei tag: Molte aziende inseriscono link o testo facente riferimento ai propri social media all’interno di tag o contenitori con class contenente la parola “social”;
• Analisi degli attributi id dei tag: Similmente alle class, molte aziende inseriscono link o testo facente riferimento ai propri social media all’interno di tag o contenitori con id contenente la parola
“social”;
• Analisi dei microdata Ld+Json: I microdata possono contenere un campo “sameAs” che identifica siti collegati alla stessa azienda, solitamente questo campo è usato per i social media;
• Analisi dei link: È possibile analizzare l’attributo href di tutti i link, alla ricerca di possibili social media, filtrandoli per dominio, i domini più usati sono Facebook, Instagram, YouTube e LinkedIn.
3.4.3.3 Partite IVA/Codici Fiscali
Le partite IVA in Italia hanno una struttura ben precisa composta da un eventuale codice nazione (IT) ed un numero ad 11 cifre.
Nei siti web questo pattern può essere preceduto da vari prefissi tra cui “P.I.”, “C.F” e “P.Iva”, quindi ho deciso di usare una lista dalla quale ricaverò una serie di alternative da inserire in un’espressione regolare.
Tale lista è simile alla seguente:
PARTITA_IVA_PREFIX = ["PI", "P.I", "P.I.", "CF",
"C.F.", "C.F", "P.Iva", "PIva",
"Partita IVA", "VAT", "UID"]
Tale lista andrà poi a generare il prefisso di un’altra espressione regolare atta a rilevare il resto del codice fiscale o partita IVA.
Questo permette di estendere facilmente i prefissi senza dover andare a modificare direttamente l’espressione regolare stessa.
3.4.3.4 Numeri telefonici
I numeri telefonici possono avere strutture molto diversificate, contenenti caratteri di separazione diversi in diverse posizioni, precedute da diversi prefissi e con una lunghezza che va dalle 6 alle 10 cifre.
È stata quindi costruita un’espressione regolare che possa accettare la maggior parte dei numeri di telefono incontrati finora.
3.4.3.5 Indirizzi geografici
Gli indirizzi geografici possono avere strutture estremamente eterogenee e non è possibile rappresentare tali strutture con un linguaggio regolare, ma è comunque possibile estrarne un sottoinsieme molto limitato che in molti casi può risultare soddisfacente.
Per questo sono state create due espressioni regolari per ricercare i due formati di indirizzo più comune, cioè quelli nei formati:
• prefisso strada numero località CAP paese provincia nazione
• CAP paese prefisso strada numero
Eventuali elementi non presenti sono stati gestiti all’interno dell’espressione, aumentando la probabilità di trovare una corrispondenza.
4 Analisi dei requisiti
Walking on water and developing software from a specification are easy if both are frozen.
Edward Berard
4.1 Casi d’uso
Dato che il sistema è quasi completamente automatico, e l’unico attore coinvolto è l’utente autenticato, i diagrammi dei casi d’uso sono pochi e molto semplici.
I dati necessari per l’esecuzione dello scraping sono automaticamente ricavati dallo stato della web-app, in modo che l’interazione dell’utente sia minima o nulla.
In Figura 1 si riportano i casi d’uso riguardanti l’obiettivo obbligatorio di creazione di una componente di Web Scraping.
Figura 1: Diagramma dei casi d’uso per la componente WebScraper
ID UC1.
Titolo Avvio dello web scraper.
Attori primari Utente Autenticato.
Pre-condizione L’attore è autenticato presso il sistema e visualizza il pulsante "Avvia Scraping".
Post-condizione Il sistema salva il risultato dello scraping in database.
Scenario principale
1. L’attore clicca sul pulsante "Avvia Scraping";
2. Il sistema avvia un task[g]in background[g] che effettua lo scraping;
3. Alla fine del task, il sistema salva in database i risultati dello scraping.
ID UC2.
Titolo Visualizzazione dei risultati dello scraping.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e visualizza il pulsante "Visualizza Risultati".
Post-condizione Il sistema visualizza una finestra modale[g] con i risultati dello scraping.
Scenario principale
1. L’attore clicca sul pulsante "Visualizza Risultati";
2. Il sistema recupera i dati dal database;
3. Il sistema visualizza a schermo una finestra modale con i risultati dello scraping.
ID UC3.
Titolo Riavvio di uno scraping completato.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e visualizza il pulsante "Riavvia Scraping".
Post-condizione Il sistema cancella i dati salvati, esegue un nuovo scraping e salva il risultato in database.
Scenario principale
1. L’attore clicca sul pulsante "Riavvia Scraping";
2. Il sistema avvia un task in background che elimina i dati esistenti ed effettua un nuovo scraping;
3. Alla fine del task, il sistema salva in database i risultati del nuovo scraping.
È stato inoltre pianificato un obiettivo desiderabile consistente nell’implementazione di una componente di scraping dal catasto, i cui casi d’uso sono esposti in Figura 2.
Figura 2: Diagramma dei casi d’uso per la componente LRScraper
ID UC4.
Titolo Avvio dello scraper catasto.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema e visualizza il pulsante "Avvia Scraping del Catasto".
Post-condizione Il sistema salva in database la lista degli omonimi in catasto corrispondenti alla ragione sociale del cliente cercato.
Scenario principale
1. L’utente clicca sul pulsante "Avvia Scraping del Catasto";
2. Il sistema avvia un task in background per ricercare gli omonimi del cliente cercato nei registri catastali;
3. Il sistema salva in database la lista degli omonimi trovati.
ID UC5.
Titolo Scelta dell’omonimo catastale da elaborare.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema e visualizza un elenco di omonimi catastali tra cui scegliere.
Post-condizione Il sistema salva in database i risultati dello scraping dell’omonimo catastale scelto.
Scenario principale
1. L’utente clicca su un omonimo catastale da elaborare;
2. Il sistema avvia un task in background per ricavare informazioni sull’omonimo scelto;
3. Il sistema salva in database il risultato dello scraping.
ID UC6.
Titolo Visualizzazione dei risultati dello scraping del catasto.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e l’utente visualizza il pulsante "Visualizza Risultati".
Post-condizione Il sistema visualizza una finestra modale contenente i risultati dello scraping effettuato.
Scenario principale
1. L’utente clicca sul pulsante "Visualizza Risultati";
2. Il sistema recupera dal database i dati corrispondenti allo scraping del cliente ricavato dal contesto;
3. Il sistema visualizza una finestra modale contenente i risultati dello scraping effettuato;
ID UC7.
Titolo Riavvio di uno scraping del catasto completato.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e l’utente visualizza il pulsante "Riavvia Scraping del Catasto".
Post-condizione Il sistema elimina i dati dello scraping precedente, e riavvia la procedura di scraping degli omonimi catastali.
Scenario principale
1. L’utente clicca sul pulsante "Riavvia Scraping del Catasto";
2. Il sistema elimina i dati dello scraping precedente per il cliente;
3. Il sistema avvia nuovamente il task di scraping degli omonimi catastali.
4.2 Tracciamento dei requisiti
Si riportano a seguire i requisiti in dettaglio, comprensivi di tracciamento ai rispettivi casi d’uso e decisioni, i requisiti sono classificati in forma tabellare e sono legati ad un codice così costituito:
R[Tipo Requisito][Priorità requisito] - [Identificativo Univoco]
Il tipo di requisito è rappresentato da uno dei seguenti codici:
• F: Requisito Funzionale;
• Q: Requisito di Qualità;
• V: Requisito di Vincolo.
La priorità di un requisito è rappresentata da uno dei seguenti codici:
• 0: Obbligatorio, necessario per considerare il progetto completato con esito positivo;
• 1: Desiderabile, non necessario per completare con successo il progetto, ma che apporta ad esso un valore aggiunto notevole;
• 2: Facoltativo, non necessario per il completamento del progetto e che apporta dei benefici limitati ad esso.
L’identificativo univoco avrà forma numerica, nel formato [Padre].[Figlio].[Nipote].[. . . ].
4.2.1 Requisiti Funzionali
Tabella 6: Tabella di tracciamento dei requisiti funzionali
ID Descrizione Fonti Stato
RF0 - 1 Il sistema deve effettuare lo scraping di dati anagrafici da
Google Places API. UC1,
UC3 Soddisfatto
RF0 - 1.1 Il sistema deve ricercare una ragione sociale su Google Places
API in maniera diretta. UC1,
UC3 Soddisfatto
RF0 - 1.2 Il sistema deve ricercare una ragione sociale su Google Places API tramite ricerca fuzzy[g].
UC1,UC3 Soddisfatto
RF0 - 1.3 Il sistema deve ricavare dati dettagliati sull’azienda cercata
da Google Places API. UC1,
UC3 Soddisfatto
ID Descrizione Fonti Stato RF0 - 1.3.1 Il sistema deve ricavare l’indirizzo dell’azienda cercata su
Google Places API. UC1,
UC3 Soddisfatto
RF0 - 1.3.2 Il sistema deve ricavare le coordinate geografiche dell’azienda
cercata su Google Places API. UC1,
UC3 Soddisfatto
RF0 - 1.3.3 Il sistema deve ricavare l’URL del sito web dell’azienda
cercata su Google Places API. UC1,
UC3 Soddisfatto
RF0 - 1.3.4 Il sistema deve ricavare il nome dell’azienda trovato su
Google Places API. UC1,
UC3 Soddisfatto
RF0 - 1.3.5 Il sistema deve ricavare il “Place ID” di Google Places API
per l’azienda cercata. UC1,
UC3 Soddisfatto
RF0 - 1.3.6 Il sistema deve ricavare le categorie di cui l’azienda cercata
su Google Places API fa parte. UC1,
UC3 Soddisfatto
RF0 - 1.4 Il sistema deve essere in grado di salvare i dati ricavati da
Google Places nel database UC1,
UC3 Soddisfatto
RF0 - 2 Il sistema deve cercare il logo dell’azienda cercata,
analizzando il sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 2.1 Il sistema deve cercare il logo dell’azienda analizzando i fogli
stile CSS del sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 2.2 Il sistema deve cercare il logo dell’azienda analizzando l’attributo alt dei tag <img ...>, nel caso questi contengano la ragione sociale dell’azienda (fuzzy search)
UC1,UC3 Soddisfatto
RF0 - 2.3 Il sistema deve cercare il logo dell’azienda analizzando l’attributo alt dei tag <img ...>, nel caso questi contengano la parola “logo”
UC1,UC3 Soddisfatto
RF0 - 2.4 Il sistema deve cercare il logo aziendale analizzando l’attributo class dei tag <img ...>, nel caso questi contengano la parola “logo”
UC1,UC3 Soddisfatto
RF0 - 2.5 Il sistema deve cercare il logo aziendale analizzando l’attributo id dei tag <img ...>, nel caso contengano la parola “logo”
UC1,UC3 Soddisfatto
RF0 - 2.6 Il sistema deve cercare il logo aziendale analizzando l’attributo src dei tag <img ...>, nel caso il nome del file contenga la parola “logo”
UC1,UC3 Soddisfatto
RF0 - 2.7 Il sistema deve cercare il logo aziendale analizzando i microdata Ld+JSON del sito web aziendale alla ricerca del campo “logo”
UC1,UC3 Soddisfatto
ID Descrizione Fonti Stato
RF0 - 2.8 Il sistema deve cercare il logo aziendale analizzando i meta
tag Facebook/OpenGraph del sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 2.9 Il sistema deve cercare il logo aziendale analizzando i meta
tag Twitter del sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 2.10 Il sistema deve cercare il logo aziendale analizzando la
favicondel sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 2.11 Il sistema deve essere in grado di salvare il logo aziendale
trovato su disco UC1,
UC3 Soddisfatto
RF0 - 2.12 Il sistema deve essere in grado di salvare il percorso del logo
scaricato nel database UC1,
UC3 Soddisfatto
RF0 - 3 Il sistema deve ricavare dati anagrafici testuali dal sito web
aziendale UC1,
UC3 Soddisfatto
RF0 - 3.1 Il sistema deve analizzare il file robots.txt per cercare una
possibile sitemap XML del sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 3.2 Il sistema deve analizzare la sitemap XML del sito web
aziendale alla ricerca di una pagina contatti UC1,
UC3 Soddisfatto
RF0 - 3.2.1 Il sistema deve essere in grado di gestire sitemap XML
annidate all’interno di altre sitemap XML UC1,
UC3 Soddisfatto
RF0 - 3.3 Il sistema deve essere in grado di effettuare un crawling[g]del
sito web alla ricerca di una pagina contatti UC1,
UC3 Soddisfatto
RF0 - 3.3.1 Il sistema deve essere in grado di rispettare i limiti al
crawling imposti dal file robots.txt UC1,
UC3 Soddisfatto
RF0 - 3.4 Il sistema deve essere in grado di ricavare indirizzi email dal
sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 3.5 Il sistema deve essere in grado di ricavare indirizzi geografici
dal sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 3.6 Il sistema deve essere in grado di ricavare numeri di telefono
dal sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 3.7 Il sistema deve essere in grado di ricavare numeri di partita
IVA dal sito web aziendale UC1,
UC3 Soddisfatto
RF0 - 3.8 Il sistema deve essere in grado di ricavare indirizzi ai social media[g]dal sito web aziendale
UC1,UC3 Soddisfatto
ID Descrizione Fonti Stato RF0 - 3.9 Il sistema deve essere in grado di salvare i dati ricavati dai
siti web in database UC1,
UC3 Soddisfatto
RF0 - 4 Il sistema deve mettere a disposizione una componente
front-end per l’utente UC1,
UC3 Soddisfatto
RF0 - 4.1 Il sistema deve mettere a disposizione dell’utente un pulsante
per avviare la procedura di scraping UC1,
UC3 Soddisfatto
RF0 - 4.2 Il sistema deve mettere a disposizione dell’utente un pulsante
per riavviare una procedura di scraping già completata UC3 Soddisfatto RF0 - 4.3 Il sistema deve mettere a disposizione dell’utente un pulsante
per visualizzare i risultati di uno scraping già eseguito UC2 Soddisfatto RF0 - 4.4 Il sistema deve visualizzare all’utente una finestra modale
contenente i risultati dello scraping effettuato UC2 Soddisfatto RF0 - 5 Il sistema deve mettere a disposizione un pannello
amministrativo per la gestione dei modelli di database Decisione
Interna Soddisfatto RF1 - 1 Il sistema deve essere in grado di scaricare gli omonimi
catastali dal catasto nazionale UC4,
UC7 Soddisfatto
RF1 - 2 Il sistema deve mettere a disposizione dell’utente la possibilità di scegliere di quale quale omonimo catastale vuole fare lo scraping
UC5 Parzialmente
Soddisfatto
RF1 - 3 Il sistema deve essere in grado di scaricare i dati catastali di
un omonimo scelto UC6 Soddisfatto
RF1 - 3.1 Il sistema deve essere in grado di scaricare i dati presenti nelle tabelle del sito dell’Agenzia delle Entrate, contenenti informazioni limitate sugli edifici cercati
UC6 Soddisfatto
RF1 - 3.2 Il sistema deve essere in grado di scaricare fogli XML
contenenti le visure catastali degli edifici cercati UC6 Non Soddisfatto RF1 - 3.3 Il sistema deve essere in grado di estrarre il Foglio XML dai
documenti firmati p7m scaricati dall’Agenzia delle entrate UC6 Parzialmente Soddisfatto RF1 - 3.4 Il sistema deve essere in grado di salvare i dati estratti dalle
tabelle del catasto in database UC6 Soddisfatto
RF1 - 3.5 Il sistema deve essere in grado di salvare i dati estratti dai
file XML del catasto in database UC6 Non
Soddisfatto RF1 - 4 Il sistema deve essere in grado di visualizzare i risultati dello
scrapingdel catasto in una finestra modale UC6 Non
Soddisfatto
ID Descrizione Fonti Stato RF1 - 5 Il sistema deve mettere a disposizione dell’utente la
possibilità di riavviare uno scraping dal catasto già completato
UC7 Parzialmente
Soddisfatto
RF1 - 6 Il sistema deve poter salvare un’immagine della home page[g]
del sito web aziendale UC1,
UC3 Soddisfatto
RF1 - 6.1 Il sistema deve poter salvare un’immagine della home page
del sito web aziendale su disco UC1,
UC3 Soddisfatto
RF1 - 6.2 Il sistema deve poter salvare il percorso dell’immagine della home pagedel sito web aziendale scaricata all’interno del database
UC1,UC3 Soddisfatto
4.2.2 Requisiti di Qualità
Tabella 7: Tabella di tracciamento dei requisiti di qualità
ID Descrizione Fonti Stato
RQ0 - 1 Ogni componente dello scraping da Google Places API deve
essere coperta da test automatici di unità Piano di
Lavoro Soddisfatto RQ0 - 2 Ogni componente dello scraping dal sito web aziendale deve
essere coperta da test automatici di unità Piano di
Lavoro Soddisfatto RQ1 - 1 Ogni componente deve contenere al proprio interno dei
commenti di documentazione in stile PyDoc Decisione
Interna Soddisfatto RQ1 - 2 La copertura del codice da parte dei test deve essere
superiore al 75% Decisione
Interna Soddisfatto RQ2 - 1 Ogni componente dello scraper del catasto deve essere
coperto da test automatici di unità Piano di
Lavoro Non
Soddisfatto RQ2 - 2 Ogni componente deve essere coperta da test automatici di
integrazione Piano di
Lavoro Parzialmente Soddisfatto RQ2 - 3 I test automatici del sistema creato devono integrarsi nella
suite di test esistente in Ayako Piano di
Lavoro Soddisfatto
4.2.3 Requisiti di Vincolo
Tabella 8: Tabella di tracciamento dei requisiti di vincolo
ID Descrizione Fonti Stato
RV0 - 1 Il sistema deve mettere a disposizione degli endpoint[g] REST
per il web scraper Piano di
Lavoro Soddisfatto RV0 - 1.1 Il sistema deve mettere a disposizione un endpoint REST per
un sottoinsieme delle normali operazioni CRUD[g]sui risultati dello scraping tramite UUID[g]
Piano di
Lavoro Soddisfatto
RV0 - 1.1.1 Il sistema deve mettere a disposizione un endpoint REST per
il recupero dei risultati dello scraping tramite UUID Piano di
Lavoro Soddisfatto RV0 - 1.1.2 Il sistema deve mettere a disposizione un endpoint REST per
la cancellazione dei risultati dello scraping tramite UUID Piano di
Lavoro Soddisfatto RV0 - 1.1.3 Il sistema deve mettere a disposizione un endpoint REST per
l’aggiornamento manuale dei risultati dello scraping tramite UUID
Piano di
Lavoro Soddisfatto
RV0 - 1.2 Il sistema deve mettere a disposizione un endpoint REST per un sottoinsieme delle normali operazioni CRUD[g]sui risultati dello scraping tramite UUID del cliente
Piano di
Lavoro Soddisfatto
RV0 - 1.2.1 Il sistema deve mettere a disposizione un endpoint REST per
il recupero dei risultati tramite UUID del cliente Piano di
Lavoro Soddisfatto RV0 - 1.2.2 Il sistema deve mettere a disposizione un endpoint REST per
la cancellazione dei risultati tramite UUID del cliente Piano di
Lavoro Soddisfatto RV0 - 1.3 Il sistema deve mettere a disposizione un endpoint REST per
l’avvio della procedura di scraping tramite UUID del cliente da ricercare
Piano di
Lavoro Soddisfatto
RV0 - 2 L’architettura deve essere costruita facendo uso di Python 3.5 Decisione
Interna Soddisfatto RV0 - 3 L’architettura deve essere costruita facendo uso di Django 1.9 Decisione
Interna Soddisfatto RV1 - 1 Il sistema deve mettere a disposizione un endpoint REST per
l’avvio della procedura di scraping degli omonimi catastali, data la ragione sociale
Piano di
Lavoro Soddisfatto
RV1 - 2 Il sistema deve mettere a disposizione un endpoint REST per il recupero degli omonimi catastali scaricati, data la ragione sociale
Piano di
Lavoro Soddisfatto
ID Descrizione Fonti Stato RV1 - 3 Il sistema deve mettere a disposizione un endpoint REST per
l’avvio della procedura di scraping degli omonimi catastali, dato l’UUID del cliente
Piano di
Lavoro Soddisfatto
RV1 - 4 Il sistema deve mettere a disposizione un endpoint REST per il recupero degli omonimi catastali scaricati, dato l’UUID del cliente
Piano di
Lavoro Soddisfatto
RV1 - 5 Il sistema deve mettere a disposizione un endpoint REST per l’avvio della procedura completa di scraping dal catasto, dati ragione sociale ed indice nella lista ordinata degli omonimi
Piano di
Lavoro Soddisfatto
RV1 - 6 Il sistema deve mettere a disposizione un endpoint REST per l’avvio della procedura completa di scraping dal catasto, dati UUID del cliente ed indice nella lista ordinata degli omonimi
Piano di
Lavoro Soddisfatto
RV1 - 7 Il sistema deve mettere a disposizione un endpoint REST per un sottoinsieme delle normali operazioni CRUD sui risultati dello scraping del catasto, dato l’UUID del dato da ricavare
Piano di
Lavoro Soddisfatto
RV1 - 7.1 Il sistema deve mettere a disposizione un endpoint REST per il recupero di un risultato dello scraping del catasto, dato l’UUID del dato da ricavare
Piano di
Lavoro Soddisfatto
RV1 - 7.2 Il sistema deve mettere a disposizione un endpoint REST per la cancellazione di un risultato dello scraping del catasto, dato l’UUID del dato da ricavare
Piano di
Lavoro Soddisfatto
RV1 - 7.3 Il sistema deve mettere a disposizione un endpoint REST per l’aggiornamento manuale di un risultato dello scraping del catasto, dato l’UUID del dato da ricavare
Piano di
Lavoro Soddisfatto
4.2.4 Riepilogo Requisiti
Tabella 9: Riepilogo dei requisiti
Tipo Requisito Obbligatorio Desiderabile Facoltativo Totale
Funzionale 42 13 0 55
Di qualità 2 2 3 7
Di Vincolo 11 10 0 21
Totale 55 25 3 83
5 Progettazione
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
Abraham Lincoln
5.1 Tecnologie e strumenti
5.1.1 Python 3
Python [7] è un linguaggio di programmazione interpretato[g], con pre-compilazione in bytecode[g]che supporta diversi paradigmi di programmazione, tra cui il paradigma object-oriented[g], la programmazione funzionale[g]
e la reflection[g].
Le caratteristiche a prima vista più evidenti di Python sono la definizione dei blocchi di codice tramite indentazioni di 4 spazi (invece di usare le parentesi graffe tipiche di linguaggi come C++), oltre all’uso del duck typing[g] per l’identificazione dei tipi a runtime.
Python offre un’estesa libreria standard, in cui sono inclusi strumenti per lo sviluppo di applicazioni che si interfacciano con il web, il filesystem ed una libreria standard dedicata allo unit testing[g].
La scelta di questo linguaggio è obbligata, dato che è il linguaggio con cui è stata sviluppata l’intera architettura esistente.
5.1.2 Flake8
Flake8 [11] è un software di analisi statica di codice Python il cui obiettivo principale è forzare il rispetto delle normative stilistiche PEP-8 [6], ma permette anche di rilevare incorrettezze che provocherebbero il non funzionamento del codice scritto.
Questo strumento è stato scelto per la propria capacità di integrazioni in diversi editor, configurabilità ed immediatezza.
5.1.3 Django
Django [8] è un framework[g]per lo sviluppo di applicazioni web che comprende al proprio interno una serie di strumenti integrati dedicati a risolvere i problemi più comuni che si incontrano durante lo sviluppo di applicazioni web, tra cui amministrazione, gestione degli accessi e gestione del database.
Essendo il framework su cui si basa l’intera architettura esistente, il suo uso è obbligatorio.
5.1.4 DjangoREST
DjangoREST [9] è un framework che si integra con Django per lo sviluppo di applicazioni web che fanno uso dello stile architetturale REST[g], comprendendo politiche di autenticazione basate su OAuth e JWT.
Dato che DjangoREST è il framework usato per la gestione delle chiamate REST dell’architettura, il suo uso è obbligatorio.
5.1.5 Celery
Celery [10] è una coda asincrona e distribuita di task orientata all’esecuzione di compiti in tempo reale.
Dato che questa è la coda già in uso nell’architettura esistente, la scelta di questo prodotto è obbligatoria.
5.1.6 Swagger
Swagger [12] è una serie di strumenti per la semplificazione dello sviluppo di API[g], tra le varie caratteristiche include un’interfaccia web che consente di visualizzare e testare le API create.
Questa serie di strumenti è stata messa a disposizione dall’azienda ospitante all’interno dell’architettura esistente, perciò l’uso di questo software è obbligatorio.
5.1.7 Vagrant
Vagrant [13] è uno strumento di costruzione e gestione di macchine virtuali, basato sull’automazione, così da avere a disposizione un ambiente uniforme fra tutti i collaboratori per lo sviluppo di un progetto software.
La scelta di questo software è obbligata, facendo parte del sistema di sviluppo adottato dall’azienda ospitante.
5.1.8 VirtualBox
VirtualBox [14] è uno strumento di virtualizzazione che consente di eseguire un sistema operativo ospite (detto appunto guest), all’interno di un diverso sistema operativo ospitante (chiamato host). In questo progetto VirtualBox è usato come motore di esecuzione da Vagrant.
La scelta di questo software è obbligata, facendo parte del sistema di sviluppo adottato dall’azienda ospitante.
5.1.9 BeautifulSoup4
BeautifulSoup4 [15] è una libreria che facilita la navigazione, ricerca e l’elaborazione di documenti HTML ed XML. Solitamente viene usata per operazioni di web scraping[g].
Questa scelta è stata fatta in virtù dell’ottima integrazione della libreria con il linguaggio Python, oltre ad essere una libreria già disponibile tra le dipendenze dell’architettura esistente.
5.1.10 PostgreSQL
PostgreSQL è un DBMS[g] per la gestione di database relazionali, conosciuto per affidabilità, robustezza e prestazioni, oltre che per essere un progetto con oltre 30 anni di sviluppo alle spalle.
Questo è il DBMS usato all’interno dell’architettura preesistente, quindi la sua scelta è obbligata.
5.1.11 Selenium
Selenium [17] è un framework di testing di applicazioni web che consente di manovrare in maniera automatizzata un browser (tramite Selenium WebDriver) ed analizzare la pagina visualizzata dal browser stesso.
Questo framework può anche essere usato per la navigazione automatizzata di siti internet.
La scelta di questo framework è stata dettata dalla necessità di catturare schermate delle pagine principali dei siti internet.
5.1.12 Requests
Requests [18] è una libreria che semplifica ed astrae l’invio di richieste HTTP/1.1, gestendo autonomamente la connessione. Questo permette di avere codice più leggibile all’interno di moduli che fanno uso di richieste HTTP.
Oltre ad essere già messo a disposizione come dipendenza nell’architettura preesistente, questa libreria permette di creare codice di gestione delle richieste HTTP che risulta molto leggibile e per questo è stato scelto.
5.1.13 NeoVIM
NeoVIM [19] è un editor di testo derivato da VIM che mette a disposizione un ambiente estremamente personalizzabile, cerca/sostituisci basato su espressioni regolari, evidenziazione della sintassi ed un’estesa libreria di plugin[g] creati dalla comunità.
Questo strumento è stato scelto per la velocità di esecuzione, flessibilità, supporto della comunità ed estrema libertà nella personalizzazione.
5.1.14 JavaScript
JavaScript [20] è un linguaggio di programmazione (inizialmente era un linguaggio di scripting) orientato agli oggetti [22] comunemente usato nella programmazione web lato client, ma a volte anche lato server (grazie a Node.js). Questo linguaggio è stato standardizzato da ECMA international tramite lo standard ECMAScript.
Questo linguaggio è già stato adottato per lo sviluppo del front-end dell’architettura preesistente, quindi l’uso di questo linguaggio risulta una scelta obbligata.
5.1.15 ESLint
EsLint [21] è uno strumento per identificare errori nel codice JavaScript, con l’obiettivo di rendere il codice più consistente ed evitare bachi, oltre che forzare alcune norme di codifica specificate nel proprio file di configurazione.
Questo strumento è stato scelto in virtù della propria flessibilità e velocità di esecuzione e messa in opera.
5.1.16 ReactJS
React [23] è una libreria JavaScript per la creazione di interfacce utente basata sulla creazione di componenti e la loro composizione per la creazione di interfacce anche molto complesse.
Questa tecnologia è già stata adottata per lo sviluppo del front-end dell’architettura preesistente, quindi l’uso di tale tecnologia è obbligatorio.
5.1.17 Redux
Redux [24] è una libreria open-source[g]che funge da contenitore di stati predicibile per applicazioni JavaScript, così da poter gestire lo stato globale di un’applicazione.
Questa tecnologia è già stata adottata per lo sviluppo del front-end dell’architettura preesistente, quindi l’uso di tale tecnologia è obbligatorio.
5.1.18 Bundle-js
Bundle-js [25] si occupa di concatenare file JavaScript in un determinato ordine, così da creare un unico file ed evitare scaricamenti multipli da parte della web-app in esame.
Questo strumento fa parte dell’infrastruttura che esegue le build del front-end, quindi l’uso di questo strumento è obbligatorio.
5.1.19 Scrapy
Scrapy [26] è stato usato in questo progetto a scopo di studio ed analisi per la creazione di un’architettura specifica.
Scrapy è un framework di web crawling[g]e web scraping basato su Python.
5.2 Ciclo di vita del software
Come modello di ciclo di vita del software si è optato per un modello incrementale [27, cap. 8-5 §2.2, p. 152], il cui diagramma è esposto in Figura 3, con elementi Kanban[g]per l’organizzazione dei compiti giornalieri.
Figura 3: Schema del ciclo di vita incrementale
Il prototipo in lavorazione era sempre visibile ai proponenti e si è optato per un rilascio settimanale dei prototipi contenenti specifiche funzionalità, arrivando quindi a 7 prototipi ed un rilascio finale della componente.
L’elemento Kanban di cui si è fatto uso è una “lavagna virtuale” per il tracciamento dei compiti giornalieri e per avere una visuale d’insieme dell’andamento del progetto, un esempio di tale “lavagna” è visibile in Figura 4.
Figura 4: Esempio di lavagna Kanban
5.3 Design Pattern utilizzati
5.3.1 Chain of Responsibility Design Pattern
Il primo design pattern usato è il chain of responsibility pattern [28], usato per la gestione di situazioni in cui non si conosce a priori quale funzione può gestire una determinata situazione e si vuole consentire l’estensione futura delle possibilità di gestione. In Figura 5 è esposto il diagramma delle classi di questo design pattern.
Figura 5: Esempio di chain of responsiblity pattern
In questo pattern si definisce un’interfaccia che permette la gestione di una richiesta ed eventualmente implementa un link ad un “nodo successivo”: nel caso il nodo interpellato non possa gestire la richiesta, tale richiesta verrà delegata al nodo successivo, fino a quando non si troverà un nodo in grado di gestirla.
Questo consente un’ottima flessibilità nell’aggiunta, rimozione e riordino degli stadi di gestione.
5.3.2 Pipeline design pattern
Il pipeline design pattern, così come usato in questo progetto, è un pattern con struttura identica al chain of responsibility pattern ma le differenze sono sufficientemente marcate da richiedere una differenziazione. In Figura 6 è esposto il diagramma delle classi del pipeline design pattern
Figura 6: Struttura del pipeline pattern
In maniera analoga al PipelineProcessing Pattern [29], il pipeline pattern riceve un input e lo passa attraverso una catena di stadi. A differenza del chain of responsibility pattern, il quale ferma l’elaborazione e ritorna un risultato quando un nodo gestisce la richiesta, senza modificare attivamente il dato passato, questo pattern elabora il dato e lo passa allo stadio successivo in ogni caso, similmente ad una catena di montaggio, fino alla fine della catena stessa.
Questo design pattern permette (con delle limitazioni) di riordinare gli stadi, rimuoverne o aggiungerne, aumentando la flessibilità del sistema.
5.4 Altre scelte di design
5.4.1 Interfacce fluide per la costruzione della pipeline
I costruttori dei vari stadi permettono l’inizializzazione diretta del nodo successivo, dando luogo a pezzi di codice poco leggibili, come il seguente che fa uso di molte indentazioni con soli 3 stadi:
Pipeline = FirstStage(
MiddleStage(
LastStage() ) )
Result = Pipeline.handleRequest(inputData)
Questo codice rende complesso il debugging dell’inizializzazione degli stadi, quindi solitamente si preferisce fare uso di variabili per ogni singolo stadio, ma questo provoca la necessità di costruire gli stadi “dall’ultimo al primo”:
Stage3 = LastStage()
Stage2 = MiddleStage(Stage3) Stage1 = FirstStage(Stage2)
Result = Stage1.handleRequest(inputData)
Un’interfaccia fluida [30] permette di collegare gli stadi in ordine, mettendo a disposizione del codice simile alla prosa scritta, semplice da leggere e con minori difficoltà nel debugging. Purtroppo dato che la struttura della catena è analoga ad una singly linked list[g], ogni aggiunta (effettuata in coda) ha costo computazionale O(n) con n numero degli stadi già presenti in coda.
Stage3 = LastStage() Stage2 = MiddleStage() Stage1 = FirstStage() Pipeline = Stage1
.then(Stage2) .then(Stage3)
Result = Pipeline.handleRequest(inputData)
5.5 Progettazione dell’architettura
L’architettura della componente è stata pensata come se fosse una “catena di montaggio”, in cui ogni componente dell’architettura interviene sul risultato finale, arricchendolo.
In Figura 7 si espone uno schema esemplificativo della procedura seguita dall’architettura per l’elaborazione dei dati:
