Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di un chatbot serverless con i servizi
AWS ed integrato su una Web App Angular
Tesi di laurea triennale
Relatore
Prof.Franceso Ranzato
Laureando
Enrico Trinco
Anno Accademico 2018-2019Enrico Trinco: Sviluppo di un chatbot serverless con i servizi AWS ed integrato su una Web App Angular, Tesi di laurea triennale, c Dicembre 2019.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata
di circa trecento ore, dal laureando Enrico Trinco presso l’azienda Zero12 s.r.l.
Lo stage consisteva nella realizzazione di un chatbot, basato su interfaccia conversazio-
nale, in modo da rendere più facile e veloce l’accesso alle informazioni di viaggio per i
dipendenti di un’azienda.
In secondo luogo doveva essere realizzata una Web App che esponesse il chatbot ed
offrisse opzioni di salvataggio ed eliminazione di una chat.
Il presente documento ha lo scopo di esporre il contesto aziendale nel quale ho operato,
l’attività di stage svolta e una valutazione finale sul lavoro eseguito.
iiiRingraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Francesco Ranzato, relatore
della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per il sostegno, il grande aiuto e per
essermi stati vicini in ogni momento durante gli anni di studio.
Ringrazio l’azienda Zero12 s.r.l. per avermi concesso l’opportunità di svolgere questo
progetto, in particolar modo Andrea Barcaro e Nicola dalla Costa per il supporto datomi
nell’apprendimento di diversi concetti.
Ultimi, ma non meno importanti, vorrei ringraziare i miei amici, veneti e non, per
aver reso indimenticabili questi miei anni universitari.
Padova, Dicembre 2019 Enrico Trinco
vIndice
1 Introduzione 1
1.1 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Suddivisione dei capitoli . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Note sul testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 L’azienda 3
2.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Filosofia dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Metodologia di lavoro . . . . . . . . . . . . . . . . . . . . . . . 4
3 Il progetto 5
3.1 Introduzione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Vincoli lavorativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Ambiente di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Metodologia adottata . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.3 Composizione del team . . . . . . . . . . . . . . . . . . . . . . 6
3.2.4 Orario di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Svolgimento del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1 Requisiti fissati . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Tecnologie utilizzate 9
4.1 Tecnologie chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Tecnologie Web App . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Progettazione 15
5.1 Visione dell’architettura generale . . . . . . . . . . . . . . . . . . . . . 15
5.2 Progettazione del chatbot . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 Prima presentazione del progetto e studio tecnologie . . . . . . 16
5.2.2 Comprensione dei servizi adottati . . . . . . . . . . . . . . . . . 17
5.2.3 AWS Lex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4 Progettazione AWS DynamoDB . . . . . . . . . . . . . . . . . 22
5.2.5 Progettazione AWS API Gateway . . . . . . . . . . . . . . . . 25
5.2.6 Definizione funzioni Lambda . . . . . . . . . . . . . . . . . . . 25
5.3 Progettazione parte utente Web App . . . . . . . . . . . . . . . . . . . 26
5.3.1 Studio tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.2 Definizione risorse AWS API Gateway . . . . . . . . . . . . . . 26
5.3.3 Pagina login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
viiviii INDICE
5.3.5 Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Progettazione parte admin Web App . . . . . . . . . . . . . . . . . . . 28
5.4.1 Definizione risorse AWS API Gateway . . . . . . . . . . . . . . 28
5.4.2 Pagina di gestione utenti . . . . . . . . . . . . . . . . . . . . . 29
5.4.3 Pagina di gestione delle utterances . . . . . . . . . . . . . . . . 29
5.4.4 Pagine di gestione tabelle . . . . . . . . . . . . . . . . . . . . . 30
6 Codifica 31
6.1 Organizzazione directory . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Pacchetti utilizzati per la comunicazione con i servizi AWS . . . . . . 32
6.3 Codifica del chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3.1 Invio di un messaggio al chatbot . . . . . . . . . . . . . . . . . 32
6.3.2 Gestione del messaggio con AWS Lex e AWS Lambda . . . . . 33
6.4 Integrazione del Chatbot sulla Web App . . . . . . . . . . . . . . . . . 34
6.4.1 Interfaccia di conversazione . . . . . . . . . . . . . . . . . . . . 34
6.4.2 Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.3 Salvataggio dei messaggi . . . . . . . . . . . . . . . . . . . . . . 36
6.4.4 Caricamento dei messaggi . . . . . . . . . . . . . . . . . . . . . 36
6.4.5 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5 Operazioni database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.1 Lettura dal database dei messaggi salvati di una chat . . . . . 38
6.5.2 Scrittura nel database di una conversazione di chat . . . . . . . 38
7 Conclusioni 39
7.1 Adempimento delle tempistiche e dei requisiti . . . . . . . . . . . . . . 39
7.1.1 Adempimento tempistiche . . . . . . . . . . . . . . . . . . . . . 39
7.1.2 Adempimento requisiti . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 Stato finale del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.1 Possibili miglioramenti sul progetto . . . . . . . . . . . . . . . . 40
7.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Glossario 43
Bibliografia 47Elenco delle figure
2.1 Logo zero12 s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Logo AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Logo AWS Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Logo Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 Logo AWS Lex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Logo AWS Dynamodb . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Logo AWS API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Logo AWS API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8 Logo AWS API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9 Logo AWS API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Visione dell’architettura . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Bozza del funzionamento del chatbot richiesto . . . . . . . . . . . . . . 16
5.3 Progettazione del chatbot . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4 Dashboard della Web App . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5 Interfaccia di chat della Web App . . . . . . . . . . . . . . . . . . . . . 27
5.6 Pagina di gestione degli utenti . . . . . . . . . . . . . . . . . . . . . . . 29
5.7 Pagina di gestione delle utterance . . . . . . . . . . . . . . . . . . . . . 29
5.8 Pagina di modifica tabella trasferimento sede . . . . . . . . . . . . . . 30
ixElenco delle tabelle
3.1 Tabella requisiti obbligatori . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Tabella requisiti desiderabili . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Tabella requisiti formativi . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Classificazione richiesta-argomento . . . . . . . . . . . . . . . . . . . . 18
5.2 Tabella dei dati necessari per ogni intent . . . . . . . . . . . . . . . . . 18
5.3 Campi tabella massimali hotel e pasti . . . . . . . . . . . . . . . . . . 22
5.4 Campi tabella utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Campi tabella voli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.6 Campi tabella trasferimento sede . . . . . . . . . . . . . . . . . . . . . 23
5.7 Campi tabella chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.8 Campi tabella soglia massima classe e pasti . . . . . . . . . . . . . . . 24
7.1 Tabella soddisfacimento dei requisiti . . . . . . . . . . . . . . . . . . . 39
xCapitolo 1
Introduzione
In questo capitolo viene data un’introduzione allo stage e viene descritta la suddivisone dei
capitoli
1.1 Stage
Nella fase conclusiva del ciclo triennale di informatica, ogni studente deve sostenere un
periodo di stage presso un’azienda convenzionata dall’Università di Padova. Lo scopo
principale dello stage è quello di dare allo studente l’opportunità di vivere un’esperienza
lavorativa nel proprio ambito di competenza, portando avanti un progetto concordato
e permettendogli di imparare e sperimentare nuove tecnologie o di rafforzare quelle già
apprese stando a contatto con il personale più esperto dell’azienda.
L’Università di Padova organizza annualmente l’evento StageIt, un’iniziativa che per-
mette di agevolare gli incontri tra imprese e studenti che devono sostenere lo stage
attraverso dei colloqui compresi tra i 15 e 20 minuti, dove l’azienda presenta i progetti
che intende sviluppare mentre lo studente si fa conoscere e chiede ulteriori informazioni.
Prima dell’evento è possibile leggere una lista delle aziende aderenti seguita da una
breve descrizione dei progetti che presenteranno.
Dopo diversi colloqui e proposte da altre aziende, ho deciso di affrontare questo
mio periodo con l’azienda Zero12 s.r.l.
Le motivazioni che mi hanno spinto a sceglierli sono le seguenti:
• La maggior parte dei progetti proposti hanno attratto la mia curiosità, consen-
tendo quindi di avere più scelte nel caso in cui uno dei progetti fosse stato già
preso da un altro studente;
• I progetti non erano fini all’attività di stage ma progetti che successivamente
verranno utilizzati da altre persone;
• Le tecnologie utilizzate dall’azienda, sia per il progetto che durante la loro attività
lavorativa, rientravano nell’insieme delle tecnologie che avrei voluto conoscere.
1.2 Suddivisione dei capitoli
Il secondo capitolo descrive il contesto aziendale nel quale ho lavorato.
12 CAPITOLO 1. INTRODUZIONE
Il terzo capitolo approfondisce il progetto svolto durante il periodo di stage, in
particolar modo viene descritto il progetto, com’è stato pianificato il lavoro, i
requisiti e risultati attesi.
Il quarto capitolo approfondisce le tecnologie coinvolte nello sviluppo.
Il quinto capitolo approfondisce la progettazione, dalla prima bozza mostrata fino
allo stato finale.
Il sesto capitolo approfondisce la codifica, approfondendo i punti più rilevati nella
realizzazione del chatbot.
Il settimo capitolo riporta le considerazioni finali sullo svolgimento dello stage e del
progetto.
1.3 Note sul testo
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
• gli acronimi vengono definiti nel glossario, situato alla fine del presente documento;
• per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: parola (g) ;
• i termini in lingua straniera sono evidenziati con il carattere corsivo.Capitolo 2
L’azienda
2.1 L’azienda
Zero12 s.r.l. è una piccola startup informatica fondata nel 2012 con sede operativa
a Carmignano di Brenta. L’azienda è specializzata nella gestione di progetti digitali,
creazione software B2B (g) , B2C (g) e nelle applicazioni mobile, prevalentemente iOS (g) .
È partner con Amazon Web Services e MongoDB, con i quali offre soluzioni scalabili
ed analisi dei Big Data (g) in tempo reale.
Figura 2.1: Logo zero12 s.r.l.
L’ambiente piccolo e giovane permette di ambientarsi velocemente al contesto aziendale
e di ricevere un veloce supporto da parte degli altri sviluppatori.
2.1.1 Filosofia dell’azienda
L’azienda costruisce le sue relazioni attraverso sei step:
1. Onboarding: vengono definiti gli obiettivi, tempi e metodi delle diverse attività
del progetto insieme al cliente;
2. Training: basandosi sulle informazioni ottenute dalla precedente fase, viene
definito un piano formativo per ottimizzare le risorse interne;
3. Cloud and Data Design: viene realizzata una configurazione ed installazione
delle infrastrutture cloud attraverso Amazon Web Services e di architetture
database attraverso MongoDB;
34 CAPITOLO 2. L’AZIENDA
4. Sviluppo software: attività di realizzazione dell’applicativo software o affian-
camento del team di sviluppo del cliente;
5. Monitoraggio e tuning: viene monitorata l’esecuzione del progetto per l’otte-
nimento di feedback sull’esecuzione e per prevenire eventuali problematiche;
6. Supporto al progetto: il cliente viene affiancato durante le fasi di lancio e
vengono effettuate verifiche periodiche sul prodotto.
2.1.2 Metodologia di lavoro
L’azienda utilizza una metodologia di lavoro agile (g) . Questa metodologia si basa su
quattro principi:
• Persone ed iterazioni piuttosto che processi e strumenti;
• Collaborazione col cliente piuttosto che negoziazione del contratto;
• Software funzionante piuttosto che avere una documentazione esaustiva;
• Risposta al cambiamento piuttosto che seguire un piano
Zero12 segue questi quattro punti attraverso i seguenti principi:
• Stretta collaborazione: il team coinvolge costantemente il cliente attraverso
meeting online, attività on-site o presso l’azienda. Viene effettuata così una
collaborazione col cliente, condividendo così eventuali problemi ed effettuando
una retrospettiva per ottenere risultati migliori;
• Valorizzare il team: il team deve essere responsabile di ogni azione che compie.
Per perseguire questo obiettivo il team deve essere coinvolto in ogni fase del
processo decisionale;
• Feedback rapidi: attraverso un rilascio periodico di quanto realizzato, vengono
raccolti feedback costanti e precisi dalle persone;
• Realizzazione di soluzioni semplici: il prodotto software viene realizzato
partendo da quello che è necessario per il corretto funzionamento e non da quello
che potrebbe esserlo.Capitolo 3
Il progetto
In questo capitolo viene effettuata una descrizione più approfondita del progetto, sui
requisiti e sulle condizioni esso legate.
3.1 Introduzione del progetto
Il progetto consiste nella realizzazione di un chatbot (g) che permetta ai dipendenti di
un’azienda di recuperare le informazioni sui viaggi aziendali e i relativi costi, sui trasfe-
rimenti tra due sedi, sulle destinazioni supportate, sui limiti di spesa ed informazioni
sulle modalità di viaggio.
Devono essere realizzate inoltre delle API RESTful (g) JSON (g) , con la quali il chatbot
dovrà interagire per fornire le risposte agli utenti.
Inoltre, il chatbot deve appoggiarsi ad una piattaforma mobile o ad una Web App (g)
in modo da permetterne l’interazione da parte dell’utente.
Lo scopo del progetto, in concomitanza della realizzazione del chatbot, consiste anche
nella sperimentazione dei servizi offerti da Amazon Web Services, in particolar modo
del servizio AWS Lex, in modo da vedere le potenzialità che possono offrire e come
essi riescono ad interfacciarsi tra di loro.
3.2 Vincoli lavorativi
3.2.1 Ambiente di lavoro
L’azienda permette di lavorare sia presso la sede operativa, sia a casa da remoto. Per
lo stage si è concordato che l’intera attività venisse svolta presso la sede operativa,
permettendo così di:
• Lavorare a contatto con gli altri programmatori;
• Adottare la metodologia aziendale per lo sviluppo del software.
3.2.2 Metodologia adottata
L’azienda ha stabilito l’utilizzo della loro metodologia di lavoro agile. Ogni Lunedì si
teneva un meeting con il responsabile, attraverso i quali si discuteva dell’operato svolto
56 CAPITOLO 3. IL PROGETTO
la settimana precedente, in modo da rivedere in tempo reale gli obiettivi settimanali
oppure definire nuovi miglioramenti al progetto.
3.2.3 Composizione del team
Il progetto non prevedeva l’affiancamento ad altri programmatori. Nonostante questo
gli altri dipendenti hanno comunque dato la disponibilità ad aiutarmi nel comprendere
concetti o nel darmi consigli sulla codifica.
3.2.4 Orario di lavoro
Da regolamento, le ore totali di stage devono essere comprese tra le 300 e le 320 ore.
Per rispettare tale vincolo si è deciso seguire i seguenti orari:
• Inizio stage: 2 Settembre;
• Fine stage: 25 Ottobre;
• Orario lavorativo: Da lunedì al venerdì, ore 8:30-17:30
Per un totale di 320 ore di stage.
3.3 Svolgimento del progetto
Lo stage si è svolto nel seguente modo:
• Introduzione del progetto e studio delle tecnologie di Amazon Web
Services: Il primo giorno, il tutor aziendale mi ha presentato una bozza di
progettazione del chatbot e della piattaforma d’appoggio, illustrandomi il flusso
dell’applicazione e i servizi di Amazon Web Services più adatti. Dopo la spiega-
zione del progetto, le prime due settimane si sono concentrate principalmente
sullo studio di tali servizi;
• Progettazione e codifica del chatbot: dopo una migliore comprensione delle
tecnologie da adottare, è iniziata la fase di progettazione, fornendo una migliore
descrizione delle funzionalità e di ciò che richiedeva il chatbot. Successivamente
é iniziata una prima fase di codifica.
• Studio delle tecnologie per la piattaforma d’appoggio: dopo aver realizza-
to una versione semi definitiva del chatbot, ho voluto dedicarmi alla piattaforma
d’appoggio. Attraverso un meeting con il responsabile, si è deciso di adottare
un template di Angular per creare la piattaforma sulla quale il chatbot si sa-
rebbe successivamente integrato. I giorni successivi sono dedicati allo studio e
apprendimento del framework Angular attraverso la sua documentazione;
• Codifica della Web App: dopo la fase di studio ho iniziato a realizzare
la Web App. Il primo obiettivo consisteva nel riuscire a collegare il chat-
bot all’applicazione, successivamente si è pensato alla dashboard ed infine
all’autenticazione.
• Miglioramenti Chatbot e WebApp e documentazione: le ultime due
settimane le ho dedicate a migliorare le risposte e il codice del chatbot e della
Web App. Infine ho provveduto a documentare il codice e le API.3.3. SVOLGIMENTO DEL PROGETTO 7
3.3.1 Requisiti fissati
Viene ora definita una lista dei requisiti concordati con l’azienda. Questi requisiti sono
classificati nel seguente modo:
R[Tipo][Numero]
Dove il valore Tipo corrisponde a:
• O: obbligatorio, un requisito che deve essere necessariamente soddisfatto in
quanto richiesto dal committente;
• D: desiderabile, un requisito non vincolante o non strettamente necessario ma
dal riconoscibile valore aggiunto.
• F: formativo, un requisito che ha come scopo l’insegnamento o l’apprendimento
di una nozione.
Mentre il valore Numero corrisponde ad un numero identificativo univoco per ogni
requisito.
3.3.1.1 Requisiti obbligatori
Requisito Descrizione
RO1 Integrazione con il servizio Lex di Amazon Web Services
RO2 Progettazione di architettura a microservizi Amazon Web Services
possibilmente serverless.
RO3 Creazione di API e back-end (g) per il caricamento delle
informazioni.
RO4 Realizzazione di una Web App come appoggio per il Chatbot.
Tabella 3.1: Tabella requisiti obbligatori8 CAPITOLO 3. IL PROGETTO
3.3.1.2 Requisiti desiderabili
Requisito Descrizione
RD1 Introduzione di un sistema di analisi semantica del testo come
AWS Comprehend;
RD2 Ottimo livello di comprensione dei messaggi inviati dall’utente e
qualità delle risposte fornite;
Tabella 3.2: Tabella requisiti desiderabili
3.3.1.3 Requisiti formativi
Requisito Descrizione
RF1 Avvicinamento allo sviluppo di architetture a microservizi
RF2 Entrare nel contesto di sviluppo di sistemi di Intelligenza Artificiale
RF3 Sperimentare tecnologie nuove
RF4 Lavorare in un contesto operativo dinamico
Tabella 3.3: Tabella requisiti formativiCapitolo 4
Tecnologie utilizzate
In questo capitolo vengono introdotte le tecnologie utilizzate durante lo svolgimento del
progetto, differenziando quelle adottate per il chatbot e quelle per la Web App
4.1 Tecnologie chatbot
4.1.1 Amazon Web Services
Amazon Web Services, conosciuto anche con la sigla AWS, è una piattaforma che
offre centinaia di servizi IT (g) in cloud (g) come servizi di sviluppo, storage, database,
elaborazione serverless, apprendimento automatico e molto altro. Ciò che rende AWS
una buona piattaforma è la facilità nell’accesso a tali servizi attraverso una conso-
le (g) dedicata per ognuno di essi, permettendo così ad uno sviluppatore meno esperto
di creare e gestire al meglio il servizio selezionato.
Oltre alla facilità d’uso è molto usato dalle imprese per il fatto che vengono esonerate
dagli oneri di installazione, gestione e manutenzione hardware e server.
I servizi di AWS non sono completamente gratuiti: ognuno di essi offre un piano
base gratis ma, al superamento di tale soglia, AWS addebiterà il relativo costo ogni 30
giorni.
Figura 4.1: Logo AWS
4.1.1.1 AWS Lambda
AWS Lambda è un servizio che permette di eseguire codice per qualsiasi applicazione
o servizio back-end in modalità serverless.
Viene impiegato principalmente in risposta ad eventi come le chiamate HTTP di
AWS API Gateway oppure per l’invocazione di codice attraverso le API offerte dagli
AWS SDK (g) , permettendo così la gestione ed elaborazione degli altri servizi attraverso
la codifica.
910 CAPITOLO 4. TECNOLOGIE UTILIZZATE
I linguaggi supportati dal runtime di Lambda sono i seguenti:
• Node.js nelle versioni 8.X e 10.X;
• Python nelle versioni 2.7, 3.6 e 3.7;
• Java 8;
• Ruby 2.5;
• C#;
• Go 1.x.
Figura 4.2: Logo AWS Lambda
Durante la lettura, le funzioni create con questo servizio saranno chiamate funzioni
Lambda con la lettera L maiuscola in modo da evitare ambiguità con le funzioni
lambda, anche dette funzioni anonime.
4.1.1.2 Python
Python è un linguaggio di programmazione open source (g) ad alto livello (g) e fortemente
tipizzato che supporta diversi paradigmi di programmazione quali:
• Orientamento agli oggetti;
• Imperativo;
• Funzionale.
Durante il progetto è stata utilizzata la versione 3.6.
Figura 4.3: Logo Python
4.1.1.3 AWS Lex
AWS Lex è un servizio che permette la creazione di chatbot attraverso un’interfaccia di
conversazione sia testuale che vocale ed è lo stesso motore di comunicazione utilizzato
per Alexa.
Ogni bot è caratterizzato da uno o più intent, i quali rappresentano un particola-
re contesto di conversazione del bot. Un intent si conclude quando questo viene
dichiarato Fullfilled o Rejected4.1. TECNOLOGIE CHATBOT 11
Ogni conversazione con un bot di Lex inizia con l’inserimento da parte dell’uten-
te di una utterance, una particolare frase che indica al bot quale comportamento
adottare verso l’utente, le informazioni di cui ha bisogno per soddisfare l’intent e come
rispondergli.
L’utilizzo delle funzioni Lambda permette di rendere dinamico e sicuro il flusso della
conversazione e di adattare le risposte in base ai messaggi ricevuti dall’utente.
Figura 4.4: Logo AWS Lex
4.1.1.4 AWS DynamoDB
AWS DynamoDB è un database serverless NoSQL(g) che supporta modelli di dati di
tipo documento e di tipo chiave-valore come i file JSON.
La scelta di utilizzare AWS DynamoDB invece di MongoDB è data dal fatto che,
nonostante la scarsa conoscenza di entrambi, il primo è più facile da implementare con
gli altri servizi di AWS.
Figura 4.5: Logo AWS Dynamodb
4.1.1.5 AWS API Gateway
AWS API Gateway è un servizio che permette la creazione, mantenimento, gestione e
protezione di API Rest e WebSocket. In questo progetto il servizio è stato usato per la
creazione di API Rest, caratterizzate da:
• Utilizzo dei protocolli HTTP;
• Rispetto dell’architettura REST;
• Utilizzo di risorse e metodi;
• Implementazioni metodi standard GET, POST, PUSH e DELETE.12 CAPITOLO 4. TECNOLOGIE UTILIZZATE
All’atto della creazione di un metodo, AWS API Gateway ne richiede l’integrazione a
uno dei seguenti tipi:
• Funzione Lambda;
• Metodo HTTP;
• Mock (g) ;
• Servizio AWS;
Durante lo svolgimento del progetto, ogni chiamata alle API è stata collegata ad una
funzione Lambda dedicata.
Figura 4.6: Logo AWS API Gateway
4.1.1.6 AWS Cognito
AWS Cognito è un servizio che permette la creazione, gestione e manutenzione di un
pool di utenti. Fornisce strumenti di accesso, registrazione e controllo degli accessi per
Web App e mobile.
Cognito è composto da due componenti:
• Cognito User Pool: directory utente di Cognito che fornisce le operazioni di
registrazione ed accesso (anche attraverso i social network), un’interfaccia web
per l’accesso e funzioni di protezione quali l’autenticazione a più fattori oppure
la verifica dell’email e telefono;
• Cognito Identity Provvider: directory attraverso la quale l’utente autenticato
riceve delle credenziali temporanee di AWS per accedere ed utilizzare determinati
servizi.
Figura 4.7: Logo AWS API Gateway4.2. TECNOLOGIE WEB APP 13
4.2 Tecnologie Web App
4.2.0.1 Typescript
Linguaggio di programmazione open source sviluppato da Microsoft. Estende il
linguaggio di programmazione JavaScript fornendo il supporto della tipizzazione e delle
interfacce durante la fase di codifica.
Durante la fase di compilazione il linguaggio viene prima tradotto e poi compilato
in JavaScript, permettendo così di avere un maggiore controllo e comprensione sulla
codifica.
Figura 4.8: Logo AWS API Gateway
4.2.0.2 Angular 8
Framework open source sviluppato da Google ed utilizzato per la creazione di Web
App attraverso l’uso di HTML e TypeScript.
Figura 4.9: Logo AWS API Gateway
Un’applicazione Angular di base deve possedere almeno due elementi fondamentali:
• Modulo: elemento che contiene le funzionalità della Web App quali componenti,
direttive e servizi. Se sono presenti più moduli, questi vengono combinati insieme,
permettendo così di creare l’applicazione finale.
• Componente: elemento che contiene i dati o la logica dell’applicazione. Ad ogni
componente è collegato un template HTML per permetterne la visualizzazione.
Di default sono presenti un componente, definito AppComponent, e un modulo, definito
AppModule.
Sono presenti ulteriori elementi per migliorare lo sviluppo della Web App quali Guardie
e Servizi.Capitolo 5
Progettazione
5.1 Visione dell’architettura generale
In questo progetto è stata richiesta l’adozione di un’architettura a microservizi. Questo
tipo di architettura è basata su componenti indipendenti che eseguono ogni processo
come un servizio. Ogni servizio adempie ad un unica funzione e comunicano attraverso
API leggere.
L’adozione di questa architettura è molto vantaggiosa dato che permette una buona
scalabilità vista l’indipendenza di ogni singolo servizio.
Figura 5.1: Visione dell’architettura
Nelle prossime sezioni verrà prima approfondita la progettazione riguardante il chatbot
e successivamente quella riguardante la Web App.
1516 CAPITOLO 5. PROGETTAZIONE
5.2 Progettazione del chatbot
5.2.1 Prima presentazione del progetto e studio tecnologie
Il primo giorno di stage mi è stata presentata una bozza di progettazione del chatbot,
spiegandomi il funzionamento che avrebbero dovuto adottare i servizi coinvolti.
Figura 5.2: Bozza del funzionamento del chatbot richiesto
Non avendo mai avuto esperienze pregresse con la suite di servizi AWS, prima di
iniziare la progettazione mi sono posto le seguenti domande:
• Come funzionano gli strumenti scelti?
• Come si integrano tra di loro?
Per poter rispondere a queste domande, ho affrontato un periodo di studio della
documentazione dei servizi richiesti, con relativi esempi d’uso.
Successivamente ho iniziato un piccolo progetto indipendente in cui ho applicato tutto
ciò che ho appreso, realizzando un chatbot di utilità per appuntare su Google Calendar
gli esami universitari al quale l’utente era interessato.
Alla fine di questo periodo sono riuscito a dare una risposta alle domande che mi ero
posto ed ero pronto ad iniziare la progettazione del chatbot commissionato.5.2. PROGETTAZIONE DEL CHATBOT 17
5.2.2 Comprensione dei servizi adottati
La progettazione del chatbot verte su questi servizi:
• AWS Lex: creazione del chatbot composto da uno o più intents;
– Intents: contesto della conversazione del bot. Un singolo intent è caratte-
rizzato dai seguenti elementi:
∗ Slots: rappresentano le informazioni necessarie al bot per adempiere
all’intent;
∗ Sample utterances: frasi con le quali il bot riconosce un intent. Per
una maggiore precisione nel riconoscimento, devono essercene molte e
possono contenere uno o più slot.
∗ Lambda code hook : funzioni Lambda che vengono aggiunte al bot in
modo da rendere più dinamico il flusso della conversazione.
• AWS DynamoDB: definizione delle tabelle richieste per la memorizzazione
delle informazioni necessarie per le risposte del chatbot;
• AWS API Gateway: definizione delle API necessarie all’utente per chattare
con il chatbot;
• AWS Lambda: definizione delle funzioni necessarie per il corretto funziona-
mento del bot e per l’integrazione tra i diversi servizi AWS.
Figura 5.3: Progettazione del chatbot
La fase di progettazione di questi servizi è molto importante e delicata. Oltre al fatto
di avvantaggiare la parte di codifica bisogna prestare attenzione alle risorse che un
servizio utilizza durante l’esecuzione, in modo da minimizzarne il costo mensile. Ad
esempio AWS Lambda addebita un costo in base al tempo d’esecuzione e la memoria
richiesta mentre AWS DynamoDB addebita un costo in base al numero di letture e
scritture che vengono effettuate sulla tabelle.18 CAPITOLO 5. PROGETTAZIONE
5.2.3 AWS Lex
5.2.3.1 Definizione degli intents
Il chatbot deve essere in grado di rispondere a diverse richieste dell’utente. Queste
possono essere classificate in base all’argomento trattato.
Richiesta di un utente Argomento trattato
Raggiungimento di una determinata sede Cambio sede
Modalità di spostamento in una determinata destinazione Elenco trasporti
Vincoli di spesa e classi prenotabili per voli, treni e auto Massimali
Costo totale di un viaggio Informazioni viaggio
Informazioni sulle modalità di richiesta di un viaggio Informazioni generali
Informazioni sulle modalità d’uso dei veicoli Informazioni veicoli
Tabella 5.1: Classificazione richiesta-argomento
Grazie a questa classificazione è possibile determinare il numero di intents necessari al
soddisfacimento delle richieste passate.
5.2.3.2 Approfondimento degli intents
Per ogni intent è necessario capire il tipo di dati di cui necessita, come l’utente può
invocarlo e come dev’essere gestito il flusso della conversazione affinché si riesca a
concluderlo.
Slots (tipo di dati)
Uno slot aiuta a definire i tipi di dati necessari al bot per adempiere all’intent e vengono
impiegati quando un’utterance da sola non riesce ad adempierlo completamente.
Per ognuno di essi si è quindi approfondito quello che è necessario al suo soddisfacimento:
Intent Dati necessari
Cambio sede Sedi disponibili, mezzi di trasporto disponibili
Elenco trasporti Destinazioni disponibili
Massimali Ruoli dell’azienda
Informazioni viaggio Destinazioni disponibili
Informazioni generali Nessun dato richiesto
Informazioni veicoli Mezzi di trasporto disponibili
Tabella 5.2: Tabella dei dati necessari per ogni intent5.2. PROGETTAZIONE DEL CHATBOT 19
Dopo un attenta lettura dei documenti fornitomi dall’azienda committente, i tipi di
slot che sono stati creati per il chatbot sono i seguenti:
• travelDestination: slot contenente le destinazioni disponibili;
• officesVal: slot contenente tutte le sedi del cliente;
• transportType: slot contenente i tipi di trasporto disponibili:
• carService: slot contenente i servizi disponibili se si utilizza la macchina come
mezzo di trasporto;
• clientRole: slot contenente i ruoli assegnabili ai dipendenti dell’azienda.
Sample utterances (Invocazione dell’intent)
Le sample utterances consistono in frasi che aiutano il bot a capire quale intent in-
vocare. In questo modo, quando l’utente invia un determinato messaggio o ne invia
uno simile, il chatbot riconosce il corrispondente intent, rispondendo in base ai dati
ricevuti dall’utente.
Nel caso in cui il messaggio inviato dall’utente non corrisponda a nessuna utterance
disponibile, il chatbot risponderà con una frase di fraintendimento. Se dopo un determi-
nato numero di tentativi, specificati dallo sviluppatore, il bot continuerà a non capire,
chiuderà la sessione di chat con un messaggio di chiusura e fallimento nell’adempimento.
Il numero di utterance disponibili deve quindi essere il più ampio possibile ma, al
contempo, non deve portare a casi di ambiguità nella scelta dell’intent.
In tutti gli intent sono state inserite molteplici utterances, tutte quante classificabili in
queste tre categorie:
• Utterance base: utterance basata sul nome dell’intento, ad esempio "Informa-
zioni sui veicoli ";
• Utterance articolate: utterance basata su una frase completa, ad esempio
"Quali veicoli sono disponibili ";
• Utterance composte: utterance articolate con l’inserimento di campi slot
all’interno. In questo modo, se l’utente è certo di sapere quello che vuole, può
specificare fin da subito i campi slot senza che sia il bot a richiederli.
Esempio di utterance composta: "Devo andare a {sede} in {veicolo} " dove i
valori sede e veicolo sono riempiti con tipi slot validi.
Per questa parte è stato necessario il supporto di più persone, in modo da avere più
varietà nella creazione delle utterances.20 CAPITOLO 5. PROGETTAZIONE
Lambda code hook (Gestione del flusso conversazionale)
Da solo il servizio AWS Lex offre soltanto delle operazioni basilari, con poca persona-
lizzazione delle risposte e non garantisce nessun controllo sui dati passati dall’utente.
Ad esempio, in caso di prenotazione di un appuntamento, non viene controllato se
la data in questione è già occupata, rischiando quindi di dare informazioni sbagliate
all’utente.
Per effettuare questo tipo di controlli, AWS Lex permette di aggiungere una o due
funzioni Lambda per gestire i casi di:
• Inizializzazione e validazione: la funzione Lambda viene collegata al servizio
e verrà eseguita ogni volta che il bot avrà compreso l’intent;
• Adempimento: la funzione Lambda viene richiamata quando l’utente forni-
sce tutti gli slot richiesti ed esegue le operazioni necessarie all’adempimento
dell’intent.
Per avere un controllo completo delle conversazioni, per ogni intent è stata creata una
funzione Lambda dedicata che gestita entrambi i casi.
Ogni funzione Lambda è progettata per gestire i seguenti stati di conversazione:
• Richiesta di un dato slot: il bot interpreta correttamente il messaggio ma
necessita di uno o più dati prima di poter adempiere all’intent;
• Richiesta di un intent: il bot non è riuscito a collegare il messaggio ad
un’intent;
• Conferma operazione: il bot richiede una conferma o negazione prima di poter
adempiere all’intent;
• Chiusura conversazione: il bot invia una risposta di chiusura della sessione.
La risposta varia in base al successo o meno nell’adempimento dell’intent.
Quando l’utente invia un messaggio, AWS Lex contatta la funzione Lambda collegata
all’intent attraverso il seguente file JSON:5.2. PROGETTAZIONE DEL CHATBOT 21
1 {
2 " currentIntent " : {
3 " name " : " intent - name " ,
4 " slots " : {
5 " slot name " : " value " ,
6 ...
7 },
8 " slotDetails " : {
9 " slot name " : {
10 " resolutions " : [
11 { " value " : " resolved value " } ,
12 { " value " : " resolved value " }
13 ],
14 " originalValue " : " original text "
15 },
16 " slot name " : { ... }
17 " confirmationStatus " : " None , Confirmed , or Denied
18 },
19 " bot " : {
20 " name " : " bot name " ,
21 " alias " : " bot alias " ,
22 " version " : " bot version "
23 },
24 " userId " : " User ID "
25 " inputTranscript " : " Text used to process the request " ,
26 " invocationSource " : " FulfillmentCodeHook or DialogCodeHook " ,
27 " outputDialogMode " : " Text " ,
28 " messageVersion " : " Version " ,
29 " sessionAttributes " : {
30 " key " : " value " ,
31 " key " : " value "
32 },
33 " requestAttributes " : {
34 " key " : " value " ,
35 " key " : " value "
36 }
37 }
Listing 5.1: input di AWS Lex ad AWS Lambda
Basandosi sull’utente, sul messaggio inviato e sulle informazioni contenute su currentIntent,
la funzione Lambda crea la risposta da ritornare ad AWS Lex che a sua volta ritornerà
all’utente.22 CAPITOLO 5. PROGETTAZIONE
5.2.4 Progettazione AWS DynamoDB
AWS DynamoDB, per gli scopi del progetto, è stato progettato per contenere le
chat con i relativi messaggi, le informazioni sugli utenti quali ruolo ed informazioni
sull’utilizzatore, ed infine le informazioni utili a garantire una risposta precisa all’utente.
Queste informazioni riguardano:
• Prezzi dei voli;
• Massimali hotel e pasti per destinazione;
• Soglie massime delle classi utilizzabili e di spesa giornaliera per i pasti;
• Sedi delle aziende con relativi mezzi disponibili;
• Destinazioni raggiungibili.
Per ogni informazione riportata è stata una creata tabella che sia in grado di contenerle
e che ne permetta un facile accesso. Di seguito viene riportata la struttura delle tabelle:
Tabella massimali hotel e pasti
Questa tabella rappresenta, per ogni ruolo, il costo giornaliero di hotel e pasti in base
alla destinazione. La chiave d’ordinamento è necessaria in quanto la chiave primaria
viene ripetuta più volte.
Nome Tipo Valore
role Chiave primaria String
destination Chiave ordinamento String
hotel Attributo Integer
meal Attributo Integer
Tabella 5.3: Campi tabella massimali hotel e pasti
Tabella utenti
In questa tabella vengono rappresentati gli utenti che utilizzano il chatbot. Ad ogni
utente viene associato un ID al quale corrispondono le informazioni personali e il ruolo
in azienda.
Nome Tipo Valore
id_employee Chiave primaria String
name Attributo String
role Attributo String
surname Attributo String
Tabella 5.4: Campi tabella utenti5.2. PROGETTAZIONE DEL CHATBOT 23
Tabella voli
In questa tabella viene rappresentato quanto un’impiegato, classificato per ruolo, può
spendere per il volo in una determinata destinazione. I prezzi sono divisi per classe.
Nome Tipo Valore
role Chiave primaria String
destination Chiave ordinamento String
business Attributo Integer
premium_economy Attributo Integer
Tabella 5.5: Campi tabella voli
Tabella trasferimento sede
In questa tabella viene rappresentata, per ogni sede dell’azienda, la disponibilità
dell’utilizzo di un veicolo e la relativa modalità d’uso.
Nome Tipo Valore
office Chiave primaria String
city Attributo String
airplane Attributo Object JSON
carPooling Attributo Object JSON
carSharing Attributo Object JSON
companyOwnCar Attributo Object JSON
taxi Attributo Object JSON
train Attributo Object JSON
Tabella 5.6: Campi tabella trasferimento sede
Tabella chat
In questa tabella vengono salvate le chat create dagli utenti.
Nome Tipo Valore
userId Chiave primaria String
chatName Chiave ordinamento String
botmessage Attributo String
usermessage Attributo String
Tabella 5.7: Campi tabella chat24 CAPITOLO 5. PROGETTAZIONE
Tabella massimali delle classi utilizzabili e la spesa massima per i pasti
In questa tabella viene rappresentato quanto un determinato ruolo può spendere, al
giorno, per i pasti e la massima classe selezionabile per ogni servizio di viaggio.
Nome Tipo Valore
role Chiave primaria String
destination Chiave ordinamento String
rent_car Attributo String
flight_minus4h Attributo String
flight_plus4h Attributo String
italo Attributo String
trenitalia Attributo String
breakfast Attributo Integer
launch Attributo Integer
dinner Attributo Integer
Tabella 5.8: Campi tabella soglia massima classe e pasti5.2. PROGETTAZIONE DEL CHATBOT 25
5.2.5 Progettazione AWS API Gateway
Nel contesto del chatbot, è necessaria una singola risorsa ’/chat’ che esponga un metodo
POST per inviare il messaggio al bot e ricevere una sua risposta.
Ogni volta che viene inviato un messaggio, l’API contatta la funzione Lambda ad essa
collegata, questa riceve in input il messaggio dell’utente e poi contatta il bot. Infine, a
risposta pronta, la ritorna all’utente.
Il metodo è configurato con un’integrazione proxy, una modalità d’implementazione
della funzione Lambda e dei metodi HTTP in grado di semplificare la creazione e
gestione del metodo. L’integrazione proxy è stata preferita all’integrazione normale (o
non proxy) perchè:
• La richiesta d’integrazione, ossia la fase di mappatura dei dati da parte di
API Gateway prima di essere passati al servizio di back-end, accetta qualsiasi
input inviato dell’utente. Se fosse stata un’integrazione non proxy si sarebbe
dovuto creare una mappatura specifica per ogni input.
• La risposta dell’integrazione, ossia la fase di mappatura del codice di stato,
intestazione e payload del back-end al formato richiesto dal client, è unica e non
modificabile, lasciando così una più semplice gestione della risposta della funzione
Lambda. La risposta è così strutturata:
1 {
2 " isBase 6 4 Encoded " : true | false ,
3 " statusCode " : httpStatusCode ,
4 " headers " : { " headerName " : " headerValue " , ... } ,
5 " multiValueHeaders " : { " headerName " : [ " headerValue " , "
headerValue 2 " , ... ] , ... } ,
6 " body " : "..."
7 }
Listing 5.2: struttura risposta AWS Lambda
Se fosse stata applicata un’integrazione non proxy, la risposta poteva essere
personalizzata ma a costo di una maggiore difficoltà nel gestirla lato client.
5.2.6 Definizione funzioni Lambda
Le funzioni Lambda sono ciò che uniscono i servizi, passando e manipolando le infor-
mazioni da uno all’altro.
Dopo la progettazione dei precedenti servizi, sono facilmente emerse le funzioni Lambda
necessarie per il corretto funzionamento del chatbot. Queste funzioni sono:
• Funzioni per gli intents: è stata creata una funzione Lambda per ogni intent
in modo da rendere la conversazione il più reale possibile. Queste funzioni si
interfacciano sia con AWS Lex per gestire il messaggio, sia con AWS DynamoDB
per reperire le informazioni necessarie;
• Funzione d’instradamento del messaggio: è stata creata una funzione Lamb-
da per inoltrare il messaggio al chatbot e, una volta elaborata la risposta, ritor-
narla all’utente.
Questa funzione inoltre traduce il messaggio in lingua italiana nel caso sia
richiesta.26 CAPITOLO 5. PROGETTAZIONE
5.3 Progettazione parte utente Web App
5.3.1 Studio tecnologie
Successivamente alla fase di progettazione e prima codifica del chatbot, ho dovuto
affrontare la parte di progettazione della Web App.
Dopo un meeting con il tutor aziendale si è deciso che la Web App dev’essere in grado
di offrire queste tre pagine:
• Login: Pagina di autenticazione per il dipendente;
• Dashboard: pagina principale per l’utente nella quale deve essere in grado di
creare, riprendere ed eliminare chat di conversazione;
• Chat: pagina nella quale l’utente è in grado di scambiare messaggi con il chatbot.
Per la realizzazione, sempre durante il meeting, il tutor mi ha consigliato l’utilizzo di
ngx-admin, un template per dashboard admin basato su tecnologia Angular 8+.
Non avendo mai avuto occasione di utilizzare ed imparare il framework Angular, la
prima settimana l’ho dedicata alla lettura della documentazione e alla realizzazione
degli esempi presentati.
5.3.2 Definizione risorse AWS API Gateway
Per la parte utente è stata configurata una risorsa API ’/database’ per il salvataggio e
il caricamento delle chat. Nello specifico vengono implementati i seguenti metodi:
• Metodo GET: ritorna la lista delle chat e lo storico dei messaggi;
• Metodo POST: crea nel database la nuova chat;
• Metodo DELETE: elimina la chat dal database.
5.3.3 Pagina login
La pagina di login presenta due campi input per l’inserimento del nome utente e della
password personale.
All’atto dell’autenticazione viene contattato il servizio AWS Cognito che provvede a
validare i dati e successivamente autentica l’utente.5.3. PROGETTAZIONE PARTE UTENTE WEB APP 27
5.3.4 Dashboard
La dashboard presenta due schede nelle quali è possibile creare e riprendere le conver-
sazioni.
Figura 5.4: Dashboard della Web App
Questa pagina è l’unico punto d’accesso al chatbot dato che, per avviare una chat, è
necessario fornirle titolo.
5.3.5 Chat
La pagina di chat presenta un’interfaccia conversazionale alla quale è viene collegato il
chatbot.
Figura 5.5: Interfaccia di chat della Web App28 CAPITOLO 5. PROGETTAZIONE
5.4 Progettazione parte admin Web App
Inizialmente non era prevista una parte dedicata all’admin dato che il chatbot viene
utilizzato dai dipendenti dell’azienda per ricercare informazioni velocemente, senza
l’ausilio di controlli admin. Successivamente è stato deciso di implementarla per i
seguenti motivi:
• Se l’impiegato IT dell’azienda trova un errore, può modificarlo senza dover
investire del tempo per contattarci ed attendere le modifiche;
• Si evita la creazione di particolari ruoli IAM (g) per AWS;
• L’impiegato IT può gestire tutto dalla Web App senza doversi interfacciare con
la console di AWS;
Un’utente admin è un dipendente della sezione IT dell’azienda utilizzatrice del chatbot.
Questo utente viene riconosciuto durante la fase d’autenticazione da AWS Cognito
grazie alla possibilità di assegnare gli utenti a dei gruppi.
La parte admin della Web App è stata progettata per poter eseguire modifiche alle
informazioni fornite dal chatbot, alle utterances e per gestire gli utenti utilizzatori.
5.4.1 Definizione risorse AWS API Gateway
Per la parte admin è stato necessario configurare delle risorse API per ogni pagina
presente.
La configurazione delle risorse per la parte dedicata all’admin risulta essere la seguente:
/admin
/bot
/utterances
/flights
/office-transfer
/user
Ognuna di queste risorse implementa i metodi GET, POST, PUT e DELETE,
fatta eccezione per le risorse utterance e office-transfer, ritenute non necessarie o
particolarmente onerose in termini d’implementazione dati i tempi ristretti.5.4. PROGETTAZIONE PARTE ADMIN WEB APP 29
5.4.2 Pagina di gestione utenti
Questa pagina consente la gestione completa degli utenti, dalla creazione alla rimozione.
Dato che l’applicazione verrà utilizzata solo in un contesto aziendale, la creazione degli
utenti non avverrà tramite registrazione ma solo attraverso l’utente admin.
Infine è disponibile una tabella a fine pagina nella quale è possibile vedere gli utenti
già registrati, rendendone più semplice per la gestione.
Figura 5.6: Pagina di gestione degli utenti
5.4.3 Pagina di gestione delle utterances
Questa pagina consente una completa gestione delle utterances di ogni intent, fornendo
le stesse operazioni della pagina utente.
Figura 5.7: Pagina di gestione delle utterance30 CAPITOLO 5. PROGETTAZIONE
5.4.4 Pagine di gestione tabelle
Sono state create le pagine adibite alla modifica di due tabelle utilizzate dal chatbot
per fornire le risposte.
Figura 5.8: Pagina di modifica tabella trasferimento sede
Le implementazioni di creazione e di rimozione nella pagina dedicata alla gestione
dei dati relativi ai voli sono state inserite solo a scopo sperimentale per studiare il
comportamento del database e non per un uso effettivo. Nel caso si utilizzassero:
• La creazione non porterebbe a risultati concreti dato che il chatbot non saprebbe
riconoscere le nuove destinazioni;
• La rimozione potrebbe causare problemi nella risposta fornita dal chatbot dato
che verrebbero effettuate query che non porterebbero a risultati.
Come per le precedenti pagine, è presente anche la tabella riassuntiva.Capitolo 6
Codifica
In questo capitolo vengono descritte le parti di codice ritenute significative per lo svolgimento
del progetto.
6.1 Organizzazione directory
Per tenere separato il codice dei servizi AWS da quello della Web App, sono state
create due directory :
• Funzioni Lambda: contiene tutte le funzioni Lambda necessarie al corretto
funzionamento dell’applicazione. Al suo interno sono presenti altre due directory,
create per separare le funzioni dedicate al chatbot (quali gestione degli intents e
richiamo del chatbot) da quelle dedicate altri servizi (quali AWS Cognito e AWS
DynamoDB);
• Web App: contiene i file necessari per il corretto funzionamento della Web App
e la documentazione delle relative API, effettuata tramite Swagger. Il codice
dell’applicazione risiede nella cartella src/app.
.
Progetto
Funzioni Lambda
Bot
DynamoDB_Cognito_API
Web App
Integrazione
src
app
admin
api
auth
login
pages
dashboard
chatbot
3132 CAPITOLO 6. CODIFICA
6.2 Pacchetti utilizzati per la comunicazione con i
servizi AWS
Per lo sviluppo del progetto sono stati di fondamentale importanza l’adozione dei
seguenti SDK:
• Boto3: SDK rilasciato da AWS che permette di semplificare le integrazioni di
funzioni e applicazioni Python con i relativi servizi AWS.
L’installazione avviene da terminale nel seguente modo:
$pip3 install boto3
• AWS Amplify: pacchetto per semplificare l’integrazione dei servizi AWS nelle
Web App e nelle applicazioni mobile. L’installazione avviene da terminale nel
seguente modo:
$npm install aws - amplify
6.3 Codifica del chatbot
6.3.1 Invio di un messaggio al chatbot
Quando l’utente invia un messaggio dalla Web App, l’API di riferimento contatta la
funzione Lambda dedicata alla gestione del messaggio dell’utente.
Come prima cosa è necessario istanziare il servizio AWS Lex attraverso Boto3. Sola-
mente dopo è possibile richiamare la funzione post_text, funzione che permette di
scambiare messaggi con il chatbot.
1 travelBot = boto3 . client ( " lex - runtime " )
2
3 response = travelBot . post_text (
4 botName = " TravelInformation "
5 botAlias = " test "
6 userId = event [ ’ headers ’ ][ ’ username ’]
7 inputText = message
8 )
Listing 6.1: invio messaggio ad AWS Lex
La risposta ritornata da AWS Lex è un JSON contenente diverse informazioni quali:
• Risposta testuale del chatbot;
• Intent attuale;
• Stato della conversazione;
Dal momento che il formato della risposta ritornata dalla funzione Lambda deve essere
uguale alla struttura mostrata nella sezione 5.2.5, la risposta del chatbot è contenuta
nel campo Body.6.3. CODIFICA DEL CHATBOT 33
6.3.2 Gestione del messaggio con AWS Lex e AWS Lambda
Quando AWS Lex ha ricevuto il messaggio passato dalla funzione post_text, viene
controllato se è possibile associarlo ad un intent.
In caso positivo, viene contattata la funzione Lambda collegata ad esso passandogli il
JSON visto nella sezione 5.2.3.2.
A messaggio ricevuto, la funzione Lambda ne analizza il contenuto e genera la risposta
basandosi su uno dei quattro stati elencati nella sezione 5.2.3.2.
Le possibili risposte tornate sono le seguenti:
• Richiesta di un dato slot: ritorna un codice ElicitSlot, accompagnato da
un messaggio e dallo slot richiesto per continuare la conversazione.
1 def response_elicit_slot ( session_attributes ,
message_to_return , intent_name , slot , ste ) :
2 return {
3 " sessionAttributes " : session_attributes ,
4 " dialogAction " : {
5 " type " : " ElicitSlot " ,
6 " message " : message_to_return ,
7 " intentName " : intent_name ,
8 " slots " : slot ,
9 " slotToElicit " : ste
10 }
11 }
Listing 6.2: funzione richiesta slot
• Conferma operazione: ritorna un codice ConfirmIntent sul campo type,
accompagnato da un messaggio al quale l’utente è invitato ad esprimere una
risposta affermativa o negativa.
• Chiusura del messaggio: ritorna un codice Close sul campo type ed è accom-
pagnato da un messaggio di chiusura. In questa risposta è presente un campo
fulfillmentState che è uguale a Fulfilled se l’intent è stato soddisfatto con
successo, altrimenti è Rejected34 CAPITOLO 6. CODIFICA
6.4 Integrazione del Chatbot sulla Web App
6.4.1 Interfaccia di conversazione
Viene ora descritta la struttura della directory contenete i file necessari alla corretta
esecuzione della pagina dedicata all’interfaccia di conversazione:
• chatbot.module.ts: rappresenta il modulo Angular dedicato.
• chatbot.service.ts: rappresenta il servizio Angular dedicato. Si occupa di
gestire la parte logica del chatbot e le comunicazione con gli altri servizi
• chatbot.component.ts: rappresenta il componente Angular dedicato. Si
occupa di gestire la parte visiva della pagina.
• chatbot.component.html: rappresenta il template HTML. Questo file viene
importato nel decorator del file chatbot.component.ts per definire il DOM.
• chatbot.component.scss: rappresenta il foglio di stile utilizzato per persona-
lizzare l’interfaccia di conversazione.
6.4.1.1 Invio di un messaggio
Quando un utente invia un messaggio attraverso l’interfaccia di conversazione, viene
richiamata la funzione sendMessage. Di base questa funzione crea due messaggi, uno
che rispecchia il messaggio dell’utente e l’altro una risposta già predefinita dal creatore
del template.
Subito dopo i messaggi vengono inseriti nell’array message, contenitore collegato
al template HTML il quale si aggiorna ad ogni inserimento, mostrando a schermo i
nuovi messaggi.
1 async sendMessage ( event : any ) {
2 this . messages . push ({
3 text : event . message ,
4 date : new Date () ,
5 reply : true ,
6 type : ’ text ’ ,
7 user :
8 {
9 name : ’ You ’ ,
10 avatar : ’ user - avatar . jpg ’
11 },
12 }) ;
13
14 const botReply = this . chatShowcaseService . reply ( event . message
);
15 if ( botReply ) {
16 setTimeout (() = > { this . messages . push ( botReply ) } , 500) ;
17 }
18 }
Listing 6.3: funzione sendMessage prima dell’integrazione6.4. INTEGRAZIONE DEL CHATBOT SULLA WEB APP 35
6.4.2 Integrazione
Partendo dalla funzione sendMessage, l’integrazione dei messaggi con il chatbot è
stata effettuata apportando le seguenti modifiche:
• Rimozione delle risposte predefinite;
• Creazione funzione di richiamo delle API;
• Creazione funzione di gestione del messaggio del chatbot;
La funzione usata per richiamare l’API è la seguente:
1 // chatbot . service . ts
2 handleMessage ( passedMessage , usern : string , selectedLanguage :
string , token : string ) : Observable < JSON >{
3 const header = {
4 ’ username ’: usern ,
5 ’ language ’: selectedLanguage ,
6 ’ inizialize ’: ’ false ’
7 }
8 const requestOption = {
9 headers : new HttpHeaders ( header )
10 }
11 return this . http . post < JSON >( botAPI , passedMessage ,
requestOption )
Listing 6.4: funzione handleMessage
La funzione ritorna un Observable, un tipo di dato della libreria Rxjs simile al
tipo Promise ma con la peculiarità di poter tornare più valori invece di uno solo.
Al ricevimento della risposta da parte di AWS API Gateway, viene eseguito il codice
all’interno della funzione subscribe, impostando così la risposta del bot come risposta
al messaggio di chat inviato dall’utente.
1 // chatbot . component . ts
2 async sendMessage ( event : any ) {
3 this . messages . push ({...}) // Push messaggio utente
4 // Integrazione
5 var mesForBot : messageToTheBot ={
6 message : event . message
7 }
8 this . chatService . handleMessage ( mesForBot , this . user . username ,
this . selectedLanguage , this . tok ) . subscribe ( lexResp = > {
9 var botReply : messageStructure = {
10 type : ’ text ’ ,
11 text : lexResp [ ’ message ’] , // messaggio chatbot
12 date : new Date () ,
13 reply : false ,
14 user :{
15 name : ’ AziendaBot ’ ,
16 avatar : ’ user - avatar . jpg ’
17 },
18 }
19 }
Listing 6.5: funzione sendMessage con l’integrazionePuoi anche leggere
